Enterprise Manager AWRウェアハウスでは、重要なOracleデータベースの自動ワークロード・リポジトリから詳細なパフォーマンス・データを統合して保存できます。この統合されたAWRウェアハウスを使用することにより、DBAおよび開発者は、ソース・データベースのAWR保存期間を超えて履歴パフォーマンス・データを表示および分析できます。Enterprise Managerでは、自動ワークロード・リポジトリ(AWR)のデータを1つ以上のソース・データベース・ターゲットから抽出し、ソース・データベースから独立して管理されているAWRウェアハウスに転送します。AWRウェアハウスでは、選択したEnterprise Managerデータベース・ターゲットのAWRデータの長期履歴を保持できます(そのように構成されている場合)。これにより、ソース・データベース・ターゲットにパフォーマンスや領域の影響を与えずに、データベース間でAWRデータの長期分析を行うことができます。
そのため、一元管理されたAWRウェアハウスにAWRデータをアップロードすることで、本番システムの領域を解放して、パフォーマンスを向上させることができます。
AWRウェアハウスを構成するには、Enterprise Manager管理者が既存のEnterprise Managerデータベース・ターゲットをAWRウェアハウスとして指定する必要があります。ウェアハウスは、SYSAUX表領域を使用してSYSスキーマに構築されます。ウェアハウス・ターゲット・データベースは、バージョン12.1.0.2以上、または適切なパッチを適用済のバージョン11.2.0.4である必要があります。また、対応するソース・データベースのデータベース・バージョン以上である必要があります。
この機能を使用するには、まず、Enterprise Managerで使用可能なOracleデータベースをAWRウェアハウスとして設定する必要があります。ウェアハウス・データベースを設定したら、リポジトリを抽出してウェアハウスにアップロードする対象のソース・データベースを指定できます。
「AWRウェアハウス」ページにアクセスする手順:
「ターゲット」メニューから「データベース」を選択します。
「データベース」ページで、「パフォーマンス」をクリックし、「AWRウェアハウス」を選択します。
初期設定(ウェアハウスの設定前)では、ページの左側に機能のワークフローが、右側に構成アクセスが表示されます。
設定後は、ページの右側にウェアハウス構成の概要がまとめられ、使用可能な領域の使用率(%)がグラフで表示されます。このビューで、ウェアハウスを構成できます。
初期設定後、ホーム・ページがダッシュボードとなって、次のタスクを実行できるようになります。
ソース・データベースの追加および削除。
スナップショットのアップロードの有効化および無効化。
スナップショットのオンデマンド・アップロード。
ウェアハウスに格納されているAWRデータへのアクセス権を管理者へ付与。
インシデントおよびエラーの監視と調査。
ウェアハウスでのパフォーマンス・レポートおよび分析の実行(ローカルのAWRと同様)。
この項では、AWRウェアハウスに関する次の内容について説明します。
ターゲット・データベースが、既存のバージョン12.1.0.2以上または適切なパッチ・レベルを適用済の11.2.0.4で、Enterprise Manager Cloud Controlの管理対象ターゲットであること。選択したデータベースが他のアプリケーションで使用されないようにすること、およびEnterprise Manager Cloud Controlリポジトリがウェアハウスとして使用されないようにすることをお薦めします。
アップロードされるデータを収容できる十分な領域(1ソース・データベース1日当たりの倍数)があること。1データベース1日当たりの目安は4-10MBの範囲です。
AWRウェアハウスを構成するには、スーパー管理者権限を有していること。
ソース・データベースの追加および削除。
スナップショットのアップロードの有効化および無効化。
スナップショットのオンデマンド・アップロード。
一元的に保存されたAWRデータの表示アクセス権の付与。
ソース・データベースの追加および削除
AWRデータをウェアハウスにアップロードする対象のソース・データベースは、ウェアハウス・データベースのバージョン以前(10.2.0.4まで)である必要があります。ソース・データベースを追加および削除するには、sys.dbms_swrf_internal
パッケージの実行権限とDBAロールを保持し、データベース・ターゲットおよびデータベース資格証明にアクセスできる必要があります。
ツールバーの「追加」ボタンをクリックして、AWRウェアハウスに追加するソース・データベースを選択します。削除する場合は、ダッシュボードでソース・データベースを選択し、「削除」ボタンをクリックします。データベースを削除しても、そのデータを消去するジョブが実行されるまでの間、データは残っています。データを保持する場合は、データベースを削除するかわりに、スナップショットのアップロードを無効化します。
スナップショットのアップロードの有効化および無効化
ソース・データベースを追加する場合、そのスナップショットのアップロードはデフォルトで有効になっています。ソース・データベースのスナップショットのアップロードを無効化(および再度有効化)するには、所有者またはプロキシである必要があります。アップロードを無効化する場合、処理中のジョブはアップロードの停止前に完了できます。再度有効化した場合、アップロードは次回のスケジュール済アップロードで再開されます。
スナップショットのオンデマンド・アップロード
スナップショットをオンデマンドでアップロードすることもできます。ダッシュボードでソース・データベースを選択し、「アクション」メニューから「スナップショットをただちにアップロード」を選択します。
AWRスナップショットの表示アクセス権の付与
ソース・データベースからのAWRスナップショット・データのアップロードは、ETLプロセス(抽出、転送、ロードといったETL処理を実行する一連のジョブ)として行われます。
AWRデータの抽出
収集プロセスの一環として、DBMSジョブを一定の間隔で実行し、AWRスナップショットを収集して、ターゲット・ホスト上のステージング領域にダンプを作成します。このジョブでは、初回時に既存のAWRデータを収集し、以降は最新のスナップショットを増分方式で収集します。初回時に収集するデータが多すぎる場合、ジョブは時間をずらして収集プロセスを実行し、ソース・データベースに負荷がかからないようにします。
AWRデータの転送
Enterprise Managerジョブをそれぞれのホスト上で一定の間隔で実行し、ソース・データベースのAWRデータをウェアハウス・ホスト上のステージング領域に転送して、後続の処理に備えます。このジョブでは、エージェント間のファイル転送メカニズムを使用してダンプ・ファイルをコピーします。ウェアハウスへのアップロードが正常に完了すると、ダンプ・ファイルはホストのステージング領域から削除されます。
転送済データのAWRウェアハウスへのロード
DBMSジョブを一定の間隔で実行し、複数のソース・データベースのダンプ・ファイルを処理して、それらをウェアハウス・スキーマにインポートします。これは、インポート済のスナップショットが重複しないように、増分方式で行われます。インポート・プロセスの一環として、ジョブではDB IDをマップして、一意性を確保します。この情報を別の表で管理して、重複したDB IDを処理し、マルチテナント・シナリオ(たとえば、1つのAWRデータベースに複数の顧客データが保存され、データベース名が重複している場合など)に対応します。AWRデータは、構成可能な保存期間まではウェアハウスに保持され、その後でパージされます。
注意:
スナップショットをオンデマンドでアップロードすることもできます。ダッシュボードでソース・データベースを選択し、「アクション」メニューから「スナップショットをただちにアップロード」を選択します。
構成済のAWRウェアハウスから履歴データ、グラフおよびレポートを表示するには、次の手順に従って、ソース・データベースのそれぞれのパフォーマンス・ページ上で「データの表示」モードを「AWRウェアハウス」に切り替えます。
「パフォーマンス・ホーム」ページ
AWRウェアハウスで「パフォーマンス・ホーム」ページを使用するには、次の手順を実行します。
ダッシュボードでソース・データベースを選択します。
ツールバーの「パフォーマンス・ホーム」ボタンをクリックします。
「パフォーマンス・ホーム」ページが、履歴 - AWRウェアハウス・モードで表示されます。このページを表示するためにソース・データベースにログインする必要はありません。
「パフォーマンス・ホーム」ページにはデータベースのホーム・ページからもアクセスできます。「パフォーマンス・ホーム」ページで、「データの表示」ドロップダウン・メニューから 「履歴 - AWRウェアハウス」を選択します。AWRウェアハウスの選択肢は、ソース・データベースとして追加されているデータベースのみを対象とし、アクセス権を付与されているユーザーのみが使用できます。
参照:
「パフォーマンス・ホーム」ページの詳細は、「ユーザー・アクティビティの監視」を参照してください。
「ASH分析」ページ
AWRウェアハウスで「ASH分析」ページを使用するには、次の手順を実行します。
ダッシュボードでソース・データベースを選択します。
ツールバーの「ASH分析」ボタンをクリックします。
「ASH分析」ページが、履歴 - AWRウェアハウス・モードで表示されます。このページを表示するためにソース・データベースにログインする必要はありません。
「ASH分析」ページには、選択したデータベースのホーム・ページからもアクセスできます。「パフォーマンス」メニューから「ASH分析」を選択します。「ASH分析」ページで、「AWRデータ・ソース」ドロップダウン・メニューから「履歴 - AWRウェアハウス」を選択します。
参照:
ASH分析の詳細は、「データベース・アクティビティのスパイクの原因の確認」を参照してください。
「AWRレポート」ページ
AWRウェアハウスで「AWRレポート」ページを使用するには、次の手順を実行します。
ダッシュボードでソース・データベースを選択します。
ツールバーの「AWRレポート」ボタンをクリックします。
「AWRレポート」ページが、履歴 - AWRウェアハウス・モードで表示されます。このページを表示するためにソース・データベースにログインする必要はありません。
「レポートを生成」をクリックします。
「AWRレポート」ページには、選択したデータベースのホーム・ページからもアクセスできます。「パフォーマンス」メニューから、「AWR」、「AWRレポート」の順に選択します。「AWRレポート」ページで、「AWRデータ・ソース」ドロップダウン・メニューから「履歴 - AWRウェアハウス」を選択します。
参照:
AWRレポートの詳細は、「時間の経過によるパフォーマンス低下の解決」を参照してください。
「期間比較ADDM」ページ
AWRウェアハウスで「期間比較ADDM」ページを使用するには、次の手順を実行します。
ダッシュボードでソース・データベースを選択します。
「期間の比較」ドロップダウン・メニューから「期間比較ADDM」を選択します。
「期間比較ADDM」ページが、履歴 - AWRウェアハウス・モードで表示されます。このページを表示するためにソース・データベースにログインする必要はありません。
手順1および2を完了します。手順2のデータベースの選択肢には、ウェアハウス内のAWRデータが保存されている、アクセス可能なすべてのデータベースが表示されます。
「実行」をクリックして、比較を実行します。
「期間比較ADDM」ページには、選択したデータベースのホーム・ページからもアクセスできます。「パフォーマンス」メニューから、「AWR」、「期間比較ADDM」の順に選択します。「期間比較ADDM」ページで、「AWRデータ・ソース」ドロップダウン・メニューから「履歴 - AWRウェアハウス」を選択します。期間比較ADDMの実行の詳細は、ここをクリックしてください。
参照:
期間比較ADDMの詳細は、「現在のシステム・パフォーマンスのベースライン期間との比較」を参照してください。
期間比較レポート
AWRウェアハウスで「期間比較レポート」ページを使用するには、次の手順を実行します。
ダッシュボードでソース・データベースを選択します。
「期間の比較」ドロップダウン・メニューから「期間比較レポート」を選択します。
「期間比較レポート」ページが、履歴 - AWRウェアハウス・モードで表示されます。このページを表示するためにソース・データベースにログインする必要はありません。
「第1期間」および「第2期間」を完了します。2つの期間の選択肢は、ウェアハウス内のデータから導出されます。第2期間では、ウェアハウス内のアクセス可能な任意のデータベースを選択できます。
「レポートを生成」をクリックします。
「期間比較レポート」ページには、選択したデータベースのホーム・ページからもアクセスできます。「パフォーマンス」メニューから、「AWR」、「期間比較レポート」の順に選択します。「期間比較レポート」ページで、「AWRデータ・ソース」ドロップダウン・メニューから「履歴 - AWRウェアハウス」を選択します。
参照:
期間比較レポートの詳細は、「AWR期間の比較レポートの実行」を参照してください。
データを定期的に移動すると、アップロード・プロセスの様々な段階で問題が発生することがあります。ダッシュボードにはインシデントおよびエラーのレポートが表示されるので、問題をトレースして解決できます。Enterprise Managerのベスト・プラクティスに従い、既存のフレームワークを使用してインシデントの管理や通知の構成などを行うことができます。
ダッシュボードのグラフ領域には、ウェアハウスのアップロード・アクティビティ全般で発生した問題の一覧が表示されます。インシデントが発生すると、「インシデントの表示」リンクが表示され、それをクリックするとインシデント・マネージャに直接リンクされるので、ドリルダウンして詳細を調べることができます。「ガイドされた解決」セクションには、レポートされたウェアハウス・エラーを表示するリンクやAWRウェアハウスのダッシュボードに戻るリンクが用意されています。
特定のデータベース・ソースに関するエラーを表示するには、ダッシュボードでデータベース行を選択し、ツールバーの「エラーの表示」をクリックします。
通常、エラーはアクティビティ別(AWRウェアハウスのロード、ソース・データベースの抽出、転送)に分類されます。よくあるエラーおよび推奨される解決策の一部を次に示します。
AWRウェアハウスのロード・エラー
AWRウェアハウスのSYSAUX表領域が不十分で、AWRスナップショットのインポートに対応できない場合、インポートは次のエラーにより失敗します。
ORA-20115: Data Pump import encountered error: ORA-31626: job does not exist ORA-31633: unable to create master table "SYS.SYS_IMPORT_FULL_27" ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95 ORA-06512: at "SYS.KUPV$FT", line 1048 ORA-01658: unable to create INITIAL extent for segment in tablespace SYSAUX ORA-31626: job does not exist
この問題を解決するには、SYSAUX表領域を増やしてください。
ロード・ジョブでは、データ・ポンプを使用してAWRスナップショット・ダンプをインポートします。データ・ポンプ・ジョブでは、マスター表を使用してジョブの進捗を追跡します。インポート中にエラーが発生すると、マスター表はそのまま残ります。エラーが累積するに従ってマスター表も増え、最終的に次のエラーが発生します。
ORA-20115: Data Pump import encountered error: ORA-31634: job already exists ORA-31664: unable to construct unique job name when defaulted ORA-31634: job already exists
これを解決するには、以前に失敗したジョブのマスター表を削除します。次のようにして、NOT RUNNING
状態のジョブを対象としたdba_datapump_jobs
ビューの問合せを行います。
SELECT job_name FROM dba_datapump_jobs WHERE owner_name='SYS' AND operation='IMPORT' AND job_mode='FULL' AND job_name like 'SYS_IMPORT_%' AND state='NOT RUNNING';
注意:
問合せが戻したジョブ名がアクティブなデータ・ポンプ・ジョブによって使用されている場合があります。データ・ポンプのマスター表を誤って削除しないように、アクティブなデータ・ポンプ・ジョブがないことを確認してください。
AWRウェアハウスの機能を有効にするパッチには、レガシー・マスター表の修正が含まれているので、パッチ適用後にこの問題が発生することはありません。
アクティブなデータ・ポンプ・ジョブが正常に終了しないと(ジョブの異常終了、データベースの停止など)、後続のジョブは次のエラーにより失敗します。
ORA-39097: Data Pump job encountered unexpected error -56935 ORA-39065: unexpected master process exception in DISPATCH ORA-56935: existing datapump jobs are using a different version of time zone data file
この問題を解決するには、データベース・プロパティでデータベースの起動に関する特定の値をチェックし、次のように適切なアクションを実行します。
SELECT property_name, property_value FROM sys.database_properties WHERE property_name in ('DST_UPGRADE_STATE', 'DST_SECONDARY_TT_VERSION');
指定したプロパティに対して、問合せから'DATAPUMP'
および '<> 0'
がそれぞれ戻された場合は、次を実行します。
exec dbms_dst.unload_secondary();
注意:
このデータ・ポンプ・エラーは、ソース・データベースの抽出時にも発生する場合があります。
ソース・データベースのタイムゾーンがAWRウェアハウスのタイムゾーンよりも進んでいると、最新のスナップショット・ダンプのインポート時に次のエラーが発生します。
ORA-20105: Unable to move AWR data to SYS ORA-06512: at "SYS.DBMS_SWRF_INTERNAL", line 4773 ORA-13555: Message 13555 not found; product=RDBMS; facility=ORA; arguments: [end_time is greater than SYSDATE]
処置は必要ありません。この問題は、AWRウェアハウスのSYSDATE
がポンプ・ファイルの日付を過ぎると自動的に修正されます。
ソース・データベースの抽出エラー
ソース・データベースのSYSAUX表領域が不十分で、AWRスナップショットの抽出に対応できない場合、抽出は次のエラーにより失敗します。
ORA-20115: Data Pump export encountered error: ORA-31626: job does not exist ORA-31633: unable to create master table "SYS.SYS_EXPORT_TABLE_08" ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95 ORA-06512: at "SYS.KUPV$FT", line 1048 ORA-01658: unable to create INITIAL extent for segment in tablespace SYSAUX ORA-06512: at "SYS.DBMS_SWRF_INTERNAL", line 2159 ORA-31626: job does not exist
この問題を解決するには、SYSAUX表領域を増やしてください。
抽出ジョブでは、データ・ポンプを使用してAWRスナップショット・ダンプをエクスポートします。データ・ポンプ・ジョブでは、マスター表を使用してジョブの進捗を追跡します。エクスポート中にエラーが発生すると、マスター表はそのまま残ります。エラーが累積するに従ってマスター表も増え、最終的に次のエラーが発生します。
ORA-20115: Data Pump import encountered error: ORA-31634: job already exists ORA-31664: unable to construct unique job name when defaulted ORA-31634: job already exists
これを解決するには、以前に失敗したジョブのマスター表を削除します。次のようにして、NOT RUNNING
状態のジョブを対象としたdba_datapump_jobs
ビューの問合せを行います。
SELECT job_name FROM dba_datapump_jobs WHERE owner_name='SYS' AND operation='EXPORT' AND job_mode='TABLE' AND job_name like 'SYS_EXPORT_%' AND state='NOT RUNNING';
注意:
問合せが戻したジョブ名がアクティブなデータ・ポンプ・ジョブによって使用されている場合があります。データ・ポンプのマスター表を誤って削除しないように、アクティブなデータ・ポンプ・ジョブがないことを確認してください。
AWRウェアハウスの機能を有効にするパッチには、レガシー・マスター表の修正が含まれているので、パッチ適用後にこの問題が発生することはありません。
ソース・データベースの抽出時に発生する可能性のあるその他のエラーは、「AWRウェアハウスのロード・エラー」のデータ・ポンプ・エラーも参照してください。
転送エラー
1つのソース・データベースにAWRウェアハウスへのロードを待機しているダンプ・ファイルが多数あり、それぞれのサイズを合計するとしきい値(1GB)を超える場合は、次のエラーが発生します。
The total size of dump files from the source database exceeds threshold value (size: xxx MB, threshold: xxx MB)
AWRウェアハウスへのダンプ・ファイルのロードに根本的な問題があって、ダンプ・ファイルのバックログが生成されている可能性があります。未処理のロード・エラーがないかチェックし、ある場合はそのエラーを解決して、インポートを再開できるようにします。
AWRウェアハウスへのロードを待機しているすべてのソース・データベースのダンプ・ファイルの合計サイズがしきい値(30GB)を超える場合、次のエラーが発生します。
The total size of dump files on AWR Warehouse exceeds threshold value (size: xxx MB, threshold: xxx MB)
ロード・キューに保留中のダンプ・ファイルのバックログが存在する理由を特定します。バックログの問題を解決すると、ロードを再開できるようになります。
Oracleでは、ウェアハウス・マネージャとEnterprise Managerの両方の視点からのベスト・プラクティスを推奨しています。
ウェアハウス・データベースの視点からのベスト・プラクティスには、次の領域が関連します。
ウェアハウス・データベースでの管理および必要な場合の調整には、自動メモリー管理を使用することをお薦めします。このためには、ターゲット・メモリー・サイズ初期化パラメータ(MEMORY_TARGET)と、オプションの最大メモリー・サイズ初期化パラメータ(MEMORY_MAX_TARGET)を設定します。ターゲット・メモリーの量はウェアハウスのユーザー数に依存します。2GB以上に設定し、負荷やその他の要件に応じて変更します。
手動メモリー管理を使用する場合は、SGAおよびインスタンスPGAのサイズを十分高い値(2GB以上)に設定します。手動共有メモリー管理の場合は、個別SGAコンポーネントのサイズ(特にバッファ・キャッシュ・サイズおよび共有プール・サイズなど)を十分高い値に設定します。
デフォルトでは、Oracle Databaseは1時間おきにスナップショットを取得しますが、スナップショット・サイズはデータベースのロードによって異なります。同時アクティブ・セッションが平均10セッションの一般的なシステムでは、スナップショットごとに1MBから2MBを使用します。このため、デフォルトの1時間のスナップショット間隔で、1日およそ24MBから48MBが必要です。
AWRデータはSYSAUX表領域に格納されます。必要な表領域はソース・データベースの数に依存します。ソース・データベースの一般的なロードでデフォルト設定を使用する場合、ソース・データベースごとに1日およそ24MBから48MBが必要です。
必要な領域をさらに正確に読み取るには、ORACLE_HOME/rdbms/admin
ディレクトリにあるawrinfo.sql
スクリプトを実行します。具体的には、「Size estimates for AWR snapshots」セクションの「AWR size/day」と「AWR size/wk」の値を参照してください。ソース・データベースでは、これらの値はデータベース上に生成されるAWRデータの平均サイズを表します。AWRウェアハウス・データベースでは、これらの値はすべてのソース・データベースからインポートされるAWRデータの平均サイズを表します。これらの値を使用してウェアハウス領域要件を見積ります。通常は、ウェアハウスにソース・データベースが追加されると、AWRデータの格納に必要な領域も増加します。
冗長性の高いディスク・グループで、「同期単一ブロック読取りの平均待機時間」が40ミリ秒未満の場合に自動ストレージ管理(ASM)を使用します。これは記憶域とI/Oに関連するその他のメトリックとあわせてDBA_HIST_SYSMETRIC_SUMMARYビューに表示されます。
また、ソース・データベースから受信したAWRデータを含むダンプ・ファイルをウェアハウス・データベースにロードするまで格納するために、ウェアハウス・ホストに十分な空きディスク領域(約50GB)があることを確認してください。
Enterprise Managerの視点からのベスト・プラクティスには、次の領域が関連します。
ソース・データベース・ターゲットをAWRウェアハウス・リポジトリに追加するには、それぞれのソース・データベースとそのホストに優先資格証明を設定します(通常の資格証明で十分です)。これにより、複数のソース・データベースを一括して追加できます(複数のデータベースは「検索と選択: データベース」ダイアログで選択します)。
データベース資格証明 - データベース・ユーザーには次のものが必要です。
DBAロール
SYS.DBMS_SWRF_INTERNAL
パッケージに対する実行権限
データベース・ホスト資格証明 – ユーザーはエージェント・ユーザーと同じである必要があります。