2026年4月に作ったLoop Tweet
Too many Loops / N + 1 Loops
これ作ってる時にイントロ部分のシンセ使ったダブバージョンが浮かんで即作ったのだが、その後v1.1リリースしたので、こいつだけ。ということにしておくw
2026年5月 9日 (土)
2026年4月10日 (金)
2026年3月に作ったLoop Tweet
Stare blankly Loops / N + 1 Loops
これも粛々と仕事をこなすときの無限ループBGMとして思いつきでつくったやつの一つ。
Cherry Blossom Loops 2026 / N + 1 Loops
ちょうど桜が咲いてたので今年バージョン（昨年も作ってたけどねw）。前述のループのドラム部分だけ気に入ってたので、他にも再利用したいなー思いつつ。他にも思いついたので今月は別のを作ってるわけですけどもねw。
2026年3月22日 (日)
2026年2月に作ったLoop Tweet
Loops and Loops! / N + 1 Loops
先月作ったループのドラムトラックが気に入りw再利用してなにかを作るということだけが目的で作ってみた一つ目。
Heavy Query Blues Loops / N + 1 Loops
ブルース風になったが、それなりに雰囲気でたかもw これもドラムトラックの一部は先月作ったループのを再利用してます。
2026年3月10日 (火)
x86/64 VMs on VirtualBox for macOS - Apple Silicon / Oracle Database , PostgreSQL, MySQL rebooted! :) Tweet
さてさて、半年振りぐらいの、VirtualBox for macOS / Apple Silicon ネタです。
前々回のVirtualBoxエントリーで、VirtualBox 7.2でもフラグを立てれば x86/64 VMsを起動できるところまでは確認できました。ただし、Oracle Databaseは起動できませんでしたよね。
しばらく、忙しくて忘れてたので、久々に試してみたら、なんと！！！！！！！ 起動するじゃあーーーーーーーーーりませんか。;)
これで、x86/64版の古いOracle Databaseとの比較ネタなんてのみできちゃうので、遅くても嬉しい。VirtualBox Teamのみなさん、ありがとう！
では、その記録です。
ホスト環境
oracle@Mac-Studio ~ % ./print_env.sh
*** mac info. ***
ProductName: macOS
ProductVersion: 26.3.1
BuildVersion: 25D2128
*** maxOS ver. ***
Model Name: Mac Studio
Chip: Apple M1 Ultra
Total Number of Cores: 20 (16 Performance and 4 Efficiency)
Memory: 64 GB
*** VirtualBox ver. ***
7.2.7r173034
oracle@Mac-Studio ~ % VBoxManage getextradata global "VBoxInternal2/EnableX86OnArm"
Value: 1
起動していいるVirtualBox VMsとArchitectureの確認
oracle@Mac-Studio ~ % VBoxManage list --long runningvms | grep -E 'Platform Architecture|Name'
Name: Oracle Linux 8 21c and postgresql13
Platform Architecture: x86
Name: Oracle Linux 8 mysql8 postgrsql13
Platform Architecture: x86
2026年2月18日 (水)
ミックの楽しいSQLパズル / 書籍 Tweet
ミックさん、インプレス様から恵贈いただきました。 :)
馴染みやすいタイトル。
SQLパズル本！
ぶ、ぶ厚いw
1日、1SQLパズルにチャレンジするか
ありがとうございました
2026年2月 8日 (日)
2026年1月に作ったLoop Tweet
Winter Loops 2026 / N + 1 Loops
2022年にGarageBandをrebootしたときに作ったWinter Loopsを新たに作ろうとおもったが、今聞くと最初のやつのニュアンスに近いほうがよかったのかもねとかw
Winter Sunny Loops / N + 1 Loops
で、Winterでもいい天気の日はぼーっとできたりしていいかなとおもいつつ、先のLoopのドラムトラックをほぼ流用しつつ載せるものをかえてみたやつ。
WOW Loops! / N + 1 Loops
作ってて面白かなと思うのはFUNK系の路線であることを再認識w
前の2つのLoopでも使っていたドラムセットをさらに流用しつつテンポとリズムを少々かえて、さらにFUNKなループをチョップしたりまんまつかったり、VOXで遊びつつできたのがこれ。
Logic ProにAI来るって話もありますが、GarageBandのメジャーアップデートはどうなるんだろうね。。。。
ではまた。
Enjoy DTM, GarageBand!
2026年2月 5日 (木)
Oracle Database - Multi Row INSERT、バインド変数を使うとリテラル値を使う場合では見える景色が変わるんだよね #最終回 - ぐるぐるしちゃう影響 Tweet
Previously on Mac De Oracle
Oracle Database - Multi Row INSERT、バインド変数を使うとリテラル値を使う場合では見える景色が変わるんだよね #4 - The SQL was transformed!
前回は、Multi row Insertをリモート表へインサートするとSQL transformの影響で、
DUAL表アクセスがオーバーヘッドとなり Multi row Insertのメリットが削がれてしまう（現時点の仕様では）ということを確認しました！
偶々リモート表に実行したから気づけたわけですがw。あの仕様に気付けたのはラッキーというべきかw
ということで、脇道にそれまくったこのシリーズも、やっと最終回です！
リモート表を使ってぐるぐるしてネットワークラウンドトリップを乗せる必要はなくて、
それが自然に乗るAPサーバーとDBサーバー間の状況を作ればよいだけなので、
最終回は素直にw
JavaからOracle Databaseへアクセスしローカル表に対してぐるぐるしちゃいながら、
Single row insert を繰り返すぐるぐる系と、
Multi row insert を利用して、ゆるやかに、ぐーるぐーるするタイプで 100,000 行を登録してみようと思いますw
N+1問題の類とネットワークラウンドトリップとネットワークレイテンシーと、コミット間隔などパラメータは多いですが、だいたい 100 - 1000 行程度付近前後にリーズナブルなポイントが現れていますよね。。。
(ちなにみSQL*Netのパラメータ等はデフォのままです。また、リモート表ではないので、OPEN_CURSORSもデフォルトのままの 300 で問題ありません。参考まで)
バインド変数利用と、どの程度の単位でまとめてインサートするか、コミットの間隔など沢山のパラメータがあるので、そららの様子をみながら表を見てもらうと面白いと思います。
なお、いつものように後半にログと利用したコードなどをまとめて載せています。
（今回は、生成AIのGeminiくんにサクッと書いてもらいましたw）
Multi Row Insertで、100 - 1000行程度まとめるとメモリにもCPUにも優しくなりますね。単純に、1行毎ぐるぐるすると無駄が多くなるのは一目瞭然だと思います。
2026年2月 4日 (水)
Oracle Database - Multi Row INSERT、バインド変数を使うとリテラル値を使う場合では見える景色が変わるんだよね #4 - The SQL was transformed! Tweet
Previously on Mac De Oracle
前回は、Oracle Database - Multi Row INSERT、バインド変数を使うとリテラル値を使う場合では見える景色が変わるんだよね #3 - ローカル表とリモート表での挙動の差異？！ でした。
復習を兼ねて、前回の表（再掲）をみつつ。23aiでサポートされたMulti row Insert文をローカル表とリモート表（via DB Link）へ実行してみると。。なんと。想定外の結果に。。。
v$mystatから得られた統計値をみると、execution countやparse count (total) - parse count (hard) それに伴うパースタイムなどなど、一体何が起きてるの。。。。。（ニヤニヤ
という感じでした。
さらに、リモート表に対して、1,000 rows / INSERT で Multi row Insert すると、OPEN_CURSORS = 300（default）では足らず、 1,300まで増やすと不足しないという、状況。
なにか引っかかりますよね。単純にSQLをまるっとリモートDB (インスタンスは同じだけど、DB Linkでパススルーして投げているだけでは？？。。。と思っていたが) へ投げているだけではなさそうな様子。
ということで、その謎を追い Oracle Database の奥へ進んでいきましょう ;)
2026年2月 3日 (火)
Oracle Database - Multi Row INSERT、バインド変数を使うとリテラル値を使う場合では見える景色が変わるんだよね #3 - ローカル表とリモート表での挙動の差異？！ Tweet
Previously on Mac De Oracle
前回は、
Oracle Database - Multi Row INSERT、バインド変数を使うとリテラル値を使う場合では見える景色が変わるんだよね #2
このシリーズものの本題でした。（それ書くまでの寄り道が長かったわけですがw）
ということで今日は、その続編！！
前回で完結じゃないの？！
はいw 、というか再び、脱線していきます！ www
前回使った無名PL/SQLブロックのスクリプト（バインド変数を使っている方だけですが）を使って、ローカル表とリモート表（via Database Link)へMulti row Insertするとどうなるのか？
（覚えていますか？ 前々回、いろいろなバグやら未実装やらのエラーにハマりまくり、なんとかリモート表へMulti row Insert文を投げることに成功した話を。。。。）
ローカル表とリモート表だとどのような景色の違いがあるか、絶対、Network Round Trips（dblinkの）が増加するよね！！！
だとすると、差分（処理時間など含め）の多くは、そのDatabase Linkを介して発生するNetwork Round Trips部分だけのはず。。。ネットワークレイテンシーの影響が見えやすくなる？ だろう。。。。。か。
（PL/SQLだからリモート表にするしかなかったのですが、本来なら、JavaやらPythonやらアプリケーションから実行するだけでその部分は見えるわけですけどもね。一応、PL/SQLでやってた流れで、やってみようかなと。。。。w 数々のバグやら仕様やらにハマりましたが。。。w）
ログが長いので、まとめから！w
ポイントになりそうなところだけv$mystatからまとめた表ですが、一目瞭然で、妙な箇所があります。
私が、事前に想定していたのは、execute countはローカル表と同じ値ですし、当然ですが、parse count (total) - parse count (hard) の数もローカル表と同じ想定でした。100rows付近がもっとも結果が良いのはどちらでも同じではあるのですが。。
また、それらに加えて、1,000rows/INSERTにしたケースでは、リモート表へのINSERTで、OPEN_CURSORS(デフォルト 300)が枯渇し、+1,000の 1,300に増加すると枯渇しかなった点です。1,000rowsの時に+1,000したOPEN_CURSORSで枯渇回避になるというのも、気になりますよね。。。。。
SQL*Net roundtrips to/from dblinkが乗ってくるのは、想定通りですが、なんとなく数も多めですしね。。。なんだろうこの違和感w。。。。
想定していた挙動と随分違いそう。。。。DB Linkをつかっちゃったからからもしれないですけども。。。。。。。。
2026年2月 2日 (月)
Oracle Database - Multi Row INSERT、バインド変数を使うとリテラル値を使う場合では見える景色が変わるんだよね #2 Tweet
Previously on Mac De Oracle
前回は、
Oracle Database - Multi Row INSERT、バインド変数を使うと、リテラル値を使う場合では見える景色が変わるんだよね #1 - バグなのか現時点の仕様なのか?
でした。本題からちょっと脱線気味でしたがw、今日は、Multi Row INSERT、バインド変数を使うとリテラル値を使う場合では見える景色が変わるんだよね。の本題。（やっとw）
前々回、帰ってきた！ 標準はあるにはあるが癖の多いSQL #22 - Multi Row INSERTのようにリテラル値のままでMulti row Insertしちゃうと言う無茶なことやっていると、いくらメモリ(メモリだけでもないけども)があったも足らなくなるよなーーー。というのはイメージできたと思うので、今日はバインド変数化すると景色がどう変わるか（良い方に）見てみましょう。
Use The Bind Variable, Luke!
メモリ消費も抑えられますし。ハードパースコストも下げられますし。:)
特にOracle Databaseのようにハードパースなど比較的重量級かつカーソルシェアリングなど含むキャッシュ機能満載のRDBMSでは絶大な効果を発揮します。はい。
リテラル値のままのmulti row insertとバインド変数化した場合のPGA周り含めた景色、どうかわるでしょうねぇ。。。。（そんなことわかっとる！ と言う方は見なくて良いです ;)
前回色々ハマりながら作ってたw 無名PL/SQLブロックを含むスクリプトを利用（Geminiくんにもお手伝いしてもらいw）して、ローカル表（リモート表の話は別ネタにてw）へアクセスして、バインド変数有無でそのような景色の違いがでるかを見てみましょう。
23aiでサポートされたMulti row Insert構文で、10行、100行、1000行まとめてインサートする文のPGA/UGAの最大サイズを比較。
バインド変数を利用せず、1000行まとめたMulti row Insertでは、SQL文をCLOBで保持した影響で、PGAから溢れて、一時LOBを利用した影響で、log write/readが発生。PGA/UGAは多少減り、変わり一時表領域へのIO増加ということからパース時間が随分伸びたことがわかります！
バインド変数を利用した場合とのPGA/UGA消費サイズ、および、パースタイムは大幅に軽減されていて、各種リソースにも優しくなっているのが見えますよね！(ハードパース回数でも一目瞭然)
あと、傾向として、100行毎ぐらいにまとめるのが全体的にリーズナブルな傾向はありますよね。（この前後がリーズナブルって肌感覚とも一致してるんですよね。何行ぐらいにしようかなー。と探る時もだいだいこれぐらいの前後一桁ずらしてってことは多いかな）
パース時間とPGA/UGAの最大サイズ比較
2026年1月27日 (火)
Oracle Database - Multi Row INSERT、バインド変数を使うと、リテラル値を使う場合では見える景色が変わるんだよね #1 - バグなのか現時点の仕様なのか? Tweet
Previously on Mac De Oracle
前回は、
帰ってきた！ 標準はあるにはあるが癖の多いSQL #22 - Multi Row INSERT でした。
TVC(Table Value Constractor)の流れではあったのですが、通常やるとは思えないリテラルを使ったMulti row insertで大量の行を詰め込んでみました！
TVCはともかく、Multi row insertをリテラル値で、かつ、大量の行を詰め込むのはリーズナブルな方法ではないですよね。特にOracle Databaseでは。というあたりに気づければそれで良いと思います:)
PostgreSQL/MySQLは幾分マイルドなw 結果でしたが、Oracle Databaseは、らしい特徴がでていましたよね。
ハードパースコストがめちゃめちゃ高くて。
そういえば、
以前、
パースが重いぞーというネタをやってたことありましたが、取り上げたハードパースがキツくなるネタは、Oracle Databaseで索引のある列に対してIN句を使い大量の値をセットするネタでした。（これ意外と見かけます）
それ以外のケースだと、MySQLで結合する表が多くて考え過ぎてるケース。
どちらも実行計画を立てるためにオプティマイザが考え過ぎてしまう（得られる実行計画は良いのですが）ことでパース時間が異常に長くなる症状でしたよね！
悩ませ過ぎは及ばざるがごとし #3
悩ませ過ぎは及ばざるがごとし #4
悩ませ過ぎは及ばざるがごとし #7 - おまけ
悩ませ過ぎは及ばざるがごとし （MySQL 8.0.32編）
ただ、今回取り上げたOracle DatabaseのINSERT(Multi row insert)は、どちらかというとメモリリソース確保の影響が色濃い状況でした。（パース時の帯域イベントもほぼそれだけ）
リテラル値を使い、大量の行を詰め込んだ巨大なmulti row insert文を実行するのは考えものですよね。まじでw
前置きはそれぐらいにして、
前回、そんなことやる人いないでしょーっ、というノリで、リテラル値を使い巨大なMulti row insertを行いましたが、
通常なら、バインド変数使いますよね！ 絶対！w
ということで、バインド変数を利用したMulti row insertの準備をしていた際に気づいたバグというか現時点の仕様というかなんというかw にハマった記録です！ が今回のネタ。
（Oracle Database 23ai FREEのPL/SQLからの実行だと、現時点では、EXECUTE IMMEDIATEを利用してバインド変数化することぐらいしかできなそう！）
まじで？！ という状況なので、細かい確認は次のリリース以降で再度試してみようかなと。
2026年1月 8日 (木)
帰ってきた！ 標準はあるにはあるが癖の多いSQL #22 - Multi Row INSERT Tweet
Previously on Mac De Oracle
と言いたいところですが、前回は、読了ネタだったのでw 前々回の話に関連して。。。
前々回は、帰ってきた！ 標準はあるにはあるが癖の多いSQL #21 - Table Value Constructer（TVC）- ハードパース時間とメモリ消費量 / BONUS TRACKでした。
おまけのおまけ的な内容で前々回のネタと関連はあるのですが、TVCではなく、Multi Row INSERTの癖の確認というか、メモリ消費量などの傾向を、肌感覚で覚えておきましょうね。 というネタです。
Oracle Databaseで以下のような表を作成、PostgreSQL/MySQLでも同様に作成しておきます。
create table mrows_ins_tab
(
id integer not null primary key,
col1 varchar2(1000),
col2 varchar2(1000),
col3 varchar2(1000),
col4 varchar2(1000),
col5 varchar2(1000),
col6 varchar2(1000),
col7 varchar2(1000),
col8 varchar2(500)
);
Oracle Databaseの方言、multi table insertの対象を単一表にしてmulti row insertのPGA消費傾向を見る。
行数を変えつつ以下のようなINSERT ALL文にて検証。
SCOTT@localhost:1521/freepdb1> !cat sql_mrows_ins_5000.sql
INSERT ALL
INTO mrows_ins_tab(id, col8) VALUES(1,
'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1')
...略...
INTO mrows_ins_tab(id, col8) VALUES(5000,
'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx5000')
SELECT * FROM dual;
手始めに5000行をガツンとINSERT ALLにて。この程度の行サイズと行数でも300MB超えのPGA消費ですね。
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.8.0.25.04
に接続されました。
SCOTT@localhost:1521/freepdb1> @show_mystats.sql
SID NAME VALUE
---------- ---------------------------------------------------------------- ----------
39 CPU used by this session 4
39 CPU used when call started 3
...略...
39 session pga memory 4254712
39 session pga memory max 5123744
39 session uga memory 1844408
39 session uga memory max 3053904
...略...
SCOTT@localhost:1521/freepdb1> @sql_mrows_ins_5000
5000行が作成されました。
経過: 00:00:05.95
SCOTT@localhost:1521/freepdb1> @show_mystats.sql
SID NAME VALUE
---------- ---------------------------------------------------------------- ----------
39 CPU used by this session 550
39 CPU used when call started 550
...略...
39 session logical reads 26402
39 session pga memory 88534008
39 session pga memory max 339274744
39 session uga memory 84055376
39 session uga memory max 85103896
...略...
2026年1月 2日 (金)
クリスマスに届けられた「NewSQL徹底入門」読了 Tweet
新年、最初のエントリは、珍しく、読書の話題からw
昨年、クリスマスに届けられた「NewSQL徹底入門」
正月のお楽しみに残しておいたのですが、駅伝往路も終わり、Netflixでストレンジャーシングスも観終り読み始めたら、
一気読みしてしまったw
NewじゃないSQLerの方もNewSQL怖くない！、という程度にNewSQLの基本を把握できるような一冊ではないだろうか。
ただ、今のところNewSQLもいろいろと癖が強かったり、多いのも事実なので、
Multi-purpose databasesの一つとしての選択肢と考えるのもよいだろうし、
未来の？ Converged Databaseかも？なんてワクワクしながら追いかけるのもよいだろうし。
データベース界隈は相変わらず、飽きないネタを提供し続けてくれて楽しいですね。ほんとに。
2025年12月26日 (金)
帰ってきた！ 標準はあるにはあるが癖の多いSQL #21 - Table Value Constructer（TVC）- ハードパース時間とメモリ消費量 / BONUS TRACK Tweet
https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2025/12/post-d04e78.htmlのおまけです！
前回は、マニュアルでは言及されたりしていますが、TVCで多くの行を生成するのは複数の問題を引き起こしそう。。。
Oracle Databaseでは生成行数上限があるのですが、なにか異様に時間がかかってました。どのあたりだろう？。とか
MySQL/PostgreSQLは行数こそ制限されてないようですが、メモリ消費には影響しそうだよなぁ。
というあたり気になりますよね。今日はその辺りをざっくりと確認しておこうという。
マニュアルでも言及されてるし、TVCで大量行生成しねーーーだろーーーっ。
とも思うわけですが、世の中広いので、油断禁物ww
それやっちゃうと、実際にどうなりそうかって、肌感覚で知ってたほうが良いだろうという意図もあり。
まずは、
前回利用したSQLをCOUNT(1)に書き換えたものを利用します
Oracle Databaseの例(MySQLではRVCを利用する点以外違いはありません）
e.g.
sql_oracle_65534.sql
SELECT COUNT(1) FROM ( VALUES
(1)
,(2)
,(3)
,(4)
...略...
,(65530)
,(65531)
,(65532)
,(65533)
,(65534)
) t1 ( id )
/
環境はいつものとおり、arm64向け Oracle Database/MySQL/PostgreSQL環境をVirtualBox for macOS / Apple Siliconにて
oracle@Mac ~ % ./print_env.sh
*** mac info. ***
Model Name: MacBook Air
Chip: Apple M2
Total Number of Cores: 8 (4 performance and 4 efficiency)
Memory: 24 GB
*** macOS ver. ***
ProductName: macOS
ProductVersion: 26.2
BuildVersion: 25C56
*** VirtualBox ver. ***
7.2.4r170995
[master@arm64-oraclelinux8u10 ~]$ cat /etc/oracle-release
Oracle Linux Server release 8.10
[master@arm64-oraclelinux8u10 ~]$ uname -r
5.15.0-313.189.5.3.el8uek.aarch64
以降, 変化確認のために実行時間も記録しておきます
PostgreSQL 17.6だと、29ms程度。
[postgres@Oracle-Linux-8u10-arm64-2 ~]$ psql -U scott -d perftestdb -h localhost
Password for user scott:
psql (17.6)
Type "help" for help.
perftestdb=> \timing
Timing is on.
perftestdb=> select version();
version
---------------------------------------------------------------------------------------------------------------
PostgreSQL 17.6 on aarch64-unknown-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-26), 64-bit
(1 row)
Time: 1.848 ms
perftestdb=>
perftestdb=> \i sql_postgresql_65534.sql
count
-------
65534
(1 row)
Time: 28.617 ms
MySQL 8.4.7 だと 60ms程度のようですね。
[master@Oracle-Linux-8u10-arm64-2 ~]$ mysql -u root -D perftestdb -p -h localhost
Enter password:
...略...
mysql> select version();
+-----------+
| version() |
+-----------+
| 8.4.7 |
+-----------+
1 row in set (0.00 sec)
mysql>
mysql> \. sql_mysql_65534.sql
+----------+
| COUNT(1) |
+----------+
| 65534 |
+----------+
1 row in set (0.06 sec)
さて、今日の真打w Oracle Database、
前回のエントリで気づいたかもしれませんが、Oracle DatabaseのTVCどうやらハードパースにものすごく時間がかかっている雰囲気。
かといってソフトパースでも17秒ぐらいなので決して速くはないのですが、ハードパース時間がすごいですね。
[oracle@arm64-oraclelinux8u10 ~]$ sqlplus scott@localhost:1521/freepdb1
...略...
SCOTT@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.8.0.25.04
-- ハードパースだと..
SCOTT@localhost:1521/freepdb1> @sql_oracle_65534.sql
COUNT(1)
----------
65534
経過: 00:50:43.88
-- ソフトパースだと...
SCOTT@localhost:1521/freepdb1> @sql_oracle_65534.sql
COUNT(1)
----------
65534
経過: 00:00:17.99
ということで、Oracle Database。ハードハース時間が長いのですが、もう少し掘り下げて覗いてみようと思います。
10046トレース（久々w）でログをとって追ってみます。
SCOTT@localhost:1521/freepdb1> alter session set tracefile_identifier='10046_tvc';
セッションが変更されました。
SCOTT@localhost:1521/freepdb1> alter session set statistics_level=all;
セッションが変更されました。
SCOTT@localhost:1521/freepdb1> alter session set max_dump_file_size = unlimited;
セッションが変更されました。
SCOTT@localhost:1521/freepdb1> alter system flush shared_pool;
システムが変更されました。
SCOTT@localhost:1521/freepdb1> alter session set events '10046 trace name context forever,level 12';
セッションが変更されました。
SCOTT@localhost:1521/freepdb1> @sql_oracle_65534
COUNT(1)
----------
65534
経過: 00:43:01.31
SCOTT@localhost:1521/freepdb1> alter session set events '10046 trace name context off';
セッションが変更されました。
[oracle@arm64-oraclelinux8u10 trace]$ ls -l *10046_tvc*
-rw-r-----. 1 oracle oinstall 1289063 Dec 25 20:36 FREE_ora_5169_10046_tvc.trc
-rw-r-----. 1 oracle oinstall 18615 Dec 25 20:36 FREE_ora_5169_10046_tvc.trm
[oracle@arm64-oraclelinux8u10 trace]$ tkprof FREE_ora_5169_10046_tvc.trc FREE_ora_5169_10046_tvc.trc.txt explain=scott/tiger@localhost:1521/freepdb1 sys=yes waits=yes aggregate=no
...略...
2025年12月25日 (木)
ミックさんからクリスマスプレゼントが届いた:) / New SQL徹底入門 Tweet
ミックさんからクリスマスプレゼントが届いた:) ありがとうございます！ / New SQL徹底入門
正月休み読もうと思ってます。 楽しみ。
最近のコメント