現在地

第1回 Oracleで失敗しないコツ


さて、第1回はOracleで失敗しないコツです。筆者は、Oracle7に始まり、今まで20年近くOracleデータベースにかかわってきました。そのあいだ、インターネットは当たり前になり、ハードウェアは高性能化・大容量化し、だれでもスマートフォンや携帯を持つようになりました。コンピューティング環境は、まったくと言っていいほど変わっています。

それと同時に、十分ではないけれどソフトウェア工学は進歩し、Oracle技術者も圧倒的に増えています。昔と比べれば周辺環境は圧倒的によくなっているはずです。
にもかかわらず、トラブルを抱えたプロジェクトは、それなりの割合で発生しています。マネジメント要因のものは人や組織の問題なので除外するとしても、原因の多くは、今も昔もあまり変わっていないように感じます。代表的な原因を挙げてみます。

よくあるトラブルの原因

不十分な知識、間違った知識によるもの
ここに分類されるものには「単純な知識不足によるもの」「DBMSの違いを認識していないことによるもの」「昔の常識や思い込みによるもの」などがあります。
Oracleには数多くの機能があります。またバージョンによっても機能は違います。使いこなすためには、Oracleのアーキテクチャーを理解し、またターゲットとするバージョンの機能を理解する必要があります。たとえ実績のあるベンダーでも、初歩的なミスや勘違いによる障害を見かけます。製品を活用するために十分な教育コストはかけるべきです。
また、他DBMSからの移行の場合、同じ用語や似た用語であっても、DBMSが違うとまったく違うものを指していることがあります。たとえば同じ「データベース」という用語でも、OracleとSQL Serverではまったく意味は違います。
いちばん厄介なのはベテラン選手の思い込みです。本人に自信があるだけに、対話だけでは簡単に解決しません。Oracleは日々進歩しています。昔の常識が今でも通用するとは限りません。とくにパフォーマンス系のテクニックや常識は、かなり疑ってみるべきです。筆者はたまにベンチマークをやりますが、「昔の常識」や「昔のベンチマーク結果」が、激変しているのに愕然とすることがあります。最近一番驚いたのは「定期的にインデックスを再編成する必要性は少ない」ことです。
実績の少ないシステム構成、サポート外のシステム構成によるもの
Oracle社は、サポートする各ソフトウェアの動作環境やソフトウェア同士の接続性を公開しています。この条件に合致してない場合はサポート対象外になります。この場合のサポート対象外の意味は、実際に動くかどうかとは関係ありません。その環境でトラブルが起きても問い合わせの対象外になりますよという意味です。
Oracle RACの場合は、さらにシステム構成が複雑になるので、信頼のおけるベンダーと十分に調整することをお薦めします。オラクルに詳しい方にとっては常識のようなことですが、今まで決して少なくない数に出会っています。
誤ったデータベース設計によるもの
データベース設計が悪いことによって、データに不整合が発生したり、十分なパフォーマンスが出なかったりすることがあります。リレーショナルデータベースはリレーショナルデータモデルに基づいたものなので、リレーショナルデータモデルらしい設計が必要です。
近年はKey-Value型データベースやJSONデータの普及によって、正規化をおろそかにする場面もあると思います。それでもメリット・デメリットを十分に考えたうえで、論理設計・物理設計してください。正規化しないならば、それなりの理由づけをして、エビデンスとして残すことをお薦めします。
データベース設計に関しては下記の書籍がお薦めです。また3)の著者であるジョー・セルコ(Joe Celko)氏は、データベース設計に関する多くの著書があります。現時点(2014年9月)では翻訳されていませんが、興味のある方は探してみてください。
  1. 「SQLアンチパターン」(Bill Karwin(著)、和田 卓人、和田 省二(監訳)、児島 修(訳)、オライリージャパン、2013年1月)
  2. 「達人に学ぶDB設計」(ミック(著)、翔泳社、2012年3月)
  3. 「プログラマのためのSQL 第4版」(ジョー・セルコ(著)、ミック(監訳)、翔泳社、2013年5月(第4版))
誤ったアプリケーション設計によるもの
パフォーマンスのトラブルを抱えているシステムで一番困るのが、アプリケーション設計やSQLなど、アプリケーション側に問題があるケースです。具体的には、本来PL/SQLで記述したほうがよい処理を、DBと疎結合という理由だけでロジックをAPサーバー側で持ったり、適切なコネクション管理をしていなかったりする場合です。
開発フェーズの後ろになるほど修正にかかる工数は増大します。とくにアプリケーションが完成したあとで、チューニングできることは限られます。今までのチューニング経験でも、アプリケーション設計に起因した問題に突き当たり、大した成果を上げられなかったことも少なくありません。
設計に関しては、アプリケーション特性に依存する部分が多いので、前提条件なしに「絶対に○○○すべき」とは言えません。それでもプロジェクト毎に適切な方針を決め、有識者に随時レビューしてもらうことをお薦めします。
未熟なSQLによるもの
SQLは、初心者とエキスパートではパフォーマンスの差が出やすい言語です。初心者では、複数のSQLとプログラムロジックを使って書いたプログラムを、エキスパートは単一のSQLでシンプルに書き上げてしまうこともあります。SQLを直接書く場合には、コーディング規約を作るのは当然のこと、十分なSQL教育が必要です。場合によっては、SQLを書く開発者を限定したほうがよいかもしれません。
近年はHibernateやJPAなどのO/Rマッパーが持つ自動SQL生成機能を利用して、SQLを直接書かないこともあります。OLTP系のシステムでは十分なことも多いのですが、データウェアハウスなどの分析系のシステムでは最適なSQL文を生成できないこともあります。このあたりはシステムに応じて柔軟にコーディング規約を決めたほうがよいでしょう。
少ないデータ量によるテスト
パフォーマンス問題が後で発覚する典型的なパターンです。とくに納期の短いプロジェクトではコーディングに集中してしまい、開発時に十分なテストデータを利用していないことがあります。
データの自動生成&ローディングツールなどを用意して、大量データで簡単にテストできる仕組みを用意すべきです。データの生成・ロードだけならば、スクリプトだけで作れます。またOracle Real Application Testingといったテストを支援するツールもあります。
テストデータで悩ましいのが、その内容(質)です。過去の経験では、ハードウェアもアプリケーションもデータ量もほぼ同じだったにもかかわらず、本番環境と検証環境ではまったく違うパフォーマンスになったことがあります。調べたところ、本番環境と検証環境では使用していたデータ特性が違うことが原因でした。セキュリティ度が高いデータの場合、簡単な解決策はありませんが、データ特性によってパフォーマンスが大幅に違う可能性があることは心に留めておくべきでしょう。データ特性でいえば、インデックスを張るような列は、同程度のカーディナリティにする必要があります。
検証環境がない
コスト削減のあまり、本番環境と同等の機能を持った検証環境がないことがあります。検証環境がないと、システムの変更はぶっつけ本番になり、本番環境の稼働に影響を与えてしまう可能性があります。
そういえば映画「アポロ13」では、宇宙船にトラブルが起きたとき、NASAは地上にある同じ宇宙船を使って対応策を考えていましたね。あれと同じ対策が必要です。
実際のところ、ある程度重要なシステムで検証環境がないことは少数派でしょう。とりあえず仮想マシンがあれば、ミドルウェアやアプリケーションレベルでは検証の役目を果たせます。それでも本番環境が物理サーバーだった場合、デバイスドライバーなどカーネルレベルの操作や、ハードウェア回りの設定など、物理サーバーでしかできない操作もあります。本番環境が物理サーバーならば、多少スペックは落ちたとしても、検証環境も物理サーバーにするのが理想的です。
また長い間運用していると、本番環境と検証環境で設定が異なってしまうこともあります。同じ設定になるような運用ルールを決めるのと同時に、定期的に差異がないことをチェックしたほうがよいでしょう。

成功するために心掛けること

こんどは成功するためという視点で書きます。長くなったので、サポートや教育など、これまで触れていない部分を中心に紹介します。

サポート情報を活用すること
Oracle社の有償サポートサイトMy Oracle Supportは、FAQ情報の参照やパッチのダウンロードだけではありません。Get Proactive(事前に対策を講じておこう)というページでは、予防・解決・アップグレードなどに必要なコンテンツがまとまっています。また導入におけるベストプラクティスを集めたコンテンツもあります。このあたりの情報は、作業を実施する前に、ひととおり目を通すことをお薦めします。
マニュアルをちゃんと読むこと
サーチエンジンが発達した結果、わからないことがあったら、何でもサーチエンジンで調べてしまう人が多くなりました。サーチエンジンを使うことを否定はしませんが、サーチエンジンの場合、ヒットした情報の正しさは玉石混交です。
Oracleのよいところは、メーカーが提供している正規情報の圧倒的な多さです。Oracleにはたくさんのマニュアルがあり、サポートサイトで提供しているナレッジも膨大です。情報を正しく取捨する能力が付くまでは、製品マニュアルやMy Oracle Supportのナレッジ、KROWN情報を積極的に読むことをお薦めします。
積極的に英語情報を読むこと
真剣にOracle製品に付き合うならば英語は欠かせません。データベースのマニュアルはほとんど日本語化されていますが、翻訳されていないものもあります。またMy Oracle Supportのナレッジは英語で書かれたものの方が多くあります。市販書籍についても、洋書によいものが多いので、英語を読む習慣をつけましょう。英語を読む習慣は、今後のエンジニア人生できっと無駄にならないはずです。
教育サービスを活用すること
わたし自身、初めてOracleをさわったときには、マニュアルの厚さや機能の難しさに苦労しました。いまと比べればはるかに機能の少ないOracle7にもかかわらずです。昔は有識者がいなかったことや、初心者向けコンテンツがなかったことにも起因していますが、初めて研修コースに参加したときは、そのわかりやすさに驚きました。
実戦経験も大切ですが、それはある程度基礎があってのことです。教育サービスのよさは、正しい知識を比較的短期間に習得できることです。研修費用を払ったとしても、その分、短期間に習得できればトータルでは安くなる可能性もあります。メリットとデメリットを理性的に判断することが重要です。
適切な製品選択、バージョン選択
Oracle製品にはプロダクトのライフサイクルがあり、それぞれサポート期間が定められています。新しいバージョンは障害が多いという思い込みで、古いバージョンに固執するのはナンセンスです。「システムのカットオーバー時期やライフサイクル」「サポート期間」「製品の旬なバージョン」などを総合的に考えて、製品やバージョンを選択してください。
有償サポートを活用すること
予算が少ないことを理由に「有償サポートを契約しない」もしくは「システムがカットオーバーしたあとは契約を更新しない」というケースをたまに見かけます。結局あとでトラブルが発生して、混乱状態に陥ることは珍しくありません。そのときに問題が解決できない、もしくは解決できても非常に時間がかかれば、直接かかった工数や機会損失金額は莫大です。
有効な場面は、トラブルに関するものだけではありません。My Oracle Supportには膨大なナレッジが蓄積されています。推奨事項やチューニングなど、開発に役立つ専門家のアドバイスも受けられます。パッチには、アプリケーションの動作に影響の少ないCritical Patch Updateというセキュリティの集積パッチもあります。トラブルのときだけでなく、もっとサポートセンターを活用してください。
サポートツールを活用すること
有償サポートユーザ向けサイトのMy Oracle Supportでは、ORAchk, OSWatcher, TFA Collector, RDA, sqlt, sqlhcなどの、OSやDB、SQLの情報収集・分析ツールを提供しています。これらのツールを使うことで、問題となりそうな個所を事前に発見したり、簡単に情報収集したりできるようになります。
それぞれのツールの詳細はサポートサイトをご覧ください。とりあえず使ってみるならばORAchkやOSWatcherがお薦めです。
トラブル時に分析しやすい設計
Webアプリケーションのような複数階層システムでは、クライアントからアプリケーションに接続するセッションと、アプリケーションからデータベースに接続するセッションが異なるため、クライアントの動作を追跡することは困難です。単体のSQL文でしか追跡できない場合、問題はどこにあるのか、修正するべき個所はどこなのか、といったことがわかりづらくなります。
DBMS_APPLICATION_INFOやDBMS_MONITORといったパッケージをあらかじめ利用していれば、アプリケーションのドコに問題があるのか追求しやすくなります。これらの詳細は「Oracle Database開発ガイド」「Oracle Database SQLチューニング・ガイド」をご覧ください。
パッチの適用を考慮に入れた運用設計
Oracle社は定期的にパッチを適用することを推奨しています。それは既知のバグに遭遇しないためや、今後提供されるパッチを適用しやすくするためです。可能であれば、パッチ適用を考慮した運用設計をすることをお薦めします。
しかしながらパッチの適用には、アプリケーションの動作テストも伴う場合もあります。そのためシステムによっては難しいこともあるでしょう(それでもテスト自動化の仕組みを導入していれば、実現可能性は増えますが)。運用開始後にパッチを適用することは難しい場合でも、初回インフラ構築時にパッチを適用してそのままではなく、開発フェーズのどこかでパッチ適用を見直すことをお薦めします。

にわかワイン通養成講座

第1回 スパークリングワインの話

みなさんお酒を飲みますか?
わたしはお酒好きで、中でも一番好きなのはワインです。十数年前には、熱中するあまり、ワイン業界以外で働く人のためのソムリエ資格「ワインエキスパート」を取りました。
コラムのタイトルを「ボトル片手にOracleデータベース」としたのは、わたしがワイン好きだからです。ワインと聞くとスノッブなイメージを持たれるかもしれません。でも偏見も多いのかなと思っています。ワインを知ったことで人生の幅が広がったと感じています。

「彼を知り己を知れば百戦して殆うからず」。自在に付き合えるようになるためには、相手のことを知ることが肝心です。ワインに関することを毎回少し書く予定です。

今回は「スパークリングワイン」の話です。発泡性ワインの総称を「スパークリングワイン」と呼びます。その中でもフランスのシャンパーニュ地方で、伝統的な製法で作られたものだけを「シャンパン」と呼びます。フランス語読みだと「シャンパーニュ(Champagne)」です。

したがって日本産やアメリカ産の「シャンパン」は存在しません。日本産の発泡性ワインの総称は「スパークリングワイン」です。

フランス料理店やワインバーでシャンパンを注文するとき、より通っぽい作法は

×:「シャンパンください」
○:「シャンパーニュください」

と注文することです。

「シャンパーニュ」という呼び方はプロっぽいので「こいつデキル!」と思われるかもしれません。ただし予算の無いときにやってしまうと、自爆になるので気を付けてください。