はじめに
OCI（Oracle Cloud Infrastructure）の Base Database Service(以下 BaseDB) を運用していると、比較的高い確率で /u01 ファイルシステムが枯渇する問題に遭遇するかと思います。
本記事では/u01容量枯渇問題に関して以下のように整理し、紹介したいと思います。
- なぜ /u01 が枯渇するのか
- どのような運用で発生するのか
- OCI 環境での対応例
OCI BaseDB のディスク構成
BaseDB の代表的な構成は以下となります。
※以下はストレージ管理ソフトウェアとして論理ボリューム・マネージャを使用した例で、 BaseDB 作成直後の情報となります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
Filesystem Size Used Avail Use% Mounted on devtmpfs 16G 0 16G 0% /dev tmpfs 16G 0 16G 0% /dev/shm tmpfs 16G 944K 16G 1% /run tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/mapper/vg00-root 9.6G 3.7G 5.5G 40% / tmpfs 16G 132K 16G 1% /tmp /dev/mapper/vg00-opt 33G 2.9G 29G 9% /opt /dev/mapper/vg00-var 9.6G 151M 9.0G 2% /var /dev/mapper/vg00-home 958M 140K 891M 1% /home /dev/mapper/vg00-var_tmp 958M 20K 891M 1% /var/tmp /dev/mapper/vg00-var_log 3.8G 93M 3.5G 3% /var/log /dev/sda2 974M 256M 652M 29% /boot /dev/mapper/vg00-var_log_audit 1.9G 948K 1.8G 1% /var/log/audit /dev/sda1 128M 5.1M 123M 4% /boot/efi /dev/mapper/DATA_GRP-DATA 251G 24G 215G 10% /u02 /dev/mapper/RECO_GRP-RECO 251G 3.1G 236G 2% /u03 /dev/mapper/BITS_GRP-BITS 196G 14G 173G 8% /u01 tmpfs 3.2G 0 3.2G 0% /run/user/101 tmpfs 3.2G 0 3.2G 0% /run/user/1000 |
上記のうち /u02 はデータ・ファイルが格納されており、 /u03 は REDO ログなどが格納されている領域となります。
両方とも、OCI コンソールにてストレージのスケールアップを使用して拡張することが可能です。
※/u01 の標準的な構成は以下となります。
|
1 2 3 4 5 6 7 8 |
/u01 (約200GBほど) ├─ app/oracle/admin ├─ app/oracle/audit ├─ app/oracle/cfgtoollogs ├─ app/oracle/checkpoints ├─ app/oracle/diag └─ app/oracle/product/19c/dbhome_1 |
ここで重要なポイントとしては、 /u01 のサイズは BaseDB 作成時に確保され、コンピュート・インスタンスのように容量を拡張することはできない、ブロック・ボリュームをアタッチして、データ等を退避させることもできないということです。
そして、主な増加要因としては Oracle Database が出力するログ類が原因であることがほとんどとなります。
/var/tmp や /var/log 等に関しては、Linux で一般的に使用されている、 logwatch や tmpwatch を利用していただければと思いますが、本記事では /u01 にフォーカスをあてて紹介させていただきます。
/u01 が枯渇する典型パターン
ADR(diag) ログが肥大
場所: /u01/app/oracle/diag
対象: trace, alert log, incident
特に trace ファイルはデータベースの利用状況により、多数のファイル、巨大なファイルになりがちです。
cfgtoollogs の肥大
場所: /u01/app/oracle/cfgtoollogs
対象: datapatch, opatch, catctl
パッチ適用作業後に肥大するケースがあります。
audit ログ
場所: /u01/app/oracle/admin/*/adump
対象: 監査ログ
Unified Audit 有効時など多数のファイルが出力される可能性があります。
基本的な対処法
adrci を使用して削除する
|
1 2 |
$ adrci exec="set homepath diag/rdbms/＜一意のデータベース名＞/＜インスタンス名＞;purge -age 7200" |
上記例では、 7200 分（ 5 日 ）より古い set homepath で指定したホーム内の全診断データ（トレース、アラートログ等）を削除します。
運用時のスクリプト例
/home/oracle/bin/purge_adrci.sh
|
1 2 3 4 5 6 7 8 9 |
#!/bin/bash export ORACLE_SID=＜ORACLE SID＞ export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1; export PATH=$PATH:/u01/app/oracle/product/19.0.0/dbhome_1/bin; export LD_LIBRARY_PATH=/u01/app/oracle/product/19.0.0/dbhome_1/lib; adrci exec="set homepath diag/rdbms/＜一意のデータベース名＞/＜インスタンス名＞;purge -age 7200" exit $? |
crontab (root)
|
1 2 |
0 2 * * * sudo -u oracle /home/oracle/bin/purge_adrci.sh 2>&1 > /dev/null |
BaseDB では、デフォルトで /etc/cron.allow が空ファイルで存在しているため、一般ユーザーである oracle ユーザーでは cron が利用できません。
そのため、 root ユーザーの crontab に登録し、 sudo -u oracle で oracle ユーザーとしてスクリプトを実行する必要があります。
※BaseDB では、 oracle や grid などのデフォルトで作成されているユーザーに対しての変更は推奨されていないため、 /etc/cron.allow へ oracle ユーザーを追加し、 oracle ユーザーの crontab 実行も避けていただいたほうが良いかと思います。
まとめ
BaseDB はブロック・ボリュームをアタッチしたり、 /u01 を拡張することはできません。
そのためログ管理が非常に重要になってきます。
また、本記事では触れませんでしたが、ディレクトリ・オブジェクトである DATA_PUMP_DIR も /u01 を使用しますので、 Data Pump を利用してバックアップを取得する場合も注意が必要となります。
そのような場合には、ファイル・ストレージ・サービス や オブジェクト・ストレージ を利用し、 expdp の出力先をローカル・ディスクにしないようにすることで回避可能となるため、各サービスの利用を検討いただけますと幸いです。
