2012年5月 6日 (日)

VirtualBox 4.1.14 と OS X Mountain Lion対応? 4.1.15がリリースされてた

今気づいたけど、4.1.14だけだと思ったら、MacOS X Mountain Lion対応の VirtualBox 4.1.15も出てたのね。:)

https://www.virtualbox.org/wiki/Downloads

20120506_183804


20120506_190633


とりあえずアップデート

20120506_185041


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

オプティマイザをだましちゃお! の続き。

オプティマイザをだましちゃお! の続きです。

リテラル値指定、かつ、全件ヒットするからTABLE FULL SCANになるはずなのに、何故、INDEX RANGE SCANしたのか? の種明かしです


status列の値が全て 0 の状態で統計情報を取得した状態で、status列全てを 2 に更新、その後統計情報は再取得していません。
オプティマイザは、status列が全て 0 だと思い込んでいるわけですね、実際は、全て 2 なのに。

08:55:05 SCOTT> update deluding_tab set status = 2;

100000行が更新されました。

08:55:15 SCOTT> commit;

コミットが完了しました。

status列が全て、またはほぼ、 0 なのであれば、全データをINDEX RANGE SCANで取得するなんて通常はあり得ないですよね :) 

列値と統計情報の取得タイミングでオプティマイザを騙しているわけです。
(これは意図的ですが、意図せずオプティマイザが誤った実行計画を算出して夜中に電話が鳴った,なんて方は意外に多いかも…w)

続きを読む "オプティマイザをだましちゃお! の続き。"

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

2012年5月 1日 (火)

オプティマイザをだましちゃお! (マジック・ザ・ギャザリング風w かも)

ということで、準備から。なにやら索引がいるのか怪しい列にまでBツリー索引を作成しちゃってます ;)

23:34:03 SYS> conn scott/tiger
接続されました。
23:36:01 SCOTT>
23:36:01 SCOTT>
23:36:01 SCOTT> create table deluding_tab (id number not null, status number(2) not null, data varchar2(500)) nologging;

表が作成されました。

23:50:47 SCOTT> begin for i in 1..100000 loop insert into deluding_tab values(i,0,lpad(i,500,'*')); end loop; end;
23:55:22 2 /

PL/SQLプロシージャが正常に完了しました。

23:55:27 SCOTT> commit;

コミットが完了しました。

23:55:31 SCOTT> alter table deluding_tab add constraint pk_deluding_tab primary key (id) using index nologging;

表が変更されました。

23:56:07 SCOTT> create index ix_deluding_tab on deluding_tab(status) nologging;

索引が作成されました。

23:58:26 SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'DELUDING_TAB', -
23:58:34 > no_invalidate=>false,cascade=>true,method_opt=>'FOR ALL COLUMNS SIZE AUTO');

PL/SQLプロシージャが正常に完了しました。

ヒストグラムの状態も見ておきましょ。

TABLE_NAME                     COLUMN_NAME                    NUM_BUCKETS HISTOGRAM
------------------------------ ------------------------------ ----------- ---------------
DELUDING_TAB ID 1 NONE
DELUDING_TAB STATUS 1 NONE
DELUDING_TAB DATA 1 NONE

登録したデータ件数も見ておきましょうか。

00:03:27 SCOTT> 
00:08:41 SCOTT> select count(1) from deluding_tab;

COUNT(1)
----------
100000

では、オプティマイザとデュエル!


アンタップ、アップキープ、ドロー! 

00:03:54 SCOTT> select * from deluding_tab where status = 1;

レコードが選択されませんでした。

経過: 00:00:00.01

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

------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time |
------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 508 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| DELUDING_TAB | 1 | 508 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IX_DELUDING_TAB | 1 | | 1 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------

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

2 - access("STATUS"=1)


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

データはヒットしていないですね。索引レンジスキャンは妥当な実行計画:)

続きを読む "オプティマイザをだましちゃお! (マジック・ザ・ギャザリング風w かも)"

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

2012年4月28日 (土)

述語のつづきの続き。

前回の続きです。


今回の例も今ひとつといえばそうなのだけど、述語プッシュで索引が利用されることを期待した書き方なのに残念な結果になっている以下のようなパターン、意外と見かけるんですよー
オプティマイザが進化して今以上に賢くなったら気にしなくても最適化してくれるかもしれないけど………

11:28:59 SCOTT> l   
1 select
2 v1.id
3 ,v1.data
4 from
5 (
6 select
7 to_char(id) as id
8 ,data
9 from
10 push_pred_test1
11 union
12 select
13 to_char(id) as id
14 ,data
15 from
16 push_pred_test2
17 ) v1
18 where
19* v1.id = 10
11:30:40 SCOTT> /

11行が選択されました。

経過: 00:00:01.58

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

------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 11 | 814 | 4857 (1)| 00:00:59 |
| 1 | VIEW | | 11 | 814 | 4857 (1)| 00:00:59 |
| 2 | SORT UNIQUE | | 11 | 1166 | 4857 (91)| 00:00:59 |
| 3 | UNION-ALL | | | | | |
|* 4 | TABLE ACCESS FULL| PUSH_PRED_TEST1 | 1 | 106 | 445 (1)| 00:00:06 |
|* 5 | TABLE ACCESS FULL| PUSH_PRED_TEST2 | 10 | 1060 | 4410 (1)| 00:00:53 |
------------------------------------------------------------------------------------------

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

4 - filter(TO_NUMBER(TO_CHAR("ID"))=10)
5 - filter(TO_NUMBER(TO_CHAR("ID"))=10)


統計
----------------------------------------------------------
0 recursive calls
0 db block gets
17554 consistent gets
15960 physical reads
0 redo size
1819 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)
11 rows processed

11:30:43 SCOTT>


続きを読む "述語のつづきの続き。"

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

2012年4月27日 (金)

述語 ;) のつづき

さて、前回のつづきです。

以下のようにtable full scanになっちゃってるのをもうちょっといい感じにチューニングするには? ってとこまででした。

わかっちゃったもんね〜〜〜〜〜〜の方〜〜〜〜〜〜〜っ。 沢山いるようですね。頼もしいです:)

赤字で示した部分が重要なんですよーーーー。TO_CHAR()関数が使われていて述語プッシュでうまく索引が利用できないのが原因なんですよ。

22:52:28 SCOTT> set autot trace exp stat
22:52:34 SCOTT>
22:52:35 SCOTT>
22:52:35 SCOTT> l
1 select
2 t1.id
3 ,t1.data
4 ,t1.ctr
5 from
6 (
7 select
8 to_char(t0.id) as id
9 ,data
10 ,count(1) as ctr
11 from
12 push_pred_tab1 t0
13 group by
14 t0.id
15 ,t0.data
16 ) t1
17 where
18 t1.id between 1 and 20
19 order by
20* t1.id
22:52:38 SCOTT> /

20行が選択されました。

経過: 00:00:00.07

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

--------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time |
--------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 250 | 123K| 1950 (1)| 00:00:24 |
| 1 | SORT ORDER BY | | 250 | 123K| 1950 (1)| 00:00:24 |
| 2 | HASH GROUP BY | | 250 | 123K| 1950 (1)| 00:00:24 |
|* 3 | TABLE ACCESS FULL| PUSH_PRED_TAB1 | 250 | 123K| 1948 (1)| 00:00:24 |
--------------------------------------------------------------------------------------------

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

3 - filter(TO_NUMBER(TO_CHAR("T0"."ID"))>=1 AND
TO_NUMBER(TO_CHAR("T0"."ID"))<=20)


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

続きを読む "述語 ;) のつづき"

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

2012年4月25日 (水)

述語 ;)

書こうと思っているうちに時間がなくて書けなかったので、簡単なチューニングネタを一つ。


こんな感じのクエリ、どうやったら、いい感じにチューニングできるんでしょうね?

ちなみに、index only accessにする必要はないです。 やってもいいけどw

(いろいろ端折りすぎたらお題のクエリイマイチw ま、いいっか)

・準備 - 以下のような表を作って、データを登録しておきます。

22:33:20 SCOTT> create table push_pred_tab1 (id number not null, data varchar2(500)) nologging;

表が作成されました。

経過: 00:00:00.02
22:33:53 SCOTT> begin for i in 1..100000 loop insert into push_pred_tab1 values(i,lpad(i,500,'*')); end loop; commit; end;
22:36:30 2 /

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:04.17
22:38:03 SCOTT> alter table push_pred_tab1 add constraint pk_push_pred_tab1 primary key(id) using index nologging;

表が変更されました。

経過: 00:00:00.18
22:38:28 SCOTT>
22:47:55 SCOTT> exec
dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'PUSH_PRED_TAB1',no_invalidate=>false,cascade=>true);

PL/SQLプロシージャが正常に完了しました。

経過: 00:00:00.31

続きを読む "述語 ;)"

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

2012年4月 8日 (日)

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

Oracle OpenWorld Unconference presented by JPOUG
とこかで聞いたようなタイトルを"インデックス"に置換えた「いん!、イン!、Index どっぷり Inde Only Scan生活w」のセッション資料を公開します。
(相変わらず文才ないな〜〜と落ち込む....作文嫌いは死ぬまで治らないと思ってるが、がんばって書くw)

デモ内容とデモ環境情報を追加予定です。 2012/4/15デモとデモ環境情報追加しました)

直前にデモ環境のOracle11gR2が起動しないという想定外のトラブルを乗り越えw かなりイッパイ、イッパイの状態でしたが楽しい時間を過ごさせていただきました。

関係者の皆様、ご来場の皆様、ありがとうございました。

Safari以外のブラウザではアニメーション効果はありませんが、Safari (Mac/iPad/iPhone)ではKeynote風(但し、ページ間のトランジッションなし)に表示されます。

いん!、イン!、IndexどっぷりIndes Only Scan生活w


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

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

2012年4月 7日 (土)

VirtualBox 4.1.12 released

https://www.virtualbox.org/wiki/Changelog

20120407_194045

おやおや、今気づいたけど、VirtualBoxについてのダイアログ。バー部分が角張ってるよね。4.1.10から上部だけ角張ってる。

4.1.8まではラウンドだったのに…気になる

以下、4.1.8

20111220_12335


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

2012年3月17日 (土)

売れてるんだね。

InnoDB Deep Talk #1に参加してきました。が、勉強会の話は別エントリにします。今日はDB関連書籍の売れ行きの話。

勉強会で、まつのぶさんの本すげ〜売れてるという話を聞いて早速amazonのぞいてみたら…。すごい売れ行きですね。

ちなみに、http://dbstudy.info/files/20120310/mysql_costcalc.pdf sh2ndさんのセッションで出された宿題まだやってません. m(_ _)m

まつのぶさんの本ってamazonの本全体で435位か、すげ〜。

20120317_84208

ミックさんの本、DB部門だと、まつのぶさんに次いで2位、本全体で、1496位か、これまたすげ〜

20120317_84341

ミックさんと小田さんの本、データベース部門だと、トップ10に2冊もランクイン、すげ〜。

20120317_85604



20120317_85620

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

2012年3月16日 (金)

VirtualBox 4.1.10 released - あれ前回は 4.1.8だったけど一つ飛んだね

https://www.virtualbox.org/

少々時間空いたな〜と思っていたら、4.1.8の次は、一つ飛ばして4.1.10ですね。:)

20120316_163833

Oracle OpenWorld Tokyo 2012 Unconference当日のデモ環境は VirtualBox4.1.10で、GuestOSはCentOS5.8、データベースはOracle11g R2で。もちろんホストOSはOS Xですよ:)

Unconference_jpoug

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

2012年2月25日 (土)

Oracle OpenWorld Tokyo 2012 Unconference


JPOUGのFacebookページはこちら :)


Unconference_jpoug


Oracle OpenWorldの3日目(4/6)に・・・・


なにかが・・・・・・


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

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)


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

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

2012年1月22日 (日)

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

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

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

楽しみだ



20120122_03912


続きを読む "WIF2012 の季節が近づいて来たな〜 :)"

| | コメント (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

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

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