Dion Cho - Oracle Performance Storyteller

グローバルヒントの制約の面白いケース

2010-12-16T22:19:00.000-08:00

次はグローバルヒントで結合順序を制御できないテストケースです。

1. 表T1, T2, T3を作ります。


SQL> create table t1(c1 number, c2 number);

Table created.

SQL> create table t2(c1 number, c2 number);

Table created.

SQL> create table t3(c1 number, c2 number);

Table created.

2. グローバルヒントを使って、結合順序をT1->T2->T3にしますが、なぜか予想通りに動作しません。


SQL> explain plan for
  2  select * from
  3  (
  4  select
  5        /*+ leading(v.t1 v.t2 t3) */
  6        v.c1 as v_c1,
  7        v.c2 as v_c2,
  8        t3.c2 as t3_c2
  9  from
 10        (select
 11         t1.c1,
 12         t2.c2
 13        from
 14         t1, t2
 15        where
 16         t1.c1 = t2.c1) v,
 17        t3
 18  where
 19        v.c1 = t3.c1
 20  ) x
 21  ;

------------------------------------------------------------------------------
| Id  | Operation             | Name | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |      |     1 |    65 |     7  (15)| 00:00:01 |
|*  1 |  HASH JOIN            |      |     1 |    65 |     7  (15)| 00:00:01 |
|   2 |   MERGE JOIN CARTESIAN|      |     1 |    52 |     4   (0)| 00:00:01 |
|   3 |    TABLE ACCESS FULL  | T2   |     1 |    26 |     2   (0)| 00:00:01 |
|   4 |    BUFFER SORT        |      |     1 |    26 |     2   (0)| 00:00:01 |
|   5 |     TABLE ACCESS FULL | T3   |     1 |    26 |     2   (0)| 00:00:01 |
|   6 |   TABLE ACCESS FULL   | T1   |     1 |    13 |     2   (0)| 00:00:01 |
------------------------------------------------------------------------------

テストの結果から、Optimizerはグローバルヒントがグローバルではないヒントとは正常的に動作しないことがわります。インラインビューでヒントを与える方法もありますが、この例ではグローバルヒントだけで制御するのが目的です。

3. ここで適用できるのがOracleの内部的なグローバルヒントの表記法です。DBMS_XPLAN.DISPLAY関数にADVANCEDオプションを使えばOracleの内部的なヒント表記法が出力されます。


select * from table(dbms_xplan.display(null, null, 'advanced'));
...

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$5C160134
   3 - SEL$5C160134 / T1@SEL$3
   4 - SEL$5C160134 / T2@SEL$3
   5 - SEL$5C160134 / T3@SEL$2

Outline Data
-------------

  /*+
      BEGIN_OUTLINE_DATA
      USE_HASH(@"SEL$5C160134" "T3"@"SEL$2")
      USE_HASH(@"SEL$5C160134" "T2"@"SEL$3")
      LEADING(@"SEL$5C160134" "T1"@"SEL$3" "T2"@"SEL$3" "T3"@"SEL$2")
      FULL(@"SEL$5C160134" "T3"@"SEL$2")
      FULL(@"SEL$5C160134" "T2"@"SEL$3")
      FULL(@"SEL$5C160134" "T1"@"SEL$3")
      OUTLINE(@"SEL$3")
      OUTLINE(@"SEL$2")
      MERGE(@"SEL$3")
      OUTLINE(@"SEL$335DD26A")
      OUTLINE(@"SEL$1")
      MERGE(@"SEL$335DD26A")
      OUTLINE_LEAF(@"SEL$5C160134")
      ALL_ROWS
      DB_VERSION('11.2.0.1')
      OPTIMIZER_FEATURES_ENABLE('11.2.0.1')
      IGNORE_OPTIM_EMBEDDED_HINTS
      END_OUTLINE_DATA
  */

4. その結果を応用してグローバルヒントを与えれば、結合順序を完全に制御できます。


SQL> explain plan for
  2  select * from
  3  (
  4  select
  5        /*+ LEADING(@"SEL$5C160134" "T1"@"SEL$3" "T2"@"SEL$3" "T3"@"SEL$2" ) */
  6        v.c1 as v_c1,
  7        v.c2 as v_c2,
  8        t3.c2 as t3_c2
  9  from
 10        (select
 11         t1.c1,
 12         t2.c2
 13        from
 14         t1, t2
 15        where
 16         t1.c1 = t2.c1) v,
 17        t3
 18  where
 19        v.c1 = t3.c1
 20  ) x
 21  ;

----------------------------------------------------------------------------
| Id  | Operation           | Name | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |      |     1 |    65 |     7  (15)| 00:00:01 |
|*  1 |  HASH JOIN          |      |     1 |    65 |     7  (15)| 00:00:01 |
|*  2 |   HASH JOIN         |      |     1 |    39 |     5  (20)| 00:00:01 |
|   3 |    TABLE ACCESS FULL| T1   |     1 |    13 |     2   (0)| 00:00:01 |
|   4 |    TABLE ACCESS FULL| T2   |     1 |    26 |     2   (0)| 00:00:01 |
|   5 |   TABLE ACCESS FULL | T3   |     1 |    26 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------

5. もっと良い方法はQB_NAMEヒントでしょう。このヒントを使用すればもっと読みやすくて変更しやしはずです。


SQL> explain plan for
  2  select * from
  3  (
  4  select
  5        /*+ leading(t1@inline t2@inline t3) */
  6        v.c1 as v_c1,
  7        v.c2 as v_c2,
  8        t3.c2 as t3_c2
  9  from
 10        (select /*+ qb_name(inline) */
 11         t1.c1,
 12         t2.c2
 13        from
 14         t1, t2
 15        where
 16         t1.c1 = t2.c1) v,
 17        t3
 18  where
 19        v.c1 = t3.c1
 20  ) x
 21  ;

----------------------------------------------------------------------------
| Id  | Operation           | Name | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |      |     1 |    65 |     7  (15)| 00:00:01 |
|*  1 |  HASH JOIN          |      |     1 |    65 |     7  (15)| 00:00:01 |
|*  2 |   HASH JOIN         |      |     1 |    39 |     5  (20)| 00:00:01 |
|   3 |    TABLE ACCESS FULL| T1   |     1 |    13 |     2   (0)| 00:00:01 |
|   4 |    TABLE ACCESS FULL| T2   |     1 |    26 |     2   (0)| 00:00:01 |
|   5 |   TABLE ACCESS FULL | T3   |     1 |    26 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------

グローバルヒントの使い方を理解するに役に立つ面白いテストケースですね。

並列MERGE文章の実行計画の解析

2010-12-12T01:48:00.000-08:00

数日前に同僚の一人が並列MERGE文章の実行計画の解析に困っていることを見て、次のようにステップーバイーステップの説明をしました。

1. まずテーブルを作ります。


SQL> create table t1
  2  as
  3  select
  4         level as c1,
  5         level as c2,
  6         rpad('x',100) as c3
  7  from
  8         dual
  9  connect by level <= 10000
 10  ;

Table created.

SQL> create table t2
  2  as
  3  select
  4         level as c1,
  5         level as c2,
  6         rpad('x', 100) as c3
  7  from
  8         dual
  9  connect by level <= 10000
 10  ;

Table created.

2. 次のSQL文は並列に実行されるでしょうか。


SQL> explain plan for
  2  merge /*+ parallel */ into t1
  3   using (select c1, c2 from t2) t2
  4   on (t1.c1 = t2.c1)
  5  when matched then
  6         update set t1.c2 = t1.c2
  7  when not matched then
  8         insert(c1, c2) values(t2.c1, t2.c2)
  9  ;

Explained.

-------------------------------------------------------
| Id  | Operation                  | Name     | Rows  |
-------------------------------------------------------
|   0 | MERGE STATEMENT            |          |  9356 |
|   1 |  MERGE                     | T1       |       |
|   2 |   PX COORDINATOR           |          |       |
|   3 |    PX SEND QC (RANDOM)     | :TQ10001 |  9356 |
|   4 |     VIEW                   |          |       |
|*  5 |      HASH JOIN OUTER       |          |  9356 |
|   6 |       PX BLOCK ITERATOR    |          |  9356 |
|   7 |        TABLE ACCESS FULL   | T2       |  9356 |
|   8 |       BUFFER SORT          |          |       |
|   9 |        PX RECEIVE          |          | 11234 |
|  10 |         PX SEND BROADCAST  | :TQ10000 | 11234 |
|  11 |          PX BLOCK ITERATOR |          | 11234 |
|  12 |           TABLE ACCESS FULL| T1       | 11234 |
-------------------------------------------------------

答えはNOです。段階２番から分かるように、MERGEパート自体は直列に実行されます。

3. 理由はたぶんPARALLEL　DMLが活性化されていないからでしょう。PARALLEL　DMLを活性化したらどうなれるか確認してみます。


SQL> alter session enable parallel dml;

Session altered.

SQL> explain plan for
  2  merge /*+ parallel */ into t1
  3   using (select c1, c2 from t2) t2
  4   on (t1.c1 = t2.c1)
  5  when matched then
  6         update set t1.c2 = t1.c2
  7  when not matched then
  8         insert(c1, c2) values(t2.c1, t2.c2)
  9  ;

-------------------------------------------------------
| Id  | Operation                  | Name     | Rows  |
-------------------------------------------------------
|   0 | MERGE STATEMENT            |          |  9356 |
|   1 |  MERGE                     | T1       |       |
|   2 |   PX COORDINATOR           |          |       |
|   3 |    PX SEND QC (RANDOM)     | :TQ10001 |  9356 |
|   4 |     VIEW                   |          |       |
|*  5 |      HASH JOIN OUTER       |          |  9356 |
|   6 |       PX BLOCK ITERATOR    |          |  9356 |
|   7 |        TABLE ACCESS FULL   | T2       |  9356 |
|   8 |       BUFFER SORT          |          |       |
|   9 |        PX RECEIVE          |          | 11234 |
|  10 |         PX SEND BROADCAST  | :TQ10000 | 11234 |
|  11 |          PX BLOCK ITERATOR |          | 11234 |
|  12 |           TABLE ACCESS FULL| T1       | 11234 |
-------------------------------------------------------

また、MERGEパートが直列に実行されています。

4. たぶん、並列MERGEはもっと正確なヒントを必要にするみたいです。これは当たり前でしょう。MERGE文章は２つ以上のテーブルを使用するから。PARALLELヒントにエイリアスを追加してみましょう。


SQL> explain plan for
  2  merge /*+ parallel(t1) */ into t1
  3   using (select c1, c2 from t2) t2
  4   on (t1.c1 = t2.c1)
  5  when matched then
  6         update set t1.c2 = t1.c2
  7  when not matched then
  8         insert(c1, c2) values(t2.c1, t2.c2)
  9  ;

----------------------------------------------------
| Id  | Operation                       | Name     |
----------------------------------------------------
|   0 | MERGE STATEMENT                 |          |
|   1 |  PX COORDINATOR                 |          |
|   2 |   PX SEND QC (RANDOM)           | :TQ10003 |
|   3 |    MERGE                        | T1       |
|   4 |     PX RECEIVE                  |          |
|   5 |      PX SEND HYBRID (ROWID PKEY)| :TQ10002 |
|   6 |       VIEW                      |          |
|*  7 |        HASH JOIN OUTER BUFFERED |          |
|   8 |         BUFFER SORT             |          |
|   9 |          PX RECEIVE             |          |
|  10 |           PX SEND HASH          | :TQ10000 |
|  11 |            TABLE ACCESS FULL    | T2       |
|  12 |         PX RECEIVE              |          |
|  13 |          PX SEND HASH           | :TQ10001 |
|  14 |           PX BLOCK ITERATOR     |          |
|  15 |            TABLE ACCESS FULL    | T1       |
----------------------------------------------------

今度こそ、MERGEパートがちゃんと並列に実行されています。

5. 注意すべきのことがもう１つあります。対象テーブルT1に新しいインデックスをつけ、どんな変化が起こるか確認してみましょう。


SQL> create index t1_n1 on t1(c1);

Index created.

SQL> explain plan for
  2  merge /*+ parallel(t1) */ into t1
  3   using (select c1, c2 from t2) t2
  4   on (t1.c1 = t2.c1)
  5  when matched then
  6         update set t1.c2 = t1.c2
  7  when not matched then
  8         insert(c1, c2) values(t2.c1, t2.c2)
  9  ;

---------------------------------------------------------------
| Id  | Operation                          | Name     | Rows  |
---------------------------------------------------------------
|   0 | MERGE STATEMENT                    |          |  9356 |
|   1 |  PX COORDINATOR                    |          |       |
|   2 |   PX SEND QC (RANDOM)              | :TQ10004 |  9356 |
|   3 |    INDEX MAINTENANCE               | T1       |       |
|   4 |     PX RECEIVE                     |          |  9356 |
|   5 |      PX SEND RANGE                 | :TQ10003 |  9356 |
|   6 |       MERGE                        | T1       |       |
|   7 |        PX RECEIVE                  |          |  9356 |
|   8 |         PX SEND HYBRID (ROWID PKEY)| :TQ10002 |  9356 |
|   9 |          VIEW                      |          |       |
|* 10 |           HASH JOIN OUTER BUFFERED |          |  9356 |
|  11 |            BUFFER SORT             |          |       |
|  12 |             PX RECEIVE             |          |  9356 |
|  13 |              PX SEND HASH          | :TQ10000 |  9356 |
|  14 |               TABLE ACCESS FULL    | T2       |  9356 |
|  15 |            PX RECEIVE              |          | 11234 |
|  16 |             PX SEND HASH           | :TQ10001 | 11234 |
|  17 |              PX BLOCK ITERATOR     |          | 11234 |
|  18 |               TABLE ACCESS FULL    | T1       | 11234 |
---------------------------------------------------------------

INDEX MAINTENANCEと言う新しい段階が現れます。インデックスメンテナンスのためにもう一つのテーブルキューTQ10004が使用されることも分かります。問題は、なぜここでインデックスメンテナンスをするのかということです。

並列MERGEは並列UPDATEと並列INSERTで構成されます。
並列INSERTとはダイレクトパスINSERTです。
ダイレクトパスINSERTが終わったら、インデックスに変更内容を反映しなければなりません。

OracleはダイレクトパスINSERTの後で、インデックスのメンテナンスをするようになっています。この機能は_idl_conventional_index_maintenanceという隠しパラメーターで制御されます。


SQL> select * from table(tpack.param('_idl_conventional_index_maintenance'));

NAME                                VALUE
----------------------------------- ----------------------------------------
Name #1                             _idl_conventional_index_maintenance
  Value                             TRUE
  Is Default                        TRUE
  Sess Modifiable                   false
  Sys Modifiable                    false
  Description                       enable conventional index maintenance fo
                                    r insert direct load

INDEX MAINTENANCEの段階はインデックスをUNUSABLEさせても消えません。でも、実際に実行する際にはUNUSABLE状態のインデックスはメンテナンスされないはずです。


SQL> alter index t1_n1 unusable;

Index altered.

SQL> explain plan for
  2  merge /*+ parallel(t1) */ into t1
  3   using (select c1, c2 from t2) t2
  4   on (t1.c1 = t2.c1)
  5  when matched then
  6         update set t1.c2 = t1.c2
  7  when not matched then
  8         insert(c1, c2) values(t2.c1, t2.c2)
  9  ;

---------------------------------------------------------------
| Id  | Operation                          | Name     | Rows  |
---------------------------------------------------------------
|   0 | MERGE STATEMENT                    |          |  9356 |
|   1 |  PX COORDINATOR                    |          |       |
|   2 |   PX SEND QC (RANDOM)              | :TQ10004 |  9356 |
|   3 |    INDEX MAINTENANCE               | T1       |       |
|   4 |     PX RECEIVE                     |          |  9356 |
|   5 |      PX SEND RANGE                 | :TQ10003 |  9356 |
|   6 |       MERGE                        | T1       |       |
|   7 |        PX RECEIVE                  |          |  9356 |
|   8 |         PX SEND HYBRID (ROWID PKEY)| :TQ10002 |  9356 |
|   9 |          VIEW                      |          |       |
|* 10 |           HASH JOIN OUTER BUFFERED |          |  9356 |
|  11 |            BUFFER SORT             |          |       |
|  12 |             PX RECEIVE             |          |  9356 |
|  13 |              PX SEND HASH          | :TQ10000 |  9356 |
|  14 |               TABLE ACCESS FULL    | T2       |  9356 |
|  15 |            PX RECEIVE              |          | 11234 |
|  16 |             PX SEND HASH           | :TQ10001 | 11234 |
|  17 |              PX BLOCK ITERATOR     |          | 11234 |
|  18 |               TABLE ACCESS FULL    | T1       | 11234 |
---------------------------------------------------------------

私の説明が役に立ったのか分かりませんが、ともかくこのようにブログに残します。

Oracle 11gのSerial Direct Path Readと_very_large_object_thresholdパラメータパラメータ

2010-11-02T01:17:00.000-07:00

次のポストを通じてOracle 11gのSerial Direct Path Readを制御する方法を紹介したことがあります。

オラクル11ｇのserial全表スキャンに対するdirect path read非活性化しよう。

ポストの核心は10949診断イベントを利用してSerial Direct Path Readを不活性化することが可能だということです。

最近Serial Direct Path Readを制御するもう１つの隠しパラメータを知るようになりました。_VERY_LARGE_OBJECT_THRESHOLD隠しパラメータです。例えば、このパラメータの値が「500」ならば、セグメントのサイズが500MNB以上だったら10949診断イベントとは無関係にSerail Direct Path Readが使用されるようになります。これが意味するのは大きすぎるテーブルは可能なかぎりSerial Direct Path Readを使用しろということです。とても合理的な決定だと思います。

簡単なテストケースで説明してみます。

1. Oracleのバージョンは11.2.0.1です。


SQL> select * from v$version where rownum = 1;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

2. _VERY_LARGE_OBJECT_THRESHOLDパラメータの値は500(MB)です。


SQL> @para very_large_object
SQL> set echo off
old   9: and i.ksppinm like '%&1%'
new   9: and i.ksppinm like '%very_large_object%'

NAME                           VALUE                IS_DEFAUL SES_MODIFI SYS_MODIFI
------------------------------ -------------------- --------- ---------- ----------
DESCRIPTION
-------------------------------------------------------------------------------------
_very_large_object_threshold   500                  TRUE      true       deferred
upper threshold level of object size for direct reads

3. 約104MBのサイズのテーブルT_VLOTを作り、セッションレベルで94MBを_VERY_LARGE_OBJECT_THRESHOLDパラメータの値で指定します。


SQL> create table t_vlot
  2  as
  3  select
  4   rpad('x',2000) as c1,
  5   rpad('x',2000) as c2,
  6   rpad('x',2000) as c3,
  7   rpad('x',2000) as c4
  8  from dual
  9  connect by level <= 6500
 10  ;

Table created.

SQL> col tsize new_value tsize
SQL> select trunc(blocks*8*1024/1024/1024) - 10 as tsize
  2  from dba_segments
  3  where owner = user and segment_name = 'T_VLOT'
  4  ;

     TSIZE
----------
        94

SQL> 
SQL> alter session set "_very_large_object_threshold" = &tsize;
old   1: alter session set "_very_large_object_threshold" = &tsize
new   1: alter session set "_very_large_object_threshold" =         94

Session altered.

10949診断イベントを活性化し、T_VLOTテーブルに対してTable Full Scanを行ないます。そして10046診断イベントを通じて待機イベントを分析します。


SQL> -- even when 10949 is enabled
SQL> alter session set events '10949 trace name context forever, level 1';

Session altered.

SQL> alter system flush buffer_cache;

System altered.

SQL> exec tpack.begin_diag_trace(userenv('sid'), 10046, 8);

PL/SQL procedure successfully completed.

SQL> select count(*) from t_vlot;

  COUNT(*)
----------
      6500

SQL> exec tpack.end_diag_trace(userenv('sid'), 10046);

PL/SQL procedure successfully completed.

SQL> select * from table(tpack.get_diag_trace(userenv('sid'), 'TKPROF', 'sys=no'));

5. 次にその結果があります。10949イベントが活性化されていますが、direct path read待機イベントが現れます。Serial Direct Path Readが動作したという意味です。


SQL ID: 1n87ukuyyv5h2
Plan Hash: 2969598161
select count(*)
from
 t_vlot


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          1          1          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.09       2.86      13000      13004          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.09       2.86      13001      13005          0           1

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 97

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  SORT AGGREGATE (cr=13004 pr=13000 pw=0 time=0 us)
   6500   TABLE ACCESS FULL T_VLOT (cr=13004 pr=13000 pw=0 time=60657 us cost=3575 size=0 card=6473)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential read                         1        0.00          0.00
  SQL*Net message to client                       2        0.00          0.00
  direct path read                              412        0.04          2.73
  asynch descriptor resize                        1        0.00          0.00
  SQL*Net message from client                     2        0.00          0.00

たとえ診断イベントと隠しパラメータを通じてSerial Direct Path Readを完全に不活性化できますが、この機能は基本的に良い機能です。バッチI/Oの性能が優れた多くのストレージで良い性能を見せてくれるのを期待できます。本番環境で色々なファクターを考えて適切に制御する必要があります。

結合の手順の制御

2010-10-25T23:22:00.000-07:00

Oracleが提供するヒントが強すぎて、基本的なことを忘れてしまうことがあります。たまにはヒントがないとしたらどんな方法で実行計画を制御しようかを考えてみれば面白いことを見つけるようになるでしょう。

例えば、次のような五つのテーブルがあります。


create table t1(c1, c2)
as 
select
  level, level
from dual
connect by level <= 5000;

create table t2(c1, c2)
as 
select
  level, level
from dual
connect by level <= 4000;

create table t3(c1, c2)
as 
select
  level, level
from dual
connect by level <= 3000;

create table t4(c1, c2)
as 
select
  level, level
from dual
connect by level <= 2000;

create table t5(c1, c2)
as 
select
  level, level
from dual
connect by level <= 1000;

create index t1_n1 on t1(c1);
create index t2_n1 on t2(c1);
create index t3_n1 on t3(c1);
create index t4_n1 on t4(c1);
create index t5_n1 on t5(c1);

exec dbms_stats.gather_table_stats(user, 't1');
exec dbms_stats.gather_table_stats(user, 't2');
exec dbms_stats.gather_table_stats(user, 't3');
exec dbms_stats.gather_table_stats(user, 't4');
exec dbms_stats.gather_table_stats(user, 't5');

テーブルT1, T2, T3, T4, T5を結合するクエリで結合手順はどうなりましょうか。テーブルのデータ分布を見るとT1(c1 between 1 and 10 条件のため）がドライビングテーブルになり、その次はT5(1000件）、T4(2000件）、T3(3000件）、T2(4000件）になるのが分かります。


explain plan for
select 
 *
from
 t1, t2, t3, t5, t4
where
 t1.c1 = t2.c1
 and t1.c1 = t3.c1
 and t1.c1 = t4.c1
 and t1.c1 = t5.c1
 and t1.c2 between 1 and 10
;

--------------------------------------
| Id  | Operation             | Name |
--------------------------------------
|   0 | SELECT STATEMENT      |      |
|*  1 |  HASH JOIN            |      |
|*  2 |   HASH JOIN           |      |
|*  3 |    HASH JOIN          |      |
|*  4 |     HASH JOIN         |      |
|*  5 |      TABLE ACCESS FULL| T1   |
|   6 |      TABLE ACCESS FULL| T5   |
|   7 |     TABLE ACCESS FULL | T4   |
|   8 |    TABLE ACCESS FULL  | T3   |
|   9 |   TABLE ACCESS FULL   | T2   |
--------------------------------------

結合の手順をT1 -> T2 -> T3 -> T4 -> T5としたいと言ったらどう？次のようにORDEREDヒントを使えばいいでしょう。またはLEADING(t1 t2 t3 t4 t5)ヒントを使ってもいいです。


explain plan for
select /*+ ordered */
 *
from
 t1, t2, t3, t5, t4
where
 t1.c1 = t2.c1
 and t1.c1 = t3.c1
 and t1.c1 = t4.c1
 and t1.c1 = t5.c1
 and t1.c2 between 1 and 10
;

--------------------------------------
| Id  | Operation             | Name |
--------------------------------------
|   0 | SELECT STATEMENT      |      |
|*  1 |  HASH JOIN            |      |
|*  2 |   HASH JOIN           |      |
|*  3 |    HASH JOIN          |      |
|*  4 |     HASH JOIN         |      |
|*  5 |      TABLE ACCESS FULL| T1   |
|   6 |      TABLE ACCESS FULL| T2   |
|   7 |     TABLE ACCESS FULL | T3   |
|   8 |    TABLE ACCESS FULL  | T4   |
|   9 |   TABLE ACCESS FULL   | T5   |
--------------------------------------

仮にヒントを使用せず（そしてRBOではなくてCBOと言えば）、結合の手順が常に上のように出るようにしたいといったらどうすればいいでしょうか。ヒントに慣れてしまえばこのような簡単な質問に答えることが難しくなりかねません。

最も典型的な方法は次のようにt1.c1 = t3.c1の条件をt1.c1 + 0*t2.c1 = t3.c1のような形で使用することです。t3.c1で結合が可能になるためにはt2.c1の値を知らなければならないので、T2 -> T3の手順しか結合方法がありません。同じ原理で条件を付けば全ての結合手順を制御できます。


explain plan for
select 
 *
from
 t1, t2, t3, t4, t5
where
 t1.c1 = t2.c1
 and t1.c1 + 0*t2.c1 = t3.c1  -- t2.c1値なしは t3.c1の結合不可能
 and t1.c1 + 0*t3.c1= t4.c1  -- t3.c1値なしはt4.c1の結合不可能
 and t1.c1 + 0*t4.c1 = t5.c1  -- t4.c1値なしは t5.c1結合不可能
 and t1.c2 between 1 and 10
;

--------------------------------------
| Id  | Operation             | Name |
--------------------------------------
|   0 | SELECT STATEMENT      |      |
|*  1 |  HASH JOIN            |      |
|*  2 |   HASH JOIN           |      |
|*  3 |    HASH JOIN          |      |
|*  4 |     HASH JOIN         |      |
|*  5 |      TABLE ACCESS FULL| T1   |
|   6 |      TABLE ACCESS FULL| T2   |
|   7 |     TABLE ACCESS FULL | T3   |
|   8 |    TABLE ACCESS FULL  | T4   |
|   9 |   TABLE ACCESS FULL   | T5   |
--------------------------------------

このような方法を応用すれば結合の手順を自由に制御できます。例えば結合の手順をT1 -> T2 -> T4 -> T3 -> T5（T4がT3より先に結合されるように）とするためにはどうすればいいでしょうか。


explain plan for
select 
 *
from
 t1, t2, t3, t4, t5
where
 t1.c1 = t2.c1
 { ここにどんな条件があれば下のような結合手順が？ }
 and t1.c2 between 1 and 10
;

--------------------------------------
| Id  | Operation             | Name |
--------------------------------------
|   0 | SELECT STATEMENT      |      |
|*  1 |  HASH JOIN            |      |
|*  2 |   HASH JOIN           |      |
|*  3 |    HASH JOIN          |      |
|*  4 |     HASH JOIN         |      |
|*  5 |      TABLE ACCESS FULL| T1   |
|   6 |      TABLE ACCESS FULL| T2   |
|   7 |     TABLE ACCESS FULL | T4   |
|   8 |    TABLE ACCESS FULL  | T3   |
|   9 |   TABLE ACCESS FULL   | T5   |
--------------------------------------

解答はもう公開されていたも同然ですからここに書くことはしません。

でもやっぱりヒントが便利ですね。

RAW値の切り替え

2010-10-12T00:28:00.000-07:00

ディクショナリーを検索してみるとRAWの形で提供されるコラムが時々あります。例えばUSER_TAB_COLSビューでコラムの最小値と最大値を見ると次のように意味の分からない変な値と見えます。


SQL> col column_name format a10
SQL> col data_type format a10
SQL> select
  2   column_name,
  3   data_type,
  4   low_value,
  5   high_value
  6  from
  7   user_tab_cols
  8  where
  9   table_name = 'T1'
 10  ;

COLUMN_NAM DATA_TYPE  LOW_VALUE            HIGH_VALUE
---------- ---------- -------------------- --------------------
C1         NUMBER     C102                 C302
C2         VARCHAR2   6D616E79             6F6E65

このような値たちはUTL_RAW　パッケージで切り替えられます。


SQL> select utl_raw.cast_to_number('C102') from dual;

UTL_RAW.CAST_TO_NUMBER('C102')
------------------------------
                             1

SQL> select utl_raw.cast_to_varchar2('6D616E79') from dual;

UTL_RAW.CAST_TO_VARCHAR2('6D616E79')
--------------------------------------------------------------------------------
many

次のように使用されるでしょう。


SQL> select
  2   column_name,
  3   data_type,
  4   decode(data_type,
  5    'NUMBER', utl_raw.cast_to_number(low_value)||'',
  6    'VARCHAR2', utl_raw.cast_to_varchar2(low_value), low_value||'') as low_value,
  7   decode(data_type,
  8    'NUMBER', utl_raw.cast_to_number(high_value)||'',
  9    'VARCHAR2', utl_raw.cast_to_varchar2(high_value), high_value||'') as high_value
 10  from
 11   user_tab_cols
 12  where
 13   table_name = 'T1'
 14  ;

COLUMN_NAM DATA_TYPE  LOW_VALUE            HIGH_VALUE
---------- ---------- -------------------- --------------------
C1         NUMBER     1                    10000
C2         VARCHAR2   many                 one

DBMS_STATS　パッケージも同一な役割の関数を提供します。でも、パラメータの指定しかたが少し違います。使用の便利性のために次のように使用者定義関数を作ります。


SQL> -- dbms_stats (conversion)
SQL> create or replace function convert_me(p_value in raw, p_type in varchar2)
  2  return varchar2
  3  is
  4     v_number  number;
  5     v_varchar2   varchar2(4000);
  6  begin
  7     if (p_type = 'NUMBER') then
  8        dbms_stats.convert_raw_value(p_value, v_number);
  9        return v_number|| '';
 10     elsif (p_type = 'VARCHAR2') then
 11        dbms_stats.convert_raw_value(p_value,v_varchar2);
 12        return v_varchar2;
 13     /* other data types */
 14     else
 15        return p_value || '';
 16     end if;
 17  end;
 18  /

Function created.

SQL> 
SQL> select convert_me('C102', 'NUMBER') from dual;

CONVERT_ME('C102','NUMBER')
--------------------------------------------------------------------------------
1

SQL> select convert_me('6D616E79', 'VARCHAR2') from dual;

CONVERT_ME('6D616E79','VARCHAR2')
--------------------------------------------------------------------------------
many

そうすると次のようにSQL文内で使用できます。


SQL> select
  2   column_name,
  3   data_type,
  4   convert_me(low_value, data_type) as low_value,
  5   convert_me(high_value, data_type) as high_value
  6  from
  7   user_tab_cols
  8  where
  9   table_name = 'T1'
 10  ;

COLUMN_NAM DATA_TYPE  LOW_VALUE            HIGH_VALUE
---------- ---------- -------------------- --------------------
C1         NUMBER     1                    10000
C2         VARCHAR2   many                 one

上のような面倒なことをしなくても良いようにOracleが自ら切り替えてくれたら良かったんですけどね。ともかく時折こんな切り替え作業が必要なところがあります。その際、活用すれば良いでしょう。

Batching NLJに対するOracleマニュアルの説明

2010-10-11T02:59:00.000-07:00

Oracle 11gのBatching NLJにより物理I/Oが発生する時、整列が壊れてしまうように見える現象をこのポストで紹介したことがあります。

今日偶然にOracleマニュアル(Performance Tuning Guide)でOracle 11gのBatching NLJに対して説明している部分を見つかったんです。

11.3.3.1.2 New Implementation for Nested Loop Joins

単純で明確に説明してあります。この説明と共に私が説明したヒントと隠しパラメーターを理解していただければ本番環境で問題が発生した際、効果的に対処できるはずです。

PLAN_HASH_VALUE

2010-10-06T23:07:00.000-07:00

SQL AとSQL Bの実行計画がお互いに同じか違うか比べられる一番易い方法は何でしょうか。

Oracleがて提供するPLAN_HASH_VALUEが正解ではないかと思います。この値は文字通り実行計画に対するハッシュねであります。ハッシュねなので100%の唯一性が保障されてはいないが、殆ど大部分の場合識別するに使えます。

Oracleでは同一なSQLテキストのSQLカーソルが複数の実行計画が持てます。こんな柔らかのおかげでいろいろな性能問題が現れますが...

簡単な例えを通して説明してみます。この例えはOracle 11gのAdaptive Cursor Sharing機能を利用しています。

Oracleのバージョンは11gR2です。


TPACK@ukja1120> select * from v$version where rownum = 1;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

偏りのある表を持つテーブルT1を作ります。列C1に対して索引を作り、ヒストグラムも作ります。


TPACK@ukja1120> 
TPACK@ukja1120> create table t1
  2  as
  3  select level as c1 from dual connect by level <= 10000
  4  union all
  5  select 1 as c1 from dual connect by level <= 100000
  6  ;

Table created.

TPACK@ukja1120> 
TPACK@ukja1120> create index t1_n1 on t1(c1);

Index created.

TPACK@ukja1120> 
TPACK@ukja1120> exec dbms_stats.gather_table_stats(user, 't1', method_opt=>'for all columns size skewonly');

PL/SQL procedure successfully completed.

「100」の値が条件で使われる時はIndex Range Scanを使用します。


TPACK@ukja1120> explain plan for
  2  select count(*) from t1 where c1 = 100;

Explained.

TPACK@ukja1120> select * from table(dbms_xplan.display);
---------------------------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |     1 |     3 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE   |       |     1 |     3 |            |          |
|*  2 |   INDEX RANGE SCAN| T1_N1 |     1 |     3 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------

「1」の値が条件で使われる時はTable FullScanを使用します。


TPACK@ukja1120> explain plan for
  2  select count(*) from t1 where c1 = 1;

Explained.

TPACK@ukja1120> select * from table(dbms_xplan.display);
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |     3 |    53   (4)| 00:00:01 |
|   1 |  SORT AGGREGATE    |      |     1 |     3 |            |          |
|*  2 |   TABLE ACCESS FULL| T1   | 99173 |   290K|    53   (4)| 00:00:01 |
---------------------------------------------------------------------------

「100」と「1」と値を繰り返しながらクエリを実行します。バインド変数を使用してAdpative Cursor Sharingが働くようにします。


TPACK@ukja1120> var b1 number;
TPACK@ukja1120> exec :b1 := 100;

PL/SQL procedure successfully completed.

TPACK@ukja1120> select count(*) from t1 where c1 = :b1;

  COUNT(*)
----------
         1

TPACK@ukja1120> 
TPACK@ukja1120> exec :b1 := 1;

PL/SQL procedure successfully completed.

TPACK@ukja1120> select count(*) from t1 where c1 = :b1;

  COUNT(*)
----------
    100001

TPACK@ukja1120> 
TPACK@ukja1120> exec :b1 := 100;

PL/SQL procedure successfully completed.

TPACK@ukja1120> select count(*) from t1 where c1 = :b1;

  COUNT(*)
----------
         1

TPACK@ukja1120> 
TPACK@ukja1120> exec :b1 := 1;

PL/SQL procedure successfully completed.

TPACK@ukja1120> select count(*) from t1 where c1 = :b1;

  COUNT(*)
----------
    100001

TPACK@ukja1120> 
TPACK@ukja1120> exec :b1 := 100;

PL/SQL procedure successfully completed.

TPACK@ukja1120> select count(*) from t1 where c1 = :b1;

  COUNT(*)
----------
         1

TPACK@ukja1120> 
TPACK@ukja1120> exec :b1 := 1;

PL/SQL procedure successfully completed.

TPACK@ukja1120> select count(*) from t1 where c1 = :b1;

  COUNT(*)
----------
    100001

TPACK@ukja1120> 
TPACK@ukja1120> exec :b1 := 100;

PL/SQL procedure successfully completed.

TPACK@ukja1120> select count(*) from t1 where c1 = :b1;

  COUNT(*)
----------
         1

TPACK@ukja1120> 
TPACK@ukja1120> exec :b1 := 1;

PL/SQL procedure successfully completed.

TPACK@ukja1120> select count(*) from t1 where c1 = :b1;

  COUNT(*)
----------
    100001

四つのチャイルドカーソルができました。


TPACK@ukja1120> col sql_id new_value sql_id
TPACK@ukja1120> select sql_id, version_count, plan_hash_value
  2  from v$sqlarea
  3  where sql_text = 'select count(*) from t1 where c1 = :b1';

SQL_ID        VERSION_COUNT PLAN_HASH_VALUE
------------- ------------- ---------------
7dwqb1wjmp5hm             4        73337487

チャイルドカーソルを表すV$SQLビューを見るとチャイルドは四つですけどPLAN_HASH_VALUEは2つが存在します。すなわち、実際の実行計画は2つ(Index Range Scan + Table Full Scan)だけです。


TPACK@ukja1120> select sql_id, child_number, plan_hash_value
  2  from v$sql
  3  where sql_id = '&sql_id';
old   3: where sql_id = '&sql_id'
new   3: where sql_id = '7dwqb1wjmp5hm'

SQL_ID        CHILD_NUMBER PLAN_HASH_VALUE
------------- ------------ ---------------
7dwqb1wjmp5hm            0        73337487
7dwqb1wjmp5hm            1        73337487
7dwqb1wjmp5hm            2        73337487
7dwqb1wjmp5hm            3      3724264953

DBMS_XPLAN.DISPLAY_CURSOR関数を利用して実行計画を検索してみると、詳細な情報が得られます。


TPACK@ukja1120> select * from table(dbms_xplan.display_cursor('&sql_id', null));
old   1: select * from table(dbms_xplan.display_cursor('&sql_id', null))
new   1: select * from table(dbms_xplan.display_cursor('7dwqb1wjmp5hm', null))

Plan hash value: 73337487

---------------------------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |       |       |     1 (100)|          |
|   1 |  SORT AGGREGATE   |       |     1 |     3 |            |          |
|*  2 |   INDEX RANGE SCAN| T1_N1 |     1 |     3 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------

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

   2 - access("C1"=:B1)

SQL_ID  7dwqb1wjmp5hm, child number 1
-------------------------------------
select count(*) from t1 where c1 = :b1

Plan hash value: 73337487

---------------------------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |       |       |     1 (100)|          |
|   1 |  SORT AGGREGATE   |       |     1 |     3 |            |          |
|*  2 |   INDEX RANGE SCAN| T1_N1 |     1 |     3 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------

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

   2 - access("C1"=:B1)

SQL_ID  7dwqb1wjmp5hm, child number 2
-------------------------------------
select count(*) from t1 where c1 = :b1

Plan hash value: 73337487

---------------------------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |       |       |     1 (100)|          |
|   1 |  SORT AGGREGATE   |       |     1 |     3 |            |          |
|*  2 |   INDEX RANGE SCAN| T1_N1 |     1 |     3 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------

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

   2 - access("C1"=:B1)

SQL_ID  7dwqb1wjmp5hm, child number 3
-------------------------------------
select count(*) from t1 where c1 = :b1

Plan hash value: 3724264953

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |       |       |    53 (100)|          |
|   1 |  SORT AGGREGATE    |      |     1 |     3 |            |          |
|*  2 |   TABLE ACCESS FULL| T1   | 99173 |   290K|    53   (4)| 00:00:01 |
---------------------------------------------------------------------------

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

   2 - filter("C1"=:B1)


76 rows selected.

PLAN_HASH_VALUEが実行計画を分けるに使用できるという特徴を利用したら、実行計画の変更を分析するに使用することまできます。例えば、AWRに格納されているTop SQLとSQLテキストは同様ですがPLAN_HASH_VALUEは違う新しいSQL文が現れたら、実行計画の変更が発生したのではないか疑われます。

1つ注意していただきたいこてゃ、1つのSQLテキストに複数の実行計画が持てるから、精密な分析は必要だということです。

待機イベントが含まれている10046診断イベントの実行ーOracle11g

2010-09-27T23:23:00.000-07:00

Oracle 11gで待機イベントが含まれている10046診断イベントの実行方法を整えてみました。

1. 伝統的な10046診断イベントの使い方は次のとおりです。レベル８以上なら待機イベントが記録されます。


alter session set events '10046 trace name context forever, level 8';

select /* 10046 */ count(*) from user_objects;

alter session set events '10046 trace name context off';

2. 11gからは次のようにsql_traceという「認識できる」名前の診断イベントが使えます。


-- sql_trace + level 8
alter session set events 'sql_trace level 8';

select /* sql_trace_1 */ count(*) from user_objects;

alter session set events 'sql_trace off';

-- sql_trace + wait=true
alter session set events 'sql_trace wait=true';

select /* sql_trace_2 */ count(*) from user_objects;

alter session set events 'sql_trace off';

-- sql_trace + wait=true, bind=true
alter session set events 'sql_trace wait=true, bind=true';

select /* sql_trace_3 */ count(*) from user_objects;

alter session set events 'sql_trace off';

11gから追加された新しい診断イベント機能は強すぎて、次のように特定のSQLを特定することもできます。あまりに有効な機能であるんでしょう。


-- SQL_IDを得て...
select /* sql_trace_4 */ count(*) from user_objects;
select /* sql_trace_5 */ count(*) from user_objects;

col sql_id new_value sql_id1
select sql_id 
from v$sqlarea 
where sql_text = 'select /* sql_trace_4 */ count(*) from user_objects';

col sql_id new_value sql_id2
select sql_id 
from v$sqlarea 
where sql_text = 'select /* sql_trace_5 */ count(*) from user_objects';

-- 1つのSQLに対して
alter session set events 'sql_trace [sql: &sql_id1] wait=true';
select /* sql_trace_4 */ count(*) from user_objects;
select /* sql_trace_5 */ count(*) from user_objects;
alter session set events 'sql_trace off';

-- 複数のSQLに対して
alter session set events 'sql_trace [sql: &sql_id1 | &sql_id2] wait=true';
select /* sql_trace_4 */ count(*) from user_objects;
select /* sql_trace_5 */ count(*) from user_objects;
alter session set events 'sql_trace off';

3. DBMS_MONITORパッケージこそオラクルの公式的なお勧めの方法です。DBMS_MONITORパッケージもSQLを特定する機能が提供したらいいけど、開発者等がまだそこまでは考えていないようです。


exec dbms_monitor.session_trace_enable(waits=>true);

select /* dbms_monitor */ count(*) from user_objects;

exec dbms_monitor.session_trace_disable;

4. DBMS_SYSTEMパッケージやDBMS_SUPPORTパッケージなどの隠しパッケージも同様な機能を提供しています。でも、DBMS_MONITORパッケージが登場した以上必要がなくなったといえます。


col sid new_value sid
col serial# new_value se
select sid, serial# 
from v$session 
where sid = userenv('sid');

exec sys.dbms_system.set_ev(&sid, &se, 10046, 8, null);

select /* dbms_system */ count(*) from user_objects;

exec sys.dbms_system.set_ev(&sid, &se, 10046, 0, null);

SQL_ID値を利用して特定SQLに対してのみ診断イベントを行なう機能が特に有効に見えます。Oracle 11gの拡張された診断イベント機能は次の文書で詳細に紹介しています。

ORADEBUG DOC

Library Cache Pinに対するSelf Deadlockを作ってみよう。

2010-09-15T18:15:00.000-07:00

Library Cache Pinに対するSelf Deadlockをとても易く作ってみます。まず次のように空いたプロシージャであるTEST_PROC1を作ります。


create or replace procedure test_proc1 
is
begin
 null;
end;
/

次のPL/SQLブロックでTEST_PROC1を実行し、まのなくTEST_PROC1をコンパイルします。そうすると、セッションはハング状態に落ちってしまいます。


TPACK@ukja1120> begin
  2     test_proc1;
  3
  4     execute immediate 'alter procedure test_proc1 compile';
  5
  6  end;
  7  /

...
(Hang)

ASH(Active Session History)を通じて該当セッションの状態を分析してみると、WaiterとBlockerが一致していることが分かります。Self Deadlockという状態です。


select * 
from (
 select
  h.session_id as sid,
  to_char(h.sample_time,'mi:ss') as sample_time,
  h.sql_id,
  (select sql_text from v$sqlarea a where a.sql_id = h.sql_id) as sql_text,
  event,
  blocking_session as blocker
 from
  v$active_session_history h
 where
  h.session_id = &sid
 order by h.sample_time desc   
) where rownum <= 20 
;     

 SID SAMPL SQL_ID        SQL_TEXT             EVENT         BLOCKER
---- ----- ------------- -------------------- ---------- ----------
 136 49:10                                    library ca        136
                                              che pin

 136 49:09                                    library ca        136
                                              che pin

 136 49:08                                    library ca        136
                                              che pin

 136 49:07                                    library ca        136
                                              che pin

 136 49:06                                    library ca        136
                                              che pin

 136 49:05                                    library ca        136
                                              che pin

 136 49:04                                    library ca        136
                                              che pin

 136 49:03                                    library ca        136
                                              che pin

 136 49:02                                    library ca        136
                                              che pin

 136 49:01                                    library ca        136
                                              che pin

 136 49:00                                    library ca        136
                                              che pin

 136 48:59                                    library ca        136
                                              che pin

 136 48:58                                    library ca        136
                                              che pin

 136 48:57                                    library ca        136
                                              che pin

 136 48:56                                    library ca        136
                                              che pin

 136 48:55                                    library ca        136
                                              che pin

 136 48:54                                    library ca        136
                                              che pin

 136 48:53                                    library ca        136
                                              che pin

 136 48:52                                    library ca        136
                                              che pin

 136 48:51                                    library ca        136
                                              che pin


20 rows selected.

ティパックが提供する待機イベントの詳細情報からもっと詳しい状態が得られます。


TPACK@ukja1120> select * from table(tpack.session_detail(136,'wait_detail'))

NAME                           VALUE
------------------------------ --------------------
SID                            136
Serial#                        2797
SPID                           5148
Program                        sqlplus.exe
Process                        5404:672
Module                         SQL*Plus
SQL ID                         9pbva4bn2m25b
Child No                       0
SQL Text                       alter procedure test
                               _proc1 compile

Status                         ACTIVE
Blocking Instance              1
Blocking Session               136
SQL Exec Start                 2010/09/15 13:45:34
Event                          library cache pin
Seq#                           130
P1(P1raw)                      384372376(0000000016
                               E90E98)

P2(P2raw)                      384372376(0000000016
                               DAB608)

P3(P3raw)                      384372376(00014F8500
                               010003)

Seconds in wait                40
State                          WAITING
Wait Event                     library cache pin
Holder SID                     136
Namespace                      TABLE/PROCEDURE
Object                         TEST_PROC1
Holding Mode                   2(S)

理由は何と考えますか？

Remote SQL

2010-09-09T00:40:00.000-07:00

数日前にデータベースリンクを使う分散クエリ(Distributed Query)の動作原理に対する質問を受けました。それに対する答えを簡単なテストでします。

テスト環境はOracle 11.1.0.6です。


TPACK@ukja1106> -- version
TPACK@ukja1106> select * from v$version where rownum = 1;

BANNER
-----------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production

分散クエリのためにループバックデータベースリンクを作ります。ループバックデータベースリンクとは自己自身がリモートデータベースとなるデータベースリンクとことを意味します。


TPACK@ukja1106> -- create loopback database link
TPACK@ukja1106> create public database link loopback
  2  connect to {user}
  3  identified by {password}
  4  using '{service_name}';

Database link created.

テーブルT1、T2を作ります。


TPACK@ukja1106> -- create table
TPACK@ukja1106> create table t1(c1, c2)
  2  as
  3  select level, level
  4  from dual
  5  connect by level <= 1000
  6  ;

Table created.

TPACK@ukja1106> 
TPACK@ukja1106> create table t2(c1, c2)
  2  as
  3  select level, level
  4  from dual
  5  connect by level <= 1000
  6  ;

Table created.

TPACK@ukja1106> 
TPACK@ukja1106> create index t2_n1 on t2(c1);

Index created.

TPACK@ukja1106> 
TPACK@ukja1106> exec dbms_stats.gather_table_stats(user, 't1');

PL/SQL procedure successfully completed.

TPACK@ukja1106> exec dbms_stats.gather_table_stats(user, 't2');

PL/SQL procedure successfully completed.

テーブルT1(ローカル)が先行テーブルとなり、テーブルT2(リモート)が結合対象となる分散くえりの実行計画です。Remote SQL Informationという部分に注意してください。


TPACK@ukja1106> -- explain plan
TPACK@ukja1106> -- nested loops join
TPACK@ukja1106> 
TPACK@ukja1106> -- execute it, but 0 row
TPACK@ukja1106> explain plan for
  2  select /*+ leading(t1) use_nl(d) */
  3   *
  4  from t1, t2@loopback d
  5  where t1.c1 = d.c1
  6   and t1.c1 < 0
  7  ;

TPACK@ukja1106> select * from table(dbms_xplan.display);

---------------------------------------------------
| Id  | Operation          | Name | Inst   |IN-OUT|
---------------------------------------------------
|   0 | SELECT STATEMENT   |      |        |      |
|   1 |  NESTED LOOPS      |      |        |      |
|*  2 |   TABLE ACCESS FULL| T1   |        |      |
|   3 |   REMOTE           | T2   | LOOPB~ | R->S |
---------------------------------------------------

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

   2 - filter("T1"."C1"<0)

Remote SQL Information (identified by operation id):
----------------------------------------------------

   3 - SELECT /*+ USE_NL ("D") */ "C1","C2" FROM "T2" "D" WHERE "C1"<0 AND :1="C1"
       (accessing 'LOOPBACK' )

Remote SQLとは分散くえりを実行する時、リモートデータベースからデータを伝送させられうためにリモートデータベースで実行するSQLのことです。すなわち、ローカルデータベースはRemote SQLをリモートデータベースに発行してほしいデータを受け付けます。

ローカルデータベースはリモートデータベースからリモートテーブルとインデックスの基本統計情報を伝送されます。その情報を利用して実行計画を作ります。この過程でRemote SQLを作ります。Remote SQLは実際にデータを伝送されるために実行するまではリモートデータベースに送りません。

これを証明するために、クエリを実行した後、リモートデータベースでRemote SQLが実行されたかどうか確認してみます。次のクエリを実行したら、先行テーブルから一件の行もでないので（t1.c1 < 0 の条件のため）リモートデータベースへのデータリクエストもないはずです。つぎの結果を見ると、この推測があたることが分かります。


TPACK@ukja1106> select /*+ leading(t1) use_nl(d) */
  2   *
  3  from t1, t2@loopback d
  4  where t1.c1 = d.c1
  5   and t1.c1 < 0
  6  ;

no rows selected

TPACK@ukja1106> 
TPACK@ukja1106> select sql_id, executions
  2  from v$sqlarea
  3  where sql_text = 'SELECT /*+ USE_NL ("D") */ "C1","C2" FROM "T2" "D" WHERE "C1"<0 AND :1="C1"';

no rows selected

今度は同一なテストを1,000回のデータリクエストをリモートデータベースへ送る分散クエリに対して修行してみます。


TPACK@ukja1106> -- execute it, for 1000 rows
TPACK@ukja1106> explain plan for
  2  select /*+ leading(t1) use_nl(d) */
  3   *
  4  from t1, t2@loopback d
  5  where t1.c1 = d.c1
  6  ;

Explained.

TPACK@ukja1106> 
TPACK@ukja1106> select * from table(dbms_xplan.display);

---------------------------------------------------
| Id  | Operation          | Name | Inst   |IN-OUT|
---------------------------------------------------
|   0 | SELECT STATEMENT   |      |        |      |
|   1 |  NESTED LOOPS      |      |        |      |
|   2 |   TABLE ACCESS FULL| T1   |        |      |
|   3 |   REMOTE           | T2   | LOOPB~ | R->S |
---------------------------------------------------

Remote SQL Information (identified by operation id):
----------------------------------------------------

   3 - SELECT /*+ USE_NL ("D") */ "C1","C2" FROM "T2" "D" WHERE :1="C1" (accessing
       'LOOPBACK' )

1,000回のデータリクエストを送った結果、Remote SQLがリモートデータベースで1,000回修行されました。これはまるでSQL*Plusで該当くえりを1,000回修行したのは同一です。


TPACK@ukja1106> select /*+ leading(t1) use_nl(d) */
  2   *
  3  from t1, t2@loopback d
  4  where t1.c1 = d.c1
  5  ;

        C1         C2         C1         C2
---------- ---------- ---------- ----------
         1          1          1          1
         2          2          2          2
         3          3          3          3
...
       999        999        999        999
      1000       1000       1000       1000

1000 rows selected.

TPACK@ukja1106> 
TPACK@ukja1106> col sql_id new_value sql_id
TPACK@ukja1106> select sql_id, executions
  2  from v$sqlarea
  3  where sql_text = 'SELECT /*+ USE_NL ("D") */ "C1","C2" FROM "T2" "D" WHERE :1="C1"';

SQL_ID        EXECUTIONS
------------- ----------
6skxmvb24s6v4       1000

DBMS_XPLAN.DISPLAY_CURSOR関数を利用したら、リモートデータベースでのRemote SQLの実行計画も分かります。次のようにIndex Range Scanが選択されました。


TPACK@ukja1106> select * from table(dbms_xplan.display_cursor('&sql_id', null));

-------------------------------------------------------------------------------------
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |       |       |       |     2 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID| T2    |     1 |     7 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | T2_N1 |     1 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

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

   2 - access("C1"=:1)

今度はNested Loops JoinではなくてHash Joinに対して同一なテストを修行してみます。Remote SQLは次のようです。


TPACK@ukja1106> explain plan for
  2  select /*+ leading(t1) use_hash(d) */
  3   *
  4  from t1, t2@loopback d
  5  where t1.c1 = d.c1
  6  ;

Explained.

TPACK@ukja1106> 
TPACK@ukja1106> select * from table(dbms_xplan.display);

---------------------------------------------------
| Id  | Operation          | Name | Inst   |IN-OUT|
---------------------------------------------------
|   0 | SELECT STATEMENT   |      |        |      |
|*  1 |  HASH JOIN         |      |        |      |
|   2 |   TABLE ACCESS FULL| T1   |        |      |
|   3 |   REMOTE           | T2   | LOOPB~ | R->S |
---------------------------------------------------


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

   1 - access("T1"."C1"="D"."C1")

Remote SQL Information (identified by operation id):
----------------------------------------------------

   3 - SELECT /*+ USE_HASH ("D") */ "C1","C2" FROM "T2" "D" (accessing 'LOOPBACK' )

たとえ1,000件をフェッチするのは同様ですが、Hash Joinの特性上リモートデータベースへRemote SQLを1,000回送ることではなく、ただ一回の実行でほしいデータを受け付けることができます。したがって実行回数(EXECUTIONS)は”１”となっています。


TPACK@ukja1106> select /*+ leading(t1) use_hash(d) */
  2   *
  3  from t1, t2@loopback d
  4  where t1.c1 = d.c1
  5  ;

        C1         C2         C1         C2
---------- ---------- ---------- ----------
         1          1          1          1
         2          2          2          2
         3          3          3          3
...
       999        999        999        999
      1000       1000       1000       1000

1000 rows selected.

TPACK@ukja1106> col sql_id new_value sql_id
TPACK@ukja1106> select sql_id, executions
  2  from v$sqlarea
  3  where sql_text = 'SELECT /*+ USE_HASH ("D") */ "C1","C2" FROM "T2" "D"';

SQL_ID        EXECUTIONS
------------- ----------
0uksumbhuswyx          1

1 row selected.

そしてRemote SQLはTable Full Scanの実行計画を持ちます。


TPACK@ukja1106> select * from table(dbms_xplan.display_cursor('&sql_id', null));

SQL_ID  0uksumbhuswyx, child number 0
-------------------------------------
SELECT /*+ USE_HASH ("D") */ "C1","C2" FROM "T2" "D"

Plan hash value: 1513984157

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |       |       |     3 (100)|          |
|   1 |  TABLE ACCESS FULL| T2   |  1000 |  7000 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------

上の一連のテスト結果を見ると次のような結論が下せます。

分散くえりの動作方式はローカルクエリの動作方式とほとんど同一。
リモートデータベースからデータを伝送されるためRemote SQLをリモートデータベースの送る。

これから、分散クエリをテストする時、上のような方法の分析が役に立つことをお願いします。

Deferred Segment Creation機能の面白い2つのバグ

2010-08-23T23:40:00.000-07:00

Oracle 11gR2ではDeferred Segment Creationという機能が追加されました。

マニュアルはこちら

簡単に言えば、CREATE TABLE文を実行しても実際にデータが追加されるまでにはセグメントが生成されない機能です。このポストではDeferred Segment CreationとINSERT ... SELECT文に関する面白い2つのバグを紹介します。

バグ9078678: セグメントのないテーブルへの並列INSERT ... SELECT文に対しる予想実行計画（Explain Plan）は並列ではなく直列実行計画に表示されます。しかし、実際には並列で行なわれます。
バグ9329566: セグメントのないテーブルに対してINSERT ...SELECT文を実行すれば、SELECT文を二回実行するバグです。

2つのバグはすべてセグメントかないという特徴から発生するバグです。簡単なテストケースを見ましょう。まずバグ9078678に当たる現象です。

1. オラクルバージョンは11.2.0.1です。


TPACK@ukja1120> -- version
TPACK@ukja1120> select * from v$version where rownum = 1;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

2. テーブルT1を作ります。テーブルT1はセグメントが存在しない状態です。テーブルT1に対して並列INSERT文章を行なう場合実行計画がどうなるか見ましょう。


TPACK@ukja1120> create table t1(c1 number);

Table created.

TPACK@ukja1120> alter session enable parallel dml;

Session altered.

TPACK@ukja1120> explain plan for
  2  insert /*+ parallel(t1 4) */ into t1
  3  select level from dual connect by level <= 10000;

Explained.

TPACK@ukja1120> select * from table(dbms_xplan.display);

------------------------------------------------------------------------------
| Id  | Operation                     | Name | Rows  | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | INSERT STATEMENT              |      |     1 |     2   (0)| 00:00:01 |
|   1 |  LOAD AS SELECT               | T1   |       |            |          |
|*  2 |   CONNECT BY WITHOUT FILTERING|      |       |            |          |
|   3 |    FAST DUAL                  |      |     1 |     2   (0)| 00:00:01 |
------------------------------------------------------------------------------

ヒントを付けて並列実行を指定したが直列実行の実行計画が選択されました。

3. 予想実行計画ではなくて実際にSQL文を実行した後並列で実行するかどうかを見ましょう。


TPACK@ukja1120> insert /*+ parallel(t1 4) */ into t1
  2  select level from dual connect by level <= 10000;

10000 rows created.

TPACK@ukja1120> 
TPACK@ukja1120> commit;

Commit complete.

-- https://sites.google.com/site/ukja/sql-scripts-1/o-s/pqstat
TPACK@ukja1120> @pq_stat

DFO_NUMBER      TQ_ID SERVER_TYP PROCESS      NUM_ROWS 
---------- ---------- ---------- ---------- ---------- 
         1          0 Consumer   P000             2500 
         1          0 Consumer   P001             2500 
         1          0 Consumer   P002             2500 
         1          0 Consumer   P003             2500 
         1          0 Producer   QC              10000 
         1          1 Consumer   QC                  4 
         1          1 Producer   P000                1 
         1          1 Producer   P001                1 
         1          1 Producer   P002                1 
         1          1 Producer   P003                1 


10 rows selected.

STATISTIC                      LAST_QUERY SESSION_TOTAL
------------------------------ ---------- -------------
Queries Parallelized                    0             0
DML Parallelized                        1             1
DDL Parallelized                        0             0
DFO Trees                               1             1
Server Threads                          4             0
Allocation Height                       4             0
Allocation Width                        1             0
Local Msgs Sent                        44            44
Distr Msgs Sent                         0             0
Local Msgs Recv'd                      44            44
Distr Msgs Recv'd                       0             0

11 rows selected.

Explain Planをよる予想実行計画では直列実行という結果がでてきたが、実際の結果からは並列に実行されたのがわかります。もっと面白いのはこの状態で（すなわち、テーブルT1にデータが追加された状態）予想実行計画を見直すと並列実行計画にかえるとくうことです。


TPACK@ukja1120> explain plan for
  2  insert /*+ append parallel(t1 4) */ into t1
  3  select level from dual connect by level <= 10000;

Explained.

------------------------------------------------------
| Id  | Operation                         | Name     |
------------------------------------------------------
|   0 | INSERT STATEMENT                  |          |
|   1 |  PX COORDINATOR                   |          |
|   2 |   PX SEND QC (RANDOM)             | :TQ10001 |
|   3 |    LOAD AS SELECT                 | T1       |
|   4 |     PX RECEIVE                    |          |
|   5 |      PX SEND ROUND-ROBIN          | :TQ10000 |
|*  6 |       CONNECT BY WITHOUT FILTERING|          |
|   7 |        FAST DUAL                  |          |
------------------------------------------------------

これはバグです。セグメントがまだ生成されていないテーブルに対する並列実行文章の予想実行計画はまるで直列に実行されうように見えるが、実際には並列に実行されるバグです。すなわち、セグメントのないテーブルに対する並列実行文章の予想実行計画を正確に見せてくれないバグです。

バグ9329566に該当するテストケースも見ましょう。

1. テーブルT1とテーブルT2を同一に生成します。ただ、テーブルT2には一件の行を追加してセグメントもあらかじめ作っておきます。テーブルT1はセグメントがまだ存在しない状態です。10,000ブロックのサイズのテーブルT3も作っておきます。


TPACK@ukja1120> create table t1(c1 varchar2(2000), c2 varchar2(2000), c3 varchar2(2000), c4 varchar2(1000));

Table created.

TPACK@ukja1120> create table t2(c1 varchar2(2000), c2 varchar2(2000), c3 varchar2(2000), c4 varchar2(1000));

Table created.

TPACK@ukja1120> 
TPACK@ukja1120> -- insert 1 row into table t2 to create the segment
TPACK@ukja1120> insert into t2 values('1','1','1','1');

1 row created.

TPACK@ukja1120> -- table size 10000 block
TPACK@ukja1120> create table t3
  2  as
  3  select rpad('x',2000) as c1, rpad('x',2000) as c2, rpad('x',2000) as c3, rpad('x',1000) as c4
  4  from dual
  5  connect by level <= 10000;

Table created.

2. テーブルT3から最高値を読み込んでテーブルT1（セグメントない）、テーブルT2（セグメントある）へINSERTするクエリのそれぞれのConsistent Getsを比べてみましょう。手軽なテストのためにティパックのSession Snapshot Reportを利用します。


TPACK@ukja1120> exec tpack.begin_session_snapshot;

PL/SQL procedure successfully completed.

TPACK@ukja1120> insert into t1
  2  select max(c1), max(c2), max(c3), max(c4) from t3;

1 row created.

TPACK@ukja1120> exec tpack.add_session_snapshot;

PL/SQL procedure successfully completed.

TPACK@ukja1120> insert into t2
  2  select max(c1), max(c2), max(c3), max(c4) from t3;

1 row created.

TPACK@ukja1120> 
TPACK@ukja1120> exec tpack.add_session_snapshot;

PL/SQL procedure successfully completed.

次の結果を見たら、テーブルT1（セグメントない）に対するINSERTがテーブルT2（セグメントある）に対するINSERTに比べて2倍程度のConsistentを見せます。


TPACK@ukja1120> col item format a40
TPACK@ukja1120> col deltas format a20
TPACK@ukja1120> select item, deltas from table(tpack.session_snapshot_report)
  2  where type = 'STAT';

TPACK@ukja1120> select item, deltas from table(tpack.session_snapshot_report)
  2  where type = 'STAT';

ITEM                                     DELTAS
---------------------------------------- --------------------
...
physical read bytes                      164339712->82305024
consistent gets                          20451->10327
...

これもやはりバグです。

テーブルT3からデータを読んでからそのデータをテーブルT1へINSERTしようとします。
どころが、テーブルT1はまだセグメントがありません。したがってまずセグメントを作ります。
ここでオラクルは1番段階で獲得したデータを再活用できずまたテーブルT3からデータを読み込みます。現在のクエリはテーブルT3から最高値(MAX)を取り出しているから、クエリを実行するたびにテーブルのサイズである10,000ブロックを全部読み込まなければなりません。このために、テーブルT1に対するINSERTの際には20,000ブロック（二回読み込むから）、テーブルT2に対するINSERTは10,000ブロック（1回読み込むから）を読み込むようになるのです。

このバグたちはセグメントのないテーブルに対してのみ発生するから致命的なバグとは言いかねます。むしろ開発者がいくら基本的な罠に陥るのかをわかる良い例だといえます。オラクルで発生する多い性能問題がこのようなロジック穴から発生します。性能問題が起こった時このようなロジック穴を見破るテスト能力備えることが重要だといえます。

Batching NLJ最適化と整列

2010-08-16T19:12:00.000-07:00

Batching NLJ最適化って聞いたこたあります？Batching NLJとはOracle 11gで紹介されたNested Loops Joinの最適化技法であります。例えば、次の２つの実行計画を見てください。


-- Oracle 10g
------------------------------------------------
| Id  | Operation                      | Name  |
------------------------------------------------
|   0 | SELECT STATEMENT               |       |
|*  1 |  COUNT STOPKEY                 |       |
|   2 |   TABLE ACCESS BY INDEX ROWID  | T2    |  <-- Here
|   3 |    NESTED LOOPS                |       |
|   4 |     TABLE ACCESS BY INDEX ROWID| T1    |
|*  5 |      INDEX RANGE SCAN          | T1_N1 |
|*  6 |     INDEX RANGE SCAN           | T2_N1 |
------------------------------------------------

-- Oracle 11g
------------------------------------------------
| Id  | Operation                      | Name  |
------------------------------------------------
|   0 | SELECT STATEMENT               |       |
|*  1 |  COUNT STOPKEY                 |       |
|   2 |   NESTED LOOPS                 |       |
|   3 |    NESTED LOOPS                |       |
|   4 |     TABLE ACCESS BY INDEX ROWID| T1    |
|*  5 |      INDEX RANGE SCAN          | T1_N1 |
|*  6 |     INDEX RANGE SCAN           | T2_N1 |
|   7 |    TABLE ACCESS BY INDEX ROWID | T2    |   <-- And here
------------------------------------------------

TABLE ACCESS BY INDEX ROWID (T2)のオペレーションの位置の違いに気付いたんでしょうか。これがOracle 11gのNested Loops Join最適化(Batching NLJ)の現れ方です。Batching NLJによって、論理読み込みが減り、性能が効率的になるはずです。

さて、ほんの数日前、Batching NLJ関連の変な整列問題に出会いました。下記は再現のできるテストケースです。ORDER BYのオーバーヘッドなく整列をするために、索引T1_N1を利用していることに注意してください。


create table t1
as
select 1 as c1, mod(level, 4) as c2, level as c3, level as c4, rpad('x',1000) as dummy
from dual
connect by level <= 1000;

create table t2
as
select 1001-level as c1, level as c2, rpad('x',1000) as dummy
from dual
connect by level <= 100;

create index t1_n1 on t1(c1, c2, c3);
create index t2_n1 on t2(c1);

exec dbms_stats.gather_table_stats(user, 't1');
exec dbms_stats.gather_table_stats(user, 't2');

explain plan for
select /*+ leading(t1 t2) use_nl(t2) index_asc(t1) index_asc(t2) */
 rownum as rnum,
 t2.c1,
 t1.c4,
 t2.c2
from t1, t2
where
 t1.c3 = t2.c1
 and t1.c1 = 1
 and t1.c2 = 0
 and rownum <= 20
;

select * from table(dbms_xplan.display);

-- Read from the disk
alter system flush buffer_cache;

select * from (
 select /*+ leading(t1 t2) use_nl(t2) index_asc(t1) index_asc(t2) */
  rownum as rnum,
  t2.c1,
  t1.c4,
  t2.c2
 from t1, t2
 where
  t1.c3 = t2.c1
  and t1.c1 = 1
  and t1.c2 = 0
  and rownum <= 20
) where rnum >= 15
;

-- Read from the buffer cache
select * from (
 select /*+ leading(t1 t2) use_nl(t2) index_asc(t1) index_asc(t2) */
  rownum as rnum,
  t2.c1,
  t1.c4,
  t2.c2
 from t1, t2
 where
  t1.c3 = t2.c1
  and t1.c1 = 1
  and t1.c2 = 0
  and rownum <= 20
) where rnum >= 15
;

-- Disable exceptions for buffer cache misses
alter session set "_nlj_batching_misses_enabled" = 0;

-- Read from the disk
alter system flush buffer_cache;

select * from (
 select /*+ leading(t1 t2) use_nl(t2) index_asc(t1) index_asc(t2) */
  rownum as rnum,
  t2.c1,
  t1.c4,
  t2.c2
 from t1, t2
 where
  t1.c3 = t2.c1
  and t1.c1 = 1
  and t1.c2 = 0
  and rownum <= 20
) where rnum >= 15
;

-- Read from the buffer cache
select * from (
 select /*+ leading(t1 t2) use_nl(t2) index_asc(t1) index_asc(t2) */
  rownum as rnum,
  t2.c1,
  t1.c4,
  t2.c2
 from t1, t2
 where
  t1.c3 = t2.c1
  and t1.c1 = 1
  and t1.c2 = 0
  and rownum <= 20
) where rnum >= 15
;

時間の節約のために、コメントが付いた簡単な結果を見ましょう。


-- Case1 : batching NLJ enabled
-- when the query reads from the disk
      RNUM         C1         C4         C2
---------- ---------- ---------- ----------
        15        960        960         41
        16        964        964         37
        17        980        980         21  <-- Why 980 here?
        18        968        968         33
        19        972        972         29
        20        976        976         25

-- when the query reads from the buffer cache
      RNUM         C1         C4         C2
---------- ---------- ---------- ----------
        15        960        960         41
        16        964        964         37
        17        968        968         33
        18        972        972         29
        19        976        976         25
        20        980        980         21

-- Case 2: batching NLJ disabled
-- when the query reads from the disk
      RNUM         C1         C4         C2
---------- ---------- ---------- ----------
        15        960        960         41
        16        964        964         37
        17        968        968         33
        18        972        972         29
        19        976        976         25
        20        980        980         21

-- when the query reads from the buffer cache
      RNUM         C1         C4         C2
---------- ---------- ---------- ----------
        15        960        960         41
        16        964        964         37
        17        968        968         33
        18        972        972         29
        19        976        976         25
        20        980        980         21

いかがでしょう。整列の順序に変わったこと

これは次のように解説できます。
「新しいNested Loops Joinの最適化コードは行が整列されたまま返されることを保障しない。特にディスクからデータを読み出している際には」

これはページネーションクエリ(Pagination Query)を索引とNested Loops Joinを利用して作成したい時に制約になる可能性があると思います。では、この制約がバグというのではありません。オラクルで整列順序を保障する雄一な方法はORDER BY句を与えることだけからです。

この制約を抜けていくためには次の方法で1つくらいを進めます。

隠しパラメーター_nlj_batching_misses_enabledを0にセット
隠しパラメーター_nlj_batching_enabledを0にセット
NO_NLJ_BATCHING(T2)ヒントの追加

「ティパック」知能的な待機イベントの分析 - Part 1

2010-08-10T21:36:00.000-07:00

オラクルが提供する待機イベントとは本?に?特です。どんなDBMSでも待機現象をこんなに詳細に報告してくれる製品はありません。

これはオラクルの性能問題を分析かつ解決すべき私たちには大きいプレゼントである同時?みであります。まるで初?の運?者にポルシェを?えるのと同じだと言えないでしょうか。ポルシェのような車を走らせようとしたらまず丈夫な運?わざが必要です。

待機イベント分析も同?です。正確な分析のためにはオラクルのア?キテクチャ?に?する相?な知識が必要です。これが待機イベント分析の技法がより?範?に使用されうことに邪魔となっています。

待機イベント分析で1つ?をつけなければならないのが大?イベントだけでは意味のある情報を引き出し難しいということです。?連のあるほかの情報が必要である場合がたくさんあります。ティパックではこれを知能的な待機イベントの分析と呼びます。例えをあげてみればこのような追加的な情報が必要です。

cache buffers chainsラッチで競合が?生する場合、おもにどんなブロックで?生しているかわかる？
　row cache objectsラッチで競合が?生する場合、おもにどんなディクショナリ?オブジェクトなのかわかる？
db file sequential readのようなI/O待機いの場合、どんなセグメントのどのような種類のブロックで?生するかわかる？
ラッチ、ロック（Enqueue）、library cache lock、library cache pin、row cache lock、Mutexなどの同期化客?で競合が?生する場合、ホルダ?情報および?連の客?の情報が得られる？

これから?回にわたって待機イベントをもっと知能的に分析するためにどんなデ?タを追加的に分析する必要があらのかいくつかの例を見るつもりです。

1. ホルダ?を突き止め！　

オラクルでの競合は次の六つ程度の同期化客?により?生します。

ラッチ
ロック
Library cache lock
Library cache pin
Row cache lock
Mutex

個?の客?が何を意味しているのかすでにわかっている方?も多いはずなので、詳細な?明は足らないと思います。

同期化客?の種類別に提供されるビュ?が違いですから、ホルダ?を突き止めるときも違うビュ?を?索しなければなりません。幸いに最近バ?ジョンのオラクルではV$SESSIONビィ?のBLOCKING_SESSION、BLOCKING_INSTANCE
などの列から大部分の?況でホルダ?情報が提供されます。大?有?な情報だと言えます。しかし、待機イベントによっては?純にホルダ?を知るだけでは不足である場合もあります。正確にどんなオブジェクトで、どんなモ?ドで?生しているのかなどの情報が必要である場合もあります。

これから公開する情報はたぶん（！）ホルダ?を突き止める方法を今までのどんな文書より一番?範?で完璧にまとめていることであるはずです。

1.1 ラッチのホルダ?

ラッチホルダ?はV$LATCHHOLDERビュ?から突き止められます。


-- ラッチホルダ?
select h.pid, h.sid, h.laddr, h.name, h.gets
from v$latchholder h, v$session_wait s
where s.sid = &sid
   and s.p1raw = h.laddr;

ラッチはとても短い時間に獲得されうため、上のような?純なクエリだけでは欲しい結果を得ることができない場合がたくさんあります。（もちろんオラクルのバグなどによって特定のラッチを長い間持っている場合もあります）

この時に使用できるのがプロファイル方法です。ティパックは1)スナップショット、2)プロファイル2つの方法を使用しています。この中で、プロファイルとは短い時間に記?され、消えてしまう値を可能な限りよく取り出して、要約する方法を意味します。V$LATCHHOLDERビュ?も次のようにプロファイリングできます。


-- ラッチホルダ?プロファイリング
TPACK@ukja1021> select /*+ ordered use_nl(x) */
  2     x.sid, x.name, count(*)
  3  from
  4     (select /*+ no_merge */ level from dual connect by level <= 10000) t1,
  5     (select  /*+ no_merge */ h.pid, h.sid, h.laddr, h.name, h.gets
  6             from v$latchholder h, v$session_wait s
  7             where s.sid = &sid
  8                             and s.p1raw = h.laddr) x
  9  group by x.sid, x.name
 10  ;
old   7:                where s.sid = &sid
new   7:                where s.sid =        138

       SID NAME                             COUNT(*)
---------- ------------------------------ ----------
       134 shared pool                            33
       134 library cache                         308

1.3 ロックのホルダ?

ロックホルダ?はV$LOCKビュ?で十分です。


-- ロックホルダ?
select
 h.sid,  -- ホルダ?SID
 h.type,   -- ロックタイプ
 h.id1,  -- ID1
 h.id2,  -- ID2
 h.lmode, 
 t.name,
 t.id1_tag,
 t.id2_tag,
 t.description
from v$lock h, v$lock w, v$lock_type t
where w.sid = { waiter_sid }
 and h.id1 = w.id1
 and h.id2 = w.id2
 and h.lmode > 0 
 and h.block > 0
 and h.type = t.type
;

1.3 Library cache lockのホルダ?

Library cache lockとはLCO(Library Cache Object)を保護するシステムロックです。競合が?生すればlibrary cache lock待機イベントを持ちます。Library cache lockのホルダ?はX$KGLLKビュ?を通じて突き止められます。


-- Library cache lock ホルダ?　　　　　　　　　　
select
 (select sid from v$session where saddr = k.kgllkuse) as sid,  -- ホルダ?SID
 k.kglhdnsp,  -- 客?の種類
 k.kglnaobj,  -- 客?名（SQL文章や表、プロシ?ジャ名など）
 decode(k.kgllkmod, 3, '3(X)', 2, '2(S)', 1, '1(N)', k.kgllkmod) as lkmode
from x$kgllk k
where k.kgllkhdl = { v$session_wait.p1raw }
   and k.kgllkmod > 0
;

1.4 Library cache pinのホルダ?

Library cache pinとはカ?ソルやプロシ?ジャの?行を保護するシステムロックです。競合が?生すればlibrary cache pin待機イベントを待ちます。Library cache pinホルダ?はX$LGLPNビュ?を通じて突き止められます。


-- Library cache pin　ホルダ?
select
  (select sid from v$session where saddr = n.kglpnuse) as sid, 
  o.kglnaobj,
  o.kglhdnsp,
  decode(n.kglpnmod, 3, '3(X)', 2, '2(S)', 1, '1(N)', n.kglpnmod) as lkmode
from x$kglpn n, x$kglob o
where n.kglpnhdl = { v$session_wait.p1raw }
   and n.kglpnmod > 0
   and o.kglhdadr = n.kglpnhdl
;

1.5 Row cache lockのホルダ?

Row cache lockとはディクショナリ?オブジェクトを保護するロックです。競合が?生すればrow cache lock待機イベントを待ちます。Row cache lockのホルダ?はV$ROWCACHE_PARENTビュ?から突き止められます。


-- Row cache lock ホルダ?
select 
 (select sid from v$session where saddr = h.saddr) as sid,  -- ホルダ?SID
 h.cache_name,  -- ディクショナリ?オブジェクトの種類
 h.lock_mode,    
 h.inst_lock_type 
from v$rowcache_parent h, v$rowcache_parent w, v$session s
where h.address = w.address
   and w.saddr = s.saddr 
   and s.sid = { waiter_sid }
   and h.lock_mode > 0
;

1.6 Mutexのホルダ?

Mutexのホルダ?はV$MUTEX_SLEEP_HISTORYビュ?を通じて突き止められます。


-- Mutexのホルダ?
select * from (
 select
   blocking_session as sid,  -- ホルダ?SID
  (select kglnaobj from x$kglob 
  where kglnahsh = mutex_identifier 
  and rownum = 1) as obj_name,   -- オブジェクト命(11gで追加)
   mutex_type,  -- Mutexのタイプ
   location,  -- Mutexを獲得した位置、すなわち何のためにMutexを獲得しようとしているのか？
   sleeps,
   gets,
   to_char(sleep_timestamp,'yyyy/mm/dd hh24:mi:ss') as sleep_timestamp
 from v$mutex_sleep_history
 where requesting_session = session_id
 order by sleep_timestamp desc
) where rownum <= 1 ;

11gからはMUTEX_IDENTIFIERという有?なコラムが追加されMutex競合の分析がもっと易くなりました。

上の情報からわかるようにホルダ?の?索も大事ものの、もっと具?的にどんな情報で、どんあ客?で問題が?生しているのかを把握することも重要です。このような理由から、文書化されていないV$ビュ?やX$ビュ?を?索するしかありません。

ティパックではSession Detail Reportを通じて上の情報を取り出すことができます。ほぼ同じクエリを使用します。

Library cache pin競合の例で?明してみます。


-- とても長いSQL文章を作ります。正確にいえばハ?ドパ?スの時間が長いSQL文章です。
-- http://sites.google.com/site/ukja/sql-scripts-1/j-m/make_long
TPACK@ukja1021> @make_long
select count(*) from TPACK_REPORT_PARAMS, TPACK_REPORT_CONDITIONS,
TPACK_REPORT_JOB_HIST, TPACK_REPORT_SESSION_TEMP, TPACK_FUNCTION_NAMES,
...

-- セッション＃１で上のクエリを行います。（私のテスト環境で２分５０秒くらいかかります）
TPACK@ukja1021> exec dbms_application_info.set_client_info('session1');

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.39
TPACK@ukja1021> @long_parse
....

-- セッション＃１と同時にセッション＃２で同じクエリを行います。
TPACK@ukja1021> exec dbms_application_info.set_client_info('session2');

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.04
TPACK@ukja1021> @long_parse
...

セッション＃２はセッション＃１がハ?ドパ?スを行なう間、待機?態になります。セッション＃２に?してSession Detail Reportを?集して待機イベントを詳細に分析します。


-- セッション＃２のSID
TPACK@ukja1021> col sid new_value sid
TPACK@ukja1021> select sid from v$session where client_info = 'session2';

       SID
----------
       138

1 row selected.

Elapsed: 00:00:00.14

-- セッション＃２のSession Detail Report
TPACK@ukja1021> col name format a30
TPACK@ukja1021> col value format a45
TPACK@ukja1021> set pages 200
TPACK@ukja1021> set long 10000000
TPACK@ukja1021> select * from table(tpack.session_detail(&sid, 'wait_detail'));
old   1: select * from table(tpack.session_detail(&sid, 'wait_detail'))
new   1: select * from table(tpack.session_detail(       138, 'wait_detail'))

NAME                           VALUE
------------------------------ ---------------------------------------------
SID                            138
Serial#                        711
SPID                           3724
Program                        sqlplus.exe
Process                        5364:5208
Module                         SQL*Plus
SQL ID
Child No
SQL Text
Status                         ACTIVE
Blocking Instance              1
Blocking Session               134
Event                          library cache pin
Seq#                           4137
P1(P1raw)                      970230240(39D489E0)
P2(P2raw)                      970230240(36A9AB34)
P3(P3raw)                      970230240(000000C8)
Seconds in wait                10
State                          WAITING
Wait Event                     library cache pin
Holder SID                     134
Namespace                      CURSOR
Object                         select count(*) from TPACK_SGA_STAT, TPACK_SG
                               A_STAT, TPACK_SGA_STAT, TPACK_SGA_STAT, TPACK
                               _SGA_STAT, TPACK_SGA_STAT, TPACK_SGA_STAT, TP
                               ACK_SGA_STAT, TPACK_SGA_STAT, TPACK_SGA_STAT,
                                TPACK_SGA_STAT, TPACK_SGA_STAT, TPACK_SGA_ST
                               AT, TPACK_SGA_STAT, TPACK_SGA_STAT, TPACK_SGA
                               _STAT, TPACK_SGA_STAT, TPACK_SGA_STAT, TPACK_
                               SGA_STAT, TPACK_SGA_STAT, TPACK_SGA_STAT, TPACK_S

                               GA_STAT, TPACK_SGA_STAT, TPACK_SGA_STAT, TPAC
                               K_SGA_STAT, TPACK_SGA_STAT, TPACK_SGA_STAT, T
                               PACK_HEAP_DUMP, TPACK_HEAP_DUMP, TPACK_HEAP_D
                               UMP, TPACK_HEAP_DUMP, TPACK_HEAP_DUMP, TPACK_
                               HEAP_DUMP, TPACK_HEAP_DUMP, TPACK_HEAP_DUMP,
                               TPACK_HEAP_DUMP, TPACK_HEAP_DUMP, TPACK_HEAP_
                               DUMP, TPACK_HEAP_DUMP, TPACK_HEAP_DUMP, TPACK
                               _HEAP_DUMP, TPACK_HEAP_DUMP, TPACK_HEAP_DUMP, TPA

                               CK_HEAP_DUMP, TPACK_HEAP_DUMP, TPACK_HEAP_DUM
                               P, TPACK_HEAP_DUMP, TPACK_HEAP_DUMP, TPACK_HE
                               AP_DUMP, TPACK_HEAP_DUMP, TPACK_HEAP_DUMP, TP
                               ACK_HEAP_DUMP, TPACK_HEAP_DUMP, TPACK_HEAP_DU
                               MP, TPACK_HEAP_DUMP_SUM, TPACK_HEAP_DUMP_SUM,
                                TPACK_HEAP_DUMP_SUM, TPACK_HEAP_DUMP_SUM, TP
                               AC

Holding Mode                   3(X)

NamespaceとObject情報からlibrary cache pin待機に?するより正確な分析が可能です。Oracle 11gではlibrary cache pinではなくてMutexに?する競合が?生します。


TPACK@ukja1106> select * from table(tpack.session_detail(&sid, 'wait_detail'));
old   1: select * from table(tpack.session_detail(&sid, 'wait_detail'))
new   1: select * from table(tpack.session_detail(       127, 'wait_detail'))

NAME                           VALUE
------------------------------ ---------------------------------------------
SID                            127
Serial#                        1642
SPID                           2656
Program                        sqlplus.exe
Process                        5364:5208
Module                         SQL*Plus
SQL ID
Child No
SQL Text
Status                         ACTIVE
Blocking Instance              1
Blocking Session               139
SQL Exec Start
Event                          cursor: pin S wait on X
Seq#                           631
P1(P1raw)                      3859422310(00000000E60A1C66)
P2(P2raw)                      3859422310(00000000008B0000)
P3(P3raw)                      3859422310(0000000000050256)
Seconds in wait                0
State                          WAITING
Wait Event                     cursor: pin S wait on X
Holder SID                     139
Mutex Type                     Cursor Pin
Location
Target Object                  select count(*) from TPACK_SGA_STAT, TPACK_SG
                               A_STAT, TPACK_SGA_STAT, TPACK_SGA_STAT, TPACK
                               _SGA_STAT, TPACK_SGA_STAT, TPACK_SGA_STAT, TP
                               ACK_SGA_STAT, TPACK_SGA_STAT, TPACK_SGA_STAT,
                                TPACK_SGA_STAT, TPACK_SGA_STAT, TPACK_SGA_ST
                               AT, TPACK_SGA_STAT, TPACK_SGA_STAT, TPACK_SGA
                               _STAT, TPACK_SGA_STAT, TPACK_SGA_STAT, TPACK_
                               SGA_STAT, TPACK_SGA_STAT, TPACK_SGA_STAT, TPACK_S

                               GA_STAT, TPACK_SGA_STAT, TPACK_SGA_STAT, TPAC
                               K_SGA_STAT, TPACK_SGA_STAT, TPACK_SGA_STAT, T
                               PACK_HEAP_DUMP, TPACK_HEAP_DUMP, TPACK_HEAP_D
                               UMP, TPACK_HEAP_DUMP, TPACK_HEAP_DUMP, TPACK_
                               HEAP_DUMP, TPACK_HEAP_DUMP, TPACK_HEAP_DUMP,
                               TPACK_HEAP_DUMP, TPACK_HEAP_DUMP, TPACK_HEAP_
                               DUMP, TPACK_HEAP_DUMP, TPACK_HEAP_DUMP, TPACK
                               _HEAP_DUMP, TPACK_HEAP_DUMP, TPACK_HEAP_DUMP, TPA

                               CK_HEAP_DUMP, TPACK_HEAP_DUMP, TPACK_HEAP_DUM
                               P, TPACK_HEAP_DUMP, TPACK_HEAP_DUMP, TPACK_HE
                               AP_DUMP, TPACK_HEAP_DUMP, TPACK_HEAP_DUMP, TP
                               ACK_HEAP_DUMP, TPACK_HEAP_DUMP, TPACK_HEAP_DU
                               MP, TPACK_HEAP_DUMP_SUM, TPACK_HEAP_DUMP_SUM,
                                TPACK_HEAP_DUMP_SUM, TPACK_HEAP_DUMP_SUM, TP
                               AC

Last Sleep Time                2010/06/29 16:03:51
Gets                           1
Sleeps                         611

重要なのは待機現象が?生するとき適切なビュ?から適切なデ?タを?索することができるかということです。ティパックはその中核心的なデ?タを自動に?集してくれるだけです。

以前のポスト

「ティパック」oradebug

2010-08-05T23:03:00.003-07:00

このポストの目的はoradebugの使用法全?を?明することではなくてティパックで使われているoradebugコマンドを簡?に紹介することです。

1. 特定のプロセスにバインディング

ティパックがoradebugコマンドを使用する理由は特定のプロセスに自由にバインディングできるからです。


-- SYSDBA ユ?ザ?でログイン

sqlplus "/as sysdba"



-- 現在のプロセスにバインディング

SQL> oradebug setmypid



-- 特定のセッションのOS Process IDでバインディング

SQL> select sid, serial#,

   (select spid from v$process where addr = paddr) as ospid

from v$session 

where sid = (select sid from v$mystat where rownum = 1);



       SID    SERIAL# OSPID

---------- ---------- ------------

       144       2446 4872



SQL> oradebug setospid 4872

Oracle pid: 16, Windows thread id: 4872, image: ORACLE.EXE (SHAD)

特定のプロセスにバインディングするには次の４つの方法があります。


SQL> oradebug help

SETMYPID                                 Debug current process

SETOSPID       {ospid}                   Set OS pid of process to debug

SETORAPID      {orapid} ['force']        Set Oracle pid of process to debug

SETORAPNAME    {orapname}                Set Oracle process name to debug  -- 11g에서 추가

...

SETOSPIDコマンドを主に使用する理由はUnix/Linux環境ではProcess ID(PID)を得るのが易いからです。でも、ティパックでは特定のセッションを指定するためにSession ID(SID)をパラメ?タ?で使用します。オラクルではSIDが一番認識しやすい値からです。

2. トレ?スファイルの名前の獲得

ティパックでは特定のプロセスに?してイベントやダンプを行い、その中身を?み?む作業がいくつかあります。したがって、トレ?スファイルの名前を正確にえるのが大事です。oradebug tracefile_name名前がそれに?たります。


SQL> oradebug tracefile_name

c:\oracle\admin\ukja1021\udump\ukja1021_ora_4872.trc

上の作業をティパックでは次のように行なえます。


-- 143番セッションのトレ?スファイルの名前

SQL> select tpack.get_tracefile_name(143) from dual;

c:\oracle\admin\ukja1021\udump\ukja1021_ora_4872.trc



-- レ?スファイルの中身

SQL> select * from table(tpack.get_tracefile_contents('c:\oracle\admin\ukja1021\udump\ukja1021_ora_4872.trc'))

あるいは次のようなクエリを通じても得られます。しかし、ファイル名の正確なフォ?マットはバ?ジョンやＯＳにより?わられます。もう１つの短所は該?プロセスがサ?バ?プロセスなのか、バックグラウンドプロセスなのかを事前に知ることが必要で、プロセスの種類によりどんなディレクトリ?にファイルが書き?まれるのかも判?したければならないということです。このような複?性のためにティパックではoradebug tracefile_nameコマンドを利用します。


select

  d.value||'\'||p.value||'_ora_'||s.spid||'.trc'   as trace_file_name

from 

  (

  select value 

  from v$parameter

  where name = 'instance_name'

  ) p, 

  (

  select value

  from v$parameter

  where name = 'user_dump_dest'

  ) d,

  (

  select spid

  from v$process

  where addr = (

    select paddr 

    from v$session

    where sid = {sid here}

    )

  ) s

3. 診?イベントの修行

特定のプロセスにバインディングした後は該?プロセスに?して診?イベントが行なわれます。


-- 診?イベントの活性化

SQL> oradebug event 10046 trace name context forever, level 12



-- 診?イベントの非活性化

SQL> oradebug event 10046 context off



-- トレ?スファイルの確認

SQL> oradebug tracefile_name

SQL> ed {tracefile_name}

上の作業をティパックでは次のように行われます。


-- 診?イベントの活性化

SQL> exec tpack.begin_diag_trace(143, 10046, 12);



-- 診?イベントの非活性化

SQL> exec tpack.end_diag_trace(143, 10046);



-- トレ?スファイルの確認

SQL> select * from table(tpack.get_diag_trace(143));

ティパックを利用すればoradebugを利用するためにテルネットで接?する必要かないし、クライアントでSQL*Plusですべての作業ができます。ティパックのもう１つの長所は診?イベントを活性した後に生成された中身だけを?み?むということです。すなわち、診?イベントを活性する前に、もうほかの作業により書き?まれた多くのデ?タわスキップされ、今度の作業により書き?まれた中身だけを?み?みます。

4. ダンプの修行

特定のプロセスにバインディングした後、該?プロセスに?して多?なダンプファイルを生成できます。次に簡?な例があります。


-- レベル１でCallstackダンプの修行

SQL> oradebug dump callstack 1



-- PGA Heap Dump。Level 0x20000001とは最上位ヒ?プだけではなくてサイズが大きい五つのサブヒ?プに?して再?的にダンプを修行しろという意味です。非常に有?な機能だと言えます。

SQL> oradebug dump heapdump 0x20000001

ティパックではヒ?プダンプファイルから?み?んだデ?タを加工して分析レポ?トを提供します。


-- 143番セッションに?してCallstackダンプを1秒?たり10回行い、その結果を要約してレポ?ト

SQL> select * from table(tpack.callstack_prof_report(143));



-- 143番セッションに?してPGA Heap Dumpをレベル0x20000001で行い、この結果をレポ?ト

SQL> select * from table(tpack.pga_heap_report(143, 2));

ティパックは性能トラブルシュ?ティングに必要な基本的なデ?タの一部を診?イベントやダンプを通じて得ています。PGA Heap DumpやCallstack Dumpが代表的な例です。このようなデ?タを得るための一番易い（もしかしたら唯一
な）方法としてoradebugを使用しています。

1つの技術的な難しさはSQLコマンドからどうすればoradebugを自由に呼び出すのかということです。ティパックではJava Stored Procedureを利用しています。これに?する詳細なお話は次のポストで進める予定です。

性能トラブルシュ?ティングの段階が深まるほどoradebugの魅力におぼれるはずです。特にOracle 11gでは完全に新しく設計されたOracle Debugging Frameworkが提供され、それに連れてoradebugの機能ももっと?くなりました。詳細な?容は次の文書を?考してください。

Oradebug DOC

以前のポスト

「ティパック」性能問題をトラブルシュ?ティングする２つのフレ?ム

「ティパック」性能問題をトラブルシューティングする２つのフレーム

2010-07-26T23:42:00.000-07:00

クイズであります。

1. オラクルで特定のセッション（あるいはシステム）の現在の状態をすぐにわかる一番良い方法はなんでしょうか。

2. オラクルで特定のセッション（あるいはシステム）が何をしているのかを追跡できる一番良い方法は何でしょうか。

性能問題を分析する2つのフレームで上の質問に対する私の答えを代わります。私はオラクル性能問題をトラブルシューティングする全てのツールと技法を次の２つのフレームに分けます。

スナップショット（Snapshot） - 特定の時点の作業の現在の状態を検索する方法
プロファイル（Profile） - 特定の作業を時間の流れで追跡する方法

例をあげていましょうか。

10053診断イベント - オプティマイザの作業を時間の順序で追跡するプロファイル機能
V$SESSION_WAIT - セッションの待機状態を検索するスナップショット機能
Heap Dump - 特定のセッションやシステムの現在のメモリー使用程度を検索するスナップショット機能
System State Dump - システムの現在の状態を検索するスナップショット機能
Call Stack(oradebug dump callstack) - 特定のセッションの現在呼び出されているファンクションのコールツリーなのでスナップショットとプロファイルの中間性格
Active Session History - アクティブセッションのリストを秒あたり一度づつサンプリングしたことなのでスナップショットとプロファイルの中間性格

スナップショットデータを時間の流れによって全体あるいは一部をサンプリングしたらそれがプロファイルになります。スナップショットは特定の時点の状態をいみするので一番基本的なデータだと言えます。

スナップショットは特定の時点の状態を示しているから、ほとんど大部分差異（Delta）と比較（Diff）を通じてだけ意味を持ちます。AWRレポートをみればスナップショット間の値を差異（Delta）を計算してくれます。差異と比較を通じて直感的にシステムの現在の状態がわかります。

プロファイルは時間の流れによってデータを追跡する方式だから、ほとんど大部分集計と要約を通じてだけ意味を持ちます。10046イベントにより生成されたプロファイルデータをTKPROFレポートというツールを利用して集計して見るのが代表的な例です。

ティパックは上のような簡単明瞭なフレームの上で状況によって適当なスナップショットとプロファイルだけ存在すれば比較と要約を通じて大部分の性能問題をトラブルシューティングできるという考えに基づいています。これからブログを通じてより具体的な事例たちとともにオラクルで使用できる多様な技法たちを論議するようにします。

「ティパック」を紹介します。

2010-07-26T22:35:00.000-07:00

ティパックとはオラクル性能トラブルシューティング機能を提供するPL/SQLライブラリーであります。

ティパックウェブページ

これからブログを通じてティパック機能の使用方法を説明するつもりです。

性能改善の絶対的な原則！

2010-07-14T23:41:00.000-07:00

オラクル性能問題の関する最高の専門家で平価されているCarry Milsapさんは性能を改善する絶対的な原則を言及したことがあります。

ある作業の性能を改善する最高の方法はその作業自体をしないということだ。

本当に名言の中の名言です。

次に簡単な例があります。

1. これ以上チューニング不可能に見える完璧に最適化された文章です。ほぼ3.4秒がかかりました。


TPACK@ukja1106> declare
  2   v_value number;
  3  begin
  4   for idx in 1 .. 100000 loop
  5    select trunc(idx) into v_value from dual;
  6   end loop;
  7  end;
  8  /

PL/SQL procedure successfully completed.

Elapsed: 00:00:03.42

本当にそうでしょうか。上で話した絶対原則を適用したら？不必要なSELECT ... FROM DUAL分をなくしたら？


TPACK@ukja1106> declare
  2   v_value number;
  3  begin
  4   for idx in 1 .. 100000 loop
  5    v_value := trunc(idx);
  6   end loop;
  7  end;
  8  /

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.07

0.07秒だけで作業が終わります。

2. DECODE関数はSQL文章内のみで修行可能です。従ってCASE...文に変換すれば同じ効果を享受できます。



TPACK@ukja1106> -- decode
TPACK@ukja1106> declare
  2   v_value varchar2(1);
  3  begin
  4   for idx in 1 .. 100000 loop
  5    select decode(mod(idx,2),0,'A','B') into v_value from dual;
  6   end loop;
  7  end;
  8  /

PL/SQL procedure successfully completed.

Elapsed: 00:00:03.59

TPACK@ukja1106> -- case
TPACK@ukja1106> declare
  2   v_value varchar2(1);
  3  begin
  4   for idx in 1 .. 100000 loop
  5    v_value := case mod(idx,2) when 0 then 'A' else 'B' end;
  6   end loop;
  7  end;
  8  /

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.15

3. Oracle 11gからはSequenceの値もSELECT ... FROM DUALを通じなくて直接えることがでいます。でも性能に与える影響はほとんどありませんね。


TPACK@ukja1106> -- SELECT... FROM DUAL
TPACK@ukja1106> declare
  2   v_value number;
  3  begin
  4   for idx in 1 .. 100000 loop
  5    select s1.nextval into v_value from dual;
  6   end loop;
  7  end;
  8  /

PL/SQL procedure successfully completed.

Elapsed: 00:00:03.73

TPACK@ukja1106> -- 直接
TPACK@ukja1106> declare
  2   v_value number;
  3  begin
  4   for idx in 1 .. 100000 loop
  5    v_value := s1.nextval;
  6   end loop;
  7  end;
  8  /

PL/SQL procedure successfully completed.

Elapsed: 00:00:03.64

うん。。。なぜでしょうか。それに対する応えはSQL*Traceを通じて得られます。SQL*Traceを実行してみたら{ v_value := s1.nextval }作業は{ Select S1.NEXTVAL from dual }

もう一度言いますが、性能改善の一番の原則は！

ある作業の性能を改善する最高の方法はその作業自体をしないということだ。

_gby_hash_aggregation_enabledバグ

2010-07-06T18:51:00.000-07:00

カスタムーからの問い合わせ：オラクルがどんな状況でもHASH GROUP BYを選択しないが、理由は何?

オラクルバージョンは10gR2（10.2.0.1）であります。


TPACK@ukja1021> select * from v$version where rownum = 1;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod

次のクエリを見れば、一番簡単なGroup By文でもHASH GROUP BYではなくてSORT GROUP BYを使っています。


create table t1
as
select level as c1
from dual
connect by level <= 10;


explain plan for 
select count(*)
from tpack.t1
group by c1;

-------------------------------------------
| Id  | Operation          | Name | Rows  |
-------------------------------------------
|   0 | SELECT STATEMENT   |      |    10 |
|   1 |  SORT GROUP BY     |      |    10 |
|   2 |   TABLE ACCESS FULL| T1   |    10 |
-------------------------------------------

隠しパラメーターである_gby_hash_aggregation_enabledの値がFalseである可能性があるでしょう。確かそうです。


TPACK@ukja1021> col value format a10
TPACK@ukja1021> @para gby_hash
TPACK@ukja1021> set echo off
old   9: and i.ksppinm like '%&1%'
new   9: and i.ksppinm like '%gby_hash%'

NAME                           VALUE                IS_DEFAUL SES_MODIFI
------------------------------ -------------------- --------- ----------
SYS_MODIFI
----------
DESCRIPTION
-------------------------------------------------------------------------

_gby_hash_aggregation_enabled  FALSE                FALSE     true
immediate
enable group-by and aggregation using hash scheme

しかし、_gby_hash_aggregation_enabledパラメーターをTrueに変え、USE_HASH_AGGREGATIONヒントを与えても、かわりなくSORT GROUP BYが選べられます。


alter session set "_gby_hash_aggregation_enabled" = true;

explain plan for 
select /*+ use_hash_aggregation */ count(*)
from t1
group by c1;

-------------------------------------------
| Id  | Operation          | Name | Rows  |
-------------------------------------------
|   0 | SELECT STATEMENT   |      |    10 |
|   1 |  SORT GROUP BY     |      |    10 |
|   2 |   TABLE ACCESS FULL| T1   |    10 |
-------------------------------------------

これは正常的な状況とは言えません。MOSで検索してみたら、完璧に一致するバグが見つかりました。


Bug 8631742: ALTER SESSION SET ... NOT HAVING EFFECT IN 10.2.0.4
...
RELEASE NOTES:
]] Setting _gby_hash_aggregation_enabled at the session level did not
]] always take effect
REDISCOVERY INFORMATION:
If you change the use of hash aggregation at the session level, but this does
not affect the choice of aggregation method in subsequebtly parsed SQL,
you are probably hitting this bug.

このバグはパラメーターファイルで_gby_hash_aggregation_enabledパラメーターの値を指定する時にのみ起こります。


*._gby_hash_aggregation_enabled=FALSE

初期のHASH GROUP BY機能が多くのバグを持っていたから、パラメーターファイルでこのパラメーターをFalseで指定しているシステムが多いと思います。でもUSE_HASH_AGGREGATIONヒントを使うにもかかわらずHASH GROUP BY機能が動作しないというのは予想しなかった副作用でしょう。

このバグは10.2.0.5でパッチされました。

INSERT...VALUESコマンドとAPPENDヒント

2010-06-20T23:14:00.000-07:00

1つの行のインサートにAPPENDヒントを用いたDirect Path Modeが必要なのかよく分かりません。とにかく、オラクルは11gからこのようなモードを支援するようにしました。すなわちINSERT...VALUES...コマンドでもAPPENDヒントが動作するように修正されました。もっと詳細に整理してみれば...

Oracle 10gまではINSERT...VALUES...コマンドにAPPENDヒントを与えても無視されます。すなわち、APPENDヒントはINSERT...SELECT...コマンドでだけ動作します。
APPENDヒントによってDirect Path Modeで動作すると行をインサートするとき現在セグメントの空きブロックを無視し（同時にバッファーキャッシュを経緯しなくて）セグメントのHigh Water MarkのあとにAppendさせてしまいます。したがって大量のデータを追加する時速度は速いがデータファイルにその分不要な空き容量が残りかねません。（でもこの空き容量もあとで使用されるはずです）
Oracle 11gR1ではINSERT...VALUES...コマンドでもAPPENDヒントが動作します。隠しパラメーター_direct_path_insert_featuresで制御できます。
Oracle 11gR2ではINSERT...VALUES...コマンドでAPPENDヒントを与えて無視されます。かわりにAPPEND_VALUESというヒントが追加されました。すなわちAPPEND_VALUESヒントを使用すればINSERT...VALUES...コマンドでもDirect Path Modeでインサートされます。

少し複雑になったでしょう。下記は簡単なテスト結果です。


create table t1(c1 number);

insert into t1 values(1);
commit;
insert into t1 values(2);
commit;

-- （2件の行をインサートして、Conventional Path Modeであるため二つの行が同じブロックにあるはずです）
select
 dbms_rowid.rowid_relative_fno(rowid) as file#,
 dbms_rowid.rowid_block_number(rowid) as block#
from t1;

-- 10.2.0.1
     FILE#     BLOCK#
---------- ----------
         4        853
         4        853

-- 11.1.0.6
     FILE#     BLOCK#
---------- ----------
         4        758
         4        758

-- （APPENDヒントが与えられたINSERT...VALUES...コマンドです）
insert /*+ append */ into t1 values(3);
commit;

-- 10.2.0.1ではAPPENDヒントが無視されるためやはり同じブロックにインサートされます。
     FILE#     BLOCK#
---------- ----------
         4        853
         4        853
         4        853

-- でも11.1.0.6ではAPPENDヒントが動作し、その結果High Water Markの以後にインサートされてしまいます。
     FILE#     BLOCK#
---------- ----------
         4        758
         4        758
         4        769

-- 11.2.0.1ではAPPEND_VALUESヒントがその役割を代わります。
iinsert /*+ append_values */ into t1 values(3);
commit;

     FILE#     BLOCK#
---------- ----------
         4        526
         4        526
         4        528

なぜオラクル開発者たちが急にINSERT...VALUES...コマンドでもAPPENDヒントが動作することに変えたんでしょうか。いくら考えてみてもわかりません。誰かその理由が浮かんでくる方あります?

PGAサイズの非正常的な増加

2010-06-15T21:18:00.000-07:00

PGAサイズが多すぎるとシステムに多い問題を起こします。非正常的なPGAサイズの問題を分析する最高の方法はPGAヒープダンプを落としてそれを精密分析することです。しかし、PGAのサイズ増加が速すぎる場合は手動的にダンプコマンドを実行するのはむずかしいはずです。

幸い、オラクルが提供する診断イベントを活用すればPGAヒープダンプを自動的かすることができます。

1. まず、10261診断イベントを通じてPGAヒープダンプサイズを制限します。たとえば、下記のコマンドでPGAヒープサイズを100000KBに制限できます。


alter system set events '10261 trace name context forever, level 100000';

2. 10261イベントが存在する場合、PGAのサイズが設定したサイズを超えるプロセスはORA-600 [723]エラーとともに失敗します。


-- make big pga
declare
 type varchar2_array is table of varchar2(32767) index by pls_integer;
 vc  varchar2_array;
 v  varchar2(32767);
begin
 for idx in 1 .. 10000 loop
 v := rpad('x',32767,'x');
 vc(idx) := v;
 end loop;
end;
/

ERROR at line 1:
ORA-00600: internal error code, arguments: [723], [41000], [pga heap], [], [],
[], [], []

3. この時、600診断イベントをPGAヒープダンプを実行するように設定すれば、10261→600→ヒープダンプの手順で自動的にPGAヒープダンプが実行されます。


alter system set events '600 trace name heapdump level 0x20000001';

4. 下記は自動的に生成されたPGAヒープダンプの一部です。特に、ダンプレベル0x20000001のおかげで下位Subheapを含んだダンプが記録されます。


DDE: Problem Key 'ORA 600 [723]' was flood controlled (0x2) (incident: 44800)
ORA-00600: internal error code, arguments: [723], [41000], [pga heap], [], [], [], [], []
****** ERROR: PGA size limit exceeded: 102450812 > 102400000 *****
******************************************************
HEAP DUMP heap name="pga heap"  desc=11AFB098
 extent sz=0x206c alt=92 het=32767 rec=0 flg=2 opc=1
 parent=00000000 owner=00000000 nex=00000000 xsz=0xfff8 heap=00000000
 fl2=0x60, nex=00000000
EXTENT 0 addr=39150008
  Chunk 39150010 sz=    24528    free      "               "
  Chunk 39155fe0 sz=    40992    freeable  "koh-kghu call  "  ds=0D4D9A60
EXTENT 1 addr=39140008
  Chunk 39140010 sz=    24528    free      "               "
  Chunk 39145fe0 sz=    40992    freeable  "koh-kghu call  "  ds=0D4D9A60
...

5. 最後の段階はヒープダンプを分析してどんなオブジェクトがヒープを使用しているのかを見破ることです。例えば、私はティパックという個人的なライブラリーを使用します。


select * from table(tpack.heap_file_report('C:\oracle\diag\rdbms\ukja1106\ukja1106\trace\ukja1106_ora_3640.trc'));

TYPE     HEAP_NAME        ITEM             ITEM_COUNT  ITEM_SIZE  HEAP_SIZE      RATIO
-------- ---------------- ---------------- ---------- ---------- ---------- ----------
HEAP     pga heap                                   0      97.14      97.14        100
HEAP     top call heap                              0        .18        .18        100
HEAP     top uga heap                               0        .31        .31        100
CHUNK    pga heap         free                   1554       36.2       97.1       37.3
CHUNK    pga heap         recreate                  9          0       97.1          0
CHUNK    pga heap         perm                     14          0       97.1          0
CHUNK    pga heap         freeable               1597       60.7       97.1       62.5
CHUNK    top uga heap     recreate                  1          0         .3       19.9
CHUNK    top uga heap     free                      5          0         .3          0
CHUNK    top uga heap     freeable                  4         .2         .3       79.9
CHUNK    top call heap    free                      3         .1         .1       65.5
CHUNK    top call heap    recreate                  2          0         .1          1
CHUNK    top call heap    freeable                  1          0         .1       33.3
CHUNK    top call heap    perm                      1          0         .1          0
OBJECT   pga heap         kews sqlstat st           1          0       97.1          0
OBJECT   pga heap         pesom.c:Proces            3          0       97.1          0
...

6. オラクルの診断イベントのほかに、V$SESSTATビューをモニターリングしながらメモリーサイズがあるサイズを超える時、PGAヒープダンプを行なう方法もあります。例えば、前述のティパックライブラリーを次のように利用できます。


col report_id new_value report_id

select tpack_server.create_report('Heap Dump') as report_id from dual;

exec tpack_server.add_parameter('&report_id', 'dump_level', '0x20000001');
exec tpack_server.add_parameter('&report_id', 'get_whole_contents', 0);

exec tpack_server.add_condition('&report_id', 'STAT', 'session pga memory', '>100000000', 'SUM');

exec tpack_server.register_report('&report_id');

-- start server
exec tpack_server.start_server;

PGAヒープサイズが100000000Bに達すると、ティパックはあらかじめ定義されているプロシージャを実行してヒープダンプを落とします。


Fri Jun 11 06:19:10 GMT+00:00 2010 : Session 142 got! sum=659645392, name = session pga memory
...
Fri Jun 11 06:27:50 GMT+00:00 2010 : executing report 1:142:1973827792 for session 142
Fri Jun 11 06:27:55 GMT+00:00 2010 : executing report = begin tpack.heap_dump(  dump_level=>'0x20000001', get_whole_contents=>0,  session_id => 142); end;
...

10261と600診断イベントは仮の方便にすぎないでしょう。最も重要なのはヒープダンプを注意深く分析してPGAサイズの非正常的な増加を防ぐことです。

Library cache pin競合の面白いケース

2010-05-11T00:24:00.000-07:00

最近、面白いlibrary cache pin（もしくはMutex）の競合の事例を経験しました。

（この例ではTPackという個人的なライブラリーを使用していますが、すべての情報はX$View,V$View,Trace Fileなどから取得できます。）

１．次のようにテーブルを作ります。


drop table t1 purge;
create table t1(c1 int);
insert into t1 values(1);
commit;

２．セッション＃１で次のようなSQLコマンドを行います。１００８エーらが発生するのに注意してください。


       SID    SERIAL# PID
---------- ---------- ----------
       147      23608 11556

1 row selected.

Elapsed: 00:00:05.12

TPACK@ukja1021> declare
  2    v_value   number;
  3  begin
  4    execute immediate 'select 1 from t1 where c1 = :b1'
  5        into v_value;
  6
  7    dbms_output.put_line('value = ' || v_value);
  8
  9  end;
 10  /
declare
*
ERROR at line 1:
ORA-01008: not all variables bound
ORA-06512: at line 4

３．セッション＃２が同じコマンドを実行します。でも、ブロックされて待機ようになります。


       SID    SERIAL# PID
---------- ---------- ----------
       148      56408 11736

Elapsed: 00:00:00.00

TPACK@ukja1021> declare
  2    v_value   number;
  3  begin
  4    execute immediate 'select 1 from t1 where c1 = :b1'
  5        into v_value;
  6
  7    dbms_output.put_line('value = ' || v_value);
  8
  9  end;
 10  /

４．なぜセッション＃２が待機するのでしょうか。詳細な待機情報を分析してみます。セッション＃１（１４７）がCURSORタイプ（SQL）のオブジェクトに対してlibrary cache pinをExclusiveモードで獲得しているのが原因であることがわらります。


TPACK@ukja1021> select * from table(tpack.session_detail(&sid));
Enter value for sid: 148
old   1: select * from table(tpack.session_detail(&sid))
new   1: select * from table(tpack.session_detail(148))

NAME                           VALUE
------------------------------ --------------------
SID                            148
Serial#                        56408
SPID                           11736
Program                        sqlplus.exe
Process                        7940:1228
Module                         SQL*Plus
SQL ID
Child No
SQL Text
Status                         ACTIVE
Blocking Instance              1
Blocking Session               147
Event                          library cache pin
Seq#                           29
P1(P1raw)                      764496508(2D914A7C)
P2(P2raw)                      764496508(2CDC1330)
P3(P3raw)                      764496508(000000C8)
Seconds in wait                81
State                          WAITING
Wait Event                     library cache pin
Holder SID                     147
Namespace                      CURSOR
Object                         select 1 from t1 whe
                               re c1 = :b1

Holding Mode                   3(X)

24 rows selected.

５．より正確な情報のために待機しているセッション＃１に対してコールスタックをプロファイリングしてみます。


TPACK@ukja1021> select * from table(tpack.callstack_prof_report(&sid));
Enter value for sid: 148
old   1: select * from table(tpack.callstack_prof_report(&sid))
new   1: select * from table(tpack.callstack_prof_report(148))

STACK_TRACE
--------------------------------------------------------------------------------
   HIT_CNT    HIT_PCT
---------- ----------
7C80B710
 ->_OracleThreadStart@4
  ->_opimai
   ->_opimai_real
    ->_sou2o
     ->_opidrv
      ->_opiodr
       ->_opiino
        ->_opitsk
         ->_ttcpip
          ->_opiodr
           ->_kpoal8
            ->_opiexe
             ->_kkxexe
              ->_peicnt
               ->_plsql_run
                ->_pfrrun
                 ->_pfrrun_no_tool
                  ->_pfrinstr_EXIM
                   ->_pevm_EXIM
                    ->_psdnal
                     ->_psddr0
                      ->_rpidrv
                       ->_rpiswu2
                        ->_rpidru
                         ->_rpidrus
                          ->_opiodr
                           ->_opipls
                            ->_opiosq0
                             ->_kksParseCursor
                              ->_kkspsc0
                               ->_kksfbc
                                ->_kksSearchChildList
                                 ->_kksCheckCursor
                                  ->_kkslce
                                   ->_kxsGetRuntimeLock
                                    ->_kglpin
                                     ->_kglpnal
                                      ->__PGOSF169__ksfwat
                                       ->_kslwait
                                        ->_kskthbwt
                                         ->_kslwaitns
                                          ->_ksliwat
                                           ->_skgpwwait
                                            ->7C80253D
                                             ->00000000
                                              ->7C80B710
                                               ->_OracleOradebugThreadStart@4
                                                ->_ssthreadsrgruncallback
                                                 ->_ksdxcb
                                                  ->_ksdxfdmp
                                                   ->_ksedst_tracecb
        10        100

関数名_pevm_EXIMに注意してください。これはExecute Immediateコマンドが実行しているのを意味します。複雑な状況でこのような待機が発生したらコールスタック情報が特に有効です。

これは疑いなくバグであるはずです。MOS（Metalink）で次のようなKeywordで検索してみます。

library cache pin
execute immediate
pevm_EXIM

いくつかの簡単な情報を適切に取得すれば問題の分析がより正確で便利にできるようになることが分かります。

Oracle Hang状態でActive Session Listを獲得しよう。

2010-04-25T18:27:00.000-07:00

Maxgaugeのようなツールの最高のメリットはOracle Hang状態でもActive Session Listを得ることができるということです。待機イベントとSQL情報が含まれたActive Session Listこそがすべての性能トラブルシューティングの初めです。ここからすべてのトラブルシューティングが始まります。

MaxgaugeのようなツールがOracle Hang状況でもデータを収集できるのはDMA（Direct Memory Access）を使用するためです。この方法はOracleのCOE（Center of Expertise)チームが極限の状況、すなわちSQLで必要な情報を収集できない際使用していた方法です。これがMaxgaugeのようなツールのおかげで普遍化されたのです。

もしMaxgaugeのようなツールがなければどうすればいいでしょうか。Oracleが提供するASHDUMP機能をPreliminary Connectionとともに使えば同じ効果が得られます。

Preliminary ConnectionとはSQL*Net方式ではない、Direct Memory Access方式で接続することです。
ASHDUMPとはActive Session ListのメモリーバージョンであるASH（Active Session History）をテキストファイルに書き込む機能です。

従って、この二つの機能を一緒に使えばまるでDMA方式でActive Session Listを得るのは同じ効果があります。

簡単な例で説明します。

まずPreliminary Connectionを結びます。


#> sqlplus -prelim sys/oracle@ukja1106 as sysdba

SQL*Plus: Release 11.1.0.6.0 - Production on Mon Apr 26 09:43:35 2010

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

一般的なクエリは動きません。


alter session set nls_date_format='yyyy/mm/dd hh24:mi:ss'

*

ERROR at line 1:

ORA-01012: not logged on

Process ID: 0

Session ID: 0 Serial number: 0

Preliminary Connection状態でASHDUMPを行ないます。レベル（10）は10分を意味します。すなわち、過去の10分間のASHを意味します。


SYS@ukja1106> oradebug setmypid

Statement processed.

SYS@ukja1106> oradebug dump ashdump 10

Statement processed.

SYS@ukja1106> oradebug tracefile_name

c:\oracle\diag\rdbms\ukja1106\ukja1106\trace\ukja1106_ora_12152.trc

ダンプファイルの内容は次のようです。11gからはActive Session Listとともに該当リストをテーブルに格納するためのスクリプトまで提供します。ハングの悪夢が終わったあと（大部分リスタート）、正確な分析をする目的です。


Processing Oradebug command 'dump ashdump 10'

ASH dump

<<>>

****************

SCRIPT TO IMPORT

****************

------------------------------------------

Step 1: Create destination table 

------------------------------------------

CREATE TABLE ashdump AS

SELECT * FROM SYS.WRH$_ACTIVE_SESSION_HISTORY WHERE rownum < 0

----------------------------------------------------------------

Step 2: Create the SQL*Loader control file  as below

----------------------------------------------------------------

load data 

infile * "str '\n####\n'"

append

into table ashdump

fields terminated by ',' optionally enclosed by '"'

(                               

SNAP_ID  CONSTANT 0           , 

DBID                          , 

INSTANCE_NUMBER               , 

SAMPLE_ID                     , 

SAMPLE_TIME TIMESTAMP ENCLOSED BY '"' AND '"' "TO_TIMESTAMP(:SAMPLE_TIME   ,'MM-DD-YYYY HH24:MI:SSXFF')"   , 

SESSION_ID                    , 

SESSION_SERIAL#               , 

SESSION_TYPE                  , 

USER_ID                       , 

SQL_ID                        , 

SQL_CHILD_NUMBER              , 

SQL_OPCODE                    , 

FORCE_MATCHING_SIGNATURE      , 

TOP_LEVEL_SQL_ID              , 

TOP_LEVEL_SQL_OPCODE          , 

SQL_PLAN_HASH_VALUE           , 

SQL_PLAN_LINE_ID              , 

SQL_PLAN_OPERATION#           , 

SQL_PLAN_OPTIONS#             , 

SQL_EXEC_ID                   , 

SQL_EXEC_START DATE 'MM/DD/YYYY HH24:MI:SS' ENCLOSED BY '"' AND '"' ":SQL_EXEC_START"   , 

PLSQL_ENTRY_OBJECT_ID         , 

PLSQL_ENTRY_SUBPROGRAM_ID     , 

PLSQL_OBJECT_ID               , 

PLSQL_SUBPROGRAM_ID           , 

QC_INSTANCE_ID                , 

QC_SESSION_ID                 , 

QC_SESSION_SERIAL#            , 

EVENT_ID                      , 

SEQ#                          , 

P1                            , 

P2                            , 

P3                            , 

WAIT_TIME                     , 

TIME_WAITED                   , 

BLOCKING_SESSION              , 

BLOCKING_SESSION_SERIAL#      , 

CURRENT_OBJ#                  , 

CURRENT_FILE#                 , 

CURRENT_BLOCK#                , 

CURRENT_ROW#                  , 

CONSUMER_GROUP_ID             , 

XID                           , 

REMOTE_INSTANCE#              , 

TIME_MODEL                    , 

SERVICE_HASH                  , 

PROGRAM                       , 

MODULE                        , 

ACTION                        , 

CLIENT_ID                       

)                               

---------------------------------------------------

Step 3: Load the ash rows dumped in this trace file

---------------------------------------------------

sqlldr userid/password control=ashldr.ctl data= errors=1000000

---------------------------------------------------

<<>>

<<>>

####

58646642,1,12519562,"04-26-2010 09:44:01.822000000",160,1,2,0,

"",0,0,0,"",0,0,0,0,0,

0,"",0,0,0,0,0,0,0,

3213517201,9858,0,3,1,0,69788,4294967295,0,

4294967295,0,0,0,0,,0,0,165959219,

"ORACLE.EXE (CKPT)","",

"",""

####

58646642,1,12519486,"04-26-2010 09:42:45.808000000",160,1,2,0,

"",0,0,0,"",0,0,0,0,0,

0,"",0,0,0,0,0,0,0,

3213517201,9767,1,1,1,0,38825,4294967295,0,

4294967295,0,0,0,0,,0,0,165959219,

"ORACLE.EXE (CKPT)","",

"",""

####

58646642,1,12519416,"04-26-2010 09:41:35.770000000",160,1,2,0,

"",0,0,0,"",0,0,0,0,0,

0,"",0,0,0,0,0,0,0,

4078387448,9683,3,3,3,0,11083,4294967295,0,

4294967295,0,0,0,0,,0,0,165959219,

"ORACLE.EXE (CKPT)","",

"",""

####

58646642,1,12519384,"04-26-2010 09:41:03.774000000",163,1,2,0,

"",0,0,0,"",0,0,0,0,0,

0,"",0,0,0,0,0,0,0,

3176176482,40612,5,1,1000,999888,0,4294967291,0,

4294967295,0,0,0,0,,0,0,165959219,

"ORACLE.EXE (DIA0)","",

"",""

####

58646642,1,12519304,"04-26-2010 09:39:43.719000000",160,1,2,0,

"",0,0,0,"",0,0,0,0,0,

0,"",0,0,0,0,0,0,0,

3213517201,9551,1,1,1,0,38798,4294967295,0,

4294967295,0,0,0,0,,0,0,165959219,

"ORACLE.EXE (CKPT)","",

"",""

####

58646642,1,12519265,"04-26-2010 09:39:04.663000000",163,1,2,0,

"",0,0,0,"",0,0,0,0,0,

0,"",0,0,0,0,0,0,0,

3176176482,40493,5,1,1000,999941,0,4294967291,0,

4294967295,0,0,0,0,,0,0,165959219,

"ORACLE.EXE (DIA0)","",

"",""

####

58646642,1,12519183,"04-26-2010 09:37:42.554000000",160,1,2,0,

"",0,0,0,"",0,0,0,0,0,

0,"",0,0,0,0,0,0,0,

3213517201,9406,0,1,1,0,54077,4294967295,0,

4294967295,0,0,0,0,,0,0,165959219,

"ORACLE.EXE (CKPT)","",

"",""

####

<<>>



*** 2010-04-26 09:45:51.625

Oradebug command 'dump ashdump 10' console output:

事後分析用で使用したら有効であるはずです。ただし、Preliminary ConnectionとOradebugは非公式的な支援機能だから徹底なテストのあとに使用しなければならないし、可能な限りオラクル支援エンジニアの承認の上で使用しなければなりません。

もっと詳しい情報は次のリンクを参照してください。

Preliminary ConnectionとDirect Access
MLノート: 243132.1

SQLでOSの資源を操作したい時　-　Java Stored Procedureの活用

2010-03-23T00:23:00.000-07:00

SQLとPL/SQLの多様な機能に慣れてみればOracleがインストールされているOSシステムの資源をSQLやPL/SQLで制御したくなります。SQLとPL/SQLの活用を極大化したい自然な願いだと思います。Java Stored Procedureがこのような要求事項を解決するに一番強力なツールと言えます。

実際に私が開発しているトラブルシューチングパックというライブラリーも内部的にJava Stored Procedureを幅広く活用しています。

簡単な例を通じて説明してみます。次のような要求事項があります。

オラクルが設置されたシステムの特定のフォルダーのファイルリストをSQL分を通じて得たいです。

次のように解決できます。


UKJA@ukja1106> connect sys/oracle@ukja1106 as sysdba
Connected.

Session altered.

Elapsed: 00:00:00.00

       SID    SERIAL# PID
---------- ---------- ----------
       129      12732 12376

Elapsed: 00:00:00.00
SYS@ukja1106> 
SYS@ukja1106> exec dbms_java.grant_permission('UKJA', 'SYS:java.io.FilePermission', -
>   'c:\temp', 'read ,write, execute, delete');

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.03
SYS@ukja1106> 
SYS@ukja1106> connect ukja/ukja@ukja1106
Connected.

Session altered.

Elapsed: 00:00:00.00

       SID    SERIAL# PID
---------- ---------- ----------
       129      12734 10400

Elapsed: 00:00:00.00
UKJA@ukja1106> 
UKJA@ukja1106> create or replace and compile java source named FileList
  2  as
  3    import java.io.*;
  4    import java.util.*;
  5    import java.sql.*;
  6    import oracle.sql.*;
  7  
  8    public class FileList {
  9  
 10       public static oracle.sql.ARRAY getFileList() throws Exception {
 11  
 12         File f = new File("c:\\temp");
 13         String[] flist = f.list();
 14  
 15         Connection conn = DriverManager.getConnection("jdbc:default:connection:");
 16  
 17         ArrayDescriptor desc = ArrayDescriptor.createDescriptor("VARCHAR2_ARRAY", conn);
 18         ARRAY array = new ARRAY(desc, conn, flist);
 19         return array;
 20       }
 21  
 22    }
 23  ;
 24  /

Java created.

Elapsed: 00:00:00.18
UKJA@ukja1106> 
UKJA@ukja1106> create or replace type varchar2_array as table of varchar2(1000);
  2  /

Type created.

Elapsed: 00:00:00.01
UKJA@ukja1106> 
UKJA@ukja1106> 
UKJA@ukja1106> create or replace function get_file_list
  2    return varchar2_array
  3    as language java
  4    name 'FileList.getFileList() return oracle.sql.ARRAY';
  5  /

Function created.

Elapsed: 00:00:00.00
UKJA@ukja1106> 
UKJA@ukja1106> select * from table(get_file_list);

COLUMN_VALUE
--------------------------------------------------------------------------------
1269319491031.sql
1269319491031.txt
20100323.log
343225818.out
343225818.trc

Elapsed: 00:00:00.03
UKJA@ukja1106>

本当に簡単で強いせす。活用によって多くの作業を自動化できるはずです。

Oracle 11.1.0.6のトリガーバグ分析　－　ティパックの活用

2010-03-11T20:55:00.000-08:00

この頃トラブルシューティングパック（Troubleshooting Pack。以下ティパック）という名前のライブラリーを開発しています。オラクルが提供するトラブルシューティング機能（診断イベント、ダンプ、X$ビュー）を利用して普遍的ないくつかの性能問題について意味のあるレポートを提供する目的で企画されました。

次のアーティクルにOracle 11.1.0.6の面白いトリガー関係のバグが紹介されています。

Inserts Experiencing an Increasing CPU Consumption

このバグで現れる現象ががティパックを活用して問題を分析できる良い例に見えて簡単に紹介します。

まず上のアーティクルで説明している問題は次のようです。


UKJA@ukja1106> create table t1(c1 int);

Table created.

UKJA@ukja1106> create table t2(c1 int);

Table created.

次のように二つのトリガーを作ります。二つ目のトリガーをどんな意味もないトリガーだけれど開発規則によって追加されました。何もしないトリガーなので性能に与える影響はほとんどないはずです。


UKJA@ukja1106> create or replace trigger t1_trg1 after insert on t1 for each row
  2  begin
  3    insert into t2 values(:new.c1);
  4  end;
  5  /

Trigger created.

UKJA@ukja1106> 
UKJA@ukja1106> create or replace trigger t1_trg2 after insert on t2 for each row
  2  begin
  3    declare
  4    numrows number;
  5    begin
  6    numrows := 1;
  7    end;
  8  end;
  9  /

Trigger created.

どころが、Oracle 11.1.0.6で次のように繰り返しにテーブルT1に対してInsertを行うとだんだんその性能が遅れていきます。


UKJA@ukja1106> declare
  2    v_start_time  number := dbms_utility.get_time;
  3  begin
  4    for idx in 1 .. 50000 loop
  5    insert into t1 values(idx);
  6  
  7    if mod(idx, 1000) = 0 then
  8      dbms_output.put_line(idx || 'th exe = ' || (dbms_utility.get_time - v_start_time)/100);
  9      v_start_time := dbms_utility.get_time;
 10    end if;
 11    end loop;
 12  end;
 13  /
1000th exe = .14
2000th exe = .17
3000th exe = .16
4000th exe = .17
5000th exe = .15
6000th exe = .19
7000th exe = .16
8000th exe = .2
9000th exe = .19
10000th exe = .2
11000th exe = .21
12000th exe = .23
13000th exe = .22
14000th exe = .23
15000th exe = .25
16000th exe = .24
17000th exe = .23
18000th exe = .27
19000th exe = .28
20000th exe = .26
21000th exe = .27
22000th exe = .28
23000th exe = .3
24000th exe = .31
25000th exe = .3
26000th exe = .34
27000th exe = .31
28000th exe = .35
29000th exe = .36
30000th exe = .43
31000th exe = .52
32000th exe = .45
33000th exe = .49
34000th exe = .43
35000th exe = .68
36000th exe = .64
37000th exe = .89
38000th exe = .53
39000th exe = .44
40000th exe = .47
41000th exe = .48
42000th exe = .52
43000th exe = .56
44000th exe = .59
45000th exe = .64
46000th exe = .69
47000th exe = .7
48000th exe = .77
49000th exe = .78
50000th exe = .84

PL/SQL procedure successfully completed.

Oracle 10gR2やOracle 11.1.0.7ではこのような現象は発生しません。Oracle 11.1.0.6のバグに見えます。

上のアーティクルでは次のような二つの現象を報告しています。

実行回数が増えるほどCPU使用時間が増えていく（SQL*Trace）
実行回数が増えるほどPGA使用量が増えていく（V$SESSTAT）

上の現象から見るとたぶんわけのわからない理由のためメモリーを使いすぎて、その過程でCPU使用時間も増えるように見えます。

この問題をティパック（Troubleshooting Pack）を通じて分析してみます。

Session Snapshot機能を通じてどんな性能指標がおもに増加するか観察する。
PGA Heap Dump分析を通じてPGAのサイズが増加する原因を分析します。
Call Stack Traceの分析を通じてどんな係数をおもに呼び出しながらCPUを使用するか分析する。

下にその結果があります。

Session Snapshotで得た結果はアーティクルの結果と一致します。500,000件のInsertが終わったあとPGAのサイズが1.6Mから45Mまで増加したのがわかります。


01. statistics

NAME                                          DIFF         VALUE1         VALUE2
----------------------------------- -------------- -------------- --------------
session pga memory                      45,285,376      1,663,952     46,949,328
session pga memory max                  45,154,304      1,795,024     46,949,328
session uga memory                      45,104,696        891,300     45,995,996
session uga memory max                  44,973,768      1,022,228     45,995,996
...

PGAのサイズが増加した原因を分析するためにPGAレポートを生成します。


UKJA@ukja1106> select * from table(tpack.get_pga_report);

...
02. Size per Chunk Type

Heap Name            Chunk Type Count      Chunk Size Heap Size  Ratio(%)
-------------------- ---------- ---------- ---------- ---------- ----------
...
kxs-heap-p           perm                1          0       20.9          0
kxs-heap-p           freeable       250005       20.9       20.9       99.6
pesom.c:Proces       free                2          0          0       68.3
...


03. Size Per Object Type
Heap Name            Obj Type             Count      Chunk Si Heap Siz Ratio
-------------------- -------------------- ---------- -------- -------- -----
...
kxs-heap-p           kxt.c: PL/SQL p          150000     16.3     20.9  77.7
kxs-heap-p           kxt.c: Trigger           100000      4.5     20.9  21.8
kxs-heap-p           none                       3334        0     20.9    .3
kxs-heap-p           kxtcin:kxscplx                1        0     20.9     0
...

Kxs-heap-pヒープのfreeable Chunk（再活用可能なChunk）の数が250,005個に達して、20M程度のサイズを占めています。メモリーりーくが疑われます。KXSはKernel Execution Shared Cursorの略語です。Shared Cursorと関連したメモリー問題の可能性があります。PGA内のShared Cursorの領域はSESSION_CACHED_CURSORパラメータで制御されます。

Ksx-heap-pヒープのkxt.c: PL/SQL p、kxt.c: Triggerオブジェクトの数が250,000個です。この値はkxs-heap-pヒープのfreeable Chunkの数とほとんど一致しています。KXTはKernel Execution Triggerの略語です。

情報を総合してみると、トリガー実行関係のオブジェクトがShared Cursor領域で再活用されないまま繰り返しに追加され、メモリーとCPUの使用量が一緒に増加していると仮定できます。

Call Stack Trace分析を通じて実際にどんなコードがおもに呼び出されているのか確認してみます。


UKJA@ukja1106> select * from table(tpack.stacktrace_profile_report(&1,5,0.1));
old   1: select * from table(tpack.stacktrace_profile_report(&1,5,0.1))
new   1: select * from table(tpack.stacktrace_profile_report(134,5,0.1))


STACK_TRACE
--------------------------------------------------------------------------------
   HIT_CNT    HIT_PCT
---------- ----------
->00000000->7C80B710->_OracleThreadStart@4()+764->_opimai()+92->_opimai_real()+1
30->_sou2o()+45->_opidrv()+807->_opiodr()+1224->_opiino()+1067->_opitsk()+1278->
_ttcpip()+2733->_opiodr()+1224->_kpoal8()+2299->_opiexe()+14438->_kkxexe()+1046-
>_peicnt()+250->_plsql_run()+729->_pfrrun()+875->_pfrrun_no_tool()+56->_pfrinstr
_EXECC()+58->_pevm_EXECC()+295->_psdnal()+348->_psddr0()+487->_rpidrv()+1357->_r
piswu2()+560->_rpidru()+88->_rpidrus()+178->_opiodr()+1224->_opipls()+1312->_opi
exe()+5344->_insexe()+1027->_qerltcFetch()+896->_qerltcInsertValuesRop()+243->_q
erltcLoadStateMachine()+609->__PGOSF492__qerltcNoKdtBufferedInsRowCBK()+336->__V
Infreq__qesltcAfterRowProcessing()+238->_qesltcExecuteAfterRowTriggers()+1299->_
kxtexe()+483->_rpiswu2()+560->_kxtex1()+478->_kkxtexe()+901->_peiet_execute_trig
ger()+47->_peicnt()+250->_plsql_run()+729->_pfrrun()+875->_pfrrun_no_tool()+56->
_pfrinstr_EXECC()+58->_pevm_EXECC()+295->_psdnal()+348->_psddr0()+487->_rpidrv()
+1357->_rpiswu2()+560->_rpidru()+88->_rpidrus()+178->_opiodr()+1224->_opipls()+1
312->_opiexe()+1823->_kksfbc()+12485->_kxtInstantiateAllTriggers()+77->_kxtCreat
eTriggerInst()+250->_kxsPersistentHeapAllocFree()+42->_kghalf()+188->00000000->7
C80B710->_OracleOradebugThreadStart@4()+825->_ssthreadsrgruncallback()+432->_ksd
xcb()+1780->_ksdxfdmp()+850->_ksedst_tracecb()+53->_ksedst1()+91->_skdstdst()+11
4
         8         16

->00000000->7C80B710->_OracleThreadStart@4()+764->_opimai()+92->_opimai_real()+1
30->_sou2o()+45->_opidrv()+807->_opiodr()+1224->_opiino()+1067->_opitsk()+1278->
_ttcpip()+2733->_opiodr()+1224->_kpoal8()+2299->_opiexe()+14438->_kkxexe()+1046-
>_peicnt()+250->_plsql_run()+729->_pfrrun()+875->_pfrrun_no_tool()+56->_pfrinstr
_EXECC()+58->_pevm_EXECC()+295->_psdnal()+348->_psddr0()+487->_rpidrv()+1357->_r
piswu2()+560->_rpidru()+88->_rpidrus()+178->_opiodr()+1224->_opipls()+1312->_opi
exe()+1823->_kksfbc()+12485->_kxtInstantiateAllTriggers()+77->_kxtCreateTriggerI
nst()+250->_kxsPersistentHeapAllocFree()+42->_kghalf()+188->00000000->7C80B710->
_OracleOradebugThreadStart@4()+825->_ssthreadsrgruncallback()+432->_ksdxcb()+178
0->_ksdxfdmp()+850->_ksedst_tracecb()+53->_ksedst1()+91->_skdstdst()+114
         3          6

->00000000->7C80B710->_OracleThreadStart@4()+764->_opimai()+92->_opimai_real()+1
30->_sou2o()+45->_opidrv()+807->_opiodr()+1224->_opiino()+1067->_opitsk()+1278->
_ttcpip()+2733->_opiodr()+1224->_kpoal8()+2299->_opiexe()+14438->_kkxexe()+1046-
>_peicnt()+250->_plsql_run()+729->_pfrrun()+875->_pfrrun_no_tool()+56->_pfrinstr
_EXECC()+58->_pevm_EXECC()+295->_psdnal()+348->_psddr0()+487->_rpidrv()+1357->_r
piswu2()+560->_rpidru()+88->_rpidrus()+178->_opiodr()+1224->_opipls()+1312->_opi
exe()+5344->_insexe()+1027->_qerltcFetch()+896->_qerltcInsertValuesRop()+243->_q
erltcLoadStateMachine()+609->__PGOSF492__qerltcNoKdtBufferedInsRowCBK()+336->__V
Infreq__qesltcAfterRowProcessing()+238->_qesltcExecuteAfterRowTriggers()+1299->_
kxtexe()+483->_rpiswu2()+560->_kxtex1()+478->_kkxtexe()+901->_peiet_execute_trig
ger()+47->_peicnt()+250->_plsql_run()+729->_pfrrun()+875->_pfrrun_no_tool()+56->
_pfrinstr_EXECC()+58->_pevm_EXECC()+295->_psdnal()+348->_psddr0()+487->_rpidrv()
+1357->_rpiswu2()+560->_rpidru()+88->_rpidrus()+178->_opiodr()+1224->_opipls()+1
312->_opiexe()+1823->_kksfbc()+12485->_kxtInstantiateAllTriggers()+77->_kxtCreat
eTriggerInst()+304->_kxsPersistentHeapAllocFree()+42->_kghalf()+188->00000000->7
C80B710->_OracleOradebugThreadStart@4()+825->_ssthreadsrgruncallback()+432->_ksd
xcb()+1780->_ksdxfdmp()+850->_ksedst_tracecb()+53->_ksedst1()+91->_skdstdst()+11
4
         3          6

...

Call Stack Traceを見ると下の呼びさしパターンが一番普遍的に発生していることがわかります。


_kxtInstantiateAllTriggers
_kxtCreateTriggerInst
_kxsPersistentHeapAllocFree

PGAレポートと完璧に一致する係数呼び出しパターンです。トリガーオブジェクトを続けて生成し、その過程でメモリーを続けて割り当てされています。

確かに、メモリー関係のバグの可能性が高そうです。こんな情報があればメタリンクをもっと正確に検索できます。下にメタリンクの検索結果があります。

バグ番号6400175が見えるでしょう。ほとんど完璧に一致する現象を報告しています。

オラクルが提供するいくつかの基本的な性能データを通じてオラクルでの性能異常現象を体系的に分析できるということを見せてくれる良い例だと思われます。

PS) 上の例で紹介されたティパックの機能は次のようなデータを利用しています。このデータたちを直接検索し、分析できると誰でも同一な分析が可能です。

V$SESSTAT
PGA Heap Dump (oradebug dump heapdump 0x20000001)
Call Stack (oradebug dump callstack 1)

Errorstackダンプで問題のSQLを突き止めること

2010-03-04T17:09:00.000-08:00

オラクルでエラーが発生したとき、どのSQL文が問題なのかを突き止める必要があります。例えば、alert.logファイルに次のようなエラーメッセージが記録されています。


Fri Mar 05 09:47:53 2010
ORA-1652: unable to extend temp segment by 128 in tablespace                 VERY_SMALL_TBS

どんなSQL文が犯人なのかを知らなければ、解決は難しいでしょ。

このような場合でやってみれるのがErrorStackダンプです。ErrorStackダンプを診断イベントと一緒に使えばエラーを起こしたSQL文がトレースファイルに記録されるようにすることができます。

簡単な例で説明します。まず小さなサイズ（10m）のテーブルスペースを作ります。


UKJA@ukja1021> create tablespace very_small_tbs
  2  datafile size 10m;

Tablespace created.

ORA-01652エラーが発生したら、ErrorStackダンプを実行するように診断イベントを掛けます。


UKJA@ukja1021> alter system set events '1652 trace name errorstack level 1, forever';

Session altered.

10mより大きいテーブルを作ればORA-01652エラーが発生します。


UKJA@ukja1021> create table tbig(c1)
  2  tablespace very_small_tbs
  3  as
  4  select rpad('x',1000) from dual
  5  connect by level <= 10000
  6  ;
select rpad('x',1000) from dual
                           *
ERROR at line 4:
ORA-01652: unable to extend temp segment by 128 in tablespace VERY_SMALL_TBS

UKJA@ukja1021> alter system set events '1652 trace name context off';

Session altered.

Alert.logファイルには次のようなエラーメッセージが残ります。


Fri Mar 05 09:47:53 2010
ORA-1652: unable to extend temp segment by 128 in tablespace                 VERY_SMALL_TBS

プロセスのダンプファイルにはエラー発生時のSQL文とCallStackトレースが記録してあります。


ORA-01652: unable to extend temp segment by 128 in tablespace VERY_SMALL_TBS
Current SQL statement for this session:
create table tbig(c1)
tablespace very_small_tbs
as
select rpad('x',1000) from dual
connect by level <= 10000
----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
_ksedst+38           CALLrel  _ksedst1+0           0 1
_ksedmp+898          CALLrel  _ksedst+0            0
_ksddoa+2088         CALLreg  00000000             1
_ksdpcg+238          CALLrel  _ksddoa+0            A9615C0 93C78C0
_ksdpec+230          CALLrel  _ksdpcg+0            674 C04A478 1
__PGOSF89__ksfpec+1  CALLrel  _ksdpec+0            674
18                                                 
_kgesev+88           CALLreg  00000000             A0C6760 674
_ksesec2+39          CALLrel  _kgesev+0            A0C6760 93C0020 674 2 C04A4E4
_ktsxterr+316        CALLrel  _ksesec2+0           674 0 80 0 1 E C04A55E
_ktfbtgex1+969       CALLrel  _ktsxterr+0          792DE5C 80 0
_ktsxs_add+1766      CALLrel  _ktfbtgex1+0         C04AD8C 3D C04AA50 80 18 A 3
                                                   0 0 C04AD50 37B3EE88
_ktsxssr_sadd+1409   CALLrel  _ktsxs_add+0         C04B048 C04AD8C 80 A 3 0 18 1
                                                   C04B11C C04AE08 C04ADC0 0
                                                   C04AD50
_ktrsexec+372        CALL???  00000000             C04B0D8
_ktelwbl+770         CALLrel  _ktrsexec+0          C04B0D8
_kdblba+168          CALLrel  _ktelwbl+0           792DE5C 1
_kdblGetBlockDba+58  CALLrel  _kdblba+0            
_kdblgb+26           CALLrel  _kdblGetBlockDba+0   C04B3C8 792DD9C
_kdblailb+2101       CALLrel  _kdblgb+0            
_kdblai+1560         CALLrel  _kdblailb+0          C04B3C8 792DC9C 792DD9C 0 1 1
_klclil1r+187        CALLrel  _kdblai+0            
_qerltRop+514        CALLrel  _klclil1r+0          792DBEC
_qercbiFetch+935     CALLreg  00000000             34C4F034 7FFF
_rwsfcd+95           CALL???  00000000             34C4F384 1C72EB4 34C4F034
                                                   7FFF
_qerltFetch+368      CALL???  00000000             34C4F148 1C72EB4 34C4F034
                                                   7FFF
_ctcdrv+7674         CALL???  00000000             34C4F034 1D28394 C04CE30 1
_opiexe+12257        CALLrel  _ctcdrv+0            34EE5F50 C04D548 C04D510
_opiosq0+6088        CALLrel  _opiexe+0            4 0 C04D8C0
_kpooprx+232         CALLrel  _opiosq0+0           3 E C04D9D8 A4
_kpoal8+775          CALLrel  _kpooprx+0           C04F6F8 C04E224 6D 1 0 A4
_opiodr+1099         CALLreg  00000000             5E 17 C04F6F4
_ttcpip+1273         CALLreg  00000000             5E 17 C04F6F4 0
_opitsk+1017         CALL???  00000000             
_opiino+1087         CALLrel  _opitsk+0            0 0
_opiodr+1099         CALLreg  00000000             3C 4 C04FC8C
_opidrv+819          CALLrel  _opiodr+0            3C 4 C04FC8C 0
_sou2o+45            CALLrel  _opidrv+0            3C 4 C04FC8C
_opimai_real+112     CALLrel  _sou2o+0             C04FC80 3C 4 C04FC8C
_opimai+92           CALLrel  _opimai_real+0       2 C04FCB8
_OracleThreadStart@  CALLrel  _opimai+0            
4+708                                              
7C80B710             CALLreg  00000000

ErrorStackダンプはそのレベルによっていろいろな有効な情報を提供してくれます。次のアーティクルで詳細な情報を得られます。

http://tech.e2sn.com/oracle/troubleshooting/how-to-read-errorstack-output

SQL文章レベルの診断イベント

2010-03-01T21:52:00.000-08:00

次のアーティクルを見るとOracle 11gからSQL文章レベルで診断イベントを適用する機能が追加されたのが分かります。

すなわち、特定のSQL IDに該当するSQL文章に対して10046イベントや10053イベントのような診断イベントを適用できます。Oracle 10gやその以下のバージョンでは診断イベントの最低のレベルはセッションでありました。SQL文章レベルで診断イベントを適用できることになるにつれて、システムに与える影響を最小化しながら正確に特定のSQL文章だけを分析できるようになりました。

簡単な使用例は次のようです。


UKJA@ukja1106> select * from t1 where c1 = 1;

        C1         C2
---------- ----------
         1          1

UKJA@ukja1106> 
UKJA@ukja1106> col prev_sql_id new_value sql_id
UKJA@ukja1106> select prev_sql_id from v$session where sid = userenv('sid');

PREV_SQL_ID
-------------
3c3yp27cag5mv

UKJA@ukja1106> 
UKJA@ukja1106> select sql_text from v$sql where sql_id = '&sql_id';
old   1: select sql_text from v$sql where sql_id = '&sql_id'
new   1: select sql_text from v$sql where sql_id = '3c3yp27cag5mv'

SQL_TEXT
--------------------------------------------------------------------------------
select * from t1 where c1 = 1

UKJA@ukja1106> 
UKJA@ukja1106> alter system flush shared_pool;

System altered.

UKJA@ukja1106> -- Enable 10046 Event
UKJA@ukja1106> alter system set events 'sql_trace[sql:&sql_id] level=12';
old   1: alter system set events 'sql_trace[sql:&sql_id] level=12'
new   1: alter system set events 'sql_trace[sql:3c3yp27cag5mv] level=12'

System altered.

UKJA@ukja1106> -- Enable 10053 Event
UKJA@ukja1106> alter system set events 'trace[sql_costing][sql:&sql_id]';
old   1: alter system set events 'trace[sql_costing][sql:&sql_id]'
new   1: alter system set events 'trace[sql_costing][sql:3c3yp27cag5mv]'

System altered.

UKJA@ukja1106> 
UKJA@ukja1106> select * from t1 where c1 = 1;

        C1         C2
---------- ----------
         1          1

UKJA@ukja1106> 
UKJA@ukja1106> select * from t1 where c1 = 2;

        C1         C2
---------- ----------
         2          2

UKJA@ukja1106> -- Disable 10046 Event
UKJA@ukja1106> alter system set events 'sql_trace[sql:&sql_id] off';
old   1: alter system set events 'sql_trace[sql:&sql_id] off'
new   1: alter system set events 'sql_trace[sql:3c3yp27cag5mv] off'

System altered.

UKJA@ukja1106> -- Disable 10053 Event
UKJA@ukja1106> alter system set events 'trace[sql_costing][sql:&sql_id] off';
old   1: alter system set events 'trace[sql_costing][sql:&sql_id] off'
new   1: alter system set events 'trace[sql_costing][sql:3c3yp27cag5mv] off'

System altered.

トレースファイルを見てみたら指定されたSQL IDに当たるSQL文章だけに対して診断イベントが適用されたことが分かります。


-- 10053 Event
OPTIMIZER INFORMATION

******************************************
----- Current SQL Statement for this session (sql_id=3c3yp27cag5mv) -----
select * from t1 where c1 = 1
*******************************************
Legend
The following abbreviations are used by optimizer trace.
CBQT - cost-based query transformation
JPPD - join predicate push-down
OJPPD - old-style (non-cost-based) JPPD
...

-- 10046 Event
PARSING IN CURSOR #6 len=29 dep=0 uid=88 oct=3 lid=88 tim=1619996238190 hv=3634861691 ad='355836ec' sqlid='3c3yp27cag5mv'
select * from t1 where c1 = 1
END OF STMT
EXEC #6:c=0,e=60,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1619996238186
WAIT #6: nam='SQL*Net message to client' ela= 6 driver id=1413697536 #bytes=1 p3=0 obj#=375 tim=1619996238266
FETCH #6:c=0,e=50,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=1,tim=1619996238382
WAIT #6: nam='SQL*Net message from client' ela= 258 driver id=1413697536 #bytes=1 p3=0 obj#=375 tim=1619996238690
FETCH #6:c=0,e=13,p=0,cr=1,cu=0,mis=0,r=0,dep=0,og=1,tim=1619996238739
STAT #6 id=1 cnt=1 pid=0 pos=1 obj=79656 op='TABLE ACCESS BY INDEX ROWID T1 (cr=4 pr=0 pw=0 time=0 us cost=2 size=7 card=1)'
STAT #6 id=2 cnt=1 pid=1 pos=1 obj=79657 op='INDEX RANGE SCAN T1_N1 (cr=3 pr=0 pw=0 time=0 us cost=1 size=0 card=1)'

まだこの機能が公式的に文書化されてはいないようです。従って本番環境で使用する前に十分な検証をしなければなりません。Oracle 11.1.0.6のテスト環境ではこの機能のせいでセッションが非正常終了する場合もたまにありました。

過去の統計情報を分析しましょう。

2010-02-03T23:25:00.000-08:00

Oracle 10g以降からは統計情報が更新されるたびに以前の統計情報をディクショナリーに貯蔵します。統計情報更新によって性能問題が発生した時、以前の統計情報で復元するための目的です。

でも過去の統計情報を問い合わせる簡単な方法はなさそうです。たぶんディクショナリーを直接クエリするのが雄一な方法みたいです。

SYS.WRI$_OPTSTAT_TAB_HISTORY: テーブル統計情報
SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY:列統計情報
SYS.WRI$_OPTSTAT_HISTGRM_HISTORY:ヒストグラム統計情報
SYS.WRI$_OPTSTAT_IND_HISTORY:索引統計情報

このテーブルたちを問い合わせて過去の特定の時点のテーブルの統計情報を確認する簡単なスクリプトを作ってみれば次のようです。

(簡単なサンプルに過ぎませんので、運営システムで使用しようとすれば補完が必要です)


--------------------------------------------------------------------------------
-- @name: tab_stat_hist
-- @author: dion cho
-- @note: show stats gathering history 
-- @usage: @tab_stat_hist   
--          @tab_stat_hist ukja t1 "2010/12/13 13:00:00"
--------------------------------------------------------------------------------

define __OWNER = &1;
define __TABLE_NAME = &2;
define __TIME = "&3";

col obj# new_value obj_id
col savtime new_value savtime

select * from 
  (select obj#, to_char(savtime, 'yyyy/mm/dd hh24:mi:ss') as savtime
    from sys.wri$_optstat_tab_history 
    where obj# = (select object_id from all_objects 
              where owner = upper('&__OWNER') 
                    and object_name = upper('&__TABLE_NAME')
                    and subobject_name is null)
          and savtime <= to_date('&__TIME', 'yyyy/mm/dd hh24:mi:ss')
    order by savtime desc)
where rownum = 1 
;

set serveroutput on

prompt 01. table stats
exec print_table('-
    select obj#, upper(''&__TABLE_NAME'') as table_name, -
      rowcnt, blkcnt, avgrln, samplesize, analyzetime, -
      to_char(savtime, ''yyyy/mm/dd hh24:mi:ss'') as savtime -
    from sys.wri$_optstat_tab_history -
    where obj# = &obj_id -
          and to_char(savtime, ''yyyy/mm/dd hh24:mi:ss'') = ''&savtime'' -
');

prompt 02. column stats
exec print_table(' -
select c.intcol#, c.name as column_name, null_cnt, minimum, maximum, -
      distcnt, density, avgcln -
from sys.wri$_optstat_histhead_history h, sys.col$ c -
where h.obj# = c.obj# -
      and h.obj# = &obj_id -
      and h.intcol# = c.intcol# -
      and to_char(h.savtime,''yyyy/mm/dd hh24:mi:ss'') = ''&savtime'' -
order by 1 asc -
');

col col_name format a10
col epvalue format a30
prompt 03. histogram
select
  c.name as col_name,
  h.bucket,
  h.endpoint,
  h.epvalue
from 
  sys.wri$_optstat_histgrm_history h, sys.col$ c
where
  h.obj# = &obj_id
  and h.obj# = c.obj#
  and h.intcol# = c.intcol#
  and to_char(h.savtime,'yyyy/mm/dd hh24:mi:ss') = '&savtime'
order by c.intcol#, h.bucket
;

過去の索引統計情報やパーティション統計情報なども同じ方法で得られます。

この方法を利用すれば統計情報更新の後、実行計画の変わった場合、統計情報の変化を追跡できます。以前のバージョンではできなっかた重要な改善だと言えます。とくにAWRのようなデータと連動してよく使えば有効な道具になるはずです。

クエリが現在実行段階のどこを実行しているのか分かる方法がないんでしょうか

2010-01-18T17:53:00.000-08:00

この前、社内のエンジニアたちと話し合ううちこんな疑問が提起が提起されました。

クエリが現在実行段階のどこを実行しているのか分かる方法がないんでしょうか。

SQL*Traceのような一般的な方法では不可能です。たぶん唯一な方法はオラクルが実行計画によってクエリを実行しながら呼び出す関数(Function)をトレースすることでしょう。オラクルが呼び出す関数をトレースする一番簡単な方法はoradebug short_stackコマンドです。

簡単な例を通じて見ましょう。まず次のように必要なオブジェクトを作ります。


create table t1 as
select level as c1, 'x' as c2
from dual
connect by level <= 1000;

create table t2 as
select level as c1, 'x' as c2
from dual
connect by level <= 1000;

create index t2_n1 on t2(c1);

create or replace function f_wait(p1 number, p2 number)
return number
is
begin
  dbms_lock.sleep(p2);
  return 1;
end;
/

次のようにNested Loops Joinを通じてデータをフェッチするクエリがあります。ただしf_wait(t1.c1, 0.01)を利用して実際のデータをフェッチする時遅延が起こるようにします。


explain plan for
select /*+ ordered use_nl(t2) */ t1.c1, t2.c2, f_wait(t1.c1, 0.01)
from t1, t2
where t1.c1 = t2.c1
;

---------------------------------------------
| Id  | Operation                   | Name  |
---------------------------------------------
|   0 | SELECT STATEMENT            |       |
|   1 |  TABLE ACCESS BY INDEX ROWID| T2    |
|   2 |   NESTED LOOPS              |       |
|   3 |    TABLE ACCESS FULL        | T1    |
|*  4 |    INDEX RANGE SCAN         | T2_N1 |
---------------------------------------------

クエリを実行する途中、実行計画のどんな段階にあるののかトレースしてみましょう。


UKJA@ukja1021> select /*+ ordered use_nl(t2) */ t1.c1, t2.c2, f_wait(t1.c1, 0.01)
  2  from t1, t2
  3  where t1.c1 = t2.c1
  4  ;

        C1 C F_WAIT(T1.C1,0.01)
---------- - ------------------
         1 x                  1
         2 x                  1
...

クエリの特性からたぶん現在テーブルT2からデータをフェッチする段階(id=1)にある確率が高いです。下にoradebug short_stackコマンドの結果があります。


SYS@ukja1021> oradebug short_stack
_ksdxfstk+14<-_ksdxcb+1481<-_ssthreadsrgruncallback+428<-_OracleOradebugThreadSt
art@4+795<-7C80B710<-00000000<-7C80253D<-_skgpwwait+124<-_ksliwat+843<-_kslwaitn
s+24<-_kskthbwt+159<-_kslwait+52<-_psdwat+155<-_pevm_icd_call_common+722<-_pfrin
str_ICAL+120<-_pfrrun_no_tool+56<-_pfrrun+781<-_plsql_run+738<-_peidxr_run+199<-
_peidxexe+52<-_kkxdexe+278<-_kkxmpexe+184<-_kgmexec+295<-_evapls+724<-_evaopn2+4
02<-_kpofcr+1593<-_qertbFetchByRowID+2083<-_rwsfcd+95<-_opifch2+3104<-_opifch+51
<-_opiodr+1099<-_ttcpip+1273<-_opitsk+1017<-_opiino+1087<-_opiodr+1099<-_opidrv+
819<-_sou2o+45<-_opimai_real+112<-_opimai+92<-_OracleThreadStart@4+708<-7C80B710

上のスタックトレース中実行計画と係りのあるのだけ引き出してみれば次のようです。最初の予想とぴったり合います。


opifch2 : Fetch. SELECTに該当
  qertbFetchByRowID : TABLE FETCH BY ROWIDに該当

もう少し正確な観察をために今度はWHERE句にf_wait(t2.c1, 0.01) = 1条件を与えてテーブルT2をアクセスする過程で遅延が起こるようにしてみます。実行計画上でみればIndex Range Scanに該当する４番の段階で遅延が発生することが確認できます。


explain plan for
select /*+ ordered use_nl(t2) */ t1.c1, t2.c2
from t1, t2
where t1.c1 = t2.c1 and f_wait(t2.c1, 0.01) = 1
;

---------------------------------------------
| Id  | Operation                   | Name  |
---------------------------------------------
|   0 | SELECT STATEMENT            |       |
|   1 |  TABLE ACCESS BY INDEX ROWID| T2    |
|   2 |   NESTED LOOPS              |       |
|   3 |    TABLE ACCESS FULL        | T1    |
|*  4 |    INDEX RANGE SCAN         | T2_N1 |
---------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   4 - access("T1"."C1"="T2"."C1")
       filter("F_WAIT"("T2"."C1",0.01)=1)

クエリを実行しながらoradebug short_stackコマンドでトレースします。


UKJA@ukja1021> select /*+ ordered use_nl(t2) */ t1.c1, t2.c2
  2  from t1, t2
  3  where t1.c1 = t2.c1 and f_wait(t2.c1, 0.01) = 1
  4  ;

        C1 C
---------- -
         1 x
         2 x
         3 x
...

結果は次のようです。


SYS@ukja1021> oradebug short_stack
_ksdxfstk+14<-_ksdxcb+1481<-_ssthreadsrgruncallback+428<-_OracleOradebugThreadSt
art@4+795<-7C80B710<-00000000<-7C80253D<-_skgpwwait+124<-_ksliwat+843<-_kslwaitn
s+24<-_kskthbwt+159<-_kslwait+52<-_psdwat+155<-_pevm_icd_call_common+722<-_pfrin
str_ICAL+120<-_pfrrun_no_tool+56<-_pfrrun+781<-_plsql_run+738<-_peidxr_run+199<-
_peidxexe+52<-_kkxdexe+278<-_kkxmpexe+184<-_kgmexec+295<-_evapls+724<-_evaopn2+4
02<-_evareo+110<-_expepr+73<-_expeal+17<-_qerixtFetch+3498<-_qerjoFetch+864<-_qe
rpfFetch+251<-_qertbFetchByRowID+475<-_rwsfcd+95<-_opifch2+3104<-_opifch+51<-_op
iodr+1099<-_ttcpip+1273<-_opitsk+1017<-_opiino+1087<-_opiodr+1099<-_opidrv+819<-
_sou2o+45<-_opimai_real+112<-_opimai+92<-_OracleThreadStart@4+708<-7C80B710

この中で実行計画と関係のある部分だけを引き出せば次のようです。


_opifch2 : Fetch. SELECT
  _qertbFetchByRowID : TABLE FETCH BY ROWID
     _qerpfFetch : Prefetch
        _qerjoFetch : NESTED LOOPS JOIN
           _qerixtFetch : INDEX RANGE SCAN

すなわち、現在４番の段階のIndex Range Scanを実行しているのが分かります。４番段階で遅延が発生するように操作したのがよく動作しました。

もっと長くて複雑なクエリも上と同じ方法でトレースが可能です。もちろん安くてはないんですけど…

クエリの実行時間が長すぎる場合やハング(Hang)が発生するときを想像しましょう。万一SQL*Traceや待機イベント分析のような一般的な方法ではもう以上のトレースが不可能だったら?上の方法はそんな場合使えるたぶん唯一な方法でしょう。

Process Explorer

2010-01-10T18:05:00.000-08:00

この前、Ask ExemにWindows用のオラクルのメモリモニタリングの問題に対する問い合わせがありました。

Oracleのメモリ使用量関連

(Ask Exemは韓国のExemが運営するQ&Aサイトです)

これはオラクルの問題というよりはOSの問題です。オラクルもOSが提供するメモリ管理記法をそのまま使用するアプリに過ぎませんからです。

Windows環境でプロセスをモニタリングする最善のツールははProcess Explorerです。Windowsを使用しながらこのツールを使用していないのは大きい損害だと言えます。

Process Explorerを通じてオラクルをモニタリングする簡単な画面を見てみましょう。

1. ハンドラーモニタリング - ユニックスのlsofコマンドに該当

2. スレッドモニタリング - オラクルのセッションに該当

3. CPU, Memoryなど核心性能指標 - ユニックスのps, topなどに該当

より幅広い性能指標を1つの画面で見ることもできます。

このような機能たちをよく活用すればユニックスに劣らなく精密なプロセスモニタリングが可能です。ただし、Windows用のオラクルはマルチプロセス環境ではなくてマルチスレッド環境ですのでもう少しややこしいといえます。

他のセッションのパラメータを制御しよう

2010-01-07T20:58:00.000-08:00

セッションモニタリングをしてみると次のような二つの要求事項ができるはずです。

特定のセッションが特定のパラメータ値を変更した場合(すなわち、システムディフォルト値と違う値を設定した場合)、これを確認できる？
特定のセッションの特定のパラメータ値を変えることができる？

まず特定のセッションのパラメータ値を確認できる一番確実な方法はoradebug dump errorstackコマンドです。


-- Session #1
UKJA@ukja1021> @me

SADDR           SID    SERIAL# PID        PADDR
-------- ---------- ---------- ---------- --------
34328D4C        140       5489 5924       3424C60C

UKJA@ukja1021> alter session set "_hash_join_enabled" = false;

Session altered.

-- Session #2
SYS@ukja1021> oradebug setospid 5924
Oracle pid: 15, Windows thread id: 5924, image: ORACLE.EXE (SHAD)
SYS@ukja1021> oradebug dump errorstack 3;
Statement processed.
SYS@ukja1021> oradebug tracefile_name
c:\oracle\admin\ukja1021\udump\ukja1021_ora_5924.trc

SYS@ukja1021> ed c:\oracle\admin\ukja1021\udump\ukja1021_ora_5924.trc

....
Dump event group for SESSION
Dump event group for SYSTEM
DYNAMICALLY MODIFIED PARAMETERS:
  _hash_join_enabled       = FALSE   <--- 注目!

Oracle10gからはV$SES_OPTIMIZER_ENVビューを通じて一部のパラメータ値を確認できるがオプティマイザに関したパラメータ値に限るという制約があります。

他のセッションのパラメータ値を変更するのはDBMS_SYSTEMパッケージを通じて可能です。


-- Session #2
SYS@ukja1021> exec dbms_system.set_bool_param_in_session(140,5489,'_hash_join_enabled', true);

PL/SQL procedure successfully completed.

-- Session #1
UKJA@ukja1021> @para hash_join_enabled
UKJA@ukja1021> set echo off
old   9: and i.ksppinm like '%&1%'
new   9: and i.ksppinm like '%hash_join_enabled%'

NAME                           VALUE                IS_DEFAUL SES_MODIFI
------------------------------ -------------------- --------- ----------
SYS_MODIFI
----------
DESCRIPTION
------------------------------------------------------------------------

_hash_join_enabled             TRUE                 TRUE      true
false
enable/disable hash join

DBMS_SYTEM.SET_BOOL_PARAM_IN_SESSIONプロシージャはBoolean(True/False)タイプのパラメータ値を、DBMS_SYSTEM.SET_INT_PARAM_IN_SESSIONプロシージャはIntegerタイプのパラメータ値を変更する機能を提供します。しかし、文字列タイプのパラメータ値を変更する機能は提供されません。たぶん、過去のバージョンでどんな理由のために提供しなかったが、その後機能の追加や変更がなかったと思われます。

OradebugやDBMS_SYSTEMのような文書化がなっていない機能を使用しなければならないのが負担になるかも知れません。こんな機能の使用でオラクルデータベースに問題ができたらサポートの領域を外れるようになると言うのも大きい負担です。でも、トラブルシューチングを少し深く入ってもすぐこんな隠し機能が必要になるのが現実でもあります。

AWRレポートを手軽に利用しよう。

2009-12-30T21:51:00.000-08:00

AWR(Automatic Workload Reposistory)はオラクルからのプレゼントです。もちろん、ただではないけどど…

私は特定な作業の性能特徴を分析する時、次のように手軽にAWRレポートを利用しています。


@snap_begin

alter session enable parallel dml;

insert /*+ append parallel(t1 4) trace */ into t1
select /*+ parallel(t2 4) */ * from t2;
commit;

@snap_end

@snap_report

-- AWR Report
WORKLOAD REPOSITORY report for

DB Name         DB Id    Instance     Inst Num Release     RAC Host
------------ ----------- ------------ -------- ----------- --- ------------
UKJA1021       738915393 ukja1021            1 10.2.0.1.0  NO  UKJAX

              Snap Id      Snap Time      Sessions Curs/Sess
            --------- ------------------- -------- ---------
Begin Snap:      1284 29-Dec-09 15:04:38        19       3.5
  End Snap:      1285 29-Dec-09 15:04:42        19       3.5
   Elapsed:                0.08 (mins)
   DB Time:                0.15 (mins)

Cache Sizes
~~~~~~~~~~~                       Begin        End
                             ---------- ----------
               Buffer Cache:       452M       452M  Std Block Size:         8K
           Shared Pool Size:       116M       116M      Log Buffer:     6,968K

Load Profile
~~~~~~~~~~~~                            Per Second       Per Transaction
                                   ---------------       ---------------
                  Redo size:          1,201,392.36          5,725,836.00
              Logical reads:              2,178.56             10,383.00
              Block changes:                298.99              1,425.00
             Physical reads:                 97.36                464.00
            Physical writes:                142.89                681.00
                 User calls:                 12.80                 61.00
                     Parses:                 26.44                126.00
                Hard parses:                  0.42                  2.00
                      Sorts:                  8.60                 41.00
                     Logons:                  1.68                  8.00
                   Executes:                 27.07                129.00
               Transactions:                  0.21
...


Event                                 Waits  -outs    Time (s)    (ms)      /txn
---------------------------- -------------- ------ ----------- ------- ---------
db file scattered read                   42     .0           2      55      42.0
log file parallel write                  27     .0           1      32      27.0
rdbms ipc reply                           8     .0           0      50       8.0
control file sequential read            674     .0           0       1     674.0
db file sequential read                  11     .0           0      27      11.0
...

snap_begin、snap_end、snap_reportスクリプトは下記のとおりです。簡単なSQL*Plusだけで手軽にAWRレポートを作れます。
1. snap_begin.sql


col begin_snap new_value begin_snap;
col db_id new_value db_id;
col inst_num new_value inst_num;

select dbid as db_id from v$database;
select instance_number as inst_num from v$instance;

select dbms_workload_repository.create_snapshot as begin_snap from dual;

2. snap_end.sql


col end_snap new_value end_snap;

select dbms_workload_repository.create_snapshot as end_snap from dual;

3. snap_report.sql


select * from table(
  dbms_workload_repository.awr_report_text(
          &db_id,
          &inst_num,
          &begin_snap,
          &end_snap)
  );

もう一度言いますが、AWRはオラクルからの大切なプレゼントです。たとえその値段は高いかも知れませんが、よく利用すればするほど支払いの甲斐があります。

オラクル性能に対する短い考え＃19

2009-12-24T06:28:00.000-08:00

オラクルの機能は長期間にかかって完成される。

例えば、

プランスタビリティーはOracle 8iのStored Outlineから始まったが、実際に使えるほどの水準はOracle 11gR2で達成された。
CBOはOracle 7で紹介されたが、公式的にRBOを完全に代替したのはOracle 10gからだ。
バインドピークはOracle 9iから提供されつつあるが、現実的に使用可能にたったのはOracle 11gからだ。

オラクルを理解するのには結構長い時間の観察が必要だと言えますね。

Oracle 11gR2のオプティマイザのCardinaliy Feedback

2009-12-19T02:43:00.000-08:00

Oracle 11gR2のランタイムーオプティマイザにCardinality Feedback機能が追加されたことを知るようになりました。

オラクルは10gから自動クエリチューニング(Automatic Query Tuning)という名前でCardinality Feedback機能を紹介しました。予想の行数(Estimated Cardinality)と実際の行数(Actual Cardinality)を比べてその差を減らす方式がCardinality Feedback機能の動作原理です。このためにOPT_ESTIMATEヒントが追加されました。しかし、これはあくまでもチューニングオプティマイザエンジンにすみました。

11gR2でこの機能はチューニングエンジンにやまずにランタイムーエンジンまで適用されました。詳しい内容は上のリンクこ参照すればいいでしょう。簡単に整理すると次のとおりです。

クエリを行ったあと予想行数件数と実際行数件数の違いが大きすぎると判断されると該当実行計画は共有物不可の状態になって実際の行数件数をカーソルに書き込みます。しかし予想行数件数と実際行数件数の違いだけが唯一なファクターなのかは確実ではなんです。
あとで同一なクエリがまた実行されると最初の実行で書き込んでおいた行数をOPT_ESTIMATEヒントを通じてクエリに挿入します。すなわちCardinality Feedbackが行われます。
この過程はたった一度のみ行われます。すなわち最初のクエリだけがフィードバックの対象となります。
_OPTIMIZER_USE_FEEDBACKパラメーターを利用して制御できます。すなわちこのパラメーターの値をFALSEに変更したらCardinality Feedbackは行われません。

私の個人的な意見を申し上げるとCardinality Feedbackがランタイムーエンジンまで適用されるはずだとはまったく期待しませんでした。でも結局そうなってしまいました。たぶん多くのシステムで熱いイシューになるはずです。

私のブログに雪が降っています。

2009-12-16T00:14:00.000-08:00

少しだけ(数秒ぐらい)待ってください。しんしんと雪が降っているんですよ。

次のようにJava Scriptをエンベッドしました。

この雪は一月上旬までだけ降ります。

書き出し一貫性 - Restartメカニズム

2009-12-14T22:28:00.000-08:00

先日、特定のDMLが多すぎるロジカルリードを持つ問題に対する問い合わせがありました。たとえその問題に対する原因ではありませんでしたけど、おかげで書き出し一貫性(Write Consistency)問題を一度話し合う必要性を感じました。

簡単なテストを通じて話し合ってみます。まず次のようにテーブルを一つ作ります。


UKJA@ukja1021> select * from v$version where rownum = 1;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod

UKJA@ukja1021> create table t1
  2  as
  3  select level as c1, rpad('x',1000) as c2
  4  from dual
  5  connect by level <= 10000
  6  ;

Table created.

テーブルT1に対してトリガーを作って行一件が変更されるたびにpkg_temp.g_update_cnt値を１づつ増加します。


UKJA@ukja1021> create or replace package pkg_temp
  2  is
  3   g_update_cnt number;
  4  end;
  5  /

Package created.

UKJA@ukja1021> -- create trigger
UKJA@ukja1021> create or replace trigger trg1
  2  after update on t1
  3  for each row
  4  begin
  5   pkg_temp.g_update_cnt := pkg_temp.g_update_cnt + 1;
  6  end;
  7  /

次のように10,000件を変更するとpkg_temp.g_update_cnt値は10,000になります。


UKJA@ukja1021> exec pkg_temp.g_update_cnt := 0;

PL/SQL procedure successfully completed.

UKJA@ukja1021> 
UKJA@ukja1021> update t1 set c2 = rpad('y',1000)
  2  where c1 = c1
  3  ;

10000 rows updated.

UKJA@ukja1021> commit;

Commit complete.

UKJA@ukja1021> 
UKJA@ukja1021> exec dbms_output.put_line('update cnt = ' || pkg_temp.g_update_cnt);
update cnt = 10000

PL/SQL procedure successfully completed.

今、次のようにテストを変更します。

セッションAで10,000件を変更します。
セッションAがまだ最後の行を変更する前にセッションBが最後の行の値を変えてコミットを行います。
セッションAが変更を終えたあとpkg_temp.g_update_cnt値を確認します。

セッションAが10,000件を変更始めます。


UKJA@ukja1021> exec pkg_temp.g_update_cnt := 0;

PL/SQL procedure successfully completed.

UKJA@ukja1021> 
UKJA@ukja1021> update t1 set c2 = rpad('y',1000)
  2  where c1 = c1
  3  ;
....

セッションAがまだ最後の行を変更する前にセッションBが最後の行の値を変えてコミットを行います。


UKJA@ukja1021> update t1 set c1 = c1+1 where c1 = 10000;

1 row updated.

UKJA@ukja1021> commit;

Commit complete.

セッションAが変更を終えた後pkg_temp.g_update_cnt値を確認します。驚いたことにpgk_temp.g_update_cntの値は19,999件です!


...
10000 rows updated.

UKJA@ukja1021> commit;

Commit complete.

UKJA@ukja1021> exec dbms_output.put_line('update cnt = ' || pkg_temp.g_update_cnt);
update cnt = 19999

PL/SQL procedure successfully completed.

これは10,000件ではなくてその二倍に該当する20,000件ぐらいが変更されたということを意味します。これをよくRestartメカニズムと呼びます。

セッションAが最後の行を変更するため一応Consistent Readモードで該当ブロックを読み込みます。
セッションAはクエリが始まった後該当行がセッションBに変更されてコミットされたのを確認します。
UPDATE文のwhere c1 = c1 条件で一貫性確認(Consistency Check)がなされます。セッションAは最後の行はUPDATEが始まった後で変更されたので該当条件を満足するかしないかを確認するのが不可能だと判断します。
こんな場合セッションAは今までの変更をロールバックし、UPDATE文を行い直します。これをRestartメカニズムと言います。したがって9,999＋10,000＝19,999件の行が変更されたことです。

Restartの副作用はSQL*Traceの結果でもよく現れます。Restartが発生した場合同じに10,000個の行を変更しますが、ずっと多い仕事をします。ロールバックをして行い直さなければならないからです。


-- Restartがなされない場合
update t1 set c2 = rpad('y',1000)
where c1 = c1

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.01       0.00          0          7          0           0
Execute      1      0.34       0.52          0       1443      12992       10000
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.35       0.53          0       1450      12992       10000

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 61  

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  UPDATE  T1 (cr=1487 pr=0 pw=0 time=530716 us)
  10000   TABLE ACCESS FULL T1 (cr=1432 pr=0 pw=0 time=74012 us)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  log buffer space                                5        0.01          0.05
  SQL*Net message to client                       1        0.00          0.00
  SQL*Net message from client                     1        0.00          0.00
********************************************************************************

-- Restartがなされる場合
update t1 set c2 = rpad('y',1000)
where c1 = c1

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      1.25       6.29          0       4323      67568       10000
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      1.25       6.29          0       4323      67568       10000

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 61  

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  UPDATE  T1 (cr=4411 pr=0 pw=0 time=5643605 us)
  30000   TABLE ACCESS FULL T1 (cr=4297 pr=0 pw=0 time=180259 us)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  log file switch completion                      4        0.99          2.28
  log file switch (checkpoint incomplete)         2        0.38          0.44
  log buffer space                               18        0.68          1.98
  enq: TX - row lock contention                   1        0.07          0.07
  SQL*Net message to client                       1        0.00          0.00
  SQL*Net message from client                     1        0.00          0.00
********************************************************************************

このようなRestartメカニズムはよくオラクルは読み取り一貫性(Read Consistency)のみならず書き出し一貫性(Write Consistency)を持っているとも言います。もっと正確に言えばオラクルの読み取り一貫性(Read Consistency)のメカニズムがDMLに掛ける特殊な影響だと言っても良いでしょう。

オラクル性能に対する短い考え＃18

2009-12-12T07:15:00.000-08:00

少数の視覚を持て

例えばこのようなものであります。

皆がSQLトレースに満足している時オラクル内部的な知識を活用して体系的な性能分析技法を研究したSteve Adamsさん。
皆がクエリをチューニングする方法について話をしている時オプティマィザの動作原理を元にした問題解決を話したJonathan Lewisさん。
皆がSQLトレースで満足している時ダイレクトメモリーアクセス方式でアクティブセッションをすべて収集して性能分析の新しい次元を提示したExemとMaxgauge。

私はこのごろすこしづつ自身が少数の視覚を備えて行っていると感じます。少数の視覚が成功的に大衆化すれば、すぐ多数の視覚になり、誰かがまた新しい少数の視覚を提示するはずです。こうだから知識の世界は面白いものです。

バインドピーキングとSQLトレースの出会い

2009-12-09T21:04:00.000-08:00

バインドピーキング(Bind Peeking)が起こす一番大きい混乱の一つはバインド変数を使用する同一なSQL文章の実行計画が変わるということです。その中面白い事例一つを簡単なテストを通じて紹介します。

次のようにオブジェクトを作ります。


UKJA@ukja1106> create table t1(c1 int, c2 varchar2(10));

Table created.

UKJA@ukja1106> insert into t1
  2  select 1, level from dual connect by level <= 10000;

10000 rows created.

UKJA@ukja1106> 
UKJA@ukja1106> insert into t1
  2  select level, level from dual connect by level <= 10000;

10000 rows created.

UKJA@ukja1106> 
UKJA@ukja1106> create index t1_n1 on t1(c1);

Index created.

UKJA@ukja1106> 
UKJA@ukja1106> exec dbms_stats.gather_table_stats(user, 't1', -
>   method_opt=>'for columns c1 size skewonly');

PL/SQL procedure successfully completed.

コラムC1はばらつきがあってヒストグラムが存在します。統計情報はつぎのようです。Height-Balancedヒストグラムが生成されているのが分かります。


UKJA@ukja1106> @tab_stat t1
UKJA@ukja1106> set echo off
01. table stats
old   9:  table_name = upper(''&T_NAME'')
new   9:  table_name = upper(''t1'')
TABLE_NAME                    : T1
PARTITION_NAME                :
NUM_ROWS                      : 20000
BLOCKS                        : 42
SAMPLE_SIZE                   : 20000
LAST_ANAL                     : 2009/12/07 13:41:08
-----------------

PL/SQL procedure successfully completed.

02. column stats
old   9:  s.table_name = upper(''&T_NAME'')
new   9:  s.table_name = upper(''t1'')
TABLE_NAME                    : T1
COLUMN_NAME                   : C1
NUM_DISTINCT                  : 10000
NUM_NULLS                     : 0
DENSITY                       : .00005
LOW_VALUE                     : C102
HIGH_VALUE                    : C302
HISTOGRAM                     : HEIGHT BALANCED
-----------------
TABLE_NAME                    : T1
COLUMN_NAME                   : C2
NUM_DISTINCT                  :
NUM_NULLS                     :
DENSITY                       :
LOW_VALUE                     :
HIGH_VALUE                    :
HISTOGRAM                     : NONE
-----------------

PL/SQL procedure successfully completed.

03. histogram stats
old   7:  table_name = upper('&T_NAME')
new   7:  table_name = upper('t1')

TABLE_NAME           COLUMN_NAME          ENDPOINT_NUMBER ENDPOINT_VALUE
-------------------- -------------------- --------------- --------------------
T1                   C1                               126 1()
T1                   C1                               127 33()
T1                   C1                               128 112()
...
T1                   C1                               254 10000()

129 rows selected.

コラムC1に”１”を代入したらバインドピーキングによって全表走査を選択するようになります。


UKJA@ukja1106> var b1 number;
UKJA@ukja1106> exec :b1 := 1;
UKJA@ukja1106> var b2 varchar2(10);
UKJA@ukja1106> exec :b2 := '1';

UKJA@ukja1106> 
UKJA@ukja1106> select /*+ gather_plan_statistics */
  2   count(*) from t1
  3  where c1 = :b1 and c2 = :b2;

  COUNT(*)
----------
         2

--------------------------------------------------------------
| Id  | Operation          | Name | Starts | E-Rows | A-Rows |
--------------------------------------------------------------
|   1 |  SORT AGGREGATE    |      |      1 |      1 |      1 |
|*  2 |   TABLE ACCESS FULL| T1   |      1 |     99 |      2 |
--------------------------------------------------------------

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

   2 - filter("C2"=:B2)
   3 - access("C1"=:B1)

今度はSQL*Traceを活性化します。そしてコラムC1に1ではなくて2を代入します。


UKJA@ukja1106> alter session set sql_trace = true;

Session altered.

UKJA@ukja1106> var b1 number;
UKJA@ukja1106> exec :b1 := 2;

PL/SQL procedure successfully completed.

UKJA@ukja1106> var b2 varchar2(10);
UKJA@ukja1106> exec :b2 := '1';

PL/SQL procedure successfully completed.

UKJA@ukja1106> 
UKJA@ukja1106> select /*+ gather_plan_statistics */
  2   count(*) from t1
  3  where c1 = :b1 and c2 = :b2;

  COUNT(*)
----------
         0

-------------------------------------------------------------------------
| Id  | Operation                    | Name  | Starts | E-Rows | A-Rows |
-------------------------------------------------------------------------
|   1 |  SORT AGGREGATE              |       |      1 |      1 |      1 |
|*  2 |   TABLE ACCESS BY INDEX ROWID| T1    |      1 |      1 |      0 |
|*  3 |    INDEX RANGE SCAN          | T1_N1 |      1 |      1 |      1 |
-------------------------------------------------------------------------

実行計画が変わりました。何かおかしいではありませんか。最初の実行でバインドピーキングがもうなされたので次の同一なテキストのクエリは同一な実行計画を見せなければなりません。

もっと詳細な分析をしてみましょう。まず現在登録されている息子LCOたちとその実行計画を見ます。


UKJA@ukja1106> select * from table(dbms_xplan.display_cursor('&sql_id', null, 'typical'));
old   1: select * from table(dbms_xplan.display_cursor('&sql_id', null, 'typical'))
new   1: select * from table(dbms_xplan.display_cursor('98721ruagfx5c', null, 'typical'))

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------
SQL_ID  98721ruagfx5c, child number 0
-------------------------------------
select /*+ gather_plan_statistics */  count(*) from t1 where c1 = :b1
and c2 = :b2

Plan hash value: 3724264953

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |       |       |    18 (100)|          |
|   1 |  SORT AGGREGATE    |      |     1 |     8 |            |          |
|*  2 |   TABLE ACCESS FULL| T1   |    99 |   792 |    18   (0)| 00:00:01 |
---------------------------------------------------------------------------

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

   2 - filter(("C2"=:B2 AND "C1"=:B1))

SQL_ID  98721ruagfx5c, child number 1
-------------------------------------
select /*+ gather_plan_statistics */  count(*) from t1 where c1 = :b1
and c2 = :b2

Plan hash value: 359681750

--------------------------------------------------------------------------------------
| Id  | Operation                    | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |       |       |       |     2 (100)|          |
|   1 |  SORT AGGREGATE              |       |     1 |     8 |            |          |
|*  2 |   TABLE ACCESS BY INDEX ROWID| T1    |     1 |     8 |     2   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN          | T1_N1 |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------

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

   2 - filter("C2"=:B2)
   3 - access("C1"=:B1)

確かに二つの実行計画が存在します。これが意味するのはSQLトレースが活性化されるとオラクルは同一なSQL文章だといっても他のSQL文で認識するということを意味します。その理由をV$SQL_SHARED_CURSORビューを通じて見つけられます。私が作成した簡単なスクリプトでV$SQL_SHARED_CURSORビューを検索します。


UKJA@ukja1106> @shared_cursor2 &sql_id
UKJA@ukja1106> set echo off
old  14:           and s.sql_id = ''&1''',
new  14:           and s.sql_id = ''98721ruagfx5c''',
SQL_TEXT                       = select /*+ gather_plan_statistics */  count(*) from t1 where c1 = :b1 and c2 = :b2
SQL_ID                         = 98721ruagfx5c
ADDRESS                        = 29D81B30
CHILD_ADDRESS                  = 2879E2BC
CHILD_NUMBER                   = 0
--------------------------------------------------
SQL_TEXT                       = select /*+ gather_plan_statistics */  count(*) from t1 where c1 = :b1 and c2 = :b2
SQL_ID                         = 98721ruagfx5c
ADDRESS                        = 29D81B30
CHILD_ADDRESS                  = 2F5E79DC
CHILD_NUMBER                   = 1
STATS_ROW_MISMATCH             = Y
--------------------------------------------------

すなわち、SQLトレースが活性化されるとSTATS_ROW_MISMATCHによってSQL文章を共有できずに新しいチャイルドカーソルを作るようになります。その過程で再びバインドピーキングがなされます。

SQLトレースの結果だけを見てせっかちにチューニングをするのはあぶないという恐れが生じませんか。

Oracle 11gの基準で同一なSQL文章が共有されないにはなんと60余種類の理由があります。


UKJA@ukja1106> desc v$sql_shared_cursor                       
           Name                                               
           ---------------------------------------------------
    1      SQL_ID                                             
    2      ADDRESS                                            
    3      CHILD_ADDRESS                                      
    4      CHILD_NUMBER                                       
    5      UNBOUND_CURSOR                                     
    6      SQL_TYPE_MISMATCH                                  
    7      OPTIMIZER_MISMATCH                                 
    8      OUTLINE_MISMATCH                                   
    9      STATS_ROW_MISMATCH                                 
   10      LITERAL_MISMATCH                                   
   11      FORCE_HARD_PARSE                                   
   12      EXPLAIN_PLAN_CURSOR                                
   13      BUFFERED_DML_MISMATCH                              
   14      PDML_ENV_MISMATCH                                  
   15      INST_DRTLD_MISMATCH                                
   16      SLAVE_QC_MISMATCH                                  
   17      TYPECHECK_MISMATCH                                 
   18      AUTH_CHECK_MISMATCH                                
   19      BIND_MISMATCH                                      
   20      DESCRIBE_MISMATCH                                  
   21      LANGUAGE_MISMATCH                                  
   22      TRANSLATION_MISMATCH                               
   23      ROW_LEVEL_SEC_MISMATCH                             
   24      INSUFF_PRIVS                                       
   25      INSUFF_PRIVS_REM                                   
   26      REMOTE_TRANS_MISMATCH                              
   27      LOGMINER_SESSION_MISMATCH                          
   28      INCOMP_LTRL_MISMATCH                               
   29      OVERLAP_TIME_MISMATCH                              
   30      EDITION_MISMATCH                                   
   31      MV_QUERY_GEN_MISMATCH                              
   32      USER_BIND_PEEK_MISMATCH                            
   33      TYPCHK_DEP_MISMATCH                                
   34      NO_TRIGGER_MISMATCH                                
   35      FLASHBACK_CURSOR                                   
   36      ANYDATA_TRANSFORMATION                             
   37      INCOMPLETE_CURSOR                                  
   38      TOP_LEVEL_RPI_CURSOR                               
   39      DIFFERENT_LONG_LENGTH                              
   40      LOGICAL_STANDBY_APPLY                              
   41      DIFF_CALL_DURN                                     
   42      BIND_UACS_DIFF                                     
   43      PLSQL_CMP_SWITCHS_DIFF                             
   44      CURSOR_PARTS_MISMATCH                              
   45      STB_OBJECT_MISMATCH                                
   46      CROSSEDITION_TRIGGER_MISMATCH                      
   47      PQ_SLAVE_MISMATCH                                  
   48      TOP_LEVEL_DDL_MISMATCH                             
   49      MULTI_PX_MISMATCH                                  
   50      BIND_PEEKED_PQ_MISMATCH                            
   51      MV_REWRITE_MISMATCH                                
   52      ROLL_INVALID_MISMATCH                              
   53      OPTIMIZER_MODE_MISMATCH                            
   54      PX_MISMATCH                                        
   55      MV_STALEOBJ_MISMATCH                               
   56      FLASHBACK_TABLE_MISMATCH                           
   57      LITREP_COMP_MISMATCH                               
   58      PLSQL_DEBUG                                        
   59      LOAD_OPTIMIZER_STATS                               
   60      ACL_MISMATCH                                       
   61      FLASHBACK_ARCHIVE_MISMATCH                         
   62      LOCK_USER_SCHEMA_FAILED                            
   63      REMOTE_MAPPING_MISMATCH                            
   64      LOAD_RUNTIME_HEAP_FAILED

こんなに多い理由が存在するので同一なSQL文章が複数の実行計画を見せる時必ずこのビューを検索しなければならないんでしょうね。

オラクル性能に対する短い考え＃17

2009-12-05T21:41:00.000-08:00

DaaSの時代が来る？

クラウドコンピューティング(Cloud Computing)という新しい流れとともにデータベースをサービスで提供する試しが本格化されています。

私はこれをDaas(Database As A Service. ダース)と呼びます。自分の勝手に作った言葉せす。

これはオラクルのような商用ライセンスでもないし、PostgreSQLのような無料ライセンスでもない第三のライセンスです。データをどのくらい使うかによってお金を支払うとても合理的なライセンス政策が現れるようになります。

DaaSが成功的に普遍化すると企業はメインテナンスの費用を大きく減らすことができるでしょう。中小規模の企業には魅力的に見えます。もちろん大型企業たちは保安と性能、安全性の問題でいぜんとして既存の方式を選り好みする可能性が高いです。

エンジニアの立場から見ると大変な危機で思われるかも知れません。その間データベースのインストール、パッチ、チューニングに必要だった人力が大きく減りかねません。

しかしデータベースへの接近費用が大きく減るによってデータベース使用の爆発的な増加を呼び起こすはずです。そこから新しい機会が開かれるかもしれません。

バグ5364143 - バインドピーク問題

2009-12-02T21:50:00.000-08:00

バインドピークが活性化されているにも関わらずバインドピークが実行されないバグ5364143があります。

クエリが最初にハードパースされる時はバインドピークが成功的に発生します。
以降該当クエリがフラッシュ、メモリPressure、DDLなどの理由でInvalidationされます。
次回に同一なクエリがまたハードパースされる時はバインドピークを修行しません。

ここで核心はクエリの情報全体が消えるのではなくて実行計画情報のみ消える場合です。SQL文章に当たるLCO(Library Cache Object)はヒープ0にメタ情報を、ヒープ6に実行計画情報を持っています。万一ヒープ6が消えて再びハードパースされる時はバインドピークが起こらない場合が時々発生すると言うのがこのバグが現れる方式です。

反面バインドピークを非活性化してもバインドピークが起こるバグもあります。

バインド変数を使用する同じSQL文章がたまに違う実行計画を作って困らせる場合が時々あったが、とてもその理由が分からない場合があります。こんなバグたちのためか疑われますね。

バージョン互換性を備えたスクリプト作り

2009-11-29T22:05:00.000-08:00

オラクルバージョンが多様になり、バージョンごと支援するオブジェクトが変わるによりバージョン互換性を持つスクリプトを作るのが少しづつ難しくなっていきます。(幸いに基本となるオブジェクトたちは大きな変化がないので問題が深刻ではないけれどね)

例えば、9i以下だったらV$SESSION_WAITビューから、10g以上だったらV$SESSIONビューから待機イベント情報を抽出するスクリプトが作りたいんです。PL/SQLを利用せずSQL*Plusで実行可能な一つのスクリプトファイルで作りたければどうしたらいいでしょうか。多い方法があるはずですが次のような簡単なトリックが使えます。


col is_10g new_value __is_10g
col is_9i new_value __is_9i

with v as (
 select 
  to_number(substr(banner, 
     instr(banner, 'Release ')+8,
     instr(banner, '.') - instr(banner, 'Release ')-8)) as version
 from v$version where rownum = 1
)
select
 case when version >= 10 then '' else '--' end as is_10g,
 case when version <= 9 then '' else '--' end as is_9i
from v
;

__is_19g、__is_9i置換変数を利用して次のように手軽に解決します。


select * from (
&__is_10g select event, p1, p2, p3 from v$session
&__is_9i select event, p1, p2, p3 from v$session_wait
)
;

応用したら次のようにバージョン別にコラムまで操作できます。


select 
 sid
 ,serial#
&__is_10g ,event
&__is_10g ,p1
from
 v$session
;

SQL*Plusの強力さが分かる良い例と言えます。

オラクルに対する短い考え #16

2009-11-26T21:35:00.000-08:00

オラクルは長い間ほとんど変わらなかった

オラクル性能トラブルシューチングが難しいながらも易しい理由があります。オラクルがエンタープライズの姿を備えたのがバージョン6(1988年)からと言われます。Undoに基づいた細かい行レベルロックとPL/SQLを支援し始めたのがこの時からです。

なんと20年の間オラクルの核心エンジンはほとんど変化なしに維持されて来ています。Redo、Undo、行レベルロック、Enqueue、Latch、Shared Pool、Cache Bufferなど性能を支配するすべての要素が大きい変化なしに(しかし少しづつ改善されながら)その様子をそのまま持っています。

そのおかげで核心概念に対する理解が優れたら少ない努力だけで専門家的な水準を維持できます。しかし逆さまに言うと核心的な概念に対する理解が十分ではなければ何か勉強し続けてもいつも2%不足な状態になります。

Oracle 11gR2의 Zero-Size Unusable Indexとテーブル拡張(Table Expansion)

2009-11-25T20:54:00.000-08:00

Christian AntogniniがここからOracle 11gR2の新機能の一つのZero-size Unusable Indexに対する簡単な紹介とオプティマィザに及ぶ影響について説明しています。

Zero-Sized Unusable Indexというのは使用不可インデックスまたはインデックスパーティションのセグメント空間を物理的に解除することを意味しています。次に簡単な例があります。

バージョンはOracle 11gR2です。


UKJA@UKJA1120> select * from v$version where rownum <= 1;
BANNER
----------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

パーティションテーブルを作ってからローカルインデックスを作ります。


UKJA@UKJA1120> create table t1(c1 int, c2 int)
  2  partition by range(c1) (
  3        partition p1 values less than (10000),
  4        partition p2 values less than (20000),
  5        partition p3 values less than (30000),
  6        partition p4 values less than (maxvalue)
  7  );

Table created.

UKJA@UKJA1120> insert into t1 select level, level from dual connect by level <= 30000;

30000 rows created.

Elapsed: 00:00:00.14
UKJA@UKJA1120> 
UKJA@UKJA1120> create index t1_n1 on t1(c1) local;

Index created.

Elapsed: 00:00:00.17
UKJA@UKJA1120> 
UKJA@UKJA1120> @gather t1
UKJA@UKJA1120> exec dbms_stats.gather_table_stats(user, '&1', no_invalidate=>false);

最後のパーティションP4を除いて残りの三つのパーティションを使用不可の状態に変えます。


UKJA@UKJA1120> 
UKJA@UKJA1120> alter index t1_n1 modify partition p1 unusable;

UKJA@UKJA1120> alter index t1_n1 modify partition p2 unusable;

UKJA@UKJA1120> alter index t1_n1 modify partition p3 unusable;

USER_SEGMENTSビューを問い合わせてみると使用不可状態のインデックスパーティション自体が存在しないのが分かります。空間節約次元で望ましい動作方式と言えます。


UKJA@UKJA1120> select partition_name, bytes
  2  from user_segments where segment_name = 'T1_N1';

PARTITION_NAME            BYTES
-------------------- ----------
P4                     10485760

ここからもう一つの魔法のようなものが発生します。つぎのようにパーティションP3とP4をかかる条件節を持ったクエリを実行します。万一Oracle 10gだったら全表走査を選択するしかないでしょう。でもOracle 11gR2では次のようにUNION ALLに変化された完璧な実行計画が生成されます。


UKJA@UKJA1120> explain plan for
  2  select count(*) from t1
  3  where c1 between 29999 and 30001;

-------------------------------------------------------------
| Id  | Operation                 | Name    | Pstart| Pstop |
-------------------------------------------------------------
|   0 | SELECT STATEMENT          |         |       |       |
|   1 |  SORT AGGREGATE           |         |       |       |
|   2 |   VIEW                    | VW_TE_2 |       |       |
|   3 |    UNION-ALL              |         |       |       |
|   4 |     PARTITION RANGE SINGLE|         |     4 |     4 |
|   5 |      INDEX RANGE SCAN     | T1_N1   |     4 |     4 |
|   6 |     PARTITION RANGE SINGLE|         |     3 |     3 |
|   7 |      TABLE ACCESS FULL    | T1      |     3 |     3 |
-------------------------------------------------------------

インデックスが正常的に存在するパーティションP4に対しては索引走査を、インデックスが存在しないパーティションP3に対しては全表走査を修行します。こんな動作方式はパーティション数に関わらず良く修行されます。


UKJA@UKJA1120> alter index t1_n1 rebuild partition p2;

UKJA@UKJA1120> explain plan for
  2  select count(*) from t1
  3  where c1 between 19999 and 30001;

--------------------------------------------------------------
| Id  | Operation                  | Name    | Pstart| Pstop |
--------------------------------------------------------------
|   0 | SELECT STATEMENT           |         |       |       |
|   1 |  SORT AGGREGATE            |         |       |       |
|   2 |   VIEW                     | VW_TE_2 |       |       |
|   3 |    UNION-ALL               |         |       |       |
|   4 |     CONCATENATION          |         |       |       |
|   5 |      PARTITION RANGE SINGLE|         |     4 |     4 |
|   6 |       INDEX RANGE SCAN     | T1_N1   |     4 |     4 |
|   7 |      PARTITION RANGE SINGLE|         |     2 |     2 |
|   8 |       INDEX RANGE SCAN     | T1_N1   |     2 |     2 |
|   9 |     PARTITION RANGE SINGLE |         |     3 |     3 |
|  10 |      TABLE ACCESS FULL     | T1      |     3 |     3 |
--------------------------------------------------------------

この動作方式を見てこの一語を浮かべたらオプティマィザの動作方式についてある程度理解していると言えます。"Transformation!"

これを確認するため10053トレースを修行してみます。その結果です。


TE: Checking validity of table expansion for query block SEL$1 (#0)

***********************************
Cost-Based Table Expansion
***********************************
TE: Checking validity of TE for query block SEL$1 (#1)
TE: Checking validity of table expansion for query block SEL$1 (#1)

TE: after table expansion:******* UNPARSED QUERY IS *******
SELECT COUNT(*) "COUNT(*)" FROM  
(
 (SELECT 0 FROM "UKJA"."T1" "T1" 
  WHERE TBL$OR$IDX$PART$NUM("UKJA"."T1",0,0,65535,"T1".ROWID)>=4 AND 
  TBL$OR$IDX$PART$NUM("UKJA"."T1",0,0,65535,"T1".ROWID)<=4 
  AND "T1"."C1"<= 30001 AND NULL IS NULL 
  AND ("T1"."C1">=30000 OR NULL IS NOT NULL)) 
 UNION ALL  
 (SELECT 0 FROM "UKJA"."T1" "T1" 
  WHERE TBL$OR$IDX$PART$NUM("UKJA"."T1",0,0,65535,"T1".ROWID)>=3 
  AND TBL$OR$IDX$PART$NUM("UKJA"."T1",0,0,65535,"T1".ROWID)<=3 
  AND "T1"."C1">= 29999 AND "T1"."C1"<30000)) 
"VW_TE_1"

テーブル拡張(Table Expansion)という技法を通じて数個のパーティションをかかる条件節がUNION ALLに変形されたのが分かります。Oracle 11gR2で新しく追加されたこの技法は_OPTIMIZER_TABLE_EXPANSIONパラメターで制御されます。


UKJA@UKJA1120> alter session set "_optimizer_table_expansion" = false;

UKJA@UKJA1120> explain plan for
  2  select count(*) from t1
  3  where c1 between 19999 and 30001;

----------------------------------------------------------
| Id  | Operation                 | Name | Pstart| Pstop |
----------------------------------------------------------
|   0 | SELECT STATEMENT          |      |       |       |
|   1 |  SORT AGGREGATE           |      |       |       |
|   2 |   PARTITION RANGE ITERATOR|      |     2 |     4 |
|   3 |    TABLE ACCESS FULL      | T1   |     2 |     4 |
----------------------------------------------------------

もう一つの注意するところはテーブル拡張(Table Expansion)もコストベースで定義されていることです。万一費用計算で不利な値が出たら上の例でも全表走査を選択されたかも知れません。

Oracle 11gR2にまたどんな隠れた改善点が見つかるか楽しみですね。

オラクル性能に対する短い考え＃15

2009-11-22T22:47:00.000-08:00

tahiti.oracle.comを使用しましょう。

オラクルが提供する命令文やPL/SQLパッケージの情報を探すとき一番先に行ってみるべき所は？

答えはGoogleではなくてTahitiです。Tahitiの存在を数人に聞いてみましたが知らない人が意外に多いんでした。習慣的にGoogleを検索する前に必ずしもここを尋ねてみましょう。マニュアルも読んでみなかったと怒られたくなければ。

なおSQL Referenceを読む方法も身につけましょう。SQL Referenceは次のような形式で文脈(Syntax)を説明しています。

上の形式がまだ慣れていなかったら練習がもっと必要です。最小限オラクルマニュアルほどはどんな問題もなしに読めるべきです。

統計情報がない時CBOは何をするだろうか。

2009-11-21T03:15:00.000-08:00

この前統計情報がない場合オプティマィザが費用(Cost)をどのように計算するかに対する問い合わせがありました。基本的な方法は次のようです。

動的サンプリング(Dynamic Sampling)が利用できればサンプリングにより統計情報を作った後で費用を計算する。
動的サンプリングが利用できなければ内部的に決められている基本値を使用する。

ここで内部的に決められている基本値ということの意味が気になります。幸いにオラクルマニュアルとWolfgang Breitlingが作成した有名な白書によく説明してあります。

簡単なテストを通じて整理してみます。

まず次のようにテーブルを作ります。


UKJA@ukja1021> -- case1
UKJA@ukja1021> create table t1
  2  as
  3  select level as c1, 'x' as c2
  4  from dual
  5  connect by level <= 10000;

Table created.

Elapsed: 00:00:00.04
UKJA@ukja1021> 
UKJA@ukja1021> create index t1_n1 on t1(c1);

Index created.

Elapsed: 00:00:00.03

動的サンプリングを動作しないようにする上、OPTIMIZER_MODE値をALL_ROWSにするによってオプティマィザが内部的な基本値を使用するようにします。


UKJA@ukja1021> alter session set optimizer_dynamic_sampling = 1;

Session altered.

Elapsed: 00:00:00.00
UKJA@ukja1021> alter session set optimizer_mode = all_rows;

Session altered.

実行計画を見ましょうか。たとえ統計情報はないんですけど、予測行件数が31で結構もっともらしく予測しました。


UKJA@ukja1021> explain plan for
  2  select * from t1
  3  where c1 = 1;

Explained.

-------------------------------------------------------------------------------------
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |       |    31 |   496 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T1    |    31 |   496 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | T1_N1 |    12 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

31の予測行件数がどこから来たのかは10053トレースファイルによく書き込んであります。


***************************************
BASE STATISTICAL INFORMATION
***********************
Table Stats::
  Table: T1  Alias: T1  (NOT ANALYZED)
    #Rows: 3104  #Blks:  38  AvgRowLen:  100.00
Index Stats::
  Index: T1_N1  Col#: 1
    LVLS: 1  #LB: 21  #DK: 10000  LB/K: 1.00  DB/K: 1.00  CLUF: 16.00
***************************************
SINGLE TABLE ACCESS PATH
  Column (#1): C1(NUMBER)  NO STATISTICS (using defaults)
    AvgLen: 22.00 NDV: 97 Nulls: 0 Density: 0.010309
  Table: T1  Alias: T1     
    Card: Original: 3104  Rounded: 31  Computed: 31.04  Non Adjusted: 31.04
  Access Path: TableScan
    Cost:  10.15  Resp: 10.15  Degree: 0
      Cost_io: 10.00  Cost_cpu: 892035
      Resp_io: 10.00  Resp_cpu: 892035
  Access Path: index (AllEqGuess)
    Index: T1_N1
    resc_io: 2.00  resc_cpu: 29893
    ix_sel: 0.004  ix_sel_with_filters: 0.004
    Cost: 2.01  Resp: 2.01  Degree: 1
  Best:: AccessPath: IndexRange  Index: T1_N1
         Cost: 2.01  Degree: 1  Resp: 2.01  Card: 31.04  Bytes: 0

上の内容を分析してみると次のようです。

テーブルのブロック数は33である。
したがってテーブルの基本Cardinality = 38*(8192 - 24)/100 = 3103.84 = 3104になった。
したがって列C1のDensityは1 / ( 3103.84 / 32 ) = 0.01030981 = 0.010309である。
したがってWHERE C1 = 1に該当する予測行件数は3104 * 0.010309 = 31になる。

すなわち、テーブルブロック数だけ手に入ればその後は上で言った二つの文書で説明された内部的な公式によって自然に計算されます。ここで問題はテーブルのブロック数をどう手に入れるのです。オラクルマニュアルによると次のように得られます。

セグメントに存在するExtent Mapからブロック数を手に入れる。
万一上の方法が不可能だったら(たとえばTable Functionを使ったりExternal Tableを使用したばあい)100だと仮定する。

上の説明が正しいかExtent Mapを実際に確認してみます。セグメントヘッダーブロックを見ると次のようにExtent Mapが存在します。


UKJA@ukja1021> col header_file new_value header_file
UKJA@ukja1021> col header_block new_value header_block
UKJA@ukja1021> select header_file, header_block
  2  from dba_segments where owner = user and segment_name = 'T1';

HEADER_FILE HEADER_BLOCK
----------- ------------
          7        40990

Elapsed: 00:00:00.03

UKJA@ukja1021> alter system dump datafile &header_file block &header_block;

...
  Extent Map
  -----------------------------------------------------------------
   0x01c0a009  length: 1280  

UKJA@ukja1021> select to_dec('01c0a009') from dual;

TO_DEC('01C0A009')
------------------
          29401097

Extent Mapによると一つのExtentが存在するし現在0番から37番、すなわち38個のブロックが実際に使用されているのが分かります。したがってオプティマィザは38個のブロックが存在すると認識しているのです。


-- dump_dba.sql : http://sites.google.com/site/ukja/sql-scripts-1/c/dump-dba
UKJA@ukja1021> @dump_dba 29401097
...
Dump of First Level Bitmap Block

  --------------------------------------------------------
  DBA Ranges :
  --------------------------------------------------------
   0x01c0a009  Length: 64     Offset: 0      
  
   0:Metadata   1:Metadata   2:Metadata   3:Metadata
   4:Metadata   5:Metadata   6:Metadata   7:Metadata
   8:Metadata   9:Metadata   10:Metadata   11:Metadata
   12:Metadata   13:Metadata   14:Metadata   15:Metadata
   16:Metadata   17:Metadata   18:Metadata   19:Metadata
   20:Metadata   21:Metadata   22:FULL   23:FULL
   24:FULL   25:FULL   26:FULL   27:FULL
   28:FULL   29:FULL   30:FULL   31:FULL
   32:FULL   33:FULL   34:FULL   35:FULL
   36:FULL   37:FULL   38:unformatted   39:unformatted
   40:unformatted   41:unformatted   42:unformatted   43:unformatted
   44:unformatted   45:unformatted   46:unformatted   47:unformatted
   48:unformatted   49:unformatted   50:unformatted   51:unformatted
   52:unformatted   53:unformatted   54:unformatted   55:unformatted
   56:unformatted   57:unformatted   58:unformatted   59:unformatted
   60:unformatted   61:unformatted   62:unformatted   63:unformatted
  --------------------------------------------------------

この情報はdbms_space.unused_spaceプロシージャを通じて手に入れた値を一致します。したがってExtent Mapを通じてテーブルのブロック数を手に入れるというマニュアルの内容が事実であることが分かります。


UKJA@ukja1021> exec show_space('T1');
Free Blocks.............................
Total Blocks............................1280
Total Bytes.............................10485760
Total MBytes............................10
Unused Blocks...........................1242
Unused Bytes............................10174464
Last Used Ext FileId....................9
Last Used Ext BlockId...................52489
Last Used Block.........................38

一つ面白いことはテーブルのブロック数を物理的に得るのでとても正確だということです。このために統計情報が全然無い状態で(そして動的サンプリングが動作しないことにもかかわらず)CBO(RBOではなくて)が作った実行計画が以外に立派なのでびっくりする場合があります。生半な統計情報よりは統計情報が初めからないほうが良い場合がたくさんあります。

オラクル性能に対する短い考え＃14

2009-11-17T23:41:00.000-08:00

初期化パラメータのデフォルト値一つ一つには哲学が入っている。

オラクルほど初期化パラメータ(Initialization Parameter)を利用して多様な制御が可能なスフトも少ないんです。特に隠しパラメータと呼ばれるものたちは本当に細かいものまで制御できるようになっています。初めてはこんな多きパラメータたちが不慣れで面倒くさく感じられるかも知れませんが、オラクルを使用する時間が増えるほどありがたく感じるようになります。それだけ自由を許すと言う意味だからです。

ここのパラメータは固有の目的を持っています。多くのパラメータがデフォルト値(Default Value)を持っています。デフォルト値は当然にそのパラメータの固有の目的を一番よく果たすように設定されます。あるパラメータはデフォルト値が間違い設定されて私たちを困らせるようにします。オラクル開発チームが現実を誤解したはずです。デフォルト値が意味することを正確に理解したらそれだけオラクルの性能に対する理解が深まります。

例をあげてみましょうか。

なぜOPTIMIZER_MODEのデフォルト値はALL_ROWSなのか。
なぜ_OPTIM_PEEK_USER_BINDSのデフォルト値はTRUEなのか。
なぜOPTIMIZER_DYNAMIC_SAMPLINGのデフォルト値は2なのか。
なぜDB_BLOCK_SIZEは8KBなのか。

並列実行とV$PQ_TQSTATビュー

2009-11-16T20:39:00.000-08:00

並列実行(Parallel Execution)をきちんと解析するには必ずといっても良いだけV$PQ_TQSTATビューを確認すべき場合があります。一度もこのビューを使用したことがなかったら次の例を見てびっくりするはずです。

オラクルバージョンは次のようです。


UKJA@ukja1021> select * from v$version where rownum = 1
  2  ;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod

テーブルを作ります。C1列について自然に整列になっている形態です。


UKJA@ukja1021> create table t1
  2  as select level as c1
  3  from dual
  4  connect by level <= 100000
  5  -- order by dbms_random.random
  6  -- how the table is ordered may affect the result
  7  ;

Table created.

テーブルの全ての行をフェッチするもっとも単純な形態の並列実行です。


UKJA@ukja1021> begin
  2    for c in ( select /*+ parallel(t1,4)*/ * from t1) loop
  3      null;
  4    end loop;
  5  end;
  6  /

PL/SQL procedure successfully completed.

その結果をV$PQ_TQSTATビューを通じて観察してみます。


ed pq_stat.sql

col process format a10
col server_type format a10
select dfo_number, tq_id, server_type,  process, 
  num_rows, bytes, avg_latency, waits, timeouts
from v$pq_tqstat
order by 1, 2, 3, 4, 5
;

その結果は次のようです。


UKJA@ukja1021> @pq_stat

DFO_NUMBER      TQ_ID SERVER_TYP PROCESS      NUM_ROWS      BYTES AVG_LATENCY
---------- ---------- ---------- ---------- ---------- ---------- -----------
     WAITS   TIMEOUTS
---------- ----------
         1          0 Consumer   QC             100000     595112           0
       223         64

         1          0 Producer   P000             5913      33710           0
         3          0

         1          0 Producer   P001            40870     243406           0
        21          0

         1          0 Producer   P002             7884      45733           0
         4          0

         1          0 Producer   P003            45333     272263           0
        23          0


Elapsed: 00:00:00.01

四つのスレーブプロセスがテーブルからデータを読み込む生産者(Producer)で動作しました。驚いたことにP001、P003二つのプロセスが大部分のデータを読み込み、残りの二つは一部のデータだけを読み込みました。スレーブプロセスの間にデータを公平に読み込んでいないと言えます。こんな現状ができたら並列実行の性能が考えより高くない結果になってしまいます。

ORDER BY句を利用して整列を修行したらもっと深刻な結果が出ます。


UKJA@ukja1021> begin
  2    for c in ( select /*+ parallel(t1,4)*/ * from t1 order by c1) loop
  3      exit;
  4    end loop;
  5  end;
  6  /

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.07
UKJA@ukja1021> 
UKJA@ukja1021> @pq_stat

DFO_NUMBER      TQ_ID SERVER_TYP PROCESS      NUM_ROWS      BYTES AVG_LATENCY
---------- ---------- ---------- ---------- ---------- ---------- -----------
     WAITS   TIMEOUTS
---------- ----------
         1          0 Consumer   P000             1972       9925           0
         9          2

         1          0 Consumer   P001             1971      10018           0
         9          3

         1          0 Consumer   P002             1971      10018           0
         8          2

         1          0 Consumer   P003            94086     565403           0
       116         47

         1          0 Producer   P004            31015     183753           0
        24          3

         1          0 Producer   P005            21681     129330           0
        17          4

         1          0 Producer   P006            27594     165130           0
        22          5

         1          0 Producer   P007            19710     117279           0
        14          2

         1          0 Ranger     QC                372       3789           0
         3          1

         1          1 Consumer   QC                100       1927           0
        67         23

         1          1 Producer   P000             1166       5782           0
        14          3

         1          1 Producer   P001             1146       5780           0
        14          3

         1          1 Producer   P002             1146       5781           0
        13          2

         1          1 Producer   P003             1146       5781           0
       122         48

14 rows selected.

四つのプロセス(P004 ~ P007)が生産者(Producer)でテーブルからデータを読み込むし四つのプロセス(P000 ~ P003)が消費者(Consumer)で整列を行いますが、その分布がたいへん良くないです。四つ目のプロセスであるP003が大部分の作業(94%、10,000件中94,086件)を行うのが分かります。このままなら並列実行のメリットはほとんどないと言えます。

こんな現状は索引を生成する時も同じです。索引の生成は内部的に整列作業を行います。次にその結果があります。


UKJA@ukja1021> create index t1_n1 on t1(c1) parallel 4;

Index created.

UKJA@ukja1021> @pq_stat

DFO_NUMBER      TQ_ID SERVER_TYP PROCESS      NUM_ROWS      BYTES AVG_LATENCY
---------- ---------- ---------- ---------- ---------- ---------- -----------
     WAITS   TIMEOUTS
---------- ----------
         1          0 Consumer   P000           100000    1807692           0
         4          1

         1          0 Consumer   P001                0         80           0
         4          1

         1          0 Consumer   P002                0         80           0
         4          1

         1          0 Consumer   P003                0         80           0
         4          1

         1          0 Producer   P004            11826     212999           0
         8          1

         1          0 Producer   P005            38899     705092           0
        26          4

         1          0 Producer   P006            11826     213097           0
         7          0

         1          0 Producer   P007            37449     676904           0
        29          6

         1          0 Ranger     QC                  0        160           0
         5          1

         1          1 Consumer   QC                  4       1272           0
         4          1

         1          1 Producer   P000                1        318           0
         0          0

         1          1 Producer   P001                1        318           0
         0          0

         1          1 Producer   P002                1        318           0
         0          0

         1          1 Producer   P003                1        318           0
         0          0


14 rows selected.

今度はP000プロセスが全ての整列作業を行いました。並列作業のメリットはないと言えます。

こんな現状はデータの整列程度とも関連があるようです。次のようにテーブルにランダムでデータが入るように変えてみます。


UKJA@ukja1021> create table t1
  2  as select level as c1
  3  from dual
  4  connect by level <= 100000
  5  order by dbms_random.random  -- !!
  6  -- how the table is ordered may affect the result
  7  ;

Table created.

この場合には四つのスレーブプロセスがほとんど公平に４等分して整列作業を行います。最高の理想的な場合だと言えます。


UKJA@ukja1021> begin
  2    for c in ( select /*+ parallel(t1,4)*/ * from t1 order by c1) loop
  3      exit;
  4    end loop;
  5  end;
  6  /

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.06
UKJA@ukja1021> 
UKJA@ukja1021> @pq_stat

DFO_NUMBER      TQ_ID SERVER_TYP PROCESS      NUM_ROWS      BYTES AVG_LATENCY
---------- ---------- ---------- ---------- ---------- ---------- -----------
     WAITS   TIMEOUTS
---------- ----------
         1          0 Consumer   P000            23570     132528           0
        39         13

         1          0 Consumer   P001            27176     164544           0
        65         16

         1          0 Consumer   P002            27655     167454           0
        50         18

         1          0 Consumer   P003            21599     130778           0
        60         14

         1          0 Producer   P004            17739     105608           0
        15          4

         1          0 Producer   P005            29044     173021           0
        30         10

         1          0 Producer   P006            21681     129097           0
        20          4

         1          0 Producer   P007            31536     187718           0
        23          5

         1          0 Ranger     QC                372       4546           0
         1          0

         1          1 Consumer   QC                100       1927           0
        67         24

         1          1 Producer   P000             1166       5782           0
        44         14

         1          1 Producer   P001              955       5782           0
        70         17

         1          1 Producer   P002              955       5780           0
        56         20

         1          1 Producer   P003              954       5777           0
        66         16


14 rows selected.

하지만 인덱스를 생성할 경우에는 여전히 같은 문제가 발생합니다.


UKJA@ukja1021> create index t1_n1 on t1(c1) parallel 4;

Index created.

Elapsed: 00:00:00.54
UKJA@ukja1021> 
UKJA@ukja1021> @pq_stat

DFO_NUMBER      TQ_ID SERVER_TYP PROCESS      NUM_ROWS      BYTES AVG_LATENCY
---------- ---------- ---------- ---------- ---------- ---------- -----------
     WAITS   TIMEOUTS
---------- ----------
         1          0 Consumer   P000           100000    1807712           0
         4          1

         1          0 Consumer   P001                0         80           0
         4          1

         1          0 Consumer   P002                0         80           0
         4          1

         1          0 Consumer   P003                0         80           0
         4          1

         1          0 Producer   P004            15768     285122           0
        10          0

         1          0 Producer   P005            32986     596372           0
        25          0

         1          0 Producer   P006            17739     320856           0
        12          1

         1          0 Producer   P007            33507     605762           0
        22          1

         1          0 Ranger     QC                  0        160           0
         1          0

         1          1 Consumer   QC                  4       1272           0
         3          1

         1          1 Producer   P000                1        318           0
         0          0

         1          1 Producer   P001                1        318           0
         0          0

         1          1 Producer   P002                1        318           0
         0          0

         1          1 Producer   P003                1        318           0
         0          0

14 rows selected.

上記の現状を見ると整列作業を並列に修行するコードの一部分にロジックの誤りがあると考えられます。V$PQ_TQSTATビューではなければこんな現状を観察するのは易しくないです。機会がある時ぜひ活用してみるのをお勧めします。

この現状に対するもっとも詳しい説明は次のURLを参照してください。

Oracle Parallel Query Sorting and Index Creation Performance Problems

My Oracle Support(MOS. 旧Metalink)はなおHTMLを支援します。

2009-11-15T17:28:00.000-08:00

何時ぞやメタリンクの次世代バージョンのMy Oracle Support(MOS)がオープンされました。その過程でログイン失敗、性能劣化などの問題かできましたが、その中でもフラッシュに対する不満が高いでした。

幸いにフラッシュではなくてHTMLで組み合わされたMy Oracle Supportがなお支援されています。次のURLを利用してみてください。

HTMLバージョンのMy Oracle Support

私もここを主に利用するつもりです。

オラクル性能に対する短い考え＃13

2009-11-14T06:59:00.000-08:00

プログラミング実力はオラクル性能専門家になるのに一番大きい役にたつ

性能問題に対してある程度知識を積んでいってみると必ずしも大きい壁に会うようになります。その壁の名前は経験です。自分の経験が一番大きい限界になります。多くのエンジニアたちが一定水準を外れられない決定的な理由中の一つです。

自分の経験だけでは解決できない問題に会ったら創造的な方式で状況を解き明かすべきです。優れたプログラミング能力はこんな時に大きい役に立ちます。万一プログラミングが苦手だとしたら問題を解決する速度は遅くなるし正確度も低くなるものです。

すなわち、初対面の問題を速い速度で解決する最高の道具はプログラミング能力です。単純にプログラミング言語が分かるのかを言うわけではなくてそれを通じて問題を解き明かす能力を言っているのです。

いつかあなたが今解き明かしたこの問題が全世界で自分が最初に解決した問題となる瞬間が来るはずです。オラクル性能専門家の世界へいらっしゃったのを歓迎いたします!

Physical Reads、Logical Readsを追い掛けよう。

2009-11-12T20:53:00.000-08:00

安そうに見えるが、難しい問題が多いです。次の例もその代表的な場合です。

まず次のように空いたテーブルを一つ作ります。動的サンプリングとハードパースによるI/O発生をなくすために統計情報と収集しクエリもあらかじめ一回づつ実行しておきます。


drop table t1 purge;

create table t1(c1 char(1));

exec dbms_stats.gather_table_stats(user, 't1');

select /* no_rows */ * from t1;
select /* 1 rows */ * from t1;

次の結果を見てください。


alter system flush buffer_cache;

select /* no_rows */ * 
from
 t1

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  TABLE ACCESS FULL T1 (cr=3 pr=1 pw=0 time=828 us)
      

insert into t1 values('1');
commit;

alter system flush buffer_cache;

select /* 1 rows */ * 
from
 t1

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  TABLE ACCESS FULL T1 (cr=21 pr=19 pw=0 time=3303 us)

空いたテーブルに対して全表走査をする場合にはPhysical Reads=1、Logical Reads=3であります。この値はどこから来るでしょうか。行(Row)が一つのテーブルの場合は全表走査に対してPhysical Reads=19、Logical Reads=21であります。この値はまたどこから来ますか。

この質問に答えてみたらオラクルでI/Oを追いかける簡単な技法を習うようになります。まずバージョンは次のようです。


UKJA@ukja1021> @version

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod

TablespaceはASSM(Automatic Segment Space Management)で管理されていてExtentのサイズはUniform Size 10Mであります。テーブルにデータが一件もない場合のSQL*Traceに対するTkprofの結果です。


select /* no_rows */ * 
from
 t1


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.00          1          3          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.00       0.00          1          3          0           0

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 61  

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  TABLE ACCESS FULL T1 (cr=3 pr=1 pw=0 time=828 us)

まずPhysical Reads(1)はどこから出た値かを確認してみます。トレース原本ファイルは次のようです。


PARSING IN CURSOR #10 len=30 dep=0 uid=61 oct=3 lid=61 tim=3012155435237 hv=1069717740 ad='2836fe0c'
select /* no_rows */ * from t1
END OF STMT
PARSE #10:c=0,e=877,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=3012155435230
EXEC #10:c=0,e=46,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=3012155436544
WAIT #10: nam='SQL*Net message to client' ela= 4 driver id=1413697536 #bytes=1 p3=0 obj#=18 tim=3012155436775
WAIT #10: nam='db file sequential read' ela= 282 file#=7 block#=25630 blocks=1 obj#=55933 tim=3012155437320 
FETCH #10:c=0,e=833,p=1,cr=3,cu=0,mis=0,r=0,dep=0,og=1,tim=3012155437829
WAIT #10: nam='SQL*Net message from client' ela= 1197 driver id=1413697536 #bytes=1 p3=0 obj#=55933 tim=3012155439358
STAT #10 id=1 cnt=0 pid=0 pos=1 obj=55933 op='TABLE ACCESS FULL T1 (cr=3 pr=1 pw=0 time=828 us)'

Db file sequential readイベントを見たらFile#=7、Block#=25630であります。ブロックダンプを通じて確認して見るとSegment Headerであるのが分かります。


UKJA@ukja1021> @which_obj2 7 25630
old   1: alter system dump datafile &__FILE block &__BLOCK
new   1: alter system dump datafile 7 block 25630

System altered.

Elapsed: 00:00:00.04
------------------------------------------------
dba =               7/25630
type =              PAGETABLE SEGMENT HEADER
------------------------------------------------

すなわち、Segment Headerを読み込むために一回のPhysical Readsが発生します。データが一件もないのでこれ以上のI/Oは不必要です。Physical Readsが一回しかないと言うのがその証拠です。それにもかかわらずLogical Reads(cr)が3であるのはSegment Headerをもう二度(したがって総三回)読むのを意味します。その理由は文書化されていません。たぶん空間情報を得るために内部的に確認作業をするのではないかと考えています。

そんな理由で全表走査による最小のLogical Readsは三回と認識されています。ここで一つ確認したいことは10200イベントです。10200イベントはLogical Readsを追いかける時使用されます。


10200
 "consistent read buffer status"
// *Cause:
// *Action:

でもこのイベントはデータを読み込む時のみ動作します。すなわち上の例のようにSegment Headerのようなメタブロックを読み込む時には記録されないようです。惜しい制約です。

一件のデータをInsertした後を観察してみます。


insert into t1 values ('1');
commit;

SQL*TraceによるTkprofの結果は次のようです。


select /* 1 rows */ * 
from
 t1


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00         19         21          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.00       0.00         19         21          0           1

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 61  

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  TABLE ACCESS FULL T1 (cr=21 pr=19 pw=0 time=3303 us)

私がテストしたシステムの場合にはPhysical Reads=19、Logical Reads=21であります。この値はバージョンやSegment Space Management方式、Extentのサイズによって違えます。

Physical Readsの19の値がどこから来たのかをトレース原本ファイルから確認してみます。


PARSING IN CURSOR #24 len=29 dep=0 uid=61 oct=3 lid=61 tim=3012155797727 hv=2697749229 ad='2825d88c'
select /* 1 rows */ * from t1
END OF STMT
PARSE #24:c=0,e=713,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=3012155797723
EXEC #24:c=0,e=49,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=3012155799033
WAIT #24: nam='SQL*Net message to client' ela= 6 driver id=1413697536 #bytes=1 p3=0 obj#=0 tim=3012155799433
WAIT #24: nam='db file sequential read' ela= 254 file#=7 block#=25630 blocks=1 obj#=55933 tim=3012155800000
WAIT #24: nam='db file sequential read' ela= 243 file#=7 block#=25609 blocks=1 obj#=55933 tim=3012155800562
WAIT #24: nam='db file sequential read' ela= 228 file#=7 block#=25629 blocks=1 obj#=55933 tim=3012155801014
WAIT #24: nam='db file scattered read' ela= 1315 file#=7 block#=25641 blocks=16 obj#=55933 tim=3012155802707
FETCH #24:c=0,e=3316,p=19,cr=13,cu=0,mis=0,r=1,dep=0,og=1,tim=3012155803019
WAIT #24: nam='SQL*Net message from client' ela= 298 driver id=1413697536 #bytes=1 p3=0 obj#=55933 tim=3012155803696
FETCH #24:c=0,e=34,p=0,cr=8,cu=0,mis=0,r=0,dep=0,og=1,tim=3012155803938
WAIT #24: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=55933 tim=3012155803998
WAIT #24: nam='SQL*Net message from client' ela= 2449 driver id=1413697536 #bytes=1 p3=0 obj#=55933 tim=3012155806478
STAT #24 id=1 cnt=1 pid=0 pos=1 obj=55933 op='TABLE ACCESS FULL T1 (cr=21 pr=19 pw=0 time=3303 us)'

三回のSingle Block I/O(Db file sequential read)と一回のMulti Block I/O(Db file scatteread read、Blocks=16)を通じて総19ブロックをPhysical I/Oで読み込みました。Single Block I/Oがどんなブロックを読み込んだのを確認してみたら次のようです。


UKJA@ukja1021> @which_obj2 7 25630
UKJA@ukja1021> @which_obj2 7 25609
UKJA@ukja1021> @which_obj2 7 25629

------------------------------------------------
dba =               7/25630
type =              PAGETABLE SEGMENT HEADER
------------------------------------------------
dba =               7/25609
type =              FIRST LEVEL BITMAP BLOCK
object_id =         55933
object_name =       T1
------------------------------------------------
dba =               7/25629
type =              SECOND LEVEL BITMAP BLOCK
object_id =         55933
object_name =       T1
------------------------------------------------

Segment HeaderとともにASSM(Automatic Segment Space Management)で使用されるFirst Level BMB、Second Level BMBを読み込んだのが分かります。（Third Level BMBはまだ生成されなかったので読み込まなかったんです）

それでは16個のPhysical Readsはどこから来たのでしょうか。スペース情報を見ると次のようです。


UKJA@ukja1021> exec show_space('T1');
Free Blocks.............................
Total Blocks............................1280
Total Bytes.............................10485760
Total MBytes............................10
Unused Blocks...........................1216
Unused Bytes............................9961472
Last Used Ext FileId....................7
Last Used Ext BlockId...................25609
Last Used Block.........................64

PL/SQL procedure successfully completed.

High Water Markが64番目のブロックまでを指差しています。したがってPhysical Readsは16ではなくて61(64－3)になるべきです。全表走査と言うのはデータブロックの初めてからHigh Water MarkまでをSequentialに読み込むのではありませんか。しかしオラクルはただ16個のブロックだけをPhysical Readsで読み込みました。これを説明しようとすればブロックの分布を管理するFirst Level BMBブロックの内容を見る必要があります。First Level BMB(file#=7, block#=25609)の内容は次のようです。


  --------------------------------------------------------
  DBA Ranges :
  --------------------------------------------------------
   0x01c06409  Length: 64     Offset: 0      
  
   0:Metadata   1:Metadata   2:Metadata   3:Metadata
   4:Metadata   5:Metadata   6:Metadata   7:Metadata
   8:Metadata   9:Metadata   10:Metadata   11:Metadata
   12:Metadata   13:Metadata   14:Metadata   15:Metadata
   16:Metadata   17:Metadata   18:Metadata   19:Metadata
   20:Metadata   21:Metadata   22:unformatted   23:unformatted
   24:unformatted   25:unformatted   26:unformatted   27:unformatted
   28:unformatted   29:unformatted   30:unformatted   31:unformatted
   32:75-100% free   33:75-100% free   34:75-100% free   35:75-100% free
   36:75-100% free   37:75-100% free   38:75-100% free   39:75-100% free
   40:75-100% free   41:75-100% free   42:75-100% free   43:75-100% free
   44:75-100% free   45:75-100% free   46:75-100% free   47:75-100% free
   48:unformatted   49:unformatted   50:unformatted   51:unformatted
   52:unformatted   53:unformatted   54:unformatted   55:unformatted
   56:unformatted   57:unformatted   58:unformatted   59:unformatted
   60:unformatted   61:unformatted   62:unformatted   63:unformatted

上の情報をみると総16個のブロック(32－47)のみが実際に使われていて残りのブロックは使わないUnformattedと言うのが分かります。オラクルはこの情報を利用して16個のブロックのみを一回のMulti Block I/Oで読み込んだのであります。

Physical Readsが19でここで上で見たように追加的なLogical Readsが二回発生するのでLogical Readsは21だと報告されているのです。

今頃ならなぜ安いながらも難しい質問だと言ったのか分かるんでしょう。意味のないテストのようですが(Just for Fun?)、その過程で得られる経験と知識は相当なものです。

テストで使われたスクリプトは次のURLを参照してください。

オラクル性能に対する短い考え＃11

2009-11-10T20:47:00.000-08:00

性能問題に対する正確な理解は用語に対する正確な理解から来る。

人間の考える能力が言語を作ったが、逆に言語が言語が人間の考えを支配するようになるでしょう。

オラクル性能世界でも同じです。用語に対する正確な理解がなければ問題を100％理解できないばかりでなく間違った知識を信じるようになってしまいます。例を挙げてみましょうか。

Explain PlanとExecution Planの違いが説明できますか。
ScanとLookupの差異は何ですか。
Histogramの意味は何ですか。
LockとEnqueueの意味が分けられますか。
SQLとCursorの違いが説明できますか。
Eventと言う用語はいつ使われるのか説明できますか。

用語が100％正確に説明できたらその自体で性能問題に対する相当な洞察力を持っていると言えます。

PL/SQLでのLoggingの使用

2009-11-09T21:02:00.000-08:00

Programming Langaugeと言うのが開発された以降発明された最高のデバッグツールはなんでしょうか。精巧で強力なデバッグツールがたくさんありますがなお一番強力で一番よく使われるデバッグツールは開発者が自分で記録するログ(Log)であります。

しかしPL/SQLは相対的にログを残す機能がとても弱いです。この問題を話し合ってみみます。

一番よく使用されるのがDBMS_OUTPUTパッケージでしょう。でも、PL/SQLブロックの実行が終わった後で記録されるので実行時間が長いPL/SQLブロックをデバッグする場合は相当不便です。


set serveroutput on

begin
 for idx in 1 .. 10 loop
  dbms_output.put_line(sysdate || ', ' || idx || 'th insertion');
  dbms_lock.sleep(1);
 end loop;
end;
/

2009/11/10 13:33:18, 1th insertion
2009/11/10 13:33:19, 2th insertion
2009/11/10 13:33:20, 3th insertion
2009/11/10 13:33:21, 4th insertion
2009/11/10 13:33:22, 5th insertion
2009/11/10 13:33:23, 6th insertion
2009/11/10 13:33:24, 7th insertion
2009/11/10 13:33:25, 8th insertion
2009/11/10 13:33:26, 9th insertion
2009/11/10 13:33:27, 10th insertion

PL/SQL procedure successfully completed.

Elapsed: 00:00:10.00

他のトリックは次のようにDBMS_SYSTEMパッケージを用いてトレースファイル(1)やAlert Logファイル(2)、または両方(3)に記録することです。TAILとかテキストエディターでファイルを開けてみればいいでしょう。UTL_FILEパッケージを利用して別途のファイルに記録して確認することもできます。この方法の一つデメリットはログファイルがサーバーにあると言うことです。ネットワーク接続や保安の問題によって使用しにくい場合が多いです。


begin
 for idx in 1 .. 10 loop
  sys.dbms_system.ksdwrt(1, sysdate || ', ' || idx || 'th insertion');
  dbms_lock.sleep(1);
 end loop;
end;
/

-- C:\ORACLE\ADMIN\UKJA1021\UDUMP\ukja1021_ora_1448.trc
*** 2009-11-10 13:37:15.015
*** ACTION NAME:() 2009-11-10 13:37:15.000
*** MODULE NAME:(SQL*Plus) 2009-11-10 13:37:15.000
*** SERVICE NAME:(UKJA1021) 2009-11-10 13:37:15.000
*** SESSION ID:(140.1169) 2009-11-10 13:37:15.000
2009/11/10 13:37:15, 1th insertion
2009/11/10 13:37:16, 2th insertion
2009/11/10 13:37:17, 3th insertion
2009/11/10 13:37:18, 4th insertion
2009/11/10 13:37:19, 5th insertion
2009/11/10 13:37:20, 6th insertion
2009/11/10 13:37:21, 7th insertion
2009/11/10 13:37:22, 8th insertion
2009/11/10 13:37:23, 9th insertion
2009/11/10 13:37:24, 10th insertion

プログラミングに興味があったらもっと良い方法が作れます。次の例を見てください。Pipelined Table FunctionとDBMS_PIPEパッケージを利用しています。特定セッションでログを記録すれば他のセッションではSELECT文を利用してログの内容を確認できます。上で見た二つの方法をみんな乗り越えています。


create or replace package pkg_log
as 
  type log_array is table of varchar2(4000);
 procedure log(message in varchar2);
 procedure flush;
 function get_log return log_array pipelined;
end;
/

show err

create or replace package body pkg_log
as
 procedure log(message in varchar2) is
  v_status number;
 begin
  dbms_pipe.pack_message(sysdate || ', ' || message);
    v_status := dbms_pipe.send_message('log');
 end log;
 
 procedure flush is
  v_status number;
 begin
  dbms_pipe.pack_message('$$END$$');
  v_status := dbms_pipe.send_message('log');
 end;
 
 function get_log return log_array pipelined is
  v_status  number;
  v_message varchar2(4000);
 begin
  while true loop
   v_status := dbms_pipe.receive_message('log');
     if v_status = 0 then
       dbms_pipe.unpack_message(v_message);
       if v_message = '$$END$$' then
        return;
       end if;
       pipe row(v_message);
       pipe row('');
     end if;
  end loop;
  return;
 end get_log;
end;
/

show err

使用例は次のようです。


-- session #1
begin
 for idx in 1 .. 10 loop
  pkg_log.log(idx || 'th insertion');
  dbms_lock.sleep(1);
 end loop;
 pkg_log.flush;
end;
/


-- session #2
set array 2
set pages 100
select * from table(pkg_log.get_log);

COLUMN_VALUE
---------------------------------------

2009/11/10 13:30:12, 1th insertion

2009/11/10 13:30:13, 2th insertion

2009/11/10 13:30:14, 3th insertion

2009/11/10 13:30:15, 4th insertion

2009/11/10 13:30:16, 5th insertion

2009/11/10 13:30:17, 6th insertion

2009/11/10 13:30:18, 7th insertion

2009/11/10 13:30:19, 8th insertion

2009/11/10 13:30:20, 9th insertion

2009/11/10 13:30:21, 10th insertion

考え方に沿って無数な方法でログを管理することができます。重要なものは自分が必要なツールはたまに自分で作ることができれば良いと言うことです。

オラクル性能に対する短い考え＃11

2009-11-08T22:27:00.000-08:00

人間は失敗から習うようにオラクル性能問題はバーグから習う

オラクル性能に対して最高のエンジニアはオラクル出身のエンジニアである場合がたくさんあります。なぜそうでしょうか。

オラクル内で他の人は得られない高級な情報をたくさん接したことでしょうか。

そうかも知れませんが、一番大きい理由はオラクルの障害およびバーグを接してそれを解決した経験が多いからです。

人間は失敗から習って、オラクルエンジニアは障害やバーグからオラクルを習うことです。障害に会ったら喜んで解決しようとすべき理由です。

SELECT文－Parse, Execute, Fetchどの段階？

2009-11-07T19:04:00.000-08:00

大部分のSELECT文はFetch段階で多くの時間とI/Oを使うようになります。例として、次のTkprof結果を見てください。


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.01       0.03          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.15       0.26        172        161          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.17       0.29        172        161          0           1

とても一般的な結果でしょう。SQL文は次のようです。


select max(t1.c1), max(t2.c2) from t1, t2
where rownum <= 100000
order by t2.c2, t1.c1

今度は次の結果を見てください。いかがですか。なぜFetch段階じゃなくてParse段階で大部分の時間を使っていますか。


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1    300.10     353.29         90       7060          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00          0          0          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4    300.10     353.29         90       7060          0           1

正答はハードパースです。ハードパースのために発生するOptimization過程はParse段階に属するのでTkprof結果でもParse段階に記録されます。SQL文は次のようです(500個のテーブルをジョインするように動的に生成されたSQL文です）。


select count(*) from T_HEAP_DUMP, T_ALERT_ANALYZE, T_MON_TEMP, T_MON_TIME_TEMP,
T_MON_LATCH_TEMP, T_MON_EVENT_TEMP, T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP,
CHAINED_ROWS, TT1, TT2, T1, T_SMALL, EXT_ORAUS, T_SMALL_WITH_SMALL_ROW,
T_TARGET2, T_ORAUS, T_TARGET1, T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG,
T_SMALL_LOB, T_BIG_LOB, T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP,
T_ALERT_ANALYZE, T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP,
T_MON_EVENT_TEMP, T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2,
T1, T_SMALL, EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP,  dual where 1 = 0

次はどうですか。なぜ今回はParse段階でもFetch段階でもなくてExecute段階で大部分の時間を使っていますか。


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1    322.45     368.33          3       6725          0           0
Fetch        2      0.00       0.01          0          0          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4    322.45     368.34          3       6725          0           1

正答はBind Peekingです。Bind Peekingが使われるとParse段階ではなくてExecute段階でOptimizationが行われます。従ってTkprof結果でもExecute段階に記録されます。


select count(*) from T_HEAP_DUMP, T_ALERT_ANALYZE, T_MON_TEMP, T_MON_TIME_TEMP,
T_MON_LATCH_TEMP, T_MON_EVENT_TEMP, T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP,
CHAINED_ROWS, TT1, TT2, T1, T_SMALL, EXT_ORAUS, T_SMALL_WITH_SMALL_ROW,
T_TARGET2, T_ORAUS, T_TARGET1, T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG,
T_SMALL_LOB, T_BIG_LOB, T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP,
T_ALERT_ANALYZE, T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP,
T_MON_EVENT_TEMP, T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2,
T1, T_SMALL, EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP, T_MON_MUTEX_TEMP, CHAINED_ROWS, TT1, TT2, T1, T_SMALL,
EXT_ORAUS, T_SMALL_WITH_SMALL_ROW, T_TARGET2, T_ORAUS, T_TARGET1,
T_SMALL_WITH_BIG_ROW, T_SMALL_WITH_LOB, T_NO_LOG, T_SMALL_LOB, T_BIG_LOB,
T_NOLOB, T3, T_LOB, T_NO_LOB, T_TARGET, T2, T_HEAP_DUMP, T_ALERT_ANALYZE,
T_MON_TEMP, T_MON_TIME_TEMP, T_MON_LATCH_TEMP, T_MON_EVENT_TEMP,
T_MON_ROWCACHE_TEMP,  dual where rownum = :b1

Tkprofの結果を解析する時はやっぱりいろいろなところに気にしなければならないと言う良い例の一つです。

オラクル性能に対する短い考え＃10

2009-11-03T22:22:00.000-08:00

パーティションはOLTPとはあまり関係ない

パーティションは大容量のデータを扱うDWシステムのため設計されました。OLTPシステムでのメリットはほとんどないと思います。

単純に行数が多いという理由でパーティションの使用を考慮していたら考え直すほうが良いです。目的に会わないパーティションの使用はかえって管理の難しさと以外の性能問題を起こす可能性があります。

もちろんOLTPとDWの中間どこかにあるハイブリッドシステムが多いので現実はこんなに単純ではありませんけど…

Native Full Outer Hash JoinとROWNUM

2009-11-02T22:25:00.000-08:00

オラクル11gはNative Full Outer Hash Joinを支援しています。ここによく説明されています。

ここで一つの疑問が生じます。Full Outer Joinを使いながらPagination QueryのためにROWNUM条件を使用すればオラクルはどんな実行計画を作るでしょうか。Native Full Outer JoinはHash Joinでだけ支援されるがPagination QueryはNested Loops Joinともっと似合います。次に簡単なテスト結果があります。

まず次のように二つのテーブルを作ります。


create table t1 as 
select level as c1, rpad('x',100) as c2
from dual
connect by level <= 100000
;

create table t2 as 
select level as c1, rpad('x',100) as c2
from dual
connect by level <= 100000
;

alter table t1 modify c1 not null;
alter table t2 modify c2 not null;

create index t1_n1 on t1(c1);
create index t2_n1 on t2(c1);

exec dbms_stats.gather_table_stats(user, 't1', no_invalidate=>false);
exec dbms_stats.gather_table_stats(user, 't2', no_invalidate=>false);

Full Outer Joinではない一般Outer Joinの場合はNested Loops Joinが選択されPaginationの目的によく合います。性能も優れるはずです。


explain plan for
select * from (
 select rownum as r, x.* from (
  select *
  from t1 left join t2 on t1.c1 = t2.c1
  ) x where rownum <= 10
) where r >= 1
;

-----------------------------------------------------------------------------
| Id  | Operation                      | Name  | Rows  | Bytes | Cost (%CPU)|
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |       |    10 |  1430 |    24   (0)|
|*  1 |  VIEW                          |       |    10 |  1430 |    24   (0)|
|*  2 |   COUNT STOPKEY                |       |       |       |            |
|   3 |    NESTED LOOPS OUTER          |       |    11 |  2310 |    24   (0)|
|   4 |     TABLE ACCESS FULL          | T1    |    11 |  1155 |     2   (0)|
|   5 |     TABLE ACCESS BY INDEX ROWID| T2    |     1 |   105 |     2   (0)|
|*  6 |      INDEX RANGE SCAN          | T2_N1 |     1 |       |     1   (0)|
-----------------------------------------------------------------------------

でもFull Outer Joinを使えばNative Full Outer Hash Joinが使用されます。Paginationの目的にはぜんぜん合いません。


explain plan for
select * from (
 select rownum as r, x.* from (
  select *
  from t1 full join t2 on t1.c1 = t2.c1
  ) x where rownum <= 10
) where r >= 1
;

--------------------------------------------------------------------------------
| Id  | Operation               | Name     | Rows  | Bytes |TempSpc| Cost (%CPU)
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT        |          |    10 |  1430 |       |  2302   (1)
|*  1 |  VIEW                   |          |    10 |  1430 |       |  2302   (1)
|*  2 |   COUNT STOPKEY         |          |       |       |       |            
|   3 |    VIEW                 | VW_FOJ_0 |   100K|    12M|       |  2302   (1)
|*  4 |     HASH JOIN FULL OUTER|          |   100K|    20M|    11M|  2302   (1)
|   5 |      TABLE ACCESS FULL  | T1       |   100K|    10M|       |   596   (1)
|   6 |      TABLE ACCESS FULL  | T2       |   100K|    10M|       |   596   (1)
--------------------------------------------------------------------------------

Native Full Outer Joinは次のパラメータで制御されます。


UKJA@ukja1106> @para outer_join
NAME                           VALUE                IS_DEFAUL SES_MODIFI
------------------------------ -------------------- --------- ----------
SYS_MODIFI
----------
DESCRIPTION
------------------------------------------------------------------------

_optimizer_native_full_outer_j FORCE                TRUE      true
oin
immediate
execute full outer join using native implementaion

このパラメータをオフさせたらNative Full Outer JoinではなくてUNION ALLを利用したFull Outer Join(すなわち10gの方式)に変わるだけ、Paginationに適当なNested Loops Joinに変わることではないんです。


explain plan for
select * from (
 select rownum as r, x.* from (
  select /*+ opt_param('_optimizer_native_full_outer_join', 'off') */ *
  from t1 full join t2 on t1.c1 = t2.c1
 ) x where rownum <= 10
) where r >= 1
;

--------------------------------------------------------------------------------
| Id  | Operation                 | Name  | Rows  | Bytes |TempSpc| Cost (%CPU)|
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT          |       |    10 |  1430 |       |  3620   (1)|
|*  1 |  VIEW                     |       |    10 |  1430 |       |  3620   (1)|
|*  2 |   COUNT STOPKEY           |       |       |       |       |            |
|   3 |    VIEW                   |       |   199K|    24M|       |  3620   (1)|
|   4 |     UNION-ALL             |       |       |       |       |            |
|*  5 |      HASH JOIN OUTER      |       |   100K|    20M|    11M|  2302   (1)|
|   6 |       TABLE ACCESS FULL   | T1    |   100K|    10M|       |   596   (1)|
|   7 |       TABLE ACCESS FULL   | T2    |   100K|    10M|       |   596   (1)|
|*  8 |      HASH JOIN RIGHT ANTI |       | 99999 |    10M|  1664K|  1318   (1)|
|   9 |       INDEX FAST FULL SCAN| T1_N1 |   100K|   488K|       |    86   (2)|
|  10 |       TABLE ACCESS FULL   | T2    |   100K|    10M|       |   596   (1)|
--------------------------------------------------------------------------------

無理にFIRST_ROWS(10)ヒントを与えるとようやく欲した形態の実行計画が現れます。


explain plan for
select * from (
 select rownum as r, x.* from (
  select /*+ first_rows(10) 
         opt_param('_optimizer_native_full_outer_join', 'off') */ *
  from t1 full join t2 on t1.c1 = t2.c1
 ) x where rownum <= 10
) where r >= 1
;

-------------------------------------------------------------------------------
| Id  | Operation                        | Name  | Rows  | Bytes | Cost (%CPU)|
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |       |    10 |  1430 |    37   (0)|
|*  1 |  VIEW                            |       |    10 |  1430 |    37   (0)|
|*  2 |   COUNT STOPKEY                  |       |       |       |            |
|   3 |    VIEW                          |       |    22 |  2860 |    37   (0)|
|   4 |     UNION-ALL                    |       |       |       |            |
|   5 |      NESTED LOOPS OUTER          |       |    11 |  2310 |    24   (0)|
|   6 |       TABLE ACCESS FULL          | T1    |    11 |  1155 |     2   (0)|
|   7 |       TABLE ACCESS BY INDEX ROWID| T2    |     1 |   105 |     2   (0)|
|*  8 |        INDEX RANGE SCAN          | T2_N1 |     1 |       |     1   (0)|
|   9 |      NESTED LOOPS ANTI           |       |    11 |  1210 |    13   (0)|
|  10 |       TABLE ACCESS FULL          | T2    |    11 |  1155 |     2   (0)|
|* 11 |       INDEX RANGE SCAN           | T1_N1 |     1 |     5 |     1   (0)|
-------------------------------------------------------------------------------

これはちょっと失望名結果です。なぜならROWNUM条件を使えばオラクルは内部的にFIRST ROWS技法を真似するオプションを持っているからです。でも願っただけきちんと動作しませんでした。


UKJA@ukja1106> @para rownum_pred
NAME                           VALUE                IS_DEFAUL SES_MODIFI
------------------------------ -------------------- --------- ----------
SYS_MODIFI
----------
DESCRIPTION
------------------------------------------------------------------------

_optimizer_rownum_pred_based_f TRUE                 TRUE      true
kr
immediate
enable the use of first K rows due to rownum predicate

次のようにヒントを使用してNative Full Outer Hash Joinを制御できます。


UKJA@ukja1106> @hint native

NAME                           INVERSE                        VERSION
------------------------------ ------------------------------ ----------
NATIVE_FULL_OUTER_JOIN         NO_NATIVE_FULL_OUTER_JOIN      10.2.0.3
NO_NATIVE_FULL_OUTER_JOIN      NATIVE_FULL_OUTER_JOIN         10.2.0.3

次のように使用します。


explain plan for
select * from (
 select rownum as r, x.* from (
  select /*+ first_rows(10) no_native_full_outer_join */ *
  from t1 full join t2 on t1.c1 = t2.c1
  ) x where rownum <= 10
) where r >= 1
;

-------------------------------------------------------------------------------
| Id  | Operation                        | Name  | Rows  | Bytes | Cost (%CPU)|
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |       |    10 |  1430 |    37   (0)|
|*  1 |  VIEW                            |       |    10 |  1430 |    37   (0)|
|*  2 |   COUNT STOPKEY                  |       |       |       |            |
|   3 |    VIEW                          |       |    22 |  2860 |    37   (0)|
|   4 |     UNION-ALL                    |       |       |       |            |
|   5 |      NESTED LOOPS OUTER          |       |    11 |  2310 |    24   (0)|
|   6 |       TABLE ACCESS FULL          | T1    |    11 |  1155 |     2   (0)|
|   7 |       TABLE ACCESS BY INDEX ROWID| T2    |     1 |   105 |     2   (0)|
|*  8 |        INDEX RANGE SCAN          | T2_N1 |     1 |       |     1   (0)|
|   9 |      NESTED LOOPS ANTI           |       |    11 |  1210 |    13   (0)|
|  10 |       TABLE ACCESS FULL          | T2    |    11 |  1155 |     2   (0)|
|* 11 |       INDEX RANGE SCAN           | T1_N1 |     1 |     5 |     1   (0)|
-------------------------------------------------------------------------------

伝統的なUSE_NLヒントも当然動作します。


explain plan for
select * from (
 select rownum as r, x.* from (
  select /*+ use_nl(t1) use_nl(t2) */ *
  from t1 full join t2 on t1.c1 = t2.c1
  ) x where rownum <= 10
) where r >= 1
;

--------------------------------------------------------------------------
| Id  | Operation                        | Name  | Rows  | Bytes |TempSpc|
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |       |    10 |  1430 |       |
|*  1 |  VIEW                            |       |    10 |  1430 |       |
|*  2 |   COUNT STOPKEY                  |       |       |       |       |
|   3 |    VIEW                          |       |   199K|    24M|       |
|   4 |     UNION-ALL                    |       |       |       |       |
|   5 |      NESTED LOOPS OUTER          |       |   100K|    20M|       |
|   6 |       TABLE ACCESS FULL          | T1    |   100K|    10M|       |
|   7 |       TABLE ACCESS BY INDEX ROWID| T2    |     1 |   105 |       |
|*  8 |        INDEX RANGE SCAN          | T2_N1 |     1 |       |       |
|*  9 |      HASH JOIN RIGHT ANTI        |       | 99999 |    10M|  1664K|
|  10 |       INDEX FAST FULL SCAN       | T1_N1 |   100K|   488K|       |
|  11 |       TABLE ACCESS FULL          | T2    |   100K|    10M|       |
--------------------------------------------------------------------------

Nested Loops Joinが選択された場合とそうではない場合はPagination Queryで相当な性能の違いが存在します。


select /*+ gather_plan_statistics */ * from (
 select rownum as r, x.* from (
  select *
  from t1 full join t2 on t1.c1 = t2.c1
  ) x where rownum <= 10
) where r >= 1
;

--------------------------------------------------------------------------------
| Id  | Operation               | Name     | Starts | A-Rows | Buffers | Reads |
--------------------------------------------------------------------------------
|*  1 |  VIEW                   |          |      1 |     10 |    1547 |    682|
|*  2 |   COUNT STOPKEY         |          |      1 |     10 |    1547 |    682|
|   3 |    VIEW                 | VW_FOJ_0 |      1 |     10 |    1547 |    682|
|*  4 |     HASH JOIN FULL OUTER|          |      1 |     10 |    1547 |    682|
|   5 |      TABLE ACCESS FULL  | T1       |      1 |    100K|    1542 |      0|
|   6 |      TABLE ACCESS FULL  | T2       |      1 |     16 |       5 |      0|
--------------------------------------------------------------------------------


select /*+ gather_plan_statistics */ * from (
 select rownum as r, x.* from (
  select /*+ first_rows(10) 
       opt_param('_optimizer_native_full_outer_join', 'off') */ *
  from t1 full join t2 on t1.c1 = t2.c1
 ) x where rownum <= 10
) where r >= 1
;

------------------------------------------------------------------------------
| Id  | Operation                        | Name  | Starts | A-Rows | Buffers |
------------------------------------------------------------------------------
|*  1 |  VIEW                            |       |      1 |     10 |      16 |
|*  2 |   COUNT STOPKEY                  |       |      1 |     10 |      16 |
|   3 |    VIEW                          |       |      1 |     10 |      16 |
|   4 |     UNION-ALL                    |       |      1 |     10 |      16 |
|   5 |      NESTED LOOPS OUTER          |       |      1 |     10 |      16 |
|   6 |       TABLE ACCESS FULL          | T1    |      1 |     10 |       5 |
|   7 |       TABLE ACCESS BY INDEX ROWID| T2    |     10 |     10 |      11 |
|*  8 |        INDEX RANGE SCAN          | T2_N1 |     10 |     10 |       9 |
|   9 |      NESTED LOOPS ANTI           |       |      0 |      0 |       0 |
|  10 |       TABLE ACCESS FULL          | T2    |      0 |      0 |       0 |
|* 11 |       INDEX RANGE SCAN           | T1_N1 |      0 |      0 |       0 |
------------------------------------------------------------------------------

ここでもう一つの疑問が持てます。多くのPagination QueryがORDER BY句を使用します。万一このORDER BYをインデックスで処理できないとしたらNested Loops Joinのメリットは消えてしまいます。こんな場合はNative Full Outer Hash Joinが本然のメリットを発揮することができるはずです。

私は個人的にFIRST_ROWS類のヒントやモードはなくなるべきだと思いますが、なお必要がありますね。:)

オプティマイザがだんだん賢くなっていますがたまにはとても簡単なクエリでも手動制御が必要な場合があります。われらが相変わらずヒントを身に付けなければならない理由となります。

オラクル性能に対する短い考え＃9

2009-11-01T23:14:00.000-08:00

データがなければ性能分析もない。

次の質問をよく見てください。

昨夜にオラクルセッション数が急に増えながら性能が低下しました。あるセッションは何もできないハング状態でした。一部のセッションはlog file syncイベントを待機していました。原因は何でしょうか。

次の質問と比べたらどうですか。似ているんじゃないですか。

昨夜寝ているのに急に頭が少しぼっとして手足も痛みました。右手は動かせなかったんです。左側の太股もわずかに痛みました。原因は何でしょうか。

個人的に病院に行って検査受けるのが大嫌いですが、患者の状態に対する細かいデータがなくては診断も治療も不可能です。相談をしたりMRIを取ったりするのがみんなこのような理由です。オラクル性能問題も同じです。性能問題の類型に応じてSystem State Dump, Process State Dump, Error Stack Dump, Heap Dump, 10046 Event Dump, 10053 Event Dumpなどのデータがなくては全てが推測に過ぎません。推測するのが面白いかも知れませんが、大事な健康を推測で危なくするのはだめでしょう。

専門化が一番輝く瞬間は分析できるデータが十分な時です。

オラクル性能に対する短い考え＃8

2009-10-29T01:08:00.000-07:00

ジャヴァ開発者たちはオラクルに対してもっと知らなければならない

ジャヴァとJDBCを利用すれば具現に一月が掛かって性能は遅いプログラムをオラクルが提供する機能を利用すれば具現には一日が掛かって性能は優れるプログラムが作れます。いつもそうだと言うことではないんですけど多くのばあいそうです。

でもこんなノーハウたちがまだ多い開発者たちに広範囲に共有されていないみたいです。誰の責任なのかは分かりませんけど...

オラクル性能に対する短い考え　＃7

2009-10-27T18:10:00.000-07:00

オラクル性能コンサルティングの単価は上がるか下がるか

オラクルに入門した人なら誰でもオラクル性能専門家を夢見て、究極的には高い収入が保障されるコンサルタントを目標にするようになります。

現実は、世界的な景気沈滞と共に大型プロジェクトが失踪しながらオラクル性能コンサルタントの単価は速い速度で下がっています。当分の間はこんな傾向が加速化するはずです。

もう一度の事実は、ソフトウエア業界が若い人たちに離れられて実力のある者の数がかえって次第に減っていることです。それなら実力を認められた人たちの単価はかえって上がらないんでしょうか。

今の選択が向後5－10年を左右します。皆さんの選択は何ですか。

なぜ診断イベントを理解すべきなのか。

2009-10-26T23:18:00.000-07:00

たとえ開発者と言ってもオラクルが提供する診断イベントを理解するのが必要だと思います。たとえば次のような質問を見てください。

整列領域大きさ(Sort Area Size)によって整列がどのように行われるかを理解するように多様なテストを修行しています。どころでSORT_AREA_SIZEパラメータ値を300バイトで低く設定してもオラクルが最小値を自分で調整するらしいです。オラクルで使用可能な整列領域大きさの最小値がいくらなのか分かる方法は何でしょうか。

マニュアルには下記のように記述されています。

http://download.oracle.com/docs/cd/B28359_01/server.111/b28320/initparams232.htm

すなわち、整列領域大きさの最小値は6*8K(データベースブロックサイズ)＝48Kバイトだというのが分かります。本当のエンジニアだったらここから進み、この最小値を目で確認する方法はないのか？と質問をするようになるはずです。

この類の質問に一番直接的に答ができるのが診断イベントです。たとえば10032イベントを活性化すれば、オラクルは整列作業の修行に対する詳細な統計情報を記録してくれます。


UKJA@ukja1021> @oerr 10032
10032
 "sort statistics (SOR*)"
// *Cause:
// *Action:

また10033イベントを利用すれば実際の整列を修行しながら個別Sort Runたちをどのように使用するのかまで分かります。大変有用な情報でしょう。


UKJA@ukja1021> @oerr 10033
10033
 "sort run information (SRD*/SRS*)"
// *Cause:
// *Action:
// *Cause:
// *Action:

10032イベントを利用してマニュアルの内容を検証してみましょうか。


drop table t1 purge;
create table t1
as select rpad('x',300,'x') as c1
from dual
connect by level <= 100
;

alter session set workarea_size_policy=manual;
alter session set sort_area_size=300;

alter session set events '10032 trace name context forever, level 1';

select c1 from t1 order by c1;

alter session set events '10032 trace name context off';

トレースファイルの内容は次のとおりです。SORT_AREA_SIZE値が正確に48Kバイトというのが確認できます。


---- Sort Parameters ------------------------------
sort_area_size                    49152
sort_area_retained_size           16384
sort_multiblock_read_count        1
max intermediate merge width      2
---- Sort Statistics ------------------------------
Initial runs                              1
Input records                             100
Output records                            100
Disk blocks 1st pass                      4
Total disk blocks used                    6
Total number of comparisons performed     102
  Comparisons performed by in-memory sort 101
  Comparisons while searching for key in-memory 1
Temp segments allocated                   1
Extents allocated                         1
Uses version 2 sort
Uses asynchronous IO
    ---- Run Directory Statistics ----
Run directory block reads (buffer cache)  2
Block pins (for run directory)            1
Block repins (for run directory)          1
    ---- Direct Write Statistics -----
Write slot size                           8192
Write slots used during in-memory sort    2
Number of direct writes                   4
Num blocks written (with direct write)    4
Block pins (for sort records)             4
Cached block repins (for sort records)    1
Waits for async writes                    3
    ---- Direct Read Statistics ------
Size of read slots for output             8192
Number of read slots for output           2
Number of direct sync reads               2
Number of blocks read synchronously       2
Number of direct async reads              2
Number of blocks read asynchronously      2
---- End of Sort Statistics -----------------------

立派な開発者ならデバッガ(Debugger)に上手なはずです。オラクルの診断イベントはオラクルデバッガと言えます。オラクルを深く理解しようとすれば必修的な知識だと言えます。

バージョン間パラメータの比較

2009-10-25T18:05:00.000-07:00

多数のバージョンのオラクルを運営してみたらパラメータ値のバージョン間の違いを知るのが重要になります。次が私がよく使用する方法です。

比較してみたい対象DBに対してDB Linkを作ります。
Full Outer Joinを通じて両DB間のパラメータ値を比較します。
X$ビューを利用すればヒドゥンパラメータの値まで得られます。

このロジックがここに具現されています。

次は使用例です。まずDB Linkが成功的に作られたか確認します。


UKJA@ukja1106> select * from dual@ukja1021;

D
-
X

Mutexに関するパラメータのバージョン間の違いは？


UKJA@ukja1106> @para_diff UKJA1021 mutex

MCH NAME                      M_VALUE    Y_VALUE    DESCRIPTION
--- ------------------------- ---------- ---------- -------------------------
X   _kks_use_mutex_pin        TRUE       FALSE      Turning on this will make
                                                     KKS use mutex for cursor

オプティマイザとインデックスに関するパラメータのバージョン間の違いは？


UKJA@ukja1106> @para_diff UKJA1021 optimizer%index

MCH NAME                      M_VALUE    Y_VALUE    DESCRIPTION
--- ------------------------- ---------- ---------- -------------------------
O   _optimizer_compute_index_ TRUE       TRUE       force index stats collect
    stats                                           ion on index creation/reb
                                                    uild

X   _optimizer_fkr_index_cost 10                    Optimizer index bias over
    _bias                                            FTS/IFFS under first K r
                                                    ows mode

O   optimizer_index_caching   0          0          optimizer percent index c
                                                    aching
                                                    
O   optimizer_index_cost_adj  100        100        optimizer index cost adju
                                                    stment

X   optimizer_use_invisible_i FALSE                 Usage of invisible indexe
    ndexes                                          s (TRUE/FALSE)

このようにすれば全てのパラメータが比べられます。


UKJA@ukja1106> @para_diff UKJA1021 %

MCH NAME                      M_VALUE    Y_VALUE    DESCRIPTION
--- ------------------------- ---------- ---------- -------------------------
O   O7_DICTIONARY_ACCESSIBILI FALSE      FALSE      Version 7 Dictionary Acce
    TY                                              ssibility Support

O   _4031_dump_bitvec         67194879   67194879   bitvec to specify dumps p
                                                    rior to 4031 error

O   _4031_dump_interval       300        300        Dump 4031 error once for
                                                    each n-second interval
...

O   workarea_size_policy      AUTO       AUTO       policy used to size SQL w
                                                    orking areas (MANUAL/AUTO
                                                    )

X   xml_db_events             enable                are XML DB events enabled

1964 rows selected.

Elapsed: 00:00:08.35

かなり便利じゃないですか。:)

オラクル性能に対する短い考え＃6

2009-10-23T02:20:00.000-07:00

時間(Time)は一番危ない性能測定方法である

これ何のとんでもない言葉でしょうか。：)

もちろん時間は一番直観的で確実な性能測定方法です。これには異論の余地がありません。

でも、時間が改善された理由を明確に打ち明けずに済んだらこれより危険なものはありません。間違った結論を下しやすいです。オラクルがどんな作業をどのようにしたので時間が改善されたのか、これが重要なものですか、時間の改善自体は重要ではありません。

それでオラクルの性能を測る時は時間だけじゃなくてワーカロード(Logical Readsのような)、レッチの獲得、Mutexの獲得、待機イベント、必要な場合OSレベルのデータなどのバックグラウンドデータがずっと重要です。こんなデータをよく収集し分析したら時間は見る必要さえありません。不幸にも現在のオラクル性能教育ではこんなものを体系的に教える所はありません。

長い文字列(VARCHAR2)の使用

2009-10-21T21:56:00.000-07:00

PL/SQLを使用してみたら、長い文字列、すなわち4,000バイト以上の文字列を使用する必要ができます。どころでちょっと、VARCHAR2は4,000バイトまでだけ支援していませんか。


UKJA@ukja1021> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production

次のように4,000バイトはよく表現されます。


UKJA@ukja1021> select rpad('x',4000,'x') from dual;

RPAD('X',4000,'X')
--------------------------------------------------------------------------------
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...

10,000バイトも使用できましょうか。次の結果を見ると、あら、支援されますよね。


UKJA@ukja1021> select rpad('x',10000,'x') from dual;

RPAD('X',10000,'X')
--------------------------------------------------------------------------------
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...

でも、実際は4,000バイトで切られてしまったのが分かります。


UKJA@ukja1021> select length(rpad('x',10000,'x')) from dual;

LENGTH(RPAD('X',10000,'X'))
---------------------------
                       4000

次のような無理な試みはやっぱり駄目でしょう。


UKJA@ukja1021> select rpad('x',4000,'x')||rpad('x',4000,'x') from dual;
select rpad('x',4000,'x')||rpad('x',4000,'x') from dual
                                                   *
ERROR at line 1:
ORA-01489: result of string concatenation is too long

幸いにPL/SQL内ではVARCHAR2を32Kバイトまで使用できます。もちろんPL/SQL内でだけ使用可能です。このぐらいの長い文字列だったら大部分SQL文章を動的に生成しようとする場合です。


UKJA@ukja1021> declare
  2        v_sql      varchar2(32767);
  3        v_cursor      sys_refcursor;
  4  begin
  5        v_sql := 'select ';
  6        for idx in 1 .. 100 loop
  7         v_sql := v_sql || q'[']' || rpad('x',200) || q'[',]';
  8        end loop;
  9        v_sql := v_sql || ' 1 from dual';
 10  
 11        open v_cursor for v_sql;
 12        close v_cursor;
 13  end loop;
 14  /

PL/SQL procedure successfully completed.

でも32Kバイトを越えるとエラーが出ます。


UKJA@ukja1021> declare
  2        v_sql      varchar2(32767);
  3        v_cursor      sys_refcursor;
  4  begin
  5        v_sql := 'select ';
  6        for idx in 1 .. 300 loop
  7         v_sql := v_sql || q'[']' || rpad('x',200) || q'[',]';
  8        end loop;
  9        v_sql := v_sql || ' 1 from dual';
 10  
 11        open v_cursor for v_sql;
 12        close v_cursor;
 13  end loop;
 14  /
declare
*
ERROR at line 1:
ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at line 7

こんな場合にはCLOBを使用すればいいです。でもCLOBの場合にはREF CURSORとは使用できません。


UKJA@ukja1021> declare
  2        v_sql      clob;
  3        v_cursor      sys_refcursor;
  4  begin
  5        v_sql := 'select ';
  6        for idx in 1 .. 300 loop
  7         v_sql := v_sql || q'[']' || rpad('x',200) || q'[',]';
  8        end loop;
  9        v_sql := v_sql || ' 1 from dual';
 10  
 11        open v_cursor for v_sql;
 12        close v_cursor;
 13  end loop;
 14  /
 open v_cursor for v_sql;
                   *
ERROR at line 11:
ORA-06550: line 11, column 20:
PLS-00382: expression is of wrong type
ORA-06550: line 11, column 2:
PL/SQL: Statement ignored

当然にEXECUTE IMMEDIATEでも願うとおり動作しません。では32Kバイトより長いSQL文章を動的に使用できる方法は何でしょうか。次のように少しは複雑に見える方法でDBMS_SQLパッケージを使用することです。CLOBをいくつかの小さなVARCHAR2文字列に割ってDBMS_SQL.PARSEパッケージに伝達します。


UKJA@ukja1021> declare
  2        v_sql      clob;
  3        v_array dbms_sql.varchar2a;
  4        v_curno number;
  5        v_ret      integer;
  6        v_ub      number;
  7  begin
  8        v_sql := 'select ';
  9        for idx in 1 .. 300 loop
 10         v_sql := v_sql || q'[']' || rpad('x',200) || q'[',]';
 11        end loop;
 12        v_sql := v_sql || ' 1 from dual';
 13  
 14        v_curno := dbms_sql.open_cursor;
 15        v_ub := ceil(dbms_lob.getlength(v_sql)/1000);
 16        for idx in 1 .. v_ub loop
 17         v_array(idx) := dbms_lob.substr(v_sql, 1000, (idx-1)*1000+1);
 18        end loop;
 19  
 20        dbms_sql.parse(v_curno, v_array, 1, v_ub, false, dbms_sql.native);
 21        v_ret := dbms_sql.execute(v_curno);
 22        dbms_sql.close_cursor(v_curno);
 23  end loop;
 24  /

PL/SQL procedure successfully completed.

幸いにOracle11gからはCLOBをREF CURSORに直接使用できます。EXECUTE IMMEDIATEでも使用できるのは当然ですよ。


UKJA@ukja1106> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
CORE 11.1.0.6.0 Production
TNS for 32-bit Windows: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production

UKJA@ukja1106> declare
  2        v_sql      clob;
  3        v_cursor      sys_refcursor;
  4  begin
  5        v_sql := 'select ';
  6        for idx in 1 .. 300 loop
  7         v_sql := v_sql || q'[']' || rpad('x',200) || q'[',]';
  8        end loop;
  9        v_sql := v_sql || ' 1 from dual';
 10  
 11        open v_cursor for v_sql;
 12        close v_cursor;
 13  end loop;
 14  /

PL/SQL procedure successfully completed.

DBMS_SQLパッケージでもCLOBをSQLテキストに使用可能です。


UKJA@ukja1106> declare
  2        v_sql      clob;
  3        v_curno number;
  4        v_ret      integer;
  5  begin
  6        v_sql := 'select ';
  7        for idx in 1 .. 300 loop
  8         v_sql := v_sql || q'[']' || rpad('x',200) || q'[',]';
  9        end loop;
 10        v_sql := v_sql || ' 1 from dual';
 11  
 12        v_curno := dbms_sql.open_cursor;
 13        dbms_sql.parse(v_curno, v_sql, dbms_sql.native);
 14        v_ret := dbms_sql.execute(v_curno);
 15        dbms_sql.close_cursor(v_curno);
 16  end loop;
 17  /

PL/SQL procedure successfully completed.

なお、REF CURSORとDBMS_SQLの間に変換も自由です。以前の制約がほとんどなくなりました。


UKJA@ukja1106> declare
  2        v_sql      clob;
  3        v_curno number;
  4        v_ret      integer;
  5        v_cursor      sys_refcursor;
  6  begin
  7        v_sql := 'select ';
  8        for idx in 1 .. 300 loop
  9         v_sql := v_sql || q'[']' || rpad('x',200) || q'[',]';
 10        end loop;
 11        v_sql := v_sql || ' 1 from dual';
 12  
 13        v_curno := dbms_sql.open_cursor;
 14        dbms_sql.parse(v_curno, v_sql, dbms_sql.native);
 15        v_ret := dbms_sql.execute(v_curno);
 16        v_cursor := dbms_sql.to_refcursor(v_curno);
 17        close v_cursor;
 18  
 19  end loop;
 20  /

PL/SQL procedure successfully completed.

やはり新しいバージョンがいいですね。

オラクル性能に対する短い考え　＃５

2009-10-20T23:36:00.000-07:00

専門家の言うことを信じるな。

いわゆるオラクル性能専門家という方々が書いたこととか言ったことを反駁したら一冊の本を出せるかもと普段から考えています。

私も三冊の本を出したが、専門家たちが自分がもうよく分かっている内容を本で出すようでしょう。とんでもないんです。分からないものを研究しながら本を出すのです。だからどんなに多くの誤りがあるでしょうか。

皆が普通の人間なのでだんなにとんでもない失敗をするか知れません。大部分の開発者がアプリソースコードの100ラインあたり一ラインくらいでバグを作ると言われています。1％の誤謬がいつもあるのです。専門家たちの言うことや書くことも例外ではありません。私が書いた本を今見るといくら多くの誤りがあるか知れません。顔が真っ赤になります。

誰が専門家のように何かを言えば三番だけしつこく聞いてみてください。すぐ底をつくことになってしまいますよ。その過程を繰り返してみれば自分がいつの間にか専門家の水準に発展したのを見るようになるでしょう。

Dion Cho - Oracle Performance Storyteller

グローバルヒントの制約の面白いケース

並列MERGE文章の実行計画の解析

Oracle 11gのSerial Direct Path Readと_very_large_object_thresholdパラメータパラメータ

結合の手順の制御

RAW値の切り替え

Batching NLJに対するOracleマニュアルの説明

PLAN_HASH_VALUE

待機イベントが含まれている10046診断イベントの実行ーOracle11g

Library Cache Pinに対するSelf Deadlockを作ってみよう。

Remote SQL

Deferred Segment Creation機能の面白い2つのバグ

Batching NLJ最適化と整列

「ティパック」知能的な待機イベントの分析 - Part 1

「ティパック」oradebug

「ティパック」性能問題をトラブルシューティングする２つのフレーム

「ティパック」を紹介します。

性能改善の絶対的な原則！

_gby_hash_aggregation_enabledバグ

INSERT...VALUESコマンドとAPPENDヒント

PGAサイズの非正常的な増加

Library cache pin競合の面白いケース

Oracle Hang状態でActive Session Listを獲得しよう。

SQLでOSの資源を操作したい時 - Java Stored Procedureの活用

Oracle 11.1.0.6のトリガーバグ分析 － ティパックの活用

Errorstackダンプで問題のSQLを突き止めること

SQL文章レベルの診断イベント

過去の統計情報を分析しましょう。

クエリが現在実行段階のどこを実行しているのか分かる方法がないんでしょうか

Process Explorer

他のセッションのパラメータを制御しよう

AWRレポートを手軽に利用しよう。

オラクル性能に対する短い考え＃19

Oracle 11gR2のオプティマイザのCardinaliy Feedback

私のブログに雪が降っています。

書き出し一貫性 - Restartメカニズム

オラクル性能に対する短い考え＃18

バインドピーキングとSQLトレースの出会い

オラクル性能に対する短い考え＃17

バグ5364143 - バインドピーク問題

バージョン互換性を備えたスクリプト作り

オラクルに対する短い考え #16

Oracle 11gR2의 Zero-Size Unusable Indexとテーブル拡張(Table Expansion)

オラクル性能に対する短い考え＃15

統計情報がない時CBOは何をするだろうか。

オラクル性能に対する短い考え＃14

並列実行とV$PQ_TQSTATビュー

My Oracle Support(MOS. 旧Metalink)はなおHTMLを支援します。

オラクル性能に対する短い考え＃13

Physical Reads、Logical Readsを追い掛けよう。

オラクル性能に対する短い考え＃11

PL/SQLでのLoggingの使用

オラクル性能に対する短い考え＃11

SELECT文－Parse, Execute, Fetchどの段階？

オラクル性能に対する短い考え＃10

Native Full Outer Hash JoinとROWNUM

オラクル性能に対する短い考え＃9

オラクル性能に対する短い考え＃8

オラクル性能に対する短い考え ＃7

なぜ診断イベントを理解すべきなのか。

バージョン間パラメータの比較

オラクル性能に対する短い考え＃6

長い文字列(VARCHAR2)の使用

オラクル性能に対する短い考え ＃５

SQLでOSの資源を操作したい時　-　Java Stored Procedureの活用

Oracle 11.1.0.6のトリガーバグ分析　－　ティパックの活用

オラクル性能に対する短い考え　＃7

オラクル性能に対する短い考え　＃５