Oracle DB構築（2ノードRAC）
DB構成概要
物理構成
ASMディスク・グループ
ASMディスク・グループはDG01、DG02、GD11、DG21の4グループです。このうちDG01はRAC用なので残りのDG02、GD11、DG21にDBの構成ファイル及びアーカイブログを格納します。
【ASMディスク・グループ一覧】
| ディスク・グループ | 用途 | ASMディスク（仮想ディスク） | 冗長性 | 合計サイズ(G) |
| DG01 | 投票ディスク＆OCR格納用 | storage/prsdb26/disk001.vmdk（3 GB） storage/prsdb26/disk002.vmdk（3 GB） storage/prsdb26/disk003.vmdk（3 GB） | 標準 | 9 |
| DG02 | アーカイブログ格納用 | storage/prsdb26/disk011.vmdk（10 GB） storage/prsdb26/disk012.vmdk（10 GB） | 外部 | 20 |
| DG11 | REDOログ、一時ファイル格納用 | storage/prsdb26/disk101.vmdk（10 GB） storage/prsdb26/disk102.vmdk（10 GB） | 外部 | 20 |
| DG21 | データファイル格納用 | storage/prsdb26/disk201.vmdk（30 GB） storage/prsdb26/disk202.vmdk（30 GB） | 外部 | 60 |
制御ファイル、初期化パラメータファイル、パスワードファイル
制御ファイル、初期化パラメータファイル、パスワードファイルは DG11に格納します。
【制御ファイル、初期化パラメータファイル、パスワードファイル】
| ファイル | パス（エイリアス） |
| 制御ファイル1 | +DG11/PRDB/ctl/control01.ctl |
| 制御ファイル2 | +DG11/PRDB/ctl/control02.ctl |
| SPファイル | +DG11/PRDB/PARAMETERFILE/spfile.xxx.xxxxxxxxxx* |
| パスワード・ファイル | +DG11/PRDB/PASSWORD/pwdprdb..xxx.xxxxxxxxxx* |
*xxx（ファイル番号）、xxxxxxxxxx（インカネーション）
ストレージの機能を使用した高速ボリューム・バックアップはデータ・ファイルを格納するDG21のみが対象です。DB障害の復旧でデータ・ファイルをリストアしてもDG11に格納した制御ファイル、初期化パラメータファイル、パスワードファイルがバックアップ時点の状態に戻ることはない反面、ストレージ全損のケースではボリューム・バックアップから戻すことはできないので構成変更の都度、手動でバックアップを取得します。
REDOログ、一時ファイル
DBの完全回復には最新状態のREDOログのみ使用します。一時ファイル内のデータはそもそもDBの回復に使いません。なのでこの2つをDBバックアップに含めても何のメリットもないどころか無駄に容量を食うだけです。
また、この2つは一日当たりに書き込まれるデータ量が多いのでDBバックアップに含めてしまうとボリューム・バックアップで別のストレージに差分データだけ転送している場合、転送データ量もバックアップの所要時間も増加してしまいます。なのでREDOログ、一時ファイルはデータ・ファイルと分離してDG11に格納*します。
【REDOログ】
| ノード | インスタンス | スレッド | グループ | スレッド | メンバ | サイズ(M) |
| prsdb01 （DBサーバ#1） | prdb1 | 1 | 11、12、13 | 1 | +DG11/PRDB/log/redo<グループ>_1.log +DG11/PRDB/log/redo<グループ>_2.log | 各256 |
| prsdb02 （DBサーバ#2） | prdb2 | 2 | 21、22、23 | 2 | +DG11/PRDB/log/redo<グループ>_1.log +DG11/PRDB/log/redo<グループ>_2.log | 各256 |
| prsdb03 （DBサーバ#3） | prdb3 | 3 | 31、32、33 | 3 | +DG11/PRDB/log/redo<グループ>_1.log +DG11/PRDB/log/redo<グループ>_2.log | 各256 |
【一時ファイル】
| コンテナ | 表領域 | 一時ファイル | 初期サイズ(MB) | 自動拡張 | 増分（MB） | 上限サイズ(M) |
| CDB | TEMP | +DG11/PRDB/tmp/temp01.dbf | 2048 | ON | 16 | UNLIMITED |
| PRPDB | TEMP | +DG11/PRDB/prpdb/temp01.dbf | 2048 | ON | 16 | UNLIMITED |
*PDBシードの一時ファイルサイズは非常に小さいので他のシード関連ファイルとまとめてDG21に格納します。
データファイル、PDB Seed
CDBであれPDBであれデータファイルはすべてDG21に格納します。また、PDBシードは一時ファイルを含めてオールイン・ワンでDG21に格納します。
【データファイル、PDB Seed】
| コンテナ | 表領域 | 表領域 タイプ | データファイル | 初期サイズ(M) | 自動拡張 | 増分（M） | 上限サイズ(M) |
| CDB | SYSTEM | SMALLFILE | +DG21/PRDB/dbf/system01.dbf | 1024 | ON | 16 | UNLIMITED |
| CDB | SYSAUX | SMALLFILE | +DG21/PRDB/dbf/sysaux01.dbf | 2048 | ON | 16 | UNLIMITED |
| CDB | UNDOTBS1（prdb1） UNDOTBS2（prdb2） | SMALLFILE | +DG21/PRDB/rbs/undotbs01.dbf +DG21/PRDB/rbs/undotbs02.dbf | 1024 1024 | ON | 16 | UNLIMITED |
| CDB | TEMP | SMALLFILE | +DG11/PRDB/tmp/temp01.dbf | 2048 | ON | 16 | UNLIMITED |
| CDB | USERS | SMALLFILE | +DG21/PRDB/dbf/users01.dbf | 16 | ON | 4 | UNLIMITED |
| SEED | SYSTEM | SMALLFILE | +DG21/PRDDB/pdbseed/system01.dbf | 210 | ON | 16 | UNLIMITED |
| SEED | SYSAUX | SMALLFILE | +DG21/PRDDB/pdbseed/sysaux01.dbf | 165 | ON | 16 | UNLIMITED |
| SEED | UNDOTBS1 | SMALLFILE | +DG21/PRDDB/pdbseed/undotbs01.dbf | 60 | ON | 16 | UNLIMITED |
| SEED | TEMP | SMALLFILE | +DG21/PRDDB/pdbseed/temp01.dbf | 20 | ON | 16 | UNLIMITED |
| PDB | SYSTEM | SMALLFILE | +DG21/PRDB/prpdb/system01.dbf | 1024 | ON | 16 | UNLIMITED |
| PDB | SYSAUX | SMALLFILE | +DG21/PRDB/prpdb/sysaux01.dbf | 2048 | ON | 16 | UNLIMITED |
| PDB | UNDOTBS1（prdb1） UNDOTBS2（prdb2） | SMALLFILE | +DG21/PRDB/prpdb/undotbs01.dbf +DG21/PRDB/prpdb/undotbs02.dbf | 1024 1024 | ON | 16 | UNLIMITED |
| PDB | TEMP | SMALLFILE | +DG11/PRDB/prpdb/temp01.dbf | 2048 | ON | 16 | UNLIMITED |
| PDB | USERS | SMALLFILE | +DG21/PRDB/prpdb/users01.dbf | 16 | ON | 4 | UNLIMITED |
| PDB | USERTBL01 | SMALLFILE | +DG21/PRDB/prpdb/usertbl01.dbf | 10240 | ON | 16 | UNLIMITED |
| PDB | USERIDX01 | SMALLFILE | +DG21/PRDB/prpdb/useridx01.dbf | 5120 | ON | 16 | UNLIMITED |
【表領域、一時表領域の上限サイズについて】
こちらのシステムはアプリの要件なんぞ無いので表領域、一時表領域（のデータファイル）にサイズの上限は設けていませんが、まじめに設計するならきちんと各表領域のデータ量を見積もって上限サイズを設定するべきだと思います。
表領域のサイズに上限を設けていれば領域不足が発生したとしてもいきなりASMディスクの拡張（ストレージ作業が必要でハードル高し）とはならず、まずはデータ・ファイルの拡張で対応が可能です。DBの管理者とストレージは管理者が別なんてことはよくありますから、ASMディスク・グループがパンクして真夜中にストレージ管理者に拡張をお願いするよりも（DB側でちゃんと領域管理していないのかと普通はブチ切れでございます）、表領域の空き容量不足にはまずはDB側で対応してそれでディスク・グループ全体の空き領域領域不足が懸念されるようでしたら計画的にASMディスクを拡張（または追加）したほうがナンボかマシだというのが私の個人的な考えでございます。
また、何らかのトラブルで万一、表領域内のセグメントが爆発的に増加（ありがちなのがTEMP表領域の一時セグメント）しても表領域のサイズに制限がかかっていれば、その表領域がパンクするだけでディスク・グループ全体（場合によってはDB全体）の影響を回避できます。なのでやはり表領域（のデータ・ファイル）サイズの上限は設定しておいた方がよろしいかと。ま、このシステムはあまりまじめじゃないんで表領域のサイズ上限は無制限ですが。
メモリ設定
Oracle 23aiからDBのメモリ管理機能に統合メモリ管理なるものが実装されたようでございます。Oracle 26aiのデータベース概要に載っている統合メモリ管理の説明を読むと従来の自動メモリ管理の強化版っぽい印象です。
Geminiさんによると実際その通りらしく、自動メモリ管理ではHugePagesを使用できなかったのが統合メモリー管理ではHugePagesも可能というのが大きな変更点だとか。まあ、こちらのシステム（現行のOracle 21c DB）では自動共有メモリ管理を選択しておりまして新DB（Oracle 26ai）もこれを継承するので折角の新機能ですが統合メモリ管理は使いません。
で、新DBでその自動共有メモリ管理に設定するパラメータについてです。現行DBではこのようにSGA及びPGA、processesを設定しています。
【現行DB（21c）メモリ関連初期化パラメータ】
| パラメータ | 値 |
| sga_target | 3584M（3.5GB） |
| pga_aggregate_target | 1024M（1.0GB） |
| processes | 1000 |
現行DBの構築ではサイジングの元ネタとなる情報がOSとGrid Infrastructure（CRS）のメモリ消費量しかありませんでした。で、サーバの実メモリからその2つを引いた残りのメモリ・サイズ（利用可能メモリ・サイズ）を見てSGAやPGAのサイズをざっくり決めてしまったわけですが、今回はOSとGrid Infrastructure（CRS）のメモリ使用量については新DB、DBバック・グラウンド・プロセスとセッションごとに生成される専用サーバ・プロセス（PGAを除く初期生成サイズ）は現行DBのメモリ使用量をそれぞれ参考できるのでもう少し真面目にサイジングをしたいと思います。
以下は新DBのOS、Grid Infrastructure、現行DBのバック・グラウンド・プロセス、クライアント・セッションの専用サーバ・プロセスがそれぞれ起動時に消費するメモリの実測値です。
【OS及びOracle関連プロセス メモリ消費量（KiB）実測値】
| プロセス | 測定対象サーバ（プロダクト） | DBサーバ#1 | DBサーバ#2 | 補足 |
| OS | 新DBサーバ（RHEL9） | 1,081,516 | 1,161,508 | 現行DBサーバ（RHEL8）のOSメモリ使用量は約870MiB |
| Grid Infrastructure | 新DBサーバ（Oracle 26ai） | 2,941,712 | 2,861,880 | 現行DBのGrid Infrastructureメモリ使用量は約2.47GiB（DBサーバ#1） |
| バック・グラウンド・プロセス | 現行DBサーバ（Oracle 21c） | 1,409,992 | 1,416,764 | 現行DBサーバ#1：111プロセス、現行DBサーバ#2：102プロセス |
| 専用サーバ・プロセス（各ノード接続数約300） | 現行DBサーバ（Oracle 21c） | 2,437,172 | 2,487,760 | APサーバ（WebLogic）からDBへのセッション生成前後のタイミングで取得したメモリ消費量の差分。 DBサーバ#1：296本、DBサーバ#2：304本。1セッションあたりの専用サーバ・プロセス生成に伴うメモリ消費量*はどちらのノードも8MiB。 |
新DBサーバのOSが認識しているメモリ・サイズ（freeコマンドのtotal）は11,982,000MiB（11.5GiB弱）でOSによって消費されるメモリは1GiB、Grid Infrastructureの消費メモリは3GiB、現行DBのバック・グラウンド・プロセスによるメモリ消費量は1.4MiB弱*1となっています。
現行DBの専用サーバ・プロセスのメモリ消費量*2は300セッション（専用サーバ・プロセス300個）で約2400MiB、1セッション（1専用サーバ・プロセス）あたりだと8MiB。
もっともこれらの数字はいずれもプロセス起動前後でメモリ使用量の差分から算出した値、つまりプロセス起動直後のメモリ消費量でしかありません。実際にプロセスが稼働しているとヒープの使用やページ・テーブルの肥大によってメモリ消費量は増加します。また、DBのバックグラウンド・プロセスや専用サーバ・プロセスの実測値はOracle 21cのデータですからOracle 26aiではより大きくなっていることもありえます。
なので見積メモリ消費量には実測値にある程度を持たせた値を設定するわけですが、じゃあ具体的にどれぐらい余裕を持たせりゃいいかというのをGeminiさんといろいろ検討して出てきた結論が実測値の20%（専用サーバプロセスだけは実測値の25%、プロセス当たりの見積メモリ消費はキリよく10MiB）。もちろんこのパーセンテージは余裕率として最低ギリギリのラインですが仮想基盤プラットフォームのEXSiサーバが実装しているメモリは限られているので贅沢は言えません。
で、各機能が使用するメモリ・サイズの実測値にこの余裕率を掛けて算出した見積メモリ消費量をDBサーバの実メモリから引くとどうなるか。
新DBメモリ割り当て見積
a.サーバ認識実メモリ 11.5 GiB
-----------------------------------------------
b.OS 1.3 GiB 実測値*1.2
c.Grid Infrastructure 3.4 GiB 実測値*1.2
d.DBバックグラウンド・プロセス 1.6 GiB 実測値*1.2
e.専用サーバ・プロセス 3.9 GiB ※ノード障害発生時の最大接続数400本で計算*4
-----------------------------------------------
f.あまり 1.3 GiB
ん？
1.3 GiBしか残らんやん……
これじゃSGA、PGAを現行DBと同じサイズで新DBに割り当てるどころか、まともにDBを動かすだけのメモリを割り当てることすらできない、というか、現行DBにこも見積メモリ消費量を割り当てたとしても実メモリが全然足りてません。
この見積で何が一番メモリを食っているかといえば専用サーバ・プロセス、言い換えるとDBセッションによって消費するメモリですが、どうやらセッション数が多すぎてキャパ・オーバーしてしまっている模様です。
実は元々、現行DBの構築時は想定セッション数が現在よりぜんぜん少ない本数だったんですけどAPサーバの構築でデータソースの構成検討や障害回復検証でセッション数をぽこぽこ増やしてしまい現在の本数になっているんですよね。その際DB側のリソースのことなどすっぽり頭から抜け落ちておりましてまったくお恥ずかしい次第でございます。
ま、現在のセッション数はアプリ（システム）要件に基づいて決めたわけではなくかかる次第で適当に設定したものですからここは新DB側のリソースに合わせてざっくり削ってしまうことにします。
現在のセッション数はノード当たり最大400本なので、これを思い切って1/5（80本）まで削るとどうなるか？
新DBメモリ割り当て見積
a.サーバ認識実メモリ 11.5 GiB
-----------------------------------------------
b.OS 1.3 GiB 実測値*1.2
c.Grid Infrastructure 3.4 GiB 実測値*1.2
d.DBバックグラウンド・プロセス 1.6 GiB 実測値*1.2
e.専用サーバ・プロセス 0.8 GiB ※ノード障害発生時の最大接続数400本で計算
-----------------------------------------------
f.あまり 4.4 GiB
むーん、新DBに現行DBと同じサイズのSGA、PGA（合計4.5MiB）を割り当てた場合、セッション数をノード当たり最大80本まで減らしても計算上、メモリがまだ少し足りません*5。しかしま、足りないといってもたったの0.1MiBですからね。ここはひとつ妥協してこのまま行ってしまおうと思います*6。
【新DB・メモリ関連パラメータ】
| 設定項目 | 設定値 | 備考 |
| SGA_TARGET | 3584MiB | 現行DBと同じ |
| PGA_AGGREGATE_TARGET*7 | 1024MiB | 現行DBと同じ |
| PROCESSES | 1000 | 現行DBと同じ。セッション数は80本に減らしますがプロセス数の制限は現状維持とします。 |
*1：現在のDBバージョンだと初期化パラメータのpre_page_sgaはデフォルトでTRUEに設定されており現行DBでもこの設定はTRUEです。pre_page_sgaがrueの場合、バック・グラウンド・プロセスは起動するときにSGAのすべてのメモリページにアクセスするのでそのページ数分のエントリがプロセスのページテーブルに書き込まれます。つまり、SGAのサイズがデカかったりHugePagesではなく通常ページを使っているとバックグラウンド・プロセスの初期消費メモリはもっと多くなります（たぶん）。
*2：このシステムのDBは専用サーバ・プロセス構成なのでクライアント（ユーザ）がDBにログインするたびにリクエストを処理するための専用サーバ・プロセスがDBサーバ上で起動します。クライアントのSQLリクエストはこのプロセスのヒープを使って処理しますがそこで割り当てられるメモリはPGAとして管理されるので一旦置いといて、ここではプロセス自体がスタックやテキスト領域、ページテーブルなんかで消費するメモリのサイズを実測しています。
＊3：専用サーバ・プロセスがSQLを処理するためにPGAを割り当てられればプロセスのメモリ消費が増加するのは当然ですが、これとは別にプロセスが新しくメモリ・ページにアクセスするたびに仮想メモリ空間アドレスと実メモリ・アドレスのマッピング情報がページテーブルに追加され、稼働を重ねるうちにプロセスのメモリ消費量が増加します。マッピング情報（エントリ）は1ページ当たり8バイトなので1GiB分のHugePages（1ページのサイズが2MiB）へのアクセスなら4KiB、同じサイズの通常ページ（1ページのサイズが4KiB）へのアクセスであれば2MiBのエントリがページテーブルに追加されます。専用サーバプロセス当たりのメモリ消費量を実測値の8MiBから2MiB増やして見積サイズを10MiBとしたのはこうした稼働に伴うメモリ消費量の増加を想定したものです。
*4：こちらの環境ではデータソースの機能比較をやりたいという理由で2台のAPサーバ（WebLogic）のうち1台のデータソースをMulti Data Sources（MDS）、もう1台のデータソースをActive GridLink（AGL）で構成しています。ノード障害が起きた場合、MDSのセッションは縮退（ダウン・ノードへのセッションを無効化）、AGLのセッションは接続フェイルオーバー（ダウン・ノードへのセッションは生存ノードに再作成）という想定です。APサーバ1台が必要とするDBへの最大セッション数は200本の想定なのでMDSの場合はどちらのノードがコケても必要なキャパを確保できるようあらかじめ200本のセッションをどちらのRACノードにも生成、一方AGLはRACノード全体で200本のセッションを生成する設定で、ノードの稼働に偏りがなければ各ノードに概ね100本のセッションを生成しています。つまり、通常時はRACノード当たりのセッション数は300本、ノード障害時は400本という次第でございます。
*5：こうやって各コンポーネントのメモリ割り当て（見積サイズ）をサーバの実メモリ・サイズに収まるように無理くり設定しても空きメモリ（余裕）はまったくありません。できればDBサーバの仮想マシンにメモリを追加したいところですが、ESXi筐体のメモリが128GiBしかないところへもってこの後OEM（Oracle Enterprise Manager）サーバの構築が控えているんですよねぇ。ぶっちゃけOEMってなくてもぜんぜん困らないくせにメモリはバカみたいに食うという厄介なシロモノです。正直言えばこんなものを構築するのは取りやめにしたいところですけど今更そういうわけにもいかないのでDBサーバへのメモリ追加の方を諦めます。
*6：当然のことながら本物のシステムでこんなふざけたサイジングをやったらふつうはプロジェクトの上役や場合によっては顧客がブチ切れます。当たり前の話ですが普通はDBサーバを用意してからそのメモリをどう割り当てるか考えるなんて馬鹿なことはせず、先にサイジングをちゃんとやって必要十分なキャパを持つDBサーバを用意します。
*7：PGA_AGGREGATE_TARGETは目標値であってこれを超えたからと言って処理に制限がかかるとかはありません。PGAサイズにきっちり制限を掛けるならPGA_AGGREGATE_LIMITも設定すべきですがメモリかつかつでやっていてサーバの空きメモリに余裕もないのに厳密な制限を掛けても仕方がないのでPGA_AGGREGATE_TARGETのみを設定しています。ちなみにPGA_AGGREGATE_LIMITのデフォルト値は「PGA_AGGREGATE_TARGETの200%」か「少なくとも2GB、および少なくとも3MB×PROCESSESパラメータ(および少なくとも5MB×Oracle RACインスタンスのPROCESSESパラメータ)の値」だそうでございます。
DBサービス
現行DB同様、新DBでもアプリケーション接続用にオンライン・アプリケーション接続用とバッチ・アプリケーション接続用の2種類のDBサービスを作成します。
| サービス名 | 用途 | 設定 |
| online_srv | オンライン・アプリケーション接続用 | PDB：prdpdb 優先インスタンス：prddb1,prddb2 フェイルバック：NO TAFポリシー：BASIC サービス管理ポリシー：AUTOMATIC 高速アプリケーション通知：TRUE 接続時ロード・バランシング目標*1：SHORT フェイルオーバー・タイプ：SESSION ランタイム・ロード・バランシングの目標＊2：SERVICE_TIME 接続リトライ回数：3 再接続試行間の時間遅延（秒）：5 |
| batch_srv | バッチ・アプリケーション接続用 | PDB：prdpdb 優先インスタンス：prddb3 使用可能インスタンス：prddb2 フェイルバック：NO TAFポリシー：BASIC 高速アプリケーション通知：TRUE フェイルオーバー・タイプ：SESSION 接続リトライ回数：3 再接続試行間の時間遅延（秒）：5 |
*1：こうした「xxx目標」の設定に意味があるのはクライアントのデータソースがロード・バランシング・アドバイザの情報を元にRACノード間の作業分担を調整している場合に限ります（たぶん）。具体的にはWebLogic側でActive GridLinkを使ってデータソースを構成してONSの接続を構成、FANイベント受信を有効化している場合です。逆に言えば汎用データソースやMulti Data Sourceを使用している環境ではまあ無意味なんじゃないかなあ、と思います。
*2：正直にゲロってしまいますと私は当初、online_srvの接続時ロード・バランシング目標をTHROUGHPUTに設定しておりました。Real Application Clusters管理およびデプロイメント・ガイドにはSERVICE_TIMEはオンライン向け、THROUGHPUTはバッチ向け的なことが書いてあるのに、いったい何を考えていたんでしょうかね。まあ一応、どちらを設定してもAGLはRACノード間で作業分散はしてくれます。ただ、THROUGHPUTだとDB側が低稼働時にRACノードの稼働バランスが少し崩れただけでノード間のセッション数に偏りが生じたりして使い勝手があまりよろしくありません。というか、これはまったく個人的な感想ですがActive GridLinkそのものが良く言えば使うシステムを選ぶ、悪く言えば大概のシステムだと金がかかる割にはメリットが感じられない、そのくせ扱いが面倒なところまであるシロモノだと思います。幸い新DBを構築したら次はWebLogicのバージョン・アップをやるつもりなので、そのタイミングでDBへのセッション数削減と一緒にデータソースはMulti Data Sourceに一本化してしまおうと思います。
少し記事が長くなったので一旦ここで切って、次は実際の2ノードRAC DB構築です。
DBサーバ構築（Oracle 26ai）・関連ページ
DBサーバ構築、Oracle 26ai（１）概要
DBサーバ構築、Oracle 26ai（２）OS、N/W、ストレージ
DBサーバ構築、Oracle 26ai（３）Gridインストール１
DBサーバ構築、Oracle 26ai（４）Gridインストール２
DBサーバ構築、Oracle 26ai（５）DBインストール
DBサーバ構築、Oracle 26ai（６）2ノードRAC構築 1 （DB設計）
DBサーバ構築、Oracle 26ai（６）2ノードRAC構築 2 （DB構築）
メニュー
トップページ
投稿一覧
自己紹介
問合せ（メール）
参考情報
大容量メモリに潜むメモリ枯渇問題その２ ～Linux HugePageの薦め～｜技術ブログ｜レック・テクノロジー・コンサルティング株式会社
コメント