>> 連載トップページに戻る

辻先輩と大橋君の
「Oracle Database 進撃のアップグレード」談義

これは、日々お客様のオラクルデータベース環境のアップグレード推進に奔走する二人のエンジニアの物語である。

駆け出しエンジニア・大橋君は、アップグレードの「達人」辻先輩から、「アップグレードのなんたるか」に始まり、アップグレードを無事にやりとげるための準備やチェックポイント、便利なツールなどのベスト・プラクティスを叩き込まれる。大橋君が辻先輩の教えをうけて成長する物語で「達人」を目指そう!

日本オラクル株式会社
テクノロジー製品事業統括本部 製造ソリューション部
辻研一郎 /大橋洸輔


今回はアップグレード時のお客様メリットについて12cの注目機能を紹介します。 (第1回「すごい資料公開!「Oracle Database 12cへのアップグレード」の読み方を知る」はこちら)


第2回 すぐ使いたくなる!Oracle Database 12c 新機能


辻: 辻先輩  大: 大橋君

大: アップグレードの非互換情報や手順書がまとまっていない点については理解しました!ところで、アップグレードのメリットを的確にお客様にお伝えすることって結構難しいですよね。

辻: そうだね。12cでは約500の新機能が搭載されたんだ。その中から本当にお客様に必要と思われる機能を的確にお伝えすることが最も重要かもしれないね。

前号で紹介した資料、「Oracle Database 12c への アップグレード/ 移行とデータベース統合」のPart2には、12c の主要な新機能も紹介されているよ。

大: なるほど。12c の主要機能なら、こんな説明になりますかね?


 ■Pluggable Database
マルチテナント環境に向けた新たなデータベースのアーキテクチャである。従来の仮想化やインスタンス統合に比べ、集約率が高まる上、スキーマ統合よりもコスト・工数をかけずにデータベース統合が実現可能になる機能。

 ■Heat Map / Automatic Data Optimization (ADO)
Heat Map では、データへのアクセスパターンやアクセス頻度を記録しておき、ADO ではデータの圧縮や移動をどのタイミングで実行するかをポリシーとして制御する機能。 今までの運用では手作業が必要だったところを自動化して管理コストを削減する。

 ■Far Sync
Data Guard を同期で行うとユーザーへのレスポンスが遅くなり、非同期で行うとデータをロスする可能性が出てしまうというトレードオフを最小限にした機能。ログデータのみを転送するサーバーを構築し、高レスポンスとゼロデータロスを実現する。

辻: さすが大橋君、要点をよくつかんでるね。僕からはお客様へのメリットという観点でこの機能が生まれた背景など含めて補足するよ。
今から大橋君のことを実際のお客様だと思って説明するから、ちょっと長いけど、よく聞いておいてね。

以下、辻:

 ■Pluggable Database

この機能がお客様にもたらすメリットは複数DBシステムの集約率の向上を実現しつつ各DBの独立性も担保しているところだと思います。

近年のサーバーの性能向上により、複数のDBシステムの処理負荷を1サーバーでも充分に捌ける時代になっています。また、コア数もどんどん増加しているのでライセンスから考えても1サーバー1DBではもったいない時代です。

つまり、1サーバーあたりのDBシステム数(集約率)を増やせば増やすほどコストメリットが出ます。12cのPluggable Databaseではリソースを消費するプロセス群やメモリ群は各DBで共有とし、データ領域を分割して持つことで、1DBあたりのリソース効率を上げる構造になっています。

また、1サーバーに複数DBを集約したときに気になるのがそれぞれのDBの独立性です。Pluggable Databaseでは、各DBごとに権限によってアクセスやメンテナンス処理を遮断するなどDB間の影響度を少なくするように設計されています。また同時に、管理者には各DBを一括して管理できるような管理性の向上も実現しています。

 ■Heat Map / ADO

この機能がお客様にもたらすメリットはSSDの登場によって再注目されているILM(InformationLifecycleManagement)の実現手段を提供しているところだと思います。

ILMというのは、 複数のストレージ装置をレベル別に用意し、価値のあるデータはハイエンドストレージ、そうでないデータはコモディティストレージに配置することでストレージの全体コストを削減する、という考え方です。

例えば、よくアクセスする直近一カ月のデータは価値が高いデータとしてハイエンドストレージに配置し、逆に1年以上たったデータはほとんどアクセスしないので価値の低いデータとみなしてコモディティストレージに圧縮して配置する、というやり方です。

このやり方を使えば、ストレージの初期購入コストが削減できるため、一見魅力的なのですが、問題となるのは時間が経てばデータを移動して圧縮するなどの運用負荷とストレージを複数筺体用意するので管理が煩雑になるという障壁です。このうち、データの移動や圧縮という運用負荷の問題を12cのHeat Map / ADOという機能で自動化により解決します。

一方、ストレージの複数筺体の用意の問題というのは、DBの機能ではどうにもならないところですが、こちらは、SSDの登場という近年のハードウエア事情が後押ししています。つまり、SSDの出現により同一ストレージ筺体でもSSD領域とHDD領域という異なるレベルの保存領域が存在し、ユーザーはこの2つの領域をどう活用すればよいか悩んでいます。

この点について、Heat Map / ADO という機能でユーザー定義のポリシーに基づいて価値のあるデータをSSD、それ以外のデータは圧縮してHDDに、といった配置が可能になります。

 ■Far Sync

この機能がお客様にもたらすメリットは、遠隔地の同期手段として従来高い費用が必要だったカスケードスタンバイのコストのハードルを引き下げたところだと思います。

災害によるサイト障害対策として Data Guard では、できるだけプライマリとスタンバイの間の距離を離すことが望まれます。しかし、お互いの距離を離せば離すほど同期待ちオーバーヘッドが発生してしまう。かといって非同期にするとデータロスする可能性が発生してしまう。

この解決策としてローカルサイトに近いところに同期先を準備、さらにリモートに非同期先を準備するのがFar Sync のアイデアなのですが、実はこの構成自体は11gR2以前もカスケードスタンバイという構成にすることで可能でした。

ただ、このとき問題となるのがコストです。この場合、中間サーバーも DB サーバーなのでたとえ REDO 転送しか期待していなくてもEnterprise Edition のライセンスが必要になってしまう。また、本番DBと同じデータを持つのでストレージコストもかかってしまう。そのため、この構成を実際に導入するのは一部の金融のお客様など限られたお客様でした。

この状況に対して、12c の Far Sync では真ん中のサーバーをDBではなく REDO 転送専用機(遠隔同期インスタンス)とすることでライセンス不要に、さらにデータファイルも持たないのでストレージコストも抑えられる構成を実現しています。これにより今まで敷居の高った DG カスケード構成のコストのハードルがぐっと下がりました。


辻: ・・・まあ、ざっとこんな感じだ。

大: おぉぉぉぉ!辻先輩、分かりやすいしメリットもお客様に伝わりそうですね!辻先輩を見習って、僕もこういうご提案ができるようになりたいです!この新機能を使うためにアップグレードしたくなってきますね!

辻: そうだね。それにもし、12cにアップグレードするメリットが見つからない場合でも、 アップグレードをしないリスクは既知バグを回避できないなど無視できないものであることを忘れないでね。さらに大橋君、これだけでアップグレードの問題がなくなったと思っちゃいけないよ。まだこれからアップグレード後のパフォーマンス影響という一番大きな問題が残っているんだ。そう、あの巨人のような。。。



次回、最終回。アップグレード後のパフォーマンス影響というテーマに取り組みます。



<< 前号を読む I 次号を読む >>