第7章ミニコピーによるデータのバックアップ (Integrity および Alpha)

この章では，OpenVMS バージョン 7.3 から導入された Volume Shadowing for OpenVMS のミニコピー機能を説明します。ミニコピーとそれを実現するテクノロジであるビットマップは， OpenVMS Integrity および OpenVMS Alpha システムに完全に実装されています。 OpenVMS VAX ノードでは，この機能を使っているシャドウセットに書き込みはできますが，マスタ・ビットマップを作成したり，DCL コマンドで管理することはできません。 OpenVMS Alpha Cluster システムでミニコピーを使うためには，Alpha システムを 1 台だけ必要とします。

ミニコピーの主な目的は，シャドウセット・メンバをシャドウセットに戻す時間を短縮することです。通常，シャドウセット・メンバを削除するのはデータのバックアップのためであり，それがすむとシャドウセットのメンバに戻します。

7.1 ミニコピーとは何か

ミニコピー操作は，コピー操作を効率化したものです。ビットマップはシャドウセットへの書き込みを追跡し，シャドウセット・メンバをシャドウセットに戻す際のミニコピー操作を指示するために使われます。デバイスの内容全体をコピーするのではなく，ビットマップにより認識される変更済みブロックのみがコピーされます。シャドウセット・メンバがシャドウセットに戻されたとき，そのメンバのデータとシャドウセットのデータが同一になることがミニコピーによって保証されます。

シャドウセット・メンバを削除する前は，図 7-1 「アプリケーションによるシャドウセットへの書き込み」に示すように，アプリケーションからの書き込みは直接シャドウセット (仮想ユニットとも言う) に送られます。

図 7-1 アプリケーションによるシャドウセットへの書き込み

シャドウセット・メンバをディスマウントするときにミニコピー修飾子 (/POLICY=MINICOPY[=OPTIONAL]) を指定すると，ビットマップが作成されます。シャドウセットへのその後の書き込みは，ビットマップに記録されます。ビットマップへの記録は，対応する書き込みの論理ブロック番号 (LBN) だけで，内容ではないことに注意してください。アドレスは，ビットマップに 1 つ以上のビットを設定することで表現されます。各々のビットは 127 ディスク・ブロックの範囲に対応します。

データが 127 ブロックの範囲のどこかのブロックに書き込まれると，その範囲に対応するビットマップのビットが設定されます。ビットが設定されると，そのデータが，図 7-2 「アプリケーションによるビットマップへの書き込み」に示すように，シャドウセットに書き込まれます。

図 7-2 アプリケーションによるビットマップへの書き込み

メンバをシャドウセットを戻すとき，ビットマップは，図 7-3 「シャドウセット (仮想ユニット) に戻されるメンバ」に示すようにミニコピー操作の指示のために使われます。ミニコピー操作が行われている間でも，アプリケーションはシャドウセットの読み書きを継続できます。

図 7-3 シャドウセット (仮想ユニット) に戻されるメンバ

システム管理者が 7.11 項「バックアップ用にシャドウセット・メンバを使う際のガイドライン」のガイドラインに従っている限り，ミニコピー機能を使うと，メンバをシャドウセットに戻す際のフルコピーは不要になります。この章では，コピーとフルコピーは同じ意味で使っていることに注意してください。

いくつかの DCL コマンドを，ビットマップの管理のために使うことができます。 OpenVMS Cluster システムでのビットマップの更新の管理や，ノードごとのシャドウセットの上限数を設定するためのシステム・パラメータが用意されています。

7.2 コピーとミニコピーの異なる使い方

ミニコピーが導入される前は，コピー操作は 2 つの目的で使われていました。仮想ユニットにメンバを追加するのと，削除されたメンバを元のシャドウセットに戻すためです。メンバを仮想ユニットに戻すためには，そのメンバのデータをシャドウセットのデータに一致させなければなりません。

コピー操作は，複数メンバ・シャドウセットを作成するための代表的な方法です。 (DCL コマンド INITIALIZE/SHADOW を使用して，空の複数メンバ・シャドウセットを作成することもできます。) メンバをシャドウセットに戻す場合は，コピー操作よりもミニコピー操作の方が優れています。

通常，シャドウセット・メンバを削除する目的は，データをテープやディスクにバックアップするためです。

シャドウセット・メンバをバックアップ操作で使うためには，システム管理者は次の手順に従う必要があります。

SHOW DEVICE コマンドを使って，仮想ユニットにマージ操作がマークされていないことを確認します。
アプリケーションの入出力を止めます。
止める方法は，アプリケーションやコンピューティング環境に依存します。
シャドウセット・メンバを削除します。
アプリケーションを再起動します。
シャドウセット・メンバのデータをディスクやテープにバックアップします。
バックアップを行っている間，アプリケーションはシャドウセットの残りのメンバにデータを書き込みます。
バックアップが完了したら，シャドウセット・メンバをシャドウセットに戻します。




	注意: この形式のバックアップがサポートされる条件についての詳細は， 7.11 項「バックアップ用にシャドウセット・メンバを使う際のガイドライン」を参照してください。

7.3 ミニコピーを使う理由

ミニコピー操作は，システム管理者の意志で，システム管理者が決めた時間に使うことができます。

ミニコピーを使うと，シャドウセットにメンバを戻すために要する時間が著しく短縮されるため，システム管理者が行うシャドウセット・メンバの削除と復元を柔軟に計画することができ，可用性が向上します。

ミニコピーの実行に要する時間は，ディスクを外していた間にシャドウセットに加えられた変更の量に比例します。コピー時間が短縮されることで，バックアップの管理が容易になります。

表 7-1 「ミニコピーとフルコピーの性能比較」には一連のテスト結果を示しています。ここではシャドウセットに多様な書き込みが行われたときのフルコピーとミニコピーに要する時間の比較を行っています。表 7-1 「ミニコピーとフルコピーの性能比較」と表 7-2 「ミニコピーとハードウェア補助付き (DCD) コピーの性能比較」は，ミニコピーを使ったときに得られる性能向上の目安として参考にしてください。

表 7-1 ミニコピーとフルコピーの性能比較

設定されているビットの割合	フルコピーの時間 (秒)	ミニコピーの時間 (秒)	フルコピーの時間に対するミニコピーの時間の割合
100%	4196.09	3540.21	84.4%
90%	3881.95	3175.92	81.8%
80%	3480.50	2830.47	81.3%
75%	3290.67	2614.87	79.5%
70%	3194.05	2414.03	75.6%
60%	2809.06	2196.60	78.2%
50%	2448.39	1759.67	71.9%
40%	2076.52	1443.44	69.5%
30%	1691.51	1039.90	61.5%
25%	1545.94	775.35	50.2%
20%	1401.21	682.67	48.7%
15%	1198.80	554.06	46.2%
10%	1044.33	345.78	33.1%
5%	905.88	196.32	21.7%
2%	712.77	82.79	11.6%
1%	695.83	44.90	6.5%

表 7-2 「ミニコピーとハードウェア補助付き (DCD) コピーの性能比較」は，別の一連のテストの結果です。多様な書き込みについて，ハードウェア補助付きコピー (HSJ コントローラで MSCP ディスク・コピー・データ (DCD) コマンドを使用) とミニコピーに要求する時間を比較しています。

表 7-2 ミニコピーとハードウェア補助付き (DCD) コピーの性能比較

設定されているビットの割合	DCD コピーの時間 (秒)	ミニコピーの時間 (秒)	DCD コピーの時間に対するミニコピーの時間の割合
100%	1192.18	1181.61	99.1%
90%	1192.18	1097.03	92.0%
80%	1192.18	979.06	82.1%
70%	1192.18	862.66	72.4%
60%	1192.18	724.61	60.8%
50%	1192.18	627.24	52.6%
40%	1192.18	490.70	41.2%
30%	1192.18	384.45	32.3%
20%	1192.18	251.53	21.1%
10%	1192.18	128.11	10.7%
5%	1192.18	71.00	6.0%
0%	1192.18	8.32	0.7%

7.4 ミニコピーを使う手順

ミニコピー操作を使うには，以下の手順に従います。

ビットマップを開始します。
ビットマップは，シャドウセットからメンバを削除するときに， DISMOUNT コマンドに新しい修飾子 /POLICY=MINICOPY[=OPTIONAL] を指定すると開始されます。 7.6.3 項「MOUNT でのビットマップの作成」で説明するように， 1 つまたは 2 つ少ない数のメンバをシャドウセットにマウントするために， MOUNT コマンドを使っても，ビットマップが開始されます。
シャドウセット・メンバをシャドウセットに戻すときに，ミニコピー操作のためにビットマップを使います。
そのシャドウセット用のビットマップが存在する場合，ミニコピー操作は，デフォルトで次の MOUNT コマンドで起動されます。
$ MOUNT DSA42/SHAD=$4$DUA42 volume-label
ミニコピーだけが実行されるようにするには，次の例に示すとおり， /POLICY=MINICOPY 修飾子を使います。
$ MOUNT DSA42/SHAD=$4$DUA42 volume-label/POLICY=MINICOPY
ミニコピーのためのビットマップが存在しない場合は，マウントは失敗します。
ミニコピー操作が完了すると，そのディスクに対応するビットマップは消去されます。

MOUNT および DISMOUNT コマンドの /POLICY=MINICOPY[=OPTIONAL] 修飾子の使い方の詳細は，7.6 項「ビットマップの作成」と 7.7 項「ミニコピー操作の開始」を参照してください。

7.5 ミニコピーの制限事項

以下は，ミニコピーを使う場合の制限です。

OpenVMS Cluster 内のすべてのノードが，OpenVMS Alpha バージョン 7.2--2， OpenVMS バージョン 7.3 (以降)，またはこれらのバージョンの組み合わせのいずれかで稼働している場合にだけ，クラスタ内でミニコピーを使用することができます。クラスタ内でこれらよりも前のバージョンの OpenVMS を使おうとすると，ミニコピー機能は使用できなくなります。
ビットマップは一度しか使えません。
たとえば，ディスマウントされた 3 メンバ (D1，D2，D3) のシャドウセットがある場合，D1 だけを /POLICY=MINICOPY[=OPTIONAL] 修飾子を指定してマウントし直すと，ビットマップが作成されます。このシャドウセットに D2 を戻そうとすると，自動的にミニコピーが実行されます。そして残りのメンバ D3 をシャドウセットにマウントすると，今度はフルコピー操作が実行されます。
この最後のメンバ D3 のフルコピーを避けるためには，/POLICY=MINICOPY を指定して，シャドウセット・メンバを一度に 1 つずつディスマウントします。こうすれば，シャドウセットのメンバごとにビットマップを用意できます。各々のディスクをシャドウセットに戻すとき，それぞれにミニコピーが可能になります。
1 つの MOUNT コマンドで 2 つのメンバを指定すると，どちらのメンバがミニコピー操作でアップデートされるか優先度をつけることはできません。
ミニコピーが即座に行われるようにするためには，各々の MOUNT コマンドで， 1 つのシャドウセット・メンバだけを指定します。そしてミニコピーが開始されるのを待ち，別の MOUNT コマンドで次のメンバを追加します。
ボリューム・シャドウイング・ソフトウェアによって，シャドウセットに既にマージ操作がマークされている場合，マージ操作が行われ，ビットマップは作成されません。
仮想ユニットがディスマウントされたときに，仮想ユニットの未使用のビットマップがメモリに残ります。仮想ユニットが再びマウントされると，自動的に削除されます。
7.9.4 項「ビットマップの削除」で説明するように，余分なビットマップは，DELETE コマンドで削除できます。
間違いやすいエラー・メッセージ
ビットマップを開始してシャドウセット・メンバを (DISMOUNT/POLICY=MINICOPY[=OPTIONAL] を指定して) ディスマウントしようとすると，シャドウセット・メンバでマージ操作が実行中か，コピーのターゲットになっている場合，次のエラー・メッセージが表示されます。
%DISM-F-SRCMEM, only source member of shadow set cannot be dismounted
ミニコピーの将来のバージョンでは，もっとわかりやすいエラー・メッセージに変更される予定です。
マスタ・ビットマップを 1 つ以上持っているノードがシステム・ダウンあるいはクラッシュすると，そのノード上のビットマップは抹消されます。したがって，マスタ・ビットマップが抹消されたシャドウセットは，ミニコピー操作ができなくなります。その代わりにフルコピーが実行されます。
シャドウセット・メンバがエラーやタイムアウトでシャドウセットから切り離されると，ビットマップは使えなくなります。ビットマップはシャドウセット・メンバが明示的にディスマウントされたときだけ，ミニコピーで使うことができます。
OpenVMS Alpha バージョン 7.2–2 または 7.3 が稼働しているシステムでは，シャドウセットにメンバを戻すためにミニコピー操作が使われたシステム・ディスク・シャドウセット内のダンプ・ファイルにアクセスするには，追加の手順が必要です。詳細は，1.4.3.1 項「ミニコピーが使われた場合の，シャドウ化されたシステム・ディスクのダンプ・ファイルの取得 (Alpha のみ)」を参照してください。

7.6 ビットマップの作成

ビットマップの作成には，DCL コマンドの DISMOUNT と MOUNT が使われます。MOUNT コマンドは，ビットマップを使ったミニコピー操作を開始するためにも使われます (7.7 項「ミニコピー操作の開始」を参照)。

7.6.1 書き込みビットマップと異種デバイス・シャドウイング (DDS) の注意事項

OpenVMS Version 7.3-2 で導入された DDS を使用すると，異なるサイズのディスク・デバイスからなるシャドウ・セットを構築できます。

書き込みビットマップは，完全コピーのオーバヘッドなしでメンバを仮想ユニットに戻せるように，シャドウ・セットの仮想ユニットに対して行われたアプリケーションの書き込みを追跡します。ユーザがシャドウ・セット・メンバに対して DISMOUNT/POLICY=MINICOPY コマンドを実行した場合や，MOUNT/POLICY=MINICOPY コマンドを使用してシャドウ・セットをマウントした場合に，書き込みビットマップが作成されます。このビットマップが作成されるときのサイズは，ボリュームの現在のサイズに依存します。

シャドウ・セットがマウントされるとき，そのシャドウ・セットの仮想ユニットの論理サイズは，最小のメンバ・ユニットのサイズになります。シャドウ・セットのメンバが削除された場合，仮想ユニットの論理サイズは，セット内に残っているメンバのサイズをもとにして，再計算されます。その結果，仮想ユニットの論理サイズは，大きくなることがあります。

シャドウ・セットに書き込みビットマップが作成されるとき，そのサイズは，シャドウ・セットの仮想ユニットの現在のサイズによって決まります。仮想ユニットのサイズが後で大きくなると，ビットマップは仮想ユニット全体をカバーできなくなります。その後，ビットマップを使用してミニコピー操作でシャドウ・セット・メンバを戻すと，仮想ユニット内でビットマップがカバーしていない部分は，フルコピー操作でコピーされます。

この問題を，次の例で説明します。

シャドウ・セット DSA1: は，次の 3 つのメンバから構成されます。
$1$DGA20: (18 GB)
$1$DGA21: (36 GB)
$1$DGA22: (36 GB)
次のコマンドを使用して，ミニコピー・ビットマップ付きで，シャドウ・セットから $1$DGA22: を削除します。
$ DISMOUNT/POLICY=MINICOPY $1$DGA22:
書き込みビットマップのサイズは，シャドウ・セットの仮想ユニットの現在のサイズである 18 GB をもとにして決められます。
$1$DGA20: をシャドウ・セットから削除します。ファイル・システムで残りのメンバの 36 GB 全体を利用できるようにするには，次のコマンドを使用します。
$ SET VOLUME/SIZE DSA1
$1$DGA20 は新しいボリューム・サイズよりも小さいため，このシャドウ・セットでは使用できなくなります。
次のコマンドを使用して，$1$DGA22: をシャドウ・セットに戻します。
$ MOUNT/SYSTEM DSA1:/SHADOW=$1$DGA22: label
DSA1: の論理サイズは 36 GB のままですが，ビットマップがカバーしているのは，最初の 18 GB だけです。
$1$DGA22: の最初の 18 GB はミニコピー・ビットマップを使用してコピーされ，残りの 18 GB は，フルコピー操作でコピーされます。

小さいシャドウ・セット・メンバの削除を予定している場合は，ミニコピー・ビットマップ付きで大きなシャドウ・セット・メンバを削除する前に小さいメンバを削除すれば，大きなビットマップが作成され，短いビットマップで性能へ悪影響を及ぼすのを避けることができます。上記の例では，$1$DGA22: を削除する前に $1$DGA20: を削除します。

7.6.2 DISMOUNT でのビットマップの作成

DISMOUNT コマンドでビットマップを作成するには， /POLICY=MINICOPY[=OPTIONAL] 修飾子を指定します。 /POLICY=MINICOPY=OPTIONAL を指定すると，十分なメモリがあれば，ビットマップが作成されます。ビットマップが作成されたかどうかにかかわらず，ディスクはディスマウントされます。

次の例は， DISMOUNT コマンドの /POLICY=MINICOPY=OPTIONAL 修飾子の使い方を示しています。

$ DISMOUNT $4$DUA1 /POLICY=MINICOPY=OPTIONAL

このコマンドは，シャドウセットから $4$DUA1 を削除し，可能ならば，ビットマップへのログの書き込みを開始します。

/POLICY=MINICOPY とだけ (すなわち，=OPTIONAL を省略) 指定して，ノードにビットマップを作成するのに十分なメモリがなかった場合は，ディスマウントは失敗します。

7.6.3 MOUNT でのビットマップの作成

以下の条件のとき，MOUNT コマンドでビットマップを作成できます。

以前マウントされていたシャドウセットが，正しくディスマウントされていた。
複数メンバのシャドウセットは，以前のマウントでは，同一のノード，同一クラスタの別のノード，あるいは，クラスタ外の別のノードに，マウントされていなければなりません。
シャドウセットをマウントしようとしているノードがクラスタに組み込まれている場合，そのシャドウセットは現在，クラスタ内のどのノードにもマウントされていない。
シャドウセットをマウントするとき，1 メンバ少なくしてマウントする。
MOUNT コマンドで /POLICY=MINICOPY[=OPTIONAL] 修飾子を指定する。

このコマンドで作成されるビットマップは，後でシャドウセットの以前のメンバをシャドウセットにマウントするときに，ミニコピー操作で使われます。

/POLICY=MINICOPY=OPTIONAL 修飾子を指定したときに，シャドウセットがクラスタ内の別のノードに既にマウントされていた場合， MOUNT コマンドは成功しますが，ビットマップは作成されません。

7.7 ミニコピー操作の開始

シャドウセット・メンバにビットマップが存在する場合，シャドウセットにシャドウセット・メンバを戻すために MOUNT コマンドを実行すると，デフォルトでミニコピー操作が開始されます。これは， MOUNT コマンドに /POLICY=MINICOPY=OPTIONAL 修飾子を指定したのと同じです。ビットマップが存在しない場合，フルコピーが行われます。

MOUNT コマンドで /POLICY=MINICOPY=OPTIONAL 修飾子を使う例は，次のとおりです。

$ MOUNT DSA5/SHAD=$4$DUA0/POLICY=MINICOPY=OPTIONAL volume-label

シャドウセット (DSA5) が既にマウントされていて，このシャドウセット・メンバ ($4$DUA0) にビットマップが存在している場合，このコマンドでは，ミニコピー操作によって，デバイス $4$DUA0 がシャドウセットに追加されます。ビットマップが存在していない場合，このコマンドはフルコピーで $4$DUA0 を追加します。

ミニコピー操作が行われるときだけ MOUNT コマンドを成功させたいときは， /POLICY=MINICOPY とだけ (つまり，=OPTIONAL を省略) 指定します。この場合，ビットマップが使えなければ，マウントは失敗します。

7.8 マスタおよびローカルのビットマップ

OpenVMS Cluster システムでは， マスタ・ビットマップ は，ビットマップを作成する DISMOUNT や MOUNT のコマンドを発行したノードに作成されます。マスタ・ビットマップが作成される際に，シャドウセットがマウントされているクラスタ内のすべてのノードでは，ノードにメモリが十分あれば， ローカル・ビットマップ が自動的に作成されます。

マスタ・ビットマップには，シャドウセットをマウントしているクラスタ内のすべてのノードでのシャドウセットへの書き込みがすべて記録されます。ローカル・ビットマップには，ローカル・ノードでのシャドウセットへの書き込みがすべて記録されます。

ローカル・ビットマップを持つノードがシャドウセットの同じ論理ブロック番号 (LBN) へ複数回書き込みを行っても，最初の書き込みの LBN だけがマスタ・ビットマップに送られることに注意してください。ミニコピー操作では，LBN がアップデートされた事実だけを使い，その LBN が変更された回数は使いません。

ローカル・ビットマップを作成するための十分なメモリがノードに存在しない場合，そのノードは，書き込みのたびにメッセージを直接マスタ・ビットマップに送ります。これにより，アプリケーションの書き込み性能が落ちます。

7.9 DCL コマンドによるビットマップの管理

SHOW DEVICE，SHOW CLUSTER，および DELETE のコマンドが，ビットマップを管理するために機能拡張されました。

7.9.1 ビットマップのサポートと動作の調査

あるシャドウセットにビットマップが存在するかどうかは， DCL コマンドの SHOW DEVICE/FULL device-name で調べることができます。シャドウセットがビットマップをサポートしていれば，device supports bitmaps が， bitmaps active と no bitmaps active のいずれかとともに，表示されます。デバイスがビットマップをサポートしていなければ，ビットマップについてのメッセージは何も表示されません。

以下のコマンド例は，どのビットマップもアクティブでないことを示しています。

$ SHOW DEVICE/FULL DSA0

Disk DSA0:, device type RAM Disk, is online, mounted, file-oriented device,
    shareable, available to cluster, error logging is enabled, device supports
    bitmaps (no bitmaps active) .

    Error count                    0    Operations completed                 47
    Owner process                 ""    Owner UIC                      [SYSTEM]
    Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
    Reference count                2    Default buffer size                 512
    Total blocks                1000    Sectors per track                    64
    Total cylinders                1    Tracks per cylinder                  32
    Volume label              "TST0"    Relative volume number                0
    Cluster size                   1    Transaction count                     1
    Free blocks                  969    Maximum files allowed               250
    Extend quantity                5    Mount count                           1
    Mount status              System    Cache name      "_$252$DUA721:XQPCACHE"
    Extent cache size             64    Maximum blocks in extent cache       96
    File ID cache size            64    Blocks currently in extent cache      0
    Quota cache size               0    Maximum buffers in FCP cache        404
    Volume owner UIC        [SYSTEM]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD

  Volume Status:  ODS-2, subject to mount verification, file high-water marking,
      write-back caching enabled.

Disk $252$MDA0:, device type RAM Disk, is online, member of shadow set DSA0:.

    Error count                    0    Shadow member operation count       128
    Allocation class             252
                                             

Disk $252$MDA1:, device type RAM Disk, is online, member of shadow set DSA0:.

    Error count                    0    Shadow member operation count       157
    Allocation class             25

7.9.2 ビットマップ ID の表示

DCL コマンドの SHOW DEVICE/BITMAP device-name で，ノード上の各々のビットマップの ID を調べることができます。 SHOW DEVICE の /BITMAP 修飾子は，/FULL 以外の修飾子と組み合わせることはできません。SHOW DEVICE/BITMAP の表示には，省略形と完全形があります。省略形がデフォルトです。

どのビットマップもアクティブでない場合，ビットマップ ID は表示されません。 no bitmaps active というメッセージが表示されます。

以下の例は，SHOW DEVICE/BITMAP の表示です。

$ SHOW DEVICE/BITMAP DSA1 
Device         BitMap        Size        Percent of 
Name           ID            (Bytes)     Full Copy 
DSA1:          00010001      652         11%

以下の例は，SHOW DEVICE/BITMAP/FULL の表示です。

$ SHOW DEVICE DSA12/BITMAP/FULL 
Device  Bitmap  Size   Percent of  Active Creation        Master  Cluster Local Delete  Bitmap  
Name    ID     (bytes) Full Copy          Date/Time       Node    Size    Set   Pending Name 
                       
DSA12: 00010001  652    11%       Yes  5-MAY-2000 13:30...300F2    127      2%    No   SHAD$TEST




	注意: ビットマップ名は，SHOW/DEVICE/FULL を指定したときだけ表示され，SHAD$volume-name の後に複数 (約 30 文字) の読めない文字が続く形式で表示されます。これらの読めない文字は，ビットマップの世代番号，作成時刻，およびその他の詳細を内部的に表すために使用されます。ビットマップ名は，内部的にのみ使用されます。ビットマップ ID は，システム管理者が使用します。

7.9.3 クラスタ・メンバのビットマップ・ステータスの表示

以下の例に示すように，SHOW CLUSTER 表示の中で ADD BITMAPS コマンドを発行することによって，ビットマップ情報の表示を指定することができます。

$ SHOW CLUSTER/CONTINUOUS

Command > ADD BITMAPS
Command > ADD CSID

View of Cluster from system ID 57348  node: WPCM1     14-FEB-2000 13:38:53

      SYSTEMS              MEMBERS       
  NODE   SOFTWARE    CSID   STATUS    BITMAPS  

 CSGF1   VMS X6TF    300F2   MEMBER    MINICOPY  

 HSD30Y  HSD YA01    300E6                  

 HS1CP2  HSD V31D    300F4                  

 CSGF2   VMS X6TF    300D0  MEMBER    MINICOPY

この例で，MINICOPY は，ノード CSGF1 と CSGF2 がミニコピー操作をサポートできることを意味します。クラスタ・ノードがミニコピーをサポートしていない場合，MINICOPY の代わりに UNSUPPORTED が表示され，クラスタ内でミニコピー機能が無効になっています。

7.9.4 ビットマップの削除

ミニコピー操作が完了すると，対応するビットマップは自動的に削除されます。

1 つ以上のビットマップを削除したい場合があります。ビットマップを削除したい理由には，以下のものがあります。

ビットマップで使われているメモリを回収する
ビットマップの記録を停止する

ビットマップは，/BITMAP 修飾子を指定して DCL コマンドの DELETE を実行することで削除できます。ビットマップ修飾子を使って，削除したいビットマップの ID を指定することができます。たとえば，次のとおりです。

$ DELETE/BITMAP/LOG 00010001

%DELETE-I-DELETED, 00010001 deleted

7.10 ビットマップによる性能への影響

ビットマップが性能に与える影響は，いくつかの要素で決まります。すなわち，ローカルおよびマスタのビットマップ間のメッセージ・トラフィック，各々のビットマップに必要なメモリ量，SetBit メッセージの非同期処理，およびシーケンシャル I\O に対する SetBit メッセージの低減です。

メッセージ・トラフィックはメッセージ・モードを変更することで調整できます。デフォルトのモードはシングル・メッセージ・モードです。バッファード・メッセージ・モードでは，システム全体の性能が改善されますが，各々のプロセスの書き込みがマスタ・ビットマップに記録されるまでの時間が通常長くなります。これらのモードについての詳細は， 3.4 項「ビットマップ・システム・パラメータ」を参照してください。




	注記: 「メモリ要件」で説明しているように，ビットマップを使用するとメモリの使用量が増えます。使用しているシステムのメモリ使用状況によっては，メモリの追加が必要になるかもしれません。

1 つのシャドウセットで複数のマスタ・ビットマップ・ノードを持つ場合があります。 OpenVMS Version 8.3 以前では，SetBit メッセージは複数のマスタ・ビットマップ・ノードへ同期的に送信されます。最初のリモート・マスタ・ビットマップ・ノードから SetBit メッセージに対する応答を受信すると，そのメッセージが次のマスタ・ビットマップ・ノードへ送信されます。この処理がすべてのリモート・マスタ・ビットマップ・ノードについて完了すると，I/O が再開されます。

OpenVMS Version 8.4 では，SetBit メッセージはすべてのマスタ・ビットマップ・ノードへ非同期に送信されます。すべてのマスタ・ビットマップ・ノードから応答を受けとると I/O が再開されるため，ビットマップ・コードによる I/O の遅れが低減されます。

以前のバージョンでは，ディスクに対するシーケンシャルな書き込みが発生すると，リモート・ビットマップのシーケンシャルなビットを設定する Setbit メッセージが送信されていました。 OpenVMS Version 8.4 では，書き込みビットマップ・コードは，ビットマップのどの場所に前のビットが設定されているかを認識するようになりました。これにより，シーケンシャルな書き込みが続く場合により少ない Setbit メッセージで済むように，追加ビットが設定されます。シーケンシャルな I/O が続くとの想定により Setbit メッセージが 10 分の 1 ほどに低減され，この結果，シーケンシャル書き込みの I/O レートが改善されます。

7.11 バックアップ用にシャドウセット・メンバを使う際のガイドライン

Volume Shadowing for OpenVMS は，オンライン・バックアップ・メカニズムとして使うことができます。アプリケーションの設計や操作手順が正しければ，マウントされているシャドウセットから削除したシャドウセット・メンバは，バックアップに使えます。

Volume Shadowing for OpenVMS を使って，ファイル・システムやアプリケーション・データベースのコピーをバックアップ用に取得する標準的な方法は，仮想ユニットがマージ状態にないことを確認し，仮想ユニットをディスマウントし，その後仮想ユニットを，メンバを 1 つ減らした状態でマウントし直すことです。 OpenVMS バージョン 7.3 より前では，マウントされていてアクティブに使われている仮想ユニットから，バックアップ用にシャドウセット・メンバを個別にディスマウントするときの，一般的な制限事項についてのドキュメントがありました。この制限事項は，メンバを削除する際の，ファイル・システム，アプリケーション・データ，仮想ユニットに格納されているデータベースのデータ整合性に関するものでした。

しかし，この制限事項はアプリケーションの真の連続運転 (24 時間 x 7日) が必要なときには受け入れ難いため，アプリケーション・ソフトウェアとシステム管理が連携することで，適切なデータ整合性が確保できる場合は，この制限事項は不要と考えられます。

7.11.1 バックアップ用にシャドウセット・メンバを削除する

現在サポートされている OpenVMS のリリースでは，以下の条件が満たされていれば，DISMOUNT を使って，データのバックアップ用にシャドウセットからメンバを削除することができます。

シャドウセットが マージ状態ではないこと。シャドウセットのコピー操作が実行中でないという条件も満たすことをお勧めします。
メンバを削除した後でも十分な冗長性が維持できていること。アクティブなシャドウセットのメンバを 2 つより少なくしないことをお勧めします。言い換えると，シャドウセットではコントローラのミラーリングや RAID 5 を採用することをお勧めします。

メンバを削除するには，以下の手順に従ってください。

システム管理手順またはアプリケーション・ソフトウェアあるいはその両方で，仮想ユニット全体でのデータ整合性を確立します。このトピックは複雑なので，この章の残りの大部分ではこのトピックについて説明します。
マージ状態と冗長性の要件が満たされていることを確認します。
仮想ユニットから，バックアップするメンバを削除します。
ステップ 1 で行ったデータ整合性の処置を停止します。

7.11.2 データ整合性の要件

シャドウセット・メンバを削除すると，いわゆる クラッシュ対応コピー ができます。つまり，削除されたメンバに格納されているデータのコピーは，その時点でシステム障害が発生した場合と同レベルの整合性を持ったものです。クラッシュ対応コピーからの復旧は，アプリケーションの設計，システムとデータベースの設計，そして操作手順によって保証されます。復旧を保証する手順は，アプリケーションとシステムの設計に依存するため，サイトごとに異なります。

システム障害が発生したときの状態は，データが書き込まれていない，データを書き込もうとしたがディスクに書き込まれていない，というものから，すべてのデータが書き込まれたというものまで多岐にわたります。以下の項では，障害が発生したときに処理中の書き込みがあった (すなわち，書き込もうとしたがディスクに書き込まれていない) 場合に，関係するオペレーティング・システムの要素と動作を説明しています。使っている環境でデータ整合性を確保する手順を確立する場合に，これらの問題を考慮してください。

7.11.3 アプリケーションの動作

データ整合性を達成するためには，アプリケーションの動作が停止され，すべての操作が停止している必要があります。操作が進行していると，バックアップされたアプリケーション・データとの不整合がおきます。多くの対話型アプリケーションでは，ユーザが操作しなければ，動作が停止する傾向がありますが，アプリケーションの動作を確実に停止するには，アプリケーション自身に意識させる必要があります。ジャーナリングやトランザクションの技法が，進行中の不整合の問題解決に使えますが，使うためには細心の注意が必要です。また，アプリケーションの他に，バックアップ・データに影響を与える可能性のある，システムの対話型操作も，停止する必要があります。

7.11.4 RMS への配慮

RMS ファイル・アクセスを使っているアプリケーションでは，以下の問題を認識しておく必要があります。

7.11.4.1 キャッシングと遅延書き込み

アプリケーションのオプションによっては，RMS では，アップデートの完了がアプリケーションに報告された後でも，ディスクへの書き込みが遅延されることがあります。ディスク上のデータは， RMS バッファ・キャッシュに対するその他の要求に対応したり，共有ファイル環境では協調プロセスが同じデータまたは近くのデータを参照することによって，アップデートされます。

順編成ファイルへの書き込みは，常にメモリにバッファされ，バッファが満杯になるまでディスクへ書き込まれません。

7.11.4.2 エンド・オブ・ファイル (EOF)

順編成ファイルの EOF ポインタは，通常，ファイルがクローズされたときのみアップデートされます。

7.11.4.3 インデックスのアップデート

索引編成ファイルで 1 つのレコードをアップデートすると，複数のインデックスのアップデートが必要になることがあります。これらのアップデートは，アプリケーションのオプションによってはキャッシュされることがあります。インデックスのアップデートが不完全なときにシャドウセットを分割すると，インデックスとデータ・レコードの間に，不整合が生ずることがあります。遅延書き込みが無効になっていれば，RMS は不完全なインデックス・アップデートで，アップデートが失われることはあっても，インデックスが壊れることがないような順序で書き込みを処理します。しかし，遅延書き込みが有効になっていると，インデックス・アップデートを書き込む順番が予測不可能になります。

7.11.4.4 実行時ライブラリ

種々の言語の入出力ライブラリでは，RMS の種々のバッファリングと遅延書き込みのオプションを使っています。言語によっては，アプリケーションが RMS のオプションを制御できるものがあります。

7.11.4.5 $FLUSH

アプリケーションでは，データ整合性を確保するために，$FLUSH サービスを使うことができます。 $FLUSH サービスは，アプリケーションで完了したすべてのアップデート (順編成ファイルの EOF も含む) が，ディスクに記録されたことを保証します。

7.11.4.6 ジャーナリングとトランザクション

RMS には，ロール・フォワード，ロール・バック，およびリカバリ・ユニット・ジャーナルのオプション機能があり， OpenVMS トランザクション・サービスを使ったトランザクション回復機能もサポートしています。これらの機能を使って，削除されたシャドウセット・メンバから，進行中だったアップデートを取り消すことができます。このような技法を使うためには，データやアプリケーションを注意深く設計する必要があります。ベース・データ・ファイルとともに，ジャーナルを含む仮想ユニットのバックアップを取ることが重要です。

7.11.5 マップされたファイル

OpenVMS では，プロセスおよびグローバル・セクション・サービスを通じて，仮想メモリのバッキング・ストアとしてのファイルをアクセスすることができます。このモードのアクセスでは，プロセスの仮想アドレス空間はファイル・データのキャッシュの働きをします。 OpenVMS では，バッキング・ファイルを強制的にアップデートするための $UPDSEC サービスを用意しています。

7.11.6 データベース・システム

Oracle® のようなデータベース管理システムは，ジャーナリングやトランザクションによる回復機能が組み込まれているので，シャドウセットの分割によるバックアップに適しています。シャドウセット・メンバをディスマウントする前に，次の形式の SQL コマンドを使って， Oracle データベースを " バックアップ・モード " にする必要があります。

ALTER TABLESPACE tablespace-name BEGIN BACKUP;

このコマンドによって，テーブルスペースの各々のコンポーネント・ファイルの回復ポイントが設定されます。回復ポイントは，データベースのバックアップ・コピーによって，後で整合状態に回復できることを保証します。バックアップ・モードは，次の形式のコマンドを使って終了させます。

ALTER TABLESPACE tablespace-name END BACKUP;

データベース・データ・ファイルと同時に，データベース・ログと制御ファイルもバックアップすることが重要です。

7.11.7 ベース・ファイル・システム

基本的な OpenVMS ファイル・システムは，空きスペースをキャッシュします。ただし，すべてのファイル・メタデータ操作 (たとえば，作成や削除) は，「注意深いライト・スルー」方式で実行されるため，結果は，アプリケーションに完了が報告される前に，ディスク上で確定しています。空きスペースの一部は失われる可能性がありますが，通常のディスク再構築で回復できます。シャドウセット・メンバをディスマウントするときにファイル操作が進行中だった場合は，ちょっとした不整合が起きることがありますが，これらは ANALYZE/DISK で修復できます。注意深く書き込みの順番を守れば，ディスクを修復する以前に，データの不整合でディスクの完全性が危うくなることはありません。

7.11.8 $QIO ファイル・アクセスと VIOC

OpenVMS は，ファイル・データをキャッシュするために，仮想入出力キャッシュ (VIOC) を使用しています。ただし，このキャッシュはライト・スルーです。OpenVMS バージョン 7.3 では，拡張ファイル・キャッシュ (XFC) が導入されましたが，これもライト・スルーです。

$QIO サービスを使ったファイル書き込みでは，呼び出したプログラムに完了が通知される前にディスクへの書き込みが完了しています。

7.11.9 マルチ・シャドウセット

マルチ・シャドウセットの場合，バックアップのためにシャドウセットを分割するのは，大仕事です。シングル・シャドウセットのメンバを削除するのは簡単ですが，マルチ・シャドウセットから複数のメンバを同時に削除する手段はありません。整合性を維持してバックアップする必要があるデータがマルチ・シャドウセットにまたがっている場合，すべてのシャドウセット・メンバをディスマウントする間，アプリケーションの動作は停止している必要があります。そうしないと，データがマルチ・ボリュームでクラッシュ対応でなくなります。関連するシャドウセットのディスマウントを高速化するために，コマンド・プロシージャその他の自動化技法を使うことをお勧めします。マルチ・シャドウセットに Oracle データベースが格納されている場合は，データベースの回復性を確保するために， Oracle データベースをバックアップ・モードにしておいてください。

7.11.10 ホストベースの RAID

OpenVMS のソフトウェアの RAID ドライバは，マルチ・シャドウセットの特別な場合です。ソフトウェア RAID セットは，それぞれのシャドウセットが複数のメンバで構成されるマルチ・シャドウセットで構成できます。ソフトウェア RAID ドライバの管理機能によって，構成要素のそれぞれのシャドウセットから，不可分な操作でメンバを 1 つディスマウントできます。 RAID ソフトウェアのもとで使われるシャドウセットの管理は，整合性を確保するために，常に RAID 管理コマンドを使って行う必要があります。

7.11.11 OpenVMS Cluster 操作

データ整合性を維持するためのすべての管理操作は，関連するアプリケーションを実行している OpenVMS Cluster システムのすべてのメンバで実行する必要があります。

7.11.12 テスト

テストだけでは，バックアップ手順の正しさは保証されません。ただし，テストは，バックアップと回復の手順を設計する上で重要な要素です。

7.11.13 データの復元

データの復元方法を深く考えることをしないで，バックアップ手順だけを検討する場合があります。しかし，すべてのバックアップ戦略の究極の目的は，障害時のデータ復元です。復元や回復の手順はバックアップ手順同様，注意深く設計しテストする必要があります。

7.11.14 データ整合性を確保する手順の再評価

この節の説明は OpenVMS バージョン 7.3 (およびそれ以降) の機能と動作に基づいていますが，それより前のバージョンにも当てはまります。 OpenVMS の将来のバージョンでは，データ整合性を確保するために必要な手順に影響を与えるような機能が追加されたり，仕様変更が行われる可能性があります。 OpenVMS の将来のバージョンにアップグレードするサイトでは，バックアップ後も整合性が確保されるように，手順を再評価し，OpenVMS の変更や非標準の設定に備える必要があります。

第7章 ミニコピーによるデータのバックアップ (Integrity および Alpha)

OpenVMSドキュメント・ライブラリ