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

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

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

スポンサーサイト

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

文化の違いとシステム開発の困難(日中のブリッジSEから聞いた話)

今回も文化の違いに関する話です。とはいっても、システム開発を他文化の国に依頼する際の苦労話です。知り合いにブリッジSE(橋渡しをするSE)が何人かいまして、その人たちから聞いた話です(そのうち一人は中国出身の方)。ご存じのブリッジSEの苦労も多いと思いますが、一端を感じていただければと思います。

・まず仕様が大事。あいまいにしないこと。「日本なら皆わかる」ことも文書化することが必要。「~ならXXXする」を書いたら、次は「~以外ならXXXする」も書く
オフショア先のエンジニアは自信満々だから、自分から聞いてくることはしない(オフショア先出身の方から聞いた話)。日本が最初から説明しきらないと、あとで「それは聞いていない」ということになって、もめる。
・進捗管理について。直接現地を見に行くことはしない。やると大変。そのため、管理の仕方は工夫が必要。
・品質管理については、まず契約時に合意しておくことが重要。契約時は「スケジュール、予算、システム開発計画」の3点セットをつくると良いと思う。「システム開発計画」の中に、開発方法やら、動作させる環境(海外の開発環境が日本と同じとは限らない!)やら、命名規約やら、もろもろの標準化ガイドについても書いておくことによって、オフショア先と日本が同じイメージを持つようにする。
・品質管理を上記のように契約時に提示していないと、あとで「知らないよ」となる。自分のやりたいようにやってしまう。逆に提示があった方がオフショア先もやりやすい。日本側でできる品質管理としては、最初に1つサブモジュールをつくってもらって、それをレビューすること。現地に出向いて実際に調べたりするのは実質的に無理。
日本のユーザーには、「あとで直してくれるから、最初の要件定義は適当でいいや」という意識の人も居るていて、オフショア先とあとでもめる。そのため、オフショアするときには、案件(ひいてはユーザー)を選ばないと危ないと感じる

日本国内の開発にも当てはまる内容も散見されますが、文化の違いや距離の違いというのは大変なんですね。
スポンサーサイト

文化の違いとコンピュータシステムへの影響

ニュースなどで文化の違い(一部、宗教の違い)を見聞きするたびに、「大変だなあ」と思いますが、今日の記事は、その文化の違いがコンピュータシステムにも影響を与えるという話です。

私の知り合いがパッケージソフトの開発をやっているのですが、その人から「世界にはこんな言語(ひいては文化)がある。」と聞きました。ほとんどイスラム世界のネタです。

●右から左、左から右の混在

アラビア語は、基本的に、横書きで右から左に書いていきます。日本人も横書きをしますが、左から右ですよね? 右から左だけでも違和感がありますが、ところどころ、左から右に書いていく(表示していく)ところもあるそうなのです。イメージすると、右から左に文字が表示され、ところどころ左から右に表示され、また、右から左に文字が表示される・・・・という感じです。なんでも外来語などは左から右なのだそうです。

●ボタンが増える?

右から左、左から右、という2パターンあるということは、モノによっては、ボタンもそれに対応する必要があるそうです。すると、英語では1つのボタンで済んでいた画面が、2つになったりするそうで、当然、アプリケーション変更でしょう。ここまで来ると「文字が違う」だけでは済まないな、と思います。

●アイコン禁止?

「偶像崇拝禁止」に関連するそうですが、アイコンのようなものも、基本的には良くないそうです。ただ、イスラム圏でもアイコン禁止・・・までではないようです。

●色づかいも問題?

色にも意味があるそうで、「この色づかいはまずい」と言われたりするそうです。

●カレンダーは、地域によって異なる? 当日になるまで分からない?

日本でも良く聞く、「ラマダン」ですが、「新月が確認できたら」なのだそうです。ということは、曇ると開始がずれたり、地域(緯度や経度)によって日にちが違ったりするわけで、ラマダンをシステムに持たせるためには、「ラマダンを設定する機能」が必要なのだそうです。

※意外と知られていませんが、日本の祝日である「春分の日」と「秋分の日」は前年の2月1日にならないと決定しません。ただ、数年先くらいなら大体予想できるそうです。
参考 http://www.nao.ac.jp/QA/faq/a0301.html

●まとめ

ローカリゼーション(各国語対応)というと、「単純に文章を翻訳してお終い」というイメージがありますが、このように大変な場合もあるという話でした。

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

「私はOSとストレージとネットワークに興味がある」という割には、そういう話題を書いていませんでした。今日はOSをテーマとして、将来のボトルネックという話を書いてみたいと思います。今回は難しい内容を簡単に説明できていないので、「分からなかった」というコメントが届いたら、丁寧に書き直したいと思います。

さて、「分散メモリー」という技術があります。いいですよね。クラウドコンピューティングは将来バラ色に見えます。

マルチコア化(クアッドだけではなく、8コアとか)も、いいですね。どんどん性能が上がるように思えます。

ここで質問です。クラウドコンピューティングやマルチコア化やグリッドやDBMSに共通する(はず)の将来のボトルネックってなんだと思いますか?
・・・それは”(厳密な)調整”機能だと私は思っています。

ここからの説明はちょっと遠回りになります。HPのコンパイラのサイトに、このような実験結果が載っています。あるDBMSにおけるCPU命令プロファイルの結果です。プロファイルから「何に時間がかかっているか」が分かります。
http://www.it-kiban.jp/hpux/developer/old/?column02/compiler_02/index.html

この結果からも分かるように、実はDBMSにおいて、CPUコアは頻繁にデータを捨てたり、ロードしたり、他のCPUと同期をとったりしなければいけません。理由は、「データベースが扱っているデータそのものは複数のCPUで同時に更新してはいけない」(図1参照)ことの他に、”DBMSの内部ロック命令そのものが、CPUのメモリ命令を使って実装されているから”(図2参照)です。

図1

図2


APサーバーを多数持つ、Webの大規模システムであっても、結局DBMSで排他制御のためのロックを実装しますよね。(参考:過去の記事「商用DBMSとオープンソースデータベースの差」)。
そのDBMSのロックは、最終的には、CPUの命令ベースのロック命令に行き着きます
#もし私の不勉強で他の実装を知らないだけの場合、教えていただけると助かります。
専門的に言うと、OSレベルではmutexなどです。それを支えるアセンブラの命令はCPUの種類によって異なりますが、CPU間でのメモリ同期と、メモリを使ったtest-and-setやcompare-and-swapなどです(詳細は内緒です)。これらの命令の特徴は成功か失敗のどちらかしかないことです(この特徴をAtomicと呼びます)。

ここまで読んで「マルチコアにおいて、DBMSは同時に処理できているではないか。」と思うかもしれませんが、CPUのメモリ処理で同期が必要なものは、メモリバリアとかメモリフェンスとか、そういうCPUの命令でCPU間で同期をとっています(図3参照)(とらないと最悪、ロックが壊れます)。これが”厳密な調整”機能の1つの例です。こういう、他のCPUコアを待たせるような処理は、コアや台数が増えれば増えるほど、ボトルネックとなっていきます。

図3


NUMA(複数CPUでメモリアクセスの速度が異なるアーキテクチャ、詳細は割愛)というアーキテクチャが出てきていますが、これは多くのCPUをまたがって、メモリアクセスの速度を保つのが困難になってきたからです。それほどCPU間やメモリの通信のレイテンシーは問題になってきています。

NUMAやマルチコアですら、通信の高速化が困難になってきているのに、理想のクラウド(※)はどう高速なロックを実装すればよいのでしょうか? 今後、マルチコアは進むはずですし、グリッドやクラウドはどんどん台数が増えていくはずです。ということで、将来、クラウド等の環境で超高速な処理をさせようとすると困るはずです。
※いつ、どこで実行されるかまで含めて自由なクラウドコンピューティングのことを、今回こう表現しています。

クラウドがダメと言っているわけではありません。クラウドは好きですし、今後も発展していくのだと思います。そこでソリューション案(予想)です。

●ソリューション案

そもそも、現実世界では、いろいろなものが自律的にバラバラに動いているわけで、それを決定論のように厳密に1つがコントロールする現状のコーディングでは、性能的に無理が出る時もあると思います。

CPUの命令レベルから、クラウドのレベルまで考えてみましたが、やはりこれ以上、コンピュータの性能を上げようと思うと、最初に書いた「厳密な調整」の能力に何らかの制限をつけるしかないと思います。ということは、「厳密な調整」が不十分であるというシステム(ひいては業務処理)というものが求められそうです

「別々にいい加減に処理する(最後につじつまあわせをする)」という「曖昧な調整」を行うコーディングがはやるかもしれません(個人的にはそうなると思っています)。例えば、在庫の管理もいい加減になり、「だいたいあと10個ね」とか、「だいたい売り切れね」というシステムが出てくるかもしれません。もしくは、あとから在庫調整(つじつま合わせ)をするDB群とか。なんだか面白そうですね。

前回の記事でも紹介した、ITアーキテクトのVOL19 のP23にグーグルのソフトウェアアーキテクトのホーペ氏の話は近い内容だと思います。
---------------------------引用ここから------------------------------
「クラウド・コンピューティングの世界は、非常に不確実性が高く、現状ではそれを解消する術はない」とホーペ氏は語る。そして、こうした状況下では、「エンジニアはソフトウェアに対する考え方を変えなければならない」というのがホーペ氏の主張だ。システムのすべてをコントロール可能だと考えるのではなく、偶発的に起こる事象に対して柔軟に対応できるように備えよというのである
---------------------------引用ここまで------------------------------

私はDBMSのCPUのロック命令から、この結論にたどり着きましたが、クラウドの専門家も同じような考えのようです。きっと、エンタープライズシステムの利用者もコンピュータに対する考えを変えなければいけなくなるんでしょう。特にバッチ処理の考え方(※)は変わらざるをえないはずです。
※:高速なCPUで処理をぶん回す発想のバッチ処理のことを指しています。

開発におけるモデリングも変わると思います。なんせ、コンピュータに「厳密」を期待できなくなる(かもしれない)のですから。

今回の内容は、突飛すぎたかもしれませんが、インフラのアーキテクトとして、自分なりの考えを書いてみました。楽しんでいただければ幸いです♪

[ 2009/01/20 23:00 ] アーキテクチャ | TB(0) | CM(5)

クラウドコンピューティングとミッションクリティカルシステムの相性

クラウドコンピューティングが流行りですが、それとミッションクリティカルシステムの相性についてのコメントです。

ミッションクリティカルシステムでは、SLAや非機能要件(機能以外の「性能、可用性、etc」の要件のこと)が重要とされます。止めてはいけない、性能不足になってはいけない、だからこそ”ミッションクリティカル”という名前になっています。リソースを掴んでいて、すぐ実行できるような状況でないと、SLAや非機能要件は満たすのが困難です。サービス自体の可用性の契約はあるようですが、諸々の品質のSLAを満たすのが苦手なのが、クラウドコンピューティングだと思います。

また、ミッションクリティカルシステムでは、基本的に”見える化”を行い、ブラックボックスを無くすようにしていきますが(そうしないと細かい制御や原因追究ができない)、クラウドコンピューティングでは、「(物理的な)システム状況」は、ブラックボックスになってしまいます。ということで、この両者は、そもそも相性が悪いと私は思っています

実際、仮想OSなどでは、CPUリソースの微妙な調整アンバランス、I/Oの原因不明な動きなど、仮想ならではの動きが見られます。将来は改善されるのかもしれませんが、細かいことを気にするシステムでは、ちょっと厳しいです

実際、ITアーキテクトのVOL19 のP23にグーグルのソフトウェアアーキテクトのホーペ氏の話が載っています。
---------------------------引用ここから------------------------------
「クラウド・コンピューティングの世界は、非常に不確実性が高く、現状ではそれを解消する術はない」とホーペ氏は語る。そして、こうした状況下では、「エンジニアはソフトウェアに対する考え方を変えなければならない」というのがホーペ氏の主張だ。システムのすべてをコントロール可能だと考えるのではなく、偶発的に起こる事象に対して柔軟に対応できるように備えよというのである。
---------------------------引用ここまで------------------------------

性能テストをどうやるんだろ? いったん性能が出たからといって、それでどんなケースでも問題が無いとどうやって担保するんだろ? などいくつもの疑問が浮かびます。

他の記事では、どこにデータが保管されるのか分からないため、セキュリティ面でNGになるケースが考えられるなどの話もありました。クラウド自体の監視や障害時の対応、連絡体制も気になるところです。

今後、社内システムや少人数用のシステムとしては、クラウドコンピューティングはどんどん広がっていくと思いますが、ミッションクリティカルシステムでは、クラウドコンピューティング活用と異なる流れができるかもしれないと思っています。

念のため、繰り返しますが、会社としての意見ではなく、個人としての意見ですので、その点はご了承ください。
[ 2009/01/18 01:59 ] アーキテクチャ | TB(0) | CM(0)

データベースのモデリングを学ぶには?

「T字型ER データベース設計技法」 という本があります。今日はモデリングを学ぶ人のために、このT字型ERの紹介です。実は、データモデリングには、「これ」という決定的な方法論が存在していません。私の周りのモデリングのコンサルタントたちも、「私はXXX派です」とか、「私は、XXXをメインに、XXXXの要素も」といった感じで、十人十色です。

どの手法が一番か、は私には分かりませんが、どの手法を最初に学ぶべきかについては、お勧めを1つ持っています。それが「T字型ER」です。T字型ERの特徴をいくつか説明すると
・「データモデリングは工学であるべき」と言うだけあって、決まった手順がある。
・分析に特化しているだけあって、多くを望んでいない(それゆえに分かりやすい)
・リソースやイベントといった考え方が有用
・非正規化ではなく、ターボファイルという独自の考え方を持っている(これが実システムの設計で使い難い点です。でも分析のための手法だと割り切れば問題ありませんが)


たとえば、Oracleのサンプルスキーマ scott/tigerには、emp(従業員表)とdept(部門表)というテーブルがありますが、いかにこのデータモデリングが実業務には不向きかをスパッと解説してくれています(私もempとdeptはサンプルスキーマとしてはOKだと思いますが、実業務には向かないと思います)。empとdeptとassign(配属)があるべき姿ですね。

まだ、データモデリングを知らず、これからやろうかという方は、T字型ERも検討してみてはいかがでしょうか?
#T字型ERとOracleコンサルとの関係は無いので、あしからず。あくまで個人的なお勧めです。

T字型ERの注意点は、正規化(およびテーブル分割)のため、テーブルが分かれてしまい(テーブル数も多くなる)、性能が出ないことがあることだと私は思います。正しくT字型を使った例ではないのかもしれませんが、そういうプロジェクトを見たこともあります。

あと、真野正さんの本「実践的データモデリング入門」 も分かりやすいと評判ですね。真野さんとは一緒に仕事をしたこともあります。

次回はクラウドとミッションクリティカルシステムの相性などについて書くつもりです。お楽しみに!
[ 2009/01/15 02:25 ] DBA | TB(0) | CM(0)

商用DBMSとオープンソースデータベースの差

商用DBMSとオープンソースデータベースの差はなんでしょうか?
まっさきに挙げられるのは、「サポートの有無」だと思います。商用DBMSはサポートが提供されますから、特に大事なシステムでは採用されやすいと思います。もちろん、一部のオープンソースデータベースでは、サポートが提供されています(企業がサポートを提供)。違いとして、「ソースコードが公開されているかどうか」も差の1つです。

しかし、商用のDBMSは細かい制御が行えるため、大量データや統合DB、大量処理に向くという面を忘れてはいけないと思います。今日は、その説明です。

実は、DBMSの内部は、ロックの塊です。理由は、アプリケーションからのアクセスはDBMSに集中します。そのためDBMS内部でデータの排他性を実現しなければならないからです。よく知られている行ロックや表ロックはもちろん、その他にもSQLのロック、ブロックのロック、ファイルのロック・・・と無数と言っても良いくらいロックがあります。ロックを細かくすることによって、多重実行性を上げることができますが、この多重実行性が高いのが、商用DBMSの売りの1つです。オープンソースデータベースから商用のDBMSに移行するお客様がいらっしゃいますが、それは処理が多くなって、オープンソースデータベースでは性能が出なくなっているケースが多いです。

ということで、処理量が少ない、もしくは自作文化で、アプリケーション側で細かい制御するのが当たり前であれば、商用DBMSが要らないかもしれませんが、大規模システム、性能がシビア、同時処理が多い、メンテナンス時間が短いなどの特徴があれば、商用DBMSを使う理由になるはずです。あとは、パッケージ製品がサポートするDBMS(大抵は商用DBMS)を指定していることも多いです。

要件に合わせて、DBMSをうまく使いましょう♪

P.S. コメントいただきました。たしかに、フリーウエアのDBMSという表現はいまいちだったため、オープンソースデータベースという表現で書き直しました。yahondaさんありがとうございました。
[ 2009/01/09 22:17 ] DBA | TB(0) | CM(1)

Oracle Open Worldが久々に開催されます

本日も記事2つです。最初はOOWジャパンの話題です。

2009年4月22日から24日にかけて、Oracle Open Worldというイベントが開かれます。昔は展示が中心でしたが、前回および今回はセミナーが中心です。場所も有楽町の国際フォーラムで行きやすいです。OOWホームページはこちらです。お忙しいとは思いますが、知識の習得も大事です。ぜひ足を運んでいただければと思います。

ラリーエリソン会長も講演を行う予定です。きっと何か目新しいことを言ってくれるでしょう。

今、OOW無料事前登録いただくと、200を上回るセッションを一般公開に先駆けて予約いただけます(※)。なお、登録の際に招待コードという番号を入力するのですが、そこには 729 と入れていただければと思います。
※:Oracle Developという有料セッションを除きます。

会場でお会いできたらと思います。
[ 2009/01/07 23:00 ] 雑談 | TB(0) | CM(0)

アーキテクチャをレビューする方法(ATAM)

インフラの設計をレビューする方法って、何があるのでしょうか? 多くの現場では”経験に基づいた判断”程度ではないでしょうか?

私がお勧めしているのは、ATAM(Architecture Tradeoff Analysis Method)です。「シナリオ」と呼ばれる”ある事象”においてどんな振る舞いを起こすのかを確認することで、リスクや危ない点、トレードオフなどを洗い出し、アーキテクチャの品質を確認することができます。

ATAMの解説PDF(英語)です。日本語は書籍で(ピラミッドのような絵が表紙の「実践ソフトウェアアーキテクチャ」 が良いと思います。

私がATAMが特に良いと思うのは、シナリオを使っていることです。アーキテクチャ評価するにあたって、”経験による判断”ではなく、シナリオを用いて、こう動くはずだという視点でレビューするのは、経験が少ない人にとってやりやすいですし、誰も気付いていないリスクの洗い出しにも効果的です。

インフラは機能面での充足というより、品質面での問題・リスクがないかが重要です。機能であれば、抜け漏れや間違いを指摘するという、通常行なわれるレビュー方法で十分だと思いますが、インフラの場合は、ATAMのような手法を使うか、テストで確認すべきと思います。機会があったら学んでみてください。
[ 2009/01/07 22:57 ] アーキテクチャ | TB(0) | CM(0)

現実の業務のシュミレータとしての情報システム

今回は、データのモデリングや現実との乖離、といった話から、手入力が面倒なシステムというテーマまで辿って行きたいと思います。

●概要

人から聞いた話の受け売りですが、情報システムは、現実の世界のシミュレータとしての一面を持ちます。後述しますが、特にモデリングのときは、それを意識すべきです。もうすこし話を進めると、データのモデリングが、現実の業務や実態からかけ離れていると不幸になるとも解釈できます

●はじめに

まず、必要なデータ項目をシステム内に持っていないと、業務を十分カバーしているとは言えません。かと言って、必要以上にデータ項目を持っていると、データ入力が大変です。そういう意味で、データ項目(データ定義)が現実の業務と合っていないと、利用者が不便になるのはイメージがつきやすいかと思います。

●正しいデータ項目(エンティティ)を選んでいるか?

また、重要なことの1つに、「データ項目が実態と合っているか?」があります。簡単に言うと、クレジットカードのカード番号で、ユーザーを識別するのか(カード番号を通じて人にアクセス)、それとも、個人を個人(名前や住所などで個人を識別)として扱うべきなのかという問いです。限られた業務としては、カード番号で十分かもしれません。でも、業務を広げたときに、個人が特定できないと業務の拡張性がないかもしれません。カード番号を複数もつ個人が居ることも考えられますよね? ということは、カード番号で個人を特定しようとしていると、ビジネスに限界があるということになります。

●リレーション

また、リレーションが業務を反映しているかというのも大事なポイントです。エンティティが多数存在する以上、リレーションは多くの組み合わせが考えられます。しかし、実際のリレーション(どうデータが結びついているか ≒ 「辿れるか」を示しているとも言えます)は少数です。そのため、このリレーションの張り方によっては、辿れない(つまり業務処理が行えない)こともありえます。これも不便を招きます。

●それらが悪いと?

さて、皆さんのシステムは、手作業が多くありませんか? その理由はデータモデルが、現実の業務に対応していないためではないですか? システムの帳票や既存のシステムの画面だけを見てモデリングしていると、現実の業務と合わないデータ項目になるかもしれません。また、システムの更新・追加開発のときに、現実のビジネスのデータ項目ではなく、つじつま合わせのデータ項目を追加したりしていませんか?
このような場合、現実の業務のデータをシステムに入力しようとしても、入力に大変な困難が出てくるはずですし、そもそも正しいデータ項目を持っていないと、手作業でカバーする必要がでてくるはずです。つまり、現実のビジネスに対応するデータモデルがシステムに存在してこそ、スムーズな業務が実行できるというわけです

●システムは業務のシミュレータでもあるのです。

「現実世界でのトランザクション(処理)が発生したら、システム側でも対応するトランザクション(データ更新)が行われる。多少、タイムラグがあるものの、現実世界の実態とデータベースの中のデータが同期する・・・」というシミュレータのイメージです。現実世界とDBの中がずれていると、コンピュータオペレーションが大変であることが想像できるかと思います。

●まとめ

現場のデータモデリングでは、既存システムの画面や帳票からデータ項目を抽出するモデリングが行われていると思いますが、より良いシステムのためには、それらに加えて、現実のビジネスの実態や動きもみるようにしましょう!

あなたのシステムでは、現実の業務と同じように、データがコンピュータの中で動いている(シミュレートされている)と思いますか?
[ 2009/01/03 00:55 ] アーキテクチャ | TB(0) | CM(0)

日本オラクルのお茶室(高層ビルのお茶室)

あけましておめでとうございます。

お正月ということで、ちょっと和風な内容です。実は、日本オラクル青山オフィスには、本格的なお茶室があります(写真参照)。
茶室1

茶室4

ビルの最上階の中に庭付きのお茶室、外には高層ビルが見える・・・というのも非日常的で良い感じです(写真参照)。日本が大好きなラリーエリソン会長の肝入りです。

茶室2

茶室3

マナーを知っておく必要などもないため、日本オラクル青山オフィス(本社)にいらっしゃる際には、訪問してみてはいかがでしょう? オラクル社員に頼めば事情(他の予約が入っていたりなど)がない限り、案内してくれるでしょう。

火曜日、木曜日、金曜日が社外公開の日です。予約すれば、和服の先生から、お抹茶やお茶菓子などもいただけます。取材などもOKなはずです。ぜひ、いらっしゃってください♪
[ 2009/01/03 00:43 ] 雑談 | 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ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。