【ORACLEのお勉強#01】テーブル、表領域、データファイル、ディスクの関係

■ORACLEの論理と物理

　ORACLEで言うところの論理と物理って何だろうと考えてみました。※1
　10年以上、ORACLEと付き合って来た私は、以下の図の通りという認識です。
　物凄く簡略化していますが、こういった感じです。

　・論理的なところ
　　・テーブル
　　・表領域
　　　(他にもマテリアライズドビューやシーケンスもありますが、省略しています。)

　・物理的なところ
　　・データファイル
　　・ディスク
　　　(他にもREDOログや制御ファイルもありますが、省略しています。)

　スクリプトで上記の図を表現すると、以下の通りです。

・テーブル
CREATE TABLE TEST_TABLE
(
TEST_COL1 CHAR(3),
TEST_COL2 CHAR(3),
TEST_COL3 VARCHAR2(10)
) TABLESPACE TEST_TABLESPACE;

・表領域
CREATE TABLESPACE TEST_TABLESPACE
DATAFILE '/oracle/data/test_datafile.dbf' SIZE 100M;

■テーブルが出来るまで

　物に例えるとかえって分かりにくくなると思ったし、ORACLE用語のままのほうがスムーズに説明できるので、多少、専門用語が出てきますが頑張ってください。
　まずは、どういう順番でディスクからテーブルまでが構築されるか説明します。
　ORACLEはインストール済み、業務データが無いデータベースが作成済みとします。
　(SYSTEM表領域にあるデータだけを持った、実質空のデータベースです)

　1.データ領域用のディスクを用意します。
　2.そのディスクに表領域を作成します。
　　どのディスクの、どこのディレクトリにデータファイルを配置するかスクリプトにて定義します。
　3.表領域指定してテーブルを作成します。

　テーブルを作るときに意識するのは表領域とテーブルサイズだけで、どこのディスクのどのデータファイルに作られるかと言った物理的な事は意識する必要ありません。
　こう言った感じで物理から始まって論理に向かって行くわけです。
　DBAが意識するのは1と2で、開発者が意識するのは3です。
　つまり、開発者はどのテーブルにどんなデータが入っているかだけを気にし、DBAは表領域、ディスク、データファイルのサイズと使用量を気にしています。

　では、データベース設計の時はどうなのかと言うと実は、構築時の逆、論理的なところからスタートします。

　1.全テーブルのサイズを計算します。
　2.各テーブルをどの表領域に格納するかを決めます。
　3.表領域のサイズを決めます。
　　サイズは表領域に配置する各テーブルのサイズを合計したものになります。
　4.各表領域をどのディスクに配置するか決めます。
　　ASMの場合は、どのASMディスクグループに配置するかを決めることになります。
　5.ディスクのサイズを決定します。
　　各ディスクは、3で計算した表領域を配置できるサイズを用意します。
　　余裕を持たせて大きめのサイズにすることが多いです。

　最初は業務から情報を引き出すところからです。
　業務から訊き出した各テーブルのカラム数、型、桁数そして、格納されるであろう最大件数が、最後に用意されるディスクのサイズに影響します。
　ソフトウエア開発のV字モデルのような形がここでも出て来ていて、これに気付いたとき既視感を覚えたものです。

■実際の運用

　本番運用が始まると、データベースは容易に変更できなくなります。
　データベースの変更は、業務サービスの停止を余儀なくされる場合が多いからです。
　それでも変更がどうしても必要な場合は、お客さんと調整して土日などにシステムを停止して変更を行います。
　変更が多い順に並べると、テーブル、表領域、データファイル、ディスクとなります。
　健全な設計を行ってきたデータベースなら、変更対象のほとんどがテーブルであり、表領域やデータファイルに変更は余り無いと言っても過言ではありません。
　逆に設計時のサイジングが適当だった場合、ディスクの追加や表領域の作り直しと行った大規模で時間の掛かる作業を、本番環境で行う羽目になります。
　それだけは避けたいので、最初のテーブルサイズ計算から慎重に行うのが大事です。

■まとめ

　こうして物理層と論理層が分かれているため、開発する側と管理する側で、お互いを意識しなくていいようになっている訳です。
　表領域を別のディスクに再配置したりサイズを大きくしても、プログラムを変える必要は無いですし、プログラムを作るうえでテーブルがどこのディスクにあるかを考える必要はありません。
　ディスクというハードに寄れるば寄る程、物理的な立場にいると言えるし、遠ざかる程、論理的な立場にいると言えます。
　どちらが優れているとかと言うわけでは無くて、役割の違いだけだと思ってます。
　ただ、物理に近い部分を扱うようになるとOSやハードの知識が必要になるのは確かだし、論理に近くなればテーブルのつながりや業務の知識が必要になって来ると思います。
　どちらの立場にいても、時間に余裕があればお互いのことを少し知っておくと開発が円滑に進むかもしれません。

-------------------------------------------------------------------------

※1：考えたのはデータ領域についてのみです。
　　REDOログ、制御ファイル、UNDO、一時表領域は割愛しました。
　　ORACLEのソフトウエア自体がインストールされている領域についても考慮していません。