先生！、全行アクセスしてるのに Nested Loop Join しちゃうんです！ （東京都 ITエンジニア 男性） - optimizer_mode は正しく設定しましょう！

ということで、（どういうことだw
（今日のねたはアドベントカレンダーのネタを考えていた時に思い出したネタです）

さて、本題。

Oracle DatabaseのSQLチューニングや実行計画の読み方を学び始めたとき、最初に学ぶ（多分）、コストベースオプティマイザが作り出す実行計画に大きく影響を与える初期化パラメータ。
そのパラメータは何か？、
みなさん、パッと思う浮かでしょうか？

_optim_peek_user_binds ってアンダースコアパラメータを思い浮かべた方は居ないはず！（と断言してしまったが、意外と結構居たりして..

それは絶対にないと信じwww、
今日は、 optimizer_mode 初期化パラメータのお話をしてみたいと思います。

冒頭で書いたようにに、 Oracle Database の実行計画やSQLチューニングを学び始めたときに、最初に習う、覚えるのは、このパラメータだったと。思う（私の記憶ではw 私の場合、その最初の頃が昔すぎて怪しい）

それが、
optimizer_modeパラメータです。

この類のパラメータがあるのは Oracle Database だけではないかと思います。
例えば、Hash Join/Merge Joinを無効にして、Nested Loop Joinだけにするなど複数のオプションを組み合わせて似たような挙動にすることはできるものは多いですが、Oracle Databaseのように単一パラメータで、緩めに制御できるのは他にはないと思います。

このパラメータ、むかーーーーーーーーーーーーーーーしからあって、現在の ALL_ROWS/FISRT_ROWS_N というオプションになる前はCHOOSEやRULEというオプションがありました。
これは、Oracle Database 10gリリース1(10.1) 10gR1でルールベースオプティマイザが非サポートとなったタイミングで廃止され、現在この初期化パラメータがサポートしているオプションは以下のようになっています。デフォルトは ALL_ROWS です。

Database / Oracle / Oracle Database / Release 19 / Database Reference / 1.248 OPTIMIZER_MODE https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/OPTIMIZER_MODE.html

OPTIMIZER_MODE = { FIRST_ROWS_[1 | 10 | 100 | 1000] | FIRST_ROWS | ALL_ROWS }

このパラメータのオプションの特徴をざっくり解説してしまうと、
optimizer_mode = ALL_ROWSだとスループットを最大限にする実行計画が選択されます。（一般的にバッチだったり、分析系のSQLの実行計画に向いているのがこのモードで、デフォルトはこれです）
optimizer_mode = FIRST_ROWS_Nに設定した場合、N行の結果を如何に速く返すか、つまり、レスポンスタイムの良さを実現するための実行計画が選択されます。（一般的にはOLTP向きとされる実行計画になります。結合方法として Nested Loop Joinが選ばれやすくなります。全行じゃなくても最初の１行を早くクライアントへ返してあげられるような実行計画になりやすいですのがこのモードです）

ちなみに　FIRST_ROWS は下位互換として残されているだけなので最近では使うことはないです。

ALL_ROWSがデフォルトなので、多くの場合、デフォルトのままで、OLTP系のSQLでは、index scanや、nested loop joinになるようにWHERE句を記述したり、ヒント等で制御したりしているケースが多いのではないでしょうか？
一方、optimizer_mode = first_rows_n　に設定しておき, OLTP向きの実行計画をデフォルトで選択しやすい状況にしているケースもそれなりに見かけます（かなり少ないと思いますが、ちゃんと考えて設定しているという意味では、自分たちのシステムのワークロードで重要なのはどれだ！　認識している証かもしれません。どちらにするかは方針次第ではあるのですが。）

と、ここまでが、ながーーーい前説ですw

今回のタイトル　”先生！、全行アクセスしてるのに、Nested Loop Joinしちゃうんです！” 　

もうお分かりですねw　今日のネタ。

今日の患者さん、 optimizer_mode = first_rows_1 となっている環境で、where句もない結合を伴うクエリーが、Nested Loop Joinで、全行読み込んでしまったことに悩んでいました。
optimizer_mode = first_rows_n という設定になっていることにも気づいてなかったようですね。 all_rows の感覚のままでいると戸惑うのも当然です。

チューニング前に、オプティマイザに影響する初期化パラメータを確認しておくことをお勧めします！！！
チューニングをお願いされた場合、該当する初期化パラメータの設定も一緒に提供してもらう。
セッションレベルで変更されている場合もあるので、それらの情報も提供してもらうことが大切ですよ。忘れないでくださいね。
それらパラメータ情報も、ERに運び込まれた患者SQLを救うには大切な情報なのです！

このケースの場合、治療は非常に簡単で、初期化パラメータ optimizer_mode はそのままで、 ALL_ROWS ヒントを該当SQLに埋め込むのが手っ取り早いと思います。セッションレベルで optimizer_mode = all_rowsにするのもありです。

強力なヒントではないので軽視されがちな初期化パラメータですが、実は、ひょんなことで、その実力に気付いたりするものですwwwwwwww
ただ、ざっくりとした実行計画の傾向を支持するものなので、追加のヒントで矯正したりする必要もあることは忘れないでください。

では、早速、その効力を確認することにします。 21cを利用します。古くても新しくても挙動は同じです、
また、ネタ的に面白いので一時表での挙動も含めています　：）
一時表は統計情報の持ち方等が永続表とは異なるので別の注意が必要です。（参考　津島博士のパフォーマンス講座　第35回　オプティマイザ統計の運用について（２））

統計情報に影響され難い例なので、知っておくと、どこかで役立つと思いますよ！ 多分。:)

---

---

まず、環境と今回の主役となる初期化パラメータの確認から。

optimizer_dynamic_sampling
optimizer_mode
をセッションレベルで制御。ヒント制御しても同じ。
（なお、optimizer_adaptive_plansが発動すると分かりにくくなるので無効化しておきます）

SCOTT@orclpdb1> select banner_full from v$version;

BANNER_FULL
----------------------------------------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0

SCOTT@orclpdb1> show parameter optimizer_mode

NAME                                 TYPE                              VALUE
------------------------------------ --------------------------------- ------------------------------
optimizer_mode                       string                            ALL_ROWS

SCOTT@orclpdb1> show parameter optimizer_dynamic_sampling

NAME                                 TYPE                              VALUE
------------------------------------ --------------------------------- ------------------------------
optimizer_dynamic_sampling           integer                           2

SCOTT@orclpdb1> show parameter optimizer_adaptive_plans

NAME                                 TYPE                              VALUE
------------------------------------ --------------------------------- ------------------------------
optimizer_adaptive_plans             boolean                           TRUE

前提条件は以下の通り。

1. 表には大量のデータが登録されている。
2. 2表をINNNER JOINするが、WHERE句のないクエリー。
3. 統計の無い状態、無いが動的統計有効、それに統計のある状態、それぞれで検証

普通に考えれば、table full scan + Hash Joinが実行計画として選択されるケースですが、、、どうなりますか。ニヤニヤ。（想像できる結果なのでw

一時表での実行計画から確認してみます。

統計情報なし、動的統計取得なし、Adaptive plansも無効です。 データ量、SQL文ではWHERE句による絞り込み条件も無いため、全表走査＋ハッシュ結合となって欲しいケースですが、 first_row_1 と all_rows の違いは如何に。。。

SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

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

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 0;

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

SCOTT@orclpdb1> alter session set optimizer_mode = first_rows_1;

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

SCOTT@orclpdb1> create global temporary table hoge_tmp (id number not null primary key, memo varchar2(100)) on commit preserve rows;

表が作成されました。

SCOTT@orclpdb1> create global temporary table hoge_tmp2 (id number not null primary key, memo varchar2(100)) on commit preserve rows;

表が作成されました。

SCOTT@orclpdb1> select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS
------------------------------ ----------
HOGE_TMP
HOGE_TMP2

SCOTT@orclpdb1> select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS
------------------------------ ------------------------------ ----------
HOGE_TMP                       SYS_C0010733
HOGE_TMP2                      SYS_C0010735

SCOTT@orclpdb1> select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS SCOPE
------------------------------ ---------- ---------------------
HOGE_TMP                                  SHARED
HOGE_TMP2                                 SHARED

SCOTT@orclpdb1> select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS SCOPE
------------------------------ ------------------------------ ---------- ---------------------
HOGE_TMP                       SYS_C0010733                              SHARED
HOGE_TMP2                      SYS_C0010735                              SHARED

SCOTT@orclpdb1> begin for i in 1..100000 loop insert into hoge_tmp values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
  2  /

PL/SQLプロシージャが正常に完了しました。

SCOTT@orclpdb1> begin for i in 1..100000 loop insert into hoge_tmp2 values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
  2  /

PL/SQLプロシージャが正常に完了しました。

SCOTT@orclpdb1> select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS
------------------------------ ----------
HOGE_TMP
HOGE_TMP2

SCOTT@orclpdb1> select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS
------------------------------ ------------------------------ ----------
HOGE_TMP                       SYS_C0010733
HOGE_TMP2                      SYS_C0010735

SCOTT@orclpdb1> select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS SCOPE
------------------------------ ---------- ---------------------
HOGE_TMP                                  SHARED
HOGE_TMP2                                 SHARED

SCOTT@orclpdb1> select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS SCOPE
------------------------------ ------------------------------ ---------- ---------------------
HOGE_TMP                       SYS_C0010733                              SHARED
HOGE_TMP2                      SYS_C0010735                              SHARED

あらびっくり！（知ってたけどw
100,000行の結合がNested Loop Joinになっています。駆動表は Table full scan しちゃってます。って（WHERE句ないのでここは当然ですがw）
問題は、Nested Loop Joinになっている。INDEX UNIQUE SCANを 100,000回ぐるぐる繰り返しているということになります！　まじですw

一時表で統計情報もなくて、動的統計取得も無効されている影響だな！　そう思ったあなた。そういうケースもありますがw
WHERE句もないSQLでNested Loop Joinを選択してしまうのは危険ですよ。(昔は特殊な事情で、それでもこれで行くか〜というレアなこともなくはなかったですがw　最近はほぼないですからね)

（後半で、統計情報なんて関係ねぇってネタをご用意してありますので、長いですがお付き合いくださいw）

SCOTT@orclpdb1> -- 一時表（Global Temporary Table）のセッション固有統計なし
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

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

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 0;

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

SCOTT@orclpdb1> alter session set optimizer_mode = first_rows_1;

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

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

---------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     1 |   130 |     4   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |              |     1 |   130 |     4   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL          | HOGE_TMP     |  8168 |   518K|     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS BY INDEX ROWID| HOGE_TMP2    |     1 |    65 |     1   (0)| 00:00:01 |
|*  4 |    INDEX UNIQUE SCAN         | SYS_C0010735 |     1 |       |     0   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

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

   4 - access("A"."ID"="B"."ID")

統計
----------------------------------------------------------
         25  recursive calls
          0  db block gets
     119340  consistent gets
          0  physical reads
          0  redo size
    2812231  bytes sent via SQL*Net to client
      73378  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

では、 all_rows にして再実行します。他の設定は同じです。
はい、見事に、 Table full scan + Hash Join の実行計画が選択されました！！！！

違いは、first_rows_1 であるか、 all_rows であるかだけです。それだけなんです。

SCOTT@orclpdb1> -- 一時表（Global Temporary Table）のセッション固有統計なし
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

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

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 0;

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

SCOTT@orclpdb1> alter session set optimizer_mode = all_rows;

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

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

--------------------------------------------------------------------------------
| Id  | Operation          | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           |  8168 |  1036K|   150   (3)| 00:00:01 |
|*  1 |  HASH JOIN         |           |  8168 |  1036K|   150   (3)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| HOGE_TMP  |  8168 |   518K|    74   (2)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| HOGE_TMP2 |  8168 |   518K|    74   (2)| 00:00:01 |
--------------------------------------------------------------------------------

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

   1 - access("A"."ID"="B"."ID")

統計
----------------------------------------------------------
         22  recursive calls
          0  db block gets
       9334  consistent gets
          0  physical reads
          0  redo size
    2812231  bytes sent via SQL*Net to client
      73599  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
          3  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

さらに深掘りしてみましょう。
統計情報の有無が影響しないことを確認してみましょう。一時表なので永続表とは異なる統計情報の持ち方になっていることをお忘れなく。でも、大丈夫ですよ。持ってますからw

SCOTT@orclpdb1> -- 一時表（Global Temporary Table）のセッション固有統計取得
SCOTT@orclpdb1> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'HOGE_TMP',cascade=>true,no_invalidate=>false);

PL/SQLプロシージャが正常に完了しました。

SCOTT@orclpdb1> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'HOGE_TMP2',cascade=>true,no_invalidate=>false);

PL/SQLプロシージャが正常に完了しました。

SCOTT@orclpdb1> select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS
------------------------------ ----------
HOGE_TMP
HOGE_TMP2

SCOTT@orclpdb1> select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS
------------------------------ ------------------------------ ----------
HOGE_TMP                       SYS_C0010733
HOGE_TMP2                      SYS_C0010735

SCOTT@orclpdb1> select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS SCOPE
------------------------------ ---------- ---------------------
HOGE_TMP                                  SHARED
HOGE_TMP2                                 SHARED
HOGE_TMP2                          100000 SESSION
HOGE_TMP                           100000 SESSION

SCOTT@orclpdb1> select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS SCOPE
------------------------------ ------------------------------ ---------- ---------------------
HOGE_TMP                       SYS_C0010733                              SHARED
HOGE_TMP2                      SYS_C0010735                              SHARED
HOGE_TMP                       SYS_C0010733                       100000 SESSION
HOGE_TMP2                      SYS_C0010735                       100000 SESSION

一時表のセッション固有統計により駆動表の見積もり行数が、100K 担っている点に注目。大量にデータがヒットすることが、見えていながら、 first_roww_1 という１行目のレスポンスタイムを最短にするため、Nested Loop Joinが行われているます！

統計情報なんて、関係ねぇっ、って感じなのが確認できたので、実は、ほっとしていたりw...

SCOTT@orclpdb1> -- dyamic sampling off
SCOTT@orclpdb1> -- first_rows_1
SCOTT@orclpdb1> -- 一時表（Global Temporary Table）のセッション固有統計あり
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

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

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 0;

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

SCOTT@orclpdb1> alter session set optimizer_mode = first_rows_1;

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

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

---------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     2 |   424 |     5   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |              |     2 |   424 |     5   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL          | HOGE_TMP     |   100K|    10M|     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS BY INDEX ROWID| HOGE_TMP2    |     1 |   106 |     1   (0)| 00:00:01 |
|*  4 |    INDEX UNIQUE SCAN         | SYS_C0010735 |     1 |       |     0   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

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

   4 - access("A"."ID"="B"."ID")

Note
-----
   - Global temporary table session private statistics used

統計
----------------------------------------------------------
          1  recursive calls
          0  db block gets
     115889  consistent gets
          0  physical reads
          0  redo size
    2812231  bytes sent via SQL*Net to client
      73599  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

確認するまでもないですが、 all_rows で他の条件は同一のケースも見てみましょう。
こちらは安定の、table full scan + hash joinのままですね。（予想通りですw）

SCOTT@orclpdb1> -- dyamic sampling off
SCOTT@orclpdb1> -- all_rows
SCOTT@orclpdb1> -- 一時表（Global Temporary Table）のセッション固有統計あり
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

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

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 0;

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

SCOTT@orclpdb1> alter session set optimizer_mode = all_rows;

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

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

----------------------------------------------------------------------------------------
| Id  | Operation          | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           |   100K|    20M|       |  6154   (2)| 00:00:01 |
|*  1 |  HASH JOIN         |           |   100K|    20M|    11M|  6154   (2)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| HOGE_TMP  |   100K|    10M|       |  1110   (2)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| HOGE_TMP2 |   100K|    10M|       |  1110   (2)| 00:00:01 |
----------------------------------------------------------------------------------------

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

   1 - access("A"."ID"="B"."ID")

Note
-----
   - Global temporary table session private statistics used

統計
----------------------------------------------------------
        705  recursive calls
         14  db block gets
      10430  consistent gets
          0  physical reads
          0  redo size
    2812231  bytes sent via SQL*Net to client
      73378  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
        170  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

一時表でもう一つ確認しておきましょう。
一時表（Global Temporary Table）のセッション固有統計なしで、動的統計有効にした場合、 first_rows_1 / all_rows の実行計画はどうなるでしょうか。

一旦、セッションを終了して、一時表を空にします。

SCOTT@orclpdb1> exit
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0との接続が切断されました。
[oracle@localhost ~]$ sqlplus scott@orclpdb1

...略...

SCOTT@orclpdb1> begin for i in 1..100000 loop insert into hoge_tmp values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
  2  /

PL/SQLプロシージャが正常に完了しました。

SCOTT@orclpdb1> begin for i in 1..100000 loop insert into hoge_tmp2 values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
  2  /

PL/SQLプロシージャが正常に完了しました。

SCOTT@orclpdb1> select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS
------------------------------ ----------
HOGE_TMP
HOGE_TMP2

SCOTT@orclpdb1> select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS
------------------------------ ------------------------------ ----------
HOGE_TMP                       SYS_C0010733
HOGE_TMP2                      SYS_C0010735

SCOTT@orclpdb1> select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS SCOPE
------------------------------ ---------- ---------------------
HOGE_TMP                                  SHARED
HOGE_TMP2                                 SHARED

SCOTT@orclpdb1> select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS SCOPE
------------------------------ ------------------------------ ---------- ---------------------
HOGE_TMP                       SYS_C0010733                              SHARED
HOGE_TMP2                      SYS_C0010735                              SHARED

お〜〜〜〜。変化しました〜、動的統計取得で挙動が変わりますね。。。。とはいえ、 Merg Joinです！
実行計画、最悪ですよね。
重いソート処理を回避するために、主キーをindex full scan（主キー順に読み込む）した後に、 Table Access by index rowid ですよ。みなさん！
次に、table access fullの後に、SORT JOIN してます。。consistent getsもこれまでで最も多いですね。どうせなら table full scan + hash join を選んで欲しかったw
とはいえ、optimizer_mode = first_rows_1にするぐらいだから、動的統計って無効化していることも多いので、有効にするまでは気が回らなそうな気もしますね。
いずれにしてもあまり良い設定の相性ではないのは街がないですね。このケースでは。動的統計のレベルによっても変化してより良い実行計画に変化するとは思いますが。（今回の目的ではないのでその確認まではしません）

SCOTT@orclpdb1> -- first_rows_1
SCOTT@orclpdb1> -- 一時表（Global Temporary Table）のセッション固有統計なし
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

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

SCOTT@orclpdb1> alter session set optimizer_mode = first_rows_1;

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

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 2;

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

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

---------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     1 |   130 |   569   (2)| 00:00:01 |
|   1 |  MERGE JOIN                  |              |     1 |   130 |   569   (2)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| HOGE_TMP2    | 97069 |  6161K|     3   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | SYS_C0010735 |     2 |       |     2   (0)| 00:00:01 |
|*  4 |   SORT JOIN                  |              | 95480 |  6060K|   566   (2)| 00:00:01 |
|   5 |    TABLE ACCESS FULL         | HOGE_TMP     | 95480 |  6060K|   566   (2)| 00:00:01 |
---------------------------------------------------------------------------------------------

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

   4 - access("A"."ID"="B"."ID")
       filter("A"."ID"="B"."ID")

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)

統計
----------------------------------------------------------
         23  recursive calls
          0  db block gets
      19853  consistent gets
          0  physical reads
          0  redo size
    2812231  bytes sent via SQL*Net to client
      73378  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

同じ条件で、 all_rows に変えてみましょう。おそらくいい感じになるのではないでしょうか（これまで同様に）

SCOTT@orclpdb1> -- all_rows
SCOTT@orclpdb1> -- 一時表（Global Temporary Table）のセッション固有統計なし
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

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

SCOTT@orclpdb1> alter session set optimizer_mode = all_rows;

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

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 2;

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

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

----------------------------------------------------------------------------------------
| Id  | Operation          | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           | 95481 |    11M|       |  4699   (2)| 00:00:01 |
|*  1 |  HASH JOIN         |           | 95481 |    11M|  7184K|  4699   (2)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| HOGE_TMP  | 95480 |  6060K|       |  1109   (2)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| HOGE_TMP2 | 97069 |  6161K|       |  1110   (2)| 00:00:01 |
----------------------------------------------------------------------------------------

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

   1 - access("A"."ID"="B"."ID")

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)

統計
----------------------------------------------------------
         13  recursive calls
          0  db block gets
       9426  consistent gets
          0  physical reads
          0  redo size
    2812231  bytes sent via SQL*Net to client
      73599  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off
SCOTT@orclpdb1> exit

最後に、永続表での実行計画も確認しておきます。

SCOTT@orclpdb1> drop table hoge_tmp purge;

表が削除されました。

SCOTT@orclpdb1> drop table hoge_tmp2 purge;

表が削除されました。

SCOTT@orclpdb1> create table hoge_tmp (id number not null primary key, memo varchar2(100));

表が作成されました。

SCOTT@orclpdb1> create table hoge_tmp2 (id number not null primary key, memo varchar2(100));
  2  /

PL/SQLプロシージャが正常に完了しました。

SCOTT@orclpdb1> begin for i in 1..100000 loop insert into hoge_tmp2 values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
  2  /

PL/SQLプロシージャが正常に完了しました。

SCOTT@orclpdb1> select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS
------------------------------ ----------
HOGE_TMP
HOGE_TMP2

SCOTT@orclpdb1> select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS
------------------------------ ------------------------------ ----------
HOGE_TMP                       SYS_C0010737
HOGE_TMP2                      SYS_C0010739

SCOTT@orclpdb1> select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS SCOPE
------------------------------ ---------- ---------------------
HOGE_TMP                                  SHARED
HOGE_TMP2                                 SHARED

SCOTT@orclpdb1> select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS SCOPE
------------------------------ ------------------------------ ---------- ---------------------
HOGE_TMP                       SYS_C0010737                              SHARED
HOGE_TMP2                      SYS_C0010739                              SHARED

永続表のケースで、統計なし、動的統計オフで、first_rows_1の場合は、一時表と同様に駆動表を全表走査した上で、Nested Loop Joinしています。first_rows_1の影響をそのまま受けています。

SCOTT@orclpdb1> -- first_rows_1
SCOTT@orclpdb1> -- 統計なし
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

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

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 0;

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

SCOTT@orclpdb1> alter session set optimizer_mode = first_rows_1;

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

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

---------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     1 |   130 |     4   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |              |     1 |   130 |     4   (0)| 00:00:01 |
|   2 |   NESTED LOOPS               |              |     1 |   130 |     4   (0)| 00:00:01 |
|   3 |    TABLE ACCESS FULL         | HOGE_TMP     |    82 |  5330 |     3   (0)| 00:00:01 |
|*  4 |    INDEX UNIQUE SCAN         | SYS_C0010739 |     1 |       |     0   (0)| 00:00:01 |
|   5 |   TABLE ACCESS BY INDEX ROWID| HOGE_TMP2    |     1 |    65 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

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

   4 - access("A"."ID"="B"."ID")

統計
----------------------------------------------------------
         84  recursive calls
         23  db block gets
     126963  consistent gets
        231  physical reads
       4336  redo size
    2812231  bytes sent via SQL*Net to client
      73378  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
         13  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

他の条件は同じで、 all_rows に変更した場合同様に、全表走査＋ハッシュ結合（いいですねぇ。バッチ処理ならこれが一番良いですね。

SCOTT@orclpdb1> -- all_rows
SCOTT@orclpdb1> -- 統計なし
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

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

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 0;

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

SCOTT@orclpdb1> alter session set optimizer_mode = all_rows;

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

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

--------------------------------------------------------------------------------
| Id  | Operation          | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           |    82 | 10660 |     6   (0)| 00:00:01 |
|*  1 |  HASH JOIN         |           |    82 | 10660 |     6   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| HOGE_TMP  |    82 |  5330 |     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| HOGE_TMP2 |    82 |  5330 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------

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

   1 - access("A"."ID"="B"."ID")

統計
----------------------------------------------------------
        189  recursive calls
          5  db block gets
       9700  consistent gets
          1  physical reads
        184  redo size
    2812231  bytes sent via SQL*Net to client
      73599  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
         28  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

永続表、統計情報なし、動的統計取得有効、first_rows_1。一時表同様の結果です。永続表と一時表による違いは無さそうですね。これはNLJより避けたいw

SCOTT@orclpdb1> -- first_rows_1
SCOTT@orclpdb1> -- 統計なし
SCOTT@orclpdb1> -- 動的統計有効
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

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

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 2;

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

SCOTT@orclpdb1> alter session set optimizer_mode = first_rows_1;

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

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

---------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     1 |   130 |   795   (2)| 00:00:01 |
|   1 |  MERGE JOIN                  |              |     1 |   130 |   795   (2)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| HOGE_TMP     |   124K|  7911K|     3   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | SYS_C0010737 |     2 |       |     2   (0)| 00:00:01 |
|*  4 |   SORT JOIN                  |              | 92574 |  5876K|   792   (2)| 00:00:01 |
|   5 |    TABLE ACCESS FULL         | HOGE_TMP2    | 92574 |  5876K|   792   (2)| 00:00:01 |
---------------------------------------------------------------------------------------------

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

   4 - access("A"."ID"="B"."ID")
       filter("A"."ID"="B"."ID")

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)

統計
----------------------------------------------------------
        181  recursive calls
         26  db block gets
      16729  consistent gets
        182  physical reads
        140  redo size
    2812231  bytes sent via SQL*Net to client
      73599  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
         24  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

永続表、統計情報なし、動的統計取得有効、all_rowsも、一時表のケースと同様。安定して、全表走査＋ハッシュ結合が行われています。 all_rows にするべきSQLですからね。

SCOTT@orclpdb1> -- all_rows
SCOTT@orclpdb1> -- 統計なし
SCOTT@orclpdb1> -- 動的統計有効
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

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

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 2;

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

SCOTT@orclpdb1> alter session set optimizer_mode = all_rows;

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

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

----------------------------------------------------------------------------------------
| Id  | Operation          | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           | 92574 |    11M|       |  5148   (2)| 00:00:01 |
|*  1 |  HASH JOIN         |           | 92574 |    11M|  6968K|  5148   (2)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| HOGE_TMP2 | 92574 |  5876K|       |  1173   (2)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| HOGE_TMP  |   124K|  7911K|       |  1177   (2)| 00:00:01 |
----------------------------------------------------------------------------------------

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

   1 - access("A"."ID"="B"."ID")

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)

統計
----------------------------------------------------------
         32  recursive calls
          0  db block gets
       9438  consistent gets
          0  physical reads
          0  redo size
    2812231  bytes sent via SQL*Net to client
      73378  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
          3  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

いよいよ最後、動的統計取得を無効化して、静的統計による挙動を確認します。

SCOTT@orclpdb1> -- 統計取得
SCOTT@orclpdb1> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'HOGE_TMP',cascade=>true,no_invalidate=>false);

PL/SQLプロシージャが正常に完了しました。

SCOTT@orclpdb1> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'HOGE_TMP2',cascade=>true,no_invalidate=>false);

PL/SQLプロシージャが正常に完了しました。

SCOTT@orclpdb1> select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS
------------------------------ ----------
HOGE_TMP                           100000
HOGE_TMP2                          100000

SCOTT@orclpdb1> select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS
------------------------------ ------------------------------ ----------
HOGE_TMP                       SYS_C0010737                       100000
HOGE_TMP2                      SYS_C0010739                       100000

SCOTT@orclpdb1> select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                       NUM_ROWS SCOPE
------------------------------ ---------- ---------------------
HOGE_TMP                           100000 SHARED
HOGE_TMP2                          100000 SHARED

SCOTT@orclpdb1> select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

TABLE_NAME                     INDEX_NAME                       NUM_ROWS SCOPE
------------------------------ ------------------------------ ---------- ---------------------
HOGE_TMP                       SYS_C0010737                       100000 SHARED
HOGE_TMP2                      SYS_C0010739                       100000 SHARED

統計情報あり、動的統計有効ですが、動作しないはずですね。統計情報は最新ですし。 first_rows_1では期待した結果（良いという意味ではないw）が得られています。
駆動表を全表走査してNested Loop Joinが行われています。動的統計取得の副作用で、Merge Joinになることもなかったようですね。

SCOTT@orclpdb1> -- 統計あり
SCOTT@orclpdb1> -- 動的統計有効
SCOTT@orclpdb1> alter session set optimizer_adaptive_plans = false;

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

SCOTT@orclpdb1> alter session set optimizer_dynamic_sampling = 2;

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

SCOTT@orclpdb1> alter session set optimizer_mode = first_rows_1;

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

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;

100000行が選択されました。

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

---------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     2 |   424 |     5   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |              |     2 |   424 |     5   (0)| 00:00:01 |
|   2 |   NESTED LOOPS               |              |     2 |   424 |     5   (0)| 00:00:01 |
|   3 |    TABLE ACCESS FULL         | HOGE_TMP     |   100K|    10M|     3   (0)| 00:00:01 |
|*  4 |    INDEX UNIQUE SCAN         | SYS_C0010739 |     1 |       |     0   (0)| 00:00:01 |
|   5 |   TABLE ACCESS BY INDEX ROWID| HOGE_TMP2    |     1 |   106 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

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

   4 - access("A"."ID"="B"."ID")

統計
----------------------------------------------------------
          5  recursive calls
          0  db block gets
     126786  consistent gets
          0  physical reads
          0  redo size
    2812231  bytes sent via SQL*Net to client
      73599  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orclpdb1> set autot off

同一条件で、 all_rows の場合です。こちらも想定通り、全表走査＋ハッシュ結合になっています。

最後に、 optimizer_mode をチューニングのゴールに合わせて、バッチ、分析系、そして、OLTPと、
all_rows または、first_rows_n　のいずれか正しく設定することも想定外の実行計画を防ぐことに役立つか、お分かりいただけたのではないでしょうか？
効果の薄い機能ではなく、重要な役目をもつ、 optimizer_mode、お忘れなく。ヒントでも使えます。状況に合わせて使い分けることをお勧めします:)

おまけ 昔、OTHER_XML列からOUTLINEを取り出すなんてネタ書いてましたが、しっかりと、optimizer_modeに対応するヒントが含まれています。
OTHER_XMLの中身 / Mac De Oracle / 2015年12月 4日 (金) https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2015/12/other_xml-7f15.html

では、また。

良いお年をお迎えください。

Enjoy! SQL and Optimizer Features! ：）

---

---

今回利用したSQLなど

alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 0;
alter session set optimizer_mode = first_rows_1;


create global temporary table hoge_tmp (id number not null primary key, memo varchar2(100)) on commit preserve rows;
create global temporary table hoge_tmp2 (id number not null primary key, memo varchar2(100)) on commit preserve rows;


select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

begin for i in 1..100000 loop insert into hoge_tmp values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
/
begin for i in 1..100000 loop insert into hoge_tmp2 values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
/


select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

-- 一時表（Global Temporary Table）のセッション固有統計なし
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 0;
alter session set optimizer_mode = first_rows_1;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off

-- 一時表（Global Temporary Table）のセッション固有統計なし
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 0;
alter session set optimizer_mode = all_rows;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off


-- 一時表（Global Temporary Table）のセッション固有統計取得
exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'HOGE_TMP',cascade=>true,no_invalidate=>false);
exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'HOGE_TMP2',cascade=>true,no_invalidate=>false);

select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

-- dyamic sampling off
-- first_rows_1
-- 一時表（Global Temporary Table）のセッション固有統計あり
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 0;
alter session set optimizer_mode = first_rows_1;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off

-- dyamic sampling off
-- all_rows
-- 一時表（Global Temporary Table）のセッション固有統計あり
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 0;
alter session set optimizer_mode = all_rows;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off



+++　一時表（Global Temporary Table）のセッション固有統計なしで、動的統計有効　+++

alter session set optimizer_adaptive_plans = false;
alter session set optimizer_mode = first_rows_1;
alter session set optimizer_dynamic_sampling = 2;

select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');


begin for i in 1..100000 loop insert into hoge_tmp values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
/
begin for i in 1..100000 loop insert into hoge_tmp2 values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
/


select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');


-- first_rows_1
-- 一時表（Global Temporary Table）のセッション固有統計なし
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_mode = first_rows_1;
alter session set optimizer_dynamic_sampling = 2;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off


-- all_rows
-- 一時表（Global Temporary Table）のセッション固有統計なし
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_mode = all_rows;
alter session set optimizer_dynamic_sampling = 2;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off




--パーマネント表でも同じ

alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 0;
alter session set optimizer_mode = first_rows_1;


create table hoge_tmp (id number not null primary key, memo varchar2(100));
create table hoge_tmp2 (id number not null primary key, memo varchar2(100));


select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

begin for i in 1..100000 loop insert into hoge_tmp values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
/
begin for i in 1..100000 loop insert into hoge_tmp2 values(i,lpad('x',100,'x')); if mod(i,1000) = 0 then commit; end if; end loop; end;
/


select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');


-- first_rows_1
-- 統計なし
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 0;
alter session set optimizer_mode = first_rows_1;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off

-- all_rows
-- 統計なし
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 0;
alter session set optimizer_mode = all_rows;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off


-- first_rows_1
-- 統計なし
-- 動的統計有効
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 2;
alter session set optimizer_mode = first_rows_1;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off


-- all_rows
-- 統計なし
-- 動的統計有効
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 2;
alter session set optimizer_mode = all_rows;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off


-- 統計取得
exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'HOGE_TMP',cascade=>true,no_invalidate=>false);
exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'HOGE_TMP2',cascade=>true,no_invalidate=>false);

select table_name,num_rows from user_tables where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows from user_indexes where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,num_rows,scope from user_tab_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');
select table_name,index_name,num_rows,scope from user_ind_statistics where table_name in ('HOGE_TMP','HOGE_TMP2');

-- first_rows_1
-- 統計あり
-- 動的統計有効
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 2;
alter session set optimizer_mode = first_rows_1;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off


-- all_rows
-- 統計あり
-- 動的統計有効
alter session set optimizer_adaptive_plans = false;
alter session set optimizer_dynamic_sampling = 2;
alter session set optimizer_mode = all_rows;
set autot trace exp stat
select * from hoge_tmp a inner join hoge_tmp2 b on a.id = b.id;
set autot off

実行計画は, SQL文のレントゲン写真だ！ Oracle Database (全部俺）Advent Calendar 2022 / No.61 / ANSI JOINのおまけのおまけ

年を跨いで, ”実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 / No.61 / ANSI JOINのおまけ”のおまけです.

前回の投稿から間隔が空いていたので, まずは, 簡単な復習から.

ANSI構文のON句の結合条件でORが利用されているという, スーパータイプ, サブタイプテーブルの実装崩れというか, 大人の事情に押し切られて負けた感じありありの半端な状態.
あ, そうだ, Oralceの外部結合だとOR使えないけど, ANSIなら使えるじゃん！
という流れを感じるSQL文を, Oracleのオプティマイザは, LATERALへの書き換え(VW_LAT_E87C3AAF)や, OR EXPANDの書き換え(VW_ORE_FDF394AE)を駆使して, 物凄い最適化を行っていました.

この例では, 外部表, 内部表の多重度は, 1:0..1. かつ, スーパータイプ, サブタイプでいうところの不完全なサブタイプ.
さらに, 内部表は, 単純にニコイチにしただけのようなサブタイプテーブルで外部表との結合列が2列（おそらく本来同一列に統合されていただろう. . と思われる）ある. 惜しい！という感じのモデル.
比較的軽度のモデリング障害ではあるので, このまま使うのであれば, LATERAL変換されるのを避けるような書き換え, 比較的単純な HASH JOIN なるようにすればそこそこ改善できそうな感じはしますよね（いわゆるTemp落ちはある程度発生する前提で）

なお, この例で AUTO TRACEでの実行時間と, SQL MONITORの実行時間（DB内部）に差異があることに気づいた方もいると思いますが. これ, クライアントがデータをFETCHしている時間ですね. 行数が多いので. SQL*Plusの場合, デフォルトのFETCH SIZEが15なので行数が多いと, FETCHの際, サーバーからの受信で時間がかかります.
（この症状は以前, 高フェッチ圧症として紹介したこともあるので, 覚えている方も多いのではないかと思います. この例では1行の行サイズも大きめかつ, 行数も多めにして SELECT * にしているのでそこそこ目立つ時間になるようにしています. これも別のエントリーでネタにするための仕込みではあるのですが, 今回の記事では気にしないでください. SQLモニターのサーバー内部での純粋な処理時間だけで, 書き換え前後での差を見て行きます！）

SCOTT@orclpdb1> @dayx
  1  SELECT *
  2  FROM
  3    supertype st
  4    LEFT OUTER JOIN nikoichi_mitaina_subtype nmst
  5    ON
  6      st.pkey = nmst.col1
  7*     OR st.pkey = nmst.col2

10001行が選択されました. 

経過: 00:00:01.41

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

-------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |                          | 20002 |    20M| 40226   (1)| 00:00:02 |
|   1 |  MERGE JOIN OUTER                |                          | 20002 |    20M| 40226   (1)| 00:00:02 |
|   2 |   TABLE ACCESS FULL              | SUPERTYPE                | 10001 |  4971K|   204   (0)| 00:00:01 |
|   3 |   BUFFER SORT                    |                          |     2 |  1082 | 40021   (1)| 00:00:02 |
|   4 |    VIEW                          | VW_LAT_E87C3AAF          |     2 |  1082 |     4   (0)| 00:00:01 |
|   5 |     VIEW                         | VW_ORE_FDF394AE          |     2 |  1082 |     4   (0)| 00:00:01 |
|   6 |      UNION-ALL                   |                          |       |       |            |          |
|   7 |       TABLE ACCESS BY INDEX ROWID| NIKOICHI_MITAINA_SUBTYPE |     1 |  1009 |     2   (0)| 00:00:01 |
|*  8 |        INDEX UNIQUE SCAN         | UK1                      |     1 |       |     1   (0)| 00:00:01 |
|*  9 |       TABLE ACCESS BY INDEX ROWID| NIKOICHI_MITAINA_SUBTYPE |     1 |  1009 |     2   (0)| 00:00:01 |
|* 10 |        INDEX UNIQUE SCAN         | UK2                      |     1 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------

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

   8 - access("ST"."PKEY"="NMST"."COL1")
       filter("NMST"."COL1" IS NOT NULL)
   9 - filter(LNNVL("ST"."PKEY"="NMST"."COL1"))
  10 - access("ST"."PKEY"="NMST"."COL2")
       filter("NMST"."COL2" IS NOT NULL)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      32231  consistent gets
          0  physical reads
          0  redo size
   15493776  bytes sent via SQL*Net to client　(別エントリ向け)
       7378  bytes received via SQL*Net from client
        668  SQL*Net roundtrips to/from client (別エントリ向け)
      10001  sorts (memory)
          0  sorts (disk)
      10001  rows processed


  1  SELECT /*+ MONITOR */ *
  2  FROM
  3    supertype st
  4    LEFT OUTER JOIN nikoichi_mitaina_subtype nmst
  5    ON
  6      st.pkey = nmst.col1
  7*     OR st.pkey = nmst.col2

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT')
--------------------------------------------------------------------------------------------------------------------------------------
SQL Monitoring Report

SQL Text
------------------------------
SELECT /*+ MONITOR */ * FROM supertype st LEFT OUTER JOIN nikoichi_mitaina_subtype nmst ON st.pkey = nmst.col1 OR st.pkey = nmst.col2

Global Information
------------------------------
 Status              :  DONE (ALL ROWS)

 ...略...

 Duration            :  3s（別ネタ向け仕込み）

 ...略...

Global Stats
=================================================
| Elapsed |   Cpu   |  Other   | Fetch | Buffer |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  |
=================================================
|    0.37 |    0.31 |     0.06 |   668 |  32231 |
=================================================

SQL Plan Monitoring Details (Plan Hash Value=2133431102)
=====================================================================================================================================================================
| Id |             Operation              |           Name           |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   |  Mem  | Activity | Activity Detail |
|    |                                    |                          | (Estim) |       | Active(s) | Active |       | (Actual) | (Max) |   (%)    |   (# samples)   |
=====================================================================================================================================================================
|  0 | SELECT STATEMENT                   |                          |         |       |         4 |     +0 |     1 |    10001 |     . |          |                 |
|  1 |   MERGE JOIN OUTER                 |                          |   20002 | 40226 |         4 |     +0 |     1 |    10001 |     . |          |                 |
|  2 |    TABLE ACCESS FULL               | SUPERTYPE                |   10001 |   204 |         4 |     +0 |     1 |    10001 |     . |          |                 |
|  3 |    BUFFER SORT                     |                          |       2 | 40021 |         4 |     +0 | 10001 |    10000 |  2048 |          |                 |
|  4 |     VIEW                           | VW_LAT_E87C3AAF          |       2 |     4 |         4 |     +0 | 10001 |    10000 |     . |          |                 |
|  5 |      VIEW                          | VW_ORE_FDF394AE          |       2 |     4 |         4 |     +0 | 10001 |    10000 |     . |          |                 |
|  6 |       UNION-ALL                    |                          |         |       |         4 |     +0 | 10001 |    10000 |     . |          |                 |
|  7 |        TABLE ACCESS BY INDEX ROWID | NIKOICHI_MITAINA_SUBTYPE |       1 |     2 |         4 |     +0 | 10001 |     5000 |     . |          |                 |
|  8 |         INDEX UNIQUE SCAN          | UK1                      |       1 |     1 |         4 |     +0 | 10001 |     5000 |     . |          |                 |
|  9 |        TABLE ACCESS BY INDEX ROWID | NIKOICHI_MITAINA_SUBTYPE |       1 |     2 |         4 |     +0 | 10001 |     5000 |     . |          |                 |
| 10 |         INDEX UNIQUE SCAN          | UK2                      |       1 |     1 |         4 |     +0 | 10001 |     5000 |     . |          |                 |
=====================================================================================================================================================================

では, 書き換えて, LATERAL変換を避け, HASH JOINになるようにしてみましょう. (WITH句を利用していますが, 再利用ではなく読みやすさ狙いです. Oracleもそれを理解できるのでインラインビューとして扱われます)
今回のようなデータモデル障害の場合は, 治療もシンプルで良いのですがw（例に取り上げるのがメンドクサイやつだと, 解説するのもメンドクサイし良いことないので）

現場どのようになっているかを理解する必要があります. この例では, col1列とcol2列は実は同一列で良いだろうということになるので, 以下のように書き換えれば, JOIN ON ... OR　なんて現時点のオプティマイザでは, ほぼ危険な感じしかしない実行計画になるようなSQLへの書き換えも回避できるのではないでしょうか？
結果は見ての通り, 別エントリ向けの仕込みであるFETCH時間を除いたデータベース内部のみの処理時間は, 0.37sec から 0.15secと62%ほど改善しています（ただ, このデータ量で私の環境だとPGA内に収まっているのでTemp落ちの影響は見えないですね. オンメモリなら勝ちは確実ですが）

  1  WITH
  2  t1 AS
  3  (
  4    SELECT
  5      pkey
  6      , CASE
  7          WHEN col2 IS NULL
  8            THEN col1
  9            ELSE col2
 10      END AS join_key
 11      ,description
 12    FROM
 13      nikoichi_mitaina_subtype
 14    WHERE
 15      col1 IS NOT NULL
 16      OR col2 IS NOT NULL
 17  )
 18  SELECT *
 19  FROM
 20    supertype st
 21    LEFT OUTER JOIN t1
 22    ON
 23*     st.pkey = t1.join_key

10001行が選択されました. 

経過: 00:00:01.28

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

-------------------------------------------------------------------------------------------------------
| Id  | Operation          | Name                     | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                          | 10001 |    14M|       |  1224   (1)| 00:00:01 |
|*  1 |  HASH JOIN OUTER   |                          | 10001 |    14M|  5096K|  1224   (1)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| SUPERTYPE                | 10001 |  4971K|       |   204   (0)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| NIKOICHI_MITAINA_SUBTYPE |  7500 |  7390K|       |   410   (1)| 00:00:01 |
-------------------------------------------------------------------------------------------------------

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

   1 - access("ST"."PKEY"=CASE  WHEN (ROWID(+) IS NOT NULL) THEN CASE  WHEN ("COL2"(+) IS
              NULL) THEN "COL1"(+) ELSE "COL2"(+) END  ELSE NULL END )
   3 - filter("COL1"(+) IS NOT NULL OR "COL2"(+) IS NOT NULL)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       2748  consistent gets
          0  physical reads
          0  redo size
   15483707  bytes sent via SQL*Net to client（別ネタ向け仕込み）
       7378  bytes received via SQL*Net from client
        668  SQL*Net roundtrips to/from client（別ネタ向け仕込み）
          0  sorts (memory)
          0  sorts (disk)
      10001  rows processed


  1  WITH
  2  t1 AS
  3  (
  4    SELECT
  5      pkey
  6      , CASE
  7          WHEN col2 IS NULL
  8            THEN col1
  9            ELSE col2
 10      END AS join_key
 11      ,description
 12    FROM
 13      nikoichi_mitaina_subtype
 14    WHERE
 15      col1 IS NOT NULL
 16      OR col2 IS NOT NULL
 17  )
 18  SELECT /*+ MONITOR */ *
 19  FROM
 20    supertype st
 21    LEFT OUTER JOIN t1
 22    ON
 23*     st.pkey = t1.join_key

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT')
----------------------------------------------------------------------------------------------------------------
SQL Monitoring Report

SQL Text
------------------------------
WITH t1 AS ( SELECT pkey , CASE WHEN col2 IS NULL THEN col1 ELSE col2 END AS join_key ,description
FROM nikoichi_mitaina_subtype WHERE col1 IS NOT NULL OR col2 IS NOT NULL ) SELECT /*+ MONITOR */ *
FROM supertype st LEFT OUTER JOIN t1 ON st.pkey = t1.join_key

Global Information
------------------------------
 Status              :  DONE (ALL ROWS)

 ...略...

 Duration            :  2s（別ネタ向け仕込み）

 ...略...

Global Stats
=================================================
| Elapsed |   Cpu   |  Other   | Fetch | Buffer |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  |
=================================================
|    0.15 |    0.13 |     0.02 |   668 |   2748 |
=================================================

SQL Plan Monitoring Details (Plan Hash Value=2223315184)
======================================================================================================================================================
| Id |      Operation       |           Name           |  Rows   | Cost |   Time    | Start  | Execs |   Rows   |  Mem  | Activity | Activity Detail |
|    |                      |                          | (Estim) |      | Active(s) | Active |       | (Actual) | (Max) |   (%)    |   (# samples)   |
======================================================================================================================================================
|  0 | SELECT STATEMENT     |                          |         |      |         3 |     +0 |     1 |    10001 |     . |          |                 |
|  1 |   HASH JOIN OUTER    |                          |   10001 | 1224 |         3 |     +0 |     1 |    10001 |   7MB |          |                 |
|  2 |    TABLE ACCESS FULL | SUPERTYPE                |   10001 |  204 |         1 |     +0 |     1 |    10001 |     . |          |                 |
|  3 |    TABLE ACCESS FULL | NIKOICHI_MITAINA_SUBTYPE |    7500 |  410 |         3 |     +0 |     1 |    10000 |     . |          |                 |
======================================================================================================================================================

将来のデータ量が100倍だとして. . . . HASH JOIN化してTemp落ちの影響も含めて見ておきましょう

SCOTT@orclpdb1> @dayx-1
  1* DROP TABLE supertype

表が削除されました. 

経過: 00:00:00.47
  1  CREATE TABLE supertype
  2  (
  3    pkey NUMBER PRIMARY KEY
  4    , attr1 NUMBER NOT NULL
  5    , attr2 NUMBER NOT NULL
  6    , note VARCHAR2(500)
  7* )

表が作成されました. 

経過: 00:00:00.15
  1* DROP TABLE nikoichi_mitaina_subtype

表が削除されました. 

経過: 00:00:00.05
  1  CREATE TABLE nikoichi_mitaina_subtype
  2  (
  3    pkey NUMBER PRIMARY KEY
  4    , col1 NUMBER
  5    , col2 NUMBER
  6    , description VARCHAR2(1000)
  7    , CONSTRAINT uk1 unique (col1) USING INDEX
  8    , CONSTRAINT uk2 unique (col2) USING INDEX
  9* )

表が作成されました. 

経過: 00:00:00.03
  1  DECLARE
  2    cMAX_ROWS CONSTANT NUMBER := 1000000;
  3  BEGIN
  4    FOR i IN 1..cMAX_ROWS LOOP
  5      INSERT INTO supertype VALUES(i,0,0,LPAD(i,500,'*'));
  6      INSERT INTO nikoichi_mitaina_subtype VALUES(
  7        i
  8        , CASE WHEN MOD(i,2) = 0 THEN i ELSE null END
  9        , CASE WHEN MOD(i,2) = 1 THEN i ELSE null END
 10        , LPAD(i,1000,'*')
 11      );
 12      IF MOD(i,100) = 0 THEN COMMIT; END IF;
 13    END LOOP;
 14    INSERT INTO supertype VALUES(cMAX_ROWS+1,0,0,null);
 15    COMMIT;
 16    DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT',tabname=>'SUPERTYPE',no_invalidate=>false,cascade=>true);
 17    DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT',tabname=>'NIKOICHI_MITAINA_SUBTYPE',no_invalidate=>false,cascade=>true);
 18* END;

PL/SQLプロシージャが正常に完了しました. 

経過: 00:04:37.66

まず元ネタのLATERALとOR EXPAND書き換えされている方はどうか. . SQLモニターのExecが綺麗に増加（当然ですが）

SCOTT@orclpdb1> @dayx
  1  SELECT *
  2  FROM
  3    supertype st
  4    LEFT OUTER JOIN nikoichi_mitaina_subtype nmst
  5    ON
  6      st.pkey = nmst.col1
  7*     OR st.pkey = nmst.col2

1000001行が選択されました. 

経過: 00:02:23.03

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

-------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |                          |  2000K|  2004M|  6022K  (1)| 00:03:56 |
|   1 |  MERGE JOIN OUTER                |                          |  2000K|  2004M|  6022K  (1)| 00:03:56 |
|   2 |   TABLE ACCESS FULL              | SUPERTYPE                |  1000K|   486M| 19524   (1)| 00:00:01 |
|   3 |   BUFFER SORT                    |                          |     2 |  1082 |  6002K  (1)| 00:03:55 |
|   4 |    VIEW                          | VW_LAT_E87C3AAF          |     2 |  1082 |     6   (0)| 00:00:01 |
|   5 |     VIEW                         | VW_ORE_FDF394AE          |     2 |  1082 |     6   (0)| 00:00:01 |
|   6 |      UNION-ALL                   |                          |       |       |            |          |
|   7 |       TABLE ACCESS BY INDEX ROWID| NIKOICHI_MITAINA_SUBTYPE |     1 |  1012 |     3   (0)| 00:00:01 |
|*  8 |        INDEX UNIQUE SCAN         | UK1                      |     1 |       |     2   (0)| 00:00:01 |
|*  9 |       TABLE ACCESS BY INDEX ROWID| NIKOICHI_MITAINA_SUBTYPE |     1 |  1012 |     3   (0)| 00:00:01 |
|* 10 |        INDEX UNIQUE SCAN         | UK2                      |     1 |       |     2   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------

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

   8 - access("ST"."PKEY"="NMST"."COL1")
       filter("NMST"."COL1" IS NOT NULL)
   9 - filter(LNNVL("ST"."PKEY"="NMST"."COL1"))
  10 - access("ST"."PKEY"="NMST"."COL2")
       filter("NMST"."COL2" IS NOT NULL)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
    3561836  consistent gets
      71485  physical reads
          0  redo size
 1552273780  bytes sent via SQL*Net to client（別ネタ向け仕込み）
     734925  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client（別ネタ向け仕込み）
    1000001  sorts (memory)
          0  sorts (disk)
    1000001  rows processed


  1  SELECT /*+ MONITOR */ *
  2  FROM
  3    supertype st
  4    LEFT OUTER JOIN nikoichi_mitaina_subtype nmst
  5    ON
  6      st.pkey = nmst.col1
  7*     OR st.pkey = nmst.col2

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT')
-----------------------------------------------------------------------------------------
SQL Monitoring Report

SQL Text
------------------------------
SELECT /*+ MONITOR */ * FROM supertype st LEFT OUTER JOIN nikoichi_mitaina_subtype nmst
ON st.pkey = nmst.col1 OR st.pkey = nmst.col2

Global Information
------------------------------
 Status              :  DONE (ALL ROWS)

 ...略...

 Duration            :  219s（別ネタ向け仕込み）

 ...略...

Global Stats
===========================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
===========================================================================
|      37 |      32 |     0.22 |     4.20 | 66668 |     4M |  573 | 558MB |
===========================================================================

SQL Plan Monitoring Details (Plan Hash Value=2133431102)
====================================================================================================================================================================================
| Id |             Operation              |           Name           |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity | Activity Detail |
|    |                                    |                          | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |   (# samples)   |
====================================================================================================================================================================================
|  0 | SELECT STATEMENT                   |                          |         |       |       220 |     +0 |     1 |       1M |      |       |     . |          |                 |
|  1 |   MERGE JOIN OUTER                 |                          |      2M |    6M |       220 |     +0 |     1 |       1M |      |       |     . |     6.90 | Cpu (2)         |
|  2 |    TABLE ACCESS FULL               | SUPERTYPE                |      1M | 19524 |       220 |     +0 |     1 |       1M |  573 | 558MB |     . |    10.34 | Cpu (3)         |
|  3 |    BUFFER SORT                     |                          |       2 |    6M |       220 |     +0 |    1M |       1M |      |       |  2048 |    17.24 | Cpu (5)         |
|  4 |     VIEW                           | VW_LAT_E87C3AAF          |       2 |     6 |       220 |     +0 |    1M |       1M |      |       |     . |          |                 |
|  5 |      VIEW                          | VW_ORE_FDF394AE          |       2 |     6 |       220 |     +0 |    1M |       1M |      |       |     . |          |                 |
|  6 |       UNION-ALL                    |                          |         |       |       220 |     +0 |    1M |       1M |      |       |     . |     6.90 | Cpu (2)         |
|  7 |        TABLE ACCESS BY INDEX ROWID | NIKOICHI_MITAINA_SUBTYPE |       1 |     3 |       220 |     +0 |    1M |     500K |      |       |     . |          |                 |
|  8 |         INDEX UNIQUE SCAN          | UK1                      |       1 |     2 |       220 |     +0 |    1M |     500K |      |       |     . |    17.24 | Cpu (5)         |
|  9 |        TABLE ACCESS BY INDEX ROWID | NIKOICHI_MITAINA_SUBTYPE |       1 |     3 |       220 |     +0 |    1M |     500K |      |       |     . |          |                 |
| 10 |         INDEX UNIQUE SCAN          | UK2                      |       1 |     2 |       220 |     +0 |    1M |     500K |      |       |     . |     6.90 | Cpu (2)         |
====================================================================================================================================================================================

LATERAL変換を避け, HASH JOINにしてくれるような書き換えを行った方はどうかというと.
やはり, PGA内に収まっていたHASH JOINと比較して, Temp落ち（1GBほど）の影響で改善幅は減っていますが, 37sec が 32secと, 15%程度は勝っていますね. Temp落ちは避けられないですからね.

であれば, Temp落ちの落ちている先を速くすれば良いではないか. . . ということで, メモリにさえ余裕があれば, 使いすぎないようにした上で, tmpfs を使ってみましょうか. （一時表領域はなければOracleが再作成してくれるので）

  1  WITH
  2  t1 AS
  3  (
  4    SELECT
  5      pkey
  6      , CASE
  7          WHEN col2 IS NULL
  8            THEN col1
  9            ELSE col2
 10      END AS join_key
 11      ,description
 12    FROM
 13      nikoichi_mitaina_subtype
 14    WHERE
 15      col1 IS NOT NULL
 16      OR col2 IS NOT NULL
 17  )
 18  SELECT *
 19  FROM
 20    supertype st
 21    LEFT OUTER JOIN t1
 22    ON
 23*     st.pkey = t1.join_key

1000001行が選択されました. 

経過: 00:02:24.20

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

-------------------------------------------------------------------------------------------------------
| Id  | Operation          | Name                     | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                          |  1000K|  1451M|       |   120K  (1)| 00:00:05 |
|*  1 |  HASH JOIN OUTER   |                          |  1000K|  1451M|   497M|   120K  (1)| 00:00:05 |
|   2 |   TABLE ACCESS FULL| SUPERTYPE                |  1000K|   486M|       | 19524   (1)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| NIKOICHI_MITAINA_SUBTYPE |   750K|   723M|       | 39559   (1)| 00:00:02 |
-------------------------------------------------------------------------------------------------------

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

   1 - access("ST"."PKEY"=CASE  WHEN (ROWID(+) IS NOT NULL) THEN CASE  WHEN ("COL2"(+) IS
              NULL) THEN "COL1"(+) ELSE "COL2"(+) END  ELSE NULL END )
   3 - filter("COL1"(+) IS NOT NULL OR "COL2"(+) IS NOT NULL)

統計
----------------------------------------------------------
       1297  recursive calls
          0  db block gets
     229696  consistent gets
     374740  physical reads
          0  redo size
 1551273711  bytes sent via SQL*Net to client（別ネタ向け仕込み）
     734925  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client（別ネタ向け仕込み）
          0  sorts (memory)
          0  sorts (disk)
    1000001  rows processed


  1  WITH
  2  t1 AS
  3  (
  4    SELECT
  5      pkey
  6      , CASE
  7          WHEN col2 IS NULL
  8            THEN col1
  9            ELSE col2
 10      END AS join_key
 11      ,description
 12    FROM
 13      nikoichi_mitaina_subtype
 14    WHERE
 15      col1 IS NOT NULL
 16      OR col2 IS NOT NULL
 17  )
 18  SELECT /*+ MONITOR */ *
 19  FROM
 20    supertype st
 21    LEFT OUTER JOIN t1
 22    ON
 23*     st.pkey = t1.join_key

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT')
----------------------------------------------------------------------------------------------
SQL Monitoring Report

SQL Text
------------------------------
WITH t1 AS ( SELECT pkey , CASE WHEN col2 IS NULL THEN col1 ELSE col2 END AS join_key
,description FROM nikoichi_mitaina_subtype WHERE col1 IS NOT NULL OR col2 IS NOT NULL )
SELECT /*+ MONITOR */ * FROM supertype st LEFT OUTER JOIN t1 ON st.pkey = t1.join_key

Global Information
------------------------------
 Status              :  DONE (ALL ROWS)

 ...略...

 Duration            :  223s

 ...略...

Global Stats
================================================================================
| Elapsed |   Cpu   |    IO    | Fetch | Buffer | Read | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes | Reqs  | Bytes |
================================================================================
|      32 |      17 |       15 | 66668 |   230K | 6887 |   3GB |  5169 |   1GB |
================================================================================

SQL Plan Monitoring Details (Plan Hash Value=2223315184)
==============================================================================================================================================================================================================
| Id |      Operation       |           Name           |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |         Activity Detail         |
|    |                      |                          | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |           (# samples)           |
==============================================================================================================================================================================================================
|  0 | SELECT STATEMENT     |                          |         |       |       222 |     +2 |     1 |       1M |      |       |       |       |     . |     . |          |                                 |
|  1 |   HASH JOIN OUTER    |                          |      1M |  120K |       223 |     +1 |     1 |       1M | 5169 |   1GB |  5169 |   1GB | 184MB |   1GB |    90.62 | Cpu (9)                         |
|    |                      |                          |         |       |           |        |       |          |      |       |       |       |       |       |          | SQL*Net more data to client (7) |
|    |                      |                          |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path write temp (13)     |
|  3 |    TABLE ACCESS FULL | NIKOICHI_MITAINA_SUBTYPE |    750K | 39559 |        67 |     +7 |     1 |       1M | 1145 |   1GB |       |       |     . |     . |     6.25 | Cpu (2)                         |
==============================================================================================================================================================================================================

ということで, メモリに余裕があるので　tmpfsを使って遊んでみましょう. 2GB固定サイズの一時表領域を作成して, SCOTTユーザーのデフォルト一時表領域にしました

[master@localhost ~]$ df -TH
ファイルシス        タイプ   サイズ  使用  残り 使用% マウント位置
tmpfs               tmpfs      9.3G   17k  9.3G    1% /dev/shm
tmpfs               tmpfs      9.3G  9.7M  9.3G    1% /run
tmpfs               tmpfs      9.3G     0  9.3G    0% /sys/fs/cgroup
/dev/mapper/ol-root xfs         48G   44G  4.3G   92% /
/dev/mapper/ol-work xfs         11G  109M   11G    2% /work

...略...

[master@localhost ~]$ sudo mkdir /oratemp
...略...
[master@localhost ~]$ ls -l / | grep oratemp
drwxrwxrwt.   2 root     root       60  1月 14 12:03 oratemp
[master@localhost ~]$ sudo mount -t tmpfs tmpfs /oratemp
[sudo] master のパスワード:
[master@localhost ~]$ df -TH
ファイルシス        タイプ   サイズ  使用  残り 使用% マウント位置
devtmpfs            devtmpfs   9.3G     0  9.3G    0% /dev
tmpfs               tmpfs      9.3G   17k  9.3G    1% /dev/shm
tmpfs               tmpfs      9.3G  9.7M  9.3G    1% /run
tmpfs               tmpfs      9.3G     0  9.3G    0% /sys/fs/cgroup
/dev/mapper/ol-root xfs         48G   44G  4.3G   92% /
/dev/mapper/ol-work xfs         11G  109M   11G    2% /work

...略...

tmpfs               tmpfs      9.3G     0  9.3G    0% /oratemp

一時表領域を作成して, scottのデフォルト一時表領域にする

...略...
SYS@orclpdb1> create temporary tablespace hogetemp tempfile '/oratemp/hogetmp.dbf' size 2g;

表領域が作成されました. 

SYS@orclpdb1> alter user scott temporary tablespace hogetemp;

ユーザーが変更されました. 

では, オリジナルから. こちらそもそもTemp落ちしないので, LATERALビューへのアクセス回数が積み上がるだけなので, 該当表の物理読み込みが影響しなければほぼCPUタイムですね

SCOTT@orclpdb1> @dayx
  1  SELECT /*+ MONITOR */ *
  2  FROM
  3    supertype st
  4    LEFT OUTER JOIN nikoichi_mitaina_subtype nmst
  5    ON
  6      st.pkey = nmst.col1
  7*     OR st.pkey = nmst.col2

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

SQL Text
------------------------------
SELECT /*+ MONITOR */ * FROM supertype st LEFT OUTER JOIN nikoichi_mitaina_subtype nmst
ON st.pkey = nmst.col1 OR st.pkey = nmst.col2

Global Information
------------------------------
 Status              :  DONE (ALL ROWS)

...略...

 Duration            :  188s（別ネタ向け仕込み）

...略...

Global Stats
===========================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
===========================================================================
|      39 |      34 |     0.21 |     4.62 | 66668 |     4M |  575 | 559MB |
===========================================================================

SQL Plan Monitoring Details (Plan Hash Value=2133431102)
=========================================================================================================================================================================================
| Id |             Operation              |           Name           |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity |   Activity Detail    |
|    |                                    |                          | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |     (# samples)      |
=========================================================================================================================================================================================
|  0 | SELECT STATEMENT                   |                          |         |       |       189 |     +0 |     1 |       1M |      |       |     . |          |                      |
|  1 |   MERGE JOIN OUTER                 |                          |      2M |    6M |       189 |     +0 |     1 |       1M |      |       |     . |     2.78 | Cpu (1)              |
|  2 |    TABLE ACCESS FULL               | SUPERTYPE                |      1M | 19593 |       189 |     +0 |     1 |       1M |  575 | 559MB |     . |    13.89 | Cpu (4)              |
|    |                                    |                          |         |       |           |        |       |          |      |       |       |          | direct path read (1) |
|  3 |    BUFFER SORT                     |                          |       2 |    6M |       189 |     +0 |    1M |       1M |      |       |  2048 |    22.22 | Cpu (8)              |
|  4 |     VIEW                           | VW_LAT_E87C3AAF          |       2 |     6 |       189 |     +0 |    1M |       1M |      |       |     . |          |                      |
|  5 |      VIEW                          | VW_ORE_FDF394AE          |       2 |     6 |       189 |     +0 |    1M |       1M |      |       |     . |          |                      |
|  6 |       UNION-ALL                    |                          |         |       |       189 |     +0 |    1M |       1M |      |       |     . |     2.78 | Cpu (1)              |
|  7 |        TABLE ACCESS BY INDEX ROWID | NIKOICHI_MITAINA_SUBTYPE |       1 |     3 |       189 |     +0 |    1M |     500K |      |       |     . |     8.33 | Cpu (3)              |
|  8 |         INDEX UNIQUE SCAN          | UK1                      |       1 |     2 |       189 |     +0 |    1M |     500K |      |       |     . |     5.56 | Cpu (2)              |
|  9 |        TABLE ACCESS BY INDEX ROWID | NIKOICHI_MITAINA_SUBTYPE |       1 |     3 |       189 |     +0 |    1M |     500K |      |       |     . |     8.33 | Cpu (3)              |
| 10 |         INDEX UNIQUE SCAN          | UK2                      |       1 |     2 |       189 |     +0 |    1M |     500K |      |       |     . |    13.89 | Cpu (5)              |
=========================================================================================================================================================================================

では, HASH JOINになるように書き換えた方のTemp落ちの時間は...想定通り短縮していますね. 15secほどあったIO Waits(s)ものが1/15程度まで減っています.
結果的に, 39sec -> 21secとなりました. Temp落ちする前提だから落ちた先のIOレイテンシーが小さければこうなるわけですけども. 逆に落ちた先のIOレイテンシーが大きければ影響も大きくなりますよね.

  1  WITH
  2  t1 AS
  3  (
  4    SELECT
  5      pkey
  6      , CASE
  7          WHEN col2 IS NULL
  8            THEN col1
  9            ELSE col2
 10      END AS join_key
 11      ,description
 12    FROM
 13      nikoichi_mitaina_subtype
 14    WHERE
 15      col1 IS NOT NULL
 16      OR col2 IS NOT NULL
 17  )
 18  SELECT /*+ MONITOR */ *
 19  FROM
 20    supertype st
 21    LEFT OUTER JOIN t1
 22    ON
 23*     st.pkey = t1.join_key

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>NULL,TYPE=>'TEXT')
--------------------------------------------------------------------------------------------
SQL Monitoring Report

SQL Text
------------------------------
WITH t1 AS ( SELECT pkey , CASE WHEN col2 IS NULL THEN col1 ELSE col2 END AS join_key
,description FROM nikoichi_mitaina_subtype WHERE col1 IS NOT NULL OR col2 IS NOT NULL )
SELECT /*+ MONITOR */ * FROM supertype st LEFT OUTER JOIN t1 ON st.pkey = t1.join_key

Global Information
------------------------------
 Status              :  DONE (ALL ROWS)

...略...

 Duration            :  211s（別ネタ向け仕込み）

...略...

Global Stats
===========================================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes | Reqs  | Bytes |
===========================================================================================
|      21 |      16 |     1.65 |     3.28 | 66668 |   247K | 5566 |   3GB |  3855 | 934MB |
===========================================================================================

SQL Plan Monitoring Details (Plan Hash Value=2223315184)
==============================================================================================================================================================================================================
| Id |      Operation       |           Name           |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |         Activity Detail         |
|    |                      |                          | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |           (# samples)           |
==============================================================================================================================================================================================================
|  0 | SELECT STATEMENT     |                          |         |       |       210 |     +2 |     1 |       1M |      |       |       |       |     . |     . |          |                                 |
|  1 |   HASH JOIN OUTER    |                          |      1M |  119K |       211 |     +1 |     1 |       1M | 3855 | 934MB |  3855 | 934MB | 367MB |   1GB |    85.71 | sort segment request (1)        |
|    |                      |                          |         |       |           |        |       |          |      |       |       |       |       |       |          | Cpu (10)                        |
|    |                      |                          |         |       |           |        |       |          |      |       |       |       |       |       |          | SQL*Net message to client (1)   |
|    |                      |                          |         |       |           |        |       |          |      |       |       |       |       |       |          | SQL*Net more data to client (6) |
|  2 |    TABLE ACCESS FULL | SUPERTYPE                |      1M | 19593 |         3 |     +2 |     1 |       1M |  575 | 559MB |       |       |     . |     . |          |                                 |
|  3 |    TABLE ACCESS FULL | NIKOICHI_MITAINA_SUBTYPE |    750K | 38796 |       120 |     +4 |     1 |       1M | 1134 |   1GB |       |       |     . |     . |    14.29 | Cpu (2)                         |
|    |                      |                          |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read (1)            |
==============================================================================================================================================================================================================

既存表定義を変えないでということになるとこの辺りが限界でしょうね.

オプティマイザは進化し続けていますが, モデル起因だったり構文起因だったり, まだまだ頑張っているけど, 何でもかんでもい感じに最適化できるわけではないので, モデリング頑張りましょうね. というのは不変ですよね. と思います.
今回の例は比較的単純かしていますが, 多重度が 1:*　で結合カーディナリティが多くなるタイプや, スーパータイプ, サブタイプの共存的サブタイプだとさらに結合カーディナリティが増加するので, UNIONに分割してあげるなど別の手を駆使しないと対応しにくいタイプもあるので, 頭の片隅に置いておくと良さそうです.

2022年分のおまけのおまけ. これで, おしまい.

では, また.

---

Related article on Mac De Oracle

・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒント と　手書きSQLのレントゲンの見分け方
・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 15 / No.50 / REMOTE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 16 / No.51 / Concurrent Execution of Union All and Union
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 17 / No.52 / Order by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 19 / No.54 / Group by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 20 / No.55 / DISTINCT Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 21 / No.56 / INLIST ITERATOR と Sub Query と STATISTICS COLLECTOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 22 / No.57 / Subquery Unnesting
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 23 / No.58 / ANTI JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 24 / No.59 / SQL MACRO (19.7〜)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 25 / No.60 / ANSI JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 / No.60 / ANSI JOINのおまけ

実行計画は, SQL文のレントゲン写真だ！ Oracle Database (全部俺）Advent Calendar 2022 Day 23 / No.58 / ANTI JOIN

Day 22は, Subquery Unnestingを取り上げました. 最近は積極的にUnnestingしているように思うのですが, 皆さんはどう思いますか？

では, Day 23の窓を開けましょう！

今日は, 昨日話題にした, Subquery Unnesting の発動も必要ですが　ANTI JOIN　の実行計画という名のレントゲンから, いくつか特徴のある物をピックアップ（全バリエーション取れなかった言い訳w）.

ANTI JOIN（結合されなかった主問い合わせの対象行を返す）もJOINのナカーマなであるわけで, Nested Loop Join, Hash Join, Merge joinがあり, さらに, NULLを考慮する必要のある結合列がないか, 一つか, それ以上かで, Null-Awareなし, NA(Null-Aware), SNA(Single Null-Aware) でOperation列に表示されるOperation名にいくつかのバリエーションがあります.
とはいえ, ANTI JOINかNULLを意識する必要があるかないか大きな分類で, JOIN方式は通常のJOINと同じ種類があるのはご存知の通り.

NOT EXISTS演算子や, NOT IN条件かつSubquery Unnestingが発動していると, 直感的にイメージできるようになってればいいかもしれないですね. かつ, NULLを意識してるなどもOperation名から見切れるとなお.
たった1文のOperationにそこまで情報が詰め込まれているんですよね.

参考）

Oracle Database 21c SQL Tuning Guide / 9.3.4 Antijoins

いつもと同じように 21c で確認します.

SCOTT@orclpdb1> select banner from v$version;

BANNER
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

ヒントまで使ってなんとか, NESTED LOOPS ANTI　が取れました（なかなか言うこと聞いてくれなかったw）
結合列でNULLを意識する必要のない場合に現れます.

HR@orclpdb1> @day23-2
1  SELECT
2    /*+
3      NO_INDEX(departments DEPT_ID_PK)
4    */
5    department_id
6    , department_name
7  FROM
8    departments
9  WHERE
10    department_id NOT IN
11    (
12       SELECT
13         /*+
14           NL_AJ
15         */
16         department_id
17       FROM
18         employees
19       WHERE
20         department_id IS NOT NULL
21*   )

DEPARTMENT_ID DEPARTMENT_NAME
------------- ----------------------
          120 Treasury
          130 Corporate Tax
          140 Control And Credit

...略...

          240 Government Sales
          250 Retail Sales
          260 Recruiting
          270 Payroll

16行が選択されました. 

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

----------------------------------------------------------------------------------------
| Id  | Operation          | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                   |    17 |   323 |     3   (0)| 00:00:01 |
|   1 |  NESTED LOOPS ANTI |                   |    17 |   323 |     3   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| DEPARTMENTS       |    27 |   432 |     3   (0)| 00:00:01 |
|*  3 |   INDEX RANGE SCAN | EMP_DEPARTMENT_IX |    41 |   123 |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

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

 3 - access("DEPARTMENT_ID"="DEPARTMENT_ID")
     filter("DEPARTMENT_ID" IS NOT NULL)

一つ前のSQL文とほぼ同じですが, IS NOT NULL条件を取り除いてあります.
NESTED LOOPS ANTI SNAです, SNAとなっているので, NULLを意識する必要のあることがわかります.

  1  SELECT
  2    /*+
  3      NO_INDEX(departments DEPT_ID_PK)
  4    */
  5    department_id
  6    , department_name
  7  FROM
  8    departments
  9  WHERE
 10    department_id NOT IN
 11    (
 12       SELECT
 13         department_id
 14       FROM
 15         employees
 16*   )

レコードが選択されませんでした. 

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

--------------------------------------------------------------------------------------------
| Id  | Operation              | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |                   |     1 |    19 |     6   (0)| 00:00:01 |
|*  1 |  FILTER                |                   |       |       |            |          |
|   2 |   NESTED LOOPS ANTI SNA|                   |    17 |   323 |     6  (50)| 00:00:01 |
|   3 |    TABLE ACCESS FULL   | DEPARTMENTS       |    27 |   432 |     3   (0)| 00:00:01 |
|*  4 |    INDEX RANGE SCAN    | EMP_DEPARTMENT_IX |    41 |   123 |     0   (0)| 00:00:01 |
|*  5 |   TABLE ACCESS FULL    | EMPLOYEES         |     1 |     3 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------

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

   1 - filter( NOT EXISTS (SELECT 0 FROM "EMPLOYEES" "EMPLOYEES" WHERE
              "DEPARTMENT_ID" IS NULL))
   4 - access("DEPARTMENT_ID"="DEPARTMENT_ID")
   5 - filter("DEPARTMENT_ID" IS NULL)

MERGE JOIN ANTIが現れています. NA, SNAが現れていないことから, NULLは考慮しないANTI JOINであることがわかります.

SCOTT@orclpdb1> @day23

  1  SELECT
  2    deptno
  3    ,dname
  4  FROM
  5    dept
  6  WHERE
  7    deptno NOT IN
  8    (
  9       SELECT
 10         deptno
 11       FROM
 12         emp
 13       WHERE
 14         deptno IS NOT NULL
 15*   )

    DEPTNO DNAME
---------- ------------------------------------------
        40 OPERATIONS

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

----------------------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |     1 |    16 |     6  (17)| 00:00:01 |
|   1 |  MERGE JOIN ANTI             |         |     1 |    16 |     6  (17)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     4 |    52 |     2   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | PK_DEPT |     4 |       |     1   (0)| 00:00:01 |
|*  4 |   SORT UNIQUE                |         |    12 |    36 |     4  (25)| 00:00:01 |
|*  5 |    TABLE ACCESS FULL         | EMP     |    12 |    36 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

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

   4 - access("DEPTNO"="DEPTNO")
       filter("DEPTNO"="DEPTNO")
   5 - filter("DEPTNO" IS NOT NULL)

MERGE JOIN ANTI NAが出ています. NAがあるので, NULLを考慮したMERGE JOIN ANTIであることがわかります. でもこれ本当は, SNAではないのか？（時間があったら10053でも追ってみようかなぁ）

  1  SELECT
  2    deptno
  3    ,dname
  4  FROM
  5    dept
  6  WHERE
  7    deptno NOT IN
  8    (
  9       SELECT
 10         deptno
 11       FROM
 12         emp
 13*   )

    DEPTNO DNAME
---------- ------------------------------------------
        40 OPERATIONS

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

-------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |         |     1 |    16 |     6  (17)| 00:00:01 |
|   1 |  MERGE JOIN ANTI NA                   |         |     1 |    16 |     6  (17)| 00:00:01 |
|   2 |   SORT JOIN                           |         |     4 |    52 |     2   (0)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| DEPT    |     4 |    52 |     2   (0)| 00:00:01 |
|   4 |     INDEX FULL SCAN                   | PK_DEPT |     4 |       |     1   (0)| 00:00:01 |
|*  5 |   SORT UNIQUE                         |         |    12 |    36 |     4  (25)| 00:00:01 |
|   6 |    TABLE ACCESS FULL                  | EMP     |    12 |    36 |     3   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------

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

   5 - access("DEPTNO"="DEPTNO")
       filter("DEPTNO"="DEPTNO")

HASH JOIN ANTIが現れています. NULLを考慮させないために, IS NOT NULL条件を追加しています.

 1  SELECT
 2    empno
 3    ,ename
 4  FROM
 5    emp
 6  WHERE
 7    emp.deptno NOT IN
 8    (
 9       SELECT
10         /*+
11           HASH_AJ
12         */
13         dept.deptno
14       FROM
15         dept
16       WHERE
17         dept.deptno = 50
18         AND dept.deptno IS NOT NULL
19    )
20*   AND emp.deptno IS NOT NULL

    EMPNO ENAME
---------- ------------------------------
     7499 ALLEN
     7521 WARD

...略...

     7369 SMITH
     7566 JONES
     7902 FORD

12行が選択されました. 

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

------------------------------------------------------------------------------
| Id  | Operation          | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |         |    11 |   176 |     3   (0)| 00:00:01 |
|*  1 |  HASH JOIN ANTI    |         |    11 |   176 |     3   (0)| 00:00:01 |
|*  2 |   TABLE ACCESS FULL| EMP     |    12 |   156 |     3   (0)| 00:00:01 |
|*  3 |   INDEX UNIQUE SCAN| PK_DEPT |     1 |     3 |     0   (0)| 00:00:01 |
------------------------------------------------------------------------------

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

  1 - access("EMP"."DEPTNO"="DEPT"."DEPTNO")
  2 - filter("EMP"."DEPTNO" IS NOT NULL)
  3 - access("DEPT"."DEPTNO"=50)

HASH JOIN ANTI SNAが現れています. NULLを考慮する必要のあるSNAが付いた, HASH JOIN ANTIですね.

  1  SELECT
  2    empno
  3    ,ename
  4  FROM
  5    emp
  6  WHERE
  7    deptno NOT IN
  8    (
  9       SELECT
 10         deptno
 11       FROM
 12         dept
 13       WHERE
 14         deptno = 50
 15*   )

     EMPNO ENAME
---------- ------------------------------
      7499 ALLEN
      7521 WARD
      7654 MARTIN

...略...

      7369 SMITH
      7566 JONES
      7902 FORD

12行が選択されました. 

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

------------------------------------------------------------------------------
| Id  | Operation          | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |         |    11 |   176 |     3   (0)| 00:00:01 |
|*  1 |  HASH JOIN ANTI SNA|         |    11 |   176 |     3   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| EMP     |    12 |   156 |     3   (0)| 00:00:01 |
|*  3 |   INDEX UNIQUE SCAN| PK_DEPT |     1 |     3 |     0   (0)| 00:00:01 |
------------------------------------------------------------------------------

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

   1 - access("DEPTNO"="DEPTNO")
   3 - access("DEPTNO"=50)

次は, HASH JOIN ANTI NAが出ているので, NULLを複数列で考慮してもらう必要があるので, 無理感はありますがw. 一応, 取れたw　NA付きのHASH JOIN ANTIのOperationです.

SCOTT@orclpdb1> desc foo
名前                                    NULL?    型
----------------------------------------- -------- ----------------------------
COL1                                      NOT NULL NUMBER
COL2                                      NOT NULL NUMBER
COL3                                               NUMBER

SCOTT@orclpdb1> desc bar
名前                                    NULL?    型
----------------------------------------- -------- ----------------------------
COL0                                      NOT NULL NUMBER
COL1                                               NUMBER
COL2                                               NUMBER
COL4                                               NUMBER

 1  SELECT
 2    col1
 3  FROM
 4    foo
 5  WHERE
 6    col3 NOT IN
 7    (
 8       SELECT
 9          col2
10        FROM
11          bar
12*   )

レコードが選択されませんでした. 

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

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |    39 |     4   (0)| 00:00:01 |
|*  1 |  HASH JOIN ANTI NA |      |     1 |    39 |     4   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| FOO  |     1 |    26 |     2   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| BAR  |     1 |    13 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------

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

  1 - access("COL3"="COL2")

狙った通りのOperationを行わせるのって難しいですねwwwwwwww (^^;;;;;;; NA, SNAまで考えるとw　

なかなか, これだけのバリエーション, 現場で見ることはないわけですけどもwww 今回のレントゲンシリーズで一番疲れたw
今日は, ここまで,

残り2日だ.

明日も, 頑張って, 窓を開きますよ. ここまできたらw

---

Related article on Mac De Oracle

・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒント と　手書きSQLのレントゲンの見分け方
・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 15 / No.50 / REMOTE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 16 / No.51 / Concurrent Execution of Union All and Union
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 17 / No.52 / Order by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 19 / No.54 / Group by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 20 / No.55 / DISTINCT Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 21 / No.56 / INLIST ITERATOR と Sub Query と STATISTICS COLLECTOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 22 / No.57 / Subquery Unnesting

実行計画は, SQL文のレントゲン写真だ！ Oracle Database (全部俺）Advent Calendar 2022 Day 21 / No.56 / INLIST ITERATOR と Sub Query と STATISTICS COLLECTOR

Previously on Mac De Oracle...

Day 20は, DISTINCT Eliminationを取り上げました. 古くから実装されているElimination機能ですが, 知ってる方いましたかね？w　古すぎでしょうかw. とはいえ, この恩恵を得ている方も実は多いかもしれませんよ. クソデカクエリー追いきれてないかもしれないですし.

では, Day 21の窓を開けましょう！

久々に, 実行計画は, SQL文のレントゲン写真だ！　っぽく, 実行計画に現れるOperationを楽しんで診ていきましょう！

いつもと同じように 21c で確認します.

SCOTT@orclpdb1> select banner from v$version;

BANNER
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

今日のテーマはIN条件とサブクエリー. IN条件といえば, 昔, 悩ませ過ぎは及ばざるがごとし #1という記事を書いてました. （そのころはまだIT業界に居なかった？　方も多そうですが）
IN条件, 索引を使って少量のデータをアクセスするには, 以下の実行計画にあるように, 　INLIST ITERATORで繰り返しアクセスするは問題ないわけですが, 大量にあるとかなり性能面で影響が出ます. （悩ませ過ぎは及ばざるがごとし #1などは, ハードパース時間に影響がでたケースです）

SCOTT@orclpdb1> @day21
  1  SELECT *
  2  FROM
  3    emp
  4  WHERE
  5*   empno IN (7369,7499)

     EMPNO ENAME                          JOB                                MGR HIREDATE        SAL       COMM     DEPTNO
---------- ------------------------------ --------------------------- ---------- -------- ---------- ---------- ----------
      7369 SMITH                          CLERK                             7902 80-12-17        800                    20
      7499 ALLEN                          SALESMAN                          7698 81-02-20       1600        300         30

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

---------------------------------------------------------------------------------------
| Id  | Operation                    | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |        |     2 |    78 |     2   (0)| 00:00:01 |
|   1 |  IINLIST ITERATOR            |        |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| EMP    |     2 |    78 |     2   (0)| 00:00:01 |
|*  3 |    INDEX UNIQUE SCAN         | PK_EMP |     2 |       |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

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

   3 - access("EMPNO"=7369 OR "EMPNO"=7499)

性能問題も多かった影響なのか？！, Oracle Database 9i R2頃以降, IN条件が, 結合に書き換えられるように（私の感覚でしかないのですが, 最近は, より積極的に書き換えが行われる傾向があるように感じます）なっています.
以下のようにサブクエリーを利用しているケースが典型例ですね. IN条件だけでなく, EXISTS演算子や, スカラー副問合せなどもこの書き換えの対象です. この書き換えは, Subquery Unnestingと呼ばれています. ご存知の方も多いですよね. 今日の主役はそれでなく, INLIST ITERATOR　の方ですが, これ両方話さないとOperationの向き不向きが見えないのでw

  1  SELECT
  2    *
  3  FROM
  4    emp
  5  WHERE
  6    deptno IN (
  7      SELECT
  8        deptno
  9      FROM
 10        dept
 11      WHERE
 12        dname IN ('SALES','ACCOUNT')
 13*   )

     EMPNO ENAME                          JOB                                MGR HIREDATE        SAL       COMM     DEPTNO
---------- ------------------------------ --------------------------- ---------- -------- ---------- ---------- ----------
      7499 ALLEN                          SALESMAN                          7698 81-02-20       1600        300         30
      7521 WARD                           SALESMAN                          7698 81-02-22       1250        500         30
      7654 MARTIN                         SALESMAN                          7698 81-09-28       1250       1400         30
      7698 BLAKE                          MANAGER                           7839 81-05-01       2850                    30
      7844 TURNER                         SALESMAN                          7698 81-09-08       1500          0         30
      7900 JAMES                          CLERK                             7698 81-12-03        950                    30

6行が選択されました. 

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

---------------------------------------------------------------------------------------
| Id  | Operation                    | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |        |     8 |   416 |     5   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |        |     8 |   416 |     5   (0)| 00:00:01 |
|   2 |   NESTED LOOPS               |        |     8 |   416 |     5   (0)| 00:00:01 |
|*  3 |    TABLE ACCESS FULL         | DEPT   |     2 |    26 |     3   (0)| 00:00:01 |
|*  4 |    INDEX RANGE SCAN          | IX_EMP |     4 |       |     0   (0)| 00:00:01 |
|   5 |   TABLE ACCESS BY INDEX ROWID| EMP    |     4 |   156 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

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

   3 - filter("DNAME"='ACCOUNT' OR "DNAME"='SALES')
   4 - access("DEPTNO"="DEPTNO")

Note
-----
   - this is an adaptive plan

前述した実行計画の Noteに, - this is an adaptive plan　と気になる情報が出ています. これ, 実行計画上は, Subquery Unnestingされて, Nested Loop Join　(NLJ) になっていますが, 駆動表のヒット件数に応じて, それ以外の結合メソッドに
へ切り替わる可能性があることを示しています. これは, adaptive planと呼ばれている機能です.
実際, NLJなのかそれ以外なのかをみる方法は, SQL Monitor, Actual Planを利用する方法と, 以下のように, Adaptive Planを表示させ, どちらで動作したのかを確認する方法があります.

ここで登場するのが, Adaptive Planの鍵になる, STATISTICS COLLECTOR というOperationです. ここで駆動表の件数をみつつ, これは！　HJ向きのと判断すれば, NLJ から HJ へ切り替えることになります.
今回は, NLJ のままですね. ()

  1* SELECT * FROM TABLE(DBMS_XPLAN.display_cursor(format => 'adaptive'))

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------
SQL_ID  cuxwr51s6gs61, child number 0
-------------------------------------
SELECT   * FROM   emp WHERE   deptno IN (     SELECT       deptno
FROM       dept     WHERE       dname IN ('SALES','ACCOUNT')   )

Plan hash value: 4207756064

------------------------------------------------------------------------------------------
|   Id  | Operation                     | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|     0 | SELECT STATEMENT              |        |       |       |     5 (100)|          |
|- *  1 |  HASH JOIN                    |        |     8 |   416 |     5   (0)| 00:00:01 |
|     2 |   NESTED LOOPS                |        |     8 |   416 |     5   (0)| 00:00:01 |
|     3 |    NESTED LOOPS               |        |     8 |   416 |     5   (0)| 00:00:01 |
|-    4 |     STATISTICS COLLECTOR      |        |       |       |            |          |
|  *  5 |      TABLE ACCESS FULL        | DEPT   |     2 |    26 |     3   (0)| 00:00:01 |
|  *  6 |     INDEX RANGE SCAN          | IX_EMP |     4 |       |     0   (0)|          |
|     7 |    TABLE ACCESS BY INDEX ROWID| EMP    |     4 |   156 |     1   (0)| 00:00:01 |
|-    8 |   TABLE ACCESS FULL           | EMP    |     4 |   156 |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------------

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

   1 - access("DEPTNO"="DEPTNO")
   5 - filter(("DNAME"='ACCOUNT' OR "DNAME"='SALES'))
   6 - access("DEPTNO"="DEPTNO")

Note
-----
   - this is an adaptive plan (rows marked '-' are inactive)

残り, 4日, 最終日はクリスマスで, 日曜日じゃないか！今年は.
大きめのネタをぶん投げて, おまけブログでまとめる感じにするか. 悩みどころだ. それとも軽めのネタで最後まで通すか.

明日も担当は, 私ですよ. （全部俺アドベントカレンダー, 来年はどうしようw　なんの苦行だという感じw　でも, それ楽しんでる俺は...w）

では, また　:)

---

Related article on Mac De Oracle

・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒント と　手書きSQLのレントゲンの見分け方
・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 15 / No.50 / REMOTE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 16 / No.51 / Concurrent Execution of Union All and Union
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 17 / No.52 / Order by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 19 / No.54 / Group by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 20 / No.55 / DISTINCT Elimination

実行計画は, SQL文のレントゲン写真だ！ Oracle Database (全部俺）Advent Calendar 2022 Day 20 / No.55 / DISTINCT Elimination

Previously on Mac De Oracle... 
Day 19は, かなり地味にデビューしていた機能ですが、変なところで目立った　Group by Elimination　にフォーカスを当てました。この手のEliminationは、実行計画という名のレントゲンからは見えなくなってしまう。何か悪さをしているときの調査は難易度高めです。基本的に操作が行われなくなるわけですが、例としてお見せしたような単純なSQLなら別ですが、クソデカクエリーだと、キッツイですよねw　結果不正って。

と言うことで、Day 20の窓を開けましょう！

今日は、 DISTINCT Eliminationです。またか！　と。そういうEliminationもある。ということ知っておいた方が良いと思うので、eliminationネタの最後として、ちょっと飽きてきた感じはありますが取り上げてみました。この機能の提供も古く、機能が提供されていなかった時代を知る人の方が少ないかもしれませんw

ちなみに、今回も該当機能をを局所的に無効化する例を書いていますが、ヒントが提供されていない最適化もあるので、そう言う場合は、隠しパラメータからそれらしいのを探してして、検証して効果の有無を確かめると良いと思います。MOSに書かれてないケースも多いのでBlogなどから情報を集めたりして、最終的には動作確認。もし不具合などと関連しているようであればサポートへ問い合わせても対応してくれるでしょう。コミュニティーにこれどうよ？と投げてみるのもありだと思います。Jonathanもネタもとは、コミュニティーでのやりとりだったりすることも多く、調べてみたら、そうだった！という記事も多く、本当に助かった！って経験は何度もあります！！！。

parameterはこんなあたりから見つけると楽ですよん。
Difference of Initialization Parameters between 19c (19.3.0.0.0) and 21c (21.3.0.0.0) - including hidden params
Difference of Initialization Parameters between 19c (19.3.0.0.0) and 21c (21.3.0.0.0)

いつもと同じように 21c で確認します.

SCOTT@orclpdb1> select banner from v$version;

BANNER
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

前回と同じデータを使います。（こんな使いまわせるテストデータを作るスクリプト用意しておくと何かと便利ですよ！）

SCOTT@orclpdb1> @day20
  1* DROP TABLE business_day_calendar

表が削除されました。

  1  CREATE TABLE business_day_calendar AS
  2  WITH
  3    FUNCTION get_num_of_dates
  4    RETURN NUMBER IS
  5      l_dummy_date DATE;
  6      --
  7      eORA01839 exception;
  8      pragma exception_init(eORA01839, -1839);
  9    BEGIN
 10      -- validate leap year
 11      l_dummy_date := TO_DATE(TO_CHAR(SYSDATE, 'YYYY') || '0229', 'YYYYMMDD');
 12      RETURN 366;
 13    EXCEPTION
 14      WHEN eORA01839 THEN
 15        RETURN 365;
 16    END;
 17  SELECT
 18    TO_DATE(TRUNC(SYSDATE,'YYYY') + level - 1) AS business_date
 19    , CASE
 20        WHEN TO_CHAR(
 21          TO_DATE(TRUNC(SYSDATE,'YYYY') + level - 1)
 22          , 'DY'
 23          , 'NLS_DATE_LANGUAGE=AMERICAN'
 24        ) IN ('SUN','WED')
 25        THEN '1'
 26        ELSE '0'
 27      END AS is_holiday
 28  FROM
 29    dual
 30  CONNECT BY
 31*   level <= get_num_of_dates

表が作成されました。

  1  ALTER TABLE business_day_calendar
  2    ADD CONSTRAINT pk_business_day_calendar PRIMARY KEY
  3    (
  4      business_date
  5    )
  6*   USING INDEX

表が変更されました。

はい、主キー列にDISTINCTを使ってますが、無駄ですよね！（いきなり本題w）

DISTINCT操作は見事に実行計画から排除されています！（簡単ですね。とは言っても実行計画を見ただけでは、DISTINCT Eliminationが行われていることには気付けないわけですけども）

  1  SELECT
  2    DISTINCT business_date
  3  FROM
  4*   business_day_calendar

BUSINESS
--------
22-01-01
22-01-02
22-01-03

...略...

22-12-29
22-12-30
22-12-31

365行が選択されました。

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

---------------------------------------------------------------------------------------------
| Id  | Operation        | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                          |   365 |  2920 |     1   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | PK_BUSINESS_DAY_CALENDAR |   365 |  2920 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         26  consistent gets
          0  physical reads
          0  redo size
       8855  bytes sent via SQL*Net to client
        316  bytes received via SQL*Net from client
         26  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        365  rows processed

では、元栓というか、Optimizer自体を、とーーーく昔の状態にしてみましょう（DISTINCT Eliminationがバックポートもされてない時代の10g 10.2.0.3。こういうことができるOracle面白いですよね）
このようなことを本番でやるのはかなりレアで、よっぽど新しい機能を使いたくないか、めちゃめちゃキツイ大人の事情があるんだと思います（知らんけど）

Optimizerを10g R2ぐらいに戻したことで、DISTINCT操作として、SORT UNIQUE NOSORTが合わられましたが、INDEX FULL SCANでユニークキーをアクセスしているのでNOSORTとなり、SORT UNIQUE操作はスキップされていることがわかります。ソート順に索引を全捜査する INDEX FULL SCANだからこそできる動きですね。

  1  SELECT
  2    /*+
  3      OPTIMIZER_FEATURES_ENABLE('10.2.0.3')
  4    */
  5    DISTINCT business_date
  6  FROM
  7*   business_day_calendar

BUSINESS
--------
22-01-01
22-01-02
22-01-03

...略...

22-12-29
22-12-30
22-12-31

365行が選択されました。

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

-----------------------------------------------------------------------------------------------
| Id  | Operation          | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                          |   365 |  2920 |     2  (50)| 00:00:01 |
|   1 |  SORT UNIQUE NOSORT|                          |   365 |  2920 |     2  (50)| 00:00:01 |
|   2 |   INDEX FULL SCAN  | PK_BUSINESS_DAY_CALENDAR |   365 |  2920 |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         26  consistent gets
          0  physical reads
          0  redo size
       8855  bytes sent via SQL*Net to client
        316  bytes received via SQL*Net from client
         26  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        365  rows processed

Optimizerの能力を10gに戻してしまうのも勿体ないので、よく使う局所的な方法。特定のSQLだけが影響するのであれば、この方法がおすすめです。
元々の機能に影響を受けていない。逆に恩恵を受けているものあるかもしれません。
前回の結果不正などもそうですが、どの方法で治療するというかチューニングかは、対応するエンジニア考え方や、該当する患者さん（システムや、お客様の大人の事情w）にもよりますが、私は、基本的に局所的な対処で済むのなら、そちらを選ぶ方針です。
なるべく狭い範囲、SQL、セッションあたりで無効、有効にして、経過観察、副作用有無、対処した範囲外で、同一理由による問題が発生していないか。もし狭い範囲の対処では無理なら徐々に広げる。最終系がインスタンス全体で。みたいな流れにすることで、無駄に全て止めてしまうということを避けたい（恩恵を受けているのもあるはずということを前提にしています）。この辺りは考え方次第なので、絶対、こうするのが良いとか悪いという話では無いですが。長い目で考えるとそれが良いのでは無いかと個人的には思います。
この機能、直接利用できるヒントはないので、隠しパラメータでon/offできます。冒頭で紹介したパラメータ一覧には隠しパラメータもリストしているので、こういう時はクエリ投げずに該当ページを検索すると楽ですよん:)

  1  SELECT
  2    /*+
  3      OPT_PARAM('_optimizer_distinct_elimination','false')
  4    */
  5    DISTINCT business_date
  6  FROM
  7*   business_day_calendar

BUSINESS
--------
22-01-01
22-01-02
22-01-03

...略...

22-12-29
22-12-30
22-12-31

365行が選択されました。

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

-----------------------------------------------------------------------------------------------
| Id  | Operation          | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                          |   365 |  2920 |     2  (50)| 00:00:01 |
|   1 |  SORT UNIQUE NOSORT|                          |   365 |  2920 |     2  (50)| 00:00:01 |
|   2 |   INDEX FULL SCAN  | PK_BUSINESS_DAY_CALENDAR |   365 |  2920 |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         26  consistent gets
          0  physical reads
          0  redo size
       8855  bytes sent via SQL*Net to client
        316  bytes received via SQL*Net from client
         26  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        365  rows processed

別テストケースで確認してみましょう。

  1* DROP TABLE case2

表が削除されました。

  1  CREATE TABLE case2
  2  (
  3    id NUMBER PRIMARY KEY
  4    , col2 NUMBER NOT NULL
  5    , col3 NUMBER
  6    , col4 VARCHAR2(10) NOT NULL
  7    , CONSTRAINT uix_case2 UNIQUE (col2,col3) USING INDEX
  8* )

表が作成されました。

  1  BEGIN
  2    FOR i IN 1..2000 LOOP
  3      INSERT INTO case2 VALUES(i, i, NULL, LPAD(TO_CHAR(i),10,'*'));
  4      IF MOD(i,100) = 0 THEN COMMIT; END IF;
  5    END LOOP;
  6* END;

PL/SQLプロシージャが正常に完了しました。

このテストケースでは、複合一意キーかつ、第二キーに null を許しています。
（Oraleの索引は、null が含まれない！という都市伝説がありましたが、そんなことはないのは以前解説していた通りです。一部の列にnullを許可した一意キーでもDISTINCT Eliminationは発動することを確認するテストケースです）

この例では、第二キー列がnullableで、この状態では、第二キー列全てを null にしています。DISTINCT Eliminationの条件を満たすため、DISTINCT 捜査が排除されていることがわかります！

  1  SELECT
  2    DISTINCT col2, col3
  3  FROM
  4*   case2

      COL2       COL3
---------- ----------
       541 [null]
       542 [null]
       543 [null]

...略...

      1998 [null]
      1999 [null]
      2000 [null]

2000行が選択されました。

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

----------------------------------------------------------------------------------
| Id  | Operation            | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |           |  2000 | 52000 |     5   (0)| 00:00:01 |
|   1 |  INDEX FAST FULL SCAN| UIX_CASE2 |  2000 | 52000 |     5   (0)| 00:00:01 |
----------------------------------------------------------------------------------

OPT_PARAM('_optimizer_distinct_elimination','false')でDISTINCT Eliminationを無効化すれば、DISTINCT 操作は現れますが、INDEX FAST FULL SCANとなっているため HASH UNIQUE操作が行われていることがわかります。
実際には、ユニーク索引なので、不要ではあるのですが:)

  1  SELECT
  2    /*+
  3      OPT_PARAM('_optimizer_distinct_elimination','false')
  4    */
  5    DISTINCT col2, col3
  6  FROM
  7*   case2

      COL2       COL3
---------- ----------
       555 [null]
       585 [null]
       586 [null]

...略...

      1986 [null]
      1989 [null]
      1990 [null]

2000行が選択されました。

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

-----------------------------------------------------------------------------------
| Id  | Operation             | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |           |  2000 | 52000 |     6  (17)| 00:00:01 |
|   1 |  HASH UNIQUE          |           |  2000 | 52000 |     6  (17)| 00:00:01 |
|   2 |   INDEX FAST FULL SCAN| UIX_CASE2 |  2000 | 52000 |     5   (0)| 00:00:01 |
-----------------------------------------------------------------------------------

では、ちょっと初歩的な確認で、1, nullというすでに存在する値をINSERTしてみましょう。当然エラーです。UIX_CASE2は一意キーなので。

  1* INSERT INTO case2 VALUES(2001,1,NULL,'test')
INSERT INTO case2 VALUES(2001,1,NULL,'test')
*
行1でエラーが発生しました。:
ORA-00001: 一意制約(SCOTT.UIX_CASE2)に反しています

第二キーがnullではない値を登録しておきます。

  1* INSERT INTO case2 VALUES(2002,1,1,'test')

1行が作成されました。

  1* COMMIT

コミットが完了しました。

特にどうだということもないのですがw　正しく、DISTINCT EliminationされINDEX FAST FULL SCANだけの実行計画という名のレントゲンが現れています。ニッコリ（どちらかというと、索引に null　入らないという本当の意味を知らずにいる方もいるのではないだろうかという余計な心配をしただけのお節介なテストケース。というだけだったかもしれません）

  1  SELECT
  2    DISTINCT col2, col3
  3  FROM
  4*   case2

      COL2       COL3
---------- ----------
       541 [null]
       542 [null]
       543 [null]

...略...

         1          1
         1 [null]
         2 [null]
         3 [null]

...略...

       538 [null]
       539 [null]
       540 [null]

2001行が選択されました。

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

----------------------------------------------------------------------------------
| Id  | Operation            | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |           |  2000 | 52000 |     5   (0)| 00:00:01 |
|   1 |  INDEX FAST FULL SCAN| UIX_CASE2 |  2000 | 52000 |     5   (0)| 00:00:01 |
----------------------------------------------------------------------------------

ということで、 Day 20はここまで。

残り5日。追い込みだーーーーっ
明日も、私が担当なので、よろしくお願いします。

---

Related article on Mac De Oracle
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒント と　手書きSQLのレントゲンの見分け方
・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 15 / No.50 / REMOTE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 16 / No.51 / Concurrent Execution of Union All and Union
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 17 / No.52 / Order by Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 19 / No.54 / Group by Elimination

実行計画は, SQL文のレントゲン写真だ！ Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination

Previously on Mac De Oracle...
Day 17は, order by Elimination にフォーカスをあてました. チューニングの現場で気づいたのが最初だったと思いますが, SQL文を見ていて, これ無駄なソートだなぁなんて思いながら実行計画という名のレントゲンをみていたら, おお！　NOSORTとかではなく, ORDER BY自体が消されてる！　賢い！　と.

では, Day 18のお題, Join Eliminationです. (登場したのは10gR2 ぐらいのはずですが, 間違ってたらツッコミ歓迎)
この排除系書き換えも, 実行計画という名のレントゲンシリーズでは, まだ紹介していなかったので, 今回は, ヒントで無効化する例も含め, 軽めの内容でw, 診ていきたいと思います. （参照整合性制約アレルギーネタを思い出すw）

いつもと同じように 21c で確認します.

SCOTT@orclpdb1> select banner from v$version;

BANNER
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

対象となる表には外部参照整合制約があることが前提です.

customers表を結合していますが, 参照整合性制約でcustomers表に存在する顧客しか注文できないという制約があります. つまり, この参照整合性制約があるため, INNER JOINやEXISTSを利用して存在チェックする必要はないということを意味しています.
Join EliminationによりSQLが書き換えられ結合が排除されていることがわかります. 実行計画には, ORDER_PKをIndex Only Scanしているだけで, customers表やcustomersの索引を結合しているOperationは含まれていない！！！
結合しないので, 結合のコスト及び, customers表やcustomersの索引へのアクセスコストが削減されています. 実行統計からは, Pysical Readや, Buffer Getsの低下という形で現れてきます.

とはいえ, 参照整合性制約アレルギーのお持ちの方も多く, 一生目にすることのない方々も, 残念ながら多いのも事実です.
参照整合性制約アレルギーが発症してしまうと, 一生付き合っていくことになちゃいますからね（大抵の場合）

Day19の内容とDay18のネタを入れ替えたので, day19.sqlを実行しているところは気にしないでくださいw

OE@orclpdb1> @day19
  1  SELECT
  2    order_id
  3  FROM
  4    orders o
  5    INNER JOIN customers c
  6    ON
  7      o.customer_id = c.customer_id
  8  WHERE
  9*   order_id < 2400

  ORDER_ID
----------
      2354
      2355
      2356
      2357
      2358

...略...

      2396
      2397
      2398
      2399

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

-----------------------------------------------------------------------------
| Id  | Operation        | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT |          |    46 |   184 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| ORDER_PK |    46 |   184 |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------

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

   1 - access("O"."ORDER_ID"<2400)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          5  consistent gets
          0  physical reads
          0  redo size
       1482  bytes sent via SQL*Net to client
         85  bytes received via SQL*Net from client
          5  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         46  rows processed
/code>

NO_ELIMINATE_JOINヒントを利用し, Join Eliminationを抑止してみましょう.
NO_ELIMINATE_JOINは, 使うことがあるのか？　と思う方もいるかもしれませんが, 例えば, 不具合で7445とか, その他結果不正などに当たった時, かつ, 局所的対応で回避できそうなケースでは, 該当SQLにヒントを埋め込み, Join Eliminationの抑止で回避したりします.
どこで起きるかわからんので, インスタンスレベルで止めるケースもなくなないですが, そういう場合は, 隠しパラメータで無効化するのが一般的です. （ほぼ使わないと思いますが, ELIMINATE_JOIN　でJoin Eliminationを利用できます. インスタンスレベルで無効化している状態で, 特定のSQLだけはJoin Eliminationしたいという場合に使うぐらいですね. 滅多にないと思いますが）

  1  SELECT
  2    /*+
  3      NO_ELIMINATE_JOIN(c)
  4    */
  5    order_id
  6  FROM
  7    orders o
  8    INNER JOIN customers c
  9    ON
 10      o.customer_id = c.customer_id
 11  WHERE
 12*   order_id < 2400

  ORDER_ID
----------
      2354
      2355
      2356
      2357
      2358

...略...

      2392
      2393
      2394
      2395
      2396
      2397
      2398
      2399

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

-----------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |              |    46 |   552 |     2   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                        |              |    46 |   552 |     2   (0)| 00:00:01 |
|*  2 |   TABLE ACCESS BY INDEX ROWID BATCHED| ORDERS       |    46 |   368 |     2   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | ORDER_PK     |    46 |       |     1   (0)| 00:00:01 |
|*  4 |   INDEX UNIQUE SCAN                  | CUSTOMERS_PK |     1 |     4 |     0   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------

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

   2 - filter("O"."CUSTOMER_ID">0)
   3 - access("O"."ORDER_ID"<2400)
   4 - access("O"."CUSTOMER_ID"="C"."CUSTOMER_ID")

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         15  consistent gets
          0  physical reads
          0  redo size
       1482  bytes sent via SQL*Net to client
         85  bytes received via SQL*Net from client
          5  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         46  rows processed
/code>

アドベントカレンダー終わったら, もう, 今年も残りわずか....

ということで, 出口が見えつつある, アドベントカレンダー全部俺, 明日も, 俺が書きますw
では, また.

参考）
Join Elimination（結合の排除）と 参照整合性制約　/ FAQ
db tech showcase Tokyo 2013 - A35 特濃JPOUG：潮溜まりでジャブジャブ, SQLチューニングの「参照整合性制約アレルギー」を参照のこと

---

Related article on Mac De Oracle

・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒント と　手書きSQLのレントゲンの見分け方
・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 14 / No.49 / the DUAL Table
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 15 / No.50 / REMOTE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 16 / No.51 / Concurrent Execution of Union All and Union
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 17 / No.52 / Order by Elimination

実行計画は, SQL文のレントゲン写真だ！ Oracle Database (全部俺）Advent Calendar 2022 Day 13 / No.48 / MULTI-TABLE INSERT

Previously on Mac De Oracle... Day 12は, TEMP TABLE TRANSFORMATIONにフォーカスをあてました. WITH句以外でも内部的に行われますが, 一時表へのマテリアライズを意図した話ではありますが, クソでかSQLの可読性向上のために利用されることも少なくなく, そのようなケースではインラインビューとして展開されるとうお話しでした. オプティマイザが間違えなければ:)

それでは, Day 13 の窓を開けましょう！.

今日は, MULTI-TABLE INSERT　です. え！, INSERT文なのに？　みたいに思った方もいるかもしれませんが, MULTI-TABLE INSERTは特徴的なOperationgが現れるので, 知っていた方が良いですよ. ただ, この構文自体はOracleの方言なので, なかなかお目にかからない（マルチテーブルインサート自体は他のRDBMSにもありますが, 癖の多い部分の一つなので）のですがねw　良い機能だと思いますけどね！
では, 診ていこうと思います.

いつもと同じように 21c で確認します.

SCOTT@orclpdb1> select banner from v$version;

BANNER
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

Oracle Database 23cからdualを省略できるようになるらしいですが！　21cまでは, MULTI TABLE INSERTを利用する場合, SELECT * FROM dual　が必須です. 不要になるとかなり便利ですよね.
以下では, 文字通り複数表へINSERTしていますが, a href="https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2020/12/post-10aa61.html">同一表へ複数行INSERTすることもできます. 何気に便利でしょこれ.

SCOTT@orclpdb1> @day13
  1  INSERT ALL
  2    INTO emp(empno, ename) VALUES(7788, 'Lucky')
  3    INTO dept(deptno, dname) VALUES(88, 'QA')
  4* SELECT * FROM dual

2行が作成されました. 

さて, 実行計画は, どうでしょうか. MULTI-TABLE INSERTに加えて, INTOが複数現れます. 現状, FAST DUALも出ますけど:)

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

--------------------------------------------------------------------
| Id  | Operation           | Name | Rows  | Cost (%CPU)| Time     |
--------------------------------------------------------------------
|   0 | INSERT STATEMENT    |      |     1 |     2   (0)| 00:00:01 |
|   1 |  MULTI-TABLE INSERT |      |       |            |          |
|   2 |   FAST DUAL         |      |     1 |     2   (0)| 00:00:01 |
|   3 |   INTO              | EMP  |       |            |          |
|   4 |   INTO              | DEPT |       |            |          |
--------------------------------------------------------------------

統計
----------------------------------------------------------
          6  recursive calls
         11  db block gets
         10  consistent gets
          4  physical reads
       1288  redo size
        188  bytes sent via SQL*Net to client
         41  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
          2  rows processed

この手の方言って, SQL標準で使用禁止みたいに書かれてたりすることが多くて, なんで？という気はします. 方言でも性能面で有利に働くのであれば例外は設けておくべきだと, 個人的は思うんですよね.
昔. 階層問合せ使わずに（典型的なSQLアンチパターンで）ヒーヒー言ってた現場を思い出したり. かなり昔ですけどね　ー＞　その現場へ有用性説明し階層問い合わせに書き換えたことで, 皆さん幸せな感じになってましたよーと：）

調子が出てきたので, また明日も, 担当は, 私です！

ではでは.

---

Related article on Mac De Oracle

・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒント と　手書きSQLのレントゲンの見分け方
・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 /　TEMP TABLE TRANSFORMATION

実行計画は, SQL文のレントゲン写真だ！ Oracle Database (全部俺）Advent Calendar 2022 Day 12 / No.47 / TEMP TABLE TRANSFORMATION

Previously on Mac De Oracle... Day 11は, GROUPING SETS, ROLLUP, CUBEでした. ROLLUP, CUBEが登場したのは, Oracle Database 8i なので, 1999年あたりだったと思います. それまでUNIONを使ったクソ重, クソクエリーが多かった記憶はありますw　ROLLUP, CUBEが神様に見えましたものw　

それでは, Day 12 の窓を開けましょう！.

今日の実行計画という名のレントゲンは, TEMP TABLE TRANSFORMATION です. 内部的に変換されて行われて現れることもあるこのOperationですが, 意図的にTEMP TABLE TRANSFORMATIONに行う場合で有名なのはCTEではないでしょうか？
類似する話題LOAD AS SELECT (CURSOR DURATION MEMORY)を取り上げていました, 内容としては11g,12c,18c,19cの差異の話。今回はその元となるTEMP TABLE TRANSFORMATIONにフォーカスをあてます。

では診ていこうと思います.

いつもと同じように 21c で確認します.

SCOTT@orclpdb1> select banner from v$version;

BANNER
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

ちなみに, WITH句でCTEを使ったら必ず, TEMP TABLE TRANSFORMATION　でマテリアライズされるということでもなく, マテリアライズするよ理, インラインビューのままでいいよねとオプティマイザが判断してインラインビューとして展開する場合もあります. それを強制する　INLINE というヒントもあります.
WITH句が利用されるケースの１つとして, 可読性向上だけを目的としている場合WITH句で定義されたクエリーが一度しか参照されていないようなケースでは, マテリアライズして一時表作るよりインラインビューで十分という判断でそのような最適化が行われます:)
逆に, マテリアライズして, 一時表に変換してほいしケースもあります. （複数回参照しているのに....みたいな場合ですね. 場合は, MATERIALIZE ヒントでオプティマイザヒントに教えてあげましょう. 最近ミスらなくなった気がしないでもない. オプティマイザも進化してますからね）

以下, オプティマイザはCTEと認識して, 一時表へマテリアライズした上で, 一時票表を再利用しています.

SCOTT@orclpdb1> @day12
  1  WITH temp_emp AS
  2  (
  3   SELECT
  4     emp.*
  5     ,dept.dname
  6   FROM
  7     emp
  8     INNER JOIN dept
  9     ON
 10       emp.deptno = dept.deptno
 11  )
 12  SELECT
 13    *
 14  FROM
 15    temp_emp
 16  WHERE
 17    temp_emp.empno = 7369
 18  UNION
 19  SELECT
 20    *
 21  FROM
 22    temp_emp
 23  WHERE
 24*   temp_emp.deptno = 20

     EMPNO ENAME                          JOB                                MGR HIREDATE        SAL       COMM     DEPTNO DNAME
---------- ------------------------------ --------------------------- ---------- -------- ---------- ---------- ---------- ------------------------------------------
      7369 SMITH                          CLERK                             7902 80-12-17        800                    20 RESEARCH
      7902 FORD                           ANALYST                           7566 81-12-03       3000                    20 RESEARCH
      7566 JONES                          MANAGER                           7839 81-04-02       2975                    20 RESEARCH

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

----------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                         |                           |     8 |   768 |     6  (34)| 00:00:01 |
|   1 |  TEMP TABLE TRANSFORMATION               |                           |       |       |            |          |
|   2 |   LOAD AS SELECT (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D665A_DDA815 |       |       |            |          |
|   3 |    MERGE JOIN                            |                           |     4 |   208 |     6  (17)| 00:00:01 |
|   4 |     TABLE ACCESS BY INDEX ROWID          | DEPT                      |     4 |    52 |     2   (0)| 00:00:01 |
|   5 |      INDEX FULL SCAN                     | PK_DEPT                   |     4 |       |     1   (0)| 00:00:01 |
|*  6 |     SORT JOIN                            |                           |     4 |   156 |     4  (25)| 00:00:01 |
|*  7 |      TABLE ACCESS FULL                   | EMP                       |     4 |   156 |     3   (0)| 00:00:01 |
|   8 |   HASH UNIQUE                            |                           |     8 |   768 |     6  (34)| 00:00:01 |
|   9 |    UNION-ALL                             |                           |       |       |            |          |
|* 10 |     VIEW                                 |                           |     4 |   384 |     2   (0)| 00:00:01 |
|  11 |      TABLE ACCESS FULL                   | SYS_TEMP_0FD9D665A_DDA815 |     4 |   196 |     2   (0)| 00:00:01 |
|* 12 |     VIEW                                 |                           |     4 |   384 |     2   (0)| 00:00:01 |
|  13 |      TABLE ACCESS FULL                   | SYS_TEMP_0FD9D665A_DDA815 |     4 |   196 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------------

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

   6 - access("EMP"."DEPTNO"="DEPT"."DEPTNO")
       filter("EMP"."DEPTNO"="DEPT"."DEPTNO")
   7 - filter("EMP"."DEPTNO"=20 OR "EMP"."EMPNO"=7369)
  10 - filter("TEMP_EMP"."EMPNO"=7369)
  12 - filter("TEMP_EMP"."DEPTNO"=20)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          8  consistent gets
          0  physical reads
          0  redo size
       1362  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          3  rows processed

CTEの一時表へのマテリアライズを　INLINE　ヒントでインラインに展開するようにした例です. 一時表へのマテリアライズが抑止され, SQL本文に同一クエリーが展開されている様子が見えます.
WITH句がサポートされていなかった頃は, 事前に一時表を作成して使ったり苦労していたことを思うと, これも非常に便利な機能ですよね.

  1  WITH temp_emp AS
  2  (
  3   SELECT
  4     /*+
  5       inline
  6     */
  7     emp.*
  8     ,dept.dname
  9   FROM
 10     emp
 11     INNER JOIN dept
 12     ON
 13       emp.deptno = dept.deptno
 14  )
 15  SELECT
 16    *
 17  FROM
 18    temp_emp
 19  WHERE
 20    temp_emp.empno = 7369
 21  UNION
 22  SELECT
 23    *
 24  FROM
 25    temp_emp
 26  WHERE
 27*   temp_emp.deptno = 20

     EMPNO ENAME                          JOB                                MGR HIREDATE        SAL       COMM     DEPTNO DNAME
---------- ------------------------------ --------------------------- ---------- -------- ---------- ---------- ---------- ------------------------------------------
      7369 SMITH                          CLERK                             7902 80-12-17        800                    20 RESEARCH
      7566 JONES                          MANAGER                           7839 81-04-02       2975                    20 RESEARCH
      7902 FORD                           ANALYST                           7566 81-12-03       3000                    20 RESEARCH

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

---------------------------------------------------------------------------------------------------
| Id  | Operation                              | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                       |          |     4 |   208 |     5  (20)| 00:00:01 |
|   1 |  HASH UNIQUE                           |          |     4 |   208 |     5  (20)| 00:00:01 |
|   2 |   UNION-ALL                            |          |       |       |            |          |
|   3 |    NESTED LOOPS                        |          |     1 |    52 |     2   (0)| 00:00:01 |
|   4 |     TABLE ACCESS BY INDEX ROWID        | EMP      |     1 |    39 |     1   (0)| 00:00:01 |
|*  5 |      INDEX UNIQUE SCAN                 | PK_EMP   |     1 |       |     0   (0)| 00:00:01 |
|   6 |     TABLE ACCESS BY INDEX ROWID        | DEPT     |     1 |    13 |     1   (0)| 00:00:01 |
|*  7 |      INDEX UNIQUE SCAN                 | PK_DEPT  |     1 |       |     0   (0)| 00:00:01 |
|   8 |    NESTED LOOPS                        |          |     3 |   156 |     2   (0)| 00:00:01 |
|   9 |     TABLE ACCESS BY INDEX ROWID        | DEPT     |     1 |    13 |     1   (0)| 00:00:01 |
|* 10 |      INDEX UNIQUE SCAN                 | PK_DEPT  |     1 |       |     0   (0)| 00:00:01 |
|  11 |     TABLE ACCESS BY INDEX ROWID BATCHED| EMP      |     3 |   117 |     1   (0)| 00:00:01 |
|* 12 |      INDEX RANGE SCAN                  | IX01_EMP |     3 |       |     0   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------

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

   5 - access("EMP"."EMPNO"=7369)
   7 - access("EMP"."DEPTNO"="DEPT"."DEPTNO")
  10 - access("DEPT"."DEPTNO"=20)
  12 - access("EMP"."DEPTNO"=20)

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

サッカーの判定に利用されているVAR(Video Assistant Referee)ですが, 人の判断だと微妙なところとは人それぞれのブレが現れるので, テニスでもそうですがわかりやすいので良いんじゃないかと思いますが. ね. （ここ数日そういうブレによる判定へ意義申し立てしたりしてるw　しかも見落としだし原因は. ）

でちょいと, めんどくせーなーとなっていたりしているわけですけども.

それはさておき.

明日も, アドベントの担当は私ですw

ではまた.

参考）

SCOTT@orclpdb1> select name,inverse, sql_feature from v$sql_hint where name in ('INLINE');

NAME                 INVERSE              SQL_FEATURE
-------------------- -------------------- ------------------------------
INLINE               MATERIALIZE          QKSFM_TRANSFORMATION

---

Related article on Mac De Oracle

・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒント と　手書きSQLのレントゲンの見分け方
・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE

実行計画は, SQL文のレントゲン写真だ！ Oracle Database (全部俺）Advent Calendar 2022 Day 11 / No.46 / GROUPING SETS, ROLLUP, CUBE

Previously on Mac De Oracle... Day 10は, MAT_VIEW REWRITE ACCESS FULLでした. Materialized Viewアクセスへ内部でRewriteする機能は随分前からありますが, Oracle Databaseらしい機能の一つだなぁ. と思います. 6.7 Using Real-time Materialized Viewsのように既存機能のブラッシュアップなど継続的に細かい改善が行われていたりします.

それでは, Day 11 の窓を開けましょう！.

まだ紹介していない既存の実行計画多いんですよね. SQLもそうですが, 実行計画になるとますます奥が深いですといいますか, このシリーズ, ネタは沢山あるので当分持ちそうですw

まず, 2011年の面倒くさい大人の事情縛りシリーズのネタですが, 考え方は今でも同じなので, 一度, 軽く眺めておいてください. その間に準備しますのでw.. (違
なお, SQLヒントの書き方で, 最近, ヒントが利用されたかどうかレポートされるようになったことで, USE_HASH, USE_NLのヒントの書き方が云々とかいう話をたまに聞きますが, エラーではなくて無視されるというのが仕様なので, それをうまく利用した使い方を, 面倒くさい大人の事情だらけの現場で考えて今に至った結果であるということは, いずれどこかで説明したいとは思います. （ポイントはチューニングする際の手間削減だったり, どこまで固定するべきか, しないほうが良いかという判断だったりします. 経年で変化もしますからね. ただ, それが手癖になっているという点は否めないわけですけども）
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #1
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #2
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #3
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #4
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #5
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #6
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #7 おまけ
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング８ おまけのおまけ
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング番外編

昔の2011年ぐらいの頃の　Oracle Database の実行計画を見たことない年齢のエンジニア多くなってきているとは思いますが, どうでしたか？　上記の過去エントリー. 今でも考え方の基本のキです.

ということで, やっと, 今日の本題です.

データはなくても想定した実行計画のキーワードは取得できるので, 表（データなし）と索引だけ作っておきます. （データ登録するのが面倒だったということでもありますが, 影響はないのでw）
なお, 以下表は, ・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #1で利用したものと同一です.

SCOTT@orclpdb1> @day11
  1* drop table test1

表が削除されました. 

経過: 00:00:00.04
  1  create table test1
  2  (
  3  	starting_date char(8) not null,
  4  	shop_code char(4) not null,
  5  	sales_figure number not null,
  6  	item_code char(10) not null,
  7  	constraint pk_test1 primary key (starting_date,item_code,shop_code) using index nologging
  8  )
  9* nologging

表が作成されました. 

経過: 00:00:00.02
  1* drop table test2

表が削除されました. 

経過: 00:00:00.05
  1  create table test2
  2  (
  3  	starting_date char(8) not null,
  4  	shop_code char(4) not null,
  5  	sales_figure number not null,
  6  	item_code char(10) not null,
  7  	constraint pk_test2 primary key (starting_date,item_code,shop_code) using index global nologging
  8  )
  9  partition by hash(starting_date)
 10  (
 11   	partition test201,
 12   	partition test202,
 13   	partition test203,
 14   	partition test204
 15  )
 16* nologging

表が作成されました. 

経過: 00:00:00.02
  1* drop table test3

表が削除されました. 

経過: 00:00:00.07
  1  create table test3
  2  (
  3  	starting_date char(8) not null,
  4  	shop_code char(4) not null,
  5  	sales_figure number not null,
  6  	item_code char(10) not null,
  7  	constraint pk_test3 primary key (starting_date,item_code,shop_code) using index local
  8  	(
  9  		partition test301idx,
 10  		partition test302idx,
 11  		partition test303idx,
 12  		partition test304idx,
 13  		partition test305idx,
 14  		partition test306idx,
 15  		partition test307idx,
 16  		partition test308idx,
 17  		partition test309idx,
 18  		partition test310idx,
 19  		partition test311idx,
 20  		partition test312idx,
 21  		partition testmaxidx
 22  	)
 23  	nologging
 24   )
 25   partition by range(starting_date) (
 26   	partition test301 values less than ('20110201') ,
 27   	partition test302 values less than ('20110301') ,
 28   	partition test303 values less than ('20110401') ,
 29   	partition test304 values less than ('20110501') ,
 30  	partition test305 values less than ('20110601') ,
 31  	partition test306 values less than ('20110701') ,
 32  	partition test307 values less than ('20110801') ,
 33  	partition test308 values less than ('20110901') ,
 34  	partition test309 values less than ('20111001') ,
 35  	partition test310 values less than ('20111101') ,
 36  	partition test311 values less than ('20111201') ,
 37  	partition test312 values less than ('20120101') ,
 38   	partition testmax values less than (maxvalue)
 39  )
 40* nologging

表が作成されました. 

経過: 00:00:00.05

GROUPING SETSから.
GROUPING SETSというキーワードは実行計画には現れまん. 内部で後半で説明するROLLUPが含まれる一時表が生成されるように書き換えられる挙動が特徴です. 2011の頃の実行計画と大きく違うのは, CURSOR DURATION MEMORYなんて操作が行われてるあたりですね.
GROUPING SETSというキーワードはないですが, 内部的には, CTEが利用されてROLLUP等と併用されている挙動なので, CTEによる一時表の生成コストがポイントになります. 最近はSSDがほとんどだろうと思うので, HDDだった頃ほど, 一時表の生成コストは気にならないケースも多いかもしれないですけども, 状況次第, どこまでチューニングするか次第というところはありますよね.

  1  SELECT
  2       CASE
  3          WHEN quarter IS NULL THEN month
  4          ELSE quarter
  5       END AS month
  6      ,CASE
  7          WHEN grouping_id = 1 THEN 'ALL'
  8          ELSE shop_code
  9       END AS shop_code
 10     ,sales_figure
 11  FROM (
 12     SELECT
 13          grouping_id(shop_code) as grouping_id
 14         ,quarter
 15         ,month
 16         ,shop_code
 17         ,SUM(sales_figure) AS sales_figure
 18     FROM
 19     (
 20         SELECT
 21             CASE
 22                 WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
 23                 WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
 24                 WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 25                 WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 26             END AS quarter
 27             ,SUBSTR(starting_date,1,6) AS month
 28             ,shop_code
 29             ,sales_figure
 30         FROM
 31             test2
 32         WHERE
 33             SUBSTR(starting_date,1,6) BETWEEN '201101' AND '201103'
 34     )
 35     GROUP BY GROUPING SETS (
 36         (month, shop_code),
 37         (quarter, shop_code),
 38         (month),
 39         (quarter)
 40     )
 41  )
 42  WHERE
 43         shop_code = '1000'
 44      OR grouping_id  = 1
 45  ORDER BY
 46       month
 47*     ,shop_code

レコードが選択されませんでした. 

経過: 00:00:00.03

レコードが選択されませんでした. 

経過: 00:00:00.01

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

----------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                  | Name                      | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                           |                           |     1 |    50 |    11  (28)| 00:00:01 |       |       |
|   1 |  SORT ORDER BY                             |                           |     1 |    50 |    11  (28)| 00:00:01 |       |       |
|   2 |   VIEW                                     |                           |     1 |    50 |    10  (20)| 00:00:01 |       |       |
|   3 |    TEMP TABLE TRANSFORMATION               |                           |       |       |            |          |       |       |
|   4 |     LOAD AS SELECT (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D6620_DD3617 |       |       |            |          |       |       |
|   5 |      PARTITION HASH ALL                    |                           |     1 |    29 |     2   (0)| 00:00:01 |     1 |     4 |
|*  6 |       TABLE ACCESS FULL                    | TEST2                     |     1 |    29 |     2   (0)| 00:00:01 |     1 |     4 |
|   7 |     LOAD AS SELECT (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D6621_DD3617 |       |       |            |          |       |       |
|   8 |      HASH GROUP BY ROLLUP                  |                           |     1 |    29 |     3  (34)| 00:00:01 |       |       |
|   9 |       TABLE ACCESS FULL                    | SYS_TEMP_0FD9D6620_DD3617 |     1 |    29 |     2   (0)| 00:00:01 |       |       |
|  10 |     LOAD AS SELECT (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D6621_DD3617 |       |       |            |          |       |       |
|  11 |      HASH GROUP BY ROLLUP                  |                           |     1 |    23 |     3  (34)| 00:00:01 |       |       |
|  12 |       TABLE ACCESS FULL                    | SYS_TEMP_0FD9D6620_DD3617 |     1 |    23 |     2   (0)| 00:00:01 |       |       |
|  13 |     VIEW                                   |                           |     1 |    50 |     2   (0)| 00:00:01 |       |       |
|* 14 |      TABLE ACCESS FULL                     | SYS_TEMP_0FD9D6621_DD3617 |     1 |    29 |     2   (0)| 00:00:01 |       |       |
----------------------------------------------------------------------------------------------------------------------------------------

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

   6 - filter(SUBSTR("SYS_TBL_$1$"."STARTING_DATE",1,6)>='201101' AND SUBSTR("SYS_TBL_$1$"."STARTING_DATE",1,6)<='201103')
  14 - filter("SYS_TEMP_0FD9D6621_DD3617"."C1"='1000' OR BIN_TO_NUM(SYS_OP_VECBIT(SYS_OP_NUMTORAW("SYS_TEMP_0FD9D6621_DD3617"."D
              0"),1))=1)

Hint Report (identified by operation id / Query Block Name / Object Alias):
Total hints for statement: 1 (U - Unused (1))
---------------------------------------------------------------------------

  13 -  SEL$80FD2AB9
         U -  NO_MERGE

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)

統計
----------------------------------------------------------
          0  recursive calls
          2  db block gets
          0  consistent gets
          0  physical reads
        384  redo size
        542  bytes sent via SQL*Net to client
         41  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          0  rows processed

次に, ROLLUP. GROUPPING SETSで内部的に行われていますが, 実際にROLLUPを実行するとこうなります. （最初のSQL分とは集計内容が異なるので結果は同一ではないことはお気づきだと思います. データが無い状態で実行しているのでわかりづらいですが, ご注意くさだい）

  1  SELECT
  2     CASE
  3         WHEN grouping_id(month) = 1 THEN
  4             CASE
  5                 WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0406' THEN 'Q1'
  6                 WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0709' THEN 'Q2'
  7                 WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '1012' THEN 'Q3'
  8                 WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0103' THEN 'Q4'
  9             END
 10          ELSE month
 11      END AS month
 12     ,CASE
 13          WHEN grouping_id(shop_code) = 1 THEN 'ALL'
 14          ELSE shop_code
 15      END AS shop_code
 16     ,SUM(sales_figure) AS sales_figure
 17  FROM
 18      (
 19          SELECT
 20               SUBSTR(starting_date,1,6) AS month
 21              ,shop_code
 22              ,SUM(sales_figure) AS sales_figure
 23          FROM
 24              test2
 25          WHERE
 26              starting_date BETWEEN '20110101' AND '20110331'
 27          GROUP BY
 28              SUBSTR(starting_date,1,6)
 29             ,shop_code
 30      )
 31  GROUP BY
 32      ROLLUP(month,shop_code)
 33  HAVING
 34      shop_code = '1000'
 35      OR grouping_id(shop_code) = 1
 36  ORDER BY
 37      month
 38*    ,shop_code

レコードが選択されませんでした. 

経過: 00:00:00.02

レコードが選択されませんでした. 

経過: 00:00:00.01

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

----------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                       | Name     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                                |          |     1 |    33 |     4  (75)| 00:00:01 |       |       |
|   1 |  SORT ORDER BY                                  |          |     1 |    33 |     4  (75)| 00:00:01 |       |       |
|*  2 |   FILTER                                        |          |       |       |            |          |       |       |
|   3 |    HASH GROUP BY ROLLUP                         |          |     1 |    33 |     4  (75)| 00:00:01 |       |       |
|   4 |     VIEW                                        |          |     1 |    33 |     2  (50)| 00:00:01 |       |       |
|   5 |      HASH GROUP BY                              |          |     1 |    29 |     2  (50)| 00:00:01 |       |       |
|   6 |       TABLE ACCESS BY GLOBAL INDEX ROWID BATCHED| TEST2    |     1 |    29 |     1   (0)| 00:00:01 | ROWID | ROWID |
|*  7 |        INDEX RANGE SCAN                         | PK_TEST2 |     1 |       |     1   (0)| 00:00:01 |       |       |
----------------------------------------------------------------------------------------------------------------------------

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

   2 - filter("SHOP_CODE"='1000' OR GROUPING_ID(BIN_TO_NUM(SYS_OP_GROUPING("SHOP_CODE",1,0,SYS_OP_BITVEC)))=1)
   7 - access("STARTING_DATE">='20110101' AND "STARTING_DATE"<='20110331')

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
        542  bytes sent via SQL*Net to client
         41  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          0  rows processed

最後は, CUBEです. これは, GROUPING SETSで行っていたことと同じことをCUBEを使って実現しています. 同じ結果を得るのであれば, CUBEの方が有利そうだ, という点に気づいた方は多いだろう思います:)

  1  SELECT
  2     CASE
  3         WHEN grouping_id(month) = 1 THEN
  4             CASE
  5                 WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0406' THEN 'Q1'
  6                 WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0709' THEN 'Q2'
  7                 WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '1012' THEN 'Q3'
  8                 WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0103' THEN 'Q4'
  9             END
 10          ELSE month
 11      END AS month
 12     ,CASE
 13          WHEN grouping_id(shop_code) = 1 THEN 'ALL'
 14          ELSE shop_code
 15      END AS shop_code
 16     ,SUM(sales_figure) AS sales_figure
 17  FROM
 18      (
 19          SELECT
 20               SUBSTR(starting_date,1,6) AS month
 21              ,shop_code
 22              ,SUM(sales_figure) AS sales_figure
 23          FROM
 24              test2
 25          WHERE
 26              starting_date BETWEEN '20110101' AND '20110331'
 27          GROUP BY
 28              SUBSTR(starting_date,1,6)
 29             ,shop_code
 30      )
 31  GROUP BY
 32      CUBE(month,shop_code)
 33  HAVING
 34      shop_code = '1000'
 35      OR grouping_id(shop_code) = 1
 36  ORDER BY
 37      month
 38*    ,shop_code

レコードが選択されませんでした. 

経過: 00:00:00.01

レコードが選択されませんでした. 

経過: 00:00:00.00

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

------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                         | Name     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                                  |          |     1 |    33 |     4  (75)| 00:00:01 |       |       |
|   1 |  SORT ORDER BY                                    |          |     1 |    33 |     4  (75)| 00:00:01 |       |       |
|*  2 |   FILTER                                          |          |       |       |            |          |       |       |
|   3 |    SORT GROUP BY                                  |          |     1 |    33 |     4  (75)| 00:00:01 |       |       |
|   4 |     GENERATE CUBE                                 |          |     1 |    33 |     4  (75)| 00:00:01 |       |       |
|   5 |      SORT GROUP BY                                |          |     1 |    33 |     4  (75)| 00:00:01 |       |       |
|   6 |       VIEW                                        |          |     1 |    33 |     2  (50)| 00:00:01 |       |       |
|   7 |        HASH GROUP BY                              |          |     1 |    29 |     2  (50)| 00:00:01 |       |       |
|   8 |         TABLE ACCESS BY GLOBAL INDEX ROWID BATCHED| TEST2    |     1 |    29 |     1   (0)| 00:00:01 | ROWID | ROWID |
|*  9 |          INDEX RANGE SCAN                         | PK_TEST2 |     1 |       |     1   (0)| 00:00:01 |       |       |
------------------------------------------------------------------------------------------------------------------------------

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

   2 - filter("SHOP_CODE"='1000' OR GROUPING_ID(BIN_TO_NUM(SYS_OP_GROUPING("SHOP_CODE",1,0,SYS_OP_BITVEC)))=1)
   9 - access("STARTING_DATE">='20110101' AND "STARTING_DATE"<='20110331')

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
        542  bytes sent via SQL*Net to client
         41  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          3  sorts (memory)
          0  sorts (disk)
          0  rows processed

アドベントカレンダー書いているだけで, 12月が終わってしまう気がするw

ということを, 言っても, やはり, 明日も担当は, 私ですw

では, また.

参考） Oracle Database 21c - Data Warehousing Guide / 21 SQL for Aggregation in Data Warehouses

---

Related article on Mac De Oracle ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒント と　手書きSQLのレントゲンの見分け方
・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4 / No.39 / In-Memory Hybrid Scans
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 6 / No.41 / In-Memory Vectorized Join
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 7 / No.42 / INDEX RANGE SCAN (MULTI VALUE)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 8 / No.43 / TABLE ACCESS BY INDEX ROWID BATCHED
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 9 / No.44 / COLLECTION ITERATOR PICKLER FETCH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 10 / No.45 / MAT_VIEW REWRITE ACCESS FULL

実行計画は, SQL文のレントゲン写真だ！ Oracle Database (全部俺）Advent Calendar 2022 Day 5 / No.40 / PIVOT and UNPIVOT

Previously on Mac De Oracle...
Day 4は, SQLというより, in-memory operationに追加された, In-Memory Hybrid Scans　の実行計画という名のレントゲンをみながら, どのような状況で発動するのかを簡単に確認しましたー.

なかな面白い動きでしたね. 別途時間を取って深掘りしないとね, と. :)

ということで, Day 5 の窓を開けましょう. 今日は, 新機能というより以前からあったのにレントゲン取ってなかったよね？　ということで　PIVOT and UNPIVOT　を診てみたいと思います.

いつもと同じように 21c で確認します.

SCOTT@orclpdb1> select banner from v$version;

BANNER
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production

最初は, pivot 向けデータの準備から

SCOTT@orclpdb1> @day5

表が削除されました. 

  1  CREATE TABLE for_pivot
  2  AS
  3  SELECT
  4    stat_name
  5  , value
  6  FROM
  7    v$sys_time_model
  8  WHERE
  9    stat_name IN (
 10      'DB time'
 11    , 'DB CPU'
 12    , 'background elapsed time'
 13    , 'background cpu time'
 14*   )

表が作成されました. 

  1* CREATE INDEX ix_for_pivot ON for_pivot(stat_name)

索引が作成されました. 

  1  SELECT
  2    *
  3  FROM
  4*   for_pivot

STAT_NAME                           VALUE
------------------------------ ----------
DB time                         143415979
DB CPU                          127540525
background elapsed time           7381483
background cpu time               6340262
/code>

PIVOTで行持ちを列持ちに変換してみます.

おお, 実行計画には, PIVOT とか出ないのですよーーーー！！　（知ってましたか！
こいつも実行計画を見ただけでは, PIVOTが行われているかは読み取れないですねw　アクセスパス以外は注意する箇所はあまりないわけですけども:)

  1  SELECT
  2    db_time
  3   ,db_cpu
  4  FROM
  5  (
  6    SELECT
  7      stat_name
  8    , value
  9    FROM
 10      for_pivot
 11    WHERE
 12      stat_name IN ('DB time', 'DB CPU')
 13  )
 14  PIVOT
 15  (
 16    MAX(value)
 17    FOR stat_name IN
 18    (
 19      'DB time' AS db_time
 20     ,'DB CPU' AS db_cpu
 21    )
 22* )

   DB_TIME     DB_CPU
---------- ----------
 143415979  127540525


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

-------------------------------------------------------------------------------------------------------
| Id  | Operation                              | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                       |              |     1 |    26 |     2   (0)| 00:00:01 |
|   1 |  VIEW                                  |              |     1 |    26 |     2   (0)| 00:00:01 |
|   2 |   SORT AGGREGATE                       |              |     1 |    22 |            |          |
|   3 |    INLIST ITERATOR                     |              |       |       |            |          |
|   4 |     TABLE ACCESS BY INDEX ROWID BATCHED| FOR_PIVOT    |     2 |    44 |     2   (0)| 00:00:01 |
|*  5 |      INDEX RANGE SCAN                  | IX_FOR_PIVOT |     2 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------

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

   5 - access("STAT_NAME"='DB CPU' OR "STAT_NAME"='DB time')

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          3  consistent gets
          0  physical reads
          0  redo size
        677  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
/code>

次に, UNPIVOT 向けデータの準備

表が削除されました. 

  1  CREATE TABLE for_unpivot
  2  AS
  3  SELECT
  4  	db_time
  5  	,db_cpu
  6  	,bg_time
  7  	,bg_cpu
  8  FROM
  9  	(
 10  		SELECT
 11  			stat_name
 12  			,value
 13  		FROM
 14  			v$sys_time_model
 15  	)
 16  PIVOT
 17  	(
 18  		MAX(value)
 19  		FOR stat_name IN
 20  			(
 21  				'DB time' AS db_time
 22  				,'DB CPU' AS db_cpu
 23  				,'background elapsed time' AS bg_time
 24  				,'background cpu time' AS bg_cpu
 25  			)
 26* 	)

表が作成されました. 

  1* COMMIT

コミットが完了しました. 

  1  SELECT
  2    *
  3  FROM
  4*   for_unpivot

   DB_TIME     DB_CPU    BG_TIME     BG_CPU
---------- ---------- ---------- ----------
 143522885  127634777    7381483    6340262
/code>

UNPIVOT では, PIVOT とは異なり, 実行計画上 UNPIVOT であることが読み取れます！！！　ここ試験に出ますよ！（嘘w

  1  SELECT
  2    stat_name
  3  , value
  4  FROM
  5    for_unpivot
  6  UNPIVOT
  7  (
  8    value FOR stat_name IN
  9    (
 10        db_time
 11      , db_cpu
 12      , bg_time
 13      , bg_cpu
 14    )
 15  )
 16* ORDER BY stat_name

STAT_NAME                           VALUE
------------------------------ ----------
BG_CPU                            6340262
BG_TIME                           7381483
DB_CPU                          127634777
DB_TIME                         143522885

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

------------------------------------------------------------------------------------
| Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |             |     4 |    72 |     6  (17)| 00:00:01 |
|   1 |  SORT ORDER BY       |             |     4 |    72 |     6  (17)| 00:00:01 |
|*  2 |   VIEW               |             |     4 |    72 |     5   (0)| 00:00:01 |
|   3 |    UNPIVOT           |             |       |       |            |          |
|   4 |     TABLE ACCESS FULL| FOR_UNPIVOT |     1 |    26 |     3   (0)| 00:00:01 |
------------------------------------------------------------------------------------

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

   2 - filter("unpivot_view_005"."VALUE" IS NOT NULL)

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          2  consistent gets
          0  physical reads
          0  redo size
        781  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          4  rows processed
/code>

ということで, 　Operation には, なぜ, UNPIVOT　は現れるのに, PIVOT が現れないのだろう. . . その謎を求め, 一向は洞窟の奥深くへ進んでいくのであった. . . .

昔からサポートされている PIVOT / UNPIVOT ですが, 改めて実行計画というレントゲンを診てみると, 新しい気づきとかあって良いですね.

参考 SQL Language Reference / PIVOT and UNPIVOT

Oracle Database 11g：Oracle ACEディレクター, Arup Nanda - PIVOT and UNPIVOT

ということで, 明日の担当は, またまた私ですw

---

Related article on Mac De Oracle ・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は, SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は, SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は, SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は, SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS
・実行計画は, SQL文のレントゲン写真だ！ No.34 - 似て非なるもの　USE_CONCAT　と　OR_EXPAND ヒント と　手書きSQLのレントゲンの見分け方
・実行計画は, SQL文のレントゲン写真だ！ No.35 - 似て非なるもの USE_CONCAT と OR_EXPANDヒントとパラレルクエリー
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 1　/ No.36 / INTERSECT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 2　/ No.37 / MINUS ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 3　/ No.38 / EXCEPT and EXCEPT ALL
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 4　/ No.39 / In-Memory Hybrid Scans

実行計画は、SQL文のレントゲン写真だ！ No.34 - 似て非なるもの USE_CONCAT と OR_EXPAND ヒント と 手書きSQLのレントゲンの見分け方

Previously on Mac De Oracle
前回のレントゲンは、BITMAP CONVERSION TO ROWIDSでした。複数の索引を同時に使うという昔からあるオペレーションでした。

今回は単にレントゲンを見ていくだけではなく、同じ問い合わせ結果（よくある間違いなどもいれてありますw）になるものの微妙に違うレントゲンをみつつ、元のSQL文、それに今回ヒントになにが使われているか、見ていきたいと思います。

これが前回のエントリで使ったSQL分です. 問い合わせ結果と実行計画（前回のエントリで取り上げたBITMAP CONVERSIONです。この問い合わせ結果と実行計画という名のレントゲンをよーーーーーーーーーく、覚えておいてくださいね。

いくつかのレントゲンを使って、これなーーーーーーーんだ？　wみたいなw

これが原型なので、覚えておいてください。

select
  *
from
  tab311
where
  unique_id= 1
  or sub_item_code = '0001000000';

UNIQUE_ID SUB_ITEM_CODE                  FOO                                                 IS_DELETE
---------- ------------------------------ -------------------------------------------------- ----------
         1 0000000002                     **************************************************          0
                                          **************************************************
                                          **************************************************
                                          **************************************************
                                          *************************************************1

         1 0001000001                     fooooooooooooo1                                             0
         2 0001000000                     fooooooo2                                                   0
         1 0001000000                     2****                                                       0

---------------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |                         |     5 |  1345 |     8  (13)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     5 |  1345 |     8  (13)| 00:00:01 |
|   2 |   BITMAP CONVERSION TO ROWIDS       |                         |       |       |            |          |
|   3 |    BITMAP OR                        |                         |       |       |            |          |
|   4 |     BITMAP CONVERSION FROM ROWIDS   |                         |       |       |            |          |
|   5 |      SORT ORDER BY                  |                         |       |       |            |          |
|*  6 |       INDEX RANGE SCAN              | TAB311_PK               |       |       |     3   (0)| 00:00:01 |
|   7 |     BITMAP CONVERSION FROM ROWIDS   |                         |       |       |            |          |
|*  8 |      INDEX RANGE SCAN               | TAB311_IX_SUB_ITEM_CODE |       |       |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------------

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

   6 - access("UNIQUE_ID"=1)
       filter("UNIQUE_ID"=1)
   8 - access("SUB_ITEM_CODE"='0001000000')

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

前回のエントリでも少し書いたのですが、CONCATENATION がレントゲンに現れるときは、BITMAP CONVERTなど効率が悪いOR条件の実行計画を改善するため、OR条件部分を分離排除し、2つの索引それぞれを有効に利用させるためのヒントによるチューニングで行なった場合が多いです。オプティマイザが選択するケースもありますが。

ヒントで強制的にすることもありますが、ヒントが効かないケースは多も多いのは事実です。理由は内部的に2つのクエリーに分解しているわけですが、それぞれで利用する索引のアクセス効率が悪いオプティマイザに見えている場合にはヒントが効かない場合が多いように思います。
なんとなーーーくざっくりなイメージですが、UNIONのような形に内部的に書き換えていると思うとわかりやすいかもしれないですね。。UNIONとでてないのでUNIONのようなものとしかかけないのですがW
とにかく、CONCATENATIONを見つけたら　USE_CONCAT ヒントでチューニングされてるね！
と脊髄反応できるようになっているとよいですね！

 UNIQUE_ID SUB_ITEM_CODE                  FOO                                                 IS_DELETE
---------- ------------------------------ -------------------------------------------------- ----------
         2 0001000000                     fooooooo2                                                   0
         1 0001000000                     2****                                                       0
         1 0000000002                     **************************************************          0
                                          **************************************************
                                          **************************************************
                                          **************************************************
                                          *************************************************1

         1 0001000001                     fooooooooooooo1                                             0

----------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                         |     5 |  1345 |    11   (0)| 00:00:01 |
|   1 |  CONCATENATION                       |                         |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
|   4 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  5 |    INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------

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

   3 - access("SUB_ITEM_CODE"='0001000000')
   5 - access("UNIQUE_ID"=1)
       filter(LNNVL("SUB_ITEM_CODE"='0001000000'))

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

上記のレントゲンの元はこれです。USE_CONCATヒント使われてますよね。このケースではオプティマイザは言うことを聞いてくれたようですね。w

select
  /*+
    use_concat
  */
  *
from
  tab311
where
  unique_id= 1
  or sub_item_code = '0001000000';

では、オプティマイザが言うことを聞いてくれなかった場合、Oracle Database 12c R1まではどうやって、治療していたか。知りたく無いですか？
USE_CONCATでUNIONのように内部的書き換えてくれると、SQLへはヒントの追加だけで済むので、同値検証等も不要で患者さんの痛みは少なくてすむわけですが、先にも買いたように必ず効くわけでもないという、ちょっと癖のあるヒントなんです。で、12c R1までは、しかたないの、SQL構文変更という中程度の難易度の手術（SQL書き換えw）が必要でした。

先ほと、UNIONのようにと書きましたが、まさに、それで、UNIONまたは、UNION ALLに書き換えてしまうという手術ですw

どちらでやってもよいのですが、重複データの排除がどれだけの負荷になるかというところかなと思います。重複排除するデータ量が多いのであれば UNION にしてHASH UNIQUEによる重複行排除の方がよいかもしれませんし、少量なら UNION ALLでフィルタリングによる重複行排除のほうがよいかもしれません。HASH UNIQUEにしてもPGA不足でTEMP落ちしてしまうようなことがあるのならフィルタリングのほうがよさそうですし、その時の状況次第かと思います。

では、ずは、UNION を使った書き換えから。

ソートしていないので並びが変わってますが、あえてソートしていません。Id=2のUNION-ALLとId=1にHASH UNIQUEというoperationがありますが、これが現在のUNIONの典型的なoperationです。HASH UNIQUEがなかったころは、SORT UNIQUEだったわけですが、その影響でデータがソートされていたので、諸々勘違いしてデフォルトでソートされるんだー、みたいな勘違いしている方も一定数存在していた時期があり、HASH UNIQUEがなって順序通りになってない！　と勝手にザワザワしていたこともありましたね。それ知ってる方々はOracleにながーーーーいこと関わっている方だと思いますw　注意しましょうね。思った通りの並びにしたい場合は、ちゃんとORDER BY句でソートしましょうね。（これ言いたかっただけw）
あと、最近は、UNIONをパラレル実行できるようになったので、その場合も、順序はバラバラになります。シリアルに実行している場合は上位にあるクエリから処理されるのでその順序で行が戻されていましたが、パラレルだと何が来るかはその時々ですね。

脇道にそれましたが、手書きでSQLを UNION に書き換えた場合のレントゲンはこんな感じです。UNION-ALLのオペレーションの後に重複行排除のUNIQUE操作が必ず入るので覚えやすいと思います。

 UNIQUE_ID SUB_ITEM_CODE                  FOO                                                 IS_DELETE
---------- ------------------------------ -------------------------------------------------- ----------
         1 0000000002                     **************************************************          0
                                          **************************************************
                                          **************************************************
                                          **************************************************
                                          *************************************************1

         1 0001000000                     2****                                                       0
         1 0001000001                     fooooooooooooo1                                             0
         2 0001000000                     fooooooo2                                                   0

-----------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                         |     5 |  1345 |    12   (9)| 00:00:01 |
|   1 |  HASH UNIQUE                          |                         |     5 |  1345 |    12   (9)| 00:00:01 |
|   2 |   UNION-ALL                           |                         |       |       |            |          |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
|   5 |    TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  6 |     INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------

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

   4 - access("UNIQUE_ID"=1)
   6 - access("SUB_ITEM_CODE"='0001000000')

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

もともとOR条件でしたが、それぞれの索引を有効に活用させるため、2つの文に分解し、それらを UNIONしています。UNIONで重複排除も行なっているわけです。

select
  *
from
  tab311
where
  unique_id = 1
union
select
  *
 from
   tab311
 where
   sub_item_code = '0001000000';

次に、UNION ALLへ手動で書き換えた場合はどうなるかレントゲンを見てみましょう。

結果も正しいです。レントゲンで見える UNION と UNION-ALLとの違いは、重複行排除のUNIQUEオペレーションが無いところです。Id=1にあるUNION-ALL だけで、 HASH UNIQUEがありません。
これ大丈夫なのでしょうか？　重複行を排除するオペレーションがないなんで、たまため結果が正しいだけでしょうか？？？

実は、実行計画に現れない違いが述語部分にあります。 Predicate Information (identified by operation id):セクションに 4 - filter(LNNVL("UNIQUE_ID"=1)) とあるのに気づきましたか？

4は、実行計画の Id = 4を示しています。これは Id = 4の TAB311のアクセス時に、"UNIQUE_ID"=1　であれば falseとして該当行をフィルタリングして捨てていることを意味しています。
つまり、UNIONで　HASH UNIQUEを行なっていた重複行を排除と同様の効果をえるフィルター条件なんです。この条件にで、 Id = 2 と Id = 3で取得されたUNIQUE_ID=1の行を捨てています

 UNIQUE_ID SUB_ITEM_CODE                  FOO                                                 IS_DELETE
---------- ------------------------------ -------------------------------------------------- ----------
         1 0000000002                     **************************************************          0
                                          **************************************************
                                          **************************************************
                                          **************************************************
                                          *************************************************1

         1 0001000000                     2****                                                       0
         1 0001000001                     fooooooooooooo1                                             0
         2 0001000000                     fooooooo2                                                   0

----------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                         |     5 |  1345 |    11   (0)| 00:00:01 |
|   1 |  UNION-ALL                           |                         |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
|*  4 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  5 |    INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------

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

   3 - access("UNIQUE_ID"=1)
   4 - filter(LNNVL("UNIQUE_ID"=1))
   5 - access("SUB_ITEM_CODE"='0001000000')

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

UNION ALLでの書き換えは、以下のようなSQL文でした。and LNNVL(unique_id=1)という条件追加がポイントです。

select
  *
from
  tab311
where
  unique_id = 1
union all
select
  *
from
  tab311
where
  sub_item_code = '0001000000'
  and LNNVL(unique_id=1);

では、つい忘れそうな、フィルター条件追加をわすれてUNION ALLにしてしまった場合はどうなるでしょう？　もう想像できますよねw

SQLの違いからみてみましょう。 and LNNVL(unique_id=1)　と言う条件が無いこと以外前述のSQLと同じです。

select
  *
from
  tab311
where
  unique_id = 1
union all
select
  *
from
  tab311
where
  sub_item_code = '0001000000';

実行してみると。。。。。あららららら、ちゃっしゃいましたな感じの結果ですねw Predicate Information (identified by operation id): には重複排除のフィルター条件は見当たりません。（当然ですね。書き忘れているわけですから）

UNIQUE_ID = 1　でもあり、SUB_ITEM_CODE = '0001000000' である行が2回リストされています。ざんねーーーん。注意しましょうね。

 UNIQUE_ID SUB_ITEM_CODE                  FOO                                                 IS_DELETE
---------- ------------------------------ -------------------------------------------------- ----------
         1 0000000002                     **************************************************          0
                                          **************************************************
                                          **************************************************
                                          **************************************************
                                          *************************************************1

         1 0001000000                     2****                                                       0
         1 0001000001                     fooooooooooooo1                                             0
         2 0001000000                     fooooooo2                                                   0
         1 0001000000                     2****                                                       0


----------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                         |     5 |  1345 |    11   (0)| 00:00:01 |
|   1 |  UNION-ALL                           |                         |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
|   4 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  5 |    INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------

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

   3 - access("UNIQUE_ID"=1)
   5 - access("SUB_ITEM_CODE"='0001000000')

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         10  consistent gets
          0  physical reads
          0  redo size
       1239  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          5  rows processed

よーーーーし、バグになるのが怖いから、常に　UNION だーーーと安全策に流れそうですが、性能面ではフィルタリングと HASH UNIQUE、または、SORT UNIQUEかということであれば、データ量次第でどちらが良いか判断した方がよいだろうと。個人的には思っています。フィルターしたほうが有利なケースも当然ありますし、しないほうが良い場合もあるでしょう。

最後に、今日のタイトルにも書いた NO_EXPAND これ少々気難しい、USE_CONCATの後継として 12c R2　で登場したヒントです。内部の書き換えもそれまでのCONCATENATIONではなく、UNION　ALLとフィルタリングにより重複行排除が行われるように、内部的に書き換えられるのが特徴です。なんでこれもっと早く実装してくれなかったんですかね？　強強ですね。USE_CONCATの気まぐれ感は消えてる感じがします。

事実、某所で、USE_CONCAT効かなくて、しぬーーーーーみたいな状況で、たまたま 12c R2だったので、NO_EXPAND　で回避したーーーーなんてこともありました。そういことで、USE_EXPANDをUSE_CONCATの代わりにUSE_EXPANDを使うことをおすすめしますw　（それ以外にもメリットも多いですし、それはまた、次回にでも）

select
  /*+
    or_expand
  */
  *
from
  tab311
where
  unique_id= 1
  or sub_item_code = '0001000000';

 UNIQUE_ID SUB_ITEM_CODE                  FOO                                                 IS_DELETE
---------- ------------------------------ -------------------------------------------------- ----------
         1 0000000002                     **************************************************          0
                                          **************************************************
                                          **************************************************
                                          **************************************************
                                          *************************************************1

         1 0001000000                     2****                                                       0
         1 0001000001                     fooooooooooooo1                                             0
         2 0001000000                     fooooooo2                                                   0

レントゲンを見ると、手書きで書いた UNION ALLへの書き換えと微妙に違うの気づきますか？　これまで紹介してきた手書きでの書き換えとヒントに夜書き換えは4つありますが、それぞれ実行計画に特徴があるんです。（もしかしたら将来は区別しにくくなるかもしれませんが、現状は区別できます！！！

OR_EXPANヒントでUNION ALL変換した場合 Id = 1にあるような、インラインビューがは登場します。VW_ORE_5F0E22D2　とオプティマイザが動的に名称をつけますが、ポイントは　VW_ORE_* というprefixが作ろころですね。VWはびゅー。OREは、OR_Expand の大文字部分みたいですねw　（そのうち内部的に生成されるインラインビュー名もまとめて紹介したいですね。すでに誰かやってそうな気もしますがw）

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

-----------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                         |     5 |  1450 |    11   (0)| 00:00:01 |
|   1 |  VIEW                                 | VW_ORE_5F0E22D2         |     5 |  1450 |    11   (0)| 00:00:01 |
|   2 |   UNION-ALL                           |                         |       |       |            |          |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
|*  5 |    TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  6 |     INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------

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

   4 - access("UNIQUE_ID"=1)
   5 - filter(LNNVL("UNIQUE_ID"=1))
   6 - access("SUB_ITEM_CODE"='0001000000')

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

長くなったので、まとめです。
ヒントによる OR条件のUNIONのような書き換えや、UNION ALLへの書き換え、または、人が UNION や UNION ALLへ手書きで書き換えたSQLのレントゲン、それぞれに特徴があり、4つとも、レントゲンから元のSQLがイメージできるんですよ！！！

USE_CONCATによる書き換え Oracle 8i 8.1以降〜

select
  /*+
    use_concat
  */
  *
from
  tab311
where
  unique_id= 1
  or sub_item_code = '0001000000';

----------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                         |     5 |  1345 |    11   (0)| 00:00:01 |
|   1 |  CONCATENATION                       |                         |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
|   4 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  5 |    INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------

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

   3 - access("SUB_ITEM_CODE"='0001000000')
   5 - access("UNIQUE_ID"=1)
       filter(LNNVL("SUB_ITEM_CODE"='0001000000'))

OR_EXPANDによる書き換え Oracle 12cR2以降〜

select
  /*+
    or_expand
  */
  *
from
  tab311
where
  unique_id= 1
  or sub_item_code = '0001000000';

-----------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                         |     5 |  1450 |    11   (0)| 00:00:01 |
|   1 |  VIEW                                 | VW_ORE_5F0E22D2         |     5 |  1450 |    11   (0)| 00:00:01 |
|   2 |   UNION-ALL                           |                         |       |       |            |          |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
|*  5 |    TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  6 |     INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------

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

   4 - access("UNIQUE_ID"=1)
   5 - filter(LNNVL("UNIQUE_ID"=1))
   6 - access("SUB_ITEM_CODE"='0001000000')

手動書き換え　UNION

select
  *
from
  tab311
where
  unique_id = 1
union
select
  *
 from
   tab311
 where
   sub_item_code = '0001000000';

-----------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                         |     5 |  1345 |    12   (9)| 00:00:01 |
|   1 |  HASH UNIQUE                          |                         |     5 |  1345 |    12   (9)| 00:00:01 |
|   2 |   UNION-ALL                            |                         |       |       |            |          |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
|   5 |    TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  6 |     INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------

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

   4 - access("UNIQUE_ID"=1)
   6 - access("SUB_ITEM_CODE"='0001000000')

手動書き換え　UNION ALL + 重複排除フィルター条件追加

select
  *
from
  tab311
where
  unique_id = 1
union all
select
  *
from
  tab311
where
  sub_item_code = '0001000000'
  and LNNVL(unique_id=1);

----------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                         |     5 |  1345 |    11   (0)| 00:00:01 |
|   1 |  UNION-ALL                           |                         |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
|*  4 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  5 |    INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------

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

   3 - access("UNIQUE_ID"=1)
   4 - filter(LNNVL("UNIQUE_ID"=1))
   5 - access("SUB_ITEM_CODE"='0001000000')

レントゲンから諸々読み取るスキルは大切だと思っているので、みんなもレントゲンというなの実行計画は読んでみるといいよーーーっ。おすすめ。

では、次回へつづく

---

---

Related article on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は、SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は、SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS

実行計画は、SQL文のレントゲン写真だ！ No.33 - BITMAP CONVERSION TO ROWIDS

Previously on Mac De Oracle
前回は外部表特有のoperationであるEXTERNAL TABLE ACCESS FULL / INMEMORY FULL のレントゲンでした。

今日は、昔からあるBITMAP CONVERSION TO ROWIDSを見てみたいと思います。

SQLチューニング・ガイド 8.4.2 ビットマップのROWIDへの変換
SQLチューニング・ガイド 8.4.2 ビットマップのROWIDへの変換 / 21c

このオペレーションは、複数の索引からbitmapを生成しその結果のrowidを用いて表をアクセスするところにあります。通常一つの索引が利用されますが、この場合は複数の索引が利用されるところが特徴です。
ただ、bitmapに変換コストより、unionに書き換えたり（内部的な書き換えも含む）したほうが効率が良かったりします。なので意外と嫌われてたりw　なので、STAR TRANSFORM などで見るぐららいで、結構それ以外の方向へチューニングされているケースのほうが多いかもしれません。でもこれで問題なければそのままでも問題はないわけですが。

あ、そういえば、以前、CONCATENATIONのレントゲンを紹介していましたね。
ちょうどよいので、CONCATENATIONのレントゲン撮影時と同じ表とSQL文を使って BITMAP CONVERSION TO ROWIDS のレントゲンを見てみましょう :)

SCOTT@orclpdb1> desc tab311
名前                                    NULL?    型
----------------------------------------- -------- ----------------------------
UNIQUE_ID                                 NOT NULL NUMBER(10)
SUB_ITEM_CODE                             NOT NULL CHAR(10)
FOO                                       NOT NULL VARCHAR2(500)
IS_DELETE                                 NOT NULL NUMBER(1)

SCOTT@orclpdb1> select count(1) from tab311

COUNT(1)
----------
2000000

経過: 00:00:00.09

実行計画を見てわかると思いますが、　2つの索引(TAB311_PK, TAB311_IX_SUB_ITEM_CODE)のROWIDからBITMAPを作り(Id=3,7)、それを BITMAP OR (SQL文の7行目 Id=3)した結果をROWIDへ変換(Id=2)、複数のROWIDをまとめ、IOリクエストを少なくするための ROWID BATCHED(Id=1)で表(TAB311)をアクセスしていことが読み取れます。
ROWIDでアクセスするので、基本的に少量の行にアクセスする場合には有利ではあります。ただ、BITMAPへの変換コスト次第というところではあるわけです。なので、BITMAPの変換のないタイプのトランスフォームを狙ったHINTを利用したり、SQL文自体を書き換えたりするケースは少なくありません。意外に嫌いな方が多くてw　大抵チューニングされてしまい、あまり見かけることはないかもしれませんw　

SCOTT@orclpdb1> r
  1  select
  2    *
  3  from
  4    tab311
  5  where
  6    unique_id= 1
  7*   or sub_item_code = '0001000000'

経過: 00:00:00.01

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

---------------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |                         |     5 |  1345 |     8  (13)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     5 |  1345 |     8  (13)| 00:00:01 |
|   2 |   BITMAP CONVERSION TO ROWIDS       |                         |       |       |            |          |
|   3 |    BITMAP OR                        |                         |       |       |            |          |
|   4 |     BITMAP CONVERSION FROM ROWIDS   |                         |       |       |            |          |
|   5 |      SORT ORDER BY                  |                         |       |       |            |          |
|*  6 |       INDEX RANGE SCAN              | TAB311_PK               |       |       |     3   (0)| 00:00:01 |
|   7 |     BITMAP CONVERSION FROM ROWIDS   |                         |       |       |            |          |
|*  8 |      INDEX RANGE SCAN               | TAB311_IX_SUB_ITEM_CODE |       |       |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------------

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

   6 - access("UNIQUE_ID"=1)
       filter("UNIQUE_ID"=1)
   8 - access("SUB_ITEM_CODE"='0001000000')

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

ちなみに、CONCATENATIONのエントリーを見ていただくのがよいとは思いますが、これも比較的古くからある、CONCATENATIONを使ったSQL変換のレントゲンも改めて載せておきます。
（USE_CONCATヒントで強制しています。みなさん、知っているとは思いますが、NO_EXPANDヒントが逆のヒントです）

実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 Day 17 / CONCATENATION
UNION のような実行計画ですが、UNIONとは出てませんw　これはまた別の機会に。ただ、ほぼ同等の意味で、OR条件でそれぞれに最適な索引を使うことでindex range scanやindex unique scanを効かせて高速にアクセスしようとしています。
BITMAPとの相互変換などが無い分、安定して早いケースは経験的にも多いのは確かです。どちらを選ぶかはやはり、登録されているデータの傾向と検索条件次第ではあります。ただ一般的BITMAP変換を避ける傾向が強いのは確かではありますね。

SCOTT@orclpdb1> r
  1  select
  2    /*+
  3       use_concat
  4    */
  5    *
  6  from
  7    tab311
  8  where
  9    unique_id= 1
 10*   or sub_item_code = '0001000000'

経過: 00:00:00.00

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

----------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                         |     5 |  1345 |    11   (0)| 00:00:01 |
|   1 |  CONCATENATION                       |                         |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     4 |  1076 |     7   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | TAB311_IX_SUB_ITEM_CODE |     4 |       |     3   (0)| 00:00:01 |
|   4 |   TABLE ACCESS BY INDEX ROWID BATCHED| TAB311                  |     1 |   269 |     4   (0)| 00:00:01 |
|*  5 |    INDEX RANGE SCAN                  | TAB311_PK               |     1 |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------

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

   3 - access("SUB_ITEM_CODE"='0001000000')
   5 - access("UNIQUE_ID"=1)
       filter(LNNVL("SUB_ITEM_CODE"='0001000000'))


統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          8  consistent gets
          0  physical reads
          0  redo size
       1091  bytes sent via SQL*Net to client
         52  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

GWも間近だ。そろそろ予定考えないとな。その前にACEのKPIはクリアしておかないと。追い込み追い込みw

ということで、次回へつづく。

---

---

Related article on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT
・実行計画は、SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)
・実行計画は、SQL文のレントゲン写真だ！ No.32 - EXTERNAL TABLE ACCESS FULL / INMEMORY FULL

実行計画は、SQL文のレントゲン写真だ！ No.31 - TEMP TABLE TRANSFORMATION LOAD AS SELECT (CURSOR DURATION MEMORY)

さて、実行計画のバリエーションの数だけ、レントゲンはありますよー（まだネタには余裕があるw）

ということで、今回は、12c前後で変化したところを見ておきたいと思います。

タイトルにも書いた

TEMP TABLE TRANSFORMATION
  LOAD AS SELECT (CURSOR DURATION MEMORY)

は、12c以降のリリースから見られるWITH CTEで繰り返し利用されることが自明で性能改善につながると想定される場合に、一時表にマテリアライズされたときのオペレーションですよね。
（みなさんご存知だとおもいます。

12c以降のリリースしか利用したことのない方は、気づかないと思いますが、11gまで少々違いました。

TEMP TABLE TRANSFORMATION
　　LOAD AS SELECT

違いといっても、CURSOR DURATION MEMORY があるかないかなのですがw、細かい改善の一つでだよね。と。

ちょうど良いネタなので、昨年末のAdvent CalendarのSQL文と実行計画でバージョン間のレントゲン写真の差を確認しておきましょう:)

まず、一つまえの 19cから。
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

Id=2のオペレーションは、LOAD AS SELECT (CURSOR DURATION MEMORY)　ですね。

もう一点、Predicate Informationセクションには、/*+ CACHE ("T1") */　というヒントが内部的に利用されていますね。ふーむ。
また、アダプティブな挙動もレポートされていないようですね。計画自体もindex only scanですし、まあ、想定通りというところですね。

参考までに、OPTIMIZER_DYNAMIC_SAMPLING = 2 と。デフォルトのままです。

CURSOR DURATION MEMORYの挙動については、
SQLチューニング・ガイド cursor-duration一時表

にあるように、シリアル実行では、PGAを利用するようですね。パラレルだと違うのか... でいずれもメモリ上に乗らなくなると、一時セグメントがストレージ上に確保されると記載されているのでTEMP表領域が利用されそうですね。
メモリに余裕があり、かつ、繰り返し参照されるケースでは効果はありそうですよね。ストレージに落ちてしまうと、direct path read from tempが発生するでしょうし、ストレージを繰り返しアクセスするかしないかの違いは大きいかも。
とはいえ、WITH句のCTEで性能改善を狙うケースでポイントになるところは同じなので、その点は忘れないようにしておきたいところですね。（例外は巨大なSQLで可読性向上を目的とした場合ぐらい）

Execution Plan
----------------------------------------------------------
Plan hash value: 3964084889

----------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                         |                           |     7 |   553 |    12   (0)| 00:00:01 |
|   1 |  TEMP TABLE TRANSFORMATION               |                           |       |       |            |          |
|   2 |   LOAD AS SELECT (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D6640_6FF953 |       |       |            |          |
|   3 |    WINDOW SORT                           |                           |     7 |   119 |     8   (0)| 00:00:01 |
|   4 |     NESTED LOOPS                         |                           |     7 |   119 |     8   (0)| 00:00:01 |
|   5 |      NESTED LOOPS                        |                           |     7 |    77 |     4   (0)| 00:00:01 |
|   6 |       INDEX FULL SCAN                    | SYS_C0012896              |     4 |    24 |     1   (0)| 00:00:01 |
|*  7 |       INDEX FAST FULL SCAN               | SYS_C0012900              |     2 |    10 |     1   (0)| 00:00:01 |
|*  8 |      INDEX FAST FULL SCAN                | SYS_C0012898              |     1 |     6 |     1   (0)| 00:00:01 |
|   9 |   LOAD AS SELECT (CURSOR DURATION MEMORY)| SYS_TEMP_0FD9D6641_6FF953 |       |       |            |          |
|  10 |    WINDOW SORT                           |                           |     7 |   371 |     2   (0)| 00:00:01 |
|* 11 |     FILTER                               |                           |       |       |            |          |
|  12 |      VIEW                                |                           |     7 |   371 |     2   (0)| 00:00:01 |
|  13 |       TABLE ACCESS FULL                  | SYS_TEMP_0FD9D6640_6FF953 |     7 |   119 |     2   (0)| 00:00:01 |
|* 14 |      VIEW                                |                           |     7 |   210 |     2   (0)| 00:00:01 |
|  15 |       TABLE ACCESS FULL                  | SYS_TEMP_0FD9D6640_6FF953 |     7 |   119 |     2   (0)| 00:00:01 |
|* 16 |      VIEW                                |                           |     7 |   210 |     2   (0)| 00:00:01 |
|  17 |       TABLE ACCESS FULL                  | SYS_TEMP_0FD9D6640_6FF953 |     7 |   119 |     2   (0)| 00:00:01 |
|  18 |   VIEW                                   |                           |     7 |   553 |     2   (0)| 00:00:01 |
|  19 |    WINDOW SORT                           |                           |     7 |   371 |     2   (0)| 00:00:01 |
|* 20 |     FILTER                               |                           |       |       |            |          |
|  21 |      VIEW                                |                           |     7 |   371 |     2   (0)| 00:00:01 |
|  22 |       TABLE ACCESS FULL                  | SYS_TEMP_0FD9D6641_6FF953 |     7 |   217 |     2   (0)| 00:00:01 |
|* 23 |      VIEW                                |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  24 |       TABLE ACCESS FULL                  | SYS_TEMP_0FD9D6641_6FF953 |     7 |   217 |     2   (0)| 00:00:01 |
|* 25 |      VIEW                                |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  26 |       TABLE ACCESS FULL                  | SYS_TEMP_0FD9D6641_6FF953 |     7 |   217 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------------

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

   7 - filter("NAME"='Scott' AND "ANIMALS"."KIND"='Snake' OR "NAME"='Steve' AND "ANIMALS"."KIND"<>'Dog' AND
              "ANIMALS"."KIND"<>'Snake' OR "NAME"='Hiro' AND "ANIMALS"."KIND"<>'Turtle' AND "ANIMALS"."KIND"<>'Snake' OR
              "NAME"='Larry' AND "ANIMALS"."KIND"<>'Snake')
   8 - filter(("OWNERS"."NAME"='Hiro' AND "PETS"."NAME"='Tiger' OR "OWNERS"."NAME"<>'Hiro' AND
              "PETS"."NAME"<>'Tiger') AND ("NAME"='Wendy' AND "KIND"='Dog' OR "NAME"='Tiger' AND "KIND"<>'Dog' AND
              "KIND"<>'Turtle' OR "NAME"='Lisa' AND "KIND"<>'Snake' AND "KIND"<>'Dog' OR "NAME"='Taro' AND "KIND"<>'Dog'))
  11 - filter("NUM_OF_ROWS"=1 OR "NUM_OF_ROWS">1 AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE ("T1") */
              "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3" "ANIMAL_KIND" FROM
              "SYS"."SYS_TEMP_0FD9D6640_6FF953" "T1") "UNKNOWN_PET_OWNERS" WHERE "PET_NAME"=:B1 AND "NUM_OF_ROWS"=1) AND
              NOT EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2"
              "PET_NAME","C3" "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D6640_6FF953" "T1") "UNKNOWN_PET_OWNERS" WHERE
              "ANIMAL_KIND"=:B2 AND "NUM_OF_ROWS"=1))
  14 - filter("PET_NAME"=:B1 AND "NUM_OF_ROWS"=1)
  16 - filter("ANIMAL_KIND"=:B1 AND "NUM_OF_ROWS"=1)
  20 - filter("NUM_OF_ROWS"=1 OR "NUM_OF_ROWS">1 AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE ("T1") */
              "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3" "ANIMAL_KIND" FROM
              "SYS"."SYS_TEMP_0FD9D6641_6FF953" "T1") "TEMP_PET_OWNERS" WHERE "PET_NAME"=:B1 AND "NUM_OF_ROWS"=1) AND  NOT
              EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3"
              "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D6641_6FF953" "T1") "TEMP_PET_OWNERS" WHERE "ANIMAL_KIND"=:B2 AND

              "NUM_OF_ROWS"=1))
  23 - filter("PET_NAME"=:B1 AND "NUM_OF_ROWS"=1)
  25 - filter("ANIMAL_KIND"=:B1 AND "NUM_OF_ROWS"=1)

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         49  consistent gets
          0  physical reads
          0  redo size
        922  bytes sent via SQL*Net to client
       2090  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          3  sorts (memory)
          0  sorts (disk)
          4  rows processed

では次、12R1の場合です。(12R2は19cと同じなので省略)
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

基本的にデフォルト設定のままなので、　OPTIMIZER_DYNAMIC_SAMPLING = 2　でもろもろ止めたりしていませんw

12cR2以降との違いの１つめ！
12cR1では、CURSOR DURATION MEMORY　オペレーションがありません！！　

12cR2以降との違いの２つめ！
/*+ CACHE ("T1") */ではなく、/*+ CACHE_TEMP_TABLE ("T1") */　という一時表専用のヒントが担っている点。
CACHE_TEMP_TABLEヒントって解説がないヒントなのですが、12cR2以降はCACHEヒントという解説のある通常の表と同じヒントに置き換えられいますね。一時表だけ特別なわけではないので統一したのでしょうか（中の人のみぞ知るw）

Note部分にもでてますが、動的統計とプランディレクティブが動いてますね。再起コールが減らないのもその影響のようです。19cの挙動とは興味深い違いですね。データ量が多くなった場合にどう変化するのかなという気はしますがw

ちなみに、この挙動は、11cR2とくらべて、プランディレクティブが無い以外の挙動は同じ。

Execution Plan
----------------------------------------------------------
Plan hash value: 3787387246

--------------------------------------------------------------------------------------------------------
| Id  | Operation                  | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |                           |     7 |   448 |    13   (8)| 00:00:01 |
|   1 |  TEMP TABLE TRANSFORMATION |                           |       |       |            |          |
|   2 |   LOAD AS SELECT           | SYS_TEMP_0FD9D6647_566AED |       |       |            |          |
|   3 |    WINDOW SORT             |                           |     8 |   136 |     8   (0)| 00:00:01 |
|   4 |     NESTED LOOPS           |                           |     8 |   136 |     8   (0)| 00:00:01 |
|   5 |      NESTED LOOPS          |                           |     8 |    88 |     4   (0)| 00:00:01 |
|   6 |       INDEX FULL SCAN      | SYS_C0014925              |     4 |    24 |     1   (0)| 00:00:01 |
|*  7 |       INDEX FAST FULL SCAN | SYS_C0014929              |     2 |    10 |     1   (0)| 00:00:01 |
|*  8 |      INDEX FAST FULL SCAN  | SYS_C0014927              |     1 |     6 |     1   (0)| 00:00:01 |
|   9 |   LOAD AS SELECT           | SYS_TEMP_0FD9D6648_566AED |       |       |            |          |
|  10 |    WINDOW SORT             |                           |     7 |   371 |     2   (0)| 00:00:01 |
|* 11 |     FILTER                 |                           |       |       |            |          |
|  12 |      VIEW                  |                           |     7 |   371 |     2   (0)| 00:00:01 |
|  13 |       TABLE ACCESS FULL    | SYS_TEMP_0FD9D6647_566AED |     7 |   119 |     2   (0)| 00:00:01 |
|* 14 |      VIEW                  |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  15 |       TABLE ACCESS FULL    | SYS_TEMP_0FD9D6647_566AED |     7 |   119 |     2   (0)| 00:00:01 |
|* 16 |      VIEW                  |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  17 |       TABLE ACCESS FULL    | SYS_TEMP_0FD9D6647_566AED |     7 |   119 |     2   (0)| 00:00:01 |
|  18 |   SORT ORDER BY            |                           |     7 |   448 |     3  (34)| 00:00:01 |
|* 19 |    FILTER                  |                           |       |       |            |          |
|  20 |     VIEW                   |                           |     7 |   448 |     2   (0)| 00:00:01 |
|  21 |      TABLE ACCESS FULL     | SYS_TEMP_0FD9D6648_566AED |     7 |   217 |     2   (0)| 00:00:01 |
|* 22 |     VIEW                   |                           |     7 |   210 |     2   (0)| 00:00:01 |
|  23 |      TABLE ACCESS FULL     | SYS_TEMP_0FD9D6648_566AED |     7 |   217 |     2   (0)| 00:00:01 |
|* 24 |     VIEW                   |                           |     7 |   210 |     2   (0)| 00:00:01 |
|  25 |      TABLE ACCESS FULL     | SYS_TEMP_0FD9D6648_566AED |     7 |   217 |     2   (0)| 00:00:01 |


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

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

   7 - filter("OWNERS"."NAME"='Scott' AND "ANIMALS"."KIND"='Snake' OR "OWNERS"."NAME"='Steve'
              AND "ANIMALS"."KIND"<>'Dog' AND "ANIMALS"."KIND"<>'Snake' OR "OWNERS"."NAME"='Hiro' AND
              "ANIMALS"."KIND"<>'Turtle' AND "ANIMALS"."KIND"<>'Snake' OR "OWNERS"."NAME"='Larry' AND
              "ANIMALS"."KIND"<>'Snake')
   8 - filter(("OWNERS"."NAME"='Hiro' AND "PETS"."NAME"='Tiger' OR "OWNERS"."NAME"<>'Hiro' AND
              "PETS"."NAME"<>'Tiger') AND ("PETS"."NAME"='Wendy' AND "ANIMALS"."KIND"='Dog' OR
              "PETS"."NAME"='Tiger' AND "ANIMALS"."KIND"<>'Dog' AND "ANIMALS"."KIND"<>'Turtle' OR
              "PETS"."NAME"='Lisa' AND "ANIMALS"."KIND"<>'Snake' AND "ANIMALS"."KIND"<>'Dog' OR
              "PETS"."NAME"='Taro' AND "ANIMALS"."KIND"<>'Dog'))
  11 - filter("NUM_OF_ROWS"=1 OR "NUM_OF_ROWS">1 AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+
              CACHE_TEMP_TABLE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3"
              "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D6647_566AED" "T1") "PET_OWNER_UNKNOWN" WHERE
              "PET_NAME"=:B1 AND "NUM_OF_ROWS"=1) AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+
              CACHE_TEMP_TABLE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3"
              "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D6647_566AED" "T1") "PET_OWNER_UNKNOWN" WHERE
              "ANIMAL_KIND"=:B2 AND "NUM_OF_ROWS"=1))
  14 - filter("PET_NAME"=:B1 AND "NUM_OF_ROWS"=1)
  16 - filter("ANIMAL_KIND"=:B1 AND "NUM_OF_ROWS"=1)
  19 - filter("NUM_OF_ROWS"=1 OR "NUM_OF_ROWS">1 AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+
              CACHE_TEMP_TABLE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3"
              "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D6648_566AED" "T1") "PET_OWNERS" WHERE "PET_NAME"=:B1
              AND "NUM_OF_ROWS"=1) AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE_TEMP_TABLE ("T1") */
              "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3" "ANIMAL_KIND" FROM
              "SYS"."SYS_TEMP_0FD9D6648_566AED" "T1") "PET_OWNERS" WHERE "ANIMAL_KIND"=:B2 AND
              "NUM_OF_ROWS"=1))
  22 - filter("PET_NAME"=:B1 AND "NUM_OF_ROWS"=1)
  24 - filter("ANIMAL_KIND"=:B1 AND "NUM_OF_ROWS"=1)

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)
   - 5 Sql Plan Directives used for this statement

Statistics
----------------------------------------------------------
          4  recursive calls
         36  db block gets
        126  consistent gets
          2  physical reads
       1160  redo size
        811  bytes sent via SQL*Net to client
        552  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          3  sorts (memory)
          0  sorts (disk)
          4  rows processed

そして、最後は、私の環境で最も古いOracle 11.1.0.7

Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production

わかっちゃいたけど、オプティマイザの進化が見えて嬉しいですねw

なかなか苦しい実行計画ですね。これは。。。w

Index only Scanにはなっていますが、マテリアライズする部分の実行計画が.. オプティマイザありがとう。（主に最新版のほうですけどw）

本題にもどると、このリリースではCURSOR DURATION MEMORYがないのは当然ですが、CACHE_TEMP_TABLEヒントが利用されているという点に関しては、12cR1と同じ
そして、アダプティブな挙動も一切ない自体の実行計画ですね。ここには戻りたくないですよね。みなさんw

アダプティブな挙動はないにしても、再起コールがおおいし、実行計画が行けてないのでヒントで補正してみたくなりますよねw

Plan hash value: 3067991639

----------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |                           |     7 |   448 |    14  (15)| 00:00:01 |
|   1 |  TEMP TABLE TRANSFORMATION   |                           |       |       |            |          |
|   2 |   LOAD AS SELECT             |                           |       |       |            |          |
|   3 |    WINDOW SORT               |                           |     8 |   240 |     9  (12)| 00:00:01 |
|   4 |     CONCATENATION            |                           |       |       |            |          |
|   5 |      NESTED LOOPS            |                           |     7 |   210 |     7   (0)| 00:00:01 |
|   6 |       NESTED LOOPS           |                           |     9 |   225 |     7   (0)| 00:00:01 |
|   7 |        NESTED LOOPS          |                           |     5 |   100 |     4   (0)| 00:00:01 |
|   8 |         NESTED LOOPS         |                           |     7 |   105 |     4   (0)| 00:00:01 |
|   9 |          NESTED LOOPS        |                           |     4 |    40 |     1   (0)| 00:00:01 |
|  10 |           INDEX FULL SCAN    | SYS_C009964               |     4 |    20 |     1   (0)| 00:00:01 |
|* 11 |           INDEX UNIQUE SCAN  | SYS_C009964               |     1 |     5 |     0   (0)| 00:00:01 |
|* 12 |          INDEX FAST FULL SCAN| SYS_C009962               |     2 |    10 |     1   (0)| 00:00:01 |
|* 13 |         INDEX UNIQUE SCAN    | SYS_C009962               |     1 |     5 |     0   (0)| 00:00:01 |
|* 14 |        INDEX FAST FULL SCAN  | SYS_C009960               |     2 |    10 |     1   (0)| 00:00:01 |
|* 15 |       INDEX UNIQUE SCAN      | SYS_C009960               |     1 |     5 |     0   (0)| 00:00:01 |
|  16 |      NESTED LOOPS            |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  17 |       NESTED LOOPS           |                           |     2 |    50 |     1   (0)| 00:00:01 |
|  18 |        NESTED LOOPS          |                           |     1 |    20 |     0   (0)| 00:00:01 |
|  19 |         NESTED LOOPS         |                           |     1 |    15 |     0   (0)| 00:00:01 |
|  20 |          NESTED LOOPS        |                           |     1 |    10 |     0   (0)| 00:00:01 |
|* 21 |           INDEX UNIQUE SCAN  | SYS_C009962               |     1 |     5 |     0   (0)| 00:00:01 |
|* 22 |           INDEX UNIQUE SCAN  | SYS_C009960               |     1 |     5 |     0   (0)| 00:00:01 |
|* 23 |          INDEX UNIQUE SCAN   | SYS_C009962               |     4 |    20 |     0   (0)| 00:00:01 |
|* 24 |         INDEX UNIQUE SCAN    | SYS_C009960               |     4 |    20 |     0   (0)| 00:00:01 |
|* 25 |        INDEX FULL SCAN       | SYS_C009964               |     2 |    10 |     1   (0)| 00:00:01 |
|* 26 |       INDEX UNIQUE SCAN      | SYS_C009964               |     1 |     5 |     0   (0)| 00:00:01 |
|  27 |   LOAD AS SELECT             |                           |       |       |            |          |
|  28 |    WINDOW SORT               |                           |     7 |   217 |     2   (0)| 00:00:01 |
|* 29 |     FILTER                   |                           |       |       |            |          |
|  30 |      VIEW                    |                           |     7 |   217 |     2   (0)| 00:00:01 |
|  31 |       TABLE ACCESS FULL      | SYS_TEMP_0FD9D660C_11BDA4 |     7 |   210 |     2   (0)| 00:00:01 |
|* 32 |      VIEW                    |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  33 |       TABLE ACCESS FULL      | SYS_TEMP_0FD9D660C_11BDA4 |     7 |   210 |     2   (0)| 00:00:01 |
|* 34 |      VIEW                    |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  35 |       TABLE ACCESS FULL      | SYS_TEMP_0FD9D660C_11BDA4 |     7 |   210 |     2   (0)| 00:00:01 |
|  36 |   SORT ORDER BY              |                           |     7 |   448 |     3  (34)| 00:00:01 |
|* 37 |    FILTER                    |                           |       |       |            |          |
|  38 |     VIEW                     |                           |     7 |   448 |     2   (0)| 00:00:01 |
|  39 |      TABLE ACCESS FULL       | SYS_TEMP_0FD9D660D_11BDA4 |     7 |   217 |     2   (0)| 00:00:01 |
|* 40 |     VIEW                     |                           |     7 |   210 |     2   (0)| 00:00:01 |
|  41 |      TABLE ACCESS FULL       | SYS_TEMP_0FD9D660D_11BDA4 |     7 |   217 |     2   (0)| 00:00:01 |
|* 42 |     VIEW                     |                           |     7 |   210 |     2   (0)| 00:00:01 |
|  43 |      TABLE ACCESS FULL       | SYS_TEMP_0FD9D660D_11BDA4 |     7 |   217 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------

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

  11 - access("ANIMALS"."KIND"="ANIMALS"."KIND")
  12 - filter("PETS"."NAME"='Wendy' AND "ANIMALS"."KIND"='Dog' OR "PETS"."NAME"='Tiger' AND
              "ANIMALS"."KIND"<>'Dog' AND "ANIMALS"."KIND"<>'Turtle' OR "PETS"."NAME"='Lisa' AND
              "ANIMALS"."KIND"<>'Snake' AND "ANIMALS"."KIND"<>'Dog' OR "PETS"."NAME"='Taro' AND
              "ANIMALS"."KIND"<>'Dog')
  13 - access("PETS"."NAME"="PETS"."NAME")
       filter("PETS"."NAME"<>'Tiger')
  14 - filter("OWNERS"."NAME"='Scott' AND "ANIMALS"."KIND"='Snake' OR "OWNERS"."NAME"='Steve' AND
              "ANIMALS"."KIND"<>'Dog' AND "ANIMALS"."KIND"<>'Snake' OR "OWNERS"."NAME"='Hiro' AND
              "ANIMALS"."KIND"<>'Turtle' AND "ANIMALS"."KIND"<>'Snake' OR "OWNERS"."NAME"='Larry' AND
              "ANIMALS"."KIND"<>'Snake')
  15 - access("OWNERS"."NAME"="OWNERS"."NAME")
       filter("OWNERS"."NAME"<>'Hiro')
  21 - access("PETS"."NAME"='Tiger')
  22 - access("OWNERS"."NAME"='Hiro')
       filter(LNNVL("OWNERS"."NAME"<>'Hiro') OR LNNVL("PETS"."NAME"<>'Tiger'))
  23 - access("PETS"."NAME"="PETS"."NAME")
  24 - access("OWNERS"."NAME"="OWNERS"."NAME")
  25 - filter("OWNERS"."NAME"='Scott' AND "ANIMALS"."KIND"='Snake' OR "OWNERS"."NAME"='Steve' AND
              "ANIMALS"."KIND"<>'Dog' AND "ANIMALS"."KIND"<>'Snake' OR "OWNERS"."NAME"='Hiro' AND
              "ANIMALS"."KIND"<>'Turtle' AND "ANIMALS"."KIND"<>'Snake' OR "OWNERS"."NAME"='Larry' AND
              "ANIMALS"."KIND"<>'Snake')
  26 - access("ANIMALS"."KIND"="ANIMALS"."KIND")
       filter("PETS"."NAME"='Wendy' AND "ANIMALS"."KIND"='Dog' OR "PETS"."NAME"='Tiger' AND
              "ANIMALS"."KIND"<>'Dog' AND "ANIMALS"."KIND"<>'Turtle' OR "PETS"."NAME"='Lisa' AND
              "ANIMALS"."KIND"<>'Snake' AND "ANIMALS"."KIND"<>'Dog' OR "PETS"."NAME"='Taro' AND
              "ANIMALS"."KIND"<>'Dog')
  29 - filter("NUM_OF_ROWS"=1 OR "NUM_OF_ROWS">1 AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+
              CACHE_TEMP_TABLE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3"
              "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D660C_11BDA4" "T1") "PET_OWNER_UNKNOWN" WHERE
              "PET_NAME"=:B1 AND "NUM_OF_ROWS"=1) AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE_TEMP_TABLE
              ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3" "ANIMAL_KIND" FROM
              "SYS"."SYS_TEMP_0FD9D660C_11BDA4" "T1") "PET_OWNER_UNKNOWN" WHERE "ANIMAL_KIND"=:B2 AND
              "NUM_OF_ROWS"=1))
  32 - filter("PET_NAME"=:B1 AND "NUM_OF_ROWS"=1)
  34 - filter("ANIMAL_KIND"=:B1 AND "NUM_OF_ROWS"=1)
  37 - filter("NUM_OF_ROWS"=1 OR "NUM_OF_ROWS">1 AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+
              CACHE_TEMP_TABLE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3"
              "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D660D_11BDA4" "T1") "PET_OWNERS" WHERE "PET_NAME"=:B1 AND
              "NUM_OF_ROWS"=1) AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE_TEMP_TABLE ("T1") */ "C0"
              "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3" "ANIMAL_KIND" FROM
              "SYS"."SYS_TEMP_0FD9D660D_11BDA4" "T1") "PET_OWNERS" WHERE "ANIMAL_KIND"=:B2 AND "NUM_OF_ROWS"=1))
  40 - filter("PET_NAME"=:B1 AND "NUM_OF_ROWS"=1)
  42 - filter("ANIMAL_KIND"=:B1 AND "NUM_OF_ROWS"=1)

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

アダプティブな挙動がないにしても、再起コールがおおいし、実行計画が行けてないのでヒントで補正してみたくなりますよねw
NO_EXPANDヒントでCONCATENATIONを抑止してみましたw
それでもイマイチだ。古いオプティマイザとの挙動の違いをみると、ほんと、最新版のオプテマイザの良さが身にしみますw

Plan hash value: 2841796482

---------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                           |     7 |   448 |    13   (8)| 00:00:01 |
|   1 |  TEMP TABLE TRANSFORMATION  |                           |       |       |            |          |
|   2 |   LOAD AS SELECT            |                           |       |       |            |          |
|   3 |    WINDOW SORT              |                           |     7 |   210 |     8   (0)| 00:00:01 |
|   4 |     NESTED LOOPS            |                           |     7 |   210 |     8   (0)| 00:00:01 |
|   5 |      NESTED LOOPS           |                           |    12 |   300 |     8   (0)| 00:00:01 |
|   6 |       NESTED LOOPS          |                           |     7 |   140 |     4   (0)| 00:00:01 |
|   7 |        NESTED LOOPS         |                           |     7 |   105 |     4   (0)| 00:00:01 |
|   8 |         NESTED LOOPS        |                           |     4 |    40 |     1   (0)| 00:00:01 |
|   9 |          INDEX FULL SCAN    | SYS_C009964               |     4 |    20 |     1   (0)| 00:00:01 |
|* 10 |          INDEX UNIQUE SCAN  | SYS_C009964               |     1 |     5 |     0   (0)| 00:00:01 |
|* 11 |         INDEX FAST FULL SCAN| SYS_C009962               |     2 |    10 |     1   (0)| 00:00:01 |
|* 12 |        INDEX UNIQUE SCAN    | SYS_C009962               |     1 |     5 |     0   (0)| 00:00:01 |
|* 13 |       INDEX FAST FULL SCAN  | SYS_C009960               |     2 |    10 |     1   (0)| 00:00:01 |
|* 14 |      INDEX UNIQUE SCAN      | SYS_C009960               |     1 |     5 |     0   (0)| 00:00:01 |
|  15 |   LOAD AS SELECT            |                           |       |       |            |          |
|  16 |    WINDOW SORT              |                           |     7 |   217 |     2   (0)| 00:00:01 |
|* 17 |     FILTER                  |                           |       |       |            |          |
|  18 |      VIEW                   |                           |     7 |   217 |     2   (0)| 00:00:01 |
|  19 |       TABLE ACCESS FULL     | SYS_TEMP_0FD9D6624_11BDA4 |     7 |   210 |     2   (0)| 00:00:01 |
|* 20 |      VIEW                   |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  21 |       TABLE ACCESS FULL     | SYS_TEMP_0FD9D6624_11BDA4 |     7 |   210 |     2   (0)| 00:00:01 |
|* 22 |      VIEW                   |                           |     1 |    30 |     1   (0)| 00:00:01 |
|  23 |       TABLE ACCESS FULL     | SYS_TEMP_0FD9D6624_11BDA4 |     7 |   210 |     2   (0)| 00:00:01 |
|  24 |   SORT ORDER BY             |                           |     7 |   448 |     3  (34)| 00:00:01 |
|* 25 |    FILTER                   |                           |       |       |            |          |
|  26 |     VIEW                    |                           |     7 |   448 |     2   (0)| 00:00:01 |
|  27 |      TABLE ACCESS FULL      | SYS_TEMP_0FD9D6625_11BDA4 |     7 |   217 |     2   (0)| 00:00:01 |
|* 28 |     VIEW                    |                           |     7 |   210 |     2   (0)| 00:00:01 |
|  29 |      TABLE ACCESS FULL      | SYS_TEMP_0FD9D6625_11BDA4 |     7 |   217 |     2   (0)| 00:00:01 |
|* 30 |     VIEW                    |                           |     7 |   210 |     2   (0)| 00:00:01 |
|  31 |      TABLE ACCESS FULL      | SYS_TEMP_0FD9D6625_11BDA4 |     7 |   217 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------

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

10 - access("ANIMALS"."KIND"="ANIMALS"."KIND")
11 - filter("PETS"."NAME"='Wendy' AND "ANIMALS"."KIND"='Dog' OR "PETS"."NAME"='Tiger' AND
            "ANIMALS"."KIND"<>'Dog' AND "ANIMALS"."KIND"<>'Turtle' OR "PETS"."NAME"='Lisa' AND
            "ANIMALS"."KIND"<>'Snake' AND "ANIMALS"."KIND"<>'Dog' OR "PETS"."NAME"='Taro' AND
            "ANIMALS"."KIND"<>'Dog')
12 - access("PETS"."NAME"="PETS"."NAME")
13 - filter("OWNERS"."NAME"='Scott' AND "ANIMALS"."KIND"='Snake' OR "OWNERS"."NAME"='Steve'
            AND "ANIMALS"."KIND"<>'Dog' AND "ANIMALS"."KIND"<>'Snake' OR "OWNERS"."NAME"='Hiro' AND
            "ANIMALS"."KIND"<>'Turtle' AND "ANIMALS"."KIND"<>'Snake' OR "OWNERS"."NAME"='Larry' AND
            "ANIMALS"."KIND"<>'Snake')
14 - access("OWNERS"."NAME"="OWNERS"."NAME")
     filter("OWNERS"."NAME"='Hiro' AND "PETS"."NAME"='Tiger' OR "OWNERS"."NAME"<>'Hiro' AND
            "PETS"."NAME"<>'Tiger')
17 - filter("NUM_OF_ROWS"=1 OR "NUM_OF_ROWS">1 AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+
            CACHE_TEMP_TABLE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3"
            "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D6624_11BDA4" "T1") "PET_OWNER_UNKNOWN" WHERE
            "PET_NAME"=:B1 AND "NUM_OF_ROWS"=1) AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE_TEMP_TABLE
            ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3" "ANIMAL_KIND" FROM
            "SYS"."SYS_TEMP_0FD9D6624_11BDA4" "T1") "PET_OWNER_UNKNOWN" WHERE "ANIMAL_KIND"=:B2 AND
            "NUM_OF_ROWS"=1))
20 - filter("PET_NAME"=:B1 AND "NUM_OF_ROWS"=1)
22 - filter("ANIMAL_KIND"=:B1 AND "NUM_OF_ROWS"=1)
25 - filter("NUM_OF_ROWS"=1 OR "NUM_OF_ROWS">1 AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+
            CACHE_TEMP_TABLE ("T1") */ "C0" "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3"
            "ANIMAL_KIND" FROM "SYS"."SYS_TEMP_0FD9D6625_11BDA4" "T1") "PET_OWNERS" WHERE "PET_NAME"=:B1 AND
            "NUM_OF_ROWS"=1) AND  NOT EXISTS (SELECT 0 FROM  (SELECT /*+ CACHE_TEMP_TABLE ("T1") */ "C0"
            "NUM_OF_ROWS","C1" "OWNER_NAME","C2" "PET_NAME","C3" "ANIMAL_KIND" FROM
            "SYS"."SYS_TEMP_0FD9D6625_11BDA4" "T1") "PET_OWNERS" WHERE "ANIMAL_KIND"=:B2 AND
            "NUM_OF_ROWS"=1))
28 - filter("PET_NAME"=:B1 AND "NUM_OF_ROWS"=1)
30 - filter("ANIMAL_KIND"=:B1 AND "NUM_OF_ROWS"=1)

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

SQLのレントゲン写真、バージョンと共に基本形wが変化していくので、常に差分と最新の内容を把握しておきたいですよね。いざ、診療するとなったときには役に立つ、はず！！

今回利用したSQL文や表定義およびデータは、誰がどんな名前のペットを飼っているのかな？ 解答編 / JPOUG Advent Calendar Day 23を参照ください。

では、また。

---

---

Related article on Mac De Oracle
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 1 / TABLE FULL SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 2 / INDEX UNIQUE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 3 / INDEX RANGE SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 4 / INDEX RANGE SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 5 / INDEX RANGE SCAN, INLIST ITERATOR
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 6 / INDEX FAST SCAN, Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 7 / INDEX FULL SCAN,Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 8 / INDEX SKIP SCAN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 9 / TABLE ACCESS INMEMORY FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 10 / NESTED LOOP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 11 / MERGE JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 12 / HASH JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 13 / HASH JOIN OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 14 / HASH JOIN FULL OUTER
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 15 / PX, TABLE ACCESS FULL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 16 / CONCATENATION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 17 / SORT UNIQUE, UNION-ALL = UNION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 18 / UNION-ALL
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 19 / INTERSECTION
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 20 / MINUS
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 21 / WINDOW NOSORT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 22 / COUNT STOPKEY
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 23 / HASH JOIN - LEFT-DEEP JOIN vs RIGHT-DEEP JOIN
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 24 / CONNECT BY NO FILTERING WITH START-WITH
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - Day 25 / UNION ALL (RECURSIVE WITH) DEPTH FIRST, RECURSIVE WITH PUMP
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#1 / STAR TRANSFORM, VECTOR TRANSFORM (DWH向け)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#2 / MERGE (UPSERT)
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#3 / RDFView
・実行計画は、SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 - おまけ#4 / INDEX FULL SCAN (MIN/MAX) - Index Only Scan
・実行計画は、SQL文のレントゲン写真だ！ No.30 - LOAD TABLE CONVENTIONAL vs. LOAD AS SELECT

19cの初期化パラメータ数や隠しパラメータ数などどう変化したのか、久々に確認してみた

ORACLE-ORCLCDB@SYS> select banner_full from v$version;

BANNER_FULL
------------------------------------------------------------------------
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0

compute sum label 'Total' of "Num Of Parameters" on report
break on report
WITH cte_params AS
(
  SELECT
    a.ksppinm
  FROM
    x$ksppi a JOIN x$ksppcv b
    ON a.indx = b.indx

)
SELECT
   *
FROM
(
  SELECT
   '1. Single underscore parameters' AS "CATEGORY"
   , COUNT(1) AS "Num Of Parameters"
  FROM
   cte_params
  WHERE
   REGEXP_LIKE(ksppinm, '^([_][^_]){1}.*')
  UNION
  SELECT
   '2. Double underscore parameters'
   , COUNT(1)
  FROM
   cte_params
  WHERE
   REGEXP_LIKE(ksppinm, '^[_]{2}.*')
  UNION
  SELECT
   '3. Non hidden parameters'
   , COUNT(1)
  FROM
   cte_params
  WHERE
   REGEXP_LIKE(ksppinm, '^[^_].*')
)
ORDER by
 category;

カウントした結果配は以下のとおり。やはりhidden parameter、かなり増えてますよね。

CATEGORY                        Num Of Parameters
------------------------------- -----------------
1. Single underscore parameters              4934
2. Double underscore parameters                30
3. Non hidden parameters                      448
                                -----------------
Total                                        5412

経過: 00:00:00.06

ぽかぽか陽気すぎて、海辺でパタパタしたいw

---

・Difference of Initialization Parameters between 11g r1 (11.1.0.6.0) and 12c r1 (12.1.0.1.0) - including hidden params
・Difference of Initialization Parameters between 11g and 12c #2

なぜ、そこに、LONG型があるんだ / FAQ

all/dba/user_tab_columns

https://docs.oracle.com/cd/E82638_01/refrn/ALL_TAB_COLUMNS.html#GUID-F218205C-7D76-4A83-8691-BFD2AD372B63

これらのビューは、列の属性関連の情報を持つビューです。
たまに、便利なびゅーではあるのですが、これらのビューをアクセスする使うスクリプトというかPL/SQLでコード書くこともあるのですが、一箇所だけ、使いにくいところがあります。

どこかわかります？

下位互換のためだろうと思われるのですが、一般には推奨されていない　LONG型の列　が残っています。

ご存知だとは思いますが、一般的なガイドだと、CLOBの利用が推奨されています。
下位互換のためだから仕方ないのだとは思うのですが。

LONG型といえば、とにかく制約が多くて、文字列操作を行うにもめんどくさいわけで、実際に利用したい状況になると、うううううっとなることしばしば。

LONG型

で、普段どうやって、その面倒くさいところを回避しているかといえば、CLOBに変換してしまうことがが多いです。
CLOBにしてしまえば、沢山の制約から解放されますしね　:)

以下のような感じで。

SCOTT> l
  1  CREATE TABLE my_dba_tab_columns
  2  AS
  3  SELECT
  4    owner
  5    ,table_name
  6    ,column_name
  7    ,data_type
  8    ,data_type_mod
  9    ,data_type_owner
 10    ,data_length
 11    ,data_precision
 12    ,data_scale
 13    ,nullable
 14    ,column_id
 15    ,TO_CLOB(default_length) AS default_length
 16    ,num_distinct
 17    ,low_value
 18    ,high_value
 19    ,density
 20    ,num_nulls
 21    ,num_buckets
 22    ,last_analyzed
 23    ,sample_size
 24    ,character_set_name
 25    ,char_col_decl_length
 26    ,global_stats
 27    ,user_stats
 28    ,avg_col_len
 29    ,char_length
 30    ,char_used
 31    ,v80_fmt_image
 32    ,data_upgraded
 33    ,histogram
 34    ,default_on_null
 35    ,identity_column
 36    ,sensitive_column
 37    ,evaluation_edition
 38    ,unusable_before
 39    ,unusable_beginning
 40    ,collation
 41  FROM
 42*   dba_tab_columns
SCOTT> /

Table created.

SCOTT> desc dba_tab_columns
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 OWNER                                     NOT NULL VARCHAR2(128)
 TABLE_NAME                                NOT NULL VARCHAR2(128)
 COLUMN_NAME                               NOT NULL VARCHAR2(128)
 DATA_TYPE                                          VARCHAR2(128)
 DATA_TYPE_MOD                                      VARCHAR2(3)
 DATA_TYPE_OWNER                                    VARCHAR2(128)
 DATA_LENGTH                               NOT NULL NUMBER
 DATA_PRECISION                                     NUMBER
 DATA_SCALE                                         NUMBER
 NULLABLE                                           VARCHAR2(1)
 COLUMN_ID                                          NUMBER
 DEFAULT_LENGTH                                     NUMBER
 DATA_DEFAULT                                       LONG
 NUM_DISTINCT                                       NUMBER
 LOW_VALUE                                          RAW(2000)
 HIGH_VALUE                                         RAW(2000)
 DENSITY                                            NUMBER
 NUM_NULLS                                          NUMBER
 NUM_BUCKETS                                        NUMBER
 LAST_ANALYZED                                      DATE
 SAMPLE_SIZE                                        NUMBER
 CHARACTER_SET_NAME                                 VARCHAR2(44)
 CHAR_COL_DECL_LENGTH                               NUMBER
 GLOBAL_STATS                                       VARCHAR2(3)
 USER_STATS                                         VARCHAR2(3)
 AVG_COL_LEN                                        NUMBER
 CHAR_LENGTH                                        NUMBER
 CHAR_USED                                          VARCHAR2(1)
 V80_FMT_IMAGE                                      VARCHAR2(3)
 DATA_UPGRADED                                      VARCHAR2(3)
 HISTOGRAM                                          VARCHAR2(15)
 DEFAULT_ON_NULL                                    VARCHAR2(3)
 IDENTITY_COLUMN                                    VARCHAR2(3)
 SENSITIVE_COLUMN                                   VARCHAR2(3)
 EVALUATION_EDITION                                 VARCHAR2(128)
 UNUSABLE_BEFORE                                    VARCHAR2(128)
 UNUSABLE_BEGINNING                                 VARCHAR2(128)
 COLLATION                                          VARCHAR2(100)

SCOTT> desc my_dba_tab_columns
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 OWNER                                     NOT NULL VARCHAR2(128)
 TABLE_NAME                                NOT NULL VARCHAR2(128)
 COLUMN_NAME                               NOT NULL VARCHAR2(128)
 DATA_TYPE                                          VARCHAR2(128)
 DATA_TYPE_MOD                                      VARCHAR2(3)
 DATA_TYPE_OWNER                                    VARCHAR2(128)
 DATA_LENGTH                               NOT NULL NUMBER
 DATA_PRECISION                                     NUMBER
 DATA_SCALE                                         NUMBER
 NULLABLE                                           VARCHAR2(1)
 COLUMN_ID                                          NUMBER
 DEFAULT_LENGTH                                     CLOB
 NUM_DISTINCT                                       NUMBER
 LOW_VALUE                                          RAW(2000)
 HIGH_VALUE                                         RAW(2000)
 DENSITY                                            NUMBER
 NUM_NULLS                                          NUMBER
 NUM_BUCKETS                                        NUMBER
 LAST_ANALYZED                                      DATE
 SAMPLE_SIZE                                        NUMBER
 CHARACTER_SET_NAME                                 VARCHAR2(44)
 CHAR_COL_DECL_LENGTH                               NUMBER
 GLOBAL_STATS                                       VARCHAR2(3)
 USER_STATS                                         VARCHAR2(3)
 AVG_COL_LEN                                        NUMBER
 CHAR_LENGTH                                        NUMBER
 CHAR_USED                                          VARCHAR2(1)
 V80_FMT_IMAGE                                      VARCHAR2(3)
 DATA_UPGRADED                                      VARCHAR2(3)
 HISTOGRAM                                          VARCHAR2(15)
 DEFAULT_ON_NULL                                    VARCHAR2(3)
 IDENTITY_COLUMN                                    VARCHAR2(3)
 SENSITIVE_COLUMN                                   VARCHAR2(3)
 EVALUATION_EDITION                                 VARCHAR2(128)
 UNUSABLE_BEFORE                                    VARCHAR2(128)
 UNUSABLE_BEGINNING                                 VARCHAR2(128)
 COLLATION                                          VARCHAR2(100)

---

db tech showcase 2019もおわり、今年も残すところ 3ヶ月あまり。一年早い. そして。
来週は、開催時期を秋に変更してから2回目の多摩川花火大会。天気がよいといいのですが:)

ではまた。

FAQ / PL/SQL PACKAGEでパプリックスコープを持つ定数をSQL文中で利用するには...

かなーり、ご無沙汰しておりました。（本業でいっぱいいっぱいで、という言い訳はこれぐらいにしてw） 偶に聞かれることがあるので、FAQネタから。 パッケージでパブリックなスコープを持つ定数は無名PL/SQLブロックやパッケージ、プロシージャ、ファンクションでしか参照できないんですよねー 例えば、DBMS_CRYPTOパッケージでHASHファンクションを利用してSH-256を作成したいなーと思って、

39.4 DBMS_CRYPTOのアルゴリズム
https://docs.oracle.com/cd/F19136_01/arpls/DBMS_CRYPTO.html#GUID-CE3CF17D-E781-47CB-AEE7-19A9B2BCD3EC

DBMS_CRYPTO.HASH()は関数なのでSQL文から呼びたーい、と以下のような使い方をすると...

SQL> SELECT DBMS_CRYPTO.HASH(TO_CLOB('hoge'), DBMS_CRYPTO.HASH_SH2569) AS "SH-256" FROM dual;
SELECT DBMS_CRYPTO.HASH(TO_CLOB('hoge'), DBMS_CRYPTO.HASH_SH2569) AS "SH-256" FROM dual
                                         *
ERROR at line 1:
ORA-00904: "DBMS_CRYPTO"."HASH_SH2569": invalid identifier


SQL>
SQL> select DBMS_CRYPTO.HASH_SH256 from dual;
select DBMS_CRYPTO.HASH_SH256 from dual
       *
ERROR at line 1:
ORA-06553: PLS-221: 'HASH_SH256' is not a procedure or is undefined

見事にエラーとなるわけです。 DBMS_CRYPTO.HASH_SH256は、パッケージファンクションではないので...利用可能なのはPL/SQLでのみ。

SQL> set serveroutput on
SQL>
¥SQL>
SQL> begin
  2    dbms_output.put_line('DBMS_CRYPTO.HASH_SH256 : ' || DBMS_CRYPTO.HASH_SH256);
  3  end;
  4  /
DBMS_CRYPTO.HASH_SH256 : 4

PL/SQL procedure successfully completed.

SQL文で活用する為には、ファンクションでラップする必要があります。 以下のように。

SQL> l
  1  CREATE OR REPLACE FUNCTION get_hash_sh256_type
  2  RETURN NUMBER
  3  AS
  4  BEGIN
  5    RETURN DBMS_CRYPTO.HASH_SH256;
  6* END;
SQL> /

Function created.

SQL>

冒頭でエラーとなっていたSQL文をDBMS_CRYPTO.HASH_SH256を返すファンクションを使うように書き換えると、 はい、できました。

SQL> l
  1  SELECT
  2    DBMS_CRYPTO.HASH(
  3	     TO_CLOB('hoge')
  4	     , get_hash_sh256_type()
  5    ) AS "SH-256"
  6  FROM
  7*   dual
SQL> /

SH-256
--------------------------------------------------------------------------------
ECB666D778725EC97307044D642BF4D160AABB76F56C0069C71EA25B1E926825

SQL>

---

露店の焼きそばと焼き鳥を食べつつ、晩夏の夏祭りと、涼しい朝晩の気温で熟睡可能な山形より。 では、では。

ORA_HASH()を使ってリストパーティションにハッシュパーティションのような均一配分を

ハッシュパーティションってリストパーティションみたいにパーティション狙い撃ちできて、かつ、ハッシュパーティションみたいに、データをパーティション間で均一化できないのかなぁ
というずいぶん昔の話を思い出して、そう言えば書いてないかもしれない。いつの話だよってぐらい昔の話だけどw
どうやったかというと、
ハッシュキーにふさわしい値をもつ列を決める（一意キーとか主キー列が理想、カーディナリティの低い、分布に偏りのあるデータを持つ列は使わない）

で、ハッシュキーが決まったら、話は早くて、ORA_HASH()関数で取得できるハッシュ値を利用したリストパーティションを作成するだけ。
ゴニョゴニュ言わなくても、SQLとPL/SQLのコードを見ていただければ、理解していただけるかと。

ORCL@SCOTT> l
  1  CREATE TABLE list_p_tab
  2  (
  3    id_code VARCHAR2(10) NOT NULL
  4    , foo VARCHAR2(30)
  5    , id_code_hash_value NUMBER(2) NOT NULL
  6  )
  7  PARTITION BY LIST (id_code_hash_value)
  8  (
  9    PARTITION list_p_tab_p1 VALUES(0)
 10    ,PARTITION list_p_tab_p2 VALUES(1)
 11    ,PARTITION list_p_tab_p3 VALUES(2)
 12    ,PARTITION list_p_tab_p4 VALUES(3)
 13* )
ORCL@SCOTT> /

Table created.

ORCL@SCOTT> ALTER TABLE list_p_tab ADD CONSTRAINT gpk_list_p_tab PRIMARY KEY(id_code) USING INDEX GLOBAL;

Table altered.

 ORCL@SCOTT> l
  1  DECLARE
  2    TYPE id_code_t IS TABLE OF list_p_tab.id_code%TYPE INDEX BY PLS_INTEGER;
  3    TYPE foo_t IS TABLE OF list_p_tab.foo%TYPE INDEX BY PLS_INTEGER;
  4    id_codes id_code_t;
  5    foos foo_t;
  6    k PLS_INTEGER := 1;
  7  BEGIN
  8    FOR i IN 1..400000 LOOP
  9        id_codes(k)            := TO_CHAR(i,'fm0000000009');
 10        foos(k)                := i;
 11        k := k + 1;
 12        IF k > 1000 THEN
 13          FORALL j in 1..k-1
 14            INSERT INTO list_p_tab VALUES(id_codes(j), foos(j), ORA_HASH(id_codes(j),3));
 15          COMMIT;
 16          k := 1;
 17        END IF;
 18    END LOOP;
 19* END;
ORCL@SCOTT> /

PL/SQL procedure successfully completed.

Elapsed: 00:00:12.28

ORCL@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'LIST_P_TAB',granularity=>'ALL',cascade=>true,no_invalidate=>false,degree=>4);

PL/SQL procedure successfully completed.

Elapsed: 00:00:02.51

ORCL@SCOTT> r
  1  select
  2    table_name
  3    ,partition_name
  4    ,num_rows
  5  from
  6    user_tab_partitions
  7  where
  8    table_name = 'LIST_P_TAB'
  9  order by
 10*   1,2

TABLE_NAME                     PARTITION_NAME                   NUM_ROWS
------------------------------ ------------------------------ ----------
LIST_P_TAB                     LIST_P_TAB_P1                       99901
LIST_P_TAB                     LIST_P_TAB_P2                      100194
LIST_P_TAB                     LIST_P_TAB_P3                      100056
LIST_P_TAB                     LIST_P_TAB_P4                       99849

ORCL@SCOTT> select id_code_hash_value,count(1) from list_p_tab group by id_code_hash_value order by 1;

ID_CODE_HASH_VALUE   COUNT(1)
------------------ ----------
                 0      99901
                 1     100194
                 2     100056
                 3      99849

Elapsed: 00:00:00.06

ORCL@SCOTT> explain plan for 
  2  select
  3    *
  4  from
  5    list_p_tab
  6  where
  7    id_code_hash_value = 1;       

Explained.

Elapsed: 00:00:00.10
ORCL@SCOTT> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
Plan hash value: 2143708561

----------------------------------------------------------------------------------------------------
| Id  | Operation             | Name       | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |            |   100K|  2054K|   275   (1)| 00:00:01 |       |       |
|   1 |  PARTITION LIST SINGLE|            |   100K|  2054K|   275   (1)| 00:00:01 |     2 |     2 |
|   2 |   TABLE ACCESS FULL   | LIST_P_TAB |   100K|  2054K|   275   (1)| 00:00:01 |     2 |     2 |
----------------------------------------------------------------------------------------------------

グローバル索引を作成してあるので、パーティション関係ない検索は主キー索引経由でも可。

ORCL@SCOTT> explain plan for select * from list_p_tab where id_code = '00004000000';

Explained.

Elapsed: 00:00:00.02
ORCL@SCOTT> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------------------------------
Plan hash value: 4132161764

---------------------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name           | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
---------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |                |     1 |    21 |     3   (0)| 00:00:01 |       |       |
|   1 |  TABLE ACCESS BY GLOBAL INDEX ROWID| LIST_P_TAB     |     1 |    21 |     3   (0)| 00:00:01 | ROWID | ROWID |
|*  2 |   INDEX UNIQUE SCAN                | GPK_LIST_P_TAB |     1 |       |     2   (0)| 00:00:01 |       |       |
---------------------------------------------------------------------------------------------------------------------

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

   2 - access("ID_CODE"='00004000000')

Join Elimination（結合の排除）と 参照整合性制約 / FAQ

偶に聞かれることがあるので、再び、Join Elimination（結合の排除）について

まずは、以下のSQL文を。

order表とcustomers表をinner joinしている単純な文ですが、重要なのは、実行計画の方！

order表とcustomers表をinner joinしているのに、order表だけ（この場合、order表の主キー索引だけのIndex Only Scanになっていますが）で、customes表を結合していせん。

理由は単純で、以下のSQL文では、customsers表の結合が不要なだけなんです。なぜかわかりますか？

以前、浅瀬でジャブジャブしていたセッション資料にヒントがあります。

db tech showcase Tokyo 2013 - A35 特濃JPOUG：潮溜まりでジャブジャブ、SQLチューニングの「参照整合性制約アレルギー」を参照のこと

order表に定義されている参照整合性制約によりcustomer_idがcustomsers表に存在していることを確認するための結合は不要と、オプティマイザーが判断した結果なんですよね。これ。

上記以外のケースでも無駄な結合を排除しようとする最適化を行うことがあります。内部的にはSQL文を書き換えてくれているわけですね。無駄に結合を行わないために。。。10053トレースをとって、　Join Elimination で grep をかけてみるとオプティマイザの気持ちが見えてきます:)

ORCL@OE> explain plan for
  2  select
  3    distinct
  4    order_id
  5  from
  6    orders o 
  7    , customers c
  8  where
  9    o.customer_id = c.customer_id
 10    and order_id < 2400;

Explained.

ORCL@OE> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
Plan hash value: 1653993310

-----------------------------------------------------------------------------
| Id  | Operation        | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT |          |    46 |   184 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| ORDER_PK |    46 |   184 |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------

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

   1 - access("ORDER_ID"<2400)

上記、SQL文は、参照整合性制約により、orders表に存在するcustomer_idがcustomers表に存在することが保証されているため、結合により存在確認が不要となり、Optimizerは内部的にSQL文を以下のように書き換えたということになります。賢いですよね。

ORCL@OE> r
  1  explain plan for
  2  select
  3    distinct
  4    order_id
  5  from
  6    orders o
  7  where
  8*   order_id < 2400

Explained.

ORCL@OE> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
Plan hash value: 1653993310

-----------------------------------------------------------------------------
| Id  | Operation        | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT |          |    46 |   184 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| ORDER_PK |    46 |   184 |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------

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

   1 - access("ORDER_ID"<2400)

13 rows selected.

order表の参照整合性制約を確認しておきます。

ORCL@OE> r
  1  select
  2    table_name
  3    ,owner
  4    ,constraint_name
  5    ,constraint_type
  6    ,r_owner
  7    ,r_constraint_name
  8    ,status
  9    ,rely
 10  from
 11    user_constraints
 12  where
 13*   constraint_type='R'

TABLE_NAME                     OWNER                          CONSTRAINT_NAME                C R_OWNER                        R_CONSTRAINT_NAME              STATUS   RELY
------------------------------ ------------------------------ ------------------------------ - ------------------------------ ------------------------------ -------- ----
ORDERS                         OE                             ORDERS_CUSTOMER_ID_FK          R OE                             CUSTOMERS_PK                   ENABLED
INVENTORIES                    OE                             INVENTORIES_WAREHOUSES_FK      R OE                             WAREHOUSES_PK                  ENABLED
INVENTORIES                    OE                             INVENTORIES_PRODUCT_ID_FK      R OE                             PRODUCT_INFORMATION_PK         ENABLED
ORDER_ITEMS                    OE                             ORDER_ITEMS_ORDER_ID_FK        R OE                             ORDER_PK                       ENABLED
ORDER_ITEMS                    OE                             ORDER_ITEMS_PRODUCT_ID_FK      R OE                             PRODUCT_INFORMATION_PK         ENABLED
PRODUCT_DESCRIPTIONS           OE                             PD_PRODUCT_ID_FK               R OE                             PRODUCT_INFORMATION_PK         ENABLED

ORCL@OE> r
  1  select
  2    table_name
  3    ,column_name
  4    ,constraint_name
  5  from
  6    user_cons_columns
  7  where
  8    table_name in ('ORDERS','CUSTOMERS')
  9  order by
 10*   table_name

TABLE_NAME                     COLUMN_NAME                    CONSTRAINT_NAME
------------------------------ ------------------------------ ------------------------------
CUSTOMERS                      CUSTOMER_ID                    CUSTOMERS_PK
CUSTOMERS                      CUST_FIRST_NAME                CUST_FNAME_NN
CUSTOMERS                      CUSTOMER_ID                    CUSTOMER_ID_MIN
CUSTOMERS                      CREDIT_LIMIT                   CUSTOMER_CREDIT_LIMIT_MAX
CUSTOMERS                      CUST_LAST_NAME                 CUST_LNAME_NN
ORDERS                         ORDER_ID                       ORDER_PK
ORDERS                         ORDER_TOTAL                    ORDER_TOTAL_MIN
ORDERS                         ORDER_MODE                     ORDER_MODE_LOV
ORDERS                         CUSTOMER_ID                    ORDER_CUSTOMER_ID_NN
ORDERS                         CUSTOMER_ID                    ORDERS_CUSTOMER_ID_FK
ORDERS                         ORDER_DATE                     ORDER_DATE_NN

Oracle SQL DeveloperでリバースエンジニアリングしたERDは以下のとおり

では、最後に、参照整合性制約を無効化した場合、実行計画はどうなるか見ておきましょう。

ORCL@OE> alter table orders disable constraint orders_customer_id_fk;

Table altered.

ORCL@OE> r
  1  select
  2    table_name
  3    ,owner
  4    ,constraint_name
  5    ,constraint_type
  6    ,r_owner
  7    ,r_constraint_name
  8    ,status
  9    ,rely
 10  from
 11    user_constraints
 12  where
 13*   constraint_type='R'

TABLE_NAME                     OWNER                          CONSTRAINT_NAME                C R_OWNER                        R_CONSTRAINT_NAME              STATUS   RELY
------------------------------ ------------------------------ ------------------------------ - ------------------------------ ------------------------------ -------- ----
ORDERS                         OE                             ORDERS_CUSTOMER_ID_FK          R OE                             CUSTOMERS_PK                   DISABLED
INVENTORIES                    OE                             INVENTORIES_WAREHOUSES_FK      R OE                             WAREHOUSES_PK                  ENABLED
INVENTORIES                    OE                             INVENTORIES_PRODUCT_ID_FK      R OE                             PRODUCT_INFORMATION_PK         ENABLED
ORDER_ITEMS                    OE                             ORDER_ITEMS_ORDER_ID_FK        R OE                             ORDER_PK                       ENABLED
ORDER_ITEMS                    OE                             ORDER_ITEMS_PRODUCT_ID_FK      R OE                             PRODUCT_INFORMATION_PK         ENABLED
PRODUCT_DESCRIPTIONS           OE                             PD_PRODUCT_ID_FK               R OE                             PRODUCT_INFORMATION_PK         ENABLED

あらまあ、不思議w わざとらしいw

customers表げ結合されちゃってネステッドループ結合に！

ORCL@OE> r
  1  explain plan for
  2  select
  3    distinct
  4    order_id
  5  from
  6    orders o
  7    , customers c
  8  where
  9    o.customer_id = c.customer_id
 10*   and order_id < 2400

Explained.

ORCL@OE> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------
Plan hash value: 2552081916

----------------------------------------------------------------------------------------------
| Id  | Operation                     | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |              |    46 |   552 |     3  (34)| 00:00:01 |
|   1 |  SORT UNIQUE NOSORT           |              |    46 |   552 |     3  (34)| 00:00:01 |
|   2 |   NESTED LOOPS SEMI           |              |    46 |   552 |     2   (0)| 00:00:01 |
|*  3 |    TABLE ACCESS BY INDEX ROWID| ORDERS       |    46 |   368 |     2   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN          | ORDER_PK     |    46 |       |     1   (0)| 00:00:01 |
|*  5 |    INDEX UNIQUE SCAN          | CUSTOMERS_PK |   319 |  1276 |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------

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

   3 - filter("O"."CUSTOMER_ID">0)
   4 - access("ORDER_ID"<2400)
   5 - access("O"."CUSTOMER_ID"="C"."CUSTOMER_ID")

目黒方面の密林で、美登利の寿司弁当を食べるのが最近のマイブームw

ではまた。

Wait Events

データベース関連で待機イベントと言えば、これまでは、Oracle Database しか浮かばなかったわけですが、今は、PostgreSQL、そして、MySQL にも実装された。

待機イベントを知らずして、どうするの？　でも大丈夫。 今までOracleの待機イベントに親しんできたデータベースエンジニアの活躍の場が広がるんじゃないかなぁ。。。と遠くをみている。。。

Oracle Database Wait Events

PostgreSQL Wait Events

MySQL : 25.12.15.1 Wait Event Summary Tables

SQL*Plusでcsv出力できるんですよ #2 null はどうなる？ / FAQ

前回は、SQL*Plusでcsvファイルをお手軽にできることを確認したので、今回はもう少し細かいところを確認しておきます。

csvファイルを作成するOracle Databaseのバージョン等は以下のとおり。

SQL> select
  2    banner_full
  3  from
  4    v$version;

BANNER_FULL
--------------------------------------------------------------------------------
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.3.0.0.0

データベースキャラクタセットは最近では一般的なAL32UTF8

SQL> r
  1  select
  2    parameter
  3    , value
  4  from
  5    nls_database_parameters
  6  where
  7*   parameter in ('NLS_CHARACTERSET')

PARAMETER                                VALUE
---------------------------------------- ------------------------------
NLS_CHARACTERSET                         AL32UTF8

SQL> 
SQL> !echo $NLS_LANG
Japanese_Japan.AL32UTF8

SQL> !echo $LANG
ja_JP.UTF-8

適当に作成した表は以下のとおり。NULLの取り込みを見ておきたかったのでnullも含めてあります。

SQL> desc test
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID                                        NOT NULL NUMBER
 DATA                                               VARCHAR2(10)
 FOO                                       NOT NULL VARCHAR2(10)
 
SQL> select * from test order by id;

        ID DATA       FOO
---------- ---------- ----------
         1 テスト     note
         2 平成       note
         3 abcdbef    note
         4 あ         note
         5 A          note
         6            note

6行が選択されました。

id=6のdata列は　null なのですが空白区別しにくいので可視化して確認しておきます。
注意）set null コマンドで設定した文字列は csv作成時のにも反映されるため空にリセットすることをお忘れなく。

SQL> set null [null]
SQL> select * from test order by id;

        ID DATA       FOO
---------- ---------- ----------
         1 テスト     note
         2 平成       note
         3 abcdbef    note
         4 あ         note
         5 A          note
         6 [null]     note

6行が選択されました。

SQL> set null ""

csvファイルの作成。スクリプトの例は前回の記事（SQL*Plusでcsv出力できるんですよ / FAQ）参照のこと。

SQL> @makecsv test
SQL> !cat loaddata_test.csv
1,"テスト","note"
2,"平成","note"
3,"abcdbef","note"
4,"あ","note"
5,"A","note"
6,,"note"

SQL> exit
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Productionとの接続が切断されました。
discus-mother:˜ oracle$ 

ということで、 nullは、,, としてcsvファイルに書き出されることを確認しました。
だたし、set nullでnullを他の文字列に置き換えている場合には、置換した文字列がそのままcsvファイルへかきだされてしまうので注意が必要です。

---

previously on Mac De Oracle
SQL*Plusでcsv出力できるんですよ / FAQ

---

数日前の朝、仕事先に向かおうとしら、ちょいと熱っぽい？、頭痛もあるな！　と体温を測ったら37度、インフル？
と思い仕事を休んで夕方まで様子見。。。熱は夜更けすぎに、平熱と変わっていましたw めでたしめでたし:) インフルじゃなくてよかった。
家庭内隔離解除されてほっとしているところ。。
では、また。

Oracle Database Connect 2018 エキスパートはどう考えるか？ 体感！パフォーマンスチューニング Ⅱ （番外編＝没ネタ）

Oracle Database Connect 2018 エキスパートはどう考えるか？体感！パフォーマンスチューニング Ⅱ
～Autonomous Databaseの到来において必要となるチューニングとは～

これ、パフォーマンスチューニングネタをまとめ上げるまで、みなさんスケジュール調整し、
オンライン／オフラインミーティングを繰り返してネタを詰めていくという、かなーり面倒なことをやっています。
私なんて、ネタの候補検討だけで16時間ぐらい使ってますからねw（自分の余暇を使って、半分楽しみながら、締め切りがあるので半分苦しみながらw）

---

余談はこれくらいにして、今日の本題です。:)

Oracle Database Connect 2018 エキスパートはどう考えるか？ 体感！パフォーマンスチューニング Ⅱ で没にしたネタがあるのですが、
そのまま捨てるのも勿体ないので、多少取得情報を追加した状態で公開しちゃおうと思います。

お時間のありますときに、頭の体操、AWRレポートの解析方法（最近はADDM、ASHレポートまで含まれています）のトレーニングにどうぞ。

遅延原因の想定と、想定原因の特定情報は、このエントリでは公開しません。おそらくGW開けの12日あたりか、その一週間後の19日ごろには原因を公開しようかと:)の後半に追記してあります:)

なお、本ページに公開した情報以外に、追加で見たい情報がある場合は、コメント欄やtwのmentionで具体的にリクエストいただければ、取得されている情報の範囲内で追加公開します。取得されてない情報はその旨を追記していきます。:)
まずは、エスパー力全開で、原因を想定してみてください。>
(かなり難易度高めだとは思いますが、過去この状況に遭遇した経験をお持ちのかたは、ここに公開した程度の情報から勘で言い当てたりしちゃうんですよね。実は、昨年末に、何年か振りでこの症状を目にしたのでネタにしよう思いました。)

以下取得された情報は以下のとおり。以下の情報を元に遅延原因を想定してみてください。

---

なーんでだ？！

---

状況説明
試験時には問題のなかった処理（30分以内に終了する状態が正常な状態です。）をリリースしました。
ところが、30分以上経過しても終了しません。遅延原因を想定、特定してください。
なお、本番環境のメンテナンス時間中に試験を行ったため、データベースインスタンス内で試験を行いリリースしています。
ちなみに、試験時の処理時間は、約21分でしたが、リリース時は約56分と大幅に遅延。

他のトランザクションが走行している状況をミックスするとより
本物っぽくなり、特定に苦労するので面白いのですが、
遅延している処理だけが走行している状況にしてあります。

---

資料1 試験時（正常時）AWRレポート
資料2 リリース時（遅延時）AWRレポート
資料3 試験時（正常時）とリリース時（遅延時）のAWR DIFFレポート

資料4 試験時（正常時）CPU利用率グラフ(調査による多少のノイズあり）

資料5 リリース時（遅延時）CPU利用率グラグ(スパイク部分調査による多少のノイズあり）

GWも後半スタート、天気は少々荒れそうですが、みなさん、よいGWを！

---

---

Twitterでのやり取り....

---

---

ここまでくるとなにかが見えてきたかな。。。原因を特定するまであと一歩な感じ。

追加資料1（遅延時）
top

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
13058 oracle    20   0 10.434g 365704 359548 R 100.0  1.4   1:05.70 oracle_13058_or
 5973 oracle    20   0 1955632 253648  73812 S   4.7  1.0   1:42.62 gnome-shell
 4657 oracle    -2   0 10.417g  58792  55660 S   2.0  0.2   0:12.15 ora_vktm_orcl12
 1285 root      20   0  483544  76000  21372 S   1.7  0.3   0:55.11 Xorg
 4862 oracle    20   0 10.417g  68960  65868 S   1.3  0.3   0:01.23 ora_lg00_orcl12
  223 root      20   0       0      0      0 S   0.7  0.0   0:00.49 kworker/u24:3
13059 oracle    20   0  157976   4564   3544 R   0.7  0.0   0:00.29 top
   ...略...

追加資料2（遅延時）
sar -P ALL

   ...略...
02:47:29 AM    CPU     %user     %nice   %system   %iowait    %steal     %idle
02:47:34 AM    all      4.78      0.00      2.36      0.07      0.00     92.80
02:47:34 AM      0      1.06      0.00      1.06      0.85      0.00     97.03
02:47:34 AM      1      0.20      0.00      0.40      0.00      0.00     99.40
02:47:34 AM      2      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM      3      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM      4      0.00      0.00      0.20      0.00      0.00     99.80
02:47:34 AM      5      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM      6      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM      7     68.08      0.00     31.92      0.00      0.00      0.00
02:47:34 AM      8      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM      9      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM     10      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM     11      0.00      0.00      0.20      0.20      0.00     99.60
   ...略...

追加資料3（遅延時）
perf top -C 7

Samples: 107K of event 'cpu-clock', Event count (approx.): 29550214790                                                              

Overhead  Shared Object       Symbol
   4.36%  libc-2.17.so        [.] vfprintf
   2.77%  oracle              [.] lxoCpStr
   2.00%  [kernel]            [k] __radix_tree_lookup
   1.94%  oracle              [.] dbgfcsIlcsGetNextDef
   1.58%  oracle              [.] skgovprint
   1.48%  [kernel]            [k] __do_softirq
   1.44%  [kernel]            [k] selinux_file_permission
   1.43%  oracle              [.] dbgaFmtAttrCb_int
   1.36%  [kernel]            [k] system_call_after_swapgs
   1.33%  oracle              [.] dbgaAttrFmtProcArg
   1.26%  oracle              [.] dbgtfmWriteMetadata
   1.13%  oracle              [.] dbgtfdFileWrite
   1.02%  libc-2.17.so        [.] _IO_default_xsputn
   ...略...

---

---

その後のやりとり　（Twitter）

そして核心に迫る追加資料が...あったんです。（しばちょうさん風にはしづらかったw）

---

---

正常時（試験時）の追加情報はないようです。リリース後は常に遅いらしい。

ふむふむ。

以下、遅延時のstrace -c -pの情報を取得してもらいました。
straceで眺めるとsystem call write()がダントツで上位にきています。その次が lseek()

追加資料4
strace -c -p

[oracle@localhost ˜]$ sudo strace -c -p 13058
Process 13058 attached
^CProcess 13058 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 77.24   47.883538           1  35085592           write
 19.22   11.913638           1  17542850           lseek
  3.53    2.191099           1   3414889           getrusage
  0.01    0.006377          12       524           semop
  0.00    0.000403           7        62           close
  0.00    0.000210           4        54           chown
  0.00    0.000126           2        63           open
  0.00    0.000099           2        54           lstat
  0.00    0.000050           1        54           chmod
  0.00    0.000029           1        54           stat
  0.00    0.000028           3        10           semtimedop
  0.00    0.000015           0        54           fcntl
  0.00    0.000010           1         8           read
  0.00    0.000007           1         8           select
  0.00    0.000000           0         3           mmap
  0.00    0.000000           0         6           rt_sigprocmask
  0.00    0.000000           0         1           rt_sigreturn
  0.00    0.000000           0         1           readlink
------ ----------- ----------- --------- --------- ----------------
100.00   61.995629              56044287           total

そろそろ突き止めた感が。

なにかを、どこかに、書き出してますよね。

lsofで書き込みに絞って取得してもった結果は以下のとおり。

[root@localhost ˜]# lsof -p 13058 | grep -E '[0-9]+w'
oracle_13 13058 oracle    1w      CHR    1,3         0t0      1038 /dev/null
oracle_13 13058 oracle    2w      CHR    1,3         0t0      1038 /dev/null
oracle_13 13058 oracle    7w      REG   8,17  2351882843  71176413 /u01/app/oracle/diag/rdbms/orcl12c/orcl12c/trace/orcl12c_ora_13058.trc
oracle_13 13058 oracle    8w      REG   8,17   358606101  71176414 /u01/app/oracle/diag/rdbms/orcl12c/orcl12c/trace/orcl12c_ora_13058.trm

ほう。　.trcファイルへ大量の書き込みがあります。

このようになるときは、 なにが起っていると思いますか？

.trcファイルに大量の書き込みのあるケースとして、SQLトレースが有効になっている場合です。（意図したSQLトレースなら問題はないですが...意図していない場合はちょいと問題ですよね。）

ということで、確定診断に移りましょう。

SQL*Plus: Release 12.2.0.1.0 Production on Wed Apr 25 01:23:13 2018

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

Connected.
ORCL@SYSTEM> 
ORCL@SYSTEM> select username,status,event,sql_trace from v$session where paddr = (select addr from v$process where spid = 13058)

USERNAME                       STATUS   EVENT                                                            SQL_TRAC
------------------------------ -------- ---------------------------------------------------------------- --------
SCOTT                          ACTIVE   log file switch completion                                       ENABLED

見ての通り、
SQL_TRACE列がdisabled（デフォルト)からenabledに変わっていることから、.trcファイルへの大量の書き出しは、セッションレベルでSQLトレースが有効化されたため、と言えますよね。

今回の新規リリースバッチ処理遅延の原因は、

SQLトレースを有効化したままリリースしたしまったことにより、オーバーヘッドが発生し、グルグル系バッチ処理のスループットが低下したため！　

ということでした。SQLトレースを利用したあとの無効化をお忘れなく！ :)

SQLトレースは便利な機能の一つですが、インスタンスレベルやグルグル系バッチ処理での利用時は大量のトレース情報の書き出し等によるオーバーヘッドが発生します。
便利なツールではありますが、スループットの低下等による影響を考慮して利用するタイプのツールでもあります。
また、利用した後は、必ず、無効化することもお忘れなく...

ミイラ取りがミイラになってしまってはいみないですから.....ね :)

Temp落ち #9 - 自動PGA管理で_pga_max_sizeと戯れたPGAサイズって本当に使えるのか？ 12.2.0.1版

Previously on Mac De Oracle

自動PGA管理下で、_pga_max_size隠しパラメータとpga_aggregate_targetを最大値に設定するした場合、global memory boundは
最大で、約839GBまで増加することがわかりました。

ただ、これは、内部的なパラメータ上の話。

---

今日は、実際にソートやハッシュ結合を行なわせ、PGAのSQL Work Areaサイズがどこまで利用できるものなのか確認してみることにします。

さて、どういう結末になりますやら（w

随分前から同じようなことを試している方はいますし....:)

なぜ今そこをdiggingしちゃってるのか？　って？

メモリーたっぷりあるのに、何故Temp落ち？　が話題になったからに決まってるじゃないですかw

まず、デフォルト設定では最大サイズだった　1GB を超えられるか？　の確認

注意） 事前にpga_aggregate_target および　_pga_max_size をそれぞれ 4TB - 1に設定し、パラメータの上では、global memory boundが約839GBにしてあります。

なお、Temp落ちの確認データやスクリプトはTemp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認のエントリーを参照のこと。

ソートやハッシュ結合は2GB程度になるように調整しています。
2GBのソート

ORCL@SCOTT> @auto_sortwk2gb_optimal.sql

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
workarea_size_policy                 string      AUTO

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 4398046511103

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size                        big integer 4398046511103

NAME                                                                        VALUE UNIT             CON_ID
---------------------------------------------------------------- ---------------- ------------ ----------
global memory bound                                                  879609302016 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C750000'
 10  ORDER BY
 11      id
 12*     ,rev#
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=3534657201)
========================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity |    Activity Detail    |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |      (# samples)      |
========================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        34 |     +2 |     1 |       1M |      |       |     . |     5.26 | Cpu (1)               |
|  1 |   SORT ORDER BY      |      |      1M |  553K |        34 |     +2 |     1 |       1M |      |       |   2GB |    26.32 | Cpu (5)               |
|  2 |    TABLE ACCESS FULL | M1   |      1M | 90829 |        17 |     +1 |     1 |       1M | 2637 |   3GB |     . |    68.42 | Cpu (3)               |
|    |                      |      |         |       |           |        |       |          |      |       |       |          | direct path read (10) |
========================================================================================================================================================

2GBのハッシュ結合

ORCL@SCOTT> @auto_hashwk2gb_optimal.sql

・・・中略・・・

NAME                                                                     VALUE UNIT             CON_ID
---------------------------------------------------------------- ------------- ------------ ----------
global memory bound                                               879609302016 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4          LEADING(m1 m2)
  5          USE_HASH(m2)
  6      */
  7      *
  8  FROM
  9      m1
 10      INNER JOIN m2
 11      ON
 12          m1.id = m2.id
 13          AND m1.rev# = m2.rev#
 14  WHERE
 15*     m1.id <= 'C084000'
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=1822065247)
===========================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity |     Activity Detail      |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |       (# samples)        |
===========================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        37 |     +2 |     1 |     840K |      |       |     . |     4.35 | Cpu (1)                  |
|  1 |   HASH JOIN          |      |    843K |  351K |        37 |     +2 |     1 |     840K |      |       |   2GB |    26.09 | Cpu (5)                  |
|    |                      |      |         |       |           |        |       |          |      |       |       |          | PGA memory operation (1) |
|  2 |    TABLE ACCESS FULL | M1   |    843K | 90828 |        15 |     +1 |     1 |     840K | 2633 |   3GB |     . |    52.17 | Cpu (1)                  |
|    |                      |      |         |       |           |        |       |          |      |       |       |          | direct path read (11)    |
|  3 |    TABLE ACCESS FULL | M2   |    846K | 90581 |        23 |    +16 |     1 |     840K | 2619 |   3GB |     . |    17.39 | Cpu (2)                  |
|    |                      |      |         |       |           |        |       |          |      |       |       |          | direct path read (2)     |
===========================================================================================================================================================

ソートやハッシュ結合は4GB程度になるように調整しています。
見ての通り、ソートは4GBのメモリー内ソートですが、ハッシュ結合は、2GBまで使ったところで Temp落ち！ （こんなもんなんですよ。実は!)
4GBのソート

ORCL@SCOTT> @auto_sortwk4gb_optimal.sql

・・・中略・・・

NAME                                                                     VALUE UNIT             CON_ID
---------------------------------------------------------------- ------------- ------------ ----------
global memory bound                                               879609302016 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C085000'
 10  UNION ALL
 11  SELECT *
 12  FROM
 13      m1 m12
 14  WHERE
 15      id <= 'C085000'
 16  ORDER BY
 17*     1, 2
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
-----------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=2686238998)
============================================================================================================================================================
| Id |       Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity |     Activity Detail      |
|    |                       |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |       (# samples)        |
============================================================================================================================================================
|  0 | SELECT STATEMENT      |      |         |       |        40 |     +2 |     1 |       2M |      |       |     . |    27.78 | Cpu (5)                  |
|  1 |   SORT ORDER BY       |      |      2M |  182K |        41 |     +1 |     1 |       2M |      |       |   4GB |    38.89 | Cpu (6)                  |
|    |                       |      |         |       |           |        |       |          |      |       |       |          | PGA memory operation (1) |
|  2 |    UNION-ALL          |      |         |       |        12 |     +2 |     1 |       2M |      |       |     . |          |                          |
|  3 |     TABLE ACCESS FULL | M1   |    855K | 90828 |         6 |     +2 |     1 |     850K | 2633 |   3GB |     . |    22.22 | Cpu (2)                  |
|    |                       |      |         |       |           |        |       |          |      |       |       |          | direct path read (2)     |
|  4 |     TABLE ACCESS FULL | M1   |    855K | 90828 |         6 |     +8 |     1 |     850K | 2633 |   3GB |     . |    11.11 | Cpu (2)                  |
============================================================================================================================================================

4GBのハッシュ結合 最大3GBのPGAが消費されていますが、Temp落ちしないサイズ、つまり、optimalで処理する場合には、最大2GBが最大サイズとなっています。以下を3GBのハッシュ結合にすると、2GBまでPGAを消費し、一時表領域が3GB利用されます。

ORCL@SCOTT> @auto_hashwk4gb_optimal.sql
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=3532417599)
=========================================================================================================================================================================================
| Id |       Operation        | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read  | Read  | Write | Write |  Mem  | Temp  | Activity |       Activity Detail       |
|    |                        |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs  | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |         (# samples)         |
=========================================================================================================================================================================================
|  0 | SELECT STATEMENT       |      |         |       |       216 |     +2 |     1 |       3M |       |       |       |       |     . |     . |     4.49 | Cpu (7)                     |
|  1 |   HASH JOIN            |      |      2M |  670K |       217 |     +1 |     1 |       3M | 18091 |   4GB | 18091 |   4GB |   3GB |   4GB |    79.49 | Cpu (87)                    |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read temp (19)  |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path write temp (18) |
|  2 |    VIEW                |      |      2M |  182K |         9 |     +2 |     1 |       2M |       |       |       |       |     . |     . |          |                             |
|  3 |     UNION-ALL          |      |         |       |         9 |     +2 |     1 |       2M |       |       |       |       |     . |     . |          |                             |
|  4 |      TABLE ACCESS FULL | M1   |    752K | 90828 |         5 |     +2 |     1 |     750K |  2633 |   3GB |       |       |     . |     . |     1.92 | Cpu (3)                     |
|  5 |      TABLE ACCESS FULL | M1   |    752K | 90828 |         4 |     +7 |     1 |     750K |  2633 |   3GB |       |       |     . |     . |     1.92 | Cpu (3)                     |
|  6 |    VIEW                |      |      2M |  181K |        78 |    +99 |     1 |       2M |       |       |       |       |     . |     . |     0.64 | Cpu (1)                     |
|  7 |     UNION-ALL          |      |         |       |        78 |    +99 |     1 |       2M |       |       |       |       |     . |     . |          |                             |
|  8 |      TABLE ACCESS FULL | M2   |    759K | 90581 |        50 |    +92 |     1 |     750K |  2618 |   3GB |       |       |     . |     . |     9.62 | Cpu (2)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (13)       |
|  9 |      TABLE ACCESS FULL | M2   |    759K | 90581 |        36 |   +141 |     1 |     750K |  2618 |   3GB |       |       |     . |     . |     1.92 | Cpu (2)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (1)        |
=========================================================================================================================================================================================

では、最後に
ソートやハッシュ結合のサイズが8GB程度ならどうでしょうか？
結果は、ソートは4GBを使い切ったのち、Temp落ち、ハッシュ結合は、やはり、3GBまで利用したのちTemp落ちでした。なんと！（ちょっとわざとらしいリアクションしてすみませんw）

8GBのソート

ORCL@SCOTT> @auto_sortwk8gb_optimal.sql

・・・中略・・・

NAME                                                                     VALUE UNIT             CON_ID
---------------------------------------------------------------- ------------- ------------ ----------
global memory bound                                               879609302016 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C090000'
 10  UNION ALL
 11  SELECT *
 12  FROM
 13      m1 m12
 14  WHERE
 15      id <= 'C090000'
 16  UNION ALL
 17  SELECT *
 18  FROM
 19      m1 m13
 20  WHERE
 21      id <= 'C090000'
 22  UNION ALL
 23  SELECT *
 24  FROM
 25      m1 m14
 26  WHERE
 27      id <= 'C090000'
 28  ORDER BY
 29*     1, 2
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=946172832)
=========================================================================================================================================================================================
| Id |       Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read  | Read  | Write | Write |  Mem  | Temp  | Activity |       Activity Detail        |
|    |                       |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs  | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |         (# samples)          |
=========================================================================================================================================================================================
|  0 | SELECT STATEMENT      |      |         |       |       279 |     +2 |     1 |       4M |       |       |       |       |     . |     . |     5.79 | Cpu (6)                      |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | PGA memory operation (1)     |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | local write wait (7)         |
|  1 |   SORT ORDER BY       |      |      4M |  363K |       279 |     +2 |     1 |       4M | 38603 |   8GB | 32072 |   8GB |   4GB |   8GB |    84.30 | Cpu (49)                     |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | PGA memory operation (1)     |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read temp (28)   |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path write temp (126) |
|  2 |    UNION-ALL          |      |         |       |       176 |     +2 |     1 |       4M |       |       |       |       |     . |     . |          |                              |
|  3 |     TABLE ACCESS FULL | M1   |    907K | 90828 |        16 |     +1 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     4.55 | Cpu (2)                      |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (9)         |
|  4 |     TABLE ACCESS FULL | M1   |    907K | 90828 |         8 |    +17 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     2.48 | Cpu (5)                      |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (1)         |
|  5 |     TABLE ACCESS FULL | M1   |    907K | 90828 |        79 |    +26 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     2.48 | Cpu (2)                      |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (4)         |
|  6 |     TABLE ACCESS FULL | M1   |    907K | 90828 |        72 |   +106 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     0.41 | Cpu (1)                      |
=========================================================================================================================================================================================

8GBのハッシュ結合

ORCL@SCOTT> @auto_hashwk8gb_optimal.sql

・・・中略・・・

NAME                                                                     VALUE UNIT             CON_ID
---------------------------------------------------------------- ------------- ------------ ----------
global memory bound                                               879609302016 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4          LEADING(m1 m2)
  5          USE_HASH(m2)
  6      */
  7      *
  8  FROM
  9      (
 10          SELECT * FROM m1 m11
 11          UNION ALL
 12          SELECT * FROM m1 m12
 13          UNION ALL
 14          SELECT * FROM m1 m13
 15      ) m1
 16      INNER JOIN
 17      (
 18          SELECT * FROM m2 m21
 19          UNION ALL
 20          SELECT * FROM m2 m22
 21          UNION ALL
 22          SELECT * FROM m2 m23
 23      ) m2
 24      ON
 25          m1.id = m2.id
 26          AND m1.rev# = m2.rev#
 27  WHERE
 28*     m1.id <= 'C075000'
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=2506347387)
=========================================================================================================================================================================================
| Id |       Operation        | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read  | Read  | Write | Write |  Mem  | Temp  | Activity |       Activity Detail       |
|    |                        |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs  | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |         (# samples)         |
=========================================================================================================================================================================================
|  0 | SELECT STATEMENT       |      |         |       |       350 |     +2 |     1 |       7M |       |       |       |       |     . |     . |     9.18 | Cpu (18)                    |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | PGA memory operation (1)    |
|  1 |   HASH JOIN            |      |      5M |    1M |       350 |     +2 |     1 |       7M | 31032 |   7GB | 31032 |   7GB |   3GB |   8GB |    67.15 | Cpu (81)                    |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read temp (36)  |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path write temp (22) |
|  2 |    VIEW                |      |      2M |  272K |        27 |     +2 |     1 |       2M |       |       |       |       |     . |     . |          |                             |
|  3 |     UNION-ALL          |      |         |       |        27 |     +2 |     1 |       2M |       |       |       |       |     . |     . |     0.97 | Cpu (2)                     |
|  4 |      TABLE ACCESS FULL | M1   |    752K | 90828 |        16 |     +1 |     1 |     750K |  2633 |   3GB |       |       |     . |     . |     7.25 | Cpu (3)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (12)       |
|  5 |      TABLE ACCESS FULL | M1   |    752K | 90828 |         5 |    +18 |     1 |     750K |  2633 |   3GB |       |       |     . |     . |     1.45 | Cpu (2)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (1)        |
|  6 |      TABLE ACCESS FULL | M1   |    752K | 90828 |         7 |    +23 |     1 |     750K |  2633 |   3GB |       |       |     . |     . |     1.93 | Cpu (2)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (2)        |
|  7 |    VIEW                |      |      2M |  272K |       130 |    +97 |     1 |       2M |       |       |       |       |     . |     . |          |                             |
|  8 |     UNION-ALL          |      |         |       |       130 |    +97 |     1 |       2M |       |       |       |       |     . |     . |     0.48 | Cpu (1)                     |
|  9 |      TABLE ACCESS FULL | M2   |    759K | 90581 |        47 |    +88 |     1 |     750K |  2618 |   3GB |       |       |     . |     . |     4.83 | Cpu (3)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (7)        |
| 10 |      TABLE ACCESS FULL | M2   |    759K | 90581 |        41 |   +134 |     1 |     750K |  2618 |   3GB |       |       |     . |     . |     4.35 | Cpu (5)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (4)        |
| 11 |      TABLE ACCESS FULL | M2   |    759K | 90581 |        53 |   +174 |     1 |     750K |  2618 |   3GB |       |       |     . |     . |     2.42 | Cpu (1)                     |
|    |                        |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (4)        |
=========================================================================================================================================================================================

これ、Linuxのカーネルパラメータのvm.max_map_count

/proc/sys/vm/max_map_count

65530

が絡んでるよねという話と、隠しパラメータの realfree_heap関連のパラメータでも調整できそうだよね。という話はあるんですが...それはPL/SQLのはなし...で

_realfree_heap_pagesize                        65536                          TRUE
_use_realfree_heap                             TRUE                           TRUE

とりあえず、
vm/max_map_countを196608

にして
_realfree_heap_pagesize=65536 や
_realfree_heap_pagesize=256K

などとして戯れてみましたが

ソートやハッシュ結合で利用可能なサイズは、それらで制御できるものでもありません。いまのところ。

ORCL@SCOTT> @auto_sortwk8gb_optimal.sql

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
workarea_size_policy                 string      AUTO

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 4398046511103

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size                        big integer 4398046511103

NAME                                                                     VALUE UNIT             CON_ID
---------------------------------------------------------------- ------------- ------------ ----------
global memory bound                                               879609302016 bytes                 0

/proc/sys/vm/max_map_count
196608

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C090000'
 10  UNION ALL
 11  SELECT *
 12  FROM
 13      m1 m12
 14  WHERE
 15      id <= 'C090000'
 16  UNION ALL
 17  SELECT *
 18  FROM
 19      m1 m13
 20  WHERE
 21      id <= 'C090000'
 22  UNION ALL
 23  SELECT *
 24  FROM
 25      m1 m14
 26  WHERE
 27      id <= 'C090000'
 28  ORDER BY
 29*     1, 2
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

SQL Plan Monitoring Details (Plan Hash Value=946172832)
=========================================================================================================================================================================================
| Id |       Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read  | Read  | Write | Write |  Mem  | Temp  | Activity |       Activity Detail        |
|    |                       |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs  | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |         (# samples)          |
=========================================================================================================================================================================================
|  0 | SELECT STATEMENT      |      |         |       |       295 |     +2 |     1 |       4M |       |       |       |       |     . |     . |     3.38 | Cpu (8)                      |
|  1 |   SORT ORDER BY       |      |      4M |  363K |       297 |     +1 |     1 |       4M | 38603 |   8GB | 38600 |   8GB |   4GB |   8GB |    91.56 | Cpu (43)                     |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read temp (12)   |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path write temp (162) |
|  2 |    UNION-ALL          |      |         |       |       205 |     +2 |     1 |       4M |       |       |       |       |     . |     . |     0.84 | Cpu (2)                      |
|  3 |     TABLE ACCESS FULL | M1   |    907K | 90828 |         6 |     +2 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     2.11 | Cpu (1)                      |
|    |                       |      |         |       |           |        |       |          |       |       |       |       |       |       |          | direct path read (4)         |
|  4 |     TABLE ACCESS FULL | M1   |    907K | 90828 |         7 |     +8 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     0.42 | Cpu (1)                      |
|  5 |     TABLE ACCESS FULL | M1   |    907K | 90828 |       100 |    +14 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     0.84 | Cpu (2)                      |
|  6 |     TABLE ACCESS FULL | M1   |    907K | 90828 |        94 |   +113 |     1 |     900K |  2633 |   3GB |       |       |     . |     . |     0.84 | Cpu (2)                      |
=========================================================================================================================================================================================

ちなみに、PL/SQLで巨大なPGAメモリーを利用する場合は、しっかり9GBとか...やばい状態になったら、pga_aggregate_limitで抑えてくれると思いますが.....

[oracle@localhost ˜]$ ulimit -v -m
virtual memory          (kbytes, -v) unlimited
max memory size         (kbytes, -m) unlimited

orcl12c@SYS> @show_param

KSPPINM                                        KSPPSTVL                       KSPPSTDF
---------------------------------------------- ------------------------------ ------------------------------
_pga_max_size                                  4398046511103                  FALSE
_realfree_heap_pagesize                        65536                          TRUE
_use_realfree_heap                             TRUE                           TRUE
pga_aggregate_limit                            0                              FALSE
pga_aggregate_target                           4398046511103                  FALSE


/proc/sys/vm/max_map_count
65530

PGAを大量に消費するスクリプトは以下のブログを参考に
Max PGA Research: Check that a process can allocate a large volume of memory / Yury's Blog

ORCL@SCOTT> @plsql_pga8gb 8192
old   2: c_count number := 1024*&1;
new   2: c_count number := 1024*8192;

PL/SQL procedure successfully completed.

実際に確保されたPGAサイズなど。。。

ORCL@SCOTT> r
  1  select
  2  	vss.value/1024/1024/1024 "GB"
  3  	,vsn.name
  4  	,vss.sid
  5  from
  6  	v$sesstat vss
  7  	inner join v$statname vsn
  8  	on
  9  		vss.statistic# = vsn.statistic#
 10  		and vss.con_id = vsn.con_id
 11  		and (vsn.name like '%pga%' or vsn.name like '%uga%')
 12  where
 13  	sid IN (select sid from v$session where username='SCOTT')
 14  order by
 15* 	sid,name

        GB NAME                                                                    SID
---------- ---------------------------------------------------------------- ----------
9.49698084 session pga memory                                                      321
9.49698084 session pga memory max                                                  321
1.48221001 session uga memory                                                      321
3.99991362 session uga memory max                                                  321

[oracle@localhost ˜]$ free -h
              total        used        free      shared  buff/cache   available
Mem:            22G        1.0G        9.6G         11G         11G         10G
Swap:          4.0G        8.7M        4.0G

・・・中略・・・

[oracle@localhost ˜]$ free -h
              total        used        free      shared  buff/cache   available
Mem:            22G         10G        128M         11G         11G        705M
Swap:          4.0G        8.8M        4.0G

ここまでくればおわかりだと思いますが、global memory bound (約839GB)からは巨大なPGAサイズになりそうに思えますが、Temp落ちせずにソート可能なサイズは、隠しパラメータを調整した場合でも最大4GB、ハッシュ結合は、2GBが上限、となっています。いまのところ。。。。

ということは、2014年の以下のプレゼンでも話題になっていましたよね。:)
Overcome Oracle PGA Memory Limits Mar.5.2014 Alex Fatkulin / Enkatic

だったら、どのようにして、Temp落ち　に立ち向かえばいいんだろう.....次回へ続く　:)

---

10gR2(64bit)のころのままなので、以下のシリーズも合わせて読んでおくといいですよ：）

---

・Mac De Oracle なんですが、Windows(32bit)でのOracleな話
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #2
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #16
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #17
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #18
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #19
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。シーズン２
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #2
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #3
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #4
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #5
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #6
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #7
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #8

---

・Temp落ち #1 - "Temp落ち" って？
・Temp落ち #2 - PGA (Program Global Area)
・Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ
・Temp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認
・Temp落ち #5 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版 （その前に少し脱線）
・Temp落ち #6 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版
・Temp落ち #7 - 自動PGA管理で到達可能な最大サイズ de Temp落ちの確認 12.2.0.1版
・Temp落ち #8 - 自動PGA管理でパラメータ上設定可能な最大サイズは？（実際に利用可能なサイズとは限りませんが。意味深） 12.2.0.1版

Temp落ち #8 - 自動PGA管理でパラメータ上設定可能な最大サイズは？（実際に利用可能なサイズとは限りませんが。意味深） 12.2.0.1版

Previously on Mac De Oracle

自動PGA管理下では、SQL Work Areaサイズは、pga_aggregate_targetのサイズに応じて変化し、最大1GBまで調整され、それのサイズ以上のソートやハッシュ結合は、もれなく、"Temp落ち" する。
手動PGA管理下では、最大2GBまで指定できました。。自動だと1GBまでなのか。。。と残念がる声が、昔は海だった方面から聞こえた気がしましたが、たぶん、気のせいw

というところまででした。

---

今日は、自動PGA管理下ではそれが最大なのか？　のか？　自己責任で試してみることにしますw

まずはこれまでの復習。

自動PGA管理で、SQL Work Areaサイズの算出に関わるパラメータは以下の通り

pga_aggregate_target = 10MB 〜 4TB - 1
_pga_max_size = 200MB 〜　2GB
（Oracleが動的に値を調整している_pga_max_sizeパラメータへユーザーが値を設定してしまうとOracleの自動調整が無効化され、設定した値で固定されてしまうので注意が必要です。）

私の観測範囲だとおおよそ以下のように変化します。最近は大量のメモリーを搭載したサーバーが多いので、pga_aggregate_targetが10GB以上という状況も普通になってきたので、自動PGA管理下のSQL Work Areaサイズは最大1GBとざっくり丸暗記しても困ることは思いますw（ちょっと乱暴かw）

pga_aggregate_target = 10MB〜10GB - 1 :

_pga_max_size = 200MB 〜　2047MB
GREATEST(pga_aggregate_target*0.2 ,200MB)

pga_aggregate_target = 10GB以上〜4TB-1 :

_pga_max_size = 2GB
LEAST(pga_aggregate_target*0.2 ,2GB)

_pga_max_sizeはpga_aggregate_targetの値に応じて動的に変化し、それらを元に _smm_max_size が算出される

LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5)

pga_aggregate_target = 10MB〜10GB-1
_pga_max_size = 200MB〜2047MB
_smm_max_size = 2MB〜1023MB


pga_aggregate_target = 10GB〜4TB-1
_pga_max_size = 2048MB
_smm_max_size = 1024MB

_smm_max_sizeは、v$pgastatのglobal memory boundだろうということは確からしいということまでは確認しました。



いままでの結果をまとめると
PGAのSQL Work Areaサイズの最大サイズを示す global memory boundは、pga_aggregate_targetが10MB〜10GB-1までは2MB〜1023MBで調整され、pga_aggregate_targetが10GB〜4TB-1では、1024MB (1GB) で固定されている、というのが、Oracle 10GR2〜12cR2まで動きであることは間違いなさそう:)

自動PGA管理下でSQL Work Areaを1GBを超えるサイズにするにはどのパラメータをどのような値に設定すればよいか。。。
その鍵を握るパラメータは

_pga_max_size

(いまいちピンとこないという方は、過去のエントリーを参照していただけるとスッキリすると思います。）

ただ、冒頭にも書きましたが（昔それでハマったw）、（Oracleが動的に値を調整している_pga_max_sizeパラメータへユーザーが値を設定してしまうとOracleの自動調整が無効化され、設定した値で固定されてしまうので注意が必要です。）
という点はお忘れなく。また、今後も同仕様のままである保証はなく、世界中のOracle使いの方達が調べ上げた結果、現状はこんな感じ。
という状況だと認識しておいたほうが無難だと思っています。

とはいえ、実際どこまで設定可能なのか？　　1GBを以上使えるのか？　知りたいですよね...

長い前置きはこれぐらいにして、
実際にSQL Work Areaサイズに対応したメモリーが実際にどの程度割り当てられるのかということの確認は後回しですが、 パラメータの上では、どこまで設定できるのかというところを確認しました。

なお、
以下のエラーメッセージから、_pga_max_sizeに設定可能な値は、pga_aggregate_targetと同様（Big Integer）、10MB〜4TB-1までであると思われます。

orcl12c@SYS> show parameter _pga_max_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size                        big integer 2G

orcl12c@SYS> alter system set "_pga_max_size" = 4T scope=memory;
alter system set "_pga_max_size" = 4T scope=memory
*
行1でエラーが発生しました。:
ORA-02097: 指定した値が無効なので、パラメータを変更できません。 ORA-00093:
_pga_max_sizeは、10Mから4096G-1の間に設定する必要があります。

ということで、
_pga_max_sizeを1GB/10GB/100GB/1TB/4T-1のそれぞれに設定したうえで、Temp落ち #6 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版 で利用したスクリプトを利用し、global memory boundやその他パラメータの変化を確認しました。

ログの例

orcl12c@SYS> alter system set "_pga_max_size" = 10m scope=both;

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

orcl12c@SYS> show parameter _pga_max_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size                        big integer 10m


orcl12c@SYS> @dotest_auto_workarea
<< 10m >>
接続されました。
  1* alter system set pga_aggregate_target=&1 scope=spfile
旧   1: alter system set pga_aggregate_target=&1 scope=spfile
新   1: alter system set pga_aggregate_target=10m scope=spfile

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

データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
ORACLEインスタンスが起動しました。

Total System Global Area 2147483648 bytes
Fixed Size                  8794848 bytes
Variable Size             603983136 bytes
Database Buffers         1526726656 bytes
Redo Buffers                7979008 bytes
データベースがマウントされました。
データベースがオープンされました。
+++ initial parameters +++

KSPPINM                                        KSPPSTVL                       KSPPSTDF
---------------------------------------------- ------------------------------ ------------------------------
__pga_aggregate_target                         16777216                       FALSE

・・・中略・・・

pga_aggregate_limit                            0                              FALSE
pga_aggregate_target                           10485760                       FALSE

50行が選択されました。

/proc/sys/vm/max_map_count

65530

+++ v$pgastat +++

NAME                                                                  VALUE UNIT             CON_ID
---------------------------------------------------------------- ---------- ------------ ----------
aggregate PGA target parameter                                           10 MB                    0
aggregate PGA auto target                                                 4 MB                    0
global memory bound                                                       2 MB                    0

・・・中略・・・

結果は以下のグラフと表にまとめたとおり。
_pga_max_size=4TB-1、pga_aggregate_target=4TB-1の時のglobal memory bound (v$pgastat) = _smm_max_size が最大となり、約839GBとなることがわかりました。
パラメータ上は839GB程度まで増加しますが、ほんとうにPGAがそんなサイズまで利用可能なのでしょうか？....（怪しいです。答え、知ってるんですけどねw。。

ということで、

次回は実際に、そんなに使えんのかよ！　という実験をしてみたいと思います :)

つづく。

---

10gR2(64bit)のころのままなので、以下のシリーズも合わせて読んでおくといいですよ：）
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #2
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #16
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #17
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #18
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #19
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。シーズン２
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #2
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #3
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #4
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #5
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #6
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #7
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #8

---

・Temp落ち #1 - "Temp落ち" って？
・Temp落ち #2 - PGA (Program Global Area)
・Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ
・Temp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認
・Temp落ち #5 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版 （その前に少し脱線）
・Temp落ち #6 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版
・Temp落ち #7 - 自動PGA管理で到達可能な最大サイズ de Temp落ちの確認 12.2.0.1版

Temp落ち #7 - 自動PGA管理で到達可能な最大サイズ de Temp落ちの確認 12.2.0.1版

Previously on Mac De Oracle

自動PGA管理で利用可能なSQL Work Areaサイズはいくつなのか？の確認でした。
これまで同様、隠しパラメータ等の変更をしないデフォルトの設定では最大1GBまで到達することを確認しました。
また、手動PGA管理で利用可能な最大サイズより小さいことも再確認しました。

---

今日は自動PGA管理下ではオンメモリーで処理可能なサイズは1GBまでなのか、それを超えた場合はもれなく　"Temp落ち" なのか確認することにします。

確認用データおよび方法は前々回のエントリーを参照ください。

自動PGA管理でGlobal Memory Bound = 1GB（自動PGA管理での最大 Sort作業領域サイズ）

メモリーソートで1GBぐらいまで利用していることが確認できます。（ソートされるデータ量は1GB以下程度に制限しています。）

ORCL@SCOTT> @auto_sortwk1gb_optimal

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
workarea_size_policy                 string      AUTO

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 4398046511103

NAME                                                                  VALUE UNIT             CON_ID
---------------------------------------------------------------- ---------- ------------ ----------
global memory bound                                              1073741824 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C045000'
 10  ORDER BY
 11      id
 12*     ,rev#
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
===========================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
===========================================================================
|    4.78 |    3.85 |     0.34 |     0.59 | 30001 |   334K | 2633 |   3GB |
===========================================================================

SQL Plan Monitoring Details (Plan Hash Value=3534657201)
==================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity | Activity Detail |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |   (# samples)   |
==================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        10 |     +2 |     1 |     450K |      |       |     . |    33.33 | Cpu (2)         |
|  1 |   SORT ORDER BY      |      |    456K |  302K |        11 |     +1 |     1 |     450K |      |       |   1GB |    33.33 | Cpu (2)         |
|  2 |    TABLE ACCESS FULL | M1   |    456K | 90827 |         3 |     +2 |     1 |     450K | 2633 |   3GB |     . |    33.33 | Cpu (2)         |
==================================================================================================================================================

Temp落ちする程度のデータ量でソートさせた場合も、PGAの作業領域は最大1GBまで利用されていたことが確認できます。

ORCL@SCOTT> @auto_sortwk1gb_mpass    

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
workarea_size_policy                 string      AUTO

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 4398046511103

NAME                                                                  VALUE UNIT             CON_ID
---------------------------------------------------------------- ---------- ------------ ----------
global memory bound                                              1073741824 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C050000'
 10  ORDER BY
 11      id
 12*     ,rev#
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
===========================================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes | Reqs  | Bytes |
===========================================================================================
|      16 |    6.91 |     7.91 |     0.71 | 33335 |   334K | 7996 |   4GB |  4431 |   1GB |
===========================================================================================

SQL Plan Monitoring Details (Plan Hash Value=3534657201)
=====================================================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |      Activity Detail       |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |        (# samples)         |
=====================================================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        22 |     +2 |     1 |     500K |      |       |       |       |     . |     . |     6.25 | Cpu (1)                    |
|  1 |   SORT ORDER BY      |      |    507K |  326K |        22 |     +2 |     1 |     500K | 5363 |   1GB |  4431 |   1GB |   1GB |   1GB |    68.75 | Cpu (4)                    |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read temp (1)  |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path write temp (6) |
|  2 |    TABLE ACCESS FULL | M1   |    507K | 90828 |        13 |     +1 |     1 |     500K | 2633 |   3GB |       |       |     . |     . |    25.00 | Cpu (3)                    |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read (1)       |
=====================================================================================================================================================================================

自動PGA管理でGlobal Memory Bound = 1GB（自動PGA管理での最大 Hash作業領域サイズ）

Hash Joinの場合も、自動PGA管理の最大サイズ程度まで利用されていることが確認できます。（Temp落ちしない程度のデータ量にしています。）

ORCL@SCOTT> @auto_hashwk1gb_optimal

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
workarea_size_policy                 string      AUTO

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 4398046511103

NAME                                                                  VALUE UNIT             CON_ID
---------------------------------------------------------------- ---------- ------------ ----------
global memory bound                                              1073741824 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4          LEADING(m1 m2)
  5          USE_HASH(m2)
  6      */
  7      *
  8  FROM
  9      m1
 10      INNER JOIN m2
 11      ON
 12          m1.id = m2.id
 13          AND m1.rev# = m2.rev#
 14  WHERE
 15*     m1.id <= 'C042000'
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
===========================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
===========================================================================
|    7.29 |    5.05 |     0.68 |     1.55 | 28001 |   695K | 5251 |   5GB |
===========================================================================

SQL Plan Monitoring Details (Plan Hash Value=1822065247)
==================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity | Activity Detail |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |   (# samples)   |
==================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        14 |     +2 |     1 |     420K |      |       |     . |    22.22 | Cpu (2)         |
|  1 |   HASH JOIN          |      |    423K |  268K |        15 |     +1 |     1 |     420K |      |       |   1GB |    22.22 | Cpu (2)         |
|  2 |    TABLE ACCESS FULL | M1   |    432K | 90827 |         2 |     +2 |     1 |     420K | 2633 |   3GB |     . |    11.11 | Cpu (1)         |
|  3 |    TABLE ACCESS FULL | M2   |    423K | 90580 |        13 |     +3 |     1 |     420K | 2618 |   3GB |     . |    44.44 | Cpu (4)         |
==================================================================================================================================================

Hash Joinの場合もSort時と同じように、一時表領域も利用が必要となるデータ量になると、一旦、自動PGA管理の最大サイズ程度まで利用したうえでTemp落ちしていることが確認できます。

ORCL@SCOTT> @auto_hashwk1gb_mpass

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
workarea_size_policy                 string      AUTO

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 4398046511103

NAME                                                                  VALUE UNIT             CON_ID
---------------------------------------------------------------- ---------- ------------ ----------
global memory bound                                              1073741824 bytes                 0

  1  SELECT
  2      /*+
  3          MONITOR
  4          LEADING(m1 m2)
  5          USE_HASH(m2)
  6      */
  7      *
  8  FROM
  9      m1
 10      INNER JOIN m2
 11      ON
 12          m1.id = m2.id
 13          AND m1.rev# = m2.rev#
 14  WHERE
 15*     m1.id <= 'C055000'
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
============================================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read  | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs  | Bytes | Reqs  | Bytes |
============================================================================================
|      24 |    7.18 |       15 |     1.99 | 36668 |   687K | 10829 |   6GB |  5578 |   1GB |
============================================================================================

SQL Plan Monitoring Details (Plan Hash Value=1822065247)
======================================================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |       Activity Detail       |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |         (# samples)         |
======================================================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        33 |     +2 |     1 |     550K |      |       |       |       |     . |     . |    14.29 | Cpu (4)                     |
|  1 |   HASH JOIN          |      |    551K |  293K |        33 |     +2 |     1 |     550K | 5578 |   1GB |  5578 |   1GB |   1GB |   1GB |    67.86 | Cpu (8)                     |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read temp (1)   |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path write temp (10) |
|  2 |    TABLE ACCESS FULL | M1   |    551K | 90828 |        16 |     +1 |     1 |     550K | 2633 |   3GB |       |       |     . |     . |     7.14 | Cpu (1)                     |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read (1)        |
|  3 |    TABLE ACCESS FULL | M2   |    557K | 90580 |        16 |    +16 |     1 |     550K | 2618 |   3GB |       |       |     . |     . |    10.71 | Cpu (3)                     |
======================================================================================================================================================================================

PGAの最大サイズは異なりますが、自動PGA管理、手動PGA管理いずれでの場合でも制限値を超えた場合は、もれなく　"Temp落ち" するということはご理解いただけたのではないかと思います。

では、次回は恒例？w の隠しパラメータと戯れた場合、自動PGA管理下ではどこまで増加させることができるのか？。。。。確認してみたいと思います。

---

・Temp落ち #1 - "Temp落ち" って？
・Temp落ち #2 - PGA (Program Global Area)
・Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ
・Temp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認
・Temp落ち #5 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版 （その前に少し脱線）
・Temp落ち #6 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版

Temp落ち #6 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版

Previously on Mac De Oracle
pga_aggregate_target scope=memory or bothでそれまでとはことなる動きとエラーは発生するところの話でした。

---

きょうは、自動PGA管理下ではどうなるか確認しておきます。
以前、簡単に確認した範囲結果から、これまでの仕様と大きな違いはないとみています。（変わっていないと思っていたのでブログでも書いていなかったのですが、"Temp落ち"ネタの準備運動も兼ね現状を確認しながら進めてみたいと思います）

まず環境情報から、
確認に利用するインスタンスのPGA以外のパラメータは以下の通りです。
（隠しパラメータは必要がある場合には適宜変更します。また、いくつかのパラメータは確認の都合上物理メモリーサイズ以上に設定することがあります。それらの変更が必要な場合には事前に解説する予定です。）

OS等の情報は以前のエントリーを参照のこと。

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
sga_max_size                         big integer 12G
sga_min_size                         big integer 0
sga_target                           big integer 12G

今回の主役である自動PGA管理のパラメータの初期設定は以下の通り（隠しパラメータを除く）
pga_aggregate_limit = 0 に設定し、pga_aggregate_targetの上限値制限を仕様上のサイズ4096GB - 1まで利用できるようにしておきます。（以前と同様の手順で確認するために、pga_aggregate_limitによる制限を無効化しています。なお、pga_aggregate_limitを0以外に設定して行う場合には、pga_aggregate_targetを4TB - 1まで設定することを考慮すると、pga_aggregate_limitは、8TB以上に設定する必要があります。）

orcl12c@SYS> show parameter pga_aggregate

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_limit                  big integer 0
pga_aggregate_target                 big integer 10M

上記設定からスタートして、pga_aggregate_targetを10MB/50MB/100MB/500MB/1GB/5GB/10GB/50GB/100GB/500GB/1T/4TB - 1と増加させながら、pgaサイズおよび、関連する隠しパラメータ(_pga_max_sizeや_smm_*など）がどのように変化するか、pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #8の手順で確認します。

昔のように実行ログをペタペタ貼っていると長くなるので、確認結果を表とグラフにしました。
想定通り以前と変わっていませんでした:)

デフォルト設定のままであれば、pga_aggregate_targetを限界値まで大きく増やしたとしても、10GB以降、個々のソート操作やハッシュ結合操作で利用できるPGAのSQL work areaサイズはv$pgastatのglobal memory boundの示す通り、1GB（シリアル実行時）が最大であることが確認できます。　えーーー。手動PGA管理より最大サイズ小さいじゃんと、今更驚かないようにしましょうねw （以前からそうなのですからw）
つまり、自動PGA管理の場合、特定の隠しパラメータを変更しない限り、1GBを超えるソート処理はやハッシュ結合操作は全て、"Temp落ち" する宿命にあるわけです。12cR2であっても。
え"〜〜〜〜〜っ！　と一応、驚いておきましょうw。　メモリーを沢山積んでるマシンは最近多いわけですが、このあたりはなぜか変わってません。

ちなみに、v$pgastatの示すglobal memory boundは、どこから？　という確認がしたくて、　_smm_max_sizeの変化と比較しているグラグも作成しておきました。
_smm_max_sizeパラメータはpga_aggregate_targetのサイズ変化に伴い変化する隠しパラメータですが、このパラメータがglobal memory boundの元になっているのは確からしいですね。

最後のグラフは、pga_aggregate_targetの値とv$pgastatのglobal memory boundの変化をまとめたグラフです。
global memory boundで示されるPGAのSQL Work Areaサイズの最大サイズには上限があることがわかります：）

次回は、自動PGA管理では、1GBを超えるソートやハッシュ結合はもれなく"Temp落ち"するのか確認してみることにします。

参考：このエントリーで利用したスクリプト
（今後の確認も兼ねてw このエントリーでネタにしている以外で関連しそうなパラメータも取得して変化を確認できるようにしてあります。）

orcl12c@SYS> !cat show_param.sql
set linesize 200
col ksppinm for a46
col ksppstvl for a30
col ksppstdf for a30
select
   a.ksppinm
  ,b.ksppstvl
  ,b.ksppstdf
from
  x$ksppi a join x$ksppcv b
  on a.indx = b.indx
where
  a.ksppinm in (
	'pga_aggregate_target'
	,'pga_aggregate_limit'
	,'_use_realfree_heap'
	,'_realfree_heap_pagesize'
  )
or a.ksppinm like '%\_smm%' escape '\'
or a.ksppinm like '%\_pga%' escape '\'
order by
  a.ksppinm
/

!echo /proc/sys/vm/max_map_count
!more /proc/sys/vm/max_map_count

orcl12c@SYS> !cat show_pgstat.sql
select
  name
 ,case
    when unit='bytes' then
      value/1024/1024
    else value
  end "VALUE"
 ,case
    when unit='bytes' then
      'MB'
    else unit
  end "UNIT"
 ,con_id
from
  v$pgastat
where
  name in (
    'aggregate PGA target parameter'
    ,'aggregate PGA auto target'
    ,'global memory bound'
    ,'total PGA used for auto workareas'
    ,'maximum PGA used for auto workareas'
    ,'total PGA used for manual workareas'
    ,'maximum PGA used for manual workareas'
  )  
;

orcl12c@SYS> !cat auto_workarea.sql
conn sys/oracle@orcl12c as sysdba
alter system set pga_aggregate_target=&1 scope=spfile
.
r
shutdown immediate
startup

prompt +++ initial parameters +++
@show_param

prompt +++ v$pgastat +++
@show_pgstatå

orcl12c@SYS> !cat doTest_auto_workarea.sql
prompt << 10m >>
@auto_workarea 10m

prompt << 50m >>
@auto_workarea 50m

prompt << 100m >>
@auto_workarea 100m

prompt << 500m >>
@auto_workarea 500m

prompt << 1g >>
@auto_workarea 1g

prompt << 5g >>
@auto_workarea 5g

prompt << 10g >>
@auto_workarea 10g

prompt << 50g >>
@auto_workarea 50g

prompt << 100g >>
@auto_workarea 100g

prompt << 500g >>
@auto_workarea 500g

prompt << 1t >>
@auto_workarea 1t

prompt << 4t - 1 >>
@auto_workarea 4398046511103

実行例

orcl12c@SYS> @doTest_auto_workarea.sql
<< 10m >>
Connected.
  1* alter system set pga_aggregate_target=&1 scope=spfile
old   1: alter system set pga_aggregate_target=&1 scope=spfile
new   1: alter system set pga_aggregate_target=10m scope=spfile

System altered.

Database closed.
Database dismounted.
ORACLE instance shut down.
ORACLE instance started.

Total System Global Area 1.2885E+10 bytes
Fixed Size                  8807168 bytes
Variable Size            1375735040 bytes
Database Buffers         5033164800 bytes
Redo Buffers               24743936 bytes
In-Memory Area           6442450944 bytes
Database mounted.
Database opened.
+++ initial parameters +++

KSPPINM                                        KSPPSTVL                       KSPPSTDF
---------------------------------------------- ------------------------------ ------------------------------
__pga_aggregate_target                         33554432                       FALSE

・・・略・・・

pga_aggregate_limit                            0                              FALSE
pga_aggregate_target                           10485760                       FALSE

50 rows selected.

/proc/sys/vm/max_map_count

65530

+++ v$pgastat +++

NAME                                                                  VALUE UNIT             CON_ID
---------------------------------------------------------------- ---------- ------------ ----------
aggregate PGA target parameter                                           10 MB                    0
aggregate PGA auto target                                                 4 MB                    0
global memory bound                                                       2 MB                    0
total PGA used for auto workareas                                .106445313 MB                    0
maximum PGA used for auto workareas                              .106445313 MB                    0
total PGA used for manual workareas                                       0 MB                    0
maximum PGA used for manual workareas                                     0 MB                    0

7 rows selected.

・・・略・・・

---

・Temp落ち #1 - "Temp落ち" って？
・Temp落ち #2 - PGA (Program Global Area)
・Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ
・Temp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認
・Temp落ち #5 - pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 12.2.0.1版 （その前に少し脱線）

Temp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認

---

Previously on Mac De Oracle
手動PGA管理で作業領域として指定可能な最大サイズは、2GB - 1までということの確認でした。
本当に、その程度のサイズまでPGAの作業領域が利用されるのでしょうか？。　念のために確認しておきましょう。 実は、それより少ないサイズで頭打ちなんてことは、ないかな〜　と　わざとらしく言ってみたりして（意味深w

その前に、指定した作業領域を使い切れるぐらい（つまり、Temp落ちさせられる程度）のデータ量の表を準備しておきます。
今回は、Nested Loop Join（NLJ)やソート回避などのための索引は作成しません。Temp落ちのネタなので。

M1とM2の2表を作成し、それぞれ、2.5GB程度のセグメントサイズにしておきます。 なお、以下の無名PL/SQLブロックでは、FORALLを利用して1000行単位でバルク処理しています。配列を利用するのでメモリー使用量にはそれなりに配慮が必要ですが。:)
単純なぐるぐる系INSERTにしてしまうとデータ量が多い場合、性能的に辛くなってしまうので、ここ重要！

ORCL@SCOTT> l
  1  CREATE TABLE m1
  2  (
  3  	id CHAR(7) NOT NULL
  4  	,rev# NUMBER NOT NULL
  5  	,value NUMBER NOT NULL
  6  	,description VARCHAR2(4000)
  7  	,additional_info CHAR(200)
  8* ) NOLOGGING
ORCL@SCOTT> /

Table created.

ORCL@SCOTT> l
  1  DECLARE
  2      TYPE IDS_t IS TABLE OF m1.id%TYPE INDEX BY PLS_INTEGER;
  3      TYPE REV#S_t IS TABLE OF m1.rev#%TYPE INDEX BY PLS_INTEGER;
  4      TYPE VALS_t IS TABLE OF m1.value%TYPE INDEX BY PLS_INTEGER;
  5      IDs IDS_t;
  6      REV#s REV#S_t;
  7      VALs VALS_t;
  8      k PLS_INTEGER := 1;
  9  BEGIN
 10      FOR i IN 1..100000 LOOP
 11          FOR j IN 1..10 LOOP
 12              IDs(k) := 'C' || TO_CHAR(i, 'FM000000');
 13              REV#s(k) := j;
 14              VALs(k) := i + j;
 15              k := k + 1;
 16          END LOOP;
 17          IF MOD(i, 100) = 0 THEN
 18              FORALL l in 1..1000 EXECUTE IMMEDIATE
 19                  'INSERT /*+ APPEND_VALUE NO_GATHER_OPTIMIZER_STATISTICS */ INTO m1 '
 20                   || 'VALUES(:1, :2, :3,  LPAD(''X'',2000, ''X''), LPAD(''9'',200,''9''))'
 21                   USING IDs(l), REV#s(l), VALs(l);
 22              COMMIT;
 23              k := 1;
 24          END IF;
 25      END LOOP;
 26* END;
ORCL@SCOTT> /

PL/SQL procedure successfully completed.

Elapsed: 00:01:22.45
ORCL@SCOTT> select count(1) from m1;

  COUNT(1)
----------
   1000000

ORCL@SCOTT> select segment_name,sum(bytes)/1024/1024/1024 "GB" from user_segments where segment_name='M1' group by segment_name;

SEGMENT_NAME                           GB
------------------------------ ----------
M1                                 2.5625

ORCL@SCOTT> l
  1  CREATE TABLE m2
  2  (
  3  	id CHAR(7) NOT NULL
  4  	,rev# NUMBER NOT NULL
  5  	,value NUMBER NOT NULL
  6  	,description VARCHAR2(4000)
  7* ) NOLOGGING
ORCL@SCOTT> /

Table created.

ORCL@SCOTT> l
  1  INSERT /*+ APPEND NO_GATHER_OPTIMIZER_STATISTICS */ INTO m2
  2* SELECT id,rev#,value,description FROM m1
ORCL@SCOTT> /

1000000 rows created.

Elapsed: 00:00:40.22
ORCL@SCOTT> commit;

Commit complete.

ORCL@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'M1',no_invalidate=>false,method_opt=>'FOR ALL COLUMNS SIZE SKEWONLY');

PL/SQL procedure successfully completed.

ORCL@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'M2',no_invalidate=>false,method_opt=>'FOR ALL COLUMNS SIZE SKEWONLY');

PL/SQL procedure successfully completed.

これで、準備完了。
ちなみに、NO_GATHER_OPTIMIZER_STATISTICSヒントを利用していますが、データ登録後に、ヒストグラムも含めて取得したかったため、バルクロード時のオンラインオプティマイザ統計収集を行わないようにするためのヒントです。
データ登録後オプティマイザ統計を取得するため、データ登録時のオンラインオプティマイザ統計のオーバーヘッドは無駄となるためです。利用できるなら利用したほうがよいとは思いますが、制限もあるのでご一読を（バルク・ロードのためのオンライン統計収集）

---

手動PGA管理で2GB - 1（手動PGA管理での最大 Sort作業領域サイズ）

メモリーソートで2GBぐらいまで利用していることが確認できます。（ソートされるデータ量が2GB以下程度に制限しています。）

ORCL@SCOTT> @manual_sortwk2gb_optimal    
  1* alter session set workarea_size_policy=manual

Session altered.

  1* alter session set sort_area_size = 2147483647

Session altered.

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C075000'
 10  ORDER BY
 11      id
 12*     ,rev#
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
=================================================
| Elapsed |   Cpu   |  Other   | Fetch | Buffer |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  |
=================================================
|    5.42 |    4.13 |     1.29 | 50001 |   334K |
=================================================

SQL Plan Monitoring Details (Plan Hash Value=3534657201)
===================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   |  Mem  | Activity | Activity Detail |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | (Max) |   (%)    |   (# samples)   |
===================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        15 |     +2 |     1 |     750K |     . |    20.00 | Cpu (1)         |
|  1 |   SORT ORDER BY      |      |    752K |  439K |        16 |     +1 |     1 |     750K |   2GB |    60.00 | Cpu (3)         |
|  2 |    TABLE ACCESS FULL | M1   |    752K | 90828 |         3 |     +2 |     1 |     750K |     . |    20.00 | Cpu (1)         |
===================================================================================================================================

Temp落ちする程度のデータ量でソートさせた場合も、PGAの作業領域は一旦、2GBまで利用されていることが確認できます。

ORCL@SCOTT> @manual_sortwk2gb
  1* alter session set workarea_size_policy=manual

Session altered.

  1* alter session set sort_area_size = 2147483647

Session altered.

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  ORDER BY
  9      id
 10*     ,rev#
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
-------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
===========================================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes | Reqs  | Bytes |
===========================================================================================
|      46 |      11 |       15 |       20 | 66668 |   334K | 2148 |   2GB |  2146 |   2GB |
===========================================================================================

SQL Plan Monitoring Details (Plan Hash Value=3534657201)
=====================================================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |      Activity Detail       |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |        (# samples)         |
=====================================================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        60 |     +2 |     1 |       1M |      |       |       |       |     . |     . |     6.38 | Cpu (2)                    |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | PGA memory operation (1)   |
|  1 |   SORT ORDER BY      |      |      1M |  553K |        61 |     +1 |     1 |       1M | 2148 |   2GB |  2146 |   2GB |   2GB |   2GB |    91.49 | Cpu (32)                   |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read temp (10) |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path write temp (1) |
|  2 |    TABLE ACCESS FULL | M1   |      1M | 90822 |        27 |     +2 |     1 |       1M |      |       |       |       |     . |     . |     2.13 | Cpu (1)                    |
=====================================================================================================================================================================================

手動PGA管理で2GB - 1（手動PGA管理での最大 Hash作業領域サイズ） Hash Joinの場合も、手動PGA管理で設定可能な最大サイズ程度まで利用されていることが確認できます。（Temp落ちしない程度のデータ量にしています。）

ORCL@SCOTT> @manual_hashwk2gb_optimal
  1* alter session set workarea_size_policy = manual

Session altered.

  1* alter session set hash_area_size = 2147483647

Session altered.

  1  SELECT
  2      /*+
  3          MONITOR
  4          LEADING(m1 m2)
  5          USE_HASH(m2)
  6      */
  7      *
  8  FROM
  9      m1
 10      INNER JOIN m2
 11      ON
 12          m1.id = m2.id
 13          AND m1.rev# = m2.rev#
 14  WHERE
 15*     m1.id <= 'C075000'
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
===========================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
===========================================================================
|    8.05 |    4.66 |     0.16 |     3.23 | 50001 |   717K | 2618 |   3GB |
===========================================================================

SQL Plan Monitoring Details (Plan Hash Value=1822065247)
==================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity | Activity Detail |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |   (# samples)   |
==================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        21 |     +2 |     1 |     750K |      |       |     . |    12.50 | Cpu (1)         |
|  1 |   HASH JOIN          |      |    752K |  181K |        22 |     +1 |     1 |     750K |      |       |   2GB |    25.00 | Cpu (2)         |
|  2 |    TABLE ACCESS FULL | M1   |    752K | 90828 |         2 |     +2 |     1 |     750K |      |       |     . |    25.00 | Cpu (2)         |
|  3 |    TABLE ACCESS FULL | M2   |    759K | 90581 |        20 |     +3 |     1 |     750K | 2618 |   3GB |     . |    37.50 | Cpu (3)         |
==================================================================================================================================================

Hash Joinの場合もSort時と同じように、一時表領域も利用させる程度のデータ量になると、一旦、手動PGA管理で設定可能な最大サイズ程度まで利用したうえでTemp落ちしていることが確認できます。

ORCL@SCOTT> @manual_hashwk2gb
  1* alter session set workarea_size_policy = manual

Session altered.

  1* alter session set hash_area_size = 2147483647

Session altered.

  1  SELECT
  2      /*+
  3          MONITOR
  4          LEADING(m1 m2)
  5          USE_HASH(m2)
  6      */
  7      *
  8  FROM
  9      m1
 10      INNER JOIN m2
 11      ON
 12          m1.id = m2.id
 13*         AND m1.rev# = m2.rev#
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
===========================================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes | Reqs  | Bytes |
===========================================================================================
|      12 |    5.68 |     2.17 |     4.59 | 66668 |   706K | 3133 |   3GB |   515 | 511MB |
===========================================================================================

SQL Plan Monitoring Details (Plan Hash Value=1822065247)
=====================================================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |      Activity Detail       |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |        (# samples)         |
=====================================================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        30 |     +2 |     1 |       1M |      |       |       |       |     . |     . |    25.00 | Cpu (4)                    |
|  1 |   HASH JOIN          |      |      1M |  189K |        31 |     +1 |     1 |       1M |  515 | 511MB |   515 | 511MB |   2GB | 515MB |    43.75 | Cpu (5)                    |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read temp (1)  |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path write temp (1) |
|  2 |    TABLE ACCESS FULL | M1   |      1M | 90822 |         6 |     +0 |     1 |       1M |      |       |       |       |     . |     . |    12.50 | Cpu (2)                    |
|  3 |    TABLE ACCESS FULL | M2   |      1M | 90574 |        24 |     +5 |     1 |       1M | 2618 |   3GB |       |       |     . |     . |    18.75 | Cpu (2)                    |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read (1)       |
=====================================================================================================================================================================================

おまけ 1つのSQLの実行で利用されるPGAの作業領域は1つだけではないということも確認しておきましょうかね。（知ってる方はスルーしてよいですよ：）
以下の例では、MERGE JOINさせていますが、表M1と表M2それぞれのSort作業領域は、Merge Join終了時まで保持されることになるため、最大3GBのSort作業領域が利用されています。（SQLモニターの結果ではわかりにくいのですが。。。）
なお、手動PGA管理、自動PGA管理に関係なく、実行される操作により複数の作業領域が同時に確保されることがあります。
（ちなみに、自動PGA管理で利用されるPGA_AGGREGATE_LIMITがPGA_AGGREGATE_TARGETの2倍とされるのも、このような動きが考慮された結果だと知っていると、納得感はあるかもしれません。）

前回使った図で朱色で示したSQL Work Areaが複数ありますが、Hash/Sort/Bitmap系など複数のタイプおよび同一タイプの作業領域が同時に確保されることも意図した図になっているのは、これが理由なんです。

ORCL@SCOTT> @manual_sortwk2gb2_optimal
  1* alter session set workarea_size_policy = manual

Session altered.

  1* alter session set sort_area_size = 2147483647

Session altered.

  1  SELECT
  2      /*+
  3          MONITOR
  4          USE_MERGE(m1 m2)
  5      */
  6      *
  7  FROM
  8      m1
  9      INNER JOIN m2
 10      ON
 11          m1.id = m2.id
 12          AND m1.rev# = m2.rev#
 13  WHERE
 14*     m1.id <= 'C075000'
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_ID=>'',TYPE=>'TEXT')
-------------------------------------------------------------------------------------------
SQL Monitoring Report

・・・中略・・・

Global Stats
===========================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
===========================================================================
|      17 |      10 |     4.75 |     2.19 | 50001 |   667K | 5251 |   5GB |
===========================================================================

SQL Plan Monitoring Details (Plan Hash Value=1391069689)
========================================================================================================================================================
| Id |       Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity |   Activity Detail    |
|    |                       |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |     (# samples)      |
========================================================================================================================================================
|  0 | SELECT STATEMENT      |      |         |       |        23 |    +10 |     1 |     750K |      |       |     . |    14.29 | Cpu (2)              |
|  1 |   MERGE JOIN          |      |    752K |  849K |        23 |    +10 |     1 |     750K |      |       |     . |          |                      |
|  2 |    SORT JOIN          |      |    752K |  439K |        32 |     +1 |     1 |     750K |      |       |   2GB |    21.43 | Cpu (3)              |
|  3 |     TABLE ACCESS FULL | M1   |    752K | 90828 |         8 |     +2 |     1 |     750K | 2633 |   3GB |     . |    35.71 | Cpu (3)              |
|    |                       |      |         |       |           |        |       |          |      |       |       |          | direct path read (2) |
|  4 |    SORT JOIN          |      |    759K |  410K |        23 |    +10 |  750K |     750K |      |       |   1GB |    14.29 | Cpu (2)              |
|  5 |     TABLE ACCESS FULL | M2   |    759K | 90581 |         5 |    +10 |     1 |     750K | 2618 |   3GB |     . |    14.29 | Cpu (2)              |
========================================================================================================================================================

SQLモニターの結果ではわかりにくいわけですが、v$sesstatをから眺めれば状況がよくわかります！
2つのソート作業領域が同時に確保されたことで、2GB + 1GB = 3GB程度のサイズにまで達していることが確認できます。

ORCL@SYSTEM> r
  1  select
  2  	vss.value/1024/1024/1024 "GB"
  3  	,vsn.name
  4  	,vss.sid
  5  from
  6  	v$sesstat vss
  7  	inner join v$statname vsn
  8  	on
  9  		vss.statistic# = vsn.statistic#
 10  		and vss.con_id = vsn.con_id
 11  		and vsn.name like '%pga%'
 12  where
 13  	sid IN (select sid from v$session where username='SCOTT')
 14  order by
 15* 	sid,name

        GB NAME                                                                    SID
---------- ---------------------------------------------------------------- ----------
3.04611414 session pga memory                                                      203
3.04611414 session pga memory max                                                  203

では、次回はやっとw、真打、自動PGA管理下での確認。（引っ張り過ぎかもしれないw）
つづく。

---

・Temp落ち #1 - "Temp落ち" って？
・Temp落ち #2 - PGA (Program Global Area)
・Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ

Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ

自動PGA管理は12cでどうなんだっけ？という確認の前に、
いままで何度か質問されたことがあり、FAQだと思っているので

手動PGA管理で利用する以下パラメータの最大サイズはいくつ？　

HASH_AREA_SIZE
SORT_AREA_SIZE
BITMAP_MERGE_AREA_SIZE
CREATE_BITMAP_AREA_SIZE

ということを書いておきたいと思います。

これからしばらく続く　Temp落ち　ネタで利用する環境で固定部分は以下のとおり
（初期化パラメータ等は必要に応じて載せるつもりです。）

環境は以下のとおり。
host osとguest osのバージョンやメモリーサイズなど

discus:˜ oracle$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.13.3
BuildVersion:	17D47

discus:˜ oracle$ system_profiler SPHardwareDataType | grep -E 'Processor Name|Cores|Memory'
      Processor Name: 6-Core Intel Xeon
      Total Number of Cores: 12
      Memory: 32 GB

discus:˜ oracle$ VBoxManage -v
5.2.6r120293

discus:˜ oracle$ VBoxManage showvminfo e3d4f948-b2e6-4db3-a89d-df637d87a372 | grep -E 'Memory size|OS type|Number of CPUs'
Memory size:     23569MB
Number of CPUs:  12
OS type:                             Linux26_64


orcl12c@SYS> select * from v$version;

BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production              0
PL/SQL Release 12.2.0.1.0 - Production                                                    0
CORE    12.2.0.1.0	Production                                                            0
TNS for Linux: Version 12.2.0.1.0 - Production                                            0
NLSRTL Version 12.2.0.1.0 - Production                                                    0


orcl12c@SYS> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 ORCL                           READ WRITE NO

さて、今日の本題

手動PGA管理で各SQL Work Area Sizeを決定する以下の初期化パラメータの最大サイズは？　いくつでしょう？　
すでにご存知のかたはスキップしていいですよ:)

マニュアルを読んでみるときづくのですが、手動PGA管理で各SQL Work Area Sizeを決定する4パラメータとも、「０以上、上限はOS依存」のような記述になっています。

そう、マニュアルを読んだだけではまったく参考にならないわけです。（え〜〜っ！）

そこで、みなさんサポートを頼るなり、ご自分でMOSを検索するなり、そこそこの苦労をして入手することになります。
私みたいな性格だと、どのマニュアルでもいいからまとめて載せてよーめんどくさいから。と、めんどくさい病の発作がでたりしますw

なので、環境があるのなら、you 試しちゃいなよー。が手っ取り早いかなーと（最終的にMOSとかサポートを頼るにしてもw）

上限はOS依存とだけしか記載されていませんが、私の観測範囲では、2GB - 1 が上限 となっています。
以下、Linux/Solaris/Windowsでの検証ログ。

Oracle® Databaseリファレンス　12cリリース2 (12.2) E72905-03より

HASH_AREA_SIZE
https://docs.oracle.com/cd/E82638_01/REFRN/HASH_AREA_SIZE.htm

SORT_AREA_SIZE
https://docs.oracle.com/cd/E82638_01/REFRN/SORT_AREA_SIZE.htm

BITMAP_MERGE_AREA_SIZE
https://docs.oracle.com/cd/E82638_01/REFRN/BITMAP_MERGE_AREA_SIZE.htm

CREATE_BITMAP_AREA_SIZE
https://docs.oracle.com/cd/E82638_01/REFRN/CREATE_BITMAP_AREA_SIZE.htm

Linux

orcl12c@SYS> !uname -r; cat /etc/redhat-release /etc/oracle-release
4.1.12-94.3.6.el7uek.x86_64
Red Hat Enterprise Linux Server release 7.3 (Maipo)
Oracle Linux Server release 7.3

orcl12c@SYS> create pfile from spfile;

File created.

orcl12c@SYS> --2GB  
orcl12c@SYS> select 2*1024*1024*1024 from dual;

2*1024*1024*1024
----------------
      2147483648

orcl12c@SYS> alter system set hash_area_size = 2147483648 scope=spfile;
alter system set hash_area_size = 2147483648 scope=spfile
                                  *
ERROR at line 1:
ORA-02017: integer value required

orcl12c@SYS> alter system set sort_area_size = 2147483648 scope=spfile;
alter system set sort_area_size = 2147483648 scope=spfile
                                  *
ERROR at line 1:
ORA-02017: integer value required

orcl12c@SYS> alter system set bitmap_merge_area_size = 2147483648 scope=spfile;
alter system set bitmap_merge_area_size = 2147483648 scope=spfile
                                          *
ERROR at line 1:
ORA-02017: integer value required

orcl12c@SYS> alter system set create_bitmap_area_size = 2147483648 scope=spfile;
alter system set create_bitmap_area_size = 2147483648 scope=spfile
                                           *
ERROR at line 1:
ORA-02017: integer value required

orcl12c@SYS> --2GB - 1
orcl12c@SYS> select 2*1024*1024*1024-1 from dual;

2*1024*1024*1024-1
------------------
        2147483647

orcl12c@SYS> alter system set hash_area_size = 2147483647 scope=spfile;

System altered.

orcl12c@SYS> alter system set sort_area_size = 2147483647 scope=spfile;

System altered.

orcl12c@SYS> alter system set bitmap_merge_area_size = 2147483647 scope=spfile;

System altered.

orcl12c@SYS> alter system set create_bitmap_area_size = 2147483647 scope=spfile;

System altered.

orcl12c@SYS> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
orcl12c@SYS> create spfile from pfile;

File created.

orcl12c@SYS>

Solaris 11 (x86)

SQL> !uname -r; cat /etc/release
5.11
                             Oracle Solaris 11.3 X86
  Copyright (c) 1983, 2015, Oracle and/or its affiliates.  All rights reserved.
                            Assembled 06 October 2015

SQL> 
SQL> create pfile from spfile;

ファイルが作成されました。

SQL> --2GB
SQL> select 2*1024*1024*1024 from dual;

2*1024*1024*1024
----------------
      2147483648

SQL> alter system set hash_area_size = 2147483648 scope=spfile;
alter system set hash_area_size = 2147483648 scope=spfile
                                  *
行1でエラーが発生しました。:
ORA-02017: 整数値が必要です。


SQL> alter system set sort_area_size = 2147483648 scope=spfile;
alter system set sort_area_size = 2147483648 scope=spfile
                                  *
行1でエラーが発生しました。:
ORA-02017: 整数値が必要です。


SQL> alter system set bitmap_merge_area_size = 2147483648 scope=spfile;
alter system set bitmap_merge_area_size = 2147483648 scope=spfile
                                          *
行1でエラーが発生しました。:
ORA-02017: 整数値が必要です。


SQL> alter system set create_bitmap_area_size = 2147483648 scope=spfile;
alter system set create_bitmap_area_size = 2147483648 scope=spfile
                                           *
行1でエラーが発生しました。:
ORA-02017: 整数値が必要です。


SQL> --2GB - 1
SQL> select 2*1024*1024*1024-1 from dual;

2*1024*1024*1024-1
------------------
	2147483647

SQL> alter system set hash_area_size = 2147483647 scope=spfile;

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

SQL> alter system set sort_area_size = 2147483647 scope=spfile;

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

SQL> alter system set bitmap_merge_area_size = 2147483647 scope=spfile;

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

SQL> alter system set create_bitmap_area_size = 2147483647 scope=spfile;

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

SQL> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
ERROR:
ORA-12514: TNS:
リスナーは接続記述子でリクエストされたサービスを現在認識していません


警告: Oracleにはもう接続されていません。
SQL> conn sys/oracle@orcl122 as sysdba
ERROR:
ORA-12514: TNS:
リスナーは接続記述子でリクエストされたサービスを現在認識していません


SQL> exit
bash-4.1$ export ORACLE_SID=orcl122
bash-4.1$ sqlplus / as sysdba

SQL*Plus: Release 12.2.0.1.0 Production on 月 2月 19 22:44:47 2018

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

アイドル・インスタンスに接続しました。

SQL> startup
ORACLEインスタンスが起動しました。

Total System Global Area  838860800 bytes
Fixed Size		    8790120 bytes
Variable Size		  356519832 bytes
Database Buffers	  465567744 bytes
Redo Buffers		    7983104 bytes
データベースがマウントされました。
データベースがオープンされました。
SQL> show parameter _area_size

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
bitmap_merge_area_size               integer     2147483647
create_bitmap_area_size              integer     2147483647
hash_area_size                       integer     2147483647
sort_area_size                       integer     2147483647
workarea_size_policy                 string      AUTO
SQL> 
SQL> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SQL> 
SQL> create spfile from pfile;

File created.

Microsoft Windows

Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
に接続されました。
SQL>
SQL> $ver

Microsoft Windows [Version 10.0.16299.125]

SQL> create pfile from spfile;

ファイルが作成されました。

SQL> --2GB
SQL> select 2*1024*1024*1024 from dual;

2*1024*1024*1024
----------------
      2147483648

SQL> alter system set hash_area_size = 2147483648 scope=spfile;
alter system set hash_area_size = 2147483648 scope=spfile
                                  *
行1でエラーが発生しました。:
ORA-02017: 整数値が必要です。

SQL> alter system set sort_area_size = 2147483648 scope=spfile;
alter system set sort_area_size = 2147483648 scope=spfile
                                  *
行1でエラーが発生しました。:
ORA-02017: 整数値が必要です。

SQL> alter system set bitmap_merge_area_size = 2147483648 scope=spfile;
alter system set bitmap_merge_area_size = 2147483648 scope=spfile
                                          *
行1でエラーが発生しました。:
ORA-02017: 整数値が必要です。

SQL> alter system set create_bitmap_area_size = 2147483648 scope=spfile;
alter system set create_bitmap_area_size = 2147483648 scope=spfile
                                           *
行1でエラーが発生しました。:
ORA-02017: 整数値が必要です。


SQL> --2GB - 1
SQL> select 2*1024*1024*1024-1 from dual;

2*1024*1024*1024-1
------------------
        2147483647

SQL> alter system set hash_area_size = 2147483647 scope=spfile;

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

SQL> alter system set sort_area_size = 2147483647 scope=spfile;

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

SQL> alter system set bitmap_merge_area_size = 2147483647 scope=spfile;

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

SQL> alter system set create_bitmap_area_size = 2147483647 scope=spfile;

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

SQL> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
ERROR:ORA-12514: TNSリスナーは接続記述子でリクエストされたサービスを現在認識していません
SQL> 警告: Oracleにはもう接続されていません。
SQL> exit
Disconnected
C:\Users\discus>set ORACLE_SID=orcl122SQL> 
C:\Users\discus>sqlplus / as sysdba
SQL*Plus: Release 12.2.0.1.0 Production on 月 2月 19 22:28:45 2018
Copyright (c) 1982, 2016, Oracle.  All rights reserved.
SQL> 
アイドル・インスタンスに接続しました。
SQL> create spfile from pfile;
SQL> 
File created.
SQL> exit
Disconnected

C:\Users\discus>

ということで、

手動PGA管理でSQL Work Area Sizeを制御する初期化パラメータで指定可能な最大サイズは

2GB -1

ということになります。(HP-UXやAIXは未確認なので情報いただけたら、ここに追記しまーす。:)

次回へつづく。

---

・Temp落ち #1 - "Temp落ち" って？
・Temp落ち #2 - PGA (Program Global Area)

Temp落ち #2 - PGA (Program Global Area)

Previously on Mac De Oracle
”Temp落ち”ってなに？　
という話と、それを確認できるツールをいくつか紹介したところまででした。

---

余談

このネタを書きながら、"Temp落ち"とは異なる理由で今回ネタにするメモリー領域の事を調べていた事を思い出しました。（懐かしい）

当時、自動PGA管理に関する情報があまりなく、新・ソートに関する検証　その１　ペンネーム　グリーンペペを隅から隅まで読み試していました：)。その何年か後に、グリーンペペさんが、だれなのかを知ることに。。業界狭いですw

むか〜し、Windows(32bit)環境のOracleで、」ORA-12518が頻発していたトラブルの原因は今回のネタで取り上げるメモリー領域だった！なんてこともあるので、構造等、知ってて損はないですよ:)

---

では、今回のお話。

"Hash JoinやSortなどの処理をできる限りメモリー上で行う"という、そのメモリー領域とは？？？
PGA (Program Global Area)と呼ばれるメモリー領域のSQL Work Areaに確保されます。
また、それらのサイズを制御する初期化パラメータがあります。（後述）
PGAは、おおよそ以下のような構造で、サーバープロセスやバックグランドプロセス毎に確保されます。”ここ大切"

---

参考)
PGAのメモリーサイズを制御するパラメータは、以下の通り（隠しパラメータもありますが、とりあえずデフォルト前提で：）

以下の4パラメータは、手動PGA管理で利用されるパラメータで、自動PGA管理が主流となった今ではあまり利用されることはありません。（たま〜〜に使いたくなるときはありますが、結局使わなかったり、それは別の機会にでも書くことにします）

HASH_AREA_SIZE
https://docs.oracle.com/cd/E82638_01/REFRN/HASH_AREA_SIZE.htm

SORT_AREA_SIZE
https://docs.oracle.com/cd/E82638_01/REFRN/SORT_AREA_SIZE.htm

BITMAP_MERGE_AREA_SIZE
https://docs.oracle.com/cd/E82638_01/REFRN/BITMAP_MERGE_AREA_SIZE.htm

CREATE_BITMAP_AREA_SIZE
https://docs.oracle.com/cd/E82638_01/REFRN/CREATE_BITMAP_AREA_SIZE.htm

Oracle database 9.2.0以降、自動PGA管理が登場し、上記4パラメータで個別にサイズを管理する必要がなくなりました。
PGA_AGGREGATE_TARGET/PGA_AGGREATE_LIMITの２つのパラメータで自動PGA管理で行う方法に慣れておいた方が良いと思います。

余談
ちなみに、10gR1〜11gR2までは、PGA_AGGREGATE_TARGETパラメータだけだったのですが、その頃、自動PGA管理で割り当てられるサイズを検証していたネタは以下:) pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #8 https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2010/09/pga_aggregate-7.html

ところで、ひさびさに以下マニュアルを読んで見たのですが、何度見てもモヤモヤは消えない感じのままなのがつらいです。もう少しなんとかならんかなー。
と思わなくもないです...w 作業領域の割り当てルールを明記しないのは、何故なんだろうと、ズーーーーっと考えてる。書いてくれてれば楽なのにな〜と。

Oracle® Databaseパフォーマンス・チューニング・ガイド 12cリリース2 (12.2) E72901-03
16 プログラム・グローバル領域のチューニング
https://docs.oracle.com/cd/E82638_01/TGDBA/tuning-program-global-area.htm

Oracle® Databaseリファレンス 12cリリース2 (12.2) E72905-03
PGA_AGGREGATE_LIMIT
https://docs.oracle.com/cd/E82638_01/REFRN/PGA_AGGREGATE_LIMIT.htm

12.2からResource Managerを利用して特定のコンシューマ・グループ内の各セッションに割り当てられるようになったようで、 PGAメモリー使用量に絶対制限を設定し、超過した場合にはORA-10260エラーとさせることができるようになったようですね。（まだ試したことはないのですが）

16.3.2 リソース・マネージャを使用したプログラム・グローバル領域のサイズ設定
https://docs.oracle.com/cd/E82638_01/TGDBA/tuning-program-global-area.htm

PGA_AGGREGATE_TARGET
https://docs.oracle.com/cd/E82638_01/REFRN/PGA_AGGREGATE_TARGET.htm

12cの自動PGA管理について軽く確認した感触だと、12cR2でPDB毎の制御ができるようになった事以外、大きな変化ないんじゃないかと思っているのですが、そういえばちゃんと確認したことないな。。。
次回は、昔試した方法で、12cでもPGA割り当てルールに変化はないのか確認しておきますか。。。18cはどうなるんだろ:)

続く。

---

・Temp落ち #1 - "Temp落ち" って？

”utl_file I/O” - この症状はあれの可能性が高いですね。

JPOUG Advent Calendar 2017の4日目のエントリーです。

さて、最近あまりお目にかかってなかったUTL_FILEパッケージで表データをcsvに書きだすネタにしました。

先日、UTL_FILEパッケージを利用した処理が想定以上に遅いという相談をうけました。
AWRレポートをみると、上位の待機イベントは、”utl_file I/O"。

！！！！おーーーこれは、珍しいというか、久々にみた病気w

UTL_FILEパッケージを利用したI/Oをグルグルしているとか、でかいファイル読み書きしているかの、どちらかですよねw
ということで、この症状の治療法を考えてみます。

＜参考 - 環境＞

MacBook:˜ system_profiler SPHardwareDataType | grep -E 'Model|Processor|Cores|Memory'
      Model Name: MacBook
      Model Identifier: MacBook9,1
      Processor Name: Intel Core m5
      Processor Speed: 1.2 GHz
      Number of Processors: 1
      Total Number of Cores: 2
      Memory: 8 GB

ホストOS
MacBook:˜ discus$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.13.1
BuildVersion:	17B1003

MacBook:˜ discus$ VBoxManage -version
5.1.30r118389


ゲストOSとOracle Database
orcl@SYS> !uname -a
Linux localhost.localdomain 4.1.12-94.3.6.el7uek.x86_64 #2 SMP Tue May 30 19:25:15 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux

orcl@SYS> !cat /etc/oracle-release
Oracle Linux Server release 7.3

orcl@SYS> 
orcl@SYS> select * from v$version;

BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production              0
PL/SQL Release 12.2.0.1.0 - Production                                                    0
CORE	12.2.0.1.0	Production                                                            0
TNS for Linux: Version 12.2.0.1.0 - Production                                            0
NLSRTL Version 12.2.0.1.0 - Production                                                    0

UTL_FILEでファイル出力する際、ちょっとした手順の漏れが性能差として現れてしまうことがあります。
表の行長は数百バイト程度ですが、行数は数千万〜数億行なんていう状況だと、性能差が顕著に現れてしまうので注意が必要です。

以下の表、セグメントサイズは1GB程度ですが、行数は1千万行以上あります。
この表データをUTL_FILEパッケージを利用してcsvに出力してみます。

ORCL@SCOTT> select segment_name,sum(bytes)/1024/1024/1024 "GB" from user_segments group by segment_name;

SEGMENT_NAME                           GB
------------------------------ ----------
ABOUT_100BYTES_ROWS              .9140625
PK_ABOUT_100BYTES_ROWS            .171875


ORCL@SCOTT> select count(1) from about_100bytes_rows;

  COUNT(1)
----------
  10737420

表の1行は100bytes(改行コード含）です。

ORCL@SCOTT%gt; r
  1  SELECT
  2  	LENGTH(
  3  		TO_CHAR(id,'FM000000000000000000000000000009')
  4  		||','||FOO
  5  	) row_length
  6  FROM
  7  	about_100bytes_rows
  8  WHERE
  9* 	rownum <= 1

ROW_LENGTH
----------
        99

次の2つのコードの赤太文字部分に着目してください。
その部分が異なるだけで処理時間に大きな差が出ます。

DECLARE
	cDIR_NAME CONSTANT VARCHAR2(30) := 'FILES_DIR';
	cFILE_NAME CONSTANT VARCHAR2(128) := 'no_writebuffering_'||TO_CHAR(systimestamp, 'rrmmddhh24miss.ff')||'.txt';
	cBufferSize CONSTANT BINARY_INTEGER := 32767;
	cOpenMode CONSTANT VARCHAR2(2) := 'w';
	fileHandle UTL_FILE.FILE_TYPE;
	
	cBulkReadLimit CONSTANT PLS_INTEGER := 324;
	TYPE tBulkReadArray IS TABLE OF VARCHAR2(8192) INDEX BY BINARY_INTEGER;
	bulkReadArray tBulkReadArray;
	CURSOR cur_about100bytesRow IS
		SELECT
			TO_CHAR(id,'FM000000000000000000000000000009')
			||','||FOO
			AS csvrow
		FROM
			about_100bytes_rows
		;
BEGIN
	OPEN cur_about100bytesRow;
	fileHandle := UTL_FILE.FOPEN(cDIR_NAME, cFILE_NAME, cOpenMode, cBufferSize);
	LOOP
		FETCH cur_about100bytesRow
			BULK COLLECT INTO bulkReadArray
			LIMIT cBulkReadLimit;
		
		EXIT WHEN bulkReadArray.COUNT = 0;
		
		FOR i IN bulkReadArray.FIRST..bulkReadArray.LAST LOOP
			UTL_FILE.PUT_LINE(
				file => fileHandle
				, buffer => bulkReadArray(i)
				, autoflush => true
			);
		END LOOP;
	END LOOP;
	UTL_FILE.FFLUSH(fileHandle);
	UTL_FILE.FCLOSE(fileHandle);
	CLOSE cur_about100bytesRow;
EXCEPTION
	WHEN OTHERS THEN
		IF UTL_FILE.IS_OPEN(fileHandle) THEN
			UTL_FILE.FCLOSE(fileHandle);
		END IF;
		
		IF cur_about100bytesRow%ISOPEN THEN
			CLOSE cur_about100bytesRow;
		END IF;
		RAISE;
END;
/


PL/SQLプロシージャが正常に完了しました。

経過: 00:02:27.05

DECLARE
	cDIR_NAME CONSTANT VARCHAR2(30) := 'FILES_DIR';
	cFILE_NAME CONSTANT VARCHAR2(128) := 'writebuffering_'||TO_CHAR(systimestamp, 'rrmmddhh24miss.ff')||'.txt';
	cBufferSize CONSTANT BINARY_INTEGER := 32767;
	cOpenMode CONSTANT VARCHAR2(2) := 'w';
	fileHandle UTL_FILE.FILE_TYPE;
	buffer VARCHAR2(32767);
	
	cBulkReadLimit CONSTANT PLS_INTEGER := 324;
	TYPE tBulkReadArray IS TABLE OF VARCHAR2(8192) INDEX BY BINARY_INTEGER;
	bulkReadArray tBulkReadArray;
	CURSOR cur_about100bytesRow IS
		SELECT
			TO_CHAR(id,'FM000000000000000000000000000009')
			||','||FOO
			AS csvrow
		FROM
			about_100bytes_rows
		;
BEGIN
	OPEN cur_about100bytesRow;
	fileHandle := UTL_FILE.FOPEN(cDIR_NAME, cFILE_NAME, cOpenMode, cBufferSize);
	LOOP
		FETCH cur_about100bytesRow
			BULK COLLECT INTO bulkReadArray
			LIMIT cBulkReadLimit;
		
		EXIT WHEN bulkReadArray.COUNT = 0;
	
		buffer := NULL;	
		FOR i IN bulkReadArray.FIRST..bulkReadArray.LAST LOOP
			buffer := buffer || bulkReadArray(i) || UTL_TCP.CRLF;   
 		END LOOP;
		UTL_FILE.PUT(fileHandle, buffer);
		UTL_FILE.FFLUSH(fileHandle);
	END LOOP;
	UTL_FILE.FFLUSH(fileHandle);
	UTL_FILE.FCLOSE(fileHandle);
	CLOSE cur_about100bytesRow;
EXCEPTION
	WHEN OTHERS THEN
		IF UTL_FILE.IS_OPEN(fileHandle) THEN
			UTL_FILE.FCLOSE(fileHandle);
		END IF;
		
		IF cur_about100bytesRow%ISOPEN THEN
			CLOSE cur_about100bytesRow;
		END IF;
		RAISE;
END;
/


PL/SQLプロシージャが正常に完了しました。

経過: 00:00:43.96

何が違うかお分ですよね！
UTL_FILE.PUT_LINE/UTL_FILE.PUTが違う！！w
その部分は重要ではなく、100Bytes単位に書き込んでいるか、約32KB単位で書き込んでいるかが重要なんです。

UTL_FILEは最大32767バイトのバッファを利用できますが、前者はバッファを有効利用せず、100Bytes毎に書き出しています。後者は約32KB単位で書き出しています。

その差はAWRレポートからも見えてきます。

AWRレポート（一部抜粋）
UTL_FILEパッケージによるI/Oの待機は、”utl_file I/O”という待機イベントで現れます。

Avg Waitは短いですが、理由は100バイト単位の小さいなサイズの書き込みを繰り返しているわけなので、そんなとこでしょう。

Top 10 Foreground Events by Total Wait Time

                                           Total Wait       Avg   % DB Wait
Event                                Waits Time (sec)      Wait   time Class
------------------------------ ----------- ---------- --------- ------ --------
DB CPU                                          147.4             99.3
utl_file I/O                    32,212,266       49.5    1.54us   33.3 User I/O
direct path read                     1,881        1.2  620.61us     .8 User I/O
resmgr:cpu quantum                       1         .1   85.85ms     .1 Schedule
db file sequential read                 17          0     .98ms     .0 User I/O
PGA memory operation                    90          0   35.13us     .0 Other
latch: shared pool                       1          0    1.05ms     .0 Concurre
control file sequential read            80          0   12.83us     .0 System I
Disk file operations I/O                 6          0   73.67us     .0 User I/O
SQL*Net message to client                2          0    9.00us     .0 Network

一方、約32KB単位でバッファリングして書き出している場合、Waits回数が激減しています。
Avg Waitsは大きくなっていますが、書き出しサイズにほぼ比例しているので想定通りというところ。

Top 10 Foreground Events by Total Wait Time

                                           Total Wait       Avg   % DB Wait
Event                                Waits Time (sec)      Wait   time Class
------------------------------ ----------- ---------- --------- ------ --------
DB CPU                                             45             98.5
utl_file I/O                        66,288       27.4  413.54us   60.1 User I/O
direct path read                     1,881          1  550.71us    2.3 User I/O
db file sequential read                 88          0  443.38us     .1 User I/O
direct path write                        2          0    4.69ms     .0 User I/O
control file sequential read            80          0   33.25us     .0 System I
latch: shared pool                       1          0    2.38ms     .0 Concurre
Disk file operations I/O                 4          0  323.50us     .0 User I/O
PGA memory operation                    79          0   15.73us     .0 Other
SQL*Net message to client                4          0   20.25us     .0 Network

utl_file.put/put_lineでcsvを出力しているdeviceのiostat(util%)
まだまだ余裕があるのでI/Oで詰まっているのではなく、UTL_FILE.PUT/PUT_LINEの使い方の影響が大きいということですね。

最後に、
UTL_FILEパッケージの入出力時にはバッファの有効利用をお忘れなく。(つい忘れちゃうこともあるので、急いでるときとかw）
扱うデータが多い場合は得に。

そして、みなさま、
メリークリスマス（まだエントリーを書くかもしれませんがw）
#JPOUG

DBMS_ADVISOR.CREATE_FILE()プロシージャは、Diagnostic/Tuning Pack不要らしいということの確認

Previously on Mac De Oracle

---

余談

DBMS_ADVISOR.CREATE_FILEとなっているがライセンス上、diagnostic/tuning packライセンスはなくてもアクセスしてできるように読み取れるのだけと、もしかすると、この影響で、DBMS_ADVISOR.CREATE_FILEの存在は知っていても使ってないのかあるのかな？？

以下のマニュアルを読む限り、Diagnostic/Tuning Packでは、DBMS_ADVISORパッケージ全体ではなく、Diagnostic/Tuning Packに関連するパラメータを与える必要のある機能についての制限であることしか記載されていない。
つまり、DBMS_ADVISOR.CREATE_FILE()に関して言えば、Diagnostic/Tuning Pack特有の機能ではないから利用可能なはず。　←間違ってたらツッコミ希望w

Oracle® Databaseライセンス情報 12cリリース1 (12.1) 2 オプションおよびパック
https://docs.oracle.com/cd/E49329_01/license.121/b71334/options.htm

---

なんてことを書いたところ、

control_management_pack_access=none

でも使えるとなら間違いなくないんじゃないの？
というコメントがあったので試してみました。　マニュアルの通りだと思われます。ということですね。FAQ!

orcl@SYS> show parameter control_management_pack_access

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_management_pack_access        string     NONE
orcl@SYS> 
orcl@SYS> l
1 DECLARE
2     reportClob CLOB := EMPTY_CLOB();
3 BEGIN
4     reportClob := 'test test test';
5     DBMS_ADVISOR.CREATE_FILE(
6     buffer => reportClob
7     ,location => 'REP_DIR'
8     ,filename => 'test.txt'
9 );
10* END;
orcl@SYS> /

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:00.23
orcl@SYS> !ls report 
test.txt

orcl@SYS> !cat report/test.txt
test test test

---

・DBMS_SQLTUNE.PACK_STGTAB_SQLSETって、例外投げんのかよw
・SQL Tuning Setのキャプチャから退避までのスクリプト（やっつけ）
・SQL Tuning Set (STS)のフィルタリング
・DBMS_SQLTUNE.REPORT_ANALYSIS_TASK()ファンクションで生成されるCLOB型のレポートをファイルに保存する簡単な方法

DBMS_SQLTUNE.REPORT_ANALYSIS_TASK()ファンクションで生成されるCLOB型のレポートをファイルに保存する簡単な方法

Previously on Mac De Oracle
STSとの格闘というかSPAとの格闘に疲れてきたところw ですが、
SQL Tuning Set (STS)のフィルタリング
などで、SQLSETを程よい大きさに分割するところまでたどり着きましたw

今回は、いくつかある細かい分析方法については、一旦、置いといて、
分析レポートを保存する簡単な方法についての備忘録

分析などにこの記事も参考になると思いますが、紹介している記事でも分析レポートをファイルに保存する方法はSQL*Plusのコマンドを駆使して行われています。
個人的には少々やぼったい方法かなと感じている方法なんですが、以前はこんなやりかたが多かったようにも思います。

var rep CLOB
...略...
EXEC :rep := DBMS_SQLSPA.REPORT_ANALYSIS_TASK('STSNAM','TEXT',...
spo hoge_report.txt
print :rep
spo off

SQL*PlusとPL/SQLが行ったり来たりするところや、ループ制御しにくいので、この方法は避けたい。。。。

かといって、DBMS_OUTPUT.PUT_LINEで行おうとするとset linesize等の制御が面倒くさいし
結局、SQL*Plusの機能にも依存してしまうので、いまひとつ。

PL/SQLだけで行う方法として、UTL_FILEパッケージを利用してファイル出力する方法もありますが、
UTL_FILEパッケージで提供されているAPIはlow levelなものばかりなので、急ぎの時にはめんどくさくて、やだw

もっと簡単なやつないの？？？？？

あります！w

DBMS_ADVISOR.CREATE_FILE(buffer, location, filename)

なぜ、UTL_FILEパッケージに入れてくれないんだw と思いたくなる方もいるかと思いますが、 理由はよくわかりませんw
（UTL_FILEパッケージはlow levelなAPIだけだから入れたくないのかも、かも、かも。と思ってますが、DBMS_ADVISORパッケージに入れるとは。どういうつもりだ！w）

UTL_FILE.CREATE_FILE()ってあったほうが直感的に探しやすくないかw UTL_FILEみて無い！！
となると、他を探すこともあまりなくなって、結局、コード書いてる場面を多く見てる＞＜　

---

余談

DBMS_ADVISOR.CREATE_FILEとなっているがライセンス上、diagnostic/tuning packライセンスはなくてもアクセスしてできるように読み取れるのだけと、もしかすると、この影響で、DBMS_ADVISOR.CREATE_FILEの存在は知っていても使ってないのかあるのかな？？

以下のマニュアルを読む限り、Diagnostic/Tuning Packでは、DBMS_ADVISORパッケージ全体ではなく、Diagnostic/Tuning Packに関連するパラメータを与える必要のある機能についての制限であることしか記載されていない。
つまり、DBMS_ADVISOR.CREATE_FILE()に関して言えば、Diagnostic/Tuning Pack特有の機能ではないから利用可能なはず。　←間違ってたらツッコミ希望w

Oracle® Databaseライセンス情報 12cリリース1 (12.1) 2 オプションおよびパック
https://docs.oracle.com/cd/E49329_01/license.121/b71334/options.htm

---

とりあえず、SQLSETの分析レポートをDBMS_ADVISOR.CREATE_FILE()を利用して保存するやっつけスクリプトを作ってみました
これを元に育てていけるかなw

実行例）

注）STS20171102というSQLSETを事前に作成してあります。

orcl@SYS> select * from v$version;

BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production              0
PL/SQL Release 12.2.0.1.0 - Production                                                    0
CORE	12.2.0.1.0	Production                                                            0
TNS for Linux: Version 12.2.0.1.0 - Production                                            0
NLSRTL Version 12.2.0.1.0 - Production                                                    0


orcl@SYS> select owner,name,statement_count,created from dba_sqlset order by name;

OWNER      NAME                           STATEMENT_COUNT CREATED
---------- ------------------------------ --------------- ---------
SPAUSER    STS20171102                               1003 02-NOV-17

spa.sqlのパラメータは、SQLSETと分析レポートの出力ディレクトリオブジェクトとSQLを実行するスキーマ向けのDBリンクです。

スクリプトの概要
・初回の分析（SQLSETで元のSQLを分析）
・２回目の分析（新環境でSQLを実行して分析)
・初回と２回目の比較レポート作成／保存
・レポートを出力後、分析に利用したタスクを削除

orcl@SYS> @spa STS20171102 rep_dir link_4_target

task name:STS20171102 has been droped.
***END***

PL/SQL procedure successfully completed.

分析レポートは、ディレクトリオブジェクトに対応づけられたパスに保存されます

orcl@SYS> !ls -l report
-rw-r--r-- 1 oracle oinstall 13688 11月  3 02:44 DIFF_STS20171102171103024433.txt

orcl@SYS> !cat report/DIFF_STS20171102171103024433.txt

General Information
---------------------------------------------------------------------------------------------

 Task Information:                              Workload Information:                         
 ---------------------------------------------  --------------------------------------------- 
  Task Name    : STS20171102                     SQL Tuning Set Name        : STS20171102     
  Task Owner   : SYS                             SQL Tuning Set Owner       : SPAUSER         
  Description  :                                 Total SQL Statement Count  : 1003            

Execution Information:
---------------------------------------------------------------------------------------------
  Execution Name             : DIFF_STS20171102       Started             : 11/03/2017 02:44:26  
  Execution Type             : COMPARE PERFORMANCE    Last Updated        : 11/03/2017 02:44:29  
  Description                :                        Global Time Limit   : UNLIMITED            
  Scope                      : COMPREHENSIVE          Per-SQL Time Limit  : UNUSED               
  Status                     : COMPLETED              Number of Errors    : 0                    
  Number of Unsupported SQL  : 4                                                                 

Analysis Information:
---------------------------------------------------------------------------------------------
 Before Change Execution:                       After Change Execution:                       
 ---------------------------------------------  --------------------------------------------- 
  Execution Name      : SOURCE_STS20171102       Execution Name      : TARGET_STS20171102     
  Execution Type      : CONVERT SQLSET           Execution Type      : TEST EXECUTE REMOTE    
  Scope               : COMPREHENSIVE            Database Link       : LINK_4_TARGET          
  Status              : COMPLETED                Scope               : COMPREHENSIVE          
  Started             : 11/03/2017 02:44:04      Status              : COMPLETED              
  Last Updated        : 11/03/2017 02:44:04      Started             : 11/03/2017 02:44:04    
  Global Time Limit   : UNLIMITED                Last Updated        : 11/03/2017 02:44:18    
  Per-SQL Time Limit  : UNUSED                   Global Time Limit   : UNLIMITED              
                                                 Per-SQL Time Limit  : UNUSED                 
                                                 Number of Errors    : 0                      
                                                                                              
 ---------------------------------------------                                                
 Comparison Metric: ELAPSED_TIME                                                              
 ------------------                                                                           
 Workload Impact Threshold: 1%                                                                
 --------------------------                                                                   
 SQL Impact Threshold: 1%                                                                     
 ----------------------                                                                       

Report Summary
---------------------------------------------------------------------------------------------

Projected Workload Change Impact:
-------------------------------------------
 Overall Impact      :  0% 
 Improvement Impact  :  0% 
 Regression Impact   :  0% 

SQL Statement Count
-------------------------------------------
 SQL Category  SQL Count  Plan Change Count 
 Overall             999                490 
 Unchanged           995                490 
 Unsupported           4                  0 

Top 100 SQL Sorted by Absolute Value of Change Impact on the Workload
---------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
|           |               | Impact on | Execution | Metric | Metric | Impact | Plan   |
| object_id | sql_id        | Workload  | Frequency | Before | After  | on SQL | Change |
-----------------------------------------------------------------------------------------
|      1477 | 7hys3h7ysgf9m |       .1% |         1 |  14630 |     33 | 99.77% | n      |
|      1811 | cw6vxf0kbz3v1 |      .03% |         1 |   3602 |     24 | 99.33% | n      |
|      1175 | 2s9mmb6g8kbqb |      .01% |         1 |   1537 |     20 |  98.7% | n      |

...中略...

|      1691 | az25yp5qunj77 |      .01% |         1 |    882 |     20 | 97.73% | n      |
|      1896 | faun6bjrjqr17 |      .01% |         1 |    881 |     19 | 97.84% | n      |
|      1956 | g7a2tmw1nrxbh |      .01% |         1 |    881 |     19 | 97.84% | n      |
-----------------------------------------------------------------------------------------
Note: time statistics are displayed in microseconds
---------------------------------------------------------------------------------------------


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

スクリプトは以下のとおり、無名PL/SQLブロックにしてあります。
レポートのタイプなどは固定にしてますが、それらも含めてパラメータにしてもいいかも。

ちなみに、このエントリの本題である、DBMS_ADVISOR.CREATE_FILE()は赤字部分です！

orcl@SYS> !cat spa.sql

set serveroutput on
DECLARE
	report_clob CLOB;
	cSQLSET_OWNER VARCHAR2(30) := 'SPAUSER';
	cSQLSET_NAME VARCHAR2(20) := UPPER('&1');
	cEXECUTION_NAME_PREFIX_SOURCE VARCHAR2(7) := 'SOURCE_';
	cEXECUTION_NAME_PREFIX_TARGET VARCHAR2(7) := 'TARGET_';
	cEXECUTION_NAME_PREFIX_DIFF   VARCHAR2(5) := 'DIFF_';
	cREPORT_TYPE CONSTANT VARCHAR2(4) := 'text';
	cFILE_EXTENTION CONSTANT VARCHAR2(5) := '.txt';
	cDIRECTORY_NAME CONSTANT VARCHAR2(30) := UPPER('&2');
	cDB_LINK_4_PARSING_SCHEMA CONSTANT VARCHAR2(128) := UPPER('&3');
	stmt_task VARCHAR2(64);

	PROCEDURE drop_task (iTASK_NAME VARCHAR2)
	IS
	BEGIN
        	FOR task_rec IN (
                	SELECT
                        	task_name
                	FROM
                        	dba_advisor_tasks
                	WHERE
                        	task_name = iTASK_NAME
                        	AND advisor_name = 'SQL Performance Analyzer'
        	) LOOP
                	DBMS_OUTPUT.PUT_LINE(
				'task name:'||task_rec.task_name||' has been droped.'
			);
                	DBMS_SQLPA.DROP_ANALYSIS_TASK(
            			task_name => task_rec.task_name
                	);
        	END LOOP;
	END drop_task;
BEGIN
	--Create analysis task
	stmt_task := DBMS_SQLPA.CREATE_ANALYSIS_TASK(
		sqlset_name => cSQLSET_NAME
		,basic_filter => 'parsing_schema_name in (''SCOTT'')'
		,sqlset_owner => cSQLSET_OWNER
		,task_name => cSQLSET_NAME
	);

	--SQL Analysis on Source DB
	DBMS_SQLPA.EXECUTE_ANALYSIS_TASK(
		task_name => cSQLSET_NAME
		,execution_type => 'CONVERT SQLSET'
		,execution_name => 
			cEXECUTION_NAME_PREFIX_SOURCE
			|| cSQLSET_NAME
		,execution_params => 
			DBMS_ADVISOR.ARGLIST(
				'sqlset_name', cSQLSET_NAME
				,'sqlset_owner', cSQLSET_OWNER
		)
	);

	--SQL Analysis on Target DB
	DBMS_SQLPA.EXECUTE_ANALYSIS_TASK(
		task_name => cSQLSET_NAME
		,execution_type => 'EXECUTE'
		,execution_name => 
			cEXECUTION_NAME_PREFIX_TARGET
			|| cSQLSET_NAME
		,execution_params =>
			DBMS_ADVISOR.ARGLIST(
				'DATABASE_LINK', cDB_LINK_4_PARSING_SCHEMA	
				,'EXECUTE_FULLDML', 'TRUE'
			)
	);

	--Comparison Source and Target Analysys 
	DBMS_SQLPA.EXECUTE_ANALYSIS_TASK(
		task_name => cSQLSET_NAME
		,execution_type => 'COMPARE'
		,execution_name => 
			cEXECUTION_NAME_PREFIX_DIFF
			|| cSQLSET_NAME
		,execution_params =>
			DBMS_ADVISOR.ARGLIST(
				'PLAN_LINES_COMPARISON','ALWAYS'
			)
	);

	--Make comparison report
	report_clob := DBMS_SQLPA.REPORT_ANALYSIS_TASK(
		task_name => cSQLSET_NAME
		,execution_name => 
			cEXECUTION_NAME_PREFIX_DIFF
			|| cSQLSET_NAME
		,type => cREPORT_TYPE
		,level => 'typical'
		,section => 'summary'
	);

	--Save comparison report
	DBMS_ADVISOR.CREATE_FILE(
		buffer => report_clob
		,location => cDIRECTORY_NAME
		,filename => 
			cEXECUTION_NAME_PREFIX_DIFF
			||cSQLSET_NAME
			||TO_CHAR(systimestamp, 'RRMMDDHH24MISS')
			||cFILE_EXTENTION
	);

	--Drop Task
	drop_task(cSQLSET_NAME);
	DBMS_OUTPUT.PUT_LINE('***END***');
EXCEPTION
	WHEN OTHERS THEN
		drop_task(cSQLSET_NAME);
		RAISE;
END;
/

---

・DBMS_SQLTUNE.PACK_STGTAB_SQLSETって、例外投げんのかよw
・SQL Tuning Setのキャプチャから退避までのスクリプト（やっつけ）
・SQL Tuning Set (STS)のフィルタリング

SQL Tuning Set (STS)のフィルタリング

Previously on Mac De Oracle
前回は、やっつけすくりぷとを書いたところまででした。

ということで、今回のやっつけスクリプトの準備というかアイデア

SQLSET大量のSQL文キャプチャされていて、SQLSETにキャプチャされている大量のSQL文を一括でSPAでまわしたりすることが辛い場合があります。
そんなときはどうすればよいか。。なやみますよね。。。ほんと。。
SQL Performance AnalyzerによるSQLパフォーマンス比較実行例(API)

SQLSETから、より細かなSQLSETにほぼ当分に分割し、新たなSQLSETを作成したいような場合もあるかもしれません。
そんな時はどうするか？

手取りばやくやるなら、ORA_HASH()が便利ですよね。（SQLSETの全表走査はさけられないのですが、Exaならw）

たとえば、以下のSQLSETがあったとして、300件程度に均等に分割したいという場合。
ora_hash()のバケット数はだいたい12ぐらいでできそうですね。

orcl@SYS> select name,statement_count,created from dba_sqlset order by name;

NAME                           STATEMENT_COUNT CREATED
------------------------------ --------------- ---------
STS20171029                               3819 29-OCT-17

orcl@SYS> select statement_count/300 from dba_sqlset where name='STS20171029';

STATEMENT_COUNT/300
-------------------
              12.73

いい感じに分割できそうです。

orcl@SYS> r
  1  select
  2    ora_hash(sql_id,12) as hash#
  3   ,count(sql_id)
  4  from
  5    table(dbms_sqltune.select_sqlset(
  6      sqlset_name=>'STS20171029'
  7     ,basic_filter=>null
  8    ))
  9  group by
 10    ora_hash(sql_id,12)
 11* order by 1

     HASH# COUNT(SQL_ID)
---------- -------------
         0           289
         1           293
         2           278
         3           296
         4           297
         5           281
         6           282
         7           298
         8           288
         9           304
        10           305
        11           298
        12           310

13 rows selected.

実際に利用するには、basic_filterでwhere句の条件文そのものを書いてあげます。サブクエリも書けますが、データ量が多い場合は性能面に注意しながらいろいろ試してみるといいと思います。
basic_filterでは、SQLSET_ROWオブジェクト・タイプの属性を利用したフィルタリングができるのですが、インジェクションですよね。構文を見ている限り;)
Oracle® Database PL/SQLパッケージおよびタイプ・リファレンス 12c リリース1 (12.1) SQLSET_ROWオブジェクト・タイプ

orcl@SYS> set serveroutput on
orcl@SYS> r
  1  begin
  2    for i in 0..12 loop
  3      for sqlset_rec in
  4      (
  5        select count(sql_id) as num_sql
  6        from
  7          table(dbms_sqltune.select_sqlset(
  8            sqlset_name=>'STS20171029'
  9           ,basic_filter=>'ora_hash(sql_id,12)='||i
 10          ))
 11      )
 12      loop
 13        dbms_output.put_line('hash#='||to_char(i,'fm99')||':'||sqlset_rec.num_sql);
 14      end loop;
 15    end loop;
 16* end;
hash#=0:289
hash#=1:293
hash#=2:278
hash#=3:296
hash#=4:297
hash#=5:281
hash#=6:282
hash#=7:298
hash#=8:288
hash#=9:304
hash#=10:305
hash#=11:298
hash#=12:310

PL/SQL procedure successfully completed.

ハッシュ値10でsql_id数をカウント！
うまくできそうですよね。

orcl@SYS> r
  1  select
  2    count(sql_id)
  3  from
  4    table(dbms_sqltune.select_sqlset(
  5      sqlset_name=>'STS20171029'
  6     ,basic_filter=>'ora_hash(sql_id,12) = 10'
  7*   ))

COUNT(SQL_ID)
-------------
          305

参考
Oracle® Database PL/SQLパッケージおよびタイプ・リファレンス　12c リリース1 (12.1) DBMS_SQLTUNE
Oracle® Database SQL言語リファレンス 12cリリース1 (12.1) ORA_HASH

---

・DBMS_SQLTUNE.PACK_STGTAB_SQLSETって、例外投げんのかよw
・SQL Tuning Setのキャプチャから退避までのスクリプト（やっつけ）

SQL Tuning Setのキャプチャから退避までのスクリプト（やっつけ）

Previously on Mac De Oracleは
DBMS_SQLTUNE.PACK_STGTAB_SQLSETって、例外投げんのかよwという備忘録でした、

今回は
以下のURLで紹介されているSTS (SQL Tuning Set)へSQLの性能統計や実行計画をキャプチャしちゃおう！
Oracle DatabaseのSTS(SQL Tuning Set) を活用して、SQLの性能統計や実行計画をキャプチャする。 / ora_gonsuke777

というSTS機能を利用した応用編w　（という名のやっつけスクリプト）　を書いたので、備忘録

STSでSQLの実行計画や性能統計をキャプチャするのはいいのですが、キャプチャするデータが多い場合、SYSAUX表領域を圧迫したり、拡張したりしてしまうことがあります。
本番環境で表領域サイズにドキドキする日々を送るのも嫌なので、一定期間STSヘキャプチャしたあとSTSを退避、削除したいよね。という方向の話が湧いてきたりしますw

で、書いたやっつけスクリプトが以下。(11g2と12cR1でテスト済み）
STSをキャプチャする時間、インターバル、そして、STSを退避するためのステージング表を作成するスキーマ名と、エクスポートに必要なディレクトリオブジェクト名を
パラメータに取ります。キャプチャする時間とインターバルは秒を指定します。エクスポートは、DBMS_DATAPUMPパッケージを利用しています。
今回利用したパッケージの詳細は以下を参照のこと:)

Oracle® Database PL/SQLパッケージおよびタイプ・リファレンス 11g リリース2(11.2) B56262-06
- DBMS_SQLTUNEサブプログラムの要約
- 46 DBMS_DATAPUMP

なお、本スクリプト実施前に、DataPump Export向けディレクトリオブジェクトを、ステージング表を作成するユーザを作成しておく必要があります。
（後半の実行例は、STS_EXP_DIRディレクトリオブジェクト、STSUSRユーザを事前に作成）
sts_capture.sql

SET SERVEROUTPUT ON
/*
  Arguments :
    &1 - Schema name for sts staging table
    &2 - Directory object name for Data Pump Export
    &3 - Duration for SQLSET capturing (sec)
    &4 - Sampling interval for SQLSET (sec)
*/
DECLARE
  -- for STS capturing and packing
  vStsName VARCHAR2(30) := 'STS' || TO_CHAR(SYSDATE, 'YYYYMMDDHH24MISS');
  cTimeLimit CONSTANT POSITIVE := &3;  
  cInterval CONSTANT POSITIVE := &4; 
  cCaptureOpt CONSTANT VARCHAR2(20) := 'MERGE';
  cStagingSchema CONSTANT VARCHAR2(30) := UPPER('&1');
  v4Debug VARCHAR2(50);
  
  -- for DataPump Export Job
  cDirectory CONSTANT VARCHAR2(20) := UPPER('&2');
  IsSkipExport BOOLEAN := false;
  i NUMBER;
  vDataPumpJobHandle NUMBER; 
  vProgress_ratio NUMBER;
  vJobState VARCHAR2(30);
  oLogEntry ku$_LogEntry;
  oStatus ku$_Status;
BEGIN
  DBMS_OUTPUT.ENABLE;
  
  -- STS名にInstance#を付加
  -- （RAC環境での複数ノードでの実行を考慮してインスタンス番号を付加）
  v4Debug := 'Build STSNAME';
  FOR instance_rec IN (SELECT TO_CHAR(instance_number) AS inum FROM v$instance) LOOP
    vStsName := vStsName || instance_rec.inum;
  END LOOP;
  
  -- SQLSETの作成
  v4Debug := 'CREATE_SQLSET';
  DBMS_SQLTUNE.CREATE_SQLSET (
    sqlset_name => vStsName
    ,sqlset_owner => NULL
  );

  -- カーソルキャッシュからSTSへ定期キャプチャ
  v4Debug := 'CAPTURE_CURSOR_CACHE_SQLSET';
  DBMS_SQLTUNE.CAPTURE_CURSOR_CACHE_SQLSET (
    sqlset_name => vStsName
    ,time_limit => cTimeLimit
    ,repeat_interval => cInterval
    ,capture_option => cCaptureOpt
    ,capture_mode => DBMS_SQLTUNE.MODE_REPLACE_OLD_STATS
    ,basic_filter =>
      'parsing_schema_name NOT IN (
         ''SYS'', ''SYSTEM'', ''APEX_050000'', ''APEX_040000'', ''SYSMAN''
      )'
    ,sqlset_owner => NULL
  );
  
  -- STSエクスポート向けステージング表の作成
  v4Debug := 'CREATE_STGTAB_SQLSET';
  DBMS_SQLTUNE.CREATE_STGTAB_SQLSET (
    table_name => vStsName
    ,schema_name => cStagingSchema
    ,db_version => NULL
  );
  
  -- STSをステージング表へパック
  v4Debug := 'PACK_STGTAB_SQLSET';
  BEGIN
  DBMS_SQLTUNE.PACK_STGTAB_SQLSET (
    sqlset_name => vStsName
    ,sqlset_owner => NULL
    ,staging_table_name => vStsName
    ,staging_schema_owner => cStagingSchema
    ,db_version => NULL
  );
  EXCEPTION
    WHEN OTHERS THEN
      IF sqlcode = -15701 THEN
        IsSkipExport := true;
        DBMS_OUTPUT.PUT_LINE('*** Info - No data packed from SQLSET ***');
      ELSE
        RAISE;
      END IF;
  END;

  IF IsSkipExport = false 
  THEN
    -- ステージング表を表モードでエクスポート 
    -- エクスポートのモード等の設定
    v4Debug := 'OPEN';
    vDataPumpJobHandle 
     := DBMS_DATAPUMP.OPEN (
       operation => 'EXPORT'
       ,job_mode => 'TABLE'
       ,remote_link => NULL
       ,job_name => vStsName
       ,version => 'LATEST'
     );

    -- エスポートダンプファイルとログファイルの設定
    v4Debug := 'ADD_FILE - dumpfile';
    DBMS_DATAPUMP.ADD_FILE (
      handle => vDataPumpJobHandle
      ,filename => vStsName || '.dmp'
      ,directory => cDirectory
      ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_DUMP_FILE
    );

    v4Debug := 'ADD_FILE - logfile';
    DBMS_DATAPUMP.ADD_FILE (
      handle => vDataPumpJobHandle
      ,filename => vStsName || '.log'
      ,directory => cDirectory
      ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_LOG_FILE
    );

    -- メターデータフィルタの設定
    -- エクスポート対象表のスキーマ
    v4Debug := 'METADATA_FILTER - schema name';
    DBMS_DATAPUMP.METADATA_FILTER (
      handle => vDataPumpJobHandle
      ,name => 'SCHEMA_LIST'
      ,value => '''' || cStagingSchema || ''''
    );

    -- エクスポート対象表
    v4Debug := 'METADATA_FILTER - table name';
    DBMS_DATAPUMP.METADATA_FILTER (
      handle => vDataPumpJobHandle
      ,name => 'NAME_LIST'
      ,value => '''' || vStsName || ''''
    );

    -- DataPump Exportジョブの実行
    v4Debug := 'START_JOB';
    DBMS_DATAPUMP.START_JOB (
      handle => vDataPumpJobHandle
    );

    -- DataPump Exportジョブ状況監視と終了判定
    -- ジョブ終了または停止されるまでループして待機
    v4Debug := 'JOB_STATE';
    vProgress_ratio := 0;
    vJobState := 'UNDEFINED';
    WHILE (vJobState != 'COMPLETED') AND (vJobState != 'STOPPED') LOOP
      DBMS_DATAPUMP.GET_STATUS (
        vDataPumpJobHandle
        ,DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR 
          + DBMS_DATAPUMP.KU$_STATUS_JOB_STATUS 
          + DBMS_DATAPUMP.KU$_STATUS_WIP
        ,-1
        ,vJobState
        ,oStatus
      );

      -- 処理中(Work-In-Progress : WIP)または、
      -- エラーのいずれかのメッセージを受け取ったら表示
      IF (BITAND(oStatus.mask, DBMS_DATAPUMP.KU$_STATUS_WIP) != 0)
      THEN
        oLogEntry := oStatus.wip;
      ELSE
        IF (BITAND(oStatus.mask, DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR) != 0)
        THEN
          oLogEntry := oStatus.error;
        ELSE
          oLogEntry := NULL;
        END IF;
      END IF;
      IF oLogEntry IS NOT NULL
      THEN
        i := oLogEntry.FIRST;
        WHILE i IS NOT NULL LOOP
          DBMS_OUTPUT.PUT_LINE(oLogEntry(i).LogText);
          i := oLogEntry.NEXT(i);
        END LOOP;
      END IF;
    END LOOP;

    -- Data Pump Exportジョブ終了
    DBMS_DATAPUMP.DETACH(vDataPumpJobHandle);
  END IF;
    
  -- ステージング表の削除
  v4Debug := 'Drop staging table';
  EXECUTE IMMEDIATE 'DROP TABLE ' || cStagingSchema || '.' || vStsName || ' PURGE';
  
  -- SQLSETの削除
  v4Debug := 'DROP_SQLSET';
  DBMS_SQLTUNE.DROP_SQLSET (
    sqlset_name => vStsName
  );

EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE(sqlerrm());
    DBMS_OUTPUT.PUT_LINE(v4Debug);
    RAISE;
END;
/
EXIT

STSが空ではない場合の実行例
キャプチャ処理は600秒実行しキャプチャ間隔は120秒、キャプチャ終了後、STSUSRスキーマにステージング表を作成、STSをステージング表へパック、ステージング表を指定したディレクトリオブジェクト以下にDataPump Exportしています。

[oracle@guppy ˜]$ sqlplus system@orcl @sts_capture stsusr sts_exp_dir 10*60 2*60

SQL*Plus: Release 12.1.0.2.0 Production on Fri Oct 6 15:13:53 2017

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

Enter password: 

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

old   4:   cTimeLimit CONSTANT POSITIVE := &3;
new   4:   cTimeLimit CONSTANT POSITIVE := 10*60;
old   5:   cInterval CONSTANT POSITIVE := &4;
new   5:   cInterval CONSTANT POSITIVE := 2*60;
old   7:   cStagingSchema CONSTANT VARCHAR2(30) := UPPER('&1');
new   7:   cStagingSchema CONSTANT VARCHAR2(30) := UPPER('stsusr');
old  11:   cDirectory CONSTANT VARCHAR2(20) := UPPER('&2');
new  11:   cDirectory CONSTANT VARCHAR2(20) := UPPER('sts_exp_dir');
Starting "SYS"."STS201710061513571":
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 1.062 MB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type TABLE_EXPORT/TABLE/STATISTICS/MARKER
. . exported "STSUSR"."STS201710061513571"               51.55 KB       1 rows
Master table "SYS"."STS201710061513571" successfully loaded/unloaded
******************************************************************************
Dump file set for SYS.STS201710061513571 is:
/home/oracle/exp/STS201710061513571.dmp
Job "SYS"."STS201710061513571" successfully completed at Fri Oct 6 15:26:50 2017 elapsed 0 00:00:47

PL/SQL procedure successfully completed.

STSが空の場合の例
ステージング表へのSTSのパックやDataPump Exportの実行をパイパス。STSが空であることを表示して終了します。
なお、以下の例ではキャプチャ時間と間隔は意図的に短くしてあります。

[oracle@guppy  ˜]$ sqlplus system@orcl @sts_capture stsusr sts_exp_dir 2*60 60

SQL*Plus: Release 12.1.0.2.0 Production on Fri Oct 6 16:04:55 2017

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

Enter password: 

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

old   4:   cTimeLimit CONSTANT POSITIVE := &3;
new   4:   cTimeLimit CONSTANT POSITIVE := 2*60;
old   5:   cInterval CONSTANT POSITIVE := &4;
new   5:   cInterval CONSTANT POSITIVE := 60;
old   7:   cStagingSchema CONSTANT VARCHAR2(30) := UPPER('&1');
new   7:   cStagingSchema CONSTANT VARCHAR2(30) := UPPER('stsusr');
old  11:   cDirectory CONSTANT VARCHAR2(20) := UPPER('&2');
new  11:   cDirectory CONSTANT VARCHAR2(20) := UPPER('sts_exp_dir');
*** Info - No data packed from SQLSET ***

PL/SQL procedure successfully completed.

このスクリプトをshellに組み込んでcronでも定期実行したりDBMS_SCHEDULERで定期実行するのも良いかな。
オレオレサンプルなので、より便利に改造して使ってね。v

ORA-12034 #2

前回の通り、高速リフレッシュの間にdata pump export / importを完了させれば、ORA-12034なんて起きないはず。

VirtualBoxの環境は試験開始前のスナップショットで戻してあります

SQL*Plus: Release 12.1.0.2.0 Production on Mon Aug 28 20:57:49 2017

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

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

orcl@MVIEW_SCHEMA1> @mview_info_c
Connected.

¥Session altered.

ROWNER               RNAME                  REFGROUP        JOB B INTERVAL             NEXT_DATE               CON_ID
-------------------- -------------------- ---------- ---------- - -------------------- ------------------- ----------
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+5/1440       2017/08/28 21:00:54          3

MVIEW_NAME                     REFRES REFRESH_ LAST_REF AFTER_FAST_REFRESH  COMPILE_STATE
------------------------------ ------ -------- -------- ------------------- -------------------
MV_MASTER                      DEMAND FAST     FAST     UNDEFINED           VALID

       JOB LOG_USER             SCHEMA_USER          LAST_DATE           NEXT_DATE           INTERVAL               FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 20:55:54 2017/08/28 21:00:54 sysdate+5/1440                0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

前回は5分間隔だったので、余裕をもたせて30分にしてあります。
本番環境で5分間隔の高速リフレッシュを30分にしたり、止めたりってことはかなり敷居が高いとは思いますが、そのあたりは空気を読んで対応する必要があるかと。　:)

orcl12c@SYS> conn mview_schema1@orcl
Connected.
orcl@MVIEW_SCHEMA1> alter materialized view mv_master refresh next sysdate+30/1440;

Materialized view altered.

orcl@MVIEW_SCHEMA1> @mview_info_c
Connected.

Session altered.


ROWNER               RNAME                  REFGROUP        JOB B INTERVAL             NEXT_DATE               CON_ID
-------------------- -------------------- ---------- ---------- - -------------------- ------------------- ----------
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+30/1440      2017/08/28 21:30:36          3

MVIEW_NAME                     REFRES REFRESH_ LAST_REF AFTER_FAST_REFRESH  COMPILE_STATE
------------------------------ ------ -------- -------- ------------------- -------------------
MV_MASTER                      DEMAND FAST     FAST     UNDEFINED           VALID

       JOB LOG_USER             SCHEMA_USER          LAST_DATE           NEXT_DATE           INTERVAL               FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 20:55:54 2017/08/28 21:30:36 sysdate+30/1440               0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

準備は整ったので、高速リフレッシュが終わったタイミングでexportからimportまでをやっつけちゃいます！
まずはエクスポート

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Starting "SYSTEM"."SYS_EXPORT_SCHEMA_01":  system/********@orcl directory=workdir dumpfile=mview_schema1.dmp logfile=exp_mview_schema1.log schemas=mview_schema1 
Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 64 KB
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/DB_LINK
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/STATISTICS/MARKER
Processing object type SCHEMA_EXPORT/MATERIALIZED_VIEW
Processing object type SCHEMA_EXPORT/JOB
Processing object type SCHEMA_EXPORT/REFRESH_GROUP
. . exported "MVIEW_SCHEMA1"."MV_MASTER"                   5.5 KB       2 rows
Master table "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_SCHEMA_01 is:
  /u01/userhome/oracle/mview_schema1.dmp
Job "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully completed at Mon Aug 28 21:05:00 2017 elapsed 0 00:00:56

[oracle@vbgeneric ˜]$ sqlplus master_schema@orcl

SQL*Plus: Release 12.1.0.2.0 Production on Mon Aug 28 21:05:19 2017

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


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

orcl@MASTER_SCHEMA> select count(*) from mlog$_master;

  COUNT(*)
----------
         0

orcl@MASTER_SCHEMA> conn mview_schema1@orcl
Connected.

orcl@MVIEW_SCHEMA1> @mview_info_c
Connected.

Session altered.


ROWNER               RNAME                  REFGROUP        JOB B INTERVAL             NEXT_DATE               CON_ID
-------------------- -------------------- ---------- ---------- - -------------------- ------------------- ----------
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+30/1440      2017/08/28 21:30:36          3

MVIEW_NAME                     REFRES REFRESH_ LAST_REF AFTER_FAST_REFRESH  COMPILE_STATE
------------------------------ ------ -------- -------- ------------------- -------------------
MV_MASTER                      DEMAND FAST     FAST     UNDEFINED           VALID

       JOB LOG_USER             SCHEMA_USER          LAST_DATE           NEXT_DATE           INTERVAL               FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 20:55:54 2017/08/28 21:30:36 sysdate+30/1440               0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

次にインポートしてMviewを複製！　

orcl12c@SYS> conn system@orcl2
Connected.
orcl2@SYSTEM>  create directory workdir as '/u01/userhome/oracle';

Directory created.

orcl2@SYSTEM> exit
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
[oracle@vbgeneric ˜]$ impdp system@orcl2 directory=workdir dumpfile=mview_schema1.dmp logfile=imp_mview_schema1.dmp 

Import: Release 12.1.0.2.0 - Production on Mon Aug 28 21:07:13 2017

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_FULL_01":  system/********@orcl2 directory=workdir dumpfile=mview_schema1.dmp logfile=imp_mview_schema1.dmp 
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/DB_LINK
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
. . imported "MVIEW_SCHEMA1"."MV_MASTER"                   5.5 KB       2 rows
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/STATISTICS/MARKER
Processing object type SCHEMA_EXPORT/MATERIALIZED_VIEW
Processing object type SCHEMA_EXPORT/JOB
Processing object type SCHEMA_EXPORT/REFRESH_GROUP
Job "SYSTEM"."SYS_IMPORT_FULL_01" successfully completed at Mon Aug 28 21:07:40 2017 elapsed 0 00:00:23

複製完了！！！！
結果はいかに...

[oracle@vbgeneric ˜]$ sqlplus mview_schema1@orcl2

SQL*Plus: Release 12.1.0.2.0 Production on Mon Aug 28 21:08:09 2017

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


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

orcl2@MVIEW_SCHEMA1> @mview_info_c
Connected.

Session altered.

ROWNER               RNAME                  REFGROUP        JOB B INTERVAL             NEXT_DATE               CON_ID
-------------------- -------------------- ---------- ---------- - -------------------- ------------------- ----------
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+30/1440      2017/08/28 22:00:46          5
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+30/1440      2017/08/28 22:00:46          3

MVIEW_NAME                     REFRES REFRESH_ LAST_REF AFTER_FAST_REFRESH  COMPILE_STATE
------------------------------ ------ -------- -------- ------------------- -------------------
MV_MASTER                      DEMAND FAST     FAST     UNDEFINED           VALID
MV_MASTER                      DEMAND FAST     FAST     UNDEFINED           VALID

       JOB LOG_USER             SCHEMA_USER          LAST_DATE           NEXT_DATE           INTERVAL               FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 21:30:46 2017/08/28 22:00:46 sysdate+30/1440               0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 21:30:46 2017/08/28 22:00:46 sysdate+30/1440               0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

予想通り成功しました！

エクスポート〜インポートによるMVIEW複製までを高速リフレッシュの間に行うことが可能ならば例のエラーは回避できることが確認できました。
が、
小さなMViewならまだしも、巨大なMView、巨大なMViewが複数あるリフレッシュグループだったりすると、それはもう大変な作業になることは想像できます。
大人の事情でMViewの高速リフレッシュを止められない、とか高速リフレッシュ間隔が非常短い場合には無理しないで、ほかの手を考えた方が良いと思います。
ただし、他の手を進めるにも時間には余裕を持った方がいいですよね。なんでギリギリなんだろうねと、よく思います。
夏休みの最後の1週間で宿題全部やりきるみたいなのは嫌ですよねw

---

Data Pumpも癖モノだよね〜w　その１ - queryパラメーターの解析タイミング
Data Pumpも癖モノだよね〜w　その２ - Materialized ViewをTableとして移行する
Data Pumpも癖モノだよね〜w　その3 - dbms_job と dbms_scheduler との複雑な関係
Data Pumpも癖モノだよね〜w　その4 - schemaモードでMviewを他のPDBへ複製
Data Pumpも癖モノだよね〜w　その4と1/2 - schemaモードでMviewを他のPDBへ複製 (紛らわしいステータスw）
Data Pumpも癖モノだよね〜w　その5 - schemaモードでMviewを他のPDBへ複製（オプジェクトパス de 絞り込み）
Data Pumpも癖モノだよね〜w　その6 - schemaモードでMviewを他のPDBへ複製（オプジェクトパスが不足すると...）
ORA-12034

ORA-12034

一ヶ月の家庭内、ワンオペも無事終了したので、ブログも今年前半のペースで再開か！？w

ということで、
以前ちょっとだけ書いた高速リフレッシュを止めてないと完全リフレッシュが必要になってしまう。タイミングの問題にフォーカスしてみようと思います。

どのようなタイミングの問題かというと、

ORA-12034: materialized view log on "xxxxxx"."xxxxxxx" younger than last refresh

出会った方も意外と多かったりしてw　

前述のエラーは、materialized view logが絡んいるので、”高速リフレッシュ”時に発生するエラーです！
高速リフレッシュを行なっている環境でこの状態になってしまうと、”高速リフレッシュ”の再開には”完全リフレッシュ”が必須となってしまうところが怖いというか面倒くさいところ。
マスターサイトも含めて同期するサイズが小さければ完全リフレッシュも面倒なことにならない場合もありますが、数十GB以上の巨大なマテビューだったら、どうします？？？
マテリアライズドビューのリフレッシュ間隔が短いシステムだと、完全リフレッシュに要する時間が大問題になることも... (色々な状況が想定されていない構成だと、そうなりやすい.....なw

もう少し簡単に言うと、
materialized view logの伝播が必要なデータ有無に関係なく、リフレッシュ時刻を跨いてしまうかどうか！　なんですよね、これ。

実際にどうなるか、materialized view logは空の状態で、Data Pumpも癖モノだよね〜w　その２ - Materialized ViewをTableとして移行する
の環境を利用して再現させてみます。環境の詳細は、Data Pumpも癖モノだよね〜w　その4 - schemaモードでMviewを他のPDBへ複製参照のこと。

VirtualBoxのスナップショットから基本レプリケーション環境構築済みの状態（以前いろいろ行った試験前の状態）に戻してあります。

まず、高速リフレッシュの状態がどうなっているか確認してみると....５分間隔（INTERVAL列）で動作中であることがわかりますよね！（DBMS_JOBのINTERVALの指定方法っ非直感的わかりづらいので早くなくなってほしいw）
直近の高速リフレッシュが終わり、MLOGも0件。つまりマテリアライズドビューに反映する必要のあるデータは存在しない状態にしてあります。

orcl@MVIEW_SCHEMA1> select job,log_user,schema_user,last_date,next_date,interval,failures,what from user_jobs;

       JOB LOG_USER             SCHEMA_USER          LAST_DATE           NEXT_DATE           INTERVAL               FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 09:00:44 2017/08/28 09:05:44 sysdate+5/1440                0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

前述の状態（5分間隔の高速リフレッシュが動作中の状態）で、次の高速リフレッシュが実行されるまでの間にマテリアライズドビュー関連オブジェクトを含むschemaを丸ごとエクスポートします（他のデータベースへ複製するために）
エラーを再現するData Pump Export、Importと高速リフレッシュ間隔との間合いは下図の通り

上図の通りの流れでData Pump ExportからImportまでを行い、ORA-12034の発生状況を確認

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Starting "SYSTEM"."SYS_EXPORT_SCHEMA_01":  system/********@orcl directory=workdir dumpfile=mview_schema1.dmp logfile=exp_mview_schema1.log schemas=mview_schema1 
Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 64 KB
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/DB_LINK
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/STATISTICS/MARKER
Processing object type SCHEMA_EXPORT/MATERIALIZED_VIEW
Processing object type SCHEMA_EXPORT/JOB
Processing object type SCHEMA_EXPORT/REFRESH_GROUP
. . exported "MVIEW_SCHEMA1"."MV_MASTER"                   5.5 KB       2 rows
Master table "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_SCHEMA_01 is:
  /u01/userhome/oracle/mview_schema1.dmp
Job "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully completed at Mon Aug 28 09:02:48 2017 elapsed 0 00:00:54

念のためマスターサイトでMLOGの件数を確認しておきます。
マテビューサイトと同期する必要のあるデータはないことが確認できます。

orcl@MASTER_SCHEMA> select count(*) from mlog$_master;

  COUNT(*)
----------
         0

という確認を行なっている間いに高速リフレッシュが実行されました！ （LAST_DATE列、NEXT_DATE列、FAILURES列から正常にリフレッシュされたことを確認できます）

orcl@MVIEW_SCHEMA1> select job,log_user,schema_user,last_date,next_date,interval,failures,what from user_jobs;
       JOB LOG_USER             SCHEMA_USER          LAST_DATE           NEXT_DATE           INTERVAL               FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 09:05:48 2017/08/28 09:10:48 sysdate+5/1440                0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

まず、異なるPDBにディレクトリオブジェクトを作成して、schemaごとインポートします。
この時点で以前のエントリにもあるようにORCL:master_schema.masterをマスターサイトするmviewが、ORCL:mview_schema1.mview_masterとORCL2:mview_schema1.mview_masterという構成になります。

orcl2@SYSTEM> create directory workdir as '/u01/userhome/oracle';

Directory created.


Starting "SYSTEM"."SYS_IMPORT_FULL_01":  system/********@orcl2 directory=workdir dumpfile=mview_schema1.dmp logfile=imp_mview_schema1.dmp 
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/DB_LINK
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
. . imported "MVIEW_SCHEMA1"."MV_MASTER"                   5.5 KB       2 rows
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/STATISTICS/MARKER
Processing object type SCHEMA_EXPORT/MATERIALIZED_VIEW
Processing object type SCHEMA_EXPORT/JOB
Processing object type SCHEMA_EXPORT/REFRESH_GROUP
Job "SYSTEM"."SYS_IMPORT_FULL_01" successfully completed at Mon Aug 28 10:02:09 2017 elapsed 0 00:00:22

インポートが無事終わったので、高速リフレッシュの状態を確認！！

おおおおおおおお〜〜、インポートしたschemaに含まれるMVIEWは高速リフレッシュに失敗しています。
なんということでしょうw（狙い通りなので、わざとらしいですねw）

なお、LAST_REF列がCOMPLETEという完全リフレッシュを示すステータスになっていますが、これはで確認下通り、昔からこんな動作だった曖昧な記憶があるので仕様だと思われますが、
インポート時に完全リフレッシュしているわけでもないのに、完全リフレッシュ扱いとされている紛らわしい状態になります。（このステータスが影響している可能性もありそうな...）

orcl2@MVIEW_SCHEMA1> @mview_info_c
Connected.

Session altered.

ROWNER               RNAME                  REFGROUP        JOB B INTERVAL             NEXT_DATE               CON_ID
-------------------- -------------------- ---------- ---------- - -------------------- ------------------- ----------
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+5/1440       2017/08/28 10:06:46          3
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+5/1440       2017/08/28 10:04:22          5


MVIEW_NAME                     REFRES REFRESH_ LAST_REF AFTER_FAST_REFRESH  COMPILE_STATE
------------------------------ ------ -------- -------- ------------------- -------------------
MV_MASTER                      DEMAND FAST     FAST     UNDEFINED           VALID
MV_MASTER                      DEMAND FAST     COMPLETE UNDEFINED           VALID


       JOB LOG_USER             SCHEMA_USER          LAST_DATE           NEXT_DATE           INTERVAL               FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 10:01:46 2017/08/28 10:06:46 sysdate+5/1440                0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1                            2017/08/28 10:04:22 sysdate+5/1440                1 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

高速リフレッシュのが実行され２度目の失敗、failusers列が２になっています。いずれ高速リフレッシュジョブは自動的に停止されます。
（自動停止される前に問題に対処すればそのまま継続されます）

orcl2@MVIEW_SCHEMA1> @mview_info_c
Connected.

Session altered.

ROWNER               RNAME                  REFGROUP        JOB B INTERVAL             NEXT_DATE               CON_ID
-------------------- -------------------- ---------- ---------- - -------------------- ------------------- ----------
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+5/1440       2017/08/28 10:08:26          5
MVIEW_SCHEMA1        MV_MASTER                    61         81 N sysdate+5/1440       2017/08/28 10:06:46          3


MVIEW_NAME                     REFRES REFRESH_ LAST_REF AFTER_FAST_REFRESH  COMPILE_STATE
------------------------------ ------ -------- -------- ------------------- -------------------
MV_MASTER                      DEMAND FAST     FAST     UNDEFINED           VALID
MV_MASTER                      DEMAND FAST     COMPLETE UNDEFINED           VALID


       JOB LOG_USER             SCHEMA_USER          LAST_DATE           NEXT_DATE           INTERVAL               FAILURES WHAT
---------- -------------------- -------------------- ------------------- ------------------- -------------------- ---------- ------------------------------------------------------------
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1        2017/08/28 10:01:46 2017/08/28 10:06:46 sysdate+5/1440                0 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');
        81 MVIEW_SCHEMA1        MVIEW_SCHEMA1                            2017/08/28 10:08:26 sysdate+5/1440                2 dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');

では、原因を調査してみましょう！

P列（POSSIBLE列）の　REFRESH_FAST行がNになっていて高速リフレッシュできない状態になっています。
コメントにはmv log is newer than last full refresh 記載されています。　このメッセージ冒頭で書いたメッセージと微妙に違うのですが、

orcl2@MVIEW_SCHEMA1> @?/rdbms/admin/utlxmv

Table created.

orcl2@MVIEW_SCHEMA1> exec dbms_mview.explain_mview('MV_MASTER','TEST01');

PL/SQL procedure successfully completed.

orcl2@MVIEW_SCHEMA1> SELECT mvname,capability_name,related_text,related_num,msgno,possible,msgtxt,seq FROM mv_capabilities_table;

MVNAME                         CAPABILITY_NAME                RELATED_TEXT         RELATED_NUM      MSGNO P MSGTXT                                                                                            SEQ
------------------------------ ------------------------------ -------------------- ----------- ---------- - ------------------------------------------------------------------------------------------ ----------
MV_MASTER                      PCT                                                                        N                                                                                                     1
MV_MASTER                      REFRESH_COMPLETE                                                           Y                                                                                                  1002
MV_MASTER                      REFRESH_FAST                                                               N                                                                                                  2003
MV_MASTER                      REWRITE                                                                    N                                                                                                  3004
MV_MASTER                      PCT_TABLE                      MASTER                        52       2068 N relation is not a partitioned table                                                              4005
MV_MASTER                      REFRESH_FAST_AFTER_INSERT      MASTER_SCHEMA.MASTER                   2077 N mv log is newer than last full refresh                           5006
MV_MASTER                      REFRESH_FAST_AFTER_ONETAB_DML                                         2146 N see the reason why REFRESH_FAST_AFTER_INSERT is disabled                                         6007
MV_MASTER                      REFRESH_FAST_AFTER_ANY_DML                                            2161 N see the reason why REFRESH_FAST_AFTER_ONETAB_DML is disabled                                     7008
MV_MASTER                      REFRESH_FAST_PCT                                                      2197 N PCT FAST REFRESH is not possible if query contains a remote table                                8009
MV_MASTER                      REWRITE_FULL_TEXT_MATCH        MASTER                        52       2099 N mv references a remote table or view in the FROM list                                            9010
MV_MASTER                      REWRITE_FULL_TEXT_MATCH                                               2159 N query rewrite is disabled on the materialized view                                               9011
MV_MASTER                      REWRITE_PARTIAL_TEXT_MATCH                                            2159 N query rewrite is disabled on the materialized view                                              10012
MV_MASTER                      REWRITE_GENERAL                                                       2159 N query rewrite is disabled on the materialized view                                              11013
MV_MASTER                      REWRITE_PCT                                                           2158 N general rewrite is not possible or PCT is not possible on any of the detail tables              12014
MV_MASTER                      PCT_TABLE_REWRITE              MASTER                        52       2068 N relation is not a partitioned table                                                             13015

15 rows selected.

試しに手動で高速リフレッシュさせてみます。

orcl2@MVIEW_SCHEMA1> exec dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"');
BEGIN dbms_refresh.refresh('"MVIEW_SCHEMA1"."MV_MASTER"'); END;

*
ERROR at line 1:
ORA-12034: materialized view log on "MASTER_SCHEMA"."MASTER" younger than last refresh
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2821
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 3058
ORA-06512: at "SYS.DBMS_IREFRESH", line 687
ORA-06512: at "SYS.DBMS_REFRESH", line 195
ORA-06512: at line 1

冒頭で説明した高速リフレッシュ時のエラーが発生していることがわかります。
そして、.......
このエラーが発生してしまうと、完全リフレッシュで回復させるしかありません！！！！！　

参考：
新規マテリアライズド・ビュー・サイトでの高速リフレッシュ・エラー

"新規マテリアライズド・ビュー・サイトでマテリアライズド・ビュー作成中に、マスター表またはマスター・マテリアライズド・ビューのマテリアライズド・ビュー・ログがパージされる場合があります。これが発生すると、次のエラーが検出される場合があります。

ORA-12004 REFRESH FAST cannot be used for materialized view materialized_view_name
ORA-12034 materialized view log on materialized_view_name younger than last refresh"

回避策として使えそうな方法は....
高速リフレッシュを停止して行う方法もあります（止められないシステムもあるので大人の事情しだいでしょうけど）
デプロイメントテンプレートで対応できそうな要件か十分検討、検証した上でやる必要があると思います。（完全リフレッシュするマテビューが巨大すぎて完全リフレッシュだけで作業時間オーバーなんてこともありえますから）

マニュアルに記載されている回避方法ってのもあるけど、手順がめんどくさい＞＜　な。　可能なら止めちゃった方が楽そうだが、大人の事情が絡んでるとそうもいかないだろうし、結局めんどくさいw
めんどくさいの嫌いなので試したこともないんだけど、時間があったら回避できるか試してみるか....な。

新規マテリアライズド・ビュー・サイトを追加するときの問題の回避

次回は、高速リフレッシュを跨がないように、したら回避できるよね。と言うお話へつづく
リフレッシュの間に終わらないとNGだけどw　、高速リフレッシュの間にexport/importが終わればこの問題は発生しない。。わけで。
次回のネタのイメージ（リフレッシュをまた跨らなければ例のエラーは発生しないという確認:）

---

Data Pumpも癖モノだよね〜w　その１ - queryパラメーターの解析タイミング

Data Pumpも癖モノだよね〜w　その２ - Materialized ViewをTableとして移行する

Data Pumpも癖モノだよね〜w　その3 - dbms_job と dbms_scheduler との複雑な関係

Data Pumpも癖モノだよね〜w　その4 - schemaモードでMviewを他のPDBへ複製

Data Pumpも癖モノだよね〜w　その4と1/2 - schemaモードでMviewを他のPDBへ複製 (紛らわしいステータスw）

Data Pumpも癖モノだよね〜w　その5 - schemaモードでMviewを他のPDBへ複製（オプジェクトパス de 絞り込み）

Data Pumpも癖モノだよね〜w　その6 - schemaモードでMviewを他のPDBへ複製（オプジェクトパスが不足すると...）

あまりにもネタになってないので、少しだけ sysresv のことを書いといた

共有メモリやセマフォセットの数などの確認は、ipcsでほぼ足りてるわけですが。（複数インスタンスが起動している場合を除く）
あまりにもネタになってないので、少しだけ　sysresvのことを書いといた:)

[oracle@vbgeneric ˜]$ sysresv

IPC Resources for ORACLE_SID "orcl12c" :
Maximum shared memory segment size (shmmax): 4398046511104 bytes
Total system shared memory (shmall): 4398046511104 bytes
Total system shared memory count (shmmni): 4096
*********************** Dumping ipcs output ********************

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 0          oracle     600        8802304    173                     
0x00000000 32769      oracle     600        822083584  87                      
0x00000000 65538      oracle     600        7974912    87                      
0x21485470 98307      oracle     600        16384      87                      
0x00000000 262148     oracle     600        524288     2          dest         
0x00000000 294917     oracle     600        4194304    2          dest         
0x00000000 393222     oracle     600        33554432   2          dest         
0x00000000 491527     oracle     600        4194304    2          dest         
0x00000000 524296     oracle     600        1048576    2          dest         

------ Semaphore Arrays --------
key        semid      owner      perms      nsems     
0x245b195c 163840     oracle     600        152       
0x245b195d 196609     oracle     600        152       
0x245b195e 229378     oracle     600        152       

*********************** End of ipcs command dump **************


***************** Dumping Resource Limits(s/h) *****************
core file size                         0 KB/UNLIMITED         
data seg size                     UNLIMITED/UNLIMITED         
scheduling priority                    0 KB/0 KB              
file size                         UNLIMITED/UNLIMITED         
pending signals                       30 KB/30 KB             
max locked memory                    128 GB/128 GB            
max memory size                   UNLIMITED/UNLIMITED         
open files                            64 KB/64 KB             
POSIX message queues                 800 KB/800 KB            
real-time priority                     0 KB/0 KB              
stack size                            32 MB/32 MB             
cpu time                          UNLIMITED/UNLIMITED         
max user processes                    16 KB/16 KB             
virtual memory                    UNLIMITED/UNLIMITED         
file locks                        UNLIMITED/UNLIMITED         

***************** End of Resource Limits Dump ******************
Maximum map count configured per process:  65530
Total /dev/shm size: 4050014208 bytes, used: 98304 bytes
Shared Memory:
ID		KEY
32769   	0x00000000
65538   	0x00000000
0       	0x00000000
98307   	0x21485470
Semaphores:
ID		KEY
163840  	0x245b195c
196609  	0x245b195d
229378  	0x245b195e
Oracle Instance alive for sid "orcl12c"
[oracle@vbgeneric ˜]$ 

[oracle@vbgeneric ˜]$  ipcs -sb

------ Semaphore Arrays --------
key        semid      owner      perms      nsems     
0x245b195c 163840     oracle     600        152       
0x245b195d 196609     oracle     600        152       
0x245b195e 229378     oracle     600        152       

[oracle@vbgeneric ˜]$  ipcs -st

------ Semaphore Operation/Change Times --------
semid    owner      last-op                    last-changed              
163840   oracle      Tue May  2 01:35:32 2017   Tue May  2 01:26:30 2017  
196609   oracle      Not set                    Tue May  2 01:26:30 2017  
229378   oracle      Tue May  2 01:26:35 2017   Tue May  2 01:26:30 2017  

pivotとSQL*PlusとSETコマンドと #2

昨日の続きですw

v$sys_time_modelの列データを行データへpivotで変換し、かつシェルで定期的に取得してみたものの、出力形式は今ひとつ。　iostatやvmstatのように出力したい。

前回のエントリーの出力結果は以下の通りでした。

[oracle ˜]$ ./sample.sh

SQL*Plus: Release 12.1.0.2.0 Production on 日 8月 17 21:10:47 2014

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


Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
に接続されました。
21:10:48 SCOTT> 
                        DB_TIME                          DB_CPU                         BG_TIME                          BG_CPU
------------------------------- ------------------------------- ------------------------------- -------------------------------
                       66172667                         7714783                       127809578                        27114874

経過: 00:00:00.02
21:10:48 SCOTT>
                        DB_TIME                          DB_CPU                         BG_TIME                          BG_CPU
------------------------------- ------------------------------- ------------------------------- -------------------------------
                       66179178                         7720782                       128085853                        27160868

経過: 00:00:00.01
21:10:57 SCOTT>
                        DB_TIME                          DB_CPU                         BG_TIME                          BG_CPU
------------------------------- ------------------------------- ------------------------------- -------------------------------
                       66180864                         7723782                       128249102                        27197862

経過: 00:00:00.00 

じゃまな出力は、以下の通り

• SQL*Plusのプロンプト
• ヘッダー行
• 経過時間
• 出力の状態から見て、余分な改行

そして、不足している出力はメトリックのログ取得時のタイムスタンプ

以下のSQL*Plusシステム変数を調整追加すればなんとかなりそうな感じ。。。。

• SQL*Plusのプロンプトは、　set sqlp ""　で抑止。
• ヘッダー行は、 set head off で抑止
• 経過時間は、　set timi off で抑止
• 余分な改行は、 たぶん、　set newp none で抑止
• 直接関係ないけど、Excelにコピペするときにじゃまになるので set tab offでタブの混入抑止

不足しているログ取得時のタイムスタンプは、シェルのdateコマンドで取得した日時をSQL文に埋め込むことでなんとかなりそうな気がします。

と頭に浮かんだら忘れないうちに試してみますよ〜

★横に長くてごめんなさい。時間取れたらSyntaxHighlighterとか入れます詐欺 m(_ _)m

#!/bin/bash
#
(
echo "conn scott/tiger"
echo "set timi off time off tab off sqlp \"\" head off newp none"
echo "col db_time for 999999999999999999999999999999"
echo "col db_cpu for 999999999999999999999999999999"
echo "col bg_time for 999999999999999999999999999999"
echo "col bg_cpu for 999999999999999999999999999999"
while [ 1 ] 
do
        echo "SELECT db_time,db_cpu,bg_time,bg_cpu FROM (SELECT stat_name,value FROM v\$sys_time_model) PIVOT (MAX(value) FOR stat_name IN ('DB time' AS db_time,'DB CPU' AS db_cpu,'background elapsed time' AS bg_time,'background cpu time' AS bg_cpu));"
        sleep 10
done
) | sqlplus /nolog

ん〜〜〜〜〜、なんか、惜しい！！！！　　いい感じにななったのに。... しばし考える。。。。

[oracle ˜]$ ./sample.sh

SQL*Plus: Release 12.1.0.2.0 Production on 日 8月 17 21:45:43 2014

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

21:45:43 > 接続されました。
21:45:44 SCOTT>                        67126005                         8476651                       182158980                        37408311

                       67129138                         8479651                       182310474                        37445305

きた〜〜〜、神が降りてきたのでちょっと書き換えた

#!/bin/bash
#
(
echo "conn scott/tiger"
echo "set timi off time off sqlp \"\""
echo "col db_time for 999999999999999999999999999999"
echo "col db_cpu for 999999999999999999999999999999"
echo "col bg_time for 999999999999999999999999999999"
echo "col bg_cpu for 999999999999999999999999999999"
while [ 1 ] 
do
	t=`date +'%DT%T'`
        echo "SELECT SUBSTR('${t}',1,INSTR('${t}','T')-1) as logged_date,SUBSTR('${t}',INSTR('${t}','T')+1) as logged_time,db_time,db_cpu,bg_time,bg_cpu FROM (SELECT stat_name,value FROM v\$sys_time_model) PIVOT (MAX(value) FOR stat_name IN ('DB time' AS db_time,'DB CPU' AS db_cpu,'background elapsed time' AS bg_time,'background cpu time' AS bg_cpu));"
	echo "set head off newp none"
        sleep 10
done
) | sqlplus /nolog

ん〜〜〜、まだ余計な改行というか空行がある。。。なんだこれ。。。。再び、考え中........ あ、あれだ！　出力行数を返すやつ！

SQL*Plus: Release 12.1.0.2.0 Production on 日 8月 17 21:56:21 2014

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

21:56:21 > 接続されました。
21:56:22 SCOTT> 
LOGGED_D LOGGED_T                         DB_TIME                          DB_CPU                         BG_TIME                          BG_CPU
-------- -------- ------------------------------- ------------------------------- ------------------------------- -------------------------------
08/17/14 21:56:21                        67688748                         8937570                       198751230                        40650823

08/17/14 21:56:31                        67695983                         8945569                       199012673                        40699815

で、できたのがこれ。

#!/bin/bash
#
(
echo "conn scott/tiger"
echo "set timi off time off sqlp \"\" feed off"
echo "col db_time for 999999999999999999999999999999"
echo "col db_cpu for 999999999999999999999999999999"
echo "col bg_time for 999999999999999999999999999999"
echo "col bg_cpu for 999999999999999999999999999999"
while [ 1 ] 
do
	t=`date +'%DT%T'`
        echo "SELECT SUBSTR('${t}',1,INSTR('${t}','T')-1) as logged_date,SUBSTR('${t}',INSTR('${t}','T')+1) as logged_time,db_time,db_cpu,bg_time,bg_cpu FROM (SELECT stat_name,value FROM v\$sys_time_model) PIVOT (MAX(value) FOR stat_name IN ('DB time' AS db_time,'DB CPU' AS db_cpu,'background elapsed time' AS bg_time,'background cpu time' AS bg_cpu));"
	echo "set head off newp none"
        sleep 10
done

) | sqlplus /nolog

出力結果は以下のようになり、 iostatやvmstat風にヘッダー行は一度だけ、その後、定期的に取得されるメトリックが出力されていくイメージに！ :)

[oracle ˜]$ ./sample.sh

SQL*Plus: Release 12.1.0.2.0 Production on 日 8月 17 22:02:59 2014

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

22:02:59 > 接続されました。
22:02:59 SCOTT> 
LOGGED_D LOGGED_T                         DB_TIME                          DB_CPU                         BG_TIME                          BG_CPU
-------- -------- ------------------------------- ------------------------------- ------------------------------- -------------------------------
08/17/14 22:02:59                        68026469                         9252517                       211057107                        42641516
08/17/14 22:03:09                        68034074                         9261515                       211217278                        42686507
08/17/14 22:03:19                        68039874                         9267514                       211414489                        42730501
08/17/14 22:03:29                        68045221                         9272514                       211576132                        42769498
08/17/14 22:03:39                        68051396                         9276513                       211844118                        42862480
^C
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing optionsとの接続が切断されました。

Enjoy!

---

・pivotとSQL*PlusとSETコマンドと

pivotとSQL*PlusとSETコマンドと

Oracle Databaseの性能試験で以下のようなメトリックを定期取得して、分析やビジュアライズに利用している方も多いと思います。（思ってます。）
でも、ですねぇ。
以下のv$sys_time_model動的パフォーマンスビューも典型例なのですが、列持ちのメトリックが多いので集計にはかなり苦労します。というか、してます。

v$sys_time_model動的パフォーマンスビューの出力例）

SCOTT> SELECT stat_name, value from v$sys_time_model;

STAT_NAME                                                             VALUE
---------------------------------------------------------------- ----------
DB time                                                            64073868
DB CPU                                                              6549986
background elapsed time                                            42988476
background cpu time                                                11080311

・・・以下略・・・

列持ちなんですよね、　列持ち！（しつこいw

行持ちにしたいですよね。　どう料理しましょう。　まさか、手作業ではやってないですよね。

SQL文でやってますよね！　私もそうです。
ちなみに、UNION連打はしてませんからね！（キリっ！

昔はほかに手がなかったのですが、Oracle11gから便利で比較的読みやすい構文がサポートされています。

列持ちを行持ちにするといえば....そうです、あれです。 pivot

ということで、

pivotを使って、v$sys_time_modelを例にオレオレv$sys_time_modelを作り出してみます。
（これができれば、数あるオラクルの動的パフォーマンスビューをもっと好きになれるんじゃないかなぁ。と思います。）

では、早速

v$sys_time_modelの stat_name列の列値が、'DB time'、'DB CPU'、 'background elapsed time'、'background cpu time'の４つのメトリックを列持ちから行持ちに変え、オレオレv$sys_time_model作り出すSQL文です。
ビューは作りませんけど (^^;;;

SELECT 
	db_time
	,db_cpu
	,bg_time
	,bg_cpu 
FROM 
	(
		SELECT 
			stat_name
			,value 
		FROM 
			v$sys_time_model
	) 
PIVOT 
	(
		MAX(value) 
		FOR stat_name IN 
			(
				'DB time' AS db_time
				,'DB CPU' AS db_cpu
				,'background elapsed time' AS bg_time
				,'background cpu time' AS bg_cpu
			)
	)
;

これを実行すると以下のような結果になります。本来４行なのですが、１行にできるんです！ 便利ですね。 pivot （pivotの逆の操作をする unpivotもあります）

   DB_TIME     DB_CPU    BG_TIME     BG_CPU
---------- ---------- ---------- ----------
  63895360    6364016   32965031    8718671

いい感じになってきました。

しかし、まだ物足りないですよね。　そう！
取得時のタイムスタンプとか、例えば iostat や vmstatのように定期的に取得したくなってきます！！！！

「門外不出のOracle現場ワザ」　第5章　DBアクセスの空白地帯 コネクションプーリングを極めるの定期的にSQLを発行するシェルを作成するには？　でも解説されているのでこの方法で取得されている方も多いと思います。:)

ただ、そのまんまだと以下のような出力になってしまいます。 iostatやvmstatの出力をイメージしちゃうと余分な表示が多いわけです。

[oracle ˜]$ ./sample.sh

SQL*Plus: Release 12.1.0.2.0 Production on 日 8月 17 21:10:47 2014

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


Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
に接続されました。
21:10:48 SCOTT> 
                        DB_TIME                          DB_CPU                         BG_TIME                          BG_CPU
------------------------------- ------------------------------- ------------------------------- -------------------------------
                       66172667                         7714783                       127809578                        27114874

経過: 00:00:00.02
21:10:48 SCOTT>
                        DB_TIME                          DB_CPU                         BG_TIME                          BG_CPU
------------------------------- ------------------------------- ------------------------------- -------------------------------
                       66179178                         7720782                       128085853                        27160868

経過: 00:00:00.01
21:10:57 SCOTT>
                        DB_TIME                          DB_CPU                         BG_TIME                          BG_CPU
------------------------------- ------------------------------- ------------------------------- -------------------------------
                       66180864                         7723782                       128249102                        27197862

経過: 00:00:00.00 

前述の出力は以下のコードで取得したのですが、実はそんなに手を加えなくても vmstatやiostatのような出力形式で、みなさんの大好きなExcelで集計しやすくすることができるんですよ。
どこを変更すればよいか分かった人、手を挙げて〜〜〜〜っ!

注）scottユーザにselect any dictionaryシステム権限付けてます。

#!/bin/bash
#
(
echo "conn scott/tiger"
echo "set timi on time on"
echo "col db_time for 999999999999999999999999999999"
echo "col db_cpu for 999999999999999999999999999999"
echo "col bg_time for 999999999999999999999999999999"
echo "col bg_cpu for 999999999999999999999999999999"
while [ 1 ] 
do
        echo "SELECT db_time,db_cpu,bg_time,bg_cpu FROM (SELECT stat_name,value FROM v\$sys_time_model) PIVOT (MAX(value) FOR stat_name IN ('DB time' AS db_time,'DB CPU' AS db_cpu,'background elapsed time' AS bg_time,'background cpu time' AS bg_cpu));"
        sleep 10
done
) | sqlplus /nolog

つづきは、次のエントリーで :)

Difference of Initialization Parameters between 11g and 12c #2

以前、11gと12cの初期化パラメータ数を比較したエントリーを書いたのですが、12c R1も 12.1.0.1.0と12.1.0.2.0でまたまた大きく変わっているようだったので調べてみた。

Oracle Database 11g R1 11.1.0.6.0
Oracle Database 11g R2 11.2.0.1.0
Oracle Database 12c R1 12.1.0.1.0
上記に加え、先日リリースされた Oracle database 12c R1 12.1.0.2.0　を加え、とりあえずパラメータ数だけを比較しました。　（差分はまた別途 TODO)

今回も隠しパラメータの増加が目立ちます。(@@)

11.1.0.6.0から11.2.0.1.0で302個の隠しパラメータが増加、
11.2.0.1.0から12.1.0.1.0で926個の隠しパラメータが増加、
そして今回、 12.1.0.1.0から12.1.0.2.0で612個の隠しパラメータが増加し、
11g R2と 12c R1の単純な比較では1500個以上の隠しパラメータが増加している。

これらの隠しパラメータの中で、有名人になるパラメータは登場するのかしないのか...
今後のお楽しみは尽きないわけですが。。。それにしてもすごい増加量、ですよね。

---

・Difference of Initialization Parameters between 11g r1 (11.1.0.6.0) and 12c r1 (12.1.0.1.0) - including hidden params

シーケンス.NEXTVALが使えないからぐるぐる〜〜〜っとしていいですか？ （30歳 エンジニア 男性）

CREATE TABLE 〜　AS SELECT文でシーケンス.NEXTVALって使えないからぐるぐる〜〜〜っとしたループ処理しないといけないですよね〜。

と質問されたのですが、１文で書けますからね！
（SQL文でワンライナーって言いそうになったけど、飲み込んだw)

準備

SCOTT> l
  1  CREATE TABLE table_foobar
  2  (
  3  	id NUMBER PRIMARY KEY
  4  	,data VARCHAR2(10)
  5* )
SCOTT> /

表が作成されました。

SCOTT> l
  1  INSERT INTO table_foobar
  2  	SELECT
  3  		LEVEL
  4  		,'D'||TO_CHAR(LEVEL,'FM099999999')
  5  	FROM
  6  		dual
  7  	CONNECT BY
  8* 		LEVEL <= 100.
SCOTT> /

100行が作成されました。

SCOTT> commit;

コミットが完了しました。

SCOTT> SELECT * FROM table_foobar ORDER BY id;

        ID DATA
---------- ----------
         1 D000000001
         2 D000000002
         3 D000000003
         4 D000000004
         5 D000000005
         6 D000000006
         7 D000000007
         8 D000000008
         9 D000000009
        10 D000000010

　　　...中略...

        90 D000000090
        91 D000000091
        92 D000000092
        93 D000000093
        94 D000000094
        95 D000000095
        96 D000000096
        97 D000000097
        98 D000000098
        99 D000000099
       100 D000000100

100行が選択されました。

前述のデータを複製しtable_foobar_tmp表を作成するとします。
なお、DATA列はそのままで、ID列は、次のシーケンスを利用してID = 1..100の順にシーケンスから採番しなおしたい。
（以下のシーケンスの定義からすると、 ID=1 は、1000、 ID=2は、1001にしたい。）

SCOTT> CREATE SEQUENCE seq_foobar start with 1000 maxvalue 999999999;

順序が作成されました。

１文で書けますよね!

SCOTT> l
  1  CREATE TABLE table_foobar_tmp
  2  AS
  3  	SELECT
  4  		seq_foobar.NEXTVAL AS id
  5  		,t01.data
  6  	FROM
  7  		(
  8  			SELECT
  9  				id
 10  				,data
 11  			FROM
 12  				table_foobar
 13  			ORDER BY
 14  				id
 15* 		) t01
SCOTT> /

表が作成されました。

SCOTT> SELECT * FROM table_foobar_tmp ORDER BY ID;

        ID DATA
---------- ----------
      1000 D000000001
      1001 D000000002
      1002 D000000003
      1003 D000000004
      1004 D000000005
      1005 D000000006
      1006 D000000007
      1007 D000000008
      1008 D000000009
      1009 D000000010
      1010 D000000011

　　　...中略...

      1090 D000000091
      1091 D000000092
      1092 D000000093
      1093 D000000094
      1094 D000000095
      1095 D000000096
      1096 D000000097
      1097 D000000098
      1098 D000000099
      1099 D000000100

100行が選択されました。

はい、できました！

マニュアルには、「NEXTVALへの参照が含まれる単一のSQL文の中では、Oracleは、次の各行につき1回順序を増加させます。」
と記載されているので、質問してきた方は、マニュアルを読んでいないか、マニュアル読んでなくても実際に試していない食わず嫌い状態だったか、
以下のようなシーケンスの制限に遭遇して、できないんだ！と思い込んでしまった。

病は気からという状態だったのでしょうね。:)

SCOTT> l
  1  CREATE TABLE table_foobar_tmp_NG
  2  AS
  3      SELECT
  4          seq_foobar.NEXTVAL AS ID
  5          ,t01.data
  6      FROM
  7      	table_foobar t01
  8      ORDER BY
  9*     	t01.id
SCOTT> /
        seq_foobar.NEXTVAL AS ID
                   *
行4でエラーが発生しました。:
ORA-02287: ここでは順序番号は使用できません。

エラーメッセージを見ても、Action がRemove the sequence numberだけですからね....

SCOTT> !oerr ORA 2287
02287, 00000, "sequence number not allowed here"
// *Cause: The specified sequence number (CURRVAL or NEXTVAL) is inappropriate
//	  here in the statement.
// *Action: Remove the sequence number.

そんな時はマニュアルを..
Oracle® Database SQL言語リファレンス 11gリリース2 (11.2) 順序疑似列

順序値の使用方法には、CREATE TABLE ... AS SELECTで使用できると書いてるのに。なんでだろう？
と,、なるかもしれないですが、よ〜〜〜くマニュアルを読んでくださいよ〜っ。

順序値の制限事項にGROUP BY句やORDER BY句を持つSELECT文では使用できないとも書かれているところにちゅうも〜〜〜〜く！

ORDER BY句を含んでいるのでORA-02287回避のために、サブクエリにして別クエリブロック化、シーケンスを利用しているクエリブロックにはORDER BY句を含まないようにしているところがポイント :)

テストデータ作るときとか、知ってると便利ですよ〜と。

SCOTT> l
  1  CREATE TABLE table_foobar_tmp
  2  AS
  3  	SELECT
  4  		seq_foobar.NEXTVAL AS id
  5  		,t01.data
  6  	FROM
  7  		(
  8  			SELECT
  9  				id
 10  				,data
 11  			FROM
 12  				table_foobar
 13  			ORDER BY
 14  				id
 15* 		) t01
SCOTT> /

Enjoy SQL!

SELECT ~ FOR UPDATE SKIP LOCKED その4 - もしもITL不足だったら...

skip lockedのつづきです。

ITLエントリー不足時のskip lockedの動きを確認してみるか....

100行が1ブロックに収まるような表を作成しておく...計算上、ITLエントリーは最大で4エントリー程度になるように....したつもり....
（ASSMで、INITRANSはデフォルト、ブロックサイズは8KB、PCTFREEは0%）

SCOTT@pdborcl> r
  1  select
  2      objectid
  3      ,file#
  4      ,block#
  5      ,count(id) as num_of_rows
  6  from
  7  (
  8      select
  9           dbms_rowid.rowid_object(rowid) as objectid
 10          ,dbms_rowid.rowid_relative_fno(rowid) as file#
 11          ,dbms_rowid.rowid_block_number(rowid) as block#
 12          ,id
 13      from
 14          q
 15  )
 16  group by
 17      objectid
 18      ,file#
 19      ,block#
 20  order by
 21      objectid
 22      ,file#
 23*     ,block#

  OBJECTID      FILE#     BLOCK# NUM_OF_ROWS
---------- ---------- ---------- -----------
     93077          9     972461         100

※セッション１ - lockできた

SESSION1@pdborcl> select * from q where id = '0001' for update;

ID
----
TEXT_STRING
----------------------------------------------------------------------
0001
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション２ - lockできた。 この時点で 1 + 1 = 2 のITLエントリは使い切っている。

SESSION2@pdborcl> select * from q where id = '0002' for update;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0002
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション３ - lockできた。　ITLがブロック内の空きスペースに作れたため :)

SESSION3@pdborcl> select * from q where id = '0003' for update;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0003
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション４ - 計算上のITLエントリー数の上限値. 問題なくlockできた。

SESSION4@pdborcl> select * from q where id = '0004' for update;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0004
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション５ - 狙い通り！　５つめのITLエントリーを作成するだけの空きがブロック内にない状況なので待機しちゃう :)

SESSION5@pdborcl> select * from q where id = '0005' for update;

待機イベント見れば一目瞭然、ITLエントリー不足で待機してますね！

SYS@pdborcl> select username,event from v$session where username = 'SCOTT'

USERNAME   EVENT
---------- ----------------------------------------
SCOTT      SQL*Net message from client
SCOTT      SQL*Net message from client
SCOTT      enq: TX - allocate ITL entry
SCOTT      SQL*Net message from client
SCOTT      SQL*Net message from client

ここまでは、ITL不足な状況のfor update文ではよく見かける光景ですよね :)

for update skip lockedにすると.....

※セッション１ - locked!

SESSION1@pdborcl> select * from q where id = '0001' for update skip locked;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0001
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション２ - locked!!

SESSION2@pdborcl> select * from q where id = '0002' for update skip locked;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0002
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション３　- locked!!!

SESSON3@pdborcl> select * from q where id = '0003' for update skip locked;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0003
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション４ - locked!!!!

SESSION4@pdborcl> select * from q where id = '0004' for update skip locked;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0004
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション５（ITLエントリーが確保できず id = '0005'の行をlockすることができないので空振りします。興味深い動きですよね。)

SESSION5@pdborcl> select * from q where id = '0005' for update skip locked;

レコードが選択されませんでした。

次回へつづく.....かもしれない。

---

・SELECT ~ FOR UPDATE SKIP LOCKED　その１ - @sh2ndさんエントリの復習など
・SELECT ~ FOR UPDATE SKIP LOCKED　その２
・SELECT ~ FOR UPDATE SKIP LOCKED　その３

SELECT ~ FOR UPDATE SKIP LOCKED その3

skip lockedのつづきです。

skip lockedの特徴を確認しておきますか！

skip lockedはロックの獲得ができた行だけをロック待機なしで返してくれる :)
IDが'0001', '0002', '0003', '0005'の行をロックしておく。

SESSION1@pdborcl> select id from q where id in ('0001', '0002', '0003', '0005') for update skip locked;

ID
----
0001
0002
0003
0005

IDが '0001','0002','0003'の行は先行のトランザクションで既にロックされているため、ロックできた行だけがロック待機なしで返される。

SESSION2@pdborcl> select id from q where id in ('0001', '0002', '0003', '0004', '0005', '0006') for update skip locked;

ID
----
0004
0006

もちろん、ロックできる行が１行もなければロックを待機せず空振！

SESSION3@pdborcl> select id from q where id in ('0001', '0002', '0003') for update skip locked;

レコードが選択されませんでした。

つづく。

---

・SELECT ~ FOR UPDATE SKIP LOCKED　その１ - @sh2ndさんエントリの復習など
・SELECT ~ FOR UPDATE SKIP LOCKED　その２

SELECT ~ FOR UPDATE SKIP LOCKED その２

つづきです。

そういえば、skip lockedって構文がマニュアルでは解説されていないリリースででふつーーーーに、使われててビビったことあったな。
(マニュアルに書かれていないリリースでは、自己責任使ってねw)

・Oracle12c R1 - SKIP LOCKED
http://docs.oracle.com/cd/E49329_01/server.121/b71278/statements_10002.htm#SQLRF55374

・Oracle11g R2 - (skip locked、推奨事項などが追記された）
http://docs.oracle.com/cd/E16338_01/server.112/b56299/statements_10002.htm#i2126016

・Oracle11g R1 - (skip locked登場）
http://otndnld.oracle.co.jp/document/products/oracle11g/111/doc_dvd/server.111/E05750-03/statements_10.htm#7292

・Oracle10g R2 (ここまでのマニュアルにはskip lookedは記載されていない。AQがらみで使われていたのは確かだ....)
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/server.102/B19201-02/statements_10.html#6799

どのあたりのバージョンから登場していたのかはJonathan Lewisさんのブログからたどれば分かると思うよ...
http://jonathanlewis.wordpress.com/2010/05/31/skip-locked/

Oracle11g R2のドキュメントからは以下のような追記されている。

「この機能は、Oracle Streams Advanced Queuingなどのマルチコンシューマ・キュー環境で使用するために設計されています。
　キュー・コンシューマは、他のコンシューマによってロックされた行はスキップして未ロックの行を取得できるので、
　他のコンシューマの操作が終了するまで待つ必要はなくなります。
　SKIP LOCKED機能を直接使用するかわりに、Oracle Streams Advanced Queuing APIを使用することをお薦めします。」

と。

以下のリリースで確認したが skip lockedに関して動作の差は無いようだ。
2013/1/5追記
動作の差は無いようだ、とは書いたが、結果オーライってことでございます。内部動作までは見えないので（キリつ
・Oracle11g R1 11.1.0.7.0
・Oracle11g R2 11.2.0.1.0
・Oracle11g R2 11.2.0.2.0
・Oracle12c R1 12.1.0.1.0

※セッション１
SESSION1> select * from q order by id;

	ID DATA
---------- ----------
	 1 a
	 2 b
	 3 c

※セッション１
SESSION1>  SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE SKIP LOCKED;

	ID DATA
---------- ----------
	 1 a

			※セッション２
			SKIP LOCKEDなのでしようとしていたレコードがロックできなければ空振りし、ロック獲得を待機しません
			SESSION2>  SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE SKIP LOCKED;

			レコードが選択されませんでした。


※セッション１
SESSION1> DELETE FROM q WHERE id = 1;

1行が削除されました。

			※セッション２
			何度やっても同じですよね :)
			SESSION2>  SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE SKIP LOCKED;

			レコードが選択されませんでした。


※セッション１
SESSION1> COMMIT;

コミットが完了しました。

SESSION1> 

			※セッション２
			ここで初めて、対象レコードがロックできます！
			マルチコンシューマ・キュー環境向けって意味がよ〜〜〜〜く分かる動きだと思います
			SESSION2>  SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE SKIP LOCKED;

				ID DATA
			---------- ----------
				 2 b

skip lockedって面白いよね。

skip lockedの特徴について、もう少し書く予定、多分、来年へつづく。。。。。

みなさま、良いお年を！

---

・SELECT ~ FOR UPDATE SKIP LOCKED　その１ - @sh2ndさんエントリの復習など

SELECT ~ FOR UPDATE SKIP LOCKED その１ - @sh2ndさんのエントリの復習など

JPOUT Advent Calender 2013の@sh2ndさんのエントリーが面白かったので大晦日に酒飲みながら... :)
まずは twitterでのやり取りなど....

イケテナイとか、良いとか、自由に言えるのはユーザーだからこそだと思うんだ。
セールストークじゃない生の情報って大切だ。

ということで、skip locked へ行く前に、Oracle11g R1 11.1.0.7.0 および、Oracle12c R1 12.1.0.1.0 で @sh2ndさんのエントリーの復習から :)

※セッション１
SESSION1> select * from q order by id;

        ID DATA
---------- ----------
         1 a
         2 b
         3 c

※セッション１
SESSION1> SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE;

        ID DATA
---------- ----------
         1 a

				※セッション２
				SESSION2> SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE;
				（ここで待たされる。待つことは正しい動き）

※セッション１
SESSION1> DELETE FROM q WHERE id = 1;

1行が削除されました。

※セッション１
SESSION1> commit;

コミットが完了しました。

SESSION1> 

				※セッション２はここでロックを獲得できる。
						        		ID DATA
				---------- ----------
				         2 b

				SESSION2> 

Oracle11g R2 11.2.0.1.0とOracle11g R2 11.2.0.2.0は、Wrong Resultだったんだと思うが...

※セッション１
SESSION1> select * from q order by id;

	ID DATA
---------- ----------
	 1 a
	 2 b
	 3 c

※セッション１
SESSION1> SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE;

	ID DATA
---------- ----------
	 1 a

				※セッション２
				SESSION2> SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE;
				(ここで待たされる。というところまでは同じ）


※セッション１
SESSION1> DELETE FROM q WHERE id = 1;

1行が削除されました。

※セッション１
SESSION1> COMMIT;

コミットが完了しました。

SESSION1> 

				※セッション２ (注１
				（しか〜〜〜し、なんとレコードが選択されませんでした！！！！！）
				レコードが選択されませんでした。

				SESSION2> 

結果

Oracle	READ COMMITTED
11.1.0.7.0	ID=2を取得
11.2.0.1.0	空振り
11.2.0.2.0	空振り
12.1.0.1.0	ID=2を取得

注１）
Oracle11g 11.2.0.3.0以降では修正されているとのこと...(私は手持ちのが無かったので未確認...だれか書いてw)

SELECT ~ FOR UPDATE SKIP LOCKEDへつづく...

db tech showcase tokyo 2013 - A35 - JPOUG特濃：潮溜まりでジャブジャブ、SQLチューニング

11/13〜15に開催されたdb tech showcase tokyo 2013 の最終日、午後の４枠で特濃JPOUGとてセッションを行いました。

貴重な機会を提供いただいたインサイトテクノロジーの皆様ありがとうございました。
また、お忙しい中、セッションに参加してくださった皆様、ありがとうございました。

A35
15:00-15:45 / 「JPOUG特濃：潮溜まりでジャブジャブ、SQLチューニング」 のセッション資料を公開しました。

塩分濃いめの潮溜まりで釣り上げたSQLは治療できるかどうかもわからない病になっていました….
治療できたか、できなかったのか……

曲者すぎる難病もありますが、何かの機会に思い出していただければと思います。

みなさん、楽しい時間をありがとう。

db tech showcase Tokyo 2013 - A35 特濃JPOUG：潮溜まりでジャブジャブ、SQLチューニング from Hiroshi Sekiguchi

オプティマイザをだましちゃお！ （マジック・ザ・ギャザリング風w かも)

ということで、準備から。なにやら索引がいるのか怪しい列にまでBツリー索引を作成しちゃってます ;)

23:34:03 SYS> conn scott/tiger
接続されました。
23:36:01 SCOTT> 
23:36:01 SCOTT> 
23:36:01 SCOTT> create table deluding_tab (id number not null, status number(2) not null, data varchar2(500)) nologging;

表が作成されました。

23:50:47 SCOTT> begin for i in 1..100000 loop insert into deluding_tab values(i,0,lpad(i,500,'*')); end loop; end;
23:55:22   2  /

PL/SQLプロシージャが正常に完了しました。

23:55:27 SCOTT> commit;

コミットが完了しました。

23:55:31 SCOTT> alter table deluding_tab add constraint pk_deluding_tab primary key (id) using index nologging;

表が変更されました。

23:56:07 SCOTT> create index ix_deluding_tab on deluding_tab(status) nologging;

索引が作成されました。

23:58:26 SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'DELUDING_TAB', -
23:58:34 > no_invalidate=>false,cascade=>true,method_opt=>'FOR ALL COLUMNS SIZE AUTO');

PL/SQLプロシージャが正常に完了しました。

ヒストグラムの状態も見ておきましょ。

TABLE_NAME                     COLUMN_NAME                    NUM_BUCKETS HISTOGRAM
------------------------------ ------------------------------ ----------- ---------------
DELUDING_TAB                   ID                             1           NONE
DELUDING_TAB                   STATUS                         1           NONE
DELUDING_TAB                   DATA                           1           NONE

登録したデータ件数も見ておきましょうか。

00:03:27 SCOTT> 
00:08:41 SCOTT> select count(1) from deluding_tab;

  COUNT(1)
----------
    100000

では、オプティマイザとデュエル！

アンタップ、アップキープ、ドロー！　

00:03:54 SCOTT> select * from deluding_tab where status = 1;

レコードが選択されませんでした。

経過: 00:00:00.01

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

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

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

   2 - access("STATUS"=1)


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

データはヒットしていないですね。索引レンジスキャンは妥当な実行計画:)

お〜〜っと、ここで、インスタント!　全データをヒント無しで、索引レンジスキャン！

ちなみに、遊戯王ばかりで、マジック・ザ・ギャザリングをしらない、最近の子の為に解説しておくと、フラッシュタイミングで使うカードと似たような使い方をするカードのことだぉ

00:07:27 SCOTT> select * from deluding_tab where status = 2;

100000行が選択されました。

経過: 00:00:02.32

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

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

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

   2 - access("STATUS"=2)


統計
----------------------------------------------------------
       1  recursive calls
       0  db block gets
   20166  consistent gets
       0  physical reads
       0  redo size
53229491  bytes sent via SQL*Net to client
   73846  bytes received via SQL*Net from client
    6668  SQL*Net roundtrips to/from client
       0  sorts (memory)
       0  sorts (disk)
  100000  rows processed

ターンエンド。

リテラル値指定、かつ、全件ヒットするからTABLE FULL SCANになるはずなのに、何故、INDEX RANGE SCANしてすげ〜時間かかっているんだ〜〜〜〜というマジックの秘密は次回。

バインド変数使ってなくてもオプティマイザをだませるんだぉ

つづく。

述語のつづきの続き。

前回の続きです。

今回の例も今ひとつといえばそうなのでだけど、述語プッシュで索引が利用されることを期待した書き方なのに残念な結果になっている以下のようなパターン、意外と見かけるんですよー
オプティマイザが進化して今以上に賢くなったら気にしなくても最適化してくれるかもしれないけど………

11:28:59 SCOTT> l   
  1  select
  2     v1.id
  3     ,v1.data
  4  from
  5     (
  6         select
  7             to_char(id) as id
  8             ,data
  9         from
 10             push_pred_test1
 11         union
 12         select
 13            to_char(id) as id
 14            ,data
 15         from
 16            push_pred_test2
 17     ) v1
 18  where
 19*    v1.id = 10
11:30:40 SCOTT> /

11行が選択されました。

経過: 00:00:01.58

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

------------------------------------------------------------------------------------------
| Id  | Operation            | Name            | Rows  | Bytes | Cost (%CPU)  | Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |                 |    11 |   814 |  4857     (1)| 00:00:59 |
|   1 |  VIEW                |                 |    11 |   814 |  4857     (1)| 00:00:59 |
|   2 |   SORT UNIQUE        |                 |    11 |  1166 |  4857    (91)| 00:00:59 |
|   3 |    UNION-ALL         |                 |       |       |              |          |
|*  4 |     TABLE ACCESS FULL| PUSH_PRED_TEST1 |     1 |   106 |   445     (1)| 00:00:06 |
|*  5 |     TABLE ACCESS FULL| PUSH_PRED_TEST2 |    10 |  1060 |  4410     (1)| 00:00:53 |
------------------------------------------------------------------------------------------

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

   4 - filter(TO_NUMBER(TO_CHAR("ID"))=10)
   5 - filter(TO_NUMBER(TO_CHAR("ID"))=10)


統計
----------------------------------------------------------
      0  recursive calls
      0  db block gets
  17554  consistent gets
  15960  physical reads
      0  redo size
   1819  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      1  sorts (memory)
      0  sorts (disk)
     11  rows processed

11:30:43 SCOTT> 

こんな実行計画を期待して書いたはず (^^)

11:31:49 SCOTT> l
  1  select
  2     to_char(v1.id) as id
  3     ,v1.data
  4  from
  5     (
  6         select
  7             id
  8             ,data
  9         from
 10             push_pred_test1
 11         union
 12         select
 13             id
 14             ,data
 15         from
 16             push_pred_test2
 17     ) v1
 18  where
 19*    v1.id = 10
11:31:50 SCOTT> /

11行が選択されました。

経過: 00:00:00.00

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

--------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name               | Rows   | Bytes  | Cost (%CPU) | Time     |
--------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                    |     11 |    715 |      8  (25)| 00:00:01 |
|   1 |  VIEW                          |                    |     11 |    715 |      8  (25)| 00:00:01 |
|   2 |   SORT UNIQUE                  |                    |     11 |  1166  |      8  (75)| 00:00:01 |
|   3 |    UNION-ALL                   |                    |        |        |             |          |
|   4 |     TABLE ACCESS BY INDEX ROWID| PUSH_PRED_TEST1    |      1 |    106 |      2   (0)| 00:00:01 |
|*  5 |      INDEX UNIQUE SCAN         | PK_PUSH_PRED_TEST1 |      1 |        |      1   (0)| 00:00:01 |
|   6 |     TABLE ACCESS BY INDEX ROWID| PUSH_PRED_TEST2    |     10 |  1060  |      4   (0)| 00:00:01 |
|*  7 |      INDEX RANGE SCAN          | PK_PUSH_PRED_TEST2 |     10 |        |      3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------

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

   5 - access("ID"=10)
   7 - access("ID"=10)


統計
----------------------------------------------------------
      0  recursive calls
      0  db block gets
      7  consistent gets
      0  physical reads
      0  redo size
   1819  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      1  sorts (memory)
      0  sorts (disk)
     11  rows processed

11:31:51 SCOTT> 

---

ここまでのあらすじ

・述語 ;)
・述語 ;) のつづき

いん！、イン！、Index どっぷり Inde Only Access生活w - Oracle OpenWorld Unconference presented by JPOUG

Oracle OpenWorld Unconference presented by JPOUG
とこかで聞いたようなタイトルを"インデックス"に置換えた「いん！、イン！、Index どっぷり Inde Only Scan生活w」のセッション資料を公開します。
（相変わらず文才ないな〜〜と落ち込む....作文嫌いは死ぬまで治らないと思ってるが、がんばって書くw)

（デモ内容とデモ環境情報を追加予定です。 2012/4/15デモとデモ環境情報追加しました）

直前にデモ環境のOracle11gR2が起動しないという想定外のトラブルを乗り越えw かなりイッパイ、イッパイの状態でしたが楽しい時間を過ごさせていただきました。

関係者の皆様、ご来場の皆様、ありがとうございました。

Safari以外のブラウザではアニメーション効果はありませんが、Safari (Mac/iPad/iPhone)ではKeynote風（但し、ページ間のトランジッションなし）に表示されます。

(2012/4/10追加)
セッションで利用したデモ環境の情報を載せておきます。

MacBook Air late 2010 13inch 2GB (MacOS X Lion)
VirtualBox4.1.10 for MacOS X
GuestOS：CentOS5.8 x86　
DB : Oracle11g R2 11.2.0.1.0 EE for Linux x86

VMの設定は以下のようになってます。
仮想ディスクはほかにもいろいろやるので合計で21GBほどにしてあります :)

(2012/4/15)host i/o cacheはオフにしてあります。

late2010のMBAはメモリが2GBなので、VMには1GBのメモリを割り当ててます。
(オラクルのmemory_targetなどの値も書いたほうがいいのかな〜）

(2012/4/15追記）
メモリサイズがギリギリなのでOracleのメモリ関連初期化パラメータも以下の通りで少なめです。

memory_max_target                    big integer 404M
memory_target                        big integer 404M
sga_max_size                         big integer 404M
sga_target                           big integer 0
pga_aggregate_target                 big integer 0

(2012/4/15追記）
・デモで使った表これ。

13:56:52 SCOTT> desc tab1
 名前                        NULL?    型
 ----------------------------- -------- --------------------
 UNIQUE_ID                     NOT NULL NUMBER
 NON_UNIQUE_ID                          NUMBER(10)
 NON_UNIQUE_ID2                         NUMBER(5)
 DATA                                   VARCHAR2(500)
 IS_DELETE                              NUMBER(1)
 STATUS_CODE                            CHAR(2)

13:56:55 SCOTT> desc tab2
 名前                        NULL?    型
 ----------------------------- -------- --------------------
 UNIQUE_ID2                    NOT NULL NUMBER(5)
 DATA                                   VARCHAR2(500)
 IS_DELETE                              NUMBER(1)

こんなデータを登録して...

13:56:58 SCOTT> 
15:01:15 SCOTT> begin for i in 1..100000 loop insert into tab1 values(i,ora_hash(i,999),ora_hash(i,99),lpad(i,500,'*'),0,'00'); end loop; end;
15:01:17 SCOTT> /

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:25.46
15:01:44 SCOTT> commit;

コミットが完了しました。

経過: 00:00:00.01
15:01:59 SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'TAB1',no_invalidate=>false,cascade=>true);

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:08.50
15:09:43 SCOTT> begin for i in 1..200 loop insert into tab2 values(i,lpad(i,500,'*'),0); end loop; end;
15:10:12   2  /

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:00.05
15:10:13 SCOTT> commit;

コミットが完了しました。

経過: 00:00:00.08
15:10:16 SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'TAB2',no_invalidate=>false,cascade=>true);

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:00.99
15:10:50 SCOTT> 

データ件数、データのカーディナリティは以下のようになってます。

15:10:50 SCOTT> @show_tab_info
tabnameに値を入力してください: tab1

SEGMENT_NAME                   SEGMENT_TYPE       SEGMENT_SU         MB   NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR VISIBLE
------------------------------ ------------------ ---------- ---------- ---------- ------------- ----------------- -------
TAB1                           TABLE              ASSM               62     100000                                 YES
TAB1_IX1                       INDEX              ASSM                3     100000          1000             99400 YES
TAB1_IX2                       INDEX              ASSM                3     100000           100             94181 YES
TAB1_PK                        INDEX              ASSM                2     100000        100000              7693 YES

経過: 00:00:00.78

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME          DESC DATA_TYPE     NUM_NULLS    DENSITY NUM_DISTINCT HI_VALUE      LO_VALUE      HISTOGRAM
------------------------------ ------------------------------ -------------------- ---- ------------ ---------- ---------- ------------ ------------- ------------- ---------------
TAB1                           TAB1_IX1                       NON_UNIQUE_ID        ASC  NUMBER                0       .001         1000 999           0             NONE

                               TAB1_IX2                       NON_UNIQUE_ID2       ASC  NUMBER                0 5.0182E-06          100 99            0             FREQUENCY

                               TAB1_PK                        UNIQUE_ID            ASC  NUMBER                0     .00001       100000 100000        1             NONE


経過: 00:00:02.51
15:17:47 SCOTT> @show_tab_info
tabnameに値を入力してください: tab2

SEGMENT_NAME                   SEGMENT_TYPE       SEGMENT_SU         MB   NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR VISIBLE
------------------------------ ------------------ ---------- ---------- ---------- ------------- ----------------- -------
TAB2                           TABLE              ASSM                1        200                                 YES
TAB2_PK                        INDEX              ASSM                1        200           200                15 YES

経過: 00:00:00.78

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME          DESC DATA_TYPE     NUM_NULLS    DENSITY NUM_DISTINCT HI_VALUE      LO_VALUE      HISTOGRAM
------------------------------ ------------------------------ -------------------- ---- ------------ ---------- ---------- ------------ ------------- ------------- ---------------
TAB2                           TAB2_PK                        UNIQUE_ID2           ASC  NUMBER                0       .005          200 200           1             NONE


経過: 00:00:02.55
15:18:03 SCOTT> 

注）毎回buffer cacheをクリア、かつ、ソフトパース時の結果を載せています。

・demo1

通常ならこの実行計画であればなにもしないですよね...

こんな良さげな実行計画でもSQL文と実行計画それに表定義をじ〜〜〜〜〜〜っと見ていると解決策が見えてきますよね。そうindex only accessならね。

14:45:34 SCOTT> 
14:45:34 SCOTT> set autot trace exp stat
14:45:34 SCOTT> @demo1

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

経過: 00:00:00.03
  1  select
  2       unique_id
  3      ,status_code
  4  from
  5      tab1
  6  where
  7      unique_id between 1 and 1000
  8*     and is_delete = 0

998行が選択されました。

経過: 00:00:00.07

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

---------------------------------------------------------------------------------------
| Id  | Operation                   | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |         |   999 | 10989 |    81   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS BY INDEX ROWID| TAB1    |   999 | 10989 |    81   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | TAB1_PK |  1000 |       |     4   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

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

   1 - filter("IS_DELETE"=0)                                                           
   2 - access("UNIQUE_ID">=1 AND "UNIQUE_ID"<=1000)                                   
 

統計
----------------------------------------------------------                             
          0  recursive calls                                                           
          0  db block gets                                                             
        210  consistent gets                                                           
         80  physical reads                                                            
          0  redo size                                                                 
      19586  bytes sent via SQL*Net to client                                          
       1142  bytes received via SQL*Net from client                                    
         68  SQL*Net roundtrips to/from client                                         
          0  sorts (memory)                                                            
          0  sorts (disk)                                                              
        998  rows processed                                                            

is_deleteなんて列を参照するためにだけに行長の長い行を持つ表を、しかも、レンジスキャンしているのでデータアクセス量が多くなっているんですよね。
そこで、index only access

index only accessするための索引を作成してしまえばそれを回避できますよね.

14:45:36 SCOTT> @demo1_ix
create index tab1_ix_demo1 on tab1(unique_id,is_delete,status_code) nologging invisible

索引が作成されました。

経過: 00:00:00.80
alter session set optimizer_use_invisible_indexes=true

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

経過: 00:00:00.01

TABLE ACCESSが消えました！
consistent getsは、1/3に減少しましたよね :) 時間も 70msから10ms程度に改善してます。

14:46:05 SCOTT> @demo1

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

経過: 00:00:00.04
  1  select
  2       unique_id
  3      ,status_code
  4  from
  5      tab1
  6  where
  7      unique_id between 1 and 1000
  8*     and is_delete = 0

998行が選択されました。

経過: 00:00:00.01

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

----------------------------------------------------------------------------------     
| Id  | Operation        | Name          | Rows  | Bytes | Cost (%CPU)| Time     |     
----------------------------------------------------------------------------------     
|   0 | SELECT STATEMENT |               |   999 | 10989 |     4   (0)| 00:00:01 |     
|*  1 |  INDEX RANGE SCAN| TAB1_IX_DEMO1 |   999 | 10989 |     4   (0)| 00:00:01 |     
----------------------------------------------------------------------------------     

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

   1 - access("UNIQUE_ID">=1 AND "IS_DELETE"=0 AND "UNIQUE_ID"<=1000)                  
       filter("IS_DELETE"=0)                                                           


統計
----------------------------------------------------------                             
          0  recursive calls                                                           
          0  db block gets                                                             
         70  consistent gets                                                           
          4  physical reads                                                            
          0  redo size                                                                 
      19586  bytes sent via SQL*Net to client                                          
       1142  bytes received via SQL*Net from client                                    
         68  SQL*Net roundtrips to/from client                                         
          0  sorts (memory)                                                            
          0  sorts (disk)                                                              
        998  rows processed                                                            

次のデモのために作成した索引を削除しておきます。

14:46:13 SCOTT> @drop_demo1_ix
drop index tab1_ix_demo1

索引が削除されました。

経過: 00:00:00.61
alter session set optimizer_use_invisible_indexes=false

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

経過: 00:00:00.00

・demo2

demo1同様に行長の長い行をある程度の範囲でレンジスキャンかつ、group/order by句があるのでソート処理が行われています。

これも通常ならチューニングなんてしないのですが、大人の事情で何かできないか？　

と聞かれればindex only accessにして表をアクセスしない＋ソート処理も省略しましょうか！　と返してあげることが多いです。

14:47:05 SCOTT> @demo2

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

経過: 00:00:00.02
  1  select
  2      non_unique_id2
  3      ,count(1)
  4  from
  5      tab1
  6  where
  7      non_unique_id  = 70
  8      and is_delete = 0
  9  group by
 10      non_unique_id2
 11  order by
 12*     non_unique_id2

経過: 00:00:00.06

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

-----------------------------------------------------------------------------------------    
| Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| Time     |    
-----------------------------------------------------------------------------------------    
|   0 | SELECT STATEMENT             |          |    63 |   630 |   102   (1)| 00:00:02 |    
|   1 |  SORT GROUP BY               |          |    63 |   630 |   102   (1)| 00:00:02 |    
|*  2 |   TABLE ACCESS BY INDEX ROWID| TAB1     |   100 |  1000 |   101   (0)| 00:00:02 |    
|*  3 |    INDEX RANGE SCAN          | TAB1_IX1 |   100 |       |     1   (0)| 00:00:01 |    
-----------------------------------------------------------------------------------------    

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

   2 - filter("IS_DELETE"=0)                                                           
   3 - access("NON_UNIQUE_ID"=70)                                                      


統計
----------------------------------------------------------                             
          0  recursive calls                                                           
          0  db block gets                                                             
        103  consistent gets                                                           
        103  physical reads                                                            
          0  redo size                                                                 
        517  bytes sent via SQL*Net to client                                          
        416  bytes received via SQL*Net from client                                    
          2  SQL*Net roundtrips to/from client                                         
          1  sorts (memory)                                                            
          0  sorts (disk)                                                              
          1  rows processed                                                            

index only scanにしてソート処理も省略するための索引を作成します。

ではどのような索引を作成すればよいのでしょう？

実行計画のPredicate Informationセクションにはどのような索引を作成するかを決定するための重要な情報がリストされています。

気づきましたか？

以下の２行が重要。

2 - filter("IS_DELETE"=0)
3 - access("NON_UNIQUE_ID"=70)

NON_UNIQUE_ID列に作成されている索引を利用して行を取得し、IS_DELETE=0 でフィルタ処理を実施していることがわかります。

ということは、　NON_UNIQUE_ID,IS_DELETEの２列（つまりWHERE句に記述されている検索条件）がアクセスパスですよね。

次に、選択リスト/GROUP BY句/ORDER BY句を見ると NON_UNIQUE_ID2毎のCOUNT()を取りNON_UNIQUE_ID2を昇順にソートしていることがわかります。

NON_UNIQUE_ID,IS_DELETE列アクセスして、NON_UNIQUE_ID2が昇順にソート済みとなっている索引があればindex only accessになるはず！

14:47:14 SCOTT> @demo2_ix
create index tab1_ix_demo2 on tab1(non_unique_id,is_delete,non_unique_id2) logging invisible

索引が作成されました。

経過: 00:00:00.63
alter session set optimizer_use_invisible_indexes=true

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

経過: 00:00:00.01

結果は...

index range scanのみになり、SORT GROUP BY NOSORTというオペレーションからもわかるように、ソート処理が省略されています。;)

consistent getsは約1/50、処理時間は60msから10msまで改善しました。

14:47:28 SCOTT> @demo2

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

経過: 00:00:00.03
  1  select
  2      non_unique_id2
  3      ,count(1)
  4  from
  5      tab1
  6  where
  7      non_unique_id  = 70
  8      and is_delete = 0
  9  group by
 10      non_unique_id2
 11  order by
 12*     non_unique_id2

経過: 00:00:00.01

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

-------------------------------------------------------------------------------------- 
| Id  | Operation            | Name          | Rows  | Bytes | Cost (%CPU)| Time     | 
-------------------------------------------------------------------------------------- 
|   0 | SELECT STATEMENT     |               |    63 |   630 |     1   (0)| 00:00:01 | 
|   1 |  SORT GROUP BY NOSORT|               |    63 |   630 |     1   (0)| 00:00:01 | 
|*  2 |   INDEX RANGE SCAN   | TAB1_IX_DEMO2 |   100 |  1000 |     1   (0)| 00:00:01 | 
-------------------------------------------------------------------------------------- 

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

   2 - access("NON_UNIQUE_ID"=70 AND "IS_DELETE"=0)                                    


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

作成した索引を削除して次のデモへ。

14:47:33 SCOTT> @drop_demo2_ix
drop index tab1_ix_demo2

索引が削除されました。

経過: 00:00:00.10
alter session set optimizer_use_invisible_indexes=false

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

経過: 00:00:00.00

・demo3

これdemo2の応用編です. 行長の長い行をある程度の範囲でレンジ検索し、最小値(min)を取得するものです。最大値(max)でも考え方は同じ。

14:47:49 SCOTT> @demo3

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

経過: 00:00:00.04
  1  select
  2      min(non_unique_id2)
  3  from
  4      tab1
  5  where
  6      non_unique_id = 70
  7*     and is_delete = 0

経過: 00:00:00.05

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

-----------------------------------------------------------------------------------------    
| Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| Time     |    
-----------------------------------------------------------------------------------------    
|   0 | SELECT STATEMENT             |          |     1 |    10 |   101   (0)| 00:00:02 |    
|   1 |  SORT AGGREGATE              |          |     1 |    10 |            |          |    
|*  2 |   TABLE ACCESS BY INDEX ROWID| TAB1     |   100 |  1000 |   101   (0)| 00:00:02 |    
|*  3 |    INDEX RANGE SCAN          | TAB1_IX1 |   100 |       |     1   (0)| 00:00:01 |    
-----------------------------------------------------------------------------------------    

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

   2 - filter("IS_DELETE"=0)                                                           
   3 - access("NON_UNIQUE_ID"=70)                                                      


統計
----------------------------------------------------------                             
          0  recursive calls                                                           
          0  db block gets                                                             
        103  consistent gets                                                           
        103  physical reads                                                            
          0  redo size                                                                 
        456  bytes sent via SQL*Net to client                                          
        416  bytes received via SQL*Net from client                                    
          2  SQL*Net roundtrips to/from client                                         
          0  sorts (memory)                                                            
          0  sorts (disk)                                                              
          1  rows processed                                                            

demo2と同様に、WHERE句で参照されている検索条件列がアクセスパスになるような索引に、選択リスト中のmin()関数で参照されている列を追加した索引でindex only accessになりそうですよね。

14:47:51 SCOTT> @demo3_ix
create index tab1_ix_demo3 on tab1(non_unique_id, is_delete, non_unique_id2) nologging invisible

索引が作成されました。

経過: 00:00:00.65
alter session set optimizer_use_invisible_indexes=true

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

経過: 00:00:00.00

結果は、狙い通りになりました！

処理時間は40msから10msへ。consistent getsは約1/50に改善しました。

実行計画のINDEX RANGE SCAN (MIN/MAX) 〜 FIRST ROWSという素敵なオペレーションが現れています。

Rowsを見ると索引作成前は 100行選択して1行返すという無駄の多い(99行は捨てている）操作から１行とってきて１行返すというエコな動きをしていることが確認できます！　素敵ですね。

14:48:05 SCOTT> @demo3

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

経過: 00:00:00.04
  1  select
  2      min(non_unique_id2)
  3  from
  4      tab1
  5  where
  6      non_unique_id = 70
  7*     and is_delete = 0

経過: 00:00:00.01

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

----------------------------------------------------------------------------------------------
| Id  | Operation                    | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |               |     1 |    10 |     2   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE              |               |     1 |    10 |            |          |
|   2 |   FIRST ROW                  |               |     1 |    10 |     2   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN (MIN/MAX)| TAB1_IX_DEMO3 |     1 |    10 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------

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

   3 - access("NON_UNIQUE_ID"=70 AND "IS_DELETE"=0)                                    


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

作詞絵作成した索引を削除して次のデモへ...

14:48:09 SCOTT> @drop_demo3_ix
drop index tab1_ix_demo3

索引が削除されました。

経過: 00:00:00.09
alter session set optimizer_use_invisible_indexes=false

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

経過: 00:00:00.01

・demo4

大人の事情で実行計画だけみてるとチューニングなんて不要でしょ！　という感じのクエリをチューニングできないか？

と依頼されたら・・・

２つの表を結合した結果でgorup/order byしているのでソート処理のバイパスはできせんが、index only accessを使ってNested Loop結合でアクセスされるブロック数を最小化することはできますよね。

14:48:26 SCOTT> @demo4

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

経過: 00:00:00.12
  1  select
  2      d.non_unique_id
  3     ,m.unique_id2
  4     ,count(1)
  5  from
  6      tab2 m join tab1 d
  7      on m.unique_id2 = d.non_unique_id2
  8         and m.is_delete = 0
  9         and d.is_delete = 0
 10  where
 11      m.unique_id2 between 1 and 10
 12  group by
 13      d.non_unique_id
 14      ,m.unique_id2
 15  order by
 16      d.non_unique_id
 17*     ,m.unique_id2

100行が選択されました。

経過: 00:00:01.71

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

-------------------------------------------------------------------------------------------  
| Id  | Operation                      | Name     | Rows  | Bytes | Cost (%CPU)| Time     |  
-------------------------------------------------------------------------------------------  
|   0 | SELECT STATEMENT               |          |  1034 | 16544 |   539   (1)| 00:00:07 |  
|   1 |  SORT GROUP BY                 |          |  1034 | 16544 |   539   (1)| 00:00:07 |  
|   2 |   NESTED LOOPS                 |          |       |       |            |          |  
|   3 |    NESTED LOOPS                |          |  1034 | 16544 |   537   (0)| 00:00:07 |  
|*  4 |     TABLE ACCESS BY INDEX ROWID| TAB2     |    10 |    60 |     2   (0)| 00:00:01 |  
|*  5 |      INDEX RANGE SCAN          | TAB2_PK  |    10 |       |     1   (0)| 00:00:01 |  
|*  6 |     INDEX RANGE SCAN           | TAB1_IX2 |   111 |       |     1   (0)| 00:00:01 |  
|*  7 |    TABLE ACCESS BY INDEX ROWID | TAB1     |   103 |  1030 |   106   (0)| 00:00:02 |  
-------------------------------------------------------------------------------------------  

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

   4 - filter("M"."IS_DELETE"=0)                                                       
   5 - access("M"."UNIQUE_ID2">=1 AND "M"."UNIQUE_ID2"<=10)                           
    6 - access("M"."UNIQUE_ID2"="D"."NON_UNIQUE_ID2")                                   
       filter("D"."NON_UNIQUE_ID2"<=10 AND "D"."NON_UNIQUE_ID2">=1)                   
   7 - filter("D"."IS_DELETE"=0)                                                       


統計
----------------------------------------------------------                             
          0  recursive calls                                                           
          0  db block gets                                                             
       9604  consistent gets                                                           
       5793  physical reads                                                            
          0  redo size                                                                 
       2588  bytes sent via SQL*Net to client                                          
        482  bytes received via SQL*Net from client                                    
          8  SQL*Net roundtrips to/from client                                         
          1  sorts (memory)                                                            
          0  sorts (disk)                                                              
        100  rows processed                                                            

WHERE句やPredicate Informationからも駆動表(TAB2)と内部表(TAB1)は判断できると思います。

駆動表(TAB2)はWHERE句の検索条件および結合条件でアクセスパスとなる列が参照されています。
内部表(TAB1)はWHERE句では参照されておらず、結合条件でのみアクセスパスとなる列が参照されていることがわかります。

選択リストやGROUP/ORDER BY句から、内部表(TAB1)のNON_UNIQUE_ID列も索引に含める必要があるとわかるはずです。

既に気づいた方も多いと思うのですが、index only access化に必要な索引列候補はSQL文だけでも見つけることができるんですよ。

ただ、複雑な結合などが含まれる場合は、実行計画計画やPredicate Informationに有益な情報が載っているので、できれば合わせて見ておくと吉ですね。 　

Truth is out there! :) って場合もあるってことで。

14:48:31 SCOTT> @demo4_ix
create index tab2_ix_demo4 on tab2(unique_id2,is_delete) nologging invisible

索引が作成されました。

経過: 00:00:00.06
create index tab1_ix_demo4 on tab1(non_unique_id2, is_delete, non_unique_id) nologging invisible

索引が作成されました。

経過: 00:00:01.21
alter session set optimizer_use_invisible_indexes=true

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

経過: 00:00:00.00

大きなクエリほど効果は絶大ということで。

1710msから50msに改善してます。consistents getsは、1/291に :)

14:49:04 SCOTT> @demo4

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

経過: 00:00:00.05
  1  select
  2      d.non_unique_id
  3     ,m.unique_id2
  4     ,count(1)
  5  from
  6      tab2 m join tab1 d
  7      on m.unique_id2 = d.non_unique_id2
  8         and m.is_delete = 0
  9         and d.is_delete = 0
 10  where
 11      m.unique_id2 between 1 and 10
 12  group by
 13      d.non_unique_id
 14      ,m.unique_id2
 15  order by
 16      d.non_unique_id
 17*     ,m.unique_id2

100行が選択されました。

経過: 00:00:00.04

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

------------------------------------------------------------------------------------   
| Id  | Operation          | Name          | Rows  | Bytes | Cost (%CPU)| Time     |   
------------------------------------------------------------------------------------   
|   0 | SELECT STATEMENT   |               |  1034 | 16544 |    31   (4)| 00:00:01 |   
|   1 |  SORT GROUP BY     |               |  1034 | 16544 |    31   (4)| 00:00:01 |   
|   2 |   NESTED LOOPS     |               |  1034 | 16544 |    30   (0)| 00:00:01 |   
|*  3 |    INDEX RANGE SCAN| TAB1_IX_DEMO4 | 10314 |   100K|    30   (0)| 00:00:01 |   
|*  4 |    INDEX RANGE SCAN| TAB2_IX_DEMO4 |     1 |     6 |     0   (0)| 00:00:01 |   
------------------------------------------------------------------------------------   

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

   3 - access("D"."NON_UNIQUE_ID2">=1 AND "D"."IS_DELETE"=0 AND                        
              "D"."NON_UNIQUE_ID2"<=10)                                                
       filter("D"."IS_DELETE"=0)                                                       
   4 - access("M"."UNIQUE_ID2"="D"."NON_UNIQUE_ID2" AND "M"."IS_DELETE"=0)             
       filter("M"."UNIQUE_ID2"<=10 AND "M"."UNIQUE_ID2">=1)                           
 

統計
----------------------------------------------------------                             
          0  recursive calls                                                           
          0  db block gets                                                             
         33  consistent gets                                                           
         31  physical reads                                                            
          0  redo size                                                                 
       2588  bytes sent via SQL*Net to client                                          
        482  bytes received via SQL*Net from client                                    
          8  SQL*Net roundtrips to/from client                                         
          1  sorts (memory)                                                            
          0  sorts (disk)                                                              
        100  rows processed                                                            

14:49:09 SCOTT> @drop_demo4_ix
drop index tab1_ix_demo4

索引が削除されました。

経過: 00:00:00.11
drop index tab2_ix_demo4

索引が削除されました。

経過: 00:00:00.04
alter session set optimizer_use_invisible_indexes=false

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

経過: 00:00:00.00

Enjoy!

---

・Index Only Access (Index Only Scan) っていいよね（デメリットもあるけどさ） #1
・Index Only Access (Index Only Scan) っていいよね（デメリットもあるけどさ） #2

AWRレポート、AWR SQLレポート一括取得スクリプトを作ったよ。

Statspackレポートもそうなのですが、AWRレポート／AWR SQLレポートも個別に取得していると凄ーく辛いんですよね。一日分出力するとか、AWRレポートで処理時間の長いSQL文のAWR SQLレポートを個別に取得しようとなると...

ただでさえ忙しいのに、AWRレポート取得するのに時間掛けたくないですよね。

ということで、やっつけで作ったのですが、そのまま載せるのもあれなんで、やっつけで作った感じを多少減らしてgithubに公開しました。;)

https://github.com/discus/Oracle-AWR-batch-generation-script/blob/master/awrreport_batch.sql

もっといい感じに改造してくれるといいな〜とかとか... :)

Oracle11g R1/R2 Enterprise Edition、HTML形式で出力します。(RAC環境では試してないので多分だめかと。)。
（AWRを利用するには追加ライセンスが必要なのでご注意を）

使い方は・・

SQL*plusを起動し、select any dictionaryシステム権限、dbms_repositoryパッケージの実行権限が付与されたユーザで接続して実行するだけ。
SYSTEMユーザでやる事が多いけど、所変わればなんとやらなので・・・そこんとこよろしく。(w

一括取得なので実行当日を含めてn日分のAWRレポートを取得し、同時に処理時間の長いTop20のAWR SQLレポートも取得します。
レポートは各スナップショット間（今のところ固定）で取得します。

指定するパラメータは、以下の３つ。

Enter snap_id for starting AWR report generation. [NULL] : 

AWRレポートを取得する最初のSNAP_IDを指定します。 NULLがデフォルトでほとんどの場合デフォルトのままで事足りると思います。

Enter number of days for reporting period. [1] : 

一括取得する日数を指定します。当日を含みます。
当日分のAWRレポートを出力するのであれば、デフォルト値の1のままでOKです。

Enter suffix for AWR reports filename. [NULL] : test

保存するAWRレポートのファイル名に付加するsuffixを指定します。
試験名とか設定するといいですよね。

"test"と指定した場合

awrrpt_nnnn_nnnn_test.htmlや
awrsqrpt_nnnn_nnnn_test_sqlid.html

の形式で保存します。(nnnnはSNAP_ID)

実行例１）当日分の全レポートを取得する例

SYSTEM> 
SYSTEM> !ls -l awr*.sql
-rw-r--r-- 1 oracle oinstall 6065  1月 29 18:23 awrreport_batch.sql

SYSTEM> @awrreport_batch   
 --
-- Oracle AWR and AWR SQL report batch generation script
--
-- ***** This script always generate html format AWR reports. *****
--
Enter snap_id for starting AWR report generation. [NULL] : 
Enter number of days for reporting period. [1] : 
Enter suffix for AWR reports filename. [NULL] : test
--
--
--
clear break compute;
repfooter off;
ttitle off;
btitle off;

・・・中略・・・

<p />
<br /><a class="awr" href="#top">Back to Top</a><p />
</body></html>

SYSTEM> 

実行例２）当日分かつsnap_id=291以降で一括取得。（事前にsnap_idを調べておいてね）

SYSTEM> 
SYSTEM> @awrreport_batch
--
-- Oracle AWR and AWR SQL report batch generation script
--
-- ***** This script always generate html format AWR reports. *****
--
Enter snap_id for starting AWR report generation. [NULL] : 291
Enter number of days for reporting period. [1] : 
Enter suffix for AWR reports filename. [NULL] : test
--
--
--
clear break compute;
repfooter off;
ttitle off;
btitle off;

・・・中略・・・

<p />
<br /><a class="awr" href="#top">Back to Top</a><p />
</body></html>

SYSTEM> 
SYSTEM> 
SYSTEM> !ls -l *.html
-rw-r--r-- 1 oracle oinstall 379083  1月 29 22:23 awrrpt_291_292_test.html
-rw-r--r-- 1 oracle oinstall  11899  1月 29 22:23 awrsqrpt_291_292_test_0c83z9rqx45hu.html
-rw-r--r-- 1 oracle oinstall  11899  1月 29 22:23 awrsqrpt_291_292_test_0h3mfbzk6uyw0.html
-rw-r--r-- 1 oracle oinstall  11897  1月 29 22:23 awrsqrpt_291_292_test_2p7t0mw7zvu5z.html

・・・中略・・・

-rw-r--r-- 1 oracle oinstall  11899  1月 29 22:23 awrsqrpt_291_292_test_bhtycgwkxhfj9.html
-rw-r--r-- 1 oracle oinstall  11900  1月 29 22:23 awrsqrpt_291_292_test_bpaggvtfkar9k.html
-rw-r--r-- 1 oracle oinstall  11899  1月 29 22:23 awrsqrpt_291_292_test_c50hdbyuwhfn6.html
-rw-r--r-- 1 oracle oinstall  11892  1月 29 22:23 awrsqrpt_291_292_test_g3f3cw3zy5aat.html

SYSTEM> 

なお、Oracleインスタンスが再起動された期間でawrrpt.sqlなどを実行すると、レポートが作成できずエラーでSQL*Plusも終了してしまいますが、本スクリプトでは該当部分のレポートはスキップするようにしてあります。:)

Instance     DB Name      Snap Id   Snap Started       Level
------------ ------------ --------- ------------------ -----
lampeye      LAMPEYE            274 29 1月  2012 09:33     1
                                275 29 1月  2012 10:00     1
                                276 29 1月  2012 10:30     1
                                277 29 1月  2012 11:00     1
                                278 29 1月  2012 11:30     1
                                279 29 1月  2012 12:00     1
                                280 29 1月  2012 12:30     1
                                281 29 1月  2012 13:00     1
                                282 29 1月  2012 13:30     1
                                283 29 1月  2012 14:00     1
                                284 29 1月  2012 14:30     1
                                285 29 1月  2012 15:00     1
                                286 29 1月  2012 15:30     1
                                287 29 1月  2012 16:00     1
                                288 29 1月  2012 16:30     1
                                289 29 1月  2012 17:00     1
                                290 29 1月  2012 17:30     1

                                291 29 1月  2012 18:31     1  ←再起動されてる
                                292 29 1月  2012 18:34     1

                                293 29 1月  2012 22:26     1　←再起動されてる

Enjoy!

shutdown immeidateしない、ほかの理由に遭遇！ （FYI)

ず〜〜〜〜っと、追記しようと思ってたんだけど書いてなかったので、徹夜明けで早起きした次いでなんで書いておきます。

もう一年近く前のネタなんだけどね。「shutdown immeidateしない、ほかの理由に遭遇！」

＞ yoheia-a さんありがとう :)

私か書いた記事がキッカケで調べなきゃいけなくなったらしいんだけどね。 ;)

http://d.hatena.ne.jp/yohei-a/20110627/1309180675

---

・shutdown immeidateしない、ほかの理由に遭遇！
・shutdown immeidateしない、ほかの理由に遭遇！ #2
・shutdown immeidateしない、ほかの理由に遭遇！ #3
・shutdown immeidateしない、ほかの理由に遭遇！ おまけ
・shutdown immeidateしない、ほかの理由に遭遇！ おまけのおまけ（でた〜最近、よくあるパターンw）

Index Only Access (Index Only Scan) っていいよね（デメリットもあるけどさ） #2

Index Only Accessのいいとこ、紹介しちゃいますの続きです。

前回は、索引しかアクセスしない（Index Only Access）場合と、索引＋表データもアクセスしちゃう場合の実行計画上の違いを確認しましたよね。

今回は、Index Only Accessで得られる改善効果の１つであるソート処理の回避について簡単な例で確認してみます。

※VISIBLE/INVISIBLEにしている索引の詳細は前回の記事を参照してくださいね。

Now Playing ♪ - ハイスクールララバイ / イモ欽トリオ - 1981

まず、最初は、悪い子の例から。

索引を全表走査した上で　order by seq#　でソート処理が実行されます。酷いですね。検索条件列に適切な索引を作れよ〜〜〜っ。という状態ですね。

SQL> alter index tab10_i01 invisible;

索引が変更されました。

SQL> alter index tab10_i02 invisible;

索引が変更されました。

SQL> select seq# from tab10 where non_unique_key = '0000000001' order by seq#;

10行が選択されました。

経過: 00:00:04.99

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

----------------------------------------------------------------------------
| Id  | Operation           | Name  | Rows | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |       |   10 |   160 | 16788   (1)| 00:03:22 |
|   1 |  SORT ORDER BY      |       |   10 |   160 | 16788   (1)| 00:03:22 |
|*  2 |   TABLE ACCESS FULL | TAB10 |   10 |   160 | 16787   (1)| 00:03:22 |
----------------------------------------------------------------------------

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

   2 - filter("NON_UNIQUE_KEY"='0000000001')


統計
----------------------------------------------------------
      0  recursive calls
      0  db block gets
  61544  consistent gets
  61540  physical reads
      0  redo size
    655  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      1  sorts (memory)
      0  sorts (disk)
     10  rows processed

次に、普通の子の例。

検索条件であるnon_unique_keyに定義された索引を使いIndex range scanかつ、seq#をアクセスするために表データをrowidでアクセス。その後にソート処理が行われています。

普通の子らしい、よい実行計画ですね。 :)

SQL> alter index tab10_i01 visible;

索引が変更されました。

SQL> alter index tab10_i02 invisible;  

索引が変更されました。

SQL> select seq# from tab10 where non_unique_key = '0000000001' order by seq#;

10行が選択されました。

経過: 00:00:00.08

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

------------------------------------------------------------------------------------------
| Id  | Operation                    | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |           |    10 |   160 |     5  (20)| 00:00:01 |
|   1 |  SORT ORDER BY               |           |    10 |   160 |     5  (20)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| TAB10     |    10 |   160 |     4   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN          | TAB10_I01 |    10 |       |     3   (0)| 00:00:01 |
------------------------------------------------------------------------------------------

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

   3 - access("NON_UNIQUE_KEY"='0000000001')


統計
----------------------------------------------------------
      0  recursive calls
      0  db block gets
      4  consistent gets
     17  physical reads
      0  redo size
    655  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      1  sorts (memory)
      0  sorts (disk)
     10  rows processed

そして、最後は、良い子の登場。

この子、データ量が多くなった場合、ソート処理も足枷になると考えたようで　Index only accessを利用したソート処理回避作戦を取ったようです。　
実行計画をみればわかりますが、索引しかアクセスしておらず、SORT ORDER BY というオペレーションも消えています!

検索条件である、non_unique_key列とソート対象のseq#列の２列からなる複合索引を利用するIndex only accessを狙ったようですね。

ただし、これには order by seq# [asc]であるという大前提があります。
order by seq# desc　というソートも考慮する必要がある場合には、non_unique_key [asc]とseq# desc とした別の複合索引必要になります。（デメリットといえばデメリットですかね、）

order by seq# descというソート条件が仕様上無い事を事前に確認しておけば、なお完璧ですよね〜。　良い子。流石です。 :)

SQL> alter index tab10_i01 invisible;

索引が変更されました。

SQL> alter index tab10_i02 visible;  

索引が変更されました。

SQL> select seq# from tab10 where non_unique_key = '0000000001' order by seq#;

10行が選択されました。

経過: 00:00:00.01

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

------------------------------------------------------------------------------
| Id  | Operation        | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |           |    10 |   160 |     3   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| TAB10_I02 |    10 |   160 |     3   (0)| 00:00:01 |
------------------------------------------------------------------------------

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

   1 - access("NON_UNIQUE_KEY"='0000000001')


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

次回へつづく。（他のソート回避の例も紹介しちゃうか、考えちう）

---

・Index Only Access (Index Only Scan) っていいよね（デメリットもあるけどさ） #1

・いん！、イン！、Index どっぷり Inde Only Access生活w - Oracle OpenWorld Unconference presented by JPOUG

Index Only Access (Index Only Scan) っていいよね（デメリットもあるけどさ） #1

さて、OracleさんがAppleさんのOSで楽しいことしてくれないから最近つまんなくなりつつあるので、普通にSQL文のチューニングネタです。

鬼熱かった、鬼熱かった！ :: Insight out 2011- DB tech showcaseでもかなり触れていた、Index Only Scan日本ではこの表現が割合的に多いようなのですが、Index Only Accessって言ってましたね、トムカイトさんも。英語では後者のほうが一般的なのかもしれません。ここではIndex Only Accessってことにしておきます。;)

デメリットもあるけど、Index Only Accessのいいとこばかりを中心に、書いちゃうよ〜w

まず、前提から。

TAB10表は以下のように定義してあります。意図的に表データが大きくなるようにしてあります :)

 名前                NULL?    型
 ------------------ -------- --------------
 SEQ#               NOT NULL NUMBER
 NON_UNIQUE_KEY     NOT NULL CHAR(10)
 DATA                        VARCHAR2(500)

また、以下のような索引を事前に索引しているが、PK_TAB10という主キー索引以外はINVISIBLEとして作成してある。
INVISIBLEで作成しておくと、索引は通常通りメンテナンスされるが、オプティマイザは実行計画作成時にINVISIBLEな索引を利用しないというOracle11gから登場した便利な機能

また前述の表には以下のような主キー(PK_TAB10)と非ユニークな索引が２つ作成してあります。（あまり良い例ではないですがご勘弁を）
但し、TAB10_I01、TAB10_I02の２索引は、INVISIBLEで作成してあります。効果確認時など便利ですよね。
(不可視索引の詳細はマニュアル「Oracle Database 管理者ガイド　11gリリース1（11.1）不可視索引の作成」を参照のこと。）

INDEX_NAME   COLUMN_NAME
------------ -------------------
PK_TAB10     SEQ#

TAB10_I01    NON_UNIQUE_KEY

TAB10_I02    NON_UNIQUE_KEY
             SEQ#

検証時の処理時間及び、実行統計は、各クエリを２回実行し２回目の処理時間及び、実行統計を載せてあります。
（２回目の実行前にバッファキャッシュをクリアしてあるので、ソフトパース＋キャッシュミスほぼ100%という状況の処理時間及び実行統計情報です。）

テストデータは以下件数で、non_unique_keyは偏りはなく均一に分布させあります。
実際のはなし、均等になることの方が稀ではあると思いますけど、Index Only Accessの効果を見る事ができればそれでOKなので。

COUNT(1)
----------
    800000


COUNT(DISTINCTNON_UNIQUE_KEY)
-----------------------------
                        80000


NON_UNIQUE   COUNT(1)
---------- ----------
0000000001         10
0000000002         10
0000000003         10
0000000004         10
0000000005         10
0000000006         10
0000000007         10
0000000008         10
0000000009         10
0000000010         10
0000000011         10
0000000012         10
0000000013         10
0000000014         10
0000000015         10
0000000016         10
0000000017         10
0000000018         10
0000000019         10
0000000020         10

・・・以下略・・・

まず最初は一番分かりやすい、Index Only Accessの例から。

non_unique_key列に、TAB10_I01という非ユニーク索引を作成してありますが、現状、INVISIBLE状態にしてあるため索引が無く全表走査がとなっていますよね。

SQL> set autot trace exp stat
SQL>
SQL> select count(non_unique_key) from tab10 where non_unique_key between '0000000001' and '0000000010';

経過: 00:00:04.32

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

----------------------------------------------------------------------------
| Id  | Operation          | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |       |     1 |    11 | 16787   (1)| 00:03:22 |
|   1 |  SORT AGGREGATE    |       |     1 |    11 |            |          |
|*  2 |   TABLE ACCESS FULL| TAB10 |   100 |  1100 | 16787   (1)| 00:03:22 |
----------------------------------------------------------------------------

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

   2 - filter("NON_UNIQUE_KEY"<='0000000010' AND
          "NON_UNIQUE_KEY">='0000000001')


統計
----------------------------------------------------------
      0  recursive calls
      0  db block gets
  61544  consistent gets
  61539  physical reads
      0  redo size
    562  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      0  sorts (memory)
      0  sorts (disk)
      1  rows processed

ここで、TAB10_I01索引をVISIBLEへ変更して同一クエリを実行してみると……
TAB10_I01索引を利用した実行計画はIndex Range Scanに変化します。しかも、表データはアクセスしていません。これがIndex Only Accessの典型的な例です。アクセスブロック数も処理時間も大きく改善していますよね。

ただ、Index only scanにはデメリットもあります。

それは、索引が多くなればなるほどDML文には足枷になり遅くなるため点です。参照と更新、挿入、削除のバランスを取るのが大切ですが、
とにかく参照を速くする、更新、挿入、削除の処理性能などは少々犠牲にしても問題ないのであれば、どんどんやっちゃいます！（ご利用は計画的にw)

SQL> alter index tab10_i01 visible;
SQL> 
SQL> select count(non_unique_key) from tab10 where non_unique_key between '0000000001' and '0000000010';

経過: 00:00:00.02

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

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

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

   2 - access("NON_UNIQUE_KEY">='0000000001' AND
          "NON_UNIQUE_KEY"<='0000000010')


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

ちなみに、クエリは少々違うのですが、Index only accessで無い場合は、index range scan＋table access by index rowidとなり以下のような実行計画になっちゃいます。
（こちらの方がよく目にする実行計画じゃないでしょうかね。私も性能的な問題等なければ以下のような実行計画であれば良しとしておくことが多いのも事実です。。）

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

------------------------------------------------------------------------------------------
| Id  | Operation                    | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |           |   100 | 51700 |    11   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID | TAB10     |   100 | 51700 |    11   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN           | TAB10_I02 |   100 |       |     3   (0)| 00:00:01 |
------------------------------------------------------------------------------------------

次回へつづく。（忙しくてなかなか書けないかもw)

PL/SQL de Conditional Compile #6

随分前にPL/SQL de Conditional Compile #5ってエントリ書いてたのを思い出して、11g R1/R2用のを見てみたらソースに丁寧なコメント（マニュアルよりいいんじゃね？w )が書かれていてうれしくなった。

オラクルさんとして見せたくない部分は見えないようになっているけど、見せても問題ないところはコードが見える(all_sourceビュー）わけで、それはそれでうれしいわけです。はい。マニュアルが意外に不親切だったりするので。

（マニュアル、良くなりましたよ。昔より。　＞　褒めておかないとね、だれとなくw。）...文字サイズも多くしておきましたw

● Oracle11g R1 11.1 の DBMS_DB_VERSION

package dbms_db_version is
  version constant pls_integer := 11; -- RDBMS version number
  release constant pls_integer := 1;  -- RDBMS release number

  /* The following boolean constants follow a naming convention. Each
     constant gives a name for a boolean expression. For example,
     ver_le_9_1  represents version <=  9 and release <= 1
     ver_le_10_2 represents version <= 10 and release <= 2
     ver_le_10   represents version <= 10

     A typical usage of these boolean constants is

         $if dbms_db_version.ver_le_10 $then
           version 10 and ealier code
         $elsif dbms_db_version.ver_le_11 $then
           version 11 code
         $else
           version 12 and later code
         $end

     This code structure will protect any reference to the code
     for version 12. It also prevents the controlling package
     constant dbms_db_version.ver_le_11 from being referenced
     when the program is compiled under version 10. A similar
     observation applies to version 11. This scheme works even
     though the static constant ver_le_11 is not defined in
     version 10 database because conditional compilation protects
     the $elsif from evaluation if the dbms_db_version.ver_le_10 is
     TRUE.
  */

  ver_le_9_1    constant boolean := FALSE;
  ver_le_9_2    constant boolean := FALSE;
  ver_le_9      constant boolean := FALSE;
  ver_le_10_1   constant boolean := FALSE;
  ver_le_10_2   constant boolean := FALSE;
  ver_le_10     constant boolean := FALSE;
  ver_le_11_1   constant boolean := TRUE;
  ver_le_11     constant boolean := TRUE;

end dbms_db_version;

● Oracle11g R2 11.2 の DBMS_DB_VERSION

package dbms_db_version is
  version constant pls_integer := 11; -- RDBMS version number
  release constant pls_integer := 2;  -- RDBMS release number

  /* The following boolean constants follow a naming convention. Each
     constant gives a name for a boolean expression. For example,
     ver_le_9_1  represents version <=  9 and release <= 1
     ver_le_10_2 represents version <= 10 and release <= 2
     ver_le_10   represents version <= 10

     A typical usage of these boolean constants is

         $if dbms_db_version.ver_le_10 $then
           version 10 and ealier code
         $elsif dbms_db_version.ver_le_11 $then
           version 11 code
         $else
           version 12 and later code
         $end

     This code structure will protect any reference to the code
     for version 12. It also prevents the controlling package
     constant dbms_db_version.ver_le_11 from being referenced
     when the program is compiled under version 10. A similar
     observation applies to version 11. This scheme works even
     though the static constant ver_le_11 is not defined in
     version 10 database because conditional compilation protects
     the $elsif from evaluation if the dbms_db_version.ver_le_10 is
     TRUE.
  */

  ver_le_9_1    constant boolean := FALSE;
  ver_le_9_2    constant boolean := FALSE;
  ver_le_9      constant boolean := FALSE;
  ver_le_10_1   constant boolean := FALSE;
  ver_le_10_2   constant boolean := FALSE;
  ver_le_10     constant boolean := FALSE;
  ver_le_11_1   constant boolean := FALSE;
  ver_le_11_2   constant boolean := TRUE;
  ver_le_11     constant boolean := TRUE;

end dbms_db_version;

version 12 and later codeなんて箇所、いいですね〜w

---

・PL/SQL de Conditional Compile #1
・PL/SQL de Conditional Compile #2
・PL/SQL de Conditional Compile #3
・PL/SQL de Conditional Compile #4
・PL/SQL de Conditional Compile #5

Oracle11g R1のAWRレポートでは%idleと%iowaitが逆なのな。

Oracle11g R1のAWRって仕事でも使うこともそれなりにあるわけですが、なんと、いままで気づかなかったAWRレポートのバグみつけ〜ということで（とっくに気づいていた人はいたはずだけど、基本、11g R1だと修正する気はナッシングと思われw）。メモ代わり。
（でも、リリースされてからづ〜〜と気づかなかったということは私はOperating System Statisticsセクションはスルーしてて見てなかったということなんだろーなー多分）

以下、AWRレポートを出力した時間帯のsarの結果、どう見ても暇な状況なわけですよ。

02時33分37秒       CPU     %user     %nice   %system   %iowait    %steal     %idle
02時33分47秒       all      0.29      0.00      0.13      0.14      0.00     99.44
02時33分57秒       all      0.10      0.00      0.08      0.01      0.00     99.81
02時34分07秒       all      0.20      0.00      0.10      0.02      0.00     99.68
02時34分17秒       all      0.04      0.00      0.02      0.08      0.00     99.86
02時34分27秒       all      0.14      0.00      0.03      0.03      0.00     99.80
02時34分37秒       all      0.13      0.00      0.03      0.03      0.00     99.82
02時34分47秒       all      0.14      0.00      0.02      0.01      0.00     99.83
02時34分57秒       all      0.03      0.00      0.01      0.00      0.00     99.97
02時35分07秒       all      0.11      0.00      0.02      0.03      0.00     99.84
02時35分17秒       all      0.08      0.00      0.03      0.01      0.00     99.88

AWRレポートのHost CPUセクションを見るとまあ、そんな感じなわけです。はい。

でも、Operating SYstem Statistics - Detailセクションを見ると、%iowaitが99.77で、%idleが0.12となっていて、ここだけみるとびっくり〜しちゃうわけですよ〜。

Oracle11g R1 11.1.0.x.xのAWRレポートは皆こんな状態でリストされるので、Operating System Statistics - Detailセクション見る場合は%ildeと%iowaitの値は脳内で入れ替えてね :) というお話でした。

ちなみに、Oracle11g R2ではしっかり修正されていますね。Oracle11g R1のAWRレポート見て驚かないためのメモw でした。

オラクルは会議室で動いてんじゃな〜〜イ。統計情報で動いてんだ！

と少々無理矢理なタイトル付けてみました:) 今回はチューニングはチューニングでも、statspack.snap()のチューニングのお話。

注）表現はそれなりに脚色してありますw

ある日のこと。

大トラブルなんです〜（こういう人、うまくいってないプロジェクトにはよくいます。全然”大”じゃないのに、もう口癖なんでしょうねw）

statspack.snap()がものすごく遅いんです！　なんとかなりませんか？

ん〜〜〜、で、状況を教えてください。

PERFSTAT> 
PERFSTAT> exec statspack.snap(i_snap_level=>7,i_executions_th=>0);

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:31.46

・・・・中略・・・・

PERFSTAT> exec statspack.snap(i_snap_level=>7,i_executions_th=>0);

PL/SQLプロシージャが正常に完了しました。

経過: 00:06:28.02

説明によると、こんな状況になっていたらしい。最初は３０秒ぐらいで終わっていたのに、ここ最近は５分以上になり今日はついに６分超えたとか。

で……statspack.snap()の時間がかかってて試験の消化に支障でてんですよね…とか、

マシン貧弱だからな…とか、

と打ち合わせでも話題になることしばしば…

で、この状態になってからやっと、訪ねてきたわけね.

・・・・マシン環境について、しばし歓談タイム〜・・・・

話していて気づいた！

あ！、その試験環境って、統計情報の自動収集は止められてますよね。しかも試験する時に取得している統計情報って試験用のユーザだけ統計情報収集していますよね〜。

あれだ！、　　感のいいかあなたなら気づきましたよね。ね。ね。:)

次のディクショナリを見れば一億目瞭然！　:)

PERFSTAT> select table_name,num_rows,stale_stats,last_analyzed from user_tab_statistics;

TABLE_NAME                       NUM_ROWS STA LAST_ANA
------------------------------ ---------- --- --------
STATS$BUFFERED_QUEUES
STATS$BUFFERED_SUBSCRIBERS
STATS$BUFFER_POOL_STATISTICS
STATS$CR_BLOCK_SERVER
STATS$CURRENT_BLOCK_SERVER
STATS$DATABASE_INSTANCE
STATS$DB_CACHE_ADVICE
STATS$DLM_MISC
STATS$DYNAMIC_REMASTER_STATS
STATS$ENQUEUE_STATISTICS
STATS$EVENT_HISTOGRAM

・・・・中略・・・・

STATS$STREAMS_POOL_ADVICE
STATS$SYSSTAT
STATS$SYSTEM_EVENT
STATS$SYS_TIME_MODEL
STATS$TEMPSTATXS
STATS$TEMP_SQLSTATS
STATS$THREAD
STATS$TIME_MODEL_STATNAME
STATS$UNDOSTAT
STATS$WAITSTAT

72行が選択されました。

じゃ〜、統計情報収集しましょーよー、ちゃんと！　

23:58:46 PERFSTAT> execdbms_stats.gather_schema_stats(ownname=>'PERFSTAT',no_invalidate=>false,cascade=>true);

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:04.02

試してみて！、 staspack.snap()を！　　ね！ 　前よりすげー速くなった！

23:58:50 PERFSTAT> exec statspack.snap(i_snap_level=>7,i_executions_th=>0);

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:01.38

STATSPACK.SNAP()内で実行されてるSQL文にも統計情報は必要ですよーーーーーーーーーーーーと。

ごれぐらい”ー”付けてればわかってくれるかなー:)

一発ネタは、これにて FIN

悩ませ過ぎは及ばざるがごとし #7 - おまけ

最近、おまけ付けるの好きなので:)

コストベースオプティマイザがどんだけ考えているか、チューニング前とチューニング後（案１と案２）でトレースファイルサイズで比較してみることに（本来それだけで比較できるものではないとは思いますが、あまりにも差があるのでw)

コストベースオプティマイザのトレースは次のようにして取得できますよね（詳細はググってね）

SCOTT> alter session set events='10053 trace name context forever, level 1';

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

経過: 00:00:00.00
SCOTT> SELECT　……　

・・・仲略・・・

5999行が選択されました。

経過: 00:00:53.48

SCOTT> alter session set events='10053 trace name context off';

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

経過: 00:00:00.00

SCOTT> 

オプティマイザトレースファイルのサイズを比較すると以下のようになります：）　
オプティマイザを悩ますクエリ、ヒントで考えるな！感じろ！にしたクエリ（考えてますけど〜〜〜w）、最後が、相関副問合せに書き換えたクエリの順となっています。

[oracle@lampeye trace]$ ll
合計 59088
-rw-r----- 1 oracle oinstall    54431  9月  8 22:14 alert_lampeye2.log
-rw-r----- 1 oracle oinstall 54294792  9月  8 22:16 lampeye2_ora_5913.trc
-rw-r----- 1 oracle oinstall  5154103  9月  8 22:17 lampeye2_ora_5969.trc
-rw-r----- 1 oracle oinstall   898699  9月  8 22:19 lampeye2_ora_5981.trc
[oracle@lampeye trace]$ 

最初のトレースファイル(.trc)，54294792バイトもありますよーw このオプティマイザトレースファイルがハードパースで４８秒も考え込んでた時のものです。
（対象クエリも合わせて載せてみました）

-rw-r----- 1 oracle oinstall 54294792  9月  8 22:16 lampeye2_ora_5913.trc

こんなにオプティマイザを考えさせちゃうクエリ↓

SELECT
    T1.surro_id,
    T1.name,
    T1.modified
FROM
    test T1 JOIN (
        SELECT  DISTINCT
            surro_id,
            surro_bcd
        FROM
            test
    ) T2
    ON 
        T1.surro_id  = T2.surro_id AND
        T1.surro_bcd = T2.surro_bcd
    JOIN test T3
    ON    
        T1.surro_id = T3.surro_id AND
        T1.surro_acd= T3.surro_acd
WHERE
    T1.surro_id IN (リテラル,....限界まで)
    OR T1.surro_id IN (リテラル,....限界まで）

    .....以下....すきなだけ繰り返しw

/

２つめのトレースファイル、5154103バイトで、１／１０程度になりましたーでも大きいですよね。これはヒントを付加して悩まないようにしてあげたものですが、それでもこんなサイズになってます！

-rw-r----- 1 oracle oinstall  5154103  9月  8 22:17 lampeye2_ora_5969.trc

案２、ヒントを付加したクエリでもこんなにでるのね。

SELECT   
    /*+
        LEADING(T1 T2 T3)
        USE_HASH(T1 T2)
        USE_HASH(T1 T3)
        INDEX(T1 IX01_TEST) 
        INDEX(T3 IX01_TEST) 
    */
    T1.surro_id,
    T1.name,
    T1.modified
FROM
    test T1 JOIN (
        SELECT 
            /*+ 
                MERGE 
                INDEX(test IX02_TEST) 
            */ 
            DISTINCT
            surro_id,
            surro_bcd
        FROM
            test
    ) T2
    ON 
        T1.surro_id  = T2.surro_id AND
        T1.surro_bcd = T2.surro_bcd
    JOIN test T3
    ON    
        T1.surro_id = T3.surro_id AND
        T1.surro_acd= T3.surro_acd
WHERE
    T1.surro_id IN (リテラル,....限界まで)
    OR T1.surro_id IN (リテラル,....限界まで）

    .....以下....すきなだけ繰り返しw

/

最後のトレースファイルが（案１）、相関副問合せを利用して改善したクエリをハードパースした際に出力されたトレースファイルです。随分違うもんですねー

-rw-r----- 1 oracle oinstall   898699  9月  8 22:19 lampeye2_ora_5981.trc

案１、処理時間も短いけど、ほんと決断はやって感じですね。

SELECT
     T1.surro_id
    ,T1.name
    ,T1.modified
FROM
    test T1 JOIN (
        SELECT DISTINCT
             surro_id
            ,surro_bcd
        FROM
            test
    ) T2
    ON
        T1.surro_id  = T2.surro_id AND
        T1.surro_bcd = T2.surro_bcd
    JOIN test T3
    ON
        T1.surro_id = T3.surro_id AND
        T1.surro_acd= T3.surro_acd
WHERE
    EXISTS (
        SELECT
            1
        FROM
            test_keys
        WHERE
            surro_id BETWEEN 1000000001 AND 1000005999
            AND surro_id = T1.surro_id
    )
/

---

ここまでのあらずじ

・悩ませ過ぎは及ばざるがごとし #1
・悩ませ過ぎは及ばざるがごとし #2
・悩ませ過ぎは及ばざるがごとし #3
・悩ませ過ぎは及ばざるがごとし #4
・悩ませ過ぎは及ばざるがごとし #5
・悩ませ過ぎは及ばざるがごとし #6

悩ませ過ぎは及ばざるがごとし #6

前回のつづきです。

ヒントを使ってコストベースオプティマイザを悩ませないという方法で、４０秒台っただった処理時間を１秒台にすることに成功しました。

これでも解決は解決なのですが、SQL文単体としては。ただ、インスタンスレベルて考えた場合無駄なメモリ使い過ぎだろという点が気がかり。コストベースオプティマイザが悩まなくなったことでCPUリソースの無駄遣いは回避できましたが、メモリリソースの無駄遣いが凄い。

ということで、どちらの無駄も減らす効果が期待できる案１を…

案１で書き換えるとヒントなしでも随分スッキリしちゃいます。
リテラル値が６０００個近くありましたが、その部分を相関副問合せにしてあります。リテラル値の箇所はバインド変数化しちゃえばいいっすね。

SELECT
     T1.surro_id
    ,T1.name
    ,T1.modified
FROM
    test T1 JOIN (
        SELECT DISTINCT
             surro_id
            ,surro_bcd
        FROM
            test
    ) T2
    ON
        T1.surro_id  = T2.surro_id AND
        T1.surro_bcd = T2.surro_bcd
    JOIN test T3
    ON
        T1.surro_id = T3.surro_id AND
        T1.surro_acd= T3.surro_acd
WHERE
    EXISTS (
        SELECT
            1
        FROM
            test_keys
        WHERE
            surro_id BETWEEN 1000000001 AND 1000005999
            AND surro_id = T1.surro_id
    )
/

実行してみると…　（以下、SQL*Plusで set autot trace exp statコマンド叩いて実行した結果です。なお事前に共有プールはクリアしてあります。）

5999行が選択されました。

経過: 00:00:00.07

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

-------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |              |  5997 |   468K|   144   (3)| 00:00:02 |
|   1 |  VIEW                            | VM_NWVW_1    |  5997 |   468K|   144   (3)| 00:00:02 |
|   2 |   HASH UNIQUE                    |              |  5997 |   491K|   144   (3)| 00:00:02 |
|*  3 |    HASH JOIN RIGHT SEMI          |              |  5997 |   491K|   143   (2)| 00:00:02 |
|*  4 |     INDEX RANGE SCAN             | PK_TEST_KEYS |  5999 | 41993 |    17   (0)| 00:00:01 |
|*  5 |     HASH JOIN                    |              |  5997 |   450K|   125   (1)| 00:00:02 |
|*  6 |      INDEX RANGE SCAN            | IX01_TEST    |  5999 |   128K|    20   (0)| 00:00:01 |
|*  7 |      HASH JOIN                   |              |  5998 |   322K|   105   (1)| 00:00:02 |
|*  8 |       INDEX RANGE SCAN           | IX02_TEST    |  5999 | 53991 |    19   (0)| 00:00:01 |
|   9 |       TABLE ACCESS BY INDEX ROWID| TEST         |  5999 |   269K|    85   (0)| 00:00:02 |
|* 10 |        INDEX RANGE SCAN          | IX02_TEST    |  5999 |       |    19   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------

SQL_ID        SHARABLE_MEM PERSISTENT_MEM RUNTIME_MEM SQL_TEXT
------------- ------------ -------------- ----------- ------------------------------
52gaz3tjd90dh        43446          15648       14504 SELECT  T1.surro_id,  T1.name,
                                                        T1.modified FROM  test T1 jo
                                                      in (   SELECT    DISTINCT    s
                                                      urro_id,    surro_bcd   FROM
                                                        test  ) T2  ON   T1.surro_id
                                                        = T2.surro_id AND   T1.surro
                                                      _bcd = T2.surro_bcd         JO
                                                      IN test T3         ON   T1.sur
                                                      ro_id = T3.surro_id AND   T1.s
                                                      urro_acd= T3.surro_acd WHERE
                                                      EXISTS (   SELECT    1   FROM
                                                         test_keys   WHERE    surro_
                                                      id BETWEEN 1000000001 AND 1000
                                                      005999    AND T1.surro_id = su
                                                      rro_id  )

きゃほーーーーーーっ。　最高〜〜〜〜っ！ :) 言うことナッシングw　　

処理時間が、48.83秒　から　0.07秒へ、SHARABLE_MEMが、3318142バイト　から　43446バイトに。　でバインド変数化しちゃえば〜〜〜、

同時に多数のセッションから集中して発行されても耐えられそうな〜

最後に、ドヤ顔（キリっ

ほんとうにヤバそうなところはキッチリ潰しておきましょ！

OLTP系で実行計画はよいけど、コストベースオプティマイザを悩ませ過ぎて遅延してたら本末転倒ですよー。と。

ーーーー完ーーーーー

---

ここまでのあらずじ

・悩ませ過ぎは及ばざるがごとし #1
・悩ませ過ぎは及ばざるがごとし #2
・悩ませ過ぎは及ばざるがごとし #3
・悩ませ過ぎは及ばざるがごとし #4
・悩ませ過ぎは及ばざるがごとし #5

悩ませ過ぎは及ばざるがごとし #5

前回のつづきです。

前回は改善案を２つ提示しました。

まず、最初は案２のヒントを使って、コストベースオプティマイザに、「考えるな！　感じろ！」作戦w

元のクエリに次のようにヒントを書き加えちゃいます。
どの索引使えとか、結合方法はハッシュとか、とか、よく見かけるヒントだけです。

SELECT   
    /*+
        LEADING(T1 T2 T3)
        USE_HASH(T1 T2)
        USE_HASH(T1 T3)
        INDEX(T1 IX01_TEST) 
        INDEX(T3 IX01_TEST) 
    */
    T1.surro_id,
    T1.name,
    T1.modified
FROM
    test T1 JOIN (
        SELECT 
            /*+ 
                MERGE 
                INDEX(test IX02_TEST) 
            */ 
            DISTINCT
            surro_id,
            surro_bcd
        FROM
            test
    ) T2
    ON 
        T1.surro_id  = T2.surro_id AND
        T1.surro_bcd = T2.surro_bcd
    JOIN test T3
    ON    
        T1.surro_id = T3.surro_id AND
        T1.surro_acd= T3.surro_acd
WHERE
    T1.surro_id IN (リテラル,....限界まで)
    OR T1.surro_id IN (リテラル,....限界まで）

    .....以下....すきなだけ繰り返しw

/

では実行してみると…　（以下、SQL*Plusで set autot trace exp statコマンド叩いて実行した結果です。なお事前に共有プールはクリアしてあります。）

経過: 00:00:01.32

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

----------------------------------------------------------------------------------------------
| Id  | Operation                        | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |           |  5999 |   456K|  5796   (1)| 00:01:10 |
|   1 |  VIEW                            | VM_NWVW_1 |  5999 |   456K|  5796   (1)| 00:01:10 |
|   2 |   HASH UNIQUE                    |           |  5999 |   451K|  5796   (1)| 00:01:10 |
|*  3 |    HASH JOIN                     |           |  5999 |   451K|  5795   (1)| 00:01:10 |
|   4 |     INLIST ITERATOR              |           |       |       |            |          |
|*  5 |      INDEX RANGE SCAN            | IX01_TEST |  5999 |   128K|  1935   (1)| 00:00:24 |
|*  6 |     HASH JOIN                    |           |  5999 |   322K|  3859   (1)| 00:00:47 |
|   7 |      INLIST ITERATOR             |           |       |       |            |          |
|   8 |       TABLE ACCESS BY INDEX ROWID| TEST      |  5999 |   269K|  2001   (1)| 00:00:25 |
|*  9 |        INDEX RANGE SCAN          | IX01_TEST |  5999 |       |  1935   (1)| 00:00:24 |
|  10 |      INLIST ITERATOR             |           |       |       |            |          |
|* 11 |       INDEX RANGE SCAN           | IX02_TEST |  5999 | 53991 |  1857   (1)| 00:00:23 |
----------------------------------------------------------------------------------------------

やたーーーーーーーーーーーーっ！　:) 目標の３秒を下回りましたよー :)

コストベースオプティマイザの悩みを解消してあげることができました…が、例のSHARABLE_MEMが3MB超えちゃってる問題はまだ抱えたままです。＞＜

SQL_ID        SHARABLE_MEM PERSISTENT_MEM RUNTIME_MEM SQL_TEXT
------------- ------------ -------------- ----------- ------------------------------
fbjw4wjdma4f7      3318142         396808      395664 SELECT  /*+   LEADING(T1 T2 T3
                                                      )   USE_HASH(T1 T2)   USE_HASH
                                                      (T1 T3)   INDEX(T1 IX01_TEST)
                                                        INDEX(T3 IX01_TEST)  */  T1.
                                                      surro_id,  T1.name,  T1.modifi
                                                      ed FROM  test T1 join (   SELE
                                                      CT    /*+     MERGE     INDEX(
                                                      test IX02_TEST)    */    DISTI
                                                      NCT    surro_id,    surro_bcd

今回はここまで、次回へつづく。

---

ここまでのあらずじ

・悩ませ過ぎは及ばざるがごとし #1
・悩ませ過ぎは及ばざるがごとし #2
・悩ませ過ぎは及ばざるがごとし #3
・悩ませ過ぎは及ばざるがごとし #4

悩ませ過ぎは及ばざるがごとし #4

さて、さて、前回のつづきです。

意識的に間を取ったんですが、ちょいと長過ぎたかw

前回、ハードパースに時間がかかってるねーってとこまで確認しましたよね〜

・１回目のSQLトレース

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1     45.18      45.15          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch      401      0.04       0.05          0       1897          0        5999
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      403     45.23      45.21          0       1897          0        5999

・２回目のSQLトレース

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      401      0.04       0.04          0       1897          0        5999
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      403      0.04       0.04          0       1897          0        5999

ということでした。

じゃ、こんなにコストペースオプティマイザに考えさせちゃうSQL文でどんなのよー。と。　OLTPなのに分析系のすげー難しそーなSQL文なげてるとか？？？　想像しているより現物見た方が早いですw

こんな感じのクエリだんたんよー。

SELECT
    T1.surro_id,
    T1.name,
    T1.modified
FROM
    test T1 JOIN (
        SELECT  DISTINCT
            surro_id,
            surro_bcd
        FROM
            test
    ) T2
    ON 
        T1.surro_id  = T2.surro_id AND
        T1.surro_bcd = T2.surro_bcd
    JOIN test T3
    ON    
        T1.surro_id = T3.surro_id AND
        T1.surro_acd= T3.surro_acd
WHERE
    T1.surro_id IN (リテラル,....限界まで)
    OR T1.surro_id IN (リテラル,....限界まで）

    .....以下....すきなだけ繰り返しw

/

え、え〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜っ、リテラル値が〜〜〜〜すげ〜〜〜〜〜〜〜ぞ〜〜〜〜〜〜。
クエリ自体はたいしたことないw あの人達がすきそーな自己結合だー。(失礼w)

このクエリを見て、解決策を２つをすぐに思いついたあたなあなた！、　そう、あなた、凄いです！
INリストには上限あるからね：）- Oracle® Database SQL言語リファレンス11gリリース2（11.2）式のリスト

このクエリの解決策。

解決案１
一番効果のありそうなの、リテラルを排除して、その部分を副問合せにしちゃう！。

解決案２
コストベースオプティマイザを悩ませない方法って、ありますよね、そう、ヒントを使って、「こんな感じにうごいて！」作戦。

このクエリの一番の問題点は、リテラル値が山ほどあって、似たような索引が沢山あって、しかも、リテラル値だから毎回値が異なる。結果として毎回ハードパースになるので、毎回コストベースオプティマイザが考え過ぎちゃうとこと。

解決策は前述の２案のうちいずれか一つなんだけど、おすすめは案１のほう。

その訳は、でかいんです、なにが？

以下を見れば、なに？　が　でかいかよーくわかりますw

23:49:06 SYS> SELECT SQL_ID,SHARABLE_MEM,PERSISTENT_MEM,RUNTIME_MEM,SQL_TEXT FROM v$sql WHERE SQL_TEXT LIKE '%/*TEST*/%';

SQL_ID        SHARABLE_MEM PERSISTENT_MEM RUNTIME_MEM SQL_TEXT
------------- ------------ -------------- ----------- ------------------------------
82q8wxz56y357      3317991         396816      395672 SELECT /*TEST*/  T1.surro_id,
                                                       T1.name,  T1.modified FROM  t
                                                      est T1 join (   SELECT  DISTIN
                                                      CT    surro_id,    surro_bcd
                                                       FROM    test  ) T2  ON   T1.s
                                                      urro_id  = T2.surro_id AND   T
                                                      1.surro_bcd = T2.surro_bcd
                                                           JOIN test T3         ON

ね、でかいでしょ。SHARABLE_MEMなんて３MBいっちゃってるし、この程度のことするにしてはデカ過ぎw
これって、直ちには影響はないのですが…（どっかで聞いた事ある言い回し＞＜　　やはり同じ事するセッション多いとさーボディーブローよ。全部ハードパースだしw

今回はここまで、次回へつづく。

---

ここまでのあらずじ

・悩ませ過ぎは及ばざるがごとし #1
・悩ませ過ぎは及ばざるがごとし #2
・悩ませ過ぎは及ばざるがごとし #3

悩ませ過ぎは及ばざるがごとし #3

前回の続きだす。（まだGANTZ語が抜けてないw)

前回は状況証拠固めでした。

で、以下のような状況証拠は確認済み。

• １回目だけ処理時間が異常に長い。
• 実行統計（consistent getsなど）から実行時のアクセスブロック数の差異はない。かつ、ブロック数も少ない。
• 物理読み込みは処理時間には影響していない。

という状況証拠を踏まえ、SQL文の処理フェーズを頭に浮かべて、順序よく考えていくと……

consitents getsの量や処理時間からexecutionフェーズ以降で時間を要しているわけではない……
また、
１回目だけ処理時間が長いが、物理読み込みが影響しているわけではない…

ということは、１回目だけ実行されるといえばハードパース……この部分の処理時間が長いってことですよね！

だんだん近づいてきましたね。というこで、次はパース時間が長いという証拠固めを。

パース時間を比較する方法はいくつかあります…。　SQL*Plusのset autot trace exp を使って実行計画だけを確認する方法とか、Explain plan文使うとか、SQLトレースを取るとか。
ようするに、パース時間が確認できる方法であればどんな方法でもOKなんです。

今回は結果の比較もしやすい、SQLトレースで証拠固をしてみます。SQLトレースを取得する方法はdbms_monitorパッケージを利用する方法が簡単ですかね。（他にもありますが）

SCOTT> exec dbms_monitor.session_trace_enable(null,null,true,false,'ALL_EXECUTIONS');

PL/SQLプロシージャが正常に完了しました。

SCOTT> SELECT 

・・・中略・・・

5999行が選択されました。

経過: 00:00:48.37

SCOTT> exec dbms_monitor.session_trace_disable(null,null);

PL/SQLプロシージャが正常に完了しました。

こんな感じでセッション単位でSQLトレースを取得してtkprofで整形するというおなじみのスタイル。

・１回目のSQLトレース

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1     45.18      45.15          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch      401      0.04       0.05          0       1897          0        5999
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      403     45.23      45.21          0       1897          0        5999

・２回目のSQLトレース

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      401      0.04       0.04          0       1897          0        5999
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      403      0.04       0.04          0       1897          0        5999

予想的中！。　パースに時間を要しているのは明らかですね。

最近のコストベースオプティマイザは賢いです。賢いのでいろいろと考えさせすぎると時間がかかります。（将棋でも相手の手数を読み過ぎなんて…ことありますよね。そんな状況に近いです。）。DWH系のクエリならそんなこともあるでしょうけど、今回問題になっているのはOLTPです、しかも、３秒程度で結果を返してほしいらしいし…

で、どのようにしたらコストベースオプティマイザを"悩ませずに”済むか、そこが今回のポイント。

思い切って、ルールベースにしちゃおーか？。それはNG。確かにパース時間は短くなるでしょうけど…

解決方法を見つけるには問題のクエリがどんなものか見極める必要がありそうですね〜…。どんな方法があるだろー。

今日はここまで、次回へつづく。

---

ここまでのあらずじ

・悩ませ過ぎは及ばざるがごとし #1
・悩ませ過ぎは及ばざるがごとし #2

悩ませ過ぎは及ばざるがごとし #2

「一緒に考えてみてくらちい」タイポじゃないだすw GANTZ見てたんでつい。:)

ということで前回のつづきです。

１回目だけ異常に処理時間を要するクエリがあると相談を受けたという前振り覚えてますか？

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

--------------------------------------------------------------------------------------------
| Id  | Operation                      | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |           |  5999 |   351K|  5718   (1)| 00:01:09 |
|*  1 |  HASH JOIN                     |           |  5999 |   351K|  5718   (1)| 00:01:09 |
|   2 |   INLIST ITERATOR              |           |       |       |            |          |
|*  3 |    INDEX RANGE SCAN            | IX01_TEST |  5999 | 59990 |  1935   (1)| 00:00:24 |
|*  4 |   HASH JOIN                    |           |  5999 |   292K|  3782   (1)| 00:00:46 |
|   5 |    VIEW                        |           |  5999 | 95984 |  1858   (1)| 00:00:23 |
|   6 |     HASH UNIQUE                |           |  5999 | 53991 |  1858   (1)| 00:00:23 |
|   7 |      INLIST ITERATOR           |           |       |       |            |          |
|*  8 |       INDEX RANGE SCAN         | IX02_TEST |  5999 | 53991 |  1857   (1)| 00:00:23 |
|   9 |    INLIST ITERATOR             |           |       |       |            |          |
|  10 |     TABLE ACCESS BY INDEX ROWID| TEST      |  5999 |   199K|  1923   (1)| 00:00:24 |
|* 11 |      INDEX RANGE SCAN          | IX02_TEST |  5999 |       |  1857   (1)| 00:00:23 |
--------------------------------------------------------------------------------------------

・・・中略・・・

統計
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       1897  consistent gets
          0  physical reads
          0  redo size
     247808  bytes sent via SQL*Net to client
      69769  bytes received via SQL*Net from client
        401  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       5999  rows processed

１回目とそれ以降で実行計画の差異はありません。実行統計上はrecursive callが1から0になっている程度の変化しかありません。

ですが……………………

１回目は、４８．８３秒なのに、２回目以降は、０．０８秒…

１回目の処理時間　(SQL*Plusのset timiing on　及び、set autot trace exp statにて計測）

5999行が選択されました。

経過: 00:00:48.83

２回目以降〜

5999行が選択されました。

経過: 00:00:00.08

実行統計を見ると、consistent gets 1897もそれほど多くないのに１回目だけ処理時間が長い、その差はどこに……

SQL文がどのような順序で処理されるのか、よーーーーーく思い出してください；）

リンク先にあるオラクルのマニュアルの図をざっくりまとめちゃうと以下のような感じ（BINDや、FETCHフェーズが書かれている図もよく見かけますね）

となっています。

この辺りも一緒に読むといいですよね。わかりやすいです。無料だし:)
・門外不出のOracle現場ワザ - 第4章　Oracleデータベースの頭脳 「オプティマイザ」徹底研究
・SQL文の処理におけるオプティマイザの役割
・Part2　CBOは何を見てどう判断するのか

これまでに確認できた状況証拠

• １回目だけ処理時間が異常に長い。
• 実行統計（consistent getsなど）から実行時のアクセスブロック数の差異はない。かつ、ブロック数も少ない。
• 物理読み込みは処理時間には影響していない。

これらの状況証拠とSQL文の処理フェーズから導きだせますよね。どこに処理時間を要しているか…………

ほーら、ほら。見えてきました…………………よね？　（ヒントだしてますから〜〜:)

ということで、今日はここまで、次回へつづく。

---

ここまでのあらずじ

・悩ませ過ぎは及ばざるがごとし #1

悩ませ過ぎは及ばざるがごとし #1

あるクエリを実行していて、目標時間は3秒程度のオンライン処理向けクエリ、初回だけ異常に遅いんですけど……。　と再び、大人の事情に縛られて心が痣だらけ（どんなだ）な人達からお呼びがかかりました。

こんな感じの表（索引は似たようなのが数多くありそれもイケてないといえばイケテてないが）を自己結合しているだけ（イケてるクエリとか、イケてないクエリだというのは置いといて）で実行計画もそんなに悪くないし、実行統計を見る限り
初回とそれ以降で大きく乖離しているようにも見えません。

表は次のように定義されています。

SCOTT> desc test
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID                                        NOT NULL NUMBER(10)
 SURRO_ID                                  NOT NULL NUMBER(10)
 SURRO_ACD                                 NOT NULL CHAR(2)
 SURRO_BCD                                 NOT NULL CHAR(1)
 SURRO_CCD                                 NOT NULL CHAR(3)
 SURRO_DCD                                 NOT NULL CHAR(5)
 NAME                                      NOT NULL VARCHAR2(100)
 DESCRIPTION                                        VARCHAR2(300)
 CREATED                                   NOT NULL TIMESTAMP(6)
 MODIFIED                                  NOT NULL TIMESTAMP(6)

索引は以下のようになってます。

INDEX_NAME                     COLUMN_NAME
------------------------------ ------------------------------
IX01_TEST                      SURRO_ID
                               SURRO_ACD
                               
IX02_TEST                      SURRO_ID
                               SURRO_BCD
                               
IX03_TEST                      SURRO_ID
                               SURRO_CCD
                               
IX04_TEST                      SURRO_ID
                               SURRO_DCD
                               
PK_TEST                        ID

なんだか、どれも似たような索引がならんでいます。

INDEX_NAME                     INDEX_TYPE                    NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR
------------------------------ --------------------------- ---------- ------------- -----------------
IX04_TEST                      NORMAL                          700000        700000              7653
IX03_TEST                      NORMAL                          700000        700000              7653
IX02_TEST                      NORMAL                          700000        700000              7653
IX01_TEST                      NORMAL                          700000        700000              7653
PK_TEST                        NORMAL                          700000        700000              7653

どーーーーーーーしてでしょう。

このつづきは次回のお楽しみ。

一緒に考えてみてくらちい ;)

１回目の処理行数、処理時間、実行計画及び実行統計。

・・・中略・・・

5999行が選択されました。

経過: 00:00:48.83

実行計画
----------------------------------------------------------                                  
Plan hash value: 1865103575                          
             
--------------------------------------------------------------------------------------------
| Id  | Operation                      | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |           |  5999 |   351K|  5718   (1)| 00:01:09 |
|*  1 |  HASH JOIN                     |           |  5999 |   351K|  5718   (1)| 00:01:09 |
|   2 |   INLIST ITERATOR              |           |       |       |            |          |
|*  3 |    INDEX RANGE SCAN            | IX01_TEST |  5999 | 59990 |  1935   (1)| 00:00:24 |
|*  4 |   HASH JOIN                    |           |  5999 |   292K|  3782   (1)| 00:00:46 |
|   5 |    VIEW                        |           |  5999 | 95984 |  1858   (1)| 00:00:23 |
|   6 |     HASH UNIQUE                |           |  5999 | 53991 |  1858   (1)| 00:00:23 |
|   7 |      INLIST ITERATOR           |           |       |       |            |          |
|*  8 |       INDEX RANGE SCAN         | IX02_TEST |  5999 | 53991 |  1857   (1)| 00:00:23 |
|   9 |    INLIST ITERATOR             |           |       |       |            |          |
|  10 |     TABLE ACCESS BY INDEX ROWID| TEST      |  5999 |   199K|  1923   (1)| 00:00:24 |
|* 11 |      INDEX RANGE SCAN          | IX02_TEST |  5999 |       |  1857   (1)| 00:00:23 |
--------------------------------------------------------------------------------------------

・・・中略・・・

統計
----------------------------------------------------------
          1  recursive calls                         
          0  db block gets                           
       1897  consistent gets                         
          0  physical reads                          
          0  redo size                               
     247808  bytes sent via SQL*Net to client        
      69769  bytes received via SQL*Net from client  
        401  SQL*Net roundtrips to/from client       
          0  sorts (memory)                          
          0  sorts (disk)                            
       5999  rows processed  

２回目の処理行数、処理時間、実行計画及び実行統計。

１回目とくらべて随分処理時間が短いです。。。。

・・・中略・・・

5999行が選択されました。

経過: 00:00:00.08

実行計画
----------------------------------------------------------                                  
Plan hash value: 1865103575                          
             
--------------------------------------------------------------------------------------------
| Id  | Operation                      | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |           |  5999 |   351K|  5718   (1)| 00:01:09 |
|*  1 |  HASH JOIN                     |           |  5999 |   351K|  5718   (1)| 00:01:09 |
|   2 |   INLIST ITERATOR              |           |       |       |            |          |
|*  3 |    INDEX RANGE SCAN            | IX01_TEST |  5999 | 59990 |  1935   (1)| 00:00:24 |
|*  4 |   HASH JOIN                    |           |  5999 |   292K|  3782   (1)| 00:00:46 |
|   5 |    VIEW                        |           |  5999 | 95984 |  1858   (1)| 00:00:23 |
|   6 |     HASH UNIQUE                |           |  5999 | 53991 |  1858   (1)| 00:00:23 |
|   7 |      INLIST ITERATOR           |           |       |       |            |          |
|*  8 |       INDEX RANGE SCAN         | IX02_TEST |  5999 | 53991 |  1857   (1)| 00:00:23 |
|   9 |    INLIST ITERATOR             |           |       |       |            |          |
|  10 |     TABLE ACCESS BY INDEX ROWID| TEST      |  5999 |   199K|  1923   (1)| 00:00:24 |
|* 11 |      INDEX RANGE SCAN          | IX02_TEST |  5999 |       |  1857   (1)| 00:00:23 |
--------------------------------------------------------------------------------------------
             
・・・中略・・・

統計
----------------------------------------------------------
          0  recursive calls                         
          0  db block gets                           
       1897  consistent gets                         
          0  physical reads                          
          0  redo size                               
     247808  bytes sent via SQL*Net to client        
      69766  bytes received via SQL*Net from client  
        401  SQL*Net roundtrips to/from client       
          0  sorts (memory)                          
          0  sorts (disk)                            
       5999  rows processed                          

３回目の処理行数、処理時間、実行計画及び実行統計。

３回目も２回目と同じようです。１回目だけなぜか異常に遅い。ちなみに、Oracle11g R2 11.2.0.1.0 for Linux x86_64です。

・・・中略・・・

5999行が選択されました。

経過: 00:00:00.08

実行計画
----------------------------------------------------------                                  
Plan hash value: 1865103575                          
             
--------------------------------------------------------------------------------------------
| Id  | Operation                      | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |           |  5999 |   351K|  5718   (1)| 00:01:09 |
|*  1 |  HASH JOIN                     |           |  5999 |   351K|  5718   (1)| 00:01:09 |
|   2 |   INLIST ITERATOR              |           |       |       |            |          |
|*  3 |    INDEX RANGE SCAN            | IX01_TEST |  5999 | 59990 |  1935   (1)| 00:00:24 |
|*  4 |   HASH JOIN                    |           |  5999 |   292K|  3782   (1)| 00:00:46 |
|   5 |    VIEW                        |           |  5999 | 95984 |  1858   (1)| 00:00:23 |
|   6 |     HASH UNIQUE                |           |  5999 | 53991 |  1858   (1)| 00:00:23 |
|   7 |      INLIST ITERATOR           |           |       |       |            |          |
|*  8 |       INDEX RANGE SCAN         | IX02_TEST |  5999 | 53991 |  1857   (1)| 00:00:23 |
|   9 |    INLIST ITERATOR             |           |       |       |            |          |
|  10 |     TABLE ACCESS BY INDEX ROWID| TEST      |  5999 |   199K|  1923   (1)| 00:00:24 |
|* 11 |      INDEX RANGE SCAN          | IX02_TEST |  5999 |       |  1857   (1)| 00:00:23 |
--------------------------------------------------------------------------------------------
             
・・・中略・・・
                  
 
統計
----------------------------------------------------------
          0  recursive calls                         
          0  db block gets                           
       1897  consistent gets                         
          0  physical reads                          
          0  redo size                               
     247808  bytes sent via SQL*Net to client        
      69766  bytes received via SQL*Net from client  
        401  SQL*Net roundtrips to/from client       
          0  sorts (memory)                          
          0  sorts (disk)                            
       5999  rows processed  

いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング番外編

おまけのおまけのおまけとは、さすがに書きづらかったのでw 番外編。

いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング８ おまけのおまけで次のように書いていたのを覚えてますか？

"アクセスするブロック数を減らすのはハッシュパーティションのままではもう、むーりーw　限界です。"

なぜ、限界としたか。という点、聞きたくないですか？

聞きたいですよね。:)

理由は次のクエリ(GROUP BYとCUBEでチューニングしたクエリの一番大切部分）と処理時間、実行計画、consistent getsを見ていただければお分かりいただけるかと……　　

そーーーなんです。　以下のブロック数と処理時間って、前回、GROUP BY と CUBEだけでチューニングした結果とそっくりですよね。

  1   SELECT
  2        SUBSTR(starting_date,1,6) AS month
  3       ,shop_code
  4       ,SUM(sales_figure) AS sales_figure
  5   FROM
  6       test2
  7   WHERE
  8       starting_date BETWEEN '20110101' AND '20110331'
  9   GROUP BY
 10        SUBSTR(starting_date,1,6)
 11*      ,shop_code

3900行が選択されました。

経過: 00:00:06.89

実行計画
----------------------------------------------------------  
Plan hash value: 2608398149  
                  
--------------------------------------------------------------------------------------------- 
| Id  | Operation           | Name  | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop | 
--------------------------------------------------------------------------------------------- 
|   0 | SELECT STATEMENT    |       |  8274 |   137K| 82839   (2)| 00:16:35 |       |       | 
|   1 |  HASH GROUP BY      |       |  8274 |   137K| 82839   (2)| 00:16:35 |       |       | 
|   2 |   PARTITION HASH ALL|       |  1703K|    27M| 82788   (2)| 00:16:34 |     1 |     4 | 
|*  3 |    TABLE ACCESS FULL| TEST2 |  1703K|    27M| 82788   (2)| 00:16:34 |     1 |     4 | 
--------------------------------------------------------------------------------------------- 
                  
Predicate Information (identified by operation id):     
---------------------------------------------------     
                  
   3 - filter("STARTING_DATE"<='20110331' AND "STARTING_DATE">='20110101') 


統計
----------------------------------------------------------
          0  recursive calls                            
          0  db block gets                              
     302341  consistent gets
     302289  physical reads 
          0  redo size                                  
      87392  bytes sent via SQL*Net to client           
       3369  bytes received via SQL*Net from client     
        261  SQL*Net roundtrips to/from client          
          0  sorts (memory)                             
          0  sorts (disk)                               
       3900  rows processed                             

と、いうことで限界！　と判断したわけなんです。　どうですか？　スッキリしましたか？　:) では、また。

---

これまでのあらずじ…

・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #1
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #2
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #3
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #4
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #5
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #6
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #7 おまけ
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング８ おまけのおまけ

いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング８ おまけのおまけ

前回のつづきです。

GROUPING SETSを単純に使っただけでは可読性は向上するが内部で自動的に行われる一時表への展開（WITH句で書くのに似ている）とUNION　ALLによる集計時オーバーヘッドが大きくなるようで、WITH句＋UNION ALLに書き換えた場合ほど効果はありませんでした。残念。

だったら〜。

ということで、GROUPING SETSは使わず、やってる事がやってる事だから、素直にCUBEを使ってクロス集計しちゃえばオーバーヘッドとなっているWITH句＋UNION ALLへの展開も行わないようにすればなって良いんジャマイカ！　そうしよう！

で、パーティションは大人の事情でハッシュのままに、WITH句＋UNION ALLへの書き換えや、GROUPING SETSで自動的にWITH句＋UNION ALLへ展開する方法を止めたのが以下のクエリ。

え〜〜〜〜〜、え〜〜〜〜〜〜。シリアル実行としては最速の結果、６秒台キタ〜〜〜〜！。
可読性は副問合せなどの影響でちょいと落ちますがSQL文は短いのでそれほど影響はないですよね。いままで一番短いのではないでしょうか:)

  1  SELECT
  2      CASE
  3          WHEN grouping_id(month) = 1 THEN
  4              CASE
  5                  WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0406' THEN 'Q1'
  6                  WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0709' THEN 'Q2'
  7                  WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '1012' THEN 'Q3'
  8                  WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0103' THEN 'Q4'
  9              END
 10          ELSE month
 11      END AS month
 12     ,CASE
 13          WHEN grouping_id(shop_code) = 1 THEN 'ALL'
 14          ELSE shop_code
 15      END AS shop_code
 16     ,SUM(sales_figure) AS sales_figure
 17  FROM
 18      (
 19          SELECT
 20               SUBSTR(starting_date,1,6) AS month
 21              ,shop_code
 22              ,SUM(sales_figure) AS sales_figure
 23          FROM
 24              test2
 25          WHERE
 26              starting_date BETWEEN '20110101' AND '20110331'
 27          GROUP BY
 28              SUBSTR(starting_date,1,6)
 29             ,shop_code
 30      )
 31  GROUP BY
 32      CUBE(month,shop_code)
 33  HAVING
 34      shop_code = '1000'
 35      OR grouping_id(shop_code) = 1
 36  ORDER BY
 37      month
 38*    ,shop_code

8行が選択されました。

経過: 00:00:06.86

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

---------------------------------------------------------------------------------------------------
| Id  | Operation                 | Name  | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
---------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT          |       |  1381 | 34525 | 83173   (2)| 00:16:39 |       |       |
|   1 |  SORT ORDER BY            |       |  1381 | 34525 | 83173   (2)| 00:16:39 |       |       |
|*  2 |   FILTER                  |       |       |       |            |          |       |       |
|   3 |    SORT GROUP BY          |       |  1381 | 34525 | 83173   (2)| 00:16:39 |       |       |
|   4 |     GENERATE CUBE         |       |  1381 | 34525 | 83173   (2)| 00:16:39 |       |       |
|   5 |      SORT GROUP BY        |       |  1381 | 34525 | 83173   (2)| 00:16:39 |       |       |
|   6 |       VIEW                |       |  2758 | 68950 | 83172   (2)| 00:16:39 |       |       |
|   7 |        HASH GROUP BY      |       |  2758 | 66192 | 83172   (2)| 00:16:39 |       |       |
|   8 |     PARTITION HASH ALL    |       |   394K|  9242K| 83161   (2)| 00:16:38 |     1 |     4 |
|*  9 |      TABLE ACCESS FULL    | TEST2 |   394K|  9242K| 83161   (2)| 00:16:38 |     1 |     4 |
---------------------------------------------------------------------------------------------------

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

   2 - filter("SHOP_CODE"='1000' OR GROUPING_ID(BIN_TO_NUM(SYS_OP_GROUPING("SHOP_CODE",1,0,
          SYS_OP_BITVEC)))=1)
   9 - filter("STARTING_DATE"<='20110331' AND SUBSTR("STARTING_DATE",1,6)<='201103' AND
          SUBSTR("STARTING_DATE",1,6)>='201101' AND "STARTING_DATE">='20110101')


統計
----------------------------------------------------------
      0  recursive calls
      0  db block gets
 302587  consistent gets
 302556  physical reads
      0  redo size
    871  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      3  sorts (memory)
      0  sorts (disk)
      8  rows processed

お約束、オラクルお任せのパラレル実験。　

お〜〜〜〜〜〜〜〜〜〜〜〜っ。キター、1.2秒台〜〜〜〜〜。　パーティションタイプのミスという痛恨の設計ミスを帳消にしてあげたかも。（それは嘘。
そもそも、アクセスするブロック数を減らすのはハッシュパーティションのままではもう、むーりーw　限界です。

  1  SELECT /*+ PARALLEL */
  2      CASE
  3          WHEN grouping_id(month) = 1 THEN
  4              CASE
  5                  WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0406' THEN 'Q1'
  6                  WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0709' THEN 'Q2'
  7                  WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '1012' THEN 'Q3'
  8                  WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0103' THEN 'Q4'
  9              END
 10          ELSE month
 11      END AS month
 12     ,CASE
 13          WHEN grouping_id(shop_code) = 1 THEN 'ALL'
 14          ELSE shop_code
 15      END AS shop_code
 16     ,SUM(sales_figure) AS sales_figure
 17  FROM
 18      (
 19          SELECT
 20               SUBSTR(starting_date,1,6) AS month
 21              ,shop_code
 22              ,SUM(sales_figure) AS sales_figure
 23          FROM
 24              test2
 25          WHERE
 26              starting_date BETWEEN '20110101' AND '20110331'
 27          GROUP BY
 28              SUBSTR(starting_date,1,6)
 29             ,shop_code
 30      )
 31  GROUP BY
 32      CUBE(month,shop_code)
 33  HAVING
 34      shop_code = '1000'
 35      OR grouping_id(shop_code) = 1
 36  ORDER BY
 37      month
 38*    ,shop_code

8行が選択されました。

経過: 00:00:01.24

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

-----------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                         | Name         | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                  |              |  1381 | 34525 |  5773   (2)| 00:01:10 |       |       |        |      |            |
|   1 |  PX COORDINATOR                   |              |       |       |            |          |       |       |        |      |            |
|   2 |   PX SEND QC (ORDER)              | :TQ10004     |  1381 | 34525 |  5773   (2)| 00:01:10 |       |       |  Q1,04 | P->S | QC (ORDER) |
|   3 |    SORT ORDER BY                  |              |  1381 | 34525 |  5773   (2)| 00:01:10 |       |       |  Q1,04 | PCWP |            |
|   4 |     PX RECEIVE                    |              |  1381 | 34525 |  5773   (2)| 00:01:10 |       |       |  Q1,04 | PCWP |            |
|   5 |      PX SEND RANGE                | :TQ10003     |  1381 | 34525 |  5773   (2)| 00:01:10 |       |       |  Q1,03 | P->P | RANGE      |
|*  6 |       FILTER                      |              |       |       |            |          |       |       |  Q1,03 | PCWC |            |
|   7 |        SORT GROUP BY              |              |  1381 | 34525 |  5773   (2)| 00:01:10 |       |       |  Q1,03 | PCWP |            |
|   8 |     PX RECEIVE                    |              |  1381 | 34525 |  5773   (2)| 00:01:10 |       |       |  Q1,03 | PCWP |            |
|   9 |      PX SEND HASH                 | :TQ10002     |  1381 | 34525 |  5773   (2)| 00:01:10 |       |       |  Q1,02 | P->P | HASH       |
|  10 |       GENERATE CUBE               |              |  1381 | 34525 |  5773   (2)| 00:01:10 |       |       |  Q1,02 | PCWC |            |
|  11 |        SORT GROUP BY              |              |  1381 | 34525 |  5773   (2)| 00:01:10 |       |       |  Q1,02 | PCWP |            |
|  12 |         PX RECEIVE                |              |  1381 | 34525 |  5773   (2)| 00:01:10 |       |       |  Q1,02 | PCWP |            |
|  13 |          PX SEND HASH             | :TQ10001     |  1381 | 34525 |  5773   (2)| 00:01:10 |       |       |  Q1,01 | P->P | HASH       |
|  14 |           SORT GROUP BY           |              |  1381 | 34525 |  5773   (2)| 00:01:10 |       |       |  Q1,01 | PCWP |            |
|  15 |            VIEW                   |              |  2758 | 68950 |  5772   (2)| 00:01:10 |       |       |  Q1,01 | PCWP |            |
|  16 |         HASH GROUP BY             |              |  2758 | 66192 |  5772   (2)| 00:01:10 |       |       |  Q1,01 | PCWP |            |
|  17 |          PX RECEIVE               |              |  2758 | 66192 |  5772   (2)| 00:01:10 |       |       |  Q1,01 | PCWP |            |
|  18 |           PX SEND HASH            | :TQ10000     |  2758 | 66192 |  5772   (2)| 00:01:10 |       |       |  Q1,00 | P->P | HASH       |
|  19 |            HASH GROUP BY          |              |  2758 | 66192 |  5772   (2)| 00:01:10 |       |       |  Q1,00 | PCWP |            |
|  20 |             PX BLOCK ITERATOR     |              |   394K|  9242K|  5770   (2)| 00:01:10 |     1 |     4 |  Q1,00 | PCWC |            |
|* 21 |              TABLE ACCESS FULL    | TEST2        |   394K|  9242K|  5770   (2)| 00:01:10 |     1 |     4 |  Q1,00 | PCWP |            |
-----------------------------------------------------------------------------------------------------------------------------------------------

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

   6 - filter("SHOP_CODE"='1000' OR GROUPING_ID(BIN_TO_NUM(SYS_OP_GROUPING("SHOP_CODE",1,0,SYS_OP_BITVEC)))=1)
  21 - filter("STARTING_DATE"<='20110331' AND SUBSTR("STARTING_DATE",1,6)<='201103' AND SUBSTR("STARTING_DATE",1,6)>='201101' AND
          "STARTING_DATE">='20110101')

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


統計
----------------------------------------------------------
     96  recursive calls
      0  db block gets
 304109  consistent gets
 302556  physical reads
      0  redo size
    871  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
     65  sorts (memory)
      0  sorts (disk)
      8  rows processed

今一度、最初のイケてないクエリと比較。あ〜、ダメダメだ〜。やっぱり無駄が多すぎですね！

  1  SELECT
  2       month
  3      ,shop_code
  4      ,sales_figure
  5  FROM
  6  (
  7      SELECT
  8           SUBSTR(starting_date,1,6) AS month
  9          ,shop_code
 10          ,SUM(sales_figure) AS sales_figure
 11      FROM
 12          test2
 13      WHERE
 14          starting_date BETWEEN '20110101' AND '20110331'
 15          AND shop_code = '1000'
 16      GROUP BY
 17           SUBSTR(starting_date,1,6)
 18          ,shop_code
 19      UNION ALL
 20      SELECT
 21           CASE
 22              WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
 23              WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
 24              WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 25              WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 26           END AS month
 27          ,shop_code
 28          ,SUM(sales_figure) AS salles_figure
 29      FROM
 30          test2
 31      WHERE
 32          starting_date BETWEEN '20110101' AND '20110331'
 33          AND shop_code = '1000'
 34      GROUP BY
 35           CASE
 36              WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
 37              WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
 38              WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 39              WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 40           END
 41          ,shop_code
 42      UNION ALL
 43      SELECT
 44           SUBSTR(starting_date,1,6) AS month
 45          ,'ALL ' AS shop_code
 46          ,SUM(sales_figure) AS sales_figure
 47      FROM
 48          test2
 49      WHERE
 50          starting_date BETWEEN '20110101' AND '20110331'
 51      GROUP BY
 52          SUBSTR(starting_date,1,6)
 53      UNION ALL
 54      SELECT
 55           CASE
 56              WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
 57              WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
 58              WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 59              WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 60           END AS month
 61          ,'ALL ' AS shop_code
 62          ,SUM(sales_figure) AS salles_figure
 63      FROM
 64          test2
 65      WHERE
 66          starting_date BETWEEN '20110101' AND '20110331'
 67      GROUP BY
 68          CASE
 69              WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
 70              WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
 71              WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 72              WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 73          END
 74  )
 75  ORDER BY
 76       month
 77*     ,shop_code

8行が選択されました。

経過: 00:00:20.92

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

-------------------------------------------------------------------------------------------------------------------
| Id  | Operation                              | Name       | Rows  | Bytes | Cost (%CPU)| Time     |Pstart| Pstop|
-------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                       |            |    22 |   726 |   166K  (2)| 00:33:18 |      |      |
|   1 |  SORT ORDER BY                         |            |    22 |   726 |   166K  (2)| 00:33:18 |      |      |
|   2 |   VIEW                                 |            |    22 |   726 |   166K  (2)| 00:33:18 |      |      |
|   3 |    UNION-ALL                           |            |       |       |            |          |      |      |
|   4 |     HASH GROUP BY                      |            |     3 |    72 |    43   (3)| 00:00:01 |      |      |
|   5 |      PARTITION HASH ALL                |            |   303 |  7272 |    42   (0)| 00:00:01 |    1 |    4 |
|   6 |       TABLE ACCESS BY LOCAL INDEX ROWID| TEST2      |   303 |  7272 |    42   (0)| 00:00:01 |    1 |    4 |
|*  7 |        INDEX RANGE SCAN                | PK_TEST2   |   303 |       |    19   (0)| 00:00:01 |    1 |    4 |
|   8 |     HASH GROUP BY                      |            |     7 |   119 |    43   (3)| 00:00:01 |      |      |
|   9 |      PARTITION HASH ALL                |            |   303 |  5151 |    42   (0)| 00:00:01 |    1 |    4 |
|  10 |       TABLE ACCESS BY LOCAL INDEX ROWID| TEST2      |   303 |  5151 |    42   (0)| 00:00:01 |    1 |    4 |
|* 11 |        INDEX RANGE SCAN                | PK_TEST2   |   303 |       |    19   (0)| 00:00:01 |    1 |    4 |
|  12 |     HASH GROUP BY                      |            |     3 |    57 | 83172   (2)| 00:16:39 |      |      |
|  13 |      PARTITION HASH ALL                |            |   394K|  7316K| 83161   (2)| 00:16:38 |    1 |    4 |
|* 14 |       TABLE ACCESS FULL                | TEST2      |   394K|  7316K| 83161   (2)| 00:16:38 |    1 |    4 |
|  15 |     HASH GROUP BY                      |            |     9 |   108 | 83172   (2)| 00:16:39 |      |      |
|  16 |      PARTITION HASH ALL                |            |   394K|  4621K| 83161   (2)| 00:16:38 |    1 |    4 |
|* 17 |       TABLE ACCESS FULL                | TEST2      |   394K|  4621K| 83161   (2)| 00:16:38 |    1 |    4 |
-------------------------------------------------------------------------------------------------------------------

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

   7 - access("SHOP_CODE"='1000' AND "STARTING_DATE">='20110101' AND "STARTING_DATE"<='20110331')
       filter(SUBSTR("STARTING_DATE",1,6)<='201103' AND SUBSTR("STARTING_DATE",1,6)>='201101')
  11 - access("SHOP_CODE"='1000' AND "STARTING_DATE">='20110101' AND "STARTING_DATE"<='20110331')
       filter(SUBSTR("STARTING_DATE",1,6)<='201103' AND SUBSTR("STARTING_DATE",1,6)>='201101')
  14 - filter("STARTING_DATE"<='20110331' AND SUBSTR("STARTING_DATE",1,6)<='201103' AND
          SUBSTR("STARTING_DATE",1,6)>='201101' AND "STARTING_DATE">='20110101')
  17 - filter("STARTING_DATE"<='20110331' AND SUBSTR("STARTING_DATE",1,6)<='201103' AND
          SUBSTR("STARTING_DATE",1,6)>='201101' AND "STARTING_DATE">='20110101')


統計
----------------------------------------------------------
      0  recursive calls
      0  db block gets
 606978  consistent gets
 605112  physical reads
      0  redo size
    875  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      1  sorts (memory)
      0  sorts (disk)
      8  rows processed

前回の結果なのでここには載せませんが、GROUPSING SETSで書き換えた場合や、WITH句＋UNION ALLで書き換えた場合でも一時表への書き込み及び一時表からの読み込みは複数回発生し、それがボディーブローのように効いていたんよね。:)

これもお約束、そもそもパーティションタイプが月単位のレンジパーティションだったら〜（タラレバw）どんな結果になるか。

キター、シリアル実行でも４秒台、４秒切りそうな勢いです：）
月単位のレンジパーティションにより無駄なブロックを読み込む必要がなくなったことが効いてますね。

  1  SELECT
  2      CASE
  3          WHEN grouping_id(month) = 1 THEN
  4              CASE
  5                  WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0406' THEN 'Q1'
  6                  WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0709' THEN 'Q2'
  7                  WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '1012' THEN 'Q3'
  8                  WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0103' THEN 'Q4'
  9              END
 10         ELSE month
 11      END AS month
 12     ,CASE
 13          WHEN grouping_id(shop_code) = 1 THEN 'ALL'
 14          ELSE shop_code
 15      END AS shop_code
 16     ,SUM(sales_figure) AS sales_figure
 17  FROM
 18     (
 19         SELECT
 20              SUBSTR(starting_date,1,6) AS month
 21             ,shop_code
 22             ,SUM(sales_figure) AS sales_figure
 23         FROM
 24             test3
 25         WHERE
 26             starting_date BETWEEN '20110101' AND '20110331'
 27         GROUP BY
 28              SUBSTR(starting_date,1,6)
 29             ,shop_code
 30     )
 31  GROUP BY
 32      CUBE(month,shop_code)
 33  HAVING
 34      shop_code = '1000' OR
 35      grouping_id(shop_code) = 1
 36  ORDER BY
 37      month
 38*    ,shop_code

8行が選択されました。

経過: 00:00:04.04

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

-----------------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name     | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
-----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |          |     1 |    32 |       | 52177   (2)| 00:10:27 |       |       |
|   1 |  SORT ORDER BY               |          |     1 |    32 |       | 52177   (2)| 00:10:27 |       |       |
|*  2 |   FILTER                     |          |       |       |       |            |          |       |       |
|   3 |    SORT GROUP BY             |          |     1 |    32 |       | 52177   (2)| 00:10:27 |       |       |
|   4 |     GENERATE CUBE            |          |     1 |    32 |       | 52177   (2)| 00:10:27 |       |       |
|   5 |      SORT GROUP BY           |          |     1 |    32 |       | 52177   (2)| 00:10:27 |       |       |
|   6 |       VIEW                   |          | 80894 |  2527K|       | 52171   (2)| 00:10:27 |       |       |
|   7 |        HASH GROUP BY         |          | 80894 |  1342K|   428M| 52171   (2)| 00:10:27 |       |       |
|   8 |     PARTITION RANGE ITERATOR |          |    15M|   258M|       | 20630   (2)| 00:04:08 |     1 |     3 |
|*  9 |      TABLE ACCESS FULL       | TEST3    |    15M|   258M|       | 20630   (2)| 00:04:08 |     1 |     3 |
-----------------------------------------------------------------------------------------------------------------

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

   2 - filter("SHOP_CODE"='1000' OR GROUPING_ID(BIN_TO_NUM(SYS_OP_GROUPING("SHOP_CODE",1,0,SYS_OP_BITVEC)
          ))=1)
   9 - filter("STARTING_DATE"<='20110331' AND "STARTING_DATE">='20110101')


統計
----------------------------------------------------------
      1  recursive calls
      0  db block gets
  73961  consistent gets
  25665  physical reads
      0  redo size
    871  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      3  sorts (memory)
      0  sorts (disk)
      8  rows processed

これまた恒例になった、オラクル任せのパラレル処理〜〜。ついにでました、１秒切りそうな処理時間w

  1  SELECT /*+ PARALLEL */
  2      CASE
  3          WHEN grouping_id(month) = 1 THEN
  4              CASE
  5                  WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0406' THEN 'Q1'
  6                  WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0709' THEN 'Q2'
  7                  WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '1012' THEN 'Q3'
  8                  WHEN SUBSTR(MIN(month),5,2)||SUBSTR(MAX(month),5,2) = '0103' THEN 'Q4'
  9              END
 10         ELSE month
 11      END AS month
 12     ,CASE
 13          WHEN grouping_id(shop_code) = 1 THEN 'ALL'
 14          ELSE shop_code
 15      END AS shop_code
 16     ,SUM(sales_figure) AS sales_figure
 17  FROM
 18     (
 19         SELECT
 20              SUBSTR(starting_date,1,6) AS month
 21             ,shop_code
 22             ,SUM(sales_figure) AS sales_figure
 23         FROM
 24             test3
 25         WHERE
 26             starting_date BETWEEN '20110101' AND '20110331'
 27         GROUP BY
 28              SUBSTR(starting_date,1,6)
 29             ,shop_code
 30     )
 31  GROUP BY
 32      CUBE(month,shop_code)
 33  HAVING
 34      shop_code = '1000' OR
 35      grouping_id(shop_code) = 1
 36  ORDER BY
 37      month
 38*    ,shop_code

8行が選択されました。

経過: 00:00:01.09

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

-------------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                         | Name         | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
-------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                  |              |     1 |    32 |       | 13834   (2)| 00:02:47 |       |       |        |      |            |
|   1 |  PX COORDINATOR                   |              |       |       |       |            |          |       |       |        |      |            |
|   2 |   PX SEND QC (ORDER)              | :TQ10004     |     1 |    32 |       | 13834   (2)| 00:02:47 |       |       |  Q1,04 | P->S | QC (ORDER) |
|   3 |    SORT ORDER BY                  |              |     1 |    32 |       | 13834   (2)| 00:02:47 |       |       |  Q1,04 | PCWP |            |
|   4 |     PX RECEIVE                    |              |     1 |    32 |       | 13834   (2)| 00:02:47 |       |       |  Q1,04 | PCWP |            |
|   5 |      PX SEND RANGE                | :TQ10003     |     1 |    32 |       | 13834   (2)| 00:02:47 |       |       |  Q1,03 | P->P | RANGE      |
|*  6 |       FILTER                      |              |       |       |       |            |          |       |       |  Q1,03 | PCWC |            |
|   7 |        SORT GROUP BY              |              |     1 |    32 |       | 13834   (2)| 00:02:47 |       |       |  Q1,03 | PCWP |            |
|   8 |     PX RECEIVE                    |              |     1 |    32 |       | 13834   (2)| 00:02:47 |       |       |  Q1,03 | PCWP |            |
|   9 |      PX SEND HASH                 | :TQ10002     |     1 |    32 |       | 13834   (2)| 00:02:47 |       |       |  Q1,02 | P->P | HASH       |
|  10 |       GENERATE CUBE               |              |     1 |    32 |       | 13834   (2)| 00:02:47 |       |       |  Q1,02 | PCWC |            |
|  11 |        SORT GROUP BY              |              |     1 |    32 |       | 13834   (2)| 00:02:47 |       |       |  Q1,02 | PCWP |            |
|  12 |         PX RECEIVE                |              |     1 |    32 |       | 13834   (2)| 00:02:47 |       |       |  Q1,02 | PCWP |            |
|  13 |          PX SEND HASH             | :TQ10001     |     1 |    32 |       | 13834   (2)| 00:02:47 |       |       |  Q1,01 | P->P | HASH       |
|  14 |           SORT GROUP BY           |              |     1 |    32 |       | 13834   (2)| 00:02:47 |       |       |  Q1,01 | PCWP |            |
|  15 |            VIEW                   |              | 80894 |  2527K|       | 13831   (2)| 00:02:46 |       |       |  Q1,01 | PCWP |            |
|  16 |         HASH GROUP BY             |              | 80894 |  1342K|   428M| 13831   (2)| 00:02:46 |       |       |  Q1,01 | PCWP |            |
|  17 |          PX RECEIVE               |              | 80894 |  1342K|       | 13831   (2)| 00:02:46 |       |       |  Q1,01 | PCWP |            |
|  18 |           PX SEND HASH            | :TQ10000     | 80894 |  1342K|       | 13831   (2)| 00:02:46 |       |       |  Q1,00 | P->P | HASH       |
|  19 |            HASH GROUP BY          |              | 80894 |  1342K|   428M| 13831   (2)| 00:02:46 |       |       |  Q1,00 | PCWP |            |
|  20 |             PX BLOCK ITERATOR     |              |    15M|   258M|       |  5726   (2)| 00:01:09 |     1 |     3 |  Q1,00 | PCWC |            |
|* 21 |              TABLE ACCESS FULL    | TEST3        |    15M|   258M|       |  5726   (2)| 00:01:09 |     1 |     3 |  Q1,00 | PCWP |            |
-------------------------------------------------------------------------------------------------------------------------------------------------------

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

   6 - filter("SHOP_CODE"='1000' OR GROUPING_ID(BIN_TO_NUM(SYS_OP_GROUPING("SHOP_CODE",1,0,SYS_OP_BITVEC)))=1)
  21 - filter("STARTING_DATE"<='20110331' AND "STARTING_DATE">='20110101')

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


統計
----------------------------------------------------------
     24  recursive calls
      0  db block gets
  74326  consistent gets
  73923  physical reads
      0  redo size
    871  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
     17  sorts (memory)
      0  sorts (disk)
      8  rows processed

以上、いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング　無事に終了。（おわらすのか〜w)

おまけのおまけまでチューニングしハッシュパーティションのままでも６秒台までになることは確認しましたが、実際に提示したクエリは、UNION ALLで記述された無駄の多いダメダメクエリをWITH句とUNION ALLに書き換えた8秒台の結果となるクエリでした。

なぜ、今回のおまけのおまけで載せた最速クエリを提示しなかったか。。。。。その理由は・・・・・・、８秒台であればユーザと調整可能なレベルだったから、元クエリを書いた方に書き換え方を伝えやすかった(UNION ALLを残しつつチューニング）という、これまた大人の事情が絡んでいます；）。

いま以上にチューニングできるとはわかっていても、余力を残しつつ許容できるレベルでチューニングを止めるという”チューニングのゴール”は大切ですよ。（チューニングに割ける時間もお金も限りがありますから）

８秒台のクエリもデータ量や処理量が増加した際、再び問題視される時期が来るかもしれません。その時は、GROUP BY+CUBEにすれば喜ばれますよ。月単位のレンジパーティションに切り替えてあげるだけでも喜ばれますよ（より工数掛かりますが）。チューニング余地は見切れていたほうがいいですよね。

追記、なにか忘れてるー、と思ったらPIVOTの事すっかり忘れてたw。どうしようw

さて、次のネタのキーワードは、「悩ませ過ぎは及ばざるがごとし」w にしようかな。

---

これまでのあらずじ…

・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #1
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #2
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #3
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #4
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #5
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #6
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #7 おまけ

いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング７ おまけ

前回、思いつきでGROUPING SETSに書き換えたら予想外に結果が悪かったわけですが、よーく考えたら事前にもうちょっとサマってしまえばいけるんじゃないかと気づいて少々書き換えてみました、
悲惨だった前回の結果に比べたら随分改善しましたが、それでも元に戻った程度ですね。(^^;;;;;;

やはり、いくない。

以下、前回、一番処理時間が長くなったケース。単純にGROUPING SETSに書き換えた場合、元のクエリより遅い。アクセスブロック数は３／４程度なんですがね。処理時間がねぇ〜

　1  SELECT
  2      CASE
  3         WHEN quarter IS NULL THEN month
  4         ELSE quarter
  5      END AS month
  6     ,CASE
  7         WHEN grouping_id = 1 THEN 'ALL'
  8         ELSE shop_code
  9      END AS shop_code
 10     ,sales_figure
 11  FROM (
 12     SELECT
 13          grouping_id(shop_code) as grouping_id
 14         ,quarter
 15         ,month
 16         ,shop_code
 17         ,SUM(sales_figure) AS sales_figure
 18     FROM
 19     (
 20         SELECT
 21             CASE
 22                 WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
 23                 WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
 24                 WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 25                 WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 26             END AS quarter
 27             ,SUBSTR(starting_date,1,6) AS month
 28             ,shop_code
 29             ,sales_figure
 30         FROM
 31             test2
 32         WHERE
 33             SUBSTR(starting_date,1,6) BETWEEN '201101' AND '201103'
 34     )
 35     GROUP BY GROUPING SETS (
 36         (month, shop_code),
 37         (quarter, shop_code),
 38         (month),
 39         (quarter)
 40     )
 41  )
 42  WHERE
 43         shop_code = '1000'
 44      OR grouping_id  = 1
 45  ORDER BY
 46       month
 47*     ,shop_code

8行が選択されました。

経過: 00:00:34.88

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

------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name                        | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |                             |   711K|    33M|       | 93048   (3)| 00:18:37 |       |       |
|   1 |  SORT ORDER BY               |                             |   711K|    33M|    43M| 93048   (3)| 00:18:37 |       |       |
|   2 |   VIEW                       |                             |   711K|    33M|       | 84288   (3)| 00:16:52 |       |       |
|   3 |    TEMP TABLE TRANSFORMATION |                             |       |       |       |            |          |       |       |
|   4 |     LOAD AS SELECT           | SYS_TEMP_0FD9D6636_4A53D793 |       |       |       |            |          |       |       |
|   5 |      PARTITION HASH ALL      |                             |    15M|   351M|       | 84280   (3)| 00:16:52 |     1 |     4 |
|*  6 |       TABLE ACCESS FULL      | TEST2                       |    15M|   351M|       | 84280   (3)| 00:16:52 |     1 |     4 |
|   7 |     LOAD AS SELECT           | SYS_TEMP_0FD9D6637_4A53D793 |       |       |       |            |          |       |       |
|   8 |      SORT GROUP BY ROLLUP    |                             |     1 |    33 |       |     3  (34)| 00:00:01 |       |       |
|   9 |       TABLE ACCESS FULL      | SYS_TEMP_0FD9D6636_4A53D793 |     1 |    33 |       |     2   (0)| 00:00:01 |       |       |
|  10 |     LOAD AS SELECT           | SYS_TEMP_0FD9D6637_4A53D793 |       |       |       |            |          |       |       |
|  11 |      SORT GROUP BY ROLLUP    |                             |     1 |    23 |       |     3  (34)| 00:00:01 |       |       |
|  12 |       TABLE ACCESS FULL      | SYS_TEMP_0FD9D6636_4A53D793 |     1 |    23 |       |     2   (0)| 00:00:01 |       |       |
|  13 |     VIEW                     |                             |     1 |    50 |       |     2   (0)| 00:00:01 |       |       |
|* 14 |      TABLE ACCESS FULL       | SYS_TEMP_0FD9D6637_4A53D793 |     1 |    50 |       |     2   (0)| 00:00:01 |       |       |
------------------------------------------------------------------------------------------------------------------------------------

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

   6 - filter(SUBSTR("STARTING_DATE",1,6)<='201103' AND SUBSTR("STARTING_DATE",1,6)>='201101')
  14 - filter("SYS_TEMP_0FD9D6637_4A53D793"."C1"='1000' OR
          BIN_TO_NUM(SYS_OP_VECBIT(SYS_OP_NUMTORAW("SYS_TEMP_0FD9D6637_4A53D793"."D0"),1))=1)


統計
----------------------------------------------------------
    761  recursive calls
  52432  db block gets
 405879  consistent gets
 405750  physical reads
   1944  redo size
    871  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      3  sorts (memory)
      0  sorts (disk)
      8  rows processed

意外な結果になってしまったので、WITH句は利用していないのですが今回試したのは事前にある程度サマったケース。
コードサイズも一番小さくて可読性もよいと思うんだけどね〜。
アクセスしているブロック数は１／２でいい感じなのですが、処理時間は今回ネタにしたクエリ（後述）より少々良い程度。ブロック数は半減したのに処理時間がさほど改善していないのはCPUへの負荷が考えていた以上に高いのでしょうかね。（それはまた別途しらべておきますか）

  1  SELECT
  2     CASE
  3         WHEN quarter IS NULL THEN month
  4         ELSE quarter
  5     END AS month
  6     ,CASE
  7         WHEN grouping_id(shop_code) = 1 THEN 'ALL'
  8         ELSE shop_code
  9     END AS shop_code
 10     ,SUM(sales_figure) AS sales_figure
 11  FROM
 12      (
 13         SELECT
 14             CASE
 15                 WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
 16                 WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
 17                 WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 18                 WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 19             END AS quarter
 20             ,SUBSTR(starting_date,1,6) AS month
 21             ,shop_code
 22             ,SUM(sales_figure) AS sales_figure
 23         FROM
 24             test2
 25         WHERE
 26             starting_date BETWEEN '20110101' AND '20110331'
 27         GROUP BY
 28             CASE
 29                 WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
 30                 WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
 31                 WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 32                 WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 33             END
 34             ,SUBSTR(starting_date,1,6)
 35             ,shop_code
 36     )
 37  GROUP BY GROUPING SETS (
 38     (month, shop_code),
 39     (quarter, shop_code),
 40     (month),
 41     (quarter)
 42  )
 43  HAVING
 44     shop_code = '1000'
 45     OR grouping_id(shop_code) = 1
 46  ORDER BY
 47       month
 48*     ,shop_code

8行が選択されました。

経過: 00:00:19.69

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

--------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                  | Name                        | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
--------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |                             |  2758 |   134K| 83181   (2)| 00:16:39 |       |       |
|   1 |  TEMP TABLE TRANSFORMATION |                             |       |       |            |          |       |       |
|   2 |   LOAD AS SELECT           | SYS_TEMP_0FD9D66D1_4A54AE09 |       |       |            |          |       |       |
|   3 |    HASH GROUP BY           |                             | 17550 |   411K| 83172   (2)| 00:16:39 |       |       |
|   4 |     PARTITION HASH ALL     |                             |   394K|  9242K| 83161   (2)| 00:16:38 |     1 |     4 |
|*  5 |      TABLE ACCESS FULL     | TEST2                       |   394K|  9242K| 83161   (2)| 00:16:38 |     1 |     4 |
|   6 |   LOAD AS SELECT           | SYS_TEMP_0FD9D66D2_4A54AE09 |       |       |            |          |       |       |
|   7 |    SORT GROUP BY ROLLUP    |                             |     1 |    33 |     3  (34)| 00:00:01 |       |       |
|   8 |     TABLE ACCESS FULL      | SYS_TEMP_0FD9D66D1_4A54AE09 |     1 |    33 |     2   (0)| 00:00:01 |       |       |
|   9 |   LOAD AS SELECT           | SYS_TEMP_0FD9D66D2_4A54AE09 |       |       |            |          |       |       |
|  10 |    SORT GROUP BY ROLLUP    |                             |     1 |    23 |     3  (34)| 00:00:01 |       |       |
|  11 |     TABLE ACCESS FULL      | SYS_TEMP_0FD9D66D1_4A54AE09 |     1 |    23 |     2   (0)| 00:00:01 |       |       |
|  12 |   SORT ORDER BY            |                             |  2758 |   134K|     3  (34)| 00:00:01 |       |       |
|  13 |    VIEW                    |                             |     1 |    50 |     2   (0)| 00:00:01 |       |       |
|* 14 |     TABLE ACCESS FULL      | SYS_TEMP_0FD9D66D2_4A54AE09 |     1 |    50 |     2   (0)| 00:00:01 |       |       |
--------------------------------------------------------------------------------------------------------------------------

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

   5 - filter("SYS_TBL_$2$"."STARTING_DATE"<='20110331' AND SUBSTR("STARTING_DATE",1,6)<='201103' AND
          SUBSTR("STARTING_DATE",1,6)>='201101' AND "SYS_TBL_$2$"."STARTING_DATE">='20110101')
  14 - filter("SYS_TEMP_0FD9D66D2_4A54AE09"."C1"='1000' OR
          BIN_TO_NUM(SYS_OP_VECBIT(SYS_OP_NUMTORAW("SYS_TEMP_0FD9D66D2_4A54AE09"."D0"),1))=1)


統計
----------------------------------------------------------
    358  recursive calls
     52  db block gets
 302715  consistent gets
 302587  physical reads
   1764  redo size
    871  bytes sent via SQL*Net to client
    519  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      3  sorts (memory)
      0  sorts (disk)
      8  rows processed

前々回、WITH句とunion allだけでチューニングしたクエリと比べてみるとブロック数は同じ程度でもCPUコストの差は実行計画からもある程度読み取れますね（参考程度ですがw）。

  1  WITH
  2  t01 AS
  3  (
  4      SELECT
  5           SUBSTR(starting_date,1,6) AS month
  6          ,CASE
  7               WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
  8               WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
  9               WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 10               WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 11          END AS quarter
 12          ,shop_code
 13          ,SUM(sales_figure) as sales_figure
 14      FROM
 15          test2
 16      WHERE
 17          starting_date BETWEEN '20110101' AND '20110331'
 18      GROUP BY
 19           SUBSTR(starting_date,1,6)
 20          ,SUBSTR(starting_date,5,2)
 21          ,shop_code
 22  ),
 23  t02 AS
 24  (
 25      SELECT
 26           month
 27          ,quarter
 28          ,shop_code
 29          ,sales_figure
 30      FROM
 31          t01
 32      WHERE
 33          month BETWEEN '201101' AND '201103'
 34      AND shop_code = '1000'
 35  )
 36  SELECT
 37       month
 38      ,shop_code
 39      ,sales_figure
 40  FROM
 41  (
 42      SELECT
 43           month
 44          ,shop_code
 45          ,SUM(sales_figure) AS sales_figure
 46      FROM
 47          t02
 48      GROUP BY
 49           month
 50          ,shop_code
 51      UNION ALL
 52      SELECT
 53           quarter AS month
 54          ,shop_code
 55          ,SUM(sales_figure) AS sales_figure
 56      FROM
 57          t02
 58      GROUP BY
 59           quarter
 60          ,shop_code
 61      UNION ALL
 62      SELECT
 63           month
 64          ,'ALL ' AS shop_code
 65          ,SUM(sales_figure) AS sales_figure
 66      FROM
 67          t01
 68      GROUP BY
 69          month
 70      UNION ALL
 71      SELECT
 72           quarter AS month
 73          ,'ALL ' AS shop_code
 74          ,SUM(sales_figure) AS salles_figure
 75      FROM
 76          t01
 77      GROUP BY
 78          quarter
 79  )
 80  ORDER BY
 81       month
 82*     ,shop_code

8行が選択されました。

経過: 00:00:08.35

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

--------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                  | Name                        | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
--------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |                             |  3692 |   118K| 83282   (2)| 00:16:40 |       |       |
|   1 |  TEMP TABLE TRANSFORMATION |                             |       |       |            |          |       |       |
|   2 |   LOAD AS SELECT           | SYS_TEMP_0FD9D660A_4A53712A |       |       |            |          |       |       |
|   3 |    HASH GROUP BY           |                             | 17550 |   411K| 83172   (2)| 00:16:39 |       |       |
|   4 |     PARTITION HASH ALL     |                             |   394K|  9242K| 83161   (2)| 00:16:38 |     1 |     4 |
|*  5 |      TABLE ACCESS FULL     | TEST2                       |   394K|  9242K| 83161   (2)| 00:16:38 |     1 |     4 |
|   6 |   LOAD AS SELECT           | SYS_TEMP_0FD9D660B_4A53712A |       |       |            |          |       |       |
|*  7 |    VIEW                    |                             | 17550 |   497K|    17   (0)| 00:00:01 |       |       |
|   8 |     TABLE ACCESS FULL      | SYS_TEMP_0FD9D660A_4A53712A | 17550 |   411K|    17   (0)| 00:00:01 |       |       |
|   9 |   SORT ORDER BY            |                             |  3692 |   118K|    93   (8)| 00:00:02 |       |       |
|  10 |    VIEW                    |                             |  3692 |   118K|    92   (7)| 00:00:02 |       |       |
|  11 |     UNION-ALL              |                             |       |       |            |          |       |       |
|  12 |      HASH GROUP BY         |                             |  2758 | 68950 |    27   (4)| 00:00:01 |       |       |
|  13 |       VIEW                 |                             | 17550 |   428K|    26   (0)| 00:00:01 |       |       |
|  14 |        TABLE ACCESS FULL   | SYS_TEMP_0FD9D660B_4A53712A | 17550 |   497K|    26   (0)| 00:00:01 |       |       |
|  15 |      HASH GROUP BY         |                             |   920 | 20240 |    27   (4)| 00:00:01 |       |       |
|  16 |       VIEW                 |                             | 17550 |   377K|    26   (0)| 00:00:01 |       |       |
|  17 |        TABLE ACCESS FULL   | SYS_TEMP_0FD9D660B_4A53712A | 17550 |   497K|    26   (0)| 00:00:01 |       |       |
|  18 |      HASH GROUP BY         |                             |    13 |   260 |    18   (6)| 00:00:01 |       |       |
|  19 |       VIEW                 |                             | 17550 |   342K|    17   (0)| 00:00:01 |       |       |
|  20 |        TABLE ACCESS FULL   | SYS_TEMP_0FD9D660A_4A53712A | 17550 |   411K|    17   (0)| 00:00:01 |       |       |
|  21 |      HASH GROUP BY         |                             |     1 |    17 |    18   (6)| 00:00:01 |       |       |
|  22 |       VIEW                 |                             | 17550 |   291K|    17   (0)| 00:00:01 |       |       |
|  23 |        TABLE ACCESS FULL   | SYS_TEMP_0FD9D660A_4A53712A | 17550 |   411K|    17   (0)| 00:00:01 |       |       |
--------------------------------------------------------------------------------------------------------------------------

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

   5 - filter("STARTING_DATE"<='20110331' AND SUBSTR("STARTING_DATE",1,6)<='201103' AND
          SUBSTR("STARTING_DATE",1,6)>='201101' AND "STARTING_DATE">='20110101')
   7 - filter("MONTH">='201101' AND "MONTH"<='201103' AND "SHOP_CODE"='1000')


統計
----------------------------------------------------------
      4  recursive calls
     28  db block gets
 302642  consistent gets
 302570  physical reads
   1156  redo size
    875  bytes sent via SQL*Net to client
    519  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      1  sorts (memory)
      0  sorts (disk)
      8  rows processed

ということで、おまけはおしまい、次回へつづく。（どーやってまとめんるんだこれw)

追記（2011/8/3)
次回は、今回チューニングしたGROUPING SETSを利用した文をさらにチューニングするというおまけのおまけ。（ほんと、どーやってまとめんだこれ！）

---

これまでのあらずじ…

・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #1
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #2
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #3
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #4
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #5
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #6

いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #6

2011/7/28追記
GROUPING SETSで異常に遅かったのは使い方わるいなーと m(_ _)m WITH句で一時表１つ使うのと同じぐらいにはなるかもね。と（次回書きます）

前回のつづきでーす。

前回のは、元々がイケテない、かつ、大人の事情でパーティションタイプ変更とか、マテリアライズドビューとか、パラレルクエリーもだーめー。と言いつつ、なんとか、できる限り早くしてくれーという、匂いの元を絶たないで別の匂いでごまかしてくれー的なことだったのですが、いろいろと考えた末、WITH句を使えばなんとかいい感じになりました。でも、元が元だけにほぼ限界ですね。

大人の事情で男らしくずばーっとパーティションタイプ変更することができないとか言ってた方々も、この結果をもって、交渉のテーブルにつけるんじゃないかな。検討祈る :)
この結果で納得してもらえるかは感知しませんからねw 最後の手としてパーティションタイプ変更を残しておいてもいいいと思いますし。;)

ということで、今回は、他の方法との比較編。

前回、grouping setsでもいけそーな感じがすると書いたのですが、grouping setsの場合裏の動きはOracleにお任せなので…

まあ、見てみましょう。

最初は、シンプルにgrouping setsに置き換えて見ました。（深く考えてないので余計な部分はまだまだありそうですがw ）

実行計画と処理時間、アクセスブロック数みて少々意外な結果に驚いたんですよ。　

ダメダメだった元のクエリより処理時間は長くなってる＞＜。　アクセスしているブロック数は随分少なくなっているんですが。CPUへの負荷が高いのか（詳細は別途調べるとして）とにかく前より遅くなっちゃNGです。ただ、クエリ自体は随分読みやすい :)

grouping setsで置き換えた今回のクエリ、実行計画を見るとWITH句で書き換えたときのようものにかなり似ていますが、WITH句で書き換えた場合と大きく異なるのは内部で一時表に置き換えられるタイミングにありそうですね。WITH句は本体のクエリとは別で、しかも一番先に実行されますが、以下の実行計画をみると違いますよね。WITH句で書き換えた実行計画と比較するとその違いがよくわかります。

  1  SELECT
  2      CASE
  3         WHEN quarter IS NULL THEN month
  4         ELSE quarter
  5      END AS month
  6     ,CASE
  7         WHEN grouping_id = 1 THEN 'ALL'
  8         ELSE shop_code
  9      END AS shop_code
 10     ,sales_figure
 11  FROM (
 12     SELECT
 13          grouping_id(shop_code) as grouping_id
 14         ,quarter
 15         ,month
 16         ,shop_code
 17         ,SUM(sales_figure) AS sales_figure
 18     FROM
 19     (
 20         SELECT
 21             CASE
 22                 WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
 23                 WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
 24                 WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 25                 WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 26             END AS quarter
 27             ,SUBSTR(starting_date,1,6) AS month
 28             ,shop_code
 29             ,sales_figure
 30         FROM
 31             test2
 32         WHERE
 33             SUBSTR(starting_date,1,6) BETWEEN '201101' AND '201103'
 34     )
 35     GROUP BY GROUPING SETS (
 36         (month, shop_code),
 37         (quarter, shop_code),
 38         (month),
 39         (quarter)
 40     )
 41  )
 42  WHERE
 43         shop_code = '1000'
 44      OR grouping_id  = 1
 45  ORDER BY
 46       month
 47*     ,shop_code

8行が選択されました。

経過: 00:00:34.88

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

------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name                        | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |                             |   711K|    33M|       | 93048   (3)| 00:18:37 |       |       |
|   1 |  SORT ORDER BY               |                             |   711K|    33M|    43M| 93048   (3)| 00:18:37 |       |       |
|   2 |   VIEW                       |                             |   711K|    33M|       | 84288   (3)| 00:16:52 |       |       |
|   3 |    TEMP TABLE TRANSFORMATION |                             |       |       |       |            |          |       |       |
|   4 |     LOAD AS SELECT           | SYS_TEMP_0FD9D6636_4A53D793 |       |       |       |            |          |       |       |
|   5 |      PARTITION HASH ALL      |                             |    15M|   351M|       | 84280   (3)| 00:16:52 |     1 |     4 |
|*  6 |       TABLE ACCESS FULL      | TEST2                       |    15M|   351M|       | 84280   (3)| 00:16:52 |     1 |     4 |
|   7 |     LOAD AS SELECT           | SYS_TEMP_0FD9D6637_4A53D793 |       |       |       |            |          |       |       |
|   8 |      SORT GROUP BY ROLLUP    |                             |     1 |    33 |       |     3  (34)| 00:00:01 |       |       |
|   9 |       TABLE ACCESS FULL      | SYS_TEMP_0FD9D6636_4A53D793 |     1 |    33 |       |     2   (0)| 00:00:01 |       |       |
|  10 |     LOAD AS SELECT           | SYS_TEMP_0FD9D6637_4A53D793 |       |       |       |            |          |       |       |
|  11 |      SORT GROUP BY ROLLUP    |                             |     1 |    23 |       |     3  (34)| 00:00:01 |       |       |
|  12 |       TABLE ACCESS FULL      | SYS_TEMP_0FD9D6636_4A53D793 |     1 |    23 |       |     2   (0)| 00:00:01 |       |       |
|  13 |     VIEW                     |                             |     1 |    50 |       |     2   (0)| 00:00:01 |       |       |
|* 14 |      TABLE ACCESS FULL       | SYS_TEMP_0FD9D6637_4A53D793 |     1 |    50 |       |     2   (0)| 00:00:01 |       |       |
------------------------------------------------------------------------------------------------------------------------------------

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

   6 - filter(SUBSTR("STARTING_DATE",1,6)<='201103' AND SUBSTR("STARTING_DATE",1,6)>='201101')
  14 - filter("SYS_TEMP_0FD9D6637_4A53D793"."C1"='1000' OR
          BIN_TO_NUM(SYS_OP_VECBIT(SYS_OP_NUMTORAW("SYS_TEMP_0FD9D6637_4A53D793"."D0"),1))=1)


統計
----------------------------------------------------------
    761  recursive calls
  52432  db block gets
 405879  consistent gets
 405750  physical reads
   1944  redo size
    871  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      3  sorts (memory)
      0  sorts (disk)
      8  rows processed

GROUPING SETSで内部的に行われる一時表作成の効率が今ひとつなのであれば、やはり明示的にWITH句で宣言してからやったほうがいいのかな〜ということで、WITH句で一番大きな一時表を作ってみます。

お〜〜〜〜〜〜〜〜〜〜っ。随分変りましたねー。

  1  WITH
  2  t01 AS
  3  (
  4      SELECT
  5           SUBSTR(starting_date,1,6) AS month
  6          ,CASE
  7               WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
  8               WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
  9               WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 10               WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 11          END AS quarter
 12          ,shop_code
 13          ,SUM(sales_figure) as sales_figure
 14      FROM
 15          test2
 16      WHERE
 17          starting_date BETWEEN '20110101' AND '20110331'
 18      GROUP BY
 19          　SUBSTR(starting_date,1,6)
 20          ,SUBSTR(starting_date,5,2)
 21          ,shop_code
 22  )
 23  SELECT
 24      CASE
 25         WHEN quarter IS NULL THEN month
 26         ELSE quarter
 27      END AS month
 28     ,CASE
 29         WHEN grouping_id = 1 THEN 'ALL'
 30         ELSE shop_code
 31      END AS shop_code
 32     ,sales_figure
 33  FROM (
 34     SELECT
 35          grouping_id(shop_code) as grouping_id
 36         ,quarter
 37         ,month
 38         ,shop_code
 39         ,SUM(sales_figure) AS sales_figure
 40     FROM
 41      t01
 42     GROUP BY GROUPING SETS (
 43         (month, shop_code),
 44         (quarter, shop_code),
 45         (month),
 46         (quarter)
 47     )
 48  )
 49  WHERE
 50     shop_code = '1000'
 51     OR grouping_id  = 1
 52  ORDER BY
 53     month
 54*     ,shop_code

8行が選択されました。

経過: 00:00:11.83

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

----------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name                        | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |                             |  2758 |   134K| 83181   (2)| 00:16:39 |       |       |
|   1 |  SORT ORDER BY               |                             |  2758 |   134K| 83181   (2)| 00:16:39 |       |       |
|   2 |   VIEW                       |                             |  2758 |   134K| 83180   (2)| 00:16:39 |       |       |
|   3 |    TEMP TABLE TRANSFORMATION |                             |       |       |            |          |       |       |
|   4 |     LOAD AS SELECT           | SYS_TEMP_0FD9D6650_4A53D793 |       |       |            |          |       |       |
|   5 |      HASH GROUP BY           |                             | 17550 |   411K| 83172   (2)| 00:16:39 |       |       |
|   6 |       PARTITION HASH ALL     |                             |   394K|  9242K| 83161   (2)| 00:16:38 |     1 |     4 |
|*  7 |        TABLE ACCESS FULL     | TEST2                       |   394K|  9242K| 83161   (2)| 00:16:38 |     1 |     4 |
|   8 |     LOAD AS SELECT           | SYS_TEMP_0FD9D6651_4A53D793 |       |       |            |          |       |       |
|   9 |      SORT GROUP BY ROLLUP    |                             |     1 |    33 |     3  (34)| 00:00:01 |       |       |
|  10 |       TABLE ACCESS FULL      | SYS_TEMP_0FD9D6650_4A53D793 |     1 |    33 |     2   (0)| 00:00:01 |       |       |
|  11 |     LOAD AS SELECT           | SYS_TEMP_0FD9D6651_4A53D793 |       |       |            |          |       |       |
|  12 |      SORT GROUP BY ROLLUP    |                             |     1 |    23 |     3  (34)| 00:00:01 |       |       |
|  13 |       TABLE ACCESS FULL      | SYS_TEMP_0FD9D6650_4A53D793 |     1 |    23 |     2   (0)| 00:00:01 |       |       |
|  14 |     VIEW                     |                             |     1 |    50 |     2   (0)| 00:00:01 |       |       |
|* 15 |      TABLE ACCESS FULL       | SYS_TEMP_0FD9D6651_4A53D793 |     1 |    50 |     2   (0)| 00:00:01 |       |       |
----------------------------------------------------------------------------------------------------------------------------

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

   7 - filter("SYS_TBL_$2$"."STARTING_DATE"<='20110331' AND SUBSTR("STARTING_DATE",1,6)<='201103' AND
          SUBSTR("STARTING_DATE",1,6)>='201101' AND "SYS_TBL_$2$"."STARTING_DATE">='20110101')
  15 - filter("SYS_TEMP_0FD9D66B3_4A54062A"."C1"='1000' OR
          BIN_TO_NUM(SYS_OP_VECBIT(SYS_OP_NUMTORAW("SYS_TEMP_0FD9D66B3_4A54062A"."D0"),1))=1)


統計
----------------------------------------------------------
    358  recursive calls
     53  db block gets
 302715  consistent gets
 302589  physical reads
   1712  redo size
    871  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      3  sorts (memory)
      0  sorts (disk)
      8  rows processed

じゃ、WITH句だけで行ったチューニング同様に2つの一時表を作ることにしましょー :)
WITH句で２つの一時表を準備（本体の表へは１度だけアクセス）、かつ、grouping sets を使いunion allの利用は最小限にしてみました。w

読みやすくなったし、速度的にも WITH句で２つの一時表を使う場合と変らないし、GROUPING SETSだけだと今回のような問題は解決しづらいかもしれませんね、今のところ。
可読性の向上にはかなり効果あるとおもいます、GROUPING SETSって。

  1  WITH
  2  t01 AS
  3  (
  4      SELECT
  5           SUBSTR(starting_date,1,6) AS month
  6          ,CASE
  7               WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
  8               WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
  9               WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 10               WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 11          END AS quarter
 12          ,shop_code
 13          ,SUM(sales_figure) as sales_figure
 14      FROM
 15          test2
 16      WHERE
 17          starting_date BETWEEN '20110101' AND '20110331'
 18      GROUP BY
 19          　SUBSTR(starting_date,1,6)
 20          ,SUBSTR(starting_date,5,2)
 21          ,shop_code
 22  ),
 23  t02 AS
 24  (
 25      SELECT
 26           month
 27          ,quarter
 28          ,shop_code
 29          ,sales_figure
 30      FROM
 31          t01
 32      WHERE
 33          month BETWEEN '201101' AND '201103'
 34      AND shop_code = '1000'
 35  )
 36  SELECT
 37      CASE
 38          WHEN quarter IS NULL THEN month
 39          ELSE quarter
 40      END AS month
 41     ,shop_code
 42     ,sales_figure
 43  FROM (
 44      SELECT
 45           quarter
 46          ,month
 47          ,shop_code
 48          ,SUM(sales_figure) AS sales_figure
 49      FROM
 50          t02
 51      GROUP BY GROUPING SETS (
 52          (month, shop_code),
 53          (quarter, shop_code)
 54      )
 55      UNION ALL
 56      SELECT
 57           quarter
 58          ,month
 59          ,'ALL' AS shop_code
 60          ,SUM(sales_figure) AS sales_figure
 61      FROM
 62          t01
 63      GROUP BY GROUPING SETS (
 64          (month),
 65          (quarter)
 66      )
 67  )
 68  ORDER BY
 69       month
 70*     ,shop_code

8行が選択されました。

経過: 00:00:08.34

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

------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name                        | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                             |    17 |   595 | 83223   (2)| 00:16:39 |       |       |
|   1 |  TEMP TABLE TRANSFORMATION     |                             |       |       |            |          |       |       |
|   2 |   LOAD AS SELECT               | SYS_TEMP_0FD9D667D_4A53D793 |       |       |            |          |       |       |
|   3 |    HASH GROUP BY               |                             | 17550 |   411K| 83172   (2)| 00:16:39 |       |       |
|   4 |     PARTITION HASH ALL         |                             |   394K|  9242K| 83161   (2)| 00:16:38 |     1 |     4 |
|*  5 |      TABLE ACCESS FULL         | TEST2                       |   394K|  9242K| 83161   (2)| 00:16:38 |     1 |     4 |
|   6 |   SORT ORDER BY                |                             |    17 |   595 |    51  (10)| 00:00:01 |       |       |
|   7 |    VIEW                        |                             |    17 |   595 |    50   (8)| 00:00:01 |       |       |
|   8 |     UNION-ALL                  |                             |       |       |            |          |       |       |
|   9 |      TEMP TABLE TRANSFORMATION |                             |       |       |            |          |       |       |
|  10 |       LOAD AS SELECT           | SYS_TEMP_0FD9D667E_4A53D793 |       |       |            |          |       |       |
|* 11 |        TABLE ACCESS FULL       | SYS_TEMP_0FD9D667D_4A53D793 |     1 |    24 |    17   (0)| 00:00:01 |       |       |
|  12 |       LOAD AS SELECT           | SYS_TEMP_0FD9D667F_4A53D793 |       |       |            |          |       |       |
|  13 |        HASH GROUP BY           |                             |     1 |    33 |     3  (34)| 00:00:01 |       |       |
|  14 |     TABLE ACCESS FULL          | SYS_TEMP_0FD9D667E_4A53D793 |     1 |    33 |     2   (0)| 00:00:01 |       |       |
|  15 |       LOAD AS SELECT           | SYS_TEMP_0FD9D667F_4A53D793 |       |       |            |          |       |       |
|  16 |        HASH GROUP BY           |                             |     1 |    23 |     3  (34)| 00:00:01 |       |       |
|  17 |     TABLE ACCESS FULL          | SYS_TEMP_0FD9D667E_4A53D793 |     1 |    23 |     2   (0)| 00:00:01 |       |       |
|  18 |       VIEW                     |                             |     1 |    37 |     2   (0)| 00:00:01 |       |       |
|  19 |        TABLE ACCESS FULL       | SYS_TEMP_0FD9D667F_4A53D793 |     1 |    37 |     2   (0)| 00:00:01 |       |       |
|  20 |      TEMP TABLE TRANSFORMATION |                             |       |       |            |          |       |       |
|  21 |       LOAD AS SELECT           | SYS_TEMP_0FD9D6680_4A53D793 |       |       |            |          |       |       |
|  22 |        TABLE ACCESS FULL       | SYS_TEMP_0FD9D667D_4A53D793 | 17550 |   411K|    17   (0)| 00:00:01 |       |       |
|  23 |       LOAD AS SELECT           | SYS_TEMP_0FD9D6681_4A53D793 |       |       |            |          |       |       |
|  24 |        HASH GROUP BY           |                             |     1 |    27 |     3  (34)| 00:00:01 |       |       |
|  25 |     TABLE ACCESS FULL          | SYS_TEMP_0FD9D6680_4A53D793 |     1 |    27 |     2   (0)| 00:00:01 |       |       |
|  26 |       LOAD AS SELECT           | SYS_TEMP_0FD9D6681_4A53D793 |       |       |            |          |       |       |
|  27 |        HASH GROUP BY           |                             |     1 |    17 |     3  (34)| 00:00:01 |       |       |
|  28 |     TABLE ACCESS FULL          | SYS_TEMP_0FD9D6680_4A53D793 |     1 |    17 |     2   (0)| 00:00:01 |       |       |
|  29 |       VIEW                     |                             |     1 |    31 |     2   (0)| 00:00:01 |       |       |
|  30 |        TABLE ACCESS FULL       | SYS_TEMP_0FD9D6681_4A53D793 |     1 |    31 |     2   (0)| 00:00:01 |       |       |
------------------------------------------------------------------------------------------------------------------------------

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

   5 - filter("STARTING_DATE"<='20110331' AND SUBSTR("STARTING_DATE",1,6)<='201103' AND
          SUBSTR("STARTING_DATE",1,6)>='201101' AND "STARTING_DATE">='20110101')
  11 - filter("SYS_TBL_$2$"."C0">='201101' AND "SYS_TBL_$2$"."C0"<='201103' AND "SYS_TBL_$2$"."C2"='1000')


統計
----------------------------------------------------------
    790  recursive calls
     82  db block gets
 302843  consistent gets
 302593  physical reads
   3964  redo size
    871  bytes sent via SQL*Net to client
    520  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      1  sorts (memory)
      0  sorts (disk)
      8  rows processed

次回は、月毎のレンジパーティションで同じ対処をしたらとこまで改善するのか確認しておきましょう。

---

これまでのあらずじ…

・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #1
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #2
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #3
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #4
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #5

いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #5

前回のつづきです。

さて、前回登場したボスキャラなSQL。どう料理しましょーか。
前回は、まずは肩ならし程度のチューニングをしましたがそれほど改善していません。(^^;;;; 元が元ですからね。

このままでは多いく改善することはむーりー、なので構文変更を前提にしましょう。

で、このクエリをよーく見ていたら、店、品目毎の日単位の売上げデータから、店毎の月単位売上げ合計と四半期の売上げ合計、全店の月単位売上げ合計、四半期の売上げ合計を求めるクエリだとわかりました。

本来なら月単位のレンジパーティション表とか、マテリアライズドビューでも用意しておけばすげー簡単な話ではあるんですが、パーティションタイプの変更とかマテリアライズドビューの追加作成とかむーりーと言われてしまう大人の事情が因縁をつけてきますw

でも、じ〜〜〜〜〜〜っと、このSQL文を見ていると改善案が見えてきます。大きな無駄が……………………見えてきますよね。ほーら、ほーらw

  1  SELECT
  2       month
  3      ,shop_code
  4      ,sales_figure
  5  FROM
  6  (
  7      SELECT
  8           SUBSTR(starting_date,1,6) AS month
  9          ,shop_code
 10          ,SUM(sales_figure) AS sales_figure
 11      FROM
 12          test2
 13      WHERE
 14          starting_date BETWEEN '20110101' AND '20110331'
 15      AND shop_code = '1000'
 16      GROUP BY
 17           SUBSTR(starting_date,1,6)
 18          ,shop_code
 19      UNION ALL
 20      SELECT
 21          CASE
 22              WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
 23              WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
 24              WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 25              WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 26          END AS month
 27          ,shop_code
 28          ,SUM(sales_figure) AS salles_figure
 29      FROM
 30          test2
 31      WHERE
 32          starting_date BETWEEN '20110101' AND '20110331'
 33      AND shop_code = '1000'
 34      GROUP BY
 35          CASE
 36              WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
 37              WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
 38              WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 39              WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 40          END
 41          ,shop_code
 42      UNION ALL
 43      SELECT
 44           SUBSTR(starting_date,1,6) AS month
 45          ,'ALL ' AS shop_code
 46          ,SUM(sales_figure) AS sales_figure
 47      FROM
 48          test2
 49      WHERE
 50          starting_date BETWEEN '20110101' AND '20110331'
 51      GROUP BY
 52          SUBSTR(starting_date,1,6)
 53      UNION ALL
 54      SELECT
 55          CASE
 56              WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
 57              WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
 58              WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 59              WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 60          END AS month
 61          ,'ALL ' AS shop_code
 62          ,SUM(sales_figure) AS salles_figure
 63      FROM
 64          test2
 65      WHERE
 66          starting_date BETWEEN '20110101' AND '20110331'
 67      GROUP BY
 68          CASE
 69              WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
 70              WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
 71              WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 72              WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 73          END
 74  )
 75  ORDER BY
 76       month
 77*     ,shop_code

8行が選択されました。

経過: 00:00:21.03

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

-------------------------------------------------------------------------------------------------------------------
| Id  | Operation                              | Name       | Rows  | Bytes | Cost (%CPU)| Time     |Pstart|Pstop |
-------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                       |            |    22 |   726 |   166K  (2)| 00:33:18 |      |      |
|   1 |  SORT ORDER BY                         |            |    22 |   726 |   166K  (2)| 00:33:18 |      |      |
|   2 |   VIEW                                 |            |    22 |   726 |   166K  (2)| 00:33:18 |      |      |
|   3 |    UNION-ALL                           |            |       |       |            |          |      |      |
|   4 |     HASH GROUP BY                      |            |     3 |    72 |    43   (3)| 00:00:01 |      |      |
|   5 |      PARTITION HASH ALL                |            |   303 |  7272 |    42   (0)| 00:00:01 |    1 |    4 |
|   6 |       TABLE ACCESS BY LOCAL INDEX ROWID| TEST2      |   303 |  7272 |    42   (0)| 00:00:01 |    1 |    4 |
|*  7 |        INDEX RANGE SCAN                | PK_TEST2   |   303 |       |    19   (0)| 00:00:01 |    1 |    4 |
|   8 |     HASH GROUP BY                      |            |     7 |   119 |    43   (3)| 00:00:01 |      |      |
|   9 |      PARTITION HASH ALL                |            |   303 |  5151 |    42   (0)| 00:00:01 |    1 |    4 |
|  10 |       TABLE ACCESS BY LOCAL INDEX ROWID| TEST2      |   303 |  5151 |    42   (0)| 00:00:01 |    1 |    4 |
|* 11 |        INDEX RANGE SCAN                | PK_TEST2   |   303 |       |    19   (0)| 00:00:01 |    1 |    4 |
|  12 |     HASH GROUP BY                      |            |     3 |    57 | 83172   (2)| 00:16:39 |      |      |
|  13 |      PARTITION HASH ALL                |            |   394K|  7316K| 83161   (2)| 00:16:38 |    1 |    4 |
|* 14 |       TABLE ACCESS FULL                | TEST2      |   394K|  7316K| 83161   (2)| 00:16:38 |    1 |    4 |
|  15 |     HASH GROUP BY                      |            |     9 |   108 | 83172   (2)| 00:16:39 |      |      |
|  16 |      PARTITION HASH ALL                |            |   394K|  4621K| 83161   (2)| 00:16:38 |    1 |    4 |
|* 17 |       TABLE ACCESS FULL                | TEST2      |   394K|  4621K| 83161   (2)| 00:16:38 |    1 |    4 |
-------------------------------------------------------------------------------------------------------------------

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

   7 - access("SHOP_CODE"='1000' AND "STARTING_DATE">='20110101' AND "STARTING_DATE"<='20110331')
       filter(SUBSTR("STARTING_DATE",1,6)<='201103' AND SUBSTR("STARTING_DATE",1,6)>='201101')
  11 - access("SHOP_CODE"='1000' AND "STARTING_DATE">='20110101' AND "STARTING_DATE"<='20110331')
       filter(SUBSTR("STARTING_DATE",1,6)<='201103' AND SUBSTR("STARTING_DATE",1,6)>='201101')
  14 - filter("STARTING_DATE"<='20110331' AND SUBSTR("STARTING_DATE",1,6)<='201103' AND
          SUBSTR("STARTING_DATE",1,6)>='201101' AND "STARTING_DATE">='20110101')
  17 - filter("STARTING_DATE"<='20110331' AND SUBSTR("STARTING_DATE",1,6)<='201103' AND
          SUBSTR("STARTING_DATE",1,6)>='201101' AND "STARTING_DATE">='20110101')


統計
----------------------------------------------------------
      0  recursive calls
      0  db block gets
 606978  consistent gets
 605112  physical reads
      0  redo size
    875  bytes sent via SQL*Net to client
    519  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      1  sorts (memory)
      0  sorts (disk)
      8  rows processed

03:43:16 SCOTT> 

見えてきましたよね、無駄が。

このクエリ、同じ検索範囲のデータを対象に４回もTEST2表にアクセスしています。全表走査２回、改善したとはいえ２回の全ローカル索引のレンジスキャンを行っています。無駄なアクセスが多すぎます。
こんなタイプのUNION ALLやUNION繰り返しタイプのクエリを改善できる方法は……

まず浮かんだのは、WITH句を使って各クエリの共通部分をまとめてしまう方法です。

WITH句に記述したクエリは最初に１度実行され結果を一時セグメントに溜め込みます。その後、一時セグメントに溜め込んだ結果を使い回せばいいので巨大な表本体を何度も参照する必要がなくなります。
そうそう、うまく使えば、都度使い捨てのマテリアライズドビュー（例えが良くないですが気にしないでね）みたいな使い方ができます。

書き換えのポイントは一番大きな範囲で集計する共通部分を見つけ出してWITH句にまとめてしまうこと！
あとはその結果をうまく使い回すこと！　　それだけです。　SQL文も共通部分をWITH句にまとめたことで随分読みやすくなりましたよね。　直感的に読みやすい訳ではないですがね。：）

以下、書き換えた結果…

  1  WITH
  2  t01 AS
  3  (
  4      SELECT
  5           SUBSTR(starting_date,1,6) AS month
  6          ,CASE
  7               WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
  8               WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
  9               WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 10               WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 11          END AS quarter
 12          ,shop_code
 13          ,SUM(sales_figure) as sales_figure
 14      FROM
 15          test2
 16      WHERE
 17          starting_date BETWEEN '20110101' AND '20110331'
 18      GROUP BY
 19           SUBSTR(starting_date,1,6)
 20          ,SUBSTR(starting_date,5,2)
 21          ,shop_code
 22  ),
 23  t02 AS
 24  (
 25      SELECT
 26           month
 27          ,quarter
 28          ,shop_code
 29          ,sales_figure
 30      FROM
 31          t01
 32      WHERE
 33          month BETWEEN '201101' AND '201103'
 34      AND shop_code = '1000'
 35  )
 36  SELECT
 37       month
 38      ,shop_code
 39      ,sales_figure
 40  FROM
 41  (
 42      SELECT
 43           month
 44          ,shop_code
 45          ,SUM(sales_figure) AS sales_figure
 46      FROM
 47          t02
 48      GROUP BY
 49           month
 50          ,shop_code
 51      UNION ALL
 52      SELECT
 53           quarter AS month
 54          ,shop_code
 55          ,SUM(sales_figure) AS sales_figure
 56      FROM
 57          t02
 58      GROUP BY
 59           quarter
 60          ,shop_code
 61      UNION ALL
 62      SELECT
 63           month
 64          ,'ALL ' AS shop_code
 65          ,SUM(sales_figure) AS sales_figure
 66      FROM
 67          t01
 68      GROUP BY
 69          month
 70      UNION ALL
 71      SELECT
 72           quarter AS month
 73          ,'ALL ' AS shop_code
 74          ,SUM(sales_figure) AS salles_figure
 75      FROM
 76          t01
 77      GROUP BY
 78          quarter
 79  )
 80  ORDER BY
 81       month
 82*     ,shop_code

8行が選択されました。

経過: 00:00:08.35

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

--------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                  | Name                        | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
--------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |                             |  3692 |   118K| 83282   (2)| 00:16:40 |       |       |
|   1 |  TEMP TABLE TRANSFORMATION |                             |       |       |            |          |       |       |
|   2 |   LOAD AS SELECT           | SYS_TEMP_0FD9D660A_4A53712A |       |       |            |          |       |       |
|   3 |    HASH GROUP BY           |                             | 17550 |   411K| 83172   (2)| 00:16:39 |       |       |
|   4 |     PARTITION HASH ALL     |                             |   394K|  9242K| 83161   (2)| 00:16:38 |     1 |     4 |
|*  5 |      TABLE ACCESS FULL     | TEST2                       |   394K|  9242K| 83161   (2)| 00:16:38 |     1 |     4 |
|   6 |   LOAD AS SELECT           | SYS_TEMP_0FD9D660B_4A53712A |       |       |            |          |       |       |
|*  7 |    VIEW                    |                             | 17550 |   497K|    17   (0)| 00:00:01 |       |       |
|   8 |     TABLE ACCESS FULL      | SYS_TEMP_0FD9D660A_4A53712A | 17550 |   411K|    17   (0)| 00:00:01 |       |       |
|   9 |   SORT ORDER BY            |                             |  3692 |   118K|    93   (8)| 00:00:02 |       |       |
|  10 |    VIEW                    |                             |  3692 |   118K|    92   (7)| 00:00:02 |       |       |
|  11 |     UNION-ALL              |                             |       |       |            |          |       |       |
|  12 |      HASH GROUP BY         |                             |  2758 | 68950 |    27   (4)| 00:00:01 |       |       |
|  13 |       VIEW                 |                             | 17550 |   428K|    26   (0)| 00:00:01 |       |       |
|  14 |        TABLE ACCESS FULL   | SYS_TEMP_0FD9D660B_4A53712A | 17550 |   497K|    26   (0)| 00:00:01 |       |       |
|  15 |      HASH GROUP BY         |                             |   920 | 20240 |    27   (4)| 00:00:01 |       |       |
|  16 |       VIEW                 |                             | 17550 |   377K|    26   (0)| 00:00:01 |       |       |
|  17 |        TABLE ACCESS FULL   | SYS_TEMP_0FD9D660B_4A53712A | 17550 |   497K|    26   (0)| 00:00:01 |       |       |
|  18 |      HASH GROUP BY         |                             |    13 |   260 |    18   (6)| 00:00:01 |       |       |
|  19 |       VIEW                 |                             | 17550 |   342K|    17   (0)| 00:00:01 |       |       |
|  20 |        TABLE ACCESS FULL   | SYS_TEMP_0FD9D660A_4A53712A | 17550 |   411K|    17   (0)| 00:00:01 |       |       |
|  21 |      HASH GROUP BY         |                             |     1 |    17 |    18   (6)| 00:00:01 |       |       |
|  22 |       VIEW                 |                             | 17550 |   291K|    17   (0)| 00:00:01 |       |       |
|  23 |        TABLE ACCESS FULL   | SYS_TEMP_0FD9D660A_4A53712A | 17550 |   411K|    17   (0)| 00:00:01 |       |       |
--------------------------------------------------------------------------------------------------------------------------

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

   5 - filter("STARTING_DATE"<='20110331' AND SUBSTR("STARTING_DATE",1,6)<='201103' AND
          SUBSTR("STARTING_DATE",1,6)>='201101' AND "STARTING_DATE">='20110101')
   7 - filter("MONTH">='201101' AND "MONTH"<='201103' AND "SHOP_CODE"='1000')


統計
----------------------------------------------------------
      4  recursive calls
     28  db block gets
 302642  consistent gets
 302570  physical reads
   1156  redo size
    875  bytes sent via SQL*Net to client
    519  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      1  sorts (memory)
      0  sorts (disk)
      8  rows processed

04:15:55 SCOTT> 

アクセスしているブロック数は約１／２に減少し処理時間も２０秒台から８秒台へ改善することができました。バンザーイ！w

ついでなので、オラクル任せのパラレルクエリだとどうなるか試してみました。（CPUたくさんあるんでw)
アクセスブロック数は少々増えますが、パラレルの良さが出ています。２秒台になりましたー。しかしーw 、影響が大きいのでこのときは参考出品で、ここまでできるよーって話のネタだけにしときました :)

  1  WITH
  2  t01 AS
  3  (
  4      SELECT
  5           SUBSTR(starting_date,1,6) AS month
  6          ,CASE
  7               WHEN SUBSTR(starting_date,5,2) BETWEEN '04' AND '06' THEN 'Q1'
  8               WHEN SUBSTR(starting_date,5,2) BETWEEN '07' AND '09' THEN 'Q2'
  9               WHEN SUBSTR(starting_date,5,2) BETWEEN '10' AND '12' THEN 'Q3'
 10               WHEN SUBSTR(starting_date,5,2) BETWEEN '01' AND '03' THEN 'Q4'
 11          END AS quarter
 12          ,shop_code
 13          ,SUM(sales_figure) as sales_figure
 14      FROM
 15           test2
 16      WHERE
 17           starting_date BETWEEN '20110101' AND '20110331'
 18      GROUP BY
 19           SUBSTR(starting_date,1,6)
 20          ,SUBSTR(starting_date,5,2)
 21          ,shop_code
 22  ),
 23  t02 AS
 24  (
 25      SELECT
 26           month
 27          ,quarter
 28          ,shop_code
 29          ,sales_figure
 30      FROM
 31          t01
 32      WHERE
 33          month BETWEEN '201101' AND '201103'
 34      AND shop_code = '1000'
 35  )
 36  SELECT  /*+ PARALLEL */
 37      month
 38      ,shop_code
 39      ,sales_figure
 40  FROM
 41  (
 42      SELECT
 43           month
 44          ,shop_code
 45          ,SUM(sales_figure) AS sales_figure
 46      FROM
 47          t02
 48      GROUP BY
 49           month
 50          ,shop_code
 51      UNION ALL
 52      SELECT
 53           quarter AS month
 54          ,shop_code
 55          ,SUM(sales_figure) AS sales_figure
 56      FROM
 57          t02
 58       GROUP BY
 59           quarter
 60          ,shop_code
 61      UNION ALL
 62      SELECT
 63           month
 64          ,'ALL ' AS shop_code
 65          ,SUM(sales_figure) AS sales_figure
 66      FROM
 67          t01
 68      GROUP BY
 69          month
 70      UNION ALL
 71      SELECT
 72           quarter AS month
 73          ,'ALL ' AS shop_code
 74          ,SUM(sales_figure) AS salles_figure
 75      FROM
 76          t01
 77      GROUP BY
 78          quarter
 79  )
 80  ORDER BY
 81       month
 82*     ,shop_code

8行が選択されました。

経過: 00:00:02.98

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

-------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name                        | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ    |IN-OUT| PQ Distrib |
-------------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                             |  3692 |   118K|  5787   (2)| 00:01:10 |       |       |          |      |            |
|   1 |  TEMP TABLE TRANSFORMATION     |                             |       |       |            |          |       |       |          |      |            |
|   2 |   PX COORDINATOR               |                             |       |       |            |          |       |       |          |      |            |
|   3 |    PX SEND QC (RANDOM)         | :TQ10001                    | 17550 |   411K|  5772   (2)| 00:01:10 |       |       |  Q1,01   | P->S | QC (RAND)  |
|   4 |     LOAD AS SELECT             | SYS_TEMP_0FD9D6626_4A53712A |       |       |            |          |       |       |  Q1,01   | PCWP |            |
|   5 |      HASH GROUP BY             |                             | 17550 |   411K|  5772   (2)| 00:01:10 |       |       |  Q1,01   | PCWP |            |
|   6 |       PX RECEIVE               |                             | 17550 |   411K|  5772   (2)| 00:01:10 |       |       |  Q1,01   | PCWP |            |
|   7 |        PX SEND HASH            | :TQ10000                    | 17550 |   411K|  5772   (2)| 00:01:10 |       |       |  Q1,00   | P->P | HASH       |
|   8 |     HASH GROUP BY              |                             | 17550 |   411K|  5772   (2)| 00:01:10 |       |       |  Q1,00   | PCWP |            |
|   9 |      PX BLOCK ITERATOR         |                             |   394K|  9242K|  5770   (2)| 00:01:10 |     1 |     4 |  Q1,00   | PCWC |            |
|* 10 |       TABLE ACCESS FULL        | TEST2                       |   394K|  9242K|  5770   (2)| 00:01:10 |     1 |     4 |  Q1,00   | PCWP |            |
|  11 |   PX COORDINATOR               |                             |       |       |            |          |       |       |          |      |            |
|  12 |    PX SEND QC (RANDOM)         | :TQ20000                    | 17550 |   497K|     2   (0)| 00:00:01 |       |       |  Q2,00   | P->S | QC (RAND)  |
|  13 |     LOAD AS SELECT             | SYS_TEMP_0FD9D6627_4A53712A |       |       |            |          |       |       |  Q2,00   | PCWP |            |
|* 14 |      VIEW                      |                             | 17550 |   497K|     2   (0)| 00:00:01 |       |       |  Q2,00   | PCWP |            |
|  15 |       PX BLOCK ITERATOR        |                             | 17550 |   411K|     2   (0)| 00:00:01 |       |       |  Q2,00   | PCWC |            |
|  16 |        TABLE ACCESS FULL       | SYS_TEMP_0FD9D6626_4A53712A | 17550 |   411K|     2   (0)| 00:00:01 |       |       |  Q2,00   | PCWP |            |
|  17 |   PX COORDINATOR               |                             |       |       |            |          |       |       |          |      |            |
|  18 |    PX SEND QC (ORDER)          | :TQ30005                    |  3692 |   118K|    13  (39)| 00:00:01 |       |       |  Q3,05   | P->S | QC (ORDER) |
|  19 |     SORT ORDER BY              |                             |  3692 |   118K|    13  (39)| 00:00:01 |       |       |  Q3,05   | PCWP |            |
|  20 |      PX RECEIVE                |                             |  3692 |   118K|    12  (34)| 00:00:01 |       |       |  Q3,05   | PCWP |            |
|  21 |       PX SEND RANGE            | :TQ30004                    |  3692 |   118K|    12  (34)| 00:00:01 |       |       |  Q3,04   | P->P | RANGE      |
|  22 |        BUFFER SORT             |                             |  3692 |   118K|            |          |       |       |  Q3,04   | PCWP |            |
|  23 |     VIEW                       |                             |  3692 |   118K|    12  (34)| 00:00:01 |       |       |  Q3,04   | PCWP |            |
|  24 |      UNION-ALL                 |                             |       |       |            |          |       |       |  Q3,04   | PCWP |            |
|  25 |       HASH GROUP BY            |                             |  2758 | 68950 |     3  (34)| 00:00:01 |       |       |  Q3,04   | PCWP |            |
|  26 |        PX RECEIVE              |                             |  2758 | 68950 |     3  (34)| 00:00:01 |       |       |  Q3,04   | PCWP |            |
|  27 |         PX SEND HASH           | :TQ30000                    |  2758 | 68950 |     3  (34)| 00:00:01 |       |       |  Q3,00   | P->P | HASH       |
|  28 |          HASH GROUP BY         |                             |  2758 | 68950 |     3  (34)| 00:00:01 |       |       |  Q3,00   | PCWP |            |
|  29 |           VIEW                 |                             | 17550 |   428K|     2   (0)| 00:00:01 |       |       |  Q3,00   | PCWP |            |
|  30 |            PX BLOCK ITERATOR   |                             | 17550 |   497K|     2   (0)| 00:00:01 |       |       |  Q3,00   | PCWC |            |
|  31 |         TABLE ACCESS FULL      | SYS_TEMP_0FD9D6627_4A53712A | 17550 |   497K|     2   (0)| 00:00:01 |       |       |  Q3,00   | PCWP |            |
|  32 |       HASH GROUP BY            |                             |   920 | 20240 |     3  (34)| 00:00:01 |       |       |  Q3,04   | PCWP |            |
|  33 |        PX RECEIVE              |                             |   920 | 20240 |     3  (34)| 00:00:01 |       |       |  Q3,04   | PCWP |            |
|  34 |         PX SEND HASH           | :TQ30001                    |   920 | 20240 |     3  (34)| 00:00:01 |       |       |  Q3,01   | P->P | HASH       |
|  35 |          HASH GROUP BY         |                             |   920 | 20240 |     3  (34)| 00:00:01 |       |       |  Q3,01   | PCWP |            |
|  36 |           VIEW                 |                             | 17550 |   377K|     2   (0)| 00:00:01 |       |       |  Q3,01   | PCWP |            |
|  37 |            PX BLOCK ITERATOR   |                             | 17550 |   497K|     2   (0)| 00:00:01 |       |       |  Q3,01   | PCWC |            |
|  38 |         TABLE ACCESS FULL      | SYS_TEMP_0FD9D6627_4A53712A | 17550 |   497K|     2   (0)| 00:00:01 |       |       |  Q3,01   | PCWP |            |
|  39 |       HASH GROUP BY            |                             |    13 |   260 |     3  (34)| 00:00:01 |       |       |  Q3,04   | PCWP |            |
|  40 |        PX RECEIVE              |                             |    13 |   260 |     3  (34)| 00:00:01 |       |       |  Q3,04   | PCWP |            |
|  41 |         PX SEND HASH           | :TQ30002                    |    13 |   260 |     3  (34)| 00:00:01 |       |       |  Q3,02   | P->P | HASH       |
|  42 |          HASH GROUP BY         |                             |    13 |   260 |     3  (34)| 00:00:01 |       |       |  Q3,02   | PCWP |            |
|  43 |           VIEW                 |                             | 17550 |   342K|     2   (0)| 00:00:01 |       |       |  Q3,02   | PCWP |            |
|  44 |            PX BLOCK ITERATOR   |                             | 17550 |   411K|     2   (0)| 00:00:01 |       |       |  Q3,02   | PCWC |            |
|  45 |         TABLE ACCESS FULL      | SYS_TEMP_0FD9D6626_4A53712A | 17550 |   411K|     2   (0)| 00:00:01 |       |       |  Q3,02   | PCWP |            |
|  46 |       HASH GROUP BY            |                             |     1 |    17 |     3  (34)| 00:00:01 |       |       |  Q3,04   | PCWP |            |
|  47 |        PX RECEIVE              |                             |     1 |    17 |     3  (34)| 00:00:01 |       |       |  Q3,04   | PCWP |            |
|  48 |         PX SEND HASH           | :TQ30003                    |     1 |    17 |     3  (34)| 00:00:01 |       |       |  Q3,03   | P->P | HASH       |
|  49 |          HASH GROUP BY         |                             |     1 |    17 |     3  (34)| 00:00:01 |       |       |  Q3,03   | PCWP |            |
|  50 |           VIEW                 |                             | 17550 |   291K|     2   (0)| 00:00:01 |       |       |  Q3,03   | PCWP |            |
|  51 |            PX BLOCK ITERATOR   |                             | 17550 |   411K|     2   (0)| 00:00:01 |       |       |  Q3,03   | PCWC |            |
|  52 |         TABLE ACCESS FULL      | SYS_TEMP_0FD9D6626_4A53712A | 17550 |   411K|     2   (0)| 00:00:01 |       |       |  Q3,03   | PCWP |            |
-------------------------------------------------------------------------------------------------------------------------------------------------------------

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

  10 - filter("STARTING_DATE"<='20110331' AND SUBSTR("STARTING_DATE",1,6)<='201103' AND SUBSTR("STARTING_DATE",1,6)>='201101' AND
          "STARTING_DATE">='20110101')
  14 - filter("MONTH">='201101' AND "MONTH"<='201103' AND "SHOP_CODE"='1000')

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


統計
----------------------------------------------------------
    348  recursive calls
   5435  db block gets
 318993  consistent gets
 309118  physical reads
 310176  redo size
    875  bytes sent via SQL*Net to client
    519  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
     33  sorts (memory)
      0  sorts (disk)
      8  rows processed

04:31:33 SCOTT> 

パラレルクエリの話は一旦横に置いといて（月単位のレンジパーティションならもっと良い結果がでそうですがそれはまた別途ということで…

WITH句以外にもGROUPING SETも効果がありそうではあります。次回は、それらを試して結果を比較してみようかと…。

つづく。

---

これまでのあらずじ…

・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #1
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #2
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #3
・いろいろと面倒くさい大人の事情縛りのOracleパフォーマンスチューニング #4

shutdown immeidateしない、ほかの理由に遭遇！ おまけのおまけ（でた〜最近、よくあるパターンw）

さて、前回のおまけで終了〜。　のつもりだったがリスナー経由の時は問題ないな〜と気づいて気が変わり。おまけのおまけとなりましたw

前回まではBEQで繋いでたな〜、と思ってリスナー経由の専用サーバー接続で同じことを試してみたらshutdown immeidateが待機させられない事に気づいた。

お〜〜〜〜っ。oracleのサーバープロセスがdefunctのにならないっつーことは…

ということで、早速試してみた。

※１つめの端末でSQL*Plusを起動してOracleをスタートアップ（なお事前にリスナーは起動済みです）

[oracle@lampeye ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.7.0 - Production on 水 2月 16 23:10:11 2011

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

23:10:11 > conn / as sysdba
接続されました。
23:21:54 SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area 1603411968 bytes
Fixed Size                  2160112 bytes
Variable Size             436210192 bytes
Database Buffers         1157627904 bytes
Redo Buffers                7413760 bytes
データベースがマウントされました。
データベースがオープンされました。
23:22:04 SYS> 

※２つめの端末でSQL*Plusを起動してリスナー経由（この例では専用サーバー接続）でOracleへ接続後、host command(!)でshellへ入っておく。

[oracle@lampeye ˜]$ 
[oracle@lampeye ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.7.0 - Production on 水 2月 16 23:22:45 2011

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

23:22:45 > conn scott/tiger@lampeye
接続されました。
23:22:53 SCOTT> !
[oracle@lampeye ˜]$ 

※この状態で、プロセスツリーをチェックしてみると…Bequeath Protocol接続の時は、PID=5398の子プロセスとしてOracleのサーバープロセスがforkされていたのに、居ないのよ…

[oracle@lampeye ˜]$ ps -ef | grep gnome-terminal
oracle    4976     1  0 23:08 ?        00:00:01 gnome-terminal
oracle    5440  5031  0 23:23 pts/3    00:00:00 grep gnome-terminal
[oracle@lampeye ˜]$ 
[oracle@lampeye ˜]$ pstree -p 4976 -ual 
gnome-terminal,4976,oracle
  ├─bash,4982
  │   └─sqlplus,5154       
  │       └─oracle,5376 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
  ├─bash,5007
  │   └─sqlplus,5398       
  │       └─bash,5413
  ├─bash,5031
  │   └─pstree,5441 -p 4976 -ual
  ├─bash,5161
  ├─gnome-pty-helpe,4981
  └─{gnome-terminal},4983
[oracle@lampeye ˜]$ 

※じゃ、どこに行ったのよ…と、調べてみると…リスナー経由だとサーバープロセスの親プロセスはINIT

23:29:17 SYS> select s.username,p.username,p.spid from v$process p join v$session s on p.addr = s.paddr where s.username='SCOTT'

USERNAME                       USERNAME        SPID
------------------------------ --------------- ------------------------
SCOTT                          oracle          5400

経過: 00:00:00.01
23:29:18 SYS> 

[oracle@lampeye ˜]$ ps -f -p 5400
UID        PID  PPID  C STIME TTY          TIME CMD
oracle    5400     1  0 23:22 ?        00:00:00 oraclelampeye (LOCAL=NO)
[oracle@lampeye ˜]$ 

※これならshutdown immeidateは待たされずに実行される！

23:35:22 SYS> 
23:35:22 SYS> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
23:35:33 SYS> 

ということは、SQL*PlusからBequeath Protocol接続の場合、host commandでshellへ入ったままにしているとshutdown immeidateが待機させられるのな…

じゃ、sqlnet.ora　に　BEQUEATH_DETACH=yes　を設定すれば回避できそーな気がする
Oracle Database Net Servicesリファレンス 11g リリース1（11.1）- 5.2.1 BEQUEATH_DETACH

早速、検証…

sqlnet.oraにBEQUEATH_DETACH=yesを追記。

[oracle@lampeye ˜]$ 
[oracle@lampeye ˜]$ cat  $ORACLE_HOME/network/admin/sqlnet.ora
# sqlnet.ora Network Configuration File: /opt/u01/app/oracle/product/11.1.0/db_1/network/admin/sqlnet.ora
# Generated by Oracle configuration tools.

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
BEQUEATH_DETACH=yes

[oracle@lampeye ˜]$ 

※１つめの端末でSQL*Plusを起動し、Oracleをstartup…

[oracle@lampeye ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.7.0 - Production on 水 2月 16 23:39:14 2011

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

23:39:14 > conn / as sysdba
アイドル・インスタンスに接続しました。
23:39:17 SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area 1603411968 bytes
Fixed Size                  2160112 bytes
Variable Size             436210192 bytes
Database Buffers         1157627904 bytes
Redo Buffers                7413760 bytes
データベースがマウントされました。
データベースがオープンされました。
23:39:26 SYS> 

※２つめの端末でSQL*Plusを起動、BEQ接続でSCOTTユーザへ接続後、host command(!)でshellへ入っておく…

[oracle@lampeye ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.7.0 - Production on 水 2月 16 23:39:39 2011

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

23:39:39 > conn scott/tiger
接続されました。
23:39:45 SCOTT> !
[oracle@lampeye ˜]$ 

※この状態でプロセスツリーを見てみると…お〜〜〜、SQL*Plusの子プロセスではなくなっている…

[oracle@lampeye ˜]$ pstree -p 4976 -ual 
gnome-terminal,4976,oracle
  ├─bash,4982
  │   └─sqlplus,5596       
  ├─bash,5007
  │   └─sqlplus,5664       
  │       └─bash,5686
  ├─bash,5031
  │   └─pstree,5711 -p 4976 -ual
  ├─bash,5161
  ├─gnome-pty-helpe,4981
  └─{gnome-terminal},4983
[oracle@lampeye ˜]$ 

※じゃ〜、どこの子になっちゃったのか調べてみましょう…

23:41:08 SYS> select s.username,p.username,p.spid from v$process p join v$session s on p.addr = s.paddr where s.username IN ('SYS','SCOTT');

USERNAME                       USERNAME        SPID
------------------------------ --------------- ------------------------
SYS                            oracle          5685
SCOTT                          oracle          5666

経過: 00:00:00.03
23:41:40 SYS> 

お〜、やはり、SQL*Plusの子じゃなくて、INITの養子となってしまったようですw

[oracle@lampeye ˜]$ ps -f -p 5685 5666
UID        PID  PPID  C STIME TTY      STAT   TIME CMD
oracle    5666     1  0 23:39 ?        Ss     0:00 oraclelampeye (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle    5685     1  0 23:40 ?        Ss     0:00 oraclelampeye (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
[oracle@lampeye ˜]$ 

これなら、shutdown immeidateも待たされないでしょうね :)

23:42:52 SYS> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
23:43:07 SYS> 

immeidateしない、ほかの理由に遭遇！　ネタはこれで、ほんとにほんとのおしまい :)

---

・shutdown immeidateしない、ほかの理由に遭遇！
・shutdown immeidateしない、ほかの理由に遭遇！ #2
・shutdown immeidateしない、ほかの理由に遭遇！ #3
・shutdown immeidateしない、ほかの理由に遭遇！ おまけ

shutdown immeidateしない、ほかの理由に遭遇！ おまけ

前回までで状況も把握できたし、そうなった場合の回避策も見えたのですが、子プロセスの生成とかdefunctなゾンピ君の刈り取りってどーなってんだろーと気になり…

子プロセスの生成を状況を以下の順で見てみる…

1. shellに入っただけ
2. SQL*Plus起動
3. SCOTTユーザへ接続
4. host command(!)でshellへ入る

shellに入っただけ

[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ 

[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ ps -e -u oracle | grep gnome-terminal
 3337 ?        00:00:09 gnome-terminal
[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ pstree -p 3337 -u
gnome-terminal(3337,oracle)─┬─bash(3377)
                            ├─bash(3737)───pstree(4063)
                            ├─gnome-pty-helpe(3342)
                            └─{gnome-terminal}(3344)

SQL*Plus起動

[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.7.0 - Production on 木 2月 10 14:54:44 2011

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

14:54:44 > 

[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ pstree -p 3337 -u
gnome-terminal(3337,oracle)─┬─bash(3377)───sqlplus(4064)
                            ├─bash(3737)───pstree(4066)
                            ├─gnome-pty-helpe(3342)
                            └─{gnome-terminal}(3344)

SCOTTユーザへ接続

[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.7.0 - Production on 木 2月 10 14:54:44 2011

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

14:54:44 > conn scott/tiger
接続されました。
14:54:57 SCOTT> 

scottユーザに接続した状態…
このようにSQL*Plusの子プロセスが１つであればshutdown immeidateが待機させられることはないんだけど…ね。

[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ pstree -p 3337 -u
gnome-terminal(3337,oracle)─┬─bash(3377)───sqlplus(4064)───oracle(4067)
                            ├─bash(3737)───pstree(4068)
                            ├─gnome-pty-helpe(3342)
                            └─{gnome-terminal}(3344)

host command(!)でshellに入った

[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.7.0 - Production on 木 2月 10 14:54:44 2011

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

14:54:44 > conn scott/tiger
接続されました。
14:54:57 SCOTT> !
[oracle@pleco ˜]$ 

SQL*Plusからホストコマンド(!)でshellに入った状態…
SQL*Plusの子プロセスが複数でoracle以外のがある状態で、他のSQL*Plusからshutdown immediateを実行されちゃうと、以下にあるpid=4067が<defunct>状態のまま刈り取られない。＝＝＝＞Oracleがshutdown immeidateで停止しない。ってことになるのな。

[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ pstree -p 3337 -u
gnome-terminal(3337,oracle)─┬─bash(3377)───sqlplus(4064)─┬─bash(4069)
                            │                            └─oracle(4067)
                            ├─bash(3737)───pstree(4093)
                            ├─gnome-pty-helpe(3342)
                            └─{gnome-terminal}(3344)
[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ 

じゃ、実験！

以下のようにshutdown immeidateが待機させられている状態を作る。赤字（pid=3627)の子プロセスがdefunctつまりゾンビになるわけね。

shutdown immeidateを実行するSQL*Plusとは別にSQL*Plusを起動し、host command(!)でshellに入っておきます…

16:09:28 > conn scott/tiger
接続されました。
16:12:45 SCOTT> !
[oracle@pleco ˜]$ 

[oracle@pleco ˜]$ pstree -p 3372 -u
gnome-terminal(3372,oracle)─┬─bash(3378)───sqlplus(3493)─┬─bash(3628)
                            │                            └─oracle(3627)
                            ├─bash(3403)───sqlplus(3427)───oracle(3599)
                            ├─bash(3520)───pstree(3672)
                            ├─gnome-pty-helpe(3377)
                            └─{gnome-terminal}(3379)

この状態で、もう一つのSQL*Plusからsysユーザでshutdown immeidateを実行します…shutdown immeidateは待機させられます。
この時、pid=3627の子プロセスはdefunct状態になってますが、刈り取られていません。この影響でshutdown immediateが待機させられています。
SQL*Plusからshellに入っていない場合、つまり、SQL*Plusのプロセス(pid=3493)の子プロセスが１つしかない場合は、shutdown immeidateが待機させられることはない…この辺りに問題がありそうな気がします…

16:12:59 SYS> 
16:12:59 SYS> 
16:13:00 SYS> shutdown immediate

[oracle@pleco ˜]$ pstree -p 3372 -u
gnome-terminal(3372,oracle)─┬─bash(3378)───sqlplus(3493)─┬─bash(3628)
                            │                            └─oracle(3627)
                            ├─bash(3403)───sqlplus(3427)───oracle(3599)
                            ├─bash(3520)───pstree(3672)
                            ├─gnome-pty-helpe(3377)
                            └─{gnome-terminal}(3379)

試しに親プロセスであるSQL*Plus(pid=3493)にSIGCHLDシグナルを送ってみましょう。

[oracle@pleco ˜]$ kill -SIGCHLD 3493
[oracle@pleco ˜]$ kill -SIGCHLD 3493
[oracle@pleco ˜]$ kill -SIGCHLD 3493
[oracle@pleco ˜]$ kill -SIGCHLD 3493
[oracle@pleco ˜]$ kill -SIGCHLD 3493
・・・・以下略w・・・・

ん〜〜〜〜〜。ゾンビを刈り取ってくれません＞＜

試しにshellからexitしてみます…

16:09:28 > conn scott/tiger
接続されました。
16:12:45 SCOTT> !
[oracle@pleco ˜]$ exit
exit

16:18:24 SCOTT> 

[oracle@pleco ˜]$ pstree -p 3372 -u
gnome-terminal(3372,oracle)─┬─bash(3378)───sqlplus(3493)───oracle(3627)
                            ├─bash(3403)───sqlplus(3427)───oracle(3599)
                            ├─bash(3520)───pstree(3673)
                            ├─gnome-pty-helpe(3377)
                            └─{gnome-terminal}(3379)

shellからはexitしました。SQL*Plus(pid=3493)の子プロセスがoracleだけ(pid=3627)のゾンビだけになりました。oracleのゾンビ(pid=3627)が残っているうちはshutdown immeidateは待機させられたままです！　

では、もう一回、親プロセスであるSQL*PlusにSIGCHLDシグナルを送ってみましょう！　今度はうまく行きそうな気がします！

[oracle@pleco ˜]$ kill -SIGCHLD 3493
[oracle@pleco ˜]$ pstree -p 3372 -u
gnome-terminal(3372,oracle)─┬─bash(3378)───sqlplus(3493)
                            ├─bash(3403)───sqlplus(3427)───oracle(3599)
                            ├─bash(3520)───pstree(3675)
                            ├─gnome-pty-helpe(3377)
                            └─{gnome-terminal}(3379)
[oracle@pleco ˜]$ 

やった〜〜〜〜〜〜 :) SQL*Plus(pid=3493)の子プロセス（pid=3627)のゾンビが見事に刈り取られました！

その瞬間……待機させられていたshutdown immeidateは見事終了！！！！

16:12:59 SYS> 
16:12:59 SYS> 
16:13:00 SYS> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
16:18:42 SYS> 

shutdown immeidateしない、ほかの理由に遭遇！ ネタはこれにて :)

---

・shutdown immeidateしない、ほかの理由に遭遇！
・shutdown immeidateしない、ほかの理由に遭遇！ #2
・shutdown immeidateしない、ほかの理由に遭遇！ #3
・shutdown immeidateしない、ほかの理由に遭遇！ おまけ

shutdown immeidateしない、ほかの理由に遭遇！ #3

もう一つ検証し忘れてた!。

この現象に気づいたとき、SQL*Plusから接続していたユーザがsysユーザや、systemユーザだけだったので、それ以外のユーザで接続している場合は大丈夫なんじゃね？都市伝説の検証…

これまでと同様に２つのSQL*Plusを起動しておきます。

１つめのSQL*Plusでは、sysユーザに接続しておきます…

[oracle@leaffish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 水 2月 9 07:26:10 2011

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

07:26:10 > conn / as sysdba
接続されました。

２つめのSQL*Plusでは、scottユーザ（sysユーザ、systemユーザ以外の一般ユーザ）に接続し、host command(!)でshellに入ったままにしておきます…

[oracle@leaffish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 水 2月 9 07:26:23 2011

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

07:26:23 > conn scott/tiger
接続されました。
07:26:29 SCOTT> !
[oracle@leaffish ˜]$ 

では、sysユーザでshutdown immeidateを実行してみます…

07:26:10 > conn / as sysdba
接続されました。
07:26:16 SYS>
07:26:16 SYS> 
07:26:17 SYS> shutdown immediate

お〜〜〜、shutdown immeidateが待機させられています。

「SQL*Plusから接続していたユーザがsysユーザや、systemユーザだけだったので、それ以外のユーザで接続している場合は大丈夫なんじゃね？都市伝説」は都市伝説。
Oracleへ接続するユーザに関係なく、SQL*Plusからhost command(!)でshellに入ったままのセッションがある状態で他のセッションからshutdown immeidateを実行した場合、shutdown immeidateは、shutdown timeoutせずにshutdownを待機し続けるのは事実。

まとめると…

現象：

• shutdown immeidate文を実行したがshutdown timeout（１時間）も発生せずshutdownが待機させれれたままになり停止できない。

発生条件(Updated 16-Feb-2011)：

• Linux/Unix系のOracle11g R2 11.2.0.1.0 （ちなみにそれ以外のリリースでは11.1.0.7.0で同様の現象を確認しています、他のリリースでは未検証。）
• shutdown immeidateを発行するセッション以外に、SQL*Plusからhost command(! はたま host)でshellに入ったままになっているセッションがある場合。かつ、Bequeath ProtocolでOracleへ接続している。

確認ポイント：

• アラートログに　"SHUTDOWN: Active processes prevent shutdown operation"が繰り返される。
• ps -ef | grep ora などでプロセスをみると <defunct>な子プロセスがあり、親プロセスがSQL*Plusである。
• ls -lrt で最後にリストされるトレースファイル（shutdownを実行しているプロセスのトレースファイル）に"ksukia: Attempt <連番?> to re-kill process OS PID=<pid>"のメッセージが繰り返し出力され続ける。

対処(Updated 16-Feb-2011)：

• shutdown aboartするしかない。<defunct>なプロセスの親であるSQL*Plusのプロセスをkill -SIGTERMとか-SIGKILLで終了させる。それでもshutdownが待機しているようなら、最後の手段、shutdown abortということで。
  SQL*Plus起動してる人が連絡取れる場所にいるのならその方にexitしてもらうのもありw
• その他の方法として、sqlnet.oraに、BEQUEATH_DETACH=yes を設定して、サーバープロセスをSQL*Plusの子ではなく、INITの子になってもらう（これがおすすめかも）

現象と回避方法を確認したリリース(Updated 16-Feb-2011)：

• Oracle11g R1 11.1.0.7.0 for Linux (32bit/64bit)
• Oracle11g R1 11.1.0.7.0 for HP-UX(itanium)
• Oracle11g R2 11.2.0.1.0 for Linux (32bit/64bit)
• Oracle11g R2 11.2.0.1.0 for Solaris x86-64

KROWNっぽいまとめ方にしてみました :) (他のUnix系リリースでも作りはおなじでしょうね)

でもさあ、SQL*Plusからホストコマンド、使うんだよね結構。shellに入って、SQL*Plusから入っていたこと忘れて、また、SQL*Plus起動しちゃって…さらにshellに入って…以下繰り返しw。 注意しましょうね。→　自分。

---

・shutdown immeidateしない、ほかの理由に遭遇！
・shutdown immeidateしない、ほかの理由に遭遇！ #2
・shutdown immeidateしない、ほかの理由に遭遇！ #3
・shutdown immeidateしない、ほかの理由に遭遇！ おまけ

shutdown immeidateしない、ほかの理由に遭遇！ #2

さて、昨日のつづきです。

Oracle11g R2 11.2.0.1.0 for Linux x86 をVirtualBox4.0 for MacOS XのCentOS5.5にインストールしてあります。

昨日は、SQL*Plusの!(host command)でshellへ入っている状態で、かつ、別端末のSQL*plusからshutdown immeidate文を発行してしまうとSQL*Plusのプロセスの子プロセスに<defunct>なプロセスが登場して、shutdown immeidateを待機させてしまうところまでを再現してみました。

今日は、shutdown immediate文を発行するsysユーザ以外のsysユーザがSQL*Plusから接続しているだけでもshutdown immediateを待機させるんじゃないか？疑惑の確認と、shutdown immeidateの待機させるだけじゃなく、shutdown timeoutも抑止しちゃってるよね疑惑などを検鏡検証してみようと思います。

短期遠征先から帰宅している予定だったのによそーーーーー外の１日延泊となってしまった次いでに、VirtuslBox4.0のCentOS5.5のOracle11g R2でたっぷり検証してみましょうw

では、最初に、shutdown immeidateを実行するsysユーザ以外のsysユーザがSQL*Plusから接続しているだけでも実行に他の端末のSQL*Plusでsysユーザが接続しているだけでもshutdown immeidateがを待機させるんじゃないか？疑惑するんじゃね？疑惑の検証から。

まず、SQL*Plusでsysユーザに接続している端末を２つ用意して…

一つめのSQL*Plusで〜す。

[oracle@leaffish ˜]$ 
[oracle@leaffish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 水 2月 9 00:09:00 2011

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

00:09:00 > conn / as sysdba
接続されました。
00:09:11 SYS> 
00:09:12 SYS> 
00:09:12 SYS> 

２つめのSQL*Plusで〜す。

[oracle@leaffish ˜]$ 
[oracle@leaffish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 水 2月 9 00:08:39 2011

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

00:08:39 > conn / as sysdba
接続されました。
00:08:44 SYS> 
00:08:45 SYS> 
00:08:45 SYS> 

この状態で１つめのSQL*Plusのsysユーザでshutdown immeidate文を実行します…

00:22:43 SYS> 
00:22:43 SYS> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
00:22:57 SYS> 

待機させられることなく、shutdown immeidate文が実行されました。Oracle11g R2 11.2.0.1.0 for Linuxでは”疑惑”だけだったようですね。一安心w。他のバージョンだとどうなんだろ＝＞TODO.
（昨日の記事では、systemユーザがSQL*Plusで接続している場合、他の端末のSQL*Plusのsysユーザがshutdown immeidateを実行した場合の検証もしていましたよね。これでshutdown immeidate文を実行するセッション以外にsysユーザやsystemユーザのセッションが存在していてもshutdown immeidateが待機させられることは、すくなくともOracle11g R2 11.2.0.1.0 for Linuxでは発生しないことは確かなようです。）

つづいて、SQL*Plusのhost command(!)からshellへ入ったままのセッションが存在している状態でshutdown immeidate文を別セッションから実行してしまうとshutdown immediateを待機させるだけでなく、shutdown timeoutも妨害してしまい１時間を経過してもハングしたままじゃね疑惑を検証してみたいと思います。

同じように２つのSQL*Plusを起動し、ともにsysユーザで接続して、一方のセッションではhost command (!)でshellへ入ったままにしておきます。

１つめのSQL*Plusです…

[oracle@leaffish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 水 2月 9 00:36:01 2011

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

00:36:01 > conn / as sysdba
接続されました。
00:36:04 SYS> 
00:36:04 SYS> 

２つめのSQL*Plusです〜、こちらはhost commandでshellへ入っておきます。

[oracle@leaffish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 水 2月 9 00:35:51 2011

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

00:35:51 > conn / as sysdba
接続されました。
00:35:54 SYS> 
00:35:56 SYS> !
[oracle@leaffish ˜]$ 
[oracle@leaffish ˜]$ 

この状態で１つめのSQL*Plusのセッションからshutdown immeidate文を実行してみます…

00:39:34 SYS> 
00:39:34 SYS> shutdown immediate

見事にshutdown immeidateは待機させられます。すばらし〜。
このまま放置してみます。Oracle10g以降の機能であるshutdown timeoutが働いて１時間程度でshutdownはキャンセルされるはずです。しばしの間、ご歓談くださいませ。:)

・・・・・・・・・中略・・・・・・・・・・・

ながらくお待たせいたしました〜、shutdown immeidateを実行してから２時間以上経過しましたが、shutdown timeoutでshutdownがキャンセルされるどころか、止まる気配すらありません…

以下、アラートログの内容です。

Wed Feb 09 00:39:41 2011
Shutting down instance (immediate)
Stopping background process SMCO
Shutting down instance: further logons disabled
Stopping background process QMNC
Stopping background process MMNL
Stopping background process MMON
License high water mark = 2
All dispatchers and shared servers shutdown
Wed Feb 09 00:44:51 2011
SHUTDOWN: Active processes prevent shutdown operation
Wed Feb 09 00:50:05 2011
SHUTDOWN: Active processes prevent shutdown operation
Wed Feb 09 00:55:20 2011
SHUTDOWN: Active processes prevent shutdown operation
Wed Feb 09 01:00:36 2011
SHUTDOWN: Active processes prevent shutdown operation
Wed Feb 09 01:05:48 2011
SHUTDOWN: Active processes prevent shutdown operation
Wed Feb 09 01:10:57 2011
SHUTDOWN: Active processes prevent shutdown operation
Wed Feb 09 01:16:12 2011
SHUTDOWN: Active processes prevent shutdown operation

・・・中略・・・

Wed Feb 09 02:28:17 2011
SHUTDOWN: Active processes prevent shutdown operation
Wed Feb 09 02:33:21 2011
SHUTDOWN: Active processes prevent shutdown operation
Wed Feb 09 02:38:25 2011
SHUTDOWN: Active processes prevent shutdown operation
Wed Feb 09 02:43:28 2011
SHUTDOWN: Active processes prevent shutdown operation
Wed Feb 09 02:48:32 2011
SHUTDOWN: Active processes prevent shutdown operation
Wed Feb 09 02:53:38 2011
SHUTDOWN: Active processes prevent shutdown operation

ということで、「shutdown immeidateのを待機させるだけじゃなく、shutdown timeoutも抑止しちゃってるよね！疑惑」は、疑惑じゃなくて真実。

次回へつづく。

---

・shutdown immeidateしない、ほかの理由に遭遇！
・shutdown immeidateしない、ほかの理由に遭遇！ #2
・shutdown immeidateしない、ほかの理由に遭遇！ #3
・shutdown immeidateしない、ほかの理由に遭遇！ おまけ

shutdown immeidateしない、ほかの理由に遭遇！

別途検証して別エントリにする予定だけど（遠征先で時間ないので…）、この状態でshutdown immeidateが待機するとshutdown timeoutしないというのも特徴みたい…

Oracleのバージョンは11g R2 11.2.0.1.0 for Linux (32bit)だけどUnix/Linux系なら発生するよ、きっと。

そういえば、以前こんなエントリ書いてましたっけ「shutdown timeout」

では、早速再現テスト。

まず、SQL*Plusを起動、SYSユーザに接続してOracleインスタンスを起動します…

[oracle@leaffish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 火 2月 8 00:46:11 2011

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

00:46:11 > conn / as sysdba
アイドル・インスタンスに接続しました。
00:46:16 SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area  422670336 bytes
Fixed Size                  1336960 bytes
Variable Size             373295488 bytes
Database Buffers           41943040 bytes
Redo Buffers                6094848 bytes
データベースがマウントされました。
データベースがオープンされました。
00:47:17 SYS> 

別端末でSQL*Plusを起動してSYSTEMユーザまたはSYSユーザに接続.
(別途詳しく検証する予定だけど、今のところSYSTEM/SYSユーザ以外では発生してないので）

[oracle@leaffish ˜]$ 
[oracle@leaffish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 火 2月 8 00:50:18 2011

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

00:50:18 > conn system
パスワードを入力してください: 
接続されました。
00:50:23 SYSTEM> 

次にOracleを起動したSQL*PlusのSYSユーザでshutdown immeidateを発行する…

00:51:22 SYS> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
00:51:34 SYS> 

この状態だとOracleインスタンスは正常にshutdown immeidateで停止できる。あたりまえだけど。

では、再現テストですよん。

では次のパターンはどうか？

前述した手順と同じく、SYSで接続してOracleインスタンスを起動する…

[oracle@leaffish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 火 2月 8 00:54:47 2011

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

00:54:47 > conn / as sysdba
アイドル・インスタンスに接続しました。
00:54:52 SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area  422670336 bytes
Fixed Size                  1336960 bytes
Variable Size             373295488 bytes
Database Buffers           41943040 bytes
Redo Buffers                6094848 bytes
データベースがマウントされました。
データベースがオープンされました。
00:55:46 SYS> 

前述した手順と同様に、別端末でSQL*Plusを起動し、SYSTEMユーザ(SYSユーザでもいいよ）へ接続する。
さらに、! (SQL*Plusのhost command）でshellに入っておく…。ここがポイント

[oracle@leaffish ˜]$ 
[oracle@leaffish ˜]$ 
[oracle@leaffish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 火 2月 8 01:01:42 2011

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

01:01:42 > conn system
パスワードを入力してください: 
接続されました。
01:01:47 SYSTEM> !
[oracle@leaffish ˜]$ 

shutdow immeidateの待機を再現させますよー、Oracleインスタンスを起動したSQL*PlusのSYSユーザでshutdown immeidate文を発行する…

01:03:04 SYS> 
01:03:05 SYS> shutdown immediate

いつまでたってもOracleインスタンスは停止しない。この例では載せていないがマニュアルに記載されているshutdown timeoutも１時間たっても２時間たっても発生しないようだ…（別途検証予定）

アラートログを確認してみると…５分毎に、”SHUTDOWN: Active processes prevent shutdown operation”というログを出力し続けてる…

Tue Feb 08 01:03:07 2011
Shutting down instance (immediate)
Shutting down instance: further logons disabled
Stopping background process QMNC
Stopping background process MMNL
Stopping background process MMON
License high water mark = 2
All dispatchers and shared servers shutdown
Tue Feb 08 01:08:17 2011
SHUTDOWN: Active processes prevent shutdown operation
Tue Feb 08 01:13:24 2011
SHUTDOWN: Active processes prevent shutdown operation
Tue Feb 08 01:18:31 2011
SHUTDOWN: Active processes prevent shutdown operation
Tue Feb 08 01:23:37 2011
SHUTDOWN: Active processes prevent shutdown operation
Tue Feb 08 01:28:43 2011
SHUTDOWN: Active processes prevent shutdown operation

プロセスのトレースファイルで最新のものでファイルサイズが増えつつけているものがある…
tailでのぞいてみると…

PID=3542のOSプロセスをkillできずにループしているように見える…

[oracle@leaffish trace]$ ll -lrt

・・・中略・・・

-rw-r----- 1 oracle oinstall      61  2月  8 01:00 discus_mman_3483.trm
-rw-r----- 1 oracle oinstall     863  2月  8 01:00 discus_mman_3483.trc
-rw-r----- 1 oracle oinstall      61  2月  8 01:00 discus_dbrm_3477.trm
-rw-r----- 1 oracle oinstall     904  2月  8 01:00 discus_dbrm_3477.trc
-rw-r----- 1 oracle oinstall      45  2月  8 01:01 discus_ora_3539.trm
-rw-r----- 1 oracle oinstall     669  2月  8 01:01 discus_ora_3539.trc
-rw-r----- 1 oracle oinstall  235323  2月  8 01:08 alert_discus.log
-rw-r----- 1 oracle oinstall    6420  2月  8 01:12 discus_ora_3513.trm
-rw-r----- 1 oracle oinstall   60565  2月  8 01:12 discus_ora_3513.trc
[oracle@leaffish trace]$ 
[oracle@leaffish trace]$ tail -f discus_ora_3513.trc
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:15.641
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:16.663
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:17.678
ksukia: Starting kill, flags = 1
ksukia: Attempt 119 to re-kill process OS PID=3542.
ksukia: killed 1 out of 1 processes.

*** 2011-02-08 01:13:18.699
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:19.709
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:20.735
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:21.750
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:22.756
ksukia: Starting kill, flags = 1
ksukia: Attempt 120 to re-kill process OS PID=3542.
ksukia: killed 1 out of 1 processes.

*** 2011-02-08 01:13:23.779
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:24.790
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

*** 2011-02-08 01:13:25.821
ksukia: Starting kill, flags = 1
ksukia: killed 0 out of 1 processes.

[oracle@leaffish trace]$ 

killできないと繰り返しログに吐かれているプロセス　PID=3542とは何者？…
psとpstreeコマンドでみてみると…

SQL*Plusの!(host command)でshellに入る生成されるプロセスらしい…、このプロセスSYSTEMユーザやSYSユーザ以外接続している場合はなぜか今のところ生成されいないように見える…

この<defunct>なプロセスは何屋さん？　shutdown immediateをimmediateじゃない状態にするのは大量のundoデータだけじゃないのね〜＞＜

それもSQL*Plusの!(host command）は便利なので、私も多用していまして、ついつい、SQL*Plusに接続して、!でshellに入って、SQL*Plusから入ったのを忘れてさらに、SQL*Plus起動して、！でshellに入って…なんてことやってしまうことは多々あります。＞＜

これが原因で、shutdown immeidateが待機させられるなんて〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜＞＜。

[oracle@leaffish ˜]$ ps -ef | grep 3542
oracle    3542  3541  0 01:01 ?        00:00:00 [oracle] <defunct>
oracle    3785  3056  0 01:24 pts/5    00:00:00 grep 3542
[oracle@leaffish ˜]$ 
[oracle@leaffish ˜]$ pstree -up oracle

・・・中略・・・

gnome-terminal(2806)─┬─bash(2812)───sqlplus(3398)───oracle(3513)
                     ├─bash(2909)───tail(3055)
                     ├─bash(2937)
                     ├─bash(3031)───sqlplus(3541)─┬─bash(3543)
                     │                            └─oracle(3542)
                     ├─bash(3056)───pstree(3772)
                     ├─gnome-pty-helpe(2811)
                     └─{gnome-terminal}(2813)

・・・以下略・・・

もう少し検証してみましょう！　

shellからだけexitしてみるも……Oracleはまだ停止しない…

01:01:42 > conn system
パスワードを入力してください: 
接続されました。
01:01:47 SYSTEM> !
[oracle@leaffish ˜]$ exit
exit

01:30:56 SYSTEM> 

じゃ、SQL*Plusからもexitしよう

01:01:42 > conn system
パスワードを入力してください: 
接続されました。
01:01:47 SYSTEM> !
[oracle@leaffish ˜]$ exit
exit

01:30:56 SYSTEM> exit
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing optionsとの接続が切断されました。
[oracle@leaffish ˜]$ 

次の瞬間……

データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
01:32:10 SYS> 

なんだと〜〜〜〜〜〜〜〜。いつからこーなんだー。　怖くてSQL*Plusから!(host command)でshellに入れないじゃないか〜〜〜＞＜

次回へつづく。

---

・shutdown immeidateしない、ほかの理由に遭遇！
・shutdown immeidateしない、ほかの理由に遭遇！ #2
・shutdown immeidateしない、ほかの理由に遭遇！ #3
・shutdown immeidateしない、ほかの理由に遭遇！ おまけ

階層問合せか、再帰問合せか、それが問題だ #3 おまけ

階層問合せと再帰問合せを比較するため条件を合わせるという意味でWITH句を利用したが、階層問合せは、再帰問合せと異なりWITH句は必要ないのも有利ですね。

実行計画こそWITH句を利用した場合と変わりまりませんが、階層問合せではWITH句は必須ではないので、WITH句を利用しない階層問合せとWITH句が必須な再帰問合せでは、今のところ、階層問合せの方がPGAの利用サイズが決定的に少ないものは間違いないですね　:)

WITH句伴わない階層問合せでPGAサイズを見てみると…

SCOTT> r
  1  select
  2  	empno,
  3  	ename,
  4  	job,
  5  	mgr,
  6  	level
  7  from
  8  	emp
  9  start with
 10  	mgr is null
 11  connect by
 12* 	prior empno = mgr

     EMPNO ENAME      JOB	       MGR	LEVEL
---------- ---------- --------- ---------- ----------
      7839 KING       PRESIDENT 		    1
      7566 JONES      MANAGER	      7839	    2
      7788 SCOTT      ANALYST	      7566	    3
      7876 ADAMS      CLERK	      7788	    4
      7902 FORD       ANALYST	      7566	    3
      7369 SMITH      CLERK	      7902	    4
      7698 BLAKE      MANAGER	      7839	    2
      7499 ALLEN      SALESMAN	      7698	    3
      7521 WARD       SALESMAN	      7698	    3
      7654 MARTIN     SALESMAN	      7698	    3
      7844 TURNER     SALESMAN	      7698	    3
      7900 JAMES      CLERK	      7698	    3
      7782 CLARK      MANAGER	      7839	    2
      7934 MILLER     CLERK	      7782	    3

14行が選択されました。

再帰問合せとの差がはっきりでましたね〜 Oracle11g R2では階層問合せでいいかな。再帰問合せはどーゆー場合に有利なんだろ。悩む。

SYS> /

       SID NAME 			       VALUE
---------- ------------------------------ ----------
        66 session pga memory		      672296
        66 session pga memory max	      672296
        66 session uga memory		      246552
        66 session uga memory max	      246552


SYS> /

       SID NAME 			       VALUE
---------- ------------------------------ ----------
        66 session pga memory		      999976
        66 session pga memory max	      999976
        66 session uga memory		      377528
        66 session uga memory max	      377528

SYS> 

---

・階層問合せか、再帰問合せか、それが問題だ
・階層問合せか、再帰問合せか、それが問題だ #2

VirtualBox de Oracle11g R2 RAC #23

VirtualBox de Oracle11g R2 RACのつづき。

さて、いよいよVirtualBox de Oracle11g R2 RACの最終回。簡単なTAFのテスト！

1. ハードウェア構成(VMなのでVMの構成も含めて）、ソフトウェア構成など
2. Linux (CentOS 5.5 x86_64)のインストール
3. Openfiler2.3 x86のインストール
4. Openfiler2.3 x86によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２、その３
6. Oracle所有者、Oracle Grid Infrastructureユーザの作成と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. Oracle RACノード間リモートアクセスの構成とntpの構成
   （sshの構成は念のために行った、多分、実施しなくても大丈夫だと思うけど…ついでなので、ちょいと意地悪な実験をしてみた）
9. ローカルネームサーバの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Automatic Storage Management(ASMLib 2.0.5 x84_64)のインストール及び構成
12. Oracle11g R2 11.2.0.1.0 RACインストール事前作業
13. Oracle11g R2 11.2.0.1.0 Grid Infrastractureのインストール
14. Oracle11g R2 11.2.0.1.0 Database softwareのインストール
15. Oracle11g R2 11.2.0.1.0 examplesのインストール
16. Oracle Cluster databaseの作成
17. Net Serviceの確認
18. Oralce Grid InsfastructureとDatabase構成の確認
19. Clusterの開始と停止の確認
20. 簡単なTransparent Application Failover (TAF)の確認

簡単なTransparent Application Failover (TAF)の確認

MacOS X Snow LeopardにあるOracle Instant Client 10g R2 for MacOS Xのtnsnames.oraを編集し以下の定義を追加しておきました！

ORCLTAF =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = discus-rac64-scan.macdeoracle.jp)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl.macdeoracle.info)
      (FAILOVER_MODE =
        (TYPE = SELECT)
        (METHOD = BASIC)
        (RETRIES = 180)
        (DELAY = 5)
      )
    )
  )

TAF定義の接続識別子で接続します。

discus:˜ oracle$ 
discus:˜ oracle$ sqlplus /nolog

SQL*Plus: Release 10.2.0.4.0 - Production on 木 1月 6 04:47:16 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

> conn scott/tiger@orcltaf
接続されました。
SCOTT> 
SCOTT> 
SCOTT> select count(*) from user_objects;

  COUNT(*)
----------
	 0

orcl1インスタンスで、sysユーザで接続し、セッションの状態を確認してみます。

[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 木 1月 6 04:48:42 2011

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

SYS> 
SYS> 
SYS> conn / as sysdba
接続されました。
SYS> 
SYS> select
  2    instance_name
  3   ,username
  4   ,failover_type
  5   ,failover_method
  6   ,failed_over
  7  from
  8    gv$session sess join gv$instance inst
  9    on sess.inst_id = inst.inst_id
 10  where
 11    sess.username = 'SCOTT'
 12  /

INSTANCE_NAME	 USERNAME			FAILOVER_TYPE FAILOVER_M FAI
---------------- ------------------------------ ------------- ---------- ---
orcl1		 SCOTT				SELECT	      BASIC	 NO

SYS> 

SCOTTはorcl1インスタンスに接続されクエリが実行されたようですね！
failoverさせるため、orcl1インスタンスをabortで強制停止してみます。

SYS> !srvctl status database -d orcl
インスタンスorcl1はノードdiscus164で実行中です。
インスタンスorcl2はノードdiscus264で実行中です。

SYS> !srvctl stop instance -d orcl -i orcl1 -o abort
SYS> 
SYS> !srvctl status database -d orcl
インスタンスorcl1はノードdiscus164で実行されていません。
インスタンスorcl2はノードdiscus264で実行中です。

SYS> 
SYS> l
  1  select
  2    instance_name
  3   ,username
  4   ,failover_type
  5   ,failover_method
  6   ,failed_over
  7  from
  8    gv$session sess join gv$instance inst
  9    on sess.inst_id = inst.inst_id
 10  where
 11*   sess.username = 'SCOTT'
SYS> /
select
*
行1でエラーが発生しました。:
ORA-03135: 接続が失われました
プロセスID: 5563
セッションID: 13、シリアル番号: 25

おっと〜、sysユーザでorcl1インスタンスに接続していたのでした〜。exitしちゃいます。

SCOTTユーザで、failoverさせるためクエリを再実行します。

SCOTT> r
  1* select count(*) from user_objects

  COUNT(*)
----------
	 0

SCOTT> 

インスタンス：orcl2へ接続し直し確認。お〜うまくいけてますね！
orcl1のセッションだったscottユーザのセッションがfailoverしorcl2のセッションになっています。また今回設定したTAFのモードではクエリはエラーにはならず、生存インスタンスへ透過的にfailoverされます。

[oracle@discus264 ˜]$ 
[oracle@discus264 ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 木 1月 6 04:55:48 2011

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

> conn / as sysdba
接続されました。
SYS> select
  2    instance_name
  3   ,username
  4   ,failover_type
  5   ,failover_method
  6   ,failed_over
  7  from
  8   gv$session sess join gv$instance inst
  9   on sess.inst_id = inst.inst_id
 10  where
 11   sess.username = 'SCOTT'
 12  /


INSTANCE_NAME	 USERNAME			FAILOVER_TYPE FAILOVER_M FAI
---------------- ------------------------------ ------------- ---------- ---
orcl2		 SCOTT				SELECT	      BASIC	 YES

SYS> 

ちなみにcrsctl status resource -tで確認すると

・・・中略・・・
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       discus264                                    
ora.LISTENER_SCAN2.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.LISTENER_SCAN3.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.discus164.vip
      1        ONLINE  ONLINE       discus164                                    
ora.discus264.vip
      1        ONLINE  ONLINE       discus264                                    
ora.oc4j
      1        OFFLINE OFFLINE                                                   
ora.orcl.db
      1        OFFLINE OFFLINE                               Instance Shutdown   
      2        ONLINE  ONLINE       discus264                Open                
ora.scan1.vip
      1        ONLINE  ONLINE       discus264                                    
ora.scan2.vip
      1        ONLINE  ONLINE       discus164                                    
ora.scan3.vip
      1        ONLINE  ONLINE       discus164                                    
[grid@discus164 ˜]$ 

となっています。今回のようにデータベースインスタンスだけを停止した場合はこんな状態になるんですね。:)

ついでなので更新トランザクションも試してみましょうかね。
停止したデータベースインスタンスを起動し、scottユーザでupdate文を実行します。

discus:˜ oracle$ 
discus:˜ oracle$ sqlplus scott/tiger@orcltaf

SQL*Plus: Release 10.2.0.4.0 - Production on 木 1月 6 05:20:27 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP
and Data Mining options
に接続されました。
SCOTT> 
SCOTT> 
SCOTT> insert into hoge values('abc');

1行が作成されました。

SCOTT> 

orcl2インスタンスにsysユーザで接続して状態を確認してみます。
scottユーザはorcl1インスタンスに接続してinsert文を実行したようですね。まだ、failoverしていません。

SYS> 
SYS> l
  1  select
  2    instance_name
  3   ,username
  4   ,failover_type
  5   ,failover_method
  6   ,failed_over
  7  from
  8   gv$session sess join gv$instance inst
  9   on sess.inst_id = inst.inst_id
 10  where
 11*  sess.username = 'SCOTT'
SYS> /

INSTANCE_NAME	 USERNAME			FAILOVER_TYPE FAILOVER_M FAI
---------------- ------------------------------ ------------- ---------- ---
orcl1		 SCOTT				SELECT	      BASIC	 NO

では、先ほどと同じようにorcl1インスタンスを強制停止してみます

SYS> !srvctl stop instance -d orcl -i orcl1 -o abort

SYS> 
SYS> !srvctl status database -d orcl
インスタンスorcl1はノードdiscus164で実行されていません。
インスタンスorcl2はノードdiscus264で実行中です。

scottユーザで再度insert文を実行してみました。TAF特有のエラーメッセージが返されましたね。

SCOTT> r
  1* insert into hoge values('abc')
insert into hoge values('abc')
*
行1でエラーが発生しました。:
ORA-25402: トランザクションをロールバックしてください。

セッションの状態を確認してみると…セッションはfailoverしています！

SYS> r
  1  select
  2    instance_name
  3   ,username
  4   ,failover_type
  5   ,failover_method
  6   ,failed_over
  7  from
  8   gv$session sess join gv$instance inst
  9   on sess.inst_id = inst.inst_id
 10  where
 11*  sess.username = 'SCOTT'

INSTANCE_NAME	 USERNAME			FAILOVER_TYPE FAILOVER_M FAI
---------------- ------------------------------ ------------- ---------- ---
orcl2		 SCOTT				SELECT	      BASIC	 YES

scottユーザのトランザクションをロールバック後、リトライしてみると…

SCOTT> 
SCOTT> rollback;

ロールバックが完了しました。

SCOTT> insert into hoge values('abc');

1行が作成されました。

SCOTT> 
SCOTT> 

うまくいきましたね　:)

ということで、VirtualBox de Oracle11g R2 RAC for Linux x86_64環境のできあがり〜。（完）

---

これまでのあらすじ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

・VirtualBox de RAC (Oracle11g R1編） #1
・VirtualBox de RAC (Oracle11g R1編） #2

---

・VirtualBox de Oracle11g R2 RAC #1
・VirtualBox de Oracle11g R2 RAC #2 - 事前調査など…
・VirtualBox de Oracle11g R2 RAC #3
・VirtualBox de Oracle11g R2 RAC #4
・VirtualBox de Oracle11g R2 RAC #5
・VirtualBox de Oracle11g R2 RAC #6
・VirtualBox de Oracle11g R2 RAC #7
・VirtualBox de Oracle11g R2 RAC #8
・VirtualBox de Oracle11g R2 RAC #9
・VirtualBox de Oracle11g R2 RAC #10
・VirtualBox de Oracle11g R2 RAC #11
・VirtualBox de Oracle11g R2 RAC #12
・VirtualBox de Oracle11g R2 RAC #13
・VirtualBox de Oracle11g R2 RAC #14
・VirtualBox de Oracle11g R2 RAC #15
・VirtualBox de Oracle11g R2 RAC #16
・VirtualBox de Oracle11g R2 RAC #17
・VirtualBox de Oracle11g R2 RAC #18
・VirtualBox de Oracle11g R2 RAC #19
・VirtualBox de Oracle11g R2 RAC #20
・VirtualBox de Oracle11g R2 RAC #21
・VirtualBox de Oracle11g R2 RAC #22

---

VirtualBox de Oracle11g R2 RAC #16 - 番外編

VirtualBox de Oracle11g R2 RAC #22

VirtualBox de Oracle11g R2 RACのつづき。

ラス前です :) cluster databaseの起動停止確認。

1. ハードウェア構成(VMなのでVMの構成も含めて）、ソフトウェア構成など
2. Linux (CentOS 5.5 x86_64)のインストール
3. Openfiler2.3 x86のインストール
4. Openfiler2.3 x86によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２、その３
6. Oracle所有者、Oracle Grid Infrastructureユーザの作成と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. Oracle RACノード間リモートアクセスの構成とntpの構成
   （sshの構成は念のために行った、多分、実施しなくても大丈夫だと思うけど…ついでなので、ちょいと意地悪な実験をしてみた）
9. ローカルネームサーバの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Automatic Storage Management(ASMLib 2.0.5 x84_64)のインストール及び構成
12. Oracle11g R2 11.2.0.1.0 RACインストール事前作業
13. Oracle11g R2 11.2.0.1.0 Grid Infrastractureのインストール
14. Oracle11g R2 11.2.0.1.0 Database softwareのインストール
15. Oracle11g R2 11.2.0.1.0 examplesのインストール
16. Oracle Cluster databaseの作成
17. Net Serviceの確認
18. Oralce Grid InsfastructureとDatabase構成の確認
19. Clusterの開始と停止の確認
20. 簡単なTransparent Application Failover (TAF)の確認

Clusterの開始と停止の確認

Grid Infrastructureは自動起動にしてますが、手動起動、停止を確認しておきます。

rootユーザにてcrsctlコマンドでclusterを起動します。データベースインスタンスはOracle所有者でsrvctlコマンドを利用して起動してみます。
(ちなみに、rootユーザには、grid infrastructureのHOMEのbinへパスを通してあります。）

[root@discus164 ˜]# 
[root@discus164 ˜]# crsctl check cluster -all
**************************************************************
discus164:
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4530: Communications failure contacting Cluster Synchronization Services daemon
CRS-4534: Cannot communicate with Event Manager
**************************************************************
discus264:
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4530: Communications failure contacting Cluster Synchronization Services daemon
CRS-4534: Cannot communicate with Event Manager
**************************************************************
[root@discus164 ˜]# 
[root@discus164 ˜]# crsctl start cluster -all
CRS-2672: 'ora.cssdmonitor'('discus164')の起動を試行しています
CRS-2672: 'ora.cssdmonitor'('discus264')の起動を試行しています
CRS-2676: 'ora.cssdmonitor'('discus264')の起動が成功しました
CRS-2676: 'ora.cssdmonitor'('discus164')の起動が成功しました
CRS-2672: 'ora.cssd'('discus164')の起動を試行しています
CRS-2672: 'ora.cssd'('discus264')の起動を試行しています
CRS-2672: 'ora.diskmon'('discus264')の起動を試行しています
CRS-2672: 'ora.diskmon'('discus164')の起動を試行しています
CRS-2676: 'ora.diskmon'('discus264')の起動が成功しました
CRS-2676: 'ora.diskmon'('discus164')の起動が成功しました
CRS-2676: 'ora.cssd'('discus164')の起動が成功しました
CRS-2676: 'ora.cssd'('discus264')の起動が成功しました
CRS-2672: 'ora.ctssd'('discus164')の起動を試行しています
CRS-2672: 'ora.ctssd'('discus264')の起動を試行しています
CRS-2676: 'ora.ctssd'('discus164')の起動が成功しました
CRS-2672: 'ora.evmd'('discus164')の起動を試行しています
CRS-2676: 'ora.ctssd'('discus264')の起動が成功しました
CRS-2672: 'ora.evmd'('discus264')の起動を試行しています
CRS-2672: 'ora.asm'('discus164')の起動を試行しています
CRS-2672: 'ora.asm'('discus264')の起動を試行しています
CRS-2676: 'ora.evmd'('discus264')の起動が成功しました
CRS-2676: 'ora.evmd'('discus164')の起動が成功しました
CRS-2676: 'ora.asm'('discus164')の起動が成功しました
CRS-2672: 'ora.crsd'('discus164')の起動を試行しています
CRS-2676: 'ora.asm'('discus264')の起動が成功しました
CRS-2672: 'ora.crsd'('discus264')の起動を試行しています
CRS-2676: 'ora.crsd'('discus164')の起動が成功しました
CRS-2676: 'ora.crsd'('discus264')の起動が成功しました
[root@discus164 ˜]# 
[root@discus164 ˜]# crsctl check cluster -all
**************************************************************


discus164:
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
**************************************************************
discus264:
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
**************************************************************
[root@discus164 ˜]# 
[root@discus164 ˜]# crsctl status resource -w 'TYPE co ora' -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.CRS.dg
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.DATA.dg
               OFFLINE OFFLINE      discus164                                    
               OFFLINE OFFLINE      discus264                                    
ora.FRA.dg
               OFFLINE OFFLINE      discus164                                    
               OFFLINE OFFLINE      discus264                                    
ora.LISTENER.lsnr
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.asm
               ONLINE  ONLINE       discus164                Started             
               ONLINE  ONLINE       discus264                Started             
ora.eons
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.gsd
               OFFLINE OFFLINE      discus164                                    
               OFFLINE OFFLINE      discus264                                    
ora.net1.network
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.ons
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.registry.acfs
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       discus264                                    
ora.LISTENER_SCAN2.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.LISTENER_SCAN3.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.discus164.vip
      1        ONLINE  ONLINE       discus164                                    
ora.discus264.vip
      1        ONLINE  ONLINE       discus264                                    
ora.oc4j
      1        OFFLINE OFFLINE                                                   
ora.orcl.db
      1        OFFLINE OFFLINE                                                   
      2        OFFLINE OFFLINE                                                   
ora.scan1.vip
      1        ONLINE  ONLINE       discus264                                    
ora.scan2.vip
      1        ONLINE  ONLINE       discus164                                    
ora.scan3.vip
      1        ONLINE  ONLINE       discus164                                    
[root@discus164 ˜]# 

データベースインスタンスを起動します。

[root@discus164 ˜]# su - oracle
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl start database -d orcl
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status database -d orcl
インスタンスorcl1はノードdiscus164で実行中です。
インスタンスorcl2はノードdiscus264で実行中です。
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ exit
logout

[root@discus164 ˜]# 
[root@discus164 ˜]# crsctl status resource ora.orcl.db 
NAME=ora.orcl.db
TYPE=ora.database.type
TARGET=ONLINE             , ONLINE
STATE=ONLINE on discus164, ONLINE on discus264

[root@discus164 ˜]# 

起動しましたね :)

最後に、データベースインスタンスは起動したままの状態で、clusterを停止／起動し、再び、データベースインスタンスが起動した状態になるかを確認しておきます。
Oracle Restartってんでしたっけ？　この機能。

まず、データベースインスタンスは起動したまま、Grid Infrastructureを停止(全ノードを停止）します。

[root@discus164 ˜]# crsctl stop cluster -all
CRS-2673: 'ora.crsd'('discus164')の停止を試行しています
CRS-2673: 'ora.crsd'('discus264')の停止を試行しています
CRS-2790: 'discus264'上にある、Cluster Ready Services管理下のリソースのシャットダウンを開始しています
CRS-2673: 'ora.LISTENER.lsnr'('discus264')の停止を試行しています
CRS-2790: 'discus164'上にある、Cluster Ready Services管理下のリソースのシャットダウンを開始しています
CRS-2673: 'ora.LISTENER.lsnr'('discus164')の停止を試行しています
CRS-2673: 'ora.LISTENER_SCAN2.lsnr'('discus164')の停止を試行しています
CRS-2673: 'ora.LISTENER_SCAN3.lsnr'('discus164')の停止を試行しています
CRS-2673: 'ora.CRS.dg'('discus164')の停止を試行しています
CRS-2673: 'ora.LISTENER_SCAN1.lsnr'('discus264')の停止を試行しています
CRS-2673: 'ora.orcl.db'('discus164')の停止を試行しています
CRS-2673: 'ora.CRS.dg'('discus264')の停止を試行しています
CRS-2673: 'ora.orcl.db'('discus264')の停止を試行しています
CRS-2673: 'ora.registry.acfs'('discus264')の停止を試行しています
CRS-2673: 'ora.registry.acfs'('discus164')の停止を試行しています
CRS-2677: 'ora.LISTENER.lsnr'('discus264')の停止が成功しました
CRS-2673: 'ora.discus264.vip'('discus264')の停止を試行しています
CRS-2677: 'ora.LISTENER_SCAN1.lsnr'('discus264')の停止が成功しました
CRS-2673: 'ora.scan1.vip'('discus264')の停止を試行しています
CRS-2677: 'ora.discus264.vip'('discus264')の停止が成功しました
CRS-2677: 'ora.scan1.vip'('discus264')の停止が成功しました
CRS-2677: 'ora.LISTENER_SCAN3.lsnr'('discus164')の停止が成功しました
CRS-2673: 'ora.scan3.vip'('discus164')の停止を試行しています
CRS-2677: 'ora.LISTENER.lsnr'('discus164')の停止が成功しました
CRS-2673: 'ora.discus164.vip'('discus164')の停止を試行しています
CRS-2677: 'ora.LISTENER_SCAN2.lsnr'('discus164')の停止が成功しました
CRS-2673: 'ora.scan2.vip'('discus164')の停止を試行しています
CRS-2677: 'ora.scan3.vip'('discus164')の停止が成功しました
CRS-2677: 'ora.discus164.vip'('discus164')の停止が成功しました
CRS-2677: 'ora.scan2.vip'('discus164')の停止が成功しました
CRS-2677: 'ora.registry.acfs'('discus264')の停止が成功しました
CRS-2677: 'ora.registry.acfs'('discus164')の停止が成功しました
CRS-2677: 'ora.CRS.dg'('discus264')の停止が成功しました
CRS-2677: 'ora.CRS.dg'('discus164')の停止が成功しました
CRS-2677: 'ora.orcl.db'('discus264')の停止が成功しました
CRS-2673: 'ora.DATA.dg'('discus264')の停止を試行しています
CRS-2673: 'ora.FRA.dg'('discus264')の停止を試行しています
CRS-2677: 'ora.FRA.dg'('discus264')の停止が成功しました
CRS-2677: 'ora.orcl.db'('discus164')の停止が成功しました
CRS-2673: 'ora.DATA.dg'('discus164')の停止を試行しています
CRS-2673: 'ora.FRA.dg'('discus164')の停止を試行しています
CRS-2677: 'ora.DATA.dg'('discus264')の停止が成功しました
CRS-2673: 'ora.asm'('discus264')の停止を試行しています
CRS-2677: 'ora.asm'('discus264')の停止が成功しました
CRS-2673: 'ora.eons'('discus264')の停止を試行しています
CRS-2673: 'ora.ons'('discus264')の停止を試行しています
CRS-2677: 'ora.DATA.dg'('discus164')の停止が成功しました
CRS-2677: 'ora.ons'('discus264')の停止が成功しました
CRS-2673: 'ora.net1.network'('discus264')の停止を試行しています
CRS-2677: 'ora.net1.network'('discus264')の停止が成功しました
CRS-2677: 'ora.FRA.dg'('discus164')の停止が成功しました
CRS-2673: 'ora.asm'('discus164')の停止を試行しています
CRS-2677: 'ora.asm'('discus164')の停止が成功しました
CRS-2677: 'ora.eons'('discus264')の停止が成功しました
CRS-2792: 'discus264'上にある、Cluster Ready Services管理下のリソースのシャットダウンが完了しました
CRS-2673: 'ora.eons'('discus164')の停止を試行しています
CRS-2673: 'ora.ons'('discus164')の停止を試行しています
CRS-2677: 'ora.crsd'('discus264')の停止が成功しました
CRS-2673: 'ora.cssdmonitor'('discus264')の停止を試行しています
CRS-2673: 'ora.ctssd'('discus264')の停止を試行しています
CRS-2673: 'ora.evmd'('discus264')の停止を試行しています
CRS-2673: 'ora.asm'('discus264')の停止を試行しています
CRS-2677: 'ora.cssdmonitor'('discus264')の停止が成功しました
CRS-2677: 'ora.evmd'('discus264')の停止が成功しました
CRS-2677: 'ora.ctssd'('discus264')の停止が成功しました
CRS-2677: 'ora.asm'('discus264')の停止が成功しました
CRS-2673: 'ora.cssd'('discus264')の停止を試行しています
CRS-2677: 'ora.cssd'('discus264')の停止が成功しました
CRS-2673: 'ora.diskmon'('discus264')の停止を試行しています
CRS-2677: 'ora.diskmon'('discus264')の停止が成功しました
CRS-2675: 'ora.ons'('discus164')の停止に失敗しました
CRS-2679: 'ora.ons'('discus164')のクリーニングを試行しています
CRS-2681: 'ora.ons'('discus164')のクリーニングが成功しました
CRS-2673: 'ora.net1.network'('discus164')の停止を試行しています
CRS-2677: 'ora.net1.network'('discus164')の停止が成功しました
CRS-2677: 'ora.eons'('discus164')の停止が成功しました
CRS-2792: 'discus164'上にある、Cluster Ready Services管理下のリソースのシャットダウンが完了しました
CRS-2677: 'ora.crsd'('discus164')の停止が成功しました
CRS-2673: 'ora.cssdmonitor'('discus164')の停止を試行しています
CRS-2673: 'ora.ctssd'('discus164')の停止を試行しています
CRS-2673: 'ora.evmd'('discus164')の停止を試行しています
CRS-2673: 'ora.asm'('discus164')の停止を試行しています
CRS-2677: 'ora.cssdmonitor'('discus164')の停止が成功しました
CRS-2677: 'ora.evmd'('discus164')の停止が成功しました
CRS-2677: 'ora.asm'('discus164')の停止が成功しました
CRS-2677: 'ora.ctssd'('discus164')の停止が成功しました
CRS-2673: 'ora.cssd'('discus164')の停止を試行しています
CRS-2677: 'ora.cssd'('discus164')の停止が成功しました
CRS-2673: 'ora.diskmon'('discus164')の停止を試行しています
CRS-2677: 'ora.diskmon'('discus164')の停止が成功しました
[root@discus164 ˜]# 
[root@discus164 ˜]# crsctl check cluster -all
**************************************************************
discus164:
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4530: Communications failure contacting Cluster Synchronization Services daemon
CRS-4534: Cannot communicate with Event Manager
**************************************************************
discus264:
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4530: Communications failure contacting Cluster Synchronization Services daemon
CRS-4534: Cannot communicate with Event Manager
**************************************************************
[root@discus164 ˜]# 
[root@discus164 ˜]# su - oracle
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status database -d orcl
PRCD-1027 : データベースorclの取得に失敗しました
PRCR-1070 : リソース ora.orcl.dbが登録されているかどうかの確認に失敗しました
Cannot communicate with crsd
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ exit
logout

では、起動しま〜す。

[oracle@discus164 ˜]$ 
[root@discus164 ˜]# crsctl start cluster -all
CRS-2672: 'ora.cssdmonitor'('discus164')の起動を試行しています
CRS-2672: 'ora.cssdmonitor'('discus264')の起動を試行しています
CRS-2676: 'ora.cssdmonitor'('discus164')の起動が成功しました
CRS-2672: 'ora.cssd'('discus164')の起動を試行しています
CRS-2676: 'ora.cssdmonitor'('discus264')の起動が成功しました
CRS-2672: 'ora.cssd'('discus264')の起動を試行しています
CRS-2672: 'ora.diskmon'('discus264')の起動を試行しています
CRS-2672: 'ora.diskmon'('discus164')の起動を試行しています
CRS-2676: 'ora.diskmon'('discus264')の起動が成功しました
CRS-2676: 'ora.diskmon'('discus164')の起動が成功しました
CRS-2676: 'ora.cssd'('discus264')の起動が成功しました
CRS-2672: 'ora.ctssd'('discus264')の起動を試行しています
CRS-2676: 'ora.cssd'('discus164')の起動が成功しました
CRS-2672: 'ora.ctssd'('discus164')の起動を試行しています
CRS-2676: 'ora.ctssd'('discus264')の起動が成功しました
CRS-2676: 'ora.ctssd'('discus164')の起動が成功しました
CRS-2672: 'ora.evmd'('discus264')の起動を試行しています
CRS-2672: 'ora.evmd'('discus164')の起動を試行しています
CRS-2672: 'ora.asm'('discus264')の起動を試行しています
CRS-2672: 'ora.asm'('discus164')の起動を試行しています
CRS-2676: 'ora.evmd'('discus264')の起動が成功しました
CRS-2676: 'ora.evmd'('discus164')の起動が成功しました
CRS-2676: 'ora.asm'('discus164')の起動が成功しました
CRS-2672: 'ora.crsd'('discus164')の起動を試行しています
CRS-2676: 'ora.asm'('discus264')の起動が成功しました
CRS-2672: 'ora.crsd'('discus264')の起動を試行しています
CRS-2676: 'ora.crsd'('discus164')の起動が成功しました
CRS-2676: 'ora.crsd'('discus264')の起動が成功しました
[root@discus164 ˜]# 
[root@discus164 ˜]# crsctl status resource -w 'TYPE co ora' -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.CRS.dg
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.DATA.dg
               ONLINE  ONLINE       discus164                                    
               OFFLINE OFFLINE      discus264                                    
ora.FRA.dg
               ONLINE  ONLINE       discus164                                    
               OFFLINE OFFLINE      discus264                                    
ora.LISTENER.lsnr
               ONLINE  ONLINE       discus164                                    
               ONLINE  OFFLINE      discus264                                    
ora.asm
               ONLINE  ONLINE       discus164                Started             
               ONLINE  ONLINE       discus264                Started             
ora.eons
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.gsd
               OFFLINE OFFLINE      discus164                                    
               OFFLINE OFFLINE      discus264                                    
ora.net1.network
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.ons
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.registry.acfs
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.LISTENER_SCAN2.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.LISTENER_SCAN3.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.discus164.vip
      1        ONLINE  ONLINE       discus164                                    
ora.discus264.vip
      1        ONLINE  INTERMEDIATE discus164                FAILED OVER         
ora.oc4j
      1        OFFLINE OFFLINE                                                   
ora.orcl.db
      1        ONLINE  OFFLINE                                                   
      2        ONLINE  OFFLINE                                                   
ora.scan1.vip
      1        ONLINE  ONLINE       discus164                                    
ora.scan2.vip
      1        ONLINE  ONLINE       discus164                                    
ora.scan3.vip
      1        ONLINE  ONLINE       discus164 

ora.LISTENER_SCAN1.lsnr/ora.discus264.vipの両リソースがノードdiscus164からノードdiscus264へ移動し、ノードdiscus164でデータベースインスタンスが起動しました…

・・・中着・・・
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       discus264                                    
ora.LISTENER_SCAN2.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.LISTENER_SCAN3.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.discus164.vip
      1        ONLINE  ONLINE       discus164                                    
ora.discus264.vip
      1        ONLINE  ONLINE       discus264                                    
ora.oc4j
      1        OFFLINE OFFLINE                                                   
ora.orcl.db
      1        ONLINE  ONLINE       discus164                Open                
      2        ONLINE  OFFLINE                                                   
ora.scan1.vip
      1        ONLINE  ONLINE       discus264                                    
ora.scan2.vip
      1        ONLINE  ONLINE       discus164                                    
ora.scan3.vip
      1        ONLINE  ONLINE       discus164                                    

最後にノードdiscus264でもデータベースインスタンスが起動し、crsctl stop cluster -allで停止する以前の状況になっています。 :)

・・・中略・・・
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       discus264                                    
ora.LISTENER_SCAN2.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.LISTENER_SCAN3.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.discus164.vip
      1        ONLINE  ONLINE       discus164                                    
ora.discus264.vip
      1        ONLINE  ONLINE       discus264                                    
ora.oc4j
      1        OFFLINE OFFLINE                                                   
ora.orcl.db
      1        ONLINE  ONLINE       discus164                Open                
      2        ONLINE  ONLINE       discus264                Open                
ora.scan1.vip
      1        ONLINE  ONLINE       discus264                                    
ora.scan2.vip
      1        ONLINE  ONLINE       discus164                                    
ora.scan3.vip
      1        ONLINE  ONLINE       discus164  

ということで起動／停止の確認終了！

次回へつづく。

---

これまでのあらすじ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

・VirtualBox de RAC (Oracle11g R1編） #1
・VirtualBox de RAC (Oracle11g R1編） #2

---

・VirtualBox de Oracle11g R2 RAC #1
・VirtualBox de Oracle11g R2 RAC #2 - 事前調査など…
・VirtualBox de Oracle11g R2 RAC #3
・VirtualBox de Oracle11g R2 RAC #4
・VirtualBox de Oracle11g R2 RAC #5
・VirtualBox de Oracle11g R2 RAC #6
・VirtualBox de Oracle11g R2 RAC #7
・VirtualBox de Oracle11g R2 RAC #8
・VirtualBox de Oracle11g R2 RAC #9
・VirtualBox de Oracle11g R2 RAC #10
・VirtualBox de Oracle11g R2 RAC #11
・VirtualBox de Oracle11g R2 RAC #12
・VirtualBox de Oracle11g R2 RAC #13
・VirtualBox de Oracle11g R2 RAC #14
・VirtualBox de Oracle11g R2 RAC #15
・VirtualBox de Oracle11g R2 RAC #16
・VirtualBox de Oracle11g R2 RAC #17
・VirtualBox de Oracle11g R2 RAC #18
・VirtualBox de Oracle11g R2 RAC #19
・VirtualBox de Oracle11g R2 RAC #20
・VirtualBox de Oracle11g R2 RAC #21

---

VirtualBox de Oracle11g R2 RAC #16 - 番外編

VirtualBox de Oracle11g R2 RAC #21

VirtualBox de Oracle11g R2 RACのつづき。

1. ハードウェア構成(VMなのでVMの構成も含めて）、ソフトウェア構成など
2. Linux (CentOS 5.5 x86_64)のインストール
3. Openfiler2.3 x86のインストール
4. Openfiler2.3 x86によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２、その３
6. Oracle所有者、Oracle Grid Infrastructureユーザの作成と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. Oracle RACノード間リモートアクセスの構成とntpの構成
   （sshの構成は念のために行った、多分、実施しなくても大丈夫だと思うけど…ついでなので、ちょいと意地悪な実験をしてみた）
9. ローカルネームサーバの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Automatic Storage Management(ASMLib 2.0.5 x84_64)のインストール及び構成
12. Oracle11g R2 11.2.0.1.0 RACインストール事前作業
13. Oracle11g R2 11.2.0.1.0 Grid Infrastractureのインストール
14. Oracle11g R2 11.2.0.1.0 Database softwareのインストール
15. Oracle11g R2 11.2.0.1.0 examplesのインストール
16. Oracle Cluster databaseの作成
17. Net Serviceの確認
18. Oralce Grid InsfastructureとDatabase構成の確認
19. Clusterの開始と停止の確認
20. 簡単なTransparent Application Failover (TAF)の確認

Oralce Grid InsfastructureとDatabase構成の確認

OUIやらなんやらがいろいろと構成してくれたりしてくれてるので確認方法の確認って感じですが…

Oracle所有者にて実行…

[oracle@discus164 ˜]$
[oracle@discus164 ˜]$ srvctl status database -d orcl
インスタンスorcl1はノードdiscus164で実行中です。
インスタンスorcl2はノードdiscus264で実行中です。
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status instance -d orcl -n discus164
インスタンスorcl1はノードdiscus164で実行中です。
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status instance -d orcl -n discus264
インスタンスorcl2はノードdiscus264で実行中です。
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status nodeapps
VIP discus164-vipは有効です
VIP discus164-vipはノードで実行中です: discus164
VIP discus264-vipは有効です
VIP discus264-vipはノードで実行中です: discus264
ネットワークは有効です
ネットワークはノードで実行中です: discus164
ネットワークはノードで実行中です: discus264
GSDは無効です
GSDはノードで実行されていません: discus164
GSDはノードで実行されていません: discus264
ONSは有効です
ONSデーモンはノードで実行中です: discus164
ONSデーモンはノードで実行中です: discus264
eONSは有効です
eONSデーモンはノードで実行中です:discus164
eONSデーモンはノードで実行中です:discus264
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status vip -n discus164
VIP discus164-vipは有効です
VIP discus164-vipはノードで実行中です: discus164
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status vip -n discus264
VIP discus264-vipは有効です
VIP discus264-vipはノードで実行中です: discus264
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status asm -a
ASMはdiscus164,discus264で実行中です
ASMは有効です。
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status listener -n discus164
リスナーLISTENERはノードで有効です: discus164
リスナーLISTENERはノードで実行中です: discus164
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status listener -n discus264
リスナーLISTENERはノードで有効です: discus264
リスナーLISTENERはノードで実行中です: discus264
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status scan
SCAN VIP scan1は有効です
SCAN VIP scan1はノードdiscus264で実行されています
SCAN VIP scan2は有効です
SCAN VIP scan2はノードdiscus164で実行されています
SCAN VIP scan3は有効です
SCAN VIP scan3はノードdiscus164で実行されています
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status scan_listener
SCANリスナーLISTENER_SCAN1は有効です
SCANリスナーLISTENER_SCAN1はノードdiscus264で実行されています
SCANリスナーLISTENER_SCAN2は有効です
SCANリスナーLISTENER_SCAN2はノードdiscus164で実行されています
SCANリスナーLISTENER_SCAN3は有効です
SCANリスナーLISTENER_SCAN3はノードdiscus164で実行されています
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status srvpool -a
サーバー・プール名: Free
アクティブ・サーバー数: 0
アクティブ・サーバー名: 
サーバー・プール名: Generic
アクティブ・サーバー数: 2
アクティブ・サーバー名: discus164,discus264
NAME=discus164 STATE=ONLINE
NAME=discus264 STATE=ONLINE
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status server -n discus164,discus264 -a
サーバー名: discus164
サーバーの状態: ONLINE
アクティブなサーバー・プール: Generic ora.orcl
サーバーの状態の詳細: 
サーバー名: discus264
サーバーの状態: ONLINE
アクティブなサーバー・プール: Generic ora.orcl
サーバーの状態の詳細: 
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status oc4j
OC4Jは無効です
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status diskgroup -g DATA -a
ディスク・グループDATAはdiscus164,discus264で実行中です
ディスク・グループDATAは有効です
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status diskgroup -g CRS -a
ディスク・グループCRSはdiscus164,discus264で実行中です
ディスク・グループCRSは有効です
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl status diskgroup -g FRA -a
ディスク・グループFRAはdiscus164,discus264で実行中です
ディスク・グループFRAは有効です
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ 

構成の確認…

[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl config database -d orcl -a
一意のデータベース名: orcl
データベース名: orcl
Oracleホーム: /u01/app/oracle/product/11.2.0/dbhome_1
Oracleユーザー: oracle
spfile: +DATA/orcl/spfileorcl.ora
ドメイン: macdeoracle.info
開始オプション: open
停止オプション: immediate
データベース・ロール: PRIMARY
管理ポリシー: AUTOMATIC
サーバー・プール: orcl
データベース・インスタンス: orcl1,orcl2
ディスク・グループ: DATA,FRA
サービス: 
データベースは有効です
データベースは管理者によって管理されています
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl config nodeapps -a -g -s
VIPが存在します。:discus164
VIPが存在します。: /discus164-vip/192.168.1.190/255.255.255.0/eth0
VIPが存在します。:discus264
VIPが存在します。: /discus264-vip/192.168.1.191/255.255.255.0/eth0
GSDが存在します。
ONSデーモンは存在します。ローカル・ポート6100、リモート・ポート6200
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl config asm -a
ASMホーム: /u01/app/11.2.0/grid
ASMリスナー: LISTENER
ASMは有効です。
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl config listener -a
名前: LISTENER
ネットワーク: 1、所有者: grid
ホーム: <CRS home>
  ノードdiscus264,discus164の/u01/app/11.2.0/grid
エンド・ポイント: TCP:1521
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl config scan
SCAN名: discus-rac64-scan.macdeoracle.jp、ネットワーク: 1/192.168.1.0/255.255.255.0/eth0
SCAN VIP名: scan1、IP: /discus-rac64-scan.macdeoracle.jp/192.168.1.200
SCAN VIP名: scan2、IP: /discus-rac64-scan.macdeoracle.jp/192.168.1.201
SCAN VIP名: scan3、IP: /discus-rac64-scan.macdeoracle.jp/192.168.1.202
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl config scan_listener
SCANリスナーLISTENER_SCAN1は存在します。ポート: TCP:1521
SCANリスナーLISTENER_SCAN2は存在します。ポート: TCP:1521
SCANリスナーLISTENER_SCAN3は存在します。ポート: TCP:1521
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ srvctl config srvpool
サーバー・プール名: Free
重要度: 0、最小: 0、最大: -1
候補サーバー名: 
サーバー・プール名: Generic
重要度: 0、最小: 0、最大: -1
候補サーバー名: discus164,discus264
[oracle@discus164 ˜]$ 

Grid Infrastructureユーザにて実行…

[grid@discus164 ˜]$ crsctl check cluster -all
**************************************************************
discus164:
CRS-4537: Cluster Ready Servicesがオンラインです
CRS-4529: Cluster Synchronization Servicesがオンラインです
CRS-4533: イベント・マネージャがオンラインです
**************************************************************
discus264:
CRS-4537: Cluster Ready Servicesがオンラインです
CRS-4529: Cluster Synchronization Servicesがオンラインです
CRS-4533: イベント・マネージャがオンラインです
**************************************************************
[grid@discus164 ˜]$ 
[grid@discus164 ˜]$ crsctl check crs
CRS-4638: Oracle高可用性サービスがオンラインです
CRS-4537: Cluster Ready Servicesがオンラインです
CRS-4529: Cluster Synchronization Servicesがオンラインです
CRS-4533: イベント・マネージャがオンラインです
[grid@discus164 ˜]$ 
[grid@discus164 ˜]$ crsctl check ctss
CRS-4700: クラスタ時刻同期化サービスはオブザーバ・モードになっています。
[grid@discus164 ˜]$ 
[grid@discus164 ˜]$ crsctl check css
CRS-4529: Cluster Synchronization Servicesがオンラインです
[grid@discus164 ˜]$ 
[grid@discus164 ˜]$ 
[grid@discus164 ˜]$ crsctl status serverpool
NAME=Free
ACTIVE_SERVERS=

NAME=Generic
ACTIVE_SERVERS=discus164 discus264

NAME=ora.orcl
ACTIVE_SERVERS=discus164 discus264

[grid@discus164 ˜]$ 
[grid@discus164 ˜]$ 
[grid@discus164 ˜]$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   8f431fe5d1304fd9bf6ad331d3aef536 (ORCL:CRSVOL1) [CRS]
1の投票ディスクを検出しました。
[grid@discus164 ˜]$ 
[grid@discus164 ˜]$ crsctl status resource -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.CRS.dg
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.DATA.dg
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.FRA.dg
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.LISTENER.lsnr
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.asm
               ONLINE  ONLINE       discus164                Started             
               ONLINE  ONLINE       discus264                Started             
ora.eons
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.gsd
               OFFLINE OFFLINE      discus164                                    
               OFFLINE OFFLINE      discus264                                    
ora.net1.network
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.ons
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.registry.acfs
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       discus264                                    
ora.LISTENER_SCAN2.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.LISTENER_SCAN3.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.discus164.vip
      1        ONLINE  ONLINE       discus164                                    
ora.discus264.vip
      1        ONLINE  ONLINE       discus264                                    
ora.oc4j
      1        OFFLINE OFFLINE                                                   
ora.orcl.db
      1        ONLINE  ONLINE       discus164                Open                
      2        ONLINE  ONLINE       discus264                Open                
ora.scan1.vip
      1        ONLINE  ONLINE       discus264                                    
ora.scan2.vip
      1        ONLINE  ONLINE       discus164                                    
ora.scan3.vip
      1        ONLINE  ONLINE       discus164                                    

[grid@discus164 ˜]$ 

あれ、perlでエラーメッセージでてるけどご愛嬌 :)

[grid@discus164 ˜]$ asmcmd
ASMCMD> 
ASMCMD> 
ASMCMD> lsdg -g
Use of uninitialized value in string comparison (cmp) at /u01/app/11.2.0/grid/lib/asmcmdbase.pm line 3420, <STDIN> line 42.
Use of uninitialized value in string comparison (cmp) at /u01/app/11.2.0/grid/lib/asmcmdbase.pm line 3420, <STDIN> line 42.
Use of uninitialized value in string comparison (cmp) at /u01/app/11.2.0/grid/lib/asmcmdbase.pm line 3420, <STDIN> line 42.
Use of uninitialized value in string comparison (cmp) at /u01/app/11.2.0/grid/lib/asmcmdbase.pm line 3420, <STDIN> line 42.
Use of uninitialized value in string comparison (cmp) at /u01/app/11.2.0/grid/lib/asmcmdbase.pm line 3420, <STDIN> line 42.
Use of uninitialized value in string comparison (cmp) at /u01/app/11.2.0/grid/lib/asmcmdbase.pm line 3420, <STDIN> line 42.
Inst_ID  State    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name
      1  MOUNTED  EXTERN  N         512   4096  1048576      4092     3694                0            3694              0             N  CRS/
      2  MOUNTED  EXTERN  N         512   4096  1048576      4092     3694                0            3694              0             N  CRS/
      1  MOUNTED  NORMAL  N         512   4096  1048576     43006    37436                0           18718              0             N  DATA/
      2  MOUNTED  NORMAL  N         512   4096  1048576     43006    37436                0           18718              0             N  DATA/
      1  MOUNTED  NORMAL  N         512   4096  1048576     43006    42336                0           21168              0             N  FRA/
      2  MOUNTED  NORMAL  N         512   4096  1048576     43006    42336                0           21168              0             N  FRA/
ASMCMD> 
ASMCMD> lsct -g
Instance_ID  DB_Name  Status     Software_Version  Compatible_version  Instance_Name  Disk_Group
          1  +ASM     CONNECTED        11.2.0.1.0          11.2.0.1.0  +ASM1          CRS       
          1  +ASM     CONNECTED        11.2.0.1.0          11.2.0.1.0  +ASM1          DATA      
          2  +ASM     CONNECTED        11.2.0.1.0          11.2.0.1.0  +ASM2          CRS       
          2  +ASM     CONNECTED        11.2.0.1.0          11.2.0.1.0  +ASM2          DATA      
          1  orcl     CONNECTED        11.2.0.1.0          11.2.0.0.0  orcl1          DATA      
          1  orcl     CONNECTED        11.2.0.1.0          11.2.0.0.0  orcl1          FRA       
          2  orcl     CONNECTED        11.2.0.1.0          11.2.0.0.0  orcl2          DATA      
          2  orcl     CONNECTED        11.2.0.1.0          11.2.0.0.0  orcl2          FRA       
ASMCMD> 
ASMCMD> ls -g
Use of uninitialized value in string comparison (cmp) at /u01/app/11.2.0/grid/lib/asmcmdbase.pm line 3420, <STDIN> line 46.
Use of uninitialized value in string comparison (cmp) at /u01/app/11.2.0/grid/lib/asmcmdbase.pm line 3420, <STDIN> line 46.
Use of uninitialized value in string comparison (cmp) at /u01/app/11.2.0/grid/lib/asmcmdbase.pm line 3420, <STDIN> line 46.
Use of uninitialized value in string comparison (cmp) at /u01/app/11.2.0/grid/lib/asmcmdbase.pm line 3420, <STDIN> line 46.
Use of uninitialized value in string comparison (cmp) at /u01/app/11.2.0/grid/lib/asmcmdbase.pm line 3420, <STDIN> line 46.
Use of uninitialized value in string comparison (cmp) at /u01/app/11.2.0/grid/lib/asmcmdbase.pm line 3420, <STDIN> line 46.
Inst_ID  Name
      1  CRS/
      2  CRS/
      1  DATA/
      2  DATA/
      1  FRA/
      2  FRA/
ASMCMD> 
ASMCMD> lsof 
DB_Name  Instance_Name  Path                                    
+ASM     +ASM1          +crs.255.4294967295                          
orcl     orcl1          +data/orcl/controlfile/current.256.739409625 
orcl     orcl1          +data/orcl/datafile/sysaux.260.739409693     
orcl     orcl1          +data/orcl/datafile/system.259.739409647     
orcl     orcl1          +data/orcl/datafile/undotbs1.261.739409729   
orcl     orcl1          +data/orcl/datafile/undotbs2.263.739409753   
orcl     orcl1          +data/orcl/datafile/users.264.739409767      
orcl     orcl1          +data/orcl/onlinelog/group_1.257.739409631   
orcl     orcl1          +data/orcl/onlinelog/group_2.258.739409637   
orcl     orcl1          +data/orcl/onlinelog/group_3.265.739412213   
orcl     orcl1          +data/orcl/onlinelog/group_4.266.739412217   
orcl     orcl1          +data/orcl/tempfile/temp.262.739409741       
orcl     orcl1          +fra/orcl/controlfile/current.256.739409629  
orcl     orcl1          +fra/orcl/onlinelog/group_1.257.739409635     
orcl     orcl1          +fra/orcl/onlinelog/group_2.258.739409643     
orcl     orcl1          +fra/orcl/onlinelog/group_3.259.739412215     
orcl     orcl1          +fra/orcl/onlinelog/group_4.260.739412225     
ASMCMD>     

最後にSQL*Plusから

SYS> l
  1  select
  2    inst_id
  3   ,instance_name
  4   ,parallel
  5   ,status
  6   ,database_status
  7   ,active_state
  8   ,host_name
  9  from
 10*   gv$instance
SYS> 
SYS> /

   INST_ID INSTANCE_NAME    PAR STATUS	     DATABASE_STATUS   ACTIVE_ST HOST_NAME
---------- ---------------- --- ------------ ----------------- --------- ------------------------------
	 1 orcl1	    YES OPEN	     ACTIVE	       NORMAL	 discus164.macdeoracle.jp
	 2 orcl2	    YES OPEN	     ACTIVE	       NORMAL	 discus264.macdeoracle.jp

SYS> 

次回へつづく。

---

これまでのあらすじ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

・VirtualBox de RAC (Oracle11g R1編） #1
・VirtualBox de RAC (Oracle11g R1編） #2

---

・VirtualBox de Oracle11g R2 RAC #1
・VirtualBox de Oracle11g R2 RAC #2 - 事前調査など…
・VirtualBox de Oracle11g R2 RAC #3
・VirtualBox de Oracle11g R2 RAC #4
・VirtualBox de Oracle11g R2 RAC #5
・VirtualBox de Oracle11g R2 RAC #6
・VirtualBox de Oracle11g R2 RAC #7
・VirtualBox de Oracle11g R2 RAC #8
・VirtualBox de Oracle11g R2 RAC #9
・VirtualBox de Oracle11g R2 RAC #10
・VirtualBox de Oracle11g R2 RAC #11
・VirtualBox de Oracle11g R2 RAC #12
・VirtualBox de Oracle11g R2 RAC #13
・VirtualBox de Oracle11g R2 RAC #14
・VirtualBox de Oracle11g R2 RAC #15
・VirtualBox de Oracle11g R2 RAC #16
・VirtualBox de Oracle11g R2 RAC #17
・VirtualBox de Oracle11g R2 RAC #18
・VirtualBox de Oracle11g R2 RAC #19
・VirtualBox de Oracle11g R2 RAC #20

---

VirtualBox de Oracle11g R2 RAC #16 - 番外編

VirtualBox de Oracle11g R2 RAC #20

VirtualBox de Oracle11g R2 RACのつづき。

データベースも無事？作成できたので、今回はNet Serviceの確認を。

1. ハードウェア構成(VMなのでVMの構成も含めて）、ソフトウェア構成など
2. Linux (CentOS 5.5 x86_64)のインストール
3. Openfiler2.3 x86のインストール
4. Openfiler2.3 x86によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２、その３
6. Oracle所有者、Oracle Grid Infrastructureユーザの作成と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. Oracle RACノード間リモートアクセスの構成とntpの構成
   （sshの構成は念のために行った、多分、実施しなくても大丈夫だと思うけど…ついでなので、ちょいと意地悪な実験をしてみた）
9. ローカルネームサーバの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Automatic Storage Management(ASMLib 2.0.5 x84_64)のインストール及び構成
12. Oracle11g R2 11.2.0.1.0 RACインストール事前作業
13. Oracle11g R2 11.2.0.1.0 Grid Infrastractureのインストール
14. Oracle11g R2 11.2.0.1.0 Database softwareのインストール
15. Oracle11g R2 11.2.0.1.0 examplesのインストール
16. Oracle Cluster databaseの作成
17. Net Serviceの確認
18. Oralce Grid InsfastructureとDatabase構成の確認
19. Clusterの開始と停止の確認
20. 簡単なTransparent Application Failover (TAF)の確認

Net Serviceの確認

まず、クライアントになるMacOS X Snow LeopardのOracle10g R2 Instant Client側の設定(tnsnames.ora)から。

tnsnames.oraにVirtualBox上に構築したRACに接続するため以下ように定義した。
接続識別子ORCLはVirtualBox上に構築した際、自動生成された部分を複製し、残り２つの定義はRACの各ノードを個別に狙って接続するため接続識別子ORCL1/ORCL2を定義した。

discus:˜ oracle$ diff -u $TNS_ADMIN/tnsnames.ora.org $TNS_ADMIN/tnsnames.ora
--- /Users/Shared/instantclient_10_2/tnsnames.ora.org	2011-01-04 22:34:28.000000000 +0900
+++ /Users/Shared/instantclient_10_2/tnsnames.ora	2011-01-04 22:57:31.000000000 +0900
@@ -10,3 +10,32 @@
     )
   )
 
+# Oracle11g R2 11.2.0.1.0 RAC for Linux x86_64 / VirtualBox 
+ORCL =
+  (DESCRIPTION =
+    (ADDRESS = (PROTOCOL = TCP)(HOST = discus-rac64-scan.macdeoracle.jp)(PORT = 1521))
+    (CONNECT_DATA =
+      (SERVER = DEDICATED)
+      (SERVICE_NAME = orcl.macdeoracle.info)
+    )
+  )
+
+ORCL2 =
+  (DESCRIPTION =
+    (ADDRESS = (PROTOCOL = TCP)(HOST = discus-rac64-scan.macdeoracle.jp)(PORT = 1521))
+    (CONNECT_DATA =
+      (SERVER = DEDICATED)
+      (SERVICE_NAME = orcl.macdeoracle.info)
+      (INSTANCE_NAME = orcl2)
+    )
+  )
+
+ORCL1 =
+  (DESCRIPTION =
+    (ADDRESS = (PROTOCOL = TCP)(HOST = discus-rac64-scan.macdeoracle.jp)(PORT = 1521))
+    (CONNECT_DATA =
+      (SERVER = DEDICATED)
+      (SERVICE_NAME = orcl.macdeoracle.info)
+      (INSTANCE_NAME = orcl1)
+    )
+  )
discus:˜ oracle$

接続テスト

事前にscan vipがどのような状態か確認しておく。

[oracle@discus164 ˜]$ srvctl status scan
SCAN VIP scan1は有効です
SCAN VIP scan1はノードdiscus264で実行されています
SCAN VIP scan2は有効です
SCAN VIP scan2はノードdiscus164で実行されています
SCAN VIP scan3は有効です
SCAN VIP scan3はノードdiscus164で実行されています
[oracle@discus164 ˜]$ 

[root@discus164 ˜]# crsctl status resource -w 'TYPE co scan' -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       discus264                                    
ora.LISTENER_SCAN2.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.LISTENER_SCAN3.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.scan1.vip
      1        ONLINE  ONLINE       discus264                                    
ora.scan2.vip
      1        ONLINE  ONLINE       discus164                                    
ora.scan3.vip
      1        ONLINE  ONLINE       discus164                                    
[root@discus164 ˜]# 

MacOS X Snow LeopardのSQL*PlusからVirtualBox上のOracle11g R2 11.2.0.1.0 RACへの接続テスト。

discus:˜ oracle$ sqlplus /nolog

SQL*Plus: Release 10.2.0.4.0 - Production on 火 1月 4 23:16:53 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

SQL> -- ロードバランシングで適当なインスタンスへ接続される。この場合インスタンス２に接続した
SQL> conn scott/tiger@orcl
接続されました。
SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
orcl2

SQL> -- ２度目はインスタンス１に接続した。（うまくいってる！）
SQL> conn scott/tiger@orcl
接続されました。
SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
orcl1

SQL> -- インスタンス１(orcl1)を狙った接続！ OK.
SQL> conn scott/tiger@orcl1 
接続されました。
SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
orcl1

SQL> -- 念のためもう一度。狙ったインスタンスへ接続している。
SQL> conn scott/tiger@orcl1
接続されました。
SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
orcl1

SQL> -- インスタンス２(orcl2)を狙った接続！ OK.
SQL> conn scott/tiger@orcl2
接続されました。
SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
orcl2

SQL> -- 念のためもう一度！。狙ったインスタンスへ接続している。
SQL> conn scott/tiger@orcl2
接続されました。
SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
orcl2

SQL> 

リモートからのも接続OK :)

以下、RACインスタンスのバージョン情報、Client側情報としてSQL*Plusのバージョン及び、OSのバージョン情報。

SQL> select * from gv$version; 

   INST_ID BANNER
---------- --------------------------------------------------------------------------------
	 2 Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
	 2 PL/SQL Release 11.2.0.1.0 - Production
	 2 CORE	11.2.0.1.0	Production
	 2 TNS for Linux: Version 11.2.0.1.0 - Production
	 2 NLSRTL Version 11.2.0.1.0 - Production
	 1 Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
	 1 PL/SQL Release 11.2.0.1.0 - Production
	 1 CORE	11.2.0.1.0	Production
	 1 TNS for Linux: Version 11.2.0.1.0 - Production
	 1 NLSRTL Version 11.2.0.1.0 - Production

10行が選択されました。

SQL> !sqlplus -v

SQL*Plus: Release 10.2.0.4.0 - Production

SQL> !system_profiler SPSoftwareDataType | grep 'System Version'
      System Version: Mac OS X 10.6.5 (10H574)

SQL> 

次回へつづく。

---

これまでのあらすじ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

・VirtualBox de RAC (Oracle11g R1編） #1
・VirtualBox de RAC (Oracle11g R1編） #2

---

・VirtualBox de Oracle11g R2 RAC #1
・VirtualBox de Oracle11g R2 RAC #2 - 事前調査など…
・VirtualBox de Oracle11g R2 RAC #3
・VirtualBox de Oracle11g R2 RAC #4
・VirtualBox de Oracle11g R2 RAC #5
・VirtualBox de Oracle11g R2 RAC #6
・VirtualBox de Oracle11g R2 RAC #7
・VirtualBox de Oracle11g R2 RAC #8
・VirtualBox de Oracle11g R2 RAC #9
・VirtualBox de Oracle11g R2 RAC #10
・VirtualBox de Oracle11g R2 RAC #11
・VirtualBox de Oracle11g R2 RAC #12
・VirtualBox de Oracle11g R2 RAC #13
・VirtualBox de Oracle11g R2 RAC #14
・VirtualBox de Oracle11g R2 RAC #15
・VirtualBox de Oracle11g R2 RAC #16
・VirtualBox de Oracle11g R2 RAC #17
・VirtualBox de Oracle11g R2 RAC #18
・VirtualBox de Oracle11g R2 RAC #19

---

VirtualBox de Oracle11g R2 RAC #16 - 番外編

VirtualBox de Oracle11g R2 RAC #16の番外編

VirtualBox de Oracle11g R2 RAC #16の番外編として、Oracle11g R2 11.2.0.1.0のOracle Grid Infrastructureをdeinstallツールのログを備忘録として残しておきます。　:)

[grid@discus164 deinstall]$ ./deinstall
Checking for required files and bootstrapping ...
Please wait ...
Location of logs /tmp/deinstall2010-12-01_08-36-01-午後/logs/

############ ORACLE DEINSTALL & DECONFIG TOOL START ############


######################## CHECK OPERATION START ########################
インストールの構成確認の開始


Oracleホームの場所が存在するかどうかを確認しています /u01/app/11.2.0/grid
選択された削除対象のOracleホームのタイプ: CRS
選択された削除対象のOracleベース: /u01/app/grid
中央インベントリの場所が存在するかどうかを確認しています /u01/app/oraInventory
Oracle Grid Infrastructureホームが存在するかどうかを確認しています /u01/app/11.2.0/grid
次のノードはこのクラスタの一部です: discus164,discus264

インストールの構成確認の終了

Traces log file: /tmp/deinstall2010-12-01_08-36-01-午後/logs//crsdc.log

ネットワーク構成チェック構成START

ネットワーク構成解除トレース・ファイルの場所: /tmp/deinstall2010-12-01_08-36-01-午後/logs/netdc_check7323528496868837695.log

構成解除するすべてのRACリスナーを指定してください[LISTENER]:

ネットワーク構成チェック構成END

ASMチェック構成START

ASM構成解除トレース・ファイルの場所: /tmp/deinstall2010-12-01_08-36-01-午後/logs/asmcadc_check7638050551281896899.log

このOracleホーム/u01/app/11.2.0/gridで自動ストレージ管理(ASM)インスタンスが検出されました。
ASM診断先: /u01/app/grid
ASMディスク・グループ: +CRS
ディスク・グループは削除されます
ASMを構成解除すると、クリーンアップ時にすべてのディスク・グループおよびそのコンテンツが削除されます。これは、
このASMインスタンスを使用するすべてのデータベースおよびACFSに影響します。
 既存のディスク・グループを保持する場合、または検出された情報が正しくない場合、'y'と入力することにより、変更できます。前述の情報(y|n)を変更しますか [n]: y
ASMの診断先を指定してください [/u01/app/grid]: 
このASMインスタンスによって管理されているディスク・グループを指定してください [+CRS]: 

ASMを構成解除すると、クリーンアップ時にすべてのディスク・グループが削除されます。構成解除ツールでディスク・グループy|nを削除しますか [y]: y


######################### CHECK OPERATION END #########################


####################### CHECK OPERATION SUMMARY #######################
Oracle Grid Infrastructureホーム: /u01/app/11.2.0/grid
Oracleホームが存在するクラスタ・ノード: (ノードを","で区切って入力してください。例: node1,node2,...)discus164,discus264
選択された削除対象のOracleホーム: /u01/app/11.2.0/grid
Oracleホームが登録されているインベントリの場所: /u01/app/oraInventory
次のRACリスナーが構成解除されます: LISTENER
ASMインスタンスはこのOracleホームから構成解除されます
続行しますか (y - はい、n - いいえ)[n]: y
このセッションのログは/tmp/deinstall2010-12-01_08-36-01-午後/logs/deinstall_deconfig2010-12-01_08-36-34-PM.outに書き込まれます
このセッションのすべてのエラー・メッセージは/tmp/deinstall2010-12-01_08-36-01-午後/logs/deinstall_deconfig2010-12-01_08-36-34-PM.errに書き込まれます

######################## CLEAN OPERATION START ########################
ASM構成解除トレース・ファイルの場所: /tmp/deinstall2010-12-01_08-36-01-午後/logs/asmcadc_clean4713857881917098991.log
ASMクリーンアップ構成START
ASMクリーンアップ構成END

ネットワーク構成クリーニング構成START

ネットワーク構成解除トレース・ファイルの場所: /tmp/deinstall2010-12-01_08-36-01-午後/logs/netdc_clean533226112421006626.log

RACリスナーの構成解除: LISTENER

リスナーの構成解除: LISTENER
    リスナーを停止しています: LISTENER
    リスナーの停止に成功しました。
    リスナーを登録解除しています: LISTENER
    リスナーの登録解除に成功しました。
リスナーは正常に構成解除されました。

すべてのノードでネーミング・メソッド構成ファイルの構成解除中です...
ネーミング・メソッド構成ファイルが正常に構成解除されました。 

すべてのノードでローカル・ネット・サービス名構成ファイルの構成解除中です...
ローカル・ネット・サービス名構成ファイルが正常に構成解除されました。 

すべてのノードでディレクトリ使用構成ファイルの構成解除中です...
ディレクトリ使用構成ファイルが正常に構成解除されました。 

すべてのノードでバックアップ・ファイルの構成解除中です...
バックアップ・ファイルが正常に構成解除されました。 

ネットワーク構成が正常にクリーンアップされました。

ネットワーク構成クリーニング構成END


---------------------------------------->

ノード"discus264"のrootユーザーまたは管理者として次のコマンドを実行します。


/tmp/deinstall2010-12-01_08-36-01-午後/perl/bin/perl -I/tmp/deinstall2010-12-01_08-36-01-午後/perl/lib -I/tmp/deinstall2010-12-01_08-36-01-午後/crs/install /tmp/deinstall2010-12-01_08-36-01-午後/crs/install/rootcrs.pl -force  -delete -paramfile /tmp/deinstall2010-12-01_08-36-01-午後/response/deinstall_Ora11g_gridinfrahome1.rsp

ノード"discus164"のrootユーザーまたは管理者として次のコマンドを実行します。

/tmp/deinstall2010-12-01_08-36-01-午後/perl/bin/perl -I/tmp/deinstall2010-12-01_08-36-01-午後/perl/lib -I/tmp/deinstall2010-12-01_08-36-01-午後/crs/install /tmp/deinstall2010-12-01_08-36-01-午後/crs/install/rootcrs.pl -force  -delete -paramfile /tmp/deinstall2010-12-01_08-36-01-午後/response/deinstall_Ora11g_gridinfrahome1.rsp -lastnode

前述のコマンドを実行した後、[Enter]を押します

<----------------------------------------

Oracle Universal Installerクリーンアップの開始

Oracleホーム'/u01/app/11.2.0/grid'をローカル・ノードの中央インベントリからデタッチします : 終了

ローカル・ノードのディレクトリ'/u01/app/11.2.0/grid'を削除します : 終了

ローカル・ノードのディレクトリ'/u01/app/oraInventory'を削除します : 終了

ローカル・ノードのディレクトリ'/u01/app/grid'を削除します : 終了

Oracleホーム'/u01/app/11.2.0/grid'をリモート・ノード'discus264'の中央インベントリからデタッチします : 終了

リモート・ノード'discus264'のディレクトリ'/u01/app/11.2.0/grid'を削除します : 終了

リモート・ノード'discus264'のディレクトリ'/u01/app/oraInventory'を削除します : 終了

リモート・ノード'discus264'のディレクトリ'/u01/app/grid'を削除します : 終了

Oracle Universal Installerのクリーンアップが成功しました。

Oracle Universal Installerクリーンアップの終了


Oracleインストール・クリーンアップの開始

インストールのクリーンアップ操作により、ノードdiscus164の一時ディレクトリ/tmp/installを削除しています
インストールのクリーンアップ操作により、ノードdiscus264の一時ディレクトリ/tmp/installを削除しています

Oracleインストール・クリーンアップの終了


######################### CLEAN OPERATION END #########################


####################### CLEAN OPERATION SUMMARY #######################
ASMインスタンスはOracleホームから正常に構成解除されました
次のRACリスナーが正常に構成解除されました: LISTENER
Oracleクラスタウェアはノード"discus164"で停止され、正常に構成解除されています
Oracleクラスタウェアはノード"discus264"で停止され、正常に構成解除されています
Oracleクラスタウェアは正常に停止および構成解除されています。
Oracleホーム'/u01/app/11.2.0/grid'がローカル・ノードの中央インベントリから正常にデタッチされました。
ローカル・ノードのディレクトリ'/u01/app/11.2.0/grid'が正常に削除されました。
ローカル・ノードのディレクトリ'/u01/app/oraInventory'が正常に削除されました。
ローカル・ノードのディレクトリ'/u01/app/grid'が正常に削除されました。
Oracleホーム'/u01/app/11.2.0/grid'がリモート・ノード'discus264'の中央インベントリから正常にデタッチされました。
リモート・ノード'discus264'のディレクトリ'/u01/app/11.2.0/grid'が正常に削除されました。
リモート・ノード'discus264'のディレクトリ'/u01/app/oraInventory'が正常に削除されました。
リモート・ノード'discus264'のディレクトリ'/u01/app/grid'が正常に削除されました。
Oracle Universal Installerのクリーンアップが成功しました。


セッション終了時にノード'discus164,discus264'でrootとして'rm -rf /etc/oraInst.loc'を実行します。

Oracleインストールにより、一時ディレクトリが正常にクリーンアップされました。
#######################################################################


############# ORACLE DEINSTALL & DECONFIG TOOL END #############

[grid@discus164 deinstall]$ 

---

これまでのあらすじ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

・VirtualBox de RAC (Oracle11g R1編） #1
・VirtualBox de RAC (Oracle11g R1編） #2

---

・VirtualBox de Oracle11g R2 RAC #1
・VirtualBox de Oracle11g R2 RAC #2 - 事前調査など…
・VirtualBox de Oracle11g R2 RAC #3
・VirtualBox de Oracle11g R2 RAC #4
・VirtualBox de Oracle11g R2 RAC #5
・VirtualBox de Oracle11g R2 RAC #6
・VirtualBox de Oracle11g R2 RAC #7
・VirtualBox de Oracle11g R2 RAC #8
・VirtualBox de Oracle11g R2 RAC #9
・VirtualBox de Oracle11g R2 RAC #10
・VirtualBox de Oracle11g R2 RAC #11
・VirtualBox de Oracle11g R2 RAC #12
・VirtualBox de Oracle11g R2 RAC #13
・VirtualBox de Oracle11g R2 RAC #14
・VirtualBox de Oracle11g R2 RAC #15
・VirtualBox de Oracle11g R2 RAC #16
・VirtualBox de Oracle11g R2 RAC #17
・VirtualBox de Oracle11g R2 RAC #18
・VirtualBox de Oracle11g R2 RAC #19

VirtualBox de Oracle11g R2 RAC #19

VirtualBox de Oracle11g R2 RACのつづき。

いよいよデータベースの作成です。 :)

1. ハードウェア構成(VMなのでVMの構成も含めて）、ソフトウェア構成など
2. Linux (CentOS 5.5 x86_64)のインストール
3. Openfiler2.3 x86のインストール
4. Openfiler2.3 x86によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２、その３
6. Oracle所有者、Oracle Grid Infrastructureユーザの作成と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. Oracle RACノード間リモートアクセスの構成とntpの構成
   （sshの構成は念のために行った、多分、実施しなくても大丈夫だと思うけど…ついでなので、ちょいと意地悪な実験をしてみた）
9. ローカルネームサーバの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Automatic Storage Management(ASMLib 2.0.5 x84_64)のインストール及び構成
12. Oracle11g R2 11.2.0.1.0 RACインストール事前作業
13. Oracle11g R2 11.2.0.1.0 Grid Infrastractureのインストール
14. Oracle11g R2 11.2.0.1.0 Database softwareのインストール
15. Oracle11g R2 11.2.0.1.0 examplesのインストール
16. Oracle Cluster databaseの作成
17. Net Serviceの確認
18. Oralce Grid InsfastructureとDatabase構成の確認
19. Clusterの開始と停止の確認
20. 簡単なTransparent Application Failover (TAF)の確認

Oracle Cluster databaseの作成

映像を見てもお分かりだと思いますが、VirtualBox上でクラスタデータベースを作成するとほぼ１００％、DBCAの最後のダイアログを表示後DBCAを起動したVMが固まります。
Oracle11g R1 RACをVirtualBox上で構築した時と同じ症状です。DBCAのダイアログ上、データベースは作成されましたと表示されているのでそれを信じるばかり (^^;;;

念のため１時間ほど放置したあと、固まったVMは強制終了、残るノードはCentOSをシャットダウンします。その後、Openfiler、RACの両ノードを起動します。（ノード間の処理で固まっているようで実は処理に時間を要していることがなんどかあったので…念のため）

grid infrastructureユーザからcrsctlコマンドで状態を確認した結果は以下。（ちなみに、VM再起動後の状態）

[grid@discus164 ˜]$ crsctl status resource -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.CRS.dg
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.DATA.dg
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.FRA.dg
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.LISTENER.lsnr
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.asm
               ONLINE  ONLINE       discus164                Started             
               ONLINE  ONLINE       discus264                Started             
ora.eons
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.gsd
               OFFLINE OFFLINE      discus164                                    
               OFFLINE OFFLINE      discus264                                    
ora.net1.network
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.ons
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.registry.acfs
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       discus264                                    
ora.LISTENER_SCAN2.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.LISTENER_SCAN3.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.discus164.vip
      1        ONLINE  ONLINE       discus164                                    
ora.discus264.vip
      1        ONLINE  ONLINE       discus264                                    
ora.oc4j
      1        OFFLINE OFFLINE                                                   
ora.orcl.db
      1        ONLINE  ONLINE       discus164                Open                
      2        ONLINE  ONLINE       discus264                Open                
ora.scan1.vip
      1        ONLINE  ONLINE       discus264                                    
ora.scan2.vip
      1        ONLINE  ONLINE       discus164                                    
ora.scan3.vip
      1        ONLINE  ONLINE       discus164                                    
[grid@discus164 ˜]$ 

[oracle@discus164 ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 火 11月 30 14:54:50 2010

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

SQL> conn / as sysdba
パスワードを入力してください: 
接続されました。
SQL> set linesize 132
SQL> select * from gv$version;

   INST_ID BANNER
---------- --------------------------------------------------------------------------------
	 1 Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
	 1 PL/SQL Release 11.2.0.1.0 - Production
	 1 CORE	11.2.0.1.0	Production
	 1 TNS for Linux: Version 11.2.0.1.0 - Production
	 1 NLSRTL Version 11.2.0.1.0 - Production
	 2 Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
	 2 PL/SQL Release 11.2.0.1.0 - Production
	 2 CORE	11.2.0.1.0	Production
	 2 TNS for Linux: Version 11.2.0.1.0 - Production
	 2 NLSRTL Version 11.2.0.1.0 - Production

10行が選択されました。

SQL> 

ふ〜、なんとかできたようですね。　とりあえず遊べそうです。

次回へつづく。　Grid Infrastructure周りはもっと調べないと…覚える必要のあることはまだまだ多い (^^;;

Oracle Clusterware管理およびデプロイメント・ガイド 11gリリース2（11.2非推奨のサブプログラムまたはコマンド…このマニュアルもちゃんと読んでおかないとな。＞＜

---

これまでのあらすじ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

・VirtualBox de RAC (Oracle11g R1編） #1
・VirtualBox de RAC (Oracle11g R1編） #2

---

・VirtualBox de Oracle11g R2 RAC #1
・VirtualBox de Oracle11g R2 RAC #2 - 事前調査など…
・VirtualBox de Oracle11g R2 RAC #3
・VirtualBox de Oracle11g R2 RAC #4
・VirtualBox de Oracle11g R2 RAC #5
・VirtualBox de Oracle11g R2 RAC #6
・VirtualBox de Oracle11g R2 RAC #7
・VirtualBox de Oracle11g R2 RAC #8
・VirtualBox de Oracle11g R2 RAC #9
・VirtualBox de Oracle11g R2 RAC #10
・VirtualBox de Oracle11g R2 RAC #11
・VirtualBox de Oracle11g R2 RAC #12
・VirtualBox de Oracle11g R2 RAC #13
・VirtualBox de Oracle11g R2 RAC #14
・VirtualBox de Oracle11g R2 RAC #15
・VirtualBox de Oracle11g R2 RAC #16
・VirtualBox de Oracle11g R2 RAC #17
・VirtualBox de Oracle11g R2 RAC #18

VirtualBox de Oracle11g R2 RAC #18

VirtualBox de Oracle11g R2 RACのつづきです。

インストールしなくてもいいんだけどいろいろと試したくなったときは便利なので、次いでにexamplesもインストール。

1. ハードウェア構成(VMなのでVMの構成も含めて）、ソフトウェア構成など
2. Linux (CentOS 5.5 x86_64)のインストール
3. Openfiler2.3 x86のインストール
4. Openfiler2.3 x86によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２、その３
6. Oracle所有者、Oracle Grid Infrastructureユーザの作成と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. Oracle RACノード間リモートアクセスの構成とntpの構成
   （sshの構成は念のために行った、多分、実施しなくても大丈夫だと思うけど…ついでなので、ちょいと意地悪な実験をしてみた）
9. ローカルネームサーバの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Automatic Storage Management(ASMLib 2.0.5 x84_64)のインストール及び構成
12. Oracle11g R2 11.2.0.1.0 RACインストール事前作業
13. Oracle11g R2 11.2.0.1.0 Grid Infrastractureのインストール
14. Oracle11g R2 11.2.0.1.0 Database softwareのインストール
15. Oracle11g R2 11.2.0.1.0 examplesのインストール
16. Oracle Cluster databaseの作成
17. Net Serviceの確認
18. Oralce Grid InsfastructureとDatabase構成の確認
19. Clusterの開始と停止の確認
20. 簡単なTransparent Application Failover (TAF)の確認

Oracle11g R2 11.2.0.1.0 examplesのインストール

[oracle@discus164 database]$ 
[oracle@discus164 database]$ 
[oracle@discus164 database]$ cd ../examples
[oracle@discus164 examples]$ ll
合計 48
drwxr-xr-x  7 oracle oinstall 4096  8月 12  2009 doc
drwxr-xr-x  4 oracle oinstall 4096  8月 15  2009 install
drwxrwxr-x  2 oracle oinstall 4096  8月 15  2009 response
-rwxr-xr-x  1 oracle oinstall 3230  8月 15  2009 runInstaller
drwxr-xr-x 12 oracle oinstall 4096  8月 15  2009 stage
-rw-r--r--  1 oracle oinstall 3419  8月 18  2009 welcome.html
[oracle@discus164 examples]$ 

[oracle@discus164 examples]$ ./runInstaller
Oracle Universal Installerを起動中です...
・・・中略・・・

次回へつづく。

---

これまでのあらすじ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

・VirtualBox de RAC (Oracle11g R1編） #1
・VirtualBox de RAC (Oracle11g R1編） #2

---

・VirtualBox de Oracle11g R2 RAC #1
・VirtualBox de Oracle11g R2 RAC #2 - 事前調査など…
・VirtualBox de Oracle11g R2 RAC #3
・VirtualBox de Oracle11g R2 RAC #4
・VirtualBox de Oracle11g R2 RAC #5
・VirtualBox de Oracle11g R2 RAC #6
・VirtualBox de Oracle11g R2 RAC #7
・VirtualBox de Oracle11g R2 RAC #8
・VirtualBox de Oracle11g R2 RAC #9
・VirtualBox de Oracle11g R2 RAC #10
・VirtualBox de Oracle11g R2 RAC #11
・VirtualBox de Oracle11g R2 RAC #12
・VirtualBox de Oracle11g R2 RAC #13
・VirtualBox de Oracle11g R2 RAC #14
・VirtualBox de Oracle11g R2 RAC #15
・VirtualBox de Oracle11g R2 RAC #16
・VirtualBox de Oracle11g R2 RAC #17

VirtualBox de Oracle11g R2 RAC #17

VirtualBox de Oracle11g R2 RACのつづきです。

つづいてOracle11g R2 11.2.0.1.0 Database Installのインストール。
データベースは作成しないでソフトウェアだけのインストールを行います。

1. ハードウェア構成(VMなのでVMの構成も含めて）、ソフトウェア構成など
2. Linux (CentOS 5.5 x86_64)のインストール
3. Openfiler2.3 x86のインストール
4. Openfiler2.3 x86によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２、その３
6. Oracle所有者、Oracle Grid Infrastructureユーザの作成と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. Oracle RACノード間リモートアクセスの構成とntpの構成
   （sshの構成は念のために行った、多分、実施しなくても大丈夫だと思うけど…ついでなので、ちょいと意地悪な実験をしてみた）
9. ローカルネームサーバの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Automatic Storage Management(ASMLib 2.0.5 x84_64)のインストール及び構成
12. Oracle11g R2 11.2.0.1.0 RACインストール事前作業
13. Oracle11g R2 11.2.0.1.0 Grid Infrastractureのインストール
14. Oracle11g R2 11.2.0.1.0 Database softwareのインストール
15. Oracle11g R2 11.2.0.1.0 examplesのインストール
16. Oracle Cluster databaseの作成
17. Net Serviceの確認
18. Oralce Grid InsfastructureとDatabase構成の確認
19. Clusterの開始と停止の確認
20. 簡単なTransparent Application Failover (TAF)の確認

ASMディスクグループの作成

Grid Infrastructureのインストール同様、Oracle所有者でもsshはパスフレーズありであらかじめ作成しておきます。OUIが作ってくれるだろうということを期待してね。

と、その前に、asmcaでOracleデータファイル及び、フラッシュ・リカバリ・エリア向けASMディスクグループを作成しておきました。
データファイル向けに+DATA、フラッシュ・リカバリ・エリア向けに+FRAというASMディスクグループを作成します。

Oracle11g R2 11.2.0.1.0 Database softwareのインストール

次に、Oracle Database 11g R2 11.2.0.1.0をインストールします。データベースは作成せず、別途dbcaを利用してデータベースを作成します。

省略していますが、お約束、root.shの実行もお忘れなく！

次回へつづく。

---

これまでのあらすじ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

・VirtualBox de RAC (Oracle11g R1編） #1
・VirtualBox de RAC (Oracle11g R1編） #2

---

・VirtualBox de Oracle11g R2 RAC #1
・VirtualBox de Oracle11g R2 RAC #2 - 事前調査など…
・VirtualBox de Oracle11g R2 RAC #3
・VirtualBox de Oracle11g R2 RAC #4
・VirtualBox de Oracle11g R2 RAC #5
・VirtualBox de Oracle11g R2 RAC #6
・VirtualBox de Oracle11g R2 RAC #7
・VirtualBox de Oracle11g R2 RAC #8
・VirtualBox de Oracle11g R2 RAC #9
・VirtualBox de Oracle11g R2 RAC #10
・VirtualBox de Oracle11g R2 RAC #11
・VirtualBox de Oracle11g R2 RAC #12
・VirtualBox de Oracle11g R2 RAC #13
・VirtualBox de Oracle11g R2 RAC #14
・VirtualBox de Oracle11g R2 RAC #15
・VirtualBox de Oracle11g R2 RAC #16

VirtualBox de Oracle11g R2 RAC #16

VirtualBox de Oracle11g R2 RACのつづきです。

いよいよOracle11g R2 11.2.0.1.0 Grid Infrastractureのインストール♪

1. ハードウェア構成(VMなのでVMの構成も含めて）、ソフトウェア構成など
2. Linux (CentOS 5.5 x86_64)のインストール
3. Openfiler2.3 x86のインストール
4. Openfiler2.3 x86によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２、その３
6. Oracle所有者、Oracle Grid Infrastructureユーザの作成と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. Oracle RACノード間リモートアクセスの構成とntpの構成
   （sshの構成は念のために行った、多分、実施しなくても大丈夫だと思うけど…ついでなので、ちょいと意地悪な実験をしてみた）
9. ローカルネームサーバの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Automatic Storage Management(ASMLib 2.0.5 x84_64)のインストール及び構成
12. Oracle11g R2 11.2.0.1.0 RACインストール事前作業
13. Oracle11g R2 11.2.0.1.0 Grid Infrastractureのインストール
14. Oracle11g R2 11.2.0.1.0 Database softwareのインストール
15. Oracle11g R2 11.2.0.1.0 examplesのインストール
16. Oracle Cluster databaseの作成
17. Net Serviceの確認
18. Oralce Grid InsfastructureとDatabase構成の確認
19. Clusterの開始と停止の確認
20. 簡単なTransparent Application Failover (TAF)の確認

Oracle11g R2 11.2.0.1.0 Grid Infrastractureのインストール

今回、確かめたかったこともあり、意図的にパスフレーズ付きでsshを手動構成しておいた。
その結果は…CVUの検査はパスするもののOUI上ではsshの構成がNGとなりOUIからsshの構成を行った。その後は問題なくインストールできた :)　便になったねOUI.

[grid@discus164 grid]$ ./runInstaller 
[1] 4417
[grid@discus164 grid]$ Oracle Universal Installerを起動中です...

一時領域の確認中: 120MBを超えている必要があります.   実際 32846MB    問題なし
スワップ領域の確認中: 150MBを超えている必要があります.   実際 5951MB    問題なし
モニターの確認中: 少なくとも256色表示するよう設定されている必要があります.    実際 16777216    問題なし
Oracle Universal Installerの起動を準備中 /tmp/OraInstall2010-11-29_01-51-19PM. お待ちください...

インストールの後半で、上記画面が表示されたら、いつものお約束、orainstRoot.shの実行とroot.shスクリプトの実行です！
RACを構成する全ノードのrootユーザで。最初にOUIを実行したノードで実行。成功したら以後残りのノードで実施（残りのノードでは平行実行可能だとか…今回は２ノードなので確認できず…）。

まず、OUIを実行したノードで実行！

[root@discus164 ˜]#
[root@discus164 ˜]# /u01/app/oraInventory/orainstRoot.sh
権限を変更中 /u01/app/oraInventory.
グループの読取り/書込み権限を追加中。
全ユーザーの読取り/書込み/実行権限を削除中。

グループ名の変更 /u01/app/oraInventory 宛先 oinstall.
スクリプトの実行が完了しました。

[root@discus164 ˜]#
[root@discus164 ˜]#
[root@discus164 ˜]# /u01/app/11.2.0/grid/root.sh
Running Oracle 11g root.sh script...

The following environment variables are set as:
    ORACLE_OWNER= grid
    ORACLE_HOME=  /u01/app/11.2.0/grid

Enter the full pathname of the local bin directory: [/usr/local/bin]: 
   Copying dbhome to /usr/local/bin ...
   Copying oraenv to /usr/local/bin ...
   Copying coraenv to /usr/local/bin ...


Creating /etc/oratab file...

・・・中略・・・

  profile reader pa cert TP
  profile reader peer cert TP
  peer user cert
  pa user cert
Adding daemon to inittab
CRS-4123: Oracle High Availability Services has been started.
ohasd is starting
ADVM/ACFS is not supported on centos-release-5-5.el5.centos

CRS-2672: 'ora.gipcd'('discus164')の起動を試行しています

・・・中略・・・

CRS-2676: 'ora.ctssd'('discus164')の起動が成功しました

ASMは正常に作成され、起動しました。

ディスク・グループCRSは正常に作成されました。

clscfg: -install mode specified
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
CRS-2672: 'ora.crsd'('discus164')の起動を試行しています
CRS-2676: 'ora.crsd'('discus164')の起動が成功しました
CRS-4256: Updating the profile
Successful addition of voting disk 5d6c953bf3aa4fe6bfff2a0f9b1e0d37.
Successfully replaced voting disk group with +CRS.
CRS-4256: Updating the profile
CRS-4266: Voting file(s) successfully replaced
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   5d6c953bf3aa4fe6bfff2a0f9b1e0d37 (ORCL:CRSVOL1) [CRS]
Located 1 voting disk(s).
CRS-2673: 'ora.crsd'('discus164')の停止を試行しています

・・・中略・・・

CRS-2676: 'ora.asm'('discus164')の起動が成功しました
CRS-2672: 'ora.CRS.dg'('discus164')の起動を試行しています
CRS-2676: 'ora.CRS.dg'('discus164')の起動が成功しました

discus164     2010/11/29 14:21:13     /u01/app/11.2.0/grid/cdata/discus164/backup_20101129_142113.olr
Configure Oracle Grid Infrastructure for a Cluster ... succeeded
クラスタウェアのインベントリ・プロパティの更新中
Oracle Universal Installerを起動中です...

スワップ領域の確認中: 500MBを超えている必要があります.   実際 5951MB    問題なし
The inventory pointer is located at /etc/oraInst.loc
The inventory is located at /u01/app/oraInventory
'UpdateNodeList'が成功しました。
[root@discus164 ˜]# 

ADVM/ACFS is not supported on centos-release-5-5.el5.centosという気になるメッセージがあったがこれはCentOSが正式にサポートされていないことが影響している。
一昨年暮れのエントリだけど、以下のブログが参考になるかも。

参考:
http://brianbontrager.blogspot.com/2009/09/learning-asm-breakin-rules-or-running.html

2011/1/4追記：
http://ivan.kartik.sk/index.php?show_article=49
リリースを偽装する方法もあるんだけどね。後者の方が楽は楽だけど元に戻すのが面倒だから今回はパスした。

簡単にリカバル方法がよくわかんなかったんでOracle Grid Infrastructureを一旦deinstallした。（これが一番わかりやすい！）
Oracle Grid Infrastructureをdeinstallコマンドで削除した記録は別途書くとして、一旦deinstallしたと思ってください！！！

ということで、OUIでOracle Grid Infrastractureをインストール。

orainstRoot.shを実行したところで、前述の参考ブログに記載されていたCentOS向け手当を行う。手当を行ってからroot.shを実行する。

orainstRoot.shを実行したところで、前述の参考ブログに記載されていたCentOS向け手当を行う。手当を行ってからroot.shを実行する。

CentOS上へのOracle Grid Infrastructureインストールでは大切（らしい）なので２度、書きましたよw

Oracle Grid Infrastructureユーザの$ORACLE_HOME/lib/osds_acfslib.pmの278行目以下にCentOSも正常に処理できるよう修正を加える。

[grid@discus164 ˜]$ su -
パスワード:
[root@discus164 ˜]# cd /u01/app/11.2.0/grid/lib
[root@discus164 lib]# 
[root@discus164 lib]# cp -p osds_acfslib.pm osds_acfslib.pm.org
[root@discus164 lib]# 
[root@discus164 lib]# vi osds_acfslib.pm
[root@discus164 lib]# 
[root@discus164 lib]# diff -u osds_acfslib.pm osds_acfslib.pm.org
--- osds_acfslib.pm	2010/11/29 17:19:00.000000000 +0900
+++ osds_acfslib.pm.org	2009-07-02 11:13:48.000000000 +0900
@@ -278,8 +278,7 @@
   # OK, now check to see if we support this release
   $supported = 0;
   if (($release =˜ /enterprise-release-5/) ||
-         ($release =˜ /redhat-release-5/)  ||
-	 ($release =˜ /centos-release-5/))
+         ($release =˜ /redhat-release-5/))
   {
     # Redhat 5
     $supported = 1;
[root@discus164 lib]# 

多分上記の修正だけで対処できると思うのだが、自信がないので以下のこともやっておいた… 写経になっております。m(_ _)m (RACを構成する全ノードのrootユーザで実施）

[root@discus164 ˜]# mkdir /lib/modules/2.6.18-194.17.1.el5/extra/usm
[root@discus164 ˜]# 
[root@discus164 ˜]# 
[root@discus164 ˜]# ls /u01/app/11.2.0/grid/install/usm/EL5/x86_64/2.6.18-8/2.6.18-8.el5-x86_64/bin/*ko
/u01/app/11.2.0/grid/install/usm/EL5/x86_64/2.6.18-8/2.6.18-8.el5-x86_64/bin/oracleacfs.ko
/u01/app/11.2.0/grid/install/usm/EL5/x86_64/2.6.18-8/2.6.18-8.el5-x86_64/bin/oracleadvm.ko
/u01/app/11.2.0/grid/install/usm/EL5/x86_64/2.6.18-8/2.6.18-8.el5-x86_64/bin/oracleoks.ko
[root@discus164 ˜]# 
[root@discus164 ˜]# 
[root@discus164 ˜]# cp /u01/app/11.2.0/grid/install/usm/EL5/x86_64/2.6.18-8/2.6.18-8.el5-x86_64/bin/*ko /lib/modules/2.6.18-194.17.1.el5/extra/usm
[root@discus164 ˜]# chmod 744 /lib/modules/2.6.18-194.17.1.el5/extra/usm
[root@discus164 ˜]# 
[root@discus164 ˜]# depmod
[root@discus164 ˜]# 
[root@discus164 ˜]# cp /u01/app/11.2.0/grid/install/usm/EL5/x86_64/2.6.18-8/2.6.18-8.el5-x86_64/bin/acfsdbg /sbin
[root@discus164 ˜]# chmod 755 /sbin/acfsdbg

ここまでの作業を終えたらOUIでOracle Grid InfrastructureをOUIでインストールする。手順は前述の映像を見てくださいね。

お約束のorainstRoot.shそれに続いて、root.shをOUIを起動したノードで実施、その後、残りのノードでも同様にrootユーザで実施する。

root.shの実行。こんどは大丈夫でしょうか〜〜〜〜。

[root@discus164 grid]# ./root.sh
Running Oracle 11g root.sh script...

The following environment variables are set as:
    ORACLE_OWNER= grid
    ORACLE_HOME=  /u01/app/11.2.0/grid

Enter the full pathname of the local bin directory: [/usr/local/bin]: 
The file "dbhome" already exists in /usr/local/bin.  Overwrite it? (y/n) 
[n]: y
   Copying dbhome to /usr/local/bin ...
The file "oraenv" already exists in /usr/local/bin.  Overwrite it? (y/n) 
[n]: y
   Copying oraenv to /usr/local/bin ...
The file "coraenv" already exists in /usr/local/bin.  Overwrite it? (y/n) 
[n]: y
   Copying coraenv to /usr/local/bin ...


Creating /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.
2010-11-29 17:23:44: Parsing the host name
2010-11-29 17:23:44: Checking for super user privileges
2010-11-29 17:23:44: User has super user privileges

Using configuration parameter file: /u01/app/11.2.0/grid/crs/install/crsconfig_params
Creating trace directory
LOCAL ADD MODE 
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
  root wallet
  root wallet cert
  root cert export
  peer wallet
  profile reader wallet
  pa wallet
  peer wallet keys
  pa wallet keys
  peer cert request
  pa cert request
  peer cert
  pa cert
  peer root cert TP
  profile reader root cert TP
  pa root cert TP
  peer pa cert TP
  pa peer cert TP
  profile reader pa cert TP
  profile reader peer cert TP
  peer user cert
  pa user cert
Adding daemon to inittab
CRS-4123: Oracle High Availability Services has been started.
ohasd is starting
CRS-2672: 'ora.gipcd'('discus164')の起動を試行しています
CRS-2672: 'ora.mdnsd'('discus164')の起動を試行しています
CRS-2676: 'ora.gipcd'('discus164')の起動が成功しました
CRS-2676: 'ora.mdnsd'('discus164')の起動が成功しました
CRS-2672: 'ora.gpnpd'('discus164')の起動を試行しています
CRS-2676: 'ora.gpnpd'('discus164')の起動が成功しました
CRS-2672: 'ora.cssdmonitor'('discus164')の起動を試行しています
CRS-2676: 'ora.cssdmonitor'('discus164')の起動が成功しました
CRS-2672: 'ora.cssd'('discus164')の起動を試行しています
CRS-2672: 'ora.diskmon'('discus164')の起動を試行しています
CRS-2676: 'ora.diskmon'('discus164')の起動が成功しました
CRS-2676: 'ora.cssd'('discus164')の起動が成功しました
CRS-2672: 'ora.ctssd'('discus164')の起動を試行しています
CRS-2676: 'ora.ctssd'('discus164')の起動が成功しました

ASMは正常に作成され、起動しました。

ディスク・グループCRSは正常に作成されました。

clscfg: -install mode specified
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
CRS-2672: 'ora.crsd'('discus164')の起動を試行しています
CRS-2676: 'ora.crsd'('discus164')の起動が成功しました
CRS-4256: Updating the profile
Successful addition of voting disk 8f431fe5d1304fd9bf6ad331d3aef536.
Successfully replaced voting disk group with +CRS.
CRS-4256: Updating the profile
CRS-4266: Voting file(s) successfully replaced
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   8f431fe5d1304fd9bf6ad331d3aef536 (ORCL:CRSVOL1) [CRS]
Located 1 voting disk(s).
CRS-2673: 'ora.crsd'('discus164')の停止を試行しています
CRS-2677: 'ora.crsd'('discus164')の停止が成功しました
CRS-2673: 'ora.asm'('discus164')の停止を試行しています
CRS-2677: 'ora.asm'('discus164')の停止が成功しました
CRS-2673: 'ora.ctssd'('discus164')の停止を試行しています
CRS-2677: 'ora.ctssd'('discus164')の停止が成功しました
CRS-2673: 'ora.cssdmonitor'('discus164')の停止を試行しています
CRS-2677: 'ora.cssdmonitor'('discus164')の停止が成功しました
CRS-2673: 'ora.cssd'('discus164')の停止を試行しています
CRS-2677: 'ora.cssd'('discus164')の停止が成功しました
CRS-2673: 'ora.gpnpd'('discus164')の停止を試行しています
CRS-2677: 'ora.gpnpd'('discus164')の停止が成功しました
CRS-2673: 'ora.gipcd'('discus164')の停止を試行しています
CRS-2677: 'ora.gipcd'('discus164')の停止が成功しました
CRS-2673: 'ora.mdnsd'('discus164')の停止を試行しています
CRS-2677: 'ora.mdnsd'('discus164')の停止が成功しました
CRS-2672: 'ora.mdnsd'('discus164')の起動を試行しています
CRS-2676: 'ora.mdnsd'('discus164')の起動が成功しました
CRS-2672: 'ora.gipcd'('discus164')の起動を試行しています
CRS-2676: 'ora.gipcd'('discus164')の起動が成功しました
CRS-2672: 'ora.gpnpd'('discus164')の起動を試行しています
CRS-2676: 'ora.gpnpd'('discus164')の起動が成功しました
CRS-2672: 'ora.cssdmonitor'('discus164')の起動を試行しています
CRS-2676: 'ora.cssdmonitor'('discus164')の起動が成功しました
CRS-2672: 'ora.cssd'('discus164')の起動を試行しています
CRS-2672: 'ora.diskmon'('discus164')の起動を試行しています
CRS-2676: 'ora.diskmon'('discus164')の起動が成功しました
CRS-2676: 'ora.cssd'('discus164')の起動が成功しました
CRS-2672: 'ora.ctssd'('discus164')の起動を試行しています
CRS-2676: 'ora.ctssd'('discus164')の起動が成功しました
CRS-2672: 'ora.asm'('discus164')の起動を試行しています
CRS-2676: 'ora.asm'('discus164')の起動が成功しました
CRS-2672: 'ora.crsd'('discus164')の起動を試行しています
CRS-2676: 'ora.crsd'('discus164')の起動が成功しました
CRS-2672: 'ora.evmd'('discus164')の起動を試行しています
CRS-2676: 'ora.evmd'('discus164')の起動が成功しました
CRS-2672: 'ora.asm'('discus164')の起動を試行しています
CRS-2676: 'ora.asm'('discus164')の起動が成功しました
CRS-2672: 'ora.CRS.dg'('discus164')の起動を試行しています
CRS-2676: 'ora.CRS.dg'('discus164')の起動が成功しました
CRS-2672: 'ora.registry.acfs'('discus164')の起動を試行しています
CRS-2676: 'ora.registry.acfs'('discus164')の起動が成功しました

discus164     2010/11/29 17:30:15     /u01/app/11.2.0/grid/cdata/discus164/backup_20101129_173015.olr
パッケージインストールの準備中...
cvuqdisk-1.0.7-1
Configure Oracle Grid Infrastructure for a Cluster ... succeeded
クラスタウェアのインベントリ・プロパティの更新中
Oracle Universal Installerを起動中です...

スワップ領域の確認中: 500MBを超えている必要があります.   実際 5951MB    問題なし
The inventory pointer is located at /etc/oraInst.loc
The inventory is located at /u01/app/oraInventory
'UpdateNodeList'が成功しました。
[root@discus164 grid]#

お〜〜、でけた。

では、他のノードでも実行
残りのノードでも同様の操作実施後root.sh実行

[root@discus264 grid]# ./root.sh
Running Oracle 11g root.sh script...

The following environment variables are set as:
    ORACLE_OWNER= grid
    ORACLE_HOME=  /u01/app/11.2.0/grid

Enter the full pathname of the local bin directory: [/usr/local/bin]: 
The file "dbhome" already exists in /usr/local/bin.  Overwrite it? (y/n) 
[n]: y
   Copying dbhome to /usr/local/bin ...
The file "oraenv" already exists in /usr/local/bin.  Overwrite it? (y/n) 
[n]: y
   Copying oraenv to /usr/local/bin ...
The file "coraenv" already exists in /usr/local/bin.  Overwrite it? (y/n) 
[n]: y
   Copying coraenv to /usr/local/bin ...


Creating /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.
2010/11/29 17:45:30: Parsing the host name
2010/11/29 17:45:30: Checking for super user privileges
2010/11/29 17:45:30: User has super user privileges
Using configuration parameter file: /u01/app/11.2.0/grid/crs/install/crsconfig_params
Creating trace directory
LOCAL ADD MODE 
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
Adding daemon to inittab
CRS-4123: Oracle High Availability Services has been started.
ohasd is starting
CRS-4402: CSSデーモンが排他モードで開始されましたが、ノードdiscus164、番号1のアクティブCSSデーモンが検出されたため中断します
CRS-2673: 'ora.cssdmonitor'('discus264')の停止を試行しています
CRS-2677: 'ora.cssdmonitor'('discus264')の停止が成功しました
CRS-2673: 'ora.gpnpd'('discus264')の停止を試行しています
CRS-2677: 'ora.gpnpd'('discus264')の停止が成功しました
CRS-2673: 'ora.gipcd'('discus264')の停止を試行しています
CRS-2677: 'ora.gipcd'('discus264')の停止が成功しました
CRS-2673: 'ora.mdnsd'('discus264')の停止を試行しています
CRS-2677: 'ora.mdnsd'('discus264')の停止が成功しました
An active cluster was found during exclusive startup, restarting to join the cluster
CRS-2672: 'ora.mdnsd'('discus264')の起動を試行しています
CRS-2676: 'ora.mdnsd'('discus264')の起動が成功しました
CRS-2672: 'ora.gipcd'('discus264')の起動を試行しています
CRS-2676: 'ora.gipcd'('discus264')の起動が成功しました
CRS-2672: 'ora.gpnpd'('discus264')の起動を試行しています
CRS-2676: 'ora.gpnpd'('discus264')の起動が成功しました
CRS-2672: 'ora.cssdmonitor'('discus264')の起動を試行しています
CRS-2676: 'ora.cssdmonitor'('discus264')の起動が成功しました
CRS-2672: 'ora.cssd'('discus264')の起動を試行しています
CRS-2672: 'ora.diskmon'('discus264')の起動を試行しています
CRS-2676: 'ora.diskmon'('discus264')の起動が成功しました
CRS-2676: 'ora.cssd'('discus264')の起動が成功しました
CRS-2672: 'ora.ctssd'('discus264')の起動を試行しています
CRS-2676: 'ora.ctssd'('discus264')の起動が成功しました
CRS-2672: 'ora.drivers.acfs'('discus264')の起動を試行しています
CRS-2676: 'ora.drivers.acfs'('discus264')の起動が成功しました
CRS-2672: 'ora.asm'('discus264')の起動を試行しています
CRS-2676: 'ora.asm'('discus264')の起動が成功しました
CRS-2672: 'ora.crsd'('discus264')の起動を試行しています
CRS-2676: 'ora.crsd'('discus264')の起動が成功しました
CRS-2672: 'ora.evmd'('discus264')の起動を試行しています
CRS-2676: 'ora.evmd'('discus264')の起動が成功しました

discus264     2010/11/29 17:48:45     /u01/app/11.2.0/grid/cdata/discus264/backup_20101129_174845.olr
パッケージインストールの準備中...
cvuqdisk-1.0.7-1
Configure Oracle Grid Infrastructure for a Cluster ... succeeded
クラスタウェアのインベントリ・プロパティの更新中
Oracle Universal Installerを起動中です...

スワップ領域の確認中: 500MBを超えている必要があります.   実際 5951MB    問題なし
The inventory pointer is located at /etc/oraInst.loc
The inventory is located at /u01/app/oraInventory
'UpdateNodeList'が成功しました。
[root@discus264 grid]# 

root.sh実行おわり！

Grid Infrastructureインストール後の簡単な確認（RACを構成する全ノードのgrid infrastructureユーザ及び、rootユーザで実施）

crsの状態確認（RACを構成する全ノードのGrid Infrastructureユーザで

[grid@discus164 ˜]$ crsctl check crs
CRS-4638: Oracle高可用性サービスがオンラインです
CRS-4537: Cluster Ready Servicesがオンラインです
CRS-4529: Cluster Synchronization Servicesがオンラインです
CRS-4533: イベント・マネージャがオンラインです
[grid@discus164 ˜]$ 

[grid@discus264 ˜]$ crsctl check crs
CRS-4638: Oracle高可用性サービスがオンラインです
CRS-4537: Cluster Ready Servicesがオンラインです
CRS-4529: Cluster Synchronization Servicesがオンラインです
CRS-4533: イベント・マネージャがオンラインです
[grid@discus264 ˜]$ 

clusterノードの確認（RACを構成する全ノードのGrid Infrastructureユーザで）

[grid@discus164 ˜]$ olsnodes -n
discus164       1
discus264       2
[grid@discus164 ˜]$ 

[grid@discus264 ˜]$ olsnodes -n
discus164       1
discus264       2
[grid@discus264 ˜]$ 

リスナーの確認（RACを構成する全ノード

[grid@discus164 ˜]$ ps -ef | grep lsnr | grep -v 'grep' | grep -v 'ocfs' | awk '{print $9}'
LISTENER_SCAN2
LISTENER_SCAN3
LISTENER
[grid@discus164 ˜]$ 

[grid@discus264 ˜]$ ps -ef | grep lsnr | grep -v 'grep' | grep -v 'ocfs' | awk '{print $9}'
LISTENER_SCAN1
LISTENER
[grid@discus264 ˜]$ 

以下、OUIを実行したノードから確認しとけばOKかな
ASMは起動してるかな〜（Grid Infrastructureユーザで

[grid@discus164 ˜]$ srvctl status asm -a
ASMはdiscus164,discus264で実行中です
ASMは有効です。
[grid@discus164 ˜]$ 

rootユーザでcrsctlコマンド実行してますが、Grid Infrastructureホームのbinにパス通しているだけです :) 楽なので。
Oracle Cluster Registry (OCR)　- rootユーザで実施

[root@discus164 grid]# ocrcheck
Status of Oracle Cluster Registry is as follows :
         Version                  :          3
         Total space (kbytes)     :     262120
         Used space (kbytes)      :       2364
         Available space (kbytes) :     259756
         ID                       : 1391852321
         Device/File Name         :       +CRS
                                    Device/File integrity check succeeded

                                    Device/File not configured

                                    Device/File not configured

                                    Device/File not configured

                                    Device/File not configured

         Cluster registry integrity check succeeded

         Logical corruption check succeeded

[root@discus164 grid]# 

Voting Diskの確認（Grid Infrastructureユーザで

[grid@discus164 ˜]$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   5d6c953bf3aa4fe6bfff2a0f9b1e0d37 (ORCL:CRSVOL1) [CRS]
1の投票ディスクを検出しました。
[grid@discus164 ˜]$ 

[grid@discus164 ~]$ crsctl status resource -w 'TYPE co ora' -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.CRS.dg
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.LISTENER.lsnr
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.asm
               ONLINE  ONLINE       discus164                Started             
               ONLINE  ONLINE       discus264                Started             
ora.eons
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.gsd
               OFFLINE OFFLINE      discus164                                    
               OFFLINE OFFLINE      discus264                                    
ora.net1.network
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.ons
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
ora.registry.acfs
               ONLINE  ONLINE       discus164                                    
               ONLINE  ONLINE       discus264                                    
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       discus264                                    
ora.LISTENER_SCAN2.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.LISTENER_SCAN3.lsnr
      1        ONLINE  ONLINE       discus164                                    
ora.discus164.vip
      1        ONLINE  ONLINE       discus164                                    
ora.discus264.vip
      1        ONLINE  ONLINE       discus264                                    
ora.oc4j
      1        OFFLINE OFFLINE                                                   
ora.scan1.vip
      1        ONLINE  ONLINE       discus264                                    
ora.scan2.vip
      1        ONLINE  ONLINE       discus164                                    
ora.scan3.vip
      1        ONLINE  ONLINE       discus164                                    
[grid@discus164 ~]$ 

root.shのバックアップが推奨されているので、これはやっといた。

Back Up the root.sh Script

Oracle recommends that you back up the root.sh script after you
complete an installation. If you install other products
in the same Oracle home directory, then the installer updates
the contents of the existing root.sh script during the installation.
If you require information contained in the original root.sh script,
then you can recover it from the root.sh file copy.

Back up the root.sh file on both Oracle RAC nodes as root:

[grid@discus164 ˜]$ su -
パスワード:
[root@discus164 ˜]# cd /u01/app/11.2.0/grid
[root@discus164 grid]# ls -l root.sh
-rwxr-x--- 1 grid oinstall 723 11月 29 14:10 root.sh
[root@discus164 grid]# cp -p root.sh root.sh.discus164_after_install20101129
[root@discus164 grid]# 

[grid@discus264 ˜]$ su - 
パスワード:
[root@discus264 ˜]# cd /u01/app/11.2.0
[root@discus264 11.2.0]# cd grid
[root@discus264 grid]# ls -l root.sh
-rwxr-x--- 1 grid oinstall 723 11月 29 14:12 root.sh
[root@discus264 grid]# cp -p root.sh root.sh.discus264_after_install20101129
[root@discus264 grid]# 

Install Cluster Health Management Software が推奨されてるけど。別途時間があったらやる→TODO

次回へつづく。

---

これまでのあらすじ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

・VirtualBox de RAC (Oracle11g R1編） #1
・VirtualBox de RAC (Oracle11g R1編） #2

---

・VirtualBox de Oracle11g R2 RAC #1
・VirtualBox de Oracle11g R2 RAC #2 - 事前調査など…
・VirtualBox de Oracle11g R2 RAC #3
・VirtualBox de Oracle11g R2 RAC #4
・VirtualBox de Oracle11g R2 RAC #5
・VirtualBox de Oracle11g R2 RAC #6
・VirtualBox de Oracle11g R2 RAC #7
・VirtualBox de Oracle11g R2 RAC #8
・VirtualBox de Oracle11g R2 RAC #9
・VirtualBox de Oracle11g R2 RAC #10
・VirtualBox de Oracle11g R2 RAC #11
・VirtualBox de Oracle11g R2 RAC #12
・VirtualBox de Oracle11g R2 RAC #13
・VirtualBox de Oracle11g R2 RAC #14
・VirtualBox de Oracle11g R2 RAC #15

VirtualBox de Oracle11g R2 RAC #15

VirtualBox de Oracle11g R2 RACのつづきです。

今回はOracle11g R2 11.2.0.1.0 RACインストール事前作業。

1. ハードウェア構成(VMなのでVMの構成も含めて）、ソフトウェア構成など
2. Linux (CentOS 5.5 x86_64)のインストール
3. Openfiler2.3 x86のインストール
4. Openfiler2.3 x86によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２、その３
6. Oracle所有者、Oracle Grid Infrastructureユーザの作成と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. Oracle RACノード間リモートアクセスの構成とntpの構成
   （sshの構成は念のために行った、多分、実施しなくても大丈夫だと思うけど…ついでなので、ちょいと意地悪な実験をしてみた）
9. ローカルネームサーバの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Automatic Storage Management(ASMLib 2.0.5 x84_64)のインストール及び構成
12. Oracle11g R2 11.2.0.1.0 RACインストール事前作業
13. Oracle11g R2 11.2.0.1.0 Grid Infrastractureのインストール
14. Oracle11g R2 11.2.0.1.0 Database softwareのインストール
15. Oracle11g R2 11.2.0.1.0 examplesのインストール
16. Oracle Cluster databaseの作成
17. Net Serviceの確認
18. Oralce Grid InsfastructureとDatabase構成の確認
19. Clusterの開始と停止の確認
20. 簡単なTransparent Application Failover (TAF)の確認

Oracle11g R2 11.2.0.1.0 RACインストール事前作業

以下、Linux 64bit版をダウンロード
Oracle11g R2 11.2.0.1.0 for Linux (64bit）
linux.x64_11gR2_database_1of2.zip
linux.x64_11gR2_database_2of2.zip

Oracle11g R2 Grid Infrastructure for Linux (64bit)
linux.x64_11gR2_grid.zip

Oracle11g R2 Examples for Linux (64bit)
linux.x64_11gR2_examples.zip

ダウンロードした、Oracle Grid Infrastructureをgrid infrastructureユーザで解凍

[grid@discus164 oracle]$ ll
合計 1029240
-rw-r--r-- 1 grid oinstall 1052897657 11月 25 10:51 linux.x64_11gR2_grid.zip
[grid@discus164 oracle]$ unzip linux.x64_11gR2_grid.zip

・・・中略・・・

 extracting: grid/install/addLangs.sh  
  inflating: grid/runInstaller       
  inflating: grid/welcome.html       
  inflating: grid/runcluvfy.sh       
[grid@discus164 oracle]$ 

ダウンロードしたOracle11g R2 11.2.0.1.0とexamplesをOracle所有者で解凍

[oracle@discus164 oracle]$ ll
合計 2840744
-rw-r--r-- 1 oracle oinstall 1239269270 11月 25 10:56 linux.x64_11gR2_database_1of2.zip
-rw-r--r-- 1 oracle oinstall 1111416131 11月 25 10:57 linux.x64_11gR2_database_2of2.zip
-rw-r--r-- 1 oracle oinstall  555366950 11月 25 10:57 linux.x64_11gR2_examples.zip
[oracle@discus164 oracle]$ unzip linux.x64_11gR2_database_1of2.zip

・・・中略・・・

 extracting: database/install/addLangs.sh  
  inflating: database/runInstaller   
  inflating: database/welcome.html   
[oracle@discus164 oracle]$ 
[oracle@discus164 oracle]$ unzip linux.x64_11gR2_database_2of2.zip

・・・中略・・・

  inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.1.0/1/DataFiles/filegroup13.jar  
  inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.1.0/1/DataFiles/filegroup8.jar  
  inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.1.0/1/DataFiles/filegroup9.jar  
[oracle@discus164 oracle]$ 
[oracle@discus164 oracle]$ unzip linux.x64_11gR2_examples.zip

・・・中略・・・

 extracting: examples/install/addLangs.sh  
  inflating: examples/runInstaller   
  inflating: examples/welcome.html   
[oracle@discus164 oracle]$ 

cvudiskパッケージのインストール（RACを構成する全ノードのrootユーザで）

[grid@discus164 ˜]$ cd ./software/oracle/grid/rpm
[grid@discus164 rpm]$ su
パスワード:
[root@discus164 rpm]# ll
合計 12
-rw-rw-r-- 1 grid oinstall 8173  7月 15  2009 cvuqdisk-1.0.7-1.rpm
[root@discus164 rpm]# CVUQDISK_GRP=oinstall; export CVUQDISK_GRP
[root@discus164 rpm]# rpm -iv cvuqdisk-1.0.7-1.rpm
パッケージインストールの準備中...
cvuqdisk-1.0.7-1
[root@discus164 rpm]#
 

CVUによる事前チェック（RACを構成する全ノードのOracle Grid Infrastructureユーザで実施）
-fixupオプションを付加すると修正用スクリプトが作成されますが、下記例では付加していません。（修正スクリプトを作成させた方が楽ですけどね。)

今回は全ログを省略なしで！w

[grid@discus164 grid]$ pwd
/home/grid/software/oracle/grid
[grid@discus164 grid]$ ll
合計 76
drwxr-xr-x  9 grid oinstall 4096  8月 17  2009 doc
drwxr-xr-x  4 grid oinstall 4096 12月  3 11:05 install
drwxrwxr-x  2 grid oinstall 4096  8月 15  2009 response
drwxrwxr-x  2 grid oinstall 4096  8月 15  2009 rpm
-rwxr-xr-x  1 grid oinstall 3227  8月 15  2009 runInstaller
-rwxrwxr-x  1 grid oinstall 3795  1月 29  2009 runcluvfy.sh
drwxrwxr-x  2 grid oinstall 4096  8月 15  2009 sshsetup
drwxr-xr-x 14 grid oinstall 4096  8月 15  2009 stage
-rw-r--r--  1 grid oinstall 4228  8月 18  2009 welcome.html
[grid@discus164 grid]$
[grid@discus164 grid]$
[grid@discus164 grid]$ ./runcluvfy.sh stage -pre crsinst -n discus164,discus264 -verbose

クラスタ・サービス設定の事前チェックを実行しています 

ノード到達可能性をチェック中...

チェック: ノード"discus164"からのノード到達可能性
  宛先ノード                                 到達可能ですか                 
  ------------------------------------  ------------------------
  discus264                             はい                      
  discus164                             はい                      
結果: ノード"discus164"からのノード到達可能性チェックに合格しました


ユーザー等価をチェック中...

チェック: ユーザー"grid"のユーザー等価
  ノード名                                  コメント                    
  ------------------------------------  ------------------------
  discus264                             合格                      
  discus164                             合格                      
結果: ユーザー"grid"のユーザー等価チェックに合格しました

ノード接続性をチェック中...

ホスト構成ファイルをチェック中...
  ノード名          ステータス                     コメント                    
  ------------  ------------------------  ------------------------
  discus264     合格                                                
  discus164     合格                                                

ホスト構成ファイルの検証に成功しました


ノード"discus264"のインタフェース情報
 名前     IPアドレス          サブネット           ゲートウェイ          デフォルト・ゲートウェイ    HWアドレス            MTU   
 ------ --------------- --------------- --------------- --------------- ----------------- ------
 eth0   192.168.1.91    192.168.1.0     0.0.0.0         192.168.1.1     08:00:27:CC:3B:97 1500  
 eth1   192.168.3.91    192.168.3.0     0.0.0.0         192.168.1.1     08:00:27:2F:97:0D 1500  
 eth2   192.168.2.91    192.168.2.0     0.0.0.0         192.168.1.1     08:00:27:AD:F8:40 1500  


ノード"discus164"のインタフェース情報
 名前     IPアドレス          サブネット           ゲートウェイ          デフォルト・ゲートウェイ    HWアドレス            MTU   
 ------ --------------- --------------- --------------- --------------- ----------------- ------
 eth0   192.168.1.90    192.168.1.0     0.0.0.0         192.168.1.1     08:00:27:B1:38:96 1500  
 eth1   192.168.3.90    192.168.3.0     0.0.0.0         192.168.1.1     08:00:27:FC:A5:8E 1500  
 eth2   192.168.2.90    192.168.2.0     0.0.0.0         192.168.1.1     08:00:27:47:E9:2C 1500  


チェック: サブネット"192.168.1.0"のノード接続性
  ソース                             宛先                              接続しましたか         
  ------------------------------  ------------------------------  ----------------
  discus264:eth0                  discus164:eth0                  はい              
結果: ノードdiscus264,discus164を持つサブネット"192.168.1.0"のノード接続性に合格しました


チェック: サブネット"192.168.1.0"のTCP接続性
  ソース                             宛先                              接続しましたか         
  ------------------------------  ------------------------------  ----------------
  discus164:192.168.1.90          discus264:192.168.1.91          合格              
結果: サブネット"192.168.1.0"のTCP接続性チェックに合格しました


チェック: サブネット"192.168.3.0"のノード接続性
  ソース                             宛先                              接続しましたか         
  ------------------------------  ------------------------------  ----------------
  discus264:eth1                  discus164:eth1                  はい              
結果: ノードdiscus264,discus164を持つサブネット"192.168.3.0"のノード接続性に合格しました


チェック: サブネット"192.168.3.0"のTCP接続性
  ソース                             宛先                              接続しましたか         
  ------------------------------  ------------------------------  ----------------
  discus164:192.168.3.90          discus264:192.168.3.91          合格              
結果: サブネット"192.168.3.0"のTCP接続性チェックに合格しました


チェック: サブネット"192.168.2.0"のノード接続性
  ソース                             宛先                              接続しましたか         
  ------------------------------  ------------------------------  ----------------
  discus264:eth2                  discus164:eth2                  はい              
結果: ノードdiscus264,discus164を持つサブネット"192.168.2.0"のノード接続性に合格しました


チェック: サブネット"192.168.2.0"のTCP接続性
  ソース                             宛先                              接続しましたか         
  ------------------------------  ------------------------------  ----------------
  discus164:192.168.2.90          discus264:192.168.2.91          合格              
結果: サブネット"192.168.2.0"のTCP接続性チェックに合格しました


VIPの候補となるサブネット"192.168.1.0"で見つかったインタフェースは次のとおりです:
discus264 eth0:192.168.1.91
discus164 eth0:192.168.1.90

プライベート・インターコネクトの候補となるサブネット"192.168.3.0"で見つかったインタフェースは次のとおりです:
discus264 eth1:192.168.3.91
discus164 eth1:192.168.3.90

プライベート・インターコネクトの候補となるサブネット"192.168.2.0"で見つかったインタフェースは次のとおりです:
discus264 eth2:192.168.2.91
discus164 eth2:192.168.2.90

結果: ノード接続性チェックに合格しました


チェック: メモリー合計 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     3.86GB (4051640.0KB)      1.5GB (1572864.0KB)       合格        
  discus164     3.86GB (4051640.0KB)      1.5GB (1572864.0KB)       合格        
結果: メモリー合計チェックに合格しました

チェック: 使用可能なメモリー 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     3.5GB (3673300.0KB)       50MB (51200.0KB)          合格        
  discus164     3.34GB (3498792.0KB)      50MB (51200.0KB)          合格        
結果: 使用可能なメモリーチェックに合格しました

チェック: スワップ領域 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     5.81GB (6094840.0KB)      3.86GB (4051640.0KB)      合格        
  discus164     5.81GB (6094840.0KB)      3.86GB (4051640.0KB)      合格        
結果: スワップ領域チェックに合格しました

チェック: "discus264:/tmp"のディスク空き領域 
  パス                ノード名          マウント・ポイント     使用可能          必須            コメント        
  ----------------  ------------  ------------  ------------  ------------  ------------
  /tmp              discus264     /             37.78GB       1GB           合格          
結果: "discus264:/tmp"のディスク空き領域チェックに合格しました

チェック: "discus164:/tmp"のディスク空き領域 
  パス                ノード名          マウント・ポイント     使用可能          必須            コメント        
  ----------------  ------------  ------------  ------------  ------------  ------------
  /tmp              discus164     /             33.62GB       1GB           合格          
結果: "discus164:/tmp"のディスク空き領域チェックに合格しました

チェック: "grid"の既存ユーザー 
  ノード名          ステータス                     コメント                    
  ------------  ------------------------  ------------------------
  discus264     存在します                     合格                      
  discus164     存在します                     合格                      
結果: "grid"の既存ユーザーチェックに合格しました

チェック: "oinstall"のグループの存在 
  ノード名          ステータス                     コメント                    
  ------------  ------------------------  ------------------------
  discus264     存在します                     合格                      
  discus164     存在します                     合格                      
結果: "oinstall"のグループの存在チェックに合格しました

チェック: "dba"のグループの存在 
  ノード名          ステータス                     コメント                    
  ------------  ------------------------  ------------------------
  discus264     存在します                     合格                      
  discus164     存在します                     合格                      
結果: "dba"のグループの存在チェックに合格しました

チェック: グループ"oinstall"内のユーザー"grid"[プライマリ]のメンバーシップ
  ノード名              ユーザーが存在します    グループが存在します    グループ内のユーザー    プライマリ         コメント        
  ----------------  ------------  ------------  ------------  ------------  ------------
  discus264         はい            はい            はい            はい            合格          
  discus164         はい            はい            はい            はい            合格          
結果: グループ"oinstall"内のユーザー"grid"[プライマリ]のメンバーシップ・チェックに合格しました

チェック: グループ"dba"内のユーザー"grid"のメンバーシップ
  ノード名              ユーザーが存在します    グループが存在します    グループ内のユーザー    コメント            
  ----------------  ------------  ------------  ------------  ----------------
  discus264         はい            はい            いいえ           失敗              
  discus164         はい            はい            いいえ           失敗              
結果: グループ"dba"内のユーザー"grid"のメンバーシップ・チェックが失敗しました

チェック: 実行レベル 
  ノード名          実行レベル                     必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     5                         3,5                       合格        
  discus164     5                         3,5                       合格        
結果: 実行レベルチェックに合格しました

チェック: "最大オープン・ファイル記述子数"の強い制限 
  ノード名              タイプ           使用可能          必須            コメント            
  ----------------  ------------  ------------  ------------  ----------------
  discus264         強い            65536         65536         合格              
  discus164         強い            65536         65536         合格              
結果: "最大オープン・ファイル記述子数"の強い制限チェックに合格しました

チェック: "最大オープン・ファイル記述子数"の弱い制限 
  ノード名              タイプ           使用可能          必須            コメント            
  ----------------  ------------  ------------  ------------  ----------------
  discus264         弱い            1024          1024          合格              
  discus164         弱い            1024          1024          合格              
結果: "最大オープン・ファイル記述子数"の弱い制限チェックに合格しました

チェック: "最大ユーザー・プロセス"の強い制限 
  ノード名              タイプ           使用可能          必須            コメント            
  ----------------  ------------  ------------  ------------  ----------------
  discus264         強い            16384         16384         合格              
  discus164         強い            16384         16384         合格              
結果: "最大ユーザー・プロセス"の強い制限チェックに合格しました

チェック: "最大ユーザー・プロセス"の弱い制限 
  ノード名              タイプ           使用可能          必須            コメント            
  ----------------  ------------  ------------  ------------  ----------------
  discus264         弱い            2047          2047          合格              
  discus164         弱い            2047          2047          合格              
結果: "最大ユーザー・プロセス"の弱い制限チェックに合格しました

チェック: システム・アーキテクチャ 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     x86_64                    x86_64                    合格        
  discus164     x86_64                    x86_64                    合格        
結果: システム・アーキテクチャチェックに合格しました

チェック: カーネル・バージョン 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     2.6.18-194.17.1.el5       2.6.9                     合格        
  discus164     2.6.18-194.17.1.el5       2.6.9                     合格        
結果: カーネル・バージョンチェックに合格しました

チェック: "semmsl"のカーネル・パラメータ 
  ノード名          構成済                       必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     250                       250                       合格        
  discus164     250                       250                       合格        
結果: "semmsl"のカーネル・パラメータチェックに合格しました

チェック: "semmns"のカーネル・パラメータ 
  ノード名          構成済                       必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     32000                     32000                     合格        
  discus164     32000                     32000                     合格        
結果: "semmns"のカーネル・パラメータチェックに合格しました

チェック: "semopm"のカーネル・パラメータ 
  ノード名          構成済                       必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     100                       100                       合格        
  discus164     100                       100                       合格        
結果: "semopm"のカーネル・パラメータチェックに合格しました

チェック: "semmni"のカーネル・パラメータ 
  ノード名          構成済                       必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     128                       128                       合格        
  discus164     128                       128                       合格        
結果: "semmni"のカーネル・パラメータチェックに合格しました

チェック: "shmmax"のカーネル・パラメータ 
  ノード名          構成済                       必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     68719476736               536870912                 合格        
  discus164     68719476736               536870912                 合格        
結果: "shmmax"のカーネル・パラメータチェックに合格しました

チェック: "shmmni"のカーネル・パラメータ 
  ノード名          構成済                       必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     4096                      4096                      合格        
  discus164     4096                      4096                      合格        
結果: "shmmni"のカーネル・パラメータチェックに合格しました

チェック: "shmall"のカーネル・パラメータ 
  ノード名          構成済                       必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     4294967296                2097152                   合格        
  discus164     4294967296                2097152                   合格        
結果: "shmall"のカーネル・パラメータチェックに合格しました

チェック: "file-max"のカーネル・パラメータ 
  ノード名          構成済                       必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     6815744                   6815744                   合格        
  discus164     6815744                   6815744                   合格        
結果: "file-max"のカーネル・パラメータチェックに合格しました

チェック: "ip_local_port_range"のカーネル・パラメータ 
  ノード名          構成済                       必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     between 9000 & 65500      between 9000 & 65500      合格        
  discus164     between 9000 & 65500      between 9000 & 65500      合格        
結果: "ip_local_port_range"のカーネル・パラメータチェックに合格しました

チェック: "rmem_default"のカーネル・パラメータ 
  ノード名          構成済                       必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     262144                    262144                    合格        
  discus164     262144                    262144                    合格        
結果: "rmem_default"のカーネル・パラメータチェックに合格しました

チェック: "rmem_max"のカーネル・パラメータ 
  ノード名          構成済                       必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     4194304                   4194304                   合格        
  discus164     4194304                   4194304                   合格        
結果: "rmem_max"のカーネル・パラメータチェックに合格しました

チェック: "wmem_default"のカーネル・パラメータ 
  ノード名          構成済                       必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     262144                    262144                    合格        
  discus164     262144                    262144                    合格        
結果: "wmem_default"のカーネル・パラメータチェックに合格しました

チェック: "wmem_max"のカーネル・パラメータ 
  ノード名          構成済                       必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     1048576                   1048576                   合格        
  discus164     1048576                   1048576                   合格        
結果: "wmem_max"のカーネル・パラメータチェックに合格しました

チェック: "aio-max-nr"のカーネル・パラメータ 
  ノード名          構成済                       必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     1048576                   1048576                   合格        
  discus164     1048576                   1048576                   合格        
結果: "aio-max-nr"のカーネル・パラメータチェックに合格しました

チェック: "make-3.80"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     make-3.81-3.el5           make-3.80                 合格        
  discus164     make-3.81-3.el5           make-3.80                 合格        
結果: "make-3.80"のパッケージの存在チェックに合格しました

チェック: "binutils-2.15.92.0.2"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     binutils-2.17.50.0.6-14.el5  binutils-2.15.92.0.2      合格        
  discus164     binutils-2.17.50.0.6-14.el5  binutils-2.15.92.0.2      合格        
結果: "binutils-2.15.92.0.2"のパッケージの存在チェックに合格しました

チェック: "gcc-3.4.6"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     gcc-4.1.2-48.el5          gcc-3.4.6                 合格        
  discus164     gcc-4.1.2-48.el5          gcc-3.4.6                 合格        
結果: "gcc-3.4.6"のパッケージの存在チェックに合格しました

チェック: "libaio-0.3.105 (i386)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     libaio-0.3.106-5 (i386)   libaio-0.3.105 (i386)     合格        
  discus164     libaio-0.3.106-5 (i386)   libaio-0.3.105 (i386)     合格        
結果: "libaio-0.3.105 (i386)"のパッケージの存在チェックに合格しました

チェック: "libaio-0.3.105 (x86_64)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     libaio-0.3.106-5 (x86_64)  libaio-0.3.105 (x86_64)   合格        
  discus164     libaio-0.3.106-5 (x86_64)  libaio-0.3.105 (x86_64)   合格        
結果: "libaio-0.3.105 (x86_64)"のパッケージの存在チェックに合格しました

チェック: "glibc-2.3.4-2.41 (i686)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     glibc-2.5-49.el5_5.6 (i686)  glibc-2.3.4-2.41 (i686)   合格        
  discus164     glibc-2.5-49.el5_5.6 (i686)  glibc-2.3.4-2.41 (i686)   合格        
結果: "glibc-2.3.4-2.41 (i686)"のパッケージの存在チェックに合格しました

チェック: "glibc-2.3.4-2.41 (x86_64)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     glibc-2.5-49.el5_5.6 (x86_64)  glibc-2.3.4-2.41 (x86_64)  合格        
  discus164     glibc-2.5-49.el5_5.6 (x86_64)  glibc-2.3.4-2.41 (x86_64)  合格        
結果: "glibc-2.3.4-2.41 (x86_64)"のパッケージの存在チェックに合格しました

チェック: "compat-libstdc++-33-3.2.3 (i386)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     compat-libstdc++-33-3.2.3-61 (i386)  compat-libstdc++-33-3.2.3 (i386)  合格        
  discus164     compat-libstdc++-33-3.2.3-61 (i386)  compat-libstdc++-33-3.2.3 (i386)  合格        
結果: "compat-libstdc++-33-3.2.3 (i386)"のパッケージの存在チェックに合格しました

チェック: "compat-libstdc++-33-3.2.3 (x86_64)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     compat-libstdc++-33-3.2.3-61 (x86_64)  compat-libstdc++-33-3.2.3 (x86_64)  合格        
  discus164     compat-libstdc++-33-3.2.3-61 (x86_64)  compat-libstdc++-33-3.2.3 (x86_64)  合格        
結果: "compat-libstdc++-33-3.2.3 (x86_64)"のパッケージの存在チェックに合格しました

チェック: "elfutils-libelf-0.97 (x86_64)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     elfutils-libelf-0.137-3.el5 (x86_64)  elfutils-libelf-0.97 (x86_64)  合格        
  discus164     elfutils-libelf-0.137-3.el5 (x86_64)  elfutils-libelf-0.97 (x86_64)  合格        
結果: "elfutils-libelf-0.97 (x86_64)"のパッケージの存在チェックに合格しました

チェック: "elfutils-libelf-devel-0.97"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     elfutils-libelf-devel-0.137-3.el5  elfutils-libelf-devel-0.97  合格        
  discus164     elfutils-libelf-devel-0.137-3.el5  elfutils-libelf-devel-0.97  合格        
結果: "elfutils-libelf-devel-0.97"のパッケージの存在チェックに合格しました

チェック: "glibc-common-2.3.4"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     glibc-common-2.5-49.el5_5.6  glibc-common-2.3.4        合格        
  discus164     glibc-common-2.5-49.el5_5.6  glibc-common-2.3.4        合格        
結果: "glibc-common-2.3.4"のパッケージの存在チェックに合格しました

チェック: "glibc-devel-2.3.4 (x86_64)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     glibc-devel-2.5-49.el5_5.6 (x86_64)  glibc-devel-2.3.4 (x86_64)  合格        
  discus164     glibc-devel-2.5-49.el5_5.6 (x86_64)  glibc-devel-2.3.4 (x86_64)  合格        
結果: "glibc-devel-2.3.4 (x86_64)"のパッケージの存在チェックに合格しました

チェック: "glibc-headers-2.3.4"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     glibc-headers-2.5-49.el5_5.6  glibc-headers-2.3.4       合格        
  discus164     glibc-headers-2.5-49.el5_5.6  glibc-headers-2.3.4       合格        
結果: "glibc-headers-2.3.4"のパッケージの存在チェックに合格しました

チェック: "gcc-c++-3.4.6"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     gcc-c++-4.1.2-48.el5      gcc-c++-3.4.6             合格        
  discus164     gcc-c++-4.1.2-48.el5      gcc-c++-3.4.6             合格        
結果: "gcc-c++-3.4.6"のパッケージの存在チェックに合格しました

チェック: "libaio-devel-0.3.105 (i386)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     libaio-devel-0.3.106-5 (i386)  libaio-devel-0.3.105 (i386)  合格        
  discus164     libaio-devel-0.3.106-5 (i386)  libaio-devel-0.3.105 (i386)  合格        
結果: "libaio-devel-0.3.105 (i386)"のパッケージの存在チェックに合格しました

チェック: "libaio-devel-0.3.105 (x86_64)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     libaio-devel-0.3.106-5 (x86_64)  libaio-devel-0.3.105 (x86_64)  合格        
  discus164     libaio-devel-0.3.106-5 (x86_64)  libaio-devel-0.3.105 (x86_64)  合格        
結果: "libaio-devel-0.3.105 (x86_64)"のパッケージの存在チェックに合格しました

チェック: "libgcc-3.4.6 (i386)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     libgcc-4.1.2-48.el5 (i386)  libgcc-3.4.6 (i386)       合格        
  discus164     libgcc-4.1.2-48.el5 (i386)  libgcc-3.4.6 (i386)       合格        
結果: "libgcc-3.4.6 (i386)"のパッケージの存在チェックに合格しました

チェック: "libgcc-3.4.6 (x86_64)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     libgcc-4.1.2-48.el5 (x86_64)  libgcc-3.4.6 (x86_64)     合格        
  discus164     libgcc-4.1.2-48.el5 (x86_64)  libgcc-3.4.6 (x86_64)     合格        
結果: "libgcc-3.4.6 (x86_64)"のパッケージの存在チェックに合格しました

チェック: "libstdc++-3.4.6 (i386)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     libstdc++-4.1.2-48.el5 (i386)  libstdc++-3.4.6 (i386)    合格        
  discus164     libstdc++-4.1.2-48.el5 (i386)  libstdc++-3.4.6 (i386)    合格        
結果: "libstdc++-3.4.6 (i386)"のパッケージの存在チェックに合格しました

チェック: "libstdc++-3.4.6 (x86_64)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     libstdc++-4.1.2-48.el5 (x86_64)  libstdc++-3.4.6 (x86_64)  合格        
  discus164     libstdc++-4.1.2-48.el5 (x86_64)  libstdc++-3.4.6 (x86_64)  合格        
結果: "libstdc++-3.4.6 (x86_64)"のパッケージの存在チェックに合格しました

チェック: "libstdc++-devel-3.4.6 (x86_64)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     libstdc++-devel-4.1.2-48.el5 (x86_64)  libstdc++-devel-3.4.6 (x86_64)  合格        
  discus164     libstdc++-devel-4.1.2-48.el5 (x86_64)  libstdc++-devel-3.4.6 (x86_64)  合格        
結果: "libstdc++-devel-3.4.6 (x86_64)"のパッケージの存在チェックに合格しました

チェック: "sysstat-5.0.5"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     sysstat-7.0.2-3.el5_5.1   sysstat-5.0.5             合格        
  discus164     sysstat-7.0.2-3.el5_5.1   sysstat-5.0.5             合格        
結果: "sysstat-5.0.5"のパッケージの存在チェックに合格しました

チェック: "unixODBC-2.2.11 (i386)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     unixODBC-2.2.11-7.1 (i386)  unixODBC-2.2.11 (i386)    合格        
  discus164     unixODBC-2.2.11-7.1 (i386)  unixODBC-2.2.11 (i386)    合格        
結果: "unixODBC-2.2.11 (i386)"のパッケージの存在チェックに合格しました

チェック: "unixODBC-2.2.11 (x86_64)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     unixODBC-2.2.11-7.1 (x86_64)  unixODBC-2.2.11 (x86_64)  合格        
  discus164     unixODBC-2.2.11-7.1 (x86_64)  unixODBC-2.2.11 (x86_64)  合格        
結果: "unixODBC-2.2.11 (x86_64)"のパッケージの存在チェックに合格しました

チェック: "unixODBC-devel-2.2.11 (i386)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     unixODBC-devel-2.2.11-7.1 (i386)  unixODBC-devel-2.2.11 (i386)  合格        
  discus164     unixODBC-devel-2.2.11-7.1 (i386)  unixODBC-devel-2.2.11 (i386)  合格        
結果: "unixODBC-devel-2.2.11 (i386)"のパッケージの存在チェックに合格しました

チェック: "unixODBC-devel-2.2.11 (x86_64)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     unixODBC-devel-2.2.11-7.1 (x86_64)  unixODBC-devel-2.2.11 (x86_64)  合格        
  discus164     unixODBC-devel-2.2.11-7.1 (x86_64)  unixODBC-devel-2.2.11 (x86_64)  合格        
結果: "unixODBC-devel-2.2.11 (x86_64)"のパッケージの存在チェックに合格しました

チェック: "pdksh-5.2.14"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     pdksh-5.2.14-36.el5       pdksh-5.2.14              合格        
  discus164     pdksh-5.2.14-36.el5       pdksh-5.2.14              合格        
結果: "pdksh-5.2.14"のパッケージの存在チェックに合格しました

チェック: "expat-1.95.7 (x86_64)"のパッケージの存在 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     expat-1.95.8-8.3.el5_5.3 (x86_64)  expat-1.95.7 (x86_64)     合格        
  discus164     expat-1.95.8-8.3.el5_5.3 (x86_64)  expat-1.95.7 (x86_64)     合格        
結果: "expat-1.95.7 (x86_64)"のパッケージの存在チェックに合格しました

UID値0を持つ複数のユーザーをチェック中
結果: UID値0を持つ複数のユーザーのチェックに合格しました

チェック: 現行のグループID 
結果: 現行のグループIDチェックに合格しました
コア・ファイル名パターンの一貫性をチェック中...
コア・ファイル名パターンの一貫性チェックに合格しました。

ユーザー"grid"が"root"グループにないことを確認中
  ノード名          ステータス                     コメント                    
  ------------  ------------------------  ------------------------
  discus264     存在しません                    合格                      
  discus164     存在しません                    合格                      
結果: ユーザー"grid"は"root"グループの一部ではありません。チェックに合格しました

デフォルトのユーザー・ファイル作成マスクのチェック
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus264     0022                      0022                      合格        
  discus164     0022                      0022                      合格        
結果: デフォルトのユーザー・ファイル作成マスクのチェックに合格しました

ネットワーク・タイム・プロトコル(NTP)を使用してクロック同期のチェックを開始中...

NTP構成ファイルのチェックが開始されました...
NTP構成ファイル"/etc/ntp.conf"はすべてのノードで使用できます
NTP構成ファイルのチェックに合格しました

デーモン活性をチェック中...

チェック: "ntpd"の活性
  ノード名                                  実行中ですか                  
  ------------------------------------  ------------------------
  discus264                             はい                      
  discus164                             はい                      
結果: "ntpd"の活性チェックに合格しました

NTPデーモンのコマンドラインのslewオプション"-x"をチェック中
チェック: NTPデーモン・コマンド・ライン
  ノード名                                  Slewオプションが設定されているか      
  ------------------------------------  ------------------------
  discus264                             はい                      
  discus164                             はい                      
結果: 
NTPデーモンのslewオプションのチェックに合格しました

ファイル"/etc/sysconfig/ntpd"内のNTPデーモンのブート時構成のslewオプション"-x"をチェック中

チェック: NTPデーモンのブート時構成
  ノード名                                  Slewオプションが設定されているか      
  ------------------------------------  ------------------------
  discus264                             はい                      
  discus164                             はい                      
結果: 
NTPデーモンのブート時構成のslewオプションのチェックに合格しました

NTP共通タイム・サーバーのチェックが開始されました...
NTPタイム・サーバー"210.173.160.86"は、NTPデーモンが実行されているすべてのノードで共通です
NTPタイム・サーバー"210.173.176.251"は、NTPデーモンが実行されているすべてのノードで共通です
PRVF-5408 : NTPタイム・サーバー"210.173.160.56"は、次のノード"discus264"でのみ共通です
共通NTPタイム・サーバーのチェックに合格しました

NTPタイム・サーバーからのクロック時間オフセットのチェックが開始されました...
ノード"[discus264, discus164]"をチェック中...
チェック: NTP タイム・サーバーからのクロック時間オフセット

タイム・サーバー: 210.173.160.86 
時間オフセット制限: 1000.0 ミリ秒
  ノード名          時間オフセット                   ステータス                   
  ------------  ------------------------  ------------------------
  discus264     -428.02                   合格                      
  discus164     0.164                     合格                      
タイム・サーバー"210.173.160.86"の時間オフセットは、ノード"[discus264, discus164]"の許容限界内です。

タイム・サーバー: 210.173.176.251 
時間オフセット制限: 1000.0 ミリ秒
  ノード名          時間オフセット                   ステータス                   
  ------------  ------------------------  ------------------------
  discus264     -427.36                   合格                      
  discus164     0.417                     合格                      
タイム・サーバー"210.173.176.251"の時間オフセットは、ノード"[discus264, discus164]"の許容限界内です。
クロック時間オフセットのチェックに合格しました

結果: ネットワーク・タイム・プロトコル(NTP)を使用したクロック同期のチェックに合格しました

クラスタ・サービス設定の事前チェックはすべてのノードで失敗しました。

「結果: グループ"dba"内のユーザー"grid"のメンバーシップ・チェックが失敗しました」という箇所は無視可能というかマニュアルにもGrid Infrastructureユーザをdbaグループに属させる必要があると記載されていないので無視でOK.

次に、H/WとOSの設定の事前チェック（RACを構成する全ノードのOracle Grid Infrastructureユーザで実施）

[grid@discus164 grid]$ pwd
/home/grid/software/oracle/grid
[grid@discus164 grid]$ ll
合計 76
drwxr-xr-x  9 grid oinstall 4096  8月 17  2009 doc
drwxr-xr-x  4 grid oinstall 4096 12月  3 11:05 install
drwxrwxr-x  2 grid oinstall 4096  8月 15  2009 response
drwxrwxr-x  2 grid oinstall 4096  8月 15  2009 rpm
-rwxr-xr-x  1 grid oinstall 3227  8月 15  2009 runInstaller
-rwxrwxr-x  1 grid oinstall 3795  1月 29  2009 runcluvfy.sh
drwxrwxr-x  2 grid oinstall 4096  8月 15  2009 sshsetup
drwxr-xr-x 14 grid oinstall 4096  8月 15  2009 stage
-rw-r--r--  1 grid oinstall 4228  8月 18  2009 welcome.html
[grid@discus164 grid]$
[grid@discus164 grid]$
[grid@discus164 grid]$ ./runcluvfy.sh stage -post hwos -n discus164,discus264 -verbose

ハードウェアとオペレーティング・システム設定の事後チェックを実行しています 

ノード到達可能性をチェック中...

チェック: ノード"discus164"からのノード到達可能性
  宛先ノード                                 到達可能ですか                 
  ------------------------------------  ------------------------
  discus264                             はい                      
  discus164                             はい                      
結果: ノード"discus164"からのノード到達可能性チェックに合格しました


ユーザー等価をチェック中...

チェック: ユーザー"grid"のユーザー等価
  ノード名                                  コメント                    
  ------------------------------------  ------------------------
  discus264                             合格                      
  discus164                             合格                      
結果: ユーザー"grid"のユーザー等価チェックに合格しました

ノード接続性をチェック中...

ホスト構成ファイルをチェック中...
  ノード名          ステータス                     コメント                    
  ------------  ------------------------  ------------------------
  discus264     合格                                                
  discus164     合格                                                

ホスト構成ファイルの検証に成功しました


ノード"discus264"のインタフェース情報
 名前     IPアドレス          サブネット           ゲートウェイ          デフォルト・ゲートウェイ    HWアドレス            MTU   
 ------ --------------- --------------- --------------- --------------- ----------------- ------
 eth0   192.168.1.91    192.168.1.0     0.0.0.0         192.168.1.1     08:00:27:CC:3B:97 1500  
 eth1   192.168.3.91    192.168.3.0     0.0.0.0         192.168.1.1     08:00:27:2F:97:0D 1500  
 eth2   192.168.2.91    192.168.2.0     0.0.0.0         192.168.1.1     08:00:27:AD:F8:40 1500  


ノード"discus164"のインタフェース情報
 名前     IPアドレス          サブネット           ゲートウェイ          デフォルト・ゲートウェイ    HWアドレス            MTU   
 ------ --------------- --------------- --------------- --------------- ----------------- ------
 eth0   192.168.1.90    192.168.1.0     0.0.0.0         192.168.1.1     08:00:27:B1:38:96 1500  
 eth1   192.168.3.90    192.168.3.0     0.0.0.0         192.168.1.1     08:00:27:FC:A5:8E 1500  
 eth2   192.168.2.90    192.168.2.0     0.0.0.0         192.168.1.1     08:00:27:47:E9:2C 1500  


チェック: サブネット"192.168.1.0"のノード接続性
  ソース                             宛先                              接続しましたか         
  ------------------------------  ------------------------------  ----------------
  discus264:eth0                  discus164:eth0                  はい              
結果: ノードdiscus264,discus164を持つサブネット"192.168.1.0"のノード接続性に合格しました


チェック: サブネット"192.168.1.0"のTCP接続性
  ソース                             宛先                              接続しましたか         
  ------------------------------  ------------------------------  ----------------
  discus164:192.168.1.90          discus264:192.168.1.91          合格              
結果: サブネット"192.168.1.0"のTCP接続性チェックに合格しました


チェック: サブネット"192.168.3.0"のノード接続性
  ソース                             宛先                              接続しましたか         
  ------------------------------  ------------------------------  ----------------
  discus264:eth1                  discus164:eth1                  はい              
結果: ノードdiscus264,discus164を持つサブネット"192.168.3.0"のノード接続性に合格しました


チェック: サブネット"192.168.3.0"のTCP接続性
  ソース                             宛先                              接続しましたか         
  ------------------------------  ------------------------------  ----------------
  discus164:192.168.3.90          discus264:192.168.3.91          合格              
結果: サブネット"192.168.3.0"のTCP接続性チェックに合格しました


チェック: サブネット"192.168.2.0"のノード接続性
  ソース                             宛先                              接続しましたか         
  ------------------------------  ------------------------------  ----------------
  discus264:eth2                  discus164:eth2                  はい              
結果: ノードdiscus264,discus164を持つサブネット"192.168.2.0"のノード接続性に合格しました


チェック: サブネット"192.168.2.0"のTCP接続性
  ソース                             宛先                              接続しましたか         
  ------------------------------  ------------------------------  ----------------
  discus164:192.168.2.90          discus264:192.168.2.91          合格              
結果: サブネット"192.168.2.0"のTCP接続性チェックに合格しました


VIPの候補となるサブネット"192.168.1.0"で見つかったインタフェースは次のとおりです:
discus264 eth0:192.168.1.91
discus164 eth0:192.168.1.90

プライベート・インターコネクトの候補となるサブネット"192.168.3.0"で見つかったインタフェースは次のとおりです:
discus264 eth1:192.168.3.91
discus164 eth1:192.168.3.90

プライベート・インターコネクトの候補となるサブネット"192.168.2.0"で見つかったインタフェースは次のとおりです:
discus264 eth2:192.168.2.91
discus164 eth2:192.168.2.90

結果: ノード接続性チェックに合格しました


UID値0を持つ複数のユーザーをチェック中
結果: UID値0を持つ複数のユーザーのチェックに合格しました

ハードウェアとオペレーティング・システム設定の事後チェックは成功しました。 

次回へつづく。

---

これまでのあらすじ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

・VirtualBox de RAC (Oracle11g R1編） #1
・VirtualBox de RAC (Oracle11g R1編） #2

---

・VirtualBox de Oracle11g R2 RAC #1
・VirtualBox de Oracle11g R2 RAC #2 - 事前調査など…
・VirtualBox de Oracle11g R2 RAC #3
・VirtualBox de Oracle11g R2 RAC #4
・VirtualBox de Oracle11g R2 RAC #5
・VirtualBox de Oracle11g R2 RAC #6
・VirtualBox de Oracle11g R2 RAC #7
・VirtualBox de Oracle11g R2 RAC #8
・VirtualBox de Oracle11g R2 RAC #9
・VirtualBox de Oracle11g R2 RAC #10
・VirtualBox de Oracle11g R2 RAC #11
・VirtualBox de Oracle11g R2 RAC #12
・VirtualBox de Oracle11g R2 RAC #13
・VirtualBox de Oracle11g R2 RAC #14

VirtualBox de Oracle11g R2 RAC #14

VirtualBox de Oracle11g R2 RACのつづきです。

今回は、ASMlibのインストール及び構成です。（やっと半分w)

1. ハードウェア構成(VMなのでVMの構成も含めて）、ソフトウェア構成など
2. Linux (CentOS 5.5 x86_64)のインストール
3. Openfiler2.3 x86のインストール
4. Openfiler2.3 x86によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２、その３
6. Oracle所有者、Oracle Grid Infrastructureユーザの作成と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. Oracle RACノード間リモートアクセスの構成とntpの構成
   （sshの構成は念のために行った、多分、実施しなくても大丈夫だと思うけど…ついでなので、ちょいと意地悪な実験をしてみた）
9. ローカルネームサーバの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Automatic Storage Management(ASMLib 2.0.5 x84_64)のインストール及び構成
12. Oracle11g R2 11.2.0.1.0 RACインストール事前作業
13. Oracle11g R2 11.2.0.1.0 Grid Infrastractureのインストール
14. Oracle11g R2 11.2.0.1.0 Database softwareのインストール
15. Oracle11g R2 11.2.0.1.0 examplesのインストール
16. Oracle Cluster databaseの作成
17. Net Serviceの確認
18. Oralce Grid InsfastructureとDatabase構成の確認
19. Clusterの開始と停止の確認
20. 簡単なTransparent Application Failover (TAF)の確認

Oracle Automatic Storage Management(ASMLib 2.0.5 x84_64)のインストール及び構成

[root@discus164 tmp]# uname -a
Linux discus164.macdeoracle.jp 2.6.18-194.17.1.el5 #1 SMP Wed Sep 29 12:50:31 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

CentOS5.5 2.6.18-194.17.1.el5 x86_64なので、以下のasmパッケージをRACを構成する全ノードでインストール、構成する。

oracleasm-support-2.1.3-1.el5.x86_64.rpm
oracleasmlib-2.0.4-1.el5.x86_64.rpm
oracleasm-2.6.18-194.17.1.el5-2.0.5-1.el5.x86_64.rpm

ダウンロード（RACを構成する全ノードのrootユーザで）CentOS5.5 x86_64ですが、ダウンロードするのはrhel5 amd64版でOK

[root@discus164 tmp]# wget http://oss.oracle.com/projects/oracleasm-support/dist/files/RPMS/rhel5/amd64/2.1.3/oracleasm-support-2.1.3-1.el5.x86_64.rpm
--2010-11-24 16:19:15--  http://oss.oracle.com/projects/oracleasm-support/dist/files/RPMS/rhel5/amd64/2.1.3/oracleasm-support-2.1.3-1.el5.x86_64.rpm
oss.oracle.com をDNSに問いあわせています... 141.146.12.120
oss.oracle.com|141.146.12.120|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 90444 (88K) [application/x-rpm]
`oracleasm-support-2.1.3-1.el5.x86_64.rpm' に保存中

100%[=================================================================================================>] 90,444       105K/s 時間 0.8s    

2010-11-24 16:19:17 (105 KB/s) - `oracleasm-support-2.1.3-1.el5.x86_64.rpm' へ保存完了 [90444/90444]

[root@discus164 tmp]# wget http://download.oracle.com/otn_software/asmlib/oracleasmlib-2.0.4-1.el5.x86_64.rpm
--2010-11-24 16:19:30--  http://download.oracle.com/otn_software/asmlib/oracleasmlib-2.0.4-1.el5.x86_64.rpm
download.oracle.com をDNSに問いあわせています... 203.77.186.253, 203.77.186.254
download.oracle.com|203.77.186.253|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 14176 (14K) [text/plain]
`oracleasmlib-2.0.4-1.el5.x86_64.rpm' に保存中

100%[=================================================================================================>] 14,176      --.-K/s 時間 0.01s   

2010-11-24 16:19:30 (1.33 MB/s) - `oracleasmlib-2.0.4-1.el5.x86_64.rpm' へ保存完了 [14176/14176]

[root@discus164 tmp]# wget
http://oss.oracle.com/projects/oracleasm/dist/files/RPMS/rhel5/amd64/2.0.5/2.6.18-194.17.1.el5/oracleasm-2.6.18-194.17.1.el5-2.0.5-1.el5.x86_64.rpm
--2010-11-24 16:19:44-- http://oss.oracle.com/projects/oracleasm/dist/files/RPMS/rhel5/amd64/2.0.5/2.6.18-194.17.1.el5/oracleasm-2.6.18-194.17.1.el5-2.0.5-1.el5.x86_64.rpm
oss.oracle.com をDNSに問いあわせています... 141.146.12.120
oss.oracle.com|141.146.12.120|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 137417 (134K) [application/x-rpm]
`oracleasm-2.6.18-194.17.1.el5-2.0.5-1.el5.x86_64.rpm' に保存中

100%[=================================================================================================>] 137,417      161K/s 時間 0.8s    

2010-11-24 16:19:46 (161 KB/s) - `oracleasm-2.6.18-194.17.1.el5-2.0.5-1.el5.x86_64.rpm' へ保存完了 [137417/137417]

[root@discus164 tmp]# 

インストール（RACを構成する全ノードのrootユーザで）

[root@discus164 tmp]# rpm -ivh oracleasm-2.6.18-194.17.1.el5-2.0.5-1.el5.x86_64.rpm oracleasm-support-2.1.3-1.el5.x86_64.rpm oracleasmlib-2.0.4-1.el5.x86_64.rpm
警告: oracleasm-2.6.18-194.17.1.el5-2.0.5-1.el5.x86_64.rpm: ヘッダ V3 DSA signature: NOKEY, key ID 1e5e0159
準備中...                ########################################### [100%]
   1:oracleasm-support      ########################################### [ 33%]
   2:oracleasm-2.6.18-194.17########################################### [ 67%]
   3:oracleasmlib           ########################################### [100%]
[root@discus164 tmp]# 

構成（RACを構成する全ノードのrootユーザで）

[root@discus164 ˜]# /usr/sbin/oracleasm configure
ORACLEASM_ENABLED=false
ORACLEASM_UID=
ORACLEASM_GID=
ORACLEASM_SCANBOOT=true
ORACLEASM_SCANORDER=""
ORACLEASM_SCANEXCLUDE=""
[root@discus164 ˜]# /usr/sbin/oracleasm configure -i
Configuring the Oracle ASM library driver.

This will configure the on-boot properties of the Oracle ASM library
driver.  The following questions will determine whether the driver is
loaded on boot and what permissions it will have.  The current values
will be shown in brackets ('[]').  Hitting  without typing an
answer will keep that current value.  Ctrl-C will abort.

Default user to own the driver interface []: grid
Default group to own the driver interface []: asmadmin
Start Oracle ASM library driver on boot (y/n) [n]: y
Scan for Oracle ASM disks on boot (y/n) [y]: y
Writing Oracle ASM library driver configuration: done
[root@discus164 ˜]# 
[root@discus164 ˜]# /usr/sbin/oracleasm init
Creating /dev/oracleasm mount point: /dev/oracleasm
Loading module "oracleasm": oracleasm
Mounting ASMlib driver filesystem: /dev/oracleasm
[root@discus164 ˜]# 

ASMディスクの作成（RACを構成する１ノードのrootユーザで実行する）
iSCSIとして作成したデバイスへ作成する。

[root@discus164 iscsi]# ls -l /dev/iscsi/*
/dev/iscsi/openfiler:asm1:
合計 0
lrwxrwxrwx 1 root root  9 11月 24 10:39 part -> ../../sdb
lrwxrwxrwx 1 root root 10 11月 24 10:39 part1 -> ../../sdb1

/dev/iscsi/openfiler:asm2:
合計 0
lrwxrwxrwx 1 root root  9 11月 24 10:39 part -> ../../sdf
lrwxrwxrwx 1 root root 10 11月 24 10:39 part1 -> ../../sdf1

/dev/iscsi/openfiler:asm3:
合計 0
lrwxrwxrwx 1 root root  9 11月 24 10:39 part -> ../../sde
lrwxrwxrwx 1 root root 10 11月 24 10:39 part1 -> ../../sde1

/dev/iscsi/openfiler:asm4:
合計 0
lrwxrwxrwx 1 root root  9 11月 24 10:39 part -> ../../sdd
lrwxrwxrwx 1 root root 10 11月 24 10:39 part1 -> ../../sdd1

/dev/iscsi/openfiler:crs1:
合計 0
lrwxrwxrwx 1 root root  9 11月 24 10:39 part -> ../../sdg
lrwxrwxrwx 1 root root 10 11月 24 10:39 part1 -> ../../sdg1

/dev/iscsi/openfiler:crs2:
合計 0
lrwxrwxrwx 1 root root  9 11月 24 10:39 part -> ../../sdc
lrwxrwxrwx 1 root root 10 11月 24 10:39 part1 -> ../../sdc1
[root@discus164 iscsi]#
[root@discus164 iscsi]# /usr/sbin/oracleasm createdisk CRSVOL1 /dev/iscsi/openfiler:crs1/part1
Writing disk header: done
Instantiating disk: done
[root@discus164 iscsi]# /usr/sbin/oracleasm createdisk CRSVOL2 /dev/iscsi/openfiler:crs2/part1
Writing disk header: done
Instantiating disk: done
[root@discus164 iscsi]# /usr/sbin/oracleasm createdisk DATAVOL1 /dev/iscsi/openfiler:asm1/part1
Writing disk header: done
Instantiating disk: done
[root@discus164 iscsi]# /usr/sbin/oracleasm createdisk DATAVOL2 /dev/iscsi/openfiler:asm2/part1
Writing disk header: done
Instantiating disk: done
[root@discus164 iscsi]# /usr/sbin/oracleasm createdisk FRAVOL1 /dev/iscsi/openfiler:asm3/part1
Writing disk header: done
Instantiating disk: done
[root@discus164 iscsi]# /usr/sbin/oracleasm createdisk FRAVOL2 /dev/iscsi/openfiler:asm4/part1
Writing disk header: done
Instantiating disk: done
[root@discus164 iscsi]# 

ASMディスクを確認（RACを構成する全ノードのrootユーザで）
ASMディスクを作成したノード以外で scandisksコマンドを実行して認識させる。

[root@discus264 ˜]# /usr/sbin/oracleasm scandisks
Reloading disk partitions: done
Cleaning any stale ASM disks...
Scanning system for ASM disks...
Instantiating disk "FRAVOL2"
Instantiating disk "FRAVOL1"
Instantiating disk "DATAVOL1"
Instantiating disk "CRSVOL2"
Instantiating disk "DATAVOL2"
Instantiating disk "CRSVOL1"
[root@discus264 ˜]# 

listdisksコマンドでASMディスクが認識されたか確認！

[root@discus164 ˜]# 
[root@discus164 ˜]# 
[root@discus164 ˜]# /usr/sbin/oracleasm listdisks
CRSVOL1
CRSVOL2
DATAVOL1
DATAVOL2
FRAVOL1
FRAVOL2
[root@discus164 ˜]# 

[root@discus264 ˜]# 
[root@discus264 ˜]# 
[root@discus264 ˜]# /usr/sbin/oracleasm listdisks
CRSVOL1
CRSVOL2
DATAVOL1
DATAVOL2
FRAVOL1
FRAVOL2
[root@discus264 ˜]# 

次回へつづく。

---

これまでのあらすじ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

・VirtualBox de RAC (Oracle11g R1編） #1
・VirtualBox de RAC (Oracle11g R1編） #2

---

・VirtualBox de Oracle11g R2 RAC #1
・VirtualBox de Oracle11g R2 RAC #2 - 事前調査など…
・VirtualBox de Oracle11g R2 RAC #3
・VirtualBox de Oracle11g R2 RAC #4
・VirtualBox de Oracle11g R2 RAC #5
・VirtualBox de Oracle11g R2 RAC #6
・VirtualBox de Oracle11g R2 RAC #7
・VirtualBox de Oracle11g R2 RAC #8
・VirtualBox de Oracle11g R2 RAC #9
・VirtualBox de Oracle11g R2 RAC #10
・VirtualBox de Oracle11g R2 RAC #11
・VirtualBox de Oracle11g R2 RAC #12
・VirtualBox de Oracle11g R2 RAC #13

VirtualBox de Oracle11g R2 RAC #13

VirtualBox de Oracle11g R2 RACのつづきです。

RACを構成する各ノードの構成ファイルを確認しておきま〜す。

1. ハードウェア構成(VMなのでVMの構成も含めて）、ソフトウェア構成など
2. Linux (CentOS 5.5 x86_64)のインストール
3. Openfiler2.3 x86のインストール
4. Openfiler2.3 x86によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２、その３
6. Oracle所有者、Oracle Grid Infrastructureユーザの作成と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. Oracle RACノード間リモートアクセスの構成とntpの構成
   （sshの構成は念のために行った、多分、実施しなくても大丈夫だと思うけど…ついでなので、ちょいと意地悪な実験をしてみた）
9. ローカルネームサーバの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Automatic Storage Management(ASMLib 2.0.5 x84_64)のインストール及び構成
12. Oracle11g R2 11.2.0.1.0 RACインストール事前作業
13. Oracle11g R2 11.2.0.1.0 Grid Infrastractureのインストール
14. Oracle11g R2 11.2.0.1.0 Database softwareのインストール
15. Oracle11g R2 11.2.0.1.0 examplesのインストール
16. Oracle Cluster databaseの作成
17. Net Serviceの確認
18. Oralce Grid InsfastructureとDatabase構成の確認
19. Clusterの開始と停止の確認
20. 簡単なTransparent Application Failover (TAF)の確認

Oracle RACノード構成ファイルの確認

RACを構成する各ノードの構成ファイルをざっと確認。ここまでの作業でRACを構成する各ノードの構成ファイルは以下のようになっているはず…

/etc/hosts

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1	localhost.localdomain localhost
#::1		localhost6.localdomain6 localhost6

#for public network
192.168.1.90	discus164.macdeoracle.jp	discus164
192.168.1.91	discus264.macdeoracle.jp	discus264
192.168.1.92	arowana2.macdeoracle.jp		arowana2

#for Oracle Interconnect private network
192.168.3.90	discus164-priv.macdeoracle.jp	discus164-priv
192.168.3.91	discus264-priv.macdeoracle.jp	discus264-priv

#for iSCSI private network
192.168.2.92	arowana2-priv.macdeoracle.jp	arowana2-priv
192.168.2.90	discus164-iscsi.macdeoracle.jp	discus164-iscsi
192.168.2.91	discus264-iscsi.macdeoracle.jp	discus264-iscsi

#for virtual public network
192.168.1.190	discus164-vip.macdeoracle.jp	discus164-vip
192.168.1.191	discus264-vip.macdeoracle.jp	discus264-vip

192.168.1.2	lampeye.macdeoracle.jp		lampeye

/etc/security/limits.conf

[root@discus164 security]# diff -u limits.conf.org limits.conf
--- limits.conf.org     2010-03-12 02:24:15.000000000 +0900
+++ limits.conf 2010-11-24 11:10:30.000000000 +0900
@@ -48,3 +48,11 @@
 #@student        -       maxlogins       4
 
 # End of file
+grid soft nproc 2047
+grid hard nproc 16384
+grid soft nofile 1024
+grid hard nofile 65536
+oracle soft nproc 2047
+oracle hard nproc 16384
+oracle soft nofile 1024
+oracle hard nofile 65536
[root@discus164 security]# 

/etc/pam.d/login

[root@discus164 pam.d]# diff -u login.org login
--- login.org   2010-01-20 19:36:29.000000000 +0900
+++ login       2010-11-24 11:16:33.000000000 +0900
@@ -12,3 +12,4 @@
 # pam_selinux.so open should only be followed by sessions to be executed in the user context
 session    required     pam_selinux.so open
 session    optional     pam_keyinit.so force revoke
+session    required     pam_limits.so
[root@discus164 pam.d]# 

/etc/profile

[root@discus164 etc]# diff -u profile.org profile
--- profile.org 2009-09-22 08:27:09.000000000 +0900
+++ profile     2010-11-24 11:21:27.000000000 +0900
@@ -56,3 +56,12 @@
 
 unset i
 unset pathmunge
+if [ $USER = "oracle" ] || [ $USER = "grid" ]; then 
+    if [ $SHELL = "/bin/ksh" ]; then
+        ulimit -p 16384
+        ulimit -n 65536
+    else
+        ulimit -u 16384 -n 65536
+    fi
+    umask 022
+fi
[root@discus164 etc]# 

/etc/sysctl.conf

[root@discus164 ˜]# sysctl -a | grep -E '(se|sh)m|file-max|aio-max-nr|ip_local_port_range|(w|r)mem_(default|max)'
net.ipv4.ip_local_port_range = 32768    61000
net.core.rmem_default = 129024
net.core.wmem_default = 129024
net.core.rmem_max = 131071
net.core.wmem_max = 131071
vm.hugetlb_shm_group = 0
kernel.sem = 250        32000   32      128
kernel.shmmni = 4096
kernel.shmall = 4294967296
kernel.shmmax = 68719476736
fs.aio-max-nr = 65536
fs.file-max = 371217
[root@discus164 ˜]# 

/etc/udev/rules.d/55-openiscsi.rules

[root@discus164 ˜]# cat /etc/udev/rules.d/55-openiscsi.rules
KERNEL=="sd*", BUS=="scsi", PROGRAM="/etc/udev/scripts/iscsidev.sh %b",SYMLINK+="iscsi/%c/part%n"
[root@discus164 ˜]#

/etc/udev/scripts

[root@discus164 ˜]# cd /etc/udev/scripts
[root@discus164 scripts]# cat iscsidev.sh
#!/bin/sh

# FILE: /etc/udev/scripts/iscsidev.sh

BUS=${1}
HOST=${BUS%%:*}
[ -e /sys/class/iscsi_host ] || exit 1

file="/sys/class/iscsi_host/host${HOST}/device/session*/iscsi_session*/targetname"

target_name=$(cat ${file})

# This is not an open-scsi drive
if [ -z "${target_name}" ]; then
   exit 1
fi

echo "${target_name##*.}"
[root@discus164 scripts]# 

/etc/ntp.conf

[root@discus164 ˜]# cat /etc/ntp.conf
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod nomodify notrap nopeer noquery

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1 
#restrict -6 ::1

# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).

#broadcast 192.168.1.255 key 42		# broadcast server
#broadcastclient			# broadcast client
#broadcast 224.0.1.1 key 42		# multicast server
#multicastclient 224.0.1.1		# multicast client
#manycastserver 239.255.254.254		# manycast server
#manycastclient 239.255.254.254 key 42	# manycast client

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. 
#server 127.127.1.0
#fudge	127.127.1.0 stratum 10	

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift

# Key file containing the keys and key identifiers used when operating
# with symmetric key cryptography. 
keys /etc/ntp/keys

# Specify the key identifiers which are trusted.
#trustedkey 4 8 42

# Specify the key identifier to use with the ntpdc utility.
#requestkey 8

# Specify the key identifier to use with the ntpq utility.
#controlkey 8
server 192.168.1.2
server 192.168.1.2
server 192.168.1.2
restrict 192.168.1.2 mask 255.255.255.255 nomodify notrap noquery
[root@discus164 ˜]# 

/etc/sysconfig/ntpd

[root@discus164 ˜]# cat /etc/sysconfig/ntpd
# Drop root to id 'ntp:ntp' by default.
OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"

# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=yes

# Additional options for ntpdate
NTPDATE_OPTIONS="-B"
[root@discus164 ˜]# 

/etc/host.conf

[root@discus164 ˜]$ cat /etc/host.conf
order hosts,bind

Oracle Grid Infrastructureユーザや、Oracle所有者の確認はこちら

念のためにuserとgroupのスナップショットを乗せておきますね。

Openfier側構成(やゾンビセッション抑止などは以前の記事参照のこと）

次回へつづく。

---

これまでのあらすじ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

・VirtualBox de RAC (Oracle11g R1編） #1
・VirtualBox de RAC (Oracle11g R1編） #2

---

・VirtualBox de Oracle11g R2 RAC #1
・VirtualBox de Oracle11g R2 RAC #2 - 事前調査など…
・VirtualBox de Oracle11g R2 RAC #3
・VirtualBox de Oracle11g R2 RAC #4
・VirtualBox de Oracle11g R2 RAC #5
・VirtualBox de Oracle11g R2 RAC #6
・VirtualBox de Oracle11g R2 RAC #7
・VirtualBox de Oracle11g R2 RAC #8
・VirtualBox de Oracle11g R2 RAC #9
・VirtualBox de Oracle11g R2 RAC #10
・VirtualBox de Oracle11g R2 RAC #11
・VirtualBox de Oracle11g R2 RAC #12

VirtualBox de Oracle11g R2 RAC #12

VirtualBox de Oracle11g R2 RACのつづきです。

今回はRACノード構成ファイルの確認という予定だったのですが、DNSの構成を別建てにして置く事にします。量が多いので (^^;;

構成するDNSは、ローカルネットワークかつRACを構成するノードの管理さえできればいいので、ローカルネームサーバとして機能すれば十分。
ということで、RAC向けローカルネームサーバを構成することにします。（DNSは素人なので調べるほうが大変だったw)

では、さっそくやってみましょう。

1. ハードウェア構成(VMなのでVMの構成も含めて）、ソフトウェア構成など
2. Linux (CentOS 5.5 x86_64)のインストール
3. Openfiler2.3 x86のインストール
4. Openfiler2.3 x86によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２、その３
6. Oracle所有者、Oracle Grid Infrastructureユーザの作成と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. Oracle RACノード間リモートアクセスの構成とntpの構成
   （sshの構成は念のために行った、多分、実施しなくても大丈夫だと思うけど…ついでなので、ちょいと意地悪な実験をしてみた）
9. ローカルネームサーバの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Automatic Storage Management(ASMLib 2.0.5 x84_64)のインストール及び構成
12. Oracle11g R2 11.2.0.1.0 RACインストール事前作業
13. Oracle11g R2 11.2.0.1.0 Grid Infrastractureのインストール
14. Oracle11g R2 11.2.0.1.0 Database softwareのインストール
15. Oracle11g R2 11.2.0.1.0 examplesのインストール
16. Oracle Cluster databaseの作成
17. Net Serviceの確認
18. Oralce Grid InsfastructureとDatabase構成の確認
19. Clusterの開始と停止の確認
20. 簡単なTransparent Application Failover (TAF)の確認

DNSの構成

悩んだのが、DNSをどこにたてるかということ。いろいろ悩んでいたんですが、元ネタの１つからいいアイデアもらいました。
それは、DNSをOpenfiler上に構成するということ。ストレージサーバなのでRACを構成する各ノードより先に起動していますし。:)

最初にやるのはDNSサーバを最新版にアップデートすること。でもでもでもですね。以前痛い目にあっていたのでOpenfilerというかrPath Linuxのパッケージ管理は無効化していたんです。このままじゃDNSの最新パッケージを使えないので一時的に使えるようにします。

Openfilerのパッケージ管理は、conaryというrPath Linux由来のものが利用されています。/etc/conaryrcの内容をすべてコメントアウトして利用できないようしてあります。

[root@arowana2 ˜]# cat /etc/conaryrc
#installLabelPath openfiler.rpath.org@ofns:2 conary.rpath.com@rpl:1
#pinTroves (kernel|linux-image-2\.6\.[0-9]+-[0-9]+(-[a-z]+)?)([:-].*|$)
#autoResolve True
#includeConfigFile /etc/conary/config.d/*
[root@arowana2 ˜]# 

コメントアウトしていただけなのですぐに利用できるように戻せるのだ！ :)

[root@arowana2 ˜]# cat /etc/conaryrc
installLabelPath openfiler.rpath.org@ofns:2 conary.rpath.com@rpl:1
pinTroves (kernel|linux-image-2\.6\.[0-9]+-[0-9]+(-[a-z]+)?)([:-].*|$)
autoResolve True
includeConfigFile /etc/conary/config.d/*
[root@arowana2 ˜]# 

conaryをつかってbindを最新版にアップデート！！

[root@arowana2 ˜]# conary update bind:runtime

確認！　最新版になりました！

[root@arowana2 ˜]# conary q bind
bind=9.4.3_P5-1.1-1

再び、conaryを無効化しておく。（トラウマなだけで今は安定しているかもしれんw　だけど止めとくw)

[root@arowana2 ˜]# cat /etc/conaryrc
#installLabelPath openfiler.rpath.org@ofns:2 conary.rpath.com@rpl:1
#pinTroves (kernel|linux-image-2\.6\.[0-9]+-[0-9]+(-[a-z]+)?)([:-].*|$)
#autoResolve True
#includeConfigFile /etc/conary/config.d/*
[root@arowana2 ˜]# 

Openfiler（host名：arowana2）で、DNSの構成を始めるにあたって参考にしたサイトを書いておきますね。

・Oracle Grid Infrastructureインストレーション・ガイド 11gリリース2（11.2）for Linux - 2.7.4 グリッド・ネーミング・サービスの構成例
・Openfiler側にDNSを立てるというアイデアを頂いたサイト。元ネタの１つでもある。
・DNSの素人なりにいろいろググって見つけたすげー参考になったサイト「月刊NetworkWorld連載『DNSの仕組み完全解説』」(ありがとうございます！）

今回構築するRACのネットワーク構成は以前の書いたが以下のように構成する。

RACを構成するノード１ (hostname=discus164.macdeoracle.jp)
Hostname	タイプ	IP address	名前解決方法
discus164	Public	192.168.1.90	hostsおよびDNS
discus164-iscsi	Private	192.168.2.90
discus164-priv	Private	192.168.3.90
discus164-vip	Virtual	192.168.1.190
RACを構成するノード２ (hostname=discus264.macdeoracle.jp)
Hostname	タイプ	IP address	名前解決方法
discus264	Public	192.168.1.91	hostsおよびDNS
discus264-iscsi	Private	192.168.2.91
discus264-priv	Private	192.168.3.91
discus264-vip	Virtual	192.168.1.191
SCAN VIP1/2/3
Hostname	タイプ	IP address	名前解決方法
discus-rac64-scan	Virtual	192.168.1.200	DNS
discus-rac64-scan		192.168.1.201
discus-rac64-scan		192.168.1.202
Openfiler2.3(iSCSI) - (hostname=arowana2.macdeoracle.jp)
Hostname	タイプ	IP address	名前解決方法
arowana2	Public	192.168.1.92	hostsおよびDNS
arowana2-priv	Private	192.168.2.92

・DNSの構成

/etc/resolv.confの構成は以下の通り。ローカルipアドレスを利用しているRACの各ノードやOpenfilerは/etc/hostsとdnsで解決できるようにしておきます。ipアドレスはすべて固定です。

[root@arowana2 ˜]# cat /etc/resolv.conf
search macdeoracle.jp
nameserver 192.168.1.92

; Forward Lookup Zone
discus164               IN A            192.168.1.90
discus264               IN A            192.168.1.91
discus164-priv          IN A            192.168.3.90
discus264-priv          IN A            192.168.3.91
discus164-iscsi         IN A            192.168.2.90
discus264-iscsi         IN A            192.168.2.91
discus164-vip           IN A            192.168.1.190
discus264-vip           IN A            192.168.1.191
arowana2                IN A            192.168.1.92
arowana2-priv           IN A            192.168.2.92
discus-rac64-scan       IN A            192.168.1.200
discus-rac64-scan       IN A            192.168.1.201
discus-rac64-scan       IN A            192.168.1.202

; Reverse Lookup Zone
90                      IN PTR          discus164.macdeoracle.jp.
91                      IN PTR          discus264.nacdeiracle,jp.
190                     IN PTR          discus164-vip.macdeoracle.jp.
191                     IN PTR          discus264-vip.macdeoracle.jp.
200                     IN PTR          discus-rac64-scan.macdeoracle.jp.
201                     IN PTR          discus-rac64-scan.macdeoracle.jp.
202                     IN PTR          discus-rac64-scan.macdeoracle.jp.
[root@arowana2 ˜]# 

/etc/named.confの構成。（逆引き／正引きのゾーン設定や上位DNSへの回送設定）
逆引きの設定で、RACで利用しているローカルipアドレス以外はダーミーゾーンに設定しているところがポイント。気になっていたところなのでググってよい参考サイト見つけられてよかった。ほんと感謝、感謝。

[root@arowana2 ˜]# cat /etc/named.conf
# DNS configuration file for Oracle RAC 11g release 2 

options {


    // FORWARDERS:  Forward any name this DNS can't resolve to my router.
    forwarders { 192.168.1.1; };

    // DIRECTORY:   Directory where named will look for zone files.
    directory "/srv/named/data";

	//allow query requests 
    allow-query { 192.168.0.0/22; };
};

# ----------------------------------
# Forward Zone
# ----------------------------------

zone "macdeoracle.jp" IN {
    type master;
    file "macdeoracle.jp.zone";
    allow-update { none; };
};

# ----------------------------------
# Reverse Zone
# ----------------------------------

zone "1.168.192.in-addr.arpa" IN {
    type master;
    file "1.168.192.in-addr.arpa.zone";
    allow-update { none; };
};

zone "168.192.in-addr.arpa" IN {
	type master;
	file "dummy.zone";
	notify no;
};

zone "0.0.127.in-addr.arpa" IN {
	type master;
	file "0.0.127.in-addr.arpa.zone";
	notify no;
};

# ----------------------------------
# private addresses dummy Zone
# ---------------------------------

zone "10.in-addr.arpa" {
	type master;
	file "dummy.zone";
	notify no;
};

zone "16.172.in-addr.arpa" {
    type master;
    file "dummy.zone";
    notify no;
};

zone "17,172,in-addr.arpa" {
	type master;
	file "dummy.zone";
	notify no;
};

zone "18.172.in-addr.arpa" {
    type master;
    file "dummy.zone";
    notify no;
};

zone "19.172.in-addr.arpa" {
    type master;
    file "dummy.zone";
    notify no;
};

zone "20.172.in-addr.arpa" {
    type master;
    file "dummy.zone";
    notify no;
};

zone "21.172.in-addr.arpa" {
    type master;
    file "dummy.zone";
    notify no;
};

zone "22.172.in-addr.arpa" {
    type master;
    file "dummy.zone";
    notify no;
};

zone "23.172.in-addr.arpa" {
    type master;
    file "dummy.zone";
    notify no;
};

zone "24.172.in-addr.arpa" {
    type master;
    file "dummy.zone";
    notify no;
};

zone "25.172.in-addr.arpa" {
    type master;
    file "dummy.zone";
    notify no;
};

zone "26.172.in-addr.arpa" {
    type master;
    file "dummy.zone";
    notify no;
};

zone "27.172.in-addr.arpa" {
    type master;
    file "dummy.zone";
    notify no;
};

zone "28.172.in-addr.arpa" {
    type master;
    file "dummy.zone";
    notify no;
};

zone "29.172.in-addr.arpa" {
    type master;
    file "dummy.zone";
    notify no;
};

zone "30.172.in-addr.arpa" {
    type master;
    file "dummy.zone";
    notify no;
};

zone "31.172,in-addr.arpa" {
    type master;
    file "dummy.zone";
    notify no;
};

[root@arowana2 ˜]# 

・以下、正引き／逆引き用ゾーンファイルの作成
/srv/named/data/macdeoracle.jp.zoneの作成（正引き用ゾーンファイル）

[root@arowana2 ˜]# cat /srv/named/data/macdeoracle.jp.zone
; +-------------------------------------------------------------------+
; | /srv/named/data/macdeoracle.jp.zone                               |
; |                                                                   |
; | Forward zone definition file for macdeoracle.jp zone              |
; +-------------------------------------------------------------------+

$ORIGIN macdeoracle.jp.

$TTL 86400          ; time-to-live   - (1 day)

@  IN SOA  arowana2.macdeoracle.jp. discus.lampeye.macdeoracle.jp. (
        201011021   ; serial number  - (yyyymmdd+s)
        7200        ; refresh        - (2 hours)
        300         ; retry          - (5 minutes)
        604800      ; expire         - (1 week)
        60          ; minimum        - (1 minute)
)
                        IN NS       arowana2.macdeoracle.jp.
localhost               IN A        127.0.0.1

; Oracle RAC Nodes
discus164               IN A            192.168.1.90
discus264               IN A            192.168.1.91
discus164-priv          IN A            192.168.3.90
discus264-priv          IN A            192.168.3.91
discus164-iscsi         IN A            192.168.2.90
discus264-iscsi         IN A            192.168.2.91
discus164-vip           IN A            192.168.1.190
discus264-vip           IN A            192.168.1.191

; Network Storage Server
arowana2                IN A            192.168.1.92
arowana2-priv           IN A            192.168.2.92

; Single Client Access Name (SCAN) virtual IP
discus-rac64-scan       IN A            192.168.1.200
discus-rac64-scan       IN A            192.168.1.201
discus-rac64-scan       IN A            192.168.1.202

; Miscellaneous Nodes
lampeye                 IN A            192.168.1.2
[root@arowana2 ˜]# 

/srv/named/data/168.192.in-addr.arpa.zon（逆引き用ゾーンファイル）の作成

[root@arowana2 data]# cat 168.192.in-addr.arpa.zone
; +-------------------------------------------------------------------+
; | /srv/named/data/168.192.in-addr.arpa.zone                         |
; |                                                                   |
; | Reverse zone definition file for 168.192.in-addr.arpa.zone        |
; +-------------------------------------------------------------------+

$ORIGIN 168.192.in-addr.arpa.

$TTL 86400          ; time-to-live   - (1 day)

@  IN SOA  arowana2.macdeoracle.jp. discus.lampeye.macdeoracle.jp. (
        201011021   ; serial number  - (yyyymmdd+s)
        7200        ; refresh        - (2 hours)
        300         ; retry          - (5 minutes)
        604800      ; expire         - (1 week)
        60          ; minimum        - (1 minute)
)
                        IN NS       arowana2.macdeoracle.jp.

; Oracle RAC Nodes
90                      IN PTR          discus164.macdeoracle.jp.
91                      IN PTR          discus264.macdeoracle.jp.
190                     IN PTR          discus164-vip.macdeoracle.jp.
191                     IN PTR          discus264-vip.macdeoracle.jp.

; Network Storage Server
92                      IN PTR          arowana2.macdeoracle.jp.

; Single Client Access Name (SCAN) virtual IP
200                     IN PTR          discus-rac64-scan.macdeoracle.jp.
201                     IN PTR          discus-rac64-scan.macdeoracle.jp.
202                     IN PTR          discus-rac64-scan.macdeoracle.jp.

; Miscellaneous Nodes
2                       IN PTR          lampeye.macdeoracle.jp.
[root@arowana2 data]# 

ローカルホスト(127.0.0.1)の逆引きゾーンの定義

[root@arowana2 ˜]# cat /srv/named/data/0.0.127.in-addr.arpa.zone
; +-------------------------------------------------------------------+
; | /srv/named/data/0.0.127.in-addr.arpa.zone                         |
; |                                                                   |
; | Reverse zone definition file for 0.0.127.in-addr.arpa.zone        |
; +-------------------------------------------------------------------+

$ORIGIN 0.0.127.in-addr.arpa.

$TTL 86400          ; time-to-live   - (1 day)

@  IN SOA  arowana2.macdeoracle.jp. discus.lampeye.macdeoracle.jp. (
        201011021   ; serial number  - (yyyymmdd+s)
        7200        ; refresh        - (2 hours)
        300         ; retry          - (5 minutes)
        604800      ; expire         - (1 week)
        60          ; minimum        - (1 minute)
)
                        IN NS       arowana2.macdeoracle.jp.

; localhost
1			IN PTR		localhost.
[root@arowana2 ˜]# 

/srv/named/data/dummy.zone（ダミーゾーンファイル）の作成
「月刊NetworkWorld連載『DNSの仕組み完全解説』」の記事を参考にローカルipアドレスの逆引きの問い合わせが外部のDNSに発生しないようにするために利用するダミーゾーンファイルの定義を以下のように作成した。

[root@arowana2 ˜]# cat /srv/named/data/dummy.zone
; +-------------------------------------------------------------------+
; | /srv/named/data/dummy.zone                                        |
; +-------------------------------------------------------------------+


$TTL 86400          ; time-to-live   - (1 day)

@  IN SOA  arowana2.macdeoracle.jp. discus.lampeye.macdeoracle.jp. (
        201011021   ; serial number  - (yyyymmdd+s)
        28800       ; refresh        - (2 hours)
        2700        ; retry          - (5 minutes)
        604800      ; expire         - (1 week)
        3600        ; minimum        - (1 minute)
)
                        IN NS       arowana2.macdeoracle.jp.
[root@arowana2 ˜]# 

構成できたらnamedを自動起動設定にしてnamedを起動

[root@arowana2 ˜]# chkconfig named on
[root@arowana2 ˜]# chkconfig --list named
named			0:off	1:off	2:on	3:on	4:on	5:on	6:off
[root@arowana2 ˜]# service named start
Starting named:								[  OK  ]

ここまでてdnsの設定はおしまい。前述の作業はすべてOpenfilerを乗せているサーバ上で行った。

つづいて、RACを構成する各ノードでOpenfiler上に構成したローカルネームサーバを参照させるように設定する。
/etc/host.confの構成（RACを構成する全ノード及び、Openfilerを構成したノード）

/etc/hostsを優先させる。/etc/hostsを見てもらうとわかるけど、dnsと重複定義している。無駄と言えばむだだと思うけど。SCAN VIPだけdns管理すればOKなのかってとこまでは見えてないからそれはそれで別途確認だな→TODO

[oracle@discus164 ˜]$ cat /etc/host.conf
order hosts,bind

/etc/hostsの構成（RACを構成する全ノード及び、Openfilerを構成したノード）

[oracle@discus164 ˜]$ cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1	localhost.localdomain localhost
#::1		localhost6.localdomain6 localhost6

#for public network
192.168.1.90	discus164.macdeoracle.jp	discus164
192.168.1.91	discus264.macdeoracle.jp	discus264
192.168.1.92	arowana2.macdeoracle.jp		arowana2

#for Oracle Interconnect private network
192.168.3.90	discus164-priv.macdeoracle.jp	discus164-priv
192.168.3.91	discus264-priv.macdeoracle.jp	discus264-priv

#for iSCSI private network
192.168.2.92	arowana2-priv.macdeoracle.jp	arowana2-priv
192.168.2.90	discus164-iscsi.macdeoracle.jp	discus164-iscsi
192.168.2.91	discus264-iscsi.macdeoracle.jp	discus264-iscsi

#for virtual public network
192.168.1.190	discus164-vip.macdeoracle.jp	discus164-vip
192.168.1.191	discus264-vip.macdeoracle.jp	discus264-vip


192.168.1.2	lampeye.macdeoracle.jp		lampeye
[oracle@discus164 ˜]$ 

これで準備OK.続いて動作確認！

・正引きテスト

最初に外部サイトが引けるか確認…OK.

[root@discus164 ˜]# nslookup openfiler.com
Server:		192.168.1.92
Address:	192.168.1.92#53

Non-authoritative answer:
Name:	openfiler.com
Address: 84.45.94.236

[root@discus164 ˜]# 

次に内部…

[root@discus164 ˜]# nslookup lampeye 
Server:         192.168.1.92
Address:        192.168.1.92#53

Name:   lampeye.macdeoracle.jp
Address: 192.168.1.2

[root@discus164 ˜]# nslookup discus164
Server:         192.168.1.92
Address:        192.168.1.92#53

Name:   discus164.macdeoracle.jp
Address: 192.168.1.90

[root@discus164 ˜]# nslookup discus164-vip
Server:         192.168.1.92
Address:        192.168.1.92#53

Name:   discus164-vip.macdeoracle.jp
Address: 192.168.1.190

[root@discus164 ˜]# nslookup discus264
Server:         192.168.1.92
Address:        192.168.1.92#53

Name:   discus264.macdeoracle.jp
Address: 192.168.1.91

[root@discus164 ˜]# nslookup discus264-vip
Server:         192.168.1.92
Address:        192.168.1.92#53

Name:   discus264-vip.macdeoracle.jp
Address: 192.168.1.191

[root@discus164 ˜]# nslookup discus-rac64-scan
Server:         192.168.1.92
Address:        192.168.1.92#53

Name:   discus-rac64-scan.macdeoracle.jp
Address: 192.168.1.201
Name:   discus-rac64-scan.macdeoracle.jp
Address: 192.168.1.202
Name:   discus-rac64-scan.macdeoracle.jp
Address: 192.168.1.200

[root@discus164 ˜]# nslookup localhost
Server:         192.168.1.92
Address:        192.168.1.92#53

Name:   localhost.macdeoracle.jp
Address: 127.0.0.1

・逆引きテスト

[root@discus164 ˜]# nslookup 192.168.1.200
Server:         192.168.1.92
Address:        192.168.1.92#53

200.1.168.192.in-addr.arpa      name = discus-rac64-scan.macdeoracle.jp.

[root@discus164 ˜]# nslookup 192.168.1.201
Server:         192.168.1.92
Address:        192.168.1.92#53

201.1.168.192.in-addr.arpa      name = discus-rac64-scan.macdeoracle.jp.

[root@discus164 ˜]# nslookup 192.168.1.202
Server:         192.168.1.92
Address:        192.168.1.92#53

202.1.168.192.in-addr.arpa      name = discus-rac64-scan.macdeoracle.jp.

[root@discus164 ˜]# nslookup 192.168.1.90
Server:         192.168.1.92
Address:        192.168.1.92#53

90.1.168.192.in-addr.arpa       name = discus164.macdeoracle.jp.

[root@discus164 ˜]# nslookup 192.168.1.91
Server:         192.168.1.92
Address:        192.168.1.92#53

91.1.168.192.in-addr.arpa       name = discus264.macdeoracle.jp.

[root@discus164 ˜]# nslookup 192.168.1.190
Server:         192.168.1.92
Address:        192.168.1.92#53

190.1.168.192.in-addr.arpa      name = discus164-vip.macdeoracle.jp.

[root@discus164 ˜]# nslookup 192.168.1.191
Server:         192.168.1.92
Address:        192.168.1.92#53

191.1.168.192.in-addr.arpa      name = discus264-vip.macdeoracle.jp.


[root@discus164 ˜]# nslookup 127.0.0.1
Server:		192.168.1.92
Address:	192.168.1.92#53

1.0.0.127.in-addr.arpa	name = localhost.

[root@discus164 ˜]# 

これでOK次回へつづく。

---

これまでのあらすじ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

・VirtualBox de RAC (Oracle11g R1編） #1
・VirtualBox de RAC (Oracle11g R1編） #2

---

・VirtualBox de Oracle11g R2 RAC #1
・VirtualBox de Oracle11g R2 RAC #2 - 事前調査など…
・VirtualBox de Oracle11g R2 RAC #3
・VirtualBox de Oracle11g R2 RAC #4
・VirtualBox de Oracle11g R2 RAC #5
・VirtualBox de Oracle11g R2 RAC #6
・VirtualBox de Oracle11g R2 RAC #7
・VirtualBox de Oracle11g R2 RAC #8
・VirtualBox de Oracle11g R2 RAC #9
・VirtualBox de Oracle11g R2 RAC #10
・VirtualBox de Oracle11g R2 RAC #11

VirtualBox de Oracle11g R2 RAC #11

VirtualBox de Oracle11g R2 RACのつづきです。

今回は、RACノード間リモートアクセスの構成です。
Oracle11g R2 11.2.0.2.0ではパスフレーズなしでSSHを構成する必要があるのですが、OUIが自動構成してくれるということ、また、インストレーションガイドでもOUIの自動構成を利用するよう推奨されているんですが、今回はちょっと意地悪なことをしてみます。事前にパスワード付きでSSHを構成しておき、OUIがパスワードなしのSSH構成行われていないと認識しちゃんと自動構成してくれるか見てみます。

Oracle Grid Infrastructureインストレーション・ガイド 11gリリース2（11.2）for Linux - 2.13 インストール時におけるSSHの自動構成
Oracle Grid Infrastructureインストレーション・ガイド 11gリリース2（11.2）for Linux - E.1 すべてのクラスタ・ノードでの手動によるSSHの構成

では、さっそくやってみましょう。

1. ハードウェア構成(VMなのでVMの構成も含めて）、ソフトウェア構成など
2. Linux (CentOS 5.5 x86_64)のインストール
3. Openfiler2.3 x86のインストール
4. Openfiler2.3 x86によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２、その３
6. Oracle所有者、Oracle Grid Infrastructureユーザの作成と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. Oracle RACノード間リモートアクセスの構成とntpの構成
   （sshの構成は念のために行った、多分、実施しなくても大丈夫だと思うけど…ついでなので、ちょいと意地悪な実験をしてみた）
9. ローカルネームサーバの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Automatic Storage Management(ASMLib 2.0.5 x84_64)のインストール及び構成
12. Oracle11g R2 11.2.0.1.0 RACインストール事前作業
13. Oracle11g R2 11.2.0.1.0 Grid Infrastractureのインストール
14. Oracle11g R2 11.2.0.1.0 Database softwareのインストール
15. Oracle11g R2 11.2.0.1.0 examplesのインストール
16. Oracle Cluster databaseの作成
17. Net Serviceの確認
18. Oralce Grid InsfastructureとDatabase構成の確認
19. Clusterの開始と停止の確認
20. 簡単なTransparent Application Failover (TAF)の確認

Oracle RACノード間リモートアクセスの構成
（念のために行った、多分、実施しなくても大丈夫だと思うけど…ちょいと意地悪な実験をしてみた）
sshパッケージの確認。（RACを構成する全ノードで）

[root@discus164 etc]# rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE} (%{ARCH})\n"| grep ssh
openssh-server-4.3p2-41.el5_5.1 (x86_64)
openssh-askpass-4.3p2-41.el5_5.1 (x86_64)
openssh-clients-4.3p2-41.el5_5.1 (x86_64)
openssh-4.3p2-41.el5_5.1 (x86_64)
[root@discus164 etc]# 

Oracle11g R2 11.2.0.2.0以降ではSSHのユーザの等価化ではパスフレーズなしのみサポートされているのだとか。なんなく面白そうなので、今回は手動でユーザの等価化をわざわざサポートされていないというパスフレーズ付きで実施してみた（ユーザの等価化チェックでエラーとなりOUI側で自動的にパスフレーズなしのユーザ等価化が行われるはず、なのでどうなるか楽しみ！！！）

RACを構成する全ノードのgrid infrastrucreユーザと/oracle所有者で実施する。（Oracle11g 11.2.0.2.0において手動でSSHのユーザ等価化を行う場合、パスフレーズを入力する箇所でパスフレーズを入力せず、[ENTER]キーをタイプすればOKなのですが、今回は、あえてパスフレーズを入力してあります。ログ上ではパスフレーズを入力していないように見えますが.)

[root@discus164 ˜]# su - grid
[grid@discus164 ˜]$ 
[grid@discus164 ˜]$ mkdir ˜/.ssh
[grid@discus164 ˜]$ chmod 700 ˜/.ssh
[grid@discus164 ˜]$ /usr/bin/ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/grid/.ssh/id_dsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/grid/.ssh/id_dsa.
Your public key has been saved in /home/grid/.ssh/id_dsa.pub.
The key fingerprint is:
ba:bb:09:72:94:94:d6:29:99:12:7f:d2:a6:a6:60:0a grid@discus164.macdeoracle.jp
[grid@discus164 ˜]$ 

[root@discus164 ˜]# 
[root@discus164 ˜]# su - oracle
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ mkdir ˜/.ssh
[oracle@discus164 ˜]$ chmod 700 ˜/.ssh
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ /usr/bin/ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/oracle/.ssh/id_dsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/oracle/.ssh/id_dsa.
Your public key has been saved in /home/oracle/.ssh/id_dsa.pub.
The key fingerprint is:
88:5d:b0:ec:80:8c:59:ed:22:f7:d8:88:6d:6c:41:1a oracle@discus164.macdeoracle.jp
[oracle@discus164 ˜]$ 

以下の操作はRAC上の１ノードから行えばOK。ただ、gid infrastructureユーザとOracle所有者の両ユーザで行う必要があるのでご注意を。11.2.0.2.0以降では以前のリリースのように神経質にならなくてもいいかもね。sshの構成に関しては……
Oracle Grid Infrastructureユーザから…

[root@discus164 ˜]# su - grid
[grid@discus164 ˜]$ 
[grid@discus164 ˜]$ 
[grid@discus164 ˜]$ touch ˜/.ssh/authorized_keys
[grid@discus164 ˜]$ cd ˜/.ssh
[grid@discus164 .ssh]$ ls -l *.pub
-rw-r--r-- 1 grid oinstall 619 11月 24 13:11 id_dsa.pub
[grid@discus164 .ssh]$ ssh discus164 cat ˜/.ssh/id_dsa.pub >> ˜/.ssh/authorized_keys
The authenticity of host 'discus164 (192.168.1.90)' can't be established.
RSA key fingerprint is 15:90:e9:89:98:8e:ed:3f:67:7b:d4:e7:97:6b:58:c5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'discus164,192.168.1.90' (RSA) to the list of known hosts.
grid@discus164's password: 
[grid@discus164 .ssh]$ ssh discus264 cat ˜/.ssh/id_dsa.pub >> ˜/.ssh/authorized_keys
The authenticity of host 'discus264 (192.168.1.91)' can't be established.
RSA key fingerprint is 55:80:d3:23:4f:82:44:4b:b8:89:02:d8:69:31:7e:f5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'discus264,192.168.1.91' (RSA) to the list of known hosts.
grid@discus264's password: 
[grid@discus164 .ssh]$ scp ˜/.ssh/authorized_keys discus264:.ssh/authorized_keys
grid@discus264's password: 
authorized_keys                                                        100% 1238     1.2KB/s   00:00
[grid@discus164 .ssh]$ chmod 600 ˜/.ssh/authorized_keys
[grid@discus164 .ssh]$ 
[grid@discus164 ˜]$ ssh discus164 hostname
Enter passphrase for key '/home/grid/.ssh/id_dsa': 
discus164.macdeoracle.jp
[grid@discus164 ˜]$ ssh discus264 hostname
Enter passphrase for key '/home/grid/.ssh/id_dsa': 
discus264.macdeoracle.jp
[grid@discus164 ˜]$ 

次はOracle所有者で…　11.2.0.2.0以降パスブレーズなしにする必要があるのですがわざと入れてます　(^^)

[root@discus164 ˜]# su - oracle
[oracle@discus164 ˜]$ touch ˜/.ssh/authorized_keys
[oracle@discus164 ˜]$ cd ˜/.ssh
[oracle@discus164 .ssh]$ ls -l *.pub
-rw-r--r-- 1 oracle oinstall 621 11月 24 13:14 id_dsa.pub
[oracle@discus164 .ssh]$ ssh discus164 cat ˜/.ssh/id_dsa.pub >> ˜/.ssh/authorized_keys
The authenticity of host 'discus164 (192.168.1.90)' can't be established.
RSA key fingerprint is 15:90:e9:89:98:8e:ed:3f:67:7b:d4:e7:97:6b:58:c5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'discus164,192.168.1.90' (RSA) to the list of known hosts.
oracle@discus164's password: 
[oracle@discus164 .ssh]$ ssh discus264 cat ˜/.ssh/id_dsa.pub >> ˜/.ssh/authorized_keys
The authenticity of host 'discus264 (192.168.1.91)' can't be established.
RSA key fingerprint is 55:80:d3:23:4f:82:44:4b:b8:89:02:d8:69:31:7e:f5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'discus264,192.168.1.91' (RSA) to the list of known hosts.
oracle@discus264's password: 
[oracle@discus164 .ssh]$ scp ˜/.ssh/authorized_keys discus264:.ssh/authorized_keys
oracle@discus264's password: 
authorized_keys                                                        100% 1242     1.2KB/s   00:00
[oracle@discus164 .ssh]$ chmod 600 ˜/.ssh/authorized_keys
[oracle@discus164 .ssh]$ cd
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ ssh discus164 hostname
Enter passphrase for key '/home/oracle/.ssh/id_dsa': 
discus164.macdeoracle.jp

[oracle@discus164 ˜]$ ssh discus264 hostname
Enter passphrase for key '/home/oracle/.ssh/id_dsa': 
discus264.macdeoracle.jp
[oracle@discus164 ˜]$ 

確認！ gird infrastructureユーザとOracle所有者の両方で。

[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ exec /usr/bin/ssh-agent $SHELL
[oracle@discus164 ˜]$ /usr/bin/ssh-add
Enter passphrase for /home/oracle/.ssh/id_dsa: 
Identity added: /home/oracle/.ssh/id_dsa (/home/oracle/.ssh/id_dsa)
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ ssh discus164 hostname
discus164.macdeoracle.jp
[oracle@discus164 ˜]$ ssh discus264 hostname
discus264.macdeoracle.jp
[oracle@discus164 ˜]$ 
[oracle@discus164 ˜]$ exit
exit
[root@discus164 ˜]# su - grid
[grid@discus164 ˜]$ exec /usr/bin/ssh-agent $SHELL
[grid@discus164 ˜]$ /usr/bin/ssh-add
Enter passphrase for /home/grid/.ssh/id_dsa: 
Identity added: /home/grid/.ssh/id_dsa (/home/grid/.ssh/id_dsa)
[grid@discus164 ˜]$ ssh discus164 hostname
discus164.macdeoracle.jp
[grid@discus164 ˜]$ ssh discus264 hostname
discus264.macdeoracle.jp
[grid@discus164 ˜]$ 

最後に、sttyコマンドよるインストールエラーメッセージ抑止（全ノードの grid/oracleユーザで実施）

参考：Oracle Grid Infrastructureインストレーション・ガイド 11gリリース2（11.2）for Linux - 2.14.5 インストール中にsttyコマンドによって発生するエラーの防止

[grid@discus164 ˜]$ su - oracle
パスワード:
[oracle@discus164 ˜]$ vi .bashrc
[oracle@discus164 ˜]$ cat .bashrc
# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi

# User specific aliases and functions
if [ -t 0 ]; then
        stty intr ^C
fi
[oracle@discus164 ˜]$ 

ここで、やる予定ではなかったのですが、次いでなのでNTPの設定もついでにやっちゃいました。

Host OS側で公開NTPサーバと同期、VirtualBox上に作成したRACを構成する各Guest OSは、Host OSをNTPサーバとして同期する。
このようにしておけば公開NTPサーバを参照するのはHost OSだけなので余計な問い合わせを押さえることができますよね。

RACを構成する全ノード及び、iSCSIでも同じ構成にしてあります。ちなみに、192.168.1.2がHost OS

/etc/ntp.confと/etc/sysconfig/ntpdで構成します。ntpはslewモードで調整するよう設定します。

[root@discus164 ˜]# cat /etc/ntp.conf
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod nomodify notrap nopeer noquery

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1 
#restrict -6 ::1

# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).

#broadcast 192.168.1.255 key 42		# broadcast server
#broadcastclient			# broadcast client
#broadcast 224.0.1.1 key 42		# multicast server
#multicastclient 224.0.1.1		# multicast client
#manycastserver 239.255.254.254		# manycast server
#manycastclient 239.255.254.254 key 42	# manycast client

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. 
#server 127.127.1.0
#fudge	127.127.1.0 stratum 10	

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift

# Key file containing the keys and key identifiers used when operating
# with symmetric key cryptography. 
keys /etc/ntp/keys

# Specify the key identifiers which are trusted.
#trustedkey 4 8 42

# Specify the key identifier to use with the ntpdc utility.
#requestkey 8

# Specify the key identifier to use with the ntpq utility.
#controlkey 8
server 192.168.1.2
server 192.168.1.2
server 192.168.1.2
restrict 192.168.1.2 mask 255.255.255.255 nomodify notrap noquery
[root@discus164 ˜]# 

[root@discus164 ˜]# cat /etc/sysconfig/ntpd
# Drop root to id 'ntp:ntp' by default.
OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"

# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=yes

# Additional options for ntpdate
NTPDATE_OPTIONS="-B"
[root@discus164 ˜]# 

HostOS側は公開NTPサーバと同期するので以下のような設定にしてあります。

[root@lampeye ˜]# cat /etc/ntp.conf
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod nomodify notrap nopeer noquery

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1 

# Hosts on local network are less restricted.
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server -4 ntp.nict.jp minpoll 8 maxpoll 12
server -4 ntp.nict.jp minpoll 8 maxpoll 12
server -4 ntp.nict.jp minpoll 8 maxpoll 12

#broadcast 192.168.1.255 key 42		# broadcast server
#broadcastclient			# broadcast client
#broadcast 224.0.1.1 key 42		# multicast server
#multicastclient 224.0.1.1		# multicast client
#manycastserver 239.255.254.254		# manycast server
#manycastclient 239.255.254.254 key 42	# manycast client

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. 
server 127.127.1.0 #local clock
fudge	127.127.1.0 stratum 10	

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift

# Key file containing the keys and key identifiers used when operating
# with symmetric key cryptography. 
keys /etc/ntp/keys

# Specify the key identifiers which are trusted.
#trustedkey 4 8 42

# Specify the key identifier to use with the ntpdc utility.
#requestkey 8

# Specify the key identifier to use with the ntpq utility.
#controlkey 8
restrict ntp.nict.jp mask 255.255.255.255 nomodify notrap noquery
[root@lampeye ˜]# 

[root@lampeye ˜]# cat /etc/sysconfig/ntpd
# Drop root to id 'ntp:ntp' by default.
OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"

# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=yes

# Additional options for ntpdate
NTPDATE_OPTIONS="-B"
[root@lampeye ˜]#

service ntpd restart で再起動。しばらくしてから…

Host OSがntpサーバと同期できているか確認！！

[root@lampeye ˜]# ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*210.171.226.40  .NICT.           1 u   38 1024  377   10.447   59.103   9.904
 127.127.1.0     .LOCL.          10 l   22   64  377    0.000    0.000   0.001
[root@lampeye ˜]# 

公開NTPサーバと同期できています。:)

次はRACを構成する各ノードでHost OSと同期しているか確認します。"*"が表示されているのでうまくいっているようですね。 :)

[root@discus164 ˜]# ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.1.2     210.171.226.40   2 u   95  128  377    0.179  121.450  39.443
[root@discus164 ˜]# 

[root@discus264 ˜]# ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.1.2     210.171.226.40   2 u    5  128  377    0.288  214.652  43.610
[root@discus264 ˜]# 

[root@arowana2 ˜]# ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.1.2     210.171.226.40   2 u   35  128  377    0.278  -83.188   0.087
[root@arowana2 ˜]# 

ということで次回へつづく。

---

これまでのあらすじ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

・VirtualBox de RAC (Oracle11g R1編） #1
・VirtualBox de RAC (Oracle11g R1編） #2

---

・VirtualBox de Oracle11g R2 RAC #1
・VirtualBox de Oracle11g R2 RAC #2 - 事前調査など…
・VirtualBox de Oracle11g R2 RAC #3
・VirtualBox de Oracle11g R2 RAC #4
・VirtualBox de Oracle11g R2 RAC #5
・VirtualBox de Oracle11g R2 RAC #6
・VirtualBox de Oracle11g R2 RAC #7
・VirtualBox de Oracle11g R2 RAC #8
・VirtualBox de Oracle11g R2 RAC #9
・VirtualBox de Oracle11g R2 RAC #10

VirtualBox de Oracle11g R2 RAC #7

VirtualBox de Oracle11g R2 RACのつづきです。

前回に引き続き、Oracle RACの各ノードでiSCSIボリュームの構成です。前回は各ノードからiSCSI targetへ自動接続するまででした。
今回は、そのつづき。各ノードで接続したiSCSI targetにローカルデバイス名をマッピングします。
以前行ったCentOS5.2(x86)内容と同じ手順でのでそちらの記事も参考してくださいね。（今回はマッピングするiSCSI targetが１つ多いだけです！）

1. ハードウェア構成(VMなのでVMの構成も含めて）、ソフトウェア構成など
2. Linux (CentOS 5.5 x86_64)のインストール
3. Openfiler2.3 x86のインストール
4. Openfiler2.3 x86によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. Oracle RACノード間リモートアクセスの構成とntpの構成
   （sshの構成は念のために行った、多分、実施しなくても大丈夫だと思うけど…ついでなので、ちょいと意地悪な実験をしてみた）
9. ローカルネームサーバの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Automatic Storage Management(ASMLib 2.0.5 x84_64)のインストール及び構成
12. Oracle11g R2 11.2.0.1.0 RACインストール事前作業
13. Oracle11g R2 11.2.0.1.0 Grid Infrastractureのインストール
14. Oracle11g R2 11.2.0.1.0 Database softwareのインストール
15. Oracle11g R2 11.2.0.1.0 examplesのインストール
16. Oracle Cluster databaseの作成
17. Net Serviceの確認
18. Oralce Grid InsfastructureとDatabase構成の確認
19. Clusterの開始と停止の確認
20. 簡単なTransparent Application Failover (TAF)の確認

・ローカルデバイス名の作成
以前の記事も参考に。
iSCSIでは再起動／再接続する度にiscsi-targetにマッピングされるSCSIデバイス名が変わってしまうことがあるので、udevでマッピングするデバイス名を固定化します。

前回までの操作がうまく行っていれば、デバイス名のマッピングは異なると思いますがRACを構成する各ノードで以下のようになっているはず。（以下、discus164での例）

[root@discus164 ˜]# (cd /dev/disk/by-path; ls -l *openfiler* | awk '{FS=" "; print $9 " " $10 " " $11}')
ip-192.168.2.92:3260-iscsi-iqn.2006-01.com.openfiler:asm1-lun-0 -> ../../sdb
ip-192.168.2.92:3260-iscsi-iqn.2006-01.com.openfiler:asm2-lun-0 -> ../../sde
ip-192.168.2.92:3260-iscsi-iqn.2006-01.com.openfiler:asm3-lun-0 -> ../../sdc
ip-192.168.2.92:3260-iscsi-iqn.2006-01.com.openfiler:asm4-lun-0 -> ../../sdf
ip-192.168.2.92:3260-iscsi-iqn.2006-01.com.openfiler:crs1-lun-0 -> ../../sdd
ip-192.168.2.92:3260-iscsi-iqn.2006-01.com.openfiler:crs2-lun-0 -> ../../sdg
[root@discus164 ˜]# 

udevを利用してデバイス名をiscsi-targetに固定割当する。（RACの全ノードのrootユーザで実施）

[root@discus164 ˜]# 
[root@discus164 ˜]# cat /etc/udev/rules.d/55-openiscsi.rules
KERNEL=="sd*", BUS=="scsi", PROGRAM="/etc/udev/scripts/iscsidev.sh %b",SYMLINK+="iscsi/%c/part%n"
[root@discus164 ˜]# 
[root@discus164 ˜]# 
[root@discus164 ˜]# 
[root@discus164 ˜]# cd /etc/udev/scripts
[root@discus164 scripts]# cat iscsidev.sh
#!/bin/sh

# FILE: /etc/udev/scripts/iscsidev.sh

BUS=${1}
HOST=${BUS%%:*}
[ -e /sys/class/iscsi_host ] || exit 1

file="/sys/class/iscsi_host/host${HOST}/device/session*/iscsi_session*/targetname"

target_name=$(cat ${file})

# This is not an open-scsi drive
if [ -z "${target_name}" ]; then
   exit 1
fi

echo "${target_name##*.}"
[root@discus164 scripts]# 
[root@discus164 scripts]# chmod 755 iscsidev.sh
[root@discus164 scripts]# 
[root@discus164 scripts]# cd
[root@discus164 ˜]# 
[root@discus164 ˜]# 
[root@discus164 ˜]# service iscsi stop
Logging out of session [sid: 1, target: iqn.2006-01.com.openfiler:asm1, portal: 192.168.2.92,3260]
Logging out of session [sid: 2, target: iqn.2006-01.com.openfiler:asm2, portal: 192.168.2.92,3260]
Logging out of session [sid: 3, target: iqn.2006-01.com.openfiler:asm4, portal: 192.168.2.92,3260]
Logging out of session [sid: 4, target: iqn.2006-01.com.openfiler:crs2, portal: 192.168.2.92,3260]
Logging out of session [sid: 5, target: iqn.2006-01.com.openfiler:asm3, portal: 192.168.2.92,3260]
Logging out of session [sid: 6, target: iqn.2006-01.com.openfiler:crs1, portal: 192.168.2.92,3260]
Logout of [sid: 1, target: iqn.2006-01.com.openfiler:asm1, portal: 192.168.2.92,3260]: successful
Logout of [sid: 2, target: iqn.2006-01.com.openfiler:asm2, portal: 192.168.2.92,3260]: successful
Logout of [sid: 3, target: iqn.2006-01.com.openfiler:asm4, portal: 192.168.2.92,3260]: successful
Logout of [sid: 4, target: iqn.2006-01.com.openfiler:crs2, portal: 192.168.2.92,3260]: successful
Logout of [sid: 5, target: iqn.2006-01.com.openfiler:asm3, portal: 192.168.2.92,3260]: successful
Logout of [sid: 6, target: iqn.2006-01.com.openfiler:crs1, portal: 192.168.2.92,3260]: successful
Stopping iSCSI daemon: 
[root@discus164 ˜]#                                        [  OK  ]
[root@discus164 ˜]# 
[root@discus164 ˜]# service iscsi start
iscsid が停止していますが PID ファイルが残っています
Starting iSCSI daemon:                                     [  OK  ]
                                                           [  OK  ]
iSCSI ターゲットを設定中: Logging in to [iface: default, target: iqn.2006-01.com.openfiler:asm1, portal:
192.168.2.92,3260]
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:asm2, portal: 192.168.2.92,3260]
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:asm4, portal: 192.168.2.92,3260]
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:crs2, portal: 192.168.2.92,3260]
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:asm3, portal: 192.168.2.92,3260]
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:crs1, portal: 192.168.2.92,3260]
Login to [iface: default, target: iqn.2006-01.com.openfiler:asm1, portal: 192.168.2.92,3260]: successful
Login to [iface: default, target: iqn.2006-01.com.openfiler:asm2, portal: 192.168.2.92,3260]: successful
Login to [iface: default, target: iqn.2006-01.com.openfiler:asm4, portal: 192.168.2.92,3260]: successful
Login to [iface: default, target: iqn.2006-01.com.openfiler:crs2, portal: 192.168.2.92,3260]: successful
Login to [iface: default, target: iqn.2006-01.com.openfiler:asm3, portal: 192.168.2.92,3260]: successful
Login to [iface: default, target: iqn.2006-01.com.openfiler:crs1, portal: 192.168.2.92,3260]: successful
                                                           [  OK  ]
[root@discus164 ˜]# 
[root@discus164 ˜]# 

再接続すると各ISCSIターゲットがマッピングされているSCSIデバイス名が前回と違っているのに気づくと思います。

[root@discus164 ˜]#
[root@discus164 ˜]# (cd /dev/disk/by-path; ls -l *openfiler* | awk '{FS=" "; print $9 " " $10 " " $11}')
ip-192.168.2.92:3260-iscsi-iqn.2006-01.com.openfiler:asm1-lun-0 -> ../../sdb
ip-192.168.2.92:3260-iscsi-iqn.2006-01.com.openfiler:asm2-lun-0 -> ../../sdc
ip-192.168.2.92:3260-iscsi-iqn.2006-01.com.openfiler:asm3-lun-0 -> ../../sdg
ip-192.168.2.92:3260-iscsi-iqn.2006-01.com.openfiler:asm4-lun-0 -> ../../sdd
ip-192.168.2.92:3260-iscsi-iqn.2006-01.com.openfiler:crs1-lun-0 -> ../../sdf
ip-192.168.2.92:3260-iscsi-iqn.2006-01.com.openfiler:crs2-lun-0 -> ../../sde
[root@discus164 ˜]# 
[root@discus164 ˜]#

udevでiSCSIターゲットがローカルデバイスへ固定マッピングできているか確認！
うまくいってます。RACの全ノードで同じローカルデバイスへマッピングできています。

が、しか〜〜し、記事書いてて気づいたけど ":"入っちゃってた (^^;;; そゆーところはまねしないでね。
狙いとしては ":"入れるつもりはなかったっす！。ミスった〜。
今回、iSCSIターゲット名をちょっと変えてしまったので、以前から流用しているiscsidev.shスクリプトの最後の行　

echo "${target_name##*.}"

のところがイケてない＞＜　今回設定したiSCSIターゲット名だと

echo "${target_name#*:}"

しないと asm1やasm2だけを抜き出せない　＞＜
記載したiscsidev.shスクリプトをそのまま利用するのであれば、IQNは、iqn.2006-01.com.openfiler:xxx.asm1のように設定する必要があります！

そー作っちゃったのでそのまま載せときます。　(^^;;;;;;

[root@discus164 ˜]# ls -l /dev/iscsi/*/*
lrwxrwxrwx 1 root root  9 12月 17 22:36 /dev/iscsi/openfiler:asm1/part -> ../../sdb
lrwxrwxrwx 1 root root  9 12月 17 22:36 /dev/iscsi/openfiler:asm2/part -> ../../sdc
lrwxrwxrwx 1 root root  9 12月 17 22:36 /dev/iscsi/openfiler:asm3/part -> ../../sdg
lrwxrwxrwx 1 root root  9 12月 17 22:36 /dev/iscsi/openfiler:asm4/part -> ../../sdd
lrwxrwxrwx 1 root root  9 12月 17 22:36 /dev/iscsi/openfiler:crs1/part -> ../../sdf
lrwxrwxrwx 1 root root  9 12月 17 22:36 /dev/iscsi/openfiler:crs2/part -> ../../sde
[root@discus164 ˜]#
[root@discus164 ˜]#

ということで、当初の設定予定とは違うローカルデバイス名にしちゃいましたがiSCSIとローカルデバイスは以下のようにマッピングしました。

iscsi-targetとローカルデバイス名の対応
iscsi-target名	ローカルデバイス名
iqn.2006-01.com.openfiler:asm1	/dev/iscsi/openfiler:asm1/part
iqn.2006-01.com.openfiler:asm2	/dev/iscsi/openfiler:asm2/part
iqn.2006-01.com.openfiler:asm3	/dev/iscsi/openfiler:asm3/part
iqn.2006-01.com.openfiler:asm4	/dev/iscsi/openfiler:asm4/part
iqn.2006-01.com.openfiler:crs1	/dev/iscsi/openfiler:crs1/part
iqn.2006-01.com.openfiler:crs2	/dev/iscsi/openfiler:crs2/part

でもほんとは以下のようなローカルデバイス名にしたかったんです〜〜。ごめんなさい。

[root@discus164 ˜]# ls -l /dev/iscsi/*/*
lrwxrwxrwx 1 root root  9 12月 17 22:36 /dev/iscsi/asm1/part -> ../../sdb
lrwxrwxrwx 1 root root  9 12月 17 22:36 /dev/iscsi/asm2/part -> ../../sdc
lrwxrwxrwx 1 root root  9 12月 17 22:36 /dev/iscsi/asm3/part -> ../../sdg
lrwxrwxrwx 1 root root  9 12月 17 22:36 /dev/iscsi/asm4/part -> ../../sdd
lrwxrwxrwx 1 root root  9 12月 17 22:36 /dev/iscsi/crs1/part -> ../../sdf
lrwxrwxrwx 1 root root  9 12月 17 22:36 /dev/iscsi/crs2/part -> ../../sde
[root@discus164 ˜]#

いやな間違いに気づいたので、今日はこの辺で…　(RAC自体で作れたんですけど、気持ち悪いので）

---

これまでのあらすじ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

・VirtualBox de RAC (Oracle11g R1編） #1
・VirtualBox de RAC (Oracle11g R1編） #2

---

・VirtualBox de Oracle11g R2 RAC #1
・VirtualBox de Oracle11g R2 RAC #2 - 事前調査など…
・VirtualBox de Oracle11g R2 RAC #3
・VirtualBox de Oracle11g R2 RAC #4
・VirtualBox de Oracle11g R2 RAC #5
・VirtualBox de Oracle11g R2 RAC #6

多すぎるのはいかがな物かと。

少々間が空いてしまいましたが、久々にvirtualな世界の話じゃないネタ。

バッファキャッシュや共有プールに何も乗っかってない時と乗った後って、パーティションがどんだけあるかっていうことが、再帰コールとかconsistent getsとかphysical readsとかにも影響あるよね〜という確認。

どんなこと試したかっていうと…、
非パーティション表、５０パーティション、１００パーティション、５００パーティション、１０００パーティション、５０００パーティション、１００００パーティションの各パーティション表に対して、INSERT文を実行した場合どれだけ再帰コールなどが行われるのか確かめてみた。

前提
・初回のINSERT文実行前に共有プール、バッファキャッシュをクリアする。
・INSERTを３回実行する。
・deferred_segment_creation初期化パラメータは一時的にfalseにしておく。

まずは結果からどうぞ。consistent getsやphysical readsは再帰コールと同じ傾向があった。予想通り。

１回目だけ前述の再帰コール等が高くなる。これまた予想通り。まあこんなもんでしょうね。という確認でした。以下、１００００パーティションで試した結果。

以下、ついでにいくつか確認した事のログ :)

SYS> show parameter deferred

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
deferred_segment_creation            boolean     TRUE


SYS> alter system set deferred_segment_creation=false scope=memory;

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

SYS> show parameter deferred

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
deferred_segment_creation            boolean     FALSE

SYS> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

SYS> 

SCOTT> desc test        
 名前                        NULL?    型
 --------------------------- -------- ---------------------------
 COL1                        NOT NULL CHAR(4)
 COL2                        NOT NULL CHAR(8)
 COL3                        NOT NULL CHAR(10)
 COL4                        NOT NULL VARCHAR2(20)
 COL5                        NOT NULL CHAR(7)


SCOTT> select table_name,count(*) "num of partitions" from user_tab_partitions where table_name='TEST' group by table_name;

TABLE_NAME                     num of partitions
------------------------------ -----------------
TEST                                       10000

SCOTT> set timi on
SCOTT> alter system flush buffer_cache;

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

経過: 00:00:00.04
SCOTT>  alter system flush shared_pool;

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

経過: 00:00:00.13
SCOTT> set autot trace exp stat
SCOTT> insert into test values('0001','12345678','0000123456','00001234560123456789','000001');

1行が作成されました。

経過: 00:00:01.02

実行計画
----------------------------------------------------------

-------------------------------------------------------------------------
| Id  | Operation                | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | INSERT STATEMENT         |      |     1 |     1   (0)| 00:00:01 |
|   1 |  LOAD TABLE CONVENTIONAL | TEST |       |            |          |
-------------------------------------------------------------------------


統計
----------------------------------------------------------
     242080  recursive calls
          7  db block gets
      40908  consistent gets
        648  physical reads
       3000  redo size
       1180  bytes sent via SQL*Net to client
       1331  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
         52  sorts (memory)
          0  sorts (disk)
          1  rows processed

SCOTT> insert into test values('0009','12345678','0000123456','00001234560123456789','000001');

1行が作成されました。

経過: 00:00:00.01

実行計画
----------------------------------------------------------

-------------------------------------------------------------------------
| Id  | Operation                | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | INSERT STATEMENT         |      |     1 |     1   (0)| 00:00:01 |
|   1 |  LOAD TABLE CONVENTIONAL | TEST |       |            |          |
-------------------------------------------------------------------------


統計
----------------------------------------------------------
         32  recursive calls
         39  db block gets
          4  consistent gets
          7  physical reads
       2820  redo size
       1179  bytes sent via SQL*Net to client
       1331  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          1  rows processed

SCOTT> insert into test values('0010','12345678','0000123456','00001234560123456789','000001');

1行が作成されました。

経過: 00:00:00.02

実行計画
----------------------------------------------------------

-------------------------------------------------------------------------
| Id  | Operation                | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | INSERT STATEMENT         |      |     1 |     1   (0)| 00:00:01 |
|   1 |  LOAD TABLE CONVENTIONAL | TEST |       |            |          |
-------------------------------------------------------------------------


統計
----------------------------------------------------------
          1  recursive calls
         39  db block gets
          2  consistent gets
          6  physical reads
       2820  redo size
       1180  bytes sent via SQL*Net to client
       1331  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          1  rows processed

インサート後にupdateをしてみたが、shared_poolクリア後のようなrecursible callsの多さはない。

SCOTT> update test set code5='0000000' where code1='0010' and code2='0000123456';
<

0行が更新されました。

経過: 00:00:00.02

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

-----------------------------------------------------------------------------
| Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | UPDATE STATEMENT  |         |     1 |    25 |     0   (0)| 00:00:01 |
|   1 |  UPDATE           | TEST    |       |       |            |          |
|*  2 |   INDEX RANGE SCAN| TEST_PK |     1 |    25 |     0   (0)| 00:00:01 |
-----------------------------------------------------------------------------

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

   2 - access("CODE1"='0010' AND "CODE2"='0000123456')


統計
----------------------------------------------------------
        124  recursive calls
          0  db block gets
         18  consistent gets
          3  physical reads
          0  redo size
       1180  bytes sent via SQL*Net to client
       1326  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          0  rows processed

同じことをバッファキャッシュ、共有プールクリア後にやってみると…やはり、同程度のrecursible callsの回数になる。

SCOTT> alter system flush buffer_cache;

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

経過: 00:00:00.06
SCOTT> alter system flush shared_pool;

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

経過: 00:00:00.13
SCOTT> update test set code5='0000000' where code1='0010' and code2='0000123456';

0行が更新されました。

経過: 00:00:00.98

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

-----------------------------------------------------------------------------
| Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | UPDATE STATEMENT  |         |     1 |    25 |     0   (0)| 00:00:01 |
|   1 |  UPDATE           | TEST    |       |       |            |          |
|*  2 |   INDEX RANGE SCAN| TEST_PK |     1 |    25 |     0   (0)| 00:00:01 |
-----------------------------------------------------------------------------

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

   2 - access("CODE1"='0010' AND "CODE2"='0000123456')


統計
----------------------------------------------------------
     242492  recursive calls
          0  db block gets
      40980  consistent gets
        650  physical reads
          0  redo size
       1180  bytes sent via SQL*Net to client
       1326  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
         41  sorts (memory)
          0  sorts (disk)
          0  rows processed

ようするにディクショナリキャッシュに該当オブジェクトのディクショナリ情報が乗ったということなんだろうねぇ。
insert文を実行してみるとrecursible callsは多少あるもののそれほど多いくはない。おそらくハードパースの影響だけなんだろう。

SCOTT> insert into test values('0011','12345678','0000123456','00001234560123456789','000001');

1行が作成されました。

経過: 00:00:00.08

実行計画
----------------------------------------------------------

-------------------------------------------------------------------------
| Id  | Operation                | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | INSERT STATEMENT         |      |     1 |     1   (0)| 00:00:01 |
|   1 |  LOAD TABLE CONVENTIONAL | TEST |       |            |          |
-------------------------------------------------------------------------


統計
----------------------------------------------------------
         32  recursive calls
         39  db block gets
          4  consistent gets
          7  physical reads
       2884  redo size
       1180  bytes sent via SQL*Net to client
       1331  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          1  rows processed

VirtualBox de RAC (Oracle11g R1編）#2

VirtualBox de RAC (Oracle11g R1編）の続きです。
試していて気付いた問題点やハマった点が幾つかあったので備忘録として残しておきますね。

まず最初はCentOS5.5でのiscsidの問題。

この問題、iscsiデバイスを利用しているCentOS5.5をshutdown/rebootすると停止時に以下のようなメッセージを表示した後、いきなりHALTしてしまう。Openfiler側が起動しっぱなりしの場合は、大量のゾンビセッションが残ってしまい 気付かないと大変なことになってしまうという、なかなかスリリングな事象なのでご用心を。

私の場合、停止時のエラーメッセージに気付き、Openfiler側のセッションがゾンビだらけで驚いた！〜っていうとこで気付いた。

ググってみたら、これは、Red hat Linux/CentOS 5.5でのバグということが判明。
暫定的な対処方法はいつくかあるが、私の環境では、/etc/init.d/iscsiを書き換え、run level 0/1/6でなにもしないで抜ける部分をコメントアウトして対処した。

ちなみに、run level 0/1/6以外ならiscsiは正しく動作してます。以下、stop/startで正しくiscsiが実行されてLogout/Logonが成功している状態。

[root@discus164  ˜]# service iscsi stop
Logging out of session [sid: 1, target: iqn.2006-01.com.openfiler:asm1, portal: 192.168.2.92,3260]
Logging out of session [sid: 2, target: iqn.2006-01.com.openfiler:asm2, portal: 192.168.2.92,3260]
Logging out of session [sid: 3, target: iqn.2006-01.com.openfiler:asm4, portal: 192.168.2.92,3260]
Logging out of session [sid: 4, target: iqn.2006-01.com.openfiler:crs2, portal: 192.168.2.92,3260]
Logging out of session [sid: 5, target: iqn.2006-01.com.openfiler:asm3, portal: 192.168.2.92,3260]
Logging out of session [sid: 6, target: iqn.2006-01.com.openfiler:crs1, portal: 192.168.2.92,3260]
Logout of [sid: 1, target: iqn.2006-01.com.openfiler:asm1, portal: 192.168.2.92,3260]: successful
Logout of [sid: 2, target: iqn.2006-01.com.openfiler:asm2, portal: 192.168.2.92,3260]: successful
Logout of [sid: 3, target: iqn.2006-01.com.openfiler:asm4, portal: 192.168.2.92,3260]: successful
Logout of [sid: 4, target: iqn.2006-01.com.openfiler:crs2, portal: 192.168.2.92,3260]: successful
Logout of [sid: 5, target: iqn.2006-01.com.openfiler:asm3, portal: 192.168.2.92,3260]: successful
Logout of [sid: 6, target: iqn.2006-01.com.openfiler:crs1, portal: 192.168.2.92,3260]: successful
Stopping iSCSI daemon: 
[root@discus164  ˜]# service iscsi start
iscsid が停止していますが PID ファイルが残っています
Starting iSCSI daemon:                                     [  OK  ]
                                                           [  OK  ]
iSCSI ターゲットを設定中: Logging in to [iface: default, target: iqn.2006-01.com.openfiler:asm1, portal: 192.168.2.92,3260]
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:asm2, portal: 192.168.2.92,3260]
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:asm4, portal: 192.168.2.92,3260]
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:crs2, portal: 192.168.2.92,3260]
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:asm3, portal: 192.168.2.92,3260]
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:crs1, portal: 192.168.2.92,3260]
Login to [iface: default, target: iqn.2006-01.com.openfiler:asm1, portal: 192.168.2.92,3260]: successful
Login to [iface: default, target: iqn.2006-01.com.openfiler:asm2, portal: 192.168.2.92,3260]: successful
Login to [iface: default, target: iqn.2006-01.com.openfiler:asm4, portal: 192.168.2.92,3260]: successful
Login to [iface: default, target: iqn.2006-01.com.openfiler:crs2, portal: 192.168.2.92,3260]: successful
Login to [iface: default, target: iqn.2006-01.com.openfiler:asm3, portal: 192.168.2.92,3260]: successful
Login to [iface: default, target: iqn.2006-01.com.openfiler:crs1, portal: 192.168.2.92,3260]: successful
                                                           [  OK  ]
[root@discus164  ˜]# 

この場合はなんの問題もないわけです。が…

ところが、対処前のCentOS5.5では、shutdown/reboot時に以下のログが表示されLogoutできずOpenfiler側のセッションがゾンビ化する。

Unmounting pipe file systems:                              [  OK  ]
 connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4300342437, last ping 4300347437, now 4300352437
 connection2:0: detected conn error (1011)
 connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4300342437, last ping 4300347437, now 4300352439
 connection1:0: detected conn error (1011)
 connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4300342437, last ping 4300347437, now 4300352449
 connection4:0: detected conn error (1011)
 connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4300342437, last ping 4300347437, now 4300352463
 connection3:0: detected conn error (1011)
 connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4300342437, last ping 4300347437, now 4300352472
 connection5:0: detected conn error (1011)
 connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4300342437, last ping 4300347437, now 4300352474
 connection6:0: detected conn error (1011)
Unmounting file systems:                                   [  OK  ]
Halting system...

スクリーンショットは以下

前述の問題の対処として/etc/init.d/iscsiを修正する方法を選択した。diffは以下のとおり。

[root@discus164 ˜]# diff -u /etc/init.d/iscsi.org /etc/init.d/iscsi
--- /etc/init.d/iscsi.org   2010-03-31 22:26:39.000000000 +0900
+++ /etc/init.d/iscsi       2010-10-31 01:33:12.000000000 +0900
@@ -35,10 +35,10 @@

        # If this is a final shutdown/halt, do nothing since
        # lvm/dm, md, power path, etc do not always handle this
-       if [ "$RUNLEVEL" = "6" -o "$RUNLEVEL" = "0" -o "$RUNLEVEL" = "1" ]; then
-               success
-               return
-       fi
+       #if [ "$RUNLEVEL" = "6" -o "$RUNLEVEL" = "0" -o "$RUNLEVEL" = "1" ]; then
+       #       success
+       #       return
+       #fi

        # don't turn off iscsi if root is possibly on a iscsi disk
        rootopts=$(awk '{ if ($1 !˜ /^[ \t]*#/ && $2 == "/") { print $4; }}' /etc/mtab)

修正後は以下のとおり問題なくiscsiのセッションがlogoutされている ;)

参考：

Stray Penguin - Linux Memo (iSCSi) - シャットダウン/リブート時のSCSI cache エラー
Red Hat Bugzilla – Bug 583218

---

これまでのあらずじ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

・VirtualBox de RAC (Oracle11g R1編） #1

Mac de Oracle - １０万円未満 de RAC (11g編）改め、 VirtualBox de RAC (Oracle11g R1編） #1

いままでいろいろと遊んでいたPCやうちの奥さんのPCがじゃまになってきたのでCore i7 980x (6 core / ハイパースレッディングを使って12CPU）というやつ１台に集約！。

さすがに"１０万円未満 de"はとは言えなくなった(購入金額をVM数で割ってもちょいと足がでるが、電気代とか占有スペースとか必要に応じてVM作って遊べるのでお得だ。）ので、VirtualBox de RACと改名いたしましたw

とは言っても、Oracle11g R1 EE for Linux x86でiSCSIを使うというのは同じで、違うのは全部VMっていうところだけ。
手順もMac de Oracle - １０万円未満 de RAC (11g編）と同じ（OCFS2やASMlibのバージョンはCentOSのバージョンに対応する最新のものを利用しています。）なのでVM使ってて悩んだ所などを中心に書く予定。

・CPU - Intel Core i7-980X Extreme Edition 3.33Ghz (6 core / 12 thread) * 1
・Memory - 12GB (2GB * 6)
・Disk - S-ATA2 1TB * 2
・NIC - on board Gbit NIC
グラフィックカードは気にしてなかったので安めの、 NVIDIA GeForce GTS 250 (512MB)

ソフトウェアは以下の通り。

ホストOS等
・CentOS5.5 x86_64 (Kernel:2.6.18-194.17.1.e15)
・VirtualBox3.2.8 x86_64

ゲストOS等
・CentOS5.5 x86 (kernel:2.6.18-194.17.1.e15PAE)
・Openfiler2.3 x86
・Oracle11g 11.1.0.6.0 EE for Linux x86
　など…

以下、適当に書いた配置図。
VNICの設定では、外部ネットワークにも行けるようにBridge Adapterを使ったこととInterconnect向けにInternal Networkを使った（VirtualBoxのInternal NetworkはGestOS間でのみ通信できHostOSからも見えない）

という案で、VMごとクラッシュさせたりいろいろ悩みながらなんとかインスコ＆構築done。現在は以下ような状態！ :)

次回へつづく。

---

関連エントリ
・Mac de Oracle - １０万円未満 de RAC (11g編）#28

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #8

前回の続きです。pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2も今回で一旦終了。

今回は、最後に残った、Oracle11g EE R2 11.2.0.1.0 for Linux x86-64で再確認。64bit版のOracle11g R21と同じ結果になるに違いねぇ。とまた、決めつけてるw

SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

SQL> show parameter pga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 100M
SQL> 
SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_ldr_pga_lim                   0                              TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_pgactx_cap_stacks             FALSE                          TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           104857600                      FALSE

9行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                            100
aggregate PGA auto target                          58.6582031
global memory bound                                        20

SQL>

pga_aggregate_targetを10MB/50MB/1GB/5GB/10GB/100GB/4095GBと、いつものように増加させながらv$pgastatビューのGlobal memory boundでpgaサイズを確認してみます！

SQL> alter system set pga_aggregate_target=10m;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_ldr_pga_lim                   0                              TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_pgactx_cap_stacks             FALSE                          TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           10485760                       FALSE

9行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                             10
aggregate PGA auto target                                   4
global memory bound                                         2

SQL> alter system set pga_aggregate_target=50m;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_ldr_pga_lim                   0                              TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_pgactx_cap_stacks             FALSE                          TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           52428800                       FALSE

9行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                             50
aggregate PGA auto target                          13.6582031
global memory bound                                        10

SQL> alter system set pga_aggregate_target=1g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_ldr_pga_lim                   0                              TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  214732800                      TRUE
_pgactx_cap_stacks             FALSE                          TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           1073741824                     FALSE

9行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                           1024
aggregate PGA auto target                          890.314453
global memory bound                                102.392578

SQL> alter system set pga_aggregate_target=5g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_ldr_pga_lim                   0                              TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  1073725440                     TRUE
_pgactx_cap_stacks             FALSE                          TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           5368709120                     FALSE

9行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                           5120
aggregate PGA auto target                          4576.67578
global memory bound                                511.992188

SQL> alter system set pga_aggregate_target=10g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_ldr_pga_lim                   0                              TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  2147471360                     TRUE
_pgactx_cap_stacks             FALSE                          TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           10737418240                    FALSE

9行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                          10240
aggregate PGA auto target                          9184.63184
global memory bound                                1023.99414

SQL> alter system set pga_aggregate_target=100g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_ldr_pga_lim                   0                              TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  2147483648                     TRUE
_pgactx_cap_stacks             FALSE                          TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           107374182400                   FALSE

9行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                         102400
aggregate PGA auto target                           92126.127
global memory bound                                      1024

SQL> alter system set pga_aggregate_target=4095g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_ldr_pga_lim                   0                              TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  2147483648                     TRUE
_pgactx_cap_stacks             FALSE                          TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           4396972769280                  FALSE

9行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                        4193280
aggregate PGA auto target                           3773909.9
global memory bound                                      1024

SQL> 

結果は、予想通り、Oracle11g EE R1 11.1.0.7.0 for Linux x86-64と全く同じでした〜

やっと、もやもやしてたOracle10g R2以降のpga回りの動きが掴めたので、ゆっくーり、寝れそうw　（ほんとうはパラレル版もやりたいけど〜それはまた。）

---

前回までのあらすじ・・・
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #2
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #16
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #17
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #18
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #19
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。シーズン２
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #2
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #3
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #4
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #5
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #6
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #7

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #7

前回の続きです。

今回は、Oracle11g EE R2 11.2.0.1.0 for Linux x86で再確認。32bit版です。32bit版のOracle11g R1と同じ結果になるに違いねぇ。（決めつけてるw)

SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

SQL> show parameter pga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 100M
SQL> 
SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_ldr_pga_lim                   0                              TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_pgactx_cap_stacks             FALSE                          TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           104857600                      FALSE

9行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                            100
aggregate PGA auto target                          62.5078125
global memory bound                                        20

pga_aggregate_targetを10MB/50MB/1GB/5GB/10GB/100GB/4095GBと、いつものように増加させながらv$pgastatビューのGlobal memory boundでpgaサイズを確認してみます！

SQL> alter system set pga_aggregate_target=10m;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_ldr_pga_lim                   0                              TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_pgactx_cap_stacks             FALSE                          TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           10485760                       FALSE

9行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                             10
aggregate PGA auto target                                   4
global memory bound                                         2

SQL> alter system set pga_aggregate_target=50m;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_ldr_pga_lim                   0                              TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_pgactx_cap_stacks             FALSE                          TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           52428800                       FALSE

9行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                             50
aggregate PGA auto target                            16.59375
global memory bound                                        10

SQL> alter system set pga_aggregate_target=1g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_ldr_pga_lim                   0                              TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  214732800                      TRUE
_pgactx_cap_stacks             FALSE                          TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           1073741824                     FALSE

9行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                           1024
aggregate PGA auto target                          893.197266
global memory bound                                102.392578

SQL> alter system set pga_aggregate_target=5g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_ldr_pga_lim                   0                              TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  1073725440                     TRUE
_pgactx_cap_stacks             FALSE                          TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           5368709120                     FALSE

9行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                           5120
aggregate PGA auto target                          4580.46387
global memory bound                                511.992188

SQL> alter system set pga_aggregate_target=10g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target        134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_ldr_pga_lim                   0                              TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  1073741824                     TRUE
_pgactx_cap_stacks             FALSE                          TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           10737418240                    FALSE

9行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                          10240
aggregate PGA auto target                          9188.41992
global memory bound                                       512

SQL> alter system set pga_aggregate_target=100g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_ldr_pga_lim                   0                              TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  1073741824                     TRUE
_pgactx_cap_stacks             FALSE                          TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           107374182400                   FALSE

9行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                         102400
aggregate PGA auto target                          92130.6797
global memory bound                                       512

SQL> alter system set pga_aggregate_target=4095g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_ldr_pga_lim                   0                              TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  1073741824                     TRUE
_pgactx_cap_stacks             FALSE                          TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           4396972769280                  FALSE

9行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                        4193280
aggregate PGA auto target                          3773915.44
global memory bound                                       512

SQL> 

結果は、予想通り、Oracle11g EE R1 11.1.0.7.0 for Linux x86と全く同じでした〜

次回、Oracle11g R2 64bit版へつづく。

---

前回までのあらすじ・・・
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #2
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #16
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #17
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #18
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #19
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。シーズン２
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #2
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #3
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #4
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #5
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #6

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #6

前回の続きです。

今回は、Oracle11g EE R1 11.1.0.7.0 for Linux x86-64で再確認してみます。前回は、32bit版でしたが今回は同バージョンの64bit版です。何か違いがあるでしょうか？（多分、Oracle10g R2 MacOS X x86-64と同じなんじゃないかと予想してます。）

SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
PL/SQL Release 11.1.0.7.0 - Production
CORE    11.1.0.7.0      Production
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production

SQL> show parameter pga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 100M
SQL> 
SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           104857600                      FALSE

7行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                            100
aggregate PGA auto target                          57.7529297
global memory bound                                        20

pga_aggregate_targetを10MB/50MB/1GB/5GB/10GB/100GB/4095GBと、いつものように増加させながらv$pgastatビューのGlobal memory boundでpgaサイズを確認してみます！

SQL> alter system set pga_aggregate_target=10m;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           10485760                       FALSE

7行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                             10
aggregate PGA auto target                                   4
global memory bound                                         2

SQL> alter system set pga_aggregate_target=50m;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           52428800                       FALSE

7行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                             50
aggregate PGA auto target                          12.7177734
global memory bound                                        10

SQL> alter system set pga_aggregate_target=1g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  214732800                      TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           1073741824                     FALSE

7行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                           1024
aggregate PGA auto target                            889.3125
global memory bound                                102.392578

SQL> alter system set pga_aggregate_target=5g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  1073725440                     TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           5368709120                     FALSE

7行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                           5120
aggregate PGA auto target                          4575.68262
global memory bound                                511.992188

SQL> alter system set pga_aggregate_target=10g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  2147471360                     TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           10737418240                    FALSE

7行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                          10240
aggregate PGA auto target                          9183.62988
global memory bound                                1023.99414

SQL> alter system set pga_aggregate_target=100g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  2147483648                     TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           107374182400                   FALSE

7行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                         102400
aggregate PGA auto target                          92126.0039
global memory bound                                      1024

SQL> alter system set pga_aggregate_target=4095g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  2147483648                     TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           4396972769280                  FALSE

7行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                        4193280
aggregate PGA auto target                          3773910.37
global memory bound                                      1024

SQL> 

結果は、予想通り、Oracle10g EE R2 10.2.0.4.0 for MacOS X x86-64と全く同じ。:)

次回、Oracle11g R2 32bit版へつづく。

---

前回までのあらすじ・・・
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #2
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #16
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #17
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #18
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #19
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。シーズン２
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #2
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #3
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #4
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #5

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #5

前回の続きです。

今回は、Oracle11g EE R1 11.1.0.7.0 for Linux x86で再確認してみます。前回は、64bitのOracle10g R2でしたが今回は32bitのOracle11g R1です。さて何か違いがあるでしょうか？

SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
PL/SQL Release 11.1.0.7.0 - Production
CORE    11.1.0.7.0      Production
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production

SQL> show parameter pga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 100M
SQL> 
SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           104857600                      FALSE

7行が選択されました。

pga_aggregate_targetを10MB/50MB/1GB/5GB/10GB/100GB/4095GBと、いつものように増加させながらv$pgastatビューのGlobal memory boundでpgaサイズを確認してみます！

SQL> alter system set pga_aggregate_target=10m;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           10485760                       FALSE

7行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                             10
aggregate PGA auto target                                   4
global memory bound                                         2

SQL> alter system set pga_aggregate_target=50m;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           52428800                       FALSE

7行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                             50
aggregate PGA auto target                          10.7929688
global memory bound                                        10

SQL> alter system set pga_aggregate_target=1g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  214732800                      TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           1073741824                     FALSE

7行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                           1024
aggregate PGA auto target                          895.368164
global memory bound                                102.392578

SQL> alter system set pga_aggregate_target=5g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  1073725440                     TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           5368709120                     FALSE

7行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                           5120
aggregate PGA auto target                          4581.67676
global memory bound                                511.992188

SQL> alter system set pga_aggregate_target=10g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  1073741824                     TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           10737418240                    FALSE

7行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                          10240
aggregate PGA auto target                            9190.125
global memory bound                                       512

SQL> alter system set pga_aggregate_target=100G;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  1073741824                     TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           107374182400                   FALSE

7行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                         102400
aggregate PGA auto target                          92132.8242
global memory bound                                       512

SQL> alter system set pga_aggregate_target=4095g;

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

SQL> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ------------------------------
__pga_aggregate_target         134217728                      FALSE
_kdli_sio_pga                  FALSE                          TRUE
_kdli_sio_pga_top              FALSE                          TRUE
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  1073741824                     TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           4396972769280                  FALSE

7行が選択されました。

SQL> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                        4193280
aggregate PGA auto target                          3773917.11
global memory bound                                       512

SQL> 

お〜っ！。　Oracle10g R2のように_pga_max_sizeが自動調整されて増加しているのがわかります。ただ、Oracle10g R2 (64bit)と割当ルールはほぼ同じなようなのですが、１箇所だけ違うようですね。
それは 自動調整される　_pga_max_sizeの上限値が、512MBであること。Oracle10g R2 (64bit)では、1GBまで増加したはず！。

このエントリに載せていない確認内容も含めてまとめると…

1. Oracle11g R1(32bit)で_pga_max_sizeの値が、1000MBを超えると動的に変化し始める。
   - Oracle10g R2 (64bit)と同じ。


2. pga_aggregate_targetが1GB近くまでだと、pga_aggregate_targetの20%。
   - Oracle10g R2 (64bit)と同じ。


3. pga_aggregate_targetが1GB以上になると、_pga_max_sizeが、pga_aggregate_targetの19.999%程度の値に自動設定され、さらにその値の50%。結果的として、pga_aggregate_target値の10%をほんの少し下回る値が設定される。pga_aggregate_targetが5GBである場合、512MBをほんの少し下回るのサイズがpgaとして割り当てられる。


4. pga_aggretate_targetが5GBを超えた場合、_pga_max_sizeが1GBで頭打ちとなり、結果的として512MBがPGAとして割り当てられる。つまり自動PGA管理における最大PGAサイズは512MBということになる。(32bit版ではね）

---

前回までのあらすじ・・・
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #2
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #16
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #17
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #18
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #19
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。シーズン２
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #2
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #3
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #4

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #4

Oracle10g R2 EE 10.2.0.4.0 for MacOS X x86-64で再確認の続き。

pga_aggregate_targetがどの程度になると、_pga_max_sizeが200MBをこえるんでしょうねぇ。調べてみましょう。わくわくです。

SYS> alter system set pga_aggregate_target=150m;

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

SYS> 
SYS> @show_hidden_pga_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       209715200		      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       157286400		      FALSE

SYS> alter system set pga_aggregate_target=200m;

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

SYS> @show_hidden_pga_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       209715200		      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       209715200		      FALSE

SYS> alter system set pga_aggregate_target=500m;

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

SYS> @show_hidden_pga_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       209715200		      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       524288000		      FALSE

SYS> alter system set pga_aggregate_target=1023m;

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

SYS> @show_hidden_pga_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       214528000		      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       1072693248		      FALSE

SYS> alter system set pga_aggregate_target=1010m;

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

SYS> @show_hidden_pga_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       211804160		      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       1059061760		      FALSE

SYS> alter system set pga_aggregate_target=1000m;

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

SYS> @show_hidden_pga_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       209715200		      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       1048576000		      FALSE

SYS> alter system set pga_aggregate_target=1001m;

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

SYS> @show_hidden_pga_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       209920000		      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       1049624576		      FALSE

SYS> 

ということで、pga_aggreate_target=1000MBまでは、元々の値である200MBを維持しているようです。
1001MB以上で、_pga_max_sizeの値が動的に変化し始め、実際の値は、pga_aggregate_targetの19.999%程度になるようです。
丸めてしまえば、pga_aggregate_targetの20%なので、pga_aggregate_targetが1001MB以上の場合、その値の20%が、_pga_max_sizeに設定されるとしちゃっても特に問題ないかもしれませんけどね。

前回の結果も含めてまとめると、

1. Oracle10g R2になると、10g R1までとは異なり_pga_max_sizeの値が、1000MBを超えると動的に変化し始める。
2. pga_aggregate_targetが1GB近くまでだと、pga_aggregate_targetの20%。
3. pga_aggregate_targetが1GB以上になると、_pga_max_sizeが、pga_aggregate_targetの19.999%程度の値に自動設定され、さらにその値の50%。結果的として、pga_aggregate_target値の10%をほんの少し下回る値が設定される。pga_aggregate_targetが10GBである場合、1GBをほんの少し下回るのサイズがpgaとして割り当てられる。
4. pga_aggretate_targetが10GBを超えた場合、_pga_max_sizeが2GBで頭打ちとなり、結果的として1GBがPGAとして割り当てられる。つまり自動PGA管理における最大PGAサイズは1GBということになる。(64bit版ではね）

意図せず、_pga_max_sizeが固定化されてしまっていた以前のテストとは大きく異なる結果となってしまったが、_pga_max_sizeが動的に変化し最大2GBまで増えるってところを除けば仕組みは同じだよね。と :)

次回は、Oracle11g R1 EE 11.1.0.6.0 (x86) 32bit版で同様に再確認。次回へつづく。

---

前回までのあらすじ・・・
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #2
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #16
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #17
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #18
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #19
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。シーズン２
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #2
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #3

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #3

前回でOracle10g R1の再確認は終わり、今回はOracle10g R2 EE 10.2.0.4.0 for MacOS X x86_64で再確認。

pga_aggregate_targetパラメータを10MB/50MB/1GB/5GB/10GB/100GB/4095GBと変化させた場合、pgaに使用されるサイズがどのように変化するかv$pgastatビューのglobal memory boundを見て確認。

_pga_max_sizeパラメータがデフォルト値となっているか確認。問題なさそうですね :)

SYS> 
SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target		     big integer 100M
SYS> 
SYS> @pgastat.sql

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				  100
aggregate PGA auto target			   73.6699219
global memory bound					   20

SYS> @show_hidden_pga_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       209715200		      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       104857600		      FALSE

では、早速、確認してみましょう！

pga_aggregate_targetをどんどん増加させ、あるサイズ以上になると、_pga_max_sizeパラメータが動的に増加し始めます。
これをキッカケにして、global memory boundも増加していき、最終的には、1024MBつまり1GBで頭打ちになります。まあ、ないとはおもいますけど、１セッションで1GBを超えるPGAが必要な場合は、_pga_max_sizeをセットしちゃうか、自動PGA管理をOFFにするんでしょうね。多分後者の方がいいように思いますね。やるなら。(^^:::

SYS> alter system set pga_aggregate_target=10m;

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

SYS> @show_hidden_pga_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       209715200		      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       10485760 		      FALSE

SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				   10
aggregate PGA auto target				    4
global memory bound					    2

SYS> alter system set pga_aggregate_target=50m;

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

SYS> @show_hidden_pga_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       209715200		      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       52428800 		      FALSE

SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				   50
aggregate PGA auto target			   28.6611328
global memory bound					   10

SYS> alter system set pga_aggregate_target=1G;

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

SYS> @show_hidden_pga_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       214732800		      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       1073741824		      FALSE

SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 1024
aggregate PGA auto target			   905.255859
global memory bound				   102.392578

SYS> alter system set pga_aggregate_target=5G;

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

SYS> @show_hidden_pga_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       1073725440		      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       5368709120		      FALSE

SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 5120
aggregate PGA auto target			    4591.6084
global memory bound				   511.992188

SYS> alter system set pga_aggregate_target=10g;

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

SYS> @show_hidden_pga_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       2147471360		      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       10737418240		      FALSE

SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				10240
aggregate PGA auto target			   9199.56445
global memory bound				   1023.99414

SYS> alter system set pga_aggregate_target=100g;

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

SYS> @show_hidden_pga_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       2147483648		      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       107374182400		      FALSE

SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter			       102400
aggregate PGA auto target			   92142.4834
global memory bound					 1024

SYS> alter system set pga_aggregate_target=4095g;

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

SYS> @show_hidden_pga_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       2147483648		      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       4396972769280		      FALSE

SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter			      4193280
aggregate PGA auto target			   3773926.51
global memory bound					 1024

ということで、Oracle10g R2 EE 10.2.0.4.0 for MacOS X x86_64での再確認パート１は終了。Oracle10g R1の頃と違い、PGAサイズって自動的に1GBまで多きくなるんですね。

次回は、_pga_max_sizeが元々の値である200MBから値が変化し始めるpga_aggregate_targetパラメータのサイズっていくつ？　ってところをチェックしておこうと思います。

---

前回までのあらすじ・・・
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #2
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #16
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #17
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #18
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #19
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。シーズン２
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #2

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #2

前回からのつづきです。Oracle10g R1 10.1.0.3.0 (32bit)で _pga_max_sizeパラメータ値がデフォルトの場合、pga_aggregate_targetパラメータ値を10MB/50MB/1GB/5GB/10GB/4095GBと変化させ、pgaに使用されるサイズがどのように変化するか、v$pgastatビューのglobal memory boundを見て確認していく。

結果は見ての通り。Oracle10g R1では、_pga_max_sizeパラメータはpga_aggregate_targetには影響されず、常に200MBで固定されている。従ってOracle10g R1では、以前のテスト結果の通り。
pga_aggregate_targetの5%又は、_pga_max_size(200MB)の50%でいづれかの小さいサイズが利用されるというのは正しいようだ。

SYS> alter system set pga_aggregate_target=10m;

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

SYS> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ---------------------------
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           10485760                       FALSE

SYS> @pgastat

NAME                             size(MB)
------------------------------ ----------
aggregate PGA target parameter         10
aggregate PGA auto target               4
global memory bound                    .5

SYS> alter system set pga_aggregate_target=50m;

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

SYS> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ---------------------------
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           52428800                       FALSE

SYS> @pgastat

NAME                             size(MB)
------------------------------ ----------
aggregate PGA target parameter         50
aggregate PGA auto target      31.7548828
global memory bound                   2.5


SYS> alter system set pga_aggregate_target=1g;

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

SYS> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ---------------------------
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           1073741824                     FALSE

SYS> @pgastat

NAME                             size(MB)
------------------------------ ----------
aggregate PGA target parameter       1024
aggregate PGA auto target      908.358398
global memory bound            51.1992188

SYS> alter system set pga_aggregate_target=5g;

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

SYS> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ---------------------------
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           5368709120                     FALSE

SYS> @pgastat

NAME                             size(MB)
------------------------------ ----------
aggregate PGA target parameter       5120
aggregate PGA auto target      4594.71973
global memory bound                   100

SYS> alter system set pga_aggregate_target=10g;

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

SYS> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ---------------------------
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           10737418240                    FALSE

SYS> @pgastat

NAME                             size(MB)
------------------------------ ----------
aggregate PGA target parameter      10240
aggregate PGA auto target      9202.67578
global memory bound                   100

SYS> alter system set pga_aggregate_target=4095g;

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

SYS> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ---------------------------
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           4396972769280                  FALSE

SYS> @pgastat

NAME                             size(MB)
------------------------------ ----------
aggregate PGA target parameter    4193280
aggregate PGA auto target      3773929.69
global memory bound                   100

SYS> 

Oracle10g R2で再確認へつづく。

---

前回までのあらすじ・・・
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #2
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #16
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #17
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #18
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #19
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。シーズン２
・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

前回のネタ振りから随分間があいてしまいました。m(_ _)m

「pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ 」シリーズで_pga_max_sizeが固定値の様に見えてしまっているのですが、そのようになってしまった、"大きなミス"ってどこかわかりますか？

ってところ、わかりますかね。

実は、行く先々で pga_aggregate_targetとか _pga_max_sizeの値を覗いてみてて、あれ、自分のMacやPCで確かめた値と違う？？？何故ってことが数回あって、あ、そういことかと気付いたわけです。

答えから先に言うと、

Oracle10g R1までは確かに _pga_max_sizeは200MBで固定値だった。ところが、Oracle10g R2以降は、Oracleが内部で動的に変更する隠しパラメータになったということ。

そして、_pga_max_sizeをalter system文で変更してしまうと、Oracle10g R2以降では、その値は動的に変更されず、ユーザが設定した値で固定されてしまう。

ということ。

この影響で、私が実施したテストケースでは全て_pga_max_sizeは200MBのままで固定値のように見えていたということ。。

orz... まあ、隠しパラメータですから、どんな仕様変更があっても文句はいいません。＞＜　はい。

では、早速、alter system文で値を設定してしまった　_pga_max_sizeパラメータを元の状態に戻しましょう！

手順としては、Oracleインスタンス起動、spfileからpfileを作り、pfileから_pga_max_sizeの部分を削除、インスタンス停止、pfileでOracleインスタンス起動、spfile作って再起動って感じです。

とりあえず、Oracle10g R1で。

SYS> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - Prod
PL/SQL Release 10.1.0.3.0 - Production
CORE    10.1.0.3.0      Production
TNS for MacOS X Server: Version 10.1.0.3.0 - Production
NLSRTL Version 10.1.0.3.0 - Production

SYS> show parameter pga

NAME                                 TYPE                              VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size                        big integer                       200M
pga_aggregate_target                 big integer                       100M

SYS> @pgastat

NAME                             size(MB)
------------------------------ ----------
aggregate PGA target parameter        100
aggregate PGA auto target      76.1923828
global memory bound                     5

SYS>
SYS> create pfile from spfile;

ファイルが作成されました。

SYS> !cat $ORACLE_HOME/dbs/initxtiger.ora

・・・中略・・・

xtiger.__large_pool_size=4194304
xtiger.__shared_pool_size=104857600
*._pga_max_size=209715200
*.background_dump_dest='/Volumes/Discus/4oracle/oracle/u01/app/oracle/admin/xtiger/bdump'
*.compatible='10.1.0.2.0'

・・・中略・・・

SYS> edit $ORACLE_HOME/dbs/initxtiger.ora



*._pga_max_sizeの行を削除！
SYS> !cat $ORACLE_HOME/dbs/initxtiger.ora

・・・中略・・・

xtiger.__large_pool_size=4194304
xtiger.__shared_pool_size=104857600
*.background_dump_dest='/Volumes/Discus/4oracle/oracle/u01/app/oracle/admin/xtiger/bdump'
*.compatible='10.1.0.2.0'

・・・中略・・・

SYS> shutdown
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SYS> 
SYS> startup pfile=$ORACLE_HOME/dbs/initxtiger.ora
ORACLEインスタンスが起動しました。

Total System Global Area  293601280 bytes
Fixed Size                   778888 bytes
Variable Size             120331640 bytes
Database Buffers          171966464 bytes
Redo Buffers                 524288 bytes
データベースがマウントされました。
データベースがオープンされました。

SYS> create spfile from pfile;

ファイルが作成されました。

SYS> shutdown
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。

SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area  293601280 bytes
Fixed Size                   778888 bytes
Variable Size             120331640 bytes
Database Buffers          171966464 bytes
Redo Buffers                 524288 bytes
データベースがマウントされました。
データベースがオープンされました。

SYS> show parameter pga

NAME                                 TYPE                              VALUE
------------------------------------ --------------------------------- ------------------------------
pga_aggregate_target                 big integer                       100M

SYS> @pgastat

NAME                             size(MB)
------------------------------ ----------
aggregate PGA target parameter        100
aggregate PGA auto target      76.3242188
global memory bound                     5

SYS> @show_hidden_pga_param

KSPPINM                        KSPPSTVL                       KSPPSTDF
------------------------------ ------------------------------ ---------------------------
_pga_large_extent_size         1048576                        TRUE
_pga_max_size                  209715200                      TRUE
_use_ism_for_pga               TRUE                           TRUE
pga_aggregate_target           104857600                      FALSE

SYS> 

戻った〜。 show parameter pgaで 隠しパラメータである_pga_max_sizeパラメータが表示されているということは、その値がデフォルト値と同じ値であっても、そのパラメータの値は、ユーザがセットした値ということ。show parameterで _pga_max_sizeが表示されなくなったらOK。

ちなみに、 show_hidden_pga_param.sqlは以下のようなクエリ。

select
   a.ksppinm
  ,b.ksppstvl
  ,b.ksppstdf
from
  x$ksppi a join x$ksppcv b
  on a.indx = b.indx
where
  a.ksppinm like '%pga%'
order by
  a.ksppinm
/

次回へつづく。

---

前回までのあらすじ・・・
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #2
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #16
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #17
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #18
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #19
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。
・_pga_max_sizeってOracle11gではどうなったっけ？　という確認。シーズン２

続・Client result cache (クライアント結果キャッシュ） #1 w

最終回とおまけで終了させてしまったので、”続”にしてみたw

まずは、Oracle11 r2のマニュアル（原文）を。(Oracle11g r1でも同じなので）

マニュアルには、シノニムを経由の場合、クライアント結果キャッシュされないという記載はない…

ところが…

デモプログラムでアクセスするqctable表をOCITESTユーザではなくSCOTTユーザに作成し
パブリックシノニムを経由してOCITESTユーザからアクセスするよう環境を変更し〜て〜み〜る〜と〜

なんと〜〜〜〜〜〜〜〜クライアント結果キャッシュ対象外になるではありませんか〜〜〜。:)

なぜ、この手の見つけるとニッコリしちゃうんでしょw

11:21:52 SYS> conn ocitest/ocitest
接続されました。
11:22:23 OCITEST> drop table qctable purge;

表が削除されました。

経過: 00:00:00.55
11:22:33 OCITEST> desc qctable
ERROR:
ORA-04043: オブジェクトqctableは存在しません。


11:24:32 OCITEST> conn scott/tiger
接続されました。
11:26:50 SCOTT> CREATE TABLE qctable (empno NUMBER, ename VARCHAR2(20), sal NUMBER);

表が作成されました。

経過: 00:00:00.16
11:26:57 SCOTT> conn / as sysdba
接続されました。
11:27:39 SYS> grant select, insert, delete, update on scott.qctable to ocitest;

権限付与が成功しました。

経過: 00:00:00.03
11:27:54 SYS> create public synonym qctable for scott.qctable;

シノニムが作成されました。

経過: 00:00:00.12
11:28:15 SYS> conn ocitest/ocitest
接続されました。
11:29:30 OCITEST> desc qctable
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 EMPNO                                              NUMBER
 ENAME                                              VARCHAR2(20)
 SAL                                                NUMBER


11:29:33 OCITEST> exec insert_val;

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:00.36
11:29:39 OCITEST> commit;

コミットが完了しました。

経過: 00:00:00.01
11:29:41 OCITEST> 

という準備の後に、前回改造した（オリジナルのcdemoqc.cでも確認できます。）デモプログラムを実行中にclient_result_cache_stats$ビュ−を覗いて見ると〜

シノニム経由だとキャッシュされなくなることが確認できる。

11:33:22 SYS> /

  CACHE_ID    STAT_ID NAME                                VALUE
---------- ---------- ------------------------------ ----------
       140          1 Block Size                            256
       140          2 Block Count Max                      4096
       140          3 Block Count Current                   128
       140          4 Hash Bucket Count                    1024
       140          5 Create Count Success                    0
       140          6 Create Count Failure                    0
       140          7 Find Count                              0
       140          8 Invalidation Count                      0
       140          9 Delete Count Invalid                    0
       140         10 Delete Count Valid                      0

10行が選択されました。

経過: 00:00:00.00
11:33:48 SYS> 

あと一つぐらいはエントリ書くかも、（書かないかも）

---

・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #1
・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #2
・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #3
・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #4
・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #5 （最終回）
・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #おまけ

Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #おまけ

前回、最終回と言っておきながらおまけを付けるのもMac De Oracle流w

client result cacheの効果を見る方法はclient_result_cache_stats$ビューだけじゃないんですよ。

おなじみのSQLトレースを使っても確認できます。

・クライアント結果キャッシュなしのSQLトレース

SQL ID: 6xq85x8zzu4wf
Plan Hash: 1630726318
SELECT empno, ename, sal 
FROM
 qctable


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00         11         34          0           0
Execute      5      0.00       0.00          0          0          0           0
Fetch       10      0.00       0.00          6         40          0           5
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       16      0.00       0.00         17         74          0           5

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 82  (OCITEST)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  TABLE ACCESS FULL QCTABLE (cr=8 pr=6 pw=0 time=0 us cost=3 size=12 card=1)


Rows     Execution Plan
-------  ---------------------------------------------------
      0  SELECT STATEMENT   MODE: ALL_ROWS
      1   TABLE ACCESS   MODE: ANALYZED (FULL) OF 'QCTABLE' (TABLE)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                      15        0.00          0.00
  SQL*Net message from client                    15        0.00          0.00
  db file sequential read                         1        0.00          0.00
  db file scattered read                          1        0.00          0.00

・クライアント結果キャッシュありのSQLトレース

SQL ID: 6gsb66qbaqg37
Plan Hash: 1630726318
SELECT /*+ result_cache */ empno, ename, sal 
FROM
 qctable


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.02         10         34          0           0
Execute      1      0.00       0.02          0          0          1           0
Fetch        2      0.00       0.00          6          8          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.00       0.04         16         42          1           1

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 82  (OCITEST)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  RESULT CACHE  35dnz5hwwxb2k5f5b2ucfcff1d (cr=8 pr=6 pw=0 time=0 us)
      1   TABLE ACCESS FULL QCTABLE (cr=8 pr=6 pw=0 time=0 us cost=3 size=12 card=1)


Rows     Execution Plan
-------  ---------------------------------------------------
      0  SELECT STATEMENT   MODE: ALL_ROWS
      1   RESULT CACHE OF '35dnz5hwwxb2k5f5b2ucfcff1d'
             column-count=3; dependencies=(OCITEST.QCTABLE); name="SELECT /*+ 
               result_cache */ empno, ename, sal FROM qctable"
      1    TABLE ACCESS   MODE: ANALYZED (FULL) OF 'QCTABLE' (TABLE)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       3        0.00          0.00
  log file sync                                   1        0.00          0.00
  SQL*Net message from client                     3        0.00          0.00
  db file sequential read                         1        0.00          0.00
  db file scattered read                          1        0.00          0.00

---

・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #1
・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #2
・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #3
・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #4
・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #5 （最終回）

Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #5 （最終回）

これってクライアント結果キャッシュをちゃんと動作させる為じゃなく、cdemoqc.cってクライアント結果キャッシュのデモを実行した時に、別クライアントからclient_result_cache_stats$ビューの作成、参照件数等をチェックすることで動作確認できるようにするための改造なので、動作確認できたらdual表を無理矢理問い合わせるなんてぇロジック不要ですから、お間違いのないように。m(_ _)m 2010/9/13追記。

さて、Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係も今回が最終回.

最終回なのでOracleのバージョン情報も載せておきますね。

19:54:51 SYS> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
PL/SQL Release 11.1.0.7.0 - Production
CORE    11.1.0.7.0      Production
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production

経過: 00:00:00.00
19:55:56 SYS> 

Client Result Cacheを有効化する為のプログラミング上のポイント！
・OCIStmtPrepare2()を使う。

マニュアルにも記載されてますが、Client Result Cacheを有効かするためにはStatement cache（文キャッシュ）を有効化している必要がある。
　OCIStmtPrepare()を使ってしまうと文キャッシュされないのでClient result cacheが効かない。

・OCIStmtFetch2()でOCI_NO_DATAまでフェッチする。

例えば、１行しかないからOCIStmtExecute()の後、OCIStmtFetch2()を１度しか行っていないと、OCI_NO_DATAが発生しないのでClient Result Cacheに問合せ結果が乗らない。

その他、初期化パラメータや　/*+ RESULT_CACHE */　ヒントを利用する等といった前提はマニュアルを読んでね。

最後に総まとめとして、cdemoqc.cを思いっきり修正し必要最低限かつ、cdemoqc.c内でclient_result_cache_stats$を確認するという怪しい作りじゃなく、別途、SQL*Plusからclient_result_cache_stats$ビューを問い合わせ、Client result cache（クライアント結果キャッシュ）が出来ているか確認できるように改造しちゃいました。

但し、削除次いでにwindows対応の部分までも削ぎ落としてしまいました。ごめんなさい。ごめんなさい。

以下、Mac De Oracle版 cdemoqc.c （除くWindows)のコード。

[oracle@lampeye demo]$ cat $ORACLE_HOME/rdbms/demo/cdemoqc.c
/* Copyright (c) 2007, Oracle. All rights reserved.  */

/*
  NAME
    cdemoqc - Basic OCI Query Cache(result cache) functionality 
         
  DESCRIPTION
    This program demonstrate the working of Query cache. 
    To use the query cache feature (and hence this program), database
    should have been brought up with client side result cache enabled. To bring
    the database with result cache enabled, add the following lines in
    initialization parameter file,
       client_result_cache_size=<cache size in bytes>
       client_result_cache_lag=<timeout value for cache in ms>
       compatible=11.0.0.0.0
    and bring up the database.

*/


# include <oci.h>

# include <stdio.h>
# include <string.h>
# include <stdlib.h>
# include <time.h>

#include <unistd.h>

#define EMPLOYEE 0

/* Function prototypes */
static void query_tab();
static void dummy_query();
static void dbLogon();
static void dbLogoff();
static void Checkerr(OCIError *errhp, sword status, text *msg);

int main();

static sword status = 0;
static OCISvcCtx *svchp;
static OCIError   *errhp;
static OCIEnv     *envhp;

/* Queries with result cache hints */
static text *cache_query=
(text *)"SELECT /*+ result_cache */ empno, ename, sal FROM qctable";
//(text *)"SELECT empno, ename, sal FROM qctable";

static text *dummy= (text *)"SELECT COUNT(*) FROM DUAL";
/* - main -------------------------------------------------------------------*/ 
int main ()
{
  long t;
  time(&t);
  printf ("Start -- %s",ctime(&t));
  printf ("Query cache is enabled by using result_cache hints\n\n");

  /* Logging on to multiple sessions */
  dbLogon ();

  printf ("Employee: Execute will fetch rows from server\n");
  query_tab(EMPLOYEE);
  printf ("\n\nEmployee: Execute will fetch rows from local cache, 4 times\n");
  query_tab(EMPLOYEE);
  query_tab(EMPLOYEE);
  query_tab(EMPLOYEE);
  query_tab(EMPLOYEE);
  printf ("\n\nTotal query 5 times\nSleeping...30sec..\n");
  sleep(30);
  time(&t);
  dummy_query(EMPLOYEE);
  printf("dummyクエリ実行済み、１０秒待機中。\n");
  printf("この間にclient_result_cache_stats$ビューを他端末からチェック！\n\n%s",
	 ctime(&t));
  sleep(10);

  dbLogoff ();
  return 0;
}

static void dummy_query ()
{
  OCIStmt *stmthp = (OCIStmt *)0;
  OCIDefine *def1hp = (OCIDefine *)0;
  ub4 ctr;
  sb4 ctrSz = sizeof(ctr);
  ub2 datelen=0;
  ub4 prefetch = 0;

  Checkerr (errhp,
    OCIStmtPrepare2 ((OCISvcCtx *)svchp,(OCIStmt **)&stmthp,
    (OCIError *)errhp, (text *)dummy, (ub4)strlen((char *)dummy),
    (oratext *)NULL, (ub4) 0, (ub4)OCI_NTV_SYNTAX, (ub4)OCI_DEFAULT),
    (oratext *)"OCIStmtPrepare");

  /* Setting the prefetch count = 0 */
  Checkerr(errhp,
    OCIAttrSet((OCIStmt *) stmthp, OCI_HTYPE_STMT, (dvoid *)&prefetch,
    sizeof(prefetch), OCI_ATTR_PREFETCH_ROWS, (OCIError *)errhp),
    (oratext *) "OCIAttrSet-prefetch");

  Checkerr (errhp,
    OCIDefineByPos ((OCIStmt *)stmthp, (OCIDefine **)&def1hp,
    (OCIError *)errhp, (ub4)1, (dvoid *)&(ctr), (sb4)ctrSz, (ub2)SQLT_INT,
    (dvoid *)0, (ub2 *)0, (ub2 *)0, (ub4)OCI_DEFAULT),
    (oratext *)"OCIDefByPos");

  if ((status = OCIStmtExecute ((OCISvcCtx *)svchp, (OCIStmt *)stmthp,
                  (OCIError *)errhp, (ub4)0, (ub4)0, (OCISnapshot *)0,
                  (OCISnapshot *)0, (ub4)OCI_DEFAULT)) != OCI_SUCCESS )
  {
    printf ("OCIStmtExecute for Query Dual - Fail\n" );
    Checkerr (errhp, status,(oratext *)"Stmt Execute");
  }
  else
  {
    status = OCIStmtFetch2((OCIStmt *)stmthp, (OCIError *)errhp, (ub4)1,
             (ub2)OCI_FETCH_NEXT, (sb4)0, (ub4)OCI_DEFAULT);

    if (status == OCI_ERROR || status == OCI_INVALID_HANDLE)
    {
      Checkerr(errhp, status, (oratext *)"OCIStmtFetch2");
      return;
    }
    else if (status != OCI_NO_DATA)
    {
      printf("Dual selected.\n");
    }
  }

  Checkerr (errhp,
    OCIStmtRelease ((OCIStmt *)stmthp, (OCIError *)errhp,(dvoid *)NULL, 0,
    OCI_DEFAULT), (oratext *)"StmtRelease");
}

/* - Logon to the DB in two sessions ----------------------------------------*/ 
static void dbLogon ()
{
  ub4 cachesize=10;
  OraText *connStr = (text *)"";
  OraText *username = (text *)"ocitest";
  OraText *password = (text *)"ocitest";
  OCIAuthInfo *authhp = (OCIAuthInfo *)0;

  OCIEnvCreate ((OCIEnv **)&envhp, (ub4)OCI_DEFAULT, (dvoid *)0,
                (dvoid * (*)(dvoid *, size_t))0,
                (dvoid * (*)(dvoid *, dvoid *, size_t))0,
                (void (*)(dvoid *, dvoid *))0, (size_t)0, (dvoid **)0);

  OCIHandleAlloc ((dvoid *) envhp, (dvoid **) &errhp, OCI_HTYPE_ERROR,
                  (size_t) 0, (dvoid **) 0);

  OCIHandleAlloc ((dvoid *)envhp, (dvoid **)&authhp,
                  (ub4)OCI_HTYPE_AUTHINFO, (size_t)0, (dvoid **)0);

  OCIAttrSet ((dvoid *)authhp, (ub4)OCI_HTYPE_AUTHINFO, (dvoid *)username,
     (ub4)strlen((char *)username), (ub4)OCI_ATTR_USERNAME,
     (OCIError *)errhp);

  OCIAttrSet ((dvoid *)authhp, (ub4)OCI_HTYPE_AUTHINFO, (dvoid *)password,
     (ub4)strlen((char *)password), (ub4)OCI_ATTR_PASSWORD,
     (OCIError *)errhp);

  Checkerr (errhp, 
     OCISessionGet ((OCIEnv *)envhp, (OCIError *)errhp,
     (OCISvcCtx **)&svchp, (OCIAuthInfo *)authhp, (OraText *)connStr,
     (ub4)strlen((char *)connStr), (OraText *)NULL, (ub4)0, (OraText **)0,
     (ub4 *)0, (boolean *)0,(ub4)OCI_DEFAULT),
     (oratext *)"OCISessionGet");

  printf ("Connected to Employee Session\n");

  OCIAttrSet((dvoid *)svchp, OCI_HTYPE_SVCCTX, (dvoid *)&cachesize,
     (ub4)0,OCI_ATTR_STMTCACHESIZE,errhp);

}

/* - Execute SQL query and prints the data ----------------------------------*/ 
static void query_tab ()
{
  OCIStmt *stmthp = (OCIStmt *)0; 
  OCIDefine *def1hp = (OCIDefine *)0;
  OCIDefine *def2hp = (OCIDefine *)0;
  OCIDefine *def3hp = (OCIDefine *)0;
  ub4 empno;
  text ename[100];
  ub4 sal;
  sb4 empnoSz = sizeof (empno);
  sb4 enameSz = sizeof (ename);
  sb4 salSz = sizeof (sal);
  ub2 datelen=0;
  ub4  prefetch = 0;

  Checkerr (errhp, 
    OCIStmtPrepare2 ((OCISvcCtx *)svchp,(OCIStmt **)&stmthp,
    (OCIError *)errhp, (text *)cache_query, (ub4)strlen((char *)cache_query), 
    (oratext *)NULL, (ub4) 0, (ub4)OCI_NTV_SYNTAX, (ub4)OCI_DEFAULT),
    (oratext *)"OCIStmtPrepare");

  /* Setting the prefetch count = 0 */
  Checkerr(errhp, 
    OCIAttrSet((OCIStmt *) stmthp, OCI_HTYPE_STMT, (dvoid *)&prefetch,
    sizeof(prefetch), OCI_ATTR_PREFETCH_ROWS, (OCIError *)errhp),
    (oratext *) "OCIAttrSet-prefetch");

  Checkerr (errhp, 
    OCIDefineByPos ((OCIStmt *)stmthp, (OCIDefine **)&def1hp,
    (OCIError *)errhp, (ub4)1, (dvoid *)&(empno), (sb4)empnoSz, (ub2)SQLT_INT,
    (dvoid *)0, (ub2 *)0, (ub2 *)0, (ub4)OCI_DEFAULT),
    (oratext *)"OCIDefByPos");

  Checkerr (errhp, 
    OCIDefineByPos ((OCIStmt *)stmthp, (OCIDefine **)&def2hp,
    (OCIError *)errhp, (ub4)2, (dvoid *)&(ename), (sb4)enameSz, (ub2)SQLT_STR,
    (dvoid *)0, (ub2 *)0, (ub2 *)0, (ub4)OCI_DEFAULT),
    (oratext *)"OCIDefByPos2");

  Checkerr (errhp, 
    OCIDefineByPos ((OCIStmt *)stmthp, (OCIDefine **)&def3hp,
    (OCIError *)errhp, (ub4)3, (dvoid *)&(sal), (sb4)salSz, (ub2)SQLT_INT,
    (dvoid *)0, (ub2 *)0, (ub2 *)0, (ub4)OCI_DEFAULT),
    (oratext *)"OCIDefByPos3");

  if ((status = OCIStmtExecute ((OCISvcCtx *)svchp, (OCIStmt *)stmthp,
                  (OCIError *)errhp, (ub4)0, (ub4)0, (OCISnapshot *)0,
                  (OCISnapshot *)0, (ub4)OCI_DEFAULT)) != OCI_SUCCESS )
  {
    printf ("OCIStmtExecute for SELECT - Fail\n" );
    Checkerr (errhp, status,(oratext *)"Stmt Execute");
  }
  else
  {
    do 
    {
      status = OCIStmtFetch2((OCIStmt *)stmthp, (OCIError *)errhp, (ub4)1,
                 (ub2)OCI_FETCH_NEXT, (sb4)0, (ub4)OCI_DEFAULT);

      if (status == OCI_ERROR || status == OCI_INVALID_HANDLE)
      {
        Checkerr(errhp, status, (oratext *)"OCIStmtFetch2");
        break;
      }
      else if (status != OCI_NO_DATA)
      {
        printf("\nEMPNO is %d, ENAME is %s, SAL is %d\n", empno, ename, sal);
      } 
    }while(status !=  OCI_NO_DATA);
  }

  Checkerr (errhp,
    OCIStmtRelease ((OCIStmt *)stmthp, (OCIError *)errhp,(dvoid *)NULL, 0,
    OCI_DEFAULT), (oratext *)"StmtRelease");
}

/* - Session Logoff --------------------------------------------------------*/
static void dbLogoff ()
{
  printf ("\nLogging off the connected session.\n");

  Checkerr (errhp, 
    OCISessionRelease(svchp, errhp, 0,0, OCI_DEFAULT),
    (oratext *) "Session-Release");
}

/* - Error checking routing -------------------------------------------------*/
void Checkerr(OCIError *errhp, sword status, text *msg)
{
  text  msgbuf[512];
  sb4   errcode = 0;

  memset((void *) msgbuf, (int)'\0', (size_t)512);
  if(status!=OCI_SUCCESS)
  {
    printf("error msg: %s\n",msg);
  }

  switch (status)
  {
  case OCI_SUCCESS: break;
  case OCI_SUCCESS_WITH_INFO:
    printf("status = OCI_SUCCESS_WITH_INFO\n");
    OCIErrorGet((dvoid *) errhp, (ub4) 1, (text *) NULL, &errcode,
                       msgbuf, (ub4) sizeof(msgbuf), (ub4) OCI_HTYPE_ERROR);
    printf("ERROR CODE = %d\n", errcode);
    printf("%.*s\n", 512, msgbuf);
    if (errcode == 436 || errcode == 437 || errcode == 438 || errcode == 439)
      exit(1);
    break;
  case OCI_NEED_DATA:
    printf("status = OCI_NEED_DATA\n");
    break;
  case OCI_NO_DATA:
     printf("status = OCI_NO_DATA\n");
    break;
  case OCI_ERROR:
     printf("status = OCI_ERROR\n");
     OCIErrorGet((dvoid *) errhp, (ub4) 1, (text *) NULL, &errcode,
                       msgbuf, (ub4) sizeof(msgbuf), (ub4) OCI_HTYPE_ERROR);
     printf("ERROR CODE = %d\n", errcode);
     printf("%.*s\n", 512, msgbuf);
    if (errcode == 436 || errcode == 437 || errcode == 438 || errcode == 439)
      exit(1);
    break;
  case OCI_INVALID_HANDLE:
     OCIErrorGet((dvoid *) errhp, (ub4) 1, (text *) NULL, &errcode,
                       msgbuf, (ub4) sizeof(msgbuf), (ub4) OCI_HTYPE_ERROR);
     printf("ERROR CODE = %d\n", errcode);
     printf("%.*s\n", 512, msgbuf);
     printf("status = OCI_INVALID_HANDLE\n");
    break;
  case OCI_STILL_EXECUTING:
     printf("status = OCI_STILL_EXECUTE\n");
    break;
  case OCI_CONTINUE:
     printf("status = OCI_CONTINUE\n");
    break;
  default:
    break;
  }
  return;
}

64bit 環境なので以下のように demo_rdbms64.mkでmakeしま〜す。

[oracle@lampeye demo]$  make -f demo_rdbms64.mk build EXE=cdemoqc OBJS="cdemoqc.o"

/usr/bin/gcc -fPIC -c -I/opt/u01/app/oracle/product/11.1.0/db_1/rdbms/demo 
-I/opt/u01/app/oracle/product/11.1.0/db_1/rdbms/public 
-I/opt/u01/app/oracle/product/11.1.0/db_1/plsql/public -I/opt/u01/app/oracle/product/11.1.0/db_1/network/public 
-I/opt/u01/app/oracle/product/11.1.0/db_1/precomp/public cdemoqc.c -DLINUX -DORAX86_64 -D_GNU_SOURCE -D_LARGEFILE64_SOURCE=1 
-D_LARGEFILE_SOURCE=1 -DSLTS_ENABLE -DSLMXMX_ENABLE -D_REENTRANT -DNS_THREADS -DLONG_IS_64 -DSS_64BIT_SERVER
/usr/bin/gcc -L/opt/u01/app/oracle/product/11.1.0/db_1/lib/ 
-L/opt/u01/app/oracle/product/11.1.0/db_1/rdbms/lib/ -o cdemoqc cdemoqc.o -lclntsh   
`cat /opt/u01/app/oracle/product/11.1.0/db_1/lib/sysliblist` -ldl -lm  -lpthrea

実行！！！ 同一表(1行だけ登録されてます）を５回問合せ、うち４回はClient result cacheにヒットさせます。
Sleeping...30sec..の待機は、オリジナルのコードでは60秒待機させていましたが私の環境だと30秒待機でOKでした。
dummyクエリ実行済み、１０秒待機中。のメッセージが表示されたら、予め起動していたSQL*Plusからclient_result_cache_stats$を問い合わせます。クライアント結果キャッシュが効いているか確認できるはずです。

[oracle@lampeye demo]$ ./cdemoqc
Start -- Thu Sep  9 19:54:09 2010
Query cache is enabled by using result_cache hints

Connected to Employee Session
Employee: Execute will fetch rows from server

EMPNO is 1, ENAME is EMP_1, SAL is 900


Employee: Execute will fetch rows from local cache, 4 times

EMPNO is 1, ENAME is EMP_1, SAL is 900

EMPNO is 1, ENAME is EMP_1, SAL is 900

EMPNO is 1, ENAME is EMP_1, SAL is 900

EMPNO is 1, ENAME is EMP_1, SAL is 900


Total query 5 times
Sleeping...30sec..
Dual selected.
dummyクエリ実行済み、１０秒待機中。
この間にclient_result_cache_stats$ビューを他端末からチェック！

Thu Sep  9 19:54:39 2010

Logging off the connected session.
[oracle@lampeye demo]$ 

SQL*Plusからの確認！

・デモプログラム起動直後の状態
19:39:02 SYS> select * from client_result_cache_stats$;

  CACHE_ID    STAT_ID NAME                                VALUE
---------- ---------- ------------------------------ ----------
       111          1 Block Size                              0
       111          2 Block Count Max                         0
       111          3 Block Count Current                     0
       111          4 Hash Bucket Count                       0
       111          5 Create Count Success                    0
       111          6 Create Count Failure                    0
       111          7 Find Count                              0
       111          8 Invalidation Count                      0
       111          9 Delete Count Invalid                    0
       111         10 Delete Count Valid                      0

10行が選択されました。

経過: 00:00:00.00

・この間にclient_result_cache_stats$ビューを他端末からチェック！が表示された時点の状態
19:54:13 SYS> /

  CACHE_ID    STAT_ID NAME                                VALUE
---------- ---------- ------------------------------ ----------
       111          1 Block Size                            256
       111          2 Block Count Max                      4096
       111          3 Block Count Current                   128
       111          4 Hash Bucket Count                    1024
       111          5 Create Count Success                    1
       111          6 Create Count Failure                    0
       111          7 Find Count                              4
       111          8 Invalidation Count                      0
       111          9 Delete Count Invalid                    0
       111         10 Delete Count Valid                      0

10行が選択されました。

経過: 00:00:00.00

・デモプログラム終了直後の状態
19:54:40 SYS> /

レコードが選択されませんでした。

経過: 00:00:00.00

---

・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #1
・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #2
・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #3
・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #4

Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #4

前回のつづきです。

前回は、OCIStmtPreare2()まで実行させた。
OCIStmtExecute()かOCIStmtFetch2()が実行されたタイミングでclient_result_cache_stats$ビューへ該当クライアントから統計情報がアップされているように見える！　という動きは確認。

今回は、OCIStmtExecute()まで実行させ、OCIStmtFetch2()をコメントアウトしてみた。

[oracle@lampeye demo]$ diff $ORACLE_HOME/rdbms/demo/cdemoqc.c.org $ORACLE_HOME/rdbms/demo/cdemoqc.c
138d137
<   /*
144d142
<   */
431,452c429,450
<   else
<   {
<     printf("Contents of CLIENT_RESULT_CACHE_STATS$\n");
<     printf("STAT_ID    NAME OF STATISTICS      VALUE  CACHE_ID\n"); 
<     printf("=======    ==================      =====  ========\n"); 
<     do 
<     {
<       status = OCIStmtFetch2((OCIStmt *)stmthp, (OCIError *)errhp, (ub4)1,
<                              (ub2)OCI_FETCH_NEXT, (sb4)0, (ub4)OCI_DEFAULT);
< 
<       if (status == OCI_ERROR || status == OCI_INVALID_HANDLE)
<       {
<         Checkerr(errhp, status, (oratext *)"OCIStmtFetch2");
<         break;
<       }
<       else if (status != OCI_NO_DATA)
<       {
<         printf("%5d      %-20s %8d %6d\n", statid, name, value, cacheid); 
<       } 
<     }while(status !=  OCI_NO_DATA);
< 
<   }
---
> //  else
> //  {
> //    printf("Contents of CLIENT_RESULT_CACHE_STATS$\n");
> //    printf("STAT_ID    NAME OF STATISTICS      VALUE  CACHE_ID\n"); 
> //    printf("=======    ==================      =====  ========\n"); 
> //    do 
> //    {
> //      status = OCIStmtFetch2((OCIStmt *)stmthp, (OCIError *)errhp, (ub4)1,
> //                             (ub2)OCI_FETCH_NEXT, (sb4)0, (ub4)OCI_DEFAULT);
> //
> //      if (status == OCI_ERROR || status == OCI_INVALID_HANDLE)
> //      {
> //        Checkerr(errhp, status, (oratext *)"OCIStmtFetch2");
> //        break;
> //      }
> //      else if (status != OCI_NO_DATA)
> //      {
> //        printf("%5d      %-20s %8d %6d\n", statid, name, value, cacheid); 
> //      } 
> //    }while(status !=  OCI_NO_DATA);
> //
> //  }
457a456,458
>   printf("Sleep 10sec...\n");
>   sleep (10);
> 
[oracle@lampeye demo]$ 

mekeして実行！！！

[oracle@lampeye demo]$ ./cdemoqc
Query cache is enabled by using result_cache hints

Connected to Employee Session
Connected to HR Session

Employee: Execute will fetch rows from server
Employee: Execute will fetch rows from local cache
HR: Execute will cause a roundtrip during first execute, but the same result 
        set created in Employee Session will be shared thereafter
HR: Execute will fetch rows from local cache

HR: Updating the table

Employee: Execute will fetch rows from server and hence the local result set 
        will be updated
HR: Execute will fetch rows from updated local cache
Employee: Execute will fetch rows from local cache

Sleeping for few seconds to let the stat table to get updated

Please enter password for sys user to continue:
xxxxxxxx!
Sleep 10sec...

Logging off all the connected sessions.
[oracle@lampeye demo]$ 

やった〜〜〜、見えた〜〜〜〜〜。OCIStmtExecute()が実行され、その要求がサーバまで到達する場合に、client_result_cache_stats$へ統計情報が反映されているように見える。
（ちなみに、ログは載せていないが、sleep(60)待機後、もう一度、クライアント結果キャッシュ対象のクエリを実行しても別クライアントからclient_result_cache_stats$から統計情報を参照することはできなかった）

・デモプログラム実行前の状態
21:59:31 SYS> /

レコードが選択されませんでした。

経過: 00:00:00.00

・デモプログラム実行直後の状態
21:59:32 SYS> /

 CACHE_ID    STAT_ID NAME                                VALUE
---------- ---------- ------------------------------ ----------
       116          1 Block Size                              0
       116          2 Block Count Max                         0
       116          3 Block Count Current                     0
       116          4 Hash Bucket Count                       0
       116          5 Create Count Success                    0
       116          6 Create Count Failure                    0
       116          7 Find Count                              0
       116          8 Invalidation Count                      0
       116          9 Delete Count Invalid                    0
       116         10 Delete Count Valid                      0

10行が選択されました。

経過: 00:00:00.00

・Please enter password for sys user to continue:が表示され、待機している状態
21:59:36 SYS> /

  CACHE_ID    STAT_ID NAME                                VALUE
---------- ---------- ------------------------------ ----------
       116          1 Block Size                              0
       116          2 Block Count Max                         0
       116          3 Block Count Current                     0
       116          4 Hash Bucket Count                       0
       116          5 Create Count Success                    0
       116          6 Create Count Failure                    0
       116          7 Find Count                              0
       116          8 Invalidation Count                      0
       116          9 Delete Count Invalid                    0
       116         10 Delete Count Valid                      0

10行が選択されました。

経過: 00:00:00.00

・Sleep 10sec...が表示され１０秒待機している状態
22:00:54 SYS> /

  CACHE_ID    STAT_ID NAME                                VALUE
---------- ---------- ------------------------------ ----------
       116          1 Block Size                            256
       116          2 Block Count Max                      4096
       116          3 Block Count Current                   128
       116          4 Hash Bucket Count                    1024
       116          5 Create Count Success                    2
       116          6 Create Count Failure                    0
       116          7 Find Count                              4
       116          8 Invalidation Count                      1
       116          9 Delete Count Invalid                    0
       116         10 Delete Count Valid                      0

10行が選択されました。

経過: 00:00:00.00

・デモプログラム終了直後の状態
22:01:00 SYS> /

レコードが選択されませんでした。

経過: 00:00:00.00
22:01:23 SYS> 

次回へつづく〜。

---

・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #1
・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #2
・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #3

Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #3

前回のつづきです。

前回は、print_stats()のOCIStmtRelease()とOCISessionEnd()の間にsleepを追加し、sleepしている間（つまり、OCISessionEnd()が実行される前であれば、client_result_cache_stats$ビューに反映されたクライアント結果キャッシュの統計情報が参照できることを確認したところまでだった。

今回は、さらに掘り下げてみます。OCISessionEnd()で統計情報が破棄されるので、破棄されるタイミングのは分りました。が、では、その統計情報は、どのタイミングで反映されるのでしょう。
ログはありませんが、cdemoqc.cにもともと実装されているsleep(60)をsleep(180)としても、他のクライアントの別セッションからclient_result_cache_stats$の統計情報を除いて覗いても反映されることはありませんでした。

いままでの結果から、sleep(60)〜OCISessionEnd()の間行われているということは想像できます。ということで、OCIStmtExecute()とOCIStmtFetc2()部分をコメントアウトし、OCIStmtPrepare2()だけ実行される状態にしてみました。

[oracle@lampeye demo]$ diff $ORACLE_HOME/rdbms/demo/cdemoqc.c.org $ORACLE_HOME/rdbms/demo/cdemoqc.c
138d137
<   /*
144d142
<   */
423,452c421,450
<   if ((status = OCIStmtExecute ((OCISvcCtx *)syssvchp, (OCIStmt *)stmthp,
<                                 (OCIError *)errhp, (ub4)0, (ub4)0,
<                                 (OCISnapshot *)0, (OCISnapshot *)0, 
<                                 (ub4)OCI_DEFAULT)) != OCI_SUCCESS )
<   {
<     printf ("OCIStmtExecute for SELECT - Fail\n" );
<     Checkerr (errhp, status,(oratext *)"Stmt Execute");
<   }
<   else
<   {
<     printf("Contents of CLIENT_RESULT_CACHE_STATS$\n");
<     printf("STAT_ID    NAME OF STATISTICS      VALUE  CACHE_ID\n"); 
<     printf("=======    ==================      =====  ========\n"); 
<     do 
<     {
<       status = OCIStmtFetch2((OCIStmt *)stmthp, (OCIError *)errhp, (ub4)1,
<                              (ub2)OCI_FETCH_NEXT, (sb4)0, (ub4)OCI_DEFAULT);
< 
<       if (status == OCI_ERROR || status == OCI_INVALID_HANDLE)
<       {
<         Checkerr(errhp, status, (oratext *)"OCIStmtFetch2");
<         break;
<       }
<       else if (status != OCI_NO_DATA)
<       {
<         printf("%5d      %-20s %8d %6d\n", statid, name, value, cacheid); 
<       } 
<     }while(status !=  OCI_NO_DATA);
< 
<   }
---
> //  if ((status = OCIStmtExecute ((OCISvcCtx *)syssvchp, (OCIStmt *)stmthp,
> //                                (OCIError *)errhp, (ub4)0, (ub4)0,
> //                                (OCISnapshot *)0, (OCISnapshot *)0, 
> //                                (ub4)OCI_DEFAULT)) != OCI_SUCCESS )
> //  {
> //    printf ("OCIStmtExecute for SELECT - Fail\n" );
> //    Checkerr (errhp, status,(oratext *)"Stmt Execute");
> //  }
> //  else
> //  {
> //    printf("Contents of CLIENT_RESULT_CACHE_STATS$\n");
> //    printf("STAT_ID    NAME OF STATISTICS      VALUE  CACHE_ID\n"); 
> //    printf("=======    ==================      =====  ========\n"); 
> //    do 
> //    {
> //      status = OCIStmtFetch2((OCIStmt *)stmthp, (OCIError *)errhp, (ub4)1,
> //                             (ub2)OCI_FETCH_NEXT, (sb4)0, (ub4)OCI_DEFAULT);
> //
> //      if (status == OCI_ERROR || status == OCI_INVALID_HANDLE)
> //      {
> //        Checkerr(errhp, status, (oratext *)"OCIStmtFetch2");
> //        break;
> //      }
> //      else if (status != OCI_NO_DATA)
> //      {
> //        printf("%5d      %-20s %8d %6d\n", statid, name, value, cacheid); 
> //      } 
> //    }while(status !=  OCI_NO_DATA);
> //
> //  }
457a456,458
>   printf("Sleep 10sec...\n");
>   sleep (10);
> 
[oracle@lampeye demo]$ 

makeして実行！！！！！

[oracle@lampeye demo]$ ./cdemoqc
Query cache is enabled by using result_cache hints

Connected to Employee Session
Connected to HR Session

Employee: Execute will fetch rows from server
Employee: Execute will fetch rows from local cache
HR: Execute will cause a roundtrip during first execute, but the same result 
        set created in Employee Session will be shared thereafter
HR: Execute will fetch rows from local cache

HR: Updating the table

Employee: Execute will fetch rows from server and hence the local result set 
        will be updated
HR: Execute will fetch rows from updated local cache
Employee: Execute will fetch rows from local cache

Sleeping for few seconds to let the stat table to get updated

Please enter password for sys user to continue:
xxxxxxxx!
Sleep 10sec...

Logging off all the connected sessions.
[oracle@lampeye demo]$ 

Sleep 10sec...中に、他クライアントからclient_result_cache_stats$ビューを覗いて見ると…

お〜〜〜〜〜〜〜〜〜〜〜〜〜、一度も統計情報が反映されません！！！！！　;)

・デモプログラム実行前の状態
21:52:37 SYS> /

レコードが選択されませんでした。

経過: 00:00:00.01


・デモプログラム実行直後の状態

21:52:39 SYS> /

  CACHE_ID    STAT_ID NAME                                VALUE
---------- ---------- ------------------------------ ----------
       115          1 Block Size                              0
       115          2 Block Count Max                         0
       115          3 Block Count Current                     0
       115          4 Hash Bucket Count                       0
       115          5 Create Count Success                    0
       115          6 Create Count Failure                    0
       115          7 Find Count                              0
       115          8 Invalidation Count                      0
       115          9 Delete Count Invalid                    0
       115         10 Delete Count Valid                      0

10行が選択されました。

経過: 00:00:00.00


・Please enter password for sys user to continue:が表示されている時点の状態
21:52:44 SYS> /

  CACHE_ID    STAT_ID NAME                                VALUE
---------- ---------- ------------------------------ ----------
       115          1 Block Size                              0
       115          2 Block Count Max                         0
       115          3 Block Count Current                     0
       115          4 Hash Bucket Count                       0
       115          5 Create Count Success                    0
       115          6 Create Count Failure                    0
       115          7 Find Count                              0
       115          8 Invalidation Count                      0
       115          9 Delete Count Invalid                    0
       115         10 Delete Count Valid                      0

10行が選択されました。

経過: 00:00:00.00

・Sleep 10sec...が表示されている時点の状態
21:53:44 SYS> /

  CACHE_ID    STAT_ID NAME                                VALUE
---------- ---------- ------------------------------ ----------
       115          1 Block Size                              0
       115          2 Block Count Max                         0
       115          3 Block Count Current                     0
       115          4 Hash Bucket Count                       0
       115          5 Create Count Success                    0
       115          6 Create Count Failure                    0
       115          7 Find Count                              0
       115          8 Invalidation Count                      0
       115          9 Delete Count Invalid                    0
       115         10 Delete Count Valid                      0

10行が選択されました。

経過: 00:00:00.00
21:53:52 SYS> /

  CACHE_ID    STAT_ID NAME                                VALUE
---------- ---------- ------------------------------ ----------
       115          1 Block Size                              0
       115          2 Block Count Max                         0
       115          3 Block Count Current                     0
       115          4 Hash Bucket Count                       0
       115          5 Create Count Success                    0
       115          6 Create Count Failure                    0
       115          7 Find Count                              0
       115          8 Invalidation Count                      0
       115          9 Delete Count Invalid                    0
       115         10 Delete Count Valid                      0

10行が選択されました。

経過: 00:00:00.00

・デモプログラム終了後の状態
21:53:54 SYS> /

レコードが選択されませんでした。

経過: 00:00:00.00
21:54:00 SYS> 

徐々に、ポイントが見えてきました。次回へつづく。

---

・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #1
・Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #2

Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #2

前回の続きです。

最初に前回のまとめから。

client_result_cache_stats$の内容に関して以下３点が確認できました。

・client_result_cache_stats$ヘ該当クライアントから統計情報が反映されるまでタイムラグがある。
　(cdemoqc.cでは、60秒も待機してからclient_result_cache_stats$を問い合わせている）
・client_result_cache_stats$に表示されるCACHE_ID列値は、cdemoqc.cが表示している内容に一致する。
・cdemoqc.c内の別セッションを使った問い合わせてでは、client_result_cache_stats$の値が取得できている。

いろいろと考え込んでいて閃いたのが、クライアント結果キャッシュってクライアントとサーバ間のラウンドトリップを減らすことも目的なわけだから、キャッシュを保持しているクライアントから、キャッシュの統計情報がサーバに渡るタイミングが非常に限られているんじゃないか……と。
ということで、クライアント結果キャッシュが効いているクエリではサーバまで行かないので、後続のOCIでサーバまで行かないと処理が終わらないタイプのOCIをコールしてたついでにclient_result_cache_stats$に表示する統計情報を送るんじゃないだろーかー。ということ。

OCISessionEnd()で、統計情報が破棄されているんだろーという推測の元、クライアント結果キャッシュに載せないSQL文のPrepare,ExecuteやFetchのいずれかのタイミングで送っているんだろうという切り分けのため、print_stats()のOCIStmtRelease()とOCISessionEnd()の間にsleepを追加した。

[oracle@lampeye demo]$ diff cdemoqc.c.org cdemoqc.c
138d137
<   /*
144d142
<   */
457a456,458
>   printf("Sleep 10sec...\n");
>   sleep (10);
> 
[oracle@lampeye demo]$

実行結果は以下の通り。

[oracle@lampeye demo]$ ./cdemoqc
Query cache is enabled by using result_cache hints

Connected to Employee Session
Connected to HR Session

Employee: Execute will fetch rows from server
Employee: Execute will fetch rows from local cache
HR: Execute will cause a roundtrip during first execute, but the same result
        set created in Employee Session will be shared thereafter
HR: Execute will fetch rows from local cache

HR: Updating the table

Employee: Execute will fetch rows from server and hence the local result set
        will be updated
HR: Execute will fetch rows from updated local cache
Employee: Execute will fetch rows from local cache

Sleeping for few seconds to let the stat table to get updated

Please enter password for sys user to continue:
xxxxxxxx
Contents of CLIENT_RESULT_CACHE_STATS$
STAT_ID    NAME OF STATISTICS      VALUE  CACHE_ID
=======    ==================      =====  ========
    1      Block Size                256    114
    2      Block Count Max          4096    114
    3      Block Count Current       128    114
    4      Hash Bucket Count        1024    114
    5      Create Count Success        2    114
    6      Create Count Failure        0    114
    7      Find Count                  4    114
    8      Invalidation Count          1    114
    9      Delete Count Invalid        0    114
   10      Delete Count Valid          0    114
Sleep 10sec...

Logging off all the connected sessions.
[oracle@lampeye demo]$ 

事前に起動していたSQL*Plusからclient_result_cache_stats$ビューを確認してみると…
お〜〜〜〜〜〜〜っ！、ちゃんと表示されています！！！！！。

感があたりました〜〜〜〜〜〜！ :)

・cdemoqc実行前
21:41:48 SYS> select * from client_result_cache_stats$;

レコードが選択されませんでした。

・cdemoqc実行直後
経過: 00:00:00.00
21:41:49 SYS> /

  CACHE_ID    STAT_ID NAME                                VALUE
---------- ---------- ------------------------------ ----------
       114          1 Block Size                              0
       114          2 Block Count Max                         0
       114          3 Block Count Current                     0
       114          4 Hash Bucket Count                       0
       114          5 Create Count Success                    0
       114          6 Create Count Failure                    0
       114          7 Find Count                              0
       114          8 Invalidation Count                      0
       114          9 Delete Count Invalid                    0
       114         10 Delete Count Valid                      0

10行が選択されました。


・60秒間待機している状態の時
経過: 00:00:00.00
21:41:54 SYS> /

  CACHE_ID    STAT_ID NAME                                VALUE
---------- ---------- ------------------------------ ----------
       114          1 Block Size                              0
       114          2 Block Count Max                         0
       114          3 Block Count Current                     0
       114          4 Hash Bucket Count                       0
       114          5 Create Count Success                    0
       114          6 Create Count Failure                    0
       114          7 Find Count                              0
       114          8 Invalidation Count                      0
       114          9 Delete Count Invalid                    0
       114         10 Delete Count Valid                      0

10行が選択されました。

・cdemoqcが、client_result_cache_stats$を表示した直後の10秒待機の時
経過: 00:00:00.00
21:42:53 SYS> /

  CACHE_ID    STAT_ID NAME                                VALUE
---------- ---------- ------------------------------ ----------
       114          1 Block Size                            256
       114          2 Block Count Max                      4096
       114          3 Block Count Current                   128
       114          4 Hash Bucket Count                    1024
       114          5 Create Count Success                    2
       114          6 Create Count Failure                    0
       114          7 Find Count                              4
       114          8 Invalidation Count                      1
       114          9 Delete Count Invalid                    0
       114         10 Delete Count Valid                      0

10行が選択されました。

・cdemoqcが終了した直後
経過: 00:00:00.00
21:42:59 SYS> /

レコードが選択されませんでした。

経過: 00:00:00.00
21:43:09 SYS> 

次回はさらに絞りこんで確認します。つづく〜

---

Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #1

Client result cache (クライアント結果キャッシュ）と client_result_cache_stats$の怪しい関係 #1

pga_aggregate_targetネタをやる予定が…client result cache（クライアント結果キャッシュ）ネタを先にやることにw

なにそれ？　美味しいのって感じの人はググって調べてもらうにしても

以下の辺りを見るとざっとなにが嬉しいのか分るかも :)
http://www.ooug.org/presentations/2010slides/Oracle_11g_Results_Cache.ppt

環境は、CentOS5.5 - Oracle11g R1 11.1.0.7.0 EEで、examplesを追加インストールして $ORACLE_HOME/rdbms/demo以下にcdemoqc.c及びcdemoqc.sqlをインストールしてあります。

あ、そうそう、今回の中心人物は、client_result_cache_stats$ビュー。クライアント結果キャッシュがどの程度効いているか客観的に判断するための統計情報が表示される。
http://download.oracle.com/docs/cd/E16338_01/server.112/b56311/statviews_2150.htm

さて、やっと本題です。

クライアント結果キャッシュがどの程度嬉しいのか確認する意味もあり、examplesをインストールして試し始めて、一番最初に悩みました。

examplesをインストールすると、クライアント結果キャッシュ用のOCIのデモプログラム cdemoqc.cを実行しても、client_result_cache_stats$ビューに該当クライアントのクライアント結果キャッシュの統計情報が表示されません。（表示されないというのは０件という意味ではなく、有るみたいなんだけど、値が０のままということなんです。見た瞬間人柱確定コースw)

クライアント結果キャッシュにクエリ結果がキャッシュされ、サーバとのラウンドトリップが無くなっているか確認したいだけなに、なんでハマるんじゃ〜w

と、叫びつつ。

cdemoqc.cのprint_stats()とその前に60秒スリープする部分のコメントを削除しました。

cdemoqc.cのオリジナルをcdemoqc.c.orgとしてdiffした結果。（とりあえず載せておきますねw）

[oracle@lampeye demo]$ diff cdemoqc.c.org cdemoqc.c
138d137
<   /*
144d142
<   */
[oracle@lampeye demo]$ 

実行した結果（makeし忘れないでね）。cdemoqc中からは60秒後にclient_result_cache_stats$の統計情報が確認できています。しか〜〜〜〜し！
（尚、事前に別xtermからSQL*Plusでsysユーザに接続、cdemoqc実行中に、client_reslut_cache_stats$ビューを確認します。）

[oracle@lampeye demo]$ ./cdemoqc
Query cache is enabled by using result_cache hints

Connected to Employee Session
Connected to HR Session

Employee: Execute will fetch rows from server
Employee: Execute will fetch rows from local cache
HR: Execute will cause a roundtrip during first execute, but the same result 
        set created in Employee Session will be shared thereafter
HR: Execute will fetch rows from local cache

HR: Updating the table

Employee: Execute will fetch rows from server and hence the local result set 
        will be updated
HR: Execute will fetch rows from updated local cache
Employee: Execute will fetch rows from local cache

Sleeping for few seconds to let the stat table to get updated

Please enter password for sys user to continue:
xxxxxxx

Contents of CLIENT_RESULT_CACHE_STATS$
STAT_ID    NAME OF STATISTICS      VALUE  CACHE_ID
=======    ==================      =====  ========
    1      Block Size                256    113
    2      Block Count Max          4096    113
    3      Block Count Current       128    113
    4      Hash Bucket Count        1024    113
    5      Create Count Success        2    113
    6      Create Count Failure        0    113
    7      Find Count                  4    113
    8      Invalidation Count          1    113
    9      Delete Count Invalid        0    113
   10      Delete Count Valid          0    113

Logging off all the connected sessions.
[oracle@lampeye demo]$ 

同じ時間で他のxtermの別セッションからclient_result_cache_stats$ビューを一生懸命問い合わせましたが、一度も統計情報にお目にかかれませんでした。
（以下のログからもわかるように、０件なのではなく同一CHACHE_IDの各列はリストされてはいるのですが、値が常に０のままなんです。）

・cdemoqc起動前
21:33:37 SYS> select * from client_result_cache_stats$;

レコードが選択されませんでした。

・cdemoqc起動直後
経過: 00:00:00.00
21:33:39 SYS> /

  CACHE_ID    STAT_ID NAME                                VALUE
---------- ---------- ------------------------------ ----------
       113          1 Block Size                              0
       113          2 Block Count Max                         0
       113          3 Block Count Current                     0
       113          4 Hash Bucket Count                       0
       113          5 Create Count Success                    0
       113          6 Create Count Failure                    0
       113          7 Find Count                              0
       113          8 Invalidation Count                      0
       113          9 Delete Count Invalid                    0
       113         10 Delete Count Valid                      0

10行が選択されました。

・cdemoqc側でclient_result_cache_stats$が表示された直後
経過: 00:00:00.00
21:33:46 SYS> /

  CACHE_ID    STAT_ID NAME                                VALUE
---------- ---------- ------------------------------ ----------
       113          1 Block Size                              0
       113          2 Block Count Max                         0
       113          3 Block Count Current                     0
       113          4 Hash Bucket Count                       0
       113          5 Create Count Success                    0
       113          6 Create Count Failure                    0
       113          7 Find Count                              0
       113          8 Invalidation Count                      0
       113          9 Delete Count Invalid                    0
       113         10 Delete Count Valid                      0

10行が選択されました。

・cdemoqc正常終了後
経過: 00:00:00.00
21:35:05 SYS> /

レコードが選択されませんでした。

経過: 00:00:00.00
21:35:12 SYS>

これでは、クライアント結果キャッシュが作成され、利用されているのか判断しにくいですよね〜。なんで他プロセスの別セッションからclient_result_cache_stats$の内容が見えないのでしょう？
（cdempqc.cの作りからして、きな臭い匂いがしませんか〜w　マニュアルにも書かれていないけど〜いろんな仕掛けがありそーですぞ〜。）

ということで、原因を突き止めたので、次回からじわじわ追いつめていきますw

つづく。

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #19

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その１９回目、

そして、あっという間に、Oracle11g R2の自動メモリー管理を無効、自動PGAメモリー管理有効状態での確認も最終回！
前回、_pga_max_sizeの50%になってしまったpga_aggregate_targetを16GB/4095GBに設定した場合のテストを_pga_max_sizeを調整してpga_aggregate_targetの20%が利用される状態にして再び確認して終わりにしたいと思います。

SYS> alter system set "_pga_max_size"=6554m;

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

SYS> alter system set pga_aggregate_target=16g;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            6554M
pga_aggregate_target                 big integer            16G
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                          16384
aggregate PGA auto target                          14721.3281
global memory bound                                 3276.7998

SYS> alter system set "_pga_max_size"=1677313m;

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

SYS> alter system set pga_aggregate_target=4095g;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            1677313M
pga_aggregate_target                 big integer            4095G
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                        4193280
aggregate PGA auto target                          3773918.79
global memory bound                                    838656

SYS>


・・・中略・・・

SCOTT> @test4

SQL_TEXT                                 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 30000 SORT (v2)                 1171.63
0 order by code

SCOTT>

Oracle10g R2以降は32bitでも64bitでも、自動メモリー管理が無効で、自動PGAメモリー管理が有効ならば、かつNon parallelならば、LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5)とう条件で作業域を割り当てているのは確からしい。

次回は、ちょっと別の角度から。ということで次回へつづく。

---

前回までのあらすじ・・・
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #16
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #17
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #18

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #18

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その１８回目、

Oracle11g R2での検証の続き。まいどおなじみ、_pga_max_sizeを大きな値にして、pga_aggregate_targetの20%がglobal memory boundに設定されるようにして確認。

SYS> alter system set "_pga_max_size"=3840m;

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

SYS> alter system set pga_aggregate_target=256m;

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

SYS> alter system flush shared_pool;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            3840M
pga_aggregate_target                 big integer            256M
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                            256
aggregate PGA auto target                          206.173828
global memory bound                                51.1992188

SYS>
SYS> alter system set pga_aggregate_target=512m;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            3840M
pga_aggregate_target                 big integer            512M
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                            512
aggregate PGA auto target                          436.869141
global memory bound                                102.399414

SYS> alter system set pga_aggregate_target=768m;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            3840M
pga_aggregate_target                 big integer            768M
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                            768
aggregate PGA auto target                          667.212891
global memory bound                                153.599609

SYS>
SYS> alter system set pga_aggregate_target=1g;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            3840M
pga_aggregate_target                 big integer            1G
SYS> @pgastat



NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                           1024
aggregate PGA auto target                          897.591797
global memory bound                                204.799805

SYS> alter system set pga_aggregate_target=2g;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            3840M
pga_aggregate_target                 big integer            2G
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                           2048
aggregate PGA auto target                           1820.0127
global memory bound                                409.599609

SYS>
SYS> alter system set pga_aggregate_target=4g;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            3840M
pga_aggregate_target                 big integer            4G
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                           4096
aggregate PGA auto target                          3662.25293
global memory bound                                819.199219

SYS> alter system set pga_aggregate_target=8g;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            3840M
pga_aggregate_target                 big integer            8G
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                           8192
aggregate PGA auto target                          7349.43164
global memory bound                                1638.39941

やはりここで変化あり！

SYS> 
SYS> alter system set pga_aggregate_target=16g;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            3840M
pga_aggregate_target                 big integer            16G
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                          16384
aggregate PGA auto target                          14722.1543
global memory bound                                      1920

SYS> alter system set pga_aggregate_target=4095g;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            3840M
pga_aggregate_target                 big integer            4095G
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                        4193280
aggregate PGA auto target                           3773917.1
global memory bound                                      1920

SYS>

Oracle11g R1と同じ結果になりましたね。LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5) ということね。Oracle11g R2でも。
次回へつづく。

---

前回までのあらすじ・・・
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #16
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #17

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #17

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その１７回目、

Oracle11g R2　自動メモリー管理は無効、自動PGAメモリー管理は有効な状態での検証スタート！

いつものように、_pga_max_sizeはデフォルトの200MBで、pga_aggregate_targetを10MBから4095MBまで増加させてglobal memory boundがどのように変化するか確認します！

SYS> alter system set pga_aggregate_target=10m;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            200M
pga_aggregate_target                 big integer            10M
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                             10
aggregate PGA auto target                                   4
global memory bound                                         2

SYS> alter system set pga_aggregate_target=20m;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            200M
pga_aggregate_target                 big integer            20M
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                             20
aggregate PGA auto target                                   4
global memory bound                                         4

SYS> alter system set pga_aggregate_target=40m;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            200M
pga_aggregate_target                 big integer            40M
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                             40
aggregate PGA auto target                          12.8583984
global memory bound                                         8

SYS> alter system set pga_aggregate_target=256m;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            200M
pga_aggregate_target                 big integer            256M
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                            256
aggregate PGA auto target                          207.263672
global memory bound                                51.1992188

SYS> alter system set pga_aggregate_target=512m;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            200M
pga_aggregate_target                 big integer            512M
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                            512
aggregate PGA auto target                          436.851563
global memory bound                                       100

SYS>

お、変化ありました。Oracle11g R2でも自動PGAメモリー管理の動きは同じみたいね。

どんどんやっつけちゃいましょー

SYS> alter system set pga_aggregate_target=768m;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            200M
pga_aggregate_target                 big integer            768M
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                            768
aggregate PGA auto target                          667.283203
global memory bound                                       100

SYS> alter system set pga_aggregate_target=1g;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            200M
pga_aggregate_target                 big integer            1G
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                           1024
aggregate PGA auto target                          897.688477
global memory bound                                       100

SYS> alter system set pga_aggregate_target=2g;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            200M
pga_aggregate_target                 big integer            2G
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                           2048
aggregate PGA auto target                          1819.87207
global memory bound                                       100

SYS> alter system set pga_aggregate_target=4g;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            200M
pga_aggregate_target                 big integer            4G
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                           4096
aggregate PGA auto target                          3662.25293
global memory bound                                       100

SYS> alter system set pga_aggregate_target=8g;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            200M
pga_aggregate_target                 big integer            8G
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                           8192
aggregate PGA auto target                          7349.43164
global memory bound                                       100

SYS> alter system set pga_aggregate_target=16g;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            200M
pga_aggregate_target                 big integer            16G
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                          16384
aggregate PGA auto target                          14721.3457
global memory bound                                       100

SYS> alter system set pga_aggregate_target=2095g;

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

SYS> show parameter pga

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size                        big integer            200M
pga_aggregate_target                 big integer            2095G
SYS> @pgastat

NAME                                                 size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter                        2145280
aggregate PGA auto target                          1930719.63
global memory bound                                       100

SYS>

そして、念のため実際にソート！　glolbal memory boundに設定されたサイズになってますね〜。

SCOTT> @test2

SQL_TEXT                                 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT (v2)                  100.02         409993216        409993216
0 order by code

SCOTT>

次回へつづく。

---

前回までのあらすじ・・・
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #16

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #16

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その１６回目、

今回からOracle11g R2 for Windows 32bit環境での検証です。なお、自動メモリー管理(AMM)はOFFで自動SGAメモリー管理(ASMM)、自動PGAメモリー管理(APMM)は有効になっています。
この状態でOracle11g R1までと動きに違いがないかみてみることにします。

SYS> select * from v$version;

BANNER
----------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

SYS>

ダブルアンダースコアの隠しパラメータがが気味悪いw　ですが、たぶん影響しないんじゃないかと。もともとOracle側で制御しているパラメータだし。

SYS> @show_param

KSPPINM                          KSPPSTVL                         KSPPSTDF
-------------------------------- -------------------------------- --------------------------------
_4031_sga_dump_interval          3600                             TRUE
_4031_sga_max_dumps              10                               TRUE
__pga_aggregate_target           79691776                         TRUE
__sga_target                     239075328                        TRUE
_kdli_sio_pga                    FALSE                            TRUE
_kdli_sio_pga_top                FALSE                            TRUE
_ldr_pga_lim                     0                                TRUE
_lock_sga_areas                  0                                TRUE
_memory_imm_mode_without_autosga TRUE                             TRUE
_memory_initial_sga_split_perc   60                               TRUE
_memory_nocancel_defsgareq       FALSE                            TRUE
_pga_large_extent_size           1048576                          TRUE
_pga_max_size                    209715200                        TRUE
_pgactx_cap_stacks               FALSE                            TRUE
_sga_clear_dump                  FALSE                            TRUE
_sga_early_trace                 0                                TRUE
_sga_locking                     none                             TRUE
_use_ism_for_pga                 TRUE                             TRUE
lock_sga                         FALSE                            TRUE
memory_max_target                0                                TRUE
memory_target                    0                                TRUE
pga_aggregate_target             78643200                         FALSE
pre_page_sga                     FALSE                            TRUE
sga_max_size                     239075328                        TRUE
sga_target                       239075328                        FALSE

25行が選択されました。

SYS>
SYS> show parameter workarea_size_policy

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
workarea_size_policy                 string                 AUTO
SYS>

次回へつづく。

---

前回までのあらすじ・・・
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #15

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その１５回目、

さて、Oracle11g R1での検証もいよいよ最終回。　
前回、_pga_max_sizeが3840MBで、pga_aggregate_targetを16GB/4095GBとしたところで、_pga_max_sizeの50%がglobal memory boundとして設定されていました。
じゃ、最後の２でもpga_aggregate_targetの20%をglobal memory boundとして利用するようにしちゃえ！

ということで、_pga_max_sizeを6554MB/1677313MB、pga_aggregate_targetを16GB/4096GBとしてギリギリでpga_aggregate_targetの20%が利用されるように設定してみました。
以下の通り、global memory boundは、pga_aggregate_targetの20%である、3276.8MB/838656MBになってます！

SYS> alter system set "_pga_max_size"=6554m;

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

SYS> alter system set pga_aggregate_target=16g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 6554M
pga_aggregate_target		     big integer 16G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				16384
aggregate PGA auto target			   14720.7744
global memory bound				    3276.7998

SYS>


SYS> alter system set "_pga_max_size"=1677313m;

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

SYS> alter system set pga_aggregate_target=4095g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 1677313M
pga_aggregate_target		     big integer 4095G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter			      4193280
aggregate PGA auto target			   3773917.72
global memory bound				       838656

SYS> 

最後に、実メモリ768MBしか積んでないマシンなのに無理矢理、1GB越えのPGAを利用してもらっちゃいます。
当然ですが、swapしまくりなので、普通の時間でレスポンスなんて戻ってきませんから真似しないようにw　swapを使ってDISKガリガリいってましたがOracle上ではちゃんとOPTIMALとなっておりますはい！。

SCOTT> @test4

SQL_TEXT				 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 30000 SORT (v2)		   1171.63
0 order by code

SCOTT> 

ということで、次回、Oracle11g R2 for Linux x86の自動メモリー管理(AMM)下でどうなるか確認と、思ったのですが、ちょうど　Oracle11g R2 for Windows (32bit)がダウンロードできるようになっていたので、急遽、Oracle11g R2 for Windows(32bit)かつ、自動メモリー管理をオフにした状態ではどうなるか確認してみましょう。なを32bitのWindowsなのでSGA/PGA合わせて2GB超えないような範囲で遊びマッス！。

なんか久々に１ヶ月ものぐらいのネタに膨らまそうか考えてたりして・・・・。

次回へつづく。

---

前回までのあらすじ・・・
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #14

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

_pag_max_sizeに大きな値を設定し、LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5)という条件で割り当てられていることを確認してみます！

SYS> alter system flush shared_pool;

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

SYS> alter system set "_pga_max_size"=3840m;

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

SYS> alter system set pga_aggregate_target=256m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 256M
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				  256
aggregate PGA auto target			   205.734375
global memory bound				   51.1992188

SYS> alter system set pga_aggregate_target=512m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 512M
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				  512
aggregate PGA auto target			   435.700195
global memory bound				   102.399414

SYS> alter system set pga_aggregate_target=768m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 768M
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				  768
aggregate PGA auto target			   666.518555
global memory bound				   153.599609

SYS> alter system set pga_aggregate_target=1g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 1G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 1024
aggregate PGA auto target			    896.52832
global memory bound				   204.799805

SYS> alter system set pga_aggregate_target=2g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 2G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 2048
aggregate PGA auto target			   1818.44824
global memory bound				   409.599609

SYS> alter system set pga_aggregate_target=4g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 4G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 4096
aggregate PGA auto target			   3735.43555
global memory bound				   819.199219

SYS> alter system set pga_aggregate_target=8g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 8G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 8192
aggregate PGA auto target			   7347.50684
global memory bound				   1638.39941

まちがいなく、pga_aggregate_targetの20%がglobal memory boundに設定されてます！

さて、pga_aggregate_targetを16GB以上に設定すると、_pga_max_sizeの50%より、pga_aggregate_targetの20%の方が大きくなるため、_pga_max_sizeパラメータの50%のサイズがglobal memory boundに設定されるはず！　ではやってみよう！

SYS> alter system set pga_aggregate_target=16g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 16G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				16384
aggregate PGA auto target			   15023.2441
global memory bound					 1920

SYS> alter system set pga_aggregate_target=4095g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 4095G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter			      4193280
aggregate PGA auto target			   3773917.55
global memory bound					 1920

SYS> 

予想通り、_pga_max_sizeの50%がglobal memory boundに設定されてますね。
Oracle11g R1での検証もいよいよ次回が最終回。ということで、次回へつづく。

---

前回までのあらすじ・・・
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #13

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その１３回目、

_pga_max_sizeはデフォルトのままで、pga_aggregate_targetを増加させていくと、Oracle10g R2と同様に、LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5)という条件で割り当てられてるようだ。ということでその確認のつづき。

pga_aggregate_targetが512MBになったところで、_pga_max_sizeの200MBの50%のサイズがglobal memory boundとして設定されるようになった。さらに増加させてその割合に変化がないか確認していく。

SYS> alter system set pga_aggregate_target=768m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 768M
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				  768
aggregate PGA auto target			   666.720703
global memory bound					  100

SYS> alter system set pga_aggregate_target=1g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 1G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 1024
aggregate PGA auto target			   896.677734
global memory bound					  100

SYS> alter system set pga_aggregate_target=2g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 2G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 2048
aggregate PGA auto target			   1818.26367
global memory bound					  100

SYS> alter system set pga_aggregate_target=4g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 4G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 4096
aggregate PGA auto target			   3661.89258
global memory bound					  100

SYS> alter system set pga_aggregate_target=8g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 8G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 8192
aggregate PGA auto target			   7348.25391
global memory bound					  100

SYS> alter system set pga_aggregate_target=16g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 16G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				16384
aggregate PGA auto target			   14720.5371
global memory bound					  100

pga_aggregate_targetを16GBにしても、_pga_max_sizeの50%のサイズである100MBがglobal memory boundに設定されていますね。

最後に、pga_aggregate_targetを4095GBにしてみると〜

SYS> alter system set pga_aggregate_target=4095g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 4095G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter			      4193280
aggregate PGA auto target			   3773918.45
global memory bound					  100

SYS> 

・・・中略・・・

SCOTT> @test2

SQL_TEXT				 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT (v2)		    100.02	   409993216	    409993216
0 order by code

SCOTT> 

やはり、global memory boundは、_pga_max_sizeの50%のままですね。_pga_max_sizeを大きなサイズにし、pga_aggregate_targetの20%が利用されるかを確認しますよ〜。ということで次回へつづく。

---

前回までのあらすじ・・・
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #12

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その１２回目、

さて、Oracle11g R1 for Linux x86を利用した検証を始めるよ〜　:)

これまでと同様に、まず、_pga_max_sizeはデフォルトの200MBのままで、pga_aggregate_targetを10MB/20MB/40MB/256MB/512MBと増加させてglobal memory boundがどう変化するか確認していく。

SYS> alter system set pga_aggregate_target=10m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 10M
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				   10
aggregate PGA auto target				    4
global memory bound					    2

SYS> alter system set pga_aggregate_target=20m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 20M
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				   20
aggregate PGA auto target				    4
global memory bound					    4

SYS> alter system set pga_aggregate_target=40m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 40M
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				   40
aggregate PGA auto target			   11.3720703
global memory bound					    8

SYS> 

ここまでのところ、 pga_aggregate_targetの20%がglobal memory boundとして設定されている。

次ぎいってみよー！

SYS> alter system set pga_aggregate_target=256m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 256M
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				  256
aggregate PGA auto target			   205.479492
global memory bound				   51.1992188

SYS> alter system set pga_aggregate_target=512m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 512M
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				  512
aggregate PGA auto target			    436.31543
global memory bound					  100

お、やはり、変化しました。 512MBの20%は、102.4MBですが、global memory boundに設定された値は、100MB。　_pga_max_sizeの50%ですね〜。
おそらく、Oracle10g R1と同じ割当条件なんでしょうね。

次回はpga_aggregate_targetパラメータをさらに増加させてみますよ。。つづく。

---

前回までのあらすじ・・・
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #11

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その１１回目、

さて、Oracle10g R2までは試したので、今回からはOracle11g R1で試します。利用したのはOracle11g R1 for Linux x86.

いつものように現状確認と、登録済みデータの確認から。自動メモリー管理が有効は無効にしてあります。自動SGA管理と自動PGA管理は有効になってますよー。
というか少なくとも自動PGA管理は有効にしておかないとこの検証自体が・・・・w

dSYS> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
PL/SQL Release 11.1.0.7.0 - Production
CORE	11.1.0.7.0	Production
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production

SYS> 
SYS> @show_param

KSPPINM 			 KSPPSTVL			KSPPSTDF
-------------------------------- ------------------------------ ------------------------------
_4031_sga_dump_interval 	 3600				TRUE
_4031_sga_max_dumps		 10				TRUE
__pga_aggregate_target		 104857600			FALSE
__sga_target			 352321536			FALSE
_kdli_sio_pga			 FALSE				TRUE
_kdli_sio_pga_top		 FALSE				TRUE
_lock_sga_areas 		 0				TRUE
_memory_initial_sga_split_perc	 60				TRUE
_memory_nocancel_defsgareq	 FALSE				TRUE
_pga_large_extent_size		 1048576			TRUE
_pga_max_size			 209715200			FALSE
_sga_clear_dump 		 FALSE				TRUE
_sga_early_trace		 0				TRUE
_sga_locking			 none				TRUE
_use_ism_for_pga		 TRUE				TRUE
lock_sga			 FALSE				TRUE
memory_max_target		 0				TRUE
memory_target			 0				TRUE
pga_aggregate_target		 104857600			FALSE
pre_page_sga			 FALSE				TRUE
sga_max_size			 352321536			TRUE
sga_target			 352321536			FALSE

22行が選択されました。

SYS> show parameter workarea_size_policy

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
workarea_size_policy		     string	 AUTO
SYS> 

とりあえず、200000万件、1.6GBほどのデータを登録してあります。

SCOTT> select count(*) from code;

  COUNT(*)
----------
    200000

SCOTT> l
  1  select
  2    blocks*block_size/1024/1024 as "table_size(MB)"
  3  from
  4    user_tables ut join user_tablespaces uts
  5    on ut.tablespace_name = uts.tablespace_name
  6*   and ut.table_name = 'CODE'
SCOTT> /

table_size(MB)
--------------
      1600.625

SCOTT> 

次回へつづく。

---

前回までのあらすじ・・・
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #10

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その１０回目、

前回までで、Oracle10g R2では、LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5)という条件でPGAの作業領域を割り当てているらしいというところまでは確認できた。
今回は、隠しパラメータ、 _pga_max_sizeパラメータを3840MBという大きな値に設定し、 pga_aggregate_targetの20%が利用されるか確認してみた。

_pga_max_sizeを3840MBと設定し、pga_aggregate_targetを256MB/512MB/768MB/1G/2G/4G/8G/16Gと増加させた場合、常に1920MB(_pga_max_size*0.5)より小さくなるのでpga_aggregate_target*0.2のサイズがglobal memory boundとして設定されるはず。

では、早速確認してみる。

SYS> alter system flush shared_pool;

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

SYS> alter system set "_pga_max_size"=3840m;

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

SYS> alter system set pga_aggregate_target=256m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 256M
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				  256
aggregate PGA auto target			       213.75
global memory bound				   51.1992188

SYS> alter system set pga_aggregate_target=512m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 512M
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				  512
aggregate PGA auto target			   444.155273
global memory bound				   102.399414

SYS> alter system set pga_aggregate_target=768m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 768M
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				  768
aggregate PGA auto target			   685.213867
global memory bound				   153.599609

SYS> alter system set pga_aggregate_target=1g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 1G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 1024
aggregate PGA auto target			   919.334961
global memory bound				   204.799805

SYS> alter system set pga_aggregate_target=2g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 2G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 2048
aggregate PGA auto target			    1826.8418
global memory bound				   409.599609

SYS> alter system set pga_aggregate_target=4g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 4G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 4096
aggregate PGA auto target			   3669.74121
global memory bound				   819.199219

SYS> alter system set pga_aggregate_target=8g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 8G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 8192
aggregate PGA auto target			   7472.14941
global memory bound				   1638.39941

SYS> alter system set pga_aggregate_target=16g;

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

SYS> show parameter pga                 

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 16G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				16384
aggregate PGA auto target			    14729.168
global memory bound					 1920

SYS> 

実メモリ２GBしか積んでないので3.2GB近くのPGAサイズが割り当てられるか実際のテストはちょいとだけ無理をして1GBぐらいを目指してみた…

SYS> alter system flush shared_pool;

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

SYS> alter system set pga_aggregate_target=6g;

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

SYS> 
SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 3840M
pga_aggregate_target		     big integer 6G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 6144
aggregate PGA auto target			   5513.83594
global memory bound				    1228.7998

SYS> 

・・・中略・・・

SCOTT> @test4

SQL_TEXT				 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 30000 SORT (v2)		   1171.63
0 order by code

1GB以上のPGAが利用されたところまでは確認できた〜〜。ということで、

Oracle10g R2において、１セッションでパラレルクエリでなければ、LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5)という条件でPGAを割り当てているのは確からしい。

今回で、Oracle10g R2 for MacOS X Server x86-64での検証はおわり、Oracle11g R1 for Linux x86で試してみようと思う。なお自動メモリー管理(AMM)は利用していない構成にしてある。ということで次回へつづく。

---

前回までのあらすじ・・・
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #9

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その９回目、

_pga_max_sizeはデフォルトの200MBのままで、pga_aggregate_targetを256MB/512MB/768MB/1GB/2GB/4GB/8GB/16GB/4095GBと増加させてみる。

Oracle10g R2 for MacOS X x86_64版では、Oracle10g R1までと違い、pga_aggregate_target * 0.2を割り当てているということまでは見る事ができた。
以前のリリースのように _pga_max_size * 0.5と比べて小さい値を使うのだと仮定すれば、　LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5)となっているんでしょうね。きっと。

とすると… 256MB/512MB/768MB/1GB/2GB/4GB/8GB/16GB/4095GBとpga_aggregate_targetを増加させると、256MBの場合だけ _pga_max_size * 0.5 を下回る。pga_aggregate_targetが512MB以上、かつ_pga_max_sizeがデフォルトの200MBの場合、global memory boundは常に100MBになるはず。

じゃ、確かめてみよう！

SYS> alter system set pga_aggregate_target=256m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 256M
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				  256
aggregate PGA auto target			   213.855469
global memory bound				   51.1992188

SYS> 

SYS> alter system set pga_aggregate_target=512m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 512M
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				  512
aggregate PGA auto target			   443.979492
global memory bound					  100

やはり、ここで変化しましたね！

SYS> alter system set pga_aggregate_target=768m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 768M
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				  768
aggregate PGA auto target			   674.384766
global memory bound					  100

SYS> alter system set pga_aggregate_target=1g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 1G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 1024
aggregate PGA auto target			   905.053711
global memory bound					  100

SYS> alter system set pga_aggregate_target=2g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 2G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 2048
aggregate PGA auto target			   1826.63965
global memory bound					  100

SYS> alter system set pga_aggregate_target=4g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 4G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 4096
aggregate PGA auto target			   3669.82031
global memory bound					  100

SYS> alter system set pga_aggregate_target=8g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 8G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 8192
aggregate PGA auto target			   7356.19043
global memory bound					  100

SYS> alter system set pga_aggregate_target=16g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 16G
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				16384
aggregate PGA auto target			   14728.9131
global memory bound					  100

SYS> 

・・・中略・・・

SCOTT> @test2

SQL_TEXT				 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT (v2)		    100.02	   409993216	    409993216

0 order by code

SCOTT> 

・・・中略・・・

SYS> alter system flush shared_pool;

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

SYS> alter system set pga_aggregate_target=4095g;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 4095G
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter			      4193280
aggregate PGA auto target			   3773925.04
global memory bound					  100

・・・中略・・・

SCOTT> @test2

SQL_TEXT				 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT (v2)		    100.02	   409993216	    409993216
0 order by code

SCOTT> 

予想通り、 LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5) となっている模様〜。まだまだつづきますよ〜 :)

---

前回までのあらすじ・・・
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #8

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その８回目、

Oracle10g R1の場合と同様に、_pga_max_sizeパラメータはデフォルト(200BMMB)のまま、pga_aggregate_targetを10MBスタートして増加させて確認していきますよ〜。

SYS> alter system set pga_aggregate_target=10m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 10M
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				   10
aggregate PGA auto target				    4
global memory bound					    2

SYS> 

・・・中略・・・

SCOTT> @test2

SQL_TEXT				 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT (v2)		      2.01	   409993216	    409993216
0 order by code

SCOTT> 

あれ、Oracle10g R1までの頃と割り当てられてるサイズが違う！　pga_aggregate_targetが10MBなのに0.5MBではなく、2MB。つまり20%が割り当てられてます。

SYS> alter system flush shared_pool;

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

SYS> alter system set pga_aggregate_target=20m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 20M
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				   20
aggregate PGA auto target				    4
global memory bound					    4

・・・中略・・・

SCOTT> @test2

SQL_TEXT				 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT (v2)		      4.04	   409993216	    409993216
0 order by code

SCOTT> 

・・・中略・・・

SYS> alter system flush shared_pool;

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

SYS> alter system set pga_aggregate_target=40m;

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

SYS> show parameter pga

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size			     big integer 200M
pga_aggregate_target		     big integer 40M
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				   40
aggregate PGA auto target			   18.4570313
global memory bound					    8

・・・中略・・・

SCOTT> @test2

SQL_TEXT				 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT (v2)		      8.04	   409993216	    409993216
0 order by code

SCOTT> 

Oracle10g R1までの頃より、pgaの作業領域が大きく確保されるようになってるということもある程度見えましたが、まだばだ続きます。

注）パラレルクエリの場合はちょいと違いますからご注意を。余裕があったらやるかもしれないけど。:)

---

前回までのあらすじ・・・
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #7

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その７回目、

今回からOracle10g R2での検証、環境は以下。

Oracle10g R2 for MacOS X Server (x86_64) / MacOS X 10.6.3 Core2 Duo 2.2Ghz RAM:2GB

手順はOracle10g R1の場合と同じだが、多少順番が前後したり設定するサイズは変更しながら行うかもしれないのであしからず。

SYS> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE	10.2.0.4.0	Production
TNS for MacOS X Server: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

SYS> 

Oracle10g R1 for MacOS X Serverの場合と同じテスト表とデータを用意してっ、と。

SCOTT> 
SCOTT> create table code (code varchar2(4000));

表が作成されました。

SCOTT> 
SCOTT> begin for i in 1..100000 loop insert into code values(lpad('#',4000,'#')); end loop; commit; end;
  2  /

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'CODE',degree=>2,estimate_percent=>100);

PL/SQLプロシージャが正常に完了しました。

SCOTT> 
SCOTT> l
  1  select
  2    blocks*block_size/1024/1024 as "table_size(MB)"
  3  from
  4    user_tables ut join user_tablespaces uts
  5    on ut.tablespace_name = uts.tablespace_name
  6*   and ut.table_name = 'CODE'
SCOTT> /

table_size(MB)
--------------
    788.101563

SCOTT> 

テスト開始まえの関連パラメータの値は以下のような状態になってます。

SYS> @show_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ------------------------------
_4031_sga_dump_interval        3600			      TRUE
_4031_sga_max_dumps	       10			      TRUE
_lock_sga_areas 	       0			      TRUE
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       209715200		      FALSE
_use_ism_for_pga	       TRUE			      TRUE
lock_sga		       FALSE			      TRUE
pga_aggregate_target	       104857600		      FALSE
pre_page_sga		       FALSE			      TRUE
sga_max_size		       612368384		      TRUE
sga_target		       612368384		      FALSE

11行が選択されました。

SYS> show parameter workarea_size

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
workarea_size_policy		     string	 AUTO
SYS> 

引っ張るメソッドはいつもと同じということで、Oracle10g R2編、次回へつづく。 :)

---

前回までのあらすじ・・・
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #6

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その６回目、

前回までで、Oracle10g R1 (32bit)がpga_aggregate_targetパラメータと_pga_max_sizeパラメータをどのように使ってpgaの作業領域を割り当てているか見えたのですが、念押しでもういっちょw.

_pga_max_size * 50% が使われるというところをデフォルトの200MB以外でも確認して、Oracle10g R1 (32bit)での検証はおわりにしたい。:)

_pga_max_sizeパラメータは隠しパラメータなのでOracle Supportの指示なしには変更しないパラメータ、遊ぶ場合は、趣味の環境等でやってね :)

_pga_max_sizeを400MB/800MBと変更し、pga_aggregate_targetも4GB/8GBと設定する。Oracleがきまぐれで割り当てていないのであれば、 LEAST(_pga_max_size*0.5, pga_aggregate_target*0.05)より、200MB/400MBがglobal memory boundとして設定されるはず。

SYS> alter system set "_pga_max_size" = 400m;

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

SYS> alter system set pga_aggregate_target = 4g;

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

SYS> shutdown
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area  293601280 bytes
Fixed Size		     778888 bytes
Variable Size		  116137336 bytes
Database Buffers	  176160768 bytes
Redo Buffers		     524288 bytes
データベースがマウントされました。
データベースがオープンされました。
SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       400M
pga_aggregate_target		     big integer		       4G
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 4096
aggregate PGA auto target			   3673.17773
global memory bound					  200

SYS> 

・・・中略・・・

SCOTT> @test2

SQL_TEXT				 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT			    172.89	   409993216	    409993216
0 order by code

・・・中略・・・

SYS> alter system set "_pga_max_size" = 800m;

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

SYS> alter system set pga_aggregate_target = 8g;

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

SYS> shutdown
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area  293601280 bytes
Fixed Size		     778888 bytes
Variable Size		  116137336 bytes
Database Buffers	  176160768 bytes
Redo Buffers		     524288 bytes
データベースがマウントされました。
データベースがオープンされました。
SYS> 
SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       800M
pga_aggregate_target		     big integer		       8G
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 8192
aggregate PGA auto target			   7359.09961
global memory bound					  400

SYS> 

・・・中略・・・

SCOTT> @test2

SQL_TEXT				 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT			    370.66	   409993216	    409993216
0 order by code

ということで、Oracle10g R2 編へつづく。

---

前回までのあらすじ・・・
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #5

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その５回目、

Oracle10g R1 (32bit)で、pga_aggregate_targetを40MBから一気に上限に近い4095GBに増加させたところで、global memory boundへの割当割合が変化した。

今回は、pga_aggregate_targetを1GBから16GBそして、後半では、_pga_max_sizeも増加させてどう変化するか確認してみることに。

_pga_max_sizeパラメータは隠しパラメータなのでOracle Supportの指示なしには変更しないパラメータ、遊ぶ場合は、趣味の環境等でやってね :)

あ、ところで、なんでPGAネタを始めたかって？　知りたいですか？　

実は、先日、インフラ担当（Oracleにはかなり詳しいと思われる）の方と話していて、pga_aggregate_targetの話題になったとき、その方が、「そーゆー、都市伝説みたいな話があるよね〜、キッパリ！」、みたいなノリで話していたので、私：「そんな事ないよー、都市伝説みたいじゃなくて都市伝説だよ（ウソウソ）、ほんととうにそう動いてるよ〜」、という話をしていて、どーしても書かなきゃ！、という気持ちになったのでした〜。それ以外に、第一回目でもちょっと書きましたが、10g r2ではちょいと変わったとか...いう話もあったし。（マニュアルにも書いてないし、Oracleに完全お任せでいいかというと、性能問題に絡んでくるちょいといやらしいとこなので）

余談はこのくらいにして、実験再開。

実際にソート処理をさせなくても、いままでの結果から、global memory boundの値が自動PGAメモリー管理では重要な意味があることは確認できたと思うので、毎回ソート処理を行わないで進めます。（適当な所で実際にソートしてみます！）

Oracle10g R1も9iと同様に、MIN(pga_aggregate_target * 0.05, _pga_max_size * 0.5)という条件で割り当てているのはほぼ確実なので、_pga_max_size=200MB (デフォルト）のままで、pga_aggregate_targetを1GB/2GB/4GB/8GB/16GBと増加させた場合、_pga_max_size * 0.5 = 100MBを下回るのは、pga_aggregate_targetに1GBを指定した場合のみなので、Oracleが気まぐれにglobal memory boundを設定しているのでなければ、global memory boundは、51.2BM/100MB/100MB/100MB/100MBという変化になるはず！

---

2010/5/8追記：
MIN(pga_aggregate_target * 0.05, _pga_max_size * 0.5)という表現よりSQLなら
LEAST(pga_aggregate_target * 0.05, _pga_max_size * 0.5)こっちの方がいいな次ぎからLEASTにする。

---

ということを脳のcacheにKEEPした上で、以下をご覧ください。

SYS> alter system set pga_aggregate_target=1g;

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

SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       200M
pga_aggregate_target		     big integer		       1G

SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 1024
aggregate PGA auto target			     908.4375
global memory bound				   51.1992188

SYS> 
SYS> 
SYS> alter system set pga_aggregate_target=2g;

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

SYS> 
SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       200M
pga_aggregate_target		     big integer		       2G
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 2048
aggregate PGA auto target			    1830.2168
global memory bound					  100

SYS> 
SYS> alter system set pga_aggregate_target=4g;

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

SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       200M
pga_aggregate_target		     big integer		       4G
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 4096
aggregate PGA auto target			   3673.33594
global memory bound					  100

SYS> 
SYS> alter system set pga_aggregate_target=8g;

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

SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       200M
pga_aggregate_target		     big integer		       8G
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 8192
aggregate PGA auto target			   7359.69727
global memory bound					  100

SYS> 
SYS> alter system set pga_aggregate_target=16g;

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

SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       200M
pga_aggregate_target		     big integer		       16G
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				16384
aggregate PGA auto target			   14732.2793
global memory bound					  100

SYS> 
SYS> 

・・・中略・・・

SCOTT> @test2

SQL_TEXT				 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT			     97.58	   409993216	    409993216
0 order by code

やった〜！、予想通り！！！　:)

さらに念押し、pga_aggregate_target * 5%が　_pga_max_size * 50%　より小さくなるようにして、さらに変化を見る。

16GB * 5% = 819.2MB なので 820MB * 2 = 1640MB を _pga_max_sizeパラメータに設定すればいろいろと見えるよね。たぶん。

MacOS X版Oracle10g R1だけかもしれないけど？（未確認なので）、動的に変わるはず（と思っている）_pga_max_sizeがどうも静的なので、Oracle10g R1では　_pga_max_sizeを変更した場合は必ず、インスタンスを再起動しています。 (^^;;;;

_pga_max_sizeを1640MBに設定後、pga_aggregate_targetを1GB/2GB/4GB/8GB/16GBと増加させます。Oracleが気まぐれでglobal memory boundを設定していなければ、global memory boundの値は、51.2MB/102.4MB/204.8MB/409.6MB/819.2MBという変化を見せてくれるはず。

SYS> alter system set "_pga_max_size"=1640m;

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

SYS> alter system set pga_aggregate_target=1g;

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

SYS> shutdown
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area  293601280 bytes
Fixed Size		     778888 bytes
Variable Size		  116137336 bytes
Database Buffers	  176160768 bytes
Redo Buffers		     524288 bytes
データベースがマウントされました。
データベースがオープンされました。
SYS> 
SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       1640M
pga_aggregate_target		     big integer		       1G
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 1024
aggregate PGA auto target			   907.892578
global memory bound				   51.1992188

SYS> alter system set pga_aggregate_target=2g;

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

SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       1640M
pga_aggregate_target		     big integer		       2G
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 2048
aggregate PGA auto target			   1829.30273
global memory bound				   102.399414

SYS> 
SYS> alter system set pga_aggregate_target=4g;

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

SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       1640M
pga_aggregate_target		     big integer		       4G
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 4096
aggregate PGA auto target			    3672.4834
global memory bound				   204.799805

SYS> 
SYS> alter system set pga_aggregate_target=8g;

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

SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       1640M
pga_aggregate_target		     big integer		       8G
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				 8192
aggregate PGA auto target			   7358.87988
global memory bound				   409.599609

SYS> 
SYS> alter system set pga_aggregate_target=16g;

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

SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       1640M
pga_aggregate_target		     big integer		       16G
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				16384
aggregate PGA auto target			   14731.6289
global memory bound				   819.199219

SYS> 

データ量を倍にして、実際にソートしてみると。。。700MB以上のPGAを使ってくれました〜パチパチ。

SCOTT> 
SCOTT> begin for i in 1..100000 loop insert into code values(lpad('#',4000,'#')); end loop; commit; end;
  2  /

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'CODE',degree=>2,estimate_percent=>100);

PL/SQLプロシージャが正常に完了しました。

SCOTT> alter system flush shared_pool;

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

SCOTT> @test3

SQL_TEXT				    OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
------------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 20000 SORT		       781.26
0 order by code


SCOTT> 

もうここまででもOracle10g R1での検証は十分かと思いますが、さらに念押しで確認してみますよ〜（趣味の世界w) 次回へつづく。

---

前回までのあらすじ・・・
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #4

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その４回目、

Oracle10g R1 (32bit)で、pga_aggregate_targetを徐々に増加させ、PGAの使われ方がどう変わるかの確認のつづき。

pga_aggregate_targetを10MB、20MBと増加させてきたが、今回は、40MB、そして 4095GBと上限値近くまで増やしてみる。

SYS> alter system flush shared_pool;

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

SYS> alter system set pga_aggregate_target=40m;

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

SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       200M
pga_aggregate_target		     big integer		       40M
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				   40
aggregate PGA auto target			   22.5527344
global memory bound					    2

・・・中略・・・

SCOTT> 
SCOTT> -- test #3 _pga_max_size=200m (default) / pga_aggregate_target=40m
SCOTT> @test2

SQL_TEXT				 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT			      1.92	   409993216	    409993216
0 order by code

SCOTT> 

pga_aggregate_targetを10MB、20MB、40MBと増加させてみたところ、Oracle9i R2までと同じく、pga_aggregate_targetの5%をglobal memory boundとし、その値を上限にオペレーションしていることは確からしい。

次ぎは、_pga_max_sizeパラメータのデフォルト値である200MBを元にしてPGAサイズが決定されるようにしてみる。
pga_aggregate_targetを4095GBにする必要は全くないのだけれどね、ほんとうは。 :)

SYS> 
SYS> alter system flush shared_pool;

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

SYS> alter system set pga_aggregate_target=4095g;

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

SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       200M
pga_aggregate_target		     big integer		       4095G
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter			      4193280
aggregate PGA auto target			   3773929.32
global memory bound					  100

SYS> 

・・・中略・・・

SCOTT> 
SCOTT> -- test #4 _pga_max_size=200m (default) / pga_aggregate_target=4095G
SCOTT> @test2

SQL_TEXT				 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT			     97.58	   409993216	    409993216
0 order by code

SCOTT> 

お〜〜〜っと、ここで変化が現れました。

これまでのテストでは、pga_aggregate_targetの5%がglobal memory boundとして調整されていましたが、5%より随分小さい値が設定されています。これもOracle9i R2と同様に、_pga_max_sizeの50%という値が設定されていると考えてよさそう。 pga_aggregate_target * 5% か　_pga_max_size * 50%　のいずれか小さい方が利用されていますよね。

次回はその辺りをもう少し細かく確認してみよと思います。つづく…

---

前回までのあらすじ・・・

・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #3

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その３回目、

まずは、pga_aggregate_targetパラメータを変更し、PGAがどのように利用されるかみていく。10MBからはじめ、徐々に増加させてみる。
（なお、Oracleのバックグラウンドプロセス以外のセッションは以後のテストで接続している１セッションのみ。同時に複数のセッションがあると自動PGAメモリー管理が働きすぎて困るのでw）

SYS>
SYS> alter system set pga_aggregate_target=10m;

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

SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       200M
pga_aggregate_target		     big integer		       10M

SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				   10
aggregate PGA auto target				    4
global memory bound					   .5

SYS> 

前述の情報を見ただけでもわかる方はもう気づいたと思いますが、実際にソート処理を行わせてPGAのサイズなどもみておきますね。（その方が面白いしw)

SCOTT> --test #1 _pga_max_size=200m(default) / pga_aggregate_target=10m
SCOTT> @test2

SQL_TEXT				 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT			       .44	   409993216	    409993216
0 order by code

SCOTT> 

前述の結果から見ると、ソート処理は、0.44MBのPGAを利用していることが確認でき、そのサイズは、global memory bound以下のサイズであり、global memory boundは、pga_aggregate_targetパラメータで指定したサイズ（10MB）の5%である0.5MBであることがわかる。

では次ぎに、20MBに増加させて試してみると…

SYS> alter system flush shared_pool;

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

SYS> alter system set pga_aggregate_target=20m;

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

SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       200M
pga_aggregate_target		     big integer		       20M

SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				   20
aggregate PGA auto target			   4.36816406
global memory bound					    1

・・・中略・・・

SCOTT> 
SCOTT> -- test #2 _pga_max_size=200m(default) / pga_aggregate_target=20m
SCOTT> @test2

SQL_TEXT				 OPERATION_TYPE       last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT			       .97	   409993216	    409993216
0 order by code

SCOTT> 

pga_aggregate_targetパラメータが10MBの場合と同様に、pga_aggregate_targetの5%がglobal memory boundのサイズとして調整され、ソート処理を行わせてもその範囲以下を上限としてメモリソート＋DISKソートが行われていることがわかる。

Oracle10g R1は、Oracle9i R2のまでと同じ割当方法だよね〜。

ここまでに利用したスクリプトは以下。（今回使った分ね。）
・test2.sql

set term off
select * from code where rownum <= 100000 order by code
/
set term on
@show_workarea2

・show_workarea2.sql

col sql_text for a40
col operation_type for a20
select
  sql_text
 ,operation_type
 ,round(last_memory_used/1024/1024,2) as "last_mem(MB)"
 ,last_tempseg_size
 ,max_tempseg_size
from 
  v$sql vs join v$sql_workarea vsw
  on vs.sql_id = vsw.sql_id
where
  sql_text='select * from code where rownum <= 100000 order by code'
/

ということで、次回へつづく。 :)

---

前回までのあらすじ・・・

・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #2

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ その２回目、

自動PGAメモリー管理下ではどのようにPGAが割り当てられているのか確認して見ることに…

はじめは、

Oracle10g R1 for MacOS X Server (32bit) / MacOS X 10.4.11 Server PPC G5 Dual 2.7Ghz RAM:1GB

という環境から。

SYS> select * from v$version;

BANNER
----------------------------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - Prod
PL/SQL Release 10.1.0.3.0 - Production
CORE	10.1.0.3.0	Production
TNS for MacOS X Server: Version 10.1.0.3.0 - Production
NLSRTL Version 10.1.0.3.0 - Production

SYS>

以下、隠しパラメータも含めて（多めに表示してますが気にしないで・・）確認！
赤字のパラメータはいろいろ関わってくるから気にしておくと吉だけど、隠しパラメータは基本的にユーザがかってに変更するパラメータではないので、Oracle社さんからの指示に従ってね :-)

ちなみに、隠しパラメータは、パラメータ名称の先頭が "_"になっているパラメータのこと。かってに変更されては困るからマニュアルにも記載されていないパラメータのこと。
英語圏のブログを検索するときは、hidden parameters なんてキーワード含めるといいよ!

SYS> @show_param

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ------------------------------
_4031_sga_dump_interval        3600			      TRUE
_4031_sga_max_dumps	       10			      TRUE
_lock_sga_areas 	       0			      TRUE
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       209715200		      FALSE
_use_ism_for_pga	       TRUE			      TRUE
lock_sga		       FALSE			      TRUE
pga_aggregate_target	       104857600		      FALSE
pre_page_sga		       FALSE			      TRUE
sga_max_size		       293601280		      TRUE
sga_target		       293601280		      FALSE

11行が選択されました。

SYS>
SYS> show parameter workarea_size_policy

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
workarea_size_policy		     string			       AUTO
SYS> 

隠しパラメータは通常はshow parameterコマンドでは表示されないけど一旦設定してあげると表示されるようになるんだよ〜。
_pga_max_size隠しパラメータのデフォルト値は200MBなんだけどあえて設定してやることでshow parameterコマンドで確認できるようにしてあります。
マネしないでね、してもいいけど自己責任でお願いします (^^;;;

SYS> show parameter pga

NAME				     TYPE			       VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size			     big integer		       200M
pga_aggregate_target		     big integer		       100M
SYS> 
SYS> @pgastat

NAME						     size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter				  100
aggregate PGA auto target			   76.6142578
global memory bound					    5

SYS> 

最後の結果は、v$pgastatビューを問い合わせているんですが、一番のポイントは赤字部分のglobal memory boundなのでよ〜〜〜〜く覚えておいてね (^^

以下、ここまでで使ったスクリプト。

・show_param.sql

set linesize 200
col ksppinm for a30
col ksppstvl for a30
col ksppstdf for a30
select
   a.ksppinm
  ,b.ksppstvl
  ,b.ksppstdf
from
  x$ksppi a join x$ksppcv b
  on a.indx = b.indx
where
  a.ksppinm like '%pga%'
  or a.ksppinm like '%sga%'
  or a.ksppinm like 'memory%'
order by
  a.ksppinm
/

・pgastat.sql

set linesize 200
col name for a50
select
  name
 ,value/1024/1024 "size(MB)"
from
  v$pgastat
where
  name in (
    'aggregate PGA target parameter'
   ,'aggregate PGA auto target'
   ,'global memory bound'
  )
/

というこで、引っぱりまくってますが、Oracle10g R1 (32bit)編、次回へつづく。

---

前回までのあらすじ・・・
・pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1

pga_aggregate_targetでPGA？、_pga_max_sizeでPGA？ #1

かな〜り間が空きましたが、久々にMac De Oracleっぽいネタにしました〜w

pga_aggregate_targetというか_pga_max_sizeパラメータというかPGAに割り当てられるSORTやhash-joinなどのサイズ絡みの話をいくつかのプロジェクトでしてたらOracle10g R2以降は割当る割合が変わったよね〜なんて話が出てた事もあり、実際はどーなーのよー。という事で調べてみる事にした。

Oracle9i R2までのお話は、過去記事や国内外のブログでも沢山書かれているのでそちらも参考にしてもらうよろしいかと…

・sizing pga_aggregate_target and pga_max_size for Oracle
・The _PGA_MAX_SIZE hidden parameter
・新・ソートに関する検証
・32bitと64bitのOracle10gでも_pga_max_sizeの値は同じ。
・Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #2

確認方法は、前述した新・ソートに関する検証の検証方法を参考に進めて行くことにした。
pga_aggregate_target関連の話でかつ、日本語の記事だとここが一番分かりやすい。感謝。

今回対象としたのは以下のプラットフォームとリリースのOracle

・Oracle10g R1 for MacOS X Server (32bit) / MacOS X 10.4.11 Server PPC G5 Dual 2.7Ghz RAM:1GB
・Oracle10g R2 for MacOS X Server (64bit) / MacOS X 10.6.3 Core2 Duo 2.2Ghz RAM:2GB
・Oracle11g R1 for Linux x86 (32bit) / CentOS 5.4 Pentium M 1Ghz RAM:768MB
・Oracle11g R2 for Linux x86 (32bit) / CentOS 5.4 Pentium M 1Ghz RAM:768MB

まず、検証対象の全データベースのSCOTTスキーマに以下の表とデータを登録しておく！　:)

SCOTT> create table code (code varchar2(4000));

表が作成されました。

SCOTT> begin for i in 1..100000 loop insert into code values(lpad('#',4000,'#')); end loop; commit; end;
  2  /

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'CODE',estimate_percent=>100);

PL/SQLプロシージャが正常に完了しました。

SCOTT> 
SCOTT> l
  1  select
  2    blocks*block_size/1024/1024 as "table_size(MB)"
  3  from
  4    user_tables ut join user_tablespaces uts
  5    on ut.tablespace_name = uts.tablespace_name
  6*   and ut.table_name = 'CODE'
SCOTT> /

table_size(MB)
--------------
    782.101563

SCOTT> 

ということで、次回へつづく。 (^^

_pga_max_sizeってOracle11gではどうなったっけ？ という確認。

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた！という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

_pga_max_sizeなどの隠しパラメータのサイズを確認しておこっと。ということでOracle11g r1とr2の比較。_pga_max_sizeの値は10g r2の頃と同じだな〜と。
ただ、Oracle11g r2ではr1とくらべてpgaが付く隠しパラメータが２つ増えてるね。

SYS> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
PL/SQL Release 11.1.0.7.0 - Production
CORE	11.1.0.7.0	Production
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production

SYS> 
SYS> l
  1  select
  2    a.ksppinm
  3   ,b.ksppstvl
  4   ,b.ksppstdf
  5  from
  6    x$ksppi a join x$ksppcv b
  7    on a.indx = b.indx
  8    and a.ksppinm like '%pga%'
  9  order by
 10*   a.ksppinm
SYS> /

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
__pga_aggregate_target	       79691776 		      FALSE
_kdli_sio_pga		       FALSE			      TRUE
_kdli_sio_pga_top	       FALSE			      TRUE
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       209715200		      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       78643200 		      FALSE

7行が選択されました。

SYS> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE	11.2.0.1.0	Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

SYS> 
SYS> 
SYS> l
  1  select
  2    a.ksppinm
  3   ,b.ksppstvl
  4   ,b.ksppstdf
  5  from
  6    x$ksppi a join x$ksppcv b
  7    on a.indx = b.indx
  8    and a.ksppinm like '%pga%'
  9  order by
 10*   a.ksppinm
SYS> /

KSPPINM 		       KSPPSTVL 		      KSPPSTDF
------------------------------ ------------------------------ ---------
__pga_aggregate_target	       109051904		      FALSE
_kdli_sio_pga		       FALSE			      TRUE
_kdli_sio_pga_top	       FALSE			      TRUE
_ldr_pga_lim		       0			      TRUE
_pga_large_extent_size	       1048576			      TRUE
_pga_max_size		       209715200		      TRUE
_pgactx_cap_stacks	       FALSE			      TRUE
_use_ism_for_pga	       TRUE			      TRUE
pga_aggregate_target	       0			      TRUE

9行が選択されました。

SYS> 

UTL_FILE.FCOPY()とかFRENAME()とか

UTL_FILE.FRENAME()プロシージャとか、UTL_FILE.FCOPY()プロシージャって何かと便利っていうお話。

テストでOracleデータベース側に格納されたデータと紐づけながら画像ファイルを複製してみたり、名称を紐づけたりするときにも重宝するプロシージャなんですよね。
特に、shellなどがないWindows環境で画像を大量に複製したりする場合にはかなり便利だなと。

まずは、OS上のディレクトリとの紐付け。ディレクトリオブジェクトを作成しておきます。（今回はSCOTTユーザにディレクトリオブジェクトを作成できるように権限を付与しておきました）

SCOTT> 
SCOTT> create directory ora_dir as '/home/oracle/ora_dir';

ディレクトリが作成されました。

SCOTT>  

UTL_FILE.FRENAME()プロシージャは、Linux/Unixのmvコマンドライク。
以下は、リネーム後のファイル名(hogehoge.png)と同じファイルが既に存在する場合には置き換えない場合の例。overwriteパラメータをFALSE（デフォルト）にしてあげる。

SCOTT> !ls -l ora_dir
-rw-r--r-- 1 oracle oinstall 28800  2月 20 09:26 hogehoge.png
-rw-r--r-- 1 oracle oinstall 28800  2月 19 23:57 test.png

SCOTT> l
  1  BEGIN
  2    UTL_FILE.FRENAME('ORA_DIR','test.png','ORA_DIR','hogehoge.png',FALSE);
  3* END;
SCOTT> /
BEGIN
*
行1でエラーが発生しました。:
ORA-29292: ファイル名の変更操作に失敗しました。 ORA-06512:
"SYS.UTL_FILE", 行348
ORA-06512: "SYS.UTL_FILE", 行1290
ORA-06512: 行2

SCOTT> !ls -l ora_dir
-rw-r--r-- 1 oracle oinstall 28800  2月 20 09:26 hogehoge.png
-rw-r--r-- 1 oracle oinstall 28800  2月 19 23:57 test.png

以下は、リネーム後のファイル名(hogehoge.png)と同じファイルが既に存在する場合に置き換えてしまう例。overwriteパラメータをTRUEにしてあげる。

SCOTT> !ls -l ora_dir
-rw-r--r-- 1 oracle oinstall 28800  2月 20 09:26 hogehoge.png
-rw-r--r-- 1 oracle oinstall 28800  2月 19 23:57 test.png

SCOTT> l
  1  BEGIN
  2    UTL_FILE.FRENAME('ORA_DIR','test.png','ORA_DIR','hogehoge.png',TRUE);
  3* END;
SCOTT> /

PL/SQLプロシージャが正常に完了しました。

SCOTT> !ls -l ora_dir
-rw-r--r-- 1 oracle oinstall 28800  2月 19 23:57 hogehoge.png

SCOTT>

せっかくUTL_FILE.FRENAME()プロシージャを試したので、次いでにUTL_FILE.FCOPY()でファイルコピーも！
といきたいところですが、UTL_FILE.FCOPY()プロシージャはテキストファイルのコピーしか行えない！（パラメータからも想像できると思うけど）
では、画像ファイルなどのバイナリファイルはどうすんのさ！オラクルさん！。ってことで、そのようなプロシージャは無いので自前で作りましょ。
以下は、そのサンプル、バイナリモードで画像ファイルを読み込んでバイナリモードで別ファイルへ書き出す。だたそれだけ。

SCOTT> !ls -l ora_dir 
-rw-r--r-- 1 oracle oinstall 28800  2月 19 23:13 test2.png

SCOTT> 
SCOTT> l
  1  DECLARE
  2	 src_file UTL_FILE.FILE_TYPE;
  3	 dst_file UTL_FILE.FILE_TYPE;
  4	 buffer RAW(32767);
  5    BEGIN
  6	 src_file := UTL_FILE.FOPEN('ORA_DIR','test2.png', 'rb', 32767);
  7	 dst_file := UTL_FILE.FOPEN('ORA_DIR','hogehogehoge.png', 'wb', 32767);
  8	 LOOP
  9	   BEGIN
 10	     UTL_FILE.GET_RAW(src_file, buffer, 32767);
 11	     UTL_FILE.PUT_RAW(dst_file, buffer, TRUE);
 12	   EXCEPTION
 13	     WHEN NO_DATA_FOUND THEN
 14	       EXIT;
 15	   END;
 16	 END LOOP;
 17	 UTL_FILE.FCLOSE(src_file);
 18	 UTL_FILE.FCLOSE(dst_file);
 19*   END;
SCOTT> /

PL/SQLプロシージャが正常に完了しました。

SCOTT> !ls -l ora_dir
-rw-r--r-- 1 oracle oinstall 28800  2月 19 23:57 hogehogehoge.png
-rw-r--r-- 1 oracle oinstall 28800  2月 19 23:13 test2.png

SCOTT> 

CentOS5.4で無線LAN

先日、転居に伴い自宅のLAN環境を変えたついでに、それまでケーブル接続していたCentOS5を入れていたお遊び用Toshiba Dynabook SS SX/210LNLW RAM:768MBを無線LAN接続で使う事にした。rootユーザの言語をJapanseにしていた関係で「ワイヤレスでバイス設定」を使って少々ハマってしまったので、何にハマったのかも備忘録として書いてあります。

尚、無線LAN設定時はCentOS5.4。

まず、無線LANアダプターの確認。

[root@corydoras ˜]# lspci | grep Ether
01:05.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01)
01:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (MOB) Ethernet Controller (rev 83)
[root@corydoras ˜]# 

wpa_supplicant関係の確認.

[root@corydoras ˜]# rpm -q wpa_supplicant
wpa_supplicant-0.5.10-8.el5
[root@corydoras ˜]# rpm -ql wpa_supplicant
/etc/dbus-1/system.d/wpa_supplicant.conf
/etc/logrotate.d/wpa_supplicant
/etc/rc.d/init.d/wpa_supplicant
/etc/sysconfig/wpa_supplicant
/etc/wpa_supplicant
/etc/wpa_supplicant/wpa_supplicant.conf
/usr/sbin/wpa_cli
/usr/sbin/wpa_passphrase
/usr/sbin/wpa_supplicant
/usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service
/usr/share/doc/wpa_supplicant-0.5.10
/usr/share/doc/wpa_supplicant-0.5.10/COPYING
/usr/share/doc/wpa_supplicant-0.5.10/ChangeLog
/usr/share/doc/wpa_supplicant-0.5.10/README
/usr/share/doc/wpa_supplicant-0.5.10/eap_testing.txt
/usr/share/doc/wpa_supplicant-0.5.10/examples
/usr/share/doc/wpa_supplicant-0.5.10/examples/ieee8021x.conf
/usr/share/doc/wpa_supplicant-0.5.10/examples/plaintext.conf
/usr/share/doc/wpa_supplicant-0.5.10/examples/wep.conf
/usr/share/doc/wpa_supplicant-0.5.10/examples/wpa-psk-tkip.conf
/usr/share/doc/wpa_supplicant-0.5.10/examples/wpa2-eap-ccmp.conf
/usr/share/doc/wpa_supplicant-0.5.10/todo.txt
/usr/share/doc/wpa_supplicant-0.5.10/wpa_supplicant.conf
/usr/share/man/man5/wpa_supplicant.conf.5.gz
/usr/share/man/man8/wpa_background.8.gz
/usr/share/man/man8/wpa_cli.8.gz
/usr/share/man/man8/wpa_passphrase.8.gz
/usr/share/man/man8/wpa_supplicant.8.gz
/var/run/wpa_supplicant
[root@corydoras ˜]# 

以下、関連configファイルをダラダラと。。この辺りの設定方法はググルと山ほど出て来るのでほんと助かりまっす！

[root@corydoras ˜]# cat /etc/sysconfig/network-scripts/ifcfg-wlan0
# Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter
DEVICE=wlan0
BOOTPROTO=none
ONBOOT=yes
#HWADDR=XX:XX:XX:XX:XX:XX
NETMASK=255.255.255.0
DHCP_HOSTNAME=
IPADDR=192.168.1.20
DOMAIN=
GATEWAY=192.168.1.1
TYPE=Wireless
USERCTL=no
IPV6INIT=no
PEERDNS=yes
ESSID=MyAirPortExpress
CHANNEL=1
MODE=Managed
SECURITYMODE=Restricted
RATE=Auto
[root@corydoras ˜]# 

パスフレーズを設定して…

[root@corydoras ˜]# wpa_passphrase MyAirPortExpress hogehoge >> /etc/wpa_supplicant/wpa_supplicant.conf
[root@corydoras ˜]# cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel

#network={
#       ssid="any"
#       key_mgmt=NONE
#}

network={
        scan_ssid=1
        proto=WPA2
        key_mgmt=WPA-PSK
        pairwise=CCMP TKIP
        group=CCMP TKIP
        ssid="MyAirPortExpress"
        psk=4151a3813315d0175c7cd157a3afbb27ae50b9f466608687a60c0514ef0ec427
}
[root@corydoras ˜]# 

/etc/sysconfig/wpa_supplicantは以下のように設定した

[root@corydoras ˜]# cat /etc/sysconfig/wpa_supplicant
# Use the flag "-i" before each of your interfaces, like so:
#  INTERFACES="-i eth1 -i wlan0"
INTERFACES="-i wlan0"


# Use the flag "-D" before each driver, like so:
#  DRIVERS="-D wext"
DRIVERS="-D wext"


# Other arguments
#   -u   Enable the D-Bus interface (required for use with NetworkManager)
#   -f   Log to /var/log/wpa_supplicant.log
OTHER_ARGS="-f /var/log/wpa_supplicant.log"

[root@corydoras ˜]# 

/etc/rc.d/init.d/wpa_supplicantは/etc/rc.d/init.d/networkより前に起動するように

[root@corydoras ˜]# grep -w "# chkconfig" /etc/rc.d/init.d/network
# chkconfig: 2345 10 90
[root@corydoras ˜]# grep -w "# chkconfig" /etc/rc.d/init.d/wpa_supplicant
# chkconfig: 2345 09 88
[root@corydoras ˜]# chkconfig wpa_supplicant on
[root@corydoras ˜]# 

ここで再起動

繋がってるか確認。

[root@corydoras ˜]# 
[root@corydoras ˜]# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=2.29 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.58 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.58 ms

--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 1.588/1.825/2.298/0.334 ms
[root@corydoras ˜]# 

MacOS X側からもアクセスしてみる、試しにOracle Instant ClientでCentOS5.4上のOracle11g R1へ接続。

G5Server:˜ discus$ sqlplus /nolog

SQL*Plus: Release 10.1.0.3.0 - Production on 日 11月 29 16:43:02 2009

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

> conn sys@lampeye as sysdba
パスワードを入力してください: 
接続されました。
SYS> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
PL/SQL Release 11.1.0.7.0 - Production
CORE    11.1.0.7.0      Production
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production

SYS> 

---

おまけ
上記だけ載せてしまうと順調に進んだように見えますがハマった所もありました。
GUI上で「ネットワーク設定」や「ワイヤレスデバイス設定」を利用して各種構成が行えるのだが、rootユーザの言語設定が日本語になっていると「ワイヤレスデバイス設定」で”自動”と設定したパラメータが構成ファイル上でも”自動”と設定され起動時にエラーになってしまった。これに気付くのに手間取り少々ハマったのでご注意を。

以下、「ワイヤレスデバイス設定」で”自動”とした場合の内容（これじゃうまく行かないよね。w）

[root@corydoras ˜]# cat /etc/sysconfig/network-scripts/ifcfg-wlan0 
# Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter
DEVICE=wlan0
BOOTPROTO=none
ONBOOT=yes
HWADDR=XX:XX:XX:XX:XX:XX
NETMASK=255.255.255.0
DHCP_HOSTNAME=
IPADDR=192.168.1.20
DOMAIN=
GATEWAY=192.168.1.1
TYPE=Wireless
USERCTL=no
IPV6INIT=no
PEERDNS=no
ESSID=MyAirPortExpress
CHANNEL=自動
MODE=Auto
SECURITYMODE=
RATE=自動
[root@corydoras ˜]# 

Oracle SQL Developer Data Modeler #3

前回予告したようにOracle SQL Developer Data Modeler 2.0で日本語を使ったモデリングを試してみた。まず使用感から先に書いておくと”まあまあ”と言ったところ。
日本語を使う上で注意する点も現時点ではまだまだあるな。という感じで、その辺りが面倒だとか気になるようであればERwinとかObjectBrowser ERとか既存のツールを使った方が楽だと感じる方も多いかもしれない。

まずはYouTubeへアップしたムービーでご覧ください。
論理モデルを日本語で作成し、物理モデルへ変換する。
その際のポイントは以下。

• 変換する際に英語表記へ変換しているが制約名（主キー制約、ユニーク制約、外部参照制約など）を日本語表記から英語表記へ置換する機能が無い（？）ようで、制約名に関しては論理モデル上で英語表記へ手動変更している。


• 外部参照制約では外部キー削除時のデフォルトアクションをNO ACTIONと設定していてもSET NULLが設定されてしまうため、この項目についても適宜手動で設定する必要がある。


• DDL生成時に指定した名称を置換する「Name Substitution」機能は動作しないようなので使うのをやめた。（使い方が悪いのか？）


• 今回あえて、日本語名のままのカラム（従業員.給与）を残しておきDDLにどのように書き出されるか確認しておいた。結果としては識別引用子(quoted identifier）は付加されないので「日本語名称でテーブル等のデータベースオブジェクト名称」を作成したいという方々には残念！かも。ただ、どうしても識別引用子を付加したい場合もあると思うのでDDL生成時オプションとして用意してもらえると良いと思う。（確かObjectBrowser ERはそんな機能があったような気がする。）


• 論理モデル上にてリレーションを作成した場合、属性名称のPreferred Abbreviationに指定した名称を継承しないので手動で入力する必要がる。（タイプミスには要注意。）

ムービーは最大化するといいよ!

ムービーで作成した物理モデルから生成したDDLは以下の通り。（EMPLOYEESの給与列はあえてマルチバイトのままにしてあるが識別引用子が付加されていない。赤太字部分）

他に気付いたことも幾つかあった気がする・・・・・。が・・・思い出したらこのエントリに追記するか別エントリにする予定。

尚、論理モデルから物理モデルへ変換する際「Apply Name Translation」と「Use preferred abbreviations」をチェックしたが、「Use preferred abbreviations」をチェックしなかった場合はどこに設定した名称に変換してくれるのか未確認。

-- Generated by Oracle SQL Developer Data Modeler Version: 2.0.0 Build: 570
--   at:        2009-09-26 22:05:49
--   site:      Oracle Database 11g
--   type:      Oracle Database 11g


CREATE TABLE DEPARTMENTS 
    ( 
     DEPARTMENT_ID NUMBER (4)  NOT NULL , 
     DEPARTMENT_NAME VARCHAR2 (60 BYTE)  NOT NULL 
    ) TABLESPACE HOGE_TS 
    
;


COMMENT ON TABLE DEPARTMENTS IS '部署マスタ'
;

COMMENT ON COLUMN DEPARTMENTS.DEPARTMENT_ID IS '部署ID' 
;

COMMENT ON COLUMN DEPARTMENTS.DEPARTMENT_NAME IS '部署名' 
;
CREATE UNIQUE INDEX DEPARTMENTS_PKX ON DEPARTMENTS 
    ( 
     DEPARTMENT_ID ASC 
    ) 
;

ALTER TABLE DEPARTMENTS 
    ADD CONSTRAINT DEPARTMENTS_PK PRIMARY KEY ( DEPARTMENT_ID ) ;


CREATE TABLE EMPLOYEES 
    ( 
     EMPLOYEE_ID NUMBER (5)  NOT NULL , 
     EMPLOYEE_NAME VARCHAR2 (40 BYTE)  NOT NULL , 
     給与 NUMBER (7,2)  NOT NULL , 
     DEPARTMENT_ID NUMBER (4) , 
     MGR_ID NUMBER (5) 
    ) TABLESPACE HOGE_TS 
    
;



COMMENT ON TABLE EMPLOYEES IS '従業員マスタ'
;

COMMENT ON COLUMN EMPLOYEES.EMPLOYEE_ID IS '従業員ID' 
;

COMMENT ON COLUMN EMPLOYEES.EMPLOYEE_NAME IS '従業員名' 
;

COMMENT ON COLUMN EMPLOYEES.給与 IS '給与' 
;

COMMENT ON COLUMN EMPLOYEES.DEPARTMENT_ID IS '部署ID' 
;

COMMENT ON COLUMN EMPLOYEES.MGR_ID IS '上司ID' 
;
CREATE UNIQUE INDEX EMPLOYEES_PKX ON EMPLOYEES 
    ( 
     EMPLOYEE_ID ASC 
    ) 
;
CREATE INDEX EMP_DEPT_FK1X ON EMPLOYEES 
    ( 
     DEPARTMENT_ID ASC 
    ) 
;
CREATE INDEX EMP_EMP_FK1X ON EMPLOYEES 
    ( 
     MGR_ID ASC 
    ) 
;

ALTER TABLE EMPLOYEES 
    ADD CONSTRAINT EMPLOYEES_PK PRIMARY KEY ( EMPLOYEE_ID ) ;



ALTER TABLE EMPLOYEES 
    ADD CONSTRAINT EMP_DEPT_FK1 FOREIGN KEY 
    ( 
     DEPARTMENT_ID
    ) 
    REFERENCES DEPARTMENTS 
    ( 
     DEPARTMENT_ID
    ) 
;


ALTER TABLE EMPLOYEES 
    ADD CONSTRAINT EMP_EMP_FK1 FOREIGN KEY 
    ( 
     MGR_ID
    ) 
    REFERENCES EMPLOYEES 
    ( 
     EMPLOYEE_ID
    ) 
;


-- Oracle SQL Developer Data Modeler Summary Report: 
-- 
-- CREATE TABLE                             2
-- CREATE INDEX                             4
-- ALTER TABLE                              2
-- CREATE VIEW                              0
-- CREATE PROCEDURE                         0
-- CREATE TRIGGER                           0
-- CREATE STRUCTURED TYPE                   0
-- CREATE COLLECTION TYPE                   0
-- CREATE CLUSTER                           0
-- CREATE CONTEXT                           0
-- CREATE DATABASE                          0
-- CREATE DIMENSION                         0
-- CREATE DIRECTORY                         0
-- CREATE DISK GROUP                        0
-- CREATE ROLE                              0
-- CREATE ROLLBACK SEGMENT                  0
-- CREATE SEQUENCE                          0
-- CREATE SNAPSHOT                          0
-- CREATE SYNONYM                           0
-- CREATE TABLESPACE                        0
-- CREATE USER                              0
-- 
-- DROP TABLESPACE                          0
-- DROP DATABASE                            0
-- 
-- ERRORS                                   0
-- WARNINGS                                 0

---

バックナンバー
・Oracle SQL Developer Data Modeler #1
・Oracle SQL Developer Data Modeler #2

Cross Platform Transportable Tablespace #11

twitterで呟かれていたリトルエンティアン、ビッグエンディアンで思い出したので、久々にトランスポータブル表領域について。
Oracle database 11gが登場したり、MacがPowerPCからIntelに移行したりしたのでその辺りの情報も追加されているんだろうな〜。と思い$transportable_platformの内容を比較してみた。

まず、Oracle10g R2の頃のv$transportable_platformの情報。（以前載せたものを再掲載）

SYS> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production
PL/SQL Release 10.2.0.2.0 - Production
CORE    10.2.0.2.0      Production
TNS for Linux: Version 10.2.0.2.0 - Production
NLSRTL Version 10.2.0.2.0 - Production

SYS> SYS> l
  1  select
  2     endian_format
  3    ,platform_name
  4  from
  5*   v$transportable_platform
SYS> /

ENDIAN_FORMAT                PLATFORM_NAME
---------------------------- -----------------------------------------
Big                          Solaris[tm] OE (32-bit)
Big                          Solaris[tm] OE (64-bit)
Little                       Microsoft Windows IA (32-bit)
Little                       Linux IA (32-bit)
Big                          AIX-Based Systems (64-bit)
Big                          HP-UX (64-bit)
Little                       HP Tru64 UNIX
Big                          HP-UX IA (64-bit)
Little                       Linux IA (64-bit)
Little                       HP Open VMS
Little                       Microsoft Windows IA (64-bit)
Big                          IBM zSeries Based Linux
Little                       Linux 64-bit for AMD
Big                          Apple Mac OS
Little                       Microsoft Windows 64-bit for AMD
Little                       Solaris Operating System (x86)
Big                          IBM Power Based Linux

17行が選択されました。

SYS>

次に、Oracle11g R2のv$transportable_platformの内容
黒太字部分は名称が変っただけですね。for AMDからx86と変更されている。
また、赤太字のHP IA Open VMSとSolaris Operating System (x86-64)が追加されている。

SYS> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
PL/SQL Release 11.1.0.7.0 - Production
CORE    11.1.0.7.0      Production
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production

SYS> l
  1  select
  2     endian_format
  3    ,platform_name
  4  from
  5*   v$transportable_platform
SYS> /

ENDIAN_FORMAT  PLATFORM_NAME
-------------- --------------------------------------------------
Big            Solaris[tm] OE (32-bit)
Big            Solaris[tm] OE (64-bit)
Little         Microsoft Windows IA (32-bit)
Little         Linux IA (32-bit)
Big            AIX-Based Systems (64-bit)
Big            HP-UX (64-bit)
Little         HP Tru64 UNIX
Big            HP-UX IA (64-bit)
Little         Linux IA (64-bit)
Little         HP Open VMS
Little         Microsoft Windows IA (64-bit)
Big            IBM zSeries Based Linux
Little         Linux x86 64-bit
Big            Apple Mac OS
Little         Microsoft Windows x86 64-bit
Little         Solaris Operating System (x86)
Big            IBM Power Based Linux
Little         HP IA Open VMS
Little         Solaris Operating System (x86-64)

19行が選択されました。


SYS> 

最後は、先日リリースされたOracle11g R2のv$transportable_platformの内容。
赤太字で示した通り、Intel Macが追加されている。PowerPC版のMacはBig eneianだったがIntel版ではLittle endian。

SYS> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

SYS> 
SYS> l
  1  select
  2     endian_format
  3    ,platform_name
  4  from
  5*   v$transportable_platform
SYS> /

ENDIAN_FORMAT  PLATFORM_NAME
-------------- --------------------------------------------------
Big            Solaris[tm] OE (32-bit)
Big            Solaris[tm] OE (64-bit)
Little         Microsoft Windows IA (32-bit)
Little         Linux IA (32-bit)
Big            AIX-Based Systems (64-bit)
Big            HP-UX (64-bit)
Little         HP Tru64 UNIX
Big            HP-UX IA (64-bit)
Little         Linux IA (64-bit)
Little         HP Open VMS
Little         Microsoft Windows IA (64-bit)
Big            IBM zSeries Based Linux
Little         Linux x86 64-bit
Big            Apple Mac OS
Little         Microsoft Windows x86 64-bit
Little         Solaris Operating System (x86)
Big            IBM Power Based Linux
Little         HP IA Open VMS
Little         Solaris Operating System (x86-64)
Little         Apple Mac OS (x86-64)

20行が選択されました。

SYS> 

いつの間にやらこんな本が．．．

・Oracle and AWS
・Oracle cloud computing center


とか眺めてたらタイムリーだな。ベッドの脇にいつの間にかあった。妻が買って来たんだね。よませてもらおっと！

AWSについてはHadoopとAmazon EC2による安くて簡単大規模データ処理@Gree オープンソース勉強会なんて話もあって面白がってるとこなので。
あそうそう、ゲストで呼んでもらったOracle LOVERSでもOracle10g express editionをAWS使ってやってましたね。

PL/SQL で Python Challenge Level 18 - 完

ということで、Python Challenge Level18の最終回。
前回報告した通り level 18　はPL/SQLだけで解けます。今回は問題の元ネタの抽出と回答を抽出した後の確認はOSに付属している機能を使ったが大切なのは問題の元ネタから解答を抽出する所なので。

SQL*Plusから実行したストアドプロシージャで問題を解いたところ．．．．例によってヒントになりそうな部分はもやもやさせてます。 :)

ヒントになりまくりの答えのスナップショット。（これ以外にも私のブログにヒントになる記事もあるのだが・・・・・それは書きませんよ。。。。）

ちなみに絵を見れば分かると思いますが、MacOS XからX11のX forwordingを使って今回利用したLinuxのDesktopを表示/操作しています。X11のxtermからssh -Y user@hostで接続してgnome-sessionを実行しているだけ。

Python Challenge Level19へつづく！（？）

PL/SQL で Python Challenge Level 18 解けた

一年以上間が空いてしまったが・・・Python Challenge Level18はPL/SQLだけで解けますよん。ヒントになるようなならないようなモヤモヤした記事は明日にでも。。

PL/SQL de O(ND) Difference Algorithm

かなり久々ですが、まあ、シリーズもののネタを毎日アップするのもなかなか難しい状況なので単発ネタでも。

ということで今回は、PL/SQLでAn O(ND) Difference Algorithmを実装して頭の体操。

文書比較のアルゴリズムとしてはAn O(NP) Sequence Comparison Algorithmが効率は良いのだが、先日javascriptで書かれたO(ND)のコードを見つけたことをキッカケにPL/SQLで写経したくなったというわけ。

文書比較アルゴリズムは２、３年くらい前、文書比較アブゴリズム、diff(1)/diff(2)/diff(3)等をみたことがあったが、最近pyhthonやらjavascriptのコードを目にするようになり　(^^) な顔して眺めていて時間があったらPL/SQLで遊んでみようと思っていた。。他の言語でやってもMac De Oracle的にはおもしろくないので。

ちなみに、pythonだどdifflib使えば文書比較はできるので実際新たに書く必要はそんなにないんじゃなかろうかとも思うわけですが、私のようにわざわざPL/SQLで書いてみようと思う人間もいるわけで、頭の体操にはいいと思います！。理解するのは大変だったけど。wwww

最近見つけたO(ND)やO(NP)に関するブログ等のリンクは以下。

・レコメンデーションとエディットグラフ
・diff O(np) javascript implementation
・"An O(NP) Sequence Comparison Algorithm" with Python
・"An O(NP) Sequence Comparison Algorithm" with Python の添削
・Javascriptでdiffる ( with 形態素解析 )
・google-diff-match-patch

今回はレコメンデーションとエディットグラフにあるO(ND)コードを写経してPL/SQLでやってみた。O(NP)も集中できる時間があったらやってみたい。。。脳トレにも丁度いいかもよ。。。
※Oracle11g 11.1.0.7.0を使ったが、Oracle10g 10.1.0.3.0以上なら動作するはず。。。。(^^;;;

まずは、結果からどうぞ。O(ND)をPL/SQLストアドファンクション化し、SQLから実行できるようにしてあります。また、pythonのdifflibにあるdifferクラスで利用されている差異コード('?'を除く）を出力するようにしてあります。）

SCOTT> set timi on
SCOTT> l
  1  SELECT
  2    '"' || diffs.code || diffs.string || '"' AS "diff O(ND) results"
  3  FROM
  4    TABLE(
  5      SELECT diffOND('BFEABD', 'ABCDA') from dual
  6    ) diffs
  7  ORDER BY
  8*   diffs.seq DESC
SCOTT> /

diff O(ND) results
--------------------------------------------------------------------------------
"- B"
"- F"
"- E"
"  A"
"  B"
"+ C"
"  D"
"+ A"

8行が選択されました。

経過: 00:00:00.00

SCOTT> 
SCOTT> l
  1  SELECT
  2    '"' || diffs.code || diffs.string || '"' AS "diff O(ND) results"
  3  FROM
  4    TABLE(
  5      SELECT diffOND('aaebdd ', 'aedajkd') from dual
  6    ) diffs
  7  ORDER BY
  8*   diffs.seq DESC
SCOTT> /

diff O(ND) results
--------------------------------------------------------------------------------
"  a"
"- a"
"  e"
"- b"
"  d"
"+ a"
"+ j"
"+ k"
"  d"
"-  "

10行が選択されました。

経過: 00:00:00.00

SCOTT> 
SCOTT> l
  1  SELECT
  2    '"' || diffs.code || diffs.string || '"' AS "diff O(ND) results"
  3  FROM
  4    TABLE(
  5      SELECT diffOND('ABCDE', 'ABCDE') from dual
  6    ) diffs
  7  ORDER BY
  8*   diffs.seq DESC
SCOTT> /

diff O(ND) results
--------------------------------------------------------------------------------
"  A"
"  B"
"  C"
"  D"
"  E"

経過: 00:00:00.00

SCOTT> 
SCOTT> l
  1  SELECT
  2    '"' || diffs.code || diffs.string || '"' AS "diff O(ND) results"
  3  FROM
  4    TABLE(
  5      SELECT diffOND('あいうえお','かきくけこ') from dual
  6    ) diffs
  7  ORDER BY
  8*   diffs.seq DESC
SCOTT> /

diff O(ND) results
--------------------------------------------------------------------------------
"- あ"
"- い"
"- う"
"- え"
"- お"
"+ か"
"+ き"
"+ く"
"+ け"
"+ こ"

10行が選択されました。

経過: 00:00:00.00

SCOTT> 

PL/SQLのコードは以下の通り。

SCOTT> !cat ond.sql

CREATE OR REPLACE TYPE vRecType AS OBJECT
(
     x NUMBER
    ,y NUMBER
    ,parent ANYDATA
);
/
show errors

BEGIN
  FOR functionNames 
    IN (SELECT object_name FROM USER_OBJECTS WHERE object_name='DIFFOND' AND OBJECT_TYPE='FUNCTION')
  LOOP
    EXECUTE IMMEDIATE 'DROP FUNCTION ' || functionNames.object_name;
  END LOOP;

  FOR typeNames 
    IN (SELECT type_name FROM USER_TYPES WHERE type_name='DIFFLISTTYPE')
  LOOP
    EXECUTE IMMEDIATE 'DROP TYPE ' || typeNames.type_name;
  END LOOP;
END;
/

CREATE OR REPLACE TYPE diffType AS OBJECT
(
     seq        NUMBER
    ,code       CHAR(2)
    ,string     VARCHAR2(32767)
);
/
show errors

CREATE OR REPLACE TYPE diffListType AS TABLE OF diffType;
/
show errors

CREATE FUNCTION diffOND
(
     str1       IN VARCHAR2
    ,str2       IN VARCHAR2
)
RETURN diffListType
IS
    STAT_INIT  CONSTANT PLS_INTEGER := 0;
    STAT_X     CONSTANT PLS_INTEGER := 1;
    STAT_Y     CONSTANT PLS_INTEGER := 2;

    TYPE vType IS TABLE OF vRecType;
    v vType := vType();

    FUNCTION isVRecNotEmpty(
        vRec    IN vRecType
    )
    RETURN BOOLEAN
    IS
    BEGIN
        RETURN (CASE WHEN vRec.x IS NULL AND vRec.y IS NULL AND vRec.parent IS NULL THEN FALSE ELSE TRUE END);
    END isVRecNotEmpty;

    FUNCTION getDirection
    (
         vMinus IN vRecType
        ,vPlus  IN vRecType
    )
    RETURN PLS_INTEGER
    IS
    BEGIN
        IF NOT isVRecNotEmpty(vMinus) AND NOT isVRecNotEmpty(vPlus) THEN
            RETURN STAT_INIT;
        END IF;

        IF NOT isVRecNotEmpty(vMinus) THEN
            RETURN STAT_X;
        END IF;

        IF NOT isVRecNotEmpty(vPlus) THEN
            RETURN STAT_Y;
        END IF;

        RETURN (CASE WHEN vMinus.x < vPlus.x THEN STAT_X ELSE STAT_Y END);
    END getDirection;

    FUNCTION OND
    (
         str1 IN VARCHAR2
        ,str2 IN VARCHAR2
    )
    RETURN vRecType
    IS
        offset  PLS_INTEGER;
        kMax    PLS_INTEGER;
        kMin    PLS_INTEGER;
        k       PLS_INTEGER;
        vIndex  PLS_INTEGER;
        x       PLS_INTEGER;
        y       PLS_INTEGER;
        str1Len PLS_INTEGER;
        str2Len PLS_INTEGER;
        parent  vRecType;
    BEGIN
        str1Len := LENGTH(str1);
        str2Len := LENGTH(str2);
        v.EXTEND(str1Len + str2Len + 3);
        offset:= str2Len + 2;

        FOR d IN 0..str1Len + str2Len LOOP
            kMax := (CASE WHEN d <= str1Len THEN d ELSE str1Len - (d - str1Len) END);
            kMin := (CASE WHEN d <= str2Len THEN d ELSE str2Len - (d - str2Len) END);

            k := kMin * -1;
            WHILE k <= kMax LOOP
                vIndex := offset + k;
                CASE getDirection(v(vIndex-1), v(vIndex+1))
                    WHEN STAT_INIT THEN
                        x := 0;
                        y := 0;
                        parent := vRecType(0, 0, NULL);
                    WHEN STAT_X THEN
                        x := v(vIndex+1).x;
                        y := v(vIndex+1).y + 1;
                        parent := v(vIndex+1);
                    WHEN STAT_Y THEN
                        x := v(vIndex-1).x + 1;
                        y := v(vIndex-1).y;
                        parent := v(vIndex-1);
                END CASE;

                -- snake
                WHILE (x < str1Len AND y < str2Len) 
                AND (SUBSTR(str1, x+1, 1) = SUBSTR(str2, y+1, 1)) 
                LOOP
                    x := x + 1;
                    y := y + 1;
                END LOOP;
                v(vIndex) := vRecType(x, y, ANYDATA.ConvertObject(parent));

                IF str1Len <= x AND str2Len <= y THEN
                    RETURN v(vIndex);
                END IF;

                k := k + 2;
            END LOOP; 
        END LOOP;
    END OND;

    FUNCTION diff
    (
         str1 IN VARCHAR2
        ,str2 IN VARCHAR2
    )
    RETURN diffListType
    IS
        endPoint                vRecType;
        parent                  vRecType;
        diff_x                  PLS_INTEGER;
        diff_y                  PLS_INTEGER;
        same_len                PLS_INTEGER;
        isSuccessGetObject      PLS_INTEGER;
        diffs                   diffListType := diffListType();
        seq                     PLS_INTEGER := 0;
    BEGIN
        endPoint := OND(str1, str2);
        WHILE endPoint.parent IS NOT NULL LOOP
            IF ANYDATA.getObject(endPoint.parent, parent) != DBMS_TYPES.SUCCESS THEN
                RAISE_APPLICATION_ERROR(-20000,'DBMS_TYPES.NO_DATA');
            END IF;

            diff_x := endPoint.x - parent.x;
            diff_y := endPoint.y - parent.y;
            same_len := CASE WHEN diff_x <= diff_y THEN diff_x ELSE diff_y END;

            FOR i IN 0..same_len-1 LOOP
                -- common
                diffs.EXTEND();
                seq := seq + 1;
                diffs(diffs.COUNT()) := diffType(seq, '  ', SUBSTR(str1, endPoint.x-i, 1));
            END LOOP;

            IF diff_y != diff_x THEN
                diffs.EXTEND();
                seq := seq + 1;
                IF diff_y < diff_x THEN
                    -- del
                    diffs(diffs.COUNT()) := diffType(seq, '- ', SUBSTR(str1, parent.x+1, 1));
                ELSE
                    -- add
                    diffs(diffs.COUNT()) := diffType(seq, '+ ', SUBSTR(str2, parent.y+1, 1));
                END IF;
            END IF;

            endPoint := parent;
        END LOOP;

        RETURN diffs;
    END diff;
BEGIN
    RETURN diff(str1, str2);
END diffOND;
/
show errors

Enjoy PL/SQL! というより Enjoy Programming! のほうがいいか。。

OraTweet 1.0 あそび始めた。

OraTweet v1.0が公開されたということなので早速試してみた。といってもちょっとだけ。細かいところはみてないけどとりあえずは日本語も使えるみたい。ちょうどPL/SQL gatewayからTwitter APIを使って遊んでみようと思っていたところだから少し遊ぶか。

DB2 で PL/SQL

DB2新版はPL/SQL対応、Oracleユーザーの移行狙う@ ITmedia

へぇ〜、それじゃ、昨日作ったケンブリッジ関数もDB2 9.7で動作するようになるのか〜〜。へぇ〜。mod_plsqlというかPL/SQL gatewayはどうなんだろうか？、Oracleが提供しているPL/SQLパッケージも対応しているのだろうか？　機会があったら質問しておこうっと。

できれば他のRDBMSでもやってくれるとありがたいかも．．．

PL/SQL : Write Once Run Any RDBMS なんてね。

Oracle Open World Tokyo 2009 #2（最終日） - Do you Poken?

Oracle Open World Tokyo 2009でOracle社員犬のWendyがPoken始めたというのでハイフォーしてきました。私以外にWendyとハイフォーした方いたのかな？

おっと、忘れるところでした、Unconferenceや他のセッション、そして最後に、Oracle Master de Night（なんとなく似ている？　de　だけね）にもちゃんと参加してきましたよ。


今話題のSun Microsystemsさんのブースにて（T５４４０の256スレッドのデモ中）、知っている営業の方がいたので、つい話し込んでしまいました。あはは。


そしてちょっとしたサプライズ、MacとiPhoneがWendyのブースのお隣に！！！！（できればもっと目立つところに・・・・）


そして最後はOracle Master de Night!
ここで名刺交換した方々がこのブログをよく見てくださっているようで、名刺交換した時の反応に私自身が驚いてしまいました。:)
見て頂いてありがとうございます。

ところで、Oracle Master de Night!とMac De Oracleの"de"がかぶってますが、Mac De Oracleの"De"は、Cube De Zopeから頂いた"De"なんですよ。実はそれほど売れなかったPowerMac G4 Cubeでしたが、私はあのデザインが好きで未だにPowerMac G4 Cube保管してます。SonnetのCPUカード付けて1.2GhzにClock-upしてますけど。

ちょいと迷惑だったストアドファンクション（おまけ）

す〜〜ぱ〜〜し〜〜し〜〜でぃ〜〜っ。はにかむ、せぶん！
やけに耳の残っちゃうんだよな〜。あの声とアクセント。

なんて関係ない話はおいといて。。と


以前、
ちょいと迷惑だったストアドファンクション
ちょいと迷惑だったストアドファンクション（つづき）

ということを書いていたが、ちょいと迷惑だったストアドファンクションの例外ハンドラーで問題解決の手がかりとするためログ出力が実装されていたらどうするの？　っていうこともあるのでおまけのおまけということで書いておきます。

以前の例では例外ハンドラーをバッサリ切り捨ててしまったのですが、例外ハンドラーで問題解決の手がかりとするためのログ出力が実装されていて例外ハンドラーを取り除くことが出来ない場合、例外名無しのRAISE文を使えば解決できますよ。:)

ちょいと迷惑だったストアドファンクションの例外ハンドラーで問題解決の手がかりとするためのログ出力を実装していたらという例・・・・（赤太字部分）

尚、この例ではオープンソースのPL/SQL向けロギングフレームワークLog4PLSQLを利用している。

CREATE OR REPLACE
PACKAGE inconvenient_package
AS
  TYPE  employeesType IS TABLE OF emp%ROWTYPE INDEX BY BINARY_INTEGER;
  TYPE  membersType IS RECORD (
    deptNo    dept.deptNo%TYPE
   ,deptName  dept.dName%TYPE
   ,employees employeesType
  );
  FUNCTION inconvenient_function(iDeptNo IN dept.deptNo%TYPE)
    RETURN membersType;
END inconvenient_package;
/
show errors


CREATE OR REPLACE
PACKAGE BODY inconvenient_package
AS
  FUNCTION inconvenient_function(iDeptNo IN dept.deptNo%TYPE)
  RETURN membersType
  AS
    members         membersType;
    Log4PlsqlCtx    plogparam.log_ctx := plog.init(pDBMS_OUTPUT => TRUE); -- Log4PLSQL setting
  BEGIN
    SELECT
      deptNo
     ,dName
    INTO
      members.deptNo
     ,members.deptName
    FROM
      dept
    WHERE
      deptNo = iDeptNo
    ;
    --
    SELECT *
    BULK COLLECT INTO
      members.employees
    FROM
      emp
    WHERE
      deptno = iDeptNo
    ;
    RETURN members;
  EXCEPTION
    WHEN NO_DATA_FOUND THEN
      plog.warn(Log4PlsqlCtx, sqlerrm());  -- Log4PLSQL warnning
      RETURN NULL;
  END inconvenient_function;
END inconvenient_package;
/
show errors

変更前ファンクションの例外ハンドラー部分にある"RETURN NULL;"を"RAISE;"（例外名無しのRAISE文）に変更するだけ。

CREATE OR REPLACE
PACKAGE BODY inconvenient_package
AS
  FUNCTION inconvenient_function(iDeptNo IN dept.deptNo%TYPE)
  RETURN membersType
  AS
    members         membersType;
    Log4PlsqlCtx    plogparam.log_ctx := plog.init(pDBMS_OUTPUT => TRUE); -- Log4PLSQL setting
  BEGIN
    SELECT
      deptNo
     ,dName
    INTO
      members.deptNo
     ,members.deptName
    FROM
      dept
    WHERE
      deptNo = iDeptNo
    ;
    --
    SELECT *
    BULK COLLECT INTO
      members.employees
    FROM
      emp
    WHERE
      deptno = iDeptNo
    ;
    RETURN members;
  EXCEPTION
    WHEN NO_DATA_FOUND THEN
      plog.warn(Log4PlsqlCtx, sqlerrm());  -- Log4PLSQL warnning
      RAISE;
  END inconvenient_function;
END inconvenient_package;
/

例外ハンドラー内で例外名を省略すると該当する例外がさらに外側のブロックへスローされます。詳細はマニュアル（Oracle Database PL/SQL Language Reference 11g Release 1 : RIASE statement）及び、Oracle Database PL/SQL Language Reference 11g Release 1 : How PL/SQL Exceptions Propagate参照のこと。

SCOTT> set linesize 132
SCOTT> set serveroutput on
SCOTT> l
  1  DECLARE
  2    members inconvenient_package.membersType;
  3    Log4PlsqlCtx plogparam.log_ctx := plog.init(pDBMS_OUTPUT => TRUE);
  4  BEGIN
  5    BEGIN
  6      members := inconvenient_package.inconvenient_function(99);
  7      DBMS_OUTPUT.PUT_LINE(
  8        'Dept name/id:'
  9        ||members.deptname
 10        ||'/'||TO_CHAR(members.deptno)
 11      );
 12      FOR i IN members.employees.FIRST..members.employees.LAST LOOP
 13        DBMS_OUTPUT.PUT_LINE(' -- '||members.employees(i).ename);
 14      END LOOP;
 15    EXCEPTION
 16      WHEN NO_DATA_FOUND THEN
 17        plog.warn(Log4PlsqlCtx, sqlerrm());
 18    END;
 19* END;
SCOTT> /
12:35:27:02-WARN-block-->SCOTT.INCONVENIENT_PACKAGE  ORA-01403: データが見つかりません。
12:35:27:03-WARN-block  ORA-01403: データが見つかりません。

PL/SQLプロシージャが正常に完了しました。

SCOTT> l
  1  DECLARE
  2    members inconvenient_package.membersType;
  3    Log4PlsqlCtx plogparam.log_ctx := plog.init(pDBMS_OUTPUT => TRUE);
  4  BEGIN
  5    BEGIN
  6      members := inconvenient_package.inconvenient_function(10);
  7      DBMS_OUTPUT.PUT_LINE(
  8        'Dept name/id:'
  9        ||members.deptname
 10        ||'/'||TO_CHAR(members.deptno)
 11      );
 12      FOR i IN members.employees.FIRST..members.employees.LAST LOOP
 13        DBMS_OUTPUT.PUT_LINE(' -- '||members.employees(i).ename);
 14      END LOOP;
 15    EXCEPTION
 16      WHEN NO_DATA_FOUND THEN
 17        plog.warn(Log4PlsqlCtx, sqlerrm());
 18    END;
 19* END;
SCOTT> /
Dept name/id:ACCOUNTING/10
-- CLARK
-- KING
-- MILLER

PL/SQLプロシージャが正常に完了しました。

SCOTT> 

Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #6（おまけ）

Oracle JDeveloper 11gのQuickStartからオンラインマニュアルへジャンプできなくても大した問題ではないのですが・・・とりあえず書いときます。
QuickStartからオンラインドキュメントへジャンプできるようになっているようなのだが、クリックすると、「ブラウザが見つかりません」と言われ、「了解」ボタンをクリックすると開く「ブラウザ選択」でSafariを選んでも「ブラウザが見つかりません」と言われる。ン〜〜。という状態、QuickStartにはPerferenceも無いようなのでFirefoxで試すことはしてない・・・面倒なのとQUickStartから開けなくても困らないから。というの理由で。

QuickStartのオンラインドキュメントのアクセスをクリックすると「ブラウザが見つかりません」。。なんで？


「了解」ボタンをクリックしてブラウザ（この例ではSafari）を選択して．．．．．と


でもやっぱりブラウザが見つかりません・・・・なんですよね。OTNのドキュメントダウンロードすればいいのでこれ以上は調べてないですが・・・

---

バックナンバー
・Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #1
・Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #2
・Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #3
・Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #4
・Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #5

Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #5

PowerMac G5 + Java SE6.0 DP1 de Oracle JDeveloper 11gとOracle Weblogic Server 10.3をインストールしちゃうぞ〜の最終回。

前回はJDeveloper 11gを起動して超簡単な動作確認までだった。

今回はBEA Weblogic Server改めOracle WebLogic Server 10.3のコンフィギュレーションから起動確認まで

QuickStartから「Oracle ADFのドメインコンフィギュレーション」をクリック
（2009/4/11画像が間違っていたので入れ替えた）


見慣れない（当然ですが）スプラッシュが．．

特に変更するところもなくインストーラのデフォルト設定でコンフィギュレーションした。この例で管理ユーザ名はweblogicにしたが、scottにもできるよ。w










ドメインを入力（この例ではmac_de_oracle）して・・・・



ということで無事コンフィギュレーション終了。

続いて、Oracle Weblogic Server 10.3を起動してAdministration Consoleへログインできることを確認。

その前に 山本祐介さんのWebLogic Server 10g Release 3 を Mac OSX にインストール に記載されているSetDomainEnv.shのJAVA_VENDORの変更を行う。

G5Server:/Volumes/DiscusWork/Development/Oracle/Middleware/user_projects/domains/mac_de_oracle/bin discus$ diff setDomainEnv.sh.org setDomainEnv.sh
89c89,90
<               JAVA_VENDOR="Unknown"
---
> #             JAVA_VENDOR="Unknown"     #modified at 2009/3/18
>               JAVA_VENDOR="Sun"

G5Server:˜ discus$ 
G5Server:˜ discus$ cd /Volumes/DiscusWork/Development/Oracle/Middleware/user_projects/domains/mac_de_oracle/bin
G5Server:/Volumes/DiscusWork/Development/Oracle/Middleware/user_projects/domains/mac_de_oracle/bin discus$ ./startWebLogic.sh
/Volumes/DiscusWork/Development/Oracle/Middleware/user_projects/domains/mac_de_oracle/bin/startWebLogic.sh: Don't know how to set the shared library path for Darwin.  
.
.
JAVA Memory arguments: -Xms256m -Xmx512m -XX:CompileThreshold=8000 -XX:PermSize=48m  -XX:MaxPermSize=128m
.
WLS Start Mode=Development
.
・・・・中略・・・・
.
***************************************************
*  To start WebLogic Server, use a username and   *
*  password assigned to an admin-level user.  For *
*  server administration, use the WebLogic Server *
*  console at http://hostname:port/console        *
***************************************************
starting weblogic with Java version:
java version "1.6.0-dp"
Java(TM) SE Runtime Environment (build 1.6.0-dp-b88-34)
Java HotSpot(TM) Core VM (build 1.6.0-b88-17-release, interpreted mode, sharing)
Starting WLS with line:

・・・・中略・・・・

<2009/03/18 7時28分12秒 JST> <Notice> <WebLogicServer> <BEA-000365> <サーバ状態が RUNNING に変化しました。> 
<2009/03/18 7時28分12秒 JST> <Notice> <WebLogicServer> <BEA-000360> <サーバが RUNNING モードで起動しました。> 

変更後、startWebLogic.shのままTerminalから起動してもいいし、.sh拡張子を.commandへ変更しダブルクリックで起動してもOK。





使えそうですね。:)

---

バックナンバー
・Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #1
・Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #2
・Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #3
・Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #4

Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #4

PowerMac G5 + Java SE6.0 DP1 de Oracle JDeveloper 11gとOracle Weblogic Server 10.3をインストールしちゃうぞ〜の続きです。

前回はJDeveloper 11gをインストールしてQuickStartが起動したところまでだった。今回はそのつづきでインストールしたJDeveloper 11gを起動し、JDeveloper 10gで作成したProjectを取込むところまでを確認しておく。

「JDeveloper 11g の起動」をクリック

「ロールの選択」ダイアログでは「デフォルトのロール」ラジオボタンを選択後、毎回起動時に聞かれるのはうざいので「起動時にロール選択を常に要求」チェックボックのチェックをはずして「OK」ボタンをクリック


見慣れたJDeveloperのスプラッシュ


「ユーザ設定の移行」では「はい」ボタンをクリックして移行を許可。（お、ちょっとしたバグ発見、ダイアログの文言が「以前のリリースから設定を移行しま　か」と「す」が全角空白になってる。）


「ユーザー設定の移行」は参照先をそのまま受け入れるので「OK」ボタンをクリックする。


preview releaseでも見慣れたJDeveloper 11g
あとはJDeveloper 10gで作成したプロジェクトを開くと11gに合わせて移行してくれる。





PowerMac向けのJava SE 6.0 DP1でも取りあえず遊べそうね。:)

---

バックナンバー
・Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #1
・Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #2
・Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #3

Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #3

PowerMac G5 + Java SE6.0 DP1 de Oracle JDeveloper 11gとOracle Weblogic Server 10.3をインストールしちゃうぞ〜の続きです。

前回はローカルJDKをInstallerが認識できるようにしたところまでだった。

今回はそのそのつづき。
JDeveloper 11gのインストールからQuickStartが起動するまで。

JDKを認識したので「次へ」ボタンをクリックしてインストール開始

あとは終了まで、暫し待つ・・・

「QuickStart実行」チェックボックスをチェックして「完了ボタン」をクリック。

Installerが終了するとQuickStartが起動する。

うまくインストールできたようですね。
次回は、インストールしたJDeveloper 11gを起動してみる。ということでつづく。。

---

バックナンバー
・Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #1
・Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #2

Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #2

PowerMac G5 + Java SE6.0 DP1 de Oracle JDeveloper 11gとOracle Weblogic Server 10.3をインストールしちゃうぞ〜の続きです。

前回はOTNからJDeveloper 11g Studio Edition (Base Install For all the platforms without JDK 6)を入手したところまでだったので、今回はOracleあたらしいインストーラ？！（どうもBEAさんのものをベースにしたみたい・・・インストーラを起動するとcom.bea・・・と表示されるし）を起動するところまで。


ということで早速取りかかる．．

・ダウンロードしたJDeveloper 11g installのjarファイル

ファインダーからアプリケーション→ユーティリティ→Java→Java SE 6→Java Preferenceを起動し、Java Application Running SettingでJava SE 6が一番上に来ていることを確認。（このようになっていないとダブルクリックでは起動できないのでご注意を。）

Java SE 6.0 PD1のJava PreferenceのJava Application Running Settingだけではshell上のパスまでは変更してくれないので、手動でJDKへのパスをJava SE 5.0からava SE 6.0へ変更しちゃいます。(PowerPC版のMacOSXではJava SE 6は正式にはリリースされていないので面倒なのは仕方ないですね。）
シンボリックリンク CurrentJDKが1.5を指してしるので1.6に切り替えちゃいます。これでJava SE 6.0 DP1が動きます。

G5Server:˜ discus$ cd /System/Library/Frameworks/javaVM.framework/Versions
G5Server:/System/Library/Frameworks/javaVM.framework/Versions discus$ ll
total 48
lrwxr-xr-x    1 root  wheel    5 Sep 25 21:27 1.3 -> 1.3.1
drwxr-xr-x    8 root  wheel  272 Jul 21  2005 1.3.1
lrwxr-xr-x    1 root  wheel    5 Sep 25 21:27 1.4 -> 1.4.2
drwxr-xr-x    8 root  wheel  272 Jul 21  2005 1.4.2
lrwxr-xr-x    1 root  wheel    5 Sep 25 21:27 1.5 -> 1.5.0
drwxr-xr-x    9 root  wheel  306 Mar 17 19:54 1.5.0
lrwxr-xr-x    1 root  wheel    5 Jul 21  2007 1.6 -> 1.6.0
drwxr-xr-x   10 root  wheel  340 Mar 24 10:30 1.6.0
drwxr-xr-x    6 root  wheel  204 Mar 17 19:53 A
lrwxr-xr-x    1 root  wheel    1 Sep 25 21:27 Current -> A
lrwxr-xr-x    1 root  wheel    3 Mar 24 10:32 CurrentJDK -> 1.5
G5Server:/System/Library/Frameworks/javaVM.framework/Versions discus$ java -version
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-275)
Java HotSpot(TM) Client VM (build 1.5.0_16-132, mixed mode)
G5Server:/System/Library/Frameworks/javaVM.framework/Versions discus$ ll
total 48
lrwxr-xr-x    1 root  wheel    5 Sep 25 21:27 1.3 -> 1.3.1
drwxr-xr-x    8 root  wheel  272 Jul 21  2005 1.3.1
lrwxr-xr-x    1 root  wheel    5 Sep 25 21:27 1.4 -> 1.4.2
drwxr-xr-x    8 root  wheel  272 Jul 21  2005 1.4.2
lrwxr-xr-x    1 root  wheel    5 Sep 25 21:27 1.5 -> 1.5.0
drwxr-xr-x    9 root  wheel  306 Mar 17 19:54 1.5.0
lrwxr-xr-x    1 root  wheel    5 Jul 21  2007 1.6 -> 1.6.0
drwxr-xr-x   10 root  wheel  340 Mar 24 10:30 1.6.0
drwxr-xr-x    6 root  wheel  204 Mar 17 19:53 A
lrwxr-xr-x    1 root  wheel    1 Sep 25 21:27 Current -> A
lrwxr-xr-x    1 root  wheel    3 Mar 24 10:32 CurrentJDK -> 1.5
G5Server:/System/Library/Frameworks/javaVM.framework/Versions discus$ sudo rm CurrentJDK
G5Server:/System/Library/Frameworks/javaVM.framework/Versions discus$ sudo ln -s 1.6 CurrentJDK
G5Server:/System/Library/Frameworks/javaVM.framework/Versions discus$ cd
G5Server:˜ discus$ 
G5Server:˜ discus$ java -version
java version "1.6.0-dp"
Java(TM) SE Runtime Environment (build 1.6.0-dp-b88-34)
Java HotSpot(TM) Core VM (build 1.6.0-b88-17-release, interpreted mode)
G5Server:˜ discus$ 

ということで、jdevstudio11110install.jarをダブルクリックしてinstallerを起動！

お〜〜起動しました〜〜パチパチ。

あとはインストーラの指示にしたがいクリックしていくだけ。
（この例ではOracle MIddleware Home Directoryを/Volumes/DiscusWork/Development/Oracle/Middlewareにしてあります。）

ん、ん、あれ〜、Java Perference及びJava SE 6.0 DP1へのパスを変更したのにJDKが見えないとでますね〜。

あ〜、忘れてました。これはRelease Noteに書かれていた既知の問題の一つですね。
Release NoteにはClasses.jarとrt.jarへシンボリックリンクを張るように記載されていますが、この例では山本祐介さんのWebLogic Server 10g Release 3 を Mac OSX にインストールで紹介されている方法で対処しました。

G5Server:˜ discus$ cd /System/Library/Frameworks/javaVM.framework/Versions/CurrentJDK/Home 
G5Server:/System/Library/Frameworks/javaVM.framework/Versions/CurrentJDK/Home discus$ ll
total 8
drwxr-xr-x   42 root  wheel  1428 Jul 21  2007 bin
lrwxr-xr-x    1 root  wheel    10 Jul 21  2007 include -> ../Headers
drwxr-xr-x   38 root  wheel  1292 Mar 17 19:56 lib
drwxr-xr-x   24 root  wheel   816 Jul 21  2007 man
G5Server:/System/Library/Frameworks/javaVM.framework/Versions/CurrentJDK/Home discus$  sudo mkdir jre
Password:
G5Server:/System/Library/Frameworks/javaVM.framework/Versions/CurrentJDK/Home discus$  sudo mkdir jre/lib
G5Server:/System/Library/Frameworks/javaVM.framework/Versions/CurrentJDK/Home discus$  sudo touch jre/lib/rt.jar
G5Server:/System/Library/Frameworks/javaVM.framework/Versions/CurrentJDK/Home discus$  sudo touch jre/lib/core.jar
G5Server:/System/Library/Frameworks/javaVM.framework/Versions/CurrentJDK/Home discus$ 

前述の対処でローカルJDKを認識したようですね。ただし、unknown JDK　:)

次回へつづく。。。

---

バックナンバー
・Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #1

Oracle JDeveloper 11g (Build 5188) - with Oracle WebLogic Server 10.3 - #1

Oracle JDeveloper 11g (Build 5188) - Base Install (For all the platforms without JDK6.0で、Oracle JDeveloper11g にOracle WebLogic Server 10.3がバンドルされリリースされていたのでいままで使っていたJDeveloper10gと入れ替えてみた。

尚、
MacOSX 10.4.11 Tiger/PowerPC G5かつ今は多分入手できないんじゃないかと思うけどPowerPC/MacOSX Tiger向けJava SE6.0 Developer Preview 1という環境なので、ちょっとした確認なら使えない事もないかな〜ぐらいの軽い気持ちで使うのが吉ですよん。たぶん。
Java SE6.0 DP1を使うので。

（あ、そうそう、Intel版の64bit環境かつMacOSX 10.5 Leopardはすんなり出来そうなので後日。）

尚、MacOSXへインストールする際の注意があるので事前に把握しておくといいですよ。
・JDeveloper 11g Release Notes
・Installing JDeveloper on Mac OS

それと山本祐介さんのWebLogic Server 10g Release 3 を Mac OSX にインストールの記事も参考にさせて頂いた。

まずは今回の環境から：

・H/W : Apple PowerMac G5 Dual 2.7Ghz RAM 3GB
・OS : MacOSX 10.4.11 Tiger Server（Serverである必要はないですよ。）
・JDK : Java SE 6.0 Developer Preview 1

という環境へOracle JDeveloper 11g とOracle WebLogic Server 10.3をインストールする。

OTNからOracle JDeveloper 11g Studio Edition (Base Install
For all the platforms without JDK 6)をダウンロードする。


ながくなるので次回へつづく。

In Oracle Database 11g, native dynamic SQL now supports statements bigger than 32K characters

久々にOracleネタ。

Oracle11gのPL/SQLのDynamic SQLでCLOBが使えるようになったようなので試してみた。
10gまではexecute immediate文で使えるのは最大でVARCHAR2(32767)までだったワケで、ど〜〜〜〜〜〜しても（書きたくないけど・・）巨大なSQL文をダイナミックに実行しなきゃいけない人には朗報？なんでしょうね。（DWH系ではCLOBが必要なくらい巨大なクエリをダイナミックに生成するなんてこともあるんでしょうね。私は今のところ３２Kを超えるクエリは書いたことないけどそれに近いのは過去１度あったかな？！　という程度。）

ということで10gと11g for linux(x86)を使って確認！（ClientはMacOSX(PPC)版Instant Clientですよん）

まず最初はOracle10g
execute immediate文に利用できるのはVARCHAR2(32767)が最大サイズなのでダイナミックに生成するSQL文もそのサイズに制限されちゃう。VARCHAR2(32767)を超えるとORA-06502が発生する。（尚、10gの場合でもDBMS_SQLを使えばもっと大きいサイズの動的SQLも使用できる。）

G5Server:˜ discus$ sqlplus /nolog

SQL*Plus: Release 10.1.0.3.0 - Production on 金 2月 6 1:19:22 2009

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

> conn scott@catfish
パスワードを入力してください: 
接続されました。
SCOTT> set serveroutput on
SCOTT> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - Prod
PL/SQL Release 10.1.0.3.0 - Production
CORE    10.1.0.3.0      Production
TNS for Linux Server: Version 10.1.0.3.0 - Production
NLSRTL Version 10.1.0.3.0 - Production

SCOTT> l
  1  CREATE OR REPLACE PROCEDURE dynamic_sql_test10g(iLength IN NUMBER)
  2  IS
  3    vSQL VARCHAR2(32767);
  4    vResult NUMBER;
  5  BEGIN
  6    vSQL := 'SELECT 1';
  7    FOR i IN 1.. iLength LOOP
  8      vSQL := vSQL || '+1';
  9    END LOOP;
 10    vSQL := vSQL || ' FROM DUAL';
 11    EXECUTE IMMEDIATE vSQL INTO vresult;
 12    DBMS_OUTPUT.PUT_LINE('Result:'||TO_CHAR(vresult));
 13* END;
SCOTT> /

プロシージャが作成されました。

SCOTT> exec dynamic_sql_test10g(16374);
Result:16375

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec dynamic_sql_test10g(16375);
BEGIN dynamic_sql_test10g(16375); END;

*
行1でエラーが発生しました。:
ORA-06502: PL/SQL: 数値または値のエラー:
文字列バッファが小さすぎます。が発生しました ORA-06512:
"SCOTT.DYNAMIC_SQL_TEST10G", 行10
ORA-06512: 行1

SCOTT> 

11gの場合
execute immediate文にCLOBが使えるようになったことで以下のように３２Ｋ超えの動的SQLも実行できちゃうのだ。

注）
以下のコードで遊ぶときは個人で遊べるデータベースでやってくださいね。（本番データベースや多数の開発者で共有しているテスト／開発データベースでどとんでもなく巨大なクエリを実行すると他の方の迷惑になるので・・・・・）

SCOTT> 
SCOTT> conn scott@lampeye
パスワードを入力してください: 
接続されました。
SCOTT>
SCOTT> 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 Linux: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production

SCOTT> 
SCOTT> l
  1  CREATE OR REPLACE PROCEDURE dynamic_sql_test11g(iLength IN NUMBER)
  2  IS
  3    vSQL CLOB;
  4    vResult NUMBER;
  5  BEGIN
  6    vSQL := 'SELECT 1';
  7    FOR i IN 1.. iLength LOOP
  8      vSQL := vSQL || '+1';
  9    END LOOP;
 10    vSQL := vSQL || ' FROM DUAL';
 11    EXECUTE IMMEDIATE vSQL INTO vresult;
 12    DBMS_OUTPUT.PUT_LINE('Result:'||TO_CHAR(vresult));
 13* END;
SCOTT> /

プロシージャが作成されました。

SCOTT> set serveroutput on
SCOTT> exec dynamic_sql_test11g(32767);
Result:32768

PL/SQLプロシージャが正常に完了しました。

SCOTT> 
SCOTT> set timi on  
SCOTT> exec dynamic_sql_test11g(1000000);
Result:1000001

PL/SQLプロシージャが正常に完了しました。

経過: 00:06:25.93
SCOTT> 

iPhone 3G の iSSH de Oracle11g へアクセス

iPhone App StoreでiSSHというiPhone向けsshアプリを購入（¥600円）

早速iSSHからLinux(x86)へ接続してOracle11gのSQL*Plusでお遊び。
限られた画面サイズなので使い易いとは言いがたいが何かの時には使えるでしょう。多分。w

１０日後は何日？、翌月末日って何日？

ichii386さん「相対的な日付って」記事に背骨というか脊髄反応的にコメントした勢いで、今日の１０日後は何日？、翌月末日って何日？の算出を幾つかやってみた。（「オリジナルの記事は今月末を求めているんですけど・・・・」・・・・ハイ、私が読み間違えて”翌月末”と勘違いしてました。今気付いたよ。w）

なんでgnuとphpだけなの? という突っ込みはなしで…。

なんでFirebirdが無いのかとか、CachéでSQLを使わないでMUMPSというかM言語というかCaché ObjectScriptなのかとか、Oracle11gなのに、MySQLは5.0でPostgreSQLは7.4.9なのかとか、というツッコミはなしで...w

前提：
今日は１月２４日として、１０日後、翌月末日を算出します。

まずはPowerPC版のは古いのしかなかったのでCaché 5.2 for MacOSX(PowerPC)
MUMPS(M言語)がCachéで拡張？されてObjectiveになっちゃってObjectScriptと呼ばれているのには少々戸惑うけど、そこは昔取った杵柄。SQLも使えるけどM言語の方が作り易かったので。。w
ObjectScriptだと日付レベルで何日前とか何日後という計算は簡単なのだが、何ヶ月後とかいう計算は面倒なので。
（算出方法は翌々月の１日の前日が翌月末という考え方です。）

G5Server:˜ discus$ csession cache -U user

USER>
USER>w !,$zversion

Cache for UNIX (Mac OS X/32-bit) 5.2 (Build 329U_su) Wed Jun 21 2006 11:29:29 EDT
USER>
USER>
USER>w !,$zd($h+10,3)

2009-02-03
USER>s now=$h, y=$e($zd(now),7,10), m=$e($zd(now),1,2) w !,$zd($zdh($s(m<11:y_m+2_"01", m>10:y+1_m-10_"01"),5)-1,3)

2009-02-28
USER>
USER>halt
G5Server:˜ discus$ 

次は、Oracle11g EE 11.1.0.6.0 for Linux(x86)
OracleのSQLだとlast_day()や期間リテラルで簡単に算出できる。お気楽モード :-)

G5Server:˜ discus$ sqlplus /nolog

SQL*Plus: Release 10.1.0.3.0 - Production on 土 1月 24 13:53:33 2009

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

> conn scott/tiger@lampeye
接続されました。
SCOTT> 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 Linux: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production

SCOTT> 
SCOTT> alter session set nls_date_format = 'yyyy-mm-dd';

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

SCOTT> select sysdate + interval '10' day from dual;

SYSDATE+IN
----------
2009-02-03

SCOTT> select last_day(sysdate + interval '1' month) from dual;

LAST_DAY(S
----------
2009-02-28

SCOTT> 
SCOTT> exit
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing optionsとの接続が切断されました。
G5Server:˜ discus$ 

お次は、MySQL Community Server 5.0.67 for MacOSX(PowerPC)版
MySQL5.0でもOracleと同様にlast_day()と期間リテラルだけで算出できます。こちらもOracle同様、余計なことを悩まなくてすみますね。(^^)

G5Server:˜ discus$ mysql --version
mysql  Ver 14.12 Distrib 5.0.67, for apple-darwin8.11.0 (powerpc) using readline 5.1
G5Server:˜ discus$ mysql -u scott -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 177
Server version: 5.0.67 MySQL Community Server (GPL)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> select curdate() + interval 10 day;
+-----------------------------+
| curdate() + interval 10 day |
+-----------------------------+
| 2009-02-03                  | 
+-----------------------------+
1 row in set (0.00 sec)

mysql> select last_day(curdate() + interval 1 month);
+----------------------------------------+
| last_day(curdate() + interval 1 month) |
+----------------------------------------+
| 2009-02-28                             | 
+----------------------------------------+
1 row in set (0.00 sec)

mysql> 
mysql> exit
Bye
G5Server:˜ discus$ 

最後にPosgreSQL 7.4.9 for MacOSX(PowerPC)版
１０日後は期間リテラルで単純に算出可能だが、OracleやMySQLとは異なりlast_day()のような関数が無い(マニュアルをみたけど該当する関数が見当たらない）ので翌々月１日の前日で算出してみた。

G5Server:˜ discus$ psql -U scott postgresql749
Password: 
Welcome to psql 7.4.9, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help on internal slash commands
       \g or terminate with semicolon to execute query
       \q to quit

postgresql749=# 
postgresql749=# select version();
                                                         version                                                         
-------------------------------------------------------------------------------------------------------------------------
 PostgreSQL 7.4.9 on powerpc-apple-darwin8.3.0, compiled by GCC gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1809)
(1 row)

postgresql749=# select cast(current_date + interval '10 day' as date);
    date    
------------
 2009-02-03
(1 row)

postgresql749=# select cast(to_date(to_char(current_date + interval'2 months','yyyymm')||'01','yyyymmdd') - interval '1 day' as date);
    date   
 ------------
 2009-02-28
(1 row)


postgresql749=# \q
G5Server:˜ discus$ 

CachéではObjectScript（M言語）を使ったので脇に置いといて、他の３つのデータベースのSQLでは期間リテラル（interval)の書き方が微妙に異なるも点は知っておいたほうがいいかも。

---

今日も息子は保育園でバイバイせず結構泣いてた、最近、保育園にくるとパパもママもSee Ya! といっていなくなってしまうことに気付いた模様。いずれ慣れるだろうけど。。

謹賀新年

この画面を見るためだけの目的でMacOS9を起動．．．w

よいお年を！

さて、来年はいいことあるでしょうかね。みなさん、良いお年を！

懐かしいMacOS9のHappy new year風のスタートアップスクリーンで。

うるう秒か

そういえば来年の１月１日はうるう秒があるんだった。２００６年にもあったからちゃんと対応しているところは対応していると思うけど。。。。。。。

ちなみに、Oracleに関しては以下のKROWNが公開されているので一読しておくといいよ。
16785:システム時刻の変更にともなう注意点

33273: うるう秒について

ということでOracle11gのお遊び環境のNTPはちゃんとslewモードで調整するようになっているか確認しておくか．．

[root@corydoras ˜]# vi /etc/sysconfig/ntpd

# Drop root to id 'ntp:ntp' by default.
OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"

# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=yes

[root@corydoras ˜]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ntp-a2.nict.go. .NICT.           1 u   42   64   17    7.282    0.368   0.518
*ntp1.jst.mfeed. 210.173.160.56   2 u   42   64   17    4.127    0.590   0.135
+ntp2.jst.mfeed. 210.173.160.86   2 u   42   64   17    3.717    0.414   0.213
+ntp3.jst.mfeed. 210.173.160.86   2 u   41   64   17    3.355    0.460   0.308
[root@corydoras ˜]#

うちのは問題ないな。

(2015/6/16　更新）

Mac de Oracle - １０万円未満 de RAC (11g編）#28

今回はTransparent Application Failover (TAF)を簡単な方法で確認

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１、その２、その３
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成　その１、その２、その３
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）☆項番１９．で確認してしまったので削除

---

２２．簡単なTransparent Application Failover (TAF)の確認

１．TAFの設定。
Oracle Database Net Servicesリファレンス 11g リリース1（11.1） - FAILOVER_MODE等のマニュアル参照のこと。（11/30:リンク先変更。オラクルさんのオンラインマニュアルのURL変更が激し過ぎ。なんとかして〜
USのOTNのマニュアルはリンク切れしてないのに...）

G5Server:˜ discus$ tail -16 $TNS_ADMIN/tnsnames.ora

RACTAF =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = discus1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = discus2-vip)(PORT = 1521))
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl.macdeoracle.info)
      (FAILOVER_MODE =
        (TYPE = SELECT)
        (METHOD = BASIC)
        (RETRIES = 180)
        (DELAY = 5)
      )
    )
  )

２．scottユーザでログインして表などを問い合わせておく。

G5Server:˜ discus$ sqlplus /nolog

SQL*Plus: Release 10.1.0.3.0 - Production on 月 10月 20 01:08:31 2008

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

> conn scott/tiger@orcl
接続されました。
SCOTT> 
SCOTT> select count(*) from user_objects;

  COUNT(*)
----------
         5

ここでorcl2をabortで停止（その間に行っていた操作は「３．orcl2の強制停止と接続先の確認」を参照のこと）。

orcl2に接続されていたscottユーザでは特にエラーもなくクエリを発行できる。この時既にfailoverしorcl1からorcl2へセッションが引き継がれている。
SCOTT> select count(*) from user_objects;

  COUNT(*)
----------
         5

SCOTT> 

３．orcl2の強制停止と接続先の確認

orcl2をabortで強制停止、scootの接続がfailoverしたことを確認。

[oracle@discus1 ˜]$ 
[oracle@discus1 ˜]$ 
[oracle@discus1 ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on 月 10月 20 01:14:52 2008

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

SQL> conn sys@orcl1 as sysdba
パスワードを入力してください: 
接続されました。
SQL> 
SYS> l
  1  select
  2    instance_name
  3   ,username
  4   ,failover_type
  5   ,failover_method
  6   ,failed_over
  7  from
  8    gv$session sess join gv$instance inst
  9    on sess.inst_id = inst.inst_id
 10  where
 11*   sess.username = 'SCOTT'
SYS> /

INSTANCE_NAME    USERNAME                       FAILOVER_TYPE FAILOVER_M FAI
---------------- ------------------------------ ------------- ---------- ---
orcl2            SCOTT                          SELECT        BASIC      NO

SYS> !srvctl status database -d orcl
インスタンスorcl1はノードdiscus1で実行中です。
インスタンスorcl2はノードdiscus2で実行中です。

SYS> !srvctl stop instance -d orcl -i orcl2 -o abort

SYS> !srvctl status database -d orcl
インスタンスorcl1はノードdiscus1で実行中です。
インスタンスorcl2はノードdiscus2で実行されていません。

SYS> l
  1  select
  2    instance_name
  3   ,username
  4   ,failover_type
  5   ,failover_method
  6   ,failed_over
  7  from
  8    gv$session sess join gv$instance inst
  9    on sess.inst_id = inst.inst_id
 10  where
 11*   sess.username = 'SCOTT'
SYS> /

INSTANCE_NAME    USERNAME                       FAILOVER_TYPE FAILOVER_M FAI
---------------- ------------------------------ ------------- ---------- ---
orcl1            SCOTT                          SELECT        BASIC      YES

SYS> 

Oracle11g for Linux x86(CentOS5.2)とiSCSI(Openfiler2.3)を使った安価なOracle11g R1 RAC構築完

Mac de Oracle - １０万円未満 de RAC (11g編）#27

今回はOracle Clusterwareプロセス・モニター・デーモンの構成

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１、その２、その３
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成　その１、その２、その３
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）☆項番１９．で確認してしまったので削除

---

２１．Oracle Clusterwareプロセス・モニター・デーモンの構成

以下のマニュアルを参考に。
Oracle Clusterware Installation Guide 11g Release 1 (11.1) for Linux
　- 7.1.2 Configure Input/Output Fencing
Oracle Clusterware Installation Guide 11g Release 1 (11.1) for Linux
　- 7.1.2.3 Configuring Oracle Clusterware Process Monitor Daemon

Cluster Database/ASMなどを停止（全ノード）

G5Server:˜ discus$ ssh root@discus1
root@discus1's password: 
Last login: Sat Oct 18 18:32:53 2008 from 192.168.1.19
[root@discus1 ˜]# su - oracle
[oracle@discus1 ˜]$ srvctl stop database -d orcl
[oracle@discus1 ˜]$ srvctl stop asm -n discus2
[oracle@discus1 ˜]$ srvctl stop asm -n discus1
[oracle@discus1 ˜]$ srvctl stop nodeapps -n discus2
[oracle@discus1 ˜]$ srvctl stop nodeapps -n discus1
[oracle@discus1 ˜]$ echo $ORA_CRS_HOME
/u01/app/crs
[oracle@discus1 ˜]$ exit
logout

rootユーザでRACの停止を確認（全てOFFLINEであればOK）

[root@discus1 ˜]# 
[root@discus1 ˜]# /u01/app/crs/bin/crs_stat
NAME=ora.discus1.ASM1.asm
TYPE=application
TARGET=OFFLINE
STATE=OFFLINE

NAME=ora.discus1.LISTENER_DISCUS1.lsnr
TYPE=application
TARGET=OFFLINE
STATE=OFFLINE

NAME=ora.discus1.gsd
TYPE=application
TARGET=OFFLINE
STATE=OFFLINE

・・・・中略・・・・

NAME=ora.orcl.db
TYPE=application
TARGET=OFFLINE
STATE=OFFLINE

NAME=ora.orcl.orcl1.inst
TYPE=application
TARGET=OFFLINE
STATE=OFFLINE

NAME=ora.orcl.orcl2.inst
TYPE=application
TARGET=OFFLINE
STATE=OFFLINE

crsの状態確認

[root@discus1 ˜]# 
[root@discus1 ˜]# /u01/app/crs/bin/crsctl check cluster
discus1    ONLINE
discus2    ONLINE
[root@discus1 ˜]# 

crsの停止（RAC全ノードのrootユーザで実施）

[root@discus1 ˜]# 
[root@discus1 ˜]# /u01/app/crs/bin/crsctl check crs
Cluster Synchronization Services appears healthy
Cluster Ready Services appears healthy
Event Manager appears healthy
[root@discus1 ˜]# 
[root@discus1 ˜]# 
[root@discus1 ˜]# /u01/app/crs/bin/crsctl stop crs
Stopping resources. 
This could take several minutes.
Successfully stopped Oracle Clusterware resources 
Stopping Cluster Synchronization Services. 
Shutting down the Cluster Synchronization Services daemon. 
Shutdown request successfully issued.
[root@discus1 ˜]# 
[root@discus1 ˜]# 
[root@discus1 ˜]# /u01/app/crs/bin/crsctl check crs
Failure 1 contacting Cluster Synchronization Services daemon
Cannot communicate with Cluster Ready Services
Cannot communicate with Event Manager
[root@discus1 ˜]# 

oprocdの停止手順が書いてあるがcrsを停止するとoprocdも停止するのでこの操作は不要なのでは？（マニュアルバグ？）とりあえずマニュアル通りにやったが・・・。（RAC全ノードのrootユーザで実施）

[root@discus1 ˜]# 
[root@discus1 ˜]# /u01/app/crs/bin/oprocd stop
Oct 20 02:53:05.858 | ERR | failed to connect to daemon, errno(111)
[root@discus1 ˜]# 
[root@discus1 ˜]# 
[root@discus1 ˜]# ps -ef | grep oprocd
root     23327 21934  0 02:54 pts/1    00:00:00 grep oprocd
[root@discus1 ˜]# 

diagwaitパラメータを１３秒に変更する。（この操作はRACを構成する１ノードから行う。）

[root@discus1 ˜]# /u01/app/crs/bin/crsctl set css diagwait 13 -force
Configuration parameter diagwait is now set to 13.
[root@discus1 ˜]# 

crsの起動（RAC全ノードのrootユーザで実施）

[root@discus1 ˜]# 
[root@discus1 ˜]# /u01/app/crs/bin/crsctl start crs
Attempting to start Oracle Clusterware stack 
The CRS stack will be started shortly
[root@discus1 ˜]# 
[root@discus1 ˜]# /u01/app/crs/bin/crsctl check crs
Cluster Synchronization Services appears healthy
Cluster Ready Services appears healthy
Event Manager appears healthy
[root@discus1 ˜]# 
[root@discus1 ˜]# ps -ef | grep oprocd
root     24758 22215  0 02:56 ?        00:00:00 /bin/sh /etc/init.d/init.cssd oprocd
root     25125 24758  0 02:56 ?        00:00:00 /u01/app/crs/bin/oprocd run -t 1000 -m 10000 -hsi 5:10:50:75:90 -f
root     26140 21934  0 02:57 pts/1    00:00:00 grep oprocd
[root@discus1 ˜]# 
[root@discus1 ˜]# /u01/app/crs/bin/oprocd check
Oct 19 03:16:49.630 | INF | daemon running in fatal mode
[root@discus1 ˜]# 

次回へつづく

Mac de Oracle - １０万円未満 de RAC (11g編）#26

今回はClusterの開始と停止の確認

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１、その２、その３
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成　その１、その２、その３
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）☆項番１９．で確認してしまったので削除

---

２０．Clusterの開始と停止の確認

下記はdiscus1で実施例。(ついでなのでEnterprise Manager Enterprise Managerの停止、起動も確認。）

[oracle@discus1 ˜]$ 
[oracle@discus1 ˜]$ emctl stop dbconsole
Oracle Enterprise Manager 11g Database Control Release 11.1.0.6.0 
Copyright (c) 1996, 2007 Oracle Corporation.  All rights reserved.
https://discus1.macdeoracle.jp:1158/em/console/aboutApplication
Stopping Oracle Enterprise Manager 11g Database Control ... 
 ...  Stopped. 
[oracle@discus1 ˜]$ srvctl stop database -d orcl
[oracle@discus1 ˜]$ srvctl status database -d orcl
インスタンスorcl1はノードdiscus1で実行されていません。
インスタンスorcl2はノードdiscus2で実行されていません。
[oracle@discus1 ˜]$ srvctl stop asm -n discus2
[oracle@discus1 ˜]$ srvctl status asm -n discus2
ASMインスタンス+ASM2はノードdiscus2で実行されていません。
[oracle@discus1 ˜]$ srvctl stop asm -n discus1
[oracle@discus1 ˜]$ srvctl status asm -n discus1
ASMインスタンス+ASM1はノードdiscus1で実行されていません。
[oracle@discus1 ˜]$ srvctl stop nodeapps -n discus2
[oracle@discus1 ˜]$ srvctl status nodeapps -n discus2
VIPはノードで実行されていません: discus2
GSDはノードで実行されていません: discus2
リスナーはノードで実行されていません:discus2
ONSデーモンはノードで実行されていません: discus2
[oracle@discus1 ˜]$ srvctl stop nodeapps -n discus1
[oracle@discus1 ˜]$ srvctl status nodeapps -n discus1
VIPはノードで実行されていません: discus1
GSDはノードで実行されていません: discus1
リスナーはノードで実行されていません:discus1
ONSデーモンはノードで実行されていません: discus1
[oracle@discus1 ˜]$ exit
logout
Connection to discus1 closed.
G5Server:˜ discus$ 
G5Server:˜ discus$ ssh root@discus1
root@discus1's password: 
Last login: Sun Oct 19 12:17:45 2008 from 192.168.1.19
[root@discus1 ˜]# shutdown -r now

Broadcast message from root (pts/1) (Sun Oct 19 18:33:05 2008):

The system is going down for reboot NOW!
[root@discus1 ˜]# exit
logoutConnection to discus1 closed.
G5Server:˜ discus$ ssh root@discus2
root@discus2's password: 
Last login: Sun Oct 19 12:17:55 2008 from 192.168.1.19
[root@discus2 ˜]# shutdown -r now

Broadcast message from root (pts/1) (Sun Oct 19 18:33:19 2008):

The system is going down for reboot NOW!
[root@discus2 ˜]# exit
logout
Connection to discus2 closed.
G5Server:˜ discus$ 

リブート中〜〜〜〜〜〜そしてリブート後、

Connection to discus2 closed.
G5Server:˜ discus$ ssh oracle@discus1
oracle@discus1's password: 
Last login: Sun Oct 19 15:47:12 2008 from 192.168.1.19
[oracle@discus1 ˜]$ srvctl status database -d orcl
インスタンスorcl1はノードdiscus1で実行中です。
インスタンスorcl2はノードdiscus2で実行中です。
[oracle@discus1 ˜]$ srvctl status asm -n discus2
ASMインスタンス+ASM2はノードdiscus2で実行中です。
[oracle@discus1 ˜]$ srvctl status asm -n discus1
ASMインスタンス+ASM1はノードdiscus1で実行中です。
[oracle@discus1 ˜]$ srvctl status nodeapps -n discus2
VIPはノードで実行中です: discus2
GSDはノードで実行中です: discus2
リスナーはノードで実行中です: discus2
ONSデーモンはノードで実行中です: discus2
[oracle@discus1 ˜]$ srvctl status nodeapps -n discus1
VIPはノードで実行中です: discus1
GSDはノードで実行中です: discus1
リスナーはノードで実行中です: discus1
ONSデーモンはノードで実行中です: discus1
[oracle@discus1 ˜]$

次回へつづく

Mac de Oracle - １０万円未満 de RAC (11g編）#25

今回はOralce RAC ClusterとDatabase構成の確認

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１、その２、その３
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成　その１、その２、その３
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）☆項番１９．で確認してしまったので削除

---

２０．Oralce RAC ClusterとDatabase構成の確認

[oracle@discus1 ˜]$ srvctl status database -d orcl
インスタンスorcl1はノードdiscus1で実行中です。
インスタンスorcl2はノードdiscus2で実行中です。
[oracle@discus1 ˜]$ srvctl status nodeapps -n discus1
VIPはノードで実行中です: discus1
GSDはノードで実行中です: discus1
リスナーはノードで実行中です: discus1
ONSデーモンはノードで実行中です: discus1
[oracle@discus1 ˜]$ srvctl status nodeapps -n discus2
VIPはノードで実行中です: discus2
GSDはノードで実行中です: discus2
リスナーはノードで実行中です: discus2
ONSデーモンはノードで実行中です: discus2
[oracle@discus1 ˜]$ srvctl status asm -n discus1
ASMインスタンス+ASM1はノードdiscus1で実行中です。
[oracle@discus1 ˜]$ srvctl status asm -n discus2
ASMインスタンス+ASM2はノードdiscus2で実行中です。
[oracle@discus1 ˜]$ srvctl config database
orcl
[oracle@discus1 ˜]$ srvctl config database -d orcl
discus1 orcl1 /u01/app/oracle/product/11.1.0/db_1
discus2 orcl2 /u01/app/oracle/product/11.1.0/db_1
[oracle@discus1 ˜]$ srvctl config nodeapps -n discus1 -a -g -s -l
VIPが存在します。: /discus1-vip/192.168.1.100/255.255.255.0/eth0
GSDが存在します。
ONSデーモンが存在します。
リスナーが存在します。
[oracle@discus1 ˜]$ srvctl config nodeapps -n discus2 -a -g -s -l
VIPが存在します。: /discus2-vip/192.168.1.101/255.255.255.0/eth0
GSDが存在します。
ONSデーモンが存在します。
リスナーが存在します。
[oracle@discus1 ˜]$ srvctl config asm -n discus1
+ASM1 /u01/app/oracle/product/11.1.0/db_1
[oracle@discus1 ˜]$ srvctl config asm -n discus2
+ASM2 /u01/app/oracle/product/11.1.0/db_1

[oracle@discus1 ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on 日 10月 19 15:57:38 2008

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

SQL> conn sys@orcl as sysdba
パスワードを入力してください: 
接続されました。
SQL> l
  1  select name from v$datafile
  2  union
  3  select member from v$logfile
  4  union
  5  select name from v$controlfile
  6  union
  7* select name from v$tempfile
SQL> /

NAME
--------------------------------------------------------------------------------
+FLASH_RECOVERY_AREA/orcl/controlfile/current.268.667323469
+FLASH_RECOVERY_AREA/orcl/onlinelog/group_1.269.667323483
+FLASH_RECOVERY_AREA/orcl/onlinelog/group_2.270.667323497
+FLASH_RECOVERY_AREA/orcl/onlinelog/group_3.271.667336061
+FLASH_RECOVERY_AREA/orcl/onlinelog/group_4.272.667336077
+ORCL_DATA1/orcl/controlfile/current.295.667323465
+ORCL_DATA1/orcl/datafile/apex.302.667323623
+ORCL_DATA1/orcl/datafile/example.303.667323669
+ORCL_DATA1/orcl/datafile/sysaux.299.667323543
+ORCL_DATA1/orcl/datafile/system.298.667323505
+ORCL_DATA1/orcl/datafile/undotbs1.300.667323559

NAME
--------------------------------------------------------------------------------
+ORCL_DATA1/orcl/datafile/undotbs2.304.667323685
+ORCL_DATA1/orcl/datafile/users.305.667323705
+ORCL_DATA1/orcl/datafile/xmldb.306.667323705
+ORCL_DATA1/orcl/onlinelog/group_1.296.667323473
+ORCL_DATA1/orcl/onlinelog/group_2.297.667323489
+ORCL_DATA1/orcl/onlinelog/group_3.307.667336051
+ORCL_DATA1/orcl/onlinelog/group_4.308.667336067
+ORCL_DATA1/orcl/tempfile/temp.301.667323579

19行が選択されました。

SQL> 

あとは問題はないだろうね。次回へつづく。

Mac de Oracle - １０万円未満 de RAC (11g編）#24

今回はOracle Net Serviceの確認

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１、その２、その３
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成　その１、その２、その３
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）☆項番１９．で確認してしまったので削除

---

１９．Oracle Net Serviceの確認

まずRAC側のtnsnames.oraの内容確認から。ORCL2以下の内容をMacOSXのOracle Instant Client 10g R1のtnsnames.oraへコピーする。

[oracle@discus1 ˜]$ cat $TNS_ADMIN/tnsnames.ora
# tnsnames.ora Network Configuration File: /u01/app/oracle/product/11.1.0/db_1/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.

LISTENERS_ORCL =
  (ADDRESS_LIST =
    (ADDRESS = (PROTOCOL = TCP)(HOST = discus1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = discus2-vip)(PORT = 1521))
  )

ORCL2 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = discus2-vip)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl.macdeoracle.info)
      (INSTANCE_NAME = orcl2)
    )
  )

ORCL1 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = discus1-vip)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl.macdeoracle.info)
      (INSTANCE_NAME = orcl1)
    )
  )

ORCL =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = discus1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = discus2-vip)(PORT = 1521))
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl.macdeoracle.info)
    )
  )

[oracle@discus1 ˜]$ 

コピー内容を確認。

G5Server:˜ discus$ tail -31 $TNS_ADMIN/tnsnames.ora
ORCL2 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = discus2-vip)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl.macdeoracle.info)
      (INSTANCE_NAME = orcl2)
    )
  )

ORCL1 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = discus1-vip)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl.macdeoracle.info)
      (INSTANCE_NAME = orcl1)
    )
  )

ORCL =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = discus1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = discus2-vip)(PORT = 1521))
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl.macdeoracle.info)
    )
  )

G5Server:˜ discus$ 

次にOracle Instant Client 10g R1 for MacOSX(PPC)から接続テストを行う。

G5Server:˜ discus$ sqlplus -version

SQL*Plus: Release 10.1.0.3.0 - Production

G5Server:˜ discus$ sqlplus /nolog

SQL*Plus: Release 10.1.0.3.0 - Production on 日 10月 19 10:37:35 2008

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

> !sw_vers
ProductName:    Mac OS X Server
ProductVersion: 10.4.11
BuildVersion:   8S169

> !/usr/sbin/system_profiler SPHardwareDataType SPSoftwareDataType | grep -E '((System|Kernel) Version|CPU)'
      CPU Type: PowerPC G5  (3.1)
      Number Of CPUs: 2
      CPU Speed: 2.7 GHz
      L2 Cache (per CPU): 512 KB
      System Version: Mac OS X Server 10.4.11 (8S169)
      Kernel Version: Darwin 8.11.0

> 
> conn sys@orcl1 as sysdba
パスワードを入力してください: 
接続されました。
SYS> select instance_name from v$instance;

INSTANCE_NAME
----------------
orcl1

SYS> conn sys@orcl2 as sysdba
パスワードを入力してください: 
接続されました。
SYS> select instance_name from v$instance;

INSTANCE_NAME
----------------
orcl2

SYS> conn sys@orcl as sysdba
パスワードを入力してください: 
接続されました。
SYS> select instance_name from v$instance;

INSTANCE_NAME
----------------
orcl1

SYS> conn sys@orcl as sysdba
パスワードを入力してください: 
接続されました。
SYS>: --ロードバランシングされて次はorcl2へ繋がるだろうな・・・・・多分。
SYS> select instance_name from v$instance;

INSTANCE_NAME
----------------
orcl2

SYS> -- gv$instanceビューでracの全インスタンスのチェック
SYS> select
  2    inst_id
  3   ,instance_number
  4   ,instance_name
  5   ,host_name
  6   ,version
  7   ,status
  8   ,parallel
  9  from
 10    gv$instance;

   INST_ID INSTANCE_NUMBER INSTANCE_NAME    HOST_NAME                VERSION           STATUS       PAR
---------- --------------- ---------------- ------------------------ ----------------- ------------ ---
         1               1 orcl1            discus1.macdeoracle.jp   11.1.0.6.0        OPEN         YES
         2               2 orcl2            discus2.macdeoracle.jp   11.1.0.6.0        OPEN         YES

SYS> 
SYS> 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 Linux: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production

SYS> 

同様にintel x86版のMacOSXからも接続確認(^^)。intel x86 mac向けにはOracle Instant Client 10g R2が利用できる。もちろんOracle Instant Client 10g R1(PPC)をRosetta上で動作させてもOKだが。。

Macintosh:˜ discus$ sqlplus -version

SQL*Plus: Release 10.2.0.4.0 - Production

Macintosh:˜ discus$ sqlplus /nolog
¥
SQL*Plus: Release 10.2.0.4.0 - Production on 日 10月 19 11:31:45 2008

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

SQL> !sw_vers
ProductName:	Mac OS X
ProductVersion:	10.5.5
BuildVersion:	9F33

SQL> !/usr/sbin/system_profiler SPHardwareDataType SPSoftwareDataType | grep -E '((System|Kernel) Version|Processor (Name|Speed))'
      Processor Name: Intel Core 2 Duo
      Processor Speed: 2.2 GHz
      System Version: Mac OS X 10.5.5 (9F33)
      Kernel Version: Darwin 9.5.0

SQL> conn sys@orcl as sysdba
Enter password: 
Connected.
SQL> select
  2    instance_number
  3   ,instance_name
  4   ,status
  5   ,version
  6  from
  7   gv$instance;

INSTANCE_NUMBER INSTANCE_NAME	 STATUS       VERSION
--------------- ---------------- ------------ -----------------
	      2 orcl2		 OPEN	      11.1.0.6.0
	      1 orcl1		 OPEN	      11.1.0.6.0

SQL>

Yahoo! 上手く行ったね〜。Oracle11g R1でお遊びRAC環境を構築するにも物理メモリ１ＧＢは載せないとダメね。ということで次回へつづく

追記(2008/10/19)
しまった〜、一番最後に行う予定だったMacOSXのOracle Clientからの接続テストをやっちゃった。w
しかたないので項番２４．は削除しておくか。。(^^;;

Mac de Oracle - １０万円未満 de RAC (11g編）#23

今回はOracle Cluster databaseの作成 その３

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１、その２、その３
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成　その１、その２、その３
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

１８．Oracle Cluster databaseの作成 その３

Cluster Database作成再々チャレンジ。３度目の正直ということで今度は大丈夫。w

iLifeで作成、BGMはGarage Bandのループの組み合わせだけで作成したものをYouTubeへ。。
高画質版はこちらから

ふ〜、上手く行った。(^^。次回へつづく

Mac de Oracle - １０万円未満 de RAC (11g編）#22

今回はOracle Cluster databaseの作成 その２

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１、その２、その３
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成　その１、その２
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

１８．Oracle Cluster databaseの作成 その２

さて、前回「ORA-00845: MEMORY_TARGET no support on this system」という既知の落とし穴に落ちてしまったがなんとか脱出、dbcaにて中途半端な状態のデータベースを削除後、Cluster databaseの作成を再開。
今回はASMの作成はすんなりできたものの・・・・こんどこそ物理メモリ５１２ＭＢという最低限必要とされていた物理メモリサイズの半分ではRAC+ASMのインストールは無理だ・・・という結論に。・・・。
以前シングルインスタンスのOracle11g R1 EEを物理メモリ７６８ＭＢのDynabookにインストールした経験からギリギリなんとかなるかもと思っていたが、５１２ＭＢでは無理でしたね、さすがに．．．。www

順調に見えたが上記の画面でステータスが全く進まなくなった（そのように見えるがハングしている訳ではない）。原因はORA-04031が連発、バッググラウンドプロセスもまともに動けずエラー終了と再起動を繰り返している様子がalert.logファイルから確認できた。
ということで各５１２ＭＢのメモリを追加しRAC全ノードの物理メモリを１ＧＢに。
カーネルパラメータshmmax調整後、dbcaにて中途半端な状態のデータベースを削除してからcluster database作成を再開。。結果は次回。。。(^^)

[root@discus1 ˜]# cat /proc/meminfo | grep MemTotal
MemTotal:      1033760 kB
[root@discus1 ˜]# 
[root@discus1 ˜]# sysctl -a | grep shmmax
kernel.shmmax = 536870912
[root@discus1 ˜]# 

ちなみにOracleの初期化パラメータsga_max_size/memory_max_target/memory_targetは各400M程度に設定する

Cluster Databaseの作成はまだつづく・・・・・・・。

Mac de Oracle - １０万円未満 de RAC (11g編）#21

今回はOracle Cluster databaseの作成 その１

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１、その２、その３
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成　その１
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

１８．Oracle Cluster databaseの作成 その１

まず、dbca実行事前チェック。
CentOSで実行出来るよう構成ファイルをカスタマイズしたCVUを利用する。尚、事前にsshのユーザ等価関係を有効にしておくこと。（RACを構成する１ノードから実行する。）

[oracle@discus1 ˜]$ cd /home/oracle/orainstall/clusterware
[oracle@discus1 clusterware]$ ./bin/cluvfy stage -pre dbcfg -n discus1,discus2 -d ${ORACLE_HOME} -verbose

データベース構成の事前チェックを実行しています 

ノード到達可能性をチェック中...

チェック: ノード"discus1"からのノード到達可能性
  宛先ノード                                 到達可能ですか                 
  ------------------------------------  ------------------------
  discus1                               はい                      
  discus2                               はい                      
結果: ノード"discus1"からのノード到達可能性チェックに合格しました。


ユーザー等価をチェック中...

チェック: ユーザー"oracle"のユーザー等価
  ノード名                                  コメント                    
  ------------------------------------  ------------------------
  discus2                               合格                      
  discus1                               合格                      
結果: ユーザー"oracle"のユーザー等価チェックに合格しました。

管理権限をチェック中...

・・・・中略・・・・

チェック: サブネット"192.168.1.0"のノード接続性
  ソース                             宛先                              接続しましたか         
  ------------------------------  ------------------------------  ----------------
  discus2:eth0                    discus2:eth0                    はい              
  discus2:eth0                    discus1:eth0                    はい              
  discus2:eth0                    discus1:eth0                    はい              
  discus2:eth0                    discus1:eth0                    はい              
  discus2:eth0                    discus1:eth0                    はい              
  discus1:eth0                    discus1:eth0                    はい              
結果: ノードdiscus2,discus1を持つサブネット"192.168.1.0"のノード接続性チェックに合格しました。

チェック: サブネット"192.168.2.0"のノード接続性
  ソース                             宛先                              接続しましたか         
  ------------------------------  ------------------------------  ----------------
  discus2:eth1                    discus1:eth1                    はい              
結果: ノードdiscus2,discus1を持つサブネット"192.168.2.0"のノード接続性チェックに合格しました。

インタフェースがVIPの候補となるサブネット"192.168.1.0"で見つかりました:
discus2 eth0:192.168.1.4 eth0:192.168.1.101
discus1 eth0:192.168.1.3 eth0:192.168.1.100

インタフェースがプライベート・インタコネクトの候補となるサブネット"192.168.2.0"で見つかりました:
discus2 eth1:192.168.2.4
discus1 eth1:192.168.2.3

・・・・中略・・・・

CRS状態をチェック中...

チェック: CRSの状態
  ノード名                                  CRS OK?                 
  ------------------------------------  ------------------------
  discus2                               はい                      
  discus1                               はい                      
結果: CRS状態チェックに合格しました。

CRS整合性チェックに合格しました。

データベース構成の事前チェックは成功しました。 
[oracle@discus1 clusterware]$ 

チェックOKなので、dbcaを起動しCluster database作成を作成する。
今回もMacOSXのxterm(X11)から行う。尚、sshのユーザ等価関係が有効になっていない場合は有効化しておくこと。

G5Server:˜ discus$ ssh -Y oracle@discus1
oracle@discus1's password: 
[oracle@discus1 ˜]$ 
[oracle@discus1 ˜]$ exec /usr/bin/ssh-agent $SHELL
[oracle@discus1 ˜]$ /usr/bin/ssh-add
Enter passphrase for /home/oracle/.ssh/id_rsa:
 Identity added: /home/oracle/.ssh/id_rsa (/home/oracle/.ssh/id_rsa)
[oracle@discus1 ˜]$ 
[oracle@discus1 ˜]$ ssh discus1 hostname
discus1.macdeoracle.jp
[oracle@discus1 ˜]$ ssh discus2 hostname
discus2.macdeoracle.jp
[oracle@discus1 ˜]$ 
[oracle@discus1 ˜]$ dbca &

・・・中略・・・

あ〜〜〜〜、ダメか？、物理メモリ５１２ＭＢでは・・・無理しているのは承知だが．．？？　ASMインスタンスを作成しようとしているところで以下のエラーが出て進む事ができない。。。ここまでか・・・。

ORA-00845: MEMORY_TARGET no support on this system

諦めずにログから調査していくと．．．ありました・・・既知の問題が・・・

どうやらtmpfsを大きく取ってやることで回避できるようだ。。以下のマニュアルを参照のこと。
Oracle Clusterware Installation Guide11g Release 1 (11.1) for Linux
- MEMORY_TARGET not supported on this system

なんとか回避できそうだな・・・ということで、早速tmpfsのサイズを増す。。

Connection to discus1 closed.
G5Server:˜ discus$ ssh root@discus1
root@discus1's password: 
Last login: Sat Oct  4 04:08:21 2008 from 192.168.1.19
[root@discus1 ˜]# df -a
Filesystem           1K-ブロック    使用   使用可 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
                      16790968  11316644   4607612  72% /
proc                         0         0         0   -  /proc
sysfs                        0         0         0   -  /sys
devpts                       0         0         0   -  /dev/pts
/dev/hda1               101086     11816     84051  13% /boot
tmpfs                   256984         0    256984   0% /dev/shm
none                         0         0         0   -  /proc/sys/fs/binfmt_misc
sunrpc                       0         0         0   -  /var/lib/nfs/rpc_pipefs
configfs                     0         0         0   -  /sys/kernel/config
ocfs2_dlmfs                  0         0         0   -  /dlm
/dev/sdc1              2095648    335520   1760128  17% /u02
oracleasmfs                  0         0         0   -  /dev/oracleasm
[root@discus1 ˜]# umount tmpfs

[root@discus1 ˜]# mount -t tmpfs shmfs -o size=2g /dev/shm
[root@discus1 ˜]# df -a
Filesystem           1K-ブロック    使用   使用可 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
                      16790968  11316648   4607608  72% /
proc                         0         0         0   -  /proc
sysfs                        0         0         0   -  /sys
devpts                       0         0         0   -  /dev/pts
/dev/hda1               101086     11816     84051  13% /boot
none                         0         0         0   -  /proc/sys/fs/binfmt_misc
sunrpc                       0         0         0   -  /var/lib/nfs/rpc_pipefs
configfs                     0         0         0   -  /sys/kernel/config
ocfs2_dlmfs                  0         0         0   -  /dlm
/dev/sdc1              2095648    335520   1760128  17% /u02
oracleasmfs                  0         0         0   -  /dev/oracleasm
shmfs                  2097152         0   2097152   0% /dev/shm
[root@discus1 ˜]# 
[root@discus1 ˜]# cat /etc/fstab
/dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0
LABEL=oracrsfiles       /u02                    ocfs2   _netdev,datavolume,nointr       0 0
shmfs                   /dev/shm                tmpfs   size=2g 0
[root@discus1 ˜]# 

・・・・・一旦再起動・・・・・

[root@discus1 ˜]# df -ah
Filesystem          サイズ  使用  残り 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
                       17G   11G  4.4G  72% /
proc                     0     0     0   -  /proc
sysfs                    0     0     0   -  /sys
devpts                   0     0     0   -  /dev/pts
/dev/hda1              99M   12M   83M  13% /boot
tmpfs                 2.0G     0  2.0G   0% /dev/shm
shmfs                 2.0G     0  2.0G   0% /dev/shm
none                     0     0     0   -  /proc/sys/fs/binfmt_misc
sunrpc                   0     0     0   -  /var/lib/nfs/rpc_pipefs
configfs                 0     0     0   -  /sys/kernel/config
ocfs2_dlmfs              0     0     0   -  /dlm
/dev/sdd1             2.0G  328M  1.7G  17% /u02
oracleasmfs              0     0     0   -  /dev/oracleasm
[root@discus1 ˜]# 

注）上記操作はRAC全ノードのrootユーザで行った

Cluster Databaseの作成は次回へつづく・・・・・・・。

Mac de Oracle - １０万円未満 de RAC (11g編）#20

今回はTNS Listenerの構成

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１、その２、その３
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

１７．TNS Listenerの構成

netcaでの構成はRACの１ノードから実行する。
netcaもMacOSXのxterm(X11)から行う。尚、sshのユーザ等価関係が有効になっていない場合は有効化しておくこと。

G5Server:˜ discus$ ssh -Y oracle@discus1
oracle@discus1's password: 
[oracle@discus1 ˜]$ 
[oracle@discus1 ˜]$ exec /usr/bin/ssh-agent $SHELL
[oracle@discus1 ˜]$ /usr/bin/ssh-add
Enter passphrase for /home/oracle/.ssh/id_rsa:
 Identity added: /home/oracle/.ssh/id_rsa (/home/oracle/.ssh/id_rsa)
[oracle@discus1 ˜]$ 
[oracle@discus1 ˜]$ ssh discus1 hostname
discus1.macdeoracle.jp
[oracle@discus1 ˜]$ ssh discus2 hostname
discus2.macdeoracle.jp
[oracle@discus1 ˜]$ 
[oracle@discus1 ˜]$ netca &

・・・中略・・・

久々にMovie化、iLifeで作成、BGMはGarage Bandのループの組み合わせだけで作成したものをYouTubeへ。。
高画質版はこちらから

確認はRAC全ノードのoracleユーザで実施する。（以下はdiscus1で実施した例）

[oracle@discus1 ˜]$ hostname
discus1.macdeoracle.jp
[oracle@discus1 ˜]$ ps -ef | grep lsnr | grep -v 'grep' | grep -v 'ocfs' | awk '{print $9}'
LISTENER_DISCUS1
[oracle@discus1 ˜]$ $ORA_CRS_HOME/bin/crs_stat ora.discus1.LISTENER_DISCUS1.lsnr
NAME=ora.discus1.LISTENER_DISCUS1.lsnr
TYPE=application
TARGET=ONLINE
STATE=ONLINE on discus1

[oracle@discus1 ˜]$ 

次回へつづく

Mac de Oracle - １０万円未満 de RAC (11g編）#19

今回はOracle11g R1 examplesのインストール

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１、その２、その３
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

１６．Oracle11g R1 examplesのインストール

OUIによるインストールはRACの１ノードから実行する。
Oracle11g R1 exapmlesのインストールもMacOSXのxterm(X11)からOUIを起動して行う。尚、sshのユーザ等価関係が有効になっていない場合は有効化しておくこと。

G5Server:~ discus$ ssh -Y oracle@discus1
oracle@discus1's password: 
[oracle@discus1 ˜]$ cd /home/oracle/orainstall/examples
[oracle@discus1 examples]$ 
[oracle@discus1 examples]$ exec /usr/bin/ssh-agent $SHELL
[oracle@discus1 examples]$ /usr/bin/ssh-add
Enter passphrase for /home/oracle/.ssh/id_rsa:
 Identity added: /home/oracle/.ssh/id_rsa (/home/oracle/.ssh/id_rsa)
[oracle@discus1 examples]$ 
[oracle@discus1 examples]$ ssh discus1 hostname
discus1.macdeoracle.jp
[oracle@discus1 examples]$ ssh discus2 hostname
discus2.macdeoracle.jp
[oracle@discus1 examples]$ 
[oracle@discus1 examples]$ ./runInstaller &

・・・中略・・・

Copyright (C) 1999, 2007, Oracle. All rights reserved.

MacOSXのxtermからOUIを起動した場合、xterm上のログは文字化けするが起動されるOUIは文字化けしないので特に困ることもない。

久々にMovie化、iLifeで作成、BGMはGarage Bandのループの組み合わせだけで作成したものをYouTubeへ。。

高画質版はこちらからどうぞ。

尚、他のインストールと同様にOUIが実行するCVUでは物理メモリチェック失敗となるが物理メモリ５１２MBで実行している影響なので無視して続行する。

次回へつづく

Mac de Oracle - １０万円未満 de RAC (11g編）#18

今回はOracle11g R1 Database softwareのインストール

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１、その２、その３
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

１５．Oracle11g R1 Database softwareのインストール（ソフトウェアのみインストール）

Oracle databaseインストール事前チェックを手動実行する。CentOS向けに構成ファイルを変更したCVUで行う。物理メモリ及び物理メモリ（５１２ＭＢ）に合わせたカーネルパラメータshmmaxのチェックに失敗するが想定内のことなのでそれ以外のチェック失敗がなければインストールが行える。尚、チェック実施前にsshのユーザ等価関係は有効にしておくこと。

[oracle@discus1 &tilde]$ cd clusterware
[oracle@discus1 clusterware]$ ./bin/cluvfy stage -pre dbinst -n discus1,discus2 -r 11gR1 -verbose

データベース・インストールの事前チェックを実行しています 

ノード到達可能性をチェック中...

チェック: ノード"discus1"からのノード到達可能性
  宛先ノード                                 到達可能ですか                 
  ------------------------------------  ------------------------
  discus1                               はい                      
  discus2                               はい                      
結果: ノード"discus1"からのノード到達可能性チェックに合格しました。


ユーザー等価をチェック中...

チェック: ユーザー"oracle"のユーザー等価
  ノード名                                  コメント                    
  ------------------------------------  ------------------------
  discus2                               合格                      
  discus1                               合格                      
結果: ユーザー"oracle"のユーザー等価チェックに合格しました。

・・・中略・・・

システム要件をチェック中: 'database'...

チェック: メモリー合計 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus2       501.92MB (513968KB)       1GB (1048576KB)           失敗
  discus1       501.92MB (513968KB)       1GB (1048576KB)           失敗        
結果: メモリー合計チェックが失敗しました。

チェック: "/tmp"ディレクトリのディスク空き領域
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus2       10.5GB (11012728KB)       400MB (409600KB)          合格        
  discus1       8.01GB (8396028KB)        400MB (409600KB)          合格        
結果: ディスク空き領域チェックに合格しました。

チェック: スワップ領域 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus2       2GB (2097144KB)           1.5GB (1572864KB)         合格        
  discus1       2GB (2097144KB)           1.5GB (1572864KB)         合格        
結果: スワップ領域チェックに合格しました。

・・・中略・・・

チェック: "shmmax"のカーネル・パラメータ 
  ノード名          構成済                       必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus2       268435456                 536870912                 失敗        
  discus1       268435456                 536870912                 失敗        
結果: "shmmax"のカーネル・パラメータチェックが失敗しました。

チェック: "shmall"のカーネル・パラメータ 
  ノード名          構成済                       必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus2       2097152                   2097152                   合格        
  discus1       2097152                   2097152                   合格        
結果: "shmall"のカーネル・パラメータチェックに合格しました。


・・・中略・・・

チェック: CRSの状態
  ノード名                                  CRS OK?                 
  ------------------------------------  ------------------------
  discus2                               はい                      
  discus1                               はい                      
結果: CRS状態チェックに合格しました。

CRS整合性チェックに合格しました。

データベース・インストールの事前チェックはすべてのノードで失敗しました。 
[oracle@discus1 clusterware]$ 

物理メモリとshmmaxのチェックが失敗しているが、実メモリが少ないことによる影響なので無視して作業を進める。５１２ＢＭの物理メモリでどこまでいけるか・・・
尚、OUI内のチェックでも同じポイントでチェックが失敗するが同じ問題なので無視してインストールを続ける。(^^)

OUIによるインストールはRACの１ノードから実行する。
Oracle databaseのインストールもMacOSXのxterm(X11)からOUIを起動して行う。尚、sshのユーザ等価関係が有効になっていない場合は有効化しておくこと。

G5Server:~ discus$ ssh -Y oracle@discus1
oracle@discus1's password: 
[oracle@discus1 ˜]$ cd /home/oracle/orainstall/database
[oracle@discus1 database]$ 
[oracle@discus1 database]$ exec /usr/bin/ssh-agent $SHELL
[oracle@discus1 database]$ /usr/bin/ssh-add
Enter passphrase for /home/oracle/.ssh/id_rsa:
 Identity added: /home/oracle/.ssh/id_rsa (/home/oracle/.ssh/id_rsa)
[oracle@discus1 database]$ 
[oracle@discus1 database]$ ssh discus1 hostname
discus1.macdeoracle.jp
[oracle@discus1 database]$ ssh discus2 hostname
discus2.macdeoracle.jp
[oracle@discus1 database]$ 
[oracle@discus1 database]$ ./runInstaller &

・・・中略・・・

Copyright (C) 1999, 2007, Oracle. All rights reserved.

MacOSXのxterm上では文字化けするがOUI自体は文字化けしないのでご心配なく。

インストールの最後でのお約束！　root.shの実行。RAC全ノードのrootユーザで実施後、OUIに戻りダイアログを閉じる。

[root@discus1 ~]# /u01/app/oracle/product/11.1.0/db_1/root.sh
Running Oracle 11g root.sh script...

The following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /u01/app/oracle/product/11.1.0/db_1

Enter the full pathname of the local bin directory: [/usr/local/bin]: 
   Copying dbhome to /usr/local/bin ...
   Copying oraenv to /usr/local/bin ...
   Copying coraenv to /usr/local/bin ...


Creating /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.
Finished product-specif

次回へつづく

Mac de Oracle - １０万円未満 de RAC (11g編）#17

今回はOracle11g R1 Clusterwareのインストール

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１、その２、その３
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

１４．Oracle11g R1 Clusterwareのインストール

ということでやっとインストール作業。まずはOracle Clusterwareのインストール。OUIによるインストールはRACの１ノードから実行する。
今回もMacOSXのxterm(X11)でOUIを起動する。

G5Server:~ discus$ ssh -Y oracle@discus1
oracle@discus1's password: 
[oracle@discus1 ˜]$ cd /home/oracle/orainstall/clusterware
[oracle@discus1 clusterware]$ 
[oracle@discus1 clusterware]$ exec /usr/bin/ssh-agent $SHELL
[oracle@discus1 clusterware]$ /usr/bin/ssh-add
Enter passphrase for /home/oracle/.ssh/id_rsa:
 Identity added: /home/oracle/.ssh/id_rsa (/home/oracle/.ssh/id_rsa)
[oracle@discus1 clusterware]$ 
[oracle@discus1 clusterware]$ ssh discus1 hostname
discus1.macdeoracle.jp
[oracle@discus1 clusterware]$ ssh discus2 hostname
discus2.macdeoracle.jp
[oracle@discus1 clusterware]$ 
[oracle@discus1 clusterware]$ ./runInstaller &

・・・中略・・・

Copyright (C) 1999, 2007, Oracle. All rights reserved.

MacOSXのxterm上では文字化けするがOUI自体は文字化けしないのでご心配なく。

お約束のorainstRoot.sh及びroot.shスクリプトはRAC全ノードのrootユーザで実行する。

[root@discus1 ˜]# /u01/app/oraInventory/orainstRoot.sh
権限の変更:/u01/app/oraInventory : 770.
グループ名の変更:/u01/app/oraInventory : oinstall.
スクリプトの実行が完了しました
[root@discus1 ˜]# /u01/app/crs/root.sh
WARNING: directory '/u01/app' is not owned by root
Checking to see if Oracle CRS stack is already configured
/etc/oracle does not exist. Creating it now.

Setting the permissions on OCR backup directory
Setting up Network socket directories
Oracle Cluster Registry configuration upgraded successfully
The directory '/u01/app' is not owned by root. Changing owner to root
Successfully accumulated necessary OCR keys.
Using ports: CSS=49895 CRS=49896 EVMC=49898 and EVMR=49897.
node <nodenumber>: <nodename> <private interconnect name> <hostname>
node 1: discus1 discus1-priv discus1
node 2: discus2 discus2-priv discus2
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
Now formatting voting device: /u02/oradata/orcl/CSSFile
Now formatting voting device: /u02/oradata/orcl/CSSFile_mirror1
Now formatting voting device: /u02/oradata/orcl/CSSFile_mirror2
Format of 3 voting devices complete.
Startup will be queued to init within 30 seconds.
Adding daemons to inittab
Expecting the CRS daemons to be up within 600 seconds.
Cluster Synchronization Services is active on these nodes. 
        discus1
Cluster Synchronization Services is inactive on these nodes. 
        discus2
Local node checking complete. Run root.sh on remaining nodes to start CRS daemons.
[root@discus1 ˜]# ssh root@discus2
root@discus1's password: 
[root@discus2 ˜]# /u01/app/oraInventory/orainstRoot.sh
権限の変更:/u01/app/oraInventory : 770.
グループ名の変更:/u01/app/oraInventory : oinstall.
スクリプトの実行が完了しました
[root@discus2 ˜]# /u01/app/crs/root.sh
WARNING: directory '/u01/app' is not owned by root
Checking to see if Oracle CRS stack is already configured
/etc/oracle does not exist. Creating it now.

・・・．中略・・・・

        discus1
        discus2
Cluster Synchronization Services is active on all the nodes. 
Waiting for the Oracle CRSD and EVMD to start
Oracle CRS stack installed and running under init(1M)
Running vipca(silent) for configuring nodeapps

(2)ノードでVIPアプリケーション・リソースを作成しています...
(2)ノードでGSDアプリケーション・リソースを作成しています...
(2)ノードでONSアプリケーション・リソースを作成しています...
(2)ノードでVIPアプリケーション・リソースを起動しています...
(2)ノードでGSDアプリケーション・リソースを起動しています...
(2)ノードでONSアプリケーション・リソースを起動しています...


Done.
[root@discus2 ˜]# 

OUIの最後のCVUでエラーが発生するが既知の問題(CentOS5.2がサポートされていないから）なので無視してOUIを進め、OTN USから別途ダウンロードしCentOS5でも実行できるようカスタマイズしたCVUをOUIを起動したノードで実行し正常であることの確認が取れればOK。
以下はOUIのログ。

-----------------------------------------------------------------------------
コンフィギュレーション・アシスタント"Oracle Cluster Verification Utility"から生成された出力:
Command = /u01/app/crs/bin/cluvfy stage -post crsinst -n discus1,discus2

ERROR: 
オペレーティング・システムを識別できません。このオペレーティング・システムに対して正しいソフトウェアが実行中であることを確認してください。
検証を続行できません。


コンフィギュレーション・アシスタント"Oracle Cluster Verification Utility"が失敗しました。
-----------------------------------------------------------------------------
"/u01/app/crs/cfgtoollogs/configToolFailedCommands"スクリプトには、失敗したコマンド、スキップされたコマンド、または取り消されたコマンドがすべて含まれています。
このファイルは、OUI以外でコンフィギュレーション・アシスタントを実行するために使用される場合があります。このスクリプトを実行する前に、
(存在する場合は)パスワードを使用してスクリプトを更新する必要がある場合があります。
-----------------------------------------------------------------------------

[oracle@discus1 clusterware]$ ./bin/cluvfy stage -post crsinst -n discus1,discus2 -verbose

クラスタ・サービス設定の事後チェックを実行しています 

ノード到達可能性をチェック中...

チェック: ノード"discus1"からのノード到達可能性
  宛先ノード                                 到達可能ですか                 
  ------------------------------------  ------------------------
  discus1                               はい                      
  discus2                               はい                      
結果: ノード"discus1"からのノード到達可能性チェックに合格しました。


ユーザー等価をチェック中...

チェック: ユーザー"oracle"のユーザー等価
  ノード名                                  コメント                    
  ------------------------------------  ------------------------
  discus2                               合格                      
  discus1                               合格                      
結果: ユーザー"oracle"のユーザー等価チェックに合格しました。

クラスタ・マネージャ整合性をチェック中... 


CSSデーモンをチェック中...
  ノード名                                  ステータス                   
  ------------------------------------  ------------------------
  discus2                               実行中                     
  discus1                               実行中                     
結果: "CSS daemon"のデーモン・ステータスチェックに合格しました。

クラスタ・マネージャ整合性チェックに合格しました。

クラスタ整合性をチェック中... 

  ノード名                                
  ------------------------------------
  discus1                             
  discus2                             

クラスタ整合性チェックに合格しました


OCR整合性をチェック中...

非クラスタ構成がないことをチェック中...
すべてのノードにローカル専用の非クラスタ構成がありません。

OCRデバイスの一意性チェックに合格しました。

OCRのバージョンをチェック中...
OCRの正しいバージョン"2"が存在します。

OCRのデータ整合性をチェック中...
OCRのデータ整合性チェックに合格しました。

OCR整合性チェックに合格しました。

CRS整合性をチェック中...

デーモン活性をチェック中...

チェック: "CRS daemon"の活性

・・・・中略・・・・

GSDノード・アプリケーションの存在をチェック中です 
  ノード名          必須                        ステータス                     コメント      
  ------------  ------------------------  ------------------------  ----------
  discus2       いいえ                       存在します                     合格     
     discus1       いいえ                       存在します                     合格        
結果: チェックに合格しました。


クラスタ・サービス設定の事後チェックは成功しました。 
[oracle@discus1 clusterware]$ 

最後に全ノードのOracleユーザで以下の確認を行ってOracle clusterwareのインストールは終了。

[oracle@discus1 ˜]$ $ORA_CRS_HOME/bin/olsnodes -n
discus1 1
discus2 2
[oracle@discus1 ˜]$ $ORA_CRS_HOME/bin/crs_stat -t -v
Name           Type           R/RA   F/FT   Target    State     Host        
----------------------------------------------------------------------
ora....us1.gsd application    0/5    0/0    ONLINE    ONLINE    discus1
ora....us1.ons application    0/3    0/0    ONLINE    ONLINE    discus1     
ora....us1.vip application    0/0    0/0    ONLINE    ONLINE    discus1     
ora....us2.gsd application    0/5    0/0    ONLINE    ONLINE    discus2     
ora....us2.ons application    0/3    0/0    ONLINE    ONLINE    discus2     
ora....us2.vip application    0/0    0/0    ONLINE    ONLINE    discus2     
[oracle@discus1 ˜]$ $ORA_CRS_HOME/bin/crsctl check crs
Cluster Synchronization Services appears healthy
Cluster Ready Services appears healthy
Event Manager appears healthy
[oracle@discus1 ˜]$ ls -l /etc/init.d/init.*
-rwxr-xr-x 1 root root  2236 10月  2 21:43 /etc/init.d/init.crs
-rwxr-xr-x 1 root root  5290 10月  2 21:43 /etc/init.d/init.crsd
-rwxr-xr-x 1 root root 49416 10月  2 21:43 /etc/init.d/init.cssd
-rwxr-xr-x 1 root root  3859 10月  2 21:43 /etc/init.d/init.evmd
[oracle@discus1 ˜]$ 

次回へつづく

Mac de Oracle - １０万円未満 de RAC (11g編）#16

今回はOracle11g R1 インストール事前作業

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１、その２、その３
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

１３．Oracle11g R1 インストール事前作業

インストールするOracle製品は、
linux_x86_11gR1_database.zip　/　linux_x86_11gR1_clusterware.zip　/　linux_11gR1_examples.zip

及び、cvupack_Linux_x86.zip

CVUのFAQ:
http://www.oracle.com/technology/products/database/clustering/cvu/faq/cvufaq_11g.htmlを参照のこと。

2008/10/16追記
尚、DVDを利用する場合はcvupack_Linux_x86.zipだけを別途ダウンロードし適当なディレクトリで解凍して利用する。DVDを利用する場合、OUIはDatabase/Clusterware/Oracle Clientを選択してインストールすることができるが、本エントリではOracle Database及び、Clusterwareは個々のOUIで個別にインストールしているためrunInstallerのディレクトリが異なっていることに注意してください。
ちなみに１枚のDVDに纏まられているOUIを起動した場合は以下のような画面が現れ、インストールする製品を選択できる。

インストールするOracle製品をダウンロードする。

インストールは１つのノードから行うのでRACを構成するいずれか１ノードへダウンロードすればOK。だたDISK容量はそれほど多くないのでunzipしたファイルはどんどん削除。（こちらの事情ですのでインストール上必須ではありません。こんなこと書かなくても大丈夫だと思いますが。）
ただし、cvuqdisk-1.0.1-1.rpmだけはRAC全ノードにダウンロードして個別にインストールする。

[root@discus1 ˜]# su - oracle
[oracle@discus1 ˜]$ mkdir orainstall
[oracle@discus1 ˜]$ cd orainstall
[oracle@discus1 orainstall]$ pwd
/home/oracle/orainstall
[oracle@discus1 orainstall]$ ll
合計 2524844
-rw-r--r-- 1 oracle oinstall   36428926 10月  1 21:12 cvupack_Linux_x86.zip
-rw-r--r-- 1 oracle oinstall  457209469 10月  1 21:41 linux_11gR1_examples.zip
-rw-r--r-- 1 oracle oinstall  244660141 10月  1 21:20 linux_x86_11gR1_clusterware.zip
-rw-r--r-- 1 oracle oinstall 1844572234 10月  1 21:27 linux_x86_11gR1_database.zip
[oracle@discus1 orainstall]$ unzip linux_x86_11gR1_database.zip

・・・・中略・・・

[oracle@discus1 orainstall]$ rm linux_x86_11gR1_database.zip
[oracle@discus1 orainstall]$ unzip linux_11gR1_examples.zip

・・・・中略・・・

[oracle@discus1 orainstall]$ rm linux_11gR1_examples.zip
[oracle@discus1 orainstall]$unzip linux_x86_11gR1_clusterware.zip

・・・・中略・・・

[oracle@discus1 orainstall]$ rm linux_x86_11gR1_clusterware.zip
[oracle@discus1 orainstall]$ ll
合計 35644
drwxr-xr-x 8 oracle oinstall     4096  9月 19  2007 clusterware/
-rw-r--r-- 1 oracle oinstall 36428926 10月  1 21:12 cvupack_Linux_x86.zip
drwxr-xr-x 6 oracle oinstall     4096  9月 19  2007 database/
drwxr-xr-x 6 oracle oinstall     4096  8月  7  2007 examples/
[oracle@discus1 orainstall]$ mv cvupack_Linux_x86.zip ./clusterware
[oracle@discus1 orainstall]$ ll
合計 24
drwxr-xr-x 8 oracle oinstall 4096  9月 19  2007 clusterware/
drwxr-xr-x 6 oracle oinstall 4096  9月 19  2007 database/
drwxr-xr-x 6 oracle oinstall 4096  8月  7  2007 examples/
[oracle@discus1 orainstall]$ cd clusterware
[oracle@discus1 clusterware]$ unzip cvupack_Linux_x86.zip

・・・・中略・・・

  inflating: lib/libsrvm11.so        
replace rpm/cvuqdisk-1.0.1-1.rpm? [y]es, [n]o, [A]ll, [N]one, [r]ename: n
[oracle@discus1 clusterware]$ rm cvupack_Linux_x86.zip
[oracle@discus1 clusterware]$ ll
合計 112
drwxr-xr-x  2 oracle oinstall 4096  8月 19 15:34 bin/
drwxr-xr-x  6 oracle oinstall 4096  8月 19 15:34 cv/
drwxr-xr-x  8 oracle oinstall 4096  8月  7  2007 doc/
drwxr-xr-x  4 oracle oinstall 4096  8月  4  2007 install/
drwxr-xr-x  3 oracle oinstall 4096  8月 19 15:34 jdk/
drwxr-xr-x  2 oracle oinstall 4096  8月 19 15:34 jlib/
drwxr-xr-x  2 oracle oinstall 4096  8月 19 15:34 lib/
drwxr-xr-x  2 oracle oinstall 4096  9月 19  2007 response/
drwxr-xr-x  2 oracle oinstall 4096  8月  4  2007 rpm/
-rwxr-xr-x  1 oracle oinstall 2912  8月  4  2007 runInstaller*
-rwxr-xr-x  1 oracle oinstall 2990  8月  4  2007 runcluvfy.sh*
drwxr-xr-x 13 oracle oinstall 4096  8月  4  2007 stage/
drwxr-xr-x  2 oracle oinstall 4096  8月  4  2007 upgrade/
-rw-r--r--  1 oracle oinstall 3824  7月 13  2007 welcome.html

この例ではRACを構成するdiscus1で解凍したcvuqdisk-1.0.1-1.rpmを残りのノードへコピー後、全ノードで個別にインストールする。

[oracle@discus1 clusterware]$ cd rpm
[oracle@discus1 rpm]$ ll
合計 12
-rw-r--r-- 1 oracle oinstall 5339  8月  4  2007 cvuqdisk-1.0.1-1.rpm
[oracle@discus1 rpm]$ scp cvuqdisk-1.0.1-1.rpm discus2:/home/oracle/orainstall/clusterware/rpm
Enter passphrase for key '/home/oracle/.ssh/id_rsa': 
cvuqdisk-1.0.1-1.rpm                                                        100% 5339     5.2KB/s   00:00    
[oracle@discus1 rpm]$ 
[root@discus1 rpm]# export CVUQDISK_GRPP=oinstall
[root@discus1 rpm]# rpm -iv cvuqdisk-1.0.1-1.rpm
準備中...
cvuqdisk-1.0.1-1

今回利用するzipファイルを全て展開すると上記のようなdirectory構成になる。cvupack_Linux_x86.zipを利用する理由は、後続作業にてCentOS5.2上でCVUによる事前チェックが行えるようにすることが目的でcvu_configファイルのCV_ORACLE_RELEASEパラメータ及び、CV_ASSUME_DISTIDパラメータをカスタマイズするため。

CV_ORACLE_RELEASEパラメータはコメントアウトされているだけなので#を削除するだけ。
CV_ASSUME_DISTIDパラメータはCentOS5.2をRHEL5と思わせるためにRHEL5へ変更する。

前述の設定を怠ると．．．．

[oracle@discus1 clusterware]$ ./bin/cluvfy stage -pre crsinst -n discus1,discus2 -verbose

ERROR: 
オペレーティング・システムを識別できません。このオペレーティング・システムに対して正しいソフトウェアが実行中であることを確認してください。
検証を続行できません。

[oracle@discus1 clusterware]$

というエラーが発生するのでご注意を

[oracle@discus1 clusterware]$ cat ./cv/admin/cvu_config
# Configuration file for Cluster Verification Utility(CVU)
# Version: 011405
#
# NOTE:
# 1._ Any line without a '=' will be ignored
# 2._ Since the fallback option will look into the environment variables,
#     please have a component prefix(CV_) for each property to define a
#     namespace.
# 


#Default Oracle release(10gR1/10gR2/11gR1). If specified here, this release 
#will be assumed when -r option is not specified in the command line.
CV_ORACLE_RELEASE=11gR1

#Nodes for the cluster. If CRS home is not installed, this list will be 
#picked up when -n all is mentioned in the commandline argument.
#CV_NODE_ALL=

#if enabled, cvuqdisk rpm is required on all nodes on RedHat 3 or Redhat 4
CV_RAW_CHECK_ENABLED=TRUE

# Fallback to this distribution id
CV_ASSUME_DISTID=RHEL5

# Whether X-Windows check should be performed for user equivalence with SSH
#CV_XCHK_FOR_SSH_ENABLED=TRUE

# To override SSH location
#ORACLE_SRVM_REMOTESHELL=/usr/bin/ssh

# To override SCP location
#ORACLE_SRVM_REMOTECOPY=/usr/bin/scp

[oracle@discus1 clusterware]$ 

さ事前チェックを行う前にsshのユーザ等価は確認しておく。
ここでpasswordを要求されるようならユーザ等価関係が有効になっていないので再度設定するべし。

[oracle@discus1 clusterware]$ ssh discus1 hostname
discus1.macdeoracle.jp
[oracle@discus1 clusterware]$ ssh discus2 hostname
discus2.macdeoracle.jp
[oracle@discus1 clusterware]$ 

・CVUによるOracle Clusterware事前チェック（RACを構成する１ノードのoracleユーザで実施すればOK）

[oracle@discus1 clusterware]$ pwd
/home/oracle/orainstall/clusterware
[oracle@discus1 clusterware]$ ./bin/cluvfy stage -pre crsinst -n discus1,discus2 -verbose

クラスタ・サービス設定の事前チェックを実行しています 

ノード到達可能性をチェック中...

チェック: ノード"discus1"からのノード到達可能性
  宛先ノード                                 到達可能ですか                 
  ------------------------------------  ------------------------
  discus1                               はい                      
  discus2                               はい                      
結果: ノード"discus1"からのノード到達可能性チェックに合格しました。


ユーザー等価をチェック中...

チェック: ユーザー"oracle"のユーザー等価
  ノード名                                  コメント                    
  ------------------------------------  ------------------------
  discus2                               合格                      
  discus1                               合格                      
結果: ユーザー"oracle"のユーザー等価チェックに合格しました。

管理権限をチェック中...

チェック: ユーザー"oracle"の存在
  ノード名          ステータス                     ユーザーID                  
  ------------  ------------------------  ------------------------
  discus2       存在します                     601                     
  discus1       存在します                     601                     
結果: "oracle"のユーザーの存在チェックに合格しました。

チェック: グループ"oinstall"の存在
  ノード名          ステータス                     グループID                  
  ------------  ------------------------  ------------------------
  discus2       存在します                     601                     
  discus1       存在します                     601                     
結果: "oinstall"のグループの存在チェックに合格しました。

チェック: グループ"oinstall"内のユーザー"oracle"[プライマリ]のメンバーシップ
  ノード名              ユーザーが存在します    グループが存在します    グループ内のユーザー    プライマリ         コメント        
  ----------------  ------------  ------------  ------------  ------------  ------------
 discus2          はい           はい           はい           はい           合格          
 discus1          はい           はい           はい           はい           合格          
結果: グループ"oinstall"内のユーザー"oracle"[プライマリ]のメンバーシップ・チェックに合格しました。

管理権限チェックに合格しました。

ノード接続性をチェック中...


・・・・中略・・・・


システム要件をチェック中: 'crs'...

チェック: メモリー合計 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus2       501.92MB (513968KB)       1GB (1048576KB)           失敗        
  discus1       501.92MB (513968KB)       1GB (1048576KB)           失敗        
結果: メモリー合計チェックが失敗しました。

チェック: "/tmp"ディレクトリのディスク空き領域
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus2       11.2GB (11743644KB)       400MB (409600KB)          合格        
  discus1       8.56GB (8972272KB)        400MB (409600KB)          合格        
結果: ディスク空き領域チェックに合格しました。

チェック: スワップ領域 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus2       2GB (2097144KB)           1.5GB (1572864KB)         合格        
  discus1       2GB (2097144KB)           1.5GB (1572864KB)         合格        
結果: スワップ領域チェックに合格しました。

チェック: システム・アーキテクチャ 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus2       i686                      i686                      合格        
  discus1       i686                      i686                      合格        
結果: システム・アーキテクチャチェックに合格しました。

チェック: カーネル・バージョン 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus2       2.6.18-92.el5             2.6.9                     合格        
  discus1       2.6.18-92.el5             2.6.9                     合格        
結果: カーネル・バージョンチェックに合格しました。

・・・・中略・・・・

チェック: "glibc-headers-2.5-12"のパッケージの存在 
  ノード名                            ステータス                           コメント            
  ------------------------------  ------------------------------  ----------------
  discus2                         glibc-headers-2.5-24            合格              
  discus1                         glibc-headers-2.5-24            合格              
結果: "glibc-headers-2.5-12"のパッケージの存在チェックに合格しました。

チェック: "dba"のグループの存在 
  ノード名          ステータス                     グループID                  
  ------------  ------------------------  ------------------------
  discus2       存在します                     602                     
  discus1       存在します                     602                     
結果: "dba"のグループの存在チェックに合格しました。

チェック: "oinstall"のグループの存在 
  ノード名          ステータス                     グループID                  
  ------------  ------------------------  ------------------------
  discus2       存在します                     601                     
  discus1       存在します                     601                     
結果: "oinstall"のグループの存在チェックに合格しました。

チェック: "nobody"の既存ユーザー 
  ノード名          ステータス                     ユーザーID                  
  ------------  ------------------------  ------------------------
  discus2       存在します                     99                      
  discus1       存在します                     99                      
結果: "nobody"の既存ユーザーチェックに合格しました。

チェック: "オープン・ファイル・ディスクリプタ"のハード・リソース制限 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus2       65536                     65536                     合格        
  discus1       65536                     65536                     合格        
結果: "オープン・ファイル・ディスクリプタ"のハード・リソース制限チェックに合格しました。

チェック: "オープン・ファイル・ディスクリプタ"のソフト・リソース制限 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus2       1024                      1024                      合格        
  discus1       1024                      1024                      合格        
結果: "オープン・ファイル・ディスクリプタ"のソフト・リソース制限チェックに合格しました。

チェック: "最大ユーザー・プロセス"のハード・リソース制限 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus2       16384                     16384                     合格        
  discus1       16384                     16384                     合格        
結果: "最大ユーザー・プロセス"のハード・リソース制限チェックに合格しました。

チェック: "最大ユーザー・プロセス"のソフト・リソース制限 
  ノード名          使用可能                      必須                        コメント      
  ------------  ------------------------  ------------------------  ----------
  discus2       2047                      2047                      合格        
  discus1       2047                      2047                      合格        
結果: "最大ユーザー・プロセス"のソフト・リソース制限チェックに合格しました。

システム要件が失敗しました 'crs'

クラスタ・サービス設定の事前チェックはすべてのノードで失敗しました。 
[oracle@discus1 clusterware]$ 

NGなのはメモリだけなのでこのまま先へ進む。（実メモリが少ないのは承知の上で行っているので）

・CVUによるハードウェアとOSのセットアップチェック。（RACを構成する１ノードのoracleユーザで実施すればOK）

[oracle@discus1 clusterware]$ ./bin/cluvfy stage -post hwos -n discus1,discus2 -verbose

ハードウェアとオペレーティング・システム設定の事後チェックを実行しています 

ノード到達可能性をチェック中...

チェック: ノード"discus1"からのノード到達可能性
  宛先ノード                                 到達可能ですか                 
  ------------------------------------  ------------------------
  discus1                               はい                      
  discus2                               はい                      
結果: ノード"discus1"からのノード到達可能性チェックに合格しました。


ユーザー等価をチェック中...

チェック: ユーザー"oracle"のユーザー等価
  ノード名                                  コメント                    
  ------------------------------------  ------------------------
  discus2                               合格                      
  discus1                               合格                      
結果: ユーザー"oracle"のユーザー等価チェックに合格しました。

ノード接続性をチェック中...


ノード"discus2"のインタフェース情報
 名前     IPアドレス          サブネット           ゲートウェイ          デフォルト・ゲートウェイ    HWアドレス            MTU   
 ------ --------------- --------------- --------------- --------------- ----------------- ------
 eth0   192.168.1.4     192.168.1.0     0.0.0.0         192.168.1.1     00:08:74:B1:C4:4C 1500  
 eth1   192.168.2.4     192.168.2.0     0.0.0.0         192.168.1.1     00:01:8E:B3:6E:BA 1500  


ノード"discus1"のインタフェース情報
 名前     IPアドレス          サブネット           ゲートウェイ          デフォルト・ゲートウェイ    HWアドレス            MTU   
 ------ --------------- --------------- --------------- --------------- ----------------- ------
 eth0   192.168.1.3     192.168.1.0     0.0.0.0         192.168.1.1     00:08:74:B1:C4:50 1500  
 eth1   192.168.2.3     192.168.2.0     0.0.0.0         192.168.1.1     00:01:8E:B3:76:A3 1500  


チェック: サブネット"192.168.1.0"のノード接続性
  ソース                             宛先                              接続しましたか         
  ------------------------------  ------------------------------  ----------------
  discus2:eth0                    discus1:eth0                    はい              
結果: ノードdiscus2,discus1を持つサブネット"192.168.1.0"のノード接続性チェックに合格しました。

チェック: サブネット"192.168.2.0"のノード接続性
  ソース                             宛先                              接続しましたか         
  ------------------------------  ------------------------------  ----------------
  discus2:eth1                    discus1:eth1                    はい              
結果: ノードdiscus2,discus1を持つサブネット"192.168.2.0"のノード接続性チェックに合格しました。

インタフェースがVIPの候補となるサブネット"192.168.1.0"で見つかりました:
discus2 eth0:192.168.1.4
discus1 eth0:192.168.1.3

インタフェースがプライベート・インタコネクトの候補となるサブネット"192.168.2.0"で見つかりました:
discus2 eth1:192.168.2.4
discus1 eth1:192.168.2.3

結果: ノード接続性チェックに合格しました。


共有記憶域アクセス可能性をチェック中...

  Disk                                  共有ノード(数量: 2)            
  ------------------------------------  ------------------------
  /dev/sdc                              discus2                 
  /dev/sda                              discus1                 

  Disk                                  共有ノード(数量: 2)            
  ------------------------------------  ------------------------
  /dev/sdb                              discus2 discus1         

  Disk                                  共有ノード(数量: 2)            
  ------------------------------------  ------------------------
  /dev/sda                              discus2                 
  /dev/sdd                              discus1                 

  Disk                                  共有ノード(数量: 2)            
  ------------------------------------  ------------------------
  /dev/sdd                              discus2                 
  /dev/sdc                              discus1                 

  Disk                                  共有ノード(数量: 2)            
  ------------------------------------  ------------------------
  /dev/sde                              discus2 discus1         


共有記憶域チェックはノード"discus2,discus1"で成功しました。

ハードウェアとオペレーティング・システム設定の事後チェックは成功しました。 
[oracle@discus1 clusterware]$ 

ということでメモリ５１２ＭＢ以外は問題なし。想定通りなのでそのまま続行。

次回へつづく<

Mac de Oracle - １０万円未満 de RAC (11g編）#15

今回はOracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１、その２、その３
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

１２．Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成

以下のRHEL5 x86用パッケージをインストールする。
oracleasm-2.6.18-92.el5-2.0.4-1.el5.i686.rpm
oracleasm-support-2.0.4-1.el5.i386.rpm
oracleasmlib-2.0.3-1.el5.i386.rpm

インストールガイド：
http://oss.oracle.com/projects/oracleasm/dist/documentation/asm-install.txt

OCFS2の場合と同様に関連するパッケージを一旦MacOSXへダウンロード後、scpにてRAC全ノードへ配布してインストールする。

G5Server:˜ discus$ scp /Users/discus/Desktop/oracleasm-support-2.0.4-1.el5.i386.rpm oracle@discus1:/tmp
oracle@discus1's password: 
oracleasm-support-2.0.4-1.el5.i386.rpm                                      100%   22KB  22.4KB/s   00:00    
G5Server:˜ discus$ scp /Users/discus/Desktop/oracleasm-support-2.0.4-1.el5.i386.rpm oracle@discus2:/tmp
oracle@discus2's password: 
oracleasm-support-2.0.4-1.el5.i386.rpm                                      100%   22KB  22.4KB/s   00:00    
G5Server:˜ discus$ scp /Users/discus/Desktop/oracleasmlib-2.0.3-1.el5.i386.rpm oracle@discus1:/tmp
oracle@discus1's password: 
oracleasmlib-2.0.3-1.el5.i386.rpm                                           100%   13KB  13.3KB/s   00:00    
G5Server:˜ discus$ scp /Users/discus/Desktop/oracleasmlib-2.0.3-1.el5.i386.rpm oracle@discus2:/tmp
oracle@discus2's password: 
oracleasmlib-2.0.3-1.el5.i386.rpm                                           100%   13KB  13.3KB/s   00:00    
G5Server:˜ discus$ scp /Users/discus/Desktop/oracleasm-2.6.18-92.el5-2.0.4-1.el5.i686.rpm oracle@discus1:/tmp
oracle@discus1's password: 
oracleasm-2.6.18-92.el5-2.0.4-1.el5.i686.rpm                                100%  122KB 122.2KB/s   00:00    
G5Server:˜ discus$ scp /Users/discus/Desktop/oracleasm-2.6.18-92.el5-2.0.4-1.el5.i686.rpm oracle@discus2:/tmp
oracle@discus2's password: 
oracleasm-2.6.18-92.el5-2.0.4-1.el5.i686.rpm                                100%  122KB 122.2KB/s   00:00    
G5Server:˜ discus$ 

配布が完了したらRAC全ノードのrootユーザでインストール及び構成を行う。
(2010/10/13訂正)

[root@discus1 tmp]# ll *.rpm
-rw-r--r-- 1 oracle oinstall  125137 10月  2 00:51 oracleasm-2.6.18-92.el5-2.0.4-1.el5.i686.rpm
-rw-r--r-- 1 oracle oinstall   22936 10月  2 00:50 oracleasm-support-2.0.4-1.el5.i386.rpm
-rw-r--r-- 1 oracle oinstall   13658 10月  2 00:51 oracleasmlib-2.0.3-1.el5.i386.rpm
[root@discus1 tmp]# rpm -qa | grep oracleasm | sort
[root@discus1 tmp]# rpm -Uvh oracleasm-2.6.18-92.el5-2.0.4-1.el5.i686.rpm oracleasm-support-2.0.4-1.el5.i386.rpm oracleasmlib-2.0.3-1.el5.i386.rpm
準備中...                 ########################################### [100%]
1:oracleasm-support      ########################################### [ 33%]
2:oracleasm-2.6.18-92.el5########################################### [ 67%]
3:oracleasmlib           ########################################### [100%]
[root@discus1 tmp]# rpm -qa | grep oracleasm | sort
oracleasm-2.6.18-92.el5-2.0.4-1.el5
oracleasm-support-2.0.4-1.el5
oracleasmlib-2.0.3-1.el5
[root@discus1 tmp]# 
[root@discus1 ˜]# /etc/init.d/oracleasm configure
Configuring the Oracle ASM library driver.

This will configure the on-boot properties of the Oracle ASM library
driver.  The following questions will determine whether the driver is
loaded on boot and what permissions it will have.  The current values
will be shown in brackets ('[]').  Hitting 
 without typing an
answer will keep that current value.  Ctrl-C will abort.

Default user to own the driver interface []: oracle
Default group to own the driver interface []: oinstall
Start Oracle ASM library driver on boot (y/n) [n]: y
Fix permissions of Oracle ASM disks on boot (y/n) [y]: y
Writing Oracle ASM library driver configuration:           [  OK  ]
Creating /dev/oracleasm mount point:                       [  OK  ]
Loading module "oracleasm":                                [  OK  ]
Mounting ASMlib driver filesystem:                         [  OK  ]
Scanning system for ASM disks:                             [  OK  ]
[root@discus1 ˜]# 

asmディスク作成する。（iscsiとして作成したデバイスへ作成する）。以下の操作はRACを構成する１ノードのrootユーザで実行する。

[root@discus1 ˜]# /etc/init.d/oracleasm createdisk VOL1 /dev/iscsi/asm1/part1
Marking disk "/dev/iscsi/asm1/part1" as an ASM disk:       [  OK  ]
[root@discus1 ˜]# /etc/init.d/oracleasm createdisk VOL2 /dev/iscsi/asm2/part1
Marking disk "/dev/iscsi/asm2/part1" as an ASM disk:       [  OK  ]
[root@discus1 ˜]# /etc/init.d/oracleasm createdisk VOL3 /dev/iscsi/asm3/part1
Marking disk "/dev/iscsi/asm3/part1" as an ASM disk:       [  OK  ]
[root@discus1 ˜]# /etc/init.d/oracleasm createdisk VOL4 /dev/iscsi/asm4/part1
Marking disk "/dev/iscsi/asm4/part1" as an ASM disk:       [  OK  ]
[root@discus1 ˜]# 

asmディスクの確認。以下の操作はRAC全ノードのrootユーザで実施する。

[root@discus1 ˜]# /etc/init.d/oracleasm scandisks
Scanning system for ASM disks:                             [  OK  ]
[root@discus1 ˜]# /etc/init.d/oracleasm listdisks
VOL1
VOL2
VOL3
VOL4
[root@discus1 ˜]# 

次回へつづく

Mac de Oracle - １０万円未満 de RAC (11g編）#14

今回はOracle Cluster File System (OCFS2)のインストール及び構成　その３

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１、その２、その３
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

１１．Oracle Cluster File System (OCFS2)のインストール及び構成　その３

・O2CBの構成
「１０万円 de RAC」と同じH/WなのでO2CBのheartbeatのしきい値は以前と同じで81に設定する。configureだけで全て行えるのでocfs2 1.2.3のときより構成は楽。。(Heartbeat dead threshholdに関してはマニュアルP.18 Heartbeat Dead Threshold参照のこと。)

[root@discus1 ocfs2]# /etc/init.d/o2cb offline ocfs2
Stopping O2CB cluster ocfs2: OK
[root@discus1 ocfs2]#
[root@discus1 ocfs2]# /etc/init.d/o2cb unload
Unmounting ocfs2_dlmfs filesystem: OK
Unloading module "ocfs2_dlmfs": OK
Unmounting configfs filesystem: OK
Unloading module "configfs": OK
[root@discus1 ocfs2]#
[root@discus1 ocfs2]# /etc/init.d/o2cb configure
Configuring the O2CB driver.

This will configure the on-boot properties of the O2CB driver.
The following questions will determine whether the driver is loaded on
boot.  The current values will be shown in brackets ('[]').  Hitting
<ENTER> without typing an answer will keep that current value.  Ctrl-C
will abort.

Load O2CB driver on boot (y/n) [n]: y
Cluster stack backing O2CB [o2cb]: 
Cluster to start on boot (Enter "none" to clear) [ocfs2]: 
Specify heartbeat dead threshold (>=7) [31]: 81
Specify network idle timeout in ms (>=5000) [30000]: 
Specify network keepalive delay in ms (>=1000) [2000]: 3000
Specify network reconnect delay in ms (>=2000) [2000]: 
Writing O2CB configuration: OK
Loading filesystem "configfs": OK
Mounting configfs filesystem at /sys/kernel/config: OK
Loading filesystem "ocfs2_dlmfs": OK
Mounting ocfs2_dlmfs filesystem at /dlm: OK
Starting O2CB cluster ocfs2: OK

・OCFS2ファイルシステムのフォーマット

[root@discus1 ˜]# mkfs.ocfs2 -b 4K -C 32K -N 4 -L oracrsfiles /dev/iscsi/crs/part1
mkfs.ocfs2 1.4.1
Cluster stack: classic o2cb
Filesystem label=oracrsfiles
Block size=4096 (bits=12)
Cluster size=32768 (bits=15)
Volume size=2145943552 (65489 clusters) (523912 blocks)
3 cluster groups (tail covers 977 clusters, rest cover 32256 clusters)
Journal size=67108864
Initial number of node slots: 4
Creating bitmaps: done
Initializing superblock: done
Writing system files: done
Writing superblock: done
Writing backup superblock: 1 block(s)
Formatting Journals: done
Formatting slot map: done
Writing lost+found: done
mkfs.ocfs2 successful

事前に作成しておいたマウントポイント/u02へOCFS2ファイルシステムをマウントする。また、/etc/fstabも以下のようの編集する。

[root@discus1 ˜]# mount -t ocfs2 -o datavolume,nointr -L "oracrsfiles" /u02
[root@discus1 ˜]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
configfs on /sys/kernel/config type configfs (rw)
ocfs2_dlmfs on /dlm type ocfs2_dlmfs (rw)
/dev/sde1 on /u02 type ocfs2 (rw,_netdev,datavolume,nointr,heartbeat=local)
[root@discus1 ˜]# vi /etc/fstab

/dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0
LABEL=oracrsfiles       /u02                    ocfs2   _netdev,datavolume,nointr       0 0
[root@discus1 ˜]#

最後に/etc/sysctl.confへ以下の２行を追加（詳細はマニュアルのP.19 Kernel Configuration 参照）。
kernel.panic_on_oops = 1
kernel.panic = 30

[root@discus1 ˜]# vi /etc/sysctl.conf
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled.  See sysctl(8) and
# sysctl.conf(5) for more details.

# Controls IP packet forwarding
net.ipv4.ip_forward = 0

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0

・・・・中略・・・・
# for Oracle11g
kernel.sem = 250 32000 100 128
fs.file-max = 65536
kernel.shmall = 2097152
kernel.shmmax = 268435456
kernel.shmmni = 4096
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 4194304
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 262144
kernel.panic_on_oops = 1
kernel.panic = 30

ここでRAC全ノードを再起動する。再起動後、mountコマンドで状態を確認する。

[root@discus1 ˜]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
configfs on /sys/kernel/config type configfs (rw)
ocfs2_dlmfs on /dlm type ocfs2_dlmfs (rw)
/dev/sde1 on /u02 type ocfs2 (rw,_netdev,datavolume,nointr,heartbeat=local)

OCFS2のバージョン確認方法。以前とかわったようだ。以前は/proc/fs/ocfs2/versionで見る事ができたが1.4.1では以下のようにすると確認できる。

[root@discus1 ˜]# mkfs.ocfs2 -V
mkfs.ocfs2 1.4.1
[root@discus1 ˜]# 

これでOCFS2に関する作業はひとまず終了。次回へつづく

Mac de Oracle - １０万円未満 de RAC (11g編）#13

今回はOracle Cluster File System (OCFS2)のインストール及び構成　その２

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１、その２
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

１１．Oracle Cluster File System (OCFS2)のインストール及び構成　その２

・OCFS2の構成

ocfs2consoleというGUIツールが提供されているのでそれを利用する。この操作はRACを構成する全ノードで実施する。（OCFS2の構成もMacOSXのxtermから行う。お約束.w）

2010/10/16訂正
Node Configurationダイアログの画像を訂正。private networkのホスト名として設定したdiscus1-priv/discus2-privではなく、public networkのホスト名として設定したdiscus1/discus2を設定するのが正しい。

OCFS2コンソールで構成後には/etc/ocfs2/cluster.confが作成される。

[root@discus1 ˜]# cat /etc/ocfs2/cluster.conf
node:
        ip_port = 7777
        ip_address = 192.168.2.3
        number = 0
        name = discus1
        cluster = ocfs2

node:
        ip_port = 7777
        ip_address = 192.168.2.4
        number = 1
        name = discus2
        cluster = ocfs2

cluster:
        node_count = 2
        name = ocfs2

[root@discus1 ˜]# 

簡単な状況確認及び動作確認。（これをやらなくてもインストール及び構成には支障はありませんが。。。念のため。）
後ほど調整するが、Heatbeat dead threshholdが31（デフォルト）になっていることが確認できる。

[root@discus2 ocfs2]# /etc/init.d/o2cb status
Driver for "configfs": Loaded
Filesystem "configfs": Mounted
Driver for "ocfs2_dlmfs": Loaded
Filesystem "ocfs2_dlmfs": Mounted
Checking O2CB cluster ocfs2: Online
Heartbeat dead threshold = 31
  Network idle timeout: 30000
  Network keepalive delay: 2000
  Network reconnect delay: 2000
Checking O2CB heartbeat: Not active
[root@discus2 ocfs2]#
[root@discus2 ocfs2]# /etc/init.d/o2cb offline ocfs2
Stopping O2CB cluster ocfs2: OK
[root@discus2 ocfs2]#
[root@discus2 ocfs2]# /etc/init.d/o2cb unload
Unmounting ocfs2_dlmfs filesystem: OK
Unloading module "ocfs2_dlmfs": OK
Unmounting configfs filesystem: OK
Unloading module "configfs": OK
[root@discus2 ocfs2]#
[root@discus2 ocfs2]# /etc/init.d/o2cb load
Loading filesystem "configfs": OK
Mounting configfs filesystem at /sys/kernel/config: OK
Loading filesystem "ocfs2_dlmfs": OK
Mounting ocfs2_dlmfs filesystem at /dlm: OK
[root@discus2 ocfs2]#
[root@discus2 ocfs2]# /etc/init.d/o2cb online ocfs2
Starting O2CB cluster ocfs2: OK
[root@discus2 ocfs2]#
[root@discus2 ocfs2]# /etc/init.d/o2cb status
Driver for "configfs": Loaded
Filesystem "configfs": Mounted
Driver for "ocfs2_dlmfs": Loaded
Filesystem "ocfs2_dlmfs": Mounted
Checking O2CB cluster ocfs2: Online
Heartbeat dead threshold = 31

  Network idle timeout: 30000

  Network keepalive delay: 2000
  Network reconnect delay: 2000
Checking O2CB heartbeat: Not active
[root@discus2 ocfs2]# 

その３へつづく。

(2010/10/17追記）
ちなみに、add nodeダイアログで「Name」欄にpublic networkに設定したhost名ではなく、private networkに設定したhost名を設定してしまうと、cluster file system（以下の例では “ocfs2”)をonlineにできずエラーが発生する。 add nodeダイアログでは、public networkに指定したhost名を設定しましょうね。（直感的に分かりにくいので注意しましょ！）

[root@discus1 ˜]# /etc/init.d/o2cb status
Driver for "configfs": Loaded
Filesystem "configfs": Mounted
Driver for "ocfs2_dlmfs": Loaded
Filesystem "ocfs2_dlmfs": Mounted
Checking O2CB cluster ocfs2: Offline

[root@discus1 ˜]# /etc/init.d/o2cb unload
Unmounting ocfs2_dlmfs filesystem: OK
Unloading module "ocfs2_dlmfs": OK
Unmounting configfs filesystem: OK
Unloading module "configfs": OK

[root@discus1 ˜]# /etc/init.d/o2cb load
Loading filesystem "configfs": OK
Mounting configfs filesystem at /sys/kernel/config: OK
Loading filesystem "ocfs2_dlmfs": OK
Mounting ocfs2_dlmfs filesystem at /dlm: OK

[root@discus1 ˜]# /etc/init.d/o2cb online ocfs2
Starting O2CB cluster ocfs2: Failed
Cluster ocfs2 created
Node discus1-priv added
Node discus2-priv added
o2cb_ctl: Configuration error discovered while populating cluster ocfs2. 
          None of its nodes were considered local.  
          A node is considered local when its node name 
          in the configuration matches this machine's host name.

Mac de Oracle - １０万円未満 de RAC (11g編）#12

今回はOracle Cluster File System (OCFS2)のインストール及び構成　その１

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成　その１
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

１１．Oracle Cluster File System (OCFS2)のインストール及び構成　その１

・Oracle Cluster File System (OCFS2)と関連ツールのダウンロード

約２年前はRHEL4向けのOCFS2 1.2.3-1を利用したが今回はCentOS5.2なのでRHEL5向け1.4.1-1を利用する。kernelのリリース毎に個別のパッケージが用意されているので対応するものを利用する。

[oracle@discus1 ˜]$ uname -r
2.6.18-92.el5
[oracle@discus1 ˜]$ 

今回インストールしたCentOS5.2のkernelは2.6.18-92.el5なので以下のパッケージをインストールする。尚、「１０万円 de RAC #20」のようにRAC全ノードからwgetで直接ダウンロードすることも可能なのだが今回は一旦MacOSX側で全てダウンロード後、各RACノードへscpでコピーすることにした。（Macも絡めないとね・・・Mac De Oracleですから。wwww）

http://oss.oracle.com/projects/ocfs2/dist/files/RedHat/RHEL5/i386/1.4.1-1/2.6.18-92.el5/ocfs2-2.6.18-92.el5-1.4.1-1.el5.i686.rpm
http://oss.oracle.com/projects/ocfs2-tools/dist/files/RedHat/RHEL5/i386/1.4.1-1/ocfs2-tools-1.4.1-1.el5.i386.rpm
http://oss.oracle.com/projects/ocfs2-tools/dist/files/RedHat/RHEL5/i386/1.4.1-1/ocfs2console-1.4.1-1.el5.i386.rpm

OCFS2 1.4.1-1のドキュメント（USER'S GUIDE FOR RELEASE 1.4）は以下。
http://oss.oracle.com/projects/ocfs2/dist/documentation/v1.4/ocfs2-1_4-usersguide.pdf

MacでダンロードしたOCFS2関連パッケージをscpでRACの各ノードの/tmpへ配布。（以下はdiscus1の/tmpへscpしている例。）

Welcome to Darwin!
G5Server:˜ discus$
G5Server:˜ discus$ scp /Users/discus/Desktop/ocfs2-2.6.18-92.el5-1.4.1-1.el5.i686.rpm oracle@discus1:/tmp
oracle@discus1's password: 
ocfs2-2.6.18-92.el5-1.4.1-1.el5.i686.rpm                                          100%  303KB 303.0KB/s   00:00    
G5Server:˜ discus$ scp /Users/discus/Desktop/ocfs2-tools-1.4.1-1.el5.i386.rpm oracle@discus1:/tmp
oracle@discus1's password: 
ocfs2-tools-1.4.1-1.el5.i386.rpm                                                  100% 1396KB   1.4MB/s   00:00    
G5Server:˜ discus$ scp /Users/discus/Desktop/ocfs2console-1.4.1-1.el5.i386.rpm oracle@discus1:/tmp
oracle@discus1's password: 
ocfs2console-1.4.1-1.el5.i386.rpm                                                 100%  306KB 306.5KB/s   00:00    
G5Server:˜ discus$ 

RACの各ノードでOCFS2関連パーッケージをインストール

G5Server:˜ discus$ ssh root@discus1
root@discus1's password: 
Last login: Mon Oct 1 21:00:10 2008 from 192.168.1.19
[root@discus1 ˜]# 
[root@discus1 ˜]# cd /tmp
[root@discus1 tmp]# ll *.rpm
-rw-r--r-- 1 oracle oinstall  310243 10月  1 22:07 ocfs2-2.6.18-92.el5-1.4.1-1.el5.i686.rpm
-rw-r--r-- 1 oracle oinstall 1429676 10月  1 22:08 ocfs2-tools-1.4.1-1.el5.i386.rpm
-rw-r--r-- 1 oracle oinstall  313824 10月  1 22:10 ocfs2console-1.4.1-1.el5.i386.rpm
[root@discus1 tmp]# rpm -qa | grep ocfs2 | sort
[root@discus1 tmp]# rpm -Uvh ocfs2-tools-1.4.1-1.el5.i386.rpm
準備中...                ########################################### [100%]
   1:ocfs2-tools            ########################################### [100%]
[root@discus1 tmp]# rpm -Uvh ocfs2-2.6.18-92.el5-1.4.1-1.el5.i686.rpm
準備中...                ########################################### [100%]
   1:ocfs2-2.6.18-92.el5    ########################################### [100%]
[root@discus1 tmp]# rpm -Uvh ocfs2console-1.4.1-1.el5.i386.rpm
準備中...                ########################################### [100%]
   1:ocfs2console           ########################################### [100%]
[root@discus1 tmp]# rpm -qa | grep ocfs2 | sort
ocfs2-2.6.18-92.el5-1.4.1-1.el5
ocfs2-tools-1.4.1-1.el5
ocfs2console-1.4.1-1.el5
[root@discus1 tmp]# 

ファイヤーウォール及びSELinux設定はCentOS5.2インストール後に行っているので特に行はないが、もう一度確認。
MacOSXのxterm(X11)から行っている。MacOSXのxtermから ssh -Y username@hostname　でX forwardingが有効になる。

ここで各RACノードを再起動。

長いので次回へ続く

Mac de Oracle - １０万円未満 de RAC (11g編）#11

今回はOracle RACノード構成ファイルの確認

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

１０．Oracle RACノード構成ファイルの確認。

ここまでの作業で編集したり作成したRACノードの構成ファイル等の確認。内容の確認だけなのでさらりと・・・楽しい部分ではないのでね・・・w。（RACの全ノードで確認する。）

/etc/sysctl.conf
(2010/10/13訂正)

[root@discus1 ˜]#  cat /etc/sysctl.conf
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled.  See sysctl(8) and
# sysctl.conf(5) for more details.

・・・・中略・・・・

# for Oracle11g
kernel.sem = 250 32000 100 128
fs.file-max = 6553600
fs.aio-max-nr = 1048576
kernel.shmall = 2097152
kernel.shmmax = 268435456
kernel.shmmni = 4096
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
[root@discus1 ˜]# 

/etc/security/limits.conf

[root@discus1 ˜]# cat /etc/security/limits.conf | grep oracle
oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536

/etc/pam.d/login

[root@discus1 ˜]# cat /etc/pam.d/login | grep pam_limits.so
session  required  /lib/security/pam_limits.so
session  required  pam_limits.so

/etc/profile
(2010/10/13訂正)

[root@discus1  ˜]# tail -9 /etc/profile
 if [ $USER = "oracle" ]; then
     if [ $SHELL = "/bin/ksh" ]; then
         ulimit -p 16384
         ulimit -n 65536
    else
         ulimit -u 16384 -n 65536
     fi
     umask 022
 fi
[root@discus1  ˜]#

/etc/hosts

[root@discus1 ˜]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain localhost

# Public Networks - (eth0)
192.168.1.3     discus1.macdeoracle.jp  discus1
192.168.1.4     discus2.macdeoracle.jp  discus2
192.168.1.5     arowana.macdeoracle.jp  arowana

# Private Network - (eth1)
192.168.2.3     discus1-priv.macdeoracle.jp     discus1-priv
192.168.2.4     discus2-priv.macdeoracle.jp     discus2-priv
192.168.2.5     arowana-priv.macdeoracle.jp     arowana-priv

# Public Virtual IP(VIP) address for - (eth0)
192.168.1.100   discus1-vip.macdeoracle.jp      discus1-vip
192.168.1.101   discus2-vip.macdeoracle.jp      discus2-vip
[root@discus1 ˜]# 

/etc/modprobe.conf

[root@discus1 ˜]# cat /etc/modprobe.conf | grep hangcheck-timer
options hangcheck-timer hangcheck_tick=1 hangcheck_margin=55 hangcheck_reboot=1
[root@discus1 ˜]# 

/etc/rc.local

[root@discus1 ˜]# cat /etc/rc.local | grep hangcheck-timer
/sbin/modprobe hangcheck-timer
[root@discus1 ˜]# 

/etc/udev/rules.d/55-openiscsi.rules

[root@discus1 ˜]# cat /etc/udev/rules.d/55-openiscsi.rules
KERNEL=="sd*", BUS=="scsi", PROGRAM="/etc/udev/scripts/iscsidev.sh %b",SYMLINK+="iscsi/%c/part%n"

/etc/udev/sripts/iscsidev.sh

[root@discus1 ˜]# cat /etc/udev/scripts/iscsidev.sh
#!/bin/sh

# FILE: /etc/udev/scripts/iscsidev.sh

BUS=${1}
HOST=${BUS%%:*}

[ -e /sys/class/iscsi_host ] || exit 1

file="/sys/class/iscsi_host/host${HOST}/device/session*/iscsi_session*/targetname"

target_name=$(cat ${file})

# This is not an open-scsi drive
if [ -z "${target_name}" ]; then
   exit 1
fi

echo "${target_name##*.}"

/etc/iscsi/initiatorname.iscsi

[root@discus1 ˜]# cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1994-05.jp.macdeoracle:discus1
[root@discus1 ˜]# ssh root@discus2 cat /etc/iscsi/initiatorname.iscsi
root@discus2's password: 
InitiatorName=iqn.1994-05.jp.macdeoracle:discus2
[root@discus1 ˜]# 

iscsid及び、iscsiの自動起動設定の確認

[root@discus1 ˜]# chkconfig --list iscsid
iscsid          0:off   1:off   2:off   3:on    4:on    5:on    6:off
[root@discus1 ˜]# chkconfig --list iscsi
iscsi           0:off   1:off   2:off   3:on    4:on    5:on    6:off
[root@discus1 ˜]# 

そして最後はOracleユーザの.bash_profile

[oracle@discus1  ˜]$ cat .bash_profile
# .bash_profile

# Get the aliases and functions
if [ -f  ˜/.bashrc ]; then
        .  ˜/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/bin

export PATH

alias ls="ls -FA"

export JAVA_HOME=/usr/local/java

# User specific environment and startup programs
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/11.1.0/db_1
export ORA_CRS_HOME=/u01/app/crs
export ORACLE_PATH=$ORACLE_BASE/common/oracle/sql:.:$ORACLE_HOME/rdbms/admin

# discus1の場合はorcl1 / discus2の場合はorcl2をセット
export ORACLE_SID=orcl1

export PATH=.:${JAVA_HOME}/bin:${PATH}:$HOME/bin:$ORACLE_HOME/bin
export PATH=${PATH}:/usr/bin:/bin:/usr/bin/X11:/usr/local/bin
export PATH=${PATH}:$ORACLE_BASE/common/oracle/bin
export ORACLE_TERM=xterm
export TNS_ADMIN=$ORACLE_HOME/network/admin
export ORA_NLS10=$ORACLE_HOME/nls/data
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$ORACLE_HOME/oracm/lib:/lib:/usr/lib:/usr/local/lib
export CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib:$ORACLE_HOME/network/jlib
export THREADS_FLAG=native
export TEMP=/tmp
export TMPDIR=/tmp

次回へつづく。

Mac de Oracle - １０万円未満 de RAC (11g編）#10

今回はOracle RACノード間リモートアクセスの構成

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

９．Oracle RACノード間リモートアクセスの構成。

行う操作はマニュアルに記載している内容に沿っているので詳細は以下マニュアルを参照のこと。
Oracle Clusterware Installation Guide 11g Release 1 (11.1) for Linux - 2.11 Configuring SSH on All Cluster Nodes

RAC全ノードのoracleユーザで実施する。

[oracle@discus1 ˜]$ mkdir -p ˜/.ssh
[oracle@discus1 ˜]$ chmod 700 ˜/.ssh
[oracle@discus1 ˜]$ /usr/bin/ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/oracle/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
・・・・以下略・・・・

以下の操作はRACを構成する１ノードのoracleユーザで実施すればOK(この例ではdiscus1から）

[oracle@discus1 ˜]$ touch ˜/.ssh/authorized_keys
[oracle@discus1 ˜]$ cd ˜/.ssh
[oracle@discus1 .ssh]$ ls -l *.pub
-rw-r--r-- 1 oracle oinstall 411 10月  1 21:39 id_rsa.pub
[oracle@discus1 .ssh]$ ssh discus1 cat ˜/.ssh/id_rsa.pub >> ~˜.ssh/authorized_keys
The authenticity of host 'discus1 (192.168.1.3)' can't be established.
RSA key fingerprint is 4c:17:88:23:b0:40:3a:b2:cb:93:07:61:63:4d:12:03.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'discus1,192.168.1.3' (RSA) to the list of known hosts.
oracle@discus1's password: 
[oracle@discus1 .ssh]$ ssh discus2 cat ˜/.ssh/id_rsa.pub >> ˜/.ssh/authorized_keys
The authenticity of host 'discus2 (192.168.1.4)' can't be established.
RSA key fingerprint is 15:d7:fe:b0:dd:7f:42:cc:2d:5e:60:e8:a5:06:5b:d2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'discus2,192.168.1.4' (RSA) to the list of known hosts.
oracle@discus2's password: 
[oracle@discus1 .ssh]$ scp ˜/.ssh/authorized_keys discus2:.ssh/authorized_keys
oracle@discus2's password: 
authorized_keys                                      100%  822     0.8KB/s   00:00    
[oracle@discus1 .ssh]$ 

RAC全ノードのoracleユーザで実施する。

[oracle@discus1 .ssh]$ chmod 600 ˜/.ssh/authorized_keys
[oracle@discus1 .ssh]$ 

以下の操作はRACを構成する１ノードのoracleユーザで実施すればOK(この例ではdiscus1から）

[oracle@discus1 ˜]$ ssh discus1 hostname
root@discus1's password: 
discus1.macdeoracle.jp
[oracle@discus1 ˜]$ ssh discus2 hostname
root@discus2's password: 
discus2.macdeoracle.jp
[oracle@discus1 ˜]$ 

sshユーザ等価関係の有効化。以下の操作はRACを構成する１ノードのoracleユーザで実施すればOK(この例ではdiscus1から）
RACのインストールではOUIを実行する前にsshユーザ等価関係の有効化を行っておく必要があるのでお忘れなく。

[oracle@discus1 ˜]$ 
[oracle@discus1 ˜]$ exec /usr/bin/ssh-agent $SHELL
[oracle@discus1 ˜]$ /usr/bin/ssh-add
Enter passphrase for /home/oracle/.ssh/id_rsa:
 Identity added: /home/oracle/.ssh/id_rsa (/home/oracle/.ssh/id_rsa)
[oracle@discus1 ˜]$ 
[oracle@discus1 ˜]$ 
[oracle@discus1 ˜]$ ssh discus1 hostname
discus1.macdeoracle.jp
[oracle@discus1 ˜]$ ssh discus2 hostname
discus2.macdeoracle.jp
[oracle@discus1 ˜]$ 

次回へつづく。

今回はhangcheck-timerカーネル・モジュールの構成

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

８．hangcheck-timerカーネル・モジュールの構成。

注）
現時点(2008年10月時点）で公開されているUS OTN：Oracle11gのRAC構築記事ではhangcheck-timerに関する設定は見当たらないのだが、どうもマニュアルバグがあり初期のマニュアルにはhangcheck-timerの構成は不要とされていたことが影響しているのかもしれない。（あくまで想像）
「１０万円未満 de RAC (11g編）」では訂正された手順に従い構成することにする。

訂正されたマニュアルは以下。

Oracle Clusterware Installation Guide 11g Release 1 (11.1) for Linux
　- 7.1.2.2 Configuring the Hangcheck-timer Module　日本語、English
Oracle Clusterware Installation Guide 11g Release 1 (11.1) for Linux
　- OPROCD and Hangcheck Timer Provide Fencing for Cluster Nodes : 日本語、English

hangcheck-margin以外はマニュアルに記載されている内容と同じ値に設定した。少々非力なPCを利用しているので長目の設定。（CSS misscountはデフォルト値(60sec)を利用するのでhangcheck_tick+hangcheck_margin < CSS misscountとなるように設定した。）
この操作はRAC全ノードのrootユーザで実施する。

[root@discus1 ˜]# find /lib/modules -name "hangcheck-timer.ko"
/lib/modules/2.6.18-92.el5/kernel/drivers/char/hangcheck-timer.ko
[root@discus1 ˜]# echo "options hangcheck-timer hangcheck_tick=1 hangcheck_margin=55 hangcheck_reboot=1" >> /etc/modprobe.conf
[root@discus1 ˜]# cat /etc/modprobe.conf
alias eth0 e1000
alias eth1 r8169
alias scsi_hostadapter ata_piix
alias snd-card-0 snd-intel8x0
options snd-card-0 index=0
options snd-intel8x0 index=0
remove snd-intel8x0 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-intel8x0
options hangcheck-timer hangcheck_tick=1 hangcheck_margin=55 hangcheck_reboot=1
[root@discus1˜~]# 
[root@discus1 ˜]# echo "/sbin/modprobe hangcheck-timer" >> /etc/rc.local
[root@discus1 ˜]# cat /etc/rc.local
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local
/sbin/modprobe hangcheck-timer
[root@discus1 ˜]# 

次回へつづく

Mac de Oracle - １０万円未満 de RAC (11g編）#8

今回はOracle向けLinuxサーバーの構成（カーネルパラメータの設定）

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

７．Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）。

Oracle Database Quick Installation Guide 11g Release 1 (11.1) for Linux x86 - 6 Configuring Kernel Parameters / Settting Shell limits for the oracle user

リブートするのが面倒なのでOSのリブートなしで変更したカーネルパラメータ値を反映させたついでに/etc/sysctl.confへも追加。
(2010/10/13訂正。）

[root@discus1 ˜]# sysctl -w fs.file-max=65536 >> /etc/sysctl.conf; tail -1 /etc/sysctl.conf;
fs.file-max = 65536

・・・・中略・・・・

[root@discus1 ˜]# sysctl -w net.core.wmem_max = 1048576 >> /etc/sysctl.conf; tail -1 /etc/sysctl.conf;
net.core.wmem_max = 1048576
[root@discus1 ˜]#

として、今回は以下のように設定。
物理メモリが少な過ぎる（５１２ＭＢなので）ので・・・キツいかな・・・今回は・・DynaBookの時でさえ７６８ＭＢだったからな・・）
(2010/10/13訂正。）

[root@discus1 ˜]# 
[root@discus1 ˜]# cat /etc/sysctl.conf
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled.  See sysctl(8) and
# sysctl.conf(5) for more details.

# Controls IP packet forwarding
net.ipv4.ip_forward = 0

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename
# Useful for debugging multi-threaded applications
kernel.core_uses_pid = 1

# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1

# Controls the maximum size of a message, in bytes
kernel.msgmnb = 65536

# Controls the default maxmimum size of a mesage queue
kernel.msgmax = 65536

# Controls the maximum shared segment size, in bytes
#kernel.shmmax = 4294967295

# Controls the maximum number of shared memory segments, in pages
#kernel.shmall = 268435456

# for Oracle11g
kernel.sem = 250 32000 100 128
fs.file-max = 65536
fs.aio-max-nr = 1048576
kernel.shmall = 2097152
kernel.shmmax = 268435456
kernel.shmmni = 4096
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
[root@discus1 ˜]# 

・Oracleユーザのshell limitの設定
(2010/10/13訂正。バックスラッシュを削除）

[root@discus1 ˜]# cat >> /etc/security/limits.conf <<EOF
> oracle soft nproc 2047
> oracle hard nproc 16384
> oracle soft nofile 1024
> oracle hard nofile 65536
> EOF
[root@discus1 ˜]#
[root@discus1 ˜]# cat >> /etc/pam.d/login  <<EOF
> # added for oracle shell limits
> session  required  /lib/security/pam_limits.so
> session  required  pam_limits.so
> EOF
[root@discus1 ˜]#
[root@discus1 ˜]# cat >> /etc/profile  <<EOF
> if [ $USER = "oracle" ]; then
>     if [ $SHELL = "/bin/ksh" ]; then
>         ulimit -p 16384
>         ulimit -n 65536
>     else
>         ulimit -u 16384 -n 65536
>     fi
>     umask 022
> fi
> EOF
[root@discus1 ˜]#

discus1からOracleのインストールを行うので他のノード時刻をduscus1より少々進めておく。今回はdiscus2を約４０秒進めてある。（NTPによる時刻調整はRACインストール後に行えばよいので。）

[root@discus1 ˜]# date
2008年 10月  1日 水曜日 21:23:47 JST
[root@discus1 ˜]# 

[root@discus2 ˜]# date
2008年 10月  1日 水曜日 21:24:28 JST
[root@discus2 ˜]#

次回へつづく。

Mac de Oracle - １０万円未満 de RAC (11g編）#7

今回はOracle所有者と関連ディレクトリの作成及び環境変数の設定

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

６．Oracle所有者と関連ディレクトリの作成及び環境変数の設定。

この作業はインストレーションガイドに記載されているお約束の作業なので詳細はOracle Database Installation Guide 11g Release 1 (11.1) for Linux - 2 Oracle Database Preinstallation Requirements / Oracle Clusterware Installation Guide 11g Release 1 (11.1) for Linux - 2 Oracle Clusterware Preinstallation Tasks / Oracle Clusterware Installation Guide 11g Release 1 (11.1) for Linux - 3 Oracle Real Application Clusters Preinstallation Tasksなどを参照のこと。

・Oracle用ユーザとグループの作成（RACの全ノードのrootユーザで実施）

[root@discus1 ˜]# groupadd -g 601 oinstall
[root@discus1 ˜]# groupadd -g 602 dba
[root@discus1 ˜]# groupadd -g 603 oper
[root@discus1 ˜]# groupadd -g 604 asm
[root@discus1 ˜]# groupadd -g 605 asmdba
[root@discus1 ˜]# 
[root@discus1 ˜]# useradd -m -u 601 -g oinstall -G dba,oper,asm -d /home/oracle -s /bin/bash -c "Oracle Software Owner" oracle
[root@discus1 ˜]# id oracle
uid=601(oracle) gid=601(oinstall) 所属グループ=601(oinstall),602(dba),603(oper),604(asm) context=root:system_r:unconfined_t:SystemLow-SystemHigh
[root@discus1 ˜]# 
[root@discus1 ˜]# id nobody
uid=99(nobody) gid=99(nobody) 所属グループ=99(nobody) context=root:system_r:unconfined_t:SystemLow-SystemHigh
[root@discus1 ˜]# 

・Oracle Base向けディレクトリの作成（RACの全ノードのrootユーザで実施）

[root@discus1 ˜]# mkdir -p /u01/app/oracle
[root@discus1 ˜]# chown -R oracle:oinstall /u01/app
[root@discus1 ˜]# chmod -R 755 /u01/app
[root@discus1 ˜]# 

・Oracle Clusterware向けホームディレクトリの作成（RACの全ノードのrootユーザで実施）

[root@discus1 ˜]# mkdir -p /u01/app/crs
[root@discus1 ˜]# chown -R oracle:oinstall /u01/app/crs
[root@discus1 ˜]# chmod -R 755 /u01/app/crs
[root@discus1 ˜]# 

・Oracle Cluster File System 2 (OCSF2)のマウントポイントの作成（RACの全ノードのrootユーザで実施）

[root@discus1 ˜]# mkdir -p /u02
[root@discus1 ˜]# chown -R oracle:oinstall /u02
[root@discus1 ˜]# chmod -R 755 /u02
[root@discus1 ˜]# 

尚、iSCSI共有ストレージの構成は以下のようにする。

共有ストレージの構成
ファイルシステム	iSCSIターゲット名	サイズ(GB)	マウントポイント	ASMディスクグループ名	ファイルタイプ
OCFS2	crs	2	/u02/oradata/orcl	-	Oracle Cluster Registry - (100 MB) Voting Disk - (20MB)
ASM	asm1	21.5	ORCL:VOL1	+ORCL_DISK_GRP1	Oracleデータベースファイル
ASM	asm2	21.5	ORCL:VOL2	+ORCL_DISK_GRP1	Oracleデータベースファイル
ASM	asm3	21.5	ORCL:VOL3	+FLASH_RECOVERY_AREA	Flash recovery area
ASM	asm4	21.5	ORCL:VOL4	+FLASH_RECOVERY_AREA	Flash recovery area
合計	-	88	-	-	-

・Oracleユーザのログインスクリプトの作成（RACの全ノードのoracleユーザで実施）

環境変数全般についてはOracle Database Administrator's Reference 11g Release 1 (11.1) for Linux and UNIX-Based Operating Systems - 1.2 Environment Variablesを参照のこと。

以下、viを利用する前後で環境変数LANGをja_JP.UTF-8からus_US.UTF-8そしてまたja_JP.UTF-8へ変更しているが、MacOSX10.4.11のTerminalからssh接続しているのだが、LANG=ja_JP.UTF-8のままだとviで編集する際、行のポジションがずれるなど問題が生じることからviを利用する前後でLANGの設定を変更している。MacOSX10.4.11のTerminalからssh接続しないのであれば特に行う必要はない。

[oracle@discus1 ˜]$ export LANG=us_US.UTF-8
[oracle@discus1 ˜]$ vi .bash_profile
[oracle@discus1 ˜]$ cat .bach_profile
# .bash_profile

# Get the aliases and functions
if [ -f ˜/.bashrc ]; then
        . ˜/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/bin

export PATH

alias ls="ls -FA"

export JAVA_HOME=/usr/local/java

# User specific environment and startup programs
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/11.1.0/db_1
export ORA_CRS_HOME=/u01/app/crs
export ORACLE_PATH=$ORACLE_BASE/common/oracle/sql:.:$ORACLE_HOME/rdbms/admin

# discus1の場合はorcl1 / discus2の場合はorcl2をセット
export ORACLE_SID=orcl1

export PATH=.:${JAVA_HOME}/bin:${PATH}:$HOME/bin:$ORACLE_HOME/bin
export PATH=${PATH}:/usr/bin:/bin:/usr/bin/X11:/usr/local/bin
export PATH=${PATH}:$ORACLE_BASE/common/oracle/bin
export ORACLE_TERM=xterm
export TNS_ADMIN=$ORACLE_HOME/network/admin
export ORA_NLS10=$ORACLE_HOME/nls/data
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$ORACLE_HOME/oracm/lib:/lib:/usr/lib:/usr/local/lib
export CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib:$ORACLE_HOME/network/jlib
export THREADS_FLAG=native
export TEMP=/tmp
export TMPDIR=/tmp
[oracle@discus1 ˜]$ export LANG=ja_JP.UTF-8
[oracle@discus1 ˜]$

次回へつづく

Mac de Oracle - １０万円未満 de RAC (11g編）#6

今回はOracle RACノード側でiSCSIボリュームの構成の後半。

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１、その２
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

５．Oracle RACノードでのiSCSIボリュームの構成のつづき。

udevに関連しない操作／確認は「１０万円でRAC」の場合と同じなのでそちらも参照のこと。

・fdiskでSCSIデバイスにパーティション作成

/dev/iscsi/asm1/part、/dev/iscsi/asm2/part、/dev/iscsi/asm3/part、/dev/iscsi/asm4/part、/dev/iscsi/crs/partに対して１パーティションを作成し利用可能な全シリンダを割り当てる。
尚、この操作はRACを構成するノードの１ノードでrootユーザとして実施する。

[root@discus1 ˜]# fdisk /dev/iscsi/asm1/part
デバイスは正常な DOS 領域テーブルも、Sun, SGI や OSF ディスクラベルも
含んでいません
新たに DOS ディスクラベルを作成します。あなたが書き込みを決定するまで、変更は
メモリ内だけに残します。その後はもちろん以前の内容は修復不可能になります。

このディスクのシリンダ数は 22016 に設定されています。
間違いではないのですが、1024 を超えているため、以下の場合
に問題を生じうる事を確認しましょう:
1) ブート時に実行するソフトウェア (例. バージョンが古い LILO)
2) 別の OS のブートやパーティション作成ソフト
   (例. DOS FDISK, OS/2 FDISK)
警告: 領域テーブル 4 の不正なフラグ 0x0000 は w(書き込み)によって
正常になります

コマンド (m でヘルプ): n
コマンドアクション
   e   拡張
   p   基本領域 (1-4)
p
領域番号 (1-4): 1
最初 シリンダ (1-22016, default 1): 1
終点 シリンダ または +サイズ または +サイズM または +サイズK (1-22016, default 22016): 22016

コマンド (m でヘルプ): w
領域テーブルは交換されました！

ioctl() を呼び出して領域テーブルを再読込みします。
ディスクを同期させます。
[root@discus1 ˜]# 

/dev/iscsi/asm2/part、/dev/iscsi/asm3/part、/dev/iscsi/asm3/partにも同様の操作を繰り返す。
・・・・中略・・・・

[root@discus1 ˜]# 
[root@discus1 ˜]# fdisk /dev/iscsi/crs/part
デバイスは正常な DOS 領域テーブルも、Sun, SGI や OSF ディスクラベルも
含んでいません
新たに DOS ディスクラベルを作成します。あなたが書き込みを決定するまで、変更は
メモリ内だけに残します。その後はもちろん以前の内容は修復不可能になります。
警告: 領域テーブル 4 の不正なフラグ 0x0000 は w(書き込み)によって
正常になります

コマンド (m でヘルプ): n
コマンドアクション
   e   拡張
   p   基本領域 (1-4)
p
領域番号 (1-4): 1
最初 シリンダ (1-1009, default 1): 1
終点 シリンダ または +サイズ または +サイズM または +サイズK (1-1009, default 1009): 1009

コマンド (m でヘルプ): w
領域テーブルは交換されました！

ioctl() を呼び出して領域テーブルを再読込みします。
ディスクを同期させます。
[root@discus1 ˜]# 

・確認

パーティションの作成が済んだらRACの全ノードでrootユーザとしてパーティションが認識されているか確認する。以下はdiscus1から実施したもの

[root@discus1 ˜]#
[root@discus1 ˜]# partprobe
[root@discus1 ˜]#
[root@discus1 ˜]# fdisk -l

Disk /dev/hda: 20.0 GB, 20020396032 bytes
255 heads, 63 sectors/track, 2434 cylinders
Units = シリンダ数 of 16065 * 512 = 8225280 bytes

デバイス Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1          13      104391   83  Linux
/dev/hda2              14        2434    19446682+  8e  Linux LVM

Disk /dev/sda: 23.0 GB, 23085449216 bytes
64 heads, 32 sectors/track, 22016 cylinders
Units = シリンダ数 of 2048 * 512 = 1048576 bytes

デバイス Boot      Start         End      Blocks   Id  System
/dev/sda1               1       22016    22544368   83  Linux

Disk /dev/sdb: 23.0 GB, 23085449216 bytes
64 heads, 32 sectors/track, 22016 cylinders
Units = シリンダ数 of 2048 * 512 = 1048576 bytes

デバイス Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       22016    22544368   83  Linux

Disk /dev/sdc: 23.0 GB, 23085449216 bytes
64 heads, 32 sectors/track, 22016 cylinders
Units = シリンダ数 of 2048 * 512 = 1048576 bytes

デバイス Boot      Start         End      Blocks   Id  System
/dev/sdc1               1       22016    22544368   83  Linux

Disk /dev/sdd: 23.0 GB, 23085449216 bytes
64 heads, 32 sectors/track, 22016 cylinders
Units = シリンダ数 of 2048 * 512 = 1048576 bytes

デバイス Boot      Start         End      Blocks   Id  System
/dev/sdd1               1       22016    22544368   83  Linux

Disk /dev/sde: 2147 MB, 2147483648 bytes
67 heads, 62 sectors/track, 1009 cylinders
Units = シリンダ数 of 4154 * 512 = 2126848 bytes

デバイス Boot      Start         End      Blocks   Id  System
/dev/sde1               1        1009     2095662   83  Linux
[root@discus1 ˜]#
[root@discus1 ˜]# (cd /dev/disk/by-path; ls -l *openfiler* | awk '{FS=" "; print $9 " " $10 " " $11}')
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm1 -> ../../sdb
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm1-part1 -> ../../sdb1
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm2 -> ../../sdd
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm2-part1 -> ../../sdd1
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm3 -> ../../sdc
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm3-part1 -> ../../sdc1
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm4 -> ../../sda
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm4-part1 -> ../../sda1
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.crs -> ../../sde
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.crs-part1 -> ../../sde1
[root@discus1 ˜]#

udevが作成したパーティションに対して新たなデバイス名をruleに従い作成してくれている。(^^..

[root@discus1 ˜]# ls -l /dev/iscsi/*/*
lrwxrwxrwx 1 root root  9  9月 30 17:52 /dev/iscsi/asm1/part -> ../../sdd
lrwxrwxrwx 1 root root 10  9月 30 18:01 /dev/iscsi/asm1/part1 -> ../../sdd1
lrwxrwxrwx 1 root root  9  9月 30 17:52 /dev/iscsi/asm2/part -> ../../sde
lrwxrwxrwx 1 root root 10  9月 30 18:01 /dev/iscsi/asm2/part1 -> ../../sde1
lrwxrwxrwx 1 root root  9  9月 30 17:52 /dev/iscsi/asm3/part -> ../../sdb
lrwxrwxrwx 1 root root 10  9月 30 18:01 /dev/iscsi/asm3/part1 -> ../../sdb1
lrwxrwxrwx 1 root root  9  9月 30 17:52 /dev/iscsi/asm4/part -> ../../sda
lrwxrwxrwx 1 root root 10  9月 30 18:01 /dev/iscsi/asm4/part1 -> ../../sda1
lrwxrwxrwx 1 root root  9  9月 30 17:52 /dev/iscsi/crs/part -> ../../sdc
lrwxrwxrwx 1 root root 10  9月 30 18:01 /dev/iscsi/crs/part1 -> ../../sdc1
[root@discus1 ˜]# 

特に問題もなく作成できたようだ。

次回へつづく

Mac de Oracle - １０万円未満 de RAC (11g編）#5

つづきです。今回はOracle RACノード側でiSCSIボリュームの構成を行う。

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成　その１
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

５．Oracle RACノードでのiSCSIボリュームの構成 尚、iscsi-targetがOpenfiler2.3でもiscsi-initiator側の設定手順には違いはないのでUS OTNのBuild Your Own Oracle RAC Clusters on Oracle Enterprise Linux and iSCSI - 11.COnfigure iSCSI Volumes on Oracle Rac Nodesも参照のこと。 注）iscsi-initiatorの構成はOracle RACの全ノードで行うがパーティションの作成は１ノードだけで行う。 ・iscsi-initiator-utilsのインストール

rpmでやるのもいいが今回はyumを使ってiscsi-initiator-utilsパッケージをインストールする。Oracle RACの全ノードのrootユーザで実行する。（以下のdiscus1で実施したログ。）


(20101013訂正というか追記)
以下の例ではiscsidを自動起動にしていますが、CentOS5.5ではiscsiを自動起動にすればiscsi起動・停止時にiscsidの起動・停止も行っているのでCentOS5.5ではiscsidの自動起動は不要。CentOS5.4以前はどうか未確認なので、/etc/rc.d/init.d/iscsiを確認するか、service iscsi start/stopでiSCSI deamonが起動・停止されるか確認するよいかと。

[root@discus1 ˜]# yum list iscsi-initiator-utils
Available Packages
iscsi-initiator-utils.i386               6.2.0.868-0.7.el5      base            
[root@discus1 ˜]# yum -y install iscsi-initiator-utils
Setting up Install Process
Parsing package install arguments
Resolving Dependencies
--> Running transaction check
---> Package iscsi-initiator-utils.i386 0:6.2.0.868-0.7.el5 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Installing:
 iscsi-initiator-utils   i386       6.2.0.868-0.7.el5  base              550 k

Transaction Summary
=============================================================================
Install      1 Package(s)         
Update       0 Package(s)         
Remove       0 Package(s)         

Total download size: 550 k
Downloading Packages:
(1/1): iscsi-initiator-ut 100% |=========================| 550 kB    00:00     
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing: iscsi-initiator-utils        ######################### [1/1] 

Installed: iscsi-initiator-utils.i386 0:6.2.0.868-0.7.el5
Complete!
[root@discus1 ˜]# service iscsid start
Turning off network shutdown. Starting iSCSI daemon: [  OK  ]
                                                     [  OK  ]

[root@discus1 ˜]# chkconfig iscsid on
[root@discus1 ˜]# chkconfig iscsi on

 

/etc/iscsi/initiatorname.iscsiの設定。
分かり易いIQNにしておいたほうがいいですよ。RACを構成する全ノードで実施

[root@discus1 ˜]# cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1994-05.jp.macdeoracle:discus1
[root@discus1 ˜]# 

[root@discus2 ˜]# cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1994-05.jp.macdeoracle:discus2
[root@discus2 ˜]# 

・iscsi-targetの検出

以下のコマンドでiscsi-targetの検出しそのIQNのリストしてくれる。-p にはiscsi-targetのip addressを指定する。以下の例はdiscus1からarowana-privに存在するiscsi-targetを検出した例。尚、この操作はRACの全ノードのrootユーザで実施する。

[root@discus1 ˜]# iscsiadm -m discovery -t sendtargets -p 192.168.2.5
192.168.2.5:3260,1 iqn.2006-01.com.openfiler:tsn.asm1
192.168.2.5:3260,1 iqn.2006-01.com.openfiler:tsn.asm2
192.168.2.5:3260,1 iqn.2006-01.com.openfiler:tsn.asm3
192.168.2.5:3260,1 iqn.2006-01.com.openfiler:tsn.asm4
192.168.2.5:3260,1 iqn.2006-01.com.openfiler:tsn.crs

・iscsi-targetへの手動接続

iscsi-target側では認証設定はしていないので以下のコマンドで手動ログインする。
-Tで接続するiscsi-targetのIQNを指定する。-pはiscsi-targetが起動しているホストのhostname又はip addressを指定する。詳細はこの操作はRACの全ノードのrootユーザで実施する。

[root@discus1 ˜]# iscsiadm -m node -T iqn.2006-01.com.openfiler:tsn.asm1 -p 192.168.2.5 -l
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:tsn.asm1, portal: 192.168.2.5,3260]
Login to [iface: default, target: iqn.2006-01.com.openfiler:tsn.asm1, portal: 192.168.2.5,3260]: successful
[root@discus1 ˜]# iscsiadm -m node -T iqn.2006-01.com.openfiler:tsn.asm2 -p 192.168.2.5 -l
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:tsn.asm2, portal: 192.168.2.5,3260]
Login to [iface: default, target: iqn.2006-01.com.openfiler:tsn.asm2, portal: 192.168.2.5,3260]: successful
[root@discus1 ˜]# iscsiadm -m node -T iqn.2006-01.com.openfiler:tsn.asm3 -p 192.168.2.5 -l
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:tsn.asm3, portal: 192.168.2.5,3260]
Login to [iface: default, target: iqn.2006-01.com.openfiler:tsn.asm3, portal: 192.168.2.5,3260]: successful
[root@discus1 ˜]# iscsiadm -m node -T iqn.2006-01.com.openfiler:tsn.asm4 -p 192.168.2.5 -l
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:tsn.asm4, portal: 192.168.2.5,3260]
Login to [iface: default, target: iqn.2006-01.com.openfiler:tsn.asm4, portal: 192.168.2.5,3260]: successful
[root@discus1 ˜]# iscsiadm -m node -T iqn.2006-01.com.openfiler:tsn.crs -p 192.168.2.5 -l
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:tsn.crs, portal: 192.168.2.5,3260]
Login to [iface: default, target: iqn.2006-01.com.openfiler:tsn.crs, portal: 192.168.2.5,3260]: successful
[root@discus1 ˜]# 

・iscsi-targetへの自動ログインの構成

iscsiadmコマンドでiscsi-targetへの自動ログインができるようにしておく。この操作はRACの全ノードのrootユーザで実施する。

[root@discus1 ˜]# 
[root@discus1 ˜]# iscsiadm -m node -T iqn.2006-01.com.openfiler:tsn.asm1 -p 192.168.2.5 --op update -n node.startup -v automatic
[root@discus1 ˜]# iscsiadm -m node -T iqn.2006-01.com.openfiler:tsn.asm2 -p 192.168.2.5 --op update -n node.startup -v automatic
[root@discus1 ˜]# iscsiadm -m node -T iqn.2006-01.com.openfiler:tsn.asm3 -p 192.168.2.5 --op update -n node.startup -v automatic
[root@discus1 ˜]# iscsiadm -m node -T iqn.2006-01.com.openfiler:tsn.asm4 -p 192.168.2.5 --op update -n node.startup -v automatic
[root@discus1 ˜]# iscsiadm -m node -T iqn.2006-01.com.openfiler:tsn.crs -p 192.168.2.5 --op update -n node.startup -v automatic
[root@discus1 ˜]# 

・ローカルデバイス名の作成

iSCSIでは再起動する度にiscsi-targetにマッピングされるSCSIデバイス名が変ってしまうことがある。（少々面倒）。
ということでudevを利用してデバイス名を固定しておきましょう。そのほうが使い易いですから。
たとえば、ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm1が /dev/sdaにマッピングされているが再起動すると/dev/sdbにマッピングされたりすることがある。

[root@discus1 ˜]# (cd /dev/disk/by-path; ls -l *openfiler* | awk '{FS=" "; print $9 " " $10 " " $11}')
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm1 -> ../../sda
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm2 -> ../../sdb
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm3 -> ../../sdc
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm4 -> ../../sdd
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.crs -> ../../sde
[root@discus1 ˜]# 

udevについては以下のドキュメントが参考になるのではないだろうか。
Udev on Fedora（英語) - http://docs.fedoraproject.org/udev/
Writing udev rules（英語） - http://www.reactivated.net/writing_udev_rules.html 日本語訳も見つけたのでメモ代わりに・・（翻訳してくださっている方々に感謝！）
Udev on Fedora（日本語訳） - http://mux03.panda64.net/docs/udev_on_fedora_ja.html
Writing udev rules（日本語訳） - http://www.gentoo.gr.jp/transdocs/udevrules/udevrules.html

udevを利用して固定的なデバイス名をiscsi-targetに割り当てる。内容は元ネタと同じです。（以下の操作はRACの全ノードのrootユーザで実施する。

[root@discus1 ˜]# cat /etc/udev/rules.d/55-openiscsi.rules
KERNEL=="sd*", BUS=="scsi", PROGRAM="/etc/udev/scripts/iscsidev.sh %b",SYMLINK+="iscsi/%c/part%n"
[root@discus1 ˜]# 
[root@discus1 ˜]# cd /etc/udev/scripts
[root@discus1 scripts]# ls -l iscsidev.sh
-rwxr-xr-x 1 root root 334  9月 30 17:50 iscsidev.sh
[root@discus1 scripts]# cat iscsidev.sh
#!/bin/sh

# FILE: /etc/udev/scripts/iscsidev.sh

BUS=${1}
HOST=${BUS%%:*}

[ -e /sys/class/iscsi_host ] || exit 1

file="/sys/class/iscsi_host/host${HOST}/device/session*/iscsi_session*/targetname"

target_name=$(cat ${file})

# This is not an open-scsi drive
if [ -z "${target_name}" ]; then
   exit 1
fi

echo "${target_name##*.}"
[root@discus1 scripts]# 
[root@discus1 scripts]# chmod 755 iscsidev.sh
[root@discus1 scripts]# cd
[root@discus1 ˜]# service iscsi stop
Logging out of session [sid: 1, target: iqn.2006-01.com.openfiler:tsn.asm1, portal: 192.168.2.5,3260]
Logging out of session [sid: 2, target: iqn.2006-01.com.openfiler:tsn.asm2, portal: 192.168.2.5,3260]
Logging out of session [sid: 3, target: iqn.2006-01.com.openfiler:tsn.asm3, portal: 192.168.2.5,3260]
Logging out of session [sid: 4, target: iqn.2006-01.com.openfiler:tsn.asm4, portal: 192.168.2.5,3260]
Logging out of session [sid: 5, target: iqn.2006-01.com.openfiler:tsn.crs, portal: 192.168.2.5,3260]
Logout of [sid: 1, target: iqn.2006-01.com.openfiler:tsn.asm1, portal: 192.168.2.5,3260]: successful
Logout of [sid: 2, target: iqn.2006-01.com.openfiler:tsn.asm2, portal: 192.168.2.5,3260]: successful
Logout of [sid: 3, target: iqn.2006-01.com.openfiler:tsn.asm3, portal: 192.168.2.5,3260]: successful
Logout of [sid: 4, target: iqn.2006-01.com.openfiler:tsn.asm4, portal: 192.168.2.5,3260]: successful
Logout of [sid: 5, target: iqn.2006-01.com.openfiler:tsn.crs, portal: 192.168.2.5,3260]: successful
Stopping iSCSI daemon: /etc/init.d/iscsi: line 33:  8989 強制終了            /etc/init.d/iscsid stop
[root@discus1 ˜]#                                          [  OK  ]
[root@discus1 ˜]# 
[root@discus1 ˜]# service iscsi start
iscsid が停止していますが PID ファイルが残っています
Turning off network shutdown. Starting iSCSI daemon:       [  OK  ]
                                                           [  OK  ]
iSCSI ターゲットを設定中: Logging in to [iface: default, target: iqn.2006-01.com.openfiler:tsn.asm4, portal: 192.168.2.5,3260]
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:tsn.asm1, portal: 192.168.2.5,3260]
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:tsn.asm3, portal: 192.168.2.5,3260]
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:tsn.asm2, portal: 192.168.2.5,3260]
Logging in to [iface: default, target: iqn.2006-01.com.openfiler:tsn.crs, portal: 192.168.2.5,3260]
Login to [iface: default, target: iqn.2006-01.com.openfiler:tsn.asm4, portal: 192.168.2.5,3260]: successful
Login to [iface: default, target: iqn.2006-01.com.openfiler:tsn.asm1, portal: 192.168.2.5,3260]: successful
Login to [iface: default, target: iqn.2006-01.com.openfiler:tsn.asm3, portal: 192.168.2.5,3260]: successful
Login to [iface: default, target: iqn.2006-01.com.openfiler:tsn.asm2, portal: 192.168.2.5,3260]: successful
Login to [iface: default, target: iqn.2006-01.com.openfiler:tsn.crs, portal: 192.168.2.5,3260]: successful
                                                           [  OK  ]
[root@discus1 ˜]# 
[root@discus1 ˜]# (cd /dev/disk/by-path; ls -l *openfiler* | awk '{FS=" "; print $9 " " $10 " " $11}')
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm1 -> ../../sda
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm2 -> ../../sdb
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm3 -> ../../sdc
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.asm4 -> ../../sdd
ip-192.168.2.5:3260-iscsi-iqn.2006-01.com.openfiler:tsn.crs -> ../../sde
[root@discus1 ˜]# 
[root@discus1 ˜]# ls -l /dev/iscsi/*/*
lrwxrwxrwx 1 root root  9  9月 30 17:52 /dev/iscsi/asm1/part -> ../../sda
lrwxrwxrwx 1 root root  9  9月 30 17:52 /dev/iscsi/asm2/part -> ../../sdb
lrwxrwxrwx 1 root root  9  9月 30 17:52 /dev/iscsi/asm3/part -> ../../sdc
lrwxrwxrwx 1 root root  9  9月 30 17:52 /dev/iscsi/asm4/part -> ../../sdd
lrwxrwxrwx 1 root root  9  9月 30 17:52 /dev/iscsi/crs/part -> ../../sde
[root@discus1 ˜]# 

これでiscsi-targetとローカルデバイス名の固定的なマッピングができた。

iscsi-targetとローカルデバイス名の対応
iscsi-target名	ローカルデバイス名
iqn.2006-01.com.openfiler:tsn.asm1	/dev/iscsi/asm1/part
iqn.2006-01.com.openfiler:tsn.asm2	/dev/iscsi/asm2/part
iqn.2006-01.com.openfiler:tsn.asm3	/dev/iscsi/asm3/part
iqn.2006-01.com.openfiler:tsn.asm4	/dev/iscsi/asm4/part
iqn.2006-01.com.openfiler:tsn.crs	/dev/iscsi/crs/part

chkconigで確認しておく。念のため。（RACの全ノードで）
(20101013訂正というか追記)
以下の例ではiscsidを自動起動にしていますが、CentOS5.5ではiscsiを自動起動にすればiscsi起動・停止時にiscsidの起動・停止も行っているのでCentOS5.5ではiscsidの自動起動は不要。CentOS5.4以前はどうか未確認なので、/etc/rc.d/init.d/iscsiを確認するか、service iscsi start/stopでiSCSI deamonが起動・停止されるか確認するよいかと。

[root@discus1 ˜]# chkconfig --list iscsid
iscsid          0:off   1:off   2:off   3:on    4:on    5:on    6:off
[root@discus1 ˜]# chkconfig --list iscsi
iscsi           0:off   1:off   2:off   3:on    4:on    5:on    6:off
[root@discus1 ˜]# 

上記操作後openfiler storage control centerのiscsi-target-status画面では以下のようなに接続状況を確認できるようになる。

次回へつづく 子供寝かしつけようと一緒に横に寝ていると、私が先に寝ちゃうんだなこれが・・・、予定していたことは早起きしてやるようになったりして。。w

Mac de Oracle - １０万円未満 de RAC (11g編）#4

つづきです。今回はOpenfiler2.3によるiSCSIボリュームの構成を行う。

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

４．Openfiler2.3によるiSCSIボリュームの構成

考え方はOpenfiler2.1と同じなのだが管理画面のレイアウトが少々変更されている。

https://hostname or ip address:446/

でOpenfiler Storage Control Centerへアクセスする。

・Openfiler Strorage Control Center へのLogin

・管理者パスワードの変更

管理者のアカウントは、openfiler、インストール直後のデフォルトパスワードは。passwordとなっている。(openfiler2.1と同じ。）
ログインするとSystem Overview画面が表示される。

次にAccountsタブをクリック->Accounts SectionペインのAdmin passwordをクリック->Change Administrator Password画面でパスワードを変更する。

・iSCSI target serverの有効化。

ここで一旦ログアウトし新しいパスワードでログインし直してからServicesタブをクリック->Manage Services画面でiSCSI target serverのModification列にあるEnableをクリックしてiSCSI target serverを起動する。

iscsi-targetの状態を確認（rootユーザで）

[root@arowana ˜]# service iscsi-target status
ietd (pid 3354) is running...
[root@arowana ˜]# 

・ネットワークアクセスの構成

Systemタブをクリック->System sectionペインのNetwork Setupをクリック->Network Access ConfigurationでiSCSIをアクセスするノードを定義する。
Name列には各ノードのhostnameを、Network/Host列にはインターコネクトに利用するIPアドレスを設定する。Netmaskは255.255.255.255、TypeはShareを設定する。

・ボリュームグループの構成

今回も以前のように１つのボリュームグループを作成し、そのグループにcrs用の論理ボリューム１つ、ASM用の論理ボリューム４つを作成する。
Volumeタブ->Volume sectionペインでBlock Device Management画面に遷移する

IDEディスクが２本ありiSCSI向けに/dev/hda に６９ＧＢ、/dev/hdb に１９ＧＢの空きがある。各パーティションのサイズは、６９ＧＢ、１９ＧＢ、合計で８８ＧＢをcrs用の論理ボリュームに２ＧＢ、ASM用の４つの論理ボリュームに各２１．５ＧＢを割り当てる。

Partitionの作成

/dev/hda に６９ＧＢ、/dev/hdb に１９ＧＢの空きがあるのでそれぞれをパーティションとして割り当てる。
以下の例では/dev/hda4及び/dev/hdb1の２つのパーティションを割り当てた。
Block Device Management画面のEdit Diskの各Diskをクリックしてパーティションを追加する。ちなみに、viewをクリックすると作成済みパーティションの一覧が確認できる。

/dev/hda4に約６９ＧＢのパーティションを作成している様子。同様の手順で/dev/hdb1に約１９ＧＢのパーティションを作成する。

Volume Groupの作成

Volumes sectionペインのVolume Groupをクリックしてボリュームグループを作成する。
今回はrac1というボリュームグループを作成し前ステップで割り当てた/dev/hda4と/dev/hdb1の２パーティションをボリュームグループrac1へ割り当てる。（どのボリュームグループにも属さないパーティションが自動的にリストされるので必要なパーティションを選択するだけ。）
※作成されたボリュームグループの容量が８８ＧＢあることが確認できる。

論理ボリュームの割当

Volumes sectionペインのAdd Volumeをクリックして前ステップで作成したボリュームグループへ論理ボリュームを割り当てる。
ボリュームグループrac1に割り当てた８８ＧＢをcrs向け論理ボリューム（２ＧＢ）及び、ASM向け論理ボリューム（２１．５ＧＢ＊４ボリューム）の５つの論理ボリュームへ割り振る。
各論理ボリュームのFilesystem/Volume typeはiSCSIを選択する。

割り当てた論理ボリューム名及び名称は次の通り。crs:2GB/asm1:21.5GB/asm2:21.5GB/asm3:21.5GB/asm4:21.5GB

iSCSI Target Qualified Name(IQN)の設定 (2010/10/4訂正)

今回はiqn.2006-01.com.oepnfiler:arowanaというiSCSI target rualified nameにした。今回は、iqn.2006-01.com.openfiler:tsn.crs/iqn.2006-01.com.openfiler:tsn.asm1/iqn.2006-01.com.openfiler:tsn.asm2/iqn.2006-01.com.openfiler:tsn.asm3/iqn.2006-01.com.openfiler:tsn.asm4という５つのiSCSI Targetを作成した。Volumeタブ->Volumes sectionペイン->iSCSI targets->Target Configurationタブで表示されるVolumes:iSCSI Targets画面で行う。

Network ACLの設定

前操作で設定したIQNに対してNetwork ACLを設定する。ネットワークアクセスの構成で登録したノードがリストされているのでAccess列をAllowに変更する。
設定はVolumeタブ->Volumes sectionペイン->iSCSI targets->Network ACLタブで表示される画面で行う。

LUN Mapping (2010/10/4訂正)

論理ボリュームの割当操作で割り当てた各論理ボリューム(crs/asm1/asm2/asm3/asm4)をiSCSI Target Qualified Name(IQN)の設定で作成した各iSCSI Target(iqn.2006-01.com.openfiler:tsn.crs/iqn.2006-01.com.openfiler:tsn.asm1/iqn.2006-01.com.openfiler:tsn.asm2/iqn.2006-01.com.openfiler:tsn.asm3/iqn.2006-01.com.openfiler:tsn.asm4)のLUN Id.=0にマッピングしていく、crs/asm1/asm2/asm3/asm4の順で割り当てる。する。

設定はVolumeタブ->Volumes sectionペイン->iSCSI targets->LUN Mappingタブで表示される画面で行う。Map New LUN to target:にリストされている論理ボリュームをMapボタンをクリックしてマッピングするだけ。簡単！。

最後にiscsi-targetを再起動して設定完了！

[root@arowana ˜]# service iscsi-target restart
Stopping iSCSI target service: ......                      [  OK  ]
Starting iSCSI target service:                             [  OK  ]
[root@arowana ˜]# service iscsi-target status
ietd (pid 7455) is running...
[root@arowana ˜]# 

再度、Openfiler storage Control Centerにログインし、Status->Status sectionペインのiSCSI Targetをクリックすると以下のスクリーンショットのようになる。
これでiSCSI Target側の準備は完了。

ふ〜〜今回は長かった〜〜。:) 次回へつづく

Mac de Oracle - １０万円未満 de RAC (11g編）#3

つづきです。今回はOpenfiler2.3をiscsi-targetにするPCへインストールする。

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

３．Openfiler2.3のインストール

Openfiler2.3は以下のisoイメージをダウンロードして利用する
・openfiler-2.3-x86-disc1.iso

ダウンロードしたisoイメージをCDに焼く。MacでisoイメージをCDに焼く方法は以前の記事を参考に。

・インストール
Openfiler2.3のインストールもOpenfiler2.1のインストール手順と全く同じであった。インストールするPCも以前使用したであるためインストール及びネットワーク構成は「１０万円 de RAC」のエントリを参照してもらいたい。

但し、以前と比べ改善点があった。Openfiler2.1では同一PCに複数のNICがある場合、より高速なNICをeth0として認識していたようなのだが（そのような結果になっていた）、Openfier2.3ではオンボードのNICをeth0、追加したNICをeth1と認識くれたのでお陰で、以前のように一度認識されたNICの構成を手動で入れ替えるという操作は不要だった。(^^)

参考：openfiler graphical installation

おっと、忘れるところだった。Openfilerをインストールしたマシンを再起動する前にやっておきたい事が１つ。それは・・・自動アップデートを止めておくこと。。
以前、自動更新されiscsi-targetが消えてしまうという事態が発生したためだ。今回も念のためconaryによる自動アップデートを行わないようにしておく。（現時点では自動アップデートは不要なので）

お手軽な方法は、/etc/conaryrcの定義を全てコメントアウトしてしまう方法。

[root@arowana ˜]# cat /etc/conaryrc
#commeted out
#installLabelPath openfiler.rpath.org@ofns:2 conary.rpath.com@rpl:1 raa.rpath.org@rpath:raa-2
#pinTroves kernel.*
#autoResolve True
#includeConfigFile /etc/conary/config.d/*
[root@arowana ˜]# 

インストールに成功していれば、ブラウザでhttps://hostname or ip address:446/へアクセスすると以下のようなログイン画面を見る事ができるだろう。


次回へつづく

Mac de Oracle - １０万円未満 de RAC (11g編）#2

以下に示した内容に沿って書いていこうと考えているが、実際に行った作業で１０万円 de RACで書いた内容と同じ部分がほとんど。結局、以前の記事参照なんて部分が多くなりそうだ。。。(^^
Openfiler2.3の管理画面が2.2の頃とは違っているのOpenfiler関連部分が中心になるかもしれません。

1. ハードウェア構成と価格（Mac De Oracle - １０万円 de RAC #1とMac De Oracle - １０万円 de RAC #5参照のこと）
2. Linux (CentOS 5.2)のインストール
3. Openfiler2.3のインストール
4. Openfiler2.3によるiSCSIボリュームの構成
5. Oracle RACノードでのiSCSIボリュームの構成
6. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
7. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
8. hangcheck-timerカーネル・モジュールの構成
9. Oracle RACノード間リモートアクセスの構成
10. Oracle RACノード構成ファイルの確認
11. Oracle Cluster File System (OCFS2)のインストール及び構成
12. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
13. Oracle11g R1 インストール事前作業
14. Oracle11g R1 Clusterwareのインストール
15. Oracle11g R1 Database softwareのインストール
16. Oracle11g R1 examplesのインストール
17. TNS Listenerの構成
18. Oracle Cluster databaseの作成
19. Oracle Net Serviceの確認
20. Oralce RAC ClusterとDatabase構成の確認
21. Clusterの開始と停止の確認
22. Oracle Clusterwareプロセス・モニター・デーモンの構成
23. 簡単なTransparent Application Failover (TAF)の確認
24. MacOSXからの接続確認（Mac De Oracleではお約束！なので）

---

２．CentOS5.2のインストール

２台のDELL Optiplex GX260 CPU:P4 2.4Ghz/DISK:20GB（この時点では搭載メモリは５１２ＭＢ）へCentOS5.2をインストールしネットワークの構成まで行う。

・CentOS5.2のダウンロード（CDドライブしかない機種なのでISOイメージをダウンロード）
　CentOS-5.2-i386-bin-1of6.iso
　CentOS-5.2-i386-bin-2of6.iso
　CentOS-5.2-i386-bin-3of6.iso
　CentOS-5.2-i386-bin-4of6.iso
　CentOS-5.2-i386-bin-5of6.iso
　CentOS-5.2-i386-bin-6of6.iso

MacでISOイメージのCDを焼く方法は以前の記事を参考に。

CentOS5.2になったからといっても特にインストール方法に大きな違いはなく、以前使っていたH/Wを流用していることもありパーティションサイズやネットワーク構成も以前書いた内容と全く同じなので詳細は以前の記事及び、US OTNの記事を参照のこと。
（今回、CentOS5.2を使っているがUS OTNの記事ではOracle Enterprise Linuxを利用している。どちらもRHEL5互換なのでインストールするパッケージも同じようだ。まだOracle Enterprise Linuxをインストールした事がないので詳しく書くだけの知識はないのですがね・・・。）

ネットワーク構成について少々追記しておくと。RACを構成する２ノードとも、DHCPは利用せず、固定IP。また、gateway及び、DNSの ipアドレスは、192.168.1.1　とした。（配置図参照のこと。）また、IPv6はOFFにしてある。

RACを構成するノード１ (hostname=discus1.macdeoracle.jp)
device	ip address	sub-netmask	備考
eth0	192.168.1.3	255.255.255.0	パブリックネットワーク用、100メガビット
eth1	192.168.2.3	255.255.255.0	プライベートネットワーク用、ギガビット
RACを構成するノード２ (hostname=discus2.macdeoracle.jp)
device	ip address	sub-netmask	備考
eth0	192.168.1.4	255.255.255.0	パブリックネットワーク用、100メガビット
eth1	192.168.2.4	255.255.255.0	プライベートネットワーク用、ギガビット

・リリースノートにも記載されているが、SELinuxはPermissiveモードにすること。
また、FirewallはDisableにしておく。

Openfiler2.3をインストールするPCも含めたネットワークの構成は以下。（内容は以前と同じなのですが念のため）

[root@discus1 ˜]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain localhost

# Public Networks - (eth0)
192.168.1.3     discus1.macdeoracle.jp  discus1
192.168.1.4     discus2.macdeoracle.jp  discus2
192.168.1.5     arowana.macdeoracle.jp  arowana

# Private Network - (eth1)
192.168.2.3     discus1-priv.macdeoracle.jp     discus1-priv
192.168.2.4     discus2-priv.macdeoracle.jp     discus2-priv
192.168.2.5     arowana-priv.macdeoracle.jp     arowana-priv

# Public Virtual IP(VIP) address for - (eth0)
192.168.1.100   discus1-vip.macdeoracle.jp      discus1-vip
192.168.1.101   discus2-vip.macdeoracle.jp      discus2-vip
[root@discus1 ˜]# 

次回へつづく

Mac de Oracle - １０万円未満 de RAC (11g編）#1

まずは環境から。
（前回のシリーズの環境をそのまま流用。但し、各PCのメモリ不足が明確になった時点で各５１２ＭＢ増設し１ＧＢとする。）

Hardware
PC2100 512MBのメモリ２枚（合計２，９６０円）以外は既存のH/Wを流用したので、現在の価値は５万円にも満たない。。。。はず？！

(1) PC - RAC用 - DELL Optiplex GX260 CPU:P4 2.4Ghz RAM:512MB * 1
　　（尚、DBCA実行時にメモリ不足となったので。最終的には各１GBのメモリと搭載させる。）

(2) PC - iSCSI用 - DELL PowerEdge SC600 CPU : P4 1.8Ghz RAM:769MB * 1

(3) DISPLAY - DELL 15inch 液晶ディスプレイ　* 1

(4) KEYBOARD, MOUSE -- DELL製　* 2セット

(5) HUB - Corega CG-SW05TXPL(100base for public)
　　Corega CG-SW05GTPLB(1000base for interconnect) 各１

注）DISPLAY、Keyboard、mouseはPC数より少ないが必要に応じて繋ぎ替えて利用する。

Software
・Oracle11g 11.1.0.6.0 EE for Linux x86
・CentOS5.2 - 2.6.18-92.el5
・Openfiler2.3 - Final Release
・OCFS2(Oracle Cluster File System 2) - 1.4.1-1
・Oracle Cluster Verification Utility - Linux x86(Aug 2008)
・Oracle ASMLib2.0 for RHEL5
　(oracleasm-support-2.0.4-1.el5.i386
　oracleasmlib-2.0.3-1.el5.i386
　oracleasm-2.6.18-92.el5-2.0.4-1.el5.i686.rpm)

尚、Openfiler2.2(respin 2)及びOracle Enterprise Linuxを利用しているUS OTN記事ー「Build Your Own Oracle RAC Cluster on Oracle Enterprise Linux and iSCSI」も参考にしたが、Openfiler2.2と2.3では管理画面構成が異なる点、Oracle Enterprise Linuxは正式にサポートされているプラットフォームだがCentOS5.2はサポートされていないプラットフォームである点等は異なる。

そして・・・Mac De OracleですからLinuxのインストール以外はMacOSXのxtermから全て行う。（お約束）w

今回はPowerMac G5(PPC)とMacBook Pro(Intel)を利用するが、インストールなど構成はPowerMac G5から行う。
また、MacOSX用Oracle Clientは以下のOracle Instant Clientを利用する。
Oracle Instant Client for MacOSX (PPC) 10.1.0.3.0
Oracle Instant Client for MacOSX (Intel) 10.2.0.4.0

ClientにするMacも含めた配置図は以下の通り。

---

バックナンバー
１０万円未満 de RAC (Oracle11g R1編)

１０万円未満 de RAC (Oracle11g R1編)

いや〜予定外だ。。
キールズバーへベルギービールを飲みに行く予定だったのだが・・・。息子が風邪をひいたようでたまにミルクを咳と一緒に嘔吐してしまったり（実際は元気バリバリで少し大人しくしてろよ！という状態なので心配はなさそうなのですがね。）で予定はキャンセル。

ということで今日は予てより準備を進めていたOracle11g R1 for Linux x86、Openfiler2.3、OCFS2 1.4.1-1、Oracle ASMLib 2.0、それにCentOS5.2を使ったRAC構築「１０万円 de RAC」改め「１０万円未満 de RAC (11g編）」として復活。w。

もちろんCentOS5.2でOracle11g for Linux x86がサポートされていないのはいつも承知のうえなのでサポートされているプラットフォーム以外では手を出したくない方はスルーしてくださいね。:)
また、簡単なテストや動作確認向けのRAC環境ですのでご注意ください。（推奨されない方法で無理矢理インストールしていますので．．）

以前の環境と同じH/Wを再利用（但し、メモリだけはキツいので作業の途中で増設しました。）したので現在の価値では５万円もしない環境でRACを構築したことになりますね。

OpenFiler2.3/CentOS5.2/ASMLib 2.0.4を利用している上にマシンも非力なので、OTN USのBuild Your Own Oracle RAC Cluster on Oracle Enterprise Linux and iSCSIという記事より多少チャレンジングな内容になっているかもしれません。:)

今日はここまで。次回へつづく。

さて・・

Oracle11g、MySQL5.0、PostgreSQL8.3、（FireBird2.1もやるか）、それにOpenfiler2.3なども利用して旧リリースで試していたことを再度試しておこうかそろそろ。
たとえば、HeterogeneousとRACのネタなど。まず、RACからやりますか．．。

ちょいと迷惑だったストアドファンクション（つづき）

前回の続きです。

ところで何がちょっと迷惑だったのか？

まずは、マニュアルをご覧ください。

もうお分かりですよね！

例の関数、戻り値としてレコード型を返してくれるのはよいのですが、該当データが存在しなかった場合にNULLを返す作りになっています。そのレコード型はどのように比較すれば該当データが存在しないのか外部の仕様からは全く見えません。（当然、レコードがNULLであるか判定する関数も用意されていません。）

レコード型がNULLかテストできないので以下のようなコードは書けないのですよ！

SCOTT> set serveroutput on size 100000
SCOTT> l
  1  DECLARE
  2    members inconvenient_package.membersType;
  3  BEGIN
  4    members := inconvenient_package.inconvenient_function(99);
  5      IF members IS NULL THEN
  6      RAISE NO_DATA_FOUND;
  7    ELSE
  8      DBMS_OUTPUT.PUT_LINE('Dept name/id:'||members.deptname||'/'||TO_CHAR(members.deptno));
  9      FOR i IN members.employees.FIRST..members.employees.LAST LOOP
 10        DBMS_OUTPUT.PUT_LINE(' -- '||members.employees(i).ename);
 11      END LOOP;
 12    END IF;
 13* END;
SCOTT> /
  IF members IS NULL THEN
     *
行5でエラーが発生しました。:
ORA-06550: 行5、列6:
PLS-00306: 'IS NULL'の呼出しで、引数の数または型が正しくありません。 
ORA-06550: 行5、列3:PL/SQL: Statement ignored

利用する側からすると、該当データが存在しない場合のコードをどうかいて良いのかAPIからは判断がつかない（該当関数のソースコードを読まない限り判断できない）。
この点がちょいと迷惑だったわけ。

例の関数をそのまま利用した場合以下のようなコードを書かないと該当データが存在しないことを判定できない。
（赤太字部分は利用する関数のコード及びこの関数がアクセスしている表定義を見て判断する必要がある。面倒くさい！　なんでAPI見ただけでコード書く事できないような共通関数があるの〜〜〜。）

SCOTT> l
  1  DECLARE
  2    members inconvenient_package.membersType;
  3  BEGIN
  4    members := inconvenient_package.inconvenient_function(99);
  5    IF members.employees.COUNT = 0
  6       OR members.deptno IS NULL
  7    THEN
  8      DBMS_OUTPUT.PUT_LINE('該当データが存在しません.');
  9    ELSE
 10      DBMS_OUTPUT.PUT_LINE(
 11        'Dept name/id:'
 12        ||members.deptname
 13        ||'/'||TO_CHAR(members.deptno)
 14      );
 15      FOR i IN members.employees.FIRST..members.employees.LAST LOOP
 16        DBMS_OUTPUT.PUT_LINE(' -- '||members.employees(i).ename);
 17      END LOOP;
 18    END IF;
 19* END;
SCOTT> /
該当データが存在しません.

PL/SQLプロシージャが正常に完了しました。


SCOTT> l
  1  DECLARE
  2    members inconvenient_package.membersType;
  3  BEGIN
  4    members := inconvenient_package.inconvenient_function(10);
  5    IF members.employees.COUNT = 0
  6       OR members.deptno IS NULL
  7    THEN
  8      DBMS_OUTPUT.PUT_LINE('該当データが存在しません.');
  9    ELSE
 10      DBMS_OUTPUT.PUT_LINE(
 11        'Dept name/id:'
 12        ||members.deptname
 13        ||'/'||TO_CHAR(members.deptno)
 14      );
 15      FOR i IN members.employees.FIRST..members.employees.LAST LOOP
 16        DBMS_OUTPUT.PUT_LINE(' -- '||members.employees(i).ename);
 17      END LOOP;
 18    END IF;
 19* END;
SCOTT> /
Dept name/id:ACCOUNTING/10
-- CLARK
-- KING
-- MILLER

PL/SQLプロシージャが正常に完了しました。

SCOTT> 

例の関数を修正するとしたら、私個人の趣味だとNO_DATA_FOUND例外はそのままスローするように例外ハンドラー部分を削除しますね。
（ファンクションである必要も無さそうなのでプロシージャにして該当データ無しなどを表すステータスを返す方法を好む方も多いのですが。）

例の関数を修正しNO_DATA_FOUND例外をそのままスローする仕様に変更すれば共通関数のソースコードや関連する表定義まで追っかける必要は無くなりますよ！。w
以下、NO_DATA_FOUNDの例外ハンドラーを削除した例

CREATE OR REPLACE PACKAGE BODY inconvenient_package
AS
  FUNCTION inconvenient_function(iDeptNo IN dept.deptNo%TYPE) 
  RETURN membersType 
  AS
    members membersType;
  BEGIN
    SELECT
      deptNo
     ,dName
    INTO
      members.deptNo
     ,members.deptName
    FROM
      dept
    WHERE
      deptNo = iDeptNo
    ;
    --
    SELECT *
    BULK COLLECT INTO
      members.employees
    FROM
      emp
    WHERE
      deptno = iDeptNo
    ;
    RETURN members;
  -- NO_DATA_FOUND例外ハンドラーを削除して利用する側でハンドリングさせる
  END inconvenient_function;
END inconvenient_package;
/

前述のように修正すれば以下のようなコードを書くだけでよく余計なことに気を使う事もなくなる。（関数のコードやアクセスしている表定義なんて覗かなくても該当データが存在しない場合、NO_DATA_FOUND例外をキャッチするだけで済む）

SCOTT> l
  1  DECLARE
  2    members inconvenient_package.membersType;
  3  BEGIN
  4    BEGIN
  5      members := inconvenient_package.inconvenient_function(10);
  6      DBMS_OUTPUT.PUT_LINE(
  7        'Dept name/id:'
  8        ||members.deptname
  9        ||'/'||TO_CHAR(members.deptno)
 10      );
 11      FOR i IN members.employees.FIRST..members.employees.LAST LOOP
 12        DBMS_OUTPUT.PUT_LINE(' -- '||members.employees(i).ename);
 13      END LOOP;
 14    --
 15    EXCEPTION
 16      WHEN NO_DATA_FOUND THEN
 17        DBMS_OUTPUT.PUT_LINE('該当データが存在しません。');
 18    END;
 19* END;
SCOTT> /
Dept name/id:ACCOUNTING/10
-- CLARK
-- KING
-- MILLER

PL/SQLプロシージャが正常に完了しました。

SCOTT> l
  1  DECLARE
  2    members inconvenient_package.membersType;
  3  BEGIN
  4    BEGIN
  5      members := inconvenient_package.inconvenient_function(99);
  6      DBMS_OUTPUT.PUT_LINE(
  7        'Dept name/id:'
  8        ||members.deptname
  9        ||'/'||TO_CHAR(members.deptno)
 10      );
 11      FOR i IN members.employees.FIRST..members.employees.LAST LOOP
 12        DBMS_OUTPUT.PUT_LINE(' -- '||members.employees(i).ename);
 13      END LOOP;
 14    --
 15    EXCEPTION
 16      WHEN NO_DATA_FOUND THEN
 17        DBMS_OUTPUT.PUT_LINE('該当データが存在しません。');
 18    END;
 19* END;
SCOTT> /
該当データが存在しません。

PL/SQLプロシージャが正常に完了しました。

SCOTT> 

2009/3/25追記:
この例では該当関数の例外ハンドラーを削除しただけですが、もし該当関数やプロシージャの例外ハンドラーでエラーログ（例えばLog4PLSQLとか）などでエラーなどを追跡しやすくするようなロジックを実装していたら・・・・例外ハンドラーを削除することは避けてくださいね。そのような場合は例外ハンドラー内で同じ例外をスローするように変更すべきです（プロジェクトの規約でユーザー定義例外をスローするようにしているところもあります。）
そのようにすることで該当関数から呼び出しもとへ同じ例外がスローされるようになります。具体的な例は別エントリで書く予定。

ついでなのでOTNオンラインマニュアルのURLを変更。（OTNのオンラインマニュアルは訂正が入るとリビジョンが上がりURLまで変っちゃうのが面倒なのよ。ほんと。。URL変らないように工夫してくれないかな。。

ちょいと迷惑だったストアドファンクション

以下のような既存パッケージがあり、共通ファンクションがあるのでこれを利用してくださいとのこと。

仕様書には、該当データが存在する場合はユーザ定義レコード型として定義されているmembersType、該当データが存在しない場合この関数はNULLを返すとある。フムフム。・・・・・でもなんとなく怪しい匂いが。。
で、ソースを除いてみたら以下の”ような”コードだった。どこがちょいと迷惑なのか分かりますか？
（私だったらコードレビュー時に指摘して変更させちゃうんだけどね。そのプロジェクトでは此の手のちょいと迷惑なのがかなりあったのよ。w）
2008/9/12　仕様書には、以下に少々追記

以下の例で利用している表は、Scottスキーマのemp表とdept表です。

CREATE OR REPLACE PACKAGE inconvenient_package 
AS
  TYPE  employeesType IS TABLE OF emp%ROWTYPE INDEX BY BINARY_INTEGER;
  TYPE  membersType IS RECORD (
    deptNo    dept.deptNo%TYPE
   ,deptName  dept.dName%TYPE
   ,employees employeesType
  );
  FUNCTION inconvenient_function(iDeptNo IN dept.deptNo%TYPE) 
    RETURN membersType;
END inconvenient_package;
/
show errors

CREATE OR REPLACE PACKAGE PACKAGE BODY inconvenient_package
AS
  FUNCTION inconvenient_function(iDeptNo IN dept.deptNo%TYPE) 
  RETURN membersType 
  IS
    members membersType;
  BEGIN
    SELECT
      deptNo
     ,dName
    INTO
      members.deptNo
     ,members.deptName
    FROM
      dept
    WHERE
      deptNo = iDeptNo
    ;
    --
    SELECT *
    BULK COLLECT INTO
      members.employees
    FROM
      emp
    WHERE
      deptno = iDeptNo
    ;
    RETURN members;
  EXCEPTION
    WHEN NO_DATA_FOUND THEN
      RETURN NULL;
  END inconvenient_function;
END inconvenient_package;
/
show errors

次回へつづく。

トリガーカスケード制限 #3

前回まではLinux(32bit)環境（CentOS5)だったが気になったのでWindows XP Professional (32bit)でも試してみた。

結果を先に書くがLinux(32bit)と同じくトリガーカスケードの最大値は４９となっている。ついでに調べたところOracle10g for MacOS X Serverでも同じであった。
Oracleのトリガーカスケードの最大値が３２という制限値が正しい？！としても私が普段利用するプラットフォームでは４９で正解のようだ。

以下、Windows XP Professional(32bit)上のログ

SCOTT> 
SCOTT> 
SCOTT> create table master(seq# number);

表が作成されました。

SCOTT> create sequence master_seq
  2  start with 1
  3  increment by 1
  4  nocache
  5  noorder;

順序が作成されました。

SCOTT> 
SCOTT> create or replace trigger ins_cascade_test
  2    after insert on master
  3  begin
  4    insert into master values(master_seq.nextval); 
  5  end; 
  6  /

トリガーが作成されました。

SCOTT> 
SCOTT> select last_number
  2  from user_sequences
  3  where sequence_name = 'MASTER_SEQ';

LAST_NUMBER
-----------
          1

SCOTT> 
SCOTT> insert into master values(-100);
insert into master values(-100)
            *
行1でエラーが発生しました。:
ORA-00036: 再帰的SQLレベルの最大値(50)を超えました ORA-06512:
"SCOTT.INS_CASCADE_TEST", 行2
ORA-04088: トリガー'SCOTT.INS_CASCADE_TEST'の実行中にエラーが発生しました ORA-06512:
"SCOTT.INS_CASCADE_TEST", 行2
ORA-04088: トリガー'SCOTT.INS_CASCADE_TEST'の実行中にエラーが発生しました ORA-06512:
"SCOTT.INS_CASCADE_TEST", 行2
ORA-04088: トリガー'SCOTT.INS_CASCADE_TEST'の実行中にエラーが発生しました ORA-06512:
"SCOTT.INS_CASCADE_TEST", 行2
ORA-04088: トリガー'SCOTT.INS_CASCADE_TEST'の実行中にエラーが発生しました ORA-06512:
"SCOTT.INS_CASCADE_TEST", 行2
ORA-04088: トリガー'SCOTT.INS_CASCADE_TEST'の実行中にエラーが発生しました ORA-06512:
"SCOTT.INS_CASCADE_TEST", 行2
ORA-04088: トリガー'SCOTT.INS_CASCADE_TEST'の実行中にエラーが発生しました ORA-06512:
"SCOTT.INS_CASCADE_TEST", 行2
ORA-04088: トリガー'SCOTT.INS_CASCADE_TEST'の実行中にエラーが発生しました ORA-06512:


SCOTT> 
SCOTT> select last_number
  2  from user_sequences
  3  where sequence_name = 'MASTER_SEQ';

LAST_NUMBER
-----------
         51

SCOTT> 

ところで半年振りに起動した自宅のWindowsマシンのコードレスキーボードが壊れたらしく、仕方ないのでRDCをダウンロードしてMacOSXから利用することに。。。。

トリガーカスケード制限 #2

さて、前回のつづき。

今回は無限ループする（実際にはしませんけど）させずにトリガーカスケード制現値を確認する。（前回の実験でも十分なんですが。。）

環境は前回と同じです。

シナリオ１

３２テーブルに１トリガー／表で３２のINSERTトリガーを定義し正しく動作することを確認する。（カスケード制現値が４９のようなのでトリガーの３２連鎖では問題ないはず！）

３３テーブルを作成しておく。

SCOTT> l
  1  begin
  2    for seq in 1..33 loop
  3       execute immediate 'create table t'||to_char(seq,'FM09')|| ' (seq# number)';
  4    end loop;
  5* end;
SCOTT> /

PL/SQLプロシージャが正常に完了しました。

SCOTT> select table_name from user_tables where table_name like 'T%' order by table_name;

TABLE_NAME
------------------------------
T01
T02
T03
T04

・・・・中略・・・・

T30
T31
T32
T33

33行が選択されました。

SCOTT> 

作成した各表に１つづつ３２のトリガーを定義する。
ちなみに、イメージとしては親表にINSERT文が発行されるとトリガーが起動し子表へデータをINSERTする。以下、子表へのINSERT文でトリガーが起動し孫表へINSERT....の繰り返しでトリガーを３２回起動させる。

SCOTT> l
  1  declare
  2    ddlstr constant varchar2(1000)
  3      := 'create or replace trigger trg__$$seq$$__'
  4      || '  after insert on t__$$seq$$__ '
  5      || '  for each row '
  6      || 'begin'
  7      || '  insert into t__$$nextSeq$$__ values(:new.seq# + 1); '
  8      || 'end;';
  9    wkstr varchar2(2000);
 10  begin
 11    for seq in 1..32 loop
 12      wkstr := replace(
 13                  replace(
 14                    ddlstr,'__$$seq$$__',to_char(seq,'FM09')
 15                  ),
 16                  '__$$nextSeq$$__',
 17                  to_char(seq+1,'FM09')
 18                );
 19  --    dbms_output.put_line(wkstr);
 20      execute immediate wkstr;
 21    end loop;
 22* end;
SCOTT> /

PL/SQLプロシージャが正常に完了しました。

SCOTT> 
SCOTT> l
  1  select text
  2  from all_source
  3  where name like 'TRG__'
  4  and type = 'TRIGGER'
  5* order by name,line
SCOTT> /

TEXT
--------------------------------------------------------------------------------
trigger trg01  after insert on t01   for each row begin  insert into t02 values(
:new.seq# + 1); end;

trigger trg02  after insert on t02   for each row begin  insert into t03 values(
:new.seq# + 1); end;

trigger trg03  after insert on t03   for each row begin  insert into t04 values(
:new.seq# + 1); end;

・・・・中略・・・・

trigger trg30  after insert on t30   for each row begin  insert into t31 values(
:new.seq# + 1); end;

trigger trg31  after insert on t31   for each row begin  insert into t32 values(
:new.seq# + 1); end;

trigger trg32  after insert on t32   for each row begin  insert into t33 values(
:new.seq# + 1); end;


32行が選択されました。

SCOTT> 

実行！

SCOTT> insert into t01 values(1);

1行が作成されました。

SCOTT>

正常にINSERTできたようですね。

SCOTT> set serveroutput on size 10000
SCOTT> l
  1  declare
  2    seq# number;
  3  begin
  4      for i in 1..33 loop
  5        execute immediate 'select * from t'||to_char(i,'fm09') into seq#;
  6        dbms_output.put_line('T'||to_char(i,'fm09')||':'||to_char(seq#));
  7      end loop;
  8* end;
SCOTT> /
T01:1
T02:2
T03:3

・・・・中略・・・・

T31:31
T32:32
T33:33

PL/SQLプロシージャが正常に完了しました。

SCOTT> 

シナリオ２

３３テーブルに１トリガー／表で３３のINSERTトリガーを定義し正しく動作することを確認する。（カスケード制現値が４９のようなのでトリガーの３３連鎖でも問題ないはず！）

さきほどのデータはじゃまなのでロールバックしておく。

SCOTT> rollback;

ロールバックが完了しました。

テーブルとトリガーを各１つ追加作成し、トリガーを３３連鎖させる。

SCOTT> create table t34 as select * from t33;

表が作成されました。

SCOTT> l
  1* create or replace trigger trg33 after insert on t33 for each row begin insert into t34 values(:new.seq# + 1); end;
SCOTT> 

SCOTT> l
  1  select text
  2  from all_source
  3  where name like 'TRG__'
  4  and type = 'TRIGGER'
  5* order by name,line
SCOTT> /

TEXT
--------------------------------------------------------------------------------
trigger trg01  after insert on t01   for each row begin  insert into t02 values(
:new.seq# + 1); end;

trigger trg02  after insert on t02   for each row begin  insert into t03 values(
:new.seq# + 1); end;


・・・・中略・・・・


trigger trg32  after insert on t32   for each row begin  insert into t33 values(
:new.seq# + 1); end;

trigger trg33 after insert on t33 for each row begin insert into t34 values(:new
.seq# + 1); end;


33行が選択されました。

SCOTT> 

どうなりますか！。実行してみる。

SCOTT> insert into t01 values(1);

1行が作成されました。

SCOTT> 

トリガーの３３連鎖は無事終了。

SCOTT> l
  1  declare
  2    seq# number;
  3  begin
  4    for i in 1..34 loop
  5      execute immediate 'select * from t'||to_char(i,'fm09') into seq#;
  6      dbms_output.put_line('T'||to_char(i,'fm09')||':'||to_char(seq#));
  7    end loop;
  8* end;
SCOTT> /
T01:1
T02:2
T03:3

・・・・中略・・・・

T31:31
T32:32
T33:33
T34:34

PL/SQLプロシージャが正常に完了しました。

SCOTT> 

シナリオ３

５０テーブルに１トリガー／表でINSERTトリガーを定義し正しく動作することを確認する。（カスケード制現値が４９のようなのでトリガーの５０連鎖ではエラーがになるはず！）

SCOTT> rollback;

ロールバックが完了しました。

SCOTT> l
  1  begin
  2    for i in 35..52 loop
  3      execute immediate 'create table t'||to_char(i,'fm09')|| ' as select * from t34';
  4    end loop;
  5* end;
SCOTT> /

PL/SQLプロシージャが正常に完了しました。

SCOTT> 
SCOTT> l
  1  declare
  2    ddlstr constant varchar2(1000)
  3      := 'create or replace trigger trg__$$seq$$__'
  4      || '  after insert on t__$$seq$$__ '
  5      || '  for each row '
  6      || 'begin'
  7      || '  insert into t__$$nextSeq$$__ values(:new.seq# + 1); '
  8      || 'end;';
  9    wkstr varchar2(2000);
 10  begin
 11    for seq in 34..50 loop
 12      wkstr := replace(
 13                 replace(
 14                   ddlstr,'__$$seq$$__',to_char(seq,'FM09')
 15                 ),
 16                 '__$$nextSeq$$__',
 17                 to_char(seq+1,'FM09')
 18              );
 19  --    dbms_output.put_line(wkstr);
 20      execute immediate wkstr;
 21    end loop;
 22* end;
SCOTT> /

PL/SQLプロシージャが正常に完了しました。

SCOTT> 
SCOTT> l
  1  select text
  2  from all_source
  3  where name like 'TRG__'
  4  and type = 'TRIGGER'
  5* order by name,line
SCOTT> /

TEXT
--------------------------------------------------------------------------------
trigger trg01  after insert on t01   for each row begin  insert into t02 values(
:new.seq# + 1); end;

trigger trg02  after insert on t02   for each row begin  insert into t03 values(
:new.seq# + 1); end;

trigger trg03  after insert on t03   for each row begin  insert into t04 values(
:new.seq# + 1); end;

・・・・中略・・・・

trigger trg48  after insert on t48   for each row begin  insert into t49 values(
:new.seq# + 1); end;

trigger trg49  after insert on t49   for each row begin  insert into t50 values(
:new.seq# + 1); end;

trigger trg50  after insert on t50   for each row begin  insert into t51 values(
:new.seq# + 1); end;


50行が選択されました。

SCOTT> 

では実行！

SCOTT> insert into t01 values(1);
insert into t01 values(1)
*
行1でエラーが発生しました。:
ORA-00036: 再帰的SQLレベルの最大値(50)を超えました ORA-06512:
"SCOTT.TRG50", 行1
ORA-04088: トリガー'SCOTT.TRG50'の実行中にエラーが発生しました ORA-06512:
"SCOTT.TRG49", 行1
ORA-04088: トリガー'SCOTT.TRG49'の実行中にエラーが発生しました ORA-06512:
"SCOTT.TRG48", 行1
ORA-04088: トリガー'SCOTT.TRG48'の実行中にエラーが発生しました ORA-06512:
"SCOTT.TRG47", 行1
ORA-04088: トリガー'SCOTT.TRG47'の実行中にエラーが発生しました ORA-06512:
"SCOTT.TRG46", 行1
ORA-04088: トリガー'SCOTT.TRG46'の実行中にエラーが発生しました ORA-06512:
"SCOTT.TRG45", 行1
ORA-04088: トリガー'SCOTT.TRG45'の実行中にエラーが発生しました ORA-06512:
"SCOTT.TRG44", 行1
ORA-04088: トリガー'SCOTT.TRG44'の実行中にエラーが発生しました ORA-06512:
"SCOTT.TRG43", 行1
ORA-04088: トリガー'SCOTT.TRG43'の実行中にエラーが発生しました ORA-06512:
"SCOTT.TRG42", 行1
ORA-04088: トリガ


SCOTT> 

おおお〜〜〜。　:) でましたね。トリガーを５０連鎖させたところで制限を超えたようだ。

最後に、トリガーを４９連鎖させることが可能なことを確認しておく。

シナリオ４

４９テーブルに１トリガー／表で４９のINSERTトリガーを定義し正しく動作することを確認する。（カスケード制現値が４９のようなのでトリガーの４９連鎖は正常に実行できるはず！）

SCOTT> alter trigger trg50 disable;

トリガーが変更されました。

SCOTT> 
SCOTT> l
  1  select count(src.text)
  2  from
  3    all_source src join user_triggers trg
  4    on src.name = trg.trigger_name
  5  where
  6    src.name like 'TRG__'
  7    and src.type = 'TRIGGER'
  8    and trg.status = 'ENABLED'
  9  order by
 10    src.name,
 11*   src.line
SCOTT> /

COUNT(SRC.TEXT)
---------------
             49

SCOTT> 
SCOTT> rollback;

ロールバックが完了しました。

SCOTT> insert into t01 values(1);

1行が作成されました。

SCOTT> 

ということで、Linux(32bit)環境ではトリガーカスケード最大値は４９ということになる。

Windowsや32bit/64bitで違いはあるのだろうか？？？　違いが無かったらマニュアルが間違っているということか？！・・・・・・。別途調査予定。

トリガーカスケード制限 #1

やっと時間が取れるようになったのでしばらくは純粋にデータベースと戯れることができそうだ。w

ということで、キムラデービーブログ：徹底比較!! PostgreSQL vs MySQLパート2 with 勝手に vs Firebird (13)に面白そうなこと（以下の引用部分）が書いてあったので実際に試してみる事にした。

*2: 　カスケードは、例えばOracleは32個に制限されており、それ以下に設定することも可能です。

　これは例えば、あるトリガーから発せられたSQLによりトリガーが発せらるような場合で、ヘタすると、それが無限ループになってしまう。それを防ぐような形で制限されている(のだと思います。それか、もしかしたら実装上の制限かもしれません)

　勇気ある人は、無限にお互いを呼び合うようなトリガーを書いて、ご自分のプラットフォームで実行させてみてください。そして結果を木村まで知らせてください(^_^;)

環境はOracle11g EE for Linux x86/CentOS5という組み合わせです。詳しい環境は以前の記事をご参考に。

Oracle de XMLDB #6 - Linux x86版再び。
Mac de Ruby on Rails - #2 - Oracleと遊ぶ #1

では実験開始。

今回はある表に定義したINSERTトリガーをカスケードさせ無限に起動する状況を作ってみた。

１）まず、トリガーを定義する以下のような単純な表を作成。

SCOTT> desc master
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 SEQ#                                               NUMBER

２）定義するトリガーはmaster表へのINSERT文で起動しシーケンスから連番を取得し
　　トリガーが定義されているmaster表へ再度INSERT文を発行する。（無限ループするカスケードを実装した）

SCOTT> select text      
  2  from all_source
  3  where name = 'INS_CASCADE_TEST'
  4  order by line;

TEXT
--------------------------------------------------------------------------------
TRIGGER INS_CASCADE_TEST
  after insert on master
begin
  insert into master values(master_seq.nextval);
end;

上記トリガーを起動すれば、Oracleのマニュアル：論理データベースの制限のトリガー・カスケード制限に記載されている最大値に達すればエラーになるはず。無限ループするカスケードを実装したとしても実行途中でエラーとなり停止するはずだ。
マニュアルにはプラットーフォーム依存だが、通常は３２と記載されている。私の記憶違いでなければ、この値はOracle7の頃から変っていない。

３）では実行！

・実行前のシーケンス値の確認！。

SCOTT> select last_number
  2  from user_sequences
  3  where sequence_name = 'MASTER_SEQ';

LAST_NUMBER
-----------
          1

・実行！

SCOTT> insert into master values(-100);
insert into master values(-100)
            *
行1でエラーが発生しました。:
ORA-00036: 再帰的SQLレベルの最大値(50)を超えました ORA-06512:
"SCOTT.INS_CASCADE_TEST", 行2
ORA-04088: トリガー'SCOTT.INS_CASCADE_TEST'の実行中にエラーが発生しました ORA-06512:
"SCOTT.INS_CASCADE_TEST", 行2
ORA-04088: トリガー'SCOTT.INS_CASCADE_TEST'の実行中にエラーが発生しました ORA-06512:
"SCOTT.INS_CASCADE_TEST", 行2
ORA-04088: トリガー'SCOTT.INS_CASCADE_TEST'の実行中にエラーが発生しました ORA-06512:
"SCOTT.INS_CASCADE_TEST", 行2
ORA-04088: トリガー'SCOTT.INS_CASCADE_TEST'の実行中にエラーが発生しました ORA-06512:
"SCOTT.INS_CASCADE_TEST", 行2
ORA-04088: トリガー'SCOTT.INS_CASCADE_TEST'の実行中にエラーが発生しました ORA-06512:
"SCOTT.INS_CASCADE_TEST", 行2
ORA-04088: トリガー'SCOTT.INS_CASCADE_TEST'の実行中にエラーが発生しました ORA-06512:
"SCOTT.INS_CASCADE_TEST", 行2
ORA-04088: トリガー'SCOTT.INS_CASCADE_TEST'の実行中にエラーが発生しました ORA-06512:

予想通りエラーにはなったもののプラットフォーム依存と記載されている通り？、Linux(32bit)環境ではカスケードできる最大値は３２ではなく、４９というコンピュータの世界では半端な値になっているようだ。LinuxではなくWindowsでは３２なのだろうか？？？？

SCOTT> 
SCOTT> select last_number
  2  from user_sequences
  3  where sequence_name = 'MASTER_SEQ';

LAST_NUMBER
-----------
         51

SCOTT> 

次回は、linux(32bit)環境でトリガーカスケード制限が４９であるということを無限ループするトリガーを使わずに確認してみることにする。

カスケードの制限値を超えた場合にどうなるのかなんて確認したことなど一度も無かったので面白い発見だ！ :)

ORA-01722がエラーメッセージマニュアルに記載されていない怪

2014/5/12追記
Oracle11g R2以降のエラーメッセージマニュアルには、ORA-01722が記載されています。

---

さて、随分間が空いてしまいましたがしばらくはこんなベースでしょうおそらく。

先日、珍しいオラクルエラーに遭遇している方をフォローしたこともあり案外ハマる方も多いのかなぁ。と思いそんな方々の為の備忘録ということで書いておきましょう。

Oracle11gより前のリリースでも同じ結果になるのでOracleのバージョンはどうでもいいのですが、とりあえず最新ですよ。ということで。

SCOTT> 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 Linux: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production

ある方がプロシージャの実行時に以下のようなエラーで悩んでいた。

SCOTT> exec sample1722(10);
Department Name : ACCOUNTING
BEGIN sample1722(10); END;

*
行1でエラーが発生しました。:
ORA-01722: 数値が無効です。
ORA-06512: "SCOTT.SAMPLE1722", 行6
ORA-06512: 行1

本人は自分のプログラムのどこが悪いのか、ORA-01722が何故起きているか理解できていない模様。。。
実は、ORA-01722ってエラーメッセージはシンプルなんですが、オラクルのマニュアルには記載されていないのですよ。（ず〜〜〜〜〜と昔から。。）
unix系の環境でOracleをお使いになっているのなら以下のようにして確認してもちゃんと返ってくる。しかし解決方法も理由も記載されていない。。。www

SCOTT> !oerr ora 1722
01722, 00000, "invalid number"
// *Cause:
// *Action:

以下、Oracle Database Error Messages 11g Release 1 (11.1) より引用

実はこのエラー、そのまんまのエラーなのです。
コードは簡単にしてありますが、以下の６行目のような間違いを犯していたのです。

SCOTT> l
  1  create or replace procedure sample1722(in_deptno number)
  2  is
  3  begin
  4    for dept_rec in (select * from dept where deptno = in_deptno) loop
  5      dbms_output.put_line('Department Name : '||dept_rec.dname);
  6        for emp_rec in (select * from emp where deptno = dept_rec.dname order by sal desc) loop
  7          dbms_output.put_line('===>'||emp_rec.ename||':'||to_char(emp_rec.sal));
  8        end loop;
  9    end loop;
 10* end;
SCOTT> list 6
  6*       for emp_rec in (select * from emp where deptno = dept_rec.dname order by sal desc) loop
SCOTT> 
SCOTT> 

もうお分かりですよね。emp表のdeptno列はNUMBER型、dept表のdname列はVARCHAR2型、ということでVARCHAR2=>NUMBERへの暗黙の型変換が発生し数字文字以外の文字を数値へ変換しようとしてエラーが発生しているわけです。

SCOTT> desc emp
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 EMPNO                                     NOT NULL NUMBER(4)
 ENAME                                              VARCHAR2(10)
 JOB                                                VARCHAR2(9)
 MGR                                                NUMBER(4)
 HIREDATE                                           DATE
 SAL                                                NUMBER(7,2)
 COMM                                               NUMBER(7,2)
 DEPTNO                                             NUMBER(2)

SCOTT> desc dept
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 DEPTNO                                    NOT NULL NUMBER(2)
 DNAME                                              VARCHAR2(14)
 LOC                                                VARCHAR2(13)

SCOTT> 
SCOTT> 

以下の例を見れば一目瞭然ですよね。

SCOTT> select * from emp where deptno = 'AA';
select * from emp where deptno = 'AA'
                                *
行1でエラーが発生しました。:
ORA-01722: 数値が無効です。

もっと分かり易くすると。。。

SCOTT> select * from emp where deptno = to_number('AA');
select * from emp where deptno = to_number('AA');
                                           *
行1でエラーが発生しました。:
ORA-01722: 数値が無効です。

という単純なミスだったわけです。正しく修正して実行すれば以下の通り。

SCOTT> l
  1  create or replace procedure sample1722(in_deptno number)
  2  is
  3  begin
  4    for dept_rec in (select * from dept where deptno = in_deptno) loop
  5      dbms_output.put_line('Department Name : '||dept_rec.dname);
  6        for emp_rec in (select * from emp where  deptno = dept_rec.deptno order by sal desc) loop
  7          dbms_output.put_line('===>'||emp_rec.ename||':'||to_char(emp_rec.sal));
  8        end loop;
  9    end loop;
 10* end;
SCOTT> /

プロシージャが作成されました。

SCOTT> exec sample1722(10);
Department Name : ACCOUNTING
===>KING:5000
===>CLARK:2450
===>MILLER:1300

PL/SQLプロシージャが正常に完了しました。

SCOTT> 

暗黙の型変換にはご注意を。
黙の型変換はしないように！　とコーディング規約で定めているプロジェクトがほとんどだと思うけど、目視オンリーのレビューだとこの手のはすり抜けることも多いだろうね。今回のように変換エラーになる場合ならテストで発見し易いと思うけど、はっきり現れない嫌らしい暗黙の型変換もあるからね。;)

Mac de Ruby on Rails - #14 - IntelMac編 #5

さて、準備は整ったのでサンプルを作ってみましょう。利用するのはSCOTTスキーマのemp表。

Macintosh:test discus$ rails -d oracle emp_list
      create  
      create  app/controllers
      create  app/helpers
      create  app/models
      create  app/views/layouts
      create  config/environments
      create  config/initializers
      create  db
      create  doc
      create  lib

・・・・・・中略・・・・・・

      create  public/favicon.ico
      create  public/robots.txt
      create  public/images/rails.png
      create  public/javascripts/prototype.js
      create  public/javascripts/effects.js
      create  public/javascripts/dragdrop.js
      create  public/javascripts/controls.js
      create  public/javascripts/application.js
      create  doc/README_FOR_APP
      create  log/server.log
      create  log/production.log
      create  log/development.log
      create  log/test.log
Macintosh:test discus$
Macintosh:test discus$

scaffoldを使ってサンプルを作ってみます。
（database.ymlの編集なども以前の記事と同じなので省略しますね。）

Macintosh:test discus$ vi emp_list/config/database.yml
Macintosh:test discus$
Macintosh:test discus$
Macintosh:test discus$ cd emp_list
Macintosh:emp_list discus$ rails ruby script/generate scaffold Emp ename:string job:string mgr:integer hiredate:date sal:integer
      create  
      create  app/controllers
      create  app/helpers
      create  app/models
      create  app/views/layouts
      create  config/environments
      create  config/initializers
      create  db
      create  doc
      create  lib
      create  lib/tasks
      create  log

・・・・・・中略・・・・・・

      create  public/500.html
      create  public/index.html
      create  public/favicon.ico
      create  public/robots.txt
      create  public/images/rails.png
      create  public/javascripts/prototype.js
      create  public/javascripts/effects.js
      create  public/javascripts/dragdrop.js
      create  public/javascripts/controls.js
      create  public/javascripts/application.js
      create  doc/README_FOR_APP
      create  log/server.log
      create  log/production.log
      create  log/development.log
      create  log/test.log
Macintosh:emp_list discus$ ruby script/server
=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
=> Rails 2.1.0 application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no restart).
** Rails signals registered.  HUP => reload (without restart).  It might not work well.
** Mongrel 1.1.4 available at 0.0.0.0:3000
** Use CTRL-C to stop.

でアクセスしてみると。。。でました〜。これでIntelMac上でもRoRからOracleへアクセスできるようになりました〜〜。:-)

---

バックナンバー：
Mac de Ruby on Rails - #10 - IntelMac編 #1
Mac de Ruby on Rails - #11 - IntelMac編 #2
Mac de Ruby on Rails - #12 - IntelMac編 #3
Mac de Ruby on Rails - #13 - IntelMac編 #4

---

Mac de Ruby on Rails - #13 - IntelMac編 #4

前回のつづき旧バージョンが悪さをしているようなのでこの際、残っている古いバージョンをuninstallしてしまえ！　ということに。
尚、Leopardでは事前にRoRが/System/Library/Frameworks/Ruby.framework/以下にインストールされている。

Macintosh:test discus$ sudo gem uninstall activerecord --install-dir=/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8

Select gem to uninstall:
 1. activerecord-1.15.3
 2. activerecord-1.15.6
 3. activerecord-2.1.0
 4. All versions
> 2

You have requested to uninstall the gem:
	activerecord-1.15.6
actionwebservice-1.2.6 depends on [activerecord (= 1.15.6)]
rails-1.2.6 depends on [activerecord (= 1.15.6)]
If you remove this gems, one or more dependencies will not be met.
Continue with Uninstall? [Yn]  Y
Successfully uninstalled activerecord-1.15.6
Macintosh:test discus$ ruby test.rb
/Library/Ruby/Site/1.8/rubygems.rb:139:in `activate': can't activate activerecord (= 1.15.3), already activated activerecord-2.1.0] (Gem::Exception)
	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'
	from /Library/Ruby/Gems/1.8/gems/activesupport-2.1.0/lib/active_support/dependencies.rb:509:in `require'
	from /Library/Ruby/Gems/1.8/gems/activesupport-2.1.0/lib/active_support/dependencies.rb:354:in `new_constants_in'
	from /Library/Ruby/Gems/1.8/gems/activesupport-2.1.0/lib/active_support/dependencies.rb:509:in `require'
	from /Library/Ruby/Gems/1.8/gems/activerecord-2.1.0/lib/active_record/connection_adapters/abstract/connection_specification.rb:230:in `establish_connection'
	from test.rb:8
Macintosh:test discus$ sudo gem uninstall activerecord --install-dir=/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8

Select gem to uninstall:
 1. activerecord-1.15.3
 2. activerecord-2.1.0
 3. All versions
> 1

You have requested to uninstall the gem:
	activerecord-1.15.3
actionwebservice-1.2.3 depends on [activerecord (= 1.15.3)]
rails-1.2.3 depends on [activerecord (= 1.15.3)]
If you remove this gems, one or more dependencies will not be met.
Continue with Uninstall? [Yn]  Y
Successfully uninstalled activerecord-1.15.3
Macintosh:test discus$ ruby test.rb
/Library/Ruby/Gems/1.8/gems/activerecord-2.1.0/lib/active_record/connection_adapters/abstract/connection_specification.rb:232:in `establish_connection': Please install the oracle adapter:
 `gem install activerecord-oracle-adapter` (no such file to load -- active_record/connection_adapters/oracle_adapter) (RuntimeError)
	from test.rb:8
Macintosh:test discus$ 
Macintosh:test discus$ 

お〜〜〜、忘れていました。　oracle_adapter.rbを。

ということで、oracle_adapter.rbをダウンロード後、/Library/Ruby/Gems/1.8/gems/activerecord-2.1.0/lib/active_record/connection_adapters以下へコピー。

Macintosh:test discus$ 
Macintosh:test discus$ curl -O http://svn.rubyonrails.org/rails/adapters/oracle/lib/active_record/connection_adapters/oracle_adapter.rb
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 27847  100 27847    0     0  28714      0 --:--:-- --:--:-- --:--:-- 66645
Macintosh:test discus$ ll
total 64
drwxr-xr-x  15 discus  staff    510  6 14 07:31 emp_list
-rw-r--r--   1 discus  staff  27847  6 14 09:43 oracle_adapter.rb
-rw-r--r--   1 discus  staff    325  6 14 09:13 test.rb
Macintosh:test discus$ sudo cp oracle_adapter.rb /Library/Ruby/Gems/1.8/gems/activerecord-2.1.0/lib/active_record/connection_adapters
Password:
Macintosh:test discus$
Macintosh:test discus$

再度、テストプログラムを実行。

Macintosh:test discus$ ruby test.rb
7934, MILLER,CLERK

動いた！。
ということで次回へつづく。

---

バックナンバー：
Mac de Ruby on Rails - #10 - IntelMac編 #1
Mac de Ruby on Rails - #11 - IntelMac編 #2
Mac de Ruby on Rails - #12 - IntelMac編 #3

---

Mac de Ruby on Rails - #12 - IntelMac編 #3

さて、少々間が空いてしまったがこれから暫くは土日中心に記事をアップすることが多くなるかも。(おチビちゃんの世話などいろいろあるのでね。w　土日に１週間分のネタを時間指定公開しるようにしておいてもよいかもしれないが、そのネタを纏めてる時間がなかなか取れない。く〜〜〜っ。という感じ。）

と長い前置きはこれくらいにして、本題です。前回は、ruby-oci8をインストールしたところまでだった。（自分でも忘れてる。。）
今日は確認のため以前PPC版の時も使ったテストコードでオラクルへアクセスできるか確認しておくことにする。

以下、PPC版の時と同じなのでさらりとながします。。

Macintosh:˜ discus$ mkdir test
Macintosh:˜ discus$ cd test
Macintosh:test discus$ rails -d oracle emp_list
      create  
      create  app/controllers
      create  app/helpers
      create  app/models
      create  app/views/layouts
      create  config/environments
      create  config/initializers
      create  db
      create  doc
      create  lib
      create  lib/tasks
      create  log

・・・・中略・・・・

      create  public/javascripts/controls.js
      create  public/javascripts/application.js
      create  doc/README_FOR_APP
      create  log/server.log
      create  log/production.log
      create  log/development.log
      create  log/test.log
Macintosh:test discus$

database.ymlを編集。編集内容は見ての通り。

Macintosh:test discus$
Macintosh:test discus$ vi emp_list/config/database.yml
Macintosh:test discus$ cat emp_list/config/database.yml
# Oracle/OCI 8i, 9, 10g
#
# Requires Ruby/OCI8:
#  http://rubyforge.org/projects/ruby-oci8/
#
# Specify your database using any valid connection syntax, such as a
# tnsnames.ora service name, or a SQL connect url string of the form:
#
#   //host:[port][/service name]
#
# By default prefetch_rows (OCI_ATTR_PREFETCH_ROWS) is set to 100. And
# until true bind variables are supported, cursor_sharing is set by default
# to 'similar'. Both can be changed in the configation below; the defaults
# are equivalent to specifying:
#
#  prefetch_rows: 100
#  cursor_sharing: similar
#

development:
  adapter: oracle
  database: lampeye
  username: scott
  password: tiger

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
  adapter: oracle
  database: lampeye
  username: test
  password: test

production:
  adapter: oracle
  database: lampeye
  username: sample
  password: sampleadmin

テストコードも以前作ったコードを使い回し。

Macintosh:test discus$ vi test.rb
Macintosh:test discus$
Macintosh:test discus$
Macintosh:test discus$ cat test.rb
require 'rubygems'
require 'active_record'

class Emp < ActiveRecord::Base
  set_table_name "EMP"
end

ActiveRecord::Base.establish_connection(
  :adapter  => "oracle",
  :database => "lampeye",
  :username => "scott",
  :password => "tiger"
)

emp = Emp.find(:first,:conditions =>["ENAME = ?", "MILLER"])
puts "#{ emp.empno}, #{ emp.ename}, #{emp.job}, #{emp.hiredate}"
Macintosh:test discus$
Macintosh:test discus$ ruby test.rb
/Library/Ruby/Site/1.8/rubygems.rb:139:in `activate': can't activate activerecord (= 1.15.6), already activated
 ctiverecord-2.1.0] (Gem::Exception)
	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'
	from /Library/Ruby/Gems/1.8/gems/activesupport-2.1.0/lib/active_support/dependencies.rb:509:in `require'
	from /Library/Ruby/Gems/1.8/gems/activesupport-2.1.0/lib/active_support/dependencies.rb:354:in `new_constants_in'
	from /Library/Ruby/Gems/1.8/gems/activesupport-2.1.0/lib/active_support/dependencies.rb:509:in `require'
	from /Library/Ruby/Gems/1.8/gems/activerecord-2.1.0/lib/active_record/connection_adapters/abstract/connection_specification.rb:230:in
 establish_connection'
	from test.rb:8

エラーメッセージをみると、activerecord-1.15.6なんてのが悪さしているようだ。。。

Macintosh:test discus$
Macintosh:test discus$ gem li

*** LOCAL GEMS ***

actionmailer (2.1.0, 1.3.6, 1.3.3)
actionpack (2.1.0, 1.13.6, 1.13.3)
actionwebservice (1.2.6, 1.2.3)
activerecord (2.1.0, 1.15.6, 1.15.3)
activeresource (2.1.0)
activesupport (2.1.0, 1.4.4, 1.4.2)
acts_as_ferret (0.4.1)

・・・・中略・・・・
<
ruby-yadis (0.3.4)
rubygems-update (1.1.1)
rubynode (0.1.3)
sources (0.0.1)
sqlite3-ruby (1.2.1)
termios (0.9.4)

Macintosh:test discus$
Macintosh:test discus$

ということで、どうやら古いactiverecordが悪さしているらしい。。というところまでは分かった。。。uninstallすればいいらしい。どうやるか調べとく。=>TODO

ということで次回へ続く。

---

バックナンバー：
Mac de Ruby on Rails - #10 - IntelMac編 #1
Mac de Ruby on Rails - #11 - IntelMac編 #2

---

Mac de Ruby on Rails - #11 - IntelMac編 #2

さて、つづきです。ruby-oci8をインストールする。（ruby-oci8は、1.0.0を事前にダウンロードしておいた。尚、本記事を書いている時点では、1.0.1が最新。）

まず、make。

Macintosh:˜ discus$ ll
total 216
drwx------+ 32 discus  staff    1088  6  8 23:25 Desktop
drwx------+ 10 discus  staff     340  1  3 01:32 Documents
drwx------+ 14 discus  staff     476  6  8 23:26 Downloads
drwxr-xr-x  10 discus  staff     340 12 19 16:03 Image Browser
drwxr-xr-x  10 discus  staff     340 12 19 16:57 Image Kit Browser
drwx------+ 32 discus  staff    1088  3  1 14:07 Library
drwx------+  3 discus  staff     102 11 26  2007 Movies
drwx------+  4 discus  staff     136  2  2 11:12 Music
drwx------+  9 discus  staff     306  6 14 05:21 Pictures
drwxr-xr-x+  5 discus  staff     170 11 26  2007 Public
drwxr-xr-x+  5 discus  staff     170 11 26  2007 Sites
drwxr-xr-x  16 discus  staff     544 11 25  2007 ruby-oci8-1.0.0
-rw-r--r--   1 discus  staff  107494  3  2 02:27 ruby-oci8-1.0.0.tar.gz
Macintosh:˜ discus$ cd ruby-oci8-1.0.0
Macintosh:ruby-oci8-1.0.0 discus$ make
ruby setup.rb config 
---> lib
---> lib/DBD
---> lib/DBD/OCI8
<--- lib/DBD/OCI8
<--- lib/DBD
<--- lib
---> ext
---> ext/oci8
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby /Users/discus/ruby-oci8-1.0.0/ext/oci8/extconf.rb 
checking for load library path... (DYLD_LIBRARY_PATH)... 
  found: /Users/Shared/OracleInstantClient/libclntsh.dylib.10.1 looks like an instant client.
checking for cc... ok
checking for gcc... yes
checking for LP64... no
checking for ruby header... ok
checking for OCIInitialize() in oci.h... no
---------------------------------------------------
error messages:
Could not compile with Oracle instant client.
You may need to set a environment variable:
    DYLD_LIBRARY_PATH=/Users/Shared/OracleInstantClient
    export DYLD_LIBRARY_PATH

---------------------------------------------------
See:
 * http://ruby-oci8.rubyforge.org/ja/HowToInstall.html
 * http://ruby-oci8.rubyforge.org/ja/ReportInstallProblem.html

*** /Users/discus/ruby-oci8-1.0.0/ext/oci8/extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

Provided configuration options:
	--with-opt-dir
	--without-opt-dir
	--with-opt-include
	--without-opt-include=${opt-dir}/include
	--with-opt-lib
	--without-opt-lib=${opt-dir}/lib
	--with-make-prog
	--without-make-prog
	--srcdir=/Users/discus/ruby-oci8-1.0.0/ext/oci8
	--curdir
	--ruby=/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby
	--with-instant-client
	--without-instant-client
/Users/discus/ruby-oci8-1.0.0/ext/oci8/oraconf.rb:941:in `initialize': RuntimeError (RuntimeError)
	from /Users/discus/ruby-oci8-1.0.0/ext/oci8/oraconf.rb:236:in `new'
	from /Users/discus/ruby-oci8-1.0.0/ext/oci8/oraconf.rb:236:in `get'
	from /Users/discus/ruby-oci8-1.0.0/ext/oci8/extconf.rb:6
'system /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby /Users/discus/ruby-oci8-1.0.0/ext/oci8/extconf.rb ' failed
Try 'ruby setup.rb --help' for detailed usage.
make: *** [config.save] Error 1
Macintosh:ruby-oci8-1.0.0 discus$

checking for OCIInitialize() in oci.h... noというエラーが出てmakeできない。いろいろ調べてみたら、ruby-oci8 1.0.0はInteli386アーキテクチャのみ有効なようなので、以下のようにコンパイルオプションに"-arch i386"を追加すればインストールできるとのこと。
以下のサイトを参考にさせてもらった。
http://blog.rayapps.com/2008/04/24/how-to-setup-ruby-and-new-oracle-instant-client-on-leopard/

ということで再make。

Macintosh:ruby-oci8-1.0.0 discus$ export ARCHFLAGS="-arch i386"
Macintosh:ruby-oci8-1.0.0 discus$ make
ruby setup.rb config 
---> lib
---> lib/DBD
---> lib/DBD/OCI8
<--- lib/DBD/OCI8
<--- lib/DBD
<--- lib
---> ext
---> ext/oci8
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby /Users/discus/ruby-oci8-1.0.0/ext/oci8/extconf.rb 
checking for load library path... (DYLD_LIBRARY_PATH)... 
  found: /Users/Shared/OracleInstantClient/libclntsh.dylib.10.1 looks like an instant client.
checking for cc... ok
checking for gcc... yes
checking for LP64... no
checking for ruby header... ok
checking for OCIInitialize() in oci.h... yes
checking for OCIEnvCreate()... yes
checking for OCITerminate()... yes
checking for OCILobOpen()... yes
checking for OCILobClose()... yes
checking for OCILobCreateTemporary()... yes
checking for OCILobGetChunkSize()... yes
checking for OCILobLocatorAssign()... yes
creating ../../lib/oci8.rb from /Users/discus/ruby-oci8-1.0.0/ext/oci8/../../lib/oci8.rb.in
creating extconf.h
creating Makefile
<--- ext/oci8
<--- ext
ruby setup.rb setup
---> lib
---> lib/DBD
---> lib/DBD/OCI8
<--- lib/DBD/OCI8
<--- lib/DBD
<--- lib
---> ext
---> ext/oci8
make 
gcc -I. -I. -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin9.0 -I/Users/discus/ruby-oci8-1.0.0/ext/oci8 -DRUBY_EXTCONF_H=\"extconf.h\"  -fno
-common -arch i386 -Os -pipe -fno-common -I/Users/Shared/OracleInstantClient/sdk/include -Wall  -c oci8.c

・・・・中略・・・・

cc -arch i386 -pipe -bundle -undefined dynamic_lookup -o oci8lib.bundle oci8.o handle.o const.o env.o error.o svcctx.o server.o session.o
 stmt.o define.o bind.o describe.o descriptor.o param.o lob.o oradate.o oranumber.o ocinumber.o attr.o -L"." -L"/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib" -L. 
-arch i386    -lruby  -L/Users/Shared/OracleInstantClient -lclntsh  -lpthread -ldl -lm  
<--- ext/oci8
<--- ext
Macintosh:ruby-oci8-1.0.0 discus$ 
Macintosh:ruby-oci8-1.0.0 discus$ sudo make install
Password:
ruby setup.rb install
---> lib
mkdir -p /Library/Ruby/Site/1.8/
install oci8.rb /Library/Ruby/Site/1.8/
---> lib/DBD
mkdir -p /Library/Ruby/Site/1.8/DBD
---> lib/DBD/OCI8
mkdir -p /Library/Ruby/Site/1.8/DBD/OCI8
install OCI8.rb /Library/Ruby/Site/1.8/DBD/OCI8
<--- lib/DBD/OCI8
<--- lib/DBD
<--- lib
---> ext
---> ext/oci8
mkdir -p /Library/Ruby/Site/1.8/universal-darwin9.0/.
install oci8lib.bundle /Library/Ruby/Site/1.8/universal-darwin9.0/.
<--- ext/oci8
<--- ext
Macintosh:ruby-oci8-1.0.0 discus$ 

少々注意する点はあるがそれ以外は順調、順調。

---

バックナンバー：Mac de Ruby on Rails - #10 - IntelMac編 #1

---

Mac de Ruby on Rails - #10 - IntelMac編 #1

さて、やっと時間ができたので前回Leopard(IntelMac)のRosettaで動作させていたOracle Instant Client 10g R1 10.1.0.3.0 for MacOSX(PPC)からネイディブで動作するOracle Instant Client 10g R2 10.2.0.4.0 for MacOSX(Intel x86)へ入れ替えたのもこれをやるための準備。

Mac OS X 10.5.1 Leopard (Intel x86)にはRuby/Ruby on Railsがインストールされている。やっとx86ネイティブなOracle Instant Client for MacOSX(intel x86)がリリースされたのだからその環境を整えておかないと。。。というのがその理由。

では早速。今日は、Ruby on RailsとRubyGemsをアップデートするまで。

まずは、MacOSXの環境

Macintosh:˜ discus$ uname -a
Darwin Macintosh.local 9.3.0 Darwin Kernel Version 9.3.0: Fri May 23 00:49:16 PDT 2008; root:xnu-1228.5.18~1/RELEASE_I386 i386
Macintosh:˜ discus$ 
Macintosh:˜ discus$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.5.3
BuildVersion:	9D34
Macintosh:˜ discus$ /usr/sbin/system_profiler SPApplicationsDataType | grep Xcode

    Xcode:
      Get Info String: Xcode version 3.1
      Location: /Developer/Applications/Xcode.app

次はRuby関連のバージョン確認（プレインストールされているRailsは2.xではなく、1.2.6なので今回は、2.1へアップデート RubyGemsもついでにアップデートしておく。）

Last login: Sat Jun 14 05:18:31 on console
Macintosh:˜ discus$ ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [universal-darwin9.0]
Macintosh:˜ discus$ rails -v
Rails 1.2.6
Macintosh:˜ discus$ gem -v
1.0.1
Macintosh:˜ discus$
Macintosh:˜ discus$

では、railsのアップデートから。

Macintosh:˜ discus$
Macintosh:˜ discus$ sudo gem install rails --include-dependencies
Password:
INFO:  `gem install -y` is now default and will be removed
INFO:  use --ignore-dependencies to install only the gems you list
Bulk updating Gem source index for: http://gems.rubyforge.org
Successfully installed rake-0.8.1
Successfully installed activesupport-2.1.0
Successfully installed activerecord-2.1.0
Successfully installed actionpack-2.1.0

・・・・中略・・・・

Installing RDoc documentation for rake-0.8.1...
Installing RDoc documentation for activesupport-2.1.0...
Installing RDoc documentation for activerecord-2.1.0...
Installing RDoc documentation for actionpack-2.1.0...
Installing RDoc documentation for actionmailer-2.1.0...
Installing RDoc documentation for activeresource-2.1.0...
Macintosh:˜ discus$
Macintosh:˜ discus$

うまくいったようだ。。:)

お次は、RubyGemsのアップデート

Macintosh:˜ discus$
Macintosh:˜ discus$ sudo gem update --system
Updating RubyGems...
Attempting remote update of rubygems-update
Successfully installed rubygems-update-1.1.1
1 gem installed
Updating version of RubyGems to 1.1.1
Installing RubyGems 1.1.1
mkdir -p /Library/Ruby/Site/1.8/rbconfig
install -c -m 0644 rbconfig/datadir.rb /Library/Ruby/Site/1.8/rbconfig/datadir.rb
mkdir -p /Library/Ruby/Site/1.8/rubygems
install -c -m 0644 rubygems/builder.rb /Library/Ruby/Site/1.8/rubygems/builder.rb
install -c -m 0644 rubygems/command.rb /Library/Ruby/Site/1.8/rubygems/command.rb

・・・・中略・・・・

= Announce: RubyGems Release 1.1.1

Release 1.1.1 fixes some bugs.

Bugs Fixed:

* Gem.prefix now returns non-nil only when RubyGems was installed outside
  sitelibdir or libdir.
* The `gem server` gem list now correctly links to gem details.
* `gem update --system` now passes --no-format-executable to setup.rb.
* Gem::SourceIndex#refresh! now works with multiple gem repositories.
* Downloaded gems now go into --install-dir's cache directory.
* Various fixes to downloading gem metadata.
* `gem install --force` now ignores network errors too.
* `gem pristine` now rebuilds extensions.
* `gem update --system` now works on virgin Apple ruby.
* Gem::RemoteFetcher handles Errno::ECONNABORTED.
* Printing of release notes fixed.

For a full list of changes to RubyGems including credits, see the ChangeLog
file.

・・・・中略・・・・

If you find a bug where RubyGems crashes, please provide debug output. You can
do that with `gem --debug the_command`.

== Thanks

Keep those gems coming!

-- Jim & Chad & Eric (for the RubyGems team)


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

RubyGems installed the following executables:
	/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/gem

If `gem` was installed by a previous RubyGems installation, you may need
to remove it by hand.

RubyGems system software updated
Macintosh:˜ discus$
Macintosh:˜ discus$

こちらも問題なくアップデートできたようだ。

最後にバージョン確認。

Macintosh:˜ discus$
Macintosh:˜ discus$ gem -v
1.1.1
Macintosh:˜ discus$ ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [universal-darwin9.0]
Macintosh:˜ discus$ rails -v
Rails 2.1.0
Macintosh:˜ discus$ 

順調、順調！

今日はここまで、次回へつづく。

Oracle Instant Client 10g R2 10.2.0.4.0 for IntelMacへ入れ替える

随分前にRosettaを介してOracle Instant Client 10g R1 for PPCがIntelMac上で動作するという記事を書いたが、少々前のこと、やっとIntalMac版Oracle Instant Client 10g R2 10.2.0.4.0 for IntelMacがリリースされたので次のステップへの準備として以前インストールしたPPC版Oracle Instant ClientをIntelMac版に入れ替えておく！

インストール手順などは以前の記事を参考してくださいね。同じですから。

尚、今回は以前のインストールしたPPC版Oracle Instant ClientをIntelMac版と入れ替えるだけなので、PPC版を一旦削除してからIntelMac版のOracle Instant Clientをダウンロード、解凍しただけ。環境変数も以前のままです。

Macintosh:OracleInstantClient discus$ ll
total 211792
-rw-r--r--@ 1 discus  wheel       287  3 27 04:38 BASIC_LITE_README
-rw-r--r--@ 1 discus  wheel       277  3 27 04:38 BASIC_README
-rw-r--r--@ 1 discus  wheel       275  3 27 04:38 JDBC_README
-rw-r--r--@ 1 discus  wheel       281  3 27 04:38 SQLPLUS_README
-r--r--r--@ 1 discus  wheel   1609607  2 18 03:54 classes12.jar
-rwxr-xr-x@ 1 discus  wheel     30556  3 27 04:37 genezi
-r-xr-xr-x@ 1 discus  wheel      1525  8 30  2004 glogin.sql
lrwxr-xr-x  1 discus  wheel        20  6  8 23:07 libclntsh.dylib -> libclntsh.dylib.10.1
-rwxr-xr-x@ 1 discus  wheel  21252860  3  7 09:12 libclntsh.dylib.10.1
-rwxr-xr-x@ 1 discus  wheel     31016  2 22 09:02 libheteroxa10.dylib
-rwxr-xr-x@ 1 discus  wheel     31016  2 22 09:02 libheteroxa10.jnilib
-rwxr-xr-x@ 1 discus  wheel   1638264  3  7 03:09 libnnz10.dylib
lrwxr-xr-x  1 discus  wheel        18  6  8 23:07 libocci.dylib -> libocci.dylib.10.1
-rwxr-xr-x@ 1 discus  wheel   1111964  3 11 04:49 libocci.dylib.10.1
-rwxr-xr-x@ 1 discus  wheel  72626696  3 27 04:38 libociei.dylib
-rwxr-xr-x@ 1 discus  wheel   4309524  3 27 04:38 libociicus.dylib
-rwxr-xr-x@ 1 discus  wheel    103800  2 22 09:02 libocijdbc10.dylib
-rwxr-xr-x@ 1 discus  wheel    103800  2 22 09:02 libocijdbc10.jnilib
-rwxr-xr-x@ 1 discus  wheel    865412  2 21 06:53 libsqlplus.dylib
-rwxr-xr-x@ 1 discus  wheel   1442316  2 21 06:54 libsqlplusic.dylib
-r--r--r--@ 1 discus  wheel   1555682  2 18 03:55 ojdbc14.jar
-r--r--r--@ 1 discus  wheel   1646178  1 23 01:28 orai18n.jar
drwxr-xr-x@ 7 discus  staff       238  3 27 04:38 sdk
-rwxr-xr-x@ 1 discus  wheel     12612  2 21 06:53 sqlplus
-rw-r--r--  1 discus  wheel       225  2  2 10:31 tnsnames.ora
Macintosh:OracleInstantClient discus$ 
Macintosh:˜ discus$ cat .bashrc
alias ll='ls -lv'

export ORACLE_HOME=/Users/Shared/OracleInstantClient
export NLS_LANG=Japanese_Japan.AL32UTF8
export DYLD_LIBRARY_PATH=$ORACLE_HOME
export PATH=$ORACLE_HOME:$PATH
export TNS_ADMIN=$ORACLE_HOME
Macintosh:˜ discus$ 

では、SQL*Plusを起動してOracle11g R1 11.1.0.6.0へ接続してみる。

上手く行きましたね。ということで今日はここまで。

PL/SQL で Python Challenge Level 18 う〜〜〜ん。

やることは分かったのだがPL/SQLでは重要な部分(pythonなら一発だけど）を手作りしないとならない。。。とりあえず適当に作ったてはみたもののまだ思うような結果にはなっていない。。だが、そこさえクリアできればlevel18はPL/SQLだけで解けるはず。。。。。ということで暇を見て実装中。といってもその暇がなかなか取れなくなりそうな予感も。。。まあ、今回のネタはおもしろそうなので、少しづつでも進めて行きますよ。。。w

PL/SQL で Python Challenge Level 18 わかちゃったかも・・

Level18は以外と簡単かも〜〜、Pythonならば。と。
当然だよね。Python ChallengeなんだからPythonを使って解くことを前提に作られてるのは。。。。

しかし、今回はもしかするとPL/SQLだけで全部解けちゃうかもしれない・・・久々だ〜。一部はかなり苦労してガリガリ作り込まなければならないと思われるのだが・・・その方法で上手く解けるという自信は７０％。チャレンジしてみますよ〜〜。連休中にロジックを考えとく。。。

次回へつづく。;)

PL/SQL で Python Challenge Level 17 - 完

さて、少々間があいてしまったが、Python Challenge Level17の最終回。

前回、つまらないところでモタモタしてしまったが、Oracle Application Express 3.0.xを使わず、単純に mod_plsqlを使えばいいじゃんと言うことで。。。。

Level17は、以前にも書いたがWeb Applicationを書いたことのある人なら簡単に解けると思います。
今回は一部を除き、約９０％がPL/SQL、残りをJava stored procedureで処理した。;)

ということで答えを導きだしたスクリーンショット。（答えはぼかしてますよ！）

次回、Python Challenge Level 18はこれまた気が向いたときにても。。。Enjoy Python Challenge!

埋込みPL/SQL Gatewayで外部URLアクセス

Oracle11g R1 11.1.0.6.0 for Linux x86 and Oracle Application Expressという記事で埋込みPL/SQL GatewayをでPython Challengeを試してみたのだが・・・埋込みPL/SQL Gatewayを利用した場合、UTL_HTTPパッケージで外部のURLへアクセスすることはできないみたいなので、あきらめて通常のmod_plsqlでやってみるか・・・。Oracle11gからならACLで許可してやればアクセスできるのに、Oracle11gに内蔵されているXDB HTTP Serverではそれは効かないのね。。遊べると思ったのに。。orz.（Oracle11gの埋込みPL/SQL Gatewayの備忘録として残しておくか。。）

エラーメッセージは以下の通り。（Apexを3.1にするとできるようになったりして。。。2008/4/19追記)

ORA-31020:操作できません。 理由:For security reasons, ftp and http access over XDB repository is not allowed on server side

以下、埋込みPL/SQL Gatewayを利用したOracle Application Expressのスクリーンショット

4/18追記
どうもこれは埋込みPL/SQL GatewayというよりOracle Application Express側の影響のように思えてきた。10gのmod_plsql経由でもApexでは同じエラーだった。
ちなみに、mod_plsql経由で呼び出すだけならACL定義でアクセスするホストを許可してやるだけでOK。

以下にその時のスクリーンショットを載せておく。
答えにLevel17の答えに結びつく部分はぼかしてますよ〜〜。

でも何故、ApexからUTL_HTTPを利用するとXDB絡みのエラーになるんだ？　不思議すぎる。。。これは追々調べておくか。。何か手順から漏れていることがあったりして。。。。つづく。

さらに追記、やはり出来ない（11gからはできなくなったと言ったほうがいいだろう）というのが正しいようだ。10gではApexから直接UTL_HTTPパッケージからHTTPリクエスト出してfeedやらHTMLやらアクセスし放題だったのに〜〜〜、プンプンのプン。　ふ〜普通のmod_plsqlでやりますよ〜〜〜〜だ。

Oracle11g R1 11.1.0.6.0 for Linux x86 and Oracle Application Express

Python Challenge Level17の記事を書く前に、やっておきたい事があったのでそちらを先に。

何をやりたかったのか？　それは、APEX（Oracle Application Express）環境を作っておく事。

Python ChallengeではWeb Applicationとして処理して欲しそうな問題も多数存在する。Level17はそうしたほうが自然な感じをだと思ったので。。。（実際にはそこまでしなくても解けたのですが）
Oracle11gからApexがバンドルされたのと同時に、組み込みPL/SQL gateway機能も追加されたのでその辺りも含めて確認しておきたかった。

この組込PL/SQL Gatewayってなによ？　って方もいると思うのだが、簡単に言うと、”Oracle11gのデータベース内部にHTTP Server+mod_plsqが内蔵されちゃっている”と思えばイメージしやすいんじゃないかと。

概要はこのあたりのマニュアルを読めば掴めると思います。はい。

マニュアル（英語）Understanding Oracle Application Express Architecture

データベースサーバがHTTPサーバを内蔵なんて言うといや〜な顔する人もいるだろうなぁ。なんて思ったりもします。（笑）
実際の所組込みPL/SQLゲートウェイは、外部に公開するというより開発目的など内部の閉じられた環境で利用されることがほとんどじゃないかなぁと個人的には思います。

Oracle11gをインストールした場合、OUIによるインストールでは明示的に除外しなければOracle Application Expressも同時にインストールされる。尚、埋込みPL/SQLゲートウェイを利用するためには、Oracle XML DBも必要。詳細はマニュアルに記載されているので、よ〜〜〜く読めば簡単に構成できます。
4.5 Postinstallation Tasks for Oracle Application Express

ちなみに、Oracle11g R1 1011.1.0.6.0に含まれるOracle Application Expressは、3.0.1.00.08とのこと、3.1が既にリリースされているのでアップグレードするのもいいが、今回は面倒なのでそのまま使うことにした。

では”素直に”マニュアルに従い作業を進める。。。（笑）

sysdbaで接続後、 $ORACLE_HOME/apex/apexconfを実行しadminユーザのパスワードとapexのport番号を設定してから、anonymousユーザをアンロックします。

G5Server:˜ discus$ ssh oracle@corydoras
oracle@corydoras's password: 
Last login: Tue Apr 15 22:09:38 2008 from 192.168.1.19
[oracle@corydoras ˜]$ 
[oracle@corydoras ˜]$ 
[oracle@corydoras ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on 火 4月 15 22:46:50 2008

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

> conn / as sysdba
接続されました。
SYS> spo apexconfig.log
SYS> @?/apex/apxconf

      PORT
----------
      8080

Enter values below for the XDB HTTP listener port and the password for the Application Express ADMIN user.
Default values are in brackets [ ].
Press Enter to accept the default value.


Enter a password for the ADMIN user              [] apex
Enter a port for the XDB HTTP listener [      8080] 
...changing HTTP Port

PL/SQLプロシージャが正常に完了しました。


PL/SQLプロシージャが正常に完了しました。


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

...changing password for ADMIN

PL/SQLプロシージャが正常に完了しました。


コミットが完了しました。

SYS> alter user anonymous account unlock;

ユーザーが変更されました。

SYS> 

さて、お継ぎはマニュアルに記載されている通り（コピペでOKです。）外部のネットワークにアクセスする為にACLを変更しました。
（この例ではマニュアルと同様、どこでもアクセスできるようにしておきます。今回の場合は、python challengeのサイトだけアクセス許可しておけば問題ないのですが、いろいろと試したいことがあるので今回マニュアルの例をそのまま利用させてもらいました。）

SYS> l
  1  DECLARE
  2  	ACL_PATH VARCHAR2(4000);
  3  	ACL_ID RAW(16);
  4  BEGIN
  5  	-- Look for the ACL currently assigned to '*' and give FLOWS_030000
  6  	-- the "connect" privilege if FLOWS_030000 does not have the privilege yet.
  7  	SELECT ACL INTO ACL_PATH FROM DBA_NETWORK_ACLS
  8  	WHERE HOST = '*' AND LOWER_PORT IS NULL AND UPPER_PORT IS NULL;
  9
 10  	-- Before checking the privilege, make sure that the ACL is valid
 11  	-- (for example, does not contain stale references to dropped users).
 12  	-- If it does, the following exception will be raised:
 13  	--
 14  	-- ORA-44416: Invalid ACL: Unresolved principal 'FLOWS_030000'
 15  	-- ORA-06512: at "XDB.DBMS_XDBZ", line ...
 16  	--
 17  	SELECT SYS_OP_R2O(extractValue(P.RES, '/Resource/XMLRef')) INTO ACL_ID
 18  	FROM XDB.XDB$ACL A, PATH_VIEW P
 19  	WHERE extractValue(P.RES, '/Resource/XMLRef') = REF(A) AND
 20  	EQUALS_PATH(P.RES, ACL_PATH) = 1;
 21
 22  	DBMS_XDBZ.ValidateACL(ACL_ID);
 23
 24  	IF DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE(ACL_PATH, 'FLOWS_030000', 'connect')
 25  	IS NULL THEN
 26  	    DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(ACL_PATH,
 27         'FLOWS_030000', TRUE, 'connect');
 28  	END IF;
 29
 30  EXCEPTION
 31  	-- When no ACL has been assigned to '*'.
 32  	WHEN NO_DATA_FOUND THEN
 33  	    DBMS_NETWORK_ACL_ADMIN.CREATE_ACL('power_users.xml',
 34  	    'ACL that lets power users to connect to everywhere',
 35  	    'FLOWS_030000', TRUE, 'connect');
 36  	    DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('power_users.xml','*');
 37* END;
SYS> /

PL/SQLプロシージャが正常に完了しました。

SYS> 
SYS> commit;

コミットが完了しました。

SYS> 

apexの管理画面にログインするには...以下のような形式のURLでブラウザからアクセスする。もちろん、ホストはOracle11g Databaseインスタンスがあるサーバですよ。

http://host:port/apex/apex_admin

ここまでで、application expressは利用可能な状態なのだが１つ問題がある、それは英語版のままだということ。（これは以前のOracle Application Expressでも同じですね。）
ということで、日本語リソースをロードします。尚、環境変数NLS_LANGは、AL32UTF8である必要があります。（これも以前と同じなので利用したことがあれば間違うことは無いと思いますが、注意しなければならない点ですよ。うっかりミスというのもありますから。）

[oracle@corydoras ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on 火 4月 15 23:06:03 2008

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

> conn / as sysdba
接続されました。
SYS> !echo $NLS_LANG
japanese_japan.AL32UTF8

SYS> alter session set current_schema=FLOWS_030000;

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

SYS> @?/apex/builder/ja/load_ja
.  ____   ____           ____        ____
. /    \ |    \   /\    /     |     /
.|      ||    /  /  \  |      |    |
.|      ||---    ----  |      |    |--
.|      ||   \  /    \ |      |    |
. \____/ |    \/      \ \____ |____ \____
.
. Application Express Hosted Development Service Installation.
.........................................................

PL/SQLプロシージャが正常に完了しました。

Install Application Express applications

PL/SQLプロシージャが正常に完了しました。

APPLICATION 4420 - APEX  - System Messages
Set Credentials...
Check Compatibility...
API Last Extended:20070525
Your Current Version:20070525
This import is compatible with version: 20070108
COMPATIBLE (You should be able to run this import without issues.)
Set Application ID...
...authorization schemes
...navigation bar entries
...application processes
...application items
...application level computations
...Application Tabs
...Application Parent Tabs
...Shared Lists of values
...Application Trees
...page groups
...PAGE 1.442: メッセージ
...lists
...breadcrumbs

中略

...PAGE 91.4009: 検証の作成 - 検証タイプ
...PAGE 92.4009: 標準タブの作成の確認
...PAGE 93.4009: 既存のタブ・セットの選択
...PAGE 94.4009: タブ情報の指定
...PAGE 95.4009: 親タブ・セット
...PAGE 96.4009: 新しいタブ名
...PAGE 97.4009: 表形式フォーム
...PAGE 98.4009: 検証の作成 - SQL検証
...PAGE 99.4009: SQLレポートの作成
...PAGE 100.4009: カレンダ・ページの作成
...PAGE 101.4009: ボタンのコピー
...PAGE 102.4009: リージョンの削除の確認
...PAGE 103.4009: ビルド・ステータス
...PAGE 104.4009: ビルド・チャート問合せ
...PAGE 105.4009: スクリプト・ファイルのエクスポート
...PAGE 106.4009: ビルド・チャート問合せ
...PAGE 107.4009: 作成ウィザード
...PAGE 108.4009: 作成ウィザード
...PAGE 109.4009: 作成ウィザード
...PAGE 110.4009: 作成ウィザード
...PAGE 111.4009: 作成ウィザード
...PAGE 112.4009: ツリー・ウィザード
...PAGE 113.4009: ツリー・ウィザード
...PAGE 114.4009: ツリー・ウィザード

中略

......scheme 108165525079033088.4709
...done
Adjust instance settings

PL/SQLプロシージャが正常に完了しました。

最後に、job_queue_process初期化パラメータが１以上になっているか確認します。
私も初めて気付いたがデフォルトで1000になっているんですね。びっくり。以前は１桁か２桁だったようなきがするが。

SYS> 
SYS> show parameter job_queue_processes

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
job_queue_processes                  integer     1000
SYS> 

尚、今回はSSLの設定は行わないので早速Apexの管理ユーザログインし直し開発用作業領域と開発ユーザを作っておく。

さて、準備もできたので次へ行くか！

PL/SQL で Python Challenge Level 17 #2 - 解けた！

さて、前回、解き方は見えたような気がすると書いたがいろいろな罠？に見事に引っかかったが解けました。はい。
今、Level18の問題が見えたのだが、また画像問題なのかな？

Level17は、Web Applicationを作った経験のある方ならLevel17の質問の画像自体がヒント。
なんですが、２重、３重の仕掛けがあるのでイライラするよ。ですが、基本的にはいままでの問題を解いてきたテクニックやコードを再利用すれば十分なので特に新しいことが必要でもない。。。

ということで、次回のPL/SQL で　Python ChallengeはLevel17のヒントにならないヒント。でLevel17を締めくくろう。

以下のスクリーンショットは、最後の仕掛けを通り抜ける為のヒントを取り出す事に成功した場面。Level18のURLを導きだした時のスクリーンショットではありません。:)

タイムゾーン de 自動調整のおまけ

今回はタイムゾーンネタというより、前回、前々回のおまけネタ。

前回、前々回ともほとんど解説なしにサンプルSQLを載せていたので、今回は表を利用せずにカレンダーを生成している部分の説明を少々。
　
前々回の例で利用した階層問合せによるカレンダー生成、前回の例で利用した集計関数cubeによるカレンダー生成いずれも連番を生成するとという点では同じなのですが、階層問合せとcube関数の性格の違いから使い方も少々異なる。いずれにしても知っていると便利なことも多々ありますよ。

では、まず最初は階層問合せから。

カレンダーを生成する前に階層と合わせで一連番号を生成するには、level疑似列を用いて必要なlevelまで階層を作り出せばOK。
（但し、Oracle9iまではこの方法は想定通りに動作しないのでご注意を。10g以降であれば想定通りの結果を返してくれます。）

以下の例では階層問合せを利用し１〜２７までの一連番号を生成したものです。

SCOTT> select level
  2    from dual
  3    connect by level <= 27;

     LEVEL
----------
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        25
        26
        27

27行が選択されました。

SCOTT> 

上記の一連番号を利用し、実行同日を含む２７日前までの日付を求めてみます。

SCOTT> l
  1  select trunc(sysdate) - (level-1)
  2  from dual
  3  connect by level <= 27
  4* order by 1
SCOTT> /

TRUNC(SY
--------
08-03-05
08-03-06
08-03-07
08-03-08
08-03-09
08-03-10
08-03-11
08-03-12
08-03-13
08-03-14
08-03-15
08-03-16
08-03-17
08-03-18
08-03-19
08-03-20
08-03-21
08-03-22
08-03-23
08-03-24
08-03-25
08-03-26
08-03-27
08-03-28
08-03-29
08-03-30
08-03-31

27行が選択されました。

SCOTT> 

できましたよね。簡単です。

次に集計関数cubeを利用する方法です。
cubeに関するマニュアルも事前に読んでおくといいですよ。

一連版を生成するために、cube関数の以下のような性質を利用しています。

SCOTT> select 1
  2  from dual
  3  group by cube(1);

         1
----------
         1
         1

SCOTT> select 1
  2  from dual
  3  group by cube(1,1);

         1
----------
         1
         1
         1
         1

SCOTT> select 1
  2  from dual
  3  group by cube(1,1,1);

         1
----------
         1
         1
         1
         1
         1
         1
         1
         1

8行が選択されました。

SCOTT> 

階層問合せのような柔軟性はないのですが、３２件のデータを生成するには cube(1,1,1,1,1)とすればいいわけです。

SCOTT> select 1
  2  from dual
  3  group by cube(1,1,1,1,1);

         1
----------
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1
         1

32行が選択されました。

SCOTT> 

ただ一連番号にはなっていません。単に３２行の結果を得たたけです。そこでronum疑似列を利用して１〜２７までの一連番号を求めます。

SCOTT> select rownum
  2  from (select 1 from dual group by cube(1,1,1,1,1))
  3  where rownum <= 27;

    ROWNUM
----------
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        25
        26
        27

27行が選択されました。

SCOTT> 

ここまでできればあとは簡単。階層問合せと同じように日付を生成してみましょう。

SCOTT> select trunc(sysdate) - (rownum-1)
  2  from (select 1 from dual group by cube(1,1,1,1,1))
  3  where rownum <= 27
  4  order by 1;

TRUNC(SY
--------
08-03-05
08-03-06
08-03-07
08-03-08
08-03-09
08-03-10
08-03-11
08-03-12
08-03-13
08-03-14
08-03-15
08-03-16
08-03-17
08-03-18
08-03-19
08-03-20
08-03-21
08-03-22
08-03-23
08-03-24
08-03-25
08-03-26
08-03-27
08-03-28
08-03-29
08-03-30
08-03-31

27行が選択されました。

SCOTT> 

cube関数はOracle9iから利用できる関数なのでOracle9iでこんなことを行いたい場合には前述した階層問い合せの代役にもなりますね。

Enjoy SQL!

タイムゾーン de 自動調整 #2

タイムゾーン de 自動調整の続きです。 前回階層問合せを利用して実現した方法を集計関数cubeで置き換えた例。

クライアントのタイムゾーン(SESSIONTIMEZONE)を確認。(タイムゾーンはJST）。

SCOTT> select sessiontimezone from dual;

SESSIONTIMEZONE
-----------------------------------------------------------------
+09:00

SCOTT> l
  1  select
  2    cal."date",
  3    nvl(logs."activity",0) as "activity"
  4  from
  5    (
  6      select
  7        "date",
  8        count(ts_ltz) as "activity"
  9      from
 10        (
 11          select
 12            to_char(ts_ltz, 'YYYY/MM/DD') as "date",
 13            ts_ltz
 14          from
 15            ts_test
 16        )
 17      group by
 18        "date"
 19    ) logs
 20    right outer join
 21    (
 22      select
 23        to_char(
 24          trunc(sysdate) - (rownum - 1),
 25          'YYYY/MM/DD'
 26        ) as "date"
 27      from
 28        (
 29          select 1
 30          from
 31            dual
 32          group by
 33            cube (1,1,1,1,1)
 34        )
 35      where
 36        rownum <= 27
 37    ) cal
 38    on logs."date" = cal."date"
 39  order by
 40*   cal."date"
SCOTT> /

date         activity
---------- ----------
2008/03/02          2
2008/03/03          2
2008/03/04          2
2008/03/05          2
2008/03/06          2
2008/03/07          2
2008/03/08          2
2008/03/09          2
2008/03/10          2
2008/03/11          2
2008/03/12          2
2008/03/13          2
2008/03/14          2
2008/03/15          2
2008/03/16          2
2008/03/17          2
2008/03/18          2
2008/03/19          2
2008/03/20          2
2008/03/21          2
2008/03/22          2
2008/03/23          2
2008/03/24          0
2008/03/25          2
2008/03/26          2
2008/03/27          3
2008/03/28          0

27行が選択されました。

SCOTT> 
<

クライアントのタイムゾーンをUTCへ変更

SCOTT> alter session set time_zone='UTC';

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

SCOTT>
SCOTT> l
  1  select
  2    cal."date",
  3    nvl(logs."activity",0) as "activity"
  4  from
  5    (
  6      select
  7        "date",
  8        count(ts_ltz) as "activity"
  9      from
 10        (
 11          select
 12            to_char(ts_ltz, 'YYYY/MM/DD') as "date",
 13            ts_ltz
 14          from
 15            ts_test
 16        )
 17      group by
 18        "date"
 19    ) logs
 20    right outer join
 21    (
 22      select
 23        to_char(
 24          trunc(sysdate) - (rownum - 1),
 25          'YYYY/MM/DD'
 26        ) as "date"
 27      from
 28        (
 29          select 1
 30          from
 31            dual
 32          group by
 33            cube (1,1,1,1,1)
 34        )
 35      where
 36        rownum <= 27
 37    ) cal
 38    on logs."date" = cal."date"
 39  order by
 40*   cal."date"
SCOTT> /

date         activity
---------- ----------
2008/03/02          2
2008/03/03          2
2008/03/04          2
2008/03/05          2
2008/03/06          2
2008/03/07          2
2008/03/08          2
2008/03/09          2
2008/03/10          2
2008/03/11          2
2008/03/12          2
2008/03/13          2
2008/03/14          2
2008/03/15          2
2008/03/16          2
2008/03/17          2
2008/03/18          2
2008/03/19          2
2008/03/20          2
2008/03/21          2
2008/03/22          2
2008/03/23          1
2008/03/24          1
2008/03/25          2
2008/03/26          2
2008/03/27          2
2008/03/28          0

27行が選択されました。

SCOTT> 

階層問合せほどの柔軟性はないのですがcubeでも同様のことができるんですよ。

タイムゾーン de 自動調整

Python Challengeは気が向いた時にやるとして、今日は、タイムゾーンで日時の自動調整をして楽をしようというお話。

Oracleには、timestamp with local time zone型（マニュアルの説明はわかりにくいかも)という便利な日時データ型があります。この日時データ型で日時を保存すると、クライアント側ではクライアントのタイムゾーンに調整された日時を参照することができるようになります。
timestamp with local time zone型はデータベースの作成時に指定されたタイムゾーンで日時データを保持（クライアント側とタイムゾーンが異なる場合はデータベース側のタイムゾーンへ自動調整されます）します。

言葉で言っても分かり憎いでしょうから、早速、例をお見せしましょう。　といっても少々変った例なので（Oracleの）SQL初心者向きではないですが。。

●●●この例の環境及び条件の説明●●●

データベース（この例の場合はOracle10g R1）のタイムゾーン(DBTIMEZONE)は、UTC。
クライアント（この例の場合はSQL*Plus）のタイムゾーン(SESSIONTIMEZONE)は、+9（つまりJST)とUTCをalter sessionにて変更する。
ts_test表には、TIMESTAMP WITH LOCAL TIME ZONE型（今回の場合はUTCで）で２／２８から３／２７までのあるアクティビティのログ（日時データのみ）が記録されている。（尚、アクティビティの無い日のログは記録されていない。）

というデータ、環境で、実行当日を含む直近２７日分のアクティビティ数を日毎に集計して日付順に取得する。アクティビティが無い日はアクティビティ数を０として日付を表示する。
（但し、ts_test以外の表は使わずに実現する。必須じゃないけど、できればSQL１文で！）

では、早速。

　
データベースタイムゾーン(DBTIMEZONE)は、UTCであることを確認。

（ちなみに、データベースに既にTIMESTAMP WITH LOCAL TIME ZONE型を持つ表が存在しなければ、alter database文で変更可能。)

Last login: Fri Mar 28 05:01:29 on console
Welcome to Darwin!
G5Server:˜ discus$ su - oracle


Password:
G5Server:˜ oracle$ 
G5Server:˜ oracle$ sqlplus /nolog

SQL*Plus: Release 10.1.0.3.0 - Production on 金 3月 28 07:52:49 2008

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

> 
> conn scott/tiger@catfish
接続されました。
SCOTT> select dbtimezone from dual;

DBT
---
UTC

次にクライアントのタイムゾーン(SESSIONTIMEZONE)を確認。(JSTになっている）。

SCOTT> select sessiontimezone from dual;

SESSIONTIMEZONE
-----------------------------------------------------------------
+09:00

ts_test表の登録データを確認する。（クライアントのタイムゾーン(JST)へ自動調整されて表示される。）

TIMESTAMP WITH LOCAL TIME ZONE型として登録されている日時データはクライアントのタイムゾーンに自動調整されて表示される。
簡単に確認する方法としてCURRENT_TIMESTAMP疑似列を問い合わせて現状を確認することがもできる。

SCOTT> select current_timestamp from dual;

CURRENT_TIMESTAMP
-----------------------------------------------------------------
08-03-28 08:07:33.082296 +09:00

SCOTT> desc ts_test         
名前                        NULL?    型
-------------------------- -------- ----------------------------
TS_LTZ                              TIMESTAMP(6) WITH LOCAL TIME
                                    ZONE


SCOTT> select * from ts_test order by ts_ltz;

TS_LTZ
-----------------------------------------------------------------
08-02-29 00:00:00.000000
08-02-29 23:59:59.999999
08-03-01 00:00:00.000000
08-03-01 23:59:59.999999
08-03-02 00:00:00.000000
08-03-02 23:59:59.999999
08-03-03 00:00:00.000000
08-03-03 23:59:59.999999
08-03-04 00:00:00.000000
08-03-04 23:59:59.999999
08-03-05 00:00:00.000000
08-03-05 23:59:59.999999
08-03-06 00:00:00.000000
08-03-06 23:59:59.999999
08-03-07 00:00:00.000000
08-03-07 23:59:59.999999
08-03-08 00:00:00.000000
08-03-08 23:59:59.999999
08-03-09 00:00:00.000000
08-03-09 23:59:59.999999
08-03-10 00:00:00.000000
08-03-10 23:59:59.999999
08-03-11 00:00:00.000000
08-03-11 23:59:59.999999
08-03-12 00:00:00.000000
08-03-12 23:59:59.999999
08-03-13 00:00:00.000000
08-03-13 23:59:59.999999
08-03-14 00:00:00.000000
08-03-14 23:59:59.999999
08-03-15 00:00:00.000000
08-03-15 23:59:59.999999
08-03-16 00:00:00.000000
08-03-16 23:59:59.999999
08-03-17 00:00:00.000000
08-03-17 23:59:59.999999
08-03-18 00:00:00.000000
08-03-18 23:59:59.999999
08-03-19 00:00:00.000000
08-03-19 23:59:59.999999
08-03-20 00:00:00.000000
08-03-20 23:59:59.999999
08-03-21 00:00:00.000000
08-03-21 23:59:59.999999
08-03-22 00:00:00.000000
08-03-22 23:59:59.999999
08-03-23 00:00:00.000000
08-03-23 23:59:59.999999
08-03-25 00:00:00.000000
08-03-25 23:59:59.999999
08-03-26 00:00:00.000000
08-03-26 23:59:59.999999
08-03-27 08:59:59.999999
08-03-27 09:00:00.000000
08-03-27 10:12:11.928490

55行が選択されました。

SCOTT>

では、上記のデータを直近２７日分のアクティビティ数を日毎に集計。アクティビティの無い日はアクティビティ数を０として問い合わせるSQL文。

以下の例では、Oracle独自の階層問合せのlevel疑似列を利用しSYSDATEから２７日分のカレンダーを生成しログと外部結合することで、ログデータが存在していない日の
アクティビティ数を０として取得している。

SCOTT> l
  1  select
  2    cal."date",
  3    nvl(logs."activity",0) as "activity"
  4  from
  5    (
  6      select
  7        "date",
  8        count(ts_ltz) as "activity"
  9      from
 10        (
 11          select
 12            to_char(ts_ltz, 'YYYY/MM/DD') as "date",
 13            ts_ltz
 14          from
 15            ts_test
 16        )
 17      group by
 18        "date"
 19    ) logs
 20    right outer join
 21    (
 22      select
 23        to_char(trunc(sysdate) - (level - 1), 
 24        'YYYY/MM/DD') as "date"
 25      from
 26        dual
 27      where
 28        to_char(trunc(sysdate) - (level - 1), 
 29        'YYYY/MM/DD') <= trunc(sysdate)
 30      connect by
 31        level <= 27
 32    ) cal
 33    on logs."date" = cal."date"
 34  order by
 35*   cal."date"
SCOTT> /

date         activity
---------- ----------
2008/03/02          2
2008/03/03          2
2008/03/04          2
2008/03/05          2
2008/03/06          2
2008/03/07          2
2008/03/08          2
2008/03/09          2
2008/03/10          2
2008/03/11          2
2008/03/12          2
2008/03/13          2
2008/03/14          2
2008/03/15          2
2008/03/16          2
2008/03/17          2
2008/03/18          2
2008/03/19          2
2008/03/20          2
2008/03/21          2
2008/03/22          2
2008/03/23          2
2008/03/24          0
2008/03/25          2
2008/03/26          2
2008/03/27          3
2008/03/28          0

27行が選択されました。

SCOTT>

では、クライアントのタイムゾーンをJSTからUTCへ変更してみましょう。(表示しているデータは前述の例と同じts_test表の内容ですがUTCに自動調整されて表示されています。)

SCOTT> alter session set time_zone='UTC';

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

SCOTT> select * from ts_test order by ts_ltz;

TS_LTZ
-------------------------------------------------------
08-02-28 15:00:00.000000
08-02-29 14:59:59.999999
08-02-29 15:00:00.000000
08-03-01 14:59:59.999999
08-03-01 15:00:00.000000
08-03-02 14:59:59.999999
08-03-02 15:00:00.000000
08-03-03 14:59:59.999999
08-03-03 15:00:00.000000
08-03-04 14:59:59.999999
08-03-04 15:00:00.000000
08-03-05 14:59:59.999999
08-03-05 15:00:00.000000
08-03-06 14:59:59.999999
08-03-06 15:00:00.000000
08-03-07 14:59:59.999999
08-03-07 15:00:00.000000
08-03-08 14:59:59.999999
08-03-08 15:00:00.000000
08-03-09 14:59:59.999999
08-03-09 15:00:00.000000
08-03-10 14:59:59.999999
08-03-10 15:00:00.000000
08-03-11 14:59:59.999999
08-03-11 15:00:00.000000
08-03-12 14:59:59.999999
08-03-12 15:00:00.000000
08-03-13 14:59:59.999999
08-03-13 15:00:00.000000
08-03-14 14:59:59.999999
08-03-14 15:00:00.000000
08-03-15 14:59:59.999999
08-03-15 15:00:00.000000
08-03-16 14:59:59.999999
08-03-16 15:00:00.000000
08-03-17 14:59:59.999999
08-03-17 15:00:00.000000
08-03-18 14:59:59.999999
08-03-18 15:00:00.000000
08-03-19 14:59:59.999999
08-03-19 15:00:00.000000
08-03-20 14:59:59.999999
08-03-20 15:00:00.000000
08-03-21 14:59:59.999999
08-03-21 15:00:00.000000
08-03-22 14:59:59.999999
08-03-22 15:00:00.000000
08-03-23 14:59:59.999999
08-03-24 15:00:00.000000
08-03-25 14:59:59.999999
08-03-25 15:00:00.000000
08-03-26 14:59:59.999999
08-03-26 23:59:59.999999
08-03-27 00:00:00.000000
08-03-27 01:12:11.928490

55行が選択されました。

SCOTT> 
SCOTT> l
  1  select
  2    cal."date",
  3    nvl(logs."activity",0) as "activity"
  4  from
  5    (
  6      select
  7        "date",
  8        count(ts_ltz) as "activity"
  9      from
 10        (
 11          select
 12            to_char(ts_ltz, 'YYYY/MM/DD') as "date",
 13            ts_ltz
 14          from
 15            ts_test
 16        )
 17      group by
 18        "date"
 19    ) logs
 20    right outer join
 21    (
 22      select
 23        to_char(trunc(sysdate) - (level - 1), 
 24        'YYYY/MM/DD') as "date"
 25      from
 26        dual
 27      where
 28        to_char(trunc(sysdate) - (level - 1), 
 29        'YYYY/MM/DD') <= trunc(sysdate)
 30      connect by
 31        level <= 27
 32    ) cal
 33    on logs."date" = cal."date"
 34  order by
 35*   cal."date"
SCOTT> /

date         activity
---------- ----------
2008/03/02          2
2008/03/03          2
2008/03/04          2
2008/03/05          2
2008/03/06          2
2008/03/07          2
2008/03/08          2
2008/03/09          2
2008/03/10          2
2008/03/11          2
2008/03/12          2
2008/03/13          2
2008/03/14          2
2008/03/15          2
2008/03/16          2
2008/03/17          2
2008/03/18          2
2008/03/19          2
2008/03/20          2
2008/03/21          2
2008/03/22          2
2008/03/23          1
2008/03/24          1
2008/03/25          2
2008/03/26          2
2008/03/27          2
2008/03/28          0

27行が選択されました。

SCOTT> 

はい、データベース側でクライアントのタイムゾーンに日時を自動調整してくれるお陰でタイムゾーンが変っても同一SQL文で処理できます。（楽でしょ。）

次回は、同じことを集計関数cubeを使って実現するSQL文の例をお見せします。(Oracle de Fizzbuzz #2を見れば想像できてしまうとは思いますが。。）

ところで、MySQLやPostgreSQLなど他のデータベースではどうするんだろう。。余裕があったら調べてみるか。。。。。

2008/3/29追記
当日から必要な日数分の過去日付を求める階層問合せ部分はもっと簡単にできることに今気付いた。帰宅したら改善したクエリも追加する予定！

ということで以下のように、階層問合せのwhere句の部分は無くてもOKということだったのです。はい。

SCOTT> l
  1  select
  2    cal."date",
  3    nvl(logs."activity",0) as "activity"
  4  from
  5    (
  6       select
  7         "date",
  8         count(ts_ltz) as "activity"
  9       from
 10         (
 11             select
 12               to_char(ts_ltz, 'YYYY/MM/DD') as "date",
 13               ts_ltz
 14             from
 15               ts_test
 16           )
 17         group by
 18           "date"
 19    ) logs
 20    right outer join
 21    (
 22      select
 23        to_char(
 24          trunc(sysdate) - (level - 1),
 25          'YYYY/MM/DD'
 26        ) as "date"
 27      from
 28        dual
 29      connect by
 30         level <= 27
 31    ) cal
 32    on logs."date" = cal."date"
 33  order by
 34*     cal."date"
SCOTT> /

date         activity
---------- ----------
2008/03/03          2
2008/03/04          2
2008/03/05          2
2008/03/06          2
2008/03/07          2
2008/03/08          2
2008/03/09          2
2008/03/10          2
2008/03/11          2
2008/03/12          2
2008/03/13          2
2008/03/14          2
2008/03/15          2
2008/03/16          2
2008/03/17          2
2008/03/18          2
2008/03/19          2
2008/03/20          2
2008/03/21          2
2008/03/22          2
2008/03/23          2
2008/03/24          0
2008/03/25          2
2008/03/26          2
2008/03/27          3
2008/03/28          0
2008/03/29          0

27行が選択されました。

SCOTT> 

PL/SQL で Python Challenge Level 17

さて、ココログのデータベースのデフラグ？作業でログインできなかったので今書いてますが。
Level 17、少々ハマったが解き方は見えた（ような気がする）ので次回はその経過でも。

Level 17は、Web Applicationを作った経験のあるかたなら案外すんなり解けるかもしれない。
問題の画像にそのすべてのヒントが！

Enjoy! Python Challenge!
（Python じゃなくても楽しめるのだ！）

PL/SQL で Python Challenge Level 16完

前回の続きです

さて、Level 16のページには、"let me get this straight"　というタイトルが付けられている。これ自体が大きなヒント。なのでこれ以上は何も言うまい。

問題の解くjavaアプリケーションの内容は、以前、Level 11の処理の流れを書いていたが、その３、４以外の部分は同じ。
但し、Level7で利用した Level7.getBfile()とLevel9で作成したLevel9.writeImageFile()というファンクションとプロシージャを以下のPL/SQLパッケージに纏めた。

CREATE OR REPLACE PACKAGE PYTHONCHALLENGE_UTL AS

  FUNCTION getBfile 
  (
    i_dir_name  IN VARCHAR2,
    i_file_name IN vARCHAR2
  ) RETURN BFILE;
  
  PROCEDURE writeImageFile(
    directoryName IN VARCHAR2,
    fileName      IN VARCHAR2,
    srcImage      IN OUT NOCOPY BLOB
  );

END PYTHONCHALLENGE_UTL;

CREATE OR REPLACE PACKAGE BODY PYTHONCHALLENGE_UTL AS

  FUNCTION getBfile 
  (
    i_dir_name  IN VARCHAR2,
    i_file_name IN VARCHAR2
  ) RETURN bfile AS
    v_file BFILE;
  BEGIN
    v_file := BFILENAME(UPPER(i_dir_name),i_file_name);
    RETURN v_file;
  END getBfile;

  PROCEDURE writeImageFile(
    directoryName IN VARCHAR2,
    fileName      IN VARCHAR2,
    srcImage      IN OUT NOCOPY BLOB
  ) IS
    file utl_file.file_type;
  BEGIN
    file := UTL_FILE.FOPEN(UPPER(directoryName), fileName, 'w', 32767);
    DBMS_LOB.OPEN(srcImage, DBMS_LOB.LOB_READONLY);

    DECLARE
      v_raw   RAW(32767);
      amount  INTEGER;
      offset  INTEGER;
    BEGIN
      offset := 1;
      LOOP
        amount := 32767;
        DBMS_LOB.READ(srcImage, amount, offset, v_raw);
        UTL_FILE.PUT_RAW(file, v_raw, true);
        offset := offset + amount;
      END LOOP;
    EXCEPTION
      WHEN no_data_found THEN
        NULL;
      WHEN OTHERS THEN
        UTL_FILE.FCLOSE(file);
        DBMS_LOB.CLOSE(srcImage);
        RAISE_APPLICATION_ERROR(-20001, sqlerrm());
    END;

    UTL_FILE.FCLOSE(file);
    DBMS_LOB.CLOSE(srcImage);
  END writeImageFile;
  
END PYTHONCHALLENGE_UTL;
/

上記のパッケージをJava Stored Procedureから利用するわけです。javaのソースコードは載せませんよ。ネタバレになっちゃいますから。

次に、デプロイしたjava classは以下のようにしてJava Stored Procedureとして定義します。

CREATE OR REPLACE PACKAGE LEVEL16 AS
  FUNCTION getResult RETURN NUMBER AS 
  LANGUAGE JAVA NAME 'jp.macdeoracle.Level16.getResult() return java.lang.boolean';
END LEVEL16;

では、SQL*Plusから実行してみましょう！

Last login: Sun Mar 23 20:29:41 on ttyp2
Welcome to Darwin!
G5Server:˜ discus$ ssh oracle@corydoras
oracle@corydoras's password: 
Last login: Sun Mar 23 20:31:49 2008 from 192.168.1.19
[oracle@corydoras ˜]$ cd python_challenge
[oracle@corydoras python_challenge]$ ll
合計 264
-rw-r--r-- 1 oracle oinstall 254006  3月 23 16:26 level16.gif

[oracle@corydoras python_challenge]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on 日 3月 23 20:58:34 2008

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

> conn scott/tiger
接続されました。
SCOTT> l
  1  select
  2    case
  3      when level16.getResult() = 1 then '成功！'
  4      else '失敗！'
  5    end as "Level16"
  6* from dual
SCOTT> /

Level16
---------
成功！

SCOTT> !ls -l
合計 504
-rw-r--r-- 1 oracle oinstall 254006  3月 23 16:26 level16.gif
-rw-r--r-- 1 oracle oinstall 239515  3月 23 21:02 level16_result.png

SCOTT> 

これだけでもかなりのヒントになっているような気もしますが。。。
MacOSXのChicken of the VNC(MacOSX向けのVNC Client)経由でLinux(CentOS5)にある結果を確認！

ということで、Python Challenge Level 16完。　Level 17は気が向いたら載せると思います。　
Enjoy Python Challenge!

PL/SQL で Python Challenge Level 16 - ２年５ヶ月ぶり

そう、あれは、このブログをはじめたころ、Oracle10g R1 for MacOSX ServerとPL/SQL（画像処理関係はjava stored procedure）を利用し、Python Challengeに　PL/SQLでチャレンジしていたっけ〜〜。遠い目。

アクセスログを見ていたら最近、またPython Challengeのキーワード検索が多くヒットしているのにびっくり！。
前述のエントリを書いていたのが約２年半前になるわけですから！　ということで、久々にちょっとだけ再開してみようかと。。Level 16を見てみる。

Level 16の問題の画像を見ると、いかにもわざとらしい柄というか模様が目につく！。

で、Level 16のページタイトルもいつものようにヒントになっている。

画像にある模様を眺めつつ、ページタイトルの英文（簡単な英文です）を読み試しにJavaだけで作ってみると、考え方はいいと思うのだが全然答えにはなっていない。。。

こうか？　ん、、、、それとも、こうか？　でも違う。　あ、横にしてたよ。。。あはは。。(^^;;
と独り言を言いつつ何とか答えを見つけました。。は〜〜っ。暫くぶりだと疲れるわ。

次回は答えは書きませんが、Level 16の結果をぼかしたスナップショットを載せる予定。

ちなみに、今回の環境は以下。
Database Server : Oracle11g R1 EE for Linux x86

開発用クライアント：
JDeveloper10g 10.1.3 for MacOSX
Oracle SQL Developer 1.1.3 for MacOSX
（Java Stored Procedure、PL/SQL package、Java関連で利用した）

準備が整ったらMacOSXからsshでLinuxのOracle11gへ接続して実行！
結果確認は、MacOSXのVNCからLinuxへ接続して確認するという面倒なことまでしてMacを絡めている。
（Mac de Oracle ですから！　笑）

尚、以前のように、なるべくPL/SQLやSQLレベルで問題を解いて行くがPL/SQLやSQLでは不可能な処理はJava stored procedureで行う。Level 16もLevel14と同じような処理になっている。

Installation of Oracle 11g R1 (11.1.0.6.0) on SuSE Linux Enteprise Server (SLES) 10 and OpenSuSE 10.3 (x86_64)

少々前に、Oracle10g R2 on OpenSuSE10.2に関するインストレーション手順のドキュメントがNovelのサイトから入手できることを書いたが、Oracle ACE Memberのivan kartik氏のサイトには、Oracle11g R1をSuSE Linux Enterprise Server(SLES) 10 及び OpenSuSE 10.3（但し今のところ、64ビットのみ）へインストールする際のHOW TOが紹介されている。近いうちに３２ビット版のドキュメントも公開する予定とのこと。
前回の記事も含めて備忘録ということで。

Installation of Oracle 11g R1 (11.1.0.6.0) on SuSE Linux Enteprise Server (SLES) 10 and OpenSuSE 10.3

Mac de Ruby on Rails - #8 - Oracleと遊ぶ #7

以前の記事で以下のように書いていたことを覚えていますか？

注）
赤太字で示したシンボリックリンクは今回事前に作成したもので、それらのシンボリックリンクは作成しなくても通常利用には問題ない。以前の記事参照のこと。
尚、今回は事前に参照していた資料にシンボリックリンクの作成に関する記述があったため前述のシンボリックリンクを作成した。
（ほんとうに必要なのか？　という点については未検証であることを書き加えておく。余計なものだとしても悪さはしないでしょう。きっと。）

---

バックナンバー:
Mac de Ruby on Rails - #1
Mac de Ruby on Rails - #2 - Oracleと遊ぶ #1
Mac de Ruby on Rails - #3 - Oracleと遊ぶ #2
Mac de Ruby on Rails - #4 - Oracleと遊ぶ #3
Mac de Ruby on Rails - #5 - Oracleと遊ぶ #4
Mac de Ruby on Rails - #6 - Oracleと遊ぶ #5
Mac de Ruby on Rails - #7 - Oracleと遊ぶ #6

---

先日、興味本位で、もし、前述したシンボリックリンクを作成しなかったらどうなるかを試してみた。

Macintosh:ruby-oci8-1.0.0 discus$ make
ruby setup.rb config 
---> lib
---> lib/DBD
---> lib/DBD/OCI8
<--- lib/DBD/OCI8
<--- lib/DBD
<--- lib
---> ext
---> ext/oci8
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby /Users/discus/ruby-oci8-1.0.0/ext/oci8/extconf.rb 
checking for load library path... (DYLD_LIBRARY_PATH)... 
  found: /Users/Shared/OracleInstantClient/libclntsh.dylib.10.1 looks like an instant client.
checking for cc... ok
checking for gcc... yes
checking for LP64... no
checking for ruby header... ok
---------------------------------------------------
error messages:
Could not compile with Oracle instant client.
/Users/Shared/OracleInstantClient/libclntsh.dylib could not be found.
You may need to make a symbolic link.
   cd /Users/Shared/OracleInstantClient
   ln -s libclntsh.dylib.10.1 libclntsh.dylib

---------------------------------------------------
See:
 * http://ruby-oci8.rubyforge.org/ja/HowToInstall.html
 * http://ruby-oci8.rubyforge.org/ja/ReportInstallProblem.html

*** /Users/discus/ruby-oci8-1.0.0/ext/oci8/extconf.rb failed ***

ご覧の通りエラーになりますし、シンボリックリンクが無いのが原因かもしれないと示唆される。分かり易くていいな〜。
当然、指摘された通りにシンボリックリンクを作成してあげれば問題は解消される。

Oracle de XMLDB #26 - XMLTYPEの更新

OTN-Jで、PL/SQLでXMLTYPEのあるの要素の値を変更したり、ある要素の値を参照したいというスレッドがあったのでレスしておいた。

そういえば、XQueryやXPathを使ったOracle XMLDBネタもやっているが更新系のはやってないな（というかまだ、XMLの更新、追加、削除に関する標準が定まっていないわけだから仕方ない。）

ということで、前述したOTN-Jのネタをもう少しフラッシュアップして？！(for updateなどが抜けていたので。。）残しておく事にした。

まず、hogehoge表に以下のようなXMLを登録する。

SCOTT> 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 Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production

SCOTT> 
SCOTT>  desc hogehoge
 名前                                        NULL?    型
 ----------------------------------------- -------- ----------------------------
 SEQNO                                     NOT NULL NUMBER
 XMLINFO                                            XMLTYPE

SCOTT>  
SCOTT> insert into hogehoge values(1,xmltype('<?xml version="1.0"?><addressbook>
<person id="1"><name>岡田</name><age>30</age>
<address zipcode="123456">東京都ホゲ市ホゲ町１−１</address></person><person id="2">
<name>安倍</name><age>50</age>
<address zipcode="1050011">東京都ホゲ区ホゲ田町１−１−１</address>
</person></addressbook>'));

1行が作成されました。

SCOTT> commit;

コミットが完了しました。

SCOTT> 
SCOTT> 
SCOTT> set timi on
SCOTT> set long 4000
SCOTT> col xmlinfo for a80
SCOTT> set linesize 132
SCOTT> set pagesize 1000
SCOTT> select * from hogehoge where seqno=1;

     SEQNO XMLINFO
---------- ------------------------------------------------------------
         1 <?xml version="1.0"?><addressbook><person id="1"><name>岡田<
           /name><age>30</age><address zipcode="123456">東京都ホゲ市ホ
           ゲ町１−１</address></person><person id="2"><name>安倍</name>
           <age>50</age><address zipcode="1050011">東京都ホゲ区ホゲ田
           町１−１−１</address></person></addressbook>


経過: 00:00:00.01
SCOTT> 

上記のようなXML文書を対象に特定のid属性値を持つperson要素に含まれるname要素の値を変更するストアドファンクション。
（もうすこし平たく言うと、指定した名前を変更するストアドファンクション。略し過ぎか・・・）

XML文書の変更方法は他にもあるが、PL/SQLパッケージで行うにはDOM APIであるDBMS_XMLDOMパッケージを利用して行う。
尚、XMLTYPEをDBMS_XMLDOMパッケージで更新する際のポイントは、XMLTYPEインスタンスからDOMインスタンスを生成し、DOMインスタンに対して必要な更新操作行った上で、XMLTYPEインスタンスを表へ書き戻すという所。（該当部分は赤太字にしてあります。）

SCOTT> l
  1  create or replace
  2  function changePersonName
  3  (
  4    iKey      in number,
  5    iPersonId in varchar2,
  6    iNewName  in varchar2
  7  ) return xmltype
  8  is
  9    xml               xmlType;
 10    personNodeList    dbms_xmldom.DomNodeList;
 11    personNode        dbms_xmldom.DomNode;
 12    nameNodeList      dbms_xmldom.DomNodeList;
 13    personAttrNodeMap dbms_xmldom.DomNamedNodeMap;
 14    idAttrNode        dbms_xmldom.DomNode;
 15    wKey              number;
 16    wPersonId         varchar2(38);
 17    wNewName          varchar2(60);
 18  begin
 19    wKey      := iKey;
 20    wPersonId := iPersonId;
 21    wNewName  := iNewName;
 22
 23    select xmlinfo into xml from hogehoge where seqno = wKey for update;
 24
 25    personNodeList := dbms_xmldom.getElementsByTagName(
 26                        dbms_xmldom.newDomDocument(xml)
 27                        ,'person'
 28                      );
 29
 30    if not dbms_xmldom.isNull(personNodeList) then
 31      for i in 0..dbms_xmldom.getLength(personNodeList) loop
 32        personNode := dbms_xmldom.item(personNodeList, i);
 33        personAttrNodeMap := dbms_xmldom.getAttributes(personNode);
 34        idAttrNode := dbms_xmldom.getNamedItem(personAttrNodeMap, 'id');
 35        if dbms_xmldom.getNodeValue(idAttrNode) = wPersonId then
 36          nameNodeList := dbms_xmldom.getChildrenByTagName(
 37                            dbms_xmldom.makeElement(personNode)
 38                            ,'name'
 39                          );
 40          dbms_xmldom.setNodeValue(
 41            dbms_xmldom.getFirstChild(dbms_xmldom.item(nameNodeList, 0))
 42            ,wNewName
 43          );
 44          update hogehoge set xmlinfo = xml where seqno = wKey;
 45          exit;
 46        end if;
 47      end loop;
 48    end if;
 49    return xml;
 50* end;
SCOTT> /

ファンクションが作成されました。

経過: 00:00:00.04
SCOTT> 
SCOTT> 
SCOTT> 
SCOTT> l
  1  declare
  2    xml xmlType;
  3  begin
  4    xml := changePersonName(1, '1', '福田ほげ蔵');
  6    commit;
  7* end;
SCOTT> /

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:00.03
SCOTT> 
SCOTT> 
SCOTT> select * from hogehoge where seqno=1;
     SEQNO XMLINFO
---------- --------------------------------------------------------------------------------
        1 <?xml version="1.0"?>
           <addressbook>
             <person id="1">
               <name>福田ほげ蔵</name>
               <age>30</age>
               <address zipcode="123456">東京都ホゲ市ホゲ町１−１</address>
             </person>
             <person id="2">
               <name>安倍</name>
               <age>50</age>
               <address zipcode="1050011">東京都ホゲ区ホゲ田町１−１−１</address>
             </person>
           </addressbook>


経過: 00:00:00.00
SCOTT> 

もうお気づきだと思うが、Oracle11gでも発生しているこちらからは操作できないところでwhitespaceが追加されたり、されなかったりする。まあこれ自体は大抵の場合問題にはならないのだが。。

あともうひとつの話題は特定の要素の値を取り出したいということ。これだけならDBMS_XMLDOMパッケージを使わなくても、SQL/XMLを使えば簡単ですよね。
XMLQuery()関数を使って、id属性値が "1"であるperson要素以下にあるage要素の値を参照する例です。

SCOTT> set linesize 80
SCOTT> l
  1  select
  2    xmlquery(
  3      'let $n := $xmldoc//person[@id="1"]/age/text()
  4       return $n'
  5      passing by value xmlinfo as "xmldoc"
  6      returning content
  7    ) as "age"
  8* from hogehoge where seqno=1
SCOTT> /

age
--------------------------------------------------------------------------------
30

経過: 00:00:00.04
SCOTT> 

ちなみに、Oracleのマニュアルは以下の辺りを参照するとよいと思いますが、DOM、XQueryやXPathに関してはXML関連のサイトもググって調べたほうがよいと思います。XMLの操作の基本を理解していれば、あとはどんなツールを使ってそれを行うかということだけですから。

マニュアル
Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス 10g R2 - DBMS_XMLDOM
Oracle Database SQLリファレンス 10g R2 - XMLQUERY

Enjoy!

Mac de Ruby on Rails - #7 - Oracleと遊ぶ #6

さて、前回まででRuby on Rails 2.0.2からOracle11g R1 11.1.0.6.0をアクセスするアプリケーションはできたのだが、まだ、幾つか手お加えたい箇所もある。例えばViewのタイトルやドロップダウンメニューが英語だとか、日付の表示が長過ぎるとか。

---

バックナンバー:
Mac de Ruby on Rails - #1
Mac de Ruby on Rails - #2 - Oracleと遊ぶ #1
Mac de Ruby on Rails - #3 - Oracleと遊ぶ #2
Mac de Ruby on Rails - #4 - Oracleと遊ぶ #3
Mac de Ruby on Rails - #5 - Oracleと遊ぶ #4
Mac de Ruby on Rails - #6 - Oracleと遊ぶ #5

---

そこで、indexページの日付フォーマットを変更してみることにする。（Viewというか、scaffoldでの日本語対応などまだまだ知らないことも多い。それらは次の機会のお楽しみということで・・・）

index.html.erbを以下のように変更して・・・・

pb17:/Volumes/Repository/employee_list discus$
pb17:/Volumes/Repository/employee_list discus$pb17:/Volumes/Repository/employee_list discus$ cd app/views/emps
pb17:/Volumes/Repository/employee_list/app/views/emps discus$ cp index.html.erb index.html.erb.org
pb17:/Volumes/Repository/employee_list/app/views/emps discus$ vi index.html.erb
pb17:/Volumes/Repository/employee_list/app/views/emps discus$ diff index.html.erb.org index.html.erg
17c17,23
<     <td><%=h emp.hiredate %></td>
---
>     <td>
>       <% if emp.hiredate %>
>         <%=h emp.hiredate.to_formatted_s(:db) %>
>       <% else %>
>         <%=h emp.hiredate %>
>       <% end %>
>     </td>
pb17:/Volumes/Repository/employee_list/app/views/emps discus$ 
pb17:/Volumes/Repository/employee_list/app/views/emps discus$ cd $OLDPWD
pb17:/Volumes/Repository/employee_list discus$ ruby script/server
=> Booting WEBrick...
=> Rails application started on http://0.0.0.0:3000
=> Ctrl-C to shutdown server; call with --help for options
[2008-02-24 16:19:46] INFO  WEBrick 1.3.1
[2008-02-24 16:19:46] INFO  ruby 1.8.6 (2007-09-23) [powerpc-darwin8.11.0]
[2008-02-24 16:19:46] INFO  WEBrick::HTTPServer#start: pid=702 port=3000
127.0.0.1 - - [24/Feb/2008:16:20:05 JST] "GET /emps HTTP/1.1" 500 15280
- -> /emps
127.0.0.1 - - [24/Feb/2008:16:20:26 JST] "GET /favicon.ico HTTP/1.1" 200 0
http://localhost:3000/emps -> /favicon.ico
^C[2008-02-24 16:20:59] INFO  going to shutdown ...
[2008-02-24 16:20:59] INFO  WEBrick::HTTPServer#start done.
pb17:/Volumes/Repository/employee_list discus$ cd app/views/emps

なんとか、出来ましたね。RubyもRuby on Railsも始めてですが、なんとかここまでできました〜　:)

”Ruby on Rails2.0.2とOracle11gでそこそこ遊べる環境を作る”　ひとまず、完！

Mac de Ruby on Rails - #6 - Oracleと遊ぶ #5

Ruby on RailsでOracleとそこそこ遊べる環境構築もそろそろ終盤。
今回は、Ruby on RailsでOracle11g R1のデータベースをアクセスする簡単なアプリケーションを作ってみる。
尚、アプリケーションで利用する表は事前に作成しておいた。（Oracleにアクセスできることが確認できれば十分なので）

---

バックナンバー:
Mac de Ruby on Rails - #1
Mac de Ruby on Rails - #2 - Oracleと遊ぶ #1
Mac de Ruby on Rails - #3 - Oracleと遊ぶ #2
Mac de Ruby on Rails - #4 - Oracleと遊ぶ #3
Mac de Ruby on Rails - #5 - Oracleと遊ぶ #4

---

まず事前に、emp表を元にemps表を作り、数件データを追加しておきます。

pb17:˜ discus$
pb17:˜ discus$
pb17:˜ discus$ sqlplus /nolog

SQL*Plus: Release 10.1.0.3.0 - Production on 日 2月 24 15:55:07 2008

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

SQL> conn scott/tiger@lampeye
接続されました。
SQL> create table emps as select * from emp; 

表が作成されました。

SQL> alter table emps rename column empno to id;

表が変更されました。

SQL> alter table emps add constraint emp_pk primary key (id); 

表が変更されました。

SQL> create sequence emps_seq;

順序が作成されました。

SQL> insert into emps(id,ename) values(8888,'ヌルポ');

1行が作成されました。

SQL> commit;

コミットが完了しました。

SQL> set linesize 132
SQL> set pagesize 1000
SQL> select * from emps order by id;

        ID ENAME      JOB              MGR HIREDATE        SAL       COMM     DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
      7369 SMITH      CLERK           7902 80-12-17        800                    20
      7499 ALLEN      SALESMAN        7698 81-02-20       1600        300         30
      7521 WARD       SALESMAN        7698 81-02-22       1250        500         30
      7566 JONES      MANAGER         7839 81-04-02       2975                    20
      7654 MARTIN     SALESMAN        7698 81-09-28       1250       1400         30
      7698 BLAKE      MANAGER         7839 81-05-01       2850                    30
      7782 CLARK      MANAGER         7839 81-06-09       2450                    10
      7839 KING       PRESIDENT            81-11-17       5000                    10
      7844 TURNER     SALESMAN        7698 81-09-08       1500          0         30
      7900 JAMES      CLERK           7698 81-12-03        950                    30
      7902 FORD       ANALYST         7566 81-12-03       3000                    20
      7934 MILLER     CLERK           7782 82-01-23       1300                    10
      8888 ヌルポ
      9999 ほげ       ENGINEER        7566 08-01-01       2500                    20

14行が選択されました。

SQL> exit
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing optionsとの接続が切断されました。
pb17:˜ discus$
pb17:˜ discus$

次にOracleデータベースを利用するプロジェクトを作成します。
-d　オプションを付けるとOracle向け構成ファイル:databaase.ymlを生成してくれます。

pb17:˜ discus$ cd /Volumes/Repository
pb17:˜ discus$
pb17:/Volumes/Repository discus$ rails -h          
Usage: /opt/local/bin/rails /path/to/your/app [options]

Options:
    -r, --ruby=path                  Path to the Ruby binary of your choice (otherwise scripts use env, dispatchers current path).
                                     Default: /opt/local/bin/ruby
    -d, --database=name              Preconfigure for selected database (options: mysql/oracle/postgresql/sqlite2/sqlite3).
                                     Default: mysql
    -f, --freeze                     Freeze Rails in vendor/rails from the gems generating the skeleton
                                     Default: false

・・・・中略・・・・

Example:
    rails ˜/Code/Ruby/weblog

    This generates a skeletal Rails installation in ˜/Code/Ruby/weblog.
    See the README in the newly created application to get going.

今回は、employee_listというプロジェクトを作ります。（コードとディレクトリーが自動的い生成されていく・・・）
database.ymlを環境の合わせ変更！

pb17:/Volumes/Repository discus$ rails -d oracle employee_list
      create  
      create  app/controllers
      create  app/helpers
      create  app/models

・・・・中略・・・・

      create  log/server.log
      create  log/production.log
      create  log/development.log
      create  log/test.log
pb17:/Volumes/Repository discus$
pb17:/Volumes/Repository discus$ 
pb17:/Volumes/Repository discus$ cd employee_list/config
pb17:/Volumes/Repository discus$
pb17:/Volumes/Repository discus$
pb17:/Volumes/Repository/employee_list/config discus$ vi database.yml
pb17:/Volumes/Repository/employee_list/config discus$ cat database.yml
# Oracle/OCI 8i, 9, 10g
#
# Requires Ruby/OCI8:
#  http://rubyforge.org/projects/ruby-oci8/
#
# Specify your database using any valid connection syntax, such as a
# tnsnames.ora service name, or a sql connect url string of the form:
#
#   //host:[port][/service name]
#
# By default prefetch_rows (OCI_ATTR_PREFETCH_ROWS) is set to 100. And
# until true bind variables are supported, cursor_sharing is set by default
# to 'similar'. Both can be changed in the configation below; the defaults
# are equivalent to specifying:
#
#  prefetch_rows: 100
#  cursor_sharing: similar
#

development:
  adapter: oracle
  database: lampeye
  username: scott
  password: tiger

# Warning: The database defined as 'test' will be erased and
# re-generated from your development database when you run 'rake'.
# Do not set this db to the same as development or production.
test:
  adapter: oracle
  database: lampeye
  username: test
  password: tiger

production:
  adapter: oracle
  database: lampeye
  username: prod
  password: tiger
pb17:/Volumes/Repository/employee_list/config discus$
pb17:/Volumes/Repository/employee_list/config discus$
pb17:/Volumes/Repository/employee_list/config discus$

ここまでできたら、emps表を操作、表示するためのscaffold（足場）を生成する。（あれまあ、簡単にできるんだなぁ）

pb17:/Volumes/Repository/employee_list/config discus$ cd ..
pb17:/Volumes/Repository/employee_list discus$ ruby script/generate scaffold Emp
      exists  app/models/
      exists  app/controllers/
      exists  app/helpers/

・・・・中略・・・・

      create  app/controllers/emps_controller.rb
      create  test/functional/emps_controller_test.rb
      create  app/helpers/emps_helper.rb
       route  map.resources :emps
pb17:/Volumes/Repository/employee_list discus$
pb17:/Volumes/Repository/employee_list discus$

ではテスト用サーバを起動して確認！

pb17:/Volumes/Repository/employee_list discus$
pb17:/Volumes/Repository/employee_list discus$ ruby script/server
=> Booting WEBrick...
=> Rails application started on http://0.0.0.0:3000
=> Ctrl-C to shutdown server; call with --help for options
[2008-02-24 16:10:11] INFO  WEBrick 1.3.1
[2008-02-24 16:10:11] INFO  ruby 1.8.6 (2007-09-23) [powerpc-darwin8.11.0]
[2008-02-24 16:10:11] INFO  WEBrick::HTTPServer#start: pid=683 port=3000
127.0.0.1 - - [24/Feb/2008:16:10:31 JST] "GET / HTTP/1.1" 200 7557
- -> /
127.0.0.1 - - [24/Feb/2008:16:10:32 JST] "GET /favicon.ico HTTP/1.1" 200 0
http://localhost:3000/ -> /favicon.ico

・・・・中略・・・・

127.0.0.1 - - [24/Feb/2008:16:11:35 JST] "GET /stylesheets/scaffold.css?1203836970 HTTP/1.1" 200 1152
http://localhost:3000/emps -> /stylesheets/scaffold.css?1203836970
^C[2008-02-24 16:12:35] INFO  going to shutdown ...
[2008-02-24 16:12:35] INFO  WEBrick::HTTPServer#start done.

あれ〜〜、表の中身が表示されていない？　なんで〜〜〜〜！

調べてみると、Ruby on Rails 2.xでは、scaffoldの使い方に違いがあるからということが理由とのこと。
ということでrailsのscaffold利用方法をを参照
/opt/local/lib/ruby/gems/1.8/gems/rails-2.0.2/lib/rails_generator/generators/components/scaffold/USAGE

では早速、作り直してみる。

pb17:/Volumes/Repository/employee_list discus$ 
pb17:/Volumes/Repository/employee_list discus$ ruby script/generate scaffold Emp ename:string job:string mgr:integer hiredate:date sal:integer
      exists  app/models/
      exists  app/controllers/

・・・・中略・・・・

      exists  test/functional/
      exists  test/unit/
overwrite app/views/emps/index.html.erb? (enter "h" for help) [Ynaqdh] Y
       force  app/views/emps/index.html.erb
overwrite app/views/emps/show.html.erb? (enter "h" for help) [Ynaqdh] Y
       force  app/views/emps/show.html.erb
overwrite app/views/emps/new.html.erb? (enter "h" for help) [Ynaqdh] Y
       force  app/views/emps/new.html.erb
overwrite app/views/emps/edit.html.erb? (enter "h" for help) [Ynaqdh] Y
       force  app/views/emps/edit.html.erb
   identical  app/views/layouts/emps.html.erb

・・・・中略・・・・

        skip    test/fixtures/emps.yml
      exists    db/migrate
Another migration is already named create_emps: db/migrate/001_create_emps.rb
pb17:/Volumes/Repository/employee_list discus$ ruby script/server
=> Booting WEBrick...
=> Rails application started on http://0.0.0.0:3000
=> Ctrl-C to shutdown server; call with --help for options
[2008-02-24 16:15:40] INFO  WEBrick 1.3.1
[2008-02-24 16:15:40] INFO  ruby 1.8.6 (2007-09-23) [powerpc-darwin8.11.0]
[2008-02-24 16:15:40] INFO  WEBrick::HTTPServer#start: pid=696 port=3000
127.0.0.1 - - [24/Feb/2008:16:15:56 JST] "GET /emps HTTP/1.1" 200 12543
- -> /emps
127.0.0.1 - - [24/Feb/2008:16:16:17 JST] "GET /stylesheets/scaffold.css?1203836970 HTTP/1.1" 200 1152
http://localhost:3000/emps -> /stylesheets/scaffold.css?1203836970
127.0.0.1 - - [24/Feb/2008:16:16:17 JST] "GET /favicon.ico HTTP/1.1" 200 0
http://localhost:3000/emps -> /favicon.ico
^C[2008-02-24 16:17:22] INFO  going to shutdown ...
[2008-02-24 16:17:22] INFO  WEBrick::HTTPServer#start done.
pb17:/Volumes/Repository/employee_list discus$
pb17:/Volumes/Repository/employee_list discus$

お〜〜〜〜、できた〜！　

次回いよいよ、Ruby on RailsとOracleでそこそこ遊べる環境作りの最終回。日付の表示が気に入らないので少々コードを変更してみる。

Mac de Ruby on Rails - #5 - Oracleと遊ぶ #4

まず、前回の復習。
前回は、rubyからruby-oci8さらにOracle Instant Client 10gを介してOracle11g R1 EE 11.1.0.6.0のデータベースへアクセスできることを確認した。

今回は、rubyからActiveRecordを利用してOracle11g R1のデータベースへアクセスできるか確認する。

---

バックナンバー:
Mac de Ruby on Rails - #1
Mac de Ruby on Rails - #2 - Oracleと遊ぶ #1
Mac de Ruby on Rails - #3 - Oracleと遊ぶ #2
Mac de Ruby on Rails - #4 - Oracleと遊ぶ #3

---

コードは以下の通り。

pb17:˜ discus$
pb17:˜ discus$ cat test.rb
require 'rubygems'
require 'active_record'

class Emp < ActiveRecord::Base
  set_table_name "EMP"
end

ActiveRecord::Base.establish_connection(
  :adapter  => "oracle",
  :database => "lampeye",
  :username => "scott",
  :password => "tiger"
)

emp = Emp.find(:first,:conditions =>["ENAME = ?", "ほげ"])
puts "#{ emp.empno}, #{ emp.ename}, #{emp.job}, #{emp.hiredate}"

実行してみる！

pb17:˜ discus$
pb17:˜ discus$
pb17:˜ discus$ ruby test.rb
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.2/lib/active_record/connection_adapters/abstract/connection_specification.rb:231
:in `establish_connection': Please install the oracle adapter: `gem install activerecord-oracle-adapter` 
(no such file to load -- active_record/connection_adapters/oracle_adapter) (RuntimeError) from test.rb:8

あ〜〜なるほど、ActiveRecordからruby-oci8を利用するためには、oracle_adapter.rbが必要なんですね！　
ということでoracle_adapter.rbをダウンロードし、/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.2/lib/active_record/connection_adapters以下にコピーする。

pb17:˜ discus$
pb17:˜ discus$
pb17:˜ discus$ cd :/Volumes/Repository/temp
pb17:/Volumes/Repository/temp discus$ curl -O http://svn.rubyonrails.org/rails/adapters/oracle/lib/active_record/connection_adapters/oracle_adapter.rb
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 27596  100 27596    0     0  25998      0  0:00:01  0:00:01 --:--:-- 43123
pb17:/Volumes/Repository/temp discus$ 
pb17:/Volumes/Repository/temp discus$ 
pb17:/Volumes/Repository/temp discus$ sudo cp oracle_adapter.rb /opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.2/lib/active_record/connection_adapters
Password:
pb17:/Volumes/Repository/temp discus$

再度実行してみる！

pb17:/Volumes/Repository/temp discus$ cd
pb17:˜ discus$
pb17:˜ discus$
pb17:˜ discus$ ruby test.rb
9999, ほげ, ENGINEER, Tue Jan 01 00:00:00 +0900 2008
pb17:˜ discus$ 

お〜〜〜、上手くいった！〜〜。

今日はここまで、次回へつづく。

Mac de Ruby on Rails - #4 - Oracleと遊ぶ #3

Mac de Ruby on Rails、オラクルと遊ぶ　その３回目は、ruby-oci8の動作確認の意味も含め、rubyからociを使ってOracle11g R1のscott.emp表をアクセスしてみる。

---

バックナンバー:
Mac de Ruby on Rails - #1
Mac de Ruby on Rails - #2 - Oracleと遊ぶ #1
Mac de Ruby on Rails - #3 - Oracleと遊ぶ #2

---

以下の操作は全て、Oracle Instant Client 10g R1 10.1.0.3.0 for MacOSX(PPC)をインストールしたPowerBook G4から行っている。

SQL*Plusを利用してSCOTTユーザのemp表の内容を確認しておく。

pb17:˜ discus$ sqlplus /nolog

SQL*Plus: Release 10.1.0.3.0 - Production on 日 2月 24 15:47:19 2008

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

> conn scott/tiger@lampeye
接続されました。
SCOTT> 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 Linux: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production

SCOTT> set linesize 132
SCOTT> set pagesize 1000
SCOTT> select * from emp order by empno;

     EMPNO ENAME      JOB              MGR HIREDATE        SAL       COMM     DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
      7369 SMITH      CLERK           7902 80-12-17        800                    20
      7499 ALLEN      SALESMAN        7698 81-02-20       1600        300         30
      7521 WARD       SALESMAN        7698 81-02-22       1250        500         30
      7566 JONES      MANAGER         7839 81-04-02       2975                    20
      7654 MARTIN     SALESMAN        7698 81-09-28       1250       1400         30
      7698 BLAKE      MANAGER         7839 81-05-01       2850                    30
      7782 CLARK      MANAGER         7839 81-06-09       2450                    10
      7839 KING       PRESIDENT            81-11-17       5000                    10
      7844 TURNER     SALESMAN        7698 81-09-08       1500          0         30
      7900 JAMES      CLERK           7698 81-12-03        950                    30
      7902 FORD       ANALYST         7566 81-12-03       3000                    20
      7934 MILLER     CLERK           7782 82-01-23       1300                    10
      9999 ほげ       ENGINEER        7566 08-01-01       2500                    20

13行が選択されました。

SCOTT> exit
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production

pb17:˜ discus$

rubyからruby-oci8、さらにOracle Clientを介して、Oracle11g R1のscott.emp表をempno順に問い合わせて動作確認した結果。

pb17:˜ discus$
pb17:˜ discus$ ruby -r oci8 -e "OCI8.new('scott','tiger','lampeye').exec('select * from emp order by empno') do |r| puts r.join(','); end"
7369,SMITH,CLERK,7902,1980/12/17 00:00:00,800.0,,20
7499,ALLEN,SALESMAN,7698,1981/02/20 00:00:00,1600.0,300.0,30
7521,WARD,SALESMAN,7698,1981/02/22 00:00:00,1250.0,500.0,30
7566,JONES,MANAGER,7839,1981/04/02 00:00:00,2975.0,,20
7654,MARTIN,SALESMAN,7698,1981/09/28 00:00:00,1250.0,1400.0,30
7698,BLAKE,MANAGER,7839,1981/05/01 00:00:00,2850.0,,30
7782,CLARK,MANAGER,7839,1981/06/09 00:00:00,2450.0,,10
7839,KING,PRESIDENT,,1981/11/17 00:00:00,5000.0,,10
7844,TURNER,SALESMAN,7698,1981/09/08 00:00:00,1500.0,0.0,30
7900,JAMES,CLERK,7698,1981/12/03 00:00:00,950.0,,30
7902,FORD,ANALYST,7566,1981/12/03 00:00:00,3000.0,,20
7934,MILLER,CLERK,7782,1982/01/23 00:00:00,1300.0,,10
9999,ほげ,ENGINEER,7566,2008/01/01 00:00:00,2500.0,,20
pb17:˜ discus$
pb17:˜ discus$

順調、順調！　

次回へつづく。

Mac de Ruby on Rails - #3 - Oracleと遊ぶ #2

さて、前回予告した通り、MacOSXのRuby on Rails 2.0.2からOracle11g R1 EE 11.1.0.6.0 for Linux x86へOracle Instant Client 10g R1 for MacOSX(PPC)を利用し、そこそこ遊べる環境を作ってみる。

---

バックナンバー:
Mac de Ruby on Rails - #1
Mac de Ruby on Rails - #2 - Oracleと遊ぶ #1

---

2008/2/26追記-文字エンコーディングに関する情報を書き忘れていたので追記
Oracle DB character set : Japanese_Japan.AL32UTF8
Oracle Client NLS_LANG : Japanese_Japan.AL32UTF8
ということで全てUTF-8で統一してあります。

まずは、Ruby on Railsの開発環境にするPowerBook G4の情報から

H/W: Apple PowerBook G4 1Ghz / RAM:1GB
OS : MacOSX 10.4.11 Tiger (XCode 2.4.1インストール済み）
Oracle Instant Client : Oracle Instant Client 10g R1 for MacOSX(PPC)
Ruby : 1.8.6 (2007-09-23 patchlevel 110) [powerpc-darwin8.11.0]
RubyGems : 1.0.1
Ruby on Rails : 2.0.2
ruby-oci8 : 1.0.0

MacOSX 10.4.11 TigerへのRuby on Rails 2.0.2のインストールはこちら。

そして、Ruby on Railsから接続するOracleデータベースサーバは（サーバっていうと大げさ過ぎるノートPCですが・・・・）

H/W: Dynabook SS SX/210LNLW (RAM:768MB)
OS : CentOS 5
DB : Oracle11g R1 EE 11.1.0.6.0 for Linux x86

という構成です。配置はこんな感じ

Ruby on Rails 2.0.2からOracle11g R1 EE 11.1.0.6.0 for Linux x86へ接続するためのOracle Instant Client 10g R1 for MacOSX(PPC)関連の環境変数の設定は以下のようになっている。
（MySQLやGlassFish関連の環境変数も見えるが今回の内容には一切関係ないので気にしないでくださいませ。）

尚、Oracle Instant Client 10g R1 for MacOSX(PPC)をMacOSX 10.4.11 Tigerへインストールする例は以前の記事を参考にしてみてください。

pb17:˜ discus$ cat .bash_profile
export PATH=/usr/local/mysql/bin:$PATH

alias mysql='mysql --set autocommit=0'

# for GlassFish
export GLASSFISH_HOME=˜/glassfish/glassfish
export PATH=/opt/local/bin:$PATH:$GLASSFISH_HOME/bin

. .bashrc
pb17:˜ discus$ cat .bashrc
alias ll='ls -lv'

ORACLE_INSTANT_CLIENT_HOME=/Users/Shared/instantclient10_1
export ORACLE_HOME=$ORACLE_INSTANT_CLIENT_HOME
export NLS_LANG=Japanese_Japan.AL32UTF8
export DYLD_LIBRARY_PATH=$ORACLE_HOME
export PATH=$ORACLE_HOME:$PATH
export TNS_ADMIN=$ORACLE_HOME


pb17:˜ discus$ 
pb17:˜ discus$ ls -l $ORACLE_HOME 
total 182200
-r--r--r--   1 discus  orauser     21299 Apr 29  2004 README_IC.htm
-r--r--r--   1 discus  orauser   1461081 Jul  5  2004 classes12.jar
-r--r--r--   1 discus  orauser      1353 Oct  9  2003 glogin.sql
lrwxr-xr-x   1 discus  orauser        20 Feb 16 12:43 libclntsh.dylib -> libclntsh.dylib.10.1
-rwxr-xr-x   1 discus  orauser  14891264 Dec 13  2004 libclntsh.dylib.10.1
-rwxr-xr-x   1 discus  orauser     27432 Oct 24  2004 libheteroxa10.dylib
-rw-r--r--   1 discus  orauser   1516340 Nov 16  2004 libnnz10.dylib
lrwxr-xr-x   1 discus  orauser        18 Feb 16 12:44 libocci.dylib -> libocci.dylib.10.1
-rw-r--r--   1 discus  orauser   1841448 Oct 24  2004 libocci.dylib.10.1
-rwxr-xr-x   1 discus  orauser  66160096 Dec 14  2004 libociei.dylib
-rwxr-xr-x   1 discus  orauser     93028 Nov  9  2004 libocijdbc10.dylib
-rwxr-xr-x   1 discus  orauser    744612 Oct 24  2004 libsqlplus.dylib
-r--r--r--   1 discus  orauser     54032 Jul  5  2004 ocrs12.jar
-r--r--r--   1 discus  orauser   1397543 Jul  5  2004 ojdbc14.jar
-r--r--r--   1 discus  orauser   5018319 Jul  7  2004 orai18n.jar
drwxr-xr-x   4 discus  orauser       136 Dec 14  2004 sdk
-rwxr-xr-x   1 discus  orauser     15660 Dec 13  2004 sqlplus
-rw-r--r--   1 discus  orauser      2072 Feb 16 13:19 tnsnames.ora
pb17:˜ discus$ 

注）
赤太字で示したシンボリックリンクは今回事前に作成したもので、それらのシンボリックリンクは作成しなくても通常利用には問題ない。以前の記事参照のこと。
尚、今回は事前に参照していた資料にシンボリックリンクの作成に関する記述があったため前述のシンボリックリンクを作成した。
（ほんとうに必要なのか？　という点については未検証であることを書き加えておく。余計なものだとしても悪さはしないでしょう。きっと。）

では、早速、Ruby on Rails 2.0.2からOracleへアクセスするための準備作業に取りかかることにする。
まず、RubyForgeからruby-oci8-1.0.0.tar.gzをダウンロード、解凍する。

pb17:/Volumes/Repository/temp discus$ curl -L -O http://rubyforge.org/frs/download.php/28396/ruby-oci8-1.0.0.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  104k  100  104k    0     0  41090      0  0:00:02  0:00:02 --:--:-- 77167
pb17:/Volumes/Repository/temp discus$ ll
-rw-r--r--    1 discus  admin     593589 Dec 17 14:57 MacPorts-1.6.0-10.4-Tiger.dmg
-rw-r--r--    1 discus  admin  239926399 Aug 14  2007 aug07_adc_refib_update.dmg
-rw-r--r--    1 discus  admin        326 Apr 28  2006 comics.sql
-rw-r--r--    1 discus  admin     107494 Nov 25 20:31 ruby-oci8-1.0.0.tar.gz
-rw-r--r--    1 discus  admin     204841 May 24  2007 rubygems-0.9.4.tgz
pb17:/Volumes/Repository/temp discus$ gzip -dc ruby-oci8-1.0.0.tar.gz | tar xvf -
ruby-oci8-1.0.0/
ruby-oci8-1.0.0/NEWS
ruby-oci8-1.0.0/ChangeLog
ruby-oci8-1.0.0/Makefile

・・・中略・・・

ruby-oci8-1.0.0/test/test_oci8.rb
ruby-oci8-1.0.0/test/test_oradate.rb
ruby-oci8-1.0.0/test/test_oranumber.rb
ruby-oci8-1.0.0/test/test_metadata.rb

解凍したらmakeする。Oracle Instant Clientをちゃんと認識しているのがわかる。

pb17:/Volumes/Repository/temp discus$ cd ruby-oci8-1.0.0
pb17:/Volumes/Repository/temp/ruby-oci8-1.0.0 discus$ make
ruby setup.rb config 
---> lib
---> lib/DBD
---> lib/DBD/OCI8
<--- lib/DBD/OCI8
<--- lib/DBD
<--- lib
---> ext
---> ext/oci8
/opt/local/bin/ruby /Volumes/Repository/temp/ruby-oci8-1.0.0/ext/oci8/extconf.rb 
checking for load library path... (DYLD_LIBRARY_PATH)... 
  found: /Users/Shared/instantclient10_1/libclntsh.dylib.10.1 looks like an instant client.
checking for cc... ok
checking for gcc... yes
checking for LP64... no
checking for ruby header... ok
checking for OCIInitialize() in oci.h... yes
checking for OCIEnvCreate()... yes
checking for OCITerminate()... yes
checking for OCILobOpen()... yes
checking for OCILobClose()... yes
checking for OCILobCreateTemporary()... yes
checking for OCILobGetChunkSize()... yes
checking for OCILobLocatorAssign()... yes
creating ../../lib/oci8.rb from /Volumes/Repository/temp/ruby-oci8-1.0.0/ext/oci8/../../lib/oci8.rb.in
creating extconf.h
creating Makefile
<--- ext/oci8

・・・中略・・・

/usr/bin/gcc-4.0 -I. -I. -I/opt/local/lib/ruby/1.8/powerpc-darwin8.11.0 -I/Volumes/Repository/temp/ruby-oci8-1.0.0/ext/oci8 -DRUBY_EXTCONF_H=\"extconf.h\" -I/opt/local/include -fno-common -O2 
-fno-common -pipe -fno-common -I/Users/Shared/instantclient10_1/sdk/include -Wall  -c attr.c
cc -dynamic -bundle -undefined suppress -flat_namespace -o oci8lib.bundle oci8.o handle.o const.o env.o error.o svcctx.o server.o session.o stmt.o define.o bind.o describe.o descriptor.o
param.o lob.o oradate.o oranumber.o ocinumber.o attr.o -L"." -L"/opt/local/lib" -L. -L/opt/local/lib    -lruby  -L/Users/Shared/instantclient10_1 -lclntsh  -lpthread -ldl -lobjc  
<--- ext/oci8
<--- ext
pb17:/Volumes/Repository/temp/ruby-oci8-1.0.0 discus$ 

makeが無事終了したらinstallする。(sudoで！）

pb17:/Volumes/Repository/temp/ruby-oci8-1.0.0 discus$ sudo make install
Password:
ruby setup.rb install
---> lib
mkdir -p /opt/local/lib/ruby/site_ruby/1.8/
install oci8.rb /opt/local/lib/ruby/site_ruby/1.8/
---> lib/DBD
mkdir -p /opt/local/lib/ruby/site_ruby/1.8/DBD
---> lib/DBD/OCI8
mkdir -p /opt/local/lib/ruby/site_ruby/1.8/DBD/OCI8
install OCI8.rb /opt/local/lib/ruby/site_ruby/1.8/DBD/OCI8
<--- lib/DBD/OCI8
<--- lib/DBD
<--- lib
---> ext
---> ext/oci8
mkdir -p /opt/local/lib/ruby/site_ruby/1.8/powerpc-darwin8.11.0/.
install oci8lib.bundle /opt/local/lib/ruby/site_ruby/1.8/powerpc-darwin8.11.0/.
<--- ext/oci8
<--- ext
pb17:/Volumes/Repository/temp/ruby-oci8-1.0.0 discus$ 

ということでruby-oci8のインストールまで無事に終了した。（Ruby初心者の私でもなんとかできました。。。。 :)

つづく・・・・

---

参考にしたサイトを以下に載せておきます。
OTN:Ruby on Rails on Oracle: A Simple Tutorial
OTN:Ruby on Rails with Oracle FAQ
(但し、RoRもruby-oci8関連の設定方法も参考にはなりますが古いバージョンを利用した解説なので注意が必要ですね。）

Connecting Ruby on Rails to Oracle on an Intel Mac in Leopard (Mac OSX 10.5)
上記サイトの情報は(2008/2/24時点では比較的あたらしい、しかもIntel Macのネタですね。。

ruby-oci8 - Oracle Instant Client
ruby-oci8インストール手順

Rails supports Oracle 8i, 9i, and 10g.
How to Connect To Oracle
ruby 2.xでoracleを利用する設定関連など

以下、Rails 2 と Oracleを接続するためのdatabase.ymlの設定例の引用

oracle_adapter.rb
oracle_adapter.rbのダウンロード先

Mac de Ruby on Rails - #2 - Oracleと遊ぶ #1

Mac de Ruby on Rails - #1でも書いたように、Mac で Oracle と Ruby on Rails で戯れることにした。

Oracle Instant Clientネタを幾つか書いたのだが、それらはMac で Oracle と Ruby on Rails で戯れるための準備だったのですよ。（いろいろ検索しても、MacOSXでOracleを使ったRoRのネタがあまり見つからなかったこともあり、そうなれば自分でやるのが一番というわけ）

2008/2/24追記
配置はこんな感じ。(Visual Paradigm for UML community Editonを利用)

ということで、ただ今準備中！　次回へつづく。

---

バックナンバー:
Mac de Ruby on Rails - #1

---

Oracle de XMLDB #25 - Relational dataをXMLへ #7のおまけ

１つ忘れていました。

何故、「Relational dataをXMLへ」というネタを取り上げようと思ったのか？

それはOTN-Jのこのスレに回答したことがきっかけだった。OTN-JのスレのネタはMacOSX環境下ではないのだけれど、Oracle XML DBを調べていたこともあり、その次いでに Eclipse for MacOSXではどうなるのか単純に知りたかっただけだった。そしてその準備段階のネタがMacOSXのEclipseを日本語化という記事だった。

ということで、前回はJDeveloperを使って試したことを書いた。今回はおまけとして、

Eclipse 3.3.1.1 for MacOSX（日本語化済み）
と
NetBeans IDE 6.0.1 for MacOSX

でやってみた。。（ただそれだけなんですけど・・・・）

利用したOracle JDBCドライバなどは前々回の記事を参照してください。

どれを使っても同じ結果にはなるのですが・・・・NetBeans6.0.1は随分といい感じに仕上がっているように感じた。(^^

Oracle de XMLDB #25 - Relational dataをXMLへ #7のおまけ

１つ忘れていました。

何故、「Relational dataをXMLへ」というネタを取り上げようと思ったのか？

それはOTN-Jのこのスレに回答したことがきっかけだった。OTN-JのスレのネタはMacOSX環境下ではないのだけれど、Oracle XML DBを調べていたこともあり、その次いでに Eclipse for MacOSXではどうなるのか単純に知りたかっただけだった。そしてその準備段階のネタがMacOSXのEclipseを日本語化という記事だった。

ということで、前回はJDeveloperを使って試したことを書いた。今回はおまけとして、

Eclipse 3.3.1.1 for MacOSX（日本語化済み）
と
NetBeans IDE 6.0.1 for MacOSX

でやってみた。。（ただそれだけなんですけど・・・・）

利用したOracle JDBCドライバなどは前々回の記事を参照してください。

どれを使っても同じ結果にはなるのですが・・・・NetBeans6.0.1は随分といい感じに仕上がっているように感じた。(^^

Oracle de XMLDB #24 - Relational dataをXMLへ #7

リレーショナルデータをXMLへ変換するシリーズもひとまず最終回ということで、最後は、Oracleデータベース側でXMLTypeインスタンスへ変換して、クライアントではXMLTypeインスタンスを受け取るだけの例を一つ。
環境は前回の記事を見てもらうとして早速試してみる。

---

バックナンバー：
Oracle de XMLDB #18 - Relational dataをXMLへ #1

Oracle de XMLDB #19 - Relational dataをXMLへ #2
Oracle de XMLDB #20 - Relational dataをXMLへ #3
Oracle de XMLDB #21 - Relational dataをXMLへ #4
Oracle de XMLDB #22 - Relational dataをXMLへ #5
Oracle de XMLDB #23 - Relational dataをXMLへ #6

---

以下の例は、SQL/XMLとOracleが提供しているXQuery関数 ora:view()を利用し、リレーショナルデータからXMLTypeインスタンスを作るまでをOracleデータベース側で行い、クライアントではXMLTypeインスタンスを受け取るだけというもの。

package jp.macdeoracle.sample;

import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.SQLException;
import java.sql.Statement;

import oracle.jdbc.OracleResultSet;
import oracle.jdbc.pool.OracleDataSource;

import oracle.xdb.XMLType;


public class Table2Xml2
{
  public Table2Xml2() 
  throws SQLException
  {
    OracleDataSource ods;
    ods = new OracleDataSource();
    ods.setURL(
     "jdbc:oracle:thin:scott/tiger@192.168.1.20:1521:lampeye"
    );
 
    Connection conn = ods.getConnection();    
    Statement stmt = conn.createStatement();
    OracleResultSet rs = (OracleResultSet)stmt.executeQuery(
        "SELECT "
        + "XMLROOT("
        + "XMLQuery("
        + "'<ROWSET> {"
        + "  for $d in ora:view(\"EMP\") "
        + "  order by $d"
        + "  return $d"
        + "} </ROWSET>'"
        + "RETURNING CONTENT), VERSION '1.0') "
        + "FROM dual"
    );
    DatabaseMetaData meta = conn.getMetaData();
    System.out.println(meta.getDatabaseProductVersion());
    System.out.println(meta.getDriverName()+":"+meta.getDriverVersion());
     while(rs.next()) {
        System.out.println(
          "=======================\n"
          +((XMLType)rs.getObject(1)).getStringVal()
        );
    }
    rs.close();
    stmt.close();
    conn.close();
  }

  public static void main(String[] args) throws SQLException
  {
    Table2Xml2 dbXml = new Table2Xml2();
  }
}

実行結果は以下の通り。

Oracle Database 11g Release 11.1.0.0.0 - Production
Oracle JDBC driver:10.1.0.3.0
=======================
<?xml version="1.0"?>
<ROWSET>
  <ROW>
    <EMPNO>7369</EMPNO>
    <ENAME>SMITH</ENAME>
    <JOB>CLERK</JOB>
    <MGR>7902</MGR>
    <HIREDATE>1980-12-17</HIREDATE>
    <SAL>800</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7499</EMPNO>
    <ENAME>ALLEN</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-02-20</HIREDATE>
    <SAL>1600</SAL>
    <COMM>300</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7521</EMPNO>
    <ENAME>WARD</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-02-22</HIREDATE>
    <SAL>1250</SAL>
    <COMM>500</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7566</EMPNO>
    <ENAME>JONES</ENAME>
    <JOB>MANAGER</JOB>
    <MGR>7839</MGR>
    <HIREDATE>1981-04-02</HIREDATE>
    <SAL>2975</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7654</EMPNO>
    <ENAME>MARTIN</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-09-28</HIREDATE>
    <SAL>1250</SAL>
    <COMM>1400</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7698</EMPNO>
    <ENAME>BLAKE</ENAME>
    <JOB>MANAGER</JOB>
    <MGR>7839</MGR>
    <HIREDATE>1981-05-01</HIREDATE>
    <SAL>2850</SAL>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7782</EMPNO>
    <ENAME>CLARK</ENAME>
    <JOB>MANAGER</JOB>
    <MGR>7839</MGR>
    <HIREDATE>1981-06-09</HIREDATE>
    <SAL>2450</SAL>
    <DEPTNO>10</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7839</EMPNO>
    <ENAME>KING</ENAME>
    <JOB>PRESIDENT</JOB>
    <HIREDATE>1981-11-17</HIREDATE>
    <SAL>5000</SAL>
    <DEPTNO>10</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7844</EMPNO>
    <ENAME>TURNER</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-09-08</HIREDATE>
    <SAL>1500</SAL>
    <COMM>0</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7900</EMPNO>
    <ENAME>JAMES</ENAME>
    <JOB>CLERK</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-12-03</HIREDATE>
    <SAL>950</SAL>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7902</EMPNO>
    <ENAME>FORD</ENAME>
    <JOB>ANALYST</JOB>
    <MGR>7566</MGR>
    <HIREDATE>1981-12-03</HIREDATE>
    <SAL>3000</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7934</EMPNO>
    <ENAME>MILLER</ENAME>
    <JOB>CLERK</JOB>
    <MGR>7782</MGR>
    <HIREDATE>1982-01-23</HIREDATE>
    <SAL>1300</SAL>
    <DEPTNO>10</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>9999</EMPNO>
    <ENAME>ほげ</ENAME>
    <JOB>ENGINEER</JOB>
    <MGR>7566</MGR>
    <HIREDATE>2008-01-01</HIREDATE>
    <SAL>2500</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
</ROWSET>

プロセスが終了コード0で終了しました。

いろいろな方法があるので悩みそうな気もするなぁ。。。。やっぱり。。。

Oracle de XMLDB #23 - Relational dataをXMLへ #6

さて、Oracleデータベース側だけでリレーショナルデータをXMLTypeインスタンスへ変換する方法は一通り試したので、今度はリレーショナルデータを取り出しクライアント側でXMLへ変換してみた。
接続するOracleデータベースはいままで通り、Oracle11g R1 EE 11.1.0.6.0 for Linux(x86)なのだが、クライアントとして利用するMacOSX 10.4.11の構成は多少異なるので以下に示しておく。

IDE : Oracle JDeveloper10g Studio Edition 10.1.3.0.4 for MacOSX
Oracle XML Developer's Kit(XDK) for Java - 10.2.0.2.0 Linux Production
JDBCドライバ : Oracle Instant Client for MacOSX(PPC) 10.1.0.3.0付属の ojdbc14.jar
Oracle XML Parser : JDeveloper 10g Studio Edition for MacOSX version 10.1.3.0.4に付属するOracle XML Parser v2 (xmlparserv2.jar)
Oracle XML SQL Utility : JDeveloper 10g Studio Edition for MacOSX version 10.1.3.0.4に付属するOracle XML SQL Utiliry (xsu12.jar)

---

バックナンバー：
Oracle de XMLDB #18 - Relational dataをXMLへ #1

Oracle de XMLDB #19 - Relational dataをXMLへ #2
Oracle de XMLDB #20 - Relational dataをXMLへ #3
Oracle de XMLDB #21 - Relational dataをXMLへ #4
Oracle de XMLDB #22 - Relational dataをXMLへ #5

---

以下の例では、emp表をempno順にソートして読み込み、Oracle XML SQL Utilityを利用して読み込んだResultsetからXMLへ変換。

package jp.macdeoracle.sample;

import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;

import oracle.jdbc.pool.OracleDataSource;

import oracle.xml.sql.query.OracleXMLQuery;

public class Table2Xml1
{
  public Table2Xml1() 
  throws SQLException
  {
    OracleDataSource ods;
    ods = new OracleDataSource();
    ods.setURL(
     "jdbc:oracle:thin:scott/tiger@192.168.1.20:1521:lampeye"
    );
 
    Connection conn = ods.getConnection();    
    Statement stmt = conn.createStatement();
    ResultSet rs = stmt.executeQuery("select * from emp order by empno");
    OracleXMLQuery xmlqry = new OracleXMLQuery(conn, rs);
    
    String xmlString = xmlqry.getXMLString();
    DatabaseMetaData meta = conn.getMetaData();
    System.out.println(meta.getDatabaseProductVersion());
    System.out.println(meta.getDriverName()+":"+meta.getDriverVersion());
    System.out.println("=====================\n"+xmlString);
    rs.close();
    stmt.close();
    conn.close();
  }

  public static void main(String[] args) throws SQLException
  {
    Table2Xml1 Table2Xml1 = new Table2Xml1();
  }
}

出力結果は以下の通り。ROW要素にnum属性がある以外、データベース側だけで変換した場合と内容的には変らない。
データベースサーバ側で変換まで行うか、クライアント側で変換するか、どちらが良いかといういうより、どのように負荷分散するかという戦略に合わせて考えればいいんじゃないかと思う。

Oracle Database 11g Release 11.1.0.0.0 - Production
Oracle JDBC driver:10.1.0.3.0
=====================
<?xml version = '1.0'?>
<ROWSET>
   <ROW num="1">
      <EMPNO>7369</EMPNO>
      <ENAME>SMITH</ENAME>
      <JOB>CLERK</JOB>
      <MGR>7902</MGR>
      <HIREDATE>12/17/1980 0:0:0</HIREDATE>
      <SAL>800</SAL>
      <DEPTNO>20</DEPTNO>
   </ROW>
   <ROW num="2">
      <EMPNO>7499</EMPNO>
      <ENAME>ALLEN</ENAME>
      <JOB>SALESMAN</JOB>
      <MGR>7698</MGR>
      <HIREDATE>2/20/1981 0:0:0</HIREDATE>
      <SAL>1600</SAL>
      <COMM>300</COMM>
      <DEPTNO>30</DEPTNO>
   </ROW>
   <ROW num="3">
      <EMPNO>7521</EMPNO>
      <ENAME>WARD</ENAME>
      <JOB>SALESMAN</JOB>
      <MGR>7698</MGR>
      <HIREDATE>2/22/1981 0:0:0</HIREDATE>
      <SAL>1250</SAL>
      <COMM>500</COMM>
      <DEPTNO>30</DEPTNO>
   </ROW>
   <ROW num="4">
      <EMPNO>7566</EMPNO>
      <ENAME>JONES</ENAME>
      <JOB>MANAGER</JOB>
      <MGR>7839</MGR>
      <HIREDATE>4/2/1981 0:0:0</HIREDATE>
      <SAL>2975</SAL>
      <DEPTNO>20</DEPTNO>
   </ROW>
   <ROW num="5">
      <EMPNO>7654</EMPNO>
      <ENAME>MARTIN</ENAME>
      <JOB>SALESMAN</JOB>
      <MGR>7698</MGR>
      <HIREDATE>9/28/1981 0:0:0</HIREDATE>
      <SAL>1250</SAL>
      <COMM>1400</COMM>
      <DEPTNO>30</DEPTNO>
   </ROW>
   <ROW num="6">
      <EMPNO>7698</EMPNO>
      <ENAME>BLAKE</ENAME>
      <JOB>MANAGER</JOB>
      <MGR>7839</MGR>
      <HIREDATE>5/1/1981 0:0:0</HIREDATE>
      <SAL>2850</SAL>
      <DEPTNO>30</DEPTNO>
   </ROW>
   <ROW num="7">
      <EMPNO>7782</EMPNO>
      <ENAME>CLARK</ENAME>
      <JOB>MANAGER</JOB>
      <MGR>7839</MGR>
      <HIREDATE>6/9/1981 0:0:0</HIREDATE>
      <SAL>2450</SAL>
      <DEPTNO>10</DEPTNO>
   </ROW>
   <ROW num="8">
      <EMPNO>7839</EMPNO>
      <ENAME>KING</ENAME>
      <JOB>PRESIDENT</JOB>
      <HIREDATE>11/17/1981 0:0:0</HIREDATE>
      <SAL>5000</SAL>
      <DEPTNO>10</DEPTNO>
   </ROW>
   <ROW num="9">
      <EMPNO>7844</EMPNO>
      <ENAME>TURNER</ENAME>
      <JOB>SALESMAN</JOB>
      <MGR>7698</MGR>
      <HIREDATE>9/8/1981 0:0:0</HIREDATE>
      <SAL>1500</SAL>
      <COMM>0</COMM>
      <DEPTNO>30</DEPTNO>
   </ROW>
   <ROW num="10">
      <EMPNO>7900</EMPNO>
      <ENAME>JAMES</ENAME>
      <JOB>CLERK</JOB>
      <MGR>7698</MGR>
      <HIREDATE>12/3/1981 0:0:0</HIREDATE>
      <SAL>950</SAL>
      <DEPTNO>30</DEPTNO>
   </ROW>
   <ROW num="11">
      <EMPNO>7902</EMPNO>
      <ENAME>FORD</ENAME>
      <JOB>ANALYST</JOB>
      <MGR>7566</MGR>
      <HIREDATE>12/3/1981 0:0:0</HIREDATE>
      <SAL>3000</SAL>
      <DEPTNO>20</DEPTNO>
   </ROW>
   <ROW num="12">
      <EMPNO>7934</EMPNO>
      <ENAME>MILLER</ENAME>
      <JOB>CLERK</JOB>
      <MGR>7782</MGR>
      <HIREDATE>1/23/1982 0:0:0</HIREDATE>
      <SAL>1300</SAL>
      <DEPTNO>10</DEPTNO>
   </ROW>
   <ROW num="13">
      <EMPNO>9999</EMPNO>
      <ENAME>ほげ</ENAME>
      <JOB>ENGINEER</JOB>
      <MGR>7566</MGR>
      <HIREDATE>1/1/2008 0:0:0</HIREDATE>
      <SAL>2500</SAL>
      <DEPTNO>20</DEPTNO>
   </ROW>
</ROWSET>

プロセスが終了コード0で終了しました。

次回は、データベース側でXMLへの変換まで行いクライアント側ではその結果を受け取るだけの例を一つ。

Oracle de XMLDB #22 - Relational dataをXMLへ #5

リレーショナルデータを取り出してからXMLへ変換する方法へ行く前にもう一つあるのを忘れてました。
SYS_XMLAGG()とXMLELEMENT()とXMLFOREST()関数を利用する方法。
Oracle9i R1から提供されていた関数だったが、古くから提供されていたので完璧に忘れてました。m(_ _)m
（マニュアルを調べた上でOracle9i R1から提供されていた関数と書いたが・・・もし、Oracle8i 8.1.7あたりからあったよ！というツッコミがあればご遠慮なく。）

---

バックナンバー：
Oracle de XMLDB #18 - Relational dataをXMLへ #1

Oracle de XMLDB #19 - Relational dataをXMLへ #2
Oracle de XMLDB #20 - Relational dataをXMLへ #3
Oracle de XMLDB #21 - Relational dataをXMLへ #4

---

2008/2/19 9:0:0
文字参照のミスを修正しました。


尚、他のXQueryの結果に関してはいままでもこちらでは制御できない改行が挿入された結果だったり、逆に取り除かれた結果が返されたりしていたが、前述の関数を利用した場合は全体に整形用改行が入るのではなく、SYS_XMLAGG()関数でマージされたXMLELEMENT()の結果からは改行は取り除かれているが、XML宣言やルート要素タグの後には何故か改行が付加される。（要素間の改行やインデントなどは目視する際に見やすくするためなので、あっても無くていいのだが、なんとも気持ちの悪い付け方をしてくれる。。。）

また、いままで実行してきた各SQL文は、それぞれ２回実行してからalter system flush shared_poolを１度実行した後に実行してある。（実行環境は以前と同じ）

SQL*Plus: Release 10.1.0.3.0 - Production on 火 2月 19 00:00:09 2008

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

> conn scott/tiger@lampeye
接続されました。
SCOTT> set long 4000
SCOTT> set pagesize 1000
SCOTT> select
  2    sys_xmlagg(
  3      xmlelement("ROW",
  4        xmlforest( 
  5          empno,
  6          ename,
  7          job,
  8          mgr,
  9          hiredate,
 10          sal,
 11          comm,
 12          deptno
 13    ))) xmldoc
 14  from
 15    emp
 16  order by
 17    empno;

XMLDOC
--------------------------------------------------------------------------------
<?xml version="1.0"?>
<ROWSET>
<ROW><EMPNO>9999</EMPNO><ENAME>ほげ</ENAME><JOB>ENGINEER</JOB><MGR>7566</MGR><HI
REDATE>2008-01-01</HIREDATE><SAL>2500</SAL><DEPTNO>20</DEPTNO></ROW><ROW><EMPNO>
7369</EMPNO><ENAME>SMITH</ENAME><JOB>CLERK</JOB><MGR>7902</MGR><HIREDATE>1980-12
-17</HIREDATE><SAL>800</SAL><DEPTNO>20</DEPTNO></ROW><ROW><EMPNO>7499</EMPNO><EN
AME>ALLEN</ENAME><JOB>SALESMAN</JOB><MGR>7698</MGR><HIREDATE>1981-02-20</HIREDAT
E><SAL>1600</SAL><COMM>300</COMM><DEPTNO>30</DEPTNO></ROW><ROW><EMPNO>7521</EMPN
O><ENAME>WARD</ENAME><JOB>SALESMAN</JOB><MGR>7698</MGR><HIREDATE>1981-02-22</HIR
EDATE><SAL>1250</SAL><COMM>500</COMM><DEPTNO>30</DEPTNO></ROW><ROW><EMPNO>7566</
EMPNO><ENAME>JONES</ENAME><JOB>MANAGER</JOB><MGR>7839</MGR><HIREDATE>1981-04-02<
/HIREDATE><SAL>2975</SAL><DEPTNO>20</DEPTNO></ROW><ROW><EMPNO>7654</EMPNO><ENAME
>MARTIN</ENAME><JOB>SALESMAN</JOB><MGR>7698</MGR><HIREDATE>1981-09-28</HIREDATE>
<SAL>1250</SAL><COMM>1400</COMM><DEPTNO>30</DEPTNO></ROW><ROW><EMPNO>7698</EMPNO
><ENAME>BLAKE</ENAME><JOB>MANAGER</JOB><MGR>7839</MGR><HIREDATE>1981-05-01</HIRE
DATE><SAL>2850</SAL><DEPTNO>30</DEPTNO></ROW><ROW><EMPNO>7782</EMPNO><ENAME>CLAR
K</ENAME><JOB>MANAGER</JOB><MGR>7839</MGR><HIREDATE>1981-06-09</HIREDATE><SAL>24
50</SAL><DEPTNO>10</DEPTNO></ROW><ROW><EMPNO>7839</EMPNO><ENAME>KING</ENAME><JOB
>PRESIDENT</JOB><HIREDATE>1981-11-17</HIREDATE><SAL>5000</SAL><DEPTNO>10</DEPTNO
></ROW><ROW><EMPNO>7844</EMPNO><ENAME>TURNER</ENAME><JOB>SALESMAN</JOB><MGR>7698
</MGR><HIREDATE>1981-09-08</HIREDATE><SAL>1500</SAL><COMM>0</COMM><DEPTNO>30</DE
PTNO></ROW><ROW><EMPNO>7900</EMPNO><ENAME>JAMES</ENAME><JOB>CLERK</JOB><MGR>7698
</MGR><HIREDATE>1981-12-03</HIREDATE><SAL>950</SAL><DEPTNO>30</DEPTNO></ROW><ROW
><EMPNO>7902</EMPNO><ENAME>FORD</ENAME><JOB>ANALYST</JOB><MGR>7566</MGR><HIREDAT
E>1981-12-03</HIREDATE><SAL>3000</SAL><DEPTNO>20</DEPTNO></ROW><ROW><EMPNO>7934<
/EMPNO><ENAME>MILLER</ENAME><JOB>CLERK</JOB><MGR>7782</MGR><HIREDATE>1982-01-23<
/HIREDATE><SAL>1300</SAL><DEPTNO>10</DEPTNO></ROW></ROWSET>


経過: 00:00:00.41
SCOTT> 

ちなみに、もうお気づきだと思うが、上記のようにorder by句を付けたとしてもエラーにはならないが指定した列でソートされることはないのでご注意を！
ソートした結果が欲しい場合には副問い合せを利用するとよいだろう。

SCOTT> select
  2    sys_xmlagg(
  3      xmlelement("ROW",
  4        xmlforest(
  5          empno,
  6          ename,
  7          job,
  8          mgr,
  9          hiredate,
 10          sal,
 11          comm,
 12          deptno
 13    ))) xmldoc
 14  from
 15    (select * from emp order by empno) alias_of_emp
 16  /

XMLDOC
--------------------------------------------------------------------------------
<?xml version="1.0"?>
<ROWSET>
<ROW><EMPNO>7369</EMPNO><ENAME>SMITH</ENAME><JOB>CLERK</JOB><MGR>7902</MGR><HIRE
DATE>1980-12-17</HIREDATE><SAL>800</SAL><DEPTNO>20</DEPTNO></ROW><ROW><EMPNO>749
9</EMPNO><ENAME>ALLEN</ENAME><JOB>SALESMAN</JOB><MGR>7698</MGR><HIREDATE>1981-02
-20</HIREDATE><SAL>1600</SAL><COMM>300</COMM><DEPTNO>30</DEPTNO></ROW><ROW><EMPN
O>7521</EMPNO><ENAME>WARD</ENAME><JOB>SALESMAN</JOB><MGR>7698</MGR><HIREDATE>198
1-02-22</HIREDATE><SAL>1250</SAL><COMM>500</COMM><DEPTNO>30</DEPTNO></ROW><ROW><
EMPNO>7566</EMPNO><ENAME>JONES</ENAME><JOB>MANAGER</JOB><MGR>7839</MGR><HIREDATE
>1981-04-02</HIREDATE><SAL>2975</SAL><DEPTNO>20</DEPTNO></ROW><ROW><EMPNO>7654</
EMPNO><ENAME>MARTIN</ENAME><JOB>SALESMAN</JOB><MGR>7698</MGR><HIREDATE>1981-09-2
8</HIREDATE><SAL>1250</SAL><COMM>1400</COMM><DEPTNO>30</DEPTNO></ROW><ROW><EMPNO
>7698</EMPNO><ENAME>BLAKE</ENAME><JOB>MANAGER</JOB><MGR>7839</MGR><HIREDATE>1981
-05-01</HIREDATE><SAL>2850</SAL><DEPTNO>30</DEPTNO></ROW><ROW><EMPNO>7782</EMPNO
><ENAME>CLARK</ENAME><JOB>MANAGER</JOB><MGR>7839</MGR><HIREDATE>1981-06-09</HIRE
DATE><SAL>2450</SAL><DEPTNO>10</DEPTNO></ROW><ROW><EMPNO>7839</EMPNO><ENAME>KING
</ENAME><JOB>PRESIDENT</JOB><HIREDATE>1981-11-17</HIREDATE><SAL>5000</SAL><DEPTN
O>10</DEPTNO></ROW><ROW><EMPNO>7844</EMPNO><ENAME>TURNER</ENAME><JOB>SALESMAN</J
OB><MGR>7698</MGR><HIREDATE>1981-09-08</HIREDATE><SAL>1500</SAL><COMM>0</COMM><D
EPTNO>30</DEPTNO></ROW><ROW><EMPNO>7900</EMPNO><ENAME>JAMES</ENAME><JOB>CLERK</J
OB><MGR>7698</MGR><HIREDATE>1981-12-03</HIREDATE><SAL>950</SAL><DEPTNO>30</DEPTN
O></ROW><ROW><EMPNO>7902</EMPNO><ENAME>FORD</ENAME><JOB>ANALYST</JOB><MGR>7566</
MGR><HIREDATE>1981-12-03</HIREDATE><SAL>3000</SAL><DEPTNO>20</DEPTNO></ROW><ROW>
<EMPNO>7934</EMPNO><ENAME>MILLER</ENAME><JOB>CLERK</JOB><MGR>7782</MGR><HIREDATE
>1982-01-23</HIREDATE><SAL>1300</SAL><DEPTNO>10</DEPTNO></ROW><ROW><EMPNO>9999</
EMPNO><ENAME>ほげ</ENAME><JOB>ENGINEER</JOB><MGR>7566</MGR><HIREDATE>2008-01-01<
/HIREDATE><SAL>2500</SAL><DEPTNO>20</DEPTNO></ROW></ROWSET>


経過: 00:00:00.41

さらに前回までに紹介した、DBMS_XMLGEN.GETXMLやDBMS_XMLGEN.GETXMLTYPE()では関数に渡すクエリーにorder by句を付加すればソートできる。

SCOTT> select
  2    dbms_xmlgen.getxml(sqlQuery=>'select * from emp order by empno') xmldoc
  3  from dual
  4  /

XMLDOC
--------------------------------------------------------------------------------
<?xml version="1.0"?>
<ROWSET>
 <ROW>
  <EMPNO>7369</EMPNO>
  <ENAME>SMITH</ENAME>
  <JOB>CLERK</JOB>
  <MGR>7902</MGR>
  <HIREDATE>80-12-17</HIREDATE>
  <SAL>800</SAL>
  <DEPTNO>20</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7499</EMPNO>
  <ENAME>ALLEN</ENAME>
  <JOB>SALESMAN</JOB>
  <MGR>7698</MGR>
  <HIREDATE>81-02-20</HIREDATE>
  <SAL>1600</SAL>
  <COMM>300</COMM>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7521</EMPNO>
  <ENAME>WARD</ENAME>
  <JOB>SALESMAN</JOB>
  <MGR>7698</MGR>
  <HIREDATE>81-02-22</HIREDATE>
  <SAL>1250</SAL>
  <COMM>500</COMM>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7566</EMPNO>
  <ENAME>JONES</ENAME>
  <JOB>MANAGER</JOB>
  <MGR>7839</MGR>
  <HIREDATE>81-04-02</HIREDATE>
  <SAL>2975</SAL>
  <DEPTNO>20</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7654</EMPNO>
  <ENAME>MARTIN</ENAME>
  <JOB>SALESMAN</JOB>
  <MGR>7698</MGR>
  <HIREDATE>81-09-28</HIREDATE>
  <SAL>1250</SAL>
  <COMM>1400</COMM>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7698</EMPNO>
  <ENAME>BLAKE</ENAME>
  <JOB>MANAGER</JOB>
  <MGR>7839</MGR>
  <HIREDATE>81-05-01</HIREDATE>
  <SAL>2850</SAL>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7782</EMPNO>
  <ENAME>CLARK</ENAME>
  <JOB>MANAGER</JOB>
  <MGR>7839</MGR>
  <HIREDATE>81-06-09</HIREDATE>
  <SAL>2450</SAL>
  <DEPTNO>10</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7839</EMPNO>
  <ENAME>KING</ENAME>
  <JOB>PRESIDENT</JOB>
  <HIREDATE>81-11-17</HIREDATE>
  <SAL>5000</SAL>
  <DEPTNO>10</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7844</EMPNO>
  <ENAME>TURNER</ENAME>
  <JOB>SALESMAN</JOB>
  <MGR>7698</MGR>
  <HIREDATE>81-09-08</HIREDATE>
  <SAL>1500</SAL>
  <COMM>0</COMM>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7900</EMPNO>
  <ENAME>JAMES</ENAME>
  <JOB>CLERK</JOB>
  <MGR>7698</MGR>
  <HIREDATE>81-12-03</HIREDATE>
  <SAL>950</SAL>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7902</EMPNO>
  <ENAME>FORD</ENAME>
  <JOB>ANALYST</JOB>
  <MGR>7566</MGR>
  <HIREDATE>81-12-03</HIREDATE>
  <SAL>3000</SAL>
  <DEPTNO>20</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7934</EMPNO>
  <ENAME>MILLER</ENAME>
  <JOB>CLERK</JOB>
  <MGR>7782</MGR>
  <HIREDATE>82-01-23</HIREDATE>
  <SAL>1300</SAL>
  <DEPTNO>10</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>9999</EMPNO>
  <ENAME>ほげ</ENAME>
  <JOB>ENGINEER</JOB>
  <MGR>7566</MGR>
  <HIREDATE>08-01-01</HIREDATE>
  <SAL>2500</SAL>
  <DEPTNO>20</DEPTNO>
 </ROW>
</ROWSET>



経過: 00:00:00.65
SCOTT> 

これは書く必要は無かったかもしれないが念のため。
XMLQuery()関数や、XMLTable()関数ではXQueryのFLWOR式でorder by句を使えばソートできる。

SCOTT> select
  2    xmlroot(xmldoc.column_value, version '1.0')
  3  from
  4    xmltable(
  5      '<ROWSET>{
  6         for $d in ora:view("EMP")
  7         order by $d
  8         return $d
  9      }</ROWSET>'
 10    ) xmldoc
 11  /

XMLROOT(XMLDOC.COLUMN_VALUE,VERSION'1.0')
--------------------------------------------------------------------------------
<?xml version="1.0"?>
<ROWSET>
  <ROW>
    <EMPNO>7369</EMPNO>
    <ENAME>SMITH</ENAME>
    <JOB>CLERK</JOB>
    <MGR>7902</MGR>
    <HIREDATE>1980-12-17</HIREDATE>
    <SAL>800</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7499</EMPNO>
    <ENAME>ALLEN</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-02-20</HIREDATE>
    <SAL>1600</SAL>
    <COMM>300</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7521</EMPNO>
    <ENAME>WARD</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-02-22</HIREDATE>
    <SAL>1250</SAL>
    <COMM>500</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7566</EMPNO>
    <ENAME>JONES</ENAME>
    <JOB>MANAGER</JOB>
    <MGR>7839</MGR>
    <HIREDATE>1981-04-02</HIREDATE>
    <SAL>2975</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7654</EMPNO>
    <ENAME>MARTIN</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-09-28</HIREDATE>
    <SAL>1250</SAL>
    <COMM>1400</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7698</EMPNO>
    <ENAME>BLAKE</ENAME>
    <JOB>MANAGER</JOB>
    <MGR>7839</MGR>
    <HIREDATE>1981-05-01</HIREDATE>
    <SAL>2850</SAL>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7782</EMPNO>
    <ENAME>CLARK</ENAME>
    <JOB>MANAGER</JOB>
    <MGR>7839</MGR>
    <HIREDATE>1981-06-09</HIREDATE>
    <SAL>2450</SAL>
    <DEPTNO>10</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7839</EMPNO>
    <ENAME>KING</ENAME>
    <JOB>PRESIDENT</JOB>
    <HIREDATE>1981-11-17</HIREDATE>
    <SAL>5000</SAL>
    <DEPTNO>10</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7844</EMPNO>
    <ENAME>TURNER</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-09-08</HIREDATE>
    <SAL>1500</SAL>
    <COMM>0</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7900</EMPNO>
    <ENAME>JAMES</ENAME>
    <JOB>CLERK</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-12-03</HIREDATE>
    <SAL>950</SAL>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7902</EMPNO>
    <ENAME>FORD</ENAME>
    <JOB>ANALYST</JOB>
    <MGR>7566</MGR>
    <HIREDATE>1981-12-03</HIREDATE>
    <SAL>3000</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7934</EMPNO>
    <ENAME>MILLER</ENAME>
    <JOB>CLERK</JOB>
    <MGR>7782</MGR>
    <HIREDATE>1982-01-23</HIREDATE>
    <SAL>1300</SAL>
    <DEPTNO>10</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>9999</EMPNO>
    <ENAME>ほげ</ENAME>
    <JOB>ENGINEER</JOB>
    <MGR>7566</MGR>
    <HIREDATE>2008-01-01</HIREDATE>
    <SAL>2500</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
</ROWSET>


経過: 00:00:00.30
SCOTT> 

次回へつづく。

Oracle de XMLDB #21 - Relational dataをXMLへ #4

さて、リレーショナルデータをXMLへ変換する方法の４つ目は、以前から提供されているPL/SQLのDBMS_XMLGENパッケージのgetXML()関数を利用する例です。
前回利用したgetXMLType()関数がXMLTypeインスタンスを返してくるのに対して、こちらはCLOB型のインスタンスを返してきます。しかも一時LOBが生成されます。（一時LOBを作成しない関数もあります）

---

バックナンバー：

Oracle de XMLDB #18 - Relational dataをXMLへ #1
Oracle de XMLDB #19 - Relational dataをXMLへ #2
Oracle de XMLDB #20 - Relational dataをXMLへ #3

---

おお〜っ、XMLTypeインスタンスを返す他のどれよりも遅いですね。今回利用した関数は内部で一時LOBを作る為に負荷が高いのですかね？？（あくまで個人的な推測です。）

SCOTT> select
  2    dbms_xmlgen.getXML(sqlQuery=>'select * from emp') as xmldoc
  3  from dual
  4  /

XMLDOC
--------------------------------------------------------------------------------
<?xml version="1.0"?>
<ROWSET>
 <ROW>
  <EMPNO>9999</EMPNO>
  <ENAME>ほげ</ENAME>
  <JOB>ENGINEER</JOB>
  <MGR>7566</MGR>
  <HIREDATE>08-01-01</HIREDATE>
  <SAL>2500</SAL>
  <DEPTNO>20</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7369</EMPNO>
  <ENAME>SMITH</ENAME>
  <JOB>CLERK</JOB>
  <MGR>7902</MGR>
  <HIREDATE>80-12-17</HIREDATE>
  <SAL>800</SAL>
  <DEPTNO>20</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7499</EMPNO>
  <ENAME>ALLEN</ENAME>
  <JOB>SALESMAN</JOB>
  <MGR>7698</MGR>
  <HIREDATE>81-02-20</HIREDATE>
  <SAL>1600</SAL>
  <COMM>300</COMM>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7521</EMPNO>
  <ENAME>WARD</ENAME>
  <JOB>SALESMAN</JOB>
  <MGR>7698</MGR>
  <HIREDATE>81-02-22</HIREDATE>
  <SAL>1250</SAL>
  <COMM>500</COMM>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7566</EMPNO>
  <ENAME>JONES</ENAME>
  <JOB>MANAGER</JOB>
  <MGR>7839</MGR>
  <HIREDATE>81-04-02</HIREDATE>
  <SAL>2975</SAL>
  <DEPTNO>20</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7654</EMPNO>
  <ENAME>MARTIN</ENAME>
  <JOB>SALESMAN</JOB>
  <MGR>7698</MGR>
  <HIREDATE>81-09-28</HIREDATE>
  <SAL>1250</SAL>
  <COMM>1400</COMM>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7698</EMPNO>
  <ENAME>BLAKE</ENAME>
  <JOB>MANAGER</JOB>
  <MGR>7839</MGR>
  <HIREDATE>81-05-01</HIREDATE>
  <SAL>2850</SAL>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7782</EMPNO>
  <ENAME>CLARK</ENAME>
  <JOB>MANAGER</JOB>
  <MGR>7839</MGR>
  <HIREDATE>81-06-09</HIREDATE>
  <SAL>2450</SAL>
  <DEPTNO>10</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7839</EMPNO>
  <ENAME>KING</ENAME>
  <JOB>PRESIDENT</JOB>
  <HIREDATE>81-11-17</HIREDATE>
  <SAL>5000</SAL>
  <DEPTNO>10</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7844</EMPNO>
  <ENAME>TURNER</ENAME>
  <JOB>SALESMAN</JOB>
  <MGR>7698</MGR>
  <HIREDATE>81-09-08</HIREDATE>
  <SAL>1500</SAL>
  <COMM>0</COMM>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7900</EMPNO>
  <ENAME>JAMES</ENAME>
  <JOB>CLERK</JOB>
  <MGR>7698</MGR>
  <HIREDATE>81-12-03</HIREDATE>
  <SAL>950</SAL>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7902</EMPNO>
  <ENAME>FORD</ENAME>
  <JOB>ANALYST</JOB>
  <MGR>7566</MGR>
  <HIREDATE>81-12-03</HIREDATE>
  <SAL>3000</SAL>
  <DEPTNO>20</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7934</EMPNO>
  <ENAME>MILLER</ENAME>
  <JOB>CLERK</JOB>
  <MGR>7782</MGR>
  <HIREDATE>82-01-23</HIREDATE>
  <SAL>1300</SAL>
  <DEPTNO>10</DEPTNO>
 </ROW>
</ROWSET>



経過: 00:00:00.65
SCOTT> 

今回まででOracle11gデータベース側だけでリレーショナルデータをXMLへ変換する方法の簡単な実験は終わりです。
次回はクライアント側でリレーショナルデータを取り出してからXMLへ変換する方法でも試してみますか・・・・

Oracle de XMLDB #20 - Relational dataをXMLへ #3

さて前回に引き続きリレーショナルデータをXMLへ変換する方法の３つ目は、以前から提供されているPL/SQLのDBMS_XMLGENパッケージのgetXMLType()関数を利用する例です。

---

バックナンバー：

Oracle de XMLDB #18 - Relational dataをXMLへ #1

Oracle de XMLDB #19 - Relational dataをXMLへ #2

---

では早速取りかかる。

SCOTT> select
  2    dbms_xmlgen.getXMLType(sqlQuery=>'select * from emp') as column_value
  3  from dual
  4  /

COLUMN_VALUE
--------------------------------------------------------------------------------
<ROWSET>
 <ROW>
  <EMPNO>9999</EMPNO>
  <ENAME>ほげ</ENAME>
  <JOB>ENGINEER</JOB>
  <MGR>7566</MGR>
  <HIREDATE>08-01-01</HIREDATE>
  <SAL>2500</SAL>
  <DEPTNO>20</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7369</EMPNO>
  <ENAME>SMITH</ENAME>
  <JOB>CLERK</JOB>
  <MGR>7902</MGR>
  <HIREDATE>80-12-17</HIREDATE>
  <SAL>800</SAL>
  <DEPTNO>20</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7499</EMPNO>
  <ENAME>ALLEN</ENAME>
  <JOB>SALESMAN</JOB>
  <MGR>7698</MGR>
  <HIREDATE>81-02-20</HIREDATE>
  <SAL>1600</SAL>
  <COMM>300</COMM>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7521</EMPNO>
  <ENAME>WARD</ENAME>
  <JOB>SALESMAN</JOB>
  <MGR>7698</MGR>
  <HIREDATE>81-02-22</HIREDATE>
  <SAL>1250</SAL>
  <COMM>500</COMM>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7566</EMPNO>
  <ENAME>JONES</ENAME>
  <JOB>MANAGER</JOB>
  <MGR>7839</MGR>
  <HIREDATE>81-04-02</HIREDATE>
  <SAL>2975</SAL>
  <DEPTNO>20</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7654</EMPNO>
  <ENAME>MARTIN</ENAME>
  <JOB>SALESMAN</JOB>
  <MGR>7698</MGR>
  <HIREDATE>81-09-28</HIREDATE>
  <SAL>1250</SAL>
  <COMM>1400</COMM>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7698</EMPNO>
  <ENAME>BLAKE</ENAME>
  <JOB>MANAGER</JOB>
  <MGR>7839</MGR>
  <HIREDATE>81-05-01</HIREDATE>
  <SAL>2850</SAL>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7782</EMPNO>
  <ENAME>CLARK</ENAME>
  <JOB>MANAGER</JOB>
  <MGR>7839</MGR>
  <HIREDATE>81-06-09</HIREDATE>
  <SAL>2450</SAL>
  <DEPTNO>10</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7839</EMPNO>
  <ENAME>KING</ENAME>
  <JOB>PRESIDENT</JOB>
  <HIREDATE>81-11-17</HIREDATE>
  <SAL>5000</SAL>
  <DEPTNO>10</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7844</EMPNO>
  <ENAME>TURNER</ENAME>
  <JOB>SALESMAN</JOB>
  <MGR>7698</MGR>
  <HIREDATE>81-09-08</HIREDATE>
  <SAL>1500</SAL>
  <COMM>0</COMM>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7900</EMPNO>
  <ENAME>JAMES</ENAME>
  <JOB>CLERK</JOB>
  <MGR>7698</MGR>
  <HIREDATE>81-12-03</HIREDATE>
  <SAL>950</SAL>
  <DEPTNO>30</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7902</EMPNO>
  <ENAME>FORD</ENAME>
  <JOB>ANALYST</JOB>
  <MGR>7566</MGR>
  <HIREDATE>81-12-03</HIREDATE>
  <SAL>3000</SAL>
  <DEPTNO>20</DEPTNO>
 </ROW>
 <ROW>
  <EMPNO>7934</EMPNO>
  <ENAME>MILLER</ENAME>
  <JOB>CLERK</JOB>
  <MGR>7782</MGR>
  <HIREDATE>82-01-23</HIREDATE>
  <SAL>1300</SAL>
  <DEPTNO>10</DEPTNO>
 </ROW>
</ROWSET>


経過: 00:00:00.46

おや〜、SQL/XMLのXMLQUERY関数やXMLTABLE関数だけを利用した結果とは決定的な違いが１つあるのにお気づきだろうか？

そう、この時点で既にインデントされ改行が付加され人が読み易い形式に整形されている。Oracleさんの気まぐれなのか・・・・・・

DBMS_XMLGEN.getXMLType()を利用した場合もXMLQUERY関数やXMLTABLE関数だけを利用した場合同様XML宣言は無い。

いつものXMLROOT()関数でXML宣言を付加してみる。

SCOTT> select
  2    xmlroot(
  3      dbms_xmlgen.getXMLType(sqlQuery=>'select * from emp')
  4      ,version '1.0'
  5    ) as column_value
  6  from dual
  7  /

COLUMN_VALUE
--------------------------------------------------------------------------------
<?xml version="1.0"?>
<ROWSET>
  <ROW>
    <EMPNO>9999</EMPNO>
    <ENAME>ほげ</ENAME>
    <JOB>ENGINEER</JOB>
    <MGR>7566</MGR>
    <HIREDATE>08-01-01</HIREDATE>
    <SAL>2500</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7369</EMPNO>
    <ENAME>SMITH</ENAME>
    <JOB>CLERK</JOB>
    <MGR>7902</MGR>
    <HIREDATE>80-12-17</HIREDATE>
    <SAL>800</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7499</EMPNO>
    <ENAME>ALLEN</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>81-02-20</HIREDATE>
    <SAL>1600</SAL>
    <COMM>300</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7521</EMPNO>
    <ENAME>WARD</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>81-02-22</HIREDATE>
    <SAL>1250</SAL>
    <COMM>500</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7566</EMPNO>
    <ENAME>JONES</ENAME>
    <JOB>MANAGER</JOB>
    <MGR>7839</MGR>
    <HIREDATE>81-04-02</HIREDATE>
    <SAL>2975</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7654</EMPNO>
    <ENAME>MARTIN</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>81-09-28</HIREDATE>
    <SAL>1250</SAL>
    <COMM>1400</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7698</EMPNO>
    <ENAME>BLAKE</ENAME>
    <JOB>MANAGER</JOB>
    <MGR>7839</MGR>
    <HIREDATE>81-05-01</HIREDATE>
    <SAL>2850</SAL>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7782</EMPNO>
    <ENAME>CLARK</ENAME>
    <JOB>MANAGER</JOB>
    <MGR>7839</MGR>
    <HIREDATE>81-06-09</HIREDATE>
    <SAL>2450</SAL>
    <DEPTNO>10</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7839</EMPNO>
    <ENAME>KING</ENAME>
    <JOB>PRESIDENT</JOB>
    <HIREDATE>81-11-17</HIREDATE>
    <SAL>5000</SAL>
    <DEPTNO>10</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7844</EMPNO>
    <ENAME>TURNER</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>81-09-08</HIREDATE>
    <SAL>1500</SAL>
    <COMM>0</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7900</EMPNO>
    <ENAME>JAMES</ENAME>
    <JOB>CLERK</JOB>
    <MGR>7698</MGR>
    <HIREDATE>81-12-03</HIREDATE>
    <SAL>950</SAL>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7902</EMPNO>
    <ENAME>FORD</ENAME>
    <JOB>ANALYST</JOB>
    <MGR>7566</MGR>
    <HIREDATE>81-12-03</HIREDATE>
    <SAL>3000</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7934</EMPNO>
    <ENAME>MILLER</ENAME>
    <JOB>CLERK</JOB>
    <MGR>7782</MGR>
    <HIREDATE>82-01-23</HIREDATE>
    <SAL>1300</SAL>
    <DEPTNO>10</DEPTNO>
  </ROW>
</ROWSET>


経過: 00:00:00.58
SCOTT>

PL/SQLパッケージを利用している影響なのだろう。SQL/XML関数だけの場合よりは負荷はおおきいようだ。

ではまた。

Oracle de XMLDB #19 - Relational dataをXMLへ #2

Relational dataからXMLを生成する方法の２つ目は、SQL/XMLXMLQUERY()とOracleが提供しているXQuery関数であるora:view()を組み合わせる方法。

---

バックナンバー：
Oracle de XMLDB #18 - Relational dataからXMLへ #1

---

では、早速試してみる。

SCOTT> select * from emp
    2  /

     EMPNO ENAME      JOB              MGR HIREDATE        SAL       COMM     DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
      9999 ほげ       ENGINEER        7566 08-01-01       2500                    20
      7369 SMITH      CLERK           7902 80-12-17        800                    20
      7499 ALLEN      SALESMAN        7698 81-02-20       1600        300         30
      7521 WARD       SALESMAN        7698 81-02-22       1250        500         30
      7566 JONES      MANAGER         7839 81-04-02       2975                    20
      7654 MARTIN     SALESMAN        7698 81-09-28       1250       1400         30
      7698 BLAKE      MANAGER         7839 81-05-01       2850                    30
      7782 CLARK      MANAGER         7839 81-06-09       2450                    10
      7839 KING       PRESIDENT            81-11-17       5000                    10
      7844 TURNER     SALESMAN        7698 81-09-08       1500          0         30
      7900 JAMES      CLERK           7698 81-12-03        950                    30
      7902 FORD       ANALYST         7566 81-12-03       3000                    20
      7934 MILLER     CLERK           7782 82-01-23       1300                    10

13行が選択されました。

経過: 00:00:00.00
SCOTT> 
SCOTT> select
  2    xmlquery(
  3      '<ROWSET>{
  4        for $d in ora:view("EMP")
  5        return $d
  6      }</ROWSET>'
  7      returning content
  8    ) as COLUMN_VALUE
  9  from dual
 10  /

COLUMN_VALUE
--------------------------------------------------------------------------------
<ROWSET><ROW><EMPNO>9999</EMPNO><ENAME>ほげ</ENAME><JOB>ENGINEER</JOB><MGR>7566<
/MGR><HIREDATE>2008-01-01</HIREDATE><SAL>2500</SAL><DEPTNO>20</DEPTNO></ROW><ROW
><EMPNO>7369</EMPNO><ENAME>SMITH</ENAME><JOB>CLERK</JOB><MGR>7902</MGR><HIREDATE
>1980-12-17</HIREDATE><SAL>800</SAL><DEPTNO>20</DEPTNO></ROW><ROW><EMPNO>7499</E
MPNO><ENAME>ALLEN</ENAME><JOB>SALESMAN</JOB><MGR>7698</MGR><HIREDATE>1981-02-20<
/HIREDATE><SAL>1600</SAL><COMM>300</COMM><DEPTNO>30</DEPTNO></ROW><ROW><EMPNO>75
21</EMPNO><ENAME>WARD</ENAME><JOB>SALESMAN</JOB><MGR>7698</MGR><HIREDATE>1981-02
-22</HIREDATE><SAL>1250</SAL><COMM>500</COMM><DEPTNO>30</DEPTNO></ROW><ROW><EMPN
O>7566</EMPNO><ENAME>JONES</ENAME><JOB>MANAGER</JOB><MGR>7839</MGR><HIREDATE>198
1-04-02</HIREDATE><SAL>2975</SAL><DEPTNO>20</DEPTNO></ROW><ROW><EMPNO>7654</EMPN
O><ENAME>MARTIN</ENAME><JOB>SALESMAN</JOB><MGR>7698</MGR><HIREDATE>1981-09-28</H
IREDATE><SAL>1250</SAL><COMM>1400</COMM><DEPTNO>30</DEPTNO></ROW><ROW><EMPNO>769
8</EMPNO><ENAME>BLAKE</ENAME><JOB>MANAGER</JOB><MGR>7839</MGR><HIREDATE>1981-05-
01</HIREDATE><SAL>2850</SAL><DEPTNO>30</DEPTNO></ROW><ROW><EMPNO>7782</EMPNO><EN
AME>CLARK</ENAME><JOB>MANAGER</JOB><MGR>7839</MGR><HIREDATE>1981-06-09</HIREDATE
><SAL>2450</SAL><DEPTNO>10</DEPTNO></ROW><ROW><EMPNO>7839</EMPNO><ENAME>KING</EN
AME><JOB>PRESIDENT</JOB><HIREDATE>1981-11-17</HIREDATE><SAL>5000</SAL><DEPTNO>10
</DEPTNO></ROW><ROW><EMPNO>7844</EMPNO><ENAME>TURNER</ENAME><JOB>SALESMAN</JOB><
MGR>7698</MGR><HIREDATE>1981-09-08</HIREDATE><SAL>1500</SAL><COMM>0</COMM><DEPTN
O>30</DEPTNO></ROW><ROW><EMPNO>7900</EMPNO><ENAME>JAMES</ENAME><JOB>CLERK</JOB><
MGR>7698</MGR><HIREDATE>1981-12-03</HIREDATE><SAL>950</SAL><DEPTNO>30</DEPTNO></
ROW><ROW><EMPNO>7902</EMPNO><ENAME>FORD</ENAME><JOB>ANALYST</JOB><MGR>7566</MGR>
<HIREDATE>1981-12-03</HIREDATE><SAL>3000</SAL><DEPTNO>20</DEPTNO></ROW><ROW><EMP
NO>7934</EMPNO><ENAME>MILLER</ENAME><JOB>CLERK</JOB><MGR>7782</MGR><HIREDATE>198
2-01-23</HIREDATE><SAL>1300</SAL><DEPTNO>10</DEPTNO></ROW></ROWSET>
経過: 00:00:00.10
SCOTT> 

XMLTABLE()関数を使った場合と変るところはないが、関数本来の使い道からすればXMLQUERY()関数を使う方が自然に感じる。（まあ、どちらを使っても可能であることはまちがいないのですが。。）

最後に、前回も行ったようにXMLROOT()関数を利用しXML宣言を追加したXMLTypeインスタンスを取得してみた。

SCOTT> select
  2    xmlroot(
  3      xmlquery(
  4        '<ROWSET>{
  5           for $d in ora:view("EMP")
  6           return $d
  7        }</ROWSET>'
  8        returning content
  9      ),
 10      version '1.0'
 11    ) as column_value
 12  from dual
 13  /

COLUMN_VALUE
--------------------------------------------------------------------------------
<?xml version="1.0"?>
<ROWSET>
  <ROW>
    <EMPNO>9999</EMPNO>
    <ENAME>ほげ</ENAME>
    <JOB>ENGINEER</JOB>
    <MGR>7566</MGR>
    <HIREDATE>2008-01-01</HIREDATE>
    <SAL>2500</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7369</EMPNO>
    <ENAME>SMITH</ENAME>
    <JOB>CLERK</JOB>
    <MGR>7902</MGR>
    <HIREDATE>1980-12-17</HIREDATE>
    <SAL>800</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7499</EMPNO>
    <ENAME>ALLEN</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-02-20</HIREDATE>
    <SAL>1600</SAL>
    <COMM>300</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7521</EMPNO>
    <ENAME>WARD</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-02-22</HIREDATE>
    <SAL>1250</SAL>
    <COMM>500</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7566</EMPNO>
    <ENAME>JONES</ENAME>
    <JOB>MANAGER</JOB>
    <MGR>7839</MGR>
    <HIREDATE>1981-04-02</HIREDATE>
    <SAL>2975</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7654</EMPNO>
    <ENAME>MARTIN</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-09-28</HIREDATE>
    <SAL>1250</SAL>
    <COMM>1400</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7698</EMPNO>
    <ENAME>BLAKE</ENAME>
    <JOB>MANAGER</JOB>
    <MGR>7839</MGR>
    <HIREDATE>1981-05-01</HIREDATE>
    <SAL>2850</SAL>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7782</EMPNO>
    <ENAME>CLARK</ENAME>
    <JOB>MANAGER</JOB>
    <MGR>7839</MGR>
    <HIREDATE>1981-06-09</HIREDATE>
    <SAL>2450</SAL>
    <DEPTNO>10</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7839</EMPNO>
    <ENAME>KING</ENAME>
    <JOB>PRESIDENT</JOB>
    <HIREDATE>1981-11-17</HIREDATE>
    <SAL>5000</SAL>
    <DEPTNO>10</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7844</EMPNO>
    <ENAME>TURNER</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-09-08</HIREDATE>
    <SAL>1500</SAL>
    <COMM>0</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7900</EMPNO>
    <ENAME>JAMES</ENAME>
    <JOB>CLERK</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-12-03</HIREDATE>
    <SAL>950</SAL>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7902</EMPNO>
    <ENAME>FORD</ENAME>
    <JOB>ANALYST</JOB>
    <MGR>7566</MGR>
    <HIREDATE>1981-12-03</HIREDATE>
    <SAL>3000</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7934</EMPNO>
    <ENAME>MILLER</ENAME>
    <JOB>CLERK</JOB>
    <MGR>7782</MGR>
    <HIREDATE>1982-01-23</HIREDATE>
    <SAL>1300</SAL>
    <DEPTNO>10</DEPTNO>
  </ROW>
</ROWSET>


経過: 00:00:00.58
SCOTT> 

ではまた。

Oracle de XMLDB #18 - Relational dataをXMLへ #1

Oracle XML DBリポジトリ関連の話はしばらく脇に置いておき、これから数回に分けてリレーショナル表からXMLを生成する方法について、備忘録の意味も含めて書いておくことにする。

●　環境データ

Server : Dynabook SS SX/210LNLW (RAM:768MB) 
         CentOS5
         Oracle11g EE R1 11.1.0.6.0 for Linux x86

Client : Apple PowerMac G5 Dual 2.7Ghz (RAM:1GB) 
         MacOSX Tiger 10.4.11 Server
         Oracle10g Instant Client 10g R1 for MacOSX(PPC)

表を問い合わせXMLTypeインスタンスを返す方法は複数ある。まず最初に紹介するのは、XMLTABLE()関数のXqueryでora:view()関数を使う方法。

XMLTABLE()関数は、SQL/XMLで提供される標準関数で、本来はXMLデータをリレーショナルフォーマットへマッピングする為に利用する関数なのだが、今回は本来の目的とは異なる使い方をしてみた。
XMLTABLE()関数でリレーショナル表からXMLTypeインスタンスを取得するには、OracleがXXQuery向に提供している ora:view()関数を利用する。（Oracleが独自に拡張したXQuery向け関数の名前空間は、ora:）
ora:view()関数は、XQueryの標準関数であるfn:doc()関数を利用する感覚で利用できる。

以下の例では、XMLTABLE()関数でCOLUMNS句を指定していしないのがポイント。尚、COLUMN_VALUE疑似列を利用しています。

Last login: Sat Feb  9 06:46:43 on console
Welcome to Darwin!
G5Server:˜ discus$ sqlplus /nolog

SQL*Plus: Release 10.1.0.3.0 - Production on 土 2月 9 15:30:44 2008

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

SCOTT> conn scott/tiger@lampeye
接続されました。
SCOTT> 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 Linux: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production

SCOTT> set pagesize 1000
SCOTT> set long 4000
SCOTT> set sqlterm off
SCOTT> set linesize 80
SCOTT> l
  1  select xmldoc.COLUMN_VALUE
  2  from
  3    xmltable(
  4      '<ROWSET>{
  5        for $d in ora:view("EMP")
  6        return $d
  7      }</ROWSET>'
  8*   ) xmldoc
SCOTT> /

COLUMN_VALUE
--------------------------------------------------------------------------------
<ROWSET><ROW><EMPNO>9999</EMPNO><ENAME>ほげ</ENAME><JOB>ENGINEER</JOB><MGR>7566<
/MGR><HIREDATE>2008-01-01</HIREDATE><SAL>2500</SAL><DEPTNO>20</DEPTNO></ROW><ROW
><EMPNO>7369</EMPNO><ENAME>SMITH</ENAME><JOB>CLERK</JOB><MGR>7902</MGR><HIREDATE
>1980-12-17</HIREDATE><SAL>800</SAL><DEPTNO>20</DEPTNO></ROW><ROW><EMPNO>7499</E
MPNO><ENAME>ALLEN</ENAME><JOB>SALESMAN</JOB><MGR>7698</MGR><HIREDATE>1981-02-20<
/HIREDATE><SAL>1600</SAL><COMM>300</COMM><DEPTNO>30</DEPTNO></ROW><ROW><EMPNO>75
21</EMPNO><ENAME>WARD</ENAME><JOB>SALESMAN</JOB><MGR>7698</MGR><HIREDATE>1981-02
-22</HIREDATE><SAL>1250</SAL><COMM>500</COMM><DEPTNO>30</DEPTNO></ROW><ROW><EMPN
O>7566</EMPNO><ENAME>JONES</ENAME><JOB>MANAGER</JOB><MGR>7839</MGR><HIREDATE>198
1-04-02</HIREDATE><SAL>2975</SAL><DEPTNO>20</DEPTNO></ROW><ROW><EMPNO>7654</EMPN
O><ENAME>MARTIN</ENAME><JOB>SALESMAN</JOB><MGR>7698</MGR><HIREDATE>1981-09-28</H
IREDATE><SAL>1250</SAL><COMM>1400</COMM><DEPTNO>30</DEPTNO></ROW><ROW><EMPNO>769
8</EMPNO><ENAME>BLAKE</ENAME><JOB>MANAGER</JOB><MGR>7839</MGR><HIREDATE>1981-05-
01</HIREDATE><SAL>2850</SAL><DEPTNO>30</DEPTNO></ROW><ROW><EMPNO>7782</EMPNO><EN
AME>CLARK</ENAME><JOB>MANAGER</JOB><MGR>7839</MGR><HIREDATE>1981-06-09</HIREDATE
><SAL>2450</SAL><DEPTNO>10</DEPTNO></ROW><ROW><EMPNO>7839</EMPNO><ENAME>KING</EN
AME><JOB>PRESIDENT</JOB><HIREDATE>1981-11-17</HIREDATE><SAL>5000</SAL><DEPTNO>10
</DEPTNO></ROW><ROW><EMPNO>7844</EMPNO><ENAME>TURNER</ENAME><JOB>SALESMAN</JOB><
MGR>7698</MGR><HIREDATE>1981-09-08</HIREDATE><SAL>1500</SAL><COMM>0</COMM><DEPTN
O>30</DEPTNO></ROW><ROW><EMPNO>7900</EMPNO><ENAME>JAMES</ENAME><JOB>CLERK</JOB><
MGR>7698</MGR><HIREDATE>1981-12-03</HIREDATE><SAL>950</SAL><DEPTNO>30</DEPTNO></
ROW><ROW><EMPNO>7902</EMPNO><ENAME>FORD</ENAME><JOB>ANALYST</JOB><MGR>7566</MGR>
<HIREDATE>1981-12-03</HIREDATE><SAL>3000</SAL><DEPTNO>20</DEPTNO></ROW><ROW><EMP
NO>7934</EMPNO><ENAME>MILLER</ENAME><JOB>CLERK</JOB><MGR>7782</MGR><HIREDATE>198
2-01-23</HIREDATE><SAL>1300</SAL><DEPTNO>10</DEPTNO></ROW></ROWSET>


経過: 00:00:00.11
SCOTT> 

これだとXML宣言が無い。ではどうやってXML宣言を付加するかと言えば、XMLRoot()関数を使う。
XMLRoot()関数は2005年まではSQL/XMLの標準関数だったが現在は標準関数ではない。但し、Oracleでは利用できるのでXMLRoot()関数を利用してXML宣言を付加することができる。

では早速試してみよう！。

SCOTT> select
  2    xmlroot(xmldoc.column_value,version '1.0')
  3  from
  4    xmltable(
  5      '<ROWSET>{
  6         for $d in ora:view("EMP")
  7         return $d
  8      }</ROWSET>'
  9    ) xmldoc
 10  /

XMLROOT(XMLDOC.COLUMN_VALUE,VERSION'1.0')
--------------------------------------------------------------------------------
<?xml version="1.0"?>
<ROWSET>
  <ROW>
    <EMPNO>9999</EMPNO>
    <ENAME>ほげ</ENAME>
    <JOB>ENGINEER</JOB>
    <MGR>7566</MGR>
    <HIREDATE>2008-01-01</HIREDATE>
    <SAL>2500</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7369</EMPNO>
    <ENAME>SMITH</ENAME>
    <JOB>CLERK</JOB>
    <MGR>7902</MGR>
    <HIREDATE>1980-12-17</HIREDATE>
    <SAL>800</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7499</EMPNO>
    <ENAME>ALLEN</ENAME>
   <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-02-20</HIREDATE>
    <SAL>1600</SAL>
    <COMM>300</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7521</EMPNO>
    <ENAME>WARD</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-02-22</HIREDATE>
    <SAL>1250</SAL>
    <COMM>500</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7566</EMPNO>
    <ENAME>JONES</ENAME>
    <JOB>MANAGER</JOB>
    <MGR>7839</MGR>
    <HIREDATE>1981-04-02</HIREDATE>
    <SAL>2975</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7654</EMPNO>
    <ENAME>MARTIN</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-09-28</HIREDATE>
    <SAL>1250</SAL>
    <COMM>1400</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7698</EMPNO>
    <ENAME>BLAKE</ENAME>
    <JOB>MANAGER</JOB>
    <MGR>7839</MGR>
    <HIREDATE>1981-05-01</HIREDATE>
    <SAL>2850</SAL>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7782</EMPNO>
    <ENAME>CLARK</ENAME>
    <JOB>MANAGER</JOB>
    <MGR>7839</MGR>
    <HIREDATE>1981-06-09</HIREDATE>
    <SAL>2450</SAL>
    <DEPTNO>10</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7839</EMPNO>
    <ENAME>KING</ENAME>
    <JOB>PRESIDENT</JOB>
    <HIREDATE>1981-11-17</HIREDATE>
    <SAL>5000</SAL>
    <DEPTNO>10</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7844</EMPNO>
    <ENAME>TURNER</ENAME>
    <JOB>SALESMAN</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-09-08</HIREDATE>
    <SAL>1500</SAL>
    <COMM>0</COMM>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7900</EMPNO>
    <ENAME>JAMES</ENAME>
    <JOB>CLERK</JOB>
    <MGR>7698</MGR>
    <HIREDATE>1981-12-03</HIREDATE>
    <SAL>950</SAL>
    <DEPTNO>30</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7902</EMPNO>
    <ENAME>FORD</ENAME>
    <JOB>ANALYST</JOB>
    <MGR>7566</MGR>
    <HIREDATE>1981-12-03</HIREDATE>
    <SAL>3000</SAL>
    <DEPTNO>20</DEPTNO>
  </ROW>
  <ROW>
    <EMPNO>7934</EMPNO>
    <ENAME>MILLER</ENAME>
    <JOB>CLERK</JOB>
    <MGR>7782</MGR>
    <HIREDATE>1982-01-23</HIREDATE>
    <SAL>1300</SAL>
    <DEPTNO>10</DEPTNO>
  </ROW>
</ROWSET>

経過: 00:00:00.33
SCOTT> 

あれ、XMLRoot()関数に渡しているXMLTABLE()関数で取得したXMLTypeインスタンスには改行がありませんでしたが、XMLROOT()関数を利用すると改行が付加されたXMLTypeインスタンスが返されます。また、その影響だと思うが経過時間も増えている。

こりゃ参った〜という感じです。以前もOracle XML DBに関するエントリでwhitespaceのpreserve/stripは現時点のOracle XML DBでは明示的に制御できないということは書いていましたが思わぬところでwhitespaceかってに付加されるという動きには戸惑いますね。（利用する側で制御できるようにしてもらったほうがスッキリするように感じます。）

トレースして詳細に追跡したわけでは無いのであくまで想像の域を脱していないのですが、もしかすると、XMLROOT()関数はXMLTypeインスタンスを受け取りXML宣言を付加して返してくる際、XML宣言を追加したDOMを生成した上でXMLTypeインスタンスを返してくるのではないかと考えています。（くどいようですが、これは私の推測に過ぎませんので誤解なさらないようにしてください。）

時間があればもっと深〜〜〜く追っかけてみたい現象なのでとりあえず、TODOリストに追加しておきますかね。

では次回へつづく。

Oracle de XMLDB #17

「XMLマスター：プロフェッショナル（データベース） 試験」のサンプル問題がXML技術者育成推進委員会のサイトに掲載されている。
この問題の幾つかは直接XML DBを操作して確認することができる問題なのだが、それらの問題をOracle11g R1 11.1.0.6.0を利用して試す場合には次の２点には注意しておいたほうがよいだろう。

●　最初はSQL*Plusの仕様による影響。

SQL*PlusのXQueryコマンドで試す場合以下のように＠がSQL*PlusのSTARTコマンとして実行されてしまう。

SCOTT> xquery
  2  for $n in fn:doc("/public/scott/xml/example2.xml")/list
  3  return
  4    <codeList>
  5      <code> {
  6        @code
SP2-0310: ファイル"code.sql"をオープンできません。
  6  .     
SCOTT> 

これを回避する方法は以前も紹介した方法でSQL*PlusのSTARTコマンドして実行されることを回避できる。

SCOTT> xquery
  2  for $n in fn:doc("/public/scott/xml/example2.xml")/list
  3  return
  4    <codeList>
  5      <code>{
  6        (::) @code
  7      }</code>
・・・以下省略・・・

「XMLマスター：プロフェッショナル（データベース） 試験のサンプル問題」の問題２をOracle11g R1 11.1.0.6.0で試す場合には忘れずに！

●　もう一つはテキストノードのwhitespaceの取扱いに関するもの。

Oracle11g R1 11.1.0.6.0のXMLDBではテキストノードに対するwhitespaceの取扱いは常にstripであること。以下の例を見ていただければ一目瞭然。
ということで「XMLマスター：プロフェッショナル（データベース） 試験のサンプル問題」の問題３をOracle11g R1 11.1.0.6.0で実行した場合<space> </space>というノードの空白は削除されてしまうのでこれまたOracle11g R1ではそのような実装になっているということをお忘れなく。

SCOTT> !cat sample.xml
<?xml version="1.0" encoding="utf-8"?>
<space> </space>

SCOTT> declare
  2   r boolean;
  3  begin
  4    r := dbms_xdb.createresource(
  5             '/public/scott/xml/sample.xml',
  6             bfilename('SCOTT_XMLDIR','sample.xml'),
  7             nls_charset_id('AL32UTF8'));
  8  commit;
  9  end;
 10  /

PL/SQLプロシージャが正常に完了しました。

SCOTT> 
SCOTT> xquery
  2  fn:doc("/public/scott/xml/sample.xml")/space
  3  /

Result Sequence
--------------------------------------------------------------------------------
<space/>

SCOTT> 

ちなみにオープンソースのSaxon Bではテキストノードのwhitespaceの扱いは指定可能なのでXMLマスタープロフェッショナル（データベース）のようなベンダー比依存の試験勉強の為だけであればSaxon Bを使ったほうが無難かもしれない。ただ、プロジェクトでOracle11g R1のXML DBを利用するのであればOracle11g R1を利用して検証したほうがいいのは言うまでもない。

以下、saxon 9.0.0J(saxon B 9.0.0.2のjava版）を利用して上記２点に関連する部分を実行した例

環境：MacOSX Server 10.4.11 Tiger

●　SAXON B 9.0.0.2(java版）をダウンロード、unzipする。

今回は/User/Sharedで作業を行うことにした。Webブラウザでダウンロードしてもいいのだが折角なので全部コマンドで行っちゃいましょう。
curlコマンドでSAXON B 9.0.0.2(Java版）をダウンロード後、unzip。

G5Server:˜ oracle$ java -version
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241)
Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode)
G5Server:˜ oracle$ 
G5Server:˜ oracle$ cd /Users/Shared/ 
G5Server:/Users/Shared oracle$ 
G5Server:/Users/Shared oracle$ curl -L -o saxonb9-0-0-2j.zip http://prdownloads.sourceforge.net/saxon/saxonb9-0-0-2j.zip
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1862k  100 1862k    0     0   144k      0  0:00:12  0:00:12 --:--:--  144k

G5Server:/Users/Shared oracle$ unzip saxonb9-0-0-2j.zip -d saxonb9-0-0-2j
Archive:  saxonb9-0-0-2j.zip
  inflating: saxonb9-0-0-2j/saxon9-ant.jar  
  inflating: saxonb9-0-0-2j/saxon9-dom.jar  
  inflating: saxonb9-0-0-2j/saxon9-dom4j.jar  
  inflating: saxonb9-0-0-2j/saxon9-jdom.jar  
  inflating: saxonb9-0-0-2j/saxon9-s9api.jar  
  inflating: saxonb9-0-0-2j/saxon9-sql.jar  
  inflating: saxonb9-0-0-2j/saxon9-xom.jar  
  inflating: saxonb9-0-0-2j/saxon9-xpath.jar  
  inflating: saxonb9-0-0-2j/saxon9-xqj.jar  
  inflating: saxonb9-0-0-2j/saxon9.jar  
G5Server:/Users/Shared oracle$ cd saxonb9-0-0-2j

●　XMLファイルとXQueryファイルを用意する。

前述したXMLマスタープロフェッショナル（データベース）試験のサンプル問題元にXMLファイルとXQueryファイルを準備しておく。
（SAXON Bのコマンドラインでは直接XQueryを記述できずXQueryを記述したファイルを指定する必要がある為。)

G5Server:/Users/Shared/saxonb9-0-0-2j oracle$ ll
total 10584
-rw-r--r--   1 oracle  wheel      444 Dec 31 17:38 example.xml
-rw-r--r--   1 oracle  wheel       40 Dec 31 17:38 query1.xql
-rw-r--r--   1 oracle  wheel       58 Dec 31 17:38 query2.xql
-rw-r--r--   1 oracle  wheel      199 Dec 31 17:38 query_a.xql
-rw-r--r--   1 oracle  wheel      188 Dec 31 17:38 query_b.xql
-rw-r--r--   1 oracle  wheel      204 Dec 31 17:38 query_c.xql
-rw-r--r--   1 oracle  wheel      189 Dec 31 17:38 query_d.xql
-rw-r--r--   1 oracle  wheel       57 Dec 31 17:38 result.xml
-rw-r--r--   1 oracle  wheel      108 Dec 31 17:38 sample.xml
-rw-r--r--   1 oracle  wheel       56 Dec 31 17:38 sample2.xml
-rw-r--r--   1 oracle  wheel    23963 Nov 30 14:35 saxon9-ant.jar
-rw-r--r--   1 oracle  wheel   110602 Nov 30 14:35 saxon9-dom.jar
-rw-r--r--   1 oracle  wheel    30000 Nov 30 14:35 saxon9-dom4j.jar
-rw-r--r--   1 oracle  wheel    32743 Nov 30 14:35 saxon9-jdom.jar
-rw-r--r--   1 oracle  wheel   110818 Nov 30 14:35 saxon9-s9api.jar
-rw-r--r--   1 oracle  wheel    45598 Nov 30 14:35 saxon9-sql.jar
-rw-r--r--   1 oracle  wheel    45218 Nov 30 14:35 saxon9-xom.jar
-rw-r--r--   1 oracle  wheel    43536 Nov 30 14:35 saxon9-xpath.jar
-rw-r--r--   1 oracle  wheel   173255 Nov 30 14:35 saxon9-xqj.jar
-rw-r--r--   1 oracle  wheel  4737705 Nov 30 14:35 saxon9.jar
G5Server:/Users/Shared/saxonb9-0-0-2j oracle$ 

●　SAXON BのXQueryのコマンド形式は以下のようにして確認できます。

G5Server:/Users/Shared/saxonb9-0-0-2j oracle$ java -cp saxon9.jar net.sf.saxon.Query -?
Saxon 9.0.0.2J from Saxonica
Usage: java net.sf.saxon.Query [options] query {param=value}...
Options: 
  -cr:classname         Use specified CollectionURIResolver class
  -dtd:on|off           Validate using DTD
  -expand:on|off        Expand defaults defined in schema/DTD
  -explain[:filename]   Display compiled expression tree
  -ext:[on|off]         Allow|Disallow external Java functions
  -l:on|off             Line numbering for source document
  -mr:classname         Use specified ModuleURIResolver class
  -o:filename           Send output to named file
  -outval:recover|fatal Handling of validation errors on result document
  -p                    Recognize Saxon file extensions and query parameters
  -pipe:push|pull       Execute internally in push or pull mode
  -projection:[on|off]  Use|Don't use source document projection
  -r:classname          Use URIResolver class
  -repeat:N             Repeat N times for performance measurement
  -s:file|URI           Provide initial context document
  -sa                   Schema-aware query (requires Saxon-SA)
  -strip:all|none|ignorable      Strip whitespace text nodes
  -t                    Display version and timing information
  -tree:tiny|linked     Select tree model
  -T[:classname]        Use TraceListener class
  -TJ                   Trace calls to external Java functions
  -u                    Names are URLs not filenames
  -val:strict|lax       Validate using schema
  -wrap:on|off          Wrap result sequence in XML elements
  -x:classname          Parser (XMLReader) used for source files
  -xi:on|off            Expand XInclude on all documents
  -xmlversion:1.0|1.1   Version of XML to be handled
  -?                    Display this message 
  param=value           Set query string parameter
  +param=value          Set query document parameter
  !option=value         Set serialization option
G5Server:/Users/Shared/saxonb9-0-0-2j oracle$

SAXON Bで「XMLマスター：プロフェッショナル（データベース） 試験のサンプル問題」の問題２を試す。

G5Server:/Users/Shared/saxonb9-0-0-2j oracle$ cat example.xml
<?xml version="1.0" encoding="utf-8"?>
<logList>
        <list code="w001" message="警告１"/>
        <list code="w002" message="警告２"/>
        <list code="e001" message="エラー１"/>
        <list code="e002" message="エラー２"/>
        <day date="2007-12-01">
                <log time="10:00:00" code="w001"/>
                <log time="14:00:00" code="e001"/>
        </day>
        <day date="2007-12-02">
                <log time="13:00:00" code="e002"/>
                <log time="15:00:00" code="e001"/>
        </day>
</logList>
G5Server:/Users/Shared/saxonb9-0-0-2j oracle$ cat -n query_a.xql
     1  <result>{
     2    let $doc := fn:doc("example.xml")
     3    for $log in $doc//log
     4    return
     5      <log>{
     6        $log/../@date,
     7        $log/@time,
     8        $doc//list[@code eq $log/@code]/@message
     9      }</log>
    10  }</result>
G5Server:/Users/Shared/saxonb9-0-0-2j oracle$ java -cp saxon9.jar net.sf.saxon.Query query_a.xql
<?xml version="1.0" encoding="UTF-8"?>
<result>
   <log date="2007-12-01" time="10:00:00" message="警告１"/>
   <log date="2007-12-01" time="14:00:00" message="エラー１"/>
   <log date="2007-12-02" time="13:00:00" message="エラー２"/>
   <log date="2007-12-02" time="15:00:00" message="エラー１"/>
</result>
G5Server:/Users/Shared/saxonb9-0-0-2j oracle$ cat -n query_b.xql
     1  <result>{
     2    let $doc := fn:doc("example.xml")
     3    for $log in $doc//log
     4    return
     5      <log>{
     6        ../@date,
     7        @time,
     8        ../../list[@code = $log/@code]/@message
     9      }</log>
    10  }</result>
G5Server:/Users/Shared/saxonb9-0-0-2j oracle$ java -cp saxon9.jar net.sf.saxon.Query query_b.xql
Error on line 6 of file:/Users/Shared/saxonb9-0-0-2j/query_b.xql:
  XPDY0002: The context item is not set
Query processing failed: Run-time errors were reported
G5Server:/Users/Shared/saxonb9-0-0-2j oracle$ cat -n query_c.xql
     1  <result>{
     2    let $doc := fn:doc("example.xml")
     3    for $day in $doc//day
     4    return
     5      <log>{
     6        $day/@date,
     7        $day/log/@time,
     8        $doc//list[@code eq $day/log/@code]/@message
     9      }</log>
    10  }</result>
G5Server:/Users/Shared/saxonb9-0-0-2j oracle$ java -cp saxon9.jar net.sf.saxon.Query query_c.xql
Error on line 7 of file:/Users/Shared/saxonb9-0-0-2j/query_c.xql:
  XQDY0025: Cannot create an element having two attributes with the same name: @time
Query processing failed: Run-time errors were reported
G5Server:/Users/Shared/saxonb9-0-0-2j oracle$ cat -n query_d.xql
     1  <result>{
     2    let $doc := fn:doc("example.xml")
     3    for $day in $doc//day
     4    return
     5      <log>{
     6        @date,
     7        log/@time,
     8        ../list[@code = $day/log/@code]/@message
     9     }</log>
    10  }</result>
G5Server:/Users/Shared/saxonb9-0-0-2j oracle$ java -cp saxon9.jar net.sf.saxon.Query query_d.xql
Error on line 6 of file:/Users/Shared/saxonb9-0-0-2j/query_d.xql:
  XPDY0002: The context item for axis step attribute::attribute(date, xs:anyAtomicType) is undefined
Query processing failed: Run-time errors were reported

● SAXON Bではテキストノードのwhitespaceの取扱いを-stripオプションで指示できる。

G5Server:/Users/shared/saxonb9-0-0-2j oracle$ cat -n sample2.xml
     1  <?xml version="1.0" encoding="utf-8"?>
     2  <space> </space>
G5Server:/Users/shared/saxonb9-0-0-2j oracle$ cat -n query2.xql
     1  fn:doc("sample2.xml")/space
G5Server:/Users/shared/saxonb9-0-0-2j oracle$ 
G5Server:/Users/Shared/saxonb9-0-0-2j oracle$ java -cp saxon9.jar net.sf.saxon.Query query2.xql
<?xml version="1.0" encoding="UTF-8"?>
<space> </space>
G5Server:/Users/Shared/saxonb9-0-0-2j oracle$ java -cp saxon9.jar net.sf.saxon.Query -strip:all query2.xql
<?xml version="1.0" encoding="UTF-8"?>
<space/>
G5Server:/Users/Shared/saxonb9-0-0-2j oracle$ java -cp saxon9.jar net.sf.saxon.Query -strip:none query2.xql
<?xml version="1.0" encoding="UTF-8"?>
<space> </space>
G5Server:/Users/Shared/saxonb9-0-0-2j oracle$ java -cp saxon9.jar net.sf.saxon.Query -strip:ignorable query2.xql
<?xml version="1.0" encoding="UTF-8"?>
<space> </space>

---

●　バックナンバー
Oracle de XMLDB #1
Oracle de XMLDB #2
Oracle de XMLDB #3 - Oracle10g XEではどうよ？
Oracle de XMLDB #4
Oracle de XMLDB #5 - Oracle11g環境再構築完了
Oracle de XMLDB #6 - Linux x86版再び。
Oracle de XMLDB #7 - 何かが違う！？
Oracle de XMLDB #8 - またまた少々脱線
Oracle de XMLDB #9 - またまた少々脱線の続き
Oracle de XMLDB #10 - 三度脱線
Oracle de XMLDB #11 - 三度脱線のおまけ
Oracle de XMLDB #12
Oracle de XMLDB #13
Oracle de XMLDB #14
Oracle de XMLDB #15
Oracle de XMLDB #16

---

太った空白

書こうか迷っていたのだが、意外とハマっている方が多いらしいので書いておく事にした。
まあ、エラーメッセージがわかりずらいのでしょうがないとは思うが。

PL/SQLで開発する際に出くわす事がある。
（私もたまにやっちゃいますけどハマることはないです。こればかりは慣れるしかないですね。）

ということで太った空白のお話。

PL/SQLではマルチバイト文字の空白（全角の空白と言ったほうがわかりやすいでしょうか？）が原因で意味不明のコンパイルエラーを引き起こす。
そう、”太った空白”と書いたのはマルチバイト文字の空白。半角の空白が２つあるように見えるが全角の空白が１文字。

まずは、以下の例を見てください。

Last login: Fri Dec 21 08:25:31 on console
Welcome to Darwin!
G5Server:˜ discus$ su - oracle
Password:
G5Server:˜ oracle$ ssh oracle@corydoras
oracle@corydoras's password: 
Last login: Sun Dec 16 18:02:52 2007 from 192.168.1.19
[oracle@corydoras ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on 金 12月 21 19:50:10 2007

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

> conn scott/tiger
接続されました。
SCOTT> create or replace function now
  2  return timestamp
  3  is
  4  begin
  5  　return systimestamp;
  6  end;
  7  /

警告: ファンクションが作成されましたが、コンパイル・エラーがあります。

SCOTT> show errors
FUNCTION NOWのエラーです。

LINE/COL ERROR
-------- -----------------------------------------------------------------
5/3      PLS-00103: 記号""が見つかりました。 次のうちの1つが入るとき:
         ( begin case declare exit for goto if loop mod null pragma
         raise return select update while with <an identifier>
         <a double-quoted delimited-identifier> <a bind variable> <<
         continue close current delete fetch lock insert open rollback
         savepoint set sql execute commit forall merge pipe purge
         記号"" は無視されました。

上記では、now()というストアドファンクションを作成しようとして５行目の３カラム目でコンパイルエラーが発生している。
（ストアドファンクション自体は意味の無いものなので気にしないでね。コンパイルエラーに注目してください。）

５行目の３カラム目は、"r"だなと思ったあなたは、もうすでにハマっていますよ。

実は、５行目の先頭の空白は半角の空白２文字ではなく”全角の空白１文字”なんです。

もうお分かりですよね。では、全角空白１文字を半角空白２文字に置換して再実行してみましょう。

SCOTT> list 5
  5* 　return systimestamp;
SCOTT> c /　return/  return
  5*   return systimestamp;
SCOTT> l
  1  create or replace function now
  2  return timestamp
  3  is
  4  begin
  5    return systimestamp;
  6* end;
SCOTT> /

ファンクションが作成されました。

SCOTT> select now() from dual;

NOW()
---------------------------------------------------------------------------
07-12-21 19:56:19.046993000

SCOTT> /

Oracle de XMLDB #16

Oracle de XMLDB #13でも書いたxquery宣言のencodingがサポートされていないということも含めてOracle11g R1の以下マニュアルに記載されているので要確認。（備忘録）

Oracle® XML DB Developer's Guide 11g Release 1 (11.1) - Oracle XML DB Support for XQuery

前述のマニュアルにも記載されているが、boundary-spaceは未サポートとか。とりあえず試してみる。

Last login: Sun Dec 16 14:15:06 on console
Welcome to Darwin!
G5Server:˜ discus$ su - oracle
Password:
G5Server:˜ oracle$ ssh oracle@corydoras
oracle@corydoras's password: 
Last login: Sat Dec 15 19:59:13 2007 from 192.168.1.19
[oracle@corydoras ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on 日 12月 16 18:03:04 2007

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

> conn scott/tiger
接続されました。
SCOTT> set sqlterm off
SCOTT> set long 4000
SCOTT> set pagesize 1000
SCOTT> xquery
  2  declare boundary-space preserve;
  3  <result>
  4  {
  5    for $i in fn:doc("/public/scott/xml/addresslist.xml")//電話番号
  6    return
  7      <greeting> { fn:concat("Hello, ", $i/text())
  8    }      </greeting>
  9* }     </result>
 10  /
ERROR:
ORA-19107: 無効なXQueryX - 構成がサポートされていません - boundary-space preserve declaration

SCOTT> edit
file afiedt.bufが書き込まれました。

  1  xquery
  2  declare boundary-space strip;
  3  <result>
  4  {
  5    for $i in fn:doc("/public/scott/xml/addresslist.xml")//電話番号
  6    return
  7      <greeting> { fn:concat("Hello, ", $i/text())
  8    }      </greeting>
  9* }     </result>
SCOTT> /

Result Sequence
--------------------------------------------------------------------------------
<result><greeting>Hello, 03-1234-5555</greeting><greeting>Hello, 090-4321-7878</
greeting><greeting>Hello, 070-7777-8798</greeting><greeting>Hello, 06-1234-5555<
/greeting><greeting>Hello, 06-6860-0001</greeting><greeting>Hello, 090-6666-7878
</greeting><greeting>Hello, 080-9999-8798</greeting><greeting>Hello, 06-6860-000
1</greeting><greeting>Hello, 090-0066-0108</greeting><greeting>Hello, 090-3020-2
897</greeting></result>


SCOTT> 

Oracle11g R1 11.6.0.1.0のXQueryでは、boundary-space preserveが未サポートということでboundary-space stripで処理しているということなんだね。

---

●　バックナンバー
Oracle de XMLDB #1
Oracle de XMLDB #2
Oracle de XMLDB #3 - Oracle10g XEではどうよ？
Oracle de XMLDB #4
Oracle de XMLDB #5 - Oracle11g環境再構築完了
Oracle de XMLDB #6 - Linux x86版再び。
Oracle de XMLDB #7 - 何かが違う！？
Oracle de XMLDB #8 - またまた少々脱線
Oracle de XMLDB #9 - またまた少々脱線の続き
Oracle de XMLDB #10 - 三度脱線
Oracle de XMLDB #11 - 三度脱線のおまけ
Oracle de XMLDB #12
Oracle de XMLDB #13
Oracle de XMLDB #14
Oracle de XMLDB #15

---

Oracle de XMLDB #15

さて、まだ脱線は続きます。（いつ戻るんだ〜〜！）

Oracle de XMLDB #13でXqueryのencodingが指定できないと書いたが、どうしても文字コードを変えたい場合はどうするんだろうか？

思い出したのがOracle de XMLDB #7 - 何かが違うでも書いたクライアント側のNLS_LANG環境変数で制御する方法。

---

●　バックナンバー
Oracle de XMLDB #1
Oracle de XMLDB #2
Oracle de XMLDB #3 - Oracle10g XEではどうよ？
Oracle de XMLDB #4
Oracle de XMLDB #5 - Oracle11g環境再構築完了
Oracle de XMLDB #6 - Linux x86版再び。
Oracle de XMLDB #7 - 何かが違う！？
Oracle de XMLDB #8 - またまた少々脱線
Oracle de XMLDB #9 - またまた少々脱線の続き
Oracle de XMLDB #10 - 三度脱線
Oracle de XMLDB #11 - 三度脱線のおまけ
Oracle de XMLDB #12
Oracle de XMLDB #13
Oracle de XMLDB #14

---

●このテスト環境の文字エンコーディングの概略図
NLS_LANG環境変数を変換したい文字コードへ変更すればうまく変換できるはず・・・・

●　まずは全てUTF-8で統一させている場合の例から。

MacOSXのterminalの文字エンコーディングもUTF-8にすることをお忘れなく。

> conn scott/tiger
接続されました。
SCOTT> !echo $NLS_LANG
japanese_japan.AL32UTF8

SCOTT> set sqlterm off
SCOTT> set pagesize 1000
SCOTT> set long 4000
SCOTT> 
SCOTT> select
  2    xmlquery(
  3      'xquery version "1.0";
  4       <result>
  5       {
  6         for $i in fn:doc("/public/scott/xml/addresslist.xml")//電話番号
  7         return $i
  8       }
  9       </result>'
 10       returning content
 11    )
 12  from
 13*   dual
SCOTT> /

XMLQUERY('XQUERYVERSION"1.0";<RESULT>{FOR$IINFN:DOC("/PUBLIC/SCOTT/XML/ADDRESSLI
--------------------------------------------------------------------------------
<result><電話番号 区分="自宅">03-1234-5555</電話番号>
<電話番号 区分="携帯">090-4321-7878</電話番号>
<電話番号 区分="携帯">070-7777-8798</電話番号>
<電話番号 区分="自宅">06-1234-5555</電話番号>
<電話番号 区分="会社">06-6860-0001</電話番号>
<電話番号 区分="携帯">090-6666-7878</電話番号>
<電話番号 区分="携帯">080-9999-8798</電話番号>
<電話番号 区分="会社">06-6860-0001</電話番号>
<電話番号 区分="携帯">090-0066-0108</電話番号>
<電話番号 区分="携帯">090-3020-2897</電話番号>
</result>

SCOTT> exit

●　クライアント側のNLS_LANG=japanese_japan.JA16SJISTILDE、MacOSXのTerminalの文字エンコーディングもShift_JISへ変更して実行する。

[oracle@corydoras ˜]$ export NLS_LANG=japanese_japan.JA16SJISTILDE
[oracle@corydoras ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on 金 12月 14 23:10:29 2007

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

> conn scott/tiger
接続されました。

SCOTT> !echo $NLS_LANG
japanese_japan.JA16SJISTILDE

SCOTT> set sqlterm off
SCOTT> set pagesize 1000
SCOTT> set long 4000
SCOTT> 
SCOTT> select
  2    xmlquery(
  3      'xquery version "1.0";
  4       <result>
  5       {
  6         for $i in fn:doc("/public/scott/xml/addresslist.xml")//電話番号
  7         return $i
  8       }
  9       </result>'
 10       returning content
 11    )
 12  from
 13*   dual
SCOTT> /

XMLQUERY('XQUERYVERSION"1.0";<RESULT>{FOR$IINFN:DOC("/PUBLIC/SCOTT/XML/ADDRESSLI
--------------------------------------------------------------------------------
<result><電話番号 区分="自宅">03-1234-5555</電話番号>
<電話番号 区分="携帯">090-4321-7878</電話番号>
<電話番号 区分="携帯">070-7777-8798</電話番号>
<電話番号 区分="自宅">06-1234-5555</電話番号>
<電話番号 区分="会社">06-6860-0001</電話番号>
<電話番号 区分="携帯">090-6666-7878</電話番号>
<電話番号 区分="携帯">080-9999-8798</電話番号>
<電話番号 区分="会社">06-6860-0001</電話番号>
<電話番号 区分="携帯">090-0066-0108</電話番号>
<電話番号 区分="携帯">090-3020-2897</電話番号>
</result>

これではなんとなく分かりずらいですね。ということで結果をHTMLへスプールして確認してみましょう。

SCOTT> set markup html on spool on
SCOTT> set echo off
<br>
SCOTT> spool result.html
<br>
SCOTT> /
<br>

・・・・・中略・・・・・

SCOTT> spo off
<br>
SCOTT> set markup html off
<br>
SCOTT> set echo on
SCOTT> !cat result.html

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=SHIFT_JIS">
<meta name="generator" content="SQL*Plus 11.1.0">
<style type="text/css">
body {font:10pt Arial,Helvetica,sans-serif;
color:black; background:White;}
p {font:10pt Arial,Helvetica,sans-serif;
color:black; background:White;}
table,tr,td {font:10pt Arial,Helvetica,sans-serif;
color:Black; background:#f7f7e7;
padding:0px 0px 0px 0px; margin:0px 0px 0px 0px;}
th {font:bold 10pt Arial,Helvetica,sans-serif;
color:#336699; background:#cccc99; padding:0px 0px 0px 0px;}
h1 {font:16pt Arial,Helvetica,Geneva,sans-serif;
color:#336699; background-color:White;
border-bottom:1px solid #cccc99;
margin-top:0pt; margin-bottom:0pt;
padding:0px 0px 0px 0px;}
h2 {font:bold 10pt Arial,Helvetica,Geneva,sans-serif;
color:#336699; background-color:White;
margin-top:4pt; margin-bottom:0pt;}
a {font:9pt Arial,Helvetica,sans-serif;
color:#663300; background:#ffffff;
margin-top:0pt; margin-bottom:0pt; vertical-align:top;}
</style>
<title>
SQL*Plus レポート
</title>
</head>
<body>
SCOTT> /
<br>
<p>
<table border="1" width="90%" summary="Script output">
<tr>
<th scope="col">
XMLQUERY('XQUERYVERSION"1.0";<RESULT>{FOR$IINFN:DOC("/PUBLIC/SCOTT/XML/ADDRESSLI
</th>
</tr>
<tr>
<td>
<result><電話番号 区分="自宅">03-1234-5555</電話番号>
<電話番号 区分="携帯">090-
4321-7878</電話番号>
<電話番号 区分="携帯">070-7777-8798</電話番号>
<電話番号 区
分="自宅">06-1234-5555</電話番号>
<電話番号 区分="会社">06-6860-0001</電話番号>

<電話番号 区分="携帯">090-6666-7878</電話番号>
<電話番号 区分="携帯">080-9999-87
98</電話番号>
<電話番号 区分="会社">06-6860-0001</電話番号>
<電話番号 区分="携帯
">090-0066-0108</電話番号>
<電話番号 区分="携帯">090-3020-2897</電話番号>
</resu
lt>
</td>
</tr>
</table>
<p>

SCOTT> spo off
<br>
</body>
</html>

SCOTT> 

SQL*PlusでHTMLとして結果をSPOOLするコマンドがありますが、その機能を利用して文字エンコーディングがShift_JISになっているか確認しています。（太字で赤色で強調してある部分）
うまくShift_JISへ変換できているようです。
（NLS_LANG環境変数で制御するしかないのはかなりトリッキーではあるけれど・・・）

Oracle de XMLDB #14

またXMLマスタープロフェッショナル（DB）試験ネタからは少々脱線している・・・。と気付きつつも、気になるとやらずに居られない性分なので。

---

●　バックナンバー

Oracle de XMLDB #1

Oracle de XMLDB #2

Oracle de XMLDB #3 - Oracle10g XEではどうよ？

Oracle de XMLDB #4

Oracle de XMLDB #5 - Oracle11g環境再構築完了

Oracle de XMLDB #6 - Linux x86版再び。

Oracle de XMLDB #7 - 何かが違う！？

Oracle de XMLDB #8 - またまた少々脱線

Oracle de XMLDB #9 - またまた少々脱線の続き

Oracle de XMLDB #10 - 三度脱線

Oracle de XMLDB #11 - 三度脱線のおまけ

Oracle de XMLDB #12

Oracle de XMLDB #13

---

前々回にも書いたがSQL*Plusでは、";"を入力してしまうとそれまで入力したSQL文を実行してくれる。

ただ、SQL文や、XQueryコマンドの実行には問題ないのだが、SQL/XMLでは少々困った問題を引き起こすんです。

以下の例をご覧ください。

> conn scott/tiger
接続されました。
SCOTT> 
SCOTT> 
SCOTT> select
  2    xmlquery(
  3      'xquery version "1.0";
ERROR:
ORA-01756: 引用符付き文字列が正しく終了していません

そうなんです！。
xmlquery()関数内あっても　";"（セミコロン）を入力する必要があるのですが、入力した時点で実行しようとしてしまうんです。(><)

これには困りました！。

無理矢理な対処として、エラーになっても気にせず前述のように入力後、SQL*Plusのeditコマンドで編集する方法もありますが、今回はマニュアル Oracle® XML DB Developer's Guide 11g Release 1 (11.1)　-　Using Namespaces with XQueryにも書かれている方法でやってみましょう。

●　";"（セミコロン）の後にXQeuryのコメントを付加する方法

SCOTT> 
SCOTT> select
  2    xmlquery(
  3      'xquery version "1.0"; (::)
  4       declare namespace mo = "http://192.168.1.20/my_namespace"; (::)
  5       declare function mo:phoneNumber($phone)
  6       {
  7         $phone/text()
  8       }; (::)
  9       (: query body :)
 10       <result>
 11       {
 12         for $i in fn:doc("/public/scott/xml/addresslist.xml")//電話番号
 13         return
 14           <greeting>
 15             { fn:concat("Hello, ", mo:phoneNumber($i)) }
 16           </greeting>
 17       }
 18       </result>'
 19       returning content
 20    )
 21  from
 22    dual
 23  .
SCOTT> /

XMLQUERY('XQUERYVERSION"1.0";(::)DECLARENAMESPACEMO="HTTP://192.168.1.20/MY_NAME
--------------------------------------------------------------------------------
<result><greeting>Hello, 03-1234-5555</greeting><greeting>Hello, 090-4321-7878</
greeting><greeting>Hello, 070-7777-8798</greeting><greeting>Hello, 06-1234-5555<
/greeting><greeting>Hello, 06-6860-0001</greeting><greeting>Hello, 090-6666-7878
</greeting><greeting>Hello, 080-9999-8798</greeting><greeting>Hello, 06-6860-000
1</greeting><greeting>Hello, 090-0066-0108</greeting><greeting>Hello, 090-3020-2
897</greeting></result>


SCOTT> 

●　次は、";"（セミコロン）を無視させる方法。

SCOTT> set sqlterm off
SCOTT> select
  2    xmlquery(
  3      'xquery version "1.0";
  4       declare namespace mo = "http://192.168.1.20/my_namespace";
  5       declare function mo:phoneNumber($phone)
  6       {
  7          $phone/text()
  8       };
  9       (: query body :)
 10       <result>
 11       {
 12         for $i in fn:doc("/public/scott/xml/addresslist.xml")//電話番号
 13         return
 14           <greeting>
 15             { fn:concat("Hello, ", mo:phoneNumber($i)) }
 16           </greeting>
 17       }
 18       </result>'
 19       returning content
 20    )
 21  from
 22    dual
 23  .
SCOTT> /

XMLQUERY('XQUERYVERSION"1.0";DECLARENAMESPACEMO="HTTP://192.168.1.20/MY_NAMESPAC
--------------------------------------------------------------------------------
<result><greeting>Hello, 03-1234-5555</greeting><greeting>Hello, 090-4321-7878</
greeting><greeting>Hello, 070-7777-8798</greeting><greeting>Hello, 06-1234-5555<
/greeting><greeting>Hello, 06-6860-0001</greeting><greeting>Hello, 090-6666-7878
</greeting><greeting>Hello, 080-9999-8798</greeting><greeting>Hello, 06-6860-000
1</greeting><greeting>Hello, 090-0066-0108</greeting><greeting>Hello, 090-3020-2
897</greeting></result>


SCOTT> 

SQL/XMLやXQueryを実行する場合には、SET SQLTERMINATOR OFFを使って　";"を無視させた方が便利で簡単ですね。

Oracle de XMLDB #13

●　バックナンバー
Oracle de XMLDB #1
Oracle de XMLDB #2
Oracle de XMLDB #3 - Oracle10g XEではどうよ？
Oracle de XMLDB #4
Oracle de XMLDB #5 - Oracle11g環境再構築完了
Oracle de XMLDB #6 - Linux x86版再び。
Oracle de XMLDB #7 - 何かが違う！？
Oracle de XMLDB #8 - またまた少々脱線
Oracle de XMLDB #9 - またまた少々脱線の続き
Oracle de XMLDB #10 - 三度脱線
Oracle de XMLDB #11 - 三度脱線のおまけ
Oracle de XMLDB #12

---

さて、前回SQL*PlusのXQueryコマンドのXQuery宣言ではversion及びencodingが指定できなかったり、先頭行にコメントが書けなかったがSQL/XMLのxmlquery()関数内ではどうなのか確認しておく。
環境はいつものとおり、Oracle11g EE R1 11.1.0.6.0 for Linux x86へMacOSXのTerminalからssh接続して行った。

Last login: Thu Dec 13 07:54:08 on console
Welcome to Darwin!
G5Server:˜ discus$ su - oracle
Password:
G5Server:˜ oracle$ ssh oracle@corydoras
oracle@corydoras's password: 
Last login: Wed Dec 12 21:21:43 2007 from 192.168.1.19
[oracle@corydoras ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on 木 12月 13 17:03:36 2007

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

> conn scott/tiger
接続されました。
SCOTT> l
  1  select
  2    xmlquery(
  3      'xquery version "1.0" encoding "utf-8";
  4       declare namespace mo = "http://192.168.1.20/my_namespace";
  5       declare function mo:phoneNumber($phone)
  6       {
  7         $phone/text()
  8       };
  9     (: Query body :)
 10     <result>
 11     {
 12       for $i in fn:doc("/public/scott/xml/addresslist.xml")//電話番号
 13       return
 14        <greeting>
 15          { fn:concat("Hello, ", mo:phoneNumber($i)) }
 16        </greeting>
 17     }
 18     </result>'
 19     returning content
 20   )
 21  from
 22   dual
SCOTT> /
 dual
 *
行22でエラーが発生しました。:
ORA-19284: バージョン宣言におけるエンコーディング指定はサポートされていません

xmlquery()関数では、SQL*PlusのXQueryコマンドとは異なりencodingは指定できないがversionだけは指定できるようだ。

SCOTT> edit
file afiedt.bufが書き込まれました。

  1  select
  2    xmlquery(
  3      'xquery version "1.0";
  4       declare namespace mo = "http://192.168.1.20/my_namespace";
  5       declare function mo:phoneNumber($phone)
  6       {
  7         $phone/text()
  8       };
  9     (: Query body :)
 10     <result>
 11     {
 12       for $i in fn:doc("/public/scott/xml/addresslist.xml")//電話番号
 13       return
 14        <greeting>
 15          { fn:concat("Hello, ", mo:phoneNumber($i)) }
 16        </greeting>
 17     }
 18     </result>'
 19     returning content
 20   )
 21  from
 22*  dual
SCOTT> /

XMLQUERY('XQUERYVERSION"1.0";DECLARENAMESPACEMO="HTTP://192.168.1.20/MY_NAMESPAC
--------------------------------------------------------------------------------
<result><greeting>Hello, 03-1234-5555</greeting><greeting>Hello, 090-4321-7878</
greeting><greeting>Hello, 070-7777-8798</greeting><greeting>Hello, 06-1234-5555<
/greeting><greeting>Hello, 06-6860-0001</greeting><greeting>Hello, 090-6666-7878
</greeting><greeting>Hello, 080-9999-8798</greeting><greeting>Hello, 06-6860-000
1</greeting><greeting>Hello, 090-0066-0108</greeting><greeting>Hello, 090-3020-2
897</greeting></result>


SCOTT> 

ではSQL*PlusのXQueryコマンドでは先頭行がコメントである場合、XQueryとは解釈されずSQL文として解釈されてしまっていたがxmlquery()関数ではそのような書き方でも問題はない。
SQL*PlusのXQueryコマンドは、XQuery宣言ではなく、SQL*PlusのXQueryコマンドだということを忘れないようにしたい。（混乱しそうだが。。。。）

SCOTT> edit
file afiedt.bufが書き込まれました。

  1  select
  2    xmlquery(
  3      '(: コメントを先頭に :)
  4       xquery version "1.0";
  5       declare namespace mo = "http://192.168.1.20/my_namespace";
  6       declare function mo:phoneNumber($phone)
  7       {
  8         $phone/text()
  9       };
 10     (: Query body :)
 11     <result>
 12     {
 13       for $i in fn:doc("/public/scott/xml/addresslist.xml")//電話番号
 14       return
 15        <greeting>
 16          { fn:concat("Hello, ", mo:phoneNumber($i)) }
 17        </greeting>
 18     }
 19     </result>'
 20     returning content
 21   )
 22  from
 23*  dual
SCOTT> /

XMLQUERY('(:コメントを先頭に:)XQUERYVERSION"1.0";DECLARENAMESPACEMO="HTTP://192.
--------------------------------------------------------------------------------
<result><greeting>Hello, 03-1234-5555</greeting><greeting>Hello, 090-4321-7878</
greeting><greeting>Hello, 070-7777-8798</greeting><greeting>Hello, 06-1234-5555<
/greeting><greeting>Hello, 06-6860-0001</greeting><greeting>Hello, 090-6666-7878
</greeting><greeting>Hello, 080-9999-8798</greeting><greeting>Hello, 06-6860-000
1</greeting><greeting>Hello, 090-0066-0108</greeting><greeting>Hello, 090-3020-2
897</greeting></result>


SCOTT> 

Oracle de XMLDB #12

●　バックナンバー
Oracle de XMLDB #1
Oracle de XMLDB #2
Oracle de XMLDB #3 - Oracle10g XEではどうよ？
Oracle de XMLDB #4
Oracle de XMLDB #5 - Oracle11g環境再構築完了
Oracle de XMLDB #6 - Linux x86版再び。
Oracle de XMLDB #7 - 何かが違う！？
Oracle de XMLDB #8 - またまた少々脱線
Oracle de XMLDB #9 - またまた少々脱線の続き
Oracle de XMLDB #10 - 三度脱線
Oracle de XMLDB #11 - 三度脱線のおまけ

---

DB Magazineに連載されていたXMLマスター実践講座　プロフェッショナル（DB）試験対応　第２回　XQueryの概要にあるLIST1:サンプルのXqueryとほぼ同じクエリをOracle11g R1(Linux x86)のSQL*Plusで試してみる。

Last login: Wed Dec 12 22:18:10 on ttyp1
Welcome to Darwin!
G5Server:˜ discus$ su - oracle
Password:
G5Server:˜ oracle$ 
G5Server:˜ oracle$ ssh oracle@corydoras
oracle@corydoras's password: 
Last login: Wed Dec 12 23:03:58 2007 from 192.168.1.19
[oracle@corydoras ˜]$ 
[oracle@corydoras ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on 水 12月 12 23:04:46 2007

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

●まず、addresslist.xmlファイルをOracle XDBリポジトリへ事前に登録しておく。
簡単なXQueryで問い合わせ内容を確認しておきましょう。

> conn scott/tiger
接続されました。
SCOTT> 
SCOTT> set long 4000
SCOTT> l
  1  xquery
  2  for $i in fn:doc("/public/scott/xml/addresslist.xml")
  3  return $i
SCOTT> /

Result Sequence
--------------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?><アドレスブック><連絡先><氏名><姓>赤坂</姓
><名>元</名></氏名><住所/><メール><アドレス 区分="プライベート">G.Akasaka@coldma
il.jp</アドレス><アドレス 区分="携帯">G.Akasaka@hardbank.ne.jp</アドレス><アドレ
ス 区分="携帯">G.Akasaka@dokodemo.ne.jp</アドレス></メール><電話><電話番号 区分=
"自宅">03-1234-5555</電話番号><電話番号 区分="携帯">090-4321-7878</電話番号><電
話番号 区分="携帯">070-7777-8798</電話番号></電話></連絡先><連絡先><氏名><姓>麻
布</姓><名>太郎</名></氏名><住所/><メール><アドレス 区分="会社">T.Azabu@taro.co.
jp</アドレス><アドレス 区分="プライベート">T.Azabu@coolmail.jp</アドレス><アドレ
ス 区分="携帯">T.Azabu@a_phone.ne.jp</アドレス><アドレス 区分="携帯">T.Azabu@bu.
ne.jp</アドレス></メール><電話><電話番号 区分="自宅">06-1234-5555</電話番号><電
話番号 区分="会社">06-6860-0001</電話番号><電話番号 区分="携帯">090-6666-7878</
電話番号><電話番号 区分="携帯">080-9999-8798</電話番号></電話></連絡先><連絡先><
氏名><姓>代々木</姓><名>武</名></氏名><住所/><メール><アドレス 区分="プライベー
ト">Y.Takeshi@ba-net.ne.jp</アドレス><アドレス 区分="携帯">Y.Takeshi@dokodemo.ne
.jp</アドレス><アドレス 区分="携帯">Y.Takeshi@bu.ne.jp</アドレス></メール><電話>
<電話番号 区分="会社">06-6860-0001</電話番号><電話番号 区分="携帯">090-0066-0108
</電話番号><電話番号 区分="携帯">090-3020-2897</電話番号></電話></連絡先></アド
レスブック>

●　本来なら問題ない構文から試してみると。。。

SCOTT> (: サンプル :)
  2  xquery version "1.0" encoding "utf-8";
(: サンプル :)
 *
行1でエラーが発生しました。:
ORA-00928: SELECTキーワードがありません。

あ〜〜〜、XQueryのコメントとして解釈されているのかと思ったが、SQL*PlusではXQueryのコメントから始めることはできないようだ。

NOTE 1)
SQL*PlusでXQueryを利用する場合、XQueryのコメント文から入力してしまうと通常のSQL文と判断してしてしまうので要注意！

NOTE 2)
SQL*Plusでは、";"は文を実行するという意味があるのでXQueryのPrologで入力してしまうとそこまで入力したXQueryを解析、実行してしまうので要注意！

SQL*PLusでXqueryを入力する際のちょっとしたテクニックとして、一旦前述のように入力後SQL*Plusのeditコマンドでviなどを起動し編集すればこの問題は回避できる。以下はeditコマンドを利用してviで入力した。

SCOTT> edit
file afiedt.bufが書き込まれました。

  1  (: サンプル :)
  2  xquery version "1.0" encoding "utf-8";
  3  declare namespace mo = "http://192.168.1.20/my_namespace";
  4  declare function mo:phoneNumber($phone)
  5  {
  6    $phone/text()
  7  };
  8  (: Query Body :)
  9  <result>
 10    {
 11      for $i in fn:doc("/public/scott/xml/addresslist.xml")//電話番号
 12      return
 13        <greeting>
 14          { fn:concat( "Hello, ", mo:phoneNumber($i)) }
 15        </greeting>
 16    }
 17* </result>
 18  /
SP2-0552: バインド変数"CONCAT"が宣言されていません。

やはり、XQueryのコメント(::)から開始するとSQL文だと判断されてしまうようだ。

XQueryコマンドの前にあるXQueryのコメントを削除する。XQueryとしては正しいのだが、SQL*Plusでは別のエラーが発生する。
以下のエラーメッセージから version "1.0" の部分が文法エラーとされてしまっている。恐らくencodeingも文法エラー扱いになるだろう。

SCOTT> edit
file afiedt.bufが書き込まれました。

  1  xquery version "1.0" encoding "utf-8";
  2  declare namespace mo = "http://192.168.1.20/my_namespace";
  3  declare function mo:phoneNumber($phone)
  4  {
  5    $phone/text()
  6  };
  7  (: Query Body :)
  8  <result>
  9    {
 10      for $i in fn:doc("/public/scott/xml/addresslist.xml")//電話番号
 11      return
 12        <greeting>
 13          { fn:concat( "Hello, ",mo:phoneNumber($i)) }
 14        </greeting>
 15    }
 16* </result>
SCOTT> /
ERROR:
ORA-19114: XPST0003 - XQuery式を解析中にエラーが発生しました:  LPX-00801:
XQuery syntax error at '"1.0"'
1   version "1.0" encoding "utf-8";
-          ^

ということで、versionとencodingを削除してみると、わ〜〜、パチパチ。上手くできました。
XQueryの文法では正しくてもSQL*PlusやOracle11gの実装により文法エラーとされてしまうケースもあるので、Oracle11gでXMLマスタープロフェッショナル（DB）の勉強をする際には要注意。

SCOTT> edit
file afiedt.bufが書き込まれました。

  1  xquery
  2  declare namespace mo = "http://192.168.1.20/my_namespace";
  3  declare function mo:phoneNumber($phone)
  4  {
  5    $phone/text()
  6  };
  7  (: Query Body :)
  8  <result>
  9    {
 10      for $i in fn:doc("/public/scott/xml/addresslist.xml")//電話番号
 11      return
 12        <greeting>
 13          {　fn:concat("Hello, ",mo:phoneNumber($i))　}
 14        </greeting>
 15    }
 16* </result>
SCOTT> /

Result Sequence
--------------------------------------------------------------------------------
<result><greeting>Hello, 03-1234-5555</greeting><greeting>Hello, 090-4321-7878</
greeting><greeting>Hello, 070-7777-8798</greeting><greeting>Hello, 06-1234-5555<
/greeting><greeting>Hello, 06-6860-0001</greeting><greeting>Hello, 090-6666-7878
</greeting><greeting>Hello, 080-9999-8798</greeting><greeting>Hello, 06-6860-000
1</greeting><greeting>Hello, 090-0066-0108</greeting><greeting>Hello, 090-3020-2
897</greeting></result>

---

話はがらりと変わり、昨日はAngelique Kidjoライブご招待へ当選したので、ウチのおチビちゃんのお守りは奥さんに任せてdrmarさんをとブルーノート東京へ（久々だな〜）

曲目全ては覚えていないのだが、

Gimme Shelterをはじめ (アルバムでは、Joss Stone
をフィーチャーしている）アルバム　Djin Djinからの曲。私もdrmarさん同様、全く知らなかったアーティストなのだが、グラミー賞には過去５回ノミネートされたことがある実力派。西アフリカはペナン共和国出身。その影響だろうか、日本はもう冬なのだが、曲は太陽を感じるような曲が多い。

アルバム Djin Djinでは、ビーター・ガブリエル、カルロス・サンタナ、ジョス・ストーンなど多彩なゲストをフィーチャーしている。

YouTube - Gimme Shelter(Feat. Joss Stone)
YouTube - Africa Calling
YouTube - Voodoo Child
YouTube - Tumba

投稿日時 2007年12月13日 (木) 02時03分 Oracle, Mac, XML, Linux, Oracle Database 11g | 固定リンク | 0 | コメント (0) | トラックバック (0)

2007年12月 7日 (金)

Oracle de XMLDB #11 - 三度脱線のおまけ

三度脱線したついでに・・・・

HTTPURITYPE型のUser-Agentはどうなっているのだろうか？　　

そう思ったらやった方がはやいですね！！　　

ということで、我が家のMac OS X server Leopard 10 Client版で普段は眠っているApacheを起動、Mac De OracleのAtomを配置して試してみた。

192.168.1.19 - - [07/Dec/2007:00:43:46 +0900] "GET /feed/mac_de_oracle_atom.xml HTTP/1.1" 200 13811 "-" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3"
192.168.1.19 - - [07/Dec/2007:00:54:57 +0900] "GET /feed/mac_de_oracle_atom.xml HTTP/1.1" 304 - "-" "AppleSyndication/54"
192.168.1.20 - - [07/Dec/2007:01:05:25 +0900] "GET /feed/mac_de_oracle_atom.xml HTTP/1.1" 200 14644 "-" "-"

見ての通り、最後のログがOracleのHTTPURITYPE型でアクセスした場合のログなのだが、User-Agentは設定されていない！

三度脱線したついでに・・・・

HTTPURITYPE型のUser-Agentはどうなっているのだろうか？　　

そう思ったらやった方がはやいですね！！　　

ということで、我が家のMac OS X server Leopard 10 Client版で普段は眠っているApacheを起動、Mac De OracleのAtomを配置して試してみた。

Oracle de XMLDB #11 - 三度脱線のおまけ

三度脱線したついでに・・・・

HTTPURITYPE型のUser-Agentはどうなっているのだろうか？　　

そう思ったらやった方がはやいですね！！　　

ということで、我が家のMac OS X server Leopard 10 Client版で普段は眠っているApacheを起動、Mac De OracleのAtomを配置して試してみた。

Oracle de XMLDB #10 - 三度脱線

XMLマスタープロフェッショナル（データベース）の開始も間近だし、「XMLマスター：プロフェッショナル（データベース）」再受験無料プログラム」もあるので試験勉強を中心にと思いつつ、気になることがあると試したくなる性分なので、三たび脱線。
SQL/XMLのCOLUMNS句も確認しておこうかなと。。いうことで。。。

まずACLの確認。（今回は、OTN-JフォーラムのFEEDを材料にしてみた。。）

もしACLが作成されていない、又は、接続先ホストが割り当てられていない場合はdbms_network_acl_adminパッケージで定義／割当してくださいませ。

SYS> select acl,host from dba_network_acls;

ACL                                      HOST
---------------------------------------- --------------------------------------------------
/sys/acls/feeds.xml                      otn.oracle.co.jp

SYS> select principal,acl,privilege,is_grant from dba_network_acl_privileges
  2  where principal='SCOTT';

PRINCIPAL  ACL                                      PRIVILE IS_GRANT
---------- ---------------------------------------- ------- --------------------
SCOTT      /sys/acls/feeds.xml                      connect true
SCOTT      /sys/acls/feeds.xml                      resolve true

SYS> 
SYS> conn scott/tiger
接続されました。
SCOTT> l
  1  select *
  2  from
  3    xmltable(
  4      xmlnamespaces('http://www.jivesoftware.com/xmlns/jiveforums/rss' as "jf"),
  5      'for $i in /rss/channel/item
  6       return
  7         <rss>{$i/title}{$i/jf:creationDate}{$i/jf:author}{$i/jf:replyCount}{$i/link}</rss>'
  8      passing httpuritype('http://otn.oracle.co.jp/forum/rss/rssmessages.jspa?categoryID=2').getXML()
  9      columns
 10        title varchar2(100) path '/rss/title',
 11        pubDate varchar2(30) path '/rss/jf:creationDate',
 12        author varchar2(50) path '/rss/jf:author',
 13        replyCount integer path '/rss/jf:replyCount',
 14        link varchar2(200) path '/rss/link'
 15    )
 16  where
 17    title like '%日付のインクリメント%'
 18  order by
 19*   substr(pubdate,instr(pubdate,','))
SCOTT> /

TITLE                                    PUBDATE                        AUTHOR               REPLYCOUNT LINK
---------------------------------------- ------------------------------ -------------------- ---------- ------------------------------------------------------------------------------------------
日付のインクリメント                     火, 27 11 2007 18:02:44 +0900  tahakoda                      2 http://otn.oracle.co.jp/forum/thread.jspa?messageID=35020441&tstart=0#35020441
Re: 日付のインクリメント                 火, 27 11 2007 20:35:31 +0900  茶太郎                        0 http://otn.oracle.co.jp/forum/thread.jspa?messageID=35020443&tstart=0#35020443
Re: 日付のインクリメント                 水, 28 11 2007 06:44:47 +0900  discus                        0 http://otn.oracle.co.jp/forum/thread.jspa?messageID=35020450&tstart=0#35020450

SCOTT> 

尚、HTTPURITYPE型でマルチバイトを含むXML文書を参照する場合はXML文書の文字エンコーディングと同じデータベースキャラクタセットでないと文字化け？の影響と思われるXMLパースエラーが発生するので要注意。

前々回のエントリにも追記したのだが・・・・

XML文書の文字エンコーディングとデータベースキャラクタセットが異なる場合は、

Mac De PL/SQL RSS Reader #3

のようにUTL_HTTPパッケージを利用して対処することもできるのでどうしても文字エンコーディングが異なる環境で行うなら自作でユーザ定義型を作るしか無さそう。。。。

いまのところXMLDBなどを利用して各種Webサービスと連携するのならデータベースキャラクタセットはAL32UTF8にしておくのがいちばんよさそうだ。（オラクルさんも新規データベースはAL32UTF8を推奨しているし。。）

Oracle de XMLDB #9 - またまた少々脱線の続き

子持ちのDiscusとなって初投稿。なにげに左の画像も変えてみたり。。。　:)

Discusという魚、ディスカスミルクで子供を育てるんですよ！

discusは一夫一婦制で子育ては両親協力して行うんです。
孵化後数日し幼魚が親のまわりを泳ぎ始めると
親discusの体からは栄養のある分泌物が出し始めます。
それがディスカスミルク！

ディスカスミルクを飲むために親の体に群がる子discusたち。ほんとにかわいいです。

前置きはこれくらいにして、本題へ。

前回はHttpUriType型やその型を利用している（と思われる）DBMS_PARSER.PARSE(parser,uri)ファンクションでは参照するXML文書の文字エンコーディングとデータベースキャラクタセットが異なる場合、文字化けの影響でパースエラーが発生するというということだった。(Oracle10g R1/R2それにOracle11g R1でも）

その最後で。「・・・略・・・。上記のコードをそのまま実行しようとするとエラーになる。」と書いていたのだが、覚えているだろうか？

そのエラーは以下のような場合でも発生する。

以下、ウチの奥さんのブログのFEED(ATOM version=0.3)を利用して試してみた。（Oracle11g以降では以下のようにセキュリティが強化されている。）

Last login: Thu Nov 22 21:58:23 on ttyp1
Welcome to Darwin!
G5Server:˜ oracle$ 
G5Server:˜ oracle$ ssh oracle@corydoras
oracle@corydoras's password: 
Last login: Thu Nov 22 22:39:56 2007 from 192.168.1.19
[oracle@corydoras ˜]$ 
[oracle@corydoras ˜]$ 
[oracle@corydoras ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on 木 11月 22 22:46:51 2007

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

SCOTT> l
  1  SELECT *
  2  FROM
  3    XmlTable(
  4      'for $i in //*
  5       return $i'
  6      PASSING HttpUriType('http://atsu-log.way-nifty.com/today_s_menu/atom.xml').getXML()
  7* )
SCOTT> /
    PASSING HttpUriType('http://atsu-log.way-nifty.com/today_s_menu/atom.xml').getXML()
                                                                                     *
行6でエラーが発生しました。:
ORA-29273: HTTPリクエストに失敗しました ORA-06512:
"SYS.UTL_HTTP", 行1674
ORA-24247: アクセス制御リスト(ACL)によりネットワーク・アクセスが拒否されました ORA-06512: "SYS.HTTPURITYPE",
行34
ORA-06512: "SYS.HTTPURITYPE", 行97

詳しくはマニュアルを読んでもらうとして、HttpUriType型でネットワークアクセスを許可してみる。

マニュアル（英語）
Managing Fine-Grained Access to External Network Services
Using DBMS_NETWORK_ACL_ADMIN

●　まず、現状確認

DBA_NETWORK_ACLSビューとDBA_NETWORK_ACL_PRIVILEGESビューという２つのディクショナリビューで確認する。
以下の結果からも分かるように、外部ネットワークへのアクセスを許可するACLなど一切定義されていない。

SYS> select acl,host from dba_network_acls;

レコードが選択されませんでした。

SYS> select principal,acl,privilege,is_grant from dba_network_acl_privileges where principal = 'SCOTT';

レコードが選択されませんでした。

SYS> 

●　ACLを作成し、参照先ホストや必要な権限を付与する。

Managing Fine-Grained Access Control to External Network Services from the Databaseに書かれているように、ACLを作成後connect及び、resolve権限をSCOTTユーザへ付与し、そのACLに対してアクセス先のホストを割り当てる。

注）コミットをお忘れなく！

SYS> BEGIN
  2    DBMS_NETWORK_ACL_ADMIN.CREATE_ACL(
  3      acl=> 'feeds.xml',
  4      description=>'acl for any feeds',
  5      principal=> 'SCOTT',
  6      is_grant=> true,
  7      privilege=> 'connect'
  8    );
  9    DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(
 10      acl=> 'feeds.xml',
 11      principal=>'SCOTT',
 12      is_grant=>true,
 13      privilege=>'resolve'
 14    );
 15    DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL(
 16      acl=>'feeds.xml',
 17      host=> 'atsu-log.way-nifty.com'
 18    );
 19    COMMIT;
 20  END;
 21  /

PL/SQLプロシージャが正常に完了しました。

SYS> select acl,host from dba_network_acls;

ACL                                      HOST
---------------------------------------- --------------------------------------------------
/sys/acls/feeds.xml                      atsu-log.way-nifty.com

SYS> select principal,acl,privilege,is_grant from dba_network_acl_privileges
  2  where principal='SCOTT';

PRINCIPAL  ACL                                      PRIVILE IS_GRANT
---------- ---------------------------------------- ------- --------------------
SCOTT      /sys/acls/feeds.xml                      connect true
SCOTT      /sys/acls/feeds.xml                      resolve true

SYS> 

●　再度、試してみる。

お〜〜〜。上手く行きました。

NOTE:
Oracle10g R2でも同じことはできますがACLで保護されていないので前述の手順は無くても行えます。

SCOTT> l
  1  SELECT *
  2  FROM
  3    XmlTable(
  4      'for $i in //*
  5       return $i'
  6      PASSING HttpUriType('http://atsu-log.way-nifty.com/today_s_menu/atom.xml').getXML()
  7* )
SCOTT> /

COLUMN_VALUE
--------------------------------------------------------------------------------
<feed version="0.3" xmlns="http://purl.org/atom/ns#" xmlns:dc="http://purl.org/d
c/elements/1.1/"><title>今日のゴハン</title><link rel="alternate" type="text/htm
l" href="http://atsu-log.way-nifty.com/today_s_menu/"/><id>tag:app.cocolog-nifty
.com,2003:weblog-121882</id><link rel="service.post" type="application/x.atom+xm
l" href="http://app.cocolog-nifty.com/t/atom/weblog/blog_id=121882" title="今日
のゴハン"/><modified>2007-11-24T11:17:10Z&;t/modified><tagline>今日もごちそうさま
。（ぺこり）</tagline><generator url="http://www.typepad.com/" version="1.0">

・・・・・中略・・・・

<br xmlns="http://www.w3.org/1999/xhtml"/>
<p xmlns="http://www.w3.org/1999/xhtml">今日は夕方近くに散歩に出かけたら北風で手
が冷たくなったダーリン。<br/>
この麻婆豆腐のおかげで手も温かくなり、さらに汗だくになるくらいカプサイシン効果を
<br xmlns="http://www.w3.org/1999/xhtml"/>

197行が選択されました。

あ〜〜〜っ。長いのでちゃんと絞り込んでみましょう。

SCOTT> l
  1  SELECT *
  2  FROM
  3    XmlTable(
  4      'for $i in //entry/title
  5       return $i/text()'
  6      PASSING HttpUriType('http://atsu-log.way-nifty.com/today_s_menu/atom.xml').getXML()
  7* )
SCOTT> /

レコードが選択されませんでした。

これまた失礼。名前空間を指定し忘れたのでヒットしなかったようですね。
奥さんのブログのATOM FEEDは、version="0.3"で"1.0"のATOMとは名前空間が違う。。。ソースを確認して。。。

はい、できました〜〜。

SCOTT> l
  1  SELECT *
  2  FROM
  3    XmlTable(
  4      XmlNamespaces(
  5        'http://purl.org/dc/elements/1.1/' as "dc",
  6        default 'http://purl.org/atom/ns#'
  7      ),
  8      'for $i in //entry/title
  9       return $i/text()'
 10      PASSING HttpUriType('http://atsu-log.way-nifty.com/today_s_menu/atom.xml').getXML()
 11* )
SCOTT> /

COLUMN_VALUE
--------------------------------------------------------------------------------
酢豚
スイートポテト
白身魚のホイル焼き
ミネストローネ
一足お先に乾杯！
おいなりさん
ミルク寒天
そぼろご飯
産まれました♪
麻婆豆腐

10行が選択されました。

SCOTT> 

Oracle11g R1以降、Oracleデータベース内から外部のWebサービスを利用する際にはACLによる細かなアクセス制御が必要になるので忘れないようにしないと！ => 備忘録。

ということで２回連続で脱線してしまったが、次回からはまたOracle XML DBのXQueryを使っていろいろと試してみるか。

Oracle de XMLDB #8 - またまた少々脱線

久々にOracle11gのXML DBネタなのだが、XQueryなどのXMLマスタープロフェッショナル（データベース）絡みのネタからはまた脱線。SQL/XMLネタを一つ。

以前、Oracle10g R1/R2上でRSS FEEDをPL/SQLで取得してOracle Application Expressで表示なんてことをやっていた。
（３３回も連載してたっけ。。。。）
Mac De PL/SQL RSS Reader #1
Mac De PL/SQL RSS Reader #2

それらのエントリで、参照するXML文書の文字エンコーディングとデータベースキャラクタセットが異なると文字化けを起こしてしまうHttpUriType型の仕様？のことを書いていたのだが、先日リリースされたOracle11g R1ではどうなったのか？

確かめてみた！　

まずは、SQL/XMLを利用した例。（以下は、Oracle11g R1 for Linux x86を利用。）

XML文書の文字エンコーディングはUTF-8、Oracleデータベースのキャラクタセットは、JA16SJISTILDE。

SCOTT> r
  1  select *
  2  from
  3    xmltable(
  4      'for $i in //*
  5       return $i'
  6      passing httpuritype('https://discus-hamburg.cocolog-nifty.com/test/atom.xml').getXML()
  7*   )
    passing httpuritype('https://discus-hamburg.cocolog-nifty.com/test/atom.xml').getXML()
                                                                                                *
行6でエラーが発生しました。:
ORA-31011: XML解析に失敗しました
ORA-19202: XML処理
LPX-00244: 小なり不等号 ('<')文字の使用が無効です。 (&lt;を使用します)
Error at line 30
中にエラーが発生しました
ORA-06512: "SYS.XMLTYPE", 行5
ORA-06512: "SYS.HTTPURITYPE", 行97


SCOTT>

あ〜〜〜〜やっぱり、ダメね〜。上記はXML文書のパースエラーとして現れているのだが、その原因は文字化けなのである。

XML文書とOracleデータベースのキャラクタセットが異なる場合（前述の例では、UTF-8とSJIS）にはHttpUriType型を利用せず、UTL_HTTPパッケージを利用し、

UTL_HTTP.SET_HEADER(v_req, 'Content-Type', 'text/xml;charset=UTF-8');

のようにすることで文字化けせずにXML文書を取込むことができる。
尚、XML文書、データベースキャラクタセットが同一である場合（XML文書がUTF-8でデータベースキャラクタセットがAL32UTF8のような場合）には文字化けは発生しない。これは私個人の想像なのだが、HttpUriType型が裏でHTTP通信する際に利用する文字エンコーディングはデータベースキャラクタセットから導出しているのだと思われる。今のところHttpUriType型には文字エンコーディングは指定できないのでオラクルさんが方針を変えない限り文字化けの回避策は前述の２つしかないだろう。

2007/11/28追記
もしどうしてもXML文書の文字エンコーディングとデータベースキャラクタセットが異なる環境でHTTPURITYPE型を使いたいということであれば、代替策としてUTL_HTTPパッケージを利用したユーザ定義型を作成すれば可能かもしれない。
（あくまで推測。。あとで試してみるか＝＞TODO）

以前、DBMS_XMLPARSER.PARSE(parser, uri)を使ってFEEDを直接参照した場合も同様のエラーだったが、UTL_HTTPパッケージを利用して文字化けを回避した。
以下URL参照のこと。（下記のエントリの内容はOracle10g R1/R2で試したものです。）
Mac De PL/SQL RSS Reader #3

SQL/XML機能が充実してきたので今後はあまり使わなくなるかもしれないが、次いでなのでDBMS_XMLPARSER.PARSER(parser,uri)でも試してみた。
DBMS_XMLPARSER.PARSER(parser, uri)でもHttpUriType型を利用しているだろうから結果は同じはずだ。
(また、XMLマスタープロフェッショナル（データベース）ネタからは離れてく〜〜。w）

以前作成したコードを少々手直してOracle11gで実行！（Oracle SQL Developer for MacOSXを利用した）

● ソース

CREATE OR REPLACE PROCEDURE GET_FEED(i_url IN VARCHAR2)
AS
  v_url             VARCHAR2(32767);
  v_myParser        DBMS_XMLPARSER.Parser;
  v_rssDoc          DBMS_XMLDOM.DomDocument;
  v_xml             XMLTYPE;

  PROCEDURE println(str IN VARCHAR2)
  IS
  BEGIN 
    DBMS_OUTPUT.PUT_LINE(str);
  END;

  PROCEDURE println
  (
    i_text IN CLOB
  )
  IS
    v_tempStr     VARCHAR(32767);
    v_numOfPieces PLS_INTEGER;
  BEGIN
    v_numOfPieces := CEIL(LENGTH(i_text)/1000);
    FOR i IN 1..v_numOfPieces LOOP
      DBMS_OUTPUT.PUT_LINE(SUBSTR(i_text, ((i-1)*1000), 1000));
    END LOOP;
  EXCEPTION
    WHEN OTHERS THEN
      DBMS_OUTPUT.PUT_LINE(
        'println(CLOB) internal procedure:'
        || sqlerrm()
      );
      RAISE;
  END println;

--****************************************************************************
--* Main 
--****************************************************************************
BEGIN
  DBMS_OUTPUT.ENABLE(200000);
  println('begin...');


  v_url := i_url;
  IF v_url IS NULL THEN
    RAISE_APPLICATION_ERROR(-20000, 'URLを指定してください。');
  END IF;

  v_myParser := DBMS_XMLPARSER.NEWPARSER();
  DBMS_XMLPARSER.PARSE(v_myParser, v_url);
  v_rssDoc := DBMS_XMLPARSER.GETDOCUMENT(v_myParser);
  v_xml := DBMS_XMLDOM.GETXMLTYPE(v_rssDoc);
  println('DBMS_XMLPARSERバージョン：'||DBMS_XMLPARSER.GETRELEASEVERSION());
  println('DBMS_XMLDOMバージョン   ：'||DBMS_XMLDOM.GETVERSION(v_rssDoc));
  println(' ');
  println('=== パース済みDOMから取得したRSSソース ===');
  println(XmlType.GETCLOBVAL(v_xml));
  println('====================');
  println(' ');
  DBMS_XMLPARSER.FREEPARSER(v_myParser);

  println('...End');

EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE(
      'Main Procedure:'
      || sqlerrm()
    );
    RAISE;

END GET_FEED;

●　結果

RSS FEED(UTF-8)をデータベースキャラクタセット(JA16SJISTILDE)から取込んだ場合。

Connecting to the database Oracle11g R1 Scott(leaffish) - JA16SJISTILDE.
ORA-31011: XML解析に失敗しました
ORA-19202: XML処理
LPX-00244: 小なり不等号 ('<')文字の使用が無効です。 (&lt;を使用します)
Error at line 30
中にエラーが発生しました
ORA-06512: "SCOTT. GET_FEED", 行161
ORA-06512: 行6
begin...
Main Procedure:ORA-31011: XML解析に失敗しました
ORA-19202: XML処理
LPX-00244: 小なり不等号 ('<')文字の使用が無効です。 (&lt;を使用します)
Error at line 30
中にエラーが発生しました
Process exited.
Disconnecting from the database Oracle11g R1 Scott(leaffish) - JA16SJISTILDE.

RSS FEED(UTF-8)をデータベースキャラクタセット(AL32UTF8)から取込んだ場合。文字エンコーディングが同じ場合は問題なし！
ところで、Oracle11g R1でも、DBMS_XMLPARSERのパージョンは10.1.0.2.0なのね〜。(^^;;;

Connecting to the database Oracle11g R1 Scott(guppy) - AL32UTF8.
begin...
DBMS_XMLPARSERバージョン：10.1.0.2.0
DBMS_XMLDOMバージョン   ：1.0
 
=== パース済みDOMから取得したRSSソース ===
<?xml version="1.0" encoding="utf-8"?>

<feed xmlns="http://www.w3.org/2005/Atom">
    <title>Mac De Oracle</title>
    <link rel="alternate" type="text/html" href="https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/" />
    <link rel="service.post" type="application/x.atom+xml" href="http://app.cocolog-nifty.com/t/atom/weblog/blog_id=121907" title="Mac De Oracle" />
    <id>tag:app.cocolog-nifty.com,2003:weblog-121907</id>
    <updated>2007-11-19T09:16:39Z</updated>


・・・・中略・・・・


        <summary>前回、何かが違うと感じたと書いたがそれはなにか？　実はwhitespaceに関す...</summary>
        <author>
            <name>discus</name>
        </author>
        <category term="Linux" />
        <category term="Oracle" />
        <category term="Oracle Database 11g" />
        <category term="XML" />




    </entry>

</feed>
====================
 
...End
Process exited.
Disconnecting from the database Oracle11g R1 Scott(guppy) - AL32UTF8.

尚、Oracle11g R1ではセキュリティが強化されている。（Oracle10g R2以前のセキュリティレベルにもできるようだが。。）上記のコードをそのまま実行しようとするとエラーになる。

ということで、セキュリティ関連も含めて続きは次回ということで。

---

おまけ

以下の資料はSQL/XMLって何？　ってとこからスタートする方にはよいかも..。
オープンソースカンファレンス２００７　.DBの資料「XQuery、XPath 及び SQL / XML に関する標準化動向と今後の取組み状況」 (PDF)

以下のサイトにはSQL/XML関連の情報がいろいろ（英語です。）
SQLX.org

その他、OTN-Jなどにもあったかも。。。（未確認）

Oracle Database 11g 一気にリリース

Linux x86版、Windows(32b)版に遅れること約一ヶ月、他のプラットフォームリリースされ始めたようだ。

本日、US　OTNからダウンロードできるようになったOracle Database 11gは、

Linux x86-64、Windows(64bit)、Solaris(SPARC 64bit)、AIX(PowerPC 64bit)、HP-UX(Itanium)版

さて、MacOSX Leopard版はいつなのか？？？？

Oracle de XMLDB #7 - 何かが違う！？

前回、何かが違うと感じたと書いたがそれはなにか？　実はwhitespaceに関することだった。(OTN-Jへ投稿したものの、XMLの部屋の状況を見ているだけに、レスは付かないかもしれないな〜と思いつつも、ダメもとで、とりあえず尋ねてみた。)

---

バックナンバー:

Oracle de XMLDB #1

Oracle de XMLDB #2

Oracle de XMLDB #3 - Oracle10g XEではどうよ？

Oracle de XMLDB #4 - fizzbuzzから

Oracle de XMLDB #5 - Oracle11g環境再構築完了

Oracle de XMLDB #6 - Linux x86版再び。

---

前置きはこのくらいにして、
初めてこの違いに気付いたのはWindows環境で遊び始めたときだった。Windows環境ではデータベースキャラクタセットはAL32UTF8、SQL*Plusは当然ながらJA16SJISになっている。データベースキャラクタセットとClientのNLS_LANGが異なるとコード変換が発生して、XMLはUTF-8からSHIFT_JISへ変換されて帰ってくる。まあ、エンコードが違う程度なら驚かなかったと思うのだが、whitespace strip/preserveまで異なると、見た目が違うので、あれれ？？？？　と驚いてしまったわけなのですよ。
（Oracle10gでも似たような話はあったので理由は同じなのかもしれないですが・・）

注）OTN-Jのフォーラムへ投稿した内容は、以降に記載した内容を再編集したものです。

まずは、XMLファイルの登録。(windows/Linux環境とも全く同じことをやってます。）
●test1.xml

<?xml version="1.0" encoding="UTF-8"?>
<テスト>
        <内容>あいうえお</内容>
</テスト>

●test2.xml

<?xml version="1.0" encoding="UTF-8"?>
<test>
        <content>abcdefg</content>
</test>

●上記XMLファイルを以下のようにしてXMLリポジトリへ登録。

SCOTT> l
  1  declare
  2   r boolean;
  3  begin
  4   r := dbms_xdb.createresource(
  5          '/public/scott/xml/test1.xml',
  6          bfilename('SCOTT_XMLDIR','test1.xml'),
  7          nls_charset_id('AL32UTF8'));
  8   r := dbms_xdb.createresource(
  9          '/public/scott/xml/test2.xml',
 10          bfilename('SCOTT_XMLDIR','test2.xml'),
 11          nls_charset_id('AL32UTF8'));
 12* end;
SCOTT> /

PL/SQLプロシージャが正常に完了しました。

SCOTT> commit;

コミットが完了しました。

● Windows版Oracle11g(データベースキャラクタセット:AL32UTF8, NLS_LANG=japanese_japan.JA16SJIS)
文字エンコーディング以外は元のXMLファイルを再現している。

SCOTT> xquery
  2  let $d := fn:doc("/public/scott/xml/test1.xml")
  3  return $d
  4  /

Result Sequence
------------------------------------------------------------------------------

<?xml version="1.0" encoding="SHIFT_JIS"?>
<テスト>
  <内容>あいうえお</内容>
</テスト>


SCOTT> xquery
  2  let $d := fn:doc("/public/scott/xml/test2.xml")
  3  return $d
  4  /

Result Sequence
------------------------------------------------------------------------------

<?xml version="1.0" encoding="SHIFT_JIS"?>
<test>
  <content>abcdefg</content>
</test>

● Linux版Oracle11g（データベースキャラクタセット；AL32UTF8、NLS_LANG=japanese_japan.AL32UTF8)
文字エンコーディングは元のXMLファイルを再現しているが、whitespaceは取り除かれている。

SCOTT> l
  1  xquery
  2  let $d := fn:doc("/public/scott/xml/test1.xml")
  3* return $d
SCOTT> /

Result Sequence
--------------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?><テスト><内容>あいうえお</内容></テスト>

SCOTT> xquery
  2  let $d := fn:doc("/public/scott/xml/test2.xml")
  3  return $d
  4  /

Result Sequence
--------------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?><test><content>abcdefg</content></test>

SCOTT>

ということは、Linux環境であってもデータベースキャラクタセットとクライアントの文字エンコーディングが異なれば同じ結果になるのでは？？？

試してみた！

[oracle@corydoras ˜]$ export NLS_LANG=american_america.JA16SJISTILDE
[oracle@corydoras ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on Mon Oct 29 22:45:09 2007

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

> conn scott/tiger
Connected.
SCOTT> set long 4000
SCOTT> l
  1  xquery
  2  let $d := doc("/public/scott/xml/test2.xml")
  3* return $d
SCOTT> /

Result Sequence
--------------------------------------------------------------------------------
<?xml version="1.0" encoding="SHIFT_JIS"?>
<test>
  <content>abcdefg</content>
</test>

XMLマスタープロフェッショナル（データベース）取得へ向けて勉強しようと思っていたのだが、なんだか、どんどん別な方向へ行っている気がするのでこの辺で止めておこうかと。
（XMLのデータの再現性という点についてはちょうどいいネタでしたけどね。。）

ちなみに、XQueryの勉強用には、結果が確認しやすくなるのでデータベースキャラクタセットとNLS_LANGのエンコードは変えておいたほういいかもしれないですね。

ということで、Windows版Oracle11gは不要なので即削除ということに。うちではLinux環境の方が便利なのでね。。。（明日にはOTN Professional版のOracle11gが届きそうなのでまた入れ直すだろうけど。。）

※尚、OTN-Jでレスが付いたらこのエントリに追記する予定。

Oracle de XMLDB #6 - Linux x86版再び。

Windows版　Oracle Database 11g　R1でXMLDB環境を再構築し、再度XQueryで遊び始めたのだが。。。。Linux版のOracle11g のXMLDBとは何かが違う。。。。。・・・・・・・

---

バックナンバー:

Oracle de XMLDB #1

Oracle de XMLDB #2

Oracle de XMLDB #3 - Oracle10g XEではどうよ？

Oracle de XMLDB #4 - fizzbuzzから

Oracle de XMLDB #5 - Oracle11g環境再構築完了

---

本当はXMLDBで遊びたいだけなのだが、、何となく気持ち悪い・・・・・

となれば、以前から計画していたLinux環境復活を先に！　

ということで、以前はOracle9i R2 for Linux x86とOracle10g R1 for Linux x86環境として利用していたToshiba Dynabook SS SX/210LNLW RAM:768MB　- Turbolinux 8 Enterprise Server (United Linux 1.0)環境を潰し、CentOS5 + Oracle11g R1 for Linux x86環境として作り直して、その違いを確認してみようということに急遽決定！！！！

尚、Toshiba Dynabook SS SX/210LNLWは、FDもCD/DVDドライブも搭載していないのだが、FDブート可能なFDドライブさえあればLinuxのインストールは可能で、以前TurboLinux 8 Enterprise Serverをインストールした際もFDイメージからブートし、外付けCDドライブからインストールしたことがある。。。

今回はCentOS5をネットワークインストールし、その後Oracle11gをインストールしてみることにした。

Dynabook SS SX/210LNLWへ繋いだFDドライブはこれ。

尚、CentOS5にはFDイメージが無いということなので、CentOS3.8のFDイメージでブート。一旦、CentOS3.8をインストールしてからCentOS5をネットワークインストールでクリーンインストールするという方法を取った。

ありがたいことに、この方法を試してブログで公開されている方がいたので参考にさせてもらった。
（ありがとうございます。いろいろ調べる手間が省けて助かりました。）

●　FDはあるけどCD-ROMドライブの無いノートPCに最新版Linuxをインストール(CentOS3.8)
ただ、私がインストールした際、以下の赤字部分を変えた。（それ以外は、前述のブログに書かれている通りで行えた。）

grub.confの編集
# vi /boot/grub/grub.conf

以下の項目を追加。
title CentOS 5.0 Install
root (hd0,0)
kernel /boot/centos/vmlinuz ramdisk_size=8192
initrd /boot/centos/initrd.img

●　FDはあるけどCD-ROMドライブの無いノートPCに最新版Linuxをインストール２(CentOS5編）

では、Toshiba Dynabook SS SX/210LNLWでCentOS5が起動した画像を。

ここまでできたら、Oracle Database 11gをインストールすればいい。手順は以前のエントリを。
（尚、Oracle11gをインストールするためには最低１GBのメモリが推奨されているが、このDynabookに積めるメモリは最大７６８MBである為１２８０MBだが５１２MB一枚しかなかったので７６８MBと少なめ。OUIの物理メモリサイズに関する警告を無視することでインストールを行った。Swapが多くなりモタツキ感はあるもののOracle11gは無事にインストールできた。）

以下は、MacOSX TigerのxtermよりCentOS5(Dynabook SS SX/210)へssh接続して起動したOUIの画像。

ということで、次回は、　何かが違う。。。と思った点について確認してみるか。

Oracle de XMLDB #5 - Oracle11g環境再構築完了

前回まで使っていたCentOS5上に構築したOracle Database 11g R1 EEは、ThinkPad R52の下取りということになり、仕方ないのでメモリが１GBしかないDual AthronMP 2800+のWindows XP Professional SP2という環境にOracle11g環境を再構築した。(Linux環境へはいずれ戻る予定）
OUIの操作はLinux/Unix、いつ登場するのか不明だが？？MacOSXでも同じ。１点違うところは、root.shなどの実行が事くらいなので、ここで改めてWindows版のOracle Database 11gのインストールについて書くつもりはないのだけれど、その様子だけはQuickTimeムービーで公開しておくことにした。(^^。

バックナンバー:
Oracle de XMLDB #1
Oracle de XMLDB #2
Oracle de XMLDB #3 - Oracle10g XEではどうよ？
Oracle de XMLDB #4 - fizzbuzzから

---

WindowsへOracleをインストールするのだが、そこは、Mac De Oracleですから、素直にWindowsに向うことは無いということは予想できますよね！？

ということで、VNCを使ってもいいのだが、今回は、マイクロソフトから提供されているRemote Desktop Connection（以下、RDC)を利用することにした。（尚、RDCは、IntelMacには未対応のようなのでご注意ください。)

RDCの設定でポイントになる点を幾つか。
リモートデスクトップのサイズはご自分のディスプレイに合わせてくださいね。
　

パフォーマンスタブをクリックして、ドロップダウンメニュの「LAN(10Mbps以上）」を選択。（これより遅い環境でお使いの場合にはそれなりの設定にしてくださいね。）

もし、こんなエラーがでたら、Windowsのローカルセキュリティ設定を一時的に変更すればOK。

RDC経由でOUIを起動したところ。　:-)

---

（再生にはQuickTimeが必要です。）

約1.8MBでサウンドトラックなし。

次回は、XQuery再開予定。

Oracle Database 11g for Linux x86-64 and Windows

Oracle Database 11g R1のLinux x86-64とWindows版がUS OTNからダウンロード可能になった。

■[db] Oracle Database 11g R1、Windows版リリース - S/N Ratio より引用

手持ちのWindows PCでOracle Database 11gを試してみたい、という方など、Windows版を待っていた方も少なくないと思います。そんな方は、是非インストールを :-)

私の場合、Windows版を待っていたということは無いのだが、空いているのがWindows環境しか無くなってしまうので。。。。ダウンロード決定！　(^^/

CentOS 5に構築したOracle Database 11gは、ノートPCを下取り処分することが決定しているので、ウチにある唯一のWindows XP Professionalマシンへインストールすることにした。ディスクスペースに余裕があるのでなんとかなるでしょう。多分。

Mac de Oracleですから、Windows　でも　Apple製品を絡めるということで、ブラウザは、Safari 3 for Windows (^^;;;

ちなみに、マシンはもう随分古いが、　Dual AthronMP 2800+ RAM:1GB　+ Windows XP Professional SP2（メモリが少ないのが少々キツいね。どっかで調達できるか捜してみるか。。。無い可能性のほうが高いが。。。）

PS.
DynabookをTurbolinuxからCentOSに切り替えるタイミングでOracle11gのLinux環境を再構築する予定。

Oracle Summit 2007

奥さんの退院手続きの合間にOracle Summit 2007 in 東京へ行ってきた。

会場も赤坂という場所なので、参加し易かったのでしょうか、かなりの人が来ていました。
私は、A-1のセッションだけでしたけど。

参加者全員へのプレゼントということで、

を頂きました。　今興味のある、XMLDB関連なども解説されているようなのでいいタイミング。

ところで、赤坂見附の交差点で８年くらい前、私がOracle全般を支援していた会社の社員だった方に遭遇。地下道から階段を上がっていくと、なんか、ちらちらこちらを見ている方が、。。。私も、ん？！　なんか見覚えのある顔。
近寄っていくと、あちらも、あ！、やっぱり！　
今は、違う会社に移られたようですが、お元気そうで。　またお会できるといいですね。
（最近、こういった感じで出会う方とは、近いうちにまた合う事が多いのですよ。。　不思議です。）

Oracle de XMLDB #4

データベースマガジンでもXQuery1.0は"習うより慣れろ"なんて書いてあったので、使って覚えるのが一番いいだろうなということで前々回に環境を構築したのだが、予想外の展開で、なかなか思うように試す時間がとれない・・・、それでも何とか時間を作らなきゃね。ということでやっとその続き。　　

バックナンバー:
Oracle de XMLDB #1
Oracle de XMLDB #2
Oracle de XMLDB #3 - Oracle10g XEではどうよ？

---

最初はFizzBuzzからやってみた。（笑） さずがに、Hello Worldじゃつまらなかったので・・・・。

いつものように、Oracle Database 11g for Linux x86へMacOSXのTerminalからssh接続！

Last login: Sat Oct 20 02:18:51 on console
Welcome to Darwin!
G5Server:˜ discus$ su - oracle
Password:
G5Server:˜ oracle$ 
G5Server:˜ oracle$ ssh oracle@glasscatfish
oracle@glasscatfish's password: 
Last login: Sat Oct 20 02:19:12 2007 from 192.168.1.19
[oracle@glasscatfish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on 月 10月 20 14:13:23 2007

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

> conn scott/tiger@lampeye
接続されました。

SCOTT> 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 Linux: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production

SCOTT> set timi on
SCOTT> l
  1  xquery
  2  for $n in 1 to 100
  3  return
  4    if ($n mod 15 eq 0) then 'fizzbuzz'
  5    else if ($n mod 3 eq 0) then 'fizz'
  6    else if ($n mod 5 eq 0) then 'buzz'
  7*   else $n
SCOTT> /
1
2
fizz
4
buzz
fizz
7
8
fizz
・・・・中略・・・・
fizz
97
98
fizz
buzz

100アイテムが選択されました。

経過: 00:00:00.06
SCOTT> 

ついでなので、以前SQLでFizzBuzzしたものと処理時間を比較してみた。
お〜！、SQLでFizzBuzzしたほうが早いな〜！

SCOTT> with
  2    t as (
  3      select 1 from dual group by cube(1,1,1,1)
  4    )
  5  select
  6    case 0
  7      when mod(rownum,15) then 'fizzbuzz'
  8      when mod(rownum,3) then 'fizz'
  9      when mod(rownum,5) then 'buzz'
 10      else to_char(rownum)
 11    end as results
 12  from 
 13    t a cross join t b
 14  where
 15    rownum <= 100;
1
2
fizz
4
buzz
fizz
7
8
・・・・中略・・・・
fizz
97
98
fizz
buzz

100行が選択されました。

経過: 00:00:00.03
SCOTT> 

多分、どなたかXQueryでやっているんじゃないかな〜！？　ということでググってみたら、ありました、User's Forum For DB2 Japanに。。（^^;;;

いや〜〜〜、目から鱗ですね。User's Forum For DB2 Japanのスレッドにある下記コードは、面白い。（私のコードは読みやすいかもしれないが、ストレート過ぎるかもね。ちょいと捻ったほうが、XQueryのトリッキーな動きも見えてくるというもの。）
以下のコードは、XPath2.0/XQuery1.0では、xs:booleanじゃなくても真理値として扱われる値やシーケンスにフィルタ式を用いているなどなど参考になります。m(_ _)m
（ただ、xs:booleanじゃなくても真理値として扱われるという性質を多用しるぎると難読化傾向はあるかもしれないですね。）

SCOTT> l
  1  xquery
  2  for $n in 1 to 100
  3  return
  4    fn:concat(
  5      $n[($n mod 3 and $n mod 5)],
  6      'fizz'[fn:not($n mod 3)],
  7      'buzz'[fn:not($n mod 5)]
  8*   )
SCOTT> /
1
2
fizz
4
buzz
fizz
7
8
・・・・中略・・・・
97
98
fizz
buzz

100アイテムが選択されました。

経過: 00:00:00.06
SCOTT> 

XQueryの条件式を少々書き換えてみた。私が最初に書いたXQueryより条件式の部分が読みにくくなりますよね、やはり。（実行速度に影響がなければ、読みやすい方がいいな。。）

SCOTT> l
  1  xquery
  2  for $n in 1 to 100
  3  return
  4    if (fn:not($n mod 15)) then 'fizzbuzz'
  5    else if (fn:not($n mod 3)) then 'fizz'
  6    else if (fn:not($n mod 5)) then 'buzz'
  7*   else $n
SCOTT> /
1
2
fizz
4
buzz
fizz
7
8
・・・・中略・・・・
97
98
fizz
buzz

100アイテムが選択されました。

経過: 00:00:00.06
SCOTT>

やはりxs:booleanじゃなくても真理値として扱われるという性質は、間違いやすいところなのでもうちょっと突っ込んで理解しておく必要があるなぁ。いい加減に覚えているとハマりそうな予感。

2007/10/23 追記
Oracle10g R2でもできますよ。

DBMS_OUTPUT.PUT_LINE()/PUT()の出力制限

Oracle10g R2からDBMS_OUTPUT.PUT_LINE()/PUT()関数で出力できる１行最大サイズが、２５５バイトから３２７６７バイトへ拡張されたことはご存知だろうか？
PL/SQLでプログラミングしている方ならほとんどの方がお世話になったことがあると思うDBMS_OUTPUT.PUT_LINE()/PUT()関数。これらの関数は、Oracle7のころから、ず〜〜〜〜〜っと２５５バイトが最大サイズだった。
それが、Oracle10g R2になって、いきなり３２７６７バイト（このサイズは、VARCHAR2型のPL/SQL内での最大サイズに等しい）まで拡張された。（うれしいというか、便利にというか、楽にはなったかもしれない。）
だが、いままで工夫して利用してきているだけに、意外とそのまんまになっていたり、３２７６７バイトまで拡張されたということを知らない方も多いようなので、ネタとしてはあまり新しいとは思えないのだが取り上げておく事にした。

ということで、Oracle10g R1 10.1.0.4.0とOracle10g R2 10.2.0.1.0を利用して実際に違いを確認。

以下の無名PL/SQLブロックでは、　２５５バイト／２５６バイト／３２７６７バイト／３２７６８バイトの各文字列をDBMS_OUTPUT.PUT_LINE()関数で出力するコードである。
DBMS_OUTPUT.PUT_LINE()/PUT()関数の制限により、Oracle10g R2より前のリリースでは、２５６バイト以上の文字列を出力しようと場合／Oracle10g R2以降では３２７６８バイト以上の文字列を出力しようとするとエラーになる。

●　Oracle10g R2 10.2.0.1.0の例

３２７６８バイトの文字列を出力しようとした場合だけがエラーになっていることが確認できる。

SCOTT> 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 Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production

SCOTT> set serveroutput on size 100000
SCOTT> l
  1  declare
  2    str255 varchar2(255) := rpad('255',255,'*');
  3    str256 varchar2(256) := rpad('256',256,'*');
  4    str32767 varchar2(32767) := rpad('32767',32767,'*');
  5  begin
  6    dbms_output.put_line(str255);
  7    begin
  8      dbms_output.put_line(str256);
  9    exception
 10      when others then
 11        dbms_output.put_line(sqlerrm());
 12    end;
 13    dbms_output.put_line(str32767);
 14    begin
 15      dbms_output.put_line(str32767||'*');
 16    exception
 17      when others then
 18        dbms_output.put_line(sqlerrm());
 19    end;
 20* end;
SCOTT> /
255*****************************************************************************
********************************************************************************
********************************************************************************
***************
256*****************************************************************************
********************************************************************************
********************************************************************************
****************
32767***************************************************************************
********************************************************************************
・・・・・中略・・・・・
********************************************************************************
********************************************************************************
********************************************************************************
***********************************************
ORA-20000: ORU-10028: line length overflow, limit of 32767 bytes per line

PL/SQLプロシージャが正常に完了しました。

SCOTT> 

●　Oracle10g R1 10.1.0.4.0の例

２５６バイト以上の文字列を出力しようとした場合、全てがエラー。当然！

SCOTT> conn scott@fishtank
パスワードを入力してください: 
接続されました。
SCOTT> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.1.0.4.0 - Prod
PL/SQL Release 10.1.0.4.0 - Production
CORE    10.1.0.4.0      Production
TNS for Linux: Version 10.1.0.4.0 - Production
NLSRTL Version 10.1.0.4.0 - Production

SCOTT> set serveroutput on size 100000
SCOTT> l
  1  declare
  2    str255 varchar2(255) := rpad('255',255,'*');
  3    str256 varchar2(256) := rpad('256',256,'*');
  4    str32767 varchar2(32767) := rpad('32767',32767,'*');
  5  begin
  6    dbms_output.put_line(str255);
  7    begin
  8      dbms_output.put_line(str256);
  9    exception
 10      when others then
 11        dbms_output.put_line(sqlerrm());
 12    end;
 13    begin
 14      dbms_output.put_line(str32767);
 15    exception
 16      when others then
 17        dbms_output.put_line(sqlerrm());
 18    end;
 19    begin
 20      dbms_output.put_line(str32767||'*');
 21    exception
 22      when others then
 23        dbms_output.put_line(sqlerrm());
 24    end;
 25* end;
SCOTT> /
255*****************************************************************************
********************************************************************************
********************************************************************************
***************
ORA-20000: ORU-10028: line length overflow, limit of 255 chars per line
ORA-20000: ORU-10028: line length overflow, limit of 255 chars per line
ORA-20000: ORU-10028: line length overflow, limit of 255 chars per line

PL/SQLプロシージャが正常に完了しました。

SCOTT> 

以上で、Oracle10g R2以降でのDBMS_OUTPUT.PUT_LINE()/PUT()関数の拡張は確認できた。PL/SQL内では、３２７６７バイトがVARCHAR2型の最大サイズなので、３２７６７バイト以内の出力であればDBMS_OUTPUT.PUT_LINE()/PUT()関数１行で済むということはかなり便利だ。（３２７６８バイト以上の出力には今まで通りのコードが必要だが。。。）

ここまでやったついでに、以前紹介したPL/SQLの条件付きコンパイルを利用してOracle9i R2 9.2.0.6.0以降、Oracle10g R1 10.1.0.4.0以降、それに、Oracle10g R2及び、Oracle11g R1の各リリースでコード共有の例を１つ。

以下のサンプルコードは、最大３２７６７バイトまでの文字列を引数で受け取り、DBMS_OUTPUT.PUT_LINE()で表示するという単純なコードだ。

●　Oracle10g R1 10.1.0.4.0

PL/SQLの条件付きコンパイルは、Oracle10g R1ではデフォルトでは機能しない。隠しパラメータをTRUEに設定する必要がある。

SYS> show parameter _plsql_conditional

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
_plsql_conditional_compilation       boolean                TRUE
SYS> conn scott@fishtank
パスワードを入力してください: 
接続されました。
SCOTT> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.1.0.4.0 - Prod
PL/SQL Release 10.1.0.4.0 - Production
CORE    10.1.0.4.0      Production
TNS for Linux: Version 10.1.0.4.0 - Production
NLSRTL Version 10.1.0.4.0 - Production

SCOTT> set serveroutput on size 100000
SCOTT> l
  1  CREATE OR REPLACE PROCEDURE dbms_output_test
  2  (
  3    i_str IN VARCHAR2
  4  )
  5  IS
  6    v_str VARCHAR2(32767);
  7    $IF DBMS_DB_VERSION.VERSION <= 9
  8        OR (DBMS_DB_VERSION.VERSION = 10
  9            AND DBMS_DB_VERSION.RELEASE < 2)
 10    $THEN
 11      v_pices PLS_INTEGER;
 12      C_NumOfChars CONSTANT PLS_INTEGER := 85;
 13    $END
 14  BEGIN
 15    v_str := i_str;
 16    $IF DBMS_DB_VERSION.VERSION <= 9
 17        OR (DBMS_DB_VERSION.VERSION = 10
 18            AND DBMS_DB_VERSION.RELEASE < 2)
 19    $THEN
 20      v_pices := CEIL(LENGTHB(v_str)/C_NumOfChars);
 21      FOR i IN 1..v_pices LOOP
 22        DBMS_OUTPUT.PUT_LINE(SUBSTR(v_str,(i-1)*C_NumOfChars+1,C_NumOfChars));
 23      END LOOP;
 24    $ELSE
 25      DBMS_OUTPUT.PUT_LINE(v_str);
 26    $END
 27* END;
SCOTT> /

プロシージャが作成されました。

SCOTT> 

Oracle10g R1環境で条件付きコンパイル後のコードを確認！

SCOTT> exec dbms_preprocessor.print_post_processed_source('PROCEDURE','SCOTT','DBMS_OUTPUT_TEST');
PROCEDURE dbms_output_test
(
i_str IN VARCHAR2
)
IS
v_str VARCHAR2(32767);
v_pices PLS_INTEGER;
C_NumOfChars CONSTANT PLS_INTEGER := 85;
BEGIN
v_str := i_str;
v_pices := CEIL(LENGTHB(v_str)/C_NumOfChars);
FOR i IN 1..v_pices LOOP
DBMS_OUTPUT.PUT_LINE(SUBSTR(v_str,(i-1)*C_NumOfChars+1,C_NumOfChars));
END LOOP;
END;

PL/SQLプロシージャが正常に完了しました。

SCOTT> 
SCOTT> exec dbms_output_test(rpad('32767',32767,'*'));
32767********************************************************************************
*************************************************************************************
*************************************************************************************
・・・・・中略・・・・・
*************************************************************************************
*************************************************************************************
******************************************

PL/SQLプロシージャが正常に完了しました。

SCOTT> 

●　Oracle10g R2 10.2.0.1.0

Oracle10g R2ではPL/SQLの条件付きコンパイルは最初から有効になっている。

SCOTT> set serveroutput on size 100000
SCOTT> 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 Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production

SCOTT> l
  1  CREATE OR REPLACE PROCEDURE dbms_output_test
  2  (
  3    i_str IN VARCHAR2
  4  )
  5  IS
  6    v_str VARCHAR2(32767);
  7    $IF DBMS_DB_VERSION.VERSION <= 9
  8        OR (DBMS_DB_VERSION.VERSION = 10
  9            AND DBMS_DB_VERSION.RELEASE < 2)
 10    $THEN
 11      v_pices PLS_INTEGER;
 12      C_NumOfChars CONSTANT PLS_INTEGER := 85;
 13    $END
 14  BEGIN
 15    v_str := i_str;
 16    $IF DBMS_DB_VERSION.VERSION <= 9
 17        OR (DBMS_DB_VERSION.VERSION = 10
 18            AND DBMS_DB_VERSION.RELEASE < 2)
 19    $THEN
 20      v_pices := CEIL(LENGTHB(v_str)/C_NumOfChars);
 21      FOR i IN 1..v_pices LOOP
 22        DBMS_OUTPUT.PUT_LINE(SUBSTR(v_str,(i-1)*C_NumOfChars+1,C_NumOfChars));
 23      END LOOP;
 24    $ELSE
 25      DBMS_OUTPUT.PUT_LINE(v_str);
 26    $END
 27* END;
SCOTT> /

プロシージャが作成されました。

Oracle10g R2で条件コンパイル後のコードを確認！（コードがこんなにシンプルに！）

SCOTT> exec dbms_preprocessor.print_post_processed_source('PROCEDURE','SCOTT','DBMS_OUTPUT_TEST');
PROCEDURE dbms_output_test
(
i_str IN VARCHAR2
)
IS
v_str VARCHAR2(32767);
BEGIN
v_str := i_str;
DBMS_OUTPUT.PUT_LINE(v_str);
END;

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec dbms_output_test(rpad('32767',32767,'*'));
32767***************************************************************************
********************************************************************************
********************************************************************************
********************************************************************************
・・・・・中略・・・・・
********************************************************************************
********************************************************************************
***********************************************

PL/SQLプロシージャが正常に完了しました。

SCOTT> 

Oracle de XMLDB #3 - Oracle10g XEではどうよ？

OracleのXMLDBを試す簡単な環境は？　ということで、Oracle10g R2 Express Editionを試してみた。
だが・・・・・今のところ利用できないようだ。次のリリースに期待。

バックナンバー：
Oracle de XMLDB #1
Oracle de XMLDB #2

---

以下、前回、Oracle Database 11gを構築したPC(CentOS 5)に、Oracle10g R2 Express Edition for Linux x86を追加インストールして試した記録。
尚、Oracle10g EXへは、同環境へインストール済みOracle Database 11g R1のSQL*Plusから接続した。(MacOSXからssh接続しているため、その方が楽だったので・・・）

G5Server:˜ oracle$ ssh oracle@glasscatfish
oracle@glasscatfish's password: 
[oracle@glasscatfish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on 火 10月 16 0:04:43 2007

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

> conn sys@xe as sysdba 
パスワードを入力してください: 
接続されました。
SYS> 
SYS> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Product
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production

SYS> select comp_name,version,status from dba_registry;

COMP_NAME                                          VERSION                        STATUS
-------------------------------------------------- ------------------------------ ----------
Oracle Database Catalog Views                      10.2.0.1.0                     VALID
Oracle Database Packages and Types                 10.2.0.1.0                     VALID
Oracle Text                                        10.2.0.1.0                     VALID
Oracle XML Database                                10.2.0.1.0                     VALID

SYS> 
SYS> !   
   [oracle@glasscatfish ˜]$ ll
合計 8
drwxr-xr-x 2 oracle oinstall 4096 10月 14 15:32 Desktop
[oracle@glasscatfish ˜]$ pwd
/home/oracle
[oracle@glasscatfish ˜]$ mkdir scott_xmldir
[oracle@glasscatfish ˜]$ ll
合計 16
drwxr-xr-x 2 oracle oinstall 4096 10月 14 15:32 Desktop
drwxr-xr-x 2 oracle oinstall 4096 10月 14 15:44 scott_xmldir
[oracle@glasscatfish ˜]$ cd scott_xmldir
[oracle@glasscatfish scott_xmldir]$ cat list1.xml
<?xml version="1.0" encoding="UTF-8" ?>
<顧客名簿>
        <顧客 id="128">
                <住所>
                        <郵便番号>123-4567</郵便番号>
                        <都道府県>千葉県</都道府県>
                        <市町村名>浦安市</市町村名>
                        <町名番地>舞浜1-2-3</町名番地>
                </住所>
                <電話 タイプ="会社">03-1234-5678</電話>
                <電話 タイプ="自宅">03-5555-6666</電話>
                <電話 タイプ="携帯">090-1112-4444</電話>
                <ファックス>03-8888-7777</ファックス>
                <Eメール>hoge@macdeoracle.jp</Eメール> 
        </顧客>
       <顧客 id="256">
                <住所>
                        <郵便番号>155-5555</郵便番号>
                        <都道府県>東京都</都道府県>
                        <市町村名>世田谷区</市町村名>
                        <町名番地>用賀1-2-3</町名番地>
                </住所>
                <電話 タイプ="会社">03-7575-7575</電話>
                <電話 タイプ="自宅">03-8585-8585</電話>
                <電話 タイプ="携帯">090-9191-9191</電話>
                <ファックス>03-4141-4141</ファックス>
                <Eメール>hoge@discushamburg.jp</Eメール>
        </顧客>
       <顧客 id="512">
                <住所>
                        <郵便番号>345-4567</郵便番号>
                        <都道府県>大阪府</都道府県>
                        <市町村名>中央区</市町村名>
                        <町名番地>難波2-2-2</町名番地>
                </住所>
                <電話 タイプ="会社">06-1234-5678</電話>
                <電話 タイプ="自宅">06-5555-6666</電話>
                <電話 タイプ="携帯">090-0606-0606</電話>
                <ファックス>06-8888-7777</ファックス>
                <Eメール>hoge@lampeye.jp</Eメール> 
        </顧客>
</顧客名簿>
[oracle@glasscatfish scott_xmldir]$ exit
exit

SYS> 
SYS> create directory scott_xmldir as '/home/oracle/scott_xmldir';

ディレクトリが作成されました。

SYS> grant read on directory scott_xmldir to scott;

権限付与が成功しました。

SYS> grant write on directory scott_xmldir to scott;

権限付与が成功しました。

SYS>

SYS> 
SYS> 
SYS> conn scott@xe
パスワードを入力してください: 
接続されました。
SCOTT> 
SCOTT> declare
  2    isSuccess boolean;
  3  begin
  4    isSuccess := dbms_xdb.createfolder('/public/scott'); 
  5  end;
  6  /

PL/SQLプロシージャが正常に完了しました。

SCOTT> 
SCOTT> l
  1  declare
  2    r boolean;
  3  begin
  4    r := dbms_xdb.createresource(
  5           '/public/scott/list1.xml',
  6           bfilename('SCOTT_XMLDIR','list1.xml'),
  7           nls_charset_id('AL32UTF8'));
  8* end;
SCOTT> /

PL/SQLプロシージャが正常に完了しました。

SCOTT> 
SCOTT> xquery
  2  let $n := let("/public/scott/list1.xml")
  3  return $n
  4  /
ERROR:
ORA-19114: XQuery式を解析中にエラーが発生しました:   
ORA-06550:行1、列13:
PLS-00201: 識別子SYS.DBMS_XQUERYINTを宣言してください。 
ORA-06550:行1、列7:
PL/SQL: Statement ignored


SCOTT> 

この日本語のメッセージでググっても、おそらく Oracle10g R2 XE上のXMLDBに関するものはヒットしないだろうということで・・・・

SCOTT> xquery
  2  let $n := fn:doc("/public/scott/list1.xml")
  3  return $n
  4  /
ERROR:
ORA-19114: error during parsing the XQuery expression:
ORA-06550: line 1, column 13:
PLS-00201: identifier 'SYS.DBMS_XQUERYINT' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored

英語メッセージに切り替え、英語のメッセージを表示させてからググってみた。
すると、ありましたよ。US OTNに。

http://forums.oracle.com/forums/message.jspa?messageID=1280038#1280038

ということで、Express Editionでは今のところこの機能は動作しないようだ。
次のリリースに期待するしかなさそうですね。

---

ついに、奥さんがMacBook Pro 15inchを購入、本日届いた！　これで、このCentOS5+Oracle11gの環境も初期化して、初代のiMac G5どもども下取だな、そろそろ。
さてさて、LinuxのOracle11g環境を別に作らねば。。

Oracle de XMLDB #2

前回、Oracle XML repositoryへXMLを格納したが、PL/SQLなどのAPIから操作するほか、Enterprise Managerからrepositoryを管理することができる。通常はこちらから管理したほうが楽でしょうね。

バックナンバー：
Oracle de XMLDB #1

---

以下、CentOS 5に構築したOracle11g の Enerprise Manager Database ControlをSafariから操作している様子。

Oracle de XMLDB #1

前回のエントリでXML Master Professional Database認定試験向けのお勉強用環境をOracle10g/11g環境で作ろうかな。と書いたが早速作ってみた。

Oracle10g R2/Oracle11g R1をインストールすればXMLDBは標準でインストールされているので特に問題になることはないと思う。

ところで、Oracle10g R2からSQL*PlusからXQueryを直接実行できるようになっているのだが、ご存知だろうか？
この例では、Oracle XML RepositoryへXML文書を登録し、SQL*PlusからXQueryを直接発行する環境を作ってみる。

参考：
Oracle XML DB開発者ガイド 10gリリース2（10.2）- 20 Oracle XML DBリポジトリのデータへのアクセス
Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス 10g リリース2（10.2）- 120 DBMS_XDB

まず、今回利用した環境の情報から。
OSは、CentOS4.4(Final)　32bit　そう、今年始めに構築した、Oracle10g R2 の Linux RAC環境を利用した。 (Oracle11g R1 EEの環境もあるのだが手順は同じなので　Oracle10g R2で構築した例を載せておく。）

[oracle@discus1 ˜]$ uname -svr
Linux 2.6.9-42.EL #1 Sat Aug 12 09:17:58 CDT 2006
[oracle@discus1 ˜]$ cat /etc/redhat-release
CentOS release 4.4 (Final)
[oracle@discus1 ˜]$ srvctl status database -d orcl
インスタンスorcl1はノードdiscus1で実行中です。
インスタンスorcl2はノードdiscus2で実行中です。
[oracle@discus1 ˜]$ srvctl status nodeapps -n discus1
VIPはノードで実行中です: discus1
GSDはノードで実行中です: discus1
リスナーはノードで実行中です: discus1
ONSデーモンはノードで実行中です: discus1
[oracle@discus1 ˜]$ srvctl status nodeapps -n discus2
VIPはノードで実行中です: discus2
GSDはノードで実行中です: discus2
リスナーはノードで実行中です: discus2
ONSデーモンはノードで実行中です: discus2
[oracle@discus1 ˜]$ 


SYS> 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 Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production

SYS> 
SYS> select comp_name,version,status from dba_registry where comp_name like '%XML%';

COMP_NAME                                          VERSION                        STATUS
-------------------------------------------------- ------------------------------ ----------
Oracle XML Database                                10.2.0.1.0                     VALID

SYS> 

テストに利用するXMLファイル(list1.xml)を $ORACLE_HOME/scott_xmldir以下に作成

[oracle@discus1 scott_xmldir]$ ll
合計 4
-rw-r--r--  1 oracle dba 2078 10月 13 21:28 list1.xml
[oracle@discus1 scott_xmldir]$ pwd
/u01/app/oracle/scott_xmldir/
[oracle@discus1 scott_xmldir]$ cat list1.xml
<?xml version="1.0" encoding="UTF-8"?>
<顧客名簿>
        <顧客 id="128">
                <住所>
                        <郵便番号>123-4567</郵便番号>
                        <都道府県>千葉県</都道府県>
                        <市町村名>浦安市</市町村名>
                        <町名番地>舞浜1-2-3</町名番地>
                </住所>
                <電話 タイプ="会社">03-1234-5678</電話>
                <電話 タイプ="自宅">03-5555-6666</電話>
                <電話 タイプ="携帯">090-1112-4444</電話>
                <ファックス>03-8888-7777</ファックス>
                <Eメール>hoge@macdeoracle.jp</Eメール> 
        </顧客>
       <顧客 id="256">
                <住所>
                        <郵便番号>155-5555</郵便番号>
                        <都道府県>東京都</都道府県>
                        <市町村名>世田谷区</市町村名>
                        <町名番地>用賀1-2-3</町名番地>
                </住所>
                <電話 タイプ="会社">03-7575-7575</電話>
                <電話 タイプ="自宅">03-8585-8585</電話>
                <電話 タイプ="携帯">090-9191-9191</電話>
                <ファックス>03-4141-4141</ファックス>
                <Eメール>hoge@discushamburg.jp</Eメール> 
        </顧客>
       <顧客 id="512">
                <住所>
                        <郵便番号>345-4567</郵便番号>
                        <都道府県>大阪府</都道府県>
                        <市町村名>中央区</市町村名>
                        <町名番地>難波2-2-2</町名番地>
                </住所>
                <電話 タイプ="会社">06-1234-5678</電話>
                <電話 タイプ="自宅">06-5555-6666</電話>
                <電話 タイプ="携帯">090-0606-0606</電話>
                <ファックス>06-8888-7777</ファックス>
                <Eメール>hoge@lampeye.jp</Eメール> 
        </顧客>
</顧客名簿>
[oracle@discus1 scott_xmldir]$ 

$ORACLE_HOME/scott_xmldirをdirectoryオブジェクトとして作成。今の所読み込みだけで十分だが、書き込み権限も付与しておく。

SYS> create directory scott_xmldir as '/u01/app/oracle/scott_xmldir/';

ディレクトリが作成されました。

SYS> grant read on directory scott_xmldir to scott;

権限付与が成功しました。

SYS> grant write on directory scott_xmldir to scott;

権限付与が成功しました。

SYS> 

SYS> 

この例では、XMLファイルをOracle XML repositoryへ登録する。/publicフォルダ以下に scott/xmlフォルダを追加作成後、/public/scott/xml以下へ対象のXMLファイルを登録する。
尚、データベースキャラクタセットは、AL32UTF8であり、登録するXMLファイルのエンコーディングは、UTF-8とした。

まず、/publicフォルダ以下に、scottフォルダを作成する。

SYS> conn scott@orcltest
パスワードを入力してください: 
接続されました。

SCOTT> declare
  2    r boolean;
  3  begin
  4    r := dbms_xdb.createfolder('/public/scott');
  5  end;
  6  /

PL/SQLプロシージャが正常に完了しました。

次に、/public/scottフォルダ以下に、xmlフォルダを作成する。
SCOTT> l
  1  declare
  2    r boolean;
  3  begin
  4    r := dbms_xdb.createfolder('/public/scott/xml');
  5* end;
SCOTT> /

PL/SQLプロシージャが正常に完了しました。

/public/scott/xmlフォルダ直下へSCOTT_XMLDIRディレクトリオブジェクト以下にあるxmlファイル(list1.xml)を登録し、パスを/public/scott/xml/list1.xmlとする。
SCOTT> l
  1  declare
  2    r boolean;
  3  begin
  4    r := dbms_xdb.createresource(
  5           '/public/scott/xml/list1.xml',
  6           bfilename('SCOTT_XMLDIR','list1.xml'),
  7           nls_charset_id('AL32UTF8'));
  8* end;
SCOTT> /

PL/SQLプロシージャが正常に完了しました。

SCOTT> 
SCOTT> 

最後に、確認の意味を含めて、XML repositoryへ登録したxmlをXQueryを利用して、SQL*Plusから直接問い合わせてみる。

SCOTT> set long 4000
SCOTT> l
  1  xquery
  2    let $d := fn:doc("/public/scott/xml/list1.xml")
  3*   return $d
SCOTT> /

Result Sequence
--------------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?><顧客名簿><顧客 id="128"><住所><郵便番号>123-4567</郵便番号><都道府県>千葉県</都道府県><市町村
名>浦安市</市町村名><町名番地>舞浜1-2-3</町名番地></住所><電話 タイプ="会社">03-1234-5678</電話><電話 タイプ="自宅">03-5555-6666</電
話><電話 タイプ="携帯">090-1112-4444</電話><ファックス>03-8888-7777</ファックス><Eメール>hoge@macdeoracle.jp</Eメール></顧客><顧客 i
d="256"><住所><郵便番号>155-5555</郵便番号><都道府県>東京都</都道府県><市町村名>世田谷区</市町村名><町名番地>用賀1-2-3</町名番地></
住所><電話 タイプ="会社">03-7575-7575</電話><電話 タイプ="自宅">03-8585-8585</電話><電話 タイプ="携帯">090-9191-9191</電話><ファック
ス>03-4141-4141</ファックス><Eメール>hoge@discushamburg.jp</Eメール></顧客><顧客 id="512"><住所><郵便番号>345-4567</郵便番号><都道府
県>大阪府</都道府県><市町村名>中央区</市町村名><町名番地>難波2-2-2</町名番地></住所><電話 タイプ="会社">06-1234-5678</電話><電話 タ
イプ="自宅">06-5555-6666</電話><電話 タイプ="携帯">090-0606-0606</電話><ファックス>06-8888-7777</ファックス><Eメール>hoge@lampeye.jp
</Eメール></顧客></顧客名簿>



SCOTT> 

ここまでできれば、XQuery1.0の実行は、SQL*Plusからダイレクトに行えるようになる。　簡単！。

あとは、いろいろなXQueryを試すのみ！ Enjoy!

DBMS_COMPARISONパッケージ で表データの比較 #6

「DBMS_COMPARISONパッケージで表データの比較」のつづき。

マニュアルは、DBMS_COMPARISONを利用するための前提が記載されているいるので、前提を満たしていないとどんなエラーになるか試してみた。

バックナンバー：
DBMS_COMPARISONパッケージ で表データの比較 #1
DBMS_COMPARISONパッケージ で表データの比較 #2
DBMS_COMPARISONパッケージ で表データの比較 #3
DBMS_COMPARISONパッケージ で表データの比較 #4
DBMS_COMPARISONパッケージ で表データの比較 #5

---

●　もしも、２つの表に前提を満たす主キー制約が無かったら。。。。。

SCOTT> alter table emp2 drop constraint emp2_pk;

表が変更されました。

SCOTT> create table emp3 as select * from emp2;

表が作成されました。

SCOTT> begin
  2    dbms_comparison.create_comparison(
  3      comparison_name => '索引の無い表の比較',
  4      schema_name => 'SCOTT',
  5      object_name => 'EMP2',
  6      dblink_name => null,
  7      remote_schema_name => 'SCOTT',
  8      remote_object_name => 'EMP3'
  9    );
 10  end;
 11  /
begin
*
行1でエラーが発生しました。:
ORA-23626: 適格な索引が表SCOTT.EMP2にありません 
ORA-06512:　"SYS.DBMS_COMPARISON", 行4197
ORA-06512: "SYS.DBMS_COMPARISON", 行420
ORA-06512: 行2

ちなみに、ローカル表には主キー制約があり、リモート表（実際にリモートデータベーベースにある表、マテリアライズドビューである必要はない）に主キー制約が存在しない場合は、DBMS_COMPARISONパッケージは可能だった。
ただしその場合、データを比較する際リモート表が全表走査されることになるだろう（実際にトレース取ったわけではないが・・）から、主キー制約、または一意制約はあったほうがよいだろう。（この点には注意が必要だが、主キーベースのレプリケーション環境では影響はないかと。。）

---

そういえば、XML Master Professional Databaseが今年の１２月から開始予定とのことなので、そろそろ、XML絡みのネタを増やしていこうか・・・、Oracle9i/10g さらに11gとXML DBとしての機能も強化してきたOracleなのでOracleを使ってXML Master Professional Databaseの受験対策環境作っておくのもいいなぁ・・・準備しておくか・・・

DBMS_COMPARISONパッケージ で表データの比較 #5

「DBMS_COMPARISONパッケージで表データの比較」の続きです。

表の内容を比較すると比較結果がどんどん記録されていく。不要になった比較結果は削除しときましょ。

バックナンバー：
DBMS_COMPARISONパッケージ で表データの比較 #1
DBMS_COMPARISONパッケージ で表データの比較 #2
DBMS_COMPARISONパッケージ で表データの比較 #3
DBMS_COMPARISONパッケージ で表データの比較 #4

---

purge_comparison()とdrop_comparison()、関数名だけだと何を削除するのか分かりにくいな〜。ということでこれらの関数の確認も。。

●　比較結果をpurge_comparison()関数でパージする。

DBMS_COMPARISON.COMPARE()関数を実行すると、比較結果の詳細やサマリーなどが記録される。
不要になった結果はpurge_comparison()関数で、後始末。

SCOTT> select scan_id,comparison_name from user_comparison_scan order by scan_id;

   SCAN_ID COMPARISON_NAME
---------- ------------------------------
         1 EMP表の比較
         2 EMP表の比較
         3 EMP表の比較
         4 EMP表の比較
         5 EMP表の比較
         6 EMP表の比較
         7 EMP表の比較

7行が選択されました。

SCOTT> select scan_id,comparison_name from user_comparison_scan_summary order by scan_id;

   SCAN_ID COMPARISON_NAME
---------- ------------------------------
         1 EMP表の比較
         2 EMP表の比較
         3 EMP表の比較
         4 EMP表の比較
         5 EMP表の比較
         6 EMP表の比較
         7 EMP表の比較

7行が選択されました。

SCOTT> select scan_id,comparison_name from user_comparison_scan_values order by scan_id;

   SCAN_ID COMPARISON_NAME
---------- ------------------------------
         1 EMP表の比較
         2 EMP表の比較
         3 EMP表の比較
         4 EMP表の比較
         5 EMP表の比較
         6 EMP表の比較
         7 EMP表の比較

7行が選択されました。


SCOTT> select scan_id,comparison_name from user_comparison_row_dif order by scan_id;

   SCAN_ID COMPARISON_NAME
---------- ------------------------------
         3 EMP表の比較
         4 EMP表の比較
         4 EMP表の比較
         6 EMP表の比較

SCOTT> 

以下、指定したcomparisonに関連する比較結果全てをパージする例。

SCOTT> exec dbms_comparison.purge_comparison('EMP表の比較');

PL/SQLプロシージャが正常に完了しました。

SCOTT> select scan_id,comparison_name from user_comparison_scan order by scan_id;

レコードが選択されませんでした。

SCOTT> select scan_id,comparison_name from user_comparison_scan_summary order by scan_id;

レコードが選択されませんでした。

SCOTT> select scan_id,comparison_name from user_comparison_scan_values order by scan_id;

レコードが選択されませんでした。

SCOTT> select scan_id,comparison_name from user_comparison_row_dif order by scan_id;

レコードが選択されませんでした。

SCOTT> 

● comparisonをdrop_comparison()関数で削除する。

作成したcomparisonが不要になったら、drop_comparison()関数で削除。

SCOTT> select comparison_name from user_comparison;

COMPARISON_NAME
------------------------------
EMP表の比較

SCOTT> select comparison_name,column_position from user_comparison_columns;

COMPARISON_NAME                COLUMN_POSITION
------------------------------ ---------------
EMP表の比較                                  1
EMP表の比較                                  2
EMP表の比較                                  3
EMP表の比較                                  4
EMP表の比較                                  5
EMP表の比較                                  6
EMP表の比較                                  7
EMP表の比較                                  8

8行が選択されました。

SCOTT> exec dbms_comparison.drop_comparison('EMP表の比較');

PL/SQLプロシージャが正常に完了しました。

SCOTT> select comparison_name from user_comparison;

レコードが選択されませんでした。

SCOTT> select comparison_name,column_position from user_comparison_columns;

レコードが選択されませんでした。

SCOTT> 

DBMS_COMPARISONパッケージ で表データの比較 #4

「DBMS_COMPARISONパッケージで表データの比較」の続きです。

バックナンバー：
DBMS_COMPARISONパッケージ で表データの比較 #1
DBMS_COMPARISONパッケージ で表データの比較 #2
DBMS_COMPARISONパッケージ で表データの比較 #3

---

奥さんが、新しいMacBook Proを購入したので、今奥さんが使っているiMac G5とOracle Database 11g R1 + CentOS 5で遊んでいるIBM ThinkPad R52が下取り処分に。。。

あ〜〜〜、もう少しだけ遊ばせて〜〜〜！　と慌てたり。。。まあ、DBMS_COMPARISONパッケージを試す程度はできそうですが。。。さて、Oracle11gで遊ぶ環境が無くなる〜。

どうしよう。。。既存の環境をつぶさなければインストールできそうにない、TurboLinux(United Linux 1.0)+Oracle9i R2/Oracle10g R1環境を潰すか。。

なんて、前置きはこれくらいにして。

●　CONVERGE()関数でデータを一致させる。

EMP表の内容にEMP2表の内容を合わせるように指定して実行！。異なるデータだけが処理対象となっていることにお気づきだろうか。。

SCOTT> set serveroutput on
SCOTT> l
  1  DECLARE
  2    scanInfo DBMS_COMPARISON.COMPARISON_TYPE;
  3  BEGIN
  4    DBMS_COMPARISON.CONVERGE(
  5      comparison_name => 'EMP表の比較',
  6      scan_id => 2,
  7      scan_info => scanInfo,
  8      converge_options => DBMS_COMPARISON.CMP_CONVERGE_LOCAL_WINS


  9    );
 10    DBMS_OUTPUT.PUT_LINE('ScanID:'||to_char(scanInfo.scan_id));
 11    DBMS_OUTPUT.PUT_LINE('Local rows merged:'||to_char(scanInfo.loc_rows_merged));
 12    DBMS_OUTPUT.PUT_LINE('Remote rows merged:'||to_char(scanInfo.rmt_rows_merged));
 13    DBMS_OUTPUT.PUT_LINE('Local rows deleted:'||to_char(scanInfo.loc_rows_deleted));
 14    DBMS_OUTPUT.PUT_LINE('Remote rows deleted:'||to_char(scanInfo.rmt_rows_deleted));
 15* END;
SCOTT> /
ScanID:2
Local rows merged:0
Remote rows merged:2
Local rows deleted:0
Remote rows deleted:1

PL/SQLプロシージャが正常に完了しました。

SCOTT> 
SCOTT> select * from emp order by empno;

     EMPNO ENAME      JOB              MGR HIREDATE        SAL       COMM     DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
      7000 PLECO      MANAGER         7839 07-10-06       2500                    30
      7369 SMITH      CLERK           7902 80-12-17        800                    20
      7499 ALLEN      SALESMAN        7698 81-02-20       1600        300         30
      7521 WARD       SALESMAN        7698 81-02-22       1250        500         30
      7566 JONES      MANAGER         7839 81-04-02       2975                    20
      7654 MARTIN     SALESMAN        7698 81-09-28       1250       1400         30
      7698 BLAKE      MANAGER         7839 81-05-01       2850                    30
      7782 CLARK      MANAGER         7839 81-06-09       2450                    10
      7788 SCOTT      ANALYST         7566 87-04-19       3000                    20
      7839 KING       PRESIDENT            81-11-17       5000                    10
      7844 TURNER     SALESMAN        7698 81-09-08       1500          0         30
      7876 ADAMS      CLERK           7788 87-05-23       1100                    20
      7900 JAMES      CLERK           7698 81-12-03        950                    30
      7902 FORD       ANALYST         7566 81-12-03       3000                    20
      7934 MILLER     CLERK           7782 82-01-23       1300                    10
      9999 DISCUS     ANALYST         7839 07-10-06       3000                    20

16行が選択されました。

SCOTT> select * from emp2 order by empno;

     EMPNO ENAME      JOB              MGR HIREDATE        SAL       COMM     DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
      7000 PLECO      MANAGER         7839 07-10-06       2500                    30
      7369 SMITH      CLERK           7902 80-12-17        800                    20
      7499 ALLEN      SALESMAN        7698 81-02-20       1600        300         30
      7521 WARD       SALESMAN        7698 81-02-22       1250        500         30
      7566 JONES      MANAGER         7839 81-04-02       2975                    20
      7654 MARTIN     SALESMAN        7698 81-09-28       1250       1400         30
      7698 BLAKE      MANAGER         7839 81-05-01       2850                    30
      7782 CLARK      MANAGER         7839 81-06-09       2450                    10
      7788 SCOTT      ANALYST         7566 87-04-19       3000                    20
      7839 KING       PRESIDENT            81-11-17       5000                    10
      7844 TURNER     SALESMAN        7698 81-09-08       1500          0         30
      7876 ADAMS      CLERK           7788 87-05-23       1100                    20
      7900 JAMES      CLERK           7698 81-12-03        950                    30
      7902 FORD       ANALYST         7566 81-12-03       3000                    20
      7934 MILLER     CLERK           7782 82-01-23       1300                    10
      9999 DISCUS     ANALYST         7839 07-10-06       3000                    20

16行が選択されました。

SCOTT> 

となっており、２表の内容は一致したようだ。（黙視しただけなので、RECHECK()関数でも確認してみることに。。。）

●　RECHECK()関数で再度比較する。

前回の比較時に返されたscan_idとcomparison名を指定して再チェックするだけ。

SCOTT> l
  1  BEGIN
  2    DBMS_OUTPUT.PUT_LINE('======== 再比較結果 ========');
  3    IF DBMS_COMPARISON.RECHECK('EMP表の比較', 2, true) THEN
  4      DBMS_OUTPUT.PUT_LINE('EMP表とEMP2表の内容は同じです。');
  5    ELSE
  6      DBMS_OUTPUT.PUT_LINE('EMP表とEMP2表の内容に違いがあります。');
  7    END IF;
  8* END;
SCOTT> /
======== 再比較結果 ========
EMP表とEMP2表の内容は同じです。

PL/SQLプロシージャが正常に完了しました。

SCOTT> 

２つの表の内容は一致しました！。めでたしめでたし！

ちょ〜〜〜〜〜っと待った〜〜〜〜〜っ！

マニュアルでは、RECHECK()関数は、２つの表の内容に違いが無かった場合FALSEを返すと記載されています。COMPARE()関数とは逆と記載されています。

しか〜〜〜し。Oracle Database 11g 11.1.0.6.0では、RECHECK()を実行し、２つの表の内容が同一の場合、COMPARE()関数と同様に、TRUEを返してきます。

そうなんです、マニュアルバグのようです！。
いずれ修正されると思うので現時点のマニュアルバグの証拠写真をカシャっ！

以下はマニュアルからの引用

Return Values

This function returns TRUE when differences are found in the database objects being compared. This function returns FALSE when no differences are found in the database objects being compared.

となっており、違いがあれば、TRUEを、同じであれば、FALSEを返すと書かれています。皆さんご注意を。

また、RECHECK()関数は、同一か否かを判定するだけで、どのデータが違うといった情報までは取得していない。データが一致しているか一致していないかだけしか確認できない。どのデータが一致していないのかを確認するには、再度COMPARE()関数を実行する必要がある。とのこと。間違いやすいので要注意ですな〜〜。

Note:
This function does not identify new differences in the database objects that have appeared since the specified scan was run. To identify new differences, run the COMPARE function in this package.

DBMS_COMPARISONパッケージ で表データの比較 #3

DBMS_COMPARISONパッケージで表データの比較の続きです。

バックナンバー：
DBMS_COMPARISONパッケージ で表データの比較 #1
DBMS_COMPARISONパッケージ で表データの比較 #2

---

前回は、２つの表を比較し内容が同一であることを確認した。というところまでだった。今回は、emp/emp2の内容が異なっている場合の例を。

●　まず、emp表、emp2表で内容の一致しないデータを準備しておく。

SCOTT> 
SCOTT> insert into emp values(9999,'DISCUS','ANALYST',7839,sysdate,3000,null,20);

1行が作成されました。

SCOTT> insert into emp2 values(8888,'NEON','CLERK',7839,sysdate,1300,null,20);

1行が作成されました。

SCOTT> insert into emp values(7000,'PLECO','MANAGER',7839,sysdate,2500,null,30);

1行が作成されました。

SCOTT> insert into emp2 values(7000,'PLEGO','MANAGER',7839,sysdate,2500,null,30);

1行が作成されました。

SCOTT> commit;

コミットが完了しました。

SCOTT> 

●　COMPARE関数で比較してみる。

SCOTT> l
  1  DECLARE
  2    isSame BOOLEAN;
  3    scanInfo DBMS_COMPARISON.COMPARISON_TYPE;
  4  BEGIN
  5    isSame := DBMS_COMPARISON.COMPARE(
  6                comparison_name => 'EMP表の比較'
  7                ,scan_info => scanInfo
  8                ,perform_row_dif => true
  9              );
 10    DBMS_OUTPUT.PUT_LINE('========= 結果 =======');
 11    DBMS_OUTPUT.PUT_LINE('scan_id='||TO_CHAR(scanInfo.scan_id));
 12    IF isSame THEN
 13      DBMS_OUTPUT.PUT_LINE('EMP表とEMP2表の内容は同じです。');
 14    ELSE
 15      DBMS_OUTPUT.PUT_LINE('EMP表とEMP2表の内容に違いがあります。');
 16    END IF;
 17* END;
SCOTT> /
========= 結果 =======
scan_id=2
EMP表とEMP2表の内容に違いがあります。

PL/SQLプロシージャが正常に完了しました。

SCOTT> 

●　user_comparison_scan_summaryビューや、user_comparison_row_difビューなどで比較結果を確認。

尚、２票間に同一キーを持つデータは存在するがキー以外の列値が異なっている場合、どの列値が異なっているか？　というところまで確認することはできない。

SCOTT> l
  1  select
  2    c.comparison_name,
  3    s.scan_id,
  4    s.current_dif_count
  5  from
  6    user_comparison c join user_comparison_scan_summary s
  7    on c.comparison_name = s.comparison_name
  8  where
  9*   s.scan_id = 2
SCOTT> /

COMPARISON_NAM    SCAN_ID CURRENT_DIF_COUNT
-------------- ---------- -----------------
EMP表の比較             2                 3

SCOTT> 
SCOTT> l
  1  select
  2   s.root_scan_id as scan_id,
  3   s.comparison_name,
  4   d.index_value,
  5   s.status,
  6   case
  7     when local_rowid is not null
  8     and remote_rowid is not null then
  9       'ローカル表、リモート表に同一キーを持つ行が存在しますが、キー以外で列値に違いがあります。'
 10     when local_rowid is null
 11     and remote_rowid is not null then
 12       'ローカル表に存在しない行がリモート表に存在します。'
 13     when local_rowid is not null
 14     and remote_rowid is null then
 15       'ローカル表に存在する行がリモート表に存在しません。'
 16   end as description
 17  from
 18    user_comparison_scan_summary s join user_comparison_row_dif d
 19    on s.scan_id = d.scan_id
 20  where
 21    s.root_scan_id = 2
 22    and s.parent_scan_id is not null
 23  order by
 24*   d.index_value
SCOTT> /

   SCAN_ID COMPARISON_NAME      INDEX_VAL STATUS           DESCRIPTION
---------- -------------------- --------- ---------------- ---------------------------------------------------------------------------
         2 EMP表の比較          7000      ROW DIF          ローカル表、リモート表に同一キーを持つ行が存在しますが、キー以外で列値に違いがあります。
         2 EMP表の比較          8888      ROW DIF          ローカル表に存在しない行がリモート表に存在します。
         2 EMP表の比較          9999      ROW DIF          ローカル表に存在する行がリモート表に存在しません。

SCOTT> 

今日はここまで。
次回は、２つの表の内容を一致させてから再度比較してみる。

DBMS_COMPARISONパッケージ で表データの比較 #2

DBMS_COMPARISONパッケージで表データの比較の続きです。

バックナンバー：
DBMS_COMPARISONパッケージ で表データの比較 #1

---

DBMS_COMPARISONパッケージを利用し２つの表を比較！。（今回は、同一データベース、同一スキーマ内でテーブルの内容を比較してみることにする。）

●　表データを比較する手順

・COMPARISONを作成する。

（比較仕様を作成する。　とでも書いたほうがわかりやすいか？。。。）

・作成したCOMPARISONを元に比較する。

（比較仕様を元に比較を実行する。　とでも書いたほうがわかりやすいか？。。。）

---

では、比較実験開始！

emp表を複製してemp2表を作成する。（まずは、表、索引まで完全に複製して比較。）

SCOTT> create table emp2 as select * from emp;

表が作成されました。

SCOTT> 
SCOTT> alter table emp2 add constraint emp2_pk primary key (empno);

表が変更されました。

SCOTT> 
SCOTT> select * from emp order by empno;

     EMPNO ENAME      JOB              MGR HIREDATE        SAL       COMM     DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
      7369 SMITH      CLERK           7902 80-12-17        800 NULL               20
      7499 ALLEN      SALESMAN        7698 81-02-20       1600        300         30
      7521 WARD       SALESMAN        7698 81-02-22       1250        500         30
      7566 JONES      MANAGER         7839 81-04-02       2975 NULL               20
      7654 MARTIN     SALESMAN        7698 81-09-28       1250       1400         30
      7698 BLAKE      MANAGER         7839 81-05-01       2850 NULL               30
      7782 CLARK      MANAGER         7839 81-06-09       2450 NULL               10
      7788 SCOTT      ANALYST         7566 87-04-19       3000 NULL               20
      7839 KING       PRESIDENT NULL       81-11-17       5000 NULL               10
      7844 TURNER     SALESMAN        7698 81-09-08       1500          0         30
      7876 ADAMS      CLERK           7788 87-05-23       1100 NULL               20
      7900 JAMES      CLERK           7698 81-12-03        950 NULL               30
      7902 FORD       ANALYST         7566 81-12-03       3000 NULL               20
      7934 MILLER     CLERK           7782 82-01-23       1300 NULL               10

14行が選択されました。

SCOTT> select * from emp2 order by empno;

     EMPNO ENAME      JOB              MGR HIREDATE        SAL       COMM     DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
      7369 SMITH      CLERK           7902 80-12-17        800 NULL               20
      7499 ALLEN      SALESMAN        7698 81-02-20       1600        300         30
      7521 WARD       SALESMAN        7698 81-02-22       1250        500         30
      7566 JONES      MANAGER         7839 81-04-02       2975 NULL               20
      7654 MARTIN     SALESMAN        7698 81-09-28       1250       1400         30
      7698 BLAKE      MANAGER         7839 81-05-01       2850 NULL               30
      7782 CLARK      MANAGER         7839 81-06-09       2450 NULL               10
      7788 SCOTT      ANALYST         7566 87-04-19       3000 NULL               20
      7839 KING       PRESIDENT NULL       81-11-17       5000 NULL               10
      7844 TURNER     SALESMAN        7698 81-09-08       1500          0         30
      7876 ADAMS      CLERK           7788 87-05-23       1100 NULL               20
      7900 JAMES      CLERK           7698 81-12-03        950 NULL               30
      7902 FORD       ANALYST         7566 81-12-03       3000 NULL               20
      7934 MILLER     CLERK           7782 82-01-23       1300 NULL               10

14行が選択されました。

SCOTT> 

create_comparison関数でcomparisonを作成する。
２つの表(empとemp2）は、どちらも同一データベースのSCOTTスキーマに存在するため、dblink_name引数にはnullを指定する。

SCOTT> l
  1  begin
  2    dbms_comparison.create_comparison(
  3      comparison_name => 'EMP表の比較'
  4     ,schema_name => 'SCOTT'
  5     ,object_name => 'EMP'
  6     ,dblink_name => null
  7     ,remote_schema_name => 'SCOTT'
  8     ,remote_object_name => 'EMP2'
  9    );
 10* end;
SCOTT> /

PL/SQLプロシージャが正常に完了しました。

SCOTT> 

作成されたcomparisonを確認するには、user_comparisonビュー/user_comparison_columnsビュー問い合わせる

SCOTT> l
  1  select
  2    comparison_name
  3    ,scan_mode
  4    ,schema_name||'.'||object_name||'(type='||object_type||')' as local
  5    ,remote_schema_name||'.'||remote_object_name||'(type='||remote_object_type||')' as remote
  6    ,dblink_name
  7    ,last_update_time
  8  from
  9    user_comparison
 10  where
 11*   comparison_name = 'EMP表の比較'
SCOTT> /

COMPARISON_NAME SCAN_MODE LOCAL                      REMOTE                     DBLINK_NAME LAST_UPDATE_TIME
--------------- --------- -------------------------- -------------------------- ----------- ------------------------------
EMP表の比較     FULL      SCOTT.EMP(type=TABLE)      SCOTT.EMP2(type=TABLE)     NULL        07-10-06 15:58:36.665370

SCOTT> 
SCOTT> select * from user_comparison_columns order by column_position;

COMPARISON_NAME                COLUMN_POSITION COLUMN_NAME                    I
------------------------------ --------------- ------------------------------ -
EMP表の比較                                  1 EMPNO                          Y
EMP表の比較                                  2 ENAME                          N
EMP表の比較                                  3 JOB                            N
EMP表の比較                                  4 MGR                            N
EMP表の比較                                  5 HIREDATE                       N
EMP表の比較                                  6 SAL                            N
EMP表の比較                                  7 COMM                           N
EMP表の比較                                  8 DEPTNO                         N

8行が選択されました。

SCOTT> 

● compare関数を利用して比較する。

事前に作成されたcomparisonを元に、compare関数を利用して比較を行う。この時、比較処理事に採版されるscan_idを記録しておくとよいだろう。
scan_idは、内容に相違がある場合、その詳細をディクショナリビューから問い合わせたり、再比較する際に利用する。

SCOTT> set serveroutput on format wrapped
SCOTT> l
  1  DECLARE
  2    isSame BOOLEAN;
  3    scanInfo DBMS_COMPARISON.COMPARISON_TYPE;
  4  BEGIN
  5    isSame := DBMS_COMPARISON.COMPARE(
  6                comparison_name => 'EMP表の比較'
  7                ,scan_info => scanInfo
  8                ,perform_row_dif => true
  9              );
 10    DBMS_OUTPUT.PUT_LINE('========= 結果 =======');
 11    DBMS_OUTPUT.PUT_LINE('scan_id='||TO_CHAR(scanInfo.scan_id));
 12    IF isSame THEN
 13      DBMS_OUTPUT.PUT_LINE('EMP表とEMP2表の内容は同じです。');
 14    ELSE
 15      DBMS_OUTPUT.PUT_LINE('EMP表とEMP2表の内容に違いがあります。');
 16    END IF;
 17* END;
SCOTT> /
========= 結果 =======
scan_id=1
EMP表とEMP2表の内容は同じです。

PL/SQLプロシージャが正常に完了しました。

SCOTT> 

ということで、次回は表の内容が異なっている場合はどうなるかという例を。

MacOSXのX11 から Oracle Database 11g - 番外編 - 自動起動・停止

インストール、構成関連は前回で終わりとしていたが、自動起動、停止に関するエントリをアップし忘れていたので追記しておく。

まあ、自動起動、停止は、Oracleから提供されている dbstart/dbshutスクリプトを起動スクリプトから実行すれば良いだけなのと、マニュアルにも記載されているし、ググれば山ほどヒットするので細かい解説はしないのであしからず。

●　Oracle Database 11g になっても、わすれちゃならねぇ、oratab編集！

[oracle@glasscatfish ˜]$ cat /etc/oratab
#



# This file is used by ORACLE utilities.  It is created by root.sh
# and updated by the Database Configuration Assistant when creating
# a database.

# A colon, ':', is used as the field terminator.  A new line terminates
# the entry.  Lines beginning with a pound sign, '#', are comments.
#
# Entries are of the form:
#   $ORACLE_SID:$ORACLE_HOME:<N|Y>:
#
# The first and second fields are the system identifier and home
# directory of the database respectively.  The third filed indicates
# to the dbstart utility that the database should , "Y", or should not,
# "N", be brought up at system boot time.
#
# Multiple entries with the same $ORACLE_SID are not allowed.
#
#
lampsys:/u01/app/oracle/product/11.1.0/lampeye:Y
[oracle@glasscatfish ˜]$ 

●　Oracleの起動スクリプトする、CentOS5では以下のようにした。(ORACLE_OWNER/ORACLE_HOMEはご自分で設定したユーザ名とパスを指定してくださいね。）

[root@glasscatfish init.d]# vi oracle
[root@glasscatfish init.d]# cat oracle
#!/bin/bash
# chkconfig: 35 80 30
# description: oracle database startup/shutdown script
# 

. /etc/rc.d/init.d/functions

ORACLE_OWNER="oracle"
ORACLE_HOME="/u01/app/oracle/product/11.1.0/lampeye"


case "$1" in
start)
        echo -n $"Starting Oracle Database 11g:"
        su - $ORACLE_OWNER -c "$ORACLE_HOME/bin/dbstart $ORACLE_HOME"
        echo "OK"
        ;;
stop)
        echo -n $"Stopping Oracle Database 11g:"
        su - $ORACLE_OWNER -c "$ORACLE_HOME/bin/dbshut ORACLE_HOME"
        echo "OK"
        ;;
*)
        echo $"Usage: $0 {start|stop}"
esac
[root@glasscatfish init.d]# 
[root@glasscatfish init.d]# chmod 750 oracle
[root@glasscatfish init.d]# chkconfig --add oracle
[root@glasscatfish init.d]# chkconfig --list | grep oracle
oracle          0:off   1:off   2:off   3:on    4:off   5:on    6:off
[root@glasscatfish init.d]# 

あとは、CentOSを起動/停止し、 $ORACLE_HOME/startup.logや　$ORACLE_HOME/shutdown.log/startup.logの内容及なども含め、正しく起動、停止しているか確認すればＯＫ。

DBMS_COMPARISONパッケージ で表データの比較 #1

Oracle Database 11gで新たに追加されたDBMS_COMPARISONパッケージ。
このパッケージは２つのTable/Single-table view/Materialized view（シノニムも可）を比較したり、データを一致させたりするための機能を提供するパッケージだ。
レプリケーション関連のマニュアルへのリンクもあるのでレプリケーション環境を意識した機能ではあるようだが、単に２つの表の内容を比較したり一致させることにも利用できるのでレプリケーション環境以外でも利用できる。

ただし、マニュアルに記載されているように利用できるデータ型や索引などの制限があるので、利用に際して事前調査は必要でしょうね。

参考：
Oracle Database PL/SQL Packages and Types Reference 11g Release 1 (11.1.) 31 DBMS_COMPARISON

ということで、早速試してみる。

環境は、先日作成したIBM Thinkpad R52 のCentOS 5上に構築したOracle Database 11g R1 11.1.0.6.0 for Linux (x86)を利用した。）

例によって、MacOSXのTerminalからssh経由で利用した。
（CentOS5/Oracle11gともエンコーディングにUTF-8を利用しているため、TerminalのエンコーティングもUTF-8に設定した。

まずは、Oracle Database 11gから新規追加されたDBMS_COMPARISONパッケージ関連のディクショナリービューの確認。（尚、DBA_＊ビューも追加されている。）

[oracle@glasscatfish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on 月 10月 8 08:50:38 2007

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

> conn scott/tiger 
接続されました。
SCOTT> 
SCOTT> 
SCOTT> desc user_comparison_scan
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 COMPARISON_NAME                           NOT NULL VARCHAR2(30)
 SCAN_ID                                   NOT NULL NUMBER
 PARENT_SCAN_ID                                     NUMBER
 STATUS                                             VARCHAR2(16)
 COUNT_ROWS                                         NUMBER
 SCAN_NULLS                                         VARCHAR2(1)
 LAST_UPDATE_TIME                                   TIMESTAMP(6)


SCOTT> desc user_comparison_scan_summary
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 COMPARISON_NAME                           NOT NULL VARCHAR2(30)
 SCAN_ID                                   NOT NULL NUMBER
 PARENT_SCAN_ID                                     NUMBER
 ROOT_SCAN_ID                                       NUMBER
 STATUS                                             VARCHAR2(16)
 CURRENT_DIF_COUNT                                  NUMBER
 INITIAL_DIF_COUNT                                  NUMBER
 COUNT_ROWS                                         NUMBER
 SCAN_NULLS                                         VARCHAR2(1)
 LAST_UPDATE_TIME                                   TIMESTAMP(6)

SCOTT> desc user_comparison_scan_values
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 COMPARISON_NAME                           NOT NULL VARCHAR2(30)
 SCAN_ID                                   NOT NULL NUMBER
 COLUMN_POSITION                           NOT NULL NUMBER
 MIN_VALUE                                          VARCHAR2(4000)
 MAX_VALUE                                          VARCHAR2(4000)
 LAST_UPDATE_TIME                                   TIMESTAMP(6)

SCOTT> desc user_comparison_row_dif
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 COMPARISON_NAME                           NOT NULL VARCHAR2(30)
 SCAN_ID                                   NOT NULL NUMBER
 LOCAL_ROWID                                        ROWID
 REMOTE_ROWID                                       ROWID
 INDEX_VALUE                                        VARCHAR2(4000)
 STATUS                                             VARCHAR2(3)
 LAST_UPDATE_TIME                                   TIMESTAMP(6)

SCOTT> 
SCOTT> desc user_comparison
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 COMPARISON_NAME                           NOT NULL VARCHAR2(30)
 COMPARISON_MODE                                    VARCHAR2(5)
 SCHEMA_NAME                                        VARCHAR2(30)
 OBJECT_NAME                                        VARCHAR2(30)
 OBJECT_TYPE                                        VARCHAR2(17)
 REMOTE_SCHEMA_NAME                                 VARCHAR2(30)
 REMOTE_OBJECT_NAME                                 VARCHAR2(30)
 REMOTE_OBJECT_TYPE                                 VARCHAR2(17)
 DBLINK_NAME                                        VARCHAR2(128)
 SCAN_MODE                                          VARCHAR2(9)
 SCAN_PERCENT                                       NUMBER
 CYCLIC_INDEX_VALUE                                 VARCHAR2(4000)
 NULL_VALUE                                         VARCHAR2(4000)
 LOCAL_CONVERGE_TAG                                 RAW(2000)
 REMOTE_CONVERGE_TAG                                RAW(2000)
 MAX_NUM_BUCKETS                                    NUMBER
 MIN_ROWS_IN_BUCKET                                 NUMBER
 LAST_UPDATE_TIME                                   TIMESTAMP(6)

SCOTT> 
SCOTT> desc user_comparison_columns
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 COMPARISON_NAME                           NOT NULL VARCHAR2(30)
 COLUMN_POSITION                           NOT NULL NUMBER
 COLUMN_NAME                               NOT NULL VARCHAR2(30)
 INDEX_COLUMN                                       VARCHAR2(1)

DBMS_COMPARISIONパッケージを利用するには、EXECUTEオブジェクト権限、及び、EXECUTE_CATALOG_ROLEロール（データディクショナリ内のオブジェクトに対するEXECUTE/SELECT権限）を実行するユーザへ付与する必要がある。

SCOTT> conn / as sysdba
接続されました。
SYS> grant execute on dbms_comparison to scott;

権限付与が成功しました。

SYS> grant execute_catalog_role to scott;

権限付与が成功しました。

SYS> conn scott/tiger
接続されました。
SCOTT> desc dbms_comparison
FUNCTION COMPARE RETURNS BOOLEAN
 引数名                         タイプ                  In/Out Default?
 ------------------------------ ----------------------- ------ --------
 COMPARISON_NAME                VARCHAR2                IN
 SCAN_INFO                      RECORD                  OUT
   SCAN_ID                      NUMBER                  OUT
   LOC_ROWS_MERGED              NUMBER                  OUT
   RMT_ROWS_MERGED              NUMBER                  OUT
   LOC_ROWS_DELETED             NUMBER                  OUT
   RMT_ROWS_DELETED             NUMBER                  OUT
 MIN_VALUE                      VARCHAR2                IN     DEFAULT
 MAX_VALUE                      VARCHAR2                IN     DEFAULT
 PERFORM_ROW_DIF                BOOLEAN                 IN     DEFAULT

・・・・・・・中略・・・・・・・

FUNCTION RECHECK RETURNS BOOLEAN
 引数名                         タイプ                  In/Out Default?
 ------------------------------ ----------------------- ------ --------
 COMPARISON_NAME                VARCHAR2                IN
 SCAN_ID                        NUMBER                  IN
 PERFORM_ROW_DIF                BOOLEAN                 IN     DEFAULT

SCOTT> 

これでDBMS_COMPARISONパッケージを利用する準備は整った。というところで本日は終わり。

次回へ続く。

MacOSXのX11 から Oracle Database 11g #7

MacOSXのX11 から Oracle Database 11g その７回目。
Enterprise Manager 11g Database Controlを起動してみる。

バックナンバー
MacOSXのX11 から Oracle Database 11g #1
MacOSXのX11 から Oracle Database 11g #2
MacOSXのX11 から Oracle Database 11g #3
MacOSXのX11 から Oracle Database 11g #4
MacOSXのX11 から Oracle Database 11g #5
MacOSXのX11 から Oracle Database 11g #6

Oracle10gのEnterprise Managerは、Safariなんかに最適化してませんなどと表示されていたが、Enterprise Manager 11gでは今のところem10gに類似する現象にはお目にかかっていない。。問題なさそう・・・かな・・。

ということで、
Oracle11gのお遊び環境として利用しているThink Padが下取りに出されるまでに、Oracle11gの新機能で遊んでおきたいので、Oracle Database 11gのインストール絡みのエントリはこれでおしまい。

Oracle Database 11g - for Intel Mac

http://www.oracle.com/technology/support/metalink/index.html

によれば、Intel Mac 向け、Oracle Database 10g R2 と　Oracle Database 11g R1のステータスが追加されていますね。　期待していますよ。オラクルさん。

MacOSXのX11 から Oracle Database 11g #6

MacOSXのX11 から Oracle Database 11g その６回目。
インストール後の作業。

バックナンバー
MacOSXのX11 から Oracle Database 11g #1
MacOSXのX11 から Oracle Database 11g #2
MacOSXのX11 から Oracle Database 11g #3
MacOSXのX11 から Oracle Database 11g #4
MacOSXのX11 から Oracle Database 11g #5

オラクル所有者の環境変数の<詳細はマニュアルを参照のこと。

今回設定した環境変数は以下を。

[oracle@glasscatfish ˜]$ cat .bashrc
# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi

# User specific aliases and functions

export TMP=/tmp
export TMP_DIR=/tmp

# for oracle11g
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/11.1.0/lampeye
export ORACLE_SID=lampsys
export ORA_NLS10=$ORACLE_HOME/nls/data
export NLS_LANG=japanese_japan.AL32UTF8
export CLASSPATH=$ORACLE_HOME/JRE/lib:$ORACLE_HOME/jlib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib:/lib:/usr/lib:/usr/local/lib
export PATH=$PATH:$ORACLE_HOME/bin:.
[oracle@glasscatfish ˜]$ 

一旦、停止後、Net Serviceも含めて手動での起動確認。

G5Server:˜ oracle$ 
G5Server:˜ oracle$ 
G5Server:˜ oracle$ ssh oracle@glasscatfish


oracle@glasscatfish's password: 
Last login: Sun Sep 30 14:44:03 2007 from 192.168.1.19
[oracle@glasscatfish ˜]$ onsctl start
onsctl: ons started
[oracle@glasscatfish ˜]$ lsnrctl start

LSNRCTL for Linux: Version 11.1.0.6.0 - Production on 30-9月 -2007 14:47:05

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

/u01/app/oracle/product/11.1.0/lampeye/bin/tnslsnrを起動しています。お待ちください...

TNSLSNR for Linux: Version 11.1.0.6.0 - Production
システム・パラメータ・ファイルは/u01/app/oracle/product/11.1.0/lampeye/network/admin/listener.oraです。
ログ・メッセージを/u01/app/oracle/diag/tnslsnr/glasscatfish/listener/alert/log.xmlに書き込みました。
リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=glasscatfish.macdeoracle.jp)(PORT=1521)))
リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=glasscatfish.macdeoracle.jp)(PORT=1521)))に接続中
リスナーのステータス
------------------------
別名                      LISTENER
バージョン                TNSLSNR for Linux: Version 11.1.0.6.0 - Production
開始日                    30-9月 -2007 14:47:05
稼働時間                  0 日 0 時間 0 分 0 秒
トレース・レベル          off
セキュリティ              ON: Local OS Authentication
SNMP                      OFF
パラメータ・ファイル      /u01/app/oracle/product/11.1.0/lampeye/network/admin/listener.ora
ログ・ファイル            /u01/app/oracle/diag/tnslsnr/glasscatfish/listener/alert/log.xml
リスニング・エンドポイントのサマリー...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=glasscatfish.macdeoracle.jp)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
リスナーはサービスをサポートしていません。
コマンドは正常に終了しました。
[oracle@glasscatfish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on 日 9月 30 14:47:09 2007

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

SQL> conn / as sysdba
アイドル・インスタンスに接続しました。
SQL> startup
ORACLEインスタンスが起動しました。

Total System Global Area  514748416 bytes
Fixed Size                  1300940 bytes
Variable Size             234882612 bytes
Database Buffers          272629760 bytes
Redo Buffers                5935104 bytes
データベースがマウントされました。
データベースがオープンされました。
SQL> 

以下のようなエラーが発生する場合には、SELinuxを無効又は、Permissiveにすることを忘れている場合、KNOWN ISSUEじゃ！　ちなみに、今回は、SELinuxを無効にしたが、マニュアルには、Permissiveに変更するよう記載されているので、本番環境では、Permissiveにしておくべきでしょうね。
http://www.oracle-base.com/articles/11g/OracleDB11gR1InstallationOnEnterpriseLinux4and5.php

[oracle@glasscatfish ˜]$ sqlplus /nolog
sqlplus: error while loading shared libraries: /u01/app/oracle/product/11.1.0/lampeye/lib/libnnz11.so: cannot restore segment prot after reloc: Permission denied

さて、次回は、EMを軽く操作してみましょうか。。

MacOSXのX11 から Oracle Database 11g #5

MacOSXのX11 から Oracle Database 11g その５回目、いよいよMacOSXのxtermからssh経由でOracle Database 11gのインストールのつづきをQuickTimeムービーでどうぞ。

バックナンバー
MacOSXのX11 から Oracle Database 11g #1
MacOSXのX11 から Oracle Database 11g #2
MacOSXのX11 から Oracle Database 11g #3
MacOSXのX11 から Oracle Database 11g #4

Oracle11gになっても、rootユーザでのshellスクリプト実行は必須ですな〜！ (^^;;;

また、事前チェックでスワップ領域の警告がでたのだが、今回のインストールでは問題ないのでそのまま進めた。

（再生にはQuickTimeが必要です。）

約１３MBでサウンドトラックなし。

とCentOS5 へのOracle Database 11gのインストールは、予想通り順調ですね〜、次回へつづく。

MacOSXのX11 から Oracle Database 11g #4

MacOSXのX11 から Oracle Database 11g その４回目、いよいよMacOSXのxtermからssh経由でOracle Database 11gのインストール。

バックナンバー
MacOSXのX11 から Oracle Database 11g #1
MacOSXのX11 から Oracle Database 11g #2
MacOSXのX11 から Oracle Database 11g #3

以下、MacOSXのX11、xtermからssh接続にて、CentOS 5上のOUI(Oracle Universal Installer)を起動してインストールしたスクリーンショットをどうぞ！
（カスタムインストールでOracle Database 11g R1 EEをインストールした様子です。）

まず、X11のxtermを起動し、SSH接続してOUIを起動。
（尚、LANG=ja_JP.UTF-8、NLS_LANG=japanese_japan.AL32UTF8のままでもOUIは文字化けしません。ただ、MacOSXの付属のX11のxtermでは文字化けしちゃいますけどね。TerminalはUTF-8に対応しているんだが。まあ、気になる方は、LANG=en_US.UTF-8、NLS_LANG=american_america.AL32UTF8などにして文字化け回避すればいいんじゃないだろうか。今回は、OUIで文字化けしなければ問題ないのでそのまま実行しちゃいます。）

xtermでは文字化けしてますが、OUIでは問題なし！

ということで、つづきはムービーで公開予定。
（ダウントードサイズが大きめのQuickTimeにするかYouTubeにするか検討中。いまのところ別エントリで公開予定）

MacOSXのX11 から Oracle Database 11g #3

MacOSXのX11 から Oracle Database 11g その３回目です。

バックナンバー
MacOSXのX11 から Oracle Database 11g #1
MacOSXのX11 から Oracle Database 11g #2

（インストレーションガイドは一度は読んでおきましょうね。）

では、お役即のインストーレーション前の準備作業から。
（インストレーションガイドに示された順に行ったので、ガイドを読み進みながらやればいいと思いますよ。）

特に細かい解説はしないが、各作業に関連するマニュアルのリンクを載せているのでそちらも参照のこと。

●　Disk Space Requirements -
　　Oracle® Database Installation Guide 11g Release 1 (11.1) for Linux - Disk Space Requirements

[root@glasscatfish ˜]# df -h
Filesystem          サイズ  使用  残り 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
                       35G  8.3G   25G  26% /
/dev/sda1              99M   11M   83M  12% /boot
tmpfs                1010M     0 1010M   0% /dev/shm

●　Memory Requirements -
　　Oracle® Database Installation Guide 11g Release 1 (11.1) for Linux - Memory Requirements

[root@glasscatfish ˜]# cat /proc/meminfo
MemTotal:      2066544 kB
・・・中略・・・
SwapTotal:     2031608 kB
・・・中略・・・
[root@glasscatfish ˜]# cat /proc/cpuinfo
・・・中略・・・
model name      : Intel(R) Pentium(R) M processor 1.73GHz
・・・中略・・・

[root@glasscatfish ˜]# 

●　Operating System Requirements -
　　Oracle® Database Installation Guide 11g Release 1 (11.1) for Linux - Operating System Requirements
●　Kernel Reauirements -
　　Oracle® Database Installation Guide 11g Release 1 (11.1) for Linux - Kernel Reauirements

今回は、前述のマニュアルには以下のような NOTEがある。まあ、お遊び環境なので Red Hat Enterprise Linux 5.0と互換の高いCentOS 5なら問題ないだろう。（ちなみに、Oracle10g R2をCentOS4.4へインストールした際もRea Hat Enterprise Linux 4.0へのインストール手順と変るところは無かった。）

Note:
Only the distributions and versions listed in the earlier itemized list are supported. Do not install the software on other versions of Linux.

[root@glasscatfish ˜]# cat /proc/version
Linux version 2.6.18-8.el5 (mockbuild@builder4.centos.org) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #1 SMP Thu Mar 15 19:57:35 EDT 2007
[root@glasscatfish ˜]# 
[root@glasscatfish ˜]# uname -a
Linux glasscatfish 2.6.18-8.el5 #1 SMP Thu Mar 15 19:57:35 EDT 2007 i686 i686 i386 GNU/Linux
[root@glasscatfish ˜]#

●　Package Requirements -
　　Oracle® Database Installation Guide 11g Release 1 (11.1) for Linux - Package Requirements
●　Compiler Requirements -
　　Oracle® Database Installation Guide 11g Release 1 (11.1) for Linux - Compiler Requirements

注）libaio-devel-0.3.106-3.2、sysstat-7.0.0-3.el5、unixODBC-2.2.11-7.1、unixODBC-devel-2.2.11-7.1は、別途追加インストールした。

[root@glasscatfish ˜]# rpm -q binutils compat-libstdc++-33 elfutils-libelf elfutils-libelf-devel glibc glibc-common glibc-devel gcc gcc-c++ libaio-devel libaio libgcc libstdc++ libstdc++-devel make sysstat unixODBC unixODBC-devel
binutils-2.17.50.0.6-2.el5
compat-libstdc++-33-3.2.3-61
elfutils-libelf-0.125-3.el5
elfutils-libelf-devel-0.125-3.el5
glibc-2.5-12
glibc-common-2.5-12
glibc-devel-2.5-12
gcc-4.1.1-52.el5
gcc-c++-4.1.1-52.el5
libaio-devel-0.3.106-3.2
libaio-0.3.106-3.2
libgcc-4.1.1-52.el5
libstdc++-4.1.1-52.el5
libstdc++-devel-4.1.1-52.el5
make-3.81-1.1
sysstat-7.0.0-3.el5
unixODBC-2.2.11-7.1
unixODBC-devel-2.2.11-7.1
[root@glasscatfish ˜]# 

●　Configuring Name Resolution -
　　Oracle® Database Installation Guide 11g Release 1 (11.1) for Linux - Configuring Name Resolution

[root@glasscatfish ˜]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain localhost
::1             localhost6.localdomain6 localhost6

192.168.1.7     glasscatfish.macdeoracle.jp glasscatfish
[root@glasscatfish ˜]# 
[root@glasscatfish ˜]# hostname
glasscatfish.macdeoracle.jp
[root@glasscatfish ˜]#

●　Creating Required Operationg System Groups and Users -
　　Oracle® Database Installation Guide 11g Release 1 (11.1) for Linux - Creating Required Operationg System Groups and Users

グループは、oinstallとdbaを作成し、oracle所有者は、oracleとし、プライマリグループは、oinstall セカンダリグループは dba　というお約束の構成にした。（今回は、ASMを利用しないので asmadminグループは作成しない。）

[root@glasscatfish ˜]# cat /etc/group | grep -E '(oinstall|dba)'
oinstall:x:501:oracle
dba:x:502:oracle
[root@glasscatfish ˜]# 
[root@glasscatfish ˜]# cat /etc/passwd | grep oracle
oracle:x:501:501:oracle owner:/home/oracle:/bin/bash
[root@glasscatfish ˜]# 

●　Verifying that the User nobody Exists -
　　Oracle® Database Installation Guide 11g Release 1 (11.1) for Linux - Verifying that the User nobody Exists

[root@glasscatfish ˜]# id nobody
uid=99(nobody) gid=99(nobody) groups=99(nobody)
[root@glasscatfish ˜]# 

●　Configuring Kernel Parameters -
　　Oracle® Database Installation Guide 11g Release 1 (11.1) for Linux - Configuring Kernel Parameters

[root@glasscatfish ˜]# /sbin/sysctl -a | grep -E '(sem|shmall|shmmax|shmmni|file-max|ip_local_port_range|mem_default|mem_max|vmem_default|vmen_max)'
net.ipv4.ip_local_port_range = 32768    61000
net.core.optmem_max = 10240
net.core.rmem_default = 109568
net.core.wmem_default = 109568
net.core.rmem_max = 131071
net.core.wmem_max = 131071
kernel.sem = 250        32000   32      128
kernel.shmmni = 4096
kernel.shmall = 268435456
kernel.shmmax = 4294967295
fs.file-max = 205074
[root@glasscatfish ˜]# 
[root@glasscatfish ˜]# /sbin/sysctl -p
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 4294967295
kernel.shmall = 268435456
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 4194304
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 262144
kernel.sem = 250 32000 100 128
fs.file-max = 65536
[root@glasscatfish ˜]# 

●　Setting Shell Limits for the oracle User -
　　Oracle® Database Installation Guide 11g Release 1 (11.1) for Linux - Setting Shell Limits for the oracle User

[root@glasscatfish ˜]# tail -6 /etc/security/limits.conf

oracle          soft    nproc           2047
oracle          hard    nproc           16384
oracle          soft    nofile          1024
oracle          hard    nofile          65536
# End of file
[root@glasscatfish ˜]# 
[root@glasscatfish ˜]# vi /etc/pam.d/login
[root@glasscatfish ˜]# tail -3 /etc/pam.d/login
#for oracle11g
session required        /lib/security/pam_limits.so
session required        /pam_limits.so
[root@glasscatfish ˜]# 
[root@glasscatfish ˜]# vi /etc/profile
[root@glasscatfish ˜]# tail -14 /etc/profile
    fi
done

unset i
unset pathmunge

if [ $USER = "oracle" ]; then
        if [ $SHELL = "/bin/ksh" ]; then
                ulimit -p 16384
                ulimit -n 65536
        else
                ulimit -u 16384
        fi
fi
[root@glasscatfish ˜]# 

●　Creating an Oracle Base Directory -
　　Oracle® Database Installation Guide 11g Release 1 (11.1) for Linux - Creating an Oracle Base Directory

Oracle Base directoryもいつもの、 /u01/app とした。尚、お遊び環境なので他のディレクトリの作成はOUIにお任せすることにした。

最後に、
●　Configuring the oracle Users's Environment -
　　Oracle® Database Installation Guide 11g Release 1 (11.1) for Linux - Configuring the oracle Users's Environment

Oracle所有者の環境変数などもいつもの同じなので特に解説するまでもないと思うので、マニュアルを参照してくださいね。

尚、今回作成するデータベースの SIDは、lampeye にするつもりだったのだが、打ち間違えて、lampsys になってしまった。(^^;;;
お遊び環境なので作り直しはせず、lampsys のままに・・・・・・。（本番環境作るときはタイプミスに注意しましょうね。。）

尚、今回は、MacOSXからxtermを利用するので、MacOSXからCentOS 5へXサーバーへのアクセスを許可しておく必要がある。お忘れなく！

例）IPアドレスが192.168.1.19へXサーバーへのアクセスを許可する場合。

[root@glasscatfish ˜]# xhost +192.168.1.19
192.168.1.19 being added to access control list
[root@glasscatfish ˜]# 

ということで、　Oracle Database インストール前の準備はこんなところ、Oracle10g R2のインストール前作業と大きく変わるところはない。

次回はいよいよ、インストール。11gのインストーラーはどんな感じなのかなぁ・・・・・。

MacOSXのX11 から Oracle Database 11g #2

さて、前回からのつづきです。

CentOS 5をダウンロードし、CD６枚を作成し、あっという間にインストール終了。
MacOSXでCDを作成する方法は、「Mac De Oracle - １０万円 de RAC #9」などを参考に。

（CentOSのインストール方法は、さて前回紹介した書籍やネットをググって見てくださいね。）

CentOSのインストールについて解説するつもりはないが、インストール後にCentOS 5での準備については少々書いておく。

Oracle Universal Installer (以下、OUI)は、MacOSXのxtermからssh接続して実行するのでまずはssh接続の確認。

G5Server:˜ oracle$ ssh -Y oracle@glasscatfish
The authenticity of host 'glasscatfish (192.168.1.7)' can't be established.
RSA key fingerprint is 13:86:62:9a:95:2c:d7:98:11:aa:3b:f1:e2:35:05:b3.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'glasscatfish,192.168.1.7' (RSA) to the list of known hosts.
oracle@glasscatfish's password: 
Last login: Sat Sep 29 10:48:25 2007 from 192.168.1.13
[oracle@glasscatfish ˜]$ 

ついでに、VNCでの接続も確認しておく。（MacOSXからCentOSのGnome Desktopでいろいろとやる事もあだろうし。）
CentOS側では、メニューの「システム」->「設定」->「リモートデスクトップ」でVNCによるリモートデスクトップが利用できるようになっている。

MacOSXからはChiken of the VNCを利用し接続している。

VNC接続に必要なポートを空けて必要があるのでFirewallの設定もお忘れなく。

それと、Oracle Database 11gのインストール後に関するエントリにも書くつもりだが、SELinuxはPermissive又は無効にしておく必要がある。今回は無効にした。
（Oracle10gの時もそうだったな。）
尚、マニュアルには、Permissiveへ変更するよう記載されているので本番環境ではPermissiveにするべきでしょうね。
http://www.oracle-base.com/articles/11g/OracleDB11gR1InstallationOnEnterpriseLinux4and5.php
どのようなエラーになるのかは、Oracle Database 11gのインストール後に関するエントリで書く予定。

しかし、Linuxのインストールや設定はバージョンアップ毎に楽になっているのがわかるよな〜。ほんと。

MacOSXのX11 から Oracle Database 11g #1

いや〜、Oracle10gのころは各プラットフォームのOracle　Databaseが次々にOTN　USからダウンロードできたのになんか、Linux X86版リリース後、なかなか次のがないな〜。軸足がLinuxに置かれたのはなんとなく理解できるが・・・・。

しかたないので、Oracle Database 11g for Linux x86を　CentOS 5.0へインストールして遊ぶことにした。

え、MacOSXとは無関係じゃん？！　　　

はい。それはそうなんですが、無理矢理絡めるのが　Mac De Oracle流！

そう、　Oracle Database 11gのインストール作業はすべて、MacOSX X11のxtermからSSH接続して行うことにする。

CentOS 5は、Red Had Enterprise Linux 5と互換があるので、インストールには問題はないだろう。(Oracle10gをCentOS 4.4へインストールした際も全く問題なかったしね。）

では、まずは、利用する環境から。

●　H/W - IBM　（レノボ）　ThinkPad R52 / CPU Pentium M 1.73Ghz / メモリ：2GB / DISK:40GB

今回利用しているノートPCは、妻が仕事で利用していたものなのだが、仕事も無事おわりMacがメインのウチでは邪魔なので、いずれ下取りに出すことが確定している。ただ、下取りに出すまで間、Oracle Database 11gのサーバーにして遊んでおこうか！　というのが事の発端なのですがね。。・・・

●　OS - CentOS 5 - i386

●　Oracle Database 11g R1 EE for Linux X86

●　そして、忘れちゃならねぇ、Mac - Apple PowerMac G5 Dual 2.7Ghz - MacOSX 10.4.10 Server
うちは未だに、IntelMacが無いのだが、LeopardがリリースされてMacBookなんか登場したら考えよ。・・・・・・・

参考
Oracle Database 11g マニュアル（英語）

CentOSが始めての方は、これなんかいいんじゃないかな。

あとは、これとか

次回へつづく。

Oracle database 11g for MacOSX ?

先日リリースされたOracle database 11g R1 のUnix/Linux系のgeneral Oracle Database 11g documentation のAdministrator Guilde等で、MacOSXに関する記述のあることに気付いた！。

general Oracle Database 11g documentation

あたらしいオンラインドキュメントは、以前のリリースに比べてかなり使い易くなっていて、左側のペイン上部に検索ボックが用意されドキュメント内の検索も簡単にできる。
さらに、ドキュメントに対してコメントできたりと、Web2.0の要素を取り込んだオンラインドキュメントに進化している。

いいですね〜。気付いた方がコメントで、マニュアルバグを指摘できるようになったわけですから。
（コメントスパム対策は大変そうだが。。。）

前置きはこれくらいにして、本題に戻ると、検索ボックスに　Mac　と入力して検索してみるとMacOSXに関する記述がOracle database 11g のマニュアル内で多数ヒットする。
Oracle database 10g R2はリリースされていないが、Oracle database 11g R1はリリースされるということと考えてもよさそうな感じですね〜〜。:-)
期待してます。オラクルさん。

ということで、Oracle database 11gのドキュメント内でMacOSXに関して記述されている箇所のリンクを幾つか載せておく。

http://download.oracle.com/docs/cd/B28359_01/server.111/b32009/tuning.htm#insertedID6

http://download.oracle.com/docs/cd/B28359_01/server.111/b32009/toc.htm#BEGIN

http://download.oracle.com/docs/cd/B28359_01/server.111/b32009/strt_stp.htm#CFAHCEFC

http://download.oracle.com/docs/cd/B28359_01/server.111/b32009/appd_mac.htm#UNXAR012

Download : Oracle Database 11g R1 for Linux x86

http://www.oracle.com/technology/software/products/database/index.html?rssid=rss_otn_soft

お〜〜〜〜、Oracle Database 11g R1 for Linux x86がダウンロードできるようになってますね。
早速、ダウンロードして遊んでみますかね．

Oracle Database 11g - Database Resident Connection Pooling (DRCP)

データベースサーバー側でコネクションプールを管理できるようになるんですね。
コネクションプーリングしていないパッケージ製品を利用しているところでは喜ばれそうな機能でしょうね。
実際のところ、いちばん喜ぶのは、コネクションプールを利用していないパッケージ製品を開発・販売している会社さんだったりして。。それはさておき、この機能の詳細は興味のあるところです。

Oracle Database 11g Application Development whitepaperより引用。
Database Resident Connection Pooling (DRCP)

With this new feature, different application processes can share sessions within the
same host machine as well as across multiple host machines. The pool is
maintained on the database server by a new background process.
This feature is useful for applications that cannot be deployed as multithreaded (for
example, PHP applications in an Apache Web server environment) and database
requests are done in a session state independent manner. These applications no
longer have to hold the connections to the database persistently, thereby increasing
the scalability of the database.

Oracle Database 11g - PL/SQL - PL/Scope

これまた、渋い機能追加ですね。
Cscopeならぬ、PL/Scopeですか！。　待望の！？のクロスリファレンスツールの登場のようです。
前のエントリでもかいたプロファイリング機能や、クロスリファレンス機能などは、Oracle SQL Developerでも利用できるんでしょうかねぇ。（別途調べてみますか。。）

そういえば、Oracle7のころ、PL/SQLのクロスリファレンスって取れないのか？　なんてPro*Cで、ディクショナリビューを問い合せてクロスリファレンスもどきをリストするプログラムを試しに作ったことあったっけ。。。
遠い目。。。プログラムが複雑かつ巨大になるとディクショナリビューの検索に時間がかかり過ぎ、重くて使い物にならなかったので没でしたけど。。。（笑）

Oracle Database 11g Application Development whitepaperより引用。

PL/SQL: PL/Scope

PL/Scope allows you to browse PL/SQL source code analogously to the way that
Cscope (see http://cscope.sourceforge.net/) allows you to browse C source code.
You can search for and display all types of definitions, declarations, assignments
and references in the PL/SQL source code. The PL/SQL compiler can optionally
derive the metadata needed to support PL/Scope and store it in the database
catalog. The metadata takes into account the nuances of the language, including
scoping and overloading. You can generate reports (especially hyperlinked HTML
reports) with supplied report generators. PL/Scope supports increased developer
productivity, especially for those who need to maintain someone else's code.

Oracle Database 11g - PL/SQL - Sequences

お〜。これは便利。
PL/SQL内から直接、シーケンスにアクセスできるようになるんですね。
これまでは、PL/SQL内でシーケンスにアクセスするには

select hoge_sequence.nextval into vSeq# from dual;

なんてクエリをPL/SQL内で発行する必要があった訳ですけど、これからはダイレクトに

vSeq# := hoge_sequence.nextval;

と書けるということなんでしょうね。便利です。

眠いので今日はこの辺りで。。。。。

Oracle Database 11g Application Development 　whitepaperより引用。

PL/SQL: Sequences

The sequence generator provides a sequential series of numbers to applications.
The sequence generator is especially useful in multiuser environments for
generating unique sequential numbers such as an employee id without the overhead
of disk I/O or transaction locking.
In the previous release of Oracle Database, when a PL/SQL program needed to get
a value from syntax, it used SQL. This is a usability irritation for PL/SQL
programmers. In Oracle Database 11g, it is now possible to simply use the
pseudocolumns CURRVAL and NEXTVAL in a PL/SQL expression.
Simplifies coding.

Oracle Database 11g - PL/SQL - Hierarchical Profiler

へぇ〜。 PL/SQLのプロファイリングって、今までは、DBMS_PROFILEパッケージを使っていたけど、DBMS_PROFILERパッケージが進化したってことなのか？、それとも、新しいプロファイラーなのかなぁ。以下の概要ではそこまでは解説されていないけど、結果をHTMLで確認できるとか、深い部分までプロファイリングできそうですね。これまでのPL/SQLプロファイリングよりかなり使い勝手は向上しているようで期待してます。

Oracle Database 11g Application Development whitepaperより引用。

PL/SQL: Hierarchical Profiler

The PL/SQL hierarchical profiler reports the dynamic execution profile of your
PL/SQL program, organized by subprogram calls. It accounts for SQL and
PL/SQL execution times separately. Each subprogram-level summary in the
dynamic execution profile includes information such as number of calls to the
subprogram, time spent in the subprogram itself, time spent in the subprogram's
subtree (that is, in its descendent subprograms), and detailed parent-children
information. You can browse the generated HTML reports in any browser. The
browser's navigational capabilities, combined with well chosen links, provide a
powerful way to analyze performance of large applications, improve application
performance, and lower development costs.

Oracle Database 11g - OracleJVM

Oracle Database 11g の OracleJVMでは、Java SE 5をサポートするようですね。
ということは、先日のエントリのようなJava Stored Procedureも Java SE 5対応になるといことですね、ついに。:)

Oracle Database 11g Application Development whitepapaerより引用

Java: OracleJVM Compliance with Java 5

OracleJVM allows reusing Java SE applications and libraries directly in the database
resulting in significant productivity and performance gains. This release supports
Java SE 5 (i.e., compatibility with JDK 1.5), out of the box.

Oracle Database 11g

Oracle Database 11g Launch - New York City - Wednesday, July 11, 2007　なんだそうで・・・。

Oracle11g の登場も間近なんですねぇ。