#jpoug Oracleの熱い話が聞けるJPOUG Tech Talk Night #6に参加してきたまとめ

oracle-tech-night-talk-6-eyecacth

公開日: 

Oracleに関するテックなトークが聞けるJPOUG Tech Talk Night #6が21cafeで開催されたので参加してきました。

ついでにいつもどおりまとめてみました。

固定化か?最新化か?オプティマイザ統計の運用をもう一度考える。

日本Oracle 柴田歩様

統計固定派/Bind Peek否定するようなお話

前提知識

【A-1】オラクル・コンサルが語る! SQLチューニングに必要な考え方と最新テクニック資料

Bind Peek をもっと使おうぜ!(柴田 歩) – JPOUG Advent Calendar 2014(Day 5) – from 歩 柴田

まだ統計固定で消耗してるの? – Bind Peek をもっと使おうぜ! 2015 Edition – from 歩 柴田
  • BindPeek
  • CardinalityFeedback
  • DynamicSampling
  • ヒストグラム
  • 拡張統計
  • SQLワークロード
  • SQL計画ディレクティブ
  • 適応計画
  • 固定化/最新化/Bind peekの組み合わせ

CBOの大事なこと

  • SQLのアルゴリズムは予測で組み立てられる
    • 全てのRDBMSに共通しているが、予測である以上ハズレがあるので、ハズレがありうるのを受け入れる
  • 【A-1】オラクル・コンサルが語る! SQLチューニングに必要な考え方と最新テクニック資料などは、CBOの性能を引き出して予測の制度を上げるという設計思想で資料を作っている
    • 予測と実測の乖離を補正することで、良い実行計画をたててもらうチューニング
  • CBOの予測精度を上げる機能を最大限に使っていく
  • 最適化機能を使うと予測精度が高く性能も良いプランが建てられる
    • 外れてもベストではないにしろ、リスクが低い計画にできる
  • フレッシュな統計と最適化機能を使っていこう

統計固定/BindPeek無効化をぶった斬る

  • ミッションクリティカルではBindPeekを無効化するのではなく、Oracleの有識者を常時アサインして管理することが推奨
  • 統計固定はリスクヘッジにならない
  • 性能劣化リスクでしか評価していないため悪化することがある → SQL性能、運用負荷なども加えて評価する必要がある

①固定化運用+最適化なし

  • 性能劣化リスクは抑えられるが、SQL性能は悪く、運用負荷もピンきりになる
  • 有識者がいないと全て意味がなくなる
  • うまく運用させるには有識者の常時体制が必要
    • SQLの実行計画は全て自分で運用するというモチベーションも必要

②最新化運用+最適化あり

  • 運用負荷とリスクヘッジのバランスがそこそこ良い
  • SQL性能がいいのはおまけと感じている
  • 12cで各種最適化機能とオプティマイザ統計の最新化運用が組み合わさると、多様なSQLが実行→ワークロードが蓄積→多様なヒストグラムや拡張統計が採取される→更に性能の良い実行計画が選択されるようになる

③最新化運用+最適化無し

  • 最適化機能がないため性能は低い
  • 複数のプランが使えないため、劣化する時は劣化してしまう
    • 12cの最適化ありだったら、ブレはあるものの、ちょっとずつかわりながら劣化が収束していく
  • BindPeekを無効化してもオプティマイザ統計を最新化している時点で実行計画は変動する

最新化運用+最適化ありの実績

  • 過去5年位で推進して実績はある
  • 9iR2→11gR2のUpgradeプロジェクトでは、CBO周りの問題はなかった
  • 複数システムを集約して、2NodeRacに集約した案件では、運用負荷の低減と性能担保を両立してコスト削減も実現した
  • マルチスタンバイ・DataGuard案件では、最新化運用+最適化ありでやったところ、性能周り、可用性関連の問題は無しで、年単位で無停止稼働を続けている
  • 12cR1での環境で、ポイントポイントにオプティマイザ統計を採取したところ、SQL性能は時間経過とともに改善している

まとめ

  • 実行計画のハズレを受け入れること
  • 統計固定化+最適化なしの運用は今後も生き残るが、メリットは薄れてきている
  • 統計最新化+最適化有りの運用がおすすめ
    • CBOの機能を引き出して予測精度をあげていくとバランスよく動く

QA

  • 統計情報を固定して、オプションをOFFにした時と、ONにした時で、外れた時のチューニングの負荷や難しさの割合はどれくらいか?
    • 外れても対策はあると思っていて、SPMが使えると思っている
      • もともといい実行計画で動いていて、悪くなったらSPMで実行計画を引っ張り出して固定する
    • SQLプロファイルで、とりあえずいいのがないかを見るのがいいと思われる
      • いいSQLプロファイルがあれば提案してくれる
  • ガチでチューニングしないといけない難しさはどれくらいか?
    • 最近はSQLヒントは難しくておすすめしていない
    • ヒントを見れば固定もできるが、ヒントだらけで人間業じゃなくなるので、やむを得ない場合を除いて推奨しない
  • 11gからBindPeekの弱点が、12cからアダプティブカーソルシェアリングのおかげで補われるとあるが、実行計画が働いてないことがある。確実に機能するとは限らないのか?
    • よくないプランができるということはインプットが足らないと考えている
    • 足りないのを補うには拡張統計などをとったりするとよくなったりする
    • それでもチューニングしきれない時は個別に対応するしかない
  • 最適化機能はSEでも使えるか?
    • SPMはEEの機能なので使えない
    • SQLプロファイルはチューニングパックが必要
    • それ以外はSEでも使えます
  • 11gと12cは性能のためにバージョンアップさせるのは作業に見合うか?
    • 性能のために12cにあげるのは正直レア
    • HWのEOSや、パッチの期間などで選ぶことが多い
  • 12cの移行計画を進めていて、SAPを使っている案件でインメモリを使ってカラム型にして、DWHも統合しようとしているが、どうおもうか?
    • SAPの速さを意識して作っている
    • 12cの新機能と組み合わせればDBメモリと併用して従来の型でも使えます
  • インメモリを使ってもパーティショニングは組んだほうがいいか?
    • 組み合わせて作っていったほうがいい
  • Cardinality FeedbackをOFFにしてはダメか?
    • 併用するといいという考えもあるのでお客の事情による
    • フィードバックする統計がわるくて変なことになったことがあるが、12cでよくなったかも
  • 実績紹介で統計情報を取得して性能がよくなったのはどれくらいのスパンか?
    • 統計情報の保留の機能を使って性能がよくなった
    • 実際は2回とったところだいぶ良くなった

鳥肌必須のニューラルネットワークによる近未来の画像認識技術を体験しIoTの知られざるパワーを知る

中嶋 一樹様

    • NeuralNetworkは機械学習の大きなカテゴリの一つ
      • 画像認識などできます
      • 自動運転で人や障害物を認識するなど
    • ホットなライブラリ
      • TensorFlow
        • Googleが公開
        • 昨年末にでてきた
      • IMAGENET
        • 同じ意味を表す単語について約1000個の画像を格納している
    • tf.oracle.tokyoで試せます
    • GoogleがCloudVisionAPIというので使えるようにしている

DEMO

この画像が何かを
oracle-tech-night-talk-6-demo-1-image

uploadしてみると
oracle-tech-night-talk-6-demo-2-upload

画像解析を行って候補を示してくれます
oracle-tech-night-talk-6-3-demo-upload-done

他にもリアルタイムでアップされた画像が表示されたりします
oracle-tech-night-talk-6-4-demo

最後に

Oracle運用TIPS大放出!〜RAC環境のRMANパラレル化を極める編〜

大田ネ右也様

  • RAC環境のRMANバックアップをパラレル化で高速にする
  • RAC3ノードでorclというインスタンスが存在していて、日時でバックアップセットをとっていた
  • RMAN処理を高速化するために、パラレル化、マルチセクションバックアップを採用してみた

しかし、上記だと、一つのノードでしかパラレルに動かないので、他のノードでもパラレルで動かすために下記のようにできる。

  • パラレル化をする際に考慮すること1
    • 1つのチャネルで1CPUコアを使う
    • 検証する際にはIO性能を最大限引き出せる数を設定して下さい
    • いっぱいはれば早くなるわけではない
    • 大きなデータファイルが存在する場合、そのチャネルでのバックアップ時間がネックになる
    • →マルチセクションバックアップを使うと大きなデータファイルを分割して取得ができます
    • パラレル化とマルチセクションバックアップはセットで検討しましょう
  • 考慮すること2
    • 1チャネルが停止した場合、RMANの処理はエラー終了する
  • その3
    • ノードが落ちてるところにチャネルをはると失敗する
  • 番外編:パスワードを埋め込みたくない場合はOracleWalletを使えばパスワードを書かなくても接続できるようになります
  • SQL*Plusを簡単に問い合わせ結果をExcel形式で出力するtips
    • set markup html onを使うと簡単に表がHTMLでひらけるようになるのでそこから簡単にコピペができます

なぜFlashback Dropを使わないの?

三原 健一様

  • 直近三年で2回使うことがあった
  • なぜ使わないのか?をヒアリングしてみた
    • ゴミ箱に入れるときのI/Oが気になる
    • ゴミ箱の容量が気になる
    • 新機能が不安
    • そもそもオペミスしない

検証してみた

  • 初期状態は640KBの表領域を作り、60%使っている状態の時にdropしてみた
    • 使用している表は一意制約と外部制約がついた表
  • EMP表をdropすると表と索引がrenameされる
    • extent freeは60%にふえるが、segment freeは変わらない
    • →同じ表領域の中で見えなくしてるだけです
  • PK制約もrenameされるが、FK制約は削除される
  • flasback dropすると、EMP表は戻るが、索引とPKはrenameされたままだが、FKは削除されたままになる

検証2

  • 新しくEMP1表と索引を作ってdropしてみたあとに、EMP2と索引を作ってみてdropするとエクステントは開放されているが、セグメントは汚れたまま
    • この状態でテーブルを作ると、今まで占領していたゴミ箱の領域を作って表を作ります
  • 索引のdropのみは純粋にゴミ箱に入らず、開放される

まとめ

  • テーブルをdropすると秋エクステントは増えるが、セグメントは残ったまま
  • 空きエクステントがあっても秋セグメントが存在しない状況があり得る
    • その状態の時は新たなテーブル作成時は古いゴミ箱セグメントを開放して領域を確保する
  • 動作としてはdropした時のSCNをみて古い方から開放しているように見える
  • 索引のみのdropはそのまま削除
  • あえてRECYCLEBINパラメータをOFFにする理由がわからない

その他

  • amazon RDS for OracleはRECYCLEBINのデフォルトoffだった
  • 10gのときはpurgeしてもメタデータだけが残っていたということがあった

@mogmetの所感

set markup html onは今まで知らなかったので衝撃的なtipsでした。

懇親会でも進言しましたが、こんなtipsだけを発表するOracle勉強会も開催されてもいいかなと思いました。

  • このエントリーをはてなブックマークに追加
  • Pocket

関連記事-こちらもどうぞ

  • 藤崎修助

    数秒で結果の返っていたsqlが、ある日突然数時間経っても終わらないような大ハズレ計画を簡単に引くというのは製品としての致命的なバグじゃないかと。

    • mogmet

      CBOとして運用する以上は、ハズレ計画を引いてしまうのはある程度のリスクとしてはありますが、オプティマイザも頭はよくなってきているので簡単に大外れ計画を引くことはないかと思います。
      また、Oracleの場合はハズレの計画を引いても対策をすることができる手段がいくつもあるので案外なんとかなります。

      また、如何にオプティマイザがちゃんとした実行計画の選択をしてくれるようにデータを設計するのがアプリ側の仕事になるので、製品のバグではなく、アプリ側の設計によるものが大きいかと思われます。

      • 藤崎修助

        実行計画を予想しながらデータ設計をなんて本来ありえない話です。
        データは情報を管理すべき形で確実に保持するように設計し、SQLはアルゴリズムを意識せず論理的に正しく最もシンプルな記述で現実的なパフォーマンスが得られる形があるべき姿だと思います。
        オプティマイザの様々な改善の取り組みが行われているものの、現実として大外れを引き、問題に対して事後で対応せざるを得ない中途半端な過渡期の技術水準から15年以上抜け出せていないのがrdbms製品全般をとりまく現状だと認識しています。

PAGE TOP ↑