Oracleのデータを復元する - ＠WIKI

障害タイプ

文障害
　SQL文としては正しいけれども、Oracleサーバのルールに基づき、実行エラーとなってしまうことです。
　次のような問題と解決方法があります。

問題	解決方法
無効なデータ	制約違反、データ型の不一致、データ最大長の超過などが原因です。データを検証し、修正します。
権限不足エラー	適切なオブジェクト権限、システム権限を付与します。
領域不足エラー	表領域の空き領域不足、エクステントの拡張エラー、領域割り当て制限（QUOTA）超過が原因です。必要な領域を追加します。また、再開可能領域割り当て機能を使用することで、領域不足時に処理を一時停止させ、解消時に再開させることも可能です。

ユーザープロセス障害
　ユーザープロセスが異常終了してしまうことです。
　クライアント側のリソース不足によるプロセスの終了、Oracleサーバとのネットワークの切断によるセッションの終了などが考えられます。
　ユーザープロセス障害の解決は、Oracleサーバ側のサーバプロセスのクリーンアップで対応します。
　サーバプロセスのクリーンアップは、PMONバックグラウンドプロセスにより自動的に行われるため、データベース管理者による特別なアクションは必要ありま　せん。
　PMONバックグラウンドプロセスは、トランザクションをロールバックし、ロックを解放します。

ユーザーエラー
　ユーザーが誤ったトランザクションをCOMMITしたり、誤ってテーブルを削除、切り捨ててしまったりすることです。
　SQL文としては正しいため、 Oracleサーバは渡されたSQL文を正しく実行します。
　その結果、必要なテーブルが削除されたことにより、システムとしては問題のある状態になってしまいます。
　ユーザーエラーの解決は、操作を行う前の状態にすることで図れます。
　フラッシュバックテーブル、フラッシュバックドロップ、フラッシュバックデータベースといったフラッシュバックリカバリ機能か、データファイルのバックアップを　　使用して、過去の一時点までのリカバリ（Point-in-timeリカバリ）を行います。
　誤った操作が行われた時間を識別するために、LogMinerユーティリティが使用できます。
　LogMinerでは、REDOログファイルから、実行されたSQL文、実行したユーザー、実行した時間などを確認することができます。

インスタンス障害（インスタンス・リカバリ）
　バックグラウンドプロセスが異常終了したり、データベースファイル以外のハードディスク障害が発生したり、強制終了（SHUTDOWN ABORTを含む）したりすることです。
　インスタンス障害の解決は、インスタンスを再起動することで図れます。
　Oracleサーバは、インスタンス障害が発生した後のインスタンス起動時に、自動的にインスタンスのリカバリを行います。
　インスタンスのリカバリでは、REDOログファイルを再度適用するロールフォワード、COMMITされていないトランザクションを取り消すロールバックが行われます。

メディア障害（メディア・リカバリ）
　データベースファイルが損失したり、ディスクが破損したり、ディスクコントローラが破損したりすることです。
　メディア障害の解決には、バックアップファイルのリストアと、REDOログ（アーカイブログを含む）を適用するリカバリ操作が必要です。

データベースのバックアップ

NOARCHIVELOGモードとARCHIVELOGモード（一貫性バックアップと非一貫性バックアップ）

Oracleデータベースは、

• NOARCHIVELOGモード≒一貫性バックアップ（完全バックアップ）
• ARCHIVELOGモード≒非一貫性バックアップ（部分バックアップ）

のいずれかで運用できます。

NOARCHIVELOGモード	ARCHIVELOGモード
バックアップ時、データベースを停止する必要がある	バックアップ時、データベースがオープンしていてもよい
データファイルにREDOログファイル内のすべての変更が適用済み	データファイルに適用されていない変更が REDOログファイル、アーカイブログファイルに含まれる
同じタイミングで取得したデータベース全体のバックアップが必要	個々のデータファイル、表領域単位で取得したバックアップでよい
データファイルに障害が発生した場合、 バックアップ全体をリストア（復元）する必要がある	データファイルに障害が発生した場合、 障害が発生したファイルのみリストア（復元）すればよい
リストア（復元）操作直後にデータベースをオープンできる	リストア（復元）操作後、リカバリ操作を行う必要がある
アーカイブログファイルを適用するリカバリができない。 アーカイブログファイルの管理は不要	アーカイブログファイルを適用するリカバリができる。 アーカイブログファイルを失うとリカバリできなくなるため、適切な管理が必要
一貫性バックアップのみ有効です。	一貫性バックアップと非一貫性バックアップの両方を使用することができます。

完全リカバリとPoint-in-Timeリカバリ

メディアリカバリの基本的な流れはREDOログレコードを適用するロールフォワードとUNDOデータを適用するロールバックで構成されます。

ロールフォワードによって変更が適用されると、COMMITされたデータだけでなく、COMMITされていないデータも適用されてしまいます。
そのため、ロールフォワード中にUNDOデータを再構築し、UNDOデータを使用してCOMMITされていないものをロールバックします。

リカバリ（回復）には、

• 完全リカバリ
• Point-in-Time（不完全）リカバリ

があります。
ARCHIVELOGモードでは、完全リカバリとPoint-in-Timeリカバリを使用できます。

完全リカバリ	Point-in-Time（不完全リカバリ）
アーカイブログファイルとREDOログファイルに含まれるすべての変更を適用する	データファイルをバックアップした後の任意の時点までのアーカイブログファイル、REDOログファイルに含まれる変更を適用する
障害発生直前のCOMMITされた状態に回復する	指定した時点の状態に回復する

※過去の一時点を対象とした不完全リカバリについては、ORACLE MASTER Silverの範囲ではありません。

NOARCHIVELOGモードでは、一貫性バックアップをすべてリストア（復元）のみで、リカバリ（回復）は、おこないません。

ARCHIVELOG モードへの変更は、
Database Controlでは「メンテナンス」タブ→「バックアップ／リカバリ」リージョンの
「リカバリ設定の構成」
リンクから行えます。
アーカイブログファイルの保存先はデフォルトではフラッシュリカバリ領域になっていますが、最大10カ所を指定できます

コマンドラインからARCHIVELOGモードに変更する手順は次のとおりです。
1．データベースを停止する
2．データベースをMOUNTする
3．ALTER DATABASE ARCHIVELOGコマンドの実行
4．データベースをOPENする

• フラッシュリカバリ領域

　フラッシュリカバリ領域は、バックアップファイルやアーカイブログファイルを格納する場所です。
　 Database Controlでは、「メンテナンス」タブ→「バックアップ／リカバリ」リージョンの「リカバリ設定の構成」リンクから構成できます

フラッシュバックドロップとフラッシュバックテーブル

Oracleデータベースでは、次のようなフラッシュバック操作が提供され、過去の特定の時点に戻ることが可能です。

フラッシュバック問い合わせ	ある時間を指定して問い合わせを実行し、その時点で表示されるはずの問い合わせ結果を表示する
行履歴フラッシュバック	指定した2つの時点の間で生成されたすべてのバージョンのデータを表示
トランザクション履歴フラッシュバック	トランザクションによって行われた変更を戻すためのSQL文を表示する
フラッシュバックテーブル	表を指定した時点の状態に戻す
フラッシュバックドロップ	削除された表を戻す
フラッシュバックデータベース	データベース全体を指定した時点の状態に戻す

試験ではフラッシュバックドロップとフラッシュバックテーブルに注意しましょう。

Oracle Database 10gで表を削除すると、関連する索引、制約、データベーストリガーは元の表領域内にリネームされた状態で残されています。これをごみ箱に置かれた状態といいます。ごみ箱から元に戻すことをフラッシュバックドロップといいます。

ごみ箱からパージを行うと表内のすべての行が削除され、データディクショナリから定義が削除されます。表に作成された索引も同時に削除されます（ビューは自動的に削除されません）。

フラッシュバックテーブルではUNDOデータを使用し、1つ以上の表を特定の時点の状態に戻すことができます。特定の時点の状態を判断するために、フラッシュバック問い合わせ、行履歴フラッシュバック、トランザクション履歴フラッシュバックなどを活用します。

実行には、行の移動が有効であることなどの条件があります。

http://jibun.atmarkit.co.jp/lskill01/rensai/bronzedba11/bronzedba01.html