-
1. 回復の意味
データベースを使用するとき、データベースの内容が信頼でき、正確であることを常に望みますが、コンピュータ システムの障害 (ハードウェア障害、ネットワーク障害、プロセス障害、システム障害) はデータベース システムの動作と精度に影響を与えます。データベース内のデータを性的に破壊し、データベース内のデータのすべてまたは一部が失われることもあります。したがって、上記の障害が発生した場合、完全なデータベースを再構築できることが期待されます。このプロセスはデータベースの回復と呼ばれます。回復サブシステムはデータベース管理システムの重要な部分です。発生した障害の種類によって影響を受ける構成によって復旧処理が異なります。
2. 回復方法
インポート方法:
IMPORT を使用して、新しいデータベースにエクスポートされた最後のデータ ファイルをインポートします。この方法では、データベース オブジェクトをエクスポート時の状態に復元でき、その後の変更は元に戻せません。 IMPORT コマンドは対話的に実行できます。各パラメータの具体的な意味については、ORACLE EXP/IMP パラメータの詳細な説明を参照してください。この方法は、アーカイブ モードを使用しない環境に適しています。
安全な回復方法:
データベースがアーカイブ モードで実行されている場合、データベースが損傷しても、コールド バックアップ (ホット バックアップ) とアーカイブ バックアップを通じてデータベースをブレークポイントの状態に復元できます。
データベース制御ファイルの回復 (すべての制御ファイルが破壊されたと仮定):
データベースはファイル システムに基づいています。オペレーティング システムの tar、cp、およびその他のコマンドを使用するだけです。
データベースは raw デバイスに基づいています: dd if=$ORACLE_BASE/con.bak of=/dev/rdrd/drd1 seen=12
データベースデータファイルのリカバリ
データおよびインデックス表スペースとシステム表スペースのリカバリ:
関連するデータベース ファイルと、データ ファイルのバックアップ以降に生成されたすべての論理ログ ファイルをコピーして戻し、次のコマンドを実行します。
svrmgrl > 起動マウント
svrmgrl > データベースの自動回復の変更
制御ファイルが破損している場合は、次の手順を実行します。 svrmgrl > alter database copy using back up controfile; プロンプトに従って、ログ ファイル名と redolog ファイル名を入力します。
svrmgrl > データベースオープンリセットログを変更します。
データベース一時ファイルとロールバック表スペースのリカバリ: オフラインにドロップして再構築するだけです。
注: データベースがアーカイブ モードで実行されていない場合、リカバリでは最後のバックアップの状態にのみ復元できます。 アーカイブ モード設定とバックアップ関連テクノロジについては、「ORACLE データベース バックアップ テクノロジ」を参照してください。
3. ORACLE テーブルスペース回復ソリューション
(1) 家庭用テーブルスペースエラー現象：
データベースの起動時に ORA-01157、ORA-01110 またはオペレーティング システム レベルのエラーが発生する
データベースをシャットダウンするとき（通常のシャットダウンまたは即時シャットダウンを使用）、ORA-07360 などのエラーが発生すると、エラー ORA-01116、ORA-01110 およびオペレーティング システム レベルのエラー ORA-07368 が発生します。
解決する：
以下の 2 つの解決策があります。
解決策 1: ユーザーの表スペースは簡単に再構築できます。つまり、最近エクスポートされたオブジェクトが使用可能になったり、表スペース内のオブジェクトが簡単に再構築されたりすることができます。この場合、最も簡単な方法は、オフラインにしてデータ ファイルを削除し、表領域を削除して、表領域とすべてのオブジェクトを再構築することです。
svrmgrl> 起動マウント
svrmgrl> データベース データファイル ファイル名を変更し、オフライン ドロップします。
svrmgrl> データベースオープンを変更します。
svrmgrl> 内容を含むテーブルスペース tablespace_name を削除します。
テーブルスペースとすべてのオブジェクトを再構築します。
解決策 2: ユーザーの表スペースを簡単に再構築することは不可能であり、システムが NOARCHIVELOG モードで実行されている場合にのみ、バックアップを元に戻してメディア・リカバリーを実行する必要があります。失われたデータはオンライン REDO ログで復元できます。
手順は次のとおりです。
1)失われたデータファイルをバックアップから復元します
2)svrmgrl> 起動マウント
3)svrmgrl> v$log v1,v$logfile v2 から v1.group#,member,sequence#,first_change# を選択します (v1.group#=v2.group#;)。
4) データベースが NOARCHIVELOG モードで実行されている場合: svrmgrl> select file#,change# from v$recover_file;
CHANGE# が最小 FIRST_CHANGE# より大きい場合、データ ファイルを復元できます。
CHANGE# が最小 FIRST_CHANGE# より小さい場合、データ ファイルは回復できません。最新の完全バックアップを復元するか、オプション 1 を使用します。
5)svrmgrl> データファイルのファイル名を回復します。
6) リカバリが成功したことを確認します
7)svrmgrl> データベースオープンリセットログを変更します。
読み取り専用テーブルスペースの場合はメディアリカバリを実行する必要はなく、バックアップを復元するだけです。唯一の例外は次のとおりです。
最後のバックアップ後に表スペースが読み取り/書き込みモードに変更されました。この場合、メディアのリカバリが必要です。
(2) 一時表スペース 一時表スペースには実データは含まれません。回復方法は、一時表スペースを削除して再構築することです。
(3) システムテーブルスペースのバックアップが利用できない場合、唯一の方法はデータベースを再構築することです。
(4) テーブルスペースをロールバックするには、次の 2 つの状況があります。
1. データベースが完全にシャットダウンされました (即時シャットダウンまたはシャットダウン コマンドを使用)
1) データベースが完全に閉じられていることを確認します。
2) init.ora ファイルを変更し、「rollback-segment」にコメントを付けます。
3) svrmgrl> 起動制限マウント
4) svrmgrl> データベース データファイル ファイル名を変更し、オフライン ドロップします。
5) svrmgrl> データベースオープンを変更します。
表示される結果に基づいて、「ステートメントが処理されました」は (7) に進み、「ORA-00604,ORA-00376,ORA-01110」は (6) に進みます。
6) svrmgrl> 即時シャットダウン
init.ora ファイルを変更し、次の行を追加します: _corrupted_rollback_segments = (<roll1>,...<rolln>)
svrmgrl> 起動制限
7) svrmgrl> 内容を含むテーブルスペース tablespace_name を削除します。
8) テーブルスペースを再構築し、セグメントをロールバックします。
9) svrmgrl> alter system は制限されたセッションを無効にします。
10) init.ora ファイルを変更します。
2. データベースが完全に閉じられていません (データベースがクラッシュするか、データベースを閉じるために shutdown abort コマンドが使用されます)。
1) バックアップを復元する
2) svrmgrl> 起動マウント
3) svrmgrl> v$datafile からファイル番号、名前、ステータスを選択します。
svrmgrl> データベース データファイル ファイル名をオンラインで変更します。
4) svrmgrl> select v1.group#,member,sequence#,first_change# from v$log v1,v$logfile v2 ここで、v1.group#=v2.group#;
5) svrmgrl> select file#,change# from v$recover_file #解決策 2-4 を参照してください。
6) svrmgrl> データファイルのファイル名を回復します。
7) svrmgrl> データベースオープンを変更します。
3. データベースが開いています
1) ロールバックセグメントとテーブルスペースを削除します。
2) 表スペースの再構築とセグメントのロールバック (5)、制御ファイルのリカバリ
1.すべての制御ファイルが破棄されます。RAW DEVICE (裸のデバイス) の場合は、dd if='/dev/rdrd/drd1' シーク=128 にコピーします。
2.すべての制御ファイルが破壊されるわけではありません。他の制御ファイルを使用してデータベースを起動し (6)、データ ブロックとその中のデータを保存します。 現象: ORACLE 操作の実行時に ORA-01578 エラーが発生します。データ ブロックが破損している可能性があり、次の理由で発生する可能性があると考えられます。
I/O ハードウェアまたはファームウェアの損傷 オペレーティング システムの I/O またはキャッシュの障害 メモリまたはページ スワップ エラー データ ファイルの一部が上書きされている 未フォーマットのブロック ディスクにアクセスしようとしている 修復 その他の原因 解決策の手順:
ログ ファイルとトレース ファイルをチェックして、他のエラーや位置エラーがないかどうかを確認します。
sql>select * from v$datafile where file#=<F>;
sql>select owner,segment_name,segment_type from dba_extents where file_id=<F> and <B> block_id と block_id+blocks-1;
返されたsegment_typeに基づいて、次のようになります。
セグメントタイプが一時またはキャッシュであるか、戻り値がありません。SQL ステートメントが正しいかどうかを確認してください。
セグメントタイプがロールバックセグメントの場合、データブロックを復元する必要があります。
セグメント タイプはインデックスです。セグメント タイプが配置されているテーブルを確認してください。インデックスを再構築するだけです。
sql> select owner,table_name from dba_tables ここで、cluster_name = name_of_segment
エラー 1578 が引き続き発生するため、データベースを復元する必要があります。
セグメントタイプはテーブルであり、データはテーブルに保存されます。
エンティティに永続的なデータ破損があるかどうかを分析する
sql> テーブル table.name を分析し、構造カスケードを検証します。
sql> テーブル クラスター名を分析し、構造カスケードを検証します。
ARCHIVE モードで実行されているハードウェア エラー回復データベース
OFFLINE対応データファイルコピーバックアップデータファイル
データファイルの名前を新しい場所に変更します
アーカイブログを使用してデータファイルをリカバリする
オンライン データ ファイル データベースは非アーカイブ モードで実行されています
OFFLINE対応するデータ ファイルがバックアップされたデータ ファイルをコピーし、データファイルの名前を変更してオンラインにします。
テーブルにデータを保存します。例: sql>select * from bigemp;
エラー: ORA-01578: ORACLE DATA ブロックが破損しています (file#8、block#8147) ORA-00110: データ ファイル 8: '/oracle/usr714.dbf' … … 破損したファイル ID : 8=8(hex) 破損したブロック ID : 8147=1fd3(hex) 破損したブロックの最初の ROWID: 0000.1fd3.0000.0008 破損したブロックの最後の ROWID: 0000.1fd2.7fff.0008 このブロックの後の最初の ROWID: 0000.1fd4.0000.0008
SQL > create table temp as select * from bigemp where 1=2;
sql > insert into temp select * from bigemp /*+rowid(bigemp) */ where rowid >='0000.1fd4.0000.0008';
sql > insert into temp select * from bigemp where rowid <='0000.1fd2.7fff.0008';
ORACLE 7.1 より前のバージョンでは、ROWID 範囲スキャンが存在しない場合、インデックス作成によって上記と同じ目的を達成できます。
4. 追記
ORACLE のバックアップとリカバリのテクノロジは広範囲にわたって奥深いと言えますが、私はそのほんの一部しか知りません。これらの記事が皆さんのバックアップに関する経験を共有していただければ幸いです。問題を教えてください。興味のあるすべての DBA 友人やデータ管理者の参考のためにここに公開します。あなたの小さな努力が会社を救うかもしれません。
同時に、友人全員に、バックアップは非常に、非常に、非常に、非常に、非常に、非常に、非常に、非常に重要であることを思い出させたいと思います。 。 。重要なのは、可能であれば ARCHIVE モードを使用する必要があります。そうしないと、何か問題が発生して泣くこともできなくなります。