目次


IBM DB2 ユニバーサル・データベース V7のサスペンド I/O を使用した分割ミラー

Comments

はじめに

e-business のグローバルな成長が続く中で、超大規模データベースを保守し高可用性を保証することは、真の無停止データ集中型ビジネスの成功に不可欠なニーズとなってきました。IBM DB2R ユニバーサル・データベース (UDB) バージョン 7 のサスペンド I/O 機能は、このような重大なニーズを満たすために、オンライン分割ミラー処理のインターフェースにシステムの連続可用性を提供します。DBA の観点から書かれた本書では、いくつかの重要な概念 (分割ミラー、サスペンド I/O、db2inidb) の定義を示し、DB2 UDB の見地からの分割ミラー処理の 3 つの異なる実装シナリオについて、手順を追って説明します。分割プロセス自体はベンダーによって異なるため、使用するシステムにおける分割ミラーの作成については、ストレージ・ベンダーの適切なマニュアルを参照してください。

主要概念

IBM DB2 ユニバーサル・データベースで分割ミラー・シナリオを実装するには、次の 3 つの概念を理解することが非常に重要です。

分割ミラー

分割ミラーは、ディスク・ボリュームとまったく同じ独立したコピーであり、異なるシステムに接続でき、テスト・システムをポピュレートしたり、データベースのウォーム・スタンバイ・コピーとして使用したり、1 次マシンからバックアップの負荷を取り除くなど、さまざまな用途に使用できます。分割ミラーに対するハードウェア固有の要件はありません。ただし、SharkTM として知られる IBM エンタープライズ・ストレージ・サーバー (ESS) や EMC® Symmetrix® 3330 などのようにインテリジェントなストレージ・デバイスを使用することを強く推奨します。FlashCopyTM テクノロジーを使用すれば、ESS はすべてそれ自身の中にデータのコピーを瞬時に作成できます。Symmetrix 上での EMC TimeFinder® ソフトウェアの Instant Split 機能は、同様の方式でミラーを分割できます。

データベースの分割ミラーには、データベース・ディレクトリーのコンテンツ全体と、表スペース・コンテナーのすべて、ローカル・データベース・ディレクトリー、および (データベース・ディレクトリー上に存在しない場合は) アクティブ・ログ・ディレクトリーを含みます。アクティブ・ログ・ディレクトリーが分割される必要があるのは、db2inidb ツールのスナップショット・オプションを使用してクローン・データベースを作成するためだけです。他の 2 つのオプションであるスタンバイとミラーには、アクティブ・ログ・ディレクトリーの分割は不要です。

分割ミラーのアクセスにはコピーは関係なく、ストレージ・ベンダーの実装方法に依存します。ユーザーはストレージ・ベンダーから提供される機能を使用して、分割ミラーをアクセスする必要があります。他の方法でアクセスすべきではありません。

サスペンド I/O

ミラーを分割する場合、ソース・データベースで部分ページ書き込みが発生しないことを保証することが重要です。これを保証する方法の 1 つが、データベースをオフラインにすることです。しかし、これにはシステム停止時間が必要となり、真の連続稼動環境では実効性のあるソリューションではありません。分割ミラー処理中にもシステムの連続可用性を実現するために、DB2 ユニバーサル・データベース バージョン 7 (FixPak 2) でサスペンド I/O という新機能が追加されました。サスペンド I/O 機能を使用すると、データベースをシャットダウンせずにオンラインで分割ミラー処理を実施できます。サスペンド I/O 機能は、ソース・データベース上でのすべての書き込み操作を延期 (サスペンド) することにより、一切の部分ページ書き込みを確実に回避できます。データベースが書き込み延期モードにある間、すべての表スペースの状態は新たな状態 SUSPEND_WRITE に変わり、すべての操作が正常に機能します。ただし、バッファー・プールから煩雑なページをフラッシュしたりログ・バッファーからログをフラッシュするなど、ディスク I/O を必要とするトランザクションは、待機する場合があります。これらのトランザクションは、データベースでの書き込み操作が再開されると正常に処理を続行します。ソース・データベース上での書き込み操作の延期または再開には、次のコマンドを使用します。

db2 set write <suspend | resume> for database

db2inidb ツール

サスペンド I/O 機能を使用して作成された分割ミラーは、使用可能な状態に初期化されるまでは、書き込み延期モードに留まります。分割ミラーの初期化用に、DB2 V7 FixPak 2 で db2inidb という新規ツールが追加されました。このツールは、db2inidb コマンドに指定するオプションに応じて、分割ミラー・イメージに対してクラッシュ・リカバリーを実施したり、分割ミラーをロールフォワード保留状態に置くことができます。db2inidb コマンドの構文は次のとおりです。

db2inidb <database_alias> as < snapshot |standby |mirror >
[ relocate using <config_file> ]

「snapshot」オプションは強制的に分割ミラーのクラッシュ・リカバリーを行い、「standby」または「mirror」オプションは、データベースをロールフォワード保留状態に置きます。FixPak 4 で追加された「relocate」オプションは、データベースに関連付けられたデータベース名、データベース・ディレクトリー・パス、コンテナー・パス、ログ・パス、およびインスタンス名に従って分割ミラーを再配置します。

サスペンド I/O と db2inidb の一般的使用法

サスペンド I/O 機能と db2inidb ツールの組み合わせは、分割ミラー・データベースを作動可能状態にするために必要です。db2inidb で提供される 3 つのオプション (snapshot、standby、mirror) の機能をサスペンド I/O 機能と併用することにより、データベースの高速スナップショットを作成でき、次のような用途に使用できます。

  • 最新データをコピーすることにより、テスト・システムをポピュレートする。
  • ウォーム・スタンバイとして使用可能なスタンバイ・データベースを作成する。
  • ロールフォワード保留状態にあるときに、(DMS のみの表スペースを含む) 分割ミラー・データベースのオフライン・バックアップを実施する。この機能はバージョン 7 FixPak 3 で追加されました。ロールフォワード保留状態にある場合、SMS 表スペースを含むデータベースのバックアップは現時点ではサポートされていません。
  • 迅速なファイル・システム・レベルのリカバリー・オプションを提供する。

サスペンド I/O 機能は、ミラーを分割する前にすべての DB2 データが着実にディスクに書き込まれること (つまり部分ページ書き込みがないこと) を保証するために必要です。これにより、db2inidb ツールを使用して後でデータベースを確実に回復できる状態を保証します。db2inidb ツールは、データベースのクラッシュ・リカバリーの実行を強制することも (snapshot オプションが指定された場合)、データベースをロールフォワード保留状態 (standby または mirror オプションが指定された場合) にして追加のログ・ファイル処理を実施することもできます。

実装シナリオ

次の 3 つの実装シナリオでは、db2inidb とサスペンド I/O をいかに併用できるかを示しています。

クローン・データベースを作成してテスト・システムをポピュレートする

次のシナリオは、サスペンド I/O 機能を使用して、ターゲット・システム上にクローン・データベースを作成する方法を示しています。このシナリオでは、分割ミラー・データベースには snapshot オプション付きの db2inidb ツールによって開始されるクラッシュ・リカバリーが実施されます。この方法で生成されたクローン・データベースは、本番システムに影響を与えずにテスト・データベースのポピュレートやレポートの生成に使用できます。クラッシュ・リカバリーされるため、クローン・データベースは新しいログ・チェインを開始します。したがって、ソース・データベースから先々のログ・ファイルを適用することはできません。このクローン・データベースから取得されたデータベース・バックアップは、ソース・データベースにリストアできます。ただし、分割後にソース・データベースで生成されたログ・レコードを通してロールフォワードはできません。したがって、バージョン・レベル・コピーのみになります。

ステップ1:ソース・データベースで I/O を延期する
次のコマンドは、部分ページ書き込みが発生することなくデータベース・コンテナーのミラーを分割できるように、ソース・データベースでの I/O (DB2 クライアントからのすべての書き込みアクティビティー) を延期 (サスペンド) します。データベース上での I/O を延期しても、データベースへの既存の接続を解除するわけではなく、すべての操作は正常に動作することに注意してください。ただし、ディスク I/O を必要とするトランザクションは待機する場合がありますが、データベースで I/O が再開されるとトランザクションの処理は正常に続行します。

     db2 connect to <source-database>
     db2 set write suspend for database

ステップ 2:ミラーを分割する
ミラーを分割する処理は、ベンダーによって異なります。分割ミラーの作成方法については、使用するデバイスに適切なストレージ・ベンダーのマニュアルを参照してください。分割ミラー処理のバリエーションには無関係に、次のすべてが同時に分割される必要があります。

  • データベース・ディレクトリーのコンテンツ全体
  • すべての表スペース・コンテナー
  • ローカル・データベース・ディレクトリー
  • アーカイブ・ログ・ディレクトリー (データベース・ディレクトリーに存在しない場合)

ステップ 3:ソース・データベースで I/O を再開する
次のコマンドは、ソース・データベースで I/O (DB2 クライアントからのすべての書き込みアクティビティー) を再開し、現在実行中のトランザクションの処理は正常に進行します。

重要:
write resume コマンドの発行には、db2 set write suspend コマンドの発行に使用されたのと同じデータベース接続が使われます。

      db2 set write resume for database

ステップ 4:分割ミラーをターゲット・マシンでアクセス可能にする
ミラーの分割後、ターゲット・マシンの管理者は、ストレージ・ベンダーからの機能を使用して、分割ミラー・コピーへのアクセスを提供する必要があります。その処理を「マウント」と呼びます。ターゲット・システムで次のステップを実施します。

  1. ソース・マシン上にあるのと同じデータベース・インスタンスを作成します。
  2. ON パラメーターを付けてデータベースをカタログします (システム・データベース・ディレクトリー)。
    db2 catalog database <database-name> as alias on <path> ......
  3. データベース・ディレクトリーをソース・マシンにあるのと同じディレクトリーにマウントします。
  4. すべてのコンテナーをソース・マシンにあるのと同じパスへマウントします。コンテナーがいくつかのディレクトリーに配置されていれば、すべてのコンテナー・ディレクトリーをマウントする必要があります。
  5. ログ・ファイルがデータベース・ディレクトリー以外のディレクトリーに配置されていれば、ログ・ディレクトリーをソース・マシンにあるのと同じディレクトリーにマウントします。

ステップ 5:ターゲット・マシン上でデータベース・インスタンスを開始する
ターゲット・マシン上でデータベース・マネージャーを起動します。DB2 レジストリー変数 DB2INSTANCE がソース・マシンと同じインスタンス名に設定されたと仮定すると、コマンドは単純に次のようになります。

     db2start

ステップ 6:クローン・データベースを一貫性のある状態にする
次のコマンドはクラッシュ・リカバリーを開始し、すべての非コミット・トランザクションをロールバックするので、データベースを一貫性のある状態にします。ソースからの、分割時点で活動状態にあった全ログ・ファイルを持つことが不可欠です。アクティブ・ログ・ディレクトリーには、分割ミラーの一部ではないログ・ファイルを含んではいけません。クラッシュ・リカバリーの完了後、新しいログ・チェインが開始されるので、データベースはソース・データベースからのログ経由でロールフォワードできません。

      db2inidb <target-database> as snapshot

スタンバイ・データベースを作成してウォーム・スタンドバイとして使用する

次のシナリオは、サスペンド I/O 機能を使用してターゲット・システム上にスタンバイ・データベースを作成する方法を示しています。ウォーム・スタンバイ・データベース・シナリオでは、ソース・データベースのログ・ファイルがターゲット (スタンバイ) データベースに適用されます。スタンバイ・データベースは、ロールフォワードが終わるまでロールフォワード保留状態に保たれます。クローン・データベース (DMS のみ) で取得された DB2 バックアップ・イメージは、ミラーの分割後にソース・データベース上で作成されたログ・ファイルを使用してロールフォワード・リカバリーを実施する目的で、ソース・データベース上でリストアに使用できます。

ステップ1:ソース・データベースで I/O を延期
次のコマンドは、部分ページ書き込みが発生することなくデータベース・コンテナーのミラーを分割できるように、データベース上での I/O (DB2 クライアントからの全書き込みアクティビティー) を延期 (サスペンド) します。データベース上で I/O を延期しても、そのデータベースへの既存接続を解除するわけではなく、すべての操作は正常に機能することに注意してください。ただし、ディスク I/O を必要とするトランザクションは待機する場合がありますが、データベースで I/O が再開されるとすぐに、トランザクションの処理は正常に続行します。

     db2 connect to <source-database>
     db2 set write suspend for database

ステップ2:ミラーを分割する
ミラーを分割する処理は、ベンダーによって異なります。分割ミラーの作成方法については、使用するデバイスに適切なストレージ・ベンダーのマニュアルを参照してください。分割ミラー処理のバリエーションには無関係に、次のすべてが同時に分割される必要があります。

  • データベース・ディレクトリーのコンテンツ全体
  • すべての表スペース・コンテナー
  • ローカル・データベース・ディレクトリー

この場合は、アクティブ・ログ・ディレクトリーを分割する必要はありません。

ステップ 3:ソース・データベースで I/O を再開する
次のコマンドは、ソース・データベース上で I/O (DB2 クライアントからのすべての書き込みアクティビティー) を再開し、現在実行中のトランザクションは正常に処理が続行します。

重要:
write resume コマンドを発行するには、db2 set write suspend コマンドの発行に使用したのと同じデータベース接続が使用されます。

db2 set write resume for database

ステップ 4:ターゲット・マシン上で分割ミラーをアクセス可能にする
ミラーの分割後、ターゲット・マシンの管理者は、ストレージ・ベンダーからの機能を使用して、分割ミラー・コピーへのアクセスを提供する必要があります。その処理を「マウント」と呼びます。ターゲット・システムで次のステップを実施します。

  1. ソース・マシン上にあるのと同じデータベース・インスタンスを作成します。
  2. ON パラメーターを付けてデータベースをカタログします (システム・データベース・ディレクトリー)。
    db2 catalog database <database-name> as alias on <path> ......
  3. データベース・ディレクトリーをソース・マシンにあるのと同じディレクトリーにマウントします。
  4. すべてのコンテナーをソース・マシンにあるのと同じパスへマウントします。コンテナーがいくつかのディレクトリーに配置されていれば、すべてのコンテナー・ディレクトリーをマウントする必要があります。
  5. ログ・ファイルがデータベース・ディレクトリー以外のディレクトリーに配置されていれば、ログ・ディレクトリーをソース・マシンにあるのと同じディレクトリーにマウントします。

ステップ 5:ターゲット・マシン上でデータベース・インスタンスを開始する
ターゲット・マシン上でデータベース・マネージャーを起動します。DB2 レジストリー変数 DB2INSTANCE がソース・マシンと同じインスタンス名に設定されたと仮定すると、コマンドは単純に次のようになります。

db2start

ステップ 6:データベースをロールフォワード・モードにする
次のコマンドは、分割ミラー・データベースを「ロールフォワード保留」状態にします。クラッシュ・リカバリーは実施されず、データベースは一貫性のない状態に留まります。

db2inidb <target database> as standby

ステップ 7:ログ・ファイルの上に継続的にコピーしてロールフォワードする
データベースが「ロールフォワード保留」状態にされた後、ソース・データベースからのログ・ファイルを、ターゲット・データベースのロールフォワードに使用できます。ユーザーEXITプログラムを使用して、非活動状態のログ・ファイルの継続的アーカイブを自動化できます。ユーザーEXITを使用する場合、ソースとターゲットの両データベースは同じユーザーEXITプログラムで構成される必要があります。

db2 rollforward db <target-database> to end of logs

ステップ 8:スタンバイ・データベースを活動化する
ソース・データベースがクラッシュした場合、ターゲット・マシン上のスタンバイ・データベースをユーザー・アクセス用に活動化できます。スタンバイ・データベースを活動化するには、スタンバイ・データベースのロールフォワード保留状態を終える必要があります。これには、「stop」または「complete」オプションを付けて rollforward コマンドを発行し、データベースを一貫性のある状態にします。データベースが一貫性のある状態になると、ユーザーはスタンバイ・データベースを切り替えて作業を続行できます。ユーザー・アプリケーションはこのスタンバイ・データベースへ新たに接続する必要があります。スタンバイ・データベースで生成されたログ・ファイルは、ソース・データベースには適用できません。

ターゲット・データベースがロールフォワード保留状態にある間に、データベースの表スペースが DMS のみであれば、オフライン・バックアップを実施できます。この機能はバージョン 7 FixPak 3 で導入されました。

db2 rollforward db <target-database> stop

迅速なミラー・ファイル・リカバリー用にミラー・データベースを作成する

次のシナリオは、サスペンド I/O 機能を使用して、ターゲット・システム上にミラー・データベースを作成する方法を示しています。このオプションの目的は、分割ミラー・コピーを使用してソース・データベースの上にリストアし、そのソース・データベースのログ・ファイルをロールフォワードする手段を提供することです。ここで注意すべき重要事項は、分割ミラーはソース・データベースの上にコピーするまでは、SUSPEND_WRITE 状態に留まるべきであるということです。

ステップ1:ソース・データベース上で I/O を延期する
次のコマンドは、部分ページ書き込みが発生することなくデータベース・コンテナーのミラーを分割できるように、データベース上での I/O (DB2 クライアントからの全書き込みアクティビティー) を延期します。データベース上で I/O を延期しても、そのデータベースへの既存接続を解除するわけではなく、すべての操作は正常に機能することに注意してください。ただし、ディスク I/O を必要とするトランザクションは待機する場合がありますが、データベースで I/O が再開されるとすぐに、トランザクションの処理は正常に続行します。

db2 connect to <source-database>
db2 set write suspend for database

ステップ2:ミラーを分割する
ミラーを分割する処理は、ベンダーによって異なります。分割ミラーの作成方法については、使用するデバイスに適切なストレージ・ベンダーのマニュアルを参照してください。分割ミラー処理のバリエーションには無関係に、次のすべてが同時に分割される必要があります。

  • データベース・ディレクトリーのコンテンツ全体
  • すべての表スペース・コンテナー
  • ローカル・データベース・ディレクトリー

この場合は、アクティブ・ログ・ディレクトリーを分割する必要はありません。

ステップ 3:ソース・データベースで I/O を再開する
次のコマンドは、ソース・データベース上で I/O (DB2 クライアントからのすべての書き込みアクティビティー) を再開し、現在実行中のトランザクションは正常に処理が続行します。

重要:
write resume コマンドを発行するには、db2 set write suspend コマンドの発行に使用したのと同じデータベース接続が使用されます。

db2 set write resume for database

ディスク障害発生後に分割ミラー・イメージをリストアする

このシナリオには「ターゲット」データベースはありません。このシナリオの意図は、ミラー・コピーを使用して「ソース」データベースの上にリストアし、ディスク障害から回復することです。分割ミラーは DB2 バックアップ・ユーティリティーではバックアップできませんが、オペレーティング・システムのツールを使用してバックアップできます。ソース・データベースがクラッシュした場合、分割ミラー・イメージをソース・データベースの上にコピーすることによってリストアできます。

ステップ1:ソース・データベースのインスタンスを終了する
次の DB2 コマンドを使用して、データベース・インスタンスをシャットダウンします。

db2stop

ステップ2:分割ミラー・イメージをリストアする
ストレージ・ベンダーのユーティリティーを使用して、分割ミラー・データベースのデータ・ファイルをオリジナル・データベースの上からコピーします。この場合、オペレーティング・システムには分割イメージの知識は一切ないので、オペレーティング・システムのユーティリティーは使わないでください。

ステップ 3:ソース・データベース・インスタンスを起動する
分割ミラー・イメージをリストアした後で、ソース・データベース・インスタンスを起動します。

db2start

ステップ4:ソース・データベースのミラー・コピーを初期化する
このステップは、ソース・データベースをそのデータベースのミラー・コピーで置き換え、それをロールフォワード保留状態にします。クラッシュ・リカバリーは開始されず、データベースはログの終わりまでロールフォワードされるまでは、一貫性のない状態になります。

db2inidb <database> as mirror

ステップ 5:ログの最後までロールフォワードする
ソース・データベースからのログ・ファイルは、データベースのロールフォワードの実施に使用する必要があります。

db2 rollforward database  <database> to end of logs and complete

区分化環境の扱い

複数区画に区分化された環境では、各区画は別個のデータベースとして扱われます。したがって、分割ミラー処理中は、各区画での I/O を延期 (サスペンド) する必要があります。そしてもちろん、I/O は各区画で再開される必要があります。db2inidb ツールについても同じです。db2inidb は、データベースを使用する前に各ミラー区画で実行される必要があります。

各区画は別個のデータベースとして扱われるので、すべてのノードは相互に依存せずに延期できます。したがって、db2_all を発行して全ノードで I/O を延期する必要はありません。ただし、各ノードが別々に延期される場合、カタログ・ノードを最後に延期する必要があります。複数区画のデータベースでは、カタログ・ノード以外のいずれかのノードで I/O の延期を試みるには、カタログ・ノードに接続して許可を得る必要があます。カタログ・ノードが延期されていれば、接続の試みはハングしてしまいます。

推奨事項:
複数区画に区分化されたデータベースで I/O を延期するには、すべてのノードで別々に「set write suspenc」を発行し、カタログ・ノードを最後に延期します。これは、I/O は他のノードに影響を与えずに延期できることを意味します。

db2inidb ツールはデータベースへの接続を一切必要としません。したがって、各分割コピーでツールを別個に実行できます。また、db2_all を使用して、全区画で同時に実行することもできます。唯一の要件は、データベース・マネージャーが起動されることです。

例:
AIX 上の複数区画データベースが 4 つのデータベース区画 (0、1、2、3) を持ち、カタログ区画が 0 の場合、I/O を延期するために推奨されるコマンドは、次のとおりです。

export DBNODE=1; db2 terminate;
db2 "connect to <database-alias>"; db2 "set write suspend  for database"

export DBNODE=2; db2 terminate;
db2 "connect to <database-alias>"; db2 "set write suspend  for database"

export DBNODE=3; db2 terminate;
db2 "connect to <database-alias>"; db2 "set write suspend  for database"

export DBNODE=0; db2 terminate;
db2 "connect to <database-alias>"; db2 "set write suspend  for database"

例:
全データベース区画で db2inidb を同時に実行します。

db2_all "db2inidb <target-database> as <options>"

同一マシン上で分割ミラーを再配置する

分割ミラー・データベースはデータベース・ディレクトリー・パス、コンテナー・パス、およびログ・ディレクトリー・パスに依存するので、このパス情報が再構成されない限り、1 つのデータベースを分割して同一マシンに置くことはできません。データベースを分割する場合、データベース・ディレクトリー、コンテナー、およびログ・ディレクトリーは明らかに新しいパスに再配置されます。これらすべてを同一マシン上の新規ディレクトリーへ移動するとしたら、データベースは始動時にそれらを認識できなくなります。ターゲット・システムの起動時にも、インスタンス所有者のユーザー ID とグループ ID など、 DB2 インスタンスの設定がソース・マシンと同一であると想定されます。

DB2 UDB V7 の FixPak 4 で、db2inidb の新規オプション「relocate」が追加されました。relocate オプションを使用すると、データベース名、データベース・ディレクトリー・パス、コンテナー・パス、ログ・パス、およびそのデータベースと関連付けられたインスタンス名を変更できます。この新規オプションにより、同一マシン上でミラーを分割できます。

relocate オプションを使用するには、オリジナル・データベースの構成情報と分割ミラー・データベースの再配置に必要な構成情報 (予定) を含む入力テキスト・ファイルを提供する必要があります。relocate オプションは db2relocatedb コマンドをバックグラウンドで起動するので、構成ファイルのオプションに関する詳細は、Fixpak 4 のリリース情報の「db2relocatedb (新規コマンド)」の項を参照してください。

構成ファイルの形式を簡単に示すと、次のとおりです。

DB_NAME=oldName,newName
DB_PATH=oldPath,newPath
INSTANCE=oldInst,newInst
NODENUM=nodeNumber
LOG_DIR=oldDirPath,newDirPath
CONT_PATH=oldContPath1,newContPath1
CONT_PATH=oldContPath2,newContPath2

relocate を使用した db2inidb コマンドの構文は次のとおりです。

db2inidb <target-database> as <options> relocate using <config-file>

結論

DB2 ユニバーサル・データベースのサスペンド I/O 機能を、さまざまなインテリジェント・ストレージ・デバイスの分割ミラー機能と組み合わせると、次の事柄が実現されて、真の連続運用可能な超大規模の基幹データベースを実装できます。

  • 停止時間が「0」のシステム連続可用性
  • 超大規模データベースのための超高速のバックアップおよび災害時リカバリー方式
  • 本番データベースからバックアップの負荷を取り除く機能
  • 本番データベースに与える影響を最小化する
  • 現行データのコピーする、テスト・データベースの高速ポピュレーション

謝辞

本書のテクニカル・レビューをしていただいた Dale McInnis 氏と Jason Racicot 氏に感謝します。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=326483
ArticleTitle=IBM DB2 ユニバーサル・データベース V7のサスペンド I/O を使用した分割ミラー
publish-date=042002