【DBMS】みずほ銀行 使用していたデータベースの運用に問題か 富士通製「Symfoware Server」 [雷★]
■ このスレッドは過去ログ倉庫に格納されています
(略)
インデックスファイルがメモリー容量を超過
報告書によると、2月28日のシステム障害の発端は勘定系システム「MINORI」の一部である「定期性預金システム」のデータベース（DB）でトラブルが続発したことにあった。1年以上記帳がない定期預金の口座約45万件を、通帳を発行しない「みずほe-口座」へ一括して切り替える処理の作業中に、DBに存在する「取消情報管理テーブル」のインデックスファイルのサイズが、確保していたメモリー容量を超過した。その結果、DBの更新処理ができなくなった。
定期性預金システムのDBで更新処理エラーが続発したことをきっかけに、MINORIの司令塔に当たる「取引メイン」と呼ばれるシステムで、さらなる不具合が発生した。取引メインは定期性預金システムで起きたDB更新処理エラーに対応するため、その更新を自動的に取り消そうとした。しかし取り消し処理に必要な情報が定期性預金システムのDBに残っていなかったため、取り消し処理自体がエラーになる「二重エラー」が発生した。
MINORIは取引メインで二重エラーが相次ぎ発生すると、システムの全面停止を防止する措置を自動的に開始する。具体的には、勘定系システムに対するトランザクションの入り口にあたるATM処理システムや、みずほダイレクトの処理システムが稼働するメインフレームのパーティション（区画）をシャットダウン（閉塞）することで、トランザクションを抑制しようとした。ATM処理システムのパーティションが次々とシャットダウンしていった結果、ATMにおける通帳やキャッシュカードの取り込みが発生した。
2月28日のシステム障害の原因は突き詰めると、定期性預金システムのDBにおいてインデックスファイルのメモリー容量超過にあった。「一見初歩的なミス」（報告書）だが、その背景にはシステム運用における大きな問題があった。
次ページ
富士通製DBMSに特有の動作
https://xtech.nikkei.com/atcl/nxt/column/18/00001/05715/
ただし、ステータス変更自体は「それほど難易度の高い作業ではない」（片野常務）。データベースのテーブルにあるレコードのステータスを変更するだけだ。MINORIで定期性預金システムを構築したのは富士通であり、データベースは同社の「Symfoware Server」を用いている。簡単なSQLでステータスを変更できるはずだ。
https://xtech.nikkei.com/atcl/nxt/column/18/00138/030500746/ >>309
IT屋って責任問われると、こういう開き直り方するんだよねえ。
確かに我々にも問題があったかもしれない、
けどそれを分からなかったあなた方にも責任がある、
的な >>313
ITに限らずBtoBの場合大抵はそうなるよ。
双方に確認の義務がある。 >>313
通信事業者にしてもSI屋にしても平気で嘘をつくことがある
障害理由を他社や他社製品のせいにしていたりは日常的
SI屋の回答に不満な顧客はメーカーとの契約を直接契約にしておくといい
直接契約なら直接質問を投げられるから 大手銀行の場合は日次で本番／災対サーバーのログを採取して監視するチームがいる
そこから警告上がってても何もしなかっただけでしょ 銀行のシステムなんて、ただのお金の増減管理するだけで、何が大変なんだよ。
知らんけど。 みずほと富士通なら、どっちが悪いかますますわからんなw この人金融関連みたいだけどみずほ？
時田さん ttps://www.fujitsu.com/jp/about/corporate/management/tokita/index.html
管理屋さんでしょうけれど 運用に問題があったという事はシステムの問題じゃないんだろ。最近の奴らはデータ容量なんかお構いなしに蓄積しやがる。要らないデータは消せよ。 >>319
みずほの田中さんに株主総会で質問したら? Symfoware Pro資格持ちですよ。
かれこれ15年くらい触ってないけど。
Oracleが好き！ select * from teikikouza； 更改案件で元は富士通で運用してましただと、落札するのNTTしかいなくなる方程式ができあがってるわ
これだから一強になっていくのに この手のジョブかコケた後対応ミスってデータロストするとアヒィィって叫び声上げるよね >>326
drop table teikikouza >DBに存在する「取消情報管理テーブル」のインデックスファイルのサイズが、確保していたメモリー容量を超過
どこの素人に発注したんだよｗ >>331
発注者が素人だっただけだぞ。
多分発注で使用決めた人はもう社内に居ないって落ちだと思う 1年以上記帳がない定期預金の口座約45万件を、通帳を発行しない「みずほe-口座」へ一括して切り替える処理の作業中に、DBに存在する「取消情報管理テーブル」のインデックスファイルのサイズが、確保していたメモリー容量を超過した。
やっぱ普段やらん処理を本番機でえいやあで流した結果やないか 定期預金なんて、そもそも１年以上記帳がないことが多いだろ。
なんで、違う通帳無しの口座タイプのe口座に
一括統合させるという運用方法が必要なのか理解できんわ。
異なる契約口座なんだから、定期預金口座DBの中で処理すりゃいいじゃん。 >>334
いきなり本番機かよｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
テストしないのは異常だわ。いろいろ社内体制がおかしくなってるんだろうなぁ >>13
限界テストやれば何が起こるか事前に確認できるだろ 営業時間内に、なんでDB書き換えなんかやるわけ？
富士通とか、ここのSEってCPコマンドは使わない主義？ >>334
最初はオレもそう思ったけど、報告書のクソっぷりよく見て考えが変わった。
定期で1年以上記帳しないなんて仕様なら毎日数千件は生じるだろう。だから日次処理なら巨大きな中間テーブルは要らないとも言える。
そして実行日に一年以上たっていると言う抽出条件なら専用の移管処理は要らないとも言える。
で対象が40万件にもなる場合もあるとは考えず一気に流したらアウト。違うかな？ >>1
おまいらFにひどい目に合わされすぎｗ
恨みつらみのオンパレードやないかーいｗ いやいや、運用に問題って書いてんじゃん
システムに問題があったら
損害賠償請求するよ
流石に >>343
最後のトリガーを押したのは運用
でも、そのボタンを用意したのは開発だな >>327
ちょっと待って欲しい
元々の富士通は札入れしなかったの？ FTの末端ベンダーと20年間事をした（こちらは末端ユーザー）
取締役か大株主とつながっているから、全部泣き寝入り。
機械の不調は全部ユーザーの責任
特に独自実装の時はひどかった。間違ったキー1個を1回押しただけでサービスマンを呼ぶ事態
それで「押したのが悪い」（マニュアルにも説明会にも何も無し）。俺が上から怒られた。
ソフト実装ミスで多数のデータが吹っ飛んでも、一言も（一字）もなし。
理由はOSのバージョン確認を未実施。俺は新バージョンで使えない事をたまたま知っていた（フリーソフトを業務用にそのまま組み込んだ！！）から、被害を免れた。それまでのインチキで身に染みていたし。
リース機械の交換時に、厳密に要求（「10年前！のケーブル1本が足りない」と文句を言う） FTにはいろいろある言いたいことがあるが
頭取が問題
2時半に事態を知ったら、緊急連絡体制を取り、臨時役員会・最高対策本部設置準備を指示すべき。
そうではなくずっと放置プレーのまま
顧客には「みずほ＝システム障害」のイメージがすり込まれているのに、トップ対応できず。
会長昇格は保留だが、実権を握る頭取には留任する。
「みずほ＝システム障害」のイメージ強化という結果を考えれば、FG本体のトップ3-7人も交代すべき。 ファーストユーザーの仕事やったよ。Symfoware 。
お笑い障害頻発でしょっちゅうPTFかかってたわｗ。 >>338
不治痛のSEなんかUNIXにログインすらできないよ。
スケジュール管理と予算管理しかできない。
下請けや子会社に丸投げしかした事ないからｗ。 小規模システムをMySQLとPostgreSQLで作り比べてみたらPostgreSQLの方がちょっとだけ速かったな
扱いやすさは慣れたら同じだから、もう好きな方使っとけって感じだ
でもPostgreSQLは文字コードで失敗しにくいから、うっかりさんにオススメ >>351
今はできるが以前のバージョンのmysqlはviewの作成ができなかった
ポスグレは最初っからview作成できる
だからオラクルの代わりにポスグレが選ばれる >>181
>>229
>>248
ここら辺みると古いシステムをだましだまし運用しなくちゃならない状況が見えてくる >>229
りそなもシンフォだよ。
俺はこの二行には絶対口座は作らない 個人的にはHiRDBよりDB2だな
HiRDBはあんま性能よくないんだよなあ ソニー、NEC、シャープ、富士通、エプソン
どうしてこうなった・・・ ■ このスレッドは過去ログ倉庫に格納されています
