2014年12月17日水曜日

Oracle DBA & Developer Days 2014の資料が公開されたようです。

JPOUG Advent Calendar 2014の13日目のエントリです。
だいぶ遅れたプレゼントになりすみません。
ちょっと欲張ってJPOUG Advent Calendar 2014 二回目の登場になります。
1回目はこちら
今回も1nmくらい役に立つプレゼントになればと思ってエントリします。


さて、本記事のタイトルにあるように、
「Oracle DBA & Developer Days 2014 (DDD 2014)」の資料が公開されたようです。
以下サイトから資料がダウンロード出来るようです。

http://eventreg.oracle.com/profile/web/index.cfm?PKWebId=0x14073486e5

役立つ資料が山ほど入手出来るので、
サイトを紹介してこの記事を終わってもいいかなと思いましたが、
人の褌でうんぬんと言われそうなので、
私が担当したセッション内容についてポイントを説明しようと思います。


私が担当したセッションは
B1-4「クラウド:事例から見えてきたマルチテナント・アーキテクチャとOracle Database 12c新機能の活用ポイント」の
後半パート「Oracle Database 12c新機能の活用ポイント」になります。
39スライド辺りからです。

はじめに、41スライドの注意事項を読んで資料を活用頂きたいと思います。
この資料の内容や以下に記載する内容も、
PSUや個別パッチを適用することにより動作が変わるかもしれないので
気をつけて下さい。

まずFlex ASMについて話しをしました。
・Oracle Database 12c リリース1 (12.1.0.1)から、Oracle DatabaseやClusterwareにおいて、
 RAWストレージ・デバイスの直接の使用がサポートされなくなった※1
・ASMインスタンスの使用メモリはデフォルトで約1GB、推奨は1.5GBほど。
・Flex ASMを使用していれば、接続先のASMインスタンスが停止しても
 他ノードのASMインスタンスに自動的に接続してくれて、
 DBのダウンやエラーを返さず業務を継続できる。
・2ノードRACで(カーディナリティ)をALLに設定するとASMインスタンスは2つになります。
 ※デフォルトではASMインスタンスが3つリソース登録されます。
・10.1~のDBと共存できるが、12.1以前のリリースのインスタンスはFlex ASM機能に対応していないので、
 その場合はカーディナリティ数をALLに設定する必要がある

次にCHMですが
・Oracle Database 12c リリース1 (12.1.0.2)から、管理者管理のRACでもMemoryGuardが動作する。
・MemoryGuardはノードの空きメモリが少ない状態になった場合などに、
 データベース・サービスリソースを自動的に停止する動きをする。
・リポジトリDBを停止してもMemoryGuardの動作は停止しない。
・メモリの設計に注意しよう。
・CHMの停止でMemoryGuardは停止する
・リポジトリDBやCHMを停止して良いかは念のためサポートに問い合わせて
 ⇒その結果を誰かフィードバックしてほしい。

ADOについては書いてある内容通りを説明しました。
ADOを実装するのに必要となったのであろう以下機能を説明しました。
・オンラインデータファイル移動
 処理中は領域が2倍必要になるので注意。
 また、オラクル社でオンラインと名のつく機能はだいたい、、※2
・オンラインパーティション移動
 移動処理中に対象のパーティションに更新処理が実行されても、
 更新処理は待機しない。
 逆に、移動処理は更新処理がcommitやrollbackされるまで、
 enq:TX -row lock contentionで待機する。
 オンラインで実行出来るからと言っても、実行タイミングの考慮は必要。

コントロールグループ(プロセッサ・グループ)/
初期化パラメータPROCESSOR_GROUP_NAME※3
・OS(カーネル)の機能を利用している
・L1~L2キャッシュを特定インスタンスで占有できる?
・NUMA nodeも指定出来るようなので、遠くのRAMを見に行かなくていいかも。
・JPOUGのボードメンバーでもある新久保氏は、I/O制御も検証していた。※4
 夢が広がる。
・Standard Editionでも使える
・マルチスレッドアーキテクチャはNUMA nodeを指定してインスタンスとRAMを固定化した際に、
 固定化されたRAMを有効活用するために作られたのではないかと妄想している。

オプティマイザ周りの新機能については、スライド75のイメージで全体像で覚えることが
大切だという話をしました。※5
・適応計画
 バインド依存カーソルや述語(where句)が複雑な場合に非効率な実行計画を選択してしまっても、
 ましな実行計画に変更してくれる。
 駆動表からの取得行数が多い場合にネステッドループ結合が発生すると悲惨だが、
 この機能が動作するとハッシュ結合に変更してくれてまだましな状況となる。
・動的統計については前回の投稿に書いたような内容を説明
・自動再最適化
 統計が不正確である、述語が複雑な場合に統計情報を補ってくれる
 カーディナリティ・フィードバックの進化機能
・SQL計画ディレクティブ
 統計情報を取得してもディレクティブは残るが動作しない。(再解析、ディレクティブ評価後)
 ディクショナリにディレクティブが山ほどついていることがある
 OPTIMIZER_ADAPTIVE_FEATUREをFALSEにしても動的統計は無効化されないので注意
・オプティマイザ機能使用方針検討ポイント
 システムの要件に合わせて、これら機能を使うか止めるかを判断するのが良い
 適応計画はEEライセンスが必要だ
・バルク・ロードのためのオンライン統計収集
 CTASや空テーブルへのダイレクト・パス・インサートでも取得されるようになった。
 (索引は作成時に自動的に統計情報が取得されるのと似た動作だ)
 インデックス統計、ヒストグラムは収集されないので注意。
 あくまでも統計情報取得時間を短縮するための動作だ。

参考情報
※1:Oracle® Databaseプラットフォーム共通日本語README12cリリース1 (12.1)
    2.3 Oracle Databaseで非推奨またはサポート終了となった機能
※2:Oracle® Databaseライセンス情報 12cリリース1 (12.1) エディション別の使用可能な機能
※3:設定方法等は以下ドキュメントが参考になります。
  My Oracle SupportドキュメントID 1585184.1
    「Using PROCESSOR_GROUP_NAME to bind a database instance to CPUs or NUMA nodes on Linux」
※4:10046 trace name context foreverブログ
    12cでリソースの共有と非共有のはざまで... その3 
   JPOUG Advent Calendar 2013のネタです
※5:Oracle® Database SQLチューニング・ガイド12cリリース1(12.1) 適応問合せ最適化について


JPOUG Advent Calendar 2014
明日の扉はsabotage さんです。よろしくお願いします。

2014年12月6日土曜日

optimizer_dynamic_sampling=11

久々の投稿となります。
今日は、JPOUG Advent Calendar 2014の6日目のエントリです。
1µmくらい役に立つプレゼントになればと思ってます。


前日の第三の柴田ことgonsuke777さんが「Bind Peek を もっと使おうぜ!」という
煽り記事を書いていましたので、
私も呪文のように唱えられるoptimizer_dynamic_sampling=0で有名な
動的統計(動的サンプリング)の12cの今について書こうと思います。

動的統計は12c(または11.2.0.4.0リリース)以前は動的サンプリングという名前でした。
機能を単純に説明すると、オプティマイザ統計(俗に言う統計情報)が
不十分な場合にそれを補完(補填?)するための機能です。

第三の柴田がBind Peekを使おうと言っていますが、
それだって不十分な統計情報のもと使っても何の意味もありません!
なぜなら、Bind Peekは与えられたバインド変数をもとに実行計画を生成しますが、
その元ネタとなるのは統計情報だからです。
そんな不十分な統計情報を補うための機能、動的統計こそ至高!!


のはずですが、
・実行計画が変わる要素となる
・この機能が動くと実行計画の生成時間(解析時間)が長くなる

という理由でBind Peekと同じ道を歩むかのように無効化されてきました。。
(optimizer_dynamic_sampling=0設定)
※2個目の理由はシビアなレスポンスが求められるシステムでは
 止めることもよいとは思います。



そんな動的統計が12c(11.2.0.4.0含む)で進化を遂げます。
それがoptimizer_dynamic_sampling=11設定です。
11に設定するとどのような動作になるか。


Oracle® Database SQLチューニング・ガイド12cリリース1(12.1) B71277-02 では
オプティマイザで動的統計を使用するタイミングは「オプティマイザが必要と判断した場合は、
自動的に動的統計が使用されます。結果の統計は統計リポジトリ内で永続的であり、
他の問合せに対しても利用できます。」
サンプル・サイズ(ブロック)は「自動的に決定」となっています。

分かり難いですよね。
私が検証した結果からは、以下のように言いかえられると思いました。
-----
今までのレベル1~4の条件に合致した場合やSQLがパラレル実行された場合に動作するとともに、
SQL計画ディレクティブで動的統計の収集が登録されている場合や、
統計情報が失効した場合にも収集するようになった。
※通常、最後に統計情報が収集されて以降、表内の10%以上の行が変更されると、
 統計情報は失効したとみなされます。

また、動的統計として動的統計取得対象のSQLについて共有プールのSQL領域内、
または自動ワークロード・リポジトリ(DBA_HIST_XXX)から
去のSQL実行時の統計を取得することにより、
他の問合せでも利用できる。
-----


端的に書くと以下がポイントになると思います。
=====
★統計情報が失効している場合にも動的統計が取得出来るようになった
 11.2.0.3.0までは統計情報が取得されていない場合には動的統計が動きましたが、
 統計情報が陳腐化した場合にも動作してくれるようになった。
 ⇒バッチ処理時などのワーク表やデータ量・割合の変動が大きい表も
  取得対象となります。
  (今までは統計情報NULLでロックし、動的統計を動かすというような手法で対応していた)


★動的統計は過去の実行時統計を再利用している
 DBA_HIST_SQLSTATやV$SQLなどから過去の実行結果を参照して、
 動的統計情報を取得しているように見えます。
 ※詳細を調査したい人はSQLトレースを取得するといいと思います。
 いうなれば、第三の柴田が言っていた、
 カーディナリティフィードバック(12cでの名称は自動再最適化の統計フィードバック)が
 動作するようなイメージです。
 ⇒12cより前のリリースでは、動的統計もカーディナリティフィードバックもSQLカーソルが
  エージアウトすると折角取得した統計情報補完情報が失われていた。
  ※カーディナリティフィードバックの補完情報は今のリリースでも失われます。
===


また、統計情報が失効しているオブジェクトを参照する他のSQLや
SQLカーソルがエージアウトされて、カーディナリティフィードバックの情報が失われても、
統計情報を補完した状態でSQLを実行出来るようにするために追加された機能が、
そう、SQL計画ディレクティブ!!(のはず)


と、12cではオプティマイザ周りの機能が色々と進化していますが、
長くなるので今日はここまで。
これら機能を使う使わないなどの考え方は、
第三の柴田がDDDで説明した資料を参考にするとよいと思います。



最後に注意点を記載しておくと、

・統計情報が失効している場合や過去のSQL実行統計から情報を取得する動作は
 optimizer_dynamic_samplingが11に設定されている場合のみ動く

・DYNAMIC_SAMPLINGヒントでは11を指定しても無効(有効範囲は0~10)
 Oracle® Database SQL言語リファレンス 12cリリース1 (12.1)

・SQL計画ディレクティブにより動的統計収集が実行される場合は、
 optimizer_dynamic_sampling=2が設定されていても11の動作となる。
 停止したい場合には、optimizer_dynamic_sampling=0の設定が必要。

・OPTIMIZER_ADAPTIVE_FEATURES=FALSEを設定しても動的統計の機能は停止しない


また、とても重要な点として、
レベル11の設定は11.2.0.4.0や12cからの新機能(機能拡張)なので、
検証を十分に実施してから使用するのが良いと思います。
※デフォルトの設定はoptimizer_dynamic_sampling=2となっています。


ではでは、「第三の柴田」というキーワードが流行ることを願いつつ
これを機会に今後は12cネタをぽつぽつ書いていこうと思います。



JPOUG Advent Calendar 2014、
明日の扉は渡辺 剛 さんです。よろしくお願いします!