Oracleに関するテックなトークが聞けるJPOUG Tech Talk Night #6が21cafeで開催されたので参加してきました。
ついでにいつもどおりまとめてみました。
固定化か?最新化か?オプティマイザ統計の運用をもう一度考える。
日本Oracle 柴田歩様
統計固定派/Bind Peek否定するようなお話
前提知識
http://www.oracle.com/webfolder/technetwork/jp/ondemand/ddd2013/A-1.pdf - www.oracle.com |
- 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ヒントは難しくておすすめしていない
- ヒントを見れば固定もできるが、ヒントだらけで人間業じゃなくなるので、やむを得ない場合を除いて推奨しない
- 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
- IMAGENET
- 同じ意味を表す単語について約1000個の画像を格納している
- tf.oracle.tokyoで試せます
- GoogleがCloudVisionAPIというので使えるようにしている
DEMO
この画像が何かを
uploadしてみると
画像解析を行って候補を示してくれます
他にもリアルタイムでアップされた画像が表示されたりします
最後に
Oracle運用TIPS大放出!〜RAC環境のRMANパラレル化を極める編〜
大田ネ右也様
- RAC環境のRMANバックアップをパラレル化で高速にする
- RAC3ノードでorclというインスタンスが存在していて、日時でバックアップセットをとっていた
- RMAN処理を高速化するために、パラレル化、マルチセクションバックアップを採用してみた
RUN {
ALLOCATE CHANNEL ch1 DEVICE TYPE DISK;
ALLOCATE CHANNEL ch2 DEVICE TYPE DISK;
ALLOCATE CHANNEL ch3 DEVICE TYPE DISK;
BACKUP DATABASE;
}
しかし、上記だと、一つのノードでしかパラレルに動かないので、他のノードでもパラレルで動かすために下記のようにできる。
RUN {
ALLOCATE CHANNEL ch1 DEVICE TYPE DISK CONNECT ’sys/password@orcl1';
ALLOCATE CHANNEL ch2 DEVICE TYPE DISK CONNECT ’sys/password@orcl2';
ALLOCATE CHANNEL ch3 DEVICE TYPE DISK CONNECT ’sys/password@orcl3';
BACKUP DATABASE;
}
- パラレル化をする際に考慮すること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してもメタデータだけが残っていたということがあった
set markup html onは今まで知らなかったので衝撃的なtipsでした。
懇親会でも進言しましたが、こんなtipsだけを発表するOracle勉強会も開催されてもいいかなと思いました。
View Comments
数秒で結果の返っていたsqlが、ある日突然数時間経っても終わらないような大ハズレ計画を簡単に引くというのは製品としての致命的なバグじゃないかと。
CBOとして運用する以上は、ハズレ計画を引いてしまうのはある程度のリスクとしてはありますが、オプティマイザも頭はよくなってきているので簡単に大外れ計画を引くことはないかと思います。
また、Oracleの場合はハズレの計画を引いても対策をすることができる手段がいくつもあるので案外なんとかなります。
また、如何にオプティマイザがちゃんとした実行計画の選択をしてくれるようにデータを設計するのがアプリ側の仕事になるので、製品のバグではなく、アプリ側の設計によるものが大きいかと思われます。
実行計画を予想しながらデータ設計をなんて本来ありえない話です。
データは情報を管理すべき形で確実に保持するように設計し、SQLはアルゴリズムを意識せず論理的に正しく最もシンプルな記述で現実的なパフォーマンスが得られる形があるべき姿だと思います。
オプティマイザの様々な改善の取り組みが行われているものの、現実として大外れを引き、問題に対して事後で対応せざるを得ない中途半端な過渡期の技術水準から15年以上抜け出せていないのがrdbms製品全般をとりまく現状だと認識しています。
Can you be more specific about the content of your article? After reading it, I still have some doubts. Hope you can help me.
I don't think the title of your article matches the content lol. Just kidding, mainly because I had some doubts after reading the article.