ADB HOL よくある質問集(検証実施時のノウハウ)

Version 5

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

    >ADBコンテンツ一覧に戻るAutonomous Database ハンズオンラボ

     

     

    この章ではAutonomous Database を利用して検証作業を実施するためのノウハウを中心に記載しています。

     

    尚、“簡単”というAutonomous のコンセプトから乖離しがちな細かい内容も含まれていますが、

    基本的には簡単すぐに良い性能が得られています。

     

     

    環境作成関連

     

    OCPUはいくつからスタートすれば良いですか?

     

    ADW/ATPにおいて性能試験をされる場合、最低でも2 OCPUからスタートください。より高い性能を得るためのパラレル処理が利用可能になります。

     

     

    DBMS_CLOUD.COPY_DATAを利用した、データロードを高速化するには?

     

    こちらを参照ください

     

     

    統計情報の取得は?

     

    自動的に取得されているため、考慮不要です。

      • Autonomous Database ではデータをロード(ダイレクト・パス・ロード)する際に、自動で統計情報が取得されます
      • その後、実際のワークロードに基づいて統計情報が定期的に自動取得されます
      • さらに、クエリ実行時に統計情報が欠損している際は、ダイナミック・サンプリングが動きます

     

    それでも期待した性能が出ない場合は、以下のようにコマンドで取得することも可能です。

    SQL> exec dbms_stats.gather_table_stats( ownname => ‘YYY’, tabname => ‘XXX’) ;

     

     

    クエリ関連

     

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

     

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

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

     

    その他、Autonomous Databaseでは高速化のためのオプション機能であるパーティションが無償で利用可能であり、マテリアライズド・ビューも利用できるため、ご検討ください。

    また、ATPの場合はHCCによる圧縮もご検討ください(ADWはデフォルトで圧縮設定済み)

     

     

    ヒントは利用できますか?

     

      • ATPの場合
        • 通常Oracle Databaseと同様、特に気にせずにヒント句を利用できます。
      • ADWの場合
        • 基本的にオプティマイザに全て任せることで高速化できるため、ヒントは不要です
          • optimizer_ignore_hints がTRUEであり既存ヒントは無効化されている
          • ヒントを利用するためにはセッション単位でヒントを有効化する必要があります。(NO_RESULT_CACHEヒントを除く。後述)

     

        • おすすめの検証手順
          1. そのままの状態で計測する
          2. 予期した性能が出ない場合に限り、ヒントの効果を確認する

     

    SQL> alter session set optimizer_ignore_hints = false ;

    SQL> select /*+ xxxxx */ count(1) from test_table ;

     

     

    Result Cache(結果キャッシュ)を無効化することはできますか?

     

    Autonomous Data Warehouse (ADW) はDWHの高速化機能の一つであるResult Cacheがデフォルトで有効化されており、

    あくまでもそのままお使いいただくことを推奨しています。(ATPはデフォルト無効です)

     

    ただし、性能試験としてSQLの処理時間を計測したい場合は、2回目の計測以降は1秒未満の結果となるため、無効化したいケースがあります。

    Result Cacheを無効化したい場合は以下をお試しください。

     

      • ヒント(実行例)
        • SQL> SELECT /*+ NO_RESULT_CACHE */ count(*) from ssb.customer ;
      • プロシージャ(実行例)
        • SQL> exec DBMS_RESULT_CACHE.BYPASS(TRUE);
        • SQL> SELECT DBMS_RESULT_CACHE.STATUS FROM DUAL;  -- 確認用SQL
        • SQL> SELECT count(*) from ssb.customer ;

     

    ちなみに、Result Cacheをクリアしたい場合は以下を実施ください。あまり実施することはありませんが。。

      • SQL> execute dbms_result_cache.flush ;

     

     

    Oracle 以外のDBのSQLをOracle DB用に変換するには?

     

    簡単なSQLであれば、Online SQL Conversion tool (http://www.sqlines.com/online )がおススメです。

    その他、SQL Developer のMigration Workbenchの利用もご検討ください。

     

     

     

    結果件数が多いクエリはどうすればよい?

     

    「期待した性能が出ないんだけど、なぜ?」という問い合わせにおいて、比較的多いのがこのパターンです。

    SQLの結果件数が多い場合、例えばCSVファイルに結果セットを書き出すといったような場合は、

    データベースの処理は一瞬でも、その後のデータ転送に時間がかかるケースがあります。本来比較したいデータベース自体の性能を評価できません。

     

    そのような場合は、以下の2パターンを計測ください。

     

    ① アプリ観点)   クライアントにデータを転送するパターン

     

    SQL*Plusを例に記載していますが、効率よく転送するためのオプション利用をご検討ください。

     

    $ sqlplus –s –Fast user/xxxx@yyyy_high

    SQL> set timing on

    SQL> set echo on

    SQL > set feedback only

    SQL > set arraysize 5000  -- ※

    SQL >

    SQL > select xxxx – 計測対象のSQL

     

    ※ クライアントサーバのメモリを消費するので、PoC以外での利用は注意

    詳細は詳細は津島博士のページを参照ください。

     

    ② DB観点)   データベースとしての処理時間を計測するパターン

     

    以下のように結果セットを他の表にロードすることで、DBからクライアントへの結果セットの転送時間の影響を排除してみてください。

    こうすることで、純粋にデータベースの性能を比較することが可能です。

     

    SQL> create table TMP_TABLE as <計測対象のクエリ> where 1=2 ; -- 結果セット格納用の表を作成

    SQL> insert /*+ APPEND */ into TMP_TABLE <計測対象のクエリ> ;

     

     

     

     

     

     

    インスタンスのキャッシュをクリアするにはどうしたらよいですか?

    検証実施時にキャッシュの影響を排除して計測したいんだけど。。

     

    Autonomous Database はalter systemによる変更は基本的に許されていないため、インスタンスを再起動いただく必要があります。

    GUIだけでなく、OCICLI、REST APIにて実施ください。

    OCICLIでの実施方法はこちらを参照ください。

     

     

    パラレルクエリを利用して高速化したのだが、どう設定すれば良い??

     

    接続サービスを選択いただきます。接続サービスに関してはこちらを参照ください。

      • HIGH / MEDIUMの接続の場合
        • 自動でパラレル処理されます。
      • TPURGENTの接続の場合
        • これまで通りの方法でパラレル処理を設定します。
          • ヒントを利用する。ただし、ADWの場合はヒントを有効化する必要があります。
            • SQL> alter session set optimizer_ignore_parallel_hints = false ;

            • SQL> select /*+ parallel(2) */ count(1) from ssb.customer ;  -- 括弧内はパラレル度
          • もしくは表のDEGREE属性に従う
            • SQL> alter table XXXX degree(2) ;
          • もしくはセッション毎に指定する
            • SQL> alter session enable(force) parallel query;
            • SQL> select .... ;
      • TP/LOWの場合
        • パラレル処理はできません

     

    INSERT処理を高速化するにはどうしたら良いですか?

     

    接続サービスを選択いただきます。接続サービスに関してはこちらを参照ください。

      • MEDIUM、HIGH接続の場合
        • 特に操作は不要です。(自動的にパラレル処理となり、ダイレクト・ロードが選択されるため高速に処理されます。)
      • TPURGENT接続の場合
        • セッション毎にパラレルDMLの設定を行う(自動的にダイレクト・ロードとなるため、従来のAPPENDヒントは不要です)
          • SQL> alter session enable pararel query;
          • SQL> alter session enable pararel dml;
          • SQL> Insert  .... ;
          • SQL> Commit; (or Rollback;)   --パラレル処理後は必ずトランザクションを終了させてください。続けてInsert等の処理を実行するとエラーになります。
      • TP/LOW接続の場合
        • シリアル処理になります。この場合ダイレクト・ロードにならないため、従来通り、明示的にAPPENDヒントを指定してください。
        • SQL> INSERT /*+ APPEND */ INTO XXX SELECT * FROM YYY ;
          • (APPENDヒントの場合、alter session set optimizer_ignore_hints = false ;は不要です)

     

    尚、CTAS(Create table as select xxxx)はデフォルトでダイレクト・ロードになり高速処理されます。

    ただし、HIGH/MEDIUMを選択するか、TPURGENTについてはパラレルDDLの設定を忘れないようにしてください。

     

    以上