| Oracle® OLAPユーザーズ・ガイド 11g リリース2（11.2） B61345-01 |
|
 戻る |
 次へ |
Oracle OLAPはデータベース内にあり、そのリソースは同じツールを使用して管理されるため、Oracle OLAPおよびデータベースの管理は集中して行われます。ただし、データベースのチューニングなど、データ・ウェアハウス固有の作業は行う必要があります。
この章では、次の項目について説明します。
表7-1に、Oracle OLAPのパフォーマンスに影響するパラメータを示します。サーバー・パラメータ・ファイルまたはinit.oraファイルをこれらの値に変更した後、データベース・インスタンスを再起動します。これらの設定の効果を監視し、必要に応じて設定を調整できます。
|
参照:
|
表7-1 データベース・パラメータの初期設定
| パラメータ | デフォルト値 | 推奨設定 | 説明 |
|---|---|---|---|
|
|
この値を減らしてインスタンスで実行されるジョブ・スレーブの最大数を制限する場合は、OLAP用のプロセス数を次のように計算する。 CPUの数+CPU3個ごとに1。マルチコアCPUでは各コアを1つのCPUとして数える。 たとえば、4プロセッサのコンピュータでは |
OLAPの複数のビルドにおけるパラレル化の程度を制御する（「パラレル化」を参照）。 |
|
|
|
|
|
パラレル化の程度の決定方法を制御する。
|
|
導出 |
2.5×同時OLAPユーザーの最大数。 |
各ユーザーに対して十分な数のバックグラウンド・プロセスを確保する。 |
|
|
(10gでは |
|
UNDO表領域を使用するかどうかを指定する。 |
|
|
導出 |
UNDO表領域の名前。事前に定義されている必要がある。 |
OLAP用に定義されたUNDO表領域を指定する（「UNDO表領域の作成」を参照）。 |
システム・パラメータの設定手順:
テキスト・エディタでinit.ora初期化ファイルを開きます。
ファイルの設定を追加または変更します（表7-1を参照）。
データベースをいったん停止し、再起動します。
Windowsの「サービス」ユーティリティを使用して、OracleServiceをいったん停止し、再起動します。
Linux上では、次のようなコマンドを使用します。STARTUPコマンドの初期化ファイルが正しいものであることを確認してください。
SQLPLUS '/ AS SYSDBA' SHUTDOWN IMMEDIATE STARTUP pfile=$ORACLE_BASE/admin/orcl/pfile/init.ora.724200516420
アナリティック・ワークスペースは、特に指定しないかぎり、所有者のデフォルトの表領域に格納されます。OLAPに使用するすべての表領域には、EXTENT MANAGEMENT LOCALが指定される必要があります。デフォルト・パラメータを使用して作成される表領域では、リソースが効率的に使用されないことがあります。格納するアナリティック・ワークスペースにあわせて、UNDO表領域、永続表領域および一時表領域を作成する必要があります。
UNDO表領域は、次の例のようにEXTENT MANAGEMENT LOCAL句を使用して作成します。
CREATE UNDO TABLESPACE olapundo DATAFILE '$ORACLE_BASE/oradata/undo.dbf'
SIZE 64M REUSE AUTOEXTEND ON NEXT 8M
MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL;
UNDO表領域を作成したら、次の設定をシステム・パラメータ・ファイルに反映し、データベースを再起動します（「データベース初期化パラメータの設定」を参照）。
UNDO_TABLESPACE=tablespace
UNDO_MANAGEMENT=AUTO
各次元オブジェクトは、少なくとも1つのエクステントを占有します。エクステントのサイズを固定すると、割当て領域の大部分が無駄になることがあります。たとえば、あるオブジェクトが64KBで、エクステントが1MB（デフォルト）の均一サイズに設定されている場合、エクステントのうち、ほんのわずかな部分のみが使用されることになります。
永続表領域は、次の例のようにEXTENT MANAGEMENT LOCAL句およびSEGMENT SPACE MANAGEMENT AUTO句を使用して作成します。
CREATE TABLESPACE glo DATAFILE '$ORACLE_BASE/oradata/glo.dbf'
SIZE 64M REUSE AUTOEXTEND ON NEXT 8M MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
Oracle OLAPでは、キューブ内のデータに対するすべての変更（データ・ロードやデータ分析の結果による変更）を格納するのに一時表領域が使用されます。キューブを保存すると、これらの変更内容が永続表領域に移動され、一時表領域がクリアされます。
このような方法で使用する場合は、表領域内に相当数のエクステントが作成されます。Oracle OLAPでの使用に適した一時表領域には、次の例のようにEXTENT MANAGEMENT LOCAL句、UNIFORM SIZE句および小さめのサイズを指定することが必要です。
CREATE TEMPORARY TABLESPACE glotmp TEMPFILE '$ORACLE_BASE/oradata/glotmp.tmp'
SIZE 50M REUSE AUTOEXTEND ON NEXT 5M MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K;
Oracle Databaseには、定期的な作業を簡素化するための高度なストレージ管理ツールが用意されています。自動ストレージ管理（ASM）は、データベース記憶域をディスク・グループに仮想化する簡易なストレージ管理インタフェースを備えています。少数のディスク・グループを管理でき、それらのディスク・グループへのデータベース・ファイルの配置はASMにより自動的に行われます。
ASMでは、使用可能なすべてのストレージ・リソース間でデータを均等に分散させることにより、パフォーマンスと使用率が最適化されます。ディスクの追加または削除を行うと、ASMにより自動的にファイルがディスク・グループ全体に再分散されます
OLAPはOracle Databaseに組み込まれているため、リレーショナル・データと次元データのどちらを管理する場合にもASMを使用できます。
アナリティック・ワークスペースには、ASMを使用することを強くお薦めします。ASMを使用して管理されているシステムは、ファイル・システムに比べて動作が高速であり、RAWデバイスよりも管理が容易です。ASMを使用すると、Oracle RACを備えたシステム上でもOracle RACを備えていないシステム上でも、アナリティック・ワークスペースのパフォーマンスが最適化されます。
ただし、Oracle OLAPを使用する上でASMは必須ではありません。次の例のように表領域を定義すれば、複数のディスク間にデータを分散させることは可能です。
CREATE TABLESPACE glo DATAFILE
'disk1/oradata/glo1.dbf' SIZE 64M REUSE AUTOEXTEND ON NEXT 8M MAXSIZE 1024M
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
ALTER TABLESPACE glo ADD DATAFILE
'disk2/oradata/glo2.dbf' SIZE 64M REUSE AUTOEXTEND ON NEXT 8M MAXSIZE 1024M,
'disk3/oradata/glo3.dbf' SIZE 64M REUSE AUTOEXTEND ON NEXT 8M
MAXSIZE UNLIMITED;
Oracle Databaseのデータ・ディクショナリ・ビューとシステム表には、アナリティック・ワークスペースに関する広範な情報が格納されています。
データベースのデータ・ディクショナリの静的ビューには、アナリティック・ワークスペースに関する情報を提供するものがあります。表7-2にそれらの簡単な説明を示します。すべてのデータ・ディクショナリ・ビューには、対応するDBAビューとUSERビューがあります。
表7-2 OLAPの静的データ・ディクショナリ・ビュー
| ビュー | 説明 |
|---|---|
|
現在のユーザーがアクセス可能なすべてのアナリティック・ワークスペースを示す。 |
|
|
現在のユーザーがアクセス可能なすべてのアナリティック・ワークスペース内の現在のオブジェクトを示す。 |
|
|
現在のユーザーがアクセス可能なすべてのアナリティック・ワークスペースで定義されているプロパティを示す。 |
|
|
現在のユーザーがアクセス可能なすべてのアナリティック・ワークスペースによって現在使用されているページ領域を示す。 |
|
参照:
|
SYSユーザーは、アナリティック・ワークスペースに関連付けられた複数の表を所有します。表7-3に簡単な説明を示します。
|
重要: これらの表はOracle OLAPの操作に必須です。これらの表を削除または変更した場合の影響を十分に理解していない場合は、削除したり直接変更しないでください。 |
表7-3 SYSが所有するOLAP表
アナリティック・ワークスペースはOracleデータベース内の表に格納されます。これらの表の名前は、常にAW$で始まります。
たとえば、GLOBALユーザーがFINANCIALSとMARKETINGという2つのアナリティック・ワークスペースを作成すると、次の表がGLOBALスキーマに作成されます。
AW$FINANCIALS AW$MARKETING
これらの表には、すべてのオブジェクト定義およびデータが格納されます。
Analytic Workspace Managerを使用してデータをキューブまたはディメンションに初めてロードした時点で、いくつかのログが作成されます。これらのログはアナリティック・ワークスペースと同じスキーマ内の表に格納されます。
キューブ作成ログ: 作成中の実行内容に関する情報が書き込まれます。このログを使用して、期待どおりの作成結果が得られたかどうか、得られなかった場合は、その理由を確認できます。このログは、Analytic Workspace Manager、データベース・マテリアライズド・ビュー・リフレッシュ・サブシステム、またはPL/SQLプロシージャによりキューブまたはディメンションがリフレッシュされると、そのたびに継続して更新されます。作成の進行状況を評価し、完了する時間を推測するために、いつでもログに問い合せることができます。この表のデフォルト名は、CUBE_BUILD_LOGです。
キューブ・ディメンション・コンパイル・ログ: OLAPでキューブを集計する際に、ディメンション階層の検証中に発生したエラーが書き込まれます。この表のデフォルト名は、CUBE_DIMENSION_COMPILEです。
キューブ操作ログ: すべてのOLAPエンジン・イベントに関するメッセージおよびデバッグ情報が書き込まれます。この表のデフォルト名は、CUBE_OPERATIONS_LOGです。
キューブ拒否レコード・ログ: 予測された形式に適合しなかったために拒否されたレコードを確認できます。この表のデフォルト名は、CUBE_DIMENSION_COMPILEです。
これらのログを使用すると、長時間実行されているプロセスの進行状況を追跡し、その結果を使用してパフォーマンスの特徴をプロファイルできます。これらのログから、キューブの作成中やメンテナンス中に発生する可能性がある問題を診断して、問題の解決に役立つ情報が得られます。また、キューブに問い合せる際のパフォーマンスの問題の診断にも役立ちます。
$ORACLE_HOME/olap/admin/utlolaplog.sqlスクリプトを実行すると、いくつかの便利なビューとともに作成ログを作成することもできます。
Analytic Workspace Managerのメンテナンス・ウィザードでは、それぞれの作成処理の進行中に、これらの表の中の関連する行が「メンテナンス・ログ」ページに表示されます。この表には、任意のSQLインタフェースから直接問い合せることができます。
|
参照: 『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_CUBE_LOGエントリに関する項目 |
作成やメンテナンスに要する時間を短縮するため、キューブは原則としてパーティション化されます。パーティション化されたキューブの作成については、「パーティション化方法の選択」を参照してください。
現在のパーティションを確認するには、ALL_CUBESデータ・ディクショナリ・ビューに対して問合せを行います。PARTITION_DIMENSION_NAME、PARTITION_HIERARCHY_NAMEおよびPARTITION_LEVEL_NAMEの各列に、パーティション化情報が表示されます。たとえば次の問合せにより、Unitsキューブが、Timeディメンション、Calendar階層およびCalendar Yearレベルでパーティション化されていることがわかります。
SELECT partition_dimension_name, partition_hierarchy_name,
partition_level_name FROM all_cubes
WHERE owner='GLOBAL' AND cube_name='UNITS_CUBE';
PARTITION_DIMENSION_NAME PARTITION_HIERARCHY_NAME PARTITION_LEVEL_NAME
------------------------- ------------------------- --------------------
TIME CALENDAR CALENDAR_YEAR
OLAPエンジンでは、パーティション化ディメンションのメンバーの追加または削除に伴い、パーティションの作成や削除がデータ・メンテナンスの一環として自動的に行われます。
たとえば、サンプルのGlobalアナリティック・ワークスペースにおいて、Unitsキューブが、Timeディメンション、Calendar階層およびCalendar Quarterレベルでパーティション化されているとします。OLAPエンジンでは、各Calendar Quarterおよびその子に対してパーティションが作成されます。デフォルトの最上位パーティションには、Calender YearおよびFiscal階層のすべてのメンバーが含まれます。Globalに3年分のデータがある場合、Unitsキューブには、1つのCalender Yearにつき4つある最下位パーティションに最上位パーティションを加えた、計13のパーティションが含まれます。
通常、データがリフレッシュされると、期間が新たに作成されて古い期間は削除されます。Calendar Quarter値がTimeディメンションにロードされると、そのたびに対応するパーティションがキューブに追加されます。また、Calendar Quarter値がTimeディメンションから削除されると、そのたびに対応する空のパーティションがキューブから削除されます。
パラレル処理を有効にすると、データ・メンテナンスのパフォーマンスを向上させることができます。パラレル化には、次に示す2つのレベルがあります。
パラレル・ジョブ実行: データのロードおよび集計を、複数のプロセスを使用して行います。
パラレル更新: 一時表領域から永続表領域へのデータの移動を、複数のプロセスを使用して行います。
パラレルに集計可能なオブジェクトの数。キューブおよびパーティション（最上位パーティションを含む）ごとに、別々のプロセスを使用できます。
キューブ内のパーティションの数は、Analytic Workspace Managerのキューブ・プロパティ・シートにある「パーティショニング」タブで制御できます。
当該ユーザーが実行を許可されている同時データベース・プロセスの数。
この数は、JOB_QUEUE_PROCESSESパラメータで制御されます。SYS権限を持っている場合、このパラメータの現在の設定は次のSQLコマンドで確認できます。
SHOW PARAMETER JOB_QUEUE_PROCESSES
パラレル更新の場合は、ジョブに割り当てるプロセスの数。プロセスの数は、Analytic Workspace Managerのメンテナンス・ウィザードでタスク処理オプションを指定する際や、キューブの「マテリアライズド・ビュー」タブで指定できます。
リレーショナル・ソース表から行をフェッチするために、SQLに割り当てるプロセスの数。PARALLEL_DEGREE_POLICYがAUTOまたはLIMITEDに設定されている場合は、SQL文の実行用に追加のプロセスが自動的に割り当てられます。
ここで、TimeディメンションのQuarterレベルでパーティション化され、3年分のデータが含まれているキューブを考えます。このキューブには3×4=12のパーティションがあり、JOB_QUEUE_PROCESSESは8に設定されています。このとき、作成に対するパラレル化オプションを4に設定します。Oracle Databaseでは、PARALLEL_DEGREE_POLICYがデフォルト値のMANUALに設定されている場合に、次の方法でキューブを処理します。
キューブの各ディメンションのロードと作成を、ただ1つのプロセスを使用して逐次行います。
12の最下位パーティションのロードと作成を、4つのプロセスを使用してパラレルに行います。1つのプロセスが終了すると同時に別のプロセスが開始され、これを繰り返して12あるパーティションの処理が最後まで行われます。
このキューブに対して使用できるプロセスの数は、本来はJOB_QUEUE_PROCESSESに指定されている8ですが、ここでは作成のオプション設定により4に制限されます。
最上位パーティションのロードと作成が行われます。
PARALLEL_DEGREE_POLICYがAUTOまたはLIMITEDに設定されている場合は、指定した数より多くのプロセスが自動的に割り当てられることがあります。
例7-1は、Unitsキューブおよびそのディメンションの作成に関するCUBE_BUILD_LOGの抜粋です。TimeディメンションのCalendar Yearレベルでパーティション化した結果、1998〜2007に対応する10個の最下位パーティションが作成されました。JOB_QUEUE_PROCESSESは2に設定され、作成に対するパラレル化オプションも2に設定されています。このログは、Oracle DatabaseがGlobalを次のように処理したことを示しています。
4個のディメンションを逐次処理する。
Unitsキューブの各パーティションを処理する。
例7-1 Global Unitsキューブの作成ログ
SLAVE_NUMBER STATUS COMMAND BUILD_OBJECT PARTITION
------------ ---------- -------------------- --------------- ---------------
0 STARTED BUILD
0 STARTED ATTACH AW RW WAIT
0 COMPLETED ATTACH AW RW WAIT
0 STARTED FREEZE
0 COMPLETED FREEZE
0 STARTED LOAD NO SYNCH TIME
0 SQL LOAD NO SYNCH TIME
.
.
.
0 SQL LOAD NO SYNCH PRODUCT
0 SQL LOAD NO SYNCH PRODUCT
0 COMPLETED LOAD NO SYNCH PRODUCT
0 STARTED COMPILE PRODUCT
0 COMPLETED COMPILE PRODUCT
0 STARTED COMPILE AGGMAP UNITS_CUBE
0 COMPLETED COMPILE AGGMAP UNITS_CUBE
0 STARTED COMPILE AGGMAP PRICE_CUBE
0 COMPLETED COMPILE AGGMAP PRICE_CUBE
0 STARTED UPDATE/COMMIT PRODUCT
0 COMPLETED UPDATE/COMMIT PRODUCT
0 STARTED UPDATE/COMMIT
0 COMPLETED UPDATE/COMMIT
0 STARTED REATTACH AW MULTI TH
AW
0 COMPLETED REATTACH AW MULTI TH
AW
0 STARTED SLAVE UNITS_CUBE P10:CY2007
0 STARTED SLAVE UNITS_CUBE P9:CY2006
1 STARTED BUILD P10:CY2007
1 STARTED ATTACH AW MULTI THAW UNITS_CUBE P10:CY2007
1 COMPLETED ATTACH AW MULTI THAW UNITS_CUBE P10:CY2007
1 STARTED ACQUIRE UNITS_CUBE P10:CY2007
1 COMPLETED ACQUIRE UNITS_CUBE P10:CY2007
1 STARTED LOAD UNITS_CUBE P10:CY2007
1 SQL LOAD UNITS_CUBE P10:CY2007
1 COMPLETED LOAD UNITS_CUBE P10:CY2007
1 STARTED UPDATE/COMMIT UNITS_CUBE P10:CY2007
1 COMPLETED UPDATE/COMMIT UNITS_CUBE P10:CY2007
.
.
.
10 STARTED BUILD P1:CY1998
10 STARTED ATTACH AW MULTI THAW UNITS_CUBE P1:CY1998
10 COMPLETED ATTACH AW MULTI THAW UNITS_CUBE P1:CY1998
10 STARTED ACQUIRE UNITS_CUBE P1:CY1998
10 COMPLETED ACQUIRE UNITS_CUBE P1:CY1998
10 STARTED LOAD UNITS_CUBE P1:CY1998
10 SQL LOAD UNITS_CUBE P1:CY1998
10 COMPLETED LOAD UNITS_CUBE P1:CY1998
10 STARTED SOLVE UNITS_CUBE P1:CY1998
10 COMPLETED SOLVE UNITS_CUBE P1:CY1998
10 STARTED UPDATE/COMMIT UNITS_CUBE P1:CY1998
10 COMPLETED UPDATE/COMMIT UNITS_CUBE P1:CY1998
10 STARTED DETACH AW UNITS_CUBE P1:CY1998
10 COMPLETED DETACH AW UNITS_CUBE P1:CY1998
10 COMPLETED BUILD P1:CY1998
0 COMPLETED SLAVE UNITS_CUBE P1:CY1998
0 STARTED REATTACH AW MULTI TH
AW
0 COMPLETED REATTACH AW MULTI TH
AW
0 STARTED SLAVE UNITS_CUBE P0
11 STARTED BUILD P0
11 STARTED ATTACH AW MULTI THAW UNITS_CUBE P0
11 COMPLETED ATTACH AW MULTI THAW UNITS_CUBE P0
11 STARTED ACQUIRE UNITS_CUBE P0
11 COMPLETED ACQUIRE UNITS_CUBE P0
11 STARTED LOAD UNITS_CUBE P0
11 COMPLETED LOAD UNITS_CUBE P0
11 STARTED SOLVE UNITS_CUBE P0
11 COMPLETED SOLVE UNITS_CUBE P0
11 STARTED UPDATE/COMMIT UNITS_CUBE P0
11 COMPLETED UPDATE/COMMIT UNITS_CUBE P0
11 STARTED DETACH AW UNITS_CUBE P0
11 COMPLETED DETACH AW UNITS_CUBE P0
11 COMPLETED BUILD P0
0 COMPLETED SLAVE UNITS_CUBE P0
0 STARTED REATTACH AW RW WAIT
0 COMPLETED REATTACH AW RW WAIT
0 STARTED ANALYZE UNITS_CUBE
0 COMPLETED ANALYZE UNITS_CUBE
0 STARTED THAW
0 COMPLETED THAW
0 STARTED DETACH AW
0 COMPLETED DETACH AW
0 COMPLETED BUILD
268 rows selected.
Oracle Databaseでは、ジョブのいずれの時点でもすべてのプロセスを同時使用できるかどうかに関係なく、指定された数のプロセスが割り当てられます。たとえば、あるジョブで使用可能なプロセスが最大3個である場合に、5を指定したとします。この場合、そのジョブに割り当てられたプロセスのうちの2個は、そのジョブを含むどのジョブでも使用できません。
Oracle DatabaseとともにReal Application Clusters（Oracle RAC）がインストールされている場合、ジョブ・キューに送られたスクリプトは、クラスタ内のすべてのノードに分散されます。これによりパフォーマンスが著しく向上することがあります。たとえば、あるジョブをクラスタ内の4つのノード上で実行すると、1つのコンピュータ上で実行した場合に比べ、実行速度が最大で4倍になります。
アプリケーションにより、単独のキューブに対して直接問合せが実行される場合は、そのキューブに対してオプティマイザ統計を生成する必要はありません。これらの問合せは、アナリティック・ワークスペース内で自動的に最適化されます。
オプティマイザ統計は、2つのキューブ・ビューを結合する問合せ、または1つのキューブ・ビューを表または表のビューに結合する問合せの実行計画を作成する際に使用します。また、キューブ・マテリアライズド・ビューへのコストベース・リライトを行う際にも使用されます。統計を生成する必要があるのは、こうしたタイプの問合せに対してのみです。
オプティマイザ統計の生成には、DBMS_AW_STATS PL/SQLパッケージを使用します。このパッケージは、キューブ・スクリプトの一部として、またはSQL*PlusなどのSQLインタフェースを使用して、Analytic Workspace Managerで実行できます。統計の生成により、パフォーマンスが大きく低下することはありません。
DBMS_AW_STATSの構文は次のとおりです。
DBMS_AW_STATS.ANALYZE
(object IN VARCHAR2);
引数は、キューブまたはディメンションのどちらかです。例7-2に、Unitsキューブおよびそのディメンションに関する統計を生成するためのサンプル・スクリプトを示します。
例7-2 Unitsキューブに関する統計の生成
BEGIN
DBMS_AW_STATS.ANALYZE('units_cube');
DBMS_AW_STATS.ANALYZE('time');
DBMS_AW_STATS.ANALYZE('customer');
DBMS_AW_STATS.ANALYZE('product');
DBMS_AW_STATS.ANALYZE('channel');
END;
/
統計を直接表示することはできませんが、実行計画を確認することはできます（「実行計画の表示」を参照）。
|
参照: 『Oracle Databaseパフォーマンス・チューニング・ガイド』 |
Oracle Databaseには、パフォーマンス上の問題点を診断するのに役立つ様々なツールが用意されています。これらのツールは、Oracle DBAがデータベースのチューニングを行う上で有用性を発揮します。
Oracle Enterprise Manager Database Control（Database Control）は、汎用データベース管理ツールです。Database Controlを使用すると、ユーザーの追加やデータファイルの変更など基本的な作業を効率化できるだけでなく、データベースの現在のステータスを視覚的に把握できます。またDatabase Controlは、トラブルシューティングやパフォーマンス・チューニング・ユーティリティのインタフェースを備えています。
自動ワークロード・リポジトリでは、分析やチューニングに使用するデータベース・パフォーマンスの統計やメトリックを収集したり、データベースの処理に要した正確な時間の表示やセッション情報の保存を行うことができます。
自動データベース診断モニターでは、データベース・パフォーマンス統計が監視され、これに基づいて、ボトルネックの特定、SQL文の分析、パフォーマンス改善のための提案が行われます。
Oracle Databaseには、パフォーマンス上の問題点を診断するのに役立つ様々なシステム・ビューも用意されています。次の項では、OLAPに特化されたビュー、またはOLAPに関連するデータベース情報を表示するビューについて説明します。
各Oracle Databaseインスタンスは、現行のデータベース・アクティビティを記録する固定表を保持します。これらの表は、内部ディスク構造およびメモリー構造のデータを収集します。その中には、Oracle OLAPのデータを収集する表もあります。
これらの表は、一連の動的パフォーマンス・ビューを介してユーザーが利用できます。これらのビューを監視すると、使用方法の傾向を発見し、システムのボトルネックを診断できます。表7-4に、各ビューの簡単な説明を示します。グローバル動的パフォーマンス・ビュー（GV$）も提供されます。
|
参照: OLAPの動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
表7-4 OLAPの動的パフォーマンス・ビュー
| ビュー | 説明 |
|---|---|
|
アナリティック・ワークスペースで使用可能な集計演算子を表示する。 |
|
|
アナリティック・ワークスペースで使用可能な割当て演算子を表示する。 |
|
|
キャッシュ領域の使用状況および動的集計のステータスに関する情報を収集する。 |
|
|
SQLフェッチに関するステータス情報を収集する。 |
|
|
各アクティブ・セッションに関する情報を収集する。 |
|
|
アクティブなアナリティック・ワークスペースの状態に関する情報を収集する。 |
表7-5は、OLAPに特化してはいないものの、データベースをOLAP用にチューニングする際に使用することが推奨されるその他の動的パフォーマンス・ビューを示したものです。
次に示す問合せは、データ・ディクショナリからOLAP情報を抽出します。DBAビューを問い合せるには、その権限が付与されたアカウントを持っている必要があります。
より複雑な問合せは、スクリプト形式で用意されており、Oracle Technology NetworkのOracle OLAP Webサイトからダウンロードできます。これらのスクリプトおよびダウンロード手順については、「OLAP DBAスクリプト」を参照してください。
OLAPオプションは、Oracle Database Enterprise Editionで提供されます。OLAPコンポーネントがインストールされていることを確認するには、次のSQLコマンドを発行します。
SELECT comp_name, version, status FROM DBA_REGISTRY
WHERE comp_name LIKE '%OLAP%';
COMP_NAME VERSION STATUS
------------------------ ------------------------------ -----------
OLAP Analytic Workspace 11.2.0.1.0 VALID
Oracle OLAP API 11.2.0.1.0 VALID
OLAP Catalog 11.2.0.1.0 VALID
DBA_AWSビューは、すべてのアナリティック・ワークスペースに関する情報を提供します。アナリティック・ワークスペースの名前、所有者およびバージョンのリストを取得するには、次のSQLコマンドを使用します。
SELECT owner, aw_name, aw_version FROM DBA_AWS; OWNER AW_NAME AW_VERSION ---------- ------------------------------ ---------- SYS EXPRESS 11.2 GLOBAL GLOBAL 11.2 SYS AWCREATE 11.2 SH SH 11.2 SYS AWMD 11.2 SYS AWXML 11.2 SYS AWREPORT 11.2 SYS AWCREATE10G 11.2
特定のアナリティック・ワークスペースの表領域エクステントのサイズ（単位はバイト）を確認するには、次のSQL文を使用します。ただし、GLOBALは、対象のアナリティック・ワークスペースの名前に置き換えます。
SELECT extnum, SUM(dbms_lob.getlength(awlob)) bytes FROM global.aw$global
GROUP BY extnum;
EXTNUM BYTES
---------- ----------
0 191776956
アナリティック・ワークスペースが格納されているLOB表のサイズを確認するには、次のようなSQLコマンドを使用します。ただし、GLOBAL.AW$GLOBALは、アナリティック・ワークスペースの修飾名に置き換えます。
SELECT ROUND(SUM(dbms_lob.getlength(awlob))/1024,0) kb
FROM global.aw$global;
KB
----------
187282
DBA_OBJECTSビューは、データベースでのオブジェクトの作成日時を提供します。次のSQLコマンドでは、アナリティック・ワークスペースに関してわかりやすいレポートが生成されます。
SELECT owner, object_name, created, status FROM dba_objects
WHERE object_name LIKE 'AW$%' AND object_name!='AW$'
GROUP BY owner, object_name, created, status
ORDER BY owner, object_name;
OWNER OBJECT_NAME CREATED STATUS
---------- --------------- --------- -------
GLOBAL AW$GLOBAL 01-APR-09 VALID
SYS AW$AWCREATE 26-MAR-09 VALID
SYS AW$AWCREATE10G 26-MAR-09 VALID
SYS AW$AWMD 26-MAR-09 VALID
SYS AW$AWREPORT 26-MAR-09 VALID
SYS AW$AWXML 26-MAR-09 VALID
SYS AW$EXPRESS 26-MAR-09 VALID
7 rows selected.
SQLスクリプトがいくつか含まれたファイルを、Oracle Technology NetworkのOracle OLAP Webサイトからダウンロードできます。通常これらのスクリプトは、複数のシステム・ビューから情報を抽出し、データベースの監視やチューニングに利用できるレポートを生成します。このファイルは次のURLからダウンロードできます。
http://www.oracle.com/technology/products/bi/olap/olap_dba_scripts.zip
表7-6は、これらのスクリプトに関する説明をまとめたものです。詳細は、スクリプトに付随しているREADMEファイルを参照してください。
表7-6 OLAP DBAスクリプト
| SQLスクリプト | 説明 |
|---|---|
|
|
アナリティック・ワークスペースに関連のあるバッファ・キャッシュ内のオブジェクトを識別する。 |
|
|
一時表領域および永続表領域からの読込み数、キャッシュへの書込み数、およびアナリティック・ワークスペースで処理された行の数を集計する。 |
|
|
各アナリティック・ワークスペースによって使用されているディスク領域の量を表示する。 |
|
|
アナリティック・ワークスペースによって使用されている表領域に関する広範囲の情報を提供する。 |
|
|
アナリティック・ワークスペースのユーザーを識別する。 |
|
|
この1時間にアナリティック・ワークスペースのユーザーに対して発生した待機イベントを示す。 |
|
|
バッファ・キャッシュのヒット率を計算する。 |
|
|
オープン・カーソルの数を制限するデータベース・パラメータの設定が低すぎないかどうかを示す。 |
|
|
使用されているPGAのサイズ、OLAPページ・プールのサイズ、および各ユーザーのOLAPページのヒット/ミス率を特定する。 |
|
|
アナリティック・ワークスペースで処理を行うためにOLAPページ・プールによって消費されているPGAのサイズを特定する。 |
|
|
各オープン・セッションのUGA、PGAおよびカーソルの使用状況を識別する。 |
|
|
共有プールのヒット率を計算する。 |
「OLAP DBAスクリプト」のリストに表示されているスクリプトの中には、OLAPセッションにおけるメモリーなどのデータベース・リソースの使用状況について、詳細情報を表示できるものがあります。これらのスクリプトをそのまま使用することもできますが、それらを基にして独自のスクリプトを作成することもできます。
例7-3に、session_resourcesスクリプトにより戻された情報を示します。ここには、カーソル、PGAおよびUGAの使用状況がリスト表示されています。
例7-3 セッション・リソースの問合せ
@session_resources
USERNAME NAME VALUE
-------------------- ------------------------------ ----------
GLOBAL:86 opened cursors cumulative 621
opened cursors current 18
session cursor cache count 50
session cursor cache hits 432
session pga memory 5356368
session pga memory max 10468176
session stored procedure space 0
session uga memory 4230692
session uga memory max 7049780
9 rows selected.
「OLAP DBAスクリプト」のリストに表示されているスクリプトの中には、アナリティック・ワークスペースにおけるディスク領域の使用状況について、詳細情報を表示できるものがあります。例7-4に、aw_sizeスクリプトにより戻された情報を示します。ここには、データベース内のアナリティック・ワークスペース、それらが消費するディスク領域、およびそれらが格納されている表領域がリスト表示されています。
例7-4 アナリティック・ワークスペースにおけるディスク領域の使用状況の問合せ
@aw_size
Analytic Workspace On Disk MB Tablespace
---------------------------------------- --------------- --------------------
GLOBAL.GLOBAL 249.31 GLOBAL
SYS.AWCREATE 7.81 SYSAUX
SYS.AWCREATE10G 1.63 SYSAUX
SYS.AWMD 8.00 SYSAUX
SYS.AWREPORT 1.63 SYSAUX
SYS.AWXML 18.00 SYSAUX
SYS.EXPRESS 2.25 SYSAUX
---------------
Total Disk: 288.63
7 rows selected.
アナリティック・ワークスペースは、データベースのその他の対象と同じツールやプロシージャを使用してバックアップおよびリカバリできます。
Oracle Recovery Manager（RMAN）は、バックアップおよびリカバリについて、処理を簡素化あるいは自動化し、パフォーマンスを向上させる強力なツールです。RMANを使用すると、ワンタイム・バックアップ構成やバックアップの自動管理を行えるだけでなく、ユーザー指定のリカバリ期間に基づくアーカイブ・ログを使用できます。また、再開可能なバックアップ/リストアや、テスト・リストア/リカバリを実行することもできます。
RMANには、バックアップの有効期限を制御するリカバリ期間が実装されています。これにより、論理エラーを検出し、データベースまたは表領域のポイント・イン・タイム・リカバリにより該当オブジェクトを修正することが可能な期間を指定できます。またRMANでは、リカバリ期間のある時点までデータベースをリストアするのに必要がなくなったバックアップは、自動的に無効となります。また、RMANリポジトリが使用できない場合でも、制御ファイルの自動バックアップによりデータベースのリストアやリカバリを行うことができます。
アナリティック・ワークスペースは、別のコンピュータ上にレプリケートする場合やバックアップする場合には、様々な方法でコピーできます。
データ・ポンプ。アナリティック・ワークスペースは、スキーマ内の他のオブジェクト、またはデータベース・エクスポートとともにコピーされます。データベース・ユーティリティのexpdp/impdpを使用します。
|
ヒント: インポート先のスキーマにOLAP_XS_ADMIN権限が付与されていることを確認します。この権限が付与されていない場合は、必要な権限を持つアナリティック・ワークスペースが作成されません。 |
トランスポータブル表領域。アナリティック・ワークスペースは、他のオブジェクトとともにトランスポータブル表領域にコピーされます。ただし、OLAP DECIMALデータ型はハードウェアに依存するため、表領域のトランスポート先は同じプラットフォームに限られます（LinuxからLinux、SolarisからSolaris、WindowsからWindowsなど）。データベース・ユーティリティのexpdp/impdbを使用します。トランスポータブル表領域は、ダンプ・ファイルよりもはるかに高速です。
XMLテンプレート。テンプレートに、アナリティック・ワークスペース内にあるオブジェクトのXML定義が保存されます。アナリティック・ワークスペース全体を保存することも、キューブ、ディメンションおよび計算済メジャーを個々に保存することもできます。保存したテンプレートを使用すると、既存のものとまったく同じアナリティック・ワークスペースを作成できます。テンプレートには、データや、アナリティック・ワークスペースに対するカスタマイズ内容は保存されません。テンプレートは別のプラットフォームにコピーできます。
アナリティック・ワークスペースの所有者は、XMLテンプレートの作成と、スキーマのダンプ・ファイルへのエクスポートを行うことができます。データベース全体をエクスポートしたりトランスポータブル表領域を作成したりできるのは、EXP_FULL_DATABASE権限のあるユーザーまたは特権ユーザー（SYSユーザーやDBAロールを持つユーザーなど）のみです。
|
参照:
|
作成時にマテリアライズド・ビューの機能を使用して拡張したOracle OLAPキューブを、キューブ・マテリアライズド・ビューといいます。
データ・ディクショナリには、マテリアライズド・ビューに関する情報を提供する様々な静的ビューが用意されています。これらのビューには、キューブ・マテリアライズド・ビューがその他すべてのマテリアライズド・ビューと一緒にリスト表示されます。
|
参照: データ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
USER_MVIEWSでは、現在のユーザーが所有するマテリアライズド・ビューが各行に1つずつ表示されます。次の問合せを行うと、GLOBALユーザーが所有するマテリアライズド・ビューがリスト表示されます。各キューブ・マテリアライズド・ビューは、接頭辞CB$により識別されます。
SELECT mview_name, refresh_mode "MODE", refresh_method "METHOD",
last_refresh_date "DATE", staleness FROM user_mviews;
MVIEW_NAME MODE METHOD DATE STALENESS
------------------------ -------- -------- --------------- ----------
CB$CUSTOMER_MARKET DEMAND COMPLETE 20-MAR-09 UNKNOWN
CB$CHANNEL_PRIMARY DEMAND COMPLETE 20-MAR-09 UNKNOWN
CB$CUSTOMER_SHIPMENTS DEMAND COMPLETE 20-MAR-09 UNKNOWN
CB$PRODUCT_PRIMARY DEMAND COMPLETE 20-MAR-09 UNKNOWN
CB$TIME_CALENDAR DEMAND COMPLETE 20-MAR-09 UNKNOWN
CB$TIME_FISCAL DEMAND COMPLETE 20-MAR-09 UNKNOWN
CB$UNITS_CUBE DEMAND FORCE 20-MAR-09 UNKNOWN
7 rows selected.
この例は、Analytic Workspace Managerにより定義されたキューブ・マテリアライズド・ビューを、ディメンション階層およびキューブごとにそれぞれ1つずつ示したものです。
Oracle Databaseでは、キューブ・マテリアライズド・ビューのマスター表にログを保持できます。これらのログは、キューブの増分（高速）リフレッシュをサポートしています。リレーショナル・スキーマ・アドバイザにより生成されたスクリプトを使用すると、ファクト表およびディメンション表ごとに、データに対するすべての変更を記録するためのログが作成されます。次の問合せを行うと、GLOBALユーザーが所有するマテリアライズド・ビュー・ログがリスト表示されます。
SELECT master, log_table FROM user_mview_logs; MASTER LOG_TABLE ------------------------------ ------------------------------ CHANNEL_DIM MLOG$_CHANNEL_DIM CUSTOMER_DIM MLOG$_CUSTOMER_DIM PRODUCT_DIM MLOG$_PRODUCT_DIM TIME_DIM MLOG$_TIME_DIM UNITS_FACT MLOG$_UNITS_FACT
Analytic Workspace ManagerまたはPL/SQLパッケージを使用してキューブ・マテリアライズド・ビューのデータ・リフレッシュを開始する方法には、いくつかの選択肢があります。
自動リフレッシュ: キューブの「マテリアライズド・ビュー」タブで、マテリアライズド・ビュー・リフレッシュ・サブシステムの通常のスケジュールを作成できます（「キューブへのマテリアライズド・ビュー機能の追加」を参照）。
メンテナンス・ウィザード: メンテナンス・ウィザードを使用して、キューブ・マテリアライズド・ビューを含めたすべてのキューブおよびディメンションのリフレッシュを行えます。
DBMS_CUBE: DBMS_CUBE PL/SQLパッケージを使用して、すべてのキューブ、キューブ・ディメンションおよびキューブ・マテリアライズド・ビューのリフレッシュを行えます。
DBMS_MVIEW: DBMS_MVIEW PL/SQLパッケージには、キューブ・マテリアライズド・ビューに使用するためのプロシージャがいくつか含まれています。
DBMS_CUBEは、アナリティック・ワークスペースの作成および移入に使用できます。また、キューブ・マテリアライズド・ビューを含めたあらゆるキューブのメンテナンスにも使用できます。
次のコマンドを実行すると、キューブ・マテリアライズド・ビューとして使用されているUNITS_CUBEの完全リフレッシュが開始されます。このコマンドでは、キューブのリフレッシュが行われる前に、古いディメンションがすべて自動的にリフレッシュされます。
EXECUTE dbms_cube.build('GLOBAL.UNITS_CUBE');
USER_MVIEWSからリフレッシュ・メソッドを指定できます（「キューブ・マテリアライズド・ビューの識別」を参照）。
DBMS_MVIEWは、あらゆるタイプのマテリアライズド・ビューのリフレッシュに使用できます。次のリフレッシュ・プロシージャは、キューブ・マテリアライズド・ビューにも使用できます。
REFRESHを使用すると、1つ以上のマテリアライズド・ビューがまとめてリフレッシュされます。
REFRESH_ALL_MVIEWSを使用すると、一定の条件を満たすすべてのマテリアライズド・ビューがリフレッシュされます。
REFRESH_DEPENDENTを使用すると、特定のマスター表に依存し一定の条件を満たすすべてのマテリアライズド・ビューがリフレッシュされます。
ディメンションは、キューブより先にリフレッシュする必要があります。キューブ・マテリアライズド・ビューをリフレッシュする際、それに関連するいずれかのディメンション・マテリアライズド・ビューが失効している場合は、エラーが発生します。DBMS_MVIEWに含まれるプロシージャを使用すると、1回のコールで複数のマテリアライズド・ビューをリフレッシュすることが可能ですが、リフレッシュの順序は保証されません。リフレッシュの順序を制御するには、ディメンション・マテリアライズド・ビューからキューブ・マテリアライズド・ビューに対してDBMS_MVIEW.REFRESHを別々にコールします。
次のコマンドを実行すると、CHANNEL_PRIMARY階層に対してマテリアライズド・ビューのリフレッシュが開始されます。
EXECUTE dbms_mview.refresh('CB$CHANNEL_PRIMARY', 'C');
Analytic Workspace Managerでは、キューブのリフレッシュに使用するメソッドとして、COMPLETE、FASTまたはFORCEを指定できます。FAST_PCT、FAST_SOLVEという追加的な2つのメソッドは、マテリアライズド・ビュー・サブシステムにより起動されます。この2つのメソッドを個別に選択することはできません。
表7-7は、キューブ・マテリアライズド・ビューでサポートされているリフレッシュ・メソッドの説明をまとめたものです。
表7-7 キューブ・マテリアライズド・ビュー用のリフレッシュ・メソッド
| リフレッシュ・メソッド | 説明 |
|---|---|
|
|
キューブを削除後、再作成する。 このオプションでは、ソース表からキューブへのどのような複雑なマッピングでもサポート。 |
|
|
マテリアライズド・ビュー・ログ、またはダイレクト・パス・ロード後のALL_SUMDELTAデータ・ディクショナリ・ビューに基づいて、変更された値のみをロードして再集計する。 リフレッシュされるソースは、元のマップされたソースではなく、マテリアライズド・ビュー・ログに記録されている増分。これらの増分によって、段階的にキューブの再作成が行われる。再集計されるのは、変更された値に影響を受けるセルのみ。 このオプションでは、キューブ・マテリアライズド・ビューに対する単純なマッピングのみをサポート。つまり、マッピングを定義する問合せの中には、式（table.column以外）、ビュー、集計は現れない。
|
|
|
変更されたパーティションのデータのみをロードして再集計する。このメソッドは、ソース表とキューブが同一のディメンションでパーティション化されている場合に最適。
|
|
|
マップされた元のデータソースに基づいて、変更された値のみをロードして再集計する。
このオプションでは、ソース表からキューブへのどのような複雑なマッピングでもサポート。 |
|
|
最適なメソッドを使用して、値をロードして再集計する。
|
FAST SOLVEメソッドが使用されると、作成ログのリストにはCLEAR LEAVESコマンドが表示されます。例7-5に、UNITS_CUBEの作成に関連するCUBE_BUILD_LOGの行を示します。
例7-5 FAST SOLVEリフレッシュが行われたかどうかの確認
SELECT build_object, status, command FROM cube_build_log
WHERE build_object='UNITS_CUBE'
AND build_id=8;
BUILD_OBJECT STATUS COMMAND
------------ ---------- -------------------------
UNITS_CUBE STARTED COMPILE AGGMAP
UNITS_CUBE COMPLETED COMPILE AGGMAP
UNITS_CUBE STARTED UPDATE
UNITS_CUBE COMPLETED UPDATE
UNITS_CUBE STARTED CLEAR LEAVES
UNITS_CUBE COMPLETED CLEAR LEAVES
UNITS_CUBE STARTED LOAD
UNITS_CUBE COMPLETED LOAD
UNITS_CUBE STARTED SOLVE
UNITS_CUBE COMPLETED SOLVE
UNITS_CUBE STARTED UPDATE
UNITS_CUBE COMPLETED UPDATE
UNITS_CUBE STARTED ANALYZE
UNITS_CUBE COMPLETED ANALYZE
14 rows selected.
クエリー・リライトは、マスター表から結果セットを計算するかわりに、問合せを変更してマテリアライズド・ビューのデータを選択する機能です。変換はクライアントに対して完全に透過的であり、変換を行う際、SQL文の中にマテリアライズ・ビューを指定する必要はありません。キューブ・マテリアライズ・ビューの場合、問合せは、スター・スキーマまたはスノーフレーク・スキーマの表またはビューに対する問合せとして記述され、キューブ・マテリアライズ・ビューに対する問合せに変換されます。この変換により、実行時のパフォーマンスが大幅に向上します。
クエリー・リライトには、キューブおよびディメンションに関するオプティマイザ統計が必要です。ある問合せに対してクエリー・リライトが実行されるかどうかは、その実行計画を生成し検証することにより判断できます。
Oracle Databaseでは、次の2つの初期化パラメータを使用してクエリー・リライトが制御されます。
QUERY_REWRITE_ENABLED: データベース全体を対象にクエリー・リライトを有効にするか無効にするかが指定されます。
QUERY_REWRITE_INTEGRITY: クエリー・リライトによりマテリアライズド・ビューとソース・データとの整合性を監視する程度が指定されます。キューブ・マテリアライズド・ビューに対するクエリー・リライトを使用する場合は、trusted設定またはstale tolerated設定を使用することをお薦めします。
キューブ・マテリアライズド・ビューの管理は他のマテリアライズド・ビューの管理と同様に行います。ただし、キューブ・マテリアライズド・ビューはアナリティック・ワークスペースと同じスキーマ内にあることが必要です。ユーザーが自身のスキーマ以外のスキーマにあるマテリアライズド・ビューをリライトするには、GLOBAL QUERY REWRITE権限が必要となります。ただし、所有者の場合は、追加権限なしでどのスキーマからでもマテリアライズド・ビューにアクセスできます。
|
参照:
|
Oracle Databaseには、マテリアライズド・ビューを管理するためのPL/SQLパッケージが数多く用意されています。ただし、キューブ・マテリアライズド・ビューは、パフォーマンスが最も高くなるよう最適化されているため、これらのパッケージの大部分は使用する必要がありません。また設計について、ユーザーが決定すべき事柄もほとんどありません。そのため、キューブ・マテリアライズド・ビューに対しては、DBMS_ADVISORのTUNE_MVIEWプロシージャは無効となっています。
ただし、状況によっては有用性を発揮するパッケージもあります（表7-8を参照）。
表7-8 キューブ・マテリアライズド・ビュー用のPL/SQLパッケージ
| パッケージ | 説明 |
|---|---|
|
|
|
|
|
データ・リフレッシュを実行する。「データ・リフレッシュの開始」を参照。
|
|
|
実行計画を表示する。「実行計画の表示」を参照。 |
