ついにベールを脱いだ！Oracle 12cの新機能を紹介！

公開日：2013/08/10

先日oracle 12cの新機能紹介とやらのセミナーにうけてきたのでそれの備忘録。

とりあえずいろいろ追加されているようだがやはり大きな目玉はマルチテナント・アーキテクチャやプラガブル・データベースではなかろうか。

ますます進化するOracle。

では早速その機能を見てみようの巻。

マルチテナント・アーキテクチャ

マルチテナント・コンテナ・データベース（略してCDB）のインスタンスを一つ立ち上げ、

そのインスタンス上で複数のデータベース（プラガブル・データベース、略してPDB）を仮想的に立ち上げるもので、

複数の仮想データベース間でデータベースインスタンスと、メモリー、プロセスを共有できるので、リソースを有効的に活用できる。

今までインスタンスごとにリソース（例えばTARGET_MEMORYで使用メモリ量を指定したり）などを割り振っていたかと思うが、1つのCDB上のリソースを共有して使うので、1ノードに複数DBを立ち上げようがそれぞれにリソースを割り振る必要がなくなるわけである。

マルチテナント・アーキテクチャを使うことで以下のような利点を得られる。

高いリソース使用率
- リソースのオーバーヘッドが少ない
- 複数のインスタンスをたちあげてもバックグラウンドプロセスのセットが1つのみになる
- ITコストの削減が可能に
統合の負荷が少ない
統合前の名前空間が別々になるので同じスキーマ名であっても別々のものとして認識される
アプリケーションの改変は不要で統合が可能に
運用管理の工数は大幅に削減
いくつDBを統合しても単一DBとして管理できる
- バックアップも1回で済ませられる。運用業務がシンプルに。
システム間の独立性を保つ
別々の権限を割当てられる
高パフォーマンスでスケーラブル
DB構築期間の短縮

これでもかってくらい利点があるので紹介しきれない。

さすが目玉機能だけある。

駄菓子菓子

PDBを2つ以上作るときはEnterprise Editionかつ、Multitenant Optionが必要になるので注意。

1つのCDBに1つのPDBで作成する分にはデータベース標準機能のため、全Editionで使用でき、特にオプションはいらない。

ちなみに11gまでの従来型のDB構成ももちろん構築できる。

これはNon-CDB構成とよばれる。

Information Lifecycle Management

HeatMapという機能でセグメント、ブロック/エクステントレベルでデータの利用状況を監視している。

アクセスの多いデータは早いストレージに、アクセスの少ないデータについてはおそいところに自動的に行ってくれたりするらしい。

また、Automatic Data Optimizationという機能で表に対してのデータの配置をポリシーで設定できたりする。
例えば、作成から90日たったら圧縮、180日以上データに変更がなければアーカイブしてしまうなどなど。

ちなみにHeatMapもAutomatic Data Optimizationも、Advanced Compressionライセンスが必要になる。

Data Redaction

アクセスするユーザーやアプリケーションに応じてデータを動的にマスクする機能。

ユーザに対してポリシーを設定することで結果の返し方を設定できる。

例えば、クレジットカード番号をSELECTした場合に普通なら「0120-4444-4444-4444」とかでるところを

「****-4444-4444-4444」(伏字）
とか
「hoge-4444-4444-4444」（置き換え）
とか
「r?/s-4444-4444-4444」（ランダム）

とかに見せ方を変えて表示できる。

これでコールセンターの人には番号を見せないが、管理者の人はちゃんと見ることができるといった設定ができるのである。

ちなみにこれはAdvanced Securityのライセンスが必要。

Privilege Analysis

DBでの最小権限許諾を遂行するためのチェック機能。
ユーザに付与した権限、ロールの使用状況をモニターしてレポート出力できる。

例えばどのユーザーがどの権限でどの操作を行なっているかを見たり、高度な権限を持つロールが不要なユーザに与えられていないかをみたり。

レポートをみて、いらなそうな権限は剥奪するなどして最小権限でDBの運用ができるようになる。

これはDatabaseVaultライセンスが必要になる。

Flex ASM

ストレージグリッドとデータベースグリッドを分離して可用性を向上。

つまるところ、データベースインスタンスとASMインスタンスが独立したクラスタとして構成できるようになった！

いままで↓だったのが

FlexASMを使うと↓みたいなかんじに。

仕組み的には、ASMインスタンスを持たないRACノードは他のノードのASMクライアントとして動作し、接続先のASMインスタンスがダウンした場合は他のASMインスタンスに接続しに行く。

個人的にはこの機能はかなり嬉しい機能である。

いままでRACなどでASMインスタンスは各ノードに存在しないとASMが使えず、ASMインスタンスが落ちるとDBインスタンスも引きづられて落ちてしまった。

しかし本機能により、ASMインスタンスがなくてもDBインスタンスが立ち上げられ、またASMインスタンスダウンがDBインスタンスに影響しなくなったのだ。

また、ASMインスタンスの可用性も同時に確保されるようになり、より可用性が上がったといえる。
ただし制限としては、ASMが12cでも、DBが11gの場合は今までどおり同じノードにASMインスタンスが必要になる。

12cに全部合わせてねってことのようだ。

Far Sync

データガードでフィジカル・スタンバイなどの構成をとっている時に、スタンバイである同期先が遠いところだとネットワーク遅延などの問題があった。

本機能は、FarSyncインスタンスと呼ばれるログ転送専用インスタンスに一度同期して、FarSyncインスタンスから遠いスタンバイ環境に非同期でデータを転送する。

ワンステップ置く事により、同期転送時のネットワーク遅延を最小限に抑え、本番環境へのパフォーマンス影響を最小化した上でゼロデータスロスの環境を構築できるようになった。

Data Garudについては12cのマルチテナント・アーキテクチャにも対応しているが、CDP単位での構成しかいまのところ対応しておらず、PDB単位でスタンバイデータベースは構成できない模様。

要ActiveDataGuardライセンス。

Global Data Services

レプリケーション・サイト間でのフェイルオーバーとロードバランシングを実装する機能。

GSM(scan listenerみたいなの)を各データセンターに起動してあり、そこに本番環境とスタンバイ環境をまとめて登録しておき、ユーザはそこにアクセスする。すると、GDS内での負荷を考慮した分散を行なってくれる。

また、障害時の切り替えなどを自動で行ってくれるので、ユーザーは特に意識せずアクセスする事ができる。

GDSを使うと手動による切り替えのラグや管理の負荷を下げることができる。

複数のデータセンターにスタンバイがまたがっている時などで、複数サイトでのでの障害などが想定される場合に有効。

Active Data Guardライセンスが必要。

Application Continuity

障害時にトランザクションをリプレイする機能。
Oracle12cではTransaction GuardというAPIが新しく追加された。各トランザクションごとに正常終了したかどうかの状態をもっており、このAPIを使うとその状態を問い合わせることができる。

Application Continuityは異常終了時（例えばRACの方ノードが落ちた場合など）にTransaction Guardと連携して必要に応じてトランザクションをリプレイする。

これにより二重処理や、未処理といった事態が減るため、ユーザエクスペリエンスが向上する。

また、Transaction Guard機能をONにしてもオーバーヘッドは小さい。

いままでTransparent Application Failover（透過的アプリケーションフェールオーバー、TAF）という機能でSELECT SQLをレジュームする機能があったが、Application Continuityはそれをパワーアップさせた感じになる。トランザクション対応という意味で。

これは構成に応じてActive Data Guardか、Real Application Clustersが必要になる。