パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

神戸新聞のシステム障害はOracle9iのバグが原因」記事へのコメント

  • 商用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
                #1227227 の記事はどうみても皮肉です。
                ありがとうございました。
            • 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
            そういう時は、セッションを探して個別に担当部署に問い合わせて消していくもんだと…。
        • 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
        海外のシステムでは多いのでしょうか?

        医療情報システムのヤクザコンサルをしていますが出会ったことがありません。

        #個人的には Oracle なんてふざけた名前を名乗る DB を使いたくない

物事のやり方は一つではない -- Perlな人

処理中...