Tweet

　インターネットを使った商取引が盛んになり、24時間365日Webサイトで買い物ができるようになりました。裏を返せば、24時間365日システムを止められないということです。システムの稼働時間が長くなるということは、それだけデータ・ロスのリスクも大きくなるわけですから、バックアップの重要性が増します。さらに、システムを止められないわけですからバックアップの取り方も難しくなります。

　そこで、今回はデータベースのバックアップとリカバリについて解説します。前述したようにシステムを止めることが難しくなっていますので、システム（データベース）を止めないバックアップを中心に進めます。また、普段はリカバリを軽視しがちですが、いざ障害というときにはうまくいかないものです。リカバリ方法についても、普段から手順を確認しておくことが肝心です。

　実際の運用場面では、ストレージ管理ツールと呼ばれるバックアップ・ツールを使ってバックアップ／リカバリを行うのが一般的です。しかし、今回はDB2の機能を中心に解説します。Linux対応のストレージ管理ツールとしては、BakBone社のNetVault（http://www.bakbone.co.jp/products/netvault.html）が有名です（もちろんDB2にも対応しています）。

データベースの障害

　まず、想定されるデータベースの障害について考えてみましょう。データベースの障害は、以下の4つに大別できます。

• データベースの論理障害
  　論理障害とは、ファイルシステムが壊れたり、人為的にファイルを消してしまうなどでデータベースが破壊される障害のことです。また、DB2のプロセスがダウンして、トランザクションが不整合な状態になることも論理障害の1つです。
  
  　論理障害に対するリカバリ方法としては、バックアップ・イメージからのリストアやDB2の機能である「クラッシュ・リカバリー」があります。
  
  
• ストレージ・ディスクの障害
  　ストレージ・ディスクの障害とは、文字通りディスクが壊れてしまうことです。障害の程度にもよりますが、最悪のケースとしてはディスク装置全体が壊れてしまう事態も想定しなければいけません。
  
  　この障害に対しては、やはりバックアップ・イメージからのリストアが必要です。また、最近はハードウェアあるいはソフトウェア的にストレージデバイス間でコピーを取る仕組みも用意されているので、これを使ったスナップショット・バックアップも有効な手段です。
  
  
• サーバの障害
  　サーバがダウンしてしまう障害です。サーバとストレージを分離して構成している場合やHAクラスタを構成してスタンバイ機を用意している場合は、ストレージにデータが残っているので、クラッシュ・リカバリーなどで復旧可能です。これ以外の場合は、やはりバックアップ・イメージからのリカバリが必要です。
  
  
• サイトの障害
  　この場合の「サイト」とは、データセンターやマシンルームのある建物を指します。サイト障害は、地震や火災などでサイト全体が利用できなくなるような致命的な障害です。災害時に同じ場所で復旧するのは無理ですから、別のサイトでの復旧が必要になります。バックアップの方法としては、遠隔地のリモート・サイトにバックアップ・イメージやデータのコピーを取る必要があります。

　以下の表に、想定されるデータベース障害とそれに対応するためのバックアップ／リカバリ方式をまとめました。

データベースのリカバリに必要なものは？

　具体的なバックアップ／リカバリの解説に入る前に、まずデータベースのリカバリに必要なものは何かを整理しておきましょう。

■データベース・ディレクトリー

　DB2でデータベースを作成すると、データベース・ディレクトリーとデフォルトの表スペースなどが作られます。データベース・ディレクトリーの場所は、list database directoryコマンドで確認できます。

■テーブルスペース・コンテナー

　表スペースを別のディレクトリやRAWデバイスに作成した際は、テーブルスペース・コンテナーもバックアップ対象になります。コンテナーの場所は、list tablespacesで表スペースの概要を出力し、get snapshot for tablespaces on [DB名]で詳細なパスなどを確認します。

■ログ・ディレクトリ（アクティブ・ログ、アーカイブ・ログ）

　詳しくは後述しますが、DB2のログは2種類あります。アクティブ・ログとアーカイブ・ログです。アーカイブ・ログの場所は、データベース構成パラメータで確認できます。

　アーカイブ・ログが保存されるディレクトリは、アクティブ・ログのあるディレクトリと同じかUSEREXITプログラム（後述）で指定する保存ディレクトリとなります。

■インスタンス・ホーム

　毎回バックアップが必要というわけではありませんが、データベース・マネージャー構成ファイルやDB2レジストリ変数が格納されているので、これらのパラメータや変数を変更した後は、バックアップすることをお勧めします。

バックアップ／リカバリの方式

　それでは、バックアップとリカバリの方式を具体的に見ていきましょう。

■クラッシュ・リカバリー

　クラッシュ・リカバリーは、ディスクに書き込まれた情報（ログコントロールファイル、トランザクションログ）を基にディスクに反映されていないトランザクションを反映させ、コミットされていないトランザクションをディスクから消去し、トランザクションの整合性が保たれた状態にデータベースを戻すリカバリ方式です。この方式には、バックアップという考え方はありません。

　クラッシュ・リカバリーは、ユーザーやアプリケーションが特に意識する必要はありません。DB2のデータベース・マネージャーが、クラッシュ後に自動的に再始動を行ってクラッシュ・リカバリー処理を行います。

DB2のクラッシュ・リカバリー

　自動再始動は、データベース構成パラメータのAUTORESTARTがONになっている場合に行われます。AUTORESTARTをOFFにした場合は、明示的に再始動する必要があります。

■DB2のバックアップ／リストアコマンド

　DB2の一般的なバックアップ機能です。データベースもしくは表スペース単位でのバックアップが可能です。表単位ではバックアップできないので注意が必要です。

　可用性を求めるのであれば、オンラインバックアップを使用します。バックアップ方式は「フルバックアップ」と「増分バックアップ」。増分バックアップの場合は「累積」か「非累積」を選択します。ごく一般的な方法なので、詳しくはDB2のマニュアルを参照してください。

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/core/r0001933.htm

　この場合のリストアはもちろん、リストアコマンドを使います。

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/core/r0001976.htm

　ロギングの方式やバックアップのタイプによって、リストアコマンドのオプションも変わってくるので、運用を始める前に十分な確認が必要です。

　また、アーカイブ・ロギングを行っている場合は、リストア後にロールフォワードが必要になります。

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/core/r0001978.htm

■ローカル・コピー機能

　詳しくは次回の高可用性と災害対策の部分で解説しますが、ローカル・コピー機能はある時点でのディスク領域のコピーを丸ごと取って、データベースをバックアップする方法です。最近は、ディスク領域を高速にコピーする機能がオプションで用意されているストレージデバイスもあります。この高速コピー機能とローカル・コピー機能を組み合わせることで、可用性が高くしかも高速なバックアップが可能になります。

　高速コピー機能を使う際に注意が必要なのは、トランザクションがひっきりなしに続いている状態でディスクのコピーを取るのでは、トランザクションの整合性が取れなくなるということです。このような場合は、I/Oを止めてディスクの書き込みの静止点を取る必要があります。DB2には、set write suspend/resumeというコマンドが用意されています。これは、suspendが発行された時点でDB2からディスクへのI/Oを止め、DB2としてI/Oの静止点を取って整合性を保つというコマンドです。resumeコマンドが発行されるまで書き込みはできませんが、読み込みはできるのでSELECT文は実行可能です。

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/core/r0009503.htm

■リモート・コピー機能

　前述のローカル・コピー機能と基本的には同じです。違いは、同じマシン内ではなくマシン間（リモート）でコピーを行う点です。最近は、この方法を使った災害対策を意識したシステムも構築されています。

■ログ・シッピング

　ログ・シッピングは、FTPなどを使ってアーカイブ・ログをスタンバイサイトへ転送し、スタンバイサイトは転送されてきたログを適用して常にプライマリサイトに近い状態を保つ方式です。

データベースのロギングについて

　後回しになってしまいましたが、データベースロギングについて説明しておきます。DB2のロギングは、循環ログ方式と保存ログ（アーカイブ・ログ）方式に大別できます。

　循環ログ方式は文字通り、ログを循環式に利用する方式です。循環ログ方式では、オンラインバックアップができません。一方のアーカイブ・ログ方式は、クローズされたログを保存していく方式で、オンラインバックアップも可能です。

　どちらのログ方式を使用するかは、データベース構成パラメータのLOGRETAINで設定します。

　また、アーカイブ・ログ方式では、アーカイブ・ログを任意のディレクトリに保存し、リカバリ時に必要なログを取り出すUSEREXITプログラムを使用することもできます。USEREXITプログラムを使用するかしないかは、USEREXITパラメータで選択します。

　USEREXITプログラムは標準では提供されていませんが、サンプルが用意されているのでこれを編集して利用します。サンプルには、以下の4つがあります。

　コンパイルや使用方法はソースの中に書いてあります。例えば、ログをディスクに保存するサンプルを使う場合は適当なディレクトリにファイルをコピーして、230行目から236行目を編集します。

　このソースをコンパイルして、db2uext2というバイナリファイルを作成します。

　このバイナリを、$INSTHOME/sqllib/adm/db2uext2へコピーします。このパスは固定であり、変更することはできません。また、USEREXITプログラムはインスタンスで1つです。

◆

　今回は可用性を重視し、システムを止めることなくバックアップすることにポイントを置いて、データベースのバックアップ／リカバリについて解説しました。ただし、ローカル／リモートのコピー機能を使ったバックアップについては、まだ十分な説明ができていません。次回の高可用性と災害対策で詳しく説明したいと思います。

Index DB2マイスター養成講座 　第4回　止められないデータベースのバックアップ／リカバリ

Page 1 データベースの障害 データベースのリカバリに必要なものは？ 　データベース・ディレクトリー 　テーブルスペース・コンテナー 　ログ・ディレクトリ（アクティブ・ログ、アーカイブ・ログ） 　インスタンス・ホーム バックアップ／リカバリの方式 　クラッシュ・リカバリー 　DB2のバックアップ／リストアコマンド 　ローカル・コピー機能 　リモート・コピー機能 　ログ・シッピング データベースのロギングについて

連載 DB2マイスター養成講座

	連載：快速MySQLでデータベースアプリ！（全11回） 軽快な動作で知られるRDBMS、MySQLでDBアプリの構築を行う。MySQLのインストールに始まり、PerlやRubyなどのスクリプトでデータベースを操作する方法までを完全解説
	連載：今から始める MySQL入門（連載中） 定番のLAMP（Linux＋Apache＋MySQL＋PHP）構成でWebアプリケーション開発に挑戦！ サンプルアプリの構築を進めながら、基礎知識や操作方法について詳しく解説する
	連載：Oracleマイスター養成講座（全6回） 本連載では、Oracleの管理・チューニング方法を紹介していく。これからOracleを始める人、そしてOracleをより深く理解したい人のための、一歩踏み込んだ実用講座
	連載：DB2マイスター養成講座（全7回） 本連載では、DB2 UDBの実践的な運用・管理方法を紹介していく。DB2を利用するうえで必要な知識を、実運用を前提にDB2のプロが解説
	特集：エンタープライズ市場に向かうMySQL 5.0［前編］ MySQL 5.0の新機能をアルファ版でチェック 1月に公開された5.0アルファ版は大幅に拡張されており、エンタープライズ市場への進出を予感させる
	特集：Linuxで動くリレーショナルデータベース・カタログ データベースサーバのOSとしてLinuxを採用するケースが増えている。Linuxで動作する7つの主なリレーショナルデータベースを紹介する。製品導入の際の参考にしてほしい
	more

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード