WR blog

about Enterprise IT, Oracle Database, Jazz/Fusion Music, etc…

WR blog RSS Feed
 
 
 
 

Posts tagged Oracle

おかげさまでUnconferenceは大盛況でした!

JPOUGがお送りした最初のイベント、Oracle OpenWorld Unconference presented by JPOUG は、おかげさまで大盛況で終了しました! ご参加していただいた皆様、貴重なお時間を割いていただき、どうもありがとうございました!

私は、「バッチ処理にバインド変数はもうやめません? ~バッチ処理の突発遅延を題材にして考えてみる~」と題して、バッチ処理における突発的な処理遅延についてお話させていただきました。

少しセッション時間が短かったこともあり、駆け足での一方的な説明になってしまい、Unconferenceというよりは通常のセミナーになってしまったな・・・ と思っていたところ、セッションの最後の質問タイムで、聴講いただいた方と意見の交換をすることができ、Unconference的なエッセンスを入れ込むことができたように思っています(結果オーライw)。 Nさん、ご質問いただきありがとうございました!(感謝感激)

また、幸運なことに、本セッションの前に、SQLのバインド変数化という題材をOLTPの観点で、sh2さんにご説明いただいていました。本セッションではOLTPではなくバッチの観点で説明しましたので、同じ題材をそれぞれのセッションで異なる観点で説明で来た形になり、聞いていただいた方がより理解を深めることができたのではと考えています。sh2さん、ありがとうございました!

Oracle Database経験者がMySQLの設計思想を知っていろいろ考える会

当日発表に使用した資料を以下においておきます。

さて、ご参加いただいた方は実感されたとは思いますが、日本オラクルさま主催のセッションとはかなり色合いの異なる内容になっています。(マニュアル活用方法を題材にしたエンジニアのスキル向上に関するアドバイスしかり、MySQLとOracle Databaseの比較しかり・・・) 私個人の意見ですが、この点が 日本オラクルさまでなく、JPOUG がイベントを企画する大きな意味であると思っています。 今回のイベントの雰囲気を伝えるtweetは、Oracle OpenWorld Unconference presented by JPOUG - Togetter にまとまっています。(楽しそうでしょ?) 6月を目標に次回イベントを企画中です。企画が進行しだいイベント情報を発信させていただきますので、 ぜひFacebookページに「いいね!」してみてください!

Facebook - JPOUG fanpage

ご支援いただいた皆様に感謝したいと思います。

Oracle OpenWorld Tokyo 2012事務局のみなさま、OTN事務局のみなさま、Unconferenceをご支援いただきありがとうございました。まだ立ち上がったばかりの団体に対して、貴重な場を提供いただき、まことにありがとうございました。

セッションをご担当いただいたスピーカのみなさま、ありがとうございました。業務などで多忙な状況で、準備や調整を実施いただいたかと思います。みなさまのおかげで、イベント全体のセッション内容を、バリエーションに富んだ、より価値あるものにできました。まことにありがとうございます。

最後に、私のこのような活動に理解を示してくれている、職場のみなさん、ありがとうございます! 私が心置きなくセッションを担当できたのも、みなさんのおかげです! 感謝してもしきれません、ありがとう!!!

Oracle OpenWorld Unconference presented by JPOUG

JPOUGがお送りする最初のイベントは、Oracle OpenWorld Unconference !! Oracle OpenWorld Tokyo 2012の最終日(4/6(金))に 12:30から18:00ごろまで開催します!

Unconference とは、少なめの人数でスピーカーとリスナーがいろいろやり合いながらすすめる ユニークな形式のセミナー(?)です。 oracletech.jpにも紹介記事があります。こちらを見ていただくと、よりイメージをつかめるかも・・・

Oracle OpenWorld の特別セッション「Oracle OpenWorld Unconference presented by JPOUG」

場所は 六本木アカデミーヒルズ49 です。以下のURLの地図も合わせてご覧ください!

http://www.oracle.com/openworld/jp-ja/access/index.html

http://www.academyhills.com/forum/room/49/index.html

開催時間帯は、JPUOGメンバーが 誰かしら会場にいるはずです。Oracle製品に携わるエンジニアのお祭りです。楽しみましょう!

なにかご要望やご意見がある方は、Facebookページにコメントを。

Facebook - JPOUG fanpage

ついでに「いいね!」してもらえるとうれしいです。

JPOUG Webサイト & Facebookページ公開! + IOUCに参加

またまた久しぶりなBlogの更新となっております・・・

去年から運営メンバーの一員として打ち合わせなどに参加してきましたが、 JPOUG (Japan Oracle User Group)のWebサイトを立ち上げることができました。

JPOUG (Japan Oracle User Group) - http://www.jpoug.org

あわせて、各種の交流やイベント告知などの情報発信のため、Facebookページも作成しています。 もしよろしければ、アクセスいただき、「いいね!」をお願いいたします。

Facebook - JPOUG fanpage

また、JPOUGがIOUC(International Oracle Users Group Community)へ参加することに決まりました。

http://www.iouc.org/p/cm/ld/fid=45&region=14&gid=590

Oracle製品ユーザーの交流を深めましょう!!

9/30(金) Oracle LOVERS2 でお話させていただきました。

Blogの更新が滞り、申し訳ございません・・・ 9/30(金) Oracle LOVERS シーズン2 第2回 でお話させていただきました。

50名強(もしかするとそれ以上)という多くの方にご出席いただいただけでなく、 著名なOracleエンジニア方々の前で話すということで、非常に緊張いたしましたが 主催者の吉田さんのご配慮もあり、楽しい時間をすごすことができました。

Oracle LOVERS シーズン2 第2回 - oracletech.jp Oracle LOVERS シーズン2 第2回 - Zussar

わざわざ貴重なお時間を割いて、ご参加いただいた皆様、ありがとうございました。 実際の業務に有用な情報を1つでもご提供できたらうれしく思います。

また、主催者の吉田さん、いつもありがとうございます。 吉田さんの人柄がなせるものと思いますが、Oracle LOVERSはいつもリラックスした楽しい雰囲気で、 とてもすばらしいですね。 お忙しいとは思いますが、今後もぜひOracle LOVERSを継続していただけたらと思います。

今回の発表資料を公開する予定はありませんが、前半部分のデモで多用した DBMS_XPLAN.DISPLAY_CURSORの使い方については過去のBlogエントリの内容が参考になると 思いますので、以下にリンクを張っておきます。参考にしていただければ幸いです。

SQLパフォーマンス問題調査でEXPLAIN PLAN、SQLトレースは(ほとんど)使わない DBMS_XPLAN.DISPLAY_CURSORの使い方とちょっとした落とし穴 DISPLAY_CURSORでCBOの見積りミスを簡単に確認する

それでは・・・

フィルタ述語とアクセス述語 (実行計画の読み方#3)

さて、これまでで、実行計画のツリーのたどり方と、ツリーの構成要素である各オペレーションで 実行されている処理の概要がわかったと思います。

しかし、これだけの情報では、実行計画と実行されたSQLのWHERE条件を対応づけて理解することは 難しいです。(できなくはありませんが、かなり推測に頼る形になります。)

SQLのWHERE条件と対応付けるためには、フィルタ述語とアクセス述語に着目する必要があります。

Predicate Informationセクション

実行計画をDBMS_XPLAN.DISPLAY_CURSORで取得した場合、フィルタ述語とアクセス述語に関する情報は Predicate Informationセクションに表示されます。

—————————————————————————————– | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | —————————————————————————————– | 0 | SELECT STATEMENT [...]

オペレーションの一覧と最低限覚えておくべきオペレーション (実行計画の読み方#2)

先のエントリの説明で、実行計画をいわば「形式的には読める(*1)」ようにはなりました。 しかし、実行計画が何をやっているのかという、意味的な観点では「理解できていない」はずです。 実行計画の処理内容を理解するためには、実行計画を構成するオペレーションの処理内容を理解する 必要があります。

(*1) 「たどれる」という表現のほうが近いかもしれませんが・・・

オペレーションの一覧

Oracle Databaseには非常に多くのオペレーションが存在し、 大部分のオペレーションについては、マニュアルの以下の箇所で説明されています。

10.2 11.1 11.2

最低限覚えておくべきオペレーション

全てのオペレーションに関して説明することは、現実的でないため、 先のエントリで説明した実行計画に含まれるオペレーションを説明します。 なお、このエントリに含まれるオペレーションは、非常に多くの実行計画で使用されうる、 非常に重要なものであり、最低限覚えておく必要があります。

—————————————————————————————– | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | —————————————————————————————– | 0 | SELECT STATEMENT [...]

JPOUGに参加させていただきました!

インサイトテクノロジーの新久保さんの想いに共感し、Japan Oracle User Group - JPOUG にメンバーとして参加させていただきました!

Oracle Database Userのみなさんに役立つ活動を行っていきたいと思います! 何かご意見がありましたら、twitterやblogのコメント欄で頂戴できればうれしいです!

実行計画のツリーのたどり方 (実行計画の読み方#1)

これまでのエントリに記載してきたように、実行計画は階層的なツリー構造で表現 されます。 本エントリでは、実行計画の読み方のfirst stepとして、 実際の処理順序に即したツリー構造のたどり方を説明します。

SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, ‘LAST’));

PLAN_TABLE_OUTPUT ——————————————————————————————— SQL_ID dvv5bah5b4k51, child number 1 ————————————- SELECT /*+ FULL(PA) INDEX(CH idx_chpa) USE_NL(CH) LEADING(PA) */ cid, cname, pa.pid, pname FROM ch, pa WHERE ch.pid = pa.pid and pa.pid = 1

Plan hash value: 3514264536

—————————————————————————————– | Id | Operation [...]

実行計画の読み方

これまでのエントリで、DBMS_XPLAN.DISPLAY_CURSORをつかってV$SQL_PLAN から実行計画を取得する方法をオススメしてきました。 この方法は、手軽であり、かつ、SQLトレースやEXPLAIN PLANの問題点に対処できる 優れた方法であることがお分かりいただけたかと思います。

しかし、当たり前の話ですが、実行計画を取得できたとしても、読めなければ意味がありません。 このため、取得した実行計画の読み方をこれからいくつかのエントリで説明したいと思います。

以下の構成で進める予定です。(エントリ記載次第、リンクを張る予定)

実行計画のツリーのたどり方 オペレーションの一覧と最低限覚えておくべきオペレーション フィルタ述語とアクセス述語 結合の動作イメージとオペレーション

自身の経験上、実行計画の読み方は一度の説明で理解しにくいようです。 このため、一連のエントリでは、わざと同じようなことを何度も繰り返し説明するような 形にしています。

SQLチューニングアドバイザの代用品としての動的サンプリング

先のエントリ で、実行計画の見積もりミスの可能性を調べるため、CBOの見積もり行数と実行時行数の 差異をチェックする方法をお伝えしました。 実際にCBOの見積もり行数と実行時行数の差異が大きいSQLを見つけた場合は、 現在使用している実行計画が最適かどうか、最適な実行計画はどのようなものかを 検討する必要が出てきます。

しかし、この作業は簡単なものではありません。 先のエントリ の例は、1つのテーブルにのみアクセスするきわめてシンプルなものであり、 テーブルスキャン(TABLE ACCESS FULL) よりもインデックススキャン (INDEX RANGE SCAN) が効率的であるとすぐにわかりました。 しかし、通常のアプリケーションではSQLはもっと複雑であり、 最適な実行計画の検討は、Oracle Databaseに関するSQLチューニングスキルが必要であり、時間もかかる作業です。

Oracle Database 9.2 以前など、アドバイザ機能が充実していなかったバージョンを 使用していたときは、スキルを持ったデータベースエンジニアが、さまざまな角度から 検討し、最適と思われる実行計画を検討していたと思います。 この作業は、実際に効果が得られるかどうか不透明なわりに、時間と労力を要する非効率的なものでした。 チューニング作業は、時間をかければかけただけ、必ず改善されるという保障があるわけではないという 側面があるからです。

Oracle Database 10g以後では、アドバイザ機能が充実し、SQLチューニングアドバイザ を活用して、Oracle Database が自動的に最適な実行計画を作成してくれるように なっており、作業コストを大幅に削減できます。 しかし、SQLチューニングアドバイザを使用するためには Enterprise Edition の利用に くわえて、別売のオプション機能 Diagnostic Pack と Tuning Packが必要であるため、 使用できる人が限られるのが現実ではないでしょうか。

動的サンプリングによる最適な実行計画検討の自動化

実は、動的サンプリングという機能を使うことで、SQLチューニングアドバイザが使用で きない場合でも、最適と思われる実行計画の検討をOracle Database任せにすることが できます。

Profile

渡部亮太 / Watabe Ryota
代官山在住のOracle Database Engineer。 株式会社コーソル所属。講演/講師業もぼちぼち。書籍「プロとしてのOracle運用管理入門」「プロとしてのOracleアーキテクチャ入門」買ってくれるとうれしいなっと。 twitter:wrcsus4

Book



Other Works

Certifications

  • Oracle Master 10g Platinum
  • Oracle Master 11g Gold
  • Oracle Master Silver Oracle PL/SQL Developer
  • Oracle Master Expert 10g RAC
  • Oracle Master Expert Oracle on Linux
  • LPIC level2
  • CCNA
  • 日商簿記3級

Contact

wrcsus4 _at_ gmail _dot_ com

Archives

Recent Posts

Recent Comments

Categories

Tags

Meta