explain plan文 De 索引サイズ見積 / FAQ

久々の投稿ですw

というか、Oracle ACEのKPIを考えるとどうしても、こうなってしまう大人の事情。

今期一発目の投稿は、意外と知られていない？　explain plan文 De 索引サイズ見積。

統計情報などに依存はしますが、100億年に一度ぐらい、索引サイズどれぐらいになるかねぇ。みたいな聞かれかたしたときに、サクっとタイプして、ほれ！

と、Slackでなげかえしちゃって、飲みに行きましょうね。そこ必死にやるところじゃない時代なわけで。

では、21cもあるのですが、データ仕込むのめんどくさかったので、ありもの 19cの環境で試してみましょう。ちなみに、explain plan で索引サイズを見積もるのは私の記憶によると10gぐらいから使ってた記憶はあるので、昔からのOraclerだと知ってる方は多いはず。(もっと前からあるよーというツッコミ歓迎w）

表の存在とデータを大量に登録してあるtest表を使います。統計は最新化

[oracle@localhost ~]$ sqlplus scott/tiger

SQL*Plus: Release 19.0.0.0.0 - Production on Wed Jun 29 22:59:46 2022
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Last Successful login time: Mon Jun 06 2022 21:39:58 -04:00

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0

SQL> desc test
Name　　　Null?                    Type
-------  ------------------------ -------- ----------------------------
NUM      NUMBER

SQL> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'TEST',cascade=>true,no_invalidate=>false);

PL/SQL procedure successfully completed.

explain plan文でcreate index文を解析します。索引は作成されないので、躊躇なくタイプしちゃってくださいw
解析が終わったら、utlxpls.sqlを実行すれば見積もりサイズを確認できます。

10m行登録してるのでそれなりのサイズになるようですね。243MB という見積もりがでました！

SQL> explain plan for create index test on test(num);

Explained.

SQL> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 2829245909

-------------------------------------------------------------------------------
| Id  | Operation              | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | CREATE INDEX STATEMENT |      |    10M|    57M|  9958  (1) | 00:00:01 |
|   1 |  INDEX BUILD NON UNIQUE| TEST |       |       |            |          |
|   2 |   SORT CREATE INDEX    |      |    10M|    57M|            |          |
|   3 |    TABLE ACCESS FULL   | TEST |    10M|    57M|  4414  (2) | 00:00:01 |
-------------------------------------------------------------------------------

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Note
-----
- estimated index size: 243M bytes

14 rows selected.

SQL>

Explain plan文以外では、使い勝手が悪いというかタイプする文字数多くて嫌いな、DBMS_SPACE.CREATE_INDEX_COST()　があります。
以下のような無名PL/SQLブロックを書いておくか、あらかじめ俺俺関数(UDFね)として登録しておくと便利ですが、explain planでいいかなぁ。私はw

set serveroutput on
DECLARE
  used_bytes NUMBER;
  segment_bytes NUMBER;
BEGIN
  DBMS_SPACE.CREATE_INDEX_COST (
    ddl=> 'CREATE INDEX test ON test(num)'
    , used_bytes => used_bytes
    , alloc_bytes =>  segment_bytes
  );
  DBMS_OUTPUT.PUT_LINE('Segment Size (MB) :'||segment_bytes/1024/1024);
  DBMS_OUTPUT.PUT_LINE('Index data Size (MB) :'||used_bytes/1024/1024);
END;
/

Explain planより情報量は多いですが、セグメントサイズがどれぐらいになるか知りたいわけなので、他の情報は捨てちゃうことが多い感じはします。
DBMS_SPACE.CREATE_INDEX_COST()パッケージプロシージャでは 232MB という見積もり結果となりました。

SQL> set serveroutput on
SQL> l
  1  DECLARE
  2    used_bytes NUMBER;
  3    segment_bytes NUMBER;
  4  BEGIN
  5    DBMS_SPACE.CREATE_INDEX_COST (
  6    ddl=> 'CREATE INDEX test ON test(num)'
  7    , used_bytes => used_bytes
  8    , alloc_bytes =>  segment_bytes
  9    );
 10    DBMS_OUTPUT.PUT_LINE('Segment Size (MB) :'||segment_bytes/1024/1024);
 11    DBMS_OUTPUT.PUT_LINE('Index data Size (MB) :'||used_bytes/1024/1024);
 12* END;
SQL> /
Segment Size (MB) :232
Index data Size (MB) :57.220458984375

PL/SQL procedure successfully completed.

SQL>

実際のセグメントサイズはどれぐらいでしょう？　実際に索引を作ったあとセグメントサイズをみてみました。

SQL> select segment_name,bytes/1024/1024 "MB" from user_segments where segment_name='TEST' and segment_type='INDEX';

SEGMENT_NAME                   MB
------------------------------ ----------
TEST                           192

SQL>

---

今年も半年すぎたけど、アドベントカレンダー全部俺をやるべきか悩む。まとめてアウトプットするので、ちびちびアウトプットするのとどちらがよいか。。。w

では、また。

古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #13

随分間が空いてしまったのです、覚えてますかねw　前回のネタ。私もほぼ忘れてました　orz. w

思い出しながら進めましょう:)

Previously on Mac De Oracle
前回は、CTASだと、内部的にdirect path writeされてしまうのでクリーンアウトが必要な状況にはならないという動きを確認しました。

scattered read同様に、sequential readだとどうなの？（という遠くから声が聞こえたきがしたのでw）

とはいえ、遅延ブロッククリーンアウトって、自分の理解だと、全表走査時の動きだと思っているので、多分、起きないよなーと。頭の上に雲型の吹き出した出た状態でイメージしているところ。

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

これまでと異なる箇所は、sequential read　でぐるぐるループさせたいので、該当表に主キー索引を作成します。また、table full scanではなく、index unique scan で全行アクセスさせてみます。（この動きが大きく異なる部分です）

---

---

strong>0) 対象表のdrop/create と主キー作成
対象表のHOGE2は削除して作り直し。このテストケースでは主キーアクセスさせるため、合わせて主キーも作成しておきます。

SCOTT@orcl> @droppurge_create_hoge2_with_pk.sql
  1* drop table hoge2 purge

Table dropped.

Elapsed: 00:00:00.51
  1* create table hoge2 (id number, data varchar2(2000), constraint pk_hoge2 primary key (id) using index)

Table created.

Elapsed: 00:00:00.07
  1* select segment_name,blocks from user_segments where segment_name like '%HOGE2%'

no rows selected

Elapsed: 00:00:00.13

1) 統計をクリアするためOracle再起動

$ sudo service oracle restart


[sudo] password for oracle:


Restarting oracle (via systemctl):                         [  OK  ]

2) PDBのscottでログインしてclient_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。

SCOTT@orcl> @set_client_info
  1  begin
  2     DBMS_APPLICATION_INFO.SET_CLIENT_INFO('Target Session');
  3* end;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.00
SCOTT@orcl>

3) CDBのSYSで統計取得（初回）
内容は省略！ （思い出したいかたはこの辺りを参照ください。。

4) PDBのSCOTTユーザーでNOAPPENDヒント付きIASを実行（データサイズは、コミットクリーンアウトではクリーンアウト仕切れないサイズ）／　未コミット

NOAPPENDヒントを利用している理由は前回までの内容を見ていただければわかりますが、direct path writeさせたないためです。これによりコミットクリーンアウトではクリーンアウトできない状況、つまり、遅延ブロッククリーンアウトが必要となる状態を作っています。

SCOTT@orcl> @ias_noappend_from_hoge.sql
  1* insert /*+ noappend */ into hoge2 select * from hoge

200000 rows created.

Elapsed: 00:00:19.63
14:32:40 SCOTT@orcl>

5) CDBのSYSで統計取得（未コミット）

検証中に統計値が変動したもののみ記載

狙い通りdirect path writeは抑止できていることは確認できます。
(CDB）システム統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sysstat	DBWR checkpoint buffers written                               22,918
sysstat	DBWR checkpoints                                                  72
sysstat	DBWR thread checkpoint buffers written                        22,918
sysstat	DBWR transaction table writes                                     22
sysstat	DBWR undo block writes                                           983
sysstat	cleanouts only - consistent read gets                              0
sysstat	commit cleanout failures: block lost                               0
sysstat	commit cleanout failures: callback failure                         0
sysstat	commit cleanouts                                               1,601
sysstat	commit cleanouts successfully completed                        1,601
sysstat	consistent gets                                              122,604
sysstat	db block changes                                             564,554
sysstat	deferred (CURRENT) block cleanout applications                    12
sysstat	free buffer requested                                         70,607
sysstat	immediate (CR) block cleanout applications                         0
sysstat	immediate (CURRENT) block cleanout applications                1,752
sysstat	no work - consistent read gets                                67,108
sysstat	physical reads                                                66,750
sysstat	physical reads direct                                         66,709
sysstat	physical writes                                               22,918
sysstat	physical writes from cache                                    22,918
sysstat	physical writes non checkpoint                                22,918
sysstat	redo blocks written                                          967,108
sysstat	redo size                                                479,412,088
sysstat	redo writes                                                      378

(PDB)　SCOTTのセッション統計
こちらから見てもdirect path writeは発生していません

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sesstat	cleanouts only - consistent read gets                              0
sesstat	commit cleanout failures: block lost                               0
sesstat	commit cleanouts                                               1,589
sesstat	commit cleanouts successfully completed                        1,589
sesstat	consistent gets                                              122,204
sesstat	db block changes                                             564,506
sesstat	deferred (CURRENT) block cleanout applications                     7
sesstat	free buffer requested                                         70,595
sesstat	immediate (CR) block cleanout applications                         0
sesstat	immediate (CURRENT) block cleanout applications                1,748
sesstat	no work - consistent read gets                                66,884
sesstat	physical reads                                                66,740
sesstat	physical reads direct                                         66,709
sesstat	redo size                                                478,945,336

該当期間の待機イベント記録されていないですよね。狙い通りなので準備としては問題なしです。

EVENT                                                            WAIT_CLASS
---------------------------------------------------------------- -----------------
SQL*Net message from client                                      Idle
log buffer space                                                 Configuration
events in waitclass Other                                        Other
direct path read                                                 User I/O
log file switch (private strand flush incomplete)                Configuration
log file switch completion                                       Configuration
log file sync                                                    Commit
db file sequential read                                          User I/O
SQL*Net message to client                                        Network
Disk file operations I/O                                         User I/O
db file scattered read                                           User I/O

6) CDB or PDBのSYSユーザで接続し、buffer cacheをflushする

SYS@orclcdb> @flush_buffercache.sql
  1* alter system flush buffer_cache

System altered.

Elapsed: 00:00:09.04
14:36:26 SYS@orclcdb>

7) CDBのSYSで統計取得（buffer cacheをflush後）
strong>(CDB）システム統計
検証中に統計値が変動したもののみ記載

バッファキャッシュをフラッシュしたのでキャッシュから書き出されたことを示す　physical writes from cache　および関連する統計値が上昇しています。これも想定通りの挙動ですね。

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sysstat	DBWR checkpoint buffers written                                    0
sysstat	DBWR checkpoints                                                   0
sysstat	DBWR thread checkpoint buffers written                             0
sysstat	DBWR transaction table writes                                      8
sysstat	DBWR undo block writes                                          1912
sysstat	cleanouts only - consistent read gets                              0
sysstat	commit cleanout failures: block lost                               0
sysstat	commit cleanout failures: callback failure                         0
sysstat	commit cleanouts                                                  43
sysstat	commit cleanouts successfully completed                           43
sysstat	consistent gets                                                20793
sysstat	db block changes                                                 429
sysstat	deferred (CURRENT) block cleanout applications                    21
sysstat	free buffer requested                                           1013
sysstat	immediate (CR) block cleanout applications                         0
sysstat	immediate (CURRENT) block cleanout applications                    9
sysstat	no work - consistent read gets                                 12321
sysstat	physical reads                                                   977
sysstat	physical reads direct                                              0
sysstat	physical writes                                                47900
sysstat	physical writes from cache                                     47900
sysstat	physical writes non checkpoint                                 47900
sysstat	redo blocks written                                             2017
sysstat	redo size                                                     994652
sysstat	redo writes                                                       23

(PDB)　SCOTTのセッション統計

キャッシュをフラッシュしただけなので、該当セッションの統計には変化がありません。（まあ、そうですよねw）

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sesstat	cleanouts only - consistentread gets                              0
sesstat	commit cleanout failures: block lost                               0
sesstat	commit cleanouts                                                   0
sesstat	commit cleanouts successfully completed                            0
sesstat	consistent gets                                                    0
sesstat	db block changes                                                   0
sesstat	deferred (CURRENT) block cleanout applications                     0
sesstat	free buffer requested                                              0
sesstat	immediate (CR) block cleanout applications                         0
sesstat	immediate (CURRENT) block cleanout applications                    0
sesstat	no work - consistent read gets                                     0
sesstat	physical reads                                                     0
sesstat	physical reads direct                                              0
sesstat	physical writes                                                    0
sesstat	physical writes direct                                             0
sesstat	physical writes from cache                                         0
sesstat	physical writes non checkpoint                                     0
sesstat	redo blocks written                                                0
sesstat	redo size                                                          0

8) PDBのSCOTTユーザーでコミットの実行

SCOTT@orcl> commit;

Commit complete.

Elapsed: 00:00:00.01

9) CDBのSYSで統計取得（コミット後）
strong>(CDB）システム統計
コミット時点ではクリーンアウト仕切れないほどの更新ブロック数かつ、コミット前にバッファキャッシュをフラッシュしているので、コミット時のクリーンアウトもできない状態なっています（これも事前の準備の通りの結果。なので問題なし）
commit cleanouts　と　commit cleanout failures: block lost　がポイントです。コミット時にクリーンアウトできる量（過去の記事を参照のこと）の閾値以下の量ですら、事前にキャッシュからフラッシュしまっているので、クリーンアウトに失敗（できないようにしたので当然ですが）しています。両方の統計値が同一であるとくことは、コミットクリーンアウトしようとした全てでくりアウトできなかった。理由はキャッシュに該当ブロックがキャッシュから落ちていたから（意図的に落としたわけですが）ということを意味します。予定通りですね。

コミットの時点で最低現おこなうクリーンアウトもさせていないですが、このケースでは　11140　ブロックをコミット時にクリーンアウトしようとしているので、コミット時のクリーンアウトが行われていたとしても　50,000 ブロック以上は遅延されていたことになりますね。今回は、　66,667　ブロックがク後続のSQLで参照されるついでにクリーンアウトされることになります。

検証中に統計値が変動したもののみ記載

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sysstat	DBWR checkpoint buffers written                                    0
sysstat	DBWR checkpoints                                                   0
sysstat	DBWR thread checkpoint buffers written                             0
sysstat	DBWR transaction table writes                                      0
sysstat	DBWR undo block writes                                             0
sysstat	cleanouts only - consistent read gets                              0
sysstat	commit cleanout failures: block lost                           11140
sysstat	commit cleanout failures: callback failure                         0
sysstat	commit cleanouts                                               11140
sysstat	commit cleanouts successfully completed                            0
sysstat	consistent gets                                                   34
sysstat	db block changes                                                   1
sysstat	deferred (CURRENT) block cleanout applications                     0
sysstat	free buffer requested                                              8
sysstat	immediate (CR) block cleanout applications                         0
sysstat	immediate (CURRENT) block cleanout applications                    0
sysstat	no work - consistent read gets                                     5
sysstat	physical reads                                                     8
sysstat	physical reads direct                                              0
sysstat	physical writes                                                    0
sysstat	physical writes from cache                                         0
sysstat	physical writes non checkpoint                                     0
sysstat	redo blocks written                                                3
sysstat	redo size                                                        456
sysstat	redo writes                                                        3

(PDB)　SCOTTのセッション統計
セッションレベルでみるよりはっきり見るとことができます。

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sesstat	cleanouts only - consistent read gets                              0
sesstat	commit cleanout failures: block lost                           11140
sesstat	commit cleanouts                                               11140
sesstat	commit cleanouts successfully completed                            0
sesstat	consistent gets                                                    0
sesstat	db block changes                                                   1
sesstat	deferred (CURRENT) block cleanout applications                     0
sesstat	free buffer requested                                              1
sesstat	immediate (CR) block cleanout applications                         0
sesstat	immediate (CURRENT) block cleanout applications                    0
sesstat	no work - consistent read gets                                     0
sesstat	physical reads                                                     1
sesstat	physical reads direct                                              0
sesstat	physical writes                                                    0
sesstat	physical writes direct                                             0
sesstat	physical writes from cache                                         0
sesstat	physical writes non checkpoint                                     0
sesstat	redo blocks written                                                0
sesstat	redo size                                                        176

10) PDBのSCOTTユーザーで遅延ブロッククリーンアウト有無確認（対象表を主キーによる一意検索で全行アクセス）

さて、事前に想定している実行計画になっているかプランだけ確認しておきましょう。主キーによる索引ユニークスキャンであることが確認できます。想定通りです。この実行計画で、200,000 行をグルグル参照した場合、遅延されたブロッククリーンアウトが行われるでしょうか。。。。（してくれないと思いますが。。。試してみましょう）

SCOTT@orcl> set autot trace exp
14:41:47 SCOTT@orcl> select * from hoge2 where id = 1;
Elapsed: 00:00:00.00

Execution Plan
----------------------------------------------------------
Plan hash value: 3319133482

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

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

   2 - access("ID"=1)

SCOTT@orcl> set autot off
SCOTT@orcl>
SCOTT@orcl> @table_unique_scan_hoge2.sql
  1  begin
  2    for i in 1..&1 loop
  3      for hoge2_rec in (select * from hoge2 where id = i) loop
  4        null;
  5      end loop;
  6    end loop;
  7* end;
Enter value for 1: 200000
old   2:   for i in 1..&1 loop
new   2:   for i in 1..200000 loop

PL/SQL procedure successfully completed.

Elapsed: 00:00:14.94
14:39:36 SCOTT@orcl>

11) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認。対象表を主キーによる一意検索で全行アクセス）
strong>(CDB）システム統計

クリーンアウトが行われていれば、データブロックの総数　66,667　ブロックは少なくともクリーンアップの対象になっているはずですが。。。。。
cleanout系の統計値に動きはありませんよね。

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sysstat	DBWR checkpoint buffers written                                   21
sysstat	DBWR checkpoints                                                   0
sysstat	DBWR thread checkpoint buffers written                             0
sysstat	DBWR transaction table writes                                      5
sysstat	DBWR undo block writes                                             5
sysstat	cleanouts only - consistent read gets                              0
sysstat	commit cleanout failures: block lost                               0
sysstat	commit cleanout failures: callback failure                        15
sysstat	commit cleanouts                                                 366
sysstat	commit cleanouts successfully completed                          351
sysstat	consistent gets                                               632775
sysstat	db block changes                                                7848
sysstat	deferred (CURRENT) block cleanout applications                   169
sysstat	free buffer requested                                          76662
sysstat	immediate (CR) block cleanout applications                         0
sysstat	immediate (CURRENT) block cleanout applications                  169
sysstat	no work - consistent read gets                                 21822
sysstat	physical reads                                                 69501
sysstat	physical reads direct                                              0
sysstat	physical writes                                                   21
sysstat	physical writes from cache                                        21
sysstat	physical writes non checkpoint                                    10
sysstat	redo blocks written                                             5132
sysstat	redo size                                                    2536084
sysstat	redo writes                                                       28

(PDB)　SCOTTのセッション統計

physical reads は、67706 ブロックなのでほ、HOGE2表の索引と表のセグメントサイズほどは物理読み込みされたということになります。ただ、cleanouts only - consistent read gets　などのクリーンアウトを示す統計値はほぼ動いていません。ようするに、db file sequential readとなる index unique scan　ではブロッククリーンアウトは発生しないということを意味しています。

おおおーーー。だったら、グルグル系の処理で一行ごとに処理するのが最高じゃん！　という単純な話ではないので要注意ですからねw

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sesstat	cleanouts only - consistent read gets                              0
sesstat	commit cleanout failures: block lost                               0
sesstat	commit cleanouts                                                   4
sesstat	commit cleanouts successfully completed                            4
sesstat	consistent gets                                               600005
sesstat	db block changes                                                  14
sesstat	deferred (CURRENT) block cleanout applications                     2
sesstat	free buffer requested                                          74540
sesstat	immediate (CR) block cleanout applications                         0
sesstat	immediate (CURRENT) block cleanout applications                    2
sesstat	no work - consistent read gets                                     0
sesstat	physical reads                                                 67706
sesstat	physical reads direct                                              0
sesstat	physical writes                                                    0
sesstat	physical writes direct                                             0
sesstat	physical writes from cache                                         0
sesstat	physical writes non checkpoint                                     0
sesstat	redo blocks written                                                0
sesstat	redo size                                                       2152

10) PDBのSCOTTユーザーで遅延ブロッククリーンアウト有無確認（sacattered read）

single block readを行うindex unique scanではクリーンアウトが発生しなかったということは、全表走査させる table full scan かつ scattered readさせれば発生するのではないでしょうか？　という確認です。
auto traceで統計情報をみると、なにやら、REDOログが大量に生成されてますよね。。。これは！！！

SCOTT@orcl> @table_full_scan_hoge2.sql
  1* alter session set "_serial_direct_read" = never

Session altered.

Elapsed: 00:00:00.01
  1* alter session set "_very_large_object_threshold" = 20400

Session altered.

Elapsed: 00:00:00.00
set autot trace exp stat

  1* select * from hoge2

200000 rows selected.

Elapsed: 00:00:06.55

Execution Plan
----------------------------------------------------------
Plan hash value: 1530105727

---------------------------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |   172K|   167M| 18223   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| HOGE2 |   172K|   167M| 18223   (1)| 00:00:01 |
---------------------------------------------------------------------------

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


Statistics
----------------------------------------------------------
         10  recursive calls
          1  db block gets
     147157  consistent gets
        377  physical reads
    5866968  redo size
  406775148  bytes sent via SQL*Net to client
     147265  bytes received via SQL*Net from client
      13335  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     200000  rows processed

set autot off

14:56:56 SCOTT@orcl>

11) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認。対象表を主キーによる一意検索で全行アクセス）
strong>(CDB）システム統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sysstat	DBWR checkpoint buffers written                                 1121
sysstat	DBWR checkpoints                                                   0
sysstat	DBWR thread checkpoint buffers written                             0
sysstat	DBWR transaction table writes                                     36
sysstat	DBWR undo block writes                                           347
sysstat	cleanouts only - consistent read gets                          66676
sysstat	commit cleanout failures: block lost                               0
sysstat	commit cleanout failures: callback failure                         0
sysstat	commit cleanouts                                                 806
sysstat	commit cleanouts successfully completed                          806
sysstat	consistent gets                                               174296
sysstat	db block changes                                               80773
sysstat	deferred (CURRENT) block cleanout applications                   383
sysstat	free buffer requested                                           2095
sysstat	immediate (CR) block cleanout applications                     66676
sysstat	immediate (CURRENT) block cleanout applications                   75
sysstat	no work - consistent read gets                                 27953
sysstat	physical reads                                                  1842
sysstat	physical reads direct                                              0
sysstat	physical writes                                                 1121
sysstat	physical writes from cache                                      1121
sysstat	physical writes non checkpoint                                   981
sysstat	redo blocks written                                            16550
sysstat	redo size                                                    8074260
sysstat	redo writes                                                      351

(PDB)　SCOTTのセッション統計
HOGE2の表のクリーンアウト対象ブロック数、66,667　きっちり同じ数字が現れました。しかも cleanoutに関わる統計でかつ、大量のREDOログも生成されています。でました〜〜〜w　クリーンアウト。全表走査かつ、scattered readで。

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sesstat	cleanouts only - consistent read gets                          66667
sesstat	commit cleanout failures: block lost                               0
sesstat	commit cleanouts                                                   1
sesstat	commit cleanouts successfully completed                            1
sesstat	consistent gets                                               153731
sesstat	db block changes                                               66718
sesstat	deferred (CURRENT) block cleanout applications                     0
sesstat	free buffer requested                                            690
sesstat	immediate (CR) block cleanout applications                     66667
sesstat	immediate (CURRENT) block cleanout applications                    0
sesstat	no work - consistent read gets                                 16317
sesstat	physical reads                                                   680
sesstat	physical reads direct                                              0
sesstat	redo size                                                    5877252

---

まとめ

index unique scanでグルグルさせつつ、全行アクセスしても発生しないですよね！
single block readになるunique index scanでは、遅延ブロッククリーンアウトは発生しない。（想像通りでよかったw）
で、そのあとで全表走査（scattered read)させてみると、やはり、遅延ブロッククリーンアウトは発生するわけですよ。面白いです。ほんと。

---

さあ、5月末まで追い込みだw　ブログ書かないとw　（頑張って、アドベントカレンダー全部俺やっとくほうが実は楽なのかもしれないw）

では、また。

---

・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #4
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #5
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #6
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #7
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #8
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #9
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #10
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #11
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #12

---

古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #12

Previously on Mac De Oracle
前回、前々回とIASでdirect path writeであるか否かで、そのコミットおよび遅延ブロッククリーンアウトの有無が決まるという動きを確認しました。

今回は、DDLですが、親戚みたいな挙動のCTASではどうなるか確認しておきます。CTASはDDLなのでコミットは不要ですよね。また、 direct path writeが前提になっていることも皆さんご存知の通り。

ということは、IAS + APPENDヒントで、direct path write させた時と同じような挙動になるはず。。。。ですよね。

手順はいつもの図でご確認ください。（DDLなので手順も単純になっています）

---

---

0) 対象表のdrop
対象表のHOGE2は削除しておきます。CTASで作成することになるので。

SCOTT@orcl> @droppurge_hoge2.sql
  1* drop table hoge2 purge

Table dropped.

Elapsed: 00:00:02.79

1) 統計をクリアするためOracle再起動

$ sudo service oracle restart

2) PDBのscottでログインしてclient_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。

SCOTT@orcl> @set_client_info
  1  begin
  2     DBMS_APPLICATION_INFO.SET_CLIENT_INFO('Target Session');
  3* end;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.00
SCOTT@orcl>

3) CDBのSYSで統計取得（初回）
内容は省略！（ベースラインを取得しているだけなので）

SYS$orclcdb> @show_stat scott
...略...

4) PDBのSCOTTユーザーでCTAS（データサイズは、コミットクリーンアウトではクリーンアウト仕切れないサイズ）

SCOTT@orcl> @ctas_from_hoge.sql
  1* create table hoge2 as  select * from hoge

Table created.

Elapsed: 00:00:07.41

5) CDBのSYSで統計取得（CTAS後）
DDLなのでコミットはありませんが、念の為に確認すると、commit cleanouts、commit cleanouts successfully completed　はほんの少しだけ。このテストケースではノイズ程度の量です。
DDL終了時にクリーンアウトは発生していないと読み取れます。（この後の手順で遅延クリーンアウトも発生していなければ。direct path writeではクリーンアウトが必要な状態にはならないということは間違いないと判断するできますよね）

参考程度ですが、physical writes 、physical writes direct、physical writes non checkpoint が同数です。物理書き込みが発生し、かつ、direct path writeでチェックポイントで書き出されたものではないということが確認できます。想定通り、CTASは direct path writeで書き出されているということがわかります。
(HOGE表のデータが載っているブロック数は、66667 ブロックであることは以前確認した通りの値です)

また、physical reads　と　physical reads direct は、HOGE表のブロック数以上あり、HOGE表は direct path readでお読み込まれていることがわかります。このときのfree buffer requested は非常に低いことは、バッファキャッシュを介さず、ストレージへ書き出されていることを示しています。

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sysstat	commit cleanouts                                                  21
sysstat	commit cleanouts successfully completed                           21
sysstat	consistent gets                                                72654
sysstat	db block changes                                                3898
sysstat	deferred (CURRENT) block cleanout applications                     7
sysstat	free buffer requested                                            819
sysstat	immediate (CURRENT) block cleanout applications                    8
sysstat	no work - consistent read gets                                 69569
sysstat	physical reads                                                 67150
sysstat	physical reads direct                                          66709
sysstat	physical writes                                                66667
sysstat	physical writes direct                                         66667
sysstat	physical writes non checkpoint                                 66667

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sesstat	commit cleanouts                                                  21
sesstat	commit cleanouts successfully completed                           21
sesstat	consistent gets                                                72366
sesstat	db block changes                                                3898
sesstat	deferred (CURRENT) block cleanout applications                     7
sesstat	free buffer requested                                            818
sesstat	immediate (CURRENT) block cleanout applications                    8
sesstat	no work - consistent read gets                                 69415
sesstat	physical reads                                                 67149
sesstat	physical reads direct                                          66709
sesstat	physical writes                                                66667
sesstat	physical writes direct                                         66667
sesstat	physical writes non checkpoint                                 66667

6) PDBのSCOTTユーザーで遅延ブロッククリーンアウト有無確認（対象表をscattered readで全表走査）

IASで direct path writeさせた場合同様に、direct path writeで書き出された場合、クリーンアウトするブロックは存在しないため、遅延ブロッククリーンアウトも発生しないという状況になります。
REDOは多少生成あれていますが、recursive call 等によるものと考えられ、このテストケースではノイズの類程度です。システム／セッション統計値をみることでその点も確認できます。

SCOTT@orcl> @table_full_scan_hoge2.sql
  1* alter session set "_serial_direct_read" = never

Session altered.

Elapsed: 00:00:00.00
  1* alter session set "_very_large_object_threshold" = 20400

Session altered.

Elapsed: 00:00:00.00
set autot trace exp stat

  1* select * from hoge2

200000 rows selected.

Elapsed: 00:00:06.66

Execution Plan
----------------------------------------------------------
Plan hash value: 1530105727

---------------------------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |   200K|   382M| 18174   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| HOGE2 |   200K|   382M| 18174   (1)| 00:00:01 |
---------------------------------------------------------------------------

Statistics
----------------------------------------------------------
         14  recursive calls
         12  db block gets
      80022  consistent gets
      66669  physical reads
       2108  redo size
  406775148  bytes sent via SQL*Net to client
     147265  bytes received via SQL*Net from client
      13335  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     200000  rows processed

set autot off

7) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認。対象表をscattered readで全表走査）
deferred (CURRENT) block cleanout applications　や、immediate (CURRENT) block cleanout applicationsなど遅延ブロッククリーンアウトで動く統計に極わずかに動きがありますが、数ブロックなので気にする程度ではないです。遅延ブロッククリーンアウトは発生していないと読み取れます。

また、physical reads は該当表のブロック数程度のブロック数となっており、physical reads direct が発生していないことから、 scattered read　でバッファキャッシュに載せられたことが確認できます。free buffer requested もほぼ同じ値になっていることからも同様のことが言えます。

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sysstat	commit cleanouts                                                  16
sysstat	commit cleanouts successfully completed                           16
sysstat	consistent gets                                               105725
sysstat	db block changes                                                 255
sysstat	deferred (CURRENT) block cleanout applications                     8
sysstat	free buffer requested                                          67608
sysstat	immediate (CURRENT) block cleanout applications                    2
sysstat	no work - consistent read gets                                 94138
sysstat	physical reads                                                 67567

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sesstat	commit cleanouts                                                   6
sesstat	commit cleanouts successfully completed                            6
sesstat	consistent gets                                                86719
sesstat	db block changes                                                  43
sesstat	deferred (CURRENT) block cleanout applications                     3
sesstat	free buffer requested                                          66791
sesstat	immediate (CURRENT) block cleanout applications                    2
sesstat	no work - consistent read gets                                 82976
sesstat	physical reads                                                 66783

---

まとめ

CTASはDDLで、　direct path write を伴うため、IASのAPPEND同様、対象データブロックはクリーンアウトが必要な状態にはならず、コミットおよび遅延ブロッククリーンアウトは発生しない！
ことが確認できました。　：）

次回は、一旦中締めにしますか。

つづく。

---

目がショボショボしてるから、なにか浮遊物の影響を受けてる気がする。ブタクサやヨモギの季節だもんな。（目だけなんだよなー。アレルギーの酷方のように鼻水でたりとかではなくて。疲れ目用の目薬では、効かないw）

---

・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #4
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #5
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #6
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #7
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #8
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #9
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #10
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #11

---

古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #11

Previously on Mac De Oracle
前回は、クリーンアウトの後始末をさせられる側ではなく、そもそも、後始末不要な状況もあるという確認でした。
IAS（Insert as Select)でdirect path writeで書き込まれたブロックは、クリーンアウトする必要がない状態なので、コミットクリーンアウトも遅延ブロッククリーンアウトも発生していないことはシステム統計やセッション統計からも明らかでした。

今回は、今一度確認ということで、IASでも非direct path writeだったら、やはりコミットクリーンアウトや遅延ブロッククリーンアウトは発生するよね！　というところだけは見ておこうと思います。

手順は前回と同じ。前回と異なる点は、4) の部分。IASで NOAPPEND ヒントを使い direct path writeを抑止している部分のみ。

---

---

0) 対象表のdrop/create

SCOTT@orcl> @droppurge_create_hoge2.sql
  1* drop table hoge2 purge

Table dropped.

Elapsed: 00:00:00.67
  1* create table hoge2 (id number, data varchar2(2000))

Table created.

Elapsed: 00:00:00.05
  1* select segment_name,blocks from user_segments where segment_name like '%HOGE2%'

no rows selected

Elapsed: 00:00:00.16

1) 統計をクリアするためOracle再起動

$ sudo service oracle restart

2) PDBのscottでログインしてclient_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。

SCOTT@orcl> @set_client_info
  1  begin
  2     DBMS_APPLICATION_INFO.SET_CLIENT_INFO('Target Session');
  3* end;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.00
SCOTT@orcl>

3) CDBのSYSで統計取得（初回）
内容は省略！（ベースラインを取得しているだけなので）

SYS$orclcdb> @show_stat scott
...略...

4) PDBのSCOTTユーザーでIAS（データサイズは、コミットクリーンアウトではクリーンアウト仕切れないサイズ、コミットなし）
このケースでは 非direct path write でINSERTしたいので NOAPPEND ヒントで direct path write を抑止しています。

SCOTT@orcl> @ias_noappend_from_hoge.sql
  1* insert /*+ noappend */ into hoge2 select * from hoge

200000 rows created.

Elapsed: 00:00:16.79

5) CDBのSYSで統計取得（APPENDヒント付きのIAS後、未コミット）

IASでHOGE表を読み込み、HOGE2表へ非direct path write している様子が確認できますよね。HOGE表の読み込みは direct path read 、HOGE2表へは 非direct path write していることが読み取れます。
free buffer requested で読み込みブロック相当のブロックがバッファキャッシュへ載せられているように見えますが、読み込みは direct path read　なのでバッファキャッシュには載りません。ようするに、HOGE2表向けのデータと考えることができますよね。このキャッシュされたブロックが本当にHOGE2表向けブロックであるかどうかは、これ以降の操作で物理読み込みが発生しないということで確認することができます。

(HOGE表のデータが載っているブロック数は、66667 ブロックであることは前々回も確認した通りの値です)

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sysstat	DBWR checkpoint buffers written                                19158
sysstat	DBWR checkpoints                                                   2
sysstat	DBWR thread checkpoint buffers written                         19158
sysstat	DBWR transaction table writes                                     22
sysstat	DBWR undo block writes                                           299
sysstat	commit cleanouts                                                   6
sysstat	commit cleanouts successfully completed                            6
sysstat	consistent gets                                               110098
sysstat	db block changes                                              443304
sysstat	deferred (CURRENT) block cleanout applications                     5
sysstat	free buffer requested                                          67998
sysstat	immediate (CURRENT) block cleanout applications                    1
sysstat	no work - consistent read gets                                 66823
sysstat	physical reads                                                 66730
sysstat	physical reads direct                                          66709
sysstat	physical writes                                                19158
sysstat	physical writes from cache                                     19158
sysstat	physical writes non checkpoint                                 19158
sysstat	transaction tables consistent reads - undo records applied         2

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sesstat	commit cleanouts                                                   6
sesstat	commit cleanouts successfully completed                            6
sesstat	consistent gets                                               109971
sesstat	db block changes                                              443304
sesstat	deferred (CURRENT) block cleanout applications                     5
sesstat	free buffer requested                                          67996
sesstat	immediate (CURRENT) block cleanout applications                    1
sesstat	no work - consistent read gets                                 66781
sesstat	physical reads                                                 66730
sesstat	physical reads direct                                          66709

6) PDBのSCOTTユーザーでコミットの実行

SCOTT@orcl> commit;

Commit complete.

7) CDBのSYSで統計取得（コミット後）
APPENDモードのIASと異なり、NOAAPENDモードでは、はやり、コミットクリーンアウトが発生しています。バッファキャッシュの10%-15%の範囲のブロックがコミット時にクリーンアウトされている状況が　commit cleanouts successfully completed　および、commit cleanouts　から確認することができます。

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sysstat	commit cleanouts                                               55709
sysstat	commit cleanouts successfully completed                        55709
sysstat	consistent gets                                                18547
sysstat	db block changes                                                 289
sysstat	deferred (CURRENT) block cleanout applications                     4
sysstat	free buffer requested                                            791
sysstat	no work - consistent read gets                                 10937
sysstat	physical reads                                                   758
sysstat	transaction tables consistent reads - undo records applied         1

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sesstat	commit cleanouts                                               55700
sesstat	commit cleanouts successfully completed                        55700
sesstat	db block changes                                                   1

8) PDBのSCOTTユーザーで遅延ブロッククリーンアウト有無確認（対象表をscattered readで全表走査）

direct path writeと非direct path writeの違いはハッキリでました。REDOログは大量に生成され、遅延ブロッククリーンアウトは発生しているようです。
また、物理読み込みは発生していないので、バッファキャッシュにヒットしているという状況も読み取れます。

SCOTT@orcl> @table_full_scan_hoge2.sql
  1* alter session set "_serial_direct_read" = never

Session altered.

Elapsed: 00:00:00.00
  1* alter session set "_very_large_object_threshold" = 20400

Session altered.

Elapsed: 00:00:00.00
set autot trace exp stat

  1* select * from hoge2

200000 rows selected.

Elapsed: 00:00:05.74

Execution Plan
----------------------------------------------------------
Plan hash value: 1530105727

---------------------------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |   172K|   167M| 18223   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| HOGE2 |   172K|   167M| 18223   (1)| 00:00:01 |
---------------------------------------------------------------------------

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

Statistics
----------------------------------------------------------
         19  recursive calls
         13  db block gets
      91462  consistent gets
          2  physical reads
     967388  redo size
  406775148  bytes sent via SQL*Net to client
     147265  bytes received via SQL*Net from client
      13335  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     200000  rows processed
¥
set autot off

9) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認。対象表をscattered readで全表走査）
実行統計の示す通り、遅延ブロッククリーンアウトが発生していることは、immediate (CR) block cleanout applications、cleanouts only - consistent read getsのブロック数からもハッキリ確認することができます！（コミットクリーンアウトできなかったブロック数です）

physical readsはほんの少しありますが、発生していないとみなしても良い程度です。このケースはscattered readが発生していない。つまり、非direct path writeでバッファキャッシュに載ったブロックにヒットしていることで、scattered readの必要がなかった！　ということを意味しています。もし、この時、バッファキャッシュから該当表のブロックがある程度落ちていれば、physical readsが表のブロック数程度まで増加していたはずです。（多数の同時実行トランザクションが存在する状況であればキャッシュからエージアウトされ、物理読み込みが大量に発生するというケースは珍しくありません。その分処理時間も長くなるわけで、程度とデータサイズサイズしだいで処理時間も延びることが予想できます。場合よっては、処理時間がかかりすぎて、ザワザワしたり。。。w）

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sysstat	cleanouts only - consistent read gets                          10967
sysstat	commit cleanouts                                                  19
sysstat	commit cleanouts successfully completed                           19
sysstat	consistent gets                                                98619
sysstat	db block changes                                               11065
sysstat	deferred (CURRENT) block cleanout applications                     8
sysstat	free buffer requested                                            180
sysstat	immediate (CR) block cleanout applications                     10967
sysstat	immediate (CURRENT) block cleanout applications                    5
sysstat	no work - consistent read gets                                 72340
sysstat	physical reads                                                   169

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sesstat	cleanouts only - consistent read gets                          10967
sesstat	commit cleanouts                                                   6
sesstat	commit cleanouts successfully completed                            6
sesstat	consistent gets                                                98015
sesstat	db block changes                                               11011
sesstat	deferred (CURRENT) block cleanout applications                     2
sesstat	free buffer requested                                            121
sesstat	immediate (CR) block cleanout applications                     10967
sesstat	immediate (CURRENT) block cleanout applications                    2
sesstat	no work - consistent read gets                                 72013
sesstat	physical reads                                                   113

---

まとめ

IASで 非direct path write してINSERTされた場合、ブロッククリーンアウトが通常通り発生する（コミット時でも遅延でも）
direct path write時との統計値の違いからも明らかですね。

前回のIAS（APPEND)時の遅延ブロッククリーンアウトがなかったケースの統計を再掲しておきます。統計値の違いをよーく確認してみてください。（試験に。。。でないですけどw）

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE  NAME    　                                                       VALUE
------- ---------------------------------------------------- ---------------
sysstat	cleanouts only - consistent read gets                              1
sysstat	commit cleanouts                                                  16
sysstat	commit cleanouts successfully completed                           16
sysstat	consistent gets                                               105046
sysstat	db block changes                                                 225
sysstat	deferred (CURRENT) block cleanout applications                     9
sysstat	free buffer requested                                          67576
sysstat	immediate (CR) block cleanout applications                         1
sysstat	immediate (CURRENT) block cleanout applications                    2
sysstat	no work - consistent read gets                                 93908
sysstat	physical reads                                                 67536

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sesstat	cleanouts only - consistent read gets                              1
sesstat	commit cleanouts                                                   6
sesstat	commit cleanouts successfully completed                            6
sesstat	consistent gets                                                86566
sesstat	db block changes                                                  44
sesstat	deferred (CURRENT) block cleanout applications                     3
sesstat	free buffer requested                                          66778
sesstat	immediate (CR) block cleanout applications                         1
sesstat	immediate (CURRENT) block cleanout applications                    2
sesstat	no work - consistent read gets                                 82891
sesstat	physical reads                                                 66770

次回は、CTAS ( create table as select ) ではどうなるか確かめます。（まだいくつかの関連統計を動かせていないケースありw）

次回へつづく。

---

東京は、自転車での移動や買い物のほうが渋滞や混雑のストレスがなくていいな。久々に coutry side側をドライブしてたが、ノーストレレスだった。一転機能は、買い物でドライブするも、いちいち渋滞w
WfHも年単位になると、すでに都心の満員電車や渋滞に耐えられない感じになってる気がしないでもないw （渋滞でスタックしている時間がもったいないw）

---

・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #4
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #5
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #6
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #7
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #8
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #9
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #10

---

古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #10

Previously on Mac De Oracle
前回は、SELECT文であっても遅延ブロッククリーンアウトが発生すると該当ブロックは更新され、REDOログも生成される。ただし、direct path read で読み込まれた場合を除く。
という動きをみました。

今回もdirect pathがらみです。といっても direct path write だったら、コミットクリーンアウトや、遅延ブロッククリーンアウトはどういう扱いになるのだろう。。。と
（このシリーズの初回で紹介したいろいろなブログに答えはあるのですがw）

システム統計やセッション統計の統計値から、それをどう読み取るか。γGTP高いから肝臓あたりに問題があるか、検査前日に酒飲んじゃったでしょ！　的なところを診て、なにがおきているか診察していくシリーズなので、それぞれの統計と、auto traceによる実行計画と実行統計を診ていくわけですが。。w

ということで、今回は、前回利用していた表を元にIASで別表を作成し、コミット前後の状況を診ていきたいとおもいます。IASと言っても direct path write　になるケースと従来型のロードがあるのは皆さんご存知だと思いますが、まずは、 direct path writeの方から挙動を診ていくことにします。手順はざっとこんな感じ

そういえば、以前、IASで、direct path write かどうか判別しやすくなったよねーというネタをやってましたね。実行計画だけでも違いがわかりやすくなっているので便利になりました。：）

実行計画は、SQL文のレントゲン写真だ！ No.30より、LOAD TABL CONVENTIONAL vs. LOAD AS SELECTの実行計画の違い。

---

---

0) 対象表のdrop/create

SCOTT@orcl> @droppurge_create_hoge2.sql
  1* drop table hoge2 purge

Table dropped.

Elapsed: 00:00:00.74
  1* create table hoge2 (id number, data varchar2(2000))

Table created.

Elapsed: 00:00:00.07
  1* select segment_name,blocks from user_segments where segment_name like '%HOGE2%'

no rows selected

Elapsed: 00:00:00.15

1) 統計をクリアするためOracle再起動

$ sudo service oracle restart

2) PDBのscottでログインしてclient_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。

SCOTT@orcl> @set_client_info
  1  begin
  2     DBMS_APPLICATION_INFO.SET_CLIENT_INFO('Target Session');
  3* end;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.00
SCOTT@orcl>

3) CDBのSYSで統計取得（初回）
内容は省略！（ベースラインを取得しているだけなので）

SYS$orclcdb> @show_stat scott
...略...

4) PDBのSCOTTユーザーでIAS（データサイズは、コミットクリーンアウトではクリーンアウト仕切れないサイズ、コミットなし）
このケースでは direct path write でINSERTしたいので APPEND ヒントで direct path write を強制しています。 direct path read とは異なり、ヒントで制御できるのは楽w

SCOTT@orcl> @ias_from_hoge.sql
  1* insert /*+ append */ into hoge2 select * from hoge

200000 rows created.

Elapsed: 00:00:10.42

5) CDBのSYSで統計取得（APPENDヒント付きのIAS後、未コミット）

IASでHOGE表を読み込み、HOGE2表へdirect path write している様子が確認できますよね。HOGE表の読み込みは direct path read 、HOGE2表へは direct path write している状況がはっきりでていてわかりやすい結果を得られました :)
(HOGE表のデータが載っているブロック数は、66667 ブロックであることは前回も確認した通りの値です)

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sysstat	commit cleanouts                                                  16
sysstat	commit cleanouts successfully completed                           16
sysstat	consistent gets                                                72460
sysstat	db block changes                                                3131
sysstat	deferred (CURRENT) block cleanout applications                    12
sysstat	free buffer requested                                            792
sysstat	immediate (CURRENT) block cleanout applications                    3
sysstat	no work - consistent read gets                                 69328
sysstat	physical reads                                                 67121
sysstat	physical reads direct                                          66709
sysstat	physical writes                                                66667
sysstat	physical writes direct                                         66667
sysstat	physical writes non checkpoint                                 66667

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sesstat	commit cleanouts                                                  16
sesstat	commit cleanouts successfully completed                           16
sesstat	consistent gets                                                72373
sesstat	db block changes                                                3131
sesstat	deferred (CURRENT) block cleanout applications                    12
sesstat	free buffer requested                                            792
sesstat	immediate (CURRENT) block cleanout applications                    3
sesstat	no work - consistent read gets                                 69291
sesstat	physical reads                                                 67121
sesstat	physical reads direct                                          66709
sesstat	physical writes                                                66667
sesstat	physical writes direct                                         66667
sesstat	physical writes non checkpoint                                 66667

6) PDBのSCOTTユーザーでコミットの実行

SCOTT@orcl> commit;

Commit complete.

7) CDBのSYSで統計取得（コミット後）
direct path writeでバッファキャッシュを経由せず書き出されたブロックはコミット時にはクリーンアウトの対象にはなっていないようですね。。。。統計をみる限りノイズ程度ですね。
ということは全てのブロックが遅延ブロッククリーンアウト対象になってしまうのか、または、その逆で、最初からクリーンアウト対象にもなっていないかということになります。次の全表走査の結果でどちらであるか、わかるはずです！！！！（ニヤニヤ、それ、ねらってやってるので、答えは知っているわけですがw）

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sysstat	commit cleanouts                                                  25
sysstat	commit cleanouts successfully completed                           25
sysstat	consistent gets                                                12104
sysstat	db block changes                                                1557
sysstat	deferred (CURRENT) block cleanout applications                    12
sysstat	free buffer requested                                            714
sysstat	immediate (CURRENT) block cleanout applications                    4
sysstat	no work - consistent read gets                                  7192
sysstat	physical reads                                                   705

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sesstat	commit cleanouts                                                   2
sesstat	commit cleanouts successfully completed                            2
sesstat	consistent gets                                                  864
sesstat	db block changes                                                1474
sesstat	deferred (CURRENT) block cleanout applications                     1
sesstat	free buffer requested                                             37
sesstat	no work - consistent read gets                                   351
sesstat	physical reads                                                    32

8) PDBのSCOTTユーザーで遅延ブロッククリーンアウト有無確認（対象表をscattered readで全表走査）

REDOログは多少生成されていますが、実際に遅延ブロッククリーンアウトが発生した場合REDOログ量この程度では少なすぎますよね。
今回の検証目的からするとノイズの類ですね。むむむ。これは。。。。
（物理読み込みは発生しているので、direct path read か、scattered readのどちらかということにはなります。期待している動きは、Scattered read 。）

SCOTT@orcl> @table_full_scan_hoge2.sql
  1* alter session set "_serial_direct_read" = never

Session altered.

Elapsed: 00:00:00.00
  1* alter session set "_very_large_object_threshold" = 20400

Session altered.

Elapsed: 00:00:00.00
set autot trace exp stat

  1* select * from hoge2

200000 rows selected.

Elapsed: 00:00:06.84

Execution Plan
----------------------------------------------------------
Plan hash value: 1530105727

---------------------------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |   200K|   382M| 18174   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| HOGE2 |   200K|   382M| 18174   (1)| 00:00:01 |
---------------------------------------------------------------------------

Statistics
----------------------------------------------------------
         13  recursive calls
         12  db block gets
      80022  consistent gets
      66668  physical reads
       2284  redo size
  406775148  bytes sent via SQL*Net to client
     147265  bytes received via SQL*Net from client
      13335  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     200000  rows processed

set autot off

9) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認。対象表をscattered readで全表走査）
physical reads は想定通りのブロック以上になっていますが、physical reads direct は発生していないので、scattered readによる全表走査であると読み取ることができます。
ただ、この状態でも、遅延ブロッククリーンアウトの発生を示す統計値はノイズ程度の値です。

つまり、direct path write でINSERTされたデータブロックはクリーンアウトが必要な状態だということになりますね。興味深い動きですよね。メモしておいたほうが良さそうです :)

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sysstat	cleanouts only - consistent read gets                              1
sysstat	commit cleanouts                                                  16
sysstat	commit cleanouts successfully completed                           16
sysstat	consistent gets                                               105046
sysstat	db block changes                                                 225
sysstat	deferred (CURRENT) block cleanout applications                     9
sysstat	free buffer requested                                          67576
sysstat	immediate (CR) block cleanout applications                         1
sysstat	immediate (CURRENT) block cleanout applications                    2
sysstat	no work - consistent read gets                                 93908
sysstat	physical reads                                                 67536

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                           VALUE
------- ---------------------------------------------------- ---------------
sesstat	cleanouts only - consistent read gets                              1
sesstat	commit cleanouts                                                   6
sesstat	commit cleanouts successfully completed                            6
sesstat	consistent gets                                                86566
sesstat	db block changes                                                  44
sesstat	deferred (CURRENT) block cleanout applications                     3
sesstat	free buffer requested                                          66778
sesstat	immediate (CR) block cleanout applications                         1
sesstat	immediate (CURRENT) block cleanout applications                    2
sesstat	no work - consistent read gets                                 82891
sesstat	physical reads                                                 66770

---

まとめ

IASで direct path write してINSERTされた場合、ブロッククリーンアウトは発生しない！（コミット時でも遅延でも）
そもそもクリーンアウトが必要な状態になっていないというのが正しいのでしょうね。統計値としては全く動いてないに等しいので。

これも試験にでますよ（嘘w

次回は、同じIASもdirect path write　ではないケースではどうなるでしょう。。。（ここまでのエントリーを読んでいる方は、結果は想像できそうではありますが）

次回へつづく。

---

遅めの夏休みですが、まあ、普段とちがうのは、いろいろなタスクの締め切りに追われずに、マイペースな時間の過ごし方になるぐらいだな。この状況下ではw

---

・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #4
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #5
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #6
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #7
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #8
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #9

---

古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #9

Previously on Mac De Oracle
バッファキャッシュから溢れ出る程度のデータを登録しコミットした場合は、コミットクリーンアウトがどうなるか、遅延ブロッククリーンアウトされるブロック数はどの程度になるかという、寄り道でしたw

今回は、寄り道し過ぎて忘れるところだった、前回まで、scattered readを伴うtable full scanで発生していた遅延ブロッククリーンアウトが direct path read だったらどうなるか、というシリーズ :)　
(まだ続くのかーーーっ！　はいw　いろんなケースがありますから。シンプルなケースであっても。それぞれの基本的な挙動を知っいて損はないとおもいます。 複雑なケースだと脳汁出過ぎるくらい複雑なので考えたくもなくなるのでw)

では、早速再現してみましょう。手順はこれまで行なってきたとおりで、違いは遅延ブロッククリーンアウトを発生させるためのtable full scanでdirect path readさせるという部分のみ。手順はscattered readとの比較も入れるので長くなってしまうので、追加ステップを追記した図を見てもらうと何やっているか、流れは理解しやすいかもしれません。

事前準備
（バッファキャッシュのサイズは元のサイズに戻してあります）

SYS@orclcdb> show sga

Total System Global Area 4294963960 bytes
Fixed Size                  9143032 bytes
Variable Size             805306368 bytes
Database Buffers         3472883712 bytes
Redo Buffers                7630848 bytes

200,000行登録したデータ(セグメントサイズ農地純粋にデータが乗っているブロック数）が乗っているブロック数はこんなところ。セグメントサイズはこれより多いですよ。行データが載っているブロックだけカウントしているので。

SCOTT@orcl> select count(distinct dbms_rowid.rowid_block_number(rowid)) as "blocks" from hoge;

    blocks
----------
     66667

ということで、セグメントサイズも確認。

SCOTT@orcl> select segment_name,blocks from user_segments where segment_name = 'HOGE';

SEGMENT_NAME                       BLOCKS
------------------------------ ----------
HOGE                                67584

バッファキャッシュの10-15%程度はコミットクリーンアウトされるので、間をとってこれぐらいはコミットクリーンアウトされる。。。

SCOTT@orcl> select 3472883712 / 8192 * 0.13 from dual;

3472883712/8192*0.13
--------------------
            55111.68

残りは遅延ブロッククリーンアウトする。だいだいこんなもん。

SCOTT@orcl> select 66667 - 55112 from dual;

66667-55112
-----------
      11555

direct path read狙いの全表走査（シリアル実行で発動させることを意図していますが、言うこときいてくれるかあなぁ）

$ cat table_full_scan_with_dpr.sql
alter session set "_serial_direct_read" = always
.
l
/
alter session set "_very_large_object_threshold" = 512
.
l
/

!echo set autot trace exp stat
set autot trace exp stat

select * from hoge
.
l
/

!echo set autot off
set autot off

Scattered Read狙いの全表走査のスクリプト

$ cat table_full_scan.sql
alter session set "_serial_direct_read" = never
.
l
/
alter session set "_very_large_object_threshold" = 20400
.
l
/

!echo set autot trace exp stat
set autot trace exp stat


select * from hoge
.
l
/

!echo set autot off
set autot off

---

---

さて、うまく再現できるかどうか。。(今回もやったことをほぼすべて載せているので長いです）

0) 対象表をdrop/create
オブジェクトを作り直し前提合せ

SCOTT@orcl> @droppurge_create_hoge

Table dropped.

Table created.

SCOTT@orcl> select segment_name,blocks from user_segments where segment_name like '%HOGE%';

no rows selected

1) 統計をクリアためOracle再起動

$ sudo service oracle restart

2) PDBのscottでログインしてclient_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。

SCOTT@orcl> @set_client_info
  1  begin
  2     DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession');
  3* end;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.00
SCOTT@orcl>

3) CDBのSYSで統計取得（初回）
内容は省略！（ベースラインを取得しているだけなので）

SYS$orclcdb> @show_stat scott
...略...

4) PDBのSCOTTユーザーでINSERT（データ量2倍、コミットなし）
データサイズはバッファキャッシュに載るサイズ、コミットクリーンアウトではクリーンアウト仕切れないサイズで、ある程度の遅延ブロッククリーンアウトが発生するサイズになっているのは以前と同じ。

SCOTT@orcl> @insert_each_rows_2
  1* begin for i in 1..200000 loop insert into hoge values(i, lpad('*', 2000, '*')); end loop; end;

PL/SQL procedure successfully completed.

Elapsed: 00:00:29.48
SCOTT@orcl>

5) CDBのSYSで統計取得（INSERT後、未コミット）
insertしただけなので、insertしたデータ量に応じたブロック数がバッファキャッシュに確保されたという程度の情報( free buffer requested = 68766 なので事前に確認していた 66667 以上になっています)は確認できます。
（バッファキャッシュに収まるデータ量ですし）ただ、checkpointの発生でいくらか書き出されているのも見えますよね( DBWR checkpoint buffers written )

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sysstat	DBWR checkpoint buffers written                                22909
sysstat	DBWR checkpoints                                                   3
sysstat	DBWR thread checkpoint buffers written                         22902
sysstat	DBWR transaction table writes                                      6
sysstat	DBWR undo block writes                                           573
sysstat	commit cleanouts                                                   6
sysstat	commit cleanouts successfully completed                            6
sysstat	consistent gets                                                49682
sysstat	db block changes                                              744727
sysstat	deferred (CURRENT) block cleanout applications                     4
sysstat	free buffer requested                                          68766
sysstat	immediate (CURRENT) block cleanout applications                    1
sysstat	no work - consistent read gets                                    82
sysstat	physical reads                                                     9
sysstat	physical writes                                                22909
sysstat	physical writes from cache                                     22909
sysstat	physical writes non checkpoint                                 22892

(PDB)　SCOTTのセッション統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sesstat	commit cleanouts                                                   6
sesstat	commit cleanouts successfully completed                            6
sesstat	consistent gets                                                49561
sesstat	db block changes                                              744727
sesstat	deferred (CURRENT) block cleanout applications                     4
sesstat	free buffer requested                                          68766
sesstat	immediate (CURRENT) block cleanout applications                    1
sesstat	no work - consistent read gets                                    40
sesstat	physical reads                                                     9

6) PDBのSCOTTユーザーでコミットの実行

SCOTT@orcl> commit;

Commit complete.

7) CDBのSYSで統計取得（コミット後）
コミットクリーンアウトされているブロック数を見ると、事前に計算していた バッファキャッシュの13%( 55112 blocks )に近い 55700 ブロックがコミットのタイミングでクリーンアウトされていることがわかります。ここまでは想定通りの動きです。

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sysstat	commit cleanout failures: callback failure                        15
sysstat	commit cleanouts                                               56077
sysstat	commit cleanouts successfully completed                        56062
sysstat	consistent gets                                                50494
sysstat	db block changes                                                7894
sysstat	deferred (CURRENT) block cleanout applications                   158
sysstat	free buffer requested                                           3217
sysstat	immediate (CURRENT) block cleanout applications                  154
sysstat	no work - consistent read gets                                 32764
sysstat	physical reads                                                  2962

(PDB)　SCOTTのセッション統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sesstat	commit cleanouts                                               55700
sesstat	commit cleanouts successfully completed                        55700
sesstat	db block changes                                                   1

8) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表をdirect path readで全表走査）
全表走査させてコミットクリーンアウトされなかったブロックがクリーンアウトを確認します。ただし、全表走査ではありますが、direct path read で読み込ませるように工夫しています。

さて狙い通りになるかどうか。。。パラレルクエリーでない場合の強制はちょいとむずいのですが、見る限り、REDOログは生成されています。

ただ、以前のscattered read ( db file sequential read )で発生させた遅延ブロッククリーンアウトの検証結果に比べると明らかに少ない。。
なにかが違いますね。。。。むむむ。なんだろう？
scattered readでほぼ同じバッファキャッシュサイズで、遅延ブロッククリーンアウトさせた際、967432 redo size　というサイズが生成されていたのを思い出してみてください！！！　明らかに少ないです。。。。

SCOTT@orcl> @table_full_scan_with_dpr.sql
  1* alter session set "_serial_direct_read" = always

Session altered.

Elapsed: 00:00:00.00
  1* alter session set "_very_large_object_threshold" = 512

Session altered.

Elapsed: 00:00:00.00
set autot trace exp stat

  1* select * from hoge

200000 rows selected.

Elapsed: 00:00:10.84

Execution Plan
----------------------------------------------------------
Plan hash value: 2339479017

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   214K|   207M| 18223   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| HOGE |   214K|   207M| 18223   (1)| 00:00:01 |
--------------------------------------------------------------------------

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

Statistics
----------------------------------------------------------
         23  recursive calls
         13  db block gets
     113559  consistent gets
      66712  physical reads
       2996  redo size
    4539159  bytes sent via SQL*Net to client
     147264  bytes received via SQL*Net from client
      13335  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     200000  rows processed

set autot off

9) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）（対象表をdirect path readで全表走査）
direct path read、遅延ブロッククリーンアウトの有無をシステム統計およびセッション統計から読み取ってみます！

物理読み込み( physical writes )とダイレクトパスリードを示す( physical writes from cache )が同じであることから、間違いなく direct path readが発生しています。ブロック数も　66667　ブロックを超えていることは確認できます。
ただ、immediate (CR) block cleanout applications が想定している量の3倍ぐらいあります:)
遅延ブロッククリーンアウトは行われているのは間違いないですが、前述の通りREDOサイズが異常に少ない。どういうことだろう。。（想定通りの結果に、ニヤニヤなわけですがw）

真相を探るため、われわれはアマゾンの奥深くへ入っていくのであった。。。W

少々本題からそれますが、DBWR parallel query checkpoint buffers written　で 44793 ブロックほど書き出されています。これが発生するのは direct path readの影響です。direct path read バッファキャッシュを介ず、常にストレージからデータを読み込む必要があります。この検証では、INSERTでバッファキャッシュに載っているデータであるため一旦書き出す必要があります。書き出されたデータを direct path read で読み込むのでこんな動きになっているというわけですね。。。。。

これ、よくよく考えると、コミットクリーンアウトされていないブロックもそのままの状態で書き出されてますよね。。。ここ試験にでますよ（嘘ですw

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sysstat	DBWR checkpoint buffers written                                44793
sysstat	DBWR checkpoints                                                   2
sysstat	DBWR object drop buffers written                                   2
sysstat	DBWR parallel query checkpoint buffers written                 44793
sysstat	cleanouts only - consistent read gets                          33057
sysstat	commit cleanouts                                                  18
sysstat	commit cleanouts successfully completed                           18
sysstat	consistent gets                                               120519
sysstat	db block changes                                                  97
sysstat	deferred (CURRENT) block cleanout applications                     8
sysstat	free buffer requested                                            127
sysstat	immediate (CR) block cleanout applications                     33057
sysstat	immediate (CURRENT) block cleanout applications                    5
sysstat	no work - consistent read gets                                 50145
sysstat	physical reads                                                 66827
sysstat	physical reads direct                                          66710
sysstat	physical writes                                                44795
sysstat	physical writes from cache                                     44795
sysstat	physical writes non checkpoint                                 44795

(PDB)　SCOTTのセッション統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sesstat	cleanouts only - consistent read gets                          33057
sesstat	commit cleanouts                                                   5
sesstat	commit cleanouts successfully completed                            5
sesstat	consistent gets                                               120131
sesstat	db block changes                                                  48
sesstat	deferred (CURRENT) block cleanout applications                     1
sesstat	free buffer requested                                            120
sesstat	immediate (CR) block cleanout applications                     33057
sesstat	immediate (CURRENT) block cleanout applications                    2
sesstat	no work - consistent read gets                                 49952
sesstat	physical reads                                                 66823
sesstat	physical reads direct                                          66710

10) Oracle再起動
Oracleを再起動して、諸々綺麗にした状態で、今一度、direct path readで全表走査させてみましょう。

$ sudo service oracle restart

11) PDBのscottでログインしてclient_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。

SCOTT@orcl> @set_client_info
  1  begin
  2     DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession');
  3* end;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.00
SCOTT@orcl>

12) CDBのSYSで統計取得（再起動後初回）
内容は省略！（ベースラインを取得しているだけなので）

SYS$orclcdb> @show_stat scott
...略...

13) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表をdirect path readで全表走査）2回目
お！！！　REDOが生成されていないですね。Scattered Readの場合でも、コミット時でも一度クリーンアウトされたブロックはクリーンアウト済みなので、クリーンアウトされるような挙動は発生しませんでしたが、 direct path read　でもおなじかなーー。

と。。。。とりあえず、システム統計とセッション統計も確認しておきましょう！

SCOTT@orcl> @table_full_scan_with_dpr.sql
  1* alter session set "_serial_direct_read" = always

Session altered.

Elapsed: 00:00:00.00
  1* alter session set "_very_large_object_threshold" = 512

Session altered.

Elapsed: 00:00:00.00
set autot trace exp stat

  1* select * from hoge

200000 rows selected.

Elapsed: 00:00:03.90

Execution Plan
----------------------------------------------------------
Plan hash value: 2339479017

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   214K|   207M| 18223   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| HOGE |   214K|   207M| 18223   (1)| 00:00:01 |
--------------------------------------------------------------------------

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

Statistics
----------------------------------------------------------
         33  recursive calls
          0  db block gets
      91159  consistent gets
      66938  physical reads
          0  redo size
    4539159  bytes sent via SQL*Net to client
     147264  bytes received via SQL*Net from client
      13335  SQL*Net roundtrips to/from client
          5  sorts (memory)
          0  sorts (disk)
     200000  rows processed

set autot off

14) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）（対象表をdirect path readで全表走査）2回目
セッション統計のphysical readsとhysical reads direct は同一であることから direct path readになっていることは間違いありません。また、ブロック数も 66667 ブロック以上にはなっているので全ブロック読み込まれているようですね。
ただ、妙な値を示している統計があります。

immediate (CR) block cleanout applications 　10959　

遅延ブロッククリーンアウトが行われている時に上がる統計です。しかも、コミットクリーンアウトされたブロック数を差し引いたブロック数にほぼ一致します。（1回目の実行ではこの3倍ぐらいに跳ね上がっていましたが。。一度クリーンアウトされたのでは？？）

さらに不思議なことに、REDO生成されないんですね。。。。

ん？　ちょっと待ってください。一度、クリーンアウトされたブロックがなぜ、再度クリーンアウトされているのでしょう？　scattered readで遅延ブロッククリーンアウトされたケースと動きが違います！！！！！！

Oracleを再起動する前のステップでREDOログが異常に少ないにも関わらず、遅延クリーンアウトされていた統計値が高くなった。Oracleを再起動した後でも、同様に、direct path read で読み込み、遅延ブロッククリーンアウト発生。しかもREDOログはありません。。。これって、クリーンアウト行われているようですが、実際にはメモリー上だけで実祭のブロックはクリーンアウトされずに残っているということですよね。なんども発生しているわけですから。
（ブロックダンプしなくても統計値から状況は見えてきましたよね！！）

direct path readはその名の通り、バッファキャッシュを介さず、常にストレージからデータブロックを読み込み、PGAへ。このケースだとSELECT文なので単純にPGAへ直接読み込み、メモリ上ではクリーンアップは行なっているようですが、クエリーが終了すれば、単に捨てられるのみ。。。なので、クリーンアウトの結果は永続化されない。。。ということになりますよね！

ということは、SELECT文の場合は、scattered read等でバッファキャッシュを経由させないと、遅延ブロッククリーンアウトは、ずーっと先延ばしされる。。。direct path readのSELECT文を2回実行してクリーンアウトさせたわけだが、この後、scattered readで全表走査させれば、遅延ブロッククリーンアウトが発生して、大量のREDOログが生成されるて、完全にクリーンアウトされる。。。。。。はず。。。ですよね。

試してみよう！！！！

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sysstat	DBWR checkpoints                                                   1
sysstat	DBWR object drop buffers written                                   2
sysstat	cleanouts only - consistent read gets                          10959
sysstat	commit cleanouts                                                  36
sysstat	commit cleanouts successfully completed                           36
sysstat	consistent gets                                               106766
sysstat	db block changes                                                 166
sysstat	deferred (CURRENT) block cleanout applications                    18
sysstat	free buffer requested                                           1130
sysstat	immediate (CR) block cleanout applications                     10959
sysstat	immediate (CURRENT) block cleanout applications                   10
sysstat	no work - consistent read gets                                 77392
sysstat	physical reads                                                 67827
sysstat	physical reads direct                                          66710
sysstat	physical writes                                                    2
sysstat	physical writes from cache                                         2
sysstat	physical writes non checkpoint                                     2

(PDB)　SCOTTのセッション統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sesstat	cleanouts only - consistent read gets                          10959
sesstat	commit cleanouts                                                   2
sesstat	commit cleanouts successfully completed                            2
sesstat	consistent gets                                                98223
sesstat	db block changes                                                  30
sesstat	deferred (CURRENT) block cleanout applications                     1
sesstat	free buffer requested                                            587
sesstat	immediate (CR) block cleanout applications                     10959
sesstat	no work - consistent read gets                                 72324
sesstat	physical reads                                                 67289
sesstat	physical reads direct                                          66710

15) Oracle再起動
諸々情報を綺麗にするので再起動！！

$ sudo service oracle restart

16) PDBのscottでログインしてclient_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。

SCOTT@orcl> @set_client_info
  1  begin
  2     DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession');
  3* end;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.00
SCOTT@orcl>

17) CDBのSYSで統計取得（再々起動後初回）
内容は省略！（ベースラインを取得しているだけなので）

SYS$orclcdb> @show_stat scott
...略...

18) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表をscattered readで全表走査）3回目

キターーーーーーーーーーーーーーっ！。　予想的中！！。（競馬ならいいのにw）　

大量のREDOログが生成され、物理読み込みも初生しています。direct path readで全表走査させた時とは明らかに違う！！！（以前、見た光景！！w）

SCOTT@orcl> @table_full_scan.sql
  1* alter session set "_serial_direct_read" = never

Session altered.

Elapsed: 00:00:00.00
  1* alter session set "_very_large_object_threshold" = 20400

Session altered.

Elapsed: 00:00:00.00
set autot trace exp stat

  1* select * from hoge

200000 rows selected.

Elapsed: 00:00:04.84

Execution Plan
----------------------------------------------------------
Plan hash value: 2339479017

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   214K|   207M| 18223   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| HOGE |   214K|   207M| 18223   (1)| 00:00:01 |
--------------------------------------------------------------------------

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

Statistics
----------------------------------------------------------
         33  recursive calls
          0  db block gets
      91170  consistent gets
      66720  physical reads
     964436  redo size
    4539159  bytes sent via SQL*Net to client
     147264  bytes received via SQL*Net from client
      13335  SQL*Net roundtrips to/from client
          5  sorts (memory)
          0  sorts (disk)
     200000  rows processed

set autot off

19) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）（対象表をscattered readで全表走査）3回目

physical reads が想定ブロック数以上あるため、物理読み込みされ全ブロックが読み込まれていると読み取れます。また、physical reads direct は変化していません。（変化のない統計は記載していません）
つまり direct path read ではなく scattered read で全表走査が行われたことを示しています。

immediate (CR) block cleanout applications                     10959

という統計から、遅延ブロッククリーンアウトが発生し、ほぼ想定していたブロック数であることも確認できます。

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sysstat	cleanouts only - consistent read gets                          10959
sysstat	commit cleanouts                                                   3
sysstat	commit cleanouts successfully completed                            3
sysstat	consistent gets                                                98846
sysstat	db block changes                                               10992
sysstat	deferred (CURRENT) block cleanout applications                     2
sysstat	free buffer requested                                          67078
sysstat	immediate (CR) block cleanout applications                     10959
sysstat	no work - consistent read gets                                 72660
sysstat	physical reads                                                 67069

(PDB)　SCOTTのセッション統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sesstat	cleanouts only - consistent read gets                          10959
sesstat	commit cleanouts                                                   2
sesstat	commit cleanouts successfully completed                            2
sesstat	consistent gets                                                98234
sesstat	db block changes                                               10988
sesstat	deferred (CURRENT) block cleanout applications                     1
sesstat	free buffer requested                                          67071
sesstat	immediate (CR) block cleanout applications                     10959
sesstat	no work - consistent read gets                                 72324
sesstat	physical reads                                                 67063

20) Oracle再起動
以前の検証で、scattered readでブロッククリーンアウトされた場合のSELECT文であっても結果は永続化されるので、再度読み込ませた場合はクリーンアウト済みなので再度遅延クリーンアウトが発生しないことは確認確認済みですが、今一度確認しておきましょうw

$ sudo service oracle restart

21) PDBのscottでログインしてclient_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。

SCOTT@orcl> @set_client_info
  1  begin
  2     DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession');
  3* end;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.00
SCOTT@orcl>

22) CDBのSYSで統計取得（再再々起動後初回）
内容は省略！（ベースラインを取得しているだけなので）

SYS$orclcdb> @show_stat scott
...略...

23) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表をscattered readで全表走査）4回目

想定通り、遅延ブロッククリーンアウトは発生せず、REDOログも生成されていません！　めでたしめでたしw

SCOTT@orcl> @table_full_scan.sql
  1* alter session set "_serial_direct_read" = never

Session altered.

Elapsed: 00:00:00.01
  1* alter session set "_very_large_object_threshold" = 20400

Session altered.

Elapsed: 00:00:00.00
set autot trace exp stat

  1* select * from hoge

200000 rows selected.

Elapsed: 00:00:04.32

Execution Plan
----------------------------------------------------------
Plan hash value: 2339479017

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   214K|   207M| 18223   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| HOGE |   214K|   207M| 18223   (1)| 00:00:01 |
--------------------------------------------------------------------------

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

Statistics
----------------------------------------------------------
         33  recursive calls
          0  db block gets
      80211  consistent gets
      66719  physical reads
          0  redo size
    4539159  bytes sent via SQL*Net to clientyoutub
     147264  bytes received via SQL*Net from client
      13335  SQL*Net roundtrips to/from client
          5  sorts (memory)
          0  sorts (disk)
     200000  rows processed

set autot off

24) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）（対象表をscattered readで全表走査）4回目
physical reads はありますが、 physical reads direct は変化していません。これは scattered read で全データを読み込んだと見て良いでしょうね。読み込んだブロックサイズも該当表の想定データブロック数程度です。
また、遅延ブロッククリーンアウトが発生したことを示す統計は変化していないことから、遅延ブロッククリーンアウトは発生していないことも読み取れます。(^^)

統計値が変動したもののみ記載
(CDB）システム統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sysstat	commit cleanouts                                                   3
sysstat	commit cleanouts successfully completed                            3
sysstat	consistent gets                                                87659
sysstat	db block changes                                                  34
sysstat	deferred (CURRENT) block cleanout applications                     2
sysstat	free buffer requested                                          67058
sysstat	no work - consistent read gets                                 83510
sysstat	physical reads                                                 67048

(PDB)　SCOTTのセッション統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sesstat	commit cleanouts                                                   2
sesstat	commit cleanouts successfully completed                            2
sesstat	consistent gets                                                87049
sesstat	db block changes                                                  30
sesstat	deferred (CURRENT) block cleanout applications                     1
sesstat	free buffer requested                                          67051
sesstat	no work - consistent read gets                                 83175
sesstat	physical reads                                                 67042

---

まとめ

SELECT文であっても、遅延ブロッククリーンアウトが発生すると該当ブロックは更新され、REDOログが生成される。ただし、direct path read で読み込まれた場合を除く。
ということのようですね。

ふむふむという興味深い動きですよね。これ。:)

では、次回は direct path に関わる別の動きも確認してみましょうか。。。
このシリーズ、まだまだ引っ張れそうw

ということで次回へつづく。

---

台風の影響を心配したけどなんとか良い天気の遅い夏休みで。暑くも寒くもないく散歩の気持ちいい秋空 :)

---

・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #4
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #5
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #6
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #7
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #8

---

古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #8

Previously on Mac De Oracle
前回からのつづき（ちょいと寄り道中）
です。

では、とっとと試してみましょうw

バッファキャッシュから溢れ出る程度のデータ量だったら、どうなるのかなーーーー、という検証です。やりたいことは図の通りです。

検証方法を考えていたのですが、自動共有メモリー管理になっているのと、sga_max_size/sga_targetを小さくしすぎるとOracle Databaseが起動しないなど諸々引きそうなので、shared_pool_sizeを大きく設定して、バッファキャッシュに回せるメモリーを減らすことで、バッファキャッシュを小さく、バッファから溢れる程度のデータ量も少なくて済むようにして試してみることにします。

準備段階から書いてます。再現させる環境をどうセットアップしたかっていうことも重要だと思うのですよね。少々長くなっちゃいますが。

---

検証準備

CDBに接続して初期化パラメータを調整！！

SGAコンポーネントの状況
Database Buffersが、3G以上になってます。検証データ量も多くなってしまうので、これを1GB程度まで下げたいですね。検証時間も節約できますし、最小の手数で検証できるほうが良いですから:)

SYS@orclcdb> show sga
Total System Global Area 4294963960 bytes
Fixed Size                  9143032 bytes
Variable Size             805306368 bytes
Database Buffers         3472883712 bytes
Redo Buffers                7630848 bytes

SYS@orclcdb> select 3472883712 / 1024 / 1024 AS "MB" from dual;

        MB
----------
      3312

Elapsed: 00:00:00.00

sga_max_size,sga_min_sizeが4GBですが、ここはそのままにします。あまり小さくしすぎると起動しなくなったり。(^^;;;;

SYS@orclcdb> show parameter sga
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
allow_group_access_to_sga            boolean     FALSE
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     TRUE
sga_max_size                         big integer 4G
sga_min_size                         big integer 0
sga_target                           big integer 4G
unified_audit_sga_queue_size         integer     1048576

自動SGA管理なので、Shared Pool Sizeに大きめの値を設定。
自動SGA管理下で自動管理対象メモリーコンポーネントパラメータに値を設定した場合、その値が下限値となり最低でもその値は確保されるという仕組みを利用します！

SYS@orclcdb> show parameter shared_pool

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
shared_pool_reserved_size            big integer 39426457
shared_pool_size                     big integer 0

起動しなくなっても戻しやすいようにspfileをpfileに書き出して退避後に、shared_pool_sizeを3GBへ増やします。これで4Gのうちの3G程度がshared poolに割り当てられ、バッファキャッシュは1GBぐらいになるはず。（VirtualBoxなのでスナップショット取得しておいて戻すのもありですけどw）

SYS@orclcdb> create pfile='pfile20210912.ora' from spfile;

File created.

Elapsed: 00:00:00.00
SYS@orclcdb> alter system set shared_pool_size = 3g scope=both;

System altered.

Elapsed: 00:00:00.77

Database Buffersがいい感じにシュリンクしました。1GBぐらいになりました。これで進めますよー。

SYS@orclcdb> show sga
Total System Global Area 4294963960 bytes
Fixed Size                  9143032 bytes
Variable Size            3238002688 bytes
Database Buffers         1040187392 bytes
Redo Buffers                7630848 bytes

SYS@orclcdb> select 1040187392 / 1024 / 1024 AS "MB" from dual;

        MB
----------
       992

Elapsed: 00:00:00.01

ざっくりとブロック数を計算

SYS@orclcdb> select 1040187392 / 8192 AS "blocks"　from dual;

         blocks
---------------
         126976

Elapsed: 00:00:00.01

前回のHOGE表に200,000 rowsで、66,667 blocks のデータを生成したので、126,976 blocks を満たすデータ量にしようとすると 400,000 rowsほど必要になりそうですね。。。。少々多めで、バッファキャッシュから溢れる程度の量で、 500,000 rowsのデータを登録することにしましょう！！！！

SYS@orclcdb> select ceil(126976 / 66667) * 200000 AS "rows" from dual;

      rows
----------
    400000

Elapsed: 00:00:00.00

これまでの検証から 10%-15%程度がCOMMITクリーンアウトされ、残りが遅延されるのは確認できたので、126976 blocks のバッファキャッシュだと、　17,777 blocks ぐらいがコミットクリーンアウトされそうですね。(今回のテストケースではコミットクリーンアウトされないけど。。された場合は最大でこの程度。。。というメモです。はい)

SYS@orclcdb> select ceil(126976 * 0.14) AS "blocks for commit cleanout" from dual;

blocks for commit cleanout
--------------------------
                     17777

Elapsed: 00:00:00.00

前回作成したデータは、200,000rowsで、66,667 blocksだったので、500,000 rows だと、ざっくり　166,668 blocks ほど。

SCOTT@orcl> select ceil(66667 / 2 * 5) AS "blocks" from dual;

    blocks
----------
    166668

Elapsed: 00:00:00.00

なので、遅延ブロッククリーンアウトされると想定される（コミットクリーンアウト分を覗くと）ブロック数は、148,891 blocks 程度にはなりそう。

SYS@orclcdb>  select ceil((66667 / 2 * 5) - 17777) AS "blocks" from dual;
    blocks
----------
    148891

Elapsed: 00:00:00.01

それに加えて、バッファキャッシュに収まらず、コミットする前にバッファキャッシュから落とされ、ストレージへかきだされてしまうブロック数は、これまた、ざっくり計算すると　39,692 blocks ほどですかね。バッファキャッシュのサイズから全てのブロックは乗り切らないので、最初に読み込まれていたブロックから落とされていくことにはなりますね。。
とはいえ、この検証ではキャッシュ落とされるブロック数は特に気にしてなくて、バッファキャッシュ以上のブロック数が生成されていればいいので、落とされそうなのが確認できればOK.

SYS@orclcdb>  select ceil((66667 / 2 * 5) - 126976) AS "blocks" from dual;

    blocks
----------
     39692

Elapsed: 00:00:00.00

とりあえず、生成するデータ量（行数）の算出とバッファキャッシュサイズの調整はおわり。

次に、実際にデータを生成してブロック数とセグメントサイズを確認して、実行用スクリプトの調整を行なっておきます。

---

PDBでテストデータの実サイズの確認

SCOTT@orcl> @droppurge_create_hoge.sql
  1* drop table hoge purge

Table dropped.

Elapsed: 00:00:00.25
  1* create table hoge (id number, data varchar2(2000))

Table created.

Elapsed: 00:00:00.04
  1* select segment_name,blocks from user_segments where segment_name like '%HOGE%'

no rows selected

Elapsed: 00:00:00.11

500,000行登録！！

SCOTT@orcl> @insert_each_rows_5.sql
  1* begin for i in 1..500000 loop insert into hoge values(i, lpad('*', 2000, '*')); end loop; end;

PL/SQL procedure successfully completed.

Elapsed: 00:02:37.68

データが登録されているブロック数は、166,667 blocks で、事前に計算していた　166,668 blocks にほぼおなじ。（狙い通り）
セグメントサイズは、約 1344 MB ですね。

SCOTT@orcl> select count(distinct dbms_rowid.rowid_block_number(rowid)) as "blocks" from hoge;

    blocks
----------
    166667

Elapsed: 00:00:05.03
SCOTT@orcl> select segment_name,blocks,bytes/1024/1024 AS "MB" from user_segments where segment_name = 'HOGE';

SEGMENT_NAME                       BLOCKS         MB
------------------------------ ---------- ----------
HOGE                               172032       1344

Elapsed: 00:00:00.17

Scattered read でTable Full Scanできるように少々隠しパラメータを調整しておきますね。念の為。（セッションレベルで調整してます）
セグメントサイズが、1344 MBなので、_very_large_object_threshold　は、2048 MBぐらい設定しておけば、Scattered readのまま行けそうですね。

$ cat table_full_scan.sql
alter session set "_serial_direct_read" = never
.
l
/
alter session set "_very_large_object_threshold" = 2040
.
l
/

!echo set autot trace exp stat
set autot trace exp stat


select * from hoge
.
l
/

!echo set autot off
set autot off

準備完了！！！！！

---

---

準備長かったけどw　やっと本題です！！！w　実行している内容はいままでと同じなのでかなり端折ってポイントだけ記載。

バッファキャッシュから溢れるほどのデータ量で。コミットクリーンアウトはどうなるのだろうか。。。。想定では、ほぼコミットクリーンアウトできないはずではあるのだが。。。。

CDBのSYSで統計取得（コミット後）

commit cleanouts successfully completedはどれぐらいだったのか。。。。。ありません。commit cleanouts successfully completedに差分がなかったので、コミットクリーンアウトしようして失敗、commit cleanout failures: block lostと同数なので、１ブロックもコミットクリーンアウトできない！　　commit cleanout failures: block lostがバッファキャッシュに対象ブロックがなかったことを示しています。

つまり、バッファキャッシュに乗り切らなため、最初にINSERTされたブロックはそのままストレージへ物理書き込みされて追い出された結果。。ということになりますね。

登録したブロック全てが遅延クリーンアウト対象になってしまった、ということになります。コミット時にクリーンアウトできてないわけだから！！！！！！！！　（イメージ図でざっくり書いたとおりの感じに。。。

差分のあった統計のみ記載

CDB）システム統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sysstat	commit cleanout failures: block lost                              3028
sysstat	commit cleanouts                                                  3028
sysstat	consistent gets                                                    274
sysstat	db block changes                                                     1
sysstat	no work - consistent read gets                                     149
sysstat	physical reads                                                      60

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sesstat	commit cleanout failures: block lost                              3028
sesstat	commit cleanouts                                                  3028
sesstat	db block changes                                                     1

次に、Scattered Readが実行される全表走査を行わせ、遅延ブロッククリーンアウトどれだけ発生するか結果確認！

PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表を全表走査）
想定通り、物理読み込み（この時点ではscattered readなのか、direct path readなのかわかりませんが）になっています。また、大量のREDOログが生成されているので遅延ブロッククリーンアウトが発生しています。

SCOTT@orcl> @table_full_scan.sql
  1* alter session set "_serial_direct_read" = never

Session altered.

Elapsed: 00:00:00.00
  1* alter session set "_very_large_object_threshold" = 2040

Session altered.

Elapsed: 00:00:00.00
set autot trace exp stat

  1* select * from hoge

500000 rows selected.

Elapsed: 00:01:03.08

Execution Plan
----------------------------------------------------------
Plan hash value: 2339479017

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   669K|   647M| 46462   (1)| 00:00:02 |
|   1 |  TABLE ACCESS FULL| HOGE |   669K|   647M| 46462   (1)| 00:00:02 |
--------------------------------------------------------------------------

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

Statistics
----------------------------------------------------------
         46  recursive calls
         13  db block gets
     367852  consistent gets
     160269  physical reads
   14670268  redo size
 1016952118  bytes sent via SQL*Net to client
     367706  bytes received via SQL*Net from client
      33335  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
     500000  rows processed

set autot off

物理読み込みを伴う全表走査でどの程度の遅延ブロッククリーンアウトが発生したか統計を確認！！！！

CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）

想定どおり、INSERTした全ブロックが、immediate (CR) block cleanout applications = 166667 で遅延ブロッククリーンアウトされたことがわかります。（冒頭に記載していますが、データが格納されているブロック数は、　166667 blocks　でしたよね）
physical readsは意図通り発生していますが、physical reads directが変化していないので、狙い通りScattered Readになったようですね

差分のあった統計のみ記載

CDB）システム統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sysstat	DBWR checkpoint buffers written                                    241
sysstat	DBWR thread checkpoint buffers written                             241
sysstat	DBWR undo block writes                                            1109
sysstat	cleanouts only - consistent read gets                           166667
sysstat	commit cleanouts                                                    55
sysstat	commit cleanouts successfully completed                             55
sysstat	consistent gets                                                 377331
sysstat	db block changes                                                166904
sysstat	deferred (CURRENT) block cleanout applications                      29
sysstat	immediate (CR) block cleanout applications                      166667
sysstat	immediate (CURRENT) block cleanout applications                     15
sysstat	no work - consistent read gets                                   38449
sysstat	physical reads                                                  160805
sysstat	physical writes                                                 137551
sysstat	physical writes from cache                                      137551
sysstat	physical writes non checkpoint                                  137466

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sesstat	cleanouts only - consistent read gets                           166667
sesstat	commit cleanouts                                                     6
sesstat	commit cleanouts successfully completed                              6
sesstat	consistent gets                                                 374538
sesstat	db block changes                                                166710
sesstat	deferred (CURRENT) block cleanout applications                       3
sesstat	immediate (CR) block cleanout applications                      166667
sesstat	immediate (CURRENT) block cleanout applications                      1
sesstat	no work - consistent read gets                                   36779
sesstat	physical reads                                                  160513

念の為、今一度、物理読み込みを伴う全表走査を行なって、クリーンアウトされたのか確認してみましょうw（疑い深いw）
もう一度、PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表を全表走査）

redo sizeが 0 なのでクリーンアウトは発生してない。想定通り

SCOTT@orcl> @table_full_scan.sql
  1* alter session set "_serial_direct_read" = never

Session altered.

Elapsed: 00:00:00.00
  1* alter session set "_very_large_object_threshold" = 2040

Session altered.

Elapsed: 00:00:00.00
set autot trace exp stat

  1* select * from hoge

500000 rows selected.

Elapsed: 00:00:33.17

Execution Plan
----------------------------------------------------------
Plan hash value: 2339479017

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   669K|   647M| 46462   (1)| 00:00:02 |
|   1 |  TABLE ACCESS FULL| HOGE |   669K|   647M| 46462   (1)| 00:00:02 |
--------------------------------------------------------------------------

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

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
     200399  consistent gets
     148198  physical reads
          0  redo size
 1016952118  bytes sent via SQL*Net to client
     367706  bytes received via SQL*Net from client
      33335  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     500000  rows processed

set autot off

同様に、統計でも確認してみます！
CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）

クリーンアウトを示す統計値は上昇していません！！！（うんうんw）

差分のあった統計のみ記載

CDB）システム統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sysstat	DBWR checkpoint buffers written                                    732
sysstat	commit cleanouts                                                     1
sysstat	commit cleanouts successfully completed                              1
sysstat	consistent gets                                                 200522
sysstat	db block changes                                                    13
sysstat	deferred (CURRENT) block cleanout applications                       1
sysstat	no work - consistent read gets                                  200403
sysstat	physical reads                                                  148200
sysstat	physical writes                                                  68570
sysstat	physical writes from cache                                       68570
sysstat	physical writes non checkpoint                                   68331

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sesstat	consistent gets                                                 200414
sesstat	db block changes                                                     9
sesstat	no work - consistent read gets                                  200366
sesstat	physical reads                                                  148198

---

OK. Done. ということで、まとめ！

バッファキャッシュには収まりきれないデータ量の場合、コミットクリーンアウトしようとしていたブロックも追い出されてしまうので、結果的に、全ブロックが遅延ブロッククリーンアウトになった。というイメージしていた結果の通りでした。
（今回のケースもシンプルケースなので比較的予想しやすい結果ですが、クリーンアウトに関わる統計は以外に多く、複雑な動きになるものもあります。再現するののめんどくさいのでしませんがw）

寄り道はここまで、次回は、こんどこそ、direct path readと遅延ブロッククリーンアウトの関係をみていきたいと思います。

来週天気いいかなー。遅い夏休みなのに。微妙な気がしてきた。。。。。

---

・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #4
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #5
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #6
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #7

---

古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #7

Previously on Mac De Oracle
前回は、コミットクリーンアウトと遅延クリーンアウト、そして、そこにTable Full ScanでScattered Read （待機イベントだと db file scattered read) を絡めてストレージへ永続化されたクリーンアウトが遅延されてしまったブロックを物理読み込みませつつ遅延ブロッククリーンアウトを再現させてみました。
また、次回は、図中のscattered read 部分を direct path read にしつつ、最後の最後で、scattered read　にしてみる、とか、そんなイメージをぼやーーーーんと浮かべながら、発生させる方法をどうするか考えてますw。つづく。なんてことを言っていましたが、またまた、ちょいと寄り道ですしますw

バッファキャッシュから溢れるぐらいのデータをぐるぐる系INSERTで、しかも1回のコミットにしたら、コミット前にあふれたデータはストレージへ書き出され、かつ、クリーンアウトも遅延されるよなー。という予想を元に、ちょいと遊んでから次に進みたいw　と思います。

これまでの流れから、基本的なクリーンアウトおよび遅延ブロッククリーンアウトとしては以下ようなパターンを確認してきました。

バッファキャッシュの上でコミットクリーンアウトおよび、遅延ブロッククリーンアウト（単純なタイプ）が行われているケース

ここからが想像というか、私が理解している範囲から想像した動き。バッファキャッシュから溢れはしないけど、いっぱいいっぱいな場合は、クリーンアウトされるブロックがキャッシュ上に多くあるだろうな。と.
とは言っても、バッファキャッシュ上ではあるわけです。

そこで、ちょいと意地悪をして、バッファキャッシュから溢れ出る程度のデータ量だったどうなるのかなーーーーと。冒頭ですでコメントしているわけですけどもw　多分、以下のような動きだよねー、と。
そういえば、以前、DBTSで行なったセッションの「バッファキャッシュ欠乏症」の部分で、似たようなバッファキャッシュから溢れ出したブロックの挙動をなんとかするみたいな資料も今回の動きを想像するにはよいかもしれないですね。

と、思い、頭の中のイメージを Pagesでざざっと作ったところで、本日はここまで。次回へつづく。

Beat SaberとWalkingの合わせ技で、効果的な減量継続中w

---

・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #4
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #5
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #6

---

古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #6

Previously on Mac De Oracle
前々回と前回はバッファキャッシュの10%を超えるデータ量のINSERT文の実行とCOMMITの実行で、バッファキャッシュの10%-15%程度は、COMMIT時にクリーンアウトされ、残ったブロックのクリーンアウトは先送りされる。という検証を2つのパターンで確認してみました。

どのような流れで発生するかを各ステップ毎にシステム統計（CDB）とクエリーを実行するセッションのセッション統計（PDB)を取得し、どのように統計値が変化すれば、コミットクリーンアウトや遅延ブロッククリーンアウトが起きているのかを見ながらすすめました。以下２つのエントリーで確認した動きの違いはイメージできたのか少々不安ではありますがw　（そこそこ長いエントリーなのでw）

こちら前々回は、クリーンアウトが遅延されたブロックが永続化される前に、遅延ブロッククリーンアウトさせてみたケース
古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #4
で、

前回は、クリーンアウトが遅延されたブロックが永続化された後に、遅延ブロッククリーンアウトさせてみたケース
古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #5

なんです　：）　

---

まだ、イメージつかめない方もいるかもしれないので

超ざっくりした絵が頭の中に浮かばない方向けに、上記検証を行う前に、私の頭の中にうかんだ、ラフイメージをほぼそのまま

（こまけーとこは気にしないでくださいね。ラフイメージですから、こうだろうなーというのを想像している状態そのままのイメージですのでw）

クリーンアウトが遅延されたブロックが永続化される前に、遅延ブロッククリーンアウトさせてみたケース
古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #4

クリーンアウトが遅延されたブロックが永続化された後に、遅延ブロッククリーンアウトさせてみたケース
古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #5

再現させてるケースはシンプルなものなので処理時間云々を比較してはいないですが、複雑なケースになると、本来スマートスキャンさせたいのにシングルブロックリードが多くなったりするケースなど、以前紹介したURLを見ていただければ参考になるかもしれないですね。
クエリーやDMLの処理時間が伸びてビビるぐらいに仕事量が増えてたり、先送りされたことで、もろもろ後処理が複雑化する場合もあるわけで）

ということで、こんな図をイメージしながら、ネタ作ってます。はいw

次回は、図中のscattered read 部分を direct path read にしつつ、最後の最後で、scattered read　にしてみる、とか、そんなイメージをぼやーーーーんと浮かべながら、発生させる方法をどうするか考えてますw。つづく。

---

・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #4
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #5

---

古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #5

前回はバッファキャッシュの10%を超えるデータブロックへのINSERT文の実行とCOMMITの実行で、バッファキャッシュの13%-15%程度はCOMMIT時にクリーンアウトされ、残りは遅延ブロッククリーンアウト（先送り）される。
direct path readではないSELECT文による(前回のケースでは scattered read）)遅延ブロッククリーンアウトは、１度のみ発生するという状況を確認しました。

ところで、
前回のエントリで、2度、全表走査（前回の検証ではscattered read）を実行しているのですが、物理読み込みは発生させていません。（INSERT→COMMIT→SELECT→SELECTという流れで、十分なバッファキャッシュがあるので、当然ではあるのですがw）
バッファキャッシュに乗ったままのブロックが遅延クリーンアウトされていたわけです。

前回のエントリ：古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #4

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   194K|   188M| 18189   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| HOGE |   194K|   188M| 18189   (1)| 00:00:01 |
--------------------------------------------------------------------------

1. 遅延ブロッククリーンアウトを発生させた場合。遅延ブロッククリーンアウト対象のデータがバッファキャッシュ上ににあるためクリーンアウトに伴う物理読み込みはない。

Statistics
----------------------------------------------------------
         46  recursive calls
         13  db block gets
      91636  consistent gets
          7  physical reads
     967348  redo size
  406775148  bytes sent via SQL*Net to client
     147264  bytes received via SQL*Net from client
      13335  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
     200000  rows processed

2. 直後に再度全表走査した場合も、キャッシュヒットしているので、物理読み込みはない

Statistics
----------------------------------------------------------
         0  recursive calls
         0  db block gets
     80061  consistent gets
         0  physical reads
         0  redo size
 406775148  bytes sent via SQL*Net to client
    147264  bytes received via SQL*Net from client
     13335  SQL*Net roundtrips to/from client
         0  sorts (memory)
         0  sorts (disk)
    200000  rows processed

前述の1.2.それぞれの実行で物理読み込みだったなにか変化はあるのだろうか。。。予想では、上記に加えてscattered readに伴う物理読み込みが増えるだけのはずです。その動きを見てみることにします。（こういう動きを見ていると楽しいですよねw）
手順は前回と同じですが、各全表走査の前にインスタンスを再起動してバッファキャッシュを空にしておきます。
(buffer cacheをflushすればいいじゃん。という声も聞こえてきそうですが、今回は再起動でクリアしました。はいw)

前回から多少変更したスクリプトも載せておきます（本文中にもありますが）、細かい解説は後述

$ cat table_full_scan.sql
alter session set "_serial_direct_read" = never
.
l
/
alter session set "_very_large_object_threshold" = 1056
.
l
/

!echo set autot trace exp stat
set autot trace exp stat


select * from hoge
.
l
/

!echo set autot off
set autot off

---

0) 対象表をdrop/create
オブジェクト作り直し

SCOTT@orcl> @droppurge_create_hoge

Table dropped.

Table created.

SCOTT@orcl> select segment_name,blocks from user_segments where segment_name like '%HOGE%';

no rows selected

1) 統計をクリアするのにインスタンス再起動

$ sudo service oracle restart

2) PDBのscottでログインし、client_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションと区別するため

SCOTT@orcl> @set_client_info
  1  begin
  2     DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession');
  3* end;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.00
SCOTT@orcl>

3) CDBのSYSで統計取得（初回）

内容は省略！（統計差分取得のためのベースラインを取得しているだけ）

SYS$orclcdb> @show_stat scott

4) PDBのSCOTTユーザーでデータINSERT（データ量2倍、コミットなし）

SCOTT@orcl> @insert_each_rows_2
  1* begin for i in 1..200000 loop insert into hoge values(i, lpad('*', 2000, '*')); end loop; end;

PL/SQL procedure successfully completed.

Elapsed: 00:00:29.48
SCOTT@orcl>

5) CDBのSYSで統計取得（INSERT後、未コミット）

未コミットの状態なので特に、気にせず、ふーーーん。ぐらいの感じで眺めていただければいいですね。前回同様に、commit cleanouts, commit cleanouts successfully completed, deferred (CURRENT) block cleanout applications, immediate (CURRENT) block cleanout applicationsといったクリーンアウト関連統計が極わずかありますが、この時点で発生しているのは本題ではないので気にしなくてOK

差分のある統計のみ記載

(CDB）システム統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sysstat	DBWR checkpoint buffers written                                  23589
sysstat	DBWR checkpoints                                                     2
sysstat	DBWR thread checkpoint buffers written                           22643
sysstat	DBWR transaction table writes                                       50
sysstat	DBWR undo block writes                                             848
sysstat	cleanouts and rollbacks - consistent read gets                       5
sysstat	commit cleanout failures: callback failure                          20
sysstat	commit cleanouts                                                  1320
sysstat	commit cleanouts successfully completed                           1300
sysstat	consistent gets                                                 124041
sysstat	db block changes                                                757165
sysstat	deferred (CURRENT) block cleanout applications                     715
sysstat	immediate (CR) block cleanout applications                           5
sysstat	immediate (CURRENT) block cleanout applications                    196
sysstat	no work - consistent read gets                                   46398
sysstat	physical reads                                                    4063
sysstat	physical writes                                                  23589
sysstat	physical writes from cache                                       23589
sysstat	physical writes non checkpoint                                   23494

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sesstat	commit cleanouts                                                     6
sesstat	commit cleanouts successfully completed                              6
sesstat	consistent gets                                                  49596
sesstat	db block changes                                                744727
sesstat	deferred (CURRENT) block cleanout applications                       4
sesstat	immediate (CURRENT) block cleanout applications                      1
sesstat	no work - consistent read gets                                      49
sesstat	physical reads                                                      15

6) PDBのSCOTTユーザーでコミットの実行

SCOTT@orcl> commit;

Commit complete.

7) CDBのSYSで統計取得（コミット後）
前回同様ノイズもなく、綺麗にコミット時のクリーンアウトが発生しています。バッファキャッシュの約14-5%程度なのは前回と変わらずですね。

差分のある統計のみ記載

(CDB）システム統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sysstat	commit cleanouts                                                 55700
sysstat	commit cleanouts successfully completed                          55700
sysstat	db block changes                                                     1

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sesstat	commit cleanouts                                                 55700
sesstat	commit cleanouts successfully completed                          55700
sesstat	db block changes                                                     1

8) Oracle Databaseを再起動してバッファキャッシュをクリア

ここが前回と違う手順で、クリーンアウトされないブロックはずーーーーーっと残るよね。ということの確認でもあります。（alter system flush buffer_cacheでも同じことができるわけですが、ここでは再起動しています）

$ sudo service oracle restart
[sudo] password for oracle:
Restarting oracle (via systemctl):                         [  OK  ]
$

9) PDBのscottでログインし、client_infoをセット

disconnectしたので再度、client infoをセットし直し！

SCOTT@orcl> @set_client_info
  1  begin
  2     DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession');
  3* end;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.00
SCOTT@orcl>

10) CDBのSYSで統計取得（再起動後初回）

内容は省略！（再起動したので統計値の差分取得用ベースライン統計の取得）

SYS$orclcdb> @show_stat scott

11) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表を全表走査）- scattered read / table full scan の1回目

ここでは待機イベントまでは確認できませんが、Table full scanと実行統計よりRedoログがたっぷり生成されていることは確認できます。SELECT文ですが。。。つまり、遅延ブロッククリーンアウトが発生しているということですね。確認は後述の統計で。
狙い通り、物理読み込みも発生しています！

Note)
"_very_large_object_threshold" = 1056　としているのは、direct path readとなる上限セグメントサイズをhoge表が超えているためdirect path readを抑止するためにこの隠しパラメータで上限値を引き上げ、scattered readになるように強制しています。

SCOTT@orcl> @table_full_scan.sql
  1* alter session set "_serial_direct_read" = never

Session altered.

Elapsed: 00:00:00.01
  1* alter session set "_very_large_object_threshold" = 1056

Session altered.

Elapsed: 00:00:00.00
set autot trace exp stat

  1* select * from hoge

200000 rows selected.

Elapsed: 00:00:06.10

Execution Plan
----------------------------------------------------------
Plan hash value: 2339479017

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   214K|   207M| 18223   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| HOGE |   214K|   207M| 18223   (1)| 00:00:01 |
--------------------------------------------------------------------------

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

Statistics
----------------------------------------------------------
         38  recursive calls
         13  db block gets
      91519  consistent gets
      67073  physical reads
     967432  redo size
  406775148  bytes sent via SQL*Net to client
     147264  bytes received via SQL*Net from client
      13335  SQL*Net roundtrips to/from client
          5  sorts (memory)
          0  sorts (disk)
     200000  rows processed

set autot off
SCOTT@orcl>

12) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）/ scattered read / table full scan の１回目

遅延ブロッククリーンアウト関連統計値が上昇しているので、遅延ブロッククリーンアウトの発生が確認できます。ここまでは前回と同じ。（同じじゃないと困りますがw）

違う点は、事前にインスタンスを再起動しているため、physical reads が上昇しています。これは hoge表を scattered readで全表走査しているからです。（phsical read directは発生していない）バッファキャッシュを経由するのでconsistent gets,no work - consistent read gets も上昇しています。狙い通りです。

そして、重量な遅延ブロッククリーンアウトですが、バッファキャッシュでヒットしていた時と同数のブロックで発生しています。（ニッコリ

インスタンスの停止や起動があったとしても、クリーンアウトが先送りされたブロックはアクセスされない限りクリーンアウトされず残っているということを示しています！！！！（ここ試験にでますよー。嘘）

(CDB）システム統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sysstat	cleanouts only - consistent read gets                            10967
sysstat	commit cleanouts                                                     7
sysstat	commit cleanouts successfully completed                              7
sysstat	consistent gets                                                  98967
sysstat	db block changes                                                 11016
sysstat	deferred (CURRENT) block cleanout applications                       3
sysstat	immediate (CR) block cleanout applications                       10967
sysstat	immediate (CURRENT) block cleanout applications                      2
sysstat	no work - consistent read gets                                   72543
sysstat	physical reads                                                   67403

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sesstat	cleanouts only - consistent read gets                            10967
sesstat	commit cleanouts                                                     6
sesstat	commit cleanouts successfully completed                              6
sesstat	consistent gets                                                  98357
sesstat	db block changes                                                 11012
sesstat	deferred (CURRENT) block cleanout applications                       2
sesstat	immediate (CR) block cleanout applications                       10967
sesstat	immediate (CURRENT) block cleanout applications                      2
sesstat	no work - consistent read gets                                   72208
sesstat	physical reads                                                   67397

13) Oracle Databaseを再起動してバッファキャッシュをクリア

再度、インスタンスを再起動して、バッファキャッシュをクリアします。後続の全表走査では、遅延ブロッククリーンアウトは発生せず、物理読み込み(この検証では scattered readさせています)を伴うTable full scanが行われるだけのはずです。

$ sudo service oracle restart
[sudo] password for oracle:
Restarting oracle (via systemctl):                         [  OK  ]
$

14) PDBのscottでログインし、client_infoをセット

disconnectしたので再度、client infoをセットし直し！

SCOTT@orcl> @set_client_info
  1  begin
  2     DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession');
  3* end;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.00
SCOTT@orcl>

15) CDBのSYSで統計取得（再起動後初回）

内容は省略！（再起動したのでベースラインとなる統計を取得）

SYS$orclcdb> @show_stat scott

16) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表を全表走査）- scattered read / table full scan の2回目

実行統計から、physical readsが、発生しています。Redoは生成されていないことも読み取れるので、遅延ブロッククリーンアウトは発生していないことも確認できます。：）　想定通りですね。

SCOTT@orcl> @table_full_scan.sql
  1* alter session set "_serial_direct_read" = never

Session altered.

Elapsed: 00:00:00.00
  1* alter session set "_very_large_object_threshold" = 1056

Session altered.

Elapsed: 00:00:00.00
set autot trace exp stat

  1* select * from hoge

200000 rows selected.

Elapsed: 00:00:06.44

Execution Plan
----------------------------------------------------------
Plan hash value: 2339479017

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   214K|   207M| 18223   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| HOGE |   214K|   207M| 18223   (1)| 00:00:01 |
--------------------------------------------------------------------------

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

Statistics
----------------------------------------------------------
         30  recursive calls
          0  db block gets
      80211  consistent gets
      66719  physical reads
          0  redo size
  406775148  bytes sent via SQL*Net to client
     147264  bytes received via SQL*Net from client
      13335  SQL*Net roundtrips to/from client
          5  sorts (memory)
          0  sorts (disk)
     200000  rows processed

set autot off
SCOTT@orcl>

17) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）/ scattered read / table full scan の2回目

physical reads は発生していますが、physical reads directではないことが確認できます。Table full scanをscattered readで読み込んでいるという想定通りの結果。　
遅延ブロッククリーンアウトを示deferred (CURRENT) block cleanout applications 、immediate (CURRENT) block cleanout applicationsや、コミットクリーンアウトを示すcommit cleanouts 、commit cleanouts successfully completed という統計が極わずかに変動していますが、今回の検証ではノイズなので気にしたくてOK。

(CDB）システム統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sysstat	DBWR checkpoint buffers written                                     11
sysstat	commit cleanouts                                                    15
sysstat	commit cleanouts successfully completed                             15
sysstat	consistent gets                                                  87375
sysstat	db block changes                                                    79
sysstat	deferred (CURRENT) block cleanout applications                      12
sysstat	immediate (CURRENT) block cleanout applications                      3
sysstat	no work - consistent read gets                                   83322
sysstat	physical reads                                                   67028
sysstat	physical writes                                                     11
sysstat	physical writes from cache                                          11
sysstat	physical writes non checkpoint                                      11

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sesstat	commit cleanouts                                                     2
sesstat	commit cleanouts successfully completed                              2
sesstat	consistent gets                                                  86936
sesstat	db block changes                                                    29
sesstat	deferred (CURRENT) block cleanout applications                       1
sesstat	no work - consistent read gets                                   83098
sesstat	physical reads                                                   67023

---

まとめ

遅延ブロッククリーンアウトは、インスタンスを停止して残ったままということが確認できました。（クリアされるまで残るのですよねー）
クリーンアウトが遅延されているブロックが物理読み込みされた（アクセスされた）タイミングで遅延ブロッククリーンアウトが発生することも確認できました。（物理読み込みの有無には関係しない）
バッファキャッシュ上の遅延ブロッククリーンアウト同様、クリーンアウトされたブロックでは、再度、クリーンアウト対象になるような更新が発生しなければ、遅延ブロッククリーンアウトは発生しない

久しぶりにシステム統計やセッション統計を見ててワクワクしてきましたよーーーーっw

ところで、
冒頭でも記載しましたが、バッファキャッシュ上の遅延ブロッククリーンアウト（再掲）に加え、物理読み込みを伴う遅延ブロッククリーンアウトのauto traceの結果をまとめて記載しておきます。SELECT文ですが、REDOログが生成されている場合は遅延ブロッククリーンアウトが発生しているということになります。

実行計画

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   194K|   188M| 18189   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| HOGE |   194K|   188M| 18189   (1)| 00:00:01 |
--------------------------------------------------------------------------

1. 遅延ブロッククリーンアウトを発生させた場合。遅延ブロッククリーンアウト対象のデータがバッファキャッシュ上ににあるためクリーンアウトに伴う物理読み込みはない。

Statistics
----------------------------------------------------------
         46  recursive calls
         13  db block gets
      91636  consistent gets
          7  physical reads
     967348  redo size
  406775148  bytes sent via SQL*Net to client
     147264  bytes received via SQL*Net from client
      13335  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
     200000  rows processed

2. 直後に再度全表走査した場合も、キャッシュヒットしているので、物理読み込みはない

Statistics
----------------------------------------------------------
         0  recursive calls
         0  db block gets
     80061  consistent gets
         0  physical reads
         0  redo size
 406775148  bytes sent via SQL*Net to client
    147264  bytes received via SQL*Net from client
     13335  SQL*Net roundtrips to/from client
         0  sorts (memory)
         0  sorts (disk)
    200000  rows processed

3. 遅延ブロッククリーンアウトを発生させた場合。遅延ブロッククリーンアウト対象のデータを物理読み込みし、バッファキャッシュに載せている動きが見えます。

Statistics
----------------------------------------------------------
         38  recursive calls
         13  db block gets
       91519  consistent gets
      67073  physical reads
     967432  redo size
  406775148  bytes sent via SQL*Net to client
     147264  bytes received via SQL*Net from client
      13335  SQL*Net roundtrips to/from client
          5  sorts (memory)
          0  sorts (disk)
     200000  rows processed

4. 3.の直後に再度全表走査した場合。事前にキャッシュをクリアしているため、物理読み込みがありますが、遅延ブロッククリーンアウトは発生していません。（Redoが生成されていないことで確認できます）

Statistics
----------------------------------------------------------
        30  recursive calls
         0  db block gets
      80211  consistent gets
      66719  physical reads
          0  redo size
 406775148  bytes sent via SQL*Net to client
    147264  bytes received via SQL*Net from client
     13335  SQL*Net roundtrips to/from client
         5  sorts (memory)
         0  sorts (disk)
    200000  rows processed

ではでは。
次回は、scattered readのtable full scanではなく、direct path readだったらどうなるのか調べてみましょうか。。（いろいろな再現方法があるわけですが、手間のかからないお手軽な再現方法で確認してみようと思いますw）

---

洗濯機の修理が終わって一安心w　ということで、次回へつづく。

---

・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #3
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #4

---

古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #4

Previously on Mac De Oracle
前回はバッファキャッシュの10%未満のデータブロックへのINSERT文の実行とCOMMITの実行で、遅延ブロッククリーンアウトは発生せず、COMMIT時にすべての対象ブロックがクリーンアウトされるということを確認しました。

今回は、そのデータ量を倍にして、バッファキャッシュの10％程度を超えるデータブロックが遅延ブロッククリーンアウトされるのかを見ていくことにします。手順は前回と同じですが、遅延ブロッククリーンアウトさせた後で、もう一度全表走査してクリーンアウトが繰り返されないことも確認しておきます（次回以降に予定している確認への伏線なのですがw）

---

0) 対象表をdrop/create
オブジェクトを作り直して前提条件を合わせておきます

SCOTT@orcl> @droppurge_create_hoge

Table dropped.

Table created.

SCOTT@orcl> select segment_name,blocks from user_segments where segment_name like '%HOGE%';

no rows selected

1) 統計をクリアするのにOracle再起動

$ sudo service oracle restart

2) PDBのscottでログインし、client_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションと区別できるようにしています

SCOTT@orcl> @set_client_info
  1  begin
  2     DBMS_APPLICATION_INFO.SET_CLIENT_INFO('Target Session');
  3* end;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.00
SCOTT@orcl>

3) CDBのSYSで統計取得（初回）

内容は省略！（ベースラインを取得しているだけなので）

SYS$orclcdb> @show_stat

4) PDBのSCOTTユーザーでデータINSERT（データ量2倍、コミットなし）

SCOTT@orcl> @insert_each_rows_2
  1* begin for i in 1..200000 loop insert into hoge values(i, lpad('*', 2000, '*')); end loop; end;

PL/SQL procedure successfully completed.

Elapsed: 00:00:29.48
SCOTT@orcl>

5) CDBのSYSで統計取得（INSERT後、未コミット）

INSERTしただけです。未コミットなので特に気になる情報は現れていません。この値からコミット後にどのように変化するのか？　という部分に注目する必要があるんですよー。
deferred (CURRENT) block cleanout applications と　immediate (CURRENT) block cleanout applications が僅かにありますが、この時点では気にする部分ではないです

（値の変化が1以上ある統計のみ表示）

(CDB）システム統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sysstat	DBWR checkpoint buffers written                                  22756
sysstat	DBWR checkpoints                                                    33
sysstat	DBWR thread checkpoint buffers written                           22756
sysstat	DBWR transaction table writes                                       22
sysstat	DBWR undo block writes                                             606
sysstat	consistent gets                                                  49761
sysstat	db block changes                                                744980
sysstat	deferred (CURRENT) block cleanout applications                       4
sysstat	immediate (CURRENT) block cleanout applications                      1
sysstat	no work - consistent read gets                                     192
sysstat	physical reads                                                      18
sysstat	physical writes                                                  22756
sysstat	physical writes from cache                                       22756
sysstat	physical writes non checkpoint                                   22756

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sesstat	consistent gets                                                  49501
sesstat	db block changes                                                744980
sesstat	deferred (CURRENT) block cleanout applications                       4
sesstat	immediate (CURRENT) block cleanout applications                      1
sesstat	no work - consistent read gets                                      65
sesstat	physical reads                                                      17

6) PDBのSCOTTユーザーでコミットの実行

SCOTT@orcl> commit;

Commit complete.

7) CDBのSYSで統計取得（コミット後）

この結果、ノイズも少なく、綺麗に取れてます！！！　w

前々回の事前確認の通り、2倍のデータブロック数は、 66667ブロック　で、バッファキャッシュの10%は、ざっくり計算で、42394ブロック。つまり、想定では 42394ブロック ほどが、commit時のブロッククリーンアウトの対象と想定していました。

覚えてますか？　みなさん！

実際にcommit時にクリーンアウトされたのはどれぐらいでしょう？　
結果は、55700ブロックとなりました。想定より多いですねw　ほぼ合ってはいますが。
実際にはバッファキャッシュの13%〜15％程度が閾値になっているように見えます。とはいえ、commit時にcleanoutされたブロック数は 55700ブロック ですから、残る 10967ブロック のcleanoutは遅延されたということは確実です。commit対象のデータブロック全てをcleanoutするわけではない、ということは確認できたのではないでしょうか？

(差分が1以上ある統計のみ記載)
(CDB）システム統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sysstat	commit cleanouts                                                 55700
sysstat	commit cleanouts successfully completed                          55700
sysstat	db block changes                                                     1

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sesstat	commit cleanouts                                                 55700
sesstat	commit cleanouts successfully completed                          55700
sesstat	db block changes                                                     1

8) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表を全表走査）

SCOTT@orcl> sset autot trace exp stat
SCOTT@orcl> salter session set "_serial_direct_read" = never;

Session altered.

Elapsed: 00:00:00.00
SCOTT@orcl> select * from hoge;

200000 rows selected.

Elapsed: 00:00:05.14

Execution Plan
----------------------------------------------------------
Plan hash value: 2339479017

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   194K|   188M| 18189   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| HOGE |   194K|   188M| 18189   (1)| 00:00:01 |
--------------------------------------------------------------------------

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


Statistics
----------------------------------------------------------
         46  recursive calls
         13  db block gets
      91636  consistent gets
          7  physical reads
     967348  redo size
  406775148  bytes sent via SQL*Net to client
     147264  bytes received via SQL*Net from client
      13335  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
     200000  rows processed

9) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）

遅延ブロッククリーンアウトは、事前の計算通り、 10967ブロック 発生しています。SELECT文では、immediate (CR) block cleanout applications として現れることも確認できます。
また、cleanouts only - consistent read gets として も同数計上されているところが見てます。綺麗に現れています。

commit cleanouts, ommit cleanouts successfully completed がでていますが、ここでは気にしなくてよいですね、極わずかで。SELECT文なので。
immediate (CURRENT) block cleanout applications、deferred (CURRENT) block cleanout applications もでていますが、同じく極わずかで、対象表のものではないと考えられるためここでは気にしなくて良いですね。

しかし、計算通りに発生してくれると確認が楽w　（想定外の動きじゃなくてよかったw）

(CDB）システム統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sysstat	DBWR checkpoint buffers written                                    272
sysstat	DBWR thread checkpoint buffers written                             272
sysstat	cleanouts only - consistent read gets                            10967
sysstat	commit cleanouts                                                    16
sysstat	commit cleanouts successfully completed                             16
sysstat	consistent gets                                                 117000
sysstat	db block changes                                                 11207
sysstat	deferred (CURRENT) block cleanout applications                      10
sysstat	immediate (CR) block cleanout applications                       10967
sysstat	immediate (CURRENT) block cleanout applications                      2
sysstat	no work - consistent read gets                                   83351
sysstat	physical reads                                                     939
sysstat	physical writes                                                    272
sysstat	physical writes from cache                                         272
sysstat	physical writes non checkpoint                                     260

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sesstat	cleanouts only - consistent read gets                            10967
sesstat	commit cleanouts                                                     6
sesstat	commit cleanouts successfully completed                              6
sesstat	consistent gets                                                  98162
sesstat	db block changes                                                 11011
sesstat	deferred (CURRENT) block cleanout applications                       2
sesstat	immediate (CR) block cleanout applications                       10967
sesstat	immediate (CURRENT) block cleanout applications                      2
sesstat	no work - consistent read gets                                   72113
sesstat	physical reads                                                     122

10) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表を全表走査）

そして、ここからがおまけの確認ステップです

もう一度、同じ表を全表走査してみます。どうなると思いますか？　遅延されていたブロッククリーンアウトも行われたのですから、当然、該当オブジェクトで遅延ブロッククリーンアウトは発生しない。はず！　ですよね。

確認してみましょう。（発生してたらどうしようw、もうしそうなったらバグレポートでも上げようかなw）

.......

Redoは生成されてない！　（よかった！　想定どおりだ！w）

SCOTT@orcl> @table_full_scan
  1* alter session set "_serial_direct_read" = never

Session altered.

Elapsed: 00:00:00.00
set autot trace exp stat

  1* select * from hoge

200000 rows selected.

Elapsed: 00:00:05.43

Execution Plan
----------------------------------------------------------
Plan hash value: 2339479017

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   214K|   207M| 18223   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| HOGE |   214K|   207M| 18223   (1)| 00:00:01 |
--------------------------------------------------------------------------

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

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      80061  consistent gets
          0  physical reads
          0  redo size
  406775148  bytes sent via SQL*Net to client
     147264  bytes received via SQL*Net from client
      13335  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     200000  rows processed

set autot off

SCOTT@orcl>

11) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）2回目

これもノイズが少なく綺麗に取れました。該当セッションでは物理読み込みも発生していないので、キャッシュから全データを読み込んだようです。

そして、想定どおり、該当セッションでは遅延ブロッククリーンアウトは発生していません！

commit cleanouts、commit cleanouts successfully completed、deferred (CURRENT) block cleanout applicationsが1ブロックありますがCDB側の管理情報関連でしょうね。気にする部分ではないですね。

（差分のあった統計のみ記載）

(CDB）システム統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sysstat	commit cleanouts                                                     1
sysstat	commit cleanouts successfully completed                              1
sysstat	consistent gets                                                  80150
sysstat	db block changes                                                    13
sysstat	deferred (CURRENT) block cleanout applications                       1
sysstat	no work - consistent read gets                                   80075

(PDB)　SCOTTのセッション統計

SOURCE  NAME                                                             VALUE
------- ------------------------------------------------- --------------------
sesstat	consistent gets                                                  80076
sesstat	db block changes                                                     9
sesstat	no work - consistent read gets                                   80043

---

まとめ

おおよそ、バッファキャッシュの10%程度が commit時にcleanout　されるという点については、約15%程度と見ておいたほうが良さそうですが、まあ大きな違いはないので、その辺りに閾値があると考えて問題はなさそうです。
また、それを超えるブロックについては、cleanoutが先送りされ、最初に該当ブロックにアクセスしたSQLがその影響を受ける。

この検証ではSELECT文では、immediate (CR) block cleanout applications　という形で統計に現れました。UPDATE文やDELETE文の場合は他の統計として現れそうですね。(CURRENT)関連のcleanoutの統計は今回動いていないのでSQL文を変えて同じような検証をしてみると面白い結果をえられそうです。

そして、SELECT文で、遅延ブロッククリーンアウトされてしまえば、その間に更新が発生しなければ、クリーンアウトは発生しない（おまけで検証した部分ですが、別検証では興味深い動きを紹介する予定です。その伏線でもあります）

次回へつづく

---

5年目を迎えた、パナソニックのドラム洗濯機がH故障した。慌てて近所のコインランドリーを検索w　近所にあってよかったw

---

・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #2
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #3

---

古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #3

Previously on Mac De Oracle
前回は準備を終えたところまででした。

今日は、簡単なところから確認していきましょう。

もしも、「遅延ブロッククリーンアウトが起きない程度のブロック更新量だったなら。。。」。結果は遅延ブロッククリーンアウトは起きないはず。　ですよね。

ざっと手順を紹介しておきましょう。下図の 1)〜9)の順で行います

前述の手順で、各操作後の統計の差分（変化量）を見る。マニュアルの統計の説明ってざっくり過ぎてよくわからないのが多いわけですがw、操作と値の変化を合わせて観察すると、それなりには理解できる程度に値が変化していることに気づきますw　：）

1) 統計をクリアするのにOracle再起動

$ sudo service oracle restart

2) PDBのscottでログインし、client_infoをセット
v$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションと区別できるようにしています。

SCOTT@orcl> @set_client_info
  1  begin
  2     DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession');
  3* end;

PL/SQL procedure successfully completed.

3) CDBのSYSで統計取得（初回）
初回なのですべてリストしていますが、CON_ID=0のCDBのシステム統計([g]v$sysstat)とCON_ID=3のPDBの2)のCLIENT_INFOを設定されたセッションのセッション統計([g]v$sesstat)を取得します。
今回のケースではcleanoutが含まれている統計の差異だけに着目すれば良いのですが。準備運動程度のテストケースなので一応すべて載せておきます :)
（マルチテナントだと、DBRWの動きを見るにはCDBのDBWR関連の統計を見る必要があるため、CDBのシステム統計とPDBの当該セッションのセッション統計を対象にしています）

SYS$orclcdb> @show_stat
SOURCE  NAME                                                                        VALUE     CON_ID
------- ------------------------------------------------------------ -------------------- ----------
sysstat DBWR checkpoint buffers written                                                 0          0
sysstat DBWR checkpoints                                                                0          0
sysstat DBWR fusion writes                                                              0          0
sysstat DBWR lru scans                                                                  0          0
sysstat DBWR object drop buffers written                                                0          0
sysstat DBWR parallel query checkpoint buffers written                                  0          0
sysstat DBWR revisited being-written buffer                                             0          0
sysstat DBWR tablespace checkpoint buffers written                                      0          0
sysstat DBWR thread checkpoint buffers written                                          0          0
sysstat DBWR transaction table writes                                                   0          0
sysstat DBWR undo block writes                                                          0          0
sysstat cleanouts and rollbacks - consistent read gets                                  6          0
sysstat cleanouts only - consistent read gets                                           0          0
sysstat commit cleanout failures: block lost                                            0          0
sysstat commit cleanout failures: buffer being written                                  0          0
sysstat commit cleanout failures: callback failure                                      0          0
sysstat commit cleanout failures: cannot pin                                            0          0
sysstat commit cleanout failures: hot backup in progress                                0          0
sysstat commit cleanout failures: write disabled                                        0          0
sysstat commit cleanouts                                                              570          0
sysstat commit cleanouts successfully completed                                       570          0
sysstat consistent gets                                                           158,083          0
sysstat db block changes                                                            3,247          0
sysstat deferred (CURRENT) block cleanout applications                                316          0
sysstat immediate (CR) block cleanout applications                                      6          0
sysstat immediate (CURRENT) block cleanout applications                                15          0
sysstat no work - consistent read gets                                            108,516          0
sysstat physical reads                                                             12,551          0
sysstat physical reads direct                                                           0          0
sysstat physical writes                                                                 0          0
sysstat physical writes direct                                                          0          0
sysstat physical writes from cache                                                      0          0
sysstat physical writes non checkpoint                                                  0          0
sysstat transaction tables consistent read rollbacks                                    0          0
sysstat transaction tables consistent reads - undo records applied                      0          0
sesstat DBWR checkpoint buffers written                                                 0          3
sesstat DBWR checkpoints                                                                0          3
sesstat DBWR fusion writes                                                              0          3
sesstat DBWR lru scans                                                                  0          3
sesstat DBWR object drop buffers written                                                0          3
sesstat DBWR parallel query checkpoint buffers written                                  0          3
sesstat DBWR revisited being-written buffer                                             0          3
sesstat DBWR tablespace checkpoint buffers written                                      0          3
sesstat DBWR thread checkpoint buffers written                                          0          3
sesstat DBWR transaction table writes                                                   0          3
sesstat DBWR undo block writes                                                          0          3
sesstat cleanouts and rollbacks - consistent read gets                                  0          3
sesstat cleanouts only - consistent read gets                                           0          3
sesstat commit cleanout failures: block lost                                            0          3
sesstat commit cleanout failures: buffer being written                                  0          3
sesstat commit cleanout failures: callback failure                                      0          3
sesstat commit cleanout failures: cannot pin                                            0          3
sesstat commit cleanout failures: hot backup in progress                                0          3
sesstat commit cleanout failures: write disabled                                        0          3
sesstat commit cleanouts                                                                1          3
sesstat commit cleanouts successfully completed                                         1          3
sesstat consistent gets                                                               374          3
sesstat db block changes                                                                4          3
sesstat deferred (CURRENT) block cleanout applications                                  1          3
sesstat immediate (CR) block cleanout applications                                      0          3
sesstat immediate (CURRENT) block cleanout applications                                 0          3
sesstat no work - consistent read gets                                                220          3
sesstat physical reads                                                                 28          3
sesstat physical reads direct                                                           0          3
sesstat physical writes                                                                 0          3
sesstat physical writes direct                                                          0          3
sesstat physical writes from cache                                                      0          3
sesstat physical writes non checkpoint                                                  0          3
sesstat transaction tables consistent read rollbacks                                    0          3
sesstat transaction tables consistent reads - undo records applied                      0          3

4) PDBのSCOTTユーザーでデータINSERT（コミットなし）
データを1行単位でインサートしています。バルクインサートも使ってないです。綺麗なぐるぐる系ですねw。コミット時の効果を確認しやすいようにコミットは後で実行します！
このインサートで、前回の事前準備の時に確認しておいた、33334ブロックが更新されることになります

SCOTT@orcl> @insert_each_rows
  1* begin for i in 1..100000 loop insert into hoge values(i, lpad('*', 2000, '*')); end loop; end;

PL/SQL procedure successfully completed.

5) CDBのSYSで統計取得（INSERT後、未コミット）

注）　3)の統計との差分のみ記載

未コミットであるこの時点で、commitクリーンアウトが発生（該当セッション統計でも同数発生。commit cleanoutsとcommit cleanouts successfully completed）してますが、これは気にしなくてもよいですね。
実行したトランザクションは、未コミットなので、この実行による直接的な影響ではないので。
また、deferred (CURRENT) block cleanout applicationsやimmediate (CURRENT) block cleanout applications の遅延ブロッククリーンアウトを示す統計も微量ですがこれも同様とみて良いでしょう。

この時点で統計取得理由は、操作毎に変化する統計を追うためなので、ふーーん。ぐらいでの雰囲気でOKです　：）
コミット後とその後に該当オブジェクトをアクセスさせた時の遅延ブロッククリーンアウトの有無部分の部分が主役ですので。

参考）
INSERTした行の含まれる全ブロックはバッファキャッシュに載り切るブロック数なので、バッファキャッシュから書き出されているような動きも観測されていないのは確認できると思います。
（physical writes from cache,physical writes non checkpoint,physical writesの統計に変化がないので未記載ですが、それらの統計が動いていないということがその理由です）

(CDB）システム統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sysstat DBWR checkpoints                                                   1
sysstat commit cleanouts                                                   6
sysstat commit cleanouts successfully completed                            6
sysstat consistent gets	                                               22884
sysstat db block changes	                                      373785
sysstat deferred (CURRENT) block cleanout applications	                   5
sysstat immediate (CURRENT) block cleanout applications	                   1
sysstat no work - consistent read gets	                                  59
sysstat physical reads	                                                  12

(PDB)　SCOTTのセッション統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sesstat commit cleanouts	                                           6
sesstat commit cleanouts successfully completed	                           6
sesstat consistent gets	                                               22816
sesstat db block changes	                                      373785
sesstat deferred (CURRENT) block cleanout applications	                   5
sesstat immediate (CURRENT) block cleanout applications	                   1
sesstat no work - consistent read gets	                                  49
sesstat physical reads	                                                  12

6) PDBのSCOTTユーザーでコミットの実行

SCOTT@orcl> commit;

Commit complete.

7) CDBのSYSで統計取得（コミット後）

注）5)と7)で取得した統計の差分のみ記載

ここが主役ですよー。このケースではバッファキャッシュの10%に満たないブロック数になるようにしたINSERT文(繰り返し実行)で 33334ブロックになるようにしました。これらを1度でcommitした場合、すべてのブロックがcommit時にblock cleanoutされるはずです。

では見てみましょう。

SCOTTのセッション統計より、commit cleanouts および commit cleanouts successfully completed　から想定どおり全ブロックがcommit時にcleanoutされていることがわかります！
システム統計はインスタンス全体なのでPDBのそれら統計より大きめにでているのも確認できます。CDB側ではほんの少し　deferred (CURRENT) block cleanout applications　がありますが、管理情報系の遅延ブロッククリーンアウトでしょうね。　
古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #1で紹介したとおり 10%　未満では　commit 時点で該当ブロックすべてcleanoutされることが確認できました。

(CDB）システム統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sysstat	DBWR checkpoint buffers written                                  139
sysstat	DBWR transaction table writes	                                  22
sysstat	DBWR undo block writes	                                          55
sysstat	commit cleanouts	                                       33343
sysstat	commit cleanouts successfully completed                        33343
sysstat	consistent gets	                                               18111
sysstat	db block changes	                                         138
sysstat	deferred (CURRENT) block cleanout applications	                   5
sysstat	no work - consistent read gets	                               10853
sysstat	physical reads	                                                 827
sysstat	physical writes	                                                 139
sysstat	physical writes from cache	                                 139
sysstat	physical writes non checkpoint	                                 139

(PDB)　SCOTTのセッション統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sesstat	commit cleanouts	                                       33334
sesstat	commit cleanouts successfully completed	                       33334
sesstat	db block changes	                                           1

8) PDBのSCOTTユーザーで、遅延ブロッククリーンアウト影響有無確認（対象表を全表走査）

_serial_direct_read = never はdirect path readさせないためのおまじないです。direct path readで読み込まれたケースの動きは別エントリーで見ていく予定なので、direct path readを発生させずtable full scan (ようするにバッファキャッシュに載せる動き)で読み込むよう強制しています。
また、行数が多いのでその時間の短縮のためにautot trace exp statを有効にしてSELECT文を実行させつつ、termout offと同じ効果とauto explainの機能でSELECT文の実行統計からredoの生成有無を確認しています。（redoがあるということはなんらかの更新が行われているわけで、SELECT文の場合は比較的容易に遅延ブロッククリーンアウトの発生を推測できる統計にもなります）
以下のケースでは多少redoが生成されていますが、おそらく　recursive callによるもので、HOGE表のオブジェクトそのものに対するもではなさそうです。（このケースではhoge表のオブジェクトに対する遅延ブロッククリーンアウトや
コミット時のブロッククリーンアウトの観察が主題なので、周りのノイズはあまり気にしなくてもOK（追いかけたい場合は別ですがw)

SCOTT@orcl> set autot trace exp stat
SCOTT@orcl> alter session set "_serial_direct_read" = never;

Session altered.

Elapsed: 00:00:00.00
SCOTT@orcl> select * from hoge;

100000 rows selected.

Elapsed: 00:00:02.59

Execution Plan
----------------------------------------------------------
Plan hash value: 2339479017

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      | 57526 |    55M|  9098   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| HOGE | 57526 |    55M|  9098   (1)| 00:00:01 |
--------------------------------------------------------------------------

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

Statistics
----------------------------------------------------------
         21  recursive calls
         13  db block gets
      40465  consistent gets
          3  physical reads
       2212  redo size
  203382760  bytes sent via SQL*Net to client
      73706  bytes received via SQL*Net from client
       6668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     100000  rows processed

SCOTT@orcl> set autot off

9) CDBのSYSで統計取得（遅延ブロッククリーンアウト有無確認）

注）7)のコミット時点からとの差異のみ記載。

多少ですが、SELECT文でredoが生成されてはいます。これは、commit cleanouts/commit cleanouts successfully completed (commit時に実施されるblock cleanout)と遅延ブロッククリーンアウトの統計の一つ、deferred (CURRENT) block cleanout applications が現れている影響ですね。コミット時点でHOGE表の全ブロックはcleanout済みなので recursive callによる内部管理情報関連で定常的に現れるものと考えられ、この検証では気にするところではないのでスルーしてください。

また、physical reads は、ほぼないため、この全表走査では、物理読み込み（direct path read含む）は、発生していないことも確認できます。
HOGE表はバッファキャッシュに載ったままという意図通りの状態にはなっているようです。
これ、今後のテストケースでも利用するので、キャッシュからエージアウトされないという点が確認できてると、以降の検証やりやすいんです:)

(CDB) システム統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sysstat	DBWR checkpoint buffers written	                               34849
sysstat	DBWR transaction table writes	                                  32
sysstat	DBWR undo block writes	                                         897
sysstat	commit cleanouts	                                         558
sysstat	commit cleanouts successfully completed	                         558
sysstat	consistent gets	                                               69973
sysstat	db block changes 	                                        2862
sysstat	deferred (CURRENT) block cleanout applications	                 311
sysstat	immediate (CURRENT) block cleanout applications	                  28
sysstat	no work - consistent read gets	                               57908
sysstat	physical reads	                                                 812
sysstat	physical writes	                                               34849
sysstat	physical writes from cache	                               34849
sysstat	physical writes non checkpoint	                               34738

(PDB)　SCOTTのセッション統計

SOURCE  NAME　　　　　　　　　　　　　　　　　　　　　　　                     VALUE
------- ---------------------------------------------------- ---------------
sesstat	commit cleanouts	                                           5
sesstat	consistent gets	                                               47037
sesstat	db block changes	                                          38
sesstat	deferred (CURRENT) block cleanout applications 	                   4
sesstat	no work - consistent read gets	                               43103
sesstat	physical reads	                                                 117

まとめ

DMLにより更新されたブロック数が、バッファキャッシュの10%未満のブロック数である場合、commit時にすべてcleanoutされ、対象表では遅延ブロッククリーンアウトは発生しない。
（想定通りなのですが、ちょいと安心w　19cでどう動くか確認してなかってしので少々ドキドキしてたw　のはナイショ）

というわけで、今回はここまで。

いきなり涼しくなって、なんだこりゃ。。。。

---

・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #1
・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #2

---

古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #2

Previously on Mac De Oracle

前回は、遅延ブロッククリーンアウトに限らず、大きく変わったわけでも、最近実装された機能でもないのに意外に知られてないのか、良いところ悪いところ含め、現場でロストしてしまっているような知識って意外と多いのかもねー。なんて感じたので遅延ブロッククリーンアウトネタのURLリンクをまとめてみた。

続編書くにしても、同じようなことやっても面白くないので、ブロックダンプのような方法は使わず、[g]v$sysstatや[g]v$sesstatなどの統計から、ちょいと血糖値や尿酸値高めだよね的な角度からどのような変化が起きるか見ていくことにした :)

環境はVirtualBox上の19cでこれからの主流になるマルチテナントで試してみます。（非マルチテナントでの変化見ててもこれからはあまり役に立たないので）

今日は準備編

VirtualBox
https://www.virtualbox.org/

Pre-Built Developer VMs (for Oracle VM VirtualBox)のDatabase App Development VMとか
https://www.oracle.com/downloads/developer-vm/community-downloads.html

事前に準備しておくスクリプトは以下のとおり。繰り返し実行するので作っておくと便利ですよ。:)

まず最初に、遅延ブロッククリーンアウトはバッファキャッシュの10%ほどのブロックをコミット時にクリーンアウトして、残りを先送りするという基本的なお約束があるので、上記環境のOracle 19cがどの程度のバッファキャッシュなのかとブロックサイズを確認。これ大切ですよ。スクリプト準備する上でも　：）

メモリサイズは大きめですが。。。w　うちのは。(^^;;;

$ VBoxManage -v
6.1.26r145957
$
$ VBoxManage showvminfo 'Oracle DB Developer VM　19.3' | grep -E 'Memory|CPUs'
Memory size:                 16384MB
Number of CPUs:              4
$

コミット時にブロッククリーンアウトされそうなブロック数をざっくり算出すると　42394　ブロックぐらいになりそう。

SYS@orclcdb> show sga

Total System Global Area 4294963960 bytes
Fixed Size                  9143032 bytes
Variable Size             805306368 bytes
Database Buffers         3472883712 bytes
Redo Buffers                7630848 bytes

SYS@orclcdb>
SYS@orclcdb> show parameter db_block_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_block_size                        integer     8192
SYS@orclcdb>
SYS@orclcdb> select ceil( 3472883712 / 8192 * 0.1 ) from dual;

CEIL(3472883712/8192*0.1)
-------------------------
                    42394

Elapsed: 00:00:00.00

42394ブロックを超える程度のサイズのデータを生成するINSERT文と、その範囲に収まるデータ量生成INSERT文スクリプトを作れば良さそうですね。

想定されるブロックに収まる程度の量。1ブロック 8KB　でデフォルトのPCTFREEは10%なのでざっくり6000bytes/rec超えるぐらい。
で、1ブロックに3行ぐらい入るようにすれば面白いかな。。

ということで、

表はなんどもdrop/createするので以下のDDLで。初回は索引を作らず、表のみので影響をみることにする。

$ cat droppurge_create_hoge.sql

drop table hoge purge;
create table hoge (id number, data varchar2(2000));

データ作成（バッファキャッシュの10％未満のデータ登録）
なお、確実に遅延ブロッククリーンアウトの影響を見たいので１行ごとのINSERTを繰り返し、コミット前後の状態の変化も見たいのでcommitも含めていない。（commitは別途実行する）

$ cat insert_rows.sql

begin for i in 1..100000 loop insert into hoge values(i, lpad('*', 2000, '*')); end loop; end;
.
l
/

ブロック数の事前確認

SCOTT@ORCL> select count(distinct dbms_rowid.rowid_block_number(rowid)) as "blocks" from hoge;

    blocks
----------
     33334

データ作成（バッファキャッシュの10％を超えるのデータ登録）
単純にループ回数を倍にして増量。これで事前に算出したバッファキャッシュの10％以上のブロック数は更新される。。。はず。

$ cat insert_rows_2.sql

begin for i in 1..200000 loop insert into hoge values(i, lpad('*', 2000, '*')); end loop; end;
.
l
/

ブロック数の事前確認（20,000ブロックぐらい？は遅延される想定）

SCOTT@ORCL> select count(distinct dbms_rowid.rowid_block_number(rowid)) as "blocks" from hoge;

    blocks
----------
     66667

ここまでが遅延ブロッククリーンアウトを意図的に起こすためのデータ作成SQLスクリプト

以降は、遅延ブロッククリーンアウトの発生等を見るための[g]v$sysstatと[g]v$sestatを取得するスクリプトと、[g]v$sesstatから特定のセッションを取得するためのクライアント情報をセットするスクリプト。

$ cat set_client_info.sql
BEGIN
   DBMS_APPLICATION_INFO.SET_CLIENT_INFO('TargetSession');
END;
.
l
/

システム統計とセッション統計を取得して差分を見ていく必要があるので各統計のスナップショット取得用スクリプトが必要なわけですが、今回はマルチテナント環境。なので、システム統計はCDB全体から、セッション統計は該当するPDBかつ、前述のスクリプトでClient Infoが設定されているセッションに限定するスクリプトを作る必要があるんですよね。DBWRの動きも含めてみたいときって。少し多めに統計名を取得していますが、実際に重要なのはcleanout系の統計ですね。いくつかのテストケースを実施する上で合わせてみておきたい統計も事前に入れてあります:)

$ cat show_stat.sql
set linesize 400
set tab off
set pagesize 1000
col name for a60
col value for 999,999,999,999,999
SELECT
  'sysstat' AS "SOURCE"
  , name
  , value
  , con_id
FROM
 gv$sysstat
WHERE
 name IN (
   'physical writes direct'
   , 'physical writes from cache'
   , 'physical writes non checkpoint'
   , 'consistent gets'
   , 'no work - consistent read gets'
   , 'cleanouts and rollbacks - consistent read gets'
   , 'cleanouts only - consistent read gets'
   , 'deferred (CURRENT) block cleanout applications'
   , 'immediate (CR) block cleanout applications'
   , 'immediate (CURRENT) block cleanout applications'
   , 'commit cleanout failures: block lost'
   , 'commit cleanout failures: buffer being written'
   , 'commit cleanout failures: callback failure'
   , 'commit cleanout failures: cannot pin'
   , 'commit cleanout failures: hot backup in progress'
   , 'commit cleanout failures: write disabled'
   , 'commit cleanouts'
   , 'commit cleanouts successfully completed'
   , 'db block changes'
   , 'physical read requests'
   , 'physical reads'
   , 'physical reads direct'
   , 'physical write requests'
   , 'physical writes'
   , 'physical writes direct'
   , 'DBWR checkpoint buffers written'
   , 'DBWR thread checkpoint buffers written'
   , 'DBWR tablespace checkpoint buffers written'
   , 'DBWR parallel query checkpoint buffers written'
   , 'DBWR object drop buffers written'
   , 'DBWR transaction table writes'
   , 'DBWR undo block writes'
   , 'DBWR revisited being-written buffer'
   , 'DBWR lru scans'
   , 'DBWR checkpoints'
   , 'DBWR fusion writes'
   , 'transaction tables consistent reads - undo records applied'
   , 'transaction tables consistent read rollbacks'
  )
UNION ALL
SELECT
  'sesstat' AS "SOURCE"
  , name
  , value
  , vsesstat.con_id
FROM
 gv$sesstat vsesstat
 inner join gv$statname vstatnam
 on
   vsesstat.statistic# = vstatnam.statistic#
WHERE
 name IN (
   'physical writes direct'
   , 'physical writes from cache'
   , 'physical writes non checkpoint'
   , 'consistent gets'
   , 'no work - consistent read gets'
   , 'cleanouts and rollbacks - consistent read gets'
   , 'cleanouts only - consistent read gets'
   , 'deferred (CURRENT) block cleanout applications'
   , 'immediate (CR) block cleanout applications'
   , 'immediate (CURRENT) block cleanout applications'
   , 'commit cleanout failures: block lost'
   , 'commit cleanout failures: buffer being written'
   , 'commit cleanout failures: callback failure'
   , 'commit cleanout failures: cannot pin'
   , 'commit cleanout failures: hot backup in progress'
   , 'commit cleanout failures: write disabled'
   , 'commit cleanouts'
   , 'commit cleanouts successfully completed'
   , 'db block changes'
   , 'physical read requests'
   , 'physical reads'
   , 'physical reads direct'
   , 'physical write requests'
   , 'physical writes'
   , 'physical writes direct'
   , 'DBWR checkpoint buffers written'
   , 'DBWR thread checkpoint buffers written'
   , 'DBWR tablespace checkpoint buffers written'
   , 'DBWR parallel query checkpoint buffers written'
   , 'DBWR object drop buffers written'
   , 'DBWR transaction table writes'
   , 'DBWR undo block writes'
   , 'DBWR revisited being-written buffer'
   , 'DBWR lru scans'
   , 'DBWR checkpoints'
   , 'DBWR fusion writes'
   , 'transaction tables consistent reads - undo records applied'
   , 'transaction tables consistent read rollbacks'
  )
  and sid = (
    select
      sid
    from
      gv$session
    where
      username = upper('&1')
      and client_info = 'TargetSession'
  )
order by
  4, 1, 2
;

undefine 1

ちなみに、統計を使って状況を確認する方法って意外に利用されているんですよね。日本だとあまり活用されてないようにも感じることは多いのですが、日々の統計を追っかけてると、どのメトリックが高く跳ね上がるのか把握できるので知ってて損することはないと思います:)

そういえば、Tanel PoderのSnapperもその手のツールではありますね。
Session Snapper
http://tech.e2sn.com/oracle-scripts-and-tools/session-snapper

私の過去のセッションでもElappsed Timeを見せないでチューニング効果を見てもらうネタとしてシステム統計を使ってたりします。
db tech showcase Tokyo 2013 - A35 特濃JPOUG：潮溜まりでジャブジャブ、SQLチューニング
https://www.slideshare.net/discus_hamburg/db-tech-showcase-tokyo-2013-a35-sql

少々脱線しますが、
最近、VirtualBox、なつかしー。なんて言う方もいますが、古いバージョンのOracleを残しておけるので、リリース毎の動きの差などを見たい場合は便利なのですよーw（クラウドだと強制アップグレードされちゃうので旧バージョンとの動作比較をネタにしたいときなどには向いてないw）

次回へつづく

---

東京では救急車のサイレンがまだまだ通常より多く聞こえます。。。。

Stay home, Stay Safe and Stay Hydrated.

---

・古くて新しい？ 遅延ブロッククリーンアウト (deferred block cleanout) #1

---

RDS Oracle 雑多なメモ#21 / DBMS_DATAPUMPパッケージ Schema mode de expdp/impdp - metadata onlyとデータのインポート

Previously, Mac De Oracle...

RDS Oracle 雑多なメモ#20 / DBMS_DATAPUMPパッケージ　Schema mode de expdp/impdpの準備 SQL_FILEモードでDDL抜き出し

でした。

今回は、RDS　Oracleへスキーマ単位のインポートでメタデータだけをインポートするにはどうするかというおはなし。

メタデータだけをインポートするにはこれまでに何度か話題にしたエクスポートされたオブジェクトとその階層を表すオブジェクトパスが重要な意味を持っています。

まずはフルエクスポートログにリストされるオブジェクトパスの例をご覧ください。

Processing object type DATABASE_EXPORT/EARLY_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA
Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/TABLE_DATA
Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA
Processing object type DATABASE_EXPORT/SCHEMA/PACKAGE_BODIES/PACKAGE/PACKAGE_BODY
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/STATISTICS/FUNCTIONAL_INDEX/INDEX_STATISTICS
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type DATABASE_EXPORT/STATISTICS/MARKER
Processing object type DATABASE_EXPORT/PRE_SYSTEM_IMPCALLOUT/MARKER
Processing object type DATABASE_EXPORT/PRE_INSTANCE_IMPCALLOUT/MARKER
Processing object type DATABASE_EXPORT/TABLESPACE
Processing object type DATABASE_EXPORT/PROFILE
Processing object type DATABASE_EXPORT/SCHEMA/USER
Processing object type DATABASE_EXPORT/ROLE
Processing object type DATABASE_EXPORT/RADM_FPTM
Processing object type DATABASE_EXPORT/GRANT/SYSTEM_GRANT/PROC_SYSTEM_GRANT
Processing object type DATABASE_EXPORT/SCHEMA/GRANT/SYSTEM_GRANT
Processing object type DATABASE_EXPORT/SCHEMA/ROLE_GRANT
Processing object type DATABASE_EXPORT/SCHEMA/DEFAULT_ROLE
Processing object type DATABASE_EXPORT/SCHEMA/ON_USER_GRANT
Processing object type DATABASE_EXPORT/SCHEMA/TABLESPACE_QUOTA
Processing object type DATABASE_EXPORT/RESOURCE_COST
Processing object type DATABASE_EXPORT/TRUSTED_DB_LINK
Processing object type DATABASE_EXPORT/SCHEMA/SEQUENCE/SEQUENCE
Processing object type DATABASE_EXPORT/DIRECTORY/DIRECTORY
Processing object type DATABASE_EXPORT/DIRECTORY/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type DATABASE_EXPORT/DIRECTORY/GRANT/WITH_GRANT_OPTION/OBJECT_GRANT
Processing object type DATABASE_EXPORT/CONTEXT
Processing object type DATABASE_EXPORT/SCHEMA/PUBLIC_SYNONYM/SYNONYM
Processing object type DATABASE_EXPORT/SCHEMA/TYPE/TYPE_SPEC
Processing object type DATABASE_EXPORT/SYSTEM_PROCOBJACT/PRE_SYSTEM_ACTIONS/PROCACT_SYSTEM
Processing object type DATABASE_EXPORT/SYSTEM_PROCOBJACT/PROCOBJ
Processing object type DATABASE_EXPORT/SYSTEM_PROCOBJACT/POST_SYSTEM_ACTIONS/PROCACT_SYSTEM
Processing object type DATABASE_EXPORT/SCHEMA/PROCACT_SCHEMA
Processing object type DATABASE_EXPORT/EARLY_OPTIONS/VIEWS_AS_TABLES/TABLE
Processing object type DATABASE_EXPORT/EARLY_POST_INSTANCE_IMPCALLOUT/MARKER
Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/TABLE

上記オブジェクトパスツリーを一部省略しつつ見やすくすると以下のようなツリー構造になっているのが理解しやすいはず。

図にも書いていますが、メタデータのみをインポートするにはデータを除外(Exclude)してしまえばよいわけです。

DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA

また、同じツリーの階層にあるオブジェクトもスキーマレベルのインポートではインポートされないということも理解しやすいはずです。：）

なお、DATAPUMPが扱うオブジェクトパスの詳細は　
データベース・リファレンス - 6.238 SCHEMA_EXPORT_OBJECTS
を参照してくださいね。知らない方は多いですが、DATAPUMPと仲良くなるためには必要なビューです。

---

では、スキーマモードのメタデータオンリーインポートの仕込みから
同じデータベースへスキーマをインポートするので事前に削除しておきます。

BILL> drop user hoge cascade;

User dropped.

BILL> drop profile fizzbuzz;

Profile dropped.

BILL> drop role fizzbuzz;

Role dropped.

BILL> drop tablespace fizzbuzz including contents and datafiles;

Tablespace dropped.

たとえばこの状態でスキーマレベルのインポートを行ってしまうと、もう、想像はできていると思いますが、依存オブジェクト不足によりインポートは失敗します。
ユーザーのデフォルト表領域や依存するプロファイルが存在しない状態ではインポート時に実行されるCREATE USER文がエラーとなりインポートはエラーで終了することになります。

BILL> @imp_schema_metadataonly data_pump_dir fullexp hoge
Master table "BILL"."SYS_IMPORT_SCHEMA_03" successfully loaded/unloaded
Starting "BILL"."SYS_IMPORT_SCHEMA_03":
Processing object type DATABASE_EXPORT/SCHEMA/USER
ORA-39083: Object type USER:"HOGE" failed to create with error:
ORA-02380: profile FIZZBUZZ does not exist

Failing sql is:
 CREATE USER "HOGE" IDENTIFIED BY VALUES 

...中略...

TABLESPACE "FIZZBUZZ" TEMPORARY TABLESPACE "TEMP" PROFILE "FIZZBUZZ"

Processing object type DATABASE_EXPORT/SCHEMA/ROLE_GRANT
ORA-39083: Object type ROLE_GRANT failed to create with error:
ORA-01917: user or role 'HOGE' does not exist

Failing sql is:
 GRANT "CONNECT" TO "HOGE"

ORA-39083: Object type ROLE_GRANT failed to create with error:
ORA-01924: role 'FIZZBUZZ' not granted or does not exist

Failing sql is:
 GRANT "FIZZBUZZ" TO "HOGE"

Processing object type DATABASE_EXPORT/SCHEMA/DEFAULT_ROLE
ORA-39083: Object type DEFAULT_ROLE:"HOGE" failed to create with error:
ORA-01918: user 'HOGE' does not exist

...中略...

Job "BILL"."SYS_IMPORT_SCHEMA_03" completed with 7 error(s) at Fri Jul 24 17:51:45 2020 elapsed 0 00:00:03

PL/SQL procedure successfully completed.

では、上記のようなエラーを回避するため、前回フルエクスポートから取り出したDDL を実行して作成します。

BILL> CREATE BIGFILE TABLESPACE "FIZZBUZZ" DATAFILE
   2  SIZE 104857600
   3  AUTOEXTEND ON NEXT 104857600 MAXSIZE 1073741824
   4  LOGGING ONLINE PERMANENT BLOCKSIZE 8192
   5  EXTENT MANAGEMENT LOCAL AUTOALLOCATE DEFAULT
   6  NOCOMPRESS  SEGMENT SPACE MANAGEMENT AUTO;

Tablespace created.

BILL>  CREATE ROLE "FIZZBUZZ";

Role created.

BILL> CREATE PROFILE "FIZZBUZZ"
   2  LIMIT
   3    COMPOSITE_LIMIT DEFAULT
   4    SESSIONS_PER_USER DEFAULT
   5    CPU_PER_SESSION DEFAULT
   6    CPU_PER_CALL DEFAULT
   7    LOGICAL_READS_PER_SESSION DEFAULT
   8    LOGICAL_READS_PER_CALL DEFAULT
   9    IDLE_TIME UNLIMITED
  10    CONNECT_TIME DEFAULT
  11    PRIVATE_SGA DEFAULT
  12    FAILED_LOGIN_ATTEMPTS DEFAULT
  13    PASSWORD_LIFE_TIME DEFAULT
  14    PASSWORD_REUSE_TIME DEFAULT
  15    PASSWORD_REUSE_MAX DEFAULT
  16    PASSWORD_VERIFY_FUNCTION DEFAULT
  17    PASSWORD_LOCK_TIME DEFAULT
  18    PASSWORD_GRACE_TIME DEFAULT
  19    INACTIVE_ACCOUNT_TIME DEFAULT ;

Profile created.

準備ができたので、メタデータオンリーのスキーマモードインポートを試してみます。
スキーマ以下のオブジェクトはインポート（統計情報をフィルタするのを忘れましたがw）できました。hoge表には1行だけデータがありますがデータはインポートされていないことが確認できるはずです。

BILL> @imp_schema_metadataonly data_pump_dir fullexp hoge
Master table "BILL"."SYS_IMPORT_SCHEMA_04" successfully loaded/unloaded
Starting "BILL"."SYS_IMPORT_SCHEMA_04":
Processing object type DATABASE_EXPORT/SCHEMA/USER
Processing object type DATABASE_EXPORT/SCHEMA/ROLE_GRANT
Processing object type DATABASE_EXPORT/SCHEMA/DEFAULT_ROLE
Processing object type DATABASE_EXPORT/SCHEMA/TABLESPACE_QUOTA
Processing object type DATABASE_EXPORT/SCHEMA/PROCACT_SCHEMA
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type DATABASE_EXPORT/STATISTICS/MARKER
Job "BILL"."SYS_IMPORT_SCHEMA_04" successfully completed at Fri Jul 24 17:56:34 2020 elapsed 0 00:00:13

PL/SQL procedure successfully completed.

BILL> select username from dba_users where username='HOGE';

USERNAME
------------------------------
HOGE

BILL> select count(1) from hoge.hoge;

  COUNT(1)
----------
         0

では次にデータだけをインポートしてみます。
TABLE_DATAのみをインポートする方法と、スキーマインポートで表が存在する場合に、データをTRUNCATE後、データインポートする方法があります。（表が存在している場合のデフォルトの動作はデータインポートのスキップです）
以下の例では 通常 のスキーマインポートで表が存在する場合 、既存データをTRUNCATEして データをインポートする方法で行ってます。ユーザーが存在する場合にはCREATE USERは失敗し表が存在した場合にtruncate後にデータがインポートされます

BILL> @imp_schema data_pump_dir fullexp hoge
Master table "BILL"."SYS_IMPORT_SCHEMA_01" successfully loaded/unloaded
Starting "BILL"."SYS_IMPORT_SCHEMA_01":
Processing object type DATABASE_EXPORT/SCHEMA/USER
ORA-31684: Object type USER:"HOGE" already exists

Processing object type DATABASE_EXPORT/SCHEMA/ROLE_GRANT
Processing object type DATABASE_EXPORT/SCHEMA/DEFAULT_ROLE
Processing object type DATABASE_EXPORT/SCHEMA/TABLESPACE_QUOTA
Processing object type DATABASE_EXPORT/SCHEMA/PROCACT_SCHEMA
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE
Table "HOGE"."HOGE" exists and has been truncated. 
Data will be loaded but all dependent metadata will be skipped due to table_exists_action of truncate
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA
. . imported "HOGE"."HOGE"                               5.046 KB       1 rows
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type DATABASE_EXPORT/STATISTICS/MARKER
Job "BILL"."SYS_IMPORT_SCHEMA_01" completed with 1 error(s) at Fri Jul 24 18:01:30 2020 elapsed 0 00:00:05

PL/SQL procedure successfully completed.

BILL> select count(1) from hoge.hoge;

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

スクリプトの例は以下のとおり
DBMS＿DATAPUMP．METADATA＿FILTER()プロシージャでデータを示すオブジェクトパス（DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA）を除外しているところがポイント

BILL> !cat imp_schema_metadataonly.sql
SET VERIFY OFF
SET SERVEROUTPUT ON
DECLARE
  v4Debug VARCHAR2(200);
  cDirectory CONSTANT VARCHAR2(30) := UPPER('&1');
  cDumpFileName CONSTANT VARCHAR2(64) := '&2'||'.dmp';
  cLogFileName CONSTANT VARCHAR2(64) := '&2'||'.log';
  cSchemaName CONSTANT VARCHAR2(30) := UPPER('&3');
  cExcludePath CONSTANT VARCHAR2(128) := 'DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA';
  i NUMBER;
  vDataPumpJobHandle NUMBER;
  vProgress_ratio NUMBER;
  vJobState VARCHAR2(30);
  oLogEntry ku$_LogEntry;
  oStatus ku$_Status;
BEGIN
  DBMS_OUTPUT.ENABLE;

  v4Debug := 'OPEN';
  vDataPumpJobHandle
   := DBMS_DATAPUMP.OPEN (
     operation => 'IMPORT'
     ,job_mode => 'SCHEMA'
     ,job_name => NULL
     ,remote_link => NULL
   );

  v4Debug := 'ADD_FILE - dumpfile';
  DBMS_DATAPUMP.ADD_FILE (
    handle => vDataPumpJobHandle
    ,filename => cDumpFileName
    ,directory => cDirectory
    ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_DUMP_FILE
  );

  v4Debug := 'ADD_FILE - logfile';
  DBMS_DATAPUMP.ADD_FILE (
    handle => vDataPumpJobHandle
    ,filename => cLogFileName
    ,directory => cDirectory
    ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_LOG_FILE
  );

  v4Debug := 'METADATA_FILTER - schema name';
  DBMS_DATAPUMP.METADATA_FILTER (
    handle => vDataPumpJobHandle
    ,name => 'SCHEMA_LIST'
    ,value => '''' || cSchemaName || ''''
  );

  v4Debug := 'EXCLUDE_PATH='||cExcludePath;
  DBMS_DATAPUMP.METADATA_FILTER (
    handle => vDataPumpJobHandle
    ,name => 'EXCLUDE_PATH_LIST'
    ,value => '''' || cExcludePath || ''''
  );

  v4Debug := 'START_JOB';
  DBMS_DATAPUMP.START_JOB (
    handle => vDataPumpJobHandle
  );

  v4Debug := 'JOB_STATE';
  vProgress_ratio := 0;
  vJobState := 'UNDEFINED';
  WHILE (vJobState != 'COMPLETED') AND (vJobState != 'STOPPED') LOOP
    DBMS_DATAPUMP.GET_STATUS (
      vDataPumpJobHandle
      ,DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR
        + DBMS_DATAPUMP.KU$_STATUS_JOB_STATUS
        + DBMS_DATAPUMP.KU$_STATUS_WIP
      ,-1
      ,vJobState
      ,oStatus
    );

    IF (BITAND(oStatus.mask, DBMS_DATAPUMP.KU$_STATUS_WIP) != 0)
    THEN
      oLogEntry := oStatus.wip;
    ELSE
      IF (BITAND(oStatus.mask, DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR) != 0)
      THEN
        oLogEntry := oStatus.error;
      ELSE
        oLogEntry := NULL;
      END IF;
    END IF;
    IF oLogEntry IS NOT NULL
    THEN
      i := oLogEntry.FIRST;
      WHILE i IS NOT NULL LOOP
        DBMS_OUTPUT.PUT_LINE(oLogEntry(i).LogText);
        i := oLogEntry.NEXT(i);
      END LOOP;
    END IF;
  END LOOP;

  DBMS_DATAPUMP.DETACH(vDataPumpJobHandle);
EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE(sqlerrm());
    DBMS_OUTPUT.PUT_LINE(v4Debug);
    RAISE;
END;
/

UNDEFINE 1
UNDEFINE 2
UNDEFINE 3
SET SERVEROUTPUT OFF
SET VERIFY ON

DBMS_DATAPUMP.SET_PARAMETER()でTABLE_EXISTS_ACTION (表が存在する場合)でTRUNCATE（既存データのトランケート後データをインポート)する支持をしています。

BILL> !cat imp_schema.sql
SET VERIFY OFF
SET SERVEROUTPUT ON
DECLARE
  v4Debug VARCHAR2(200);
  cDirectory CONSTANT VARCHAR2(30) := UPPER('&1');
  cDumpFileName CONSTANT VARCHAR2(64) := '&2'||'.dmp';
  cLogFileName CONSTANT VARCHAR2(64) := '&2'||'.log';
  cSchemaName CONSTANT VARCHAR2(30) := UPPER('&3');
  i NUMBER;
  vDataPumpJobHandle NUMBER;
  vProgress_ratio NUMBER;
  vJobState VARCHAR2(30);
  oLogEntry ku$_LogEntry;
  oStatus ku$_Status;
BEGIN
  DBMS_OUTPUT.ENABLE;

  v4Debug := 'OPEN';
  vDataPumpJobHandle
   := DBMS_DATAPUMP.OPEN (
     operation => 'IMPORT'
     ,job_mode => 'SCHEMA'
     ,remote_link => NULL
   );

  v4Debug := 'ADD_FILE - dumpfile';
  DBMS_DATAPUMP.ADD_FILE (
    handle => vDataPumpJobHandle
    ,filename => cDumpFileName
    ,directory => cDirectory
    ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_DUMP_FILE
  );

  v4Debug := 'ADD_FILE - logfile';
  DBMS_DATAPUMP.ADD_FILE (
    handle => vDataPumpJobHandle
    ,filename => cLogFileName
    ,directory => cDirectory
    ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_LOG_FILE
  );

  v4Debug := 'METADATA_FILTER - schema name';
  DBMS_DATAPUMP.METADATA_FILTER (
    handle => vDataPumpJobHandle
    ,name => 'SCHEMA_LIST'
    ,value => '''' || cSchemaName || ''''
  );

  v4Debug := 'TABLE_EXISTS_ACTION=TRUNCATE';
  DBMS_DATAPUMP.SET_PARAMETER (
    handle => vDataPumpJobHandle
    ,name => 'TABLE_EXISTS_ACTION'
    ,value => 'TRUNCATE'
  );

  v4Debug := 'START_JOB';
  DBMS_DATAPUMP.START_JOB (
    handle => vDataPumpJobHandle
  );

  v4Debug := 'JOB_STATE';
  vProgress_ratio := 0;
  vJobState := 'UNDEFINED';
  WHILE (vJobState != 'COMPLETED') AND (vJobState != 'STOPPED') LOOP
    DBMS_DATAPUMP.GET_STATUS (
      vDataPumpJobHandle
      ,DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR
        + DBMS_DATAPUMP.KU$_STATUS_JOB_STATUS
        + DBMS_DATAPUMP.KU$_STATUS_WIP
      ,-1
      ,vJobState
      ,oStatus
    );

    IF (BITAND(oStatus.mask, DBMS_DATAPUMP.KU$_STATUS_WIP) != 0)
    THEN
      oLogEntry := oStatus.wip;
    ELSE
      IF (BITAND(oStatus.mask, DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR) != 0)
      THEN
        oLogEntry := oStatus.error;
      ELSE
        oLogEntry := NULL;
      END IF;
    END IF;
    IF oLogEntry IS NOT NULL
    THEN
      i := oLogEntry.FIRST;
      WHILE i IS NOT NULL LOOP
        DBMS_OUTPUT.PUT_LINE(oLogEntry(i).LogText);
        i := oLogEntry.NEXT(i);
      END LOOP;
    END IF;
  END LOOP;

  DBMS_DATAPUMP.DETACH(vDataPumpJobHandle);
EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE(sqlerrm());
    DBMS_OUTPUT.PUT_LINE(v4Debug);
    RAISE;
END;
/

UNDEFINE 1
UNDEFINE 2
UNDEFINE 3
SET SERVEROUTPUT OFF
SET VERIFY ON

今回は、上記２つのスクリプトに分けましたが、１つにまとめるように作り変えればより便利できますよ！　それはみなさんへの宿題w　

ということで今回のネタはおしまい :)

---

・Data Pumpも癖モノだよね〜w　その１ - queryパラメーターの解析タイミング
・Data Pumpも癖モノだよね〜w　その２ - Materialized ViewをTableとして移行する
・Data Pumpも癖モノだよね〜w　その3 - dbms_job と dbms_scheduler との複雑な関係
・Data Pumpも癖モノだよね〜w　その4 - schemaモードでMviewを他のPDBへ複製
・Data Pumpも癖モノだよね〜w　その4と1/2 - schemaモードでMviewを他のPDBへ複製 (紛らわしいステータスw）
・Data Pumpも癖モノだよね〜w　その5 - schemaモードでMviewを他のPDBへ複製（オプジェクトパス de 絞り込み）
・Data Pumpも癖モノだよね〜w　その6 - schemaモードでMviewを他のPDBへ複製（オプジェクトパスが不足すると...

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ
・RDS Oracle 雑多なメモ#13 / FAQ
・RDS Oracle 雑多なメモ#14 - おまけ　/ FAQ
・RDS Oracle 雑多なメモ#15 - おまけのおまけ / FAQ
・RDS Oracle 雑多なメモ#16 - 再び:) / FAQ
・RDS Oracle 雑多なメモ#17/ FAQ
・RDS Oracle 雑多なメモ#18 / DBMS_DATAPUMPパッケージ de expdp/impdp
・RDS Oracle 雑多なメモ#19 FAQ / DBMS_DATAPUMPパッケージ de ジョブの停止
・RDS Oracle 雑多なメモ#20 / DBMS_DATAPUMPパッケージ　Schema mode de expdp/impdpの準備 SQL_FILEモードでDDL抜き出し

RDS Oracle 雑多なメモ#20 / DBMS_DATAPUMPパッケージ Schema mode de expdp/impdpの準備 SQL_FILEモードでDDL抜き出し

RDS Oracle 雑多なメモ#20 / DBMS_DATAPUMPパッケージ　Schema mode de expdp/impdpの準備

Previously, Mac De Oracle...

RDS Oracle 雑多なメモ#19 FAQ / DBMS_DATAPUMPパッケージ de ジョブの停止

でした。

今回は、RDS　Oracleへスキーマ単位でインポートを行う準備に必要などを。

実は、RDS Oracleでは、フルインポートはしないようにと記載されています。ということは、つまりスキーマモードでのインポートと、それ以下の単位でのインポートのみを行うこと、となっています。ここがポイント

詳細は以下マニュアルを参照ください。
Amazon RDS での Oracle へのデータのインポート

フルモードでインポートできない場合の注意点として、スキーマレベルでインポートする際に必要となる可能性のあるオブジェクトは事前に何がしかの方法で作成しておく必要があるということを意味します。
代表的なオブジェクトは以下、

• ユーザーのデフォルトTABLESPACE（USERS表をそのまま利用しているケースは希だと思います）
• ユーザーのPROFILE（パスワード有効期限管理などで利用しているケースは多いかも）
• ROLE（直接付与権限以外はロールを付与して権限を管理することは多いはずです）
• DIRECTORY（Oracle側で事前に作成しているディレクトリ以外のディレクトリへのアクセスが必要な場合にはディレクトリオブジェクトも事前に作成しておく必要があります）

さらに、スキーマ間で依存している場合、特に、他のスキーマのオブジェクト権限を付与する必要がある場合は、スキーマをインポートする順番にも気を遣う必要も出てきます。
インポート時にエラーが出ないものもありますが。。それは今回のテーマではないのでこの辺でw
（依存しているオブジェクトは事前にALL/DBA_DEPENDENCIESビューを利用して調査しておくとよいでしょうね）

---

では、DDLを取得する前に、ネタを仕込んでおきましょう。

表領域 fizzbuzz をデフォルト表領域とし、プロファイル fizzbuzz　が設定されたユーザー hoge　を作成します。
また、connectロールとresourceロールを付与された　 fizzbuzz　ロールが hoge に付与されているとします。

表領域の追加

BILL> create tablespace fizzbuzz datafile size 100m autoextend on maxsize 1g;

Tablespace created.

プロファイルの追加

BILL> create profile fizzbuzz limit idle_time unlimited;

Profile created.

ロールの追加

BILL> create role fizzbuzz;

Role created.

BILL> grant connect to fizzbuzz;

Grant succeeded.

BILL> grant resource to fizzbuzz;

Grant succeeded.

ユーザーの作成（デフォルト表領域とプロファイルの指定）

BILL> create user hoge identified by xxxxxxxxxxxxxxxx
  2  default tablespace fizzbuzz
  3  temporary tablespace temp
  4  quota unlimited on fizzbuzz
  5  profile fizzbuzz;

User created.

ロールの付与

BILL> grant fizzbuzz to hoge;

Grant succeeded.

上記のようなユーザーだとするとスキーマ単位のインポート前に表領域の作成、プロファイルの作成、ロールの作成が必要になりますよね。
（スキーマレベルのインポートでは依存オブジェクトが自動的にインポートされるわけでは無いので）

また、元のデータベースでOracle Managed Fileを利用した表領域では無い場合にはOracle Managed Fileを利用した表領域として再作成してあげる必要あります。（ここも重要。元のデータベースもOracle Managed fileを利用していればそのまま利用できます）

ということで、DBMS_METADATA.GET_DDL()または、フルエクスポートしたData Pumpのダンプファイルファイルから上記に該当するDDLを抜き出し、事前にオブジェクトを作成しておく必要がありますよね。
（DDLソースコード管理されているのであれば、それらを再利用することも可能だとは思いますが、世の中広いのでそんな管理されていないところも多いでしょうし。DDLを取り出す複数の方法は覚えてて損は無いですよ :）

今回は、フルエクスポートダンプファイルがあるので、そこからData Pump APIを利用して取り出してみようと思います。(DBMS_METADATA.GET_DDL()の方が楽だとは思います。個人的にはw)

フルダンプからDDLを取り出す際でも、重要なのがオブジェクトパス（このパスの階層を意識していないと思わぬ失敗をするのは昔のエントリの通り）ですが、今回は比較的シンプルなので確認してみましょう。

事前にエクスポートのログから以下のパスを探し出しておきます。
（今回の例では、表領域とプロファイル、それにロールへのオブジェクトパスです。以下がそのオブジェクトパス）

Processing object type DATABASE_EXPORT/TABLESPACE
Processing object type DATABASE_EXPORT/PROFILE
Processing object type DATABASE_EXPORT/ROLE

余談ですが、同じ階層オブジェクトパスにスキーマオブジェクトのパス(DATABASE_EXPORT/SCHEMA)が存在しています。同じ階層なので、スキーマレベルのインポートではTABLESPACE/ROLE/PROFILEはインポートされることはありません。（この階層構造を理解できれば楽）
DATABASE_EXPORT/SCHEMA以下がインポートの対象になるので、メタデータフィルターでEXCLUDE または INCLUDEするか制御できることになります。TABLESPACE,PROFILEやROLEはSCHEMAと同レベルなのでそもそも対象外となりフィルタすることはできません。

Processing object type DATABASE_EXPORT/SCHEMA/

理屈がわかれば癖の強いDATAPUMPなんてw　

では、DDLを取り出してみましょう。

前提のオブジェクトを含むフルエクスポートダンプファイル fullexp.dmp　は事前に取得済みであるとします。

BILL> @extract_ddl data_pump_dir fullexp DATABASE_EXPORT/TABLESPACE'',''DATABASE_EXPORT/PROFILE'',''DATABASE_EXPORT/ROLE
Master table "BILL"."SYS_SQL_FILE_FULL_17" successfully loaded/unloaded
Starting "BILL"."SYS_SQL_FILE_FULL_17":
Processing object type DATABASE_EXPORT/TABLESPACE
Processing object type DATABASE_EXPORT/PROFILE
Processing object type DATABASE_EXPORT/ROLE
Job "BILL"."SYS_SQL_FILE_FULL_17" successfully completed at Sun Jul 19 19:12:00 2020 elapsed 0 00:00:02

PL/SQL procedure successfully completed.

取り出したDDLを確認します

BILL> @cat_file data_pump_dir fullexp.txt

TEXT
-----------------------------------------------------------------------------

...中略...

-- new object type path: DATABASE_EXPORT/TABLESPACE
...中略...
CREATE BIGFILE TABLESPACE "FIZZBUZZ" DATAFILE
  SIZE 104857600
  AUTOEXTEND ON NEXT 104857600 MAXSIZE 1073741824
  LOGGING ONLINE PERMANENT BLOCKSIZE 8192
  EXTENT MANAGEMENT LOCAL AUTOALLOCATE DEFAULT
 NOCOMPRESS  SEGMENT SPACE MANAGEMENT AUTO;
-- new object type path: DATABASE_EXPORT/PROFILE
...中略...
 CREATE PROFILE "FIZZBUZZ"
    LIMIT
         COMPOSITE_LIMIT DEFAULT
         SESSIONS_PER_USER DEFAULT
         CPU_PER_SESSION DEFAULT
         CPU_PER_CALL DEFAULT
         LOGICAL_READS_PER_SESSION DEFAULT
         LOGICAL_READS_PER_CALL DEFAULT
         IDLE_TIME UNLIMITED
         CONNECT_TIME DEFAULT
         PRIVATE_SGA DEFAULT
         FAILED_LOGIN_ATTEMPTS DEFAULT
         PASSWORD_LIFE_TIME DEFAULT
         PASSWORD_REUSE_TIME DEFAULT
         PASSWORD_REUSE_MAX DEFAULT
         PASSWORD_VERIFY_FUNCTION DEFAULT
         PASSWORD_LOCK_TIME DEFAULT
         PASSWORD_GRACE_TIME DEFAULT
         INACTIVE_ACCOUNT_TIME DEFAULT ;
-- new object type path: DATABASE_EXPORT/ROLE
...中略...
 CREATE ROLE "FIZZBUZZ";
...中略...

スキーマ hogeインポート前に作成が必要なオブジェクトのDDLを取得できました。

これでスキーマレベルのインポート準備完了。
つづく。

参考）
DDLをダンプファイルから取り出すスクリプト例は以下の通り。DBMS_DATAPUMP.OPEN()関数でoperationに’SQL_FILE'を渡しているところとDBMS_DATAPUMP.METADATA_FILTER()プロシージャで取り出すDDLのオブジェクトパスリストを渡している箇所がポイントです
PL/SQLパッケージおよびタイプ・リファレンス - 47 DBMS_DATAPUMP

BILL> !cat extract_ddl.sql
SET VERIFY OFF
SET SERVEROUTPUT ON
DECLARE
  v4Debug VARCHAR2(50);
  cDirectory CONSTANT VARCHAR2(30) := UPPER('&1');
  cDumpFileName CONSTANT VARCHAR2(64) := '&2'||'.dmp';
  cLogFileName CONSTANT VARCHAR2(64) := '&2'||'.log';
  cDdlFileName CONSTANT VARCHAR2(64) := '&2'||'.txt';
  cPathList CONSTANT VARCHAR2(4000) := UPPER('&3');
  i NUMBER;
  vDataPumpJobHandle NUMBER;
  vProgress_ratio NUMBER;
  vJobState VARCHAR2(30);
  oLogEntry ku$_LogEntry;
  oStatus ku$_Status;
BEGIN
  DBMS_OUTPUT.ENABLE;

  v4Debug := 'OPEN';
  vDataPumpJobHandle
   := DBMS_DATAPUMP.OPEN (
     operation => 'SQL_FILE'
     ,job_mode => 'FULL'
     ,remote_link => NULL
   );

  v4Debug := 'ADD_FILE - dumpfile';
  DBMS_DATAPUMP.ADD_FILE (
    handle => vDataPumpJobHandle
    ,filename => cDumpFileName
    ,directory => cDirectory
    ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_DUMP_FILE
  );

  v4Debug := 'ADD_FILE - logfile';
  DBMS_DATAPUMP.ADD_FILE (
    handle => vDataPumpJobHandle
    ,filename => cLogFileName
    ,directory => cDirectory
    ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_LOG_FILE
  );

  v4Debug := 'ADD_FILE - Ddlfile';
  DBMS_DATAPUMP.ADD_FILE (
    handle => vDataPumpJobHandle
    ,filename => cDdlFileName
    ,directory => cDirectory
    ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_SQL_FILE
  );

  v4Debug := 'METADATA_FILTER - schema name';
  DBMS_DATAPUMP.METADATA_FILTER (
    handle => vDataPumpJobHandle
    ,name => 'INCLUDE_PATH_LIST'
    ,value => '''' || cPathList || ''''
  );

  v4Debug := 'START_JOB';
  DBMS_DATAPUMP.START_JOB (
    handle => vDataPumpJobHandle
  );

  v4Debug := 'JOB_STATE';
  vProgress_ratio := 0;
  vJobState := 'UNDEFINED';
  WHILE (vJobState != 'COMPLETED') AND (vJobState != 'STOPPED') LOOP
    DBMS_DATAPUMP.GET_STATUS (
      vDataPumpJobHandle
      ,DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR
        + DBMS_DATAPUMP.KU$_STATUS_JOB_STATUS
        + DBMS_DATAPUMP.KU$_STATUS_WIP
      ,-1
      ,vJobState
      ,oStatus
    );

    IF (BITAND(oStatus.mask, DBMS_DATAPUMP.KU$_STATUS_WIP) != 0)
    THEN
      oLogEntry := oStatus.wip;
    ELSE
      IF (BITAND(oStatus.mask, DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR) != 0)
      THEN
        oLogEntry := oStatus.error;
      ELSE
        oLogEntry := NULL;
      END IF;
    END IF;
    IF oLogEntry IS NOT NULL
    THEN
      i := oLogEntry.FIRST;
      WHILE i IS NOT NULL LOOP
        DBMS_OUTPUT.PUT_LINE(oLogEntry(i).LogText);
        i := oLogEntry.NEXT(i);
      END LOOP;
    END IF;
  END LOOP;

  DBMS_DATAPUMP.DETACH(vDataPumpJobHandle);
EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE(sqlerrm());
    DBMS_OUTPUT.PUT_LINE(v4Debug);
    RAISE;
END;
/

UNDEFINE 1
UNDEFINE 2
UNDEFINE 3
SET SERVEROUTPUT OFF
SET VERIFY ON

---

やっと、いろいろ落ち着いたかと思ったら次から次に似たような事案が落ちてくる今日この頃w。
ということで、しばらくは機嫌悪いかも、ガルーーーーーっw

---

・Data Pumpも癖モノだよね〜w　その１ - queryパラメーターの解析タイミング
・Data Pumpも癖モノだよね〜w　その２ - Materialized ViewをTableとして移行する
・Data Pumpも癖モノだよね〜w　その3 - dbms_job と dbms_scheduler との複雑な関係
・Data Pumpも癖モノだよね〜w　その4 - schemaモードでMviewを他のPDBへ複製
・Data Pumpも癖モノだよね〜w　その4と1/2 - schemaモードでMviewを他のPDBへ複製 (紛らわしいステータスw）
・Data Pumpも癖モノだよね〜w　その5 - schemaモードでMviewを他のPDBへ複製（オプジェクトパス de 絞り込み）
・Data Pumpも癖モノだよね〜w　その6 - schemaモードでMviewを他のPDBへ複製（オプジェクトパスが不足すると...

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ
・RDS Oracle 雑多なメモ#13 / FAQ
・RDS Oracle 雑多なメモ#14 - おまけ　/ FAQ
・RDS Oracle 雑多なメモ#15 - おまけのおまけ / FAQ
・RDS Oracle 雑多なメモ#16 - 再び:) / FAQ
・RDS Oracle 雑多なメモ#17/ FAQ
・RDS Oracle 雑多なメモ#18 / DBMS_DATAPUMPパッケージ de expdp/impdp
・RDS Oracle 雑多なメモ#19 FAQ / DBMS_DATAPUMPパッケージ de ジョブの停止

RDS Oracle 雑多なメモ#19 FAQ / DBMS_DATAPUMPパッケージ de ジョブの停止

Previously, Mac De Oracle...

RDS Oracle 雑多なメモ#18 / DBMS_DATAPUMPパッケージ de expdp/impdp

DBMS_DATAPUMPパッケージを利用した　Full Export スクリプトと、ディレクトリ名は大文字で渡すことというマニュアルに記載されていない、発生するとしばらく道に迷ってしまいそうなエラーが返るというお話でした。

今日は、その続き、Data PumpジョブはコマンドラインであってもCTRL+Cでは停止することはできないことはみなさんご存知の通りだとは思います。

正しい停止手順は以下の通り

DBA_DATAPUMP_JOBSで停止したいDATAPUMPジョブ名とジョブオーナー名を確認する

4.199 DBA_DATAPUMP_JOBS
https://docs.oracle.com/cd/F19136_01/refrn/DBA_DATAPUMP_JOBS.html#GUID-141B1FA2-9DE4-4EAF-8270-630E68431DDA

expdp/impdpのattachコマンド、または、DBMS_DATAPUMP.ATTACH()ファンクションで該当ジョブへattachする

3.4.4 ATTACH　(expdp/impdpとも同じ対話コマンド)
https://docs.oracle.com/cd/F19136_01/sutil/datapump-import-utility.html#GUID-ADF15D47-FD19-4794-A5C4-685740AA04F9

47.5.2 ATTACHファンクション
https://docs.oracle.com/cd/F19136_01/arpls/DBMS_DATAPUMP.html#GUID-E073EA12-363D-4A6B-9596-1E1D40EA747C

expdp/impdpのkill_jobコマンド、または、DBMS_DATAPUMP.STOP_JOB()プロシージャで該当ジョブを停止する

2.5.7 KILL_JOB　(expdp/impdpとも同じ対話コマンド)
https://docs.oracle.com/cd/F19136_01/sutil/oracle-data-pump-export-utility.html#GUID-9DA12603-B6FA-4631-8DFA-B75466CAF178

47.5.16 STOP_JOBプロシージャ
https://docs.oracle.com/cd/F19136_01/arpls/DBMS_DATAPUMP.html#GUID-9CE265FA-F9C6-4816-8AE0-AD0BEF3DC3CA

コマンドラインでもAPI経由でも手順は全く同じ。利用するツールが異なるだけでなので、まずは手順を覚えることが大切なんですよね。これ。
あとは、コマンドラインでは以下のマニュアルを参照し、具体的なコマンドオプションを知る
DBMS_DATAPUMPプロシージャを利用する場合は以下のマニュアルを参照し、どのようなスクリプトになるかを知る

あとは、実践のみですよー、みなさん！ :)

---

では、DBMS_DATAPUMPパッケージでの例を（すでにエクスポートは実行中という状況からはじめます）

BILL> @show_datapump_jobs

OWNER_NAME        JOB_NAME                  STATE         JOB_MODE      OPERATION
----------------- ------------------------- ------------- ------------- -------------
BILL              SYS_EXPORT_FULL_01        EXECUTING     FULL          EXPORT



BILL> @cancel_datapump_job SYS_EXPORT_FULL_01 BILL

PL/SQL procedure successfully completed.


BILL> @show_datapump_jobs

no rows selected

BILL> @ls_dir data_pump_dir

FILENAME                    TYPE         FILESIZE MTIME
--------------------------- ---------- ---------- ---------
fullexp.log                 file             2761 18-JUL-20
datapump/                   directory        4096 18-JUL-20


BILL> @cat_file data_pump_dir fullexp.log

TEXT
----------------------------------------------------------------------------------------
FLASHBACK automatically enabled to preserve database integrity.
Starting "BILL"."SYS_EXPORT_FULL_01":
Processing object type DATABASE_EXPORT/EARLY_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA
Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/TABLE_DATA
Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA
Processing object type DATABASE_EXPORT/SCHEMA/PACKAGE_BODIES/PACKAGE/PACKAGE_BODY
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/STATISTICS/FUNCTIONAL_INDEX/INDEX_STATISTICS
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type DATABASE_EXPORT/STATISTICS/MARKER
Processing object type DATABASE_EXPORT/PRE_SYSTEM_IMPCALLOUT/MARKER
Processing object type DATABASE_EXPORT/PRE_INSTANCE_IMPCALLOUT/MARKER
Processing object type DATABASE_EXPORT/TABLESPACE
Processing object type DATABASE_EXPORT/PROFILE
Processing object type DATABASE_EXPORT/SCHEMA/USER
Processing object type DATABASE_EXPORT/ROLE
Processing object type DATABASE_EXPORT/RADM_FPTM
Processing object type DATABASE_EXPORT/GRANT/SYSTEM_GRANT/PROC_SYSTEM_GRANT

...中略...

Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/TABLE
Job "BILL"."SYS_EXPORT_FULL_01" stopped due to fatal error at Sat Jul 18 10:02:49 2020 elapsed 0 00:00:50

41 rows selected.


BILL> @rm_file data_pump_dir fullexp.log
DATA_PUMP_DIR/fullexp.log removed.

PL/SQL procedure successfully completed.

BILL> @ls_dir data_pump_dir

FILENAME                    TYPE         FILESIZE MTIME
--------------------------- ---------- ---------- ---------
datapump/                   directory        4096 18-JUL-20

停止できましたー

今回利用したDATAPUMPジョブ停止スクリプトの例は以下のとおり。

BILL> !cat show_datapump_jobs.sql

col owner_name for a30
col job_name for a30
col state for a30
col job_mode for a30
col operation for a30
SELECT
  owner_name
  , job_name
  , state
  , job_mode
  , operation
FROM
  DBA_DATAPUMP_JOBS
ORDER BY
  owner_name
  , job_name
  , state
;

BILL> !cat cancel_datapump_job.sql

DECLARE
  hdl NUMBER;
BEGIN
  hdl := DBMS_DATAPUMP.ATTACH(
    job_name => UPPER('&1')
    ,job_owner => UPPER('&2')
  );

  DBMS_DATAPUMP.STOP_JOB(
    handle => hdl
    , immediate => 1
    , keep_master => 0
  );
END;
/

ls_dir.sql, rm_file.sql　そして、cat_file.sqlの例は過去のエントリを参照してみてください。

ls_dir.sql
https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2018/09/rds-oracle-3-fa.html

rm_file.sql
https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2018/09/rds-oracle-7-fa.html

cat_file.sql
https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2018/09/rds-oracle-4-fa.html

では、次回へつづく。

---

・Data Pumpも癖モノだよね〜w　その１ - queryパラメーターの解析タイミング
・Data Pumpも癖モノだよね〜w　その２ - Materialized ViewをTableとして移行する
・Data Pumpも癖モノだよね〜w　その3 - dbms_job と dbms_scheduler との複雑な関係
・Data Pumpも癖モノだよね〜w　その4 - schemaモードでMviewを他のPDBへ複製
・Data Pumpも癖モノだよね〜w　その4と1/2 - schemaモードでMviewを他のPDBへ複製 (紛らわしいステータスw）
・Data Pumpも癖モノだよね〜w　その5 - schemaモードでMviewを他のPDBへ複製（オプジェクトパス de 絞り込み）
・Data Pumpも癖モノだよね〜w　その6 - schemaモードでMviewを他のPDBへ複製（オプジェクトパスが不足すると...

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ
・RDS Oracle 雑多なメモ#13 / FAQ
・RDS Oracle 雑多なメモ#14 - おまけ　/ FAQ
・RDS Oracle 雑多なメモ#15 - おまけのおまけ / FAQ
・RDS Oracle 雑多なメモ#16 - 再び:) / FAQ
・RDS Oracle 雑多なメモ#17/ FAQ
・RDS Oracle 雑多なメモ#18 / DBMS_DATAPUMPパッケージ de expdp/impdp

RDS Oracle 雑多なメモ#18 / DBMS_DATAPUMPパッケージ de expdp/impdp

さて、COVID-19の感染者も再び増加傾向にある今日この頃ですが、みなさま、お変わりありませんか？

半年ぶり以上ぶりのエントリです。（2020年のOracle ACEのKPIカウントもスタートしたのでやっと再始動）
再始動第一段目は、癖者の極み、Data Pumpネタで。

何年か前にも癖者だというエントリは書いたことがありますが、今回はコマンドラインではなく、DBMS_DATAPUMPパッケージ。そう、APIが主人公です

Data Pumpも癖モノだよね〜w　その6 - schemaモードでMviewを他のPDBへ複製（オプジェクトパスが不足すると...） https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2017/04/data-pumpw6---s.html

そして最近では、

DS Oracle 雑多なメモ#1 / FAQ　〜 https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2018/09/rds-oracle-1-fa.html

から

RDS Oracle 雑多なメモ#17/ FAQ https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2019/02/rds-oracle-17-f.html

---

何度かData Pumpネタを取り上げてきました、今回は RDS Oracleでは需要が多そうな
DBMS＿DATAPUMPパッケージからAPIを利用してexpdp/impdp相当の操作に特化していくつご紹介しておきます。

普段はコマンドラインだけでした操作したことないData Pumpですが、いざDBMS_DATAPUMPパッケージしか使えないという状況になって、涙目状態は辛いですよね。
そんなことにならないように普段から慣れておくとかスクリプト集を用意しておくと良いと思います。

コマンドラインでも癖もとだよねぇ〜というネタのとおりDBMS_DATAPUMPパッケージでも一癖あるのはおなじですw
とはいえ、コマンドラインである程度ポイントを抑えていればある程度は感でいけますよ。

では、さっそく、DBMS_DATAPUMPパッケージの準備運動として、Data Pump Full exportを試してみましょう。
以前も同類のスクリプトは公開済みなので、過去のエントリを読んだことがあるなら簡単なはず:)

環境 Oracle Client 19c (SQL*Plusパッケージが含まれているパッケージ） https://www.oracle.com/jp/database/technologies/instant-client.html

AWS RDS Oracle Database 19c https://aws.amazon.com/jp/console/

実行例）

BILL> @expdp_full data_pump_dir fullexp
FLASHBACK automatically enabled to preserve database integrity.
Starting "BILL"."SYS_EXPORT_FULL_01":
Processing object type DATABASE_EXPORT/EARLY_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA
Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/TABLE_DATA
Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA
Processing object type DATABASE_EXPORT/SCHEMA/PACKAGE_BODIES/PACKAGE/PACKAGE_BODY
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/STATISTICS/FUNCTIONAL_INDEX/INDEX_STATISTICS
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type DATABASE_EXPORT/STATISTICS/MARKER
Processing object type DATABASE_EXPORT/PRE_SYSTEM_IMPCALLOUT/MARKER
Processing object type DATABASE_EXPORT/PRE_INSTANCE_IMPCALLOUT/MARKER
Processing object type DATABASE_EXPORT/TABLESPACE
Processing object type DATABASE_EXPORT/PROFILE
Processing object type DATABASE_EXPORT/SCHEMA/USER
Processing object type DATABASE_EXPORT/ROLE
Processing object type DATABASE_EXPORT/RADM_FPTM
Processing object type DATABASE_EXPORT/GRANT/SYSTEM_GRANT/PROC_SYSTEM_GRANT

...中略...

Processing object type DATABASE_EXPORT/SCHEMA/VIEW/VIEW
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/INDEX
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/INDEX/FUNCTIONAL_INDEX/INDEX
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/CONSTRAINT/CONSTRAINT
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/CONSTRAINT/REF_CONSTRAINT
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TRIGGER
Processing object type DATABASE_EXPORT/SCHEMA/EVENT/TRIGGER
Processing object type DATABASE_EXPORT/FINAL_POST_INSTANCE_IMPCALLOUT/MARKER
Processing object type DATABASE_EXPORT/SCHEMA/POST_SCHEMA/PROCACT_SCHEMA
Processing object type DATABASE_EXPORT/AUDIT_UNIFIED/AUDIT_POLICY_ENABLE
Processing object type DATABASE_EXPORT/POST_SYSTEM_IMPCALLOUT/MARKER
. . exported "SYS"."KU$_USER_MAPPING_VIEW"               5.921 KB      28 rows

...中略...

. . exported "SCOTT"."TAB31"                             541.6 MB 2000000 rows
. . exported "SCOTT"."TAB311"                            521.6 MB 2000000 rows
. . exported "SCOTT"."TAB3"                              267.9 MB 1000000 rows

...中略...

. . exported "HOGE"."HOGE"                               5.093 KB       1 rows

...中略...

Master table "BILL"."SYS_EXPORT_FULL_01" successfully loaded/unloaded
******************************************************************************
Dump file set for BILL.SYS_EXPORT_FULL_01 is:
/rdsdbdata/datapump/fullexp.dmp
Job "BILL"."SYS_EXPORT_FULL_01" successfully completed at Sat Jul 18 10:25:02 2020 elapsed 0 00:04:25

PL/SQL procedure successfully completed.

Elapsed: 00:04:27.32
BILL>
BILL> @ls_dir data_pump_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- ---------
datapump/                                                              directory        4096 18-JUL-20
fullexp.log                                                            file             9071 18-JUL-20
fullexp.dmp                                                            file       1461907456 18-JUL-20

Elapsed: 00:00:00.15

なお、上記で利用している ls_dir.sql　は以下エントリを参照のこと。　
RDS Oracle 雑多なメモ#3 / FAQ https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2018/09/rds-oracle-3-fa.html

RDS Oracle 雑多なメモ#9 / FAQでも紹介しているスクリプトを多少変更してあります。
Full ExportなのでDBMS_DATAPUMP.OPEN()のjob_modeパラメータが'FULL'になっている点と、DBMS_DATAPUMP.METADATA_FILTER()でEXCLUDEやINCLUDEしていない。つまり、Full Exportになっています。
https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2018/09/rds-oracle-9-fa.html

参考）PL/SQLパッケージおよびタイプ・リファレンス
https://docs.oracle.com/cd/F19136_01/arpls/DBMS_DATAPUMP.html#GUID-AEA7ED80-DB4A-4A70-B199-592287206348

なお、マニュアルには書かれてないのですが、ディレクトリ名は、"大文字" にするのがポイントです。Case Sensitiveで大文字しか認識しません。スクリプトを注意深く見ていただけると、UPPER()を使っている部分(赤字部分)があることに気づくとおもいます。もし、小文字で渡してしまうとDBMS_DATAPUMPパッケージの癖の強いエラーメッセージを受け取りことになり、意味わからなーーーーい。としばらくは迷子になってしまうことでしょう。後半で、UPPER()なしで小文字で渡してしまった場合にはどのようなエラーが返されるのかお見せしたいと思います。

BILL> !cat expdp_full.sql

SET VERIFY OFF
SET SERVEROUTPUT ON
DECLARE
  v4Debug VARCHAR2(50);
  cDirectory CONSTANT VARCHAR2(30) := UPPER('&1');
  cDumpFileName CONSTANT VARCHAR2(128) := '&2'||'.dmp';
  cLogFileName CONSTANT VARCHAR2(128) := '&2'||'.log';
  i NUMBER;
  vDataPumpJobHandle NUMBER;
  vProgress_ratio NUMBER;
  vJobState VARCHAR2(30);
  oLogEntry ku$_LogEntry;
  oStatus ku$_Status;
BEGIN
  DBMS_OUTPUT.ENABLE;

  v4Debug := 'OPEN';
  vDataPumpJobHandle
   := DBMS_DATAPUMP.OPEN (
     operation => 'EXPORT'
     ,job_mode => 'FULL'
     ,remote_link => NULL
     ,job_name => NULL
     ,version => 'LATEST'
   );

  v4Debug := 'ADD_FILE - dumpfile';
  DBMS_DATAPUMP.ADD_FILE (
    handle => vDataPumpJobHandle
    ,filename => cDumpFileName
    ,directory => cDirectory(
    ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_DUMP_FILE
  );

  v4Debug := 'ADD_FILE - logfile';
  DBMS_DATAPUMP.ADD_FILE (
    handle => vDataPumpJobHandle
    ,filename => cLogFileName
    ,directory => cDirectory(
    ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_LOG_FILE
  );

  v4Debug := 'START_JOB';
  DBMS_DATAPUMP.START_JOB (
    handle => vDataPumpJobHandle
  );

  v4Debug := 'JOB_STATE';
  vProgress_ratio := 0;
  vJobState := 'UNDEFINED';
  WHILE (vJobState != 'COMPLETED') AND (vJobState != 'STOPPED') LOOP
    DBMS_DATAPUMP.GET_STATUS (
      vDataPumpJobHandle
      ,DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR
        + DBMS_DATAPUMP.KU$_STATUS_JOB_STATUS
        + DBMS_DATAPUMP.KU$_STATUS_WIP
      ,-1
      ,vJobState
      ,oStatus
    );

    IF (BITAND(oStatus.mask, DBMS_DATAPUMP.KU$_STATUS_WIP) != 0)
    THEN
      oLogEntry := oStatus.wip;
    ELSE
      IF (BITAND(oStatus.mask, DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR) != 0)
      THEN
        oLogEntry := oStatus.error;
      ELSE
        oLogEntry := NULL;
      END IF;
    END IF;
    IF oLogEntry IS NOT NULL
    THEN
      i := oLogEntry.FIRST;
      WHILE i IS NOT NULL LOOP
        DBMS_OUTPUT.PUT_LINE(oLogEntry(i).LogText);
        i := oLogEntry.NEXT(i);
      END LOOP;
    END IF;
  END LOOP;

  DBMS_DATAPUMP.DETACH(vDataPumpJobHandle);
EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE(sqlerrm());
    DBMS_OUTPUT.PUT_LINE(v4Debug);
    RAISE;
END;
/

UNDEFINE 1
UNDEFINE 2
SET SERVEROUTPUT OFF
SET VERIFY ON

では、少しだけ前振りしていた、もしも、ディレクトリ名を小文字で渡してしまったら....以下のようなエラーが返されます。

なかなかの癖者なエラーメッセージですよね。このエラーですぐに問題点に気づけたら達人に域ですw　（癖者な人よりは扱いやすいとは思いますがw　ただのAPIなので）

BILL> @expdp_full data_pump_dir fullexp2
old   3:   cDirectory CONSTANT VARCHAR2(30) := '&1';
new   3:   cDirectory CONSTANT VARCHAR2(30) := 'data_pump_dir';
old   4:   cDumpFileName CONSTANT VARCHAR2(64) := '&2'||'.dmp';
new   4:   cDumpFileName CONSTANT VARCHAR2(64) := 'fullexp2'||'.dmp';
old   5:   cLogFileName CONSTANT VARCHAR2(64) := '&2'||'.log';
new   5:   cLogFileName CONSTANT VARCHAR2(64) := 'fullexp2'||'.log';
ORA-39001: invalid argument value
ADD_FILE - dumpfile
DECLARE
*
ERROR at line 1:
ORA-39001: invalid argument value
ORA-06512: at line 86
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 79
ORA-06512: at "SYS.DBMS_DATAPUMP", line 4929
ORA-06512: at "SYS.DBMS_DATAPUMP", line 5180
ORA-06512: at line 26

では、次回へつづく。

---

・Data Pumpも癖モノだよね〜w　その１ - queryパラメーターの解析タイミング・Data Pumpも癖モノだよね〜w　その２ - Materialized ViewをTableとして移行する・Data Pumpも癖モノだよね〜w　その3 - dbms_job と dbms_scheduler との複雑な関係・Data Pumpも癖モノだよね〜w　その4 - schemaモードでMviewを他のPDBへ複製・Data Pumpも癖モノだよね〜w　その4と1/2 - schemaモードでMviewを他のPDBへ複製 (紛らわしいステータスw）
・Data Pumpも癖モノだよね〜w　その5 - schemaモードでMviewを他のPDBへ複製（オプジェクトパス de 絞り込み）
・Data Pumpも癖モノだよね〜w　その6 - schemaモードでMviewを他のPDBへ複製（オプジェクトパスが不足すると...

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ
・RDS Oracle 雑多なメモ#13 / FAQ
・RDS Oracle 雑多なメモ#14 - おまけ　/ FAQ
・RDS Oracle 雑多なメモ#15 - おまけのおまけ / FAQ
・RDS Oracle 雑多なメモ#16 - 再び:) / FAQ
・RDS Oracle 雑多なメモ#17/ FAQ

FAQ / PL/SQL PACKAGEでパプリックスコープを持つ定数をSQL文中で利用するには...

かなーり、ご無沙汰しておりました。（本業でいっぱいいっぱいで、という言い訳はこれぐらいにしてw） 偶に聞かれることがあるので、FAQネタから。 パッケージでパブリックなスコープを持つ定数は無名PL/SQLブロックやパッケージ、プロシージャ、ファンクションでしか参照できないんですよねー 例えば、DBMS_CRYPTOパッケージでHASHファンクションを利用してSH-256を作成したいなーと思って、

39.4 DBMS_CRYPTOのアルゴリズム
https://docs.oracle.com/cd/F19136_01/arpls/DBMS_CRYPTO.html#GUID-CE3CF17D-E781-47CB-AEE7-19A9B2BCD3EC

DBMS_CRYPTO.HASH()は関数なのでSQL文から呼びたーい、と以下のような使い方をすると...

SQL> SELECT DBMS_CRYPTO.HASH(TO_CLOB('hoge'), DBMS_CRYPTO.HASH_SH2569) AS "SH-256" FROM dual;
SELECT DBMS_CRYPTO.HASH(TO_CLOB('hoge'), DBMS_CRYPTO.HASH_SH2569) AS "SH-256" FROM dual
                                         *
ERROR at line 1:
ORA-00904: "DBMS_CRYPTO"."HASH_SH2569": invalid identifier


SQL>
SQL> select DBMS_CRYPTO.HASH_SH256 from dual;
select DBMS_CRYPTO.HASH_SH256 from dual
       *
ERROR at line 1:
ORA-06553: PLS-221: 'HASH_SH256' is not a procedure or is undefined

見事にエラーとなるわけです。 DBMS_CRYPTO.HASH_SH256は、パッケージファンクションではないので...利用可能なのはPL/SQLでのみ。

SQL> set serveroutput on
SQL>
¥SQL>
SQL> begin
  2    dbms_output.put_line('DBMS_CRYPTO.HASH_SH256 : ' || DBMS_CRYPTO.HASH_SH256);
  3  end;
  4  /
DBMS_CRYPTO.HASH_SH256 : 4

PL/SQL procedure successfully completed.

SQL文で活用する為には、ファンクションでラップする必要があります。 以下のように。

SQL> l
  1  CREATE OR REPLACE FUNCTION get_hash_sh256_type
  2  RETURN NUMBER
  3  AS
  4  BEGIN
  5    RETURN DBMS_CRYPTO.HASH_SH256;
  6* END;
SQL> /

Function created.

SQL>

冒頭でエラーとなっていたSQL文をDBMS_CRYPTO.HASH_SH256を返すファンクションを使うように書き換えると、 はい、できました。

SQL> l
  1  SELECT
  2    DBMS_CRYPTO.HASH(
  3	     TO_CLOB('hoge')
  4	     , get_hash_sh256_type()
  5    ) AS "SH-256"
  6  FROM
  7*   dual
SQL> /

SH-256
--------------------------------------------------------------------------------
ECB666D778725EC97307044D642BF4D160AABB76F56C0069C71EA25B1E926825

SQL>

---

露店の焼きそばと焼き鳥を食べつつ、晩夏の夏祭りと、涼しい朝晩の気温で熟睡可能な山形より。 では、では。

ORA_HASH()を使ってリストパーティションにハッシュパーティションのような均一配分を

ハッシュパーティションってリストパーティションみたいにパーティション狙い撃ちできて、かつ、ハッシュパーティションみたいに、データをパーティション間で均一化できないのかなぁ
というずいぶん昔の話を思い出して、そう言えば書いてないかもしれない。いつの話だよってぐらい昔の話だけどw
どうやったかというと、
ハッシュキーにふさわしい値をもつ列を決める（一意キーとか主キー列が理想、カーディナリティの低い、分布に偏りのあるデータを持つ列は使わない）

で、ハッシュキーが決まったら、話は早くて、ORA_HASH()関数で取得できるハッシュ値を利用したリストパーティションを作成するだけ。
ゴニョゴニュ言わなくても、SQLとPL/SQLのコードを見ていただければ、理解していただけるかと。

ORCL@SCOTT> l
  1  CREATE TABLE list_p_tab
  2  (
  3    id_code VARCHAR2(10) NOT NULL
  4    , foo VARCHAR2(30)
  5    , id_code_hash_value NUMBER(2) NOT NULL
  6  )
  7  PARTITION BY LIST (id_code_hash_value)
  8  (
  9    PARTITION list_p_tab_p1 VALUES(0)
 10    ,PARTITION list_p_tab_p2 VALUES(1)
 11    ,PARTITION list_p_tab_p3 VALUES(2)
 12    ,PARTITION list_p_tab_p4 VALUES(3)
 13* )
ORCL@SCOTT> /

Table created.

ORCL@SCOTT> ALTER TABLE list_p_tab ADD CONSTRAINT gpk_list_p_tab PRIMARY KEY(id_code) USING INDEX GLOBAL;

Table altered.

 ORCL@SCOTT> l
  1  DECLARE
  2    TYPE id_code_t IS TABLE OF list_p_tab.id_code%TYPE INDEX BY PLS_INTEGER;
  3    TYPE foo_t IS TABLE OF list_p_tab.foo%TYPE INDEX BY PLS_INTEGER;
  4    id_codes id_code_t;
  5    foos foo_t;
  6    k PLS_INTEGER := 1;
  7  BEGIN
  8    FOR i IN 1..400000 LOOP
  9        id_codes(k)            := TO_CHAR(i,'fm0000000009');
 10        foos(k)                := i;
 11        k := k + 1;
 12        IF k > 1000 THEN
 13          FORALL j in 1..k-1
 14            INSERT INTO list_p_tab VALUES(id_codes(j), foos(j), ORA_HASH(id_codes(j),3));
 15          COMMIT;
 16          k := 1;
 17        END IF;
 18    END LOOP;
 19* END;
ORCL@SCOTT> /

PL/SQL procedure successfully completed.

Elapsed: 00:00:12.28

ORCL@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'LIST_P_TAB',granularity=>'ALL',cascade=>true,no_invalidate=>false,degree=>4);

PL/SQL procedure successfully completed.

Elapsed: 00:00:02.51

ORCL@SCOTT> r
  1  select
  2    table_name
  3    ,partition_name
  4    ,num_rows
  5  from
  6    user_tab_partitions
  7  where
  8    table_name = 'LIST_P_TAB'
  9  order by
 10*   1,2

TABLE_NAME                     PARTITION_NAME                   NUM_ROWS
------------------------------ ------------------------------ ----------
LIST_P_TAB                     LIST_P_TAB_P1                       99901
LIST_P_TAB                     LIST_P_TAB_P2                      100194
LIST_P_TAB                     LIST_P_TAB_P3                      100056
LIST_P_TAB                     LIST_P_TAB_P4                       99849

ORCL@SCOTT> select id_code_hash_value,count(1) from list_p_tab group by id_code_hash_value order by 1;

ID_CODE_HASH_VALUE   COUNT(1)
------------------ ----------
                 0      99901
                 1     100194
                 2     100056
                 3      99849

Elapsed: 00:00:00.06

ORCL@SCOTT> explain plan for 
  2  select
  3    *
  4  from
  5    list_p_tab
  6  where
  7    id_code_hash_value = 1;       

Explained.

Elapsed: 00:00:00.10
ORCL@SCOTT> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
Plan hash value: 2143708561

----------------------------------------------------------------------------------------------------
| Id  | Operation             | Name       | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |            |   100K|  2054K|   275   (1)| 00:00:01 |       |       |
|   1 |  PARTITION LIST SINGLE|            |   100K|  2054K|   275   (1)| 00:00:01 |     2 |     2 |
|   2 |   TABLE ACCESS FULL   | LIST_P_TAB |   100K|  2054K|   275   (1)| 00:00:01 |     2 |     2 |
----------------------------------------------------------------------------------------------------

グローバル索引を作成してあるので、パーティション関係ない検索は主キー索引経由でも可。

ORCL@SCOTT> explain plan for select * from list_p_tab where id_code = '00004000000';

Explained.

Elapsed: 00:00:00.02
ORCL@SCOTT> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------------------------------
Plan hash value: 4132161764

---------------------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name           | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
---------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |                |     1 |    21 |     3   (0)| 00:00:01 |       |       |
|   1 |  TABLE ACCESS BY GLOBAL INDEX ROWID| LIST_P_TAB     |     1 |    21 |     3   (0)| 00:00:01 | ROWID | ROWID |
|*  2 |   INDEX UNIQUE SCAN                | GPK_LIST_P_TAB |     1 |       |     2   (0)| 00:00:01 |       |       |
---------------------------------------------------------------------------------------------------------------------

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

   2 - access("ID_CODE"='00004000000')

RDS Oracle 雑多なメモ#17/ FAQ

Oracle DB インスタンスの一般的な DBA タスクに記載されているAmazon RDS OracleとオンプレのOracleの操作方法の違は意外に多く、長年かけて体に染み付いていて、脊髄反応でタイプしてしまうとエラー、あ”〜っなんてこともしばしばw

仕方ないので、慣れるしかないわけですが、脊髄反応でオンプレのコマンドをタイプして、あ”〜っ！　となったことのある個人的な Top5 を備忘録として書いておきます:)
脊髄反応でそんな権限ないよーというショックなエラーうけとる回数を少しでも減らせるようAmazon RDSパッケージのタイプ練習中の日々w （いずれ、うまく切り替えられるようになれるだろうと信じてw

Oracle DB インスタンスの一般的な DBA システムタスク
Oracle DB インスタンスの一般的な DBA データベースタスク
Oracle DB インスタンスの一般的な DBA ログタスク
Oracle DB インスタンスの一般的な DBA のその他のタスク

個人的に、つい、オンプレと同じ操作をして、エラーになってしまった Top5 w

1位. sysオブジェクトへ権限付与で grant文をタイプしてしまう。
2位. つい、alter system kill session をタイプしてしまう。
3位. オンラインログファイルを切り替えたり、追加、削除で、alter database add logfile..をタイプしたり、alter system switch logfileをタイプしてしまう。
4位. ディレクトリオブジェクトを作成しようとして、create directory...をタイプしてしまう。
5位. rmanの検証コマンドを使おうとして、生のrmanは使えなかった、と気づくw

私がつい、脊髄反応でオリジナルのコマンドをタイプして、エラー？　なぬ？　あ、RDSではAmazon RDS向けのパッケージ使うんだった！！と　気づく典型的な操作の数々(^^;;;;; 長年しみついた手癖で脊髄反応しちゃうのでどうしようもないのですw
みなさんはどのコマンドで、あ”！　となることが多いのでしょうか？（おそらく Top.1は、私と同じ、grant関連ではないでしょうか？w 一番使う機会が多いですからね）

話は少々脱線しますが、上記操作を行うAmazon RDSパッケージでデータベースサイズが大きくなると処理時間を要するものもそこそこあります。
Amazon RDSパッケージで提供されていても内部ではOracleの対応する機能を実行しているわけで、処理時間を要するタイプの操作を行った場合、処理の進行状況を確認確認したくなることもあります。そんな時は、v$session_longops を参照するとよいのではないかと思います。全ての機能が詳細な情報をv$session_longopsに載せてくれるわけではないですが。。（オンプレのOracle Databaseを利用していたという方でも、v$session_longops を使ったことはないなんてことも少なくないような気がします)

RDS Oracleでも　v$session_longops ビューは効果的に利用できる例として、datapumpやOracle DB インスタンスの一般的な DBA データベースタスクでも解説されているrmanの検証コマンドの実行時など、操作にそれなりの時間を要するタイプのものです。（datapumpについては、詳細なステータスを記録していないようなので、datapumpのlogを覗くほうが状況確認としては便利ではありますが、一応、datapumpもv$session_longopsには記録されます。この点はOracle由来なのでオンプレでも同じです。）

一例として、それなりに時間を要する処理の代表格、Amazon RDS プロシージャ rdsadmin.rdsadmin_rman_util.validate_database(Oracle DB インスタンスの一般的な DBA データベースタスク参照）を利用した関連ファイル検証の進行状況をv$session_longopsを利用してモニターリング:)

今回利用したRDS Oracleのデータファイルはぞれぞれ以下のようなサイズです。

SQL> r
  1  select
  2    tablespace_name
  3    ,file_name
  4    ,sum(bytes)/1024/1024 "MB"
  5  from
  6    dba_data_files
  7  group by
  8    tablespace_name
  9    ,file_name
 10  union all
 11  select
 12    tablespace_name
 13    ,file_name
 14    ,sum(bytes)/1024/1024 "MB"
 15  from
 16    dba_temp_files
 17  group by
 18    tablespace_name
 19*   ,file_name

TABLESPACE_NAME                FILE_NAME                                                            MB
------------------------------ ------------------------------------------------------------ ----------
SYSAUX                         /rdsdbdata/db/ORCL_A/datafile/o1_mf_sysaux_fxpjf1nv_.dbf       498.9375
USERS                          /rdsdbdata/db/ORCL_A/datafile/o1_mf_users_fxpjf3d2_.dbf             100
UNDO_T1                        /rdsdbdata/db/ORCL_A/datafile/o1_mf_undo_t1_fxpjf2lx_.dbf           290
RDSADMIN                       /rdsdbdata/db/ORCL_A/datafile/o1_mf_rdsadmin_fxpkkz9k_.dbf            7
SYSTEM                         /rdsdbdata/db/ORCL_A/datafile/o1_mf_system_fxpjdxws_.dbf            500
TEMP                           /rdsdbdata/db/ORCL_A/datafile/o1_mf_temp_fxpjf34b_.tmp              100
                                                                                            ----------
sum                                                                                          1495.9375

事前に作成しておいたスクリプトでAmazon RDS プロシージャ rdsadmin.rdsadmin_rman_util.validate_databaseの処理状況をモニタリングしています（スクリプトの例は後半参照のこと）

SQL> @show_validate_status

レコードが選択されませんでした。

SQL> /

NOW                                     SID    SERIAL# OPNAME                            CONTEXT      SOFAR  TOTALWORK     % done
-------------------------------- ---------- ---------- ------------------------------ ---------- ---------- ---------- ----------
19-02-11 09:42:18.217701 +00:00         665      51783 RMAN: full datafile backup              1     123322     178680      69.02

SQL> /

NOW                                     SID    SERIAL# OPNAME                            CONTEXT      SOFAR  TOTALWORK     % done
-------------------------------- ---------- ---------- ------------------------------ ---------- ---------- ---------- ----------
19-02-11 09:42:19.298741 +00:00         665      51783 RMAN: full datafile backup              1     139452     178680      78.05

SQL> /

NOW                                     SID    SERIAL# OPNAME                            CONTEXT      SOFAR  TOTALWORK     % done
-------------------------------- ---------- ---------- ------------------------------ ---------- ---------- ---------- ----------
19-02-11 09:42:20.367723 +00:00         665      51783 RMAN: full datafile backup              1     156028     178680      87.32

SQL> /

NOW                                     SID    SERIAL# OPNAME                            CONTEXT      SOFAR  TOTALWORK     % done
-------------------------------- ---------- ---------- ------------------------------ ---------- ---------- ---------- ----------
19-02-11 09:42:21.289310 +00:00         665      51783 RMAN: full datafile backup              1     170428     178680      95.38

SQL> /

レコードが選択されませんでした。

SQL> 
SQL> !cat show_validate_status.sql
col "NOW" for a32
col opname for a30
SELECT
  systimestamp AS "NOW"
  ,sid
  ,serial#
  ,opname
  ,context
  ,sofar
  ,totalwork
  ,round(sofar / totalwork * 100, 2) "% done"
FROM
  v$session_longops
WHERE
  opname LIKE 'RMAN%'
  AND opname NOT LIKE '%aggregate%'
  AND sofar != totalwork
  AND totalwork != 0;

---

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ
・RDS Oracle 雑多なメモ#13 / FAQ
・RDS Oracle 雑多なメモ#14 - おまけ / FAQ
・RDS Oracle 雑多なメモ#15 - おまけのおまけ / FAQ
・RDS Oracle 雑多なメモ#16 - 再び:) / FAQ

RDS Oracle 雑多なメモ#16 - 再び:) / FAQ

再び忘れがちなので、備忘録。

RDS Oracleでマスターユーザー以外で、SQL*PLusの Auto trace そして、DBMS_XPLAN.DISPLAY や DBMS_XPLAN.DISPLAY_CURSOR を使おうとすると以下のようなエラーに遭遇！　
なにも準備してないと。（explain plan for文だけは準備していなくても可能なのでが）

TEST> set autot trace exp stat
SP2-0618: Cannot find the Session Identifier.  Check PLUSTRACE role is enabled
SP2-0611: Error enabling STATISTICS report

とか

...略...
TEST> select * from table(dbms_xplan.display_cursor(format=>'ALLSTATS LAST'));

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------
User has no SELECT privilege on V$SESSION

なんてことに、

RDS Oracle、マスターユーザーでは可能なのですが、PLUSTRACEロールも作成されていない、かつ、 plustrce.sql がない.

AWSUSER> select role from dba_roles where role = 'PLUSTRACE';

no rows selected

ということで、いちいち調べるのも面倒なFAQとなっているので、備忘録として書いておきました。

マスターユーザー以外のユーザーに alter session システム権限を付与しておきます。
該当システム権限が付与されていないと、セッションレベルで　statistics_level パラメータを変更できません。
このパラメータは、dbms_xplan.display_cursor でactual planを取得する際に必要になるのですが、最悪付与されていない場合には、SQL文に以下のヒントを追加することで代替可能ではありますが、いちいちSQL文に以下のヒントを追加しなければならないので面倒。
とはいえ、alter sessionは付与したくないということもなくはなく、そんな時は以下のヒントで頑張っください。

ex.

SELECT
  /*+ gather_plan_statistics */
  *
FROM
  hoge
WHERE
  id = 1;

次に必要なのは、　v$sessionなどを含むいくつかのパフォーマンスビューへのSELECTオブジェクト権限、グローバルな一時表として定義されているplan_tableへの全オブジェクト権限です。
管理面を考えてロールを作成し関連権限をロールに付与、作成したロールを対象ユーザーに付与するようにすると便利です。

alter sessionsシステム権限を含む最低限必要なオブジェクト権限とそれを付与するロール作成スクリプトの例は以下の通り。

foobar$ cat create_dev_role.sql

-- create developer role
create role dev_role;

-- for show parameter
grant alter session to dev_role;
-- for dbms_xplan.display_cursor and auto trace
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$SESSION', 'DEV_ROLE', 'SELECT');

-- for dbms_xplan.display_cursor
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$SQL_PLAN_STATISTICS_ALL', 'DEV_ROLE', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$PARAMETER', 'DEV_ROLE', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$SQL', 'DEV_ROLE', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$SQL_PLAN', 'DEV_ROLE', 'SELECT');

-- for auto trace
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$STATNAME', 'DEV_ROLE', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$MYSTAT', 'DEV_ROLE', 'SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$SESSTAT', 'DEV_ROLE', 'SELECT');

-- for auto trace (plan_table - temporary table)
exec rdsadmin.rdsadmin_util.grant_sys_object('PLAN_TABLE$', 'DEV_ROLE', 'ALL');

参考
Oracle DB インスタンスの一般的な DBA タスク

ということで、動作確認を兼ねたサンプルは以下のとおり。

まずは、RDS Oracleのマスターユーザーで.
マスターユーザー以外のユーザーの作成と権限とロールの付与（チューニングが必要とされる開発者等)を想定

foobar$ sqlplus awsuser/xxxxxxx@xxxx.xxxxxxxx.rds.amazonaws.com:1521/HOGE

SQL*Plus: Release 12.1.0.2.0 Production on Fri Nov 2 22:05:14 2018

Copyright (c) 1982, 2016, Oracle.  All rights reserved.

Last Successful login time: Fri Nov 02 2018 22:01:24 +09:00

...中略...

AWSUSER> l
  1  create user test identified by xxxxxx
  2  default tablespace users
  3  temporary tablespace temp
  4* quota unlimited on users
AWSUSER> /

User created.

AWSUSER> grant connect, resource to test;

Grant succeeded.

AWSUSER> @create_dev_role

Role created.

Grant succeeded.

PL/SQL procedure successfully completed.

PL/SQL procedure successfully completed.

PL/SQL procedure successfully completed.

PL/SQL procedure successfully completed.

PL/SQL procedure successfully completed.

PL/SQL procedure successfully completed.

PL/SQL procedure successfully completed.

PL/SQL procedure successfully completed.

PL/SQL procedure successfully completed.

AWSUSER> grant dev_role to test;

Grant succeeded.

AWSUSER> exit

作成したユーザーで接続して、各方法で実行計画を取得できるか確認！
クエリーを実行するため適当な表を作成してデータを登録しておく。

foobar$ sqlplus test/xxxxxxx@xxxx.xxxxxxxx.rds.amazonaws.com:1521/HOGE

SQL*Plus: Release 12.1.0.2.0 Production on Fri Nov 2 22:15:23 2018

Copyright (c) 1982, 2016, Oracle.  All rights reserved.

...中略...
TEST> 
TEST> l
  1  create table hoge (
  2    id number not null primary key
  3   ,foobar varchar2(20)
  4* ) nologging
TEST> /

Table created.

TEST>
TEST> l
  1  begin
  2    for i in 1..10000 loop
  3	 insert into
  4	 hoge (
  5	   id
  6	  ,foobar
  7	 )
  8	 values (
  9	   i
 10	  ,to_char(i)
 11	 );
 12    end loop;
 13    commit;
 14* end;
TEST> /

PL/SQL procedure successfully completed.

SQL*Plusのauto traceが行えるか確認！

TEST> set autot trace exp stat
TEST> select * from hoge where id = 1;

Elapsed: 00:00:00.07

Execution Plan
----------------------------------------------------------
Plan hash value: 2757398040

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

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

   2 - access("ID"=1)

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

参考
文のトレースについて

explain plan for文は準備なしで問題ないのですが、念のための確認！ DBMS_XPLAN.DISPLAYプロシージャを利用して実行計画を取得

TEST> 
TEST> explain plan for
   2  select * from hoge where id = 1;

explained.

TEST> @show_explain

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------
Plan hash value: 2757398040

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

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

   2 - access("ID"=1)

14 rows selected.

Elapsed: 00:00:00.05

スクリプト例は以下の通り。$ORACLE_HOME/rdbms/admin/utlxpls.sql や、utlxplp.sqlが利用できれば楽なんでが、それら中身は、DBMS_XPLAN.DISPLAYなので大差ない内容。

$ cat show_explain.sql

set linesize 200
set long 100000
set longchunk 200
set tab off

SELECT
  *
FROM
  TABLE(
    DBMS_XPLAN.DISPLAY(
      format => 'ALL -PROJECTION -ALIAS'
	)
  )
;

Actual planをDBMS_XPLAN.DISPLAY_CURSORプロシージャで取得〜

TEST> 
TEST> @show_realplan

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
statistics_level                     string      TYPICAL

Session altered.

*** SQL that you want to get an actual plan ***
  1* select * from hoge where id = 1
***********************************************

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------
SQL_ID  6f67zkz43kr76, child number 1
-------------------------------------
select * from hoge where id = 1

Plan hash value: 2757398040

-----------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name        | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |             |      1 |        |      1 |00:00:00.01 |       3 |
|   1 |  TABLE ACCESS BY INDEX ROWID| HOGE        |      1 |      1 |      1 |00:00:00.01 |       3 |
|*  2 |   INDEX UNIQUE SCAN         | SYS_C005687 |      1 |      1 |      1 |00:00:00.01 |       2 |
-----------------------------------------------------------------------------------------------------

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

   2 - access("ID"=1)

19 rows selected.

Elapsed: 00:00:00.11

Session altered.


NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
statistics_level                     string      TYPICAL

Actual planを取得するスクリプト例
SQL*Plusのコマンドを駆使してはいますが、ポイントはset statistics_level = allにすることと、DBMS_XPLAN.DISPLAY_CURSORをコールする際のformatパラメータです
set termout off/onでSQL文の結果を表示しないようにしています。この設定はSQLファイルからSQL文を実行した場合にだけ有効です。（ちょっとしたTips :)

$ cat show_realplan.sql

show parameter statistics_level
alter session set statistics_level = all;

set linesize 200
set long 100000
set longchunk 200
set tab off

PROMPT *** SQL that you want to get an actual plan ***

select * from hoge where id = 1
.
l

PROMPT ***********************************************

set termout off
r
set termout on


-- get the actual plan
set timi on
SELECT
  *
FROM
  TABLE(
    DBMS_XPLAN.DISPLAY_CURSOR(
      format => 'ALLSTATS LAST'
    )
  )
;
set timi off
alter session set statistics_level = typical;
show parameter statistics_level

参考
DBMS_XPLANサブプログラムの要約

Apple Store Ginzaで、息子が　”iPadでムービーを作ろう” に参加するので、その合間に、パタパタブログを書き、その足で英会話に向かう日曜日の午後w

---

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ
・RDS Oracle 雑多なメモ#13 / FAQ
・RDS Oracle 雑多なメモ#14 - おまけ / FAQ
・RDS Oracle 雑多なメモ#15 - おまけのおまけ / FAQ

RDS Oracle 雑多なメモ#15 - おまけのおまけ / FAQ

やっぱり、改造してしまった。おまけのおまけ編w

前回単純にMD5を取得だけのスクリプトをやっつけで作ったので、それを少し改造して、締めくくり。？（たぶん。。）

前回作成したMD5取得スクリプトを元に、ファイルが同じかどうか比較するスクリプトに作り変えました :)

21:35:35 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
hoge.dmp.gz                                                            file          2603349 18-09-24
hoge.log.gz                                                            file              512 18-09-24
hoge.dmp.bak                                                           file       1083412480 18-09-24
hoge.dmp.gz.bak                                                        file          2603349 18-09-24
hoge.log.bak                                                           file             1202 18-09-24
hoge.log.gz.bak                                                        file              512 18-09-24
01/                                                                    directory        4096 18-09-24
hoge.dmp                                                               file       1083412480 18-09-24
hoge.log                                                               file              904 18-09-24

9行が選択されました。

ダンプファイル（一旦圧縮したファイルを解凍したファイル）とオリジナルのダンプファイルのコピーの比較

21:35:43 rdsora121@BILL> @diff_md5 test_dir hoge.dmp hoge.dmp.bak
Src : 1B84C9E09F13A4FDC6EF2F03137C0338
Dest: 1B84C9E09F13A4FDC6EF2F03137C0338
-- No difference found. --

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

ダンプファイル（オリジナルを圧縮したファイル）とオリジナルダンプファイルを圧縮したファイルのコピーの比較

21:36:28 rdsora121@BILL> @diff_md5 test_dir hoge.dmp.gz hoge.dmp.gz.bak
Src : D2CB26A7E75C9725F00C30A9280C1599
Dest: D2CB26A7E75C9725F00C30A9280C1599
-- No difference found. --

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

異なるファイルの比較、ログファイルのコピーと、圧縮したログファイルのコピー。

21:37:35 rdsora121@BILL> @diff_md5 test_dir hoge.log.bak hoge.log.gz.bak
Src : DCE17181C95EACE997F45A2537BC1DA8
Dest: 6398E040E157B4A0CEF50FCF45C76FF7
-- Difference found. --

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

圧縮したログファイルとそのコピーの比較。同じでなにより：）

21:38:15 rdsora121@BILL> @diff_md5 test_dir hoge.log.gz hoge.log.gz.bak
Src : 6398E040E157B4A0CEF50FCF45C76FF7
Dest: 6398E040E157B4A0CEF50FCF45C76FF7
-- No difference found. --

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

異なるファイルの比較、どちらもログファイルですが、内容がことなります。

21:38:51 rdsora121@BILL> @cat_file test_dir hoge.log
   
TEXT
------------------------------------------------------------------------------------------
マスター表"BILL"."SYS_IMPORT_TABLE_01"は正常にロード/アンロードされました
"BILL"."SYS_IMPORT_TABLE_01"を起動しています:
オブジェクト型TABLE_EXPORT/TABLE/TABLEの処理中です
オブジェクト型TABLE_EXPORT/TABLE/TABLE_DATAの処理中です
. . "SCOTT"."HOGE"                              1.008 GB  270000行がインポートされました
オブジェクト型TABLE_EXPORT/TABLE/INDEX/INDEXの処理中です
オブジェクト型TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINTの処理中です
オブジェクト型TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICSの処理中です
オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICSの処理中です
オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/MARKERの処理中です
ジョブ"BILL"."SYS_IMPORT_TABLE_01"が月 9月 24 04:05:17 2018 elapsed 0 00:00:52で正常に完了しました

11行が選択されました。

21:39:38 rdsora121@BILL> @cat_file test_dir hoge.log.bak

TEXT
------------------------------------------------------------------------------------------
"BILL"."EXPTABLE_HOGE"を起動しています:
BLOCKSメソッドを使用して見積り中です...
オブジェクト型TABLE_EXPORT/TABLE/TABLE_DATAの処理中です
BLOCKSメソッドを使用した見積り合計: 2.125 GB
オブジェクト型TABLE_EXPORT/TABLE/TABLEの処理中です
オブジェクト型TABLE_EXPORT/TABLE/INDEX/INDEXの処理中です
オブジェクト型TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINTの処理中です
オブジェクト型TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICSの処理中です
オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICSの処理中です
オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/MARKERの処理中です
. . "SCOTT"."HOGE"                              1.008 GB  270000行がエクスポートされました
マスター表"BILL"."EXPTABLE_HOGE"は正常にロード/アンロードされました
******************************************************************************
BILL.EXPTABLE_HOGEに設定されたダンプ・ファイルは次のとおりです:
  /rdsdbdata/userdirs/01/hoge.dmp
ジョブ"BILL"."EXPTABLE_HOGE"が日 9月 23 05:36:33 2018 elapsed 0 00:00:35で正常に完了しました

16行が選択されました。

21:39:48 rdsora121@BILL> @diff_md5 test_dir hoge.log hoge.log.bak
Src : 6DA2D7C6150A9C8ACD60D95D6A61C1B5
Dest: DCE17181C95EACE997F45A2537BC1DA8
-- Difference found. --

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

スクリプトは以下の通り。MD5の比較には、UTL_RAW.COMPARE関数を利用しています。

21:40:05 rdsora121@BILL> !cat diff_md5.sql
SET VERIFY OFF
SET SERVEROUTPUT ON FORMAT WRAPPED
DECLARE
  vDirectoryName  VARCHAR2(30);
  vSrcFileName       VARCHAR2(60);
  vDestFileName      VARCHAR2(60);
  vSrcMd5            RAW(16);
  vDestMd5           RAW(16);

  PROCEDURE close_bfile
  (
    iBfile IN OUT NOCOPY BFILE
  ) 
  IS
  BEGIN
    IF DBMS_LOB.ISOPEN(iBfile) = 1 THEN
      DBMS_LOB.CLOSE(iBfile);
    END IF;
  END close_bfile;

  FUNCTION md5
  (
    iDirectoryName IN VARCHAR2
    , iFileName    IN VARCHAR2
  ) RETURN RAW
  IS
    vBfile     BFILE;
    vBlob      BLOB;
    vMd5       RAW(16);           
  BEGIN
    vBFile := BFILENAME(UPPER(iDirectoryName), iFileName);
    DBMS_LOB.OPEN(vBFile);

    DBMS_LOB.CREATETEMPORARY(
      lob_loc => vBlob
      , cache => false
      , dur   => DBMS_LOB.SESSION
    );

    DBMS_LOB.LOADFROMFILE(
      dest_lob      => vBlob
      , src_lob     => vBFile
      , amount      => DBMS_LOB.GETLENGTH(vBFile)
      , dest_offset => 1
      , src_offset  => 1
    );

    vMd5 := DBMS_CRYPTO.HASH(vBlob, DBMS_CRYPTO.HASH_MD5);

    DBMS_LOB.FREETEMPORARY(vBlob);
    close_bfile(vBFile);
    RETURN vMd5;
  EXCEPTION
    WHEN OTHERS THEN
      DBMS_LOB.FREETEMPORARY(vBlob);
      close_bfile(vBFile);
      RAISE;
  END md5;

BEGIN
  vDirectoryName := UPPER('&1');
  vSrcFileName   := '&2';
  vDestFileName  := '&3';

  vSrcMd5  := md5(vDirectoryName, vSrcFileName);
  vDestMd5 := md5(vDirectoryName, vDestFileName);
  
  DBMS_OUTPUT.PUT_LINE('Src : '||vSrcMd5);
  DBMS_OUTPUT.PUT_LINE('Dest: '||vDestMd5);

  IF UTL_RAW.COMPARE(r1 => vSrcMd5, r2 => vDestMd5) = 0
  THEN
    DBMS_OUTPUT.PUT_LINE('-- No difference found. --');
  ELSE
    DBMS_OUTPUT.PUT_LINE('-- Difference found. --');
  END IF;

EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE(SQLERRM()||':'||SQLCODE());
    RAISE;
END;
/

UNDEFINE 1
UNDEFINE 2
UNDEFINE 3
SET SERVEROUTPUT OFF
SET VERIFY ON

たぶん、これで終わりなはず。（なにか浮かばなければw）

---

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ
・RDS Oracle 雑多なメモ#13 / FAQ
・RDS Oracle 雑多なメモ#14 - おまけ / FAQ

RDS Oracle 雑多なメモ#14 - おまけ / FAQ

ということで、done ってしておきながら、おまけ（得意技w）です。

RDS Oracle限定というわけではなくなってきましたがw 勢いでさらに追加。

手作りのcpっぽいスクリプトなので、バグってないか少し不安w ということで、オリジナルファイルと同じなのか確認できるようにメッセージダイジェストを取得するスクリプトも作成しましたw

21:14:43 rdsora121@BILL> @list_dir

DIRECTORY_NAME                           DIRECTORY_PATH
---------------------------------------- ----------------------------------------------------------------------
ADUMP                                    /rdsdbdata/log/audit
BDUMP                                    /rdsdbdata/log/trace
DATA_PUMP_DIR                            /rdsdbdata/datapump
HOGE_DIR                                 /rdsdbdata/userdirs/02
OPATCH_INST_DIR                          /rdsdbbin/oracle/OPatch
OPATCH_LOG_DIR                           /rdsdbbin/oracle/QOpatch
OPATCH_SCRIPT_DIR                        /rdsdbbin/oracle/QOpatch
TEST_DIR                                 /rdsdbdata/userdirs/01

8行が選択されました。

21:14:48 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
hoge.dmp.gz                                                            file          2603349 18-09-24
hoge.log.gz                                                            file              512 18-09-24
hoge.dmp.bak                                                           file       1083412480 18-09-24
hoge.dmp.gz.bak                                                        file          2603349 18-09-24
hoge.log.bak                                                           file             1202 18-09-24
hoge.log.gz.bak                                                        file              512 18-09-24
01/                                                                    directory        4096 18-09-24
hoge.dmp                                                               file       1083412480 18-09-24
hoge.log                                                               file              904 18-09-24

9行が選択されました。

ダンプファイルを圧縮ファイル、ログファイル、ダンプファイルなどなど、MD5が取得できるようになりました。ファイルが壊れてないか確認しやすい:)

21:14:55 rdsora121@BILL> @check_md5 test_dir hoge.dmp.gz
TEST_DIR/hoge.dmp.gz MD5 : D2CB26A7E75C9725F00C30A9280C1599

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

21:15:32 rdsora121@BILL> @check_md5 test_dir hoge.dmp.gz.bak
TEST_DIR/hoge.dmp.gz.bak MD5 : D2CB26A7E75C9725F00C30A9280C1599

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

21:15:50 rdsora121@BILL> @check_md5 test_dir hoge.log
TEST_DIR/hoge.log MD5 : 6DA2D7C6150A9C8ACD60D95D6A61C1B5

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

21:16:26 rdsora121@BILL> @check_md5 test_dir hoge.dmp
TEST_DIR/hoge.dmp MD5 : 1B84C9E09F13A4FDC6EF2F03137C0338

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

21:18:02 rdsora121@BILL> @check_md5 test_dir hoge.dmp.bak
TEST_DIR/hoge.dmp.bak MD5 : 1B84C9E09F13A4FDC6EF2F03137C0338

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

ざっくり作ったスクリプトは以下の通り。BFILEからファイルを読み込み、一時BLOBとしてBFILEからロード、MD5取得というながれです。
(オンプレでもそのまま使える内容にはなっちゃいましたが、勢いで作ったので：）

21:18:50 rdsora121@BILL> !cat check_md5.sql
SET VERIFY OFF
SET SERVEROUTPUT ON FORMAT WRAPPED
DECLARE
  vSrcfile           BFILE;
  vSrcBlob           BLOB;
  vSrcDirectoryName  VARCHAR2(30);
  vSrcFileName       VARCHAR2(60);
  vSrcFileSize       PLS_INTEGER;
  vSrcFileMd5        RAW(16);

  PROCEDURE close_bfile
  (
    iBfile IN OUT NOCOPY BFILE
  ) 
  IS
  BEGIN
    IF DBMS_LOB.ISOPEN(iBfile) = 1 THEN
      DBMS_LOB.CLOSE(iBfile);
    END IF;
  END close_bfile;

BEGIN
  vSrcDirectoryName := UPPER('&1');
  vSrcFileName   := '&2';
  
  vSrcFile 
    := BFILENAME(UPPER(vSrcDirectoryName), vSrcFileName);

  DBMS_LOB.OPEN(vSrcFile);
  vSrcFileSize := DBMS_LOB.GETLENGTH(vSrcFile);


  DBMS_LOB.CREATETEMPORARY (
    lob_loc => vSrcBlob
    , cache   => false
    , dur     => DBMS_LOB.SESSION
  );
   
  DBMS_LOB.LOADFROMFILE (
    dest_lob => vSrcBlob
    , src_lob => vSrcFile
    , amount   => vSrcFileSize
    , dest_offset => 1
    , src_offset => 1
  );
  
  vSrcFileMd5 := DBMS_CRYPTO.HASH(vSrcBlob, DBMS_CRYPTO.HASH_MD5);

  DBMS_LOB.FREETEMPORARY(vSrcBlob);
  close_bfile(vSrcFile);

  DBMS_OUTPUT.PUT_LINE(
    vSrcDirectoryName
    ||'/'||vSrcFileName
    ||' MD5 : '||vSrcFileMd5
  );
EXCEPTION
  WHEN OTHERS THEN
    DBMS_LOB.FREETEMPORARY(vSrcBlob);
    close_bfile(vSrcFile);
    RAISE;
END;
/

UNDEFINE 1
UNDEFINE 2
SET SERVEROUTPUT OFF
SET VERIFY ON

ということで、done... これを元にまたまにか作るかもしれない、作らないかもしれないw

---

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ
・RDS Oracle 雑多なメモ#13 / FAQ

RDS Oracle 雑多なメモ#13 / FAQ

メモの続きです。
前回は、圧縮したテキストファイルとダンプファイル（バイナリファイル）を解凍するスクリプトを実行したところまででした。

やっとここまできたw

今回は、解凍したファイルが使えるかなど内容確認をしてみたいと思います。

まず、解凍したログファイル（テキストファイル）の内容を確認
問題なさそうですね。

12:35:01 rdsora121@BILL> @cat_file test_dir hoge.log

TEXT
----------------------------------------------------------------------------------------
"BILL"."EXPTABLE_HOGE"を起動しています:
BLOCKSメソッドを使用して見積り中です...
オブジェクト型TABLE_EXPORT/TABLE/TABLE_DATAの処理中です
BLOCKSメソッドを使用した見積り合計: 2.125 GB
オブジェクト型TABLE_EXPORT/TABLE/TABLEの処理中です
オブジェクト型TABLE_EXPORT/TABLE/INDEX/INDEXの処理中です
オブジェクト型TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINTの処理中です
オブジェクト型TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICSの処理中です
オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICSの処理中です
オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/MARKERの処理中です
. . "SCOTT"."HOGE"                              1.008 GB  270000行がエクスポートされました
マスター表"BILL"."EXPTABLE_HOGE"は正常にロード/アンロードされました
******************************************************************************
BILL.EXPTABLE_HOGEに設定されたダンプ・ファイルは次のとおりです:
  /rdsdbdata/userdirs/01/hoge.dmp
ジョブ"BILL"."EXPTABLE_HOGE"が日 9月 23 05:36:33 2018 elapsed 0 00:00:35で正常に完了しました

16行が選択されました。

解凍したダンプファイルをインポートして確認する前に、元のオブジェクトの確認後、削除しておきます。

12:37:17 rdsora121@BILL> set linesize 80
12:37:20 rdsora121@BILL> desc scott.hoge
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID                                        NOT NULL NUMBER
 FOO                                                VARCHAR2(4000)

12:37:25 rdsora121@BILL> select count(1) from scott.hoge;

  COUNT(1)
----------
    270000

12:39:07 rdsora121@BILL> r
  1  select
  2    segment_name
  3    ,sum(bytes)/1024/1024/1024 "GB"
  4  from
  5    dba_segments
  6  where
  7    owner='SCOTT'
  8    and segment_name in ('HOGE','PK_HOGE')
  9  group by
 10*   segment_name

SEGMENT_NAME                           GB
------------------------------ ----------
PK_HOGE                        .004882813
HOGE                                2.125

12:39:17 rdsora121@BILL> set linesize 400
12:39:21 rdsora121@BILL> 
12:40:02 rdsora121@BILL> drop table scott.hoge purge;

表が削除されました。

dbms_datapumpパッケージを利用したスクリプトを作成してインポート可能か確認 :)

13:03:40 rdsora121@BILL> @import_table test_dir hoge scott hoge
マスター表"BILL"."SYS_IMPORT_TABLE_01"は正常にロード/アンロードされました
"BILL"."SYS_IMPORT_TABLE_01"を起動しています:
オブジェクト型TABLE_EXPORT/TABLE/TABLEの処理中です
オブジェクト型TABLE_EXPORT/TABLE/TABLE_DATAの処理中です
. . "SCOTT"."HOGE"                              1.008 GB  270000行がインポートされました
オブジェクト型TABLE_EXPORT/TABLE/INDEX/INDEXの処理中です
オブジェクト型TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINTの処理中です
オブジェクト型TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICSの処理中です
オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICSの処理中です
オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/MARKERの処理中です
ジョブ"BILL"."SYS_IMPORT_TABLE_01"が月 9月 24 04:05:17 2018 elapsed 0 00:00:52で正常に完了しました

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

インポート成功！！！　表などの確認！

13:05:54 rdsora121@BILL> set linesize 80
13:06:00 rdsora121@BILL> desc scott.hoge
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID                                        NOT NULL NUMBER
 FOO                                                VARCHAR2(4000)

13:06:04 rdsora121@BILL> select count(1) from scott.hoge;

  COUNT(1)
----------
    270000

13:07:27 rdsora121@BILL> r
  1  select
  2    segment_name
  3    ,sum(bytes)/1024/1024/1024 "GB"
  4  from
  5    dba_segments
  6  where
  7    owner='SCOTT'
  8    and segment_name in ('HOGE','PK_HOGE')
  9  group by
 10*   segment_name

SEGMENT_NAME                           GB
------------------------------ ----------
PK_HOGE                        .004882813
HOGE                                2.125

スクリプトは以下の通り。　表モードのインポートをハードコードしていますが、そのあたりパラメータ化すればそこそこ使いやすくなりますかね。。

13:08:03 rdsora121@BILL> !cat import_table.sql
SET VERIFY OFF
SET SERVEROUTPUT ON
DECLARE
  v4Debug VARCHAR2(50);
  cDirectory CONSTANT VARCHAR2(30) := UPPER('&1');
  cDumpFileName CONSTANT VARCHAR2(64) := '&2'||'.dmp';
  cLogFileName CONSTANT VARCHAR2(64) := '&2'||'.log';
  cSchemaName CONSTANT VARCHAR2(30) := UPPER('&3');
  cTableName CONSTANT VARCHAR2(30) := UPPER('&4');
  i NUMBER;
  vDataPumpJobHandle NUMBER; 
  vProgress_ratio NUMBER;
  vJobState VARCHAR2(30);
  oLogEntry ku$_LogEntry;
  oStatus ku$_Status;
BEGIN
  DBMS_OUTPUT.ENABLE;
  
  v4Debug := 'OPEN';
  vDataPumpJobHandle 
   := DBMS_DATAPUMP.OPEN (
     operation => 'IMPORT'
     ,job_mode => 'TABLE'
     ,remote_link => NULL
   );

  v4Debug := 'ADD_FILE - dumpfile';
  DBMS_DATAPUMP.ADD_FILE (
    handle => vDataPumpJobHandle
    ,filename => cDumpFileName
    ,directory => cDirectory
    ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_DUMP_FILE
  );

  v4Debug := 'ADD_FILE - logfile';
  DBMS_DATAPUMP.ADD_FILE (
    handle => vDataPumpJobHandle
    ,filename => cLogFileName
    ,directory => cDirectory
    ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_LOG_FILE
  );

  v4Debug := 'METADATA_FILTER - schema name';
  DBMS_DATAPUMP.METADATA_FILTER (
    handle => vDataPumpJobHandle
    ,name => 'SCHEMA_LIST'
    ,value => '''' || cSchemaName || ''''
  );

  v4Debug := 'METADATA_FILTER - table name';
  DBMS_DATAPUMP.METADATA_FILTER (
    handle => vDataPumpJobHandle
    ,name => 'NAME_LIST'
    ,value => '''' || cTableName || ''''
  );

  v4Debug := 'START_JOB';
  DBMS_DATAPUMP.START_JOB (
    handle => vDataPumpJobHandle
  );

  v4Debug := 'JOB_STATE';
  vProgress_ratio := 0;
  vJobState := 'UNDEFINED';
  WHILE (vJobState != 'COMPLETED') AND (vJobState != 'STOPPED') LOOP
    DBMS_DATAPUMP.GET_STATUS (
      vDataPumpJobHandle
      ,DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR 
        + DBMS_DATAPUMP.KU$_STATUS_JOB_STATUS 
        + DBMS_DATAPUMP.KU$_STATUS_WIP
      ,-1
      ,vJobState
      ,oStatus
    );

    IF (BITAND(oStatus.mask, DBMS_DATAPUMP.KU$_STATUS_WIP) != 0)
    THEN
      oLogEntry := oStatus.wip;
    ELSE
      IF (BITAND(oStatus.mask, DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR) != 0)
      THEN
        oLogEntry := oStatus.error;
      ELSE
        oLogEntry := NULL;
      END IF;
    END IF;
    IF oLogEntry IS NOT NULL
    THEN
      i := oLogEntry.FIRST;
      WHILE i IS NOT NULL LOOP
        DBMS_OUTPUT.PUT_LINE(oLogEntry(i).LogText);
        i := oLogEntry.NEXT(i);
      END LOOP;
    END IF;
  END LOOP;

  DBMS_DATAPUMP.DETACH(vDataPumpJobHandle);
EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE(sqlerrm());
    DBMS_OUTPUT.PUT_LINE(v4Debug);
    RAISE;
END;
/

UNDEFINE 1
UNDEFINE 2
UNDEFINE 3
UNDEFINE 4
SET SERVEROUTPUT OFF
SET VERIFY ON

ということで、ひとまず、RDS Oracleの雑多なメモ　done :)

---

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ
・RDS Oracle 雑多なメモ#12 / FAQ

RDS Oracle 雑多なメモ#12 / FAQ

メモの続きです。

さて、前回、cpっぽいスクリプトの問題を改善したので今回は、圧縮したファイルを解凍するスクリプトを作ろうと思います。

前回の操作でファイルが増えて見づらくなったので、解凍に必要な最小限のファイルだけに整理します

12:20:19 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
hoge.log                                                               file             1202 18-09-23
hoge.dmp                                                               file       1083412480 18-09-23
hoge.dmp.gz                                                            file          2603349 18-09-24
hoge.log.gz                                                            file              512 18-09-24
hoge.dmp.bak                                                           file       1083412480 18-09-24
hoge.dmp.gz.bak                                                        file          2603349 18-09-24
hoge.log.bak                                                           file             1202 18-09-24
hoge.log.gz.bak                                                        file              512 18-09-24
01/                                                                    directory        4096 18-09-24

9行が選択されました。

12:20:25 rdsora121@BILL> @rm_file test_dir hoge.log
TEST_DIR/hoge.log removed.

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

12:21:49 rdsora121@BILL> @rm_file test_dir hoge.dmp
TEST_DIR/hoge.dmp removed.

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

12:21:57 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
hoge.dmp.gz                                                            file          2603349 18-09-24
hoge.log.gz                                                            file              512 18-09-24
hoge.dmp.bak                                                           file       1083412480 18-09-24
hoge.dmp.gz.bak                                                        file          2603349 18-09-24
hoge.log.bak                                                           file             1202 18-09-24
hoge.log.gz.bak                                                        file              512 18-09-24
01/                                                                    directory        4096 18-09-24

7行が選択されました。

では圧縮したテキストファイルとダンプファイル（バイナリファイル）を解凍してみます。

12:22:06 rdsora121@BILL> @gunzip_file test_dir hoge.log.gz
TEST_DIR/hoge.log.gz uncompressed to hoge.log (1202 bytes)

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

12:22:44 rdsora121@BILL> @gunzip_file test_dir hoge.dmp.gz
TEST_DIR/hoge.dmp.gz uncompressed to hoge.dmp (1083412480 bytes)

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

12:23:04 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
hoge.dmp.gz                                                            file          2603349 18-09-24
hoge.log.gz                                                            file              512 18-09-24
hoge.dmp.bak                                                           file       1083412480 18-09-24
hoge.dmp.gz.bak                                                        file          2603349 18-09-24
hoge.log.bak                                                           file             1202 18-09-24
hoge.log.gz.bak                                                        file              512 18-09-24
hoge.log                                                               file             1202 18-09-24
01/                                                                    directory        4096 18-09-24
hoge.dmp                                                               file       1083412480 18-09-24

9行が選択されました。

できた！！！

今回の利用した解凍スクリプトも元は12年前のエントリで利用したコードのほぼ再利用です。
Mac De Oracle (PL/SQL De UNCOMPRESS)

12:24:22 rdsora121@BILL> !cat gunzip_file.sql
SET VERIFY OFF
SET SERVEROUTPUT ON
DECLARE
  vSrcGzippedFile     BFILE;
  vUncompressedBlob   BLOB;
  vDirectoryName      VARCHAR2(30);
  vSrcGzippedFileName VARCHAR2(60);
  vDestFileName       VARCHAR2(60); 
  VUncompressedSize   PLS_INTEGER;

  PROCEDURE close_bfile
  (
    iBfile IN OUT NOCOPY BFILE
  ) 
  IS
  BEGIN
    IF DBMS_LOB.ISOPEN(iBfile) = 1 THEN
      DBMS_LOB.CLOSE(iBfile);
    END IF;
  END close_bfile;

  PROCEDURE write_blob_to_file
  (
    iDirectoryName  IN VARCHAR2,
    iFileName       IN VARCHAR2,
    iSrcBlob        IN OUT NOCOPY BLOB
  ) 
  IS
    vFile UTL_FILE.FILE_TYPE;
  BEGIN
    vFile := UTL_FILE.FOPEN(
               UPPER(iDirectoryName), 
                iFileName, 
                'wb', 
                32767
             );

    DECLARE
      cChunkSize  CONSTANT PLS_INTEGER := 32767;

      vBuffer     RAW(32767);
      vAmount     PLS_INTEGER := cChunkSize;   
      vNumOfChunk PLS_INTEGER;
    BEGIN
      vNumOfChunk := CEIL(DBMS_LOB.GETLENGTH(iSrcBlob)/cChunkSize);
      FOR chunk# IN 1..vNumOfChunk LOOP
        DBMS_LOB.READ(
          iSrcBlob, 
          vAmount, 
          (cChunkSize * (chunk# - 1)) + 1, /*offet*/
          vBuffer
        );
        UTL_FILE.PUT_RAW(vFile, vBuffer, TRUE);
      END LOOP;
    END;

    UTL_FILE.FCLOSE(vFile);
  END write_blob_to_file;

BEGIN
  vDirectoryName      := UPPER('&1');
  vSrcGzippedFileName := '&2';
  vDestFileName       := SUBSTR('&2', 1, INSTR('&2', '.gz') - 1);

  vSrcGzippedFile 
    := BFILENAME(UPPER(vDirectoryName), vSrcGzippedFileName);

  DBMS_LOB.OPEN(vSrcGzippedFile);
  vUncompressedBlob := UTL_COMPRESS.LZ_UNCOMPRESS(vSrcGzippedFile);
  vUncompressedSize := DBMS_LOB.GETLENGTH(vUncompressedBlob);
  
  write_blob_to_file(
    UPPER(vDirectoryName), 
    vDestFileName, 
    vUncompressedBlob
  );

  DBMS_LOB.FREETEMPORARY(vUncompressedBlob);
  close_bfile(vSrcGzippedFile);
  DBMS_OUTPUT.PUT_LINE(
    vDirectoryName||'/'
    ||vSrcGzippedFileName
    ||' uncompressed to '
    ||vDestFileName
    ||' ('||vUncompressedSize||' bytes)'
  );
EXCEPTION
  WHEN OTHERS THEN
    DBMS_LOB.FREETEMPORARY(vUncompressedBlob);
    close_bfile(vSrcGzippedFile);
    RAISE;
END;
/

UNDEFINE 1
UNDEFINE 2
SET SERVEROUTPUT OFF
SET VERIFY ON

ということで、次回、解凍したテキストファイルの内容確認と、解凍したダンプファイルからインポートして内容確認へつづく :)

---

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ
・RDS Oracle 雑多なメモ#11 / FAQ

RDS Oracle 雑多なメモ#11 / FAQ

メモの続きです。

はじめに、
ごねんなさい、ごねんなさい

RDS Oracle 雑多なメモ#6 / FAQ
で作成したUTL_FILE.FCOPYを利用したcpっぽいスクリプトはtextファイルにしか対応できません。
理由は、UTL_FILE.FCOPYプロシージャ自体がtextファイル向けでバイナリファイルに対応していないことが理由ではあるのですが、textファイルしかコピーできないのもなんなので、バイナリファイルにも対応したバージョンに変更したいと思います。

RDS Oracle 雑多なメモ#6 / FAQで作成したスクリプトは今回作成したスクリプトで置き換えていただければ、m(_ _)m

前々回作成したダンプファイル(バイナリファイル)やテキストファイルを使ってみようと思います。

utl_file.fcopyプロシージャでコピーできる例（テキストファイル）

10:48:50 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
hoge.dmp                                                               file       1083412480 18-09-23
hoge.log                                                               file             1202 18-09-23
hoge.dmp.gz                                                            file          2603349 18-09-24
hoge.log.gz                                                            file              512 18-09-24
01/                                                                    directory        4096 18-09-24

11:14:42 rdsora121@BILL> @cp_file test_dir hoge.log test_dir hoge.log.bak1

source file : test_dir/hoge.log
dest file   : test_dir/hoge.log.bak1 copied.

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

11:15:10 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
hoge.dmp                                                               file       1083412480 18-09-23
hoge.log                                                               file             1202 18-09-23
hoge.dmp.gz                                                            file          2603349 18-09-24
hoge.log.gz                                                            file              512 18-09-24
01/                                                                    directory        4096 18-09-24
hoge.log.bak1                                                          file             1202 18-09-24

6行が選択されました。

utl_file.fcopyプロシージャでコピーできない例（バイナリファイル）
エラーが発生し、コピー途中のゴミファイルが作成されていまいます。。。。これはこまる。。

11:15:10 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
hoge.dmp                                                               file       1083412480 18-09-23
hoge.log                                                               file             1202 18-09-23
hoge.dmp.gz                                                            file          2603349 18-09-24
hoge.log.gz                                                            file              512 18-09-24
01/                                                                    directory        4096 18-09-24
hoge.log.bak1                                                          file             1202 18-09-24

11:16:51 rdsora121@BILL> @cp_file test_dir hoge.dmp test_dir hoge.dmp.bak1
-29284:ORA-29284: ファイル読取りエラーが発生しました。

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

11:17:20 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
hoge.dmp                                                               file       1083412480 18-09-23
hoge.log                                                               file             1202 18-09-23
hoge.dmp.gz                                                            file          2603349 18-09-24
hoge.log.gz                                                            file              512 18-09-24
hoge.log.bak1                                                          file             1202 18-09-24
hoge.dmp.bak1                                                          file            45093 18-09-24
01/                                                                    directory        4096 18-09-24

7行が選択されました。

RDS Oracle 雑多なメモ#6 / FAQで作成したcp_file.sqlのコードは以下の通り
これでバイナリーファイルもコピーできると嬉しいのにね〜。昔からできないのでしかたない。。

11:25:20 rdsora121@BILL> !cat cp_file.sql
set verify off
set serveroutput on format wrapped
BEGIN
	UTL_FILE.FCOPY(
		src_location => UPPER('&1')
		,src_filename => '&2'
		,dest_location => UPPER('&3')
		,dest_filename => '&4'
	);
	DBMS_OUTPUT.PUT_LINE(' ');
	DBMS_OUTPUT.PUT_LINE('source file : &1/&2');
	DBMS_OUTPUT.PUT_LINE('dest file   : &3/&4 copied.');
EXCEPTION
	WHEN OTHERS THEN
		DBMS_OUTPUT.PUT_LINE(SQLCODE()||':'||SQLERRM());
END;
/

undefine 1
undefine 2
undefine 3
undefine 4
set verify on
set serveroutput off

他の手はないかな？？？　あ、dbms_file_transfer.copy_fileプロシージャを使ったらどうか？

ただし、バイナリファイルをうまくコピーできるようになりましたが、このプロシージャにはいくつか制限があります。
Oracle® Database PL/SQLパッケージおよびタイプ・リファレンス 12c リリース1 (12.1) DBMS_FILE_TRANSFER
コピーされるファイルのサイズは512バイトの倍数である必要があります。
コピーされるファイルのサイズは、2TB以下である必要があります。
コピーの進行状況を監視するには、V$SESSION_LONGOPS動的パフォーマンス・ビューを参照します。

コピーできない例
512バイトの倍数でないバイナリファイルをコピーしようとすると。。。

11:17:20 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
hoge.dmp                                                               file       1083412480 18-09-23
hoge.log                                                               file             1202 18-09-23
hoge.dmp.gz                                                            file          2603349 18-09-24
hoge.log.gz                                                            file              512 18-09-24
hoge.log.bak1                                                          file             1202 18-09-24
hoge.dmp.bak1                                                          file            45093 18-09-24
01/                                                                    directory        4096 18-09-24

7行が選択されました。

11:18:02 rdsora121@BILL> @cp_transferfile test_dir hoge.dmp.gz test_dir hoge.dmp.gz.bak1
-19505:ORA-19505: ファイル"/rdsdbdata/userdirs/01/hoge.dmp.gz"の識別に失敗しました。
ORA-27046: ファイル・サイズが論理ブロック・サイズの倍数ではありません。
Additional information: 1

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

うまくコピーできる例
512バイトの倍数サイズのバイナリファイルのコピー

11:23:12 rdsora121@BILL> @cp_transferfile test_dir hoge.dmp test_dir hoge.dmp.bak2

source file : test_dir/hoge.dmp
dest file   : test_dir/hoge.dmp.bak2 copied.

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

11:24:01 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
hoge.dmp                                                               file       1083412480 18-09-23
hoge.log                                                               file             1202 18-09-23
hoge.dmp.gz                                                            file          2603349 18-09-24
hoge.log.gz                                                            file              512 18-09-24
hoge.log.bak1                                                          file             1202 18-09-24
hoge.dmp.bak1                                                          file            45093 18-09-24
01/                                                                    directory        4096 18-09-24
hoge.dmp.bak2                                                          file       1083412480 18-09-24

8行が選択されました。

dbms_transfer_fileパッケージを利用したコードは以下の通り
これも制限が多くなければコードも短くてうれしいわけなんですが。。。しかたなし

11:24:10 rdsora121@BILL> !cat cp_transferfile.sql
set verify off
set serveroutput on format wrapped
BEGIN
	DBMS_FILE_TRANSFER.COPY_FILE(
                source_directory_object => UPPER('&1')
                ,source_file_name => '&2'
                ,destination_directory_object => UPPER('&3')
                ,destination_file_name => '&4'
	);
	DBMS_OUTPUT.PUT_LINE(' ');
	DBMS_OUTPUT.PUT_LINE('source file : &1/&2');
	DBMS_OUTPUT.PUT_LINE('dest file   : &3/&4 copied.');
EXCEPTION
	WHEN OTHERS THEN
		DBMS_OUTPUT.PUT_LINE(SQLCODE()||':'||SQLERRM());
END;
/

undefine 1
undefine 2
undefine 3
undefine 4
set verify on
set serveroutput off

制限もあるし、使いやすいような使いにくいような...
いろいろ消化不良状態。。。なので

スクリプト長くなってめんどくさいけど、この部分楽はできない模様なので、手作り決定！

最終的に、既存プロシージャにないのなら、作っちゃえ。ということで、cp_file.sqlを全面作り変えw ました。

11:32:13 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
hoge.dmp                                                               file       1083412480 18-09-23
hoge.log                                                               file             1202 18-09-23
hoge.dmp.gz                                                            file          2603349 18-09-24
hoge.log.gz                                                            file              512 18-09-24
01/                                                                    directory        4096 18-09-24

11:32:21 rdsora121@BILL> @cp_file test_dir hoge.dmp test_dir hoge.dmp.bak
TEST_DIR/hoge.dmp (1083412480) to TEST_DIR/hoge.dmp.bak (1083412480)

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

11:33:07 rdsora121@BILL> @cp_file test_dir hoge.log test_dir hoge.log.bak
TEST_DIR/hoge.log (1202) to TEST_DIR/hoge.log.bak (1202)

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

11:33:26 rdsora121@BILL> @cp_file test_dir hoge.dmp.gz test_dir hoge.dmp.gz.bak
TEST_DIR/hoge.dmp.gz (2603349) to TEST_DIR/hoge.dmp.gz.bak (2603349)

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

11:33:42 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
hoge.log                                                               file             1202 18-09-23
hoge.dmp                                                               file       1083412480 18-09-23
hoge.dmp.gz                                                            file          2603349 18-09-24
hoge.log.gz                                                            file              512 18-09-24
hoge.dmp.bak                                                           file       1083412480 18-09-24
hoge.log.bak                                                           file             1202 18-09-24
01/                                                                    directory        4096 18-09-24
hoge.dmp.gz.bak                                                        file          2603349 18-09-24

8行が選択されました。

新、cp_file.sqlのスクリプトは以下の通り。基本的に、gzip_file.sql内部で利用していたバイナリファイルのハンドリング部分を抜き出した感じです。一部違うのは DBMS_LOB.CREATETEMPORARYで一時BLOBを読んでいるところ。BFILEからBLOBをロードして、出力先ファイルへ書き出しているかしょは圧縮で利用しているコードと同じです。最後に一時BLOBの解放をお忘れなく

11:34:21 rdsora121@BILL> !cat cp_file.sql
SET VERIFY OFF
SET SERVEROUTPUT ON FORMAT WRAPPED
DECLARE
  vSrcfile           BFILE;
  vSrcBlob           BLOB;
  vSrcDirectoryName  VARCHAR2(30);
  vDestDirectoryName VARCHAR2(30);
  vSrcFileName       VARCHAR2(60);
  vDestFileName      VARCHAR2(60); 
  vSrcFileSize       PLS_INTEGER;
  vDestFileSize      PLS_INTEGER;

  PROCEDURE close_bfile
  (
    iBfile IN OUT NOCOPY BFILE
  ) 
  IS
  BEGIN
    IF DBMS_LOB.ISOPEN(iBfile) = 1 THEN
      DBMS_LOB.CLOSE(iBfile);
    END IF;
  END close_bfile;

  PROCEDURE write_blob_to_file
  (
    iDirectoryName  IN VARCHAR2
    , iFileName       IN VARCHAR2
    , iSrcBlob        IN OUT NOCOPY BLOB
  ) 
  IS
    vFile UTL_FILE.FILE_TYPE;
  BEGIN
    vFile := UTL_FILE.FOPEN(
               UPPER(iDirectoryName)
               , iFileName
               , 'wb'
               , 32767
             );

    DECLARE
      cChunkSize CONSTANT PLS_INTEGER := 32767;

      vBuffer    RAW(32767);
      vAmount     PLS_INTEGER := cChunkSize;      
      vNumOfChunk PLS_INTEGER;
    BEGIN
      vNumOfChunk := CEIL(DBMS_LOB.GETLENGTH(iSrcBlob)/cChunkSize);
      FOR chunk# IN 1..vNumOfChunk LOOP
        DBMS_LOB.READ(
          iSrcBlob
          , vAmount
          , (cChunkSize * (chunk# - 1)) + 1 /*offset*/
          , vBuffer
        );
        UTL_FILE.PUT_RAW(vFile, vBuffer, TRUE);
      END LOOP;
    END;
    UTL_FILE.FCLOSE(vFile);
  END write_blob_to_file;

BEGIN
  vSrcDirectoryName := UPPER('&1');
  vSrcFileName   := '&2';
  vDestDirectoryName := UPPER('&3');
  vDestFileName  := '&4';
  
  vSrcFile 
    := BFILENAME(UPPER(vSrcDirectoryName), vSrcFileName);

  DBMS_LOB.OPEN(vSrcFile);
  vSrcFileSize := DBMS_LOB.GETLENGTH(vSrcFile);


  DBMS_LOB.CREATETEMPORARY (
    lob_loc => vSrcBlob
    , cache   => false
    , dur     => DBMS_LOB.SESSION
  );
   
  DBMS_LOB.LOADFROMFILE (
    dest_lob => vSrcBlob
    , src_lob => vSrcFile
    , amount   => vSrcFileSize
    , dest_offset => 1
    , src_offset => 1
  );
  vDestFileSize := DBMS_LOB.GETLENGTH(vSrcBlob);

  write_blob_to_file(
    UPPER(vDestDirectoryName)
    , vDestFileName
    , vSrcBlob
  );
    
  DBMS_LOB.FREETEMPORARY(vSrcBlob);
  close_bfile(vSrcFile);

  DBMS_OUTPUT.PUT_LINE(
    vSrcDirectoryName||'/'||vSrcFileName||' ('||vDestFileSize||') to '
    ||vDestDirectoryName||'/'||vDestFileName||' ('||vSrcFileSize||')'
  );
EXCEPTION
  WHEN OTHERS THEN
    DBMS_LOB.FREETEMPORARY(vSrcBlob);
    close_bfile(vSrcFile);
    RAISE;
END;
/

UNDEFINE 1
UNDEFINE 2
UNDEFINE 3
UNDEFINE 4
SET SERVEROUTPUT OFF
SET VERIFY ON

ということで、次回へづつく。:)

---

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ
・RDS Oracle 雑多なメモ#10 / FAQ

RDS Oracle 雑多なメモ#10 / FAQ

メモの続きです。
前回は、dbms_datapumpパッケージを利用してエクスポートを行うスクリプトを作成しました。
今回は、作成したダンプファイル（バイナリファイルでサイズは1GB越え）をutl_compressパッケージを利用して圧縮するスクリプトを作成します。

このネタ実は、12年前の古いネタが元になっています。
Mac De Oracle (PL/SQL De COMPRESS)
Mac De Oracle (PL/SQL De UNCOMPRESS)

ということで、RDS Oracleのディレクトリオブジェクトにエクポートしたダンプファイル（バイナリファイル）圧縮してみましょう。。動くのか？。。。

ディレクトリを確認

10:48:42 rdsora121@BILL> @list_dir

DIRECTORY_NAME                           DIRECTORY_PATH
---------------------------------------- ----------------------------------------------------------------------
ADUMP                                    /rdsdbdata/log/audit
BDUMP                                    /rdsdbdata/log/trace
DATA_PUMP_DIR                            /rdsdbdata/datapump
HOGE_DIR                                 /rdsdbdata/userdirs/02
OPATCH_INST_DIR                          /rdsdbbin/oracle/OPatch
OPATCH_LOG_DIR                           /rdsdbbin/oracle/QOpatch
OPATCH_SCRIPT_DIR                        /rdsdbbin/oracle/QOpatch
TEST_DIR                                 /rdsdbdata/userdirs/01

8行が選択されました。

エクスポートしたダンプファイル（バイナリファイル）とログファイル（テキストファイル）が対象ディレクトリ以下にあることを確認

10:42:05 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
hoge.dmp                                                               file       1083412480 18-09-23
hoge.log                                                               file             1202 18-09-23
01/                                                                    directory        4096 18-09-24

まず、ダンプファイル（バイナリファイル）を圧縮します。ダンプファイルは圧縮効率がいいんですよね。なので転送する際には圧縮するのがオススメ
圧縮はうまくいった？ようですね。解凍スクリプト編で正常に解凍できるか確認する予定なのでしばしお待ちを。

10:46:00 rdsora121@BILL> @gzip_file test_dir hoge.dmp
TEST_DIR/hoge.dmp compressed to hoge.dmp.gz(99.76%)

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

圧縮したファイルは、.gzの拡張子をつけて出力するようにしています。

10:46:23 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
hoge.dmp                                                               file       1083412480 18-09-23
hoge.log                                                               file             1202 18-09-23
hoge.dmp.gz                                                            file          2603349 18-09-24
01/                                                                    directory        4096 18-09-24

次に、テキストファイルも圧縮！

10:46:32 rdsora121@BILL> @gzip_file test_dir hoge.log
TEST_DIR/hoge.log compressed to hoge.log.gz(57.4%)

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

10:46:51 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
hoge.dmp                                                               file       1083412480 18-09-23
hoge.log                                                               file             1202 18-09-23
hoge.dmp.gz                                                            file          2603349 18-09-24
hoge.log.gz                                                            file              512 18-09-24
001/                                                                    directory        4096 18-09-24

スクリプトは以下の通り、utl_compressパッケージを利用しています。バイナリファイルはBFILEから読み込み、圧縮、圧縮結果のバイナリは一時BLOBで返されるので、一時BLOBをバイナリファイルとして書き出しています。最後に一時BLOBを解放してあげてゴミ掃除という流れです。

10:46:58 rdsora121@BILL> !cat gzip_file.sql
SET VERIFY OFF
SET SERVEROUTPUT ON FORMAT WRAPPED
DECLARE
  vSrcfile        BFILE;
  vCompressedBlob BLOB;
  vDirectoryName  VARCHAR2(30);
  vSrcFileName    VARCHAR2(60);
  vDestFileName   VARCHAR2(60); 
  vSrcFileSize    PLS_INTEGER;
  vDestFileSize   PLS_INTEGER;

  PROCEDURE close_bfile
  (
    iBfile IN OUT NOCOPY BFILE
  ) 
  IS
  BEGIN
    IF DBMS_LOB.ISOPEN(iBfile) = 1 THEN
      DBMS_LOB.CLOSE(iBfile);
    END IF;
  END close_bfile;

  PROCEDURE write_blob_to_file
  (
    iDirectoryName  IN VARCHAR2,
    iFileName       IN VARCHAR2,
    iSrcBlob        IN OUT NOCOPY BLOB
  ) 
  IS
    vFile UTL_FILE.FILE_TYPE;
  BEGIN
    vFile := UTL_FILE.FOPEN(
               UPPER(iDirectoryName), 
               iFileName, 
               'wb', 
               32767
             );

    DECLARE
      cChunkSize CONSTANT PLS_INTEGER := 32767;

      vBuffer    RAW(32767);
      vAmount     PLS_INTEGER := cChunkSize; 
      vNumOfChunk PLS_INTEGER;
    BEGIN
      vNumOfChunk := CEIL(DBMS_LOB.GETLENGTH(iSrcBlob)/cChunkSize);
      FOR chunk# IN 1..vNumOfChunk LOOP
        DBMS_LOB.READ(
          iSrcBlob, 
          vAmount, 
          (cChunkSize * (chunk# - 1)) + 1, /*offset*/
          vBuffer
        );
        UTL_FILE.PUT_RAW(vFile, vBuffer, TRUE);
      END LOOP;
    END;

    UTL_FILE.FCLOSE(vFile);
  END write_blob_to_file;
--
BEGIN
  vDirectoryName := UPPER('&1');
  vSrcFileName   := '&2';
  vDestFileName  := '&2'||'.gz';
  
  vSrcFile 
    := BFILENAME(UPPER(vDirectoryName), vSrcFileName);

  DBMS_LOB.OPEN(vSrcFile);
  vSrcFileSize := DBMS_LOB.GETLENGTH(vSrcFile);
  vCompressedBlob := UTL_COMPRESS.LZ_COMPRESS(vSrcFile);
  vDestFileSize := DBMS_LOB.GETLENGTH(vCompressedBlob);

  write_blob_to_file(
    UPPER(vDirectoryName), 
    vDestFileName, 
    vCompressedBlob
  );
    
  DBMS_LOB.FREETEMPORARY(vCompressedBlob);
  close_bfile(vSrcFile);

  DBMS_OUTPUT.PUT_LINE(
    vDirectoryName
    ||'/'||vSrcFileName||' compressed to '
    ||vDestFileName||'('
    ||ROUND((1 - (vDestFileSize / vSrcFileSize)) * 100, 2)||'%)'
  );
XCEPTION
  WHEN OTHERS THEN
    DBMS_LOB.FREETEMPORARY(vCompressedBlob);
    close_bfile(vSrcFile);
    RAISE;
END;
/

UNDEFINE 1
UNDEFINE 2
SET SERVEROUTPUT OFF
SET VERIFY ON

できた〜

ということで、次回へづつく。:)

---

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ
・RDS Oracle 雑多なメモ#9 / FAQ

RDS Oracle 雑多なメモ#9 / FAQ

メモの続きです。
ということで、　（どういうことだ〜っ。久々に一人、ツッコミ）

圧縮解凍ネタに進む前に、dbms_datapumpパッケージを使って、1GB越えのファイルを作っておこうかと。ここで作成したダンプファイルを圧縮解凍ネタにしようと思います。
事前にscottユーザーを作成して、hoge表を作成し、1GB程度のセグメントサイズになるようにデータを登録、その後、主キー索引を追加してあります。

14:29:48 rdsora121@BILL> desc scott.hoge
 名前                                       NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID                                        NOT NULL NUMBER
 FOO                                                VARCHAR2(4000)
 
14:31:24 rdsora121@BILL>select segment_name,sum(bytes)/1024/1024/1024 "GB" from dba_segments where owner='SCOTT' group by segment_name;

SEGMENT_NAME                           GB
------------------------------ ----------
PK_HOGE                        .004882813
HOGE                                2.125

経過: 00:00:00.09
14:28:59 rdsora121@BILL> @list_dir

DIRECTORY_NAME                           DIRECTORY_PATH
---------------------------------------- ----------------------------------------------------------------------
ADUMP                                    /rdsdbdata/log/audit
BDUMP                                    /rdsdbdata/log/trace
DATA_PUMP_DIR                            /rdsdbdata/datapump
HOGE_DIR                                 /rdsdbdata/userdirs/02
OPATCH_INST_DIR                          /rdsdbbin/oracle/OPatch
OPATCH_LOG_DIR                           /rdsdbbin/oracle/QOpatch
OPATCH_SCRIPT_DIR                        /rdsdbbin/oracle/QOpatch
TEST_DIR                                 /rdsdbdata/userdirs/01

8行が選択されました。

経過: 00:00:00.03
14:29:03 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
01/                                                                    directory        4096 18-09-22

scottユーザーのhoge表を表モードでエクスポートしてダンプファイルをtest_dirへ出力させます！
以前やっつけで作ったのスクリプトの再利用なので、エクスポートモードなど他のパラメータも変更できるようにすれば、より良く改良できると思います。いまはやりませんがw
（以前の記事も参考にしてみてくさい。SQL Tuning Setのキャプチャから退避までのスクリプト（やっつけ）)
出力されたダンプファイルは約1GBってところですね。

14:35:41 rdsora121@BILL> @export_table test_dir hoge scott hoge
"BILL"."EXPTABLE_HOGE"を起動しています:
BLOCKSメソッドを使用して見積り中です...
オブジェクト型TABLE_EXPORT/TABLE/TABLE_DATAの処理中です
BLOCKSメソッドを使用した見積り合計: 2.125 GB
オブジェクト型TABLE_EXPORT/TABLE/TABLEの処理中です
オブジェクト型TABLE_EXPORT/TABLE/INDEX/INDEXの処理中です
オブジェクト型TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINTの処理中です
オブジェクト型TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICSの処理中です
オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICSの処理中です
オブジェクト型TABLE_EXPORT/TABLE/STATISTICS/MARKERの処理中です
. . "SCOTT"."HOGE"                              1.008 GB  270000行がエクスポートされました
マスター表"BILL"."EXPTABLE_HOGE"は正常にロード/アンロードされました
******************************************************************************


BILL.EXPTABLE_HOGEに設定されたダンプ・ファイルは次のとおりです:
/rdsdbdata/userdirs/01/hoge.dmp
ジョブ"BILL"."EXPTABLE_HOGE"が日 9月 23 05:36:33 2018 elapsed 0 00:00:35で正常に完了しました

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

経過: 00:00:40.23
14:36:34 rdsora121@BILL> 
14:37:04 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
01/                                                                    directory        4096 18-09-23
hoge.log                                                               file             1202 18-09-23
hoge.dmp                                                               file       1083412480 18-09-23

表モードエクスポートのDataPump Exportジョブを実行するスクリプトは以下のとおり。
（表モードに固定してある部分を変更してスキーマモードにしたり、複数の表のエクスポートに対応できるように改造してやれば、より便利なスクリプトにすることもできると思います。）

14:36:34 rdsora121@BILL> !cat export_table.sql
SET VERIFY OFF
SET SERVEROUTPUT ON
DECLARE
  v4Debug VARCHAR2(50);
  cDirectory CONSTANT VARCHAR2(30) := UPPER('&1');
  cDumpFileName CONSTANT VARCHAR2(64) := '&2'||'.dmp';
  cLogFileName CONSTANT VARCHAR2(64) := '&2'||'.log';
  cSchemaName CONSTANT VARCHAR2(30) := UPPER('&3');
  cTableName CONSTANT VARCHAR2(30) := UPPER('&4');
  i NUMBER;
  vDataPumpJobHandle NUMBER; 
  vProgress_ratio NUMBER;
  vJobState VARCHAR2(30);
  oLogEntry ku$_LogEntry;
  oStatus ku$_Status;
BEGIN
  DBMS_OUTPUT.ENABLE;
  
  v4Debug := 'OPEN';
  vDataPumpJobHandle 
   := DBMS_DATAPUMP.OPEN (
     operation => 'EXPORT'
     ,job_mode => 'TABLE'
     ,remote_link => NULL
     ,job_name => 'EXPTABLE_'||cTableName
     ,version => 'LATEST'
   );

  v4Debug := 'ADD_FILE - dumpfile';
  DBMS_DATAPUMP.ADD_FILE (
    handle => vDataPumpJobHandle
    ,filename => cDumpFileName
    ,directory => cDirectory
    ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_DUMP_FILE
  );

  v4Debug := 'ADD_FILE - logfile';
  DBMS_DATAPUMP.ADD_FILE (
    handle => vDataPumpJobHandle
    ,filename => cLogFileName
    ,directory => cDirectory
    ,filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_LOG_FILE
  );

  v4Debug := 'METADATA_FILTER - schema name';
  DBMS_DATAPUMP.METADATA_FILTER (
    handle => vDataPumpJobHandle
    ,name => 'SCHEMA_LIST'
    ,value => '''' || cSchemaName || ''''
  );

  v4Debug := 'METADATA_FILTER - table name';
  DBMS_DATAPUMP.METADATA_FILTER (
    handle => vDataPumpJobHandle
    ,name => 'NAME_LIST'
    ,value => '''' || cTableName || ''''
  );

  v4Debug := 'START_JOB';
  DBMS_DATAPUMP.START_JOB (
    handle => vDataPumpJobHandle
  );

  v4Debug := 'JOB_STATE';
  vProgress_ratio := 0;
  vJobState := 'UNDEFINED';
  WHILE (vJobState != 'COMPLETED') AND (vJobState != 'STOPPED') LOOP
    DBMS_DATAPUMP.GET_STATUS (
      vDataPumpJobHandle
      ,DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR 
        + DBMS_DATAPUMP.KU$_STATUS_JOB_STATUS 
        + DBMS_DATAPUMP.KU$_STATUS_WIP
      ,-1
      ,vJobState
      ,oStatus
    );

    IF (BITAND(oStatus.mask, DBMS_DATAPUMP.KU$_STATUS_WIP) != 0)
    THEN
      oLogEntry := oStatus.wip;
    ELSE
      IF (BITAND(oStatus.mask, DBMS_DATAPUMP.KU$_STATUS_JOB_ERROR) != 0)
      THEN
        oLogEntry := oStatus.error;
      ELSE
        oLogEntry := NULL;
      END IF;
    END IF;
    IF oLogEntry IS NOT NULL
    THEN
      i := oLogEntry.FIRST;
      WHILE i IS NOT NULL LOOP
        DBMS_OUTPUT.PUT_LINE(oLogEntry(i).LogText);
        i := oLogEntry.NEXT(i);
      END LOOP;
    END IF;
  END LOOP;

  DBMS_DATAPUMP.DETACH(vDataPumpJobHandle);
EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE(sqlerrm());
    DBMS_OUTPUT.PUT_LINE(v4Debug);
    RAISE;
END;
/

UNDEFINE 1
UNDEFINE 2
UNDEFINE 3
UNDEFINE 4
SET SERVEROUTPUT OFF
SET VERIFY ON

ということで、次回へづつく。:)

---

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ
・RDS Oracle 雑多なメモ#8 / FAQ

RDS Oracle 雑多なメモ#8 / FAQ

メモの続きです。
前回は、utl_fileパッケージでrmっぽいことを行うスクリプトを作成しました。
前回まででutl_fileパッケージを利用したディレクトリオブジェクト配下のファイル操作スクリリプトを作ることができました。

さて、今回はなにをしましょう？。。。。としばし考えて浮かんだのが、昔の圧縮解凍ネタとdbms_datapumpネタの組み合わせ。。。

再利用ネタ、その１は以下。
SQL Tuning Setのキャプチャから退避までのスクリプト（やっつけ
上記ネタの何を利用するかというと、DBMS_DATAPUMPパッケージ。このパッケージもディレクトリオブジェクトを利用するのでネタとしてはちょうどよさげ。

もう一つのネタはかなり古い（12年前？w）
Mac De Oracle (PL/SQL De COMPRESS)
Mac De Oracle (PL/SQL De UNCOMPRESS)
この辺りを使って、圧縮、解凍スクリプトも作っておいたら便利なんじゃないかとおもいます。

それから、kempe さんの記事も利用すればいろいろできそうですね。 プライベートサブネットのVPCエンドポイント経由でS3とやりとりすればパブリックネットワークは経由しなくて良さそうですし:)
RDSとS3でファイルのやり取りを行う

なお、11.2では、aclパラメータに.xml拡張子が必要ですが、12.1以降では必要ありません（いつ変わったw）が、12c以降では以下プロシージャは非推奨で下位互換向けにのこされています）
11.2のマニュアルには aclパラメータには、.xml 拡張子が必要とは明記されていないのですが、意味不明なエラーが返されます。例のaclには.xml拡張子が付加されているのですが、パラメータの解説では一切触れられていないのでハマることがあるので注意しましょうね。

15:54:54 orcl@SYS> select version from v$instance;

VERSION
-----------------
11.2.0.4.0

15:54:00 orcl@SYS> !cat test.sql
begin
  dbms_network_acl_admin.create_acl (
    acl => 'test'
    , description => 'acl create test'
    , principal => 'SCOTT'
    , is_grant => true
    , privilege => 'connect'
  );
end;
/

15:54:07 orcl@SYS> @test
begin
*
ERROR at line 1:
ORA-46059: Invalid ACL identifier specified
ORA-06512: at "SYS.DBMS_NETWORK_ACL_ADMIN", line 70
ORA-06512: at "SYS.DBMS_NETWORK_ACL_ADMIN", line 218
ORA-06512: at line 2

15:54:19 orcl@SYS> !cat test.sql
begin
  dbms_network_acl_admin.create_acl (
    acl => 'test.xml'
    , description => 'acl create test'
    , principal => 'SCOTT'
    , is_grant => true
    , privilege => 'connect'
  );
end;
/

15:54:25 orcl@SYS> @test

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.02
15:54:27 orcl@SYS> exec dbms_network_acl_admin.drop_acl('test.xml');

PL/SQL procedure successfully completed.

dbms_network_acl_adminについては11.2と12.1で考慮はいるかもしれません。（非推奨プロシージャはいずれ廃止されるでしょうから）

というあたりも考慮してネタを作るかどうか。。。
その前に、ファイル、圧縮解凍だけのネタを作っておくか。。

ということで、次回へづつく。:)

---

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ
・RDS Oracle 雑多なメモ#7 / FAQ

RDS Oracle 雑多なメモ#7 / FAQ

メモの続きです。
前回は、utl_fileパッケージでcpっぽいことを行うスクリプトを作成しました。
今回は、ディレクトリオブジェクト以下のファイルにrmっぽい操作が行えるようなスクリプトを作ります :)

作成済みのtest_dirディレクトのファイルを再利用しています。

ディレクトリとファイルを指定してファイル削除！

17:11:54 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
top100_tables_v1.txt                                                   file             2277 18-09-19
top100_tables_v2.txt                                                   file             2277 18-09-21
01/                                                                    directory        4096 18-09-21


17:12:37 rdsora121@BILL> @rm_file test_dir top100_tables_v2.txt
TEST_DIR/top100_tables_v2.txt removed.

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

経過: 00:00:00.03

17:13:25 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
top100_tables_v1.txt                                                   file             2277 18-09-19
01/                                                                    directory        4096 18-09-22

スクリプトは以下の通り。UTL_FILE.FREMOVEを呼び出しているだけの単純なスクリプトにしてあります
第一回目にも書きましたが、スクリプトは、EC2など、SQL*Plusを起動しているクライアント側に作成します。

17:14:51 rdsora121@BILL> !cat rm_file.sql
set verify off
set serveroutput on
BEGIN
  UTL_FILE.FREMOVE (
    location => UPPER('&1')
    , filename => '&2'
  );
  DBMS_OUTPUT.PUT_LINE(UPPER('&1')||'/&2 removed.');
EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE(SQLCODE()||':'||SQLERRM());
END;
/

set serveroutput off
undefine 1
undefine 2
set verify on

次回へ続く

---

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ
・RDS Oracle 雑多なメモ#6 / FAQ

---

ところで、今年も秋葉原UDXで開催されたdb tech showcase 2018へ参加してきました。
今回、自分のセッションも司会もなしだったので、久々にゆっくりといろいろな方のセッションを聞くことがきたし、毎年このイベント合う多数のデータベースエンジニアとの交流もたのしくてたのしくてw それ以上表現のしようがないw
（ボキャ貧なのでごめんなさい、ごめんなさい）

そして、インサイトテクノロジーの社長を退かれた小幡さん、　”おもしろった！” ありがとうございました。
おいしいみかんできたら、送ってね　:)

RDS Oracle 雑多なメモ#6 / FAQ

メモの続きです。
前回は、utl_fileパッケージでmvっぽいことを行うスクリプトを作成しました。
今回は、ディレクトリオブジェクト以下のファイルにcpっぽい操作が行えるようなスクリプトを作ります :)

---

ただ、　utl_file.fcopyってテキストファイルしかコピーできないんだよね。という制限付きです。いまのところ。
（バイナリ版は手作りで作ればできたような、。。。昔のネタ引っ張り出すかw）

ということで、utl_file.fcopyもdbms_transfer_fileパッケージも使わずにLOB系操作でバイナリファイルとテキストファイルをコピーするよう、cp_file.sqlスクリプトを作り変えました。

RDS Oracle 雑多なメモ#11 / FAQも合わせて参照ください。m(_ _)m

---

作成済みのtest_dirとhoge_dirディレクトリとファイルを再利用しています。
ざっくりめで書いたので複数ファイルの一括コピーや引数の指定方法などなど、改善したいところはあるわけですがw　適宜対応ということで。

同一ディレクトリでファイルコピー

00:44:59 SQL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
top100_tables_v1.txt                                                   file             2277 18-09-19
01/                                                                    directory        4096 18-09-21

経過: 00:00:02.35
00:55:33 SQL> @cp_file test_dir top100_tables_v1.txt test_dir top100_tables_v2.txt

source file : test_dir/top100_tables_v1.txt
dest file   : test_dir/top100_tables_v2.txt copied.

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

経過: 00:00:00.04
00:57:42 SQL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
top100_tables_v1.txt                                                   file             2277 18-09-19
top100_tables_v2.txt                                                   file             2277 18-09-21
01/                                                                    directory        4096 18-09-21

異なるディレクトリへ同一名でファイルコピー

01:01:55 SQL> @cp_file test_dir top100_tables_v2.txt hoge_dir top100_tables_v2.txt

source file : test_dir/top100_tables_v2.txt
dest file   : hoge_dir/top100_tables_v2.txt copied.

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

経過: 00:00:00.05
01:05:13 SQL> @ls_dir hoge_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
top100_tables_v2.txt                                                   file             2277 18-09-21
02/                                                                    directory        4096 18-09-21

異なるディレクトリへ異なるファイル名でコピー

01:06:30 SQL> @cp_file test_dir top100_tables_v2.txt hoge_dir top100_tables_v3.txt

source file : test_dir/top100_tables_v2.txt
dest file   : hoge_dir/top100_tables_v3.txt copied.

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

経過: 00:00:00.04
01:06:47 SQL> @ls_dir hoge_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
top100_tables_v2.txt                                                   file             2277 18-09-21
02/                                                                    directory        4096 18-09-21
top100_tables_v3.txt                                                   file             2277 18-09-21

スクリプトは以下の通り。

01:09:56 SQL> !cat cp_file.sql
set verify off
set serveroutput on format wrapped
BEGIN
	UTL_FILE.FCOPY(
		src_location => UPPER('&1')
		,src_filename => '&2'
		,dest_location => UPPER('&3')
		,dest_filename => '&4'
	);
	DBMS_OUTPUT.PUT_LINE(' ');
	DBMS_OUTPUT.PUT_LINE('source file : &1/&2');
	DBMS_OUTPUT.PUT_LINE('dest file   : &3/&4 copied.');
EXCEPTION
	WHEN OTHERS THEN
		DBMS_OUTPUT.PUT_LINE(SQLCODE()||':'||SQLERRM());
END;
/

undefine 1
undefine 2
undefine 3
undefine 4
set verify on
set serveroutput off

次回へ続く

---

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ
・RDS Oracle 雑多なメモ#5 / FAQ

RDS Oracle 雑多なメモ#5 / FAQ

メモの続きです。
前回は、AWS提供のrdsadmin.rds_file_util.read_text_file関数でcatっぽいスクリプトを作っておきました。（改善したほうがよさげなところもありますがw）
今回は、ディレクトリオブジェクト以下のファイルにmvっぽい操作が行えるようなスクリプトを作ります。

これからの操作はファイルそのものに対しておこなうので、 わかりやすくする意味もあり新たにディレクトオブジェクトを作成して、ファイルを一作っておきます。

実験用ディレクトリオブジェクトの作成

00:49:07 rdsora121@BILL> @create_dir test_dir

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

経過: 00:00:02.04

DIRECTORY_NAME                           DIRECTORY_PATH
---------------------------------------- ----------------------------------------------------------------------
TEST_DIR                                 /rdsdbdata/userdirs/01

経過: 00:00:00.03

作成したディレクトリオブジェクト以下に適当なファイル（今回はテキストファイル）を作成

01:05:30 rdsora121@BILL> @query2file.sql

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

経過: 00:00:00.12

ここでは、”utl_file I/O” - この症状はあれの可能性が高いですね。でも紹介したUTL_FILEパッケージでディレクトオブジェクト以下にファイルを出力するサンプルを再利用してファイルを書き出しました。

01:06:02 rdsora121@BILL> !cat query2file.sql
DECLARE
	cDIR_NAME CONSTANT VARCHAR2(30) := 'TEST_DIR';
	cFILE_NAME CONSTANT VARCHAR2(128) := 'top100_tablenames__'||TO_CHAR(systimestamp, 'rrmmddhh24miss.ff')||'.txt';
	cBufferSize CONSTANT BINARY_INTEGER := 32767;
	cOpenMode CONSTANT VARCHAR2(2) := 'w';
	fileHandle UTL_FILE.FILE_TYPE;
	buffer VARCHAR2(32767);
	
	cBulkReadLimit CONSTANT PLS_INTEGER := 324;
	TYPE tBulkReadArray IS TABLE OF VARCHAR2(8192) INDEX BY BINARY_INTEGER;
	bulkReadArray tBulkReadArray;
	CURSOR cur_top100_tablenames IS
		SELECT
                        table_name
		FROM
			dba_tables
		ORDER BY
			table_name
		FETCH FIRST 100 ROWS ONLY
		;
BEGIN
	OPEN cur_top100_tablenames;
	fileHandle := UTL_FILE.FOPEN(cDIR_NAME, cFILE_NAME, cOpenMode, cBufferSize);
	LOOP
		FETCH cur_top100_tablenames
			BULK COLLECT INTO bulkReadArray
			LIMIT cBulkReadLimit;
		
		EXIT WHEN bulkReadArray.COUNT = 0;
	
		buffer := NULL;	
		FOR i IN bulkReadArray.FIRST..bulkReadArray.LAST LOOP
			buffer := buffer || bulkReadArray(i) || UTL_TCP.CRLF;
   		END LOOP;
		UTL_FILE.PUT(fileHandle, buffer);
		UTL_FILE.FFLUSH(fileHandle);
	END LOOP;
	UTL_FILE.FFLUSH(fileHandle);
	UTL_FILE.FCLOSE(fileHandle);
	CLOSE cur_top100_tablenames;
EXCEPTION
	WHEN OTHERS THEN
		IF UTL_FILE.IS_OPEN(fileHandle) THEN
			UTL_FILE.FCLOSE(fileHandle);
		END IF;
		
		IF cur_top100_tablenames%ISOPEN THEN
			CLOSE cur_top100_tablenames;
		END IF;
		RAISE;
END;
/

テキストファイルがディレクトリオブジェクト以下に作成されましった！

01:06:29 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
top100_tablenames__180919160551.113374000.txt                          file             2277 18-09-19
01/                                                                    directory        4096 18-09-19

念のため中身を確認

01:06:38 rdsora121@BILL> @cat_file test_dir top100_tablenames__180919160551.113374000.txt

TEXT
------------------------------------------------------------------------------------------
ACCESS$
ACLMV$
ACLMV$_REFLOG
ACLMVREFSTAT$



・・・中略・・・

AQ$_SUBSCRIBER_TABLE
AQ$_SYS$SERVICE_METRICS_TAB_G
AQ$_SYS$SERVICE_METRICS_TAB_H
AQ$_SYS$SERVICE_METRICS_TAB_I

100行が選択されました。

同一ディレクトリ内でファイル名を変更

01:29:47 rdsora121@BILL> @mv_file test_dir top100_tablenames__180919160551.113374000.txt test_dir top100_tables.txt

source file     : test_dir/top100_tablenames__180919160551.113374000.txt
dest   file     : test_dir/top100_tables.txt moved.

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

長いファイル名称を短く変更！

01:29:57 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
top100_tables.txt                                                      file             2277 18-09-19
01/                                                                    directory        4096 18-09-19

ファイル名は同じままで、別ディレクトリへファイル移動

08:05:17 rdsora121@BILL> @create_dir hoge_dir

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

経過: 00:00:02.26

DIRECTORY_NAME                           DIRECTORY_PATH
---------------------------------------- ----------------------------------------------------------------------
HOGE_DIR                                 /rdsdbdata/userdirs/02

経過: 00:00:00.04
08:05:29 rdsora121@BILL> @mv_file test_dir top100_tables.txt hoge_dir top100_tables.txt

source file     : test_dir/top100_tables.txt
dest   file     : hoge_dir/top100_tables.txt moved.

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

経過: 00:00:00.04
08:06:27 rdsora121@BILL> @ls_dir hoge_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
top100_tables.txt                                                      file             2277 18-09-19
02/                                                                    directory        4096 18-09-19

経過: 00:00:02.25
08:06:39 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
01/                                                                    directory        4096 18-09-19

ファイル名を変更して、ディレクトリ移動

08:08:22 rdsora121@BILL> @mv_file hoge_dir top100_tables.txt test_dir top100_tables_v1.txt

source file     : hoge_dir/top100_tables.txt
dest   file     : test_dir/top100_tables_v1.txt moved.

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

経過: 00:00:00.02
08:09:00 rdsora121@BILL> @ls_dir hoge_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
02/                                                                    directory        4096 18-09-19

経過: 00:00:02.05
08:09:11 rdsora121@BILL> @ls_dir test_dir

FILENAME                                                               TYPE         FILESIZE MTIME
---------------------------------------------------------------------- ---------- ---------- --------
top100_tables_v1.txt                                                   file             2277 18-09-19
01/                                                                    directory        4096 18-09-19

経過: 00:00:02.05

スクリプトは以下の通り

01:30:20 rdsora121@BILL> !cat mv_file.sql
set verify off
set serveroutput on format wrapped
BEGIN
  UTL_FILE.FRENAME(
    src_location => UPPER('&1')
    ,src_filename => '&2'
    ,dest_location => UPPER('&3')
    ,dest_filename => '&4'
    ,overwrite => false
  );
  DBMS_OUTPUT.PUT_LINE(' ');
  DBMS_OUTPUT.PUT_LINE('source file     : &1/&2');
  DBMS_OUTPUT.PUT_LINE('dest   file     : &3/&4 moved.');
EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE(SQLCODE()||':'||SQLERRM());
END;
/

undefine 1
undefine 2
undefine 3
undefine 4
set verify on
set serveroutput off

次回へ続く

---

Previously on Mac De Oracle

・RDS Oracle 雑多なメモ#1 / FAQ
・RDS Oracle 雑多なメモ#2 / FAQ
・RDS Oracle 雑多なメモ#3 / FAQ
・RDS Oracle 雑多なメモ#4 / FAQ

Oracle Database Connect 2018 エキスパートはどう考えるか？ 体感！パフォーマンスチューニング Ⅱ （番外編＝没ネタ）

Oracle Database Connect 2018 エキスパートはどう考えるか？体感！パフォーマンスチューニング Ⅱ
～Autonomous Databaseの到来において必要となるチューニングとは～

これ、パフォーマンスチューニングネタをまとめ上げるまで、みなさんスケジュール調整し、
オンライン／オフラインミーティングを繰り返してネタを詰めていくという、かなーり面倒なことをやっています。
私なんて、ネタの候補検討だけで16時間ぐらい使ってますからねw（自分の余暇を使って、半分楽しみながら、締め切りがあるので半分苦しみながらw）

---

余談はこれくらいにして、今日の本題です。:)

Oracle Database Connect 2018 エキスパートはどう考えるか？ 体感！パフォーマンスチューニング Ⅱ で没にしたネタがあるのですが、
そのまま捨てるのも勿体ないので、多少取得情報を追加した状態で公開しちゃおうと思います。

お時間のありますときに、頭の体操、AWRレポートの解析方法（最近はADDM、ASHレポートまで含まれています）のトレーニングにどうぞ。

遅延原因の想定と、想定原因の特定情報は、このエントリでは公開しません。おそらくGW開けの12日あたりか、その一週間後の19日ごろには原因を公開しようかと:)の後半に追記してあります:)

なお、本ページに公開した情報以外に、追加で見たい情報がある場合は、コメント欄やtwのmentionで具体的にリクエストいただければ、取得されている情報の範囲内で追加公開します。取得されてない情報はその旨を追記していきます。:)
まずは、エスパー力全開で、原因を想定してみてください。>
(かなり難易度高めだとは思いますが、過去この状況に遭遇した経験をお持ちのかたは、ここに公開した程度の情報から勘で言い当てたりしちゃうんですよね。実は、昨年末に、何年か振りでこの症状を目にしたのでネタにしよう思いました。)

以下取得された情報は以下のとおり。以下の情報を元に遅延原因を想定してみてください。

---

なーんでだ？！

---

状況説明
試験時には問題のなかった処理（30分以内に終了する状態が正常な状態です。）をリリースしました。
ところが、30分以上経過しても終了しません。遅延原因を想定、特定してください。
なお、本番環境のメンテナンス時間中に試験を行ったため、データベースインスタンス内で試験を行いリリースしています。
ちなみに、試験時の処理時間は、約21分でしたが、リリース時は約56分と大幅に遅延。

他のトランザクションが走行している状況をミックスするとより
本物っぽくなり、特定に苦労するので面白いのですが、
遅延している処理だけが走行している状況にしてあります。

---

資料1 試験時（正常時）AWRレポート
資料2 リリース時（遅延時）AWRレポート
資料3 試験時（正常時）とリリース時（遅延時）のAWR DIFFレポート

資料4 試験時（正常時）CPU利用率グラフ(調査による多少のノイズあり）

資料5 リリース時（遅延時）CPU利用率グラグ(スパイク部分調査による多少のノイズあり）

GWも後半スタート、天気は少々荒れそうですが、みなさん、よいGWを！

---

---

Twitterでのやり取り....

---

---

ここまでくるとなにかが見えてきたかな。。。原因を特定するまであと一歩な感じ。

追加資料1（遅延時）
top

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
13058 oracle    20   0 10.434g 365704 359548 R 100.0  1.4   1:05.70 oracle_13058_or
 5973 oracle    20   0 1955632 253648  73812 S   4.7  1.0   1:42.62 gnome-shell
 4657 oracle    -2   0 10.417g  58792  55660 S   2.0  0.2   0:12.15 ora_vktm_orcl12
 1285 root      20   0  483544  76000  21372 S   1.7  0.3   0:55.11 Xorg
 4862 oracle    20   0 10.417g  68960  65868 S   1.3  0.3   0:01.23 ora_lg00_orcl12
  223 root      20   0       0      0      0 S   0.7  0.0   0:00.49 kworker/u24:3
13059 oracle    20   0  157976   4564   3544 R   0.7  0.0   0:00.29 top
   ...略...

追加資料2（遅延時）
sar -P ALL

   ...略...
02:47:29 AM    CPU     %user     %nice   %system   %iowait    %steal     %idle
02:47:34 AM    all      4.78      0.00      2.36      0.07      0.00     92.80
02:47:34 AM      0      1.06      0.00      1.06      0.85      0.00     97.03
02:47:34 AM      1      0.20      0.00      0.40      0.00      0.00     99.40
02:47:34 AM      2      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM      3      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM      4      0.00      0.00      0.20      0.00      0.00     99.80
02:47:34 AM      5      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM      6      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM      7     68.08      0.00     31.92      0.00      0.00      0.00
02:47:34 AM      8      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM      9      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM     10      0.00      0.00      0.00      0.00      0.00    100.00
02:47:34 AM     11      0.00      0.00      0.20      0.20      0.00     99.60
   ...略...

追加資料3（遅延時）
perf top -C 7

Samples: 107K of event 'cpu-clock', Event count (approx.): 29550214790                                                              

Overhead  Shared Object       Symbol
   4.36%  libc-2.17.so        [.] vfprintf
   2.77%  oracle              [.] lxoCpStr
   2.00%  [kernel]            [k] __radix_tree_lookup
   1.94%  oracle              [.] dbgfcsIlcsGetNextDef
   1.58%  oracle              [.] skgovprint
   1.48%  [kernel]            [k] __do_softirq
   1.44%  [kernel]            [k] selinux_file_permission
   1.43%  oracle              [.] dbgaFmtAttrCb_int
   1.36%  [kernel]            [k] system_call_after_swapgs
   1.33%  oracle              [.] dbgaAttrFmtProcArg
   1.26%  oracle              [.] dbgtfmWriteMetadata
   1.13%  oracle              [.] dbgtfdFileWrite
   1.02%  libc-2.17.so        [.] _IO_default_xsputn
   ...略...

---

---

その後のやりとり　（Twitter）

そして核心に迫る追加資料が...あったんです。（しばちょうさん風にはしづらかったw）

---

---

正常時（試験時）の追加情報はないようです。リリース後は常に遅いらしい。

ふむふむ。

以下、遅延時のstrace -c -pの情報を取得してもらいました。
straceで眺めるとsystem call write()がダントツで上位にきています。その次が lseek()

追加資料4
strace -c -p

[oracle@localhost ˜]$ sudo strace -c -p 13058
Process 13058 attached
^CProcess 13058 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 77.24   47.883538           1  35085592           write
 19.22   11.913638           1  17542850           lseek
  3.53    2.191099           1   3414889           getrusage
  0.01    0.006377          12       524           semop
  0.00    0.000403           7        62           close
  0.00    0.000210           4        54           chown
  0.00    0.000126           2        63           open
  0.00    0.000099           2        54           lstat
  0.00    0.000050           1        54           chmod
  0.00    0.000029           1        54           stat
  0.00    0.000028           3        10           semtimedop
  0.00    0.000015           0        54           fcntl
  0.00    0.000010           1         8           read
  0.00    0.000007           1         8           select
  0.00    0.000000           0         3           mmap
  0.00    0.000000           0         6           rt_sigprocmask
  0.00    0.000000           0         1           rt_sigreturn
  0.00    0.000000           0         1           readlink
------ ----------- ----------- --------- --------- ----------------
100.00   61.995629              56044287           total

そろそろ突き止めた感が。

なにかを、どこかに、書き出してますよね。

lsofで書き込みに絞って取得してもった結果は以下のとおり。

[root@localhost ˜]# lsof -p 13058 | grep -E '[0-9]+w'
oracle_13 13058 oracle    1w      CHR    1,3         0t0      1038 /dev/null
oracle_13 13058 oracle    2w      CHR    1,3         0t0      1038 /dev/null
oracle_13 13058 oracle    7w      REG   8,17  2351882843  71176413 /u01/app/oracle/diag/rdbms/orcl12c/orcl12c/trace/orcl12c_ora_13058.trc
oracle_13 13058 oracle    8w      REG   8,17   358606101  71176414 /u01/app/oracle/diag/rdbms/orcl12c/orcl12c/trace/orcl12c_ora_13058.trm

ほう。　.trcファイルへ大量の書き込みがあります。

このようになるときは、 なにが起っていると思いますか？

.trcファイルに大量の書き込みのあるケースとして、SQLトレースが有効になっている場合です。（意図したSQLトレースなら問題はないですが...意図していない場合はちょいと問題ですよね。）

ということで、確定診断に移りましょう。

SQL*Plus: Release 12.2.0.1.0 Production on Wed Apr 25 01:23:13 2018

Copyright (c) 1982, 2016, Oracle.  All rights reserved.

Connected.
ORCL@SYSTEM> 
ORCL@SYSTEM> select username,status,event,sql_trace from v$session where paddr = (select addr from v$process where spid = 13058)

USERNAME                       STATUS   EVENT                                                            SQL_TRAC
------------------------------ -------- ---------------------------------------------------------------- --------
SCOTT                          ACTIVE   log file switch completion                                       ENABLED

見ての通り、
SQL_TRACE列がdisabled（デフォルト)からenabledに変わっていることから、.trcファイルへの大量の書き出しは、セッションレベルでSQLトレースが有効化されたため、と言えますよね。

今回の新規リリースバッチ処理遅延の原因は、

SQLトレースを有効化したままリリースしたしまったことにより、オーバーヘッドが発生し、グルグル系バッチ処理のスループットが低下したため！　

ということでした。SQLトレースを利用したあとの無効化をお忘れなく！ :)

SQLトレースは便利な機能の一つですが、インスタンスレベルやグルグル系バッチ処理での利用時は大量のトレース情報の書き出し等によるオーバーヘッドが発生します。
便利なツールではありますが、スループットの低下等による影響を考慮して利用するタイプのツールでもあります。
また、利用した後は、必ず、無効化することもお忘れなく...

ミイラ取りがミイラになってしまってはいみないですから.....ね :)

Temp落ち #4 - 手動PGA管理で作業領域として指定可能な最大サイズ de Temp落ちの確認

---

Previously on Mac De Oracle
手動PGA管理で作業領域として指定可能な最大サイズは、2GB - 1までということの確認でした。
本当に、その程度のサイズまでPGAの作業領域が利用されるのでしょうか？。　念のために確認しておきましょう。 実は、それより少ないサイズで頭打ちなんてことは、ないかな〜　と　わざとらしく言ってみたりして（意味深w

その前に、指定した作業領域を使い切れるぐらい（つまり、Temp落ちさせられる程度）のデータ量の表を準備しておきます。
今回は、Nested Loop Join（NLJ)やソート回避などのための索引は作成しません。Temp落ちのネタなので。

M1とM2の2表を作成し、それぞれ、2.5GB程度のセグメントサイズにしておきます。 なお、以下の無名PL/SQLブロックでは、FORALLを利用して1000行単位でバルク処理しています。配列を利用するのでメモリー使用量にはそれなりに配慮が必要ですが。:)
単純なぐるぐる系INSERTにしてしまうとデータ量が多い場合、性能的に辛くなってしまうので、ここ重要！

ORCL@SCOTT> l
  1  CREATE TABLE m1
  2  (
  3  	id CHAR(7) NOT NULL
  4  	,rev# NUMBER NOT NULL
  5  	,value NUMBER NOT NULL
  6  	,description VARCHAR2(4000)
  7  	,additional_info CHAR(200)
  8* ) NOLOGGING
ORCL@SCOTT> /

Table created.

ORCL@SCOTT> l
  1  DECLARE
  2      TYPE IDS_t IS TABLE OF m1.id%TYPE INDEX BY PLS_INTEGER;
  3      TYPE REV#S_t IS TABLE OF m1.rev#%TYPE INDEX BY PLS_INTEGER;
  4      TYPE VALS_t IS TABLE OF m1.value%TYPE INDEX BY PLS_INTEGER;
  5      IDs IDS_t;
  6      REV#s REV#S_t;
  7      VALs VALS_t;
  8      k PLS_INTEGER := 1;
  9  BEGIN
 10      FOR i IN 1..100000 LOOP
 11          FOR j IN 1..10 LOOP
 12              IDs(k) := 'C' || TO_CHAR(i, 'FM000000');
 13              REV#s(k) := j;
 14              VALs(k) := i + j;
 15              k := k + 1;
 16          END LOOP;
 17          IF MOD(i, 100) = 0 THEN
 18              FORALL l in 1..1000 EXECUTE IMMEDIATE
 19                  'INSERT /*+ APPEND_VALUE NO_GATHER_OPTIMIZER_STATISTICS */ INTO m1 '
 20                   || 'VALUES(:1, :2, :3,  LPAD(''X'',2000, ''X''), LPAD(''9'',200,''9''))'
 21                   USING IDs(l), REV#s(l), VALs(l);
 22              COMMIT;
 23              k := 1;
 24          END IF;
 25      END LOOP;
 26* END;
ORCL@SCOTT> /

PL/SQL procedure successfully completed.

Elapsed: 00:01:22.45
ORCL@SCOTT> select count(1) from m1;

  COUNT(1)
----------
   1000000

ORCL@SCOTT> select segment_name,sum(bytes)/1024/1024/1024 "GB" from user_segments where segment_name='M1' group by segment_name;

SEGMENT_NAME                           GB
------------------------------ ----------
M1                                 2.5625

ORCL@SCOTT> l
  1  CREATE TABLE m2
  2  (
  3  	id CHAR(7) NOT NULL
  4  	,rev# NUMBER NOT NULL
  5  	,value NUMBER NOT NULL
  6  	,description VARCHAR2(4000)
  7* ) NOLOGGING
ORCL@SCOTT> /

Table created.

ORCL@SCOTT> l
  1  INSERT /*+ APPEND NO_GATHER_OPTIMIZER_STATISTICS */ INTO m2
  2* SELECT id,rev#,value,description FROM m1
ORCL@SCOTT> /

1000000 rows created.

Elapsed: 00:00:40.22
ORCL@SCOTT> commit;

Commit complete.

ORCL@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'M1',no_invalidate=>false,method_opt=>'FOR ALL COLUMNS SIZE SKEWONLY');

PL/SQL procedure successfully completed.

ORCL@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'M2',no_invalidate=>false,method_opt=>'FOR ALL COLUMNS SIZE SKEWONLY');

PL/SQL procedure successfully completed.

これで、準備完了。
ちなみに、NO_GATHER_OPTIMIZER_STATISTICSヒントを利用していますが、データ登録後に、ヒストグラムも含めて取得したかったため、バルクロード時のオンラインオプティマイザ統計収集を行わないようにするためのヒントです。
データ登録後オプティマイザ統計を取得するため、データ登録時のオンラインオプティマイザ統計のオーバーヘッドは無駄となるためです。利用できるなら利用したほうがよいとは思いますが、制限もあるのでご一読を（バルク・ロードのためのオンライン統計収集）

---

手動PGA管理で2GB - 1（手動PGA管理での最大 Sort作業領域サイズ）

メモリーソートで2GBぐらいまで利用していることが確認できます。（ソートされるデータ量が2GB以下程度に制限しています。）

ORCL@SCOTT> @manual_sortwk2gb_optimal    
  1* alter session set workarea_size_policy=manual

Session altered.

  1* alter session set sort_area_size = 2147483647

Session altered.

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  WHERE
  9      id <= 'C075000'
 10  ORDER BY
 11      id
 12*     ,rev#
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

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

・・・中略・・・

Global Stats
=================================================
| Elapsed |   Cpu   |  Other   | Fetch | Buffer |
| Time(s) | Time(s) | Waits(s) | Calls |  Gets  |
=================================================
|    5.42 |    4.13 |     1.29 | 50001 |   334K |
=================================================

SQL Plan Monitoring Details (Plan Hash Value=3534657201)
===================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   |  Mem  | Activity | Activity Detail |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | (Max) |   (%)    |   (# samples)   |
===================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        15 |     +2 |     1 |     750K |     . |    20.00 | Cpu (1)         |
|  1 |   SORT ORDER BY      |      |    752K |  439K |        16 |     +1 |     1 |     750K |   2GB |    60.00 | Cpu (3)         |
|  2 |    TABLE ACCESS FULL | M1   |    752K | 90828 |         3 |     +2 |     1 |     750K |     . |    20.00 | Cpu (1)         |
===================================================================================================================================

Temp落ちする程度のデータ量でソートさせた場合も、PGAの作業領域は一旦、2GBまで利用されていることが確認できます。

ORCL@SCOTT> @manual_sortwk2gb
  1* alter session set workarea_size_policy=manual

Session altered.

  1* alter session set sort_area_size = 2147483647

Session altered.

  1  SELECT
  2      /*+
  3          MONITOR
  4      */
  5      *
  6  FROM
  7      m1
  8  ORDER BY
  9      id
 10*     ,rev#
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

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

・・・中略・・・

Global Stats
===========================================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes | Reqs  | Bytes |
===========================================================================================
|      46 |      11 |       15 |       20 | 66668 |   334K | 2148 |   2GB |  2146 |   2GB |
===========================================================================================

SQL Plan Monitoring Details (Plan Hash Value=3534657201)
=====================================================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |      Activity Detail       |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |        (# samples)         |
=====================================================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        60 |     +2 |     1 |       1M |      |       |       |       |     . |     . |     6.38 | Cpu (2)                    |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | PGA memory operation (1)   |
|  1 |   SORT ORDER BY      |      |      1M |  553K |        61 |     +1 |     1 |       1M | 2148 |   2GB |  2146 |   2GB |   2GB |   2GB |    91.49 | Cpu (32)                   |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read temp (10) |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path write temp (1) |
|  2 |    TABLE ACCESS FULL | M1   |      1M | 90822 |        27 |     +2 |     1 |       1M |      |       |       |       |     . |     . |     2.13 | Cpu (1)                    |
=====================================================================================================================================================================================

手動PGA管理で2GB - 1（手動PGA管理での最大 Hash作業領域サイズ） Hash Joinの場合も、手動PGA管理で設定可能な最大サイズ程度まで利用されていることが確認できます。（Temp落ちしない程度のデータ量にしています。）

ORCL@SCOTT> @manual_hashwk2gb_optimal
  1* alter session set workarea_size_policy = manual

Session altered.

  1* alter session set hash_area_size = 2147483647

Session altered.

  1  SELECT
  2      /*+
  3          MONITOR
  4          LEADING(m1 m2)
  5          USE_HASH(m2)
  6      */
  7      *
  8  FROM
  9      m1
 10      INNER JOIN m2
 11      ON
 12          m1.id = m2.id
 13          AND m1.rev# = m2.rev#
 14  WHERE
 15*     m1.id <= 'C075000'
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

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

・・・中略・・・

Global Stats
===========================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
===========================================================================
|    8.05 |    4.66 |     0.16 |     3.23 | 50001 |   717K | 2618 |   3GB |
===========================================================================

SQL Plan Monitoring Details (Plan Hash Value=1822065247)
==================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity | Activity Detail |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |   (# samples)   |
==================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        21 |     +2 |     1 |     750K |      |       |     . |    12.50 | Cpu (1)         |
|  1 |   HASH JOIN          |      |    752K |  181K |        22 |     +1 |     1 |     750K |      |       |   2GB |    25.00 | Cpu (2)         |
|  2 |    TABLE ACCESS FULL | M1   |    752K | 90828 |         2 |     +2 |     1 |     750K |      |       |     . |    25.00 | Cpu (2)         |
|  3 |    TABLE ACCESS FULL | M2   |    759K | 90581 |        20 |     +3 |     1 |     750K | 2618 |   3GB |     . |    37.50 | Cpu (3)         |
==================================================================================================================================================

Hash Joinの場合もSort時と同じように、一時表領域も利用させる程度のデータ量になると、一旦、手動PGA管理で設定可能な最大サイズ程度まで利用したうえでTemp落ちしていることが確認できます。

ORCL@SCOTT> @manual_hashwk2gb
  1* alter session set workarea_size_policy = manual

Session altered.

  1* alter session set hash_area_size = 2147483647

Session altered.

  1  SELECT
  2      /*+
  3          MONITOR
  4          LEADING(m1 m2)
  5          USE_HASH(m2)
  6      */
  7      *
  8  FROM
  9      m1
 10      INNER JOIN m2
 11      ON
 12          m1.id = m2.id
 13*         AND m1.rev# = m2.rev#
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

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

・・・中略・・・

Global Stats
===========================================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes | Reqs  | Bytes |
===========================================================================================
|      12 |    5.68 |     2.17 |     4.59 | 66668 |   706K | 3133 |   3GB |   515 | 511MB |
===========================================================================================

SQL Plan Monitoring Details (Plan Hash Value=1822065247)
=====================================================================================================================================================================================
| Id |      Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  | Write | Write |  Mem  | Temp  | Activity |      Activity Detail       |
|    |                      |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | Reqs  | Bytes | (Max) | (Max) |   (%)    |        (# samples)         |
=====================================================================================================================================================================================
|  0 | SELECT STATEMENT     |      |         |       |        30 |     +2 |     1 |       1M |      |       |       |       |     . |     . |    25.00 | Cpu (4)                    |
|  1 |   HASH JOIN          |      |      1M |  189K |        31 |     +1 |     1 |       1M |  515 | 511MB |   515 | 511MB |   2GB | 515MB |    43.75 | Cpu (5)                    |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read temp (1)  |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path write temp (1) |
|  2 |    TABLE ACCESS FULL | M1   |      1M | 90822 |         6 |     +0 |     1 |       1M |      |       |       |       |     . |     . |    12.50 | Cpu (2)                    |
|  3 |    TABLE ACCESS FULL | M2   |      1M | 90574 |        24 |     +5 |     1 |       1M | 2618 |   3GB |       |       |     . |     . |    18.75 | Cpu (2)                    |
|    |                      |      |         |       |           |        |       |          |      |       |       |       |       |       |          | direct path read (1)       |
=====================================================================================================================================================================================

おまけ 1つのSQLの実行で利用されるPGAの作業領域は1つだけではないということも確認しておきましょうかね。（知ってる方はスルーしてよいですよ：）
以下の例では、MERGE JOINさせていますが、表M1と表M2それぞれのSort作業領域は、Merge Join終了時まで保持されることになるため、最大3GBのSort作業領域が利用されています。（SQLモニターの結果ではわかりにくいのですが。。。）
なお、手動PGA管理、自動PGA管理に関係なく、実行される操作により複数の作業領域が同時に確保されることがあります。
（ちなみに、自動PGA管理で利用されるPGA_AGGREGATE_LIMITがPGA_AGGREGATE_TARGETの2倍とされるのも、このような動きが考慮された結果だと知っていると、納得感はあるかもしれません。）

前回使った図で朱色で示したSQL Work Areaが複数ありますが、Hash/Sort/Bitmap系など複数のタイプおよび同一タイプの作業領域が同時に確保されることも意図した図になっているのは、これが理由なんです。

ORCL@SCOTT> @manual_sortwk2gb2_optimal
  1* alter session set workarea_size_policy = manual

Session altered.

  1* alter session set sort_area_size = 2147483647

Session altered.

  1  SELECT
  2      /*+
  3          MONITOR
  4          USE_MERGE(m1 m2)
  5      */
  6      *
  7  FROM
  8      m1
  9      INNER JOIN m2
 10      ON
 11          m1.id = m2.id
 12          AND m1.rev# = m2.rev#
 13  WHERE
 14*     m1.id <= 'C075000'
old   1: select dbms_sqltune.report_sql_monitor(sql_id=>'&1', type=>'text') from dual
new   1: select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual

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

・・・中略・・・

Global Stats
===========================================================================
| Elapsed |   Cpu   |    IO    |  Other   | Fetch | Buffer | Read | Read  |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls |  Gets  | Reqs | Bytes |
===========================================================================
|      17 |      10 |     4.75 |     2.19 | 50001 |   667K | 5251 |   5GB |
===========================================================================

SQL Plan Monitoring Details (Plan Hash Value=1391069689)
========================================================================================================================================================
| Id |       Operation       | Name |  Rows   | Cost  |   Time    | Start  | Execs |   Rows   | Read | Read  |  Mem  | Activity |   Activity Detail    |
|    |                       |      | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs | Bytes | (Max) |   (%)    |     (# samples)      |
========================================================================================================================================================
|  0 | SELECT STATEMENT      |      |         |       |        23 |    +10 |     1 |     750K |      |       |     . |    14.29 | Cpu (2)              |
|  1 |   MERGE JOIN          |      |    752K |  849K |        23 |    +10 |     1 |     750K |      |       |     . |          |                      |
|  2 |    SORT JOIN          |      |    752K |  439K |        32 |     +1 |     1 |     750K |      |       |   2GB |    21.43 | Cpu (3)              |
|  3 |     TABLE ACCESS FULL | M1   |    752K | 90828 |         8 |     +2 |     1 |     750K | 2633 |   3GB |     . |    35.71 | Cpu (3)              |
|    |                       |      |         |       |           |        |       |          |      |       |       |          | direct path read (2) |
|  4 |    SORT JOIN          |      |    759K |  410K |        23 |    +10 |  750K |     750K |      |       |   1GB |    14.29 | Cpu (2)              |
|  5 |     TABLE ACCESS FULL | M2   |    759K | 90581 |         5 |    +10 |     1 |     750K | 2618 |   3GB |     . |    14.29 | Cpu (2)              |
========================================================================================================================================================

SQLモニターの結果ではわかりにくいわけですが、v$sesstatをから眺めれば状況がよくわかります！
2つのソート作業領域が同時に確保されたことで、2GB + 1GB = 3GB程度のサイズにまで達していることが確認できます。

ORCL@SYSTEM> r
  1  select
  2  	vss.value/1024/1024/1024 "GB"
  3  	,vsn.name
  4  	,vss.sid
  5  from
  6  	v$sesstat vss
  7  	inner join v$statname vsn
  8  	on
  9  		vss.statistic# = vsn.statistic#
 10  		and vss.con_id = vsn.con_id
 11  		and vsn.name like '%pga%'
 12  where
 13  	sid IN (select sid from v$session where username='SCOTT')
 14  order by
 15* 	sid,name

        GB NAME                                                                    SID
---------- ---------------------------------------------------------------- ----------
3.04611414 session pga memory                                                      203
3.04611414 session pga memory max                                                  203

では、次回はやっとw、真打、自動PGA管理下での確認。（引っ張り過ぎかもしれないw）
つづく。

---

・Temp落ち #1 - "Temp落ち" って？
・Temp落ち #2 - PGA (Program Global Area)
・Temp落ち #3 - 手動PGA管理で作業領域として指定可能な最大サイズ

”utl_file I/O” - この症状はあれの可能性が高いですね。

JPOUG Advent Calendar 2017の4日目のエントリーです。

さて、最近あまりお目にかかってなかったUTL_FILEパッケージで表データをcsvに書きだすネタにしました。

先日、UTL_FILEパッケージを利用した処理が想定以上に遅いという相談をうけました。
AWRレポートをみると、上位の待機イベントは、”utl_file I/O"。

！！！！おーーーこれは、珍しいというか、久々にみた病気w

UTL_FILEパッケージを利用したI/Oをグルグルしているとか、でかいファイル読み書きしているかの、どちらかですよねw
ということで、この症状の治療法を考えてみます。

＜参考 - 環境＞

MacBook:˜ system_profiler SPHardwareDataType | grep -E 'Model|Processor|Cores|Memory'
      Model Name: MacBook
      Model Identifier: MacBook9,1
      Processor Name: Intel Core m5
      Processor Speed: 1.2 GHz
      Number of Processors: 1
      Total Number of Cores: 2
      Memory: 8 GB

ホストOS
MacBook:˜ discus$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.13.1
BuildVersion:	17B1003

MacBook:˜ discus$ VBoxManage -version
5.1.30r118389


ゲストOSとOracle Database
orcl@SYS> !uname -a
Linux localhost.localdomain 4.1.12-94.3.6.el7uek.x86_64 #2 SMP Tue May 30 19:25:15 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux

orcl@SYS> !cat /etc/oracle-release
Oracle Linux Server release 7.3

orcl@SYS> 
orcl@SYS> select * from v$version;

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

UTL_FILEでファイル出力する際、ちょっとした手順の漏れが性能差として現れてしまうことがあります。
表の行長は数百バイト程度ですが、行数は数千万〜数億行なんていう状況だと、性能差が顕著に現れてしまうので注意が必要です。

以下の表、セグメントサイズは1GB程度ですが、行数は1千万行以上あります。
この表データをUTL_FILEパッケージを利用してcsvに出力してみます。

ORCL@SCOTT> select segment_name,sum(bytes)/1024/1024/1024 "GB" from user_segments group by segment_name;

SEGMENT_NAME                           GB
------------------------------ ----------
ABOUT_100BYTES_ROWS              .9140625
PK_ABOUT_100BYTES_ROWS            .171875


ORCL@SCOTT> select count(1) from about_100bytes_rows;

  COUNT(1)
----------
  10737420

表の1行は100bytes(改行コード含）です。

ORCL@SCOTT%gt; r
  1  SELECT
  2  	LENGTH(
  3  		TO_CHAR(id,'FM000000000000000000000000000009')
  4  		||','||FOO
  5  	) row_length
  6  FROM
  7  	about_100bytes_rows
  8  WHERE
  9* 	rownum <= 1

ROW_LENGTH
----------
        99

次の2つのコードの赤太文字部分に着目してください。
その部分が異なるだけで処理時間に大きな差が出ます。

DECLARE
	cDIR_NAME CONSTANT VARCHAR2(30) := 'FILES_DIR';
	cFILE_NAME CONSTANT VARCHAR2(128) := 'no_writebuffering_'||TO_CHAR(systimestamp, 'rrmmddhh24miss.ff')||'.txt';
	cBufferSize CONSTANT BINARY_INTEGER := 32767;
	cOpenMode CONSTANT VARCHAR2(2) := 'w';
	fileHandle UTL_FILE.FILE_TYPE;
	
	cBulkReadLimit CONSTANT PLS_INTEGER := 324;
	TYPE tBulkReadArray IS TABLE OF VARCHAR2(8192) INDEX BY BINARY_INTEGER;
	bulkReadArray tBulkReadArray;
	CURSOR cur_about100bytesRow IS
		SELECT
			TO_CHAR(id,'FM000000000000000000000000000009')
			||','||FOO
			AS csvrow
		FROM
			about_100bytes_rows
		;
BEGIN
	OPEN cur_about100bytesRow;
	fileHandle := UTL_FILE.FOPEN(cDIR_NAME, cFILE_NAME, cOpenMode, cBufferSize);
	LOOP
		FETCH cur_about100bytesRow
			BULK COLLECT INTO bulkReadArray
			LIMIT cBulkReadLimit;
		
		EXIT WHEN bulkReadArray.COUNT = 0;
		
		FOR i IN bulkReadArray.FIRST..bulkReadArray.LAST LOOP
			UTL_FILE.PUT_LINE(
				file => fileHandle
				, buffer => bulkReadArray(i)
				, autoflush => true
			);
		END LOOP;
	END LOOP;
	UTL_FILE.FFLUSH(fileHandle);
	UTL_FILE.FCLOSE(fileHandle);
	CLOSE cur_about100bytesRow;
EXCEPTION
	WHEN OTHERS THEN
		IF UTL_FILE.IS_OPEN(fileHandle) THEN
			UTL_FILE.FCLOSE(fileHandle);
		END IF;
		
		IF cur_about100bytesRow%ISOPEN THEN
			CLOSE cur_about100bytesRow;
		END IF;
		RAISE;
END;
/


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

経過: 00:02:27.05

DECLARE
	cDIR_NAME CONSTANT VARCHAR2(30) := 'FILES_DIR';
	cFILE_NAME CONSTANT VARCHAR2(128) := 'writebuffering_'||TO_CHAR(systimestamp, 'rrmmddhh24miss.ff')||'.txt';
	cBufferSize CONSTANT BINARY_INTEGER := 32767;
	cOpenMode CONSTANT VARCHAR2(2) := 'w';
	fileHandle UTL_FILE.FILE_TYPE;
	buffer VARCHAR2(32767);
	
	cBulkReadLimit CONSTANT PLS_INTEGER := 324;
	TYPE tBulkReadArray IS TABLE OF VARCHAR2(8192) INDEX BY BINARY_INTEGER;
	bulkReadArray tBulkReadArray;
	CURSOR cur_about100bytesRow IS
		SELECT
			TO_CHAR(id,'FM000000000000000000000000000009')
			||','||FOO
			AS csvrow
		FROM
			about_100bytes_rows
		;
BEGIN
	OPEN cur_about100bytesRow;
	fileHandle := UTL_FILE.FOPEN(cDIR_NAME, cFILE_NAME, cOpenMode, cBufferSize);
	LOOP
		FETCH cur_about100bytesRow
			BULK COLLECT INTO bulkReadArray
			LIMIT cBulkReadLimit;
		
		EXIT WHEN bulkReadArray.COUNT = 0;
	
		buffer := NULL;	
		FOR i IN bulkReadArray.FIRST..bulkReadArray.LAST LOOP
			buffer := buffer || bulkReadArray(i) || UTL_TCP.CRLF;   
 		END LOOP;
		UTL_FILE.PUT(fileHandle, buffer);
		UTL_FILE.FFLUSH(fileHandle);
	END LOOP;
	UTL_FILE.FFLUSH(fileHandle);
	UTL_FILE.FCLOSE(fileHandle);
	CLOSE cur_about100bytesRow;
EXCEPTION
	WHEN OTHERS THEN
		IF UTL_FILE.IS_OPEN(fileHandle) THEN
			UTL_FILE.FCLOSE(fileHandle);
		END IF;
		
		IF cur_about100bytesRow%ISOPEN THEN
			CLOSE cur_about100bytesRow;
		END IF;
		RAISE;
END;
/


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

経過: 00:00:43.96

何が違うかお分ですよね！
UTL_FILE.PUT_LINE/UTL_FILE.PUTが違う！！w
その部分は重要ではなく、100Bytes単位に書き込んでいるか、約32KB単位で書き込んでいるかが重要なんです。

UTL_FILEは最大32767バイトのバッファを利用できますが、前者はバッファを有効利用せず、100Bytes毎に書き出しています。後者は約32KB単位で書き出しています。

その差はAWRレポートからも見えてきます。

AWRレポート（一部抜粋）
UTL_FILEパッケージによるI/Oの待機は、”utl_file I/O”という待機イベントで現れます。

Avg Waitは短いですが、理由は100バイト単位の小さいなサイズの書き込みを繰り返しているわけなので、そんなとこでしょう。

Top 10 Foreground Events by Total Wait Time

                                           Total Wait       Avg   % DB Wait
Event                                Waits Time (sec)      Wait   time Class
------------------------------ ----------- ---------- --------- ------ --------
DB CPU                                          147.4             99.3
utl_file I/O                    32,212,266       49.5    1.54us   33.3 User I/O
direct path read                     1,881        1.2  620.61us     .8 User I/O
resmgr:cpu quantum                       1         .1   85.85ms     .1 Schedule
db file sequential read                 17          0     .98ms     .0 User I/O
PGA memory operation                    90          0   35.13us     .0 Other
latch: shared pool                       1          0    1.05ms     .0 Concurre
control file sequential read            80          0   12.83us     .0 System I
Disk file operations I/O                 6          0   73.67us     .0 User I/O
SQL*Net message to client                2          0    9.00us     .0 Network

一方、約32KB単位でバッファリングして書き出している場合、Waits回数が激減しています。
Avg Waitsは大きくなっていますが、書き出しサイズにほぼ比例しているので想定通りというところ。

Top 10 Foreground Events by Total Wait Time

                                           Total Wait       Avg   % DB Wait
Event                                Waits Time (sec)      Wait   time Class
------------------------------ ----------- ---------- --------- ------ --------
DB CPU                                             45             98.5
utl_file I/O                        66,288       27.4  413.54us   60.1 User I/O
direct path read                     1,881          1  550.71us    2.3 User I/O
db file sequential read                 88          0  443.38us     .1 User I/O
direct path write                        2          0    4.69ms     .0 User I/O
control file sequential read            80          0   33.25us     .0 System I
latch: shared pool                       1          0    2.38ms     .0 Concurre
Disk file operations I/O                 4          0  323.50us     .0 User I/O
PGA memory operation                    79          0   15.73us     .0 Other
SQL*Net message to client                4          0   20.25us     .0 Network

utl_file.put/put_lineでcsvを出力しているdeviceのiostat(util%)
まだまだ余裕があるのでI/Oで詰まっているのではなく、UTL_FILE.PUT/PUT_LINEの使い方の影響が大きいということですね。

最後に、
UTL_FILEパッケージの入出力時にはバッファの有効利用をお忘れなく。(つい忘れちゃうこともあるので、急いでるときとかw）
扱うデータが多い場合は得に。

そして、みなさま、
メリークリスマス（まだエントリーを書くかもしれませんがw）
#JPOUG

DBMS_ADVISOR.CREATE_FILE()プロシージャは、Diagnostic/Tuning Pack不要らしいということの確認

Previously on Mac De Oracle

---

余談

DBMS_ADVISOR.CREATE_FILEとなっているがライセンス上、diagnostic/tuning packライセンスはなくてもアクセスしてできるように読み取れるのだけと、もしかすると、この影響で、DBMS_ADVISOR.CREATE_FILEの存在は知っていても使ってないのかあるのかな？？

以下のマニュアルを読む限り、Diagnostic/Tuning Packでは、DBMS_ADVISORパッケージ全体ではなく、Diagnostic/Tuning Packに関連するパラメータを与える必要のある機能についての制限であることしか記載されていない。
つまり、DBMS_ADVISOR.CREATE_FILE()に関して言えば、Diagnostic/Tuning Pack特有の機能ではないから利用可能なはず。　←間違ってたらツッコミ希望w

Oracle® Databaseライセンス情報 12cリリース1 (12.1) 2 オプションおよびパック
https://docs.oracle.com/cd/E49329_01/license.121/b71334/options.htm

---

なんてことを書いたところ、

control_management_pack_access=none

でも使えるとなら間違いなくないんじゃないの？
というコメントがあったので試してみました。　マニュアルの通りだと思われます。ということですね。FAQ!

orcl@SYS> show parameter control_management_pack_access

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_management_pack_access        string     NONE
orcl@SYS> 
orcl@SYS> l
1 DECLARE
2     reportClob CLOB := EMPTY_CLOB();
3 BEGIN
4     reportClob := 'test test test';
5     DBMS_ADVISOR.CREATE_FILE(
6     buffer => reportClob
7     ,location => 'REP_DIR'
8     ,filename => 'test.txt'
9 );
10* END;
orcl@SYS> /

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

経過: 00:00:00.23
orcl@SYS> !ls report 
test.txt

orcl@SYS> !cat report/test.txt
test test test

---

・DBMS_SQLTUNE.PACK_STGTAB_SQLSETって、例外投げんのかよw
・SQL Tuning Setのキャプチャから退避までのスクリプト（やっつけ）
・SQL Tuning Set (STS)のフィルタリング
・DBMS_SQLTUNE.REPORT_ANALYSIS_TASK()ファンクションで生成されるCLOB型のレポートをファイルに保存する簡単な方法

DBMS_SQLTUNE.REPORT_ANALYSIS_TASK()ファンクションで生成されるCLOB型のレポートをファイルに保存する簡単な方法

Previously on Mac De Oracle
STSとの格闘というかSPAとの格闘に疲れてきたところw ですが、
SQL Tuning Set (STS)のフィルタリング
などで、SQLSETを程よい大きさに分割するところまでたどり着きましたw

今回は、いくつかある細かい分析方法については、一旦、置いといて、
分析レポートを保存する簡単な方法についての備忘録

分析などにこの記事も参考になると思いますが、紹介している記事でも分析レポートをファイルに保存する方法はSQL*Plusのコマンドを駆使して行われています。
個人的には少々やぼったい方法かなと感じている方法なんですが、以前はこんなやりかたが多かったようにも思います。

var rep CLOB
...略...
EXEC :rep := DBMS_SQLSPA.REPORT_ANALYSIS_TASK('STSNAM','TEXT',...
spo hoge_report.txt
print :rep
spo off

SQL*PlusとPL/SQLが行ったり来たりするところや、ループ制御しにくいので、この方法は避けたい。。。。

かといって、DBMS_OUTPUT.PUT_LINEで行おうとするとset linesize等の制御が面倒くさいし
結局、SQL*Plusの機能にも依存してしまうので、いまひとつ。

PL/SQLだけで行う方法として、UTL_FILEパッケージを利用してファイル出力する方法もありますが、
UTL_FILEパッケージで提供されているAPIはlow levelなものばかりなので、急ぎの時にはめんどくさくて、やだw

もっと簡単なやつないの？？？？？

あります！w

DBMS_ADVISOR.CREATE_FILE(buffer, location, filename)

なぜ、UTL_FILEパッケージに入れてくれないんだw と思いたくなる方もいるかと思いますが、 理由はよくわかりませんw
（UTL_FILEパッケージはlow levelなAPIだけだから入れたくないのかも、かも、かも。と思ってますが、DBMS_ADVISORパッケージに入れるとは。どういうつもりだ！w）

UTL_FILE.CREATE_FILE()ってあったほうが直感的に探しやすくないかw UTL_FILEみて無い！！
となると、他を探すこともあまりなくなって、結局、コード書いてる場面を多く見てる＞＜　

---

余談

DBMS_ADVISOR.CREATE_FILEとなっているがライセンス上、diagnostic/tuning packライセンスはなくてもアクセスしてできるように読み取れるのだけと、もしかすると、この影響で、DBMS_ADVISOR.CREATE_FILEの存在は知っていても使ってないのかあるのかな？？

以下のマニュアルを読む限り、Diagnostic/Tuning Packでは、DBMS_ADVISORパッケージ全体ではなく、Diagnostic/Tuning Packに関連するパラメータを与える必要のある機能についての制限であることしか記載されていない。
つまり、DBMS_ADVISOR.CREATE_FILE()に関して言えば、Diagnostic/Tuning Pack特有の機能ではないから利用可能なはず。　←間違ってたらツッコミ希望w

Oracle® Databaseライセンス情報 12cリリース1 (12.1) 2 オプションおよびパック
https://docs.oracle.com/cd/E49329_01/license.121/b71334/options.htm

---

とりあえず、SQLSETの分析レポートをDBMS_ADVISOR.CREATE_FILE()を利用して保存するやっつけスクリプトを作ってみました
これを元に育てていけるかなw

実行例）

注）STS20171102というSQLSETを事前に作成してあります。

orcl@SYS> select * from v$version;

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


orcl@SYS> select owner,name,statement_count,created from dba_sqlset order by name;

OWNER      NAME                           STATEMENT_COUNT CREATED
---------- ------------------------------ --------------- ---------
SPAUSER    STS20171102                               1003 02-NOV-17

spa.sqlのパラメータは、SQLSETと分析レポートの出力ディレクトリオブジェクトとSQLを実行するスキーマ向けのDBリンクです。

スクリプトの概要
・初回の分析（SQLSETで元のSQLを分析）
・２回目の分析（新環境でSQLを実行して分析)
・初回と２回目の比較レポート作成／保存
・レポートを出力後、分析に利用したタスクを削除

orcl@SYS> @spa STS20171102 rep_dir link_4_target

task name:STS20171102 has been droped.
***END***

PL/SQL procedure successfully completed.

分析レポートは、ディレクトリオブジェクトに対応づけられたパスに保存されます

orcl@SYS> !ls -l report
-rw-r--r-- 1 oracle oinstall 13688 11月  3 02:44 DIFF_STS20171102171103024433.txt

orcl@SYS> !cat report/DIFF_STS20171102171103024433.txt

General Information
---------------------------------------------------------------------------------------------

 Task Information:                              Workload Information:                         
 ---------------------------------------------  --------------------------------------------- 
  Task Name    : STS20171102                     SQL Tuning Set Name        : STS20171102     
  Task Owner   : SYS                             SQL Tuning Set Owner       : SPAUSER         
  Description  :                                 Total SQL Statement Count  : 1003            

Execution Information:
---------------------------------------------------------------------------------------------
  Execution Name             : DIFF_STS20171102       Started             : 11/03/2017 02:44:26  
  Execution Type             : COMPARE PERFORMANCE    Last Updated        : 11/03/2017 02:44:29  
  Description                :                        Global Time Limit   : UNLIMITED            
  Scope                      : COMPREHENSIVE          Per-SQL Time Limit  : UNUSED               
  Status                     : COMPLETED              Number of Errors    : 0                    
  Number of Unsupported SQL  : 4                                                                 

Analysis Information:
---------------------------------------------------------------------------------------------
 Before Change Execution:                       After Change Execution:                       
 ---------------------------------------------  --------------------------------------------- 
  Execution Name      : SOURCE_STS20171102       Execution Name      : TARGET_STS20171102     
  Execution Type      : CONVERT SQLSET           Execution Type      : TEST EXECUTE REMOTE    
  Scope               : COMPREHENSIVE            Database Link       : LINK_4_TARGET          
  Status              : COMPLETED                Scope               : COMPREHENSIVE          
  Started             : 11/03/2017 02:44:04      Status              : COMPLETED              
  Last Updated        : 11/03/2017 02:44:04      Started             : 11/03/2017 02:44:04    
  Global Time Limit   : UNLIMITED                Last Updated        : 11/03/2017 02:44:18    
  Per-SQL Time Limit  : UNUSED                   Global Time Limit   : UNLIMITED              
                                                 Per-SQL Time Limit  : UNUSED                 
                                                 Number of Errors    : 0                      
                                                                                              
 ---------------------------------------------                                                
 Comparison Metric: ELAPSED_TIME                                                              
 ------------------                                                                           
 Workload Impact Threshold: 1%                                                                
 --------------------------                                                                   
 SQL Impact Threshold: 1%                                                                     
 ----------------------                                                                       

Report Summary
---------------------------------------------------------------------------------------------

Projected Workload Change Impact:
-------------------------------------------
 Overall Impact      :  0% 
 Improvement Impact  :  0% 
 Regression Impact   :  0% 

SQL Statement Count
-------------------------------------------
 SQL Category  SQL Count  Plan Change Count 
 Overall             999                490 
 Unchanged           995                490 
 Unsupported           4                  0 

Top 100 SQL Sorted by Absolute Value of Change Impact on the Workload
---------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
|           |               | Impact on | Execution | Metric | Metric | Impact | Plan   |
| object_id | sql_id        | Workload  | Frequency | Before | After  | on SQL | Change |
-----------------------------------------------------------------------------------------
|      1477 | 7hys3h7ysgf9m |       .1% |         1 |  14630 |     33 | 99.77% | n      |
|      1811 | cw6vxf0kbz3v1 |      .03% |         1 |   3602 |     24 | 99.33% | n      |
|      1175 | 2s9mmb6g8kbqb |      .01% |         1 |   1537 |     20 |  98.7% | n      |

...中略...

|      1691 | az25yp5qunj77 |      .01% |         1 |    882 |     20 | 97.73% | n      |
|      1896 | faun6bjrjqr17 |      .01% |         1 |    881 |     19 | 97.84% | n      |
|      1956 | g7a2tmw1nrxbh |      .01% |         1 |    881 |     19 | 97.84% | n      |
-----------------------------------------------------------------------------------------
Note: time statistics are displayed in microseconds
---------------------------------------------------------------------------------------------


---------------------------------------------------------------------------------------------

スクリプトは以下のとおり、無名PL/SQLブロックにしてあります。
レポートのタイプなどは固定にしてますが、それらも含めてパラメータにしてもいいかも。

ちなみに、このエントリの本題である、DBMS_ADVISOR.CREATE_FILE()は赤字部分です！

orcl@SYS> !cat spa.sql

set serveroutput on
DECLARE
	report_clob CLOB;
	cSQLSET_OWNER VARCHAR2(30) := 'SPAUSER';
	cSQLSET_NAME VARCHAR2(20) := UPPER('&1');
	cEXECUTION_NAME_PREFIX_SOURCE VARCHAR2(7) := 'SOURCE_';
	cEXECUTION_NAME_PREFIX_TARGET VARCHAR2(7) := 'TARGET_';
	cEXECUTION_NAME_PREFIX_DIFF   VARCHAR2(5) := 'DIFF_';
	cREPORT_TYPE CONSTANT VARCHAR2(4) := 'text';
	cFILE_EXTENTION CONSTANT VARCHAR2(5) := '.txt';
	cDIRECTORY_NAME CONSTANT VARCHAR2(30) := UPPER('&2');
	cDB_LINK_4_PARSING_SCHEMA CONSTANT VARCHAR2(128) := UPPER('&3');
	stmt_task VARCHAR2(64);

	PROCEDURE drop_task (iTASK_NAME VARCHAR2)
	IS
	BEGIN
        	FOR task_rec IN (
                	SELECT
                        	task_name
                	FROM
                        	dba_advisor_tasks
                	WHERE
                        	task_name = iTASK_NAME
                        	AND advisor_name = 'SQL Performance Analyzer'
        	) LOOP
                	DBMS_OUTPUT.PUT_LINE(
				'task name:'||task_rec.task_name||' has been droped.'
			);
                	DBMS_SQLPA.DROP_ANALYSIS_TASK(
            			task_name => task_rec.task_name
                	);
        	END LOOP;
	END drop_task;
BEGIN
	--Create analysis task
	stmt_task := DBMS_SQLPA.CREATE_ANALYSIS_TASK(
		sqlset_name => cSQLSET_NAME
		,basic_filter => 'parsing_schema_name in (''SCOTT'')'
		,sqlset_owner => cSQLSET_OWNER
		,task_name => cSQLSET_NAME
	);

	--SQL Analysis on Source DB
	DBMS_SQLPA.EXECUTE_ANALYSIS_TASK(
		task_name => cSQLSET_NAME
		,execution_type => 'CONVERT SQLSET'
		,execution_name => 
			cEXECUTION_NAME_PREFIX_SOURCE
			|| cSQLSET_NAME
		,execution_params => 
			DBMS_ADVISOR.ARGLIST(
				'sqlset_name', cSQLSET_NAME
				,'sqlset_owner', cSQLSET_OWNER
		)
	);

	--SQL Analysis on Target DB
	DBMS_SQLPA.EXECUTE_ANALYSIS_TASK(
		task_name => cSQLSET_NAME
		,execution_type => 'EXECUTE'
		,execution_name => 
			cEXECUTION_NAME_PREFIX_TARGET
			|| cSQLSET_NAME
		,execution_params =>
			DBMS_ADVISOR.ARGLIST(
				'DATABASE_LINK', cDB_LINK_4_PARSING_SCHEMA	
				,'EXECUTE_FULLDML', 'TRUE'
			)
	);

	--Comparison Source and Target Analysys 
	DBMS_SQLPA.EXECUTE_ANALYSIS_TASK(
		task_name => cSQLSET_NAME
		,execution_type => 'COMPARE'
		,execution_name => 
			cEXECUTION_NAME_PREFIX_DIFF
			|| cSQLSET_NAME
		,execution_params =>
			DBMS_ADVISOR.ARGLIST(
				'PLAN_LINES_COMPARISON','ALWAYS'
			)
	);

	--Make comparison report
	report_clob := DBMS_SQLPA.REPORT_ANALYSIS_TASK(
		task_name => cSQLSET_NAME
		,execution_name => 
			cEXECUTION_NAME_PREFIX_DIFF
			|| cSQLSET_NAME
		,type => cREPORT_TYPE
		,level => 'typical'
		,section => 'summary'
	);

	--Save comparison report
	DBMS_ADVISOR.CREATE_FILE(
		buffer => report_clob
		,location => cDIRECTORY_NAME
		,filename => 
			cEXECUTION_NAME_PREFIX_DIFF
			||cSQLSET_NAME
			||TO_CHAR(systimestamp, 'RRMMDDHH24MISS')
			||cFILE_EXTENTION
	);

	--Drop Task
	drop_task(cSQLSET_NAME);
	DBMS_OUTPUT.PUT_LINE('***END***');
EXCEPTION
	WHEN OTHERS THEN
		drop_task(cSQLSET_NAME);
		RAISE;
END;
/

---

・DBMS_SQLTUNE.PACK_STGTAB_SQLSETって、例外投げんのかよw
・SQL Tuning Setのキャプチャから退避までのスクリプト（やっつけ）
・SQL Tuning Set (STS)のフィルタリング

SQL Tuning Set (STS)のフィルタリング

Previously on Mac De Oracle
前回は、やっつけすくりぷとを書いたところまででした。

ということで、今回のやっつけスクリプトの準備というかアイデア

SQLSET大量のSQL文キャプチャされていて、SQLSETにキャプチャされている大量のSQL文を一括でSPAでまわしたりすることが辛い場合があります。
そんなときはどうすればよいか。。なやみますよね。。。ほんと。。
SQL Performance AnalyzerによるSQLパフォーマンス比較実行例(API)

SQLSETから、より細かなSQLSETにほぼ当分に分割し、新たなSQLSETを作成したいような場合もあるかもしれません。
そんな時はどうするか？

手取りばやくやるなら、ORA_HASH()が便利ですよね。（SQLSETの全表走査はさけられないのですが、Exaならw）

たとえば、以下のSQLSETがあったとして、300件程度に均等に分割したいという場合。
ora_hash()のバケット数はだいたい12ぐらいでできそうですね。

orcl@SYS> select name,statement_count,created from dba_sqlset order by name;

NAME                           STATEMENT_COUNT CREATED
------------------------------ --------------- ---------
STS20171029                               3819 29-OCT-17

orcl@SYS> select statement_count/300 from dba_sqlset where name='STS20171029';

STATEMENT_COUNT/300
-------------------
              12.73

いい感じに分割できそうです。

orcl@SYS> r
  1  select
  2    ora_hash(sql_id,12) as hash#
  3   ,count(sql_id)
  4  from
  5    table(dbms_sqltune.select_sqlset(
  6      sqlset_name=>'STS20171029'
  7     ,basic_filter=>null
  8    ))
  9  group by
 10    ora_hash(sql_id,12)
 11* order by 1

     HASH# COUNT(SQL_ID)
---------- -------------
         0           289
         1           293
         2           278
         3           296
         4           297
         5           281
         6           282
         7           298
         8           288
         9           304
        10           305
        11           298
        12           310

13 rows selected.

実際に利用するには、basic_filterでwhere句の条件文そのものを書いてあげます。サブクエリも書けますが、データ量が多い場合は性能面に注意しながらいろいろ試してみるといいと思います。
basic_filterでは、SQLSET_ROWオブジェクト・タイプの属性を利用したフィルタリングができるのですが、インジェクションですよね。構文を見ている限り;)
Oracle® Database PL/SQLパッケージおよびタイプ・リファレンス 12c リリース1 (12.1) SQLSET_ROWオブジェクト・タイプ

orcl@SYS> set serveroutput on
orcl@SYS> r
  1  begin
  2    for i in 0..12 loop
  3      for sqlset_rec in
  4      (
  5        select count(sql_id) as num_sql
  6        from
  7          table(dbms_sqltune.select_sqlset(
  8            sqlset_name=>'STS20171029'
  9           ,basic_filter=>'ora_hash(sql_id,12)='||i
 10          ))
 11      )
 12      loop
 13        dbms_output.put_line('hash#='||to_char(i,'fm99')||':'||sqlset_rec.num_sql);
 14      end loop;
 15    end loop;
 16* end;
hash#=0:289
hash#=1:293
hash#=2:278
hash#=3:296
hash#=4:297
hash#=5:281
hash#=6:282
hash#=7:298
hash#=8:288
hash#=9:304
hash#=10:305
hash#=11:298
hash#=12:310

PL/SQL procedure successfully completed.

ハッシュ値10でsql_id数をカウント！
うまくできそうですよね。

orcl@SYS> r
  1  select
  2    count(sql_id)
  3  from
  4    table(dbms_sqltune.select_sqlset(
  5      sqlset_name=>'STS20171029'
  6     ,basic_filter=>'ora_hash(sql_id,12) = 10'
  7*   ))

COUNT(SQL_ID)
-------------
          305

参考
Oracle® Database PL/SQLパッケージおよびタイプ・リファレンス　12c リリース1 (12.1) DBMS_SQLTUNE
Oracle® Database SQL言語リファレンス 12cリリース1 (12.1) ORA_HASH

---

・DBMS_SQLTUNE.PACK_STGTAB_SQLSETって、例外投げんのかよw
・SQL Tuning Setのキャプチャから退避までのスクリプト（やっつけ）

DBMS_SQLTUNE.PACK_STGTAB_SQLSETって、例外投げんのかよw

ということで、タイトル通り
マニュアル上、例外を投げるとは記載されてないのですが、テストしてたら”例外投げる”PL/SQLプロシージャ、意外と多いんですw
意図的に例外投げるよーというのは大抵マニュアルに記載されているんですが。人が書いてますからね、記載漏れも仕方ないっすねぇw　

マニュアルバグ、忘れちゃうので、自分向けFAQ and 備忘録　

Oracle® Database PL/SQLパッケージおよびタイプ・リファレンス　12c リリース1 (12.1)　B71281-05
DBMS_SQLTUNE.PACK_STGTAB_SQLSETプロシージャ

Oracle Database PL/SQL Packages and Types Reference (12.2)のマニュアルには DBMS_SQLTUNE.PACK_STGTAB_SQLSET Procedure は例外を投げるよ！という記載はないが...

DBMS_SQLTUNE.PACK_STGTAB_SQLSET Procedure
DBMS_SQLTUNE.PACK_STGTAB_SQLSET Procedure

orcl@SYS> r
  1  SELECT
  2    ID
  3    ,NAME
  4    ,OWNER
  5    ,CREATED
  6    ,LAST_MODIFIED
  7    ,STATEMENT_COUNT
  8  FROM
  9  	dba_sqlset
 10  ORDER BY
 11  	OWNER
 12  	,CREATED
 13*


        ID NAME                           OWNER                          CREATED   LAST_MODI STATEMENT_COUNT
---------- ------------------------------ ------------------------------ --------- --------- ---------------
         1 STS201710052340431             SYS                            05-OCT-17 05-OCT-17               0
         2 STS201710061431151             SYS                            06-OCT-17 06-OCT-17               2

statement_count=0と2の2つのSTS(SQL Tuning Set)があります。
STS(SQL Tuning Set)については、ここでは記載しませんが、何それ？　気になる、気になる〜という方は、
Oracle Database の STS(SQL Tuning Set) を活用して、SQL の 性能統計 や 実行計画 を キャプチャする。を覗いて見てください。

（次回のネタは思いっきりそこなので、予習にもなりますよ :）

例外を投げるとはマニュアルに記載されてないプロシージャが実は例外投げるじゃん！　
というケースは、dbms_sqltune.pack_stgtab_sqlset以外にもあるんですが、
急ぎのやっつけ仕事で遭遇すると、ここで見つかってよかった！！
という安堵感とともに、
ムカ〜〜〜〜っという憎悪も湧いてくるわけですw　
（何れにしてもテストはしっかりやりましょうw

以下、例外投げるとは書かれてないけど、投げるじゃん、dbms_sqltune.pack_stgtab_sqlset　の簡易テストの記録

準備として、dbms_sqltune.pack_stgtab_sqlsetは、STSを退避する為に必要なステージング表を作成します。

orcl@SYS> exec dbms_sqltune.create_stgtab_sqlset(table_name=>'TEST',schema_name=>'STSUSR');

PL/SQL procedure successfully completed.

statement_count=0つまり、STSに記録されたSQLの情報がない場合です。
ワーニングとしての意味が強いと思われますが、ORA-15701が投げつけられて、STSが空だということを教えてくれます！ :)
マニュアルには記載されてなかったので焦りますw　実際のところざっくり書いたコードではこの例外をハンドリングなんてしてませんでした。

orcl@SYS> l
  1  begin
  2    dbms_sqltune.pack_stgtab_sqlset(
  3      sqlset_name=>'STS201710052340431'
  4     ,sqlset_owner=>null
  5     ,staging_table_name=>'TEST'
  6     ,staging_schema_owner=>'STSUSR'
  7    );
  8* end;
orcl@SYS> /
begin
*
ERROR at line 1:
ORA-15701: All "SQL Tuning Set(s)" with name like "STS201710052340431" and owner like "SYS" are empty
ORA-06512: at "SYS.DBMS_SQLTUNE", line 5398
ORA-06512: at "SYS.DBMS_SQLTUNE", line 7928
ORA-06512: at line 2

一方、statement_count=2でSTSに記録されたSQLがある場合、つまり、STSは空じゃない場合は正常終了します。

orcl@SYS> l
  1  begin
  2    dbms_sqltune.pack_stgtab_sqlset(
  3      sqlset_name=>'STS201710061431151'
  4     ,sqlset_owner=>null
  5     ,staging_table_name=>'TEST'
  6     ,staging_schema_owner=>'STSUSR'
  7    );
  8* end;
orcl@SYS> /

PL/SQL procedure successfully completed.

STSが空だという例外を拾って、後続処理にあるであろう、ステージング表のエクスポートとかをバイパスしたりすることはできますね:)

dbms_sqltune.pack_stgtab_sqlsetは、STSが空だと例外投げるよ　というお話でした。

To be continued...

SQLとPL/SQLで「モルダー、あなた疲れてるのよ」を出力する方法

もうかれこれ1年以上経過しているので、何を今更という感じがしないでもないですがw

ここ２週間くらい、SQLチューニングじゃない方向で、非常に忙しかったこともあり

気分的に疲れてしまったので、気分転換のために作ってみました。

Ruby でモルダー、あなた疲れてるのよを出力する方法

Pythonでモルダー案件

Groovyで「モルダー、あなた疲れてるのよ」に対処する

と、どう見てもPL/SQLやSQL案件ではないネタですが、PL/SQL de Python Challenge精神（どんな精神じゃw)で無理やり案件化して見ました。

疲れてる時に疲れるネタやるの？、バカなの？　
とお感じの方もお多いかと存じますが、可能ならもっと変態的なネタに発展することを願いつつ、ご挨拶と代えさせていただきます

データベースエンジニアでも、「モルダー、あなた疲れてるよの」をという文字列を出力させる無茶振り案件に突っ込まれるかもしれません。
そんなときの参考になれば幸いです。

スペースで区切ったワードをシャッフルし、「モルダー、あなた疲れてるのよ」が出力されたら終了です。

色々な「モルダー、あなた疲れてるのよ」がありますので、よろしくお願いします！

Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
に接続されました。
orcl@SYSTEM> @mulder_you_tired

スカリーより
--------------------------------------------------------------------------------
1: 疲れてる、あなたのよモルダー
2: のよ、あなたモルダー疲れてる
3: モルダー、疲れてるあなたのよ
4: 疲れてる、あなたモルダーのよ
5: モルダー、あなたのよ疲れてる
6: のよ、あなたモルダー疲れてる
7: 疲れてる、モルダーあなたのよ
8: モルダー、のよ疲れてるあなた
9: のよ、疲れてるモルダーあなた
10: 疲れてる、のよモルダーあなた
11: モルダー、あなたのよ疲れてる
12: のよ、疲れてるあなたモルダー
13: モルダー、のよあなた疲れてる
14: 疲れてる、あなたのよモルダー
15: 疲れてる、あなたモルダーのよ
16: モルダー、あなたのよ疲れてる
17: のよ、あなたモルダー疲れてる
18: モルダー、あなた疲れてるのよ

コードは以下のとおり、WITH FUNCTIONで文字列を生成しCLOBで１行で返しています。
改行コード(UTL_TCP.CRLFを利用、UTL_TCPパッケージなんて使っている人は少ないと思いますがw）を付加し出力時に改行させ複数行に見せています。
WITH FUNCTIONをSELECT文のセレクトリスト部分で利用しています。(TABLE FunctionならFROM句で使えますが、TABLE Functionではないので）

09:54:34 orcl@SYSTEM> !cat mulder_you_tired.sql
set long 100000
set pagesize 10000
WITH function mulderYouAreTired (dummy char)
RETURN CLOB
IS
  cMulderYouTired CONSTANT VARCHAR2(42) := 'モルダー、あなた疲れてるのよ';
  vMessage VARCHAR2(42);
  vMessageFromScully CLOB := EMPTY_CLOB(); 
  line# BINARY_INTEGER := 1;
  --
  FUNCTION generateMessage
  RETURN VARCHAR2
  IS
    TYPE word_arr IS TABLE OF VARCHAR2(12) INDEX BY BINARY_INTEGER;
    cPunctuation CONSTANT CHAR(3) := '、';
    vWords VARCHAR2(45) := 'モルダー あなた 疲れてる のよ';
    vMessageFromScully VARCHAR2(42);
    vMessage word_arr;
    vWord VARCHAR2(13);
    isSetWord BOOLEAN := FALSE;
    idx BINARY_INTEGER := 1;
  BEGIN
    --
    FOR i IN 1..REGEXP_COUNT(vWords, ' ') + 1 LOOP
      vMessage(i) := NULL;
    END LOOP;
    --
    WHILE INSTR(vWords, ' ') != 0 LOOP
      vWord := SUBSTR(vWords, 1, INSTR(vWords, ' '));
      vWords := REPLACE(vWords, vWord);
      isSetWord := FALSE;
      WHILE NOT isSetWord LOOP
        idx := TRUNC(DBMS_RANDOM.VALUE(vMessage.FIRST, vMessage.LAST + 1));
        IF vMessage(idx) IS NULL THEN
          vMessage(idx) := TRIM(vWord);
          isSetWord := TRUE;
        END IF;
      END LOOP;
    END LOOP;
    --
    FOR j IN vMessage.FIRST..vMessage.LAST LOOP
      IF vMessage(j) IS NULL THEN
        vMessage(j) := vWords;
      END IF;
    END LOOP;
    --
    FOR x IN vMessage.FIRST..vMessage.LAST LOOP
      IF x = 2 THEN 
        vMessageFromScully := vMessageFromScully || cPunctuation;
      END IF;
      vMessageFromScully := vMessageFromScully || vMessage(x);
    END LOOP;
    RETURN vMessageFromScully;
  END generateMessage;
BEGIN
  LOOP
    vMessage := generateMessage();
    vMessageFromScully := 
      vMessageFromScully || TO_CHAR(line#) 
      || ': ' || vMessage || UTL_TCP.CRLF;
    line# := line# + 1;
    EXIT WHEN vMessage = cMulderYouTired;
  END LOOP;
  RETURN vMessageFromScully;
END;
SELECT
  mulderYouAreTired(null) AS "スカリーより"
FROM
  dual;
/

WITH clause in-line PL/SQL functionって....

12cの新機能でオイタをしてみたw

with句に関数仕込んで内部でSQL文を実行してオイタしてみました。

実際にこのような使い方するんでしょうか？
これをやるなら素直にスカラー副問合せの方がいいと思うんですね.....
（スカラー副問合せのように使われたら、同じく12cの新機能、Scalar subquery unnestingもできなし。）

なんでこんな機能必要なんだろう?
どのような場面で、有効なんだろう？

今の所、使いどころが思い浮かばないので、誰か教えて〜〜〜〜〜！　
とモヤモヤしてたんですが、今日はお留守番で時間だけはあったので、ごにょごにょとw

SCOTT> set serveroutput on
SCOTT> set feed off
SCOTT> r
  1   with
  2   	function hoge return varchar2
  3  	deterministic
  4   	as
  5   	begin
  6  		for rec in (select empno,ename from emp order by empno) loop
  7   			dbms_output.put_line('**** '||rec.empno||':'||rec.ename||' ****');
  8  		end loop;
  9  		return null;
 10   	end;
 11   select
 12   	hoge
 13   from
 14   	dual
 15   where
 16* 	hoge is not null

**** 7369:SMITH ****
**** 7499:ALLEN ****
**** 7521:WARD ****
**** 7566:JONES ****
**** 7654:MARTIN ****
**** 7698:BLAKE ****
**** 7782:CLARK ****
**** 7839:KING ****
**** 7844:TURNER ****
**** 7900:JAMES ****
**** 7902:FORD ****
**** 7934:MILLER ****

経過: 00:00:00.01

こんなことをやられると....
実行計画には現れないしw　（ちなみにスカラー副問合せは実行計画を見ただけでわかりますです。はい）

ただのチューナーいじめじゃ >< w
SQLトレースなら補足できるけど、なんぎじゃのう。げほげほ

(WITH句のインラインPL/SQLファンクション（名称あってるのかな？）内部でSQL文は実行しない方がいいと思うけど。。。。？？？)

SCOTT> 
SCOTT> set autot trace exp stat
SCOTT> r
  1   with
  2   	function hoge return varchar2
  3  	deterministic
  4   	as
  5   	begin
  6  		for rec in (select empno,ename from emp order by empno) loop
  7   			dbms_output.put_line('**** '||rec.empno||':'||rec.ename||' ****');
  8  		end loop;
  9  		return null;
 10   	end;
 11   select
 12   	hoge
 13   from
 14   	dual
 15   where
 16* 	hoge is not null

**** 7369:SMITH ****
**** 7499:ALLEN ****
**** 7521:WARD ****
**** 7566:JONES ****
**** 7654:MARTIN ****
**** 7698:BLAKE ****
**** 7782:CLARK ****
**** 7839:KING ****
**** 7844:TURNER ****
**** 7900:JAMES ****
**** 7902:FORD ****
**** 7934:MILLER ****

経過: 00:00:00.03

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

-----------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Cost (%CPU)| Time     |
-----------------------------------------------------------------
|   0 | SELECT STATEMENT |      |     1 |     2   (0)| 00:00:01 |
|*  1 |  FILTER          |      |       |            |          |
|   2 |   FAST DUAL      |      |     1 |     2   (0)| 00:00:01 |
-----------------------------------------------------------------

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

   1 - filter("HOGE"() IS NOT NULL)


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

WITH句のインラインPL/SQLファンクション内でのSQL文の実行はダークサイドな香りしかしないので、使うならデータの加工等、計算中心目的かねぇ〜。とマニュアル読んでたら見つけたw
　
(マニュアルのサンプルも加工のみ！ )

SCOTT> r
  1   with
  2   	function hoge(eno number) return varchar2
  3  	deterministic
  4   	as
  5   	begin
  6  		dbms_output.put_line('Called');
  7  		return '**** '||eno||' ****';
  8   	end;
  9   select
 10   	hoge(empno)
 11   from
 12*  	emp

HOGE(EMPNO)
---------------------------------------------------------------------
**** 7369 ****
**** 7499 ****
**** 7521 ****
**** 7566 ****
**** 7654 ****
**** 7698 ****
**** 7782 ****
**** 7839 ****
**** 7844 ****
**** 7900 ****
**** 7902 ****
**** 7934 ****
Called
Called
Called
Called
Called
Called
Called
Called
Called
Called
Called
Called
経過: 00:00:00.02

Database SQL Language Reference (12.1)
Database SQL Language Reference (12.1) - SELECT

みなさん、ダークサイドに落ちないように注意しましょうね！ :)

AWRレポート、AWR SQLレポート一括取得スクリプトを作ったよ。

Statspackレポートもそうなのですが、AWRレポート／AWR SQLレポートも個別に取得していると凄ーく辛いんですよね。一日分出力するとか、AWRレポートで処理時間の長いSQL文のAWR SQLレポートを個別に取得しようとなると...

ただでさえ忙しいのに、AWRレポート取得するのに時間掛けたくないですよね。

ということで、やっつけで作ったのですが、そのまま載せるのもあれなんで、やっつけで作った感じを多少減らしてgithubに公開しました。;)

https://github.com/discus/Oracle-AWR-batch-generation-script/blob/master/awrreport_batch.sql

もっといい感じに改造してくれるといいな〜とかとか... :)

Oracle11g R1/R2 Enterprise Edition、HTML形式で出力します。(RAC環境では試してないので多分だめかと。)。
（AWRを利用するには追加ライセンスが必要なのでご注意を）

使い方は・・

SQL*plusを起動し、select any dictionaryシステム権限、dbms_repositoryパッケージの実行権限が付与されたユーザで接続して実行するだけ。
SYSTEMユーザでやる事が多いけど、所変わればなんとやらなので・・・そこんとこよろしく。(w

一括取得なので実行当日を含めてn日分のAWRレポートを取得し、同時に処理時間の長いTop20のAWR SQLレポートも取得します。
レポートは各スナップショット間（今のところ固定）で取得します。

指定するパラメータは、以下の３つ。

Enter snap_id for starting AWR report generation. [NULL] : 

AWRレポートを取得する最初のSNAP_IDを指定します。 NULLがデフォルトでほとんどの場合デフォルトのままで事足りると思います。

Enter number of days for reporting period. [1] : 

一括取得する日数を指定します。当日を含みます。
当日分のAWRレポートを出力するのであれば、デフォルト値の1のままでOKです。

Enter suffix for AWR reports filename. [NULL] : test

保存するAWRレポートのファイル名に付加するsuffixを指定します。
試験名とか設定するといいですよね。

"test"と指定した場合

awrrpt_nnnn_nnnn_test.htmlや
awrsqrpt_nnnn_nnnn_test_sqlid.html

の形式で保存します。(nnnnはSNAP_ID)

実行例１）当日分の全レポートを取得する例

SYSTEM> 
SYSTEM> !ls -l awr*.sql
-rw-r--r-- 1 oracle oinstall 6065  1月 29 18:23 awrreport_batch.sql

SYSTEM> @awrreport_batch   
 --
-- Oracle AWR and AWR SQL report batch generation script
--
-- ***** This script always generate html format AWR reports. *****
--
Enter snap_id for starting AWR report generation. [NULL] : 
Enter number of days for reporting period. [1] : 
Enter suffix for AWR reports filename. [NULL] : test
--
--
--
clear break compute;
repfooter off;
ttitle off;
btitle off;

・・・中略・・・

<p />
<br /><a class="awr" href="#top">Back to Top</a><p />
</body></html>

SYSTEM> 

実行例２）当日分かつsnap_id=291以降で一括取得。（事前にsnap_idを調べておいてね）

SYSTEM> 
SYSTEM> @awrreport_batch
--
-- Oracle AWR and AWR SQL report batch generation script
--
-- ***** This script always generate html format AWR reports. *****
--
Enter snap_id for starting AWR report generation. [NULL] : 291
Enter number of days for reporting period. [1] : 
Enter suffix for AWR reports filename. [NULL] : test
--
--
--
clear break compute;
repfooter off;
ttitle off;
btitle off;

・・・中略・・・

<p />
<br /><a class="awr" href="#top">Back to Top</a><p />
</body></html>

SYSTEM> 
SYSTEM> 
SYSTEM> !ls -l *.html
-rw-r--r-- 1 oracle oinstall 379083  1月 29 22:23 awrrpt_291_292_test.html
-rw-r--r-- 1 oracle oinstall  11899  1月 29 22:23 awrsqrpt_291_292_test_0c83z9rqx45hu.html
-rw-r--r-- 1 oracle oinstall  11899  1月 29 22:23 awrsqrpt_291_292_test_0h3mfbzk6uyw0.html
-rw-r--r-- 1 oracle oinstall  11897  1月 29 22:23 awrsqrpt_291_292_test_2p7t0mw7zvu5z.html

・・・中略・・・

-rw-r--r-- 1 oracle oinstall  11899  1月 29 22:23 awrsqrpt_291_292_test_bhtycgwkxhfj9.html
-rw-r--r-- 1 oracle oinstall  11900  1月 29 22:23 awrsqrpt_291_292_test_bpaggvtfkar9k.html
-rw-r--r-- 1 oracle oinstall  11899  1月 29 22:23 awrsqrpt_291_292_test_c50hdbyuwhfn6.html
-rw-r--r-- 1 oracle oinstall  11892  1月 29 22:23 awrsqrpt_291_292_test_g3f3cw3zy5aat.html

SYSTEM> 

なお、Oracleインスタンスが再起動された期間でawrrpt.sqlなどを実行すると、レポートが作成できずエラーでSQL*Plusも終了してしまいますが、本スクリプトでは該当部分のレポートはスキップするようにしてあります。:)

Instance     DB Name      Snap Id   Snap Started       Level
------------ ------------ --------- ------------------ -----
lampeye      LAMPEYE            274 29 1月  2012 09:33     1
                                275 29 1月  2012 10:00     1
                                276 29 1月  2012 10:30     1
                                277 29 1月  2012 11:00     1
                                278 29 1月  2012 11:30     1
                                279 29 1月  2012 12:00     1
                                280 29 1月  2012 12:30     1
                                281 29 1月  2012 13:00     1
                                282 29 1月  2012 13:30     1
                                283 29 1月  2012 14:00     1
                                284 29 1月  2012 14:30     1
                                285 29 1月  2012 15:00     1
                                286 29 1月  2012 15:30     1
                                287 29 1月  2012 16:00     1
                                288 29 1月  2012 16:30     1
                                289 29 1月  2012 17:00     1
                                290 29 1月  2012 17:30     1

                                291 29 1月  2012 18:31     1  ←再起動されてる
                                292 29 1月  2012 18:34     1

                                293 29 1月  2012 22:26     1　←再起動されてる

Enjoy!

PL/SQL de Conditional Compile #6

随分前にPL/SQL de Conditional Compile #5ってエントリ書いてたのを思い出して、11g R1/R2用のを見てみたらソースに丁寧なコメント（マニュアルよりいいんじゃね？w )が書かれていてうれしくなった。

オラクルさんとして見せたくない部分は見えないようになっているけど、見せても問題ないところはコードが見える(all_sourceビュー）わけで、それはそれでうれしいわけです。はい。マニュアルが意外に不親切だったりするので。

（マニュアル、良くなりましたよ。昔より。　＞　褒めておかないとね、だれとなくw。）...文字サイズも多くしておきましたw

● Oracle11g R1 11.1 の DBMS_DB_VERSION

package dbms_db_version is
  version constant pls_integer := 11; -- RDBMS version number
  release constant pls_integer := 1;  -- RDBMS release number

  /* The following boolean constants follow a naming convention. Each
     constant gives a name for a boolean expression. For example,
     ver_le_9_1  represents version <=  9 and release <= 1
     ver_le_10_2 represents version <= 10 and release <= 2
     ver_le_10   represents version <= 10

     A typical usage of these boolean constants is

         $if dbms_db_version.ver_le_10 $then
           version 10 and ealier code
         $elsif dbms_db_version.ver_le_11 $then
           version 11 code
         $else
           version 12 and later code
         $end

     This code structure will protect any reference to the code
     for version 12. It also prevents the controlling package
     constant dbms_db_version.ver_le_11 from being referenced
     when the program is compiled under version 10. A similar
     observation applies to version 11. This scheme works even
     though the static constant ver_le_11 is not defined in
     version 10 database because conditional compilation protects
     the $elsif from evaluation if the dbms_db_version.ver_le_10 is
     TRUE.
  */

  ver_le_9_1    constant boolean := FALSE;
  ver_le_9_2    constant boolean := FALSE;
  ver_le_9      constant boolean := FALSE;
  ver_le_10_1   constant boolean := FALSE;
  ver_le_10_2   constant boolean := FALSE;
  ver_le_10     constant boolean := FALSE;
  ver_le_11_1   constant boolean := TRUE;
  ver_le_11     constant boolean := TRUE;

end dbms_db_version;

● Oracle11g R2 11.2 の DBMS_DB_VERSION

package dbms_db_version is
  version constant pls_integer := 11; -- RDBMS version number
  release constant pls_integer := 2;  -- RDBMS release number

  /* The following boolean constants follow a naming convention. Each
     constant gives a name for a boolean expression. For example,
     ver_le_9_1  represents version <=  9 and release <= 1
     ver_le_10_2 represents version <= 10 and release <= 2
     ver_le_10   represents version <= 10

     A typical usage of these boolean constants is

         $if dbms_db_version.ver_le_10 $then
           version 10 and ealier code
         $elsif dbms_db_version.ver_le_11 $then
           version 11 code
         $else
           version 12 and later code
         $end

     This code structure will protect any reference to the code
     for version 12. It also prevents the controlling package
     constant dbms_db_version.ver_le_11 from being referenced
     when the program is compiled under version 10. A similar
     observation applies to version 11. This scheme works even
     though the static constant ver_le_11 is not defined in
     version 10 database because conditional compilation protects
     the $elsif from evaluation if the dbms_db_version.ver_le_10 is
     TRUE.
  */

  ver_le_9_1    constant boolean := FALSE;
  ver_le_9_2    constant boolean := FALSE;
  ver_le_9      constant boolean := FALSE;
  ver_le_10_1   constant boolean := FALSE;
  ver_le_10_2   constant boolean := FALSE;
  ver_le_10     constant boolean := FALSE;
  ver_le_11_1   constant boolean := FALSE;
  ver_le_11_2   constant boolean := TRUE;
  ver_le_11     constant boolean := TRUE;

end dbms_db_version;

version 12 and later codeなんて箇所、いいですね〜w

---

・PL/SQL de Conditional Compile #1
・PL/SQL de Conditional Compile #2
・PL/SQL de Conditional Compile #3
・PL/SQL de Conditional Compile #4
・PL/SQL de Conditional Compile #5

PL/SQLでCASE式を使わずに条件分岐 #3

PL/SQLでCASE式を使わずに条件分岐の３回目です。

前回作成したプロシージャをパッケージ化し、コマンドを外部から与えられるようにしてみます。

前回作成したsimpleCommandプロシージャを削除してパッケージ化します。store()プロシージャでコマンドを登録、execute()プロシージャで実行です。

SCOTT> drop procedure simpleCommand;

プロシージャが削除されました。

SCOTT> 
SCOTT> l
  1  CREATE OR REPLACE PACKAGE simpleCommand
  2  AS
  3    PROCEDURE store(
  4	 commandName   IN VARCHAR2
  5	,commandSource IN command
  6    );
  7    --
  8    PROCEDURE execute(
  9	 commandName   IN VARCHAR2
 10    );
 11* END;
SCOTT> /

パッケージが作成されました。

SCOTT> 
SCOTT> l
  1  CREATE OR REPLACE PACKAGE BODY simpleCommand
  2  AS
  3    TYPE command_type IS TABLE OF command INDEX BY VARCHAR2(4000);
  4    commands command_type;
  5    --
  6    PROCEDURE store(
  7	 commandName   IN VARCHAR2
  8	,commandSource IN command
  9    )
 10    IS
 11    BEGIN
 12	 commands(commandName) := commandSource;
 13    END;
 14    --
 15    PROCEDURE execute(
 16	 commandName   IN VARCHAR2
 17    )
 18    IS
 19    BEGIN
 20	 commands(commandName).execute();
 21    EXCEPTION
 22	 WHEN NO_DATA_FOUND THEN
 23        DBMS_OUTPUT.PUT_LINE('そんなコマンド知りません! >< ');
 24    END;
 25* END;
SCOTT> /

パッケージ本体が作成されました。

SCOTT> 

では早速試してみます。まず、コマンドを登録！

SCOTT> l
  1    BEGIN
  2	 simpleCommand.store(
  3        'いま何時？',
  4	   Command(
  5	     'BEGIN '||
  6            'DBMS_OUTPUT.PUT_LINE(''現在時刻：''||TO_CHAR(systimestamp, ''yyyy-mm-dd hh24:mi:ss''));'||
  7	     'END;'
  8	   )
  9	 );
 10	 simpleCommand.store(
 11        '従業員数は？',
 12	   Command(
 13	     'DECLARE '||
 14	       'numberOfEmployees NUMBER;'||
 15	     'BEGIN '||
 16	       'SELECT COUNT(*) INTO numberOFEmployees FROM emp;'||
 17            'DBMS_OUTPUT.PUT_LINE(''従業員数：''||TO_CHAR(numberOfEmployees));'||
 18	     'END;'
 19	   )
 20	 );
 21	 simpleCommand.store(
 22        '従業員リスト',
 23	   Command(
 24	     'DECLARE '||
 25	       'CURSOR empList IS '||
 26		 'SELECT '||
 27		   'empno '||
 28		  ',ename '||
 29		  ',dname '||
 30		 'FROM '||
 31		   'emp JOIN dept '||
 32		   'ON emp.deptno = dept.deptno '||
 33		 'ORDER BY '||
 34		   'dname, empno, ename;'||
 35	     'BEGIN '||
 36	       'FOR empRec IN empList LOOP '||
 37		 'DBMS_OUTPUT.PUT_LINE(empRec.empno || '' '' || empRec.ename || '' '' || empRec.dname);'||
 38	       'END LOOP; '||
 39	     'END;'
 40	   )
 41	 );
 42*   END;
SCOTT> /

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

SCOTT> 

実行！.これで適用範囲を広げらるかも・・・w

SCOTT> set serveroutput on size 100000
SCOTT> 
SCOTT> exec simpleCommand.execute('従業員リスト');
7782 CLARK ACCOUNTING
7839 KING ACCOUNTING
7934 MILLER ACCOUNTING
7369 SMITH RESEARCH
7566 JONES RESEARCH
7788 SCOTT RESEARCH
7876 ADAMS RESEARCH
7902 FORD RESEARCH
7499 ALLEN SALES
7521 WARD SALES
7654 MARTIN SALES
7698 BLAKE SALES
7844 TURNER SALES
7900 JAMES SALES

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

SCOTT> exec simpleCommand.execute('いま何時？');
現在時刻：2010-03-20 23:53:22

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

SCOTT> exec simpleCommand.execute('従業員数は？');
従業員数：14

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

SCOTT> exec simpleCommand.execute('ほげほげ');
そんなコマンド知りません! ><

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

SCOTT> 

---

・バックナンバー
PL/SQLでCASE式を使わずに条件分岐 #1
PL/SQLでCASE式を使わずに条件分岐 #2

PL/SQLでCASE式を使わずに条件分岐 #2

PL/SQLでCASE式を使わずに条件分岐の２回目です。

前回作成したプロシージャから、とにかくCASE式を無くてみましょ。

まず、以下の様なオブジェクト型を定義して・・・・・

SCOTT> l
  1  CREATE OR REPLACE TYPE command AS OBJECT
  2  (
  3  	commandStr CLOB,
  4  	MEMBER PROCEDURE execute
  5* );
SCOTT> /

型が作成されました。

SCOTT> 
SCOTT> l
  1  CREATE OR REPLACE TYPE BODY command
  2  AS
  3  	MEMBER PROCEDURE execute
  4  	IS
  5  	BEGIN
  6  		EXECUTE IMMEDIATE commandStr;
  7  	END;
  8* END;
SCOTT> /

型本体が作成されました。

SCOTT> 

PL/SQLの結合配列のINDEXにVARCHAR2型を利用すればハッシュテーブルと同じように使えることを利用して実行するコマンドはCLOBに格納してEXECUTE IMMEDIATE文で実行しちゃうという方法です。実行するコマンドは外部から与えるようにすることもできますが、とりあえず内部に直書き。

SCOTT> l
  1  CREATE OR REPLACE PROCEDURE simpleCommand
  2  (
  3	 commandName IN VARCHAR2
  4  )
  5  IS
  6    TYPE command_type IS TABLE OF command INDEX BY VARCHAR2(4000);
  7    commands command_type;
  8    --
  9    PROCEDURE init IS
 10    BEGIN
 11      commands('いま何時？')
 12	   := Command(
 13		'BEGIN '||
 14               'DBMS_OUTPUT.PUT_LINE(''現在時刻：''||TO_CHAR(systimestamp, ''yyyy-mm-dd hh24:mi:ss''));'||
 15		'END;'
 16	      );
 17      commands('従業員数は？')
 18	   := Command(
 19		'DECLARE '||
 20		  'numberOfEmployees NUMBER;'||
 21		'BEGIN '||
 22		  'SELECT COUNT(*) INTO numberOFEmployees FROM emp;'||
 23               'DBMS_OUTPUT.PUT_LINE(''従業員数：''||TO_CHAR(numberOfEmployees));'||
 24		'END;'
 25	      );
 26      commands('従業員リスト')
 27	   := Command(
 28		'DECLARE '||
 29		  'CURSOR empList IS '||
 30		    'SELECT '||
 31		      'empno '||
 32		     ',ename '||
 33		     ',dname '||
 34		    'FROM '||
 35		      'emp JOIN dept '||
 36		      'ON emp.deptno = dept.deptno '||
 37		    'ORDER BY '||
 38		      'dname, empno, ename;'||
 39		'BEGIN '||
 40		  'FOR empRec IN empList LOOP '||
 41		    'DBMS_OUTPUT.PUT_LINE(empRec.empno || '' '' || empRec.ename || '' '' || empRec.dname);'||
 42		  'END LOOP; '||
 43		'END;'
 44	      );
 45    END;
 46    --
 47  BEGIN
 48    init();
 49    --
 50    commands(commandName).execute();
 51  EXCEPTION
 52    WHEN NO_DATA_FOUND THEN
 53      DBMS_OUTPUT.PUT_LINE('そんなコマンド知りません! >< ');
 54* END;
SCOTT> 
SCOTT> /

プロシージャが作成されました。

SCOTT> 

できた！！！　:)

SCOTT> set serveroutput on size 100000
SCOTT> exec simpleCommand('いま何時？');
現在時刻：2010-03-20 15:50:27

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

SCOTT> exec simpleCommand('従業員リスト');
7782 CLARK ACCOUNTING
7839 KING ACCOUNTING
7934 MILLER ACCOUNTING
7369 SMITH RESEARCH
7566 JONES RESEARCH
7788 SCOTT RESEARCH
7876 ADAMS RESEARCH
7902 FORD RESEARCH
7499 ALLEN SALES
7521 WARD SALES
7654 MARTIN SALES
7698 BLAKE SALES
7844 TURNER SALES
7900 JAMES SALES

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

SCOTT> exec simpleCommand('従業員数は？');
従業員数：14

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

SCOTT> exec simpleCommand('ほげほげ');
そんなコマンド知りません! ><

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

SCOTT> 

次回はコマンドを外部から与えられるように改造してみます。　次回へつづく。

---

・バックナンバー

PL/SQLでCASE式を使わずに条件分岐 #1

PL/SQLでCASE式を使わずに条件分岐 #1

随分前ですが、html5-developers-jpのディスカッションでJavaScriptでswitch文を使わずに条件分岐という話題があって、あ、そうそう、PL/SQLでもできるよね、って瞬間的に思っていたのですが、忙しくて、ず〜っと放置してたネタでございます。:)

今回は使うのは、Oracle11g R2 for Linux x86。

SCOTT> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE	11.2.0.1.0	Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

まずは、CASE式を使って書けば以下のような感じになるよね！　ってところから。

SCOTT> l
  1  CREATE OR REPLACE PROCEDURE simpleCommand
  2  (
  3	 commandName IN VARCHAR2
  4  )
  5  IS
  6    CURSOR empList IS
  7	 SELECT
  8	   empno
  9	  ,ename
 10	  ,dname
 11	 FROM
 12	   emp JOIN dept
 13	   ON emp.deptno = dept.deptno
 14	 ORDER BY
 15	   dname, empno, ename
 16    ;
 17    --
 18    numberOfEmployees NUMBER;
 19  BEGIN
 20    CASE commandName
 21      WHEN 'いま何時？' THEN
 22        DBMS_OUTPUT.PUT_LINE('現在時刻：'||TO_CHAR(systimestamp, 'yyyy-mm-dd hh24:mi:ss'));
 23      WHEN '従業員数は？' THEN
 24	   SELECT COUNT(*) INTO numberOFEmployees FROM emp;
 25        DBMS_OUTPUT.PUT_LINE('従業員数：'||TO_CHAR(numberOfEmployees));
 26      WHEN '従業員リスト' THEN
 27	   FOR empRec IN empList LOOP
 28	     DBMS_OUTPUT.PUT_LINE(empRec.empno || ' ' || empRec.ename || ' ' || empRec.dname);
 29	   END LOOP;
 30	 ELSE
 31        DBMS_OUTPUT.PUT_LINE('そんなコマンド知りません! >< ');
 32    END CASE;
 33    --
 34* END;
SCOTT> /

プロシージャが作成されました。

SCOTT> 
SCOTT> set serveroutput on size 100000
SCOTT> exec simpleCommand('いま何時？');
現在時刻：2010-03-21 00:10:17

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

SCOTT> exec simpleCommand('従業員リスト');
7782 CLARK ACCOUNTING
7839 KING ACCOUNTING
7934 MILLER ACCOUNTING
7369 SMITH RESEARCH
7566 JONES RESEARCH
7788 SCOTT RESEARCH
7876 ADAMS RESEARCH
7902 FORD RESEARCH
7499 ALLEN SALES
7521 WARD SALES
7654 MARTIN SALES
7698 BLAKE SALES
7844 TURNER SALES
7900 JAMES SALES

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

SCOTT> exec simpleCommand('従業員数は？');
従業員数：14

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

SCOTT> exec simpleCommand('ほげほげ');
そんなコマンド知りません! ><

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

SCOTT> 

上記のようなPL/SQLプロシージャ中のCASE式を排除してコマンドパターンっぽくできるのか。。。方法はいろいろあるな〜と思いつつ、PL/SQLの結合配列を使う方法で試してみた。
ということで、次回へつづく　:) …

UTL_FILE.FCOPY()とかFRENAME()とか

UTL_FILE.FRENAME()プロシージャとか、UTL_FILE.FCOPY()プロシージャって何かと便利っていうお話。

テストでOracleデータベース側に格納されたデータと紐づけながら画像ファイルを複製してみたり、名称を紐づけたりするときにも重宝するプロシージャなんですよね。
特に、shellなどがないWindows環境で画像を大量に複製したりする場合にはかなり便利だなと。

まずは、OS上のディレクトリとの紐付け。ディレクトリオブジェクトを作成しておきます。（今回はSCOTTユーザにディレクトリオブジェクトを作成できるように権限を付与しておきました）

SCOTT> 
SCOTT> create directory ora_dir as '/home/oracle/ora_dir';

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

SCOTT>  

UTL_FILE.FRENAME()プロシージャは、Linux/Unixのmvコマンドライク。
以下は、リネーム後のファイル名(hogehoge.png)と同じファイルが既に存在する場合には置き換えない場合の例。overwriteパラメータをFALSE（デフォルト）にしてあげる。

SCOTT> !ls -l ora_dir
-rw-r--r-- 1 oracle oinstall 28800  2月 20 09:26 hogehoge.png
-rw-r--r-- 1 oracle oinstall 28800  2月 19 23:57 test.png

SCOTT> l
  1  BEGIN
  2    UTL_FILE.FRENAME('ORA_DIR','test.png','ORA_DIR','hogehoge.png',FALSE);
  3* END;
SCOTT> /
BEGIN
*
行1でエラーが発生しました。:
ORA-29292: ファイル名の変更操作に失敗しました。 ORA-06512:
"SYS.UTL_FILE", 行348
ORA-06512: "SYS.UTL_FILE", 行1290
ORA-06512: 行2

SCOTT> !ls -l ora_dir
-rw-r--r-- 1 oracle oinstall 28800  2月 20 09:26 hogehoge.png
-rw-r--r-- 1 oracle oinstall 28800  2月 19 23:57 test.png

以下は、リネーム後のファイル名(hogehoge.png)と同じファイルが既に存在する場合に置き換えてしまう例。overwriteパラメータをTRUEにしてあげる。

SCOTT> !ls -l ora_dir
-rw-r--r-- 1 oracle oinstall 28800  2月 20 09:26 hogehoge.png
-rw-r--r-- 1 oracle oinstall 28800  2月 19 23:57 test.png

SCOTT> l
  1  BEGIN
  2    UTL_FILE.FRENAME('ORA_DIR','test.png','ORA_DIR','hogehoge.png',TRUE);
  3* END;
SCOTT> /

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

SCOTT> !ls -l ora_dir
-rw-r--r-- 1 oracle oinstall 28800  2月 19 23:57 hogehoge.png

SCOTT>

せっかくUTL_FILE.FRENAME()プロシージャを試したので、次いでにUTL_FILE.FCOPY()でファイルコピーも！
といきたいところですが、UTL_FILE.FCOPY()プロシージャはテキストファイルのコピーしか行えない！（パラメータからも想像できると思うけど）
では、画像ファイルなどのバイナリファイルはどうすんのさ！オラクルさん！。ってことで、そのようなプロシージャは無いので自前で作りましょ。
以下は、そのサンプル、バイナリモードで画像ファイルを読み込んでバイナリモードで別ファイルへ書き出す。だたそれだけ。

SCOTT> !ls -l ora_dir 
-rw-r--r-- 1 oracle oinstall 28800  2月 19 23:13 test2.png

SCOTT> 
SCOTT> l
  1  DECLARE
  2	 src_file UTL_FILE.FILE_TYPE;
  3	 dst_file UTL_FILE.FILE_TYPE;
  4	 buffer RAW(32767);
  5    BEGIN
  6	 src_file := UTL_FILE.FOPEN('ORA_DIR','test2.png', 'rb', 32767);
  7	 dst_file := UTL_FILE.FOPEN('ORA_DIR','hogehogehoge.png', 'wb', 32767);
  8	 LOOP
  9	   BEGIN
 10	     UTL_FILE.GET_RAW(src_file, buffer, 32767);
 11	     UTL_FILE.PUT_RAW(dst_file, buffer, TRUE);
 12	   EXCEPTION
 13	     WHEN NO_DATA_FOUND THEN
 14	       EXIT;
 15	   END;
 16	 END LOOP;
 17	 UTL_FILE.FCLOSE(src_file);
 18	 UTL_FILE.FCLOSE(dst_file);
 19*   END;
SCOTT> /

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

SCOTT> !ls -l ora_dir
-rw-r--r-- 1 oracle oinstall 28800  2月 19 23:57 hogehogehoge.png
-rw-r--r-- 1 oracle oinstall 28800  2月 19 23:13 test2.png

SCOTT> 

PL/SQL で Python Challenge Level 18 - 完

ということで、Python Challenge Level18の最終回。
前回報告した通り level 18　はPL/SQLだけで解けます。今回は問題の元ネタの抽出と回答を抽出した後の確認はOSに付属している機能を使ったが大切なのは問題の元ネタから解答を抽出する所なので。

SQL*Plusから実行したストアドプロシージャで問題を解いたところ．．．．例によってヒントになりそうな部分はもやもやさせてます。 :)

ヒントになりまくりの答えのスナップショット。（これ以外にも私のブログにヒントになる記事もあるのだが・・・・・それは書きませんよ。。。。）

ちなみに絵を見れば分かると思いますが、MacOS XからX11のX forwordingを使って今回利用したLinuxのDesktopを表示/操作しています。X11のxtermからssh -Y user@hostで接続してgnome-sessionを実行しているだけ。

Python Challenge Level19へつづく！（？）

PL/SQL で Python Challenge Level 18 解けた

一年以上間が空いてしまったが・・・Python Challenge Level18はPL/SQLだけで解けますよん。ヒントになるようなならないようなモヤモヤした記事は明日にでも。。

PL/SQL de O(ND) Difference Algorithm

かなり久々ですが、まあ、シリーズもののネタを毎日アップするのもなかなか難しい状況なので単発ネタでも。

ということで今回は、PL/SQLでAn O(ND) Difference Algorithmを実装して頭の体操。

文書比較のアルゴリズムとしてはAn O(NP) Sequence Comparison Algorithmが効率は良いのだが、先日javascriptで書かれたO(ND)のコードを見つけたことをキッカケにPL/SQLで写経したくなったというわけ。

文書比較アルゴリズムは２、３年くらい前、文書比較アブゴリズム、diff(1)/diff(2)/diff(3)等をみたことがあったが、最近pyhthonやらjavascriptのコードを目にするようになり　(^^) な顔して眺めていて時間があったらPL/SQLで遊んでみようと思っていた。。他の言語でやってもMac De Oracle的にはおもしろくないので。

ちなみに、pythonだどdifflib使えば文書比較はできるので実際新たに書く必要はそんなにないんじゃなかろうかとも思うわけですが、私のようにわざわざPL/SQLで書いてみようと思う人間もいるわけで、頭の体操にはいいと思います！。理解するのは大変だったけど。wwww

最近見つけたO(ND)やO(NP)に関するブログ等のリンクは以下。

・レコメンデーションとエディットグラフ
・diff O(np) javascript implementation
・"An O(NP) Sequence Comparison Algorithm" with Python
・"An O(NP) Sequence Comparison Algorithm" with Python の添削
・Javascriptでdiffる ( with 形態素解析 )
・google-diff-match-patch

今回はレコメンデーションとエディットグラフにあるO(ND)コードを写経してPL/SQLでやってみた。O(NP)も集中できる時間があったらやってみたい。。。脳トレにも丁度いいかもよ。。。
※Oracle11g 11.1.0.7.0を使ったが、Oracle10g 10.1.0.3.0以上なら動作するはず。。。。(^^;;;

まずは、結果からどうぞ。O(ND)をPL/SQLストアドファンクション化し、SQLから実行できるようにしてあります。また、pythonのdifflibにあるdifferクラスで利用されている差異コード('?'を除く）を出力するようにしてあります。）

SCOTT> set timi on
SCOTT> l
  1  SELECT
  2    '"' || diffs.code || diffs.string || '"' AS "diff O(ND) results"
  3  FROM
  4    TABLE(
  5      SELECT diffOND('BFEABD', 'ABCDA') from dual
  6    ) diffs
  7  ORDER BY
  8*   diffs.seq DESC
SCOTT> /

diff O(ND) results
--------------------------------------------------------------------------------
"- B"
"- F"
"- E"
"  A"
"  B"
"+ C"
"  D"
"+ A"

8行が選択されました。

経過: 00:00:00.00

SCOTT> 
SCOTT> l
  1  SELECT
  2    '"' || diffs.code || diffs.string || '"' AS "diff O(ND) results"
  3  FROM
  4    TABLE(
  5      SELECT diffOND('aaebdd ', 'aedajkd') from dual
  6    ) diffs
  7  ORDER BY
  8*   diffs.seq DESC
SCOTT> /

diff O(ND) results
--------------------------------------------------------------------------------
"  a"
"- a"
"  e"
"- b"
"  d"
"+ a"
"+ j"
"+ k"
"  d"
"-  "

10行が選択されました。

経過: 00:00:00.00

SCOTT> 
SCOTT> l
  1  SELECT
  2    '"' || diffs.code || diffs.string || '"' AS "diff O(ND) results"
  3  FROM
  4    TABLE(
  5      SELECT diffOND('ABCDE', 'ABCDE') from dual
  6    ) diffs
  7  ORDER BY
  8*   diffs.seq DESC
SCOTT> /

diff O(ND) results
--------------------------------------------------------------------------------
"  A"
"  B"
"  C"
"  D"
"  E"

経過: 00:00:00.00

SCOTT> 
SCOTT> l
  1  SELECT
  2    '"' || diffs.code || diffs.string || '"' AS "diff O(ND) results"
  3  FROM
  4    TABLE(
  5      SELECT diffOND('あいうえお','かきくけこ') from dual
  6    ) diffs
  7  ORDER BY
  8*   diffs.seq DESC
SCOTT> /

diff O(ND) results
--------------------------------------------------------------------------------
"- あ"
"- い"
"- う"
"- え"
"- お"
"+ か"
"+ き"
"+ く"
"+ け"
"+ こ"

10行が選択されました。

経過: 00:00:00.00

SCOTT> 

PL/SQLのコードは以下の通り。

SCOTT> !cat ond.sql

CREATE OR REPLACE TYPE vRecType AS OBJECT
(
     x NUMBER
    ,y NUMBER
    ,parent ANYDATA
);
/
show errors

BEGIN
  FOR functionNames 
    IN (SELECT object_name FROM USER_OBJECTS WHERE object_name='DIFFOND' AND OBJECT_TYPE='FUNCTION')
  LOOP
    EXECUTE IMMEDIATE 'DROP FUNCTION ' || functionNames.object_name;
  END LOOP;

  FOR typeNames 
    IN (SELECT type_name FROM USER_TYPES WHERE type_name='DIFFLISTTYPE')
  LOOP
    EXECUTE IMMEDIATE 'DROP TYPE ' || typeNames.type_name;
  END LOOP;
END;
/

CREATE OR REPLACE TYPE diffType AS OBJECT
(
     seq        NUMBER
    ,code       CHAR(2)
    ,string     VARCHAR2(32767)
);
/
show errors

CREATE OR REPLACE TYPE diffListType AS TABLE OF diffType;
/
show errors

CREATE FUNCTION diffOND
(
     str1       IN VARCHAR2
    ,str2       IN VARCHAR2
)
RETURN diffListType
IS
    STAT_INIT  CONSTANT PLS_INTEGER := 0;
    STAT_X     CONSTANT PLS_INTEGER := 1;
    STAT_Y     CONSTANT PLS_INTEGER := 2;

    TYPE vType IS TABLE OF vRecType;
    v vType := vType();

    FUNCTION isVRecNotEmpty(
        vRec    IN vRecType
    )
    RETURN BOOLEAN
    IS
    BEGIN
        RETURN (CASE WHEN vRec.x IS NULL AND vRec.y IS NULL AND vRec.parent IS NULL THEN FALSE ELSE TRUE END);
    END isVRecNotEmpty;

    FUNCTION getDirection
    (
         vMinus IN vRecType
        ,vPlus  IN vRecType
    )
    RETURN PLS_INTEGER
    IS
    BEGIN
        IF NOT isVRecNotEmpty(vMinus) AND NOT isVRecNotEmpty(vPlus) THEN
            RETURN STAT_INIT;
        END IF;

        IF NOT isVRecNotEmpty(vMinus) THEN
            RETURN STAT_X;
        END IF;

        IF NOT isVRecNotEmpty(vPlus) THEN
            RETURN STAT_Y;
        END IF;

        RETURN (CASE WHEN vMinus.x < vPlus.x THEN STAT_X ELSE STAT_Y END);
    END getDirection;

    FUNCTION OND
    (
         str1 IN VARCHAR2
        ,str2 IN VARCHAR2
    )
    RETURN vRecType
    IS
        offset  PLS_INTEGER;
        kMax    PLS_INTEGER;
        kMin    PLS_INTEGER;
        k       PLS_INTEGER;
        vIndex  PLS_INTEGER;
        x       PLS_INTEGER;
        y       PLS_INTEGER;
        str1Len PLS_INTEGER;
        str2Len PLS_INTEGER;
        parent  vRecType;
    BEGIN
        str1Len := LENGTH(str1);
        str2Len := LENGTH(str2);
        v.EXTEND(str1Len + str2Len + 3);
        offset:= str2Len + 2;

        FOR d IN 0..str1Len + str2Len LOOP
            kMax := (CASE WHEN d <= str1Len THEN d ELSE str1Len - (d - str1Len) END);
            kMin := (CASE WHEN d <= str2Len THEN d ELSE str2Len - (d - str2Len) END);

            k := kMin * -1;
            WHILE k <= kMax LOOP
                vIndex := offset + k;
                CASE getDirection(v(vIndex-1), v(vIndex+1))
                    WHEN STAT_INIT THEN
                        x := 0;
                        y := 0;
                        parent := vRecType(0, 0, NULL);
                    WHEN STAT_X THEN
                        x := v(vIndex+1).x;
                        y := v(vIndex+1).y + 1;
                        parent := v(vIndex+1);
                    WHEN STAT_Y THEN
                        x := v(vIndex-1).x + 1;
                        y := v(vIndex-1).y;
                        parent := v(vIndex-1);
                END CASE;

                -- snake
                WHILE (x < str1Len AND y < str2Len) 
                AND (SUBSTR(str1, x+1, 1) = SUBSTR(str2, y+1, 1)) 
                LOOP
                    x := x + 1;
                    y := y + 1;
                END LOOP;
                v(vIndex) := vRecType(x, y, ANYDATA.ConvertObject(parent));

                IF str1Len <= x AND str2Len <= y THEN
                    RETURN v(vIndex);
                END IF;

                k := k + 2;
            END LOOP; 
        END LOOP;
    END OND;

    FUNCTION diff
    (
         str1 IN VARCHAR2
        ,str2 IN VARCHAR2
    )
    RETURN diffListType
    IS
        endPoint                vRecType;
        parent                  vRecType;
        diff_x                  PLS_INTEGER;
        diff_y                  PLS_INTEGER;
        same_len                PLS_INTEGER;
        isSuccessGetObject      PLS_INTEGER;
        diffs                   diffListType := diffListType();
        seq                     PLS_INTEGER := 0;
    BEGIN
        endPoint := OND(str1, str2);
        WHILE endPoint.parent IS NOT NULL LOOP
            IF ANYDATA.getObject(endPoint.parent, parent) != DBMS_TYPES.SUCCESS THEN
                RAISE_APPLICATION_ERROR(-20000,'DBMS_TYPES.NO_DATA');
            END IF;

            diff_x := endPoint.x - parent.x;
            diff_y := endPoint.y - parent.y;
            same_len := CASE WHEN diff_x <= diff_y THEN diff_x ELSE diff_y END;

            FOR i IN 0..same_len-1 LOOP
                -- common
                diffs.EXTEND();
                seq := seq + 1;
                diffs(diffs.COUNT()) := diffType(seq, '  ', SUBSTR(str1, endPoint.x-i, 1));
            END LOOP;

            IF diff_y != diff_x THEN
                diffs.EXTEND();
                seq := seq + 1;
                IF diff_y < diff_x THEN
                    -- del
                    diffs(diffs.COUNT()) := diffType(seq, '- ', SUBSTR(str1, parent.x+1, 1));
                ELSE
                    -- add
                    diffs(diffs.COUNT()) := diffType(seq, '+ ', SUBSTR(str2, parent.y+1, 1));
                END IF;
            END IF;

            endPoint := parent;
        END LOOP;

        RETURN diffs;
    END diff;
BEGIN
    RETURN diff(str1, str2);
END diffOND;
/
show errors

Enjoy PL/SQL! というより Enjoy Programming! のほうがいいか。。

OraTweet 1.0 あそび始めた。

OraTweet v1.0が公開されたということなので早速試してみた。といってもちょっとだけ。細かいところはみてないけどとりあえずは日本語も使えるみたい。ちょうどPL/SQL gatewayからTwitter APIを使って遊んでみようと思っていたところだから少し遊ぶか。

Leopard de Oracle10g R2 (Intel x86-64) #18 (APEX3.2と遊ぶ #11）

Oracle10g R2 10.2.0.4.0 for MacOSX (Intel x68-64)でAPEX3.2と遊ぶの第十話。

Oracle HTTP ServerとPL/SQL gatewayをORACLE_HOMEごとPowerMacからIntel Mac移動して、Intel Macへインストール、構築すしたOracle 10g R2 10.2.0.4.0 for MacOSX(Intel x86-64) + APEX3.2へアクセスしちゃいます。RosettaがPowerPC版のOracle HTTP Server mod_plsqlをIntel Mac上で動かしてくれます。

まず、MacBook Proのオラクル所有者の環境変数の設定などはLeopard de Oracle10g R2 (Intel x86-64) #2の設定に加え、Oracle HTTP Server向けaliasと環境変数を追加。
ちなみに、/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apexをIntel Mac上でのAPExのHOMEディレクトリとしてOracle HTTP Serverを起動、停止スクリプトをaliasとして定義。（Oracle 10g R1 10.1.0.3.0 for MacOSXのCompanionCDでインストールされるOracle HTTP Serverは　ORACLE_HOME（Oracle HTTP Serverの）/opmn/bin/opmnctl stopall 又は startallではなくORACLE_HOME（Oracle HTTP Serverの）/Apache/Apache/bin/apachectl start又はstopで起動／停止できます。）

guppy:˜ oracle$ cat .bashrc
alias ll='ls -lv'
alias startohs='$ORACLE_HTMLDB_HOME/bin/apachectl start'
alias stopohs='$ORACLE_HTMLDB_HOME/bin/apachectl stop'

export LANG=ja_JP.UTF-8
export ORACLE_BASE=/Users/shared/u01/app/oracle
export ORACLE_SID=leopard1
export ORACLE_HOME=$ORACLE_BASE/oracle/product/10.2.0/db_1
export NLS_LANG=Japanese_Japan.AL32UTF8
export DYLD_LIBRARY_PATH=$ORACLE_HOME/lib:$ORACLE_HOME/rdbms/lib:$ORACLE_HOME/network/lib:$DYLD_LIBRARY_PATH
export PATH=$ORACLE_HOME/bin:$PATH

#for Oracle11g and Jdeveloper Oracle Middleware HOME
export ORACLE_MIDDLEWARE_HOME=/Users/Shared/Oracle/Middleware

#for Oracle10g R1 Oracle HTTP ServerHome (include mod_plsql)
export ORACLE_HTMLDB_HOME=/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache
guppy:˜ oracle$ 

次に、PowerPC上でzipしたORACLE HTTP ServerのORACLE_HOMEディレクトリ以下を丸ごとIntel Mac上のOracle HTTP ServerのあたらしいHOMEディレクトリへ移動します。移動方法はrcpでもいいし、環境によってはscpでもいいしUSBメモリ経由でもmobileme経由でもお好きな方法でIntel Macへコピー／解凍します。PowerPC上のORACLE HTTP Serverホームディレクトリ以下は不要なのでHOMEディレクトリごと削除するもよし、ちゃんとOUIで削除してもいいですよん。
以下、MacBook Pro上で解凍した状態。MacBook Pro上のあたらしいHOMEディレクトリは、/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex

APEX3.2のimagesディレクトリのコピー。
APEX3.2のimagesディレクトリでOracle HTTP Serverのホームディレクトリ/marvel以下にあるimagesディレクトリを置き換えます。
この作業はAPEXのアップデート作業でもよく作業なのでお忘れなく。HTML DB1.5をAPEX3.2にアップデートしたようなものなので。

guppy:apex oracle$ pwd
/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/marvel
guppy:marvel oracle$ ls
10ins.sql	core		doc		ins.sql		jlib		readme.html	upgrade.sql
builder		coreins.sql	images		install.lst	logs		sbs		utilities
guppy:marvel oracle$ mv images images_htmldb_1_5
guppy:marvel oracle$ cp -rf /Users/oracle/Downloads/apex/images .
guppy:marvel oracle$ 

.confファイルの変更
ここからがメイン。PowerPC上でインストール構築したので各種.confファイルなどのパスはホスト名がPowerPC上の値に設定されています。それら全てを移動してきたMacBook Pro(Intel x86)上の値に変更していきます。
最初はOracle HTTP Server向けコンフィグファイルから。（全てのconfファイルを確認し要変更と確定できた変更前の*.confファイルは、*.conf.15として退避しておくことにします。）

/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apexは、MacBook Pro上でのOracle HTTP Serverのホームディレクトリ。

guppy:conf oracle$ pwd


/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/conf
guppy:conf oracle$ 
guppy:conf oracle$ ll
total 680
-rwxr-xr-x  1 oracle  oinstall    348 11 16  2004 access.conf
-rwxr-xr-x  1 oracle  oinstall    348 11 16  2004 access.conf.default
-rw-------  1 oracle  oinstall   1623  5 18 14:16 dms.conf
-rw-------  1 oracle  oinstall   1633  5 18 14:14 dms.conf.15
-rw-------  1 oracle  oinstall   1626  7  2  2004 dms.conf.sbs
-rwxr-xr-x  1 oracle  oinstall  41721  5 18 14:41 httpd.conf
-rwxr-xr-x  1 oracle  oinstall  42011  5 18 14:16 httpd.conf.15
-rwxr-xr-x  1 oracle  oinstall  42011  5 17 12:23 httpd.conf.default
-rwxr-xr-x  1 oracle  oinstall  39710 12 17  2004 httpd.conf.tmp
-rwxr-xr-x  1 oracle  oinstall  12965 11 16  2004 magic
-rwxr-xr-x  1 oracle  oinstall  12965 11 16  2004 magic.default
-rwxr-xr-x  1 oracle  oinstall  15161 11 16  2004 mime.types
-rwxr-xr-x  1 oracle  oinstall  15161 11 16  2004 mime.types.default
-rw-r--r--  1 oracle  oinstall    484  5 18 14:42 mod_oc4j.conf
-rw-r--r--  1 oracle  oinstall    490  5 18 14:41 mod_oc4j.conf.15
-rw-r--r--  1 oracle  oinstall    490  5 17 12:25 mod_oc4j.conf.default
-rw-r--r--  1 oracle  oinstall    503  7  2  2004 mod_oc4j.conf.tmp
-rwxr-xr-x  1 oracle  oinstall    779  5 17 12:23 mod_osso.conf
-rwxr-xr-x  1 oracle  oinstall    779 12 17  2004 mod_osso.conf.tmp
-rwxr-xr-x  1 oracle  oinstall    323  5 17 12:23 ohs_opmn.xml
-rwxr-xr-x  1 oracle  oinstall    323 12 17  2004 ohs_opmn.xml.sbs
-rwxr-xr-x  1 oracle  oinstall    566  5 18 14:44 ohstarget.xml
-rwxr-xr-x  1 oracle  oinstall    575  5 18 14:44 ohstarget.xml.15
-rwxr-xr-x  1 oracle  oinstall    585 12 17  2004 ohstarget.xml.tmp
-rwxr-xr-x  1 oracle  oinstall    197  5 18 14:45 oracle_apache.conf
-rwxr-xr-x  1 oracle  oinstall    217  5 18 14:45 oracle_apache.conf.15
drwxr-xr-x  2 oracle  oinstall     68  5 17 12:23 osso
-rwxr-xr-x  1 oracle  oinstall    357 11 16  2004 srm.conf
-rwxr-xr-x  1 oracle  oinstall    357 11 16  2004 srm.conf.default
-rwxr-xr-x  1 oracle  oinstall   7861  5 18 14:51 ssl.conf
-rwxr-xr-x  1 oracle  oinstall   8016  5 18 14:46 ssl.conf.15
-rwxr-xr-x  1 oracle  oinstall   7192 12 17  2004 ssl.conf.tmp
drwxr-xr-x  4 oracle  oinstall    136  5 17 12:23 ssl.crl
drwxr-xr-x  3 oracle  oinstall    102  5 17 12:23 ssl.wlt
guppy:conf oracle$ 
guppy:conf oracle$ 
guppy:conf oracle$ ls *.*.15
dms.conf.15		httpd.conf.15		mod_oc4j.conf.15
	ohstarget.xml.15	oracle_apache.conf.15	ssl.conf.15
guppy:conf oracle$
guppy:conf oracle$

以下、変更したconfファイルのdiff。


PowerPC上のORACLE_HOMEのパスとIntel Mac上のパスが異なるのでパス関連及び、ホスト名関連は変更対象。


例えば、PowerMac G5上でOracle HTTP Server用のORACLE_HOMEは

/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex


だったが、Intel Mac上では
/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex
とした。

guppy:conf oracle$
guppy:conf oracle$ diff dms.conf.15 dms.conf
30c30
<   Alias /index.html  /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/htdocs/index.html
---
>   Alias /index.html  /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/htdocs/index.html
guppy:conf oracle$
guppy:conf oracle$
guppy:conf oracle$ 
guppy:conf oracle$ diff mod_oc4j.conf.15 mod_oc4j.conf
15c15
<   Allow from localhost g5server g5server
---
>   Allow from localhost guppy guppy
guppy:conf oracle$
guppy:conf oracle$
guppy:conf oracle$ 
guppy:conf oracle$ diff ohstarget.xml.15 ohstarget.xml
5c5
<        <Property NAME="OracleHome" VALUE="/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex"/>
---
>        <Property NAME="OracleHome" VALUE="/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex" />
guppy:conf oracle$ 
guppy:conf oracle$
guppy:conf oracle$
guppy:conf oracle$ diff httpd.conf.15 httpd.conf
65c65
< ServerRoot "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache"
---
> ServerRoot "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache"
76c76
< #LockFile /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/httpd.lock
---
> #LockFile /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/httpd.lock
82c82
< PidFile /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/httpd.pid
---
> PidFile /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/httpd.pid
90c90
< ScoreBoardFile /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/httpd.scoreboard
---
> ScoreBoardFile /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/httpd.scoreboard
321c321
< ServerName g5server
---
> ServerName guppy
328c328
< DocumentRoot "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/htdocs"
---
> DocumentRoot "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/htdocs"
353c353
< <Directory "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/htdocs">
---
> <Directory "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/htdocs">
456c456
< 	TypesConfig /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/conf/mime.types
---
>         TypesConfig /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/conf/mime.types
482c482
<     MIMEMagicFile /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/conf/magic
---
>     MIMEMagicFile /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/conf/magic
502c502
< ErrorLog /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/error_log 
---
> ErrorLog /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/error_log
547c547
< CustomLog /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/access_log common
---
> CustomLog /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/access_log common
553,554c553,554
< #CustomLog /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/referer_log referer
< #CustomLog /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/agent_log agent
---
> #CustomLog /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/referer_log referer
> #CustomLog /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/agent_log agent
560c560
< #CustomLog /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/access_log combined
---
> #CustomLog /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/access_log combined
582,584c582,584
<     Alias /icons/ "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/icons/"
<     Alias /jservdocs/ "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Jserv/docs/"
<     Alias /javacachedocs/ "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/javacache/javadoc/"
---
>     Alias /icons/ "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/icons/"
>     Alias /jservdocs/ "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Jserv/docs/"
>     Alias /javacachedocs/ "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/javacache/javadoc/"
586c586
<         Alias /perl/ "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/cgi-bin/"
---
>         Alias /perl/ "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/cgi-bin/"
589c589
<     <Directory "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/icons">
---
>     <Directory "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/icons">
604c604
<     ScriptAlias /cgi-bin/ "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/cgi-bin/"
---
>     ScriptAlias /cgi-bin/ "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/cgi-bin/"    
608c608
<     # "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/cgi-bin" should be changed to whatever your ScriptAliased
---
>     # "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/cgi-bin" should be changed to whatever your ScriptAliased
611c611
<     <Directory "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/cgi-bin">
---
>     <Directory "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/cgi-bin">
824a825,826
>     AddType text/xml	.xbl
>     AddType text/x-compoment	.htc
938c940
<     Allow from localhost g5server g5server
---
>     Allow from localhost quppy guppy
950c952
< #    Allow from localhost g5server g5server
---
> #    Allow from localhsot guppy guppy
989c991
< #    CacheRoot "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/proxy"
---
> #    CacheRoot "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/proxy"
1038c1040
< SetEnv PERL5LIB  "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/perl/lib/5.6.1:
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/perl/lib/site_perl/5.6.1"
---
> SetEnv PERL5LIB  "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/perl/lib/5.6.1:
/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/perl/lib/site_perl/5.6.1"
1047c1049
< #	PerlSetEnv PERL5LIB  "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/perl/lib/5.6.1:
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/perl/lib/site_perl/5.6.1"
---
> #       PerlSetEnv PERL5LIB  "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/perl/lib/5.6.1:
/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/perl/lib/site_perl/5.6.1"
1084,1086c1086,1088
<    Alias /fastcgi/ "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/fastcgi/"
<    ScriptAlias /fcgi-bin/ "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/fcgi-bin/"
<    <Directory "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/fcgi-bin">
---
>    Alias /fastcgi/ "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/fastcgi/"
>    ScriptAlias /fcgi-bin/ "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/fcgi-bin/"
>    <Directory "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/fcgi-bin">
1104c1106
< #include "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Jserv/etc/jserv.conf"
---
> #include "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Jserv/etc/jserv.conf"
1128c1130
<     Allow from localhost g5server g5server
---
>     Allow from localhost guppy guppy
1134c1136
<     Allow from localhost g5server g5server
---
>     Allow from localhost guppy guppy
1139c1141
< include "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/conf/mod_oc4j.conf"
---
> include "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/conf/mod_oc4j.conf"
1142c1144
< include "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/conf/dms.conf"
---
> include "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/conf/dms.conf"
1148c1150
< include "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/conf/ssl.conf"
---
> include "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/conf/ssl.conf"
1151c1153
< #include "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/conf/mod_osso.conf"
---
> #include "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/conf/mod_osso.conf"
1154c1156
< include "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/conf/oracle_apache.conf"
---
> include "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/conf/oracle_apache.conf"
guppy:conf oracle$ 
guppy:conf oracle$
guppy:conf oracle$
guppy:conf oracle$ diff oracle_apache.conf.15 oracle_apache.conf
1,2c1,2
< include "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf/plsql.conf"
< include "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf/marvel.conf"
---
> include "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/modplsql/conf/plsql.conf"
> include "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/modplsql/conf/marvel.conf"
guppy:conf oracle$ 
guppy:conf oracle$
guppy:conf oracle$
guppy:conf oracle$ diff ssl.conf.15 ssl.conf
23,25c23,25
< #SSLSessionCache        dbm:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/ssl_scache
< #SSLSessionCache        shmht:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/ssl_scache(512000)
< SSLSessionCache        shmcb:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/ssl_scache(512000)
---
> #SSLSessionCache	dbm:/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/ssl_scache
> #SSLSessionCache	shmht:/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/ssl_scache(512000)
> SSLSessionCache		shmcb:/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/ssl_scache(512000)
36c36
< SSLMutex  file:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/ssl_mutex
---
> SSLMutex  file:/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/ssl_mutex
45c45
< SSLLog      /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/ssl_engine_log
---
> SSLLog      /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/ssl_engine_log
81,85c81,85
< DocumentRoot "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/htdocs"
< ServerName g5server
< ServerAdmin you@your.address
< ErrorLog /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/error_log
< TransferLog /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/access_log
---
> DocumentRoot "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/htdocs"
> ServerName guppy
> ServerAdmin your@mail.address
> ErrorLog /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/error_log
> TransferLog /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/access_log
100c100
< SSLWallet file:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/conf/ssl.wlt/default
---
> SSLWallet file/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/conf/ssl.wlt/default
117,118c117,118
< #SSLCARevocationPath /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/conf/ssl.crl
< #SSLCARevocationFile /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/conf/ssl.crl/ca-bundle.crl
---
> #SSLCARevocationPath /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/conf/ssl.crl
> #SSLCARevocationFile /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/conf/ssl.crl/ca-bundle.crl
177c177
< <Directory "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/cgi-bin">
---
> <Directory "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/cgi-bin">
186c186
< CustomLog /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/ssl_request_log \
---
> CustomLog /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/ssl_request_log \
guppy:conf oracle$ 

modplsql関連コンフィグファイルの変更
パスの変更とPlsqlDatabaseUsernameとPlsqlDefaultPageの値が変っているので注意。また接続先は、MacBook proにインストールしたOracle 10g R2 10.2.0.4.0 for MacOSX(Intel x86-64)になるので忘れずに変更する。

変更対象の.confファイルは予め、*.conf.15として退避しておいた。

guppy:conf oracle$ pwd
/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/modplsql/conf
guppy:conf oracle$ 
guppy:conf oracle$
guppy:conf oracle$
guppy:conf oracle$ diff cache.conf.15 cache.conf
12c12
< PlsqlCacheDirectory /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/cache
---
> PlsqlCacheDirectory /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/modplsql/cache
guppy:conf oracle$ 
guppy:conf oracle$
guppy:conf oracle$
guppy:conf oracle$ diff marvel.conf.15 marvel.conf
1,2c1,2
< Alias /i/ "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/marvel/images/"
< 		<Location /pls/htmldb>
---
> Alias /i/ "/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/marvel/images/"
> 		<Location /pls/apex>
7c7
< 		 PlsqlDatabaseUsername      HTMLDB_PUBLIC_USER
---
> 		 PlsqlDatabaseUsername      APEX_PUBLIC_USER
9,10c9,10
< 		 PlsqlDatabaseConnectString localhost:1521:tiger.macdeoracle.info ServiceNameFormat 
< 		 PlsqlDefaultPage           htmldb
---
> 		 PlsqlDatabaseConnectString localhost:1521:leopard1.macdeoracle.jp ServiceNameFormat 
> 		 PlsqlDefaultPage           apex
15c15
< 		 PlsqlNLSLanguage           AMERICAN_AMERICA.AL32UTF8
---
> 		 PlsqlNLSLanguage           JAPANESE_JAPAN..AL32UTF8
guppy:conf oracle$ 
guppy:conf oracle$
guppy:conf oracle$
guppy:conf oracle$ diff plsql.conf.15 plsql.conf
9c9
< LoadModule plsql_module /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/bin/modplsql.so
---
> LoadModule plsql_module /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/modplsql/bin/modplsql.so
20c20
< PlsqlLogDirectory /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/logs
---
> PlsqlLogDirectory /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/modplsql/logs
29c29
< include /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf/dads.conf
---
> include /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/modplsql/conf/dads.conf
34c34
< include /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf/cache.conf
---
> include /Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/modplsql/conf/cache.conf
guppy:conf oracle$ 

Oracle HTTP ServerのHOMEディレクトリ以下にあるtnsnames.oraもMacBook ProのOracle 10g R2へ接続するよう変更（念のため）

変更前のtnsnames.oraはtnsnames.ora.15として事前に退避しておいた。

guppy:admin oracle$ pwd
/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/network/admin
guppy:admin oracle$ 
guppy:admin oracle$
guppy:admin oracle$ guppy:admin oracle$ diff tnsnames.ora.15 tnsnames.ora
1c1
< (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=tiger.macdeoracle.info))) =
---
> (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=leopard1.macdeoracle.jp))) =
7,16c7
<       (SERVICE_NAME = tiger.macdeoracle.info)
<     )
<   )
< (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=tiger.macdeoracle.info))) =
<   (DESCRIPTION =
<     (ADDRESS_LIST =
<       (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
<     )
<     (CONNECT_DATA =
<       (SERVICE_NAME = tiger.macdeoracle.info)
---
>       (SERVICE_NAME = leopard1.macdeoracle.jp)
guppy:admin oracle$ 

apache起動用シェルスクリプトの書き換え（パスの変更が主）

要変更と判断したshell scriptは事前に、*.15として退避しておいた。

guppy:bin oracle$ pwd
/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/bin
guppy:bin oracle$ 
guppy:bin oracle$ 
guppy:bin oracle$ diff apachectl.15 apachectl
25,26c25,26
< ORACLE_HOME=/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex; export ORACLE_HOME
< NLS_LANG=${NLS_LANG="JAPANESE_JAPAN.JA16EUC"}; export NLS_LANG
---
> ORACLE_HOME=/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex; export ORACLE_HOME
> NLS_LANG=${NLS_LANG="JAPANESE_JAPAN.AL32UTF8"}; export NLS_LANG
29c29
< PERL5LIB=/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/perl/lib/5.8.3:
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/perl/lib/site_perl/5.8.3 ; export PERL5LIB
---
> PERL5LIB=/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/perl/lib/5.8.3:
/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/perl/lib/site_perl/5.8.3; export PERL5LIB
32c32
< TNS_ADMIN=${TNS_ADMIN="/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/network/admin"}; export TNS_ADMIN
---
> TNS_ADMIN=${TNS_ADMIN="/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/network/admin"}; export TNS_ADMIN
37c37
< 	LD_LIBRARY_PATH=/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/lib:
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/opmn/lib ; export LD_LIBRARY_PATH
---
>         LD_LIBRARY_PATH=/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/lib:
/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/opmn/lib; export LD_LIBRAR_PATH
39c39
< 	LD_LIBRARY_PATH=/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/lib:
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/opmn/lib:${LD_LIBRARY_PATH} ; export LD_LIBRARY_PATH
---
> 	LD_LIBRARY_PATH=/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/lib:
/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/opmn/lib:${LD_LIBRARY_PATH}; export LD_LIBRARY_PATH
45c45
< 	DYLD_LIBRARY_PATH=/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/lib:
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/opmn/lib ; export DYLD_LIBRARY_PATH
---
> 	DYLD_LIBRARY_PATH=/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/lib:
/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/opmn/lib; export DYLD_LIBRARY_PATH
47c47
< 	DYLD_LIBRARY_PATH=/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/lib:
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/opmn/lib:${DYLD_LIBRARY_PATH} ; export DYLD_LIBRARY_PATH
---
> 	DYLD_LIBRARY_PATH=/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/lib:
/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/opmn/lib:${DYLD_LIBRARY_PATH}; export DYLD_LIBRARY_PATH
52c52
< PIDFILE=/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/httpd.pid
---
> PIDFILE=/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/httpd.pid
55c55
< HTTPD=/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/bin/httpd
---
> HTTPD=/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/bin/httpd
91c91
<   if eval $HTTPD -d /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache $args
---
>   if eval $HTTPD -d /Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache $args
129c129
<       if eval $HTTPD -d /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache $args
---
>       if eval $HTTPD -d /Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache $args
149c149
<     if eval $HTTPD -d /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache -t $args > /dev/null
---
>     if eval $HTTPD -d /Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache -t $args > /del/null
261c261
<   if eval $HTTPD -d /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache -t "$args"
---
>   if eval $HTTPD -d /Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache -t "$args"
guppy:bin oracle$ 

以下、apachectlと同じディレクトリにあるが利用されているか不明なシェルスクリプトもとりあえず変更した。

guppy:bin oracle$
guppy:bin oracle$
guppy:bin oracle$ diff apxs.15 apxs
1c1
< #!/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/perl/bin/perl
---
> #!/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/perl/bin/perl
78,79c78,79
< my $CFG_PREFIX        = q(/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache);
            # substituted via APACI install
< my $CFG_SBINDIR       = q(/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/bin);
           # substituted via APACI install
---
> my $CFG_PREFIX        = q(/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache);
> my $CFG_SBINDIR       = q(/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/bin);
81,82c81,82
< my $CFG_LIBEXECDIR    = q(/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/libexec);
        # substituted via APACI install
< my $CFG_SYSCONFDIR    = q(/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/conf);
        # substituted via APACI install
---
> my $CFG_LIBEXECDIR    = q(/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/libexec);
> my $CFG_SYSCONFDIR    = q(/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/conf);
guppy:bin oracle$
guppy:bin oracle$
guppy:bin oracle$ 
guppy:bin oracle$ diff dbmmanage.15 dbmmanage
1c1
< #!/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/perl/bin/perl
---
> #!/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/perl/bin/perl
guppy:bin oracle$ 
guppy:bin oracle$
guppy:bin oracle$
guppy:bin oracle$ diff iasobf.15 iasobf
11c11
< ORACLE_HOME=/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex
---
> ORACLE_HOME=/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex
guppy:bin oracle$ 
guppy:bin oracle$
guppy:bin oracle$
guppy:bin oracle$ diff log_server_status.15 log_server_status
1c1
< #!/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/perl/bin/perl
---
> #!/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/perl/bin/perl
70c70
< $wherelog = "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/graph/";
  # Logs will be like "/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/logs/graph/19960312"
---
> $wherelog = "/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/graph/";
 # Logs will be like "/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/logs/graph/19960312"
guppy:bin oracle$ 
guppy:bin oracle$
guppy:bin oracle$
guppy:bin oracle$ diff root_sh_append.sh.15 root_sh_append.sh
3c3
< ORACLE_HOME="/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex";export ORACLE_HOME
---
> ORACLE_HOME="/Users/shared/u01/app/oracle/oracle/product/10.1.0/apex"; export ORACLE_HOME
guppy:bin oracle$ 
guppy:bin oracle$
guppy:bin oracle$
guppy:bin oracle$ diff ssl2ossl.15 ssl2ossl
8c8
< ORACLE_HOME=/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex
---
> ORACLE_HOME=Users/shared/u01/app/oracle/oracle/product/10.1.0/apex
guppy:bin oracle$ 

実行してみる（listenerおよびOracle Databaseインスタンスは起動ずみ）
尚、startohsは、apachectl startをalias定義しておいたもの（本エントリの最初の部分参照）

guppy:˜ oracle$ startohs
/Users/Shared/u01/app/oracle/oracle/product/10.1.0/apex/Apache/Apache/bin/apachectl start: httpd started
guppy:˜ oracle$ 

まずOralce HTTP Serverにアクセスしてみる・・・・OK.

APEX3.2の管理画面にアクセスしてログイン．．．．．OK
ログインしたついでに開発ユーザと作業領域を作成しておく。

開発ユーザでログインしてみる。．．．．．．OK。やった〜〜〜！！！！！　うまくいった

最後にバージョン等も確認しておく。

「Oracle 10g R2 10.2.0.4.0　for MacOSX (Intel x86-64)で未サポートとなっているOracle HTTP ServerとPL/SQL gatewayをOracle 10g R1 10.1.0.3.0 for MacOSX (PowerPC)環境から移動し、Rosettaの力でそれらを動かしてAPEX3.2を使う！。」・・・・・一件落着。。。。次回はOraTweetでも遊んでみますか．．．

---

バックナンバー

・Oracle10g R2 for MacOSX (Intel x86-64) released !!!
・Leopard de Oracle10g release 2 (Intel x86-64)
・Leopard de Oracle10g R2 (Intel x86-64) #1
・Leopard de Oracle10g R2 (Intel x86-64) #2
・Leopard de Oracle10g R2 (Intel x86-64) #3 （ちょいと寄り道）
・Leopard de Oracle10g R2 (Intel x86-64) #4 （Companion CD installation）
・Leopard de Oracle10g R2 (Intel x86-64) #5 （dbstart and dbshut does not work!! But....）
・Leopard de Oracle10g R2 (Intel x86-64) #6 （onsがバグっている？件..）
・Leopard de Oracle10g R2 (Intel x86-64) #7 (iSQL*Plusのメッセージがものすごく怖い件）
・Leopard de Oracle10g R2 (Intel x86-64) #8 - (APEX3.2と遊ぶ #1）
・Leopard de Oracle10g R2 (Intel x86-64) #9 - (APEX3.2と遊ぶ #2）
・Leopard de Oracle10g R2 (Intel x86-64) #10 (APEX3.2と遊ぶ #3）
・Leopard de Oracle10g R2 (Intel x86-64) #11 (APEX3.2と遊ぶ #4）
・Leopard de Oracle10g R2 (Intel x86-64) #12 (APEX3.2と遊ぶ #5）
・Leopard de Oracle10g R2 (Intel x86-64) #13 (APEX3.2と遊ぶ #6）
・Leopard de Oracle10g R2 (Intel x86-64) #14 (APEX3.2と遊ぶ #7）
・Leopard de Oracle10g R2 (Intel x86-64) #15 (APEX3.2と遊ぶ #8）
・Leopard de Oracle10g R2 (Intel x86-64) #16 (APEX3.2と遊ぶ #9）
・Leopard de Oracle10g R2 (Intel x86-64) #17 (APEX3.2と遊ぶ #10）

Leopard de Oracle10g R2 (Intel x86-64) #17 (APEX3.2と遊ぶ #10）

Oracle10g R2 10.2.0.4.0 for MacOSX (Intel x68-64)でAPEX3.2と遊ぶの第九話。

Intel版MacへOracle HTTP ServerとPL/SQL gatewayをORACLE_HOMEごと移動するための環境作りとしてPowerPC上でOracle 10g R1 10.1.0.3.0 + Oracle HTTP Server + HTMLDB 1.5をインストール及び構成する。のづづき。
前回、HTMLDB 1.5の構成でエラーが発生したが今回はそれを解決後、再実行してHTMLDBのログイン画面にアクセスするまで

発生したエラーを確認すると、前々回の場合と同様にjavaへのパスがおかしなことになってる。

--------------------------------------
次のConfiguration Assistantが正常に完了していません。これらのアシスタントは、製品を完全に構成するため、完了する必要があります。
ファイル/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/cfgtoollogs/configToolCommandsを実行して、
スキップまたは失敗したすべてのConfiguration Assistantを再実行します。
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/jdk/jre/bin/java 
-classpath /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/marvel/jlib/htmlDBConfigClasses.jar:
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/jdbc/lib/classes12.jar:
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/jdk/jre/lib/rt.jar:
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/jlib/ojmisc.jar:
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/oui/jlib/OraInstaller.jar: htmlDBConfig 
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex 
localhost 1521 tiger.macdeoracle.info SYSAUX * 保護された値。ログは取られません。
 * * 保護された値。ログは取られません。 * 
en,ja (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=tiger.macdeoracle.info))) 
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/marvel
--------------------------------------

上記赤太字部分を実行してみると・・・・

G5Server:˜ oracle$ /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/jdk/jre/bin/java
-su: /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/jdk/jre/bin/java: No such file or directory
G5Server:˜ oracle$          

javaが見えてないね。細かく見ていくとシンボリックリンクjreが原因。ただ前々回のようにconfigToolCommandsを変更して再実行することはできない。
理由はconfigToolCommands内に全てのパラメータが記録されていない（「保護された値。ログは取られません。」となっている部分があるから．．．）

ということでjavaへパスが通るように修正・・・・・
Oracle HTTP ServerをインストールしたORACLE_HOME/jdkへ移動してシンボリックリンクjreを作り直す。

G5Server:˜ oracle$ cd　/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/jdk
drwxr-xr-x   42 oracle  oinstall  1428 May 17 12:22 bin
lrwxrwxr-x    1 oracle  oinstall    26 May 17 12:22 include -> /Library/Java/Home/include
lrwxrwxr-x    1 oracle  oinstall    22 May 17 12:22 jre -> /Library/Java/Home/jre
drwxr-xr-x   38 oracle  oinstall  1292 May 17 12:22 lib
lrwxrwxr-x    1 oracle  oinstall    22 May 17 12:22 man -> /Library/Java/Home/man
G5Server:˜/u01/app/oracle/product/10.1.0/apex/jdk oracle$ rm jre
G5Server:˜/u01/app/oracle/product/10.1.0/apex/jdk oracle$ ln -s /System/Library/Frameworks/JavaVM.framework/Home jre
G5Server:˜/u01/app/oracle/product/10.1.0/apex/jdk oracle$ ll
total 24
drwxr-xr-x   42 oracle  oinstall  1428 May 17 12:22 bin
lrwxrwxr-x    1 oracle  oinstall    26 May 17 12:22 include -> /Library/Java/Home/include
lrwxr-xr-x    1 oracle  oinstall    48 May 17 12:58 jre -> /System/Library/Frameworks/JavaVM.framework/Home
drwxr-xr-x   38 oracle  oinstall  1292 May 17 12:22 lib
lrwxrwxr-x    1 oracle  oinstall    22 May 17 12:22 man -> /Library/Java/Home/man
G5Server:˜/u01/app/oracle/product/10.1.0/apex/jdk oracle$ 

次Oracle HTTP ServerをインストールしたORACLE_HOME/oui/binへ移動後、OUIを起動。HTMLDBだけを再インストール、構成しちゃえば解決！！（これが嫌な場合はJDK1.4.2か1.5をデフォルトにしておいた方が無難だと思う。（但し、それでこの問題が再現しなくなるか確認したわけではありません。）

また、念には念ということでJAVA_HOME環境変数へもシンボリックリンクjreへ設定したパスを設定しておいた。JAVA_HOMEの設定が必要なのかどうか？　という点に関して、ちょいとヤッツケモードだったので本当に必要なのかどうか確認していません。m(_ _)m

G5Server:˜/u01/app/oracle/product/10.1.0/apex/oui/bin oracle$ pwd
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/oui/bin
G5Server:˜/u01/app/oracle/product/10.1.0/apex/oui/bin oracle$ ll
total 336
-rwxr-xr-x    1 oracle  oinstall     412 May 17 12:22 addNode.sh
-rwxr-xr-x    1 oracle  oinstall   20576 Aug 17  2004 lsnodes
drwxr-xr-x   12 oracle  oinstall     408 May 17 12:22 resource
-rwxr-xr-x    1 oracle  oinstall  136524 Aug 17  2004 runInstaller
-rwxr-xr-x    1 oracle  oinstall     105 May 17 12:22 runInstaller.sh
G5Server:˜/u01/app/oracle/product/10.1.0/apex/oui/bin oracle$ export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home
G5Server:˜/u01/app/oracle/product/10.1.0/apex/oui/bin oracle$ ./runInstaller & 
[1] 7026
G5Server:˜/u01/app/oracle/product/10.1.0/apex/oui/bin oracle$ Starting Oracle Universal Installer...
No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2009-05-17_01-26-05PM. 
Please wait ...Oracle Universal Installer, バージョン 10.1.0.3.0 製品版
Copyright (C) 1999, 2004, Oracle. All rights reserved.

Executing  install_name_tool...
Done Executing  install_name_tool...

Oracle HTTP Serverにアクセスしてみると・・・OK.うまくいってる。


HTML DBにアクセスしてみる・・・OK .準備完了。

[1]+  Done                    ./runInstaller
G5Server:˜/u01/app/oracle/product/10.1.0/apex/oui/bin oracle$ 
G5Server:˜/u01/app/oracle/product/10.1.0/apex/oui/bin oracle$ unset JAVA_HOME
G5Server:˜/u01/app/oracle/product/10.1.0/apex/oui/bin oracle$ 

うまくいった。わははは！

さてPowerMac上での最後の作業は、Oracle HTTP Server+HTMLDBをインストールしたORACLE_HOMEごとIntel Macへ移動する前にmarvel.confのPlsqlDatabasePasswordを再設定しておきます。（OUIで設定したHTML DBのパスワードとIntel MacにインストールしたAPEX3.2のパスワードを同じパスワードにすればこの作業は不要だと思われます。また、パスワードが分からなくなった場合でもAPEX3.2のパスワードを再設定後、以下の方法でmarvel.confのPlsqlDatabasePasswordを再設定、暗号化すれば解決できます。）

Oracle HTTP Server+HTMLDBをインストールしたORACLE_HOME/Apache/modplsql/confに移動して．．．．
（ちなみに、Oracle HTTP Serverはdads.confでもmarvel.confでも使えるようになっているが、HTML DBの構成情報はmarvel.confに書き込まれるためmarvel.confを編集している。）

G5Server:˜/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf oracle$ pwd 
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf
G5Server:˜/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf oracle$ cp dads.conf dads.conf.org
G5Server:˜/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf oracle$ cp marvel.conf marvel.conf.org
G5Server:˜/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf oracle$ cp marvel.conf dads.conf
G5Server:˜/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf oracle$ export ORACLE_HOME=/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex
G5Server:~˜u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf oracle$ perl dadTool.pl -o
----------------------------------------------------------------------------
Error : Cannot invoke utility 'dadobf'
Reason: The environment setting for PATH/LD_LIBRARY_PATH is not setup to load
        the required libraries.
Action: Verify the environment settings needed for running this script


----------------------------------------------------------------------------
Hint: Use the '-h' option to get details on how to invoke the script
G5Server:˜/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf oracle$ export PATH=$ORACLE_HOME:bin:.:$PATH     
G5Server:˜/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf oracle$ perl dadTool.pl -o

Information
----------------------------------------------------------------------------
Backed up older dads.conf as /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf/dads.conf.orig.2009-05-17_19-09

All passwords successfully obfuscated. New obfuscations : 0
G5Server:˜/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf oracle$ 
Information
----------------------------------------------------------------------------
Backed up older dads.conf as /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf/dads.conf.orig.2009-05-17_19-11

All passwords successfully obfuscated. New obfuscations : 1
G5Server:˜/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf oracle$ 
G5Server:˜/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf oracle$ mv dads.conf marvel.conf
G5Server:˜/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf oracle$ mv dads.conf.org dads.conf
G5Server:˜/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf oracle$ diff marvel.conf.org marvel.conf
8c8
<                PlsqlDatabasePassword      apex
---
>                PlsqlDatabasePassword      @BTpCAhnG7HjcGKTr0ns63KI= 
G5Server:˜/u01/app/oracle/product/10.1.0/apex/Apache/modplsql/conf oracle$ 

Oracle HTTP ServerとHTML DB(関連するPL/SQLパッケージを除く）のORACLE_HOMEごとIntel Macへの移動準備完了。Rosettaの力を借りる。To be continued!

---

バックナンバー

・Oracle10g R2 for MacOSX (Intel x86-64) released !!!
・Leopard de Oracle10g release 2 (Intel x86-64)
・Leopard de Oracle10g R2 (Intel x86-64) #1
・Leopard de Oracle10g R2 (Intel x86-64) #2
・Leopard de Oracle10g R2 (Intel x86-64) #3 （ちょいと寄り道）
・Leopard de Oracle10g R2 (Intel x86-64) #4 （Companion CD installation）
・Leopard de Oracle10g R2 (Intel x86-64) #5 （dbstart and dbshut does not work!! But....）
・Leopard de Oracle10g R2 (Intel x86-64) #6 （onsがバグっている？件..）
・Leopard de Oracle10g R2 (Intel x86-64) #7 (iSQL*Plusのメッセージがものすごく怖い件）
・Leopard de Oracle10g R2 (Intel x86-64) #8 - (APEX3.2と遊ぶ #1）
・Leopard de Oracle10g R2 (Intel x86-64) #9 - (APEX3.2と遊ぶ #2）
・Leopard de Oracle10g R2 (Intel x86-64) #10 (APEX3.2と遊ぶ #3）
・Leopard de Oracle10g R2 (Intel x86-64) #11 (APEX3.2と遊ぶ #4）
・Leopard de Oracle10g R2 (Intel x86-64) #12 (APEX3.2と遊ぶ #5）
・Leopard de Oracle10g R2 (Intel x86-64) #13 (APEX3.2と遊ぶ #6）
・Leopard de Oracle10g R2 (Intel x86-64) #14 (APEX3.2と遊ぶ #7）
・Leopard de Oracle10g R2 (Intel x86-64) #15 (APEX3.2と遊ぶ #8）
・Leopard de Oracle10g R2 (Intel x86-64) #16 (APEX3.2と遊ぶ #9）

Leopard de Oracle10g R2 (Intel x86-64) #16 (APEX3.2と遊ぶ #9）

Oracle10g R2 10.2.0.4.0 for MacOSX (Intel x68-64)でAPEX3.2と遊ぶの第九話。

Intel版MacへOracle HTTP ServerとPL/SQL gatewayをORACLE_HOMEごと移動するための環境作りとしてPowerPC上でOracle 10g R1 10.1.0.3.0 + Oracle HTTP Server + HTMLDB 1.5をインストール及び構成する。のづづき。
CompanionCDからOracle HTTP ServerとHTMLDB（現在はAPEX)をインストール、構成しちゃいます。

OTNからOracle 10g R1 10.1.0.3.0 for MacOSX(PowerPC)のCompanion CDをダウンロード、解凍。解凍後に作成されるDisk1ディレクトリへ移動しOUIによるインストール、構成を行います。

G5Server:˜ oracle$ cd /Volumes/DiscusWork/temp/Disk1/ 
G5Server:/Volumes/DiscusWork/temp/Disk1 oracle$ ll
total 24
drwxr-xr-x   15 oracle  oinstall   510 May 16 23:34 doc
drwxr-xr-x    7 oracle  oinstall   238 May 16 23:34 fonts
drwxr-xr-x   12 oracle  oinstall   408 May 16 23:34 install
-rwxr-xr-x    1 oracle  oinstall  1259 Dec 17  2004 runInstaller
drwxr-xr-x   15 oracle  oinstall   510 May 16 23:36 stage
-rwxr-xr-x    1 oracle  oinstall  4188 Dec 17  2004 welcome.htm
G5Server:/Volumes/DiscusWork/temp/Disk1 oracle$ ./runInstaller &
[1] 5831
G5Server:/Volumes/DiscusWork/temp/Disk1 oracle$ Starting Oracle Universal Installer...
No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.
・・・・以下略・・・・

以下、OUI各画面のスナップショット。インストール構成が今回のテーマではないのでポイントになる箇所以外解説はしていません。（過去の記事なども参考にしてみてください。）







ちなみに、インストールするORACLE_HOMEは他のDatabase等とは異なるディレクトリにするところがポイントですよん。








HTML DBのパスワードはIntel MacでインストールしたAPEX3.2で設定予定のパスワード（現時点では未設定）と同じにしておくと楽です。（異なっても問題はないです。）
それ以外の項目はこのデータベースのインストールで設定したりした値やパスワードです。
HTML DB(APEX）はSYSAUX以外の表領域でもいいですが、今回はSYSAUX以外にする必要はないのでSYSAUXにしてあります。






HTML DB Configuration Assistantでエラーが発生してますが、あとで再実行するのでここでは「OK」ボタンクリック後、エラーを無視してインストールを続行します。




お約束のroot.shの実行です。指示された場所にあるroot.shをrootユーザで実行します。が・・・・以前とは違いちょっとしたエラーが・・・・


お約束のroot.shを実行したら・・・・エラーですか・・・・
root_sh_append.shの該当行を見てみると・・・chownとchmodをfull path指定が間違っていたので修正。

G5Server:˜/u01/app/oracle/product/10.1.0/apex oracle$ sudo sh
Password:
sh-2.05b# /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/root.sh
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/
Apache/bin/root_sh_append.sh: line 7: /usr/bin/chown: No such file or directory
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/
Apache/bin/root_sh_append.sh: line 8: /usr/bin/chmod: No such file or directory
Running Oracle10 root.sh script...
¥nThe following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex

Enter the full pathname of the local bin directory: [/usr/local/bin]: 

The file "dbhome" already exists in /usr/local/bin.  Overwrite it? (y/n) [n]:n
The file "oraenv" already exists in /usr/local/bin.  Overwrite it? (y/n) [n]:n
The file "coraenv" already exists in /usr/local/bin.  Overwrite it? (y/n) [n]:n

Adding entry to /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.
sh-2.05b# 
sh-2.05b# which chmod
/bin/chmod
sh-2.05b# which chown
/usr/sbin/chown
sh-2.05b#
sh-2.05b#

root_sh_append.shの修正内容

sh-2.05b#
sh-2.05b# vi /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/bin/root_sh_append.sh
sh-2.05b# diff /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/bin/root_sh_append.sh.org
          /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/Apache/Apache/bin/root_sh_append.sh  
7,8c7,8
<    /usr/bin/chown root $SSOMIGRATE
<    /usr/bin/chmod 6750 $SSOMIGRATE
---
>    chown root $SSOMIGRATE
>    chmod 6750 $SSOMIGRATE
sh-2.05b#

root.shを再実行。（こんどは上手く行った）

sh-2.05b#
sh-2.05b#
sh-2.05b# /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex/root.sh
Running Oracle10 root.sh script...
¥nThe following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/apex

Enter the full pathname of the local bin directory: [/usr/local/bin]: 
The file "dbhome" already exists in /usr/local/bin.  Overwrite it? (y/n) [n]:n
The file "oraenv" already exists in /usr/local/bin.  Overwrite it? (y/n) [n]:n
The file "coraenv" already exists in /usr/local/bin.  Overwrite it? (y/n) [n]:n

Adding entry to /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.
sh-2.05b# 

root.shを実行したらOUIを終了しておわり。





以前は発生していなかったのですが、HTMLDB Configuration Assistantで問題が発生しました。原因は前々回と同じくJavaSE6.0 Developer Preview 1をデフォルトにしていることが影響しているようです。ということで解決方法なども含めて、To be continued.

---

バックナンバー

・Oracle10g R2 for MacOSX (Intel x86-64) released !!!
・Leopard de Oracle10g release 2 (Intel x86-64)
・Leopard de Oracle10g R2 (Intel x86-64) #1
・Leopard de Oracle10g R2 (Intel x86-64) #2
・Leopard de Oracle10g R2 (Intel x86-64) #3 （ちょいと寄り道）
・Leopard de Oracle10g R2 (Intel x86-64) #4 （Companion CD installation）
・Leopard de Oracle10g R2 (Intel x86-64) #5 （dbstart and dbshut does not work!! But....）
・Leopard de Oracle10g R2 (Intel x86-64) #6 （onsがバグっている？件..）
・Leopard de Oracle10g R2 (Intel x86-64) #7 (iSQL*Plusのメッセージがものすごく怖い件）
・Leopard de Oracle10g R2 (Intel x86-64) #8 - (APEX3.2と遊ぶ #1）
・Leopard de Oracle10g R2 (Intel x86-64) #9 - (APEX3.2と遊ぶ #2）
・Leopard de Oracle10g R2 (Intel x86-64) #10 (APEX3.2と遊ぶ #3）
・Leopard de Oracle10g R2 (Intel x86-64) #11 (APEX3.2と遊ぶ #4）
・Leopard de Oracle10g R2 (Intel x86-64) #12 (APEX3.2と遊ぶ #5）
・Leopard de Oracle10g R2 (Intel x86-64) #13 (APEX3.2と遊ぶ #6）
・Leopard de Oracle10g R2 (Intel x86-64) #14 (APEX3.2と遊ぶ #7）
・Leopard de Oracle10g R2 (Intel x86-64) #15 (APEX3.2と遊ぶ #8）

Leopard de Oracle10g R2 (Intel x86-64) #15 (APEX3.2と遊ぶ #8）

Oracle10g R2 10.2.0.4.0 for MacOSX (Intel x68-64)でAPEX3.2と遊ぶの第八話。

Intel版MacへOracle HTTP ServerとPL/SQL gatewayをORACLE_HOMEごと移動するための環境作りとしてPowerPC上でOracle 10g R1 10.1.0.3.0 + Oracle HTTP Server + HTMLDB 1.5をインストール及び構成する。のづづき。
dbcaでデータベースインスタンスを作っちゃいます。Oracle10g R1 10.1.0.3.0 for MacOSXをMacOSX Tigerで動作させるためのお約束の作業から開始！

OTNからダウンロードできるOracle 10g R1 10.1.0.3.0 for MacOSX(PowerPC)はMacOSX Tiger以降ではdbcaがこけて起動しないのでUS OTNのフォーラムでもおなじみの以下の方法で解決する。

G5Server:˜ oracle$ cd $ORACLE_HOME/lib
G5Server:˜/u01/app/oracle/product/10.1.0/tiger/lib oracle$ mv libnnz10.dylib libnnz10.dylib.org
G5Server:˜/u01/app/oracle/product/10.1.0/tiger/lib oracle$ relink all
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/bin/genclntsh
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/lib/nautab.o

・・・・中略・・・・

Enterprise Manager native components relinked
IMPORTANT NOTE: To complete this Install/upgrade, please login as root and
                execute the root.sh script.
G5Server:˜/u01/app/oracle/product/10.1.0/tiger/lib oracle$ mv libnnz10.dylib.org libnnz10.dylib
G5Server:˜/u01/app/oracle/product/10.1.0/tiger/lib oracle$ cd
G5Server:˜ oracle$

relinkが済んだらdbcaを起動してデータベースを作成。

G5Server:˜ oracle$ dbca &
[1] 5600
G5Server:˜ oracle$ 

以下dbcaの各画面。dbcaの使い方は今回のメインネタじゃないので各画面毎の解説はしていません。Tiger Server de Oracle10gやマニュアルを参考にしてくださいね。）

データベースが作成できたら、リスナーの状態を確認してデータベースインスタンスの起動を確認！

G5Server:˜ oracle$ lsnrctl status

LSNRCTL for MacOS X Server: Version 10.1.0.3.0 - Production on 17-5月 -2009 12:06:27

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

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=g5server)(PORT=1521)))に接続中
リスナーのステータス
------------------------
別名                      LISTENER
バージョン                TNSLSNR for MacOS X Server: Version 10.1.0.3.0 - Production
開始日                    17-5月 -2009 11:46:47
稼働時間                  0 日 0 時間 19 分 40 秒
トレース・レベル          off
セキュリティ              ON: Local OS Authentication
SNMP                      OFF
パラメータ・ファイル      /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/network/admin/listener.ora
ログ・ファイル            /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/network/log/listener.log
リスニング・エンドポイントのサマリー...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=g5server)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=g5server)(PORT=8080))(Presentation=HTTP)(Session=RAW))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=g5server)(PORT=2100))(Presentation=FTP)(Session=RAW))
サービスのサマリー...
サービス"PLSExtProc"には、1件のインスタンスがあります。
  インスタンス"PLSExtProc"、状態UNKNOWNには、このサービスに対する1件のハンドラがあります...
サービス"tiger.macdeoracle.info"には、1件のインスタンスがあります。
  インスタンス"tiger"、状態READYには、このサービスに対する1件のハンドラがあります...
サービス"tigerXDB.macdeoracle.info"には、1件のインスタンスがあります。
  インスタンス"tiger"、状態READYには、このサービスに対する1件のハンドラがあります...
コマンドは正常に終了しました。
G5Server:˜ oracle$ sqlplus /nolog

SQL*Plus: Release 10.1.0.3.0 - Production on 日 5月 17 12:06:32 2009

Copyright (c) 1982, 2004, Oracle.  All rights reserved.

SQL> conn sys@tiger as sysdba
パスワードを入力してください: 
接続されました。
SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - Prod
PL/SQL Release 10.1.0.3.0 - Production
CORE    10.1.0.3.0      Production
TNS for MacOS X Server: Version 10.1.0.3.0 - Production
NLSRTL Version 10.1.0.3.0 - Production

SQL> col comp_name for a50
SQL> set linesize 132
SQL> select comp_name,version,status from dba_registry;

COMP_NAME                                          VERSION                        STATUS
-------------------------------------------------- ------------------------------ -----------
Oracle Database Catalog Views                      10.1.0.3.0                     VALID
Oracle Database Packages and Types                 10.1.0.3.0                     VALID
Oracle Workspace Manager                           10.1.0.2.0                     VALID
JServer JAVA Virtual Machine                       10.1.0.3.0                     VALID
Oracle XDK                                         10.1.0.3.0                     VALID
Oracle Database Java Packages                      10.1.0.3.0                     VALID
Oracle Expression Filter                           10.1.0.3.0                     VALID
Oracle interMedia                                  10.1.0.3.0                     VALID
Oracle Data Mining                                 10.1.0.3.0                     VALID
Oracle Text                                        10.1.0.3.0                     VALID
Oracle XML Database                                10.1.0.3.0                     VALID
OLAP Analytic Workspace                            10.1.0.3.0                     VALID
Oracle OLAP API                                    10.1.0.3.0                     INVALID
OLAP Catalog                                       10.1.0.3.0                     VALID
Spatial                                            10.1.0.3.0                     VALID
Oracle Ultra Search                                10.1.0.3.0                     VALID
Oracle Enterprise Manager                          10.1.0.3.0                     VALID

17行が選択されました。

SQL> 
SQL> select tablespace_name from dba_tablespaces;

TABLESPACE_NAME
------------------------------
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS

SQL> 

次回は当時HTMLDBと呼ばれていたAPEXとOracle HTTP ServerをPowerMac上でインストール、構成しちゃいます。

今回はここまで、To be continued.

---

バックナンバー

・Oracle10g R2 for MacOSX (Intel x86-64) released !!!
・Leopard de Oracle10g release 2 (Intel x86-64)
・Leopard de Oracle10g R2 (Intel x86-64) #1
・Leopard de Oracle10g R2 (Intel x86-64) #2
・Leopard de Oracle10g R2 (Intel x86-64) #3 （ちょいと寄り道）
・Leopard de Oracle10g R2 (Intel x86-64) #4 （Companion CD installation）
・Leopard de Oracle10g R2 (Intel x86-64) #5 （dbstart and dbshut does not work!! But....）
・Leopard de Oracle10g R2 (Intel x86-64) #6 （onsがバグっている？件..）
・Leopard de Oracle10g R2 (Intel x86-64) #7 (iSQL*Plusのメッセージがものすごく怖い件）
・Leopard de Oracle10g R2 (Intel x86-64) #8 - (APEX3.2と遊ぶ #1）
・Leopard de Oracle10g R2 (Intel x86-64) #9 - (APEX3.2と遊ぶ #2）
・Leopard de Oracle10g R2 (Intel x86-64) #10 (APEX3.2と遊ぶ #3）
・Leopard de Oracle10g R2 (Intel x86-64) #11 (APEX3.2と遊ぶ #4）
・Leopard de Oracle10g R2 (Intel x86-64) #12 (APEX3.2と遊ぶ #5）
・Leopard de Oracle10g R2 (Intel x86-64) #13 (APEX3.2と遊ぶ #6）
・Leopard de Oracle10g R2 (Intel x86-64) #14 (APEX3.2と遊ぶ #7）

Leopard de Oracle10g R2 (Intel x86-64) #14 (APEX3.2と遊ぶ #7）

Oracle10g R2 10.2.0.4.0 for MacOSX (Intel x68-64)でAPEX3.2と遊ぶの第七話。

Intel版MacへOracle HTTP ServerとPL/SQL gatewayをORACLE_HOMEごと移動するための環境作りとしてPowerPC上でOracle 10g R1 10.1.0.3.0 + Oracle HTTP Server + HTMLDB 1.5をインストール及び構成する。のづづき。
Oracle 10g R1 10.1.0.3.0のインストール中netcaがコケていた。ログから原因を探ると、デフォルトのJDKをJavaSE6.0 Developer Preview 1にしちゃっているのが原因でインストール時にORACLE_HOME内に作成されるjreのシンボリックリンクが正しく作成されていない。（java2 1.4.2のjreへのシンボリックリンクを作成しようとしているみたい・・・）

というところから．．．

以下、OUIの指示に従い
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/cfgtoollogs/configToolCommandsを実行してみると、/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jdk/jre//bin/javaがNo such file or directoryとなる。
どうもシンポリックリンク先にjreが存在していない。Tiger Server de Oracle10g を試した頃はJDK1.4.2をデフォルトにしていたのでこの問題は発生しなかったがJavaSE6.0 Developer Preview 1に変更してある影響なんだろう。

G5Server:˜ oracle$ /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/cfgtoollogs/configToolCommands
Oracle Net Configuration Assistant
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/cfgtoollogs/configToolCommands: line 2: 
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jdk/jre//bin/java: No such file or directory
G5Server:˜ oracle$

ということで、/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jdk/jre//bin/javaの部分をjavaに書き換えて再実行すればOK。

G5Server:/u01/app/oracle/product/10.1.0/tiger oracle$ 
--------------------------------------
次のConfiguration Assistantが正常に完了していません。これらのアシスタントは、製品を完全に構成するため、完了する必要があります。
ファイル/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/cfgtoollogs/configToolCommandsを実行して、
スキップまたは失敗したすべてのConfiguration Assistantを再実行します。
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jdk/jre//bin/java    
-Duser.dir=/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/network/jlib 
-classpath /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jdk/jre//lib/i18n.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jdk/jre//lib/rt.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/ewt3.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/ewtcompat-3_3_15.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/netcfg.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/network/jlib/netcam.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/network/jlib/netca.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/help4.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/jewt4.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/oracle_ice.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/share.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/swingall-1_1_1.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/srvmhas.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/srvm.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/network/tools
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/ldapjclnt9.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/ldapjclnt10.jar 
oracle.net.ca.NetCA /orahome /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger 
/orahnam OraDb10g_tiger /instype custom /inscomp client,oraclenet,javavm,server 
/insprtcl tcp /cfg local /authadp NO_VALUE /nodeinfo NO_VALUE /responseFile 
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/network/install/netca_typ.rsp
--------------------------------------

G5Server:˜ oracle$ 
G5Server:˜ oracle$ cat /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/cfgtoollogs/configToolCommands
G5Server:˜ oracle$ java 
-Duser.dir=/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/network/jlib 
-classpath /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jdk/jre//lib/i18n.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jdk/jre//lib/rt.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/ewt3.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/ewtcompat-3_3_15.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/netcfg.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/network/jlib/netcam.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/network/jlib/netca.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/help4.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/jewt4.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/oracle_ice.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/share.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/swingall-1_1_1.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/srvmhas.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/srvm.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/network/tools
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/ldapjclnt9.jar
:/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/jlib/ldapjclnt10.jar 
oracle.net.ca.NetCA /orahome /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger 
/orahnam OraDb10g_tiger /instype custom /inscomp client,oraclenet,javavm,server 
/insprtcl tcp /cfg local /authadp NO_VALUE /nodeinfo NO_VALUE /responseFile 
/Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/network/install/netca_typ.rsp
コマンドライン引数の解析:
    パラメータ "orahome" = /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger
    パラメータ "orahnam" = OraDb10g_tiger
    パラメータ "instype" = custom
    パラメータ "inscomp" = client,oraclenet,javavm,server
    パラメータ "insprtcl" = tcp
    パラメータ "cfg" = local
    パラメータ "authadp" = NO_VALUE
    パラメータ "nodeinfo" = NO_VALUE
    パラメータ "responsefile" = /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/network/install/netca_typ.rsp
コマンドライン引数の解析が終了しました。
Oracle Net Servicesの構成:
デフォルトのローカル・ネーミング構成が完了しました。
次のリスナーを構成中:LISTENER
リスナーの構成が完了しました。
Oracle Net Listenerの起動:
    リスナーの制御の実行: 
      /Volumes/Discus/4oracle/oracle/u01/app/oracle/product/10.1.0/tiger/bin/lsnrctl start LISTENER
    リスナーの制御が完了しました。
    リスナーの起動に成功しました。
プロファイルの構成が完了しました。
プロファイルの構成が完了しました。
デフォルトのローカル・ネーミング構成が完了しました。
    作成されたネット・サービス名: tiger
Oracle Net Servicesの構成に成功しました。終了コードは次のとおりです。0
G5Server:˜ oracle$ 
G5Server:˜ oracle$ 

以下、netcaでlistenerとその構成中のスナップショット。（細かな解説は入れてませんのであしからず。）

次回はdbcaを利用したデータベース作成。

今回はここまで、To be continued.

---

バックナンバー

・Oracle10g R2 for MacOSX (Intel x86-64) released !!!
・Leopard de Oracle10g release 2 (Intel x86-64)
・Leopard de Oracle10g R2 (Intel x86-64) #1
・Leopard de Oracle10g R2 (Intel x86-64) #2
・Leopard de Oracle10g R2 (Intel x86-64) #3 （ちょいと寄り道）
・Leopard de Oracle10g R2 (Intel x86-64) #4 （Companion CD installation）
・Leopard de Oracle10g R2 (Intel x86-64) #5 （dbstart and dbshut does not work!! But....）
・Leopard de Oracle10g R2 (Intel x86-64) #6 （onsがバグっている？件..）
・Leopard de Oracle10g R2 (Intel x86-64) #7 (iSQL*Plusのメッセージがものすごく怖い件）
・Leopard de Oracle10g R2 (Intel x86-64) #8 - (APEX3.2と遊ぶ #1）
・Leopard de Oracle10g R2 (Intel x86-64) #9 - (APEX3.2と遊ぶ #2）
・Leopard de Oracle10g R2 (Intel x86-64) #10 (APEX3.2と遊ぶ #3）
・Leopard de Oracle10g R2 (Intel x86-64) #11 (APEX3.2と遊ぶ #4）
・Leopard de Oracle10g R2 (Intel x86-64) #12 (APEX3.2と遊ぶ #5）
・Leopard de Oracle10g R2 (Intel x86-64) #13 (APEX3.2と遊ぶ #6）

Leopard de Oracle10g R2 (Intel x86-64) #13 (APEX3.2と遊ぶ #6）

Oracle10g R2 10.2.0.4.0 for MacOSX (Intel x68-64)でAPEX3.2と遊ぶの第六話。

Intel版MacへOracle HTTP ServerとPL/SQL gatewayをORACLE_HOMEごと移動するための環境作りとしてPowerPCの環境でOracle 10g R1 10.1.0.3.0 + Oracle HTTP Server + HTMLDB 1.5をインストール及び構成するところから。

MacOSX 10.4.11とJavaSE6.0 Developer Preview 1となっている事以外は、Tiger Server De Oracle10g　その６と同じである。（ちなみにMacOSXのカーネルパラメータはTiger Server De Oracle10gをやっていた当時のままなので今回の手順ではさらりと書いておくことにした。）

Oracle所有者の環境変数やカーネルパラメータはインストレーションガイドや以前のものを参考にしてみてね。

参考資料
Oracle Database 10g Release 1 (10.1) Documentation for Apple Mac OS X

ちなみに、今回の環境変数設定などは以下、あらかじめインストールするディレクトリなどは決めているので事前に設定しておいた。(MySQL関係のは気にしないでね。）

G5Server:˜ oracle$ cat .bash_profile
alias ls='ls -v'
alias ll='ls -vl'
alias startapex='$ORACLE_HOME/../apex/Apache/Apache/bin/apachectl start'
alias stopapex='$ORACLE_HOME/../apex/Apache/Apache/bin/apachectl stop'

umask 022

# oracle environment
TEMP=/tmp
TMPDIR=/tmp
ORACLE_BASE=/Volumes/Discus/4oracle/oracle/u01/app/oracle
ORACLE_HOME=$ORACLE_BASE/product/10.1.0/tiger
ORACLE_SID=tiger
NLS_LANG=Japanese_Japan.AL32UTF8
DYLD_LIBRARY_PATH=$ORACLE_HOME/lib:$ORACLE_HOME/rdbms/lib:$DYLD_LIBRARY_PATH
PATH=$ORACLE_HOME/bin:$PATH
export TEMP TMPDIR ORACLE_BASE ORACLE_HOME ORACLE_SID NLS_LANG DYLD_LIBRARY_PATH PATH

export MYSQL_HOME=/usr/local/mysql
export DATADIR=$MYSQL_HOME/data
export PATH=$MYSQL_HOME/bin:$PATH
G5Server:˜ oracle$ 

TerminalでunzipしてできるDisk1以下のrunInstallerを起動してOracledatabase 10g R1のインストール開始（Tiger Server de Oracle10gも見てね）












今回はデータベースそのものよりOracle HTTP ServerとAPEXがメインなので必要最低限のオプションだけにしてインストール時間の節約。








インストール時にデータベース作成は行わない。






お約束のroot.shの実行要求が表示されたらTerminalからrootユーザでroot.shを実行する。


Configuration Assistantの実行でnetcaの実行に失敗するが、JavaSE6.0 Developer Preview 1を利用していることが影響していると考えられる内容であったためエラーを無視してすすめる。（netcaはこの後、手動で実行すれば問題ないので。）
JDK1.4.2又はJavaSE5.0を使っているのならこのエラーには遭遇しないと（思われる）。

OracleDatabase 10g R1のインストールでTiger Server De Oracle10gの頃にはなかったエラーがnetcaの実行中に発生したがこれはJavaSE6.0 Developer Preview 1をデフォルトのJDKに設定している（詳細は次回）ことが影響しているようなのでOUIのインストールではエラーを無視し後でnetcaを手動実行する。

今回はここまで、To be continued.

---

バックナンバー

・Oracle10g R2 for MacOSX (Intel x86-64) released !!!
・Leopard de Oracle10g release 2 (Intel x86-64)
・Leopard de Oracle10g R2 (Intel x86-64) #1
・Leopard de Oracle10g R2 (Intel x86-64) #2
・Leopard de Oracle10g R2 (Intel x86-64) #3 （ちょいと寄り道）
・Leopard de Oracle10g R2 (Intel x86-64) #4 （Companion CD installation）
・Leopard de Oracle10g R2 (Intel x86-64) #5 （dbstart and dbshut does not work!! But....）
・Leopard de Oracle10g R2 (Intel x86-64) #6 （onsがバグっている？件..）
・Leopard de Oracle10g R2 (Intel x86-64) #7 (iSQL*Plusのメッセージがものすごく怖い件）
・Leopard de Oracle10g R2 (Intel x86-64) #8 - (APEX3.2と遊ぶ #1）
・Leopard de Oracle10g R2 (Intel x86-64) #9 - (APEX3.2と遊ぶ #2）
・Leopard de Oracle10g R2 (Intel x86-64) #10 (APEX3.2と遊ぶ #3）
・Leopard de Oracle10g R2 (Intel x86-64) #11 (APEX3.2と遊ぶ #4）
・Leopard de Oracle10g R2 (Intel x86-64) #12 (APEX3.2と遊ぶ #5）

Leopard de Oracle10g R2 (Intel x86-64) #12 (APEX3.2と遊ぶ #5）

随分間が空いてしまったが、Oracle10g R2 10.2.0.4.0 for MacOSX (Intel x68-64)でAPEX3.2と遊ぶの第五話。

前回PowerMac G5へインストールしたOracle HTTP ServerとPL/SQL GatewayをそのままIntel Macへ移植移動しただけでOracle HTTP Server+PL/SQL gateway+Oracle Application Express3.2が動作した結果だけをお見せしたが、今回はその手順を。

前提としてIntel Mac以外に、PowerPC版のMacとMacOSX Tiger 10.4.11(ServerでもClient版でも可。）が必要。おそらく、PowerPC版MacはPantherでも可能（だと思う）。

手順の概要

PowerMac G5 (MacOSX Tiger Server 10.4.11)へ、Oracle 10g R1 10.1.0.3.0 for MacOSX (PowerPC版）のDatabase及び、CompanionCDよりOracle HTTP ServerとAPEX（当時はHTMLDBと呼ばれていた）をインストール及び構成（起動するところまで確認）後、Oracle HTTP Server用のORACLE_HOMEディレクトリをまるごとOracle 10g R2 10.2.0.4.0 for MacOSX(Intel x86-64)及びAPEX3.2インストール済みのMacBook Pro - MacOSX Leopard 10.5.6へ移動しコンフィグファイルを書き換えIntel Mac上で未サポート扱いのOracle HTTP Server + PL/SQL gateway + APEX3.2を使えるようにする。

まず、PowerMacの情報

gccは3.3を使うのでそれ以外の場合はgcc_selectで変更する。また、javaに関してはOracle10g R1のリリース当時はJDK1.4.2だったが、以前デフォルトをJavaSE6.0 Developer Preview 1へ切り替えたままで行うことにした。PowerPC版Macの場合JavaSE6.0は正式にリリースされていないのでJavaSE5.0までのほうが問題は少ない。。はずだが。

G5Server:˜ oracle$ sw_vers
ProductName:    Mac OS X Server
ProductVersion: 10.4.11
BuildVersion:   8S169
G5Server:˜ oracle$ 
G5Server:˜ oracle$ uname -a
Darwin G5Server 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; 
root:xnu-792.24.17˜1/RELEASE_PPC Power Macintosh powerpc
G5Server:˜ oracle$
G5Server:˜ oracle$ 
G5Server:˜ oracle$ /usr/sbin/system_profiler SPHardwareDataType | grep CPU   
      CPU Type: PowerPC G5  (3.1)
      Number Of CPUs: 2
      CPU Speed: 2.7 GHz
      L2 Cache (per CPU): 512 KB
G5Server:˜ oracle$
G5Server:˜ oracle$
G5Server:˜ oracle$ /usr/sbin/system_profiler SPApplicationsDataType | grep Xcode
    Xcode:
      Get Info String: Xcode version 2.4.1
      Location: /Developer/Applications/Xcode.app

G5Server:˜ oracle$
G5Server:˜ oracle$ gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

G5Server:˜ oracle$ 
G5Server:˜ oracle$ gcc_select -l
Available compiler versions:
3.3             3.3-fast        4.0

G5Server:˜ oracle$
G5Server:˜ oracle$ sudo gcc_select 3.3
Password:
Default compiler has been set to:
gcc version 3.3 20030304 (Apple Computer, Inc. build 1819)
G5Server:˜ oracle$
G5Server:˜ oracle$ gcc -v      
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1819)
G5Server:˜ oracle$

G5Server:˜ oracle$
G5Server:˜ oracle$ java -version
java version "1.6.0-dp"
Java(TM) SE Runtime Environment (build 1.6.0-dp-b88-34)
Java HotSpot(TM) Core VM (build 1.6.0-b88-17-release, interpreted mode)
G5Server:˜ oracle$

次に、Intel Macの情報

Oracle 10g R2 10.2.0.4.0 for MacOSX(intel x86-64)インストール時のまま。

Macintosh:˜ discus$ /usr/sbin/system_profiler SPHardwareDataType | grep -E '(Processor|Cores|Memory)'
      Processor Name: Intel Core 2 Duo
      Processor Speed: 2.2 GHz
      Number Of Processors: 1
      Total Number Of Cores: 2
      Memory: 2 GB
Macintosh:˜ discus$ 
Macintosh:˜ discus$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.5.6
BuildVersion:	9G55
Macintosh:˜ discus$ 
Macintosh:˜ discus$ uname -a
Darwin Macintosh.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 
PST 2008; root:xnu-1228.9.59˜1/RELEASE_I386 i386
Macintosh:˜ discus$ 
Macintosh:˜ discus$ gcc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5488)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Macintosh:˜ discus$ 
Macintosh:˜ discus$ java -version
java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode)
Macintosh:˜ discus$ 
Macintosh:˜ discus$ system_profiler SPApplicationsDataType | grep Xcode
    Xcode:
      Get Info String: Xcode version 3.1.1
      Location: /Developer/Applications/Xcode.app
Macintosh:˜ discus$ 

長くなるので（というより息子が風邪（フツーの）で保育園に行けない。しかも熱が３７度台になってきたので走り回ってたり私が集中できないという理由もあり）今日はここまで、次回へつづく。:)

もう、そろそろ昼寝していた息子が起きそうだ．．．相手してやらないと・・・

---

バックナンバー

・Oracle10g R2 for MacOSX (Intel x86-64) released !!!
・Leopard de Oracle10g release 2 (Intel x86-64)
・Leopard de Oracle10g R2 (Intel x86-64) #1
・Leopard de Oracle10g R2 (Intel x86-64) #2
・Leopard de Oracle10g R2 (Intel x86-64) #3 （ちょいと寄り道）
・Leopard de Oracle10g R2 (Intel x86-64) #4 （Companion CD installation）
・Leopard de Oracle10g R2 (Intel x86-64) #5 （dbstart and dbshut does not work!! But....）
・Leopard de Oracle10g R2 (Intel x86-64) #6 （onsがバグっている？件..）
・Leopard de Oracle10g R2 (Intel x86-64) #7 (iSQL*Plusのメッセージがものすごく怖い件）
・Leopard de Oracle10g R2 (Intel x86-64) #8 - (APEX3.2と遊ぶ #1）
・Leopard de Oracle10g R2 (Intel x86-64) #9 - (APEX3.2と遊ぶ #2）
・Leopard de Oracle10g R2 (Intel x86-64) #10 (APEX3.2と遊ぶ #3）
・Leopard de Oracle10g R2 (Intel x86-64) #11 (APEX3.2と遊ぶ #4）

DB2 で PL/SQL

DB2新版はPL/SQL対応、Oracleユーザーの移行狙う@ ITmedia

へぇ〜、それじゃ、昨日作ったケンブリッジ関数もDB2 9.7で動作するようになるのか〜〜。へぇ〜。mod_plsqlというかPL/SQL gatewayはどうなんだろうか？、Oracleが提供しているPL/SQLパッケージも対応しているのだろうか？　機会があったら質問しておこうっと。

できれば他のRDBMSでもやってくれるとありがたいかも．．．

PL/SQL : Write Once Run Any RDBMS なんてね。

PL/SQL de ケンブリッジ関数

先日、ケンブリッジ関数ネタを取り上げたついでなのでPL/SQLで作ってみた。
こんな感じかな。他の言語に比べるとアウェイ感が強いけど。時間があったらほかのでもやるかも．．w

ちなみに、OracleはOracle10g R2 10.2.0.4.0で、キャラクタセットはAL32UTF8

関連記事：
・ ケブンッリジ関数@ どう書く？org
・確かに“読めてしまう”コピペに2ch住人が「人間すげー」と驚く@ITmedia
・流行りのケブンリッジ関数 - JavaScript 編@IT戦記

ストアドファンクションにしてあります。

CREATE OR REPLACE FUNCTION Cambridge( iWords IN CLOB )
RETURN CLOB
IS
  words           CLOB := EMPTY_CLOB();
  word            CLOB := EMPTY_CLOB();
  nonwords        CLOB := EMPTY_CLOB();
  TYPE            t_char_table_type IS TABLE OF CHAR(1 CHAR);
  chars           t_char_table_type := t_char_table_type();
  charsInit       t_char_table_type := t_char_table_type();
  startpos        PLS_INTEGER := 1;
  endpos          PLS_INTEGER;
  l               PLS_INTEGER;
  endpos_nonwords PLS_INTEGER;
  tempwords       CLOB := EMPTY_CLOB();
  done            BOOLEAN;
  --
  FUNCTION getShuffledWord RETURN CLOB
  IS
    workCLOB CLOB := EMPTY_CLOB();
  BEGIN
    IF chars.COUNT > 0 THEN
      FOR j IN chars.FIRST..chars.LAST LOOP
        workCLOB := workCLOB || chars(j);
      END LOOP;
    END IF;
    RETURN workCLOB;
  END;
--
BEGIN
  words := iWords;
  LOOP
    endpos := REGEXP_INSTR(words, '(\s+|[[:punct:]]+|$)', startpos);
    EXIT WHEN endpos = 0;
    --
    word := DBMS_LOB.SUBSTR(words, endpos - startpos, startpos);
    chars := charsInit;
    --
    IF DBMS_LOB.getLength(word) > 3 THEN
      FOR i IN 1..DBMS_LOB.getLength(word) LOOP
        chars.EXTEND();
      END LOOP;
      chars(chars.FIRST) := DBMS_LOB.SUBSTR(word, 1, 1);
      chars(chars.LAST)  := DBMS_LOB.SUBSTR(word, 1, DBMS_LOB.getLength(word));
      --
      FOR k IN 2..DBMS_LOB.getLength(word) - 1 LOOP
          done := FALSE;
          WHILE NOT done LOOP
            l := ROUND(DBMS_RANDOM.VALUE(2, DBMS_LOB.getLength(word) - 1));
            IF chars(l) IS NULL THEN
              chars(l) := DBMS_LOB.SUBSTR(word, 1, k);
              done := TRUE;
            END IF;
          END LOOP;
      END LOOP;
      word := getShuffledWord();
    END IF;
    --
    endpos_nonwords := REGEXP_INSTR(words, '(\s+|[[:punct:]]+|$)', startpos, 1, 1);
    nonwords := DBMS_LOB.SUBSTR(words, endpos_nonwords - endpos, endpos);
    startpos := endpos + 1;
    tempwords := tempwords || word || nonwords;
  END LOOP;
  RETURN tempwords;
END;
/

あたえる文字列はテーブルに格納してあります。

SCOTT> 
SCOTT> set linesize 80
SCOTT> desc wordstable
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID					   NOT NULL NUMBER
 WORDS						    CLOB

SCOTT> set long 4000
SCOTT> set longchunk 400
SCOTT> select words from wordstable where id = 1;

WORDS
---------------------------------------------------------------------------
こんにちは みなさん おげんき ですか？ わたしは げんき です。
この ぶんしょう は いぎりす の ケンブリッジ だいがく の けんきゅう の けっか
にんげん は もじ を にんしき する とき その さしいょ と さいご の もじさえ あっていれば
じゅんばん は めちゃくちゃ でも ちゃんと よめる という けんきゅう に もとづいて
わざと もじの じゅんばん を いれかえて あります。
どうです？ ちゃんと よめちゃう でしょ？
ちゃんと よめたら はんのう よろしく

じこっう　けっか。　フツー　に　よまめす　よね？
PL/SQLをNative compileすればもっと早くなるだろうけど．．．

SCOTT> select cambridge(words) from wordstable where id = 1;

CAMBRIDGE(WORDS)
---------------------------------------------------------------------------
こちにんは みさなん おんげき ですか？ わたしは げんき です。
この ぶょんしう は いりぎす の ケブンリッジ だいがく の けゅんきう の けっか
にげんん は もじ を にしんき する とき その さしいょ と さいご の もさじえ あてっいれば
じゅんばん は めゃくちちゃ でも ちんゃと よめる という けゅんきう に もとづいて
わざと もじの じばんゅん を いかれえて あまりす。
どうです？ ちゃんと よめちゃう でしょ？
ちゃんと よためら はのんう よろしく

経過: 00:00:00.07
SCOTT> 

では、次回はLeoparde de Oracle10g R2ネタに戻るとしましょうか・・・

それにしても他の言語で書かれているの見ると随分短いよね。そういえば、Python ChallengeでもPythonなら数行なのにPL/SQL無理矢理で書いていたっけ。。そうだ誰か、PostgreSQLのPL/pgSQLとかMySQLのストアドで書くような人はいないか？なぁ〜。と呟いてみる。w (2009/5/22追記）

Leopard de Oracle10g R2 (Intel x86-64) #11 (APEX3.2と遊ぶ #4）

Oracle10g R2 10.2.0.4.0 for MacOSX (Intel x68-64)でAPEX3.2と遊ぶの第四話。

前回、Rosettaの力を借りて、PowerPC版のMacへインストールしたOracle HTTP Server + PL/SQL gatewayをIntel x86版のMacへHomeディレクトリごと移動してしまえば動作するだろう。（但し、構成ファイル等は手動で手直しする必要あり）と書いたが、試してみたところ上手く動作した。Rosetta　やっぱり、すげー！（Rosettaを作ったTransitive社はIBMに買収された。）

手順は長くなるので次回にするが、環境と動作したスナップショットを。。。。

クリックで拡大表示します。







環境

Oracle HTTP ServerとPL/SQL gatewayをインストールしたMac (PowerPC)
　---- PowerMac G5 (PowerPC G5 Dual 2.7Ghz / MacOSX Tiger Server 10.4.11)

PowerPCへインストールしたOracle HTTP ServerとPL/SQL gatewayの移動先のMac (Intel x86)
　---- MacBook Pro (Intel Core 2 Duo 2.2Ghz / MacOSX Leopard 10.5.6)

今日はここまで、次回へつづく。:)

---

バックナンバー

・Oracle10g R2 for MacOSX (Intel x86-64) released !!!
・Leopard de Oracle10g release 2 (Intel x86-64)
・Leopard de Oracle10g R2 (Intel x86-64) #1
・Leopard de Oracle10g R2 (Intel x86-64) #2
・Leopard de Oracle10g R2 (Intel x86-64) #3 （ちょいと寄り道）
・Leopard de Oracle10g R2 (Intel x86-64) #4 （Companion CD installation）
・Leopard de Oracle10g R2 (Intel x86-64) #5 （dbstart and dbshut does not work!! But....）
・Leopard de Oracle10g R2 (Intel x86-64) #6 （onsがバグっている？件..）
・Leopard de Oracle10g R2 (Intel x86-64) #7 (iSQL*Plusのメッセージがものすごく怖い件）
・Leopard de Oracle10g R2 (Intel x86-64) #8 - (APEX3.2と遊ぶ #1）
・Leopard de Oracle10g R2 (Intel x86-64) #9 - (APEX3.2と遊ぶ #2）
・Leopard de Oracle10g R2 (Intel x86-64) #10 (APEX3.2と遊ぶ #3）

Leopard de Oracle10g R2 (Intel x86-64) #10 (APEX3.2と遊ぶ #3）

Oracle10g R2 10.2.0.4.0 for MacOSX (Intel x68-64)でAPEX3.2と遊ぶの第三話。
前回まででOracle 10g R2 10.2.0.4.0 for MacOSX (Intel x86-64)へAPEX3.2日本語リソースまでインストールすることができた。今回はOracle 10g R2 10.2.0.4.0 for MacOSX (Intel x86-64)ではCompanion CDにも含まれておらずインストールすらできないOracle HTTP ServerとPL/SQL gatewayなんとかしてみる。（それさえなんとかできればAPEX3.2が使えるはず。。）
方法は幾つ考えられるが、まずは、”なんとかできるはず”と思っている根拠について書いておこうかと・・・・。

”なんとかできるはず”だと考えているのにはそれなりの理由がある。それは、Rosettaの存在。
以前、Oracle Instant Client 10g R1 for MacOSX(PPC) is running under Rosetta on MacOSX LeopardでもRosettaの力でPowerPC版のOracle Instant Client 10g R1がMacOSX Leopard (intel x86)上で動作したという記事を書いたことがあるが、今回もRosettaのお世話になれば実現できるはず！。

いくつか考えられる方法のうち、Oracle10g R1 10.1.0.3.0 for MacOSX (PowerPC)版のCompanion CDを使いMacOSX Leopard (intel x86)上でインストールするという方法は、随分前にも試したことがあるOracl10g Databaseのインストールと同様に上手く行かない。（以下、NGシーンの再現）

上記以外で確実な方法として、PowerPC版Mac上でインストール、構成までしたバイナリを、そのままIntel x86版Macへ移動して再構成（もちろん手動でね）すれば使えるようになるはず・・・・・・・。

ということで、次回へつづく。

---

バックナンバー

・Oracle10g R2 for MacOSX (Intel x86-64) released !!!
・Leopard de Oracle10g release 2 (Intel x86-64)
・Leopard de Oracle10g R2 (Intel x86-64) #1
・Leopard de Oracle10g R2 (Intel x86-64) #2
・Leopard de Oracle10g R2 (Intel x86-64) #3 （ちょいと寄り道）
・Leopard de Oracle10g R2 (Intel x86-64) #4 （Companion CD installation）
・Leopard de Oracle10g R2 (Intel x86-64) #5 （dbstart and dbshut does not work!! But....）
・Leopard de Oracle10g R2 (Intel x86-64) #6 （onsがバグっている？件..）
・Leopard de Oracle10g R2 (Intel x86-64) #7 (iSQL*Plusのメッセージがものすごく怖い件）
・Leopard de Oracle10g R2 (Intel x86-64) #8 - (APEX3.2と遊ぶ #1）
・Leopard de Oracle10g R2 (Intel x86-64) #9 - (APEX3.2と遊ぶ #2）

ちょいと迷惑だったストアドファンクション（おまけ）

す〜〜ぱ〜〜し〜〜し〜〜でぃ〜〜っ。はにかむ、せぶん！
やけに耳の残っちゃうんだよな〜。あの声とアクセント。

なんて関係ない話はおいといて。。と


以前、
ちょいと迷惑だったストアドファンクション
ちょいと迷惑だったストアドファンクション（つづき）

ということを書いていたが、ちょいと迷惑だったストアドファンクションの例外ハンドラーで問題解決の手がかりとするためログ出力が実装されていたらどうするの？　っていうこともあるのでおまけのおまけということで書いておきます。

以前の例では例外ハンドラーをバッサリ切り捨ててしまったのですが、例外ハンドラーで問題解決の手がかりとするためのログ出力�