アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
スケープゴート? (スコア:0, 余計なもの)
無理やりソフトでカバーしようとして発生したとか、
そもそもソフトは関係ないけど、単に
『ソフトの不具合でした』と言っておけば原因究明を
逃れられるからとか、
そんなことを予想してしまいました。
原因不明なのに「13:30から稼動再開」って、
それってソフトが原因だとしたらおかしくないですか?
古いテーブルをよんでいた? (スコア:4, 参考になる)
http://www.asahi.com/business/update/1101/071.html
東証は会見で「処理件数を引き上げた際に、10月末に
システムの中の証券会社のデータのある場所を自動的に
変えるようにしたが、その際に古い(システムの)
データを取り込んだために障害が起きたのではないか」
との見方を示した。
どうやら10月の頭のシステム増強のとき仕組まれたバグ
だったようで…
Re:古いテーブルをよんでいた? (スコア:1, 参考になる)
「 障害の原因はプログラムミス。10月に拡張した新システムが、月末に自動で
行われるデータ圧縮処理に対応できていなかったため障害が起きたという。」
・・・う~~む。
Re:古いテーブルをよんでいた? (スコア:1)
最新の記事 [itmedia.co.jp]によると、
> 東証のシステムは毎月末、データ格納領域の空き部
> 分を整理・統合し、各データの格納位置を最適化する
> 処理を自動で行う。10月末の自動処理の際、証券会社
> のコードなどを記録したデータの格納位置が変わった
> が、新ソフトがデータの移動先を特定できず、障害が
> 発生したという。
圧縮じゃなくてガーベジコレクション時の障害っぽいですね
こういう処理は週末にやった方がいいんじゃないの?と思うのは間違い?
Re:スケープゴート? (スコア:1, 参考になる)
(IDとパスないと見れないかも)
>今回のトラブルに影響した月次バッチ処理は、毎月、ディスクのフラグメンテーション
>を解消し空き容量を回復するために行われているもの。この処理により月末にディスク上
>のデータの配置場所が変わるが、新しいプログラムは何らかの理由でこの変更を認識せず、
>以前の場所にデータを読みに行ったと見られる。
(中略)
>東証は午後、手動で会員情報テーブルをデータベースに書き込み直し、システムを復旧させた。
書いてある事はともかくとして、意訳すると要するにDB再編成の事だとおもわれる。
という事はDBMSのバグっぽい気がする。
システム拡張に併せてバージョン/リビジョンアップしたのかな。
# しかし、記事自体が怪しい気がする。
Re:スケープゴート? (スコア:0)
毎月フォーマットしなおした新パーティションにコピーしてたんでしょう。
で奇数月は D: ドライブ、偶数月は E: ドライブを読むはずが、
件のテーブルを読むモジュールだけドライブ名をコードに直書きしてたのでしょう。
Re:スケープゴート? (スコア:0)
>テーブルを読むモジュールだけドライブ名をコードに
データベースって言ってるんだからモジュール内にドライブ名なんてある訳ないじゃん。
元ACのDBのバグに1票。
更新されたプログラム自体は実は全然問題無かったのでは??
とりあえずこないだの更新のせいにしとけと・・・スケープゴートにされたって感じ??
Re:スケープゴート? (スコア:0)