Mac De Oracle: 2024年12月

2026年6月
日	月	火	水	木	金	土
	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
28	29	30

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

ということで、（どういうことだ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

投稿日時 2024年12月27日 (金) 12時00分 Oracle, チューニング, FAQ, SQL, Oracle Database 11g, Oracle Database 11g Release 2, Oracle Database 12c release 1, パフォーマンス, Oracle Database 12c Release 2, Oracle Database Cloud Service, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c, Oracle Database 23c Free Developer Release | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#25 - フリー動画と合わせて完成 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
25日目の窓を開けました！

BarageBandではなくて、iMovieネタになっちゃいますが。
細かい動画作業ログは動画にて。（いつもの pixabay と Adobe Stock の素材を組み合わせて使う。。完成版はどうなりますか....）

完成版!
Neko Mimi Loops 2024 / N + 1 Loops

Enjoy DTM, GarageBand and iMovie

I wish you a Merry Christmas! and a Happy New Year!
C-YA! Next Articles.

投稿日時 2024年12月25日 (水) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#24 - Version.1とVersion.2の比較！ Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
24日目の窓を開けました！

完成したので、Version.1 と Version.2 の比較！〜

Before ( Ver.1 - 2023年 ) : Neco Mimi Loops / N + 1 Loops

After ( Ver.2 ) : Neko Mimi Loops 2024 / N + 1 Loops

結構変わったのでヨシとするw Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024最終日の明日は、フリー動画（ pixabay )で見つけた動画やAdobe Stock（有料）の商用でも利用可能な動画と合わせて完成予定:)

Enjoy DTM, GarageBand and iMovie

では、また明日

投稿日時 2024年12月24日 (火) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#23 - 完成間近、各トラックのバランスとか音色調整とか　その3 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
23日目の窓を開けました！

最後にスクラッチ、ネコの鳴き声トラックの音色等を調整して完成！！！！　やった〜〜
今日調整したトラックは以下。トラックにLoop名称を利用し "トラック番号.Loop名称"にしてあるので参考にしていただければ。

07.Sunday Haze Scratch Synth Pad
08.Crate Digging Scratch FX
09.Vinyl Scratch 01
10.Scratchy Wobble Bass
14.Communication Static
15.Cat Meow 05
16.Catch Me Chop Vox
17.True Heart Chop Vox
18.Choppy Vox Lead 04
19.Around Midnight Vox Melody 01.61
20.Around Midnight Vox Melody 02

細かい作業の様子は以下の動画にて。明日は、Ver.1と今回色々変えまくったVer.2の聴き比べでも。
BGM : City Lights Loops / N + 1 Loops, Heatbeats Loops / N + 1 Loops

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月23日 (月) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#22 - 完成間近、各トラックのバランスとか音色調整とか　その2 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024 22日目の窓を開けました！

レイヤー部分とかイントロの一部のシンセサイザーの音色やエコーなどを調整中
今日調整したトラックは以下。トラックにLoop名称を利用し "トラック番号.Loop名称"にしてあるので参考にしていただければ。

05.Swelling Sub Bass
06.Transport Stop Synth
11.Glow Scratchy Pad
21.Break Free Choir Pad
22.Break Free Choir Pad.1
23.Ride With Me Synth Pluck
24.Hidden Origins 01
25.Night Walk Echo Plucks
26.Night Walk Echo Plucks +12
27.Night Shift Layers
28.Night Vision Synth Layers
29.Nocturnal Phase Synth 01
30.Shine Bright Arpeggio

ちなみに、よく使っているPlug-inは、Space Desinger, Stereo Spread, Compressor, EQあたりですね。たまに、Distortion も使ったりして音のザラつき感をSaxやブラス系のLoop持たせたりすることもあります。

細かい作業はいつもの動画にて。（今回も音の確認はありません。作業の様子のみです）

BGM : Rain Loops / N + 1 Loops , Moire Loops Dub version Ver. 1.1 / N + 1 Loops

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月22日 (日) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

帰ってきた！標準はあるにはあるが癖の多いSQL #17 - 文字数取得関数も癖が強い Tweet

本エントリーは、
JPOUG Advent Calendar 2024
MySQL Advent Calendar 2024
PostgreSQL Advent Calendar 2024 の21目の記事です。

JPOUG Advent Calendar 2024の昨日のポストは、takashitel(おおの)さんの「RMANで表単位リカバリをする際の注意点（RMAN-06024）」、
MySQL Advent Calendar 2024の昨日のポストは、yoku0825さんの「Blackholeストレージエンジンとバイナリログと 2024」、
PostgreSQL Advent Calendar 2024の昨日のポストは、Noriyoshi Shinodaさんの「PostgreSQL と Oracle Database でシーケンスの動作を比較する」（シリーズ1）、および Shimooo_mutenkaさんの「【PostgreSQL】リストアの進捗状況を監視・表示するシェルスクリプト」（シリーズ2）
でした。

では、本題。

同じ名称の関数でも癖があるので移行するようなケースでは注意した方がいいよ！
という非互換はみなさんご存知の通りだと思います。

それでも検証漏れに気づいた時の雰囲気の悪さと言ったらなんとも言えませんよね。
その影響で、その他の非互換についても漏れているのでは？
と疑われてしまったり、玉突きでタスクが増えたり良いことはありません。

そんなことを一つでも減らしたいというネタです。:)

同じ結果を返す関数でも名称が違う程度ならまだ分かり易いですが、インプットする値による挙動の違いは把握するのが難しいですよね。
（マニュアルに書かれていたり書かれていなかったり、書かれていても気づきにくいところに書かれていたり、関数そのものの影響ではなかったり、様々な要因があります）

今日はそのような癖の一つで、文字数取得関数の癖。（すでに、前述した癖の一つに気づいちゃった方もいると思いますが、No Spoiler!でw）
今回のネタも有名なものの一つだと思いますが、あらためて、意識しておこう！
という意味も込めて取り上げてみました。（癖のあるシリーズでもまだ取り上げてなかったこともありますw）

長いのでw 最初に癖のまとめを。

文字数取得関数 ・Oracle Database

LENGTH()
NULLが渡された場合、 NULL が返される
空文字が渡された場合、 NULL が返される（Oracle Databaseが空文字をNULLとして扱うため）
CHAR(n)全てが空白の文字列の場合、空白分の文字数が返る。CHAR(10 CHAR)の場合は、10.
CHAR型の後続空白は文字数にカウントされる。e.g. CHAR(10 CHAR) <= 'ABC'の場合、右側を空白埋めして 10 が返される

参考）
Oracle Database / Release 19 / SQL言語リファレンス / LENGTH

今回の主役であるLENGTH()関数については以下のような記載があります。
Oracle Database / Release 19 / SQL Language Reference / Table C-1 Oracle Support of Core SQL Features

"E021-04, CHARACTER_LENGTH function: use LENGTH function instead" 上記、ドキュメントに記載されている通り、Oracle DatabaseのLENGTH()関数は方言なんですよね！！
早速、癖者感が強くなったところでw、次へ進みましょうwwww

・MySQL

CHAR_LENGTH() / CHARACTER_LENGTH()
NULLが渡された場合、 NULL が返される
空文字が渡された場合、0 が返される
全て空白の文字列の場合、 0 が返されさる（空白がトリムされるため）
CHAR型の後続空白は文字数にカウントされない。（空白がトリムされるため）ただし、 CHAR_LENGTH(CAST('12345 ' AS CHAR(10)))、 CHAR_LENGTH(CAST('12345 ' AS CHAR(30)))のようなケースでは空白を含むリテラルの文字数が返る。(Release 8.0.36)

参考）
MySQL 8.0 リファレンスマニュアル / データ型 / 文字列データ型 / CHAR および VARCHAR 型
https://dev.mysql.com/doc/refman/8.0/ja/char.html

"CHARACTER_LENGTH() は CHAR_LENGTH() のシノニム。E021-04対応とのこと。標準対応ということですね。Oracle Databaseはやってないですけど" なお、 LENGTH( str ) は、Oracle Databaseだと LENGTHB( char ) 相当ですね。バイト数を返してくるので。まじか！　この類の関数の癖の多さと強さは半端ないですね。有名な違いなので見落とされることはなさそうな気もしますが、注意が必要な部分です。
Oracle Database 以外で要注意なのはCHAR型の右側のスペースの扱いですね。該当関数云々というよりも。

"CHAR 値は格納されると、指定された長さになるように右側がスペースで埋められます。 PAD_CHAR_TO_FULL_LENGTH SQL モードが有効になっていないかぎり、CHAR 値が取り出されるときに、末尾のスペースが削除されます。"

MySQL 8.0 リファレンスマニュアル / 関数と演算子 / 文字列関数および演算子 / LENGTH(str) MySQL 8.0 リファレンスマニュアル / 関数と演算子 / 文字列関数および演算子 / CHAR_LENGTH(str) ”文字で測定された文字列 str の長さを返します。マルチバイト文字は、単一の文字としてカウントされます。つまり、5 つの 2 バイト文字を含む文字列では、LENGTH() は 10 を返し、CHAR_LENGTH() は 5 を返します。”

MySQL 8.0 リファレンスマニュアル / 関数と演算子 / 文字列関数および演算子 / CHARACTER_LENGTH(str)

・PostgreSQL

CHAR_LENGTH() / CHARACTER_LENGTH() / LENGTH()
NULLが渡された場合、 NULL が返される
空文字が渡された場合、0 が返される
全て空白の文字列の場合、 0 が返されさる（空白がトリムされるため）
CHAR型の後続空白は文字数にカウントされない（空白がトリムされるため）

参考）
PostgreSQL 16.4文書 / 第9章関数と演算子 / 9.4. 文字列関数と演算子
 PostgreSQL 16.4文書 / D.1. サポートされている機能 / D.1. サポートされている機能 / CHARACTER_LENGTH関数

”021-04 コア CHARACTER_LENGTH関数 - 数える前にCHARACTER値の最後の空白を除去します”

の冒頭でも以下のような注意点が記載されています。
”character型の値は関数あるいは演算子に適用される前にtextに変換され、character値の末尾の空白が削除されることになります。”

とさらりとまとめちゃいましたが、なかなかの癖者であることがお分かりいただけたかと思います。

移行する際にこの対応が漏れてしまうと、バグに直結する部分なのでしっかりと対処したいですよね。これ。

この程度書いただけでお腹いっぱい感はありますがw、簡単な確認ログも載せておきます。

Oracle Database Oracle Databaseに慣れてると、まあ、ふむふむって結果ではあります。

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

1)
マニュアルに記載されているように、 NULL の場合は、NULLが返ります。

SCOTT@orclpdb1> set null [null]
SCOTT@orclpdb1> SELECT LENGTH(null) AS "NULL" FROM dual;

      NULL
----------
[null]

2)
Oracle Database は空文字は NULL として扱われる別の癖があるため、空文字の場合は、NULL と同じ結果が返ります。

SCOTT@orclpdb1> SELECT LENGTH('') AS "Empty String" FROM dual;

Empty String
------------
[null]

3)

SCOTT@orclpdb1> SELECT LENGTH(' ') AS "SINGLE-BYTE SPACE" FROM dual;

SINGLE-BYTE SPACE
-----------------
                1

4)

SCOTT@orclpdb1> SELECT LENGTH('　') AS "MULTI-BYTE SPACE" FROM dual;

MULTI-BYTE SPACE
----------------
               1

5)

SCOTT@orclpdb1> SELECT LENGTH('12345') AS "SINGLE-BYTE CHARs" FROM dual;

SINGLE-BYTE CHARs
-----------------
                5

6)

SCOTT@orclpdb1> SELECT LENGTH('あいうえお') AS "MULTI-BYTE CHARs" FROM dual;

MULTI-BYTE CHARs
----------------
               5

7)

SCOTT@orclpdb1> SELECT LENGTH('12345     ') AS "SINGLE-BYTE CHARs + SPACEs" FROM dual;

SINGLE-BYTE CHARs + SPACEs
--------------------------
                        10

8)

SCOTT@orclpdb1> SELECT LENGTH('あいうえお　　　　　') AS "MULTI-BYTE CHARs + MLUTI-BYTE SPACEs" FROM dual;

MULTI-BYTE CHARs + MLUTI-BYTE SPACEs
------------------------------------
                                  10

9)

SCOTT@orclpdb1> SELECT LENGTH(CAST('12345' AS CHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs" FROM dual;

SINGLE-BYTE CHARs + SPACEs
--------------------------
                        10

10)

SCOTT@orclpdb1> SELECT LENGTH(CAST('12345     ' AS CHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs" FROM dual;

SINGLE-BYTE CHARs + SPACEs
--------------------------
                        10

11)

SCOTT@orclpdb1> SELECT LENGTH(CAST('12345' AS VARCHAR2(10))) AS "SINGLE-BYTE CHARs + SPACEs" FROM dual;

SINGLE-BYTE CHARs + SPACEs
--------------------------
                         5

12)

SCOTT@orclpdb1> SELECT LENGTH(CAST('12345     ' AS VARCHAR2(10))) AS "SINGLE-BYTE CHARs + SPACEs" FROM dual;

SINGLE-BYTE CHARs + SPACEs
--------------------------
                        10

MySQL CHARの時の挙動に注目です。CASTしたケースの挙動はなかなかキツめな気がします。

Oracle DatabaseのLENGTH()に相当するのは、CHAR_LENGTH()ですが、空文字の扱いはOracle Databaseが特殊なので要注意なのは言うまでもありません。

+-----------+
| VERSION() |
+-----------+
| 8.0.36    |
+-----------+

1)

mysql> SELECT CHAR_LENGTH(null) AS "NULL";
+------+
| NULL |
+------+
| NULL |
+------+

2)
Oracle Databaseとは異なり。空文字は空文字としてカウントされています。こちらが標準の動き（Oracle Database側に癖があります）

mysql> SELECT CHAR_LENGTH('') AS "Empty String";
+--------------+
| Empty String |
+--------------+
|            0 |
+--------------+

3)

mysql> SELECT CHAR_LENGTH(' ') AS "SINGLE-BYTE SPACE";
+-------------------+
| SINGLE-BYTE SPACE |
+-------------------+
|                 1 |
+-------------------+

4)

mysql> SELECT CHAR_LENGTH('　') AS "MULTI-BYTE SPACE";
+------------------+
| MULTI-BYTE SPACE |
+------------------+
|                1 |
+------------------+

5)

mysql> SELECT CHAR_LENGTH('12345') AS "SINGLE-BYTE CHARs";
+-------------------+
| SINGLE-BYTE CHARs |
+-------------------+
|                 5 |
+-------------------+

6)

mysql> SELECT CHAR_LENGTH('あいうえお') AS "MULTI-BYTE CHARs";
+------------------+
| MULTI-BYTE CHARs |
+------------------+
|                5 |
+------------------+

7)

mysql> SELECT CHAR_LENGTH('12345     ') AS "SINGLE-BYTE CHARs + SPACEs";
+----------------------------+
| SINGLE-BYTE CHARs + SPACEs |
+----------------------------+
|                         10 |
+----------------------------+

8)

mysql> SELECT CHAR_LENGTH('あいうえお　　　　　') AS "MULTI-BYTE CHARs + MLUTI-BYTE SPACEs";
+--------------------------------------+
| MULTI-BYTE CHARs + MLUTI-BYTE SPACEs |
+--------------------------------------+
|                                   10 |
+--------------------------------------+

9)
これはマニュアルに記載されている通りの結果ですね。Oracle Databaseとは異なり, CHAR(10)へキャストされた際に付加される空白は含まれていません。なお、MySQL 8.0 リファレンスマニュアル / MySQL サーバーの管理 / MySQL Server / サーバー SQL モード / 5.1.11 サーバー SQL モードには、PAD_CHAR_TO_FULL_LENGTH の記述がありますが、最新版ではdeprecatedになっています。

mysql> SELECT CHAR_LENGTH(CAST('12345' AS CHAR(10))) AS "SINGLE-BYTE CHARs";
+-------------------+
| SINGLE-BYTE CHARs |
+-------------------+
|                 5 |
+-------------------+

9-1)
前述の特性から言うと、ちょっと怪しい挙動ですよね。なんだろこの動き。(8.0.36)

mysql> SELECT CHAR_LENGTH(CAST('12345     ' AS CHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs";
+----------------------------+
| SINGLE-BYTE CHARs + SPACEs |
+----------------------------+
|                         10 |
+----------------------------+

9-2)
面白い挙動ですね。もう一つついでに確認しておきましょう。リテラルで指定した文字列が、CASTしたCHAR(n)のn以下の場合、CHAR(n)のnが返る訳ではなく、リテラルの文字数（後続の空白を含む）そのものが返されます。なんとなく、怪しい挙動ですね。やはり。

mysql>  SELECT CHAR_LENGTH(CAST('12345     ' AS CHAR(30))) AS "SINGLE-BYTE CHARs + SPACEs";
+----------------------------+
| SINGLE-BYTE CHARs + SPACEs |
+----------------------------+
|                         10 |
+----------------------------+

9-3)
CHAR(7)よりは長い文字列を渡しているので、超過した文字は切られて 7文字となっています。これは予想通り。

mysql>  SELECT CHAR_LENGTH(CAST('12345      ' AS CHAR(7))) AS "SINGLE-BYTE CHARs + SPACEs";
+----------------------------+
| SINGLE-BYTE CHARs + SPACEs |
+----------------------------+
|                          7 |
+----------------------------+

MySQLのCAST()ではVARCHAR/TEXTへのキャストはできないようなので、CHAR(n)へのキャストのみ確認してみました。CHARだけ見れれば良いので十分ではありますが。CHARの時の文字列に続く空白の扱いの癖の影響なので。

PostgreSQL Oracle DatabaseのLENGTH()に相当するのは、CHAR_LENGTH()ですが、空文字の扱いはOracle Databasegが特殊なので要注意なのは言うまでもありません）
また、LENGTH()も同様に文字数を返してくるのがわかります。。。。PostgreSQLの場合、関数名も同じにできるし、NULL関連の癖に注意すれば良さそうに見えるわけですが。。。。。油断しちゃいけませんよねw

                                                 version                                                 
---------------------------------------------------------------------------------------------------------
 PostgreSQL 16.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-22), 64-bit

perftestdb=> \pset null [null]
Null表示は"[null]"です。

1)

perftestdb=> SELECT LENGTH(null) AS "NULL";
  NULL  
--------
 [null]

2)
空文字の挙動はMySQLと同じですよね。

perftestdb=> SELECT LENGTH('') AS "Empty String";
 Empty String 
--------------
            0

3)

perftestdb=> SELECT LENGTH(' ') AS "SINGLE-BYTE SPACE";
 SINGLE-BYTE SPACE 
-------------------
                 1

4)

perftestdb=> SELECT LENGTH('　') AS "MULTI-BYTE SPACE";
 MULTI-BYTE SPACE 
------------------
                1

5)

perftestdb=> SELECT LENGTH('12345') AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

6)

perftestdb=> SELECT LENGTH('あいうえお') AS "MULTI-BYTE CHARs";
 MULTI-BYTE CHARs 
------------------
                5

7)

perftestdb=> SELECT LENGTH('12345     ') AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                         10

8)

perftestdb=> SELECT LENGTH('あいうえお　　　　　') AS "MULTI-BYTE CHARs + MLUTI-BYTE SPACEs";
 MULTI-BYTE CHARs + MLUTI-BYTE SPACEs 
--------------------------------------
                                   10

9)
MySQLとPostgreSQLは同じ挙動ですね。

perftestdb=> SELECT LENGTH(CAST('12345' AS CHAR(10))) AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

10)
空白が埋めされたわけではなく、文字列として空白を渡した場合も、トリムされて、5文字となります。（MySQLもこの動きを予想していたのになんだろあの動き）

perftestdb=> SELECT LENGTH(CAST('12345     ' AS CHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                          5

11)

perftestdb=> SELECT LENGTH(CAST('12345' AS VARCHAR(10))) AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

12)

perftestdb=> SELECT LENGTH(CAST('12345     ' AS VARCHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                         10

13)

perftestdb=> SELECT LENGTH(CAST('12345' AS TEXT)) AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

14)

perftestdb=> SELECT LENGTH(CAST('12345     ' AS TEXT)) AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                         10

CHAR_LENGTH()でも同様に確認しておきましょう。LENGTH()でいいじゃん感じですけどもw。

perftestdb=> SELECT CHAR_LENGTH(null) AS "NULL";
  NULL  
--------
 [null]

perftestdb=> SELECT CHAR_LENGTH('') AS "Empty String";
 Empty String 
--------------
            0

perftestdb=> SELECT CHAR_LENGTH(' ') AS "SINGLE-BYTE SPACE";
 SINGLE-BYTE SPACE 
-------------------
                 1

perftestdb=> SELECT CHAR_LENGTH('　') AS "MULTI-BYTE SPACE";
 MULTI BYTE SPACE 
------------------
                1

perftestdb=> SELECT CHAR_LENGTH('12345') AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

perftestdb=> SELECT CHAR_LENGTH('あいうえお') AS "MULTI-BYTE CHARs";
 MULTI-BYTE CHARs 
------------------
                5

perftestdb=> SELECT CHAR_LENGTH('12345     ') AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                         10

perftestdb=> SELECT CHAR_LENGTH('あいうえお　　　　　') AS "MULTI-BYTE CHARs + MLUTI-BYTE SPACEs";
 MULTI-BYTE CHARs + MLUTI-BYTE SPACEs 
--------------------------------------
                                   10

perftestdb=> SELECT CHAR_LENGTH(CAST('12345' AS CHAR(10))) AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

perftestdb=> SELECT CHAR_LENGTH(CAST('12345     ' AS CHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                          "5

perftestdb=> SELECT CHAR_LENGTH(CAST('12345' AS VARCHAR(10))) AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

perftestdb=> SELECT CHAR_LENGTH(CAST('12345     ' AS VARCHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                         10

perftestdb=> SELECT CHAR_LENGTH(CAST('12345' AS TEXT)) AS "SINGLE-BYTE CHARs";
 SINGLE-BYTE CHARs 
-------------------
                 5

perftestdb=> SELECT CHAR_LENGTH(CAST('12345     ' AS TEXT)) AS "SINGLE-BYTE CHARs + SPACEs";
 SINGLE-BYTE CHARs + SPACEs 
----------------------------
                         10

CHAR型の空白の扱いが癖の元なので、表の列がCHAR型の場合の動きも少し見ておきましょう。
まずは、データの準備、Oracle Database/MySQL/PostgreSQLそれぞれで、CHAR(10)の列を1列持つ表とデータを用意しました。

Oracle Database

SCOTT@orclpdb1> l
  1  CREATE TABLE str
  2  (
  3    memo VARCHAR2(40 CHAR)
  4    , c CHAR(10 CHAR)
  5* )
SCOTT@orclpdb1> /

表が作成されました。

SCOTT@orclpdb1> l
  1  INSERT ALL
  2    INTO str(memo, c) VALUES('NULL', null)
  3    INTO str(memo, c) VALUES('Empty string', '')
  4    INTO str(memo, c) VALUES('SINGLE-BYTE SPACE', ' ')
  5    INTO str(memo, c) VALUES('SINGLE-BYTE 2 SPACEs', '  ')
  6    INTO str(memo, c) VALUES('SINGLE-BYTE CHAR and SPACE', '1 ')
  7    INTO str(memo, c) VALUES('SINGLE-BYTE CHARs', '12345')
  8    INTO str(memo, c) VALUES('SINGLE-BYTE CHARs', '12345     ')
  9*   SELECT null FROM dual
SCOTT@orclpdb1> /

7行が作成されました。

SCOTT@orclpdb1> COMMIT;

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

MySQL

mysql> CREATE TABLE str
    -> (
    ->   memo VARCHAR(40)
    ->   , c CHAR(10)
    -> );
Query OK, 0 rows affected (0.29 sec)

mysql> INSERT 
    ->   INTO str(memo, c) 
    ->     VALUES('NULL', null)
    ->          ,('Empty string', '')
    ->          ,('SINGLE-BYTE SPACE', ' ')
    ->          ,('SINGLE-BYTE 2 SPACEs', '  ')
    ->          ,('SINGLE-BYTE CHAR and SPACE', '1 ')
    ->          ,('SINGLE-BYTE CHARs', '12345')
    ->          ,('SINGLE-BYTE CHARs', '12345     ')
    -> ;
Query OK, 7 rows affected (0.03 sec)
Records: 7  Duplicates: 0  Warnings: 0

mysql>

PostgreSQL

perftestdb=> CREATE TABLE str
perftestdb-> (
perftestdb(>   memo VARCHAR(40)
perftestdb(>   , c CHAR(10)
perftestdb(> );
CREATE TABLE

perftestdb->   INTO str(memo, c) 
perftestdb->     VALUES('NULL', null)
perftestdb->          ,('Empty string', '')
perftestdb->          ,('SINGLE-BYTE SPACE', ' ')
perftestdb->          ,('SINGLE-BYTE 2 SPACEs', '  ')
perftestdb->          ,('SINGLE-BYTE CHAR and SPACE', '1 ')
perftestdb->          ,('SINGLE-BYTE CHARs', '12345')
perftestdb->          ,('SINGLE-BYTE CHARs', '12345     ')
perftestdb-> ;
INSERT 0 7
perftestdb=>

リテラル値をキャストした場合とは少々異なる結果になりました。
MySQLとPostgreSQLは同一の挙動を示します。MySQLの場合、'12345 'をCHAR(10)へCASTした時の挙動の違い、やはり気になりますね。

Oracle Database

SCOTT@orclpdb1> SELECT memo, CASE WHEN c IS NULL THEN c ELSE '"'||c||'"' END AS "CHAR(10)", LENGTH(c) FROM str;

MEMO                                     CHAR(10)                              LENGTH(C)
---------------------------------------- ------------------------------------ ----------
NULL                                     [null]                               [null]
Empty string                             [null]                               [null]
SINGLE-BYTE SPACE                        "          "                                 10
SINGLE-BYTE 2 SPACEs                     "          "                                 10
SINGLE-BYTE CHAR and SPACE               "1         "                                 10
SINGLE-BYTE CHARs                        "12345     "                                 10
SINGLE-BYTE CHARs                        "12345     "                                 10

MySQL

mysql> SELECT memo, CASE WHEN c IS NULL THEN c ELSE CONCAT('"', c, '"') END AS "CHAR(10)", CHAR_LENGTH(c) FROM str;
+----------------------------+----------+----------------+
| memo                       | CHAR(10) | CHAR_LENGTH(c) |
+----------------------------+----------+----------------+
| NULL                       | NULL     |           NULL |
| Empty string               | ""       |              0 |
| SINGLE-BYTE SPACE          | ""       |              0 |
| SINGLE-BYTE 2 SPACEs       | ""       |              0 |
| SINGLE-BYTE CHAR and SPACE | "1"      |              1 |
| SINGLE-BYTE CHARs          | "12345"  |              5 |
| SINGLE-BYTE CHARs          | "12345"  |              5 |
+----------------------------+----------+----------------+

PostgreSQL

perftestdb=> SELECT memo, CASE WHEN c IS NULL THEN c ELSE '"'||c||'"' END AS "CHAR(10)", LENGTH(c) FROM str;
            memo            | CHAR(10) | length 
----------------------------+----------+--------
 NULL                       | [null]   | [null]
 Empty string               | ""       |      0
 SINGLE-BYTE SPACE          | ""       |      0
 SINGLE-BYTE 2 SPACEs       | ""       |      0
 SINGLE-BYTE CHAR and SPACE | "1"      |      1
 SINGLE-BYTE CHARs          | "12345"  |      5
 SINGLE-BYTE CHARs          | "12345"  |      5

明日の、JPOUG Advent Calendar 2024は、rkondoさん、MySQL Advent Calendar 2024は、今の所空いていますが誰かが書くはずw、そして、PostgreSQL Advent Calendar 2024は、kingtomo1122さん(シリーズ1)、yamatattsuさん(シリーズ2)です。

メーリークリスマスには少し早いですが、メリークリスマス！
良いお年をお迎えください。

では、また来年！（DTMのポストはまだする予定、DTMの全部俺アドベントカレンダーやってますのでw ）

Enjoy! SQL!

投稿日時 2024年12月21日 (土) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, JPOUG, Advent Calendar | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#21 - 完成間近、各トラックのバランスとか音色調整とか　その1 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024 21日目の窓を開けました！

ほぼ完成なのですが、残る作業は各トラックの音色、バランスと音量の調整ですね。
それに、Plug-inで奥行きをつけたり。。地味だけど大切なやつ。
ということで、その1回目は、リズムセクション周りの部分からやっつけちゃおうかと。

使っている機器を書いておきます。音色や音の確認って結局のところ使用機材で違ったりするので。

Apple Studio Display 27inch、基本的にこれで。

次に、イヤフォンとヘッドフォン
Bose QuietComfort Earbuds
Bose QuietComfort Ultra Headphones

おまけ(ちょい古い)
Bose SoundLink Mini II

これらで音確認してます。

今日調整したトラックは以下。トラックにLoop名称を利用し "トラック番号.Loop名称"にしてあるので参考にしていただければ。

01.Synthetic Bass House
02.Almost Electro Beat
03.Les Inferno Snare
04.Neon Dreams Snare 02
12.Aggressive Stance Bass
13.Aggressive Step Synth Bass

細かい作業はいつもの動画で、音の確認は全トラックの調整終了後に予定しているため、今回は、各トラックの音調整完了後のセッティングのまとめのみです。

BGM : Memory Loops - ver. 1.1 / N + 1 Loops

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月21日 (土) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#20 - イントロにもう少し追加したいその3 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
20日目の窓を開けました！

ほぼもういいかなぁ。と思い、音のバランス調整を始めたら、イントロにもう少し足したくなりましたw。こればかりは仕方ない、そういう気持ちになったのでw
要らなそうなら削除しちゃえば問題ないわけですし

Before

After

細かい作業はいつものように動画にて。（追加した部分の雰囲気の違い。気づかないような程度ですが変わってますw）。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月20日 (金) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#19 - イントロにもう少し追加したいその2 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
19日目の窓を開けました！

効果音をイントロの一部に追加したというのが前回まででした。
これでいいかなぁ。と思って何度か聞いていると、んーw また追加したい気持ちに。w （マジで気づかない程度にイントロにレイヤーを追加してみたい。。。と。
余計だったら後から削除すればいいですしw

Before

After

細かい作業ログはいつもの動画で。後半でイントロ含め通しで音確認しています。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月19日 (木) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#18 - イントロにもう少し追加したいその1 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024 18日目の窓を開けました！

前回イントロのループにオートメーションを追加していたときに感じたイントロの物足りなさ。
ということで、イントロをもうすこににぎやかにしてみようかとw （そんな感じ〜。というだけの感じ〜、が大切だと思うのでやってみましょうw )

Before

VOX的な効果音を追加してみたけど、悪くない感じw
After

いつものようにこまけー作業ログは動画にて。後半で本日の音確認しています。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月18日 (水) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#17 - オートメーションを追加してパンを左右に自動的に振る Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
17日目の窓を開けました！

イントロの低音のボワ〜んというところ（表現がむずいがw）xトラック目の部分にオートメーションを追加してパンを左右に自動的に振るようにしてみた。

Before

After

細かい作業は動画にて。後半で今日の作業の音確認してます。　やっぱ左右に振ったほうが面白いよなぁ。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月17日 (火) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#16 - BASSラインをチョップして音を削除 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
16日目の窓を開けました！

BASSライン、一部無い方が良いかなぁ。という音とチョップして削除してみる。（その方が良さげな気がするw

Before

After

確認中に、最後のスクラッチのタイミングが気に入らず、ついでに調整しちゃいましたw
細かい作業ログはいつもの動画で。後半で本日の音確認もしています。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月16日 (月) 05時22分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#15 - ネコだけにScratch追加したいその4 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
15日目の窓を開けました！

できた曲をしばらく聴いていたら、ん〜。もう一つScratchのトラックを追加したくなってきたので追加してみる。

Before

Scratch音のLoopに含まれていたシンセの音がいい感じのアクセントになりそうだったので、そこだけチョップして切り出して使ってみた。
After

いつものように作業ログはYoutubeの動画にて。後半で本日の音確認やってます。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月15日 (日) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#14 - ネコだけにScratch追加したいその3の修正 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
14日目の窓を開けました！

ネコだけにScratch追加したいということで、その3 で追加したスクラッチですが、短いかなぁ（という感じ）、なので少し長くしてみましょう。

Before

分かり難いですがw、少し長くしました。
After

細かい作業のログと、音の確認は以下にて。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月14日 (土) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

実行計画は, SQL文のレントゲン写真だ！ No.65 / JPOUG Advent Calendar 2024 / JSON-Relational Duality Views Tweet

本エントリーは、13日の金曜日のエントリーです。
昨日のポストは、Takayuki Nishio (Nisshii0)さんの「[Oracle] ここが違うよ Autonomous Database！初めてデータ移行して気づいたこと」でした。

ということで、私のターン。

皆様の期待通り？、13日の金曜日なので、JSON を取り上げておきたいと思います。(実は元々別のながーーーいネタを用意していたのですが、13日の金曜日であることに気づきwww 以下略)
Oracle Database のJSON関連機能について、すでに多くの方がブログ等で書かれていることもあり、本エントリーでは、Mac De Oracleっぽくw、実行計画という名のレントゲン写真はどうなのかw を診ておきたいと思います。

Stable Diffusion WebUI

対象とするのは、JSON-Relational Duality Views です。
この機能、名前の通り、リレーショナル表のままで、JSONにマッピングするVIEWを通して使えるようにしたものでOracle Database 23aiの新機能の一つです。（雑に解説すると。。）

気になりますよね。JSON-Relational Duality Viewsを介してアクセスした場合の実行計画！！！！

ちょっとわき道に逸れるのですが、Oracle Databaseには、RDFView という機能があります。リレーショナル表のままで、RDF Graphのトリプルとして参照する機能ですよね。これまた雑に解説すると。

実行計画は,SQL文のレントゲン写真だ！　Oracle Database編 (全部俺）Advent Calendar 2019 おまけ#3
トリプルとして扱うために、対象の列毎にSELECT文を作る必要がありかつ３列なのでUNIONも必要で、という想像通りのなかなかのレントゲン写真（実行計画でした）。

果たして、JSON-Relational Duality Views ではどうなるのか。。。。

早速、試してみましょう。

23aiを利用しています。

COTT@localhost:1521/freepdb1> select banner_full from v$version;

BANNER_FULL
--------------------------------------------------------------------------------
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05

まず、JSON-Relational Duality ViewsはViewなので元になるリレーショナル表を決めちゃいます。dept表をもとにして department表を作って使いましょう。 dept表のままでも良いのですけどもw

SCOTT@localhost:1521/freepdb1> set linesize 80
SCOTT@localhost:1521/freepdb1> desc dept
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 DEPTNO                                    NOT NULL NUMBER(2)
 DNAME                                              VARCHAR2(14)
 LOC                                                VARCHAR2(13)

SCOTT@localhost:1521/freepdb1> select * from dept;

    DEPTNO DNAME          LOC
---------- -------------- -------------
        10 ACCOUNTING     NEW YORK
        20 RESEARCH       DALLAS
        30 SALES          CHICAGO
        40 OPERATIONS     BOSTON

SCOTT@localhost:1521/freepdb1> create table department as select * from dept;

Table created.

SCOTT@localhost:1521/freepdb1> alter table department add constraint pk_department primary key (deptno) using index;

Table altered.

department表の列をJSONのキーにマップしちゃうだけ（おまけで, UPDATE/INSERT/DELETEも許可していますが、今回はSELECTしかしませんw）
JSON RELATIONAL DUALITY VIEWを作成します。（見るとリレーショナル表の列とJSONのキーをマップしているだけですね。シンプル）

SCOTT@localhost:1521/freepdb1> l
  1  CREATE JSON RELATIONAL DUALITY VIEW department_dv
  2  AS
  3    SELECT
  4      JSON { '_id'            : d.deptno,
  5             'departmentName' : d.dname,
  6             'location'       : d.loc }
  7    FROM
  8      department d
  9*   WITH UPDATE INSERT DELETE
SCOTT@localhost:1521/freepdb1> /

View created.

SCOTT@localhost:1521/freepdb1> select collection_name,collection_type from user_json_collections;

COLLECTION_NAME                COLLECTION_T
------------------------------ ------------
DEPARTMENT_DV                  DUALITY VIEW

SCOTT@localhost:1521/freepdb1> set linesize 400
COTT@localhost:1521/freepdb1> select * from user_json_duality_views;

VIEW_NAME                      JSON ROOT_TABLE_NAME                ROOT_TABLE_OWNER               ALLOW_INSER ALLOW_UPDAT ALLOW_DELET READ_ONLY   JSON_SCHEMA                    STATUS
------------------------------ ---- ------------------------------ ------------------------------ ----------- ----------- ----------- ----------- ------------------------------ -------
DEPARTMENT_DV                  DATA DEPARTMENT                     SCOTT                          TRUE        TRUE        TRUE        FALSE       {"title":"DEPARTMENT_DV","dbOb VALID
                                                                                                                                                  ject":"SCOTT.DEPARTMENT_DV","d
                                                                                                                                                  bObjectType":"dualit

特に何も指定せず問い合わせると、まんまのJSONが返されます。

SCOTT@localhost:1521/freepdb1> set long 4000
SCOTT@localhost:1521/freepdb1> set longchunk 4000
SCOTT@localhost:1521/freepdb1> set linesize 400
SCOTT@localhost:1521/freepdb1> select * from department_dv;

DATA
--------------------------------------------------------------------------------------------------------------------------------------------------
{"_id":10,"_metadata":{"etag":"66F269F721C734BAE74D56D6A948D0F6","asof":"0000000001799313"},"departmentName":"ACCOUNTING","location":"NEW YORK"}
{"_id":20,"_metadata":{"etag":"8A0701C115BFECAB64C34E2FF406FFDA","asof":"0000000001799313"},"departmentName":"RESEARCH","location":"DALLAS"}
{"_id":30,"_metadata":{"etag":"A7CDA588F9052B35B56E00BB22B6EC6F","asof":"0000000001799313"},"departmentName":"SALES","location":"CHICAGO"}
{"_id":40,"_metadata":{"etag":"93AE902896310C0DFFCE3FC70E0479F6","asof":"0000000001799313"},"departmentName":"OPERATIONS","location":"BOSTON"}

さて、table full scanになると思いますが、とりあえず見てみましょう。

SCOTT@localhost:1521/freepdb1> set autot trace exp stat
SCOTT@localhost:1521/freepdb1> select * from department_dv;

Elapsed: 00:00:00.03

Execution Plan
----------------------------------------------------------
Plan hash value: 826413278

--------------------------------------------------------------------------------
| Id  | Operation         | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |            |     4 |    80 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| DEPARTMENT |     4 |    80 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------

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

SCOTT@localhost:1521/freepdb1> set autot off
SCOTT@localhost:1521/freepdb1> set linesize 80
SCOTT@localhost:1521/freepdb1> desc department_dv
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 DATA                                               JSON

SCOTT@localhost:1521/freepdb1> set linesize 400
SCOTT@localhost:1521/freepdb1> col _id for a30
SCOTT@localhost:1521/freepdb1> col departmentName for a30
SCOTT@localhost:1521/freepdb1> col location for a30

...略...

リレーショナル表っぽいクエリーにもできます。

SCOTT@localhost:1521/freepdb1> r
  1  select d.data."_id",
  2         d.data."departmentName",
  3         d.data."location"
  4  from   department_dv d
  5* order by 1

_id                            departmentName                 location
------------------------------ ------------------------------ ------------------------------
10                             "ACCOUNTING"                   "NEW YORK"
20                             "RESEARCH"                     "DALLAS"
30                             "SALES"                        "CHICAGO"
40                             "OPERATIONS"                   "BOSTON"

では、次に、主キーにマップした _id 列でアクセスしてみましょう。おおおおお、普通に、INDEX UQNIQE SCANでしたね。（想像していた通りですがw）
Predicate Information に現れるアクセスパスを見ると、 access("D"."DEPTNO"=30) となっており、内部的にはリレーショナル表を問い合わせるSQL文に書き換えられているように見えますよね（まだ調べていないですがw）

SCOTT@localhost:1521/freepdb1> set autot trace exp stat
SCOTT@localhost:1521/freepdb1> select json_serialize(d.data pretty) from department_dv d where d.data."_id" = 30;

Elapsed: 00:00:00.01

Execution Plan
----------------------------------------------------------
Plan hash value: 3132674683

---------------------------------------------------------------------------------------------
| Id  | Operation                   | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |               |     1 |    20 |     1   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| DEPARTMENT    |     1 |    20 |     1   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | PK_DEPARTMENT |     1 |       |     0   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

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

 2 - access("D"."DEPTNO"=30)


Statistics
----------------------------------------------------------
          8  recursive calls
          0  db block gets
          5  consistent gets
          0  physical reads
          0  redo size
        782  bytes sent via SQL*Net to client
        108  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SCOTT@localhost:1521/freepdb1> set autot off
SCOTT@localhost:1521/freepdb1> r
  1* select json_serialize(d.data pretty) from department_dv d where d.data."location" = 'CHICAGO'

JSON_SERIALIZE(D.DATAPRETTY)
----------------------------------------------------------------------------------------------------
{
  "_id" : 30,
  "_metadata" :
  {
    "etag" : "A7CDA588F9052B35B56E00BB22B6EC6F",
    "asof" : "0000000001799BF8"
  },
  "departmentName" : "SALES",
  "location" : "CHICAGO"
}

...略...

SCOTT@localhost:1521/freepdb1> r
  1  select
  2    d.data."_id" as deptno
  3  , d.data."departmentName" as department_name
  4  , d.data."location" as location
  5  from
  6    department_dv d
  7  where
  8*   d.data."location" = 'CHICAGO'

DEPTNO                         DEPARTMENT_NAME                LOCATION
------------------------------ ------------------------------ ------------------------------
30                             "SALES"                        "CHICAGO"

JSON-Relational Duality Viewsから問い合わせてもリレーショナル表を直接問い合わせるのと同じなんですねぇ。なんとなく安心w

13日の金曜日のJSONネタなので、恐ろしーい結果を期待していた方、ごめんなさいwwww JSON怖くないですw

明日のJPOUG Advent Calendar 2024は、ketsujiさんです。

投稿日時 2024年12月13日 (金) 00時00分 Oracle, チューニング, FAQ, SQL, JPOUG, パフォーマンス, Advent Calendar, RDF Graph, Oracle Database 23c Free Developer Release, JSON | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#13 - ネコだけにScratch追加したいその3 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
13日目の窓を開けました！

まだまだ引っ掻いてる音がほしーーーい気がしませんか？w 。(まだ、追加するんかーーーーーーーいw)

Before

After

いつものように細かい作業はVlogにて。後半で、本日の作業確認として全体を通して音を確認しています。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月13日 (金) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#12 - ネコだけにScratch追加したいその2 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
12日目の窓を開けました！

さぁ。アドベントカレンダーも折り返し地点:)

もっとスクラッチ追加したいですよねw まだまだ寂しい気がするので。ということで、さらに追加してみる
Before

After

こまけー作業は以下の動画にて。後半で、ここまでの音を確認しています。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月12日 (木) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#11 - ネコだけにScratch追加したいその1 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
11日目の窓を開けました！

ネコ成分、というかネコだけに、スクラッチも追加したいですよねw 爪研ぎというかw ということで何か追加してみる。。
Before

After

細かい作業の様子は動画にて。最後に本日の作業の音確認してます。完成に近づいてきた:)

そういえば、これも書いておかないと思い忘れていたのですが、その昔、GarageBand登場前と言った方が良いのかなw PlayerProというDAWとしても老舗に近いシェアウェアがありました。私も使っていたのですが、当時は画期的でしたねぇ。と思い出に浸るw

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月11日 (水) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#10 - ネコっぽい効果音をリズムに絡める　その2 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
10日目の窓を開けました！

ネコ成分、もう少し欲しいいなぁw。
ということで、もう1トラック追加してみようと思いますw

Before

After

細かい作業の様子は以下の動画で。最後に本日の作業の結果確認として音を確認しています。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月10日 (火) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#9 - ネコっぽい効果音をリズムに絡める　その1 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
9日目の窓を開けました！

Layerを重ねてお腹いっぱいになったのでw、リズムにネコっぽい効果音を絡めて行こうと思います。（パーカッション的に使うイメージ）
猫の鳴き声ループをチョップしていい感じにできるかなぁ。
Apple Loopには、効果音として動物や生活音などいろいろな環境音もあるので、DTMにも使えるネタは結構あります。（以前作った曲で、どうしても真言宗のお経とか木魚の音を使おうとした時、適当なLoopがなくてフリーの音源を使わせてもらいましたが、オリジナルのサンプリング音をLoopライブラリへ追加して利用することもできます:)

Before

After

細かい作業風景は以下の動画で。最後に音を確認しています。
Apple Loopをそのまま利用するか、チョップして音単位で捨てたり、入れ替えたりするのは基本テクニックなので覚えちゃえば楽です。
ただ音毎に一括チョップする機能はないので、音毎にチョップするという地味な作業になってしまうわけですがw。（そのあたりはおまけでつけてくれているソフトウェアと有料版との差別化という感はありますねw）

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月 9日 (月) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#8 - Layer　どうしましょう　その4 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
8日目の窓を開けました！

欲張りすぎだろうか、気づかない程度にもう一つLayerを足したいw
（まだ追加するのかよ！〜w という感じですがw　追加しまっす！）

Before

After

こまけー作業は、これまで通りですが、一応、早送りの作業シーンと、最後に本日の音確認は以下。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月 8日 (日) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#7 - Layer　どうしましょう　その3 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
7日目の窓を開けました！

まだ、重ねても良いかなぁ。wwww 気分というかそんな感じー、なので　：）

Before

After
もう一つLayerを追加した状態。雰囲気というかなんというか、めっちゃ変わったかというと。そうでもないですけども、このままでいきましょう。

細かい作業動画は以下にて。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月 7日 (土) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#6 - Layer　どうしましょう　その2 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024 6日目の窓を開けました！

昨日はLayerトラックを2つ追加しましたが、まだ物足りない気がしていて、もう一つLayer足してみますか。。と。

Before

Before_20241205064601

After こんな感じで、Night Vision Synth Layerが良さそうだったので追加した後の状態がこれ。

いつものように細かい作業風景は早送りも含め動画にて。動画の最後で今日追加したトラック含めた音の確認をしています。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月 6日 (金) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#5 - Layer　どうしましょう　その1 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024 5日目の窓を開けました！

昨日はざっくりBASSライン決めちゃいました。
今日は、このままだと寂しいので Layer をどうするか。というところ。
最初から最後まで裏でなってる感じトラック追加します。後でさらに足したり減らしたり試行錯誤すると思いますが。。とりあえず足していきますw

良さそうなのを見つけて、雑に置いてみるだけですけども（必要ならチョップして落としたりできますし）
手順はこれまで通り、メインとのラックを再生しつつ、良さそうなループを見つけたら同時に再生して確認。
よければそのままトラックに追加。
地味な作業の繰り返しです。

以上w

Before

After

オリジナルのループと+12半音高く調整したループの2トラックを追加しました。
Before_20241204072801

地味な作業の早送りあり、BGMあり、で最後に今日完成したところまでを聴いて、明日へ続く。
（日々聞ける感じで終わって次に繋げるので、いい感じのイテレーションでしょ？。その日のタスクは確実に実装してコミットするみたいな感じw、ゴールは Ver.2を完成させるところまで:)

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月 5日 (木) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#4 - BASSトラックどうしようその1 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024 4日目の窓を開けました！

リズムセクションを固めないと次を決めにくいので、BASSトラックをざっくり決めちゃいましょう。
流れとしては、イントロ向けループを探して、試す、という地道なことの繰り返しで、イメージに近いループやなんとなくいいじゃん！、
というループを選んじゃいます。

そのまま使うこともあれば、後でチョップしたり、
一部だけ合うかなーというループはチョップして一部のみ使うとか、
色々ですね。決まりなんかないので。

Before BASSトラック追加前はこんな感じ

After 追加後はこんな感じ。今のところループの原型のまま置いているだけです（後半で、EQで調整したりチョップして音を入れ替えたり、落としたりするので今はオリジナルのまま）

いつものように作業風景を動画で。早送りや必要な部分では音の確認をしながら進めています。

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月 4日 (水) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#3 - イントロその1 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#3 - イントロその1

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
3日目の窓を開けました！

多分、ここ使わん！というトラックをバッサリ削除したのが前回。
今日は、イントロのトラックを追加していく、その１（毎回悩みますw）

ちょい重めwのイントロ（全バージョンが軽めだったのでw）を選んで２トラック追加。

イントロトラック追加前

イントロトラック追加後
Swelling Sub Bass
Transport Stop Synth
という2つのループをそのまま（音の調整は最後にするのでとりあえず置くだけ）

作業風景w 早送りあり、最後にAfterの状態の音を確認！

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月 3日 (火) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#2 - メジャーバージョンアップするための取捨選択 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
2日目の窓を開けました！

さて、対象が決まったので、どう変えていくかですが、
もとのトラックで、ん〜。いらないかなぁ〜と思うトラックをいくつか落としてベースになるトラックだけ残すことを今日の目標にしますねw
そもそもどうするかも決まってないわけですがw

Before

After

作業風景w 早送りあり、最後にAfterの状態の音を確認！

Enjoy DTM, GarageBand and iMovie

では、また明日。

投稿日時 2024年12月 2日 (月) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024　#1 Tweet

Apple Loopとチョップだけで頑張るGarageBand DTM 全部俺 Advent Calendar 2024
1日目の窓を開けました

一度やってみたかった、GarageBand Advent Calendar しかも全部俺で。

GarageBandなどで提供されているApple Loop、これだけを使い、打ち込み、MIDI入力もなし、サンプリングもなし（無料のお経のサンプリング音は一度利用した）でApple Loopをチョップして頑張るシリーズを初めて2年ほど。
以前からやろうと思っていた GarageBand Advent Calendar　全部俺。ついにその重い腰を上げw

で、一から作るのも大変なだったので、
昨年作ったLoopをメジャーアップデートする過程を25回に分けで書こうと思います。
元ネタは昨年思いつきで作って放置していたもので、Version 2というか2024年版へアップデート。

まずは、オリジナルはどうだったのか？、というところから。
これをどう変えていくか、それが問題だw
NecoというかNekoな。

Neco Mimi Loops / N + 1 Loops - GarageBand Edit

Enjoy DTM and GarageBand!

では、また明日。
25日間続けられるのか。。。。

投稿日時 2024年12月 1日 (日) 00時00分音楽, Mac, GarageBand, Advent Calendar, iMovie, DTM, AppleLoops, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

DROP SHADOW CTRL

GaragebandとiMovieで

検索

Twitter

最近の記事

最近のコメント

最近のトラックバック

カテゴリー

Oracle

Apple

その他

Googleの広告

RSS

当サイトについて

2024年12月27日 (金)

2024年12月25日 (水)

2024年12月24日 (火)

2024年12月23日 (月)

2024年12月22日 (日)

2024年12月21日 (土)

2024年12月20日 (金)

2024年12月19日 (木)

2024年12月18日 (水)

2024年12月17日 (火)

2024年12月16日 (月)

2024年12月15日 (日)

2024年12月14日 (土)

2024年12月13日 (金)

2024年12月12日 (木)

2024年12月11日 (水)

2024年12月10日 (火)

2024年12月 9日 (月)

2024年12月 8日 (日)

2024年12月 7日 (土)

2024年12月 6日 (金)

2024年12月 5日 (木)

2024年12月 4日 (水)

2024年12月 3日 (火)

2024年12月 2日 (月)

2024年12月 1日 (日)