Forum Stats

  • 3,770,761 Users
  • 2,253,163 Discussions
  • 7,875,579 Comments

Discussions

ADB HOL #5-2 : 分析系クエリの実行

TakeshiNagakubo-Oracle
TakeshiNagakubo-Oracle Posts: 18 Employee
edited May 28, 2021 12:33AM in Social Groups

目次に戻る : チュートリアル : Oracle Cloud Infrastructure を使ってみよう

>ADBコンテンツ一覧に戻る

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

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

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

Star-Schema-Benchmark(SSB)とは?

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

    • Oracle Sales History(SHスキーマ)
    • Star Schema Benchmark(SSBスキーマ)
      • 約1TB、約60億行のファクト表と、複数のディメンション表から構成
      • マニュアルには動作確認用のサンプルSQLも記載されている
      • ATPインスタンスでも利用可能(2020/12時点)

pastedImage_20png


注)本ガイドでは前の章で作成したAutonomous Transaction Processing(ATP) インスタンスの利用を前提に記載していますが、SSBのような分析系・DWH系のアプリケーションの場合、Autonomous Data Warehouse(ADW) をご選択いただくことを推奨しています。


作業の流れ

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

所要時間 : 約20分

1. SSBスキーマの確認


最初に格納されているデータ件数について確認します。

1. Tera Termを起動し、仮想マシンにログインします。

2. oracleユーザに切り替えます。

$ sudo su - oracle

3. 作業用ディレクトリに移動します。

$ cd ~/labs/querySSB

4. ADBインスタンスに接続します。ここでは接続サービスMEDIUMを利用しています。

$ export TNS_ADMIN=/home/oracle/labs/wallets
$ sqlplus admin/Welcome12345#@atp01_medium

5. 1.sqlを実行します。

SQL> @1.sql

    「ORA-56720: I/O data limit exceeded - call aborted」 というエラーが生じた場合は、に戻って、IO使用量の上限を100GBに変更ください。

        (LINEORDER表は10GBを超える表なので、HOL#5-1で設定した10GBという上限に抵触します。)

     以下のように各表の件数が表示されればOKです。

pastedImage_15png

     【補足 : 1.sqlの内容 】

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;

6. SQL*plusを終了します。

SQL> exit


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


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

1.接続サービスMEDIUMを利用して接続します

$ sqlplus admin/Welcome12345#@atp01_medium

2.  ocpu2.sqlを実行します。

SQL> @ocpu2.sql

     結果件数が56件となればOKです。処理時間をメモに控えておいてください。(概ね2分程度で終わることを想定しています。)

   【補足 : ocpu2.sqlの内容 】

select /* MEDIUM OCPU=2 *//*+ NO_RESULT_CACHE */

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
;

      • 大規模なトランザクション表と複数のマスタ表を結合して集計する処理。
      • NO_RESULT_CACHEヒントについて
        • ATPをお使いの場合、特に気にする必要はありません。
        • ADWをお使いの場合、Result Cacheと呼ばれるDWH向けの高速化機能がデフォルトで有効になっています。この機能を使うと同じ結果が得られるSQLについては、その結果をメモリ上に保持しておくことで、次回以降の検索を高速化することが可能です。ただし、本ハンズオンにおいては接続サービス毎の違いを確認したいため、この機能を無効化しています。
      • 「MEDIUM OCPU=2」は、この後に実行するSQLと区別するために記載しています。

3. SQL*plusを終了せず、そのままにしておいてください。

(この後でOCPU数を変えますが、SQL*Plusのセッションは切れず、アプリケーションはオンラインのままであることを確認ください。)

4. OCPU数を2から4に変更します。

4-1. サービス画面からスケール・アップ/ダウンをクリックします。

pastedImage_69png

4-2. OCPU数を2から4に変更し、更新をクリックします。

pastedImage_72png

4-3. ステータスがスケーリング進行中から使用可能になったらスケールアップは完了です。(数分かかりますが、この間セッションは切れません。)

pastedImage_89png

5.  ocpu4.sqlを実行します。

SQL> @ocpu4.sql

     結果件数が56件となればOKです。OCPU=2で実行した際の処理時間と比較してください。

6. SQL*plusを終了します。

SQL> exit

3. サービス・コンソールによるADBインスタンスの状態確認

ADBではインスタンスの稼働状況をサービス・コンソールを介して確認できます。

1. サービス・コンソールを起動します

pastedImage_34png

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

pastedImage_36png

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

pastedImage_39png

4. 次に、同じくActivity から Monitored SQL を選択します。

     ここでは個々のSQLの実行状況をリアルタイムに確認できます。比較的処理時間の長いSQLの状況確認に有用です。

    • Show Details : 選択したSQL Monitorレポートを表示します。(多くの情報を収集するため、表示に少々時間がかかります
    • Download Report : 選択したSQLのSQL Monitorレポートをhtmlファイルとしてダウンロードできます。オンプレミスでEMをお使いの方はこちらの方が慣れているかもしれません。
    • Cancel Execution : 選択したSQL を強制終了(Kill Session)します。

その他、実行開始・終了時間や、PARALLEL度(CPUの並列度)、実行ユーザや利用した接続サービス名などをご確認いただけます。

pastedImage_64png

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

次の章にお進みください。

NOTE

よくある質問やTipsを記載

1. IOがボトルネックになっている処理の性能向上を図るには??

Autonomous Database はOCPU数を増やすことでコア数だけでなくIO帯域も増えるため、IOバウンドな処理に対してもOCPUを増やすことで対応できます。

尚、OCPU増はコストに跳ね返ってきますが、OCPUはオンラインでスケールアップ・ダウンが可能なので、週末・夜間など使わないタイミングはコア数を減らすことでコストを削減できます。

以上