# CHAPTER 10: データベースのチェックと修復

## 10.1 はじめに

Empressプロセスは、クリーンアップ手続きを始めるように 適切な終了処理を要求します。 その手続きとは、 未解決のロックのクリア、 未終了のサーバーへのコネクションの切断、 テンポラリファイルおよびテンポラリテーブルの削除、 トランザクションの解決などが含まれます。

Empress プロセスが kill された場合（`SIGKILL`、またはマシン障害によるダウン) 適切なクリーンアップ処理が行われない可能性があります。 その結果、例えば所有者の存在しないロックが後に残ったり、 サーバー接続が終了されず、開放されないことがあります。 これらの問題は他のプロセスがデータベースにアクセスできない原因になる可能性があります。

マルチタスクの環境においては、 残されたレコードロックや未解決のトランザクションにより、 他のプロセスに影響を及ぼすことは許しがたい行為となります。 この問題を解決するためにデータベースのチェックや 必要なクリーンアップ操作の実行するための `"empclean"`と呼ばれるデータベース整合性保証 ユーティリティを紹介します。以下はその処理になります。

- サーバー処理
  - 途中終了したサーバーの再スタート
  - 未終了のクライアントの削除
- データ辞書処理
  - 再コンパイル
  - 部分的な再コンパイル
  - 矛盾したデータ辞書エントリの削除
  - 関係のないRelファイルの削除
  - データベースディレクトリ中のデータベースファイルではないファイルの削除
- トランザクションの解決
- 残ったロックのクリア
- データベースファイルの修復
- 残ったテンポラリファイルの削除
- データベース・コーディネイターファイルのクリーンアップ
- 消失したシェアードメモリーパーティションの再作成

## 10.2 データベース整合性保証ユーティリティの操作

プロセスがいつ、どのように途中終了したかにより、 データベースが破損の状況は異なります。 `"empclean"`は、これらの多くの状況の修復のために それぞれの修復クラスを実行することができます。 各クラスを以下に説明します。

### 10.2.1 サーバー操作

#### 10.2.1.1 途中終了したサーバーの再起動

サーバーを実行しているマシンで障害が発生した場合、 そのマシン上のサーバーは途中終了します。 リブートするたびにサーバーを開始するシステムではない場合、 サーバーは手動で再スタートするまでは有効ではありません。 `"empclean"`は、サーバーが実行されているマシン上で 途中終了したサーバーをチェックすることができ、 必要であるならば再スタートすることができます。

#### 10.2.1.2 未終了のクライアントの削除

サーバーにアクセスしているクライアントが実行中にマシンに障害が発生した場合、 サーバーから削除されません。 その場合、`"empclean"`を実行することで、 サーバーに記憶されているすべてのクライアントの存在を確認します。 存在しないすべてのクライアントはサーバーから削除されます。 これは `empsvadm server_name svremove client_id`コマンドの自動化と 等しい処理になります。

サーバーは制限された数のクライアントプロセスのみを その内部で記憶しているため、この操作は重要であり、 そのため、途中終了したクライアントプロセスは定期的に削除すべきです。

### 10.2.2 データー辞書操作

#### 10.2.2.1 再コンパイル

処理速度向上のためにEmpressは、テーブルスキーマについてのすべての情報を コンパイルし、データ辞書内に個々のレコードとしてこの情報を格納しています。 `"empclean"`は、データ辞書のエントリの再コンパイルを強制的にすることができます。

#### 10.2.2.2 部分的な再コンパイル

この操作は、データ辞書全体をコンパイルせず、テーブル情報のみ再コンパイルします。 この矛盾はテーブルスキーマを変更する操作が中断された場合に生じることがあります。

#### 10.2.2.3 矛盾したデータ辞書エントリの削除

`"empclean"`は、存在しないテーブルのデータ辞書のエントリを削除することができます。

#### 10.2.2.4 関係のないRelファイルの削除

`"empclean"`は、 データベース・テーブルに関係ないデータベースディレクトリ内の 以下の種類の中途半端なファイルを削除します。

- メインレコードデータファイル (`.rel`)
- オーバーフローデータファイル(`.dtf`)
- インデックスファイル(`.ix`)
- インデックスオーバーフローファイル(`.ixl`)

この操作が行われている間はデータ定義言語(DDL)コマンドは データベース上で実行することはできません。 DDLコマンドとはデータベーススキーマを変更するコマンドです。

#### 10.2.2.5 データベースディレクトリ内のデータベースファイルと関係のないファイルの削除

データベースディレクトリ内はEmpressデータベースファイルだけでなくてはなりません。 このディレクトリに他のファイルが存在した場合、`"empclean"`はそれらのファイルを 削除します。

### 10.2.3 トランザクションの解決

サーバーまたはクライアントが予期せず途中終了したとき、 その時まで進んでいたトランザクションは解決されません。 `"empclean"`は、これらのトランザクションの解決を強制におこなう ことができます。 完全なトランザクションはコミットされ、途中で終了したトランザクションは キャンセルされます。これは`empwarm` コマンドの自動化と等しく、 またアクティブはトランザクションには影響しません。

### 10.2.4 残ったロックのクリア

クライアントが途中終了したことにより保持されていた シェアードメモリおよびファイルロックはクリアされていない可能性があります。 `"empclean"`は、 既に存在していないクライアントによって保持されていたロックを見つける ことができ、それらをクリアすることができます。 これは`empadm database_name lockclear client_id`コマンドの 自動化に等しく、`client_id`は、既に有効ではないクライアントの Empress IDになります。

### 10.2.5 データベースファイルの修復

メインレコードデータファイル (`.rel`ファイル) と オーバーフローデータファイル(`.dtf` ファイル) は、 `empclean`コマンドにより修復することができます。 これはレコードカウントおよびテーブルのフリーリストの修復が含まれます。

`.rel`ファイルまたは`.dtf`ファイルの修復が必要である場合、 修復しなくてはならない箇所だけを変更し、`empclean`は、新しいファイルを 作成しません。 `.rel`ファイルまたは`.dtf`ファイルが破損し、修復が必要な場合、 `empclean`は、テーブルのインデックス(`.ix`ファイルおよび `.ixl`ファイル)を再作成します。

この操作は、データが多いテーブル上では非常に遅い可能性があります。 また、問題を見つけるためのファイル走査により、 各テーブルへの排他的なアクセスが要求され、 テーブルは完全に修復されるまでアクセスはできなくなります。

### 10.2.6 残ったテンポラリファイルの削除

Empressは、多くの目的でテンポラリファイルを利用します。 例えば、バルク型のアトリビュートのオーバーフローデータは EMPRESS変数 `MSTMPDIR`に指定されたディレクトリ以下の ディレクトリ中のファイルへ格納されます。 クライアントが突然、、kill された場合、そのクライアントが作成した テンポラリファイルとディレクトリは削除されません。 `empclean`は、既に存在しないクライアントを見つけ、 それらが作成したテンポラリファイルを削除することができます。 この操作では任意のデータベースの指定はありません。

この操作において`empclean` プロセスは、 ファイルを削除の許可を持つ有効なユーザーID が必要になることに 注意してください。

### 10.2.7 データベースコーディネイターファイルのクリーンアップ

すべてのEmpressデータベースで、 関連付けのためのコーディネイターが存在します。 コーディネイターは、データベースにアクセスするプロセスを を記録しています。

Empressプロセスが、適切なクリーンアップ処理なしに死んだ場合、 `empclean`は、コーディネイターファイルからそのプロセスのエントリを 削除します。

### 10.2.8 消失したシェアードメモリパーティションの再作成

`empclean`は、消失したシェアードメモリパーティションを見つけた場合、 シェアードメモリパーティションを自動に再作成します。

## 10.3 データベース整合性保証ユーティリティの実行

データベース整合性保証ユーティリティ`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` | このコマンドは以下を行います。 中途半端なデータ辞書エントリの削除 中途半端なデータベースファイルの削除 データベースディレクトリ中のデータベースと関係のないファイルの削除 Empressクライアントが死んだために残ってしまった `TMP_*_TAB_empress_id`テーブルの削除 これは、SQLの`ALTER`コマンドを実行中に kill された場合に `TMP_ALTER_TAB_empress_id`テーブルがデータベースに残ります。 (`empress_id`は、`ALTER`コマンド実行中のプロセスの Empress IDです。)
`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"`オプションは以下のケースでは使用に 制限される可能性があります。

1. サーバーが死んでいる場合では、`empclean`は、 サーバーが再スタートされるまで処理を続けることができません。
2. テーブル上にロックがある場合（または`sys_dictionary`にロックがかかって いる場合)、`empclean`はそのロックがクリアされるまで 整合性チェックを実行することができません。
3. シェアードメモリが壊れている場合、`empclean`の処理を続けるために シェアードメモリの削除と再作成をする必要があります。

## 10.4 データベース整合性保証ユーティリティのコンフィグレーションファイル

このセクションでは`empclean`のコンフィグレーションファイルの 作成の手順を示し、そのファイルの構成およびコンフィグレーションファイルの いくつかのカスタマイズに関して説明します。

### 10.4.1 コンフィグレーションファイルの作成

`-m`オプションを指定し、`empclean`の実行することで 対話型セッションを開始します。その間に修正を望むデータベースおよびサーバー名、 またそれらが存在するマシン名を尋ねられます。 質問に回答することにより、`empclean`によって利用される コンフィグレーションファイルは作成されます。

#### 10.4.1.1 ローカルデータベースのコンフィグレーション

以下は、データベースサーバーではないスタンドアロンマシン上の ローカルデータベースの修復のためのコンフィグレーションファイルの生成の 例です。 マシン名を`"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

#### 10.4.1.2 サーバーのコンフィグレーション

以下は、サーバーを通してアクセスされるデータベースの修復のための コンフィグレーションファイルの作成の例です。 例の環境として、物理データベース名は `"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

### 10.4.2 コンフィグレーションファイルの構成

`empclean -m`により自動的にファイルはセットアップされますが、 そのファイルの内部構成について述べることは、 提供した情報と一致するコンフィグレーションファイル内の それぞれのシステム変数がどのようなものであるかを 理解することであなたの助けとなります。 このことは、すばやく修正する場合において必要とされ、 システムエディタを使ってコンフィグレーションファイルを 編集をすることができます。

`empclean`のコンフィグレーションファイルは複数の ブロックから構成されています。 １つのブロックは１つのタイプの情報を扱い、１ブロックは１行以上含まれています。 また、Empress変数のいくつかを定義する場合もあります。 `empclean -m`によって生成された順にブロックを説明しますが、 ファイル中ではそれが任意の順に現われることがあります。

  図 10-1: データベース整合性保証ユーティリティ コンフィグレーションファイルの構成

#### 10.4.2.1 サーバー

このブロックでは、このコンフィグレーションファイルを 利用する場合、再起動させるためのサーバー名を指定します。 サーバーが複数ある場合、それぞれ１行づつ指定します。 指定は以下のフォームになります。

       MSCLSERVER=servername

このブロックは `empclean -m`を実行したときの 以下の質問と一致します。

       どのサーバが自動的に再開始しますか？ （１行に１つ）
       サーバ:

サーバーを指定しない場合、このブロック中のエントリはありません。

#### 10.4.2.2 オペレーション

このブロックでは、すべてのデータベース上で実行するオペレーションを指定します。 これらのオペレーションのことをグローバルオペレーションと呼びます。 指定は以下のフォームになります。

       MSCLCOMMAND=command

コマンドが複数ある場合、それぞれ１行づつ指定します。 このブロックは複数の行を持つことが出来ますが、 同じコマンドを何回も指定しても、それぞれのコマンドは １回のみ実行されます。 コマンドを指定しない場合、このブロック中のエントリはありません。

コンフィグレーションファイル中の操作のうちの いずれかがデータベース修復をおこなう操作の場合、 整合性チェックの基本セットが実行されます。 この基本的なセットは次のデータベース矛盾をチェックします。

- サーバーの問題
  - 途中終了のサーバーの再起動
  - 未終了のクライアントの削除
- シェアードメモリの問題
  - 消滅したシェアードメモリの再作成
- 未解決のトランザクション
  - データベース上で`empwarm`の実行
- 未解決のロック
  - ファイルおよびシェアードメモリ上の未解決のロックの削除
- コーディネイターの問題
  - 既に存在しないプロセスに対し、コーディネイター情報からの削除

実行可能なコマンド

  `recompile_all` | すべてのテーブルに対してのデータ辞書エントリの再コンパイル
  `recompile` | コンパイルエントリがヌルであるテーブルのデータ辞書エントリの再コンパイル
  `table_check` | このコマンドは以下を行います。 中途半端なデータ辞書エントリの削除 中途半端なデータベースファイルの削除 データベースディレクトリ中のデータベースに関係のないファイルの削除 Empressのクライアントが死んだために残ってしまった `TMP_*_TAB_empress_id`テーブルの削除。例えば、 SQLの`ALTER`の実行中にプロセスがkill された場合、 `TMP_ALTER_TAB_empress_id`が、データベースに残ります。 （`empress_id`のところはテーブルの変更していた プロセスのEmpress IDになります。
  `data_check` | 不整合な`.rel`ファイルおよび`.dtf`ファイルを見つけ、修復します。
  `temp` | 残ったテンポラリーファイルの削除。 このオプションは、`empclean`プロセスを実行するユーザーに ファイルを削除する許可が必要です。

このブロックは `empclean -m`を実行したときの 以下の質問と一致します。

       以下のｃｌｅａｎｕｐオペレーションは有効です。:
       temp recompile recompile_all table_check data_check rebuild_user_indices

    　 すべてのデータベース上でどのオペレーションを実行させますか？ （１行に１つ）
       オペレーション:

#### 10.4.2.3 ホストコンフィグレーション

このブロックは以下のホストに関係する情報を含みます。

- グローバルデータディクショナリの位置 - `MSCLGLOBALDATADICT`
- サーバーコンフィグレーションファイルの位置 - `MSCLSERVERCONFFILE`
- リモートシェルコマンドの絶対パス - `MSCLRMTSHELLCMD`
- ホストにより利用されるテンポラリディレクトリ - `MSCLTMPDIR`
- 通信することが可能なリモートホスト - `MSCLRMTHOST`

それぞれのブロックは １つのホストに対する定義情報を含み、 以下の１対の変数によって区切られます。

       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 ...

       ホストを入力してください、（１行に１つ）
       ホスト:

#### 10.4.2.4 データベース指定

このブロックは １つのデータベースに対し実行すべき操作を定義し、 以下の１対の変数によって区切られます。

       MSCLDATABASE=database_name
        .
        .
        .
       MSCLDATABASEEND

この`MSCLDATABASE`変数は、 `empclean -m`を実行したときの 以下の質問と一致します。

      すべてのデータベース名を入力して下さい。
      （論理名 または フルパス、１行に１つ。）
      リターンで終了。
      データベース:

オペレーションはグローバルオペレーションと同じような フォームで指定します。

       MSCLCOMMAND=command

それぞれのオペレーションは１行に指定する必要があり、また、 ブロック内のオペレーションは複数の種類を指定することが可能です。 この変数は、 `empclean -m`を実行したときの 以下の質問と一致します。

       各データベースに対するオペレーションについて尋ねます。

       データベース 'database_name':

         どの追加オペレーションを実行させますか？
         以下の中から１つ以上選んで下さい。

        recompile_all table_check data_check rebuild_user_indices
        オペレーション:

### 10.4.3 追加カスタマイズ

次の２つの変数は、 コンフィグレーションファイルの `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"の一方に一致する必要があります。
...&... | "&"を境にして、その両方の指定に一致する必要があります。 [a-z]&[^x]は、 "x"以外の任意の文字列と一致します。
\ | "?", "*", "|", "&", "{", "}", "[", "]", "\" などの特殊文字の前に"\"を指定することで、その設定した文字は 特殊文字ではなく文字どおりに解釈されます。

２番目の変数、`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`は、明示的に指定しない オペレーションを実行し、オペレーションの基本セットは常に実行されます。

## 10.6 制約

`empclean`の運用上の制約は以下のとおりです。

- ロックマネージャのすべてのスロットがアクティブプロセスにより保持されている場合、 `empclean`はロックを得ることが出来ず、実行することはできません。

- コーディネーターのすべてのスロットがアクティブプロセスにより保持されている場合、 `empclean`はコーディネーターに自分自身のエントリを登録できないため、 実行することはできません。

- アクティブプロセスが、`sys_dictionary`のテーブルロックを 保持している場合、`empclean`が、`sys_dictionary`への ロックができないため、`recompile`および`recompile_all` 、 `table_check`操作の実行ができません。

- アクティブプロセスが、あるテーブルのテーブルロックを保持している場合。 保持している場合、`empclean`はそのテーブルに対してのロックができないため、 `data_check`操作の実行ができません。

- `.rel`ファイル および`.dtf`ファイルまたシェアードメモリパーティション が、認識不可能になるほどの大きなダメージを受けている場合、`empclean`による 修復はできません。

- シェアードメモリパーティションがダメージを受けた場合、 `empclean`はメッセージを出力し、スキップします。 この場合、DBAは`empadm`コマンドと使って、手作業により 以下のようにシェアードメモリバーティションを削除と再作成が必要です。

  - `empadm database_name shmremove` ダメージを受けたシェアードメモリパーティションの削除
  - `empadm database_name shmcreate` シェアードメモリパーティションの再作成

- リモートホストのチェック時、リモートシェルコマンドを利用して通信する リモートのアカウントは、そのオペレーティングシステムの環境に `$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`コマンドを 置かないことなどになります。