DBサーバ構築、Oracle 26ai（１）概要

Oracle 26ai RAC DB構築概要

Web-AP-DB連携の検証が終わったら次はEnterprise Manager Cloud Control（OEM）を構築しようと考えていたんですが思いのほか検証に手間取っているうちにOracle 26aiがリリースされてしまいました。

このままOEMとかDRサイトの構築を進めてもあとでDBはバージョンアップしなくちゃならないし二度手間となる作業も出てきてしまうので先にOracleのバージョンアップをやってしまおうと思います。

DBをバージョンアップする方法は現在構築してあるOracle 21cのGrid InfrastructureとDBをそのまま26aiにアップグレードするか、新規にDBサーバを建ててそこに26aiのRAC環境を再構築して現行DBのオブジェクトを移行するかの二択ですがOracle 26aiのRAC環境をゼロから構築する手順を確認しておきたいので新規のRAC環境構築＆現行DBからのオブジェクト移行でやろうと思います。

全体構成

Oracle 26aiのアップグレードガイドに記載された同バージョンの変更点、Oracle Grid Infrastructure インストールのチェックリスト、Oracle AI Databaseインストールのチェックリストにざっと目を通したところ現在の構成を変えなきゃならないような変更は見当たりませんでした。

なので新DB（Oracle 26ai）の構成は基本的に現行DB（Oracle 21c）の設計をそのまま踏襲しようと思います。

現行DB全体構成：DBサーバ構築１（全体構成）

もっとも設計の大枠は現行DBのままであってもOracle 26aiの環境構築にあたって細かいところでは変更しなきゃならない点や見直すべき点がまったく無いわけではありません。

そうした設計上の変更点を以下にざっくりまとめます。

ネットワーク構成

ポートグループ（仮想ネットワーク）

新DB（Oracle 26ai）の構築期間中、本番サイトでは現行DB（Oracle 21c）が稼働しています。OracleのRAC環境はパブリック、プライベートのどちらのネットワークでもブロード・キャストを流しますから現行の本番DBと同じネットワークで新DBを構築するのは非常にリスキーです。

なので新DBサーバはポートグループを現行DBサーバのポートグループと分離して構築、最後に本番用のポートグループと差し替えます。

DBネットワーク

構築用の一時的なポートグループを作成してこれを新DBのDBネットワーク（パブリック・ネットワーク）に割り当てます。構築とデータ移行が終わったところで本番サイトのDBネットワークに差し替えます。

【DBネットワーク】

構成	現行DBサーバ（Oracle21c）	新DBサーバ（Oracle26ai）
ポートグループ	Production DB Pub Network	VUP Pub Network1
仮想スイッチ/VLAN ID	vSwitchp2/10	vSwitchp2/91
ネットワーク・アドレス	192.168.30.0/24	192.168.30.0/24

インターコネクト用ポートグループ

新DBのインターコネクトにも新規に作成したポートグループを割り当てます。こちらはプライベートネットワークでDBサーバ以外のサーバとは通信はありません。なので新DBサーバの構築が終わっても既存のインターコネクト用ポートグループと差し替えず恒久的に使用します。

【インターコネクト】

構成	現行DBサーバ（Oracle21c）	新DBサーバ（Oracle26ai）
ポートグループ	Production DB Prv Network	Production DB26 Prv Network
仮想スイッチ/VLAN ID	vSwitchp3/20	vSwitchp3/21
ネットワーク・アドレス	10.10.20.0/24	10.10.21.0/24

管理ネットワーク

管理ネットワークについては現行DBと分離する必要性が低いので新DBサーバの構築期間中も本番サイトの管理ネットワークを割り当てます（既存のDBサーバとはIPアドレスで分離）。

仮想マシンとゲストOS

仮想マシン

現行DBサーバと同じESXi筐体内に新DBサーバを構築するわけですから新DBサーバの仮想マシン名は既存の仮想マシンとかぶらないようにしなくてはなりません。ここは安直に現行DBサーバの仮想マシン名の数値部分（01~03）+10を新DBの仮想マシン名とします。

【仮想マシン名】

構成	現行DBサーバ（Oracle21c）	新DBサーバ（Oracle26ai）
DBサーバ#1・仮想マシン名	prsdb01	prsdb11
DBサーバ#2・仮想マシン名	prsdb02	prsdb12
DBサーバ#3・仮想マシン名	prsdb03	prsdb13

オペレーティング・システム

Oracle 26aiのLinux x86-64オペレーティング・システム要件はRed Hatの場合は8.6以上もしくは9.2以上となっています。

Oracle 26aiのLinux x86-64オペレーティング・システム要件

Red Hat Enterprise Linux 8.6: 4.18.0-372.26.1.0.1.el8_6.x86_64以上
Red Hat Enterprise Linux 9.2: 5.14.0-284.30.1.el9_2.x86_64以上

現行DBサーバはRHEL8.10なので新DBサーバのOSもこのバージョンに合わせることは可能です。しかしOracle 26aiがRHEL9をサポートしているのにOSバージョン合わせだけのためにRHEL8を選択するのもちょっとどうかと思うので新DBサーバのOSはRHEL9で行こうと思います。

で、このページを書いている時点でRHEL9の最新リリースはREHL9.7、これまでの投稿ではOSやミドルウェアのバージョンはシステム的な要件がない限り、構築時点で最新のものとしてます。そのルールに従えば新DBサーバのOSもRHEL9.7なんですけど、このバージョンはExtended Update Support (EUS)がついてないんですよねぇ。

まあこちらの環境は本物のシステムではないんで拡張サポートがあってもなくても同じですけれども気分的にはあった方が収まりがいい。なので新DBサーバのOSはRHEL9.7のひとつ前、EUSがついているRHEL9.6とします（管理サーバとかAPサーバはEUSがつかない9.5で作っちゃ手ますけど）。

新DBサーバ・オペレーティング・システム

Red Hat Enterprise Linux 9.6

【補足：RHEL9及びOracle製品のライフサイクル】

Red Hat Enterprise Linux のライフサイクル（RHEL 9 計画ガイド）

Oracle Technology Products Oracle Lifetime Support Policy

ホスト名とIPアドレス

べき論で言うと新DBサーバのホスト名とIPアドレスは新規に振りなおすのが筋だと思います。しかし本番切り替えの作業を最小限にとどめるため、というのは建前で「過去の投稿を直すのが面倒＆ホストアドレスの採番体系を変更したくない」というしょうもない理由で新DBのホスト名とIPアドレスは現行DBのホスト名とIPアドレスをそのまま踏襲します。

なお、インターコネクトは新しくネットワーク・セグメントを切るのでホストアドレスだけ現行DBサーバから引き継ぎます。

また、新DBサーバは構築期間中も現行DBサーバと同じ管理ネットワークを使用します。管理ネットワークでは現行DBサーバと同じIPアドレスは使用できないので新DBサーバに構築用の一時的なIPアドレスを割り当てて構築完了後に現新のDBサーバでIPアドレスを入れ替えます。

【IPアドレス】

ネットワーク	現行DBサーバ（Oracle21c）	新DBサーバ（Oracle26ai）
DBネットワーク	192.168.30.21（prsdb01） 192.168.30.22（prsdb02） 192.168.30.23（prsdb03）	192.168.30.21（prsdb01） 192.168.30.22（prsdb02） 192.168.30.23（prsdb03）
インターコネクト	10.10.20.1（prsdb01） 10.10.20.2（prsdb02） 10.10.20.3（prsdb03）	10.10.21.1（prsdb01） 10.10.21.2（prsdb02） 10.10.21.3（prsdb03）
管理ネットワーク	172.16.10.21（prsdb01） 172.16.10.22（prsdb02） 172.16.10.23（prsdb03）	172.16.10.31（prsdb01） 172.16.10.32（prsdb02） 172.16.10.33（prsdb03）

ファイアウォール

現行DBサーバのファイアウォール構成ではプライベート・ネットワーク（インターコネクト）のNICをtrusted zone、パブリック・ネットワーク（DBネットワーク）、管理ネットワークのNICをデフォルトのpublic zoneに配置しています。まあこれでも一応いいといえばいいんですけどパブリック・ネットワークと管理ネットワークが同じzoneにあるのでネットワーク・レベルでブロードキャストの許可を設定するのがなかなか面倒です。

そこで新DBサーバでは新規にzoneを追加してそこでDBネットワーク用のN/Wインターフェース（NIC）を管理しようと思います。

【firewalld・Zone構成】

NIC	現行DBサーバ（Oracle21c）	新DBサーバ（Oracle26ai）
パブリック・ネットワーク（DBネットワーク）用	public	dbzone
プライベート・ネットワーク（インターコネクト）用	trusted	trusted
管理ネットワーク用	public	public

Oracle RAC構成

クラスタ名

新DBの構築では現行DBと管理ネットワークを共有しているので念のためクラスタ名を変更しておこうと思います。

【クラスタ名】

構成	現行DBサーバ（Oracle21c）	新DBサーバ（Oracle26ai）
クラスタ名	prsdb-cluster	prsdb-cluster26

ASMディスク設計

ストレージとASMディスク（グループ）

Oracle 26ai DBサーバ構築のベースとなるOracle 21cのDBサーバ全体構成について投稿を読み返したらASMディスク・グループの設計についてさらっと流しすぎていたきらいがありました。ここで少し説明を追加しておきます。

Oracle RACの記憶域はどのノードからもアクセスできなくてなならないので通常、ストレージ上のLU（Logical Unit、ボリューム）に配置します^*1。このLUはDBサーバから見るとディスク・デバイスでありOracleから見ればASMディスクです。

DBの規模が大きくなるとRMANではDBのバックアップに時間が掛ってしまうのでストレージの機能を使ってこのASMディスクをディスク・グループ単位にまとめてバックアップします。HDDのストレージの高速バックアップには処理方式かいくつかありましたがオールフラッシュ・ストレージの場合はほとんどがスナップショットを利用した差分同期によるボリューム・コピーです^*2。

こちらのDBは中身スッカスカのお試し環境ですけど一応、本物っぽくということでオールフラッシュ・ストレージのボリューム・コピーでDBバックアップを行うことを前提にASMディスク・グループを設計しています。

もちろんこちらの環境にストレージのようなお高い機器はありませんから実際にはシングルのESXi筐体で内蔵SSDのデータストアに仮想ディスクを乗っけてマルチライターで共有しているに過ぎません。

しかしそれじゃあ高速バックアップもへったくれもないので脳内ストレージを用意して仮想ディスク＝LUに見立ててOracle RACの記憶域を設計をしているという次第でございます。

＊1：VMWareでOracle RACを構成する場合は物理ストレージを使わずvSANでASMディスクを構成するなんてことも可能らしいです（Oracle RAC の vSAN サポート）。
*2：私の調べた範囲では。他の方式があったらゴメンなさい。

【補足】ストレージのLU＝ASMディスク
DBサーバが物理サーバであれば「ストレージのLU＝ASMディスク」の1択ですが、DBサーバがESXiの仮想マシンだとRawデバイス・マッピング（RDM）でストレージのLUをASMディスクに割り当てるか（物理サーバと同じ）、ストレージのLUにデータストアを設定してそこに作成した仮想ディスクをマルチライターで共通するかの2択です。
Oracle11gの頃あたりだとストレージ性能の関係もあってRDMでASMディスクを構築するのがVMWareにおけるOracle RAC構築のスタンダードだったんと思うんですけど現在はマルチライターによる共有の方が優勢のようでございます。
RDM v/s VMDK – VMware Virtual Volumes to the rescue – VMware Cloud Foundation (VCF) Blog

ディスク・グループを構成するASMディスクの本数

これも説明の追加です。

Oracle 26aiの「Automatic Storage Management管理者ガイド」にはストレージ準備の推奨事項として「ディスク・グループごとのLUN (Oracle ASMディスク)の数は、アクティブなI/Oパスの数の少なくとも4倍である必要があり」と記述されています（通称4倍ルール）。

DBサーバのI/Oパスが2パスでActive – Activeのマルチパスを構成している場合、この推奨に従えばASMディスク（LU）は最低8本、4パスならば16本以上となかなかの本数です。

ただ、この推奨事項ってOracle 12.1の管理者ガイドからずっと同じ記述^*1なんですよねぇ……。

Oracle 12.1のリリースはちょうど企業向けのオールフラッシュ・ストレージが出回り始めたのと同じ時期ですからこの推奨は当時主流だったHDDのストレージを想定したものと見て間違いなさそうです。それに合わせて現在主流のオールフラッシュ・ストレージでASMディスクを設計するのはさすがにちょっとどうなのよ、というのが私の正直な感想^*2でございます。

DBサーバ側のI/Oパスやデバイス・キュー、それにストレージのコントローラによる処理の分散を考えればオールフラッシュ・ストレージでもディスク・グループのASMディスク（LU）は複数本で構成すべきだとは思います。

しかしHDDストレージ・ベースの4倍ルールに従って多数のASMディスクで構成してもディスク・グループ拡張時の手間が増えたりLUの管理が煩雑になるだけであまり意味がありません。

なのでこちらの環境では4倍ルールはガン無視、構築と管理の手間だけ考えてディスク・グループあたりのASMディスク本数を2本としています。

*1：Oracle 11.2の管理者ガイドでは4倍ルールがなくて「ディスク・グループごとに、同じサイズおよびパフォーマンスのLUN(Oracle ASMディスク)が4つ以上あることをお薦めします。」

*2：正直、私は最初に4倍ルールを見た時にRAID0+1で多数のディスク（RAIDグループ）を並べてDB用の記憶域を構成していた時代の推奨が紛れ込んでいるのかと思いました。

追記

ASMディスク設計の4倍ルールについてGeminiさんから非常に整理された見解をいただきました。
公開許可をもらったので少し長いですが下に掲載しておきます。

4倍ルールに関するGeminiさんのご回答
------------------------------------------------------------------

「LUN数をアクティブなI/Oパスの数の少なくとも4倍にする」という推奨事項は、まさにHDD時代の物理的な制約（キューの深さや物理ヘッドの分散）を起源とする古いガイドラインが、ドキュメントの記述としてそのまま23cや26aiまで引き継がれてしまっている典型例です。
オールフラッシュ・ストレージ（AFA）が主流となった現代において、この記述をそのまま鵜呑みにする必要がない理由と、現在の実務的な考え方を整理しました。

なぜHDD時代にこのルールが必要だったのか？ 
1.OSやHBAの「I/Oキュー（Queue Depth）」の枯渇防止:
OSやHBA（Host Bus Adapter）は、LUN（デバイス）単位でI/Oを処理するキュー（同時発行できる命令数、通常32〜128程度）を持っています。LUN数が少ないと、ストレージ本体にはまだ処理能力があっても、OS側のLUN単体のキューが先に詰まってボトルネックになりました。LUNを複数（4倍以上）に切り分けることで、OSのデバイスキューを増やし、並列度を上げる必要があったのです。

2.物理ディスクへのデータ分散（SAME: Stripe and Mirror Everything）:
古いミドルレンジのHDDストレージでは、1つのLUN＝特定の数台の物理HDDに紐づいていることが多く、LUN数を増やさないとデータの配置が少数の物理ヘッドに偏り、I/Oの競合（ホットスポット）が発生しました。

オールフラッシュ（AFA）時代における変化
1.ストレージ内部の仮想化:
現代のAFAは、LUNを切り出しても、それは論理的な「器」に過ぎません。裏側ではすべてのSSD（フラッシュモジュール）にデータが高度に分散（ワイドストライピング）され、強力なコントローラーが一元管理しています。そのため、「LUNを細かく分けないと性能が出ない」という物理的な理由は消滅しました。

2.圧倒的な処理能力とNVMeの普及:
フラッシュ自体の応答速度（レイテンシ）がμs（マイクロ秒）単になり、I/Oキューの消化スピードがHDDとは比較にならないほど高速化しました。さらに、最近のNVMe-oF（NVMe over Fabrics）などの接続プロトコルでは、プロトコル自体が膨大なマルチキューをサポートしているため、OS側のLUN単位のキュー詰まり自体が発生しにくくなっています。


現在の主要ストレージベンダー（Pure StorageやDell PowerMax/PowerStoreなど）のOracle向けベストプラクティスガイドでは、パスの4倍といった計算ではなく、ディスクグループ（+DATAや+RECO）ごとに、4個〜最大でも8個程度のLUNで構成するのが標準的です。

1個にしない理由: 
万が一のOS・マルチパス階層での一時的なシリアルロックや、レガシーな環境での最小限のキュー並列性を担保するため。
多くしすぎない理由: 
管理（WWNの紐づけやASMへのマッピング）が煩雑になるだけで、性能面でのメリットが一切ないため。

結論
オラクル社の公式ドキュメントは、下位互換性やレガシーなSANストレージ（まだ世の中に残っているHDDベースのシステム）を考慮して保守的に書かれる傾向が強く、一度記載された推奨値が10年以上更新されないケースが多々あります。
ですので、ご認識の通り「これはHDD時代の遺物である」と判断して差し支えありません。現代のAFAを導入する場合は、オラクルの汎用ガイドよりも、採用するストレージベンダーが発行している最新の「Oracle管理者向けベストプラクティス・ガイド」の推奨LUN数を優先して設計するのが最も安全でパフォーマンスを引き出せます。

制御ファイル、SPファイル、パスワードファイル

現行DB（Oracle 21c）ではディスク・グループDG11とDG21に制御ファイルを各1、DG21にSPファイルとパスワード・ファイルを格納しています。

新DB（Oracle 26ai）ではこの配置を見直して制御ファイル、SPファイル、パスワード・ファイルをすべてDG11に格納します。

【DB関連ファイル配置】

ディスク・グループ	現行DB（Oracle21c）	新DB（Oracle26ai）
DG11（バックアップ対象外）	制御ファイル1	制御ファイル1 制御ファイル2 SPファイルパスワード・ファイル
DG11（バックアップ対象）	制御ファイル2 SPファイルパスワード・ファイル	–

DG21はDBバックアップ（ボリューム・コピー）の対象です。なのでここに制御ファイルを配置すれば万一、ストレージが全損したとしてもバックアップ・ボリュームに含まれている制御ファイルでDBの復旧（バックアップ制御ファイルによる不完全回復）が可能です。

しかしコレ、逆に言うとそれ以外のケースではDG21に制御ファイルを入れておいても使い道ってないんですよね…

DB構成ファイルの全損でも起きない限り、障害DBの復旧はリストアされたDG21の制御ファイルではなくDG11にある最新の制御ファイルを使用します。

DG21の制御ファイルはボリュームのリストア時点でDG11の制御ファイルと不整合を起こしているのでDBのリカバリ前に削除してDG11の制御ファイルをコピーしてこなくちゃなりません。

また、現行DBではSPファイルとパスワード・ファイルをDG21に格納していますが、こちらもDG21のリストアで内容が巻き戻ってしまう可能性があります。

よくよく考えたらDG21に制御ファイルやSPファイル、パスワード・ファイルを置いてもメリットがあまりなく、かえって復旧作業の手間が増えるだけなので新DB（Oracle 26ai）ではすべてDG11に移動してしまいます。

もちろん制御ファイル、SPファイル、パスワード・ファイルのどれが欠けてもよろしくありませんから必要に応じてバックアップは取得します。ただしこれらのファイルをDBバックアップに含めてしまうとリストアによっていろいろよろしくないことが生じるので新DBではその点を改善しようというのがこの見直しの趣旨でございます。

【補足】制御ファイル、SPファイル、パスワードファイルのバックアップ
新DBでは制御ファイルそのものでなく制御ファイルのコピーをDG21に作成してからボリューム・バックアップを取得する運用を想定しています。
SPファイルはリストアよりも再作成の方がASMへの収まりがいいのでテキスト（Pファイル）でバックアップを取ろうかと思います、
ちなみにRMANの”CONTROLFILE AUTOBACKUP”はデフォルトでONとなっているので構成変更があればユーザーが何をしなくてもDBが勝手に制御ファイルとSPファイルをバックアップしています（デフォルトの出力先はOracleホームのdbs。21cだと読み取り専用のホームのdbsに出力）。ただ、このバックアップはRMAN形式でリストアが少々面倒です。
それにDBサーバのOracleホームがASMと同じストレージに乗っていればストレージ全損でロストしてしまうのでこちらの環境ではこれとは別に制御ファイルやSPファイルをバックアップ運用に含めている次第でございます。
しかしまあ、ここまでの話は全て設計上の運用がこうなっているというだけです。実際には現行DBのバックアップはRMANで取得しており新DB]もそれで行きます。
一応、ddか仮想ディスクのコピーを使ってボリューム・バックアップからのDB復旧検証はやりますが普段のDBバックアップで毎回なんちゃってボリューム・バックアップを取るのは面倒なのでやりません。

新DBサーバの構成はだいたいこんな感じです。

まあ正直、私もOracle 26aiのアップグレード・ガイドやGrid Infrastructureのインストール・マニュアルにざっと目を通したレベルなんであとは実際にDBサーバ（＆ Oracle 26ai RAC）を構築してみて問題があれば都度手直ししていこうと思います。

ということでまずはDBサーバのOSインストールとストレージ（仮想ディスク）の設定から。

DBサーバ構築（Oracle 26ai）・関連ページ
DBサーバ構築、Oracle 26ai（１）概要
 DBサーバ構築、Oracle 26ai（２）OS、N/W、ストレージ
 DBサーバ構築、Oracle 26ai（３）Gridインストール１
 DBサーバ構築、Oracle 26ai（４）Gridインストール２
 DBサーバ構築、Oracle 26ai（５）DBインストール