7 Oracle OLAPの管理
Oracle OLAPはデータベース内にあり、そのリソースは同じツールを使用して管理されるため、Oracle OLAPおよびデータベースの管理は集中して行われます。ただし、データベースのチューニングなど、データ・ウェアハウス固有の作業は行う必要があります。
この章のトピックは、次のとおりです:
7.1 データベース初期化パラメータの設定
表7-1に、Oracle OLAPのパフォーマンスに影響するパラメータを示します。サーバー・パラメータ・ファイルまたはinit.ora
ファイルをこれらの値に変更した後、データベース・インスタンスを再起動します。これらの設定の効果を監視し、必要に応じて設定を調整できます。
関連項目:
-
パラメータ設定のチューニングについては、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
-
個々のパラメータについては、『Oracle Databaseリファレンス』を参照してください。
表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
7.2 ストレージ管理
アナリティック・ワークスペースは、特に指定しないかぎり、所有者のデフォルトの表領域に格納されます。OLAPに使用するすべての表領域には、EXTENT MANAGEMENT LOCAL
が指定される必要があります。デフォルト・パラメータを使用して作成される表領域では、リソースが効率的に使用されないことがあります。格納するアナリティック・ワークスペースにあわせて、UNDO表領域、永続表領域および一時表領域を作成する必要があります。
7.2.1 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
7.2.2 OLAPで使用する永続表領域の作成
各次元オブジェクトは、少なくとも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;
7.2.3 OLAPで使用する一時表領域の作成
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;
7.2.4 ストレージ・リソース間のデータの分散
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;
7.3 ディクショナリ・ビューとシステム表
Oracle Databaseのデータ・ディクショナリ・ビューとシステム表には、アナリティック・ワークスペースに関する広範な情報が格納されています。
7.3.1 静的データ・ディクショナリ・ビュー
データベースのデータ・ディクショナリの静的ビューには、アナリティック・ワークスペースに関する情報を提供するものがあります。表7-2にそれらの簡単な説明を示します。すべてのデータ・ディクショナリ・ビューには、対応するDBA
ビューとUSER
ビューがあります。
表7-2 OLAPの静的データ・ディクショナリ・ビュー
ビュー | 説明 |
---|---|
|
現在のユーザーがアクセス可能なすべてのアナリティック・ワークスペースを示す。 |
現在のユーザーがアクセス可能なすべてのアナリティック・ワークスペース内の現在のオブジェクトを示す。 |
|
現在のユーザーがアクセス可能なすべてのアナリティック・ワークスペースで定義されているプロパティを示す。 |
|
現在のユーザーがアクセス可能なすべてのアナリティック・ワークスペースによって現在使用されているページ領域を示す。 |
関連項目:
-
OLAPのディメンション・オブジェクトを説明するデータ・ディクショナリ・ビューのリストは、「データ・ディクショナリの問合せ」を参照してください
-
すべてのデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
7.3.2 システム表
SYS
ユーザーは、アナリティック・ワークスペースに関連付けられた複数の表を所有します。
注意:
これらの表はOracle OLAPの操作に必須です。これらの表を削除または変更した場合の影響を十分に理解していない場合は、削除したり直接変更しないでください。
表7-3 SYSが所有するOLAP表
表 | 説明 |
---|---|
|
データベースの全アナリティック・ワークスペースのレコードを保持し、その名前や所有者などの情報を記録する。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
アナリティック・ワークスペースに格納されているオブジェクトを示す。 |
|
プログラム・データを格納。現在は使用されていません。 |
|
アナリティック・ワークスペース・オブジェクトのプロパティを格納。 |
|
集計セルへのアクセスに関するトラッキング・データを格納。現在は使用されていません。 |
|
すべてのページ領域の履歴を保持。ページ領域は順序付けられた一連のバイトで、ファイルに相当する。Oracle OLAPは、アナリティック・ワークスペース・ページのキャッシュを管理する。ページは表の記憶域から読み込まれ、問合せへの応答でキャッシュに書き込まれる。複数のセッションで同じページにアクセスすることも可能。
|
7.3.4 メンテナンス・ログ
Analytic Workspace Managerを使用してデータをキューブまたはディメンションに初めてロードした時点で、いくつかのログが作成されます。これらのログはアナリティック・ワークスペースと同じスキーマ内の表に格納されます。
-
キューブ作成ログ: 作成中の実行内容に関する情報が書き込まれます。このログを使用して、作成により予測どおりの結果が得られたかどうか、得られなかった場合は、その理由を確認できます。このログは、Analytic Workspace Manager、データベース・マテリアライズド・ビュー・リフレッシュ・サブシステム、またはPL/SQLプロシージャによりキューブまたはディメンションがリフレッシュされると、そのたびに継続して更新されます。作成の進行状況を評価し、完了する時間を推測するために、いつでもログに問い合せることができます。この表のデフォルト名は、
CUBE_BUILD_LOG
です。 -
キューブ・ディメンション・コンパイル・ログ: OLAPでキューブを集計する際に、ディメンション階層の検証中に発生したエラーが書き込まれます。この表のデフォルト名は、
CUBE_DIMENSION_COMPILE
です。 -
キューブ操作ログ: すべてのOLAPエンジン・イベントに関するメッセージおよびデバッグ情報が書き込まれます。この表のデフォルト名は、
CUBE_OPERATIONS_LOG
です。 -
キューブ拒否レコード・ログ: 予測された形式に適合しなかったために拒否されたレコードを確認できます。この表のデフォルト名は、
CUBE_REJECTED_RECORDS
です。
これらのログを使用すると、長時間実行プロセスの進行状況を追跡し、結果を使用してパフォーマンスの特徴をプロファイルできます。これらのログから、キューブの作成中やメンテナンス中に発生する可能性がある問題を診断して、問題の解決に役立つ情報が得られます。また、キューブに問い合せる際のパフォーマンスの問題の診断にも役立ちます。
$ORACLE_HOME/olap/admin/utlolaplog.sqlスクリプトを実行すると、いくつかの便利なビューとともに作成ログを作成することもできます。
Analytic Workspace Managerのメンテナンス・ウィザードでは、それぞれの作成処理の進行中に、これらの表の中の関連する行が「メンテナンス・ログ」ページに表示されます。この表には、任意のSQLインタフェースから直接問い合せることができます。
関連項目:
『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_CUBE_LOG
に関する項
7.4 パーティション化されたキューブとパラレル化
作成やメンテナンスに要する時間を短縮するため、キューブは原則としてパーティション化されます。パーティション化されたキューブの作成については、「キューブのパーティション化」を参照してください。パーティション化とパラレル化については、次のトピックで説明します。
7.4.1 キューブのパーティション化に関するメタデータの問合せ
現在のパーティションを確認するには、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
7.4.2 パーティションの作成と削除
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ディメンションから削除されると、そのたびに対応する空のパーティションがキューブから削除されます。
7.4.3 パラレル化
パラレル処理を有効にすると、データ・メンテナンスのパフォーマンスを向上させることができます。パラレル化には、次に示す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 Global Unitsキューブの作成ログ
この例は、Unitsキューブおよびそのディメンションの作成に関するCUBE_BUILD_LOG
の抜粋です。TimeディメンションのCalendar Yearレベルでパーティション化した結果、1998から2007に対応する10個の最下位パーティションが作成されました。JOB_QUEUE_PROCESSES
は2に設定され、作成に対するパラレル化オプションも2に設定されています。このログは、Oracle DatabaseがGlobalを次のように処理したことを示しています。
-
4個のディメンションを逐次処理する。
-
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データベースでは、ジョブの任意の時点ですべてのプロセスを同時に使用できるかどうかに関係なく、指定したプロセス数が割り当てられます。たとえば、あるジョブで使用可能なプロセスが最大3個である場合に、5を指定したとします。この場合、そのジョブに割り当てられたプロセスのうちの2個は、そのジョブを含むどのジョブでも使用できません。
Oracle DatabaseとともにReal Application Clusters(Oracle RAC)がインストールされている場合、ジョブ・キューに送られたスクリプトは、クラスタ内のすべてのノードに分散されます。これによりパフォーマンスが著しく向上することがあります。たとえば、あるジョブをクラスタ内の4つのノード上で実行すると、1つのコンピュータ上で実行した場合に比べ、実行速度が最大で4倍になります。
7.5 キューブおよびディメンションの分析
アプリケーションにより、単独のキューブに対して直接問合せが実行される場合は、そのキューブに対してオプティマイザ統計を生成する必要はありません。これらの問合せは、アナリティック・ワークスペース内で自動的に最適化されます。
オプティマイザ統計情報は、2つのキューブ・ビューを結合する問合せ、またはキューブ・ビューを表または表のビューに結合する問合せの実行計画を作成するために使用されます。また、キューブ・マテリアライズド・ビューへのコストベース・リライトを行う際にも使用されます。統計を生成する必要があるのは、こうしたタイプの問合せに対してのみです。
オプティマイザ統計の生成には、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; /
統計を直接表示することはできませんが、実行計画を確認することはできます(「実行計画の表示」を参照)。
7.6 アナリティック・ワークスペースの監視
Oracle Databaseには、パフォーマンス上の問題点を診断するのに役立つ様々なツールが用意されています。これらのツールは、Oracle DBAがデータベースのチューニングを行う上で有用性を発揮します。
-
Oracle Enterprise Manager Cloud Control (Cloud Control)は、汎用データベース管理ツールです。Cloud Controlを使用すると、ユーザーの追加やデータファイルの変更など基本的な作業を効率化できるのみでなく、データベースの現在のステータスを視覚的に把握できます。また、トラブルシューティングやパフォーマンス・チューニング・ユーティリティのインタフェースも備えています。
-
自動ワークロード・リポジトリでは、分析やチューニングに使用するデータベース・パフォーマンスの統計やメトリックを収集したり、データベースの処理に要した正確な時間の表示やセッション情報の保存を行うことができます。
-
自動データベース診断モニターでは、データベース・パフォーマンス統計が監視され、これに基づいて、ボトルネックの特定、SQL文の分析、パフォーマンス改善のための提案が行われます。
Oracle Databaseには、パフォーマンス上の問題点を診断するのに役立つ様々なシステム・ビューも用意されています。次の項では、OLAPに特化されたビュー、またはOLAPに関連するデータベース情報を表示するビューについて説明します。
7.6.1 動的パフォーマンス・ビュー
各Oracle Databaseインスタンスは、現行のデータベース・アクティビティを記録する固定表を保持します。これらの表は、内部ディスク構造およびメモリー構造のデータを収集します。その中には、Oracle OLAPのデータを収集する表もあります。
これらの表は、一連の動的パフォーマンス・ビューを介してユーザーが利用できます。これらのビューを監視すると、使用方法の傾向を発見し、システムのボトルネックを診断できます。表7-4に、各ビューの簡単な説明を示します。グローバル動的パフォーマンス・ビュー(GV$
)も提供されます。
関連項目:
OLAPの動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
表7-4 OLAPの動的パフォーマンス・ビュー
ビュー | 説明 |
---|---|
|
アナリティック・ワークスペースで使用可能な集計演算子を表示する。 |
|
アナリティック・ワークスペースで使用可能な割当て演算子を表示する。 |
|
キャッシュ領域の使用状況および動的集計のステータスに関する情報を収集する。 |
|
SQLフェッチに関するステータス情報を収集する。 |
|
各アクティブ・セッションに関する情報を収集する。 |
|
アクティブなアナリティック・ワークスペースの状態に関する情報を収集する。 |
表7-5は、OLAPに特化してはいないものの、データベースをOLAP用にチューニングする際に使用することが推奨されるその他の動的パフォーマンス・ビューを示したものです。
表7-5 推奨される動的パフォーマンス・ビュー
ビュー | 説明 |
---|---|
|
制御ファイルにあるログ・ファイル情報を表示する。 |
|
REDOログ・ファイルに関する情報を表示する。 |
|
|
|
データ・ディクショナリのアクティビティに関する統計を表示する。1行につき1つのデータ・ディクショナリ・キャッシュの統計情報が示されます。 |
|
システム統計を表示する。 |
7.6.2 OLAPオプションを監視するための基本的な問合せ
次に示す問合せは、データ・ディクショナリからOLAP情報を抽出します。DBAビューを問い合せるには、その権限が付与されたアカウントを持っている必要があります。
より複雑な問合せは、スクリプト形式で用意されており、Oracle Technology NetworkのOracle OLAP Webサイトからダウンロードできます。これらのスクリプトおよびダウンロード手順については、「OLAP DBAスクリプト」を参照してください。
7.6.2.1 OLAPオプションがデータベースにインストールされているかを確認するには
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 12.1.0.1.0 VALID Oracle OLAP API 12.1.0.1.0 VALID OLAP Catalog 12.1.0.1.0 VALID
7.6.2.2 データベースに存在するアナリティック・ワークスペースを確認するには
DBA_AWS
ビューは、すべてのアナリティック・ワークスペースに関する情報を提供します。アナリティック・ワークスペースの名前、所有者およびバージョンのリストを取得するには、次のSQLコマンドを使用します。
SELECT owner, aw_name, aw_version FROM DBA_AWS; OWNER AW_NAME AW_VERSION ---------- ------------------------------ ---------- SYS EXPRESS 12.0 GLOBAL GLOBAL 12.0 SYS AWCREATE 12.0 SH SH 12.0 SYS AWMD 12.0 SYS AWXML 12.0 SYS AWREPORT 12.0 SYS AWCREATE10G 12.0
関連項目:
SYS
が所有するアナリティック・ワークスペースの説明は、「システム表」を参照してください。
7.6.2.3 アナリティック・ワークスペースのサイズを確認するには
特定のアナリティック・ワークスペースの表領域エクステントのサイズ(単位はバイト)を確認するには、次の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
7.6.2.4 アナリティック・ワークスペースの作成日時を確認するには
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 20-SEP-12 VALID SYS AW$AWCREATE 20-SEP-12 VALID SYS AW$AWCREATE10G 20-SEP-12 VALID SYS AW$AWMD 20-SEP-12 VALID SYS AW$AWREPORT 20-SEP-12 VALID SYS AW$AWXML 20-SEP-12 VALID SYS AW$EXPRESS 20-SEP-12 VALID 7 rows selected.
7.6.3 OLAP DBAスクリプト
SQLスクリプトがいくつか含まれたファイルを、Oracle Technology NetworkのOracle OLAP Webサイトからダウンロードできます。通常これらのスクリプトは、複数のシステム・ビューから情報を抽出し、データベースの監視やチューニングに利用できるレポートを生成します。このファイルは次のURLからダウンロードできます。
http://www.oracle.com/technetwork/database/options/olap/olap-dba-scripts-393636.zip
表7-6は、これらのスクリプトに関する説明をまとめたものです。詳細は、スクリプトに付随しているREADME
ファイルを参照してください。
表7-6 OLAP DBAスクリプト
SQLスクリプト | 説明 |
---|---|
|
アナリティック・ワークスペースに関連のあるバッファ・キャッシュ内のオブジェクトを識別する。 |
|
一時表領域および永続表領域からの読込み数、キャッシュへの書込み数、およびアナリティック・ワークスペースで処理された行の数を集計する。 |
|
各アナリティック・ワークスペースによって使用されているディスク領域の量を表示する。 |
|
アナリティック・ワークスペースによって使用されている表領域に関する広範囲の情報を提供する。 |
|
アナリティック・ワークスペースのユーザーを識別する。 |
|
この1時間にアナリティック・ワークスペースのユーザーに対して発生した待機イベントを示す。 |
|
バッファ・キャッシュのヒット率を計算する。 |
|
オープン・カーソルの数を制限するデータベース・パラメータの設定が低すぎないかどうかを示す。 |
|
使用されているPGAのサイズ、OLAPページ・プールのサイズ、および各ユーザーのOLAPページのヒット/ミス率を特定する。 |
|
アナリティック・ワークスペースで処理を行うためにOLAPページ・プールによって消費されているPGAのサイズを特定する。 |
|
各オープン・セッションのUGA、PGAおよびカーソルの使用状況を識別する。 |
|
共有プールのヒット率を計算する。 |
7.6.4 パフォーマンス監視用スクリプト
「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.
7.6.5 ディスク領域の監視
「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.
7.7 アナリティック・ワークスペースのバックアップとリカバリについて
アナリティック・ワークスペースは、データベースのその他の対象と同じツールやプロシージャを使用してバックアップおよびリカバリできます。
Oracle Recovery Manager(RMAN)は、バックアップおよびリカバリについて、処理を簡素化あるいは自動化し、パフォーマンスを向上させる強力なツールです。RMANを使用すると、ワンタイム・バックアップ構成やバックアップの自動管理を行えるのみでなく、ユーザー指定のリカバリ期間に基づくアーカイブ・ログを使用できます。また、再開可能なバックアップ/リストアや、テスト・リストア/リカバリを実行することもできます。
RMANには、バックアップの有効期限を制御するリカバリ期間が実装されています。これにより、論理エラーを検出し、データベースまたは表領域のポイント・イン・タイム・リカバリにより該当オブジェクトを修正することが可能な期間を指定できます。またRMANでは、リカバリ期間のある時点までデータベースをリストアするのに必要がなくなったバックアップは、自動的に無効となります。また、RMANリポジトリが使用できない場合でも、制御ファイルの自動バックアップによりデータベースのリストアやリカバリを行うことができます。
7.8 アナリティック・ワークスペースのコピーについて
アナリティック・ワークスペースは、別のコンピュータ上にレプリケートする場合やバックアップする場合には、様々な方法でコピーできます。
-
データ・ポンプ。アナリティック・ワークスペースは、スキーマ内の他のオブジェクト、またはデータベース・エクスポートとともにコピーされます。データベース・ユーティリティの
expdp
/impdp
を使用します。ヒント:
インポート先のスキーマにOLAP_XS_ADMIN権限が付与されていることを確認します。この権限が付与されていない場合は、必要な権限を持つアナリティック・ワークスペースが作成されません。
-
トランスポータブル表領域。アナリティック・ワークスペースは、他のオブジェクトとともにトランスポータブル表領域にコピーされます。ただし、OLAP
DECIMAL
データ型はハードウェアに依存するため、表領域のトランスポート先は同じプラットフォームに限られます(LinuxからLinux、SolarisからSolaris、WindowsからWindowsなど)。データベース・ユーティリティのexpdp
/impdp
を使用します。トランスポータブル表領域は、ダンプ・ファイルよりもはるかに高速です。
アナリティック・ワークスペースの所有者は、スキーマをダンプ・ファイルにエクスポートできます。データベース全体をエクスポートしたりトランスポータブル表領域を作成したりできるのは、EXP_FULL_DATABASE
権限のあるユーザーまたは特権ユーザー(SYS
ユーザーやDBA
ロールを持つユーザーなど)のみです。
関連項目:
-
XMLテンプレートについては、「オブジェクト定義を使用したディメンション・オブジェクトの保存および再作成」を参照してください
-
Oracle Data Pumpおよび
expdp
/impdp
コマンドについては、『Oracle Databaseユーティリティ』を参照してください。
7.9 次元オブジェクト定義の保存について
オブジェクト定義を外部ファイルに保存することにより、その定義を別のデータベースに送ったり、バックアップ・コピーを保存したりできます。また、オブジェクト定義を表に保存することにより、その定義をOracle Databaseで使用することもできます。定義はXMLテンプレートまたはEIFファイルに保存できます。どちらのファイルもプラットフォームによって使用できない可能性があります。
7.9.1 XMLテンプレートについて
テンプレートは次元オブジェクトが記述されたXML文書です。アナリティック・ワークスペースのすべてのオブジェクトまたは選択したオブジェクトのみのXML定義を保存し、後でそれらのオブジェクトを同一データベースまたは他のコンピュータやプラットフォームのデータベースで再作成できます。テンプレートを使用して、データのディメンション・モデルを開発している間に作業をバックアップしたり、設計を他のユーザーに配布したりできます。
次のタイプのオブジェクトのXML定義を保存できます。
-
アナリティック・ワークスペース: すべてのディメンション・オブジェクト、およびすべてのユーザー定義のOLAP DMLプログラムとオブジェクトが保存されます。
-
ディメンション: ディメンションとそのレベル、階層、属性およびマッピングが保存されます。
-
キューブ: キューブおよびキューブのメジャー、計算済メジャー、ディメンション、マッピング、およびすべてのユーザー定義のOLAP DMLプログラムとキューブに関連付けられたオブジェクトが保存されます。
-
メジャー・フォルダ: メジャー・フォルダ内のメジャーのリストが保存されます。オブジェクトは保存されません。
テンプレートには、データではなくメタデータが格納されます。テンプレートを小さなテキスト・ファイルに格納することも、データベース表に格納することもできます。テンプレートからオブジェクトを再作成する際には、ソース・データにアクセスできる必要があります。
7.9.2 EIFファイルについて
アナリティック・ワークスペースのオブジェクトは、EIFファイルにエクスポートできます。EIFファイルは、アナリティック・ワークスペースをコピーするためにフォーマットされたファイルです。EIFファイルは、次の作業に使用できます。
-
個々のアナリティック・ワークスペースのバックアップ
-
別のデータベースへのアナリティック・ワークスペースのコピー
EIFファイルは、Oracle Databaseリリース間で上位互換性があります。EIFファイルには、OLAP DMLオブジェクト定義だけでなく、データ(オプション)も保存されます。EIFファイルの作成時には、アクセス権のあるデータのみ保存できます。
EIFファイルにはオブジェクト・セキュリティ・ルールは保存されません。
アナリティック・ワークスペースのEIFファイルをエクスポートおよびインポートすることができます。EIFファイルを使用すると、OLAP DMLによって詳細な設定(カスタム・プログラムのみを保存するなど)が可能になります。
7.10 キューブ・マテリアライズド・ビュー
作成時にマテリアライズド・ビューの機能を使用して拡張したOracle OLAPキューブを、キューブ・マテリアライズド・ビューといいます。キューブ・マテリアライズド・ビューについては、次のトピックで説明します。
関連項目:
7.10.1 データ・ディクショナリからの情報の取得
データ・ディクショナリには、マテリアライズド・ビューに関する情報を提供する様々な静的ビューが用意されています。これらのビューには、キューブ・マテリアライズド・ビューがその他すべてのマテリアライズド・ビューと一緒にリスト表示されます。
関連項目:
データ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
7.10.1.1 キューブ・マテリアライズド・ビューの識別
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-SEP-12 UNKNOWN CB$CHANNEL_PRIMARY DEMAND COMPLETE 20-SEP-12 UNKNOWN CB$CUSTOMER_SHIPMENTS DEMAND COMPLETE 20-SEP-12 UNKNOWN CB$PRODUCT_PRIMARY DEMAND COMPLETE 20-SEP-12 UNKNOWN CB$TIME_CALENDAR DEMAND COMPLETE 20-SEP-12 UNKNOWN CB$TIME_FISCAL DEMAND COMPLETE 20-SEP-12 UNKNOWN CB$UNITS_CUBE DEMAND FORCE 20-SEP-12 UNKNOWN 7 rows selected.
この例は、Analytic Workspace Managerにより定義されたキューブ・マテリアライズド・ビューを、ディメンション階層およびキューブごとにそれぞれ1つずつ示したものです。
7.10.1.2 リフレッシュ・ログの識別
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
7.10.2 データ・リフレッシュの開始
Analytic Workspace ManagerまたはPL/SQLパッケージを使用してキューブ・マテリアライズド・ビューのデータ・リフレッシュを開始する方法には、いくつかの選択肢があります。
-
自動リフレッシュ: キューブの「マテリアライズド・ビュー」タブで、マテリアライズド・ビュー・リフレッシュ・サブシステムの通常のスケジュールを作成できます(「キューブへのマテリアライズド・ビュー機能の追加」を参照)。
-
メンテナンス・ウィザード: メンテナンス・ウィザードを使用して、キューブ・マテリアライズド・ビューを含めたすべてのキューブおよびディメンションのリフレッシュを行えます。
-
DBMS_CUBE
:DBMS_CUBE
PL/SQLパッケージを使用して、すべてのキューブ、キューブ・ディメンションおよびキューブ・マテリアライズド・ビューのリフレッシュを行えます。 -
DBMS_MVIEW
:DBMS_MVIEW
PL/SQLパッケージには、キューブ・マテリアライズド・ビューに使用するためのプロシージャがいくつか含まれています。
7.10.2.1 DBMS_CUBEの使用
DBMS_CUBE
は、アナリティック・ワークスペースの作成および移入に使用できます。また、キューブ・マテリアライズド・ビューを含めたあらゆるキューブのメンテナンスにも使用できます。
次のコマンドを実行すると、キューブ・マテリアライズド・ビューとして有効になっているUNITS_CUBE
の完全リフレッシュが開始されます。このコマンドでは、キューブのリフレッシュが行われる前に、古いディメンションがすべて自動的にリフレッシュされます。
EXECUTE dbms_cube.build('GLOBAL.UNITS_CUBE');
USER_MVIEWS
からリフレッシュ・メソッドを指定できます(「キューブ・マテリアライズド・ビューの識別」を参照)。
7.10.2.2 DBMS_MVIEWの使用
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');
7.10.3 リフレッシュ・メソッド
Analytic Workspace Managerでは、キューブのリフレッシュに使用するメソッドとして、COMPLETE
、FAST
またはFORCE
を指定できます。FAST_PCT
、FAST_SOLVE
という追加的な2つのメソッドは、マテリアライズド・ビュー・サブシステムにより起動されます。この2つのメソッドを個別に選択することはできません。
7.10.3.1 リフレッシュ・メソッドの説明
表7-7は、キューブ・マテリアライズド・ビューでサポートされているリフレッシュ・メソッドの説明をまとめたものです。
表7-7 キューブ・マテリアライズド・ビュー用のリフレッシュ・メソッド
リフレッシュ・メソッド | 説明 |
---|---|
|
キューブを削除後、再作成する。 このオプションでは、ソース表からキューブへのどのような複雑なマッピングでもサポート。 |
|
マテリアライズド・ビュー・ログ、またはダイレクト・パス・ロード後のALL_SUMDELTAデータ・ディクショナリ・ビューに基づいて、変更された値のみをロードして再集計する。 リフレッシュされるソースは、元のマップされたソースではなく、マテリアライズド・ビュー・ログに記録されている増分。これらの増分によって、段階的にキューブの再作成が行われる。再集計されるのは、変更された値に影響を受けるセルのみ。 このオプションでは、キューブ・マテリアライズド・ビューに対する単純なマッピングのみをサポート。つまり、マッピングを定義する問合せの中には、式(table.column以外)、ビュー、集計は現れない。
|
|
変更されたパーティションのデータのみをロードして再集計する。このメソッドは、ソース表とキューブが同一のディメンションでパーティション化されている場合に最適。
|
|
マップされた元のデータソースに基づいて、変更された値のみをロードして再集計する。
このオプションでは、ソース表からキューブへのどのような複雑なマッピングでもサポートされる。 |
|
最適なメソッドを使用して、値をロードして再集計する。
|
7.10.3.2 FAST SOLVEリフレッシュ
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.
7.10.4 クエリー・リライトの使用
クエリー・リライトは、マスター表から結果セットを計算するかわりに、問合せを変更してマテリアライズド・ビューのデータを選択する機能です。変換はクライアントに対して完全に透過的であり、変換を行う際、SQL文の中にマテリアライズ・ビューを指定する必要はありません。キューブ・マテリアライズ・ビューの場合、問合せは、スター・スキーマまたはスノーフレーク・スキーマの表またはビューに対する問合せとして記述され、キューブ・マテリアライズ・ビューに対する問合せに変換されます。この変換により、実行時のパフォーマンスが大幅に向上します。
クエリー・リライトには、キューブおよびディメンションに関するオプティマイザ統計が必要です。ある問合せに対してクエリー・リライトが実行されるかどうかは、その実行計画を生成し検証することにより判断できます。
Oracle Databaseでは、次の2つの初期化パラメータを使用してクエリー・リライトが制御されます。
-
QUERY_REWRITE_ENABLED
: データベース全体を対象にクエリー・リライトを有効にするか無効にするかが指定されます。 -
QUERY_REWRITE_INTEGRITY
: クエリー・リライトによりマテリアライズド・ビューとソース・データとの整合性を監視する程度が指定されます。キューブ・マテリアライズド・ビューに対するクエリー・リライトを使用する場合は、trusted
設定またはstale tolerated
設定を使用することをお薦めします。
キューブ・マテリアライズド・ビューの管理は他のマテリアライズド・ビューの管理と同様に行います。ただし、キューブ・マテリアライズド・ビューはアナリティック・ワークスペースと同じスキーマ内にあることが必要です。ユーザーが自身のスキーマ以外のスキーマにあるマテリアライズド・ビューをリライトするには、GLOBAL QUERY REWRITE
権限が必要となります。ただし、所有者の場合は、追加権限なしでどのスキーマからでもマテリアライズド・ビューにアクセスできます。
関連項目:
-
オプティマイザ統計の詳細は、「キューブおよびディメンションの分析」を参照してください
-
実行計画については、「実行計画の表示」を参照してください。
-
初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください
7.10.5 キューブ・マテリアライズド・ビューに関する追加情報の取得
Oracle Databaseには、マテリアライズド・ビューを管理するためのPL/SQLパッケージが数多く用意されています。ただし、キューブ・マテリアライズド・ビューは、パフォーマンスが最も高くなるよう最適化されているため、これらのパッケージの大部分は使用する必要がありません。また設計について、ユーザーが決定すべき事柄もほとんどありません。そのため、キューブ・マテリアライズド・ビューに対しては、DBMS_ADVISOR
のTUNE_MVIEW
プロシージャは無効となっています。
ただし、状況によっては有用性を発揮するパッケージもあります(表7-8を参照)。
表7-8 キューブ・マテリアライズド・ビュー用のPL/SQLパッケージ
パッケージ | 説明 |
---|---|
データ・リフレッシュを実行する。「データ・リフレッシュの開始」を参照。
|
|
実行計画を表示する。「実行計画の表示」を参照。 |