oracle database...event waits time (s) (ms) time enq: tx - row lock contention 14,858 3,925 264 26.3...

1

リスクに備えたログ管理の重要性～DB特権ユーザのモニタリング～

2010年8月25日

株式会社インサイトテクノロジー

エンジニアリング本部

テクノロジーコンサルティング部

松尾亮

☆おら！オラ！Oracle -どっぷり検証生活-★

Oracle Database現場で役立つパフォーマンスチューニング

2

はじめに

Oracle のチューニングポイントは・・・

待機イベントを減らすこと！！

待機イベントの解消＝パフォーマンス向上

3

待機イベントとは？

プロセスがCPUを使用していない時間

User I/O、ロック競合、etc…

バックグラウンドプロセス

サーバプロセス

SQL解析

User I/O

SQL実行 Commit実行

Redo生成

commit

Redoログ書き込み

CPU Time

待機イベント

ロック待ち

4

待機イベントの確認方法

ある期間におけるインスタンス全体の待機イベントを確認したい

→ パフォーマンス統計レポート(STATSPACK or AWR)を確認

- STATSPACK ・・・ Oracle 8.1.6 ～

- AWR ・・・ Oracle 10.1.0 ～、EE のみ利用可

※今回のセミナーでは、Standerd Edition でも利用可能な STATSPACK を

例にして説明します。

ある特定の処理おける待機イベントを確認したい

→ SQLトレース、動的パフォーマンスビュー(V$表)を確認。

5

STATSPACK 概要

snap#1

定期的にスナップショットをDBに保存 (手動)

ある期間(snapshot間)のデータベース処理の統計情報をレポートする

snap#2 snap#3

time

#1～#3間のレポート取得

#2～#3間のレポート取得

Standard Editionで利用可能！

待機イベント統計SGAのヒット率セッション統計etc…

6

STATSPACK の使用方法

SQL> -- STATSPACK 環境のインストールSQL> conn / as sysdbaSQL> @$ORACLE_HOME/rdbms/admin/spcreate.sql

→ STATSPACK管理ユーザ（perfstat）のパスワード、オブジェクト格納表領域、一時表領域を指定

SQL> -- スナップショットの取得SQL> conn perfstat/passwordSQL> exec statspack.snap(i_snap_level=>7);

※スナップショットレベルについては次ページに記載

SQL> -- レポートの取得SQL> conn perfstat/passwordSQL> @$ORACLE_HOME/rdbms/admin/spreport.sql

→ レポートの開始ID、終了ID、レポートファイル名を指定

7

STATSPACK の取得レベル(9iR2～)

level 収集データ

基本統計アドバイス情報 SQL統計 SQL詳細セグメント情報ラッチ詳細

0 ○ ○

5 ○ ○ ○

6 ○ ○ ○ ○

7 ○ ○ ○ ○ ○

10 ○ ○ ○ ○ ○ ○

デフォルトは level 5 だが level 7 の情報が役立つことが多い。Level 10 は情報量が多くスナップショット取得にかかる負荷が高くなる為、サポートから依頼された場合を除き、基本的に使用しない。

8

STATSPACK レポートで最も注目すべきポイント

Top 5 待機イベントが、レポートで最も注目すべきポイント！

Top 5 Timed Events Avg %Total~~~~~~~~~~~~~~~~~~ wait CallEvent Waits Time (s) (ms) Time----------------------------------------- ------------ ----------- ------ ------enq: TX - row lock contention 14,858 3,925 264 26.3gc buffer busy acquire 419,613 2,921 7 19.6shared server idle wait 453,775 1,978 4 13.3enq: TX - index contention 32,020 1,757 55 11.8CPU time 1,312 8.8

Waits ：イベントのために待機した合計回数Time(s) ：合計待機時間(秒)Avg wait(ms) ：平均待機時間%Total Call Time ：全ての待機時間に対する占有比率

上位の待機イベントの解消＝チューニング効果の期待大

9

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 セクションを確認→ 空きリスト競合？逆キー索引、パーティション化？

10

調査例ステップ①

待機イベントの上位に以下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 OldTime (s) Executions Exec (s) %Total Time (s) Physical Reads Hash Value

---------- ------------ ---------- ------ ---------- --------------- ----------4071.23 50 81.4 52.4 500.71 7530123 1234567890

Module: [email protected] (TNS V1-V3)SELECT ･･･ FROM TAB1 WHERE ･･･

11

調査例ステップ②

SQL> @$ORACLE_HOME/rdbms/admin/sprepsql.sql

Snap SnapInstance DB Name Id Snap Started Level Comment------------ ------------ ----- ----------------- ----- ----------------------orcl orcl 1 23 Aug 2010 19:00 7

2 23 Aug 2010 19:30 73 23 Aug 2010 20:00 74 23 Aug 2010 20:30 7

Specify the Begin and End Snapshot Ids~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~begin_snapに値を入力してください: 1Begin Snapshot Id specified: 1

end_snapに値を入力してください: 2End Snapshot Id specified: 2

Specify the Hash Value~~~~~~~~~~~~~~~~~~~~~~hash_valueに値を入力してください: 1234567890Hash Value specified is: 1234567890

SQL ordered by XXX で確認した SQL 分析レポートを取得

12

調査例ステップ③

First First Last PlanSnap Id Snap Time Active Time Hash Value Cost

--------- ---------------- ---------------- ------------ ----------21 16-11月-09 23:00 17-11月-09 11:42 1503752779 13022 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 |--------------------------------------------------------------------------------

SQL レポートを確認

実行計画が変更されたタイミングが確認できる

13

STATSPACK での分析に向かないケース

ある特定の処理が遅かった・・・

ある特定の瞬間だけ遅かった・・・

スナップショットの取得間隔が30分間で、- 通常、1秒で終了する処理が1分かかった- ある1分間の間だけ高負荷状態になったetc…

このような場合、STATSPACK でボトルネックを検出することは困難。

14

特定の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_timefrom 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

15

特定のSQL調査(SQLトレースを確認①)

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

call count cpu elapsed disk query current rows------- ------ -------- ---------- ---------- ---------- ---------- ----------Parse 2 0.59 0.66 0 656 0 0Execute 2 0.00 0.00 0 0 0 0Fetch 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.00SQL*Net message from client 4 25.87 56.30row cache lock 2 0.00 0.00ges message buffer allocation 2776 0.00 0.02library cache lock 9 0.00 0.00KJC: Wait for msg sends to complete 5 0.00 0.00library cache pin 9 0.00 0.00SQL*Net break/reset to client 2 0.00 0.00gc cr grant 2-way 4 0.00 0.00Disk file operations I/O 3 0.00 0.00db file sequential read 5599 0.80 41.97

16

特定のSQL調査(SQLトレースを確認②)

～略～

WAIT #2: nam='db file sequential read' ela= 1211 file#=2 block#=18914 blocks=1 obj#=-1 tim=1282568692243420WAIT #2: nam='ges message buffer allocation' ela= 8 pool=0 request=1 allocated=0 obj#=-1 tim=1282568692244398WAIT #2: nam='gc cr disk read' ela= 226 p1=2 p2=18922 p3=4 obj#=-1 tim=1282568692244717WAIT #2: nam='db file sequential read' ela= 1338 file#=2 block#=18922 blocks=1 obj#=-1 tim=1282568692246167WAIT #2: nam='ges message buffer allocation' ela= 9 pool=0 request=1 allocated=0 obj#=-1 tim=1282568692247118WAIT #2: nam='gc cr disk read' ela= 204 p1=2 p2=18930 p3=4 obj#=-1 tim=1282568692247414WAIT #2: nam='db file sequential read' ela= 6934 file#=2 block#=18930 blocks=1 obj#=-1 tim=1282568692254461WAIT #2: nam='db file sequential read' ela= 2327 file#=2 block#=18946 blocks=1 obj#=-1 tim=1282568692257806WAIT #2: nam='db file sequential read' ela= 5903 file#=2 block#=18954 blocks=1 obj#=-1 tim=1282568692264806WAIT #2: nam='db file sequential read' ela= 507 file#=2 block#=18962 blocks=1 obj#=-1 tim=1282568692266332WAIT #2: nam='db file sequential read' ela= 2536 file#=2 block#=18970 blocks=1 obj#=-1 tim=1282568692270202WAIT #2: nam='db file sequential read' ela= 5483 file#=2 block#=18978 blocks=1 obj#=-1 tim=1282568692276741WAIT #2: nam='db file sequential read' ela= 3660 file#=2 block#=18986 blocks=1 obj#=-1 tim=1282568692281452WAIT #2: nam='db file sequential read' ela= 496 file#=2 block#=18994 blocks=1 obj#=-1 tim=1282568692282994WAIT #2: nam='db file sequential read' ela= 499 file#=2 block#=19002 blocks=1 obj#=-1 tim=1282568692284503WAIT #2: nam='db file sequential read' ela= 504 file#=2 block#=19010 blocks=1 obj#=-1 tim=1282568692286000

～略～

（参考） TKPROF 整形前のトレース

17

特定の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());

※別紙にて詳細解説

18

チューニング事例紹介

(ここからは、Performance Insight を活用)

19

事例1 ～概要～

• システム概要– モバイルコンテンツ配信システムのDB

– Oracle11gR1 2node RAC

• 状況– テスト期間中、アプリの改修に伴い索引を新規追加。

追加後の動作検証（負荷テスト）で遅延が発生。

（追加前：400処理/秒→追加後：200処理/秒）

– 追加した表は、複数セッションから insert （1処理1件）が大量に行われるという特性がある。

• 要望– 索引を追加した状態で追加前と同等のパフォーマンスに

戻したい。

Copyright © 2010 Insight Technology, Inc. All Rights Reserved.

20

CPU使用率は減少。（CPUが使えていない）ロック関連の待機イベントが多発！

事例1 ～状況～

索引追加前索引追加後

待機イベント待機イベント

CPU使用率 CPU使用率


21

事例1 ～状況(STATSPACKでは)～

索引追加後

Top 5 Timed Events Avg %Total~~~~~~~~~~~~~~~~~~ wait CallEvent Waits Time (s) (ms) Time----------------------------------------- ------------ ----------- ------ ------enq: TX - row lock contention 14,858 3,925 264 26.3gc buffer busy acquire 419,613 2,921 7 19.6shared server idle wait 453,775 1,978 4 13.3enq: TX - index contention 32,020 1,757 55 11.8CPU 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

22

事例1 ～状況～

索引追加前索引追加後

追加した索引に関連する表、索引に対するロック、buffer busy が多発している！

ロック発生オブジェクトロック発生オブジェクト

buffer busy発生オブジェクト buffer busy発生オブジェクト


23

事例1 ～状況(STATSPACKでは)～

索引追加後

Segments by Row Lock WaitsRow

Subobject Obj. Lock PctOwner Tablespace Object Name Name Type Waits Total---------- ---------- -------------------- ------------ ----- ------------ -----SCOTT TS_INDEX TEST1_PKEY INDEX 10,524 24.8SCOTT TS_INDEX TEST2_PKEY INDEX 8,422 19.8SCOTT TS_INDEX TEST3_PKEY INDEX 7,243 17.1SCOTT TS_INDEX TEST4_IDX1 INDEX 1,420 3.3SCOTT TS_DATA TEST2_TAB TABLE 336 .8

Segments by Buffer Busy WaitsBuffer

Subobject Obj. Busy PctOwner Tablespace Object Name Name Type Waits Total---------- ---------- -------------------- ------------ ----- ------------ -----SCOTT TS_INDEX TEST1_PKEY INDEX 20,117 31.1SCOTT TS_INDEX TEST2_PKEY INDEX 18,626 28.7SCOTT TS_INDEX TEST3_PKEY INDEX 16,787 25.9SCOTT TS_INDEX TEST3_IDX2 INDEX 3,499 5.4SCOTT TS_INDEX TEST4_IDX1 INDEX 3,334 5.1

24

事例1 ～現場の様子～

この時の現場の様子をお届けします・・・

アプリ担当者（以下、アプリ）

「アプリ改修したので、使いそうな索引を追加しました。」

DBA 「分かりました。確認します。

・・・って、めちゃくちゃいっぱいあるじゃないですか！

この索引、全部使うんですか？？」

アプリ「いやー、ちょっと分からないんですけど、使うかもしれ

ないとこには全部作ってみました。


25


DBA 「そ、そうですか・・・

確か、今回索引を追加する表って、どれも insert が

大量に実行されるテーブルですよね？

索引があると insert は遅くなるんですよ。

だから、検索に使われない索引は削除したいですね。」

アプリ「はー、そうですか・・・」

DBA 「ま、とりあえず負荷テストしてみますか。

そんなに影響出ないかもしれないし。」


26


パフォーマンス50%にDown！

DBA 「あらら・・・ちょっと想像以上に遅くなりましたね。。。

まずは使われてない索引を削除しましょうか。

想定される一連の処理を実行してもらえますか？」

アプリ「はい、分かりました。」

しばし待ち、実行終了・・・


27


DBA 「使われてない索引がいくつかあったので削除しますね。

これとこれと・・・

これらは削除しても影響なさそうですか？

確実に使う筈、というものがあれば教えて下さい。」

アプリ「うーん、削除しても大丈夫だと思います。」

DBA 「じゃ、削除しますねー」

そして、再度負荷テスト・・・

１０%くらいパフォーマンス回復。まだ、あと40%・・・


28


（ちょっと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

出力されてない→検索に利用されてない


29


DBA 「insert 競合を解消するには・・・

フリーリストを増やす！かな。試してみるか！

と思ったけど、、、

この表がある表領域は自動セグメント領域管理だった。

フリーリストの調整はできないじゃん・・・

えーっと、この表は連番で insert されていくから、

どうしても索引のブロックは競合するんだろうな。。。」

0000100002000030000400005

：

索引ブロックinsert

insert

insert

insert

insert

索引は順番に並んで格納される為、このシステムの処理特性上、同一ブロックへの競合が発生しやすい！


30


（またまた、ちょっとbreak）

フリーリストとは、 insert 可能な空きブロックの情報を管理している

領域。insert 時にはフリーリストの空きブロック情報を参照する為、

insert の多重度が高いとフリーリストへのアクセスが競合する。

その場合、フリーリストを増加させることでパフォーマンスが向上する

可能性がある。自動セグメント領域管理（ASSM）では、ビットマップ

情報で空きブロック情報が管理され、明示的に調整はできない。

insert可能なブロックのリスト

block#1block#5block#7

Insert #1

（空き）#2 #3 #4

#5

（空き）#6 #7

（空き）#8

Insert

Insert

Insert

Insert

フリーリスト


31


DBA 「連番で次々と insert されてくるデータを同一ブロックに

集中させない為には・・・

ハッシュパーティションだな！

逆キー索引も有効か？？？

でも、逆キー索引は範囲検索できないんだよな、確か。

パーティションオプション持ってるし、パーティショニング

してみるか！」

問題となっていそうな表と索引をハッシュパーティション化・・・

性能改善！更に、以前より20%程度の性能向上！


32

事例1 ～解説～

[原因]

連番データの insert が多重実行されるという特性であった為、

同一ブロックへの競合が発生しやすい状況であった。

そのような状況で過剰に索引を追加したことにより、ブロック競合

が多発した。

[対処]

1．丌要な索引の削除。

2．ハッシュパーティショニング。


33

事例1 ～解説～

索引がボトルネックになる場合もある。

- 更新系処理では、表データと同様に索引データの

更新も必要となる為、オーバヘッドがかかる。

- 連番データの insert が多重実行されるような場合

索引ブロックの競合が発生しやすい。


34

事例２～概要～

• システム概要

– 金融系システムのDB

– Oracle10gR1 4node RAC

• 状況

– 取引は月曜午前7時から土曜午前7時まで

– 土曜の日中にメンテナンス作業実施

– 月曜午前7時のオープン直後からDBの負荷が急上昇

– サーバハングによる障害発生

• 要望

– 障害調査を依頼


35

事例２～状況～

待機イベント

CPU使用率復旧障害


enqueue の TS(Temp Segment)、SS(Sort Segment)が増加している。

36



TEMP表領域への物理アクセスが多い。過剰なソートを実行しているSQLがある？？

データファイル I/O

37



CPU_TIME と ELAPSED_TIME の差が大きい→ 待機イベント時間が長いということ！

高負荷 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

38

事例２～現場の様子～

この時の現場の様子をお届けします・・・

【土曜の日中】

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さん「これで良し。さ、帰ろっと。」


39


【月曜7時】

Aさんの携帯に運用監視オペレータから電話が・・・

OP 「Aさんっ！DBサーバのCPUが100%に張り付きっぱなしで

サービスが停まってます！」

Aさん「えぇ！？すぐ確認します！」

Aさんはリモート接続してすぐに調査を開始。


40


【月曜7時30分頃】

Aさん「土曜にメンテナンスした表にアクセスしているSQLが

遅いみたいだな。実行計画が変わっちゃったみたい・・・

よし、統計情報を収集しよう！」

SQL> exec dbms_stats.gather_table_stats( -

ownname => 'SCOTT', -

tabname => 'EMP', -

cascade => true);

Aさん「どうかなぁ・・・。」


41


駄目だ！！

実行計画も変わってないようだ。

Aさん「統計情報を再収集したから、再解析してる筈なんだ

けどなぁ・・・何で実行計画が変わってくれないんだろ。

ブツブツ・・・」

その後しばらく試行錯誤するも状況は改善せず・・・


42


【月曜8時頃】

Aさん『どうしよう・・・何か他に手はないかな。。。

あ、実行計画の問題だから共有プールも関係あるか？

とりあえずフラッシュしてみよう。』

SQL> alter system flush shared_pool;

Aさん『ん？ちょっと負荷が下がってきたか？

おぉー！下がった下がった！よかった～』

これで一安心・・・

でも、かなり大きな損害が。。。


43

事例２～解説～

[原因]

以下のメンテナンス作業によって、表のオプティマイザ統計情報が

削除された。

1．表の再編成（move処理）

2．索引の再編成（rebuild処理）

その後、統計情報再収集を行わなかった為、デフォルトの統計情報

が利用され、結果的に適切な実行計画が選択されなかった。

（補足）

move処理後は索引が使用丌可（STATUS=UNUSABLE）となる為、

rebuild処理が必須。


44

事例２～解説～

[統計情報の収集後、実行計画が変わらなかったワケ]

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);

45

Question？


46

製品のご紹介

データベース監査ツール

• データベースログ管理に必要なすべてを提供

するツール

• 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ライ

センスを超える販売実績。オラクルデータ

ベースの６本に１本の割合で導入されるパ

フォーマンスツールのデファクトスタンダード

• 対応データベース

Oracle Database EE/SE/SE1

※オラクルデータベースの６本に１本という数字は、特定パートナー様からの報告内容より引用しております。


47

おら！オラ！Oracle どっぷり検証生活

Oracleを徹底検証した結果を、隔週水曜日に配信しています。


ご登録はこちらから（無料！）http://www.insight-tec.com/mailmagazine/mailmagazine_index.html

本日のセミナーに関するお問い合わせなどご自由に・・・[email protected]

http://www.insight-tec.com/mailmagazine/mailmagazine_index.html



mailto:[email protected]



oracle database...event waits time (s) (ms) time enq: tx - row lock contention 14,858 3,925 264 26.3...

Documents