誰でも簡単にOracleデータベースの「受肉」の概念を理解できる方法で説明できますか？
Oracleドキュメント インカネーションを次のように説明します。
化身
データベースの個別のバージョン。 RESETLOGSオプションを使用してデータベースを開くと、データベースのインカネーションが変更されますが、必要なREDOが使用可能である限り、以前のインカネーションからバックアップをリカバリできます。
しかし、それでも完全には理解できません。誰にでもわかりやすい説明をお願いできますか？
おかげで、
以下は、回答で具体化が使用される目的を説明するために使用する短いグラフィックです。
restore db +-----+ +-----+ +-----+
recover db | 2>3 | --------> | 3 | --> | 3 | -->
resetlogs +-----+ +-----+ +-----+
^ Incarn. 3 3
/ SCN # 400 500
/
/
restore db +-----+ +-----+ +-----+
recover db | 1>2 | -------> | 2 | --> | 2 | --> ...
resetlogs +-----+ +-----+ +-----+ ^
^ Incarn. 2 2 | 2
/ SCN # 300 400 | 500
/ |
/ |
+-----+ +-----+ +-----+ |
--> | 1 | --> | 1 | --> | 1 | --> ... |
+-----+ +-----+ +-----+ ^ |
Incarn. 1 1 1 | 1 |
SCN # 100 200 300 | 400 |
| |
Backup 11:00 ----- 12:00 ----- 13:00 ----- 14:00 ----- 15:00 ----- 16:00 ----- 17:00
| |
Restore/ (1) (2)
Recovery
基本
Oracleデータベースが作成されると、最初のインカネーション番号を受け取ります。インカネーション番号は、データベース自体、データベースインスタンスの制御ファイル、および中央のRMANカタログデータベース（ある場合）に格納されます。
新しい化身
上の図を見てみましょう。これは、Oracleが化身とは何かを説明するために使用するグラフィックを少し変更したものです。
参照：RMAN Media Recovery （ Oracleドキュメント）
アーカイブログのバックアップ
次に、アーカイブログのバックアップが1時間ごとに発生していると仮定します。ああ、そしてdatbaseはARCHIVE_LOGSモードです。これにより、アーカイブログのバックアップと復元が可能になり、データベースを特定の時点に回復できます。また、データベースが同日の04:00（a.m.）に完全バックアップを受け取ったと仮定します。さらに、データベースは最初に作成されてから復元されておらず、データベースの現在のINCARNATION＃は1にあります。
SCN
さらに、バックアップ時にSCN＃が100の倍数になるように、1時間に100回のトランザクションが発生すると仮定します。
時間
グラフィックの可読性を高めるための時間はここにあります。 Oracleが特定の時点に復元されたデータベースの新しいインカネーションを作成する理由を理解する上で役割を果たします。
特定時点へのデータベースの復元（1）
13:00（午後1時）の少し後のどこかで、誰かがデータベースを12:00（正午12時）に復元する必要があると判断しました。 DBAは一連のRMANコマンドをセットしてデータベースをその時点の状態に復元し、素晴らしいGUIを介してクリックすると、サードパーティベンダーからの復元/回復を開始します。
RMANは、データベースの完全バックアップとすべてのアーカイブログバックアップをディスク/テープから取得し、それらをディスクに復元します。リカバリフェーズでは、RMANはすべての関連情報が利用可能であることを確認し、完了したすべてのトランザクションを特定の時点にロールフォワードし、未完了のすべてのトランザクションを特定の時点にロールバックして、データベースの一貫性を確保します。状態。
データベースを一般に公開する前に、データベースは、将来のすべてのバックアップが以前のバックアップと競合しないことを確認する必要があります。これは、新しいインカネーションを作成する必要があり、次のコマンドを実行してデータベースを開くときに発生します。
ALTER DATABASE OPEN RESETLOGS;
どうして？
OK。図を見ると、元のINCARNATION＃1パスの13:00（1 pm）のSCN＃は300です。SCN＃400を記録した14:00（2pm）のバックアップには到達していません。バックアップ。復元/回復プロセス中は、バックアップは行われません。また、復元プロセスに1時間かかる場合、新しいデータは挿入されません。データベースがオンラインに戻る準備ができており、次のバックアップが14:00（2pm）に行われる場合、バックアップにはSCN＃300が含まれます。これは、復元/リカバリが開始される前と同じデータベースのSCN＃です。 、バックアップのために13:00（1pm）に記録されました。
オラクルはどのバックアップを使用するかをどのようにして知るのですか？
これが、INCARNATION＃が新しい値に設定される理由です。これにより、Oracleは13:00（1pm）のアーカイブログバックアップと以下の情報を区別できます。
INCARNATION# 1
SCN# 300
Time......... 13:00
...次の情報を含む14:00（2pm）のバックアップ：
INCARNATION# 2
SCN# 300
Time......... 14:00
特定時点へのデータベースの復元（2）
最初の復元/回復アクションの後、データベースが稼働し続け、わずかに15:00（午後3時）後、誰かが同じ日の14:00（午後2時）に新しい復元/回復が必要であると判断したとします。
RMANはファイルを復元し、データベースをリカバリし、ALTER DATABASE OPEN RESETLOGSを開始してデータベースをオンラインに戻します。 INCARNATION＃が3に設定され、16：00の最初のバックアップに次の情報が含まれます。
INCARNATION# 3
SCN# 400
Time......... 16:00
...そうしないと、15：00（午後3時）からのINCARNATION＃2およびSCN＃400でのデータベースのバックアップと競合します。しかし、新しいINCARNATION＃のおかげで、すべてがうまくいきます。
概要
それは、転生が何のために使用されるかについての（短いとはいえ）説明です。これにより、RMAN（および英雄的なDBA）は、以前に複数回バックアップおよび復元されたデータベースを復元および回復するために使用するパスを決定できます。
次へ
化身のこの短い説明は決して完全ではありません。 ORPHANEDインカネーションとOBSOLETEバックアップをもたらす他の要因があります。これらのトピックのいくつかは、このスレッドまたは別のQ＆Aのフォローアップ回答で説明されます。
例えば...
より大きなタイムスケールでインカネーションを見る場合、データベースをポイントインポイントに復元および復元する可能性があるため、データベースの復元を開始する前にRESET DATABASE TO INCARNATION <number>を開始する必要がある場合があります。 INCARNATION＃1のパス上にあり、制御ファイルの自動バックアップコピーの復元が必要になる可能性がある時間。この時間を過ぎると、データベースの復元と回復についても考えることができます。
乞うご期待...
STNDBYと呼ばれるフィジカルスタンバイに複製されたPRODと呼ばれるOracleデータベースから始めるとしましょう。 RMAN†を介してSTNDBYのコピーを取得し、それをMASTERと呼ぶことにより、開発環境を更新します。いくつかのアクション（機密ユーザーデータの削除など）を実行するためにMASTER読み取り/書き込みを開き、DEV1、DEV2などと呼ばれる開発者のためにそれをコピーします。開発者の1人がいくつかの実験を行うことを望んでいるため、DEV1をDEV1Aにさらに複製します。したがって、現在、データベースには多くのバージョンがあります。
------ -------- -------- ------ -------
|PROD| -> |STNDBY| -*-> |MASTER| -*-> |DEV1| -*-> |DEV1A|
------ -------- -------- ------ -------
*は、あなたが行ったポイントを示しますOPEN RESETLOGSまたは新しい制御ファイルを作成しました。これは、データベースの新しい化身を意味します。このチェーンでREDOログを「逆方向」に適用することはできません。 MASTERを作成する前にPRODをシャットダウン（SCNが増加しない）しても、ダウンストリームデータベース（DEV1など）に変更を加えることができず、REDOログをPRODに適用することができます。 -インカネーションがインクリメントされました。
†これが意味するところは前の化身からのバックアップを回復する
具現化は、データベースの存続期間における特定のブレークポイントです。明確にするために、データベースのフルサイクルとREDOログのバックアップから作成を開始するときのデータベースライフサイクルを確認できます。これを時系列で考えてください。いくつかのバックアップの後で、時間を遡ってデータベース全体を特定の状態に復元する必要があります。ポイントインタイムまたはSCN。これを行うと、データベースの新しいエンカネーションを作成するリセットログでデータベースを開く必要があります。これは、以前のバックアップチェーンが新しいインカネーションのポイントから復元を決定したポイントまで持っていたためです。これは、データベースを使用できなくなります。これは、リセットログでデータベースを開くと、新しい操作がREDOログに記録されるため、インカネーション時点から新しいバックアップの並列タイムラインを生成する必要があるためです。