« 2011年12月 | トップページ | 2012年2月 »

2012年1月30日 (月)

AWRレポート、AWR SQLレポート一括取得スクリプトを作ったよ。

Statspackレポートもそうなのですが、AWRレポート/AWR SQLレポートも個別に取得していると凄ーく辛いんですよね。一日分出力するとか、AWRレポートで処理時間の長いSQL文のAWR SQLレポートを個別に取得しようとなると...

ただでさえ忙しいのに、AWRレポート取得するのに時間掛けたくないですよね。

ということで、やっつけで作ったのですが、そのまま載せるのもあれなんで、やっつけで作った感じを多少減らしてgithubに公開しました。;)

https://github.com/discus/Oracle-AWR-batch-generation-script/blob/master/awrreport_batch.sql


もっといい感じに改造してくれるといいな〜とかとか... :)

Oracle11g R1/R2 Enterprise Edition、HTML形式で出力します。(RAC環境では試してないので多分だめかと。)。
AWRを利用するには追加ライセンスが必要なのでご注意を


使い方は・・

SQL*plusを起動し、select any dictionaryシステム権限、dbms_repositoryパッケージの実行権限が付与されたユーザで接続して実行するだけ。
SYSTEMユーザでやる事が多いけど、所変わればなんとやらなので・・・そこんとこよろしく。(w


一括取得なので実行当日を含めてn日分のAWRレポートを取得し、同時に処理時間の長いTop20のAWR SQLレポートも取得します。
レポートは各スナップショット間(今のところ固定)で取得します。

指定するパラメータは、以下の3つ。

Enter snap_id for starting AWR report generation. [NULL] : 
AWRレポートを取得する最初のSNAP_IDを指定します。 NULLがデフォルトでほとんどの場合デフォルトのままで事足りると思います。


Enter number of days for reporting period. [1] : 

一括取得する日数を指定します。当日を含みます。
当日分のAWRレポートを出力するのであれば、デフォルト値の1のままでOKです。


Enter suffix for AWR reports filename. [NULL] : test

保存するAWRレポートのファイル名に付加するsuffixを指定します。
試験名とか設定するといいですよね。

"test"と指定した場合

awrrpt_nnnn_nnnn_test.htmlや
awrsqrpt_nnnn_nnnn_test_sqlid.html

の形式で保存します。(nnnnはSNAP_ID)


実行例1)当日分の全レポートを取得する例

SYSTEM> 
SYSTEM> !ls -l awr*.sql
-rw-r--r-- 1 oracle oinstall 6065 1月 29 18:23 awrreport_batch.sql

SYSTEM> @awrreport_batch
--
-- Oracle AWR and AWR SQL report batch generation script
--
-- ***** This script always generate html format AWR reports. *****
--
Enter snap_id for starting AWR report generation. [NULL] :
Enter number of days for reporting period. [1] :
Enter suffix for AWR reports filename. [NULL] : test
--
--
--
clear break compute;
repfooter off;
ttitle off;
btitle off;

・・・中略・・・

<p />
<br /><a class="awr" href="#top">Back to Top</a><p />
</body></html>

SYSTEM>


実行例2)当日分かつsnap_id=291以降で一括取得。(事前にsnap_idを調べておいてね)

SYSTEM> 
SYSTEM> @awrreport_batch
--
-- Oracle AWR and AWR SQL report batch generation script
--
-- ***** This script always generate html format AWR reports. *****
--
Enter snap_id for starting AWR report generation. [NULL] : 291
Enter number of days for reporting period. [1] :
Enter suffix for AWR reports filename. [NULL] : test
--
--
--
clear break compute;
repfooter off;
ttitle off;
btitle off;

・・・中略・・・

<p />
<br /><a class="awr" href="#top">Back to Top</a><p />
</body></html>

SYSTEM>
SYSTEM>
SYSTEM> !ls -l *.html
-rw-r--r-- 1 oracle oinstall 379083 1月 29 22:23 awrrpt_291_292_test.html
-rw-r--r-- 1 oracle oinstall 11899 1月 29 22:23 awrsqrpt_291_292_test_0c83z9rqx45hu.html
-rw-r--r-- 1 oracle oinstall 11899 1月 29 22:23 awrsqrpt_291_292_test_0h3mfbzk6uyw0.html
-rw-r--r-- 1 oracle oinstall 11897 1月 29 22:23 awrsqrpt_291_292_test_2p7t0mw7zvu5z.html

・・・中略・・・

-rw-r--r-- 1 oracle oinstall 11899 1月 29 22:23 awrsqrpt_291_292_test_bhtycgwkxhfj9.html
-rw-r--r-- 1 oracle oinstall 11900 1月 29 22:23 awrsqrpt_291_292_test_bpaggvtfkar9k.html
-rw-r--r-- 1 oracle oinstall 11899 1月 29 22:23 awrsqrpt_291_292_test_c50hdbyuwhfn6.html
-rw-r--r-- 1 oracle oinstall 11892 1月 29 22:23 awrsqrpt_291_292_test_g3f3cw3zy5aat.html

SYSTEM>

なお、Oracleインスタンスが再起動された期間でawrrpt.sqlなどを実行すると、レポートが作成できずエラーでSQL*Plusも終了してしまいますが、本スクリプトでは該当部分のレポートはスキップするようにしてあります。:)

Instance     DB Name      Snap Id   Snap Started       Level
------------ ------------ --------- ------------------ -----
lampeye LAMPEYE 274 29 1月 2012 09:33 1
275 29 1月 2012 10:00 1
276 29 1月 2012 10:30 1
277 29 1月 2012 11:00 1
278 29 1月 2012 11:30 1
279 29 1月 2012 12:00 1
280 29 1月 2012 12:30 1
281 29 1月 2012 13:00 1
282 29 1月 2012 13:30 1
283 29 1月 2012 14:00 1
284 29 1月 2012 14:30 1
285 29 1月 2012 15:00 1
286 29 1月 2012 15:30 1
287 29 1月 2012 16:00 1
288 29 1月 2012 16:30 1
289 29 1月 2012 17:00 1
290 29 1月 2012 17:30 1

291 29 1月 2012 18:31 1 ←再起動されてる
292 29 1月 2012 18:34 1

293 29 1月 2012 22:26 1 ←再起動されてる


Enjoy!

| | コメント (2) | トラックバック (0)

2012年1月22日 (日)

WIF2012 の季節が近づいて来たな〜 :)

ウェブデザイン国際フェスティバル開催されるよ〜。

今年も熱い戦いがあるんだろーなー :) Interactive Design International Festival  29th-31st May 2012, Limoges, France 

楽しみだ



20120122_03912



WIF 2008 - ウェブデザイン国際フェスティバル
WIF2008 - Webdesign International Festival
WIF2008 - Webdesign International Festival - 予選終了
24(テレビドラマではないよ)
WIF2008 - Webdesign International Festival - ファイナリスト決定!
WIF2008 - Webdesign International Festival - 事務局スタッフの方がコメントをくれた!
WIF2008 - Webdesign International Festival - Finalまであと1ヶ月余り
いよいよWIF2008開幕
WIF2008 - WebJamが開始された。
WIF2008 - WebJam Results
WIF2010 - Web Design International Festival 2010だった〜
WIF2010 ファイナリスト 35チーム決定

| | コメント (0) | トラックバック (0)

2012年1月14日 (土)

shutdown immeidateしない、ほかの理由に遭遇! (FYI)


ず〜〜〜〜っと、追記しようと思ってたんだけど書いてなかったので、徹夜明けで早起きした次いでなんで書いておきます。

もう一年近く前のネタなんだけどね。「shutdown immeidateしない、ほかの理由に遭遇!」

> yoheia-a さんありがとう :)

私か書いた記事がキッカケで調べなきゃいけなくなったらしいんだけどね。 ;)

http://d.hatena.ne.jp/yohei-a/20110627/1309180675




shutdown immeidateしない、ほかの理由に遭遇!
shutdown immeidateしない、ほかの理由に遭遇! #2
shutdown immeidateしない、ほかの理由に遭遇! #3
shutdown immeidateしない、ほかの理由に遭遇! おまけ
shutdown immeidateしない、ほかの理由に遭遇! おまけのおまけ(でた〜最近、よくあるパターンw)

| | コメント (0) | トラックバック (0)

2012年1月 6日 (金)

Index Only Access (Index Only Scan) っていいよね(デメリットもあるけどさ) #2

Index Only Accessのいいとこ、紹介しちゃいますの続きです。

前回は、索引しかアクセスしない(Index Only Access)場合と、索引+表データもアクセスしちゃう場合の実行計画上の違いを確認しましたよね。


今回は、Index Only Accessで得られる改善効果の1つであるソート処理の回避について簡単な例で確認してみます。

※VISIBLE/INVISIBLEにしている索引の詳細は前回の記事を参照してくださいね。

Now Playing ♪ - ハイスクールララバイ / イモ欽トリオ - 1981

まず、最初は、悪い子の例から。

索引を全表走査した上で order by seq# でソート処理が実行されます。酷いですね。検索条件列に適切な索引を作れよ〜〜〜っ。という状態ですね。

SQL> alter index tab10_i01 invisible;

索引が変更されました。

SQL> alter index tab10_i02 invisible;

索引が変更されました。

SQL> select seq# from tab10 where non_unique_key = '0000000001' order by seq#;

10行が選択されました。

経過: 00:00:04.99

実行計画
----------------------------------------------------------
Plan hash value: 2100371779

----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 10 | 160 | 16788 (1)| 00:03:22 |
| 1 | SORT ORDER BY | | 10 | 160 | 16788 (1)| 00:03:22 |
|* 2 | TABLE ACCESS FULL | TAB10 | 10 | 160 | 16787 (1)| 00:03:22 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - filter("NON_UNIQUE_KEY"='0000000001')


統計
----------------------------------------------------------
0 recursive calls
0 db block gets
61544 consistent gets
61540 physical reads
0 redo size
655 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
10 rows processed

次に、普通の子の例。

検索条件であるnon_unique_keyに定義された索引を使いIndex range scanかつ、seq#をアクセスするために表データをrowidでアクセス。その後にソート処理が行われています。

普通の子らしい、よい実行計画ですね。 :)

SQL> alter index tab10_i01 visible;

索引が変更されました。

SQL> alter index tab10_i02 invisible;

索引が変更されました。

SQL> select seq# from tab10 where non_unique_key = '0000000001' order by seq#;

10行が選択されました。

経過: 00:00:00.08

実行計画
----------------------------------------------------------
Plan hash value: 1783972576

------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 10 | 160 | 5 (20)| 00:00:01 |
| 1 | SORT ORDER BY | | 10 | 160 | 5 (20)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| TAB10 | 10 | 160 | 4 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | TAB10_I01 | 10 | | 3 (0)| 00:00:01 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

3 - access("NON_UNIQUE_KEY"='0000000001')


統計
----------------------------------------------------------
0 recursive calls
0 db block gets
4 consistent gets
17 physical reads
0 redo size
655 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
10 rows processed

そして、最後は、良い子の登場。

この子、データ量が多くなった場合、ソート処理も足枷になると考えたようで Index only accessを利用したソート処理回避作戦を取ったようです。 
実行計画をみればわかりますが、索引しかアクセスしておらず、SORT ORDER BY というオペレーションも消えています!

検索条件である、non_unique_key列とソート対象のseq#列の2列からなる複合索引を利用するIndex only accessを狙ったようですね。

ただし、これには order by seq# [asc]であるという大前提があります。
order by seq# desc というソートも考慮する必要がある場合には、non_unique_key [asc]とseq# desc とした別の複合索引必要になります。(デメリットといえばデメリットですかね、)

order by seq# descというソート条件が仕様上無い事を事前に確認しておけば、なお完璧ですよね〜。 良い子。流石です。 :)

SQL> alter index tab10_i01 invisible;

索引が変更されました。

SQL> alter index tab10_i02 visible;

索引が変更されました。

SQL> select seq# from tab10 where non_unique_key = '0000000001' order by seq#;

10行が選択されました。

経過: 00:00:00.01

実行計画
----------------------------------------------------------
Plan hash value: 489654843

------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 10 | 160 | 3 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| TAB10_I02 | 10 | 160 | 3 (0)| 00:00:01 |
------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - access("NON_UNIQUE_KEY"='0000000001')


統計
----------------------------------------------------------
0 recursive calls
0 db block gets
4 consistent gets
16 physical reads
0 redo size
655 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
10 rows processed


次回へつづく。(他のソート回避の例も紹介しちゃうか、考えちう)


Index Only Access (Index Only Scan) っていいよね(デメリットもあるけどさ) #1

いん!、イン!、Index どっぷり Inde Only Access生活w - Oracle OpenWorld Unconference presented by JPOUG

| | コメント (0) | トラックバック (0)

2012年1月 4日 (水)

Index Only Access (Index Only Scan) っていいよね(デメリットもあるけどさ) #1

さて、OracleさんがAppleさんのOSで楽しいことしてくれないから最近つまんなくなりつつあるので、普通にSQL文のチューニングネタです。


鬼熱かった、鬼熱かった! :: Insight out 2011- DB tech showcaseでもかなり触れていた、Index Only Scan日本ではこの表現が割合的に多いようなのですが、Index Only Accessって言ってましたね、トムカイトさんも。英語では後者のほうが一般的なのかもしれません。ここではIndex Only Accessってことにしておきます。;)


デメリットもあるけど、Index Only Accessのいいとこばかりを中心に、書いちゃうよ〜w


まず、前提から。

TAB10表は以下のように定義してあります。意図的に表データが大きくなるようにしてあります :)

 名前                NULL?    型
------------------ -------- --------------
SEQ# NOT NULL NUMBER
NON_UNIQUE_KEY NOT NULL CHAR(10)
DATA VARCHAR2(500)

また、以下のような索引を事前に索引しているが、PK_TAB10という主キー索引以外はINVISIBLEとして作成してある。
INVISIBLEで作成しておくと、索引は通常通りメンテナンスされるが、オプティマイザは実行計画作成時にINVISIBLEな索引を利用しないというOracle11gから登場した便利な機能

また前述の表には以下のような主キー(PK_TAB10)と非ユニークな索引が2つ作成してあります。(あまり良い例ではないですがご勘弁を)
但し、TAB10_I01、TAB10_I02の2索引は、INVISIBLEで作成してあります。効果確認時など便利ですよね。
(不可視索引の詳細はマニュアル「Oracle Database 管理者ガイド 11gリリース1(11.1)不可視索引の作成」を参照のこと。


INDEX_NAME COLUMN_NAME
------------ -------------------
PK_TAB10 SEQ#

TAB10_I01 NON_UNIQUE_KEY

TAB10_I02 NON_UNIQUE_KEY
SEQ#

検証時の処理時間及び、実行統計は、各クエリを2回実行し2回目の処理時間及び、実行統計を載せてあります。
(2回目の実行前にバッファキャッシュをクリアしてあるので、ソフトパース+キャッシュミスほぼ100%という状況の処理時間及び実行統計情報です。)

テストデータは以下件数で、non_unique_keyは偏りはなく均一に分布させあります。
実際のはなし、均等になることの方が稀ではあると思いますけど、Index Only Accessの効果を見る事ができればそれでOKなので。

COUNT(1)
----------
800000


COUNT(DISTINCTNON_UNIQUE_KEY)
-----------------------------
80000


NON_UNIQUE COUNT(1)
---------- ----------
0000000001 10
0000000002 10
0000000003 10
0000000004 10
0000000005 10
0000000006 10
0000000007 10
0000000008 10
0000000009 10
0000000010 10
0000000011 10
0000000012 10
0000000013 10
0000000014 10
0000000015 10
0000000016 10
0000000017 10
0000000018 10
0000000019 10
0000000020 10

・・・以下略・・・

まず最初は一番分かりやすい、Index Only Accessの例から。

non_unique_key列に、TAB10_I01という非ユニーク索引を作成してありますが、現状、INVISIBLE状態にしてあるため索引が無く全表走査となっていますよね。

SQL> set autot trace exp stat
SQL>
SQL> select count(non_unique_key) from tab10 where non_unique_key between '0000000001' and '0000000010';

経過: 00:00:04.32

実行計画
----------------------------------------------------------
Plan hash value: 1584905094

----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 11 | 16787 (1)| 00:03:22 |
| 1 | SORT AGGREGATE | | 1 | 11 | | |
|* 2 | TABLE ACCESS FULL| TAB10 | 100 | 1100 | 16787 (1)| 00:03:22 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - filter("NON_UNIQUE_KEY"<='0000000010' AND
"NON_UNIQUE_KEY">='0000000001')


統計
----------------------------------------------------------
0 recursive calls
0 db block gets
61544 consistent gets
61539 physical reads
0 redo size
562 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

ここで、TAB10_I01索引をVISIBLEへ変更して同一クエリを実行してみると……
TAB10_I01索引を利用した実行計画はIndex Range Scanに変化します。しかも、表データはアクセスしていません。これがIndex Only Accessの典型的な例です。アクセスブロック数も処理時間も大きく改善していますよね。

ただ、Index only scanにはデメリットもあります。

それは、索引が多くなればなるほどDML文には足枷になり遅くなるため点です。参照と更新、挿入、削除のバランスを取るのが大切ですが、
とにかく参照を速くする、更新、挿入、削除の処理性能などは少々犠牲にしても問題ないのであれば、どんどんやっちゃいます!(ご利用は計画的にw)

SQL> alter index tab10_i01 visible;
SQL>
SQL> select count(non_unique_key) from tab10 where non_unique_key between '0000000001' and '0000000010';

経過: 00:00:00.02

実行計画
----------------------------------------------------------
Plan hash value: 3770330610

-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 11 | 3 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 11 | | |
|* 2 | INDEX RANGE SCAN| TAB10_I01 | 100 | 1100 | 3 (0)| 00:00:01 |
-------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("NON_UNIQUE_KEY">='0000000001' AND
"NON_UNIQUE_KEY"<='0000000010')


統計
----------------------------------------------------------
0 recursive calls
0 db block gets
3 consistent gets
3 physical reads
0 redo size
562 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

ちなみに、クエリは少々違うのですが、Index only accessで無い場合は、index range scan+table access by index rowidとなり以下のような実行計画になっちゃいます。
(こちらの方がよく目にする実行計画じゃないでしょうかね。私も性能的な問題等なければ以下のような実行計画であれば良しとしておくことが多いのも事実です。。)

実行計画
----------------------------------------------------------
Plan hash value: 1097902029

------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 100 | 51700 | 11 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID | TAB10 | 100 | 51700 | 11 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | TAB10_I02 | 100 | | 3 (0)| 00:00:01 |
------------------------------------------------------------------------------------------

次回へつづく。(忙しくてなかなか書けないかもw)

| | コメント (0) | トラックバック (0)

Dashboard de Aquarium v1.6 released!

Dashboard de Aquarium v1.6をリリースしました。前回修正した(つもりだった)Snow Leopard以降で発生する問題点の再修正(単純に修正方法がまずかった)しました。
(Dashboard de Aquarium v1.6 released.
What's new in this version : Fixed bug.)

Picture_2_2

Download Dashboard De Aquarium v1.6 Now!

Download! v1.6 dashboard_de_aquarium.zip (997KB)

日本語(Japanese):
"Mac OS X 10.4 Tiger以降が必要です。ダウンロードにSafariを使用する場合は、はじめにダウンロードのリンクをクリックしてください。次にダウンロードの完了後、ウィジェットを表示し、プラスボタンをクリックしてウィジェットバーを表示させ、ダウンロードしたウィジェットを追加してください。Safari以外のブラウザを使用する場合は、はじめにダウンロードのリンクをクリックしてください。次にダウンロードの完了後、解凍したウィジェットを /ライブラリ/Widgets/ フォルダに配置してください。ウィジェットを表示し、プラスボタンをクリックしてウィジェットバーを表示させ、ダウンロードしたウィジェットを追加してください。"

English:
"Mac OS X 10.4 Tiger or later is required. If you’re using Safari, click the download link. When the widget download is complete, show Dashboard, click the Plus sign to display the Widget Bar and click the widget’s icon in the Widget Bar to open it. If you’re using a browser other than Safari, click the download link. When the widget download is complete, unarchive it and place it in /Library/Widgets/ in your home folder. show Dashboard, click the Plus sign to display the Widget Bar and click the widget’s icon in the Widget Bar to open it."


動作確認した機種とMacOSXのバージョンは以下の通り。
(H/W models and the version of Mac OS X that I checked the operation as follows.)

System Requirements : MacOSX Tiger 10.4 or later -- Freeware.

PowerBook G4 1Ghz - MacOSX 10.5.8 (Leopard)
MacBookAir 1.86Ghz Core 2 Duo - MacOSX 10.7.2 (Lion)

Note: 国際化対応しています。言語環境が日本語であればメニューやボタンのテキストは日本語で表示されます。
Screen_shot_20100601_at_221756 Screen_shot_20100601_at_221810
Screen_shot_20100601_at_221821 Screen_shot_20100601_at_221832
Screen_shot_20100601_at_221840 Screen_shot_20100601_at_221915
Screen_shot_20100601_at_221936 Screen_shot_20100601_at_221946_2
20120104_153510

| | コメント (0) | トラックバック (0)

2012年1月 1日 (日)

謹賀新年 - 穏やかな一年を期待しつつ…そうもいかないでしょうけど



明けましておめでとうおめでとうございます。
(毎年同じ画像ですが)



33


| | コメント (0) | トラックバック (0)