Oracle Database 11g Release 2に関する10の重要なこと – askTom Live -
Q&A

（ 目次 ）

Q&A

• Oracle Database 11g Release 2（R2）にアップグレードすると、システムを利用するエンドユーザーにとってどのようなメリットがありますか？

私たちシステム管理者にとってのメリットによりもたらされる効果が、そのままエンドユーザーのメリットとなります。
Oracle Database 11g R2の新機能「エディション・ベースの再定義」の機能を例に挙げましょう。以前はアプリケーションにパッチを当てる場合、事前に「メンテナンスのため、○月○日○時から○時までシステムを停止します」とエンドユーザーに通知していたはずです。Oracle Database 11g R2以降であれば、アプリケーションにパッチを当てるためにシステムを止めなくてもよいので、その必要はなくなります。稼動中のアプリケーションにパッチを当て、動作テストをおこなってから、新しいバージョンをカットオーバーするだけです。これにより、エンドユーザーは「ダウンタイムの短縮」というメリットが得られます。
その他の新機能も、多くのメリットをもたらします。たとえばOracle Active Data Guardは、ユーザーに意識させることなく、トランザクションを実行中のプロダクション・データから、リードオンリーの問合せをスタンバイ・データベースにオフロードします。
スタンバイ・データベースは、ほんの数秒前のプロダクション・インスタンスのコピーですから、プロダクション・データとほぼ同じように利用できます。この機能のおかげで、プロダクション・インスタンスとリードオンリーの問い合わせのパフォーマンスが改善されます。
SQL Planned Management機能を使えば、以前よりも格段に安全なOracle Database 11g R2へのアップグレードをおこなえるため、ここでも可用性の向上が実現します。
つまり、これらの新機能によって、可用性やパフォーマンスが大幅に改善されるのです。少なくとも、Oracle Database 11g R2へのアップグレード前よりも下がることはありません。

• トム・カイトさんは製品マニュアル「Oracle Database概要11g Release 2（11.2）」の執筆者の1人と聞きました。執筆にあたって苦労した点や、「とくにここを読んでほしい」というところがあれば教えてください。

私は、最新のOracle Database概要マニュアルを執筆した2人のうちの1人です。
Oracle Database 11g R2のマニュアルは、以前のバージョンのマニュアルを改訂したものです。その際に、私たちがもっとも時間をかけたのは目次、つまりアウトラインです。
Oracle8i DatabaseやOracle9i Database、Oracle Database 10gのマニュアルには、アーキテクチャのコンセプトに関する情報だけでなく、機能に関する情報もたくさん書かれています。これらは徐々に追加されたため、わかりにくくなり、すべての読者に役立つものとはいえませんでした。「Oracleデータベースを使うことになったときに、まず読むべきもの」ではなくなっていたのです。
私たちに与えられた課題は、「もともとコンセプトを説明していたものが機能説明書になってしまったので、再びコンセプトを説明するマニュアルに戻す」ことでした。
私たちは、情け容赦なく章立てを分解し、文章を削りました。その結果、500～700ページに及ぶ分厚い文書ではなく、400ページ強程度の比較的コンパクトなマニュアルになりました。
その一方で、内容面では「厚み」のある文書です。カバーしている範囲は狭くなったものの、その分詳しく説明しているからです。説明はよりわかりやすくなり、無駄な表現が減ったはずです。
私にとって一番嫌だったのは、講演で「これは絶対にやってはいけません」と説明したあと、参加者から「でも、オラクルのマニュアルには『こうするように』と書いてありました」と言われることです。こういったことは、以前はよくありました。現在のマニュアルには、このような矛盾した記述はなくなり、オラクルのコンセプトを表現した技術的に正確な文書になっています。
まさに、初出勤した新人スタッフに手渡すべき文書といえます。開発者やDBAにとっては、データベースがどう動くかの概要を知るための手引きになるでしょう。

• 現在、データベースのテクニカルサポートを担当しており、各種バージョンのOracleデータベースのパフォーマンス調査を実施しています。対象はOracle Database Standard Editionの場合が多く、現在はおもにSTATSPACKレポートを使用してTop5 Event、キャッシュヒット率、メモリパラメータのアドバイザリ情報の3つを確認し、調査や対処をおこなっています。また、アラートログに重大なエラーがないか、統計情報が更新されているかも調べています。おもな対処としては、統計情報を最新のものにする、初期化パラメータを変更するというパターンが多いです。
  上記のパフォーマンス診断と対処の方向性は正しいのでしょうか？
  より良いパフォーマンス診断、調査、対処の手順や方向性があればご教示ください。

これは難しい質問ですね。なぜなら、Oracle Database Standard Editionはあまり自動化されておらず、手作業に頼る部分が大きいからです。Oracle Database Standard Editionを採用しなければならない状況であれば、上記のパフォーマンス診断や対処法は、非常に正しいと思います。
じつは、これらの作業はまさに、Oracle Database Enterprise EditionにおいてOracle Enterprise ManagerやOracle Diagnostics Packなどで自動化しようとしているものです。それらから得られる情報により、データベースの「危険信号」を知ることができます。あなたは、これらのソフトウェアでできることを手作業でおこなっているわけです。データベース管理の自動化というのはOracle Database Enterprise Editionを採用する重要な理由の一つなのです。
歴史を振り返ると、現在人手で処理している作業は、いずれソフトウェアが肩代わりしてくれるようになります。「次に何をすべきか」を導き出すには、データに照らし合わせた際に一定のルールがあるからです。
PGA Aggregate Targetのアドバイザリ情報やSTATSPACKレポートから「パラメータを256ではなく512に設定すべき」とわかった場合、あなたは単にパラメータを変更するだけで、付加価値のある判断はほとんどしていないということになります。
チューニングという観点で私がお勧めしたいのは、できるだけソフトウェアを活用することです。これは、(チューニングは)もはや人手を煩わすようなことではなく、自動化できる作業なのです。私たちはデータベースにできない仕事、たとえばアプリケーションをどのようなアーキテクチャにするのか、どのような機能を採用するのかに集中すべきです。
講演のなかで、私は４つの手順を新機能を活用して１つのSQLで実行するコード例を紹介しました。データベースでは、4つの手順を1つのSQL文にまとめることはできません。これは私たち技術者にしかできないことです。データベース自身が、技術者の観点でコード内の手順を見て、どのような動きをしているかを理解して、作業を効率化できるようになるまでには、これから何度もバージョンアップを重ねる必要があるでしょう。
データベースはすべてのSQLの効率を認識し、索引、マテリアライズド・ビュー、SQLプロファイルなどを推奨してくれます。この部分で、私たちは何もする必要はありません。
ですから、ご質問にあるような作業を定期的におこなっているのであれば、Oracle Database Enterprise Editionの導入をお勧めします。
多数のデータベースの統合を考えているなら、チューニングに関してはOracle Database Standard Editionでは大変です。できるだけ多くのアプリケーションをインストールしたいわけですから、大量のSQLを見なくてはなりませんし、管理や監視にもかなりの手間がかかります。一方、10のデータベースを1つにまとめれば、ソフトウェアのライセンス費用の面で大幅なコスト削減になります。Oracle Database Enterprise Editionで調査などを自動化すれば、ほかの作業に時間をかけられるようになります。

• 長年Oracleデータベースのサポートをしている私から見て、Oracleデータベースが内部エラーとして「ORA-600」を出力するのは素晴らしい実装だと思います。一般的にはあまりイメージの良くないORA-600ですが、重大な障害を防止し、かつ出力されるトレースだけで問題を解決できるというサポータビリティの高さは、他に類を見ません。このように、ネガティブに捉えられているが、じつは「昔から他の製品にはない誇るべき機能」と呼べるものがほかにあれば教えてください。

最初にこの質問を読んだとき、思わず吹き出してしまいました。「ORA-600がオラクルの競争優位なポイント」「ORA-600はオラクルの強み」だと言っているわけですから、「おかしな見方だなあ」と困惑したのです。
しかし、よく読んでみると、実際にそのとおりだと思えてきました。
確かに、ORA-600が出力されるのはありがたくない事態です。しかし、それにより膨大な情報が得られ、原因を調べることができるのですから、その意味ではいいことだともいえます。
ORA-600は、V$TABLEと同様に重要かつ必要です。ORA-600の内容は、アプリケーションがどう動いているかを見るためのSQLトレースのようなものです。
ORA-600は、問合せを処理しているわけではなく、何かを表示しているにすぎません。何かがうまくいっていないことを示し、私たちが何かをおこなった回数を数えています。これらの情報によって、データベースを調査し、どこにボトルネックがあるかを突き止められるのです。
Oracle Database 11g R1やR2などの最近のバージョンでは、ORA-600の情報を使って一歩先に進むことができます。Oracle Database 11gには、Automatic Diagnostic Repository（ADR）という新しい機能があります。これは、ORA-600が発生した場合などに、インシデントに関連する情報をパッケージすることができ、関連するトレースやログ情報など、インシデント中に記録されたすべての情報などがパッケージされるのです。
Oracle Database 11g R1やR2に付属するADRによって、ORA-600も便利な機能になりました。言い換えれば、Oracle Database 11gではORA-600が新たな機能に生まれ変わったともいえます。
ORA-600のために追加料金を払う必要はありません。私たちは、ORA-600が発生した時には、関連する診断情報をパッケージして、すぐサービスリクエストをオープンしてサポートサービスに連絡できるように改良し、使いやすくしたのです。

• Oracle Database Standard EditionでOracle Real Application Clusters（Oracle RAC）を利用する場合、ストレージシステムとしてAutomatic Storage Management（ASM）が必須となっていますが、その他の構成でもASMを積極的に採用すべきでしょうか。また、冗長性を確保するためにストレージをRAID構成にする場合（外部冗長）が多いと思いますが、ASMによるミラーリングを積極的に推進すべきでしょうか。

最初の質問に対する答えは、もちろん「イエス」です。
そもそも、なぜOracle Database Standard EditionでOracle RACを使用する場合にはASMが必須なのかをお話しします。
私たちは、Oracle Database Standard Editionをご利用のお客様ができるだけカスタマーサポートの世話にならず、自分でインストールして迅速かつスムーズに製品を使っていただきたいと考えています。
ASMを採用しない場合、Veritasなど他社のディスク管理ソフトウェアを購入し、インストールと設定をおこなってOSやデータベース上で動くようにしなくてはなりません。その過程で、どうしてもサポートセンターに頼ることになります。けっきょく、インストール作業に数週間かかり、何度もサポートセンターに電話することになるでしょう。
これに対し、ASMを使えば、ソフトウェアのインストールにそれほど時間はかかりません。私たちはすでに何千回もインストールを繰り返し、問題なく動作することを確認していますから、朝作業を始めれば午後には使えるようになるでしょう。また、Veritas用のパッチやデータベース用のパッチなども必要ありません。ただインストールするだけで終わりです。
つまり、Oracle Database Standard EditionでOracle RACを使用する際にASMが必須である理由は、そのほうがインストールや設定が簡単だからなのです。それはOracle Database Enterprise Editionでも同様ですが、こちらは他社のソフトウェアを使うこともできます。ただし、クラスタ環境の場合はOracle Database Enterprise EditionでもASMを採用することを強くお勧めします。
クラスタを利用しないシングルインスタンス環境であれば、通常のファイルシステムとASMのいずれかを選択することができます。この場合でも基本的にはASMをお勧めしますが、Oracle RACの場合ほどに強く推奨するわけではありません。
ファイルシステムを使う場合は、ASMの管理機能によってもたらされるメリットのいくつかを享受できませんが、これはお好みによります。クラスタを使用しない場合には、おもに手軽さの面でファイルシステムが推奨されることもあります。

もう1つの質問は、データのミラーリングについてです。 ASMには2つの機能があります。1つは、データのストライピングです。ASMは常に情報をストライピングします。ですから、ストレージ側で情報をストライピングしていても、ASMはストライピングを実行します。しかし、そのこと自体は問題ありません。 RAID5などの機能をもつストレージ・ソリューションが、RAID機能をオフにできない場合は、そのままRAIDによる冗長化を用いてもまったく問題はありません。ただし、純正レベルの最高のパフォーマンスは得られません。 もしRAIDをオフにできるのであれば、ASMによる冗長化をお勧めします。そのほうが、どのデータベースのどのディスクをどのように使うかといったきめ細かいチューニングがおこなえ、より管理性が高められるからです。ASMの障害グループを、データベースの利用状況に合った、より理にかなった形で設定することができます。 つまり、もしASMで冗長化できるのならそのほうがよいのですが、できなくても問題はありません。ただ、その場合はASMほどのパフォーマンスは期待できません。

• クラウド・コンピューティングのための技術として、Key-Value Store（KVS）やMapReduceなどの新たなNoSQLデータストアが登場しています。RDBMS（リレーショナル・データベース管理システム）はスケーラビリティに限界があるため、そのような新しい方法が必要だといわれています。 そういった意見について、どう思われますか。RDBMSはクラウド・コンピューティングのスケーラビリティに対応できないと思いますか。

これはよく訊かれる質問です。最近、「NoSQL運動」のようなものが広がっているようですね。「SQLは良くない」「SQLには拡張性がない」「リレーショナル・データベースはもう終わりだ」などという声も耳にします。
この話は、1995年、Informix社が、「次の時代はオブジェクト指向だ。オブジェクト指向がリレーショナル・データベースを駆逐する」などと宣言してIllustra データベースを発売したときにまで遡ります。そして今は、「クラウド・データベースがリレーショナル・データベースを駆逐する」「KVSがリレーショナル・データベースをやっつける」と言われます。
Key-Value Storeとは何でしょうか？ KVSデータベースはnameとvalueで構成され、ある種のアプリケーションできわめて有効です。
たとえば、私がAmazon.comで買い物をしているとしましょう。Amazon.comのショッピングカートでは、KVSがたいへん役立っています。
Amazon側は、顧客がどの商品をいくつショッピングカートに入れようとしているか、明確にはわかりません。商品によってはデータ構成も異なります。このようなきわめて自由度の高いデータ構成が必要なAmazonには、KVSがぴったりなのです。
また、KVSに対する検索要求が、Amazonの用途にマッチしていることも理由の1つです。
Amazon.comでのショッピングカートの使い方は、「今、私、トムのショッピングカートの中には、何が入っているのか」がわかればいいのです。Amazon.comでは、「今現在、いくつのショッピングカートの中に『赤い靴』が入っているか？」といった、複数のショッピングカートに対して問合せをおこなうようなビジネス分析はしないのです。
このため、Amazonではデータを分割して何百万もの小さなスペースに格納することができます。トムのショッピングカートがどこにあるのかさえわかっていればいいので、この方法は非常に有効です。
もし、「2日前、いくつのショッピングカートに『黄色い箱に入った青い靴』があったか」を知ろうとすれば、ビジネス分析の領域になります。この場合はKVSではうまくいきません。リレーショナル・データベースの出番です。
Amazon.comでは、チェックアウトした際に顧客の注文情報はKVSデータベースに保存されません。そこには、行や列が登場するため、そういった情報はリレーショナル・データベースに格納されます。
私たちは、KVSとリレーショナル・データベースの両方を理解しています。
Oracleデータベースには、 Oracle Application Express（Oracle APEX）というアプリケーション開発環境があります。これはPL/SQLで作られています。じつは「Ask Tom」も、Oracle APEXを使って作成しました。
Oracle APEXの中枢には、セッションID、name、valueの表、すなわちOracleデータベース内のKVSがあります。つまり、Ask TomはKVSを使っているのです。
私たちはKVSを、セッション状態の維持に活用しています。質問と回答、閲覧状況などの保存には使いません。
私には、セッション状態の属性を知る必要はありません。いつ誰かが新しい画面を追加するかもしれません。セッション状態の数は多く、自分で管理できる範囲を超えています。すべてをカバーできる数の表をデータベースに作るわけにはいきませんが、KVSなら対応できます。
しかし、画面から画面への遷移、クエリーデータなどについては、行や列に格納されています。
私たちには、両方のタイプのデータベースが必要です。どちらかだけでは足りません。一方が正しい場合もあれば、もう一方が正しい場合もあるというわけです。

• OLTP処理を高速化するには、「 In-Memory Database Cache」の機能が有効と聞きました。In-Memory Database Cacheを構築するだけで、その恩恵は受けられるのでしょうか。In-Memory Database Cacheを最大限活用するために、とくに気をつけなくてはならないことはありますか。アプリケーション設計やSQLコーディングで考慮すべき点があれば教えてください。
  また、Oracle Database 11g R2の新機能の1つである「In-Memory Parallel Query」もOLTP処理の高速化に役立つ機能なのでしょうか？

次の質問は「In-Memory Database Cache」、「Oracle TimesTen In-Memory Databse」についてです。これは、オラクルが新しい技術をデータベースに取り入れている好例です。
Oracle TimesTen In-Memory Databaseを実行エンジンに持つIn-Memory Database Cacheを使うだけで、OLTP処理を高速化することができます。
では、In-Memory Database Cacheを使ううえで、考慮すべきことは何でしょうか。この機能が必要かどうかを判断するうえで、何を見るべきなのでしょう？
インメモリ・データベースは、問合せを処理する際のレスポンス時間を保証してくれます。
通常、たとえばデータベースにあるSQL問合せを送った場合、その処理にどれくらい時間がかかるかは正直にいうとわかりません。すべての索引データとバッファキャッシュ、すべての索引データとバッファキャッシュを見つけられて、ネットワークも非常に空いているときは、1,000分の1秒で回答が返されるでしょう。次に、まったく同じデータに対し、まったく同じ問合せを送ったとします。今度は、誰かが大容量データの検索を開始したことで、索引データとテーブル上のデータがバッファキャッシュからこぼれ落ちていたとします。すると、前回よりもネットワーク内を行き来するのに時間がかかるうえ、問合せ処理もバッファキャッシュから読むのではなくハードディスク上のデータにアクセスするため、100倍の時間が必要になります。その結果、前回は1,000分の1秒だったのに、100分の1秒または10分の1秒もかかってしまいます。
実際は、パフォーマンスのグラフはこのようになるでしょう。

画像クリックで拡大します

リレーショナル・データベースの問合せ処理時間は、赤い線のようになります。とても速いときと、とても遅いときがあるのがわかります。頻繁に遅延が起こり、レスポンス時間を保証することなどできません。
インメモリ・データベースでは、ディスク処理による遅延を避けられます。アプリケーションのすぐ隣にインメモリ・データベースを置くことで、突然レスポンス時間が図の青い線のようになるのです。多少の上下はありますが、ほとんど直線といっていいでしょう。
赤い線と青い線は、ときどき交差していることにも注意してください。リレーショナル・データベースは、インメモリ・データベースと同じくらい高速なことも多いのですが、処理時間に大きな幅が見られます。
ですから、もしアプリケーションに遅延が多い、レスポンス時間に幅があるといった問題を抱えているなら、インメモリ・データベースを検討するとよいでしょう。
インメモリ・データベースを検討している方は、まずこのグラフを思い浮かべていただきたいと思います。この赤い線を、青い線に変えることができるのです。

Oracle TimesTen In-Memory DatabaseでOracle Database 11gの技術を取り入れたポイントとしては、それぞれのSQLに互換性をもたせたことが挙げられます。今では、Oracle Databaseデータベース向けにつくったアプリケーションで記述したSQLをOracle TimesTen In-Memory Databaseでも実行できます。また、すべてのデータタイプをOracle TimesTen In-Memory Databaseに実装したので、Oracle TimesTen In-Memory DatabaseはVARCHAR2などのデータ型をもっています。
もう1つは、最近Oracle TimesTen In-Memory DatabaseにPL/SQLを実装しました。100%の実装ではありませんが、ほとんどのPL/SQLが使えます。今では、PL/SQLで作成したものを、そのままインメモリ・データベースで実行することができます。
3点目は、Oracle TimesTen In-Memory DatabaseのインタフェースをOracle Call Interface（OCI）にしたことです。これはC言語のAPIで、JDBCやODBC、PHP、ODP.NET、Rubyなどの主要なドライバの大半が組み込まれています。これらのアプリケーションを使ってOracleデータベースを動かすことができるのです。ほとんどの場合、Oracle TimesTen In-Memory Databaseに接続を変更するだけで、そのまま動作します。
マルチバージョン読取り一貫性などの主要な機能も、もともとOracleデータベースのコンセプトであったものをOracle TimesTen In-Memory Databaseでも持っています。ですから、トランザクション上は、Oracleデータベースのように動作します。
Oracle TimesTen In-Memory Databaseの機能をOracleデータベースに応用したケースもあります。Oracle Database 11gでは、一部をデータベース内のインメモリ・データベースに置いたサーバー・リザルトキャッシュがあります。クライアントサイド・リザルトキャッシュも、クライアント・アプリケーションに、前述のグラフの青い線のような効果をもたらします。
講演の中でお話しした「In-Memory Parallel Execution」は、使用されるシーンは全く違います(OLTPではなく大量データ検索などのDWH処理)が、Oracle TimesTen In-Memory Databaseのコンセプトを借りて開発された技術です。

• 「Oracle Database 11g でLOB（ラージオブジェクト）のパフォーマンスが向上した」という記事をよく見かけますが、今後はRAW型ではなく、常にBLOB（バイナリ・ラージオブジェクト）を使えばよいのでしょうか。 また、CLOB（キャラクタ・ラージオブジェクト）についても同様に、パフォーマンスを考慮してVARCHAR2(4000)を使用する必要はないのでしょうか。

LOBとRAWに関する質問ですが、答えはいたって簡単です。
もしバイナリ情報があるならば、その格納はBLOBを使いましょう。ただしバイナリ情報が常に2,000バイト以下なら、RAWを使うべきです。常にそれより大きい場合は、BLOBを使いましょう。
この質問者も多分そうだと思いますが、トランザクションのアプリケーションにおいては、データが小さいデータタイプに合わない場合にのみ、大きなデータタイプを使います。
ですから、もし4,000文字以上のフィールドが必要な場合は、列を2つ使ったりしないようにしてください。VARCHAR2(4000)を2つではなく、CLOBを使うのです。そうすれば、表から2,000文字のデータを取り出してほかのセグメントに移すことができます。そして、データを取り出す必要がある場合でも、また1つにまとめることができます。データベースの表そのものではないので、スキャンも高速ですし、行もコンパクトで済み、ブロック内により多くの行が入れられます。全体的なOLTPアプリケーションのパフォーマンスも向上します。
VARCHAR2に入れられる場合には、そちらを使いましょう。VARCHAR2に入らない場合、わざわざ複雑なことをして3～4つの列を作ったりするべきではありません。こういった方法をとるケースは、割合頻繁に見受けられます。16Kのデータを格納しなくてはならない場合に、5つのVARCHAR2(4000)列を使うとしましょう。
そうなると何十行ものコードを使ってデータをまとめ、それをまた分解するようになります。このような複雑な実装は正しい方法とはいえません。

• オラクルの認定資格「ORACLE MASTER Platinum（Oracle Certified Master:OCM」は、日本では非常に高く評価されており、転職に際して有利に働いたり、収入や報酬に反映されたりすることもあります。
  米国では、ORACLE MASTER Platinum（OCM）はどのように評価されていますか？　また、トムさんはORACLE MASTER Platinum（OCM）を取得していますか？
  どうすれば、より高度なOracleデータベース技術者、データベース・アーキテクトになれるか教えてください。

これらの資格は、日本だけでなく、米国や欧州など、私が行ったことのある国のほとんどで大変高く評価されています。
私が考えるORACLE MASTER Platinum（OCM）やORACLE MASTER Gold（Oracle Certified Professional: OCP）の意味とは、「新しいテクノロジーの知識を持っていることを表すもの」です。つまり、自分の知識を、常に新しいテクノロジーに合わせてアップデートしていることを示します。
もしあなたがOracle9i Databaseの資格をもっていて、職場ではOracle Database 11gが使われているとします。その場合、周りからは「本当に最新技術に追いついているのか？」「新しい機能を学んでいるのか？」「新しいソフトウェアがどう変わって、どうやって活用するか知っているか？」という疑問を抱かれるでしょう。
私自身がオラクルの資格を取得しているかとのご質問に対する答えは、「いいえ」です。私はこれまで、資格を取る必要性を感じたことはありません。なぜなら、私の仕事は常にデータベースの進化についていくことであり、新しい機能に関するトレーニングは真っ先に受けているからです。オラクルのなかで働いていると、資格を取ることがそれほどアドバンテージにはならないのです。
もし私がオラクルを離れ、コンサルタントとして独立したら、「Oracle Database 11g Release 2と、それ以前のバージョンについて何でもわかります」ということを示すために、真っ先に資格を取るでしょう。そして、バージョン12が出たら、今度はその資格を取得するでしょう。こうして「少なくとも私はトレーニングを受けているので、バージョン12について知っているし、新しい機能についても知識がある」ことを表します。まだ実際に使ったことはないとしても、少なくとも知識は持っており、使い方もわかっていると言うためです。
コンサルタントではなく、開発・運用の現場で仕事に就こうとする場合にも、資格は有利に働くかもしれません。資格のある人とない人が面接を受けるとしたら、優位に立てるのは前者です。
つまり、自分がどんな仕事をしているのかによるのです。もし、今後20年間同じ仕事を続けるのであれば、資格は必要ないかもしれません。しかし、職場を変わって昇給を目指すのなら、資格があると便利でしょう。
この資格は、非常に厳しいものです。私も試験そのものに関わったことがありますが、とくにORACLE MASTER Platinumなどは、けっして簡単なものではありません。内容が非常に濃くて難しいので、この資格をもっていれば、中身を本当に熟知していることを証明するものです。
米国はもちろん、欧州でもこの資格は高く評価されています。とくに、独立したコンサルタントにとってはそうでしょう。
もし5人のなかからコンサルタントを選ぶとして、2人が資格をもっているなら、残りの3人は個人的な知り合いでもない限りほとんど無視されてしまうでしょう。少なくとも資格をもつ2人については、「使ったことはないかもしれないが、トレーニングを受けている」という情報が得られるからです。

どうすれば、優秀なOracleデータベース技術者、データベース・アーキテクトになれるでしょうか。私のやり方は、フォーラムやユーザーグループ、カンファレンスに参加することです。
このようなイベントに参加することで、私はオラクルについて毎日新しいことを学んでいます。ちなみに私はオラクルコーポレーションで23年間働いていますが、いつも発見があります。
ほかの人の質問や、時には回答から学ぶこともしょっちゅうです。Ask Tomに質問をするエンドユーザーは、「彼らの知らなかったことが何か」を教えてくれます。他の人が同じ質問をしたときには、私が教えてあげることができます。
このようなフォーラムやディスカッション・グループに参加することで、あなた自身が普段得るものとは違う答えを得ることができます。なぜなら、データベースについては、同じことをするのにも何百通りもの方法があるからです。どんなことでも「唯一の正解」はなく、時と場合によるのです。
もしあなたが5年間、同じ相手と同じバージョンのデータベースを使って1つの仕事をしているのなら、5年前と比べて知識はまったく増えていないでしょう。しかし、これらのグループに参加すれば、たくさんの新しいアイデアに触れることができます。
また、違う仕事に携わりさまざまな経験を積むことも良い方法でしょう。もしあなたが過去10年間、運用管理担当のDBAだったとしたら、次の1年間は設計開発担当のDBAを志願してみるのも良いでしょう。まったく違った環境で、新しいスキルが得られるでしょう。最初はひどくいらだたしい思いをするかもしれませんが、1つの問題に対して違った見方ができるようになるはずです。
もしあなたが開発者であれば、Web上にあるドキュメントを開いてみてください。
Oracle Technology Networkにある、新しい製品マニュアルの第1章を見てみましょう。通常、第1章はWhat’s Newです。たとえば「‘管理者ガイド」の第1章を読めば、データベース管理において、このバージョンでは何が新しくなったかがわかります。
また、「SQL言語リファレンス」を見ると、Oracle Database 11g R2（11.2）のSELECT文における新機能がわかります。
このような新機能を知る方法は2つあります。1つは、SQL言語リファレンスのなかの”Select”のページを探し、そのダイアグラムを見てみます。SELECTのシンタックスが表現されています。これはだいたい30ページくらいです。すべてを暗記したあとで、頭の中で新しい図と合体させてみると、SELECT文で新しくなったことがわかります。
または、第1章を見れば、私たちがSELECT文に何を追加したかがわかるようになっています。すべての変更は製品マニュアルに書かれていますから。
もし、過去3～4年、新しい製品マニュアルをまったく見ていないのであれば、今すぐご覧になることをお勧めします。
新しいバージョンが出ると、私はまず、興味のある分野の新しい製品マニュアルを開いて第1章を読みます。データウェアハウスの分野やデータベース管理の分野、アプリケーション開発で何が新しくなったかなどがわかります。
私が新機能を知るのは、いつでも製品マニュアルからなのです。

▲ ページTOPに戻る

Thomas(Tom) Kyte (トム・カイト）
2000年にAsk Tomブログ( http://asktom.oracle.com ) を開設して以来10年にわたり、全世界のオラクル技術者のありとあらゆる質問に答え、データベース技術の活用を世に広めてきた世界的に有名なエバンジェリスト。