パスワードを忘れた? アカウント作成
16397 story

神戸新聞のシステム障害はOracle9iのバグが原因 64

ストーリー by mhatta
Oracleはようわからん 部門より

あるAnonymous Coward 曰く、

神戸新聞の報道によれば、9月22日から23日にかけて同社の紙面製作システムに障害が発生し、 記事が製作不能になっていた件 (復旧の続報)の原因は、「Oracle9i Database」のバグにあったとのこと。
バグの内容だが、DB起動時に履歴データと現在のデータを照合して不一致がないかをチェックする部分にバグがあり、データを効率的に検索するために統計情報の採取処理をした後でデータベースのシステムを強制終了すると、履歴データと一致しないことが想定されるにもかかわらずプログラムはデータの不一致を障害と判断して、稀に起動できなくなるというものらしい。神戸新聞側の運用に問題は無かったとのこと。
日本オラクルによれば、今回のようなデータ不一致と、特定手順での終了から再起動にかけての一連の動作が同時に発生することは極めて稀で、これまで深刻なトラブルが発生した事例が世界でも報告されていなかったために、想定外の事例であったとしている。 当然、不具合を回避する手順も想定されていなかったために問題の切り分けに手間取ったようだ。
なおオラクルでは、修正プログラムを配布して対応するとしている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by snitch (10903) on 2007年10月02日 1時49分 (#1227582) 日記
    9/28にOracleのサポート情報に今回の障害に該当すると思われる情報がリリースされています。

    SHUTDOWN ABORT を含む強制終了後の次回インスタンス起動時に、ORA-600[kcratr1_lostwrt] が発生しデータベースがオープンできない [oracle.co.jp]

    #珍しく公開区分が「一般公開」になっていますね。
    #いつもだと、「契約顧客のみ」なのに・・・

    ITProによるとサーバ2重化していたけれども駄目だったようですね。
    【続報】神戸新聞の制作システムが回復、サーバー2重化もDBで障害 [nikkeibp.co.jp]
    システム本体はメインとバックアップを用意していたものの、DBを冗長化していなかったため全体が利用できなくなった。


    神戸新聞のシステム障害はオラクルDBの問題、修正プログラム配布へ:ITpro [nikkeibp.co.jp]

    なお、神戸新聞のシステムは業務終了時の処理としてデータベースを「強制終了(shutdown abort)」する仕様となっており、同社側に運用面での問題はなかったという。


    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]
  • by Anonymous Coward on 2007年10月01日 13時33分 (#1227251)
    著名なメーカー品なら心配無用というのは妄想であるという
    良い教訓になったでしょう。

    #昔は「完璧なソフトウェアなど存在しないのだから
    #テストを重ねて地雷を避けるのもSEの腕」と教わったけどな。
    #今って全般的にテスト工程が温いんじゃないか?
    • by Anonymous Coward on 2007年10月01日 21時47分 (#1227444)
      >著名なメーカー品なら心配無用というのは妄想であるという良い教訓になったでしょう。

      そういう妄想をしてくれていれば御の字
      トラブったときに「著名なメーカー品でそうなら仕方ないか」と責任回避できる
      という思考の人もいるんですよ

      # ええ、弊社とかに
      親コメント
  • 商用DB (スコア:1, 興味深い)

    by Anonymous Coward on 2007年10月01日 9時17分 (#1227023)
    事実上の標準つーか、唯一の選択肢というか、商用DBと言えば結局Oracleしかないんだよなあ、現状。

    DB屋さんは商用DBって他に何か使ってます?

    • Re:商用DB (スコア:2, 参考になる)

      by love-m4 (10412) on 2007年10月01日 9時21分 (#1227025) 日記
      HiRDBとか
      SQLserverとか
      Accessとか・・

      それよか、Shutdown abortってフツーの運用なの?
      親コメント
      • Re:商用DB (スコア:5, 興味深い)

        by Anonymous Coward on 2007年10月01日 9時35分 (#1227032)
        shutdown immediateならよくやるけど、自分で終わらせるときにはabortはさすがにやらないなぁ。
        ただ、業務用システムでwindowsをサーバとしたものなんかだと、システム停止手順がスタートメニューからシャットダウンってのもよく見かける。あれをやると次回起動時はリカバリから始める事になるわけで、oracleの障害復旧能力に依存したシステム設計ってことになるね。意外と多いんだ、これが。
        親コメント
        • Re:商用DB (スコア:2, 興味深い)

          by Anonymous Coward on 2007年10月01日 10時24分 (#1227068)
          oracleは使ったことはないけど、長いことWindowsアプリとして提供しているのだから
          スタートメニュー→シャットダウン 程度のことでリカバリーが発生するのは
          なんとなく不細工だなぁ。少なくとも常駐アプリなりサービスなり組み込んで
          きちんとoracleのシャットダウンができる様にしておかないと。>oracle
          その程度のアプリなんぞ作るのは大して手間じゃないだろうに。(特許除く)

          #中に組み込むのもそんなに手間じゃないけど、既稼働分との関係もあるから
          #外部アプリとしての話をしてみました。
          親コメント
          • Re:商用DB (スコア:1, すばらしい洞察)

            by Anonymous Coward on 2007年10月01日 11時07分 (#1227106)
            それはDBの仕事じゃなくて、DBを使用する側の仕事ですね。DB側としてはどこで落っこちても不整合が出ないようにリカバリはやりますが。システム終了に限らず、どこでロールバックをかけるか+はDB側では把握し切れません。
            まぁ、DBの規模にもよりますが、OSのshutdownが始まってからロールバックかけて終了処理をしてと、処理が終わらないうちにOS側のタイムアウトに引っかかってしまう気がするのでどの道だめっぽいですが。
            親コメント
            • by Anonymous Coward
              スタートボタンからシャットダウンするんじゃなくて、 DBをシャットダウンして完了後にOSもシャットダウンするスクリプトを作ればいいような気もしますが だめなんでしょうか。
              シャットダウンに時間がかかるような状態でabortしたら スタートアップにもっと時間がかかるような気がするし。
            • by Anonymous Coward
              そもそもOS自体がシャットダウン過程で、情け容赦なくサービスをKILLするのがおかしいんじゃなかろうか。
              • by Anonymous Coward
                サービスにお伺い立ててたら、いつまでも落とせない危険性が・・・
              • by Anonymous Coward
                Windowsがシャットダウンに入ればアプリに割り込みが発生しますし、そこでOSを待たせる処理も書けたと思ったけどな。
                気のせいだったかな?
              • by Anonymous Coward
                構成によってはシャットダウンに40分もかかるExchangeサーバーを「仕様」と言い切る [asahi-net.or.jp]ベンダーのOSがそんなタコな設計のわけねぇだろ。
              • by Anonymous Coward
                その場合OSはタコじゃないかもしれんが、ベンダーはタコだな。

                # ・・・この違いは大きいのか小さいのか・・・
                # フレームの元かもしれんのでAC
              • by Anonymous Coward
                お前、そんなアンチページの情報をソースに語るなよ…
              • by adeu (2937) on 2007年10月01日 14時55分 (#1227305)
                それは構成によるというよりシャットダウンの手順のせいじゃないかな。
                MicrosoftによるとWindowsのシャットダウンより前にExchange Serverのすべてのサービスを手で落とさないといけません。
                そういう意味での仕様で、少なくとも2003まではそうです。2007で改善されていればいいですが。
                だから電源の障害でUPSのバックアップ期間内に落とすにはExchange Serverサービス群をnet stopするスクリプトを書いておけばいい。
                親コメント
            • by Anonymous Coward
              影響を被るのは自分(oracle DB)のことなんだから
              他人任せでほったらかし、てのは、やはり米国製の大雑把さなんですかねぇ。
              国産アプリメーカーなら、主力級のDBあたりを商品として出していたなら
              スタートメニューの終了への対応位はすると思いますよ。
              • by Anonymous Coward
                「アプリ」って考えてるようじゃそもそも基幹向けDBなんて作れっこないね。
              • by Anonymous Coward
                いや、一つ前のコメントを書いてるのはユーザで、DBの作り手側じゃないから。
                ユーザにすりゃアプリであろうが無かろうがどっちでもいいよ、んなもん。(笑)
        • Re:商用DB (スコア:1, 興味深い)

          by Anonymous Coward on 2007年10月01日 22時39分 (#1227463)
          てゆうかさ、shutdown immediateしても全然immediateにshutdownされないんだよね。一晩放置してもまだ止まってないことあったよ。
          親コメント
        • by Anonymous Coward
          多いんだ。
          うちのはそうなってるんで、これはどうかと思ってたんだけど
          特殊な例ではないということか。
      • Re:商用DB (スコア:5, 興味深い)

        by CowardDuck (25674) on 2007年10月01日 9時40分 (#1227036)
        > それよか、Shutdown abortってフツーの運用なの?

        一回だけ必要に駆られて Shutdown abort したときがある。

        それは当時の開発現場の変電所で火事が発生し UPS に
        切り替わったあとに避難命令がでたとき。。。
        親コメント
        • by Anonymous Coward
          そんな状況でもちゃんと仕事をしているあなたに敬意を覚えます。

          # せいぜいゲーセンで火事になったときに停電直前までゲームをしていた程度なのでAC
      • Re:商用DB (スコア:4, 興味深い)

        by sasasa (5925) on 2007年10月01日 12時04分 (#1227167) ホームページ
        Oracle8まではshutdown abortデフォルトだった [oracle.co.jp]らしいので、Nの担当者の方が8までの知識を元に手順書を書いていたのではないかと。

        導入時期によりますが、それまで8.xで開発していて、導入直前に9iにversion upすることになり、担当者の頭の中がそのままで検証とドキュメントの修正がおろそかになった、というのが真相ではないですかねぇ。。。

        親コメント
        • Re:商用DB (スコア:4, 参考になる)

          by Anonymous Coward on 2007年10月01日 14時31分 (#1227288)
          > Oracle8まではshutdown abortデフォルトだったらしいので、Nの担当者の方が8までの知識を元に手順書を書いていたのではないかと。

          それはWindowsのサービス停止に対してOracleがどう処理するかのデフォルトの話ですね。
          運用としてshutdown abortを叩き込むのがデフォルトというわけではありませんので
          この仕様を基にして手順書を作る奴もいないでしょう。

          運用については

          > 「やはり、できればsql*plusで明示的にshutdownしましょうね(yasunorikakuさん)」おっしゃるとおりです。

          と書いてあるとおりです。
          親コメント
        • Re:商用DB (スコア:0, 参考になる)

          by Anonymous Coward
          このリンク先の「デフォルト」ってのは、
           「Windowsのサービスを停止した場合、デフォルトでshutdown abort相当になる」
          ということであって、
           「8以前はデフォルトでshutdown abort運用推奨」
          というわけではないと思うのですけど…

          だから、旧バージョンの知識だったにせよ、
          abortが手順に含まれていることは間違いだと思うのですが。
          (なんだか「8以前はshutdown abort運用がデフォ」みたいな印象を受けたのでそれは違うんじゃないかと)
      • Re:商用DB (スコア:2, 興味深い)

        by Anonymous Coward on 2007年10月01日 10時19分 (#1227065)
        このニュースは、バグの内容より、shutdown abortが通常業務に 利用されていたってことの方がインパクトがあるよな。
        親コメント
        • Re:商用DB (スコア:2, おもしろおかしい)

          by Anonymous Coward on 2007年10月01日 10時57分 (#1227097)
          たしかにインパクトはあるんですが、
          いろんな現場を知っている人なら
          かなり広く通常処理に使われているのを
          見ているので、そのこと自体には大した驚きは無い。

          親コメント
      • Re:商用DB (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2007年10月01日 10時39分 (#1227082)
        >それよか、Shutdown abortってフツーの運用なの?

        正規の運用手順が Shutdown abort というのは問題だと思う。
        でも、ハードウェア障害というのは普通に発生するので、
        どんな状況で落ちてもDBMSとしては普通に対応できないとだめなんですよ。
        親コメント
        • by Anonymous Coward
          正論だけどさ、今回の件は、なんらかの事故が起きて落ちた(落とした)のなら、適切な
          対処法があって簡単に復旧できたんじゃないのかな?そういう状況下では一時データに
          問題が生じるのは当然な訳で。で、障害の原因がなかなかわからなかったようだけど、
          通常の業務手順を踏んでいたのに、次回正しく起動しなかったので、すぐには原因が
          突き止められなかったということなんでは?
      • by Anonymous Coward
        HiRDBを出したのなら、たまにでいいので Symfowareのことも思い出してあげてください。

        私も忘れたいんですけどね。
      • by Anonymous Coward
        DB2を使っているところもあるんですはい。
    • by FireStorm (7429) on 2007年10月01日 9時31分 (#1227028)
      DB屋じゃありませんが、

      クラスタ構成組む時にコスト削減という名目でMicrosoft SQL使ってみたり、
      パッケージソフトに標準で添付されているのでSybase使ったり、
      簡単な物ならFilemakerで組んでみたり、
      あ、15年前ならdBASE IIIで構築された社内用のソフトをメンテナンスしてたり、

      てな感じでしたが。
      親コメント
    • んー (スコア:1, 興味深い)

      by Anonymous Coward on 2007年10月01日 13時28分 (#1227245)
      大規模データベース=オラクルと思われがちだけど

      世界的なDBのシェアを見た時
      圧倒的だと思われるオラクルでトップなのは小規模に限ってであって
      本当の大規模データベースでは、オラクルでさえその世界では
      「マイナー」であるくらいしかシェアがなかったなぁ
      トップの3は名前さえ知らないデータベースだったことに昔驚いておりました

      今もそのシェアはかわらんらしいけど 名前忘れた。
      親コメント
      • by Anonymous Coward on 2007年10月01日 15時50分 (#1227332)
        汎用機のDBだと、RDBじゃないけどこんなところかなあ
        IMS/DB(IBM)
        ADABAS(Software AG)
        AIM/DB(富士通), ADBS,RIQS(日電), XDM(日立)

        RDB発明以前からのCODASYL型のDBだと、RDBへの移行に手間がかかるからそのままずっと使われ続けているというのもありますね。
        親コメント
    • by Anonymous Coward
      AS/400(System i) 好きだし楽なんだが、対応してるソリューションが絶対的に少ない。 あと、これをちゃんと判ってくれてるSI屋さん。
    • by Anonymous Coward
      医療系だとIntersystems社のCacheとか。
  • する処理は、最も重要な処理だ。
    そこに不備があったとあっさり認める日本オラクルはエライ。
    ということは、銀行のオンラインシステムには使われていないということかな。
  • by Anonymous Coward on 2007年10月01日 13時51分 (#1227263)
    そんな大事になる運用しか想定してないって少し甘いんじゃないかなあ。
    22日朝から23日午前4時までとめちゃだめなら、もうすこしいろんな障害を想定するような。

    俺は実行計画が変わることが怖いから運用中のシステムの統計情報をとる前ってバックアップするけど。

    #うちは復旧まで6時間って決められてるから、それに従ったリハーサルは何度もやってる(やらされてる)し、
    #6時間でリストアできるように工夫させられてるよ。
  • by Anonymous Coward on 2007年10月01日 10時20分 (#1227066)
    Unbreakable ってまだ言ってる?
    まだ言ってたら恥ずかしいだろうな。
    • Re:Unbreakable (スコア:3, おもしろおかしい)

      by Anonymous Coward on 2007年10月01日 11時07分 (#1227105)
      大丈夫です。言い出したときからすでに恥ずかしかったのでいまさら何が起きても怖くありません。
      親コメント
  • by Anonymous Coward on 2007年10月01日 11時18分 (#1227115)
    やっぱり出たエラーメッセージって、ORA-00600: internal error code, arguments: hogehogehogehogeだったのかな?
    それとも…
  • by Anonymous Coward on 2007年10月01日 13時50分 (#1227261)
    「コンセントをいきなり抜いても大丈夫だと思ってた」
    って話だな。
typodupeerror

アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家

読み込み中...