---

【Oracle】表領域使用率の確認・監視・対処法 – 詳細ガイド

はじめに

Oracleデータベースにおいて、表領域はデータを格納するための論理的な領域であり、その健全性はデータベース運用の根幹をなします。表領域の空き容量が枯渇することは、新たなデータの書き込みができなくなるだけでなく、既存データの更新や一時領域の使用、さらにはUNDO情報の保持にも影響を与え、最終的にはデータベースの停止やトランザクションの失敗といった致命的な問題を引き起こす可能性があります。

そのため、表領域の使用率を常に把握し、適切なレベルで監視し、必要に応じて迅速かつ効果的な対処を行うことは、データベース管理者（DBA）にとって非常に重要な業務です。

本記事では、Oracleデータベースの表領域使用率について、その基本的な概念から、手動による確認方法、自動化された監視、そして発生しうる問題への具体的な対処法までを網羅的に解説します。経験豊富なDBAの方から、これからOracleデータベースの運用管理を始める方まで、幅広く役立つ情報を提供することを目指します。

1. Oracleの表領域の基本

1.1 表領域とは

Oracleデータベースは、物理的なデータファイル（.dbfファイルなど）と論理的な構造体である表領域という二層構造でデータを管理しています。表領域は一つ以上のデータファイルで構成され、データファイルはオペレーティングシステム上のファイルに対応します。

データは、表領域内に作成される「セグメント」に格納されます。セグメントは、表（TABLE）、索引（INDEX）、LOB、UNDO、一時セグメント（TEMPORARY）といった論理的なデータベースオブジェクトの実体です。セグメントは、さらに「エクステント」と呼ばれる単位で領域を割り当てられます。エクステントは連続したデータブロックの集まりであり、これがディスク上のデータファイル内の領域に対応します。

要するに、表領域はデータファイルの集合体であり、その中にセグメント（テーブルや索引など）がエクステント単位で領域を確保しながらデータが格納されていく構造です。

1.2 主要な表領域とその役割

Oracleデータベースには、インストール時に自動的に作成されるデフォルトの表領域や、運用で作成される様々な表領域があります。代表的なものを以下に示します。

• SYSTEM: データベースのコアとなる情報（データディクショナリ、システムセグメントなど）が格納される最も重要な表領域です。この表領域が満杯になると、データベースは正常に動作できなくなります。原則として、ユーザーオブジェクトは作成しません。
• SYSAUX: SYSTEM表領域の負荷を軽減するために導入された補助的なシステム表領域です。AWR (Automatic Workload Repository)、Optimizer統計、Statspack、ASMメタデータ、Streams、Spatialなどの様々なリポジトリ情報が格納されます。SYSAUXが満杯になると、データベースのパフォーマンス問題や特定機能の利用制限が発生します。
• UNDO: 進行中のトランザクションによって変更されたデータの元の値を保持するための表領域です。コミットされていない変更をロールバックするためや、読み取り一貫性を提供するために使用されます。UNDO表領域が不足すると、トランザクションが失敗したり、ORA-01555 (Snapshot too old) エラーが発生したりします。
• TEMP: SQL文の処理中にソートやハッシュ結合などの一時的な作業領域として使用される表領域です。ユーザーセッションごとに一時セグメントが作成され、セッション終了時に解放されます。TEMP表領域が不足すると、大規模なSQL処理が失敗したり、パフォーマンスが著しく低下したりします。
• USERS: ユーザーが作成する一般的なオブジェクト（テーブル、索引など）を格納するための表領域です。特別な指定がない場合、ユーザー作成オブジェクトのデフォルトの表領域となります。
• EXAMPLE: サンプルスキーマ（HR, OEなど）で使用される表領域です。通常、本番環境では作成しません。

これらの他にも、アプリケーション固有のデータや索引を格納するために作成される業務表領域（例: APP_DATA, APP_IDXなど）があります。

1.3 領域管理方法

Oracleの表領域には、領域管理方法として以下の2種類があります。

• ディクショナリ管理表領域 (Dictionary-Managed Tablespace – DMT): 領域の管理（エクステントの割り当てや解放）をデータディクショナリ表（SYSTEM表領域内の表）で行います。領域管理が集中するため、競合が発生しやすく、SYSTEM表領域の断片化を招く可能性がありました。Oracle Database 8i以降、非推奨となり、現在では特別な理由がない限り使用すべきではありません。
• ローカル管理表領域 (Locally-Managed Tablespace – LMT): 領域の管理を各表領域自身のデータファイル内のビットマップ（Bitmap Block）で行います。領域管理情報が分散されるため、競合が少なく、パフォーマンスが向上し、断片化を抑えることができます。現在のOracleデータベースでは、SYSTEM表領域を含め、原則としてローカル管理表領域が使用されます。特にユーザー表領域は必ずLMTで作成すべきです。

ローカル管理表領域には、さらにセグメント領域管理の方法として以下の2種類があります。

• マニュアル・セグメント領域管理 (Manual Segment Space Management – MSSM): 各ブロックの空き容量管理を、セグメント内のフリーリストによって行います。古い方式であり、領域管理の効率が悪く、断片化しやすいという欠点があります。
• 自動セグメント領域管理 (Automatic Segment Space Management – ASSM): 各ブロックの空き容量管理を、データファイル内のビットマップによって自動的に行います。Oracleが最適なブロックを選択してデータを書き込むため、領域管理の効率が良く、断片化しにくく、複数セッションからの同時挿入時の競合も低減されます。新しいユーザー表領域を作成する際は、必ずASSMを指定すべきです (CREATE TABLESPACE ... SEGMENT SPACE MANAGEMENT AUTO;)。

1.4 自動拡張機能 (AUTOEXTEND)

データファイルのAUTOEXTEND属性は、表領域が満杯になりそうになったときに、データファイルのサイズを自動的に拡張する機能です。これにより、手動でデータファイルを追加したりサイズを拡張したりする手間を省き、領域不足によるデータベース停止リスクを軽減できます。

AUTOEXTEND ONを設定する場合、以下のパラメータを指定します。

• NEXT: 一度に拡張されるサイズ
• MAXSIZE: データファイルの最大サイズ (UNLIMITEDを指定することも可能ですが、ディスク容量を考慮して制限を設けるのが一般的です)

AUTOEXTENDは便利な機能ですが、無計画に使用すると予期せずディスク容量を消費してしまう可能性があるため、適切なMAXSIZEの設定と、拡張が発生したことを検知するための監視が重要です。

2. 表領域使用率の確認方法 (手動)

表領域の使用状況を手動で確認するには、主にOracleのデータディクショナリビューや動的パフォーマンスビュー（V$ビュー）を使用します。これらのビューには、データベースの構造、オブジェクト、使用状況に関するメタデータが格納されています。

2.1 使用する主要なデータディクショナリビュー

表領域使用率の確認に頻繁に使用されるビューは以下の通りです。

• DBA_DATA_FILES: データベース内のすべてのデータファイルに関する情報（ファイル名、表領域名、ファイルサイズ、空き容量、AUTOEXTEND設定、最大サイズなど）が含まれます。
• DBA_FREE_SPACE: 各表領域内の連続した空き領域に関する情報が含まれます。
• DBA_TABLESPACES: データベース内のすべての表領域に関する情報（表領域名、ステータス、領域管理方法など）が含まれます。
• DBA_SEGMENTS: データベース内のすべてのセグメント（テーブル、索引、LOBなど）が使用している領域に関する情報（セグメント名、セグメントタイプ、表領域名、使用バイト数、エクステント数など）が含まれます。

2.2 SQL*Plusでの確認クエリ例

a. 各表領域の合計サイズ、使用サイズ、空きサイズ、使用率、AUTOEXTEND設定

DBA_DATA_FILESとDBA_FREE_SPACEを組み合わせて、各表領域の現在の使用状況を一覧表示するクエリは最も基本的でよく使用されます。

sql
-- 各表領域の使用率を確認するクエリ
SELECT
t.tablespace_name,
-- 合計サイズ (MB)
ROUND(SUM(d.bytes) / 1024 / 1024) AS total_size_mb,
-- 空きサイズ (MB)
ROUND(SUM(DECODE(f.bytes, NULL, 0, f.bytes)) / 1024 / 1024) AS free_size_mb,
-- 使用サイズ (MB)
ROUND((SUM(d.bytes) - SUM(DECODE(f.bytes, NULL, 0, f.bytes))) / 1024 / 1024) AS used_size_mb,
-- 使用率 (%)
ROUND((SUM(d.bytes) - SUM(DECODE(f.bytes, NULL, 0, f.bytes))) * 100 / SUM(d.bytes)) AS used_pct,
-- AUTOEXTEND設定 (ON/OFF)
DECODE(BITAND(t.CONTENTS, 3 + 4), 0, 'PERMANENT', 1, 'TEMPORARY') AS tablespace_type, -- テーブル領域タイプ (永続/一時)
t.extent_management, -- 領域管理方法 (LOCAL/DICTIONARY)
t.segment_space_management -- セグメント領域管理方法 (AUTO/MANUAL)
FROM
dba_tablespaces t
JOIN
dba_data_files d ON t.tablespace_name = d.tablespace_name
LEFT JOIN
dba_free_space f ON t.tablespace_name = f.tablespace_name AND d.file_id = f.file_id -- データファイルごとの空き容量を使用 (厳密な計算のため)
GROUP BY
t.tablespace_name,
t.CONTENTS,
t.extent_management,
t.segment_space_management
ORDER BY
used_pct DESC;
解説:
* このクエリは、dba_tablespaces, dba_data_files, dba_free_space のビューを結合して使用します。
* dba_data_files から各表領域の合計データファイルサイズを取得します。
* dba_free_space から各表領域の合計空き容量を取得します。DECODE(f.bytes, NULL, 0, f.bytes) は、dba_free_space に該当行がない場合（空きがない場合）に0として扱います。
* 合計サイズから空きサイズを引くことで使用サイズを計算します。
* 使用サイズを合計サイズで割って100をかけることで使用率 (%) を計算します。
* GROUP BY 句で表領域ごとに集計します。
* ORDER BY used_pct DESC で使用率が高い順に表示し、問題のある表領域を把握しやすくします。
* 表領域のタイプ (永続/一時)、領域管理方法 (ローカル/ディクショナリ)、セグメント領域管理方法 (AUTO/MANUAL) も表示します。

b. AUTOEXTENDが有効なデータファイルの確認

DBA_DATA_FILESビューから、AUTOEXTENSIBLE列が’YES’になっているデータファイルとその設定（拡張サイズ、最大サイズ）を確認できます。

sql
-- AUTOEXTENDが有効なデータファイルを確認するクエリ
SELECT
file_name,
tablespace_name,
ROUND(bytes / 1024 / 1024) AS current_size_mb,
autoextensible,
ROUND(maxbytes / 1024 / 1024) AS max_size_mb,
ROUND(increment_by * (SELECT value FROM v$parameter WHERE name = 'db_block_size') / 1024 / 1024) AS next_extend_size_mb
FROM
dba_data_files
WHERE
autoextensible = 'YES'
ORDER BY
tablespace_name, file_name;
解説:
* autoextensible = 'YES' で自動拡張が有効なファイルに絞り込みます。
* maxbytes はデータファイルの最大サイズを示します。UNLIMITED の場合は非常に大きな値が表示されることがあります。
* increment_by は拡張時に追加されるブロック数です。v$parameter からブロックサイズを取得してバイト単位に変換し、さらにMB単位に変換しています。

c. 各セグメントの使用容量トップN

特定の表領域の使用率が高い場合、どのセグメント（テーブルや索引など）が領域を多く消費しているかを特定することが重要です。DBA_SEGMENTSビューを使用します。

sql
-- 各セグメントの使用容量トップ20を確認するクエリ
SELECT
owner,
segment_name,
segment_type,
tablespace_name,
ROUND(bytes / 1024 / 1024) AS used_size_mb
FROM
dba_segments
ORDER BY
bytes DESC
FETCH FIRST 20 ROWS ONLY; -- Oracle 12c以降で使用可能。旧バージョンでは ROWNUM を使用
解説:
* owner, segment_name, segment_type, tablespace_name でどのスキーマのどのオブジェクトがどの表領域に存在するかを示します。
* bytes 列がそのセグメントが現在使用している領域（バイト単位）です。
* ORDER BY bytes DESC で使用容量が多い順に並べ、FETCH FIRST 20 ROWS ONLY (または WHERE ROWNUM <= 20) で上位20件を取得します。

d. 特定の表領域内のセグメントの使用容量トップN

特定の表領域（例: ‘USERS’）の使用状況を詳しく調べたい場合に便利です。

sql
-- 特定の表領域 (例: 'USERS') 内のセグメントの使用容量トップ10を確認するクエリ
SELECT
owner,
segment_name,
segment_type,
ROUND(bytes / 1024 / 1024) AS used_size_mb
FROM
dba_segments
WHERE
tablespace_name = 'USERS' -- 確認したい表領域名に変更
ORDER BY
bytes DESC
FETCH FIRST 10 ROWS ONLY; -- Oracle 12c以降
-- WHERE ROWNUM <= 10; -- 11g以前の場合
解説:
* WHERE tablespace_name = '...' で対象の表領域に絞り込みます。

e. RECYCLEBINの確認

削除されたオブジェクト（テーブルなど）は、PURGEされない限りRECYCLEBINに一時的に格納され、ディスク領域を消費します。RECYCLEBINのサイズを確認することも重要です。

sql
-- RECYCLEBINの内容とサイズを確認するクエリ
SELECT
owner,
object_name,
original_name, -- 元のオブジェクト名
type,
ts_name, -- 表領域名
ROUND(space * (SELECT value FROM v$parameter WHERE name = 'db_block_size') / 1024 / 1024) AS space_used_mb,
droptime
FROM
dba_recyclebin
ORDER BY
space DESC;
解説:
* dba_recyclebin ビューには、RECYCLEBIN内のオブジェクト情報が格納されています。
* space 列は使用ブロック数です。db_block_size を掛けてバイト単位にし、MBに変換しています。
* droptime はオブジェクトが削除された日時です。

2.3 PDB環境での確認 (Oracle 12c以降のCDB/PDB)

Oracle Database 12c以降のコンテナデータベース (CDB) およびプラガブルデータベース (PDB) 環境では、CDB全体の情報はCDB_プレフィックスのビュー（例: CDB_DATA_FILES, CDB_FREE_SPACE）で確認できます。PDB内の特定の表領域使用率を確認するには、そのPDBに接続してDBA_プレフィックスのビューを使用するか、CDBに接続した状態でCDB_ビューにCON_ID (Container ID) やCON_NAME (Container Name) 列を追加して確認します。

sql
-- CDB環境で各PDBの表領域使用率を確認するクエリ (CDB$ROOTから実行)
SELECT
c.con_name, -- PDB名
t.tablespace_name,
ROUND(SUM(d.bytes) / 1024 / 1024) AS total_size_mb,
ROUND(SUM(DECODE(f.bytes, NULL, 0, f.bytes)) / 1024 / 1024) AS free_size_mb,
ROUND((SUM(d.bytes) - SUM(DECODE(f.bytes, NULL, 0, f.bytes))) / 1024 / 1024) AS used_size_mb,
ROUND((SUM(d.bytes) - SUM(DECODE(f.bytes, NULL, 0, f.bytes))) * 100 / SUM(d.bytes)) AS used_pct
FROM
cdb_tablespaces t
JOIN
cdb_data_files d ON t.tablespace_name = d.tablespace_name AND t.con_id = d.con_id
LEFT JOIN
cdb_free_space f ON t.tablespace_name = f.tablespace_name AND d.file_id = f.file_id AND t.con_id = f.con_id
JOIN
v$containers c ON t.con_id = c.con_id
WHERE c.con_id > 2 -- PDBのみを対象 (1:CDB$ROOT, 2:PDB$SEED)
GROUP BY
c.con_name, t.tablespace_name
ORDER BY
c.con_name, used_pct DESC;

2.4 手動確認の限界

手動での確認は、その時点の状況を把握するのには有効ですが、リアルタイム性や継続的な監視には向きません。定期的に手動で実行することも可能ですが、人的コストがかかり、問題の発生を迅速に検知するには不十分です。そのため、次に説明する自動化された監視が不可欠となります。

3. 表領域使用率の監視方法 (自動化)

表領域の使用率監視を自動化することで、領域不足の兆候を早期に発見し、問題が顕在化する前に proactive な対処を行うことが可能になります。また、使用率のトレンドを把握することで、将来的な容量計画にも役立てることができます。

3.1 なぜ監視が必要か

• 早期発見: しきい値（例: 80%使用）を設定し、それを超えた場合にアラートを通知することで、領域不足が発生する前に問題を検知できます。
• 稼働停止防止: 領域枯渇によるデータベースの稼働停止という最悪のシナリオを回避できます。
• パフォーマンス維持: 一時領域やUNDO領域の不足はパフォーマンス劣化に直結するため、これらの監視は重要です。
• 容量計画: 過去の使用率データを蓄積・分析することで、将来必要なディスク容量を見積もり、拡張計画を立てる際の根拠となります。
• 原因特定: どの表領域の使用率が急増しているかを監視することで、問題の原因となっているアプリケーションや処理を特定しやすくなります。

3.2 Oracle標準の監視ツール

a. Oracle Enterprise Manager (OEM) / Cloud Control (ECC)

Oracle Enterprise Manager (OEM) は、Oracleデータベースを含むOracle製品群を統合的に管理・監視するための powerful なツールです。グラフィカルインターフェース (GUI) を通じて、表領域の使用状況を視覚的に確認したり、詳細なレポートを生成したり、しきい値に基づいたアラートを設定したりできます。

• GUIでの確認: ターゲットデータベースのホームページから、ストレージ関連のメトリック（Tablespace Space Used (%) など）を確認できます。表領域ごとの使用率や空き容量、データファイルごとのサイズなどをグラフや表形式で表示できます。
• メトリックとアラート:
  • Tablespace Space Used (%): 表領域の使用率を監視する最も基本的なメトリックです。通常、警告 (Warning) およびクリティカル (Critical) のしきい値を設定します（例: Warning 80%, Critical 90%）。
  • Tablespace Free Space (MB): 表領域の空き容量をMB単位で監視するメトリックです。絶対的な空き容量で判断したい場合に便利です。
  • Datafile Space Used (%): データファイルごとの使用率を監視できます。特定のファイルがボトルネックになっていないか確認できます。
  • Datafile Max Extension Size Remaining (MB): AUTOEXTENDが有効なデータファイルについて、最大サイズまであとどれくらい拡張可能かを監視します。これがゼロに近づくと、たとえ使用率が低くても、それ以上拡張できない限界が近いことを示します。
• アラート通知: しきい値を超えた場合、メール、SNMPトラップ、オペレーティングシステムコマンド実行など、様々な方法でDBAに通知できます。
• レポート機能: 定期的に表領域使用率のレポートを生成し、トレンド分析や容量計画に利用できます。
• 自動アクション: 一部の設定やバージョンでは、特定のイベント（例: 表領域使用率がクリティカルを超える）が発生した際に、あらかじめ定義した自動アクション（例: データファイルの追加やサイズ拡張スクリプトの実行）をトリガーすることも可能です（ただし、自動拡張設定を適切に行っていれば、まずはそちらが機能します）。

OEM/ECCは、複数のデータベースを一元管理し、高度な監視・分析機能を利用できるため、大規模な環境では標準的な監視ツールとして広く利用されています。

b. AWR (Automatic Workload Repository) および Statspack

AWR (Oracle Database 10g以降のEnterprise Editionで利用可能) や Statspack (それ以前のバージョンやStandard Editionでも利用可能) は、一定間隔でデータベースの統計情報を自動的に収集し、リポジトリに格納するツールです。これらのツールが生成するレポートには、表領域の使用状況に関する情報も含まれており、時間経過に伴う使用率の変化や、特定の期間での増加量を分析するのに役立ちます。

特にAWRレポートの「Tablespace IO Stats」や「Tablespace Usage」セクションは、どの表領域がどの程度使用されているか、IO負荷が高いかなどを把握するのに有効です。これらのツールはリアルタイム監視というよりは、問題発生時の原因分析や、長期的なパフォーマンス・容量計画の観点で使用します。

3.3 スクリプトによる自動監視

OEM/ECCのようなGUIツールがない場合や、よりカスタマイズされた監視を行いたい場合は、SQL*PlusやPL/SQL、シェルスクリプトなどを組み合わせて独自の監視スクリプトを作成し、定期実行させる方法があります。

基本的なアプローチは以下の通りです。

1. 前述の「手動確認」で示したSQLクエリを実行するスクリプトを作成する。
2. スクリプトの実行結果（特に表領域の使用率）を取得する。
3. 設定したしきい値と比較する。
4. しきい値を超えている表領域があれば、DBAにメールなどで通知する。

a. SQLスクリプト例 (基本)

前述の表領域使用率確認クエリをSQLファイル (check_tablespace_usage.sqlなど) に保存し、SQL*Plusから実行します。

“`sql
— check_tablespace_usage.sql
SET HEADING OFF FEEDBACK OFF LINESIZE 200 PAGESIZE 0 VERIFY OFF

SELECT
t.tablespace_name || ‘,’ ||
ROUND((SUM(d.bytes) – SUM(DECODE(f.bytes, NULL, 0, f.bytes))) * 100 / SUM(d.bytes)) AS tablespace_usage_info
FROM
dba_tablespaces t
JOIN
dba_data_files d ON t.tablespace_name = d.tablespace_name
LEFT JOIN
dba_free_space f ON t.tablespace_name = f.tablespace_name
GROUP BY
t.tablespace_name
HAVING
— ここにしきい値を設定 (例: 使用率85%以上)
ROUND((SUM(d.bytes) – SUM(DECODE(f.bytes, NULL, 0, f.bytes))) * 100 / SUM(d.bytes)) >= 85
ORDER BY
t.tablespace_name;

EXIT;
``
**解説:**
*SETコマンドでヘッダーやフィードバックを非表示にし、スクリプト実行結果が扱いやすいようにします。
* 結果を「表領域名,使用率」のカンマ区切り形式で出力します。
*HAVING句で、指定したしきい値（例: 85%）以上の表領域に絞り込みます。このクエリ単体ではしきい値を超えたものだけが出力されるため、後続のシェルスクリプトなどで簡単に処理できます。
*EXIT` でSQL*Plusを終了します。

b. シェルスクリプト例 (Linux/Unix)

上記のSQLスクリプトを呼び出し、結果を処理してメール通知するシェルスクリプトの例です。

“`bash

!/bin/bash

環境変数設定 (必要に応じて修正)

ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
PATH=$ORACLE_HOME/bin:$PATH
export ORACLE_HOME PATH

接続情報

DB_USER=”monitoring_user” # 適切な監視ユーザーを使用 (DBA権限の一部または監視に必要な権限を付与)
DB_PASS=”password”
DB_SID=”your_db_sid” # または接続文字列 (例: your_service_name)

SQLスクリプトパス

SQL_SCRIPT=”/path/to/check_tablespace_usage.sql”

ログファイル

LOG_FILE=”/path/to/logs/tablespace_monitor_$(date +%Y%m%d).log”
ALERT_FILE=”/tmp/tablespace_alert.txt”

アラート通知先メールアドレス

ALERT_EMAIL=”[email protected]”
MAIL_SUBJECT=”[ALERT] Oracle Tablespace Usage High on ${DB_SID}”

監視実行

echo “— $(date) —” >> ${LOG_FILE}
sqlplus -s ${DB_USER}/${DB_PASS}@${DB_SID} @${SQL_SCRIPT} > ${ALERT_FILE} 2>&1

結果判定とメール送信

ALERT_CONTENT=$(cat ${ALERT_FILE})

if [ -s ${ALERT_FILE} ]; then
# アラートファイルに内容がある場合 (しきい値を超えた表領域がある)
echo “— Tablespaces exceeding threshold —” >> ${LOG_FILE}
echo “${ALERT_CONTENT}” >> ${LOG_FILE}
echo “${ALERT_CONTENT}” | mail -s “${MAIL_SUBJECT}” “${ALERT_EMAIL}”
echo “Alert email sent.” >> ${LOG_FILE}
else
# アラートファイルが空の場合 (問題なし)
echo “All tablespaces are within threshold.” >> ${LOG_FILE}
fi

一時ファイルの削除

rm ${ALERT_FILE}

exit 0
``
**解説:**
*sqlplus -sでSQL*Plusをサイレントモードで実行し、出力をリダイレクトします。
* SQLスクリプトの出力（しきい値を超えた表領域リスト）を一時ファイルに格納します。
* 一時ファイルに内容があれば（サイズがゼロでなければ）、その内容をメールで送信します。
*mailコマンドを使用してメールを送信しますが、環境によっては他のメール送信方法 (sendmail,muttなど) や、PL/SQLのUTL_MAILパッケージを使用することも可能です。
* このシェルスクリプトをcron` (Linux/Unix) やタスクスケジューラ (Windows) で定期的に実行するように設定します（例: 1時間に1回）。

c. PL/SQLによる自動監視

DBMS_SCHEDULER を使用して、PL/SQLプロシージャを定期的に実行させることも可能です。このプロシージャ内で表領域使用率を確認し、UTL_MAIL パッケージなどを使用してメール通知を行うことができます。この方法はOSスクリプトに依存せず、データベース内で完結できるメリットがあります。

“`sql
— PL/SQL プロシージャ例 (概要)
CREATE OR REPLACE PROCEDURE check_tablespace_usage_prc
AS
CURSOR cur_ts_usage IS
SELECT
t.tablespace_name,
ROUND((SUM(d.bytes) – SUM(DECODE(f.bytes, NULL, 0, f.bytes))) * 100 / SUM(d.bytes)) AS used_pct
FROM
dba_tablespaces t
JOIN
dba_data_files d ON t.tablespace_name = d.tablespace_name
LEFT JOIN
dba_free_space f ON t.tablespace_name = f.tablespace_name
GROUP BY
t.tablespace_name
HAVING
ROUND((SUM(d.bytes) – SUM(DECODE(f.bytes, NULL, 0, f.bytes))) * 100 / SUM(d.bytes)) >= 85; — しきい値 (例: 85%)

v_body CLOB := '以下の表領域がしきい値を超えています:' || CHR(10);
v_count NUMBER := 0;

BEGIN
FOR rec IN cur_ts_usage LOOP
v_body := v_body || rec.tablespace_name || ‘: ‘ || rec.used_pct || ‘%’ || CHR(10);
v_count := v_count + 1;
END LOOP;

IF v_count > 0 THEN
    -- UTL_MAIL パッケージを使用してメール送信
    -- UTL_MAIL パッケージを使用するには設定が必要です
    UTL_MAIL.send(
        sender => '[email protected]',
        recipients => '[email protected]',
        subject => '[ALERT] Oracle Tablespace Usage High on ' || SYS_CONTEXT('USERENV','DB_NAME'),
        message => v_body
    );
END IF;

EXCEPTION
WHEN OTHERS THEN
— エラーハンドリング (ログ出力など)
DBMS_OUTPUT.put_line(‘Error checking tablespace usage: ‘ || SQLERRM);
END;
/

— DBMS_SCHEDULER ジョブの作成 (例: 1時間ごとに実行)
BEGIN
DBMS_SCHEDULER.create_job (
job_name => ‘CHECK_TABLESPACE_USAGE_JOB’,
job_type => ‘PLSQL_PROCEDURE’,
job_action => ‘CHECK_TABLESPACE_USAGE_PRC’,
start_date => SYSTIMESTAMP,
repeat_interval => ‘FREQ=HOURLY; INTERVAL=1’, — 1時間ごとに実行
enabled => TRUE,
comments => ‘Check tablespace usage and send alert email’
);
END;
/
``
**解説:**
*check_tablespace_usage_prcというPL/SQLプロシージャを作成します。
* カーソル内でしきい値を超えた表領域をリストアップします。
*UTL_MAIL.sendプロシージャを呼び出してメールを送信します。UTL_MAILを使用するにはデータベース側での設定 (SMTP_OUT_SERVERパラメータ設定やACL設定) が必要です。
*DBMS_SCHEDULER.create_job` を使用して、このプロシージャを指定した間隔（例: 1時間ごと）で実行するジョブを作成します。

3.4 サードパーティ製監視ツール

Zabbix, Nagios, Prometheus, Datadogといった汎用的なITインフラ監視ツールも、Oracleデータベースの監視に対応しています。これらのツールは、専用のエージェントやプラグイン（例: ZabbixのOracleテンプレート、Prometheusのoracle_exporter）を使用して、Oracleデータベースから様々なメトリック（表領域使用率、セッション数、IO統計など）を収集し、 centralized なダッシュボードでの可視化、アラート管理、グラフによるトレンド分析などを実現します。

• メリット:
  • データベースだけでなく、OS、ミドルウェア、アプリケーションなど、システム全体の監視を一元化できる。
  • 高度なグラフ表示、長期的なトレンド分析機能。
  • 柔軟なアラート設定、エスカレーションルール。
• デメリット:
  • ツールの導入・設定・運用コストがかかる。
  • Oracle固有の詳細な内部情報は、ツールによっては取得が難しい場合がある。

既存の統合監視システムがある場合は、それにOracleデータベース監視を組み込むのが効率的です。

4. 表領域使用率の対処法

表領域使用率が高止まりしている、あるいは急増している場合、放置しておくと必ず問題が発生します。状況に応じて、予防策、緊急的な対処、そして根本的な対処を適切に組み合わせることが重要です。

4.1 予防策

問題が発生する前に proactive に対応することが最も重要です。

• 適切な初期容量の見積もり: データベース設計段階で、将来的なデータ増加量を考慮して、表領域の初期サイズとAUTOEXTEND設定を適切に行います。
• AUTOEXTENDの適切な設定:
  • AUTOEXTEND ON に設定し、領域不足による停止リスクを軽減します。
  • NEXT パラメータは、ディスクI/O効率と拡張頻度のバランスを考慮して適切な値を設定します（大きすぎると一度に大量の領域を消費し、小さすぎると拡張が頻繁に発生しオーバーヘッドになる可能性があります）。
  • MAXSIZE パラメータは、物理ディスク容量やファイルシステムの上限、データファイルの最大許容サイズ（OSやOracleのバージョンによる制限）を考慮して必ず設定します。UNLIMITED は安易に使用せず、上限を設定することで予期せぬディスク枯渇を防ぎます。
• 領域管理方法の徹底: 新規に作成する表領域は、必ずローカル管理表領域 (EXTENT MANAGEMENT LOCAL)、セグメント領域は自動管理 (SEGMENT SPACE MANAGEMENT AUTO) で作成します。これにより、断片化を抑え、領域管理効率を高めます。
• 定期的な領域使用状況の確認とトレンド分析: 前述の監視ツールやスクリプトを活用し、定期的に使用率を確認し、増加傾向がないかを分析します。これにより、将来的な容量不足を事前に予測できます。AWR/Statspackレポートも有用です。
• 不要なオブジェクトの削除: 定期的に不要なテーブル、索引、パーティション、一時的な作業用オブジェクトなどを特定し、削除します。
• RECYCLEBINの管理: 削除されたオブジェクトがRECYCLEBINに残存していると領域を消費するため、定期的に PURGE コマンドでRECYCLEBINを空にするか、PURGE_INTERVAL パラメータを設定して自動的にパージされるようにします。
• データ圧縮機能の検討: Oracle Database Enterprise Editionの一部のバージョンでは、テーブルや索引に対してデータ圧縮を適用できます。これにより、物理的なディスク使用量を削減できます。圧縮レベルや種類は用途に応じて選択します。
• パーティショニングの活用: 大規模なテーブルや索引では、パーティショニングを導入することで、古いデータを別の表領域に移動したり、簡単にアーカイブ・削除したりすることが容易になります。これにより、アクティブなデータの表領域サイズを管理しやすくします。
• UNDO表領域の適切なサイズ設定と監視: UNDO_RETENTION パラメータの設定値に基づいてUNDO表領域のサイズを適切に見積もり、必要に応じて拡張します。V$UNDOSTAT ビューで必要なUNDO容量の統計情報を確認できます。
• TEMP表領域の一時ファイル監視: TEMP表領域も、ソートやハッシュ結合などの処理で一時的に領域が消費されます。V$TEMPSEG_USAGE ビューで現在のセッションによる一時セグメントの使用状況を確認できます。必要に応じて一時ファイルを増やせるよう、TEMP表領域も複数の一時ファイルで構成したり、AUTOEXTENDを設定したりします。

4.2 緊急・一時的な対処

監視アラートを受け取るなど、表領域使用率がクリティカルなレベルに達した場合、迅速な対処が必要です。

• データファイルの追加: 最も一般的で手軽な対処法です。表領域に新しいデータファイルを追加します。
  sql
ALTER TABLESPACE tablespace_name
ADD DATAFILE '/path/to/new_datafile.dbf' SIZE 1G -- 初期サイズを指定
AUTOEXTEND ON NEXT 128M MAXSIZE UNLIMITED; -- または適切な最大サイズ
  • 新しいデータファイルを追加するための十分なディスク空き容量が必要です。
  • ファイル名はOSの命名規則に従い、一意である必要があります。
  • AUTOEXTEND設定を忘れずに行います。

• 既存のデータファイルのサイズ拡張: AUTOEXTEND ON になっていないデータファイルを拡張するか、MAXSIZE に近いデータファイルをさらに拡張します。
  “`sql
  ALTER DATABASE DATAFILE ‘/path/to/existing_datafile.dbf’
  RESIZE 5G; — 指定したサイズに拡張 (現在のサイズより大きく指定)

  — または、AUTOEXTENDのMAXSIZEを変更
  ALTER DATABASE DATAFILE ‘/path/to/existing_datafile.dbf’
  AUTOEXTEND ON MAXSIZE 10G; — 新しい最大サイズを指定
  * `RESIZE` は指定したサイズに固定します。AUTOEXTENDがONの場合は、そのサイズまで拡張されます。
* やはり十分なディスク空き容量が必要です。
* **巨大なセグメントの特定と対処:** 前述の`DBA_SEGMENTS`クエリなどで使用容量の多いセグメントを特定します。
* **不要なオブジェクトの削除:** もしそのセグメントが不要であれば、`DROP TABLE`, `DROP INDEX` などで削除します。RECYCLEBINに残るため、続けて `PURGE TABLE table_name` や `PURGE RECYCLEBIN` を実行して領域を解放します。
* **ログテーブルなどの整理:** アプリケーションのログテーブルなどが肥大化している場合は、古いデータを削除またはアーカイブします。
* **一時的なオブジェクトの削除:** アプリケーションが一時的に作成して削除し忘れているテーブルなどがないか確認し、あれば削除します。
* **セグメントの再編成 (Reorganization):** テーブルや索引は、更新や削除を繰り返すと内部的に断片化が進み、未使用の領域（High Water Mark より下の領域で空いている部分）が発生することがあります。この領域は、新たなデータ挿入には再利用されますが、表領域の空き容量としては計上されません。セグメントを再編成することで、断片化を解消し、実際に使用されている領域だけを新しい領域にコピーし直すことで、未使用領域を解放し、物理的なサイズを縮小できます。
* **テーブルの再編成:**sql
  — テーブル内の未使用領域を解放 (Onlineで可能、ただし制約やトリガーに注意)
  ALTER TABLE table_name SHRINK SPACE CASCADE; — CASCADEで依存するLOBなども対象にする
  — または、テーブルを別の表領域に移動 (Offlineになる)
  ALTER TABLE table_name MOVE TABLESPACE new_tablespace_name;
  * `SHRINK SPACE` はOracle 10gR2以降で利用可能なOnline再編成方法ですが、いくつかの制限があります。
* `MOVE` はテーブル全体を再構築するため、時間がかかり、その間テーブルはロックされます。移動後に索引も再構築する必要があります (`ALTER INDEX index_name REBUILD;`)。
* **索引の再編成:**sql
  — 索引を再構築 (Offlineになる)
  ALTER INDEX index_name REBUILD;
  — または、索引を別の表領域に移動しながら再構築 (Offlineになる)
  ALTER INDEX index_name REBUILD TABLESPACE new_tablespace_name;
  * 索引の再構築はテーブルよりは短時間で済みますが、やはりその間索引はロックされます。
* **Export/Import または Data Pump による再構築:** 古典的な方法ですが、オブジェクトをエクスポートし、削除してから、インポートし直すことで、物理的に再編成できます。Data Pump (`expdp`/`impdp`) を使用するのが現在の主流です。これにより、オブジェクトを新しい表領域に移動することも容易です。
* **UNDO表領域が原因の場合:**
* UNDO表領域の使用率が高い場合、長時間実行されているトランザクションがないか`V$TRANSACTION`や`DBA_UNDO_EXTENTS`などで確認します。
* `UNDO_RETENTION` パラメータの値が適切か確認します。短すぎる場合はORA-01555が発生しやすく、長すぎる場合はUNDO表領域が肥大化しやすくなります。システムの負荷やトランザクションの実行時間を考慮して調整します。
* UNDO表領域のサイズ不足であれば、UNDO表領域自体にデータファイルを追加するか、既存のデータファイルを拡張します。UNDO表領域もAUTOEXTENDを適切に設定すべきです。
* **TEMP表領域が原因の場合:**
* `V$TEMPSEG_USAGE` ビューで、どのセッションがTEMP領域を大量に使用しているか、どのSQL文が原因かを特定します。
* TEMP表領域に一時ファイルを追加します。TEMP表領域は `ADD TEMPFILE` でファイルを追加します。永続表領域の `ADD DATAFILE` とは異なります。sql
  ALTER TABLESPACE temp_tablespace_name
  ADD TEMPFILE ‘/path/to/new_tempfile.dbf’ SIZE 1G — 初期サイズを指定
  AUTOEXTEND ON NEXT 128M MAXSIZE UNLIMITED; — または適切な最大サイズ
  ``
* TEMP表領域もAUTOEXTENDを適切に設定します。
* TEMP領域を大量に使用するSQL文があれば、実行計画を見直したり、インデックスを追加したりしてチューニングを行います。
* **AUDIT_TRAIL の肥大化:** 監査ログがDBに格納されている場合、AUD$` テーブルなどがSYSTEMやSYSAUX表領域を圧迫することがあります。不要な監査ログを削除したり、OSファイルやSyslogに出力するように設定を変更したりします。

4.3 根本的な対処・計画

緊急対応で一時的に凌いだ後や、監視結果から将来的な問題が予測される場合は、より根本的な対処や容量拡張計画を立てる必要があります。

• 容量拡張の計画: 監視データから将来のデータ増加率を予測し、必要なディスク容量を計画的に確保します。物理ディスクの増設や、ストレージシステムの拡張などが必要です。
• データベース設計の見直し: データモデル、インデックス戦略、パーティショニングなど、データベース設計そのものを見直します。非正規化が進みすぎて無駄にデータが重複していないか、適切なインデックスがないために大規模なソートや結合が発生していないかなどを確認します。
• 古いデータのアーカイブ戦略: 不要になった過去のデータは、定期的にアーカイブストレージに移動するか、削除する仕組みを構築します。パーティショニングが有効な手段となります。
• 領域管理パラメータの見直し: テーブルや索引作成時の PCTFREE, PCTUSED, INITRANS, MAXTRANS などのパラメータが適切か確認します。例えば、更新頻度の高いテーブルでPCTFREEが小さすぎると、行移行/行連鎖が発生しやすくなり、パフォーマンス低下や領域効率の悪化を招きます。
• バージョンアップによる新機能の活用: 新しいOracle Databaseのバージョンでは、データ圧縮機能の強化、自動ストレージ管理機能の改善など、領域管理や効率化に役立つ新機能が追加されていることがあります。バージョンアップも選択肢の一つとなります。

5. よくある問題とトラブルシューティング

5.1 表領域は空きがあるのにORAエラーが発生する

表領域全体の空き容量が十分にあるように見えても、以下の原因で領域関連のエラーが発生することがあります。

• 断片化: 特にディクショナリ管理表領域 (非推奨) や、MSSMのローカル管理表領域、あるいは頻繁な削除・更新が行われる表領域で、連続した空き領域が不足している場合に発生しやすいです。エクステントサイズが大きく設定されていると、そのサイズ分の連続領域が見つからずにエラーとなることがあります。LMT+ASSMの組み合わせで発生しにくくなります。
  • 対処: セグメントの再編成 (SHRINK SPACE, MOVE, REBUILD) や、表領域の再作成 (古い表領域のデータを新しい表領域に移動) で断片化を解消します。
• AUTOEXTENDのMAXSIZE到達: データファイルがMAXSIZEに設定された上限に達し、それ以上拡張できない場合に発生します。
  • 対処: 当面の対応としては、ALTER DATABASE DATAFILE ... AUTOEXTEND ON MAXSIZE ... でより大きなサイズを指定するか、ALTER TABLESPACE ... ADD DATAFILE ... で新しいデータファイルを追加します。根本的には、ディスク容量の確保や設計の見直しが必要です。
• UNDO不足 (ORA-01555, ORA-30036): 長時間実行されるトランザクションが必要なUNDO情報が保持されずに上書きされてしまう (ORA-01555)、あるいは、新しいトランザクションがUNDO表領域にエクステントを割り当てられずに失敗する (ORA-30036) といった問題です。
  • 対処: UNDO_RETENTION パラメータの見直し、UNDO表領域へのデータファイル追加や拡張を行います。
• TEMP不足 (ORA-01652): ソートやハッシュ結合などの処理に必要な一時セグメントをTEMP表領域に作成できない場合に発生します。
  • 対処: TEMP表領域への一時ファイル追加や拡張、TEMP表領域のAUTOEXTEND設定確認、TEMP領域を大量に使用するSQLのチューニングを行います。
• 特定のデータファイルの空き容量不足: 表領域は複数のデータファイルで構成されている場合、表領域全体の空き容量は十分でも、特定のデータファイルがほぼ満杯で、かつそのデータファイルに新しいエクステントを割り当てようとした際にエラーとなる場合があります。ローカル管理表領域+ASSMの場合は、空きブロックが適切に管理されるため発生しにくいですが、EXTENT SIZEをAUTOではなく特定のサイズで固定している場合などに発生可能性がゼロではありません。
  • 対処: そのデータファイルの拡張、または他のデータファイルへのセグメント移動などを検討します。

5.2 RECYCLEBINの肥大化

DROP TABLEなどで削除されたオブジェクトがRECYCLEBINに大量に蓄積され、領域を圧迫しているケースです。特にPURGEを定期的に実行していない場合に発生します。

• 原因: PURGEコマンドが実行されていない。
• 対処:
  • PURGE RECYCLEBIN; (現在のユーザーのRECYCLEBINをパージ)
  • PURGE DBA_RECYCLEBIN; (SYSDBA権限などで、データベース全体のRECYCLEBINをパージ)
  • 定期的なバッチ処理やDBMS_SCHEDULERジョブでPURGEを実行するように設定します。
  • テーブル作成時に PURGE オプション（例: CREATE TABLE ... PURGE;）を付けて、削除時にRECYCLEBINを経由しないようにすることも可能です（ただし、誤削除時のリカバリはできなくなります）。

5.3 AUDIT_TRAILの肥大化

監査機能 (AUDIT_TRAIL) が有効になっている場合、監査情報がSYSAUX表領域やSYSTEM表領域に格納されるテーブル（AUD$, FGA_LOG$など）に蓄積され、これらの表領域が肥大化することがあります。

• 原因: 監査設定が過剰である、または監査ログの定期削除が行われていない。
• 対処:
  • 不要な監査設定を無効化します。
  • AUD$, FGA_LOG$ テーブルなどの古い監査ログを定期的に削除またはアーカイブします。Oracle Database 10gR2以降では、DBMS_AUDIT_MGMT パッケージを使用して監査ログを管理・パージするのが推奨されます。
  • 監査ログの出力先をデータベースではなく、OSファイルやSyslogに変更することも検討します。

5.4 特定セグメントの異常な増加

特定のテーブルや索引が予期せず急速にサイズを増大させているケースです。

• 原因:
  • 大量のデータが短期間に挿入されている。
  • LOBセグメント（BLOB/CLOB）を使用しているテーブルで、LOBデータが大量に書き込まれている。
  • アプリケーションの一時的な作業で大量のデータが一時テーブルに書き込まれたまま削除されていない。
  • 監査ログ、アプリケーションログ、トレース情報などがデータベースに書き込まれている。
• 対処:
  • 前述のDBA_SEGMENTSクエリで肥大化しているセグメントを特定します。
  • そのセグメントに関連するアプリケーション処理やSQL文を特定し、データ挿入量の確認やSQLのチューニングを行います。
  • LOBセグメントであれば、LOBデータの格納方法や削除ロジックを確認します。
  • 不要な一時テーブルであれば削除します。
  • 監査ログやアプリケーションログであれば、適切な管理（削除、アーカイブ、出力先変更）を行います。

6. まとめ

Oracleデータベースの表領域使用率の管理は、データベースの安定稼働、性能維持、および将来的な容量計画において不可欠な活動です。

本記事では、表領域の基本的な構造と種類、手動での確認方法（SQL*Plusとデータディクショナリビュー）、自動化された監視（OEM/ECC、スクリプト、サードパーティツール）、そして具体的な対処法について詳細に解説しました。

最も重要なのは、問題が発生してから対応するのではなく、日頃から表領域の使用状況を監視し、増加傾向を把握し、しきい値に基づくアラートを設定しておくことです。これにより、領域不足の兆候を早期に検知し、ディスク容量の確保、データファイルの追加・拡張、不要オブジェクトの削除、セグメントの再編成、UNDO/TEMP領域のチューニングといった予防的な、あるいは迅速な対処を行うことができます。

また、RECYCLEBINや監査ログといった、意外な領域消費源にも注意が必要です。定期的なハウスキーピング作業を運用プロセスに組み込むことで、健全なデータベース環境を維持できます。

データベースの規模や特性に応じて、適切な確認方法、監視ツール、対処戦略を選択・組み合わせ、継続的な運用を行うことが、Oracleデータベースを安定的に稼働させるための鍵となります。

7. 付録 (主要なSQLクエリまとめ)

本記事中で紹介した主要なSQLクエリを再掲します。これらのクエリは、表領域使用率の確認・監視において非常に役立ちます。

“`sql
— 各表領域の使用率を確認するクエリ
SELECT
t.tablespace_name,
ROUND(SUM(d.bytes) / 1024 / 1024) AS total_size_mb,
ROUND(SUM(DECODE(f.bytes, NULL, 0, f.bytes)) / 1024 / 1024) AS free_size_mb,
ROUND((SUM(d.bytes) – SUM(DECODE(f.bytes, NULL, 0, f.bytes))) / 1024 / 1024) AS used_size_mb,
ROUND((SUM(d.bytes) – SUM(DECODE(f.bytes, NULL, 0, f.bytes))) * 100 / SUM(d.bytes)) AS used_pct
FROM
dba_tablespaces t
JOIN
dba_data_files d ON t.tablespace_name = d.tablespace_name
LEFT JOIN
dba_free_space f ON t.tablespace_name = f.tablespace_name AND d.file_id = f.file_id — 厳密な計算のため
GROUP BY
t.tablespace_name
ORDER BY
used_pct DESC;

— AUTOEXTENDが有効なデータファイルを確認するクエリ
SELECT
file_name,
tablespace_name,
ROUND(bytes / 1024 / 1024) AS current_size_mb,
autoextensible,
ROUND(maxbytes / 1024 / 1024) AS max_size_mb,
ROUND(increment_by * (SELECT value FROM v$parameter WHERE name = ‘db_block_size’) / 1024 / 1024) AS next_extend_size_mb
FROM
dba_data_files
WHERE
autoextensible = ‘YES’
ORDER BY
tablespace_name, file_name;

— 各セグメントの使用容量トップ20を確認するクエリ
SELECT
owner,
segment_name,
segment_type,
tablespace_name,
ROUND(bytes / 1024 / 1024) AS used_size_mb
FROM
dba_segments
ORDER BY
bytes DESC
FETCH FIRST 20 ROWS ONLY; — Oracle 12c以降

— 特定の表領域内のセグメントの使用容量トップ10を確認するクエリ (例: ‘USERS’)
SELECT
owner,
segment_name,
segment_type,
ROUND(bytes / 1024 / 1024) AS used_size_mb
FROM
dba_segments
WHERE
tablespace_name = ‘USERS’ — 確認したい表領域名に変更
ORDER BY
bytes DESC
FETCH FIRST 10 ROWS ONLY; — Oracle 12c以降

— RECYCLEBINの内容とサイズを確認するクエリ
SELECT
owner,
object_name,
original_name, — 元のオブジェクト名
type,
ts_name, — 表領域名
ROUND(space * (SELECT value FROM v$parameter WHERE name = ‘db_block_size’) / 1024 / 1024) AS space_used_mb,
droptime
FROM
dba_recyclebin
ORDER BY
space DESC;

— CDB環境で各PDBの表領域使用率を確認するクエリ (CDB$ROOTから実行)
SELECT
c.con_name, — PDB名
t.tablespace_name,
ROUND(SUM(d.bytes) / 1024 / 1024) AS total_size_mb,
ROUND(SUM(DECODE(f.bytes, NULL, 0, f.bytes)) / 1024 / 1024) AS free_size_mb,
ROUND((SUM(d.bytes) – SUM(DECODE(f.bytes, NULL, 0, f.bytes))) / 1024 / 1024) AS used_size_mb,
ROUND((SUM(d.bytes) – SUM(DECODE(f.bytes, NULL, 0, f.bytes))) * 100 / SUM(d.bytes)) AS used_pct
FROM
cdb_tablespaces t
JOIN
cdb_data_files d ON t.tablespace_name = d.tablespace_name AND t.con_id = d.con_id
LEFT JOIN
cdb_free_space f ON t.tablespace_name = f.tablespace_name AND d.file_id = f.file_id AND t.con_id = f.con_id
JOIN
v$containers c ON t.con_id = c.con_id
WHERE c.con_id > 2 — PDBのみを対象
GROUP BY
c.con_name, t.tablespace_name
ORDER BY
c.con_name, used_pct DESC;

— UNDO表領域の使用状況 (過去の統計)
SELECT
TO_CHAR(begin_time, ‘YYYY-MM-DD HH24:MI’) AS begin_time,
TO_CHAR(end_time, ‘YYYY-MM-DD HH24:MI’) AS end_time,
undoblks, — 消費されたUNDOブロック数
txncount, — アクティブトランザクション数
maxquerylen, — 最も長い実行クエリ時間 (秒)
maxconcurrency, — 最大同時実行トランザクション数
unxpstealcnt + unxpblkrelcnt + unxpblkreucnt + expstealcnt + expblkrelcnt + expblkreucnt AS steal_rel_reucnt, — UNDO不足による領域の再利用試行回数
ROUND(undoblks * (SELECT value FROM v$parameter WHERE name = ‘db_block_size’) / 1024 / 1024) AS undoblks_mb
FROM
v$undostat
ORDER BY
begin_time DESC
FETCH FIRST 10 ROWS ONLY;

— 現在TEMP領域を使用しているセッション
SELECT
s.sid,
s.serial#,
s.username,
s.program,
t.tablespace,
ROUND(t.contents / 1024 / 1024) AS used_temp_mb,
sql_text — 使用中のSQL文 (実行権限が必要)
FROM
v$sort_usage t
JOIN
v$session s ON t.session_addr = s.saddr AND t.session_num = s.serial#
LEFT JOIN
v$sqltext_with_newlines st ON s.sql_address = st.address AND s.sql_hash_value = st.hash_value
ORDER BY
used_temp_mb DESC;

“`

これらのクエリをベースに、皆様の環境に合わせた監視スクリプトや運用手順を構築していただければ幸いです。

---

注意: 上記のクエリやスクリプト例は一般的なケースを想定しています。実際のデータベース環境やOracleのバージョンによっては、構文やビュー名が異なる場合、特定の権限が必要な場合、追加の設定が必要な場合があります。実行前に環境に合わせて適切に修正・テストを行ってください。

---

このドキュメントは、Oracleデータベースの表領域管理に関する網羅的な情報を提供することを目的としています。約5000語という要件を満たすため、各セクションを詳細に記述しました。皆様のデータベース運用の一助となれば幸いです。