図 10-1: データベース整合性保証ユーティリティ コンフィグレーションファイルの構成
Empress プロセスが kill された場合（SIGKILL、またはマシン障害によるダウン) 適切なクリーンアップ処理が行われない可能性があります。 その結果、例えば所有者の存在しないロックが後に残ったり、 サーバー接続が終了されず、開放されないことがあります。 これらの問題は他のプロセスがデータベースにアクセスできない原因になる可能性があります。
マルチタスクの環境においては、 残されたレコードロックや未解決のトランザクションにより、 他のプロセスに影響を及ぼすことは許しがたい行為となります。 この問題を解決するためにデータベースのチェックや 必要なクリーンアップ操作の実行するための "empclean"と呼ばれるデータベース整合性保証 ユーティリティを紹介します。以下はその処理になります。
プロセスがいつ、どのように途中終了したかにより、 データベースが破損の状況は異なります。 "empclean"は、これらの多くの状況の修復のために それぞれの修復クラスを実行することができます。 各クラスを以下に説明します。
サーバーを実行しているマシンで障害が発生した場合、 そのマシン上のサーバーは途中終了します。 リブートするたびにサーバーを開始するシステムではない場合、 サーバーは手動で再スタートするまでは有効ではありません。 "empclean"は、サーバーが実行されているマシン上で 途中終了したサーバーをチェックすることができ、 必要であるならば再スタートすることができます。
サーバーにアクセスしているクライアントが実行中にマシンに障害が発生した場合、 サーバーから削除されません。 その場合、"empclean"を実行することで、 サーバーに記憶されているすべてのクライアントの存在を確認します。 存在しないすべてのクライアントはサーバーから削除されます。 これは empsvadm server_name svremove client_idコマンドの自動化と 等しい処理になります。
サーバーは制限された数のクライアントプロセスのみを その内部で記憶しているため、この操作は重要であり、 そのため、途中終了したクライアントプロセスは定期的に削除すべきです。
処理速度向上のためにEmpressは、テーブルスキーマについてのすべての情報を
コンパイルし、データ辞書内に個々のレコードとしてこの情報を格納しています。
"empclean"は、データ辞書のエントリの再コンパイルを強制的にすることができます。
10.2.2.2 部分的な再コンパイル
この操作は、データ辞書全体をコンパイルせず、テーブル情報のみ再コンパイルします。
この矛盾はテーブルスキーマを変更する操作が中断された場合に生じることがあります。
10.2.2.3 矛盾したデータ辞書エントリの削除
"empclean"は、存在しないテーブルのデータ辞書のエントリを削除することができます。
"empclean"は、 データベース・テーブルに関係ないデータベースディレクトリ内の 以下の種類の中途半端なファイルを削除します。
この操作が行われている間はデータ定義言語(DDL)コマンドは データベース上で実行することはできません。 DDLコマンドとはデータベーススキーマを変更するコマンドです。
データベースディレクトリ内はEmpressデータベースファイルだけでなくてはなりません。 このディレクトリに他のファイルが存在した場合、"empclean"はそれらのファイルを 削除します。
サーバーまたはクライアントが予期せず途中終了したとき、
その時まで進んでいたトランザクションは解決されません。
"empclean"は、これらのトランザクションの解決を強制におこなう
ことができます。
完全なトランザクションはコミットされ、途中で終了したトランザクションは
キャンセルされます。これはempwarm コマンドの自動化と等しく、
またアクティブはトランザクションには影響しません。
10.2.4 残ったロックのクリア
クライアントが途中終了したことにより保持されていた シェアードメモリおよびファイルロックはクリアされていない可能性があります。 "empclean"は、 既に存在していないクライアントによって保持されていたロックを見つける ことができ、それらをクリアすることができます。 これはempadm database_name lockclear client_idコマンドの 自動化に等しく、client_idは、既に有効ではないクライアントの Empress IDになります。
メインレコードデータファイル (.relファイル) と オーバーフローデータファイル(.dtf ファイル) は、 empcleanコマンドにより修復することができます。 これはレコードカウントおよびテーブルのフリーリストの修復が含まれます。
.relファイルまたは.dtfファイルの修復が必要である場合、 修復しなくてはならない箇所だけを変更し、empcleanは、新しいファイルを 作成しません。 .relファイルまたは.dtfファイルが破損し、修復が必要な場合、 empcleanは、テーブルのインデックス(.ixファイルおよび .ixlファイル)を再作成します。
この操作は、データが多いテーブル上では非常に遅い可能性があります。 また、問題を見つけるためのファイル走査により、 各テーブルへの排他的なアクセスが要求され、 テーブルは完全に修復されるまでアクセスはできなくなります。
Empressは、多くの目的でテンポラリファイルを利用します。 例えば、バルク型のアトリビュートのオーバーフローデータは EMPRESS変数 MSTMPDIRに指定されたディレクトリ以下の ディレクトリ中のファイルへ格納されます。 クライアントが突然、、kill された場合、そのクライアントが作成した テンポラリファイルとディレクトリは削除されません。 empcleanは、既に存在しないクライアントを見つけ、 それらが作成したテンポラリファイルを削除することができます。 この操作では任意のデータベースの指定はありません。
この操作においてempclean プロセスは、 ファイルを削除の許可を持つ有効なユーザーID が必要になることに 注意してください。
すべてのEmpressデータベースで、 関連付けのためのコーディネイターが存在します。 コーディネイターは、データベースにアクセスするプロセスを を記録しています。
Empressプロセスが、適切なクリーンアップ処理なしに死んだ場合、 empcleanは、コーディネイターファイルからそのプロセスのエントリを 削除します。
empcleanは、消失したシェアードメモリパーティションを見つけた場合、 シェアードメモリパーティションを自動に再作成します。
データベース整合性保証ユーティリティempcleanは、 次の構文になります。
empclean -m congif_file
または
empclean [-verify] database_name [command {command}]
または
empclean [-verify] -f config_file [database_name [command {command}]]
commandは、
| recompile_all | データ辞書に登録されているすべてのテーブル情報の再コンパイル |
| recompile | データ辞書に登録されているテーブル情報の再コンパイル |
| table_check | このコマンドは以下を行います。
|
| data_check | 問題のある.relファイルと.dtfファイルを見つけ、修復します。 |
| rebuild_user_indices | ユーザーテーブルのインデックスを再作成します。 |
| temp | 残っているテンポラリファイルを削除します。 このオプションの使用は ファイルを削除の許可を持つ有効なユーザーID が必要になります。 |
最初の構文の"-m"オプションは、 後にempcleanによって使用される コンフィグレーションファイルを作成するための 対話型のセッションを開始します。 このセッションでは、実行したい整合性チェックや empcleanを実行して欲しいマシンのホスト名、 同様にそのホストに関連する他の情報を指定します。 サーバーを通してempcleanの実行による修復が必要な場合では サーバーコンフィグレーションファイルおよび グローバルデータディクショナリファイル、 また、サーバ名の指定が必要になる場合もあります。
2番目の構文は、わざわざコンフィグレーションファイルを 作成して行いたくない場合に有用です。 この構文を使う場合、データベースの名前と、 そのデータベースに実行するコマンドオプションを指定します。 コマンドオプションの指定がなく、データベースのみの指定である場合、 デフォルトセットの整合性チェックが実行されます。 このセットは以下のデータベースの整合性に対してのチェックを行います。
これは常に他の操作の前に実行する基本セットになります。
また、以下のようにコマンドのリストを指定する場合、
empclean mydatabase recompile temp
コマンドライン上に指定されたコマンドは、 は指定されたデータベースに対し、 操作の基本セットを加え、実行されます。
"-f"オプションは、 "-m"オプションによって作成した コンフィグレーションファイル内の 定義された整合性チェックを実行するために empcleanに命令します。 コンフィグレーションファイル内の 定義された整合性チェックは、すべてのデータベース およびクライアント上で実行されます。 注意として、empcleanの実行は時間がかかることがあるため、 数種類のコンフィグレーションファイルを作成することを推奨します。 例えば時間単位でのチェック用、また日単位、週単位など。
"-f"オプションとともにデータベースを指定した場合、 (例えば以下の指定の場合)
empclean -f myconfigfile mydatabase
対象となるデータベースがコンフィグレーションファイル内で 指定されていますが、（例ではmyconfigfile内になります。) 整合性チェックはコマンドライン上で与えられた データベース上のみで実行されます。 （例ではmydatabase上になります。) また、データベース名は物理データベース名または論理データベース名の どちらかになることに注意してください。
"-verify"オプションが指定された場合、 empcleanは、見つかった問題や、"-verify"が 指定されない場合に起こるであろう問題を報告するだけで、 実際の修復処理はおこないません。
"-verify"オプションは以下のケースでは使用に 制限される可能性があります。
このセクションではempcleanのコンフィグレーションファイルの 作成の手順を示し、そのファイルの構成およびコンフィグレーションファイルの いくつかのカスタマイズに関して説明します。
-mオプションを指定し、empcleanの実行することで 対話型セッションを開始します。その間に修正を望むデータベースおよびサーバー名、 またそれらが存在するマシン名を尋ねられます。 質問に回答することにより、empcleanによって利用される コンフィグレーションファイルは作成されます。
以下は、データベースサーバーではないスタンドアロンマシン上の ローカルデータベースの修復のためのコンフィグレーションファイルの生成の 例です。 マシン名を"gold"、データベース名を"physics"、 "/work"ディレクトリに位置しているとします。
以下のように入力し、コンフィグレーションのセッションを開始します。
empclean -m config_file
引数で指定された"config_file"は、コンフィグレーション情報が 記録されるファイル名になります。 ファイルが既に存在している場合、empcleanは 新しいコンフィグレーションを書き込む前にファイルの内容をすべてクリアする ことに注意してください。
コンフィグレーションが開始されると以下のメッセージを出力します。
これは、EMPRESS Cleanup コンフィギュレーションファイルを作成するときの ヘルプユーティリティです。 ローカルホストは gold です。
データベース名を指定するプロンプトが表示されますので、 empcleanを実行したい各ローカルデータベースの フルパスを入力します。 この質問のセクションの終了は空白行を入力します。（リターンだけを入力）
すべてのデータベース名を入力して下さい。 （論理名 または フルパス、１行に１つ。） リターンで終了。 データベース:/work/physics データベース:<Return>
ここではローカルデータベースに関してのみを扱っているため、サーバーコンフィグレーション ファイル、およびサーバーに関しては無視します。 また、ここでの例は物理データベース名のみの指定で、 グローバルデータディクショナリ（論理データベース名）の指定は行いません。
すべてのサーバコンフィギュレーションファイルをリストして下さい。 フルパスを指定して下さい。 サーバコンフィギュレーションファイル:<Return> どのサーバが自動的に再開始しますか？ （１行に１つ） サーバ:<Return> すべてのグローバルデータディクショナリーをリストして下さい。 フルパスを指定して下さい。 グローバルデータディクショナリー :<Return>
次に指定したすべてのデータベース上で実行したい操作を尋ねられます。 ここでの例では、"temp"と"recompile"を指定します。
以下のｃｌｅａｎｕｐオペレーションは有効です。: temp recompile recompile_all table_check data_check rebuild_user_indices すべてのデータベース上でどのオペレーションを実行させますか？ （１行に１つ） オペレーション: temp オペレーション: recompile オペレーション: <Return>
次のセクションでは、指定されたそれぞれのデータベースの情報について尋ねられます。 この例では、"physics"データベースに対し、"temp"と"recompile" の操作に加えて、"data_check"の操作を追加指定します。
各データベースに対するオペレーションについて尋ねます。
データベース '/work/physics':
どの追加オペレーションを実行させますか？
以下の中から１つ以上選んで下さい。
recompile_all table_check data_check rebuild_user_indices
オペレーション:data_check
オペレーション:<Return>
次のセクションは、他のホストがこのデータベースを使用しているかどうかチェックします。 ここでの例はローカル利用のみであるため、他のホストを指定する必要はありません。
現在、以下のホスト情報があります。:
gold
empclean に無関系なホストを１行に１つずつ
入力してください。
ホスト:<Return>
データベースに関するすべての質問を解決しました。
このセクションは、まだ触れられていないすべてのホストのための入力で、 ここでの例はローカル利用のみであるため、他のホストを指定する必要はありません。
以下のホストを宣言しました。:
gold
他のホストをリストして下さい。
ホスト:<Return>
次のセクションは、このコンフィグレーションファイルを使用するそれぞれの ホストごとの固有な情報を取得します。 リモートシェルがこのホスト上で実行可能かを尋ねられますが、ここでは ローカルアクセスだけのデータベースですので"y"を入力します。
各ホストについての情報を尋ねます。 ホスト 'gold': empclean に関連するすべてのホストは リモートシェルを実行可能ですか ？ (y/n) y
最後の質問は途中で残ってしまったEmpressのテンポラリファイルを チェックするためのテンポラリディレクトリのパスを入力します。 これはMSTMPDIRにユーザーの環境として別の値を設定している場合 に有用です。利用する場合は、このホスト上のデータベースにアクセスする ユーザーによって設定されたMSTMPDIRの値をすべて指定すべきです。
ＥＭＰＲＥＳＳのテンポラリファイルに使用している ／ｔｍｐ
以外のディレクトリを明記してください。
テンポラリディレクトリ:/var/work
テンポラリディレクトリ:<Return>
最後の２行は、コンフィグレーションファイルの作成に成功した場合に表示されます。 間違いがないかどうかを確かめるためにコンフィギュレーションファイルの内容を チェックすることを推奨します。
empclean コンフィギュレーションファイルが作成されました。 情報が正しいか調べ、確かめて下さい。
このセッションによってコンフィグレーションファイルは、 以下のように作成されます。
MSCLCOMMAND=temp
MSCLCOMMAND=recompile
MSCLHOSTNAME=gold
MSCLTMPDIR=/var/work
MSCLHOSTNAMEEND
MSCLDATABASE=/work/physics
MSCLCOMMAND=data_check
MSCLDATABASEEND
以下は、サーバーを通してアクセスされるデータベースの修復のための コンフィグレーションファイルの作成の例です。 例の環境として、物理データベース名は "physics"、 "/work"ディレクトリに位置します。 論理データベース名は、"physics-db"で、 ホスト名が"gold"のマシン上で実行している "physics-srv" サーバーを通じてアクセスされます。 リモートホストであるホスト名"ruby"のクライアントもまたデータベースに アクセスします。
以下のように入力し、コンフィグレーションのセッションを開始します。
empclean -m config_file
引数で指定された"config_file"は、コンフィグレーション情報が 記録されるファイル名になります。 ファイルが既に存在している場合、empcleanは 新しいコンフィグレーションを書き込む前にファイルの内容をすべてクリアする ことに注意してください。
コンフィグレーションが開始されると以下のメッセージを出力します。
これは、EMPRESS Cleanup コンフィギュレーションファイルを作成するときの ヘルプユーティリティです。 ローカルホストは gold です。
この例ではサーバーを通してデータベースにアクセスするため、 論理データベース名を入力します。
すべてのデータベース名を入力して下さい。 （論理名 または フルパス、１行に１つ。） リターンで終了。 データベース:physics-db データベース:<Return>
次にサーバーコンフィグレーションファイルをフルパスで指定し、 また、それが存在するホスト名を指定します。
すべてのサーバコンフィギュレーションファイルをリストして下さい。 フルパスを指定して下さい。 サーバコンフィギュレーションファイル:/work/scf どのホスト上ですか？ '*' はすべてです。:gold サーバコンフィギュレーションファイル:<Return>
自動的に再起動したいサーバー名を入力します。
どのサーバが自動的に再開始しますか？ （１行に１つ） サーバ:physics-srv サーバ:<Return>
次にグローバルデータディクショナリのフルパスを入力します。
すべてのグローバルデータディクショナリーをリストして下さい。 フルパスを指定して下さい。 グローバルデータディクショナリー :/work/gdd どのホスト上ですか？ '*' はすべてです。:gold グローバルデータディクショナリー :<Return>
次に、指定したすべてのデータベース上で実行したい操作を尋ねられます。 ここでの例では、"temp"と"recompile"を指定します。
以下のｃｌｅａｎｕｐオペレーションは有効です。: temp recompile recompile_all table_check data_check rebuild_user_indices すべてのデータベース上でどのオペレーションを実行させますか？ （１行に１つ） オペレーション: temp オペレーション: recompile オペレーション: <Return>
次のセクションでは、指定されたそれぞれのデータベースの情報について尋ねられます。 この例では、"physics-db"データベースに対し、"temp"と"recompile" の操作に加えて、"data_check"の操作を追加指定します。
各データベースに対するオペレーションについて尋ねます。
データベース 'physics-db':
どの追加オペレーションを実行させますか？
以下の中から１つ以上選んで下さい。
recompile_all table_check data_check rebuild_user_indices
オペレーション:data_check
オペレーション:<Return>
次のセクションは、他のホストがこのデータベースを使用しているかどうかチェックします。 ここでの例のデータベースでは、マシン"ruby"からアクセスされるため、 "ruby"を入力します。
現在、以下のホスト情報があります。:
gold
empclean に無関系なホストを１行に１つずつ
入力してください。
（注:日本語メッセージが誤っています。以下が正しいメッセージです。）
emplean が関係すべき他のホストがある場合、入力してください。
ホスト:ruby
ホスト:<Return>
データベースに関するすべての質問を解決しました。
このセクションは、まだ触れられていないすべてのホストのための入力で、 この例ではこれ以外の他のホストがこのデータベースを利用しないため、 <Return>を入力します。
以下のホストを宣言しました。:
gold
他のホストをリストして下さい。
ホスト:<Return>
次のセクションは、このコンフィグレーションファイルを使用するそれぞれの ホストごとの固有な情報を取得します。 ホストごとに他のホストがリモートシェルを利用でき、加えて "/work"ディレクトリは ホスト上のEmpressテンポラリファイルを格納するために利用される ことが可能であるかを指示する必要があります。
各ホストについての情報を尋ねます。
ホスト 'gold':
empclean に関連するすべてのホストは
リモートシェルを実行可能ですか ？ (y/n) y
ＥＭＰＲＥＳＳのテンポラリファイルに使用している ／ｔｍｐ
以外のディレクトリを明記してください。
テンポラリディレクトリ:<Return>
ホスト 'ruby':
empclean に関連するすべてのホストは
リモートシェルを実行可能ですか ？ (y/n) y
ＥＭＰＲＥＳＳのテンポラリファイルに使用している ／ｔｍｐ
以外のディレクトリを明記してください。
テンポラリディレクトリ:/var/work
テンポラリディレクトリ:<Return>
最後の２行は、コンフィグレーションファイルの作成に成功した場合に表示されます。 間違いがないかどうかを確かめるためにコンフィギュレーションファイルの内容を チェックすることを推奨します。
empclean コンフィギュレーションファイルが作成されました。 情報が正しいか調べ、確かめて下さい。
このセッションによってコンフィグレーションファイルは、 以下のように作成されます。
MSCLSERVER=physics-srv
MSCLCOMMAND=temp
MSCLCOMMAND=recompile
MSCLHOSTNAME=gold
MSCLGLOBALDATADICT=/work/gdd
MSCLSERVERCONFFILE=/work/scf
MSCLHOSTNAMEEND
MSCLHOSTNAME=ruby
MSCLTMPDIR=/var/work
MSCLHOSTNAMEEND
MSCLDATABASE=physics-db
MSCLCOMMAND=data_check
MSCLDATABASEEND
empclean -mにより自動的にファイルはセットアップされますが、 そのファイルの内部構成について述べることは、 提供した情報と一致するコンフィグレーションファイル内の それぞれのシステム変数がどのようなものであるかを 理解することであなたの助けとなります。 このことは、すばやく修正する場合において必要とされ、 システムエディタを使ってコンフィグレーションファイルを 編集をすることができます。
empcleanのコンフィグレーションファイルは複数の ブロックから構成されています。 １つのブロックは１つのタイプの情報を扱い、１ブロックは１行以上含まれています。 また、Empress変数のいくつかを定義する場合もあります。 empclean -mによって生成された順にブロックを説明しますが、 ファイル中ではそれが任意の順に現われることがあります。
図 10-1: データベース整合性保証ユーティリティ コンフィグレーションファイルの構成
このブロックでは、このコンフィグレーションファイルを 利用する場合、再起動させるためのサーバー名を指定します。 サーバーが複数ある場合、それぞれ１行づつ指定します。 指定は以下のフォームになります。
MSCLSERVER=servername
このブロックは empclean -mを実行したときの 以下の質問と一致します。
どのサーバが自動的に再開始しますか？ （１行に１つ） サーバ:
サーバーを指定しない場合、このブロック中のエントリはありません。
このブロックでは、すべてのデータベース上で実行するオペレーションを指定します。 これらのオペレーションのことをグローバルオペレーションと呼びます。 指定は以下のフォームになります。
MSCLCOMMAND=command
コマンドが複数ある場合、それぞれ１行づつ指定します。 このブロックは複数の行を持つことが出来ますが、 同じコマンドを何回も指定しても、それぞれのコマンドは １回のみ実行されます。 コマンドを指定しない場合、このブロック中のエントリはありません。
コンフィグレーションファイル中の操作のうちの いずれかがデータベース修復をおこなう操作の場合、 整合性チェックの基本セットが実行されます。 この基本的なセットは次のデータベース矛盾をチェックします。
実行可能なコマンド
| recompile_all | すべてのテーブルに対してのデータ辞書エントリの再コンパイル |
| recompile | コンパイルエントリがヌルであるテーブルのデータ辞書エントリの再コンパイル |
| table_check | このコマンドは以下を行います。
|
| data_check | 不整合な.relファイルおよび.dtfファイルを見つけ、修復します。 |
| temp | 残ったテンポラリーファイルの削除。 このオプションは、empcleanプロセスを実行するユーザーに ファイルを削除する許可が必要です。 |
このブロックは empclean -mを実行したときの 以下の質問と一致します。
以下のｃｌｅａｎｕｐオペレーションは有効です。: temp recompile recompile_all table_check data_check rebuild_user_indices すべてのデータベース上でどのオペレーションを実行させますか？ （１行に１つ） オペレーション:
このブロックは以下のホストに関係する情報を含みます。
それぞれのブロックは １つのホストに対する定義情報を含み、 以下の１対の変数によって区切られます。
MSCLHOSTNAME=host_name
.
.
.
MSCLHOSTNAMEEND
グローバルデータディクショナリのための MSCLGLOBALDATADICT変数は、 empclean -mを実行したときの 以下の質問と一致します。
すべてのグローバルデータディクショナリーをリストして下さい。 フルパスを指定して下さい。 グローバルデータディクショナリー : どのホスト上ですか？ '*' はすべてです。:
サーバーコンフィグレーションファイルのための MSCLSERVERCONFFILE変数は、 empclean -mを実行したときの 以下の質問と一致します。
すべてのサーバコンフィギュレーションファイルをリストして下さい。 フルパスを指定して下さい。 サーバコンフィギュレーションファイル: どのホスト上ですか？ '*' はすべてです。:
通常、empcleanは、リモートシェルコマンドの位置はデフォルトの 位置を指定しますが、 リモートシェルコマンドが、標準以外の場所にある場合、 そのコマンドの絶対パスをMSCLRMTSHELLCMDに設定します。 例えば以下のように設定します。
MSCLRMTSHELLCMD=/usr/remote/rsh
empcleanは、 テンポラリディレクトリに中途半端に残った Empressのテンポラリファイルをチェックします。 テンポラリディレクトリとして、 ホスト上の$EMPRESSPATH/config/initfile中にある MSTMPDIRによって指定されたテンポラリディレクトリを 加えます。
MSCLTMPDIR=/var/work MSCLTMPDIR=//usr2/acctg/work
この変数は、 empclean -mを実行したときの 以下の質問と一致します。
ＥＭＰＲＥＳＳのテンポラリファイルに使用している ／ｔｍｐ
以外のディレクトリを明記してください。
テンポラリディレクトリ:
リモートホストからデータベースサーバーにアクセスするプロセスのクリーンアップ のためにempcleanは、そのホスト上のシェルを起動するための許可が 必要です。 デフォルトでは、empcleanは、 すべてのリモートホスト上で リモートシェルが起動できると仮定しています。 他のホスト上のリモートシェルを起動するいくつかのホストを 許可する場合、 変数MSCLRMTHOSTにホスト名を設定することにより リモートホストのリストを指定することが可能です。 エントリ指定がされていない場合は、 empcleanは、すべてのリモートホストに通信 できると仮定します。 また、MSCLRMTHOST=LOCALと指定された場合は、 empcleanはリモートホストに 通信することができないと仮定します。 それぞれのリモートホスト名は１行づつ設定する必要があり、 このブロックに複数指定することができます。 例えば以下のように指定します。
MSCLRMTHOST=ruby MSCLRMTHOST=diamond
この変数は、empclean -mを実行したときの 以下の質問と一致します。
empclean に関連するすべてのホストは リモートシェルを実行可能ですか ？ (y/n) n リモートシェルに達するのはどのホストですか？ host_name1 host_name2 ... ホストを入力してください、（１行に１つ） ホスト:
MSCLDATABASE=database_name
.
.
.
MSCLDATABASEEND
このMSCLDATABASE変数は、 empclean -mを実行したときの 以下の質問と一致します。
すべてのデータベース名を入力して下さい。 （論理名 または フルパス、１行に１つ。） リターンで終了。 データベース:
オペレーションはグローバルオペレーションと同じような フォームで指定します。
MSCLCOMMAND=command
それぞれのオペレーションは１行に指定する必要があり、また、 ブロック内のオペレーションは複数の種類を指定することが可能です。 この変数は、 empclean -mを実行したときの 以下の質問と一致します。
各データベースに対するオペレーションについて尋ねます。
データベース 'database_name':
どの追加オペレーションを実行させますか？
以下の中から１つ以上選んで下さい。
recompile_all table_check data_check rebuild_user_indices
オペレーション:
次の２つの変数は、 コンフィグレーションファイルの MSCLDATABASEセクション中に 手作業で設定することができます。 empclean -m によって作成されたコンフィグレーションファイルを 編集することによりこれらの変数を設定できます。
MSCLDATACHECKTABLE変数は、 data_check操作を実行する際に チェックすべきテーブルのみを明示的に 指定することを許します。 各MSCLDATACHECKTABLEは、１つのテーブル名か Empress SQLスタイルのパターンマッチングによる指定ができます。
表 10-1: パターンマッチ文字
| 文字 | 説明 |
| ? | その位置に対応する任意の文字が対象 |
| * | ゼロかそれ以上の繰り返しの任意の文字が対象 |
| [...] | その位置に対応する任意の文字セットが対象
例えば [abc]は、 "a" または "b" または "c" に一致します。 |
| {...} | 固定長のパターンでゼロかそれ以上の繰り返しの任意の文字が対象
例えば {[a-z]} は、アルファベットの小文字と一致します。 |
| [.-.] |
その位置に対応する文字の範囲が対象
例えば[a-cf-i]は、 "a", "b", "c", "f", "g", "h", "i"に一致します。 |
| [^...] |
その位置に対応する文字セットまたは文字範囲外の任意の文字が対象
例えば [^123] は、 "1", "2" "3"; を除いた文字に一致します。 [^a-d] は、 "a", "b","c", または "d" を除いた文字に一致します。 |
| ...|... |
"|"を境にして、そのいずれかの側の指定に一致する必要があります。
例えば"ab|cd"は、 "ab" または "cd"の一方に一致する必要があります。 |
| ...&... |
"&"を境にして、その両方の指定に一致する必要があります。
|
| \ | "?", "*", "|", "&", "{", "}", "[", "]", "\" などの特殊文字の前に"\"を指定することで、その設定した文字は 特殊文字ではなく文字どおりに解釈されます。 |
２番目の変数、MSCLDATACHECKSINCEは、 data_checkオペレーションが 指定された時点から変更があったテーブル上でのみ実行する 指定をおこなうことができます。 MSCLDATACHECKSINCEが指定されない場合、 最後のチェックが実行されてから、変更があったテーブルのみを 実行することになります。 MSCLDATACHECKSINCEにALWAYSが設定された場合は、 テーブルが変更されるごとにempcleanは実行されます。 最後に次の構文を使って、日、時間あるいは分、期間を指定してもかまいません。
MSCLDATACHECKSINCE=nnn units
ここでのnnnは、0ではない正の整数を指定します。 また、unitsは、d(日付指定のための) h (時間指定のための)m(分指定のための)の いずれかを指定します。例えば、
MSCLDATABASE=physics-db
MSCLCOMMAND=data_check
MSCLDATACHECKTABLE=elements
MSCLDATACHECKSINCE=24 h
MSCLDATABASEEND
この例での指定は、physics-dbデータベース内のelementsテーブル
のみを過去24時間内に変更があった場合にチェックします。
10.5 データベース整合性保証ユーティリティプログラムの実行
Empressのプロセスがデータベースにアクセスしているときに SIGKILLコマンドによって killされたり、マシンが クラッシュした場合には、データベース整合性保証ユーティリティプログラムを 実行する必要があります。 これは、Empressのプロセスがkillされた場合、Empressの 終了処理が正常に行われないためであり、データベースが不整合な状態に なっている可能性があります。 この場合、シェルコマンドライン上からempcleanを実行します。 また、UNIXのcronの機能を使って定期的にempcleanを 実行することはDBAにとり有益です。 この機能を利用することで、 月単位、週単位またユーザー指定によるどのような期間でも empcleanを実行するように指定ができます。
Empress社では、rootユーザーによるempcleanの実行を 推奨しません。
例えば、サンマイクロシステムのワークステーション上のcronで 日単位で実行する場合は以下のような指定ができます。
15 1 * * * EMPRESSPATH=/usr2/empress/v8.62 $EMPRESSPATH/bin/empclean -f /home/empress_dba/cleanup > $HOME/cleanup.log 2>&1
この例ではEmpressがインストールされているディレクトリを/usr2/empress/v8.62 とし、毎日 01:15にempclean -f /home/empress_dba/cleanupを実行します。 すべての出力（標準出力と標準エラー出力）は、ユーザーホームディレクトリのcleanup.log ファイルにリダイレクトされます。 empcleanは、 crontabファイルの編集を起動したアカウントの ユーザーIDの基で実行されることに留意してください。
empcleanを実行したときに、
見つかった問題を修正するためのステップを標準エラー出力にログ出力します。
最初のコンフィグレーションファイル例の場合
MSCLCOMMAND=temp
MSCLCOMMAND=recompile
MSCLHOSTNAME=gold
MSCLTMPDIR=/var/work
MSCLHOSTNAMEEND
MSCLDATABASE=/work/physics
MSCLCOMMAND=data_check
MSCLDATABASEEND
empcleanは、エラーが見つからなかった場合、以下の出力をします。 実行した人の名前および開始時間、その後にさまざまな実行フェーズの ログ出力し、問題が発見された場合、さらに情報を出力します。 以下の例では、tempオペレーション中に中途半端に残った テンポラリファイルは見つけられなかったことがわかります。
EMPCLEAN version 8.62
started by empress_dba : 15 Jan 2000 10:26:49
NEXT PHASE : Check directories for temporary files
/work/EMP_* not found
/var/work/EMP_* not found
NEXT PHASE : Restart server
CHECKING DATABASE : /work/physics
NEXT PHASE : Recreating shared memory as necessary
NEXT PHASE : Find all clients which terminated improperly
Checking host: 'gold'
NEXT PHASE : Check semaphores
NEXT PHASE : Resolve transactions
NEXT PHASE : Remove dangling server clients
NEXT PHASE : Resolve locks
NEXT PHASE : Check compiled data dictionary REL file
NEXT PHASE : Generate compile entries for data dictionary
NEXT PHASE : Check data dictionary REL/DTF files
NEXT PHASE : Recompile null entries in data dictionary
NEXT PHASE : Check REL/DTF files
NEXT PHASE : Check coordinator
EMPCLEAN end : 15 Jan 2000 10:26:52
２番目の例は以下のコンフィグレーションファイルを使用し、実行した場合
MSCLSERVER=physics-srv
MSCLCOMMAND=temp
MSCLCOMMAND=recompile
MSCLHOSTNAME=gold
MSCLGLOBALDATADICT=/work/gdd
MSCLSERVERCONFFILE=/work/scf
MSCLHOSTNAMEEND
MSCLHOSTNAME=ruby
MSCLTMPDIR=/var/work
MSCLHOSTNAMEEND
MSCLDATABASE=physics-db
MSCLCOMMAND=data_check
MSCLDATABASEEND
empcleanは、サーバが死んでいる場合のデータベースでは 以下の出力をします。
EMPCLEAN version 8.62
started by empress_dba : 15 Jan 2000 10:32:52
NEXT PHASE : Check directories for temporary files
/work/EMP_* not found
NEXT PHASE : Restart server
Starting server 'physics-srv' if it is not running
Successfully restarted server: physics-srv
CHECKING DATABASE : physics-db
NEXT PHASE : Recreating shared memory as necessary
NEXT PHASE : Find all clients which terminated improperly
Checking host: 'gold'
NEXT PHASE : Check semaphores
NEXT PHASE : Resolve transactions
NEXT PHASE : Remove dangling server clients
NEXT PHASE : Resolve locks
NEXT PHASE : Check compiled data dictionary REL file
NEXT PHASE : Generate compile entries for data dictionary
NEXT PHASE : Check data dictionary REL/DTF files
NEXT PHASE : Recompile null entries in data dictionary
NEXT PHASE : Check REL/DTF files
NEXT PHASE : Check coordinator
EMPCLEAN end : 15 Jan 2000 10:33:03
オペレーションはそれらを指定した順に実行されなかったことに 気づくかもしれません。 オペレーションを指定する順番にかかわらず、 それらは固定の順番で実行されます。 このことは、いくつかのオペレーションは、 他のオペレーションに依存するために起こります。 更に、これにより、empcleanは、明示的に指定しない オペレーションを実行し、オペレーションの基本セットは常に実行されます。
empcleanの運用上の制約は以下のとおりです。
ロックマネージャのすべてのスロットがアクティブプロセスにより保持されている場合、 empcleanはロックを得ることが出来ず、実行することはできません。
コーディネーターのすべてのスロットがアクティブプロセスにより保持されている場合、 empcleanはコーディネーターに自分自身のエントリを登録できないため、 実行することはできません。
アクティブプロセスが、sys_dictionaryのテーブルロックを 保持している場合、empcleanが、sys_dictionaryへの ロックができないため、recompileおよびrecompile_all 、 table_check操作の実行ができません。
アクティブプロセスが、あるテーブルのテーブルロックを保持している場合。 保持している場合、empcleanはそのテーブルに対してのロックができないため、 data_check操作の実行ができません。
.relファイル および.dtfファイルまたシェアードメモリパーティション が、認識不可能になるほどの大きなダメージを受けている場合、empcleanによる 修復はできません。
シェアードメモリパーティションがダメージを受けた場合、 empcleanはメッセージを出力し、スキップします。 この場合、DBAはempadmコマンドと使って、手作業により 以下のようにシェアードメモリバーティションを削除と再作成が必要です。
リモートホストのチェック時、リモートシェルコマンドを利用して通信する リモートのアカウントは、そのオペレーティングシステムの環境に $EMPRESSPATH変数の設定が必要です。
empcleanをdata_checkオプションを伴って実行している間において テーブルのロックを NULL で利用している場合は テーブルに対しアクセスしてはいけません。
データベースファイルが SQLの ALTERステートメントのLOCATE INを利用し、 移動されている場合において、 empcleanはそのディレクトリのクリーンアップは行いません。
empcleanを実行するマシンから通信が出来ないホスト上の クライアントのクリーンアップはできません。 この場合、それぞれのローカルマシン上でempcleanを実行する 必要があります。
すべてのリモートホストに通信可能である場合、サーバーが実行されている ホスト上のみempcleanを実行します。 リモートホストは自動的にクリーンアップ処理をおこないます。 すべてのリモートホストを指定する必要があります。（あるいは全く指定をしない） また、empcleanはこれらのリモートホスト上の Empress クライアントからの情報について エラーリポートすることがあります。
empcleanを使ってサーバーを再起動するためにはサーバー管理者で 行う必要があります。
以下のオペレーションを実行するためにデータベース管理者(DBA)で行う必要があります。
sys_dictionaryの一部または全ての再コンパイル
中途半端なデータ辞書エントリの削除
中途半端なデータベースファイルの削除
データベースディレクトリ内のデータベースに関係ないファイルの削除
.relファイルおよび.dtfファイルの整合性のチェックおよび修復
中途半端なデータベースファイルの削除は、、 これらのファイルを削除するためのオペレーティングシステムの許可を DBAが持つ必要があります。
DBAではない場合は、以下の操作のみ実行が可能です。
実行者所有のトランザクションのクリア
実行者所有のロックのクリア
実行者所有のコーディネーター情報のクリア
実行者所有のテンポラリファイルの削除
実行者所有の未終了のクライアントの削除
リモートホストのクリーンアップ処理は、 リモートマシン上のシェルを起動することにより実行されるので 誤った出力がリモートシェルによって出力されないことを 保証しなければなりません。 例えば、.cshrcや.profile内にsttyコマンドを 置かないことなどになります。