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

とりあえずアップデート

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

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

リテラル値指定、かつ、全件ヒットするから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)

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

オプティマイザをだましちゃお！ （マジック・ザ・ギャザリング風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 かも)"

述語のつづきの続き。

前回の続きです。

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

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> 

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

述語 ;) のつづき

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

以下のように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

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

述語 ;)

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

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

ちなみに、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

続きを読む "述語 ;)"

いん！、イン！、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 どっぷり Inde Only Access生活w - Oracle OpenWorld Unconference presented by JPOUG "

VirtualBox 4.1.12 released

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

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

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

以下、4.1.8

売れてるんだね。

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

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

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

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

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

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

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

https://www.virtualbox.org/

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

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

Oracle OpenWorld Tokyo 2012 Unconference

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

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

なにかが・・・・・・

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レポートも取得します。
レポートは各スナップショット間（今のところ固定）で取得します。

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

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レポート一括取得スクリプトを作ったよ。"

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

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

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

楽しみだ

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

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）

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

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

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

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

※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"