Search

OakieTags

Who's online

There are currently 0 users and 33 guests online.

Recent comments

Affiliations

TPC-H

Hadoop/HiveでTPC-H

「Peta Byteを超えるデータ量をスキャンする」のに1台のサーバでは無理がある。
だから、Hadoopということになる。でも「100台のサーバを揃えてテストをする」なんて趣味の範囲を超えてしまうのでできない。
取りあえず、以下の構成4台で、データ量も32GBにしてOracleと比較してみる。

OSもCentOS 5.5 (x86-64)にして、今回使っているAMD Phenom II X6 1100T Black Edition BOX(3.3 GHz/6 core)1台でDOP=6のOracleのパフォーマンスを見てみると:

8月13日のCompressで40% Up と同じテストを行う

Parallel QueryはTable Compressを行うとI/O量(回数)が減って速くなる。
そこで、以前のテスト(Compressで40%アップ)と同じことをしてみた:
SQL> ALTER TABLE LINEITEM MOVE COMPRESS;
Compress前はということで、同じようにCompressの効果が大きいことがわかる。

そして、8月13日のテストではタイムオーバーとなった「同時4セッション」処理も、10分ぐらい掛かったけれど完走した:
TPC-HベンチマークのようなFull Scanは転送量が全てだから、マザーボード上のSATAインターフェースの限界があるIntel P55系のLGA1156マザーボードでは今回のような転送量が出せなかったからタイムオーバとなった。これをLGA1156マザーボードでやろうと思ったら、10万円ぐらいするRAIDボードをPCI Expressバスに積まなければならない。あるいは、高価なSANデバイスを購入する。。。

今回はAMDに乗り換えて、たった4本のSSDで、900MB/sでParallel Queyが実行できたのだから、RAIDカード1枚より安いよね。SSDを2枚追加すれば1GB/sを超えるはずです。
今回の転送量:

最後に、
貴重なPCI ExpressバスはInfiniBandで使う。

TPC-Hベンチマークテストを行う

8月3日に行った「試作機でTPC-Hベンチマークテストを行う 」はIntel i7-860 Quad Core機でKingstonのお買い得SSD4本で構築したRAID-0。マザーボードは前回紹介したASUS製。
今回はAMD Phenom2 6 Coreにcrusial REAL SSDを4本で構築した、同じくRAID-0。マザーボードはGIGABYTE社製(前回のブログ参照)。

(前回)1セッション、パラレル度=6でテスト:

そのときのディスク転送量は:

今回:ディスク転送量は800MB/秒ぐらいを平均的に出している

4セッションに増やしてみると、、、

平均的に900MB/秒を上回る。

最初のテストから4ヵ月後に、高価で購入ができなかったSATA3対応のSSDが1本12000円ぐらいで買えるようになり、Intel系のマザーボードでは限界であった500MB/sの壁もAMDに乗り換えることで簡単に突破できた。それも、マザーボード込みの値段で35000円程度と、安いほうへの乗り換えでだ。

最後に、
来年になれば、Intelの次世代プロセッサーSandy Bridgeとそれに対応したマザーボードで、またまた簡単に速くなるのだろう。ソフトウェアのバージョンアップをする時代ではない!ハードウェアごとバージョンアップする方が効果的です。

冬なので、暖房もかねて、ケースを買わずにこうしました:

Intel系マザーボードでRAID0にしても

週間アスキーの「ジサトラ」を読んでいたら、僕の使ったP55マザーやX58マザーではMarvell 9128などの外部チップがPCI-E2.0 x 1で接続しているので、いくらSSDでRAID0にしても500MBの壁は破れないと書いてあった。なるほど、、、それらしい値が出た。
でも、8000円のSSDだから「満足」してしまって、高価なSSDならもっと速い!と思い込んでいました。。。
なんと、AMD800系マザーだとSATA3コントローラが性能が良く、当然RAID0接続でもこのようなことは起きないと書いてある。
最近ずっと追いかけてきたTPC-Hベンチマークでは、500MB-530MB/secぐらいでdirect path read待ちばかりとなるから、RAIDカードを買い足そうと考えていたのだけど、まだ買う前でよかったです(忙しすぎて却ってよかった)。
mini DWHにはAMDフェノムですかね?(直ぐ注文)

同時4セッション In-Memory Parallel Query

TPC-Hベンチマークの続き
In-Memory Non PQは8セッションまで、ある程度スケーラブルに処理能力は上がった(TPC-Hの結果参照)。
しかし、In-Memory PQはIn-Memory Parallel Queryセッション数でテストしたように、同時4セッションでqphは横ばいとなった。
念のために、もう一回4セッションをテスト:そして、CPU%は、前回とほぼ同じ「殆んど100%」で振り切れていた。

無駄なCPUはLatch TimeoutのSPINを調べるのが定石

statspackで分析してみると:


Parent Latch Statistics DB/Inst: ORACLE/oracle Snaps: 13-14
-> only latches with sleeps are shown
-> ordered by name

Get Spin
Latch Name Requests Misses Sleeps Gets
------------------------ --------------- ------------ ---------- -----------
Real-time plan statistic 7,048 1,133 107 1,026
active service list 25,346 2,817 1,716 1,139
call allocation 41,422 2,215 39 2,177
dummy allocation 9,807 1,635 2 1,633
enqueues 63,653 3,107 10 3,097
messages 9,540 4 1 3
parameter table manageme 24,461 2,459 1 2,458
qmn task queue latch 52 1 1 0
query server process 31 11 24 0
resmgr:free threads list 9,808 1,488 1 1,487
-------------------------------------------------------------
Child Latch Statistics DB/Inst: ORACLE/oracle Snaps: 13-14
-> only latches with sleeps/gets > 1/100000 are shown
-> ordered by name, gets desc

Child Get Spin
Latch Name Num Requests Misses Sleeps Gets
---------------------- ------- ------------ ------------ ---------- -----------
cache buffers chains 49990 2,791,680 5,344 32 5,313
cache buffers chains 42860 112,396 2,595 4 2,586
cache buffers chains 37884 91,118 3,150 2 3,148
cache buffers chains 31347 16,878 1,166 1 1,165
cache buffers chains 16597 5,280 4 1 3
cache buffers chains 48852 5,280 3 1 2
cache buffers chains 10163 5,200 3 1 2
cache buffers chains 4153 4,570 2 1 1
cache buffers chains 13172 4,568 1 1 0
cache buffers chains 14344 4,564 2 1 1
cache buffers chains 18218 4,564 2 1 1
cache buffers chains 46359 4,560 2 1 1
cache buffers chains 47367 4,560 2 1 1
cache buffers chains 55125 4,560 1 1 0
cache buffers chains 65459 4,560 4 1 3
cache buffers chains 6706 4,560 3 1 2
cache buffers chains 5678 4,560 2 1 1
cache buffers chains 17931 4,560 3 1 2
cache buffers chains 36331 4,560 1 1 0
cache buffers chains 43826 4,000 2 1 1
cache buffers chains 23857 3,440 5 1 4
cache buffers chains 49962 3,040 3 1 2
cache buffers chains 42216 3,040 3 1 2
cache buffers chains 345 3,040 1 1 0
cache buffers chains 51797 3,040 1 1 0
cache buffers chains 26238 2,885 2 1 1
cache buffers chains 35482 2,880 1 1 0
cache buffers chains 32567 2,880 3 1 2
cache buffers chains 39474 2,495 3 1 2
cache buffers chains 30680 2,480 1 1 0
cache buffers chains 44458 2,480 1 1 0
cache buffers chains 20453 2,480 3 1 2
cache buffers chains 46045 2,480 1 1 0
cache buffers chains 11421 2,480 1 1 0
cache buffers chains 31662 2,160 4 2 3
cache buffers chains 29644 1,920 1 1 0
cache buffers chains 33569 1,520 3 1 2
cache buffers lru chai 45 54,182 211 2 209
object queue header op 23 54,897 1,443 1 1,442
object queue header op 18 54,867 1,173 2 1,171
object queue header op 24 54,844 1,457 1 1,456
object queue header op 22 54,823 1,386 5 1,381
parallel query stats 1 5,720 920 13 907
process queue 6 2,526 110 2 108
process queue referenc 30 128,252 18 3 16
shared pool 1 133,446 14,215 21 14,194
shared pool 2 127,339 19,019 12 19,007
-------------------------------------------------------------


cache buffers chainsでLatch get missがたくさん発生していた。
Oracle8の時代ならば_db_block_hash_bucketsやdb_block_lru_latchesなんてパラメータがあったのだけれど、11gではない。

一度にREADするBUFFER_CACHEの量を減らせばcache buffers chainsのLatch範囲も減る予感がする

db_file_multiblock_read_countを64->32に変更:あれ?同じ4セッションでキューイング管理が働いてしまった。

CPU%は:断続的に開放されている。
これは、In-Memory Parallel Queryセッション数でのテスト結果では同時8セッションで発生した現象だ。
そしてそのときは、以下のように書いた:

8セッションからのキューイング管理は実装CPUのスレッド数から割り出されているのだろうけど、今回使用しているCore i7 860だと、管理が始まる8セッションは少し遅すぎるのではないかと感じる。実際4セッションでCPUは振り切れている。

このときはキューイング管理は実装されるCPU数で決められると思ってたけど、db_file_multiblock_read_countが関係する。

今度は、db_file_multiblock_read_countを32->128と、当初の倍に増やしてみる:
そして、CPUもほぼ振り切れている状況に戻った

最後に、
DWHシステムでは、In-Memory Parallel Queryは「どんなことがあっても使いたい!」一番魅力的な機能です。
でも全てのデータをBUFFER_CACHEに乗せる事は物理的に難しいのでParallel Queryで補完する。それが理想形です。だから、前回のブログで大容量192GBメモリー搭載可能 System-Xマンのコマーシャル映像を載せたのです。
しかし、、、parallel_degree_policy=auto だけがIn-Memory PQを制御する指定で、CPUが振り切れないように制御する「キューイング管理」がどのタイミングで働くかが良く解りません。

ORA_LPENABLEを1に設定

In-Memory Parallel Queryの続き

データベースが大量のメモリーにアクセスするのがIn-Memory Parallel Queryだから、Large Pageサポート機能を検証してみた。

ラージ・ページのサポートは、Oracle Database 10gリリース1(10.1)以上の機能です。ラージ・ページのサポートにより、Windows Server 2003で実行されているメモリー集中型のデータベース・インスタンスのパフォーマンスが向上します。新たに導入されたオペレーティング・システム・サポートを利用することにより、Oracle Database 10gリリース1(10.1)以上では、プロセッサ・メモリー・アドレッシング・リソースをより効率よく使用できるようになりました。具体的には、ラージ・ページのサポートが有効になっていると、システムのCPUはRAM内のOracle Databaseバッファにより高速にアクセスできるようになります。4KBの増分でバッファをアドレッシングするかわりに、CPUはデータベース・バッファをアドレッシングする際にPhysical Address Extension(PAE)モードでは2MBのページ・サイズ、非PAEモードでは4MBのページ・サイズを使用するように指示されます。

Oracle Databaseプラットフォーム・ガイド 11gリリース1(11.1) for Microsoft Windows E05885-03

まずは、メモリ内のPageロック機能権限を与える:

そして、レジストリにORAL_LPENABLE=1をセットする:

一応Rebootして、
THP-Hベンチマークを行うと:

nocompressでIn-Memory Parallel Queryの時の結果と比べると:

少し上がったようにも見えるが、ほとんど変わらない。

DB_BUFFER_CACHEが100GBなんていう環境であれば効果はあるのだろう。
非ページング対象になるという意味ではlock_sgaやnailed_sgaパラメータと似ている。

以前書いたExpress 5800 128GBメモリ搭載機クラス用の設定だと思う。

PQ, In-Memory PQ, In-Memory Non PQを比較する

hammeroraのTPC-Hベンチマークの10回繰り返しを行いASH Viewerで結果をモニタリングした:

A,B Parallel Query (PQが得意なCOMPRESSモードで実行)
C,D In-Memory Parallel Query (In-Memoryが得意なNOCOMPRESSモードで実行。ただしlineitemのみ)
E,F In-Memory Non Parallel Query (同上)

それぞれ、同時1セッションと2セッションの結果だ。

  • 時間軸(X軸)を見るとCおよびDのIn-Memory Parallel Queryが一番速いのが分かる
  • AのPQ 1セッションとCのIn-Memory PQのCPU(緑)を見るとCのIn-Memory PQの方がCPUを使っているように見えるが、In-Memory PQはCPU dpend?で証明したようにParallel QueryのCPU使用時間の方が大きい。I/O待ちでCPUが回らないだけ
  • BのPQ 2セッションではI/O待ち(青)が限界となり、1セッションの2倍ぐらいの時間がかかっている
  • TPC-Hの結果でも以下のように書いた:

    Parallel Queryは同時2セッションが限界で、それ以上は安定した計測値が出ないし、時間も掛かり過ぎた

  • Cの1セッションIn-Memory PQは、初めにphysical readsを行いbuffer_cacheにデータを読み込んでいるが、I/O待ちは発生しないので(青)が出ていない
  • Dの2セッションIn-Memory PQは1セッション実行より若干時間は掛かったが優秀にスケーラブルであった
  • しかし同時3セッションで全てのCPUスレッドが一杯になり、4セッションでRun Queue待ちが予測できる
  • E,FのIn-Memory Non PQはスケーラブルにほぼ同一時間内に終了している
  • そして、同時8セッションまである程度スケーラブルに処理されることが予測できる
  • TPC-Hの結果でも以下のように書いた:

    それから、
    In-Memoryはスケーラビリティでは大勝です。
    でも、メモリに収まるサイズだからです。。。

    でも、よくよく考えてみると、当たり前だな、同時8セッションまではスケーラブルで、それ以上は動かなくなるんだろう。

    そして、Parallel Queryは初めから限界ディスク転送量を出してしまうので「同時実行制御」の工夫が必要だということが、今回のテストを通じて理解できた。

    In-Memory non Parallel Queryじゃダメなんだよ!の中で書いたけど、In-Memory (Non) PQにも同じことが言える。In-Memory PQにはQueueing制御があるのだけど、

    8セッションからのキューイング管理は実装CPUのスレッド数から割り出されているのだろうけど、今回使用しているCore i7 860だと、管理が始まる8セッションは少し遅すぎるのではないかと感じる。
    実際4セッションでCPUは振り切れている。「In-Memory Parallel Queryセッション数」

    同時8セッションまで動かしてしまうと、全てが動かなくなるので、やはり、同時制御の工夫が大事だと思う。

    最後に、
    Parallel QueryはCOMPRESSが得意。
    In-Memory PQはNOCOMPRESSが得意。だから、

    ALTER TABLE lineitem MOVE PARTITION 今月 NOCOMPRESS;
    ALTER TABLE lineitem MOVE PARTITION 2ヶ月前 COMPRESS;
    ALTER TABLE lineitem MOVE PARTITION 3ヶ月前 COMPRESS;
    ..
    ALTER TABLE lineitem MOVE PARTITION 1年前 COMPRESS;

    のように工夫する。

    In-Memory PQはCPU dpend?

    ここまでの話の流れだとIn-Memory (Non) Parallel QueryはCPU dependで、
    Parallel QueryはI/O dependみたいに感じる。
    consistent gets量が多いにもかかわらずNOCOMPRESSが速い で行ったテストと同じことをParallel Queryでも行ってみる。

    まずはNOCOMPRESSをDOP=2でSelect:

    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    に接続されました。
    SQL> alter system flush buffer_cache;

    システムが変更されました。

    SQL> alter session force parallel query parallel 2;

    セッションが変更されました。

    SQL> set autot trace stat
    SQL> set timi on
    SQL> select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty
    2 , sum(l_extendedprice) as sum_base_price
    3 , sum(l_extendedprice * (1 - l_discount)) as sum_disc_price
    4 , sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge
    5 , avg(l_quantity) as avg_qty, avg(l_extendedprice) as avg_price
    6 , avg(l_discount) as avg_disc
    7 , count(*) as count_order
    8 from lineitem
    9 where l_shipdate <= date '1992-12-01' - interval '68' day (3)
    10 group by l_returnflag, l_linestatus
    11 order by l_returnflag, l_linestatus
    12 /

    経過: 00:00:02.14

    統計
    ----------------------------------------------------------
    36 recursive calls
    0 db block gets
    103961 consistent gets
    102003 physical reads
    0 redo size
    1456 bytes sent via SQL*Net to client
    519 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    7 sorts (memory)
    0 sorts (disk)
    2 rows processed

    SQL> set autot off
    SQL>
    SQL> select n.name, m.value
    2 from sys.v_$mystat m, sys.v_$statname n
    3 where n.name in ('CPU used by this session','DB time')
    4 and n.statistic# = m.statistic#
    5 /

    NAME VALUE
    ---------------------------------------------------------------- ----------
    CPU used by this session 122
    DB time 2409

    次に、COMPRESSを同じくDOP=2でSelect:

    SQL> alter system flush buffer_cache;

    システムが変更されました。

    SQL> alter session force parallel query parallel 2;

    セッションが変更されました。

    SQL> set autot trace stat
    SQL> set timi on
    SQL> select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty
    2 , sum(l_extendedprice) as sum_base_price
    3 , sum(l_extendedprice * (1 - l_discount)) as sum_disc_price
    4 , sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge
    5 , avg(l_quantity) as avg_qty, avg(l_extendedprice) as avg_price
    6 , avg(l_discount) as avg_disc
    7 , count(*) as count_order
    8 from lineitem_comp
    9 where l_shipdate <= date '1992-12-01' - interval '68' day (3)
    10 group by l_returnflag, l_linestatus
    11 order by l_returnflag, l_linestatus
    12 /

    経過: 00:00:01.19

    統計
    ----------------------------------------------------------
    37 recursive calls
    0 db block gets
    67123 consistent gets
    66958 physical reads
    0 redo size
    1456 bytes sent via SQL*Net to client
    519 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    7 sorts (memory)
    0 sorts (disk)
    2 rows processed

    SQL> set autot off
    SQL>
    SQL> select n.name, m.value
    2 from sys.v_$mystat m, sys.v_$statname n
    3 where n.name in ('CPU used by this session','DB time')
    4 and n.statistic# = m.statistic#
    5 /

    NAME VALUE
    ---------------------------------------------------------------- ----------
    CPU used by this session 138
    DB time 1428

    実行時間を比べると:
    NOCOMPRESS 2.14秒
     COMPRESS 1.19秒
    繰り返しになってしまうが、Parallel QueryはCOMPRESSの方が有利。

    そして、CPU時間を比較してみる:

    In-Memory PQ Parallel Query
    CPU used DB time CPU used DB time
    NOCOMPRESS 80 194 122 2409
    COMPRESS 122 305 138 1429

    (in 10s of milliseconds)

    In-Memory Parallel Queryと比べるとCPU使用時間もParallel Queryの方が多い。
    In-Memoryの方がCPUを消費するから「多くてもたった5倍」しか速くない!と勘違いをしていた。

    automatic DOP

    nocompressでIn-Memory Parallel Query の中でCOMPRESS->NOCOMPRESSにしたらパラレル度が自動的に4->6になった。

    NOCOMPRESSだとパラレル度は上がるのか?

    NOCOMPRESSのlineitemをSelectする:

    SQL> alter system flush buffer_cache;

    システムが変更されました。

    SQL> select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty
    2 , sum(l_extendedprice) as sum_base_price
    3 , sum(l_extendedprice * (1 - l_discount)) as sum_disc_price
    4 , sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge
    5 , avg(l_quantity) as avg_qty, avg(l_extendedprice) as avg_price
    6 , avg(l_discount) as avg_disc
    7 , count(*) as count_order
    8 from lineitem
    9 where l_shipdate <= date '1992-12-01' - interval '68' day (3)
    10 group by l_returnflag, l_linestatus
    11 order by l_returnflag, l_linestatus
    12 /

    経過: 00:00:02.03

    実行計画
    ----------------------------------------------------------
    Plan hash value: 2461824725

    ------------------------------------------------------------------------------------------------------------------
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
    ------------------------------------------------------------------------------------------------------------------
    | 0 | SELECT STATEMENT | | 5 | 135 | 6956 (1)| 00:01:24 | | | |
    | 1 | PX COORDINATOR | | | | | | | | |
    | 2 | PX SEND QC (ORDER) | :TQ10001 | 5 | 135 | 6956 (1)| 00:01:24 | Q1,01 | P->S | QC (ORDER) |
    | 3 | SORT GROUP BY | | 5 | 135 | 6956 (1)| 00:01:24 | Q1,01 | PCWP | |
    | 4 | PX RECEIVE | | 5 | 135 | 6956 (1)| 00:01:24 | Q1,01 | PCWP | |
    | 5 | PX SEND RANGE | :TQ10000 | 5 | 135 | 6956 (1)| 00:01:24 | Q1,00 | P->P | RANGE |
    | 6 | HASH GROUP BY | | 5 | 135 | 6956 (1)| 00:01:24 | Q1,00 | PCWP | |
    | 7 | PX BLOCK ITERATOR | | 634K| 16M| 6941 (1)| 00:01:24 | Q1,00 | PCWC | |
    |* 8 | TABLE ACCESS FULL| LINEITEM | 634K| 16M| 6941 (1)| 00:01:24 | Q1,00 | PCWP | |
    ------------------------------------------------------------------------------------------------------------------

    Predicate Information (identified by operation id):
    ---------------------------------------------------

    8 - filter("L_SHIPDATE"<=TO_DATE(' 1992-09-24 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

    Note
    -----
    - automatic DOP: Computed Degree of Parallelism is 3


    統計
    ----------------------------------------------------------
    22 recursive calls
    4 db block gets
    106301 consistent gets
    102004 physical reads
    0 redo size
    1456 bytes sent via SQL*Net to client
    519 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    4 sorts (memory)
    0 sorts (disk)
    2 rows processed

    DOP=3が自動的に設定され、2.03秒かかった。
    automatic DOP: Computed Degree of Parallelism is 3

    次にCOMPRESSされたlineitemをSelectしてみる:


    SQL> select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty
    2 , sum(l_extendedprice) as sum_base_price
    3 , sum(l_extendedprice * (1 - l_discount)) as sum_disc_price
    4 , sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge
    5 , avg(l_quantity) as avg_qty, avg(l_extendedprice) as avg_price
    6 , avg(l_discount) as avg_disc
    7 , count(*) as count_order
    8 from lineitem_comp
    9 where l_shipdate <= date '1992-12-01' - interval '68' day (3)
    10 group by l_returnflag, l_linestatus
    11 order by l_returnflag, l_linestatus
    12 /

    経過: 00:00:01.51

    実行計画
    ----------------------------------------------------------
    Plan hash value: 3881738590

    -----------------------------------------------------------------------------------------------------------------------
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
    -----------------------------------------------------------------------------------------------------------------------
    | 0 | SELECT STATEMENT | | 5 | 135 | 6787 (2)| 00:01:22 | | | |
    | 1 | PX COORDINATOR | | | | | | | | |
    | 2 | PX SEND QC (ORDER) | :TQ10001 | 5 | 135 | 6787 (2)| 00:01:22 | Q1,01 | P->S | QC (ORDER) |
    | 3 | SORT GROUP BY | | 5 | 135 | 6787 (2)| 00:01:22 | Q1,01 | PCWP | |
    | 4 | PX RECEIVE | | 5 | 135 | 6787 (2)| 00:01:22 | Q1,01 | PCWP | |
    | 5 | PX SEND RANGE | :TQ10000 | 5 | 135 | 6787 (2)| 00:01:22 | Q1,00 | P->P | RANGE |
    | 6 | HASH GROUP BY | | 5 | 135 | 6787 (2)| 00:01:22 | Q1,00 | PCWP | |
    | 7 | PX BLOCK ITERATOR | | 634K| 16M| 6765 (1)| 00:01:22 | Q1,00 | PCWC | |
    |* 8 | TABLE ACCESS FULL| LINEITEM_COMP | 634K| 16M| 6765 (1)| 00:01:22 | Q1,00 | PCWP | |
    -----------------------------------------------------------------------------------------------------------------------

    Predicate Information (identified by operation id):
    ---------------------------------------------------

    8 - filter("L_SHIPDATE"<=TO_DATE(' 1992-09-24 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

    Note
    -----
    - automatic DOP: Computed Degree of Parallelism is 2


    統計
    ----------------------------------------------------------
    16 recursive calls
    4 db block gets
    67041 consistent gets
    66958 physical reads
    0 redo size
    1456 bytes sent via SQL*Net to client
    519 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    3 sorts (memory)
    0 sorts (disk)
    2 rows processed

    DOP=2が自動的に設定され、1.51秒で終わった。

    まとめてみる

    NOCOMPRESS   automatic DOP=3
    COMPRESS    automatic DOP=2

    NOCOMPRESSの方がDOPが大きく設定される。 --->アンコンプレスの処理負荷を考慮しているのだろうか?

    実行時間は
    NOCOMPRESS  2.01秒
    COMPRESS   1.51秒

    COMPRESSの方が速い。それはphysical read量に比例する
     102004  physical reads
      66958  physical reads

    だから、Parallel QueryはCOMPRESSが有利
    でも、In-Memory Parallel Queryだと

    上記のテスト後にもう一度二つのSQLを実行してみる:


    SQL> select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty
    2 , sum(l_extendedprice) as sum_base_price
    3 , sum(l_extendedprice * (1 - l_discount)) as sum_disc_price
    4 , sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge
    5 , avg(l_quantity) as avg_qty, avg(l_extendedprice) as avg_price
    6 , avg(l_discount) as avg_disc
    7 , count(*) as count_order
    8 from lineitem
    9 where l_shipdate <= date '1992-12-01' - interval '68' day (3)
    10 group by l_returnflag, l_linestatus
    11 order by l_returnflag, l_linestatus
    12 /

    経過: 00:00:00.33

    実行計画
    ----------------------------------------------------------
    Plan hash value: 2461824725

    ------------------------------------------------------------------------------------------------------------------
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
    ------------------------------------------------------------------------------------------------------------------
    | 0 | SELECT STATEMENT | | 5 | 135 | 6956 (1)| 00:01:24 | | | |
    | 1 | PX COORDINATOR | | | | | | | | |
    | 2 | PX SEND QC (ORDER) | :TQ10001 | 5 | 135 | 6956 (1)| 00:01:24 | Q1,01 | P->S | QC (ORDER) |
    | 3 | SORT GROUP BY | | 5 | 135 | 6956 (1)| 00:01:24 | Q1,01 | PCWP | |
    | 4 | PX RECEIVE | | 5 | 135 | 6956 (1)| 00:01:24 | Q1,01 | PCWP | |
    | 5 | PX SEND RANGE | :TQ10000 | 5 | 135 | 6956 (1)| 00:01:24 | Q1,00 | P->P | RANGE |
    | 6 | HASH GROUP BY | | 5 | 135 | 6956 (1)| 00:01:24 | Q1,00 | PCWP | |
    | 7 | PX BLOCK ITERATOR | | 634K| 16M| 6941 (1)| 00:01:24 | Q1,00 | PCWC | |
    |* 8 | TABLE ACCESS FULL| LINEITEM | 634K| 16M| 6941 (1)| 00:01:24 | Q1,00 | PCWP | |
    ------------------------------------------------------------------------------------------------------------------

    Predicate Information (identified by operation id):
    ---------------------------------------------------

    8 - filter("L_SHIPDATE"<=TO_DATE(' 1992-09-24 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

    Note
    -----
    - automatic DOP: Computed Degree of Parallelism is 3


    統計
    ----------------------------------------------------------
    34 recursive calls
    4 db block gets
    106301 consistent gets
    0 physical reads
    0 redo size
    1456 bytes sent via SQL*Net to client
    519 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    4 sorts (memory)
    0 sorts (disk)
    2 rows processed

    SQL> select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty
    2 , sum(l_extendedprice) as sum_base_price
    3 , sum(l_extendedprice * (1 - l_discount)) as sum_disc_price
    4 , sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge
    5 , avg(l_quantity) as avg_qty, avg(l_extendedprice) as avg_price
    6 , avg(l_discount) as avg_disc
    7 , count(*) as count_order
    8 from lineitem_comp
    9 where l_shipdate <= date '1992-12-01' - interval '68' day (3)
    10 group by l_returnflag, l_linestatus
    11 order by l_returnflag, l_linestatus
    12 /

    経過: 00:00:00.62

    実行計画
    ----------------------------------------------------------
    Plan hash value: 3881738590

    -----------------------------------------------------------------------------------------------------------------------
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
    -----------------------------------------------------------------------------------------------------------------------
    | 0 | SELECT STATEMENT | | 5 | 135 | 6787 (2)| 00:01:22 | | | |
    | 1 | PX COORDINATOR | | | | | | | | |
    | 2 | PX SEND QC (ORDER) | :TQ10001 | 5 | 135 | 6787 (2)| 00:01:22 | Q1,01 | P->S | QC (ORDER) |
    | 3 | SORT GROUP BY | | 5 | 135 | 6787 (2)| 00:01:22 | Q1,01 | PCWP | |
    | 4 | PX RECEIVE | | 5 | 135 | 6787 (2)| 00:01:22 | Q1,01 | PCWP | |
    | 5 | PX SEND RANGE | :TQ10000 | 5 | 135 | 6787 (2)| 00:01:22 | Q1,00 | P->P | RANGE |
    | 6 | HASH GROUP BY | | 5 | 135 | 6787 (2)| 00:01:22 | Q1,00 | PCWP | |
    | 7 | PX BLOCK ITERATOR | | 634K| 16M| 6765 (1)| 00:01:22 | Q1,00 | PCWC | |
    |* 8 | TABLE ACCESS FULL| LINEITEM_COMP | 634K| 16M| 6765 (1)| 00:01:22 | Q1,00 | PCWP | |
    -----------------------------------------------------------------------------------------------------------------------

    Predicate Information (identified by operation id):
    ---------------------------------------------------

    8 - filter("L_SHIPDATE"<=TO_DATE(' 1992-09-24 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

    Note
    -----
    - automatic DOP: Computed Degree of Parallelism is 2


    統計
    ----------------------------------------------------------
    16 recursive calls
    4 db block gets
    67041 consistent gets
    0 physical reads
    0 redo size
    1456 bytes sent via SQL*Net to client
    519 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    3 sorts (memory)
    0 sorts (disk)
    2 rows processed

    一回目のSQLでBuffer_Cache上にデータがあるのでphysical reads=0となる。

    NOCOMPRESS   automatic DOP=3
    COMPRESS    automatic DOP=2

    実行時間は
    NOCOMPRESS  0.33秒
    COMPRESS   0.62秒

    consistent gets量が多いにもかかわらずNOCOMPRESSの方が2倍速い。
     106301   consistent gets
     67041   consistent gets

    でも、その差はたった0.3秒。しかし、その僅かな差を積み上げると:

    という結果になった

    Heavy SQLの比較

    以前行ったHeavy SQL Top5の実行時間(秒数)にIn-Memory PQも追加してみた:
    A=non parallel(all physical reads)
    B=in-memory nonParallel
    C=parallel(DOP=6)
    D=In-Memory Parallel

    SQL# A B C D
    1 7.95 3.63 3.24 1.22
    2 7.67 2.60 2.71 1.33
    3 5.24 1.01 1.51 0.35
    4 8.61 3.95 3.82 1.66
    5 2.81 1.02 2.82 0.66

    繰り返しになるが、In-Memory Parallel Queryでは明示的にパラレル度を設定することはできない。
    しかし、前回のテストで示したようにパラレル度(DOP)は自動的に6になっている。
    そして上記CのParallel(DOP=6)と比較すると2倍から5倍の性能が出ている。

    1 select c_name, c_custkey, o_orderkey, o_orderdate, o_totalprice, sum(l_quantity)
    from customer, orders, lineitem
    where o_orderkey in
    ( select l_orderkey
    from lineitem
    group by l_orderkey
    having sum(l_quantity) > 313)
    and c_custkey = o_custkey
    and o_orderkey = l_orderkey
    group by c_name, c_custkey
    , o_orderkey
    , o_orderdate
    , o_totalprice
    order by o_totalprice desc, o_orderdate;
    2 select nation, o_year, sum(amount) as sum_profit
    from ( select n_name as nation, extract(year from o_orderdate) as o_year
    , l_extendedprice * (1 - l_discount) - ps_supplycost * l_quantity as amount
    from part, supplier, lineitem, partsupp, orders, nation
    where s_suppkey = l_suppkey
    and ps_suppkey = l_suppkey
    and ps_partkey = l_partkey
    and p_partkey = l_partkey
    and o_orderkey = l_orderkey
    and s_nationkey = n_nationkey
    and p_name like '%navy%') profit
    group by nation, o_year
    order by nation, o_year desc;
    3 select l_shipmode, sum(case when o_orderpriority = '1-URGENT' or o_orderpriority = '2-HIGH' then 1 else 0 end) as high_line_count
    , sum(case when o_orderpriority <> '1-URGENT' and o_orderpriority <> '2-HIGH' then 1 else 0 end) as low_line_count
    from orders, lineitem
    where o_orderkey = l_orderkey
    and l_shipmode in ('SHIP', 'FOB')
    and l_commitdate < l_receiptdate
    and l_shipdate < l_commitdate
    and l_receiptdate >= date '1997-01-01'
    and l_receiptdate < date '1997-01-01' + interval '1' year
    group by l_shipmode
    order by l_shipmode;
    4 select s_name, count(*) as numwait
    from supplier, lineitem l1, orders, nation
    where s_suppkey = l1.l_suppkey
    and o_orderkey = l1.l_orderkey
    and o_orderstatus = 'F'
    and l1.l_receiptdate > l1.l_commitdate
    and exists
    ( select * from lineitem l2
    where l2.l_orderkey = l1.l_orderkey
    and l2.l_suppkey <> l1.l_suppkey)
    and not exists
    ( select * from lineitem l3
    where l3.l_orderkey = l1.l_orderkey
    and l3.l_suppkey <> l1.l_suppkey
    and l3.l_receiptdate > l3.l_commitdate)
    and s_nationkey = n_nationkey
    and n_name = 'CHINA'
    group by s_name
    order by numwait desc, s_name
    5 select supp_nation, cust_nation, l_year, sum(volume) as revenue
    from
    ( select n1.n_name as supp_nation, n2.n_name as cust_nation
    , extract(year from l_shipdate) as l_year, l_extendedprice * (1 - l_discount) as volume
    from supplier, lineitem, orders, customer, nation n1, nation n2
    where s_suppkey = l_suppkey
    and o_orderkey = l_orderkey
    and c_custkey = o_custkey
    and s_nationkey = n1.n_nationkey
    and c_nationkey = n2.n_nationkey
    and ( (n1.n_name = 'JAPAN' and n2.n_name = 'ETHIOPIA')
    or (n1.n_name = 'ETHIOPIA' and n2.n_name = 'JAPAN'))
    and l_shipdate between date '1995-01-01'
    and date '1996-12-31') shipping
    group by supp_nation, cust_nation, l_year
    order by supp_nation, cust_nation, l_year;