検索
連載

データベース構成要素の機能と仕組み：Oracleマイスター養成講座（3）

Share
Tweet
LINE
Hatena

　Oracleデータベースを運用するためには、データベースを構成するファイルとその機能を知らなければならない。また、ファイルの特性に応じた扱い方も心得ておく必要がある。

　前回はデータベースの設計方針についてお話ししました。データベースを設計するにはその用件に合わせてデータベース構成要素の大きさや本数を決定していく必要があります。今回はそのデータベース構成要素のそれぞれについてもう少し詳しくお話ししましょう。

初期パラメータファイル

　初期パラメータファイルは、データベースの振る舞いにかかわるたくさんのパラメータを記述するためのものです。データベースを作成する前に、必ずインスタンス別に作成し、通常はinit[インスタンス名].oraというファイル名にします。ここに設定するパラメータの例を挙げると、

  • db_name
    データベースの名前です。
  • control_files
    コントロールファイルのパス。create databaseを実行すると作成されます。
  • db_block_size
    1ブロック当たりのサイズをbytes単位で指定します。通常2048か4096を指定します。一般に、このサイズが大きければI/O効率（パフォーマンス）は向上しますが、HDD使用効率は悪くなります。
  • db_block_buffers
    更新処理などに使われるバッファの数をブロック単位で指定します。通常1000〜2000ですが、チューニングの際には見直す必要があります。

　まだまだたくさんあります。db_block_sizeなどは、後から変更するのは非常に大変（不可能？）なので、データベース作成時に決定しなければなりません。そのほかの値はデータベースのパフォーマンスにより後から調整していけばよいでしょう。上記以外は、分からないうちはデフォルト値を指定しておき、後でパフォーマンスチューニングを行いながら修正しましょう。パラメータファイル上の値の調整は、チューニングの第一歩です。

　なお、各パラメータの変更は、インスタンスをいったん停止して再起動したときに反映されます。

コントロールファイル

　これはシステムファイルであり、中身を直接見たり編集したりすることはできませんが、データベースシステムにとって重要な情報（物理構成情報）が格納されています。

  • データベース名
  • データベース稼働時の現在書き込み中のREDOログファイルとその位置
  • データファイルのファイル名

　データベースシステムは、発生するたくさんの更新処理の1つ1つについて、どの処理はコミット（確定）されていて、どれはされていない（まだ書き込み中）か、などの情報を保持しています。実際に保存されるのは後述のREDOログファイルですが、それを制御しているのがこのコントロールファイルなのです。

　なぜこのファイルがそれほど重要かというと、データベースに何らかの障害（ディスクの故障など）が起きた場合、コントロールファイルさえ無事であれば、（もちろんそれなりの準備やバックアップが必要ですが）データを回復できる可能性は高くなります。逆に、ほかのすべてのファイルが何ともなくても、コントロールファイルがすべて壊れて（誤って消してしまうなど）してしまうと、データの回復は難しくなります。

　よって、コントロールファイルは必ず複数、しかも別ディレクトリに、そしてできることであれば別の物理ディスク（なおかつ可能であれば別のSCSIコントローラ上のディスク）上に作成するように、データベース設計時に考慮しましょう。複数作っておけば1つを誤って消してしまったとしても、データベースを停止して生き残ったコントロールファイルをコピーすれば、データベースを起動することができます。

　コントロールファイルは初期パラメータファイルの中でそのファイル名を指定し、データベース作成手順の中でcreate databaseを実行したときに作成されます。

control_files = ("/ctrl1/control01.ctl", "/ctlr2/control02.ctl", "/oracle/ctrl3/control03.ctl")
初期パラメータファイルのコントロールファイル指定例

REDOログファイル

　REDOログファイルは、オンラインREDOログファイルと呼ばれ、データベースに対する書き込み情報を保持しています。REDOログファイルは最低でも2つ以上作成する決まりになっており、サイクリックに使用されます。このREDOログファイルもコントロールファイルと並んで、Oracleの最重要ファイルの1つです。OSやディスクアレイなどでディスクを完全2重化するか、「グループ化」を使って複数持たせるようにしましょう。

図1　REDOログファイルはサイクリックに使用される。同じグループ内のREDOログファイルには同時に同じ内容が書き込まれる（障害対策）
図1　REDOログファイルはサイクリックに使用される。同じグループ内のREDOログファイルには同時に同じ内容が書き込まれる（障害対策）

　REDOログファイルは図1にあるように、あらかじめある決まった大きさで作成され、その中身をデータベースシステムが変更していきます。よって、勝手にファイルの大きさが変更されることはありません。これらはコントロールファイルと同じようにcreate databaseを実行したときに作成されます。ファイル名はcreate database文中に記述します。

CREATE DATABASE "SFO"
maxdatafiles 254
maxinstances 8
maxlogfiles 32
character set JA16SJIS
national character set JA16SJIS
DATAFILE '/oracle/SFO/system01.dbf' SIZE 54M AUTOEXTEND ON NEXT 640K
logfile group 1 ('/redo1/redo01a.log', '/redo2/redo01b.log' ) 'SIZE 
50M, 
group 2 ('/redo2/redo02a.log', '/redo3/redo02b.log' ) 'SIZE 50M,
group 3 ('/redo3/redo03a.log', '/redo1/redo03b.log' ) 'SIZE 50M;
create database文の例：3グループ、合計6つのREDOログファイルを作成

注：同じグループのファイルは同時に書き込まれるので、ディスク負荷分散を考慮して別の物理ディスクに置くのが基本。

　REDOログファイルの大きさは、データベースに発生するトランザクション（書き込み処理）の頻度により慎重に決定しなければなりません。もしトランザクション量に比べて小さすぎると、ひとまわりして戻ってきたときに、書き込み処理が待たされてしまい、事実上データベースが停止してしまうという事態が発生します。

　このREDOログファイルは何のためにあるのでしょう？

　どんなデータベースシステムであっても、通常はデータの更新処理の性能アップのために「バッファリング」を行っています。これは、ユーザーが更新処理（INSERT、UPDATEなど）を行ったとき、データベースシステムは実際のテーブルが置かれている物理ディスクには書き込みにいかず、「書いたふり」をしておいて、後でゆっくり「本当の」書き込みを行う、ということです。もしこの「遅延書き込み」の仕組みを使っていないデータベースシステムを作ったとしたら、とても遅くて使い物にならないでしょう。

　「バッファリング」により得られるパフォーマンスのメリットは計り知れないのですが、それと裏腹に危険がつきまといます。それは「データの整合性」です。データの整合性を保証するということは、ユーザーが更新確定したもの（コミットしたもの）は、もし万が一更新終了直後にシステムが（強制的に）停止してしまっても、次に立ち上げればきちんとデータベース上に保持されているということです。

　それを保証する仕組みがこの「REDOログファイル」なのです。もしこの機能がないとすると、「書いたふり」をしていて、実際の物理ディスクに書き込む前にシステムが強制停止してしまうと、その情報が失われてしまいます。これは、銀行にお金を入金したのに実際の通帳には書き込まれない、というのと同じくらい重大な事態です。

　Oracleなどの「データベース」は非常に高い精度でこの「データの整合性」が求められることが多く、データベースシステムの生命線ともいえます。

図2　REDOログの働き
図2　REDOログの働き

　上の図2を見てください。このように、ユーザーが発行した更新情報はいったんメモリ上に蓄えられます。そしてコミットされた瞬間にREDOログファイルに書き込まれます。ユーザーのコミットとともに行われるのはここまでです。その後、システムはゆっくり、実際にはチェックポイントがくるごとに、物理ディスクへ書き込みます。また、メモリの状態によっては、コミット前の情報もREDOログに書かれる場合もあります。

　では、ここで物理ディスクに書き込む前に停電があったとします。ディスクが物理的に壊れさえしなければ、以下のようにデータベースを再起動した場合に「ロールフォワード」が行われます。

図3　システムの緊急停止などで未処理の情報がある場合、次回の立ち上げ時にロールフォワードが行われる
図3　システムの緊急停止などで未処理の情報がある場合、次回の立ち上げ時にロールフォワードが行われる

　きちんとデータベースを起動せずに終了（svrmgrlでshutdown abort）やマシン自体を停止してしまったときに、データベースを再起動するのに時間がかかるのは、再起動時に自動的にこの「ロールフォワード」が行われるからなのです。

　コミット前の情報がREDOログに存在した場合はロールフォワードの後に「ロールバック」が発生します。

アーカイブログファイル

　これはかなり高度なデータバックアップとリカバリ計画に基づく運用を行う場合に使用します。簡単に説明すると、上記のREDOログファイルをバックアップしていくものです。先に説明したとおり、REDOログファイルはサイクリックに使用されるため、ある一定の時間が過ぎると、上書きされてしまいます。この上書きを避けるため、REDOログを1本書き終えるごとに別ファイルにコピーしておくのです。これについては、後ほどバックアップとリカバリのところで詳しく説明する予定です。

「次回」へ


「Oracleマイスター養成講座」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る