とあるJargon絡みのおはなし

久々のDatabaseネタですw

先日、ぐるぐる系がほんとうに嫌いなんだなぁ、というアトモスフィアを感じる会話に交ぜてもらいww、
ちょっと思い出したことがあったので書いてみようと思います。
（悪いとか良いとかそういうくくりの話に振るつもりはないので、どの方法をどう使うか、よーく考えて判断しましょうね、ぐらいの気持ちで書いいてますw）

世の中には、意図的にぐるぐる系バッチだけ、index unique scanや、access by rowidだけになることを狙い、統計情報も意図的に設定（e.g.  https://docs.oracle.com/cd/F82042_01/arpls/DBMS_STATS.html#GUID-F993ADFE-85A9-4939-84D1-CC7A6E5C56D2  など）したり、あたまを振り絞って考え抜かれた　ぐるぐる系　の世界があったります。
待機イベントは、DB cpu, db file sequential readが主体で。（私は、やりたいとは思わないけどw）

ところで、

ぐるぐる系ってのは、いわゆるN+1問題に類する処理。
フレームワーク起因でそうなりやすいやつだけでなく、意図的にぐるぐるしちゃうというのもすべて含めたもの。基本的にネガティブな意味で使われていますw。
そんなJargonが存在する現場では、的確に意図が伝わるってのがメリットだったり。。。
N+1がさぁ〜より、ぐるぐるがさぁ〜ってほうが日本語の脳みそにはイメージしやすくてグっと来るw 方は多い感じはしますw。現場でうまれたJargonですのでw　英語3文字略語よりわかりやすくて良い(個人差ありw)

もう一つ、 ぐるぐる系の反対語のJargonって知ってます？

答え: ガツン系

ここまでの用語解説部分はツッコミいれるところではないので、かるくスルーしてくださいませ。 前説ですから。　m(_ _)m

（ちょっと脱線しすぎた感じはするけどもwwww）

ということで（どう言うことだ！w）、ながーーーーーーい前置きはこれぐらいにして本題へ。

ぐるぐる系とガツン系の予習をしていただいたところでww
ちょっとしたサンプルを紹介し、どちらを選ぶかは、アナタしだいです。という意味で、打ちっぱなしというか投げっぱなしの話を書いておこう思います。

今回の例ではストアドプロシージャ化してあります。
ストアドプロシージャでぐるぐるしちゃった場合、ネットワークレイテンシーの影響は受けないのですが繰り返し部分のオーバーヘッド有無の差異は見えるはずです。
SQL文の繰り返しもそうですが、それ以外のオーバーヘッドも積もると山になるわけで。

なお、SQL文がものすごく軽いくて速い、かつ、バッチ専用の別サーバーで実行される場合は繰り返し実行されるロジックだけでなく、サーバー間のネットワークレイテンシーの影響が見過ごせないぐらい（回避不能でもありますが）目立ってくることも思い出してくださいね。
以下の図をイメージしておくと危険な香りを感じ取れるのではないか思います。（特にクラウド上では）

パートの処理時間は記載の時間程度かかるった場合のイメージで書いています。処理時間の延び具合も実際の処理だったり環境でも異なるのであくまで、そんなイメージにしてあります。

普通のぐるぐる系のイメージ（オンプレミスで隣接しているような環境だネットワークレイテンシーは短いのは言うまでもないですが）

普通のぐるぐる系がネットワークレイテンシーの遅い環境に乗せられてしまった場合のイメージ（オンプレミス環境で熟成されたぐるぐる系がクラウドに乗ったらこうなったなんて話は、稀によく聞きますw。しかも自分たちではどうしようもないですよね。こればかりは。）

普通のグルグル系のがネットワークレイテンシーの遅い環境に乗せられてしまった上に、実行計画がぶれて大変なことになってしまったイメージ

最後に、がツン系にして回避したイメージ

この辺り大切なので、試験にでるよ！（ないないw

利用したリリースは以下の通り。

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

差分マージを例ネタに、ぐるぐる系とガツン系の例、そして、ぐるぐる系のループ内で実行されるSQL文の実行計画が最悪の状態でぐるぐるしている例を載せておきますね。

---

準備

以下ディレクトリにcsvファイルを作成してあります。連番で100000行のデータが入っています。

[oracle@localhost ~]$ ll /home/oracle/rowbyrow_or_batch/*.csv
-rw-r--r--. 1 oracle oinstall 588894  1月 16 14:39 /home/oracle/rowbyrow_or_batch/data.csv
[oracle@localhost ~]$ cat /home/oracle/rowbyrow_or_batch/data.csv
1
2
3
4

...中略...

99996
99997
99998
99999
100000
[oracle@localhost ~]$

差分データを外部表で提供するためにディレクトリオブジェクト、対応するディレクトリを作成します。

SCOTT@orclpdb1> create directory rowbyrow_or_batch as '/home/oracle/rowbyrow_or_batch';

ディレクトリが作成されました。

経過: 00:00:00.24
SCOTT@orclpdb1> select directory_name, directory_path from dba_directories where directory_name = upper('rowbyrow_or_batch');

DIRECTORY_NAME                 DIRECTORY_PATH
------------------------------ -------------------------------------------------
ROWBYROW_OR_BATCH              /home/oracle/rowbyrow_or_batch

経過: 00:00:00.09
SCOTT@orclpdb1>

次に外部表を定義します。この時点では該当ディレクトリにcsvファイルは実在しなくても問題ありませんが、実行前には対応するファイルシステムのディレクトとcsvファイルを作成、配置しておく必要はあります。
（外部表作成時にそれらの存在は確認されていないだけです）

SCOTT@orclpdb1> DROP TABLE csv_data PURGE;
SCOTT@orclpdb1> CREATE TABLE csv_data
(
  id NUMBER NOT NULL
)
ORGANIZATION EXTERNAL (
  TYPE ORACLE_LOADER
  DEFAULT DIRECTORY rowbyrow_or_batch
  ACCESS PARAMETERS (
    RECORDS DELIMITED BY NEWLINE
    FIELDS TERMINATED BY '|'
    (
      id
    )
  )
  LOCATION (
    'data.csv'
  )
);

表が作成されました。

経過: 00:00:00.03

SCOTT@orclpdb1> desc csv_data
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID                                        NOT NULL NUMBER

SCOTT@orclpdb1> select min(id),max(id),count(1) from csv_data;

   MIN(ID)    MAX(ID)   COUNT(1)
---------- ---------- ----------
         1     100000     100000

SCOTT@orclpdb1> select count(distinct id) from csv_data;

COUNT(DISTINCTID)
-----------------
           100000

差分データをマージする表を作成してデータを登録しておきます。（統計情報取得も忘れずに）

SCOTT@orclpdb1> CREATE TABLE tmp
(
 ID NUMBER NOT NULL
 , CONSTRAINT pk_tmp PRIMARY KEY (id) USING INDEX
);

表が作成されました。

経過: 00:00:00.17
SCOTT@orclpdb1> BEGIN
  FOR i in 50001..200000 LOOP
    INSERT INTO tmp VALUES(i);
    IF MOD(i,100) = 0 THEN COMMIT; END IF;
  END LOOP;
END;
/

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

経過: 00:00:08.57
SCOTT@orclpdb1> EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT',tabname=>'TMP',cascade=>true, no_invalidate=>false);

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

経過: 00:00:01.86
SCOTT@orclpdb1> select min(id),max(id),count(1) from tmp;

   MIN(ID)    MAX(ID)   COUNT(1)
---------- ---------- ----------
     50001     200000     150000

経過: 00:00:00.03

はい！　準備完了。

上記表へ、csvファイルというか外部表との差分を追加する処理をぐるぐる系と、ガツン系。
そして、おまけで、荒れ狂う実行計画のうるぐるぐる系（ヒントを使って最悪の実行計画にしてるだけですが）w 実行してみましょう。

特に落ちはないですが、打ちっぱなしというか、投げぱなしにしますので、
みなさん、遠ーーーくを見ながら、あーだーこーだビール片手のおつまみにでもして考えてみるのも良いか、と。。

まず、ぐるぐる系から。

SCOTT@orclpdb1> select min(id),max(id),count(id) from tmp;

   MIN(ID)    MAX(ID)  COUNT(ID)
---------- ---------- ----------
     50001     200000     150000

経過: 00:00:00.01
SCOTT@orclpdb1>  exec rowbyrow_proc;

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

経過: 00:00:04.69
SCOTT@orclpdb1> select min(id),max(id),count(id) from tmp;

   MIN(ID)    MAX(ID)  COUNT(ID)
---------- ---------- ----------
         1     200000     200000

経過: 00:00:00.01

次は、ガツン系で。

SCOTT@orclpdb1> select min(id),max(id),count(id) from tmp;

   MIN(ID)    MAX(ID)  COUNT(ID)
---------- ---------- ----------
     50001     200000     150000

経過: 00:00:00.01
SCOTT@orclpdb1> exec allrows_batch_proc;

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

経過: 00:00:00.76
SCOTT@orclpdb1> select min(id),max(id),count(id) from tmp;

   MIN(ID)    MAX(ID)  COUNT(ID)
---------- ---------- ----------
         1     200000     200000

最後に、おまけ。　荒れ狂うぐるぐる系w。（繰り返し実行されるSQL文の実行計画が最悪という設定)
こうなっちゃた経験のある方も少ないないはず。荒れ狂わないように最良の実行計画に固定しちゃう予防策を取っておく方が安全ではあります。

SCOTT@orclpdb1> select min(id),max(id),count(id) from tmp;

   MIN(ID)    MAX(ID)  COUNT(ID)
---------- ---------- ----------
     50001     200000     150000

経過: 00:00:00.18
SCOTT@orclpdb1> exec badboy_rowbyrow_proc;

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

経過: 00:28:02.30
SCOTT@orclpdb1> select min(id),max(id),count(id) from tmp;

   MIN(ID)    MAX(ID)  COUNT(ID)
---------- ---------- ----------
         1     200000     200000

経過: 00:00:00.31

それぞれの実行計画も載せておきますね。

ぐるぐる系のrowbyrow_procプロシージャで実行したSQL文
(実際に3つの方法で確認してますが、monitor/gather_plan_statisticsヒントつけちゃってるのに、autotraceの結果だけのせているのでヒントが気になるかたは外しても問題ないです。多少処理時間は速くなるはずですが。)

MERGE
  /*+
    monitor
    gather_plan_statistics
    index(tmp pk_tmp)
  */
  INTO tmp
USING (
  SELECT
    :l_id AS id
  FROM
    dual
) diff_data
ON
  ( tmp.id = diff_data.id )
WHEN NOT MATCHED THEN
  INSERT VALUES
  (
    diff_data.id
  )
;

SCOTT@orclpdb1> l
  1  MERGE
  2    /*+
  3      monitor
  4      gather_plan_statistics
  5      index(tmp pk_tmp)
  6    */
  7    INTO tmp
  8  USING (
  9    SELECT
 10      :l_id AS id
 11    FROM
 12      dual
 13  ) diff_data
 14  ON
 15    ( tmp.id = diff_data.id )
 16  WHEN NOT MATCHED THEN
 17    INSERT VALUES
 18    (
 19      diff_data.id
 20*   )
SCOTT@orclpdb1> /

1行がマージされました。

経過: 00:00:00.02

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

-------------------------------------------------------------------------------
| Id  | Operation            | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | MERGE STATEMENT      |        |     1 |    23 |     3   (0)| 00:00:01 |
|   1 |  MERGE               | TMP    |       |       |            |          |
|   2 |   VIEW               |        |       |       |            |          |
|   3 |    NESTED LOOPS OUTER|        |     1 |    23 |     3   (0)| 00:00:01 |
|   4 |     VIEW             |        |     1 |    18 |     3   (0)| 00:00:01 |
|   5 |      FAST DUAL       |        |     1 |       |     3   (0)| 00:00:01 |
|*  6 |     INDEX UNIQUE SCAN| PK_TMP |     1 |     5 |     0   (0)| 00:00:01 |
-------------------------------------------------------------------------------

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

   6 - access("TMP"."ID"(+)=TO_NUMBER("DIFF_DATA"."ID"))

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

ガツン系（allrows_batch_procプロシージャで実行）

MERGE
  /*+
    monitor
    gather_plan_statistics
    index_ffs(tmp pk_tmp)
  */
  INTO tmp
  USING (
    SELECT
      id
    FROM
      csv_data
  ) diff_data
  ON ( tmp.id = diff_data.id )
WHEN NOT MATCHED THEN
  INSERT VALUES
  (
    diff_data.id
  )
 ;

SCOTT@orclpdb1>
  1  MERGE
  2    /*+
  3      monitor
  4      gather_plan_statistics
  5      index_ffs(tmp pk_tmp)
  6    */
  7    INTO tmp
  8    USING (
  9      SELECT
 10        id
 11      FROM
 12        csv_data
 13    ) diff_data
 14    ON ( tmp.id = diff_data.id )
 15  WHEN NOT MATCHED THEN
 16    INSERT VALUES
 17    (
 18      diff_data.id
 19*   )
SCOTT@orclpdb1> /

50000行がマージされました。

経過: 00:00:00.60

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

------------------------------------------------------------------------------------------
| Id  | Operation                     | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | MERGE STATEMENT               |          |   100K|  1757K|   289  (15)| 00:00:01 |
|   1 |  MERGE                        | TMP      |       |       |            |          |
|   2 |   VIEW                        |          |       |       |            |          |
|*  3 |    HASH JOIN OUTER            |          |   100K|   976K|   289  (15)| 00:00:01 |
|*  4 |     EXTERNAL TABLE ACCESS FULL| CSV_DATA |   100K|   488K|    57  (20)| 00:00:01 |
|   5 |     INDEX FAST FULL SCAN      | PK_TMP   |   150K|   732K|   214   (6)| 00:00:01 |
------------------------------------------------------------------------------------------

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

   3 - access("TMP"."ID"(+)="ID")
   4 - filter(SYS_OP_XTNN("CSV_DATA"."ID"))

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

荒れ狂うぐるぐる系badboy_rowbyrow_procプロシージャで実行したSQL文
計測回数が少ないので参考程度ですが、荒れ狂ってない場合の同一SQLと比較して、4倍も遅い状況。（一回当たりは　0.08秒でも積み上がると笑えないですね）

MERGE
  /*+
    monitor
    gather_plan_statistics
    index_ffs(tmp pk_tmp)
  */
  INTO tmp
USING (
  SELECT
    :l_id AS id
  FROM
    dual
) diff_data
ON
  ( tmp.id = diff_data.id )
WHEN NOT MATCHED THEN
  INSERT VALUES
  (
    diff_data.id
  )
;

SCOTT@orclpdb1> l
  1  MERGE
  2    /*+
  3      monitor
  4      gather_plan_statistics
  5      index_ffs(tmp pk_tmp)
  6    */
  7    INTO tmp
  8  USING (
  9    SELECT
 10      :l_id AS id
 11    FROM
 12      dual
 13  ) diff_data
 14  ON
 15    ( tmp.id = diff_data.id )
 16  WHEN NOT MATCHED THEN
 17    INSERT VALUES
 18    (
 19      diff_data.id
 20*   )
SCOTT@orclpdb1> /

1行がマージされました。

経過: 00:00:00.08

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

----------------------------------------------------------------------------------
| Id  | Operation               | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | MERGE STATEMENT         |        |     1 |    23 |   226  (10)| 00:00:01 |
|   1 |  MERGE                  | TMP    |       |       |            |          |
|   2 |   VIEW                  |        |       |       |            |          |
|*  3 |    HASH JOIN OUTER      |        |     1 |    23 |   226  (10)| 00:00:01 |
|   4 |     VIEW                |        |     1 |    18 |     3   (0)| 00:00:01 |
|   5 |      FAST DUAL          |        |     1 |       |     3   (0)| 00:00:01 |
|   6 |     INDEX FAST FULL SCAN| PK_TMP |   150K|   732K|   214   (6)| 00:00:01 |
----------------------------------------------------------------------------------

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

   3 - access("TMP"."ID"(+)=TO_NUMBER("DIFF_DATA"."ID"))

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

本日利用したコードは以下の通り（csvファイルを作成したコードは略）

create directory rowbyrow_or_batch as '/home/oracle/rowbyrow_or_batch';
select directory_name, directory_path from dba_directories where directory_name = upper('rowbyrow_or_batch');

DROP TABLE csv_data PURGE;
CREATE TABLE csv_data
(
  id NUMBER NOT NULL
)
ORGANIZATION EXTERNAL (
  TYPE ORACLE_LOADER
  DEFAULT DIRECTORY rowbyrow_or_batch
  ACCESS PARAMETERS (
    RECORDS DELIMITED BY NEWLINE
    FIELDS TERMINATED BY ','
    (
      id
    )
  )
  LOCATION (
    'data.csv'
  )
);

DROP TABLE tmp PURGE;
CREATE TABLE tmp
(
 ID NUMBER NOT NULL
 , CONSTRAINT pk_tmp PRIMARY KEY (id) USING INDEX
);

BEGIN
  FOR i in 50001..200000 LOOP
    INSERT INTO tmp VALUES(i);
    IF MOD(i,100) = 0 THEN COMMIT; END IF;
  END LOOP;
END;
/

EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT',tabname=>'TMP',cascade=>true, no_invalidate=>false);


CREATE OR REPLACE PROCEDURE allrows_batch_proc AS
BEGIN
  MERGE
    /*+
      monitor
      gather_plan_statistics
      index_ffs(tmp pk_tmp)
    */
    INTO tmp
    USING (
      SELECT
        id
      FROM
        csv_data
    ) diff_data
    ON ( tmp.id = diff_data.id )
  WHEN NOT MATCHED THEN
    INSERT VALUES
    (
      diff_data.id
    );
  COMMIT;
EXCEPTION
  WHEN OTHERS THEN
    ROLLBACK;
    RAISE;
END;
/

CREATE OR REPLACE PROCEDURE rowbyrow_proc AS
  C_DIR CONSTANT VARCHAR2(30) := 'ROWBYROW_OR_BATCH';
  C_FILE_NAME CONSTANT VARCHAR2(30) := 'data.csv';
  C_BUFFERSIZE CONSTANT BINARY_INTEGER := 32767;
  C_OPENMODE CONSTANT VARCHAR2(2) := 'r';
  fileHandle UTL_FILE.FILE_TYPE;
  line VARCHAR2(32767);
  l_id NUMBER;
  rowcount NUMBER;
BEGIN
  fileHandle := UTL_FILE.FOPEN(C_DIR, C_FILE_NAME, C_OPENMODE, C_BUFFERSIZE);
  BEGIN
    LOOP
      UTL_FILE.GET_LINE(fileHandle, line, C_BUFFERSIZE);
      l_id := TO_NUMBER(line);

      MERGE
        /*+
          monitor
          gather_plan_statistics
          index(tmp pk_tmp)
        */
        INTO tmp
      USING (
        SELECT
          l_id AS id
        FROM
          dual
      ) diff_data
      ON
        ( tmp.id = diff_data.id )
      WHEN NOT MATCHED THEN
        INSERT VALUES
        (
          diff_data.id
        );

      rowcount := rowcount + 1;
       IF MOD(rowcount, 100) = 0 THEN
         COMMIT;
         NULL;
       END IF;
    END LOOP;

  EXCEPTION
    WHEN NO_DATA_FOUND THEN  /* EOF */
      NULL;
  END;
  COMMIT;
  UTL_FILE.FCLOSE(fileHandle);
EXCEPTION
  WHEN OTHERS THEN
    ROLLBACK;
    IF UTL_FILE.IS_OPEN(fileHandle) THEN
      UTL_FILE.FCLOSE(fileHandle);
    END IF;
    RAISE;
END;
/

CREATE OR REPLACE PROCEDURE badboy_rowbyrow_proc AS
  C_DIR CONSTANT VARCHAR2(30) := 'ROWBYROW_OR_BATCH';
  C_FILE_NAME CONSTANT VARCHAR2(30) := 'data.csv';
  C_BUFFERSIZE CONSTANT BINARY_INTEGER := 32767;
  C_OPENMODE CONSTANT VARCHAR2(2) := 'r';
  fileHandle UTL_FILE.FILE_TYPE;
  line VARCHAR2(32767);
  l_id NUMBER;
  rowcount NUMBER;
BEGIN
  fileHandle := UTL_FILE.FOPEN(C_DIR, C_FILE_NAME, C_OPENMODE, C_BUFFERSIZE);
  BEGIN
    LOOP
      UTL_FILE.GET_LINE(fileHandle, line, C_BUFFERSIZE);
      l_id := TO_NUMBER(line);

      MERGE
        /*+
          monitor
          gather_plan_statistics
          index_ffs(tmp pk_tmp)
        */
        INTO tmp
      USING (
        SELECT
          l_id AS id
        FROM
          dual
      ) diff_data
      ON
        ( tmp.id = diff_data.id )
      WHEN NOT MATCHED THEN
        INSERT VALUES
        (
          diff_data.id
        );

      rowcount := rowcount + 1;
       IF MOD(rowcount, 100) = 0 THEN
         COMMIT;
         NULL;
       END IF;
    END LOOP;

  EXCEPTION
    WHEN NO_DATA_FOUND THEN  /* EOF */
      NULL;
  END;
  COMMIT;
  UTL_FILE.FCLOSE(fileHandle);
EXCEPTION
  WHEN OTHERS THEN
    ROLLBACK;
    IF UTL_FILE.IS_OPEN(fileHandle) THEN
      UTL_FILE.FCLOSE(fileHandle);
    END IF;
    RAISE;
END;
/

Enjoy SQL!

今年は、桜吹雪を2回も見ることができたのですが、おそらく、20年ぶりw
では、また。

OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:) その３

---

前回までのMac De Oracle


OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:)

OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:)　その２

---

ということで、続きで〜〜すっ。

こんな表定義で

orcl@SCOTT> desc tab01
 Name      Null?    Type
 --------- -------- --------
 FOO                NUMBER
 BAR                NUMBER
 HOGE      NOT NULL CHAR(2)
 ID        NOT NULL NUMBER

こんな索引があって

****** Index column info : tab01 ******

INDEX_NAME                     COLUMN_NAME                    DESC
------------------------------ ------------------------------ ----
IX1_TAB01                      FOO                            ASC

IX2_TAB01                      BAR                            ASC
                               FOO                            ASC

IX3_TAB01                      ID                             ASC
                               FOO                            ASC

IX4_TAB01                      ID                             ASC
                               BAR                            ASC
                               FOO                            ASC

PK_TAB01                       ID                             ASC

こんなデータで

orcl@SCOTT> set null [NULL]
orcl@SCOTT> select * from tab01

       FOO        BAR HO         ID
---------- ---------- -- ----------
[NULL]     [NULL]     **          1
         1 [NULL]     **          2
[NULL]              1 **          3
         1          1 **          4

2列の複合索引、どちらの列もNULLだと、やはり、NULLは索引に含まれないので　IS NULL検索だと索引は利用されないですよねぇ〜。このような状態ではヒントで索引利用を強制利用させようとしても無理です。

orcl@SCOTT> r
  1  select
  2    /*+
  3      gather_plan_statistics
  4      index(tab01 ix2_tab01)
  5      no_index(tab01 ix4_tab01)
  6      no_index(tab01 ix3_tab01)
  7    */
  8    *
  9  from
 10    tab01
 11  where
 12    foo is null
 13*   and bar is null
　　　　　
       FOO        BAR HO         ID
---------- ---------- -- ----------
[NULL]     [NULL]     **          1

・・・略・・・
-------------------------------------------------------------------------------------
| Id  | Operation         | Name  | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |      1 |        |      1 |00:00:00.01 |       8 |
|*  1 |  TABLE ACCESS FULL| TAB01 |      1 |      1 |      1 |00:00:00.01 |       8 |
-------------------------------------------------------------------------------------

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

   1 - filter(("FOO" IS NULL AND "BAR" IS NULL))

でも、NOT NUL制約の列が1列でも含まれている索引であればNULLは索引に含まれます。（前回までの復習も兼ねた確認）
第1列がWHERE句で記述されていないので索引スキップスキャンになっていますが.....IS NULL検索を索引アクセスだけで行っているのがよく分かる例の一つです：）

orcl@SCOTT> r
  1  select
  2    /*+
  3      gather_plan_statistics
  4    */
  5    *
  6  from
  7    tab01
  8  where
  9    foo is null
 10*   and bar is null

       FOO        BAR HO         ID
---------- ---------- -- ----------
[NULL]     [NULL]     **          1

・・・略・・・
--------------------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
--------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |           |      1 |        |      1 |00:00:00.01 |       3 |      1 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TAB01     |      1 |      1 |      1 |00:00:00.01 |       3 |      1 |
|*  2 |   INDEX SKIP SCAN                   | IX4_TAB01 |      1 |      1 |      1 |00:00:00.01 |       2 |      1 |
--------------------------------------------------------------------------------------------------------------------

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

   2 - access("BAR" IS NULL AND "FOO" IS NULL)
       filter(("FOO" IS NULL AND "BAR" IS NULL))

最後にもう少しわかりやすい例を。

SQL文を少々書き換えてIndex Only Scanになるようにしました。索引にNULLが含まれていないと索引だけのアクセスで済むわけがないわけで、これ以上わかりやすい例はないと思います：）

まず、索引が利用できない例から。
FOO列とBAR列だけの複合索引をヒントで強制利用させようとしていますが、この索引は２列ともnullableなので２列をIS NULL検索しても索引が利用されません！
全ての列がNULLである場合、キーエントリーは索引に作成されない。単一列でも複合索引でも同じであることが確認できます。

orcl@SCOTT> r
  1  select
  2    /*+
  3      gather_plan_statistics
  4      index(tab01 ix2_tab01)
  5      no_index(tab01 ix4_tab01)
  6      no_index(tab01 ix3_tab01)
  7    */
  8    *
  9  from
 10    tab01
 11  where
 12    foo is null
 13*   and bar is null

       FOO        BAR HO         ID
---------- ---------- -- ----------
[NULL]     [NULL]     **          1

・・・略・・・
-------------------------------------------------------------------------------------
| Id  | Operation         | Name  | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |      1 |        |      1 |00:00:00.01 |       8 |
|*  1 |  TABLE ACCESS FULL| TAB01 |      1 |      1 |      1 |00:00:00.01 |       8 |
-------------------------------------------------------------------------------------

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

   1 - filter(("FOO" IS NULL AND "BAR" IS NULL))

おっと、
大切なのを忘れてました。

FOO列(nullable(、BAR列(nullable)の複合索引を　IS NOT NULL AND IS NULLで検索した場合はどうなるか？
答えは以下の通り。IS NULL と　IS NOT NULLの組み合わせでも、索引が利用されます。:)

BAR IS NULLで範囲検索しFOO IS NOT NULLでフィルタリングしています。 NULLが含まれていないと不可能な索引レンジスキャンと索引読み時のフィルタリング！

orcl@SCOTT> r
  1  select
  2    /*+
  3      gather_plan_statistics
  4      no_index(tab01 ix3_tab01)
  5      no_index(tab01 ix4_tab01)
  6    */
  7    foo
  8    , bar
  9  from
 10    tab01
 11  where
 12    foo is not null
 13*   and bar is null

       FOO        BAR
---------- ----------
         1 [NULL]

・・・略・・・
-------------------------------------------------------------------------------------------------
| Id  | Operation        | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |           |      1 |        |      1 |00:00:00.02 |       1 |      1 |
|*  1 |  INDEX RANGE SCAN| IX2_TAB01 |      1 |      1 |      1 |00:00:00.02 |       1 |      1 |
-------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("BAR" IS NULL)
       filter("FOO" IS NOT NULL)

その逆も！

orcl@SCOTT> r
  1  select
  2    /*+
  3      gather_plan_statistics
  4      no_index(tab01 ix3_tab01)
  5      no_index(tab01 ix4_tab01)
  6    */
  7    foo
  8    , bar
  9  from
 10    tab01
 11  where
 12    foo is null
 13*   and bar is not null

       FOO        BAR
---------- ----------
[NULL]              1

・・・略・・・
----------------------------------------------------------------------------------------
| Id  | Operation        | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |           |      1 |        |      1 |00:00:00.01 |       2 |
|*  1 |  INDEX SKIP SCAN | IX2_TAB01 |      1 |      1 |      1 |00:00:00.01 |       2 |
----------------------------------------------------------------------------------------

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

   1 - access("FOO" IS NULL)
       filter(("FOO" IS NULL AND "BAR" IS NOT NULL))

もういっちょ！
２列とものnullableな索引だとindex fast full scanにはできないけど、index full scanにはできるんですよ〜。

orcl@SCOTT7gt; r
  1  select
  2    /*+
  3      gather_plan_statistics
  4      no_index(tab01 ix3_tab01)
  5      no_index(tab01 ix4_tab01)
  6    */
  7    foo
  8    , bar
  9  from
 10    tab01
 11  where
 12    foo is not null
 13*   and bar is not null

       FOO        BAR
---------- ----------
         1          1

・・・略・・・
----------------------------------------------------------------------------------------
| Id  | Operation        | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |           |      1 |        |      1 |00:00:00.01 |       2 |
|*  1 |  INDEX FULL SCAN | IX2_TAB01 |      1 |      1 |      1 |00:00:00.01 |       2 |
----------------------------------------------------------------------------------------

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

   1 - filter(("FOO" IS NOT NULL AND "BAR" IS NOT NULL))

Note
-----
   - statistics feedback used for this statement

後に、NOT NULL列が含まれる索引なら index fast full scanでもできるはず！
独り言；index only scan+index fast full scanなんてのもセグメントサイズが小さければ物理読み込み量削減には効果があるんですよねぇ〜　;-)

orcl@SCOTT> r
  1  select
  2    /*+
  3      gather_plan_statistics
  4      no_index(tab01 ix3_tab01)
  5      index_ffs(tab01 ix4_tab01)
  6      no_index(tab01 ix2_tab01)
  7    */
  8    foo
  9    , bar
 10  from
 11    tab01
 12  where
 13    foo is not null
 14*   and bar is not null

       FOO        BAR
---------- ----------
         1          1

・・・略・・・
-----------------------------------------------------------------------------------------------------
| Id  | Operation            | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |           |      1 |        |      1 |00:00:00.03 |       4 |      1 |
|*  1 |  INDEX FAST FULL SCAN| IX4_TAB01 |      1 |      1 |      1 |00:00:00.03 |       4 |      1 |
-----------------------------------------------------------------------------------------------------

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

   1 - filter(("FOO" IS NOT NULL AND "BAR" IS NOT NULL))

オラクルの索引にNULLは絶対含まれない、というのは都市伝説！　
IS NOT NULLは索引使えないとかIS NULLは索引使えないというというのも違うんですよね。　

OracleのB*Tree索引では、索引に含まれる全列がNULLの場合以外はNULLが含まれてまっす！　というのが正しいですよね！？

この手の問題でピンチになったら、思い出してみてください ;)
USE THE INDEX ONLY SCAN, LUKE! w

OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:) その２

OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:)
の続きです。

念のために、もう一つの主役NULL登場してもらいましょう。

IX1_TAB01索引はNullableなFOO列だけの索引なので、このタイプの索引ではNULLは索引に格納されることはありません。
いくらヒントで索引を指定しても索引にはNULLは格納されていないので全表走査になるはず。

注）：索引が多いので意図した索引を利用するようにヒントで固定しています
例２）FOO IS NULL　で検索

orcl@SCOTT> r
  1  SELECT
  2  	/*+
  3  		gather_plan_statistics
  4  		index(tab01 ix1_tab01)
  5  		no_index(tab01 ix3_tab01)
  6  		no_index(tab01 ix4_tab01)
  7  	*/
  8  	*
  9  FROM
 10  	tab01
 11  WHERE
 12* 	foo IS NULL


       FOO        BAR HO         ID
---------- ---------- -- ----------
[NULL]     [NULL]     **          1
[NULL]              1 **          3


ーーー中略ーーー
Plan hash value: 2044041692

-------------------------------------------------------------------------------------
| Id  | Operation         | Name  | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |      1 |        |      2 |00:00:00.01 |       8 |
|*  1 |  TABLE ACCESS FULL| TAB01 |      1 |      2 |      2 |00:00:00.01 |       8 |
-------------------------------------------------------------------------------------

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

   1 - filter("FOO" IS NULL)

想定通り。NULLは格納されていないので索引が利用できず全表走査になっています。
索引からROWIDを取得できないので全表走査してフィルタリングしている箇所がポイントです。

OracleのB*Tree索引にはNULLが入らない都市伝説の始まりはここだったんじゃないか？　とい言っている方がいたのですが、ここだけの話が広まってしまい

OracleのB*Tree索引にはNULLは絶対格納されない。

という都市伝説になってしまったのだろうと。。確かに入ってないですからねー。 (^^;;;

では、NULLが索引に含まれる一例を見てみましょう。

例３）ID列（NOT NULL)とFOO列（Nullable）で作成した複合索引を ID=1 AND FOO IS NULLで検索
注）：索引が多いので意図した索引を利用するようにヒントで固定しています

Predicate Informationセクションのaccess predicateを見るとわかると思いますが、ID=1 AND FOO IS NULLで索引をアクセスしています。
NULLが索引に含まれていない場合はこのような状況にはなりません。　
複合索引では1列でもNOT NULL制約がり他の列がNullableである場合、NULLは格納されます。

NULLは格納されることもあるんです。マニュアル上の表現は少々わかりにくいとは思いますが、このような状況を指しています。

orcl@SCOTT> r
  1  SELECT
  2  	/*+
  3  		gather_plan_statistics
  4  		no_index(tab01 ix1_tab01)
  5  		index(tab01 ix3_tab01)
  6  		no_index(tab01 ix4_tab01)
  7  	*/
  8  	*
  9  FROM
 10  	tab01
 11  WHERE
 12  	id = 1
 13* 	AND foo IS NULL

       FOO        BAR HO         ID
---------- ---------- -- ----------
[NULL]     [NULL]     **          1

ーーー中略ーーー
Plan hash value: 2558346564

-----------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |           |      1 |        |      1 |00:00:00.01 |       3 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TAB01     |      1 |      1 |      1 |00:00:00.01 |       3 |
|*  2 |   INDEX RANGE SCAN                  | IX3_TAB01 |      1 |      1 |      1 |00:00:00.01 |       2 |
-----------------------------------------------------------------------------------------------------------

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

   2 - access("ID"=1 AND "FOO" IS NULL)

少し寄り道。

そういえば、偶になんですが、IS NOT NULLだと索引使うことはないという都市伝説も聞いたことがあります。
それも都市伝説なんですよね。
次の例は、その都市伝説を覆す一例を。

例４）FOO IS NOT NULL　で検索

IX1_TAB01索引は、NullableなFOO列だけの索引です。これまでの検証でこのタイプの索引にはNULLが格納されていないことは確認できると思います。
ようするに、NULLじゃないものは、まるっととズバッと索引に含まれているはずでっす！
なので、FOO IS NOT NULLという検索条件だと索引を使ってくれます。

このような性質を知っているとチューニングに役立つんですよ。
（この例のようなチューニング方法を使ったことは過去数度あるんですよ、苦肉の策でしたけどw　NULLの数が非常に多い場合、この手の索引のセグメントサイズは非常に小さくなります(索引に格納されるエントリそのものがNULLを除くと非常に少ない場合）。その性質を利用したチューニング法もあるんです。）

余談NOTE:
INDEX FAST FULL SCANにならない理由:索引にNOT NULL制約の列が少なくとも１列あること、という前提条件を満たせていないからです。チューニングや設計時に必要な知識なので覚えておくと何かの時に役に立つと思います：）

注）：索引が多いので意図した索引を利用するようにヒントで固定しています

orcl@SCOTT> r
  1  SELECT
  2  	/*+
  3  		gather_plan_statistics
  4  		index(tab01 ix1_tab01)
  5  		no_index(tab01 ix3_tab01)
  6  		no_index(tab01 ix4_tab01)
  7  	*/
  8  	*
  9  FROM
 10  	tab01
 11  WHERE
 12* 	foo IS NOT NULL


       FOO        BAR HO         ID
---------- ---------- -- ----------
         1 [NULL]     **          2
         1          1 **          4

ーーー中略ーーー
Plan hash value: 2840602802

-----------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |           |      1 |        |      2 |00:00:00.01 |       4 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TAB01     |      1 |      2 |      2 |00:00:00.01 |       4 |
|*  2 |   INDEX FULL SCAN                   | IX1_TAB01 |      1 |      2 |      2 |00:00:00.01 |       2 |
-----------------------------------------------------------------------------------------------------------

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

   2 - filter("FOO" IS NOT NULL)

恐竜博とか＊＊博ってやつは、最後のショップがメインで博のほうはおまけなんじゃないかと最近思ってるw　子供達の目が活き活きしているのはショップに入ってからだ！w

次回へつづく。

OracleのB*Tree索引にはNULLが含まれる場合があるんです！ - その性質を使ってチューニングすることもあるよ:)

先日、OracleのB*Tree索引には絶対にNULLが含まれないって思い込んでる人が意外にいるよね〜とか。
OracleのB*Tree索引には絶対NULLが含まれないって都市伝説があるのはなんでだろう。
Oracle® Database概要12cリリース1 (12.1) - 一意索引と非一意索引

みたいなことが話題になって、
ある一人が、「だよね〜、ダンプ見れば含まれてるのわかります。」って言ってて、それ、ふつ〜の人は見ないからw

と思いつつ、私の周りには、やはり、変態が多いことに改めて気づいた次第です。：）　はい。

で、
変態じゃない、ごく一般的なエンジニアの方々（ブロックダンプを華麗かつ自然にキメちゃわない方々）向けに、

OracleのB*Tree索引にNULLが含まれているか、NULLが含まれていないかの簡単な確認方法をお伝えしなければ！w

ということで、数回にわけて書いておこうかと思ってます。（予定は未定w）

（実は、このネタとほぼ同じことを１年前ぐらい前に、ローカルかつクローズドな勉強会？、でも使ってました。　最近、やってないみたいですけど）

環境は最近の定番　Oracle Database 12c R1 EE

orcl@SCOTT> select banner from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
PL/SQL Release 12.1.0.2.0 - Production
CORE	12.1.0.2.0	Production
TNS for Linux: Version 12.1.0.2.0 - Production
NLSRTL Version 12.1.0.2.0 - Production

SCOTTスキーマに以下のような表と索引を作成し少ないですが、データを登録
今回の主役は索引とNULLなのでデータ量少なくても必要なパターンが登録できていれば十分です。
（データ量を増やせばチューニングのお題の元ネタにもなると思います。）

orcl@SCOTT> create table tab01 (foo number, bar number, hoge char(2) not null,id number not null);

Table created.

orcl@SCOTT> insert into tab01 values(null,null,'**',1);

1 row created.

orcl@SCOTT> insert into tab01 values(1,null,'**',2);

1 row created.

orcl@SCOTT> insert into tab01 values(null,1,'**',3);

1 row created.

orcl@SCOTT> insert into tab01 values(1,1,'**',4);

1 row created.

orcl@SCOTT> commit;

Commit complete.

orcl@SCOTT> alter table tab01 add constraint pk_tab01 primary key(id) using index;

Table altered.

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

PL/SQL procedure successfully completed.

orcl@SCOTT> create index ix1_tab01 on tab01 (foo);

Index created.

orcl@SCOTT> create index ix2_tab01 on tab01 (bar,foo);

Index created.

orcl@SCOTT> create index ix3_tab01 on tab01(id,foo);

Index created.

orcl@SCOTT> create index ix4_tab01 on tab01(id,bar,foo);

Index created.

FOOとBAR列はNullableにしています

orcl@SCOTT> desc tab01
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 FOO                                                NUMBER
 BAR                                                NUMBER
 HOGE                                      NOT NULL CHAR(2)
 ID                                        NOT NULL NUMBER

主演の索引たち

NULLが索引でどう扱われるかを確認するため、事前作成の索引をたくさん用意してしました。後から作るの面倒なのでw
これだけ類似索引も含めて多数の索引があると確認時に意図した索引が利用されない可能性も高いため、検証では内容に合わせて利用する索引をヒントで指定することにします。

ちなみに、
普通の環境でこんなに索引があったら、アンチパターン：インデックスショットガンですからね。ご注意ください:) たまにこのような環境に遭遇することはありますが。。。

IX1_TAB01はnullableなFOO列だけの単一列索引
IX2_TAB01はnullableなBAR列とFOO列からなる複合索引
IX3_TAB01とTX4_TAB01は上記の列に加え主キー列のID列を第1キーとする複合索引

としてあります。

orcl@SCOTT> break on table_name on index_name skip 1
orcl@SCOTT> select table_name,index_name,column_name from user_ind_columns where table_name='TAB01' order by table_name,index_name,column_position;

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME
------------------------------ ------------------------------ ------------------------------
TAB01                          IX1_TAB01                      FOO

                               IX2_TAB01                      BAR
                                                              FOO

                               IX3_TAB01                      ID
                                                              FOO

                               IX4_TAB01                      ID
                                                              BAR
                                                              FOO

                               PK_TAB01                       ID

登録したデータは以下の通り
NULLは索引とともに今回の主役なので、どこがNULLになっているかメモしておいてくださいませ。

orcl@SCOTT> set null [NULL]
orcl@SCOTT> select * from tab01 order by id;

       FOO        BAR HO         ID
---------- ---------- -- ----------
[NULL]     [NULL]     **          1
         1 [NULL]     **          2
[NULL]              1 **          3
         1          1 **          4

さて、索引にNULLが含まれているか、いないか、どうやって確認すると思います？　ブロックダンプを華麗にキメきめる以外の方法でw

SQLチューニングをしたことがある方なら一般的に利用してい（と思ってる）機能で簡単に確認できちゃうんですよ。これが。

SQL*Plusのautotraceや、explain plan それに、DBMS_XPLAN.DISPLAY*　なファンクションでも確認できます。
SQLclはautotraceにはまだ未対応となっているようですが、それ以外の方法ならはできるようです。
（今回はSQL*Plusを使い、dbms_xplan.display_cursor(format=>'ALLSTATS LAST'))で確認します）

どうやって、どの部分で確認するのか？　
autottraceやDBMS_XPLAN.DISPLAY*などでリストされるpredicate information部分のaccess/filter predicate部分で確認できるんです！

例１）FOO = 1　で検索した例

注）：索引が多いので意図した索引を利用するようにヒントで固定しています

おわかりでしょうか？
Predicate Infomation部分から、Id=2のINDEX RANGE SCANで　IX1_TAB01索引を　FOO=1でアクセスしていることが読み取れますよね？
つまり、1 という値が索引に含まれている（含まれる）からaccess pathとしてIX1_TAB01索引を参照しているわけです。

orcl@SCOTT> r
  1  SELECT
  2  	/*+
  3  		gather_plan_statistics
  4  		index(tab01 ix1_tab01)
  5  	*/
  6  	*
  7  FROM
  8  	tab01
  9  WHERE
 10* 	foo = 1

       FOO        BAR HO         ID
---------- ---------- -- ----------
         1 [NULL]     **          2
         1          1 **          4

orcl@SCOTT> select * from table(dbms_xplan.display_cursor(format=>'ALLSTATS LAST'));

ーーー中略ーーー

Plan hash value: 3795960549

-----------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |           |      1 |        |      2 |00:00:00.01 |       4 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TAB01     |      1 |      2 |      2 |00:00:00.01 |       4 |
|*  2 |   INDEX RANGE SCAN                  | IX1_TAB01 |      1 |      2 |      2 |00:00:00.01 |       2 |
-----------------------------------------------------------------------------------------------------------

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

   2 - access("FOO"=1)

ということで、今日は馬事公苑の散歩は気持ちいいよ〜。

次回へつづく。