神戸新聞のシステム障害はOracle9iのバグが原因 64
ストーリー by mhatta
Oracleはようわからん 部門より
Oracleはようわからん 部門より
あるAnonymous Coward 曰く、
神戸新聞の報道によれば、9月22日から23日にかけて同社の紙面製作システムに障害が発生し、 記事が製作不能になっていた件 (復旧の続報)の原因は、「Oracle9i Database」のバグにあったとのこと。
バグの内容だが、DB起動時に履歴データと現在のデータを照合して不一致がないかをチェックする部分にバグがあり、データを効率的に検索するために統計情報の採取処理をした後でデータベースのシステムを強制終了すると、履歴データと一致しないことが想定されるにもかかわらずプログラムはデータの不一致を障害と判断して、稀に起動できなくなるというものらしい。神戸新聞側の運用に問題は無かったとのこと。
日本オラクルによれば、今回のようなデータ不一致と、特定手順での終了から再起動にかけての一連の動作が同時に発生することは極めて稀で、これまで深刻なトラブルが発生した事例が世界でも報告されていなかったために、想定外の事例であったとしている。 当然、不具合を回避する手順も想定されていなかったために問題の切り分けに手間取ったようだ。
なおオラクルでは、修正プログラムを配布して対応するとしている。
Oracleサポート情報 (スコア:5, 参考になる)
SHUTDOWN ABORT を含む強制終了後の次回インスタンス起動時に、ORA-600[kcratr1_lostwrt] が発生しデータベースがオープンできない [oracle.co.jp]
＃珍しく公開区分が「一般公開」になっていますね。
＃いつもだと、「契約顧客のみ」なのに・・・
ITProによるとサーバ2重化していたけれども駄目だったようですね。
【続報】神戸新聞の制作システムが回復、サーバー2重化もDBで障害 [nikkeibp.co.jp]
神戸新聞のシステム障害はオラクルDBの問題、修正プログラム配布へ：ITpro [nikkeibp.co.jp]
NECでサーバ2重化となるとCLUSTERPROかftサーバになるんでしょうが、
shutdown immediateさせずにわざわざshutodown abortになっていたのであれば
以下のレジストリのSHUTDOWNTYPEをOracle 9iのデフォルトのi(immediate)からa(abort)に変えてあったか、CLUSTERPROの設定が悪かったのか・・・
http://download-east.oracle.com/docs/html/B10163_01/registry.htm#g1015622 [oracle.com]
良い教訓になったことでしょう (スコア:2, 興味深い)
良い教訓になったでしょう。
＃昔は「完璧なソフトウェアなど存在しないのだから
＃テストを重ねて地雷を避けるのもSEの腕」と教わったけどな。
＃今って全般的にテスト工程が温いんじゃないか？
Re:良い教訓になったことでしょう (スコア:4, 興味深い)
そういう妄想をしてくれていれば御の字
トラブったときに「著名なメーカー品でそうなら仕方ないか」と責任回避できる
という思考の人もいるんですよ
# ええ、弊社とかに
商用DB (スコア:1, 興味深い)
DB屋さんは商用DBって他に何か使ってます？
Re:商用DB (スコア:2, 参考になる)
SQLserverとか
Accessとか・・
それよか、Shutdown abortってフツーの運用なの？
Re:商用DB (スコア:5, 興味深い)
ただ、業務用システムでwindowsをサーバとしたものなんかだと、システム停止手順がスタートメニューからシャットダウンってのもよく見かける。あれをやると次回起動時はリカバリから始める事になるわけで、oracleの障害復旧能力に依存したシステム設計ってことになるね。意外と多いんだ、これが。
Re:商用DB (スコア:2, 興味深い)
スタートメニュー→シャットダウン 程度のことでリカバリーが発生するのは
なんとなく不細工だなぁ。少なくとも常駐アプリなりサービスなり組み込んで
きちんとoracleのシャットダウンができる様にしておかないと。>oracle
その程度のアプリなんぞ作るのは大して手間じゃないだろうに。(特許除く)
#中に組み込むのもそんなに手間じゃないけど、既稼働分との関係もあるから
#外部アプリとしての話をしてみました。
Re:商用DB (スコア:1, すばらしい洞察)
まぁ、DBの規模にもよりますが、OSのshutdownが始まってからロールバックかけて終了処理をしてと、処理が終わらないうちにOS側のタイムアウトに引っかかってしまう気がするのでどの道だめっぽいですが。
Re:商用DB (スコア:0)
シャットダウンに時間がかかるような状態でabortしたら スタートアップにもっと時間がかかるような気がするし。
Re:商用DB (スコア:0)
Re:商用DB (スコア:0)
Re:商用DB (スコア:0)
気のせいだったかな?
Re:商用DB (スコア:0)
Re:商用DB (スコア:0)
# ・・・この違いは大きいのか小さいのか・・・
# フレームの元かもしれんのでＡＣ
Re:商用DB (スコア:0)
Re:商用DB (スコア:1)
MicrosoftによるとWindowsのシャットダウンより前にExchange Serverのすべてのサービスを手で落とさないといけません。
そういう意味での仕様で、少なくとも2003まではそうです。2007で改善されていればいいですが。
だから電源の障害でUPSのバックアップ期間内に落とすにはExchange Serverサービス群をnet stopするスクリプトを書いておけばいい。
Re:商用DB (スコア:0)
他人任せでほったらかし、てのは、やはり米国製の大雑把さなんですかねぇ。
国産アプリメーカーなら、主力級のDBあたりを商品として出していたなら
スタートメニューの終了への対応位はすると思いますよ。
Re:商用DB (スコア:0)
Re:商用DB (スコア:0)
ユーザにすりゃアプリであろうが無かろうがどっちでもいいよ、んなもん。(笑)
Re:商用DB (スコア:1, 興味深い)
Re:商用DB (スコア:0)
うちのはそうなってるんで、これはどうかと思ってたんだけど
特殊な例ではないということか。
Re:商用DB (スコア:5, 興味深い)
一回だけ必要に駆られて Shutdown abort したときがある。
それは当時の開発現場の変電所で火事が発生し UPS に
切り替わったあとに避難命令がでたとき。。。
Re:商用DB (スコア:0)
＃ せいぜいゲーセンで火事になったときに停電直前までゲームをしていた程度なのでAC
Re:商用DB (スコア:4, 興味深い)
導入時期によりますが、それまで8.xで開発していて、導入直前に9iにversion upすることになり、担当者の頭の中がそのままで検証とドキュメントの修正がおろそかになった、というのが真相ではないですかねぇ。。。
Re:商用DB (スコア:4, 参考になる)
それはWindowsのサービス停止に対してOracleがどう処理するかのデフォルトの話ですね。
運用としてshutdown abortを叩き込むのがデフォルトというわけではありませんので
この仕様を基にして手順書を作る奴もいないでしょう。
運用については
> 「やはり、できればsql*plusで明示的にshutdownしましょうね（yasunorikakuさん）」おっしゃるとおりです。
と書いてあるとおりです。
Re:商用DB (スコア:0, 参考になる)
「Windowsのサービスを停止した場合、デフォルトでshutdown abort相当になる」
ということであって、
「8以前はデフォルトでshutdown abort運用推奨」
というわけではないと思うのですけど…
だから、旧バージョンの知識だったにせよ、
abortが手順に含まれていることは間違いだと思うのですが。
(なんだか「8以前はshutdown abort運用がデフォ」みたいな印象を受けたのでそれは違うんじゃないかと)
Re:商用DB (スコア:2, 興味深い)
Re:商用DB (スコア:2, おもしろおかしい)
いろんな現場を知っている人なら
かなり広く通常処理に使われているのを
見ているので、そのこと自体には大した驚きは無い。
Re:商用DB (スコア:1, すばらしい洞察)
正規の運用手順が Shutdown abort というのは問題だと思う。
でも、ハードウェア障害というのは普通に発生するので、
どんな状況で落ちてもDBMSとしては普通に対応できないとだめなんですよ。
Re:商用DB (スコア:0)
対処法があって簡単に復旧できたんじゃないのかな？そういう状況下では一時データに
問題が生じるのは当然な訳で。で、障害の原因がなかなかわからなかったようだけど、
通常の業務手順を踏んでいたのに、次回正しく起動しなかったので、すぐには原因が
突き止められなかったということなんでは？
Re:商用DB (スコア:0)
私も忘れたいんですけどね。
Re:商用DB (スコア:0)
Re:商用DB (スコア:1)
クラスタ構成組む時にコスト削減という名目でMicrosoft SQL使ってみたり、
パッケージソフトに標準で添付されているのでSybase使ったり、
簡単な物ならFilemakerで組んでみたり、
あ、15年前ならdBASE IIIで構築された社内用のソフトをメンテナンスしてたり、
てな感じでしたが。
んー (スコア:1, 興味深い)
世界的なＤＢのシェアを見た時
圧倒的だと思われるオラクルでトップなのは小規模に限ってであって
本当の大規模データベースでは、オラクルでさえその世界では
「マイナー」であるくらいしかシェアがなかったなぁ
トップの３は名前さえ知らないデータベースだったことに昔驚いておりました
今もそのシェアはかわらんらしいけど 名前忘れた。
メインフレーム (スコア:1, 興味深い)
IMS/DB(IBM)
ADABAS(Software AG)
AIM/DB(富士通), ADBS,RIQS(日電), XDM(日立)
RDB発明以前からのCODASYL型のDBだと、RDBへの移行に手間がかかるからそのままずっと使われ続けているというのもありますね。
Re:商用DB (スコア:0)
Re:商用DB (スコア:0)
履歴データと現在のデータを照合 (スコア:1)
そこに不備があったとあっさり認める日本オラクルはエライ。
ということは、銀行のオンラインシステムには使われていないということかな。
Re:履歴データと現在のデータを照合 (スコア:1, おもしろおかしい)
Re:履歴データと現在のデータを照合 (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
Re:履歴データと現在のデータを照合 (スコア:0)
この部分が読めないの？
Re:履歴データと現在のデータを照合 (スコア:0)
それが何れバレる可能性が高い事を考えると
仕方なく不備を認めただけだろ
＞ 銀行のオンラインシステムには使われていない
私の知る限り某金融機関でバリバリに使われていますが…
MySQLも商用版がありますね。(T/O) (スコア:0)
Oracleにbugがあるとして (スコア:1, 興味深い)
22日朝から23日午前4時までとめちゃだめなら、もうすこしいろんな障害を想定するような。
俺は実行計画が変わることが怖いから運用中のシステムの統計情報をとる前ってバックアップするけど。
#うちは復旧まで6時間って決められてるから、それに従ったリハーサルは何度もやってる（やらされてる）し、
#6時間でリストアできるように工夫させられてるよ。
Unbreakable (スコア:0)
まだ言ってたら恥ずかしいだろうな。
Re:Unbreakable (スコア:3, おもしろおかしい)
想像だけ（ややおふとぴ） (スコア:0)
それとも…
Re:想像だけ（ややおふとぴ） (スコア:1)
OTN掲示板はOracle擁護でいつもの光景ですね。
レベル的には (スコア:0)
って話だな。
Re:京都新聞のシステムが気になる (スコア:1, 興味深い)
少し昔に、京都新聞の紙面下部の広告が富士通で、その顧客例で京都新聞のシステムが
紹介されてた記憶がある。
京都新聞では昔から編集にOASYSやFM-Rが使われてた気がしますし、記事管理の大元を司ってた
のが富士通のメインフレームだった気がします。
さすがに現在はリプレースされてるでしょうから、メインフレームはどうなってるか不明ですが、今までの流れから富士通かなと。