|
| |
| Sun™ Identity Manager 8.0 インストール | |
付録 E
DBMS の復旧とリポジトリ
リポジトリの復旧障害復旧計画は、ビジネスに不可欠なシステムの配備における重要な要素です。サポートされる各 DBMS には、データのバックアップと復元を行うための複数の機構があります。それらのすべてが使用可能であり、Identity Manager の暗黙の要件はありません。
一般に、データベースに障害が発生した場合に必要な処理は、リポジトリを障害発生直前の時点に復元することだけです。ただし、ビジネス要件により、リポジトリを任意の特定時点に復元 (Oracle では ARCHIVELOG モードや Flashback、SQL Server では FULL ログモードなど、該当するベンダー固有の方法を使用) する必要がある場合は、これも実行できます。使用する復旧方法にかかわらず、リポジトリを最新ではないバージョンに復元した場合の影響について検討する必要があります。
データの復元後、リポジトリは自己矛盾のない状態になりますが、リソースなどの外部オブジェクトとは必ずしも整合性がある (または、互換性がある) 状態になるとは限りません。発生する可能性がある不整合のいくつかを次に示します。
さらに、リソースはそれ自体がアカウント属性のリポジトリです。リポジトリを特定の時点に復元してもリソースを前の状態に復元できないことがあります。これは、前の状態に復元するために必要な情報がリポジトリに格納されたことがない場合があるためです。
redo ログ特定時点に復旧する方法では、壊れていない変更レコードセット (通常は「redo ログ」と呼ばれる) が存在している必要があります。変更率が高く、大量の redo が生成される場合は、これがロジスティック上の問題となることがあります。
Identity Manager は redo ログを書き込む必要性を最小限にしようとします。ただし、データベースアクティビティーを完全に排除することはできません。Identity Manager がアイドル状態に見える場合でも、リポジトリオブジェクト、実行可能なタスク、クリーンアップ可能なタスクなどに対する変更を検出するために、各サーバーはリポジトリをポーリングします。
これらのアクティビティーの発生間隔は設定可能であり、これらの設定間隔を大きくすると、Identity Manager がアイドル時にリポジトリに対して実行するデータベース操作の頻度が減ります (ただし排除はされない)。これらの間隔を設定するには、Waveset.properties ファイルで、cache.pollingInterval などの cache で始まるプロパティーや、ChangeNotifier などに新しい値を定義します。
さらに、Identity Manager グラフィカルユーザーインタフェースを提供しないクラスタ内のアプリケーションサーバーの listcache.size プロパティーを無効にします。このプロパティーを無効にすると、Identity Manager がアイドル時にリポジトリに対して実行する操作の数が減ります。