Cloud Object Storageを使用した、Oracle Cloud …...5 | Oracle Database Backup Cloud – Object Storage を使用した、Oracle Cloud Infrastructure Exadata のバックアップとリストアのベスト・プラクティス

Cloud Object Storageを使用した、 Oracle Cloud Infrastructure Exadataのバックアップとリストアのベスト・プラクティス Oracle ホワイト・ペーパー | 2019 年 5 月

1 | Oracle Database Backup Cloud – Object Storage を使用した、Oracle Cloud Infrastructure Exadata のバックアップとリストアのベスト・プラクティス

目次

概要 ............................................................................................................................................................2

クラウドのバックアップおよびリストア・ライフサイクルのベスト・プラクティス ................3

RMAN バックアップおよびリストア構成のベスト・プラクティス .................................................4

観測/予測されたバックアップとリストアのパフォーマンス ...........................................................7

RMAN 全体バックアップ ..............................................................................................................8

RMAN 増分バックアップ ..............................................................................................................9

全体バックアップからの RMAN リストア .............................................................................. 10

バックアップとリストアのメンテナンス作業.................................................................................. 10

結論 ......................................................................................................................................................... 13

付録 A ..................................................................................................................................................... 14

RMAN 全体バックアップ ........................................................................................................... 14

RMAN 増分バックアップ ........................................................................................................... 15

全体バックアップからの RMAN リストア .............................................................................. 16

付録 B ..................................................................................................................................................... 17

付録 C ..................................................................................................................................................... 19

付録 D ..................................................................................................................................................... 20


概要

Oracle Database Backup Cloud Service は、 Oracle のオンプレミス・データベース、またはCloud@Customer または Oracle Cloud Infrastructure（OCI）に常駐しているクラウド・データベースのバックアップを作成するためのセキュアでスケーラブルなオンデマンド・ストレージ・ソリューションです。

Oracle Exadata は、Oracle Cloud Infrastructure（OCI）のオラクル最高の Maximum Availability Architecture（MAA）データベース・プラットフォームです。

このホワイト・ペーパーでは、Exadata データベース・システムを OCI Database Backup Cloud Service にバックアップするための MAA 推奨のバックアップおよびリストア・ベスト・プラクティスを紹介します。このホワイト・ペーパーでは、以下について記載しています。

1. クラウドのバックアップおよびリストア・ライフサイクルのベスト・プラクティス

2. RMAN バックアップおよびリストア構成のベスト・プラクティス

3. 観測/予測されたバックアップとリストアのパフォーマンス

4. バックアップとリストアのパフォーマンスを上げるための例


クラウドのバックアップおよび

リストア・ライフサイクルのベスト・プラクティス

1. バックアップ、リストア、およびデータ保存の品質保証契約について理解する

手順を進める前に、次の質問に答えてください。

a. 予測されるバックアップ期間はどのくらいか。

b. ディザスタ・リカバリの予測されるリストアとリカバリの最大時間またはリカバリ時間目標

（RTO）はどのくらいか。

c. データ保存要件はどのような内容か。

d. データ損失耐性またはリカバリ・ポイント目標（RPO）はどのくらいか。

ほとんどの Exadata のお客様は、80 %の DATA および 20 %の RECO ディスク・グループ構成で事前構成さ

れた Exadata 設定を使用しています。また、Oracle Cloud Infrastructure Object Storage にバックアップして

います。リカバリ不能なデータベース、クラスタ、Exadata ラック、あるいは可用性ドメインの障害といっ

たデータベース障害から保護してくれるからです。バックアップのリストアで RTO 要件を必ずしも満たすこ

とができない場合、MAA では、スタンバイ・データベースまたは Golden Gate レプリカを別の Oracle Cloud

Infrastructure データベース・リソースに配置することを推奨します。このホワイト・ペーパーでは、最適な

バックアップとリストアの速度を達成するためのガイダンスと MAA ベスト・プラクティスを、さまざまに

変化する CPU オーバーヘッドに関する知見とともに紹介します。このホワイト・ペーパーで示す例では、

Oracle Cloud Infrastructure Object Storage と Oracle Database Backup Cloud Service を使用した場合のバッ

クアップとリストアにかかる時間を予測します。

2. 最新の Cloud DBaaS ツールがインストールされていることを確認する

Cloud DBaaS ツールである RPM リリース 18.2.3.1.0_190328.0930 以上には、検証済みの MAA バックアップ/

リストア・ベスト・プラクティスが組み込まれています。最新の Cloud DBaaS ツールの RPM に更新するに

は、「Updating the Cloud Tooling on Exadata Cloud Service」

（ https://docs.cloud.oracle.com/iaas/Content/Database/Tasks/exatooling.htm#UpdatingToolingonanExadat

aDBS ystem）を参照してください。

3. Oracle Database Backup Cloud Service のオブジェクト・ストレージにバックアップを保存する期間を

指定するデータ保存要件を決定する

この期間は『Backing Up an Exadata Database』のドキュメントで bkup_oss_recovery_window とし

て説明されています。

https://docs.cloud.oracle.com/iaas/Content/Database/Tasks/exabackingup.htm

bkup_oss_recovery_window のデフォルト値は 30 日間で、必要に応じて最大 90 日まで変更できます。ま

た、Oracle Cloud Infrastructure は CONTROL_FILE_RECORD_KEEP_TIME を自動的に設定します。バックアッ

プは自動的にすべての可用性ドメインに書き込まれます。

https://docs.cloud.oracle.com/iaas/Content/Database/Tasks/exatooling.htm#UpdatingToolingonanExadataDBSystem

https://docs.cloud.oracle.com/iaas/Content/Database/Tasks/exatooling.htm%23UpdatingToolingonanExadataDBS%20ystem

https://docs.cloud.oracle.com/iaas/Content/Database/Tasks/exatooling.htm%23UpdatingToolingonanExadataDBS%20ystem



4. 以下のドキュメントで説明されている Oracle Cloud Infrastructure Object Storage のバックアップ・ラ

イフサイクルのベスト・プラクティスに従ってください。


MAA の推奨事項：

• 毎週の全体バックアップ・レベル 0（デフォルトでは日曜日）

• 毎日の増分バックアップ（デフォルトでは approach）

• Oracle Cloud Infrastructure Object Storage でのバックアップはすべて、自動の場合は TDE 鍵

を介して、手動バックアップの場合はパスワードを介して暗号化されます。

デフォルトのレベル 0 のバックアップ推奨曜日とバックアップ開始時間は変更が可能です

（ bkup_daily_time=hh:mm ）。オンデマンドのバックアップも随時起動できます。詳しくは、

https://docs.cloud.oracle.com/iaas/Content/Database/Tasks/exabackingup.htm を参照してください。

5. バックアップとリストアを定期的に検証する

MAA が定期ベースについて推奨する手順には自動と手動があります。

• 毎日の RMAN crosscheck。これは、デフォルトで構成されているすべてのクラウド・データ

ベース・バックアップで自動的に実行されます。起動はクラウド・コンソールまたは Cloud

DBaaS ツールで行われます。

• check logical オプションを使った毎月の RESTORE VALIDATE 操作。これは手動で実行する必

要があります。CPU 利用率がさらに 8 %上がっても差し支えない期間を選択してください。

この操作は、実行中のバックアップに干渉しません。このホワイト・ペーパーの「バック

アップとリストアのメンテナンス作業」の項などを参照してください。

• 四半期ごとの全体リストアおよびリカバリ評価。これは手動で実行する必要があります。こ

のホワイト・ペーパーの「全体バックアップからの RMAN リストア」の項などを参照してく

ださい。

RMANバックアップおよびリストア構成のベスト・プラクティス

この項では、推奨されるおもなバックアップとリストアの設定、およびバックアップとリストアのパフォーマ

ンス全体に対する影響について説明します。以下の設定はすでに DBaaS RPM 18.2.3.1.0_190328.0930 以上のリ

リースでデフォルトになっています。デフォルト設定を変更する必要がある場合は、「付録 D」の「bkup_api

コマンドの使用例」を参照してください。

1. デフォルトの RMAN セクション・サイズ（64 GB）を使用する

この設定を変更することは推奨していません。マルチセクション・バックアップの目的は、Oracle RMAN

チャネルでサイズの大きな単一ファイルをパラレルでバックアップできるようにすることです。Oracle

RMAN では、処理を複数のチャネル間で分割し、各チャネルで 1 つのファイル内の 1 つのファイル・セク




ションをバックアップします。別々のセクションで大きいデータファイルをバックアップすることにより、

バックアップのパフォーマンスを格段に向上させることができ、設定は無視されるか、より小さいデータ

ファイル用に自動調整されます。注：Oracle 11g データベースは、初期レベル 0 のマルチセクションをリス

トアできますが、レベル 1 の増分バックアップはリストアできません。

2. デフォルトの RMAN 並列度を使用し、必要な場合は調整する

デフォルトの RMAN チャネル総数は、Exadata クォーター・ラックでは 8 個、Exadata ハーフ・ラックでは

16 個、Exadata フル・ラックでは 32 個です。RMAN チャネルは Oracle RAC データベース・インスタンスに

分散されます。デフォルト設定の場合、データベース・パフォーマンスへの影響を最小限に抑えながら

（CPU 利用率 5 %未満）、まずまずのバックアップ・パフォーマンスを達成します。ただし、特定の期間中

に実行されるデータベースのバックアップがほかになければ、RMAN チャネル数を 16 に変更すると、デー

タベースへの影響が許容範囲内のまま（CPU 利用率 5 %未満）、バックアップ・パフォーマンスがさらに向

上します。スループットがより高く、CPU 利用率が上がる場合は、RMAN チャネル数を 2 倍に増やします。

Exadata システムごとの RMAN チャネル最大数は 64 個です。1 台の Exadata ノード当たりの RMAN チャネ

ル最大数は 32 個です。このホワイト・ペーパーで後述する例のガイダンスを参照してください。Exadata

データベース・サーバーで使用可能な CPU 数がフルに使用されていない場合は、RMAN チャネルの総数を

減らしてバックアップのオーバーヘッドを制限します。チャネルの推奨事項については、以下の表のガイド

ラインを参照してください。

ノード当たりのCPU総数 Exadataクォーター・ラックの RMANチャネル推奨総数

46以上 8チャネル（デフォルト）以上

20 > コア数 < 46 4～8チャネル

20未満 2～4チャネル

3. デフォルトの RMAN 圧縮は LOW

Oracle Cloud Infrastructure Object Storage に送信する前にバックアップを圧縮することで、使用される全体

的なバックアップ・ストレージ、バックアップ経過時間、ネットワーク利用率が少なくなります。潜在的な

トレードオフは、バックアップとリストアの操作中、CPU 利用率が増えることです。MAA の所見によると、

LOW の RMAN 圧縮を使用した場合、バックアップのスループットが非常に高くなって、Oracle Cloud

Infrastructure Object Storage 容量が減る一方で、Exadata DB ノードの CPU オーバーヘッドが引き続き 5 %

以下に維持されます。バックアップとリストアの操作中に CPU 利用率を下げるには、RMAN 圧縮を無効に

し、クラウド API 外から RMAN コマンドを実行します。クラウド API では、さまざまなレベルの RMAN 圧

縮に変更することができますが、現時点では、クラウド・ツールまたは bkupapi set config コマンドで NONE

に設定することはできません。圧縮を NONE に設定すると、Oracle Cloud Infrastructure Object Storage での

バックアップ・ストレージ利用率が増えるので注意してください。クラウド API を使用しない場合の非圧縮

バックアップ・パフォーマンスの例については、「付録 A」を参照してください。


表領域が Exadata Hybrid Columnar Compression（HCC）圧縮で構成される場合、LOW 圧縮でバックアップ

すると CPU オーバーヘッドが余分に増えることがあります。これらのターゲット表領域での（アーカイブ・

ログ・バックアップではなく）データベース・バックアップの実行中に RMAN 圧縮を無効にすると、CPU

オーバーヘッドが減り、引き続き非常に高いバックアップとリストアのスループットが達成され、Oracle

Cloud Infrastructure Object Storage の利用率が軽減されます。パフォーマンス・テストと RMAN コマンドの

例については、「付録 C」を参照してください。

4. 制御ファイルをバックアップの保存期間と同じ期間維持する

制御ファイルの保存期間はオブジェクト・ストレージ保存期間と同じ値または

bkup_oss_recovery_window に 8 日間をプラスした値へと自動調整されます。最大

bkup_oss_recovery_window は 90 日です。

5. デフォルトのアーカイブ・バックアップ頻度は、RPO の可能性を最小限にするために 1 時間にする

bkup_archlog_frequency 設定によって、RMAN バックアップ cron ジョブが開始されて、Oracle Cloud

Infrastructure Object Storage にバックアップされていないアーカイブすべてが確実にバックアップされます。

その結果、データ損失が制限されるか、RPO の超過が 1 時間強に制限されます。Cloud Release 18.2.3.1 以

降、この値を変更して、最小 15 分に減らすオプションがあり、RPO 超過がさらに減ります。アーカイブさ

れていないオンライン REDO ログで検出された変更またはデータはカバーされません。MAA ベスト・プラ

クティスを利用して、ログ・スイッチ頻度を低く設定し（15 分に 1 回）、データベース・パフォーマンスを

最適化することもできます。ゼロまたはゼロ秒未満レベルの RPO、または 30 分未満のより確実な RPO を達

成するには、MAA では、Oracle Data Guard、およびスタンバイ・データベースをホストする、Oracle Cloud

Infrastructure 内の個別 Exadata という構成を推奨します。「Using Oracle Data Guard in Exadata Cloud

Service 」（ https://docs.oracle.com/en/cloud/paas/exadata-cloud/csexa/use-data-guard-this-

service.html#GUID- FB63CBB2-74E1-4FD6-AFFA-4F902008223C）を参照してください。

https://docs.oracle.com/en/cloud/paas/exadata-cloud/csexa/use-data-guard-this-service.html#GUID-FB63CBB2-74E1-4FD6-AFFA-4F902008223C




観測/予測されたバックアップとリストアのパフォーマンス

これらのパフォーマンス結果は、以下の構成で観測されました。

• Oracle Cloud 18.2.5.1 以上

• Oracle Exadata クォーター・ラック以上

• Oracle Exadata バージョン 18.1.6 以上

• Oracle Database バージョン 12.2（12.2.0.1.180116）以上

以下に示すバックアップとリストアの結果は、Oracle Exadata X7-2 クォーター・ラック（データベース・

ノード当たり 92 CPU コアと 742 GB の RAM）1 台で稼働する 12.8 TB の 1 つのコンテナ・データベースと 6

つのプラガブル・データベース（プラガブル・データベースのうち 4 つは圧縮されず、1 つは OLTP で圧縮

が実行され、1 つは HCC Query High で圧縮が実行されました）に対して実行されたテストに基づきます。

Swingbench ワークロード 2000～2500 TPS および 5 %～8 %の変更速度/日がデータベースに対して使用され

ました。ワークロードの稼働中にバックアップが実行されました。

バックアップとリストアのスループットは変更速度とデータ分散によって異なる場合がありますが、これら

の例では潜在的なバックアップ/リストアのパフォーマンス予測値を示します。


RMAN全体バックアップ

以下の図 1 に、RMAN データベースの全体バックアップ・テストの結果を示します。テストはさまざまな RMAN

チャネルとデフォルトの LOW 圧縮を使って実施されました（「付録 A」を参照）。デフォルトでは、RMAN 全

体バックアップは週に 1 回実行されます。CPU オーバーヘッドを低減させるために、チャネル数を減らすこと

はできますが、バックアップ期間が長くなります。

図1:RMAN全体データベース・バックアップ

さまざまなパラレル化設定を使った RMAN 全体バックアップ・パフォーマンスの所見：

合計 8 チャネル（ノードあたり 4 個）のデフォルトの RMAN パラレル化設定では、バックアップ操作により 2.1

TB/時のスループットと 1.52 %の CPU オーバーヘッドという結果になります。

合計 16 チャネルの RMAN パラレル化設定と LOW 圧縮では、バックアップ操作により 4.64 TB/時のスループッ

トと 2.73 %の CPU オーバーヘッド→より高いバックアップ・スループットを達成したい場合に推奨します。

RMAN チャネルを合計 48 以上に増やすと、10.51 TB/時を超えるスループットと 8 %未満の CPU オーバーヘッド

という結果になります。

上記の合計チャネル数の推奨値は、Exadata データベース・サーバーで 92 の CPU コアをすべて利用しているフ

ル搭載の Exadata クォーター・ラックを対象としています。有効化された CPU コア総数が大幅に少ない場合は、

RMAN チャネルの総数を減らす必要があります。

結論：RMAN チャネルを増やすと、バックアップ・スループットが直線的に高くなります。ただし、RMAN チャ

ネルを増やすと、CPU オーバーヘッドが大きくなることが観測されています。RMAN チャネル総数を 8～96 に

することを推奨します。


RMAN増分バックアップ

増分バックアップの目標は、前回のバックアップ以降に変更されたデータ・ブロックのみをバックアップする

ことです。増分バックアップのスループットは“有効スループット”、またはデータベース合計サイズで除算され

る、データベース・リカバリ可能性に必要な増分変更のバックアップにかかる時間と見なされます。デフォル

トの増分バックアップは、指定された全体バックアップの日を除いて毎日実行されます。

図2：RMAN増分データベース・バックアップ

さまざまなパラレル化設定での RMAN 増分バックアップ・パフォーマンスの所見：

合計 16 チャネルの RMAN パラレル化と LOW 圧縮では、バックアップ操作により 21 TB/時の有効スループット

と 2.55 %の CPU オーバーヘッドという結果になります。

合計チャネル数を 48 に増やした場合、有効スループットは 23 TB/時に増えますが、CPU オーバーヘッドが

2.96 %へと上昇します。

上記の合計チャネル数の推奨値は、Exadata データベース・サーバーで 92 の CPU コアをすべて利用しているフ

ル搭載の Exadata クォーター・ラックを対象としています。

結論：デフォルトのバックアップ戦略と構成では、オーバーヘッドがわずかしか生じない（2 %未満）一方で、

毎日の増分バックアップ速度（18 TB/時）は非常に速くなり、全体バックアップ速度も許容範囲内（2.1 TB/時）

です。


全体バックアップからのRMANリストア

リストアとリカバリの操作中、データベースの RTO を短縮するために RMAN チャネル数を増やすことができま

す。目標は、適切なチャネル数でスループットを最大化することです。

図3：RMAN全体データベース・バックアップ

RMAN リストアのパフォーマンス観測：

合計 48 チャネルの RMAN パラレル化では、8.6 TB/時のリストア・スループットと 21.8 %の CPU 利用率になり

ます（推奨）。

クラウド・ツールで使用されるデフォルトの RMAN パラレル化は低すぎます。この場合、MAA では、データ

ベースのリストア操作中、チャネル総数を増やすことを推奨します。

結論：目標はリストア操作中にスループットを最大化して RTO を短縮することです。48 のチャネルを使用する

ことを推奨します。その場合、クラウド・ツールを使わない明示的な RMAN リストア操作が必要です。

バックアップとリストアのメンテナンス作業

推奨される RMAN メンテナンス作業は、バックアップのクロスチェックと検証を行うことです。クラウド・

データベース・バックアップ API は自動的にバックアップに対して CROSSCHECK と DELETE OBSOLETE を実行し

ます。RMAN の RESTORE VALIDATE を手動で実行する必要があります。

クラウド・バックアップのこの重要な自動クロスチェックは、デフォルトで毎日実行され、オーバーヘッドが

ほとんど発生しません。バックアップ・セットまたはピースが欠落している場合は、削除する必要があります。

クロスチェックでは、欠落したバックアップ・セット/ピースが期限切れとしてマークされるだけであり、オブ

ジェクト・ストレージから何も削除または除去されません。


期限切れとしてマークされたバックアップ・セット/ピースは、"DELETE OBSOLETE"コマンドの保存方針によっ

て考慮されません。

推奨される RESTORE VALIDATE 操作を、少なくとも毎月 1 回手動で実行する必要があります。

Oracle RMAN の RESTORE VALIDATE は、バックアップ・セットを読み取って破損がないかをチェックします。

RMAN の RESTORE VALIDATE コマンドは、通常のリストア操作として実行されますが、データベース・ストレー

ジにデータを書き込むオーバーヘッドが生じません。データは、検証のためにオブジェクト・ストレージの

バックアップからデータベースにストリーミングされ、検証後に破棄されます。クラウド・データベース・

バックアップ API では、reval_start 引数を使用して、RMAN の VALIDATE オプションを指定できます。

クラウド API を使用しない場合のパフォーマンスの例については、「付録 B」を参照してください。

さまざまなパラレル化設定を使った、圧縮された全体バックアップからの RMAN の RESTORE VALIDATE のパ

フォーマンスに関する所見：

合計 8 チャネルのデフォルトの RMAN パラレル化設定の場合、RESTORE VALIDATE 操作により 2.42 TB/時のス

ループットと 2.28 %の CPU オーバーヘッドという結果になります。

アプリケーション・パフォーマンスに影響せずに追加の CPU ヘッドルームが利用可能な場合は、RMAN パラレ

ル化を上げることができます。以下にパフォーマンスの例を示します。

合計 24 チャネルの RMAN パラレル化では、7.42 TB/時のスループットと 8 %未満の CPU オーバーヘッドとなり

ます。RMAN チャネルを合計 48 に増やすと、12.92 TB/時のスループットと 12 %未満の CPU オーバーヘッドと

いう結果になります。

RMAN の RESTORE VALIDATE コマンドでは、バックアップをブロック・レベルでチェックし、すべてのデータ

ベース・ファイルが存在して物理的および論理的破損がないことを確認することにより、リストアを確実に実

行可能にします。データ保存要件が大きい場合は、以下のように指定したデータ制限を使って検証することを

推奨します。


restore database validate until time "to_date('2019-03-07 22:58:37','YYYY-MM-DD

HH24:MI:SS')";

または

restore database validate until time "SYSDATE - 7";

最後に、推奨される完全なリストア/リカバリのテストを四半期ごとに手動で実施する必要があります。

さまざまなパラレル化設定において、RMAN 圧縮時に RESTORE VALIDATE の check logical を使った場合のパ

フォーマンスに関する所見：

デフォルトの合計 8 チャネルの場合、RESTORE VALIDATE 操作により 2.55 TB/時のスループットと 3.70 %の CPU

オーバーヘッドという結果になります。合計 16 チャネルの RMAN パラレル化では、4.89 TB/時のスループット

と 6.44 %の CPU オーバーヘッドとなります。

RMAN チャネルを合計 64 に増やすと、15.13 TB/時のスループットと 19.95 %の CPU オーバーヘッドという結果

になります。例については、「付録 B」を参照してください。

結論：バックアップの検証は重要であり、毎月実施することを推奨します。この作業は、CPU オーバーヘッド

を許容できる期間に実施する必要があります。メンテナンス作業の時間を短縮するために、チャネル数を増や

してもかまいませんが、CPU オーバーヘッドも増えます。


結論

Oracle Database Backup Cloud Service は、Oracle データベースを保護するための有効で低コストなソリューショ

ンです。MAA 構成と運用プラクティスを利用することにより、Oracle Cloud オブジェクト・ストアからのリス

トアおよびリカバリ操作の成功度が上がり、予測しやすくなります。


付録A

この付録のテストは、RMAN 圧縮なしで実行されました。DBaaS API またはクラウド・ツールを使って、非圧縮

時のバックアップ/リストア操作を行うことはできません。RMAN コマンドを直接実行します。「付録 D」を参

照してください。

RMAN全体バックアップ

さまざまなパラレル化設定を使った、RMAN 非圧縮時の全体バックアップ・パフォーマンスの所見：

合計 16 チャネルの RMAN パラレル化では、2 TB/時のスループットと 1.18 %の CPU オーバーヘッドとなります。

RMAN チャネルを合計 48 にまで増やすと、最大 4.73 TB/時と 3 %未満の CPU オーバーヘッドとなります。

サンプルの RMAN レベル 0 のバックアップ・スクリプト：

RUN

{

CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO BACKUPSET PARALLELISM 32;

BACKUP DEVICE TYPE SBT INCREMENTAL LEVEL 0 TAG ‘MY-TAG’ AS BACKUPSET SECTION SIZE 64G

DATABASE PLUS ARCHIVELOG NOT BACKED UP FORMAT '%d_%U' DELETE INPUT;

}


RMAN増分バックアップ

さまざまなパラレル化設定を使った、RMAN 非圧縮時の増分バックアップ・パフォーマンスの所見：

合計 16 チャネルのデフォルトの RMAN パラレル化では、19 TB/時の有効スループットと 2 %未満の CPU オー

バーヘッドとなります。

合計 32 チャネルの RMAN パラレル化では、23 TB/時の有効スループットと 3 %未満の CPU オーバーヘッドとな

ります（推奨）。RMAN チャネルを合計 48 にまで増やすと、最大 24 TB/時の有効スループットと 3 %未満の

CPU オーバーヘッドとなります。

サンプルの RMAN レベル 1 のバックアップ・スクリプト：

RUN

{


BACKUP DEVICE TYPE SBT INCREMENTAL LEVEL 1 TAG ‘MY-TAG’ AS BACKUPSET SECTION SIZE 64G

DATABASE PLUS ARCHIVELOG NOT BACKED UP FORMAT '%d_%U' DELETE INPUT;

}


全体バックアップからのRMANリストア

さまざまなパラレル化設定を使った、RMAN 非圧縮時の全体リストア・パフォーマンスの所見：

合計 48 チャネルの RMAN パラレル化では、7.61 TB/時のリストア・スループットと 11.71 %の CPU 利用率にな

ります。

サンプルの RMAN リストア・スクリプト：

RUN

{


RESTORE DATABASE;

RECOVER DATABASE;

}


付録B

この付録のテストは、RMAN 圧縮なしでバックアップから実行されました。

さまざまなパラレル化設定を使った、RMAN 非圧縮時の RESTORE VALIDATE でのパフォーマンスに関する所見：


ます。

RMAN チャネルを合計 48 に増やすと、7.87 TB/時のスループットと 8 %未満の CPU オーバーヘッドという結果

になります。


さまざまなパラレル化設定において、RMAN 非圧縮時に RESTORE VALIDATE の check logical を使った場合のパ

フォーマンスに関する所見


ます。

RMAN チャネルを合計 48 に増やすと、7.46 TB/時のスループットと 5.19 %の CPU オーバーヘッドという結果に

なります。

バックアップ API または RMAN スクリプトを使った、サンプルの RESTORE VALIDATE：

# /var/opt/oracle/bkup_api/bkup_api reval_start --dbname=mydb

For a complete list of options using the cloud backup API, please refer to the documentation: https://docs.oracle.com/en/cloud/paas/exadata-cloud/csexa/back-and-recover.html

Sample RMAN restore validate code: RUN {

CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO BACKUPSET PARALLELISM 48; RESTORE DATABASE VALIDATE FROM TAG 'MY-TAG-COMP'; }

Sample RMAN restore validate code – with check logical: RUN { CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO BACKUPSET PARALLELISM 48; RESTORE DATABASE VALIDATE CHECK LOGICAL FROM TAG 'MY-TAG-COMP'; }


付録C

レベル 0 のバックアップ・テストがプラガブル・データベースに対し、非圧縮データと LOTP 圧縮データという

条件下で実行されました。以下の表に、観測されたさまざまなメトリックを示します。

データ

ベース

サイズ

（GB）

データベース

圧縮

RMANチャネル

総数 RMAN 圧縮期間

スループット

（TB/秒）

CPU（%）-

バックアップに

よる増加

PDB1 2370.09 なし 8 なし 9291 0.9 1

PDB1 2370.09 なし 16 なし 5561 1.5 2

PDB1 2370.12 なし 32 なし 2202 3.78 6

PDB1 2370.1 なし 48 なし 2225 3.74 7

PDB1 2370.15 なし 8 LOW 5097 1.63 6

PDB1 2370.19 なし 16 LOW 1877 4.44 16

PDB1 2370.19 なし 32 LOW 1275 6.54 27

PDB1 2370.24 なし 48 LOW 1335 6.24 26

PDB4 2461.03 OLTP 8 なし 9119 0.95 2

PDB4 2461.41 OLTP 16 なし 5448 1.59 3

PDB4 2461.57 OLTP 32 なし 2169 3.99 7

PDB4 2460.99 OLTP 48 なし 2255 3.84 7

PDB4 2461.08 OLTP 8 LOW 5917 1.46 6

PDB4 2461.39 OLTP 16 LOW 1879 4.61 15

PDB4 2461.47 OLTP 32 LOW 1333 6.49 25

PDB4 2461.54 OLTP 48 LOW 1379 6.28 25


付録D

バックアップ API によって使用されるデフォルトの RMAN チャネル数を変更するには、 option

bkup_channels_node を設定します。

例：# /var/opt/oracle/ocde/assistants/bkup/bkup -bkup_channels_node=8 -dbname=mini

上記の例では、クラスタ内のノードごとに 8 個の RMAN チャネル、クラスタ全体で最大合計 64 個のチャネルを

設定します。

バックアップ API によって使用される圧縮アルゴリズムを変更するには、オプション bkup_rman_compression

を設定します。このオプションには LOW（デフォルト）、MEDIUM、High の値を指定できます。

例：# /var/opt/oracle/ocde/assistants/bkup/bkup -bkup_rman_compression="MEDIUM" -dbname=mini

上記の例では、デフォルトのバックアップ圧縮アルゴリズムを LOW から MEDIUM に変更します。

以下に、サンプルのバックアップ構成ファイルを示します。

bkup_disk=no

bkup_oss=yes

bkup_oss_url=https://myobjectstorage.uk-london-1.oraclecloud.com/v1/mytenancy/bkup_bucket

bkup_oss_user=ociuser1

bkup_oss_passwd=********

bkup_oss_recovery_window=90

bkup_daily_time=01:00

bkup_cron_entry=yes bkup_channels_node=8

bkup_rman_compression=MEDIUM

バックアップ API を使用せずに非圧縮バックアップを実行する必要があります。バックアップを開始する前に、

以下の手順を実行する必要があります。

root ユーザーとして、バックアップ・エントリを/etc/crontab 内にコメントして、バックアップされるデータ

ベースを指定します。

#53 */1 * * * root /var/opt/oracle/bkup_api/bkup_api bkup_archlogs --dbname=mini

#01 01 * * * root /var/opt/oracle/bkup_api/bkup_api bkup_start --dbname=mini

Oracle ユーザーとして、RMAN 構成内で以下の変更を行います。

RMAN> CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 8 BACKUP TYPE TO BACKUPSET;

RMAN> CONFIGURE COMPRESSION ALGORITHM CLEAR;

付録 A と B に示す BACKUP、RESTORE、RESTORE VALIDATE のスクリプトを使って、データベースをオブジェク

ト・ストレージにバックアップすることができます。

上記の手順を実行したら、毎週の全体バックアップ、毎日の増分バックアップ、および定期的なアーカイブ・

ログ・バックアップをデータベースに対して手動で作成する必要があります。

Oracle Corporation, World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065, USA

海外からのお問い合わせ窓口

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

C O N N E C T W I T H U S

blogs.oracle.com/oracle

facebook.com/oracle

twitter.com/oracle

oracle.com

Copyright © 2019, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載されている内容は予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述による明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、いかなる他の保証や条件も提供するものではありません。オラクルは本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクルの書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。 Oracle および Java は Oracle およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。 Intel および Intel Xeon は Intel Corporation の商標または登録商標です。すべての SPARC 商標はライセンスに基づいて使用されるSPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMD ロゴおよび AMD Opteron ロゴは、Advanced Micro Devices の商標または登録商標です。UNIX は、The Open Group の登録商標です。0615 Cloud Object Storage を使用した、Oracle Cloud Infrastructure Exadata のバックアップとリストアのベスト・プラクティス 2019 年 5 月著者：Jony Safi 共著者：Lawrence To、Kelly Smith、Markus Michalewicz

Documents

Cloud Object Storageを使用した、Oracle Cloud …...5 | Oracle Database Backup Cloud – Object Storage を使用した、Oracle Cloud Infrastructure Exadata のバックアップとリストアのベスト・プラクティス