4.4 データベースの構成要素|エディラボ

お問い合わせ・お申し込みはお気軽に「0120-876-544」

  • 研修コースをさがす
  • サービスをさがす
  • 新着情報
  • 無料セミナー/イベント情報

4.4 データベースの構成要素

4.4.2 ファイル

図4-9 信頼性を考慮すべきファイルの配置

図4-9 信頼性を考慮すべきファイルの配置

制御ファイル

データベースを構成する物理的なファイルの情報と、データベースの一貫性に関する情報を記録しています。
データベース起動時にはインスタンスを起動した後、制御ファイルを読み込みます。
その際、そこに記述されているすべてのファイルの存在と、ファイル間で一貫性がとれていることを確認した後、ファイルをオープンし、データベースをオープン状態にします。

起動時に制御ファイルが読み込めないと、データベースをオープンすることができません。
このため、制御ファイルは多重化しておくことをお勧めします。
制御ファイルを多重化するには、データベース作成時に、初期化パラメータのCONTROL_FILESに多重化するファイル名をカンマで区切って指定します。

control_files = ('ファイル名1', 'ファイル名2', 'ファイル名3')

制御ファイルを追加する手順を以下に示します。

【STEP1】
データベースをabort以外の手順でシャットダウン

【STEP2】
制御ファイルをコピー

【STEP3】
コピーしたファイル名を初期化パラメータに追加

【STEP4】
データベースのstartup

制御ファイルは、多重化したファイルのうちの1つでも障害を起こすと、Oracleサーバのインスタンスが停止します。
障害が起きた場合でも、正常な制御ファイルが1つでもあれば、障害を起こしたファイルに正常なファイルをコピーして上書きすることによって、障害は回復できます。

制御ファイルに障害が起き、多重化されていない場合、かつ現在の物理構成の状態を保持している制御ファイルのバックアップが存在しない場合、全データベースのファイル構造を確認し、制御ファイルの再作成文を発行しなければなりません。
そこで、制御ファイルをバックアップする場合は、多重化し、データベースの物理構成が変更された場合にも対応できるように、次の2種類のバックアップを取得しておきます。

  • ● OSのコピーコマンドによる物理バックアップ
  • ● 現在の物理的なデータベースの状態を元に、制御ファイルを再作成するコマンドを作成するための論理バックアップを以下のコマンドで作成する
    alter system backup control file to 'ファイル名';

REDOログファイル

データベースに対するすべての更新処理を記録するファイルです。
更新処理そのもの(REDO情報)と、その更新を元に戻すための処理(ロールバック情報)の両方が記録されます。

書き込みのタイミングとして、トランザクションがコミットされた時点では、トランザクションすべての更新ログの書き込みが完了していることを保証しています。
このため、コミットが完了した更新処理に関してはREDOログファイルが障害を起こさない限り、障害から回復されることが保証されています。

REDOログファイルが多重化されている場合、多重化された1つのメンバーが障害を起こしてもインスタンスは障害を起こさず、稼動を続けることができます。

インスタンス障害が起きたときに必要なのは、オンラインのREDOログファイルです。
インスタンス障害後、次回起動時に、オンラインのREDOログファイルが読み込まれ、すべての更新処理を再実行します(ロールフォワード処理)。
その後、トランザクションが仕掛中の更新処理は、更新を元に戻す処理を実行して(ロールバック処理)データベースを整合性のとれた状態に回復させます。
この処理は、SMONと呼ばれるバックグランドプロセスによって自動的に実行されます。

アーカイブログファイル

REDOログファイルをコピーしたファイルです。
REDOログファイルの、あるロググループへの書き込みがいっぱいになってログスイッチが起きた後に、元のロググループをアーカイブログファイルへコピーします。コピー処理を行うのはARCHプロセスです。

履歴レコードが蓄積されたアーカイブファイルは、時系列で順序がわかるように、アーカイブファイルのファイル名の一部に、ログ順序番号が記述するように指定できます。
初期化パラメータlog_archive_file='ファイル名'の「ファイル名」の記述の中に%sまたは%Sを指定することによって、ログ順序番号を埋め込むことが可能です。

アーカイブログファイルは、ディスク障害が起きたとき、回復作業のために必要となります。
ディスク障害が起きた場合の回復手順は以下のとおりです。

障害の原因を突き止めた後、以下の手順を実行します。

【STEP1】
障害の起きたディスクを、以前取得したバックアップディスクに置き換える。
このとき、コントローラが破損していた場合は、別のコントローラ上のディスクにバックアップファイルを配置する必要がある。

【STEP2】
その後、バックアップディスクが作成された時点から、ブロックに対して変更された順番にREDOログを再実行することによって、最新の状態に戻す。
再実行するのに必要なREDOログをコピーしてあるのがアーカイブログファイル。
どのアーカイブファイルが必要かは、制御ファイルの情報から自動的に指示される。
アーカイブファイルが破損している場合、ログの適用が実行できず、データベースの障害回復は困難になる。

アーカイブファイルが破損してログの適用が実行できず、データベースの障害回復は困難になることを、不完全回復といいます。

アーカイブログファイルが破損するとディスク障害からの完全回復は困難になるので、アーカイブファイルは多重化することをお勧めします。
ディスクの障害が一部であっても、そのディスクを回復するためのアーカイブファイルがすべて揃っていなければ、データベース全体の障害に広がってしまいます。
これは、データベースの同期をとる必要があるためであり、一部のディスクのみが古いバージョンであることは許されないからです。

そのため、アーカイブファイルは必ず多重化するようにしてください。
初期化パラメータに以下のように指定することによって多重化できます(以下は二重化)。

log_archive_dest_1='ディレクトリ名1'
log_archive_dest_2='ディレクトリ名2'

データベース設計についてもっと学びたいなら

> Oracle設計 研修コース一覧

具体的な作業イメージが掴みづらい概念設計を詳しく学べるコースです。
技術力に定評のあるトレーナー陣がデータベース設計作業をじっくり丁寧に解説し、スキルアップをサポートします。
また、ご要望に応じて一社向けに研修コースをカスタマイズすることも可能です。

スケジュールガイド

4.4 データベースの構成要素

エディフィストラーニングHOME