DTM/GarageBand 6月のTop5 Tweet

さて、恒例の？　My DTM/GarageBand 6月のTop5

上位が強くてなかなか、ランキングが変わらない（下位の方は色々動いてるんだけど、それらが上位に上がってこないとなぁw）

Top1
Rain Loops / N + 1 Loops (949回)
自分でもiTuneじゃなくてMusicでヘビロテしてる。安定の１位

Top2
Memories Loops / N + 1 Loops (619回)
リズムセクション。特に後半がお気に入り:)

Top3
Loops in Clouds / N + 1 Loops (587回)
いつもより余計に回ってる？みたいなヘルプがあると、これ聞いて分析コメント書いてるw

Top4
Waterfall Loops - Dance Edition / N + 1 Loops (497回)
Dance Editionじゃない方はあまり伸びてないから、ドラム入れたのが良かったんだろうね。。

Top5
Number Of Loops - Club Edition / N + 1 Loops (460回)
奥様から、イントロのところは1,2,3...なのに、途中から1,2,4,8なの？、と聞かれ、え、それ気分で入れてるし、Club Editionじゃないのが元なので、そっちは、よりMatrix的なというかComputer的なイメージの動画なので、2進数みたいな。1,2,3、出だしのカウントだから自然かなぁと。。。で、奥様は、「わからん。」と。はいはい、いいんですよ。それでもw

その他の曲はプレイリストからどうぞ。

ということで、そろそろ、Oracleネタも再開しますよーー。最初はFAQ的なところから、最近、先祖帰りしたような、え、そこ！みたいなことが多くて、10年も経つと一周しちゃうのかしら、それとも。。なんて思いながら、改めて書いておこうかという、ネタからにしようかと思っているところ。
知ってる人は、大丈夫ですよ。脊髄反応でやっているだろうから。。。w

ではでは。

DTM/GarageBand : 5月にリリースした曲 Tweet

（Oracle ACEのKPI評価期間が切り替わる時期なので、Mac絡みのネタ多めですw）

ということで、DTM/GarageBand : 5月にリリースした曲

Moire Loops / N + 1 Loops

リズムセクションを作った後に適当にループを置いて行ったらこんな感じに。矩形波よりの音にしたらよりSHAKATAKっぽくなったかもね。

Moire Loops - Dub Version / N + 1 Loops

Moire Loops で使ったリズムセクションはファンクっぽい雰囲気もあるので、Dub Version化。ベースはチョップしまくって、落としたり、入れ替えたりしてますが、基本的な部分はMoire Loops と共通。リズムセクションに乗せる音で随分変わりますね。

Night Loops / N + 1 Loops

Moire Loops / N + 1 Loopsで、SHAKATAK風味になった影響かw。これは、完全にSHAKATAK風味に持っていきたくて、最終的にこうなった。

Jazzy Loops #2 / N + 1 Loops

Smooth Jazz風な路線に行くと、眠くなって飽きちゃいそうだったのですが、そういうのも作りたいなぁ。と思うところもありw
その一発目？w　で GarageBandのLoop Libraryをjazzでフィルタして出てきたLoop（意外に少ないw）だけで、1時間ぐらいで作ってみたらこうなってしまった。

ということで、5月の俺々DTM Top5は、明日にでも。

もう今年も半分ほど（）終わっちゃいましたね。

ではまた。

DTM/GarageBand - 4月のTop5 Tweet

GW、朝から渋滞30km以上のニュースを聞きつつ、それにハマらないように色々避けることができて、時間を無駄に溶かしてない作戦は正解だったなぁと思いつつ。

4月のN + 1 LoopsのTop5ランキングです。

1位 - Rain Loops / N + 1 Loops（883回/現時点）
自分でもこのリズムセクションいい感じにできた気がしてる。基本的にGarageBandの自動生成ドラムトラック（タイプは選んでいます）に別トラックで加工したスネアやハイハットなどを組み合わせてます。



2位 - Memories Loops / N + 1 Loops（562回/現時点）
先月2位に浮上してからも安定して2位キープ。これもリズムセクションが想定していたよりいい感じになった。後半は聞こえにくいけどリズムの強調にパーカッションのトラックが入ってます。GarageBand Editの動画をみてもらうとわかりやすいと思います:)



3位 - Loops in Clouds / N + 1 Loops（546回/現時点）
Cloud環境はマイグレーションしてもぐるぐるはついてくるのね〜、ぐるぐるが避けられないのならリソースもっと上手く使い切ってコストさげるとか全体の処理時間削減も考えましょう、という、なかなか届かない想いを込めて！？



4位 - Waterfall Loops - Dance Edition / N + 1 Loops（485回/現時点）
この曲自体は、Deep Forest with Peter Gabriel - While The Earth Sleepsみたいな曲作りたいなーと思って、ゴニョゴニョしてたらできた曲にスネアのセクション追加してDance EditionにしたVersionの曲で、森林とか滝がイメージに浮かんだのでWaterfallってタイトルに使ってます。Waterfallディスってる曲ではないですw はい。



5位 - Number Of Loops - Club Edition / N + 1 Loops（440回/現時点）
これも4位同様Dance Editionにはフリー映像がそれっぽい編集になっているだけで、Dance Editionと基本的には同じ曲。KraftwerkのComputer Worldっぽい感じのなにかとか軽くイメージしながら作ったやつです。

その他の曲はプレイリストからどうぞ。

ということで、Enjoy GW!

DTM/GarageBand : 4月にリリースした曲 Tweet

1月後半から、3月初旬ぐらいまで、急性低音障害型感音難聴と診断されて、DTMを控えていた影響なのか、回復したら色々調子に乗り過ぎ、4月は週一で1曲リリースしてしまったw

ちなみに、この急性低音障害型感音難聴っては、加齢とかそいうの関係ないらしく、はっきりした原因は掴めていないものの、疲れとか、睡眠不足とかいろいろあって内耳で起こる病らしい。対処療法的な投薬で解決する人も多いらしく、自分の場合は投薬としっかり睡眠をとって、耳に過度なw 負荷を与えないようにしていた。おかげで、低音部分の聴力も回復してほっとしているところ。

で, 調子にのって週一でリリースしてしまった曲は以下。

4/7リリース（128回視聴/現時点） - O(N) / N + 1 Loops
YMO関連の悲しいニュースが多かったのでテクノ方面かつ、YMOのドラムの加工音（とくにスネア）が好きすぎて、そいう感じの何かをつくりたくなった。その１の曲



4/16リリース（150回視聴/現時点）- Turquoise Loops / N + 1 Loops
久々にファンク風味の曲が作りたくなったので。:)



4/23リリース（104回視聴/現時点）- Single Thread Loop / N + 1 Loops
YMO関連の悲しいニュースが多かったのでテクノ方面かつ、YMOのドラムの加工音（とくにスネア）が好きすぎて、そいう感じの何かをつくりたくなった。その２の曲



4/26リリース（98回視聴/現時点）- Single Thread Loop - Dub Version / N + 1 Loops
YMO関連の悲しいニュースが多かったのでテクノ方面かつ、YMOのドラムの加工音（とくにスネア）が好きすぎて、そいう感じの何かをつくりたくなった。その３の曲。4.23リリースのDub versionで、ドラムをより意識してみたのと、細野さんのeBass風なのを意識してみた。



4月のTop5ランキングは別記事にて。

では。

N + 1 Loops / GarageBand DTM ランキング / Mar. 2023 Tweet

毎月恒例になりそうな。N + 1 Loops DTMランキングw

N + 1 Loopsは、GarageBandのAppleLoopをそのまままたは、チョップして入れ替えたり、捨てたりして作る。
打ち込み無しのツラミもあるが、そこが工夫のしどころで面白い。GarageBand付属のPluginもまだ全て試したわけではないので、色々遊べそうではある。

では、3月のランキング

1位 安定の Rain Loops. 自分でもいい感じでできたやつ。 / 843

2位 なんと！　リリースから2ヶ月でjump upしてきた Memories Loops. リズム作り込むの頑張ったやつ / 519

3位 ランクダウン！　Loops in Clouds. ぐるぐる系バッチ処理はどこに行ってもぐるぐる系みたいなテーマ曲w。　そういうニュアンスは1bitも感じない曲ではありますがw たまたま Cloudに行ってもぐるぐるしたいのか。CPU沢山あるのに、1CPU張り付かせて何時間も課金させるのかと。という相談受けてた時に作ったのでタイトルが、そうなってしまったという曲です。はいw / 514

4位 2月と変わらず4位。意外と安定してるw　/ 476

5位 Number Of Loops. 2月と変わらず5位。　/ 434

6位以下はplaylist見てね

N + 1 Loops / GarageBand DTM ランキング / Feb 2023 Tweet

Mac De Oracle 2022年最後のエントリーは、MacネタというかDTMネタで :)

あれから2ヶ月ということでw その後に追加した曲も含めたランキング

5位
Number Of Loops - Club Edition / N + 1 Loops / 416回再生

4位
Memories Loops / N + 1 Loops / 418回再生

3位
Waterfall Loops - Dance Edition / N + 1 Loops / 455回再生

2位
Loops in Clouds / N + 1 Loops / 476回再生

1位
Rain Loops / N + 1 Loops / 799回再生

join elimination（結合の排除）のバリエーション / FAQ Tweet

Previously on Mac De Oracle
SQL*Plus -Fastオプション / FAQでした。

今日は、結合排除のバリエーションをいくつか紹介しておこうと思います。
なんどか説明していた無駄に結合してないですよね？ の例は、参照整合性制約を頼りに結合排除が行われるものでした。

今日はそれに加えて、典型的な例を2つ紹介しておきたいと思います。（ここ”　”、試験に出ませんよ！w　でないけど大切：）

一つ目は、結合列がそれぞれユニークキーかプライマリキーで一意で、1 : 0..1 で外部結合されるケース
結合の排除は、その結合を排除しても結果に影響しなことが自明な場合に発動するので、条件を満たしています。ただ、参照整合性制約のパターン同様に、SQL文を見ただけでは気づけないですよね。
あれ、実行計画にSQL文に記載されている表がない！？　で制約を見てみて、あ”〜〜〜〜理解。みたいなw

実行計画ではSQLモニターも含め、Join Eliminationしたことを明示的に示すコメント等はありません。結合が消えていることで気づくことが多いわけですw（よーく考えたら、その結合イラねーじゃんというわけですけどもw0

  1* CREATE TABLE foo (id NUMBER PRIMARY KEY, note VARCHAR2(100))

表が作成されました。

  1* CREATE TABLE bar (id NUMBER PRIMARY KEY, memo VARCHAR2(100))

表が作成されました。

  1  SELECT
  2    foo.id
  3    , foo.note
  4  FROM
  5    foo
  6    LEFT OUTER JOIN bar
  7    ON
  8*     foo.id = bar.id

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

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    65 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| FOO  |     1 |    65 |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------

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

この手の制約による結合の排除は、前提になる制約が結合排除の条件からはずれると排除されなくなります。
たとえば、前述の例で、それぞれの表を主キーで　1:0..1 で外部結合していましたよね？
それが仕様変更で、片方の方の主キーが複合主キーになってしまい。1:* の外部結合になってしまうと。。。。結合排除できなくなります。排除した場合、クエリー結果に影響するから。

  1  CREATE TABLE foo2 (
  2    id NUMBER
  3   , note VARCHAR2(100)
  4   , PRIMARY KEY (id)
  5* )

表が作成されました。

  1  CREATE TABLE bar2 (
  2    id NUMBER
  3   , sq NUMBER NOT NULL
  4   , memo VARCHAR2(100)
  5   , PRIMARY KEY (id, sq)
  6* )

表が作成されました。

  1  SELECT
  2    foo2.id
  3    , foo2.note
  4  FROM
  5    foo2
  6    LEFT OUTER JOIN bar2
  7    ON
  8*     foo2.id = bar2.id

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

----------------------------------------------------------------------------------
| Id  | Operation          | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |             |     1 |    78 |     3   (0)| 00:00:01 |
|   1 |  NESTED LOOPS OUTER|             |     1 |    78 |     3   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| FOO2        |     1 |    65 |     2   (0)| 00:00:01 |
|*  3 |   INDEX RANGE SCAN | SYS_C009222 |     1 |    13 |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------------

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

   3 - access("FOO2"."ID"="BAR2"."ID"(+))

続きを読む "join elimination（結合の排除）のバリエーション / FAQ"

SQL*Plus -Fastオプション / FAQ Tweet

Previously on Mac De Oracle.
前回は、アドベントカレンダーのおまけのおまけwでした

今日は、そこで仕込んでおいたネタを使い、SQL*Plusも機能拡張されてたのすっかり忘れていた！　ので、
高Fetch圧症の話に絡めてSQL*Plusの-F[ast]オプション書いておこうと思います。

軽めですが。

Fetch回数削減に効果があるので、多数の行をFetchするような時は思い出すと良いですね。
Client/Server間のrount tripが減ることに繋がるわけで、そこが慢性病の原因なら少しでも楽になれたら良いと思いますし。
（ということで、Fetch Sizeも忘れないでね。という気持ちを込めて。）

続きを読む "SQL*Plus -Fastオプション / FAQ"

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

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

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

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

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

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

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

10001行が選択されました. 

経過: 00:00:01.41

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

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

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

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

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


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

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

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

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

 ...略...

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

 ...略...

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

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

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

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

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

10001行が選択されました. 

経過: 00:00:01.28

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

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

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

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

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


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

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

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

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

 ...略...

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

 ...略...

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

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

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

GarageBand/DTM/AppleLoops - また勢いで作ってしまったw Tweet

テレビ東京で放送された「復讐の未亡人」をNetflixで一気見した後に勢いで作ったGarageBandのApple LoopsとChopで打ち込みなしで作った16曲目w

ドラマの影響まんま受けたので、まあ、そんな感じになっております（Studio DisplayのスピーカやBOSE Sound Link IIとかイヤホンだとそうでもないけど、MBAのスピーカだとVOX系の音のエコーというか音が目立ちすぎるのに後で気づいた。いろんなスピーカー特性を気にしつつ、いい感じの音にするのって難しいなあぁと思ったりした）

GarageBandの画面の映像はこちら。
イントロのベルは、1音毎にチョップして、左右に振り分けるようにした。

年末〜1/7までに4曲公開 / GarageBand面白い:) Tweet

明けまして、おめでとうございます。新年一発目は、Mac / GarageBandネタから。(SQLネタまた別の日にw）

年末ギリギリから一昨日までに色々作りたくなり、4曲公開してしまったw（短い年末年始でしたが、まあまあ楽しめたような気がします）

では、昨年末ギリギリに公開した曲から順に。

70s後半から80s前半ぐらいまでの雰囲気のディスコっぽいイメージで何か作りたくなり作った1曲。
まあ、そんな感じですw
2022/12/28 released. 80s Loops / N + 1 Loops

HOUSE風な何か、かつ、ドライブで無限ループ再生して聴けそうな何かを、狙ってたらこうなってしまった曲w
春になったら山坂道への行き帰りに使えればいいかなと。
2023/1/2 released. Haze Loops / N + 1 Loops

えーっと、ハードロックなのないなぁ。まだ。と思って作ってみた1曲。そんな雰囲気を味わってもらえれば:)
フリー映像素材とどう合わせるか、悩みまくった結果、こうなってしまったリックス。
2023/1/4 released. Hard Code Loops / N + 1 Loops

そして、寒すぎて、寒すぎ〜る〜とガクガクしているところへ、友人のFBが共有した昨年クリスマスのスキューバダイビング中のオーストラリアの画像を見て。
ん〜、なんか、まったりした日向で、メローな曲でもあったら気分変わるかと。思いつつ、で、Musicで無限ループ再生できるような構成にしてみた曲。
2023/1/7 released. Mellow Loops / N + 1 Loops

そろそろ、SoundCloudにアカウント作って遊んだ方が良いのかなぁ。と思ったり。

では、また :)

Mac De Oracle 2022年最後のエントリーは、MacネタというかDTMネタで :) Tweet

3ヶ月前から、GarageBandのAppleLoopsとそれをチョップするだけで作り上げるDTMみたいなことにハマってましてw　（打ち込みとかMIDIを利用した録音もなし）

YouTubeで N + 1 Loops と言う性能に関わっている方ならピクっとするような名で、12曲（テスト含めるともっとありますが）リリースしました。（帰ってきた！　実行計画は、SQL文のレントゲン写真だ！　Oracle Database (全部俺） Advent Calendar 2022のネタに苦しんでいる最中にw）

と言うことで、2022年の締めくくりは、リリースした曲の中から再生回数だけのTop5を選んで締めくくりたいと思いますw
ちなみに、GarageBand進化しすぎてて、すげーなと言う話は、GrageBandの進化はすごいね（多分、周回遅れwを参考にしてください。

では早速！（2022/12/31 9:30時点結果です）

第５位　
Loops in Clouds / N + 1 Loops : 2022/11/21 released 再生回数: 323

これ、スラップベースで何か作りたいと思って、AppleLoopsを探し回りやっと見つけた〜！ベースラインをチョップしまくって作ったやつです。自分でもお気に入りではありますが、GarageBandは使いこなせてなくて、結構苦しんだ曲でもありました。
ギターは、Nile Rodgers風のがいいなーと思ってたのですが、まあこんな感じにおさまりましたw

続きを読む "Mac De Oracle 2022年最後のエントリーは、MacネタというかDTMネタで :)"

iMovieでクロマキー合成する / FAQ Tweet

久々の、Macネタです

最近、GarageBandで曲を作った後、iMovieでフリー映像コンテンツと合わせYouTubeで公開しているのですが、クロマキー合成できることを知った（何周遅れだろうw）

では、試してみましょう。

いくつか試したところ白黒のもできることに気づく！

使い方は簡単で、背景になる動画の上部にグリーン、ブルー、ブラックの動画を置く。ベースとなる動画と繋がるリンクが現れるのでわかりやすいはず。
その後、赤丸で囲ったドロップダウンメニューから、「ブルー/グリーン」を選択すれば、グリーンとブルー背景の動画は簡単に合成できる。

ブラック背景の動画はそれだけではうまく合成できず、横に並んでいる「クリーンアップ」から消しゴムアイコンを選択して動画の背景になる部分をクリックするとブラック背景の動画もいい感じで合成してくれる。簡単！！

続きを読む "iMovieでクロマキー合成する / FAQ"

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

さて, 恒例のアドベントカレンダーのおまけw

Day25で, 性能面で気になる部分のコメントしていた点を思い出してください. INDEX UNIQUE SCANを繰り返している点. 問題にならないなら良いのですが, （データ件数がそれ以上増加しなければ, 安定した処理時間にはなるわけですが....)
データ量次第の危さを感じますとコメントしていた点を思い出してください.

では, 私が, 懸念しているINDEX UNIQUE SCANの回数をSQLモニターという名の内視鏡的な方法で診ていきましょう.
VW_LAT_E87C3AAFのLATERALビューに変換されている操作以降がSUPERTYPE表のヒット件数分繰り返されています. この部分こそ, "データ量次第の危さ”と言った理由です.

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

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

Previously on Mac De Oracle...
Day 24は, SQL MACROにフォーカスをあてました. SEMI JOINだろうと思ってた方々 m(_ _)m 元々今日のネタの伏線をはろうとしていたので, いずれにしても, SEMI JOINではなかったのですがw

と, いうことで Day 25！
ついに, アドベントカレンダー　実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022も千秋楽です

最終日ですので, 大人の事情に金縛りに会いながらも, 頑張って作ってしまったと思われる, 稀に, よくみるタイプのモデルを, それぞれのバージョンのOracleオプティマイザが, どう最適化しようと苦労しているのか, 実行計画というレントゲンを通し, 生暖か, いや, 熱い眼差しでワイン片手に, 観察しつつ, アドベントカレンダー　実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022を締めくくりたいと思います. （オチはないかもw）

当医院に担ぎ込まれてきたSQL文を問診してみると, こんな感じに見えました. （スーパータイプ, サブタイプテーブルを大人の事情で無理強いされて出来上がってしまったような危うい雰囲気であります. 本題はモデルの良し悪しではないので, これ以上, ツッコまないよ）

ということで, 稀によく見るタイプの患者さんを図に起こしてみました. ん〜, かなり複雑な事情がありそうですね！
参考までに, スーパータイプ, サブタイプの概念モデルの実装方法についてはいくつかのパターンがあります. サブタイプがニコイチになっている割に, 結合キーが２個というところが大人の事情を強く感じますが.
（スーパータイプ, サブタイプよくわからんという方は, 斜め読みするならスーパータイプ／サブタイプのテーブルへの実装 / hmatsu47が良いかなと思います）

他に, 外傷がないか SQL文　を診ておきましょう, SQL文はこんなでした. ANSI構文でなければ, こうはならないですよね. Oracleの方言では結合条件のORは書けないので, UNIONで書くことになるのですが, Oracleの方言でこれを書こうとすると割と大変です. UNIONで書いた方が割と無難な実行計画に最適化されやすいというのもありますが, さて, ANSI構文ではどうなりますか. .
（SQLは雰囲気が伝わるように作ってありますw）

SELECT *
  FROM
    supertype st
    LEFT OUTER JOIN nikoichi_mitaina_subtype nmst
    ON
      st.pkey = nmst.col1
      OR st.pkey = nmst.col2
;

では, 実行計画という名のレントゲンを11gR1, 11gR2, 12cR1, 12cR2, 18c, 19c, 21cで, 最適化の違いを診ていきましょう. なお, 隠しパラメータ含めパラメータはデフォルト設定です.
データの準備

SCOTT@orclpdb1> @day25-0
  1* DROP TABLE supertype

表が削除されました. 

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

表が作成されました. 

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

表が削除されました. 

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

表が作成されました. 

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

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

経過: 00:00:02.83

現時点でリリースされている最新版, 21cから順に, 11gR2まで遡って診ていきます

続きを読む "実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 25 / No.60 / ANSI JOIN"