DBエンジニア厳選！DB基盤に効果的なOracle EE基本機能5選

Oracle Database Enterprise Edition（EE）の有償オプションは知っているけど基本機能は知らなかった、昔はよく調べていたけど最近の機能は知らない、という話はお打ち合わせの場面でもよくお伺いします。「え！？人的コストも抑えられるかも」「メンテナンスに割いていた時間が大幅削減できるかも！？」とStandard Edition 2（SE2）からEEへの変更を検討し始めるお客様も実は増えています。

今回はプリセールスエンジニアとしてお客様とお話をしながらよく聞くお悩みや課題をベースにOracle Database歴15年の筆者が独断で選出したおすすめ機能をランキング形式でご紹介します。

第5位は、「高速増分バックアップ」とも訳されるブロック・チェンジ・トラッキング機能です。

この機能はRMAN（Oracle Recovery Manager）の増分バックアップをより高速化できないか、という発想から生まれたもの。SE2でも増分バックアップは利用はできますが、前回のバックアップから今回までに更新があったデータブロックを調べるためにフルスキャンをしています。結果的にバックアップファイルサイズ自体は小さくできたとしても、バックアップ取得時間は変わりません。データ量が増えれば増えるほど必要なバックアップ取得時間も増える、という課題はSE2の増分バックアップでは残ったまま。

EEのブロック・チェンジ・トラッキング機能では、バックアップ対象のデータブロックがすぐに判別できるように「更新されたかどうかを記録したファイルを中間に挟む」という仕組みを採用しています。この中間ファイルのことを「ブロック・チェンジ・トラッキング・ファイル」と呼びます。データブロックが変更されたか、されていないかの情報だけが分かるようになっているためファイルサイズ自体も小さく、変更ブロック自体の把握にも時間がかからないのです。

データ量がますます増える昨今、夜間に実施できていたバックアップが時間内に収まらなくなり困っている、というお話もよく聞きます。データベースのバックアップ・リカバリ手法の検討でお悩みの方、基礎知識を改めて整理したい方は下記の動画も参考にしてください。

▼オンデマンド無料セミナー『データベースのバックアップ・リカバリ』
https://www.ashisuto.co.jp/product/theme/database/backup.html

第4位は、パラレル機能。
その名のとおり、複数のプロセスで1つの処理を内部的に並列で実行できる、という機能です。「使いどころがたくさんある！」という点でランクイン！

SQL処理そのものの実行時間もそうですし、SQLを実行するプロセスの並列度自体をOracle Database というソフトウェアに任せることができます。パラレル処理の機能自体は比較的歴史のあるものですが、使える場面はバージョンが上がるごとに少しずつ増強されています。

パラレル機能の一例は下記のとおりです（19cの場合の一例です）。

SE2でも疑似的にパラレル処理に似たイメージで処理を実行できるケースはあります。例えば論理バックアップ（Data Pump のExport）を実行するケースの場合、バックアップ単位自体を小分けにして準備しておく方法があります。小分けにした単位ごとにバックアップ実行ジョブ（シェルスクリプトなど）を用意しておき、複数のジョブを同時にジョブツールからキックさせるイメージです。

ただし、SE2の場合はあくまで疑似的な手法しかできません。小分けにしている処理自体はそれぞれシリアル実行です。システムにより向き不向きがあり、全てのお客様にご提案できるやり方ではありません。他にもSE2とEEのパラレル処理では下記のような違いがあります。

上記の違いを考慮すると、SE2の場合はメンテナンスや運用管理という側面では工数が増えやすいことがお分かりいただけるかと思います。同時実行可能なスレッド数にも制限があるため、物理的なリソースも有効活用したくても限界がある、という点も注意が必要です。

※SE2のスレッド数に関する参考コラム
【Oracle SE2】CPUスレッド数制限の動作検証結果～その１～
https://www.ashisuto.co.jp/db_blog/article/20160223_se2thread1.html

パラレル処理はアシストの技術者が現場でもしばしば活用している機能の一つ。「メンテナンスコスト」「CPUリソースの有効活用」という観点で現場課題がございましたら、パラレル機能の活用も視野に入れてみることをお勧めします。

第3位は、オンライン句！
たった一句「online」というキーワードを添えるだけ。「機会損失を防ぐ」ことができ「人的コストの大幅削減」にも繋がるという点で第三位にランクインです。

オンライン句を使えば業務アプリを動かしながらメンテナンスが可能です。メンテナンスのためのシステム停止による機会損失の抑止につながりますし、メンテナンス担当者にとっても業務調整が容易になり、DB管理者の負荷減にもつながる点がこの機能のポイントです。

オンライン句が利用できる場面は主に下記のとおりです（19cの場合）。一部の操作はSE2でも実施可能ですが、大半はEEの基本機能です。

実際にアシストのお客様でも「オンライン句のおかげで夜間対応していた複数メンバーがメンテナンス業務から解放された」というエピソードがあります。キーワードはとてもシンプルで、EEであれば基本機能。追加のオプションもなく利用ができる機能です。業務効率化の観点でお悩みでしたら、メンテナンスコストと人的コストも総合的にイメージしながらぜひ採用をご検討いただきたい機能です。

第2位はフラッシュバック機能。
データベースをリストアしなくても「過去のある時点に戻せる」という点で第2位にラインクイン。過去データを参照するだけの操作も可能なため「不正なデータの改ざん防止にも有効」という点も上位セレクトの理由です。

フラッシュバック機能は複数種類があり、エディション毎に使える機能が異なります。
一覧は下記のとおりです。

*履歴表の最適化(圧縮)を行う際は、EE＋Advanced Compression が必要。 履歴表の最適化を行わない場合にはSE2でも利用可。

フラッシュバック機能の一番の魅力は「データを入れ直さなくても良い」という点です。

通常、人為的なエラーによりデータ状況が誤りの状況になった場合、元の正しい状態に復旧しようとするとデータを入れ直しとするか、リストアしてリカバリをするという手順がどうしても必要です。

フラッシュバック機能はUNDO情報から辿って参照するという仕組み。UNDO情報をどれだけ保持しておくかという事前の設計は必要ですが、運用に載ればデータの入れ直しが不要なのです。

他にも、人為的なエラー以外の活用シーンとしては下記のようなパターンもあります。

・DWH でデータを取り込む作業中「取り込み過程で確定する前」の確定時点のデータを
　アプリ側では見せたい場合
　（フラッシュバック機能を使わない場合、一時参照用のDBを別に作る、等の工夫が必要）

・特定時点の情報をSQLで指定して参照したい場合
　（フラッシュバック機能を使わない場合、特定時点まで戻した別のデータベースを作る
　　等の準備が必要）

「見たいときに、見たい時点のものを参照したい」という場面、ありませんか。開発部隊やアプリ担当の部隊が分かれているような場合はヒアリングしてみるとヒントがあるかもしれませんね。

第1位は、Data Guard の「スナップショット・スタンバイ機能」です！

Data Guard 自体は古くからあるアーキテクチャです。Oracle Database で作ることができる災害対策構成（ディザスタリカバリ）の一つです。

基本的な構成は下記のイメージです。本番機側の変更履歴を災害対策用のスタンバイ機に転送し、スタンバイ機側で変更履歴の適用を行います。遠く離れた地点にも複製したデータベースを作っておけるイメージ。本番機が自然災害等で復旧が困難な場合でも、スタンバイ機に切り替えることでシステム停止時間を最小限に抑えることができます。近年はハイブリッド構成ということで Oracle Cloud上にスタンバイ用途の環境を用意する、というケースも増えています。

さて、話を戻します。このData Guard の「スナップショット・スタンバイ機能」はスタンバイ機をただ置いておくだけではなく、日々の運用で少しアレンジした使い方ができる、という機能です。

基本的にはスタンバイ機には自然災害が起きるまで変更履歴（上記の図だと変更ログ）が適用され続けます。スナップショット・スタンバイ機能を使うと一時的にこの変更履歴の適用を停止しておくことができます。この間、本番機側はそのまま運用は継続可能。スタンバイ機には本番データを使って開発用のSQLを発行し、動作確認をすることができるのです。この間、スタンバイ機にはデータの更新処理なども確認が可能です。

検証が終われば元の状態に戻せます（後続の変更履歴の適用も再開します）。一時的にリアルタイム性は失われるという点はありますが、本番環境で扱うデータとほぼ同等のデータを使った検証を行いたいケースには最適です。追加オプションは不要（※）なので、Data Guard構成を検討される際には合わせて知っておきたい機能。
※Active Data Guard という有償オプションを使うと、変更履歴を停止せずにスタンバイ機を参照用として利用できる、という機能もあります。

なかなか本番と同じデータを使った検証はできない、難しい、もしくは出来るけれどもデータ転送に時間がかかるので準備が期間内にはできない、というお悩みはよくお聞きします。災害対策の検討が必要な方はぜひ、開発部隊の方の課題解決案としても併せてEE採用をご検討いただくこともおすすめします。

「Enterprise Edition は値段が高い」というのはお客様からもよくお伺いするキーワードです。ライセンスの考え方もSE2とは異なりますから、製品の金額だけでみると安い金額ではありません。

ただ実際の弊社事例としては「業務全体」を見渡し、利用用途や運用後のイメージ、システムのあるべき姿なども照らしあわせてみた結果、システム運用全体に関わるトータルコストの削減に繋がった事例がたくさんあります。EE基本機能だけでも使いどころは本当にたくさんあります。データベース基盤が少しでも理想に近づけるよう、本記事がお役に立てれば幸いです。

とはいえ新基盤にEEを検討しようと思ったとき「じゃあリプレース後の構成はどうするか？」という点も避けては通れないお話。EE固有機能の使いどころや活用シーンに憧れるけど、「コスト的には難しい」「申請してもきっと無理」とお聞きすることも多いです。そんな時こそぜひ、アシストの営業にお気軽にご相談ください！

▼エディションに関する記事はこちら
Oracle Databaseライセンスの定義とルールを正しく理解する　～第1回：エディション編～
https://www.ashisuto.co.jp/db_blog/article/oracle-database-license-rule01.html

▼パラレル処理の参考動画はこちら
https://www.ashisuto.co.jp/product/category/database/oracle/#tab

・バックアップおよびリカバリ・ユーザーズ・ガイド（19c）
https://docs.oracle.com/cd/F19136_01/bradv/introduction-backup-recovery.html#GUID-9997EF87-B293-44D4-92F3-DD938E79170D

・VLDBおよびパーティショニング・ガイド（19c）
https://docs.oracle.com/cd/F19136_01/vldbg/preface.html#GUID-FBCA303C-0A46-4233-9DE2-EC9971F5B7A7

・オンライン・データの再編成と再定義（12c）
https://www.oracle.com/jp/database/technologies/features/online-ops.html

・フラッシュバックテクノロジーの活用（19c）
https://docs.oracle.com/cd/E96517_01/adfns/flashback.html#GUID-03D1CAAE-D940-444A-8771-B1BC636D105D

・スナップショット・スタンバイ機能（19c）
https://docs.oracle.com/cd/F19136_01/sbydb/managing-oracle-data-guard-physical-standby-databases.html#GUID-CE30E2D6-5B53-4389-8B02-FC0F341C8C1A