SQLレポート一括取得スクリプトを作ったよ。SQLレポート一括取得スクリプトを作ったよ。私のチューニング、アダプティブなオプティマイザにも、今のところ勝てそうな気がするぞ〜〜〜っ。私のチューニング、アダプティブなオプティマイザにも、今のところ勝てそうな気がするぞ〜〜〜っ。私のチューニング、アダプティブなオプティマイザにも、今のところ勝てそうな気がするぞ〜〜〜っ。私のチューニング、アダプティブなオプティマイザにも、今のところ勝てそうな気がするぞ〜〜〜っ。(wmo6hash::blog)ダーリンはGoogleで軽食なり。ココログ美しい水中写真。このような環境を子供、そしてその子供と残してあげなければ・・・・。ノベルティノベルティグッズをただ、ただ、記録していくブログ。Oracleでは出来ないネタなので、別ブログを立てた次第。Toshio)氏のサイト、専門分野以外にも、犬のmicと奥さんと伴に、「鎌倉」の風景を紹介しているブログです。(2012/6にガンで他界されたとのこと、お疲れ様でした、と言ったほうがいいですよね、きっと。「個人情報の保護に関する法律」に基づき、「個人情報保護の基本方針(プライバシーポリシー)」を定め個人情報の適切な管理・保護に努めることを表明します。個人情報の利用目的をできるだけ特定し、特定された利用目的の達成に必要な範囲を超えて利用することはありません。個人情報を偽りその他不正な手段による取得しません。取得したときは、本人に速やかに利用目的を通知又は公表します。個人情報を利用目的の範囲内で正確かつ最新の内容に保つように努めます。個人情報の漏洩や滅失を防ぐために、必要かつ適切な安全管理措置を講じます。本人の同意を得ないで第三者に個人情報を提供することはありません。健全育成に特に必要な場合、国等に協力する場合は除きます。Scan生活w」のセッション資料を公開します。(相変わらず文才ないな〜〜と落ち込む....作文嫌いは死ぬまで治らないと思ってるが、がんばって書くw)(デモ内容とデモ環境情報を追加予定です。状態でしたが楽しい時間を過ごさせていただきました。関係者の皆様、ご来場の皆様、ありがとうございました。(Mac/iPad/iPhone)ではKeynote風(但し、ページ間のトランジッションなし)に表示されます。(2012/4/10追加)セッションで利用したデモ環境の情報を載せておきます。x86VMの設定は以下のようになってます。cacheはオフにしてあります。late2010のMBAはメモリが2GBなので、VMには1GBのメモリを割り当ててます。(オラクルのmemory_targetなどの値も書いたほうがいいのかな〜)(2012/4/15追記)メモリサイズがギリギリなのでOracleのメモリ関連初期化パラメータも以下の通りで少なめです。0(2012/4/15追記)・デモで使った表これ。/PL/SQLプロシージャが正常に完了しました。commit;コミットが完了しました。dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'TAB1',no_invalidate=>false,cascade=>true);PL/SQLプロシージャが正常に完了しました。/PL/SQLプロシージャが正常に完了しました。commit;コミットが完了しました。dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'TAB2',no_invalidate=>false,cascade=>true);PL/SQLプロシージャが正常に完了しました。SCOTT>データ件数、データのカーディナリティは以下のようになってます。cacheをクリア、かつ、ソフトパース時の結果を載せています。・demo1通常ならこの実行計画であればなにもしないですよね...こんな良さげな実行計画でもSQL文と実行計画それに表定義をじ〜〜〜〜〜〜っと見ていると解決策が見えてきますよね。@demo1システムが変更されました。0998行が選択されました。processedis_deleteなんて列を参照するためにだけに行長の長い行を持つ表を、しかも、レンジスキャンしているのでデータアクセス量が多くなっているんですよね。invisible索引が作成されました。optimizer_use_invisible_indexes=trueセッションが変更されました。70msから10ms程度に改善してます。@demo1システムが変更されました。0998行が選択されました。processed次のデモのために作成した索引を削除しておきます。tab1_ix_demo1索引が削除されました。optimizer_use_invisible_indexes=falseセッションが変更されました。by句があるのでソート処理が行われています。返してあげることが多いです。@demo2システムが変更されました。scanにしてソート処理も省略するための索引を作成します。Informationセクションにはどのような索引を作成するかを決定するための重要な情報がリストされています。気づきましたか?以下の2行が重要。フィルタ処理を実施していることがわかります。NON_UNIQUE_ID,IS_DELETEの2列(つまりWHERE句に記述されている検索条件)がアクセスパスですよね。NON_UNIQUE_ID2毎のCOUNT()を取りNON_UNIQUE_ID2を昇順にソートしていることがわかります。invisible索引が作成されました。optimizer_use_invisible_indexes=trueセッションが変更されました。NOSORTというオペレーションからもわかるように、ソート処理が省略されています。getsは約1/50、処理時間は60msから10msまで改善しました。@demo2システムが変更されました。processed作成した索引を削除して次のデモへ。tab1_ix_demo2索引が削除されました。optimizer_use_invisible_indexes=falseセッションが変更されました。行長の長い行をある程度の範囲でレンジ検索し、最小値(min)を取得するものです。最大値(max)でも考え方は同じ。@demo3システムが変更されました。accessになりそうですよね。invisible索引が作成されました。optimizer_use_invisible_indexes=trueセッションが変更されました。00:00:00.00結果は、狙い通りになりました!処理時間は40msから10msへ。getsは約1/50に改善しました。ROWSという素敵なオペレーションが現れています。@demo3システムが変更されました。tab1_ix_demo3索引が削除されました。optimizer_use_invisible_indexes=falseセッションが変更されました。Loop結合でアクセスされるブロック数を最小化することはできますよね。@demo4システムが変更されました。m.unique_id2100行が選択されました。Informationからも駆動表(TAB2)と内部表(TAB1)は判断できると思います。駆動表(TAB2)はWHERE句の検索条件および結合条件でアクセスパスとなる列が参照されています。内部表(TAB1)はWHERE句では参照されておらず、結合条件でのみアクセスパスとなる列が参照されていることがわかります。BY句から、内部表(TAB1)のNON_UNIQUE_ID列も索引に含める必要があるとわかるはずです。access化に必要な索引列候補はSQL文だけでも見つけることができるんですよ。Informationに有益な情報が載っているので、できれば合わせて見ておくと吉ですね。場合もあるってことで。invisible索引が作成されました。invisible索引が作成されました。optimizer_use_invisible_indexes=trueセッションが変更されました。00:00:00.00大きなクエリほど効果は絶大ということで。1710msから50msに改善してます。@demo4システムが変更されました。m.unique_id2100行が選択されました。tab1_ix_demo4索引が削除されました。tab2_ix_demo4索引が削除されました。optimizer_use_invisible_indexes=falseセッションが変更されました。特殊部隊的に解決したぜ、という優越感もなくは無い。楽しい記事をありがとうございました。20時39分コメントを書く名前:メールアドレス:アドレス(URL):この情報を登録する内容:。