Oracle Database Cloud で作成できるデータベースの最大サイズについて

(2016年5月31更新 : 仕様変更にともなって最大サイズが少し大きくなりました)

Oracle Database Cloud (Database as a Service) を使うにあたってどのくらいの大きさのデータまで置くことができるの? という質問を受けることがあります。残念ながらクラウドだからといっていくらでもデータを配置できるというわけにはいかず、**バックアップありの場合で約4.7TB**、**バックアップなしの場合で約12TB**というのが、データベースの最大サイズの目安になります。

ここでは、じゃあなんでその値が制限になるの? という点を通じて、Oracle Database Cloud を使用する際のストレージ・ボリュームの構成方法について考えてみようと思います。

なお Database as a Service には、サービスレベルとして Automated (自動でデータベースのインストール、バックアップ設定、パッチ適用スクリプトなどを構成してくれるもの) と、 Virtual Image (素の仮想マシンの上に自由にデータベースをインストールする) の2つのタイプがあるのですが、今回は Automated についてのみが対象です。

# Compute Cloud の制限
フル・インスタンス・サービスである Database as a Service の場合、PaaS とはいいつつも IaaS である Oracle Compute Cloud Service の各種基盤の上に構築されています。このため配置できるデータ容量は、Compute Cloud の各コンポーネントの仕様上の制限を受けます。

Compute Cloud Service のデータ容量に関する主な制限には、以下のようなものがあります。

- ブロック・ストレージのボリューム1つあたりの最大サイズは2TB(2048GB)まで
- サービス・インスタンス(=仮想マシン)1つあたりにアタッチできるストレージ・ボリュームは最大10個[^a]まで

つまり、インスタンスあたり最大約20TBのボリュームというのが、基盤の観点から見た最大値ということになります。ただこれはあくまで「素の仮想マシン」が使用できる容量ですので、データベースとして使える容量としてはもっと小さくなります。

[^a]: 2016年5月より、インスタンスにアタッチできるボリュームが9個から10個に変更されました

# インスタンス作成時に作成されるボリューム
サービス・レベルに Automated を選択してサービス・インスタンスを作成すると、Oracle Database がインストールされ、データベース・インスタンスが起動した状態で仮想マシンが立ち上がってきます。このデータベースやデータなどは、予め仮想OSにマウントされた5つのストレージ・ボリュームに配置されています。

初期状態にアタッチされているストレージ・ボリュームは以下のとおりです。

| ボリューム名 | マウント・ポイント | 配置されるファイル | サイズ |
|:-----------|:----------------|:-----|:------|
| boot | /boot, /, /dev/shm | OSなど | 21GB |
| bits | /u01 | Oracle Databaseのソフトウェア・バイナリ | 30GB |
| data | /u02 | データファイル | **指定値** |
| fra | /u03 | フラッシュ・リカバリ領域(FRA)、バックアップファイル | **指定値☓1.7** または 7GB |
| redo | /u04 | オンラインREDOログ・ファイル | 10GB |

この中で、**data** と **fra** という2つのボリュームのサイズは、サービス・インスタンス作成の際にユーザーが指定する値によって変化します。**使用可能なデータベース記憶域(GB)** という箇所に指定した値が **data** ボリュームの大きさになります。

![WS000136.JPG](https://qiita-image-store.s3.amazonaws.com/0/117710/6bce7583-b955-9f81-4ed3-02a17aca88aa.jpeg "使用可能なデータベース記憶域(GB)に指定した値が、dataボリュームの大きさになります")

さらに **fra** については、バックアップを構成する否かによって大きさが変化します。バックアップを構成する (**クラウド・ストレージとローカル・ストレージ両方**を選択する) 場合には、fra は data ボリュームの1.7倍が確保されます。バックアップを構成しない (**なし**を選択する) 場合には、7GBが確保されます。

![WS000137.JPG](https://qiita-image-store.s3.amazonaws.com/0/117710/1f62ea76-bffc-85d0-f8f9-f56cec6f3f2c.jpeg "バックアップ構成の可否を選択画面")

**使用可能なデータベース記憶域(GB)** に指定できる最大値についてもバックアップ構成の有無によって変化します。バックアップを構成する場合には **1200GB**、バックアップを構成しない場合には **2048GB** がそれぞれ最大サイズになります。

![WS000138.JPG](https://qiita-image-store.s3.amazonaws.com/0/117710/b3be5b95-dadd-0022-20bb-d0ca73ff081e.jpeg "バックアップを構成する場合")

![WS000139.JPG](https://qiita-image-store.s3.amazonaws.com/0/117710/6a7fbdfb-badf-001b-5010-2c0d9197c287.jpeg "バックアップを構成しない場合")

これは、バックアップを行う場合には、**data 領域と fra 領域を 1:1.7 の割合にする**という、Oracle Database Cloud のベスト・プラクティスに基づいているためです。
1つのボリュームの最大サイズが2048GBのため、**1200GB : 2048GB = 約1:1.7** になるというわけです。

ここまで終わればインスタンスが作成されています。指定できる最大の値を指定して作成した場合には、**バックアップありの場合で1200GB**、**バックアップなしの場合で2048GB**が、データファイルの置き場として確保されていることになります。

# ボリュームの追加
さらに大きなサイズのデータを格納したい場合には、サービス・インスタンスの作成完了後にストレージ・ボリュームを追加することができます。

ストレージ・ボリュームの追加は、インスタンス詳細画面のメニューから スケール・アップ/ダウン を選択して実施することができます。

![WS000140.JPG](https://qiita-image-store.s3.amazonaws.com/0/117710/6bfe7300-085e-bd4b-f48c-94da54868e3e.jpeg "インスタンス詳細画面のメニューからスケール・アップ/ダウンを選択します")

1回のスケール・アップ操作を行う毎に、1つのストレージ・ボリュームが作成され、インスタンスにアタッチされます。

![WS000141.JPG](https://qiita-image-store.s3.amazonaws.com/0/117710/41a91561-9a8a-b524-17e8-54c612c45b0e.jpeg "スケール・アップ・ダウン")

ボリュームのアタッチ先は、ストレージの追加 に表示される3つの選択しから選ぶことができます。それぞれの選択肢とマウントされる先のボリュームは以下のとおりです。

| 選択肢 | マウント先 | マウント先の用途 |
|:---|:---|:---|
| 新規ストレージ・ボリュームの作成 | /u05以降の空き番号のマウントポイント | 任意 |
| データ・ストレージ・ボリュームの拡張 | /u02 | データファイル置き場 |
| バックアップ・ストレージ・ボリュームの拡張 | /u03 | フラッシュ・リカバリ領域(FRA) |

**Compute Cloud の制限** でもお伝えしたように、インスタンスあたりにアタッチできるストレージ・ボリュームは最大10個です。このうちインスタンス作成時に5個がアタッチ済ですので、スケール・アップ操作によるボリュームの追加は残り5回までとなります。

ちなみに、このうち **データ・ストレージ・ボリュームの拡張** と **バックアップ・ストレージ・ボリュームの拡張** を選択した場合には、アタッチされたボリュームは Linux LVM によって構成済みの論理ボリュームの中に参加するため、それぞれのマウントポイント(/u02、/u03)のボリュームが拡張されたように見えます。

# データベース最大サイズの考察
さていよいよ、ここからがデータベースの最大サイズに関するお話になります。

バックアップなしで構成した場合には簡単です。
インスタンス作成時に、データファイル置き場(/u02)には2048GBが割り当て済みで、残り5回のボリューム追加をすべてデータ・ストレージ・ボリュームの拡張に使用することができます。このため、

2048GB(初期) + 2048GB(拡張) ☓ 5回 = **12288GB**

がデータベースの最大サイズになります。

バックアップありで構成した場合には、1200GB(初期) + 2048GB(拡張) X 5回 = 11440GB が最大サイズになりそうですが、ここで先程の **data 領域と fra 領域を 1:1.7 の割合にする**というベスト・プラクティスが出てくるため、拡張分すべてをdata領域には回せず、data領域2回 + fra領域3回とするか、data領域3回 + fra領域2回とするか、拡張の回数をどちらかから選ぶことになります。

### ケース1 : 5回の拡張のうち、2回をdata領域、3回をfra領域とした場合

data領域 = 1200GB(初期) + 2048GB(拡張) x 2回 = 5296GB
fra領域 = 2048GB(初期) + 2048GB(拡張) x 3回 = 8192GB

となりそうですが、data:fra = 1:1.7 なので、

data領域 = fra領域(8192GB) * 1 / 1.7 = 4819GB

となります。

### ケース2 - 5回の拡張のうち、3回をdata領域、2回をfra領域とした場合

data領域 = 1200GB(初期) + 2048GB(拡張) x 3回 = 7344GB
fra領域 = 2048GB(初期) + 2048GB(拡張) x 2回 = 6144GB

となるところ、data:fra = 1:1.7 なので、

data領域 = fra領域(6144GB) * 1 /1.7 = 3614GB

となります。

ケース1とケース2では、ケース1の方がより大きなデータベースの容量を取れますので、バックアップありの場合のデータベースの最大サイズは、 4819GB = **約4.7TB** となります。ふぅ、ようやくこの数字にたどり着きましたね。

実際にバックアップありの場合に、最大サイズのデータベースを作成するには、

1. 初期のデータサイズ1200GB(上限)でデータベースを作成
2. data領域に、2048GB(最大サイズ)のボリュームを追加
3. data領域に、1571GBのボリュームを追加
4. fra領域に、2048GBのボリュームを3回追加

という手順を取ることになります。

# まとめ
このように、Oracle Database Cloudで、ストレージ・ボリュームを管理するには少しコツが必要になります。特に将来データが増加することが予想される場合には、**1インスタンスあたりアタッチできるボリュームは最大10個まで**、**1ボリュームの最大サイズは2048GB**、**バックアップを取得する場合にはdata領域とfra領域を1:1.7**、という制限に引っかかって慌てることのないように、あらかじめ大きいサイズ(1200GBや2048GB)を指定してインスタンスを作成しておくことをおすすめします。