おら! オラ!Oracle - どっぷり検証生活 - リスクに備えたログ管理の重要性 ~DB 特権ユーザのモニタリング~ Oracle Database 現場で役立つパフォーマンスチューニング 2010 年 8 月 25 日株式会社インサイトテクノロジーエンジニアリング本部テクノロジーコンサルティング部松尾亮 1
はじめに Oracle のチューニングポイントは 待機イベントを減らすこと!! 待機イベントの解消 = パフォーマンス向上 2
待機イベントとは? プロセスが CPU を使用していない時間 User I/O ロック競合 etc SQL 実行 Commit 実行 サーバプロセス SQL 解析 ロック待ち User I/O Redo 生成 commit バックグラウンドプロセス CPU Time 待機イベント Redo ログ書き込み 3
待機イベントの確認方法 ある期間におけるインスタンス全体の待機イベントを確認したい パフォーマンス統計レポート (STATSPACK or AWR) を確認 - STATSPACK Oracle 8.1.6 ~ - AWR Oracle 10.1.0 ~ EE のみ利用可 今回のセミナーでは Standerd Edition でも利用可能な STATSPACK を例にして説明します ある特定の処理おける待機イベントを確認したい SQL トレース 動的パフォーマンスビュー (V$ 表 ) を確認 4
STATSPACK 概要 ある期間 (snapshot 間 ) のデータベース処理の統計情報をレポートする 定期的にスナップショットを DB に保存 ( 手動 ) Standard Edition で利用可能! time snap#1 snap#2 snap#3 #1~#3 間のレポート取得 #2~#3 間のレポート取得 待機イベント統計 SGA のヒット率セッション統計 etc 5
STATSPACK の使用方法 SQL> -- STATSPACK 環境のインストール SQL> conn / as sysdba SQL> @$ORACLE_HOME/rdbms/admin/spcreate.sql STATSPACK 管理ユーザ (perfstat) のパスワード オブジェクト格納表領域 一時表領域を指定 SQL> -- スナップショットの取得 SQL> conn perfstat/password SQL> exec statspack.snap(i_snap_level=>7); スナップショットレベルについては次ページに記載 SQL> -- レポートの取得 SQL> conn perfstat/password SQL> @$ORACLE_HOME/rdbms/admin/spreport.sql レポートの開始 ID 終了 ID レポートファイル名を指定 6
STATSPACK の取得レベル (9iR2~) level 収集データ 基本統計アドバイス情報 SQL 統計 SQL 詳細セグメント情報ラッチ詳細 0 5 6 7 10 デフォルトは level 5 だが level 7 の情報が役立つことが多い Level 10 は情報量が多くスナップショット取得にかかる負荷が高くなる為 サポートから依頼された場合を除き 基本的に使用しない 7
STATSPACK レポートで最も注目すべきポイント Top 5 待機イベントが レポートで最も注目すべきポイント! Top 5 Timed Events Avg %Total ~~~~~~~~~~~~~~~~~~ wait Call Event Waits Time (s) (ms) Time ----------------------------------------- ------------ ----------- ------ ------ enq: TX - row lock contention 14,858 3,925 264 26.3 gc buffer busy acquire 419,613 2,921 7 19.6 shared server idle wait 453,775 1,978 4 13.3 enq: TX - index contention 32,020 1,757 55 11.8 CPU time 1,312 8.8 Waits : イベントのために待機した合計回数 Time(s) : 合計待機時間 ( 秒 ) Avg wait(ms) : 平均待機時間 %Total Call Time : 全ての待機時間に対する占有比率 上位の待機イベントの解消 = チューニング効果の期待大 8
STATSPACK での調査ステップ 1. Top 5 待機イベントを確認 2. 上位の待機イベントの意味を確認 ( マニュアル KROWN 等 ) 3. 待機イベントの発生要因に関連するセクションを調査 ex) db file scattered read db file sequential read 等 SQL Ordered By XXX セクションを確認 SQL チューニング? enqueue Enqueue activity Segments by Row Lock Waits セクションを確認 アプリ処理の見直し? buffer busy waits Segments by Buffer Busy Waits セクションを確認 空きリスト競合? 逆キー索引 パーティション化? 9
調査例ステップ 1 待機イベントの上位に以下 2 つのイベントが出現 db file scattered read マルチブロック読込 (Full Scan Index Fast Full Scan など ) db file sequential read 単一ブロック読込 (Index Scan) SQL の I/O 関連イベントなので SQL ordered by Elapsed time SQL ordered by Gets 等を確認 SQL ordered by Elapsed time for DB: Elapsed Elap per CPU Old Time (s) Executions Exec (s) %Total Time (s) Physical Reads Hash Value ---------- ------------ ---------- ------ ---------- --------------- ---------- 4071.23 50 81.4 52.4 500.71 7530123 1234567890 Module: httpd@web001.test.local (TNS V1-V3) SELECT FROM TAB1 WHERE 10
調査例ステップ 2 SQL ordered by XXX で確認した SQL 分析レポートを取得 SQL> @$ORACLE_HOME/rdbms/admin/sprepsql.sql Snap Snap Instance DB Name Id Snap Started Level Comment ------------ ------------ ----- ----------------- ----- ---------------------- orcl orcl 1 23 Aug 2010 19:00 7 2 23 Aug 2010 19:30 7 3 23 Aug 2010 20:00 7 4 23 Aug 2010 20:30 7 Specify the Begin and End Snapshot Ids ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ begin_snap に値を入力してください : 1 Begin Snapshot Id specified: 1 end_snap に値を入力してください : 2 End Snapshot Id specified: 2 Specify the Hash Value ~~~~~~~~~~~~~~~~~~~~~~ hash_value に値を入力してください : 1234567890 Hash Value specified is: 1234567890 11
調査例ステップ 3 SQL レポートを確認 First First Last Plan Snap Id Snap Time Active Time Hash Value Cost --------- ---------------- ---------------- ------------ ---------- 21 16-11 月 -09 23:00 17-11 月 -09 11:42 1503752779 130 22 17-11 月 -09 10:43 17-11 月 -09 11:11 4265373922 2 実行計画が変更されたタイミングが確認できる ~ 略 ~ -------------------------------------------------------------------------------- Operation PHV/Object Name Rows Bytes Cost -------------------------------------------------------------------------------- SELECT STATEMENT ----- 1503752779 ---- 130 FOR UPDATE PARTITION HASH ALL 1 360 130 TABLE ACCESS BY LOCAL INDEX RO TAB1 1 360 130 INDEX RANGE SCAN TAB1_IDX2 1 129 SELECT STATEMENT ----- 4265373922 ---- 2 FOR UPDATE PARTITION HASH SINGLE 1 60 2 TABLE ACCESS BY LOCAL INDEX RO TAB1 1 60 2 INDEX RANGE SCAN TAB1_IDX1 1 1 -------------------------------------------------------------------------------- 12
STATSPACK での分析に向かないケース ある特定の処理が遅かった ある特定の瞬間だけ遅かった スナップショットの取得間隔が 30 分間で - 通常 1 秒で終了する処理が 1 分かかった - ある 1 分間の間だけ高負荷状態になった etc このような場合 STATSPACK でボトルネックを検出することは困難 13
特定の SQL 調査 (SQL トレースを取得 ) 特定の SQL の待機イベント情報を含めた SQL トレースを取得 SQL> alter session set events '10046 trace name context forever, level 8'; ~ 問題のSQLを実行 ~ SQL> alter session set events '10046 trace name context off'; 実行中のセッションに対して SQL トレースを取得 -- v$session 等の情報からセッションを特定 alter session set nls_date_format='yyyy/mm/dd HH24:MI:SS'; select username,program,server,status,sid,serial#,last_logon_time from v$session where username is notnull; -- 特定した sid serial# に対して SQL トレースを取得 exec sys.dbms_system.set_ev(&sid, &serial, 10046, 8, ''); exec sys.dbms_system.set_ev(&sid, &serial, 10046, 0, ''); 取得したトレースファイルを整形 ( 初期化パラメータ user_dump_dest or background_dump_dest に出力される ) $ tkprof < トレースファイル名 > < 整形後ファイル名 > sys=no 14
特定の SQL 調査 (SQL トレースを確認 1) OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 2 0.59 0.66 0 656 0 0 Execute 2 0.00 0.00 0 0 0 0 Fetch 2 6.54 48.45 5599 18502 0 1 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 6 7.13 49.11 5599 19158 0 1 Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ SQL*Net message to client 4 0.00 0.00 SQL*Net message from client 4 25.87 56.30 row cache lock 2 0.00 0.00 ges message buffer allocation 2776 0.00 0.02 library cache lock 9 0.00 0.00 KJC: Wait for msg sends to complete 5 0.00 0.00 library cache pin 9 0.00 0.00 SQL*Net break/reset to client 2 0.00 0.00 gc cr grant 2-way 4 0.00 0.00 Disk file operations I/O 3 0.00 0.00 db file sequential read 5599 0.80 41.97 15
特定の SQL 調査 (SQL トレースを確認 2) ( 参考 ) TKPROF 整形前のトレース ~ 略 ~ WAIT #2: nam='db file sequential read' ela= 1211 file#=2 block#=18914 blocks=1 obj#=-1 tim=1282568692243420 WAIT #2: nam='ges message buffer allocation' ela= 8 pool=0 request=1 allocated=0 obj#=-1 tim=1282568692244398 WAIT #2: nam='gc cr disk read' ela= 226 p1=2 p2=18922 p3=4 obj#=-1 tim=1282568692244717 WAIT #2: nam='db file sequential read' ela= 1338 file#=2 block#=18922 blocks=1 obj#=-1 tim=1282568692246167 WAIT #2: nam='ges message buffer allocation' ela= 9 pool=0 request=1 allocated=0 obj#=-1 tim=1282568692247118 WAIT #2: nam='gc cr disk read' ela= 204 p1=2 p2=18930 p3=4 obj#=-1 tim=1282568692247414 WAIT #2: nam='db file sequential read' ela= 6934 file#=2 block#=18930 blocks=1 obj#=-1 tim=1282568692254461 WAIT #2: nam='db file sequential read' ela= 2327 file#=2 block#=18946 blocks=1 obj#=-1 tim=1282568692257806 WAIT #2: nam='db file sequential read' ela= 5903 file#=2 block#=18954 blocks=1 obj#=-1 tim=1282568692264806 WAIT #2: nam='db file sequential read' ela= 507 file#=2 block#=18962 blocks=1 obj#=-1 tim=1282568692266332 WAIT #2: nam='db file sequential read' ela= 2536 file#=2 block#=18970 blocks=1 obj#=-1 tim=1282568692270202 WAIT #2: nam='db file sequential read' ela= 5483 file#=2 block#=18978 blocks=1 obj#=-1 tim=1282568692276741 WAIT #2: nam='db file sequential read' ela= 3660 file#=2 block#=18986 blocks=1 obj#=-1 tim=1282568692281452 WAIT #2: nam='db file sequential read' ela= 496 file#=2 block#=18994 blocks=1 obj#=-1 tim=1282568692282994 WAIT #2: nam='db file sequential read' ela= 499 file#=2 block#=19002 blocks=1 obj#=-1 tim=1282568692284503 WAIT #2: nam='db file sequential read' ela= 504 file#=2 block#=19010 blocks=1 obj#=-1 tim=1282568692286000 ~ 略 ~ 16
特定の SQL 調査 (SQL 実行計画を確認 ) 実行計画の確認は 個人的には Explain Plan がお薦め! SQL を実行せずに Plan を表示する 実際に実行すると Plan が変わることがあるので注意 Predicate Information に出力される ID による紐付け 索引使用可否の判断 該当の where 句の判断が容易 -- PLAN_TABLE を作成 SQL> @?/rdbms/admin/utlxplan.sql -- SQL を解析 SQL> explain plan for 解析したい SQL 文 ; Explained. -- 解析結果を表示 SQL> select * from table(dbms_xplan.display()); 別紙にて詳細解説 17
チューニング事例紹介 ( ここからは Performance Insight を活用 ) 18
事例 1 ~ 概要 ~ システム概要 モバイルコンテンツ配信システムの DB Oracle11gR1 2node RAC 状況 テスト期間中 アプリの改修に伴い索引を新規追加 追加後の動作検証 ( 負荷テスト ) で遅延が発生 ( 追加前 :400 処理 / 秒 追加後 :200 処理 / 秒 ) 追加した表は 複数セッションから insert (1 処理 1 件 ) が大量に行われるという特性がある 要望 索引を追加した状態で追加前と同等のパフォーマンスに戻したい 19
事例 1 ~ 状況 ~ 索引追加前 CPU 使用率 索引追加後 CPU 使用率 待機イベント 待機イベント CPU 使用率は減少 (CPU が使えていない ) ロック関連の待機イベントが多発! 20
事例 1 ~ 状況 (STATSPACK では )~ 索引追加後 Top 5 Timed Events Avg %Total ~~~~~~~~~~~~~~~~~~ wait Call Event Waits Time (s) (ms) Time ----------------------------------------- ------------ ----------- ------ ------ enq: TX - row lock contention 14,858 3,925 264 26.3 gc buffer busy acquire 419,613 2,921 7 19.6 shared server idle wait 453,775 1,978 4 13.3 enq: TX - index contention 32,020 1,757 55 11.8 CPU time 1,312 8.8 ------------------------------------------------------------- Host CPU (CPUs: 16 Cores: 8 Sockets: 2) ~~~~~~~~ Load Average Begin End User System Idle WIO WCPU ------- ------- ------- ------- ------- ------- -------- 1.14 3.56 21.34 3.76 73.25 1.48 21
事例 1 ~ 状況 ~ 索引追加前 ロック発生オブジェクト 索引追加後 ロック発生オブジェクト buffer busy 発生オブジェクト buffer busy 発生オブジェクト 追加した索引に関連する表 索引に対するロック buffer busy が多発している! 22
事例 1 ~ 状況 (STATSPACK では )~ 索引追加後 Segments by Row Lock Waits Row Subobject Obj. Lock Pct Owner Tablespace Object Name Name Type Waits Total ---------- ---------- -------------------- ------------ ----- ------------ ----- SCOTT TS_INDEX TEST1_PKEY INDEX 10,524 24.8 SCOTT TS_INDEX TEST2_PKEY INDEX 8,422 19.8 SCOTT TS_INDEX TEST3_PKEY INDEX 7,243 17.1 SCOTT TS_INDEX TEST4_IDX1 INDEX 1,420 3.3 SCOTT TS_DATA TEST2_TAB TABLE 336.8 Segments by Buffer Busy Waits Buffer Subobject Obj. Busy Pct Owner Tablespace Object Name Name Type Waits Total ---------- ---------- -------------------- ------------ ----- ------------ ----- SCOTT TS_INDEX TEST1_PKEY INDEX 20,117 31.1 SCOTT TS_INDEX TEST2_PKEY INDEX 18,626 28.7 SCOTT TS_INDEX TEST3_PKEY INDEX 16,787 25.9 SCOTT TS_INDEX TEST3_IDX2 INDEX 3,499 5.4 SCOTT TS_INDEX TEST4_IDX1 INDEX 3,334 5.1 23
事例 1 ~ 現場の様子 ~ この時の現場の様子をお届けします アプリ担当者 ( 以下 アプリ ) アプリ改修したので 使いそうな索引を追加しました DBA 分かりました 確認します って めちゃくちゃいっぱいあるじゃないですか! この索引 全部使うんですか?? アプリ いやー ちょっと分からないんですけど 使うかもしれ ないとこには全部作ってみました 24
事例 1 ~ 現場の様子 ~ DBA そ そうですか 確か 今回索引を追加する表って どれも insert が大量に実行されるテーブルですよね? 索引があると insert は遅くなるんですよ だから 検索に使われない索引は削除したいですね アプリ はー そうですか DBA ま とりあえず負荷テストしてみますか そんなに影響出ないかもしれないし 25
事例 1 ~ 現場の様子 ~ パフォーマンス 50% に Down! DBA あらら ちょっと想像以上に遅くなりましたね まずは使われてない索引を削除しましょうか 想定される一連の処理を実行してもらえますか? アプリ はい 分かりました しばし待ち 実行終了 26
事例 1 ~ 現場の様子 ~ DBA 使われてない索引がいくつかあったので削除しますね これとこれと これらは削除しても影響なさそうですか? 確実に使う筈 というものがあれば教えて下さい アプリ うーん 削除しても大丈夫だと思います DBA じゃ 削除しますねー そして 再度負荷テスト 10% くらいパフォーマンス回復 まだ あと 40% 27
事例 1 ~ 現場の様子 ~ ( ちょっと break) 使用されていない索引の確認方法として索引のモニタリング機能がありますが v$sql_plan でメモリに存在する実行計画を参照し 現在 実行計画に使用されていないインデックスを確認するという方法も可能です 短期間のテスト等ではお手軽に確認できます SQL> select object_name,object_type,hash_value 1 from v$sql_plan 2 where object_type like 'INDEX%' and object_name like '%EMP%' 3 group by object_name,object_type,hash_value 4 order by 1,2; OBJECT_NAME OBJECT_TYPE HASH_VALUE ------------- ---------------- ---------- IDX_EMP_1 INDEX 4000148954 PK_EMP INDEX (UNIQUE) 1933697836 PK_EMP INDEX (UNIQUE) 4074557984 出力されてない 検索に利用されてない 28
事例 1 ~ 現場の様子 ~ DBA insert 競合を解消するには フリーリストを増やす! かな 試してみるか! と思ったけど この表がある表領域は自動セグメント領域管理だった フリーリストの調整はできないじゃん えーっと この表は連番で insert されていくから どうしても索引のブロックは競合するんだろうな insert insert insert 索引ブロック 00001 00002 00003 00004 00005 : insert insert 索引は順番に並んで格納される為 このシステムの処理特性上 同一ブロックへの競合が発生しやすい! 29
事例 1 ~ 現場の様子 ~ ( またまた ちょっと break) フリーリストとは insert 可能な空きブロックの情報を管理している領域 insert 時にはフリーリストの空きブロック情報を参照する為 insert の多重度が高いとフリーリストへのアクセスが競合する その場合 フリーリストを増加させることでパフォーマンスが向上する可能性がある 自動セグメント領域管理 (ASSM) では ビットマップ情報で空きブロック情報が管理され 明示的に調整はできない Insert Insert フリーリスト insert 可能なブロックのリスト #1 ( 空き ) #2 #3 #4 Insert Insert Insert block#1 block#5 block#7 #5 ( 空き ) #6 #7 ( 空き ) #8 30
事例 1 ~ 現場の様子 ~ DBA 連番で次々と insert されてくるデータを同一ブロックに集中させない為には ハッシュパーティションだな! 逆キー索引も有効か??? でも 逆キー索引は範囲検索できないんだよな 確か パーティションオプション持ってるし パーティショニングしてみるか! 問題となっていそうな表と索引をハッシュパーティション化 性能改善! 更に 以前より 20% 程度の性能向上! 31
事例 1 ~ 解説 ~ [ 原因 ] 連番データの insert が多重実行されるという特性であった為 同一ブロックへの競合が発生しやすい状況であった そのような状況で過剰に索引を追加したことにより ブロック競合が多発した [ 対処 ] 1. 丌要な索引の削除 2. ハッシュパーティショニング 32
事例 1 ~ 解説 ~ 索引がボトルネックになる場合もある - 更新系処理では 表データと同様に索引データの更新も必要となる為 オーバヘッドがかかる - 連番データの insert が多重実行されるような場合索引ブロックの競合が発生しやすい 33
事例 2 ~ 概要 ~ システム概要 金融系システムのDB Oracle10gR1 4node RAC 状況 取引は月曜午前 7 時から土曜午前 7 時まで 土曜の日中にメンテナンス作業実施 月曜午前 7 時のオープン直後からDBの負荷が急上昇 サーバハングによる障害発生 要望 障害調査を依頼 34
事例 2 ~ 状況 ~ CPU 使用率 障害 復旧 待機イベント enqueue の TS(Temp Segment) SS(Sort Segment) が増加している 35
事例 2 ~ 状況 ~ データファイル I/O TEMP 表領域への物理アクセスが多い 過剰なソートを実行している SQL がある?? 36
事例 2 ~ 状況 ~ 高負荷 SQL SQL [Hash Value=XXXXXXXXXX] ------------------------------------------------------------ SELECT FROM TAB1 WHERE DATE-TIME ROWS DISK_READS BUFFER_GETS CPU_TIME ELAPSED_TIME (YYYY/MM/DD HH24:MI:SS) EXEC /EXEC /EXEC /EXEC /EXEC(Sec) /EXEC(Sec) ----------------------- ----- ------ ----------- ------------ ----------- ------------- 2009/11/02 07:45:15 652 1 20,836 21,654 8.542 38.334 SQL [Hash Value=??????????] -------------------------------------------------- SELECT FROM TAB2 WHERE DATE-TIME ROWS DISK_READS BUFFER_GETS CPU_TIME ELAPSED_TIME (YYYY/MM/DD HH24:MI:SS) EXEC /EXEC /EXEC /EXEC /EXEC(Sec) /EXEC(Sec) ----------------------- ----- ------ ----------- ------------ ----------- ------------- 2009/11/02 07:45:12 42 472 6,302 11,249 4.905 176.225 CPU_TIME と ELAPSED_TIME の差が大きい 待機イベント時間が長いということ! 37
事例 2 ~ 現場の様子 ~ この時の現場の様子をお届けします 土曜の日中 Aさん 古いデータを大量に削除したからフラグメンテーションを解消しとかないとな SQL> alter table EMP move; SQL> alter index PK_EMP rebuild; SQL> alter index IDX_EMP_1 rebuild; SQL> alter index IDX_EMP_2 rebuild; A さん これで良し さ 帰ろっと 38
事例 2 ~ 現場の様子 ~ 月曜 7 時 A さんの携帯に運用監視オペレータから電話が OP A さんっ!DB サーバの CPU が 100% に張り付きっぱなしで サービスが停まってます! A さん えぇ!? すぐ確認します! A さんはリモート接続してすぐに調査を開始 39
事例 2 ~ 現場の様子 ~ 月曜 7 時 30 分頃 A さん 土曜にメンテナンスした表にアクセスしている SQL が 遅いみたいだな 実行計画が変わっちゃったみたい よし 統計情報を収集しよう! SQL> exec dbms_stats.gather_table_stats( - ownname => 'SCOTT', - tabname => 'EMP', - cascade => true); A さん どうかなぁ 40
事例 2 ~ 現場の様子 ~ 駄目だ!! 実行計画も変わってないようだ A さん 統計情報を再収集したから 再解析してる筈なんだ けどなぁ 何で実行計画が変わってくれないんだろ ブツブツ その後しばらく試行錯誤するも状況は改善せず 41
事例 2 ~ 現場の様子 ~ 月曜 8 時頃 A さん どうしよう 何か他に手はないかな あ 実行計画の問題だから共有プールも関係あるか? とりあえずフラッシュしてみよう SQL> alter system flush shared_pool; A さん ん? ちょっと負荷が下がってきたか? おぉー! 下がった下がった! よかった ~ これで一安心 でも かなり大きな損害が 42
事例 2 ~ 解説 ~ [ 原因 ] 以下のメンテナンス作業によって 表のオプティマイザ統計情報が削除された 1. 表の再編成 (move 処理 ) 2. 索引の再編成 (rebuild 処理 ) その後 統計情報再収集を行わなかった為 デフォルトの統計情報が利用され 結果的に適切な実行計画が選択されなかった ( 補足 ) move 処理後は索引が使用丌可 (STATUS=UNUSABLE) となる為 rebuild 処理が必須 43
事例 2 ~ 解説 ~ [ 統計情報の収集後 実行計画が変わらなかったワケ ] dbms_stats.gather_table_stats の no_invalidate オプションが auto_invalidate (10gR1 以降のデフォルト値 ) だった為 この auto_invalidate の場合 新しい統計情報を利用した再解析が行われるまでにタイムラグがある ( しばらくの間は既存のカーソルを再利用する ) [ 対策 ] 1.no_invalidate を false にして実行する ( 実行例 ) or 2. 共有プールをフラッシュする SQL> exec dbms_stats.gather_table_stats( - ownname => 'SCOTT', - tabname => 'EMP', - cascade => true, - no_invalidate => false); 44
Question? 45
製品のご紹介 データベース監査ツール パフォーマンス管理ツール データベースログ管理に必要なすべてを提供するツール 300 社 1,800 ライセンスを超える販売実績で J-SOX および情報漏洩対策ツールのシェア No.1 大規模顧客 大規模システムへの導入に強み 対応データベース Oracle Database EE/SE Microsoft SQL Server(2000_32bit.2005_32bit) Fujitsu Symfoware Server パフォーマンス管理 パフォーマンスチューニングを実現するツール 実績 1995 年の販売以来 1,000 社 8,000 ライセンスを超える販売実績 オラクルデータベースの 6 本に 1 本の割合で導入されるパフォーマンスツールのデファクトスタンダード 対応データベース Oracle Database EE/SE/SE1 オラクルデータベースの 6 本に 1 本という数字は 特定パートナー様からの報告内容より引用しております Copyright 2009 Insight Technology, Inc. All Rights Reserved. 46
おら! オラ!Oracle どっぷり検証生活 Oracle を徹底検証した結果を 隔週水曜日に配信しています ご登録はこちらから ( 無料!) http://www.insight-tec.com/mailmagazine/mailmagazine_index.html 本日のセミナーに関するお問い合わせなどご自由に rmatsuo@insight-tec.co.jp Copyright 2009 Insight Technology, Inc. All Rights Reserved. 47
無断転載を禁ず この文書はあくまでも参考資料であり 掲載されている情報は予告なしに変更されることがあります 本書で使用している製品やサービス名の名称は 各社の商標または登録商標です 48