Raidディスクアレイデータ復旧-データベース修復プロセス


お客様のDS 5020ファイバストレージに障害が発生し、データが失われました.このストレージは16個のハードディスクを使用してraidディスクアレイを構成しています.10番台と13番台はオフラインで、6番台はデータ復旧が必要だと警告した.Raidディスクアレイの障害:IBM storage managerによって現在格納されている完全なログ状態をバックアップし、バックアップされたストレージログを解析して論理ボリューム構造に関する一部の情報を得た.クライアントサーバ内のすべてのディスクを一定の順序でスロットから削除してテストしたところ、6番ディスクsmartのステータスが「警告」の場合を除き、ディスクアレイ内の他のハードディスクが正常であることがわかりました.ディスクアレイデータ復旧プロセス:エンジニアはまずwindows環境の下でraidアレイの中の正常なハードディスクをオフラインとマークし、それからすべてのディスクの記憶性を全面的に操作し、バックアップの過程で6番のハードディスクの速度が異常に遅いことを発見した.同時に、デバイス内で不良応答、待機時間、および不良セクタデータのスキップを調整します.
ミラーリング操作後、windowsプラットフォームの下でwinhexミラーリングを使用するディスクはすべてミラーリングが完了し、winhex生成のログを表示し、IBM storage manager/frombyteで発見した.comとハードディスクSMARTの状態の中ですべて間違いを報告していない1番のディスクも悪道が存在して、10番と13番のディスクはすべて大量の不規則な悪道の分布が存在して、悪道のリストによって目標の鏡像のファイルの分析に位置してこのディスクのアレイの中でファイルシステムの一部の肝心なデータが悪道区にあることを発見して、6番のハードディスクの同じバンドxorを通じて手動で修復することに回転します.バックアップしたraidのすべてのデータをデータリカバリソフトウェアを用いて展開し、ext 3ファイルシステムの逆方向およびログファイルを整理分析し、raidディスクアレイのディスクシーケンス、raidブロックサイズ、raidの検証方向および検証方式などの必要な情報を分析した.解析されたraid情報によりraidディスクアレイを仮想的に再編成し、ext 3ファイルシステムを取り外してデータベースファイルを抽出します.データベースファイルの抽出中にエラーが発生し、データベースはimp-0008エラーを報告し、データ復旧エンジニアはraid構造を再分析し、再びdmpファイルとdbf元のライブラリファイルを抽出し、すべてのファイルは正常にエラーを報告しなかった.データベースデータ復旧プロセス1.データベースファイルを元のデータベースサーバにコピーします.パスは/home/oracle/tmp/syntongです.バックアップとして使用します.ルートディレクトリの下にoradataフォルダを作成し、バックアップしたsyntongフォルダ全体をoradataディレクトリにコピーします.次にoradataフォルダとそのすべてのファイルのグループと権限を変更します.2.元のデータベース環境をバックアップし、ORACLE_を含むHOME下productフォルダ下の関連ファイル.元のマシンのsplplusを使用してデータベースに接続するリスニングを構成します.nomountステータスにデータベースを起動してみます.基本状態クエリーを行うと、環境とパラメータファイルに問題がないことがわかります.データベースをmountステータスに起動してみます.ステータスクエリに問題はありません.オープン状態にデータベースを起動します.エラー:
ORA-01122: database file 1 failed verification check/frombyte.com
ORA-01110: data file 1: '/oradata/syntong/system01.dbf'
ORA-01207: file is more recent than control file - old control file

3.更なる検査と分析を経て、この故障は制御ファイルとデータファイルの情報が一致しないと判断し、これは停電や突然のシャットダウンなどによるよくある故障である.4.データベースファイルを個々に検出し、すべてのデータファイルが物理的に破損していないことを検出します.5.mount状態で制御ファイルをバックアップし、alter database backup controlfile to trace as'/backup/controlfile';バックアップした制御ファイルを表示変更し、その中の再構築制御ファイルコマンドを取得します.これらのコマンドを新しいスクリプトファイルcontrolfileにコピーします.sqlで.6.データベースを閉じ、/oradata/synton g/の3つの制御ファイルを削除します.データベースをnomount状態に起動し、controlfileを実行する.sqlスクリプト.
SQL>startup nomount/frombyte.com
SQL>@controlfile.sql

7.制御ファイルの再構築が完了したら、直接データベースを起動し、エラーを報告し、さらに処理する必要がある.
SQL> alter database open;
alter database open/frombyte.com
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/free/oracle/oradata/orcl/system01.dbf'

次に、リカバリコマンドを実行します.
recover database using backup controlfile until cancel;
Recovery of Online Redo Log: Thread 1 Group 1 Seq 22 Reading mem 0
Mem# 0 errs 0: /free/oracle/oradata/orcl/redo01.log
…

レポートに戻るまでメディアリカバリを行い、リカバリが完了します.8.オープンデータベースを試します.SQL> alter database open resetlogs;9.データベースの起動に成功しました.元のtempテーブルスペースのデータファイルを対応するtempテーブルスペースに追加します.10.データベースの全般的なチェックを行い、エラーはありません.11.empバックアップを行います.フルライブラリバックアップが完了し、エラーは発生しませんでした.アプリケーションをデータベースに接続し、アプリケーションレベルのデータ検証を行います.