Oracle® Fusion Middleware Oracle Business Intelligenceアップグレード・ガイド 11g リリース1(11.1.1.6.2) B63034-04 |
|
![]() 前 |
![]() 次 |
この章では、Oracle Business Intelligence 10gシステムをOracle Business Intelligence 11gシステムに正しくアップグレードする計画を立てる方法について説明します。項目は次のとおりです。
注意: このドキュメントの記載内容は執筆時点において正確です。このドキュメントは、ソフトウェアのリリース後に定期的に更新されます。このドキュメントの最新情報および追加情報は、次のOracle Technology Networkサイトを参照してください。
|
Oracle Business Intelligenceの新たなリリースを検討する際、アップグレードを実行するか、パッチセット、バンドルパッチもしくは個別パッチを適用するかにより、必要となるツールやドキュメントは異なります。
パッチ適用とアップグレードの相違点の詳細は、『Oracle Fusion Middlewareパッチ適用ガイド』のインストール、パッチ適用およびアップグレードの用語に関する項を参照してください
特にSiebel Analytics 7.8以降のOracle Business Intelligenceについて、あるリリースから別のリリースに移行するために必要な手順を図1-1に示します。
図1-1 Oracle Business Intelligence 11gのアップグレードおよびパッチ適用のプロセス
図1-1に示した各操作の詳細は、次を参照してください。
Siebel Analytics 7.8からOracle Business Intelligence 10.1.3.xへのアップグレードについては、Oracle Technology Network (OTN)のサイトで、Oracle Business Intelligence Suite Enterprise Editionリリース10.1.3.2ドキュメント・ライブラリのアップグレード・ドキュメントを参照してください。
Oracle Business Intelligence 10g (10.1.3.x)からのアップグレードについては、このアップグレード・ガイドを使用して、Oracle Business Intelligence 11gリリース1 (11.1.1)を参照してください。
既存のOracle Business Intelligence 11gリリース1 (11.1.1.3.0)への11gリリース1 (11.1.1.6.0)パッチ・セットの適用または11gリリース1 (11.1.1.5.0)インストールについては、第1.7項「11.1.1.3または11.1.1.5から11.1.1.6への移行」を参照してください。
Oracle Business Intelligenceパッチ(1.1.1.6.1または11.1.1.6.2など)を適用するためのOPatchの使用については、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceシステムへのパッチの適用に関する項を参照してください。
Oracle Business Intelligence 10gシステムをOracle Business Intelligence 11gにアップグレードするには、注意深く準備、計画およびテストを行う必要があります。Oracleでは大部分のアップグレード・プロセスを自動化するツールおよびテクノロジを提供しています。ただし、採用する厳密な戦略は、既存の10gシステムの構成、およびアップグレードされる11gシステムの必要な構成によって異なります。
重要なポイントは、本番環境の10gシステムはアップグレード・プロセスに影響されないということです。既存の10gシステムは、11gシステムのロールアウトの準備ができるまで使用し続けることができます。
効率的なアップグレード戦略を作成するために、次の手順を実行することをお薦めします。
最終的に決定したアップグレード戦略は、たいてい使用している環境に固有になります。重要なポイントの1つは、システムの最適化です。最適化には、不要なコンテンツ、重複するコンテンツ、使用されてないコンテンツの削除が含まれます。また、類似のコンテンツのマージおよび連結やパフォーマンス最適化が最適化に含まれる場合もあります。10gのデプロイの最適化が貧弱だと、11gでさらにそれが悪化するため、アップグレード・アシスタントの作業が本来の処理より煩雑になる場合があります。
アップグレード戦略の適切性を判断する際に、次の2つの例が有用です。ただし、これらは単なる例にすぎません。このほかにも様々な戦略が考えられ、選択する戦略は、固有のトポロジや組織の要件によって異なります。
この例では、既存のシステムを分析した結果、不要なリクエストと不正なユーザーが多数存在することが判明しています。その場合の最も有効的なアップグレード戦略は、アップグレードする前に既存の10gシステムを最適化するということです。一般的には、次の手順に従ってそのような戦略を実装します。
本番のOracle Business Intelligence 10gシステムを10gテスト環境にコピーします。
10gテスト環境で、Oracle Business Intelligence 10gシステムをアップグレードできるように最適化します。
新しいテスト環境で、Oracle Business Intelligence 11gをインストールします。
新しい11gテスト環境で、11gアップグレード・アシスタントを実行して、インポートおよびアップグレードするシステムとして10gテスト環境の10gシステムを指定します。
11gテスト環境で、新しい11gシステムのアップグレード後の手順をすべて実行します。
11gテスト環境で、新しい11gシステムが想定どおりに実行されるかテストし、必要に応じて、アップグレード後の追加構成を実行します。
システムを11gテスト環境から11g本番環境へ移行します。
この例のアップグレード戦略を、図1-2「アップグレード戦略の例: BI 10gシステムの11gへのアップグレード: アップグレード前に実行する最適化」に示します。
この例では、既存のシステムを分析した結果、システムはすでに最適化されていることが判明しています。その場合の最も効果的なアップグレード戦略は、まず既存の10gシステムをアップグレードしてから、11gシステムの最適化を実行した後、本番環境に移行します。一般的には、次の手順に従ってそのような戦略を実装します。
新しいテスト環境で、Oracle Business Intelligence 11gをインストールします。
新しい11gテスト環境で、11gアップグレード・アシスタントを実行して、インポートおよびアップグレードするシステムとして10g本番環境の10gシステムを指定します。
11gテスト環境で、新しい11gシステムのアップグレード後の手順をすべて実行します。
11gテスト環境で、新しい11gシステムを最適化します。
11gテスト環境で、新しい11gシステムが想定どおりに実行されるかテストし、必要に応じて、アップグレード後の追加構成を実行します。
システムを11gテスト環境から11g本番環境へ移行します。
この例のアップグレード戦略を、図1-3「BI 10gシステムの11gへのアップグレード: アップグレード後に実行する最適化」に示します。
既存のOracle BI 10gシステムをアップグレードするには、時間とリソースが必要です。そのため、既存の10gシステムを分析して、アップグレードを実行する前に、不要なコンテンツ、重複するコンテンツおよび使用されていないコンテンツを削除して、既存のシステムを最適化することをお薦めします。
既存の10gシステムを分析する場合、現在稼働しているハードウェアおよびオペレーティング・システム環境を考慮してください。ハードウェアおよびソフトウェア要件、プラットフォーム、データベースなどのシステム要件および動作保証に関するドキュメントを参照して、それらと現在の環境を比較します。場合によっては、11gで要件が変更されていることがあります。たとえば、Oracle BI 11gで異なるバージョンのオペレーティング・システムが必要になる場合があります。詳細は、次を参照してください。
システム要件のドキュメントは、次の場所にあります。
http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-requirements-100147.html
動作保証のドキュメントは、次の場所にあります。
http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html
注意: アップグレード・プロセスの一部で、プラットフォームまたはアーキテクチャを変更しないでください。 たとえば、既存の10gシステムが32ビットのWindowsプラットフォームで稼働している場合、Oracle BI 11gを64ビットのLinuxプラットフォームにインストールし、64ビットのLinuxのアップグレード・アシスタントを実行して既存の10gシステムをアップグレードしないでください。 同じプラットフォームおよびアーキテクチャ上で要件を満たすために、Oracle BI 11gを既存の10gシステムと同じハードウェアにインストールすることができます。ただし、10gと11gのリリースの共存は、本番環境には適切ではありません。このような共存環境では、十分なハードウェア・リソースを使用できる必要があり、ポート管理を注意深く行う必要があります。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイド』を参照してください。 |
既存の10gシステムの分析の一環として、関連する次の詳細情報をすべて記録します。
リポジトリの名前およびサイズ
Oracle BI Presentation Catalogの名前およびサイズ
既存のセキュリティ・モデルの詳細
データソース
スケジュールされたジョブの数
外部システムへのすべてのリンク
アップグレードする前に10gシステムを最適化することで、次のようになります。
アップグレード・プロセスがより速く確実に実行されます。
アップグレードされたシステムのテストにより多くの時間をかけることができます。
新しくアップグレードされた11gシステムは、効率的に動作します。
既存の10gシステムのアップグレードを準備する際に最適化するには、次のタスクを実行します。
整合性チェッカを実行して10gリポジトリの妥当性をチェックし、問合せの失敗の原因となりうる文法またはセマンティック上のエラーおよび警告を特定および修正します。
使用されていない初期化ブロックをすべて削除します。
不要になったためアップグレードする必要がなくなったユーザーおよびグループを特定して削除します。
ダッシュボードおよび分析プロンプトで使用される日付形式をカスタムで指定している場合、日付形式に関する問題について説明されている次の2つのSupport Tech Noteに使用する形式が準拠していることを確認してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1108451.1
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1108594.1
これらのNoteには、10g環境で使用される正しい形式の仕様に関する重要な情報が記載されています。これらのNoteの指示に従って、日付形式を使用するプロンプトが正しくアップグレードされるようにします。
不要になったためにアップグレードする必要がなくなったリポジトリおよびOracle BI Presentation Catalogのオブジェクトを特定して削除します。
Oracle BI Server使用状況トラッキング機能を使用している場合は、使用状況トラッキング・データを確認して、使用されていないオブジェクトを特定します。使用状況トラッキングを使用しておらず、すぐにアップグレードを行う予定がない場合は、使用中のデータをアップグレード前に明確に把握しておく手段として、使用状況トラッキングの有効化を検討してください。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』の使用状況トラッキングの管理に関する項を参照してください。
『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のカタログの検証に関する項の説明にあるように、検証機能を使用してカタログをクリーンします。
Oracle BI 11gでは、既存の機能の多くが強化されています。場合によっては、これらの機能強化で以前の機能を置き換えたり、様々な方法でそれを再実装しています。
以前の10gの機能は、可能なかぎり対応する(かつ多くの場合、機能強化された)11g機能にアップグレードされます。表示や動作が異なる場合もありますが、最終的な結果は機能的に同じことが期待できます。
効率的なアップグレード方針では、元の10gシステムの外観および動作を、アップグレードされたシステムで正確に再現しようとはしません。正確に再現させようとすると、時間がかかり、場合によっては(不可能でなくても)非常に困難になることがあります。たとえば、既存のダッシュボードおよびプロンプトは11gでは異なる方法でレンダリングされ、10gの外観を再作成するには、大量の人手の介入が必要になります。10gの外観および動作を正確に再現しようとすると、そもそものアップグレードの原理が損なわれることもあります。つまり、11gに導入された拡張機能が利用できなくなります。
そのため、何をどのようにアップグレードするかを理解することは非常に重要になります。詳細は、次の項を参照してください。
スキン、カスタマイズされたJavaScriptファイル、および構成ファイルなどの一部の要素は自動的にはアップグレードされないので注意してください。
何をどのようにアップグレードするかを理解したら、10gシステムが想定どおりにアップグレードされたかを検証するためのテスト計画を定義します。
一般的には、テスト計画で次を特定します。
テスト・アップグレードとして使用する既存の10gシステムの代理サブセット。
テスト・アップグレードが正常に終了したかを検証する際に使用するキー・インジケータの数。
完全アップグレードが正常に終了したかを検証する際に使用する追加のキー・インジケータ。
重要: アップグレードの成否の確認に使用するキー・インジケータを特定する場合、アップグレードされたシステムの外観および動作は元の10gシステムと異なる場合があるので注意してください。そのため、アップグレードされたシステムと10gシステムの違いを見いだすよりも、検証作業によりアップグレードの前後で機能的に等しいことを確認することに専念することの方が重要になります。 11gへのアップグレード後に予想される外観の違いの例については、第1.4.2項「Oracle BI Presentation Catalog: その他のアップグレードの考慮事項」を参照してください。 |
定義するテスト計画は、使用する状況に固有になります。次の例は有用であることは明らかですが、単なる例にすぎません。最終的に決定するテスト計画は、多くの場合異なるものになります。
この例では、アップグレード・アシスタントを使用して、段階的に既存の10gシステムをアップグレードしています。各段階でアップグレード・アシスタントを実行した後に、システムのアップグレードされた部分を検証し、手動で追加手順を実行します。
表1-1 アップグレード・テスト計画の例
ステージ | 説明 | 検証手順 | 手動手順 |
---|---|---|---|
ステージ1 |
アップグレード・アシスタントを実行して、10gのスケジューラ・スキーマを11gにアップグレードします。 |
|
|
ステージ2 |
データソース接続を再構成します。 |
|
11gのデータソースへの接続設定の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。 |
ステージ3 |
アップグレード・アシスタントを実行して、10gリポジトリをアップグレードします。 |
|
|
ステージ4 |
アップグレード・アシスタントを実行して、10g Oracle BI Presentation Catalogをアップグレードします。 |
|
|
ステージ5 |
アップグレード・アシスタントを実行して、BI Publisher 10gカタログを11gにアップグレードします。 |
|
|
ステージ6 |
アップグレード・アシスタントを実行して、BI Publisher 10g Schedulerを11gにアップグレードします。 |
|
なし |
テスト・アップグレードを実行することで、次の処理を行います。
既存の10gシステムのアップグレードが成功する可能性が高いかを迅速に検証します。
既存の10gシステムとアップグレードされた11gシステム間で発生しうる差異を詳細に検証します。
テスト・アップグレードを極力効率的に実行するために、次の処理を行います。
10gシステムを最適化します(詳細は、第1.2.1項「ステップ1: アップグレードの準備段階における既存の10gシステムの分析および最適化」を参照してください。)
最初に既存の10gシステムのオブジェクトの代理サブセットのみをアップグレードします。このサブセットは、カタログのコピーを作成し、テストしないものを削除することで取得できます。
ヒント: 10gに付属のSample SalesアプリケーションまたはPaintアプリケーションで、アップグレード・プロセスをテストできます。このアップグレードにより、限定的なサンプルでそのプロセスを学習できます。 |
第5章「Oracle Business Intelligence Enterprise Editionのアップグレード」の指示に従って、テスト・アップグレードを実行します。要約すると、次のような処理を実行します。
Oracle Business Intelligence 11gソフトウェアをインストールします。
新しい11gシステムで、アップグレード・アシスタントを実行します。
アップグレード・アシスタントは、既存の10gリポジトリ・ファイルおよびOracle BI Presentation Catalogから新しい11gシステムにメタデータをインポートして、必要に応じて、それが11g環境で機能するようにアップグレードします。
スケジューラ・スキーマをアップグレードします。
インストール後の手順を実行します。
アップグレード・プロセスが完了した後も、10gシステムはそのまま残ります。
前に作成したテスト計画を使用して、テスト・アップグレード・プロセスが正常に完了し、アップグレードされたシステムが想定どおりに要件を満たしていることを確認します。
前に説明しているように、アップグレードされたシステムの外観および動作は元の10gシステムと異なる場合があるので注意してください。そのため、アップグレードされたシステムと10gシステムの違いを見いだすよりも、検証作業によりアップグレードの前後で機能的に等しいことを確認することに専念することの方が重要になります。
テストにより、外観の違い以外に、元の10gシステムとアップグレードされた11gシステムとの間で重大と考えられる差異が明らかになることがあります。その場合、アップグレードの内容とその理由を再確認することをお薦めします。詳細は、「ステップ2: アップグレードの対象とそのアップグレード方法について」を参照してください。
テスト・アップグレードでは、アップグレード・プロセスの検証のほかに、11gで追加または強化された機能の一部をテストできる理想の環境を提供します。目的の新しい機能の詳細は、次の各項を参照してください。
テスト・アップグレードを実行して、アップグレードされたシステムが要件を満たされていたら、続けてOracle BI 10gシステム全体の完全アップグレードを実行できます。
第5章「Oracle Business Intelligence Enterprise Editionのアップグレード」の指示に従って、完全アップグレードを実行します。要約すると、次のような処理を実行します。
Oracle Business Intelligence 11gソフトウェアをインストールします。
新しい11gシステムで、アップグレード・アシスタントを実行します。
アップグレード・アシスタントは、既存の10gリポジトリ・ファイルおよびOracle BI Presentation Catalogから新しい11gシステムにメタデータをインポートして、必要に応じて、それが11g環境で機能するようにアップグレードします。
スケジューラ・スキーマをアップグレードします。
インストール後の手順を実行します。
アップグレード・プロセスが完了した後も、10gシステムはそのまま残ります。
完全アップグレードを実行したら、前に作成したテスト計画を使用して、アップグレード・プロセスが正常に完了し、アップグレードされたシステムが想定どおりに要件を満たしていることを確認します。
前に説明しているように、アップグレードされたシステムの外観および動作は元の10gシステムと異なる場合があるので注意してください。そのため、アップグレードされたシステムと10gシステムの違いを見いだすよりも、検証作業によりアップグレードの前後で機能的に等しいことを確認することに専念することの方が重要になります。
テストにより、外観の違い以外に、元の10gシステムとアップグレードされた11gシステムとの間で重大と考えられる差異が明らかになることがあります。その場合、アップグレードの内容とその理由を再確認することをお薦めします。詳細は、「ステップ2: アップグレードの対象とそのアップグレード方法について」を参照してください。
完全アップグレード・プロセスを検証したら、使用する予定の11gの追加機能および拡張機能を実装できます。
アップグレードされた11gシステムと元の10gシステムは、機能的に等しくても、外観および動作が異なる場合があります。
多くの場合、既存の10gの機能は、アップグレード時に11gで導入された同等の機能を使用して再実装されます。ただし、アップグレード・プロセスでは、元の10gに存在していた機能のみをアップグレードします。11gで導入された新しい機能を使用して11gシステムを改善するように示唆することは特にはしません。
11gの新しい機能を使用してアップグレードされたシステムの向上を確認するには、次の項を参照してください。
Oracle BI EE 11gで作業する前に、Oracle BI EE 11gリポジトリ・ファイルをアップグレードする必要があります。アップグレード・プロセス時に、アップグレード・アシスタントを使用して、リポジトリ・ファイルをアップグレードします。
ただし、アップグレード・アシスタントを実行する前に、特に注意する必要がある領域が多数あります。詳細は、第1.3.1項「リポジトリ・メタデータ: 主なアップグレードの考慮事項」を参照してください。
第1.3.1項で説明されている主なアップグレードの考慮事項のほかに、リポジトリ・メタデータのアップグレードを計画する際に考慮する必要がある要素は多数あります。詳細は、第1.3.2項「リポジトリ・メタデータ: その他のアップグレードの考慮事項」を参照してください。
元の10gシステムとアップグレードされた11gシステムとでは様々な点が変更されています。また、Oracle BI 11gには新しい機能も多数導入されているため、アップグレードされたシステムでこれらの機能の実装を検討してみてもよいでしょう。詳細は、第1.3.3項「BIリポジトリ・メタデータ: 11gの注目の新機能」を参照してください。
この項では、Oracle BIリポジトリ・メタデータに関するアップグレードの考慮事項について説明します。内容は次のとおりです。
10gでは、整合性チェッカを通っていながら実行時に想定外の問合せの動作を引き起こしたり、MUDチェックアウト時に整合性がとれなくなるモデリング構造がいくつかありました。11gでは、整合性チェック・マネージャはリポジトリの一貫性の確認に役立つ追加の検証ルールを実施することでこの問題に対処しています。さらに、以前のリリースで存在していたいくつかのルールは整合性チェック時に表示できるようになりました。次の表に、それらのルールの要約を示します。
検証ルールの例 | タイプ | 説明 |
---|---|---|
[14031] 論理表FACT_TABLE_NAMEのソースの索引フィルタは、複数のディメンションを参照します。 |
エラー |
特定の論理表に複数のディメンションを参照するWHERE句フィルタを含む論理表ソースがあります。複数のディメンションを含むWHERE句は無効です。 |
[38126] 'Logical Table' '"Technology - WFA"."Fact WFA WO "'の名前の先頭または末尾にスペースがあります。 |
エラー |
オブジェクト名の先頭または末尾にスペースがあります。 リポジトリ・オブジェクト名の先頭または末尾をスペースにすることはできなくなりました。オブジェクト名の先頭または末尾にスペースがあると、問合せまたはレポートで問題が発生する場合があります。 |
[38012] 論理列DIM_Start_Date.YEAR_QUARTER_NBRには物理データ型のマッピングがなく、派生列でもありません。 [38001] 論理列DIM_Start_Date.YEAR_QUARTER_NBRに物理データ・ソースのマッピングが含まれていません。 |
エラー |
いずれの論理表ソースにもマップされていない論理列は、論理表ソース・マッピングが無効であり問合せの失敗の原因となるため、整合性エラーとしてレポートされます。 両方の特定の検証ルールは、同じ問題に関連しています。 |
[39028] データベース'MyDB'の機能がデフォルトと一致しません。この結果、問合せ問題が発生する可能性があります。 |
警告 |
一部のデータベース機能のデフォルトは、Oracle BI EE 11gで変更されました。機能セットに特定のカスタマイズがなければ、データベース機能を新しいデフォルトにリセットすることをお薦めします。 |
[39003] 列DIM_Offer_End_Date.CREATE_DTの機能依存結合が見つかりません。 |
警告 |
この警告は、特定の列が無効な論理表ソースにマップされていることを示しています。デフォルトの動作が不適切な場合、警告によってこの問題についてリポジトリ開発者に注意しています。 |
[39055] ファクト表"HR"."FACT - HC Budget"は論理ディメンション"HR"."DIM - HR EmployeeDim"の表と結合していません。これにより、プロジェクトの抽出時に問題が発生します。 |
警告 |
この警告は、特定のファクトとディメンション・ソースの間に物理結合があるものの、ファクト表とディメンション表の間に相応の論理結合がないことを示しています。 |
[39059] 論理ディメンション表MY_DIMのレベルDailyに、上位レベルのファクト・ソースMY_FACT_SUM.MTHLY_SUMと結合するソースMY_DIM_DAILYがあります |
警告 |
このファクト論理表ソースにこのディメンションで設定された集計のマス目がありますが、このディメンションの論理表ソースに接続する結合が見つかりませんでした(または潜在的に不正な結合が見つかりました)。 これは、結合が存在しないか、存在しているが高レベルのファクト・ソースと低レベル次元ソースを接続しているため、潜在的に不正であることを意味します。このような結合は、実行すると問合せの回答でダブル・カウントが発生する可能性があるため、潜在的に不正になります。 たとえば、「Select year, yearlySales」という問合せについて考えます。monthTable表とyearlySales表との間にyearIdでの結合が存在していても、この結合により結果が12の倍数(各年の月数)に増加するため、これを使用しないでください。 アップグレード後に39059警告が発生したら、結合が仕様どおりに機能しているか、および結果が不正にダブル・カウントされていないかどうかを確認します。結合が仕様どおりであれば、39059警告は無視してください。 |
[39054] ファクト表"Sales - STAR"."Fact - STAR Statistics"は論理ディメンション表"Sales - STAR"."Dim - Plan"と結合していません。これにより、プロジェクトの抽出時に問題が発生します。 |
警告 |
この警告は、ファクト表の論理表ソースの集計コンテンツ・フィルタ「Group by Level」が、そのファクト表に結合されていない論理ディメンション表を参照していることを意味します。ファクト表がextract/MUDプロセスで抽出されない場合、結合されていないディメンションは抽出されません。その場合、抽出される論理表ソースの集計コンテンツは、元の論理表ソースと同じにはなりません。 |
[39057] 論理表ソース""HR"."Dim - Schedule"."SCH_DEFN""には、列マッピングまたは式で使用されていない物理表がマップされています。 |
警告 |
この警告は、特定の論理表ソースにマッピングで使用されていない無関係の表が追加されていることを示しています。この状況でエラーが発生することはありません。 |
前の表で説明した検証ルールのほかに、次の点に注意してください。
整合性チェック・マネージャでは、同じ接続プールが問合せと初期化ブロックの両方に使用されている場合、警告を発行するようになりました。この構成はお薦めしません。そのかわりに、初期化ブロックに専用の接続プールを作成します。そうしないと、問合せのパフォーマンスが低下したり、認証の初期化ブロックを実行できずにユーザー・ログインがハングする可能性があります。これらの警告は、次のように表示されます。
[39062] Initialization Block 'Authorization' uses Connection Pool '"My_DB". "My_CP"' which is used for report queries. This may impact query performance.
無効なオブジェクトは、整合性チェック時に削除されるようになりました。この動作により、論理表ソースおよび論理列で式およびフィルタが削除されてしまうことがあります。不正な参照は、物理レイヤーでオブジェクトが削除され、ビジネス・モデルおよびマッピング・レイヤー・オブジェクトで参照が正しく考慮されていないときに発生する可能性があります。
この項では、Oracle BI Serverの問合せに対する変更について説明します。
整数の除算では、次の点に注意してください。
10gでの2つの整数を使用した除算の動作は、式が内部で評価されたか、またはANSI標準の整数の除算に準拠したデータソースに送信されたかどうかによって、整合性がありませんでした。
Microsoft SQL Serverに送信されるか、内部で評価された場合(問合せがOracle BI Server結果キャッシュから返された場合など)、7/2は3になりました。
Oracle Databaseに送信されると、7/2は3.5でした。
11gでの2つの整数による除算は、Oracle Databaseに除算が送信されても、常に整数値になります(結果は切り捨てられます)。小数の除算が必要な場合は、付録B「アップグレード後に予想されるOracle BI Enterprise Editionの外観と動作の変化」の指示に従って、値をキャストします。
結合では、次の点に注意してください。
10gのOracle BI Serverでは、ファクト論理表ソース(Monthレベルなど)と低レベルのディメンション論理表ソース(Dayレベルなど)との結合が可能でした。通常、このように結合すると、ダブル・カウントが発生します。
11gでは、ファクト論理表ソースが低レベルのディメンション論理表ソースと結合して潜在的に不正な結合になると、新しい整合性チェックで警告(39059)が表示されます。アップグレード後に39059警告が表示されたら、結合が仕様どおりに行われ不正にダブル・カウントされていないかどうかを確認してください。結合が仕様どおりであれば、39059警告は無視してください。
リポジトリをアップグレードする際は、次の考慮事項に注意してください。
Oracle BI 11gでのFusion Middleware Controlの使用に関して、次の変更点があるので注意してください。
デフォルトの公開リポジトリを含め、リポジトリの開発に影響する多くの構成設定は、Fusion Middleware Controlで一元管理されるようになりました。これらの構成設定は、NQSConfig.INIで手動で変更することはできなくなります。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』を参照してください。
オンライン・モードで管理ツールを使用してOracle BI Serverを再起動することはできなくなります。かわりに、Fusion Middleware Controlを使用してOracle BI Serverやその他のシステム・コンポーネントを再起動できます。
また、BIシステム管理APIを使用して、プログラムによってOracle BI EEを起動および停止することもできます。
詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceの起動と停止に関する項およびBIシステム管理APIを使用したOracle Business Intelligenceの起動と停止に関する項を参照してください。
Oracle BI 11gでは、セキュリティに関して次の変更点があるので注意してください。
次のセキュリティ関連の変更点に注意してください。
リポジトリは、リポジトリ固有のパスワードを使用してリポジトリ・コンテンツを暗号化するようになりました。リポジトリ・パスワードは、Oracle BI Serverがパスワードを取得してリポジトリをロードできるように、Fusion Middleware Controlでリポジトリを公開するときに、外部資格証明ストアに保存されます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のリポジトリ・パスワードの変更に関する項を参照してください。
11gでは、リポジトリ・パスワードを空にすることはできません。
リポジトリにはオブジェクトとしてのグループがなくなりました。かわりに、ユーザーが属するアプリケーション・ロールに基づいて、データ・アクセス・セキュリティを実装します。
アプリケーション・ロールは、外部ポリシー・ストアで管理されます。アプリケーション・ロール・オブジェクトはリポジトリに存在しますが、これらのオブジェクトは外部で管理されるロールへのポインタ(参照)になります。
ユーザーは外部認証プロバイダで管理され、リポジトリで管理されることはなくなりました。ユーザー・オブジェクトはリポジトリに存在しますが、これらのオブジェクトは外部で管理されるユーザーへのポインタ(参照)になります。
これらを含めたセキュリティの変更の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。また、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のデータ・アクセス・セキュリティのリポジトリ・オブジェクトへの適用に関する項も参照してください。
Oracle BI ServerのデフォルトのODBC DSNの接続パラメータはFusion Middleware Controlで一元管理され、手動で変更できなくなりました。
また、Oracle BI EEはデフォルトではクラスタ化された構成でデプロイされるようになりました。そのため、Oracle BI ServerのデフォルトのODBC DSNは、Oracle BI Serverではなく、クラスタ・コントローラを指しています。
Oracle BI ServerのODBC DSNの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionインテグレーターズ・ガイド』の他のクライアントとOracle Business Intelligenceとの統合に関する項を参照してください。
Oracle BI EE 11gには、稼働中のシステムに対して、次のような追加的な依存性があります。
インストール時に指定されたリレーショナル・データベースが稼働している必要があります。このデータベースには、リポジトリ作成ユーティリティ(RCU)を使用してロードされた必要なOracle BI EEスキーマが格納されます。
11gのインストール時に簡易インストール・オプションを選択した場合、Oracle WebLogic Serverで管理サーバーを実行してから、アップグレード・アシスタントを起動する必要があります。エンタープライズ・インストール・オプションを選択した場合は、アップグレード・アシスタントを起動する前に管理サーバーおよびいずれかの管理対象サーバーが稼働している必要があります。
任意のOracle BI Serverコマンドライン・ユーティリティを実行する前に、bi-init.cmd(UNIXの場合はbi-init.sh)を実行して、Oracleインスタンスに対して初期化されるコマンド・プロンプトまたはシェル・ウィンドウを起動する必要があります。
このユーティリティは次の場所にあります。
ORACLE_INSTANCE/bifoundation/OracleBIApplication/coreapplication/setup
詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のbi-initの実行によってOracleインスタンスに対して初期化されるシェル・ウィンドウの起動に関する項を参照してください。
この項では、11gでのデータソースの接続性に対する変更について説明します。
Oracle Databaseデータソースの設定: Oracle Databaseデータソースの接続プールのネット・サービス名を使用する場合、Oracle BI Serverでエントリを特定できるように、Oracle BI EE環境内の次の場所でtnsnames.oraファイルを設定する必要があります。
ORACLE_HOME/network/admin
Essbaseデータソースの設定: 11gでEssbaseとの接続に推奨されるクライアントのバージョンは、次のディレクトリのOracle BI EEにバンドルされた11.1.2.xクライアントです。
ORACLE_HOME/clients/epm/Essbase/EssbaseRTC
管理ツールに接続するためのbi-init.cmdでのEssbase変数の追加などの追加手順の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
Teradataデータソースの設定: WindowsでTeradataに接続する場合、opmn.xmlを編集して必要なTeradata変数を含める必要があります。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
Oracle BI 11gでは、管理ツールに関して次の変更点があるので注意してください。
管理ツールは、リポジトリ・ファイルをダブルクリックして開くことができなくなりました。そのように開くと、Oracleインスタンスに対して管理ツール・ウィンドウは初期化されず、セッションの後半でエラーが発生します。そのかわりに管理ツールは、必ず「スタート」メニューから開くか、コマンドラインでbi-init.cmdを使用して起動します。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』の管理ツールの起動に関する項を参照してください。
物理モデルおよびビジネス・モデルのダイアグラムでは、結合の「一」の方に矢印がある線で表されます。以前のリリースでは、結合の「多」の方にカラスの足跡のような形を使用した線で表していました。
たとえば、以前のリリースのダイアグラムで示されていた結合を次の図に示します。
11gリリース1では、この結合が次のように表されます。
物理モデルおよびビジネス・モデルのダイアグラムで結合を作成する場合、まず結合の「多」の方を選択してから「一」の方を選択するようになりました。以前のリリースでは、ダイアグラムで最初に結合の「一」の方を選択して結合が作成されていました。
この新しい(多対一の)動作は、前の箇条書きで説明されている新しい結合の矢印の方向と一致します。
プレゼンテーション・レイヤーのプレゼンテーション・カタログは、サブジェクト・エリアと呼ぶようになりました。
Oracle BI 11gでは、リポジトリ・モデリングに関して次の変更点があるので注意してください。
ブリッジ表は、リポジトリ・モデリング・テクノロジを使用して識別されるようになりました。以前のリリースに存在していた「論理表」ダイアログの「ブリッジ表」オプションを使用して識別することはなくなりました。リポジトリをチェックして、ブリッジ表が適切にモデリングされているか確認してください。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のブリッジ表のモデリングに関する項を参照してください。
一部の問合せである結果を返していたが、このリリースで異なる結果を返すようになる場合があります。問合せに使用される論理表ソースが厳密に順序付けて決定されるようになったため(以前のリリースでは無作為に決定)、このような動作が発生します。モデリングを検証および調整して、動作を修正します。
10gでは、同じ論理表の2つの論理表のソースが同一の物理表にマップされており、問合せに両方の論理表のソースが使用され、両方の論理表のソースにWHERE句フィルタがある場合、これらの論理表のいずれかのソースのみのフィルタが適用されていました。もう一方のWHERE句フィルタは無視されていました。
11gでは、このような状況が発生すると、両方の論理表ソースのWHERE句フィルタが問合せに適用されます。一般的には、この動作により適切な結果が得られます。この問題に関するエラーが発生した場合、物理表の別名を使用して同じ物理表が別のレベルで同じ論理表にマップされないようにすることでそれを修正できます。
以前のリリースのOracle Business Intelligenceでライトバック機能を構成していた場合、このリリースではライトバックを有効にする各論理列で明示的に「書込み可能」オプションを選択する必要があります。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』の列でのライトバックの有効化に関する項を参照してください。
静的リポジトリ変数は、定数値のデフォルトのイニシャライザを持ちます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のリポジトリ変数に関する項を参照してください。
Oracle BI管理ツールのマルチユーザー開発(MUD)環境により、ユーザーは次のようにリポジトリの変更に関する履歴情報を取得できます。
マージ前のサブセットの変更は、変更されたサブセット・リポジトリに保存されます。
MUDの場所の各バージョンは、repository_name.version_numberに保存されます。
Oracle BI 11gでは、リポジトリ・ファイルはユーザーが指定したリポジトリ・パスワードで暗号化されます。そのため、管理ツールは完全にアップグレードされ、暗号化されたリポジトリ・ファイルのみを開くことができます。
バージョン管理されたMUDリポジトリ・ファイルを管理ツールで開いてMUD履歴にアクセスできるようにするには、MUDディレクトリ内のすべてのリポジトリをアップグレードします。次のネーミング・パターン(dddはバージョン番号)を使用して、MUDディレクトリ内のすべてのリポジトリ・ファイルをアップグレードします。
repository_name.dddの変更されたサブセット
repository_name.ddd
注意: obieerpdmigrateutilコマンドライン・ツールを使用して、バージョニング済MUDリポジトリ・ファイルをアップグレードします。アップグレード・アシスタントを使用してバージョニング済MUDリポジトリ・ファイルをアップグレードしないでください。 また、obieerpdmigrateutilツールを使用して本番リポジトリ・ファイルをアップグレードしないでください。本番リポジトリはアップグレード・アシスタントを使用してアップグレードする必要があります。 |
MUD履歴にアクセスできるようにMUDリポジトリをアップグレードするには:
bi-init.cmd(UNIXの場合はbi-init.sh)を実行して、Oracleインスタンスに対して初期化されるコマンド・プロンプトまたはシェル・ウィンドウを起動します。このユーティリティは、次の場所にあります。
ORACLE_INSTANCE/bifoundation/OracleBIApplication/coreapplication/setup
起動したシェル・ウィンドウから、次のように適切なオプションを使用してobieerpdmigrateutilを実行します。
obieerpdmigrateutil -I input_repository_path -O output_repository_path -L ldif_output_path -U 10g_administrator_username
説明:
input_repository_path
は、アップグレードおよび暗号化するリポジトリの名前および場所です。
output_repository_path
は、リポジトリをアップグレードおよび暗号化する先の名前および場所です。この値は、入力リポジトリのパスと同じにすることができます。
ldif_output_path
は、ユーティリティで生成されるLDIF出力ファイルのパスです。これには、古いリポジトリからLDAPアイデンティティ・ストアにインポートするユーザーおよびグループが含まれます。
10g_administrator_username
は、以前のリリースのリポジトリの管理者ユーザー名です。
例:
obieerpdmigrateutil -I C:\mud_dir\my_repos.001 -O C:\upgr\my_repos.001 -L C:\upgr\ldif\my_ldif.ldif -U Administrator
入力を促されたら、10g管理者パスワードと新しいリポジトリの暗号化パスワードを入力します。リポジトリ・パスワードがないとリポジトリを開けないので、これを忘れないでください。エラーを回避するには、MUD環境ですべてのリポジトリ・ファイルに同一のリポジトリ・パスワードを使用します。
ヒント: 大量のMUDリポジトリがある場合、MUDリポジトリの移行タスクを自動化するスクリプトを作成することもできます。 |
Oracle BI 11gでは、環境変数に関して次の変更点があるので注意してください。
環境変数OBIS_Essbase_CustomGroup_Generation: Essbaseでカスタム・グループ構文の使用をカスタマイズするために以前のリリースで使用されていました。これは、PERF_CUSTOM_GROUP_GENERATION_MODEという新しいデータベース機能に置き換えられました。このデータベース機能は、Essbaseやその他の多次元ソースでのカスタム・グループ構文の生成方法に影響します。有効な値のセットは、環境変数と同じです(0~2)。
環境変数OBIS_Essbase_NonEmptyTuples_Generation.Database.Catalog.CubeTable: 大きな問合せセットで問題を解決するために以前のリリースで使用されていました。これは、PERF_PREFER_SUPPRESS_EMPTY_TUPLESという新しいデータベース機能に置き換えられました。このデータベース機能で、空のセル値を持つ空のタプルを削除するかどうかを制御します。このデータベース機能によって、最終結果セットでnullの抑制の動作が変更されることはありません。
Oracle BI EE 11gのOracle BIリポジトリ・メタデータに関して、次の機能を使用できます。
管理ツールとサード・パーティのソース・コントロール管理システムとの統合: MUD環境を使用するかわりに、リポジトリをMDS XML形式で保存して、管理ツールとサード・パーティのソース・コントロール管理システムを統合することもできます。
Oracle BIサマリー・アドバイザによる問合せ候補の特定: Oracle Exalytics MachineでOracle Business Intelligenceを実行している場合、Oracle BIサマリー・アドバイザ機能を使用して、問合せのパフォーマンスが向上する集計を特定できます。サマリー・アドバイザは、問合せパターンに基づいて集計表の最適なリストをインテリジェントにお薦めします。このリストを使用すると、特定のリソース制約を満たしながら、問合せのパフォーマンスが最大限に向上します。
返される行の制限およびオフセット機能: FETCH句を使用すると、SELECT文によって返される行数を制約でき、OFFSET句を使用すると、返された行を指定した数でオフセットできます。両方の句ともオプションで、組み合せて使用することも、単独で使用することもできます。
効率化されたMUDマージ・プロセス: マルチユーザー開発(MUD)環境を使用するリポジトリ開発者は、ローカルの変更内容のマージと変更内容の公開を2つの個別の手順として行うのではなく、変更内容のマージと公開を単一の手順で行えるようになりました。また、サブセットのリフレッシュを実行して、ローカルの増分をマスター・リポジトリにマージすることもできます。
自動化されたリポジトリのパッチ適用プロセス: patchrpdコマンドライン・ユーティリティで、ユーザーからの入力を必要とせずに、自動でパッチ適用を行えるオプションを使用できるようになりました。また、パッチのマージ中に、パッチ適用固有の新しいルールが適用されます。
クラスタ環境における集計の永続性のサポート: クラスタ環境で集計の永続性機能を使用できるようになりました。
Oracle BI EE 11g (11.1.1.5)では、次のOracle BIリポジトリ・メタデータに関する機能も使用できます。
Oracle OLAPデータソースへのアクセス: Oracle BI EEはデータソースとしてOracle OLAPをサポートするようになりました。
TimesTenデータソース: Oracle BI EEはデータソースとしてOracle TimesTen In-Memory Databaseをサポートするようになりました。
SAP/BWデータソース上のネイティブ接続: SAP BW Native接続オプションを使用して、BAPI上でSAP/BWデータソースに接続できるようになりました。
Oracle Business Intelligence Metadata Web Service: Oracle BI Metadata Web Serviceは、Oracle BI Serverストアド・プロシージャをコールするためのWebサービス・インタフェースを提供します。これらのストアド・プロシージャを使用して、メタデータに関する情報を取得してメタデータを変更します。
Oracle BI EE 11g (11.1.1.3)では、次のOracle BIリポジトリ・メタデータに関する機能も使用できます。
プレゼンテーション・レイヤーの階層オブジェクト: プレゼンテーション・レイヤーでプレゼンテーション階層およびプレゼンテーション・レベルを定義できるようになりました。これらのオブジェクトではOracle BI Answersで多次元モデルを公開する明示的な方法を提供し、ユーザーは階層ベースの問合せを作成できます。プレゼンテーション階層は、メンバーの選択、カスタム・メンバー・グループ、非対称型問合せなどの分析機能を公開します。
不規則階層およびスキップ・レベル階層のサポート: Oracle BI EEでは、不規則階層およびスキップ・レベル階層をサポートするようになりました。不規則階層とは、リーフ(子を持たないメンバー)が必ずしも同じ深さを持つ必要のない階層のことです。スキップ・レベル階層とは、特定の祖先レベルに値がないメンバーがある階層のことです。
親子階層のサポート: Oracle BI EEでは、親子階層をサポートするようになりました。親子階層(値階層とも呼ばれます)には、すべて同じタイプを持つメンバーが含まれます。たとえば、組織チャートには明確な親子階層がありますが、すべてのメンバーは従業員になります。
XMLパッチ・ファイルの生成および適用: リポジトリへの変更のみを含むXMLパッチ・ファイルを生成できるようになりました。そのパッチを古い(元の)バージョンのリポジトリに適用して新しいバージョンを作成できます。これは開発から本番への移行のシナリオに非常に有用で、Oracle BI Applicationsカスタマがリポジトリのアップグレードに使用することもできます。
また、Oracle BI Server XMLユーティリティを使用して、サポートされている任意のOracle BI Serverオペレーティング・システム上で、Oracle BIリポジトリ・メタデータの一般的なXMLベース表現を作成することもできます。
複数通貨のサポート: Oracle BI EEユーザーは、分析およびダッシュボードで通貨列に表示する通貨を選択できるように、論理列を構成できます。
Essbaseデータソース: Oracle BI EEはデータソースとしてEssbaseをサポートするようになりました。
Hyperion Financial Managementデータソースへのアクセス: Oracle BI EEはデータソースとしてHyperion Financial Managementをサポートするようになりました。
ADF Business Componentデータソースへのアクセス: Oracle BI EEはデータソースとしてADF Business Componentsの使用をサポートするようになりました。この機能により、ユーザーはADF Frameworkの最上位に構築される任意のアプリケーションに運用レポートを統合できます。
11gリポジトリ・メタデータで使用できるその他の新機能の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』の新しい機能に関する項を参照してください。
11gで作業をする前に、10g Oracle BI Presentation Catalogからファイルをアップグレードする必要があります。アップグレード・プロセス時に、アップグレード・アシスタントを使用して、カタログ・ファイルをアップグレードします。
ただし、アップグレード・アシスタントを実行する前に、特に注意する必要がある領域が多数あります。詳細は、第1.4.1項「Oracle BI Presentation Catalog: 主なアップグレードの考慮事項」を参照してください。
第1.4.1項で説明されている考慮事項のほかに、BI Presentation Catalogのアップグレードを計画する際に考慮する必要がある要素は多数あります。詳細は、第1.4.2項「Oracle BI Presentation Catalog: その他のアップグレードの考慮事項」を参照してください。
元の10gシステムからアップグレードされた11gシステムへの外観および動作の変更に加えて、アップグレードされたシステムで実装の検討が必要な、Oracle BI 11gに新しく導入された機能が多数あります。詳細は、第1.4.3項「Oracle BI Presentation Catalog: 11gの注目の新機能」を参照してください。
Oracle BI EE 11gでは、既存の機能を強化する多数の機能が導入されました。これらの機能向上によって、以前の機能が不要になる場合もあります。アップグレード時に、不要になった機能を含むレポートおよびダッシュボードは、新しい機能を使用するように意図的にアップグレードおよび改善されます。
10gのレポートおよびダッシュボードの外観および動作を11gで完全に再現しようとはせずに(そのような取組みは適切でなく、ほぼ不可能です)、新しい機能をどのように使用したら最適か検討することをお薦めします。
また、次の考慮事項に留意してください。
クラスタ環境でカタログに影響する多くの構成設定が変更されました。たとえば、以前のCatalogCacheTimeoutSecs要素は、CacheおよびCatalogAttributes要素の中のMaxAgeMinutes要素になりました。プレゼンテーション・サービスがクラスタ化されている場合、以前のクラスタの構成設定をすべて新しい設定に置き換える必要があります。
これらの設定の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』を参照してください。
多くのカタログ・オブジェクトは、アップグレード・プロセスの一部で発行されたすべての警告が修正され、カタログ検証レポートのエラーがなくなるまで、仕様どおりに動作しない場合があります。
たとえば、アップグレード・プロセスでは入力カタログがすべて正しいことを前提としており、未定義の動作があると不正な結果が生じます。この前提をもとに、アップグレード・プロセスですべてのオブジェクトが体系化され、最初のアップグレード・ログを使用して不正にアップグレードされたオブジェクトがあったかどうかを判断できます。この前提により、11gにアップグレードする前に10gの破損したオブジェクトを修正する必要がなくなります。
カタログを修正するには、検証レポートを生成し、オブジェクトを修正してから、アップグレードを実行するという手順を何回か繰り返す必要があります。ごく一部のオブジェクトは、手動の編集が必要になる場合もあります。
検証の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』を参照してください。
各ユーザーの独自のカタログ・コンテンツのローカライズされたテキスト(ダッシュボード名やグラフ・タイトルなど)は、表示されない場合があります。これは、以前の10gバージョンではText要素を使用していましたが、より最近の10gバージョンおよび11gバージョンではすべて大文字のTEXT要素を使用しているためです。Windowsシステムでは、次のコマンドを使用してこの問題を解決します。
runcat.cmd -localize -cleanup
UNIXシステムでは、runcat.sh
を使用します。このコマンドは次のディレクトリにあります。
ORACLE_INSTANCE\bifoundation
\OracleBIPresentationServicesComponent
\coreapplication_obipsn
\catalogmanager
-localize -cleanup
オプションの詳細を確認するには、Windowsシステムで次のコマンドを入力します。
runcat.cmd -localize -cleanup -help
サードパーティのftpプログラムを使用すると、ディスク上の一部の物理アイテム名が不正になる場合があります。アイテムの読取りの失敗に関するカタログ・エラーを見つけたり、WindowsシステムでFile Explorerなどのツールを使用していると、この問題が発見されることがあります。たとえば、正しくは「/system/privs/sa%2esales」というファイル名が「/system/privs/sa%252esales」となってしまう場合があります。ftpプログラムがエスケープ文字を「%」から「%25」に変更してしまっているのです。このftpプログラムを何回か使用すると、エラーが繰り返されてファイル名は「sa%2525252525252esales」のようになります。
不正なファイル名を修正するには、Windowsシステム上で次のコマンドを実行してからアップグレードを実行します(UNIXシステムでは、runcat.sh
を使用します)。ファイルによっては、手動で名前を変更する必要がある場合もあります。
runcat.cmd -cmd repair
repair
オプションの詳細を確認するには、Windowsシステムで次のコマンドを入力します。
runcat.cmd -cmd repair -help
カタログをアップグレードした後、11gで一部の分析が実行されずSQLエラーが発生する場合があります。
11gのOracle BI Serverでは、表名と列名の先頭または末尾に空白を入れることはできません。それらのカタログのオブジェクト名の先頭または末尾に空白が使用されている場合は、それをすべて取り除く必要があります。カタログ・マネージャのXML検索と置換機能またはsedなどのテキスト置換ツールを使用できます。
たとえば、分析で「 Product Sales .Unit Price 」に対するSQL問合せを実行する場合(「 Product Sales 」は表、「 Unit Price 」は列)、このSQLコードは「Product Sales.Unit Price」に変更する必要があります。
このような置換は、SQLおよびHTMLコードで表名および列名の処理に様々なエスケープ処理のルールがあるため煩雑になります。sqlExpressionノードでの分析では、XMLファイルの表現は次のようになります。
" " \" Product Sales \" " . " \" Unit Price \" " "
これは、次のように変更する必要があります。
""Product Sales"."Unit Price""
\"文字は、実際は名前の一部ではありませんが、別の引用レベルとして機能します。
11gの機能を最大限に使用するために、Webサーバーの構成を検討してください。Oracle BI Webクライアントのパフォーマンスを向上させるには、すべての静的ファイルを処理するWebサーバーを構成し、静的リソースも動的リソースも圧縮を有効化します。Webサーバー上でキャッシュおよびコンテンツの有効期限を有効にすると、Webブラウザでサーバーから静的ファイルをリロードする頻度を指定できます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle BI Webクライアントのパフォーマンスの向上に関する項を参照してください。
Oracle BI Presentation Catalogをアップグレードする際は、次の考慮事項に注意してください。詳細は、付録B「アップグレード後に予想されるOracle BI Enterprise Editionの外観と動作の変化」を参照してください。
アクションは次のようにアップグレードされます。
iBot定義の「詳細設定」タブで10g iBotにアタッチされたカスタム・スクリプト・アクションは、「サーバー・スクリプトの起動」アクションにアップグレードされます。
カスタムJavaプログラム・アクションは、Javaジョブの起動アクションにアップグレードされ、以前と同様に実行されます。ただし、これらのアクションは読取り専用です。サーバーで実行する新規カスタム・コードには、Javaメソッド(EJB)の起動アクションまたはWebサービスの起動アクションを使用します。
Siebel運用アプリケーションにリンクされたアクションは、「Siebel CRMにナビゲート」アクションにアップグレードされません。
Siebelワークフロー・アクションはアップグレードされません。以前のリリース(11gより前のリリース)でワークフローを起動していたアクションと同様の機能を実現するには、ワークフローをWebサービスとして公開し、Webサービスの起動アクションを作成することをお薦めします。
アクションの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』のアクションの使用に関する項を参照してください。
「詳細設定」タブで編集されたSQL文の分析をアップグレードした場合、階層列、選択またはグループを分析に追加できません。アップグレードされた分析にこれらの機能を含めようとすると、機能が使用できないことを示すメッセージが表示されます。
詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』の分析用の論理SQLの検証に関する項を参照してください。
以前のリリースでは、ピボット表に計算項目を作成すると、その計算項目は、その分析のそのピボット表にのみ適用されました。11gにアップグレードすると、すべての計算項目が選択ステップに自動的に変換され、分析のすべてのビューに適用されます。
たとえば、以前のリリース(11gより前)で分析を作成し、その基準にProducts列と3つのビュー(1つのグラフと2つのピボット表)が含まれているとします。1つ目のピボット表はpivotTable1という名前で、Products列にcalcItem1という計算項目があるとします。2つ目のピボット表はpivotTable2という名前で、Products列にcalcItem2という計算項目があるとします。11gにアップグレードした後、計算項目は選択手順に変換されるので、これらの3つのビューには、これらの計算項目が両方とも含まれます。
計算項目の表示が以前のリリースと正確に一致する必要がある場合、手動で対処方法を実装する必要があります。11gの分析では、同じ列の複数の計算項目を削減できるか確認します。たとえば、前の例を使用すると、calcItem1とcalcItem2を組み合せて、選択手順のリストから1つの手順を削除できるか確認します。
次に、計算項目をビューから削除する必要がある場合、計算項目が定義される基準列を再度「基準」タブに追加する必要があります。ビューのその列の新しいインスタンスを使用して、元のインスタンスを除外します。前の例では、グラフ・ビューでProducts列を使用し、ビューにcalcItem1もcalcItem2も含められない場合、「サブジェクト・エリア」ペインから「基準」タブの選択された列に「Products」を再度追加します。グラフ・ビューを編集して、ビューの「Products」列の2番目のインスタンスを含め、元のProducts列は除外します。
この分析で追加された元のProducts列の任意の列プロパティは、Products列の新しいインスタンスに適用しなおす必要があります。
10gでは、内部属性を設定してダッシュボードを非表示にします。11gでは、ダッシュボード・フォルダをその上位レベルのフォルダ内で非表示フォルダにすることでダッシュボードを非表示にします。カタログのアップグレード時および移行時には、非表示のダッシュボードを含む子フォルダに「非表示」属性が適用されています。
iBotsをアップグレードする際は、次の点に注意してください。
以前のリリース(11gより前のリリース)では、ただちに起動するよう設定されたiBot(現在のエージェント)を作成できました。この設定のiBotをアップグレードすると、スケジュール設定が現在のリリースにインポートされません。他のすべてのエージェントのスケジュール設定はインポートされます。
ただちに起動するよう設定されたiBotをアップグレードする場合、「エージェント」エディタの「スケジュール」タブの「頻度」設定は「なし」になります。「すぐに開始」スケジュールからの実際の開始時間は必ず過去になるため、無効になります。
以前のリリース(11gより前のリリース)では、「自分」オプションを選択すると、iBotの所有者としてコンテンツを配信するiBotを作成できました。「自分」オプションが選択されたiBotをアップグレードすると、11gでは、エージェントの所有者は次のいずれかになります。
エージェントが公開される場合は、登録者。
エージェントが公開されない場合は、受信者。
以前のリリース(11gより前のリリース)では、リクエストの結果(現在の分析)に基づいた条件下でトリガーされるiBotを作成できました。
このリリースでは、条件付きでトリガーされるエージェントを作成するには、条件を使用します。使用時に定義し、Oracle BI Presentation Catalogに保存しないインライン条件を使用することも、カタログに名前を付けて保存した名前付き条件を使用することもできます。条件の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』の条件の使用に関する項を参照してください。
以前のリリース(11gより前のリリース)で条件付きでトリガーされたiBotは、デフォルト名のAgentCondition1とインライン条件を使用するようアップグレードされます。このインライン条件では、選択されたリクエストによって返される行の数が0より大きいかどうかが評価されます。(これらの条件をエージェント内から編集したり、ベースになっている分析の場所を確認したり、カタログ内の任意の場所に保存できることに注意してください。)
以前のリリース(11gより前のリリース)では、特定のiBotが完了したらカスタムJavaプログラム・アクションを実行するように指定できました。このリリースでは、カスタムJavaプログラム・アクションは、Javaジョブの起動アクションにアップグレードされ、以前と同様に実行されます。ただし、これらのアクションは読取り専用です。サーバーで実行する新規カスタム・コードには、Javaメソッド(EJB)の起動アクションまたはWebサービスの起動アクションを使用します。
ピボット表をアップグレードする際は、次の点に注意してください。
10gでは、デフォルトでは、ピボット表のすべての行が表示されていました。11gでは、必要に応じて表ビューでデータをページごとに表示できます。デフォルトでは、最初の25行が表示されます。ピボット表エディタで「グラフのピボット結果」をクリックすると、ピボット表に現在表示されている内容を表示するのみがグラフに表示されます。ピボット表にはセクションごとのグラフが表示されます。ユーザーはテープ・デッキ・コントロールを使用してグラフをページごとに表示できます。
ピボット表のデフォルトの表示行数は、instanceconfig.xmlファイルのDefaultRowsDisplayed設定を使用して変更できます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者』の第18章を参照してください。
ピボット・ページ・プロンプトでは、列を1つのドロップダウン・リストに組み込みません。そのかわり、各列に独自のドロップダウン・リストがあります。
ピボット表には、行見出しラベルの列ヘッダーに追加の行があります。行または列に列がない場合、追加の列領域または行領域もあります。
10gでは、メジャー・データを何も持たない行も表示されます。11gでは、このような空白行は表示されません。そのため、ピボット表の行が消失する可能性があります。
ビューでの相互作用のアップグレード時には、次のことに注意してください。
以前のリリース(11gより前のリリース)では、チャートやゲージの相互作用をビュー・レベルで作成でき、基準レベルで設定された相互作用をオーバーライドできました。このリリースでは、左クリック相互作用を基準レベルで作成します。以前のリリース(11gより前のリリース)からアップグレードする場合、すべての左クリック相互作用は基準レベルのメジャーに移動され、すべてのビューで有効になります。
10gのチャートでチャートの相互作用が定義されている場合、基準列がさらに追加される場合があります。列が繰り返し表示されることがあります。チャートの相互作用は、「基準」タブに含まれている列の「列のプロパティ」ダイアログの「相互作用」タブに移行されます。他のビューへの影響を回避するために、アップグレード・プロセスによって、チャート・レベルの相互作用を含む各チャートの基準に新しい列が追加されます。
たとえば、基準が、地域、地区、売上金額および売上数量として定義された分析を以前のリリース(11gより前のリリース)で作成したとします。また、チャート・ビューに相互作用を作成してあります。このリリース用に相互作用をアップグレードするために、追加の売上金額と売上数量列が基準レベルで追加され、相互作用は、基準レベルでこれら追加された売上金額と売上数量の両方に移動されます。
11gでは、複数のリンクへのナビゲーションをサポートする分析にポップアップ・メニューが表示されることがあります。リンクが1つしかない場合は、「列のプロパティ」ダイアログの「相互作用」タブでこのメニューをオフに設定できます。
11gでは、分析エディタ: 「基準」タブに追加された条件付き書式は表とピボット表ビューの両方に適用されます。10gでは、別の列に基づく条件付き書式は表ビューのみに適用されていました。
たとえば、Product列とSales列の両方を使用する分析を作成したとします。Productに条件付き書式を設定して、Salesがある値より大きいProductに書式を指定した場合、条件が満たされると、Product列を含む表ビューおよびProductを含むピボット・ビューにこの書式が適用されます。
属性列の条件付き書式は、表ビューに表示される10gの条件付き書式と一致するために、列プロパティの編集ダイアログ: 「列書式」タブで列の「値の抑制」オプションを「繰返し」に設定する必要がある場合があります。これは、列が表ビューで使用され、条件付き書式がメジャーに基づいて設定されている場合にのみ適用されます。基準の列の「値の抑制」オプションを変更すると、この列を使用する分析でその他の表またはピボット・ビューのレイアウトに影響する場合があります。
条件付き書式の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』の条件付き書式の表およびピボット表への適用に関する項を参照してください。
以前のリリース(11gより前のリリース)では、メジャー列は属性列として容易に処理できたため、ビューのエッジ間を自由に移動できました。
11gでは、メジャー列がエッジに移動したときに詳細をすべて表示せずに、メジャー列をエッジのマス目に集計する機能が導入されました。
アップグレード時には、すべてのメジャー列に「列式の編集」ダイアログ: 「列式」タブで選択された「属性列として処理」ボックスがあります。これによって、ピボット表のエッジまたはグラフの「グループ化」に移動したメジャーを含むレポートをアップグレードしても、10gと同様に機能します。新しい11gの分析には、「属性列として処理」オプションがあります(メジャーはデフォルトではfalseに設定されます)。
以前のリリース(11gより前のリリース)には、表やピボット表のビューでレポートを基準にした合計を作成する機能がありました。レポートを基準にした合計の扱いが、このリリースでは多少異なるため、合計に関する次のような違いに注意してください。
以前の表に、レポートを基準にした合計がすべて含まれていた場合、アップグレードされた表内のすべてのメジャー列と属性列では、レポートを基準にした合計オプションとともに「デフォルト」オプションが使用されます。
以前の表ビューに、レポートを基準にした合計とレポートを基準にしていない合計が含まれていた場合、アップグレードされた表内のすべてのメジャー列と属性列では、レポートを基準にした合計オプションとともに「デフォルト」オプションが使用されます。
アップグレードされた合計に手動で対処することができます。以前のリリース(11gより前のリリース)と同じメジャー列を使用する場合、表内のメジャー列を複製し、「集計ルール」メニューを使用して、レポートを基準にしていない合計を指定します。
以前の表ビューに、レポートを基準にしていない合計がすべて含まれていた場合、アップグレードされた表内のすべてのメジャー列と属性列で、レポートを基準にしていない合計が引き続き使用されます。
ソートをアップグレードする際は、次の点に注意してください。
以前のリリース(11gより前のリリース)では、「基準」タブの列に追加されたソートはすべてのビューに適用されていました。以前のリリース(11gより前のリリース)からアップグレードする場合、表、ピボット表またはグラフ・ビューで異なるソートが適用されていることに気付くことがあります。アップグレードされたレポートでは、基準列で指定されたソートが維持されます。ただし、11gでは、基準列で指定されたソートは、ビューにその列が含まれている場合にのみそのビューに適用されます。
引き続きビューにない列でソートする場合、列を非表示列として含めることで10gの動作を再現できます。
列を非表示列として含めるには:
「結果」タブで目的のビューの「ビューの編集」ボタンをクリックします。
「レイアウト」ペインの目的の列で「詳細オプション」ボタンをクリックして「非表示」を選択します。
11gのグラフも、ソートをエミュレートするユーザー・インタフェース要素を備えていません。引き続きグラフ・ビューにないメジャー列に基づいてグラフをソートする場合は、次の回避策を使用してください。
追加メジャーを外部グループとしてグラフの「グループ化」ドロップ・ターゲット領域に加えてください。
「列式の編集」ダイアログの「列式」タブで、「属性列として処理」オプションを選択する必要があることに注意してください。(アップグレード時、このオプションはデフォルトで選択されます。)
「列のプロパティ」ダイアログの「列書式」タブの「非表示」オプションを使用する分析では、追加メジャーを非表示にしてください。
以前のリリース(11gより前のリリース)で、「基準」タブのメジャー列でソートが指定されている場合、分析をアップグレードしても、そのソートは同じメジャー列を使用するピボット表またはグラフに適用されません。
ピボット表は、デフォルトでは常に外側のレイヤーから内側のレイヤーに各エッジがソートされます。これは、以前のリリース(11gより前のリリース)の動作と異なります。以前のリリースでは、ピボット表のデフォルトのソートとして、基準列で指定されたソートによって決定される表ソートが使用されていました。
プロンプトをアップグレードする際は、次の点に注意してください。
プロンプトをアップグレードする場合、その外観および動作が元の10gシステムのものと正確に一致しないことがあります。10gの外観を再現しようとすると大量の労力を要し、手動で更新すると、11gに導入された拡張機能を利用できなくなる場合があります。アップグレードされたプロンプトは以前のリリースと同様に機能しますが、表示が多少異なる場合があります。たとえば、複数のプロンプトが含まれる2つの積上げ行を持つダッシュボードがある場合、アップグレードされたプロンプトは、それぞれのプロンプトの幅が120ピクセルに増加されるため、配置が異なります。
以前のリリース(11gより前のリリース)では、プロンプト・フィールドの幅や、プロンプト・ページでプロンプト・ラベルをラップするかどうかを指定することはできませんでした。以前のリリースからプロンプトをアップグレードする場合、次の点に注意してください。
「新規プロンプト」ダイアログでは、「選択リストの幅」フィールドは、instanceconfig.xmlファイルのDefaultPromptWidth要素で指定されたデフォルトの幅(ピクセル値)に設定されます(デフォルトでは、120ピクセル)。
「ページ設定の編集」では、次のようになります。
「ラベルをラップして合せる」オプションは選択されません。
「すべてのプロンプトの幅を次に設定」フィールドは、instanceconfig.xmlファイルのDefaultPromptWidth要素で指定されたデフォルトの幅(ピクセル値)に設定されます(デフォルトでは、120ピクセル)。
10gでは、ダミー列に対してダッシュボード・プロンプトを使用して変数を設定できました。ダミー列のデータ型は、それを入力するSQL文の値のデータ型と異なる場合がありました。それでも、10g変数はすべて文字列であったため、機能していました。
11gにアップグレードしたら、プロンプトに使用したダミー列はSQL戻り値と同じデータ型を持つ必要があります。同じでないと、実行時にデータ型検証エラーが発生します。
アップデート・プロセス時は、SQL文を実行してデータ型が判断されることはないので、エラーは発生しません。この問題が顕在化するのは、11gでプロンプトが実行された場合のみです。必ず実行前に変数の設定に使用された任意のダミー列・プロンプトのデータ型が一致していることを検証してください。
11gでは、新しい変数プロンプト・タイプを使用して変数を作成および設定することをお薦めします。これを使用することで、ダミー列を使用する必要がなくなり、それに伴うデータ型の不整合も解消されます。
以前のリリース(11gより前のリリース)でローカルに保存され、fmap関数を使用して参照されていたカスタム・ファイル(イメージ・ファイルやヘルプ・ファイルなど)は、11gで次のディレクトリに手動でコピーする必要があります。
ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent /coreapplication_obipsn/analyticsRes
Oracle BI 11gでアーキテクチャおよびユーザー・インタフェースの要素に大きな変更があったため、以前のスキンおよびスタイルから11gインスタンスへの移行には新しい取組みが必要です。カスタム・スタイルおよびスキンはアップグレードされません。10gでカスタム・スタイルおよびスキンを使用していた場合、11gでそれらを手動で再作成する必要があります。
XMLテンプレート・カスタマイズを使用したカスタマイズのタイプは、10gでは可能だったが11gでは使用できなくなるものがあるので注意してください。
表1-2に、チャートが11gのグラフにアップグレードされる際の相違点を示します。
表1-2 チャートが11gのグラフにアップグレードされる際の相違点
変化 | 説明 |
---|---|
軸ラベルの範囲の変化 |
10gと11gでは、自動軸範囲計算エンジンの違いから、グラフの数字軸ラベルの範囲が異なります。 |
棒グラフ・サービス・ダッシュボードのデータの相違 |
11gでは、データの書式が拡張され、doubleデータ型とintegerデータ型の違いが示されるようになりました。この問題は、10gではintegerデータ型で11gではdoubleデータ型になった列のデフォルトの書式をオーバーライドすることによって、手動で解決できます。 |
11gでの軸値の相違 |
10gでは、列に対する基準レベルの書式や他のグローバルなデータ書式が守られないことがあります。データ・ラベルおよび数値軸ラベルがこのような書式設定に従わないことがあります。この問題は、11gで解決されました。 |
グラフでのドリルダウンで異なる結果が表示されることがある |
アップグレード中、10gの既存の相互作用はメジャーに配置され、軸と凡例では利用不能になります。アクションを起動するには、軸ラベルまたは凡例ではなく、グラフのメジャーをクリックする必要があります。軸または凡例に配置された列にアクション・リンクを直接追加するには、基準内でその列にアクション・リンクを追加します。それにより、追加したアクション・リンクが軸ラベルまたは凡例で表示されるようになります。 |
グラフ・エンジンが応答しない |
11gでは、JavaHostからプレゼンテーション・サービスに送られるグラフ・データのデフォルト値は4MBです。グラフのサイズが大きい場合、グラフ・エンジンが応答していないことを通知するメッセージが表示されることがあります。この問題を回避するには、instanceconfig.xmlファイルでグラフのデータ・サイズを大きくします。次の例は、グラフのデータ・サイズを6MBに増やす方法を示しています。構成ファイルの編集の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』を参照してください。 <Views> <Charts> <JavaHostReadLimitInKB>6144</JavaHostReadLimitInKB> </Charts> </Views> |
グラフのラベルがなくなることがある |
11gで使用されているラベルの自動レイアウト・アルゴリズムの影響で、一部の軸ラベル(数値軸とカテゴリ軸の両方)がスキップされることがあります。 |
Y軸のグラフのラベルを回転できない |
Y軸のグラフのラベルについては、0から90度または-90度の回転のみ可能です。45度の回転は実行できません。 |
面グラフのグリッド線の動作 |
11gの面グラフでは、面マーカーの上にグリッド線が描画されます。つまり、描画された面の上にグリッド線が表示されます。10gでは、グリッド線は面マーカーの上には描画されません。 |
折れ線グラフが積み上げられる |
10gの積上げ折れ線グラフでは、同じ軸に複数のメジャーが折れ線として表示され、積上げは行われませんが、11gでは積上げが行われます。 |
折れ線としてレンダリングされていた一部のメジャーが棒としてレンダリングされる |
10gの線-棒グラフでは、一部のメジャーがランダムに選択され、棒ではなく折れ線として表示されます。11gでは、メジャーの描画は分析のグラフ定義に依存し、その描画方法が考慮されます。棒として表示するように定義されているメジャーは、棒として表示されます。 |
グラフでの不明列の消失 |
10gでは、現在レイアウトに存在する列でグラフ定義が未完了になっているものは、それぞれ不明列としてグラフに追加されます。11gではこの動作が修正されたため、グラフから列が消失することがあります。追加の列がレイアウトに含まれることはなくなり、かわりにメッセージ・ボックスが表示されます。10gから11gへのアップグレード時、このような不明列は、無効、つまり分析の問合せまたは基準のXMLファイルに存在しないとみなされ、分析から削除されます。 |
10gで単一円グラフだったものが11gで複数円グラフになる |
Oracle BI EE 10gでは複数円グラフはサポートしていませんが、11gではすべての列に対して円グラフをサポートしています。この拡張の影響で、アップグレード後に複数の円グラフが表示されるようになる場合があります。 |
グラフでのナビゲーションの変更 |
11gでは、グラフのナビゲーションが変わりました。10gで軸ラベルまたは凡例にナビゲーションを設定していた場合、そのナビゲーションは基準レベルに移動するため、利用できなくなります。 |
円グラフの負の値がレンダリングされない |
10gの円グラフでは、負の値も含めて絶対値が表示されます。負の値は正の値として解釈され、それに対応する区分が表示されます。11gでは、負の値に対応する区分は表示されません。すべての値が負の場合、グラフ自体が表示されません。11gでは、凡例は負の値に対しても表示されます。 |
円グラフにミニ円グラフ付きの凡例が表示される |
凡例でグラフを使用することを選択した場合に、グラフのサイズが縮小されあまりに小さくなると、10gではグラフ全体が表示されません。それに対し11gのエンジンは最小スペースでグラフを表示しようとします。レイアウト・アルゴリズムによって、使用できる最大領域のグラフへの割当てが試みられます。凡例に含まれる項目数が多すぎる場合は、グラフに割り当てられた領域を侵さないようにスクロール・バーが追加されます。 |
右側のスケールがグラフから消失することがある |
11gのグラフ・エンジンは、線-棒グラフのY2軸を折れ線にマップします。そのため、軸が同期化されていなくても、折れ線のデータがないため、Y2軸は表示されません。 |
11gでの凡例とグラフの不一致の可能性 |
10gの積上げ棒グラフを11gにアップグレードすると、系列の順序または位置が変わる場合があります。しかし、凡例ビューは何の変更もなくアップグレードされます。その結果、凡例ビューに表示される凡例と、グラフに表示される色の不一致が発生する可能性があります。この問題を解決するには、グラフの色を変更するか、またはグラフの色に合うように凡例を更新します。 また、「色変更方法」で列を追加すると、棒グラフの積上げ順序が変わります。その他のケースでは、順序と色は維持されます。「色変更方法」で列に対して条件付き書式設定を指定すると、凡例が正しくないものになったり、一致しなくなります。 |
パレート・グラフの動作が異なる |
このリリースのパレート・グラフでは、縦軸2の範囲は0%から100%までです。したがって、スケールとデータ・ラベルに使用される略記は変更できません(たとえば、Million(m)に変更できません)。データ・ラベルが現在表示されているデフォルトの数値書式をオーバーライドすることもできません。 |
散布図の動作が異なる |
このリリースの散布図では、以前のリリース(11gより前のリリース)と異なり、グループ化軸に1つ以上の属性列は必要ありません。 |
積上げ縦棒グラフおよび積上げ横棒グラフの積上げ順序が異なる |
このリリースの積上げ縦棒グラフおよび積上げ横棒グラフでは、積上げ順序が以前のリリース(11gより前のリリース)の順序と逆です。 |
対数スケールの動作が異なる |
このリリースでは、対数スケールは次のように動作します。
以前のリリース(11gより前のリリース)では、対数スケールは次のように動作しました。
|
アップグレード時、-ibotsという名前の非表示のフォルダはAgentsという名前に変更され、非表示でなくなります。My FoldersフォルダとShared Foldersフォルダに格納されます。
以前のリリース(11gより前のリリース)では、ゲージを使用したユーザー・インタフェースで範囲の最大値と最小値を入力していました。不連続の範囲も指定できました(たとえば、Range1: 0-200、Range2: 400-500、Range3: 200-400など)。
Oracle BI EE 11gでは、ゲージの範囲は連続になります(たとえば、Range1: 1-200、Range2: 200-400、Range3: 400-500など)。ゲージの範囲ダイアログでは、範囲を計算するしきい値のみを指定できます。しきい値を入力した結果、ゲージの範囲が不正になると、ゲージはレンダリングされず、エラー・メッセージが表示されます。
Oracle BI EE 11gは、図1-4に示すように、しきい値に基づいています。アップグレード時に、それぞれの範囲で指定された「低」/「最小」値が考慮され、範囲のアップグレードを試行して可能なかぎり連続にしようとします。範囲を正しくアップグレードできない場合、アップグレードが終了した後、範囲を修正する必要があります。
次のシナリオでは、アップグレードされたゲージのレンダリングについて説明します。
範囲が昇順に指定されないが連続な場合(重複やネストもなし)
Oracle BI EE 10gでの範囲を表1-3に示します。
表1-3 昇順に指定されないゲージの範囲(10g)
Range1 |
最小 = 0 |
最大 = 200 (赤) |
Range2 |
最小 = 400 |
最大 = 500 (緑) |
Range3 |
最小 = 200 |
最大 = 400 (黄) |
アップグレードされた11gのグラフを表1-4に示します。
表1-4 昇順に指定されないゲージの範囲(11g)
Range1 |
最小 = 0 |
最大 = 200 (赤) |
Range2 |
最小 = 200 |
最大 = 400 (黄) |
Range3 |
最小 = 400 |
最大 = 500 (緑) |
範囲は、論理的に正しければ、その最小値に基づいて決定されます。
アップグレードされた11gのゲージは、レンダリングされると10gのゲージと同じになります。
範囲の最小値または最大値が指定されない場合、ゲージは次のように10gのゲージに基づいて設定されます。最終的に得られた範囲が連続で有効であれば、アップグレードされたゲージはレンダリングされます。
範囲が結び付いていない場合、表1-9を参照してください。
表1-9 結付きのないゲージの範囲(10g)
Range1 |
最小 = 0 |
最大 = 100 (赤) |
Range2 |
最小 = 200 |
最大 = 300 (黄) |
Range3 |
最小 = 400 |
最大 = 500 (緑) |
アップグレードされたゲージは、指定された「最小」/「低」の値に基づいてレンダリングされます。
アップグレードされたゲージの範囲については、表1-10を参照してください。
指定された範囲に重複がある場合、表1-11を参照してください。
表1-12に示すように、アップグレードされた範囲は10gのゲージと同じにならない場合があります。
指定された範囲がネストされている場合、表1-13を参照してください。
表1-14に示すように、アップグレードされた範囲は10gのゲージと同じにならない場合があります。
最小値が最大値より大きい値に指定されている場合、表1-15を参照してください。
表1-16に示すように、アップグレードされた範囲は10gのゲージと同じにならない場合があります。
Oracle BI EE 11gのカタログに関して、次の機能を使用できます。
階層列: リリース11gでは階層列が導入されました。この列のタイプには、名前付きレベルおよび親子関係の両方を使用して編成されたデータ値を保持します。この列は、ツリー状の構造を使用して表示されます。個々のメンバーは概要が表示されます。階層では、データをより深くドリルダウンして分析すると、より詳細な情報を表示できます。
選択ステップ: 「選択ステップ」を作成して分析の列を連携できます。これらのステップは、分析の各ビューに横断的に実行され、分析の列のメンバー内で直感的で強力なグループ化、計算および選択が可能になります。列の値を含む計算は、分析時に容易に展開でき、カタログに単一の要素として保存できます。これらの保存された計算または選択は、カタログの分析間で即座に再利用できます。
カタログ・オブジェクト: 選択ステップ、条件およびアクションをカタログ・オブジェクトとして保存できるようになりました。これらはカタログ・オブジェクトとして保存することで、複数の分析の間で使用できます。
複数のサブジェクト・エリア: 複数のサブジェクト・エリアからの列を含む分析を作成できます。
計算関数: 分析内の中で新しい関数を使用できます。たとえば、リポジトリに設定されたメトリック集計ルールに従って、分析の特定のレベルで任意のメトリックを集計する集計対象関数を使用できます。また、動的時系列関数を使用すると、時間レベルを指定せずに時系列データを取得できます。
ズームおよびスライダ: グラフィックが強化され、インタラクティブなズームが導入されました。「セクション・スライダ」を使用すると、1つ以上の属性列または階層列のメンバーを長方形の棒上の値として表示し、値を選択するメカニズムを活用できます。セクション・スライダを使用して、グラフまたはゲージに表示されるデータを限定します。
Oracle BI Presentation Catalogの11gバージョンで使用できるその他の新機能の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』の新機能に関する項を参照してください。
BI Publisherをアップグレードするには、2つの手順でアップグレード・アシスタントを実行します。BI Publisherリポジトリを1回アップグレードして、BI Publisherのスケジューラ・スキーマを1回アップグレードします。この項では、これらの2つのプロセスの概要について説明します。
BI Publisherリポジトリのアップグレード(レポートおよび構成ファイル)
BI Publisherリポジトリをアップグレードする場合、10gのレポートはアップグレードされて11gのリポジトリに配置されます。11gでのレポート定義の最も大きな変更はデータ・モデルがカタログの個別のオブジェクトとして独立したことです。10gから11gにアップグレードすると、10gのレポート・オブジェクトはレポート定義ファイル(.xdo)とデータ・モデル・ファイル(.xdm)に分割されます。分割されたオブジェクトを図1-5に示します。
すべてのユーザーおよびロール、データソース定義、配信サーバー構成、システム・プロパティ設定などを含む管理ファイルは、11gインストールの新しい場所にコピーされ、リポジトリをアップグレードするときにすべての構成設定が保持されます。図1-6では、管理ファイルのアップグレードについて説明しています。
スケジューラ・スキーマのアップグレード
アップグレード・アシスタントでは、10gのスケジュール・ジョブおよびジョブ履歴を、リポジトリ作成ユーティリティで作成された新しい11gのスケジューラ・スキーマにコピーします。図1-7では、スケジューラ・スキーマのアップグレードについて説明しています。
アップグレード・アシスタントを実行する前に、特に注意する必要がある領域が多数あります。詳細は、第1.5.1項「BI Publisher: 主なアップグレードの考慮事項」を参照してください。
BI Publisherのアップグレードを計画する際に考慮する必要がある要素は前述のもの以外にも多数あります。詳細は、第1.5.2項「Oracle BI Publisher: その他のアップグレードの考慮事項」を参照してください。
元の10gシステムからアップグレードされた11gシステムへの外観および動作の変更に加えて、アップグレードされたシステムで実装の検討が必要な、Oracle Publisher 11gに新しく導入された機能が多数あります。詳細は、第1.5.3項「Oracle BI Publisher: 11gの注目の新機能」を参照してください。
次の項では、主なアップグレードの考慮事項について説明します。
Oracle Business Intelligence 10gと11gの機能的な違いは、Oracle WebLogic Serverにデプロイすることと、Oracle Business IntelligenceをOracle Fusion Middlewareに統合することです。詳細は、第4.1項「Oracle Business Intelligence 11gとOracle WebLogic Server」を参照してください。
BI Publisherのスタンドアロン・インストールをアップグレードする場合、アップグレード後もセキュリティ・モデルは変更されません。10gからのセキュリティ・モデルを保持できます。ただし、11gでは、Oracle Fusion Middleware Securityを実装することをお薦めします。このセキュリティ・モデルでは、Oracle WebLogic管理コンソールからユーザーおよびロールを管理します。セキュリティ・モデルの実装の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Publisher管理者ガイドのOracle Fusion Middlewareのセキュリティ・モデルの構成に関する項を参照してください。
BI PublisherをOracle BI EEに統合する場合、ユーザーおよびグループは10gのリポジトリ・ファイルからデフォルトの11gのアイデンティティ・ストア(Oracle WebLogic Serverが組み込まれたLDAPサーバー)に移行されます。10gのセキュリティ・モデルがBI Serverであった場合、アップグレード・アシスタントによりBI Serverは11gのセキュリティ・モデルとして保持されます。ただし、Oracle BI EEをOracle Fusion Middlewareのセキュリティ・モデルに移行する必要がある場合は、BI Publisher Administrationインタフェースのセキュリティ・モデルは、Oracle Fusion Middleware Securityにアップグレードする必要があります。詳細は、第1.6項「Oracle Business Intelligenceセキュリティのアップグレードについて」を参照してください。
注意: BI Serverのセキュリティを引き続き使用する場合、11gで導入された共有のユーザー・インタフェース機能は、10gの初期化ブロックベースのセキュリティ・モデルには連携されません。 |
BI PublisherとOracle BI EEの統合されたバージョンでは、11gのカタログは完全にプレゼンテーション・サービスと共有されます。そのためには、BI PublisherカタログからPresentation Servicesカタログにアップロードする必須のアップグレード手順を一度だけ実行する必要があります。引き続きBI Publisherアプリケーションにも独立でアクセスすることはできますが、共有のインタフェースによりBusiness Intelligenceの機能が完全に統合されます。このアップグレード後の手順の詳細は、第8.2項「BI Publisherのアップグレード後のタスクと考慮事項」を参照してください。
11gでは、次のオブジェクトをカタログに独立に配置できます。
レポート
データ・モデル
サブ・テンプレート
スタイル・テンプレート(11gの新しいコンポーネント)
10gでは、データ・モデルはレポートに埋め込まれていました。11gでは、データ・モデルは独立のオブジェクトになり、複数のレポートで再利用できます。図1-8に、11gでのレポートとデータ・モデル・オブジェクトとの関係を示します。
次の点に注意してください。
単一のデータ・モデルは、複数のレポートで使用することはできません。
データ・モデルからのパラメータはレポート・レベルでカスタマイズできます。
データ・モデルに複数のバースト定義を作成してからレポート・レベルで選択できます。
10gでは、サブ・テンプレートはBI Publisherリポジトリの外側に配置されていました。11gでは、サブ・テンプレートはカタログ内のオブジェクトとして保持されます。詳細は、第1.5.3.8項「カタログのサブ・テンプレートの管理」を参照してください。
スタイル・テンプレートは11gで導入された特別なテンプレートであり、スタイルシートと同様に複数のレポートでのスタイルの管理が簡略化されます。詳細は、第1.5.3.7項「スタイル・テンプレートを使用した一貫性ルック・アンド・フィール」を参照してください。
10gでは、カタログ・オブジェクトへのアクセス権の付与は「管理」のロールと権限ページで実行されていました。レポートを実行するユーザー・ロール・アクセス権を付与するには、管理者がロールと権限ページでレポートが存在するフォルダをロールにマップします。そのロールを持つユーザーはすべてそのフォルダの任意のレポートを表示する権限があります。
11gでは、権限の付与は権限タスクを使用してカタログ内で実行されます。新しい一連の権限は、ユーザーができることをより詳細に定義できるようになりました。次のような権限があります。
読取り
書込み
削除
オンラインでのレポートの実行
レポートのスケジュール
レポート出力の表示
レポート・カスタマがレポートを正常に実行するためには、レポートが参照するすべてのオブジェクトに対してそのユーザーに読取り権限を付与する必要があります。たとえば、10gでは、従業員給与レポートを実行するためにユーザーに必要なのは、そのレポートが存在するフォルダへのアクセス権のみでした。11gでは、データ・モデルは独立のオブジェクトになったため、ユーザーはそのデータ・モデル・オブジェクトの読取り権限も必要になります。レポートで参照するオブジェクトが追加された場合(スタイル・テンプレートやサブ・テンプレートなど)、それらのオブジェクトの読取り権限も付与する必要があります。
また、11gでは、データソースにアクセスする必要があるすべてのロールは、レポートを表示するだけであっても、そのデータソースへのアクセス権を付与する必要があります。そのためには、BI Publisher管理ページでデータソースにロールを割り当てる必要があります。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Publisher管理者ガイドのデータ・アクセス権の付与に関する項を参照してください。
次の項では、その他のアップグレードの考慮事項について説明します。
リリース11gでは、次のカタログ・タイプがサポートされます。
Oracle BI Publisher: ファイル・システム。スタンドアロン実装用
Oracle BI Presentation Catalog。統合実装用
10gのオプションのXML DBリポジトリ・タイプは、11gのオプションではありません。
10gの実装にデータソースとしてDiscovererワークブックを使用するレポートが含まれている場合、それらのレポートは11gでは実行できません。引き続きレポートのDiscovererデータを使用するためには、BI PublisherでSQL文を直接発行してデータを取得できるように、DiscovererワークブックからSQL問合せを手動でコピーしてBI Publisherに新しいデータ・モデルを作成します。
次の一覧は、レポートの互換性についてまとめたものです。
10gからレポートをダウンロードして、それを単純に新しい11g環境にアップロードして実行することはできません。10gのレポートはすべて最初にアップグレード・アシスタントでアップグレードする必要があります。
11gからレポートをダウンロードして、それを単純に10g環境にアップロードして実行することはできません。下位互換性はありません。
10gで作成されたテンプレートを11gで作成するレポートで使用することはできません。
Template Builderを下位互換モードで実行する場合、BI Publisher Template Builder for Word 11gを使用して10gのレポートを設計できます。下位互換モードは、Template Builderの「オプション」ダイアログから設定できます。
10gのレポート・データ・モデルでデータソース・タイプとしてSQL問合せまたはBI Answersを使用している場合、アップグレード後はデータセットにデータ・モデル・エディタの列情報が表示されなくなります。これは、10gのデータセット・タイプが新しい11gデータ・モデルの列への移入に必要な情報を取得できないために発生します。このデータ・モデルは、アップグレード後も変更せずに機能し続けますが、将来このデータ・モデルを編集することが困難になる場合があります(たとえば、計算された列の追加やその他のデータセットへのリンクの作成ができなくなります)。
データセットをアップグレードされたまま保持するようにしても、後で必要に応じてそれを編集して、元のデータセットから同じSQL問合せをコピーしてその元のデータセットを削除することができます。新しいデータセットを作成する場合、生成されたXML構造と要素名は、そのレポートのデータ・モデルを使用するテンプレートと一致する必要があります。RTFテンプレートを更新する作業は手間がかかるので、かわりにデータ・モデル・エディタの「構造」ペインを使用してXML要素名に更新できます。
データ・モデル・エディタには、10gにはなかったデータ・モデルの制限が導入されています。そのため、10gで有効であったデータ・テンプレートベースのデータ・モデルを保存しようとすると、警告メッセージが表示される場合があります。次の2つの新しい制限に注意する必要があります。
大文字/小文字の区別
10gのデータ・テンプレートでは、データ・テンプレート内の要素は、大文字/小文字に関係なく参照できました。そのため、"G_EMP.salary"でも'G_EMP.SALARY'でも参照が可能でした。11gでは、参照するアイテムの大文字/小文字は一致する必要があります。
独立した要素
10gでは、データ・テンプレートでSQL問合せに存在しない列を参照する要素名を宣言することができました。10gでは、このような状況でその要素にnull値を返していました。11gでは、このような構造が存在すると、不正な警告が発生します。この問題を修正するには、データ・モデル・エディタを使用して列を削除します。
BI Publisherと統合するためのWebサービスAPIを使用するアプリケーションがある場合、カスタム・アプリケーションでBI Publisher機能を実装し続けるようにアプリケーション・コードを更新する必要があります。11gのWebサービスの詳細は、Oracle Fusion Middleware Oracle Business Intelligence Publisher開発者ガイドを参照してください。
10gにサブ・テンプレートを使用するレポートがある場合、使用されていたインポート・プロトコルがHTTPまたはFTPであれば、11gにアップグレード後もそれらのサブ・テンプレートは機能し続けます。Fileプロトコルを使用していた場合、サブ・テンプレートを手動で11gのサーバーにコピーして10gと同じ相対パスを指定する必要があります。11gのBI Publisherでは、サブ・テンプレートはカタログ・オブジェクトとして導入されています。10gのサブ・テンプレートをカタログに移行して、強化されたセキュリティおよび管理機能を使用することをお薦めします。また、この移行では、テンプレートをコールする際のimport構文を更新する必要があります。詳細は、第1.5.3.8項「カタログのサブ・テンプレートの管理」を参照してください。
次の項で11gの新機能について説明します。
図1-9にBI Publisherのレイアウト設計ツールを示します。
レイアウト・エディタの利用対象者はビジネス・ユーザーおよびレポートの開発者です。このレイアウト・エディタは、PDF、RTF、Excel、PowerPointおよびHTMLでピクセル・パーフェクトのレポートを作成するための、直感的なドラッグ・アンド・ドロップ・インタフェースを提供する新しいブラウザベースのグラフィカル設計ツールです。これは、ブラウザを介して軽量な相互作用をサポートする動的HTML出力も提供します(第1.5.3.2項「レポートの相互作用性」を参照)。データ・モデルのサンプル・データを使用すると、コンポーネントをレイアウトに追加したときに、レイアウト・エディタにより設計がそのデータで即座に更新されるため、最終製品の外観を正確に把握できます。
図1-10にインタラクティブ・ビューアを示します。
レイアウト・エディタで設計されたレポートは、ピクセル・パーフェクトな形式で出力が生成されるだけでなく、より深い洞察力を得るためのデータの相互作用もサポートします。レポート内のチャートまたはピボット表をクリックすると、そのアイテムに応じてレポートに表示されるすべてのデータが自動的に更新およびフィルタ処理されます。インタラクティブ・ビューアにより、1つのレポートを、印刷可能な出力およびオンラインの相互作用性の両方の要件を満たすように作成できます。
図1-11に、データ・モデル・エディタを示します。
BI Publisher 11gでは、レポート・データ・モデルを作成するためのデータ・モデル・エディタが導入されました。データ・モデル・エディタにより、SQL、Excelファイル、Webサービス、HTTPフィード、その他のアプリケーションなど、様々なデータソースの複数のデータセットから単一のXML構造にデータを組み合せることができます。データ・モデルのWebユーザー・インタフェースで、問合せの作成、データのリンク、計算の作成、データ構造の定義をすべて実行できます。データ・モデル・エディタでは、複数のレポートで使用できる独立のカタログ・オブジェクトとしてデータ・モデルを保存します。
BI Publisher 11gのデータ・モデル・エディタでは、10gで使用できなかった次のソースからデータを取得することができます。
Excelワークブック
ExcelワークブックをBI Publisherが接続できる中央の場所にアップロードするか、単純にワークブックをローカル・クライアント・ディレクトリからデータ・モデル・エディタにアップロードします。ワークブックのデータをその他のデータセットのデータにリンクしたり、出力構造を変更することができます。
LDAPディレクトリ
このリリースでは、Lightweight Directory Access protocol(LDAP)データソースに対する問合せがサポートされます。LDAPディレクトリに保存されているユーザー情報を問い合せて、データ・モデル・エディタを使用してその他のデータソースから取得したデータとそのユーザー情報をリンクできます。
ビュー・オブジェクト
BI Publisherでは、Oracle Application Development Frameworkで構築されたカスタム・アプリケーションに接続して、レポートのデータソースとしてアプリケーションでビュー・オブジェクトを使用できます。
CLOB XML
データ・エンジンは、キャラクタ・ラージ・オブジェクト(CLOB)データ型としてデータベース列に保存されている整形式XMLデータを抽出して、その構造を保持できるようになりました。この機能により、個々のプロセスで生成され、BI Publisherデータ・モデルへの入力としてデータベースに保存されているXMLデータを使用することができます。
BI Publisher Schedulerの最新のアーキテクチャでは、Java Messaging Service(JMS)キュー・テクノロジを使用します。このアーキテクチャを使用して、複数のBI Publisherサーバーをクラスタに追加してから各サーバーを特定の機能専用のサーバーに指定することができます(レポート生成、ドキュメント生成、特定の配信チャンネルなど)。そのようにすることで、大量のスケジュールされたジョブに応じてPublisherをスケールアップすることができるため、柔軟性が高まります。さらに、Scheduler Diagnosticsツールを使用して、すべてのプロセッサのステータスおよび現在の負荷をリアルタイムで表示することができます。
11gの監査フレームワークにより、管理者はデータを収集してユーザー・アクティビティおよびBI Publisherとの相互作用を監査および監視できます。また11gには、BI Publisherを使用してデータを表示および分析できるように、すべてのデータをデータベース表に格納する新しいフレームワークが含まれます。強化された監査機能を使用して、管理者はユーザーがしたいこと、ユーザーがレポートにアクセスおよび表示する方法、および使用時間のピークを理解することで、コンプライアンス要件を上回るまでにカスタマ・サービスを向上させることができます。
スタイル・テンプレートとは、エンタープライズ・レポート全体でルック・アンド・フィールの一貫性を実現するための、複数のRTFレイアウトに適用するスタイル情報を定義するRTFテンプレートです。スタイル・テンプレートは、レポート定義でレポート・レイアウトに関連付けます。また、レポートを横断して一貫性のあるスタイルを簡単に適用するために、ヘッダーおよびフッター・コンテンツを定義することもできます(たとえば、複数のレポートにわたって適用され単一のテンプレートに保持できる会社ロゴ、見出し、ページ番号など)。
RTFテンプレートでサブ・テンプレートを使用する場合、サブ・テンプレートをカタログのオブジェクトとして保持できるようになりました。既存のサブ・テンプレートでこの新機能を利用するには、プライマリRTFテンプレートでコールする構文を、BI Publisherがサブ・テンプレートの新しい場所を指すように変更する必要があります。11gのサブ・テンプレートの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Publisherレポート・デザイナーズ・ガイド』のサブ・テンプレートの作成および実装に関する項を参照してください。
Oracle Business Intelligence 11gのセキュリティ・ポリシーでは、個々のユーザーおよび特定のアプリケーション・ロールを持つユーザーがアクセスできるオブジェクトおよび実行できる作業を定義します。Oracle Business Intelligence 11gでは、セキュリティ・ポリシーの定義は次のように分割されます。
Oracle BI Presentation Catalog: これにより、特定のユーザーおよびアプリケーション・ロールでアクセスできるカタログ・オブジェクトおよびプレゼンテーション・サービス機能を定義します。
リポジトリ: これにより、どのアプリケーション・ロールおよびユーザーがリポジトリ内のメタデータのどのアイテムにアクセスできるかを定義します。このセキュリティ・ポリシーは管理コンソールで定義します。
ポリシー・ストア: これにより、特定のユーザーまたは特定のアプリケーション・ロールを持つユーザーがどのOracle BI Server、BI PublisherおよびReal Time Decisions機能にアクセスできるかを定義します。Fusion Middleware Controlを使用して、デフォルトのOracle Business Intelligence Policy Storeを構成します。
Oracle Business Intelligence10gと11gのセキュリティ・モデルは、次の領域で異なります。
ユーザーおよびグループの定義: Oracle Business Intelligence 10gでは、Oracle BI管理ツールを使用してリポジトリ・ファイル内でユーザーおよびグループを定義しました。Oracle Business Intelligence 11gでは、リポジトリ内でユーザーおよびグループを定義することができなくなりました。Oracle BI EEアップグレード・アシスタントにより、ユーザーおよびグループを10gリポジトリから11gインストールの組込みのLDAPサーバーに移行します。
セキュリティ・ポリシーの定義: Oracle Business Intelligence 10gでは、カタログおよびリポジトリのセキュリティ・ポリシーはディレクトリ内のグループを参照するように定義できます。Oracle Business Intelligence 11gでは、アプリケーション・ロールに応じてセキュリティ・ポリシーを定義して、さらにそれをディレクトリ内のユーザーおよびグループにマップします。これにより、Oracle Business Intelligence 11gシステムは、企業のディレクトリを変更することなくデプロイすることができ、開発、テストおよび本番環境間でのアーティファクトの移行が容易になります。
Administratorユーザーの使用: Oracle Business Intelligence 10gのインストールでは、Administratorという名前の特別なユーザーが完全な管理権限を持ち、そのインストール内のプロセス間で信頼の確立にも使用されます。Oracle Business Intelligence 11gでは、Administratorという名前に特別な意味はありません。1人以上のユーザーが管理機能の様々なセットを請け負うように認可できます。Oracle Business Intelligence 11gでは、インストール内のプロセス間の信頼の確立に使用されるアイデンティティは構成可能であり、独立しています。
リポジトリの暗号化: Oracle Business Intelligence 10gでは、リポジトリ内の特定の機密要素が暗号化されます。Oracle Business Intelligence 11gでは、ユーザーが指定したパスワードに起因するキーを使用してリポジトリ全体が暗号化されます。11gのリポジトリはパスワードを使用しないと開きません。なくしたパスワードを復元するメカニズムはありません。
Oracle Business Intelligence 10gのセキュリティ・モデルの次の部分は、11gでも維持されています。
Oracle Business Intelligence Serverの初期化ブロック: Oracle BI Server 11gでは、引き続き認証および認可に初期化ブロックの使用がサポートされます。10gでは、リポジトリに一致するユーザーが見つからない場合にBI Serverが初期化ブロックを使用します。11gでは、インストールの構成された認証プロバイダでユーザーを認証できない場合にOracle Business Intelligenceが初期化ブロックを使用します。
詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』の初期化ブロックの作成に関する項を参照してください。
カタログ・グループ: Oracle Business Intelligence 11gでは、引き続きOracle BI Presentation Catalog内でのカタログ・グループの定義がサポートされます。これらのグループは、Oracle BI Presentation Services内でのみ表示されます。カタログ・グループは、下位互換性の目的のみで使用し、新しいインストールではアプリケーション・ロールを使用することをお薦めします。
詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』のカタログ・グループの使用に関する項を参照してください。
SAシステム・サブジェクト・エリア: Oracle Business Intelligence 11gでは、SAシステム・サブジェクト・エリアをBI Server初期化ブロックと組み合せて使用し、データベース表に保存されているユーザー、グループおよびプロファイル情報にアクセスすることができます。このサブジェクト・エリアは、下位互換性の目的でのみ使用できます。新しいインストールには組込みLDAPを使用することをお薦めします。
詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionスケジュール・ジョブ・ガイドのSAシステム・サブジェクト・エリアの設定に関する項を参照してください。
Oracle Business Intelligenceのセキュリティの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。
アップグレード・プロセス時に、既存の10gのセキュリティ・メカニズムはアップグレードされます。
アップグレード・プロセスでは、10gでサポートされるセキュリティ・メカニズム(リポジトリ・ユーザーおよびグループ、認証を初期化ブロック、カタログ・グループ、SAシステム・サブジェクト・エリアなど)を任意に組み合せて処理します。
ただし、アップグレード・アシスタントを実行する前に、注意する必要があるOracle BIのセキュリティ領域が多数あります。詳細は、第1.6.1項「Oracle BI Security: 主なアップグレードの考慮事項」を参照してください。
第1.6.1項で説明されている領域のほかに、BIのセキュリティを計画する際に考慮する必要がある要素は多数あります。詳細は、第1.6.2項「Oracle BI Security: その他のアップグレードの考慮事項」を参照してください。
次の一覧に示すように、ユーザー、グループおよび資格証明が定義および保存される方法および場所に関するセキュリティ・モデルに大きな変更がありました。セキュリティの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。
ユーザー、パスワードおよびグループは、デフォルトの10gリポジトリ・ファイルからデフォルトの11gアイデンティティ・ストア(Oracle WebLogic Serverが組み込まれたLDAPサーバー)に移行されます。リポジトリ・グループはポリシー・ストアの一致するアプリケーション・ロールを受け取ります。その他すべての認証メカニズムは、10gと同様です。
10gで別のLDAPサーバーを使用していた場合、アップグレードされた11gシステムでも初期化ブロックを介して引き続き10gで指定されていたLDAPサーバーを指定します。条件によっては、それらの初期化ブロックをWebLogic認証プロバイダに置き換えることができます。
Oracle Identity Management(OID)などの別のLDAPサーバーを使用する場合は、まず組込みのLDAPサーバーをアップグレードしてから、本番のLDAPサーバーに移行します。実際はアップグレード前に11g環境を別のセキュリティ・モデルに構成することは可能ですが、環境は組込みのLDAPサーバーにアップグレードされてしまいます。
プレゼンテーション・サービス・グループ(「Webグループ」ともいいます)は下位互換性の目的でのみ使用し、新しいインストールにはアプリケーション・ロールを使用することをお薦めします。
接続プールやLDAPサーバーなどのその他のリポジトリ・オブジェクトのパスワードは、リポジトリに維持され、暗号化されます。リポジトリ自身も暗号化されます。
Administratorユーザーはデフォルトの10gリポジトリ・ファイルからデフォルトのアイデンティティ・ストアに移行され、BIAdministratorsグループのメンバーになります。BIAdministratorsグループはBIAdministratorロールが付与され、その関連付けによりシステム管理者の権限を持ちます。
Oracle BI Presentation Catalogの古いグループおよびユーザーへの参照は更新されます。
ROLES、PERMISSIONS、USERGUIDおよびROLEGUIDSという変数名は、11gシステムで予約された変数名になります。10gのリポジトリ・ファイルをアップグレードする前に、それらの名前が存在していたら、それを変更する必要があります。ほかにもレポートなどにそれらの変数名への参照があった場合、一貫性を維持するためにその名前を変更する必要があります。
「全員」プレゼンテーション・サービス・グループは、AuthenticatedUserロールに置き換えられました。これは、認証済ロールのApplication Roleと同じです。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』のダッシュボードおよび分析のセキュリティの管理に関する項を参照してください。
10gの「プレゼンテーション・サービス管理者」というプレゼンテーション・サービス・グループを引き続き使用する場合、それに属するユーザーをこのプレゼンテーション・サービス・グループに再割当てする必要があります。かわりに、それらのユーザーには既存の最適なApplication Roleを使用するか、新しいApplication Roleを作成することをお薦めします。
USER、GROUPまたはROLESセッション変数を設定する初期化ブロックは、Fusion Middlewareのセキュリティ機構を通じてシステムにログインするユーザーの11g環境では実行されなくなります。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』のOracle Business Intelligenceのセキュリティ設定の詳細な手順に関する項を参照してください。
11gにアップグレードする際は、セキュリティに関する次の考慮事項に注意してください。
アップグレード・アシスタントでは、ターゲット・システムのOracle WebLogic Serverが組み込まれたLDAPサーバーに次のエントリを作成します。
リポジトリの各グループに対応するLDAPグループ。これには、以前のリリースに存在していたAdministratorsグループは含まれません。Administratorsグループに存在していたユーザーは、BIAdministrators LDAPグループに追加されます。
リポジトリ・グループ階層に一致するLDAPグループ階層。
Administratorユーザーは移行されて、BIAdministratorsグループの一部になります。
指定されたリポジトリのAdministratorsグループのメンバーであるAdministratorユーザー以外のすべてのユーザーは、組込みのLDAPサーバーのBIAdministratorsグループに追加されます。インストール時に指定した情報から作成した11gのAdministratorユーザーも組込みのLDAPサーバーのBIAdministratorsグループに追加されます。
アップグレード・アシスタントでは、ターゲット・システムのファイルベース・ポリシー・ストアに次のエントリを作成します。
指定されたリポジトリの各グループに対応するApplication Role。これには、以前のリリースに存在していたAdministratorsグループは含まれません。Application Roleは同じ名前を持つグループに付与されます。
リポジトリ・グループ階層に一致するApplication Role階層
アップグレード・アシスタントでは、指定されたOracle BIメタデータ・リポジトリを自動的にアップグレードして、次の変更を行います。
指定された10gリポジトリのすべてのグループは、アップグレード時にポリシー・ストアに作成されたApplication Role参照(プレースホルダ)に変換されます。
すべてのユーザーは、アップグレード時に指定されたリポジトリから削除され、ターゲット・システムの組込みのLDAPサーバーに作成されたLDAPユーザーへの参照(名前とGUID)に置き換えられます。
11gシステムにアップグレードされたリポジトリには、次の特徴があります。
アップグレードされたリポジトリは、アップグレード時に入力されたパスワードで保護され暗号化されるようになりました。
リポジトリ・ファイルは、アイデンティティ・ストアに存在すると想定されるユーザーへの参照、およびポリシー・ストアに存在すると想定されるApplication Rolesへの参照が含まれるようにアップグレードされます。
アップグレードされたリポジトリ・ファイルの名前に、数字の接尾辞が追加されます。追加された数字は、ファイルがアップグレードされた回数を示します。
アップグレードされたリポジトリは、通常どおり、Oracle BI管理ツールでオフライン・モードで開くことができ、オンライン・モードで開くOracle BI Serverにデプロイできます。
アップグレード・アシスタントでは、自動的にOracle BI Presentation Services Catalogに次のような変更を行います。
カタログはスキャンされて、古いセキュリティ表現は新しいものに変換されます。10gに存在していた権限は移行されます。アップグレードされたOracle BI Presentation Catalogの各ユーザーは、ユーザー名および新しいGUID属性を使用して参照されます。この属性は各ユーザーで一意の値を持ちます。GUID属性の値は、Oracle BI EEが使用するアイデンティティ・ストアから継承されます。そのため、後でアイデンティティ・ストアを切り替える場合、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』の指示に従ってGUIDを更新してください。
アップグレード・プロセスでは、10gのカタログ・グループをアップグレードされたカタログにそのまま残し、同じ権限、アクセス権、およびメンバーシップを割り当てます。
SSL設定などの構成設定は、アップグレード・ソースから引き継がれません。SSLの構成に関する詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』のOracle Business IntelligenceのSSLの構成に関する項を参照してください。
Oracle BI EE 11gでは、次のセキュリティ機能を使用できます。
Fusion Middlewareセキュリティ・モデル
LDAPサーバーへの直接アクセス
簡素化されたSSL構成
強化された管理権限を管理するモデル
リポジトリの保護および暗号化
新機能の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』のOracle Business Intelligenceセキュリティの新機能に関する項を参照してください。
Oracle BI EE 11.1.1.3または11.1.1.5から11.1.1.6への移行は、10gから11gへの移行とは異なります。たとえば、Oracle Fusion Middlewareアップグレード・アシスタントを使用するかわりに、パッチセット・アシスタントなど様々なツールを使用します。
その他の重要な違いは、10gから11gへのアップグレードが「アウトオブプレース・アップグレード」と呼ばれているのに対し、別の11gリリースへの移行は「インプレース・アップグレード」と呼ばれていることです。これは、既存のファイルに対して新しいソフトウェアを適用することに起因しています。また、ある11g リリースから別の11g リリースへの移行は、パッチセットの適用とも呼ばれます。
詳細な手順は、『Oracle Fusion Middlewareパッチ適用ガイド』を参照してください。表1-17に手順の概要を示します。
11gリリース1(11.1.1.5.0)から開始する場合は、表1-17のすべての手順が必要になるわけではありません。詳細は、『Oracle Fusion Middlewareパッチ適用ガイド』の参照先情報を参照してください。
表1-17 Oracle BI 11.1.1.6パッチセットの適用手順の概要
ステップ | 説明 | 注意 |
---|---|---|
1 |
次の一般的なアップグレード前のタスクを実行します。
詳細は、『Oracle Fusion Middlewareパッチ適用ガイド』の一般的なパッチ適用前タスクの実行に関する項を参照してください。 |
アップグレードするBIドメインの一部である各コンピュータでこの手順を実行します。 |
2 |
『Oracle Fusion Middlewareパッチ適用ガイド』のインストーラのダウンロードに関する項の説明にあるように、適切な製品インストーラをダウンロードします。 |
このインストーラのファイルを取得する手順を1回実行します。複数回使用することもできます。 |
3 |
『Oracle Fusion Middlewareパッチ適用ガイド』のOracle Fusion Middlewareの最新のパッチ・セットの適用に関する項の説明に従い、Oracle WebLogic Serverにパッチを適用して最新のバージョン(10.3.5)にします。 |
アップグレードするBIドメインを構成する各コンピュータでこの手順を実行します。Middlewareホームが共有されている場合は、この手順を1回のみ実行します。 |
4 |
Oracle BI Product Installerを実行してから、ソフトウェアのみのインストールを実行します(パッチを適用する既存のMiddlewareホームを指定します)。 詳細は、『Oracle Fusion Middlewareパッチ適用ガイド』のインストーラの起動に関する項を参照してください。 |
アップグレードするBIドメインを構成する各コンピュータでこの手順を実行します。Middlewareホームが共有されている場合は、この手順を1回のみ実行します。 |
5 |
次のリストにあるように、RCUで作成されたそれぞれのOracle BIスキーマでパッチ・セット・アシスタントを実行します。最初にMDSスキーマを更新します。
詳細は、『Oracle Fusion Middlewareパッチ適用ガイド』のパッチ・セット・アシスタントの使用開始前の処理に関する項、および更新後のスキーマ・バージョン番号の検証に関する項を参照してください。 |
ドメインごとにこの手順を1回実行します。 |
6 |
『Oracle Fusion Middlewareパッチ適用ガイド』のシステム・コンポーネントのアップグレードに関する項の説明にあるように、様々なシステム・コンポーネントをアップグレードします。 |
ドメインごとにこの手順を1回実行します。 |
7 |
『Oracle Fusion Middlewareパッチ適用ガイド』のFusion Middlewareの共有ライブラリの更新に関する項の説明にあるように、ライブラリを更新します。 |
ドメインごとにこの手順を1回実行します。 |
8 |
『Oracle Fusion Middlewareパッチ適用ガイド』の構成およびストアの更新に関する項の説明にあるように、構成およびストアを更新します。 |
ドメインごとにこの手順を1回実行します。 |
9 |
『Oracle Fusion Middlewareパッチ適用ガイド』のOracle Business Intelligenceコード・グラントのアップグレードに関する項の説明にあるように、Oracle BI用のコード・グラント(セキュリティ・ポリシー・アーティファクト)をアップグレードします。 |
ドメインごとにこの手順を1回実行します。 |
10 |
『Oracle Fusion Middlewareパッチ適用ガイド』のOracle Business Intelligence Catalogsの更新に関する項の説明にあるように、カタログをアップグレードします(Oracle BI EEがインストールされている場合のみ適用されます)。 |
ドメインごとにこの手順を1回実行します。 |
11 |
サーバーおよびプロセスを起動します。 詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceの起動と停止に関する項を参照してください。 |
ドメイン内のコンピュータごとにこの手順を1回実行します。 |
12 |
Oracle Real Time Decisionsがインストールされている場合、『Oracle Fusion Middlewareパッチ適用ガイド』のOracle Real-Time Decisionsの更新に関する項の説明に従ってそれを更新します。 |
ドメインごとにこの手順を1回実行します。 |
13 |
Oracle BI EEがインストールされている場合、それを起動してアップグレードされたインストールを検証します。 詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』のOracle BI Enterprise Editionへのサインインに関する項を参照してください。 |
インストール全体に対してこの手順を1回実行します。 |
Oracle BI Applicationsシステムの一部として使用するOracle BI EE 11gにアップグレードする前に、アップグレード対象のOracle BI Applicationsリリースに付属のOracle Business Intelligence Applicationsアップグレード・ガイドを必ず参照して、実行する手順を確認してください。たとえば、アップグレード元のOracle BI Applicationsのリリースに応じて、Oracle BI Applicationsの新しいリリースへのアップグレードの最初の手順は、使用しているOracle BI EEのリリースをアップグレードすることになる場合があります。
Oracle BI Applicationsリリースには、ETLテクノロジ・コンポーネントがあります。ハードウェア、プラットフォーム、およびサポートされるデータベースは、Oracle BI EEでサポートされるもの(通常はそのサブセット)と異なる場合があります。必ずOracle BI Applicationsの動作保証およびシステム要件の情報を調べて、特定のリリースのOracle BI ApplicationsにはどのリリースのOracle BI EE 11gの動作が保証されているか確認してください。
Oracle BI Applicationsリリース7.9.6.3はOracle Business Intelligence Enterprise Editionリリース11g (Oracle BI EE 11.1.1.5.0以降)上で動作保証されています。以前のリリースのOracle BI Applicationsは、Oracle BI EEリリース11g上では動作保証されていません。通常のアップグレードと同様に、現在Oracle BI EE 10gを使用しているOracle BI Applicationsカスタマは、Oracle BI 11gの新機能を利用することで得られるビジネス利益を勘案して、Oracle BI 11gにアップグレードするタイミングを検討し、Oracle BI Applicationsおよびカスタム・コンテンツを移行するために最適なアップグレード・プロジェクトを計画してください。推奨される戦略は、同じプロジェクトの一環としてOracle BI Applications 7.9.6.3とOracle BI EE 11gの両方にアップグレードすることです。Oracle BI EE 10gのまま残すことも検討に値する最適なオプションです。
11gのBI Serverはメタデータ妥当性チェックがより厳密になり、以前のOracle BI Applicationsリリースからアップグレードされたリポジトリでは多数の警告が発生するので、Oracle BI ApplicationsカスタマがOracle BI EE 11gにアップグレードする際は注意してください。Oracle BI Applicationsリリース7.9.6.3ではこの警告の対策がとられており、カスタマがOracle BI Applicationsをリリース7.9.6.3にアップグレードする際に表示されない場合があります。