- Oracle Database
- Oracle Cloud
Oracle Databaseユーザー必見！ZRCVで始めるランサムウェア対策
ランサムウェアの脅威からデータベースを守る！OCIのフルマネージドバックアップサービスZRCVは、3-2-1-1-0ルールに対応し、データ損失ゼロに近い復旧を実現します。本記事では堅牢な保護機能と、GUIで完結するわずか5ステップのシンプルな設定方法を解説します。
|
|
監視ツールから「SYSAUX表領域の使用率が90％超」というアラートが届いたり、ある日突然ORA-1653（表領域の拡張エラー）が発生したり──。Oracle Databaseを運用していると、「気付いたらSYSAUX表領域が肥大化していた」という状況は決して珍しくありません。
しかし、SYSAUXにはAWRや統計情報、各種アドバイザなど多くのコンポーネントが集約されているため、「どこから手を付けて良いか分からない」「消してはいけないものまで消してしまいそうで怖い」と感じている方も多いのではないでしょうか。
この表領域がいっぱいになると領域不足のエラー（ORA-1653）が発生し、統計情報の取得処理や重要コンポーネントの処理が失敗する可能性があります。
本記事では、SYSAUX表領域の肥大化の主な原因と、現場DBAの方がいますぐ実践できる原因特定・対処・予防のステップを、具体的なSQL例とともに整理して解説します。
＜本記事でわかること＞
Index
SYSAUX表領域は、SYSTEM表領域の補助的な役割を担っています。
AWRやアドバイザー、データベースコンポーネントのデータが格納されており、多くの管理系情報の保管場所になっています。
SYSAUX表領域が肥大化し、十分な空き容量を確保できなくなると、以下のような問題が発生する可能性があります。
・領域不足のエラー（ORA-1653）の発生
・AWRスナップショット取得処理の失敗
・統計情報取得処理の失敗
・SYSAUX表領域を使用するコンポーネント処理の失敗
SYSAUX表領域が肥大化してしまった場合は、まず「どこがどれくらい使っているのか」を把握するところから始める必要があります。
次の章では、実際に肥大化が疑われる場合の対応フローを整理します。
SYSAUX表領域が肥大化した際の対応フローは、大きく次の3つのステップに分けられます。
【原因を特定する】
【原因別に対処する】
【事前に対策する】
図にすると、以下のような流れになります。
|
以降の章で、それぞれのステップを具体的なSQL例とともに解説していきます。
このステップでは、SYSAUX表領域内で多くの容量を消費しているコンポーネントを特定します。
SYSAUX表領域は複数のコンポーネントによって共有されています。肥大化の多くは、特定のコンポーネントのデータが長期間保存され続けていることが原因になっている場合がほとんどです。
ここで押さえておきたいポイントは、次の2つです。
・どのコンポーネントが全体の容量を圧迫しているのか
・どのコンポーネントに対して対処すべきか
こうして「どのコンポーネントがどれだけ容量を使用しているか」を把握しておけば、次に行うべきデータ削除や保存期間の見直しといった具体的な対処方針を決めやすくなります。
以下のSQLで、動的パフォーマンスビューV$SYSAUX_OCCUPANTSを参照し、コンポーネントごとの使用容量（MB）を一覧できます。
下記のSQLを実行し、肥大化している部分を特定します。
SQL> set line 1000 pages 1000
col SCHEMA_NAME for a25
col OCCUPANT_NAME for a30
select SCHEMA_NAME,OCCUPANT_NAME,trunc(SPACE_USAGE_KBYTES/1024,1)
"SPACE_USAGE_MBYTES" from V$SYSAUX_OCCUPANTS order by 3 desc;
出力結果から、SPACE_USAGE_MBYTESの値が極端に大きいコンポーネントを特定します。
下記は出力結果の一例です。この例ではSM/AWRが17,084.3 MBと圧倒的な容量を占めており、AWR関連情報が肥大化の主因であることがわかります。
SQL> select SCHEMA_NAME,OCCUPANT_NAME,
2 trunc(SPACE_USAGE_KBYTES/1024,1) "SPACE_USAGE_MBYTES"
3 from V$SYSAUX_OCCUPANTS order by 3 desc;
SCHEMA_NAME OCCUPANT_NAME SPACE_USAGE_MBYTES
------------------------- ------------------------------ ------------------
SYS SM/AWR 17084.3
SYS SM/OPTSTAT 2555.1
PERFSTAT STATSPACK 1548.7
SYS SM/OTHER 126.3
SYS JOB_SCHEDULER 83.5
AUDSYS AUDSYS 74.3
XDB XDB 68.1
SYS SM/ADVISOR 56.1
SYSMAN EM 49.9
SYS AO 45.8
OLAPSYS XSAMD 15.5
SYSTEM LOGMNR 11
SYS SQL_MANAGEMENT_BASE 7.6
WMSYS WM 6.5
SYS SMON_SCN_TIME 3.3
SYS PL/SCOPE 2.8
CTXSYS TEXT 2.7
SYS STREAMS 1.6
SYSTEM LOGSTDBY 1.5
SYS AUDIT_TABLES 1
DBSNMP EM_MONITORING_USER .9
SYS AUTO_TASK .5
TSMSYS TSM .2
SYS XSOQHIST 0
WKSYS ULTRASEARCH 0
ORDSYS ORDIM 0
EXFSYS EXPRESSION_FILTER 0
MDSYS SDO 0
SI_INFORMTN_SCHEMA ORDIM/SI_INFORMTN_SCHEMA 0
ORDPLUGINS ORDIM/ORDPLUGINS 0
ORDDATA ORDIM/ORDDATA 0
WK_TEST ULTRASEARCH_DEMO_USER 0
32行が選択されました。
前のステップでSYSAUX領域を最も占めているコンポーネントを特定できました。次はセグメント単位で肥大化している箇所を特定します。
実際のディスクスペースを消費しているのは、そのコンポーネントが使用している具体的な表や索引（セグメント）です。
データ削除やセグメント縮小といった対処は常にセグメント単位で行うため、どのセグメントが最も肥大化しているかを正確に把握する必要があります。
以下のSQLはDBA_SEGMENTSビューを利用して、SYSAUX表領域に存在するすべてのセグメントについて、
・所有者（OWNER）
・セグメント名（SEGMENT_NAME）
・タイプ（SEGMENT_TYPE）
・SYSAUX全体に占める容量の割合（%）
を取得し、割合の大きい順に並べ替えてくれます。
この結果をもとに、「AWR関連」「統計情報の履歴」「アドバイザ関連」など、次章で紹介するコンポーネント別の対処方法を適用していきます。
出力結果から、「SIZE(MB)」や「%」の値が大きいセグメントを確認し、それがどのコンポーネントに属するかをセグメント名から特定します。
SQL> set line 1000 pages 1000
col SEGMENT_TYPE for a20
col OWNER for a10
col SEGMENT_NAME for a30
col PARTITION_NAME for a30
select SEGMENT_TYPE,OWNER,SEGMENT_NAME,PARTITION_NAME,
bytes/1048576 "SIZE(MB)", trunc(bytes*100/t.tb, 2) "%" from DBA_SEGMENTS,
(select sum(bytes) tb from DBA_SEGMENTS where TABLESPACE_NAME='SYSAUX') t
where TABLESPACE_NAME='SYSAUX' order by 6 desc,1;
下記が出力結果の一例です。
SQL> select SEGMENT_TYPE,OWNER,SEGMENT_NAME,PARTITION_NAME,
2 bytes/1048576 "SIZE(MB)", trunc(bytes*100/t.tb, 2) "%" from DBA_SEGMENTS,
3 (select sum(bytes) tb from DBA_SEGMENTS where TABLESPACE_NAME='SYSAUX') t
4 where TABLESPACE_NAME='SYSAUX' order by 6 desc,1;
SEGMENT_TYPE OWNER SEGMENT_NAME PARTITION_NAME SIZE(MB) %
-------------------- ---------- ------------------------------ ------------------------------ ---------- ----------
INDEX SYS I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST 984 4.42
INDEX SYS I_WRI$_OPTSTAT_H_ST 459 2.06
INDEX PERFSTAT STATS$SYSSTAT_PK 287 1.28
TABLE PERFSTAT STATS$SYSSTAT 205 .92
LOBSEGMENT SYS SYS_LOB0000010460C00001$$ 160.125 .71
TABLE PERFSTAT STATS$LATCH 138 .62
INDEX PERFSTAT STATS$LATCH_PK 136 .61
INDEX PERFSTAT STATS$EVENT_HISTOGRAM_PK 128 .57
TABLE SYS WRH$_SYSMETRIC_SUMMARY 120 .53
LOBSEGMENT SYS SYS_LOB0000364957C00038$$ 112.1875 .5
TABLE SYS WRH$_CON_SYSMETRIC_SUMMARY 104 .46
TABLE PERFSTAT STATS$SQL_SUMMARY 100 .44
INDEX SYS I_WRI$_OPTSTAT_HH_OBJ_ICOL_ST 96 .43
INDEX SYS WRH$_SYSMETRIC_SUMMARY_INDEX 88 .39
INDEX SYS WRH$_ENQUEUE_STAT_PK 88 .39
TABLE PERFSTAT STATS$EVENT_HISTOGRAM 88 .39
INDEX SYS I_WRI$_OPTSTAT_HH_ST 82 .36
INDEX SYS WRH$_BG_EVENT_SUMMARY_PK 80 .35
INDEX SYS WRH$_CON_SYSMET_SUMMARY_INDEX 72 .32
INDEX PERFSTAT STATS$PARAMETER_PK 64 .28
＜以下省略＞
この結果をもとに、次章で紹介する「コンポーネント別の対処方法」を適用していきます。
ここからは、代表的な肥大化要因ごとに、対処方法を整理していきます。
まずは、肥大化の原因となりやすいコンポーネントと、その格納情報・セグメント名の接頭辞を一覧にしておきます。
以下の早見表で「どのコンポーネントが、どのような情報を、どのセグメント名で持っているか」を整理してから、代表的な3つの原因パターンごとの対処方法を見ていきます。
| 肥大化原因 | コンポーネント名 | セグメント名接頭辞 | |
|---|---|---|---|
| ① | AWR関連情報 | SM/AWR | WRH$ |
| WRM$ | |||
| WRI$_SCH | |||
| ② | 統計情報の履歴情報 | SM/OPTSTAT | WRI$_OPTSTAT |
| I_WRI$_OPTSTAT | |||
| OPTSTAT | |||
| ③ | SQLチューニングアドバイザ、SQLアクセスアドバイザ、ADDMに関する情報 | SM/ADVISOR | WRI$_ADV |
| WRI$_SQLSET |
この早見表で「どのコンポーネントが、どのような情報を、どのセグメント名で持っているか」を整理したうえで、以降で代表的な3つの原因パターン（AWR関連情報／統計情報の履歴情報／アドバイザ関連情報）ごとに、具体的な対処手順を見ていきます。
肥大化しているコンポーネントがSM/AWRだった場合、AWRが収集・保持しているスナップショットデータが大量に蓄積していることが原因です。
対処の流れは以下のとおりです。
1. 不要なスナップショットデータを削除する
DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGEプロシージャを使用
2. AWR関連のセグメント（WRH$、WRM$または WRI$_SCHから始まるセグメント）を縮小する（※1）
＜スナップショットIDを指定して不要なスナップショットデータを削除するSQL＞
SQL> connect /as sysdba
SQL> select SNAP_ID,BEGIN_INTERVAL_TIME,END_INTERVAL_TIME from DBA_HIST_SNAPSHOT order by SNAP_ID;
SQL> exec DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(<開始ID>, <終了ID>);
- 実行例：
1、スナップショットID=9141～9142 の情報を削除する
SQL> connect /as sysdba
SQL> exec DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(9141, 9142);
2、セグメントをmoveして縮小させる
SQL> alter table SYS.WRH$_SYSMETRIC_SUMMARY move tablespace SYSAUX;
肥大化しているコンポーネントがSM/OPTSTATだった場合、Oracle Databaseが保持しているオプティマイザー統計の履歴情報が大量に蓄積していることが原因です。
対処の流れは以下のとおりです。
1.不要な統計情報の履歴を削除する。
DBMS_STATS.PURGE_STATS プロシージャを使用
2.統計情報履歴関連のセグメント（WRI$_OPTSTAT、I_WRI$_OPTSTATまたはOPTSTATから始まるセグメント）を縮小する（※1）
＜統計情報の履歴情報を削除するSQL＞
・時間指定して削除する
SQL> exec DBMS_STATS.PURGE_STATS (TO_TIMESTAMP('// ','YYYY/MM/DD HH24:MI:SS'));
・全削除する
SQL> exec DBMS_STATS.PURGE_STATS (DBMS_STATS.PURGE_ALL)
- 実行例：
1、2025/10/31 10:00:00 よりも前に保存された統計情報の履歴情報を削除する
SQL> exec DBMS_STATS.PURGE_STATS (TO_TIMESTAMP('2025/10/31 10:00:00','YYYY/MM/DD HH24:MI:SS'));
2、セグメントをrebulidすることで縮小させる
SQL> alter index SYS.I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST rebuild tablespace SYSAUX;
コンポーネントSM/ADVISORが肥大化している場合は、以下のOracle Databaseの各種アドバイザー機能の情報が大量に蓄積している可能性があります。
・SQLチューニングアドバイザー
・セグメントアドバイザー
・それらの基盤となるADDM (Automatic Database Diagnostic Monitor) の情報など
対処の流れは以下のとおりです。
1.不要なアドバイザーのタスク情報を削除する
DBMS_ADVISOR.DELETE_TASKプロシージャを使用
2.ADDM関連のセグメント（WRI$_ADVまたはWRI$_SQLSETから始まるセグメント）を縮小する（※1）
＜タスク情報を削除するSQL＞
SQL> connect /as sysdba
alter session set NLS_DATE_FORMAT= 'yyyy-mm-dd hh24:mi:ss';
select TASK_ID, TASK_NAME, EXECUTION_START, EXECUTION_END,
STATUS_MESSAGE from DBA_ADVISOR_LOG order by TASK_ID;
exec DBMS_ADVISOR.DELETE_TASK('<タスク名>');
- 実行例：
1、タスク名がADDM:1234567890_1_1000の情報を削除する
SQL> connect /as sysdba
alter session set NLS_DATE_FORMAT= 'yyyy-mm-dd hh24:mi:ss';
select TASK_ID, TASK_NAME, EXECUTION_START, EXECUTION_END, STATUS_MESSAGE from DBA_ADVISOR_LOG order by TASK_ID;
exec DBMS_ADVISOR.DELETE_TASK('ADDM:1234567890_1_1000');
2、セグメントをTRUNCATE／MOVE／REBUILDして縮小する（※1）
アドバイザ関連のテーブルでは、セグメントの種類によって縮小方法が異なります。
* TABLE：`ALTER TABLE ... MOVE`
* INDEX：`ALTER INDEX ... REBUILD`
* LONG型を含むTABLE（例：`WRI$_ADV_OBJECTS`）
* `MOVE`／`REBUILD` ができないため、データが不要であれば `TRUNCATE TABLE` を検討
SQL> TRUNCATE TABLE WRI$_ADV_OBJECTS;
ここまでご紹介したのは、すでに肥大化してしまった場合の「治療」です。
トラブルを未然に防ぐためには、日常運用の中で「肥大化しにくい状態」を作っておくことも重要です。
SYSAUX表領域の肥大化を事前に防ぐ代表的な方法は、以下の3つです。
・不要なアドバイザーや機能を停止する
・SYSAUX表領域に保存されている情報の保存期間を見直し、適切に設定する
・SYSAUX表領域の使用率を定期的に監視し、増加傾向を早期に検知する
ここからは、先ほど挙げた「不要なアドバイザーや機能を停止する」方法について、もう少し詳しく見ていきます。
アドバイザーや機能の中には、データベースの環境によっては必須ではないものも存在します。使用していないアドバイザーや機能があれば、それらを停止することで、SYSAUX表領域の肥大化リスクを低減できます。
＜アドバイザーの有効状態を確認するSQL＞
SQL> select CLIENT_NAME, STATUS from DBA_AUTOTASK_CLIENT order by CLIENT_NAME;
＜自動セグメントアドバイザーを無効化するSQL＞
SQL> exec DBMS_AUTO_TASK_ADMIN.DISABLE(client_name => 'auto space advisor', operation => NULL,window_name => NULL);
＜SQLチューニングアドバイザーを無効化するSQL＞
※SQLチューニングアドバイザーの利用には、以下の全てが必要です。
・Oracle Database Enterprise Editionライセンス
・Oracle Diagnostics Pack
・Oracle Tuning Pack
SQL>BEGIN
DBMS_AUTO_TASK_ADMIN.DISABLE (
client_name => 'sql tuning advisor',
operation => NULL,
window_name => NULL);
END;
/
＜自動オプティマイザー統計を無効化するSQL＞
SQL> BEGIN
DBMS_AUTO_TASK_ADMIN.DISABLE (
client_name => 'auto optimizer stats collection',
operation => NULL,
window_name => NULL );
END;
/
＜オプティマイザー統計アドバイザーの有効状態を確認するSQL＞
SQL> select DBMS_STATS.GET_PREFS('AUTO_STATS_ADVISOR_TASK') from dual;
＜オプティマイザー統計アドバイザーを無効化するSQL＞
個別パッチ（26749785）を適用した状態で下記コマンドを実行してください。
SQL> exec DBMS_STATS.SET_GLOBAL_PREFS('AUTO_STATS_ADVISOR_TASK','FALSE');
次に、『保存期間を見直す』方法について詳しく見ていきます。
SYSAUX表領域の肥大化の要因の一つは、AWRスナップショットや統計情報などの履歴が長期間蓄積されることです。環境の要件に合わせて「どこまで過去の情報が必要か」を見極め、これらの情報の保存期間を適切に設定することで、肥大化リスクを低減できます。
＜ADDMに関する情報の保持期間を確認するSQL＞
SQL> select ADVISOR_NAME,PARAMETER_NAME,PARAMETER_VALUE
from DBA_ADVISOR_DEF_PARAMETERS
where PARAMETER_NAME = 'DAYS_TO_EXPIRE';
＜ADDMに関する情報の保持期間を変更するSQL＞
SQL> connect /as sysdba
exec DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER('Default Advisor', 'DAYS_TO_EXPIRE', ＜日数＞);
※変更時より後に作成されるタスクの保持期間が変更されます。
＜統計情報の履歴情報の保持期間を確認するSQL＞
SQL> select DBMS_STATS.GET_STATS_HISTORY_RETENTION from dual;
＜統計情報の履歴情報の保持期間を変更するSQL＞
SQL> exec DBMS_STATS.ALTER_STATS_HISTORY_RETENTION (＜日数＞);
＜AWR関連情報の保持期間を確認するSQL＞
SQL> select * from DBA_HIST_WR_CONTROL;
＜AWR関連情報の保持期間を変更するSQL＞
SQL> exec DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(retention => ＜分＞);
最後にご紹介する3つ目の対策は、「SYSAUX表領域の容量推移を定期的に確認する仕組みを用意しておくこと」です。
週に一度などの頻度で同じSQLを実行し、前回結果と比較することで、異常な増加を早期に検知できます。
下記のSQLでSYSAUX表領域に割り当てられている物理的なデータファイルサイズと自動拡張の設定を確認し、現在の容量を把握できます。
＜SYSAUX表領域の使用率を確認するSQL＞
SQL>set lines 200 pages 100
col "全体容量(MB)" for 999,999,999
col "ファイル容量(MB)" for 999,999,999
col "使用容量(MB)" for 999,999,999
col "空き容量(MB)" for 999,999,999
col "使用率(%)" for 999.99
SELECT TABLESPACE_NAME 表領域
, ROUND(NVL(TOTAL_MAXBYTES / 1024 / 1024,0),1) AS "全体容量(MB)"
, ROUND(NVL(TOTAL_BYTES / 1024 / 1024,0),1) AS "ファイル容量(MB)"
, ROUND(NVL((TOTAL_BYTES - TOTAL_FREE) / 1024 / 1024,0),1) AS "使用容量(MB)"
, ROUND(NVL(TOTAL_FREE / 1024 / 1024,0),1) AS "空き容量(MB)"
, ROUND(NVL((TOTAL_BYTES - TOTAL_FREE) / TOTAL_MAXBYTES * 100,100),2) AS "使用率(%)"
FROM
(SELECT TABLESPACE_NAME,SUM(BYTES) AS "TOTAL_BYTES",SUM(case when MAXBYTES = 0 then BYTES else MAXBYTES end) AS "TOTAL_MAXBYTES" FROM DBA_DATA_FILES GROUP BY TABLESPACE_NAME),
(SELECT TABLESPACE_NAME AS "FS_TS_NAME",SUM(BYTES) AS "TOTAL_FREE" FROM DBA_FREE_SPACE GROUP BY TABLESPACE_NAME)
WHERE TABLESPACE_NAME = FS_TS_NAME(+)
and TABLESPACE_NAME like 'SYSAUX' ORDER BY TABLESPACE_NAME;
本記事では、Oracle DatabaseのSYSAUX表領域の肥大化に関する問題と、その原因特定・対処・予防までの流れを解説しました。
SYSAUX表領域の肥大化は、当社サポートセンターにもよくお問い合わせいただくテーマの1つです。肥大化の原因を理解し、適切な運用方法を実施すれば、この問題を事前に防ぐことができます。
本記事以外にも、Oracle Database管理者がよく遭遇するトラブルとその解決策を紹介した記事を多数公開しています。ぜひ併せて日々の運用にお役立ていただければ幸いです。
|
|
梁 文懿
|
■本記事の内容について
本記事に記載されている製品およびサービス、定義及び条件は、特段の記載のない限り本記事執筆時点のものであり、予告なく変更になる可能性があります。あらかじめご了承ください。
■商標に関して
・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。
ランサムウェアの脅威からデータベースを守る！OCIのフルマネージドバックアップサービスZRCVは、3-2-1-1-0ルールに対応し、データ損失ゼロに近い復旧を実現します。本記事では堅牢な保護機能と、GUIで完結するわずか5ステップのシンプルな設定方法を解説します。
本記事では、お客様の自己解決率向上のために注力したFAQ作成、および、そのFAQ作成をエンジニア育成に活用した当社ならではの取り組みをご紹介します。
今年もオラクル社の年次イベント「Oracle AI World 2025」が開催され、アシストからも11名の社員がラスベガス現地で参加しました。 本記事では「Oracle AI World 2025 視察記」として「Oracle AI World 2025のハイライト」と「アシストの注目ポイント」を、Oracle AI World 2025全体の雰囲気とともにお伝えします。
![[260220T]なぜPostgreSQLではなくEDBが選ばれるのか？](/db_blog/__icsFiles/afieldfile/2026/01/23/EDB_bannar-260220_176x215px_1.png)
