DROP SHADOW CTRL


GaragebandとiMovieで



検索

  • Google
フォト

Twitter

2024年12月
日 月 火 水 木 金 土
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

気まぐれ写真館

  • spider lily - 白と赤の彼岸花（曼珠沙華）

カテゴリー

Oracle

Apple

その他

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

Googleの広告



RSS

ブログ:ココログ

当サイトについて

プライバシーポリシー
■プライバシーポリシー

■個人情報の利用目的

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

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

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

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

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

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

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

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

■広告の配信について

当サイトは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による個人に関する情報の取得及び取扱いに関する方針につきましてはAmazon.co.jpプライバシー規約をご覧ください。

■免責事項

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

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

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

« 2013年9月 | トップページ | 2013年11月 »

2013年10月30日 (水)

潮溜まりでジャブジャブします :)

db tech showcase 東京 2013


潮溜まりで泳いでいる一癖ありそうなSQL文が見えませんか？

Rockpool
Rock Pool : Michael Coghlan (CC BY-NC-SA 2.0)

投稿日時 2013年10月30日 (水) 23時29分 JPOUG, DB Tech Showcase | | | コメント (0) | トラックバック (0)

2013年10月13日 (日)

母艦のMacProよりiopsでるのな。そりゃそうだ。

MacBook Air(mid 2013) だと母艦のMacProよりiopsがでる（SSDだもんなw）ので
MacProでデモ用のネタを仕込んじゃうとMacBook Airでは短くなる〜〜

70GBぐらい残っているから余裕はあるけど..最初からMacBook Airでやっときゃ良かった。

データサイズやデータ量は母艦より多くしないと　＞＜　

MacPro (Mid 2012)
1324iops


MacBook Air (Mid 2013)
1799iops

投稿日時 2013年10月13日 (日) 12時54分 Mac | | | コメント (0) | トラックバック (0)

AWRレポートはOracle Database 12c R1ではFlat Designに変更されたのか? ;p

AWRレポートもフラットデザイン採用？ w

以下、Oracle Database 11g R2までのAWRレポート

20131013_70906




Oracle Database 12C R1では、フラットデザイン。　
意図してやっているのだろうか？　
border="1"がborder="0"になってる。CSSは以前のままだが。

20131013_70856

投稿日時 2013年10月13日 (日) 07時30分 Oracle Database 11g Release 2, Oracle Database 12c release 1, AWR | | | コメント (0) | トラックバック (0)

2013年10月 6日 (日)

Scalar Subquery Unnesting Transformation (Oracle Database 12c R1 New Feature)

新機能の自分メモ　:)


スカラー副問合せを使って性能改善する場合も多いのですが、逆にそれが理由で性能劣化しているケースも意外と多いんですよね。

昨年開催したJPOUGのセッションでもネタとして取り上げたのでご存知の方も多いと思いますし、実際にチューニング手法の一つとしてうまく活用している方も多いと思います。
（やっちまった〜〜〜〜、orz。　という方もいると思いますがw）

ご利用は計画的に！w

Oracle Database 11gまでは、以下のようなスカラー副問合せがネックとなって処理時間が予想以上に延びてしまう場合の回避方法は、たった一つ！

スカラー副問合せを止めて外部結合に書き換える！


遅延するケースとして、

1.dept表の行数が多い
2.スカラー副問合せでemp表を全表走査していたり、範囲の広いレンジスキャンを繰り返している

（2.で索引がなくて　もしくは、索引が利用できずに全表走査してたら最悪ですよね！）


スカラー副問合せを利用したクエリーはNested Loopという操作は現れていませんが、外部結合でNested Loop結合しているのと同じ動きなんだぉ〜　＞＜
件数多いと辛いんだよ〜〜〜。　ってことは忘れないようにしないと...

dept表の件数が少なければ問題にはならないけど、(例が例なので部門が１０万行になることはないでしょうけどw）dept表が10万行以上だとすれば、Nested Loop結合で処理させるのはリスクが大きいですよね。
ところが、以下のようなスカラー副問合せで書かれてしまうとHASH結合やMERGE結合になって欲しくても絶対になりません... (11gまではね）

select
	deptno
	,dname
	,(
		select
			max(sal)
		from
			emp 	
		where
			emp.deptno=dept.deptno
	) as max_sal
from
	dept
order by
deptno;


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

--------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |           |     4 |    52 |     6   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE                      |           |     1 |     7 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| EMP       |     5 |    35 |     2   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | IX_EMP_01 |     5 |       |     1   (0)| 00:00:01 |
|   4 |  TABLE ACCESS BY INDEX ROWID         | DEPT      |     4 |    52 |     2   (0)| 00:00:01 |
|   5 |   INDEX FULL SCAN                    | PK_DEPT   |     4 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------


スカラー副問合せを外部結合に書き換え、オプティマイザおまかせでHASH結合やMERGE結合になるようにした方が、チューニング方法が増えることもあり後々楽になるケースが多いんですよね。
(スカラー副問合せにして、結合のコストを低く抑えたい場面もあるのは事実ですが）

余談：
データ量が見切れない、大きく変動するような表の場合には、素直に結合してもらっていたほうが楽なんですよ。
チューニング案を考える/する人目線ですなのですが、どの程度の件数になるか見切れている場合以外は結合で書いてもらって、どうしても結合のコストを下げたいという状況になったらスカラー副問合せにしてもらうというケースが一番多い、かな）
select
	dept.deptno
	,dept.dname
	,max(emp.sal) as max_sal
from
	dept
	left outer join emp
	on
		dept.deptno=emp.deptno
group by 
	dept.deptno
	,dept.dname
order by
	deptno;


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

-----------------------------------------------------------------------------------------
| Id  | Operation                     | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |         |     9 |   180 |     5   (0)| 00:00:01 |
|   1 |  SORT GROUP BY                |         |     9 |   180 |     5   (0)| 00:00:01 |
|   2 |   MERGE JOIN OUTER            |         |    15 |   300 |     5   (0)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DEPT    |     4 |    52 |     2   (0)| 00:00:01 |
|   4 |     INDEX FULL SCAN           | PK_DEPT |     4 |       |     1   (0)| 00:00:01 |
|*  5 |    SORT JOIN                  |         |    14 |    98 |     3   (0)| 00:00:01 |
|   6 |     TABLE ACCESS FULL         | EMP     |    14 |    98 |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

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

   5 - access("DEPT"."DEPTNO"="EMP"."DEPTNO"(+))
       filter("DEPT"."DEPTNO"="EMP"."DEPTNO"(+))


前述のような単純なクエリーなら書換も苦にならない(苦になる人もいるさ、きっと）と思いますが、見るのも嫌になるほど長文のクエリーだったらどうしますw
私ならストレス発散に文句いいならが修正案だしますよ。...たぶんw　


そんなあなたに朗報！？　か.....。　

Oracle Database 12c なら、そんな書換も不要に！　


オプティマイザが肩代わりしてくれます!
（駄目クエリー書いちゃった方は、オプティマイザが良きに計らってくれるので何が起きているかも知らずに成長が止まっちゃうかもね。という状況ではないと思うけど、楽になるのはいい事なのかもね。）

参考：Optimizer with Oracle Database 12c

explain plan for
select
	deptno
	,dname
	,(
		select
			max(sal)
		from
			emp 
		where
			emp.deptno=dept.deptno
	) as max_sal
from
	dept
order by
deptno;


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

-----------------------------------------------------------------------------------------
| Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |          |     4 |   116 |     5   (0)| 00:00:01 |
|   1 |  MERGE JOIN OUTER            |          |     4 |   116 |     5   (0)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEPT     |     4 |    52 |     2   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | PK_DEPT  |     4 |       |     1   (0)| 00:00:01 |
|*  4 |   SORT JOIN                  |          |     3 |    48 |     3   (0)| 00:00:01 |
|   5 |    VIEW                      | VW_SSQ_1 |     3 |    48 |     3   (0)| 00:00:01 |
|   6 |     HASH GROUP BY            |          |     3 |    21 |     3   (0)| 00:00:01 |
|   7 |      TABLE ACCESS FULL       | EMP      |    14 |    98 |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$C772B8D1
   2 - SEL$C772B8D1 / DEPT@SEL$1
   3 - SEL$C772B8D1 / DEPT@SEL$1
   5 - SEL$683B0107 / VW_SSQ_1@SEL$7511BFD2
   6 - SEL$683B0107
   7 - SEL$683B0107 / EMP@SEL$2

Outline Data
-------------

  /*+
      BEGIN_OUTLINE_DATA
      USE_HASH_AGGREGATION(@"SEL$683B0107")
      FULL(@"SEL$683B0107" "EMP"@"SEL$2")
      USE_MERGE(@"SEL$C772B8D1" "VW_SSQ_1"@"SEL$7511BFD2")
      LEADING(@"SEL$C772B8D1" "DEPT"@"SEL$1" "VW_SSQ_1"@"SEL$7511BFD2")
      NO_ACCESS(@"SEL$C772B8D1" "VW_SSQ_1"@"SEL$7511BFD2")
      INDEX(@"SEL$C772B8D1" "DEPT"@"SEL$1" ("DEPT"."DEPTNO"))
      OUTLINE(@"SEL$1")
      OUTLINE(@"SEL$7511BFD2")
      OUTLINE(@"SEL$2")
      UNNEST(@"SEL$2")
      OUTLINE_LEAF(@"SEL$C772B8D1")
      OUTLINE_LEAF(@"SEL$683B0107")
      ALL_ROWS
      DB_VERSION('12.1.0.1')
      OPTIMIZER_FEATURES_ENABLE('12.1.0.1')
      IGNORE_OPTIM_EMBEDDED_HINTS
      END_OUTLINE_DATA
  */

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

   4 - access("ITEM_1"(+)="DEPT"."DEPTNO")
       filter("ITEM_1"(+)="DEPT"."DEPTNO")


ほら、ほら、ほらほらほらほら。。！！！！！

あら不思議、スカラー副問合せがUnnestされてMERGE結合に！！！！　outer joinに書き換えてくれています！！！

すげ〜〜〜〜〜〜〜〜〜〜〜〜。
ほかのケースでも試してみないと。..


OUTLINEを見るとUNNEST(@"SEL$2")なんてヒントがついてますね! ニッコリ。


NO_UNNESTにしてみる!

explain plan for
select
	/*+
		NO_UNNEST(@"SEL$2")
	*/
	deptno
	,dname
	,(
		select
			max(sal)
		from
			emp 	
		where
			emp.deptno=dept.deptno
	) as max_sal
from
	dept
order by
deptno;

Plan hash value: 3189108593

--------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |           |     4 |    52 |     6   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE                      |           |     1 |     7 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| EMP       |     5 |    35 |     2   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | IX_EMP_01 |     5 |       |     1   (0)| 00:00:01 |
|   4 |  TABLE ACCESS BY INDEX ROWID         | DEPT      |     4 |    52 |     2   (0)| 00:00:01 |
|   5 |   INDEX FULL SCAN                    | PK_DEPT   |     4 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------

11gまでのスカラー副問合せの実行計画だ！　

スカラー副問合せ内にNO_UNNESTヒントを書いてみます（同じ結果になるはず）

explain plan for
select
	deptno
	,dname
	,(
		select
			/*+ NO_UNNEST */
			max(sal)
		from
			emp 
		where
			emp.deptno=dept.deptno
	) as max_sal
from
	dept
order by
deptno;

Plan hash value: 3189108593

--------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |           |     4 |    52 |     6   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE                      |           |     1 |     7 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| EMP       |     5 |    35 |     2   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | IX_EMP_01 |     5 |       |     1   (0)| 00:00:01 |
|   4 |  TABLE ACCESS BY INDEX ROWID         | DEPT      |     4 |    52 |     2   (0)| 00:00:01 |
|   5 |   INDEX FULL SCAN                    | PK_DEPT   |     4 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------

よし、わかった。


関連している初期化パラメータはどれだろう...

参考: Mac De Oracle / Difference of Initialization Parameters between 11g r2 (11.2.0.1.0) and 12c r1 (12.1.0.1.0) - including hidden params

以下の赤字部分が12cで追加されたunnesting関連の隠しパラメータ、なかでも KSPPDESCを見ると、Scalar Subqueryのunnestingに関わりそうなのは、_optimizer_unnest_scalar_sq ですね。
備考を読んでると _optimizer_unnest_all_subqueries パラメータも気になる！w 

SYS@orcl12c> r
  1  select
  2     a.ksppinm
  3    ,b.ksppstvl
  4    ,b.ksppstdf
  5    ,a.ksppdesc
  6  from
  7    x$ksppi a join x$ksppcv b
  8    on a.indx = b.indx
  9  where
 10    a.ksppinm like '%unnest%'
 11  order by
 12*   a.ksppinm

KSPPINM                                  KSPPSTVL             KSPPSTDF   KSPPDESC
---------------------------------------- -------------------- ---------- ----------------------------------------------------------------------
_distinct_view_unnesting                 FALSE                TRUE       enables unnesting of in subquery into distinct view
_optimizer_unnest_all_subqueries         TRUE                 TRUE       enables unnesting of every type of subquery
_optimizer_unnest_corr_set_subq          TRUE                 TRUE       Unnesting of correlated set subqueries (TRUE/FALSE)
_optimizer_unnest_disjunctive_subq       TRUE                 TRUE       Unnesting of disjunctive subqueries (TRUE/FALSE)
_optimizer_unnest_scalar_sq              TRUE                 TRUE       enables unnesting of of scalar subquery
_unnest_subquery                         TRUE                 TRUE       enables unnesting of complex subqueries


_optimizer_unnest_scalar_sqを無効にしてみると...

explain plan for
select
	/*+
		OPT_PARAM('_optimizer_unnest_scalar_sq' 'false')
	*/
	deptno
	,dname
	,(
		select
			max(sal)
		from
			emp 
		where
			emp.deptno=dept.deptno
	) as max_sal
from
	dept
order by
deptno;


Plan hash value: 3189108593

--------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |           |     4 |    52 |     6   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE                      |           |     1 |     7 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| EMP       |     5 |    35 |     2   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | IX_EMP_01 |     5 |       |     1   (0)| 00:00:01 |
|   4 |  TABLE ACCESS BY INDEX ROWID         | DEPT      |     4 |    52 |     2   (0)| 00:00:01 |
|   5 |   INDEX FULL SCAN                    | PK_DEPT   |     4 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------

できた！


気になる_optimizer_unnest_all_subqueriesを無効にすると...

explain plan for
select
	/*+
		OPT_PARAM('_optimizer_unnest_all_subqueries' 'false')
	*/
	deptno
	,dname
	,(
		select
			max(sal)
		from
			emp 
		where
			emp.deptno=dept.deptno
	) as max_sal
from
	dept
order by
deptno;


Plan hash value: 3189108593

--------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |           |     4 |    52 |     6   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE                      |           |     1 |     7 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| EMP       |     5 |    35 |     2   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | IX_EMP_01 |     5 |       |     1   (0)| 00:00:01 |
|   4 |  TABLE ACCESS BY INDEX ROWID         | DEPT      |     4 |    52 |     2   (0)| 00:00:01 |
|   5 |   INDEX FULL SCAN                    | PK_DEPT   |     4 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------

これでもできた！　　
このunder score parameterは12cで追加された一連のUnnesting transformationの元栓みたいな感じですかね :)
12cのUnnesting系で問題がでたらこのパラメータで全部止めるというケースがあるのかないのか...使うとすればこのパラメータだろうね。

将来は外部結合をスカラー副問合せに書き換えるなんてぇ、トランスフォームが登場したりするんだろうか..........


参考
TANEL PODER'S BLOG / Oracle 12c: Scalar Subquery Unnesting transformation


投稿日時 2013年10月 6日 (日) 14時39分 | | | コメント (0) | トラックバック (0)