ホワイトペーパー紹介|Oracle Standard Edition 2を検討するべき理由
こんにちは!インサイトテクノロジーマーケティング本部です。
Oracle Database Standard Edition 2(SE2)は、Enterprise Edition(EE)に対してほったらかしにされた弟分のような存在になってしまうことがあります。多くの⽅々はEnterprise Editionで利⽤できる新機能に注⽬しますが、Standard Edition 2はどうなのでしょうか。中核は同じデータベースであることが忘れられているのではないでしょうか。
実は、SE2を使⽤すると、可⽤性の⾼いソリューションを構築でき、堅牢なディザスタリカバリ(DR)環境を確⽴するのにも役⽴ちます。⾒落とされがちですが重要な点として、Oracle 18cまではStandard EditionでOracle Real Application Clusters(RAC)を使⽤できたのですが、Oracle 19c以降、Oracle RACはSE2のコードセットに含まれなくなりました。これは残念なことですが、SE2をOracle LinuxおよびOracle Clusterwareと組み合わせるという、優れた代替の選択肢は引き続き利⽤できます。その場合、Oracle Linuxサポート契約があれば無償で利⽤できます。これらを組み合わせることで、さらに⾼い可⽤性を達成するのに役⽴つアクティブ/パッシブクラスタを構築できます。その上、ライセンスコストを抑えられるという、メリットも得られます。⼩規模ビジネスなのか⼤規模ビジネスなのかに関係なく、Standard Edition 2は企業のニーズに適合し、⼤幅なコスト削減も可能なため、検討する価値があります。
本日は、「Oracle Standard Edition 2を検討するべき理由」というホワイトペーパーを紹介させていただきます。Oracle SE2で使⽤できるオプションをいくつか説明し、どのようにこれらのオプションを使⽤することで、ディザスタリカバリを配置して可⽤性に優れたソリューションを実現できるのを見てみましょう。
Oracle DatabaseのエディションおよびSE2とEEの主な相違点
SE2の主要機能を説明する前に、さまざまなOracleデータベースエディションの主な相違点を把握しておくとよいでしょう。Oracleは以下に⽰す4つのデータベースエディションを提供しています。
- Oracle Database Express Edition(XE)
- Oracle Database Personal Edition
- Oracle Database Standard Edition 2(SE2)
- Oracle Database Enterprise Edition(EE)
SE2が⼩規模企業向けのデータベースと「分類」される理由は、サイズだけではありません。機能上の制限や特に安価なライセンスコストが、⼩規模企業や⼩規模データベース向けである⼈々が認識する理由となるでしょう。では、これらの機能上の制限とはどのようなものなのでしょうか。また、実際に制限となるのでしょうか。このことをよく理解するには、使⽤可能なデータベースエディションを詳しく調べて、アプリケーションやビジネスで必要となる機能が利⽤できるか否かを確認することをお勧めします。
以下の表にはStandard Edition 2(SE2)とEnterprise Edition(EE)の主な相違点をまとめています。この表の情報は相違点の⼀部だけを取り上げたものです。詳細については、このホワイトペーパーで以降詳しく説明しますので、こちらからダウンロードしてご一読ください。
上記の表から、最善策はすべてのオプションが使⽤可能なEEですが、⼀部のオプションは、使⽤するには追加のコストが発⽣します。SE2では使⽤できない主要なRMANオプションとして、パラレルバックアップ、ブロックチェンジ トラッキングによる⾼速増分バックアップ、およびブロックレベルのメディアリカバリがあります。SE2ではEEのすべての機能を使⽤できるわけではありませんが、⾼可⽤性ソリューションを利⽤してディザスタリカバリを実現することは可能です。
SE2にはData Guardが含まれていませんが、サードパーティ製ツールを使⽤すれば、スタンバイデータベース機能を利⽤することが可能です。
Oracle Standard Edition 2とディザスタリカバリ
ディザスタリカバリについて話をする場合は常に、次の3つの災害について⾔及されています。
- ⾃然災害
- インフラストラクチャ(ハードウェア)の障害
- ⼈的ミス
これらの災害を防ぐため、災害発⽣時にインフラストラクチャ、アプリケーション、およびデータベースがわずかなダウンタイムで引き続き機能するように、または合意された時間枠内でリカバリできるように、プロセス、ポリシー、および⼿順を実装して、組織に安⼼感を提供します。
ほとんどの場合、これには、地理的に異なる場所に2つ⽬のデータセンターを配置することが含まれます。データは、さまざまな⼿法のいずれかを使⽤してプライマリ データセンターから「バックアップ」のセカンダリサイト(DRサイト)にレプリケートされます。新しいインフラストラクチャをセットアップして構成すること、ならびにプロセス、ポリシー、⼿順を確⽴することが、ビジネス継続性を確保するために重要なすべてです。このビジネス継続性を、ディザスタリカバリプロセスを構築する背景にある重要な理由であると⾒なすことができます。
以下に、⼿動で実装する必要があるプロセスの一例を⽰します。
- スタンバイデータベースの作成(プライマリデータベースの複製)
- スタンバイ制御ファイルの作成
- プライマリデータベースからスタンバイデータベースへのREDO情報の⾃動転送
- このREDOをスタンバイデータベースに適⽤するリカバリ セッションの開始
- 適⽤したアーカイブログの管理
- プライマリとスタンバイがロールを切り替える、ロール切り替え操作の実⾏
- 災害発⽣時のスタンバイデータベースのアクティブ化(スタンバイデータベースへのフェールオーバー)
以下の図は、スタンバイデータベースの概要を⽰しています。
要約すると、スタンバイデータベースを実装および保守するには、以下の3つの主要ステップが必要です。
アーカイブログの抽出
アーカイブログはデータベースのリカバリに重要です。また、このアーカイブログを使⽤して、プライマリデータベースからスタンバイデータベースにREDO情報を移動します。最初のステップとして、プライマリ環境からアーカイブログを抽出します。このログは、ASMディスクグループ内にある可能性があります。
REDOの転送
2つ⽬のステップとして、プライマリサーバーとセカンダリサーバーの間でアーカイブログを転送します。この転送にOracle Netを使⽤することはできません。他のネットワークコピー操作を使⽤してアーカイブログを転送します。
REDO(アーカイブ)の適⽤
最後のステップは、アーカイブログをスタンバイデータベースに適⽤するプロセスです。このプロセスにより、スタンバイデータベースがプライマリと同じ最新の状態になります。このプロセスで重要となるのが、アーカイブログを失わないようにすることです。失った場合は、プライマリデータベースとスタンバイデータベースの間にリカバリ不可能なギャップが⽣じてしまいます。
SE2でOracle RACを使⽤する場合や、プライマリ側にアクティブ/パッシブクラスタを使⽤する場合でも、スタンバイデータベースを使⽤することが可能です。原理は同じです。Oracle RACデータベースからスタンバイサーバーにアーカイブログが転送されて、両⽅のスレッドのアーカイブログ(REDO)がスタンバイデータベースに適⽤されます。以下の図に、この概要を⽰します。
まとめ
ここで紹介した内容のほか、このホワイトペーパーでは、Oracle Standard Edition 2を使⽤する場合のコスト上のメリットを把握できるように、コスト⽐較の例をいくつか⽰しています。また、スタンバイデータベースを使⽤してクラウド環境でディザスタリカバリを達成する⽅法についても説明しています。
下記にて本資料の一部の目次を公開します。さらにOracle Standard Edition 2の高可用性に興味がある方は、ぜひこちらよりホワイトペーパーをダウンロードしてください。
- Oracle Databaseのエディション
- 各データベースエディションの主な相違点
- ライセンスコストの⽐較
-
- 例A:単⼀インスタンスのデータベース環境を使⽤したOracleライセンス
- 例B:Oracle RACを使⽤したOracleライセンス
- Oracle Standard Edition 2と⾼可⽤性
- Oracle Standard Edition 2とディザスタリカバリ
- クラウドでのDRとは
- EnterpriseからStandard Edition 2への移⾏
- 2ソケットは実際に制限なのか
- Oracle Standard Edition 2の使⽤を検討する理由