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

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

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

Oracleデータベースの頭脳 「オプティマイザ」徹底研究

RDBMSの心臓部であるオプティマイザ、その動作を知りたくありませんか?

門外不出のOracle現場ワザにのっている、オプティマイザの記事をOTNで読むことができるようになりました。
「オプティマイザ」徹底研究

オプティマイザの概要から、どう実行計画を判断するのか、計算モデル、バインドピーク、統計の管理、実行計画の固定(10gベース)まで、一般の方が勉強するには一押しの内容です。

なお、上記Webには私の名前が載っていますが、この記事に関しては大塚信男が筆者です。一応フォローでした。
スポンサーサイト
[ 2009/06/28 23:53 ] DBA | TB(0) | CM(0)

IT関係者に贈る、心穏やかに過ごすTIPS

IT関係者は日々ストレスが大きい仕事をしているかと思います。そんな皆さんに贈る、心穏やかに過ごすTIPSです。人によっては違うでしょうから、何かの参考にしていただければと思います。

●TIPS

・仕掛りを出来るだけ減らす
 気にしなきゃいけないことが多いと人はつぶされそうになります。なので、作業途中のものはさっさとやって終りにします。多少オーバーヘッドが大きくても、今終わらしてしまうと気持が楽になり、生産性もあがり、結果的に早く終わったりします。

・何かに記録(棚卸し)して、頭の中から忘れ去る
 気にするべきことを減らすもう1つの方法として、すぐ終わらないものは、いったん何かに記録して、”安心して忘れる”という方法があります。私の場合は、めったやたらと付箋に書いています。付箋を捨てられると私の仕事はストップします。

・笑顔を忘れない
 笑顔を忘れて仕事をしていると、ストレス溜まりますよね。無理にでも笑うと、いいことが起きるものです。つらいときほど笑顔を忘れずに・・・と思っています。

・感謝を忘れない
 笑顔と同じでつらいときほど忘れるのが感謝です。怒るよりも感謝した方が、自分の気持ちが安定します。そして、友好的になって、物事がうまくいったりします。

・できなかったことを数えるのではなく、できたことを数える
 「あれもこれもできなかった・・・」と思うと暗くなりますが、同じ成果でも「今日は、あれもこれも、それどころかこんなこともできた・・・」と思うと明るくなります。ちょっとした工夫ですが、寝る前にこう考えると気持安らかに眠れます。

・怒られている時は、幽体離脱して神様の目線で。
 いやなお客さん、居ますよね。それに、どうしても怒られる立場のときもありますよね。そんなときには、第3者的に現在の状況をとらえるようにします。言ってみれば、幽体離脱&神様目線です。そうすると、自分が怒られているという感覚がなくなり、心に響かなくなり、心の平穏が保たれたりします。

・どんなに忙しくても、オフで何かに集中する時間(1時間でも可)を作る
 スイッチを切り替えると言いますが、やっぱり仕事を忘れることは大事なのだと思います。単純作業でもいいです。有無を言わさず何かに没頭することがいいですね。

・体を動かす
 肉体派ではない私ですが、それでも体を動かすことには、とても価値があると思います。体の疲労は、精神面の疲労をとります。これ、マジです。

・まずは寝てみる
 睡眠ってストレスを減らしてくれます。まずは寝てから考えるというのも、1つの手だと思います。ただし、やるべきことから逃げるように寝るのはお勧めできませんが。

・瞬時に心を平和にする、もしくは感情が高ぶる映画やビデオを思い出す
 1つくらい大好きな映画、もしくは平和な気持ちになる映画を見たことはありませんか? 今、そんなシーンを思い出すことはできないかもしれませんが、そういう映画を何度もみて、いざというときにシーンを思い出すという方法もあります。

・私のやっていることは100点でなくても価値がある・・・と思う
 「なんで、これができない、あれができない・・・」と嫌な顧客や上司に言われることがあると思います。でも、世の中100点なんて簡単にはとれませんし、100点でなくても、70点や60点でも価値があるはずです。やらなきゃ0点ですよ。つまり、不完全でも価値があるんです。

・ITの世界では、殺されることはない
 不安な人は、より最悪の未来を想像すると、安心して目の前の困難に立ち向かえるという話があります。実際、世界にはひどい地域がありますが、われわれは殺されることもないし、転職することも可能です。最悪をイメージして、それから現実を眺めてみましょう。

・よりひどいプロジェクトの話を聞く・読む
 インターネットなどで読むことはできますが、こりゃひどい!と思うプロジェクトも多く聞きます。面白い物語も多いですよね。そういうのを一生懸命読むと、あら不思議、今の自分って大した困難の中じゃないなと思えるものです。

・弱音を吐く
 アメリカでも日本でも同じだそうなのですが、男は黙ってしょいこむものだという美学があります。で、つぶれるわけです。その点、女性陣や男性陣の一部は上手なもので、うまく愚痴をいったり、共感したりして、気持ちを軽くしています。真似していいと思うんですよね。ただし、共感慣れしている人を相手に選ばないと、話の最後で前向きにならないことがあります。

・どうしようもないことは、どうにでもなってよいこと
 ブルーハーツの曲の歌詞のようなタイトルですが、大きなプロジェクトになればなるほど、自分が影響を与えられないことは多いものです。そんなことまで心配する必要はありません。どうなってもいいのです。心配する価値ないのです。

番外編:あまりお勧めしないこと
・周りやお客様を馬鹿ばっかりと思うこと
 ほとんどのプロジェクトで見られますが、これ、あまり良くありません。お客様や周りの人って見破りますからね。

●まとめ

さんざん書きましたが、実は肝は「自分は上記ノウハウを実行すべき人かどうか」の判断だったりします。世の中には、必要なのにやらない人が結構居ます。「自分はそうかも」と思ったら、周りに聞いてみることをお勧めします。

「こういうことに下手なお前が言うか・・」という声も聞こえてきそうですが、お互い気をつけましょう!

もし、皆さんも「こういうノウハウを持ってます!」という人がいたらコメントを書いてみてください。ある程度まとまったら、ブログ記事にしますので。
[ 2009/06/24 23:59 ] 雑談 | TB(0) | CM(6)

「軸となる人」それと「ぶれない方針」

仕事やプロジェクトがうまく回らないとき、どう思いますか。それほど多くのプロジェクトを見てきたわけではありませんが、結局、「軸となる人」が必要なのだと思います

「この人に調整を頼む。その代り、私たちはその人の決定についていく」、そういう軸がないとプロジェクトって効率よく回りませんよね。そして、そのような人が出す「ぶれない方針」がどれだけ、現場の効率をアップさせるか、それをいくつか見てきました。

ある人が”軸”となるだけでは、その人が調整するまで現場は動きません。しかし、「ぶれない方針」があると、末端の人たちも、その方針に従って、自分たちで判断することができるのです。でも、これが朝令暮改の方針だったりすると大変です。「その方針についていくことが意味無いじゃん」と思って、現場が軽視してしまい、動かなかったりします(これはよくみられます)。

100点の詳細設計を時間をかけて作るのではなく、方針を出して進めればいいんだと思います。そして、できれば「方針だけはぶれないよう」にします。多少インプリやテストが大変でもぶれない。大きなプロジェクトになればなるほど、舵を切ってから船が動くまで(つまり末端メンバーが動くまで)時間がかかりますから。

PMの方には、「ぶれない方針」を出してもらえるとうれしいです。「ぶれない方針を出す”覚悟”」が必要のようです。僕が見た範囲で、一流のPMはこの”覚悟”や”度胸”があったように思います。僕はプロジェクトは人間修業だと思ってます。僕も精進します。はい。

プライドで仕事する

最近、若手に仕事の仕方のアドバイスすることもあります。1つの仕事の仕方である、「プライドで仕事する(私独特の言い方です)」についてちょっと解説してみます。

お金のため仕事する人、
人のために仕事をする人、
自己実現のため仕事する人、
趣味のため仕事する人、
プライドで仕事する人

人により、いろいろな理由で仕事をします。意外と多くないのは「お金のために仕事をする人」です。元人事であるため、昔調べたことがあるのですが、「お金は必要条件であり、十分条件ではない(少なすぎなければ、それでOK。むしろ他の環境を整えるべき)」という説があります。また、一流の人たちの退職理由を見ても、「お金」というのは少ないです。

さて、「プライドで仕事をする」の私のイメージは、コンサルファームで、高い期待に対して一生懸命結果を出そうとする、若手コンサルです。どこぞで読んだのですが、そういうコンサルは「今日できなかったことをリストアップして、毎晩振り返り、明日出来るようにする。わからないことはすぐに調べる」ことをしています。自分への期待に、プライドをかけて応えようとする仕事の仕方とでも言えばいいでしょうか。

実は、プライドで仕事する人というのは、実力的には一番伸びます(若手のうちは)。いわゆるプロフェッショナルの一素養だと思います。長い人生、若いうちに、一度は仕事に(よい意味で)はまってみるとよいと思いますよ!

なお、この「プライドで仕事をする」というのは、一時期は良いと思うのですが、長いこと、この仕事の仕方をすると、たぶん体が持たなくなります。また、自己満足でもあるので、ある程度成長したら、他の目的に切り替えるべきなのだと思います。その話はまた今度。
[ 2009/06/17 23:05 ] スキル強化・教育 | TB(0) | CM(0)

SMTと運用

SMT(同時マルチスレッディング)という技術があります。
CPUのコア数が急激に増えていますが、最近は、それ以上にCPU数が多いように見えることがあります。それは大抵、このSMTと呼ばれる技術です。例としては、Intelのハイパースレッドが挙げられます。

コア数が増えるのは分かりやすいのですよね。このSMTという技術の場合、CPUの実行ユニット(処理をするところ)の暇を無くすことを目指しています。実行ユニットって、忙しそう(CPU処理中)に見えて、裏では暇していることも多いのです。そこで、仮想的に実行ユニットを増やして見せて、裏で遊んでいるときは、処理をツッこんでしまえという技術です(乱暴に言うと)。図参照。つまり、コア数ほど効果は大きくないのです。Intelのページで、15%とか、そういう数字を見たことがあります。

ハイパースレッドの説明


たまに現場の笑い話で、「SMTをオンにしました。CPUが2倍見えました。性能が2倍になったと思ったのに、10%とか20%しか性能が伸びないんです。おかしいです」と言われたという話があります。たしかに誤解しやすいと思います。

見た目は数多く、実態としては数少ないというのは、最近のはやりです(SMTとか、VMとか、OSの論理パーティショニングとか)。

で、本題ですが、「CPU使用率が正しく出ない」ので運用がやりづらいという悩みがあります。CPU使用率が低いときは、取り合いにならないので、低い使用率なのですが、CPU使用率が高くなると、急に高い使用率になります。つまり、「今、XX%だから、あと何倍までOK」と言いづらいのです。詳しくは図を拡大して見てみてください(拙著から転用です)

CPU使用率が正しくない


なお、仮想マシンでも同様のことが起きます。性能見るのが、どんどん難しくなっていきますよね・・・困ったもんです。

※参照:Wikipediaの「同時マルチスレッディング」
[ 2009/06/14 23:01 ] アーキテクチャ | TB(0) | CM(1)

コンサルティングのマッチポンプ

マッチポンプという表現はご存じですか?
火をつけて自分で消すわけです。あれもやらなければいけない、これもやらなければいけないといって、危機感をあおり、火を消すために自分を雇いましょう(もしくは消してみせました)というやり方のことを言います。

一例として、SOX法やセキュリティベンダーのアセスを受けるとそういう思いをするかと思います。私の考えでは、これは、建前を全面に出さざるを得ないコンサル分野や、成長途中のコンサルタントで見られる・・と思います(あくまで私の考えです)。

私の思う、一流のコンサルは、必要なことは「こういう理由でここは割り切りましょうと言う(もしくは割り切るというオプションがありますと提示)する」コンサルです

つまり、以下のような段階があると思っています。

初心者            中級               一流(円熟)
あまりSEと変わらない  あれもこれもやらなきゃ  (全体を俯瞰して)これは割り切りましょうよ

私の知り合い(社外)と話をしていて、この日本人の体質(大騒ぎ)が金融機関の手数料高を招いていて、結局、消費者にツケがきているよね。という見解にいたりました。

新聞のニュースを見ていても、「正直言って、そこまでの完璧さは要らないじゃん」と思うような報道もあります。「そこでみんな叩くから、高いコストになるんだよ」と思います。
いち利用者として、寛容(あまり騒がない)のも大事だと思いました。
[ 2009/06/10 23:57 ] コンサル手法 | TB(0) | CM(0)

書評「企業情報システムアーキテクチャ」

今回は、南波幸雄さんが書かれた企業情報システムアーキテクチャの書評です。

この本を紹介するのは、企業レベルのアーキテクチャに関して、時代の流れに流されず、網羅的に書かれているからです。しかも、経験にも裏打ちされています(マネックスでCIOを長年勤めてた方です)。

お勧めする読者は、SEからITコンサルになろうとしている人でしょうか。もしくはSEとしてシステムをまたがった全体最適に悩み始めた人でしょうか。私の周りの若手ITコンサルにもお勧めしたい本です。

内容は多いので「これは」と思うトピックのみ
・アーキテクチャの定義・紹介が良い
・都市計画にたとえた全体最適やEAの紹介
・P107:アーキテクチャに基づくオープン分散システムの設計(全体図)
・概念データモデリングとサブシステム分割
<- ここら辺は世の中の資料が少ないんですよね。
・アプリケーションパーティショニング、非同期と同期、密結合と疎結合
・COTS、ERP、ASPに関する持論や割り切り


よくここまで網羅的に書いたなあと思う内容です。反面、それなりに経験を積んだITコンサルタントだと、「その先を知りたいんだよ」と思うかもしれません。また、値段は張ります(3800円)が、カバーしている範囲が広いので、買う価値ありですね。手島歩三さん(アーキテクトを目指すならこの人の本も読むべきだと思います)の思想を感じます。その意味でもお勧めです。
[ 2009/06/07 23:53 ] アーキテクチャ | TB(0) | CM(0)

自動undoチューニングについて

今回はちょっとコアなOracle使いのためのネタです。ORA-1555という言葉をご存じない方は読み飛ばしていただければと思います。

ORA-1555「スナップショットが古すぎます」を起こさないためのパラメータとして有名な、undo_retention(undo情報の保持秒数)パラメータですが、実は、最近のOracleは、自動的に保持時間をチューニングするため、このパラメータ以上にundo情報を保持することが多いのです。

でも、自動でチューニングしてほしくないときもあります(undo表領域に余裕を常にもたせたい、突発的な過負荷にも余裕で対応したい、undo保持時間が長いとトランザクションが重くなることもある、etc。。。)。そんなとき、マニュアルにも書いてあるワザ「表領域のアラート管理」を使います。

実はこの自動チューニングは、デフォルトだとundo表領域の85%(アラート閾値)のサイズまでundoを溜めこむように、チューニングするようになっています。この85%というアラート閾値を下げれば、自動チューニングの時間を短くできるのです(できるはずです)。

若干わかりずらいですが、以下のマニュアルが参考になります。
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/server.102/B19224-02/undo.htm#706531 (「デフォルトが85%」の記述もここにあります)

具体的には、DBMS_SERVER_ALERT.SET_THRESHOLDパッケージ・プロシージャ で85%という数値を変えられますよ!

●まとめ

・自動undoチューニングのため、undo_retentionの秒数よりも長めになることが多い。

・DBMS_SERVER_ALERT.SET_THRESHOLDパッケージ・プロシージャでチューニングをトライしてみるのも手。
[ 2009/06/03 23:07 ] DBA | TB(0) | CM(1)
プロフィール

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