私のチームと私は、この問題の答えを見つけようと頑張ってグーグルで検索しました(そしてBinged!)ので、SFのオラクルの達人が答えを知っていることを願っています。
1週間前、サーバーをホストしている建物で停電が発生しました。データベースのエクスポートの途中でサーバー全体がダウンしました。サーバーをオンラインに戻すと、データベースインスタンスで狂ったように機能する新しいプロセスSMONに気づきました。これは、OEMの「トップアクティビティ」のスクリーンショットです。
Oracle Enterprise Manager http://www.myviewstate.net/images/oem.png
しばらく手放しましたが、1日後には心配になりました。ログを確認したところ、無限ループになっているように見えました。ログファイルの一部は次のとおりです。
Fri Aug 14 14:43:58 2009
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
これまでに行った手順は次のとおりです(ほとんどはオンラインで見つけたもののために試しました)が、どれもうまくいきませんでした。
私は開発者であり、DBAとしての経験はもちろん、Oracleの経験もほとんどないことを忘れないでください。
助言がありますか?
Oracle 9i以降では、特別なUNDO表領域とREDOログを使用してトランザクションを管理します。
REDOは実行されたステートメントのログを保存し、UNDOはそれらのステートメントの影響を受けるデータベースブロックのイメージの前後を保存します。
もう少し掘り下げました... Oracle Metalink(サポートサイト)にアクセスできる場合は、バグID3418428を調べてください。これは問題のようです。オラクルのサポート契約に違反していると思われるため、ここで情報を複製することはできません。
この問題の一般的な要点は、自動Undo管理がオンデマンドでUNDO表領域にROLLBACKセグメントを動的に作成することです。作成されるセグメントの数とサイズは、データベースの負荷によって異なります。
データベースがクラッシュする前に、データベースはデフォルト数を超えるROLLBACKセグメントを作成してオンラインにしました。
クラッシュ後、データベースはクラッシュ前に持っていたすべてのROLLBACKセグメントをオンラインにしませんでした。
十分な時間を与えれば、10gはこれから回復できるかもしれないと思います。 9iにはもっと問題がありました。データベースは接続と応答に対してオープンですか?
それを超えて、Oracleリカバリの暗い世界に入る可能性があります。リカバリを試みるときにOracleを完全に混乱させるのは簡単なので、助けを求めることをお勧めします。
データベースが回復を実行し、元に戻すセグメントをオンラインに戻してデータベースを回復しようとするときに、データベースがループしています。あなたはdbaではないので、私はすぐにOracleのサポートを受けて、大きな支援が必要であり、dbaではないことを伝えます。データベースを起動し、元に戻すセグメントをクリーンアップしようとしているsmonループがあるリカバリマネージャを無効にする可能性が非常に高くなります。過去に元に戻すセグメントのクリーンアップを実行する必要があったため、Oracleサポートのヘルプを使用して実行するのが最適です。手順の多くには、非表示のOraclemojoを無効/有効にするいくつかのイベントとアンダースコアパラメータが必要です。私はあなたが自分で見つけたものや投稿されたものを、その意味とおそらくあなたの試みから回復/取り消す方法を理解せずに試みることをお勧めしません。目的は、データベースを回復することであり、データベースを悪化させることではありません。できるだけ早く電話でOracleサポートを利用してください。
これがOracleのバージョンについては言及していません...この症状(821743.1)で10.2.0.4のMetalinkに問題があります。システムは分散トランザクションを実行しますか? 「スタック」しているコミットされていない2フェーズコミットトランザクションが存在する可能性があります。ビューdba_2pc_pendingをクエリします。
dba_2pc_pendingからlocal_tran_id、global_tran_id、stateを選択します。
消えないレコードがある場合は、それらに強制的にロールバックする必要があります。この領域では非常に注意してください... @ Geoffからのアドバイスは良いです、Oracleサポートはおそらくここで相談されるべきです、それはあなたが支払っているものです。クラッシュ後のこの症状は、データベースの破損を示している可能性があります。まれですが、可能です。オラクルは「腐敗防止」であるはずですが、最善の計画とそのすべてが……。
ロールフォワード/オープン/ロールバックワードについて説明します ここ
大まかに言って、REDOログはデータベースに変更をプッシュして適用されます。その最後に、適用されたがコミットで終了しなかった変更は、ロールバックする必要があります。 UNDOを読み取り、変更を元に戻します。
元に戻すがヒットしている場合は、ロールバックする必要のあるコミットされていない変更があったことを意味します。それはエクスポートではなかったでしょう(それは純粋な選択でなければならないので)。 v $ transactionのUSED_URECを見てください。コミットされていない変更を削除するために元に戻すレコードが適用されるときに(うまくいけば)下がるゼロ以外の値を持つ1つの行(おそらくそれ以上)があるはずです。
私はOracleの管理者でも開発者でもありませんが、「smon Oracle」をグーグルで検索すると、プロセスとは何か、DBがCPU使用率を上げるために電力を消費した後の処理内容がわかりました。引っ張られた力によるダメージが修正されるまで、このように続きます。疑わしい場合は、Oracleでチケットを開いてください。結局のところ、サポートには多額の費用がかかります。