DB Tech Showcase 2016 Tokyo - E35 - SQLチューニング総合診療所的予防医学のセッション資料を公開しました。
ぼくとつと、性能試験データの質などのことを言い続ける感じになっていたでしょうか？w
ところで、次回のJPOUG主催のイベントの開催が決まりました。セッション内容は現在準備中ですが、確定次第随時更新します。
お申し込みは以下のイベントベージよりお願いします。
| 固定リンク | 0 | コメント (0) | トラックバック (0)
db tech showcase 2014 Tokyo (Fall)から半年、今年も db tech showcase 2015の季節が....
あれ？ 例年より早くないか？？ （大人の事情でっす！ 多分）
今回は、Oracle CloudWorld 2015 Tokyoでも行った、「な〜んでだ？」再び
を行いました。
多くの方に参加していただき、ありがとうございました。
ちなみに、
”再び”としていますが、Oracle CloudWorldネタ再演ではないです、書き下ろしネタです！！（キリっ
ただ、準備不足感もあり、只今、一人反省会中でございます。 (^^;;
トリの新久保さんより長めにやってま〜〜す。:)
そういえば、
statspackのsnapshot idは番号が飛ぶことがあるけど、AWRのsnapshot idが飛ばないは、なーんでだ？ w
新久保さんのネタです。
（小田さんスタイルで、キラーパスで回答を求めるって方がいいのかもしれないですね...やはり。)
次回のJPOUGイベントで笑顔のDBエンジニアの方々にお会い出来ることを楽しみにしています。^^)
夢に出てきたので、再びメモ。
→なーんでだ？ って以前からやれたらいいなーと思っていたドクターGのような感じで進められそうだと今気づく。 orz.
| 固定リンク | 0 | コメント (0) | トラックバック (0)
恒例となってきたデータベースのお祭り db tech showcase tokyo
今年も、JPOUGのSQLチューニング総合診療医w として治療話をしてきました :)
貴重な機会を提供いただいたインサイトテクノロジーの皆様、そして、お忙しい中、セッションに参加してくださった皆様、ありがとうございました。
当日は気合で乗り切ったものの翌日は力尽きて発熱で資料アップが遅れていましたが
L35 「SQLチューニング総合診療所 ケースファイルX」の資料をslideshareに公開しました。
来年のお祭りを楽しみにしています:)
あ、そうそう、
Craig Shallahamer さんのセッションを聴講したときに感じたのですが、「本人が楽しそうに話す」の重要！！
ですね。 :)
| 固定リンク | 0 | コメント (0) | トラックバック (0)
I love your data（どこかのパクリw) な人たちが、いろいろなDBMSを見聞きし、それぞれの思いで、何年か先の未来に、それぞれの思いを馳せる
そんな、集まりが、 db tech showcase 2014 Osaka
(ん....俺っぽくない出だしを書いててワロタ....）
に臨時休業（自分ではこれも仕事のうちなんだがw 仕事って思ってないだけw）して参加した。
https://www.facebook.com/db.tech.showcase
Slideshare : セッション資料はここ
話を聞いていたら、オレオレレプリケーションできそうな気になるから不思議 :) .
オレオレ、ゴルゲやオレオレ、attunityとか、自分で作って試してみると、面倒くさいポイントとか見えていいかもね。
Attunity Replicateの画面を初めてみたけど、シンプルで好きなデザイン。
・B31 : LogMinerってレプリケーションソフトで使われてるけどどうなってる？ / 森田俊哉(インサイトテクノロジー)
Oracle以外の話も聴きたくてNoSQL系などをチョイス。 割り切った実装で特定用途でその力を発揮する。割り切り大事。
・D32 : Amazon Redshift Deep Dive / 大久保順(アマゾンデータサービスジャパン)
・B33 : Riak: 本物の高可用性を実現する仕組みとは？ / 佐藤 貴彦 (Bashoジャパン)
・D34 : データウェアハウス・エンジンTeradataのご紹介とビッグデータ統合アーキテクチャー / 山本 泰史(日本テラデータ)
The Machine!にも関連するのだろうけど、Memristorの話題も!
・D35 : インメモリーデータベース徹底比較 / 小森博之(日本HP)
そしてスペシャルセッション、遠い未来じゃないはなし
・A36 : ウエアラブルとO2Oが切り拓くICTの新地平 / 村上憲郎
vessylもそんな”もの”の一つかもしれない。飲みものの分析ができるんだからトイレにも応用できるんじゃないか的な :)
日本のトイレがそうなるかは分からないけど、先にやってくれたら面白いかもね。
毎日が健康診断、データはかかりつけの医師に共有されていて、気になるデータが見つかると、洗面台のミラー風マルチタッチデバイスに情報がプッシュされ...必要なら、その場で通院予約、その後待たされることなく診察なんて時間の無駄がなくていいな〜と、ぼーっと妄想していたり。
楽しいやね。 :)
そういえばそんなシーンのある映画で思い出したのがこれ
東京から大阪への新幹線で日帰りだと電池切れ感が半端ないので一泊することをおすすめしますw
| 固定リンク | 0 | コメント (0) | トラックバック (0)
11/13〜15に開催されたdb tech showcase tokyo 2013 の最終日、午後の４枠で特濃JPOUGとてセッションを行いました。
貴重な機会を提供いただいたインサイトテクノロジーの皆様ありがとうございました。
また、お忙しい中、セッションに参加してくださった皆様、ありがとうございました。
A35
15:00-15:45 / 「JPOUG特濃：潮溜まりでジャブジャブ、SQLチューニング」 のセッション資料を公開しました。
塩分濃いめの潮溜まりで釣り上げたSQLは治療できるかどうかもわからない病になっていました….
治療できたか、できなかったのか……
曲者すぎる難病もありますが、何かの機会に思い出していただければと思います。
みなさん、楽しい時間をありがとう。
| 固定リンク | 0 | コメント (0) | トラックバック (0)
db tech showcase 2012
Unconference at db tech showcase 2012
db tech showcaseの一角をJPOUGが占拠してUnconferenceを開催しました。 db tech showcase関係者の皆様、このような機会を与えて頂き大変感謝します。
そして、お疲れさまでした。
Index Only Access ３部作の最終回？! として 「Index Only Accessが実装されるたった一つの理由」と題したセッションを行いました。
実行計画を取得するために操作したデータベースの中には人生二度目のデータベース複数もあり、かなりの時間を裂いて調べた割にはセッション時間が少々短めになってしまいました。m(_ _)m
なぜ、このテーマを選んだか.
PostgreSQLがリリースされてから9.1まで実装されなかったIndex Only Accessでしたが、9.2でついに実装されました。
そして..db tech showcase 2012は...
SQL> select dbms_name from all_dbms where dbms_category like "%";
DBMS_NAME
------------------
Oracle
DB2
MySQL
PostgreSQL
SQL Server
Vecterwise
MongoDB
Symfoware
Clustrix
InfiniDB
.
.
.
.
的な雰囲気となっていることもあり、Index Only Accessの魚拓をあつめて比較、Index Only Accessが実装される理由について今一度、考えてみたいな..と。
タイトル見ただけで理由が想像できた方は、資料見なくても大丈夫だと思いますよ。:)
H/Wの性能が急速に伸びてきている影響もあるように感じますが、無駄に広範囲な検索や、無駄にビッグなデータとなっていること気にしていないのではないか？ というケースが多くなっていると感じています。
DBMSはアクセスするデータをより少なくするための工夫をしているのに...エンジニアがそれをうまく使っていない、使えていない、設計できてない...そんな"感じ"がするんです。
セッション資料を公開しました。
じゃ、like "%てない" 状況をどうすればいいか....答えは、小田さんのセッションの中にあった。。。。:)
#不慣れなDBMSもあり、こんなメトリックみたほうが分かりやすいよ〜、などのツッコミ歓迎します.
| 固定リンク | 0 | コメント (0) | トラックバック (0)
JPOUGが、再び、Unconference をやっちゃいます！ （タイムスケジュールなどはJPOUG(Japa Oracle User Group)のサイトをご覧ください）
今回はインサイトテクノロジー社主催のdb tech showcase 2012で...
| 固定リンク | 0 | コメント (0) | トラックバック (0)
さて、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)と非ユニークな索引が２つ作成してあります。（あまり良い例ではないですがご勘弁を）
但し、TAB10_I01、TAB10_I02の２索引は、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#
検証時の処理時間及び、実行統計は、各クエリを２回実行し２回目の処理時間及び、実行統計を載せてあります。
（２回目の実行前にバッファキャッシュをクリアしてあるので、ソフトパース＋キャッシュミスほぼ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) | トラックバック (0)
書くのおそくなっちゃいました m(_ _)m
１０月１９日〜２１日に開催されたInsight out 2011- DB tech showcase
に、つまみ食いながらなんとか参加し、インサイトテクノロジーさんの鬼熱い魂を感じてきた :)
無理矢理空き時間作って参加したセッションは以下の通り。
MySQLとかPostgreSQLとかOSSなのはOSCとかでも聴けるかなーと思いきづいたらOracle中心だったw
Effective Indexing/Developer and Indexes というセッションは予想以上だった、Indexを理解してるのって重要だよなーと改めて感じたセッションだった。
Tom Kyteさんが紹介していた書籍、「Relational Database Index Design and the Optimizers」
鬼熱い語りの山下さんのセッション、前回のOOWのUnconferenceの続編か？と思わせるような諸橋さんのセッション、つい引き込まれちゃいましたよ：）
参加者やスピーカが鬼熱いエンジニアであることは間違いないが、何と言っても、世界中からデータベースに関わる凄い方々を集めてしまうインサイトテクノロジーさんが一番、鬼熱いんじゃないかと感じた３日間だった。
来年も開催して頂きたいイベントだ。
| 固定リンク | 0 | コメント (0) | トラックバック (0)
最近のコメント