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

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

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

スポンサーサイト

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

渋滞学の勉強版? 勉強はぎりぎりまで待つ、いつか役立つという勉強はしない

今回は知識の渋滞です。長い間、人事&教育担当をやっていたので、どう教えるか、どう学ぶかについては相当研究しました。その結果、勉強には「知識の渋滞」があると思うようになりました。また、「仕掛り」や「半完成品」は避けるべきだと思うようになりました。

世は不況です。空いている人には「勉強でもしていなさい」と指示が出ますが、私の考えではギリギリにやるのが一番だと思います。そして、多少強引でも終わらせることです。

勉強で知識が身につかないケースは「勉強後、使わない」場合です。これは異論がないと思います。でも、そもそもは仕事で成果を出すために勉強をするわけで、一歩考えを進めると、「実務で使う直前になってから勉強すれば十分」となります。

前回の「間締め」でもそうでしたが、半完成品を積み上げておいていいことはありません。知識の場合、忘れていってしまいます。そこで、いかに”使う直前に学べるか”が大事になります。
「いつか役立つ」というスタイルでの勉強は、お勧めできない理由です。振り返っても、「いつか役立つ」と思って行った勉強は身につかず、結局「役立たなかった」ですね。

注:ただし、教養系は違います。日頃からの積み重ねが重要だと筆者も思います。

●じゃあどうするの?

どうしても「今すぐ仕事で使わない知識を勉強する」こともあるでしょう。その場合、元教育担当としてのお勧めは、次の3つです。

・実際にやってみる
 座学で勉強するだけでなく、体を動かしたり、実機で動かす方法です。各段に憶えられます。でも、この方法でもまだまだです。

強制的にアウトプットを出す(資料にまとめる、セミナーやる、etc・・・)
 これがお勧めです。アウトプットにならないまま積み上げているのであれば、アウトプットにしてしまえばいいのです。ということで、資料にまとめたり、自分が先生をしてしまいましょう。アウトプットすることを上司に宣言するのもお勧めです。

・その後、復習をする
 ありきたりですが、復習をしましょう。これも一種の「使う」です。


●「ぎりぎりまで勉強しない」を実現する方法

なぜ、「いつか」に備えて勉強するのでしょうか? いざというときに調べ始めたり、勉強しても間に合わないからだと思います。これが「ぎりぎりまで勉強しない」にとって障害になります。そこでお勧めの方法は次の3つです。

・「これいいな」と思ったものは、自分のPCに入れ込んで、検索エンジンに登録しておきましょう。すると、欲しいときにすぐ入手できます。「間締め」になりますね。安心して、勉強を直前までさぼれます。

・日頃から「どの本に、どんな内容が書いているか」をメモして一覧化しておきましょう。「この本いいな」と思って買って、「積ん読く」をするのも手ですが、ここは外部ストレージを活用しましょう。つまり、買わずにおいて(メモだけしておいて)、必要になったらAmazonから買いましょう。家のスペースの有効活用にもなります。

・一次的な残業や徹夜は厭わないようにしましょう。プロマネのところでも書きましたが、全体の効率のためには、どうしても瞬間的に仕事を多くした方がいいのです。それはこの勉強スタイルをとるためには必須です。割り切るしかないと思います。その代り、学習効率は劇的に上がりますよ!

最後に。身につけるために膨大な時間がかかるものは、この方法ではもちろん無理です。まじめにやりましょう。その場合は「継続は力なり」です。
スポンサーサイト
[ 2009/07/29 23:46 ] スキル強化・教育 | TB(0) | CM(0)

DBアクセスの空白地帯 コネクションプーリングを極める

「門外不出のOracle現場ワザ」にのっている、コネクションプーリングの記事をOTNで読むことができるようになりました。
DBアクセスの空白地帯 コネクションプーリングを極める

コネクションプーリングに特化して書いてある内容は珍しいと思います。コネクションプーリングの実装がどうなっているのかを理解しないまま、なんとなく使っている人が多いのではないでしょうか。この機会に学んでみてはいかがでしょうか。

なお、上記Webには私の名前が載っていますが、この記事に関しては五十嵐建平が筆者です。一応フォローでした。

[ 2009/07/28 23:44 ] アーキテクチャ | TB(0) | CM(0)

渋滞や待ち行列の続き。製造業やプロマネでは?

『「渋滞」の先頭は何をしているのか?』のP199に、渋滞情報を流すと空いている道に皆が集中して、違う道が渋滞する、そしてまた渋滞情報を流すと逆の道が混むという、振動状態の紹介があります。これは「ハンチング現象」というそうです。

これはコンピュータシステムの負荷分散装置で見られることがあります。空き状況を見て流し先のコンピュータを変えるような動的なモードにしていると、この現象が起きてしまいますね。特に通常時は良くても、障害時にこの「ハンチング現象」を起こしてしまうことがあります。このような状態に対処するには、一度上流でせき止めて、一から起動し直し、徐々に流れるようにすると解決することがあります。トラブル対応する可能性がある方は覚えておくと役に立つと思います。


●「次工程はお客様」と思え&「間締め」

プロジェクトでも仕事が渋滞することがありますよね。そんなとき、メンバーに心がけてもらいたいと思うのが、製造業で良く言われる「次工程はお客様と思え」です。これを現場のメンバーが実践しているのと、「遅延しているけど、まあいいや。あとでやれば」と思っているのでは大違いだと思うからです。

「自分が少し無理して、早く次工程に渡して、堂々と休む」と「いつもどおりに仕事して、少し遅れて次工程に渡して、特に休まない」だと、労働時間が一緒でも前者の方がプロジェクト全体が速く進みます。で、リーダーをしていると気がつくのが、せっかく稼いだ時間をただ食い潰しているチーム(や人)の存在です。プロジェクトの中のたかが一工程と思うと、急いでやろうとは思わないかもしれません。でも、お客様が目の前で待っている&自分の作業だけを待っていると思えば、「早くきちんと仕事して、渡して喜んでもらおう」と思えると思います。

「間締め」も生産性という意味では似ています。「間締め」とは、工程の間を詰めることです(参考)。

参考:「間締め」とは、運搬の浪費、待ちの浪費、移動の浪費などを最少にするために、部品の位置や設備、治工具の位置などの距離を最小限に間締めすることだそうです(by Webサイト)

一人一人、一回一回では大きな時間は生まれないかもしれませんが、プロジェクト全体となれば大きな違いがあるものです。我々ITのエンジニアも、製造業の「間締め」や「次工程はお客様」を参考に、「次の工程(や人)を待たせない」を心がけるべきなんだろうと思います。

CCPM(クリティカルチェーンプロジェクトマネジメント)が、ここら辺の知識をうまくプロマネに生かしているので、興味がある方は「TOC(制約理論)」 「情シスとSIerの”信頼しない”が非効率を生む?」 を読んでみてください。

●「間締め」などをコンピュータシステムに生かすと?

なんといっても、リクエストをシステム内に溜めこまないことだと思います。溜めこんで処理しきれなくなったり、処理しきれないまま時間が経ち、ユーザーから見て意味がなくなるくらいなら、「受け取らず、エラーにしてしまえ」と私はお勧めしています。通信のシステム屋さんは、ここら辺の渋滞への対応ノウハウを持っていて、流量制御をきちんと設計しています。ご存じない方は、調べてみてください(注)。

注:流量制御(帯域制御)については、DBマガジン2009年9月号の特集2のアンチパターン9で、簡単にご紹介しているので、もしよかったら、こちらも見てみてください。
[ 2009/07/26 23:39 ] 雑談 | TB(0) | CM(0)

DBマガジン最新号(2009年9月号)に特集が載りました

最も難しい”ヒト”の問題を徹底考察
「13のアンチパターンに学ぶDBシステムのプロジェクト管理」です。

以下のアンチパターンを載せています。
・気がついたらテストの時間がない(もしくはテストをしない)
・目標なきチューニング
・完璧な初期DBサイズ見積もりと実際のデータ量の差が生む悲劇
・性能に関するアプローチがない
・DBに格納されているテストデータ量が少ない/種類が少ない
・見て見ぬふり  <- DBやソースコードのリファクタリングをしない
・重すぎる高価な鎧 <- 過大な可用性要件
・度を越した楽観  <- パッチなどは当てよう。昔、矢木さんからコメントいただきました。
・心配屋   <- 安全率に安全率のような話
・自社に合ったDBAのあるべき姿が分からない、DBA担当の要員アサインが悪い
・DBAが育たない
・セキュリティ権限設定とDB運用のミスマッチ  <- RZPさんからいただいたネタです。
・DBチームのリーダー/担当者の権限が弱い

最後に紹介している”解決策”は個人的にはお勧めです。万能とまでは言いませんが、私の知る中ではもっとも強力です。

なお、今年の秋に、今回も含めた3回分のアンチパターンを集めた本を出す予定です。書籍化にあたっては、次の2つを追加しようと思っています。
・データの保持期間を決めていない  gskさんからのコメント
・サーバー移行やバージョンアップでSQLのテストが大変

最新版のDBマガジン、楽しんでいただければ幸いです。それと、景品が当たると評判の読者はがきでのコメントもお願いします。私の個人的なモチベーションの素なので。
[ 2009/07/25 16:43 ] 雑談 | TB(0) | CM(0)

渋滞学とコンピュータシステムの遅延の関係

これから数回に渡って、渋滞の話と、コンピュータシステムの遅延、製造業で有名なTOC、TOCのプロマネへ適用したCCPMなどなど、”行列”に関してブログで書いていきたいと思います。

きっかけは『「渋滞」の先頭は何をしているのか?』を読んで、システムの性能分析と似てるじゃん!と思ったことです。

まずはこの本から少し紹介します。この本によると、渋滞には3種類あるそうです。1つはボトルネック。もう1つは自然渋滞。最後の1つはだんご渋滞だそうです

●渋滞その1
ボトルネック型はコンピュータ屋には、分かりやすいですよね。ある箇所の限界を越えて流量が発生した場合に発生する、どうしても避けられない渋滞です。

●渋滞その2
自然渋滞は、特に明確な理由(例:事故渋滞)もないのに、渋滞しているケースで起きるそうです。ぎりぎりの混雑度で走行している中、ちょっとした坂道で連鎖的にブレーキを踏んだ結果、後ろの車が止まってしまうような渋滞です。この本によると、このような事態を避けるため、40mより短い車間距離にしないよう、皆が意識することを勧めています。そうすれば自然渋滞は防げるのだそうです。仮に誰かがブレーキを踏んでも、余裕があるため後ろの車はあまりブレーキを踏まず、ブレーキの連鎖(悪循環)が起きず、渋滞にならないという理由です。

●渋滞その3
だんご型は、電車やエレベータで見られる渋滞です。ある電車が遅れると、その結果、その先の駅で乗りたい人の数が増え、ますますその電車が遅れるという悪循環のことです。エレベータでも良く見られますが、ほぼ同じタイミングで多くのエレベータが到着するのは、この現象です。なお、電車が「後ろの電車が遅れているため、間隔調整をします」と前の電車が待つのは、この現象を避けるためだそうです。

だんご型の渋滞では、悪化をさけるため、拡大しないよう負の連鎖を早めに断ち切るべきなのだそうです。

●渋滞とコンピュータシステムの類似点

P53の渋滞の図を見て、「おっ、システムの遅延の図に似ている」と思いました。P53の要点をまとめた図と、私がシステムの遅延で見るグラフの図を載せます(クリックすると拡大)。似てますよね?

渋滞の図
渋滞の図

システム遅延の図
システム遅延の図

●疑問1:なぜ限界を超えると、スループットがちょっと落ち込むのか?

これは待ち行列がシステムの各所で発生するためです(のはずです)。するする流れているときは、1つのリクエストを処理するコストは変わりませんが、待ち行列ができてしまうと行列のメンテナンスや行列のスキャンが増えるなどして、1つのリクエストを処理するコストが増えてしまうのです(私の経験上)。そのため、よくよく見ると、渋滞の図と同じように、限界を超えると、処理量が落ち込む様子が見られます。

●疑問2:なぜ渋滞ほど、流量が落ち込まないのか

システムの場合、密度がどんどん上がるということはなく、どこかに待ち行列で待たされます。そのため、限界を超えると、スループットはフラットになるのが普通です。この点については実際の渋滞とはちょっと違うかなと思います。

●ちょっと役立つTIPS

多くのエンジニアがボトルネック型の遅延は理解していると思います。しかし、瞬間的な性能劣化に、この渋滞学が使えると私は思います。コンピュータシステムは、実は瞬間的に待ち行列を作り、また待ち行列が解消するという動きをしていることがあります。なぜかレスポンスが悪いなと思ったら、この”瞬間的な遅延”を疑ってみてください。

それと、パケット分析などをすると気がつくのですが、システムでは、道路の車のかたまりのように”処理の波”が見られます。DBMSが波を作ることもありますし、ディスクが作ることもあります。DBMSの更新ログの書き込みは大抵「まとめ書き」の機能を持ちます。まとめ書きをすると、性能は良くなりますが、複数のリクエストがかたまって処理されます。つまり、処理の波ができます。また、ハードディスクのヘッドは、エレベータシーク(※)という、まとめ処理の動きを持ちますが、これも処理の波の一種と言えます。

※:上述のエレベータの渋滞も思い出してください。

●まとめ

システムの性能分析をする際には、ボトルネックのような分かりやすい遅延以外にも、微小な遅延の存在も疑ってみましょう。

まだまだ渋滞とシステム遅延、”行列”のネタが続きます。
[ 2009/07/23 02:17 ] アーキテクチャ | TB(0) | CM(0)

人を人としてデータモデリングしていますか?

引っ越ししてしばらくしたので、以前住んでいた地域の店舗の銀行口座を解約しました。すると、インターネットバンキングも解約されるというのです。もちろん、今住んでいる地域の店舗にも口座を開いています。

しょうがないので、一度インターネットバンキングを解約し、入り直しました。ふと思ったのですが、「これは人を人としてデータモデリングしていないのが原因」と言えるなあと思いました。

多くのシステムでは、データモデリングの際にボトムアップ方式(画面項目や帳票など)でデータ項目を拾います。そしてモデリングの際、利用者個人は、口座番号やIDやメーター番号(ガスや水道など)で特定できるエンティティとします。例えば、水道局から見ると、水道のメータまでが利用者個人にひもづく範囲であり、それ以外の電気やらガスやら、その人の遺伝子などは気にしません。従来、システムを構築するにあたって、これは常識であり問題ではありませんでした。しかし、最近、問題になろうとしています。

私が経験した事象に立ち返ると、インターネットバンキングのIDは、店舗の口座にひもづいていたのです。店舗の口座が親ということです(そのはずです)。私個人にひもづいていれば、1つの店舗の口座を解約しても影響はないでしょう。でも、個人を口座で表してしまっている以上、それはできません。これが私の言う「人を人としてデータモデリングしていない」の意味です。一部の人はこれに気が付いていて、概念データモデリング時点で、人をどう捉えるか、どう表現するかにこだわります。以前、「人はメーターではない。ビジネスの発展の余地も考え、あるべき定義にしておかないと大変なことになる」と教えてもらったことがあります。ただし、この方法でも”理想的な「人」の定義ができる”わけではありません。あくまで、多少は広く通用できる定義です。

顧客データに関して、システム間連携がおかしかったり、妙な名寄せをしていたり、ビジネスの展開の足をひっぱったりしていたら、それは、「人」のモデリングが、狭い範囲での最適化になっているからかもしれません。皆さんのところの定義はどうですか?

[ 2009/07/20 01:16 ] DBA | TB(0) | CM(0)

転職の際、見過ごしがちなこと

世は不況です。転職することもあるかと思います。元人事系でもあるので、転職の際、多くの人が見過ごしがちなことに触れてみたいと思います。

●落とし穴「やりたいことがやれる職場で選ぶのはNG」

まず1つ目は、「やりたいことがやれる職場か」ではなく、「自分が必要とされている職場か」で選ぶべき・・・です

「自分はコンサルティングをしたいんです。だからSEからコンサルに転職しました。」という人が居ます。転職雑誌にいかにも載っていそうな話です。やりたいのは本当だと思います。でもうまく行かない人が結構います。

転職後、誰かが手取り足取り教えてくれるとは限りません。むしろ、転職ですから即戦力が期待されます。そのため、現状の自分のスキルが必要とされているかが大事です。感謝されるとうれしいものですが、必要とされるのはいろんな面でいいことです。必要とされると活躍できますから、すべてがうまく回ります。
逆に、やりたい仕事に就いても、必要とされない場合、悪循環に陥ります。

転職時には「なぜその職場は自分を必要としているのか。その理由は妥当か。自分は替えがきかない存在に(できれば)なれるか」を考えてみてはいかがでしょうか

●もう1つの落とし穴・・・文化

多くの人を見ていると、自分が意識せず身につけた「その職場の文化」や「やり方」の効果は大きいと思います。転職すると、それが0になります。そのため、以前の会社では”やり手”であっても、転職後に”やり手”のままでいるのは難しいと私は思います。「こんなはずじゃなかった。自分はもっとできるはず」と思うかもしれませんが、今まで「文化」に守られていたためで、自分の実力ではないのが実情です。転職のときは、そのアドバンテージを捨て去る覚悟がいるんだなあと思います。

●コンサルというイメージ憧れる人

「コンサル」というイメージに憧れるのも良くないと思います。というのも、コンサルとして”何を語りたいか”を身につけるのが先だと思うからです。「コンサルに転職したい」という人と会うと、大抵、「語るべきものを持っているか」を私は確認します。多くの人が語るべきモノを持っていないので、「じゃあ、まだ転職じゃないですね」というオチになることが多いです

●最後に

私の考えでは「簡単に自分の強みを捨てない方がいいですよ。自分の強み(や必要とされている点)をまず自覚しましょう&身につけましょう!」です。
[ 2009/07/15 23:11 ] 雑談 | TB(0) | CM(0)

マンガでOracleの内部をいくつか紹介しているサイト

人づてに、諸橋さんのブログに、マンガでOracleの内部をいくつか紹介しているサイトの紹介があると聞き、見てみました。

「AsterくんがガイドするOracle Event Tours」
http://www.ex-em.co.jp/exem_labo/exemlabo_oracle_knowledge_index.html
エンキュー、ラッチ、scattered_read、sequential_read、などなど。。。
まじめな紹介も良いと思うのですが、こういうのも良いですよね♪
Oracle用のツールなどを作っている韓国の会社のノウハウらしいです。

紹介が載っている、諸橋さんブログはこちらです。
http://d.hatena.ne.jp/wmo6hash/20090705/p2
なお、この人もスーパーなエンジニアです。
[ 2009/07/13 01:39 ] アーキテクチャ | TB(0) | CM(0)

デスマーチプロジェクトでやってはいけないこと

「何とかするように」と命を受けてデスマーチプロジェクトに参加するPMやPMO、リーダーがいるかと思います。そのような人がやりたくなるのが「やり方を変えること」だと思います。

デスマーチをさらに酷くする落とし穴として、実は「やり方(開発手法やプロジェクト管理手法やツール)を変える」ことがあります。最近、デスマーチの第2版を読んでいて、ほぼ同じ記述があったので、昔の経験と合わせてちょっと書いてみます。

デスマーチになっている以上、何かが悪いと思うのが人情です。でも、新たな何かを覚えたり、やり直しする時間は無いですよね。既に悪い状況下で、うまく回るようにするには、全員が合意するシンプルな方法を使うこと、課題をきちんと管理すること、誰かが軸となることだと思います。つまり、詰まっているところを流してあげることだと思います。

昔、PMOとしてデスマーチと呼ばれるプロジェクトに入ったとき、「プロジェクトマネジメントのガイドラインを揃えるのだ!」と新たな負荷を増やそうとしていた人がいましたが、逆効果ですよね(でしたね)。現場はそんなきれいなものを求めているわけではなく、混沌としていても効果がある方法、つまりシンプルな方法、うまく流れる方法を求めていると感じました。ある人が言っていたのですが、「途中から入るのであれば、課題管理をきちんとやること」と言っていました。私もやってみて思ったのは、「課題管理さえきちんとやれば、周りがついてくる」です(多少は出来たはずと信じてます)。誰かがきちんと軸となって、指示を出して、周りがついてくるようになれば、それで良いと思うのです。

結局は、余計な重荷は増やさず、周りの力を生かすことなんだと思います。デスマーチに途中から参加することになったら参考にしてもらえればと思います。つい、何かが悪いと思ったり、何かを変えたくなったりするものなので。

P.S. 当然、スコープ(範囲)を減らすことは王道ですよね。

ITエンジニアにお勧めの「ムードジャーナル(気分日記)」

多くのITエンジニアは、自分の気分を感じるのも、管理するのも苦手だったりします。ひところ話題になったEQ(IQに対して心の知能指数と呼ばれるものですね)ってご存じでしょうか?

以前「記録すること」の重要性をブログにも、書きましたが「記録の重要性とエンジニアの成長の関係」、気付きの能力を上げるためには、まずは記録と振り返りです。EQでもムードジャーナルという形で、記録と振り返りを勧めています(EQマネージャのP152から156あたり)。

簡単にご紹介すると、
以下の気分に対して、1~9までの点数をつけるのです。
1が「まったく感じていない」で9が「確かに感じている」です。

気分:
いきいきしている、ワクワクしている、憂鬱な、つかれている、思いやりのある、満足している、元気がない、神経過敏な、眠い、不機嫌な、元気いっぱい、神経質な、穏やかな、友好的な、うんざりしている、活動的な

併せて、次の情報も記録します。
日付
時間
場所
関係者
出来事
感情に「先立って」起こった出来事

●どんなことが分かるの?

どういうときに、どういう気分になるのか分かります。
気分がどのように変化するのか分かります(気分って、時間が経つと変化するんですよ)。
どの気分とどの気分が連動するのか分かります(気分同士に関係があるんです)。
自分の気分の特徴がわかります。

etc・・・

●最後に

自分の気分を前向きにコントロールできると、楽ですよ。苦労している人は是非EQなどの勉強をしてみることをお勧めします。

[ 2009/07/06 00:50 ] スキル強化・教育 | TB(0) | CM(0)

自分のDBエンジニアとしてのレベルを知るには?

自分の現在のレベルを知りたいというのは、万人共通の思いだと思います。
でも、ITSS(ITスキル標準)をじっくり見たことがある人は少ないと思います。
今回はITSSのDBエンジニアのレベル定義についてちょっとご紹介です。

http://www.ipa.go.jp/jinzai/itss/download_V3_2008.html
このページの「ITスペシャリスト」の箇所にDBエンジニアなど(※)のレベル定義が載っています。どんなスキルでどのレベルなのか、およびどんな研修がお勧めなのかといった紹介があります。

※:ITスペシャリストは、プラットフォーム、ネットワーク、データベース、アプリケーション共通基盤、システム管理、セキュリティという仕事についての定義を含んでいます。

また、ITSSユーザー協会によって、Oracle Master(※)とのマッピングが行われている(下記参考)ため、資格を持っている人は目安になるかと思います。

http://www.itssug.org/docs/isv/ISV-MAPver2.1_20080213.pdf
ITSSレベル4:プラチナ
ITSSレベル3:ゴールド
ITSSレベル2:シルバー

※各ベンダーの資格とのマッピングもされています。

これらで自分のレベルの評価と、学ぶべきスキルについて考えてみてはいかがでしょうか。
[ 2009/07/02 01:51 ] スキル強化・教育 | 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ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。