データベースコンサルタントのノウハウちょい見せ

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

ホーム > アーカイブ - 2009年08月

Oracle製品の実力を伸ばすのに最適なKROWN

このブログを読んでいる知り合いの方(矢木さんではなく、八木さん)に、いただいたネタです。このネタを書くのを忘れているとは「灯台もと暗し」です。

Oracle製品のサポート契約している現場の方にほぼ限られますが、オラクルのサポート部隊がKROWNという名前でナレッジを公開してくれています。これはとっても有難いものです。

ポイント
・用語を理解できる
・情報がまとまっている
・情報がエキスパートによって精査されている(お客様からも突っ込み入るし)
・検索できるので、関連ナレッジを探し出せる
・KROWNで知識を付けると、サポート問い合わせが不要になったり、スムーズに行く

■どう使うか
分からないことがでてきた -> KROWN検索
今度、新機能使う -> KROWN検索
おかしな動きのようだ -> KROWN検索
調べものしよう -> KROWN検索

こんな感じで、何はともあれ、いつでもKROWNを検索しましょう。読んでいれば自然と実力がつきます。私の知っているDB部隊でも、KROWNを活用して勉強しています。KROWNを利用できる立場に居る人はどんどん活用しましょう!

■小ネタ
KROWNって、Knowledge Repository OWNershipの略です。
CROWNの綴り間違いではありません ^^

■最後に
今の若い人は、KROWNがなかった時代なんて想像できないでしょうね。情報が公開されていることって素敵です。会社によっては、こんな公開情報、いまでも無いですから。普段は表に出てこない、サポートの人たちに感謝感謝です。

スポンサーサイト
[ 2009/08/30 23:33 ] スキル強化・教育 | TB(0) | CM(4)

問題の分析や確立されていない物事の分析

今回はコンサルのノウハウの紹介です。

矢木さんからコメントいただいた、「確立されていない物事を,あるいは問題の分析をする 力をつけるにはどうしたらいいかなー」に、できるだけ回答してみたいと思います。元先生のお勧めですが、万人共通とは言い難いので、参考程度にお考えください。

基本は、該当ブログの「現実から理論へ」の矢印がベースとなります。つまり現実の複雑さの中から、どう本質やアーキテクチャや理論を見つけ出すか・・・です。

私の周りで見ていても、できるコンサルほど、世の中の理論(セオリー)どおりにやりません。良い子(教科書通り)ではないのです。では、彼(彼女)らはどうしているのかというと、理論の底辺に流れている本質を理解していて、自分の中で、今回のケースではこうすべきと再構築をしている(らしい)のです。

●本質を見つけるには?

「自分で考える」、特に想像することは大事です。最高なのは、頭の中で、図をぐりぐり動かせることだと思います。物理の世界では「思考実験」と呼んだりもするそうですが、頭の中で実験するのは、本質把握や理論を作る良い練習になります。想像した内容が外れても良く、それを確認して、次回以降の予想の精度が上がればOKです。

「思考実験」ではなく、ホワイトボードやパワーポイントなどに図で書くのもお勧めです。図で書けるということは、アーキテクチャや動作を理解しているということでもあります。書いている途中で、「あれ? ここどうなんだっけ?」と気がつくことがありますが、それは理解していなかったということです。

100文字以内(何文字でもいいんですけど)で、”要約する”という練習もお勧めです。本質以外を切り捨てる練習になるからです。IT業界の人は、どうしても正確に伝えたいと思い、詳細を捨てきれない人が多いです。でも、理解してもらうことを優先するには、本質以外を切り捨てる説明方法も大事です。その練習をしていると、本質を把握する練習ともなります。先生をしていると嫌でも学ぶスキルです。

コピーライターの方に、「コピーライティングはどう練習すればよいですか?」と聞いた答えですが、あるモノの”他との違い”や”売り”をひたすら書き出すそうです。たとえば、あるもの(例:あるバッグとかある傘とか)。1つについて50本、100本書き出す。そしてその共通の軸を探すそうです。書き出したもの1つ1つは扇の先端に相当すると考え、その共通の軸を探すと扇の”要”がわかる。それがそのモノの本質だそうです。

コンサルタントがビジネスやプロジェクトの分析をする場合、会社を動かしている、もしくはプロジェクトでもっとも大事なこと1つを挙げるということをします。たくさん挙げれば良いと思いがちですが、そうではなく、本質は1つ(もしくは少数)挙げるのがポイントです(例外もありますが)。

文章を書くのもお勧めです。大学入試の小論文やブログなどが例です。


●現場から見つける

そもそも光る原石を発見しなければならない、というケースもあります。たとえば、マーケティングです。ある有名なマーケッターから教えてもらったのですが、現場での成功例を見つけ出し、それを横展開するのだそうです。やっぱり現場を見て、「これは!」というものを掘り起こすのだそうです。

現場での問題点の探し方は、どうすると思いますか? ヒアリングでしょうか? インタビューでしょうか? 確かにそれらも必要なことだと思います。でも、現場を知っているのは、現場の人が一番なわけで、われわれコンサルタントはあくまで第三者です。お勧めは、用意した質問に答えてもらうのではなく、率直に現場のキーマン何人かで議論してもらうことです。そこで現場の諸々の課題から、本質を抜き出すことです。それが本来のモデリング(の1つ)なんだと思います。

現場の人にヒアリングする場合、もしくは観察して問題点を見つける場合には、ギャップやコンフリクトを見つけることがお勧めです。コンサルはギャップを見つけて、効率よく解消するのが仕事だと思います(費用対効果が大きいです)。

現場へのヒアリングやアンケートについては、裏取りは必須です。これは嘘を言っているというわけではなく、同じ事実に対して、違うレッテルを貼っているケースが多いためです。特に違う立場の人、役職が違う人に聞くのが有効です。こうやって多面的にとらえると、間違った答えを避けやすくなります。

なお、率直に「本質は?」とユーザーに聞くのであれば、ヒアリングの最後がお勧めです。理由は、いろいろとヒアリングした結果、ヒアリング対象者の頭の中に、多数の課題が浮かんでいる状態になっていて(いい感じに「ごった煮」になっていて)、本質をひらめきやすい状態になっているのが、ヒアリングの最後だからです。

ミーティングやヒアリングの最後に、「何か私が聞き忘れたこと、もしくは言いたいことはありませんか?」と聞くのもお勧めです。この最後の機会における”自由発言”が本質を示していることが多いためです。


●有名なITコンサルタントはどうやっている?

有名なITコンサルタントである、ワインバーグの著作「コンサルタントの秘密」では、「そこにないものを見る法」として、次のものたちが紹介されています。P83-P93です。
・類似性を探す
・極限値に変えてみる
・境界線のそとに目を向ける
・説明の顔をしたアリバイに注目
・不調和の洞察
・異文化を調べる
・洗濯物リスト(要はチェックリスト)を使う
・ほかの人を利用する(「私は何を見落としているのでしょうか」と質問する)

”考える”が苦手な方には、「スーパーエンジニアへの道」や上記「コンサルタントの秘密」の前半を読んでみることをお勧めします。私の経験ですが、この本達を読んだあとは、しばらくの間、いろいろと考えるようになるからです。そこがこの本達の凄いところです。


五月雨のように本質の見つけ方を羅列しましたが、この中のどれか1つでも参考になればと思います。
#「五月雨でなく、1つに絞れ」と言わないでくださいね。今回は道具(引き出し)の紹介ですから^^
[ 2009/08/26 23:39 ] コンサル手法 | TB(0) | CM(2)

OSで実験しよう その1

インフラのブラックボックス化が進んで中が見えにくくなっています。そこで、今後何回かに分けて、「OSで実験しよう」シリーズを書いてみたいと思います。

「まずはメモリが足りなくなったらどうなるの?」です。

自分で自由になるマシン環境をお持ちでしたら、いくつものDBMSインスタンスをほぼ同時に立ちあげて、OSを一時的なメモリ不足にしてみてください。そのとき、OSコマンド(なんでも良いです)は即座に動きましたか? または長く時間がかかるSQLを実行したとして、普段と比べてどれくらい時間がかかりましたか? UNIX系のOSの場合、vmstatなどのデータはどうだったでしょうか?

SQLやコマンドがすぐには動かない・時間がかかるという経験はできたでしょうか? 簡単に実験できない人が多いと思うので、昔、私がLinuxで実験したときのデータ(vmstat)を載せます。 blogだと列が崩れて分かりにくいので、テキストエディタにコピペして見てみてください。


procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 90356 21092 1360 193388 0 0 198 193 1818 978 13 3 48 36
0 0 90356 21028 1368 193380 0 0 213 104 1827 993 12 5 44 39
0 4 90356 20900 1376 193372 0 0 222 161 1889 1048 15 4 41 40
0 0 90348 20772 1384 193632 0 0 206 150 1806 947 12 4 42 42
0 1 90344 20644 1392 193628 0 0 163 114 1804 966 12 4 56 27
0 0 90340 20452 1400 193624 0 0 168 123 1768 952 12 3 54 30
0 0 90340 20388 1408 193616 0 0 166 125 1739 903 10 4 53 33
0 0 90340 20132 1416 193608 0 0 154 159 1830 995 13 4 55 28
1 0 90336 20004 1424 193604 0 0 154 132 1731 891 12 3 58 27 <- ここら辺からメモリ不足になるよう操作した。
0 1 90332 19748 1432 193568 6 0 188 124 1780 941 12 3 50 34
0 3 90320 16476 1536 196748 22 0 798 134 1954 1068 13 8 11 69
1 4 111964 13452 1088 201428 23 5031 779 5144 2042 1302 15 9 0 76
0 14 139192 13284 320 205976 33 5289 434 5367 1892 985 12 10 0 78
0 15 155228 13348 352 211760 290 3946 546 3998 1564 681 7 6 0 87
0 18 189584 14548 236 210652 124 5636 302 5658 1251 322 1 6 0 93
0 25 188956 14684 368 213464 202 0 798 34 1712 852 7 3 0 90
0 17 198232 14300 564 217184 222 1697 1458 1709 1362 527 2 2 0 96
0 17 198168 14228 716 219904 179 0 768 74 1302 522 2 2 0 96
1 25 197964 14036 988 223296 128 0 834 51 1313 452 1 1 0 98
0 14 197812 14620 1228 230980 108 0 1627 68 1215 336 1 1 0 98
1 13 199528 15508 1388 237492 51 117 1751 170 1292 363 1 3 0 96
0 7 199472 14652 1612 241352 244 17 1038 92 1233 415 2 1 0 97
0 15 213588 13332 1804 233116 442 1074 813 1205 1380 529 5 3 0 93
0 18 218976 13588 1836 233592 299 1714 865 1781 1538 685 7 3 0 91
0 19 218260 14092 1728 233812 294 946 1186 1032 1695 844 11 3 0 86
0 28 217368 14220 1696 232480 401 229 1282 293 1559 725 8 3 0 89
0 31 216564 13516 1656 233900 314 1210 1261 1232 1285 441 4 2 0 94
1 32 216004 13844 1656 235404 301 1304 820 1489 1513 643 9 2 0 88

b列が大幅に増え、swapへのI/Oが増え、freeが減る傾向にあり、wa(wait I/O)が増え、CPU使用率が減っていることが分かります。b列が多い場合、I/Oなどでブロックされているプロセスが多いという意味で、トラブルを切り分ける際の参考となる情報です。swapへのI/Oが増えているのは、メモリ不足(swapへページアウト・ページインしている)からです。waは、大雑把に言うと「CPUがI/O待ちのためidleしている」ことを示すので、ページングによるI/Oが多いということを間接的に示しています。同じ負荷をかけていながら、CPU使用率が減っていることから、DBMSが処理できていないことを示しています。実は、この処理できていない理由がOSのメモリ不足(過度のページング)です。 

OSはミドルウェアやアプリケーションが動くための土台です。そのため、OSが何らかのひっ迫状況になると、本来は無関係のミドルウェアやアプリケーションまで遅くなってしまうのです。これを知らないと、「このミドルウェアが遅かったから、このミドルウェアのせいに違いない」と考えてしまいます。

 

まず第一回は、土台としてのOSの重要性と、過度のページングの怖さ、ページング時のデータ解析のポイントを知っていただければと思います。

[ 2009/08/23 23:45 ] DBA | TB(0) | CM(0)

研修や学習を仕事に生かす方法と、その練習について

研修や学習って、なかなか身につかないですよね。また、身についたノウハウを効率的に伝えることって難しいですよね。

多くの人は次の図のようになっていると私は思っています。

学習と実践の図1

残念ながら、研修や本で読んだことを、知識は知識としてそのままにしていると思います。研修で学んだことや本で読んだことをどれくらい実践したことがありますか? ほとんどの人は使っていませんよね? 日々の仕事は改善されず、せっかくおぼえた知識も忘れられていきます。

では、どうあるべきなのでしょうか。私は次のように考えています。

学習と実践の図2

知識の世界と実践の世界をぐるぐると回るイメージです。これは私が人事で先生をしていたことも影響しています。どう教えて現場で生かしてもらうか、どう研修の内容を作るか常に頭を働かせていたからです。

次に練習方法です。アウトプットを出す練習がお勧めです。その際、期限を設けるのを忘れないでください。これを繰り返せば、アウトプットに活かせるようになります。それと、先生をやりましょう。特に、すでにあるテキストを使わずに自分で内容をとりまとめて発表するのがお勧めです。その際、ものすごく頭を使うと思います。これが本質をつかむ練習となります。

学習と実践の図3

この理論の世界(教育の世界)と、実践の世界(いわゆる現場)をいったりきたり、知識をぐるぐる回せるのが、私の持つ最大のスキルだと思っています(コアスキルですね)。人事の先生になって得られた、仕事が与えてくれたギフトですね。感謝しています。

ITエンジニアは、高度なスキルが求められますし、学習や研修も多いと思います。このような”生かし方”を練習して、自分の身につけるようにしてみてはいかがでしょうか?

何百人ものエンジニアを育てた、先生からのお勧めでした。
[ 2009/08/19 23:10 ] スキル強化・教育 | TB(0) | CM(3)

異常系テストのススメ

今回は、軽視されがちな異常系のテストについてその重要性を説明します。理由は、障害が絶えないなあと思うからです。

●例

正常系のテストでは問題なく、性能を達成したけれども、あるコンポーネントが障害(H/W障害)になった途端、それをきっかけとしてOracleが大障害になることがあります。このように正常系のテストだけでは、いざというときの振る舞いまでは判らないものです。特に漏れていると思うのが、きれいに故障してくれないケースです。中途半端に動くような故障はやっかいですよね

●内容

性能試験(スループット要件の確認)、リカバリテストは多くのミッションクリティカルシステムで実施していると思います。

加えて、以下のテストをやるべきと考えます(理想論です)。
・1 どこかで処理がつまったときにエラーが出ないか、回復できるかテスト
・2 限界を超えたときにスループットが劣化しないかテスト
・3 処理がつまったときに高速に切り替えできるかテスト


理由の1つは、コネクションプーリングや、都度接続などでは、同時アクティブセッション(使用中のセッションという意味です)数が多くなってはじめて、露呈するリソース不足があるためです。

また、もう1つの理由として、同時アクティブセッションが増えて初めて処理が重くなるケースもあるからです(参照:渋滞とコンピュータシステムのBlog記事)。限界を超えた場合に、急激に性能が劣化するのは避けるべきですが同時アクティブ数が多いと、処理が重くなり、いつまで経っても処理がはけなくなる危険性があります。

●テスト方法(案)

「・1」は、LGWRやDBWRなどをKILL -STOPなどで止めてテスト
する方法があります。
「・2」は限界を超えるような負荷をかけることによって
テストできます。
「・3」は「・2」の状況下で、切り替えテストを行うことで
テストできます。

皆さんのシステムは、「異常な状態になっても大丈夫」と言い切れますか? タイミングを見て、異常系のテストもやりましょうね!
[ 2009/08/16 23:49 ] DBA | TB(0) | CM(0)

大和総研 情報技術研究所の方々と意見交換会をしました

大和総研の情報技術研究所(IT系の調査・研究・支援を目的とする組織)とデータグリッドなどをテーマに意見交換会(座談会のようなもの)をさせていただきました。

細かい内容はここでは書けませんが、金融システムへの適用のメリット、一般にインメモリDBMSがCPU負荷が低い傾向であることや、アーキテクチャ的にレスポンスのばらつきが少ないことなどをディスカッションしました。

研究所の方とベンダーコンサルが意見交換するのも価値があるものだと思いました。議論したい・リアルな意見を聞いてみたい方は、連絡いただければと思います。

情報技術研究所紹介:
http://www.dir.co.jp/souken/itrd/
ITに関するコラム アイティータイム(週1回程度のようです)なども読めます。
http://www.dir.co.jp/souken/itrd/it_time/
※プライベートクラウドなど、このブログとも近い記事が多く載っています。興味のある方はどうぞ。

当日の写真です。うちの会社のお茶室での写真です。

情報技術研究所の皆様との写真

お茶室内の一コマ
[ 2009/08/12 23:07 ] 雑談 | TB(0) | CM(2)

swingbenchって便利ですよ

Oracle DBに負荷をかけたい、もしくはDBにアクセスするような疑似アプリが欲しいこともあるでしょう。そんなときは、swingbenchです。Javaで動く上、テーブルの作成から、データの作成、負荷掛けから、スループットの監視表示までやってくれます。

Swingbench入門<Windows版 Ver2.2のもの>

●セットアップ
・http://www.dominicgiles.com/ にアクセス
・download に移動
・できるだけ最新のswingbenchをダウンロードする(ただしベータはお勧めしない)
・Cドライブかどこかに入れる(海外のソフトなので、パスに空白とか日本語がないところがお勧め)
・swingbenchenv.bat の中を書き換える。例えばつぎのようになる
set ORACLE_HOME=D:\oracle\product\10.2.0\db_1
set JAVAHOME=C:\Program Files\Java\j2re1.4.2_10
set SWINGHOME=C:\swingbench\swingbench
set ANTHOME=C:\swingbench\swingbench\lib
set CLASSPATH=%JAVAHOME%\lib\rt.jar;%ORACLE_HOME%\jdbc\lib\ojdbc14.jar;%SWINGHOME%\lib\mytransactions.jar;%SWINGHOME%\lib\swingbench.jar;

・swingbenchの2.2版では、次のSQLスクリプトにパーティションオプションの指定がある。
 パーティションオプションが入っていない場合、"partition"で検索して、partition句を削除すること。
  soecreatetables.sql ・・・5箇所ほどpartition句がある
 パーティションオプションが入っていない場合、"local"で検索して、localという単語を削除すること。
  soeconstraints.sql ・・・4箇所ほどlocalという単語がある

・コマンドプロンプトを開いてswingbenchの下まで移動する
・winbinの下のoewizard.batを実行する
・「データベースの詳細情報」において接続情報は適宜書き換えて、DBに接続する
 tnsnames.oraを作っていない場合には、THINドライバを選んで次のように指定することもできる
  192.168.0.2:1521:XE
・スキーマの詳細情報では、表領域名とデータファイル名を必要に応じて書き換える
 UNIX上のXEに作る場合の例 /usr/lib/oracle/xe/oradata/XE/soe.dbf
・データサイズを選ぶ。
・あとは「実行」ボタンを押して待つだけ

●負荷掛けの実行
・winbinフォルダから、コマンドプロンプトでswingbenchを実行する。
・DBがXE(eXpress Edition)の場合は、接続ユーザー数を減らすこと。これはリソース制限に引っかかるため。
・接続情報は適宜書き換えて、実行ボタン(再生ボタン)を押す
・停止は、停止ボタンを押すだけ

●その他
負荷掛けツールを手軽に作りたい時にもSwingbenchは使えます。自作できるよう、フレームワークのようにほとんどの機能を用意しているため、業務SQL周りのところだけ自分でコーディングすれば動かすことができますよ!

[ 2009/08/09 23:55 ] 未分類 | TB(0) | CM(0)

ITのリーダーシップの3つのタイプ(人のタイプ)

今回はITコンサルの神様? ワインバーグネタです。ITの(変化を導く)リーダーシップに関するMOIモデル(注)について紹介します。たまには、自分がどのタイプかと考えて、どうリーダーシップを発揮するのか、どうスキルアップするのか考えてみてはいかがでしょうか?

注:MOIモデルは「スーパーエンジニアへの道」に載っています。

Mは動機付け(Motivation)
Oは組織化(Organization)
Iはアイデア(Idea)


簡単に言うと、他人のモチベーションをあげる形で、リーダーシップを発揮するリーダー(M方式)もいるし、きちんと組織を作って運営する形でリーダーシップを発揮するリーダー(O方式)もいるし、革新的なアイデアで技術革新のリーダーシップを発揮するリーダー(I方式)もいるということです。

多くのテッキーなエンジニアは、I方式(I型リーダー)です。I方式でも、本を書いたり、スーパープログラマーとして活躍することはできると思います。でも、OやMの要素がないと、他人のモチベーションアップや組織化ができず、限界があるわけです。M方式の人が周りにいるといいですよね。楽しくなるし、何より皆がいきいきします。O方式も欠かせません。特にプロジェクトでは、組織化や仕組み作りは必須ですよね。

I方式の人が、MやOの要素を強くするには、いったんI方式のやりかたを捨てたり、I方式での仕事のやり方を弱めたりすることがお勧めです。I方式の人ってオーラが出ていて(例:この人は技術的に知らないことはない)、周りの人に対してMやOの要素を働かせにくいと私は思うのです。できるエンジニアだった人がマネージャーになろうとすると必ずぶつかる壁だと思います。

ITの世界では、まずはI方式のリーダーシップをおぼえる人が多いと思います。そんなI方式なリーダー(特にテッキーな方)は、いったんI方式を捨てる勇気を持つと良いと思うのです。すると、周りがついてきてくれたりしますよ!


[ 2009/08/05 23:52 ] スキル強化・教育 | TB(0) | CM(0)

Oracleで実行されたSQLのバインド変数の値を知る方法

ひさぶさにOracleネタに戻ってきました。

開発やテストをしていると、実行されたSQLのバインド変数の値を知りたいことはありませんか?

例えばアプリケーションを動かした結果、SQLが実行されたけれども、そのSQLに設定されているバインド変数の例を知りたいという場合です。SQL*Plusや開発ツールからSQLを実行したいんだけど、SQLにバインド変数があると、そのままでは実行できません。そのため、実際の値を知りたいと思いませんか?

実は、あまり知られていませんが、SQLトレース以外でバインド変数の例を確認する方法があります。10gR1以降に存在するビュー:v$sql_bind_captureです。

以下、実行例です。

variable a number
execute :a := 1
select * from test where no = :a;

select sql_id from v$sql where sql_text like 'select * from test where no =%';

SQL_ID
-------------
8n76jz52k7p2b


select name,value_STRING from v$sql_bind_capture where sql_id='8n76jz52k7p2b';

NAME
-------------------------------
VALUE_STRING
-------------------------------
:A
1

なお、最後に実行された際のバインド変数の値とは限りません。そのため、あくまでSQLを実行するためのバインド変数の例と捉えてください。それでも開発やテストで便利に使えますよね。

注:初期化パラメータ statistics_level は BASIC 以外にしてくださいね。

[ 2009/08/02 23:50 ] DBA | TB(0) | CM(0)
プロフィール

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冊としてお勧めです。