忍者ブログ
IT関係の小作人労働の日々の日記です。 最近データベースが好きです。 インフラ構築、DB構築、アプリケーション開発・・・何でも屋です。 何でもできそうで、何にもできない。

【データベース設計】データ整合性と監査を守る「5つの必須設計チェックリスト」

データベース(DB)設計の成否は、システムの堅牢性、パフォーマンス、そして運用の安定性に直結する。
今回は、テーブル定義などの論理設計から運用監視を見据えた物理設計に至るまで、開発フェーズの後半やリリース前の設計レビューで必ず担保すべき5つのクリティカルなチェックポイントを解説する。


1. データの整合性と制約の設計

アプリケーションのバグや不正なデータインジェクションから、データの正しさをデータベース層で最終防衛するための設計。

  • ① 各種制約(Not Null, Unique, Checkなど)は、正しく実装されているか
    単に主キー(Primary Key)を設定するだけでなく、業務ロジック上必須となるカラムへの NOT NULL 制約や、値の重複を許さない UNIQUE 制約が漏れなく定義されているか確認する。また、ステータス値や数値の範囲(例:年齢が0以上など)を縛る CHECK 制約を適切に配置することで、不正データの混入を未然に防ぐことができる。
  • ② Foreign key(外部キー)の設定は、適切か
    親テーブルと子テーブルの間の参照整合性を保つために、外部キー(FK)は原則として正しく設定すべきである。ただし、高頻度なトランザクションが発生するシステムでは、FKによるロック競合やパフォーマンスへの影響を考慮する必要がある。また、親レコード削除時の振る舞い(ON DELETE CASCADESET NULL など)が業務要件と一致しているかも重要なチェック対象となる。

2. データの品質・クレンジング設計

入力データのブレを吸収し、検索不具合や集計ミスを防止するための対策。

  • ③ 文字列前のスペースなど、不要な文字がある場合の処理は適切か
    ユーザー入力や外部システム連携によって、文字列の前後への「不要な全角・半角スペース」や「制御文字」の混入は頻繁に発生する。これらをそのまま格納すると、後続の WHERE 句による完全一致検索(=)がヒットしない原因になる。アプリケーション側でトリム(Trim)処理を行うか、あるいはDBのトリガー(Trigger)等を利用して自動でクレンジングする仕組みが設計されているかを確認する。

3. 監査と運用のためのログ設計

システムの透明性を担保し、障害発生時のデータ復旧や不正操作の追跡を可能にするための設計。

  • ④ 追加、更新(DML)などの処理のログが出力されているか
    いつ、誰が、どのデータを INSERT / UPDATE / DELETE したかを追跡できる設計になっているか。一般的には、すべての主要テーブルに「作成日時(created_at)」「作成者(created_by)」「更新日時(updated_at)」「更新者(updated_by)」のカラムを共通定義し、システムで自動更新する設計が標準とされる。
  • ⑤ 監査用の設定は適切か
    前述のアプリケーションレベルの更新履歴だけでなく、DBMS(Oracle、PostgreSQLなど)本体が持つ「監査ログ(Audit Log)機能」が適切に設計されているか。特に、管理者権限(スーパーユーザー)によるデータの直接操作や、データ定義の変更(ALTERDROP などの DDL)、重要情報の SELECT(閲覧)といった行為は、DB層での独立した監査ログとして安全な別領域に隔離・記録する設定が必要不可欠である。

4. まとめ:設計レビューでの活用

データベースは一度運用が始まると、後から制約を追加したり、ログ用の共通カラムを追加したりするリファクタリングが極めて困難になる。
論理設計のフェーズ、あるいはDDLを確定させる前の段階で、以下の簡易チェックシートをもとに設計の「抜け漏れ」がないかを網羅的に見直してほしい。

【データベース設計レビュー・チェック例】
□ 業務要件を満たす NOT NULL / UNIQUE / CHECK 制約が網羅されているか?
□ 外部キー(FK)のインデックス配置や削除時の挙動(CASCADE等)は最適か?
□ 表表記のブレ(前後のスペース等)を防ぐデータ制御方針は明確か?
□ 全テーブルに共通の監査用カラム(更新日時・更新者など)が組み込まれているか?
□ DBMSレベルでの監査ログ(特権ユーザーの操作監視など)の要件を定義したか?
PR

【YugabyteDB】インストール直後に必ず確認したい初期設定チェックリスト

YugabyteDB(OSS版)をインストールしたあと、まず最初にやっておくべき確認ポイントをまとめた。
この記事では、付属のインターフェースである ysqlsh を用いて、デフォルトのデータベース・ユーザ・拡張機能・テーブルスペースなどを確認する方法を紹介する。

YugabyteDB は PostgreSQL 互換を謳っているため、初期のDB構成やコマンド体系もほぼ PostgreSQL と同じである。しかし、分散データベース固有の挙動や制約もあるため、最初にこれらを押さえておくと構造理解が一気に進む。


1. ysqlsh にログインする

YugabyteDB の YSQL(PostgreSQL 互換レイヤー)に接続するには、ターミナルから以下のコマンドを実行する。

./bin/ysqlsh -h 10.x.x.x -U yugabyte -d yugabyte

2. デフォルトで作成されているデータベースを確認する

無事にログインできたら、まずはメタコマンド \l を実行して、最初から存在しているデータベースの一覧を確認する。

yugabyte=# \l

■ 実行結果(データベース一覧)

名前 | 所有者 | エンコーディング | 照合順序 | Ctype(変換演算子) | ロールプロバイダー | アクセス権限 -----------------+----------+------------------+----------+-------------------+--------------------+----------------------- postgres | postgres | UTF8 | C | en_US.UTF-8 | libc | system_platform | postgres | UTF8 | C | en_US.UTF-8 | libc | template0 | postgres | UTF8 | C | en_US.UTF-8 | libc | =c/postgres + | | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | C | en_US.UTF-8 | libc | =c/postgres + | | | | | | postgres=CTc/postgres yugabyte | postgres | UTF8 | C | en_US.UTF-8 | libc | (5 行)

✔ インストール直後に存在する主なDB:

  • yugabyte:メインとなるデータベース。実際のアプリケーション開発ではこのDBを使うのが基本となる。
  • postgres:PostgreSQL互換を維持するための管理用データベース。
  • template0 / template1:新しくデータベースを作成する際の雛形となるテンプレートDB。

※YugabyteDBはPostgreSQL互換レイヤーを持っているため、初期のシステムデータベースの構成もほぼPostgreSQLの標準状態を踏襲している。


3. デフォルトユーザを確認する

次に、データベースに定義されている初期ロール(ユーザ)を \du コマンドで確認する。

yugabyte=# \du

■ 実行結果(ロール一覧)

ロール一覧 ロール名 | 属性 | 所属グループ --------------+--------------------------------------------------------------------------------------------------------------+-------------- postgres | スーパーユーザー, ロール作成可, DB作成可, レプリケーション可, RLS のバイパス | {} yb_db_admin | 継承なし, ログインできません | {} yb_extension | ログインできません | {} yb_fdw | ログインできません | {} yugabyte | スーパーユーザー, ロール作成可, DB作成可, レプリケーション可, RLS のバイパス | {}

✔ 主な初期ユーザ:

  • yugabyte:初期接続で利用した最高権限を持つスーパーユーザ。
  • postgres:PostgreSQL互換の文脈から存在する管理ユーザ。

※セキュリティを確保するため、初期管理者ユーザー(yugabyte)をそのままアプリケーションの接続に常用するのは避け、必要に応じて最小権限を割り当てたアプリ専用のユーザーを別途作成するのがベストプラクティスだ。


4. 拡張(extensions)の確認

YugabyteDB は PostgreSQL 互換ではあるものの、すべてのシステム拡張機能がそのまま利用できるわけではない。利用可能な拡張機能をシステムカタログから確認する。

SELECT name, default_version, comment FROM pg_available_extensions;

■ 出力される主な注目機能

plpgsql | 1.0 | PL/pgSQL procedural language citext | 1.6 | data type for case-insensitive character strings earthdistance | 1.1 | calculate great-circle distances on the surface of the Earth (・・・以下略・・・)

✔ 事前に確認しておきたい主要な拡張:

  • pg_stat_statements:SQLの実行統計を採取する、パフォーマンスチューニングの必須機能。
  • uuid-ossp:分散環境で主キーとして多用されるUUIDを生成する関数群。
  • pgcrypto:データの暗号化・ハッシュ化をサポート。
  • yb_fdw:YugabyteDB専用の外部データラッパ(Foreign Data Wrapper)。

※100%すべてのPostgreSQLプラグインがそのまま動くわけではないため、利用予定の拡張機能が初期状態でサポートされているかは、開発の最初に必ずチェックしておこう。


5. テーブルスペースの確認

データベース内の物理配置を司るテーブルスペースを確認する。

SELECT oid, spcname FROM pg_tablespace;

■ 実行結果

oid | spcname
------+------------
1663 | pg_default
1664 | pg_global

✔ 各領域の仕組み:

  • pg_default:ユーザーが作成する通常のテーブルやインデックスが格納される標準領域。通常のPostgreSQLではOS上の特定のディレクトリに紐づくが、YugabyteDBでは分散ストレージである「DocDB」内部の論理的な領域として扱われる。
  • pg_global:ユーザー情報やシステムカタログなど、クラスター全体で共有・同期されるメタデータ専用の領域。

6. ノード構成(クラスタ情報)の確認

YugabyteDBの本領である分散構成(クラスタ)が正常に機能しているかを、専用の管理ツール yb-admin を使って外側から確認する。

① Master(マスター)ノードの確認

./bin/yb-admin --master_addresses 10.x.x.x:7100 list_all_masters
Master UUID RPC Host/Port State Role Broadcast Host/Port c3f22f44f3864710a8801fa2b41d082f 10.x.x.x:7100 ALIVE LEADER 10.x.x.x:7100
  • State = ALIVE:Masterが稼働中であることを示す。
  • Role = LEADER:このMasterがクラスタのメタデータを統括するリーダーであることを示す(単一ノード構成時は1台が自動的にLEADERになる)。

② Tablet Server(データノード)の確認

./bin/yb-admin --master_addresses 10.x.x.x:7100 list_all_tablet_servers
Tablet Server UUID RPC Host/Port Heartbeat delay Status Reads/s Writes/s Uptime SST total size SST uncomp size SST #files Memory Broadcast Host/Port 4e9cc709d23649ac8d67065da18e1211 10.x.x.x:9100 0.81s ALIVE 0.00 0.20 1028 0 B 0 B 0 54.11 MB 10.x.x.x:9100
  • Status = ALIVE:実際のデータ読み書きを受け持つデーモンが正常稼働している状態。
  • Heartbeat delay:Masterとの疎通確認(心拍)の間隔。1秒未満など、極めて短く維持されていることが正常の証拠である。

7. ysqlsh 内での基本メタコマンドまとめ(おまけ)

YugabyteDBを操作する上で、最低限これだけは最初に暗記しておきたいメタコマンドの一覧を以下に記す。

\l      -- データベース一覧を表示
\c db名  -- 指定したデータベースへ接続を切り替え
\dt     -- 現在のDB内のテーブル一覧を表示
\d 表名  -- 指定したテーブルのスキーマ(定義)を表示
\du     -- ロール(ユーザー)および付与された権限の一覧を表示
\df     -- 定義されている関数(ファンクション)の一覧を表示

まとめ

インストール直後に確認すべきは、以下の5点である。

  1. デフォルトDB(\l
  2. デフォルトユーザ(\du
  3. 利用可能な拡張(pg_available_extensions
  4. テーブルスペースの実体(pg_tablespace
  5. クラスタ内のノード構成(yb-admin

これらをはじめに把握しておくことで、単なるリレーショナルDBとしてではなく、「PostgreSQLのガワを被った堅牢な分散データベース」としての素性をスムーズに掴むことができる。初期設定や運用の第一歩として活用してほしい。


【データベースの知識】データベースの安全性を高めるための「14の必須チェックポイント」

システム構築において、企業の重要な資産であるデータを守るデータベース(DB)のセキュリティ対策は最優先課題である。
今回は、インフラ設計から日々の運用メンテナンスに至るまで、データベースのセキュリティを確保するために確実に実施すべき14の基本対策を体系的に整理した。


1. 通信とアクセス経路の制御(ネットワーク層)

外部からの侵入経路を断ち、盗聴を防ぐための基本設計。

  • ① 通信を暗号化する
    クライアントやアプリケーションサーバー(APサーバー)との間の通信ルートをSSL/TLS等で暗号化し、ネットワーク上での盗聴や改ざんを防ぐ。
  • ② データベースに接続できる端末を必要最小限とする
    ファイアウォールやセキュリティグループを活用し、信頼されたAPサーバーや特定の管理端末(踏み台サーバーなど)からのみ接続を許可する。
  • ③ 通信ポートをデフォルトから変更する
    標準ポート(Oracleの1521、PostgreSQLの5432など)のまま運用すると自動スキャンの標的になりやすいため、ポート番号を変更して攻撃の難易度を上げる。

2. アカウントと権限の管理(アイデンティティ層)

システム内部における不正操作や、乗っ取りリスクを最小化する対策。

  • ④ デフォルトのパスワードを変更する
    DBMSのインストール時に自動作成されるシステム管理者やサンプル用アカウントの初期パスワードは、必ず強固な文字列に変更する。
  • ⑤ データベースのアカウントを適切に設定する
    共有アカウントの利用を禁止し、開発者や運用者ごとに個別の識別子(ID)を割り当てて責任の所在を明確にする。
  • ⑥ 不要なアカウント、長期的に利用されていないアカウントを削除する
    テスト用アカウントや退職者の古いアカウントなど、利用されていない休眠アカウントはバックドアに悪用される前に完全に削除する。
  • ⑦ デフォルトのロールから不要な権限を削除する
    一般ユーザーに付与される標準ロール(PUBLICなど)に、過剰なシステム権限や他スキーマへの参照権限が残っていないか見直す。
  • ⑧ データベースのオブジェクトに対して、適切なアクセス制御を行う
    最小権限の原則に従い、テーブル、ビュー、ストアドプロシージャなどの各オブジェクトに対する割当権限(SELECT、INSERTなど)を必要最小限に制限する。

3. プラットフォームと製品の保守(システム層)

ソフトウェア自体の弱点を無くし、堅牢な土台を維持する対策。

  • ⑨ 脆弱性の少ないDBMSを利用する
    採用するデータベース管理システム(DBMS)自体のセキュリティ実績やベンダーのサポート体制を評価し、信頼性の高い製品・バージョンを選定する。
  • ⑩ DBMSに対して、セキュリティパッチを適用する
    既知の脆弱性を放置することは致命的なリスクとなる。ベンダーからリリースされる最新の修正パッチ(CPUやRUなど)を定期的に適用する。
  • ⑪ 不要な機能、モジュール、サービスなどは、削除や停止を行う
    利用していないオプション機能、拡張コンポーネント、組み込み関数などは、攻撃の足がかり(アタックサーフェス)を減らすために削除または停止する。

4. 監査とインシデント検知(監視層)

「万が一」の事態に備え、兆候を察知し、後から追跡できるようにするための仕組み。

  • ⑫ データベースへアクセスするAPサーバなどのログをとる
    経由地となるアプリケーション側のアクセスログや認証ログを収集し、誰がいつシステムを利用したかを突き止められるようにする。
  • ⑬ データベースの操作ログをとる
    DB内部でのデータ定義(DDL)や重要データの参照・更新(DML)、管理者権限の行使などの監査ログ(Audit Log)を確実に記録・保管する。
  • ⑭ データベースへの不正アクセスを検知する
    短時間での大量のログイン失敗、不審な時間帯のアクセス、通常とは異なる大量のデータエクスポートなどの異常な挙動をリアルタイムで検知・通知する仕組みを導入する。

5. まとめ:チェックリストの活用

これらの14項目は、どれか一つが欠けてもそこがセキュリティの「穴」になり得る。新しくデータベース環境を設計・構築する際はもちろんのこと、定期的なシステム運用の監査タイミングにおいて、以下の観点で設定状況を見直すガイドラインとして活用してほしい。

【定期監査時のセルフチェック例】
□ ネットワークレベルで不要な通信が遮断されているか?
□ パッチ適用状況は最新ロードマップに追従できているか?
□ ユーザー権限は「最小限の原則」が本当に維持されているか?
□ 有事の際に追跡可能なログが欠けなく採取できているか?

GCP + Ubuntu 24.04 YugabyteDB 3ノード構築完全ガイド 〜 yugabyte-node1, 2, 3 を使った複製構築戦略 〜

本ガイドでは、まずベースとなる yugabyte-node1 を「ひな形(マスター)」として完璧にセットアップする。
その後、その状態を丸ごと保存した「マシンイメージ」を作成し、それを使って yugabyte-node2yugabyte-node3 を一瞬で複製する。

この「ゴールデンイメージ戦略」により、各ノードで同じコマンドを何度も叩く不毛な手作業を省き、設定ミスをゼロに抑えて最短で分散データベースのクラスターを立ち上げることが可能だ。


1. 【1台目】ひな形となる yugabyte-node1 の作成

まずは Google Cloud コンソールで、すべてのベースとなる1台目のVMインスタンスを作成する。

「Compute Engine > VM インスタンス」を開き、「インスタンスを作成」をクリックして以下のように設定を行う。

  • 名前: yugabyte-node1
  • マシンタイプ: e2-medium (2 vCPU, 4GB RAM)
  • OS/イメージ: Ubuntu 24.04 LTS
  • ブートディスク: 50GB (バランス永続ディスク)
  • ネットワークタグ: yugabyte-node

※「詳細オプション」>「ネットワーキング」のタグ欄に入力するこのネットワークタグは、後ほど3台まとめて通信許可(ファイアウォール)を設定する際に重要となる。


2. 【1台目】共通環境のセットアップ(SSH接続)

作成した yugabyte-node1 にSSHでログインし、以下のコマンド群を実行してYugabyteDBが正常に動作する環境を完成させる。

① システムの事前準備

分散DBの大量アクセスに耐えられるよう、OSのリソース制限およびカーネルパラメータを拡張し、必須パッケージを導入する。

# リソース制限の拡張
sudo bash -c 'cat << EOF > /etc/security/limits.d/yugabyte.conf
* soft nproc 65535
* hard nproc 65535
* soft nofile 1048576
* hard nofile 1048576
EOF'

# カーネルパラメータの調整
sudo sysctl -w vm.max_map_count=262144
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf

# 依存パッケージのインストール
sudo apt update && sudo apt install -y wget bzip2 tar libatomic1 python3-pip

② Python (Miniconda) のインストール

YugabyteDBの内部スクリプトが依存するPython環境を、Minicondaを用いてホームディレクトリ配下に整備する。

# Minicondaの導入
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
bash Miniconda3-latest-Linux-x86_64.sh -b -p $HOME/miniconda3
eval "$($HOME/miniconda3/bin/conda shell.bash hook)"
conda init bash
source ~/.bashrc

③ YugabyteDB のインストール

公式から最新のバイナリ(バージョン: 2025.2.2.2-b11)を取得し、展開と初期設定を行う。

# ダウンロードと解凍
wget https://software.yugabyte.com/releases/2025.2.2.2/yugabyte-2025.2.2.2-b11-linux-x86_64.tar.gz
tar xvfz yugabyte-2025.2.2.2-b11-linux-x86_64.tar.gz
cd yugabyte-2025.2.2.2/

# Conda環境のPythonを使ってパスの初期設定を実行
./bin/post_install.sh

3. 【複製】マシンイメージから node2, node3 を作成

ここが「ゴールデンイメージ戦略」の本番である。苦労してセットアップした yugabyte-node1 をクローンし、残り2台を数クリックで複製する。

  1. VMを停止: 正確なスナップショットを取るため、GCPコンソールで yugabyte-node1 を一度停止させる。
  2. マシンイメージ作成: 左メニュー「Compute Engine > マシンイメージ」へ進み、yugabyte-node1 をソースとして yugabyte-base-image を作成する。
  3. インスタンス複製: 作成した yugabyte-base-image の詳細画面から「インスタンスを作成」を選び、名前を yugabyte-node2、同様の手順でもう1台を yugabyte-node3 として作成する。(設定やネットワークタグ、ディスク状態が丸ごと引き継がれる)
  4. 全台起動: 複製が完了したら、最初に停止した yugabyte-node1 も含め、3台すべてを起動状態にする。

4. ネットワーク設定(ファイアウォール)

GCPコンソール上で、3台のノードが互いの間で全ポート通信を行えるようにルールを追加する。この設定は既存の外部からのSSH接続等には影響を与えない。

  • 名前: yugabyte-cluster-common
  • ターゲットタグ: yugabyte-node
  • ソース IPv4 範囲: 10.0.0.0/8 (または環境に合わせたVPCの内部IPレンジ)
  • プロトコルとポート: すべて許可 を選択

5. クラスターの起動(3台それぞれで実行)

3台それぞれに個別にSSHでログインし、クラスターを起動・結合していく。

全ノード共通の準備

まずは全台共通で、インストールディレクトリへ移動しておく。

cd yugabyte-2025.2.2.2/

node1 (マスター) で実行

最初にクラスターの起点となる1台目を起動する。

./bin/yugabyted start \
--base_dir=$HOME/var/yugabyte \
--listen $(hostname -I | awk '{print $1}') \
--master_flags="memory_limit_hard_bytes=1073741824" \
--tserver_flags="memory_limit_hard_bytes=1610612736"

node2 と node3 で実行

残り2台を、node1で作成されたクラスターにジョイン(参加)させる。
<yugabyte-node1の内部IP> の部分は、GCPコンソールで確認できる node1 の内部IP(10.x.x.x)に書き換えること。

./bin/yugabyted start \
--base_dir=$HOME/var/yugabyte \
--listen $(hostname -I | awk '{print $1}') \
--join <yugabyte-node1の内部IP> \
--master_flags="memory_limit_hard_bytes=1073741824" \
--tserver_flags="memory_limit_hard_bytes=1610612736"

6. 稼働確認(どのサーバーからでもOK)

YugabyteDBは完全な分散型アーキテクチャであるため、node13 のどのサーバーからSQLシェルを起動しても、クラスター全体の同じグローバル情報を取得できる。

# 自身のノードのIPを指定してSQLシェルを起動
./bin/ysqlsh -h $(hostname -I | awk '{print $1}') -U yugabyte -d yugabyte

無事にSQLシェルに繋がったら、以下のメタデータ参照コマンドを叩く。

yugabyte=# SELECT * FROM yb_servers();

実行結果に 3台分のノードのIPアドレス、ポート番号、および正常に連動しているステータスがズラリと表示されれば、GCP上での3ノード・マルチマスター環境の構築は完全完了だ。


【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でどれだけ世界が変わるのか?インフラエンジニア必見の回となります。どうぞお楽しみに!