ヘッダーをスキップ
Oracle® Database 2日でデータ・ウェアハウス・ガイド
11g リリース2(11.2)
B56298-04
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

9 データ・ウェアハウスの操作の最適化

この章では、データ・ウェアハウスのパフォーマンスを最適化する方法を説明します。内容は次のとおりです。

システムのオーバーロードの回避

この項では、システムのオーバーロードを識別して回避する方法について説明します。一般的に、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』の説明に従って、自動診断機能である自動データベース診断モニター(ADDM)を使用して、データベースでのパフォーマンスの問題を識別する必要があります。この項では、システムにおけるパフォーマンスの問題を回避する別の方法について、次のとおり説明します。

システム・パフォーマンスの監視

この項では、重要なメトリックを定期的に監視することによりシステムのオーバーロードを回避する方法の詳細を提供します。Oracle Enterprise Managerの「データベース・パフォーマンス」ページを介してこれらのメトリックを監視できます。この項の内容は次のとおりです。

パラレル実行パフォーマンスの監視

この項では、パラレル実行パフォーマンスを監視する方法を説明します。多くのパラレル文がダウングレードされているとします。これは、パフォーマンスの問題を示します。想定よりも低い並列度で文が実行されると大幅に時間がかかり、文がダウングレードされたかどうかによって実行時間が異なります。パラレル文がダウングレードする原因には次のようなものが考えられます。

  • 最初の並列度が高く、低くする必要がある場合。

  • 使用可能なパラレル・サーバーが十分になく、システムがオーバーロードしている場合。

パラレル実行を監視する手順

  1. データベースのホームページで「パフォーマンス」をクリックします。

    「パフォーマンス」ページが表示されます。

  2. ページを下へスクロールします。リンクのリストの下で、「PQ」をクリックします。

    「PQ」ページが表示されます。次の項目に対してパラレル問合せのパフォーマンス特性が表示されます。

    • パラレル・セッション

    • パラレル・スレーブ

    • DMLおよびDDLのパラレル化

    • シリアライズおよび文のダウングレード

図9-1 パラレル実行の監視

図9-1の説明が続きます
「図9-1 パラレル実行の監視」の説明

I/Oの監視

この項では、I/Oパフォーマンスを監視する方法を説明します。システムのスループットがシステム構成に基づいて予想していたものより大幅に低く(第2章「データ・ウェアハウス・システムの設定」を参照)、ユーザーがパフォーマンスに関して不満がある場合は、パフォーマンスに問題があると考えられます。適切に構成されたシステムで通常のデータ・ウェアハウス・ワークロードを処理する場合、単一のI/Oブロックに対して、おおむね良好なI/Oと、比較的短い待ち時間(30ミリ秒以下)を期待できます。

I/Oパフォーマンス監視する手順

  1. データベースのホームページで「パフォーマンス」をクリックします。

    「パフォーマンス」ページが表示されます。

  2. ページを下へスクロールします。リンクのリストの下で、「I/O」をクリックします。

    I/Oページが表示され、「ファンクションごとのI/O MB/秒」と「ファンクションごとのI/Oリクエスト数/秒」が表示されます。

  3. 読取り/書込み操作に関する詳細は、「I/Oタイプ」を選択します。

    次の項目に対してI/O詳細が表示されます。

    • 大規模の書込み

    • 大規模の読取り

    • 小規模の書込み

    • 小規模の読取り

データベース・リソース・マネージャの使用

Database Resource Managerを使用すると、Oracleシステム内の作業に優先順位を設定できます。たとえば、優先度の高いジョブのあるユーザーは、オンライン作業のレスポンス時間を最短に抑えるためにリソースを取得する一方、バッチ・ジョブやレポートなどの優先度の低いジョブのあるユーザーに対しては、レスポンス時間が遅くなります。このように優先度を割り当てることによってリソースをより細かく制御することができ、コンシューマ・グループに対して、コンシューマ・グループの自動切替え、最大アクティブ・セッションの制御、問合せ実行時間の見積り、UNDOプール割当て制限などの機能が提供されます。

各コンシューマ・グループの同時にアクティブなセッションの最大数を指定できます。この制限に到達した場合、データベース・リソース・マネージャにより、すべての後続のリクエストが並べられ、既存のアクティブ・セッションが完了した後にのみそれらが実行されます。

データベース・リソース・マネージャはOracle Databaseの一部で、データベース内部の異なるプロセスを区別できます。結果として、データベース・リソース・マネージャにより、データベース内部で実行されている個別の操作に優先度を割り当てることができます。

データベース・リソース・マネージャを使用して、次のことを実行できます。

  • システムにかかる負荷およびユーザー数に関係なく、処理リソースの最低量をユーザーに保証します。

  • CPU時間の割合を異なるユーザーおよびアプリケーションに割り当てることにより、使用可能な処理リソースを配分します。データ・ウェアハウスでは、バッチ・ジョブよりもリレーショナル・オンライン分析処理(ROLAP)アプリケーションに対する割当ての方が多くなります。

  • 管理者が定義した基準に基づいて、ユーザーを1つのグループから他のグループに自動的に切り替えます。あるユーザー・グループのメンバーが、指定時間より長くかかるセッションを作成した場合、そのセッションはリソース要件の異なる他のユーザー・グループに自動的に切り替えられます。

  • 特定のリソース割当て方法を使用するようにインスタンスを構成します。この方法は、インスタンスを停止して再起動する必要なく、日中設定から夜間設定などのように動的に変更できます。

索引およびマテリアライズド・ビューの使用の最適化

索引およびマテリアライズド・ビューを使用することにより、データ・ウェアハウスのパフォーマンスを向上させることができます。SQLアクセス・アドバイザの主な利点は、現行のワークロードを推奨事項の基準として使用できることです。

例: SQLアクセス・アドバイザを使用した索引およびマテリアライズド・ビューの使用の最適化

この例では、特定の索引およびマテリアライズド・ビューを利用しているシステムで実行されているワークロードを所有すると仮定します。

索引およびマテリアライズド・ビューを最適化する手順

  1. 「アドバイザ・セントラル」ページから、「SQLアドバイザ」をクリックします。

    「アドバイザ」ページが表示されます。

  2. 「アドバイザ」ページから、「SQLアクセス・アドバイザ」をクリックします。

    「SQLアクセス・アドバイザ」ページが表示されます。

  3. 「デフォルト・オプションを使用」を選択して、「続行」をクリックします。

    「ワークロード・ソース」ページが表示されます。

  4. 「既存のSQLチューニング・セットを使用」をワークロード・ソースとして選択します。SQLチューニング・セットに移動し、「選択」をクリックします。次に、「次へ」をクリックします。

    「推奨オプション」ページが表示されます。

  5. 「索引」「マテリアライズド・ビュー」、および「包括モード」を選択します。「次へ」をクリックします。

    「スケジュール」ページが表示されます。

  6. 「発行」をクリックします。

    「推奨」ページが表示されます。

  7. 「名前」フィールドに名前を入力し、その開始時間として「即時」を選択します。次に、「次へ」をクリックします。

    「確認」ページが表示されます。

  8. 「発行」をクリックします。

    「確認」ページが表示されます。

  9. タスク名を選択し、「結果の表示」をクリックします。

    「推奨」、「SQL文」または「詳細」で追加情報を表示できます。

記憶域要件の最適化

データベース・ブロック内の重複値を排除してアーカイブされたデータを圧縮することにより、記憶域要件を削減できます。圧縮可能なデータベース・オブジェクトには、表およびマテリアライズド・ビューが含まれます。パーティション表については、一部またはすべてのパーティションを圧縮できます。圧縮属性は、表領域、表または表のパーティションに対して宣言できます。表領域レベルで宣言された場合、その表領域で作成されたすべての表はデフォルトで圧縮されます。表(またはパーティションまたは表領域)の圧縮属性は変更可能で、その変更はその表に移動する新規データのみに適用されます。この結果、単一の表またはパーティションにはいくつかの圧縮されたブロックといくつかの通常のブロックが含まれます。これにより、圧縮後もデータのサイズが増加しないことが保証されます。圧縮によってブロックのサイズが増加する場合は、圧縮はそのブロックには適用されません。

データ圧縮による記憶域の改善

いくつかのパーティションを圧縮するか、またはパーティション化されたヒープ構成表を作成できます。これを実行するには、完全なパーティション化された表を圧縮対象の表として定義するか、またはパーティション・レベルごとに定義するか、いずれかの定義を行います。特定の宣言のないパーティションは表定義から属性を継承し、表レベルの指定がない場合は表領域定義から継承します。

パーティションを圧縮するかまたは未圧縮のままにするかについての決定は、パーティション化されていない表と同じルールに従います。データを論理的に個別パーティションに区切る場合はレンジ・パーティション化とコンポジット・パーティション化を使用できるので、パーティション表は、主に読取り専用のデータ(パーティション)の圧縮部分として適切な候補です。たとえばこれは、古いデータが使用不可になる前の中間の段階としてのすべてのローリング・ウィンドウ操作に役立ちます。データを圧縮することにより、より多くの古いデータをオンラインで保持でき、追加的な記憶域使用の負荷を最小化できます。

また、既存の未圧縮の表パーティションを後で変更したり、新規の圧縮パーティションおよび未圧縮パーティションを追加したり、MERGE PARTITIONSPLIT PARTITIONまたはMOVE PARTITIONなどのデータ移動が必要なパーティション・メンテナンス操作の一部として圧縮属性を変更できます。パーティションにはデータを含めることができ、または空にすることもできます。

一部または完全に圧縮されたパーティション表のアクセスおよびメンテナンスは、完全に未圧縮のパーティション表と同じです。また、完全に未圧縮のパーティション表に適用されたすべてのルールも、一部または完全に圧縮されたパーティション表に対して有効です。

データ圧縮を使用する手順

次の例では、1つの圧縮パーティション、costs_oldを使用してレンジ・パーティション化された表を作成します。表の圧縮属性および他のすべてのパーティションは表領域レベルから継承されます。

CREATE TABLE costs_demo (
   prod_id     NUMBER(6),    time_id     DATE, 
   unit_cost   NUMBER(10,2), unit_price  NUMBER(10,2))
PARTITION BY RANGE (time_id)
   (PARTITION costs_old 
       VALUES LESS THAN (TO_DATE('01-JAN-2003', 'DD-MON-YYYY')) COMPRESS,
    PARTITION costs_q1_2003 
       VALUES LESS THAN (TO_DATE('01-APR-2003', 'DD-MON-YYYY')),
    PARTITION costs_q2_2003
       VALUES LESS THAN (TO_DATE('01-JUN-2003', 'DD-MON-YYYY')),
    PARTITION costs_recent VALUES LESS THAN (MAXVALUE));