忍者ブログ
データベースエンジニアのための実践ブログ。Oracle・PostgreSQL・MySQLなどの環境構築、実行計画の読み方やチューニングといった現場で役立つノウハウ、DB基礎知識までを発信しています。

【Oracle 26ai/23ai】11gからのステップアップ!Oracleマルチテナント(CDB/PDB)完全ガイド

Oracle Database 12c以降から導入され、現代のOracle環境(23ai/26aiなど)における標準アーキテクチャとなった「マルチテナント(CDB/PDB)」。
従来の非マルチテナント(非CDB)環境に慣れ親しんだエンジニアにとって、CDBとPDBの関係性や運用方法の違いは最初に押さえておきたい重要ポイントである。

今回は、マルチテナントアーキテクチャの基本概念から接続方法、バックアップ、リスナー、リソース制御までの全体像をわかりやすく整理した。


1. CDBとPDBの基本概念

Oracleのマルチテナント構造は、よく「分譲マンション」に例えると構造を掴みやすくなる。

  • CDB (Container Database) = マンションの建物・管理室・共有設備
    メモリ(SGA/PGA)やバックグラウンドプロセスなどの共通リソースを保持し、システム全体を管理・監視する「親データベース」。
  • PDB (Pluggable Database) = マンションの各部屋(専有スペース)
    業務データやテーブルを個別に保持する独立した「子データベース」。お互いの PDB は完全に分離されている。

CDB と PDB の役割比較

比較項目CDB (Container Database)PDB (Pluggable Database)
役割 システム全体のリソース管理・共通基盤 アプリケーションデータの格納・実行
主な利用者 データベース管理者(DBA) アプリケーション開発者・一般ユーザー
接続用途 DB全体の保守・監視・バックアップ Webアプリや外部ツールからのデータ操作

2. アプリケーションからの接続

Java、Python、あるいは DBeaver などの外部開発ツールから接続する場合、原則として「PDB へ接続」することが基本となる。

【接続先の指定例】
・業務アプリ利用:localhost:1521/FREEPDB1 (PDBのサービス名)
・全体管理作業:localhost:1521/FREE (CDBのサービス名)

環境の隔離:
1つの CDB 上に開発用 PDB(DEV_PDB)と検証用 PDB(TEST_PDB)を独立して同居させることが可能。

3. バックアップと運用の単位

マルチテナント環境では、目的に応じてバックアップの粒度を柔軟に選択できる。

  • CDB単位(全体物理バックアップ)
    RMAN を使用し、全 PDB を含めた CDB 全体を一括バックアップ。サーバー全体の障害対策やインフラ移行に適している。
  • PDB単位(個別物理リカバリ・複製)
    特定の PDB のみを停止・バックアップ・復元。稼働中の他 PDB に影響を与えずに、PDB の複製(Clone)や別 CDB への移植(Plug/Unplug)が可能。
  • 論理バックアップ
    expdp / impdp を使い、特定の PDB やスキーマ単位でデータをダンプファイルとして抽出する。

4. リスナーとの対応関係

リスナーは CDB(サーバー・インスタンス)単位で 1 つ存在 する。
マンションで言えば「エントランスの総合受付(コンシェルジュ)」である。各 PDB ごとに個別リスナーが存在するわけではなく、1 つのリスナーがポート 1521 への通信を一括受領する。

[アプリ / クライアント] ──(Port 1521)──> [ リスナー (受付) ]
                                              │
                    ┌─────────────────────────┴─────────────────────────┐
                    ▼ (サービス名: FREE)                                 ▼ (サービス名: FREEPDB1)
             ┌──────────────┐                                    ┌──────────────┐
             │  CDB (FREE)  │                                    │ PDB(FREEPDB1)│
             └──────────────┘                                    └──────────────┘

クライアントから渡された「サービス名」をリスナーが判定し、該当する CDB や PDB へルーティングする。PDB を追加した場合も、DB が自動でサービス名をリスナーへ登録するため、リスナーの再設定は不要となっている。


5. CDBによる一元リソース制御

各 PDB への CPU、メモリ、I/O、ストレージなどのリソース割り当ては、親である CDB が 一元管理 する。
マンションの管理組合(CDB)が各部屋(PDB)の使用上限を決める仕組みであり、主に以下の方法で制御を行う。

  • CPU / I/O 制御(CDBリソース・マネージャ)
    PDB ごとに CPU の最低保証割合(Shares)や最大使用上限(Utilization Limit)を設定できる。
  • メモリ・ストレージ制御
    PDB ごとに初期化パラメータで SGA/PGA の利用限度額を指定するほか、PDB の最大ディスク容量(MAX_SIZE)を設定可能。

この設定により、特定の PDB で重い処理が発生した際にも他の PDB が巻き添えで低速化する「ノイジー・ネイバー(うるさい隣人)問題」を効果的に防止することができる。

【11g経験者が押さえるべきマルチテナントの勘所】
✔ 接続時は従来のSID指定だけでなく、PDBの「サービス名(例: FREEPDB1)」を指定してルーティングする。
✔ CDB全体の管理(バックアップやインスタンス起動)と、PDB個別の操作(スキーマ・データ操作)を明確に意識する。
✔ 複数テナント集約時のリソース競合は「CDBリソース・マネージャ」でスマートに制御する。
PR

【Oracle 26ai】RHEL 10環境へ「Oracle AI Database 26ai Free」をネイティブ導入する

最新の次世代データベースである「Oracle AI Database 26ai Free」を、完全無料のRHEL 10互換環境(CentOS Stream 10やAlmaLinux 10など)にRPMで直接インストール(ネイティブ導入)するための手順をまとめた。

RHEL 10世代では、専用の事前準備パッケージ(Preinstall RPM)や本体パッケージが公式に提供されており、手順に沿って進めることでスムーズに最新のAIデータベース環境を構築できる。


【前提条件】

  • 作業は sudo 権限を持つユーザー(または root ユーザー)で実施すること。
  • サーバーがインターネットに接続でき、標準のリポジトリから依存パッケージを取得できること。

1. パッケージのダウンロードとサーバーへの配置

Oracle 26ai Free をインストールするためには、以下の2つの RPM ファイルを RHEL 10 サーバー上の任意の作業ディレクトリ(例: /tmp)に配置する。

  • ・事前準備 RPM: oracle-ai-database-preinstall-26ai-1.0-1.el10.x86_64.rpm
  • ・データベース本体 RPM: oracle-ai-database-free-26ai-23.26.2-1.el10.x86_64.rpm

パターンA: サーバー上で直接ダウンロードする場合(推奨)

# 作業ディレクトリに移動
cd /tmp

# 事前準備(Preinstall)パッケージのダウンロード
curl -O https://yum.oracle.com/repo/OracleLinux/OL10/appstream/x86_64/getPackage/oracle-ai-database-preinstall-26ai-1.0-1.el10.x86_64.rpm

# Oracle 26ai Free 本体パッケージのダウンロード
curl -O https://download.oracle.com/otn-pub/otn_software/db-free/oracle-ai-database-free-26ai-23.26.2-1.el10.x86_64.rpm

※ダウンロード先 URL は Oracle の公開仕様に基づきます。

パターンB: 手元のPCでダウンロード済みのファイルを転送する場合

すでに Windows や Mac のブラウザでダウンロード済みの場合は、SCP クライアント等を使って RHEL 10 サーバーへ転送する。

# (例) Mac/Linux などの手元のPCからコマンドで転送する場合
scp oracle-ai-database-preinstall-26ai-1.0-1.el10.x86_64.rpm [ユーザー名]@[サーバーのIPアドレス]:/tmp/
scp oracle-ai-database-free-26ai-23.26.2-1.el10.x86_64.rpm [ユーザー名]@[サーバーのIPアドレス]:/tmp/

2. 依存パッケージと事前設定 RPM のインストール

ファイルがあるディレクトリに移動し、Preinstall パッケージをインストールする。これにより、必要な依存関係の解決、OS ユーザー(oracle)の自動作成、カーネルパラメータの自動チューニングが行われる。

cd /tmp

# 事前準備パッケージのインストール
sudo dnf install -y ./oracle-ai-database-preinstall-26ai-1.0-1.el10.x86_64.rpm

3. Oracle 26ai Free 本体 RPM のインストール

続いて、データベース本体の RPM ファイルをインストールする。

# データベース本体のインストール
sudo dnf localinstall -y ./oracle-ai-database-free-26ai-23.26.2-1.el10.x86_64.rpm

4. データベースの構築・初期設定

インストールが完了したら、構成スクリプトを実行してデータベースを作成する。この手順で SYS / SYSTEM / PDBADMIN ユーザー共通の管理用パスワードを設定する。

# 構成スクリプトの実行
sudo /etc/init.d/oracle-free-26ai configure
【注意事項】
・スクリプト実行中、パスワードの入力を求められます。
・セキュリティ要件として、8文字以上で、大文字・小文字・数字をすべて含むパスワードを入力してください(入力した文字は画面に表示されません)。

データベースの作成が完了すると、以下のようなメッセージとログ出力先が表示される。

データベース情報:
グローバル・データベース名: FREE
システム識別子(SID): FREE
詳細はログ・ファイル "/opt/oracle/cfgtoollogs/dbca/FREE/FREE.log" を参照してください。

Connect to Oracle AI Database using one of the connect strings:
    Pluggable database: oracle26ai-server/FREEPDB1
    Multitenant container database: oracle26ai-server

5. 環境変数の設定

今後データベースの操作を行うユーザー(OS の oracle ユーザーや作業ユーザーなど)のプロファイル(~/.bash_profile)に環境変数を追加する。

# bash_profile に環境変数を明示的に追記
cat << 'EOF' >> ~/.bash_profile

# Oracle Database Environment Variables
export ORACLE_SID=FREE
export ORACLE_BASE=/opt/oracle
export ORACLE_HOME=/opt/oracle/product/26ai/dbhomeFree
export PATH=$ORACLE_HOME/bin:$PATH

# 日本語環境用の文字コード設定 (文字化け防止)
export NLS_LANG=Japanese_Japan.AL32UTF8
EOF

# 設定を現在のセッションに反映
source ~/.bash_profile

6. 動作確認・接続テスト

OS のコマンドラインから SQL*Plus を利用して、データベース(CDB および PDB)が正常に起動し、接続できるか確認する。

① CDB(コンテナ DB)へのローカル接続確認:

sqlplus / as sysdba

プロンプトが SQL> に変わったら、以下のコマンドで状態を確認する。

SQL> SELECT name, open_mode FROM v$database;

READ WRITE と表示されていれば正常である。

② PDB(プラガブル DB: FREEPDB1)へのネットワーク接続確認:

手順 4 で設定したパスワードを使用して接続テストを行う。

# 一旦 SQL*Plus を抜けてから以下を実行
sqlplus sys/[手順4で設定したパスワード]@localhost:1521/FREEPDB1 as sysdba

接続に成功すれば、導入はすべて完了となる。必要に応じてアプリケーションからの接続設定等を進めよう。


【データベース】分散システムの限界を示す!CAP定理(CAP Theorem)とは

分散データベースやNoSQLの選定・設計において、避けて通れない非常に重要な理論が「CAP定理(CAP Theorem)」である。
(※一般に「CPA」ではなく「CAP」と呼ばれることが多い概念だ)

CAP定理とは、「分散システムにおいて『一貫性』『可用性』『分断耐性』の3つの性質を、同時にすべて(3つとも)満たすことはできない」というトレードオフの定理を指す。


1. CAP定理の3つの構成要素

分散システムが備えるべき3つの評価軸の定義は以下の通りである。

  • C:Consistency(一貫性)
    システムにあるオペレーションを行った後、どのノード(サーバー)にアクセスしても常に最新で同じデータ(一貫性)が保たれている性質。
    分散システムで一貫性を担保するためには、あるノードでデータ更新(Update)が発生した場合、他のすべてのノードにもその結果を即座に同期・反映しなければならない。
  • A:Availability(可用性)
    システムを構成するノードの一部が故障(ダウン)しても、システム全体としてはレスポンスを返し続け、正常に稼働し続けなければならない性質。
    エラーを返さず、常にすべての正常なノードが読み書きの要求に応答できることが求められる。
  • P:Partition Tolerance(分断耐性)
    ノード間を結ぶネットワークが障害等で分断され、通信が一時的に不通・切断されても、システムとしては停止せずに稼働し続けなければならない性質。

2. なぜ3つ同時に満たせないのか?

ネットワーク分断(P)が発生した状況を想像してみよう。ノードAとノードBの間で通信ができない状態である。

このとき、ノードAに書き込みリクエストが届いた場合、選択肢は2つしかない。

  • 選択肢①:一貫性(C)を優先する ➔ ノードBへデータ更新を同期できないため、エラーを返して書き込みを拒否する。(可用性 A が犠牲になる)
  • 選択肢②:可用性(A)を優先する ➔ ノードAだけで書き込みを完了させ、応答を返す。しかしノードBのデータは古いままになる。(一貫性 C が犠牲になる)

このように、現実の分散環境において「分断(P)」の発生を完全に回避することは不可能なため、実質的に分散システムは「CP型」か「AP型」のどちらかを選択(トレードオフ)せざるを得ないのである。


3. NoSQLにおけるCAPによる分類

近代のNoSQLデータベースは、この3つのうち「どれを重視し、どれを妥協するか」という設計思想(トレードオフ)によって、大きく3つのタイプに分類することができる。

【CAP特性によるデータベース分類】

■ CP型(一貫性 + 分断耐性)
・特徴:ネットワーク分断時はエラーを返してでもデータ不整合を防ぐ。
・代表例:HBase, MongoDB, Redis, Accumulo
・用途:金融決済や在庫管理など、絶対的なデータ整合性が求められるシステム。

■ AP型(可用性 + 分断耐性)
・特徴:データ整合性が一時的に崩れても、止まらずに読み書きに応答する(※結果的一貫性を重視)。
・代表例:Apache Cassandra, Amazon DynamoDB, CouchDB
・用途:SNSのタイムラインやアクセスログの収集など、止まらないことが最優先のシステム。

■ CA型(一貫性 + 可用性)
・特徴:ネットワーク分断が発生しない単一ノード(非分散環境)を前提とするモデル。
・代表例:従来の単一構成RDBMS(PostgreSQL, MySQL, Oracle DB など)
・注意:分散環境においてはネットワーク障害(P)の回避が困難なため、実質の選択肢としては「CP」か「AP」の2択となる。

4. まとめ

「すべての面で完璧なデータベース」は存在しない。システム要件に応じて、「一貫性(C)」を絶対に譲れないのか、あるいは「高可用性(A)」を取って一時的な不整合(Eventual Consistency:結果的一貫性)を許容するのかを見極めることが、適切なDB選定の第一歩となる。

【CAP定理から考えるデータベース選定の要点】
✔ 金融・決済・アカウント管理など、1円・1件のズレも許されない ➔ CP型(または伝統的RDBMS)
✔ ログ収集・SNS・カートの一時保持など、止まらないことが最優先 ➔ AP型
✔ AP型を採用する場合は「結果的一貫性(最終的にデータが合えばOK)」の思想を許容できるか確認する

【Oracle Cloud Free & DB】第7回:初期状態の「ユーザー」を暴く!PaaSの中に並ぶアカウントの正体


前回まで、Autonomous Database(26ai)の論理的な表領域の特性や、裏側に隠されたマルチテナント(PDB)固有の物理ファイルパスを確認してきました。ストレージ構造の次は、データベースの『セキュリティ』に切り込んでみましょう。
クラウドでインスタンスを作成した際、最初からどのようなユーザー(スキーマ)が定義されており、どんな状態で管理されているのか、データ・ディクショナリから実態を調査します。

1. 初期ユーザーの定義状態とアカウントステータス

まずは、データベース作成直後の初期状態で、どのようなユーザーが存在しているのかを一覧で確認します。Oracle全体のユーザー情報を一元管理している DBA_USERS ビューから、主要なユーザーとそのアカウント状態(STATUS)を抽出してみましょう。なお、このクエリはすべて切り出された私たちの個室(PDB)側の環境を覗いています。

★ 初期ユーザーの状態を確認するSQL:
SELECT username, account_status, default_tablespace, profile
FROM dba_users
ORDER BY username;


【実行結果(主要なユーザーの抜粋)】
"USERNAME","ACCOUNT_STATUS","DEFAULT_TABLESPACE","PROFILE"
"ADMIN","OPEN","DATA","BM_PROFILE"
"SYS","OPEN","SYSTEM","DEFAULT"
"SYSTEM","OPEN","SYSTEM","DEFAULT"
"AUDSYS","LOCKED","SYSAUX","DEFAULT"
"APPQOSSYS","LOCKED","SYSAUX","DEFAULT"
"DBSNMP","LOCKED","SYSAUX","MONITORING_PROFILE"
"OJVMSYS","LOCKED","SYSTEM","DEFAULT"
"XDB","LOCKED","SYSAUX","DEFAULT"

【結果解説:ACCOUNT_STATUS(アカウント状態)の意味】
ズラリと並んだ実行結果のステータスには、Oracleのセキュリティ設計の基本がそのまま現れています。

  • OPEN(オープン):現在、正常にログインして操作ができる「生きている」ユーザーです。私たちが使う ADMIN や、裏で常に稼働している主要なコアシステム(SYS や SYSTEM)など、ごく僅かなアカウントだけがこの状態を許されています。
  • LOCKED(ロック):アカウントが凍結されている状態です。これらはOracle内部の特定の機能(監査や監視など)を動かすためだけに用意された専用ユーザーであり、悪意ある第三者が乗っ取って外部から不正ログインできないよう、安全のために最初からガチガチに鍵がかけされています。
  • EXPIRED & LOCKED(期限切れ&ロック):パスワードの有効期限が切れ、さらにアカウントもロックされている二重ロック状態です(上記抜粋外の多くのシステムユーザーが該当します)。現在は使われていない、完全に眠っている内部機能用のスキーマです。

【マルチテナントの仕様:なぜPDBにSYSやSYSTEMがいるの?】
「全体の親玉(CDB)ではなく個室(PDB)を見ているのに、なぜ最高権限のSYSやSYSTEMが一覧に並んでいるの?」と疑問に思うかもしれません。
これはマルチテナントの仕様によるものです。新しく個室(PDB)が作成された瞬間、その個室単体を管理・独立稼働させるためのシステムユーザー一式が、各PDBの内部にも自動的に複製されて配置される仕組みになっています。つまり、ここに並んでいる `SYS` や `SYSTEM` は、全体の親玉ではなく「この個室専用に配属された管理ユーザー」なのです。PaaSの自律運用の邪魔をしないよう、安全に制御されています。

2. まとめ

実機のデータ・ディクショナリからユーザー構造を紐解くことで、PaaS環境であってもOracle Databaseとしての堅牢なシステム構成がそのまま引き継がれていることが確認できました。

★ 本日のチェックリスト:
1. 私たちが操作する「ADMIN」は個室(PDB)内のローカルユーザーとして、正常にOPENされている。
2. 内部のシステムユーザーは、セキュリティの定石通り基本「LOCKED」状態で保護されている。
3. PDB内に見えているSYSやSYSTEMは、個室が作成された際に自動複製された「個室専用の管理アカウント」。


ストレージ(論理・物理)に続き、ユーザーの初期状態まで確認できました。完全管理型(PaaS)データベースの内部検証シリーズはここで一区切りとなります。
次回第8回は、この「枠からはみ出せない」PaaSの安心安全な世界から飛び出し、「もう一つの無料枠(Compute VM)」を立ち上げて、Linuxのroot権限、そしてデータベース全体の親玉であるCDB$ROOTまですべてを自分の完全な支配下に置く『IaaS型・23ai Express Edition 自作構築編』へ突入します。コントロールを100%自分で握るインフラ構築の世界へ。どうぞお楽しみに!



【Oracle Cloud Free & DB】第5回:作成直後の「表領域」はどうなっている?PaaSのストレージ状態をSQLで確認する


前回、私たちがブラウザから触っているデータベースが、クラウド全体の巨大なコンテナ(CDB)の中に切り出された「316番目の個室(PDB)」であることを突き止めました。今回は、その個室の中に視点を移してみましょう。データベースが作成された直後の初期状態において、内部にはどのような「表領域(Tablespace)」が確保されているのでしょうか?システム管理者(ADMIN)の視点から、データ・ディクショナリ・ビューを叩いてその中身を暴いてみます。

1. 初期状態の表領域を一覧確認するSQL

Oracleにおいて、データベース全体の表領域の全容を掴むための大本命ビューといえば、やはり DBA_TABLESPACES です。Autonomous Database(PaaS)でも、ADMIN権限でログインしていればオンプレミスと同様にこの管理者用ビューにアクセスできます。さっそく、表領域名とそのステータス、物理的な特性を一覧で取得してみましょう。

★ 表領域を確認するSQL:
SELECT tablespace_name, block_size, status, contents, bigfile FROM dba_tablespaces;

【実行結果(クラウド実機での測定値)】
"TABLESPACE_NAME","BLOCK_SIZE","STATUS","CONTENTS","BIGFILE"
"SYSTEM",8192,"ONLINE","PERMANENT","YES"
"SYSAUX",8192,"ONLINE","PERMANENT","YES"
"UNDOTBS1",8192,"ONLINE","UNDO","YES"
"DATA",8192,"ONLINE","PERMANENT","YES"
"DBFS_DATA",8192,"ONLINE","PERMANENT","YES"
"TEMP",8192,"ONLINE","TEMPORARY","YES"
"SAMPLESCHEMA",8192,"READ ONLY","PERMANENT","YES"
"UNDO_8",8192,"ONLINE","UNDO","YES"

経過時間: 00:00:00.005
8行が選択されました。

2. 実行結果から読み解くクラウド(PaaS)の4つの特徴

この生々しい8行の結果には、オンプレミスのOracleを長年触ってきたインフラエンジニアほど「おや?」と膝を打つ、クラウド特へ特有の設計思想が隠されています。

① すべてが「BIGFILE」=「1表領域=1ファイル」の極太設計
注目すべきは、右端の BIGFILE のステータスが全て「YES」になっている点です。
従来のOracle(Smallfile)のように「容量が足りなくなったら、2号ファイル、3号ファイルを追加していく」という泥臭いファイル単位の運用はここにはありません。BIGFILE表領域は「1つの表領域=1つの超巨大なデータファイル(ブロックサイズ8KBなら最大32テラバイト!)」として管理する仕様です。最初からこの設定に統一することで、ファイル追加の手間を排除し、クラウド側で容量を全自動拡張(オートスケール)させるためのスマートなインフラ設計が行われている証拠です。

② アプリケーション用データはすべて「DATA」に一元集約
オンプレミスであれば、設計時にユーザーデータ用(USERS)、インデックス用(INDX)などと物理的な表領域を細かく分けるのが定石でした。しかし、ここには伝統の「USERS」ら存在せず、あるのは「DATA」表領域だけです。インフラ内部(Exadata基盤)が自動でストレージを最適化・ストライピングしてくれるため、人間がディスクの配置設計に頭を悩ませる必要がなくなっています。

③ クラウド(PaaS)特有の隠れキャラクターたち
基本5セット以外に見つかった3つの領域が、いかにもクラウド環境らしくて面白いポイントです。

  • DBFS_DATA:データベースをOSのファイルシステムのように見せる機能(Database File System)のための領域。クラウドの内部連携などで使われます。
  • SAMPLESCHEMA:Oracleお馴染みのサンプルデータ(SHスキーマなど)が最初から入っている領域。容量を食わないように親切にも「READ ONLY(読取専用)」に固定されています。
  • UNDO_8:デフォルトの「UNDOTBS1」とは別にある謎のUNDO(変更履歴)領域。Autonomous Databaseはバックグラウンドで複数のサービスやインスタンスが協調して動いているため、システムが自動で切り出した追加のUNDO領域と推測できます。

3. 各表領域の役割まとめ

今回あぶり出した全8つの表領域の役割を、管理者の視点で整理しておきます。

表領域名STATUS / CONTENTS役割とPaaSでの見所
SYSTEM ONLINE / PERMANENT データベースの心臓部。データ・ディクショナリ(メタ情報)が格納される領域。
SYSAUX ONLINE / PERMANENT SYSTEMの補助領域。AWR(パフォーマンス統計)などが自動格納される。
DATA ONLINE / PERMANENT ★ 本番データ領域。私たちが作るテーブルやインデックスはすべてここに集約される。
DBFS_DATA ONLINE / PERMANENT DBFS(Database File System)用。クラウドのシステム管理用領域。
SAMPLESCHEMA READ ONLY / PERMANENT 学習用のサンプルスキーマ用領域。書き換えられないよう読取専用状態。
TEMP ONLINE / TEMPORARY 一時領域。大規模なソートやハッシュ結合でメモリが足りない時に使われる。
UNDOTBS1 ONLINE / UNDO 読取り一貫性やロールバックのための主要な変更履歴(UNDO)領域。
UNDO_8 ONLINE / UNDO システムによって自動追加されたマルチインスタンス用の予備UNDO領域。

4. まとめ:運用フリーの思想が表領域にも現れている

サーバーパラメータの制限に続き、表領域の構成を見ても「データベース管理者の面倒な作業(データファイルの容量追加や、断片化を防ぐための配置設計)を1つでも減らす」というAutonomous(自律型)の強い思想が感じられる結果となりました。

★ 本日の表領域チェックリスト:
1. 管理者権限(ADMIN)から全体の表領域を俯瞰するには「DBA_TABLESPACES」を使う。
2. 面倒なファイル追加・監視を排除するため、全表領域が最大32TBまでいける「BIGFILE」構成。
3. ユーザーデータは細かく分けない。クラウドの最適化を信じて「DATA」表領域に一元集約するのがPaaSの作法。


ストレージの内部構造までバッチリ把握できました。これで現在の環境(26ai)の仕様理解は完璧です!次回第6回は、このクラウド完全管理型(PaaS)の環境と比較するために、「もう一つの無料枠(Compute VM)」を立ち上げて、あえて自分ですべてを管理する「IaaS型の19c Express Edition」の自作構築に挑戦します。PaaSとIaaSでどれだけ世界が変わるのか?インフラエンジニア必見の回となります。どうぞお楽しみに!