Oracle Database を監視しようぜ!      ~~ 前のめりでいこう ~~                                                              株式会社インサイトテクノロジー ...
データベースを監視する            DB監視                                              OS監視       ・ステータス ・アラートログ                        ...
Oracle Database 監視の第一歩 – 参考:各種監視ツールで監視できる項目数    • Oracle Enterprise Manager 12c           監視対象                            ...
可用性の監視                                                 UP                                 可用性は障害監視とパフォー                   ...
Oracle Database 監視の第一歩• 障害監視をする – サービス停止に影響する項目のみを警告対象にする – 警告条件を設定する(しきい値、通知条件など) – データ収集条件(しきい値、インターバルなど)を設定する   。   参考 ...
Oracle Database 監視の第一歩OS 監視  分類        監視分類                  概要  障害        リソース                  ファイルシステム空き容量/使⽤率  障害     ...
可用性の監視                                        UP                                 可用性は障害監視とパフォー                            ...
可用性の監視           障害                           UP           監視          遅すぎて                      遅く                       ...
レイヤごとの可用性監視                                                        UP                    OS         Database  Application ...
監視のための必須要素 Copyright © 2012 Insight Technology, Inc. All Rights Reserved.   10
監視のための必須要素• 1.アプリケーションレベルで情報を取得する – パフォーマンス問題を解決するために、アプリケーション側の処理レスポンス   の情報は重要。• 2.平常時の情報が必須(ベースライン) – 監視の特徴として、一般的な数値が適...
Oracle Database 監視をバージョンアップする• Oracle Database の予兆監視                   予兆監視への取り組みの事                   予兆監視  例を紹介  – 1.一時表領...
事例1:⼀時表領域の監視  Copyright © 2012 Insight Technology, Inc. All Rights Reserved.   13
⼀時表領域のよくある障害パターン           監視は表領域のサイズのみ              ⼤量ソートで領域が拡張                     使⽤率が常に99%              ⼀時表領域の拡張エラー   ...
⼀時表領域とは?⼀時表領域・ソート処理、ソートを伴う結合が実⾏された時に使⽤される領域 Ex) ORDER BY句、GROUP BY句、DISTINCT句、UNION句     ソートマージ結合・ソート量が⼤きい場合のみ使⽤される →ソート量が...
⼀時表領域の使⽤率(セグメントサイズ)                                                                                   使⽤率:90%     ⼀時表領域   ...
⼀時表領域の使⽤率(使用済みブロックサイズ)                                                                                   使⽤率:60%     ⼀時表領域...
⼀時表領域の領域情報• ⼀時表領域の使⽤量を保持するビューは多い – v$temp_space_header    • 現在使⽤されている領域の⼤きさおよび領域ヘッダーに識別さ      れる空き領域の⼤きさ – v$temp_extent_p...
⼀時表領域の領域情報• 実際にソート時の値を⾒てみよう!• 確認方法 – 1.⼀時表領域作成直後     • 100MBのデータファイル     • 自動拡張OFF –   2.ソート中 –   3.ソート完了後 –   4.次のソートを実⾏中...
⼀時表領域の領域情報• 1.⼀時表領域作成直後 v$temp_space_header     v$temp_extent_pool        v$sort_segment      v$sort_usage v$tempseg_usage...
⼀時表領域の領域情報• 3.ソート完了後 v$temp_space_header     v$temp_extent_pool        v$sort_segment      v$sort_usage v$tempseg_usage v$...
⼀時表領域の領域情報• 5.Oracle再起動直後 v$temp_space_header     v$temp_extent_pool        v$sort_segment      v$sort_usage v$tempseg_usa...
v$temp_extent_pool• v$temp_extent_pool   – GV$TEMP_EXTENT_POOLのビュー   – GV$TEMP_EXTENT_POOLはts$とx$ktstfcのビュー         v$temp...
v$sort_segment• v$sort_segment   – GV$SORT_SEGMENTのビュー   – GV$SORT_SEGMENT はx$ktstssdのビュー          v$sort_segment         ...
実⾏計画⽐較        v$temp_extent_pool------------------------------------------------------------------------------------------...
実⾏計画⽐較      v$sort_segment------------------------------------------------------------------------------| Id | Operation  ...
監視SQL文サンプル• SQL文 select   dt.tablespace_name  ,trunc(nvl(ss.bytes, 0)/nvl(dtf.bytes, 0)*100,0) "USAGE"  from dba_tablespac...
Unofficial SQL• SQL文 select   dt.tablespace_name  ,trunc(nvl(ss.bytes, 0)/nvl(dtf.bytes, 0)*100,0) "USAGE"  from dba_table...
事例1まとめ• ⼀度拡張した⼀時セグメントは拡張したまま• 拡張した後のことも考慮してv$sort_segmentの  used_blocksを使⽤して使⽤率を取得する• ⼀時表領域の使⽤率が閾値を超えた場合、データ  ファイルの追加を実施する...
事例2:マテリアライズドビューの監視     Copyright © 2012 Insight Technology, Inc. All Rights Reserved.   30
マテリアライズドビューのよくある障害パターン      高速リフレッシュ+ON COMMIT           COMMIT時間が徐々に遅延                        待ち時間が増大          処理滞留によるDBの...
マテリアライズドビューとは?マテリアライズドビュー(マテビュー)・実体のあるビューのこと・マテビューへの更新タイミングは任意に指定可能・DBリンクと組み合わせることで、テーブルレプリケーションも可能・ビューへのデータ反映は高速リフレッシュと完全...
高速リフレッシュ(ON COMMIT)                                           基表                                                          ...
COMMITが遅延する原因                                                    基表①.基表に⼤量データを更新                                          ...
COMMIT時のトレースを取得• 検証環境  – Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 64bit  – Red Hat Enterprise Linux Serve...
COMMIT時のSQLトレース• MLOGの差分情報をマテビューに反映SQL①DELETE FROM "ITI_TEST"."MV_EMP" SNAP$WHERE "EMPNO" IN (SELECT DISTINCT MLOG$."EMPNO...
COMMIT時のSQLトレース• MLOGの差分情報をマテビューに反映SQL②MERGE INTO "ITI_TEST"."MV_EMP" "SNA$" USING (SELECT CURRENT$."EMPNO",    CURRENT$."...
COMMIT時のSQLトレース• MLOGの差分情報をマテビューに反映SQL②の続きRows (1st) Rows (avg) Rows (max) Row Source Operation---------- ---------- -----...
COMMIT時のSQLトレース• MLOGをDELETEするSQLdelete from "ITI_TEST"."MLOG$_EMP"where xid$$ xid$$ = :1call     count      cpu    elapse...
一括COMMIT後のMLOGサイズ                                 1万件                                         10万件       100万件       データ無 ...
MLOG拡張後の処理遅延テスト• 検証SQL  – データ挿入(1⾏ごとにcommit)      begin       for i in 1..10000 loop        insert Into emp values(i,to_ch...
MLOG拡張後に1万件INSERT                                                 1万件                                         10万件        ...
MLOG拡張後に1万件INSERT                                                 1万件                                         10万件        ...
MLOGが拡張してしまった場合・・・  拡張したMLOGのメンテナンス方法• 拡張した    のメンテナンス方法          MLOG                                                    ...
MLOGサイズ監視SQL• SQL文 select s.segment_name     ,s.bytes/1024/1024 “size(MB)”  from user_segments s  where segment_name like ...
事例2まとめ• マテビューの高速リフレッシュを使用するときは  MLOGのメンテナンスが必要になることを想定し  ておく• 基表への更新時に⼤量データを⼀括更新するよう  な処理はないか確認しておく• MLOGのサイズを監視して遅延発生前に対処...
事例3:共有プールの監視  Copyright © 2012 Insight Technology, Inc. All Rights Reserved.   47
共有プールのよくある障害パターン        共有化されないSQLの⼤量実⾏              使⽤率が90%前後で推移                    徐々に処理遅延発⽣    共有プールの空き領域が確保できずORA-4031...
共有プールとは?共有プール・ SQLを実⾏する時に解析処理をスキップする為に⼀度解析した結果は共有プールに保存・同じSQLが発⾏された時に共有プール上に保存されている解析結果を再利⽤・再利⽤されないSQL⽂が⼤量に実⾏されると共有プール上に⼤量...
よくある共有プールの使⽤率• 常に90%近くで推移• 再起動直後に90%近くまで上昇• 根本的改善はアプリケーションの改修(バインド  変数化)だが・・・           再起動   使⽤率だけ監視しても何も⾒えてこない       Cop...
使⽤率上昇後に⾒えてくるもの• 共有プールの拡張(⾃動メモリ管理の場合)• 共有プール関連の待機時間の上昇  使⽤率+待機情報と組み合わせた監視が重要       Copyright © 2012 Insight Technology, Inc...
共有プールの監視(上級編)• ORA-4031の発生状況を分析 • ORA-4031発生直前のデータを取得し傾向を分析    →分析結果を監視に反映?• テストパターンは以下2パターン • 1.⾃動メモリ管理で共有プールが⾃動拡張中の状態 • ...
ORA-4031発生プロシージャ• 以下プロシージャを10セッションから実⾏  – SQL文        create or replace procedure ptest_4031        (p_depth in number,p_l...
プロシージャ実⾏シェルスクリプト• main.sh(10セッション作成)                                                    • 4031.sh(プロシージャ実⾏)#!/bin/sh      ...
検証パターン共有プール:400MB自動拡張                                     共有プール:2GB自動拡張共有プール:400MB拡張済み                                    ...
検証結果 待機イベント共有プール:400MB自動拡張                                                      共有プール:2GB自動拡張                             ...
検証結果 待機イベント共有プール:400MB自動拡張                                      共有プール:2GB自動拡張               latch: library cache          ...
検証結果 PIN counts/GETS共有プール:400MB自動拡張                                     共有プール:2GB自動拡張                PINS/GETS : 5.12     ...
事例3まとめ• 共有プールは使⽤率だけではなく、領域の拡張や共有  プールの待機情報と合わせて監視する• エラーが発生した時の傾向をおさえておき、エラー時の  情報を抑えておく• ORA-4031発生時の傾向は、 – 下記の待機イベントが発生し...
Oracle Database を監視しようぜ!• ステップ1 – ⼤量の監視項目はまず、カテゴリに分けて整理する。 – カテゴリは障害監視とパフォーマンス監視。 – 障害監視以外はパフォーマンス監視と割り切る。• ステップ2 – 環境にフィッ...
無断転載を禁ずこの文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。株式会社インサイトテクノロジーは本書の内容に関していかなる保証もしません。また、本書の内容に関連したいかなる損害についても責任を負いかねま...
Upcoming SlideShare
Loading in …5
×

C22 Oracle Database を監視しようぜ! by 山下正/内山義夫

3,334 views

Published on

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,334
On SlideShare
0
From Embeds
0
Number of Embeds
151
Actions
Shares
0
Downloads
83
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

C22 Oracle Database を監視しようぜ! by 山下正/内山義夫

  1. 1. Oracle Database を監視しようぜ! ~~ 前のめりでいこう ~~ 株式会社インサイトテクノロジー 株式会社インサイトテクノロジー コンサルティング事業部 コンサルティング事業部 山下 正 / 内山 義夫 Copyright © 2012 Insight Technology, Inc. All Rights Reserved.
  2. 2. データベースを監視する DB監視 OS監視 ・ステータス ・アラートログ ・ステータス ・TRAP ・統計値 ・リスナーログ ・レスポンス ・PING ・リソース ・リソース ・接続 ・syslog 監視対象 監視目的 監視方法・アプリケーション ・API ・サービス停止・ミドルウェア ・OSコマンド ・(サービス停止の可能性)・OS ・SNMP TRAP ・レスポンス低下・HW ・ファイル・NW サービス停止 :障害監視 レスポンス低下 :パフォーマンス監視 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 2
  3. 3. Oracle Database 監視の第一歩 – 参考:各種監視ツールで監視できる項目数 • Oracle Enterprise Manager 12c 監視対象 メトリック数 カテゴリ数 HOSTターゲット 114 16 Oracle Instance ターゲット 311 57 • PIEX 7.1.0.3 監視対象 メトリック数 カテゴリ数 OS監視カートリッジ 132 12 Oracle 監視カートリッジ 631 56 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 3
  4. 4. 可用性の監視 UP 可用性は障害監視とパフォー マンス監視の2軸で監視する 障害 遅すぎて使えない 監視 正常稼働 SLOW FAST パフォーマンス 監視 障害発生 障害発生パフォーマンス監視 障害監視 プロセス、ログファイル、ステータス、ディスアプリケーションレスポンス DOWN ク・フル Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 4
  5. 5. Oracle Database 監視の第一歩• 障害監視をする – サービス停止に影響する項目のみを警告対象にする – 警告条件を設定する(しきい値、通知条件など) – データ収集条件(しきい値、インターバルなど)を設定する 。 参考 (PIEX 7.1.0.3) 監視対象 メトリック数 カテゴリ数 OS監視カートリッジ 40 5 Oracle 監視カートリッジ 115 15 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 5
  6. 6. Oracle Database 監視の第一歩OS 監視 分類 監視分類 概要 障害 リソース ファイルシステム空き容量/使⽤率 障害 ファイル ログファイル内の特定キーワード 障害 プロセス 指定プロセスの数Oracle 監視 分類 監視分類 概要 障害 容量監視 表領域空き容量/使⽤率 障害 容量監視 フラッシュリカバリ領域使⽤率 障害 容量監視 ディスクグループ空き容量/使⽤率 障害 リソース監視 リソース使⽤率 障害 ステータス監視 リスナー接続 障害 ステータス監視 ローカル接続 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 6
  7. 7. 可用性の監視 UP 可用性は障害監視とパフォー マンス監視の2軸で監視する 障害 遅すぎて使えない 監視 正常稼働SLOW FAST パフォーマンス 監視 障害発生 障害発生 ”異常状態”しか検知できな いようでは運用上かなり問 題。(サービス停止してか らの対応しかできない。) DOWN Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 7
  8. 8. 可用性の監視 障害 UP 監視 遅すぎて 遅く 正常稼働 使えない なりそう 遅く 遅すぎて なりそう 障害発生 SLOW FAST 使えない 障害発生 するかも するかもパフォーマンス 監視 障害発生 障害発生 障害発生 ”予兆監視(プロアクティブ 監視)”を⾏うことで”障害 未満”を検知し、サービス 停止を予防する。 DOWN Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 8
  9. 9. レイヤごとの可用性監視 UP OS Database Application 遅すぎて 遅く 正常稼働 使えない なりそう SLOW FAST 遅くなりそ 遅すぎて う 障害発生パフォーマンスに関する 使えない 障害発生 するかも“予兆監視”は難しい。 するかも 障害発生 障害発生 障害発生DBの予兆監視に挑戦!! DOWN Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 9
  10. 10. 監視のための必須要素 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 10
  11. 11. 監視のための必須要素• 1.アプリケーションレベルで情報を取得する – パフォーマンス問題を解決するために、アプリケーション側の処理レスポンス の情報は重要。• 2.平常時の情報が必須(ベースライン) – 監視の特徴として、一般的な数値が適用できる項目とできない項目(一般的 な値を適用しづらい項目)がある。 • 比較的適用しやすい項目: – CPU使用率、キャッシュヒット率など • 適用できない項目: – Oracleの統計値(待機イベントなど)• 3.監視設定をブラッシュアップする – 予兆監視を強化する。 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 11
  12. 12. Oracle Database 監視をバージョンアップする• Oracle Database の予兆監視 予兆監視への取り組みの事 予兆監視 例を紹介 – 1.一時表領域の監視 – 2.マテリアライズド・ビューの監視 – 3.共有プールの監視 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 12
  13. 13. 事例1:⼀時表領域の監視 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 13
  14. 14. ⼀時表領域のよくある障害パターン 監視は表領域のサイズのみ ⼤量ソートで領域が拡張 使⽤率が常に99% ⼀時表領域の拡張エラー Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 14
  15. 15. ⼀時表領域とは?⼀時表領域・ソート処理、ソートを伴う結合が実⾏された時に使⽤される領域 Ex) ORDER BY句、GROUP BY句、DISTINCT句、UNION句 ソートマージ結合・ソート量が⼤きい場合のみ使⽤される →ソート量が⼩さい場合はPGAで処理・⼀時表領域内にセグメントを1つ作成しその中でソート処理を実施・複数のセッションも1つのセグメントを共有して使用・セグメントが足りない場合、自動拡張されていく →表領域のサイズに達した時、表領域が拡張(autoextend = onの場合)・⼀度拡張したセグメントは⼩さくはならない(再起動でも減らない) 表領域の空きだけでは使⽤率はわからない Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 15
  16. 16. ⼀時表領域の使⽤率(セグメントサイズ) 使⽤率:90% ⼀時表領域 使⽤率:60% 一時セグメント 拡張後 :使用済みブロック :解放済ブロック ⼀時表領域使⽤率 = 一時セグメントサイズ / 表領域サイズ⼀時セグメントが拡張すると実際の使⽤率が把握できない Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 16
  17. 17. ⼀時表領域の使⽤率(使用済みブロックサイズ) 使⽤率:60% ⼀時表領域 使⽤率:60% 一時セグメント 拡張後 :使用済みブロック :解放済ブロック ⼀時表領域使⽤率 = SUM(使用済みブロック) / 表領域サイズ ⼀時セグメントが使⽤中の領域のみ使⽤率として算出 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 17
  18. 18. ⼀時表領域の領域情報• ⼀時表領域の使⽤量を保持するビューは多い – v$temp_space_header • 現在使⽤されている領域の⼤きさおよび領域ヘッダーに識別さ れる空き領域の⼤きさ – v$temp_extent_pool • インスタンスにキャッシュまたは使⽤される⼀時領域の状態 – v$sort_segment • 各ソート・セグメントの情報 – v$sort_usage • 一時セグメントの使用状況。9.2でv$tempseg_usageに変更 – v$tempseg_usage • 一時セグメントの使用状況 – v$temp_extent_map • すべてのローカル管理⼀時表領域の状態 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 18
  19. 19. ⼀時表領域の領域情報• 実際にソート時の値を⾒てみよう!• 確認方法 – 1.⼀時表領域作成直後 • 100MBのデータファイル • 自動拡張OFF – 2.ソート中 – 3.ソート完了後 – 4.次のソートを実⾏中 – 5.Oracle再起動後 – 6.次のソートを実⾏中(セグメント拡張+再起動後) Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 19
  20. 20. ⼀時表領域の領域情報• 1.⼀時表領域作成直後 v$temp_space_header v$temp_extent_pool v$sort_segment v$sort_usage v$tempseg_usage v$temp_extent_mapbytes_used bytes_free bytes_used bytes_cached used_blocks total_blocks sum(blocks) sum(blocks) sum(blocks)---------- ---------- ---------- ------------ ----------- ------------ ------------ --------------- ----------------- 1MB 99MB - - - - - - 99MB v$temp_space_headerとv$temp_extent_mapが出⼒ v$temp_space_header v$temp_space_header の1MBの使用はヘッダー• 2.ソート中(約30MB程度使⽤時) v$temp_space_header v$temp_extent_pool v$sort_segment v$sort_usage v$tempseg_usage v$temp_extent_mapbytes_used bytes_free bytes_used bytes_cached used_blocks total_blocks sum(blocks) sum(blocks) sum(blocks)---------- ---------- ---------- ------------ ----------- ------------ ------------ --------------- ----------------- 31MB 69MB 30MB 30MB 30MB 30MB 30MB 30MB 99MB 同じ値が出⼒ v$temp_space_headerのみ1MBプラス Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 20
  21. 21. ⼀時表領域の領域情報• 3.ソート完了後 v$temp_space_header v$temp_extent_pool v$sort_segment v$sort_usage v$tempseg_usage v$temp_extent_mapbytes_used bytes_free bytes_used bytes_cached used_blocks total_blocks sum(blocks) sum(blocks) sum(blocks)---------- ---------- ---------- ------------ ----------- ------------ ------------ --------------- ----------------- 100MB 0MB 0MB 99MB 0MB 99MB - - 99MB サイズが拡張したままのもの有 件に v$sort_usageとv$tempseg_usageはソート完了後0件に• 4.ソートを実⾏(セグメント拡張後) v$temp_space_header v$temp_extent_pool v$sort_segment v$sort_usage v$tempseg_usage v$temp_extent_mapbytes_used bytes_free bytes_used bytes_cached used_blocks total_blocks sum(blocks) sum(blocks) sum(blocks)---------- ---------- ---------- ------------ ----------- ------------ ------------ --------------- ----------------- 100MB 0MB 30MB 99MB 30MB 99MB 30MB 30MB 99MB 拡張していないものは、 ソート時の値が格納 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 21
  22. 22. ⼀時表領域の領域情報• 5.Oracle再起動直後 v$temp_space_header v$temp_extent_pool v$sort_segment v$sort_usage v$tempseg_usage v$temp_extent_mapbytes_used bytes_free bytes_used bytes_cached used_blocks total_blocks sum(blocks) sum(blocks) sum(blocks)---------- ---------- ---------- ------------ ----------- ------------ ------------ --------------- ----------------- 100MB 0MB - - - - - - 99MB v$temp_space_headerとv$temp_extent_mapのみ出⼒ v$temp_space_header• 6.ソートを実⾏中(セグメント拡張+再起動後) v$temp_space_header v$temp_extent_pool v$sort_segment v$sort_usage v$tempseg_usage v$temp_extent_mapbytes_used bytes_free bytes_used bytes_cached used_blocks total_blocks sum(blocks) sum(blocks) sum(blocks)---------- ---------- ---------- ------------ ----------- ------------ ------------ --------------- ----------------- 100MB 0MB 30MB 99MB 30MB 99MB 30MB 30MB 99MB セグメント拡張後ソート処理を実⾏した時と同じ結果 集計関数を使用していないv$temp_extent_poolと v$sort_segmentが最適 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 22
  23. 23. v$temp_extent_pool• v$temp_extent_pool – GV$TEMP_EXTENT_POOLのビュー – GV$TEMP_EXTENT_POOLはts$とx$ktstfcのビュー v$temp_extent_pool gv$temp_extent_poolselect select /*+ ordered use_nl(fc) */ fc.inst_id TABLESPACE_NAME , ts.name , fc.ktstfctfno, FILE_ID , fc.ktstfcec, EXTENTS_CACHED , fc.ktstfceu, EXTENTS_USED , fc.ktstfcbc, BLOCKS_CACHED , fc.ktstfcbu, BLOCKS_USED , fc.ktstfcbc*ts.blocksize , fc.ktstfcbu*ts.blocksize, BYTES_CACHED , fc.ktstfcfno, BYTES_USED from ts$ ts, RELATIVE_FNO , x$ktstfc fcfrom GV$TEMP_EXTENT_POOL where ts.contents$ = 1where inst_id = USERENV(Instance) and ts.bitmapped <> 0 and ts.online$ = 1 and ts.ts# = fc.ktstfctsn Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 23
  24. 24. v$sort_segment• v$sort_segment – GV$SORT_SEGMENTのビュー – GV$SORT_SEGMENT はx$ktstssdのビュー v$sort_segment gv$sort_segmentselect select TABLESPACE_NAME inst_id, SEGMENT_FILE, SEGMENT_BLOCK , tablespace_name , segment_file, segment_block, EXTENT_SIZE, CURRENT_USERS , extent_size, current_users, TOTAL_EXTENTS, TOTAL_BLOCKS , total_extents, total_blocks, USED_EXTENTS, USED_BLOCKS , used_extents, used_blocks, FREE_EXTENTS, FREE_BLOCKS , free_extents, free_blocks, ADDED_EXTENTS, EXTENT_HITS , added_extents, extent_hits , freed_extents, free_requests, FREED_EXTENTS, FREE_REQUESTS , max_size, max_blocks, MAX_SIZE, MAX_BLOCKS , max_used_size, max_used_blocks, MAX_USED_SIZE, MAX_USED_BLOCKS , max_sort_size, max_sort_blocks, MAX_SORT_SIZE, MAX_SORT_BLOCKS , relative_fno, RELATIVE_FNO from x$ktstssdfrom GV$SORT_SEGMENTwhere inst_id = USERENV(Instance‘) Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 24
  25. 25. 実⾏計画⽐較 v$temp_extent_pool-------------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |-------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 131 | 1 (0)| 00:00:01 || 1 | NESTED LOOPS | | 1 | 131 | 1 (0)| 00:00:01 ||* 2 | TABLE ACCESS BY INDEX ROWID| TS$ | 1 | 27 | 1 (0)| 00:00:01 ||* 3 | INDEX UNIQUE SCAN | I_TS1 | 1 | | 0 (0)| 00:00:01 ||* 4 | FIXED TABLE FIXED INDEX | X$KTSTFC (ind:1) | 1 | 104 | 0 (0)| 00:00:01 |-------------------------------------------------------------------------------------------------Predicate Information (identified by operation id):--------------------------------------------------- 2 - filter("TS"."CONTENTS$"=1 AND "TS"."ONLINE$"=1 AND "TS"."BITMAPPED"<>0) 3 - access("TS"."NAME"=TEMP2) 4 - filter("FC"."INST_ID"=USERENV(INSTANCE) AND "TS"."TS#"="FC"."KTSTFCTSN")統計---------------------------------------------------------- 0 recursive calls 0 db block gets 2 consistent gets 0 physical reads 0 redo size 1173 bytes sent via SQL*Net to client Consistent gets:2 520 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 25
  26. 26. 実⾏計画⽐較 v$sort_segment------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 303 | 0 (0)| 00:00:01 ||* 1 | FIXED TABLE FULL| X$KTSTSSD | 1 | 303 | 0 (0)| 00:00:01 |------------------------------------------------------------------------------Predicate Information (identified by operation id):--------------------------------------------------- 1 - filter("TABLESPACE_NAME"=TEMP2 AND "INST_ID"=USERENV(INSTANCE))統計---------------------------------------------------------- 0 recursive calls 0 db block gets 0 consistent gets 0 physical reads 0 redo size 2181 bytes sent via SQL*Net to client Consistent gets:0 520 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed v$sort_segmentの方が負荷が低い Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 26
  27. 27. 監視SQL文サンプル• SQL文 select dt.tablespace_name ,trunc(nvl(ss.bytes, 0)/nvl(dtf.bytes, 0)*100,0) "USAGE" from dba_tablespaces dt ,(select tablespace_name ,sum(bytes) as bytes from dba_temp_files group by tablespace_name) dtf ,(select tablespace_name ,used_blocks * value bytes from v$sort_segment , v$parameter where name = db_block_size) ss where dt.tablespace_name = dtf.tablespace_name(+) and dt.tablespace_name = ss.tablespace_name(+) and dt.contents = TEMPORARY; Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 27
  28. 28. Unofficial SQL• SQL文 select dt.tablespace_name ,trunc(nvl(ss.bytes, 0)/nvl(dtf.bytes, 0)*100,0) "USAGE" from dba_tablespaces dt ,(select tablespace_name ,sum(bytes) as bytes from dba_temp_files group by tablespace_name) dtf ,(select tablespace_name ,used_blocks * block_size bytes from x$ktstssd where inst_id = USERENV(Instance)) ss where dt.tablespace_name = dtf.tablespace_name(+) and dt.tablespace_name = ss.tablespace_name(+) and dt.contents = TEMPORARY; Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 28
  29. 29. 事例1まとめ• ⼀度拡張した⼀時セグメントは拡張したまま• 拡張した後のことも考慮してv$sort_segmentの used_blocksを使⽤して使⽤率を取得する• ⼀時表領域の使⽤率が閾値を超えた場合、データ ファイルの追加を実施する ( もしくは、データファイルを自動拡張にして おく) – 追加コマンド – alter tablespace temp add tempfile ‘path’ size 100M autoextend on;• 閾値は環境に合わせて定義する Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 29
  30. 30. 事例2:マテリアライズドビューの監視 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 30
  31. 31. マテリアライズドビューのよくある障害パターン 高速リフレッシュ+ON COMMIT COMMIT時間が徐々に遅延 待ち時間が増大 処理滞留によるDBのハング Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 31
  32. 32. マテリアライズドビューとは?マテリアライズドビュー(マテビュー)・実体のあるビューのこと・マテビューへの更新タイミングは任意に指定可能・DBリンクと組み合わせることで、テーブルレプリケーションも可能・ビューへのデータ反映は高速リフレッシュと完全リフレッシュがある・⾼速リフレッシュを使⽤する場合、差分情報を管理するテーブル:マ テリアライズドビューログ(mlog)を作成する必要有・高速リフレッシュは、ON COMMITオプションを指定することで、コ ミット時にリフレッシュすることが可能・リフレッシュに時間がかかる場合、コミット時間も⻑くなる リフレッシュの遅延を把握する必要がある Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 32
  33. 33. 高速リフレッシュ(ON COMMIT) 基表 ②.差分情報(①で挿①.基表に更新処理 入した情報)をMLOG Ex) に挿入 INSERT INTO … MLOG③.コミット処理実⾏ COMMIT; マテビュー ⇒⑥.DELETE処理 ⑤.MLOGの差分情報 完了後、処理完了 をDELETE ④.MLOGの差分情報 をマテビューに反映 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 33
  34. 34. COMMITが遅延する原因 基表①.基表に⼤量データを更新 ②.10000件分の差分 Ex) 情報をMLOGに挿入 FOR I in 1..10000 LOOP ⇒③.MLOGのサイズ拡張 INSERT INTO … END LOOP; MLOG マテビュー④.コミット処理実⾏ ⑥.MLOGをDELETE COMMIT; ⇒⑦.DELETE処理 ⑤と⑥で (FULL SCAN)完了 FULL SCAN発生! 後、処理完了 ⑤.MLOGの差分情報 をマテビューに反映 MLOGの拡張後のCOMMIT時間が増大 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 34
  35. 35. COMMIT時のトレースを取得• 検証環境 – Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 64bit – Red Hat Enterprise Linux Server release 5.5• 検証SQL – マテビュー作成 create materialized view log on emp; – MLOG作成 create materialized view mv_emp refresh fast on commit as select * from emp where empno <= 10000; – データ挿入(1万件) begin for i in 1..10000 loop Insert Into emp values(i,to_char(i),TEST,9999,sysdate,99999,99999,10); end loop; end; – コミット時にトレース alter session set events 10046 trace name context forever,level 12; commit; Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 35
  36. 36. COMMIT時のSQLトレース• MLOGの差分情報をマテビューに反映SQL①DELETE FROM "ITI_TEST"."MV_EMP" SNAP$WHERE "EMPNO" IN (SELECT DISTINCT MLOG$."EMPNO" FROM "ITI_TEST"."MLOG$_EMP" MLOG$ WHERE "XID$$" = :1 AND ("DMLTYPE$$" != I))call count cpu elapsed disk query current rows------- ------ -------- ---------- ---------- ---------- ---------- ----------Parse 1 0.00 0.00 0 0 0 0Execute 1 0.00 0.06 33 501 0 0Fetch 0 0.00 0.00 0 0 0 0------- ------ -------- ---------- ---------- ---------- ---------- ----------total 2 0.00 0.06 33 501 0 0Rows (1st) Rows (avg) Rows (max) Row Source Operation---------- ---------- ---------- --------------------------------------------------- 0 0 0 DELETE MV_EMP (cr=500 pr=33 pw=0 time=56615 us) 0 0 0 NESTED LOOPS (cr=500 pr=33 pw=0 time=56611 us cost=138 size=41 card=1) 0 0 0 SORT UNIQUE (cr=500 pr=33 pw=0 time=56608 us cost=137 size=28 card=1) 0 0 0 TABLE ACCESS FULL MLOG$_EMP (cr=500 pr=33 pw=0 time=56593 us cost=137 size=28 card=1) 0 0 0 INDEX UNIQUE SCAN SYS_C0051723 (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 135652)Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ db file sequential read 16 0.00 0.00 db file scattered read 7 0.00 0.00 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 36
  37. 37. COMMIT時のSQLトレース• MLOGの差分情報をマテビューに反映SQL②MERGE INTO "ITI_TEST"."MV_EMP" "SNA$" USING (SELECT CURRENT$."EMPNO", CURRENT$."ENAME",CURRENT$."JOB",CURRENT$."MGR",CURRENT$."HIREDATE", CURRENT$."SAL",CURRENT$."COMM",CURRENT$."DEPTNO" FROM (SELECT "EMP"."EMPNO" "EMPNO","EMP"."ENAME" "ENAME","EMP"."JOB" "JOB","EMP"."MGR" "MGR", "EMP"."HIREDATE" "HIREDATE","EMP"."SAL" "SAL","EMP"."COMM" "COMM", "EMP"."DEPTNO" "DEPTNO" FROM "EMP" "EMP" WHERE "EMP"."EMPNO"<=10000) CURRENT$, (SELECT DISTINCT MLOG$."EMPNO" FROM "ITI_TEST"."MLOG$_EMP" MLOG$ WHERE "XID$$" = :1 AND ("DMLTYPE$$" != D)) LOG$ WHERE CURRENT$."EMPNO" = LOG$."EMPNO")"AV$" ON ("SNA$"."EMPNO" = "AV$"."EMPNO") WHEN MATCHED THEN UPDATE SET "SNA$"."EMPNO" = "AV$"."EMPNO","SNA$"."ENAME" = "AV$"."ENAME","SNA$"."JOB" = "AV$"."JOB","SNA$"."MGR" = "AV$"."MGR", "SNA$"."HIREDATE" = "AV$"."HIREDATE","SNA$"."SAL" = "AV$"."SAL", "SNA$"."COMM" = "AV$"."COMM","SNA$"."DEPTNO" = "AV$"."DEPTNO" WHEN NOT MATCHED THEN INSERT (SNA$."EMPNO",SNA$."ENAME",SNA$."JOB",SNA$."MGR", SNA$."HIREDATE",SNA$."SAL",SNA$."COMM",SNA$."DEPTNO") VALUES (AV$."EMPNO", AV$."ENAME",AV$."JOB",AV$."MGR",AV$."HIREDATE",AV$."SAL",AV$."COMM", AV$."DEPTNO")call count cpu elapsed disk query current rows------- ------ -------- ---------- ---------- ---------- ---------- ----------Parse 1 0.00 0.00 0 0 0 0Execute 1 0.08 0.30 35 1153 1951 10000Fetch 0 0.00 0.00 0 0 0 0------- ------ -------- ---------- ---------- ---------- ---------- ----------total 2 0.08 0.30 35 1153 1951 10000 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 37
  38. 38. COMMIT時のSQLトレース• MLOGの差分情報をマテビューに反映SQL②の続きRows (1st) Rows (avg) Rows (max) Row Source Operation---------- ---------- ---------- --------------------------------------------------- 0 0 0 MERGE MV_EMP (cr=1177 pr=35 pw=0 time=375889 us) 10000 10000 10000 VIEW (cr=581 pr=35 pw=0 time=209112 us) 10000 10000 10000 NESTED LOOPS OUTER (cr=581 pr=35 pw=0 time=207972 us cost=247 size=28086 card=151) 10000 10000 10000 VIEW VM_NWVW_1 (cr=580 pr=35 pw=0 time=197703 us cost=247 size=13137 card=151) 10000 10000 10000 SORT UNIQUE (cr=580 pr=35 pw=0 time=195930 us cost=247 size=19177 card=151) 10000 10000 10000 HASH JOIN (cr=580 pr=35 pw=0 time=19903 us cost=246 size=19177 card=151) 10000 10000 10000 TABLE ACCESS FULL MLOG$_EMP (cr=500 pr=0 pw=0 time=2310 us cost=137 size=4228 card=151) 10000 10000 10000 TABLE ACCESS BY INDEX ROWID EMP (cr=80 pr=35 pw=0 time=7369 us cost=108 size=1163646 card=11754) 10000 10000 10000 INDEX RANGE SCAN SYS_C0051715 (cr=19 pr=8 pw=0 time=2296 us cost=26 size=0 card=11754)(object id 135626) 0 0 0 MAT_VIEW ACCESS BY INDEX ROWID MV_EMP (cr=1 pr=0 pw=0 time=9012 us cost=0 size=99 card=1) 0 0 0 INDEX UNIQUE SCAN SYS_C0051723 (cr=1 pr=0 pw=0 time=2222 us cost=0 size=0 card=1)(object id 135652)Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ db file sequential read 35 0.00 0.00 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 38
  39. 39. COMMIT時のSQLトレース• MLOGをDELETEするSQLdelete from "ITI_TEST"."MLOG$_EMP"where xid$$ xid$$ = :1call count cpu elapsed disk query current rows------- ------ -------- ---------- ---------- ---------- ---------- ----------Parse 1 0.00 0.00 0 0 0 0Execute 1 0.97 1.72 5 508 106528 100000Fetch 0 0.00 0.00 0 0 0 0------- ------ -------- ---------- ---------- ---------- ---------- ----------total 2 0.97 1.72 5 508 106528 100000Rows (1st) Rows (avg) Rows (max) Row Source Operation---------- ---------- ---------- --------------------------------------------------- 0 0 0 DELETE MLOG$_EMP (cr=530 pr=5 pw=0 time=1721073 us) 100000 100000 100000 TABLE ACCESS FULL MLOG$_EMP (cr=500 pr=0 pw=0 time=101685 us)Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ db file sequential read 5 0.00 0.00 log buffer space 6 0.10 0.24 reliable message 20 0.00 0.00 rdbms ipc reply 20 0.00 0.00 log file switch completion 2 0.25 0.40 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 39
  40. 40. 一括COMMIT後のMLOGサイズ 1万件 10万件 100万件 データ無 一括commit後 一括commit後 一括commit後MLOGサイズ 0.0MB 0.4MB 3.9MB 38.3MB 一括COMMIT件数に⽐例して拡張 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 40
  41. 41. MLOG拡張後の処理遅延テスト• 検証SQL – データ挿入(1⾏ごとにcommit) begin for i in 1..10000 loop insert Into emp values(i,to_char(i),TEST,9999,sysdate,99999,99999,10); commit; end loop; End; /• データ件数 – データ無 – 1万件一括コミット – 10万件一括コミット – 100万件一括コミット• 同時実⾏数 – 1セッション – 10セッション Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 41
  42. 42. MLOG拡張後に1万件INSERT 1万件 10万件 100万件 データ無 一括commit後 一括commit後 一括commit後 1万件INSERT1⾏ずつCOMMIT 処理時間(1セッション) 合計:172.99秒 合計:187.05秒 合計:219.79秒 合計:2,649.85秒 RCALL: 4.02秒 RCALL: 6.87秒 RCALL: 35.23秒 RCALL:2,250.12秒 INSERT: 3.44秒 INSERT: 3.55秒 INSERT: 3.84秒 INSERT: 8.12秒 COMMIT: 68.99秒 COMMIT: 71.89秒 COMMIT: 79.69秒 COMMIT: 86.65秒 R CALL R CALL R CALL R CALL - MVIEW DEL: 1.14秒 - MVIEW DEL: 2.24秒 - MVIEW DEL: 13.79秒 - MVIEW DEL:760.28秒 - MERGE: 1.48秒 - MERGE: 2.35秒 - MERGE: 10.31秒 - MERGE: 736.36秒 - MLOG DEL: 1.40秒 - MLOG DEL: 2.28秒 - MLOG DEL: 11.13秒 - MLOG DEL: 753.48秒 ETC: 96.54秒 ETC: 104.74秒 ETC: 101.03秒 ETC: 304.96秒 MLOGのサイズに依存して処理時間増加 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 42
  43. 43. MLOG拡張後に1万件INSERT 1万件 10万件 100万件 データ無 一括commit後 一括commit後 一括commit後 1万件INSERT1⾏ずつCOMMIT 処理時間(10セッション) 合計:1,638.72秒 合計:1,782.92秒 合計:1,984.25秒 合計:3,663.85秒 RCALL: 6.37秒 RCALL: 11.73秒 RCALL: 38.12秒 RCALL:208.82秒 INSERT: 5.71秒 INSERT: 2.76秒 INSERT: 3.63秒 INSERT: 3.86秒 COMMIT: 1532.77秒 COMMIT: 1671.36秒 COMMIT: 1845.92秒 COMMIT: 3556.36秒 R CALL R CALL R CALL R CALL - MVIEW DEL: 2.21秒 - MVIEW DEL: 4.08秒 - MVIEW DEL: 14.68秒 - MVIEW DEL: 72.89秒 - MERGE: 2.29秒 - MERGE: 4.16秒 - MERGE: 11.53秒 - MERGE: 67.52秒 - MLOG DEL: 1.87秒 - MLOG DEL: 3.49秒 - MLOG DEL: 11.91秒 - MLOG DEL: 68.41秒 ETC: 93.87秒 ETC: 97.07秒 ETC: 96.58秒 ETC: 94.81秒 COMMIT(JI Enqueue)の待機が増加 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 43
  44. 44. MLOGが拡張してしまった場合・・・ 拡張したMLOGのメンテナンス方法• 拡張した のメンテナンス方法 MLOG MLOG MLOGメンテナンス手順 ①.基表への排他ロックを取得 LOCK TABLE emp IN EXCLUSIVE MODE; ②.MLOGデータを退避 CREATE TABLE templog AS SELECT * FROM MLOG$_EMP; ③.MLOGデータ削除 TRUNCATE TABLE MLOG$_EMP; ④.退避したMLOGデータを復元 INSERT INTO MLOG$_EMP SELECT * FROM templog; ⑤.退避テーブルをDROP DROP TABLE templog; ⑥.排他ロック解除(ROLLBACKで解除可能) ROLLBACK; 詳細はOracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス参照 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 44
  45. 45. MLOGサイズ監視SQL• SQL文 select s.segment_name ,s.bytes/1024/1024 “size(MB)” from user_segments s where segment_name like ‘MLOG$_%’; Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 45
  46. 46. 事例2まとめ• マテビューの高速リフレッシュを使用するときは MLOGのメンテナンスが必要になることを想定し ておく• 基表への更新時に⼤量データを⼀括更新するよう な処理はないか確認しておく• MLOGのサイズを監視して遅延発生前に対処する Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 46
  47. 47. 事例3:共有プールの監視 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 47
  48. 48. 共有プールのよくある障害パターン 共有化されないSQLの⼤量実⾏ 使⽤率が90%前後で推移 徐々に処理遅延発⽣ 共有プールの空き領域が確保できずORA-4031 もしくは、処理滞留によるDBのハング Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 48
  49. 49. 共有プールとは?共有プール・ SQLを実⾏する時に解析処理をスキップする為に⼀度解析した結果は共有プールに保存・同じSQLが発⾏された時に共有プール上に保存されている解析結果を再利⽤・再利⽤されないSQL⽂が⼤量に実⾏されると共有プール上に⼤量のSQLが格納され、空き領域が枯渇→共有プールの使⽤率の⾼騰・空き領域が確保できなくなると、古い情報からキャッシュアウトしていく・さらに共有化されないSQLが実⾏され続けると、連続した空き領域が確保できなくなり、ORA-4031エラー発生※ORA-4031エラー:共有メモリーのstringバイトを割当てできません 共有プールが断片化していないか監視が必要 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 49
  50. 50. よくある共有プールの使⽤率• 常に90%近くで推移• 再起動直後に90%近くまで上昇• 根本的改善はアプリケーションの改修(バインド 変数化)だが・・・ 再起動 使⽤率だけ監視しても何も⾒えてこない Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 50
  51. 51. 使⽤率上昇後に⾒えてくるもの• 共有プールの拡張(⾃動メモリ管理の場合)• 共有プール関連の待機時間の上昇 使⽤率+待機情報と組み合わせた監視が重要 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 51
  52. 52. 共有プールの監視(上級編)• ORA-4031の発生状況を分析 • ORA-4031発生直前のデータを取得し傾向を分析 →分析結果を監視に反映?• テストパターンは以下2パターン • 1.⾃動メモリ管理で共有プールが⾃動拡張中の状態 • 2.⾃動メモリ管理で共有プールが最大まで拡張した状態• 取得したデータ(取得間隔:1秒) • 待機イベント情報(v$system_event) • ライブラリキャッシュの統計情報(V$librarycache) Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 52
  53. 53. ORA-4031発生プロシージャ• 以下プロシージャを10セッションから実⾏ – SQL文 create or replace procedure ptest_4031 (p_depth in number,p_level in number ,p_timer in number) is v_cursor sys_refcursor; v_sql varchar2(20000); v_sid number; begin if ( p_depth > p_level ) then dbms_lock.sleep(p_timer); else select userenv(sid) into v_sid from dual; v_sql := select /* PTEST001 || v_sid || rpad( , p_depth, Y) || */ * from emp a_ || p_depth || where empno = 7844; open v_cursor for v_sql; ptest_4031 (p_depth+1,p_level,p_timer); end if; 参照URL(スクリプトは検証しやすいようにアレンジしています) end; http://dioncho.blogspot.jp/2009/08/ora-4031.html Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 53
  54. 54. プロシージャ実⾏シェルスクリプト• main.sh(10セッション作成) • 4031.sh(プロシージャ実⾏)#!/bin/sh #!/bin/shCNT=$1 # session count sqlplus /nolog <<_EOF_ >> $0.logif [ "$CNT" = "" ]then connect scott/tiger CNT=10 # session count default 10fi exec ptest_4031 (1,10000,10);echo CNT=[$CNT] -- paramsI=0 -- arg1 1 start no. -- arg2 10000 sql countwhile [ $I -le $CNT ] -- arg3 10 sleep time in second afterdo issue all sqls. sh ./4031.sh &# echo "4031 test" exit I=`expr $I + 1` _EOF_doneexit exit Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 54
  55. 55. 検証パターン共有プール:400MB自動拡張 共有プール:2GB自動拡張共有プール:400MB拡張済み 共有プール:2GB拡張済み Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 55
  56. 56. 検証結果 待機イベント共有プール:400MB自動拡張 共有プール:2GB自動拡張 library cache load lock latch: library cache cursor: pin S wait on X cursor: pin S wait on X共有プール:400MB拡張済み 共有プール:2GB拡張済み library cache load lock cursor: pin S wait on X latch: library cache cursor: pin S wait on X Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 56
  57. 57. 検証結果 待機イベント共有プール:400MB自動拡張 共有プール:2GB自動拡張 latch: library cache library cache load lock cursor: pin S wait on X cursor: pin S wait on X library cache load lock latch: row cache objects library cache: mutex X latch: shared pool共有プール:400MB拡張済み 共有プール:2GB拡張済み library cache load lock cursor: pin S wait on X cursor: pin S wait on X latch: library cache latch: shared pool latch:row cache objects library cache: mutex X library cache load lock Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 57
  58. 58. 検証結果 PIN counts/GETS共有プール:400MB自動拡張 共有プール:2GB自動拡張 PINS/GETS : 5.12 PINS/GETS : 7.00共有プール:400MB拡張済み 共有プール:2GB拡張済み PINS/GETS : 6.89 PINS/GETS : 8.14 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 58
  59. 59. 事例3まとめ• 共有プールは使⽤率だけではなく、領域の拡張や共有 プールの待機情報と合わせて監視する• エラーが発生した時の傾向をおさえておき、エラー時の 情報を抑えておく• ORA-4031発生時の傾向は、 – 下記の待機イベントが発生している。 ”cursor:pin S wait on X” “library cache load lock” – GET に対する PIN の発生割合が上昇する。 (4以上 : 環境ごとの確認が必要) – 共有プールの使⽤率が⾼い。(90% 以上) Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 59
  60. 60. Oracle Database を監視しようぜ!• ステップ1 – ⼤量の監視項目はまず、カテゴリに分けて整理する。 – カテゴリは障害監視とパフォーマンス監視。 – 障害監視以外はパフォーマンス監視と割り切る。• ステップ2 – 環境にフィットした予兆監視を設定する。 – 予兆監視の材料の多くはパフォーマンス監視。 – 予兆監視が成功すれば、楽しい。• ステップ3 – 前のめりに監視しよう!! Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 60
  61. 61. 無断転載を禁ずこの文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。株式会社インサイトテクノロジーは本書の内容に関していかなる保証もしません。また、本書の内容に関連したいかなる損害についても責任を負いかねます。本書で使用している製品やサービス名の名称は、各社の商標または登録商標です。 Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 61

×