スキーマの変更の発行

カスタマイズ › Web インターフェースのカスタマイズ › Web Screen Painter を使用してスキーマをカスタマイズする方法 › スキーマの変更の発行

スキーマの変更の発行

スキーマの変更が完了したら、変更を発行して、すべてのユーザが変更を利用できるようにします。 WSP では、新規作成または更新したテーブルと列がそれぞれ、データベースの wsptbl テーブルと wspcol テーブルに格納されます。

次の手順に従ってください：

オブジェクトエンジンと CA SDM ユーティリティプログラムを対象として、スキーマの変更を定義するファイルを新規作成/更新します。 WSP では、wsp_webengine オプションで指定された Web エンジン（デフォルトでは web:local）に、以下のファイルを作成します。

wsp.mods

Web Screen Painter で管理されている、オブジェクトエンジンに対するスキーマ変更がすべて記述されます。

wsp_schema.sch

Web Screen Painter で管理されている、すべてのテーブルおよび列が記述されます。

wsp_index.sch

Web Screen Painter で管理されているテーブルの DBMS インデックスが記述されます。

wsp.altercol

WSP で作成され、DBMS には未定義の新規列の名前が指定されます。

wsp.altertbl

WSP で作成され、DBMS には未定義の新規テーブルの名前が指定されます。さらに、WSP は、オブジェクトエンジンを備えたすべての CA SDM サーバに wsp.mods ファイルを配布します。
［ファイル］-［保存］-［発行］を選択します。
CA SDM サーバ上に必要なファイルが作成されますが、これらがリサイクルされることはありません。このため、この操作の直後は新規ファイルの影響はありません。ただし、ファイルの作成後は、次回 CA SDM サービスがリサイクルされるときに、これらのファイルが使用されます。
標準設定を使用している場合は、以下の手順に従います。
- プライマリサーバ上の CA SDM サービスをシャットダウンし、以下のコマンドを実行します。
```
pdm_publish
```
  このコマンドは、物理 DBMS を変更し、新規スキーマの情報を格納します。
  
  重要： pdm_publish プロセスを実行すると、ほかのユーザに重大な影響を及ぼします。スキーマの変更の発行は慎重に計画するようにしてください。 CA SDM の変更要求を使用してスキーマ発行のスケジュールを調整し、事前の承認を得ることをお勧めします。
高可用性設定を使用している場合は、以下の手順に従います。
1. バックグラウンドサーバ上で以下のコマンドを実行して、サポートオートメーションを使用しているすべてのアクティブなユーザに作業を保存するよう通知します。
```
sa_server_notifier [-h] | [-q seconds] | [-c]
```
  -h
  
  ヘルプページを表示します。
  
  -q seconds
  
  このオプションは、ローカルサーバ（バックグラウンド）に指定された時間間隔内に休止するよう通知します。この間隔は、サーバがオフラインになるまでの秒数です。このオプションは、スタンバイサーバまたはアプリケーションサーバには使用できません。
  
  -c
  
  このオプションは、以前に送信された休止リクエストをキャンセルします。
  
  バックグラウンドサーバ上でサポートオートメーションを使用しているすべてのアクティブなユーザにポップアップメッセージが表示されます。このメッセージは、ユーザにサーバのシャットダウンと、シャットダウンまでに残されたスケジュールされた時間について通知します。ユーザは自分の作業を保存し、そのスケジュールされた時間内にログアウトする必要があります。
2. バックグラウンドサーバ上の CA SDM サービスをシャットダウンします。
  重要： WSP から「保存して発行」が実行された後、スタンバイまたはアプリケーションサーバ上の CA SDM サービスを再起動しないでください。このアクションによって、高可用性設定が中断されます。スタンバイまたはアプリケーションサーバ上の CA SDM サービスが停止されているときに、サービスを開始したい場合は、CA SDM サービスを開始する前に、サーバ上で pdm_server_control -v コマンドを実行してバージョン管理を抑制します。
  
  重要： アクティビティの発行中にバックグラウンドサーバに障害が発生した場合は、WSP の変更を回復するようにしてください。詳細については、「バックグラウンドサーバの障害時の WSP 変更の回復」を参照してください。
3. 新しいバックグラウンドサーバとして昇格させるスタンバイサーバ上で、以下のコマンドを実行します。
```
pdm_server_control –b
```
  -b
  
  ローカルのスタンバイサーバにバックグラウンドサーバになるよう通知します。スタンバイサーバがすでに実行されている必要があります。このサーバが実行されていない場合は起動されますが、フェールオーバは実行されません。フェールオーバを開始するには、コマンドを再度実行します。
  
  バックグラウンドサーバは自動的にシャットダウンし、スタンバイサーバが新しいバックグラウンドサーバとして昇格されます。この変更は、エンドユーザセッションには影響を与えません。進行中の更新（存在する場合）は保存され、新しいバックグラウンドサーバがオンラインになるまで遅延されます。
4. スキーマの変更を使用して DBMS を更新するには、元のバックグラウンドサーバ（現在のスタンバイサーバ）上で以下のコマンドを実行します。
```
pdm_publish
```
  pdm_publish コマンドは、CA SDM の次の起動でスタンバイサーバとバックグラウンドサーバの同期を抑制する制御ファイルを作成します。このアクションは、pdm_publish によって実行されたスキーマファイルの変更を保持するために必要です。このコマンドは、スキーマの変更の正常な発行の後、必要に応じて 2 番目のフェールオーバを実行します。正常な発行の最後に、以下のメッセージがユーザに表示されます。
```
このスタンバイ サーバで pdm_publish によって CA Service Desk Manager を開始し、フェールオーバを実行しますか? (Y/N)
```
  - 「Y」と入力すると、pdm_publish はスタンバイサーバ上で CA SDM サービスを開始し、自動的にフェールオーバを実行します。すべてのアプリケーションサーバ上でスキーマの変更を適用するには、手順 g に進みます。
  - 「N」と入力した場合は、手順 e に進みます。
5. スタンバイサーバ（元のバックグラウンドサーバ）上で CA SDM サービスを開始します。
  この起動では pdm_publish によって作成された制御ファイルが検出されますが、スタンバイサーバとバックグラウンドサーバの同期は実行されません。同期が実行されないため、この起動では pdm_publish によって実行された変更が保持されます。
  
  重要： pdm_publish の後に元のバックグラウンドサーバにフェールオーバできないとサービスが中断されるため、これらの指示に正確に従うようにしてください。
6. スタンバイサーバ（元のバックグラウンドサーバ）を再度バックグラウンドサーバにするには、そのサーバ上で以下のコマンドを実行します。
```
pdm_server_control –b 
```
  このサーバが再度スタンバイサーバになったときにバージョン管理が正常に機能するように、このコマンドでは制御ファイルも削除されます。
7. アプリケーションサーバ上で、以下のコマンドを実行します。
```
pdm_server_control -q interval -s server_name
```
  -q interval -s server_name
  
  ローカルまたはリモートアプリケーションサーバに指定された時間間隔内に休止するよう通知します。この間隔は、サーバがオフラインになるまでの秒数です。 server_name なしでこのオプションを使用した場合は、ローカルサーバが休止するよう通知されます。このオプションは、バックグラウンドまたはスタンバイサーバには使用できません。
  
  指定したアプリケーションサーバ上のすべてのアクティブなユーザにポップアップメッセージが表示されます。このメッセージは、ユーザにサーバのシャットダウンと、シャットダウンまでに残されたスケジュールされた時間について通知します。ユーザは自分の作業を保存し、そのスケジュールされた時間内にログアウトする必要があります。ユーザが自分の作業を再開するには、更新されたアプリケーションサーバにログオンします。
8. すべてのスタンバイサーバを再起動します。