Sun Java ロゴ     前へ      目次      索引      次へ     

Sun ロゴ
Sun™ Identity Manager 8.0 管理ガイド 

第 16 章
データエクスポータ

データエクスポータ機能を使用すると、ユーザー、ロール、その他のオブジェクトタイプを外部のデータウェアハウスに書き込むことができます。

この章では、データエクスポータの設定と維持に役立つ説明および手順を示します。データエクスポータの計画と実装の詳細については、『Identity Manager の配備に関する技術情報』を参照してください。

この章で説明する内容は次のとおりです。


データエクスポータの概要

Identity Manager は、分散したシステムおよびアプリケーション全体にわたってアイデンティティーを管理することに関連するデータを格納し、処理します。全体のパフォーマンスを向上させるため、Identity Manager は、通常のプロビジョニングおよびその他の日常アクティビティーの間に生成するデータの一部を保持しません。たとえば Identity Manager では、デフォルトで、中間ステータスのワークフローアクティビティーとタスクインスタンスは持続されません。Identity Manager が通常は破棄するデータのすべてまたは一部を収集する必要がある場合は、データエクスポータ機能を有効にすることができます。

データエクスポータ機能が有効にされると、Identity Manager は、指定のオブジェクト (データタイプ) に対する変更が検出されるたびに、それらをリポジトリ内のテーブルのレコードとして格納します。これらのイベントはキューに入れられ、その後、タスクがそれらを外部のデータウェアハウスに書き込みます。(各タイプのデータをエクスポートする頻度を設定することができます。) エクスポートしたデータはさらに、市販の変換ツール、レポートツール、および分析ツールを使用して、処理を行ったりクエリーや変換の基盤として利用したりできます。

データウェアハウスにデータをエクスポートすることは、Identity Manager サーバーのパフォーマンスに悪影響を及ぼすため、エクスポートされたデータに対するビジネスニーズがある場合以外、この機能は有効にしないでください。

Identity Manager では、フォレンジッククエリーの作成と実行も可能です。フォレンジッククエリーは、データウェアハウスを検索して、指定された条件を満たすユーザーオブジェクトやロールオブジェクトを特定します。詳細については、「フォレンジッククエリーの設定」を参照してください。


データエクスポータの実装計画

データエクスポータはデフォルトでは無効にされるため、操作可能になるよう設定する必要があります。データエクスポータの設定では、設定を開始する前にいくつかの決定を行う必要があります。

データエクスポータが有効にされると、デフォルトの設定では、すべてのデータタイプのすべての属性がエクスポートされます。これにより、使用されないはずのウェアハウスの記憶領域が消費されて、Identity Manager とウェアハウスで不必要な処理負荷が発生する可能性があります。データウェアハウスは保存力が高く、後でデータが使用される可能性がある場合にはデータを収集する傾向があります。エクスポートできるデータをすべてエクスポートする必要はありません。エクスポートするデータタイプを設定し、一部のイベントがエクスポートされないように制限することができます。

上記の点について決定したら、以下の手順に従ってデータエクスポータを実装します。

  1. (省略可能) 選択したタイプのエクスポートスキーマをカスタマイズし、ウェアハウス DLL を再作成します。詳細については、『Identity Manager の配備に関する技術情報』を参照してください。
  2. ウェアハウスの RDBMS にユーザーアカウントを作成し、そのシステムでウェアハウス DDL を読み込みます。詳細については、『Identity Manager の配備に関する技術情報』を参照してください。
  3. 「データエクスポータの設定」で説明するようにデータエクスポータを設定します。
  4. データエクスポータをテストして正しく設定されたことを確認します。詳細については、「データエクスポータのテスト」を参照してください。
  5. (省略可能) データウェアハウスに書き込まれるデータを検索できるフォレンジッククエリーを作成します。詳細については、「フォレンジッククエリーの設定」を参照してください。
  6. JMX を使用し、ログファイルを監視して、データエクスポータを維持します。詳細については、「データエクスポータの維持」を参照してください。


データエクスポータの設定

データエクスポータの設定ページでは、保持するデータのタイプを定義し、エクスポートする属性を指定して、データをいつエクスポートするかをスケジュールできます。各データタイプは別個に設定できます。

データエクスポータを設定するには、次の手順に従います。

  1. 管理者インタフェースで、メインメニューから「設定」をクリックします。「ウェアハウス」二次タブをクリックします。「データエクスポータの設定」ページが開きます。
  2. 図 16-1 データエクスポータの設定
    「データエクスポータの設定」メインページ

  3. 読み取り接続と書き込み接続を定義するには、「接続の追加」ボタンをクリックします。「データベース接続の編集」ページが開きます。
  4. このページにあるフィールドの設定を完了し、「保存」をクリックして「データエクスポータの設定」ページに戻ります。詳細については、「読み取り接続と書き込み接続の定義」を参照してください。

  5. WIC クラスとデータベース接続を割り当てるには、「ウェアハウスの設定情報」セクションにある「編集」リンクをクリックします。「データエクスポータウェアハウスの設定」ページが開きます。
  6. このページにあるフィールドの設定を完了し、「保存」をクリックして「データエクスポータの設定」ページに戻ります。詳細については、「ウェアハウスの設定情報の定義」を参照してください。

  7. 「ウェアハウスのモデル設定」テーブルで、データタイプのリンクをクリックします。「データエクスポータタイプの設定」ページが開きます。
  8. このページにある「エクスポート」タブ、「属性」タブ、および「スケジュール」タブの設定を完了し、「保存」をクリックして「データエクスポータの設定」ページに戻ります。詳細については、「ウェアハウスモデルの設定」を参照してください。

    すべてのデータタイプについてこの手順を繰り返します。

  9. エクスポートタスクデーモンを設定するには、「ウェアハウスのタスク設定」セクションにある「編集」リンクをクリックします。「データエクスポータウェアハウスの設定」ページが開きます。
  10. このページにあるフィールドの設定を完了し、「保存」をクリックして「データエクスポータの設定」ページに戻ります。詳細については、「ウェアハウスタスクの設定」を参照してください。


    これらの手順が完了すると、エクスポートの操作がすべて可能になります。エクスポートが有効にされると、エクスポートのためにデータレコードのキューイングが開始されます。エクスポートタスクを有効にしないと、キューテーブルがいっぱいになり、キューイングが中断されます。一般に、大きなバッチよりも小さなバッチを (より頻繁に) エクスポートする方が効率的ですが、エクスポートはウェアハウス自体での書き込みが可能かどうかに左右されるため、別の理由による制約を受けることがあります。


  11. オプションの作業として、最大キューサイズを設定します。詳細については、「設定オブジェクトの変更」を参照してください。

読み取り接続と書き込み接続の定義

Identity Manager は、エクスポートサイクル中に書き込み接続を使用します。読み取り接続は、ウェアハウス内に現在いくつのレコードがあるかを (ウェアハウスの設定中に) 示し、フォレンジッククエリーインタフェースにサービスを提供するために使用されます。

ウェアハウスの接続は、アプリケーションサーバーのデータソース、JDBC 接続、またはデータベースリソースへの参照として定義できます。JDBC 接続またはデータベースリソースが定義された場合、データのエクスポートでは、書き込み操作中に少数の接続が集中的に使用され、その後、すべての接続が閉じられます。データエクスポータが読み取り接続を使用するのは、ウェアハウスの設定中、およびフォレンジッククエリーの実行中のみで、それらの接続は操作が完了するとすぐに閉じられます。

エクスポータは、書き込み接続と読み取り接続に同じスキーマを使用するので、同じ接続情報を両方のために使用できます。ただし、別個の接続がある場合、配備時には、ウェアハウスのステージングテーブルのセットに対して書き込みを行い、それらのテーブルを実際のウェアハウスに変換し、ウェアハウステーブルを Identity Manager の読み込み元になるデータマートに変換することができます。

Identity Manager がウェアハウスから読み込みを行えないように、「データエクスポータの設定」フォームを編集できます。このフォームには、includeWarehouseCount プロパティーが含まれています。これは、Identity Manager がウェアハウスに問い合わせて各データタイプのレコード数を表示するようにするプロパティーです。この機能を無効にするには、「データエクスポータの設定」フォームをコピーし、includeWarehouseCount プロパティーの値を true に変更して、カスタマイズしたフォームをインポートします。

読み取り接続と書き込み接続を定義するには、次の手順に従います。

  1. 「データエクスポータの設定」ページから、「接続の追加」ボタンをクリックします。
  2. 図 16-2 データエクスポータの設定
    データエクスポータの「データベース接続の編集」ページ

  3. 「接続タイプ」ドロップダウンメニューからオプションを選択し、Identity Manager でデータウェアハウスに対する読み取り接続または書き込み接続を作成する方法を指定します。
    • 「JDBC」 − Java Database Connectivity (JDBC) アプリケーションプログラミングインタフェースを使用してデータベースに接続します。ウェアハウスインタフェースコードによって接続プールが提供されます。
    • 「リソース」 − リソースで定義されている接続情報を使用します。ウェアハウスインタフェースコードによって接続プールが提供されます。
    • 「データソース」 − 接続の管理とプールのため、基盤となるアプリケーションサーバーを使用します。このタイプの接続では、アプリケーションサーバーからの接続が必要とされます。
    • ページのフィールドに表示されるフィールドは、「接続タイプ」ドロップダウンメニューから、どのオプションを選択したかに応じて変化します。データベース接続の設定の詳細については、オンラインヘルプを参照してください。

  4. 「保存」をクリックして設定の変更を保存し、「データエクスポータの設定」ページに戻ります。

別個の読み取り接続と書き込み接続を使用する場合は、この手順を繰り返します。

ウェアハウスの設定情報の定義

ウェアハウスを設定するには、読み取り接続と書き込み接続を選択し、ウェアハウスインタフェースコードのファクトリクラスを指定する必要があります。WIC ファクトリクラスは、Identity Manager とウェアハウスの間のインタフェースを提供します。Identity Manager には、コードのデフォルトの実装が用意されていますが、独自のファクトリクラスを作成することもできます。カスタムファクトリクラスの作成については、『Identity Manager の配備に関する技術情報』を参照してください。

ファクトリクラスおよびサポート用のいずれかの JAR ファイルを含む JAR ファイルは、エクスポートタスクを実行する Identity Manager サーバー上と、データエクスポータを設定しているすべてのサーバー上の $WSHOME/exporter ディレクトリに存在する必要があります。任意の時点で、データをエクスポートできるのは 1 つの Identity Manager サーバーのみです。

ウェアハウスの設定情報を定義するには、次の手順に従います。

  1. 「データエクスポータの設定」ページで、「ウェアハウスの設定情報」セクションにある「編集」リンクをクリックします。
  2. 図 16-3 データエクスポータの設定
    「データエクスポータウェアハウスの設定」ページ

  3. 「ウェアハウスインタフェースのコードファクトリクラス名」フィールドで値を指定します。インテグレータがカスタムクラスを作成していない場合は、値として com.sun.idm.warehouse.base.Factory と入力します。
  4. 「接続の読み取り」および「接続の書き込み」ドロップダウンメニューの両方からオプションを選択し、接続を指定します。
  5. 「保存」をクリックして設定の変更を保存し、「データエクスポータの設定」ページに戻ります。

ウェアハウスモデルの設定

エクスポート可能な各データタイプには、そのタイプが、エクスポートされるかどうか、どのようにエクスポートされるか、およびいつエクスポートされるかの制御に使用される一連のオプションがあります。データのエクスポートによって Identity Manager サーバーでの負荷が増加するため、ビジネス上の利点があるデータタイプについてのみ、エクスポートを有効にしてください。

次の表に、エクスポート可能な各データタイプの説明を示します。

表 16-1 サポートされるデータタイプ

データタイプ

説明

Account

User と ResourceAccount の間のリンクを含むレコード

Entitlement

特定の User のアテステーションのリストを含むレコード

LogRecord

1 つの監査レコードを含むレコード

ObjectGroup

組織としてモデルになっているセキュリティコンテナ

Resource

アカウントがプロビジョニングされる場所としてのシステムまたはアプリケーション

ResourceAccount

特定の Resource でアカウントを構成している一連の属性

Role

アクセス用の論理コンテナ

Rule

Identity Manager で実行できるロジックのブロック

TaskInstance

実行中のプロセスまたは完了したプロセスを示すレコード

User

0 個以上のアカウントを含む論理ユーザー

WorkflowActivity

Identity Manager ワークフローの 1 つのアクティビティー

WorkItem

Identity Manager ワークフローからの手動アクション

ウェアハウスモデルを設定するには、次の手順に従います。

  1. 「データエクスポータの設定」ページから、データタイプのリンクをクリックします。
  2. 「エクスポート」タブで、このデータタイプをエクスポートするかどうかを指定します。このデータタイプをエクスポートしない場合は、「エクスポート」チェックボックスを選択解除して「保存」をクリックします。エクスポートする場合はこの「エクスポート」タブで、必要に応じて残りのオプションを選択します。
    • 「クエリーを許可」 − モデルを照会可能にするかどうかを制御します。
    • 「すべてをキューに入れる」 − このタイプのオブジェクトに対する変更をすべて収集します。このオプションを選択すると、エクスポータに大きな処理負荷がかかる可能性があります。このオプションは慎重に使用してください。
    • 「削除結果を収集」 − このタイプの削除済みオブジェクトをすべて記録します。このオプションを選択すると、エクスポータに大きな処理負荷がかかる可能性があります。このオプションは慎重に使用してください。
  3. 「属性」タブでは、フォレンジッククエリーの一部として指定することができる属性と、クエリー結果に表示することができる属性を選択できます。管理者インタフェースからデフォルトの属性を削除することはできません。デフォルトの属性の変更については、『Identity Manager の配備に関する技術情報』を参照してください。
  4. 新しい属性名には次の特性があります。

    • attrName − この属性は最上位で、スカラーです。
    • attrName[] − この属性はリスト値がある最上位属性で、リスト内の要素はスカラーです。
    • attrName['キー'] − この属性にはマップ値が格納され、指定されたキーを持つマップの値が必要です。
    • attrName[].name2 − この属性はリスト値がある最上位属性で、リスト内の要素は構造体です。name2 は、構造体内にあるアクセス対象の属性です。
  5. 「スケジュール」タブで、このデータタイプと関連付けられている情報をエクスポートする頻度を指定します。サイクルの基準は、サーバーでの午前零時です。20 分ごとのサイクルであれば、指定の時間と、その時間の 20 分後および 40 分後にエクスポートが行われます。エクスポートがスケジュールされたサイクルより長くかかった場合は、次のサイクルがスキップされます。たとえば、サイクルが 20 分と定義され、午前零時に開始される場合、エクスポートの完了まで 25 分かかると、次のエクスポートは 12:40 に開始されます。もともと 12:20 にスケジュールされていたエクスポートは行われません。

ウェアハウスタスクの設定

専用サーバーでエクスポートタスクを実行することは必須ではありませんが、大量のデータをエクスポートする予定であれば、専用サーバーの利用を検討してください。エクスポートタスクでは、データが効率的に Identity Manager からウェアハウスに転送されますが、エクスポート操作中には CPU が最大限に使用されます。専用サーバーを利用しない場合は、サーバーでの対話型のトラフィックの処理を制限する必要があります。これは、大量のデータのエクスポート中には応答時間が大幅に増加するためです。

ウェアハウスの設定情報を設定するには、次の手順に従います。

  1. 「データエクスポータの設定」ページで、「ウェアハウスのタスク設定」セクションにある「編集」リンクをクリックします。
  2. 図 16-4 データウェアハウスのスケジュール設定
    データエクスポータウェアハウスのスケジュールのページ

  3. 「起動モード」ドロップダウンメニューからオプションを選択し、Identity Manager の起動時にウェアハウスタスクを自動的に開始するかどうかを指定します。「無効」を選択すると、タスクを手動で開始する必要があることになります。
  4. 自分の管理アカウントでエクスポータタスクが実行されるようにする場合は、「自分でタスクを実行」チェックボックスをオンにします。
  5. タスクを実行できるサーバーを選択します。複数のサーバーを指定できますが、任意の時点で実行できるウェアハウスタスクは 1 つだけです。タスクを実行するサーバーが停止している場合、スケジューラは自動的に、リストに含まれる別のサーバーでタスクを再開します (リストがある場合)。
  6. 「キュー読み取りブロックのサイズ」フィールドでは、書き込みの前にキューからメモリーバッファーに読み取るレコードの数を指定します。このフィールドのデフォルト値は、ほとんどのエクスポートで適切です。Identity Manager リポジトリサーバーがウェアハウスサーバーに比べて低速である場合は、この値を大きくします。
  7. 「キュー書き込みブロックのサイズ」フィールドでは、1 つのトランザクションでウェアハウスに書き込むレコードの数を指定します。
  8. 「キュードレインスレッドの数」フィールドでは、キューにあるレコードの読み取りに使用する Identity Manager スレッドの数を指定します。キューテーブルに異なるタイプのレコードが多数ある場合には、この数を増やします。キューテーブルのデータタイプの数が少ない場合はこの値を減らします。
  9. 「保存」をクリックして設定の変更を保存し、「データエクスポータの設定」ページに戻ります。

設定オブジェクトの変更

データエクスポータが設定されて動作可能になると、キューに入れるよう設定されたすべてのデータタイプが、内部キューテーブルに収集されます。デフォルトではこのテーブルに上限はありませんが、Data Warehouse Configuration 設定オブジェクトを編集することで設定が可能です。このオブジェクトには、warehouseConfig という名前の入れ子になったオブジェクトがあります。次の行を warehouseConfig オブジェクトに追加します。

<Attribute name='maxQueueSize' value='YourValue'/>

maxQueueSize の値は、231 より小さい任意の正の整数です。データエクスポータは、制限に達するとキューを無効にします。生成されたデータは、キューが空にされるまでエクスポートできません。

通常の Identity Manager の動作では、変更されたレコードが 1 時間に数千生成されることもあるため、キューテーブルが急速に拡大する場合があります。キューテーブルは Identity Manager リポジトリ内にあるため、このテーブルの拡大によって RDBMS 内の表スペースが使われ、表スペースが使い尽くされる可能性があります。表スペースの容量に限度がある場合は、キューに上限を設定することが必要になる場合があります。

キューテーブルのサイズを監視するには、データキュー JMX Mbean を使用します。詳細については、「データエクスポータの監視」を参照してください。


データエクスポータのテスト

データエクスポータは、正しく設定された後、バックグラウンドプロセスとして動作し、設定された間隔でウェアハウスにデータを送信します。エクスポータをオンデマンドで実行するには、「データウェアハウスエクスポータ起動ツール」のタスクを使用します。

データウェアハウスエクスポータ起動ツールを起動するには、次の手順に従います。

  1. ウェアハウスタスクを無効にします。詳細については、「ウェアハウスタスクの設定」を参照してください。
  2. メインメニューの「サーバータスク」をクリックします。次に、「タスクの実行」二次タブをクリックします。「利用可能なタスク」ページが開きます。
  3. 「データウェアハウスエクスポータ起動ツール」リンクをクリックします。「タスクの起動」ページが開きます。
  4. 「デバッグオプション」チェックボックスを選択して追加のオプションを表示します。
  5. 「初期 LastMods を無視」チェックボックスを選択し、Identity Manager リポジトリ内のどのレコードがすでにエクスポート済みであるかを判別するためにエクスポータが使用している、「最後にポーリングされた」タイムスタンプを無視するようにします。このオプションが選択されると、Identity Manager リポジトリ内にある、選択したタイプのレコードがすべてエクスポートされます。
  6. 「一度エクスポートする」リストから、どのタイプのデータをエクスポートするかを選択します。「一度エクスポートする」リストでどのタイプも選択しないと、エクスポートタスクはデーモンとして実行され、前に定義されたスケジュールに基づいてエクスポートを行います。1 つ以上のデータタイプを選択すると、Identity Manager はそれらのタイプをただちにエクスポートし、エクスポートタスクが終了します。
  7. ページのほかのフィールドの値を必要に応じて設定します。
  8. 「起動」をクリックしてタスクを開始します。


フォレンジッククエリーの設定

フォレンジッククエリーを使用すると、データウェアハウスに格納されていたデータを Identity Manager で読み取ることができます。このクエリーは、ユーザー、ロール、または関連するデータタイプの現在値または履歴値に基づいて、ユーザーやロールを特定できます。フォレンジッククエリーは「ユーザーの検索」や「ロールの検索」のレポートと似ていますが、履歴値に対して一致条件を評価できる点が異なります。また、照会しようとしているユーザーやロールとはデータタイプが異なる属性を検索できる点が異なります。

フォレンジッククエリーの目的は、Identity Manager を使用して結果に対するアクションを実行することです。フォレンジッククエリーは汎用のレポートツールではありません。

フォレンジッククエリーでは次のような質問をすることができます。

フォレンジッククエリーの結果は、保存することができません。ウェアハウスのデータに関する汎用のレポートは、市販のレポートツールを使用して作成してください。

クエリーの作成

フォレンジッククエリーでは、ユーザーオブジェクトやロールオブジェクトを検索できます。クエリーは非常に複雑にすることができ、作成者は関連するデータタイプについて 1 つ以上の属性の条件を選択できます。ユーザーのフォレンジッククエリーでは、データタイプが User、Account、ResourceAccount、Role、Entitlement、および WorkItem である属性を検索できます。ロールのフォレンジッククエリーでは、データタイプが Role、User、および WorkItem である属性を検索できます。

1 つのデータタイプ内で、すべての属性条件の論理積が求められるため、一致と判定されるにはすべての条件が満たされる必要があります。デフォルトでは、データタイプ全体にわたる一致の論理積が求められますが、「OR の使用」チェックボックスを選択すると、データタイプ全体にわたる一致の論理和が求められます。

ウェアハウスでは、1 つのユーザーオブジェクトまたはロールオブジェクトについて複数のレコードが含まれていることがあり、1 つのクエリーで、同一のユーザーまたはロールについて複数の一致が返される可能性があります。これらの一致を区別する助けになるように、日付の範囲によって各データタイプに制約を設定できます。そのようにすると、指定した日付の範囲にあるレコードのみが一致だと見なされます。関連するデータタイプはそれぞれ日付の範囲で制約を設定できるため、次の形式のクエリーを発行することができます。

2005 年 5 月から 7 月の間に ERP1 上にリソースアカウントを持っていて、2005 年 7 月から 8 月の間に Fred Jones によってアテストされたすべてのユーザーを検索す る

日付の範囲は午前零時から午前零時です。たとえば、範囲が 2007 年 5 月 3 日から 2007 年 5 月 5 日であれば 48 時間です。2007 年 5 月 5 日からのレコードは含まれません。

各属性条件のオペランド (比較対象の値) は、クエリー定義の一部として指定する必要があります。スキーマでは、一部の属性で可能な値のセットが限定されるよう制限が設定されており、その他の属性には制限がありません。たとえば、ほとんどのデータフィールドは、YYYY-MM-DD HH:mm:ss の形式で入力する必要があります。


ウェアハウス内のデータ量が多い可能性があり、クエリーが複雑であるため、クエリーの結果が生成されるまで長い時間がかかることがあります。フォレンジッククエリーの実行中にクエリーページから移動すると、クエリーの結果を確認することができません。


フォレンジッククエリーを作成するには、次の手順に従います。

  1. 管理者インタフェースで、メインメニューの「コンプライアンス」をクリックします。
  2. 「監査ポリシー」ページ (「ポリシーの管理」タブ) が開きます。

  3. 「フォレンジッククエリー」二次タブをクリックします。
  4. 「データウェアハウスの検索」ページが開きます。

    図 16-5 データウェアハウスの検索
    「データウェアハウスの検索」ページ (フォレンジッククエリー)

  5. 「タイプ」ドロップダウンメニューから、ユーザーレコードとロールレコードのどちらを検索するかを選択します。
  6. 「OR の使用」チェックボックスを選択し、Identity Manager で、照会した各データタイプの結果の論理和が求められるようにします。デフォルトでは、結果の論理積を求める処理が実行されます。
  7. フォレンジッククエリーに含める予定のデータタイプが示されているタブを選択します。
    1. 「条件の追加」をクリックします。一連のドロップダウンメニューが表示されます。
    2. 左側のドロップダウンメニューからオペランド (チェックする条件) を選択し、右側のドロップダウンメニューから実行する比較のタイプを選択します。次に、検索する文字列または整数を入力します。使用できるオペランドのリストは外部のスキーマで定義されています。各オペランドの説明については、オンラインヘルプを参照してください。
    3. オプションの作業として、日付の範囲を選択してクエリーの範囲を絞り込みます。
    4. 必要に応じて、現在選択されているデータタイプにさらに条件を追加します。フォレンジッククエリーの定義の一部になるすべてのデータタイプについて、この手順を繰り返します。

  8. 選択可能な属性から、フォレンジッククエリーの結果に表示する属性を選択します。
  9. 「結果表示を次の件数に限定」フィールドに値を指定します。複数のデータタイプからの条件を使用する場合、各タイプのサブクエリーに制限が適用され、最終結果はすべてのサブクエリーの共通部分になります。そのため、サブクエリーの制限が原因で、最終結果から一部のレコードが除外される場合があります。
  10. 「検索」をクリックしてフォレンジッククエリーをただちに実行するか、クエリーを再利用するため「クエリーの保存」をクリックします。フォレンジッククエリーの再利用については、「フォレンジッククエリーの保存」を参照してください。

フォレンジッククエリーの保存

クエリーを設定 (オプションの作業として、クエリーを実行して必要な結果が生成されることを確認) したら、後で実行するためにクエリーを保存できます。

フォレンジッククエリーを保存するには、次の手順に従います。

  1. 「データウェアハウスの検索」ページから、「クエリーの保存」をクリックします。「フォレンジッククエリーの保存」ページが開きます。
  2. クエリーの名前を説明を指定します。
  3. 「条件値の保存」チェックボックスを選択し、「データウェアハウスの検索」ページで入力した条件の値 (文字列と整数) を保存します。このチェックボックスを選択しない場合、保存したフォレンジッククエリーはテンプレートとして機能し、クエリーを実行するたびに値を入力する必要があります。
  4. 保存されたクエリーはだれでも実行できますが、デフォルトでは、クエリーを変更できるのはクエリーの作成者のみです。ほかのユーザーがクエリーを変更できるようにするには、「ほかのユーザーがこのクエリーを変更することを許可」チェックボックスを選択します。
  5. クエリーではユーザーオブジェクトまたはロールオブジェクトが返されるため、結果にオブジェクトのどちらのオブジェクトの属性を表示するかを選択できます。「表示する属性」リストに含まれない属性を表示する場合は、「データエクスポータの設定」ページに移動し、表示可能な新しい属性を User または Role のタイプに追加することができます。

クエリーの読み込み

どのユーザーが保存したクエリーでも読み込みは可能ですが、変更できるクエリーは自分が作成したもの、またはほかのユーザーがだれでも変更できるとマークを付けたものだけです。

フォレンジッククエリーを読み込むには、次の手順に従います。

  1. 「データウェアハウスの検索」ページから、「クエリーの読み込み」をクリックします。「フォレンジッククエリーの読み込み」ページが開きます。クエリーがテンプレートとして保存された場合は、「クエリーの概要」列に「未完了のクエリー」と表示されます。
  2. クエリーの左側にあるチェックボックスを選択し、「クエリーの読み込み」をクリックします。


データエクスポータの維持

この節では、データエクスポータのステータスを追跡できる方法を説明します。

データエクスポータの監視

エクスポータが設定されて動作可能になったら、継続的な動作の確認のためにエクスポータの監視を行うことを選択できます。エクスポータには、エクスポータがどのように動作しているかを判断する場合に役立つ JMX Beans がいくつか用意されています。これらの JMX Beans には、エクスポータの平均読み取り/書き込みレート、内部メモリーキューの現在/最大のサイズ、および持続的なキューのサイズについての統計情報が含まれます。エクスポータでは、エクスポート中に監査レコードも作成されます。各データタイプの 1 サイクルごとに 1 つのレコードが作成されます。監査レコードには、そのタイプのレコードがエクスポートされた数や、エクスポートの所要時間が含まれます。

データエクスポータには、エクスポータの監視を行う次の JMX 管理 Beans が用意されています。

表 16-2 JMX 管理 Beans

Beans の名前

説明

DataExporter

現在キューにあるエクスポートの数と、キューの上限についての情報を格納しています。

DataQueue

現在キューにありキャッシュされているエクスポートの数と、キャッシュへの到着レートについての情報を格納しています。

ExporterTask

エクスポートの読み取り数 (Identity Manager から)、書き込み数 (ウェアハウスに対して)、読み取りと書き込みのレート (レコード数/秒)、およびエラーの数についての情報を格納しています。

通常の Identity Manager 操作中に、エクスポートレコードをキューテーブルに入れるようにデータエクスポータを設定できます。キューは、場合によっては大量のレコード数に応じて拡張し、サーバーの再起動後も保持される必要があるため、Identity Manager リポジトリ内のテーブルによって保持されます。リポジトリへの書き込みは一般的に、通常の Identity Manager 操作の速度を低下させるため、レコードがリポジトリ内で持続可能になるまで、キューは小さなメモリーキャッシュを使用してメモリー内にレコードをバッファーします。

DataQueue MBean 属性は、1 台の Identity Manager サーバー上でメモリーのキューに入れられたレコードの最大数を表示するように計画できます。バランスのとれたシステムでは、メモリーキャッシュ内のレコード数が少なく、数がすばやくゼロに向かうはずです。この数が大きくなったり (数千単位)、数秒以内にゼロに戻らなかったりすることが観察される場合、リポジトリの書き込みパフォーマンスを調査する必要があります。

ExportTask MBeans には、2 種類のエラー数の情報が含まれています。1 つが読み取り、もう 1 つが書き込みのエラーです。これらの数はゼロであるべきですが、特に書き込み中には、エラーが発生することがある理由がいくつか存在します。もっともよくある書き込みエラーは、エクスポートされたデータがウェアハウスのテーブル列内に入らないことから発生します。これは一般的に、文字列のオーバーフローです。エクスポートされる文字列データにはサイズの限度がないものがあります。この場合、エクスポートテーブル列に上限が設定されている必要があります。

監視ログ

Identity Manager には、限度なく大きくなる 2 セットのオブジェクトがあります。監査ログとシステムログです。データエクスポータは、ログテーブルに関連するメンテナンスの問題のいくつかに対処しています。

監査ログ

Identity Manager は、実行する操作の監査証跡の履歴として役立てるため、不変の監査レコードを監査ログに書き込みます。Identity Manager はこれらのレコードを特定のレポートで使用します。レコードのデータは、管理者インタフェースに表示されることがあります。しかし、監査ログは限度なく拡大しますが、あまり速くない速度で拡大するため、配備担当者はいつ監査ログの切り捨てを行うかを判断する必要があります。データエクスポータの前に、切り捨てに先立ってレコードを保持したい場合は、リポジトリからテーブルをダンプする必要があります。データエクスポータが有効にされていて、ログレコードをエクスポートするよう設定されている場合、古いレコードはウェアハウスに保持され、Identity Manager が必要に応じて監査テーブルを切り捨てることがあります。

システムログ

システムログは、監査ログと同じ不変のプロパティーを持っていますが、通常、監査ログと同じ頻度では生成されません。データエクスポータはシステムログをエクスポートしません。システムログを切り捨てて古いレコードを保持するには、リポジトリ内のテーブルをダンプする必要があります。



前へ      目次      索引      次へ     


Part No: 820-5433.   Copyright 2008 Sun Microsystems, Inc. All rights reserved.