はじめに

この章ではAutonomous Databaseにおける分析系クエリの性能を確認します。

特に、インスタンスのECPU数を増やした前後でのパフォーマンスを比較することで、簡単に性能が向上することをみていきます。

また、SQLの実行状況を確認するために、サービス・コンソールを操作いただきます。

目次


所要時間: 約40分

Star-Schema-Benchmark(SSB)とは?

ADBのインスタンスには、DWH系・分析系のサンプルスキーマとして以下が同梱されています。

  • Oracle Sales History(SHスキーマ)
  • Star Schema Benchmark(SSBスキーマ)

上記のサンプルスキーマの特長

  • 約1TB、約60億行のファクト表と、複数のディメンション表から構成
  • マニュアルには動作確認用のサンプルSQLも記載されている
  • ADW、ATPの双方で利用可能(2022/10時点)- 本ガイドでは前の章で作成したAutonomous Transaction Processing(ATP) インスタンスの利用を前提に記載していますが、SSBのような分析系・DWH系のアプリケーションの場合、Autonomous Data Warehouse(ADW) をご選択いただくことを推奨しています。

※サンプルスキーマの詳細についてはこちらを参照ください。

作業の流れ

  • SSBスキーマを確認しよう
  • ECPU数の違いによる処理時間の差を確認しよう
  • サービスコンソール/SQL Monitorで処理内容を確認しよう


1. SSBスキーマを確認しよう

データ・モデラーによる構成確認

  1. ADBインスタンスを作成しようで学習したDatabase Actionsを利用したインスタンスへの接続 を参照し、Database Actionsを起動し、Adminユーザーで接続してください。ツールタブから、データベース・アクションを開くをクリックしてください。

    画面ショット1-1

  2. Database Actionsのランディングページのデータ・ツールから データ・モデラー を選択し、SSBスキーマの構造を確認していきましょう。

    画面ショット1-1

  3. データ・モデラーのランディングページです。画面左上のナビゲータにSSBと入力し、SSBスキーマの下記の5つの表を確認します。

    • CUSTOMER表
    • DWDATE表
    • LINEORDER表
    • PART表
    • SUPPLIER表

    画面ショット1-1

  4. SSBスキーマの5つの表を画面中央のダイアグラムに追加します。追加方法は下記の2通りあります。

    • 表を右クリックし、オブジェクトをダイアグラムに追加をクリック
    • 表をドラッグ&ドロップで中央に移動する

    画面ショット1-1

  5. SSBスキーマの構造がER図で表示されました。画面中央上のセーブマーク をクリックし、ダイアグラムを保存します。
    ※図が重なってしまっている場合は、ドラッグして適宜移動してみてください。

    画面ショット1-1

  6. ダイアグラム・プロパティの名前(例:SSB diagram)を入力し、OKをクリックします。

    画面ショット1-1

  7. ダイアグラムが保存されました。OK をクリックします。

    画面ショット1-1

  8. 保存したダイアグラム(例:SSB diagram)を確認していきます。画面左上 ナビゲータの隣のダイアグラムタブをクリックします。保存したダイアグラム(例:SSB diagram)を選択後、開くをクリックします。

    画面ショット1-1

  9. 画面右上赤枠のボタンをクリックするとスキーマのDDL文を確認することができます。

    画面ショット1-1

  10. DDL文のプレビューになります。

    画面ショット1-1

  11. 画面右上赤枠のボタンをクリックするとスキーマ・レポートを確認することができます。

    画面ショット1-1

  12. スキーマ・レポートになります。

    画面ショット1-1


各表の件数確認

  1. Database Actionsのランディングページに戻り、データ・ツールからSQL を選択します。

    画面ショット1-1

  2. ワークシートの画面左上からスキーマSSB を選択します。

    画面ショット1-1

  3. 以下のスクリプトを実行して、各表の件数を確認します。

    select count(1) from ssb.dwdate;
    select count(1) from ssb.part;
    select count(1) from ssb.supplier;
    select count(1) from ssb.customer;
    select count(1) from ssb.lineorder;
    

    画面ショット1-1

    以上でSSBスキーマの構成、および各表に含まれる件数が確認できました。DWHとして理想的なスター・スキーマで構成されており、データサイズとしても比較的規模の大きな構成であることがご確認いただけたかと思います。

    次は、ECPU数を変えて、同じSQL文を実行することで、処理の違いを体験していきましょう。


2. ECPU数の違いによる処理時間の差を確認しよう

次にもう少し複雑なクエリを実行してみます。ECPU数を変えることで、高速に処理できることを確認していきましょう。

次のクエリをコピーして、Database Actionsのワークシートに貼り付けて実行してみましょう。
すべてのECPU数で同じクエリを実行します。

   SELECT
      SUM(LO_REVENUE),
      D_YEAR,
      P_BRAND1
   FROM
      SSB.LINEORDER,
      SSB.DWDATE,
      SSB.PART,
      SSB.SUPPLIER
   WHERE
      LO_ORDERDATE = D_DATEKEY
      AND LO_PARTKEY = P_PARTKEY
      AND LO_SUPPKEY = S_SUPPKEY
      AND P_BRAND1 BETWEEN 'MFGR#2221' AND 'MFGR#2228'
      AND S_REGION = 'ASIA'
   GROUP BY
      D_YEAR,
      P_BRAND1
   ORDER BY
      D_YEAR,
      P_BRAND1;

本編ではECPU=2および8の場合を記載しておりますが、ぜひECPU=4や16と変更し、ECPUが大きくなればElaped Timeが短くなることをご確認ください。

注意

ここではECPU数を段階的に増やし、性能が向上することをご確認いただきますが、クレジット消費も比例して大きくなりますので、ご注意ください。

補足

Autonomous Databaseのマニュアルでは、上に記載しているサンプルSQL以外にも動作確認用のサンプルSQLをご用意しております。 こちらを参照ください。


ECPU=2の場合

  1. 画面右上の接続サービスをLOWからMEDIUMに変更し、以下のスクリプトを実行します。

    現在のECPU数は、2です。

    画面ショット1-1

    処理にかかった時間は、00:01:24.915でした。


ECPU=8の場合

  1. ここでATPの詳細画面に遷移し、スケール・アップ/ダウンを選択してください。ECPU数をスケールさせていきます。

    画面ショット1-1

    注意

    自動スケーリングの有無は任意で結構です。
    自動スケーリングは複数のクエリが同時に走っているときにその効果が発揮されます。今回のように1つのクエリを走らせる分には有効にしてもしなくても性能に影響はありません。

  2. ECPU数に8を入力し、更新をクリックしてください。

    画面ショット1-1

    ATPの詳細画面でスケールアップの完了を確認後、Database ActionsのSQLワークシートに戻ります。

  3. 再度クエリを実行します。現在のECPU数は、8です。

    画面ショット1-1

    処理にかかった時間は、00:00:31.736でした。

ここまでで、ECPU=2および8のときのElapsed Timeが確認できたと思います。
Autonomous Databaseでは利用可能なコア数だけでなく、割り当てメモリのサイズやIO帯域もECPU数に比例する形で増加します。今回試したDWH系のクエリは一般的に非常に多くのリソースを消費しますが、Autonomous Databaseでは必要に応じてECPU数を調整することで性能を担保することが可能です。

NOTE

その他、ADBでは、パーティション やHCC圧縮、マテリアライド・ビューといったOracle Database / Exadata のパフォーマンスに寄与する各種オプションも追加費用なくご利用いただけます。

次の表は、ECPU数を細かく増やしていったときのElapsed Timeをまとめたものです。
このようにECPUが大きくなれば性能が向上していることが分かります。

 
接続サービスECPU数 Elapsed Time
MEDIUM 2 00:01:24.915
4 00:00:57.807
8 00:00:31.736
16 00:00:17.409

※Elapsed Timeにはブレがありますので、あくまでも参考値としてご認識ください。


3. 性能調査に使えるツールのご紹介

ここからは実際にADBにて性能調査を行う際にどう言ったツールが利用できるのかをみていきたいと思います。

サービスコンソールおよびパフォーマンスハブでは次のような機能をご利用いただけます。

データベース・ダッシュボード

ADBではインスタンスの稼働状況をDatabase Actionsのデータベース・ダッシュボードを介して確認できます。 データベース・ダッシュボードからは、リソースの利用状況(CPUやストレージは十分か?どのくらい使われているか?等)を確認する時に活用します。

  1. ATPの詳細画面のDatabase Actionsをクリックしてください。

    画面ショット1-1

  2. Database Actionsの起動パッドからデータベース・ダッシュボードをクリックします。

    画面ショット1-1

  3. 概要では、ストレージの使用状況やCPU使用率、その他、実行されたSQL数や平均レスポンス時間等をご確認いただけます。

    画面ショット1-1

  4. モニターを選択します。ここではデータベース内の待機イベントの状況、各接続サービス毎のCPU使用率などを、リアルタイムにご確認いただけます。

    画面ショット1-1

パフォーマンス・ハブ

一方、単一のSQLで時間のかかるものを監視、調査する場合はSQL Monitorが有用です。アプリケーションの性能調査においてポイントとなる、待機イベントの確認やSQL Monitorの確認、AWRの出力はパフォーマンス・ハブを利用することで簡単に確認することができます。

  1. ATPの詳細画面のパフォーマンス・ハブをクリックしてください。

    画面ショット1-1

  2. パフォーマンス・ハブのランディングページです。このページでは、特定の期間に使用可能なすべてのパフォーマンス・データを表示できます。 期間を選択すると、データベースのパフォーマンスが表示されます。ワークシートで実行したSQLを確認するため、SQLモニタリングをクリックします。

    画面ショット1-1

  3. アクティビティ・サマリーの時間指定範囲に目的のSQL文がないため、SQLが見つかりません。画面左上のクイック選択から、任意の期間を選択してください。

    画面ショット1-1

  4. 期間変更後、アクティビティ・サマリー上に多くのCPUを使用している箇所が見られました。アクティビティ・サマリー期間ウィンドウを合わせてください。SQL文が見つかりました。青文字になっているSQL IDをクリックしてください。

    画面ショット1-1

  5. パフォーマンス・ハブ: リアルタイムSQLモニタリングページにて、クリックしたSQLの詳細を確認することができます。

    こちらのページの詳細セクションでは以下のことを確認できます。

    計画統計: 選択したSQLの実行計画

    SQL: 実行したSQL文

    アクティブ・セッション: 選択したSQLのアクティブセッション履歴

    メトリック: 選択したSQLにおけるパフォーマンスを、使用中のCPUメモリーI/OスループットI/Oリクエスト数の観点から確認することが可能です。

    また、画面右上のレポートの保存をクリックすると、AWRレポートをhtml形式でダウンロードすることができ、簡単にブラウザで確認・共有することができます。

    画面ショット1-1

以上で、この章の作業は終了です。


ページトップへ戻る

更新日時: