SQLのシーケンシャルアクセスと実I/Oとしてのシーケンシャルアクセス データベースコンサルタントのノウハウちょい見せ

Oracle RDBMSなどのオラクル製品や各種インフラ技術(OS、ストレージ、ネットワーク)といった話題を取り上げます。著者は小田圭二、「門外不出のOracle現場ワザ」、「絵で見てわかるOracleの仕組み」、「絵で見てわかるOS/ストレージ/ネットワーク」などの著作もあります

ホーム > スポンサー広告 > SQLのシーケンシャルアクセスと実I/Oとしてのシーケンシャルアクセスホーム > DBA > SQLのシーケンシャルアクセスと実I/Oとしてのシーケンシャルアクセス

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
[ --/--/-- --:-- ] スポンサー広告 | トラックバック(-) | コメント(-)

SQLのシーケンシャルアクセスと実I/Oとしてのシーケンシャルアクセス

今回は、一部の人には「驚愕の事実」(らしい)、SQLのシーケンシャルアクセスと実I/Oとしてのシーケンシャルアクセスが異なる(ことがある)という話です。

何回か前の記事に、『OTNの記事を読みました。待機イベント名の「sequential(シーケンシャル)」は実質的にはランダムI/O・・・が衝撃的でした』とコメントをいただきました。確かに誤解している人が多い事実です。解説についてはこちら(リプライコメント)を御覧ください。

そのコメントを読んでいて、もっと多くの人が誤解している、ちょっとマニアックなOracleの動作があることを思い出しました。それは、SQL上ではシーケンシャルアクセス(フルスキャン)となっていながら、実I/Oではランダムアクセスが発生することがあるという事実です。<- 驚愕の事実?

この記事は、その仕組みの解説と検証による証明を載せています。本記事は「仕組みをしりたい」もしくは「コンサルの検証ノウハウの一端を見たい」という方に向いていると思います。

●仕組みの解説

昔のDBMSと比べ、Oracleはキャッシュを強く意識しています。キャッシュを前提としたアーキテクチャになっている断言しても良いと私は思います。ここで仮に、あるテーブルが4ブロックで構成されていて、その4ブロックのうち3ブロックがキャッシュに載っているとします。そのような状況でテーブルをフルスキャンするSQLが実行されたとします。すると、3ブロックが載っていますから、残りの1ブロックをランダムアクセスで読み込む・・・という動作をOracleはします

4ブロック中の2ブロックがキャッシュに存在し、キャッシュに載っていないブロックがディスク上で連続しているとします。その場合、その2ブロックだけを読み取るシーケンシャルアクセスをOracleは行います。SQLの実行計画がシーケンシャルアクセスであっても、キャッシュに存在しないデータだけを実I/Oで読みこむということです。

●検証

多少、省いているログもありますが、実際に試したところ次のような結果となりました。コンサルの検証テクニックとともに、ご確認ください。

☆確認したいこと
・キャッシュに載っていないときは、実I/Oも全ブロックをシーケンシャルアクセスをしている
・キャッシュにある程度載っていて、載っていないブロックがディスク上連続して存在している場合には、載っていないブロックだけシーケンシャルアクセスする
・キャッシュにほとんどのブロックが載っていて、1ブロックだけディスク上に残っている場合には、そのブロックだけランダムアクセスする

☆テクニック
・ある行が、どのブロックに存在しているのか確認する
・該当ブロックがキャッシュに載っているか確認する
・バッファキャッシュをフラッシュするコマンド
・待機イベントの履歴から、シーケンシャルアクセスかどうか、シーケンシャルアクセスの場合には、どのブロックを、何ブロック連続で読み込んだか確認する


☆準備(テーブル作成とデータ増殖)

SQL> create table test (no number, text varchar2(100));

表が作成されました。

SQL> create index test_index on test (no);

索引が作成されました。

SQL>
SQL> insert into test values(1,'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');

1行が作成されました。

SQL>
SQL>
SQL> insert into test select no+1, text from test;

1行が作成されました。

SQL> insert into test select no+2, text from test;

2行が作成されました。

・・・・

SQL> insert into test select no+128, text from test;

128行が作成されました。

#test表自身のデータを活用して、test表のデータを倍々に増やすやり方です。
#この増殖のさせ方は楽ですよ。

次の表の先頭行と後方の行が、どのファイル、どのブロックに存在するかを確認します。ご存知の方も多いと思いますが、DBMS_ROWIDというパッケージで調査できます。

SQL> select DBMS_ROWID.ROWID_RELATIVE_FNO (rowid),
2 DBMS_ROWID.ROWID_BLOCK_NUMBER (rowid),
3 DBMS_ROWID.ROWID_ROW_NUMBER (rowid)
4 from test where no = 1;

DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------------ ------------------------------------
DBMS_ROWID.ROWID_ROW_NUMBER(ROWID)
----------------------------------
1 87986
0


SQL>
SQL> select DBMS_ROWID.ROWID_RELATIVE_FNO (rowid),
2 DBMS_ROWID.ROWID_BLOCK_NUMBER (rowid),
3 DBMS_ROWID.ROWID_ROW_NUMBER (rowid)
4 from test where no = 255;

DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------------ ------------------------------------
DBMS_ROWID.ROWID_ROW_NUMBER(ROWID)
----------------------------------
1 87989
56

このテーブルの行は、ファイル番号:1の、ブロック番号が87986から87989の間に含まれていることが分かりました。

統計情報の取得などを行った上で、いったんバッファキャッシュから消えてもらいます。実は、最近のOracleであれば、「alter system flush buffer_cache」というコマンドが使えます。

SQL> alter system flush buffer_cache;

システムが変更されました。

SQL> select file#, block#, status from v$bh where file# = 1 and block# between 8
7986 and 87989 order by block#;

FILE# BLOCK# STATUS
---------- ---------- ----------
1 87986 free
1 87987 free
1 87987 free
1 87987 free
1 87987 free
1 87987 free
1 87988 free
1 87989 free
1 87989 free

このv$bhというビューは、バッファキャッシュの状況を確認することができます。freeという状態は、キャッシュに載っていないということを意味します。このv$bhは検証のときに重宝します。

次に、SQL*PlusのSID(セッションID)を特定します。これはあとで、具体的なI/Oを確認するためにSIDが必要となるためです。SYS_CONTEXT関数で、自分自身のセッションの情報を取ることができます。

SQL> SELECT SYS_CONTEXT('USERENV','SESSIONID') AUDSID from dual;

AUDSID
--------------------------------------------------------------------------------

80096

SQL> select sid from v$session where audsid = 80096;

SID
----------
122


SIDが122だと判明しました。

☆キャッシュにブロックが無いケース

test表をフルスキャンします。その後、SIDが122のセッションの過去10個の待機イベントを調べます。待機イベントからシーケンシャルアクセスかどうか、連続ブロック数はいくつなのか、読み込んでいるブロックはどれなのかを確認できます。

SQL> select sid, event, p1,p2,p3, time_since_last_wait_micro from v$session_wait
_history where sid = 122;

SID EVENT
---------- ----------------------------------------------------------------
P1 P2 P3 TIME_SINCE_LAST_WAIT_MICRO
---------- ---------- ---------- --------------------------
122 SQL*Net message to client
1111838976 1 0 27

122 SQL*Net message from client
1111838976 1 0 91

122 SQL*Net message to client
1111838976 1 0 582

122 db file scattered read
1 87986 4 552

122 db file sequential read
1 87985 1 79

122 db file sequential read
1 87993 1 670

122 SQL*Net message from client
1111838976 1 0 6

「db file scattered read」は、OracleのシーケンシャルアクセスのI/Oです。P1がファイル番号、P2がブロックアドレスです。P3がブロック数です。1 と 87986 で 4 となっているため、test表全体を1回のシーケンシャルアクセスで読み込んでいます。

☆キャッシュに一部のブロックが載っているケース

4ブロックのうち、最初と最後のブロックのみキャッシュに載せます。

SQL> select /*+ index(test,test_index) */ * from test where no = 1;
SQL> select /*+ index(test,test_index) */ * from test where no = 255;

SQL> select file#, block#, status from v$bh where file# = 1 and block# between 8
7986 and 87989 order by block#;

FILE# BLOCK# STATUS
---------- ---------- ----------
1 87986 xcur
1 87986 free
1 87986 free
1 87987 free
1 87987 free
1 87987 free
1 87987 free
1 87987 free
1 87988 free
1 87988 free
1 87989 xcur
1 87989 free
1 87989 free
1 87989 free

14行が選択されました。

xcurという状態は、キャッシュに載っていることを示します(一種の状態)。

87987 と 87988 はキャッシュに載っていません。この状態でフルスキャンを実行します。待機イベントを確認します。

SQL> select sid, event, p1,p2,p3, time_since_last_wait_micro from v$session_wait
_history where sid = 122;

SID EVENT
---------- ----------------------------------------------------------------
P1 P2 P3 TIME_SINCE_LAST_WAIT_MICRO
---------- ---------- ---------- --------------------------
122 SQL*Net message to client
1111838976 1 0 31

122 SQL*Net message from client
1111838976 1 0 131

122 db file scattered read
1 87987 2 196

122 db file sequential read
1 87985 1 52

説明したように、載っていないブロックのみ、シーケンシャルアクセスで
読み込んでいます。db file scattered read のP2とP3が、
87987 と 2 となっています。


☆キャッシュにほとんどのブロックが載っているケース

select /*+ index(test,test_index) */ * from test where no = 1;
select /*+ index(test,test_index) */ * from test where no = 128;
select /*+ index(test,test_index) */ * from test where no = 255;

SQL> select file#, block#, status from v$bh where file# = 1 and block# between 8
7986 and 87989 order by block#;

FILE# BLOCK# STATUS
---------- ---------- ----------
1 87986 free
1 87986 xcur
1 87987 free
1 87987 xcur
1 87987 free
1 87987 free
1 87987 free
1 87988 free
1 87989 free
1 87989 xcur

10行が選択されました。

87988のみキャッシュに載っていません。フルスキャンを実行します。待機イベントを確認します。

SQL> select sid, event, p1,p2,p3, time_since_last_wait_micro from v$session_wait
_history where sid = 122;

SID EVENT
---------- ----------------------------------------------------------------
P1 P2 P3 TIME_SINCE_LAST_WAIT_MICRO
---------- ---------- ---------- --------------------------
122 SQL*Net message to client
1111838976 1 0 29

122 SQL*Net message from client
1111838976 1 0 108

122 db file sequential read
1 87988 1 170

122 db file sequential read
1 87985 1 51

待機イベントが、db file sequential read (ランダムアクセス)に変化しました! ブロックのアドレスも87988となっていて、きちんと載っていないブロックだけを読み込んでいます。

●まとめ

いかにOracleがキャッシュを有効活用(重要視)しているかという証拠だと思います。実行計画だけで実I/Oが決まるわけではない(キャッシュの状態に依存する)ことがお分かりいただけたかと思います。

●その他

SQL Developerのデータモデリング機能(Early Access版)が更新されました。興味のある方はこのURLへ。Oracle SQL Developer Data Modeling 。SQL Developerのデータモデリング機能の記事はこちら。Oracle SQL Developer Data Modelingのblog記事

スポンサーサイト
[ 2008/12/10 23:37 ] DBA | TB(0) | CM(8)
はじめまして、矢木と申します。
興味深い検証結果、ありがとうございます。

一点だけ教えて欲しいことがあります。
検証されたバージョンと、
表領域がASSMかfree listかを教えてください。

気になったのは、
☆キャッシュにほとんどのブロックが載っているケース
のケースで、ASSMでの検証だと仮定した場合の、
bitmapブロックの扱いです。

select /*+ index(test,test_index) */ * from test where no = 1;
select /*+ index(test,test_index) */ * from test where no = 128;
select /*+ index(test,test_index) */ * from test where no = 255;

の時点で、bitmap blockもbuffer cacheの上の載ったのか、
あるいは載っていないとしたら、
bitmap blockごとdb file scattered readで
読むような気がしたので、
ちょっと確認したかったのです。

※すいません、私自身が検証したわけではないので、
 想像で書いてます。

よろしくお願いします。
[ 2008/12/21 22:17 ] [ 編集 ]
コメントありがとうございます。
回答します。

念のため見てみましたが、領域管理はMANUALでした。つまりASSMではありません。

ぜひ、お手元のマシンで試していただければと思います。なお、待機イベントでscattered readの前の、

db file sequential read
1 87985 1 79

というのが、表のもつ管理ブロックのはずです。管理ブロックは表と同時には読まないんですね。
オラクルの仕組み上、ASSMの部分は表と同時のscatteredはしないと思いますよ。もちろん、断定には検証が要りますが。
[ 2008/12/22 08:11 ] [ 編集 ]
回答ありがとうございました。

たしかに、仕組み上
insert/deleteの場合、ASSMのbitmap block
は、表と同時にscattered readしないと思いますが、
selectの場合は、疑問が残ります。

と申しますのも。。。

OTN上の私の記事で、global cache関連の
動きを確認した記載があるのですが、

http://www.oracle.com/technology/global/jp/pub/jp/articles/yagi_cache_fusion.html
 (こちらはfree list管理での確認となります。)

read - read のcache fusionの場合、segment header をgc current block 2-way で飛ばした後に、data blockをgc current block 2-way で飛ばしているんですが、
ASSMの場合は、segment header を gc current block 2-way で飛ばした後に、ASSMのbit map blockごと gc cr multiblock request で飛ばした(ように確認された) のです。
 (記事の中には掲載していません。)

なので、ASSMのbitmap blockのreadのやり方について
確認させて頂いたのですが、
折を見て、確認してみようと思います。
ありがとうございました。
[ 2008/12/22 22:55 ] [ 編集 ]
矢木さん

そうでしたか。
興味をもち、(過去に)調べていただいた上で、コメントいただいていたんですね。ありがとうございます。

脱線しますが、上記OTNの矢木さんのRACのアーキテクチャの記事はとても良いと思います。まだ読んでいない方はぜひどうぞ!

さて、まず答えを言うと、select(データの読み取りのみ)ではASSMのブロックは読みません。

ASSMは、矢木さんはご存じのように、空き領域管理のための仕組みです。ビットマップブロックは空き領域の管理をしているため、実は、今回のようなselectでは必要とされないのです。

以下、ASSMでの実行例です。

create table test (no number, text varchar2(100)) tablespace users;
create index test_index on test (no);

insert into test values(1,'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');

insert into test select no+1, text from test;
insert into test select no+2, text from test;
insert into test select no+4, text from test;
insert into test select no+8, text from test;
insert into test select no+16, text from test;
insert into test select no+32, text from test;
insert into test select no+64, text from test;
insert into test select no+128, text from test;

select DBMS_ROWID.ROWID_RELATIVE_FNO (rowid),
DBMS_ROWID.ROWID_BLOCK_NUMBER (rowid),
DBMS_ROWID.ROWID_ROW_NUMBER (rowid)
from test where no = 1;

select DBMS_ROWID.ROWID_RELATIVE_FNO (rowid),
DBMS_ROWID.ROWID_BLOCK_NUMBER (rowid),
DBMS_ROWID.ROWID_ROW_NUMBER (rowid)
from test where no = 256;

SQL> select DBMS_ROWID.ROWID_RELATIVE_FNO (rowid),
2 DBMS_ROWID.ROWID_BLOCK_NUMBER (rowid),
3 DBMS_ROWID.ROWID_ROW_NUMBER (rowid)
4 from test where no = 1;

DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------------ ------------------------------------
DBMS_ROWID.ROWID_ROW_NUMBER(ROWID)
----------------------------------
4 396
0


SQL>
SQL> select DBMS_ROWID.ROWID_RELATIVE_FNO (rowid),
2 DBMS_ROWID.ROWID_BLOCK_NUMBER (rowid),
3 DBMS_ROWID.ROWID_ROW_NUMBER (rowid)
4 from test where no = 256;

DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------------ ------------------------------------
DBMS_ROWID.ROWID_ROW_NUMBER(ROWID)
----------------------------------
4 400
57


SQL> exec dbms_stats.gather_table_stats('SYSTEM','TEST');

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

SQL> select /*+ full */ count(*) from test;

COUNT(*)
----------
256

SQL> alter system flush buffer_cache;

システムが変更されました。

SQL> select sid, event, p1,p2,p3, time_since_last_wait_micro from v$session_wait
_history where sid = 138;

SID EVENT
---------- ----------------------------------------------------------------
P1 P2 P3 TIME_SINCE_LAST_WAIT_MICRO
---------- ---------- ---------- --------------------------
138 SQL*Net message to client
1111838976 1 0 41

138 SQL*Net message from client
1111838976 1 0 166

138 db file scattered read
4 396 5 184


SID EVENT
---------- ----------------------------------------------------------------
P1 P2 P3 TIME_SINCE_LAST_WAIT_MICRO
---------- ---------- ---------- --------------------------
138 db file sequential read
4 395 1 72

138 SQL*Net message to client
1111838976 1 0 348

138 SQL*Net message from client
1111838976 1 0 8


SQL> select header_file, header_block
2 from dba_segments
3 where segment_name = 'TEST';

HEADER_FILE HEADER_BLOCK
----------- ------------
4 395

dba_segmentsの情報の通り、ブロック番号395がセグメントヘッダです。396から実際の行データが入っています。ASSMの実験でも、セグメントヘッダ(395)のみランダム読み込みして、その後、396からはシーケンシャル読み込みしています。
ビットマップブロックの在り処ですが、395でも396から始まる数ブロックの中にもありません。これは公開されていない情報かもしれないため、場所の記述は省略させていただきます。

矢木さんのテスト結果については、見てみないと何とも言えないです。基本的には、RACのキャッシュフュージョンでもシーケンシャルアクセスのような「まとめ転送」があることは事実なんですが・・・・場所の誤解があるようにも思えます。

矢木さん、また何かありましたらコメントください♪
[ 2008/12/23 21:55 ] [ 編集 ]
小田さん、

こんにちわ、ご返信&ご回答頂き、ありがとうございました。
頂いた内容について、理解しました。

まず、私の認識違いでした 笑
私のほうでも、ちゃんと確認してみました。

●ASSM と Freelistの表領域で、テーブルを作成し、1rowだけinsertしてみて、select * from <テーブル名>で、バッファキャッシュに載せる。
 ⇒ v$bhから確認。

▼ASSM上の表 'employee_a'

select o.object_name, b.status , file# , block#
from v$bh b , dba_objects o
where o.data_object_id = b.objd
and o.object_name = 'EMPLOYEE_A'
and b.status != 'free'
and b.class# = 1;

OBJECT_NAME STATU FILE# BLOCK#
------------------------------ ----- ---------- ----------
EMPLOYEE_A xcur 10 13
EMPLOYEE_A xcur 10 15
EMPLOYEE_A xcur 10 12
EMPLOYEE_A xcur 10 14
EMPLOYEE_A xcur 10 16



▼Freelist上の表 'employee_m'
select o.object_name, b.status , file# , block#
from v$bh b , dba_objects o
where o.data_object_id = b.objd
and o.object_name = 'EMPLOYEE_M'
and b.status != 'free'
and b.class# = 1;

OBJECT_NAME STATU FILE# BLOCK#
------------------------------ ----- ---------- ----------
EMPLOYEE_M xcur 11 10



●勘違いポイント、
ここで、以前に確認したときASSMのほうのv$bhの確認結果を見て、bitmap block(BMB)の場所を勘違いして、blcok#12 , 13あたりだと思ってしまったのです。
間違って、後ろを見てしまったということですね。。。
ちゃんと、ブロックダンプを取って確認すればよかったんですが。


っで、今日、ASSM segmentのsegment headerのblock dumpとってみて、そこからBMBの在り処を見て、各BMBのブロックダンプとって、
ようやく理解しました。

また、ASSM表上のバッファキャッシュの乗りかたと、Freelist表上のバッファキャッシュの乗りかたの違いについても、
segment header と BMBのblock dumpから、なんとなく違いは理解しました。

※詳細は、あまり載せるとよくない気がするので割愛します。。。


ありがとうございました。勉強になりました。
今後ともよろしくです。


あーー、楽しいーーー♪♪♪♪♪
[ 2008/12/25 06:36 ] [ 編集 ]
自己レスですが、一点とてつもない勘違いを
していたことに、いまさら気がつきました。。。

そもそも、V$BHを取得していたSQL文

select o.object_name, b.status , file# , block#
from v$bh b , dba_objects o
where o.data_object_id = b.objd
and o.object_name = 'EMPLOYEE'
and b.status != 'free'
and b.class# = 1;

の、「b.class# = 1」となっている時点で、
BMBのブロック情報が取れるわけないですよね。。。

あーーー、とんだ勘違い!! (・_・;;)


[ 2008/12/25 06:49 ] [ 編集 ]
自己レスの自己レスになりますが、、、、

勘違いが解消されたおかげで、
その後、再度いろいろと確認をしてみたところ、
insert/delete/update時のブロックの動きについても、
勘違いが解消されました!!!

たいへんありがとうございました、
名探偵コナンで言うところの、謎は全て解けた です。

まぁ、全てが解けたわけではないんですがね。。。
まだまだ、謎だらけ (・_・;;)
だからこそ楽しいんですがね♪
[ 2008/12/25 07:09 ] [ 編集 ]
矢木さん

コメントありがとうございます。
多少はお役に立てたようで幸いです。

楽しそうに検証しているのが見えるようです。
これからも検証結果を教えてもらえると
うれしいです。

「検証生活」というのをやっていた知人が
いますが、楽しく検証して、
実力が身についていましたね。

ではでは!
[ 2008/12/25 17:28 ] [ 編集 ]
コメントの投稿













管理者にだけ表示を許可する
プロフィール

odakeiji

Author:odakeiji
小田圭二 日本オラクルのテクノロジーソリューションコンサルティング統括本部においてデータベースのコンサルタントをしている。今までのキャリアでは、社内教育部隊で、データベースやOS、ネットワークを教える経験を5年ほど積んだり、コンサル部門で主にDB(インフラ含む)のコンサルを10年程度経験した。また、コンサルタントとして、主に大規模ミッションクリティカルシステムを担当。社内では”火消し”とも呼ばれ、システムトラブルの火消しをいくつも担当していたこともある。
ポリシーは、「OracleもOS上で動くアプリケーションにすぎない。だから、OS、ストレージ、ネットワークを学ぶべき。アーキテクチャから考えろ」。
スキル面の興味は、アーキテクチャ、DBA、インフラ技術、教育、コンサル手法など。
本ブログのポリシーは「週に1回、DBAやインフラ担当者の役に立つ記事を書きたい」です(守れるだけ、守りたい・・・・)
なお、本ブログにおいて示されている見解は、私自身の見解であって、オラクルの見解を必ずしも反映したものではありません。ご了承ください。

私の主な著書の紹介です。もしよかったら、お役立てください。他にもオライリーなどがあります

●「絵で見てわかるOS/ストレージ/ネットワーク データベースはこう使っている」小田圭二 著
私のポリシーである”DBMSもOSの動くアプリケーションに過ぎない”に基づいて、OSとDBMSの関係、ストレージとDBMSの関係、ネットワークとDBMSの関係、を解説した珍しい書籍です。DBを学んでひと段落したら、DB使いもインフラ全体を意識しなければなりませんが、そのような人にお勧めです。企業ユーザー向けのIT本としては、2008年度翔泳社No1だとか(最後は出版社談)。

●「絵で見てわかるOracleの仕組み」 小田圭二 著
教育に携わる者としての私の思い「丸暗記するな。アーキテクチャを知るべき。絵で説明すべき」を具体化した、Oracleの入門書です。Oracle初心者向きですが、Oracleの基礎となる部分の動きを解説しているため、バージョンに依存せずに何年先でも使えます。逆に、本書の内容を理解せずに、ひたすら丸暗記すると応用力が身につきません。この本を読むだけで何かできるようになるわけではありませんが、アーキテクチャを身につけて、本当の技術力を身につける第一歩として欲しいと思っています。

●「44のアンチパターンに学ぶDBシステム」 小田圭二 著
本書は、企業のDBシステムの設計/構築から運用管理、プロジェクト管理までの各フェーズにおけるトラブル(失敗)事例について、アンチパターン(べからず集)とその回避策/防止策として解説するものです。チェックリストとして使っていただいても構いません。分かっていてもアンチパターンは避けられないことも多いものです(政治とか)。そういう方には、同じ仲間は多いのだなと再認識していただくための一服の清涼剤としていただければと思います。

●「門外不出のOracle現場ワザ」 小田圭二 他 著
一番最初に出た本です。結構とがった内容を扱っています。
・パフォーマンス分析の考え方(私の担当)
・性能テストや障害テストの仕方、設計の注意点(主に私が執筆)
・コストベースオプティマイザ(10gベース)のアーキテクチャ
・コネクションプーリング
最新のOracleの内容は含んでいませんが、今でも性能の考え方やオプティマイザの考え方は使えるはずです。オプティマイザをここまで解説している本を私は知りません。

●「続・門外不出のOracle現場ワザ」 小田圭二 他 著
「続」の名前の通り、次に出た本です。ちょっと尖り過ぎたかもしれません^^; でも本当に使う内容を選んだつもりです。一流になりたい・他の人と差をつけたい人にお勧めでしょうか。
・性能の良いSQLの書き方
・文字化けの仕組み
・障害(特に性能やハング)の分析・対応方法(私が執筆)
・障害をリアルタイムに分析・対処する方法(私が執筆)
・オプティマイザの使い方ノウハウ
・アップグレードのノウハウ

●「データベース」小田圭二 他 著
私にしては堅い本です。なんせ、共同執筆者が大御所の國友義久先生です。階層型DBMS、ネットワーク型DBMS、リレーショナル型DBMS、XMLDBMS、OO(オブジェクト指向)DBMS、DBMSの持つ機能、DBMSのセキュリティ、データベースの著作権、監査、モデリング、正規化といった内容を網羅しており、深い記述は無いものの、DB技術全体を抑えるのに向いている一冊です。ある程度技術力がついたエンジニアの方が、DB全体を振り返りたい(勉強したい)というときの最初の1冊としてお勧めです。



上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。