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

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

ホーム > アーカイブ - 2008年09月

SQL DeveloperにERモデリング機能が付く!

OOWで発表されたことの1つに、SQL DeveloperにERモデリング(物理、論理)の機能が付くという内容があります。

SQL Developerについて解説すると、Object BrowserみたいなOracleの無償ツールです。開発者には結構お勧めのツールで、SQLやPL/SQLの開発のために結構使えます。Oracleにはビジュアルなツールが少なく、みなさんSQL*Plusで開発していたりするのですが、正直言ってもったいないです。
ご存知ない方は、OTN(日本語)のSQL Developerのサイトに行ってみましょう。SQLの作成・実行から、オブジェクトのブラウジングや定義の変更、PL/SQLのデバッグまでできます。

本題に戻って、ERモデリング機能についてです。私が歯がゆかったことの1つは、SQL ServerのERモデリング機能に相当するものがOracleに無かったことがあります。あの「ビジュアルに簡単にテーブルを作って、編集して、SQLを実行して・・・」がうらやましかったのです。しかし、今回のOOWにおいて、SQL Developerではあるものの、「グラフィカルなERモデリング機能が付く。しかも他のDBMSからの移行機能にも使える」という発表があったのです。次のSQL Developerのバージョンであり、まだ、ダウンロードはできませんが、出てくるのが楽しみです。OOWの会場では、ハンズオンのセミナーもあったようです(※)。

※:U.S. のOracleのサイトで、「SQL Developer modeling」で検索すると多少情報がでてきます。

脱線しますが、Object browserは相当便利なツールです。特に、データの生成機能がすごいなあと思います。リレーションを守り(データの整合性をとった上で)、ダミーデータを大量に作ってくれるのなんて、そう簡単にできません。痒いところに手が届くツールですよね。

早くSQL Developerの新版が出てくることを願ってます。
スポンサーサイト
[ 2008/09/30 08:59 ] DBA | TB(1) | CM(1)

Exadataについて(アップデート記事)

以前、U.S.の発表時の情報(プレゼンなど)を基にExadata( Oracle社が出したDWH用のアプライアンス )について書きましたが、今となっては情報が古くなったこと、誤解を招くことがわかったため、内容を修正します。今後はこちらの内容を見てください。
#今回の情報源はOTNのホワイトペーパーやFAQなどです。

Exadataのアーキテクチャ的な”売り”は、ストレージ側にOracleの気持ちを理解してもらうことです。通常、SQL処理はDBサーバー上で行われるわけですが、Oracleが欲しいデータをストレージに理解してもらって、可能なものはストレージ内で処理してもらおうというコンセプトです。これによりサーバーが処理すべきI/O量も減りますし、CPU負荷も減ります。

そういう意味では、以前からある、パラレルクエリーをイメージしてもらえれば理解しやすいと思います。パラレルクエリーでは、同一のDBサーバー内で手足となるプロセス(スレーブ)が立ち上がり、各々が並列に処理をして、必要なデータのみを大元のコーディネータに返すアーキテクチャでした。これのストレージ版のようなイメージです。

パラレルクエリーのイメージ:

  スレーブ -> -
            |
  スレーブ -> -+--> コーディネータ
            |
  スレーブ -> -

このようにOracleの都合を理解してもらうために、ストレージに専用のソフトウェアが搭載されます。このソフトウェアを「Exadata Storage Server Software」と呼ぶそうです。

コンサルタントの目で見ると、DWHの世界で”探索型”と呼ばれる、非定型でフルスキャンをがんがんやるような重いSQLが流れるシステムで、(特にI/Oのバスがきついシステムで)効果が見られそうです。DWHに最適化された、インテリジェントなストレージ、それがExadataということになります。
[ 2008/09/27 01:50 ] アーキテクチャ | TB(0) | CM(0)

Oracle OpenWorld2008始まります&DBA2.0に出ます

実は今日からU.S.でOracle OpenWorld2008が始まります。
昨年11gを発表したこともあり、今年は、DB関連での大きなネタは今のところ聞いていません(DB以外が当たり年みたいです)。もし、大きなネタがあったらBlogでも取り上げたいと思います。

現在のところ、OOWの情報は次のようなところから手に入ります。ざっと見ましたが、今のところ情報は少ないです。期間中になれば面白くなるかもしれません。

OOW内容一覧:
http://www28.cplan.com/cc208/catalog.jsp

Blog:
http://blogs.oracle.com/oracleopenworld/

Wiki:
http://wiki.oracle.com/page/Oracle+OpenWorld+2008?t=anon

DBAとして気になるなと思うのは、「Inside Oracle Database 11g Optimizer: Removing the Mystery」「Oracle VM Scalability and Manageability with HP」「Oracle Real Application Clusters Best Practices and Tuning in Oracle Database 11g (IOUG) 」といった技術的なセッション達で、11gやVMの話程度です(事前に分かっている範囲では)

以前、U.S.のOOWに行ったときの話をすると、「展示会というより、セッション中心」「各イベントは派手(ショーマンが来たりする)」「キーノートの会場が広く、観客が多い」「会場のごはんがおいしくない」といったところでした。技術情報は、日本のエンジニアのがんばりもあって、OOWに行かなくても皆様もほぼ同等の情報を手に入れられていると思います。

さて、 DBA 2.0 Days
~ Day1: 次世代データベース管理者への道 ~
(9/24)
というイベントがあり、これに出演することになりました。

概要は次のとおりです。
DBA2.0 Daysの二日間では、次世代データベース管理者が必要とする最新技術を、世界最大級のグリッド環境を備えたOracle Grid Centerにおける検証結果と併せて紹介します。
DAY1では、2つのトラックを用意し、データベース運用管理に関する最新技術の紹介および、アプリケーションを含めたデータベースシステムの品質管理に関する最新技術を紹介いたします。



何をやらされるのやら・・・・
[ 2008/09/21 16:25 ] DBA | TB(0) | CM(0)

定義する力、位置づける力

仕事柄、CIOもしくはCEOと呼ばれる方々(Cクラスとも呼ばれます)と会うこともあります。

そういう人たちに、テーマが何であれ、エンジニアが説明しているのを聞くと、違和感を感じることがあります。どうしても、エンジニアはロジックで語るためです。大抵は難解なロジックですし、分かりやすい説明であっても、あくまでロジックです。

私は、Cクラスと呼ばれる人たちとは、ほとんどロジックの話はしません。「課題XXは、このようにフェーズに分けて対処できます。現在は、このフェーズです」「この問題の本質はXXです」といった説明をします。もちろん、XXには「漏れ」「再利用がない」「スキルやノウハウ不足」など、ロジック以外の用語が入ります。

彼らはマネジメントしています。1つ上のレベルで物を見ています。それはエンジニアと同じ目線で物をみることではなく、プロセスや状態、方向を管理しているのです。そのため、詳細なロジックは必要ないのです(むしろノイズです)。
エンジニアには、「正しいプロセスで物事が動いていることだけを確認する」という発想は出てこない(気持ち悪い)かもしれません。しかし、「きちんと行われていることを確認する」という間接的な発想も必要です。CIOといった人の感覚からすると、「ロジックを理解してください」もしくは「すべての物事を直接確認してください」と言われることこそNGなのです。

Cクラスに対しての説明では、1段か2段、目線をあげて、「大きくくくるとこうなります。そして現在はここです」と説明しましょう。きっと皆さんに対して相手の反応が変わるはずです。

これが私が、定義する力、位置づける力と呼んでいるものです。
[ 2008/09/18 01:01 ] コンサル手法 | TB(0) | CM(0)

SQLって成功しすぎた言語かも

前回に続き、今回もSQLネタです。

SQLと普通の言語の最大の違いは、アルゴリズムを書かなくても動作することでしょう。「こういう条件のデータが欲しい」と書けば良いからです。楽ですね。

私が社内エンジニア教育をしていたとき、文系でコンピュータをほとんど触っていなかった新人たちでも、パズルのようだと言ってSQLを組み立てるのを楽しんでいました。

そのSQLの特性の功罪を考えてみたいと思います。
SQLという言語はインターフェースでもあります。RDBMSがはやった1つの理由だと思います。ほとんどのプログラミング言語でもSQLを使用できるのは、明らかにプラスです。

冒頭に載せたように複雑なアルゴリズムを書かなくてよいのは、とても大きなプラスです。SQLの実行計画を見ると分かりますが、正直、人間が簡単に考えられるものではありません。これを肩代わりしてくれるのは生産性の面で効果が大きいです。

マイナスはどうでしょう。マイナスの1つは、プログラムとの相性です。インピーダンスミスマッチと言いますが、そのままシームレスに(継ぎ目無く)プログラムからデータベースに格納/取出しができません。対策としては、O/Rマッピングでしょう。この技術もこなれてきたので、つかってみてよいと思います。

SQLが流行ったため、オブジェクト指向のDBが普及しなかった面もあると思います。あまりにも強い勢力をもったがゆえに、他の技術が影響を受けてしまった一例だと思います(オブジェクト指向の立場の人たちが、こういう考えを持っていたりします)。

最大のマイナスは、性能の保障がしづらいことです。大抵のエンジニアはコストベースの実行計画を嫌います。理由は、性能≒アルゴリズムが可変だからです。なぜこのようなことになっているかと考えると、それはSQLという言語が処理方法を記述しないからですね。
もう一度、最初から考えてみると、エンジニアはプログラムでロジックを考えます。しかし、SQLでは条件しか書きません。DBMSのエンジン任せです。そのため、SQLがどう処理されるかDBのプロ(DBAさんなど)が見て、初めて性能が分かるわけです。性能という意味でのリスクは元々大きいです。

今日の簡単なTIPSは、複雑な条件にしないことです。SQLは記述が楽なのでついつい安易に条件を追加したりしてしまいますが、複雑な条件は、重い処理を引き起こしたり、実行計画を良くないものにしがちです。条件をこねくりまわさないのは1つのコツです。

それと、上級者を目指すのであれば、プログラム全体の中でのSQLの動きを考えてみてください。言い方をかえると、SQLの動きまで含めて、プログラムの最適化を考えてみてください。これができれば一流です。一度チューニング済みのバッチ処理を早くしたい場合、私はこの方法をお勧めしています。経験上、バッチ(特に大幅に時間超過しているもの)は、SQLのチューニングだけでは解決しようがないケースが多いためです。
[ 2008/09/14 13:50 ] DBA | TB(0) | CM(0)

SQLは職人が書くもの?

今回は昔話から始まります。といっても最近DBを始めたばかりの人にも参考になります。

昔のプログラム開発では顕著でしたが、SQL部分のコーディングはSQLのスキルの高い人(職人)が書くべしとされていた時期(や開発会社)がありました。

昔は、今よりも使用リソースにシビアだった気がします。SQLがアクセスするブロック数を1つ減らすとか、CPU時間を数msec削るようなコーディングでした。
今はH/Wの性能が上がって、爪に火をともすようなチューニングはしなくなったと感じます。

でも、現在でもプロを目指すのであれば、少なくとも恥ずかしくないコーディングとチューニングは心がけましょう。
費用対効果がでなくなるほどチューニングする必要はありませんが、なんでもH/Wパワー任せで処理させていると、システムが大きくなったときやデータが多くなったとき、システムの改変をするときに自分(もしくは同僚)が痛い目を見ます。たとえば、不要なフルスキャン(しかもデータが将来増えるもの)はインデックスアクセスにする、といったチューニングは済ませておきましょう。

昔、ある人がいっていたのですが、『コップに水をぎりぎりまで注いで、コップをぴたっと静止させ、「大丈夫です」と宣言するようなまねはするな。何かあったらこぼれるだろうが』というのは今でもよく見かけます。自分はぎりぎりセーフでも、引き継いだ人のところで溢れてしまいます。

なお、実践にあたっては注意事項が2つあります。「きりのないチューニングはするな(目標を設定しろ)」と、「自分の体は自分で守ろう」です。性能問題が出てくるフェーズは終盤であり、疲弊していて、また労働時間も長くなっています。割り切ることも必要ですね。
おそらく、皆様は十中八九この状態にあって、満足なチューニングはできないと思いますが、体と相談しながらがんばってください m(_ _)m
[ 2008/09/10 17:57 ] DBA | TB(0) | CM(0)

TOC(制約理論)

今回はちょっと話を変えて、TOC(制約理論)についてです。
知り合いに岸良裕司さんというパワフルな方が居まして、私はその影響を受けてTOCも勉強・実践したりしています。社内でも自称CCPM(TOCのプロマネへの応用版)推進係をしています。

岸良さんが、「全体最適の問題解決入門」を出しました。今回はその内容をご紹介します。一言で言うと、「TOCの問題解決版。本気で取り組めば効果ありそう」です。
TOCというと、私は、ボトルネックを保護するとか、ボトルネックに従属させるとか、ボトルネックを改善するというイメージを持っていました。そのTOCを捨てずに問題解決までつなげています。
思い込みや人のサボりたい、迷惑をかけたくないという心理がいろいろなところで非効率を生みます。TOCは、それを目に見えるようにすることで解決していく手法だと私は思っています。

業務改善をしようとすると必ずと言っていいほど発生する「抵抗」もしくは「反対」。それを図(クラウド)に表し、実は思い込みであることや、他にも道があることや、思いは同じであることを示して、改善に巻き込んでいく、それを質問を主体として行うのが特徴です。TOCやCCPMのイメージで読み始めると、ちょっと意外な感じがします。でも、後半でTOCに自然とつながっていきます。

TOCやCCPMを読んだ事がない人は、「ザ・ゴール」や「目標を突破する 実践プロジェクトマネジメント」を読むことをお勧めします。そのあとの方が「全体最適の問題解決入門」が読みやすくなるでしょう。この本も分かりやすいのですが、正直言って、目標とするゴールが遠いだけに、これらの本でスタート地点を上げておかないとゴールにたどり着くのは厳しいと思います。それが「本気で取り組めば効果ありそう」の1つの理由です。

それともう1つの理由は「このような業務改善は、結局、現場の覚悟が必要」という点です。コンサルとして、いろんな現場を見て思うことは、軸となる人がいるかどうかによる、効果の違いです。どんなに方法が良くても、他人頼みのチームではなんともならない・・・というのが私の考えです。

なお、岸良さん(奥さん)のポップなキャラクターも健在です♪
私は「目標を突破する 実践プロジェクトマネジメント」の虫たちが好きです。なかでも「くれない虫」はいいですね。
[ 2008/09/07 22:23 ] コンサル手法 | TB(0) | CM(0)

メディアリカバリの注意点(TIPS)

■メディアリカバリの注意点(TIPS)

メディア(媒体)リカバリとは、バックアップなどを用いてデータファイルをリカバリすることを指します。

実は、いくつかのケースでは、リカバリが不要なのにもかかわらずリカバリが必要と勘違いすることがあるのです。今回はそのようなリカバリの落とし穴をいくつかご紹介します。

もっとも多く見聞きするのが、オンラインバックアップ中に何らかの事情でOracleが強制終了されたケースです。そのような場合、Oracleを起動すると「メディアリカバリが必要です」とOracleが言ってきますが、実はalter database end backup;を打てばデータベースは起動します。
リカバリが必要というメッセージが出たときには、まず「これではないか?」と疑うことは重要です。
たとえば、無理やりOS上でkillしてしまって、その後、DBが起動しないっ!とパニックになっている例を見たことがあります。

次に、書き込みI/Oが失敗し、データファイルがオフラインになっているだけのケースです。この場合もファイルをオンラインにするだけで復旧することがあります。
v$datafileで、statusがofflineの場合、次のようにオンラインにしてみましょう。
それだけで復旧すればめでたしです(ダメだったらリカバリです)。
alter database datafile <データファイル名のfull_path> online;

上記2点は、私からみると「リストアしてリカバリするのはもったいない」トラブルですから、覚えておきましょう。

次に、v$recover_fileとv$datafile_headerのご紹介です。こいつらはとっても便利です。v$recover_fileは、リカバリが必要なファイルを表示してくれます。また、v$datafile_headerは、データファイルのヘッダ情報を表示してくれます。これでチェックポイントと呼ばれる書き込みの時刻が分かります。まず、リストアした直後にこのビューをチェックしましょう。過去の時刻になっていることを確認します。この確認はリストア漏れ防止です。次に、リカバリしながらこのビューを見てみます。どんどん時刻が最新になっていきます。また、リカバリ後に起動できない場合もこのビューを見てみましょう。このチェックポイントが古く、最新ではない(=DBの一貫性が取れていないから起動できない)ことが判明することがあります。
なお、読み取り専用表領域などは、データを更新しないため、チェックポイントが古い場合があります。

最後に、リカバリでもったいない1つに、recover databaseコマンドを実行したけれどもデータファイルのステータスがofflineだったため、DBMSがそのファイルをリカバリしてくれなかったというものがあります(recover databaseの場合、offline状態のファイルは自動的にリカバリ対象外になります)。これも良く聞くトラブルであるため、前述のようにデータファイルのstatusには気をつけましょう!
[ 2008/09/04 21:58 ] 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冊としてお勧めです。