| 前へ | 次へ | 目次 | 索引 |
この章では，OpenVMS バージョン 7.3 から導入された Volume Shadowing for OpenVMS のミニコピー機能を説明します。ミニコピーとそれを実現するテクノロジである書き込みビットマップは， OpenVMS Alpha システムに完全に実装されています。OpenVMS VAX ノードでは，この機能を使っているシャドウ・セットに書き込みはできますが，マスタ書き込みビットマップを作成したり，DCL コマンドで管理することはできません。アーキテクチャが混在している OpenVMS Cluster システムでミニコピーを使うためには，1 台の Alpha システムがあれば十分です。
ミニコピーの主な目的は，シャドウ・セット・メンバをシャドウ・セットに戻す時間を短縮することです。通常，シャドウ・セット・メンバを削除するのはデータのバックアップのためであり，それがすむとシャドウ・セットのメンバに戻します。
7.1 ミニコピーとは何か
ミニコピー操作は，コピー操作を効率化したものです。ミニコピーによってシャドウ・セット・メンバのデータがシャドウ・セットに戻されたとき，シャドウ・セットのデータと同じになることが保証されます。
書き込みビットマップはシャドウ・セットへの書き込みを追跡し，シャドウ・セット・メンバをシャドウ・セットに戻す際のミニコピー操作を指示するために使われます。
シャドウ・セット・メンバを削除する前は，図 7-1 に示すように，アプリケーションからの書き込みは直接シャドウ・セット ( 仮想ユニットとも言う ) に送られます。
図 7-1 アプリケーションによるシャドウ・セットへの書き込み
シャドウ・セット・メンバをディスマウントするときにミニコピー修飾子 (/POLICY=MINICOPY[=OPTIONAL]) を指定すると，書き込みビットマップが作成されます。シャドウ・セットへのその後の書き込みは，書き込みビットマップに記録されます。書き込みビットマップへの記録は，対応する書き込みの論理ブロック番号 (LBN) だけで，内容ではないことに注意してください。アドレスは，書き込みビットマップに 1 つ以上のビットを設定することで表現されます。各々のビットは 127 ディスク・ブロックの範囲に対応します。
データが 127 ブロックの範囲のどこかのブロックに書き込まれると，その範囲に対応する書き込みビットマップのビットが設定されます。ビットが設定されると，そのデータが，図 7-2 に示すように，シャドウ・セットに書き込まれます。
図 7-2 アプリケーションによる書き込みビットマップへの書き込み
メンバをシャドウ・セットを戻すとき，書き込みビットマップは， 図 7-3 に示すようにミニコピー操作の指示のために使われます。ミニコピー操作が行われている間でも，アプリケーションはシャドウ・セットの読み書きを継続できます。
図 7-3 シャドウ・セット (仮想ユニット) に戻されるメンバ
システム管理者が 第 7.12 節 のガイドラインに従っている限り，ミニコピー機能を使うと，メンバをシャドウ・セットに戻す際のフル・コピーは不要になります。この章では，コピーとフル・コピーは同じ意味で使っていることに注意してください。
いくつかの DCL コマンドを，書き込みビットマップの管理のために使うことができます。OpenVMS Cluster システムでの書き込みビットマップの更新の管理や，ノードごとのシャドウ・セットの上限数を設定するためのシステム・パラメータが用意されています。
7.2 コピーとミニコピーの異なる使い方
ミニコピーが導入される前は，コピー操作は 2 つの目的で使われていました。仮想ユニットにメンバを追加するのと，削除されたメンバを元のシャドウ・セットに戻すためです。メンバを仮想ユニットに戻すためには，そのメンバのデータをシャドウ・セットのデータに一致させなければなりません。
コピー操作は，今でも複数メンバのシャドウ・セットを作成するための唯一の方法です。メンバをシャドウ・セットに戻す場合は，コピー操作よりもミニコピー操作の方が優れています。
通常，シャドウ・セット・メンバを削除する目的は，データをテープやディスクにバックアップするためです。
シャドウ・セット・メンバをバックアップ操作で使うためには，システム管理者は次の手順に従う必要があります。
止める方法は，アプリケーションやコンピューティング環境に依存します。
バックアップを行っている間，アプリケーションはシャドウ・セットの残りのメンバにデータを書き込みます。
この形式のバックアップがサポートされる条件についての詳細は， 第 7.12 節 を参照してください。 |
ミニコピー操作は，システム管理者の意志で，システム管理者が決めた時間に使うことができます。
ミニコピーを使うと，シャドウ・セットにメンバを戻すために要する時間が著しく短縮されるため，システム管理者が行うシャドウ・セット・メンバの削除と復元を柔軟に計画することができ，可用性が向上します。
ミニコピーの実行に要する時間は，ディスクを外していた間にシャドウ・セットに加えられた変更の量に比例します。コピー時間が短縮されることで，バックアップの管理が容易になります。
表 7-1 には一連のテスト結果を示しています。ここではシャドウ・セットに多様な書き込みが行われたときのフル・コピーとミニコピーに要する時間の比較を行っています。 表 7-1 と 表 7-2 は，ミニコピーを使ったときに得られる性能向上の目安として参考にしてください。
| 設定されているビットの割合 | フル・コピーの時間 (秒) | ミニコピーの時間 (秒) | フル・コピーの時間に対するミニコピーの時間の割合 |
|---|---|---|---|
| 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 は，別の一連のテストの結果です。多様な書き込みについて，ハードウェア補助付きコピー (HSJ コントローラで MSCP ディスク・コピー・データ (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% |
ミニコピー操作を使うには，以下の手順に従います。
書き込みビットマップは，シャドウ・セットからメンバを削除するときに， DISMOUNT コマンドに新しい修飾子 /POLICY=MINICOPY[=OPTIONAL] を指定すると開始されます。第 7.6.2 項 で説明するように， 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 ミニコピーの制限
以下は，ミニコピーを使う場合の制限です。
たとえば，ディスマウントされた 3 メンバ (D1，D2，D3) のシャドウ・セットがある場合，D1 だけを /POLICY=MINICOPY[=OPTIONAL] 修飾子を指定してマウントし直すと，書き込みビットマップが作成されます。このシャドウ・セットに D2 を戻そうとすると，自動的にミニコピーが実行されます。そして残りのメンバ D3 をシャドウ・セットにマウントすると，今度はフル・コピー操作が実行されます。
この最後のメンバ D3 のフル・コピーを避けるためには，/POLICY=MINICOPY を指定して，シャドウ・セット・メンバを一度に 1 つずつディスマウントします。こうすれば，シャドウ・セットのメンバごとに書き込みビットマップを用意できます。各々のディスクをシャドウ・セットに戻すとき，それぞれにミニコピーが可能になります。
ミニコピーが即座に行われるようにするためには，各々の MOUNT コマンドで， 1 つのシャドウ・セット・メンバだけを指定します。そしてミニコピーが開始されるのを待ち，別の MOUNT コマンドで次のメンバを追加します。
第 7.10.4 項 で説明するように，余分な書き込みビットマップは，DELETE コマンドで削除できます。
書き込みビットマップを開始してシャドウ・セット・メンバを (DISMOUNT/POLICY=MINICOPY[=OPTIONAL] を指定して ) ディスマウントしようとすると，シャドウ・セット・メンバでマージ操作が実行中か，コピーのターゲットになっている場合，次のエラー・メッセージが表示されます。
%DISM-F-SRCMEM, only source member of shadow set cannot be dismounted
|
ミニコピーの将来のバージョンでは，もっとわかりやすいエラー・メッセージに変更される予定です。
書き込みビットマップの作成には，DCL コマンドの DISMOUNT と MOUNT が使われます。MOUNT コマンドは，書き込みビットマップを使ったミニコピー操作を開始するためにも使われます (
第 7.7 節 を参照 )。
7.6.1 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.2 MOUNT での書き込みビットマップの作成
以下の条件のとき，MOUNT コマンドで書き込みビットマップを作成できます。
複数メンバのシャドウ・セットは，以前のマウントでは，同一のノード，同一クラスタの別のノード，あるいは，クラスタ外の別のノードに，マウントされていなければなりません。
このコマンドで作成される書き込みビットマップは，後でシャドウ・セットの以前のメンバをシャドウ・セットにマウントするときに，ミニコピー操作で使われます。
/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 書き込みビットマップのメッセージとシャドウ・セットの制限を管理するシステム・パラメータ
OpenVMS Cluster システムには，マスタ書き込みビットマップとそれに対応するローカル書き込みビットマップとの間のアップデート・トラフィックを管理するために使われるシステム・パラメータがあります。別のパラメータには，書き込みビットマップのシステム・メッセージをオペレータ・コンソールに送信するかどうか，そして送信する場合にメッセージの量を制御する新しいシステム・パラメータがあります。これらのシステム・パラメータは動的です。つまり，実行中のシステムで変更できます。これらのパラメータを， 表 3-3 に示します。
また，新しいボリューム・シャドウイング・システム・パラメータとして， 1 つのノードに存在できるシャドウ・セットの最大数を指定する SHADOW_MAX_UNIT も用意されました。このパラメータは，表 3-1 で説明しています。
書き込みビットマップのメッセージ・トラフィックを管理するシステム・パラメータによって，マスタ書き込みビットマップをアップデートするためのメッセージをバッファリングして，単一の SCS メッセージとしてパッケージ化するか，あるいは毎回，直接送るかを制御します。このシステム・パラメータは，メッセージ・トラフィックの上限および下限のしきい値とトラフィックを計測する周期を設定するために，使われます。
各々のリモート・ノードで発行される書き込みは，デフォルトでは，個別の SCS メッセージとして，マスタ書き込みビットマップのあるノードに送られます。これを，シングル・メッセージ・モード と言います。
リモート・ノードから送られてくる書き込みが，指定された周期で上限しきい値に到達した場合，シングル・メッセージ・モードは バッファード・メッセージ・モード に切り替わります。バッファード・メッセージ・モードでは，最大 9 個のメッセージが，指定された周期内に収集され，1 個の SCS メッセージとして送られます。メッセージ・トラフィックが多い時間帯では，マスタ書き込みビットマップへの複数のメッセージをグループ化し， 1 つの SCS メッセージとして送ると，通常，個々のメッセージを別個に送るより効率的です。
7.10 DCL コマンドによる書き込みビットマップの管理
SHOW DEVICE，SHOW CLUSTER，および DELETE のコマンドが，書き込みビットマップを管理するために機能拡張されました。
7.10.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 252
|
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:25:30 300F2 127 2% No SHAD$TEST
|
7.10.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.10.4 書き込みビットマップの削除
ミニコピー操作が完了すると，対応する書き込みビットマップは自動的に削除されます。
1 つ以上の書き込みビットマップを削除したい場合があります。ビットマップを削除したい理由には，以下のものがあります。
書き込みビットマップは，/BITMAP 修飾子を指定して DCL コマンドの DELETE を実行することで削除できます。ビットマップ修飾子を使って，削除したいビットマップの ID を指定することができます。たとえば，次のとおりです。
$ DELETE/BITMAP/LOG 00010001
%DELETE-I-DELETED, 00010001 deleted
|
書き込みビットマップが性能に与える影響は，2 つの要素で決まります。ローカルおよびマスタの書き込みビットマップ間のメッセージ・トラフィックと各々のビットマップに必要なメモリ量です。
メッセージ・トラフィックはメッセージ・モードを変更することで調整できます。メッセージ・モードのデフォルトはシングル・メッセージ・モードです。バッファード・メッセージ・モードでは，システム全体の性能が改善されますが，各々のプロセスの書き込みがマスタ書き込みビットマップに記録されるまでの時間が通常長くなります。これらのモードについての詳細は， 第 7.9 節 を参照してください。
第 1.3.1 項 で説明しているように，書き込みビットマップを使用するとメモリの使用量が増えます。使用しているシステムのメモリ使用状況によっては，メモリの追加が必要になるかもしれません。
7.12 バックアップ用にシャドウ・セット・メンバを使う際のガイドライン
Volume Shadowing for OpenVMS は，オンライン・バックアップ・メカニズムとして使うことができます。アプリケーションの設計や操作手順が正しければ，マウントされているシャドウ・セットから削除したシャドウ・セット・メンバは，バックアップに使えます。
Volume Shadowing for OpenVMS を使って，ファイル・システムやアプリケーション・データベースのコピーをバックアップ用に取得する標準的な方法は，仮想ユニットがマージ状態にないことを確認し，仮想ユニットをディスマウントし，その後仮想ユニットを，メンバを 1 つ減らした状態でマウントし直すことです。 OpenVMS バージョン 7.3 より前では，マウントされていてアクティブに使われている仮想ユニットから，バックアップ用にシャドウ・セット・メンバを個別にディスマウントするときの，一般的な制限事項についてのドキュメントがありました。この制限事項は，メンバを削除する際の，ファイル・システム，アプリケーション・データ，仮想ユニットに格納されているデータベースのデータ整合性に関するものでした。
しかし，この制限事項はアプリケーションの真の連続運転 (24 時間 x 7日) が必要なときには受け入れ難いため，アプリケーション・ソフトウェアとシステム管理が連携することで，適切なデータ整合性が確保できる場合は，この制限事項は不要と考えられます。
7.12.1 バックアップ用にシャドウ・セット・メンバを削除する
現在サポートされている OpenVMS のリリースでは，以下の条件が満たされていれば，DISMOUNT を使って，データのバックアップ用にシャドウ・セットからメンバを削除することができます。
メンバを削除するには，以下の手順に従ってください。
シャドウ・セット・メンバを削除すると，いわゆる クラッシュ対応コピー ができます。つまり，削除されたメンバに格納されているデータのコピーは，その時点でシステム障害が発生した場合と同レベルの整合性を持ったものです。クラッシュ対応コピーからの復旧は，アプリケーションの設計，システムとデータベースの設計，そして操作手順によって保証されます。復旧を保証する手順は，アプリケーションとシステムの設計に依存するため，サイトごとに異なります。
システム障害が発生したときの状態は，データが書き込まれていない，データを書き込もうとしたがディスクに書き込まれていない，というものから，すべてのデータが書き込まれたというものまで多岐にわたります。以下の項では，障害が発生したときに処理中の書き込みがあった ( すなわち，書き込もうとしたがディスクに書き込まれていない ) 場合に，関係するオペレーティング・システムの要素と動作を説明しています。使っている環境でデータ整合性を確保する手順を確立する場合に，これらの問題を考慮してください。
7.12.3 アプリケーションの動作
データ整合性を達成するためには，アプリケーションの動作が停止され，すべての操作が停止している必要があります。操作が進行していると，バックアップされたアプリケーション・データとの不整合がおきます。多くの対話型アプリケーションでは，ユーザが操作しなければ，動作が停止する傾向がありますが，アプリケーションの動作を確実に停止するには，アプリケーション自身に意識させる必要があります。ジャーナリングやトランザクションの技法が，進行中の不整合の問題解決に使えますが，使うためには細心の注意が必要です。また，アプリケーションの他に，バックアップ・データに影響を与える可能性のある，システムの対話型操作も，停止する必要があります。
7.12.4 RMS への配慮
RMS ファイル・アクセスを使っているアプリケーションでは，以下の問題を認識しておく必要があります。
7.12.4.1 キャッシングと遅延書き込み
アプリケーションのオプションによっては，RMS では，アップデートの完了がアプリケーションに報告された後でも，ディスクへの書き込みが遅延されることがあります。ディスク上のデータは， RMS バッファ・キャッシュに対するその他の要求に対応したり，共有ファイル環境では協調プロセスが同じデータまたは近くのデータを参照することによって，アップデートされます。
順編成ファイルへの書き込みは，常にメモリにバッファされ，バッファが満杯になるまでディスクへ書き込まれません。
7.12.4.2 エンド・オブ・ファイル (EOF)
順編成ファイルの EOF ポインタは，通常，ファイルがクローズされたときのみアップデートされます。
7.12.4.3 インデックスのアップデート
索引編成ファイルで 1 つのレコードをアップデートすると，複数のインデックスのアップデートが必要になることがあります。これらのアップデートは，アプリケーションのオプションによってはキャッシュされることがあります。インデックスのアップデートが不完全なときにシャドウ・セットを分割すると，インデックスとデータ・レコードの間に，不整合が生ずることがあります。遅延書き込みが無効になっていれば，RMS は不完全なインデックス・アップデートで，アップデートが失われることはあっても，インデックスが壊れることがないような順序で書き込みを処理します。しかし，遅延書き込みが有効になっていると，インデックス・アップデートを書き込む順番が予測不可能になります。
7.12.4.4 実行時ライブラリ
種々の言語の入出力ライブラリでは，RMS の種々のバッファリングと遅延書き込みのオプションを使っています。言語によっては，アプリケーションが RMS のオプションを制御できるものがあります。
7.12.4.5 $FLUSH
アプリケーションでは，データ整合性を確保するために，$FLUSH サービスを使うことができます。$FLUSH サービスは，アプリケーションで完了したすべてのアップデート ( 順編成ファイルの EOF も含む ) が，ディスクに記録されたことを保証します。
7.12.4.6 ジャーナリングとトランザクション
RMS には，ロール・フォワード，ロール・バック，およびリカバリ・ユニット・ジャーナルのオプション機能があり， OpenVMS トランザクション・サービスを使ったトランザクション回復機能もサポートしています。これらの機能を使って，削除されたシャドウ・セット・メンバから，進行中だったアップデートを取り消すことができます。このような技法を使うためには，データやアプリケーションを注意深く設計する必要があります。ベース・データ・ファイルとともに，ジャーナルを含む仮想ユニットのバックアップを取ることが重要です。
7.12.5 マップされたファイル
OpenVMS では，プロセスおよびグローバル・セクション・サービスを通じて，仮想メモリのバッキング・ストアとしてのファイルをアクセスすることができます。このモードのアクセスでは，プロセスの仮想アドレス空間はファイル・データのキャッシュの働きをします。 OpenVMS では，バッキング・ファイルを強制的にアップデートするための $UPDSEC サービスを用意しています。
7.12.6 データベース・システム
Oracle のようなデータベース管理システムは，ジャーナリングやトランザクションによる回復機能が組み込まれているので，シャドウ・セットの分割によるバックアップに適しています。シャドウ・セット・メンバをディスマウントする前に，次の形式の SQL コマンドを使って， Oracle データベースを " バックアップ・モード " にする必要があります。
ALTER TABLESPACE tablespace-name BEGIN BACKUP;
|
このコマンドによって，テーブルスペースの各々のコンポーネント・ファイルの回復ポイントが設定されます。回復ポイントは，データベースのバックアップ・コピーによって，後で整合状態に回復できることを保証します。バックアップ・モードは，次の形式のコマンドを使って終了させます。
ALTER TABLESPACE tablespace-name END BACKUP;
|
データベース・データ・ファイルと同時に，データベース・ログと制御ファイルもバックアップすることが重要です。
7.12.7 ベース・ファイル・システム
基本的な OpenVMS ファイル・システムは，空きスペースをキャッシュします。ただし，すべてのファイル・メタデータ操作 (たとえば，作成や削除) は，「注意深いライト・スルー」方式で実行されるため，結果は，アプリケーションに完了が報告される前に，ディスク上で確定しています。空きスペースの一部は失われる可能性がありますが，通常のディスク再構築で回復できます。シャドウ・セット・メンバをディスマウントするときにファイル操作が進行中だった場合は，ちょっとした不整合が起きることがありますが，これらは ANALYZE/DISK で修復できます。注意深く書き込みの順番を守れば，ディスクを修復する以前に，データの不整合でディスクの完全性が危うくなることはありません。
7.12.8 $QIO ファイル・アクセスと VIOC
OpenVMS は，ファイル・データをキャッシュするために，仮想入出力キャッシュ (VIOC) を使用しています。ただし，このキャッシュはライト・スルーです。OpenVMS バージョン 7.3 では，拡張ファイル・キャッシュ (XFC) が導入されましたが，これもライト・スルーです。
$QIO サービスを使ったファイル書き込みでは，呼び出したプログラムに完了が通知される前にディスクへの書き込みが完了しています。
7.12.9 マルチ・シャドウ・セット
マルチ・シャドウ・セットの場合，バックアップのためにシャドウ・セットを分割するのは，大仕事です。シングル・シャドウ・セットのメンバを削除するのは簡単ですが，マルチ・シャドウ・セットから複数のメンバを同時に削除する手段はありません。整合性を維持してバックアップする必要があるデータがマルチ・シャドウ・セットにまたがっている場合，すべてのシャドウ・セット・メンバをディスマウントする間，アプリケーションの動作は停止している必要があります。そうしないと，データがマルチ・ボリュームでクラッシュ対応でなくなります。関連するシャドウ・セットのディスマウントを高速化するために，コマンド・プロシージャその他の自動化技法を使うことをお勧めします。マルチ・シャドウ・セットに Oracle データベースが格納されている場合は，データベースの回復性を確保するために， Oracle データベースをバックアップ・モードにしておいてください。
7.12.10 ホスト・ベースの RAID
OpenVMS のソフトウェアの RAID ドライバは，マルチ・シャドウ・セットの特別な場合です。ソフトウェア RAID セットは，それぞれのシャドウ・セットが複数のメンバで構成されるマルチ・シャドウ・セットで構成できます。ソフトウェア RAID ドライバの管理機能によって，構成要素のそれぞれのシャドウ・セットから，不可分な操作でメンバを 1 つディスマウントできます。RAID ソフトウェアのもとで使われるシャドウ・セットの管理は，整合性を確保するために，常に RAID 管理コマンドを使って行う必要があります。
7.12.11 OpenVMS Cluster 操作
データ整合性を維持するためのすべての管理操作は，関連するアプリケーションを実行している OpenVMS Cluster システムのすべてのメンバで実行する必要があります。
7.12.12 テスト
テストだけでは，バックアップ手順の正しさは保証されません。ただし，テストは，バックアップと回復の手順を設計する上で重要な要素です。
7.12.13 データの復元
データの復元方法を深く考えることをしないで，バックアップ手順だけを検討する場合があります。しかし，すべてのバックアップ戦略の究極の目的は，障害時のデータ復元です。復元や回復の手順はバックアップ手順同様，注意深く設計しテストする必要があります。
7.12.14 データ整合性を確保する手順の再評価
この節の説明は OpenVMS バージョン 7.3 の機能と動作に基づいていますが，それより前のバージョンにも当てはまります。OpenVMS の将来のバージョンでは，データ整合性を確保するために必要な手順に影響を与えるような機能が追加されたり，仕様変更が行われる可能性があります。 OpenVMS の将来のバージョンにアップグレードするサイトでは，バックアップ後も整合性が確保されるように，手順を再評価し，OpenVMS の変更や非標準の設定に備える必要があります。
| 前へ | 次へ | 目次 | 索引 |