|
|
2024年5月、オンプレミス環境に先行して、Oracle Cloud環境でOracle Database 23aiがリリースされました。
Oracle Databaseを構築する際、SGA、PGAのサイズをそれぞれどう指定するかの検討に時間がかかっていたお客様もいらっしゃるかと思います。
23aiからは、SGA、PGAのサイズを個々に指定せず、SGAとPGAの合計サイズを新規に追加された初期化パラメーターMEMORY_SIZEに指定することでSGAとPGAのメモリー割当てをOracle Databaseが自動調整する「統合メモリー管理」という新機能が追加され、メモリーを有効活用できるようになりました。ユーザーが時間をかけて適切なサイズを算出する工数も削減でき、システムの安定稼働にも寄与する機能として、こんな機能を待っていた方も多いのではないでしょうか。
メモリーを有効活用するこの「統合メモリー管理」機能を、Oracle Base Database Service上のOracle DatabaseDB 23aiで検証してみました。本記事ではその結果をお伝えします。
なお、Oracle Database 23aiバージョンアップ時に押さえておくべき非推奨と廃止機能は、以下の記事ををご覧ください。
Index
| カテゴリー | 項目 | 値 |
| Hardware | メモリー容量（GB） | 64 |
| Software | Grid Infrastructure | 23.5.0.24.07 |
| Oracle Database | 23.5.0.24.07 | |
| DB | CDB（DB_UNIQUE_NAME） | sbenchc_jjk_nrt |
| PDB | SBENCHP |
前述のとおり、Oracle Database 23aiではSGA、PGAのメモリー割当てを自動調整してくれる「統合メモリー管理」が新機能として追加されました。
本記事では、「統合メモリー管理」の設定方法やメモリー割当てにフォーカスして検証しました。
１．初期化パラメーターMEMORY_SIZEの設定範囲を確認する
２．初期化パラメーターSGA_TARGET､PGA_AGGREGATE_TARGETの設定を確認する
３．初期化パラメーターUSE_LARGE_PAGESとの組み合わせを確認する
４．統合メモリー管理のSGA､PGA間のメモリー調整を確認する
[参考]
Oracle Databaseデータベース・リファレンス 23ai（オラクル社のサイトに移動します）
MEMORY_SIZE
MEMORY_MAX_SIZE
ここでは初期化パラメーターMEMORY_SIZEに、下記のような比較的小さい値を指定した場合にDBが起動可能か検証しました。
| カテゴリー | パラメーター | 値 |
| DBの初期化パラメーター | MEMORY_SIZE | 5g |
| MEMORY_MAX_SIZE | 0 | |
| SGA_TARGET | 0 | |
| PGA_AGGREGATE_TARGET | 0 | |
| USE_LARGE_PAGES | ONLY | |
| カーネルパラメーターvm.nr_hugepages | vm.nr_hugepages | 16397 |
検証の結果、DBの初期化パラメーターMEMORY_SIZEを「5GB」と設定したときはDBが起動しませんでした。これは「5GB」が設定可能な値の範囲より小さいことが原因です。下記のとおり、「ORA-00093: Parameter memory_size outside valid range 6291456000 to 60190075699.」が出力されたことでそれがわかります。
| 実行コマンド |
| oracle$ srvctl start database -db sbenchc_jjk_nrt;srvctl status database -db sbenchc_jjk_nrt |
| 実行結果 |
PRCR-1079 : Failed to start resource ora.sbenchc_jjk_nrt.db |
次に、上記「MEMORY_SIZE=5g」を実行したときに出力された有効な値の範囲の「MEMORY_SIZE=6000m」に設定して、検証を実施しました。
| カテゴリー | パラメーター | 値 |
| DBの初期化パラメーター | MEMORY_SIZE | 6000m |
| MEMORY_MAX_SIZE | 0 | |
| SGA_TARGET | 0 | |
| PGA_AGGREGATE_TARGET | 0 | |
| USE_LARGE_PAGES | ONLY | |
| カーネルパラメーター | vm.nr_hugepages | 16397 |
DBの初期化パラメーターMEMORY_SIZEを「6000m」とすると、設定可能な範囲の値のため、下記のとおりDBを起動できました。
| 実行コマンド |
| oracle$ srvctl start database -db sbenchc_jjk_nrt;srvctl status database -db sbenchc_jjk_nrt |
| 実行結果 |
Instance sbenchc is running on node <ホスト名> |
統合メモリー管理機能を有効にしたとき、SGA、PGAにどのような割合でメモリーが割り当てられるかなどを確認してみようと思います。
ここでは下記の設定で検証を実施しました。
| カテゴリー | パラメーター | 値 |
| DBの初期化パラメーター | MEMORY_SIZE | 6000m |
| MEMORY_MAX_SIZE | 0 | |
| SGA_TARGET | 0 | |
| PGA_AGGREGATE_TARGET | 0 | |
| USE_LARGE_PAGES | ONLY | |
| カーネルパラメーター | vm.nr_hugepages | 16397 |
DBの初期化パラメーターMEMORY_SIZEを「6000m」に設定してDBを起動した後、アラートログを確認しました。
| アラートログ(/u01/app/oracle/diag/rdbms/sbenchc_jjk_nrt/sbenchc/trace/alert_sbenchc.log)の確認結果(抜粋) |
2024-08-31T21:53:29.414037+09:00 WARNING: Since memory_size is set, memory_target is ignored ★1 WARNING: Since memory_size is set, memory_max_target is ignored ★1 WARNING: Since memory_size is set, sga_target set by user is ignored ★1 (略) |
上記「★1」の箇所では、初期化パラメーターMEMORY_SIZEを設定した場合、「MEMORY_TARGET」「MEMORY_MAX_TARGET」は無視され、ユーザーが設定した「SGA_TARGET」の値は無視されるとの警告メッセージが出力されました。
（検証時には「MEMORY_TARGET」「MEMORY_MAX_TARGET」ともに明示指定せずデフォルト値（0）のまま検証を実施しました）
| アラートログ(/u01/app/oracle/diag/rdbms/sbenchc_jjk_nrt/sbenchc/trace/alert_sbenchc.log)の確認結果(抜粋) |
(略) Starting ORACLE instance (normal) (OS id: 59291) (略) memory_size = 6000M sga_target = 4800M ★2 (略) pga_aggregate_target = 0 (略) |
上記「★2」の箇所では、統合メモリー管理により初期化パラメーターSGA_TARGETの値として、MEMORY_SIZEに設定した値（6000M）の80%のメモリーサイズの「4800M」が自動的に割当てられていることを確認しました。
| アラートログ(/u01/app/oracle/diag/rdbms/sbenchc_jjk_nrt/sbenchc/trace/alert_sbenchc.log)の確認結果(抜粋) |
(略)
2024-08-31T21:53:35.418435+09:00
Enabling UNIFIED MEMORY for PDB 3
Setting Unified PGA Pool max size 1200MB for PDB 3 ★3
Completed: Pluggable database SBENCHP opened read write
2024-08-31T21:53:35.557513+09:00
(略)
Completed: ALTER DATABASE OPEN /* db agent *//* {0:0:0} */
|
上記「★3」の箇所では、統合メモリー管理がPDBにも有効になり、統合PGA Poolの最大サイズとして1200MBが設定された後、PDBが起動しました。
MEMORY_SIZEに設定した値（6000M）の20%のメモリーが割り当てられました。
これまではHugePagesを設定している状態で自動メモリー管理を利用することはできませんでしたが、統合メモリー管理では利用できるようになりました。
ここでは、HugePagesを設定した場合でも正常に統合メモリー管理が利用できるかを確認しました。
初期化パラメーターUSE_LARGE_PAGEに「AUTO_ONLY」を設定し、OSのカーネルパラメーターvm.nr_hugepagesに設定したページ数を超えるMEMORY_SIZEをDBのパラメーターに設定した場合に、足りないページ数を自動確保してDBが起動可能か、下記の設定で検証を実施しました。
| カテゴリー | パラメーター | 値 |
| DBの初期化パラメーター | MEMORY_SIZE | 35g |
| MEMORY_MAX_SIZE | 0 | |
| SGA_TARGET | 0 | |
| PGA_AGGREGATE_TARGET | 0 | |
| USE_LARGE_PAGES | AUTO_ONLY | |
| カーネルパラメーター | vm.nr_hugepages | 5120 |
カーネルパラメーターvm.nr_hugepagesのページ数を超える値を初期化パラメーターMEMORY_SIZEに設定してDBを起動しようとしたところ、 初期化パラメーターUSE_LARGE_PAGES='AUTO_ONLY'を設定していたにも関わらず、Oracle Base Database ServiceではORA-27109エラー等が出力され起動できませんでした。
これにより、Oracle Base Database Serviceでは初期化パラメーターUSE_LARGE_PAGESは「ONLY」を設定して起動する必要があることが分かりました。
| 実行コマンド |
| oracle$ srvctl start database -db sbenchc_jjk_nrt;srvctl status database -db sbenchc_jjk_nrt |
| 実行結果 |
PRCR-1079 : Failed to start resource ora.sbenchc_jjk_nrt.db CRS-5017: The resource action "ora.sbenchc_jjk_nrt.db start" encountered the following error: ORA-27109: Setting of values for parameters related to SGA creation is not compatible. Help: https://docs.oracle.com/error-help/db/ora-27109/ . For details refer to "(:CLSN00107:)" in "/u01/app/grid/diag/crs/<ホスト名>/crs/trace/crsd_oraagent_oracle.trc". CRS-2674: Start of 'ora.sbenchc_jjk_nrt.db' on '<ホスト名>' failed CRS-2632: There are no more servers to try to place resource 'ora.sbenchc_jjk_nrt.db' on that would satisfy its placement policy Instance sbenchc is not running on node <ホスト名> |
ここではSGA、PGA間のメモリー調整を確認するため、下記の設定でOLTPワークロードテストを実施しました。
| カテゴリー | パラメーター | 値 |
| DBの初期化パラメーター | MEMORY_SIZE | 6000m |
| MEMORY_MAX_SIZE | 0 | |
| SGA_TARGET | 0 | |
| PGA_AGGREGATE_TARGET | 0 | |
| USE_LARGE_PAGES | ONLY | |
| カーネルパラメーター | vm.nr_hugepages | 16397 |
| 使用するSwingbenchのシナリオ | - | SOE（Simple Order Entry） |
| Swingbenchの実行時間 | - | 1時間 |
| Swingbenchの同時接続ユーザー数 | - | 500 |
この検証を実施する前に、実行中の各メモリー使用量を確認したところ、500同時ユーザー接続のため、実施前に比べて「total PGA allocated」のメモリー使用量が増加しています。
一方、テスト実施前に比べて「SGA：Shared Pool メモリー使用量」が「32MB」減っています。
SGA内の各使用量のうち「SGA：Buffer Cache」のメモリー使用量が「32MB」減っており、統合メモリー管理機能によるメモリー調整の結果、SGAが使用していた「32MB」がPGAに割当てられたと考えられます。
| OLTPワークロードテスト実行前、実行中(3:59:07の結果を抜粋)の各メモリー使用量 |
### OLTPワークロードテスト実行前
NO NAME SUM_BYTES NOW
---------- --------------------------------------------------------------------------- ---------- -------------------
0 PGA(CDB)：total PGA allocated 1108039680
0 PGA(PDB)：total PGA allocated 385024
0 SGAメモリー使用量 TOTAL 5009277824 2024/9/1 3:54:10
1 SGA：Shared Pool メモリー使用量 889192448
2 SGA：Buffer Cache メモリー使用量 3858759680
3 SGA：Large Poolメモリー使用量 83886080
4 SGA：Java Poolメモリー使用量 0
5 SGA：その他メモリー使用量 177439616
6 PGA(CDB)：cache hit percentage 0
6 PGA(PDB)：cache hit percentage 0
7 PGA(CDB)：maximum PGA allocated 3863746560
7 PGA(PDB)：maximum PGA allocated 2730214400
8 PGA(CDB)：total freeable PGA memory 0
8 PGA(PDB)：total freeable PGA memory 0
14 rows selected.
### OLTPワークロードテスト実行中(3:59:07の結果を抜粋)
NO NAME SUM_BYTES NOW
---------- --------------------------------------------------------------------------- ---------- -------------------
0 PGA(CDB)：total PGA allocated 3606819840
0 PGA(PDB)：total PGA allocated 2299363328
0 SGAメモリー使用量 TOTAL 4975723392 2024/9/1 3:59:07
1 SGA：Shared Pool メモリー使用量 889192448
2 SGA：Buffer Cache メモリー使用量 3825205248
3 SGA：Large Poolメモリー使用量 83886080
4 SGA：Java Poolメモリー使用量 0
5 SGA：その他メモリー使用量 177439616
6 PGA(CDB)：cache hit percentage 0
6 PGA(PDB)：cache hit percentage 0
7 PGA(CDB)：maximum PGA allocated 3863746560
7 PGA(PDB)：maximum PGA allocated 3202874368
8 PGA(CDB)：total freeable PGA memory 0
8 PGA(PDB)：total freeable PGA memory 0
14 rows selected.
|
Swingbenchの実行後、v$memory_dynamic_componentsディクショナリービューを確認しました。
unified pga poolが「MIN_SIZE」が「0」、「MAX_SIZE」が「33554432」となっており変動があります。
また、DEFAULT buffer cacheが「CURRENT_SIZE」は「3724541952」、「MIN_SIZE」が少し減って「3623878656」となっています。これは、統合メモリー管理がDEFAULT buffer cacheに割り当てられたメモリーの一部をunified pga poolに割り当てた結果であり、SGAとPGA間でメモリー調整されたといえます。
| Swingbenchの実行後のv$memory_dynamic_componentsの確認結果 |
COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPECIFIED_SIZE OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER_TIME GRANULE CON_ID --------------------------- ------------ ---------- ---------- ------------------- ---------- ------------- --------- ------------------ -------- ------ shared pool 889192448 889192448 973078528 0 3 SHRINK DEFERRED 2024/8/31 22:13:52 16777216 0 large pool 83886080 83886080 83886080 0 0 STATIC 16777216 0 java pool 0 0 0 0 0 STATIC 16777216 0 streams pool 33554432 33554432 33554432 0 385 SHRINK DEFERRED 2024/9/1 3:45:28 16777216 0 unified pga pool 0 0 33554432 0 219 SHRINK DEFERRED 2024/9/1 3:44:28 16777216 0 memoptimize buffer cache 0 0 0 0 0 STATIC 16777216 0 DEFAULT buffer cache 3724541952 3623878656 3724541952 0 607 GROW DEFERRED 2024/9/1 3:45:28 16777216 0 KEEP buffer cache 0 0 0 0 0 STATIC 16777216 0 RECYCLE buffer cache 0 0 0 0 0 STATIC 16777216 0 DEFAULT 2K buffer cache 0 0 0 0 0 STATIC 16777216 0 DEFAULT 4K buffer cache 0 0 0 0 0 STATIC 16777216 0 DEFAULT 8K buffer cache 0 0 0 0 0 STATIC 16777216 0 DEFAULT 16K buffer cache 0 0 0 0 0 STATIC 16777216 0 DEFAULT 32K buffer cache 0 0 0 0 0 STATIC 16777216 0 Shared IO Pool 134217728 134217728 134217728 134217728 0 STATIC 16777216 0 Data Transfer Cache 0 0 0 0 0 STATIC 16777216 0 In-Memory Area 0 0 0 0 0 STATIC 16777216 0 In Memory RW Extension Area 0 0 0 0 0 STATIC 16777216 0 In Memory RO Extension Area 0 0 0 0 0 STATIC 16777216 0 PGA Target 0 0 0 0 0 STATIC 16777216 0 ASM Buffer Cache 0 0 0 0 0 STATIC 16777216 0 21 rows selected. |
Oracle Database 23aiから追加された新機能「統合メモリー管理」の検証結果は以上のとおりです。初期化パラメーター「MEMORY_SIZE」に有効な値を設定することで「統合メモリー管理」機能を活用できることを確認しました。
また、アラートログやディクショナリービューからも負荷状況に応じてSGA、PGA間のメモリー調整を自動的に行っていることも確認できました。
今回の検証でOracle Database 23aiの新機能である「統合メモリー管理」がメモリーリソースを有効活用できる一つの手段であることが確認できました。
SGA、PGAのチューニングについては、Oracle Databaseに任せることができるようになり、ユーザー側の管理の手間を低減できることがわかりました。
もし、リソースが足りない場合は、スケールアップで対応できるようなクラウド環境では積極的に利用を検討しても良いかもしれません。
最新のOracle Database 23aiのリプレースをご検討のお客様、お気軽にアシストまでお問い合わせください。
|
|---|
■本記事の内容について
本記事に記載されている製品およびサービス、定義及び条件は、特段の記載のない限り本記事執筆時点のものであり、予告なく変更になる可能性があります。あらかじめご了承ください。
■商標に関して
・Oracle®、Java及びMySQLは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。
本記事では、従来のON COMMIT MViewが抱えてきたこのようなスループット低下や待機イベントのボトルネックを振り返りつつ、Oracle AI Database 26aiが提供する「同時リフレッシュ（Concurrent Refresh）」によって、OLTP／DWHそれぞれのユースケースでどのような改善が見込めるのかを検証していきます。
BaseDBの運用でData Pump用の領域が不足した際、外部ストレージの活用が有効です。本記事では3つのストレージについて1TB利用時のコスト目安や性能、運用負荷を徹底比較します。自社環境に最適な外部ストレージ選びのポイントが分かります。
Oracle Trace File Analyzer（TFA）は、障害時のログ収集を効率化するツールです。複数ログの一括取得や時間指定、シングル環境での導入手順まで、現場目線でわかりやすく解説します。
![[260424T]脱・PostgreSQL運用の不安！EDBのPEM管理術：GUIでの障害特定から監視まで](/db_blog/__icsFiles/afieldfile/2026/03/23/EDB_mail-bannar-260424a_176x250px.png)
