Hatena::ブログ(Diary)

ablog このページをアンテナに追加 RSSフィード Twitter

2016-12-07

Oracle DBA & Developer Day 2016 で発表しました

f:id:yohei-a:20161207232241j:image:w640

2016/10/27(木)に開催された Oracle DBA & Developer Day 2016 で、

オラクル・コンサルが語る! SQL性能を最大限に引き出すDB 12cクエリー・オプティマイザ 新機能活用と統計情報運用の戦略」

というお題で柴田歩さんと発表しました。


スライド

Oracle DBA & Developer Day 2016のプレゼンテーション資料とセッションの収録動画


サマリ*1

f:id:yohei-a:20161207233937p:image:w640

f:id:yohei-a:20161207233934p:image:w640

f:id:yohei-a:20161207234558p:image:w640

  • 12.1 では適応計画で実行中に実行計画補正、SQL計画ディレクティブでフィードバックが永続化されるようになった。

f:id:yohei-a:20161209075622p:image:w640

f:id:yohei-a:20161207234911p:image:w640

f:id:yohei-a:20161209075618p:image:w640

f:id:yohei-a:20161209075620p:image:w640

f:id:yohei-a:20161209080623p:image:w640

f:id:yohei-a:20161209080621p:image:w640

f:id:yohei-a:20161209080619p:image:w640

f:id:yohei-a:20161209080617p:image:w640

f:id:yohei-a:20161209080615p:image:w640

  • 12.2 では世の中でもっとも多い(だろう)タイプのシステムにデフォルトを合わせた。

f:id:yohei-a:20161209080613p:image:w640

  • 12.2 では適したシステムは有効化して使ってくださいという方針になっている。

f:id:yohei-a:20161209080611p:image:w640

  • 12.1 でもパッチ(Patch:22652097、Patch:21171382)で 12.2 の動作に変更することが可能。

f:id:yohei-a:20161209080817p:image:w640


参考


過去のDDD資料


私的備忘録

f:id:yohei-a:20161208021012j:image

2016/10/24 AYU(柴田歩)さんと表参道の夜景をバックに最近オラクル青山センターにできた初カフェテリアで打合せ。DBのプロダクトマネジャーのMariaとディスカッションできて有意義だった。自分達の考えてた方向性と同じだった。

複雑なクエリ統計からのカーディナリティ見積が困難なケースに対応してきた適応計画、ディレクティブ(動的統計統計フィードバック、拡張統計)。12.2 でデフォルト false になった心。統計固定時のLOW_VALUE、HIGH_VALUE はデータ型の最小、最大に。など考えてた通りだった。ディレクティブからの拡張統計は単表のみという指摘は助かった。

*1:以下で紹介しているスライドは公開版資料に含まれないものがあります

2016-12-05

シンプルでシステマチックな Oracle Database 性能分析 with AWR & OS Watcher

JPOUG Advent Calendar 2016 の5日目のエントリーです。

昨日は id:knopp さんの Oracle RAC on Docker - KNOPP’s blog でした。


2012年から始った JPOUG Advent Calendar も今年で 6 年目になりました。

今年は私が AWRレポート*1OS Watcher を使って Oracle Database の性能分析をどのようにしているかを紹介します。

このエントリが抽象的で分かりにくいと感じる方は 運用ヘルスチェックでトラブルを予防しよう! を見てみてください。


3つのポイント

ベースラインと比較する
  • 健康診断血圧や心拍数に個人差があるように、データベースのパフォーマンスはシステム特性によって差があるためベースライン(平常時の基礎値)をとります。

P.12

f:id:yohei-a:20161205080450p:image:w360

時間単価ベース分析
  • 「単価 = DB Time / 仕事量(SQL実行回数など)」の式でベースラインと比較します。
  • DB Time はプロジェクトでいう総工数、ベースラインと比較して増えた場合はシンプルに仕事量が増えたか、単価が高くなったかのどちらかになります。
    • 業務量が増えた場合は、CPUなどのリソース使用量を確認し、必要に応じてリソース増強を検討します。
      • 例)日銀の黒田砲でオンライン証券システムの取引量が急増した。
    • 単価が高くなっている場合は何らかの異常がある可能性があるので、深堀調査します。

Oracle Performance Firefighting P.30

f:id:yohei-a:20161205225248j:image:w360

3-Circle Analysis
  • OSDBインスタンス、高負荷SQLの3つの観点で分析することで、誤った分析を防ぎます*2
    • 例えば、OSレベルでCPUなどのリソース使用量はどれだけか、DBはそのうち何割を使用しているか*3、さらに上位のSQLが何割を占めているか。

P.5

f:id:yohei-a:20161205075427p:image:w360


分析手順


定常的な情報収集


分析レポート目次

3-Circle Analysis をそのまま目次構成に使います。

f:id:yohei-a:20161205080229p:image:w360

  1. はじめに
    1. 本文書の目的
    2. 分析アプローチ
    3. 分析範囲
      1. 分析対象データベース … 対象DBハードウェア、ソフトウェア構成、バージョンなど
      2. 分析情報 … AWRレポート、OS Watcher などと対象期間、取得頻度など
    4. その他
      1. 参考情報 … My Oracle Support など
  2. 分析結果サマリ
    1. 全体サマリ
      1. 分析結果
        1. OS分析結果
        2. DBインスタンス分析結果
        3. SQL分析結果
      2. 要改善項目
      3. 要経過観察項目
  3. 分析結果詳細
    1. OS分析結果
    2. DBインスタンス分析結果
    3. SQL分析結果

分析項目例

"チェック内容"はあくまで一例です。監視閾値などに合わせて変更します。

OS*4
項目チェック内容分析対象データ分析対象項目
CPU使用率100%に達している時間帯がないか
sys が 40% を超えていないか
OSWatcher[vmstat]-[usr + sys + st]
ランキューCPU数*2を超えていないかOSWatcher[vmstat]-[r]
CPU別使用率特定のCPUで100%で張り付いている時間帯がないか
sys が 40% を超えていないか
OSWatcher[mpstat]-[user + system + steal + intr + soft]
  • メモリ
項目チェック内容分析対象データ分析対象項目
メモリ使用率実質使用量が80%を超えていないかOSWatcher[meminfo]-[(MemTotal-(MemFree+Active(file)+Inactive(file)))/MemTotal]
メモリ使用率内訳ページテーブルスラブキャッシュなどのサイズが想定外に大きくないかOSWatcher[meminfo]-[PageTables,Slab]
ページング発生状況ページイン/ページアウトが発生していないかOSWatcher[vmstat]-[si, so]
スワップ領域使用率スワップが発生していないかOSWatcher[vmstat]-[swpd]
項目チェック内容分析対象データ分析対象項目
I/Oレスポンス20ms を上回っていないかOSWatcher[iostat]-[await]
I/Oサービスタイム10ms を上回っていないかOSWatcher[iostat]-[svctm]
ディスクビジー率80%を上回っていないかOSWatcher[iostat]-[%util]
IOPSカタログスペックを超えていないか*6OSWatcher[iostat]-[r/s. w/s]
DBインスタンス
  • 仕事量
項目チェック内容分析対象データ分析対象項目
SQL実行回数 なし*7AWR Report[Load Profile]-[Executes]
トランザクションなしAWR Report[Load Profile]-[Transactions]
ログオンユーザー数なしAWR Report[Key Instance Activity Stats]-[logons cumulative]
REDO生成量 なしAWR Report[Load Profile]-[Redo size (bytes)]
ハードパース回数なしAWR Report[Load Profile]-[Hard parses]
物理読込量 なしAWR Report[Load Profile]-[Physical read ]
論理読込量 なしAWR Report[Load Profile]-[Logical read]
インターコネクト通信量なしAWR Report[Load Profile]-[Global Cache blocks received] / [Global Cache blocks served]
  • DB処理時間
項目チェック内容分析対象データ分析対象項目
アクティブセッションアクティブセッション数がCPU_COUNTを超えていないかAWR Report[Wait Classes by Total Wait Time]-[Avg Active Sessions]
時間モデル統計なしAWR Report[Time Model Statistics]
待機クラスなしAWR Report[Foreground Wait Class]
Top N 待機イベントenqueue、latch、mutex等の割合が高い場合は深堀調査を行う
平均待機時間が長い待機イベントがないか
AWR Report[Top 10 Foreground Events by Total Wait Time]
I/Oレスポンスdb file sequential read
db file scattered read
direct path read
log file sync
log file parallel write
などが 20ms を上回っていないか
AWR Report[Foreground Wait Events]
[Wait Event Histogra]
[Wait Event Histogram Detai]
キャッシュフュージョン平均ブロック転送時間10ms を上回っていないかAWR Report[Global Cache and Enqueue Services - Workload Characteristics]-[Avg global cache cr/current block receive time (ms)]
  • メモリ使用状況
項目チェック内容分析対象データ分析対象項目
共有プール内訳特定コンポーネントが大きくないかAWR Report[SGA Breakdown Difference]
ラージプール内訳特定コンポーネントが大きくないかAWR Report[SGA Breakdown Difference]
共有プール・ラージプールの immediate 拡張有無immediate 拡張が発生していないかAWR Report[Memory Dynamic Components]
バッファキャッシュヒット率なしAWR Report[Instance Efficiency Percentages]
RACバッファキャッシュヒット率なしAWR Report[Global Cache Efficiency Percentages (Target local+remote 100%) ]
ライブラリキャッシュヒット率なしAWR Report[Instance Efficiency Percentages]
BufferPoolAdvisoryバッファキャッシュ拡張によりI/O量削減の可能性が高いかAWR Report[Buffer Pool Advisory]
PGA使用量PGA_AGGREGATE_TARGET を超えていないか AWR Report[PGA Aggr Target Stats]
PGA AdvisoryPGA拡張によるSQL実行時間短縮の可能性が高いかAWR Report[PGA Memory Advisory]
高負荷SQL
項目チェック内容分析対象データ分析対象項目
実行回数の多いSQL(総計) ベースラインおよび他の期間との比較AWR Report[SQL ordered by Executions]
物理読込量の多いSQL(総計/1回当り) 時系列で右肩上がりで増えているSQLがないかAWR Report[SQL ordered by Reads]
論理読込量の多いSQL(総計/1回当り) 時系列で右肩上がりで増えているSQLがないかAWR Report[SQL ordered by Gets]
CPU時間の長いSQL(総計/1回当り) 時系列で右肩上がりで増えているSQLがないかAWR Report[SQL ordered by CPU Time]
クラスタ待機時間の長いSQL(総計/1回当り) 時系列で右肩上がりで増えているSQLがないかAWR Report[SQL ordered by Cluster Wait Time]
共有メモリ使用量の多いSQL(総計) 共有メモリ使用量が 100MBを超えているSQLがないかAWR Report[SQL ordered by Sharable Memory]
Version Count の多いSQL(総計) 時系列で右肩上がりで増えているSQLがないかAWR Report[SQL ordered by Version Count]
実行時間の長いSQL(総計/1回当り) elapsed が undo_retention を超えてい るSQLがないか(1回当たり)AWR Report[SQL ordered by Elapsed Time]

私が見るポイントを一部紹介

DBが遅延しているか?
DBが使った時間の内訳は?
  • DB Time のうち何の割合が高いか。Wait Time か DB CPU か、Wait Time のうちどの Wait Class/Event の割合が高いか。特定のSQLが占める割合が高いか。
  • 例えば、8CPUのマシンで、CPU使用率が50% 、AWRスナップショット間隔が1時間で、DB CPUが14400秒(4時間)、SQL ordered by CPU Time の1位が1000秒(3時間)、SQL ordered by Gets も1位で、チューニングでアクセスブロック数が大幅にに減り、CPU時間がほぼ0になった場合、CPU使用率は37%ほど削減できることになる。
DB Time と DB CPU + Wait Time の比較

補足

DB Time について
AWRについて
  • 可能な場合は DocID 1746171.1 の手順でリポジトリごと入手し、手元のDBインポートし、深堀する際は DBA_HIST_* を抽出して分析できるようにします。
  • AWR の R は "Report" ではなく "Repository" の略です。AWRレポートを分析し、深堀調査を行う場合は、DBA_HIST_ASH、DBA_HIST_SQLSTAT、DBA_HIST_SQL_PLAN などのデータを分析します。
  • 12.1 の時点で SQL Monitor の元表(WRP$)はエクスポートしたダンプに含まれない点は要注意。
ベースラインなしで評価できる項目
  • ベースラインがなくても絶対的な評価ができるものは評価します。例えば、平均I/Oレイテンシが 20ms を超えているなど*8

参考情報など

参考資料
関連
過去の JPOUG Advent Calendar 記事
過去の JPOUG Advent Calendar

明日は Oracle ACE渡部 亮太さんです。

*1:もしくはStatspackレポート

*2:例えば、CPU使用率

*3CPU使用率CPU時間の換算が必要。スナップショット間隔 *

*4Linuxを前提としています

*5:以下は HDD を想定しています

*6RACの場合は、全ノードからの IOPS の合計値になります

*7:初回はベースラインとして使用、2回目以降はベースラインと比較

*8:20msは例で、ストレージの基本性能によって変わります。HDDでも 5〜10ms 程度なので、20ms までのびるとサチっていないか、ストレージに異常がないか確認したほうがよいです。ストレージによってはワークロードが

2016-12-04

AWR に永続化された SQL Monitor を抽出する

だいぶ前にブログに書いたつもりで書いてなかったのでメモ。


  • SQL_ID から REPORT_ID を調べる
column key1 format a30;
SELECT REPORT_ID, KEY1 FROM DBA_HIST_REPORTSWHERE KEY1 = 'gxsc2sdj0xz39' ORDER BY KEY1, REPORT_ID; 
  -- SQL_ID を指定

   REPORT_ID KEY1
  ---------- ------------------------------
     164409 gxsc2sdj0xz39
     164520 gxsc2sdj0xz39
     164632 gxsc2sdj0xz39
     ↑の3つの REPORT_ID の SQL Monitor を出力します
  • SQL*Plus の出力設定を行う
set trimspool on
set trim on
set pages 0
set linesize 1000
set long 1000000
set longchunksize 1000000
set time on
col spool_file_name new_value spool_file_name for a100
  • テキスト形式で SQL Monitor を取得する
select 'sqlmonitor_gxsc2sdj0xz39_164409_'||to_char(sysdate,'YYYY-MM-DD-HH24MISS')||'.txt' spool_file_name from dual; 
spool &spool_file_name
SELECT DBMS_AUTO_REPORT.REPORT_REPOSITORY_DETAIL(RID => 164409, TYPE => 'text') FROM dual;
spool off
  • Active形式で SQL Monitor を取得する
select 'sqlmonitor_gxsc2sdj0xz39_164409_'||to_char(sysdate,'YYYY-MM-DD-HH24MISS')||'.html' spool_file_name from dual;
spool &spool_file_name
SELECT DBMS_AUTO_REPORT.REPORT_REPOSITORY_DETAIL(RID => 164409, TYPE => 'active') FROM dual;
spool off

参考

2016-11-20

iPhone 6 Plus から iPhone 7 に移行した

iPhone 6 Plus について

  • 片手で操作するには大きすぎた
  • 角が丸く割れやすいので保護ケース必須
    • 5sまでは保護ケースなしでも画面を割ったことがないが、6 Plus は保護ケースが傷んだので一時的に外しているときに落として、見事にバキバキ*1
  • 背面の iSight カメラのピントが合わなくなる不具合にヒットした

iPhone 7 購入


切替(PCは使わずに2台の iPhone のみで移行)

前提
アクティベーション
バックアップの復元
メール設定
アドレス帳移行

*1:角が丸いため、手から滑りやすく割れやすい。Plus は自重が重いのでさらに割れやすい。と想定

*2:仕事から帰ったら宅配BOXに届いていた

*3:「データを保存する」

*4:「データを戻す」