本記事の目的
Oracle Database Administration (oracle Gold)の学習がメインである。
個人的に理解するのにわかりにくかったところを記事としてまとめた。
大前提として、
基本的にDBを障害直前に戻す場合は、ResetLogsオプションは不要！！！
目次
- 用語の整理
- ResetLogsオプションは、何をしているのか
- まとめ
1.用語の整理
ResetLogsを理解するうえで、事前に理解しておく必要がある4つの用語を以下に列挙した
- インカネーション(incarnation)
- SCN
- ログ順序番号
- 不完全リカバリ(Point-In-Timeリカバリ)
早速、用語をかみ砕いていこう。
■インカネーション(incarnation)
インカネーションを、oracle社 公式のドキュメントで調べると、以下のように記載されている。
データベースの個別のバージョン。
データベースのインカネーションは、RESETLOGSオプションでデータベースをオープンすると変更されるが、必要なREDOを使用できるかぎり、以前のインカネーションからバックアップをリカバリできる。
要するに、ResetLogsは、何をしているかわからないが、
- リカバリを行った際、ResetLogsオプションでDBをオープンしない限り、インカネーションは同一のものを再利用する
- ResetLogsオプションで、DBをオープンしたら、インカネーションは更新される
もう少し、わかりやすく書いてみる。
インカネーションは、ゲームの時系列 に近い。
某 ポケットモ〇スターのゲームをイメージしてほしい。
このゲームは、ゲームを進めていく中で、強い敵に挑む前はセーブをするかと思う。
負けたとしても、直前のセーブ地点からゲームを再開できる。
この【ゲームを進めていく上での時系列】が、インカネーションというイメージを持ってほしい。
■SCN
SCNを、oracle社 公式のドキュメントで調べると、以下のように記載されている。
システム変更番号(SCN)は、Oracle Databaseで使用される論理的な内部タイムスタンプです。
SCNを使用して、トランザクションのACIDプロパティに準拠する必要があるデータベース内で発生するイベントに順序を付けます。
要するに
- トランザクションごとに、一意に割り当てられる番号
- 同一トランザクションで、複数更新があった際は、同様の番号が割り当てられる
- データベースのすべての変更をトランザクション単位で識別することができる番号
前述した、ゲームで例えると以下の感じ。
■ログ順序番号
ログ順序番号を、oracle社 公式のドキュメントで調べると、以下のように記載されている。
REDOログ・ファイル内のREDOレコードの集合を一意に識別する番号。
データベースで1つのオンラインREDOログ・ファイルがいっぱいになり、別のファイルに切り替えるとき、データベースは新しいファイルにログ順序番号を自動的に割り当てます。
以下の図にわかりやすくまとめた。
オンラインREDOログファイルは、ローテーションする際、
既に書き込みされているファイルへは上書きではなく、追記をする
アーカイブREDOファイルは、
過去のREDOログをため込むのが目的
ローテーションするのではなく、新しいファイルを作り続ける。
また、大事な考えとして以下がある。
オンラインREDOログ・ファイルに割り当てられているログ順序番号は、アーカイブログファイルにも引き継がれる
■不完全リカバリ(Point-In-Timeリカバリ)
ログ順序番号を、oracle社 公式のドキュメントで調べると、以下のように記載されている。
指定した過去の目標時点、SCNまたはログ順序番号までデータベース全体をリカバリすることです。
これは、イメージしやすいと思う。
上記状況で、15:05時点で、13時の時点に戻したい
→必要なバックアップは、以下のものだけである。
- 12:00のフルバックアップ
- 13:00のアーカイブログ
要するに、適用できるすべてのログファイルを適用しないことを不完全リカバリと呼んでいる。
2. ResetLogsオプションは、何をしているのか
さて、本題である。
冒頭にも記載した通り、基本的にDBを障害直前に戻す場合は、ResetLogsオプションは不要である。
つまり、不完全リカバリを行うときにResetLogsオプションが必要である。
では、
Q.実際にResetLogsオプションは何を行っているのか？
A.ログ順序番号が、1からカウントし直す
ログ順序番号のカウントがリセットされることによって、以下の影響が発生する
- 現行のオンラインREDOログファイルがすべて使えなくなる
- 不完全リカバリで指定した地点と不完全リカバリを実施した地点間で生成されたREDOログは適用できない
- 新たなインカネーションが作成される
影響について文字だけだと、わかりにくいので以下の図を見てほしい。
再度、不完全リカバリを例に挙げる。
上記状況で、15:05時点で、13時の時点に戻したとする。
Q. 14時と15時に取得したアーカイブログファイルは、使用できるだろうか?
A. Noである
理由としては、シンプルで整合性が取れなくなるからだ。
例えば
14時の地点でのアーカイブログファイルには、empテーブルにEMPNO=7900のJAMESさんのSALを2900→3500にupdateした情報が入っているとする。
▼13時の地点でのempテーブル
▼14時の地点でのempテーブル
さらに、いくつかの修正が入って、15時のアーカイブログも出力したのち、13時の地点に不完全リカバリを行ったとする。
不完全リカバリを行ってから、JAMESさんのSALを2900→ 4500 に修正したとする。
仮に、14時のアーカイブログが使えたとするなら、過去の情報を適用することになってしまい、不整合が生じてしまう。
だから、不完全リカバリで指定した地点と不完全リカバリを実施した地点間で生成されたREDOログは適用できない
3. まとめ
- インカネーションとは時系列をイメージ
- SCNとは、トランザクションごとに一意に割り当てられる番号
- ログ順序番号とは、Redoログファイルに割り当てられる番号
- 不完全リカバリとは、とある過去の地点をしてその地点に戻れる番号
- ResetLogsを行うと、指定した地点には戻れるが、特定のアーカイブログが使えなくなるので注意が必要