Database Support Blog

  • Oracle Database
2022.04.27

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

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

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

RMAN ブロック・チェンジ・トラッキング(第5位)

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

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

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

RMAN 増分バックアップ

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

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


パラレル機能(第4位)

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

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

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

・テーブル/インデックススキャン
・テーブルへのDML処理
・リカバリ操作
・伝播(レプリケーション)
・データのロード処理(SQL*Loader)
・Data Pump Export / Import

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

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

項目 SE2の場合 EEのパラレル処理の場合
ライセンス上の利用可能なスレッド数の制約 制約有(同時に実行できるのは1DBあたり16スレッドまで) 制約なし
並列度の調整が必要になった場合の対処策 擬似的な並列処理になるように作り込みが必要 並列度の数値変更のみで対応可(メンテナンスが容易)

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

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

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


オンライン句(第3位)

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

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

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

機能名 概要 使用可能なエディション
オンライン列追加/変更 オンラインで列の追加、変更が可能 列の追加、削除(非主キー列)、列名変更 SE2/EE
オンライン索引ビルド オンラインで索引の構成、再構成
(索引構造劣化からの復旧、別表領域への索引移動等)
EE
オンライン表再編成/再定義 オンラインで表の論理、物理構成を再定義(表の再作成、 別表領域への表移動 通常表とパーティション表の相互変換) EE
オンラインパーティション操作 オンラインでのパーティション表操作
(パーティション追加、移動、構造変更 通常表とパーティション表の相互変換)
EE
オンラインデータファイル移動 オンラインでのデータファイル移動、リネーム EE

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


フラッシュバック機能(第2位)

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

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

機能名 概要 機能カテゴリ 使用可能なエディション
Flashback Query テーブル単位で過去時点のデータを表示 参照 SE2/EE
Flashback Version Query 指定した時間間隔のすべての変更履歴を行単位で表示 参照 SE2/EE
Flashback Drop DROPしたテーブルを復旧 リカバリ SE2/EE
Flashback Transaction Query 一定期間に行われたトランザクションの変更履歴とUNDO_SQL文を表示 参照 EE
Flashback Data Archive 一定期間の履歴データを保持し、テーブル単位で遠い過去のデータを 表示 参照 EE+オプション(*)
Flashback Transaction トランザクション単位での操作取り消し リカバリ EE
Flashback Table テーブル単位で過去の時点へ復旧 リカバリ EE
Flashback Database データベース全体を過去の特定の時点に復旧 リカバリ EE
*履歴表の最適化(圧縮)を行う際は、EE+Advanced Compression が必要。 履歴表の最適化を行わない場合にはSE2でも利用可。


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

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

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

フラッシュバック機能 UNDO情報

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

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

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

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


Data Guard スナップショット・スタンバイ機能(第1位)

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

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

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

Data Guard

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

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

Data Guard スナップショット・スタンバイ機能

検証が終われば元の状態に戻せます(後続の変更履歴の適用も再開します)。一時的にリアルタイム性は失われるという点はありますが、本番環境で扱うデータとほぼ同等のデータを使った検証を行いたいケースには最適です。追加オプションは不要(※)なので、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


執筆者情報

あさの みさ プロフィール画像

2007年度アシストに入社後、Oracle Database のフィールドエンジニアと定期研修のセミナー講師を兼務。
2度の産休・育休を経て、現在はデータベースやクラウド関連のプリセールスエンジニアとして活動中。


■本記事の内容について
 本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。

■商標に関して
 OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。
 文中の社名、商品名等は各社の商標または登録商標である場合があります。


Oracle Databaseライセンスのご相談ならアシスト

関連している記事

  • Oracle Database
  • Oracle Cloud
  • PostgreSQL
  • AWS
  • Exadata
2022.05.24

入社2年目がレポート!Cloud Database Days 2022技術セッションの見どころ

2022年5月26日~6月3日に開催される「Cloud Database Days 2022」。その中でも10個に分かれた技術セッションについて、ポイントを押さえてそれぞれご紹介いたします!

  • Oracle Database
2022.05.20

Oracle Databaseライセンスの定義とルールを正しく理解する ~第3回:仮想化環境編~

今回はOracle Databaseライセンス「仮想化環境編」です。これまでエディション、ライセンスの種類、カウントの方法、という基本的な内容を説明してきましたが、より構成に踏み込み、「ハードウェア分割の基本的な考え方」や「仮想化環境の考慮点」=Soft Partitioning理解のポイントを説明しします。

  • Oracle Database
  • Exadata
2022.04.08

Exadataをフル活用しよう!性能をさらに引き上げるチューニング方法(パラレルクエリー編)

Oracle Exadata Database MachineにおけるSQLチューニング手法2回目の本記事では、パラレルクエリー(Parallel Query)を使ってさらに性能を引き上げる方法をご紹介します。Exadataとパラレルクエリーは非常に相性が良い組み合わせです。どれくらい効果があるのか、検証結果も踏まえて解説します。

ページの先頭へ戻る