
- Oracle Database
- Oracle Cloud
【2025年10月開催!】アシストテクニカルフォーラム 2025 オラクル系セッションのご案内
2025年10月に開催される当社最大のテクニカル情報満載のイベント「アシストテクニカルフォーラム 2025」におけるオラクル系セッションをまとめてご紹介します。Oracle Database 23aiやOCIの最新情報が満載です。
|
Oracle Databaseを運用する際、可能な限りシステム停止時間を短くしてパッチ適用するにはどのようなアップデート方式を採用すべきかお悩みになるお客様もいらっしゃるかと思います。
23aiでは新たに「ローカル・ローリング・データベース・メンテナンス」機能が実装されました。
これにより、各ノードのDBインスタンスごとにローリングアップデート(アウトオブプレース)を実行でき、システム停止時間を大幅に短縮可能です。
RACまたはRAC One Node環境において、アップデート実行ノードでも処理を継続できるため、システム停止時間を短縮できるこのような機能を待ち望んでいた方も多いのではないでしょうか。
そこで本記事では、ExaDB-D(Oracle Exadata Database Service on Dedicated Infrastructure)上のOracle DatabaseDB 23aiで実施した「ローカル・ローリング・データベース・メンテナンス」検証結果をお伝えします。
なお、Oracle Database 23aiバージョンアップ時に押さえておくべき非推奨と廃止機能は、「Oracle Database 23aiが遂にリリース!バージョンアップで押さえておくべき非推奨と廃止機能とは」をご覧ください。
Index
Oracle DatabaseDB 23aiで新たに提供されたローカル・ローリング・データベース・メンテナンスの概要とメリット、留意事項は以下のとおりです。
[概要]
本機能は、RACおよびRAC One Node環境で利用可能です。
各ノード上で、現行のDB HOMEとは別に新しいパッチ適用済みのDB HOMEを
事前に用意し、インスタンス単位でデータベースを順次移行(ローリング
方式のアウトオブプレース適用)が行えます。
[メリット]
各ノードのDBインスタンスごとに処理を実行できるため、同一ノード上の
他のDBインスタンスは業務等で継続利用可能。
さらに、全ノードで稼働インスタンス数を維持したまま、最小限の停止時間で
アップデートが可能。
[留意事項]
・OCI環境の場合、ローカル・ローリング・データベース・メンテナンスを
実行してDBインスタンスが新しいDB HOME上で稼働してもDB作成時に
自動的に作成され、環境変数が記載された「$HOME/
DB HOMEは自動で更新されるわけではないため手動で修正が必要
・ローカル・ローリング・データベース・メンテナンス実行時に現行の
DBインスタンス名にアンダースコアと数字を追加した一意の名前を持った
インスタンスが生成される
・オンラインREDOログ・ファイルに新しいファイルが追加される
・新しいUNDO表領域が追加される
・ローカル・ローリング・データベース・メンテナンス実行後、DBの初期化
パラメーターTHREAD、UNDO_TABLESPACEは初期化される
今回は、下記のOracle Exadata Database Service on Dedicated Infrastructure(以下、ExaDB-D)環境で検証しました。
カテゴリ | 項目 | 値 |
Software | Exadata System Software | 25.1.2 |
Grid Infrastructure | 23.7.0.25.01 | |
Oracle Database | 【移動元DB HOME:/u02/app/oracle/product/23.0.0.0/dbhome_2】
23.5.0.24.07 【移動先DB HOME:/u02/app/oracle/product/23.0.0.0/dbhome_1】 23.7.0.25.01 |
|
DB | CDB
(DB_UNIQUE_NAME) |
sbenchc |
PDB | SBENCHP |
移行前後での構成と稼働イメージは以下図のとおりです。
図1:移行前後の構成と稼働イメージ |
本記事では、「ローカル・ローリング・データベース・メンテナンス」の下記の基本的な使用方法や実行後に変更される点にフォーカスして検証しました。
1.「ローカル・ローリング・データベース・メンテナンス」の基本的な実行方法を確認する
2.上記1実行後、下記のような変更や追加が行われていることを確認する
・移動先DB HOMEにDBが紐づけられていることを確認する
・「$HOME/
手動修正が必要であることを確認する
・オンラインREDOログ・ファイルに新しいファイルが追加されていることを確認する
・新しいUNDO表領域が追加されていることを確認する
・初期化パラメーターTHREAD、UNDO_TABLESPACEが明示指定されていないことを確認する
また、今回は以下のようなステップを踏まえて検証を実施しました。
・「ローカル・ローリング・データベース・メンテナンス」実行前の環境を確認します。
・移行元のDB HOME(23.5)上で、2ノードのインスタンスが稼働中。
・移行先DB HOMEをインストールし、新しいパッチ(23.7)を適用しておきます。
・ローカルローリング機能を有効にするために移行先DB HOME上で新しいデータベースインスタンスを作成。
・Node1のインスタンスが新DB HOME上で起動。Node2はまだ旧状態。
・Node2のインスタンスを新DB HOME上で起動。
・両ノードが新バージョンに切り替わり完了。旧インスタンスは停止。
・新DB HOMEで統一。
・UNDO、REDO、初期化パラメータも自動更新されている状態。
・$HOME/<DB_NAME>.env内のDB HOMEは手動で修正。
ここでは、まずは、「ローカル・ローリング・データベース・メンテナンス」実行前の環境を確認します。
移動元DB HOME(/u02/app/oracle/product/23.0.0.0/dbhome_2)が「23.5.0.24.07」であることを確認します。
図2:アップデート前 |
[移動元DB HOME]
実行コマンド
oracle$ opatch lspatches
実行結果
335221462;TRACKING BUG TO SHIP IAM AUTHSDK FOR CLOUD 36744688;OCW RELEASE UPDATE 23.5.0.24.07 (36744688) Gold Image 36741532;Database Release Update : 23.5.0.24.07 (36741532) Gold Image
OPatch succeeded.
移行先DB HOMEをインストールし、新しいパッチ(23.7)を適用しておきます。
移行先DB HOMEをインストールし、新しいパッチ(23.7)を適用しておきます。
移動先DB HOME(/u02/app/oracle/product/23.0.0.0/dbhome_1)が「23.7.0.25.01」であることを確認します。(赤字)
図3:移行先DB HOMEを作成
|
[移動先DB HOME]
実行コマンド
コマンド実行例 oracle$ opatch lspatches
実行結果
35221462;TRACKING BUG TO SHIP IAM AUTHSDK FOR CLOUD 37547027;PROACTIVELY COMPILE GETLONG FUNCTION TO AVOID DBMS_LOB ERROR 37369900;OCW RELEASE UPDATE 23.7.0.25.01 (37369900) Gold Image 37366180;Database Release Update : 23.7.0.25.01 (37366180) Gold Image
OPatch succeeded.
ローカル・ローリング・データベース・メンテナンス実行前の初期化パラメーターUNDO_TABLESPACEの値が下記であることを確認できます。
実行コマンド
SQL> show parameter undo_tablespace
実行結果
●CDB(sbenchc) [ノード1] NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ undo_tablespace string UNDOTBS1
[ノード2] NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ undo_tablespace string UNDOTBS2
●PDB(SBENCHP) [ノード1] NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ undo_tablespace string UNDOTBS1
[ノード2] NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ undo_tablespace string UNDO_4
ローカル・ローリング・データベース・メンテナンス実行前の初期化パラメーターTHREAD、UNDO_TABLESPACEが、SPFILEからPFILE化したファイルにて下記のとおり明示的に指定されていることを確認できます。
実行コマンド
SQL> create pfile='/tmp/db_pfile.ora' from spfile; SQL> host cat /tmp/db_pfile.ora
実行結果
●CDB(sbenchc) (略) sbenchc1.thread=1 sbenchc2.thread=2 sbenchc1.undo_tablespace='UNDOTBS1' sbenchc2.undo_tablespace='UNDOTBS2' (略)
●PDB(SBENCHP) ※PDB側では明示指定して変更していないため、出力結果はありません。
ここでは、ローカルローリング機能を有効化するために新しいOracle RACデータベースインスタンスを作成し、Oracle RACデータベースインスタンスを移動先DB HOMEで起動します。
図4:新インスタンスの作成 |
ローカルローリング機能を有効にするための新しいOracle RACデータベースインスタンスの作成がエラーなく実行できたことを確認できます。
実行コマンド
oracle$ date;srvctl modify database -db sbenchc -oraclehome /u02/app/oracle/product/23.0.0.0/dbhome_1 -localrollling;date
実行結果
Tue Apr 15 20:13:50 JST 2025 Tue Apr 15 20:13:52 JST 2025
新しいOracle RACデータベースインスタンスが停止状態で生成されたことが確認できます。(赤字)
実行コマンド
oracle$ srvctl status database -db sbenchc
実行結果
Instance sbenchc1 is running on node kkaexavm01-c3hfq1 Instance sbenchc1_3 is not running on node kkaexavm01-c3hfq1 Instance sbenchc2 is running on node kkaexavm01-c3hfq2 Instance sbenchc2_4 is not running on node kkaexavm01-c3hfq2
新旧のDB HOME、データベースインスタンスが構成情報で出力できることを確認できます。
実行コマンド
oracle$ srvctl config database -db sbenchc
実行結果
(略) Oracle home: /u02/app/oracle/product/23.0.0.0/dbhome_1 Old Oracle home: /u02/app/oracle/product/23.0.0.0/dbhome_2 (略) Database instances: sbenchc1_3,sbenchc2_4 Old database instances: sbenchc1,sbenchc2 (略)
ローカル・ローリング・データベース・メンテナンスは、全ノード一括でOracle RACデータベースインスタンスを移動先DB HOMEで起動可能ですが、ここでは、いずれかのノードでDBインスタンスを継続して稼働させる運用を想定して、各ノードのインスタンスごとに移動先DB HOMEで起動実行します。
まずは、ノード1のOracle RACデータベースインスタンスを移動先DB HOMEで起動します。
図5:Node1の切替 |
実行コマンド
oracle$ date;srvctl transfer instance -db sbenchc -node $(hostname -s);date
実行結果
Tue Apr 15 20:17:35 JST 2025 Tue Apr 15 20:19:17 JST 2025
ノード1の移動先DB HOME上で新しいデータベースインスタンスが起動したことを確認できます。(赤字)
実行コマンド
oracle$ srvctl status database -db sbenchc
実行結果
Instance sbenchc1 is running on node kkaexavm01-c3hfq1 Instance sbenchc1_3 is not running on node kkaexavm01-c3hfq1 Instance sbenchc2 is running on node kkaexavm01-c3hfq2 Instance sbenchc2_4 is not running on node kkaexavm01-c3hfq2
次にノード2のOracle RACデータベースインスタンスを移動先DB HOMEで起動します。
図6:Node2の切替 |
実行コマンド
oracle$ date;srvctl transfer instance -d sbenchc -node kkaexavm01-c3hfq2;date
実行結果
Tue Apr 15 20:22:56 JST 2025 Tue Apr 15 20:23:31 JST 2025
ノード2の移動先DB HOME上で新しいデータベースインスタンスが起動したことを確認できます。(赤字)
実行コマンド
oracle$ srvctl status database -db sbenchc
実行結果
Instance sbenchc1_3 is running on node kkaexavm01-c3hfq1
Instance sbenchc2_4 is running on node kkaexavm01-c3hfq2
データベースインスタンスの切り替えが完了したので、新しいDB HOME、データベースインスタンスのみ構成情報に出力されていることを確認します。
図7:アップデート完了 |
実行コマンド
oracle$ srvctl config database -db sbenchc
実行結果
(略) Oracle home: /u02/app/oracle/product/23.0.0.0/dbhome_1 (略) Database instances: sbenchc1_3,sbenchc2_4 (略)
ここでは、「ローカル・ローリング・データベース・メンテナンス」実行後の環境を確認します。
移動先DB HOME(/u02/app/oracle/product/23.0.0.0/dbhome_1)に検証対象DB(sbenchc)が紐づいていることを確認できます。
実行コマンド
root# /u01/app/*/grid/bin/srvctl config all
実行結果
(略) Database configuration details ==============================
Database "ora.sbenchc.db" details --------------------------------- Name ora.sbenchc.db (略) Oracle home /u02/app/oracle/product/23.0.0.0/dbhome_1 (略)
ExaDB-D上でDB作成時に自動的に生成された「$HOME/sbenchc.env」内のDB HOMEは移動元DB HOMEのままであるため、手動で修正が必要であることが確認できます。
実行コマンド
oracle$ cat $HOME/sbenchc.env
実行結果
(略) PATH=/u02/app/oracle/product/23.0.0.0/dbhome_2/bin:/u02/app/oracle/product/23.0.0.0/dbhome_2/OPatch:$PATH; export PATH (略) LD_LIBRARY_PATH=/u02/app/oracle/product/23.0.0.0/dbhome_2/lib; export LD_LIBRARY_PATH (略) OH=/u02/app/oracle/product/23.0.0.0/dbhome_2; export OH ORACLE_HOME=/u02/app/oracle/product/23.0.0.0/dbhome_2; export ORACLE_HOME TNS_ADMIN=/u02/app/oracle/product/23.0.0.0/dbhome_2/network/admin/sbenchc; export TNS_ADMIN (略)
ローカル・ローリング・データベース・メンテナンス実行後のオンラインREDOログ・ファイルの構成が、下記のとおり、Thread 3のファイルが追加されたことが確認できます。
実行コマンド
SQL > select l.thread#, f.group#, f.member, l.status, l.members, l.bytes / (1024 * 1024) file_size from v$logfile f, v$log l where f.group# = l.group# order by 1, 2, 3 ;
実行結果
THREAD# GROUP# MEMBER STATUS MEMBERS File Size(MB)
------- ------ -------------------------------------------------- --------- ------- -------------
(略)
3 9 +DATAC1/SBENCHC/ONLINELOG/group_9.312.1198527461 CURRENT 1 4,000.00
3 10 +DATAC1/SBENCHC/ONLINELOG/group_10.315.1198527463 UNUSED 1 4,000.00
3 11 +DATAC1/SBENCHC/ONLINELOG/group_11.316.1198527463 UNUSED 1 4,000.00
3 12 +DATAC1/SBENCHC/ONLINELOG/group_12.317.1198527465 UNUSED 1 4,000.00
(略)
下記のとおり、ローカル・ローリング・データベース・メンテナンス実行後のUNDO表領域が追加されていることが確認できます。(赤字)
実行コマンド
SQL > select dt.tablespace_name, ddf.file_name, dt.bigfile, ddf.bytes / (1024 * 1024) file_size, ddf.autoextensible, ddf.increment_by * block_size / 1024 increment_size_kb, ddf.increment_by * block_size / (1024 * 1024) increment_size_mb, ddf.maxbytes / (1024 * 1024) max_size, dt.segment_space_management, dt.extent_management, dt.allocation_type, dt.initial_extent / (1024 * 1024) initial_extent, dt.contents from dba_tablespaces dt, dba_data_files ddf where dt.tablespace_name = ddf.tablespace_name(+) and dt.contents <> 'TEMPORARY' union select dtf.tablespace_name, dtf.file_name, dt.bigfile, dtf.bytes / (1024 * 1024) file_size, dtf.autoextensible, dtf.increment_by * block_size / 1024 increment_size_kb, dtf.increment_by * block_size / (1024 * 1024) increment_size_mb, dtf.maxbytes / 1024 / 1024 max_size, dt.segment_space_management, dt.extent_management, dt.allocation_type, dt.initial_extent / (1024 * 1024) initial_extent, dt.contents from dba_tablespaces dt, dba_temp_files dtf where dtf.tablespace_name = dt.tablespace_name(+) order by 1, 2 ;
実行結果
●CDB(sbenchc) Tablespace File Name BIGFILE File Size(MB) AUTOEXTENSIBLE Inc Size(KB) Inc Size(MB) Max Size(MB) SEGMENT_MANAGEMENT EXTENT_MANAGEMENT ALLOCATION_TYPE Initial Extent(MB) CONTENTS ---------- ------------------------------------------------- -------- ------------- --------------- ------------ ------------ ------------ ------------------ ----------------- --------------- ------------------ -------- (略) UNDOTBS1 +DATAC1/SBENCHC/DATAFILE/undotbs1.259.1198464071 YES 2,000 YES 4,194,304 4,096 524,288 MANUAL LOCAL SYSTEM 0 UNDO UNDOTBS2 +DATAC1/SBENCHC/DATAFILE/undotbs2.275.1198464051 YES 2,000 YES 4,194,304 4,096 524,288 MANUAL LOCAL SYSTEM 0 UNDO UNDOTBS3 +DATAC1/SBENCHC/DATAFILE/undotbs3.318.1198527467 YES 2,000 YES 4,194,304 4,096 524,288 MANUAL LOCAL SYSTEM 0 UNDO (略)
●PDB(SBENCHP) (略) Tablespace File Name BIGFILE File Size(MB) AUTOEXTENSIBLE Inc Size(KB) Inc Size(MB) Max Size(MB) SEGMENT_MANAGEMENT EXTENT_MANAGEMENT ALLOCATION_TYPE Initial Extent(MB) CONTENTS ---------- ---------------------------------------------------------------------------------- -------- ------------- --------------- ------------ ------------ ------------ ------------------ ----------------- --------------- ------------------ -------- (略) UNDOTBS1 +DATAC1/SBENCHC/32C1959E1B999899E0631F8B18ACCC78/DATAFILE/undotbs1.282.1198464213 YES 600 YES 4,194,304 4,096 524,288 MANUAL LOCAL SYSTEM 0 UNDO UNDO_4 +DATAC1/SBENCHC/32C1959E1B999899E0631F8B18ACCC78/DATAFILE/undo_4.283.1198464217 YES 95 YES 4,194,304 4,096 524,288 MANUAL LOCAL SYSTEM 0 UNDO UNDO_7 +DATAC1/SBENCHC/32C1959E1B999899E0631F8B18ACCC78/DATAFILE/undo_7.319.1198527477 YES 95 YES 4,194,304 4,096 524,288 MANUAL LOCAL SYSTEM 0 UNDO (略)
ローカル・ローリング・データベース・メンテナンス実行後の初期化パラメーターUNDO_TABLESPACEの値が下記のとおり変更されていることを確認できます。(赤字)
実行コマンド
SQL> show parameter undo_tablespace
実行結果
●CDB(sbenchc) [ノード1] NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ undo_tablespace string UNDOTBS3
[ノード2] NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ undo_tablespace string UNDOTBS1
●PDB(SBENCHP) [ノード1] NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ undo_tablespace string UNDO_7
[ノード2] NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ undo_tablespace string UNDOTBS1
ローカル・ローリング・データベース・メンテナンス実行後の初期化パラメーター
THREAD、UNDO_TABLESPACEは、SPFILEからPFILE化したファイルで確認すると明示的に指定されていないことを確認できます。
実行コマンド
SQL> create pfile='/tmp/db_pfile.ora' from spfile; SQL> host cat /tmp/db_pfile.ora
実行結果
●CDB(sbenchc) ※初期化パラメーターTHREAD、UNDO_TABLESPACEは明示指定されなくなったため、
SPFILEをPFILE化したファイルに出力されません。
●PDB(SBENCHP) ※PDB側では明示指定して変更していないため、出力結果はありません。
ここまでの検証結果から、この機能がいかに少ない手順で実行できるか、お分かりいただけたかと思います。
この手軽さを支えているのが、データベース自身の自動的な振る舞いです。
ここでは、一時的に新旧DB HOMEの両方にデータベースインスタンスが存在するため、検証で確認した「利用上の注意点」として解説します。
・オンラインREDOログ・ファイル
-新しいTHREADでオンラインREDOログ・ファイルが生成される
・UNDO表領域
-新しいUNDO表領域が追加される
・DBインスタンス
-srvctl modify databaseを実行すると自動的に既存データベースインスタンス名に
アンダースコアと数字を追加した一意の名前をもったインスタンスが生成される
・初期化パラメーター「THREAD」「UNDO_TABLESPACE」
-ローカル・ローリング・データベース・メンテンス完了後、初期化パラメーター
THREAD、UNDO_TABLESPACEは初期化される
・$HOME/sbenchc.env
-ExaDB-D上でDB作成時に自動的に生成された「$HOME/sbenchc.env」内の
DB HOMEは移動元DB HOMEのままであるため、手動で修正が必要
本記事では、Oracle Database 23aiの新機能「ローカル・ローリング・データベース・メンテナンス」を検証しました。
この機能を使えば、RAC/RAC One Node環境において、非常に少ないコマンド手順で、安全なアウトオブプレース方式のローリングアップデートを実現できることを確認できました。
最大のメリットは、アップデート実行中のノードでもインスタンスを稼働させ続けられる点です。
これにより、運用中のノード数を維持したままメンテナンスが可能となり、サービス影響を最小限に抑えられます。
Oracle Database 23aiにて、ローリングアップデートを使用したシステム停止時間を短縮したいというご要件があった場合に検討可能な手段の一つになると考えます。
最新のOracle Database 23aiのリプレースをご検討のお客様、お気軽にアシストまでお問い合わせください。
■本記事の内容について
本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。
■商標に関して
・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。
2025年10月に開催される当社最大のテクニカル情報満載のイベント「アシストテクニカルフォーラム 2025」におけるオラクル系セッションをまとめてご紹介します。Oracle Database 23aiやOCIの最新情報が満載です。
BaseDBの機能で拡張できない領域を、FSSを使用して拡張する方法をご紹介します。また、/u01領域配下をFSSを使用して拡張する方法と、拡張した領域に対してOracle Data Pump(以降、Data Pump)のデータをエクスポート/インポートする方法も説明します。
仮想マシンのクラウド移行における課題のひとつ「移行後の通信経路の最適化」を実現するHCXの機能、Mobility Optimization Networking(以下、MON)に焦点を当て、その機能の概要から具体的な設定手順まで、豊富な画像とともに詳しく解説します。