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

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

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

スポンサーサイト

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

SQL Developerって使ってますか?

Oracle社が提供するフリーの開発ツールである、SQL Developerはお使いでしょうか?
SQLを開発するために、非常によくできたツールです。まだの方はお試しください。

特徴
・インストールが必要無い(私はダウンロードして解凍するのみでした・・・JVMは必要そうですけど)
・SQL入力の補完機能が付いている! SQLの構文や、表名や列名などがプルダウンで選べます! 後述)
・SQLを入力後、それをDBで実行して、SQLを編集するという一連の流れがSQL Developerだけで可能。
・explain planやautotraceも実行可能。だから簡単な性能情報も見ることができる!
・ドラッグ&ドロップでSQLの組み立てがある程度可能です。つまり、楽チンです。
・ど忘れしやすい人でも大丈夫。snippetsというタグ(ウィンドウ?)があり、そこでSQL関数や
 PL/SQL構文やヒントなどの一覧を見ることができます。
・オブジェクトのブラウズや定義変更などもできちゃいます。
・PL/SQLのデバッグが出来る! デバッガ機能があるので、PL/SQLの開発時に重宝します。
・SQL整形機能付き。これで見づらいSQLもきれいに。
・SQL Developer上でデータも見られるし、データ変更もできる。
・データのexport/importができる。

●SQL入力の補完機能

入力補完機能はこんな感じです。

途中まで入力すると、次の単語の候補を出してきます。
補完その1


FROMの後は、表名も選べます。
補完その2


where句では、列名も選べます。
補完その3


※試した限り、DDL構文は無理でした。

●参考URLなど

日本語ならここ
http://www.oracle.com/technology/global/jp/products/database/sql_developer/index.html

英語ですけど、これを見ると一通りマスターできます。
http://www.oracle.com/technology/getting-started/sqldev.html

スポンサーサイト
[ 2009/05/31 23:19 ] DBA | TB(0) | CM(0)

SSD上のOracleの性能レポート

OracleをSSDの上で動かしたら、どんな性能特性になるのか?
どんな注意点があるのか? 興味は尽きませんが、「Oracle OpenWorldで見てきた業務用SSD製品まとめ」でも紹介されている、
「報告書がドラフト版ということで詳しい内容は正式版を待ちたい・・・」の
報告書が出てきたようです。

この度、ホワイトペーパーとしてDELLとEMCとOracleの検証結果レポートがでたのを見つけました。http://wp.techtarget.itmedia.co.jp/ (TechTargetジャパンという登録が必要なサイトです)
レポートのタイトル「フラッシュドライブ搭載ストレージの実力をOracle環境で徹底検証する」

2009年7月追記:登録が不要なサイトに同じ(私が見る限り同じ)レポートが載りました。こちらです。
http://www.oracle.co.jp/solutions/grid_center/dell/pdf/GRIDCenter-DELLEMC-SSD_v1.0.pdf

以下、個人的に読み取ったSSD(EMCさんの企業向けハイエンド製品で、EFD:Enterprise Flash Driveと呼ぶそうです)の特性です。以下、私の個人的見解としてお読みください。

●ランダムアクセスで効果が大きい

当然ですが、SSDはディスクヘッドを動かす必要がありません。ということは、ランダムアクセスが物理ディスクよりもとても速くなります。ホワイトペーパーでも「約18倍高速になる可能性」って紹介されています。

●キャッシュヒット率が低くても、性能が低下しづらい

これ、大事だと思います。キャッシュヒット率が低いと、通常はディスクアクセスになり、ストレージの足回りが弱いと性能劣化するものですが、SSDを使っていると、この性能劣化が少ないというグラフが出ています。考えてみれば、Oracleのキャッシュにヒットしなくても、SSDというメモリにヒットする(I/Oする)わけで、この効果は納得できます。

●なんらかのI/Oバスが限界になりやすい

SSDにすることによって、通常ボトルネックとなるハードディスクボトルネックが解消されます。すると、他のボトルネックが出てきます。SSDの場合は、I/Oバスみたいですね。ホワイトペーパーでも、I/Oバスがボトルネックになってしまいました。という「うれしい悲鳴」の記述があります。

●費用対効果

価格は載っていませんが、物理ディスクより高価です。なので、コストも含めてメリットを比較する必要がありますね。今後、劇的に下がるんでしょうけど。


■ホワイトペーパー以外の情報

ホワイトペーパーとは関係ありませんが、以下各所から集めたSSDの特性に関する情報です。

●意外とエコ?

物理ディスクと比べて良い点として、電力消費量も挙げられます。ということは、エコと言えるそうです。最近、データセンターの電力が不足気味なので、良いことだと思います。

●注意点

I/O命令に伴うOSカーネルが使用するCPUコストがバカになりません。意外な盲点ですね。また、外部バス(Bus)がいっぱいになりやすいです。今後は、これらのオーバーヘッドやボトルネックが少ないサーバー構成も望まれるんでしょうね。。。

上記特性があるので、現段階ではまだOracleのバッファキャッシュを極端に少なくして、SSDで完全にバッファキャッシュ代わりとは行かなさそうです。正直、バッファキャッシュを”それなりに”持たせる必要があると思います。

●ストレージのwriteキャッシュほどの高速レスポンスではない(らしい)

大型ストレージでは、writeのレスポンスを改善するため、writeキャッシュ(write目的のキャッシュのこと、read+write兼用のキャッシュのことが多い)を置いているかと思います。実は、writeキャッシュの方がSSDより速いため、SSD+writeキャッシュという構成が組めますし、超高速システムのためのredoログなどには、その方が向いているようです。

●SSDの使いどころ(個人的な考え)

ストレージのwriteキャッシュも使って、プロが思いっきりチューニングすると、ほぼ同性能の性能は出せるはずです(物理ディスク本数を揃えると)。では、現時点のSSDに意味がないかというと、「そこそこのシステムにおけるチューニングレス」という点がありそうです。ホワイトペーパーにも載っているように、多少I/Oが増えたりしても、SSDが吸収してくれる(ボトルネックになりにくい)ですから、初心者にとっては使いやすいと思います。

将来は、マシン構成なども含め、いろんなDBサーバーの選択肢がありえるので、夢は膨らみますけどね。SSDがんばれ!!
[ 2009/05/27 23:16 ] アーキテクチャ | TB(0) | CM(0)

DBマガジンの特集のネタ募集

またしても厚かましく、DBマガジンのネタをブログで募集します。前回に引き続きアンチパターン。しかも、今度はDBシステムのプロジェクトマネジメントです。

ブログコメントにネタや感想を書いていただけると幸いです。なお、既に十分な数があるので、必ずしも採用となるわけではありません。ネタとして概要をいただきますが、肉付けは筆者が行うので、違うテーストになるかもしれません。現在の案は以下の通りです。

■DBシステムとプロマネの問題
気がついたらテストの時間がない(もしくはテストしない)
デスマーチ・・・・人やリソースが足りない。
テストデータが少ない、種類が少ない
性能テストを実施できない
性能のゴールを決めない・・・基準なし
DBのキャパシティマネジメントができていない・・・業務変更、でもDBのキャパは見直ししない。
性能に関するアプローチがない・・・性能がいきあたりばったり
DBが集中砲火を浴びるアーキテクチャ
暴走スポーツカー・・・性能分析できない、タイムスタンプつきのログが取れない
性能問題をDBのみで解決しようとする
はしご外し・・・誰もわからないモジュールやデータを無理に延命する

■人のサガ
タコつぼ現場(データを多重もち)
タコつぼ現場(使用プロダクトがばらばら)
ドキュメント軽視
ドキュメント過剰
過大な可用性要件
火中の栗を拾わない・・・紐解いて、元から直すべきなのに、誰も手を出さない
楽観・・・・新機能を多用する、パッチを当てない
慎重すぎ・・・・安全率に安全率、など
ベンダーいじめ

■組織の問題
DBAのあるべき姿がわからない
DB担当の要員アサインが悪い
DBチームのリーダーの権限が弱い
情報が伝わってこない
新人多すぎ
DBAが育たない・・・そもそも育成が難しい


対象外:上層部が心配をして過剰に介入、過剰に低価格を求められる、見積もりが正しくない、仕様が固まらない、SIerが強すぎる、ユーザーが強すぎる

本内容は、7月25日くらいに発売されるDBマガジンに載る予定です。「上記リストの中で、このネタが一番読みたい」「こんなネタどう?」と気軽にコメントいただければ幸いです。
[ 2009/05/25 02:06 ] 雑談 | TB(0) | CM(12)

Oracle + SSD本の簡単な書評

sh2さんのブログ「Oracle OpenWorldで見てきた業務用SSD製品まとめ」にも載っている、RAM-SANというSSDがあります。

以前、yahondaさんから、ブログコメントで「Oracle RAC & Grid Tuning with Solid State Disk」という洋書があるよ。と聞いていました。この本の中で触れられているのも、RAM-SANのSSDです。遅くなりましたが、この本を読んでみたので概要紹介(書評)です。

序文には次のように書いてあります。
「SSDはOracleのプロフェッショナルにとって重要である。なぜなら、チューニングパラダイムを変えてしまうからだ。OracleのDBAは1990年代は、ディスクI/Oの時間を減らすことを気にしていたが、それが今日ではSSDによって取り除かれつつあるのだ・・・」

P15に「ひどいデザインのOracleデータベースは、直すのに6か月と50万ドルのコンサルティング費用がかかるかもしれない。もし、SSDを救済策として使ったなら、24時間以内に、10倍速く稼働するようになるかもしれない。」と書いていて、チューニングの助けとなることが示唆されています。

途中途中、TPCベンチマークなどのデータを入れてくれています。しかし、SSDの特性を考えると想像できるような結果(「ランダムI/Oに向くよ」など)が多いです。

P171あたりに、まとめとして将来の予想が書かれています。
「現在、DBAはとても多くの時間をディスクI/Oの心配のために費やしているが、ディスクレス環境によってそれらの心配はなくなっていくだろう。仮想化が進めば、CPUの監視の方が大事になっていくはずだよ」と、I/Oに関するバラ色の未来を見せています。

ただ、yahondaさんの指摘のように、appendix BについているAWRレポートは負荷が低すぎます。ちょっと何かの間違いじゃないかと思います。

本全体としては悪くはありませんが、「おっ、これは!」という記述までは見当たりません。仕事でSSD+Oracleを検討したい人は多少参考になるのではないでしょうか。
[ 2009/05/20 23:12 ] アーキテクチャ | TB(0) | CM(2)

ACIDを超える概念か? 新しいトランザクションの考え方 - BASE

DB使いであれば、ACID(Atomicity、Consistency、Isolation、Durability)は当たり前の考えかと思います。実は、DBMSならACIDが当たり前というのは、思いこみと言っても良いのです。少なくとも、ACID以外の考え方が存在するのは事実です。

今回は、そんな考え方である、BASE(Basically Available、Soft state、Eventually consistent)を紹介します。クラウドなどの世界で徐々に広がりつつある、トランザクションの考え方です。

この記事は、「BASE: An Acid Alternative」 を参考にしています。詳細はこちらの論文を見てみてください。前半は本論文の内容の紹介です。

●BASEの紹介

ざっくり言うと、厳密な一貫性やデータの即時反映などをあきらめる代わりに、スケーラビリティを得ることができるよ。という考えです。

ACIDが悲観的で、各オペレーションに厳密な一貫性を強制するのに対して、BASEは楽観的で、不安定なのだそうです。

例として挙げられているのが、userスキーマとtransactionスキーマです。userスキーマが、id,name,amt_sold,amt_boughtの属性を持ち、transactionスキーマが、xid,seller_id,buyer_id、amountの属性を持ちます。userがamt(合計)を持ち、ディテールはtransaction表に持つ・・というDB設計ですね。

通常、ACIDの場合、transaction表とuser表(※合計の変更)の双方を1トランザクションで変更してコミットします。でも、分けてもいいじゃないか、というのがBASEです。transaction表を変更してコミットして、その次にuser表を更新してコミットするわけです。ごく短時間、一貫性が保たれませんが、大した問題はないという考えです。論文の中ではメッセージキューを用いた伝搬の例も載っています。
Soft StateとEventually consistent(最終的に一貫性を実現する)として、反映までのタイムラグの話も載っています。

●トレードオフは何か?

トレードオフは、開発者から見た”使い勝手”です。なにせ、読みこんでみたら、結果が反映されていないかもしれないのですから。このようなシステムでは、更新と参照を分けて(意識して)プログラミングしたり、データの反映が遅くなっている可能性も考えながらプログラミングする必要があります。
ということで、考えてみると、ロック処理を割り切っていることによる、スケーラビリティの実現とも言えます。

●実は古くて新しい考えだったりします。

私が知る範囲でも10年前から、このようなアーキテクチャのシステムは存在していました。ただし、大規模で特殊なシステムで用いられていたので、あまり知られていないかもしれません。

システムのイメージ図(クリックすると拡大)
BASEのシステムの絵

最近だと、新興のネット企業の大規模システムで、このアーキテクチャのシステムが見られます。スケーラビリティを実現するためには、有効なんですよね。

●どういう業務にBASEは向くのか?

実は、エンティティが少なく、トランザクションが多いようなシステム、例としてはチャネル(窓口)系のシステムに向きます。多くのエンティティをもち、多数のSQL、複雑なSQLを駆使するようなシステムでは、開発者の負担が大きすぎて向きません。つまり、従来型のセントラルDBではなく、もっとシンプルなDBMSとBASEは相性が良いのです。BASEは、インメモリDBMSとも相性が良いと思います。従来型のセントラルDBでは、RDBMSがまだまだ主流でしょうね。

●本ブログでも関係する記事があります

記事「クラウドやマルチコアでの将来のボトルネックはきっとロック処理でしょう。コーディングが変わるかもしれません!?」 が近い内容です。

記事の中で、『やはりこれ以上、コンピュータの性能を上げようと思うと、最初に書いた「厳密な調整」の能力に何らかの制限をつけるしかないと思います。・・・<中略>・・・・「別々にいい加減に処理する(最後につじつまあわせをする)」という「曖昧な調整」を行うコーディングがはやるかもしれません』と書いていますが、その1つがBASEなんだと思います。この記事を書いていた当時はBASEのことは知りませんでした(本当です)。

合わせて楽しんでいただければ幸いです。
[ 2009/05/17 03:27 ] アーキテクチャ | TB(0) | CM(0)

インフラベンダーエンジニアがユーザー側に行く際に気をつけること

コンサルティングで現場に行って思うことの1つに、インフラベンダーのエンジニアがユーザー側(例:情シス)に転職した際の落とし穴は、「下手にインフラベンダー時代の夢にこだわること」だと思います。

見ていると、どうしてもベンダーをやっていた時代の自分の夢(例:ストレージはこうあるべき、サーバーはこうあるべき、災対はこうあるべき・・・)にこだわってしまいます。しかし、情シス内のビジネスの進み方を見れば分かるように、業務を実現することが最優先です。業務の実現以外は二の次です。いっときならインフラの都合を優先できるかもしれませんが、時間が経てば大きな流れに飲み込まれてしまうのが常です。

ということで、ユーザー側は、技術にこだわるべきではないと思います。「まわす」こと、特に業務の実現に集中すべきです。「この人は頼りになる」と思われれば、SIerが力を貸してくれます。自分がSIerの代わりをすることが情シスの役目ではないはずです(多くの企業の場合)。
とはいえ、持っているITスキルは無駄にはならないと思います。レビューのときに、するどい指摘ができますし、トラブルなどのときに各種判断の根拠になるからです(特に、「こういう理由でこの作業はしない」という、負荷が減る方向のジャッジは貴重です)。

私もインフラベンダーの人間なので、万が一、ユーザー側に行った場合には「まわす」ことを心がけたいと思っています。はい。
[ 2009/05/13 23:32 ] 雑談 | TB(0) | CM(0)

コンサルタントであるとは、お客様との関係のことを言う? 皆様とお客様との関係はどうでしょうか?

前回、「若手コンサルタントが簡単に前言撤回するようなことをしてはイカン」と書きました。その理由は、コンサルタントとして不安に思われるという主旨でした。今回は、「力とは関係である」という話(※)から始まって、コンサルタントとお客様との1つの関係、ITエンジニアとお客様との関係について、ちょっと書いてみたいと思います。

※ワインバーグ著「スーパーエンジニアへの道」の第14章に書いてあるので、興味ある方は原書もどうぞ。

意外かもしれませんが、あるお客様で絶大な評価を得たITコンサルタントが他の顧客でも高評価を得るとは限りません。相性と言ってしまえば簡単ですが、ITスキルやコンサルスキルは変わらないはずで、本人が手を抜いているわけでもありません。

●力って関係です。

そのような時、「力を発揮しにくい関係になっている」というケースがあります。力を発揮しやすい関係とは、どのようなものでしょうか? そもそも技術の力ってなんでしょうか? 「スーパーエンジニアへの道」にも書いてありますが、多くのITエンジニアは、いかにITを知っているか、それが力だと思っています。もう1つの答えは役職が高い(もしくは権力がある)だと思います。
しかし、ITを知っていても、関係ない分野ならお客様は興味が無いでしょう。ITを深く知っていてもマネージャに昇進したら、あまり価値は無いでしょう。それよりはマネージメントを知っている方が良いですよね。それと、役職が高い人でも、土日はただの人です。役職が高いということ自体に意味があるわけではありませんよね。それらはあくまでも「必要とされる場合に」価値があるものです

仮に、Aさんが神様みたいなプログラマーだとします。同じプログラマーから見ると、それは力かもしれません。もう少し考えると、神業を必要とするようなプロジェクトにおいてや、自分も上達したいプログラマーから見ると尊敬に値すると思います。でも、明日はどうでもいいやと思っているプログラマーは尊敬しないでしょう。

ということで、評価を得るためには、顧客や周りとの”関係”が重要です

●コンサルタントとしての関係を築く

技術アドバイスのコンサルタントは、知識や経験を売るお仕事です(最近はシステム構築を専門とするコンサルタントも居ますし、重要ですが、ここでは除いて考えます)。「この人の知識や経験、やってくれることは僕らにとって大事だ」と思ってもらえれば、大抵、現場はスムーズに回り始めます。
この関係を作るのが、実は肝だったりします。若く見えたり、おどおどしてたり、経験不足に見えたり、お客様が「作業してよ」というマインドでいると、「期待通りのパフォーマンスじゃないね」と言われやすいのです。

ということで、最初に「おっ、こいつはすげえ。大丈夫だ」もしくは「経験豊富そうだね。安心できるよ」と思わせることも、関係づくりの大事な作業です。

コンサルタントって、「語るべき何か」があって始めて、コンサルタントだと思うので、専門分野などの何かに精通していることは大事だと思いますけど、それだけでは現場で活躍できないと思います。一部のコンサルタントはそれを理解していて、お客様の心の中に「コンサルタントとはこういうものだ」というイメージを作れる人が居ます。そういう人は見ていて「プロだなあ」と思います。

●別に技術アドバイスのコンサルタントじゃなくても

話はITエンジニア(ITに限らずもっと広く)で共通のはずです。どんなに技術力があっても、関係が適切でなれば、力は発揮できないはずです。
能力はあるはずのチームで、かつお客様も意地悪ではない、でもうまくいっていない場合には、”能力”や”お客様”を疑わずに、”関係”を疑ってみてはいかがでしょうか? 

たぶんキーワードは、前述の本にも書いてある「あなた(お客様、本人、部下、上司・・・)が本当にほしいものは何?」だと思います。
※原著では「あなたが本当にほしいものは何?」です。

P.S. 最近は、本当に欲しいものは(少なくともお客様の言い分が)”安さ”だったりするのがつらいところですよね^^; 安さ以外の価値を認めてくれるお客様のところで仕事をしたいものです。

[ 2009/05/10 23:14 ] コンサル手法 | TB(0) | CM(0)

若手コンサルタントの会話をきいて思った、コンサルに必要なこと

先日、部のメンバーでお酒を飲んでいたところ、次のような話になりました。
以下、若手(Aくん)と管理職(Bさん)の会話イメージ。
A「僕、XXできるんです。お任せください!」
B「本当かぁ?」
A (管理職から言われたので、あっさりと前言を翻し)「すみません。・・・」

コンサルって、知恵と経験を売る仕事でもあります。そのため、発言は重要です。ツッこまれて、あっさり意見を取り下げるようでは、お客様から不安に思われます。
#今回は上司だからかもしれませんが。 なお、私はBさんではありません。念のため

コンサルタントはきちんと考えた上で、「言いきる」ことが必要です。日頃の勉強は、「言いきる」ために積み重ねるものだと思っています。

とはいえ、返せないこともあるでしょう。そのときは3つの方法がお勧めです。1つは、「質問で返す」です。「XXXって出来る?」と聞かれたら、「XXXって具体的には何ですか?」などと返します。そうやって、そもそもの課題について理解を深めたり、考える余裕を作ります。なお、質問に質問を返すと、かしこく見えるという副次効果もあります。

「それは何のためですか?」と聞くのも手です。出てきた質問に答えられなくても、そもそもの課題には答えられるかもしれないからです。より根本的な課題に応えることを目指しましょう。

次は、「XXXって出来る?」と聞かれたら、「XXXという前提ならできます」という具合に、前提などを置く方法です。これは、ワインバーグさんの「コンサルタントの秘密」に書かれている「オレンジジューステスト」と同じで、全否定するのではなく、前提などを出しながら着地点を見つけるという方法です。これも「こいつやるな!」と思わせる対応の1つです。

最後の3つについては、コンサル以外の方にもお勧めです。ぜひ、身につけましょう!!
[ 2009/05/06 23:25 ] コンサル手法 | TB(0) | CM(0)

「門外不出のOracle現場ワザ」の第3章が、OTNで読めるようになりました。

OTN上で順次公開されている、「門外不出のOracle現場ワザ」の内容ですが、最近、第3章が公開されました。

第3章では、設計段階に潜在的なトラブルを仕込んでしまわないように、あるいは「気付いたときには手遅れだった」という自体をできるだけ引き起こさないように、設計時に注意するべき事項についてまとめています。本コラムは業務アプリケーション開発チーム編とインフラ設計チーム編に分けて解説しています。

第3章 データベース管理 転ばぬ先の杖~設計編

私が所属するテクノロジーコンサルタントの紹介ページ(OTN上で数か月前から掲載)もよかったら併せて読んでみてください。

第0章 オラクル社のテクノロジーコンサルタントって?
[ 2009/05/03 23:22 ] 雑談 | 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冊としてお勧めです。



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