■個人情報の利用目的
当ブログでは、メールでのお問い合わせ、ブログへのコメントの際、名前（ハンドルネーム）等の個人情報をご登録いただく場合がございます。これらの個人情報は質問に対する回答などでご連絡する場合や、スパムコメント抑止のために利用させていただくものであり、個人情報をご提供いただく際の目的以外では利用いたしません。
■個人情報の第三者への開示
当サイトでは、個人情報は適切に管理し、以下に該当する場合を除いて第三者に開示することはありません。
個人情報の開示、訂正、追加、削除、利用停止については、ご本人からの個人データの開示、訂正、追加、削除、利用停止のご希望の場合には、ご本人であることを確認させていただいた上で速やかに対応させていただきます。
■アクセス解析ツールについて
当サイトでは、Googleによるアクセス解析ツール「Googleアナリティクス」を利用しています。このGoogleアナリティクスはトラフィックデータの収集のためにCookieを使用しています。このトラフィックデータは匿名で収集されており、個人を特定するものではありません。この機能はCookieを無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。
■広告の配信について
当サイトはGoogleとAmazonの広告を配信しています。
Googleについて
Google及びGoogleのパートナー（第三者配信事業者）の提供する広告を設置しております。その広告配信にはCookieを使用し、当サイトやその他のサイトへの過去のアクセス情報に基づいて広告を配信します。
Google が広告 Cookie を使用することにより、当サイトや他のサイトにアクセスした際の情報に基づいて、Google やそのパートナーが適切な広告を表示しています。
お客様はGoogleアカウントの広告設定ページ（https://adssettings.google.com/u/0/authenticated）で、パーソナライズ広告を無効にできます。また aboutads.info のページにアクセスして頂き、パーソナライズ広告掲載に使用される第三者配信事業者のCookieを無効にできます。
その他、Googleの広告におけるCookieの取り扱い詳細については、Googleのポリシーと規約ページ（https://policies.google.com/technologies/ads）をご覧ください。
Amazonについて
AmazonはアソシエイトリンクのURLに含まれるパラメータを通じて利用者が直前に閲覧したアソシエイトサイトに関する情報などを収集し、これをアソシエイトパートナーに対する紹介料の算定、報告及び支払いに使用したり、アソシエイトパートナーによる複数のウェブサイトや商品戦略毎のパフォーマンスの分析に供したりしています。
Amazonによる個人に関する情報の取得及び取扱いに関する方針につきましてはAmazon.co.jpプライバシー規約をご覧ください。
■免責事項
当サイトからリンクやバナーなどによって他のサイトに移動された場合、移動先サイトで提供される情報、サービス等について一切の責任を負いません。当サイトのコンテンツ・情報につきまして、可能な限り正確な情報を掲載するよう努めておりますが、誤情報が入り込んだり、情報が古くなっていることもございます。当サイトに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。
■プライバシーポリシーの変更について
当サイトは、個人情報に関して適用される日本の法令を遵守するとともに、本ポリシーの内容を適宜見直しその改善に努めます。
修正された最新のプライバシーポリシーは常に本ページにて開示されます。
今年もOracle Database Connect の季節がやってきました！
昨年までの大きな会場での開催ではなく、
日本オラクル青山センターでの開催となります。
Oracle Database Connect 2018 / JPOUG告知ページ
http://www.jpoug.org/2018/03/20/odc2018
そして、私も、雛壇DBエンジニアとして参加予定です（ボケ担当？！）
皆さんと、お会いできることを楽しみにしています ：）
| 固定リンク | 0 | コメント (0) | トラックバック (0)
JPOUG主催
JPOUG> SET EVENTS 20151017
を日本オラクル青山センター 13階セミナールームで
2015年10月17日(土)13:00～17:30(開場および受付開始: 12:30)に開催します。
ハッシュタグ #JPOUG
今回は、
開発設計、チューニング関連の力セッション、インフラ関連の技セッション、入門者向けの知セッションと３本立てです。
JPOUGボードメンバーでもある渡部さん、通しで３枠！！ 知セッションを担当します！
Oracle Database 入学式のような感じになるのでしょうか？ Oracle Database初心者におすすめです。
そして、ミックさんをはじめ、JPOUG主催イベント初登場のスピーカーが多いのも今回の特徴です。
セッションの詳細は以下サイトをご覧ください。
http://www.jpoug.org/2015/09/01/setevents20151017
私は裏方ですので、うろうろしているか、受付とか、やってると思います :)
SELECT文があれば更新削除以外は、なんでもできるんじゃないかと、錯覚するほと変わってきています。
これから先も変化すると思います。（基本は同じですが。）
付いていけてますか？
まさか、Oracle Database 7.3とか、8とか8iぐらいのSELECT文で止まったままになってないでしょうか？
使いこなせてますか？
たまに、自問自答してます......
Oracle Database 7.3とOracle Database 12.1のSELECT文の文法の差をこうやってみると.....お・ど・ろ・き・ま・す・よ！！！！
| 固定リンク | 0 | コメント (0) | トラックバック (0)
当日は、予想を大きく上回るご参加、ありがとうございました。m(_ _)m エンジニアの笑顔っていいですよね。
※数日前まで風邪で体調を崩していたこもあり名刺切れしていた申し訳ありませんでした。（名刺印刷をアウトソースしないこだわり名刺というのもその理由なのですが。）
JPOUG> SET EVENTS 20120721 @ 日本オラクル青山センター でのセッション「(続)いん！、イン！、Index 大人の事情縛りのSQLチューニング」の資料を公開します。
Safari以外のブラウザではアニメーション効果はありませんが、Safari (Mac/iPad/iPhone)ではKeynote風（但し、ページ間のトランジッションなし）に表示されます。
（デモ環境は前回と同じです。）
（デモ内容は別途追加予定です。2012/7/24:デモを追加しました。）
おまけの資料(OracleとNULL)
Oracle8i SQL Reference Release 8.1.5 - Nulls
Oracle® Database SQL言語リファレンス 11gリリース2(11.2) - NULL
(2024/3/14 - html化したKeynote資料が閲覧しにくい状態になっていたので、YouTubeの動画に編集し直しました）
DEMO : 1回で２万行参照するバッチ処理
ほんとのバッチはこんなもんじゃないのは知ってますよねw.
SCOTT> @demo1_2
1 declare
2 type t_unique_id is table of tab1.unique_id%type index by pls_integer;
3 type t_non_unique_id is table of tab1.non_unique_id%type index by pls_integer;
4 unique_ids t_unique_id;
5 non_unique_ids t_non_unique_id;
6 begin
7 select
8 unique_id
9 ,non_unique_id
10 bulk collect into
11 unique_ids
12 ,non_unique_ids
13 from
14 tab1
15 where
16 unique_id between 1 and 20000
17 and is_delete = 0
18 and status_code = '00'
19 ;
20 dbms_output.put_line('rows:'||unique_ids.last);
21* end;
rows:20000
PL/SQLプロシージャが正常に完了しました。
経過: 00:00:00.75
・・・中略・・・
Plan Statistics DB/Inst: DISCUS/discus Snaps: 208-209
-> % Total DB Time is the Elapsed Time of the SQL statement divided
into the Total Database Time multiplied by 100
Stat Name Statement Per Execution % Snap
---------------------------------------- ---------- -------------- -------
Elapsed Time (ms) 699 699.0 22.4
CPU Time (ms) 310 310.0 16.3
Executions 1 N/A N/A
Buffer Gets 1,648 1,648.0 7.9
Disk Reads 1,584 1,584.0 65.0
Parse Calls 1 1.0 0.1
Rows 20,000 20,000.0 N/A
User I/O Wait Time (ms) 585 N/A N/A
Cluster Wait Time (ms) 0 N/A N/A
Application Wait Time (ms) 0 N/A N/A
Concurrency Wait Time (ms) 0 N/A N/A
Invalidations 0 N/A N/A
Version Count 1 N/A N/A
Sharable Mem(KB) 14 N/A N/A
-------------------------------------------------------------
Execution Plan
---------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 1579 (100)| |
| 1 | TABLE ACCESS BY INDEX ROWID| TAB1 | 20000 | 273K| 1579 (1)| 00:00:19 |
| 2 | INDEX RANGE SCAN | TAB1_PK | 20000 | | 39 (0)| 00:00:01 |
---------------------------------------------------------------------------------------
Full SQL Text
SQL ID SQL Text
------------ -----------------------------------------------------------------
cbmpgdpxr6vy SELECT UNIQUE_ID , NON_UNIQUE_ID FROM TAB1 WHERE UNIQUE_ID BETWEE
EN 1 AND 20000 AND IS_DELETE = 0 AND STATUS_CODE = '00'
Report written to demo1_2_awrsqrpt.txt
SCOTT>
DEMO : １行の参照を２万回グルグル回すバッチ処理
単純な比較だからね。１回 vs. ２万回グルグル系の。
グルグル回す処理方式もいろいろな大人の事情で利用する必要があるのもこともわかっていますが、基本的に性能はでないので、それを想定した対処は必要ですよね :)
SCOTT> @demo1_3
1 declare
2 type t_unique_id is table of tab1.unique_id%type index by pls_integer;
3 type t_non_unique_id is table of tab1.non_unique_id%type index by pls_integer;
4 unique_ids t_unique_id;
5 non_unique_ids t_non_unique_id;
6 cursor c1(p_unique_id tab1.unique_id%TYPE) is
7 select
8 unique_id
9 ,non_unique_id
10 from
11 tab1
12 where
13 unique_id = p_unique_id
14 and is_delete = 0
15 and status_code = '00'
16 ;
17 begin
18 for i in 1..20000 loop
19 for c1_rec in c1(i) loop
20 unique_ids(i) := c1_rec.unique_id;
21 non_unique_ids(i) := c1_rec.non_unique_id;
22 end loop;
23 end loop;
24 dbms_output.put_line('rows:'||unique_ids.last);
25* end;
rows:20000
PL/SQLプロシージャが正常に完了しました。
・・・中略・・・
Plan Statistics DB/Inst: DISCUS/discus Snaps: 210-211
-> % Total DB Time is the Elapsed Time of the SQL statement divided
into the Total Database Time multiplied by 100
Stat Name Statement Per Execution % Snap
---------------------------------------- ---------- -------------- -------
Elapsed Time (ms) 1,456 0.1 37.4
CPU Time (ms) 1,112 0.1 42.2
Executions 20,000 N/A N/A
Buffer Gets 60,047 3.0 95.3
Disk Reads 1,587 0.1 75.6
Parse Calls 1 0.0 0.7
Rows 20,000 1.0 N/A
User I/O Wait Time (ms) 866 N/A N/A
Cluster Wait Time (ms) 0 N/A N/A
Application Wait Time (ms) 0 N/A N/A
Concurrency Wait Time (ms) 0 N/A N/A
Invalidations 0 N/A N/A
Version Count 1 N/A N/A
Sharable Mem(KB) 18 N/A N/A
-------------------------------------------------------------
Execution Plan
---------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 2 (100)| |
| 1 | TABLE ACCESS BY INDEX ROWID| TAB1 | 1 | 14 | 2 (0)| 00:00:01 |
| 2 | INDEX UNIQUE SCAN | TAB1_PK | 1 | | 1 (0)| 00:00:01 |
---------------------------------------------------------------------------------------
Full SQL Text
SQL ID SQL Text
------------ -----------------------------------------------------------------
dvpjay9p4csj SELECT UNIQUE_ID , NON_UNIQUE_ID FROM TAB1 WHERE UNIQUE_ID = :B1
AND IS_DELETE = 0 AND STATUS_CODE = '00'
Report written to demo1_3_awrsqrpt.txt
SCOTT>
DEMO : DEMO : １行の参照を２万回グルグル回すバッチ処理をIndex Only Accessでチューニングしたみたよ:)
アクセスブロック数も減ったし、処理時間も短くなった。 グルグル系のはね、SQL文レベルのチューニング限界でもある。
Index Only Accessでチューニングしても、グルグル回ってる回数は同じだから。
SCOTT> @demo1_3_ix
create index tab1_ix_demo1_3 on tab1(unique_id,is_delete,status_code,non_unique_id) nologging;
索引が作成されました。
SCOTT> @demo1_3
1 declare
2 type t_unique_id is table of tab1.unique_id%type index by pls_integer;
3 type t_non_unique_id is table of tab1.non_unique_id%type index by pls_integer;
4 unique_ids t_unique_id;
5 non_unique_ids t_non_unique_id;
6 cursor c1(p_unique_id tab1.unique_id%TYPE) is
7 select
8 unique_id
9 ,non_unique_id
10 from
11 tab1
12 where
13 unique_id = p_unique_id
14 and is_delete = 0
15 and status_code = '00'
16 ;
17 begin
18 for i in 1..20000 loop
19 for c1_rec in c1(i) loop
20 unique_ids(i) := c1_rec.unique_id;
21 non_unique_ids(i) := c1_rec.non_unique_id;
22 end loop;
23 end loop;
24 dbms_output.put_line('rows:'||unique_ids.last);
25* end;
rows:20000
PL/SQLプロシージャが正常に完了しました。
・・・中略・・・
Plan Statistics DB/Inst: DISCUS/discus Snaps: 212-213
-> % Total DB Time is the Elapsed Time of the SQL statement divided
into the Total Database Time multiplied by 100
Stat Name Statement Per Execution % Snap
---------------------------------------- ---------- -------------- -------
Elapsed Time (ms) 498 0.0 11.1
CPU Time (ms) 453 0.0 13.0
Executions 20,000 N/A N/A
Buffer Gets 40,088 2.0 74.9
Disk Reads 72 0.0 8.1
Parse Calls 1 0.0 0.2
Rows 20,000 1.0 N/A
User I/O Wait Time (ms) 37 N/A N/A
Cluster Wait Time (ms) 0 N/A N/A
Application Wait Time (ms) 0 N/A N/A
Concurrency Wait Time (ms) 0 N/A N/A
Invalidations 0 N/A N/A
Version Count 1 N/A N/A
Sharable Mem(KB) 18 N/A N/A
-------------------------------------------------------------
Execution Plan
------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 1 (100)| |
| 1 | INDEX RANGE SCAN| TAB1_IX_DEMO1_3 | 1 | 14 | 1 (0)| 00:00:01 |
------------------------------------------------------------------------------------
Full SQL Text
SQL ID SQL Text
------------ -----------------------------------------------------------------
dvpjay9p4csj SELECT UNIQUE_ID , NON_UNIQUE_ID FROM TAB1 WHERE UNIQUE_ID = :B1
AND IS_DELETE = 0 AND STATUS_CODE = '00'
Report written to demo1_3_awrsqrpt.txt
SCOTT>
SCOTT> @drop_demo1_3_ix
drop index tab1_ix_demo1_3;
索引が削除されました。
DEMO : 暴走するスカラー副問合せ
SELECTリストにあるスカラー副問合せって、クエリ本体でヒットしたデータ件数分グルグル実行されるんだお。
SCOTT> @demo5
alter system flush buffer_cache;
システムが変更されました。
経過: 00:00:00.26
1 select
2 t1.unique_id,
3 t1.item_code,
4 (
5 select
6 max(t3.unique_id)
7 from
8 tab31 t2 join tab311 t3
9 on
10 t3.sub_item_code = t2.sub_item_code
11 and t3.is_delete = 0
12 where
13 t2.item_code = t1.item_code
14 and t2.is_delete = 0
15 ) current_item
16 from
17 tab3 t1
18 where
19 t1.unique_id between 1 and 10000
20 and t1.is_delete = 0
21* and t1.status_code = '00'
10000行が選択されました。
経過: 00:00:17.54
実行計画
----------------------------------------------------------
Plan hash value: 2850625377
-------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 9998 | 253K| 424 (0)| 00:00:06 |
| 1 | SORT AGGREGATE | | 1 | 47 | | |
| 2 | NESTED LOOPS | | 2 | 94 | 8 (0)| 00:00:01 |
|* 3 | TABLE ACCESS BY INDEX ROWID| TAB31 | 1 | 29 | 3 (0)| 00:00:01 |
|* 4 | INDEX UNIQUE SCAN | TAB31_PK | 1 | | 2 (0)| 00:00:01 |
|* 5 | TABLE ACCESS BY INDEX ROWID| TAB311 | 2 | 36 | 5 (0)| 00:00:01 |
|* 6 | INDEX RANGE SCAN | TAB311_IX | 2 | | 2 (0)| 00:00:01 |
|* 7 | TABLE ACCESS BY INDEX ROWID | TAB3 | 9998 | 253K| 424 (0)| 00:00:06 |
|* 8 | INDEX RANGE SCAN | TAB3_PK | 10000 | | 23 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter("T2"."IS_DELETE"=0)
4 - access("T2"."ITEM_CODE"=:B1)
5 - filter("T3"."IS_DELETE"=0)
6 - access("T3"."SUB_ITEM_CODE"="T2"."SUB_ITEM_CODE")
7 - filter("T1"."IS_DELETE"=0 AND "T1"."STATUS_CODE"='00')
8 - access("T1"."UNIQUE_ID">=1 AND "T1"."UNIQUE_ID"<=10000)
統計
----------------------------------------------------------
1256 recursive calls
0 db block gets
52747 consistent gets
22557 physical reads
116 redo size
326816 bytes sent via SQL*Net to client
7742 bytes received via SQL*Net from client
668 SQL*Net roundtrips to/from client
35 sorts (memory)
0 sorts (disk)
10000 rows processed
SCOTT>
DEMO : 暴走するスカラー副問合せをIndex Only Accessでチューニング!
アクセスブロック数が明らかに減った :) 索引だけ参照させることでね :)
SCOTT> @demo5_ix
create index tab31_demo_ix on tab31(item_code, is_delete, sub_item_code) nologging;
索引が作成されました。
経過: 00:00:01.18
create index tab311_demo_ix on tab311(sub_item_code, is_delete, unique_id) nologging;
索引が作成されました。
SCOTT> @demo5
alter systen flush buffer_cache;
システムが変更されました。
経過: 00:00:00.18
1 select
2 t1.unique_id,
3 t1.item_code,
4 (
5 select
6 max(t3.unique_id)
7 from
8 tab31 t2 join tab311 t3
9 on
10 t3.sub_item_code = t2.sub_item_code
11 and t3.is_delete = 0
12 where
13 t2.item_code = t1.item_code
14 and t2.is_delete = 0
15 ) current_item
16 from
17 tab3 t1
18 where
19 t1.unique_id between 1 and 10000
20 and t1.is_delete = 0
21* and t1.status_code = '00'
10000行が選択されました。
経過: 00:00:03.81
実行計画
----------------------------------------------------------
Plan hash value: 2957188266
----------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 9998 | 253K| 424 (0)| 00:00:06 |
| 1 | SORT AGGREGATE | | 1 | 47 | | |
| 2 | NESTED LOOPS | | 2 | 94 | 5 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | TAB31_DEMO_IX | 1 | 29 | 3 (0)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | TAB311_DEMO_IX | 2 | 36 | 2 (0)| 00:00:01 |
|* 5 | TABLE ACCESS BY INDEX ROWID| TAB3 | 9998 | 253K| 424 (0)| 00:00:06 |
|* 6 | INDEX RANGE SCAN | TAB3_PK | 10000 | | 23 (0)| 00:00:01 |
----------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("T2"."ITEM_CODE"=:B1 AND "T2"."IS_DELETE"=0)
4 - access("T3"."SUB_ITEM_CODE"="T2"."SUB_ITEM_CODE" AND "T3"."IS_DELETE"=0)
5 - filter("T1"."IS_DELETE"=0 AND "T1"."STATUS_CODE"='00')
6 - access("T1"."UNIQUE_ID">=1 AND "T1"."UNIQUE_ID"<=10000)
統計
----------------------------------------------------------
1 recursive calls
0 db block gets
32839 consistent gets
4655 physical reads
0 redo size
326816 bytes sent via SQL*Net to client
7742 bytes received via SQL*Net from client
668 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
10000 rows processed
SCOTT>
SCOTT> @drop_demo5_ix
drop index tab31_demo_ix;
索引が削除されました。
経過: 00:00:00.42
drop index tab311_demo_ix;
索引が削除されました。
DEMO : NULLとハサミは使いよう。(Index Only Accessがその効果を失う日？！)
※セッション中のデモ時間短縮のため”暴走するスカラー副問合せ”のチューニング後の状態を同一条件の別テーブルで再現してあります。
Index Only Accessでチューニングしたはずの、スカラー副問合せが...再び暴れだした。どゆこと？
処理時間も以前より遅くなってるし、かつ特定の部分のROWSが異常に増加していて、Buffer Getsがすごい事になってます。
Index Only Accessのための索引を作ったものの
SCOTT> @demo5_2_ix
create index tab31_bk_demo_ix on tab31_bk(item_code, is_delete, sub_item_code) nologging;
索引が作成されました。
経過: 00:00:01.25
create index tab311_bk_demo_ix on tab311_bk(sub_item_code, is_delete, unique_id) nologging;
索引が作成されました。
SCOTT> @demo5_2
alter system flush buffer_cache;
システムが変更されました。
経過: 00:00:00.09
1 select
2 t1.unique_id,
3 t1.item_code,
4 (
5 select
6 max(t3.unique_id)
7 from
8 tab31_bk t2 join tab311_bk t3
9 on
10 t3.sub_item_code = t2.sub_item_code
11 and t3.is_delete = 0
12 where
13 t2.item_code = t1.item_code
14 and t2.is_delete = 0
15 ) current_item
16 from
17 tab3 t1
18 where
19 t1.unique_id between 1 and 10000
20 and t1.is_delete = 0
21* and t1.status_code = '00'
10000行が選択されました。
経過: 00:00:34.59
実行計画
----------------------------------------------------------
Plan hash value: 3069420010
-------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 9998 | 253K| 424 (0)| 00:00:06 |
| 1 | SORT AGGREGATE | | 1 | 47 | | |
| 2 | NESTED LOOPS | | 35974 | 1651K| 5 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | TAB31_BK_DEMO_IX | 1 | 29 | 3 (0)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | TAB311_BK_DEMO_IX | 35978 | 632K| 2 (0)| 00:00:01 |
|* 5 | TABLE ACCESS BY INDEX ROWID| TAB3 | 9998 | 253K| 424 (0)| 00:00:06 |
|* 6 | INDEX RANGE SCAN | TAB3_PK | 10000 | | 23 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("T2"."ITEM_CODE"=:B1 AND "T2"."IS_DELETE"=0)
4 - access("T3"."SUB_ITEM_CODE"="T2"."SUB_ITEM_CODE" AND "T3"."IS_DELETE"=0)
5 - filter("T1"."IS_DELETE"=0 AND "T1"."STATUS_CODE"='00')
6 - access("T1"."UNIQUE_ID">=1 AND "T1"."UNIQUE_ID"<=10000)
統計
----------------------------------------------------------
1 recursive calls
0 db block gets
896697 consistent gets
5190 physical reads
0 redo size
326829 bytes sent via SQL*Net to client
7742 bytes received via SQL*Net from client
668 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
10000 rows processed
SCOTT>
DEMO : NULLとハサミは使いよう。(Index Only Accessがその効果を失う日？！)
なぜ、Index Only Accessが効果を失ってしまったのか。。。
スカラー副問合せのチューニングでは、Index Range ScanやIndex Unique ScanをNested Loop結合かつIndex Only Access化したのだが、
特定の値に大きな偏りがあり、広範囲のIndex Range ScanがNested Loop結合で繰り返されたのがその理由。
特定の値の意味を調査していくと、実はNULLでも問題ないという意味合いしかないことが発覚。
しか〜〜〜し、大人の事情で、該当列をNULLに更新してしまうことは許されない。さて、どのように対処するか！
閃いた！。 Oracle11g で登場した新機能を使え！ (恐る恐るw でも事前にKROWNなど調べまくりましたよv)
特定の値をNULLに置換する仮想列を追加して、その列でIndex Only Accesssを実現する索引を作る。さらに、SQL文の結合条件だけは変更してもらう。
（影響範囲を最小にした対処だと思います. 仮想列が無かったら大変だったと思います）
以下の結果の通り、処理時間も以前チューニングした時間まで改善し、広範囲のIndex Range Scanも消えていることが実行計画からも確認できます。めでたしめでたし。
SCOTT> @demo5_2_virtual
alter
table tab311_bk add (sub_item_code_virtual CHAR(10) as (replace(sub_item_code,' ',null)) virtual);
表が変更されました。
経過: 00:00:00.57
SCOTT> @demo5_2_ix_2
create index tab311_bk_demo_vix on tab311_bk(sub_item_code_virtual, is_delete, unique_id) nologging;
索引が作成されました。
経過: 00:00:05.38
SCOTT> @demo5_2_2
alter system flush buffer_cache;
システムが変更されました。
経過: 00:00:00.07
1 select
2 t1.unique_id,
3 t1.item_code,
4 (
5 select
6 max(t3.unique_id)
7 from
8 tab31_bk t2 join tab311_bk t3
9 on
10 t3.sub_item_code_virtual = t2.sub_item_code
11 and t3.is_delete = 0
12 where
13 t2.item_code = t1.item_code
14 and t2.is_delete = 0
15 ) current_item
16 from
17 tab3 t1
18 where
19 t1.unique_id between 1 and 10000
20 and t1.is_delete = 0
21* and t1.status_code = '00'
10000行が選択されました。
経過: 00:00:03.45
実行計画
----------------------------------------------------------
Plan hash value: 2681694377
--------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 9998 | 253K| 424 (0)| 00:00:06 |
| 1 | SORT AGGREGATE | | 1 | 48 | | |
| 2 | NESTED LOOPS | | 7 | 336 | 5 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | TAB31_BK_DEMO_IX | 1 | 29 | 3 (0)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | TAB311_BK_DEMO_VIX | 7 | 133 | 2 (0)| 00:00:01 |
|* 5 | TABLE ACCESS BY INDEX ROWID| TAB3 | 9998 | 253K| 424 (0)| 00:00:06 |
|* 6 | INDEX RANGE SCAN | TAB3_PK | 10000 | | 23 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("T2"."ITEM_CODE"=:B1 AND "T2"."IS_DELETE"=0)
4 - access("T3"."SUB_ITEM_CODE_VIRTUAL"="T2"."SUB_ITEM_CODE" AND "T3"."IS_DELETE"=0)
5 - filter("T1"."IS_DELETE"=0 AND "T1"."STATUS_CODE"='00')
6 - access("T1"."UNIQUE_ID">=1 AND "T1"."UNIQUE_ID"<=10000)
統計
----------------------------------------------------------
22 recursive calls
0 db block gets
32843 consistent gets
4072 physical reads
0 redo size
322687 bytes sent via SQL*Net to client
7742 bytes received via SQL*Net from client
668 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
10000 rows processed
SCOTT>
SCOTT> @drop_demo5_2_ix_2
drop index tab311_bk_demo_vix;
索引が削除されました。
経過: 00:00:00.29
SCOTT> @drop_demo5_2_ix
drop index tab31_bk_demo_ix;
索引が削除されました。
経過: 00:00:00.37
drop index tab311_bk_demo_ix;
索引が削除されました。
経過: 00:00:00.05
SCOTT> @drop_demo5_2_virtual
alter table tab311_bk drop (sub_item_code_virtual);
表が変更されました。
経過: 00:00:00.48
| 固定リンク | 0 | コメント (0) | トラックバック (0)
Japan Oracle User Groupが2012年7月21日（土）に日本オラクル青山センターにてイベントを開催します！
詳細は以下
↓↓↓↓↓
http://www.jpoug.org/2012/06/06/jpoug-set-events-20120721
なお、参加の申し込みはzussarからどうぞ :)
http://www.zusaar.com/event/311004
現在開催に先立ちオーガナイザー募集中
募集は終了しました。ご応募ありがとうございました。
5分だけのライトニングトーク、20分のアンカンファレンス、45分のセミナーで「我こそは ぜひ思いを共有したい」という方を募集中！
オーガナイザー募集の詳細も以下のURLからどうぞ
↓↓↓↓↓
http://www.jpoug.org/2012/06/06/jpoug-set-events-20120721
| 固定リンク | 0 | コメント (0) | トラックバック (0)
OSC.DBって随分ご無沙汰してたと思ったら、前回参加したOSC.DBは、2007年でしたか。息子ちゃんが生まれた年です：）
OSC.DBも2008年以来、久々に開催でしたし、久々にお会いできた方々もいて :) でした。
全てのセッションには参加できなかったので、午前中だけ。
参加したセッションは
とOSC.DBではおなじみのユーザ（ー）会のセッションでした。
PostgreSQL 9.1 は Insight outで聞けなかったところ？を駆け足で聴いた感じ。
(9.1からサポートされたIndes only scanはOracleでもよく使うチューニング方法ですね。あとは、カスケードレプリケーションとか、pg_basebackup関連とか）
MySQLは、MySQL5.6の話とストレージエンジンである groongaストレージエンジン関連をこれまた駆け足で。
(InnoDBオプティマイザ統計情報の永続化、デッドロックをエラーログに出力とか、groongaストレージエンジンには、Spiderエンジンの斯波さんも関わっているとか、MariaDBにバンドルされることになったとか、http://labs.mysql.com/ とか）
３０分ぐらいだとどうしても駆け足になってしまいますよね。皆さん早口ですよね。
（いままでで一番高速な語りは、大規模Web サイトでのMySQL導入方法および事例紹介」セミナーの松信さんだったように思います。速すぎて日本語聞き取れねーと思ったのは人生初。おおげさかw）
お腹が減ってきたランチ前のセッションは、Firebird日本ユーザー会。ユーザーなんですよユーザじゃなくて。
木村さんと、林さんの軽快なトークが炸裂（アドリブだったらしいw) したFirefoxじゃなくてFirebirdの話。
（ブラジルではFirebird関連イベントで800人ぐらい軽く集まるらしい。すげー）
そして、ほぼパーフェクトな記録発見。 Thx （やっぱ、iPhoneだけだとメモれないというかつぶやききれないw のだ)
http://emasaka.blog65.fc2.com/blog-entry-952.html
| 固定リンク | 0 | コメント (0) | トラックバック (0)
さて、この実習セミナー、回を重ねて３回目です。パチパチ。:)
今回のお題は、
「社内システムにおいて、「2010年1月10日 23:21～1月11日 0:15」に、業務遅延(障害)が発生しました。該当時間帯のDB稼動状況を確認し、遅延の原因調査を行って下さい」
というものでした。
「iPhoneの予約が殺到したんでしょうかね？。。。」と、かってに予想してましたw (違うらしいですw)
ちょっとまじめにレポートしますか（今回はw)
今回は前回とは異なりグループ単位ではなく個人で解析を進めるという形式で行われました。
普段からstatspackレポートを見て解析している人とそうでない人差が出てしまうかな？と思いましたが、statspack/AWRレポートから問題解決の糸口を見つけ出すという流れはしっかりと体験できたのではないかと思います。
ただ、初めてstatspack/AWRレポート見て困るのが、待機イベントが具体的に何を示すものなのか、オラクルのマニュアルにもわかりやすい解説がないという点ではないでしょうか。（わかり難いのはそれだけではないのですが。。。）
前々回、前回と、問題となっている待機イベントを図解していたという点からも、待機イベント重要！！ってことは十分伝わったのではないかな〜と感じました。
以下、待機イベントを言葉だけで解説しているオラクルのマニュアルですが、あの文章だけで内容を理解できちゃう人ってすげ〜と思います。というか、中の人（元、中の人含む）しかわからんのではないかと、今でも思っています。（昔のマニュアルよりかなり細かく書かれているとは思いますが）
Oracle® Databaseリファレンス 11g リリース2（11.2）待機イベントの説明
待機イベントを図解したマニュアルとかあればいいのにね〜〜〜、と、と〜〜〜〜くの空を見て思う（今、夜中なんで街灯の方が目立ちますがw）
| 固定リンク | 0 | コメント (0) | トラックバック (0)
昨日は、「実習セミナー：RAC環境でのレスポンス遅延を調査・解決」に参加してきた。 ;)
前回、２日に渡って行われた、
「DBがなんか遅いんだけど！」「DBで何か起きてないか確認して！」こんな問い合わせへの対応 “一人”でできますか？ - 勉強会＠日本オラクル青山センター
「DBがなんか遅いんだけど！」「DBで何か起きてないか確認して！」こんな問い合わせへの対応 “一人”でできますか？ - 勉強会＠日本オラクル青山センター #2
という勉強会シリーズの続編です。今回はペアプロじゃなくてグループチューニング形式（３名１組というグループで解析しました）、２ノードRACで発生した処理遅延の解析の流れを勉強しました。
前回と違って、真剣にレポート見ちゃいましたよw。
実はgc cr block grant 2-way あたりで、RACをRACとして使ってないのに遅延なんて、マニアックなネタになってるんじゃないかなー、なんて、ニヤニヤして見てたんですが、私の想像とは違う待機イベントでしたねー ;)（ネタばれ禁止なので内容はこの程度でご勘弁を）
で、皆さんいろいろと解析しつつ、最後のQAで、衝撃的（笑劇的）な解決案が提示されました！
なんと！ 「RAC使わなければ、いいんじゃね？！」（核爆
普段解析やってる人、AP設計開発オンリーだけど怖いもの見たさでやってみたい方、女性エンジニアの方（私個人の意見ではございませんw）、どんどん参加してみてくだちい。（またGANTS語に....)
次回も楽しみにしております。
追伸）
ビールの勢いとはいえ、場の空気読みきれず、じゃんけん大会で勝って頂いちゃいました m(_ _)m
| 固定リンク | 0 | コメント (0) | トラックバック (0)
「DBがなんか遅いんだけど！」「DBで何か起きてないか確認して！」こんな問い合わせへの対応 一人でできますか？ - 勉強会＠日本オラクル青山センター
先週に引き続き、「DBがなんか遅いんだけど！」「DBで何か起きてないか確認して！」こんな問い合わせへの対応 “一人”でできますか？ - 勉強会＠日本オラクル青山センター を参観してきた :)
今回も満席で、チューニング系かつ、オープンな勉強会ってのは興味ある人にとってはすげー希少な機会なんじゃないか…と。
懇親会、二次会も楽しませていただきました。二次会の締めの挨拶をなぜ私がしたのかいまいち状況わかりませんw.
次回「RAC環境の1ノードで発生したレスポンス遅延を調査・解決」の開催は日時、会場ともまだ未定ということですが、うわさによると恵比寿の可能性もあるとか。楽しみです 。また、参観枠で参加することになると思いますが :)
http://atnd.org/events/16250
http://atnd.org/events/16251
| 固定リンク | 0 | コメント (0) | トラックバック (0)
ブログ更新、随分さぼってました〜 m(_ _)m
久々のブログは、これまた今年初の勉強会ネタで。
「DBがなんか遅いんだけど！」「DBで何か起きてないか確認して！」こんな問い合わせへの対応 “一人”でできますか？
この勉強会 Oracle Database の性能問題をstatspackレポートやv$sessionのログを使って突き止めるという、その筋の人たちにはかな〜り、興味をそそる勉強会です。しかも２週連続 :)
おもしろいのは（実験的な意味もあるのかもしれないですけど…）、参観者枠があることw
http://atnd.org/events/16251
実習者枠で申し込もうかな〜 と @Guutara さんに呟いたら、参観者枠あるから、そっちにして〜と軽く強制w されたので参観者として参加。
リアルには面識の無い、オラクル界隈の濃〜っ方々にも会えたこともあり無理矢理時間作って参加した価値ありでした。
来週も楽しみです。
今回の内容は、「特定の処理にてレスポンス遅延が発生している」原因をstatspackレポートとv$sesionのログから探るものでした。
………enq: TX - row lock contention
面白い試みですよね、ほんと。
あ、そうそう、マニアックというか難しい性能問題を演習にして、オラクル界隈の濃〜っ方々が実習者で、そーゆーこと今後やっていきたいな〜と考えている方々が参観者というパターンも面白そうですね。 Oracle Database Turning Festa （勝手に命名w)
ほんとうの現場で起きた（起きているw）ような性能問題を一気に解決するようなのも面白いかもね。
インスタンスレベルの問題に限らず、SQL単体でもいいかもね。 SQL Turning Festa 。
実際のプロジェクトで起こった、絶賛SQLチューニング祭り開催中！的なネタを使って、ビール片手に、あーだーこーだ良いながらやるのも、面白いよね。きっと。：）
| 固定リンク | 0 | コメント (1) | トラックバック (0)
第７回Wikiばな〜Wikiの起源へ〜＠日本オラクル青山センターへ参加してきた。今回は当日朝にtwitterで「キャンセルが出たから空きがあるよ〜」とOracle Japanさんが呟いていたので急遽参加してきた。しかも、夫婦＋息子ちゃんで。
託児所があったわけでもないが、子連れNGでもなかったので、やや無理矢理ですが妻と交替で息子ちゃんの相手をしながらの勉強会参加となりました。
会場に着くと、会場外で元気よく騒ぐ息子ちゃんの声に気付いたOTN-Jさんがスタッフ控え室？だった部屋へ案内してくれた。まだ声のボリューム制御ができない息子ちゃんなので大変助かりました（元気ありすぎなので会場外の息子ちゃんの声が会場にも聞こえていた）。
OTN-Jの皆さん、ありがとうございました。
久々の勉強会参加となった妻も興味深いセッションに満足だったとのこと。めでたし、めでたし。
なお、急遽参加決したので懇親会までは参加できませんでした、こればかりは仕方ない。。残念でしたが。。
以下、控え室で走り回る息子ちゃん。
最後に、最近感じていることを、、、他の勉強会でも子連れで参加できるようになれば子育て中のママ・エンジニア、パパ・エンジニアの皆さんも参加し易くなるんじゃないかなぁと感じます。託児スペースというか、勉強会の会場以外にプレイルーム的な部屋も確保しなければならないので、なかなか大変だとは思うのですが、日本オラクル青山センターのような会場が確保できた場合はそのようなことも可能なのではないかと。。。。。
ママ・エンジニアもパパ・エンジニアも条件さえ整えばこのような勉強会へ参加したいと考えている方は多いのではないでしょうか。。。。
| 固定リンク | 0 | コメント (0) | トラックバック (0)
OOW 2009 tokyoで名刺交換したのことがキッカケで、Oracle LOVERS勉強会 第１２回＠日本オラクル青山センターにゲストとして参加してきました。
ゲストとして参加した私、何を話したかというと、「IT業界のサバイバビリティとは」というなんとなく難しいお題を頂きまして、かなりアウェイ感がありましたがどうにかこうにか話せたような気がします。
現状が現状だから「生き残る」というキーワードに目が行ってしまうのかもしれませんが、私は「生き残る」という言葉の響きが好きになれないのです。（実際、競争があり、その競争で「勝ち」、「負け」という状況が起こることは否定しません。）
どうしても「生き残る」＝他の屍を踏み越えて”自分が（自分だけ、もしくは、単一の組織とかが）”生き残っていくイメージが強くて。
「生き残る力」じゃなくて「生きる力」が重要なんじゃないかな？ という思いでお話させて頂きました。
まだまだ私自身が未熟者ですので、そんなに深いことはお話していないのは想像できると思いますが..... :）
Oracle LOVERS勉強会は基本的にはmixiコミュで開催告知、等をしているとのこと。
http://mixi.jp/view_community.pl?id=32605
あ、忘れてしまうところでした、OTN-J 事務局長の伊東さんから。
日本オラクル青山センターのセミナールーム（無線LAN利用可、プロジェクター有り）を勉強会で利用くださいとのこと。しかも無料。勉強会を開催しているが、場所にお困りの方はご一報くださいとのこと。OTN-Jの伊東さんは「セミナールームを社外の勉強会へ解放すること」を仕事としてやります。と会社へ宣言してやっているとのこと。すばらしい！
2015/4/13追加（当時のKeynoteが見つかったのでSlideshareで公開）
| 固定リンク | 0 | コメント (2) | トラックバック (1)
S/N Ratio (by SATO Naoki) : 新生Oracle WebLogic Serverの解 (2/27)というCTCさん主催セミナーがあるというので参加してきた。
OSSの世界では勉強会流行ですが、勉強会ではBlogで勉強会の感想など書くまでが勉強会となっている。それに倣ってBlogで関連エントリを書くまでがセミナーってことにしておくか。
昨今、自営業（個人事業主）のITエンジニアに対して案件を出さなくなってきている発注元が多くなって来ている中、私のエージェントからの情報によればCTCさんもご多分に漏れず自営業（個人事業主）に門戸を閉ざしているらしいが、このセミナーに関してはOKだったようで参加できた。（爆）。
内容的には想像していた内容に近かったのだが、WebLogic製品のロードマップの解説もあったのでまあまあといったところ。
最後にCTCさんのノベルティ（ボールペン）とCTC/BEA共著「BEA WebLogic Server 9.x/10 構築・運用ガイド」のおみやげを頂きました。m(_ _)m（ノベルティの詳細はブログ de ノベルティにて）
そういえば私が取得したIT系資格のなかで一番お金に結びついていなかったのがOCA ASだったなぁ〜〜遠い目。
資格取得前にOracle Application Server 9i ASに関わる案件で、かな〜〜〜〜り苦労したお陰で当該プロジェクト終了後、全く勉強せずにOracle Master GOLD 9i Application Serverに一発合格、その数ヶ月後にOracle Masterの体系が大きく変更され、Oracle Master GOLD 9i Application Serverが自動的にSILVER 9i Applicationに格下げ？！され一気に10g ASの資格取得熱が冷めてしまったことを覚えている。
その当時、Oracle Application Server関連案件の割合はWebLogicとWebsphereの合計と比較すると１：９９くらいだったので取得する必要は無かったといえば無かった資格だったのかもしれません。今、思うと。。。
なんだか話が変な方向へいっちゃっていますが、今となっては大変懐かしいOracle Master 9i GOLDの認定書と何故か間違ってOracle Corporationから送付されてきたOCA 9i ASの認定書（返してくれと直接Oracleさんから連絡が無かったので記念に取っておきました。w）そして、自動的にSILVERになってしまったOracle Master Silver 9i Application Serverの認定書。そして最後に記念に頂いた9i ASの置き時計。全部セピア色に加工した方が良かっただろうか・・・・。新しいOracle Weblogic 11gとか出たらまた資格熱は再燃するかも・・・w。
まずはOracle Master GOLD 9i Application Server合格後、何かの手違いでOracle Corporationから送付されてきたOracle Certified Associate 9i Application Serverの認定書（日本ではこの認定書もっている方どれだけいるんだろう）
次はOracl日本オラクルから送られてきたOracle Master GOLD 9i Application Serverの認定書とノベルティ（この１ヶ月くらい後、Oracle Masterの新体系が発表され奈落の底に・・・・w
そして最後にGOLDからSILVERへ落とされた感じをつよ〜〜〜く持ってしまったOracle Master SILVER 9i Application Serverの認定書。
そう言えば、OTN-Jで新資格体系のシンボルマークにアルファロメオみたいな蛇を巻き付けてくれたらいいのに〜〜。という気持ちで書き込んでいたりしたことも思い出したよ。wちなみにそれから、Oracle9i ASに関わっていたお陰でOTN-Jでかなりコメントいれていたこともついでに思い出した。
やはりどんどん本題から離れて行ってしまうので、この話はここまで。
| 固定リンク | 0 | コメント (0) | トラックバック (0)
最近のコメント