第14章 DECdtm サービスの管理

14.1 トランザクション・ログについて

トランザクション・ログとは，あるノード上で行われた DECdtm トランザクションに関する情報を格納するファイルのことです。 ファイルのタイプは .LM$JOURNAL です。

任意のノードで DECdtm トランザクションを実行する場合は，そのノードに対してトランザクション・ログを作成しておく必要があります。 OpenVMS Cluster では，クラスタ内の各ノードでトランザクション・ログを作成します。 ログ・マネージャ制御プログラム (LMCP) ユーティリティを使用して，トランザクション・ログの作成と管理を行います。

DECdtm サービスでは，トランザクション・ログの格納場所は論理名 SYS$JOURNAL によって判断されます。 トランザクション・ログを含むディレクトリを指すように，SYS$JOURNAL に定義する必要があります。

14.2 トランザクション・ログの計画

トランザクション・ログのサイズと格納場所は，トランザクションの性能に影響を及ぼします。 トランザクション・ログを作成する前に，そのサイズと格納場所を決定してください。

トランザクション・ログのサイズと格納場所は，作成した後でも変更することができます。 しかし，この段階でログの格納場所とサイズについて十分に検討しておくと，後になって変更する負担が少なくてすみます。

この節では次の作業について説明します。

14.2.1 トランザクション・ログのサイズの決定

トランザクション・ログを作成する場合は，そのサイズをブロック単位で指定することができます。 省略時のサイズは 4,000 ブロックです。 この値に設定すれば，ほとんどのシステムで十分な性能を得ることができます。

トランザクションの平均発生数が予想できる場合，トランザクション・ログのサイズは以下の計算式で求めることができます。

サイズ = 40 × 平均発生数

サイズ	トランザクション・ログのサイズを示すブロック数
平均発生率	1 秒あたりに実行されるトランザクション数の平均

トランザクションの平均発生数が分からない場合には，省略時の値の 4,000 ブロックを採用します。

14.2.2 トランザクション・ログの格納場所の決定

できれば，以下の属性を持つディスクに置いてください。

高速	半導体ディスクのような高性能ディスクで，負荷の低いもの。
高可用性	データに複数のアクセス・パスを設定することによって高い可用性を実現することができる。 OpenVMS Cluster では，クラスタ内の別のノードからもアクセスできるディスクを使用する。 1 つのノードがダウンした場合にも，別のノードで実行されているトランザクションはブロックされない。
高信頼性	データの複数のコピーを作成しておけば，高い信頼性を実現することができる。 シャドウ・ディスクは非シャドウ・ディスクよりも信頼性が高いが，トランザクション・ログがほぼ書き込み専用である分低速になる。

速度と可用性または信頼性のいずれかとの間で選択を行う必要があることがあります。 たとえば，ノードがワークステーションの場合には，可用性と信頼性のために速度を犠牲にして，ワークステーションに接続されたディスクではなく，それより低速の HSC ベースのシャドウ・ディスク上にノードのトランザクション・ログを置く場合があります。

クラスタ環境では，できるだけトランザクション・ログを複数のディスクに分散させてください。 1 つのディスクに複数のトランザクション・ログが存在すると，トランザクションの性能が低下します。

	注意: ディスクにトランザクション・ログを保持するための十分な連続領域があることを確認してください。 トランザクション・ログの領域が連続していないと，トランザクション性能は低下します。

14.3 DECnet-Plus ネットワークの計画

この節では，DECnet-Plus ネットワークで DECdtm を使用する際に役立つ，次の情報についてまとめます。

14.3.1 DECnet-Plus ネームスペースの計画

DECdtm では，複数の DECnet-Plus ネームスペースをサポートしません。

つまり，DECdtm サービスを使用するソフトウェアを使用したい場合には，ローカル・ネームスペースと DECdns ネームスペースの両方を使用することはできません。

14.3.2 DCEnet-Plus ネットワークでの SCSNODE 名の計画

SCSNODE は，コンピュータの名前を定義するシステム・パラメータです。 DECnet-Plus ネットワークを使用しているときに，異なる OpenVMS Clusterまたは異なるスタンドアロン・コンピュータにまたがる DECdtm トランザクションを実行したい場合には，SCSNODE 名を選択する際に次の規則に従う必要があります。

14.3.2.1 SCSNODE 名に関する規則

DECnet-Plus ネットワークを使用していて，異なる OpenVMS Cluster または異なるスタンドアロン・コンピュータにまたがる DECdtm トランザクションを実行する場合には，SCSNODE 名が次の規則に従っているかどうかを確認する必要があります。

• トランザクション・グループ内の各コンピュータの SCSNODE 名は，次の名前と異なる名前でなければならない。

  • トランザクション・グループ内の他のコンピュータの SCSNODE 名。 SCSNODE 名は，同じトランザクション・グループ内で一意な名前でなければならない。

  • 同じローカル・ルートの他のコンピュータの DECnet 単純名。

  • ネットワーク全体の他のコンピュータの DECnet 同意語。

  トランザクション・グループについての詳細は，14.3.2.2 項 「トランザクション・グループについて」を参照。

• コンピュータが OpenVMS Cluster 内にあるときは，SCSNODE 名は次の名前と異なる名前でなければならない。

  • 同じクラスタ内の他のコンピュータの DECnet 単純名。

  • 他のクラスタ・メンバと同じローカル・ルートのコンピュータの DECnet 単純名。

	注記: HP DECnet-Plus for OpenVMS ネットワーク接続を持ち，IP ルータだけを使用してノードが接続されている遠隔システムとの分散トランザクションに参加するためにユーザ作成のアプリケーションが DECdtm を呼び出している場合，このアプリケーションを実行した ACMS ユーザ，Rdb ユーザ，およびその他のユーザには，次のエラーが DECnet から返されます。 IPC-E-BCKTRNSFAIL, failure on the back translate address request このエラーは，DECnet-Plus が遠隔ノードの名前を変換できないという論理接続の障害時に表示されます。 このエラーは，次の場合に発生する可能性があります。 遠隔システムの DECnet-Plus ノード名が，ローカルの DECnet-Plus データベースには定義されておらず，遠隔ノードの TCP/IP ネーム・サーバの ALIAS としてだけ定義されている。 たとえば，ノード XXYZZY が，次のように定義されている場合。 20.43.136.54 XXYZZY.ABC.DEF.COM, XXYZZY ノード名が，DECnet データベースで解決できない。 この場合，アドレス解決メカニズムは，TCP/IP データベースを利用する。 これでもノード名が解決できない場合は，サービスは上記のエラーで失敗する。 この状況を回避するには，TCP/IP データベースに SCSNAME を登録する。

14.3.2.2 トランザクション・グループについて

トランザクション・グループとは，DECdtm トランザクションに関係するコンピュータのグループであり，その SCSNODE 名は，14.3.2.1 項 「SCSNODE 名に関する規則」で説明する規則に従わなければなりません。

トランザクション・グループは，次のガイドラインに従います。

• 各コンピュータは 1 つのトランザクション・グループに属す。

• OpenVMS Cluster 内のすべてのコンピュータは，同一トランザクション・グループに属す。

• 1 つのトランザクションがコンピュータ A とコンピュータ B にまたがる場合には，コンピュータ A とコンピュータ B は同一トランザクション・グループに属す。

図 14-2 「トランザクション・グループ」 は，トランザクション・グループの例を示しています。

図 14-2 トランザクション・グループ

この図で，9 台のコンピュータはすべて同じトランザクション・グループに属します。 これは次の理由によります。

• トランザクションは，クラスタ FRED 内のコンピュータとクラスタ BILL 内のコンピュータにまたがっている。 つまり，クラスタ FRED 内の 4 台のコンピュータと，クラスタ BILL 内の 4 台のコンピュータは，同じトランザクション・グループに属す。

• トランザクションは，スタンドアロン・コンピュータ TOM とクラスタ BILL 内のコンピュータにまたがっている。 つまり，スタンドアロン・コンピュータ TOM は，クラスタ BILL 内のコンピュータと同じトランザクション・グループに属す。

14.4 トランザクション・ログの作成

任意のノードで DECdtm サービスを利用する場合は，そのノードに対してトランザクション・ログを作成する必要があります。 OpenVMS Cluster 環境では，ノードごとにトランザクション・ログを作成します。

	重要: トランザクション・ログの作成後にクラスタからノードを削除すると，データが破壊されることがあります。 ノードを安全に削除する方法については，14.11 項 「ノードの削除」 を参照してください。

作業方法

例

この例では，OpenVMS Cluster 内のノード (SCSNODE 名が BLUE および RED) にトランザクション・ログを作成する方法を示します。 どちらのノードも，ノード固有のSYLOGICALS.COM を使用していないものとします。

トランザクション・ログの格納場所とサイズを次にように決定します。

ディスクをクラスタ全体でマウントします。

$ MOUNT/CLUSTER/SYSTEM DUA1: LOG1
$ MOUNT/CLUSTER/SYSTEM DUA2: LOG2

トランザクション・ログ用のディレクトリを作成します。

$ CREATE/DIRECTORY DISK$LOG1:[LOGFILES]
$ CREATE/DIRECTORY DISK$LOG2:[LOGFILES]

SYS$JOURNAL を定義します。

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> SET ENVIRONMENT/CLUSTER
SYSMAN> DO DEFINE/SYSTEM/EXECUTIVE_MODE SYS$JOURNAL - 
_SYSMAN> DISK$LOG1:[LOGFILES], DISK$LOG2:[LOGFILES]
SYSMAN> EXIT

コマンド・プロシージャSYS$MANAGER:SYLOGICALS.COM に以下の行を追加します。

$ !
$ DEFINE/SYSTEM/EXECUTIVE_MODE SYS$JOURNAL DISK$LOG1:[LOGFILES], -
_$DISK$LOG2:[LOGFILES]
$ !

トランザクション・ログを作成します。

$ RUN SYS$SYSTEM:LMCP
LMCP> CREATE LOG/SIZE=5000 DISK$LOG1:[LOGFILES]SYSTEM$BLUE.LM$JOURNAL
LMCP> CREATE LOG DISK$LOG2:[LOGFILES]SYSTEM$RED.LM$JOURNAL
LMCP> EXIT

DECdtm サービスが開始されたことを確認します。

$ SHOW LOGICAL SYS$DECDTM_INHIBIT
%SHOW-S-NOTRAN, no translation for logical name SYS$DECDTM_INHIBIT

SYS$DECDTM_INHIBIT が定義されていないため，DECdtm サービスが使用できます。

14.5 トランザクション性能の監視

負荷の増加など，システム構成を変更することでトランザクション性能に影響がでることがあります。 毎月一度はノード上でトランザクションを監視し，トランザクション性能が低下していないことを確認してください。 OpenVMS Cluster 環境では，クラスタ内のすべてのノードでトランザクション性能を監視してください。

作業方法

例

この例では BLUE と RED の 2 つのノードを持つ OpenVMS Cluster のトランザクション性能を監視しています。

ノード BLUE と RED のトランザクションは 24 時間連続して監視します。

$ MONITOR TRANSACTION/SUMMARY=DISK$LOG1:[LOGFILES]TRANSACTIONS.SUM -
_$ /ENDING="+1-"/NODE=(BLUE,RED) 

要約ファイルを調べます。

                   DISTRIBUTED TRANSACTION STATISTICS
                             on node BLUE         From: 16-OCT-2000 14:23:51
                                SUMMARY           To:   17-OCT-2000 14:23:51
                                   CUR        AVE        MIN        MAX

Start Rate                       49.02      43.21      31.30      49.02
Prepare Rate                     48.70      43.23      30.67      48.70
One Phase Commit Rate             0.00       0.00       0.00       0.00
Total Commit Rate                48.70      43.19      31.30      48.70
Abort Rate                        0.00       0.00       0.00       0.00
End Rate                         48.70      43.19      31.30      48.70
Remote Start Rate                 0.00       0.00       0.00       0.00
Remote Add Rate                   0.00       0.00       0.00       0.00

Completion Rate    0-1           21.42      13.57       0.63      21.42
 by Duration       1-2           25.97      29.15      24.59      33.87
 in Seconds        2-3            1.29       0.47       0.00       4.47
                   3-4            0.00       0.00       0.00       0.00
                   4-5            0.00       0.00       0.00       0.00
                    5+            0.00       0.00       0.00       0.00

                              SUMMARIZING


                   DISTRIBUTED TRANSACTION STATISTICS
                             on node RED          From: 16-OCT-2000 14:23:52
                                SUMMARY           To:   17-OCT-2000 14:23:52

⋮

以下の値に注目します。

今回の監視セッションの結果を以前のセッションの結果と比較します。

ノード BLUE のデータを見るかぎり，性能が低下した兆候は見られません。

14.6 トランザクション・ログのサイズが十分かどうかのチェック

トランザクション性能が低下しているノードが見つかった場合は，そのノードのトランザクション・ログのサイズが十分かどうかを調べる必要があります。

14.5 項 「トランザクション性能の監視」 では，トランザクション性能の低下を発見する方法を説明しています。

作業方法

例

ノード BLUE のトランザクション・ログのサイズが不十分かどうかを調べます。

ノード BLUE にログインし，トランザクション・ログがストールした回数を調べます。

$ RUN SYS$SYSTEM:LMCP
LMCP> SHOW LOG/CURRENT

Checkpoint starts/ends            2464/2464
Stall starts/ends                   21/21
Log status: no checkpoint in progress, no stall in progress.

チェックポイントの数は 2,464 で，トランザクションのストール回数は 21 回であることが分かります。

5 分後，SHOW LOG/CURRENT コマンドをもう一度入力します。

LMCP> SHOW LOG/CURRENT
Checkpoint starts/ends            2514/2514
Stall starts/ends                   28/28
Log status: no checkpoint in progress, no stall in progress.

チェックポイントの数が増え，さらにトランザクション・ログが現在 28 回ストールしており，ストール回数が 5 分間に 7 回増えていることが分かります。 したがって，トランザクション・ログのサイズが不十分であるといえます。

14.7 トランザクション・ログのサイズの変更

トランザクション・ログのサイズが不十分な場合，そのサイズを大きくする必要があります。 14.6 項 「トランザクション・ログのサイズが十分かどうかのチェック」を参照してください。

作業方法

	重要: 以下の手順で示すステップのすべてを実行してください。 途中のステップを省略すると，データが壊れることがあります。

例

この例は，ノード RED のトランザクション・ログのサイズを 6000 ブロックに変更しています。 ノード RED は OpenVMS Cluster 内に存在し，そのトランザクション・ログは DISK$LOG2:[LOGFILES] に置かれています。

ノード RED にログインします。 RED のトランザクション・ログが置かれているディレクトリを探し，そのトランザクション・ログの名前を変更します。

$ RUN SYS$SYSTEM:LMCP
LMCP> SHOW LOG SYSTEM$RED.LM$JOURNAL
Directory of DISK$LOG2:[LOGFILES]

SYSTEM$RED.LM$JOURNAL;1

Total of 1 file.
LMCP> EXIT

$ RENAME DISK$LOG2:[LOGFILES]SYSTEM$RED.LM$JOURNAL -
_$ DISK$LOG2:[LOGFILES]SYSTEM$RED.LM$OLD

DECdtm サービスを使用しているすべてのソフトウェアを終了します。 次に，トランザクション・ログを閉じます。

$ RUN SYS$SYSTEM:LMCP
LMCP> CLOSE LOG
Transaction log closed, TP_SERVER process stopped
LMCP> EXIT

TP_SERVER プロセスを再起動します。

$ @ SYS$STARTUP:DECDTM$STARTUP.COM

トランザクション・ログのサイズを変更します。

$ RUN SYS$SYSTEM:LMCP
LMCP> CONVERT LOG/SIZE=6000 DISK$LOG2:[LOGFILES]SYSTEM$RED.LM$OLD -
_LMCP> DISK$LOG2:[LOGFILES]SYSTEM$RED.LM$JOURNAL
Log file DISK$LOG2:[LOGFILES]SYSTEM$RED.LM$JOURNAL;1 created.
Log file DISK$LOG2:[LOGFILES]SYSTEM$RED.LM$OLD converted.
LMCP> EXIT

DECdtm サービスを使用するソフトウェアを再起動します。

旧トランザクション・ログを削除します。

$ DELETE DISK$LOG2:[LOGFILES]SYSTEM$RED.LM$OLD;

14.8 トランザクション・ログの移動

次の場合には，トランザクション・ログを移動します。

作業方法

	重要: 以下の手順で示すステップのすべてを実行してください。 途中のステップを省略すると，データが壊れることがあります。

例

この例は，BLUE のトランザクション・ログの移動方法を紹介しています。 BLUE は OpenVMS Cluster 内に存在します。 クラスタ・メンバおよびトランザクション・ログの格納場所を次のように想定しています。

どちらのノードも独自の SYLOGICALS.COM を使用していないものとします。

BLUE のトランザクション・ログの移動先を決定します。 この例では，DISK$LOG3:[LOGFILES] に移動します。

ノード BLUE にログインします。 次にディスクをクラスタ全体でマウントしてから，トランザクション・ログ用に新しいディレクトリを作成します。

$ MOUNT/CLUSTER/SYSTEM DUA3: LOG3
$ CREATE/DIRECTORY DISK$LOG3:[LOGFILES]

BLUE のトランザクション・ログが置かれているディレクトリを探し，トランザクション・ログの名前を変更します。

$ RUN SYS$SYSTEM:LMCP
LMCP> SHOW LOG SYSTEM$BLUE.LM$JOURNAL
Directory of DISK$LOG1:[LOGFILES]

SYSTEM$BLUE.LM$JOURNAL;1

Total of 1 file.
LMCP> EXIT
$ RENAME DISK$LOG1:[LOGFILES]SYSTEM$BLUE.LM$JOURNAL -
_$ DISK$LOG1:[LOGFILES]SYSTEM$BLUE.LM$OLD

DECdtm サービスを使用しているすべてのソフトウェアを終了します。 次にトランザクション・ログを閉じます。

$ RUN SYS$SYSTEM:LMCP
LMCP> CLOSE LOG
Transaction log closed, TP_SERVER process stopped
LMCP> EXIT

TP_SERVER プロセスを再起動します。

$ @SYS$STARTUP:DECDTM$STARTUP.COM

SYS$JOURNAL を再定義します。

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> SET ENVIRONMENT/CLUSTER
SYSMAN> DO DEFINE/SYSTEM/EXECUTIVE_MODE SYS$JOURNAL -
_SYSMAN> DISK$LOG2:[LOGFILES], DISK$LOG3:[LOGFILES]
SYSMAN> EXIT

コマンド・プロシージャ SYS$MANAGER:SYLOGICALS.COMの SYS$JOURNAL の定義内容を更新します。 その後，トランザクション・ログを移動します。

$ RUN SYS$SYSTEM:LMCP
LMCP> CONVERT LOG DISK$LOG1:[LOGFILES]SYSTEM$BLUE.LM$OLD -
_LMCP> DISK$LOG3:[LOGFILES]SYSTEM$BLUE.LM$JOURNAL
Log file DISK$LOG3:[LOGFILES]SYSTEM$BLUE.LM$JOURNAL;1 created.
Log file DISK$LOG1:[LOGFILES]SYSTEM$BLUE.LM$OLD converted.
LMCP> EXIT

DECdtm サービスを使用するソフトウェアを再起動します。 次に旧トランザクション・ログを削除します。

$ DELETE DISK$LOG1:[LOGFILES]SYSTEM$BLUE.LM$OLD;

14.9 ディスクのディスマウント

ディスクをディスマウントするには，ディスク上のトランザクション・ログをすべて閉じておく必要があります。

ここでは，トランザクション・ログを持っているディスクのディスマウント方法を説明します。

作業方法

例

次の例は，ディスク DISK$LOG3 のディスマウントの方法を説明しています。

ディスク上にあるトランザクション・ログを探す。

$ RUN SYS$SYSTEM:LMCP
LMCP> SHOW LOG
	⋮
Directory of DISK$LOG3:[LOGFILES]

SYSTEM$BLUE.LM$JOURNAL;1

DISK$LOG3 上に存在するトランザクション・ログは，ノード BLUE のトランザクション・ログだけである。

DECdtm サービスを使用するすべてのソフトウェアを終了する。

ノード BLUE にログインする。 次にトランザクション・ログの名前を変更する。

$ RENAME DISK$LOG3:[LOGFILES]SYSTEM$BLUE.LM$JOURNAL -
_$ DISK$LOG3:[LOGFILES]SYSTEM$BLUE.LM$TEMP

トランザクション・ログを閉じる。

$ RUN SYS$SYSTEM:LMCP
LMCP> CLOSE LOG
Transaction log closed, TP_SERVER process stopped
LMCP> EXIT

TP_SERVER プロセスを再起動する。

$ @SYS$STARTUP:DECDTM$STARTUP.COM

ディスクをディスマウントする。

$ DISMOUNT/CLUSTER DISK$LOG3:

ディスクを再度マウントしたいときは，クラスタ全体でマウントする。

 MOUNT/CLUSTER/SYSTEM DUA3: LOG3

BLUE のトランザクション・ログの名前を変更する。

$ RENAME DISK$LOG3:[LOGFILES]SYSTEM$BLUE.LM$TEMP -
_$ DISK$LOG3:[LOGFILES]SYSTEM$BLUE.LM$JOURNAL

DECdtm サービスを使用するソフトウェアを再起動する。

14.10 ノードの追加

OpenVMS Cluster に追加したすべてのノードで，新しいトランザクション・ログを作成する必要があります。 この節では，新規ノードでのトランザクション・ログの作成方法について説明します。

作業方法

この作業を実行するには，あらかじめ新規ノードをクラスタ内で構成しておく必要があります。 クラスタ内での新規ノードの構成方法については，『OpenVMS Cluster システム』を参照してください。

例

この例は，SCSNODE 名が WHITE である新規ノードで，トランザクション・ログを作成する方法を説明したものです。

この例では，クラスタ・メンバおよびそのトランザクション・ログの格納場所は次のとおりです。

どちらのノードもノード固有の SYLOGICALS.COM は持っていません。

WHITE のトランザクション・ログのサイズと格納場所を決定します。

DUA4 をクラスタ全体でマウントします。

 MOUNT/CLUSTER/SYSTEM DUA4: LOG4

トランザクション・ログ用のディレクトリを作成します。

$ CREATE/DIRECTORY DISK$LOG4:[LOGFILES]

SYS$JOURNAL を再定義します。

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> SET ENVIRONMENT/CLUSTER
SYSMAN> DO DEFINE/SYSTEM/EXECUTIVE_MODE SYS$JOURNAL - 
_SYSMAN> DISK$LOG2:[LOGFILES], DISK$LOG3[LOGFILES], DISK$LOG4:[LOGFILES]
SYSMAN> EXIT

SYS$MANAGER:SYLOGICALS コマンド・プロシージャを編集して，SYS$JOURNAL 定義を更新します。 次にトランザクション・ログを作成します。

$ RUN SYS$SYSTEM:LMCP
LMCP> CREATE LOG/SIZE=5000 DISK$LOG4:[LOGFILES]SYSTEM$WHITE.LM$JOURNAL
LMCP> EXIT

14.11 ノードの削除

この節では，DECdtm サービスを使用している場合にノードを削除する方法について説明します。

作業方法

スタンドアロン・マシンを使用している場合は，ステップ 1 ～ 8 までだけを実行します。

	重要: 以下の手順で示すステップのすべてを実行してください。 途中のステップを省略すると，データが壊れることがあります。

例

この例は，ノード BLUE の削除方法を示しています。 クラスタ・メンバおよびトランザクション・ログの格納場所を次のように想定しています。

どのノードもノード固有の SYLOGICALS.COM コマンド・プロシージャは持っていません。

ノード BLUE にログインします。

DECdtm サービスを使用しているすべてのソフトウェアを終了します。 BLUE のトランザクション・ログに実行中のトランザクションが含まれているかどうかを確認します。

$ RUN SYS$SYSTEM:LMCP
LMCP> DUMP/ACTIVE SYSTEM$BLUE.LM$JOURNAL
Dump of log file DISK$LOG3:[LOGFILES]SYSTEM$BLUE.LM$JOURNAL
⋮
Total of 0 transactions active, 0 prepared and 0 committed.
LMCP> EXIT

SYS$JOURNAL を再定義します。

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> SET ENVIRONMENT/CLUSTER
SYSMAN> DO DEFINE/SYSTEM/EXECUTIVE_MODE SYS$JOURNAL - 
_SYSMAN> DISK$LOG2:[LOGFILES], DISK$LOG4:[LOGFILES]
SYSMAN> EXIT

SYS$MANAGER:SYLOGICALS.COM コマンド・プロシージャを編集してSYS$JOURNAL 定義を更新します。

BLUE のトランザクション・ログを保管し，ノード BLUE をシャットダウンします。

$ @SYS$SYSTEM:SHUTDOWN.COM
⋮
Should an automatic system reboot be performed [NO]? NO

DECdtm サービスを使用するソフトウェアを再起動します。 その後，クラスタを再構成します。

$ @SYS$STARTUP:CLUSTER_CONFIG.COM

       Cluster Configuration Procedure

            1. ADD a node to a cluster.
            2. REMOVE a node from the cluster.
            3. CHANGE a cluster member's characteristics.
            4. CREATE a duplicate system disk for BLUE.

    Enter choice [1]: 2
⋮
 Updating network database...
 The configuration procedure has completed successfully.

14.12 DECdtm サービスの停止

省略時の設定では，システムをブートすると DECdtm サービスが自動的に開始され，トランザクション・ログが 1 つ 見つかるまで DECdtm プロセスTP_SERVER がチェックします。

DECdtm サービスを利用するソフトウェアを現在使用しないか，使用する予定がない場合は，DECdtm サービスを停止します。 これでメモリと CPU 時間を節約することができます。

OpenVMS Cluster 内ではすべてのノードで DECdtm サービスを停止します。

作業方法

14.13 DECdtm サービスの開始

ここで示す作業が必要になるのは，DECdtm サービスをいったん停止した後，DECdtm サービスを利用するソフトウェアを実行するようになった場合だけです。

作業方法

例

この例は，DECdtm サービスをクラスタ環境で開始する方法を説明しています。

SYS$DECDTM_INHIBIT の指定を解除してから TP_SERVER プロセスを起動します。

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> SET ENVIRONMENT/CLUSTER
SYSMAN> DO DEASSIGN/SYSTEM/EXECUTIVE_MODE SYS$DECDTM_INHIBIT
SYSMAN> DO @SYS$STARTUP.DECDTM$STARTUP.COM
SYSMAN> EXIT

SYS$MANAGER:SYLOGICALS.COM コマンド・プロシージャを編集して SYS$DECDTM_INHIBIT 定義を削除します。

制限事項

DECdtm は，作業を実行するために必要なオペレーティング環境がない場合，クラッシュの原因となる重大なシステム障害 (BUGCHECK) を引き起こします。 一般的な例は，仮想メモリの割り当ての障害です。 このようなエラーは，DECdtm の重大な例外として扱われるため，BUGCHECK で失敗し，結局はシステムがクラッシュします。

DECdtm は，主にそのデータ構造に依存して，トランザクションの完全性と一貫性を維持しています。 そのため，実行中にエラーや致命的な状況が発生すると，重大な矛盾として扱われます。 この結果，DECdtm は致命的な例外を発生させ，システムをクラッシュさせます。

オペレーティング環境では，仮想メモリや非ページング・プールなどのシステム・リソースに十分なバッファを確保することをお勧めします。 DECdtm を使用していない環境でクラッシュが発生した場合は，DECdtm を起動しないようにしてください。 (DECdtm を起動しないようにする方法については，14.12 項 「DECdtm サービスの停止」を参照してください。)

I64 プラットフォームでの「動的メモリ不足」に対処するための DECdtm 論理名の定義

KPB (Kernel Process Block) のメモリ割り当て中に発生する動的メモリ不足に対処するために，DECdtm 論理名が用意されています。 この設計ロジックは，リトライ・ロジックと呼ばれています。 このリトライ・ロジックでは，システム・テーブルの論理名 SYS$DECDTM_KPBALLOC_RETRYCNT を定義して，システム・サービス EXE$KP_ALLOCATE_KPB の呼び出しで戻り値が SS$_INSFMEM の場合にこのサービスを繰り返す回数 (リトライ・カウント) を設定できます。

システム論理名 SYS$DECDTM_KPBALLOC_RETRYCNT には，オプション文字列リテラル "MIN"，"DEF"，または "MAX" を設定します。 この文字列リテラルは，リトライ・カウント MIN=25，DEF=50，および MAX=100 を示します。

論理名 SYS$DECDTM_KPBALLOC_RETRYCNT がシステム・テーブルに見つからない場合，リトライ・ロジックでは省略時のカウント DEF=50 が使用されます。

例

$ DEFINE/SYS/EXEC SYS$DECDTM_KPBALLOC_RETRYCNT MAX

14.14 XA Gateway の使用 (Alpha および I64)

DECdtm/XA は，XA を使用するトランザクションを調整し，管理するためのサポートを提供します。 XA Gateway を使用することにより，DECdtm/XA は，他のトランザクション・マネージャ (TM) によって管理されるトランザクション内の他のリソース・マネージャ (RM) を参加させることができます。 このセクションでは，DECdtm XA Gateway サポートを設定し，使用する方法について説明します。

	注意: この章では，XA Specification は Distributed Transaction Processing: The XA Specification を意味します。

DECdtm/XA を使用し，DECdtm/XA サービスのスタートアップおよびシャットダウンが確実に正しく実行されるようにするには，以下のファイルを起動する必要があります。

コマンド @SYS$STARTUP:DDTM$XA_STARTUP.COM を，スタートアップ・データベースまたはコマンド・ファイル SYS$MANAGER:SYSTARTUP_VMS.COM に追加します。

コマンド @SYS$STARTUP:DDTM$XA_SHUTDOWN.COM をコマンド・ファイル SYS$MANAGER:SYSHUTDWN.COM に追加します。

以下の手順を実行して，DECdtm XA サービスが正しく実行されていることを確認します。

14.14.1 ゲートウェイの設定

	注記: HP DECdtm/XA Version 2.1 Gateway には現在，クラスタ単位のトランザクション回復サポートがあります。 クラスタ単位の DECdtm Gateway Domain Log を使用するアプリケーションのトランザクションは，どのような単一ノード障害からも回復できるようになりました。 障害が発生したノードの代わりに，残っているクラスタ・ノードで動作しているゲートウェイ・サーバが，トランザクション回復処理を起動できます。

XA Gateway は，XA 対応のリソース・マネージャとして，各トランザクション処理 (TP) プロセスに設定されます。 XA Gateway は XA トランザクション・マネージャ (TM) からの XA 呼び出しを処理し，これらの呼び出しを DECdtm システム・サービスの呼び出しにマップします。 これにより，DECdtm は，1 つの TP プロセスで使用されるどの DECdtm 対応のリソース・マネージャ (RM) に対しても，正しいイベントを送信できるようになります。

XA Gateway の操作は，RM からは透過的です。 このため，DECdtm の RM は，何も変更することなく XA Gateway で使用することができます。

XA Gateway では，ログ・ファイルを使用して，XA のトランザクションと DECdtm のトランザクションとのマッピングを記録します。 このログ・ファイルは，ゲートウェイ・サーバ・プロセス DDTM$XG_SERVER によって管理されます。

ゲートウェイ・ログ・ファイルは，XGCP ユーティリティを使用して作成します (『OpenVMS システム管理 ユーティリティ・リファレンス・マニュアル』を参照)。 ゲートウェイ・ログ・ファイルのサイズは，同時にアクティブになっているトランザクションの数によって決まります。 サイズは，XA TM が使用するトランザクション ID (TID) のサイズによって異なりますが，アクティブな各トランザクションごとに，最大で 600 バイトが必要です。 このゲートウェイ・ログ・ファイルは，必要に応じて自動的に拡張されます。

ゲートウェイ・ログ・ファイルは，論理名 SYS$JOURNAL によって指定されたディレクトリに常駐し，フォームの名前は SYSTEM$name.DDTM$XG_JOURNAL になります。 性能の最適化のために，各ゲートウェイ・ログ・ファイルおよび DECdtm ログ・ファイルを，個別の物理デバイスに移動し，物理デバイスのセットに対する検索リストとして SYS$JOURNAL を定義します。

XA Gateway では，各 OpenVMS Cluster ノードごとに，XA トランザクション・マネージャと XA Gateway ログ・ファイルとの間に関連付けが必要です。 この関連付けは，ゲートウェイ名を以下のように指定することによって管理されます。

• XGCP ユーティリティを使用して，ゲートウェイ名と同じ名前のゲートウェイ・ログ・ファイルを作成する (『OpenVMS システム管理 ユーティリティ・リファレンス・マニュアル』を参照)。

• ゲートウェイ名は，XA TM の制御下で実行されるアプリケーション内で Gateway RM が設定されるときに，xa_open 情報文字列内で指定される (XA RM の設定については，『OpenVMS Programming Concepts Manual, Volume II』を参照)。

• XA TM によって実行される最初の XA アプリケーションにより，ゲートウェイ名が OpenVMS Cluster のローカル・ノードに結び付けられる。 ゲートウェイ・サーバが終了するまで，ゲートウェイ名は，そのノードに結び付けられたままになる。

同じローカル・ノードで実行されるすべての XA アプリケーションは，同じゲートウェイ名を使用して設定する必要があります。 同じ名前を使用している複数の XA アプリケーションを，他の OpenVMS Cluster ノードで実行することはできません。 したがって，通常は OpenVMS Cluster の各ノードごとに，1 つのゲートウェイ名を定義し，1 つのゲートウェイ・ログ・ファイルを作成します。

ゲートウェイ名の関連付けを変更して，ゲートウェイ名を別の OpenVMS Cluster ノードに結び付けることができます。 ただし，そのノードがゲートウェイ・ログ・ファイルにアクセスできることが必要条件です。 ゲートウェイ名の関連付けを変更するには，以下の手順を実行します。

1. 元のノードで実行中のすべての XA アプリケーションを終了する。

2. XGCP ユーティリティを使用して，元のノードで実行中のゲートウェイ・サーバを終了する。

3. 新しいノードで実行中のすべての XA アプリケーションを終了する。

4. 新しいノードで実行中のゲートウェイ・サーバを終了し，ゲートウェイを再起動する。

5. 新しいノードで，元の XA アプリケーションを実行する。

	注意: ゲートウェイ・ログ・ファイルを損失から保護するため，常駐しているデバイスのシャドウイングを実行するなどの対策を講じる必要があります。 新しいログ・ファイルを生成したり，古いログ・ファイルを使用したりすると，元の記録ではすでにコミットしたことになっているトランザクションが，間違ってロール・バックされる可能性があります。 これは，データベースの間で相互に一貫性が失われたり，他のシステムまたはユーザに送信されるレポートとの一貫性が失われたりする原因になります。

ゲートウェイ・ログ・ファイルはサイズが大きいので，できるだけ削除しないようにしてください。 不要なゲートウェイ・ログ・ファイルをどうしても削除する場合には，まず DECdtm XGCP ユーティリティを使用して，このゲートウェイがもうどの用意されたトランザクションの参加者にもなっていないことを確認します。 このゲートウェイの参加者名は DDTM$XG/name です。

ゲートウェイ・サーバは，以下のシステム論理名を使用します。

• SYS$DECDTM_XG_REQS

  サーバによって処理される同時要求の数で，範囲は 100 ～ 100,000 です。 この数により，DDTM$XG がサーバとやりとりするために使用するグローバル・セッションのサイズと，サーバで必要とされる制限値が決まります。 このパラメータは，論理名 SYS$DECDTM_XG_REQS を定義することによって指定されます。 このパラメータへの変更は，サーバとすべてのクライアント・プロセスが終了されるまで，有効になりません。

  処理中にこのパラメータの値が制限値を超えた場合には，クライアント要求は，並行して処理されるのではなく，ブロックされます。

• SYS$DECDTM_XA_TRANS

  XA の同時トランザクションの予想される数の範囲は，1000 ～ 1,000,000 です。 これにより，サーバ内部で使用されるインデックス・テーブルのサイズが決まります。 このパラメータは，論理名 SYS$DECDTM_XA_TRANS を定義することによって指定されます。 このパラメータへの変更は，サーバが終了されるまで有効になりません。

  処理中にこのパラメータの値が制限値を超えた場合には，サーバによる CPU の使用量が増加します。 しかしながら，その影響は，このパラメータの値が制限値の 10 倍以上にならないと目立ちません。