Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド 12c (12.2.1.2.0) E85890-01 |
|
前へ |
次へ |
カタログの保守に関する情報については、次のトピックを参照してください。
次の各項の説明に従って、テスト環境から本番環境にカタログおよびシンプル・オブジェクト(権限付きダッシュボードなど)をデプロイできます。
テスト環境から本番環境にオブジェクト(権限付きダッシュボードなど)をデプロイできます。
(オプション)新しい本番環境にカタログ・オブジェクトをデプロイする場合。
次のようにして、テスト環境でカタログ・オブジェクトをアーカイブし、それを本番環境でアンアーカイブします。
次のいずれかを使用して、テスト環境のカタログ・オブジェクトをアーカイブします。
Oracle BIプレゼンテーション・サービス
カタログ・マネージャ
「カタログ・マネージャを使用したアーカイブとアンアーカイブ」を参照してください。
アーカイブ済ファイルを本番コンピュータにコピーします。
本番コンピュータで、オブジェクトをアンアーカイブします。
オブジェクトのアンアーカイブ方法の詳細は、「カタログ・マネージャを使用したアーカイブとアンアーカイブ」を参照してください。
必要に応じて、オブジェクトに権限を設定します。
(オプション)既存の本番環境にカタログをデプロイする場合。
次のように、新規または更新されたオブジェクトをテスト・カタログから本番カタログにコピーして貼り付けます。
2つのカタログ・マネージャ・ウィンドウ(一方はテスト・カタログ、他方は本番カタログ)を開きます。
必要なフォルダをテスト・カタログから選択してコピーし、本番カタログに貼り付けます。
テスト環境または本番環境で同じコンテンツを変更済のフォルダをコピーして貼り付けると、テスト環境のコンテンツによって本番環境のコンテンツが上書きされます。
より新しいバージョンのOracle Business Intelligenceにアップグレードするかパッチをインストールして、カタログでオブジェクトを使用すると、特定のオブジェクトへのアクセスが以前のリリースのように高速に実行されないことがあります。
この変化は、オブジェクトが正しくアップグレードされていない場合に発生する可能性があります。更新が必要かどうかは、Fusion Middleware Controlでメトリックを表示することによって確認できます。「カタログ」フォルダで、アップグレードが必要であることを示すオブジェクトの数という説明の付いた要アップグレードというメトリックを見つけます。この数が大きい場合は、プレゼンテーション・サービスの「管理」ページを使用してカタログ内のオブジェクトを更新することにより、この問題を解決できます。
Oracle Business Intelligenceアップグレード・ガイドの手順に従うことで、Oracle Business Intelligenceの新しいバージョンにアップグレードできます。カタログ・オブジェクトをアップグレードするには、Oracle Business Intelligenceアップグレード・ガイドのタスク5: Oracle BIリポジトリおよびカタログのアップグレードに関する項を参照してください。プレゼンテーション・サービスが実行されていないときにアップグレードすることをお薦めします。アップグレード・プロセス中にオブジェクトのアップグレードが完全には実行されなかったことが疑われる場合は、「管理」ページを使用して、自分でオブジェクトを更新できます。この方法の利点は、プレゼンテーション・サービスを実行したまま更新を行えることにあります。
オブジェクトの更新を準備する際は、次の点に留意してください。
クラスタ内でマシンのローリング・アップグレードを実行している場合は、クラスタ内のすべてのマシンがアップグレードされるまで、このオプションやUpgradeAndExit構成設定は使用しないでください。
このオプションは、一度にクラスタ内の1つのノードでのみ使用します。
カタログは保守が必要となる動的なコンポーネントです。
時間の経過とともに、リンクが破損する、ユーザーが削除される、NFSファイル・システムの問題が発生するなどカタログ内に非一貫性が発生することがあります。これらの非一貫性は、最終的にエージェントの受信者リストを編集できなくなるなど、不適切な動作につながることがあります。本番システムを定期的にオフラインにしてカタログを検証し、非一貫性を検出して、修正操作を実行できます。
この項では、カタログの検証に関する次の項目について説明します。
カタログの検証プロセスには、オフライン・モードでのカタログのレポートの作成や、調整または削除が必要なオブジェクトの確認があります。
一部のオブジェクトは、オフライン・モードで手動で修正できます。その後、検証操作を再度実行して、不要なオブジェクトを削除することによりシステムを「クリーン」にできます。カタログの検証が終了するまで、レポートの作成、エラーの手動修正およびカタログのクリーンを繰り返します。
システムを検証すると、プロセスが円滑に実行されていることを確認できます。
検証プロセスでは、次のタスクを実行します。
カタログ内の各オブジェクトが0バイトよりも大きいことを確認します。
カタログ内の各項目に、対応する有効な.atrファイルがあることを確認します。
カタログ内の各リンクが有効であることを確認します。
アカウント・キャッシュ内のファイルが有効であることを確認します。
カタログ内のすべてのXMLオブジェクトがスキーマ検証に通ることを確認します。
ftpプログラムによって損傷したオブジェクト名の修復を試みます。
カタログを検証する前に、特定のガイドラインに留意してください。
開発環境に本番環境とは異なるセキュリティ・ストアがある場合は、開発環境でカタログを検証する際に注意する必要があります。異なるセキュリティ・ストアを使用して検証を実行すると、多くのアカウントがカタログから削除される可能性があります。
カタログの検証をオンにすると、すべてのACL (つまり、すべての権限と各項目の権限)が「スクラブ」されます。これは、それらからデッド・アカウントが削除され、変更されたすべての項目がディスクに書き込まれることを意味します。そのため、破損した項目を自動的に修正せずに単にレポートを作成するだけであっても、カタログが広範囲に「変更」されることがあります。
クラスタ環境でカタログを検証する前に、次のいずれかを実行します。
プレゼンテーション・サービス・クラスタを停止し、そのクラスタのカタログに対して検証を直接実行します。
クラスタのカタログのコピーを作成し、そのコピーに対して検証を実行します。
7-Zipユーティリティを使用してカタログのコピーを作成する前に、プレゼンテーション・サービス・クラスタのすべてのノードを停止するか、そのクラスタのすべてのノードをメンテナンス・モードにします(推奨方法)。
検証プロセスと同時にオンラインでカタログに行った変更は、検証には含まれません。
カタログのバックアップが常に推奨されていますが、検証をカタログに対して直接実行することと、バックアップ・コピーに対して実行することの実際的な違いはありません。