Null

Transcription

1 Oracle Database Connect 2017 ~ 最新のデータベース技術がここにある ~ エキスパートはどう考えるか? 体感! パフォーマンスチューニング Japan Oracle User Group 日本オラクル株式会社クラウド テクノロジー事業統括 Database & Exadata プロダクトマネジメント本部 Copyright 2017, Oracle and/or its affiliates. All rights reserved.

2 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらないで下さい オラクル製品に関して記載されている機能の開発 リリースおよび時期については 弊社の裁量により決定されます Oracle と Java は Oracle Corporation 及びその子会社 関連会社の米国及びその他の国における登録商標です 文中の社名 商品名等は各社の商標または登録商標である場合があります

3 Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle. 3

4 Agenda 登壇者の紹介課題解決の流れ課題 1 課題 2 DEMO 4

5 登壇者の紹介 パネリスト Japan Oracle User Group(JPOUG) フリーランサー /Mac De Oracle の中の人関口裕士 日本ヒューレット パッカード株式会社諸橋渉 株式会社コーソル渡部亮太 日本オラクル株式会社コンサルティングサービス事業統括畔勝洋平 課題説明 および解説 日本オラクル株式会社津島浩樹 ( 津島博士 ) ファシリテーター 日本オラクル株式会社柴田長 ( しばちょう先生 ) 5

6 本セッションでの課題解決の流れ 1. パフォーマンス問題の説明 2. 原因の候補 3. 会場投票 4. それぞれの原因の真偽を確認する為の深堀り 5. 原因の発表 6. チューニング アイディア 7. 津島博士による解説 6

7 課題 1(A 社のパフォーマンス問題 ) A 社では 基幹業務として C システムを運用している 順調に業績を伸ばしてデータ量も年々増加しているが これまで問題なく動作していた ところが最近になって 性能が影響して業務をこなすのが難しくなってきているため 早急に改善して欲しいとのことである ここ最近のトランザクション性能を調べてもらったところ 以下のようになっていることが分かった そこで このシステムの性能が低下した原因の特定と改善方法を 皆さんに様々な情報を使用して考えて頂きたい TPS 直近 1 年のトランザクション性能の推移 時間軸 (1 年間 ) 7

8 AWR レポートスナップショット間の差分データ + 平均値? N-1 N N+1 経過時間 8

9 DB Time の内訳 DB Time ON CPU 以外の待機していた時間 Oracle Database は何にどれだけ時間を消費していたかを計測している CPU WAIT Server Process I/O Other Background Process Read Write 9

10 索引アクセスとdb file sequential read待機イベント db file sequential read 待機イベント ルートブロック SELECT * FROM emp WHERE ename = Stanly ; <= King > King <= King > King Stanly ディスクからのブロック読み込み ブランチブロック <= David > David <= Miller > Miller Stanly リーフブロック 索引エントリ <= Miller > Miller Ash 0008 JB 0003 Marcus 0005 Stanly 0007 Stanly 0007 David 0006 King 0004 Miller Woot Woot ROWID=0007 テーブルEMP ブロック Stanly Stanly 10

11 db file sequential read 待機時間が伸びた理由は? 1. あ 2. あ 3. あ 11

12 Oracle Database の基本アーキテクチャ Server Process (Foreground Process) SQL 実行 SP SP SP SP SP SP DB Server Oracle Client (Application) Buffer Cache Hit CR Block Buffer Cache Current Block Undo Block Log Buffer SGA PGA DBWn PMON SMON LGWR Others Background Process Physical Reads Physical Writes Data Files Redo Writes Redo Log Files Storage 12

13 課題 1( 解説 ) データが増加するようなシステム いつかはリソース (CPU メモリ ストレージ ) 不足になるので監視が重要 メモリ チューニング ( 第 14 回 ) アプリケーション タイプで各領域 ( バッファ キャッシュ 共有プール PGA) を指定 PGA SGA 共有プール スタック領域 セッション情報 (UGA) Redo ログバッファ バッファキャッシュ (DB_CACHE_SIZE) ラージ プール Java プール Streams プール など 自動メモリ管理 / 自動共有メモリ管理 ( アドバイザは各領域を手動で調整する ) リサイズが頻繁に発生しないように注意 最小サイズ指定を効果的に使用する 自動メモリ管理は HugePages(Linux) のとき使用できない 13

14 課題 2(B 社のパフォーマンス問題 ) B 社では 基幹業務として D システムを運用している 近年 様々な事業拡張を行っていてシステムに処理の追加も行っているが これまで問題なく動作していた ところが最近になって ある特定の時間だけ性能が低下して業務に影響しているため 早急に改善して欲しいとのことである ここ最近の 1 日のトランザクション性能を調べてもらったところ 以下のようになっていることが分かった そこで このシステムの性能が低下した原因の特定と改善方法を 皆さんに様々な情報を使用して考えて頂きたい TPS 1 日のトランザクション性能の推移 時間軸 (1 日間 ) 14

15 全表スキャンと direct path read 待機イベント サーバープロセス db file sequential read 単一ブロック読み込み PGA SGA バッファキャッシュ 読込 データファイル 全表スキャン パラレル全表スキャン サーバープロセス PGA SGA 読込 データファイル バッファキャッシュ direct path read

16 log file sync 待機イベント Server Process が Commit 要求してから LGWR によるディスクへ書き出しが完了するまでの待機 Server Process (Foreground Process) SQL 実行 SP SP SP SP SP SP DB Server Oracle Client (Application) Buffer Cache Hit CR Block Buffer Cache Current Block Undo Block Log Buffer SGA PGA DBWn PMON SMON LGWR Others Background Process Physical Reads Physical Writes Data Files Redo Writes Redo Log Files Storage 16

17 Direct path read による物理 I/O が多い理由は? 1. あ 2. あ 3. あ 17

18 iostat の基本的な見方 サービスタイム (iostat: svctm) 一回の I/O リクエストにおけるデバイスでの平均処理時間この値が長い場合 I/O に関連するレイヤー ( ストレージ装置 ) に問題がある 数 msec 未満 ストレージ コントローラのキャッシュに乗っている or SSD 10msec 前後 HDD までアクセスしている 数十 msec 以上 Disk Busy 等の問題あり IOPS(iostat: r/s + w/s) とレスポンスタイム (iostat: await) の関係 サービスタイムが正常時と同じだが レスポンスタイムが大きくなっている場合 I/O 要求回数が増えて待ちが発生している ストレージの性能限界に達していると推測 18

19 Live Demo ある時間帯にパフォーマンス問題 (Transaction Per Sec の落ち込み ) が発生 Oracle Public Cloud 上のデータベース バージョン : 12.2 Swingbench 使用 更新系のトランザクション 19

20 課題 2( 解説 ) ダイレクト パス リード ( 全表スキャン ) について ( 第 13 回 ) バッファ キャッシュを経由しないアクセス (I/O が多発する ) I/O チューニング まずはアクセス データをできるだけ少なくすること パーティション ( 第 22 回 第 46 回 ) 表圧縮 ( 第 28 回 ) Oracle Database In-Memory でも I/O を削減 ( 第 53 回 第 54 回 ) デュアル フォーマット ( 行型 列型 ) CPU コストが少ない ( ディクショナリ圧縮 ストレージ索引 SIMD:Single Instruction Multiple Data) 最後にストレージの増強 20

21 課題 2( 解説 ) パフォーマンス チューニングの基本的な考え方 処理量を減らす Index, Partitioning, Compression, Exadata Smart Scan/Storage Index, Database In-Memory Column Format/Storage Index, 実行計画の改善, 高速化 Buffer Cache, Database In-Memory, Flash Device, InfiniBand, Exafusion, 並列化 時間 = 処理量 / ( 速度 * 並列度 ) Parallel Query, Multi-Core, RAC, ASM, じかん = みちのり はやさ 21

22 Live Demo ある時間帯にパフォーマンス問題 (TPS の落ち込み ) が発生 Oracle Public Cloud 上のデータベース バージョン : 12.2 Swingbench 使用 更新系の OLTP 処理 22

23 Live Demo Database In-Memory の効果 23

24 Oracle Digital は オラクル製品の導入をご検討いただく際の総合窓口 電話とインターネットによるダイレクトなコニュニケーションで どんなお問い合わせにもすばやく対応します もちろん 無償 どんなことでも ご相談ください 24

25 25

26 26

27