ログ、バックアップおよび復元
ログ、バックアップおよびデータの復元について
PSQL には、データ整合性を確実にし、オンライン バックアップおよびデータ被害の復旧をサポートするいくつかの強力な機能があります。
トランザクション ログおよびトランザクション一貫性保持
PSQL はトランザクションに関わるデータベース オペレーションのデータ整合性を
トランザクション ログおよび
トランザクション一貫性保持の 2 つのレベルで保証します。
ここでは、以下の項目について説明します。
これらの機能の使用法
これらの機能はいずれも、PSQL Control Center 内の設定を使用して、または Distributed Tuning Interface を使用してプログラムから、データベース エンジン内で有効または無効にすることができます。
トランザクション一貫性保持および
トランザクション ログを参照してください。
トランザクション一貫性保持のデフォルト値は
オフで、
トランザクション ログのデフォルト値は
オンです。
機能の比較
これらの機能は共に複数ファイルのトランザクション アトミシティを提供し、確実にデータ ファイルの一貫性を保ち、未完了のトランザクションはどのデータ ファイルにも絶対に書き込まれないようにします。
アトミシティとは、トランザクション内のあるデータ オペレーションが完了しなかった場合にはトランザクション内のどのオペレーションも完了させないことを意味します。アトミックな変更はデータベースに部分的またはあいまいな変更を残しません。個々のファイルに対する変更は、トランザクション ログおよびトランザクション一貫性保持がオンでもオフでも、常にアトミックです。ただし、トランザクションでは、複数ファイルへの変更をグループ化して 1 つのアトミック グループにすることができます。これら複数ファイルのトランザクションのアトミシティは、アプリケーション内でトランザクションを使用し、トランザクション ログまたはトランザクション一貫性保持がオンに設定されている場合にのみ、MicroKernel が保証します。
これらの利点に加え、
トランザクション一貫性保持はシステム障害時に、障害前にアプリケーションに正常終了のステータス コードを返したトランザクションの結果がすべてデータ ファイルに含まれていることを保証します。
高パフォーマンスが求められる場合には、
トランザクション ログはこの保証を提供できません。
トランザクション一貫性保持は、エンジンが正常終了のステータス コードを返す前に完了したトランザクションを完全にトランザクション ログに書き出すことを確実にするため、トランザクション ログはロガー スレッドがログ バッファーをディスクにフラッシュするように指示されるとすぐに正常終了のステータス コードを返します。
[トランザクション ログ]は[トランザクション一貫性保持]のサブセットです。つまり、[トランザクション一貫性保持]の設定をオンにすると、ロギングが行われ、[トランザクション ログ]の設定はデータベース エンジンによって無視されます。
[トランザクション ログ]と[トランザクション一貫性保持]の主な違いを次の表で示します。
表 24 [トランザクション ログ]と[トランザクション一貫性保持]:利点
機能 | 複数ファイル間でのデータの整合性とトランザクション アトミシティの保証 | 正常終了のステータス コードを返したすべての完了済みトランザクションに対するコミットの保証 |
トランザクション ログ | 可 | 不可 |
トランザクション一貫性保持 | 可 | 可 |
表 25 トランザクション ログとトランザクション一貫性保持:機能
機能 | ログ バッファーをディスクに書き込むタイミング |
トランザクション ログ | ログ バッファーがいっぱいになったとき、または[起動時間制限]の設定値に達したときに、ログ バッファーはログ ファイルに書き込まれます。各 End Transaction オペレーションの正常終了を示すステータス コードは、ロガ- スレッドがバッファーをディスクにフラッシュするように指示されるとすぐにアプリケーションに返されます。 |
トランザクション一貫性保持 | End Transaction オペレーションごとに、ログ バッファーはトランザクション ログ ファイルに書き込まれます。各 End Transaction オペレーションの正常終了を示すステータス コードは、ログのディスク書き込みが正常終了するまでアプリケーションに返されません。トランザクションには含まれない Insert または Update オペレーションの場合は、ログ バッファーがいっぱいになったとき、または[起動時間制限]の設定値に達したときにログ バッファーがログ ファイルに書き込まれます。 |
どちらの機能を使用するか
最高のパフォーマンスを得るためには、トランザクションの安全性のニーズに合った最低レベルのロギングを使用することができます。適切なロギング レベルを決定するには、アプリケーション ベンダーに確認することが最良の方法です。同じコンピューター上の PSQL を使用する複数のアプリケーションがある場合は、それらアプリケーションのなかで要求される最高レベルのロギングを使用する必要があります。
データ ファイルが 1 つのみであるか、複数データ ファイルによるトランザクションを行うアプリケーションがない場合は、一般的に
トランザクション一貫性保持または
トランザクション ログを使用する必要はありません。このような状況下では、PSQL はログの有無に関わらず、各データ ファイルの内部的な整合性を保証します。
トランザクション ログ
PSQL アプリケーションのうち 1 つでも複数データ ファイル間でトランザクションを行うアプリケーションがある場合は、[トランザクション ログ]をオンにします。
トランザクション ログを使用しないと、PSQL ではトランザクションの複数ファイルのアトミシティまたは複数ファイルのデータ整合性を保証することはできません。
システム障害が発生した場合、このレベルのロギングでは、完了した各トランザクションがデータ ファイルに書き込まれることが保証されません。
トランザクション一貫性保持
PSQL アプリケーションのうち 1 つでも、複数データ ファイル間の完了したトランザクションが確実にデータ ファイルに書き込まれるよう保証することが必要な場合は、
トランザクション一貫性保持をオンに設定します。
システム障害が発生した場合、このレベルのロギングは正常終了した各トランザクションがデータ ファイルに書き込まれることを保証します。
ログの機能
これらの機能は、オペレーションではなくトランザクションのアトミシティを確実にするものであることに注意してください。SQL を使用する場合、トランザクションは BEGIN ステートメントまたは START TRANSACTION ステートメントと END または COMMIT ステートメントの間にある一連のオペレーションと定義されます。Btrieve を使用する場合、トランザクションは Start Transaction オペレーションと End Transaction オペレーションの間にある一連のオペレーションと定義されます。
すべてのデータ ファイルの追加および更新はログ バッファーに格納されます。トランザクションが完了するか(トランザクション一貫性保持)、バッファーがいっぱいになるか、
起動時間制限に達する(トランザクション一貫性保持またはトランザクション ログ)と、バッファーはトランザクション ログ ファイルに書き込まれ(フラッシュされ)ます。
トランザクション ログの場合、エンジンがトランザクション終了のオペレーションを受け取り、ロガー スレッドにログ バッファーをディスクにフラッシュする指示を出すことに成功した場合、エンジンはアプリケーションに正常終了のステータス コードを返しトランザクションが開始します。トランザクション一貫性保持の場合、エンジンはロガー スレッドがバッファーをディスクに書き込むことに成功したことを示すまで正常終了のステータスを返しません。
トランザクション ログ ファイル セグメントは
トランザクション ログのディレクトリに設定したロケーションに保存されます。ログ セグメントは *.LOG という名前で、00000001 から FFFFFFFF までのプレフィックスが付きます。
メモ: トランザクション ログまたはトランザクション一貫性保持が有効な場合、すべてのオペレーションは、トランザクション内で行われたかどうかに関わらず、ログ ファイルに書き込まれます。ただし、トランザクション内で実行されたオペレーションのみがアトミックであることが保証されます。システム障害が発生し、トランザクション ログがロール フォワードされる場合、完了したトランザクションのみがデータ ファイルにコミットされます。対応する End Transaction オペレーションを持たないオペレーションは拒否され、データ ファイルにコミットされません。
ヒント: データベースの使用率が高い場合には、データ ファイルが存在するのとは物理的に異なるボリュームにトランザクション ログが保持されるようにシステムを構成する必要があります。一般的に高負荷の下では、単一ドライブで I/O 帯域幅を競う代わりに、ログ ファイルへの書き込みとデータ ファイルへの書き込みを別々のドライブに分ける方がパフォーマンスがよくなります。全体的なディスク I/O は減少しませんが、ロードはディスク コントローラー間で効率よく分散されます。
設定プロパティの[
トランザクション ログのディレクトリ]設定を使用して、トランザクション ログのロケーションを指定することができます。
システム障害の発生時期が、ログ ファイルが書き込まれた後で、コミットされたオペレーションがシステム トランザクション内でデータ ファイルにフラッシュされる前であれば、コミットされたオペレーションが失われることはありません。コミットされたオペレーションをフラッシュするには、影響を受けるファイルをシステム障害後に開き、オペレーションを実行する必要があります。ファイルを開いてオペレーションの実行を試みると、システム障害の発生時点で影響を受けていたファイルにデータがロール フォワードされます。単にデータベース エンジンを再起動すると、ロール フォワードは呼び出されず、データの一貫性が保たれません。
メモ: ロール フォワードされたファイルに関連付けられているログ ファイルは自動的に削除されません。これは、ログ ファイルが 2 つ以上のデータ ファイルに関連付けられている可能性があるからです。
この機能により、個々のクライアント トランザクションは、成功を示すステータス コードをすばやく受け取ることが可能になると同時に、複数のクライアント トランザクションをグループにまとめてデータ ファイルに順次書き出すことでパフォーマンスが向上するという利点が得られます。
データベース サーバーのデータ ファイルが格納されているボリュームのディスクに障害が発生し、アーカイブ ログからデータを復元する必要がある場合、エンジンはトランザクション ログ ファイルをロール フォワードしません。アーカイブ ログにはトランザクション ログのすべてのオペレーションが含まれているため、トランザクション ログをロール フォワードする必要がありません。
ヒント: システム障害後、すべてのデータ ファイルを開き、それらのファイルに対して Stat オペレーションまたは読み取りオペレーションを実行してください。すべてのデータが復元されていることを確認できたら、古いログ ファイルは安全な場所に保管してもかまいません。
関連項目
詳細については、以下を参照してください。
アーカイブ ログおよび Continuous オペレーションについて
この製品は、オンライン バックアップおよびデータ被害復旧をサポートするための相互に排他的な 2 つの機能を提供します。
状況 | 使用する機能 |
バックアップ実行中もデータベース アプリケーションを実行し続ける必要がある。 | Continuous オペレーション |
バックアップを実行するのにエンジンをシャット ダウンすることができる。 | アーカイブ ログ |
アーカイブ ログを使用すると、最後のバックアップ以降のデータベース オペレーションのログを保存することができます。システム障害が発生した場合、バックアップからデータ ファイルを復元し、ログ ファイルから変更をロールフォワードして、システムをシステム障害発生前の状態に戻すことができます。
注意: アーカイブ ロギングは、アーカイブ ログからの復元後、すべてのデータ ファイルが一貫性のある状態になることを保証しません。速度向上のために、データベース エンジンはログ関数から成功を示すステータス コードが返されるのを待たずに、ログ バッファーを空にします。そのため、ディスク フルやオペレーティング システムの書き込みエラーなどのめったに起こらない状況において、データ ファイルで正常に行われた更新がアーカイブ ログに記録されないことがあります。また、アーカイブ ログではすべてのファイルのログをとる必要がないため、複数のファイルの更新を行うトランザクションがあるとき、そのうち一部のファイルのログしかアーカイブしていない場合は、トランザクションがアーカイブ ログに完全に記録されないことがあります。結果として、あるファイルがほかのファイルと矛盾する可能性があります。トランザクションを使用しており、複数ファイルのトランザクション アトミシティが必要な場合は、
トランザクション ログおよびトランザクション一貫性保持を参照してください。
Continuous オペレーションを使用すると、データベース エンジンが実行中でユーザーが接続中でもデータベース ファイルのバックアップを行うことができます。Continuous オペレーションの開始後、データベース エンジンはアクティブなデータ ファイルを閉じ、すべての変更をテンポラリ データ ファイル(デルタ ファイルと呼びます)に格納します。Continuous オペレーションが機能している間に、データ ファイルのバックアップを実行します。バックアップ中にデータ ファイルに対して行われた変更はすべてデルタ ファイルに記録されます。
バックアップが完了したら、Continuous オペレーションを解除します。データベース エンジンはデルタ ファイルを読み取り、元のデータ ファイルにすべての変更を適用します。この一時デルタ ファイルは、Continuous オペレーション中に多くの変更が行われた場合、元のデータ ファイルのサイズを超えることがあります。
Continuous オペレーションが設定されているファイルは、リレーショナル エンジンおよび MicroKernel エンジンからそのデータ ファイルが削除されないようロックします。さらに、このファイルはキーの変更などファイル構造の変更も受け付けません。
メモ: アーカイブ ログおよび Continuous オペレーションは相互に排他的な機能で、同時に使用することはできません。
アーカイブ ログとトランザクション ログの違い
トランザクション ログは、システム障害時のデータの完全性を守るためにデザインされたもう 1 つの機能ですが、アーカイブ ログとは直接関連を持ちません。トランザクション ログは、アーカイブ ログまたは Continuous オペレーションのいずれかと同時に機能させることができます。トランザクション ログは、短期間のログ ファイルを使用して、トランザクションが確実にディスクに書き込まれるようにします。トランザクション ログは、システム トランザクションのために、完了したクライアント トランザクションが物理データ ファイルへ移行するときに、頻繁にリセットされます。システム障害が発生すると、データベース エンジンが再起動されたときにトランザクション ログを読み取り、システム障害より前に完了していたトランザクションをデータ ファイルにいっきに移します。
アーカイブ ログは、各システム トランザクションの完了時に書き込まれるので、システム トランザクション中にシステム障害が起こらない限り、アーカイブ ログおよびトランザクション ログは適切に同期しています。
トランザクション ログの詳細については、
トランザクション ログおよびトランザクション一貫性保持を参照してください。
ファイルの復元が必要になったら
バックアップからデータ ファイルを復元する必要のあるシステム障害が発生した場合、アーカイブ ログを使ってバックアップから復元してデータベースの動作状態をシステム障害の時点に回復することができます。
アーカイブ ログを使用せずに同様の障害が起きた場合(たとえば、バックアップの実行に Continuous オペレーションを使用していた場合)、最後のバックアップからシステム障害の間のデータベースの動作を回復することはできません。
表 26 システム障害後のデータ回復の限界
アーカイブ ログ | 障害後に回復できないデータ |
オン | 障害時に未完了のトランザクション |
オフ | データ ファイルの最後のバックアップ以降に起きたすべてのデータベース オペレーション |
この章では、これ以降、アーカイブ ログおよび Continuous オペレーションに関連するオプションと手順について説明します。
アーカイブ ログの使用
このセクションでは、アーカイブ ログの設定、データ ファイルのバックアップおよび復元を行う方法について説明します。以下のトピックに分かれています。
全般的な手順
アーカイブ ログが適切に動作するためには、明確に定義された手順に従って設定する必要があり、バックアップからの復元が必要になった場合には別の手順が必要です。
注意: この手順のいずれかの段階が省かれたり、十分でない場合、バックアップからデータを復元することができません。
►アーカイブ ログを適切に使用するには
1 まだ動作していない場合は、アーカイブ ログをオンにします。設定の詳細については
アーカイブ ログの設定を参照してください。
2 データベース エンジンをシャット ダウンします。
3 データ ファイルをバックアップします。
4 バックアップに成功したら、既存のアーカイブ ログをすべて削除します。
注意: データ ファイルでの作業再開前にそれぞれのログ ファイルを削除します。バックアップ データ ファイルとそのログ ファイルが同期していることは、回復作業を成功させるための重要事項です。
5 データベース エンジンを再起動します。
►バックアップからデータ ファイルを復元し、アーカイブ ログの変更を適用するには
メモ: ハード ディスクがクラッシュし、アーカイブ ログおよびデータ ファイルの両方がそのディスク上にあった場合は、この手順でアーカイブ ログをロール フォワードすることはできません。
1 システム障害後コンピューターを再起動したら、データベース エンジンが実行中でないことを確認し、復元しようとしているデータ ファイルにほかのデータベース エンジンがアクセスしていないことを確認してください。
2 バックアップからデータ ファイルを復元します。
3 データベース エンジンを起動し、どのようなアプリケーションもエンジンに接続していないことを確認します。
注意: アーカイブ ログがデータ ファイルに適用される前にデータベース アクセスが行われないようにすることは重要です。ほかのデータベース エンジンがファイルにアクセスしていないことを確認してください。システム障害にあったのと同じエンジンを使用してアーカイブ ログをロール フォワードする必要があります。
5 ロール フォワードが正常に完了したら、データベース エンジンを停止し、データ ファイルの新しいバックアップを作成します。
6 データ ファイルが正常にバックアップできたら、アーカイブ ログ ファイルを削除します。これで、データベース エンジンを再起動し、アプリケーションがデータ ファイルにアクセスできます。
アーカイブ ログの設定
アーカイブ ログの設定には 2 つの段階があります。
•アーカイブ ログ機能を有効にする
•アーカイブするファイルとそれぞれのログ ファイルを指定する
メモ: これらの処理を行うには、データベース エンジンが起動しているコンピューターに対し管理者権限を持っているか、データベース エンジンが起動しているコンピューター上の Pervasive_Admin グループのメンバーである必要があります。
►アーカイブ ログを有効にするには
1 オペレーティング システムの[スタート]メニューまたはアプリ画面から Control Center にアクセスします。
2 PSQL エクスプローラーで、ツリーのエンジン ノードを展開します(ノードの左の展開アイコンをクリックします)。
3 アーカイブ ログを指定するデータベース エンジンを右クリックします。
4 [プロパティー]をクリックします。
5 ツリー内で[データ整合性]をクリックし、そのカテゴリに含まれるオプションの設定内容を表示します。
6 [選択ファイルのアーカイブ ロギング]チェックボックスをクリックします。
7 [OK]をクリックします。
設定を有効にするにはエンジンの再起動が必要であることを知らせるメッセージが表示されます。
8 [はい]をクリックして、エンジンを再起動します。
►アーカイブするファイルを指定するには
アーカイブ ログを実行するファイルは、そのファイルを含むボリュームに作成したアーカイブ ログ設定ファイルに、エントリを追加することによって指定します。設定ファイルは、以下の方法で設定します。
1 ログを行う対象のデータ ファイルが存在する物理ドライブのルート ディレクトリに、\BLOG ディレクトリを作成します。(マップされたルート ディレクトリは使用しないでください)。ファイルが複数のボリュームに分かれている場合は、その各ボリュームに \BLOG ディレクトリを作成します。
たとえば、C:\ および D:\ にデータ ファイルが存在し、どちらのドライブもデータベースと同じコンピューター上に存在する物理ドライブである場合、次のように 2 つの BLOG ディレクトリを作成します。
C:\BLOG\
D:\BLOG\
メモ: Linux および OS X では、ログ ディレクトリは blog という名前で、PVSW_ROOT 環境変数で指定したディレクトリ(デフォルトでは /usr/local/psql)に作成する必要があります。
2 各 \BLOG ディレクトリに、空の BLOG.CFG ファイルを作成します。BLOG.CFG の作成には、メモ帳のような任意のテキスト エディターを使用してください。Linux および OS X では、ファイルの名前は blog.cfg(小文字)である必要があります。
3 各 BLOG.CFG ファイルに、そのドライブ上にあるアーカイブ ログを実行するデータ ファイルのエントリを入力します。エントリの入力には、以下の形式を使用します。
\パス1\データ ファイル1[=\パス2\ログ ファイル1]
パス1 | ログを行う対象のデータ ファイルのパス。パスには、ドライブ名は含めません。 |
データ ファイル1 | ログを行う対象のデータ ファイルの名前。 |
パス2 | ログ ファイルのパス。ログ ファイルとデータ ファイルは、異なるドライブ上に存在する場合があるため、必要に応じてパスにドライブ名を追加します。 |
ログ ファイル1 | ログ ファイルの名前。名前を指定しない場合、データ ファイルと同じディレクトリおよびファイル名プレフィックスがデフォルト値となりますが、ファイル名サポートフィックスは ".log" に置き換えられます。異なる物理ドライブを指定して、ログとデータ ファイルを同じドライブに置かないようにすることができます。ログをとるデータ ファイルごとに別々のログ ファイルが必要です。 |
エントリにはスペースを使用せず、1 行以内に収める必要があります。(各行最大で半角 256 文字)余裕があれば同一行に複数のエントリを置くことができます。エントリはスペースで区切ります。
注意: ログをとるデータ ファイルすべてに異なるログ ファイルを使用する必要があります。2 つ以上のデータ ファイルに同一のログ ファイルを使用すると、MicroKernel はロールフォワードが必要になったときにそのログ ファイルを使用できません。
ログ ファイルの名前を入力しない場合は、ログ ファイルを最初に開いた際に、元のファイル名に拡張子 .LOG を付けたファイル名が割り当てられます。たとえば、ファイル B.BTR では、ログ ファイルに B.LOG が割り当てられます。
注意: データベースのすべてのファイルのログをとる必要はありません。ただし、データベースに参照整合性(RI)規則が指定されている場合は、各 RI の関係に含まれるすべてのファイルのログを指定するかまたは 1 つも指定しないでください。RI の関係に含まれるファイルのサブセットのみのログを指定すると、システム障害後にアーカイブ ログをロール フォワードするとき、RI 規則違反となります。
例
以下は、ドライブ C 上にある BLOG.CFG ファイルの 3 つのエントリ例です。すべてのエントリは、同じ結果になります。C:\DATA\B.BTI の処理は、C:\DATA\B.LOG に記録されます。
\data\b.bti
\data\b.bti=\data\b.log
\data\b.bti=c:\data\b.log
次の例では、C:\DATA\B.BTI の処理が、ログ ファイル D:\DATA\B.LGF に記録されます。これは、アーカイブ ログ ファイルが、データ ファイルと同じドライブ上に存在する必要がなく、拡張子が「.LOG」である必要もないことを表します(拡張子「.LOG」はデフォルト)。
\data\b.bti=d:\data\b.lgf
ヒント: 同じコンピューターの異なる物理ドライブにログを書き込むことをお勧めします。ログ ファイルを異なる物理ドライブに置けば、ハード ディスクがクラッシュした場合にデータ ファイルといっしょにログ ファイルも失うことを防げます。
次に、MicroKernel が複数のファイルのログを異なるドライブ(ドライブ D:)に作成するようにする BLOG.CFG の例を示します。BLOG.CFG ファイルはドライブ C: にあるものとします。
\data\file1.mkd=d:\backup\
\data\file2.mkd=d:\backup\file2.log
\data\file3.mkd=d:\backup\file3.log
ロール フォワード コマンド
Btrieve Maintenance ユーティリティ(GUI またはコマンド ラインの BUTIL)は、アーカイブ ログ ファイルをデータ ファイルにロール フォワードするコマンドを提供します。
アーカイブ ロギングの実行を参照してください。
Continuous オペレーションの使用
Continuous オペレーションは、データベース アプリケーションが実行中でユーザーが接続されている間にデータ ファイルのバックアップを行う機能を提供します。ただし、ハード ドライブ障害の場合、Continuous オペレーションを使用してバックアップを作成していた場合には、最後のバックアップ以降のデータの変更はすべて失われます。アーカイブ ログおよび Maintenance ユーティリティのロール フォワード コマンドを使用して最終バックアップ後に起こったデータ ファイルへの変更を復元することはできません。
PSQL には Continuous オペレーションのためのバックアップ コマンド BUTIL があります(また、PSQL は製品として Backup Agent を提供し、Continuous オペレーションを設定および管理します。詳細については、その製品で提供されるマニュアル『Backup Agent Guide』を参照してください)。
メモ: Continuous オペレーションが設定されているファイルは、リレーショナル エンジンおよび MicroKernel エンジンからそのデータ ファイルが削除されないようロックします。さらに、このファイルはキーの変更などファイル構造の変更も受け付けません。
このセクションは、以下のトピックに分かれています。
Continuous オペレーションの開始と停止
このセクションでは、
STARTBU および
ENDBU コマンドの詳細について説明します。
表 27 Continuous オペレーションの開始と停止を行うコマンド
コマンド | 説明 |
| バックアップを対象として定義されたファイルの Continuous オペレーションを開始します。(BUTIL) |
| バックアップを対象として定義されたファイルの Continuous オペレーションを停止します。(BUTIL) |
注意: Continuous オペレーション モードによって作成されたテンポラリ デルタ ファイルは対応するデータ ファイルと同じ名前ですが、拡張子 “.^^^” を使用します。同じディレクトリに、ファイル名が同一で拡張子のみが異なるようなファイルを置かないでください。たとえば、データ ファイルに INVOICE.HDR および INVOICE.DET というような名前の付け方をしないでください。もしそうした場合、MicroKernel はステータスを返し、ファイルは Continuous オペレーションに入れられません。
Continuous オペレーション モードは、MicroKernel のパフォーマンスにほとんど影響を与えませんが、ファイルのバックアップにサーバーを使用した場合は、影響が出ることがあります。
►Continuous オペレーションを使用してデータの消失を防止するには
1 STARTBU コマンドを使用し、ファイルに Continuous オペレーションを適用します。
BUTIL のコマンド構文の説明については、
STARTBU を参照してください。
2 データ ファイルをバックアップします。
3 ENDBU コマンドを使用し、ファイルに対する Continuous オペレーションを解除します。
BUTIL のコマンド構文の説明については、
ENDBU を参照してください。
BUTIL を使用してデータベースのバックアップを行う
このセクションでは、
butil コマンドの
STARTBU および
ENDBU を使用したデータベースのバックアップに関する詳細について説明します。
STARTBU
BUTIl STARTBU コマンドは、バックアップの目的でファイル(複数可)の Continuous オペレーションを開始します。
形式
BUTIL -startbu <sourceFile | @listFile> [/UID<name> </PWD<word>> [/DB<name>]]
sourceFile | バックアップのために Continuous オペレーションを開始するデータ ファイルのフル パス名(Windows プラットフォームのドライブ指定を含む)。 この完全に修飾された名前は、butil を実行しているのと同じマシン上に存在している必要があります。STARTBU コマンドではマップ ドライブは使用できません。 |
listFile | Continuous オペレーションを開始するファイルの、フル パス名を含むテキスト ファイルの名前。これらのファイル名は、キャリッジ リターン/ライン フィードで区切ります。ファイル名にはスペース文字が含まれる可能性があります。
指定したすべてのファイルを対象に Continuous オペレーションを行えない場合、ユーティリティによるファイルへの Continuous オペレーションは一切行われません。 |
/UID<name> /UIDuname | セキュリティが設定されているデータベースにアクセスする権限を与えられたユーザー名を指定します。 |
/PWD<word> /PWDpword | uname で識別されるユーザーのパスワードを指定します。uname が指定された場合、pword は必ず指定する必要があります。 |
/DB<name> /DBdbname | セキュリティが設定されたデータベース名を指定します。省略した場合はデフォルトのデータベースと解釈されます。 |
メモ: この startbu コマンドは、指定したファイルのみに対して Continuous オペレーションを開始します。startbu コマンドでは、ワイルドカードは使用できません。
Linux および OS X ディストリビューションの場合、すべてのスラッシュ("/")パラメーターはスラッシュの代わりにハイフン("-")を使用します。たとえば、/DB パラメーターは -DB です。
ファイルに関する考慮点
バックアップ対象のファイルを選択する場合、Continuous オペレーション モードによって作成されるテンポラリ デルタ ファイルは除外することをお勧めします。これらのファイルは、バックアップ時に開かれ使用中だからです。デルタ ファイルがバックアップに含まれる場合、データの復元後、これらのファイルはデータベース エンジンが起動する前に削除しておく必要があります。
Windows サーバーの例
例 A:最初の例は、COURSE.MKD の Continuous オペレーションを開始します。
Windows サーバー の場合
butil -startbu <file_path>\PSQL\Demodata\course.mkd
(PSQL ファイルのデフォルトの保存場所については、『
Getting Started With PSQL』の
PSQL ファイルはどこにインストールされますか?を参照してください。)
例 B:以下の例は、STARTLST.FIL にリストされているすべてのファイルに対して Continuous オペレーションを開始します。
butil -startbu @startlst.fil
STARTLST.FIL は、以下のようなエントリで構成されます。
<file_path>\PSQL\Demodata\course.mkd
<file_path>\PSQL\Demodata\tuition.mkd
<file_path>\PSQL\Demodata\dept.mkd
ENDBU
ENDBU コマンドは、バックアップのために事前に定義したデータ ファイル(複数可)に対する Continuous オペレーションを終了します。このコマンドは、startbu コマンドを使用して Continuous オペレーションを開始し、バックアップを実行した後に使用します。
形式
BUTIL -ENDBU </A | sourceFile | @listFile> [/UID<name> </PWD<word>> [/DB<name>]]
/A | /A を指定した場合は、startbu で初期化され、現在 Continuous オペレーション モードにあるすべてのデータ ファイルに対する Continuous オペレーションが停止します。 |
sourceFile | Continuous オペレーションを終了するデータ ファイルのフル パス名(Windows プラットフォームのドライブ指定を含む)。 この完全に修飾された名前は、butil を実行しているのと同じマシン上に存在している必要があります。endbu コマンドではマップ ドライブは使用できません。 |
@listFile | Continuous オペレーションを終了するデータ ファイル名のリストを含むテキスト ファイルの名前。テーキスト ファイルには、各データ ファイルの完全修飾ファイル名が含まれている必要があります。これらのファイル名は、キャリッジ リターン/ライン フィードで区切ります。ファイル名にはスペース文字が含まれる可能性があります。 通常、このデータ ファイルのリストは、 STARTBU コマンドで使用するリストと同じものになります。 |
/UID<name> /UIDuname | セキュリティが設定されているデータベースにアクセスする権限を与えられたユーザー名を指定します。 |
/PWD<word> /PWDpword | uname で識別されるユーザーのパスワードを指定します。uname が指定された場合、pword は必ず指定する必要があります。 |
/DB<name> /DBdbname | セキュリティが設定されたデータベース名を指定します。省略した場合はデフォルトのデータベースと解釈されます。 |
メモ: Linux および OS X ディストリビューションの場合、すべてのスラッシュ("/")パラメーターはスラッシュの代わりにハイフン("-")を使用します。たとえば、/A パラメーターは -A で、butil -endbu -A のようになります。
Windows サーバーの例
以下の例では、COURSE.MKD の Continuous オペレーションを終了します。
butil -endbu <file_path>\PSQL\Demodata\course.mkd
ここでは、現在のディレクトリが f:\demodata の場合、フル パスを省略して butil -endbu course.mkd とすることもできます。
Continuous オペレーション使用時のデータ ファイルの復元
バックアップの方法として Continuous オペレーションを使用している場合、最後のバックアップ以降の変更を回復するためのリカバリ ログはありません。最後のバックアップ以後のデータベースの変更はすべて失われますが、残っている可能性があるのは、トランザクション ログに残されたトランザクションだけです。このようなトランザクションは、データベース エンジンの再起動時に自動的にロール フォワードされます。
►データとデータベース オペレーションを復元するには
1 エラーを解決します。
障害が起きたコンピューターを再起動するのに必要な保守を行います。
2 バックアップからデータ ファイルを復元するか、バックアップからハード ドライブ イメージを復元するか適切な方法をとります。
3 ディスク イメージの一部として PSQL が復元されなかった場合は、再インストールします。
注意: デルタ ファイルがバックアップ ファイルに含まれる場合、これらのファイルは、次の手順でデータベース エンジンが起動する前に削除しておく必要があります。
4 データベース エンジンを再起動します。
最後のバックアップ以後に実行されたデータベース オペレーションを再度実行する必要があります。
Backup Agent および VSS Writer によるデータ バックアップ
この章で今まで説明されてきたトピックに加え、PSQL Server および PSQL Vx Server ではデータのバックアップに対して以下のソリューションも適用します。
ご自分のバックアップ ソフトウェアが Microsoft のボリューム シャドウ コピー サービス(VSS)を認識しない場合は、Backup Agent をご自分のバックアップ ソフトウェアと連携して使用することができます。バックアップ ソフトウェアが VSS を認識する場合は、VSS によるバックアップ時に PSQL VSS Writer が自動的に起動します。バックアップ ソフトウェアが既に VSS を認識している場合は、Backup Agent を使用する必要はありません。
Backup Agent および PSQL VSS Writer は併用できますが、それに伴う利点は特にありません。どちらか一方の方法を選択すれば、バックアップ処理はより簡潔になります。
Backup Agent
Backup Agent はオプション製品です。この製品はデフォルトではインストールされません。PSQL Server のインストール後に、インストールする必要があります。
Backup Agent を使用すれば、PSQL データベース ファイルに対する Continuous オペレーションの設定と管理を簡単かつ迅速に行うことができます。Continuous オペレーションの設定と管理は、PSQL データベースのバックアップを行う際の重要な部分です。これには Microsoft のボリューム シャドウ コピー サービス(VSS)を使用しません。Backup Agent は開いているファイルに対する Continuous オペレーションの設定と管理を処理し、バックアップ中でもアプリケーションからデータを利用できるようにします。バックアップ作業が完了すると、Backup Agent は自動的に Continuous オペレーションからファイルを取り出し、バックアップ中にキャプチャされたすべての変更をロール インします。
Backup Agent は、市販されている多くのバックアップ アプリケーションと互換性があります。そのバックアップ アプリケーションでは、ほかのアプリケーションを開始および停止できるコマンドを発行できる必要があります(そのコマンドで Backup Agent を開始および停止できます)。
Backup Agent に関する詳細については、弊社 Web サイトで提供する『Backup Agent Guide』を参照してください。
PSQLVSS Writer
Microsoft のボリューム シャドウ コピー サービス(VSS)は、ライター、プロバイダーおよびリクエスター コンポーネントで構成されています。PSQL はライター コンポーネントである PSQL VSS Writer のみで VSS をサポートします。
PSQL VSS Writer はデータベース エンジンの機能であり、PSQL Server で使用可能です。PSQL VSS Writer は、この製品のインストール後に使用できるようになります。PSQL VSS Writer は現時点で PSQL Workgroup では使用できません。
PSQL VSS Writer は Windows オペレーティング システムでのみ使用可能です。ボリューム シャドウ コピー サービスの詳細については、Microsoft Web サイトのテクニカル ドキュメント「
SQL Server バックアップ アプリケーション ベンダ向けガイド」を参照してください。
概要
VSS によるスナップショット時、PSQL VSS Writer は PSQL データおよびトランザクション ログ ファイルすべてに対し、それらが存在するボリュームに関係なく、すべてのディスク I/O 書き込み動作を停止します。スナップショットの作成後、PSQL VSS Writer は停止中に遅延された書き込みなど、すべてのディスク I/O を再開させます。
PSQL VSS Writer はディスク I/O 読み取り動作を停止することはありません。書き込みが不要である限り停止中に通常のデータベース処理を継続させることができます。PSQL VSS Writer は、VSS サービスおよび VSS リクエスターのバックアップ動作によりパフォーマンスが低下するかもしれませんが、バックアップ フェーズ時は正常に動作します。
Microsoft ボリューム シャドウ コピー機能を使用すれば、バックアップおよび復元製品はバックアップ用にシャドウ コピーを作成することができます。それに含まれるファイルは次のいずれかの状態になります。
1 定義済みで、かつ整合状態にある
2 "crash-consistent state"(クリーン リストアに適さない可能性があります)
以下の条件をすべて満たせば、VSS スナップショットのファイルは定義済み、かつ整合性のとれた状態になります。
1 ファイルのライターが VSS 対応である
2 バックアップおよび復元製品が VSS 対応ライターを認識し、そのライターにスナップショットの準備を通知する
3 VSS 対応ライターはスナップショットの準備に成功する
条件を満たさない場合、ライターのファイルは "crash-consistent state" でバックアップされます。
VSS Writer の詳細
ここでは、PSQL VSS Writer の仕様について説明します。
•サポートされるオペレーティング システム
PSQL Server 製品がサポートされる Windows オペレーティング システムは PSQL VSS Writer もサポートします。PSQL VSS Writer は、マシンのオペレーティング システムおよびインストールされている PSQL Server 製品と同じビット数に対応して機能します。PSQL VSS Writer の 32 ビット版は 32 ビット マシンのみでサポートされ、64 ビット版は 64 ビット マシンのみでサポートされます。ビット数が一致しない場合、PSQL は正しく機能しますが VSS Writer は利用できません。
•サポートされるバックアップの種類
PSQL VSS Writer はデータ ボリュームの手動バックアップまたは自動バックアップをサポートします。PSQL VSS Writer は完全ボリューム バックアップおよびコピー ボリューム バックアップに対応し、増分、差分およびログ バックアップはサポートされません。VSS は PSQL VSS Writer をコンポーネントとして認識します。ただし、PSQL VSS Writer はコンポーネントのバックアップをサポートしません。VSS リクエスターがコンポーネントのバックアップで PSQL VSS Writer を呼び出すと、VSS Writer は完全ボリューム バックアップまたはコピー ボリューム バックアップでの同じアクションを実行します。
•仮想化環境のサポート
PSQL VSS Writer は仮想化環境で VSS バックアップをトリガーする VSS リクエスターをサポートします。仮想マシンのスナップショットを実行しても VSS バックアップは起動しません。
•マルチ ボリューム PSQL データ ファイル
PSQL ファイルおよびトランザクション ログが複数のボリューム上に存在することもあります。PSQL ファイルをバックアップする場合、ほかのボリューム上にあるトランザクション ログと関連ファイルは同時にバックアップすることを覚えておいてください。互いに独立しているファイルは、関連する PSQL ファイルと同時にバックアップする必要はありません。
•バックアップ ソリューションの互換性
特定のバックアップ製品が PSQL VSS Writer を認識するかどうか、スナップショットの準備をライターに通知するかどうかを判断するためには、その製品でバックアップを開始します。バックアップ処理の進行中に、 pvsw.log で PSQL VSS Writer が Frozen または Thawed 状態を記録するかどうかを調べます。バックアップおよび復元製品が、バックアップの準備を PSQL VSS Writer へ通知しなかった場合は別のソリューションを使用する必要があります。たとえば、Backup Agent を使用すれば PSQL データ ファイルを定義済み、かつ整合性のとれた状態でバックアップできます。
•PSQL VSS Writer と復元操作
バックアップ ソフトウェアで復元操作を実行する前に PSQL サービスを停止してください。これを行わないと、VSS Writer が VSS リクエスターに対し、復元に参加できないことを通知します。データの整合性を保証するためには、トランザクション ログがデータ ファイルと共に復元される必要があります。PSQL が実行している間に PSQL データとトランザクション ログ ファイルが復元された場合、その復元結果は予測不能でデータの破損を招く恐れがあります。
•PSQL VSS Writer および PSQL Continuous オペレーション
もう既に PSQL Continuous オペレーションまたは Backup Agent を使用する既存のバックアップ処理を利用されている場合もあるでしょう。そのバックアップ処理を PSQL および PSQL VSS Writer でも引き続き使用することができます。PSQL VSS Writer は Continuous オペレーションや Backup Agent の機能を妨げることはありません。ただし、PSQL VSS Writer と Continuous オペレーション(または Backup Agent)を併用しても利点はありません。どちらか一方の方法を選択すれば、バックアップ処理はより簡潔になります。
PSQL VSS Writer が呼び出されたときにファイルが Continuous オペレーション モードに置かれている場合、VSS Writer はすべての Continuous オペレーションから独立して動作します。VSS バックアップが進行中にファイルが Continuous オペレーション モードに置かれた場合は、バックアップが完了した後に PVSW.LOG を見てください。Frozen および Thawed 状態が問題なく完了していること、またデータが定義済みかつ整合状態にあることを確認してください。
PSQL VSS Writer は Microsoft VSS フレームワークも必要とします。Backup Agent では Microsoft VSS フレームワークを使用しません。したがって、Microsoft VSS フレームワークが PSQL VSS Writer を呼び出し、I/O 操作が停止された場合でも、Backup Agent はバックアップに参加しません。Backup Agent はバックアップ処理に個別に追加する必要があります。そのバックアップ処理は Backup Agent の開始と停止を行う必要もあります。