Search

Navigation

Affiliations

TPC-H

Hadoop/HiveでTPC-H

Submitted by Ichiro Obata on Sun, 2011-02-20 02:47

「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 と同じテストを行う

Original article

Submitted by Ichiro Obata on Mon, 2010-12-13 18:53

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ベンチマークテストを行う

Original article

Submitted by Ichiro Obata on Mon, 2010-12-13 03:23

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

（前回）１セッション、パラレル度=6でテスト：

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

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

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

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

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

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

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

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

Original article

Submitted by Ichiro Obata on Thu, 2010-10-14 14:27

週間アスキーの「ジサトラ」を読んでいたら、僕の使った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

Original article

Submitted by Ichiro Obata on Wed, 2010-09-08 18:52

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に設定

Original article

Submitted by Ichiro Obata on Tue, 2010-09-07 17:12

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を比較する

Original article

Submitted by Ichiro Obata on Sat, 2010-09-04 18:53

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?

Original article

Submitted by Ichiro Obata on Sat, 2010-09-04 04:25

ここまでの話の流れだと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

Original article

Submitted by Ichiro Obata on Fri, 2010-09-03 13:24

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の比較

Original article

Submitted by Ichiro Obata on Fri, 2010-09-03 10:36

以前行った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;

Search

Navigation

OakieTags

Who's online

Recent comments