Mac De Oracle: Apple Silicon ARM64

DROP SHADOW CTRL

TEXT DROP SHADOW OFF

GaragebandとiMovieで

検索

検索用語を入力

Web Blog内

検索フォームを送信

プロフィール

Twitter

Tweets by @discus_hamburg

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

最近のトラックバック

[memo]メモを取りつつ楽しめるようなスタイル (wmo6hash::blog)
ダーリンはGoogleで軽食なり。 (今日のゴハン)
�� プログラムは読む時間の方が長い - 遥か彼方の彼方から (�� プログラムは読む時間の方が長い - 遥か彼方の彼方から)
今流行のケブンリッジ関数・・・しってました！？ (あにずむ)
poken (drmarのメモ)
Photo exhibition "Natural Faces of AIDS Orphans"　写真展「エイズ孤児の素顔」@JICA地球ひろば　広尾 (メガ放談)
創る心とおもてなし―第1回 Webエンジニア料理対決に参加する (Kwappa開発室)
創る心とおもてなし～第一回webエンジニア料理対決に参加した (Mac De Oracle)
徹底比較!! PostgreSQL vs MySQLパート2 with 勝手に vs Firebird (14) (キムラデービーブログ)
Oracle de XMLDB #18 (discus)

Oracle

OTN US

Apple

その他

ブログ de ノベルティ
ノベルティグッズをただ、ただ、記録していくブログ。Mac De Oracleでは出来ないネタなので、別ブログを立てた次第。

Googleの広告

RSS

RSSを表示する

当サイトについて

プライバシーポリシー

■プライバシーポリシー

■個人情報の利用目的

　当ブログでは、メールでのお問い合わせ、ブログへのコメントの際、名前（ハンドルネーム）等の個人情報をご登録いただく場合がございます。これらの個人情報は質問に対する回答などでご連絡する場合や、スパムコメント抑止のために利用させていただくものであり、個人情報をご提供いただく際の目的以外では利用いたしません。

■個人情報の第三者への開示

　当サイトでは、個人情報は適切に管理し、以下に該当する場合を除いて第三者に開示することはありません。

本人のご了解がある場合
法令等への協力のため、開示が必要となる場合

個人情報の開示、訂正、追加、削除、利用停止については、ご本人からの個人データの開示、訂正、追加、削除、利用停止のご希望の場合には、ご本人であることを確認させていただいた上で速やかに対応させていただきます。

■アクセス解析ツールについて

　当サイトでは、Googleによるアクセス解析ツール「Googleアナリティクス」を利用しています。このGoogleアナリティクスはトラフィックデータの収集のためにCookieを使用しています。このトラフィックデータは匿名で収集されており、個人を特定するものではありません。この機能はCookieを無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。

目的：アクセス数を把握するため
送信先：Google LCC
Googleは受け取った情報をどのように利用するか：Googleの規約に従います
送信される情報：以下４点(R), ユーザー数、セッションの統計情報、おおよその位置情報、ブラウザとデバイスの情報

■広告の配信について

当サイトはGoogleの広告を配信しています。

Googleについて

Google及びGoogleのパートナー（第三者配信事業者）の提供する広告を設置しております。その広告配信にはCookieを使用し、当サイトやその他のサイトへの過去のアクセス情報に基づいて広告を配信します。

Google が広告 Cookie を使用することにより、当サイトや他のサイトにアクセスした際の情報に基づいて、Google やそのパートナーが適切な広告を表示しています。

お客様はGoogleアカウントの広告設定ページ（https://adssettings.google.com/u/0/authenticated）で、パーソナライズ広告を無効にできます。また aboutads.info のページにアクセスして頂き、パーソナライズ広告掲載に使用される第三者配信事業者のCookieを無効にできます。

その他、Googleの広告におけるCookieの取り扱い詳細については、Googleのポリシーと規約ページ（https://policies.google.com/technologies/ads）をご覧ください。

■免責事項

　当サイトからリンクやバナーなどによって他のサイトに移動された場合、移動先サイトで提供される情報、サービス等について一切の責任を負いません。当サイトのコンテンツ・情報につきまして、可能な限り正確な情報を掲載するよう努めておりますが、誤情報が入り込んだり、情報が古くなっていることもございます。当サイトに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。

■プライバシーポリシーの変更について

　当サイトは、個人情報に関して適用される日本の法令を遵守するとともに、本ポリシーの内容を適宜見直しその改善に努めます。
修正された最新のプライバシーポリシーは常に本ページにて開示されます。

2026年6月13日 (土)

帰ってきた！　標準はあるにはあるが癖の多いSQL #23 - 直近データの結合方法。オールドファッションな構文 vs. モダンな構文。

新しい期間に切り替わり2026.6-2027.5期も Oracle ACE Pro となりました。:)　で、新シーズン最初のエントリー。

今日のテーマは、
直近データの結合方法、オールドファッションな構文 vs. モダンな構文。そして、今回の癖はSQL文というよりも、その実行計画や挙動にあります！！！！お楽しみに！
(そういえば、モダンな　って表現、外資系方面の会社でよく使われますよね。RDBMS界隈でも。むかーーし、そこが気になり過ぎて眠れなくなったことがありましたw　モダンとは、、、みたいなw)

ところで、みなさん、
表にバージョン、タイムスタンプやらで履歴データを含があり、直近のデータとだけ結合したいなんてことないですかね。。。。意外と多いのかなぁ。履歴は履歴だから分離するとうのもあるわけですけども。
データ量にしても、少量データ（OLTP）から大量データ(BATCH、DWH etc)までいろいろです。

と、いろいろなケースはあるのですが、OLTP向けには、どのような構文で行うのがよいだろうというところにフォーカスしたいと思います。
（少量でもそこそこいけるし、大量データでもパラレル化しちゃっていい感じになる方法もあれば、そうでもない方法まであるわけですけども）

今回も面白い癖というか特徴を見ることができますよ。 ;)

データの準備（各データベースに同じ表、索引、データを用意します。以下、PostgreSQLの定義）

perftestdb=> \d+ master
                                          Table "scott.master"
 Column |  Type   | Collation | Nullable | Default | Storage | Compression | Stats target | Description 
--------+---------+-----------+----------+---------+---------+-------------+--------------+-------------
 id     | integer |           | not null |         | plain   |             |              | 
Indexes:
    "master_pkey" PRIMARY KEY, btree (id)
Access method: heap

perftestdb=> \d+ detail
                                                 Table "scott.detail"
 Column |         Type         | Collation | Nullable | Default | Storage  | Compression | Stats target | Description 
--------+----------------------+-----------+----------+---------+----------+-------------+--------------+-------------
 id     | integer              |           | not null |         | plain    |             |              | 
 vnum   | integer              |           | not null |         | plain    |             |              | 
 col1   | character varying(1) |           |          |         | extended |             |              | 
Indexes:
    "pk_detail" PRIMARY KEY, btree (id, vnum)
    "ix2_detail" btree (vnum)
Access method: heap

id=200に該当するdetail表のデータは存在しない状態にしてあります。

perftestdb=> SELECT id FROM master ORDER BY id;
 id 
----
  1
  2
  3
  4
  5
200
(6 rows)

各id毎のvnumの個数は以下のとおり. id=300は100,000個あります。また直近データは、最もvnumが大きいものという設定です。
OLTPを想定しているので、履歴データがどう影響するかしないのかも見るために多めにしてあります。

perftestdb=> SELECT id,COUNT(vnum)  vnum_cout FROM detail GROUP BY id ORDER BY id;
 id  | vnum_cout 
-----+-----------
   1 |         3
   2 |         1
   3 |       100
   4 |        98
   5 |        98

...略...

  97 |        98
  98 |        98
  99 |        98
 100 |        98
 300 |    100000
(101 rows)

perftestdb=> SELECT id,vnum,col1 FROM detail WHERE id = 300 ORDER BY vnum DESC FETCH FIRST 10 ROWS ONLY;
 id  |  vnum  | col1 
-----+--------+------
 300 | 100000 | 1
 300 |  99999 | 1
 300 |  99998 | 1
 300 |  99997 | 1
 300 |  99996 | 1
 300 |  99995 | 1
 300 |  99994 | 1
 300 |  99993 | 1
 300 |  99992 | 1
 300 |  99991 | 1
(10 rows)

トップバッターは、Oracle Database、直近データだけ結合する方法は複数ありますが、オールドファッションな書き方から、比較的新しい構文（モダンな構文としておきますw）の順で試していきます。

1) 不等価結合 + 自己結合による方式
(以下はOracle Database向けにUNNEST最適化を抑止する目的でヒントを利用していますが、
他のRDBMSでは取り除いてください)

この方法、稀ですが、OLTPで見かけることがあります。(危険な香りw)
履歴データが少量であることが確実なら、あまり痛い目にあうことはないとは思います、け、ど、も。
どの辺がやばそうかは、いいませんので、考えてみてください。
（考えるまでもねぇ、脊髄反応してるあなた、さすがですね。(最近のAI風w　褒めるとこから入るw)

SELECT 
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN (
    SELECT
      t2_latest.id
      , t2_latest.vnum
    FROM
      detail t2_latest
    WHERE 
      NOT EXISTS (
        SELECT /*+ UNNEST NL_AJ */
          1
        FROM
          detail t2_all
        WHERE
          t2_latest.id = t2_all.id
          AND t2_latest.vnum < t2_all.vnum
      )
  ) t2
  ON 
    t1.id = t2.id
WHERE                
  t1.id = 300
;

2) MAX()関数 + 自己結合 + スカラー副問合せ方式
この方法もむかーしからよく見ます。王道な方法だと思います。
最適な索引は必須ですが、非常に安定した性能を得られる方法です。
デメリットとして、自己結合が避けられないのと、ぱっと見なにやっているか理解しにくいところかなと。（経験の浅い方は特に！）

SELECT 
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN DETAIL t2 
  ON               
    t1.id = t2.id 
    AND t2.vnum = (
    SELECT 
      MAX(t3.vnum)
    FROM
      detail t3
    WHERE
      t3.id = t1.id 
  )
WHERE
  t1.id = 300
;

3) ROW_NUMBER()ウィンドウ関数方式
(分析系クエリではもうお馴染みのROW_NUMBERウインドウ関数)

この方法、OLTPでも比較的多く、履歴データが多くないのが確実ならリスクは少ない方法ではあります。
自己結合も排除できますし、可読性も良いですよね。
しかし、履歴データ多くないのが確実なら、と書いたように一癖あるので、OLTP で利用する場合少々注意が必要です。
（とことが、PostgreSQLとMySQLそれぞれに、想像してなかった癖がありましたw 良い癖と悪い癖w）
履歴データ量が予測できないのなら避けたほうが良い方法だと思います。（癖の良し悪し次第でもありますがw）
逆にバッチ処理や分析系で大量データを処理するなら得意分野だと思いますよね。
この方法の癖とは何か？　も考えてみてください。:)
なお、この方法は、オプティマイザやプランナの述語プッシュダウン最適化等に依存してます。（ヒントw

SELECT 
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN  (
    SELECT
      id
      , vnum
      , ROW_NUMBER() OVER (
          PARTITION BY 
            detail.id 
          ORDER BY 
            detail.id DESC
            , detail.vnum DESC
      ) AS latest
    FROM
     detail
  ) t2
  ON 
    t1.id = t2.id
    AND t2.latest = 1
WHERE
    t1.id = 300
;

4）LATERAL JOIN + Top 1 Query方式
(なお、PostgreSQL/MySQLでも fetch first n rows only 構文は利用できますが、limit nでも同様、Oracle Database では rownum を使っても同じですが、おすすめは、fetch first n rows only かな。長いけどw)

この方法 OLTP のためにあるようなものなので、うまく活用するといいと思うのですよね。
少量データ返すケースで SELECT リストないで利用するスカラー副問合せのような使い方をイメージしてもらうと良いかなと思います。NLJにしかならないので。
自己結合も排除できることに加え、適切な索引によるソートバイパス、そして、Top 1 Query の活用で無駄のない直近データ取得を可能にしています。

SELECT 
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN LATERAL (
      SELECT
        t2l.id
        , t2l.vnum
      FROM
       detail t2l
      WHERE
        t2l.id = t1.id
      ORDER BY
        t2l.id DESC
        , t2l.vnum DESC
      FETCH FIRST 1 ROWS ONLY
  ) t2
  ON TRUE
WHERE
  t1.id = 300
;

当初、ログ見てもらいつつまとめは後半で、ほう！
みたいな構成で書こうと考えていたのですが、ログがめちゃめちゃ長いので最初にまとめを書いちゃいますねw
（ログを見て、あーだーこーだ考えてもらいつつ、あれがいいよねー、という流れがおもしろいかなーとは思っていたのですけども。。。w　流石に長すぎて疲れるかなとw）

OLTPに適している直近データの結合方法はこれだ！！！！！！

結果としては、各構文の解説でも気づかれたのではないかと思いますが、

LATERAL JOIN + Top 1 Query方式が、OLTPで直近データだけ結合したいという場合には、ベストな選択だろうな。と。
2013年ごろに登場した（内部的にはもっと前から最適化として含まれていたRDBMSもあります）LATERAL JOIN なので、新しいというほどでもないですが、ひとまず、モダンな方法としておきますねw

一方、オールドファッションな方法であるMAX()関数＋自己結合＋スカラー副問合せ方式もかなり良いわけでが、自己結合だけは避けられません。
ここがポイントです。それなりに安定していて良い結果は得られるのですが。

また、どちらの方法も履歴データが大量だったとしても、必要最小限のデータだけを安定してアクセスします。
自己結合を回避できないMAX()関数＋自己結合＋スカラー副問合せ方式では、それが弱点ではあるのですが。

なお、実装の違からMySQLだけは、MAX()関数＋自己結合＋スカラー副問合せ方式のほうが早かったというのは面白い発見でした。（後述）

まとめ
OLTP前提で、直近データを結合するためのおすすめの構文
Oracle Database
モダンな方式である LATERAL JOIN + Top 1 Query 方式

PostgerSQL
モダンな方式である LATERAL JOIN + Top 1 Query 方式
面白い挙動は、 ROW_NUMBER()ウィンドウ関数方式の索引降順スキャンを行い最初の2行目、つまり、直近データを読み終えたところでスキャンを止めること。Oracleには見られない挙動。
MySQLでは、そもそも述語プッシュダウンすらできなかった（不具合？）

MySQL
オールドファッションな方式である MAX()関数 + 自己結合 + スカラー副問合せ方式.
なお、LATERAL JOIN + Top 1 Queryも非常に安定しているが、MAX()関数 + 自己結合 + スカラー副問合せ方式の実行計画はMySQLの実行計画で最強のRows fetched before executionなので勝ち目なしw

では、判断のポイントとなった履歴データが大量に存在する場合の各RDBMSの実行計画を見ていきましょう。（サマリーといっても長いですw）
以下それぞれ、Oracle Linux / arm64 VirtualBox VM上で
Oracle Database 23ai Free Version 23.8.0.25.04
PostgreSQL 17.7
MySQL 8.4.7
で試したものです。

      T1ID       T2ID       VNUM
---------- ---------- ----------
       300        300     100000

のように、履歴が100,000件あり、vnum=100000が最新のデータ（最新バージョン）を外部結合しています。

Oracle Database 23ai Free Version 23.8.0.25.04
MAX()関数 + 自己結合 + スカラー副問合せ方式とLATERAL JOIN + Top 1 Query方式どちらも A-ROWS は 1 で履歴データが多くなってもまったく影響を受けません。
では、どちらがよいかと言えば、detail 表を二度アクセスせず、構文的にも意図を把握しやすい LATERAL のほうがよいですね。
Buffers も LATERAL 方式のほうが少ないですし。
想定通りの結果です。優秀です。

INDEX RANGE SCAN (MIN/MAX) によって最大値（直近データ）を無駄なくアクセスしてはいるのですが、Id=4 で再び detail 表をアクセスせざるを得ないのが弱点。
一方、LATERAL JOIN の方は同じく、索引を有効活用し、ソートをバイパスする INDEX RANGE SCAN DESCENDING の効果と Top 1 となる COUNT STOPKEY によって無駄なく直近データを取得しています。
ひとつ付け加えておくと、MAX()関数 + 自己結合 + スカラー副問合せ方式で書いても、Oracle Databaseのオプティマイザは内部的に LATERAL JOIN へ書き換えているのも見えますよね。 VW_LAT_CDDD7452 というビュー名称から判断できますよ。

2) MAX()関数 + 自己結合 + スカラー副問合せ方式

Plan hash value: 1568514629

-------------------------------------------------------------------------------------------------------------
| Id  | Operation                       | Name            | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                |                 |      1 |        |      1 |00:00:00.01 |       5 |
|   1 |  NESTED LOOPS OUTER             |                 |      1 |      1 |      1 |00:00:00.01 |       5 |
|*  2 |   INDEX UNIQUE SCAN             | PK_MASTER       |      1 |      1 |      1 |00:00:00.01 |       1 |
|   3 |   VIEW                          | VW_LAT_CDDD7452 |      1 |      1 |      1 |00:00:00.01 |       4 |
|*  4 |    INDEX UNIQUE SCAN            | PK_DETAIL       |      1 |      1 |      1 |00:00:00.01 |       4 |
|   5 |     SORT AGGREGATE              |                 |      1 |      1 |      1 |00:00:00.01 |       2 |
|   6 |      FIRST ROW                  |                 |      1 |      1 |      1 |00:00:00.01 |       2 |
|*  7 |       INDEX RANGE SCAN (MIN/MAX)| PK_DETAIL       |      1 |      1 |      1 |00:00:00.01 |       2 |
-------------------------------------------------------------------------------------------------------------

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

   2 - access("T1"."ID"=300)
   4 - access("T1"."ID"="T2"."ID" AND "T2"."VNUM"=)
   7 - access("T3"."ID"=:B1)

4）LATERAL JOIN + Top 1 Query方式

Plan hash value: 43833377

--------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name            | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |                 |      1 |        |      1 |00:00:00.01 |       3 |
|   1 |  NESTED LOOPS OUTER              |                 |      1 |      1 |      1 |00:00:00.01 |       3 |
|*  2 |   INDEX UNIQUE SCAN              | PK_MASTER       |      1 |      1 |      1 |00:00:00.01 |       1 |
|   3 |   VIEW                           | VW_LAT_6FD14B30 |      1 |      1 |      1 |00:00:00.01 |       2 |
|   4 |    VIEW                          | VW_LAT_A18161FF |      1 |      1 |      1 |00:00:00.01 |       2 |
|*  5 |     COUNT STOPKEY                |                 |      1 |        |      1 |00:00:00.01 |       2 |
|   6 |      VIEW                        |                 |      1 |      2 |      1 |00:00:00.01 |       2 |
|*  7 |       INDEX RANGE SCAN DESCENDING| PK_DETAIL       |      1 |   1085 |      1 |00:00:00.01 |       2 |
--------------------------------------------------------------------------------------------------------------

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

   2 - access("T1"."ID"=300)
   5 - filter(ROWNUM<=1)
   7 - access("T2L"."ID"="T1"."ID")

PostgreSQL 17.7
PostgreSQLの場合もOracle Database同様に履歴データが100,000行あっても影響はなく、rows=1となっています。結果として、4）LATERAL JOIN + Top 1 Query方式がより軽く、
メモリ消費サイズも少ないことがわかります。！！！！！！
Oracle Database同様ですが、LATERAL JOINでソートをバイパスして最大値（直近データ）を取得している操作はIndex Only Scan Backwardとして現れています。:)
なお、PostgreSQLの場合、実行計画から LATERAL JOIN が行われていることは読み取れません。また、実行計画からは、Oracle Database のように索引をMIN/MAXでアクセスするという直接的なキーワードはありませんが、Index Scan Backward using pk_detail で索引を逆からアクセスすることでMAX()を取得していることを判断できます。このあたりもRDBMS毎の癖のひとつですね。

2) MAX()関数 + 自己結合 + スカラー副問合せ方式

                                                                              QUERY PLAN 
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=1.67..17.72 rows=1 width=12) (actual time=0.033..0.035 rows=1 loops=1)
   Output: t1.id, t2.id, t2.vnum
   Inner Unique: true
   ->  Index Scan using master_pkey on scott.master t1  (cost=0.13..8.15 rows=1 width=4) (actual time=0.012..0.012 rows=1 loops=1)
         Output: t1.id
         Index Cond: (t1.id = 300)
   ->  Index Scan using ix2_detail on scott.detail t2  (cost=1.54..9.56 rows=1 width=8) (actual time=0.005..0.005 rows=1 loops=1)
         Output: t2.id, t2.vnum, t2.col1
         Index Cond: (t2.vnum = (SubPlan 2))
         Filter: (t2.id = 300)
         SubPlan 2
           ->  Result  (cost=1.24..1.25 rows=1 width=4) (actual time=0.013..0.013 rows=1 loops=1)
                 Output: (InitPlan 1).col1
                 InitPlan 1
                   ->  Limit  (cost=0.29..1.24 rows=1 width=4) (actual time=0.011..0.012 rows=1 loops=1)
                         Output: t3.vnum
                         ->  Index Scan Backward using pk_detail on scott.detail t3  (cost=0.29..1038.04 rows=1096 width=4) (actual time=0.011..0.011 rows=1 loops=1)
                               Output: t3.vnum
                               Index Cond: (t3.id = t1.id)
 Planning:
   Memory: used=78kB  allocated=128kB
 Planning Time: 0.177 ms
 Execution Time: 0.051 ms
(23 rows)

4）LATERAL JOIN + Top 1 Query方式

                                                                       QUERY PLAN                                                                        
----------------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=0.42..8.48 rows=1 width=12) (actual time=0.024..0.025 rows=1 loops=1)
   Output: t1.id, t2l.id, t2l.vnum
   Buffers: shared hit=5
   ->  Index Scan using master_pkey on scott.master t1  (cost=0.13..8.15 rows=1 width=4) (actual time=0.012..0.012 rows=1 loops=1)
         Output: t1.id
         Index Cond: (t1.id = 300)
         Buffers: shared hit=2
   ->  Limit  (cost=0.29..0.32 rows=1 width=8) (actual time=0.011..0.011 rows=1 loops=1)
         Output: t2l.id, t2l.vnum
         Buffers: shared hit=3
         ->  Index Only Scan Backward using pk_detail on scott.detail t2l  (cost=0.29..35.47 rows=1096 width=8) (actual time=0.010..0.010 rows=1 loops=1)
               Output: t2l.id, t2l.vnum
               Index Cond: (t2l.id = t1.id)
               Heap Fetches: 0
               Buffers: shared hit=3
 Planning:
   Memory: used=39kB  allocated=64kB
 Planning Time: 0.113 ms
 Execution Time: 0.037 ms
(19 rows)

MySQL 8.4.7
冒頭でもコメントしたMySQLですが、クラスターインデックスの強みでしょうか？　2) MAX()関数 + 自己結合 + スカラー副問合せ方式 の実行計画が最強すぎる！
4）LATERAL JOIN + Top 1 Query方式も無駄の無い素晴らしい実行計画なので、す、が。。。。w
MySQLに限っては、2) MAX()関数 + 自己結合 + スカラー副問合せ方式の方が良いですよね！
また、LATERAL側も実行計画は悪くないですが、Materialize操作は避けられないようです。
Rows fetched before executionには完敗のLATERAL JOINの実行計画では、他のRDBMS同様に、Covering index lookup on t2l using PRIMARY (id='300') (reverse)に同様のソートをバイパスする索引アクセスが現れています。

2) MAX()関数 + 自己結合 + スカラー副問合せ方式

+-------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                         |
+-------------------------------------------------------------------------------------------------+
| -> Rows fetched before execution  (cost=0..0 rows=1) (actual time=45e-6..90e-6 rows=1 loops=1)
 |
+-------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.00 sec)

mysql> show warnings;
+-------+------+------------------------------------------------------------------------------+
| Level | Code | Message                                                                      |
+-------+------+------------------------------------------------------------------------------+
| Note  | 1276 | Field or reference 'perftestdb.t1.id' of SELECT #2 was resolved in SELECT #1 |
+-------+------+------------------------------------------------------------------------------+
1 row in set (0.00 sec)

4）LATERAL JOIN + Top 1 Query方式

+--------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                    |
+--------------------------------------------------------------------------------------------------------------------------------------------+
| -> Nested loop left join  (cost=2.73 rows=2) (actual time=0.105..0.106 rows=1 loops=1)
    -> Rows fetched before execution  (cost=0..0 rows=1) (actual time=90e-6..135e-6 rows=1 loops=1)
    -> Table scan on t2  (cost=2.73..2.73 rows=1) (actual time=0.102..0.102 rows=1 loops=1)
        -> Materialize  (cost=105..105 rows=2) (actual time=0.101..0.101 rows=1 loops=1)
            -> Limit: 1 row(s)  (cost=105 rows=1) (actual time=0.0914..0.0914 rows=1 loops=1)
                -> Covering index lookup on t2l using PRIMARY (id='300') (reverse)  (cost=105 rows=1042) (actual time=0.0906..0.0906 rows=1 loops=1)
 |
+--------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.02 sec)

mysql> show warnings;
+-------+------+------------------------------------------------------------------------------+
| Level | Code | Message                                                                      |
+-------+------+------------------------------------------------------------------------------+
| Note  | 1276 | Field or reference 'perftestdb.t1.id' of SELECT #2 was resolved in SELECT #1 |
+-------+------+------------------------------------------------------------------------------+
1 row in set (0.00 sec)

以下は、検証ログです。長いのでコーヒーとかお酒でも飲みながら見ていただければ :)　ながーーーーーーーーーーーいのでw

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

オールドファッションな方式の中でも性能リスクの高い書き方
（OLTP想定なので結合方法はNLJとなるようにオプティマイザヒントで調整しています。見ての通りなにも指定しないと相関副問合せをUnestとしてHash Joinしてしまうので。それはそれで性能影響ではあるのですけども。NLJに倒したとしても影響がでるよというところから見ておきましょう）

Oracle Database / 不等価相関条件を利用した相関副問合せ方式
オールドファッションな方式の中でも性能リスクも高い書き方です。検証するまでもないのですがあえて加えておきました。
相関条件　t2_latest.vnum < t2_all.vnum　が曲者ですね。
自己結合した結果で自行より大きなvnumを持つデータがないことを条件にしています。不等価結合なので見た目でリスクを感じとれたら、掴みはオーケーですw
ほかにも無駄な点があります。
detail表を二度アクセスしてしまうことになるリスクですね。
自己結合は排除できるなら排除したいところですが、この構文を選択した時点で逃げ道はありません。
オプティマイザはかなり進化していて内部で最適化のために種々の書き換えを行えるようになってきてはいますが、こいつについては、そのまま実行計画に現れます。

なお、Oracle Databaseは、相関副問合せをUnnestして結合しちゃたりする最適化が発動してしまいOLTP向きのNested Loop Anti Joinになってくれない（データ量がおおいので）ため、オプティマイザヒント、/*+ UNNEST NL_AJ */を付加してNested Loops Anti Joinを強制しています。

SELECT 
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN (
    SELECT
      t2_latest.id
      , t2_latest.vnum
    FROM
      detail t2_latest
    WHERE 
      NOT EXISTS (
        SELECT /*+ UNNEST NL_AJ */
          1
        FROM
          detail t2_all
        WHERE
          t2_latest.id = t2_all.id
          AND t2_latest.vnum < t2_all.vnum
      )
  ) t2
  ON 
    t1.id = t2.id
WHERE                
  t1.id = 3
;

SCOTT@localhost:1521/freepdb1> /

      T1ID       T2ID       VNUM
---------- ---------- ----------
         3          3        100

経過: 00:00:00.00

比較用に /*+ UNNEST NL_AJ */ がない場合の実行計画です。NOT EXISTS なので ANTI JOIN ではありますが、Hash Join となっています。OLTP では避けたいですよね
この例では運良く Index Only Scan で表へのアクセスはないですが、表へのアクセスが回避できないような索引しかなかったら影響はもっと大きくなるのは言うまでもありません。
PK_DETAIL 索引が HASH JONI RIGHT ANTI で結合され、2度アクセスされている箇所がポイントです。

この方法の最大の弱点は、履歴データの多さの影響を受けてしまうというところですよね。 A-ROWS を見るとはっきり見えますよね。

Plan hash value: 1385316136

----------------------------------------------------------------------------------------------------------------------
| Id  | Operation           | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
----------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |           |      1 |        |      1 |00:00:00.01 |       5 |       |       |          |
|   1 |  NESTED LOOPS OUTER |           |      1 |    100 |      1 |00:00:00.01 |       5 |       |       |          |
|*  2 |   INDEX UNIQUE SCAN | PK_MASTER |      1 |      1 |      1 |00:00:00.01 |       1 |       |       |          |
|   3 |   VIEW              |           |      1 |    100 |      1 |00:00:00.01 |       4 |       |       |          |
|*  4 |    HASH JOIN ANTI   |           |      1 |    100 |      1 |00:00:00.01 |       4 |  2078K|  2078K|  718K (0)|
|*  5 |     INDEX RANGE SCAN| PK_DETAIL |      1 |    100 |    100 |00:00:00.01 |       2 |       |       |          |
|*  6 |     INDEX RANGE SCAN| PK_DETAIL |      1 |    100 |    100 |00:00:00.01 |       2 |       |       |          |
----------------------------------------------------------------------------------------------------------------------

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

   2 - access("T1"."ID"=3)
   4 - access("T2_LATEST"."ID"="T2_ALL"."ID")
       filter("T2_LATEST"."VNUM"<"T2_ALL"."VNUM")
   5 - access("T2_LATEST"."ID"=3)
   6 - access("T2_ALL"."ID"=3)

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

/*+ UNNEST NL_AJ */ヒントを利用して、相関副問合せを Unnest, Hash Join する最適化を抑止しました。結果は、Nested Loops Anti Join となり、OLTP には良いですね。
Hash Join のメモリー関連オーバーヘッドもないですし。
とはいえ、PK_DETAI L索引を2回アクセスするオーバーヘッド（少しですけどw）は気になります。Index Only Scan とはいえ。この方法では避けようがないのですけども。
この方法の最大の弱点である履歴データの量に影響を受けてしまうという点は HASH JOIN でも NLJ でも同じ。
A-ROWS は重要なので見忘れることのないようにね！この例では履歴が100行ありますが、読んじゃってますよね。全て。

Plan hash value: 101384627

-------------------------------------------------------------------------------------------
| Id  | Operation           | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |           |      1 |        |      1 |00:00:00.01 |      12 |
|   1 |  NESTED LOOPS OUTER |           |      1 |    100 |      1 |00:00:00.01 |      12 |
|*  2 |   INDEX UNIQUE SCAN | PK_MASTER |      1 |      1 |      1 |00:00:00.01 |       1 |
|   3 |   VIEW              |           |      1 |    100 |      1 |00:00:00.01 |      11 |
|   4 |    NESTED LOOPS ANTI|           |      1 |    100 |      1 |00:00:00.01 |      11 |
|*  5 |     INDEX RANGE SCAN| PK_DETAIL |      1 |    100 |    100 |00:00:00.01 |       3 |
|*  6 |     INDEX RANGE SCAN| PK_DETAIL |    100 |      1 |     99 |00:00:00.01 |       8 |
-------------------------------------------------------------------------------------------

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

   2 - access("T1"."ID"=3)
   5 - access("T2_LATEST"."ID"=3)
   6 - access("T2_ALL"."ID"=3 AND "T2_LATEST"."VNUM"<"T2_ALL"."VNUM")

Oracle Database / MAX()関数を利用したスカラー副問合せ方式
この方法も昔からある古いタイプの方法です。
detail 表を2度アクセスする点は同じですが、不等価結合を排除し広範囲のデータアクセスを行わないのがポイント。（適切な索引が必須です）
適切な索引によって MAX() 関数が INDEX RANGE SCAN (MIN/MAX) でソートなしで索引から直近データへアクセスします。
id,vnum からなる主キー索引から vnum の最大値を持つ索引のリーフノードをアクセスするだけ。ソート処理もバイパスされます。

SELECT 
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN detail t2 
  ON               
    t1.id = t2.id 
    AND t2.vnum = (
    SELECT 
      MAX(t3.vnum)
    FROM
      detail t3
    WHERE
      t3.id = t1.id
  )
WHERE
  t1.id = 3
;

SCOTT@localhost:1521/freepdb1> /

      T1ID       T2ID       VNUM
---------- ---------- ----------
         3          3        100
経過: 00:00:00.01

実行計画上のポイントは、Id=6,7 の部分ですね。運良く Index only scan となる主キー索引があり、かつ INDEX RANGE SCAN (MIN/MAX) となっています。ただし、この方式の弱点でる PK_DETAIL 索引の二度読みは回避できません。
鋭い方は気づいたと思いますが、相関副問い合わせではあるのですが、内部的には、LATERAL JOIN へ変換されています。ここ今回のネタの後半でも出てくるので覚えておいてください。
この場合、不等価結合を行なっていた場合とは大きく異なり、全てがヒントなしでも、Nested Loops Join になります。その挙動がLATERAL JOIN が OLTP と相性がよい理由です。逆に大量データは苦手なわけですが。

Plan hash value: 1568514629

-------------------------------------------------------------------------------------------------------------
| Id  | Operation                       | Name            | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                |                 |      1 |        |      1 |00:00:00.01 |       5 |
|   1 |  NESTED LOOPS OUTER             |                 |      1 |      1 |      1 |00:00:00.01 |       5 |
|*  2 |   INDEX UNIQUE SCAN             | PK_MASTER       |      1 |      1 |      1 |00:00:00.01 |       1 |
|   3 |   VIEW                          | VW_LAT_CDDD7452 |      1 |      1 |      1 |00:00:00.01 |       4 |
|*  4 |    INDEX UNIQUE SCAN            | PK_DETAIL       |      1 |      1 |      1 |00:00:00.01 |       4 |
|   5 |     SORT AGGREGATE              |                 |      1 |      1 |      1 |00:00:00.01 |       2 |
|   6 |      FIRST ROW                  |                 |      1 |      1 |      1 |00:00:00.01 |       2 |
|*  7 |       INDEX RANGE SCAN (MIN/MAX)| PK_DETAIL       |      1 |      1 |      1 |00:00:00.01 |       2 |
-------------------------------------------------------------------------------------------------------------

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

   2 - access("T1"."ID"=3)
   4 - access("T1"."ID"="T2"."ID" AND "T2"."VNUM"=)
   7 - access("T3"."ID"=:B1)

Oracle Database / ROW_NUMBER()ウィンドウ関数方式
さて、三番手。最近はよく見かける ROW_NUMBER() ウィンドウ関数を利用する方法で、述語プッシュダウンによる最適化も期待した方法ですね。
ウインドウ関数を適用するためにインラインビュー化した detail 表のアクセスは1回のみ。
前述の2つの方法にくらべ detail 表へのアクセスが削減され、意図が読み取りやすいというメリットもあります。

ちなみに、
このウィンドウ関数ですは、Oracle Database 8i (1999年)ごろからサポートされているのでまったく新しいという感覚は全くないのですが、他のRDBMSをみると、
- PostgreSQL 8.4 (2009年)
- MySQL 8.0 (2018)

MySQLだけは、比較的最近サポートされました。（とはいえ8年ほど前ですが）

ソートが必要になるのでその影響などを索引アクセスで削減するのもポイントになります。とはいえ、バッチ等大量データ処理前提の場面では強力なオプションではありますね。

一点、ROW_NUMBER()ウィンドウ関数には、OLTP向きとは言えない癖とうか弱点あります。><
以下実行計画の A-ROWS で気づくと思いますが、履歴データの量が性能に影響します。
逆にいえば、履歴データの量が十分少ないままなのであれば、そこそこの性能を維持できるとも言えます。　履歴データが100行あるテストケースで、100行全て読み込んでランキングづけしてから1行をフィルタリングして取り出すという挙動になっているのに気づくはずです。索引の効果でソートはバイパスしていますが、ランキングするさいに追加のメモリ消費オーバーヘッドもあります。

SELECT 
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN  (
    SELECT
      id
      , vnum
      , ROW_NUMBER() OVER (
          PARTITION BY 
            detail.id 
          ORDER BY 
            detail.id DESC
            , detail.vnum DESC
      ) AS latest
    FROM
     detail
  ) t2
  ON 
    t1.id = t2.id
    AND t2.latest = 1
WHERE
    t1.id = 3
;

SCOTT@localhost:1521/freepdb1> /

      T1ID       T2ID       VNUM
---------- ---------- ----------
         3          3        100

経過: 00:00:00.01

Plan hash value: 4287976176

---------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
---------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |           |      1 |        |      1 |00:00:00.01 |       3 |       |       |          |
|   1 |  NESTED LOOPS OUTER            |           |      1 |    100 |      1 |00:00:00.01 |       3 |       |       |          |
|*  2 |   INDEX UNIQUE SCAN            | PK_MASTER |      1 |      1 |      1 |00:00:00.01 |       1 |       |       |          |
|*  3 |   VIEW                         |           |      1 |    100 |      1 |00:00:00.01 |       2 |       |       |          |
|*  4 |    WINDOW BUFFER PUSHED RANK   |           |      1 |    100 |      1 |00:00:00.01 |       2 |  6144 |  6144 | 6144  (0)|
|*  5 |     INDEX RANGE SCAN DESCENDING| PK_DETAIL |      1 |    100 |    100 |00:00:00.01 |       2 |       |       |          |
---------------------------------------------------------------------------------------------------------------------------------

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

   2 - access("T1"."ID"=3)
   3 - filter("T2"."LATEST"=1)
   4 - filter(ROW_NUMBER() OVER ( PARTITION BY "DETAIL"."ID" ORDER BY "DETAIL"."VNUM" DESC )<=1)
   5 - access("ID"=3)

Oracle Database / LATERAL JOIN + Top 1 Query方式
さて、最後は、LATERAL JOIN を利用する方法です。
左相関にすることで確実にNLJになります。ヒントはなくてもNLJですからね。OLTPには嬉しいです。適切な索引は必須ですけども。

感覚的な使い所としては、少量のデータだけが帰る前提で、SELECT リスト内でスカラー副問合せを利用することが有利な場面に近いイメージでしょうか。
意図ぜず大量データの結合で内部的に書き換えられて発動して性能でねーーーーーーとうこともあるのでその辺りは利用シーンを考えて使うのがよいと思います。
今回のネタのように OLTP で結合が、NLJ になるのがベストですよね。

なお、LATERAL JOIN を記述した場合や内部的に LATERAL JOIN に書き換えられている場合、VW_LAT_* というVIEW名称が付与されます。
このVIEW名称をみたら LATERAL JOIN だ！　と思えば間違いないです！

ちなみに、
Oracle Database で LATERAL JOIN がサポートされたのが 2013年(12c)
PostgreSQL も 2013年（PostgreSQL 9.3）
MySQLは、2019年(MySQL 8.0.14) なので、

モダンといっても Oracle/PostgreSQL では 13 年以上前ですw。
部分的なサポートを含めるともっと古いわけですが。

直近データを結合する OLTP で LATERAL JOIN を見かけた記憶がほぼないのは、私が関わってる現場が偏ってるとか言う話だけでも無いような気もしますw (大量データ処理でパラレル化が必要だとか言う場合にはウィンドウ関数のほうが向いているわけですけども)

SELECT 
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN LATERAL (
      SELECT
        t2l.id
        , t2l.vnum
      FROM
       detail t2l
      WHERE
        t2l.id = t1.id
      ORDER BY
        t2l.id DESC
        , t2l.vnum DESC
      FETCH FIRST 1 ROWS ONLY
  ) t2
  ON TRUE
WHERE
  t1.id = 3
;


      T1ID       T2ID       VNUM
---------- ---------- ----------
         3          3        100

経過: 00:00:00.00


Plan hash value: 43833377

--------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name            | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |                 |      1 |        |      1 |00:00:00.01 |       3 |
|   1 |  NESTED LOOPS OUTER              |                 |      1 |      1 |      1 |00:00:00.01 |       3 |
|*  2 |   INDEX UNIQUE SCAN              | PK_MASTER       |      1 |      1 |      1 |00:00:00.01 |       1 |
|   3 |   VIEW                           | VW_LAT_6FD14B30 |      1 |      1 |      1 |00:00:00.01 |       2 |
|   4 |    VIEW                          | VW_LAT_A18161FF |      1 |      1 |      1 |00:00:00.01 |       2 |
|*  5 |     COUNT STOPKEY                |                 |      1 |        |      1 |00:00:00.01 |       2 |
|   6 |      VIEW                        |                 |      1 |      2 |      1 |00:00:00.01 |       2 |
|*  7 |       INDEX RANGE SCAN DESCENDING| PK_DETAIL       |      1 |   1085 |      1 |00:00:00.01 |       2 |
--------------------------------------------------------------------------------------------------------------

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

   2 - access("T1"."ID"=3)
   5 - filter(ROWNUM<=1)
   7 - access("T2L"."ID"="T1"."ID")

ということで、次は同じことをPostgreSQLで試してみましょう。

perftestdb=> select version();
                                                    version                                                    
---------------------------------------------------------------------------------------------------------------
 PostgreSQL 17.7 on aarch64-unknown-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-28), 64-bit
(1 row)

データ量が少なめなので pg_hint_plan で索引を利用するよう強制しています。

PostgreSQL / 不等価相関条件を利用した相関副問合せ方式
実行計画を見ると Oracle Database の場合と同様、他の方式にくらべ明らかにまずいところがありますが、気付きましたか？

rows=100 となっており detail 表から id に該当する履歴データ全てを読み込んでいます！　
その後、マテリアライズされてる部分のデータ量によっては重くなる可能性があります。

なんてこった！　

と言う感じですよね。この方法は避けるべきだというのがよくわかる部分だと思います。

SELECT /*+ IndexScan(t1) IndexScan(t2_latest) IndexScan(t2_all) */
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN (
    SELECT
      t2_latest.id
      , t2_latest.vnum
    FROM
      detail t2_latest
    WHERE 
      NOT EXISTS (
        SELECT
          1
        FROM
          detail t2_all
        WHERE
          t2_latest.id = t2_all.id
          AND t2_latest.vnum < t2_all.vnum
      )
  ) t2
  ON 
    t1.id = t2.id
WHERE                
  t1.id = 3
;

 t1id | t2id | vnum 
------+------+------
    3 |    3 |  100
(1 row)


                                                                      QUERY PLAN                                                                       
-------------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=0.72..518.48 rows=75 width=12) (actual time=0.477..0.478 rows=1 loops=1)
   Output: t1.id, t2_latest.id, t2_latest.vnum
   ->  Index Scan using master_pkey on scott.master t1  (cost=0.13..8.15 rows=1 width=4) (actual time=0.012..0.012 rows=1 loops=1)
         Output: t1.id
         Index Cond: (t1.id = 3)
   ->  Nested Loop Anti Join  (cost=0.58..509.58 rows=75 width=8) (actual time=0.464..0.464 rows=1 loops=1)
         Output: t2_latest.id, t2_latest.vnum
         Join Filter: (t2_latest.vnum < t2_all.vnum)
         Rows Removed by Join Filter: 5050
         ->  Index Scan using pk_detail on scott.detail t2_latest  (cost=0.29..190.52 rows=113 width=8) (actual time=0.007..0.015 rows=100 loops=1)
               Output: t2_latest.id, t2_latest.vnum, t2_latest.col1
               Index Cond: (t2_latest.id = 3)
         ->  Materialize  (cost=0.29..191.09 rows=113 width=8) (actual time=0.000..0.002 rows=51 loops=100)
               Output: t2_all.id, t2_all.vnum
               ->  Index Scan using pk_detail on scott.detail t2_all  (cost=0.29..190.52 rows=113 width=8) (actual time=0.004..0.015 rows=100 loops=1)
                     Output: t2_all.id, t2_all.vnum
                     Index Cond: (t2_all.id = 3)
 Planning:
   Memory: used=63kB  allocated=128kB
 Planning Time: 0.144 ms
 Execution Time: 0.493 ms
(21 rows)

PostgreSQL / MAX()関数を利用したスカラー副問合せ方式
detail を 2 度読みしている点は不統合を利用した場合と同じですが、読み込んでいるデータ量には圧倒的な差があります。
rows=1 loops=1　となり 1/100 の量です。

これは履歴データ数に応じて変化するため履歴データが多ければ多いほど顕著な差となって現れます。
個人て的には可読性としてはイマイチだと思っていますが、性能的には非常に安定している思います。
なお、適切な索引の作成漏れに注意が必要なのは言うまでもありません。Index Scan Backward using pk_detail on scott.detail でソート不要で索引を逆読みし、Lminit 1で直近データ（最大値）を取得しています。この部分が無駄なデータへアクセスしないための肝です。

SELECT /*+ IndexScan(t1) IndexScan(t2) IndexScan(t3) */
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN detail t2 
  ON               
    t1.id = t2.id 
    AND t2.vnum = (
    SELECT 
      MAX(t3.vnum)
    FROM
      detail t3
    WHERE
      t3.id = t1.id 
  )
WHERE  
  t1.id = 
3
;

 t1id | t2id | vnum 
------+------+------
    3 |    3 |  100
(1 row)


                                                                              QUERY PLAN                                                                              
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=1.67..17.72 rows=1 width=12) (actual time=0.058..0.059 rows=1 loops=1)
   Output: t1.id, t2.id, t2.vnum
   Inner Unique: true
   ->  Index Scan using master_pkey on scott.master t1  (cost=0.13..8.15 rows=1 width=4) (actual time=0.012..0.013 rows=1 loops=1)
         Output: t1.id
         Index Cond: (t1.id = 3)
   ->  Index Scan using ix2_detail on scott.detail t2  (cost=1.54..9.56 rows=1 width=8) (actual time=0.013..0.013 rows=1 loops=1)
         Output: t2.id, t2.vnum, t2.col1
         Index Cond: (t2.vnum = (SubPlan 2))
         Filter: (t2.id = 3)
         SubPlan 2
           ->  Result  (cost=1.24..1.25 rows=1 width=4) (actual time=0.010..0.011 rows=1 loops=1)
                 Output: (InitPlan 1).col1
                 InitPlan 1
                   ->  Limit  (cost=0.29..1.24 rows=1 width=4) (actual time=0.009..0.009 rows=1 loops=1)
                         Output: t3.vnum
                         ->  Index Scan Backward using pk_detail on scott.detail t3  (cost=0.29..1038.04 rows=1096 width=4) (actual time=0.008..0.008 rows=1 loops=1)
                               Output: t3.vnum
                               Index Cond: (t3.id = t1.id)
 Planning:
   Memory: used=78kB  allocated=128kB
 Planning Time: 0.166 ms
 Execution Time: 0.077 ms
(23 rows)

PostgreSQL / ROW_NUMBER()ウィンドウ関数方式
PostgreSQLのROW_NUMBER()とランキングづけした 1行目の取得、つまり最大値（直近データ）取得のロジックは、Oracle Databaesのウィンドウ関数の挙動はと異なることに気づきます！！！！
癖（良い意味でw）強い！！

索引を降順に読み込みソートはバイパスしているわけですから、索引エントリー 2 行目でスキャンを打ち切ったことが読み取れます！！！！！　まじか！
Oracle Databaseの挙動とは違うプランナーの挙動です。
rows=2 loops=1 と 2行読んで、これ以上索引を降順に読むのは無意味！として止めて結果を返しています。すげえ。この最適化によりPostgreSQL / MAX()関数を利用したスカラー副問合せ方式より良い結果が得られています。PostgreSQLでは、この方法を利用してもケガはしなそうです。ベストではないにしても。
また、detail 表を 1 度しかアクセスしないので、その分のコスト削減と可読性含めて古い方式より良いですよね。

SELECT /*+ IndexScan(t1) IndexScan(detail) */
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN  (
    SELECT
      id
      , vnum
      , ROW_NUMBER() OVER (
          PARTITION BY 
            detail.id 
          ORDER BY 
            detail.id DESC
            , detail.vnum DESC
      ) AS latest
    FROM
     detail
  ) t2
  ON 
    t1.id = t2.id
    AND t2.latest = 1
WHERE
    t1.id = 3
;

 t1id | t2id | vnum 
------+------+------
    3 |    3 |  100
(1 row)

                                                                      QUERY PLAN                                                                       
-------------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=2.13..202.07 rows=1 width=12) (actual time=0.031..0.033 rows=1 loops=1)
   Output: t1.id, t2.id, t2.vnum
   Buffers: shared hit=5
   ->  Index Scan using master_pkey on scott.master t1  (cost=0.13..8.15 rows=1 width=4) (actual time=0.015..0.016 rows=1 loops=1)
         Output: t1.id
         Index Cond: (t1.id = 3)
         Buffers: shared hit=2
   ->  Subquery Scan on t2  (cost=1.99..193.91 rows=1 width=8) (actual time=0.014..0.015 rows=1 loops=1)
         Output: t2.id, t2.vnum, t2.latest
         Filter: (t2.latest = 1)
         Buffers: shared hit=3
         ->  WindowAgg  (cost=1.99..192.50 rows=113 width=16) (actual time=0.013..0.014 rows=1 loops=1)
               Output: detail.id, detail.vnum, row_number() OVER (?)
               Run Condition: (row_number() OVER (?) <= 1)
               Buffers: shared hit=3
               ->  Index Scan Backward using pk_detail on scott.detail  (cost=0.29..190.52 rows=113 width=8) (actual time=0.009..0.009 rows=2 loops=1)
                     Output: detail.id, detail.vnum
                     Index Cond: (detail.id = 3)
                     Buffers: shared hit=3
 Planning:
   Memory: used=48kB  allocated=64kB
 Planning Time: 0.144 ms
 Execution Time: 0.055 ms
(23 rows)

PostgreSQL / LATERAL JOIN + Top 1 Query方式
rows=1 loops=1 で MAX()関数を利用した方法と同じですが、ここでも detail 表を 1度しかアクセスしないという効果もあり OLTP としては最高にシンプルな NLJ の実行計画になっています。
メモリサイズも小さいですよね。
OLTP には嬉しいことばかりだと思います。
また、可読性も非常に高いと思います。ぱっと見でも、なにをやりたいのか意図を容易に把握できます。
この構文は LATERAL がサポートされたことによるものなので使えるシーンでは積極的につかったほうが良いと思います。

ただし、Oracle Database のように実行計画から LATERAL JOIN であることを判断するのはむずしそうですね。いずれ拡張されるかもしれないですが。。

SELECT /*+ IndexScan(t1) IndexScan(detail) */
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN LATERAL (
       SELECT
        t2l.id
        , t2l.vnum
      FROM
        detail t2l
      WHERE
        t2l.id = t1.id
      ORDER BY
        t2l.id DESC 
        , t2l.vnum DESC
      LIMIT 1
  ) t2
  ON TRUE<br>WHERE
  t1.id = 3
;

 t1id | t2id | vnum 
------+------+------
    3 |    3 |  100
(1 row)

                                                                        QUERY PLAN                                                                        
----------------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=0.42..8.48 rows=1 width=12) (actual time=0.036..0.037 rows=1 loops=1)
   Output: t1.id, t2l.id, t2l.vnum
   Buffers: shared hit=5
   ->  Index Scan using master_pkey on scott.master t1  (cost=0.13..8.15 rows=1 width=4) (actual time=0.013..0.014 rows=1 loops=1)
         Output: t1.id
         Index Cond: (t1.id = 3)
         Buffers: shared hit=2
   ->  Limit  (cost=0.29..0.32 rows=1 width=8) (actual time=0.020..0.021 rows=1 loops=1)
         Output: t2l.id, t2l.vnum
         Buffers: shared hit=3
         ->  Index Only Scan Backward using pk_detail on scott.detail t2l  (cost=0.29..35.47 rows=1096 width=8) (actual time=0.020..0.020 rows=1 loops=1)
               Output: t2l.id, t2l.vnum
               Index Cond: (t2l.id = t1.id)
               Heap Fetches: 0
               Buffers: shared hit=3
 Planning:
   Memory: used=39kB  allocated=64kB
 Planning Time: 0.116 ms
 Execution Time: 0.049 ms
(19 rows)

最後にMySQLです。
比較しているrdbms中、LATERALやウィンドウ関数のサポートは比較的最近で、それまでは昔からある方法でしか対応できなかったMySQLなのですが、8.0以降一気にサポート範囲が広がりましたね。


mysql> select version();
+-----------+
| version() |
+-----------+
| 8.4.7     |
+-----------+
1 row in set (0.00 sec)

MySQL / 不等価相関条件を利用した相関副問合せ方式
rows=100 loops=1 で PostgreSQL や Oracle Database と同じ傾向が見られます。この方法は避けたほうがよいです。 大切なので太字にしておきましたw
master表こそ、Rows fetched before executionというMySQLでは最速の操作にはなっていますが、detail表のアクセスは2回で履歴データを全て読み込んでいます。

SELECT 
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN (
    SELECT
      t2_latest.id
      , t2_latest.vnum
    FROM
      detail t2_latest
    WHERE 
      NOT EXISTS (
        SELECT
          1
        FROM
          detail t2_all
        WHERE
          t2_latest.id = t2_all.id
          AND t2_latest.vnum < t2_all.vnum
      )
  ) t2
  ON 
    t1.id = t2.id
WHERE                
  t1.id = 3
;

+------+------+------+
| t1id | t2id | vnum |
+------+------+------+
|    3 |    3 |  100 |
+------+------+------+
1 row in set (0.00 sec)

+-------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                   |
+-------------------------------------------------------------------------------------------------------------------------------------------+
| -> Nested loop left join  (cost=1001 rows=10000) (actual time=1.19..1.19 rows=1 loops=1)
    -> Rows fetched before execution  (cost=0..0 rows=1) (actual time=46e-6..91e-6 rows=1 loops=1)
    -> Nested loop antijoin  (cost=1130 rows=10000) (actual time=1.19..1.19 rows=1 loops=1)
        -> Covering index lookup on t2_latest using PRIMARY (id=3)  (cost=11.2 rows=100) (actual time=0.0103..0.0182 rows=100 loops=1)
        -> Filter: (t2_latest.vnum < t2_all.vnum)  (cost=129 rows=100) (actual time=0.0116..0.0116 rows=0.99 loops=100)
            -> Covering index lookup on t2_all using PRIMARY (id=3)  (cost=129 rows=100) (actual time=0.00687..0.00981 rows=51.5 loops=100)
 |
+-------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set, 2 warnings (0.00 sec)

mysql> show warnings;
+-------+------+---------------------------------------------------------------------------------------+
| Level | Code | Message                                                                               |
+-------+------+---------------------------------------------------------------------------------------+
| Note  | 1276 | Field or reference 'perftestdb.t2_latest.id' of SELECT #3 was resolved in SELECT #2   |
| Note  | 1276 | Field or reference 'perftestdb.t2_latest.vnum' of SELECT #3 was resolved in SELECT #2 |
+-------+------+---------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

MySQL / MAX()関数を利用したスカラー副問合せ方式
特にコメントすることもないのですが、これ、MySQL独特の挙動で、めちゃ早いやつですね！　
（さすが) この挙動は履歴データが増加しても影響なしです。

SELECT 
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN detail t2 
  ON               
    t1.id = t2.id 
    AND t2.vnum = (
    SELECT 
      MAX(t3.vnum)
    FROM
      detail t3
    WHERE
      t3.id = t1.id 
  )
WHERE                    
  t1.id = 3
;

+------+------+------+
| t1id | t2id | vnum |
+------+------+------+
|    3 |    3 |  100 |
+------+------+------+
1 row in set (0.01 sec)

+-----------------------------------------------------------------------------------------+
| EXPLAIN                                                                                 |
+-----------------------------------------------------------------------------------------+
| -> Rows fetched before execution  (cost=0..0 rows=1) (actual time=0..0 rows=1 loops=1)
 |
+-----------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.00 sec)

mysql> show warnings;
+-------+------+------------------------------------------------------------------------------+
| Level | Code | Message                                                                      |
+-------+------+------------------------------------------------------------------------------+
| Note  | 1276 | Field or reference 'perftestdb.t1.id' of SELECT #2 was resolved in SELECT #1 |
+-------+------+------------------------------------------------------------------------------+
1 row in set (0.00 sec)

MySQL / ROW_NUMBER()ウィンドウ関数方式
おっと！
MySQLのROW_NUMBER()ウィンドウ関数によるランキングづけとTop 1をフィルタリングには特徴的な挙動がありますね。癖なのか不具合なのか、微妙ですが。

rows=109610 loops=1 とあることから、結合条件となる id列を述語プッシュダウン最適化でビュー内部に押し込めてないため、Index only scanではありますが索引全走査し、全行取得しまっているようです。興味深い。

Covering index scan on detail using PRIMARY　というアクセスはよいのですがid = 3で絞ってくれない（述語プッシュダウン頼りの構文なので、プッシュダウンできないとこうなっちゃいます。この方法オプティマイザの機能依存なので。。。）

たとえば、PostgreSQL　の実行計画から同じ操作をみると以下のように id=3 がプッシュダウンされ索引アクセスのがわかります。

->  Index Scan Backward using pk_detail on scott.detail  (cost=0.29..190.52 rows=113 width=8) (actual time=0.009..0.009 rows=2 loops=1)
      Output: detail.vnum, detail.id
      Index Cond: (detail.id = 3)

Oracle Databaseの実行計画では以下の部分から判断できますが、MySQLの場合はありません。

|*  5 |     INDEX RANGE SCAN DESCENDING| PK_DETAIL |  1085 |  8680 |     4   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------

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

...略...
   5 - access("ID"=3)

しかも、索引アクセスは revese にはなっていません！！！！その影響で、ソートが行われ、マテリアライズさらた後に 1rowに絞られています。まじか！

SELECT 
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN  (
    SELECT
      id
      , vnum
      , ROW_NUMBER() OVER (
          PARTITION BY 
            detail.id 
          ORDER BY 
            detail.id DESC
            , detail.vnum DESC
      ) AS latest
    FROM
     detail
  ) t2
  ON 
    t1.id = t2.id
    AND t2.latest = 1
WHERE
    t1.id = 3
;

+------+------+------+
| t1id | t2id | vnum |
+------+------+------+
|    3 |    3 |  100 |
+------+------+------+
1 row in set (0.11 sec)

+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                                               |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| -> Nested loop left join  (cost=10946 rows=109439) (actual time=126..126 rows=1 loops=1)
    -> Rows fetched before execution  (cost=0..0 rows=1) (actual time=45e-6..180e-6 rows=1 loops=1)
    -> Index lookup on t2 using  (id=3, latest=1)  (cost=10944..10947 rows=10) (actual time=126..126 rows=1 loops=1)
        -> Materialize  (cost=10944..10944 rows=109439) (actual time=126..126 rows=109610 loops=1)
            -> Window aggregate: row_number() OVER (PARTITION BY detail.id ORDER BY detail.id desc,detail.vnum desc )   (cost=0 rows=109439) (actual time=28.2..43.4 rows=109610 loops=1)
                -> Sort: detail.id, detail.id DESC, detail.vnum DESC  (cost=11000 rows=109439) (actual time=28.2..32.2 rows=109610 loops=1)
                    -> Covering index scan on detail using PRIMARY  (cost=11000 rows=109439) (actual time=0.621..11.3 rows=109610 loops=1)
|
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.12 sec)

MySQL / LATERAL JOIN + Top 1 Query方式
どうなるでしょう。ドキドキ

Materializeがでてますね。MySQLのオプティマイザの特徴なのでしかたなし、という部分です。とはいえ、1rowだけなので影響は軽微ではあるように見えます。

Covering index lookup on t2l using PRIMARY (id='3') (reverse) としっかり　id=3で降順に索引をアクセスし、ソート処理をバイパスしています。:)
その後、Top 1 を返したところで終了。Master表に関しては、Rows fetched before execution　という最強の操作になっています。.
ただし、MySQL / MAX()関数を利用したスカラー副問合せ方式には勝てませんでしたw 苦笑いw

SELECT 
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN LATERAL (
       SELECT
        t2l.id
        , t2l.vnum
      FROM
       detail t2l
      WHERE
        t2l.id = t1.id
      ORDER BY
        t2l.id DESC
        , t2l.vnum DESC
      LIMIT 1
  ) t2
  ON TRUE
WHERE
  t1.id = 3
;

+------+------+------+
| t1id | t2id | vnum |
+------+------+------+
|    3 |    3 |  100 |
+------+------+------+
1 row in set (0.00 sec)

+--------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                    |
+--------------------------------------------------------------------------------------------------------------------------------------------+
| -> Nested loop left join  (cost=2.73 rows=2) (actual time=0.0259..0.0263 rows=1 loops=1)
    -> Rows fetched before execution  (cost=0..0 rows=1) (actual time=45e-6..90e-6 rows=1 loops=1)
    -> Table scan on t2  (cost=2.73..2.73 rows=1) (actual time=0.0246..0.0248 rows=1 loops=1)
        -> Materialize  (cost=105..105 rows=2) (actual time=0.0236..0.0236 rows=1 loops=1)
            -> Limit: 1 row(s)  (cost=105 rows=1) (actual time=0.0181..0.0181 rows=1 loops=1)
                -> Covering index lookup on t2l using PRIMARY (id='3') (reverse)  (cost=105 rows=1042) (actual time=0.0178..0.0178 rows=1 loops=1)
 |
+--------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.00 sec)

mysql> show warnings;
+-------+------+------------------------------------------------------------------------------+
| Level | Code | Message                                                                      |
+-------+------+------------------------------------------------------------------------------+
| Note  | 1276 | Field or reference 'perftestdb.t1.id' of SELECT #2 was resolved in SELECT #1 |
+-------+------+------------------------------------------------------------------------------+
1 row in set (0.00 sec)

detail表に該当データがない場合。
これはほぼMaster表のデータ取得だけになるので、皆さんの予想通り、処理時間の差はほぼ現れないだろうと思います。

では見てみましょう。

Oracle Database / 不等価結合を利用した相関副問合せ方式
これで遅かったら何かの間違いですからね。
実行計画は同じ(Plan Hash Valueに変化はありません)ですが Adaptive PlanというNoteがでました。とはいえ、（ヒントでも抑止てますし）detail側は空振りするのでHASH JOINになることは100%ありません。

SELECT 
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN (
    SELECT 
      t2_latest.id
      , t2_latest.vnum
    FROM
      detail t2_latest
    WHERE 
      NOT EXISTS (
        SELECT /*+ UNNEST NL_AJ*/
          1
        FROM
          detail t2_all
        WHERE
          t2_latest.id = t2_all.id
          AND t2_latest.vnum < t2_all.vnum
      )
  ) t2
  ON 
    t1.id = t2.id
WHERE                    
  t1.id = 200
;


      T1ID       T2ID       VNUM
---------- ---------- ----------
       200

経過: 00:00:00.00

Plan hash value: 101384627

-------------------------------------------------------------------------------------------
| Id  | Operation           | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |           |      1 |        |      1 |00:00:00.01 |       3 |
|   1 |  NESTED LOOPS OUTER |           |      1 |      1 |      1 |00:00:00.01 |       3 |
|*  2 |   INDEX UNIQUE SCAN | PK_MASTER |      1 |      1 |      1 |00:00:00.01 |       1 |
|   3 |   VIEW              |           |      1 |      1 |      0 |00:00:00.01 |       2 |
|   4 |    NESTED LOOPS ANTI|           |      1 |      1 |      0 |00:00:00.01 |       2 |
|*  5 |     INDEX RANGE SCAN| PK_DETAIL |      1 |      1 |      0 |00:00:00.01 |       2 |
|*  6 |     INDEX RANGE SCAN| PK_DETAIL |      0 |      1 |      0 |00:00:00.01 |       0 |
-------------------------------------------------------------------------------------------

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

   2 - access("T1"."ID"=200)
   5 - access("T2_LATEST"."ID"=200)
   6 - access("T2_ALL"."ID"=200 AND "T2_LATEST"."VNUM"<"T2_ALL"."VNUM")

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

PostgreSQL / 不等価結合を利用した相関副問合せ方式
Materialize以下にある操作がnever executedとなり、重かった部分が実行されないので早いですね。

SELECT /*+ IndexScan(t1) IndexScan(t2_latest) IndexScan(t2_all) */
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN (
    SELECT
      t2_latest.id
      , t2_latest.vnum
    FROM
      detail t2_latest
    WHERE 
      NOT EXISTS (
        SELECT
          1
        FROM
          detail t2_all
        WHERE
          t2_latest.id = t2_all.id
          AND t2_latest.vnum < t2_all.vnum
      )
  ) t2
  ON 
    t1.id = t2.id
WHERE                
  t1.id = 200
;

 t1id | t2id | vnum 
------+------+------
  200 |      |     
(1 row)

                                                                  QUERY PLAN                                                                   
-----------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=0.72..35.62 rows=3 width=12) (actual time=0.022..0.023 rows=1 loops=1)
   Output: t1.id, t2_latest.id, t2_latest.vnum
   ->  Index Scan using master_pkey on scott.master t1  (cost=0.13..8.15 rows=1 width=4) (actual time=0.014..0.014 rows=1 loops=1)
         Output: t1.id
         Index Cond: (t1.id = 200)
   ->  Nested Loop Anti Join  (cost=0.58..27.44 rows=3 width=8) (actual time=0.006..0.006 rows=0 loops=1)
         Output: t2_latest.id, t2_latest.vnum
         Join Filter: (t2_latest.vnum < t2_all.vnum)
         ->  Index Scan using pk_detail on scott.detail t2_latest  (cost=0.29..13.61 rows=4 width=8) (actual time=0.006..0.006 rows=0 loops=1)
               Output: t2_latest.id, t2_latest.vnum, t2_latest.col1
               Index Cond: (t2_latest.id = 200)
         ->  Materialize  (cost=0.29..13.63 rows=4 width=8) (never executed)
               Output: t2_all.id, t2_all.vnum
               ->  Index Scan using pk_detail on scott.detail t2_all  (cost=0.29..13.61 rows=4 width=8) (never executed)
                     Output: t2_all.id, t2_all.vnum
                     Index Cond: (t2_all.id = 200)
 Planning:
   Memory: used=63kB  allocated=128kB
 Planning Time: 0.147 ms
 Execution Time: 0.044 ms
(20 rows)

MySQL / 不等価結合を利用した相関副問合せ方式
PostgreSQL同様、never executedがあるので重めの箇所は実行されず、実行計画は同じでも処理速度は大きく変化することになります。
なので、detail表が空振りしているケースが多い場合はこの方法の問題点には気付き難い。
特にテストデータのミスで空振りが多かったり、実行計画を見ずに処理時間ばかり気にしていると見逃してしまう可能性もなくないですよね。

テストデータの質、大丈夫ですか？、実行計画見てますか？（大切なので、太字にしておきました）

SELECT 
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN (
    SELECT
      t2_latest.id
      , t2_latest.vnum
    FROM
      detail t2_latest
    WHERE 
      NOT EXISTS (
        SELECT
          1
        FROM
          detail t2_all
        WHERE
          t2_latest.id = t2_all.id
          AND t2_latest.vnum < t2_all.vnum
      )
  ) t2
  ON 
    t1.id = t2.id
WHERE                    
  t1.id = 200
;

+------+------+------+
| t1id | t2id | vnum |
+------+------+------+
|  200 | NULL | NULL |
+------+------+------+
1 row in set (0.00 sec)

+------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                            |
+------------------------------------------------------------------------------------------------------------------------------------+
| -> Nested loop left join  (cost=0.35 rows=1) (actual time=0.00456..0.00465 rows=1 loops=1)
    -> Rows fetched before execution  (cost=0..0 rows=1) (actual time=90e-6..135e-6 rows=1 loops=1)
    -> Nested loop antijoin  (cost=0.7 rows=1) (actual time=0.00307..0.00307 rows=0 loops=1)
        -> Covering index lookup on t2_latest using PRIMARY (id=200)  (cost=0.35 rows=1) (actual time=0.00293..0.00293 rows=0 loops=1)
        -> Filter: (t2_latest.vnum < t2_all.vnum)  (cost=0.35 rows=1) (never executed)
            -> Covering index lookup on t2_all using PRIMARY (id=200)  (cost=0.35 rows=1) (never executed)
 |
+------------------------------------------------------------------------------------------------------------------------------------+
1 row in set, 2 warnings (0.00 sec)

mysql> show warnings;
+-------+------+---------------------------------------------------------------------------------------+
| Level | Code | Message                                                                               |
+-------+------+---------------------------------------------------------------------------------------+
| Note  | 1276 | Field or reference 'perftestdb.t2_latest.id' of SELECT #3 was resolved in SELECT #2   |
| Note  | 1276 | Field or reference 'perftestdb.t2_latest.vnum' of SELECT #3 was resolved in SELECT #2 |
+-------+------+---------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

Oracle Database / MAX()関数を利用したスカラー副問合せ方式
気になるところはないですよね。昔ながらの方法もそれなりに早いです。
detail表を二度アクセスする以外は。（このケースだと2度目のアクセスは発生しないわけですけども）

SELECT 
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN detail t2 
  ON               
    t1.id = t2.id 
    AND t2.vnum = (
    SELECT 
      MAX(t3.vnum)
    FROM
      detail t3
    WHERE
      t3.id = t1.id 
  )
WHERE                    
  t1.id = 200
;

SCOTT@localhost:1521/freepdb1> /

      T1ID       T2ID       VNUM
---------- ---------- ----------
       200

経過: 00:00:00.00


Plan hash value: 1568514629

-------------------------------------------------------------------------------------------------------------
| Id  | Operation                       | Name            | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                |                 |      1 |        |      1 |00:00:00.01 |       3 |
|   1 |  NESTED LOOPS OUTER             |                 |      1 |      1 |      1 |00:00:00.01 |       3 |
|*  2 |   INDEX UNIQUE SCAN             | PK_MASTER       |      1 |      1 |      1 |00:00:00.01 |       1 |
|   3 |   VIEW                          | VW_LAT_CDDD7452 |      1 |      1 |      0 |00:00:00.01 |       2 |
|*  4 |    INDEX UNIQUE SCAN            | PK_DETAIL       |      1 |      1 |      0 |00:00:00.01 |       2 |
|   5 |     SORT AGGREGATE              |                 |      1 |      1 |      1 |00:00:00.01 |       2 |
|   6 |      FIRST ROW                  |                 |      1 |      1 |      0 |00:00:00.01 |       2 |
|*  7 |       INDEX RANGE SCAN (MIN/MAX)| PK_DETAIL       |      1 |      1 |      0 |00:00:00.01 |       2 |
-------------------------------------------------------------------------------------------------------------

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

   2 - access("T1"."ID"=200)
   4 - access("T1"."ID"="T2"."ID" AND "T2"."VNUM"=)
   7 - access("T3"."ID"=:B1)

PostgreSQL / MAX()関数を利用したスカラー副問合せ方式
こちらはnever executed にはならないのでdetail表を2回アクセスする部分のは生き残っていますね。

SELECT /*+ IndexScan(t1) IndexScan(t2) IndexScan(t3) */
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN detail t2 
  ON               
    t1.id = t2.id 
    AND t2.vnum = (
    SELECT 
      MAX(t3.vnum)
    FROM
      detail t3
    WHERE
      t3.id = t1.id 
  )
WHERE                    
  t1.id = 200
;

 t1id | t2id | vnum 
------+------+------
  200 |      |     
(1 row)


                                                                              QUERY PLAN                                                                              
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=1.67..17.72 rows=1 width=12) (actual time=0.031..0.033 rows=1 loops=1)
   Output: t1.id, t2.id, t2.vnum
   Inner Unique: true
   ->  Index Scan using master_pkey on scott.master t1  (cost=0.13..8.15 rows=1 width=4) (actual time=0.016..0.017 rows=1 loops=1)
         Output: t1.id
         Index Cond: (t1.id = 200)
   ->  Index Scan using ix2_detail on scott.detail t2  (cost=1.54..9.56 rows=1 width=8) (actual time=0.000..0.001 rows=0 loops=1)
         Output: t2.id, t2.vnum, t2.col1
         Index Cond: (t2.vnum = (SubPlan 2))
         Filter: (t2.id = 200)
         SubPlan 2
           ->  Result  (cost=1.24..1.25 rows=1 width=4) (actual time=0.009..0.009 rows=1 loops=1)
                 Output: (InitPlan 1).col1
                 InitPlan 1
                   ->  Limit  (cost=0.29..1.24 rows=1 width=4) (actual time=0.007..0.008 rows=0 loops=1)
                         Output: t3.vnum
                         ->  Index Scan Backward using pk_detail on scott.detail t3  (cost=0.29..1038.04 rows=1096 width=4) (actual time=0.007..0.007 rows=0 loops=1)
                               Output: t3.vnum
                               Index Cond: (t3.id = t1.id)
 Planning:
   Memory: used=78kB  allocated=128kB
 Planning Time: 0.177 ms
 Execution Time: 0.054 ms
(23 rows)

MySQL / MAX()関数を利用したスカラー副問合せ方式
こちらもPostgreSQL同様に変化なし。これ以上速くはならないわけでw

SELECT 
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN detail t2 
  ON               
    t1.id = t2.id 
    AND t2.vnum = (
    SELECT 
      MAX(t3.vnum)
    FROM
      detail t3
    WHERE
      t3.id = t1.id 
  )
WHERE                    
  t1.id = 200
;

+------+------+------+
| t1id | t2id | vnum |
+------+------+------+
|  200 | NULL | NULL |
+------+------+------+
1 row in set (0.00 sec)

+-------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                         |
+-------------------------------------------------------------------------------------------------+
| -> Rows fetched before execution  (cost=0..0 rows=1) (actual time=45e-6..45e-6 rows=1 loops=1)
 |
+-------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.00 sec)

mysql> show warnings;
+-------+------+------------------------------------------------------------------------------+
| Level | Code | Message                                                                      |
+-------+------+------------------------------------------------------------------------------+
| Note  | 1276 | Field or reference 'perftestdb.t1.id' of SELECT #2 was resolved in SELECT #1 |
+-------+------+------------------------------------------------------------------------------+
1 row in set (0.00 sec)

Oracle Database / ROW_NUMBER()ウィンドウ関数方式
（述語プッシュダウン最適化依存）
想定外の挙動はなさそうですね。

SELECT 
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN  (
    SELECT
      id
      , vnum
      , ROW_NUMBER() OVER (
          PARTITION BY 
            detail.id 
          ORDER BY
            detail.id DESC 
            , detail.vnum DESC
      ) AS latest
    FROM
     detail
  ) t2
  ON 
    t1.id = t2.id
    AND t2.latest = 1
WHERE
    t1.id = 200
;

SCOTT@localhost:1521/freepdb1> /

      T1ID       T2ID       VNUM
---------- ---------- ----------
       200
       
経過: 00:00:00.00


Plan hash value: 4287976176

------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |           |      1 |        |      1 |00:00:00.01 |       3 |
|   1 |  NESTED LOOPS OUTER            |           |      1 |      1 |      1 |00:00:00.01 |       3 |
|*  2 |   INDEX UNIQUE SCAN            | PK_MASTER |      1 |      1 |      1 |00:00:00.01 |       1 |
|*  3 |   VIEW                         |           |      1 |      1 |      0 |00:00:00.01 |       2 |
|*  4 |    WINDOW BUFFER PUSHED RANK   |           |      1 |      1 |      0 |00:00:00.01 |       2 |
|*  5 |     INDEX RANGE SCAN DESCENDING| PK_DETAIL |      1 |      1 |      0 |00:00:00.01 |       2 |
------------------------------------------------------------------------------------------------------

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

   2 - access("T1"."ID"=200)
   3 - filter("T2"."LATEST"=1)
   4 - filter(ROW_NUMBER() OVER ( PARTITION BY "DETAIL"."ID" ORDER BY "DETAIL"."VNUM" DESC
              )<=1)
   5 - access("ID"=200)

PostgreSQL / ROW_NUMBER()ウィンドウ関数方式
（述語プッシュダウン最適化依存）
こちらも変化はないようです。想定通り。

SELECT /*+ IndexScan(t1) IndexScan(detail) */
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN  (
    SELECT
      id
      , vnum
      , ROW_NUMBER() OVER (
          PARTITION BY 
            detail.id 
          ORDER BY
            detail.id DESC 
            , detail.vnum DESC
      ) AS latest
    FROM
     detail
  ) t2
  ON 
    t1.id = t2.id
    AND t2.latest = 1
WHERE
    t1.id = 200
;

 t1id | t2id | vnum 
------+------+------
  200 |      |     
(1 row)

                                                                     QUERY PLAN                                                                     
----------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=3.77..21.89 rows=1 width=12) (actual time=0.022..0.023 rows=1 loops=1)
   Output: t1.id, t2.id, t2.vnum
   Buffers: shared hit=4
   ->  Index Scan using master_pkey on scott.master t1  (cost=0.13..8.15 rows=1 width=4) (actual time=0.012..0.013 rows=1 loops=1)
         Output: t1.id
         Index Cond: (t1.id = 200)
         Buffers: shared hit=2
   ->  Subquery Scan on t2  (cost=3.64..13.73 rows=1 width=8) (actual time=0.007..0.007 rows=0 loops=1)
         Output: t2.id, t2.vnum, t2.latest
         Filter: (t2.latest = 1)
         Buffers: shared hit=2
         ->  WindowAgg  (cost=3.64..13.68 rows=4 width=16) (actual time=0.006..0.007 rows=0 loops=1)
               Output: detail.id, detail.vnum, row_number() OVER (?)
               Run Condition: (row_number() OVER (?) <= 1)
               Buffers: shared hit=2
               ->  Index Scan Backward using pk_detail on scott.detail  (cost=0.29..13.61 rows=4 width=8) (actual time=0.006..0.006 rows=0 loops=1)
                     Output: detail.id, detail.vnum
                     Index Cond: (detail.id = 200)
                     Buffers: shared hit=2
 Planning:
   Memory: used=48kB  allocated=64kB
 Planning Time: 0.136 ms
 Execution Time: 0.045 ms
(23 rows)

MySQL / ROW_NUMBER()ウィンドウ関数方式
（述語プッシュダウン最適化依存）
こちらも想定通り、遅いまま。プッシュダウンできないので、Materialize 全行されちゃいますよね。rows=109610 loops=1　ということ遅いまま。不具合っぽい気がするけども。

SELECT 
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN  (
    SELECT
      id
      , vnum
      , ROW_NUMBER() OVER (
          PARTITION BY 
            detail.id 
          ORDER BY
            detail.id DESC 
            , detail.vnum DESC
      ) AS latest
    FROM
     detail
  ) t2
  ON 
    t1.id = t2.id
    AND t2.latest = 1
WHERE
    t1.id = 200
;

+------+------+------+
| t1id | t2id | vnum |
+------+------+------+
|  200 | NULL | NULL |
+------+------+------+
1 row in set (0.11 sec)

+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                                                 |
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| -> Nested loop left join  (cost=10946 rows=109439) (actual time=126..126 rows=1 loops=1)
    -> Rows fetched before execution  (cost=0..0 rows=1) (actual time=45e-6..91e-6 rows=1 loops=1)
    -> Index lookup on t2 using  (id=200, latest=1)  (cost=10944..10947 rows=10) (actual time=126..126 rows=0 loops=1)
        -> Materialize  (cost=10944..10944 rows=109439) (actual time=126..126 rows=109610 loops=1)
            -> Window aggregate: row_number() OVER (PARTITION BY detail.id ORDER BY detail.id desc,detail.vnum desc )   (cost=0 rows=109439) (actual time=27.5..42.8 rows=109610 loops=1)
                -> Sort: detail.id, detail.id DESC, detail.vnum DESC  (cost=11000 rows=109439) (actual time=27.5..31.4 rows=109610 loops=1)
                    -> Covering index scan on detail using PRIMARY  (cost=11000 rows=109439) (actual time=0.632..11.4 rows=109610 loops=1)
|
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.13 sec)

Oracle Database / LATERAL JOIN + Top 1 Query方式
想定通り。

SELECT 
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN LATERAL (
       select
        t2l.id
        , t2l.vnum
      FROM
       detail t2l
      WHERE
        t2l.id = t1.id
      ORDER BY
        t2l.id DESC
        , t2l.vnum DESC
      FETCH FIRST 1 ROWS ONLY
  ) t2
  ON TRUE
WHERE
  t1.id = 200
;

SCOTT@localhost:1521/freepdb1> /

      T1ID       T2ID       VNUM
---------- ---------- ----------
       200

経過: 00:00:00.00

Plan hash value: 43833377

--------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name            | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |                 |      1 |        |      1 |00:00:00.01 |       3 |
|   1 |  NESTED LOOPS OUTER              |                 |      1 |      1 |      1 |00:00:00.01 |       3 |
|*  2 |   INDEX UNIQUE SCAN              | PK_MASTER       |      1 |      1 |      1 |00:00:00.01 |       1 |
|   3 |   VIEW                           | VW_LAT_6FD14B30 |      1 |      1 |      0 |00:00:00.01 |       2 |
|   4 |    VIEW                          | VW_LAT_A18161FF |      1 |      1 |      0 |00:00:00.01 |       2 |
|*  5 |     COUNT STOPKEY                |                 |      1 |        |      0 |00:00:00.01 |       2 |
|   6 |      VIEW                        |                 |      1 |      2 |      0 |00:00:00.01 |       2 |
|*  7 |       INDEX RANGE SCAN DESCENDING| PK_DETAIL       |      1 |   1085 |      0 |00:00:00.01 |       2 |
--------------------------------------------------------------------------------------------------------------

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

   2 - access("T1"."ID"=200)
   5 - filter(ROWNUM<=1) 
   7 - access("T2L"."ID"="T1"."ID")

PostgreSQL / LATERAL JOIN + Top 1 Query方式
想定通りの結果、変化は見られません。

SELECT /*+ IndexScan(t1) IndexScan(detail) */
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN LATERAL (
       SELECT
        t2l.id
        , t2l.vnum
      FROM
       detail t2l
      WHERE
        t2l.id = t1.id
      ORDER BY
        t2l.id DESC
        , t2l.vnum DESC
      LIMIT 1
  ) t2
  ON TRUE
WHERE
  t1.id = 200
;

perftestdb-> ;
 t1id | t2id | vnum 
------+------+------
  200 |      |     
(1 row)

                                                                        QUERY PLAN                                                                        
----------------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=0.42..8.48 rows=1 width=12) (actual time=0.027..0.028 rows=1 loops=1)
   Output: t1.id, t2l.id, t2l.vnum
   Buffers: shared hit=4
   ->  Index Scan using master_pkey on scott.master t1  (cost=0.13..8.15 rows=1 width=4) (actual time=0.019..0.019 rows=1 loops=1)
         Output: t1.id
         Index Cond: (t1.id = 200)
         Buffers: shared hit=2
   ->  Limit  (cost=0.29..0.32 rows=1 width=8) (actual time=0.007..0.007 rows=0 loops=1)
         Output: t2l.id, t2l.vnum
         Buffers: shared hit=2
         ->  Index Only Scan Backward using pk_detail on scott.detail t2l  (cost=0.29..35.47 rows=1096 width=8) (actual time=0.006..0.006 rows=0 loops=1)
               Output: t2l.id, t2l.vnum
               Index Cond: (t2l.id = t1.id)
               Heap Fetches: 0
               Buffers: shared hit=2
 Planning:
   Memory: used=39kB  allocated=64kB
 Planning Time: 0.118 ms
 Execution Time: 0.042 ms
(19 rows)

MySQL / LATERAL JOIN + Top 1 Query方式
Materialize のステップもありますね　
rows=0 loops=1 。PRIMARY (id='200')で一度アクセスして空振りという状況ですね。実行計画に変化はありません。想定通り。
MySQLもPostgreSQL同様に、実行計画には LATERAL JOIN であることを読み取れる情報はありません。(Oracle Databaseの実行計画はではHash Join のHASH表を作成するステップや実行時の動的に発動するタイプの挙動などいくつかの操作が読み取れないのですが、他のRDBMSの実行計画よりは読み取れる内容が多くでなにが起こっているか追いやすい気はします。他のRDBMSもそのうち拡張されたりするかもしれませんが。PostgreSQLのexplain のオプションも増えてきてますし)

SELECT 
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN LATERAL (
      SELECT
        t2l.id
        , t2l.vnum
      FROM
       detail t2l
      WHERE
        t2l.id = t1.id
      ORDER BY
        t2l.id DESC
        , t2l.vnum DESC
      LIMIT 1
  ) t2
  ON TRUE
WHERE
  t1.id = 200
;

+------+------+------+
| t1id | t2id | vnum |
+------+------+------+
|  200 | NULL | NULL |
+------+------+------+
1 row in set (0.00 sec)

-------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                  |
-------------------------------------------------------------------------------------------------------------------------------------------+
| -> Nested loop left join  (cost=2.73 rows=2) (actual time=0.0114..0.0115 rows=1 loops=1)
    -> Rows fetched before execution  (cost=0..0 rows=1) (actual time=45e-6..91e-6 rows=1 loops=1)
    -> Table scan on t2  (cost=2.73..2.73 rows=1) (actual time=0.0101..0.0101 rows=0 loops=1)
        -> Materialize  (cost=105..105 rows=2) (actual time=0.00907..0.00907 rows=0 loops=1)
            -> Limit: 1 row(s)  (cost=105 rows=1) (actual time=0.00496..0.00496 rows=0 loops=1)
                -> Covering index lookup on t2l using PRIMARY (id='200') (reverse)  (cost=105 rows=1042) (actual time=0.00478..0.00478 rows=0 loops=1)
 |
-------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.01 sec)

mysql> show warnings;
+-------+------+------------------------------------------------------------------------------+
| Level | Code | Message                                                                      |
+-------+------+------------------------------------------------------------------------------+
| Note  | 1276 | Field or reference 'perftestdb.t1.id' of SELECT #2 was resolved in SELECT #1 |
+-------+------+------------------------------------------------------------------------------+
1 row in set (0.00 sec)

では最後に、履歴を100,000行もつデータにアクセスしたらどうなるでしょう..。

Oracle Database / 不等価相関条件を利用した相関副問合せ方式
おおおおおお、ついに大きな差が！！！　　
事前の予想通り、履歴データ量に影響されますね。不等価条件の影響は大きい。　7 - access("T2_ALL"."ID"=300 AND "T2_LATEST"."VNUM"<"T2_ALL"."VNUM")　だと辛いっす。

SELECT 
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN (
    SELECT
      t2_latest.id
      , t2_latest.vnum
    FROM
       detail t2_latest
    WHERE 
       NOT EXISTS (
        SELECT /*+ UNNEST NL_AJ */
          1
        FROM
           detail t2_all
        WHERE
           t2_latest.id = t2_all.id
           AND t2_latest.vnum < t2_all.vnum
      )
  ) t2
  ON 
    t1.id = t2.id
WHERE                    
  t1.id = 300
;

SCOTT@localhost:1521/freepdb1> /

      T1ID       T2ID       VNUM
---------- ---------- ----------
       300        300     100000

経過: 00:00:00.04


Plan hash value: 3008471785

-----------------------------------------------------------------------------------------------
| Id  | Operation               | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT        |           |      1 |        |      1 |00:00:00.04 |    2027 |
|   1 |  NESTED LOOPS OUTER     |           |      1 |    100K|      1 |00:00:00.04 |    2027 |
|*  2 |   INDEX UNIQUE SCAN     | PK_MASTER |      1 |      1 |      1 |00:00:00.01 |       1 |
|   3 |   VIEW PUSHED PREDICATE |           |      1 |   1085 |      1 |00:00:00.04 |    2026 |
|*  4 |    FILTER               |           |      1 |        |      1 |00:00:00.04 |    2026 |
|   5 |     NESTED LOOPS ANTI   |           |      1 |   1085 |      1 |00:00:00.04 |    2026 |
|*  6 |      INDEX RANGE SCAN   | PK_DETAIL |      1 |   1085 |    100K|00:00:00.01 |     226 |
|*  7 |      INDEX RANGE SCAN   | PK_DETAIL |    100K|      1 |  99999 |00:00:00.03 |    1800 |
-----------------------------------------------------------------------------------------------

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

   2 - access("T1"."ID"=300)
   4 - filter("T1"."ID"=300)
   6 - access("T2_LATEST"."ID"="T1"."ID")
   7 - access("T2_ALL"."ID"=300 AND "T2_LATEST"."VNUM"<"T2_ALL"."VNUM")
       filter("T2_ALL"."ID"="T1"."ID")

PostgreSQL / 不等価相関条件を利用した相関副問合せ方式
PostgreSQLでも同様の結果になっていますね。

SELECT /*+ IndexScan(t1) IndexScan(t2_latest) IndexScan(t2_all)  */
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN (
    SELECTv      t2_latest.id
      , t2_latest.vnum
    FROM
      detail t2_latest
    WHERE 
      NOT EXISTS (
        select
          1
        FROM
          detail t2_all
        WHERE
          t2_latest.id = t2_all.id
          AND t2_latest.vnum < t2_all.vnum
      )
  ) t2
  ON 
    t1.id = t2.id
WHERE                    
  t1.id = 300
;

 t1id | t2id |  vnum  
------+------+--------
  300 |  300 | 100000
(1 row)

                                                                        QUERY PLAN                                                                         
-----------------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=0.72..66943788.27 rows=66787 width=12) (actual time=314.284..314.286 rows=1 loops=1)
   Output: t1.id, t2_latest.id, t2_latest.vnum
   ->  Index Scan using master_pkey on scott.master t1  (cost=0.13..8.15 rows=1 width=4) (actual time=0.012..0.012 rows=1 loops=1)
         Output: t1.id
         Index Cond: (t1.id = 300)
   ->  Nested Loop Anti Join  (cost=0.58..66943112.25 rows=66787 width=8) (actual time=314.270..314.271 rows=1 loops=1)
         Output: t2_latest.id, t2_latest.vnum
         ->  Index Scan using pk_detail on scott.detail t2_latest  (cost=0.29..4206.32 rows=100180 width=8) (actual time=0.007..7.433 rows=100000 loops=1)
               Output: t2_latest.id, t2_latest.vnum, t2_latest.col1
               Index Cond: (t2_latest.id = 300)
         ->  Index Scan using pk_detail on scott.detail t2_all  (cost=0.29..668.19 rows=33393 width=8) (actual time=0.003..0.003 rows=1 loops=100000)
               Output: t2_all.id, t2_all.vnum, t2_all.col1
               Index Cond: ((t2_all.id = 300) AND (t2_all.vnum > t2_latest.vnum))
 Planning:
   Memory: used=64kB  allocated=128kB
 Planning Time: 0.166 ms
 Execution Time: 314.309 ms
(17 rows)

MySQL / 不等価相関条件を利用した相関副問合せ方式
影響があるのは想像してましたが、影響でか！！！　びっくり！　

SELECT 
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
from  
  master t1 
  LEFT OUTER JOIN (
    SELECT
      t2_latest.id
      , t2_latest.vnum
    FROM
      detail t2_latest
    WHERE 
      NOT EXISTS (
        SELECT
          1
        FROM
          detail t2_all
        WHERE
          t2_latest.id = t2_all.id
          AND t2_latest.vnum < t2_all.vnum
      )
  ) t2
  ON 
    t1.id = t2.id
WHERE                    
  t1.id = 300
;

+------+------+--------+
| t1id | t2id | vnum   |
+------+------+--------+
|  300 |  300 | 100000 |
+------+------+--------+
1 row in set (8 min 7.42 sec)

+----------------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                            |
+----------------------------------------------------------------------------------------------------------------------------------------------------+
| -> Nested loop left join  (cost=299e+6 rows=2.99e+9) (actual time=733106..733106 rows=1 loops=1)
    -> Rows fetched before execution  (cost=0..0 rows=1) (actual time=42e-6..84e-6 rows=1 loops=1)
    -> Nested loop antijoin  (cost=301e+6 rows=2.99e+9) (actual time=733106..733106 rows=1 loops=1)
        -> Covering index lookup on t2_latest using PRIMARY (id=300)  (cost=5499 rows=54719) (actual time=0.441..44.4 rows=100000 loops=1)
        -> Filter: (t2_latest.vnum < t2_all.vnum)  (cost=1.48e+6 rows=54719) (actual time=7.33..7.33 rows=1 loops=100000)
            -> Covering index lookup on t2_all using PRIMARY (id=300)  (cost=1.48e+6 rows=54719) (actual time=0.315..5.68 rows=50001 loops=100000)
 |
+----------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set, 2 warnings (12 min 13.11 sec)

mysql> show warnings;
+-------+------+---------------------------------------------------------------------------------------+
| Level | Code | Message                                                                               |
+-------+------+---------------------------------------------------------------------------------------+
| Note  | 1276 | Field or reference 'perftestdb.t2_latest.id' of SELECT #3 was resolved in SELECT #2   |
| Note  | 1276 | Field or reference 'perftestdb.t2_latest.vnum' of SELECT #3 was resolved in SELECT #2 |
+-------+------+---------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

Oracle Database / MAX()関数を利用したスカラー副問合せ方式
古いやり方だけど安定してはいますね。detail表2回アクセスすることと可読性はちょっと弱いかな。という部分を除けば。

SELECT 
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN detail t2 
  on               
    t1.id = t2.id 
    AND t2.vnum = (
    SELECT 
      MAX(t3.vnum)
    FROM
      detail t3
    WHERE
      t3.id = t1.id 
  )
WHERE                    
  t1.id = 300
;

SCOTT@localhost:1521/freepdb1> /

      T1ID       T2ID       VNUM
---------- ---------- ----------
       300        300     100000

経過: 00:00:00.00


Plan hash value: 1568514629

-------------------------------------------------------------------------------------------------------------
| Id  | Operation                       | Name            | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                |                 |      1 |        |      1 |00:00:00.01 |       5 |
|   1 |  NESTED LOOPS OUTER             |                 |      1 |      1 |      1 |00:00:00.01 |       5 |
|*  2 |   INDEX UNIQUE SCAN             | PK_MASTER       |      1 |      1 |      1 |00:00:00.01 |       1 |
|   3 |   VIEW                          | VW_LAT_CDDD7452 |      1 |      1 |      1 |00:00:00.01 |       4 |
|*  4 |    INDEX UNIQUE SCAN            | PK_DETAIL       |      1 |      1 |      1 |00:00:00.01 |       4 |
|   5 |     SORT AGGREGATE              |                 |      1 |      1 |      1 |00:00:00.01 |       2 |
|   6 |      FIRST ROW                  |                 |      1 |      1 |      1 |00:00:00.01 |       2 |
|*  7 |       INDEX RANGE SCAN (MIN/MAX)| PK_DETAIL       |      1 |      1 |      1 |00:00:00.01 |       2 |
-------------------------------------------------------------------------------------------------------------

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

   2 - access("T1"."ID"=300)
   4 - access("T1"."ID"="T2"."ID" AND "T2"."VNUM"=)
   7 - access("T3"."ID"=:B1)

PostgreSQL / MAX()関数を利用したスカラー副問合せ方式
Oracle同様に履歴データが大量にあったとしても影響を受けないのはわかりますね。
detail表2回アクセスを除けば（大切なのことなので、再度w

SELECT /*+ IndexScan(t1) IndexScan(t2) IndexScan(t3) */
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN detail t2 
  ON               
    t1.id = t2.id 
    AND t2.vnum = (
    SELECT 
      MAX(t3.vnum)
    FROM
      detail t3
    WHERE
      t3.id = t1.id 
  )
WHERE                    
  t1.id = 300
;

 t1id | t2id |  vnum  
------+------+--------
  300 |  300 | 100000
(1 row)

                                                                              QUERY PLAN                                                                              
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=1.67..17.72 rows=1 width=12) (actual time=0.033..0.035 rows=1 loops=1)
   Output: t1.id, t2.id, t2.vnum
   Inner Unique: true
   ->  Index Scan using master_pkey on scott.master t1  (cost=0.13..8.15 rows=1 width=4) (actual time=0.012..0.012 rows=1 loops=1)
         Output: t1.id
         Index Cond: (t1.id = 300)
   ->  Index Scan using ix2_detail on scott.detail t2  (cost=1.54..9.56 rows=1 width=8) (actual time=0.005..0.005 rows=1 loops=1)
         Output: t2.id, t2.vnum, t2.col1
         Index Cond: (t2.vnum = (SubPlan 2))
         Filter: (t2.id = 300)
         SubPlan 2
           ->  Result  (cost=1.24..1.25 rows=1 width=4) (actual time=0.013..0.013 rows=1 loops=1)
                 Output: (InitPlan 1).col1
                 InitPlan 1
                   ->  Limit  (cost=0.29..1.24 rows=1 width=4) (actual time=0.011..0.012 rows=1 loops=1)
                         Output: t3.vnum
                         ->  Index Scan Backward using pk_detail on scott.detail t3  (cost=0.29..1038.04 rows=1096 width=4) (actual time=0.011..0.011 rows=1 loops=1)
                               Output: t3.vnum
                               Index Cond: (t3.id = t1.id)
 Planning:
   Memory: used=78kB  allocated=128kB
 Planning Time: 0.177 ms
 Execution Time: 0.051 ms
(23 rows)

MySQL / MAX()関数を利用したスカラー副問合せ方式
MySQLでも同じ結果。履歴データ量の影響は受けません。

SELECT 
  t1.id AS t1id
  ,t2.id AS t2id
  ,t2.vnum AS vnum
FROM  
  master t1 
  LEFT OUTER JOIN detail t2 
  ON               
    t1.id = t2.id 
    AND t2.vnum = (
    SELECT 
      MAX(t3.vnum)
    FROM
      detail t3
    WHERE
      t3.id = t1.id 
  )
WHERE                    
  t1.id = 300
;

+------+------+--------+
| t1id | t2id | vnum   |
+------+------+--------+
|  300 |  300 | 100000 |
+------+------+--------+
1 row in set (0.00 sec)

+-------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                         |
+-------------------------------------------------------------------------------------------------+
| -> Rows fetched before execution  (cost=0..0 rows=1) (actual time=45e-6..90e-6 rows=1 loops=1)
 |
+-------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.00 sec)

mysql> show warnings;
+-------+------+------------------------------------------------------------------------------+
| Level | Code | Message                                                                      |
+-------+------+------------------------------------------------------------------------------+
| Note  | 1276 | Field or reference 'perftestdb.t1.id' of SELECT #2 was resolved in SELECT #1 |
+-------+------+------------------------------------------------------------------------------+
1 row in set (0.00 sec)

Oracle Database / ROW_NUMBER()ウィンドウ関数方式
おっと！
ここにきて履歴データの大きさの影響をおおきく受け始めました！。
A-ROWS も消費メモリも大きくなっていますね。100行の履歴データ以上に影響を受けてることがわかります！

SELECT 
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN  (
    SELECT
      id
      , vnum
      , ROW_NUMBER() OVER (
          PARTITION BY 
            detail.id 
          ORDER BY 
            detail.id DESC
            , detail.vnum DESC
      ) AS latest
    FROM
     detail
  ) t2
  ON 
    t1.id = t2.id
    AND t2.latest = 1
WHERE
    t1.id = 300
;

SCOTT@localhost:1521/freepdb1> /

      T1ID       T2ID       VNUM
---------- ---------- ----------
       300        300     100000

経過: 00:00:00.02


Plan hash value: 1648109658

----------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                       | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
----------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                |           |      1 |        |      1 |00:00:00.01 |     227 |       |       |          |
|   1 |  NESTED LOOPS OUTER             |           |      1 |    100K|      1 |00:00:00.01 |     227 |       |       |          |
|*  2 |   INDEX UNIQUE SCAN             | PK_MASTER |      1 |      1 |      1 |00:00:00.01 |       1 |       |       |          |
|*  3 |   VIEW PUSHED PREDICATE         |           |      1 |   1085 |      1 |00:00:00.01 |     226 |       |       |          |
|   4 |    WINDOW BUFFER                |           |      1 |   1085 |    100K|00:00:00.03 |     226 |  5297K|   950K| 4708K (0)|
|*  5 |     FILTER                      |           |      1 |        |    100K|00:00:00.01 |     226 |       |       |          |
|*  6 |      INDEX RANGE SCAN DESCENDING| PK_DETAIL |      1 |   1085 |    100K|00:00:00.01 |     226 |       |       |          |
----------------------------------------------------------------------------------------------------------------------------------

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

   2 - access("T1"."ID"=300)
   3 - filter("T2"."LATEST"=1)
   5 - filter("T1"."ID"=300)
   6 - access("ID"="T1"."ID")

PostgreSQL / ROW_NUMBER()ウィンドウ関数方式
多少ブレてはいますが、極端な影響はでいないように見えますね。PostgreSQLでは索引を降順で読み込み、Top 1 + 1まで読み止まっているようですし ( Index Scan Backward using ix2_detail on scott.detail (cost=0.29..3652.55 rows=100180 width=8) (actual time=0.009..0.010 rows=2 loops=1)
)。この機能、Oracle Databaseにも欲しいw Oracleは術後プッシュダウンまでは行えてるが、降順の索引スキャンが途中で止まらないので。

SELECT /*+ IndexScan(t1) IndexScan(detail) */
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN  (
    SELECT
      id
      , vnum
      , ROW_NUMBER() OVER (
          PARTITION BY 
            detail.id 
          ORDER BY 
            detail.id DESC
            , detail.vnum DESC
      ) AS latest
    FROM
     detail
  ) t2
  ON 
    t1.id = t2.id
    AND t2.latest = 1
WHERE
    t1.id = 300
;

 t1id | t2id |  vnum  
------+------+--------
  300 |  300 | 100000
(1 row)

                                                                         QUERY PLAN                                                                         
------------------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=0.48..6671.11 rows=501 width=12) (actual time=0.026..0.028 rows=1 loops=1)
   Output: t1.id, t2.id, t2.vnum
   Buffers: shared hit=5
   ->  Index Scan using master_pkey on scott.master t1  (cost=0.13..8.15 rows=1 width=4) (actual time=0.011..0.012 rows=1 loops=1)
         Output: t1.id
         Index Cond: (t1.id = 300)
         Buffers: shared hit=2
   ->  Subquery Scan on t2  (cost=0.35..6657.95 rows=501 width=8) (actual time=0.013..0.014 rows=1 loops=1)
         Output: t2.id, t2.vnum, t2.latest
         Filter: (t2.latest = 1)
         Buffers: shared hit=3
         ->  WindowAgg  (cost=0.35..5405.70 rows=100180 width=16) (actual time=0.013..0.014 rows=1 loops=1)
               Output: detail.id, detail.vnum, row_number() OVER (?)
               Run Condition: (row_number() OVER (?) <= 1)
               Buffers: shared hit=3
               ->  Index Scan Backward using ix2_detail on scott.detail  (cost=0.29..3652.55 rows=100180 width=8) (actual time=0.009..0.010 rows=2 loops=1)
                     Output: detail.id, detail.vnum
                     Filter: (detail.id = 300)
                     Buffers: shared hit=3
 Planning:
   Memory: used=48kB  allocated=64kB
 Planning Time: 0.143 ms
 Execution Time: 0.045 ms
(23 rows)

MySQL / ROW_NUMBER()ウィンドウ関数方式
MySQLの場合は、Oracle Databaseの述語プシュダウンと、PostgreSQLの述語プッシュダウン＋降順索引スキャン＋row_number() OVER (?) <= 1によるスキャン途中停止という挙動とは異なり、そもそも述語プッシュダウンできない！（不具合？）、できないので、detail表の索引を全索引スキャンしちゃってまっす！！！　なんと！！！！

SELECT 
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN  (
    select
      id
      , vnum
      , ROW_NUMBER() OVER (
          PARTITION BY 
            detail.id 
          ORDER BY 
            detail.id DESC
            , detail.vnum DESC
      ) AS latest
    FROM
     detail
  ) t2
  ON 
    t1.id = t2.id
    AND t2.latest = 1
WHERE
    t1.id = 300
;

+------+------+--------+
| t1id | t2id | vnum   |
+------+------+--------+
|  300 |  300 | 100000 |
+------+------+--------+
1 row in set (0.10 sec)

+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                                           |
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| -> Nested loop left join  (cost=10946 rows=109439) (actual time=127..127 rows=1 loops=1)
    -> Rows fetched before execution  (cost=0..0 rows=1) (actual time=45e-6..90e-6 rows=1 loops=1)
    -> Index lookup on t2 using  (id=300, latest=1)  (cost=10944..10947 rows=10) (actual time=127..127 rows=1 loops=1)
        -> Materialize  (cost=10944..10944 rows=109439) (actual time=127..127 rows=109610 loops=1)
            -> Window aggregate: row_number() OVER (PARTITION BY detail.id ORDER BY detail.id desc,detail.vnum desc )   (cost=0 rows=109439) (actual time=29.3..44.7 rows=109610 loops=1)
                -> Sort: detail.id, detail.id DESC, detail.vnum DESC  (cost=11000 rows=109439) (actual time=29.3..33.3 rows=109610 loops=1)
                    -> Covering index scan on detail using PRIMARY  (cost=11000 rows=109439) (actual time=0.677..11.9 rows=109610 loops=1)
 |
 +-------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.12 sec)

では真打。LATERAL JOIN だとどうなるか。。。MAX()関数とスカラー相関副問合せのように安定していい結果を出すのではないかと思いますよ。

Oracle Database / LATERAL JOIN + Top 1 Query方式
すばらしーーーーーーーーーーーぃ。履歴データ量の影響を受けないのは間違いないですね。

SELECT 
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN LATERAL (
       SELECT
        t2l.id
        , t2l.vnum
      FROM
       detail t2l
      WHERE
        t2l.id = t1.id
      ORDER BY
        t2l.id DESC
        , t2l.vnum DESC
      FETCH FIRST 1 ROWS ONLY
  ) t2
  ON TRUE
WHERE
  t1.id = 300
;

SCOTT@localhost:1521/freepdb1> /

      T1ID       T2ID       VNUM
---------- ---------- ----------
       300        300     100000

経過: 00:00:00.00


Plan hash value: 43833377

--------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name            | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |                 |      1 |        |      1 |00:00:00.01 |       3 |
|   1 |  NESTED LOOPS OUTER              |                 |      1 |      1 |      1 |00:00:00.01 |       3 |
|*  2 |   INDEX UNIQUE SCAN              | PK_MASTER       |      1 |      1 |      1 |00:00:00.01 |       1 |
|   3 |   VIEW                           | VW_LAT_6FD14B30 |      1 |      1 |      1 |00:00:00.01 |       2 |
|   4 |    VIEW                          | VW_LAT_A18161FF |      1 |      1 |      1 |00:00:00.01 |       2 |
|*  5 |     COUNT STOPKEY                |                 |      1 |        |      1 |00:00:00.01 |       2 |
|   6 |      VIEW                        |                 |      1 |      2 |      1 |00:00:00.01 |       2 |
|*  7 |       INDEX RANGE SCAN DESCENDING| PK_DETAIL       |      1 |   1085 |      1 |00:00:00.01 |       2 |
--------------------------------------------------------------------------------------------------------------

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

   2 - access("T1"."ID"=300)
   5 - filter(ROWNUM<=1)
   7 - access("T2L"."ID"="T1"."ID")

PostgreSQL / LATERAL JOIN + Top 1 Query方式
PostgreSQLも履歴データの影響は一切なさそうですよね。

SELECT /*+ IndexScan(t1) IndexScan(detail) */
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN LATERAL (
       SELECT
        t2l.id
        , t2l.vnum
      FROM
       detail t2l
      WHERE
        t2l.id = t1.id
      ORDER BY
        t2l.id DESC
        , t2l.vnum DESC
      LIMIT 1
  ) t2
  ON TRUE
WHERE
  t1.id = 300
;

 t1id | t2id |  vnum  
------+------+--------
  300 |  300 | 100000
(1 row)


                                                                        QUERY PLAN                                                                        
----------------------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=0.42..8.48 rows=1 width=12) (actual time=0.024..0.025 rows=1 loops=1)
   Output: t1.id, t2l.id, t2l.vnum
   Buffers: shared hit=5
   ->  Index Scan using master_pkey on scott.master t1  (cost=0.13..8.15 rows=1 width=4) (actual time=0.012..0.012 rows=1 loops=1)
         Output: t1.id
         Index Cond: (t1.id = 300)
         Buffers: shared hit=2
   ->  Limit  (cost=0.29..0.32 rows=1 width=8) (actual time=0.011..0.011 rows=1 loops=1)
         Output: t2l.id, t2l.vnum
         Buffers: shared hit=3
         ->  Index Only Scan Backward using pk_detail on scott.detail t2l  (cost=0.29..35.47 rows=1096 width=8) (actual time=0.010..0.010 rows=1 loops=1)
               Output: t2l.id, t2l.vnum
               Index Cond: (t2l.id = t1.id)
               Heap Fetches: 0
               Buffers: shared hit=3
 Planning:
   Memory: used=39kB  allocated=64kB
 Planning Time: 0.113 ms
 Execution Time: 0.037 ms
(19 rows)

MySQL / LATERAL JOIN + Top 1 Query方式
Materialize操作が入っている部分は他のRDBMSでは見られない特徴ですが、 MySQL / MAX()関数を利用したスカラー副問合せ方式が最速ですね。MySQLではw すごい良い癖w

SELECT 
  t1.id AS t1id
  , t2.id AS t2id
  , t2.vnum
FROM 
  master t1 
  LEFT OUTER JOIN LATERAL (
       SELECT
        t2l.id
        , t2l.vnum
      FROM
       detail t2l
      WHERE
        t2l.id = t1.id
      ORDER BY
        t2l.id DESC
        , t2l.vnum DESC
      LIMIT 1
  ) t2
  ON TRUE
WHERE
  t1.id = 300
;

+------+------+--------+
| t1id | t2id | vnum   |
+------+------+--------+
|  300 |  300 | 100000 |
+------+------+--------+
1 row in set (0.00 sec)

+--------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                    |
+--------------------------------------------------------------------------------------------------------------------------------------------+
| -> Nested loop left join  (cost=2.73 rows=2) (actual time=0.105..0.106 rows=1 loops=1)
    -> Rows fetched before execution  (cost=0..0 rows=1) (actual time=90e-6..135e-6 rows=1 loops=1)
    -> Table scan on t2  (cost=2.73..2.73 rows=1) (actual time=0.102..0.102 rows=1 loops=1)
        -> Materialize  (cost=105..105 rows=2) (actual time=0.101..0.101 rows=1 loops=1)
            -> Limit: 1 row(s)  (cost=105 rows=1) (actual time=0.0914..0.0914 rows=1 loops=1)
                -> Covering index lookup on t2l using PRIMARY (id='300') (reverse)  (cost=105 rows=1042) (actual time=0.0906..0.0906 rows=1 loops=1)
 |
+--------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.02 sec)

mysql> show warnings;
+-------+------+------------------------------------------------------------------------------+
| Level | Code | Message                                                                      |
+-------+------+------------------------------------------------------------------------------+
| Note  | 1276 | Field or reference 'perftestdb.t1.id' of SELECT #2 was resolved in SELECT #1 |
+-------+------+------------------------------------------------------------------------------+
1 row in set (0.00 sec)

では、また！

最近、いろいろ衝撃的なw SQLを見たりして、この世界では、いつになったら飽きという事象が来るのやらw （多分、来ないと思うwwww

Enjoy SQLs！

投稿日時 2026年6月13日 (土) 16時18分 Oracle, チューニング, FAQ, SQL, VirtualBox, MySQL, PostgreSQL, パフォーマンス, Index Only Scan, INDEX, Apple Silicon ARM64, Oracle Database 23ai | 固定リンク | 0 | コメント (0)

2026年6月 9日 (火)

2026年5月に作ったLoop

To Sigh Loops v1.1 - Dub version of Too many Loops - / N + 1 Loops
80'sのなにかの曲を思い出してもらえればw

A certain Loops / N + 1 Loops
ぼやーーんとしたいときむけw

以上、2曲でした。

Enjoy DTM and GarageBand.

GarageBandにもAIきたりするのだろうか。。。

投稿日時 2026年6月 9日 (火) 19時17分音楽, GarageBand, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2026年5月 9日 (土)

2026年4月に作ったLoop

Too many Loops / N + 1 Loops
これ作ってる時にイントロ部分のシンセ使ったダブバージョンが浮かんで即作ったのだが、その後v1.1リリースしたので、こいつだけ。ということにしておくw

投稿日時 2026年5月 9日 (土) 14時34分音楽, GarageBand, iMovie, DTM, AppleLoops, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2026年4月10日 (金)

2026年3月に作ったLoop

Stare blankly Loops / N + 1 Loops
これも粛々と仕事をこなすときの無限ループBGMとして思いつきでつくったやつの一つ。

Cherry Blossom Loops 2026 / N + 1 Loops
ちょうど桜が咲いてたので今年バージョン（昨年も作ってたけどねw）。前述のループのドラム部分だけ気に入ってたので、他にも再利用したいなー思いつつ。他にも思いついたので今月は別のを作ってるわけですけどもねw。

投稿日時 2026年4月10日 (金) 18時30分音楽, GarageBand, iMovie, DTM, AppleLoops, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2026年3月22日 (日)

2026年2月に作ったLoop

Loops and Loops! / N + 1 Loops
先月作ったループのドラムトラックが気に入りw再利用してなにかを作るということだけが目的で作ってみた一つ目。

Heavy Query Blues Loops / N + 1 Loops
ブルース風になったが、それなりに雰囲気でたかもw これもドラムトラックの一部は先月作ったループのを再利用してます。

投稿日時 2026年3月22日 (日) 10時41分音楽, GarageBand, iMovie, DTM, AppleLoops, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2026年3月10日 (火)

x86/64 VMs on VirtualBox for macOS - Apple Silicon / Oracle Database , PostgreSQL, MySQL rebooted! :)

さてさて、半年振りぐらいの、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

PostgreSQL 16.3

X86_64です！、起動してます！！！

[master@localhost ~]$ uname -rm
5.4.17-2136.304.4.1.el8uek.x86_64 x86_64

...略...

[master@localhost ~]$ sudo service postgresql-16 status
[sudo] master のパスワード:
Redirecting to /bin/systemctl status postgresql-16.service
● postgresql-16.service - PostgreSQL 16 database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql-16.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2026-03-09 20:32:25 EDT; 2min 47s ago

...略...

 Main PID: 1363 (postgres)
    Tasks: 7 (limit: 22947)
   Memory: 35.8M

...略...

[postgres@localhost ~]$ psql -d perftestdb -U discus -p 5432 -W -h localhost

...略...

perftestdb=> select version();
                                                 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
(1 行)

[master@localhost ~]$ sudo service postgresql-16 stop
Redirecting to /bin/systemctl stop postgresql-16.service
[master@localhost ~]$ sudo service postgresql-16 status
Redirecting to /bin/systemctl status postgresql-16.service
● postgresql-16.service - PostgreSQL 16 database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql-16.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Mon 2026-03-09 20:35:51 EDT; 3s ago

...略...

 Main PID: 1363 (code=exited, status=0/SUCCESS)

 3月 09 20:32:21 localhost.localdomain systemd[1]: Starting PostgreSQL 16 database server...
 3月 09 20:32:24 localhost.localdomain postgres[1363]: 2026-03-09 20:32:24.655 EDT [1363] LOG:  redirecting log output to logging 

...略...
 
 3月 09 20:35:50 localhost.localdomain systemd[1]: Stopping PostgreSQL 16 database server...
 3月 09 20:35:51 localhost.localdomain systemd[1]: postgresql-16.service: Killing process 1390 (postgres) with signal SIGKILL.
 3月 09 20:35:51 localhost.localdomain systemd[1]: postgresql-16.service: Succeeded.
 3月 09 20:35:51 localhost.localdomain systemd[1]: Stopped PostgreSQL 16 database server.

MySQL 8.0.36

X86_64です！、起動してます！

[master@localhost ~]$ uname -rm
5.4.17-2136.304.4.1.el8uek.x86_64 x86_64

...略...

[master@localhost ~]$ sudo service mysqld status
Redirecting to /bin/systemctl status mysqld.service
● mysqld.service - MySQL 8.0 database server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2026-03-09 20:32:28 EDT; 3min 38s ago

...略...

   Memory: 444.0M
   CGroup: /system.slice/mysqld.service
           └─1102 /usr/libexec/mysqld --basedir=/usr

 3月 09 20:32:04 localhost.localdomain systemd[1]: Starting MySQL 8.0 database server...
 3月 09 20:32:28 localhost.localdomain systemd[1]: Started MySQL 8.0 database server.
[master@localhost ~]$ mysql -u scott -D perftestdb -p 
Enter password: 

...略...

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+
1 row in set (0.00 sec)

mysql> exit
Bye
[master@localhost ~]$ sudo service mysqld stop
Redirecting to /bin/systemctl stop mysqld.service
[master@localhost ~]$ sudo service mysqld status
Redirecting to /bin/systemctl status mysqld.service
● mysqld.service - MySQL 8.0 database server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Mon 2026-03-09 20:36:32 EDT; 3s ago

...略...

 Main PID: 1102 (code=exited, status=0/SUCCESS)
   Status: "Server shutdown complete"

 3月 09 20:32:04 localhost.localdomain systemd[1]: Starting MySQL 8.0 database server...
 3月 09 20:32:28 localhost.localdomain systemd[1]: Started MySQL 8.0 database server.
 3月 09 20:36:30 localhost.localdomain systemd[1]: Stopping MySQL 8.0 database server...
 3月 09 20:36:32 localhost.localdomain systemd[1]: mysqld.service: Succeeded.
 3月 09 20:36:32 localhost.localdomain systemd[1]: Stopped MySQL 8.0 database server.

Oracle Database 21c

X86_64です！、起動してまーーーーーーーーーす！

[oracle@localhost ~]$ uname -rm
5.4.17-2102.201.3.el8uek.x86_64 x86_64

...略...

[oracle@localhost ~]$ lsnrctl start

...略...

/opt/oracle/product/21c/dbhome_1/bin/tnslsnrを起動しています。お待ちください...

TNSLSNR for Linux: Version 21.0.0.0.0 - Production
システム・パラメータ・ファイルは/opt/oracle/homes/OraDBHome21cEE/network/admin/listener.oraです。
ログ・メッセージを/opt/oracle/diag/tnslsnr/localhost/listener/alert/log.xmlに書き込みました。
リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521)))
リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))

...略...

[oracle@localhost ~]$ sqlplus / as sysdba

...略...

アイドル・インスタンスに接続しました。

SYS@ORCLCDB> startup
ORACLEインスタンスが起動しました。

Total System Global Area 1073740720 bytes
Fixed Size                  9694128 bytes
Variable Size             897581056 bytes
Database Buffers           54525952 bytes
Redo Buffers                7081984 bytes
In-Memory Area            104857600 bytes
データベースがマウントされました。
データベースがオープンされました。

SYS@ORCLCDB> 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

SYS@ORCLCDB> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。

SYS@ORCLCDB>

ということで、ARM64 VMsとx86_64 VMs が、 macOS / Apple Silicon　に同居させて遊べる環境のできあがりーーーーー！

ひとまず、一件落着

Enjoy RDBMSs on VirtualBox!

では、また。

投稿日時 2026年3月10日 (火) 19時22分 Oracle, Mac, Linux, VirtualBox, MySQL, PostgreSQL, Oracle Database 21c, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2026年2月 8日 (日)

2026年1月に作ったLoop

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月 8日 (日) 06時58分音楽, GarageBand, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2026年2月 5日 (木)

Oracle Database - Multi Row INSERT、バインド変数を使うとリテラル値を使う場合では見える景色が変わるんだよね #最終回 - ぐるぐるしちゃう影響

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行毎ぐるぐるすると無駄が多くなるのは一目瞭然だと思います。

一応、ログは以下のような感じ。
Client -> Datatabase - Single row Insert / commit間隔の調整
いわゆる、普通のぐるぐる系ですw

[oracle@arm64-oraclelinux8u10 ~]$ java -classpath ./:$CLASSPATH Oracle23aiDynamicBulkLoad 100000 1 1; ./post_process.sh

...略...

Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.8.0.25.04
に接続されました。

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       212 CPU used by this session                                                  4
       212 CPU used when call started                                                1
       212 SQL*Net roundtrips to/from client                                         2
...略...
       212 execute count                                                           621
...略...
       212 parse count (hard)                                                      100
       212 parse count (total)                                                     144
       212 parse time cpu                                                            2
       212 parse time elapsed                                                        2
...略...
       212 session pga memory                                                  3337208
       212 session pga memory max                                              5189280
       212 session uga memory                                                  1904696
       212 session uga memory max                                              3119464
...略...

ロード開始: 総計 100000 行 (チャンクサイズ: 1 コミット間隔: 1)
完了！ 総時間: 43.42 秒

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       212 CPU used by this session                                                694
       212 CPU used when call started                                              694
...略...
       212 SQL*Net roundtrips to/from client                                    200002
...略...
       212 execute count                                                        100669
...略...
       212 parse count (hard)                                                      106
       212 parse count (total)                                                  100149
       212 parse time cpu                                                            4
       212 parse time elapsed                                                       23
...略...
       212 session pga memory                                                  3402744
       212 session pga memory max                                              5189280
       212 session uga memory                                                  1904696
       212 session uga memory max                                              3119464
...略...
       212 user commits                                                         100000

...略...

  COUNT(1)
----------
    100000

SEGMENT_NAME                           MB
------------------------------ ----------
MROWS_INS_TAB                          45

表が切り捨てられました。

[oracle@arm64-oraclelinux8u10 ~]$ java -classpath ./:$CLASSPATH Oracle23aiDynamicBulkLoad 100000 1 10; ./post_process.sh

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       176 CPU used by this session                                                  4
       176 CPU used when call started                                                1
       176 SQL*Net roundtrips to/from client                                         2
...略...
       176 execute count                                                           417
...略...
       176 parse count (hard)                                                       78
       176 parse count (total)                                                     126
       176 parse time cpu                                                            5
       176 parse time elapsed                                                        5
...略...
       176 session pga memory                                                  3026592
       176 session pga memory max                                              5123744
       176 session uga memory                                                  1773632
       176 session uga memory max                                              3053928
...略...

ロード開始: 総計 100000 行 (チャンクサイズ: 1 コミット間隔: 10)
完了！ 総時間: 43.25 秒

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       176 CPU used by this session                                                705
       176 CPU used when call started                                              705
...略...
       176 SQL*Net roundtrips to/from client                                    200002
...略...
       176 execute count                                                        100441
...略...
       176 parse count (hard)                                                       81
       176 parse count (total)                                                  100129
       176 parse time cpu                                                            9
       176 parse time elapsed                                                       21
...略...
       176 session pga memory                                                  3026592
       176 session pga memory max                                              5123744
       176 session uga memory                                                  1773632
       176 session uga memory max                                              3053928
...略...
       176 user commits                                                         100000
...略...

  COUNT(1)
----------
    100000

...略...

[oracle@arm64-oraclelinux8u10 ~]$ java -classpath ./:$CLASSPATH Oracle23aiDynamicBulkLoad 100000 1 100; ./post_process.sh

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        44 CPU used by this session                                                  5
        44 CPU used when call started                                                1
        44 SQL*Net roundtrips to/from client                                         2
...略...
        44 execute count                                                           621
...略...
        44 parse count (hard)                                                      100
        44 parse count (total)                                                     144
        44 parse time cpu                                                            4
        44 parse time elapsed                                                        6
...略...
        44 session logical reads                                                  2518
        44 session pga memory                                                  3206136
        44 session pga memory max                                              5123744
        44 session uga memory                                                  1904800
        44 session uga memory max                                              3054064
...略...

ロード開始: 総計 100000 行 (チャンクサイズ: 1 コミット間隔: 100)
完了！ 総時間: 43.68 秒

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        44 CPU used by this session                                                723
        44 CPU used when call started                                              723
...略...
        44 SQL*Net roundtrips to/from client                                    200002
...略...
        44 execute count                                                        100669
...略...
        44 parse count (hard)                                                      106
        44 parse count (total)                                                  100149
        44 parse time cpu                                                            8
        44 parse time elapsed                                                       28
...略...
        44 session pga memory                                                  3271672
        44 session pga memory max                                              5123744
        44 session uga memory                                                  1904800
        44 session uga memory max                                              3054064
...略...
        44 user commits                                                         100000
...略...

  COUNT(1)
----------
    100000
...略...

[oracle@arm64-oraclelinux8u10 ~]$ java -classpath ./:$CLASSPATH Oracle23aiDynamicBulkLoad 100000 1 1000; ./post_process.sh

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        39 CPU used by this session                                                  4
        39 CPU used when call started                                                1
        39 SQL*Net roundtrips to/from client                                         2
...略...
        39 execute count                                                           621
...略...
        39 parse count (hard)                                                      100
        39 parse count (total)                                                     144
        39 parse time cpu                                                            3
        39 parse time elapsed                                                        1
...略...
        39 session pga memory                                                  3206136
        39 session pga memory max                                              5123744
        39 session uga memory                                                  1904800
        39 session uga memory max                                              3054064
...略...

ロード開始: 総計 100000 行 (チャンクサイズ: 1 コミット間隔: 1000)
完了！ 総時間: 42.41 秒

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        39 CPU used by this session                                                698
        39 CPU used when call started                                              698
...略...
        39 SQL*Net roundtrips to/from client                                    200002
...略...
        39 execute count                                                        100669
...略...
        39 parse count (hard)                                                      106
        39 parse count (total)                                                  100149
        39 parse time cpu                                                           10
        39 parse time elapsed                                                       23
...略...
        39 session pga memory                                                  3271672
        39 session pga memory max                                              5123744
        39 session uga memory                                                  1904800
        39 session uga memory max                                              3054064
...略...
        39 user commits                                                         100000

...略...

  COUNT(1)
----------
    100000

...略...

[oracle@arm64-oraclelinux8u10 ~]$ java -classpath ./:$CLASSPATH Oracle23aiDynamicBulkLoad 100000 1 10000; ./post_process.sh

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       176 CPU used by this session                                                  3
       176 CPU used when call started                                                1
       176 SQL*Net roundtrips to/from client                                         2
...略...
       176 execute count                                                           621
...略...
       176 parse count (hard)                                                      100
       176 parse count (total)                                                     144
       176 parse time cpu                                                            1
       176 parse time elapsed                                                        3
...略...
       176 session pga memory                                                  3206136
       176 session pga memory max                                              5123744
       176 session uga memory                                                  1904800
       176 session uga memory max                                              3054064
...略...

ロード開始: 総計 100000 行 (チャンクサイズ: 1 コミット間隔: 10000)
完了！ 総時間: 41.98 秒

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       176 CPU used by this session                                                673
       176 CPU used when call started                                              673
...略...
       176 SQL*Net roundtrips to/from client                                    200002
...略...
       176 execute count                                                        100669
...略...
       176 parse count (hard)                                                      106
       176 parse count (total)                                                  100149
       176 parse time cpu                                                            6
       176 parse time elapsed                                                       22
...略...
       176 session pga memory                                                  3271672
       176 session pga memory max                                              5123744
       176 session uga memory                                                  1904800
       176 session uga memory max                                              3054064
...略...
       176 user commits                                                         100000

...略...

  COUNT(1)
----------
    100000

...略...

[oracle@arm64-oraclelinux8u10 ~]$ java -classpath ./:$CLASSPATH Oracle23aiDynamicBulkLoad 100000 1 100000; ./post_process.sh

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       176 CPU used by this session                                                  5
       176 CPU used when call started                                                1
       176 SQL*Net roundtrips to/from client                                         2
...略...
       176 execute count                                                           621
...略...
       176 parse count (hard)                                                      100
       176 parse count (total)                                                     144
       176 parse time cpu                                                            1
       176 parse time elapsed                                                        3
...略...
       176 session pga memory                                                  3206136
       176 session pga memory max                                              5123744
       176 session uga memory                                                  1904800
       176 session uga memory max                                              3054064
...略...

ロード開始: 総計 100000 行 (チャンクサイズ: 1 コミット間隔: 100000)
完了！ 総時間: 41.62 秒

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       176 CPU used by this session                                                698
       176 CPU used when call started                                              698
...略...
       176 SQL*Net roundtrips to/from client                                    200002
...略...
       176 execute count                                                        100669
...略...
       176 parse count (hard)                                                      106
       176 parse count (total)                                                  100149
       176 parse time cpu                                                            4
       176 parse time elapsed                                                       26
...略...
       176 session pga memory                                                  3271672
       176 session pga memory max                                              5123744
       176 session uga memory                                                  1904800
       176 session uga memory max                                              3054064
...略...
       176 user commits                                                         100000
...略...

  COUNT(1)
----------
    100000

...略...

Client -> Datatabase - Multi row Insert / バルクロード行数調整
Multi row Insertなので繰り返し実行ではありますが、ぐるぐる　というより、ぐーーーーる、ぐーーーーる系な感じw です。( N+1だと　ぐるぐる、ぐーーーる、ぐーーるの違いを表現できなーーーいw )

[oracle@arm64-oraclelinux8u10 ~]$ java -classpath ./:$CLASSPATH Oracle23aiDynamicBulkLoad 100000 10 1; ./post_process.sh
...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        38 CPU used by this session                                                  4
        38 CPU used when call started                                                1
        38 SQL*Net roundtrips to/from client                                         2
...略...
        38 execute count                                                           621
...略...
        38 parse count (hard)                                                      100
        38 parse count (total)                                                     144
        38 parse time cpu                                                            2
        38 parse time elapsed                                                        5
...略...
        38 session pga memory                                                  3206136
        38 session pga memory max                                              5123744
        38 session uga memory                                                  1904800
        38 session uga memory max                                              3054064
...略...

ロード開始: 総計 100000 行 (チャンクサイズ: 10 コミット間隔: 1)
完了！ 総時間: 5.44 秒

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        38 CPU used by this session                                                 98
        38 CPU used when call started                                               98
        38 SQL*Net roundtrips to/from client                                     20002
...略...
        38 execute count                                                         10719
...略...
        38 parse count (hard)                                                      107
        38 parse count (total)                                                   10154
        38 parse time cpu                                                            5
        38 parse time elapsed                                                       10
...略...
        38 session pga memory                                                  3337208
        38 session pga memory max                                              5123744
        38 session uga memory                                                  1970280
        38 session uga memory max                                              3054064
...略...
        38 user commits                                                          10000

...略...

  COUNT(1)
----------
    100000

...略...

[oracle@arm64-oraclelinux8u10 ~]$ java -classpath ./:$CLASSPATH Oracle23aiDynamicBulkLoad 100000 100 1; ./post_process.sh

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        38 CPU used by this session                                                  4
        38 CPU used when call started                                                1
        38 SQL*Net roundtrips to/from client                                         2
...略...
        38 execute count                                                           621
...略...
        38 parse count (hard)                                                      100
        38 parse count (total)                                                     144
        38 parse time cpu                                                            2
        38 parse time elapsed                                                        2
...略...
        38 session pga memory                                                  3206136
        38 session pga memory max                                              5123744
        38 session uga memory                                                  1904800
        38 session uga memory max                                              3054064
...略...

ロード開始: 総計 100000 行 (チャンクサイズ: 100 コミット間隔: 1)
完了！ 総時間: 1.34 秒

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        38 CPU used by this session                                                 35
        38 CPU used when call started                                               35
        38 SQL*Net roundtrips to/from client                                      2002
...略...
        38 execute count                                                          1719
...略...
        38 parse count (hard)                                                      107
        38 parse count (total)                                                    1154
        38 parse time cpu                                                            2
        38 parse time elapsed                                                        2
...略...
        38 session pga memory                                                  3795960
        38 session pga memory max                                              7400440
        38 session uga memory                                                  2101240
        38 session uga memory max                                              3054064
...略...
        38 user commits                                                           1000
...略...

  COUNT(1)
----------
    100000

...略...

[oracle@arm64-oraclelinux8u10 ~]$ java -classpath ./:$CLASSPATH Oracle23aiDynamicBulkLoad 100000 1000 1; ./post_process.sh

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        38 CPU used by this session                                                  5
        38 CPU used when call started                                                1
        38 SQL*Net roundtrips to/from client                                         2
...略...
        38 execute count                                                           621
...略...
        38 parse count (hard)                                                      100
        38 parse count (total)                                                     144
        38 parse time cpu                                                            3
        38 parse time elapsed                                                        3
...略...
        38 session pga memory                                                  3206136
        38 session pga memory max                                              5123744
        38 session uga memory                                                  1904800
        38 session uga memory max                                              3054064
...略...

ロード開始: 総計 100000 行 (チャンクサイズ: 1000 コミット間隔: 1)
完了！ 総時間: 1.21 秒

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        38 CPU used by this session                                                 63
        38 CPU used when call started                                               63
        38 SQL*Net roundtrips to/from client                                       202
...略...
        38 execute count                                                           819
...略...
        38 parse count (hard)                                                      107
        38 parse count (total)                                                     254
        38 parse time cpu                                                            9
        38 parse time elapsed                                                       11
...略...
        38 session pga memory                                                  3533816
        38 session pga memory max                                             34925560
        38 session uga memory                                                  2232200
        38 session uga memory max                                              5702640
...略...
        38 user commits                                                            100
...略...

  COUNT(1)
----------
    100000

...略...

[oracle@arm64-oraclelinux8u10 ~]$ java -classpath ./:$CLASSPATH Oracle23aiDynamicBulkLoad 100000 10000 1; ./post_process.sh

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        19 CPU used by this session                                                  5
        19 CPU used when call started                                                2
        19 SQL*Net roundtrips to/from client                                         2
...略...
        19 execute count                                                           559
...略...
        19 parse count (hard)                                                      100
        19 parse count (total)                                                     142
        19 parse time cpu                                                            5
        19 parse time elapsed                                                        3
...略...
        19 session pga memory                                                  3271672
        19 session pga memory max                                              5123744
        19 session uga memory                                                  1899488
        19 session uga memory max                                              3053984
...略...

ロード開始: 総計 100000 行 (チャンクサイズ: 10000 コミット間隔: 1)
完了！ 総時間: 33.74 秒

...略...

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        19 CPU used by this session                                               3334
        19 CPU used when call started                                             3334
        19 SQL*Net roundtrips to/from client                                        22
...略...
        19 execute count                                                           667
...略...
        19 parse count (hard)                                                      107
        19 parse count (total)                                                     162
        19 parse time cpu                                                          728
        19 parse time elapsed                                                      730
...略...
        19 session pga memory                                                  6286328
        19 session pga memory max                                            286518264
        19 session uga memory                                                  5043712
        19 session uga memory max                                             31643696
...略...
        19 user commits                                                             10

...略...

  COUNT(1)
----------
    100000

...略...

ふーーーっ。

完！

では、また、別のネタでお会いしましょう :)

テスト環境の情報
macOS Apple SiliconのVirtualBox

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

VMのOS、および、Java

[oracle@arm64-oraclelinux8u10 ~]$ java -version
openjdk version "11.0.25" 2024-10-15 LTS
OpenJDK Runtime Environment (Red_Hat-11.0.25.0.9-1.0.1) (build 11.0.25+9-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-11.0.25.0.9-1.0.1) (build 11.0.25+9-LTS, mixed mode, sharing)


[oracle@arm64-oraclelinux8u10 ~]$ uname -rpo
5.15.0-313.189.5.3.el8uek.aarch64 aarch64 GNU/Linux
[oracle@arm64-oraclelinux8u10 ~]$ cat /etc/os-release
NAME="Oracle Linux Server"
VERSION="8.10"

...略...

ソース

[oracle@arm64-oraclelinux8u10 ~]$ cat show_mrows_ins_tab_size.sql
select segment_name,bytes/1024/1024 as "MB" from dba_segments where owner='SCOTT' and segment_name = upper('mrows_ins_tab')
/

[oracle@arm64-oraclelinux8u10 ~]$ cat post_process.sh
sqlplus system/hogehoge@localhost:1521/freepdb1 @post_process

[oracle@arm64-oraclelinux8u10 ~]$ cat post_process.sql
SELECT COUNT(1) FROM scott.mrows_ins_tab
/

@show_mrows_ins_tab_size

truncate table scott.mrows_ins_tab
/
exit

[oracle@arm64-oraclelinux8u10 ~]$ cat show_mystats.sh
sqlplus system/hogehoge@localhost:1521/freepdb1 @show_mystats2 scott

[oracle@arm64-oraclelinux8u10 ~]$ cat show_mystats2.sql
set veri off
SELECT
    s.sid,
    n.name,
    s.value
FROM
    v$sesstat s
    INNER JOIN v$statname n 
    ON 
      s.statistic# = n.statistic#
      AND s.sid = (SELECT sid FROM v$session WHERE username = UPPER('&1'))
WHERE
    s.value > 0
    AND (
      n.name LIKE '%memory%'
      OR n.name LIKE '%CPU%'
      OR n.name LIKE '%I/O%'
      OR n.name LIKE '%write%'
      OR n.name LIKE '%read%'
      OR n.name LIKE 'redo%'
      OR n.name LIKE 'SQL*Net%'
      OR n.name LIKE '%commit%'
      OR n.name LIKE 'execute count'
      OR n.name LIKE 'parse%'
   )
ORDER BY
    n.name;

UNDEFINE 1
set veri on
exit

Geminiくんに書いてもらったJavaのコードw

[oracle@arm64-oraclelinux8u10 ~]$ cat Oracle23aiDynamicBulkLoad.java
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.SQLException;
import java.io.IOException;
import java.io.InputStream;
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.util.Collections;

public class Oracle23aiDynamicBulkLoad {

    private static final String URL = "jdbc:oracle:thin:@localhost:1521/freepdb1";
    private static final String USER = "scott";
    private static final String PASSWORD = "hogehoge";

    public static void main(String[] args) {
        // インサートする行数、デフォルト値(10万行)
        int totalRows = (args.length > 0) ? Integer.parseInt(args[0]) : 100000;
        // 1回あたりの同時インサート行数、デフォルト100行
        int chunkSize = (args.length > 1) ? Integer.parseInt(args[1]) : 100;
        // commit interval, デフォルト1行
        int commitInterval = (args.length > 2) ? Integer.parseInt(args[2]) : 1;


        try (Connection conn = DriverManager.getConnection(URL, USER, PASSWORD)) {
            conn.setAutoCommit(false);
            showSessionStats();

            System.out.println("ロード開始: 総計 " + totalRows + " 行 (チャンクサイズ: " + chunkSize + " コミット間隔: " + commitInterval + ")");
            long startTime = System.currentTimeMillis();

            for (int i = 0; i < totalRows; i += chunkSize) {
                int currentBatchSize = Math.min(chunkSize, totalRows - i);
                executeMultiRowInsert(conn, i, currentBatchSize);

                if (chunkSize == 1 && (i % commitInterval) == 0) {
                    conn.commit();
                } else {
                    conn.commit();
                }
            }

            long endTime = System.currentTimeMillis();
            System.out.printf("完了！ 総時間: %.2f 秒%n", (endTime - startTime) / 1000.0);

            showSessionStats();
            conn.disconnect();

        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

    public static void showSessionStats() {
        try {
            ProcessBuilder pb = new ProcessBuilder("/bin/bash", "-c", "/home/oracle/show_mystats.sh");
            Process process = pb.start();

            // 結果の取得
            InputStream is = process.getInputStream();
            InputStreamReader isr = new InputStreamReader(is);
            BufferedReader br = new BufferedReader(isr);

            String line;
            while ((line = br.readLine()) != null) {
                System.out.println(line);
            }

            // 終了コードを取得
            int exitCode = process.waitFor();
            System.out.println("Exited with code: " + exitCode);

        } catch (IOException | InterruptedException e) {
            e.printStackTrace();
        }
    }

    private static String lpad(String original, int length, String padChar) {
        if (original.length() >= length) return original;
        return padChar.repeat(length - original.length()) + original;
    }

    private static void executeMultiRowInsert(Connection conn, int offset, int rowCount) throws SQLException {
        String rowPlaceholder = "(?, ?)";
        String allPlaceholders = String.join(", ", Collections.nCopies(rowCount, rowPlaceholder));

        String sql = "INSERT /* MONITOR */ INTO mrows_ins_tab (id, col8) VALUES " + allPlaceholders;

        try (PreparedStatement pstmt = conn.prepareStatement(sql)) {
            for (int i = 0; i < rowCount; i++) {
                int id = offset + i + 1;
                int baseIdx = i * 2;
                String col8 = lpad(String.valueOf(id), 373, "x");
                pstmt.setInt(baseIdx + 1, id);
                pstmt.setString(baseIdx + 2, col8);
            }
            pstmt.executeUpdate();
        }
    }
}

投稿日時 2026年2月 5日 (木) 19時45分 Oracle, Java, チューニング, FAQ, SQL, VirtualBox, パフォーマンス, Apple Silicon ARM64, Oracle Database 23ai | 固定リンク | 0 | コメント (0)

2026年2月 4日 (水)

Oracle Database - Multi Row INSERT、バインド変数を使うとリテラル値を使う場合では見える景色が変わるんだよね #4 - The SQL was transformed!

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 の奥へ進んでいきましょう ;)

まずは、10046トレースでローカル表とリモート表への実行でどういう差があるのかを見ておく。

バインド変数を利用し、1000 rows / INSERTをローカル表へ実行した場合の10046トレース

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> alter session set tracefile_identifier='10046_mrows_local';

セッションが変更されました。
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> @multi_row_insert_bind_1000 100000 1000

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       201 CPU used by this session                                                 38
       201 CPU used when call started                                               36
       201 SQL*Net roundtrips to/from client                                        11
...略...
       201 execute count                                                          2329
...略...
       201 session pga memory                                                  6696608
       201 session pga memory max                                              9055904
       201 session uga memory                                                  3178192
       201 session uga memory max                                              4776536
...略...

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

経過: 00:00:02.79

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       201 CPU used by this session                                                313
       201 CPU used when call started                                              313
       201 SQL*Net roundtrips to/from client                                        16
...略...
       201 execute count                                                          2724
...略...
       201 session pga memory                                                  8055800
       201 session pga memory max                                             52702880
       201 session uga memory                                                  4658456
       201 session uga memory max                                              4776536
...略...
       201 user commits                                                            100
...略...

  COUNT(1)
----------
    100000

...略...
SCOTT@localhost:1521/freepdb1> alter session set events '10046 trace name context off';
...略...

バインド変数を利用し、1000 rows / INSERTをリモート表（via DB Link）へ実行した場合の10046トレース

Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.8.0.25.04
に接続されました。
SCOTT2@localhost:1521/freepdb1> alter session set tracefile_identifier='10046_mrows_remote';

セッションが変更されました。
SCOTT2@localhost:1521/freepdb1> alter session set statistics_level=all;

セッションが変更されました。
SCOTT2@localhost:1521/freepdb1> alter session set max_dump_file_size = unlimited;

セッションが変更されました。
SCOTT2@localhost:1521/freepdb1> alter system flush shared_pool;

システムが変更されました。
SCOTT2@localhost:1521/freepdb1> alter session set events '10046 trace name context forever,level 12';

セッションが変更されました。
SCOTT2@localhost:1521/freepdb1> @multi_row_insert_bind_1000 100000 1000

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       201 CPU used by this session                                                 20
       201 CPU used when call started                                               18
       201 SQL*Net roundtrips to/from client                                        11
...略...
       201 execute count                                                          2661
...略...
       201 session pga memory                                                  7024288
       201 session pga memory max                                              9121440
       201 session uga memory                                                  3769944
       201 session uga memory max                                              5045168
...略...

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

経過: 00:00:28.67

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       201 CPU used by this session                                               1653
       201 CPU used when call started                                             1653
       201 SQL*Net roundtrips to/from client                                        16
       201 SQL*Net roundtrips to/from dblink                                    202411
...略...
       201 execute count                                                        103112
...略...
       201 session pga memory                                                 14167712
       201 session pga memory max                                             27799200
       201 session uga memory                                                 11361872
       201 session uga memory max                                             12865392
...略...
       201 user commits                                                            100
...略...

  COUNT(1)
----------
    100000
...略...

SCOTT2@localhost:1521/freepdb1> alter session set events '10046 trace name context off';
...略...

出力された10046トレースファイルのサイズ。リモートのほうが圧倒的に大きいですね。

[oracle@arm64-oraclelinux8u10 trace]$ ll FREE_ora_*_10046_mrows_*.trc
-rw-r-----. 1 oracle oinstall  62680689 Feb  3 22:16 FREE_ora_4704_10046_mrows_local.trc
-rw-r-----. 1 oracle oinstall 136508011 Feb  3 22:19 FREE_ora_4724_10046_mrows_remote.trc

比較しつつ覗いてみると。
ローカル表への Multi Row Insert では、投げたままのSQL文がみつかります。これは想定通りですよね。

...略...

SQL ID: 7vkx7q1gbfwr3 Plan Hash: 1

INSERT INTO mrows_ins_tab
VALUES
(:c11, null, null, null, null, null, null, null, :c81), (:c12, null, null,
  null, null, null, null, null, :c82), (:c13, null, null, null, null, null,
  null, null, :c83), (:c14, null, null, null, null, null, null, null, :c84),
  (:c15, null, null, null, null, null, null, null, :c85), (:c16, null, null,
  null, null, null, null, null, :c86), (:c17, null, null, null, null, null,
  null, null, :c87), (:c18, null, null, null, null, null, null, null, :c88),
  (:c19, null, null, null, null, null, null, null, :c89), (:c110, null, null,
  null, null, null, null, null, :c810), (:c111, null, null, null, null, null,

...略...

  null, null, null, null, :c8994), (:c1995, null, null, null, null, null,
  null, null, :c8995), (:c1996, null, null, null, null, null, null, null,
  :c8996), (:c1997, null, null, null, null, null, null, null, :c8997),
  (:c1998, null, null, null, null, null, null, null, :c8998), (:c1999, null,
  null, null, null, null, null, null, :c8999), (:c11000, null, null, null,
  null, null, null, null, :c81000);

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.13       0.13          0          0          0           0
Execute    100      1.81       1.84          7       7031      61178      100000
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      101      1.95       1.98          7       7031      61178      100000

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 134     (recursive depth: 1)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
         0          0          0  LOAD TABLE CONVENTIONAL  MROWS_INS_TAB (cr=519 pr=8 pw=0 time=7342 us starts=1 direct read=0 direct write=0)
      1000       1000       1000   VALUES SCAN  (cr=0 pr=0 pw=0 time=633 us starts=1 direct read=0 direct write=0 cost=2000 size=0 card=1000)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  Allocate PGA memory from OS                     2        0.00          0.00
  Allocate CGA memory from OS                    62        0.00          0.00
  Disk file operations I/O                        2        0.00          0.00
  db file sequential read                         7        0.00          0.00
  log file switch (private strand flush incomplete)
                                                  2        0.00          0.01

一方、リモート表に対して同一Multi Row Insert文を実行した場合の10046トレースでは。。。
やたらと、SYS.DUALへのSELECT文が出現しており、それにより10046トレースファイルサイズが大きくなっていました。
見えて来ましたよね。なんとなく。。。。

SQL ID: 7vkx7q1gbfwr3 Plan Hash: 0

INSERT INTO mrows_ins_tab
VALUES
(:c11, null, null, null, null, null, null, null, :c81), (:c12, null, null,
  null, null, null, null, null, :c82), (:c13, null, null, null, null, null,
  null, null, :c83), (:c14, null, null, null, null, null, null, null, :c84),
  (:c15, null, null, null, null, null, null, null, :c85), (:c16, null, null,
  null, null, null, null, null, :c86), (:c17, null, null, null, null, null,
  null, null, :c87), (:c18, null, null, null, null, null, null, null, :c88),
  (:c19, null, null, null, null, null, null, null, :c89), (:c110, null, null,

...略...

  null, null, null, null, :c8994), (:c1995, null, null, null, null, null,
  null, null, :c8995), (:c1996, null, null, null, null, null, null, null,
  :c8996), (:c1997, null, null, null, null, null, null, null, :c8997),
  (:c1998, null, null, null, null, null, null, null, :c8998), (:c1999, null,
  null, null, null, null, null, null, :c8999), (:c11000, null, null, null,
  null, null, null, null, :c81000);


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.13       0.14          0          0          0           0
Execute    100     14.90      26.22          0         18        100      100000
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      101     15.04      26.36          0         18        100      100000

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 136     (recursive depth: 1)

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  Allocate PGA memory from OS                     2        0.00          0.00
  single-task message                             1        0.36          0.36
  SQL*Net message from dblink                202312        0.17         18.65
  SQL*Net message to dblink                  202311        0.00          0.12
  SQL*Net more data to dblink                  5800        0.00          0.02
********************************************************************************

...略...

SELECT /*+ FULL(P) +*/ *
FROM
 "SYS"."DUAL" P


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse     1002      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     1002      0.00       0.00          0          0          0           0

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 136     (recursive depth: 2)
********************************************************************************

...略...

SQL ID: 40x1xzzgzd101 Plan Hash: 1388734953

SELECT 0
FROM
 "SYS"."DUAL" "A1002"


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse      100      0.00       0.00          0          0          0           0
Execute    100      0.00       0.00          0          0          0           0
Fetch      200      0.00       0.00          0          0          0         100
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      400      0.00       0.00          0          0          0         100

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 136     (recursive depth: 2)
Number of plan statistics captured: 100

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
         1          1          1  FAST DUAL  (cr=0 pr=0 pw=0 time=0 us starts=1 direct read=0 direct write=0 cost=2 size=0 card=1)
...略...

SYS.DUALへのアクセスが目立つ、かつ、SYS.DUALへの表エイリアスが皆異なるようなので、SYS.DUALだけで何行あるかカウントしてみました。
おおおおおおおおおおーーーー！！！！！！　これって！！

リモート表へMulti Row Insertを実行した場合のSYS.DUALへのアクセスを含む単純なSELECT文の数！！　は、 1,002件！！！！

[oracle@arm64-oraclelinux8u10 trace]$ cat FREE_ora_4724_10046_mrows_remote_aggregate.txt | grep "SELECT 0" | wc -l
1002

[oracle@arm64-oraclelinux8u10 trace]$ cat FREE_ora_4704_10046_mrows_local_aggregate.txt | grep "SELECT 0" | wc -l
0

23aiからサポートされた、Multi Row Insert 構文って、内部で TRANSFORM されちゃってないですかね？？？

10053トレースを取得すれば確実に見えるはず。。。。。。
10046トレースと同様の方法で。。

ローカル表で。

SCOTT2@localhost:1521/freepdb1> alter session set tracefile_identifier='10053_mrows_local';

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

...略...

SCOTT@localhost:1521/freepdb1> alter session set events '10053 trace name context forever, level 1';

セッションが変更されました。
SCOTT@localhost:1521/freepdb1> @multi_row_insert_bind_1000 100000 1000

...略...

リモート表で。

SCOTT2@localhost:1521/freepdb1> alter session set tracefile_identifier='10053_mrows_remote';

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

...略...

SCOTT2@localhost:1521/freepdb1> alter session set events '10053 trace name context forever, level 1';

セッションが変更されました。
SCOTT2@localhost:1521/freepdb1> @multi_row_insert_bind_1000 100000 1000

...略...

10053トレースログを見てみると。。。
はっけーーーーーーーーーーーーーーーーーん！！

23ai以降でサポートされたMulti Row Insert文は、ローカル表でもリモート表でも同様にTRANSFORMされていました！！！！！

INSERT INTO 表[(列...)] VALUES 
    (列...)
  , (列...)
  , ....;

は、内部的に以下のように、行毎に SYS.DUALをアクセスするSELECT文に分解された後、UNION ALL で縦方向に結合されたインラインビューに！！

INSERT INTO 表[(列...)] 
SELECT 列... FROM 
( 
  SELECT 列... FROM SYS.DUAL 
  UNION ALL 
  SELECT 列... FROM SYS.DUAL
  UNION ALL 
  ....
)

のように書き換えられて実行される。

これはリモート表でもローカル表でも書き換えられています。

では、なにが大きな負荷なっているのか。。
それは、23ai以降、記述が必須ではなくなった、そう、DUAL 表！！！！！

以下のように書き換えられた、Multi row insert 文において、mrows_ins_tab がローカル表である場合は、同一インスタンスのオブジェクトだけを参照するので問題はありません。
高速です！（この形に書き換えられてたのは今知ったのですがw）

INSERT INTO mrows_ins_tab
SELECT 列... FROM 
( 
  SELECT 列... FROM SYS.DUAL 
  UNION ALL 
  SELECT 列... FROM SYS.DUAL
  UNION ALL 
  ....
)

ところが、mrows_ins_tab が DB Link 経由のリモート表である場合、ローカル表扱いの SYS.DUAL が重荷になってきます！！！！
俺書いてないけど！ DUAL。

想定では、execution countは、Multi Row Insert文が実行された回数を想定していましたが、Insert対象の表がリモート表である場合は、SYS.DUALはローカル扱いのままなので、
リモートDML（すべてのオブジェクトがDBリンクの先のDBとして扱われる）ではなく、分散DMLとなり、ローカルのSYS.DUALが、合計で 100,000回アクセスされ、それに加えて、リモート表へのINSERT文が、Multi Row Insert文の実行回数分加わる！！

今一度、冒頭の表（前回のエントリの表再掲）を見つつ確認してみましょう！！！

リモート表へのexecute count謎の増加理由
1）10 rows / INSERT 　10 rows / INSERT毎に10,000回実行して 100,000行インサートする場合、リモート表だと、
　10 rows * 10,000回 + 10,000回 = 110,000回 + recursive call分なのどオーバーヘッド
　（想定していた、execute countは、 10,000 + recursive call overhead程度）

2) 100 rows / INSERT 　100 rows / INSERT毎に1,000回実行して 100,000行インサートする場合、リモート表だと、
　100 rows * 1,000回 + 1,000回 = 101,000回 + recursive call分なのどオーバーヘッド
　（想定していた、execute countは、 1,000 + recursive call overhead程度）

3) 1,000 rows / INSERT 　1,000 rows / INSERT毎に100回実行して 100,000行インサートする場合、リモート表だと、
　1,000 rows * 100回 + 100回 = 100,100回 + recursive call分なのどオーバーヘッド
　（想定していた、execute countは、 100 + recursive call overhead程度）

リモート表へのMulti Row Insertのexecute countの実測値と合っていますよね！！ その結果、ソフトパースも同様に上昇、パース時間も増加、おそらく、SQL*Net roundtrips to/from dblinkもその影響で増加しているはずです。

やっと、謎が解けた。。。。。

ということで、PL/SQLで、Bulk Loadするなら、FORALL構文なのですが、FORALL構文はそもそもリモート表には行えません！
Multi Row Insert が使えるかなーと思いましたが、PL/SQLではローカル表としてアクセスする場合以外は、避けた方がよいですね。いまのところ。

どうしてもPL/SQLでリモート表へバルクロードしなければいけないという辛い状況では、ぐるぐる系でSingle Row Insertしつつ、Commitの間隔を100, 1000などのように調整する泥臭い方式しかないのではないでしょうか。。
なお、リモートへパススルーできないかなーと、ヒントを試しましたが効果はありませんでした。残念

ということで、PL/SQLで無理やり、ネットワークラウンドトリップの影響を含めてみるのは諦めましたw
より一般的に、APサーバーとDBサーバー間のネットワークラウンドドリップの影響も含むMulti row Insert vs Single row insert + commit interval方式で、
ぐーるぐーる vs ぐるぐる　で比較しつつ、このシリーズをまとめることにしましょう！
なお、Javaのコード書くのめんどくさくなったので、Geminiくんに書いてもらって多少追加して。。。本題へ戻る。。。

To be Continued....

おまけの10053トレース抜粋 ローカル表でもリモート表でも以下のようにトランスフォームされる。1,000 rows / INSERTの場合。

[oracle@arm64-oraclelinux8u10 trace]$ view FREE_ora_5503_10053_mrows_remote.txt

Query after VW_MRG2:
 qb SEL$1 (#0):******* UNPARSED QUERY IS *******
SELECT :B1,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B2 FROM "SYS"."DUAL" "DUAL"

...略...

Query after VW_MRG2:
 qb SEL$1000 (#0):******* UNPARSED QUERY IS *******
SELECT :B1,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B2 FROM "SYS"."DUAL" "DUAL"
Query after VW_MRG2:
 qb SET$1 (#0):******* UNPARSED QUERY IS *******
 (SELECT :B1 ":1",NULL "NULL",NULL "NULL",NULL "NULL",NULL "NULL",NULL "NULL",NULL "NULL",NULL "NULL",:B2 ":1" FROM "SYS"."DUAL" "DUAL") UNION ALL  
 (SELECT :B3,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B4 FROM "SYS"."DUAL" "DUAL") UNION ALL  (SELECT :B5,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B6 FROM "SYS"."DUAL" "DUAL") UNION ALL 
 (SELECT :B7,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B8 FROM "SYS"."DUAL" "DUAL") UNION ALL  (SELECT :B9,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B10 FROM "SYS"."DUAL" "DUAL") UNION ALL
 (SELECT :B11,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B12 FROM "SYS"."DUAL" "DUAL") UNION ALL  (SELECT :B13,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B14 FROM "SYS"."DUAL" "DUAL") UNION ALL
 (SELECT :B15,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B16 FROM "SYS"."DUAL" "DUAL") UNION ALL  (SELECT :B17,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B18 FROM "SYS"."DUAL" "DUAL") UNION ALL
 (SELECT :B19,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B20 FROM "SYS"."DUAL" "DUAL") UNION ALL  (SELECT :B21,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B22 FROM "SYS"."DUAL" "DUAL") UNION ALL
 (SELECT :B23,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B24 FROM "SYS"."DUAL" "DUAL") UNION ALL  (SELECT :B25,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B26 FROM "SYS"."DUAL" "DUAL") UNION ALL
 (SELECT :B27,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B28 FROM "SYS"."DUAL" "DUAL") UNION ALL  (SELECT :B29,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B30 FROM "SYS"."DUAL" "DUAL") UNION ALL
 (SELECT :B31,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B32 FROM "SYS"."DUAL" "DUAL") UNION ALL  (SELECT :B33,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B34 FROM "SYS"."DUAL" "DUAL") UNION ALL
 (SELECT :B35,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B36 FROM "SYS"."DUAL" "DUAL") UNION ALL  (SELECT :B37,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B38 FROM "SYS"."DUAL" "DUAL") UNION ALL
  (SELECT :B39,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B40 FROM "SYS"."DUAL" "DUAL") UNION ALL  (SELECT :B41,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B42 FROM "SYS"."DUAL" "DUAL") UNION ALL

  ...略...

(SELECT :B1991,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B1992 FROM "SYS"."DUAL" "DUAL") UNION ALL  (SELECT :B1993,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B1994 FROM "SYS"."DUAL" "DUAL") UNION ALL
(SELECT :B1995,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B1996 FROM "SYS"."DUAL" "DUAL") UNION ALL  (SELECT :B1997,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B1998 FROM "SYS"."DUAL" "DUAL") UNION ALL
(SELECT :B1999,NULL,NULL,NULL,NULL,NULL,NULL,NULL,:B2000 FROM "SYS"."DUAL" "DUAL")

投稿日時 2026年2月 4日 (水) 21時34分 PL/SQL, FAQ, SQL, ダウンロード, VirtualBox, パフォーマンス, Apple Silicon ARM64, Oracle Database 23ai | 固定リンク | 0 | コメント (0)

2026年2月 3日 (火)

Oracle Database - Multi Row INSERT、バインド変数を使うとリテラル値を使う場合では見える景色が変わるんだよね #3 - ローカル表とリモート表での挙動の差異？！

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をつかっちゃったからからもしれないですけども。。。。。。。。

以下、ローカル表とリモート表でバインド変数を利用したMulti row Insertを10行、100行、1,000行ごとで実行し、合計で　100,000行登録したログです。
なお、今回利用したスクリプトは前回のエントリの後半に載せたものと同じです。
また、DB Linkでリモート表としてアクセスできるようにした内容は前々回のエントリーを参照ください。

ローカル表で、Multi table Insert を 10行、100行、1000行単位で、100,000行登録（バイント変数利用）

SCOTT@localhost:1521/freepdb1> @multi_row_insert_bind_10 100000 10

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
...略...
        46 CPU used by this session                                                  9
        46 CPU used when call started                                                8
        46 SQL*Net roundtrips to/from client                                         9
...略...
        46 execute count                                                          1326
...略...
        46 parse count (hard)                                                      140
        46 parse count (total)                                                     319
        46 parse time cpu                                                            8
        46 parse time elapsed                                                       11
...略...
        46 session pga memory                                                  4385784
        46 session pga memory max                                              6762144
        46 session uga memory                                                  2035760
        46 session uga memory max                                              4893336
...略...

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

経過: 00:00:00.88

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
...略...
        46 CPU used by this session                                                 95
        46 CPU used when call started                                               95
        46 SQL*Net roundtrips to/from client                                        16
...略...
        46 execute count                                                         11479
...略...
        46 parse count (hard)                                                      149
        46 parse count (total)                                                     353
        46 parse time cpu                                                            8
        46 parse time elapsed                                                       12
...略...
        46 session pga memory                                                  3533816
        46 session pga memory max                                              6762144
        46 session uga memory                                                  2101240
        46 session uga memory max                                              4893336
...略...
        46 user commits                                                          10000
...略...

  COUNT(1)
----------
    100000

SEGMENT_NAME                           MB
------------------------------ ----------
MROWS_INS_TAB                          45

表が切り捨てられました。

SCOTT@localhost:1521/freepdb1> @multi_row_insert_bind_100 100000 100

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
...略...
        46 CPU used by this session                                                  4
        46 CPU used when call started                                                3
        46 SQL*Net roundtrips to/from client                                         6
...略...
        46 execute count                                                           815
...略...
        46 parse count (hard)                                                      100
        46 parse count (total)                                                     226
        46 parse time cpu                                                            3
        46 parse time elapsed                                                        4
...略...
        46 session pga memory                                                  4123640
        46 session pga memory max                                              6762144
        46 session uga memory                                                  1904800
        46 session uga memory max                                              4893304
...略...

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

経過: 00:00:00.66

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
...略...
        46 CPU used by this session                                                 70
        46 CPU used when call started                                               70
        46 SQL*Net roundtrips to/from client                                        10
...略...
        46 execute count                                                          2119
...略...
        46 parse count (hard)                                                      123
        46 parse count (total)                                                     286
        46 parse time cpu                                                            6
        46 parse time elapsed                                                        7
...略...
        46 session pga memory                                                  3402744
        46 session pga memory max                                             12119032
        46 session uga memory                                                  2101240
        46 session uga memory max                                              4893304
...略...
        46 user commits                                                           1000
...略...

  COUNT(1)
----------
    100000

...略...

SCOTT@localhost:1521/freepdb1> @multi_row_insert_bind_1000 100000 1000

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        46 CPU used by this session                                                  3
        46 CPU used when call started                                                2
        46 SQL*Net roundtrips to/from client                                         6
...略...
        46 execute count                                                           464
...略...
        46 parse count (hard)                                                       46
        46 parse count (total)                                                     193
        46 parse time cpu                                                            3
        46 parse time elapsed                                                        1
...略...
        46 session pga memory                                                  3878560
        46 session pga memory max                                              3878560
        46 session uga memory                                                  1527152
        46 session uga memory max                                              2279696
...略...

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

経過: 00:00:01.28

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        46 CPU used by this session                                                129
        46 CPU used when call started                                              129
        46 SQL*Net roundtrips to/from client                                        10
...略...
        46 execute count                                                           872
...略...
        46 parse count (hard)                                                       69
        46 parse count (total)                                                     254
        46 parse time cpu                                                           46
        46 parse time elapsed                                                       43
...略...
        46 session pga memory                                                  4337312
        46 session pga memory max                                             49229472
        46 session uga memory                                                  2997304
        46 session uga memory max                                              3259328
...略...
        46 user commits                                                            100

  COUNT(1)
----------
    100000

...略...

リモート表(via DB Link)で、Multi table Insert を 10行、100行、1000行単位で、100,000行登録（バイント変数利用）
リモート表は、Oracle Database - Multi Row INSERT、バインド変数を使うと、リテラル値を使う場合では見える景色が変わるんだよね #1 - バグなのか現時点の仕様なのか?で作成した環境をそのまま利用しています。

SCOTT2@localhost:1521/freepdb1> @multi_row_insert_bind_10 100000 10

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       179 CPU used by this session                                                  4
       179 CPU used when call started                                                3
       179 SQL*Net roundtrips to/from client                                         9
...略...
       179 execute count                                                           603
...略...
       179 parse count (hard)                                                       55
       179 parse count (total)                                                     221
       179 parse time cpu                                                            2
       179 parse time elapsed                                                        4
...略...
       179 session pga memory                                                  3927032
       179 session pga memory max                                              3927032
       179 session uga memory                                                  1637320
       179 session uga memory max                                              2345032
...略...

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

経過: 00:00:22.88

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       179 CPU used by this session                                                896
       179 CPU used when call started                                              896
       179 SQL*Net roundtrips to/from client                                        16
       179 SQL*Net roundtrips to/from dblink                                    240031
...略...
       179 execute count                                                        110719
...略...
       179 parse count (hard)                                                       91
       179 parse count (total)                                                  100268
       179 parse time cpu                                                            7
       179 parse time elapsed                                                       21
...略...
       179 session pga memory                                                  4320248
       179 session pga memory max                                              4582392
       179 session uga memory                                                  2277856
       179 session uga memory max                                              2858632
...略...
       179 user commits                                                          10000
...略...

  COUNT(1)
----------
    100000

...略...

SCOTT2@localhost:1521/freepdb1> @multi_row_insert_bind_100 100000 100

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
...略...
       179 CPU used by this session                                                  5
       179 CPU used when call started                                                5
       179 SQL*Net roundtrips to/from client                                         6
...略...
       179 execute count                                                           831
...略...
       179 parse count (hard)                                                      107
       179 parse count (total)                                                     229
       179 parse time cpu                                                            4
       179 parse time elapsed                                                        4
...略...
       179 session pga memory                                                  4123640
       179 session pga memory max                                              5648032
       179 session uga memory                                                  1904800
       179 session uga memory max                                              3779144
...略...

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

経過: 00:00:18.01

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
...略...
       179 CPU used by this session                                                817
       179 CPU used when call started                                              817
       179 SQL*Net roundtrips to/from client                                        10
       179 SQL*Net roundtrips to/from dblink                                    204211
...略...
       179 execute count                                                        102095
...略...
       179 parse count (hard)                                                      234
       179 parse count (total)                                                  101389
       179 parse time cpu                                                           26
       179 parse time elapsed                                                       47
...略...
       179 session pga memory                                                  4582392
       179 session pga memory max                                              6548472
       179 session uga memory                                                  3142472
       179 session uga memory max                                              3779144
...略...
       179 user commits                                                           1000
...略...

  COUNT(1)
----------
    100000

...略...

リモート表へ、1000rows/INSERTを実行したら。。。。

SCOTT2@localhost:1521/freepdb1> @multi_row_insert_bind_1000 100000 1000

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
...略...
       179 CPU used by this session                                                  5
       179 CPU used when call started                                                4
       179 SQL*Net roundtrips to/from client                                         6
...略...
       179 execute count                                                           558
...略...
       179 parse count (hard)                                                       73
       179 parse count (total)                                                     212
       179 parse time cpu                                                            5
       179 parse time elapsed                                                        5
...略...


DECLARE
*
行1でエラーが発生しました。:
ORA-01000: セッションの最大オープン・カーソル数がPotential Leaked SQL_ID: を超えました ORA-02063:
先行のエラー・メッセージを参照してくださいline(FREEPDB1)。 ORA-02063:
先行のエラー・メッセージを参照してください2 lines(LINK2SCOTT)。 ORA-06512: 行59
ヘルプ: https://docs.oracle.com/error-help/db/ora-01000/

                                                 *
行1でエラーが発生しました。:
RA-01000: セッションの最大オープン・カーソル数がを超えました ヘルプ:
https://docs.oracle.com/error-help/db/ora-01000/

ん？　妙ですねぇー。OPEN_CURSORS=300（デフォルト）を超えちゃったようです。。。仕方ないので、一時的に大きめに。
なんかきになるなー。ローカル表だとそんなこと起きないのに。。。ちょうど＋1,000したら回避できたというのも、なんとなく気になる値ではあるし。。。。

SYSTEM@localhost:1521/freepdb1> alter system set open_cursors = 1300 scope=memory;

システムが変更されました。

SCOTT2@localhost:1521/freepdb1> @multi_row_insert_bind_1000 100000 1000

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        16 CPU used by this session                                                  5
        16 CPU used when call started                                                5
        16 SQL*Net roundtrips to/from client                                         6
...略...
        16 execute count                                                           805
...略...
        16 parse count (hard)                                                      107
        16 parse count (total)                                                     229
        16 parse time cpu                                                            4
        16 parse time elapsed                                                        4
...略...
        16 session pga memory                                                  4058104
        16 session pga memory max                                              5123744
        16 session uga memory                                                  1899488
        16 session uga memory max                                              3053984
...略...

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

経過: 00:00:24.14

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        16 CPU used by this session                                               1213
        16 CPU used when call started                                             1213
        16 SQL*Net roundtrips to/from client                                        10
        16 SQL*Net roundtrips to/from dblink                                    202411
...略...
        16 execute count                                                        100996
...略...
        16 parse count (hard)                                                     1121
        16 parse count (total)                                                  101346
        16 parse time cpu                                                           85
        16 parse time elapsed                                                      135
...略...
        16 session pga memory                                                 12119032
        16 session pga memory max                                             25619448
        16 session uga memory                                                 10382272
        16 session uga memory max                                             12082240
...略...
        16 user commits                                                            100
...略...

  COUNT(1)
----------
    100000

...略...

ということで、新たな謎を追って、Matrix...いや、Oracleの奥地へ....wwww

To be continued....

投稿日時 2026年2月 3日 (火) 19時25分 Oracle, PL/SQL, チューニング, FAQ, SQL, VirtualBox, パフォーマンス, Apple Silicon ARM64, Oracle Database 23ai | 固定リンク | 0 | コメント (0)

2026年1月27日 (火)

Oracle Database - Multi Row INSERT、バインド変数を使うと、リテラル値を使う場合では見える景色が変わるんだよね #1 - バグなのか現時点の仕様なのか?

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を利用してバインド変数化することぐらいしかできなそう！）
まじで？！　という状況なので、細かい確認は次のリリース以降で再度試してみようかなと。

不具合？なのか現時点の仕様なのか、制限っぽいエラーについてのログは以下。
運良く見つけた、現状、唯一の逃げ道も最後に記載しています。
（PL/SQLだと以前から他の方法(Bulk Insert)もあるので困ることはないとは思いますが。。。）

前回作成した表を利用します。(SCOTTスキーマに作成)

create table meows_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)
);

前提 PL/SQLを利用しリテラル値のままのMulti row insert、バインド変数を利用したMulti row insertが対象です。（PL/SQLで利用する場合だけで発生していると思われるエラー。それ以外の言語ではどうかは未確認）

以下のような構文で、バインド変数を使ういたかったわけです。PL/SQLなので直接！

INSERT INTO mrows_ins_tab(id, col8) VALUES (...), (...) ...;

と書きたいところでしたが、
これが。。。。いろいろと引き当ててしまう原因になるとは。。。知る由もなかった。。。。
いろいろあります。。。よ！　(^^ ;;;;;

バグ？ or 現時点の仕様、または制限？　その1

後で気づいたのですが、このエラーには2つの要素が絡んでいるようでした。
ひとつは、INSERTする表の列指定。もう一つは、バインド変数として利用しているVARRAY (可変サイズの配列)の二つ。（詳細は後続のエラーにて）
SQL文が無効ですというエラーに惑わされますが、エラー自体はORA-00600です。

SCOTT@localhost:1521/freepdb1> !cat bug1.sql
DECLARE
  c11 NUMBER;
  c12 NUMBER;
  c81 VARCHAR2(500);
  c82 VARCHAR2(500);
  TYPE c1_type IS VARRAY(2) OF NUMBER;
  TYPE c8_type IS VARRAY(2) OF VARCHAR2(500);
  c1 c1_type := c1_type();
  c8 c8_type := c8_type();
BEGIN
    c1.extend(2);
    c8.extend(2);
    c1(1) := 1;
    c1(2) := 2;
    c8(1) := LPAD(TO_CHAR(c1(1)),373,'x');
    c8(2) := LPAD(TO_CHAR(c1(2)),373,'x');
    INSERT INTO mrows_ins_tab(id,col8) VALUES
      (c1(1), c8(1))
      , (c1(2), c8(2))
    ;
END;
/

SCOTT@localhost:1521/freepdb1> @bug1
  c82 VARCHAR2(500);
               *
行5でエラーが発生しました。:
ORA-00900: SQL文が無効です。
ORA-00600: 内部エラー・コード, 引数: [qcsTVCApplyqbc:nameres], [], [], [], [], [], [], [], [], [], [], [] ヘルプ:
https://docs.oracle.com/error-help/db/ora-00900/

.trcファイルにも同様のログあり

Incident 222887 created, dump file: /opt/oracle/diag/rdbms/free/FREE/incident/incdir_222887/FREE_ora_4633_i222887.trc
ORA-00600: 内部エラー・コード, 引数: [qcsTVCApplyqbc:nameres], [], [], [], [], [], [], [], [], [], [], []

上記無名PL/SQLブロックスクリプトを以下のように書き換えてみます。 違いはVARRAY配列を利用していないという1点です。
VARRAY配列の要素をmulti row insert文で直接使うことはできない（現状）ことがわかります！（まじかー！）
なお、このケースではINSERT文で表の列を指定しても指定しなくても影響はありません。（他のケースではこの表の列指定が影響する問題がありました。後述）

SCOTT@localhost:1521/freepdb1> !cat bug1_1.sql
DECLARE
  c11 NUMBER;
  c12 NUMBER;
  c81 VARCHAR2(500);
  c82 VARCHAR2(500);
BEGIN
    c11 := 1;
    c12 := 2;
    c81 := LPAD(TO_CHAR(c11),373,'x');
    c82 := LPAD(TO_CHAR(c12),373,'x');
    INSERT INTO mrows_ins_tab(id,col8) VALUES
      (c11, c81)
      , (c12, c82)
    ;
END;
/

SCOTT@localhost:1521/freepdb1> @bug1_1

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

さらに書き換えてみます。このテストケースでは、VARRAY配列の要素を使うことが原因でエラーになっているようです。

SCOTT@localhost:1521/freepdb1> !cat bug1_2.sql
DECLARE
  c11 NUMBER;
  c12 NUMBER;
  c81 VARCHAR2(500);
  c82 VARCHAR2(500);
BEGIN
    c11 := 1;
    c12 := 2;
    c81 := LPAD(TO_CHAR(c11),373,'x');
    c82 := LPAD(TO_CHAR(c12),373,'x');
    INSERT INTO mrows_ins_tab(id, col1, col2, col3, col4, col5, col6, col7, col8) VALUES
      (c11, null, null, null, null, null, null, null, c81)
      , (c12, null, null, null, null, null, null, null, c82)
    ;
END;
/

SCOTT@localhost:1521/freepdb1> @bug1_2

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

さらに書き換えて、表の列指定を行わない構文（このような構文はほとんどの現場では使えないと思いますが、。。。）でも正常に実行できています。ポイントは、VARRAY配列の要素を直接渡せない（現状）って部分だけです（ここまでのテストケースでは）。
なお、ここまでは表の所有者であるSCOTTユーザで接続して検証を行いました。
次のテストケースでは、SCOTT2ユーザで接続し、DB Link経由でSCOTTの表へMulti row insertするテストを行ってみます。。。そこでも色々おきます！

SCOTT@localhost:1521/freepdb1> !cat bug1_3.sql
DECLARE
  c11 NUMBER;
  c12 NUMBER;
  c81 VARCHAR2(500);
  c82 VARCHAR2(500);
BEGIN
    c11 := 1;
    c12 := 2;
    c81 := LPAD(TO_CHAR(c11),373,'x');
    c82 := LPAD(TO_CHAR(c12),373,'x');
    INSERT INTO mrows_ins_tab VALUES
      (c11, null, null, null, null, null, null, null, c81)
      , (c12, null, null, null, null, null, null, null, c82)
    ;
END;
/

SCOTT@localhost:1521/freepdb1> @bug1_3

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

バグ？ or 現時点の仕様、または制限？　その2 PL/SQLではローカルのデータベースへアクセスことになるため、通常はSQL*Netを経由するNetwork Round Tripは発生しません。
ただ、一般的なアプリケーションではアプリケーションサーバーとデータベースサーバー間では、SQL*Net経由でNetwork Round Tripが発生するほうが普通です。
そのような状況を想定してDB Linkを経由させることで、意図的にSQL*Net経由でNetwork Round Tripを発生させるテストケースも試したいなーと、準備していた時に気づいた、とうかハマったバグ？、または現時点の仕様、制限です。

まず、scott.emp表を単一インスタンではありますが、無理やりscott2ユーザーからdb link経由でリモート表としてMulti row insertする準備から。

権限は雑に許可しちゃってます（特にシステム権限あたり）
準備

SYSTEM@localhost:1521/freepdb1> create user scott2 identified by [password] default tablespace users temporary tablespace temp quota unlimited on users;

ユーザーが作成されました。
SYSTEM@localhost:1521/freepdb1> grant select any dictionary to scott2;

権限付与が成功しました。
SYSTEM@localhost:1521/freepdb1> grant drop any table to scott2;

権限付与が成功しました。
SYSTEM@localhost:1521/freepdb1> grant connect , resource , create database link to scott2;

権限付与が成功しました。

SCOTT@localhost:1521/freepdb1> grant select on scott.mrows_ins_tab to scott2;

権限付与が成功しました。
SCOTT@localhost:1521/freepdb1> grant insert on mrows_ins_tab to scott2;

権限付与が成功しました。
SCOTT@localhost:1521/freepdb1> grant delete on mrows_ins_tab to scott2;

権限付与が成功しました。
SCOTT@localhost:1521/freepdb1> grant update on mrows_ins_tab to scott2;

権限付与が成功しました。

[oracle@arm64-oraclelinux8u10 ~]$ sqlplus scott2@localhost:1521/freepdb1

SCOTT2@localhost:1521/freepdb1> create database link link2scott connect to scott identified by [password] using 'localhost:1521/freepdb1';          

データベース・リンクが作成されました。
COTT2@localhost:1521/freepdb1> select * from mrows_ins_tab@link2scott;

レコードが選択されませんでした。
SCOTT2@localhost:1521/freepdb1> create synonym mrows_ins_tab for mrows_ins_tab@link2scott;

シノニムが作成されました。
SCOTT2@localhost:1521/freepdb1> select * from mrows_ins_tab;

レコードが選択されませんでした。
SCOTT2@localhost:1521/freepdb1> select table_name from user_tables;

レコードが選択されませんでした。
SCOTT2@localhost:1521/freepdb1> truncate table scott.mrows_ins_tab;

表が切り捨てられました。

scott2に接続して、その1と同じことを試してみます。（scott.mrows_ins_tabをDB Link経由でアクセスしている点が異なります）
以下は、ローカル表アクセスと同じ結果なので想定通りの結果です。

SCOTT2@localhost:1521/freepdb1> !cat bug1.sql
DECLARE
  c11 NUMBER;
  c12 NUMBER;
  c81 VARCHAR2(500);
  c82 VARCHAR2(500);
  cTYPE c1_type IS VARRAY(2) OF NUMBER;
  cTYPE c8_type IS VARRAY(2) OF VARCHAR2(500);
  cc1 c1_type := c1_type();
  cc8 c8_type := c8_type();
BEGIN
    c1.extend(2);
    c8.extend(2);
    c1(1) := 1;
    c1(2) := 2;
    c8(1) := LPAD(TO_CHAR(c1(1)),373,'x');
    c8(2) := LPAD(TO_CHAR(c1(2)),373,'x');
    INSERT INTO mrows_ins_tab(id,col8) VALUES
      (c1(1), c8(1))
      , (c1(2), c8(2))
    ;
END;
/


SCOTT2@localhost:1521/freepdb1> @bug1
  c82 VARCHAR2(500);
               *
行5でエラーが発生しました。:
ORA-00900: SQL文が無効です。
ORA-00600: 内部エラー・コード, 引数: [qcsTVCApplyqbc:nameres], [], [], [], [], [], [], [], [], [], [], [] ヘルプ:
https://docs.oracle.com/error-help/db/ora-00900/

問題はローカル表へのMulti row insertでは正常に実行できた残りの3ケース。 以下のケース。ローカル表では正常に実行されましたが、VARRAY配列を利用した場合と異なる点は、ORA-07445 になっているということです。SIGSEGVなので、これはバグの類です。

SCOTT2@localhost:1521/freepdb1> !cat bug1_1.sql
DECLARE
  c11 NUMBER;
  c12 NUMBER;
  c81 VARCHAR2(500);
  c82 VARCHAR2(500);
BEGIN
    c11 := 1;
    c12 := 2;
    c81 := LPAD(TO_CHAR(c11),373,'x');
    c82 := LPAD(TO_CHAR(c12),373,'x');
    INSERT INTO mrows_ins_tab(id,col8) VALUES
      (c11, c81)
      , (c12, c82)
    ;
END;
/

SCOTT2@localhost:1521/freepdb1> @bug1_1
  c82 VARCHAR2(500);
               *
行5でエラーが発生しました。:
OORA-03113: 通信チャネルでend-of-fileが検出されました プロセスID:
5150
セッションID: 17、シリアル番号: 17264 ヘルプ:
https://docs.oracle.com/error-help/db/ora-03113/

.trcファイルから本当の原因を確認してみると。。。。 ORA-07445！

Incident 222926 created, dump file: /opt/oracle/diag/rdbms/free/FREE/incident/incdir_222926/FREE_ora_5225_i222926.trc
OORA-07445: 例外が検出されました: コア・ダンプ [qcsorcqb()+784] [SIGSEGV] [ADDR:0x0] [PC:0xF0F3084] [Address not mapped to object] []

次のケースでは、また別の原因でエラーに？ この文もローカル表では正常に実行できていましたよね？（前述）

SCOTT2@localhost:1521/freepdb1> !cat bug1_2.sql
DECLARE
  c11 NUMBER;
  c12 NUMBER;
  c81 VARCHAR2(500);
  c82 VARCHAR2(500);
BEGIN
    c11 := 1;
    c12 := 2;
    c81 := LPAD(TO_CHAR(c11),373,'x');
    c82 := LPAD(TO_CHAR(c12),373,'x');
    INSERT INTO mrows_ins_tab(id, col1, col2, col3, col4, col5, col6, col7, col8) VALUES
      (c11, null, null, null, null, null, null, null, c81)
      , (c12, null, null, null, null, null, null, null, c82)
    ;
END;
/


SCOTT2@localhost:1521/freepdb1> @bug1_2
    INSERT INTO mrows_ins_tab(id, col1, col2, col3, col4, col5, col6, col7, col8) VALUES
                                                                            *
行11でエラーが発生しました。:
ORA-06550: 行11、列77:
PL/SQL: ORA-00904: "COL8": 無効な識別子です。
ORA-06550: 行11、列5:
PL/SQL: SQL Statement ignored
ヘルプ: https://docs.oracle.com/error-help/db/ora-06550/

.trcファイルから本当の原因を探ると。。でてました。また別のログが！！！！　
これって、現時点では実装されてない？　ってこと？　だとすると現時点の仕様という制限だろうか。。

 fsd_notify_cb: FsDirect not implemented

さて、最後に、留め！　（違 以下のケースもローカル表へ実行した場合は正常に実行できていました（前述）
これ、おそらく、実装されてない感じですかね。
PL/SQLのエンジンがOracle Databaseのカーネルに組み込まれていなかったOracle 7の頃とか、この類の新規構文の実装時期がズレるって珍しくなかったのですが、久々にこのような状況を見てノスタルジーを感じる、セピア色www

これどうやって回避できんのかなぁ！？

SCOTT2@localhost:1521/freepdb1> !cat bug1_3.sql
DECLARE
  c11 NUMBER;
  c12 NUMBER;
  c81 VARCHAR2(500);
  c82 VARCHAR2(500);
BEGIN
    c11 := 1;
    c12 := 2;
    c81 := LPAD(TO_CHAR(c11),373,'x');
    c82 := LPAD(TO_CHAR(c12),373,'x');
    INSERT INTO mrows_ins_tab VALUES
      (c11, null, null, null, null, null, null, null, c81)
      , (c12, null, null, null, null, null, null, null, c82)
    ;
END;
/

SCOTT2@localhost:1521/freepdb1> @bug1_3
DECLARE
*
行1でエラーが発生しました。:
ORA-00900: SQL文が無効です。
ORA-00600: 内部エラー・コード, 引数: [qctcopn_internal: null_colkcc], [0], [0], [0], [0], [0], [1], [0], [], [], [], [] ヘルプ:
https://docs.oracle.com/error-help/db/ora-00900/

.trcファイルでも同じ

Incident 222671 created, dump file: /opt/oracle/diag/rdbms/free/FREE/incident/incdir_222671/FREE_ora_5572_i222671.trc
ORA-00600: 内部エラー・コード, 引数: [qctcopn_internal: null_colkcc], [0], [0], [0], [0], [0], [1], [0], [], [], [], []

さて、ほんとうに試した事とから随分と遠くにきてしまった感じがしますが、、逃げ道を見つけましたw

対策をしばし考え中。。。。現状回避できる方法はあるのでは？。。。。わずかな期待。。。

PL/SQLには、他の方法として、 EXECUTE IMMEDIATEを使う方法はあるか。。。その分のオーバーヘッドは乗ってしまうわけだが。。。。

試してみる！ (全テストケース　NGとなったDB Link経由のケースで確認する。このケースで実行できればローカルでも動作するはずだ。。。。と)

EXECUTE IMMEDIATEでバイント変数を利用するためにUSING句を使ってみました。ためにし、VARRAY配列を使っています。また、表も列指定しています。ここでローカル表でのテストでも発生した
fsd_notify_cb: FsDirect not implementedがトレースファイルに記録されていました。！！！　VARRAYはEXECUTE IMMEDIATEでMulti row insertする場合でもダメなのか？？。

SCOTT2@localhost:1521/freepdb1> !cat bug1_4.sql
DECLARE
  sql_text CLOB := EMPTY_CLOB();
  TYPE c1_type IS VARRAY(2) OF NUMBER;
  TYPE c8_type IS VARRAY(2) OF VARCHAR2(500);
  c1 c1_type := c1_type();
  c8 c8_type := c8_type();
BEGIN
    c1.extend(2);
    c8.extend(2);
    c1(1) := 1;
    c1(2) := 2;
    c8(1) := LPAD(TO_CHAR(c1(1)),373,'x');
    c8(2) := LPAD(TO_CHAR(c1(2)),373,'x');
    sql_text := 'INSERT INTO mrows_ins_tab(id, col8) VALUES'
      || '(:c11, :c81)'
      || ', (:c12, :c82);';
    EXECUTE IMMEDIATE sql_text
      USING c1(1), c8(1), c1(2), c8(2);
END;
/

SCOTT2@localhost:1521/freepdb1> @bug1_4
DECLARE
*
行1でエラーが発生しました。:
ORA-00904: "COL8": 無効な識別子です。
ORA-06512: 行17
ヘルプ: https://docs.oracle.com/error-help/db/ora-00904/

.trcファイル

fsd_notify_cb: FsDirect not implemented

まずは、切り分けのために、VARRAY配列の使用をやめてみます。表の列指定だけは残してありますが、これでも同じエラーが発生します！！

SCOTT2@localhost:1521/freepdb1> !cat bug1_5.sql
DECLARE
  sql_text CLOB := EMPTY_CLOB();
  c11 NUMBER;
  c12 NUMBER;
  c81 VARCHAR2(500);
  c82 VARCHAR2(500);
BEGIN
    c11 := 1;
    c12 := 2;
    c81 := LPAD(TO_CHAR(c11),373,'x');
    c82 := LPAD(TO_CHAR(c12),373,'x');
    sql_text := 'INSERT INTO mrows_ins_tab(id, col8) VALUES'
      || '(:c11, :c81)'
      || ', (:c12, :c82);';
    EXECUTE IMMEDIATE sql_text
      USING c11, c81, c12, c82;
END;
/

SCOTT2@localhost:1521/freepdb1> @bug1_5
DECLARE
*
行1でエラーが発生しました。:
ORA-00904: "COL8": 無効な識別子です。
ORA-06512: 行15
ヘルプ: https://docs.oracle.com/error-help/db/ora-00904/

.trcファイル

fsd_notify_cb: FsDirect not implemented

気を取り直してw
USING句ではVARRAY配列を利用し、表の列指定だけを行わないようにしてみます。

おおおおおおお、やっと逃げ道発見！ w 変数は配列でもOKなので、取り合えず、行数増やしてもプログラミングで捌ける:)

SCOTT2@localhost:1521/freepdb1> !cat bug1_6.sql
DECLARE
  sql_text CLOB := EMPTY_CLOB();
  TYPE c1_type IS VARRAY(2) OF NUMBER;
  TYPE c8_type IS VARRAY(2) OF VARCHAR2(500);
  c1 c1_type := c1_type();
  c8 c8_type := c8_type();
BEGIN
    c1.extend(2);
    c8.extend(2);
    c1(1) := 1;
    c1(2) := 2;
    c8(1) := LPAD(TO_CHAR(c1(1)),373,'x');
    c8(2) := LPAD(TO_CHAR(c1(2)),373,'x');
    sql_text := 'INSERT INTO mrows_ins_tab VALUES'
      || '(:c11, null, null, null, null, null, null, null, :c81)'
      || ', (:c12, null, null, null, null, null, null, null, :c82);';
    EXECUTE IMMEDIATE sql_text
      USING c1(1), c8(1), c1(2), c8(2);
END;
/

SCOTT2@localhost:1521/freepdb1> @bug1_6

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

この方法でもいける！　
ただ、配列使えるなら配列のほうが便利なので、一つ前の方式に決定　EXECUTE IMMEDIATEだと全部リテラルというケースも試せるからEXECUTE IMMEDIATEでのるある程度のオーバーヘッドは見えて良いのかも。
ただ、EXECUTE IMMEDIATEを利用しない場合のポテンシャルは確認できないのが、ちょっと残念。

SCOTT2@localhost:1521/freepdb1> !cat bug1_7.sql
DECLARE
  c11 NUMBER;
  c12 NUMBER;
  c81 VARCHAR2(500);
  c82 VARCHAR2(500);
  sql_text CLOB := EMPTY_CLOB();
BEGIN
    c11 := 1;
    c12 := 2;
    c81 := LPAD(TO_CHAR(c11),373,'x');
    c82 := LPAD(TO_CHAR(c12),373,'x');
    sql_text := 'INSERT INTO mrows_ins_tab VALUES'
      || '(:c11, null, null, null, null, null, null, null, :c81)'
      || ', (:c12, null, null, null, null, null, null, null, :c82);';
    EXECUTE IMMEDIATE sql_text
      USING c11, c81, c12, c82;
END;
/

SCOTT2@localhost:1521/freepdb1> @bug1_7

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

いや、まじで、Multi row insert構文をPL/SQLで使おうとすると結構な壁というか問題残ってそうですね。
とはいえ、PL/SQLでやるなら FORALLのバルクインサートもあるわけで、困ることはないだろうなとも思われ（現状）
とはいえ、PL/SQLでやるならローカル表の場合なら、FORALLでバルクインサートでもよいのだろうけども、
リモート表だとFORALLは使えないのでまあ、DB Link使ってる環境では注意した方が良いよね。ローカルからにする方法にするとか。

そもそもエラーで挙動周りの差異を見切れてないのは心残りではあるけども、次回りリースのai新版以降のお楽しみということで.... :)

ほんとうに試したかったのとはちょっとちがうが、Multi row insert文、リテラル値じゃなくてバインド変数を使えば、メモリ消費は抑えられるよっていう、ネタ含めた次の話題は書けそうな気がしてきた。

以下の方式(EXECUTE IMMEDIATEを利用する方法を代替策にして)でバインド変数化とリテラル値を利用したMulti row insertのメモリ消費を見るネタへ続く。（予定w）

DECLARE
  sql_text CLOB := EMPTY_CLOB();
  TYPE c1_type IS VARRAY(2) OF NUMBER;
  TYPE c8_type IS VARRAY(2) OF VARCHAR2(500);
  c1 c1_type := c1_type();
  c8 c8_type := c8_type();
BEGIN
    c1.extend(2);
    c8.extend(2);
    c1(1) := 1;
    c1(2) := 2;
    c8(1) := LPAD(TO_CHAR(c1(1)),373,'x');
    c8(2) := LPAD(TO_CHAR(c1(2)),373,'x');
    sql_text := 'INSERT INTO mrows_ins_tab VALUES'
      || '(:c11, null, null, null, null, null, null, null, :c81)'
      || ', (:c12, null, null, null, null, null, null, null, :c82);';
    EXECUTE IMMEDIATE sql_text
      USING c1(1), c8(1), c1(2), c8(2);
END;
/

いや、まじでいろいろハマり過ぎだろ、ってぐらいハマったw

ではまた。

投稿日時 2026年1月27日 (火) 19時00分チューニング, FAQ, SQL, VirtualBox, パフォーマンス, Apple Silicon ARM64, Oracle Database 23ai | 固定リンク | 0 | コメント (0)

2026年1月 8日 (木)

帰ってきた！標準はあるにはあるが癖の多いSQL #22 - Multi Row INSERT

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

...略...

行数を3倍の15,000行に。こんなことする方はいないと思いますけども。。。予想以上にPGAを消費しますね。

SCOTT@localhost:1521/freepdb1> @show_mystats.sql

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       205 CPU used by this session                                                  5
       205 CPU used when call started                                                4

...略...

       205 session pga memory                                                  4123640
       205 session pga memory max                                              5123744
       205 session uga memory                                                  1839072
       205 session uga memory max                                              3053904

...略...

SCOTT@localhost:1521/freepdb1> @sql_mrows_ins_15000

15000行が作成されました。

経過: 00:01:45.96
SCOTT@localhost:1521/freepdb1> @show_mystats.sql

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       205 CPU used by this session                                               9762
       205 CPU used when call started                                             9762

...略...

       205 session pga memory                                                257551352
       205 session pga memory max                                           1402072056
       205 session uga memory                                                248118456
       205 session uga memory max                                            252312704

...略...

前述のINSERT ALLで　5,000行、15,000行の一括インサートでのPGA/UGAの最大サイズは以下の通りでした。
session pga memory max

318.7 MB / 5,000rows
1,332.23MB / 15,000rows

session uga memory max

78.2 MB / 5,000rows
237.71MB / 15,000rows

今回の環境とINSERT ALLの行数、行サイズでは 20,000行で、PGA_AGGREGATE_LIMITを超える結果となりました。
23ai FREEなので使えるメモリサイズが元々少ないので比較的簡単に制限を超過しちゃいますね

SCOTT@localhost:1521/freepdb1> @show_mystats.sql

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       203 CPU used by this session                                                  5
       203 CPU used when call started                                                4

...略...

       203 session pga memory                                                  4254712
       203 session pga memory max                                              5123744
       203 session uga memory                                                  1844408
       203 session uga memory max                                              3053904

...略...

SCOTT@localhost:1521/freepdb1> @sql_mrows_ins_20000
INTO mrows_ins_tab(id, col8) VALUES(1,
     *
行2でエラーが発生しました。:
ORA-04036: インスタンスまたはPDBにより使用されるPGAメモリーがPGA_AGGREGATE_LIMITを超えています。 ヘルプ:
https://docs.oracle.com/error-help/db/ora-04036/

上記で利用したINSERT文を生成したスクリプトです。参考まで。

set feed off
set timi off
set head off
set termout off
set veri off
set trimspool on

col col1 for a20
col col2 for a20
col col3 for a20
col col4 for a20
col col5 for a20
col col6 for a20
col col7 for a20
col col8 for a20
set linesize 400
set pagesize 1000
SET SERVEROUTPUT ON
spool sql_mrows_ins_&1..sql
DECLARE
  c_max_rows CONSTANT NUMBER := &1;
BEGIN
  DBMS_OUTPUT.PUT_LINE('INSERT ALL ');
  FOR i IN 1..c_max_rows LOOP
    DBMS_OUTPUT.PUT_LINE(
      'INTO mrows_ins_tab(id, col8) VALUES('
      || TO_CHAR(i)
      || ', ''' || LPAD(TO_CHAR(i),373,'x') || ''')'
    );
  END LOOP;
  DBMS_OUTPUT.PUT_LINE('SELECT * FROM dual;');
END;
/
spool off
SET SERVEROUTPUT OFF
UNDEFINE 1

set head on
set termout on
set feed on
set veri on
set timi on
set trimspool off

ここまでは、Oracle Databaseのmulti table insert(Oracle Databaseの方言)をつかった multi row insertでしたが、
次はPostgreSQLでも実行できるmulti row insert構文で同様の検証を行ってみます！

multi row insertを利用した場合のPGA消費量確認

見ての通り、Multi table insert文より、PGAの消費は緩やかではあるものの、それなりの消費量ですね。

これらの結果から、適当な行数（行サイズにもよるが）、10行〜多くても1000行程度ぐらいの範囲で一括INSERTするのが
性能とメモリ消費ではバランスが良さそうな感じに思えますね。
物理メモリが大量にあってPGAにそれなりに割り振れるとしても、ハードパース時間はかなり伸びですしそれを回避するのは難しいので。

こんな感じのmulti row insert文を生成(PostgreSQLも同じ文を利用できます)。なお、行数は適宜調整。

[oracle@arm64-oraclelinux8u10 ~]$ cat sql_mrows_ins_65535.sql
INSERT INTO mrows_ins_tab(id, col8) VALUES
(1, 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1')

...略...

, (65535, 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx65535')
;

まずは、5,000行から。
147MB程度のPGA消費なので、INSERT ALLにくらべると半分ぐらいの消費になってますね。

SCOTT@localhost:1521/freepdb1> @show_mystats.sql

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       203 CPU used by this session                                                  2
       203 CPU used when call started                                                1

...略...

       203 session pga memory                                                  3419808
       203 session pga memory max                                              3747488
       203 session uga memory                                                  1456416
       203 session uga memory max                                              1769824

...略...

SCOTT@localhost:1521/freepdb1> @sql_mrows_ins_5000

5000行が作成されました。

経過: 00:00:04.91
SCOTT@localhost:1521/freepdb1> @show_mystats.sql

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
       203 CPU used by this session                                                491
       203 CPU used when call started                                              491

...略...

       203 session pga memory                                                  3730424
       203 session pga memory max                                            147647480
       203 session uga memory                                                  2297424
       203 session uga memory max                                              4523744

...略...

同様に、3倍の15,000行。
INSERT ALL文と比べPGAの消費量は少なく、行数の割に緩やかに増加しているようですね。興味深い。
410MB程度のPGA消費。INSERT ALLで同様の行数を扱った検証では、1.3GB程度だったので50%以下に抑えられています。

23ai以降で、Multi row insertを行うなら、INSERT ALLは避けるべきですね。

SCOTT@localhost:1521/freepdb1> @show_mystats.sql

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        39 CPU used by this session                                                  5
        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_15000

15000行が作成されました。

経過: 00:01:03.97
SCOTT@localhost:1521/freepdb1> @show_mystats.sql

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        39 CPU used by this session                                               6381
        39 CPU used when call started                                             6381

...略...

        39 session pga memory                                                 11660280
        39 session pga memory max                                            412019704
        39 session uga memory                                                  4589264
        39 session uga memory max                                             11204640

...略...

次のケース。
INSERT ALLでは、PGA_AGGREGATE_LIMITの制限サイズを超過してしまいましたが、PGA消費はおさえられ、本環境でも正常に処理されますね。ほう！
まだ、行けますね。
とはいえ、処理時間も随分長くなってます。これTVC同様ハードパース時間の影響が大きそうですよね。

SCOTT@localhost:1521/freepdb1> @show_mystats.sql

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        38 CPU used by this session                                                  5
        38 CPU used when call started                                                3

...略...

        38 session pga memory                                                  4254712
        38 session pga memory max                                              5123744
        38 session uga memory                                                  1844408
        38 session uga memory max                                              3053904

...略...

SCOTT@localhost:1521/freepdb1> @sql_mrows_ins_20000

20000行が作成されました。

経過: 00:02:18.09
SCOTT@localhost:1521/freepdb1>  @show_mystats.sql

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        38 CPU used by this session                                              13538
        38 CPU used when call started                                            13538

...略...

        38 session pga memory                                                  7007224
        38 session pga memory max                                            550956024
        38 session uga memory                                                  5571464
        38 session uga memory max                                             14349248

...略...

では、思い切って、50,000行にしてみましょう！　なんとなくギリギリな感じですが、正常終了！
1,359MBほど使っちゃってますね。
この傾向、Table Value Constructorの傾向に近いですよね。はやり。

SCOTT@localhost:1521/freepdb1> @show_mystats.sql

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        40 CPU used by this session                                                  5
        40 CPU used when call started                                                3

...略...

        40 session pga memory                                                  4254712
        40 session pga memory max                                              5123744
        40 session uga memory                                                  1844408
        40 session uga memory max                                              3053904

...略...

SCOTT@localhost:1521/freepdb1> @sql_mrows_ins_50000

50000行が作成されました。

経過: 00:29:08.74
SCOTT@localhost:1521/freepdb1>  @show_mystats.sql

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        40 CPU used by this session                                             173596
        40 CPU used when call started                                           173596

...略...

        40 session pga memory                                                 31714296
        40 session pga memory max                                           1359735800
        40 session uga memory                                                 11073624
        40 session uga memory max                                             33220312

...略...

Table Value Constractorの傾向に類似しているので、行数上限がありそうだと思い。試してみた！
想像通り！！！！！　エラーメッセージも同じです！！

SCOTT@localhost:1521/freepdb1> @show_mystats.sql

       SID NAME                                                                  VALUE
---------- ---------------------------------------------------------------- ----------
        38 CPU used by this session                                                  5
        38 CPU used when call started                                                4

...略...

        38 session pga memory                                                  4254712
        38 session pga memory max                                              5123744
        38 session uga memory                                                  1844408
        38 session uga memory max                                              3053904

...略...

SCOTT@localhost:1521/freepdb1> @sql_mrows_ins_65535
INSERT INTO mrows_ins_tab(id, col8) VALUES
*
行1でエラーが発生しました。:
ORA-63805: 表値コンストラクタのタプルの最大数を超えました ヘルプ:
https://docs.oracle.com/error-help/db/ora-63805/


経過: 00:00:01.07

上記で利用したINSERT文を生成したスクリプトです。参考まで。
Oracle Database 23ai以降で利用できるMulti row insert文を生成するスクリプトは以下のとおり。

set feed off
set timi off
set head off
set termout off
set veri off
set trimspool on

col col1 for a20
col col2 for a20
col col3 for a20
col col4 for a20
col col5 for a20
col col6 for a20
col col7 for a20
col col8 for a20
set linesize 400
set pagesize 1000
SET SERVEROUTPUT ON
spool sql_mrows_ins_&1..sql
DECLARE
  c_max_rows CONSTANT NUMBER := &1;
BEGIN
  DBMS_OUTPUT.PUT_LINE('INSERT INTO mrows_ins_tab(id, col8) VALUES');
  FOR i IN 1..c_max_rows LOOP
    DBMS_OUTPUT.PUT_LINE(
      CASE WHEN i > 1 
    THEN ', '
      END
      || '('
      || TO_CHAR(i)
      || ', ''' || LPAD(TO_CHAR(i),373,'x') || ''')'
    );
  END LOOP;
  DBMS_OUTPUT.PUT_LINE(';');
END;
/
spool off
SET SERVEROUTPUT OFF
UNDEFINE 1

set head on
set termout on
set feed on
set veri on
set timi on
set trimspool off

では、同様の方法で、PostgreSQL/MySQLのざっくりとしたメモリ消費などを確認しておきましょう。

次は、PostgreSQL

PostgreSQL、メモリ構造がOracle Databaseとは違うといっても、65535行登録で、302MB程度。随分違う。
とはいっても行数が多くなれば消費量は増えると思われ、Oracle Database同様、詰めすぎず、性能とメモリ消費のバランスが取れる単位にまとめるってのは、同じだろうと思います。

Password for user scott: 
psql (17.7)
Type "help" for help.

...略...

perftestdb=> \d+ mrows_ins_tab
                                               Table "scott.mrows_ins_tab"
 Column |          Type           | Collation | Nullable | Default | Storage  | Compression | Stats target | Description 
--------+-------------------------+-----------+----------+---------+----------+-------------+--------------+-------------
 id     | integer                 |           | not null |         | plain    |             |              | 
 col1   | character varying(1000) |           |          |         | extended |             |              | 
 col2   | character varying(1000) |           |          |         | extended |             |              | 
 col3   | character varying(1000) |           |          |         | extended |             |              | 
 col4   | character varying(1000) |           |          |         | extended |             |              | 
 col5   | character varying(1000) |           |          |         | extended |             |              | 
 col6   | character varying(1000) |           |          |         | extended |             |              | 
 col7   | character varying(1000) |           |          |         | extended |             |              | 
 col8   | character varying(500)  |           |          |         | extended |             |              | 
Indexes:
    "mrows_ins_tab_pkey" PRIMARY KEY, btree (id)
Access method: heap



2026-01-07 20:45:03.765 JST [14222] LOG:  PARSER STATISTICS
2026-01-07 20:45:03.765 JST [14222] DETAIL:  ! system usage stats:
        !       0.063931 s user, 0.000000 s system, 0.069344 s elapsed
        !       [0.063931 s user, 0.008076 s system total]
        !       114684 kB max resident size
        !       0/0 [0/0] filesystem blocks in/out
        !       0/4816 [12/5839] page faults/reclaims, 0 [0] swaps
        !       0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
        !       0/0 [6/0] voluntary/involuntary context switches
2026-01-07 20:45:03.765 JST [14222] STATEMENT:  INSERT INTO mrows_ins_tab(id, col8) VALUES
        (1, 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1')
        , (2, 
        
        ...略...
        
        , (65535, 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx65535')
        ;
2026-01-07 20:45:03.853 JST [14222] LOG:  PARSE ANALYSIS STATISTICS
2026-01-07 20:45:03.853 JST [14222] DETAIL:  ! system usage stats:
        !       0.017787 s user, 0.000000 s system, 0.019316 s elapsed
        !       [0.144499 s user, 0.008076 s system total]
        !       166148 kB max resident size
        !       0/0 [0/0] filesystem blocks in/out
        !       44/3185 [56/11332] page faults/reclaims, 0 [0] swaps
        !       0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
        !       0/0 [120/0] voluntary/involuntary context switches
2026-01-07 20:45:03.853 JST [14222] STATEMENT:  INSERT INTO mrows_ins_tab(id, col8) VALUES
        
        ...略...

2026-01-07 20:45:03.922 JST [14222] LOG:  REWRITER STATISTICS
2026-01-07 20:45:03.922 JST [14222] DETAIL:  ! system usage stats:
        !       0.001438 s user, 0.000081 s system, 0.001645 s elapsed
        !       [0.203669 s user, 0.011451 s system total]
        !       209480 kB max resident size
        !       0/0 [0/0] filesystem blocks in/out
        !       0/1 [56/13938] page faults/reclaims, 0 [0] swaps
        !       0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
        !       0/0 [234/1] voluntary/involuntary context switches
2026-01-07 20:45:03.922 JST [14222] STATEMENT:  INSERT INTO mrows_ins_tab(id, col8) VALUES
        
        ...略...

2026-01-07 20:45:04.183 JST [14222] LOG:  PLANNER STATISTICS
2026-01-07 20:45:04.183 JST [14222] DETAIL:  ! system usage stats:
        !       0.176192 s user, 0.003606 s system, 0.195045 s elapsed
        !       [0.436538 s user, 0.018692 s system total]
        !       235792 kB max resident size
        !       0/0 [0/0] filesystem blocks in/out
        !       2/3555 [58/17991] page faults/reclaims, 0 [0] swaps
        !       0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
        !       0/1 [338/2] voluntary/involuntary context switches
2026-01-07 20:45:04.183 JST [14222] STATEMENT:  INSERT INTO mrows_ins_tab(id, col8) VALUES

        ...略...
        
2026-01-07 20:45:04.346 JST [14222] LOG:  XECUTOR STATISTICS
2026-01-07 20:45:04.346 JST [14222] DETAIL:  ! system usage stats:
        !       0.050664 s user, 0.022169 s system, 0.093750 s elapsed
        !       [0.542249 s user, 0.048167 s system total]
        !       302548 kB max resident size
        !       0/91376 [0/91376] filesystem blocks in/out
        !       7272/5528 [7330/25997] page faults/reclaims, 0 [0] swaps
        !       0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
        !       17/2 [474/4] voluntary/involuntary context switches
2026-01-07 20:45:04.346 JST [14222] STATEMENT:  INSERT INTO mrows_ins_tab(id, col8) VALUES
        
        ...略...

最後に、MySQL

MySQLでは列値コンストラクタが必要なこと以外、Oracle Database/PostgreSQLと同じです。

[oracle@arm64-oraclelinux8u10 ~]$ cat sql_mrows_ins_65535_mysql.sql
INSERT INTO mrows_ins_tab(id, col8) VALUES
ROW(1, 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1')

...略...

, ROW(65535, 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx65535')
;

MySQLもPostgreSQL同様、Oracle Databaseのような行数上限は無いですが、メモリ消費はそれなりにありますね。
やはり注意しておきたい部分ではありますね。無邪気に詰め込みすぎないのがリーズナブルだと思います。
65535行で、263MBぐらい。

[master@Oracle-Linux-8u10-arm64-2 ~]$ mysql -u scott -D perftestdb -p -h localhost 
Enter password: 
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.4.7 MySQL Community Server - GPL

...略...

mysql> desc mrows_ins_tab;
+-------+---------------+------+-----+---------+-------+
| Field | Type          | Null | Key | Default | Extra |
+-------+---------------+------+-----+---------+-------+
| id    | int           | NO   | PRI | NULL    |       |
| col1  | varchar(1000) | YES  |     | NULL    |       |
| col2  | varchar(1000) | YES  |     | NULL    |       |
| col3  | varchar(1000) | YES  |     | NULL    |       |
| col4  | varchar(1000) | YES  |     | NULL    |       |
| col5  | varchar(1000) | YES  |     | NULL    |       |
| col6  | varchar(1000) | YES  |     | NULL    |       |
| col7  | varchar(1000) | YES  |     | NULL    |       |
| col8  | varchar(500)  | YES  |     | NULL    |       |
+-------+---------------+------+-----+---------+-------+
9 rows in set (0.00 sec)

mysql> SELECT * from performance_schema.users WHERE USER='scott';
+-------+---------------------+-------------------+-------------------------------+--------------------------+
| USER  | CURRENT_CONNECTIONS | TOTAL_CONNECTIONS | MAX_SESSION_CONTROLLED_MEMORY | MAX_SESSION_TOTAL_MEMORY |
+-------+---------------------+-------------------+-------------------------------+--------------------------+
| scott |                   1 |                 1 |                       1465424 |                  2914540 |
+-------+---------------------+-------------------+-------------------------------+--------------------------+
1 row in set (0.00 sec)

mysql> SELECT MAX_TOTAL_MEMORY from performance_schema.events_statements_history WHERE SQL_TEXT LIKE 'INSERT INTO mrows_ins_tab(id, col8) VALUES%';
Empty set (0.00 sec)

mysql> \. sql_mrows_ins_65535_mysql.sql
Query OK, 65535 rows affected (0.59 sec)
Records: 65535  Duplicates: 0  Warnings: 0

mysql> SELECT MAX_TOTAL_MEMORY from performance_schema.events_statements_history WHERE SQL_TEXT LIKE 'INSERT INTO mrows_ins_tab(id, col8) VALUES%';
+------------------+
| MAX_TOTAL_MEMORY |
+------------------+
|        263061721 |
+------------------+
1 row in set (0.00 sec)

mysql> SELECT * from performance_schema.users WHERE USER='scott';
+-------+---------------------+-------------------+-------------------------------+--------------------------+
| USER  | CURRENT_CONNECTIONS | TOTAL_CONNECTIONS | MAX_SESSION_CONTROLLED_MEMORY | MAX_SESSION_TOTAL_MEMORY |
+-------+---------------------+-------------------+-------------------------------+--------------------------+
| scott |                   1 |                 1 |                     235981664 |                263061721 |
+-------+---------------------+-------------------+-------------------------------+--------------------------+
1 row in set (0.00 sec)

では、また。

デスクワークだと日中動かないので、手の部分がやたら冷える。。。
軽くBeat Saberで体動かすと、一時的には温まるのだけどもw

冬らしい、寒さの、東京より。

投稿日時 2026年1月 8日 (木) 18時00分チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス, Apple Silicon ARM64, Oracle Database 23ai | 固定リンク | 0 | コメント (0)

2025年12月 3日 (水)

2025年11月にリリースした曲 / DTM / GarageBand

Apple Loopとチョップで頑張るDTM　
11月は次の2曲でした:)

∞ Loops / N + 1 Loops
粛々と仕事をやっつける時のw BGM用、無限ループさせるループw

Risky Loops / N + 1 Loops
Inspired by 坂本龍一 feat. Iggy Pop / Risky Extended Mixのドラム音w なのですが、まあ、こんなもんです。

では、また。

Enjoy DTM and GarageBand!

投稿日時 2025年12月 3日 (水) 19時43分音楽, GarageBand, DTM, AppleLoops, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2025年11月 2日 (日)

2025年10月にリリースした曲 / DTM / GarageBand

さて、
10月のGarageBandのDTMは以下のダブバージョンを含む3つ。

Mind Game Loops ver. 1.2 / N + 1 Loops
Siriの日本語音声2の女性の声を利用して、今際の国のアリスの「ゲームを開始します」、「ゲームオーバー」っぽい音声Loopを作るテストで試した音声をGarageBandのトラックに組み込んでみたのが10月最初にリリースしたループ！

Autumn Night Rain Loops / N + 1 Loops
昨年も作った秋っぽい何かシリーズでw 1つ。

Crisp Autumn Day Loops ver. 1.6 / N + 1 Loops
- Dub version of Autumn Night Rain Loops -
そして、Autumn Night Rain Loops / N + 1 Loopsのダブバージョン。テンポを落としてドラムトラックなど合わせて変更してみたり。

では、また。

Enjoy DTM and GarageBand!

投稿日時 2025年11月 2日 (日) 19時51分音楽, Mac, GarageBand, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2025年10月 2日 (木)

2025年9月にリリースした曲 / DTM / GarageBand

ということで、前月のDTM

Dub version含め勢い余ってw、4曲

Glass Kabuki Loops / N + 1 Loops - Dub version of Kabuki Loops -
Glass Heart on Netflix （ • 佐藤健 × 宮﨑優 - 伝説のどしゃ降りセッション🎹🥁 | グラスハート | Net... ）観てたら面白かったので、inspired by Glass Heartとうい感じのDTM を。

Even so, loops! : N + 1 Loops - Dub version of Kabuki Loops -

それでもみんな大好きぐるぐる系みたいな）。ネタから思いついただけのタイトルというか、
別の曲にしようと思いドラムトラック作ってベーストラック載せた勢いだけで作ったこれも、Dub Version.

A dream one day Loops / N + 1 Loops

なんか落ちる夢って見たことないですかね。そんな感じの。
Beat Saberのゲーム動画のサウンドトラックだけ置き換えるためにチョっチョッと作ってみたやつ。

Sequel to a dream one day Loops ver. 1.1 / N + 1 Loops

全曲の勢いで、夢の続きみたいな感じで。

週一で作ってないか。。。w

Enjoy DTM and GarageBand!

ではまた。

投稿日時 2025年10月 2日 (木) 20時06分音楽, Mac, GarageBand, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2025年9月 3日 (水)

2025年8月にリリースした曲 / DTM / GarageBand

Natsu No Kabuki Loops ver.1.3 - Dub version of Kabuki Loops - / N + 1 Loops
8月は、他のことで忙しくて、時間取れなかったこともありますがwNatsu No Kabuki Loops ver.1.2 -> Natsu No Kabuki Loops ver.1.3へのマイナーバージョンアップのみでした。

そろそろガレバン、メジャーアップデートとかしないのだろうかw

ではまた。

Enjoy DTM, GarageBand and Apple Loops!

投稿日時 2025年9月 3日 (水) 18時55分音楽, Mac, GarageBand, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2025年8月29日 (金)

x86 GuestOS on VirtualBox for Apple Silicon / ARM. Rebooted. :)

一年ぐらい前、ARM版 7.1 Betaがリリースされ、ARM版7.0のテストビルドで起動していたx86 GuestOS起動ができなくなった。。。という話のその後です。

7.0.9 for Apple Silicon / ARMで Intel版VirtualBoxから移行して、起動できた〜〜ニヤニヤしていた。。。
VirtualBox TestBuild 7.0.97r163779 (2024-07-04T18:53:02Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

のですが、

7.1にアップデートしたら。。。。起動しなくなっちゃったんですよ....
VirtualBox TestBuild 7.1.0_BETA1r164292 (2024-08-07T18:27:07Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

ずーーーーっと起動しなかったので、もうしばらく無理なのだろうかと、おもい、ARM64ネイティブなGuestOSで遊び始めたあと、
Oracle Database 23ai 23.8 (aarch64) on Oracle Linux 8u10 (aarch64) on VirtualBox 7.1 for Apple Silicon 始動 w

なにげに、とあるスレッドをだらだら読んでいると。。。。。なに！！！〜。もしかして、デフォで起動しない設定に戻されてしまったのか。。。
ということに気づいたわけです！　はいw
Discuss the VirtualBox 7.1.0_BETA1 release here
https://forums.virtualbox.org/viewtopic.php?p=549283#p549283

上記スレッドで対処方法がコメントされていたことに全く気づかず、7.1以降使えなくなったままだったのかと思い込んでいただけでした。気づくの遅いw

ということで、Apple Silicon な VittualBoxで x86アーキテクチャのGuestOSのOracle Database/MySQL/PostgreSQLで遊ぶ環境が復活しました。

VBoxManage setextradata global "VBoxInternal2/EnableX86OnArm" 1

を設定しないといけないらしい、これを設定すると、”Dev Preview”マークがGUIに現れると！

結果から先に言っておくと、以下のリリース、7.2でも、x86_64のOracle Databaseは、ORA-3113で起動せず。
MySQL/PostgreSQLは起動しました。ちょっと先祖帰りした感じではありますね。とはいえ、x86 GuestOSも起動できる環境が復活できたので、起動確認もrebootさせることにしましたw

oracle@Mac-Studio ~ % . ./print_env.sh 
 
*** mac info. ***
ProductName:		macOS
ProductVersion:		14.7.7
BuildVersion:		23H723
 
*** 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.0r170228

oracle@Mac-Studio ~ % VBoxManage getextradata global "VBoxInternal2/EnableX86OnArm"
No value set!
oracle@Mac-Studio ~ %VBoxManage setextradata global "VBoxInternal2/EnableX86OnArm" 1

MySQL/PostgreSQLをインストールしてあるx86 Guestが起動するか見てみます。おおおお、起動しましたね！！！！

oracle@Mac-Studio ~ % VBoxManage list -platform-arch=x86 vms | grep 'mysql8 postgrsql13'
"Oracle Linux 8 mysql8 postgrsql13" {a61fa92b-7849-459d-9bf4-ec075f5b983e}
oracle@Mac-Studio ~ % VBoxManage list runningvms
"Oracle Linux 8 mysql8 postgrsql13" {a61fa92b-7849-459d-9bf4-ec075f5b983e}

MySQLは無事に起動しているでしょうか。。。おお、大丈夫だ！

[master@localhost ~]$ sudo service mysqld status
Redirecting to /bin/systemctl status mysqld.service
● mysqld.service - MySQL 8.0 database server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2025-08-28 06:42:56 EDT; 16min ago
  Process: 1370 ExecStartPost=/usr/libexec/mysql-check-upgrade (code=exited, status=0/SUCCESS)
  Process: 1086 ExecStartPre=/usr/libexec/mysql-prepare-db-dir mysqld.service (code=exited, status=0/SUCCESS)
  Process: 1040 ExecStartPre=/usr/libexec/mysql-check-socket (code=exited, status=0/SUCCESS)
 Main PID: 1123 (mysqld)
   Status: "Server is operational"
    Tasks: 37 (limit: 22947)
   Memory: 450.0M
   CGroup: /system.slice/mysqld.service
           └─1123 /usr/libexec/mysqld --basedir=/usr

 8月 28 06:42:37 localhost.localdomain systemd[1]: Starting MySQL 8.0 database server...
 8月 28 06:42:56 localhost.localdomain systemd[1]: Started MySQL 8.0 database server.

続いて、PostgreSQLは？。。。。おお、こちらも起動してますね

[master@localhost ~]$ sudo service postgresql-16 status
Redirecting to /bin/systemctl status postgresql-16.service
● postgresql-16.service - PostgreSQL 16 database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql-16.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2025-08-28 06:43:01 EDT; 17min ago
     Docs: https://www.postgresql.org/docs/16/static/
  Process: 1411 ExecStartPre=/usr/pgsql-16/bin/postgresql-16-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
 Main PID: 1425 (postgres)
    Tasks: 7 (limit: 22947)
   Memory: 31.8M
   CGroup: /system.slice/postgresql-16.service
           ├─1425 /usr/pgsql-16/bin/postgres -D /var/lib/pgsql/16/data/
           ├─1454 postgres: logger 
           ├─1471 postgres: checkpointer 
           ├─1472 postgres: background writer 
           ├─1480 postgres: walwriter 
           ├─1481 postgres: autovacuum launcher 
           └─1482 postgres: logical replication launcher 

 8月 28 06:42:58 localhost.localdomain systemd[1]: Starting PostgreSQL 16 database server...
 8月 28 06:43:00 localhost.localdomain postgres[1425]: 2025-08-28 06:43:00.762 EDT [1425] LOG:  redirecting log output to logging collector process
 8月 28 06:43:00 localhost.localdomain postgres[1425]: 2025-08-28 06:43:00.762 EDT [1425] HINT:  Future log output will appear in directory "log".
 8月 28 06:43:01 localhost.localdomain systemd[1]: Started PostgreSQL 16 database server.

MySQLのバージョンは、以下の通り

[master@localhost ~]$ mysql -u scott -D perftestdb -p 
Enter password: 
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.0.36 Source distribution

Copyright (c) 2000, 2024, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+
1 row in set (0.01 sec)

PostgreSQLのバージョンは以下のとおり。クエリーもとりあえず大丈夫そう。

[postgres@localhost ~]$ psql -d perftestdb -U discus -p 5432 -W -h localhost
パスワード： 
psql (16.3)
"help"でヘルプを表示します。


perftestdb=> select version();
                                                 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
(1 行)

では最後に、Oracle DatabaseをインストールしてあるVMで。。。。。。ん〜〜〜惜しい、起動できず。。。。

[oracle@localhost ~]$ uname -rm
5.4.17-2102.201.3.el8uek.x86_64 x86_64
[oracle@localhost ~]$ 
[oracle@localhost ~]$ 
[oracle@localhost ~]$ lsnrctl start

LSNRCTL for Linux: Version 21.0.0.0.0 - Production on 28-8月 -2025 20:08:06

Copyright (c) 1991, 2021, Oracle.  All rights reserved.

/opt/oracle/product/21c/dbhome_1/bin/tnslsnrを起動しています。お待ちください...

TNSLSNR for Linux: Version 21.0.0.0.0 - Production
システム・パラメータ・ファイルは/opt/oracle/homes/OraDBHome21cEE/network/admin/listener.oraです。
ログ・メッセージを/opt/oracle/diag/tnslsnr/localhost/listener/alert/log.xmlに書き込みました。
リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521)))
リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))に接続中
リスナーのステータス
------------------------
別名                      LISTENER
バージョン                TNSLSNR for Linux: Version 21.0.0.0.0 - Production
開始日                    28-8月 -2025 20:08:08
稼働時間                  0 日 0 時間 0 分 0 秒
トレース・レベル          off
セキュリティ              ON: Local OS Authentication
SNMP                      OFF
パラメータ・ファイル      /opt/oracle/homes/OraDBHome21cEE/network/admin/listener.ora
ログ・ファイル            /opt/oracle/diag/tnslsnr/localhost/listener/alert/log.xml
リスニング・エンドポイントのサマリー...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
リスナーはサービスをサポートしていません。
コマンドは正常に終了しました。
[oracle@localhost ~]$ sqlplus / as sysdba

SQL*Plus: Release 21.0.0.0.0 - Production on 木 8月 28 20:08:18 2025
Version 21.3.0.0.0

Copyright (c) 1982, 2021, Oracle.  All rights reserved.

アイドル・インスタンスに接続しました。

SYS@ORCLCDB> startup
ORA-03113: 通信チャネルでend-of-fileが検出されました
SYS@ORCLCDB>

とういことで、また、楽しみが一つ戻ってきた:)

まだまだ、蒸し暑すぎる東京の地より。
では、また。

投稿日時 2025年8月29日 (金) 19時00分 Oracle, Linux, FAQ, VirtualBox, MySQL, PostgreSQL, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2025年8月 2日 (土)

2025年7月にリリースした曲 / DTM / GarageBand

Kakko Loops / N + 1 Loops
祭りのお囃子を聴いていたら浮かんだまでは良かったが、GarageBandのLoopに和楽器系のものがない！！！w

でBASS drumとSnareで大太鼓、小太鼓を、それ以外に鐘と横笛があるのだけど、東南アジア系パーカッションとフルートと
いい感じSpace Designer のエフェクトで空間に奥行きをだしつつw

Kabuki Loops / N + 1 Loops
Kakko Loopsで和風なにかw を作りたいと思いw
浮かんだのか歌舞伎のLoopをつかったEDM

同時に一風堂のRADIO COSMOSが浮かんだので、それっぽい何かにしたいと！

そしてこんなのが出来上がった:)

Natsu No Kabuki Loops ver.1.2 - Dub version of Kabuki Loops - / N + 1 Loops
悪ノリついでに、Kabuki Loops / N + 1 Loopsのドラムトラックを活かしつつも、Dub Versionにして、夏の歌舞伎風？な感じにした

では、また。

Enjoy DTM and GarageBand!

投稿日時 2025年8月 2日 (土) 06時39分音楽, GarageBand, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2025年7月 2日 (水)

2025年6月にリリースした曲 / DTM / GarageBand

今月のDTMもリズムセクションの再利用を多用したループが多くなってしまった気がしないでもないw

Skip Scan Loops / N + 1 Loops
先月のと同じでドラムトラックを再利用して適当に載せてみたやつ。タイトルはOracle Databaseっぽい実行計画のOperationからw

LWlock LockManager waits Loops / N + 1 Loops
これも同じくw タイトルだけは先に決めちゃってた。PostgreSQLっぽい待機イベントで何かメジャーなやつということでw

では、また。

Enjoy DTM and GarageBand!

投稿日時 2025年7月 2日 (水) 18時26分音楽, Mac, GarageBand, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2025年6月 2日 (月)

2025年5月にリリースした曲 / DTM / GarageBand

今月のDTMもリズムセクションの再利用を多用したループが多くなってしまった。もう一つ作りかけのがあるしがw

Infinite Loop / N + 1 Loops
なんとなくループを置いただけのやつ

Cherry Blossom Blizzard Loops v1.2 / N + 1 Loops
4月に公開したLoopのマイナーアップデート！

Funky Clouds Loops / N + 1 Loops - Dub version of Cherry Blossom Blizzard Loops
Cherry Blossom Blizzard Loops v1.2 のリズムセクション再利用。。。:)

Another Loops in Clouds v1.1 / N + 1 Loops
Cherry Blossom Blizzard Loops v1.2 のリズムセクション再利用。。。その2

ではまた。Enjoy DTM / GarageBand!

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

2025年5月 3日 (土)

2025年4月にリリースした曲 / DTM / GarageBand

2月からドタバタしていて、ようやく一段落しはじめた4月。いつものペースを取り戻しつつ。公開したLoopはw これら

Railroad Loops / N + 1 Loops

なんとなーく、なにかに似たフリー映像版にしてしまったがw

Nested Loops III / N + 1 Loops

たまに作る、おまとめ版。

Space Cowboy Loops / N + 1 Loops

どこかの国には、関税カウボーイがいるらしいけどw

ではまた。Enjoy DTM / GarageBand!

投稿日時 2025年5月 3日 (土) 18時30分音楽, Mac, GarageBand, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2025年4月 8日 (火)

2025年3月にリリースした曲

DTM / GarageBandネタの月初のルーティーンw

3月にリリースしたループはこれ。（諸々プライベートが落ち着いたので、もうすこし遊べそうなきがする）
ver. 2.1から一年ぶりのマイナーアップデートw

Snow Loops ver. 2.2 / N + 1 Loops

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

2025年3月 2日 (日)

2025年2月にリリースした曲

DTM / GarageBandネタの月初のルーティーンですw

2月にリリースしたループはこれ。

実は1月にリリースしまくったループをベースにしたDub Versionのひとつ。勢いで作ったw
ちょうど、イカ天にでいた面白かったバンド THE家元を思い出してSpotifyで聴いていた影響で、歌舞伎のいよ〜〜〜〜〜っ、ポン！　って音のフリー音源さがしてたらいいのを見つけてイントロとエンディングと中間で使ってみたw

Another Ride the Groove Loops Dance Version v1.1 / N + 1 Loops -Dub version of Ride the Groove Loops

2月は色々多忙すぎてこれだけでしたが、3月もほぼ同じなので1曲（実はα版は作ってるw）が限界かなと。

Enjoy DTM / GarageBand!

ではまた

投稿日時 2025年3月 2日 (日) 08時15分音楽, Mac, GarageBand, iMovie, DTM, AppleLoops, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2025年2月 2日 (日)

2025年1月にリリースした曲

Untapped 🔥💀🌲＊💧 Loops Ver. 1.3 / N + 1 Loops
パイプオルガンのLoopを見つけて合わせたらボスキャラ登場的なイメージが強くなりすぎたw

Untapped 🔥💀🌲＊💧Loops Dub Version Edit3 v1.8 / N + 1 Loops
Untapped 🔥💀🌲＊💧 Loops Ver. 1.3 / N + 1 Loopsのリズムセクションが良さげな感じになってたので、それを元にダブバージョン　その1

Ride the Groove Loops / N + 1 Loops - Dub version of Untapped 🔥💀🌲＊💧Loops
さらに、Untapped 🔥💀🌲＊💧Loops Dub Version Edit3 v1.8 / N + 1 Loopsを元にしたダブバージョンその2 w

Ride the Groove Loops Dance Version (Zoe Hooks Mixed I) / N + 1 Loops
Ride the Groove Loops / N + 1 Loops - Dub version of Untapped 🔥💀🌲＊💧Loopsを元にまたまた、Zoe Nevermore Hooksをミックス　その3

Ride the Groove Loops Dance Version (Zoe Hooks Mixed II) / N + 1 Loops
Ride the Groove Loops Dance Version (Zoe Hooks Mixed I) / N + 1 Loopsを元にさらに、アジャイルな感じでドラムトラックなどを変えたその4

Ride the Groove Loops Dance Version (Zoe Hooks Mixed III) / N + 1 Loops
Ride the Groove Loops Dance Version (Zoe Hooks Mixed II) / N + 1 Loopsを元にさらに、アジャイルな感じでIIのLayerトラックを削除してリズムトラックを目立たせたその5
最終的にこれが一番いいねが多くなったw

1月は正月休みもあり、アジャイルDTM感全開だったw

実は最初の曲も、以下のベーストラックを元にしていたりするw
Long Autumn Nights Loops / N + 1 Loops

ではまた。
Enjoy DTM and GarageBand

投稿日時 2025年2月 2日 (日) 09時53分音楽, GarageBand, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2025年1月 2日 (木)

2024年12月に公開した曲

先月は、Apple Loopとチョップだけで頑張るGarageBand DTMアドベントカレンダー全部俺で作ったこのループ

Neko Mimi Loops 2024 / N + 1 Loops
これは2023年に思いつきで作ったVer.1をメジャーアップデートしたやつ。

Nested Loops II / N + 1 Loops
アドベントカレンダー全部俺で疲れたのでもう一つは、2024年公開分のまとめたもの

ということで今年のDTMもガレバンとApple Loopとチョップだけ？で頑張る予定でございます m(_ _)m

投稿日時 2025年1月 2日 (木) 12時01分音楽, Mac, GarageBand, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年12月25日 (水)

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

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)

2024年12月24日 (火)

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

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)

2024年12月23日 (月)

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

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)

2024年12月22日 (日)

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

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)

2024年12月21日 (土)

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

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名称"にしてあるので参考にしていただければ。

After

After

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

Enjoy DTM, GarageBand and iMovie

では、また明日。

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

2024年12月11日 (水)

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

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

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)

2024年12月 5日 (木)

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

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)

2024年12月 4日 (水)

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

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)

2024年12月 3日 (火)

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)

2024年12月 2日 (月)

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

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)

2024年12月 1日 (日)

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

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)

2024年11月 1日 (金)

DTM / 10月に公開した曲

DTM/GarageBandにある既存のAppleLoopsだけでがんばって作る曲シリーズw

10月は想定してなかった別件のレビューやったり、色々とプライベートな諸用が立て込んでた割には、DTMらしいw トラック再利用というかDub Versionやそれに近いのが多く作れたのでなんと、週イチペースwww

ガレバンアドベントカレンダー全部俺とかやりそうな勢い、だけはあるw （やるとは言ってない）

ということで、　10月にリリースしたループはメジャーアップデート（実は直後にマイナーアップデートしたがw）を含む4ループ、（マイナーアップデートを含めると5ループだが）

Long Autumn Nights Loops / N + 1 Loops

ベース頑張ったいつもよりスローテンポにしたループ

GarageBand映像バージョン

Turquoise Loops Ver. 2.1 / N + 1 Loops

Turquoise Loops / N + 1 Loopsのメージャーバージョンアップをさらにマイナーバージョンアップした Ver. 2.1。夏っぽいイメージなので残暑厳しかった9月に公開したかったのだが、仕方あるまいw

GarageBand映像バージョン

Turquoise Wave Loops / N + 1 Loops - Dub Version of Turquoise Loops Ver. 2.1 -

このループは上記、Turquoise Loops Ver. 2.1 / N + 1 Loopsのダブバージョンで、リズムトラックはほぼ流用して夏っぽい感じは残したまま別ループにしたもの。（GarageBand映像バージョンを見てもらってもわかると思いますが）

GarageBand映像バージョン

Shuffle Dance Loops / N + 1 Loops

最後のループは雰囲気をガラリと変えて、シャッフルダンスに合うかなぁ。と思いつつこんな感じに仕上がったのわけですがw
このループのドラムトラックとベース部分、サックスのトラックなども、前述のTurquoise Loops Ver. 2.1 、Turquoise Wave Loops から流用（EQやPluginで少し加工してますが）、他のトラックも過去使ったものを少しタイミングをズラしただけで結構雰囲気変わります:)

今回初めてAdobe Stockの映像も使ってみた（ちょうど良いのがあったので）。

GarageBand映像バージョン

では、次回のループリリースで。

Enjoy DTM / GarageBand !

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

2024年10月 2日 (水)

DTM / 9月に公開した曲

DTM/GarageBandにある既存のAppleLoopsだけでがんばって作る曲シリーズw
9月はまたまたpeer reviewとかやってて（仕事じゃないけど、面白かったw）、他のことやってる余裕が少なかったこともあり、そういえばやろうと思ったまま放置してた勢い余って4分で作った曲を2分にして後半を思い切って切り捨ててwドラムとか入れ替えた。

こちらがオリジナルの４分バージョン

こいつを2分にしたVer. 2
Haze Loops Ver.2 / N + 1 Loops

Haze Loops Ver.2 / N + 1 Loops - GarageBand Edit -
こちらはGarageBandの映像バージョン

ではまた:)

Enjoy DTM and GarageBand !

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

2024年9月 7日 (土)

VirtualBox-7.1.0_BETA2-164697 (2024-09-06T20:27:41Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録　（VM起動せず）

TestBuild Development Snapshotが　7.1.0_BETA2-164697 (2024-09-06T20:27:41Z)　になっていましたが。前回、前々回同様、7.0の初期のころに先祖返りしたような感じで、x86系VMは以下のメッセージとともに起動できず。（起動時間計測が毎回の楽しみになってきたのでw、早く組み込んでもらいたいですね7.1.0 BETAにも :)

oracle@Mac-Studio ~ % ./print_env.sh

*** mac info. ***
ProductName:		macOS
ProductVersion:		14.6.1
BuildVersion:		23G93
 
*** 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.1.0_BETA2r164697

VMが起動するとかしないとか以前の状況、この部分だけみると先祖返りしちゃってるんで、組み込まれるまではしばらくかかりそうですね。
（7.1.0_BETAになった3度目の更新ですが....)

この状況は、以前のリリースで起動していたVMでも、VirtualBox-7.1.0_BETA2-164697 にインポートしたx86系VMでも同様です。

次の更新を楽しみにして、じっと待つ:)

一瞬、秋？みたいな感じの気温だったが、真夏に逆戻りの東京より

ではまた。:)

・MySQL 8.0.32 , PostgreSQL 13.4 and Oracle Database 21c on Oracle Linux 8 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160702
・ySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r161342
・MySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r161709
・MySQL 8.0.36 , PostgreSQL 13.14, Oracle Database 21c, Oracle Database 23ai on VirtualBox for Apple Silicon Test Build 7.0.97_BETA r162957
・VirtualBox TestBuild for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録 / 7.0.97r162957(2024/4/26) / 7.0.97r163029(2024/5/3)
・VirtualBox TestBuild 7.0.97r163376 (2024-05-28T15:08:56Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録
・VirtualBox TestBuild 7.0.97r163425 (2024-06-05T13:13:46Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録
・VirtualBox TestBuild 7.0.97r163606 (2024-06-21T11:55:16Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録
・VirtualBox TestBuild 7.1.0_BETA1r164292 (2024-08-07T18:27:07Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録
・VirtualBox TestBuild 7.1.0_BETA1r164387 (2024-08-15T17:27:33Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

投稿日時 2024年9月 7日 (土) 09時42分 Oracle, VirtualBox, MySQL, PostgreSQL, Oracle Database 19c, Oracle Database 21c, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年9月 1日 (日)

DTM / 8月に公開した曲

DTM/GarageBandにある既存のAppleLoopsだけでがんばって作る曲シリーズw
月2曲というペースに落ち着きつつあるが、1曲でも良さげな気もするw （思いつきで作ってるからなぁ。いつまで続くやらw

Heavy Rain Loops / N + 1 Loops
二年前に Rain Loopsっての作ってからもっとハードな感じのできないだろうかとぼんやり思っていたのだが、酷暑とゲリラ豪雨連続なので無理やり作ってみた感じw。

Loops #78 / N + 1 Loops
曲のタイトル浮かばなくてw、　困ったときは連番でw。
ちょうど、ドンキのブルーノマーズを起用したCMの動画のミュートしてこの曲かけたら、面白い感じで合ってたりw。まぐれにしてはよいwww

こちらはDance Edit（合わせる動画変えただけですがw）

ではまたw

投稿日時 2024年9月 1日 (日) 07時37分音楽, GarageBand, iMovie, DTM, AppleLoops, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年8月16日 (金)

VirtualBox TestBuild 7.1.0_BETA1r164387 (2024-08-15T17:27:33Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

VirtualBox 7.1.0_BETA1r164378が8/15に公開されていましたが、今回もGuestVM起動できず、計測不能でした。

ちなみに、VirtualBox Extension PackもVersionが古く(7.0.97.163425なのでかなり古いですね)インストールできないミスマッチの状態となっているので、そのあたりも影響しているのかもしれません。TestBuildsですからね。長ーい目で見守りましょう。　7.1になってから二回目の更新ですし:)

インストールされたVirtualBoxのリリースは、7.1.0_BETA1r164378

ということで、強烈な台風が近づいている東京より。

みなさん、安全を最優先に:)

ではまた。

投稿日時 2024年8月16日 (金) 06時00分 Oracle, Mac, VirtualBox, MySQL, PostgreSQL, Oracle Database 21c, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年8月 8日 (木)

VirtualBox TestBuild 7.1.0_BETA1r164292 (2024-08-07T18:27:07Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

VirtualBox TestBuild 7.1.0_BETA1r164292 (2024-08-07T18:27:07Z) が公開されていました。

7.1になり、アイコンやスプラッシュも変更されたようですが、、、久しぶりに計測できず！　（次回に期待したいと思います！）

以下、M1/M2いずれもGuest VM起動できませんでした！

*** mac info. ***
ProductName:		macOS
ProductVersion:		14.6.1
BuildVersion:		23G93
 
*** 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.1.0_BETA1r164292

*** 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:		14.5
BuildVersion:		23F79

*** VirtualBox ver. ***
7.1.0_BETA1r164292

7.1になった影響だろうか。。。
なお、今回は旧リリースのVirtualBox TestBuild 7.0.97r163779 (2024-07-04T18:53:02Z)　をアップデートしただけ（本来それで良いはずだが）なので、VMのインポートし直した場合も同様の結果、No Supported 。どうなってるんだろう。どうなるかまでは未確認です。
（検証後、本エントリーへ追加する予定）

しかし、酷暑と夕方のCloud 9もくもく後のゲリラ豪雨が、夏のニューノーマルになってしまうと夏のイベントは秋にでもしないと無理かもしれないですねー。花笠祭りも影響受けたようですし。
ちなみに、多摩川花火大会は、何年か前のゲリラ豪雨以後、10月開催に切り替えた経緯がありますよね。。

ではまた。

・
・MySQL 8.0.32 , PostgreSQL 13.4 and Oracle Database 21c on Oracle Linux 8 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160702
・ySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r161342
・MySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r161709
・MySQL 8.0.36 , PostgreSQL 13.14, Oracle Database 21c, Oracle Database 23ai on VirtualBox for Apple Silicon Test Build 7.0.97_BETA r162957
・VirtualBox TestBuild for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録 / 7.0.97r162957(2024/4/26) / 7.0.97r163029(2024/5/3)
・VirtualBox TestBuild 7.0.97r163376 (2024-05-28T15:08:56Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録
・VirtualBox TestBuild 7.0.97r163425 (2024-06-05T13:13:46Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録
・VirtualBox TestBuild 7.0.97r163606 (2024-06-21T11:55:16Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録
・VirtualBox TestBuild 7.0.97r163779 (2024-07-04T18:53:02Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

投稿日時 2024年8月 8日 (木) 06時45分 Oracle, VirtualBox, MySQL, PostgreSQL, Oracle Database 21c, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年8月 3日 (土)

DTM / 7月に公開した曲

DTM/GarageBandにある既存のAppleLoopsだけでがんばって作る曲シリーズw
7月も結構なペースでリリースw（マイナーアップデート含む）

YMOPPOI LOOPS 2 / N + 1 Loops
YMOっぽい音を探して作ってみた part 2。まあ、そんな感じですw

Nu Funky Loops in Clouds ver.3 / N + 1 Loops
先月公開 ( https://youtu.be/YCw-hDWi2QI ) した曲のメジャーバージョンアップ。アジャイルDTMですので、思いついたら多分、いろいろ変えてみる流れ。

Let's Loop! / N + 1 Loops - GarageBand Edit -
爆風銃でほーじんが活躍しだしたころを思い出しつつ、Slap BASSのループをチョップしまくってなにかを作るというテーマでw。

Let's Loop! ver. 1.1 / N + 1 Loops
いつものように、思いつきで ( https://youtu.be/qaRR-eJuX50 ) を一週間後にマイナーアップデートしたやつ

ということで、　8月はなにか思いつくだろうかw

Enjoy GarageBand and DTM!

ではまた。

投稿日時 2024年8月 3日 (土) 09時36分音楽, GarageBand, iMovie, DTM, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年7月 8日 (月)

VirtualBox TestBuild 7.0.97r163779 (2024-07-04T18:53:02Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

2024-07-04T18:53:02Z に最新のTestBuild ( development revision 163779 ) が公開されていました。

恒例のOracle Database 21c on VirtualBox TestBuild for macOS/ARM64 の起動時間の記録です。

今回は、M1/M2とも前回とほぼ同じぐらい。改善は次回に期待 :) :) :) :) :)
とはいえ、そろそろ大詰め？　な感じもしなくもない。。。。

oracle@Mac-Studio ~ % ./print_env.sh 
 
*** mac info. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79
 
*** 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.0.97r163779

起動1回目 : 168 sec
停止1回目 :  77 sec
起動2回目 : 156 sec
停止2回目 :  48 sec

oracle@angelfish ~ % ./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:		14.5
BuildVersion:		23F79

*** VirtualBox ver. ***
7.0.97r163779

起動1回目 :  93 sec
停止1回目 :  33 sec
起動2回目 :  95 sec
停止2回目 :  55 sec

VMのOSバージョンなどは過去のエントリーを見ていただくとして、M1/M2 それぞれ以下のPostgreSQL/MySQL/Oracle Databaseが起動することを確認。ルーティーン :)

MySQL

[master@localhost ~]$ mysql -u scott -D perftestdb -p -h localhost -e 'select version();'
Enter password: 
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+

PostgreSQL

[master@localhost ~]$ sudo su - postgres -c 'psql -d perftestdb -U discus -p 5432 -W -h localhost -c "select version()"'
パスワード： 
                                                 version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit
(1 行)

Oracle Database (21c)

[oracle@localhost ~]$ sqlplus / as sysdba @version

....中略....

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

Oracle Database (23ai)

[oracle@localhost ~]$ sqlplus hr/oracle@localhost:1521/freepdb1 @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

では、次回の起動停止時間ログをお楽しみに:)
最近のペースだと、7月の後半にありそうですよね.

投稿日時 2024年7月 8日 (月) 12時34分 Oracle, Mac, VirtualBox, MySQL, PostgreSQL, Oracle Database 21c, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年7月 6日 (土)

DTM / 6月に公開した曲

ちょいと、遅れましたが、DTM/GarageBandにある既存のAppleLoopsだけでがんばって作る曲シリーズw

はじめてから3年目ですがw たぶん70曲ぐらい作ってるはず。だなーと。ありもののループを利用しているだけなので、お気に入りのループが固定化してワンパターンな感じになるのをなんとか避けつつw　ネタが浮ぶ限りというか飽きなければやっていこうかなとw
（普段とは使う脳の部位が違うので、頭のリフレッシュに最適w）

ということで、先月の１曲目は、5月に作った曲のリズムトラック版。
このリズムトラックを元にDub Versionを作ったり、作った曲のマイナーアップデートをしています。（ようするに意外に気に入ってるということでw）

Nu Funky Loops in Clouds ver. 1.1 Rhythm Tracks / N + 1 Loops

次は、Nu Funky Loops in Clouds ver. 1.1 をLoops in Cloudsでも使ったギターリフをやめて、ちょっと別な方向に振ったメジャーアップデート.

Nu Funky Loops in Clouds ver. 2 / N + 1 Loops

3曲目は偶に作りたくなるテクノ。YMOっぽいというかProphet-5っぽいうというか、坂本教授が好んで使っていた感じの音に近いループってAppleLoopsにほぼないので、中かな辛かったり、ピコピコ矩形波系の音も使いにくのはあるけどもで、そのなかから喫茶店にあったTVゲームっぽい音ループがあったので、Firecrackerっぽい感じと、YMOも後半のスネアの音。坂本教授の電気的音楽講座、大好きだったのでどんなエフェクター使ったとか云々が記憶に残っててw　それっぽい感じにしつつ。w

YMOPPOI LOOPS / N + 1 Loops

ではまた。

Enjoy DTM / GarageBand !

投稿日時 2024年7月 6日 (土) 05時56分 Mac, GarageBand, iMovie, DTM, AppleLoops, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年6月23日 (日)

VirtualBox TestBuild 7.0.97r163606 (2024-06-21T11:55:16Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

2024-06-21に最新のTestBuildが公開されていました。

恒例のOracle Database 21c on VirtualBox TestBuild for macOS/ARM64 の起動時間の記録です。

oracle@Mac-Studio ~ % ./print_env.sh
 
*** mac info. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79
 
*** 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.0.97r163606

M1で停止時間が2桁秒台になったほか、起動時間も改善してますね！

起動1回目 : 130 sec
停止1回目 :  66 sec
起動2回目 : 145 sec
停止2回目 :  45 sec

oracle@angelfish ~ % ./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:		14.5
BuildVersion:		23F79

*** VirtualBox ver. ***
7.0.97r163606

起動停止時間の記録をとり始めてから、M2でも最短記録ですね！！！！　

起動1回目 : 108 sec
停止1回目 :  34 sec
起動2回目 :  91 sec
停止2回目 :  49 sec

今回は、起動停止時間ともこれまでの最速値です。(^^) (^^) (^^)

次回のリリースが楽しみですね。。。

VMのOSバージョンなどは過去のエントリーを見ていただくとして、M1/M2 それぞれ以下のPostgreSQL/MySQL/Oracle Databaseが起動することを確認。

PostgreSQL

[master@localhost ~]$ sudo su - postgres -c 'psql -d perftestdb -U discus -p 5432 -W -h localhost -c "select version()"'

                                                 version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit
(1 行)

MySQL

[master@localhost ~]$ mysql -u scott -D perftestdb -p -h localhost -e 'select version();'

+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+

Oracle Database 21c

[oracle@localhost ~]$ sqlplus / as sysdba @version

...略...

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

Oracle Database 23ai

[oracle@localhost ~]$ sql hr/oracle@localhost:1521/freepdb1 @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

VirtualBox Team　がんばれ〜〜〜〜〜 :)

では、次回の起動停止時間ログをお楽しみに:)

投稿日時 2024年6月23日 (日) 17時29分 Oracle, Mac, SQL, VirtualBox, MySQL, PostgreSQL, Oracle Database 21c, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年6月15日 (土)

VirtualBox TestBuild 7.0.97r163425 (2024-06-05T13:13:46Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

さて、恒例のOracle Database 21c on VirtualBox TestBuild for macOS/ARM64 の起動時間の記録です。
2024-06-05T13:13:46Zに公開されていた。起動自体は非常に安定してきましたね。細かいところは色々あるようですが、正式リリースが待ち遠しい。

oracle@Mac-Studio ~ % ./print_env.sh 
 
*** mac info. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79
 
*** 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.0.97r163425

Oracle Database 21c / Mac Studio M1
微妙な差なので変化なしという感じですね。

起動1回目 : 202 sec
停止1回目 :  86 sec
起動2回目 : 163 sec
停止2回目 : 143 sec

oracle@angelfish ~ % ./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:		14.5
BuildVersion:		23F79

*** VirtualBox ver. ***
7.0.97r163425

Oracle Database 21c / MacBook Air M2
若干、前回公開されたTestBuildより遅くなってる気がしますよね。（たった二回しか起動停止させてないので、参考記録程度なわけですけども）

起動1回目 : 244 sec
停止1回目 : 136 sec    
起動2回目 : 201 sec
停止2回目 : 101 sec

その他、いつもの起動確認。
PostgreSQL 13.14 / MySQL 8.0.36 / Oracle Database 21c　及び、 23ai (M1/M2それぞれ起動)
GuestOSのバージョンなどはこれまでと同じなので省略して、それぞれのバージョン確認ログで起動確認。

[master@localhost ~]$ mysql -u scott -D perftestdb -p -h localhost -e 'select version();'
Enter password: 
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+

[master@localhost ~]$ sudo su - postgres -c 'psql -d perftestdb -U discus -p 5432 -W -h localhost -c "select version()"'
パスワード： 
                                                 version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit
(1 行)

[oracle@localhost ~]$ sqlplus scott@orclpdb1 @version

...略...

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


[oracle@localhost ~]$ sql hr@192.168.1.138:1521/freepdb1 @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

[oracle@localhost ~]$ cat version.sql
select banner_full from v$version;
exit

これ、ルーティーンになりそうw

ではまた。

投稿日時 2024年6月15日 (土) 19時20分 Oracle, Mac, VirtualBox, MySQL, PostgreSQL, Oracle Database 21c, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年6月 3日 (月)

DTM / 5月に公開した曲

毎月のルーティーンw

5月に公開したループ一覧
先月は、１つ作ってそのリズムトラックが面白かったのでダブバージョン作って勢いで、マイナーアップデートまでw

まず１曲目

Fallen Leaves Loops Ver.1.2 - Dub version of Sunny Spot Loops / N + 1 Loops

Fallen Leaves Loops のマイナーバージョンアップです。パーカッションなど追加。

Summer Sea Breeze Loops / N + 1 Loops

夏っぽい何かを作ろうと思ってたらこうなってしまったw。この曲のリズムトラック、ベースのループをチョップしまくってますw

Memories - Summer Sea Breeze Loops version / N + 1 Loops

Summer Sea Breeze Loops と Memories Loops Ver. 1.1 をmixしてMemories側に寄せたDub versionってところを狙ったつもりw　
なので、タイトルは、　Memories - Summer Sea Breeze Loops versionに。

Nu Funky Loops in Clouds ( Dance Edittion ) / N + 1 Loops

Summer Sea Breeze LoopsとMemories Loops Ver. 1.1 をミックスした Memories - Summer Sea Breeze Loops versionのリズムセクションと、Loops in cloudsとCity Lights Loopsの一部を混ぜ込んだ曲ですが、Loops in cloudsに寄せたので、その後継バージョンw
ループの再利用とかガレバンっぽい使い方なのではないかと。。:)

最後は、一つ前の曲のマイナーアップデート
Nu Funky Loops in Clouds ver. 1.1 / N + 1 Loops

Nu Funky Loops in Cloudsのマイナーアップデート、困った時のw VOXとHand Clapトラック追加でw。

上記の曲の親子関係というか繋がりは以下の図の通り。
リズムセクションを流用して、さらにバスドラのトラックを追加したり、一部の効果音だけをパーカッション的に流用追加したり、ガレバンらしい使い方になっているかとw（ガレバンの機能はそれだけではないですけどもね）

では、また

Enjoy GarageBand and DTM!

投稿日時 2024年6月 3日 (月) 20時36分音楽, GarageBand, DTM, AppleLoops, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年5月31日 (金)

VirtualBox TestBuild 7.0.97r163376 (2024-05-28T15:08:56Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

VirtualBox TestBuild 7.0.97r163376 (2024-05-28T15:08:56Z) / macOS/ARM64 Dev Previewがリリースされていたので、いつもの、起動確認と、Oracle Database 21cの起動時間比較を。
前回の記録は、VirtualBox TestBuild for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録 / 7.0.97r162957(2024/4/26) / 7.0.97r163029(2024/5/3)を見てもらうとして、結果的には大きくな変化なし！。

頑張って！ :)　

oracle@Mac-Studio ~ % ./print_env.sh 
 
*** mac info. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79
 
*** 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.0.97r163376

Oracle Database 21c Mac Studio M1

起動1回目 : 217sec
停止1回目 : 153sec
起動2回目 : 186sec
停止2回目 : 119sec

oracle@angelfish ~ % ./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:		14.5
BuildVersion:		23F79

*** VirtualBox ver. ***
7.0.97r163376

Oracle Database 21c MacBook Air M2

起動1回目 : 138sec
停止1回目 : 108sec
起動2回目 : 128sec
停止2回目 :  83sec

その他、いつもの起動確認。
PostgreSQL 13.14 / MySQL 8.0.36 / Oracle Database 21c　及び、 23ai 、それぞれ、VirtualBox TestBuild 7.0.97r163376 （024-05-28T15:08:56Z）でも起動した！　（このあたりはマジで安定してきた）

oracle@Mac-Studio ~ % ./print_env.sh 
 
*** mac info. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79
 
*** 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.0.97r163376

[master@localhost ~]$ cat /etc/*release*
Oracle Linux Server release 8.5
NAME="Oracle Linux Server"
VERSION="8.5"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.5"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.5"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:5:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://bugzilla.oracle.com/"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.5
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.5
Red Hat Enterprise Linux release 8.5 (Ootpa)
Oracle Linux Server release 8.5
cpe:/o:oracle:linux:8:5:server
[master@localhost ~]$

PostgreSQL 13.14 - 起動した！

[master@localhost ~]$ sudo su - postgres
[postgres@localhost ~]$ psql -d perftestdb -U discus -p 5432 -W -h localhost
パスワード： 
psql (13.14)
"help"でヘルプを表示します。

perftestdb=> select version();
                                                 version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit
(1 行)

perftestdb=> exit

MySQL 8.0.36 - 起動した！

[master@localhost ~]$ mysql -u scott -D perftestdb -p -h 192.168.1.125
Enter password: 
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.0.36 Source distribution

Copyright (c) 2000, 2024, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+
1 row in set (0.01 sec)

mysql> exit
Bye

Oracle Database 21c - 起動した！

[oracle@localhost ~]$ cat /etc/*release*
Oracle Linux Server release 8.4
NAME="Oracle Linux Server"
VERSION="8.4"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.4"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.4"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:4:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://bugzilla.oracle.com/"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.4
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.4
Red Hat Enterprise Linux release 8.4 (Ootpa)
Oracle Linux Server release 8.4
cpe:/o:oracle:linux:8:4:server
[oracle@localhost ~]$ 
[oracle@localhost ~]$ sqlplus / as sysdba

SYS@ORCLCDB> 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

SYS@ORCLCDB> exit

Oracle Database 23ai - 起動した！

[oracle@localhost ~]$ cat /etc/*release*
Oracle Linux Server release 8.9
NAME="Oracle Linux Server"
VERSION="8.9"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.9"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.9"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:9:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://github.com/oracle/oracle-linux"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.9
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.9
Red Hat Enterprise Linux release 8.9 (Ootpa)
Oracle Linux Server release 8.9
cpe:/o:oracle:linux:8:9:server
[oracle@localhost ~]$ sql scott/@192.168.1.138:1521/freepdb1


SQL> 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    

SQL>

これが、本当の5月最後の投稿ということでw

では、また。

投稿日時 2024年5月31日 (金) 13時00分 Oracle, Mac, VirtualBox, MySQL, PostgreSQL, Oracle Database 21c, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年5月 9日 (木)

VirtualBox TestBuild for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録 #2 / 7.0.97r163068 ( 2024-5-07T20:38:44Z )

2025-05-03にTestBuildが更新されていたわけですが、なんと、2024-5-07T20:38:44Zに更新されていました。(テストビルドって、月に何回更新されてるのだろう？...)

Oracle Database 23ai Free Developer、Oracle Database 21c EE 、MySQL 8.0.36 そして PostgreSQL 13.14
は問題なく起動（最近安定して起動するのでログは省略）。

ということで、Oracle Database 21cの起動、停止時間の記録だけメモしておきます。

起動停止時間は大きく変わってないように思います（ブレはある程度あるにしても）が、若干速くなってる気もしますね。特に、M1で。次のアップデートが楽しみですね。

Mac Studio M1

** macOS ver. ***
ProductName:		macOS
ProductVersion:		14.4.1
BuildVersion:		23E224
 
*** mac info. ***
      Model Name: Mac Studio
      Chip: Apple M1 Ultra
      Total Number of Cores: 20 (16 performance and 4 efficiency)
      Memory: 64 GB
 
*** VirtualBox ver. ***
7.0.97r163068

VirtualBox TestBuild 7.0.97r163068 ( 2024-5-07T20:38:44Z ) / Mac Studio M1

起動1回目 : 211sec
停止1回目 :  90sec
起動2回目 : 159sec
停止2回目 : 104sec

MacBook Air M2

*** macOS ver. ***
      Model Name: MacBook Air
      Chip: Apple M2
      Total Number of Cores: 8 (4 performance and 4 efficiency)
      Memory: 24 GB

*** mac info. ***
ProductName:		macOS
ProductVersion:		14.4.1
BuildVersion:		23E224

*** VirtualBox ver. ***
7.0.97r163068

VirtualBox TestBuild 7.0.97r163068 ( 2024-5-07T20:38:44Z ) / MacBook Air M2

起動1回目 : 133sec
停止1回目 :  20sec
起動2回目 : 152sec
停止2回目 : 106sec

ではまた

・Oracle Linux 8 and MySQL 8.0.32 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA r160167
・MySQL 8.0.32 , PostgreSQL 13.4 and Oracle Database 21c on Oracle Linux 8 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA r160702
・MySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA r161342
・MySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA r161709
・MySQL 8.0.36 , PostgreSQL 13.14, Oracle Database 21c, Oracle Database 23ai on VirtualBox for Apple Silicon Test Build 7.0.97_BETA r162957
・VirtualBox TestBuild for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録 / 7.0.97r162957(2024/4/26) / 7.0.97r163029(2024/5/3)

投稿日時 2024年5月 9日 (木) 14時00分 Oracle, Mac, VirtualBox, Oracle Database 21c, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年5月 7日 (火)

VirtualBox TestBuild for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録 / 7.0.97r162957(2024/4/26) / 7.0.97r163029(2024/5/3)

さて、ここのところVirtualBoxの話題が多いですが、安定して起動するようになったVirtualBox TestBuild for macOS/ARM64。気になるのも当然です。Intel Macいつ捨てるんだよって話もあるわけでw

という個人的な都合は置いておいてw

以下にも記載されているように、現状は、性能面含めた問題があることもあり、Intel版macのVirtualBoxと完全にお別れすることもできない状況ではあります。
https://www.virtualbox.org/wiki/Testbuilds “The test builds for macOS/ARM64 work in principle on Macs with M1, M2 or M3 CPU. However, they are developer previews with known issues (including serious performance ones) with all recent guest operating systems.”

ただ、最近のTestBuildでは安定して起動するようにところまで改善してきておりいつ正式リリースだろう。。。と気になってしょうがない状況ではありますwww

と、いうことで、
現時点のApple Silicon版VirtualBoxで安定して起動するようになったOracle Database 21c EEの起動停止速度をざっくり確認しておこうと思います。
（今後のVirtualBoxのリリースで、どう改善したのか確認するネタとしても大切なので）

起動提示時間の確認方法は、それぞれのmacで、同じ方法で行いました。

前提　同じVMをそれぞれインポートして実施
1. VirtualBoxのVMを起動（Oracleは自動起動にしていない）
2. LSNRCTL for Linuxの起動
3. Oracle Database 21cの起動
4. Oracle Database 21cの停止
5. Oracle Database 21cの起動
6. Oracle Database 21cの停止

を行い、どの程度の時間で起動停止できるのかメモっておいた。Apple SiliconのVirtualBoxもIntel版レベルに近づいて欲しいところではある。。。が現時点では桁が違いますね。。。

ただ、7.0.97r162957(2024/4/26)版のTestBuildと7.0.97r163029(2024/5/3)版のTestBuildだと、若干、7.0.97r163029(2024/5/3)版の方が速くなって気はしますよね。。。。若干ですが。

比較しやすいように、Intel版のVirtualBoxでも同様の手順で実施して記録を残しておきました。
VirtualBox TestBuild 7.0.97r162957(2024/4/26) / MacBook AIR M2

 起動1回目 : 303sec
 停止1回目 :  77sec
 起動2回目 : 147sec
 停止2回目 :  77sec

VirtualBox TestBuild 7.0.97r163029(2024/5/3) / MacBook AIR M2

 起動1回目 : 140sec
 停止1回目 :  78sec
 起動2回目 : 128sec
 停止2回目 :  57sec

VirtualBox TestBuild 7.0.97r162957(2024/4/26) / Mac Studio M1

 起動1回目 : 315sec
 停止1回目 : 156sec
 起動2回目 : 242sec
 停止2回目 : 175sec

VirtualBox TestBuild 7.0.97r163029(2024/5/3) / Mac Studio M1

 起動1回目 : 182sec
 停止1回目 : 101sec
 起動2回目 : 206sec
 停止2回目 : 111sec

VirtualBox 7.0.10r158379 / MacBook Intel

 起動1回目 :  20sec
 停止1回目 :  42sec
 起動2回目 :  13sec
 停止2回目 :  36sec

VirtualBox 6.1.26r145957 / Mac Pro Intel

 起動1回目 :  22sec
 停止1回目 :  35sec
 起動2回目 :  14sec
 停止2回目 :  38sec

以下、各ホストの情報
MacBook AIR M2 - VirtualBox TestBuild for Apple Silicon

*** macOS ver. ***
      Model Name: MacBook Air
      Chip: Apple M2
      Total Number of Cores: 8 (4 performance and 4 efficiency)
      Memory: 24 GB

*** mac info. ***
ProductName:		macOS
ProductVersion:		14.4.1
BuildVersion:		23E224

*** VirtualBox ver. ***
7.0.97r162957

MacBook AIR M2 - VirtualBox TestBuild for Apple Silicon


...略...

*** VirtualBox ver. ***
7.0.97r163029

Mac Studio M1 - VirtualBox TestBuild for Apple Silicon

*** maxOS ver. ***
ProductName:		macOS
ProductVersion:		14.4.1
BuildVersion:		23E224
 
*** mac info. ***
      Model Name: Mac Studio
      Chip: Apple M1 Ultra
      Total Number of Cores: 20 (16 performance and 4 efficiency)
      Memory: 64 GB
 
*** VirtualBox ver. ***
7.0.97r162957

Mac Studio M1 - VirtualBox TestBuild for Apple Silicon


...略...
 
*** VirtualBox ver. ***
7.0.97r163029

MacBook Intel

*** maxOS ver. ***
ProductName:	macOS
ProductVersion:	12.7.4
BuildVersion:	21H1123
 
*** mac info. ***
      Model Name: MacBook
      Processor Name: Dual-Core Intel Core m5
      Processor Speed: 1.2 GHz
      Number of Processors: 1
      Total Number of Cores: 2
      Memory: 8 GB
 
*** VirtualBox ver. ***
7.0.10r158379

Mac Pro Intel

*** maxOS ver. ***
ProductName:	Mac OS X
ProductVersion:	10.14.6
BuildVersion:	18G9323
 
*** mac info. ***
      Model Name: Mac Pro
      Processor Name: 6-Core Intel Xeon
      Processor Speed: 2.4 GHz
      Number of Processors: 2
      Total Number of Cores: 12
      L3 Cache (per Processor): 12 MB
      Memory: 32 GB
 
*** VirtualBox ver. ***
6.1.26r145957

手順例（参考）

[oracle@localhost ~]$ sqlplus / as sysdba

SQL*Plus: Release 21.0.0.0.0 - Production on 火 5月 6 16:07:02 2024
Version 21.3.0.0.0

Copyright (c) 1982, 2021, Oracle.  All rights reserved.

アイドル・インスタンスに接続しました。

16:07:02 SYS@ORCLCDB>        
16:07:10 SYS@ORCLCDB> startup
ORACLEインスタンスが起動しました。

Total System Global Area  536867744 bytes
Fixed Size                  9687968 bytes
Variable Size             360710144 bytes
Database Buffers           54525952 bytes
Redo Buffers                7086080 bytes
In-Memory Area            104857600 bytes
データベースがマウントされました。
データベースがオープンされました。
16:09:30 SYS@ORCLCDB>           
        16:10:27 SYS@ORCLCDB> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
16:11:35 SYS@ORCLCDB> 
16:12:23 SYS@ORCLCDB> 
16:12:23 SYS@ORCLCDB> startup
ORACLEインスタンスが起動しました。

Total System Global Area  536867744 bytes
Fixed Size                  9687968 bytes
Variable Size             360710144 bytes
Database Buffers           54525952 bytes
Redo Buffers                7086080 bytes
In-Memory Area            104857600 bytes
データベースがマウントされました。
データベースがオープンされました。
16:14:31 SYS@ORCLCDB> 
16:15:35 SYS@ORCLCDB> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
16:16:32 SYS@ORCLCDB>

少しずずIntel版の速度に近づいて欲しいものですね。VirtualBoxチーム頑張って〜〜〜っ！

では、また。

投稿日時 2024年5月 7日 (火) 19時14分 Mac, VM, VirtualBox, Oracle Database 21c, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年5月 4日 (土)

MySQL 8.0.36 , PostgreSQL 13.14, Oracle Database 21c, Oracle Database 23ai on VirtualBox for Apple Silicon Test Build 7.0.97_BETA r162957

Oracle Database 23c 改め、23ai となったのと、4/26日版 VirtualBox Test builds Development snapshotsがリリースされていた（だが、5/3版がすでに公開されていたw）
https://www.virtualbox.org/wiki/Testbuilds

M2 MBAでの確認情報だけで、M1はどうよ？とこともあるので、今回は、M1側で検証してみた。（本当はこちらでバシバシ使いたいわけですけども、まだまだ遅いので確認だけw）

*** mac info. ***
ProductName:		macOS
ProductVersion:		14.4.1
BuildVersion:		23E224
 
*** 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.0.97r162957
(VirtualBox 4/26 Test-Builds Developer Snapshot)

公開されたばかりの、Oracle Database 23ai Free DeveloperのVirtualBox pre-Build VMでの確認。
https://www.oracle.com/database/technologies/databaseappdev-vm.html

Oracle Database 23ai Free Developer (VirtualBox pre-build VM) / Oracle Linux 8.9

相変わらずもっさり感は強いもののなんとか起動します！　

[oracle@localhost ~]$ cat /etc/*release
Oracle Linux Server release 8.9
NAME="Oracle Linux Server"
VERSION="8.9"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.9"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.9"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:9:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://github.com/oracle/oracle-linux"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.9
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.9
Red Hat Enterprise Linux release 8.9 (Ootpa)
Oracle Linux Server release 8.9

[oracle@localhost ~]$ sql hr/oracle@192.168.1.138:1521/freepdb1

SQLcl: 土 5月 04 01:14:44 2024のリリース24.1 Production

Copyright (c) 1982, 2024, Oracle.  All rights reserved.

接続先:
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05

SQL> 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    

SQL> exit
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05から切断されました
[oracle@localhost ~]$ sudo service oracle status
[sudo] oracle のパスワード:

LSNRCTL for Linux: Version 23.0.0.0.0 - Production on 04-MAY-2024 01:26:55

Copyright (c) 1991, 2024, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 23.0.0.0.0 - Production
Start Date                04-MAY-2024 00:49:21
Uptime                    0 days 0 hr. 37 min. 34 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Default Service           FREE
Listener Parameter File   /opt/oracle/product/23ai/dbhomeFree/network/admin/listener.ora
Listener Log File         /opt/oracle/diag/tnslsnr/localhost/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Services Summary...
Service "176858bcadf91ba6e0630100007f7de0" has 1 instance(s).
  Instance "FREE", status READY, has 1 handler(s) for this service...
Service "FREE" has 2 instance(s).
  Instance "FREE", status UNKNOWN, has 1 handler(s) for this service...
  Instance "FREE", status READY, has 1 handler(s) for this service...
Service "FREEXDB" has 1 instance(s).
  Instance "FREE", status READY, has 1 handler(s) for this service...
Service "freepdb1" has 1 instance(s).
  Instance "FREE", status READY, has 1 handler(s) for this service...
The command completed successfully
[oracle@localhost ~]$ sudo service oracle stop
Stopping oracle (via systemctl):                           [  OK  ]

続いて、いつもの 21c。　こちらは、 Oracle Linux 8.4に載せています

Oracle Database 21c EE / Oracle Linux 8.4

Oracle Database 21c EE / Oracle Linux 8.4
[master@localhost ~]$ cat /etc/*release
Oracle Linux Server release 8.4
NAME="Oracle Linux Server"
VERSION="8.4"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.4"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.4"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:4:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://bugzilla.oracle.com/"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.4
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.4
Red Hat Enterprise Linux release 8.4 (Ootpa)
Oracle Linux Server release 8.4

[master@localhost ~]$ sudo su - oracle
[oracle@localhost ~]$ lsnrctl start

LSNRCTL for Linux: Version 21.0.0.0.0 - Production on 04-5月 -2024 08:54:58

Copyright (c) 1991, 2021, Oracle.  All rights reserved.

/opt/oracle/product/21c/dbhome_1/bin/tnslsnrを起動しています。お待ちください...

TNSLSNR for Linux: Version 21.0.0.0.0 - Production
システム・パラメータ・ファイルは/opt/oracle/homes/OraDBHome21cEE/network/admin/listener.oraです。
ログ・メッセージを/opt/oracle/diag/tnslsnr/localhost/listener/alert/log.xmlに書き込みました。
リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521)))
リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))に接続中
リスナーのステータス
------------------------
別名                      LISTENER
バージョン                TNSLSNR for Linux: Version 21.0.0.0.0 - Production
開始日                    04-5月 -2024 08:55:00
稼働時間                  0 日 0 時間 0 分 0 秒
トレース・レベル          off
セキュリティ              ON: Local OS Authentication
SNMP                      OFF
パラメータ・ファイル      /opt/oracle/homes/OraDBHome21cEE/network/admin/listener.ora
ログ・ファイル            /opt/oracle/diag/tnslsnr/localhost/listener/alert/log.xml
リスニング・エンドポイントのサマリー...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
リスナーはサービスをサポートしていません。
コマンドは正常に終了しました。
[oracle@localhost ~]$ 
[oracle@localhost ~]$ 
[oracle@localhost ~]$ sqlplus / as sysdba

SQL*Plus: Release 21.0.0.0.0 - Production on 土 5月 4 08:55:08 2024
Version 21.3.0.0.0

Copyright (c) 1982, 2021, Oracle.  All rights reserved.

アイドル・インスタンスに接続しました。

08:55:10 SYS@ORCLCDB> startup
ORACLEインスタンスが起動しました。

Total System Global Area 1073740720 bytes
Fixed Size                  9694128 bytes
Variable Size             910163968 bytes
Database Buffers           41943040 bytes
Redo Buffers                7081984 bytes
In-Memory Area            104857600 bytes
データベースがマウントされました。
データベースがオープンされました。
08:58:23 SYS@ORCLCDB> 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


経過: 00:00:00.32
08:58:36 SYS@ORCLCDB> exit
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0との接続が切断されました。
[oracle@localhost ~]$ sqlplus / as sysdba

SQL*Plus: Release 21.0.0.0.0 - Production on 土 5月 4 08:58:46 2024
Version 21.3.0.0.0

Copyright (c) 1982, 2021, Oracle.  All rights reserved.

08:58:55 SYS@ORCLCDB> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
09:00:51 SYS@ORCLCDB>

最後に、安定して起動しているMySQL/PostgreSQL
MySQL 8.0.36 and PostgreSQL 13.14 / Oracle Linux 8.5

[master@localhost ~]$ cat /etc/*release
Oracle Linux Server release 8.5
NAME="Oracle Linux Server"
VERSION="8.5"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.5"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.5"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:5:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://bugzilla.oracle.com/"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.5
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.5
Red Hat Enterprise Linux release 8.5 (Ootpa)
Oracle Linux Server release 8.5

MySQL 8.0.36

Redirecting to /bin/systemctl status mysqld.service
● mysqld.service - MySQL 8.0 database server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2024-05-03 05:34:51 EDT; 53min ago
 Main PID: 1119 (mysqld)
   Status: "Server is operational"
    Tasks: 38 (limit: 22947)
   Memory: 34.5M
   CGroup: /system.slice/mysqld.service
           └─1119 /usr/libexec/mysqld --basedir=/usr

 5月 03 05:34:04 localhost.localdomain systemd[1]: Starting MySQL 8.0 database server...
 5月 03 05:34:07 localhost.localdomain mysql-check-socket[1034]: Socket file /var/lib/mysql/mysql.sock exists.
 5月 03 05:34:08 localhost.localdomain mysql-check-socket[1034]: No process is using /var/lib/mysql/mysql.sock, which means it is a garbage, so it will be removed automatically.
 5月 03 05:34:51 localhost.localdomain systemd[1]: Started MySQL 8.0 database server.
[master@localhost ~]$ 
[master@localhost ~]$ 
 5月 03 05:34:47 localhost.localdomain systemd[1]: Started PostgreSQL 13 database server.

[master@localhost ~]$ mysql -u scott -D perftestdb -p -h 192.168.1.125
Enter password: 
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 10
Server version: 8.0.36 Source distribution

Copyright (c) 2000, 2024, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+
1 row in set (0.02 sec)

mysql> exit
Bye
[master@localhost ~]$ sudo service mysqld stop
Redirecting to /bin/systemctl stop mysqld.service
[master@localhost ~]$ sudo service mysqld status
Redirecting to /bin/systemctl status mysqld.service
● mysqld.service - MySQL 8.0 database server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Fri 2024-05-03 06:30:03 EDT; 8s ago
  Process: 7704 ExecStopPost=/usr/libexec/mysql-wait-stop (code=exited, status=0/SUCCESS)
  Process: 1119 ExecStart=/usr/libexec/mysqld --basedir=/usr (code=exited, status=0/SUCCESS)
 Main PID: 1119 (code=exited, status=0/SUCCESS)
   Status: "Server shutdown complete"

 5月 03 05:34:04 localhost.localdomain systemd[1]: Starting MySQL 8.0 database server...
 5月 03 05:34:07 localhost.localdomain mysql-check-socket[1034]: Socket file /var/lib/mysql/mysql.sock exists.
 5月 03 05:34:08 localhost.localdomain mysql-check-socket[1034]: No process is using /var/lib/mysql/mysql.sock, which means it is a garbage, so it will be removed automatically.
 5月 03 05:34:51 localhost.localdomain systemd[1]: Started MySQL 8.0 database server.
 5月 03 06:29:56 localhost.localdomain systemd[1]: Stopping MySQL 8.0 database server...
 5月 03 06:30:03 localhost.localdomain systemd[1]: mysqld.service: Succeeded.
 5月 03 06:30:03 localhost.localdomain systemd[1]: Stopped MySQL 8.0 database server.

PostgreSQL 13.14

[master@localhost ~]$ sudo service postgresql-13 status
Redirecting to /bin/systemctl status postgresql-13.service
● postgresql-13.service - PostgreSQL 13 database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql-13.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/postgresql-13.service.d
           └─local.conf
   Active: active (running) since Fri 2024-05-03 05:34:47 EDT; 54min ago
     Docs: https://www.postgresql.org/docs/13/static/
 Main PID: 1343 (postmaster)
    Tasks: 9 (limit: 22947)
   Memory: 19.7M
   CGroup: /system.slice/postgresql-13.service
           ├─1343 /usr/pgsql-13/bin/postmaster -D /pg/pgdata/data
           ├─1411 postgres: logger 
           ├─1591 postgres: checkpointer 
           ├─1592 postgres: background writer 
           ├─1593 postgres: walwriter 
           ├─1594 postgres: autovacuum launcher 
           ├─1596 postgres: archiver 
           ├─1597 postgres: stats collector 
           └─1598 postgres: logical replication launcher 

 5月 03 05:34:25 localhost.localdomain systemd[1]: Starting PostgreSQL 13 database server...
 5月 03 05:34:33 localhost.localdomain postmaster[1343]: 2024-05-03 05:34:33.304 EDT [1343] LOG:  redirecting log output to logging collector process
 5月 03 05:34:33 localhost.localdomain postmaster[1343]: 2024-05-03 05:34:33.304 EDT [1343] HINT:  Future log output will appear in directory "log".

[postgres@localhost ~]$ psql -d perftestdb -U discus -p 5432 -W -h localhost
パスワード： 
psql (13.14)
"help"でヘルプを表示します。

perftestdb=> select version();
                                                 version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit
(1 行)

perftestdb=> exit
[postgres@localhost ~]$ exit
ログアウト
[master@localhost ~]$ sudo service postgresql-13 stop
Redirecting to /bin/systemctl stop postgresql-13.service
[master@localhost ~]$ sudo service postgresql-13 status
Redirecting to /bin/systemctl status postgresql-13.service
● postgresql-13.service - PostgreSQL 13 database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql-13.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/postgresql-13.service.d
           └─local.conf
   Active: inactive (dead) since Fri 2024-05-03 06:31:04 EDT; 6s ago
     Docs: https://www.postgresql.org/docs/13/static/
  Process: 1343 ExecStart=/usr/pgsql-13/bin/postmaster -D ${PGDATA} (code=exited, status=0/SUCCESS)
 Main PID: 1343 (code=exited, status=0/SUCCESS)

 5月 03 05:34:25 localhost.localdomain systemd[1]: Starting PostgreSQL 13 database server...
 5月 03 05:34:33 localhost.localdomain postmaster[1343]: 2024-05-03 05:34:33.304 EDT [1343] LOG:  redirecting log output to logging collector process
 5月 03 05:34:33 localhost.localdomain postmaster[1343]: 2024-05-03 05:34:33.304 EDT [1343] HINT:  Future log output will appear in directory "log".
 5月 03 05:34:47 localhost.localdomain systemd[1]: Started PostgreSQL 13 database server.
 5月 03 06:31:03 localhost.localdomain systemd[1]: Stopping PostgreSQL 13 database server...
 5月 03 06:31:04 localhost.localdomain systemd[1]: postgresql-13.service: Killing process 1411 (postmaster) with signal SIGKILL.
 5月 03 06:31:04 localhost.localdomain systemd[1]: postgresql-13.service: Succeeded.
 5月 03 06:31:04 localhost.localdomain systemd[1]: Stopped PostgreSQL 13 database server.

残る課題は処理速度改善だろうとは思うのですが、頑張って欲しいですね:)

そして、ゴールデンウィークなのに、真夏みたいな気温とか、異常すぎる。。。
体調管理に気を遣いつつも、こんな気候だと、まじで今年の夏はどうなることやら。。。。

ではまた。

投稿日時 2024年5月 4日 (土) 11時30分 Oracle, VirtualBox, MySQL, PostgreSQL, Oracle Database 21c, M1 Mac, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年2月19日 (月)

MySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r161709

ついについに〜〜〜〜〜。　Apple Silicon 対応 VirtualBox Testbuildだけど、Oracle Databaseが起動した。。。。感動のメモ！！！！！

あとは正式版がリリースされてくれれば。。。。嬉し涙 :)

前回までは、毎回、Oracle起動でこけていた。。。

oracle@angelfish ~ % ./print_emv.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:		14.3.1
BuildVersion:		23D60

*** VirtualBox ver. ***
7.0.97_BETA5r161709

[master@localhost ~]$ cat /etc/*release
Oracle Linux Server release 8.5
NAME="Oracle Linux Server"
VERSION="8.5"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.5"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.5"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:5:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://bugzilla.oracle.com/"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.5
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.5
Red Hat Enterprise Linux release 8.5 (Ootpa)
Oracle Linux Server release 8.5
[master@localhost ~]$

Oracle Database 21cが、M2 MBAのVirtualBox TestBuildで起動した！！！！！！！

[master@localhost ~]$ sudo su - oracle
[oracle@localhost ~]$ lsnrctl start

LSNRCTL for Linux: Version 21.0.0.0.0 - Production on 19-2月 -2024 18:50:48

Copyright (c) 1991, 2021, Oracle.  All rights reserved.

/opt/oracle/product/21c/dbhome_1/bin/tnslsnrを起動しています。お待ちください...

TNSLSNR for Linux: Version 21.0.0.0.0 - Production
システム・パラメータ・ファイルは/opt/oracle/homes/OraDBHome21cEE/network/admin/listener.oraです。
ログ・メッセージを/opt/oracle/diag/tnslsnr/localhost/listener/alert/log.xmlに書き込みました。
リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521)))
リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))に接続中
リスナーのステータス
------------------------
別名                      LISTENER
バージョン                TNSLSNR for Linux: Version 21.0.0.0.0 - Production
開始日                    19-2月 -2024 18:50:50
稼働時間                  0 日 0 時間 0 分 1 秒
トレース・レベル          off
セキュリティ              ON: Local OS Authentication
SNMP                      OFF
パラメータ・ファイル      /opt/oracle/homes/OraDBHome21cEE/network/admin/listener.ora
ログ・ファイル            /opt/oracle/diag/tnslsnr/localhost/listener/alert/log.xml
リスニング・エンドポイントのサマリー...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
リスナーはサービスをサポートしていません。
コマンドは正常に終了しました。
[oracle@localhost ~]$ sqlplus / as sysdba

SQL*Plus: Release 21.0.0.0.0 - Production on 月 2月 19 18:50:53 2024
Version 21.3.0.0.0

Copyright (c) 1982, 2021, Oracle.  All rights reserved.

アイドル・インスタンスに接続しました。

SYS@ORCLCDB> startup
ORACLEインスタンスが起動しました。

Total System Global Area  536867744 bytes
Fixed Size                  9687968 bytes
Variable Size             360710144 bytes
Database Buffers           54525952 bytes
Redo Buffers                7086080 bytes
In-Memory Area            104857600 bytes
データベースがマウントされました。
データベースがオープンされました。

SYS@ORCLCDB> 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


経過: 00:00:03.22
SYS@ORCLCDB> shutdown immediate;
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SYS@ORCLCDB> exit
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0との接続が切断されました。
[oracle@localhost ~]$ lsnrctl stop

LSNRCTL for Linux: Version 21.0.0.0.0 - Production on 19-2月 -2024 19:12:48

Copyright (c) 1991, 2021, Oracle.  All rights reserved.

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))に接続中
コマンドは正常に終了しました。
[oracle@localhost ~]$

これまでも起動に成功している、MySQL 8.0.32

[master@localhost ~]$ sudo service mysqld status
Redirecting to /bin/systemctl status mysqld.service
● mysqld.service - MySQL 8.0 database server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2024-02-19 06:48:51 EST; 29min ago
  Process: 1684 ExecStartPost=/usr/libexec/mysql-check-upgrade (code=exited, status=0/SUCCESS)
  Process: 1086 ExecStartPre=/usr/libexec/mysql-prepare-db-dir mysqld.service (code=exited, status=0/SUCCESS)
  Process: 1033 ExecStartPre=/usr/libexec/mysql-check-socket (code=exited, status=0/SUCCESS)
 Main PID: 1125 (mysqld)
   Status: "Server is operational"
    Tasks: 39 (limit: 22947)
   Memory: 310.2M
   CGroup: /system.slice/mysqld.service
           └─1125 /usr/libexec/mysqld --basedir=/usr

 2月 19 06:47:43 localhost.localdomain systemd[1]: Starting MySQL 8.0 database server...
 2月 19 06:47:49 localhost.localdomain mysql-check-socket[1033]: Socket file /var/lib/mysql/mysql.sock exists.
 2月 19 06:47:50 localhost.localdomain mysql-check-socket[1033]: No process is using /var/lib/mysql/mysql.sock, which means it
 is a garbage, so it will be removed automatically.
 2月 19 06:48:51 localhost.localdomain systemd[1]: Started MySQL 8.0 database server.
[master@localhost ~]$ mysql -u scott -D perftestdb -p
Enter password:
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 10
Server version: 8.0.32 Source distribution

Copyright (c) 2000, 2023, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.32    |
+-----------+
1 row in set (0.00 sec)

mysql> exit
Bye
[master@localhost ~]$ sudo service mysqld stop
Redirecting to /bin/systemctl stop mysqld.service
[master@localhost ~]$ sudo service mysqld status
Redirecting to /bin/systemctl status mysqld.service
● mysqld.service - MySQL 8.0 database server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Mon 2024-02-19 07:19:38 EST; 6s ago
  Process: 3634 ExecStopPost=/usr/libexec/mysql-wait-stop (code=exited, status=0/SUCCESS)
  Process: 1684 ExecStartPost=/usr/libexec/mysql-check-upgrade (code=exited, status=0/SUCCESS)
  Process: 1125 ExecStart=/usr/libexec/mysqld --basedir=/usr (code=exited, status=0/SUCCESS)
  Process: 1086 ExecStartPre=/usr/libexec/mysql-prepare-db-dir mysqld.service (code=exited, status=0/SUCCESS)
  Process: 1033 ExecStartPre=/usr/libexec/mysql-check-socket (code=exited, status=0/SUCCESS)
 Main PID: 1125 (code=exited, status=0/SUCCESS)
   Status: "Server shutdown complete"

 2月 19 06:47:43 localhost.localdomain systemd[1]: Starting MySQL 8.0 database server...
 2月 19 06:47:49 localhost.localdomain mysql-check-socket[1033]: Socket file /var/lib/mysql/mysql.sock exists.
 2月 19 06:47:50 localhost.localdomain mysql-check-socket[1033]: No process is using /var/lib/mysql/mysql.sock, which means it
 is a garbage, so it will be removed automatically.
 2月 19 06:48:51 localhost.localdomain systemd[1]: Started MySQL 8.0 database server.
 2月 19 07:19:30 localhost.localdomain systemd[1]: Stopping MySQL 8.0 database server...
 2月 19 07:19:38 localhost.localdomain systemd[1]: mysqld.service: Succeeded.
 2月 19 07:19:38 localhost.localdomain systemd[1]: Stopped MySQL 8.0 database server.
[master@localhost ~]$

同じく、これまでも起動していた PostgresSQL 13.6

[master@localhost ~]$ sudo service postgresql-13 status
Redirecting to /bin/systemctl status postgresql-13.service
● postgresql-13.service - PostgreSQL 13 database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql-13.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/postgresql-13.service.d
           └─local.conf
   Active: active (running) since Mon 2024-02-19 06:47:57 EST; 32min ago
     Docs: https://www.postgresql.org/docs/13/static/
  Process: 1037 ExecStartPre=/usr/pgsql-13/bin/postgresql-13-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
 Main PID: 1062 (postmaster)
    Tasks: 9 (limit: 22947)
   Memory: 20.8M
   CGroup: /system.slice/postgresql-13.service
           ├─1062 /usr/pgsql-13/bin/postmaster -D /pg/pgdata/data
           ├─1084 postgres: logger
           ├─1127 postgres: checkpointer
           ├─1128 postgres: background writer
           ├─1129 postgres: walwriter
           ├─1130 postgres: autovacuum launcher
           ├─1131 postgres: archiver
           ├─1132 postgres: stats collector
           └─1133 postgres: logical replication launcher

 2月 19 06:47:43 localhost.localdomain systemd[1]: Starting PostgreSQL 13 database server...
 2月 19 06:47:50 localhost.localdomain postmaster[1062]: 2024-02-19 06:47:50.576 EST [1062] LOG:  redirecting log output to
 logging collector process
 2月 19 06:47:50 localhost.localdomain postmaster[1062]: 2024-02-19 06:47:50.576 EST [1062] HINT:  Future log output will appear
 in directory "log".
 2月 19 06:47:57 localhost.localdomain systemd[1]: Started PostgreSQL 13 database server.
[master@localhost ~]$ sudo su - postgres
[postgres@localhost ~]$ psql -d perftestdb -U discus -p 5432 -W -h localhost
パスワード：
psql (13.6)
"help"でヘルプを表示します。

perftestdb=> select version();
                                                version
--------------------------------------------------------------------------------------------------------
 PostgreSQL 13.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4), 64-bit
(1 行)

perftestdb=> exit
[postgres@localhost ~]$ exit
ログアウト
[master@localhost ~]$ sudo service postgresql-13 stop
Redirecting to /bin/systemctl stop postgresql-13.service
[master@localhost ~]$ sudo service postgresql-13 status
Redirecting to /bin/systemctl status postgresql-13.service
● postgresql-13.service - PostgreSQL 13 database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql-13.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/postgresql-13.service.d
           └─local.conf
   Active: inactive (dead) since Mon 2024-02-19 07:20:57 EST; 6s ago
     Docs: https://www.postgresql.org/docs/13/static/
  Process: 1062 ExecStart=/usr/pgsql-13/bin/postmaster -D ${PGDATA} (code=exited, status=0/SUCCESS)
  Process: 1037 ExecStartPre=/usr/pgsql-13/bin/postgresql-13-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
 Main PID: 1062 (code=exited, status=0/SUCCESS)

 2月 19 06:47:43 localhost.localdomain systemd[1]: Starting PostgreSQL 13 database server...
 2月 19 06:47:50 localhost.localdomain postmaster[1062]: 2024-02-19 06:47:50.576 EST [1062] LOG:  redirecting log output to
 logging collector process
 2月 19 06:47:50 localhost.localdomain postmaster[1062]: 2024-02-19 06:47:50.576 EST [1062] HINT:  Future log output will appear
 in directory "log".
 2月 19 06:47:57 localhost.localdomain systemd[1]: Started PostgreSQL 13 database server.
 2月 19 07:20:55 localhost.localdomain systemd[1]: Stopping PostgreSQL 13 database server...
 2月 19 07:20:57 localhost.localdomain systemd[1]: postgresql-13.service: Killing process 1084 (postmaster) with signal SIGKILL.
 2月 19 07:20:57 localhost.localdomain systemd[1]: postgresql-13.service: Succeeded.
 2月 19 07:20:57 localhost.localdomain systemd[1]: Stopped PostgreSQL 13 database server.
[master@localhost ~]$

正式版リリースが楽しみです！！

・Oracle Linux 8 and MySQL 8.0.32 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160167
・MySQL 8.0.32 , PostgreSQL 13.4 and Oracle Database 21c on Oracle Linux 8 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160702
・MySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r161342

投稿日時 2024年2月19日 (月) 22時03分 Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年1月27日 (土)

MySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r161342

2024年最初のエントリーは、
VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r161342がアップされていたので、いつもの定点観測です。

結果から言うと、OS起動から、MySQL, PostgreSQLまでは起動する状態にはなっています。最近は、OS毎クラッシュしたかと思うと次のテストビルドでは起動するようになったり、なかなか状況は安定していません。また、Oracleですが、今の所一度も起動せずでした。

グラフィックコントローラーの3Dアクセラレーションを有効化は、OFFにしておいたほうが現状は良さそうです！

久々なので環境情報から
MBA M2とVirtualBox Test Buildは以下の通り

oracle@catfish ~ % sw_vers 
ProductName:		macOS
ProductVersion:		14.3
BuildVersion:		23D56
oracle@catfish ~ % /usr/sbin/system_profiler SPHardwareDataType | grep -E '(Processor|Cores|Memory|Chip|Model Name)'
      Model Name: MacBook Air
      Chip: Apple M2
      Total Number of Cores: 8 (4 performance and 4 efficiency)
      Memory: 24 GB
oracle@catfish ~ % VBoxManage -v
7.0.97_BETA5r161342

[master@localhost etc]$ cat *release*
Oracle Linux Server release 8.5
NAME="Oracle Linux Server"
VERSION="8.5"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.5"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.5"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:5:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://bugzilla.oracle.com/"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.5
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.5
Red Hat Enterprise Linux release 8.5 (Ootpa)
Oracle Linux Server release 8.5
cpe:/o:oracle:linux:8:5:server
[master@localhost etc]$ uname -a
Linux localhost.localdomain 5.4.17-2136.304.4.1.el8uek.x86_64 #2 SMP Tue Feb 8 11:54:24 PST 2022 x86_64 x86_64 x86_64 GNU/Linux

MySQLは以下の通り起動しました。

[master@localhost ~]$ sudo service mysqld status
Redirecting to /bin/systemctl status mysqld.service
● mysqld.service - MySQL 8.0 database server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2024-01-26 21:25:04 EST; 8min ago
  Process: 1699 ExecStartPost=/usr/libexec/mysql-check-upgrade (code=exited, status=0/SUCCESS)
  Process: 1079 ExecStartPre=/usr/libexec/mysql-prepare-db-dir mysqld.service (code=exited, status=0/SUCCESS)
  Process: 1027 ExecStartPre=/usr/libexec/mysql-check-socket (code=exited, status=0/SUCCESS)
 Main PID: 1123 (mysqld)
   Status: "Server is operational"
    Tasks: 38 (limit: 22947)
   Memory: 402.6M
   CGroup: /system.slice/mysqld.service
           └─1123 /usr/libexec/mysqld --basedir=/usr

...略...

[master@localhost ~]$ mysql -u scott -D perftestdb -p 
Enter password: 
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.0.32 Source distribution

Copyright (c) 2000, 2023, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.32    |
+-----------+
1 row in set (0.00 sec)

mysql> exit
Bye
[master@localhost ~]$ sudo service mysqld stop
Redirecting to /bin/systemctl stop mysqld.service
[master@localhost ~]$ sudo service mysqld status
Redirecting to /bin/systemctl status mysqld.service
● mysqld.service - MySQL 8.0 database server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Fri 2024-01-26 21:34:39 EST; 5s ago
  Process: 2914 ExecStopPost=/usr/libexec/mysql-wait-stop (code=exited, status=0/SUCCESS)
  Process: 1699 ExecStartPost=/usr/libexec/mysql-check-upgrade (code=exited, status=0/SUCCESS)
  Process: 1123 ExecStart=/usr/libexec/mysqld --basedir=/usr (code=exited, status=0/SUCCESS)
  Process: 1079 ExecStartPre=/usr/libexec/mysql-prepare-db-dir mysqld.service (code=exited, status=0/SUCCESS)
  Process: 1027 ExecStartPre=/usr/libexec/mysql-check-socket (code=exited, status=0/SUCCESS)
 Main PID: 1123 (code=exited, status=0/SUCCESS)
   Status: "Server shutdown complete"

...略...

PostgreSQLも以下の通り起動した

[master@localhost ~]$ sudo service postgresql-13 status
Redirecting to /bin/systemctl status postgresql-13.service
● postgresql-13.service - PostgreSQL 13 database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql-13.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/postgresql-13.service.d
           └─local.conf
   Active: active (running) since Fri 2024-01-26 21:24:01 EST; 12min ago
     Docs: https://www.postgresql.org/docs/13/static/
  Process: 1033 ExecStartPre=/usr/pgsql-13/bin/postgresql-13-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
 Main PID: 1060 (postmaster)
    Tasks: 9 (limit: 22947)
   Memory: 23.3M
   CGroup: /system.slice/postgresql-13.service
           ├─1060 /usr/pgsql-13/bin/postmaster -D /pg/pgdata/data
           ├─1080 postgres: logger 
           ├─1127 postgres: checkpointer 
           ├─1128 postgres: background writer 
           ├─1129 postgres: walwriter 
           ├─1130 postgres: autovacuum launcher 
           ├─1131 postgres: archiver 
           ├─1132 postgres: stats collector 
           └─1134 postgres: logical replication launcher 

...略...

[master@localhost ~]$ sudo su - postgres
[postgres@localhost ~]$ psql -d perftestdb -U discus -p 5432 -W -h localhost
パスワード： 
psql (13.6)
"help"でヘルプを表示します。

perftestdb=> select version();
                                                version                                                 
--------------------------------------------------------------------------------------------------------
 PostgreSQL 13.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4), 64-bit
(1 行)

perftestdb=> exit
[postgres@localhost ~]$ exit
ログアウト
[master@localhost ~]$ sudo service postgresql-13 stop
Redirecting to /bin/systemctl stop postgresql-13.service
[master@localhost ~]$ sudo service postgresql-13 status
Redirecting to /bin/systemctl status postgresql-13.service
● postgresql-13.service - PostgreSQL 13 database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql-13.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/postgresql-13.service.d
           └─local.conf
   Active: inactive (dead) since Fri 2024-01-26 21:37:12 EST; 5s ago
     Docs: https://www.postgresql.org/docs/13/static/
  Process: 1060 ExecStart=/usr/pgsql-13/bin/postmaster -D ${PGDATA} (code=exited, status=0/SUCCESS)
  Process: 1033 ExecStartPre=/usr/pgsql-13/bin/postgresql-13-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
 Main PID: 1060 (code=exited, status=0/SUCCESS)
...略...

残念ながら、今回のテストビルトでも、Oracleは起動せず。リスナーはいつも通り起動しますが。

[oracle@localhost ~]$ lsnrctl start

LSNRCTL for Linux: Version 21.0.0.0.0 - Production on 27-1月 -2024 12:01:04

Copyright (c) 1991, 2021, Oracle.  All rights reserved.

/opt/oracle/product/21c/dbhome_1/bin/tnslsnrを起動しています。お待ちください...

TNSLSNR for Linux: Version 21.0.0.0.0 - Production
システム・パラメータ・ファイルは/opt/oracle/homes/OraDBHome21cEE/network/admin/listener.oraです。
ログ・メッセージを/opt/oracle/diag/tnslsnr/localhost/listener/alert/log.xmlに書き込みました。
リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521)))
リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))に接続中
リスナーのステータス
------------------------
別名                      LISTENER
バージョン                TNSLSNR for Linux: Version 21.0.0.0.0 - Production
開始日                    27-1月 -2024 12:01:04
稼働時間                  0 日 0 時間 0 分 1 秒
トレース・レベル          off
セキュリティ              ON: Local OS Authentication
SNMP                      OFF
パラメータ・ファイル      /opt/oracle/homes/OraDBHome21cEE/network/admin/listener.ora
ログ・ファイル            /opt/oracle/diag/tnslsnr/localhost/listener/alert/log.xml
リスニング・エンドポイントのサマリー...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
リスナーはサービスをサポートしていません。
コマンドは正常に終了しました。
[oracle@localhost ~]$ sqlplus / as sysdba

SQL*Plus: Release 21.0.0.0.0 - Production on 土 1月 27 12:01:09 2024
Version 21.3.0.0.0

Copyright (c) 1982, 2021, Oracle.  All rights reserved.

アイドル・インスタンスに接続しました。

SYS@ORCLCDB> startup
ORA-03113: 通信チャネルでend-of-fileが検出されました

もう一息なのかどうかわかりませんが、Oracleも起動してくれることを、期待しつつ、定点観測は続く :)
今年中に起動するようになってくれると嬉しいですよね。

ではまた:)

投稿日時 2024年1月27日 (土) 14時57分 Oracle, Mac, VirtualBox, MySQL, PostgreSQL, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2023年12月13日 (水)

MySQL 8.0.32 , PostgreSQL 13.4 and Oracle Database 21c on Oracle Linux 8 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160702

予定外ですが、Advent Calendarのシーズンついでなので、空いていた以下のアドベントカレンダー向けエントリーとなります。
Kernel/VM Advent Calendar 2023 / Day 13

macOS / ARM64 Beta development revision 160702
https://www.virtualbox.org/wiki/Testbuilds

以前、Oracle Linux 8 and MySQL 8.0.32 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160167で、MySQL 8.0.32が起動した！と言うことを書きましたが、その後のBETAリリースではOS起動中にクラッシュしていました。
で、今回は、development revision 160702をダメもとで試してみました。

結果から書くと、色々もっさりしているのは仕方ないかないところですが、このrevisionでは、MySQLに加えて、PostgreSQLも起動しました！！！

VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160702
GuestOS : Oracle Linux Server release 8.5
MySQL 8.0.32 - 起動した！
PostgreSQL 13.4 - 起動した！
Oracle database 21c - 起動せず！

試した内容は前回と同じですが、Oracleについては変えています。
1) Oracle Linux 8.5 に、PostgreSQL 13.4 と MySQL 8.0.32 を構成したVMをエクスポートして ova 作成
2) 1)のOracle Linux 8.5 に、Oracle Database 21cを構成したものを ova としてエクスポート。
それぞれをVirtualBoxへインポートして検証しました。

ちなみに、
Oracle Linux 7.6のPre-Built Developer VMs (for Oracle VM VirtualBox) および、Oracle Linux 8.6に構築したOracle 23c Freeは、OS起動にクラッシュしていたので、うまく起動した1)を利用して、OS起動後にOracleの挙動を確認する方法にしましたが、Oracleがコケたと言う結果となりました。

Test Buildは、結構進んできているようで、今後が楽しみです ;)

では、また。

投稿日時 2023年12月13日 (水) 17時05分 Oracle, Linux, VirtualBox, MySQL, PostgreSQL, Advent Calendar, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2023年11月17日 (金)

Oracle Linux 8 and MySQL 8.0.32 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160167

ということで、ちょっと一休み的なネタです。

Apple Silicon対応はほぼ諦めていたVirtualBoxが 7.0でBETA版をリリースして大喜びしてたわけですが、
7.0.12でも正常に起動してくれないですよね。まだ。
ただ、表には出てこないですが、Test Buildでは結構進んでいるようで、嬉しいお知らせです。:)

まだ、Oracle Databaseとかは起動しないようですが、最新のTest Buildをダメ元で試してみたら、Oracle Linux 8とMySQL 8.0.32の組み合わせならDBのお遊びに使えそうな状況（次のBuild ではどうなるかわかりませんが）であることに気づきました。確実に進捗してそうで一安心。

新規VM作成ではなく、以下の手順で簡易に確認してみました。

macOS/Intel MBAのVirtualBoxにて、以下、2つのovaを作成し、M2 MBAのTest Build最新版のVirtualBoxへインポートして動作するかどうかを確認

1) Oracle Linux 8 に、PostgreSQL 13.4 と MySQL 8.0.32 を構成したVMをエクスポートして ova 作成
2) Oracle Linux 8 に、Oracle 23c Free Developer Editionを構成していたVMをエクスポートして ova 作成

結果は、
1)のMySQLは起動成功、
1)のMySQLは起動成功、
PostgreSQLは起動できず。
2)はOSは起動したがOracle起動中にエラーでVM停止

という状況。

でも、MySQL 8.0.32が、M2 MBAのVirtualBoxで使えるようになっているのはかなりの進捗なのではないかと思います。そもそもApple SiliconでVirtualBoxインストールできなくなったりしていた悲しい時期から比べれば。
いずれ、Oracleが起動するようになってくれることを期待しつつ。。Advent Calendarの記事を考えよう :)

以下、軽めの確認ログとスクリーンショットなど。

VirtualBox Test Build 7.0.97 BETA5

OVAインポート成功後、OSは正常に起動したものの、PostgreSQL 13.4 は起動失敗。 MySQL 8.0.32は起動成功！。

Oracle Database 23c Free Developer Editionを構成したovaインポート後、Database起動中にfatal errorでVM停止。惜しいね。

MySQL 8.0.32 on Oracle Linux 8.5 on VirtualBox Test Build 7.0.97 BETA5 for macOS/M1/M2でMySQLへ接続！

VirtualBoxホストの情報 M2 MBAです。

leaffish ~ % /usr/sbin/system_profiler SPHardwareDataType | grep -E '(Processor|Cores|Memory|Chip|Model Name)'
      Model Name: MacBook Air
      Chip: Apple M2
      Total Number of Cores: 8 (4 performance and 4 efficiency)
      Memory: 24 GB

VirtualBoxは、Text Build最新(17-Nov-2023)

VirtualBox test builds
https://www.virtualbox.org/wiki/Testbuilds より、macOS/ARM64 BETAとExtension Packを利用

leaffish ~ % VBoxManage -v
7.0.97_BETA5r160167

M2 MBAのTerminalからsshでローカルのVMへ。 M2 MBAのVirtualBox Guest OSは、Oracle Linux 8.5 です。起動してますね！

leaffish ~ % ssh master@192.168.1.117
master@192.168.1.117's password:
Activate the web console with: systemctl enable --now cockpit.socket

[master@localhost ~]$
[master@localhost ~]$ cat /etc/oracle-release
Oracle Linux Server release 8.5

[master@localhost ~]$ cat /etc/redhat-release
Red Hat Enterprise Linux release 8.5 (Ootpa)
[master@localhost ~]$

起動しているのは確認できましたが、MySQLへ接続してSQLを実行するまでが確認！
おおおおおおおおーーーーーーっ！。

MySQL 8.0.32 on Oracle Linux 8.5 on M2 MacBook Air VirtualBox　。Oracle Databaseではないけど、うれしくて涙が。。。出ますね。これ。

[master@localhost ~]$ mysql -u scott -D perftestdb -p 
Enter password:
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.0.32 Source distribution

Copyright (c) 2000, 2023, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| performance_schema |
| perftestdb         |
+--------------------+
3 rows in set (0.02 sec)

mysql> show tables;
+----------------------+
| Tables_in_perftestdb |
+----------------------+
| detail               |
| hoge                 |
| master               |
| t0                   |
| t1                   |
| t1017                |
| t1017_2              |
| t2                   |
| t3                   |
| t4                   |
+----------------------+
10 rows in set (0.07 sec)

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.32    |
+-----------+
1 row in set (0.00 sec)

mysql> select * from t1;
+----+-------+
| id | t1_c1 |
+----+-------+
|  1 |     1 |
|  2 |     2 |
|  3 |     3 |
|  4 |     4 |
|  5 |     5 |
|  6 |     6 |
|  7 |     7 |
|  8 |     8 |
|  9 |     9 |
| 10 |    10 |
+----+-------+
10 rows in set (0.04 sec)

mysql> exit
Bye

ついでなので、停止も試しておきましょう:)

[master@localhost ~]$ sudo service mysqld stop
[[sudo] master のパスワード:
Redirecting to /bin/systemctl stop mysqld.service
[master@localhost ~]$ sudo shutdown -h now
Connection to 192.168.1.117 closed by remote host.
Connection to 192.168.1.117 closed.
leaffish ~ %

週末天気悪そうで、Walkingできないかもしれない。。..

では、また。

投稿日時 2023年11月17日 (金) 12時00分 Oracle, Mac, Linux, VirtualBox, MySQL, PostgreSQL, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

DROP SHADOW CTRL

GaragebandとiMovieで

検索

Twitter

最近の記事

最近のコメント

最近のトラックバック

カテゴリー

Oracle

Apple

その他

Googleの広告

RSS

当サイトについて

2026年6月13日 (土)

2026年6月 9日 (火)

2026年5月 9日 (土)

2026年4月10日 (金)

2026年3月22日 (日)

2026年3月10日 (火)

2026年2月 8日 (日)

2026年2月 5日 (木)

2026年2月 4日 (水)

2026年2月 3日 (火)

2026年1月27日 (火)

2026年1月 8日 (木)

2025年12月 3日 (水)

2025年11月 2日 (日)

2025年10月 2日 (木)

2025年9月 3日 (水)

2025年8月29日 (金)

2025年8月 2日 (土)

2025年7月 2日 (水)

2025年6月 2日 (月)

2025年5月 3日 (土)

2025年4月 8日 (火)

2025年3月 2日 (日)

2025年2月 2日 (日)

2025年1月 2日 (木)

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日 (日)

2024年11月 1日 (金)

2024年10月 2日 (水)

2024年9月 7日 (土)

2024年9月 1日 (日)

2024年8月16日 (金)

2024年8月 8日 (木)

2024年8月 3日 (土)

2024年7月 8日 (月)

2024年7月 6日 (土)

2024年6月23日 (日)

2024年6月15日 (土)

2024年6月 3日 (月)

2024年5月31日 (金)

2024年5月 9日 (木)

2024年5月 7日 (火)

2024年5月 4日 (土)