Exadata X11M 技術概要とアーキテクチャ: 前編

Transcript

1. Exadata X11M 技術概要とアーキテクチャ: 前編 日本オラクル株式会社 2026年4月6日
2. Agenda Copyright © 2026, Oracle and/or its affiliates 2 Exadata製品概要 ハードウェア構成 ネットワークアーキテクチャ ソフトウェアアーキテクチャ (RAC/ASM) 1 2 3 4 ソフトウェア機能 運用管理 パフォーマンス確認方法 技術情報 5 6 7 8 前編 後編
3. Exadata 製品概要 Copyright © 2026, Oracle and/or its affiliates 3
4. 様々なデプロイメント環境で稼働できるエンジニアド・システム オンプレミス、Cloud@Customer、Oracle Cloud、マルチクラウド データ・インテリジェント・ソフトウェア 独自のアルゴリズムにより、AI、分析、ミッションクリティカルなアプリケーションを あらゆる規模で卓越したパフォーマンスと効率を実現 データに最適化されたハードウェア スケールアウト、データに最適化されたコンピュート、ネットワーキング、ストレージ Exadata Vision すべてのデータ・ワークロードに対してきわめて高いスケーラビリティ、パフォーマンス、可用性を低コストで実現 Copyright © 2026, Oracle and/or its affiliates 4
5. 数千のミッション・クリティカル環境で活用 すべてのワークロードに最適 データのためのAI ペタバイト級のウェアハウス ミッション・クリティカル・システム • 金融取引 • プロセス製造 • 電子商取引 パッケージ・アプリケーション • SAP, Oracle, Siebel, PSFT, … データベース統合 Copyright © 2026, Oracle and/or its affiliates 5
6. 様々なデプロイメント環境で稼働できる Exadata Copyright © 2026, Oracle and/or its affiliates 6 Cloud@Customer Exadata Cloud Infrastructure (Public Cloud) オンプレミス Multicloud OCI Dedicated Region (DRCC)
7. Exadata Exascale – 次世代のExadataデータ・インテリジェント・ソフトウェア Copyright © 2026, Oracle and/or its affiliates 7 +クラウドでのIOPS追加時の 追加コスト不要 +即時のクローンおよびスナップショット お客様のプライベート・クラウド Exadata Exascale パブリッククラウド すべてのクラウドの メリット • 低いエントリーコスト、従量課金 • マルチテナント・リソース・プール • スモールスタート、高い弾力性 すべてのExadata インテリジェンス機能 • データ・インテリジェントなストレージ • 超高速RDMA • ディスク/フラッシュ/DRAM自動階層化
8. • 2ソケットのデータベース・サーバーでのスケールアウト構成が可能 • 最新のAMD 96コア・プロセッサ – X10Mよりも最大25%高速 • 最新の最速メモリ – X10Mよりも最大33%高速化 • 超高速、低レイテンシ 2X 100 Gb/s RDMAネットワーク • インテリジェントな2ソケット・ストレージ・サーバーでのスケールアウト構成が可能 • 最新のAMDプロセッサ – X10Mよりも最大11%高速 • 最新、最速のフラッシュ – X10Mより最大で2.2倍高速 • 最新のExadata RDMAメモリー(XRMEM)– X10Mより最大33%高速 Exadata X11M– 独自のデータ・インテリジェント・ソフトウェアのためのプラットフォームをさらに高速化 Copyright © 2026, Oracle and/or its affiliates 8 独自のデータ・インテリジェント・ソフトウェアにより、 競合するデータベース・システムよりも桁違いに高いパフォーマンスを実現
9. Exadata X11M のインテリジェント・データ・アーキテクチャにより 究極のパフォーマンスを提供 Copyright © 2026, Oracle and/or its affiliates 9 究極の AI検索性能 究極の OLTP性能 究極の アナリティクス性能 より少ない支出でより多くの処理を お客様に可能に
10. Artificial Intelligence インテリジェントなOLTP インテリジェントなアナリティクス Exadata インテリジェンスのハイライト 独自のAIベクトル・アクセラレーション データ集約型のベクトル検索のI/Oをス トレージ・クラウドにオフロード 独自の インテリジェント・コミュニケーション ハードウェアベースのRDMAを使用し て、最速のOLTP I/Oと 最速のノード間調整を実現 独自のデータ・インテリジェンス データ集約型のSQLを ストレージ・サーバーに 自動的にオフロード 独自のAIベクトル計算 コンピューティング負荷の高い ベクトル比較とtop-Kの選択を ストレージ・クラウドにオフロード 独自のインテリジェント・クローン 完全なExadata機能による インスタント・データベース・クローン の提供 独自のインテリジェントな列化 データを超高速インメモリー列形式に 自動的に変換 Copyright © 2026, Oracle and/or its affiliates 10
11. Exadata X11M ハードウェア構 成 Copyright © 2026, Oracle and/or its affiliates 11
12. コンピュート容量 2,880 DB コア 42 TB メモリ ストレージ容量 1088 ストレージコア 21.25 TB XRMEM 462.4 TB NVMe Flash 2 PB Raw Flash 容量 4.4 PB Raw Disk 容量 Exadata X11M:極めて高いスケーラビリティと優れたパフォーマンス Copyright © 2026, Oracle and/or its affiliates • スケールアウト可能なインテリジェントなデータベース・サーバー • 最新の 96-コア 第5世代 EPYC CPUs • 最大3TBメモリ • 超高速100Gb/s RDMA over Converged Ethernet(RoCE)内部Fabric • スケールアウト可能なインテリジェントなストレージ・サーバー • 最新の 32-コア 第5世代 AMD EPYC CPUs • 最大1.25TB Exadata RDMAメモリー(XRMEM) • 122.88TB RAW容量最適化フラッシュ(EF) • 最大264TB RAWディスク容量(HC) ラック毎 最大 Database Servers Extreme Flash (EF) Storage Server High Capacity (HC) Storage Servers 12
13. Exadata X11M Database Machine Copyright © 2026, Oracle and/or its affiliates • スケール・アウト可能なインテリジェントなデータベース・サーバー • CPUの高速化：第5世代 96-コア AMD EPYC CPUs • CPUの高速化：第5世代 32-コア AMD EPYC CPUs • メモリの高速化 : 6400 MT/s (from 4800 MT/s) • X11M: 2-ソケット, 2x 96-コア • X11M-Z: 1-ソケット, 1x 32-コア • 100GbE RDMA over Converged Ethernet (RoCE)内部ファブリック • データベース・サーバーとストレージ・サーバーでのPCIe 5.0対応、 アクティブ/アクティブ、2x 100 Gb RoCEネットワーク・インタフェース・ポート • スケール・アウト可能なインテリジェントなストレージ・サーバー • CPUの高速化：第5世代 32-コア AMD EPYC CPUs • メモリの高速化 : 6400 MT/s (from 4800 MT/s) • 最大1.25TB Exadata RDMAメモリー(XRMEM) • EF モデルと HCモデル: 2-ソケット, 2x32 コア • HC-Z、XT: 1-ソケット, 1x 32 コア X11M-Z High Capacity (HC-Z) Storage 132 TB capacity; 13.6 TB Flash Cache 576 GB XRMEM Database Server X11M 512GB, 1.5TB, 2.25TB, 3TB DRAM Extreme Flash (EF) Storage 122.88 TB capacity; 27.2 TB Flash Cache 1.25 TB XRMEM High Capacity (HC) Storage 264 TB capacity; 27.2 TB Flash Cache, 1.25 TB XRMEM Database Server X11M-Z 768GB, 1.125TB DRAM X11M Extended (XT) Storage 264 TB capacity; 13.6 TB Flash Cache 13 (X10M からの変更を青字)
14. Exadata X11M パブリック・クラウド Database Server (2-ソケット) • 第5世代 AMD EPYC CPU – 96-コア, 2.6 GHz (up to 4.5 GHz) （X9Mでは 64-コア 2.55 GHz (Up to 3.5 GHz). 32 コア増加！） • より高速な メモリ –1.5 TB DDR5-6400 MT/s （X9Mでは 1.5TB DDR4-3200 MT/s データ転送レートは2倍!） ネットワーク • より高速な 100Gb/s RoCE Network Cards; PCIe Gen5 （X9Mでは CX5-100G PCIe Gen4） Storage Server • より高速な 第5世代 AMD EPYC CPU – 32-コア, 2.95 GHz (4.4 GHz boost) （X9Mでは 24-コア 2.0 GHz (2.8 GHz Boost) 8 コア増加、 34% 高速な CPU!） • より高速な Exadata RDMA Memory Accelerator (XRMEM) – 1.25 TB DDR5 6400 MT/s （X9M：1.5TB PMEM） • より高速な メモリ – 256 GB DDR5 6400 MT/s （X9Mでは 256GB DDR4-3200 MT/sデータ転送レートは2倍!） • 新しい パフォーマンス最適化 F680 v2 6.8 TB NVMe PCIe Gen5 flash （X9M：F640 PCIe Gen4 6.4TB） • 新しい そして増加したストレージ容量 – 22 TB Hard Drives (X9M:18 TB) 22% ストレージ容量増加 - 264 TB HC Storage Server毎（X9M:216 TB) 14 Copyright © 2026, Oracle and/or its affiliates
15. Oracle Exadata – standardized and simple to deploy • すべてのDatabase Machineが同じデプロイメント • すぐに実行できる形で提供 • テスト済構成 • サポート可能 • すべてのOracle Databaseワークロードを実行可能 • OLTP、分析、統合のワークロード • 40年にわたるOracle Database の全機能 • ソフトウエアにExadataの認定は不要 • 既存のOracleエコシステムの活用が可能 • スキル、ナレッジ・ベース、個人およびパートナー Copyright © 2026, Oracle and/or its affiliates ✓ 独自構成の問題が発生しない ✓ Oracle Engineeringで 使用される構成と同じ構成 数か月ではなく数日でデプロイ可能 15
16. Exadata X11M クオーター・ラック構成からマルチラック構成への エラスティック・スケーリング Copyright © 2026, Oracle and/or its affiliates Elastic Rack Multi Rack • 2台のデータベース・サーバーと3台のストレージ・サーバーから開始 • 必要に応じてデータベース・サーバーまたはストレージ・サーバー(あるいはその両方)を追加可能。最大14ラックまでスケール・アウト可能 • Oracle Exadata Configuration Assistant (OECA)を使用した目的の構成のモデル化 X11M and X11M-Z Quarter Rack 16
17. • Exadata X11M Database Machineでは、2つの構成で使用可能なx86 2ソケットおよび1ソケットの データベース・サーバーを使用 • X11M Database Server - 両方のCPUソケットに96コア搭載 - OLTP、アナリティクス、統合、メモリー集中型、水平方向および垂直方向のスケーラブルなデータベース・ワークロード、 およびすべてのマルチラック・データ・ワークロードなど、すべてのワークロードに最適 • X11M-Z Database Server - 単一のCPUソケット32コア搭載 - スケーラビリティや最大パフォーマンスを必要としない中程度のワークロードに最適 Exadata X11M Database Servers Copyright © 2026, Oracle and/or its affiliates X11M Database Server X11M-Z Database Server 17
18. Exadata Database Server X11M Copyright © 2026, Oracle and/or its affiliates プロセッサー • 2x 96-コア AMD EPYC 9J25 Processors DDR5 メモリ • 512 GB (16x 32 GB) / 1.5 TB (24x 64 GB) / 2.25 TB (24x 96 GB) / 3 TB (24x 128 GB) 6400MT/s DDR5 DIMMs (工 場出荷時のインストール可能なオプション、フィールドアップグレード可能) ローカルディスク • 2x 3.84 TB NVMe PCIe 5.0 Drives – 拡張可能 4x 3.84 TB (ホット・スワップ可能) インストール済み ネットワークカード • 1 x dual-port QSFP28 100G RDMA Ethernet NIC (PCIe 5.0) – 両ポートアクティブ – RoCE ネットワーク • 2 x dual-port SFP28 10/25G ethernet NIC – クライアント・ネットワーク クライアント・ネットワーク (オプション、フィールド・イ ンストール) 以下から最大3枚(任意の組合せが可能): • Dual port QSFP28 100G ethernet NIC (フィールド・インストール) • Dual-port SFP28 10/25G ethernet NIC (フィールド・インストール) • Quad-port RJ45 10G ethernet NIC (フィールド・インストール) リモート管理 • 1x ethernet port (ILOM) • 1x ethernet port (eth0) パワーサプライ ホットスワップ対応冗長化電源装置およびファン 18
19. プロセッサー • 1x 32-コア AMD EPYC 9J15 Processors DDR5 メモリ • 768 GB (12x 64 GB) / 1.125 TB (12x 96 GB) 6400MT/s DDR5 DIMMs (工場出荷時のインストール可能なオプション、フィールドアップグレード可能) ローカルディスク • 2x 3.84 TB NVMe PCIe 5.0 Drives – 拡張可能 4x 3.84 TB (ホット・スワップ可能) インストール済み ネットワークカード • 1 x dual-port QSFP28 100G RDMA Ethernet NIC (PCIe 5.0) – 両ポートアクティブ – RoCE ネットワーク • 2 x dual-port SFP28 10/25G ethernet NIC – クライアント・ネットワーク クライアント・ネットワーク (オプション、フィールド・イ ンストール) 以下から1枚: • Dual port QSFP28 100G ethernet NIC (フィールド・インストール) • Dual-port SFP28 10/25G ethernet NIC (フィールド・インストール) • Quad-port RJ45 10G ethernet NIC (フィールド・インストール) リモート管理 • 1x ethernet port (ILOM) • 1x ethernet port (eth0) パワーサプライ ホットスワップ対応冗長化電源装置およびファン Exadata Database Server X11M-Z Copyright © 2026, Oracle and/or its affiliates 19
20. Exadata X11M Storage Servers • Exadata X11M Storage Servers は以下の構成で提供 • X11M High Capacity (X11M HC) - 両方のCPUソケットに32コア、264TBのRAW容量を搭載 - 容量とパフォーマンスの両方に最適 • X11M Extreme Flash (X11M EF) - 両方のCPUソケットに32コア、122.88TBのRAW容量を搭載 - High Performanceワークロードに最低 • X11M-Z High Capacity (X11M-Z HC) - 単一のCPUソケット32コア、132TBのRAW容量を搭載 - 中程度のワークロードに最適 • X11M Extended (XT) (X11M XT) - 単一のCPUソケット32コア、264TBのRAW容量を搭載 - データベースクラスター全体であまり頻繁にアクセスされないデータの保存に最適 20 Copyright © 2026, Oracle and/or its affiliates X11M – HC Storage Server X11M – EF Storage Server X11M-Z HC Storage Server X11M – XT Storage Server
21. Exadata Storage Server X11M High Capacity (HC) Copyright © 2026, Oracle and/or its affiliates プロセッサー • 2x 32-コア AMD EPYC 9J15 Processors 全 DDR5 メモリ • 1.5 TB (24x 64 GB) 6400 MT/s DDR5 DIMMs システム・メモリ • 256 GB メモリ・アクセラレーション • 1.25 TB ドライブ • 4x 6.8 TB パフォーマンス最適化 Flash Accelerator F680 PCIe Gen5 NVMe (ホット・プラガブル) • 12x 22 TB 3.5-inch 7200rpm SAS3 HDD (ホット・スワップ可能) • 2x 480 GB NVMe M.2 (ホット・プラガブル) ディスク・コントローラー • Disk Controller HBA ネットワーク • 1x Dual-port QSFP28 100G RDMA Ethernet NIC (PCIe 5.0) – 両ポートアクティブ リモート管理 • 1x ethernet port (ILOM) • 1x ethernet port (eth0) パワーサプライ ホットスワップ対応冗長化電源装置およびファン 21
22. Exadata Storage Server X11M Extreme Flash (EF) Copyright © 2026, Oracle and/or its affiliates プロセッサー • 2x 32-コア AMD EPYC 9J15 Processors 全 DDR5 メモリ • 1.5 TB (24x 64 GB) 6400 MT/s DDR5 DIMMs システム・メモリ • 256 GB メモリ・アクセラレーション • 1.25 TB ドライブ • 4x 6.8 TB パフォーマンス最適化 Flash Accelerator F680 PCIe Gen5 NVMe (ホット・プラガブル) • 4x 30.72 TB capacity-optimized 2.5-inch NVMe PCIe Gen4 SSD (ホット・スワップ可能) • 2x 480 GB NVMe M.2 (ホット・プラガブル) ネットワーク • 1x Dual-port QSFP28 100G RDMA Ethernet NIC (PCIe 5.0) – 両ポートアクティブ リモート管理 • 1x ethernet port (ILOM) • 1x ethernet port (eth0) パワーサプライ ホットスワップ対応冗長化電源装置およびファン 22
23. Exadata Storage Server X11M-Z High Capacity (HC) Copyright © 2026, Oracle and/or its affiliates プロセッサー • 1x 32-コア AMD EPYC 9J15 Processor 全 DDR5 メモリ • 768 GB (12x 64 GB) 6400 MT/s DDR5 DIMMs システム・メモリ • 192 GB メモリ・アクセラレーション • 576 GB ドライブ • 2x 6.8 TB パフォーマンス最適化 Flash Accelerator F680 PCIe Gen5 NVMe (ホット・プラガブル) • 6x 22 TB 3.5-inch 7200rpm SAS3 HDD (ホット・スワップ可能) • 2x 480 GB NVMe M.2 (ホット・プラガブル) ディスク・コントローラー • Disk Controller HBA ネットワーク • 1x Dual-port QSFP28 100G RDMA Ethernet NIC (PCIe 5.0) – 両ポートアクティブ リモート管理 • 1x ethernet port (ILOM) • 1x ethernet port (eth0) パワーサプライ ホットスワップ対応冗長化電源装置およびファン 23
24. Exadata Storage Server X11M Extended (XT) Copyright © 2026, Oracle and/or its affiliates プロセッサー • 1x 32-コア AMD EPYC 9J15 Processor 全 DDR5 メモリ • 256 GB (8x 32 GB) 6400 MT/s DDR5 DIMMs システム・メモリ • 256 GB メモリ・アクセラレーション • N/A ドライブ • 2x 6.8 TB パフォーマンス最適化 Flash Accelerator F680 PCIe Gen5 NVMe (ホット・プラガブル) • 12x 22 TB 3.5-inch 7200rpm SAS3 HDD (ホット・スワップ可能) • 2x 480 GB NVMe M.2 (ホット・プラガブル) ディスク・コントローラー • Disk Controller HBA ネットワーク • 1x Dual-port QSFP28 100G RDMA Ethernet NIC (PCIe 5.0) – 両ポートアクティブ リモート管理 • 1x ethernet port (ILOM) • 1x ethernet port (eth0) パワーサプライ ホットスワップ対応冗長化電源装置およびファン 24
25. Exadata X11M と X11M-Z –出荷時構成 Copyright © 2026, Oracle and/or its affiliates • Database Server クライアント接続 • すべてのデータベース・サーバーには、2枚のデュアルポート25GbEネットワーク・カードが付属 • Database Server メモリ容量 • Exadata X11M Database Servers: - 3 TB (24x 128 GB DDR5 DIMMs) - 2.25 TB (24x 96 GB DDR5 DIMMs) - 1.5 TB (24x 64 GB DDR5 DIMMs) - 512 GB (16x 32 GB DDR5 DIMMs) • Exadata X11M-Z Database Servers: - 1.125 TB (12x 96 GB DDR5 DIMMs) - 768 GB (12x 64 GB DDR5 DIMMs) 25
26. • Exadata X11M Memory Expansion Kit - 7627326 - Exadata X11M Memory Expansion Kit - Twenty four 64 GB DIMMs - 7627327 - Exadata X11M Memory Expansion Kit - Twenty four 96 GB DIMMs - 7627328 - Exadata X11M Memory Expansion Kit - Twenty four 128 GB DDR5 DIMMs • X11Mデータベース・サーバーのメモリー構成の拡張 - 512 GBから1.5 TBへ（64 GB DIMMを使用(1x拡張キット)）– 既存DIMMを交換 - 512 GBまたは1.5 TBから2.25 TBへ(96 GB DIMMを使用(1x拡張キット)）– 既存DIMMを交換 - 512 GB、1.5 TB、2.25 TBから3 TBへ（128 GBのDIMMを使用(1x拡張キット) ） – 既存DIMMを交換 • ノート: - Exadata X11Mストレージ・サーバーでメモリーを拡張するオプションは無し - 前世代メモリーはX11Mと互換性無し(逆も同様) Exadata Database Server X11M メモリのアップグレード (フィールド・アップグレード) Copyright © 2026, Oracle and/or its affiliates 26
27. データベース・サーバーX11M-Zは、768 GB (12x 64 GB)メモリまたは1.125 TB (12x 96 GB)メモリのいずれかの 単一ソケット・サーバー。768 GB構成のサーバーのみメモリ拡張可能 • データベース・サーバーX11M-Zのメモリー構成の拡張 - 96 GB DIMMを使用して、データベース・サーバーごとに768 GBから1.125 TB へ拡張(2台のサーバーの場合は1xキット)– 既存のDIMMを交換 - Qty 1: 7627327 - Exadata X11M Memory Expansion Kit - Twenty four 96 GB DIMMs • ノート - Exadata X11M-Zストレージ・サーバーでメモリーを拡張するオプションは無し - 前世代メモリーはX11Mと互換性無し(逆も同様) Exadata Database Server X11M-Z メモリのアップグレード (フィールド・アップグレード) Copyright © 2026, Oracle and/or its affiliates 27
28. ネットワーク拡張- フィールド・アップグレード • Exadata X11M Database Servers 工場出荷時 • 2x Dual 25G Network Adapters • ネットワークに使用可能な追加スロットを最大 3個まで、以下から選択可能 • Dual 100G Network Card (QSFP28), ないしは • Dual 25G Network Card (SFP28), ないしは • Quad 10G Network Card (RJ45) • 上記の組み合わせ Exadata Database Server X11M クライアント・ネットワーク・オプション Copyright © 2026, Oracle and/or its affiliates Dual 100G / Dual 25G / Quad 10G Dual 25G Dual 25G Dual 25G Field Upgrade Slot Dual 25G RoCE Network RoCE Network 28
29. ネットワーク拡張- フィールド・アップグレード • Exadata X11M-Z Database Servers 工場出荷時 • 2x Dual 25G Network Adapters • ネットワークに使用可能な追加スロットを最大 1個まで、以下から選択可能 • Dual 100G Network Card (QSFP28), ないしは • Dual 25G Network Card (SFP28), ないしは • Quad 10G Network Card (RJ45) Exadata Database Server X11M-Z クライアント・ネットワーク・オプション Copyright © 2026, Oracle and/or its affiliates Field Upgrade Slot Dual 100G / Dual 25G / Quad 10G Dual 25G RoCE Network ノート: 追加のQuad 10Gネットワーク・カードが必要な場合は、既存のデュアル25Gカードを交換可能 29
30. データベース・サーバーX11M-Zをデータベース・サーバーX11Mに変換するためのCPUおよびメモリーのアップグレード・キット • 既存の32コア・プロセッサを、サーバーごとに2x 96コア・プロセッサに置き換え。以下のパーツを注文: - Qty 1: 7627323 - CPU upgrade kit for Exadata Database Machine X11M-Z to X11M DB Server Rack Upgrade - Qty 1: 7627324 - Heat Sink Upgrade Kit for Exadata Database Machine X11M-Z to X11M DB Server Rack Upgrade • メモリ: - Qty 1: 7627326 Exadata X11M Memory Expansion Kit - Twenty four 64 GB DIMMs. Install 12 per server. - ないしは Qty: 2 以下のアップグレードキット: - 7627327 Exadata X11M Memory Expansion Kit - Twenty four 96 GB DIMMs - 7627328 Exadata X11M Memory Expansion Kit - Twenty four 128 GB DDR5 DIMMs • ノート: - 両方のデータベース・サーバーを同時にアップグレードする必要があります。CPUおよびヒートシンクアップグレードキットには、 2台のDBサーバー用の4つのコンポーネントが含まれています。メモリーキットには各 X11M-Zサーバー用に24個のDIMMが含まれる - X11M-Zデータベース・サーバーには、768GB以上のメモリー(12x64)が付属。 お客様が768GBから 1.5TBへのアップグレードを希望する場合は、64 GBキットの数量: 1を購入し、各サーバーに12個のDIMMを追加 (すでに12個のDIMMが存在)。完了すると、各サーバーの24x64 GB = 1.5TBになる より多いメモリ容量が必要な場合は、サーバーごとに1つずつ、96GBまたは128GBのDIMMアップグレードキットを購入 Exadata Database Server X11M-Zのメモリー・アップグレード・キット • 以下スライド参照: “Exadata Database and Storage Server X11M-Z Memory Field Upgrades” Exadata Database Server およびExadata Storage Server の X11MおよびX11M-Zは、X11M-Z容量拡張に使用可能 Exadata Database Server X11M-Z 拡張オプション Copyright © 2026, Oracle and/or its affiliates 30
31. • クォータ・ラック構成は、2台 Database Server + 3台 Storage Serverで継続 • エラスティック・ラック構成(サーバーの合計数は電力要件によって異なる) - 最小2台データベース・サーバーおよび3台ストレージ・サーバー - 最大15台データベース・サーバー(512 GBメモリ構成) - 最大12台データベース・サーバー(1.5TBおよび2.25TBメモリ構成) - 最大14台データベース・サーバー(3TBメモリ構成) - 最大15台 X11M-Zデータベース・サーバー(768 GBおよび1.125 TBメモリ構成) - 最大17台 X11M HC、HC-Z、EF ストレージ・サーバー - 最大14台 X11M XT ストレージ・サーバー • ストレージ拡張ラック(最大合計19台のサーバーまで) - ラック毎最小4台のHCまたはEFストレージ・サーバー - 最大15台の追加HC、HC-ZまたはEFストレージ・サーバー Exadata Database Machine X11M Elevation Copyright © 2026, Oracle and/or its affiliates 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 OECA (Oracle Exadata Configuration Assistant)を使用して、目的のExadata構成を作成。最大構成は、サーバーのメモリー容量、電力要件、PDU容量などによって 異なる。OECAは、構成が有効であることを確認。https://www.oracle.com/database/technologies/oeca-download.html 31
32. • 以下の構成からスタート: • 2 x X11M DB Server (3 TB) • 3 x X11M HC Storage Exadata X11M 混在および一致の例 Copyright © 2026, Oracle and/or its affiliates 32
33. Exadata X11M 混在および一致の例（続く） • 同一ラック内に以下を追加: • 2 x X11M DB Server (3 TB) • 3 x X11M HC Storage • 2 x X11M-Z DB Server • 3 x X11M EF Storage • 2 x X11M DB Server (1.5 TB) • 3 x X11M XT Storage Copyright © 2026, Oracle and/or its affiliates 33
34. • ラックの最大までサーバーを追加 • 4 x X11M DB Server (3 TB) • 3 x X11M HC Storage • 2 x X11M-Z DB Server • 3 x X11M EF Storage • 3 x X11M-Z HC Storage Exadata X11M 混在および一致の例（続く） Copyright © 2026, Oracle and/or its affiliates 34
35. • OECA、「Rack Information / Select the Rack Generation」の下に4つのオプション: - “X11M (512GB DB)”:ラック内配線が512GB構成用に最適化 - “X11M (1.5TB DB)”:ラック内配線が1.5TB構成用に最適化 - “X11M (2.25TB DB)”:ラック内配線が2.25TB構成用に最適化 - “X11M (3TB DB)”:ラック内配線が3TB構成用に最適化 - X11M-Zサーバーの場合、"X11M(512GB)"を使用 • OECA、「Rack Information / Database Server Generation 」の下に5つのオプション: - “Exadata X11M DB (512G)”: database server with 512GB memory - “Exadata X11M DB (1.5T)”: ”: database server with 1.5TB memory - “Exadata X11M DB (2.25T)”: database server with 2.25TB memory - “Exadata X11M DB (3T)”: database server with 3TB memory - “Exadata X11M-Z DB”: database server with 768GB or 1.125TB memory • CPQ/コンフィギュレータは、前述の選択をどのようにハンドルするか？ - 選択したデータベース・サーバーに基づいて、バックグラウンドで自動的に処理。 CPQでは、OECAのようにラック・タイプのオプションは無い - Exadataシステムは、選択したデータベース・サーバーに適したラック内配線で出荷 ラックの電源に関する考慮事項 Copyright © 2026, Oracle and/or its affiliates 35
36. Q: OECAを使用してExadata構成をモデル化する必要があるのはなぜです か？ - OECAは、エラスティック構成のスコープ設定および分析を容易にすることに加えて、 電力要件、PDUサイズ、重量配分などのExadata構成も検証するため Q: OECAで購入するExadata構成をモデル化する必要がありますか？ - Yes, you must.はい、必須要件です。重量、使用可能な容量、注文するPDUサイ ズ、電力および冷却の要件などに関する詳細情報を提供します。この情報により、 CPQ/コンフィギュレータでの見積と予約がスムーズに行われます。 Q: Exadata X10MおよびX11MのOECAに4つのラック・オプションがあるのはな ぜですか？以前の世代には1つのラック・オプションしかありませんでした - 異なる電力要件を持つ異なるサイズのメモリー構成でデータベース・サーバーに対応 するためです Q: 「X11M (3TB DB)」または「X11M (2.25TB DB)」ラックの使用を強制する必 要がある場合、OECAで2.25TBまたは3TBのデータベース・サーバーを「X11M (512GB DB)」ラックに追加できるのはなぜですか？ - このオプションは、Exadataシステムの購入後にのみ使用してください。512GBラックを 購入したが、後でこれらのサーバーのメモリー容量を増やす必要がある場合は、 OECAを使用して目的の構成をモデル化し、現在のラックで変更が問題ないことを確 認できます。 Q: 2.25TBまたは3TBのメモリー・データベース・サーバーを512GBまたは1.5TB のメモリー・サーバーと混在させることはできますか？ - はい、可能です。Exadataの購入から数か月または数年後、お客様の要件が変わる 可能性があり、一部のサーバーは2.25TBまたは3TBのメモリーにアップグレードする必 要があります。OECAを使用して目的の構成をモデル化し、現在のラックで問題がな いことを確認します。 Q: X11M PDU配線表は、前の世代のExadataと同じですか？ - いいえ。X11M PDU表が更新され、X11Mデータベースおよびストレージ・サーバーの 電力需要の増加が反映されます。 ラック電源に関する考慮事項- FAQ Copyright © 2026, Oracle and/or its affiliates 36
37. エラスティック構成 1. クォータ・ラック構成から開始 • 2x Exadata X11M Database Servers (X11M or X11M-Z) • 3x Exadata X11M Storage Servers (EF or HC or HC-Z) 2. Exadata X11Mデータベース・サーバーの追加(各サイズ2RU) : • 512GBメモリ構成のデータベース・サーバー(最大13台) • 1.5TBおよび2.25TBのメモリを搭載するデータベース・サーバー（最大10台） • 3TBメモリーのデータベース・サーバー（最大12台） • 768 GBまたは1.125 TBのメモリーのX11M-Zデータベース・サーバー（最大13台） 3. Exadata X11Mストレージ・サーバーの追加(各サイズ2RU): • 最大14台 HC、EF、HC-Z、XT ストレージ・サーバー • 同一ラック内でExtreme Flash、High Capacity、X11M-Z HCサーバを混在させることが可能 • XTストレージサーバは、任意のクォーターラックの有効な構成に追加可能 4. 組込みハードウェア • 2x Cisco Nexus 9336C-FX Switch (leaf), 36-port Managed QSFP28 (100GbE) switch • 1x Cisco 9348 Switch (管理ネットワークスイッチ) • 冗長化配電ユニット 5. オプションのハードウェア • 1x Cisco Nexus 9336C-FX2 Switch (spine) OECAを使用して、有効な構成、パフォーマンスおよび環境メトリックをモデル化 Exadata Database Machine X11M Copyright © 2026, Oracle and/or its affiliates Exadata X11M Elastic Examples 12x Database Servers + 7x HC Storage Servers 6x Database Servers + 13x HC Storage Servers 37
38. ストレージ拡張ラック構成 1. ベース拡張ラックから開始 • 4台構成 Exadata X11M High Capacity (HC) Storage Servers, ないしは • 4台構成 Exadata X11M Extreme Flash (EF) Storage Servers 2. Exadata X11Mストレージ・サーバーの追加(各サイズ2RU): • 最大15台 HCストレージ・サーバー • 最大15台 EFストレージ・サーバー • 最大15台 X11M-Z HC ストレージ・サーバー • Extreme Flash、大容量、およびHC-Zサーバーを同じラックに混在させることが可能 • 冗長性の最小数が適用(2x Normal Reudandancy、3x High Redundancy) 3. 組込みハードウェア • 2x Cisco Nexus 9336C-FX Switch (leaf) 36-port Managed QSFP28 (100GbE) switch • 1x Cisco 9348 Switch (management) • Redundant Power Distribution Units 4. オプションのハードウェア • 1x Cisco Nexus 9336C-FX2 Switch (spine) OECAを使用して、有効な構成、パフォーマンスおよび環境メトリックをモデル化 Exadata Database Machine X11M Copyright © 2026, Oracle and/or its affiliates Exadata X11M Storage Expansion Rack Examples 38
39. Exadata Database Server X11M and X11M-Z Copyright © 2026, Oracle and/or its affiliates X11M DB Server X11M-Z DB Server • 2x 96-コア AMD EPYC 9J25 Processors • 1x 32-コア AMD EPYC 9J15 Processors • 512 GB (16x 32 GB) / 1.5 TB (24x 64 GB) / 2.25 TB (24x 96 GB) / 3 TB (24x 128 GB) 6400MT/s DDR5 DIMMs (工場出荷時のインストール可能なオプ ション、フィールドアップグレード可能) • 768 GB (12x 64 GB) / 1.125 TB (12x 96 GB) 6400MT/s DDR5 DIMMs (工場出荷時のインストール可能なオプション、フィールドアップグレード可能) • 2x 3.84 TB NVMe Drives – expandable to 4x 3.84 TB (ホット・スワップ可能) • 2x 3.84 TB NVMe Drives – expandable to 4x 3.84 TB (ホット・スワップ可能) • One dual-port QSFP28 100G RDMA Ethernet NIC (PCIe 5.0) – 両ポートアク ティブ – RoCE Network • Two dual-port SFP28 10/25G ethernet NIC – Client Network • One dual-port QSFP28 100G RDMA Ethernet NIC (PCIe 5.0) – 両ポートアクティブ – RoCE Network • Two dual-port SFP28 10/25G ethernet NIC – Client Network 以下から最大3枚(任意の組合せ可能): • Dual port QSFP28 100G ethernet NIC (フィールド・インストール) • Dual-port SFP28 10/25G ethernet NIC (フィールド・インストール) • Quad-port RJ45 10G ethernet NIC (フィールド・インストール) 次のいずれか: • Dual port QSFP28 100G ethernet NIC (フィールド・インストール) • Dual-port SFP28 10/25G ethernet NIC (フィールド・インストール) • Quad-port RJ45 10G ethernet NIC (フィールド・インストール) • 1x ethernet port (ILOM) • 1x ethernet port (eth0) • 1x ethernet port (ILOM) • 1x ethernet port (eth0) • ホットスワップ対応冗長化電源装置およびファン • ホットスワップ対応冗長化電源装置およびファン 39
40. Exadata X11M Database Machine - storage server options Copyright © 2026, Oracle and/or its affiliates High Capacity (HC) Extreme Flash (EF) X11M-Z High Capacity (HC-Z) X11M Extended (XT) • 2x 32-core 5th Generation AMD EPYC processors • 2x 32-core 5th Generation AMD EPYC processors • 1x 32-core 5th Generation AMD EPYC processors • 1x 32-core 5th Generation AMD EPYC processors • 256 GB DDR5 Memory • 256 GB DDR5 Memory • 192 GB DDR5 Memory • 256 GB DDR5 Memory • 1.25 TB Exadata RDMA Memory • 1.25 TB Exadata RDMA Memory • 576 GB Exadata RDMA Memory • none • 2x 480 GB M.2 SSD NMVe • 2x 480 GB M.2 SSD NMVe • 2x 480 GB M.2 SSD NMVe • 2x 480 GB M.2 SSD NMVe • 12x 22 TB 7200rpm hard disk drives • 4x 30.72 TB capacity-optimized NVMe Flash Cards • 6x 22 TB 7200rpm hard disk drives • 12x 22 TB 7200rpm hard disk drives • 4x 6.8 TB F680 NVMe PCIe5.0 Flash Cards • 4x 6.8 TB F680 NVMe PCIe5.0 Flash Cards • 2x 6.8 TB F680 NVMe PCIe5.0 Flash Cards • 2x 6.8 TB F680 NVMe PCIe5.0 Flash Cards • 1x dual-port QSFP28 100Gb/s RDMA Network Fabric Adapter • 1x dual-port QSFP28 100Gb/s RDMA Network Fabric Adapter • 1x dual-port QSFP28 100Gb/s RDMA Network Fabric Adapter • 1x dual-port QSFP28 100Gb/s RDMA Network Fabric Adapter 40
41. ネットワーク・アーキテクチャ Copyright © 2026, Oracle and/or its affiliates 41
42. ネットワーク・アーキテクチャ ネットワークおよびインタフェース • 管理ネットワーク • PDUおよび管理スイッチに接続 • 管理スイッチを介してすべてのデータベースサーバーとストレージサーバーの専 用の管理ポートとILOMポート、および各RDMAネットワーク・ファブリック・ス イッチの管理ポートに接続 • クライアント・ネットワーク • すべてのデータベース・サーバーに物理的に接続 • インタフェース名：BONDETH0 • プライベート・ネットワーク • (RDMAネットワーク・ファブリック、RoCEネットワークとも呼ばれる) • RDMAネットワーク・ファブリック・スイッチのペアを使用して、 すべてのデータベース・サーバーおよびストレージ・サーバーを相互接続 • 各サーバーでは、1つのポートが各スイッチに接続され、 スループットと可用性を最大化 • オプション • データベース・サーバーは、管理ネットワークおよびクライアント・ネットワークで 使用されていない使用可能なオープン・ポートを使用して、 追加のネットワークに接続可能 • 最初の追加ネットワークの結合インタフェース名：BONDETH1、 2番目の追加ネットワークの結合インタフェース名：BONDETH2 42 Copyright © 2026, Oracle and/or its affiliates
43. RDMA over Converged Ethernet (RoCE) ネットワークアーキテクチャ Copyright © 2026, Oracle and/or its affiliates 43
44. • RDMA は Exadata のハイパフォーマンス・アーキテクチャーを実現するための不可欠の要素 • 大規模なデータ転送のための高いスループットと低いCPU利用率 • 他に類を見ない Direct-to-Wire Protocol により、OLTP処理の際のクラスタ間のメッセージングを3倍高速に転送 • 他に類を見ない Persistent Memory Commit Accelerator の機能により、redoログの書き込みレイテンシーを削減 し、OLTPのパフォーマンスを向上 • 他に類を見ない RDMA protocol により、ノード間の トランザクションを調整 • Exadata RoCE は RDMA の速度と可用性をイーサーネット・ファブリック上で提供 • X11M と PCIe 5.0 で100Gb/s active-active バンド幅 を提供 • ゼロ・パケット・ロス・メッセージング • 重要なデータベース通信の優先順位付け • 最新のKVMベースの仮想化 • ストレージのトラフィックを Secure Isolation 機能でセキュアに分離 Exadata X11M RDMA ネットワークファブリック Copyright © 2026, Oracle and/or its affiliates 44
45. • RDMA over Converged Ethernet とは Ethernet 上で InfiniBand RDMA ソフトウェアを実行するプロトコル • network protocol stack の上位層では同一のソフトウェア • InfiniBand packet が下層レイヤでは ethernet UDP packet として送ら れる • Exadata の RoCE はEthernet ファブリック上で RDMA のスピードと可用性を提供 • 100Gbps リンクスループット • 重要なデータベースメッセージの優先付け • ゼロ・パケット・ロス・メッセージング • Open Consortium により規定され、open-source Linuxで開発 • InfiniBand Trade Association (IBTA) • 主要な network card と switch ベンダーが賛同 RoCE – RDMA over Converged Ethernet Copyright © 2026, Oracle and/or its affiliates 45
46. • DB アルゴリズムに対応した「遅延に敏感なネットワーク」の優先付け • 低い遅延が求められるメッセージが、大量データメッセージにより遅れが生じ ない事を確実にする - 例: クラスタハートビート, トランザクションコミット, cache fusion • 大量データの例：バックアップ、レポーティング、バッチ • RoCE Class of Service (CoS) • 複数の service 階層(Class of Service)でパケットが送信できるため, 独立性のためにそれぞれに別のネットワークバッファを割り当て • IEEE 802.1p にて標準化 • Exadata は各 Database メッセージごと最も最適な Class of Service を独自に選 定 Exadata X11M RoCE – 優先付けネットワーキング Class of Serviceごと別 の送信バッファ Switch Buffers Switch Buffers Network Switch 優先度の 高い メッセージ 優先度の 低い メッセージ Copyright © 2026, Oracle and/or its affiliates 46
47. • パケットロスの発生する理由 輻輳により発生 • パケットが受信側あるいはスイッチが処理できる能力を超えて送信側が高速に送ら れる場合に発生しやすい 受信側は受信側のキャパシティを超えるとパケットドロップが発生 • 頻度の低い問題 – switch 故障, リンク故障 • 従来の Ethernetでは、送信が早すぎる場合は、通知無くパケットを破棄して、再送が期 待されている • パケット破棄は遅延とスループットに大きな影響を及ぼす • Exadata RoCE はパケット破棄の回避(reliable)を実現のため下記をLayer2で実装: - RoCE Explicit Congestion Notification (ECN)（明示的輻輳通知） - RoCE スイッチはパケットの送信が早すぎるとマーク。 RDMA ネットワークカードは ECN を読み込み、CNP(Congestion Notification Packet) を送信 して送信側に送信速度を下げるように通知 - RFC3168 - RoCE Rx Priority-based Flow Control (RxPFC)（優先キュー毎のフロー制御） - RoCE switch は Rx Pause frame （受信ポーズフレーム）を守るが、 Tx Pause frame（送信ポーズフレーム） は送信しない - 802.1Qbb Exadata X11M RoCE – パケットロスを回避するための実装 Network Switch Buffer が Full なので一時停止 Class of Service ごと別 の送信バッファ Switch Buffers Switch Buffers Copyright © 2026, Oracle and/or its affiliates 47
48. • Exadata は RoCE VLAN によりネットワークパケットは他のテナントから見ることを防止 • VLAN tag はネットワーク switch で強制される • Security がソフトウェアの脆弱性やサーバーの誤った構成で迂回されてしまう事が不 可能 • Database と Storage は独立した VLAN で占有 Exadata X11M RoCE-テナント分離 Tenant 1 Database and Storage Tenant 2 Database and Storage Copyright © 2026, Oracle and/or its affiliates 48
49. Exadata Database Server – KVM Host 1 Exadata Database Server – KVM Host 2 Exadata System Software 20.1以降(X8M以降)で使用可能 RoCEシステム用のExadata Secure Fabricは、 一般的なExadata Storage Serversへのアクセスを許可しながら、仮想マシン のネットワーク分離を実装 • 各Exadata VMクラスタにはプライベート・ネットワークが割り当てられる • VMは相互に通信不可能 • すべてのVMは共有ストレージ・インフラストラクチャと通信可能 • セキュリティはバイパス不可能 • ネットワーク・カードによりすべてのパケットへセキュリティを強制 • ハイパーバイザによって自動的にセキュリティ・ルールがプログラム • すべてのExadata Cloudデプロイメント*で使用中 Exadata Secure RDMA Fabric Isolation Copyright © 2026, Oracle and/or its affiliates 49 すべての新規デプロイメントに対して デフォルトで推奨され選択済（Exadata 25.1〜） * Exadata Cloud@Customer、Exadata Cloud InfrastructureのX8M以降 のすべての新しいデプロイメントが含まれる Cluster1 VM2 Cluster2 VM1 Cluster1 VM1 Cluster2 VM2 Storage Servers Cluster1 Secure Fabric Network Cluster2 Secure Fabric Network Secure Fabric Storage Network Secure Fabric Storage Network Secure Fabric Storage Network Secure Fabric Storage Network Exadata 20.1 〜
50. • Open Security • すべてのデータベース・クライアントがすべてのグリッド・ディ スクにアクセス可能 • 従来のデフォルト • ASM-Scoped Security • Oracle ASMクラスタに関連付けられたOracle ASMディス ク・グループによって使用されるグリッド・ディスクにのみアク セスを制限可能になる - Oracle ASMクラスタに関連付けられているすべてのOracle Databaseインスタンスが、ディスク・グループおよびそのディスクグ ループを構成するグリッド・ディスクにアクセス可能 - 異なるOracle ASMクラスタに属するディスク・グループで使用さ れるグリッド・ディスクには、これらのインスタンスからアクセス不 可能 • ExaDB-D Multi-VM から使用 [参考] ASM-Scoped Security Copyright © 2026, Oracle and/or its affiliates 50 ASM-Scoped Security ASM Cluster2 VM VM Private Network ・・・ ・・・ ・・・ cell01 cell02 cell03 1 db01 db02 2 ASM Cluster1 VM VM
51. RoCE ネットワークファブリックスイッチ • Cisco Nexus 9336C-FX2 QSFP28 (100GbE) Ethernet Switches • デプロイ、保守、およびアップグレードを容易にする統合ファブリックとしてイーサネッ トを使用するネットワークインフラストラクチャを提供 • 損失を許容しない信頼性の高いイーサネットワークロードを管理 • ラック内のサーバーの冗長接続のために、ラックごとに2つのリーフスイッチが標準で装備 • ExadataラックをRoCE経由で他のラックに接続する場合は、ラックごとに1つのスパインス イッチが必要 • 注文プロセスで選択すると、工場でインストール • 注文プロセス後に選択すると、フィールドでインストール Exadata X11M RDMA ネットワークファブリック Copyright © 2026, Oracle and/or its affiliates 54
52. • Exadata Database Server と Storage Servers • 各X11M Database Server と X11M Storage Server は 100Gb/s RoCE Network Cards; PCIe Gen5を装備 • Active-Active Bonding – アダプター毎に2つのIPアドレスがアサイン • アダプターの1ポートから1つのリーフスイッチへ接続され、他のポートが2台目のリーフスイッチに接続される （冗長化のため） • ケーブリングは工場出荷時に実施済 Exadata X11M RDMA ネットワークファブリック Copyright © 2026, Oracle and/or its affiliates 55
53. Exadataラック内のRoCE ネットワークファブリックスイッチケーブリング 各サーバーの RoCE NIC は冗長性のため両 方のリーフスイッチに接続 8 x Lower leaf switch Upper leaf switch Port 1 of Servers Port 2 of Servers Copyright © 2026, Oracle and/or its affiliates 56
54. マルチラック接続 Copyright © 2026, Oracle and/or its affiliates 57
55. • すべての接続されたラック間で1つの RDMA Network Fabric Network を構成 • VXLAN BGP EVPN を用いてラックをClosトポロジーで接続 • 12 Racks まで追加外部スイッチ無しに接続（X9M〜） • すべてのリーフスイッチのアップリンクはそれぞれのスパインスイッチに接続 • Leaf スイッチは他の Leaf スイッチには接続しない、同様にSpineスイッチは他のSpineスイッチには接続しない • Exadata Database Server と Storage Server のケーブリングは変更無し • ラック間接続はインストール時に実施される • Database Machine racks は標準構成では3台目のspine switch は含まれない • マルチラック構成でラック間接続する際にspineスイッチ (Expansion Switch Kit) のインストールが必要 • ラック間ケーブルは適切な長さのケーブルが必要 • 距離に応じて銅線、ないしは光ケーブルが必要 • 正確なポートマッピングはDatabase Machine Owner’s Guide を参照 Exadata X11M RDMA Network Fabric Multi-rack Copyright © 2026, Oracle and/or its affiliates 58
56. • 各ラックに Spine Switch (SS) をインストール • Upper Leaf (UL) と Lower Leaf (LL)間のスイッチ間リンクを取り外し • 各リーフスイッチとスパインスイッチを接続 (ペアあたり7 links) RDMA Network Fabric Multi-rack – 2ラック (Clos) Topology 7 x 7 x 7 x 7 x 7 x 7 x 7 x 7 x R1 UL R1 LL R2 UL R2 LL R2 SS R1 SS RACK 1 RACK 2 EXADATA X9M 〜 の変更点 200 G/sec バンド幅のため、 リーフスイッチからスパインス イッチへのアップリンクは従 来の4本から7本に増加 Copyright © 2026, Oracle and/or its affiliates 59
57. • 各ラックに Spine Switch (SS) をインストール • Upper Leaf (UL) と Lower Leaf (LL)間のスイッチ間リンクを取り外し • 各リーフスイッチからの 14 links を各スパインスイッチへ分散して接続 • 例: 7 ラックの場合 – 各リーフから2リンクをスパインスイッチへ接続 RDMA Network Fabric Multi-rack – 最大8ラックまで (Clos) Topology R1 UL R1 LL R1 SS R2 UL R2 LL R2 SS … … R8 UL R8 LL R8 SS RACK 1 RACK 2 RACK 8 EXADATA X9M 〜の 変更点 Copyright © 2026, Oracle and/or its affiliates 60
58. • 最初の8ラックに Spine Switch (SS) をインストールされていることを確認 • Upper Leaf (UL) と Lower Leaf (LL)間のスイッチ間リンクを取り外し • 9ラック目からnラック目までの各リーフスイッチからの 14 links を最初の8ラックのスパインスイッチへ分散して接続 RDMA Network Fabric Multi-rack – 9ラックから12ラック (Clos) Topology R1 UL R1 LL R1 SS R8 UL R8 LL R8 SS … … Rn UL Rn LL RACK 1 RACK 8 RACK n EXADATA X9M 〜の 変更点 Copyright © 2026, Oracle and/or its affiliates 61
59. • 目的 • マルチラック時のラック間接続のスパインスイッチが必要 • ラック間接続にラック毎に1台必要 - ”Quarter to Quarter” のマルチラック構成含む • 含まれる物 • Cisco Nexus 9336C-FX2 Ethernet Switch ラック内スパインスイッチとして利用 RDMA Network Fabric Multi-rack – Expansion Switch Kit Copyright © 2026, Oracle and/or its affiliates 62
60. • 3m copper cables ラック内接続用（例：同一ラック内スイッチ接続用） • 5m copper cables 1台目、ないしは2台目の隣のラック間スイッチ接続用 • 床上げ環境、同一列内のラック、物理的に隣り合っていることを前提 • 他のすべての場合、10m以上のケーブル（光ケーブル必須） • 4ラック以上のマルチラック環境では長い光ケーブルが必要 • 10m cables は通常8台までの物理的に隣り合った同一列、床上げ環境での十分な長さ RDMA Network Fabric Multi-rack – ケーブル長 疑わしきは計れ！ Copyright © 2026, Oracle and/or its affiliates 63
61. ネットワークアーキテクチャ 管理 ネットワーク Copyright © 2026, Oracle and/or its affiliates 64
62. • ラック毎にプリインストールされ、配線された 1台の Cisco 9348 Ethernet Management Switch • 各サーバーのハードウエア管理ポートに接続 - Storage Servers の ILOM port - Database Servers の ILOM port • 各サーバーのソフトウェア管理ポートに接続 - Storage Servers の eth0 - Database Servers の eth0 - ソフトウェア管理、rootアクセスなど • RDMA Network Switch management ports に接続済 • 管理スイッチはお客様コストでお客様の管理スイッチにリプレース可能 • スイッチリプレースメントの制限事項については後述のexpansion options presentation を参照 Exadata X11M 管理ネットワーク – 内部接続 Management switch Database Server (ILOM) Database Servers (mgmt port) Storage Servers (ILOM) Storage Servers (mgmt port) RoCE Switch (mgmt port) Copyright © 2026, Oracle and/or its affiliates 65
63. • 管理スイッチ上のRJ45 の1つのポートが データセンターの管理ネットワークに接続可能 • 追加で 2x optical 40/100 GbE QSFP28 ports と 4x Optical 10/25 GbE SFP28 ports が データセンターの管理ネットワークへの冗長化アップリンクとして 利用可能 • アップリンク実装のために Cisco Nexus 9300 platform switch documentation を確認すること • 各PDUの1つのネットワークポートが直接データセンターの 管理ネットワークに接続 • 代替手段として、管理スイッチ上の空きポートを接続として利 用可能 - 47番ポート以下の空きポートの利用を強く推奨 - 必要に応じて、未使用のポート47以下から作業 Exadata X11M 管理ネットワーク – 外部接続 Management switch To Data Center Network Database Server (ILOM) Database Servers (mgmt port) Storage Servers (ILOM) Storage Servers (mgmt port) RoCE Switch (mgmt port) Copyright © 2026, Oracle and/or its affiliates 66
64. ネットワークアーキテクチャ サービスネットワーク Copyright © 2026, Oracle and/or its affiliates 67
65. • IPv4 および IPv6 接続サポート • Database Server と Storage Server はIPv6 を管理ネットワーク、ILOM、 クライアントネットワークに利用可能。ベアメタル、仮想環境で利用可能 • データベースへのクライアントアクセス、アプリケーションアクセス • マシン上部2Uの空きスペースにお客様のtop of rack switch の搭載が可能 • ラック上部がStorage Server に専有されていないことを確認 • 各DB Server の最低1つのイーサーネットポートの接続が必要 • X11M Database Server は以下のポートが外部接続に利用可能 - 2 x dual-port SFP28 10/25G ethernet NIC – クライアント・ネットワーク(デフォルト・工場インストール) - 以下から最大3枚(任意の組合せが可能): • Dual port QSFP28 100G ethernet NIC (フィールド・インストール) • Dual-port SFP28 10/25G ethernet NIC (フィールド・インストール) • Quad-port RJ45 10G ethernet NIC (フィールド・インストール) - X11M-Zでは上記から1枚 データベースワークロードのための外部接続性 Copyright © 2026, Oracle and/or its affiliates 68
66. Virtual Local Area Network サポート • システム上のスイッチポート数を削減 • OEDA は管理ネットワーク、ILOM、クライアントネットワーク、バックアップネット ワークへのVLAN設定が可能 • VLANタギングは、VLANが複数のスイッチにまたがる場合にのみ必要 • 同じネットワークカードを介して、ディザスタリカバリネットワークとクライアントアクセ スネットワークの間にQoSを提供 • VMによるVLANタギングは、異なるVM間でクライアントネットワークを分離 データベースワークロードのための外部接続 VLAN1 VLAN3 VLAN2 VLAN4 Copyright © 2026, Oracle and/or its affiliates 69
67. Virtual Local Area Network (VLAN)サポート Copyright © 2026, Oracle and/or its affiliates 70 • OEDAでは、管理ネットワーク、ILOM、クライアントおよびバックアップ・アクセス・ネットワークのために、計算ノードおよびス トレージ・サーバーでのVLANの作成をサポート • クライアント・ネットワークとバックアップVLANネットワーク・ネットワークはbonding必要。管理ネットワークはbondingし ない • バックアップ・ネットワークが、タグVLANネットワーク上にある場合、クラスタ・ネットワークは、異なるタグVLANネット ワークにある必要がある • バックアップおよびクライアント・ネットワークは、同一のネットワーク・ケーブルを共有可能 • OEDAは物理デプロイメントと仮想デプロイメントの両方でタグVLANをサポート • IPv6 VLANは、X2およびV2システムを除くすべてのOracle Exadataシステムのベア・メタルでサポート • 現在、VMを使用したIPv6 VLANはサポートされていません。 • Oracle Exadata System Softwareリリース12.2.1.1.0では、Oracle Exadata Deployment Assistant (OEDA)を使用 してIPv6 Oracle VMおよびタグ付き仮想LAN (VLAN)がサポート • IPv6 VLANが、管理ネットワーク上でサポート
68. IPv6 support status on Exadata Database Machine (KB608858 Doc ID 2056895.1) Migrating IPv4 to IPv6 on Exadata Database Machine (KB159889 Doc ID 2056690.1) • 管理ネットワーク：IPv4 ないしは IPv6 をサポート • クライアントネットワーク：IPv4 とIPv6 を同時サポート・どちらかのサポートを可能（KB159889に従う） • InfiniBand / RoCE ネットワーク：IPv4 のみをサポート（IPv6非対応） IPv6 サポート Copyright © 2026, Oracle and/or its affiliates 71
69. 可用性（ネットワーク関連） Copyright © 2026, Oracle and/or its affiliates 72
70. • Exadataは、ノード間で頻繁にハートビートメッセージを使用し、 サーバー障害の可能性を検出 • 通常、サーバー障害の検出では長いタイムアウトを設定し、 誤検知によるクラスターからのサーバー除外を回避 • ハートビートへの応答が遅い原因が、 CPUが非常に高負荷だからなのか、 サーバー障害によるものなのかをすぐに区別するのは難しい • ExadataはRDMAを利用してサーバー障害を高速に確認 • RDMAはH/Wを使用するので、S/Wが遅くてもリモート・ポートは応答 • RDMA読込みが4回行われ、障害の可能性のあるサーバーに対し、 送信元とターゲット・ポートのすべての組合せで送信 • 4回のRDMAが失敗すると、サーバーはクラスタから除外 RoCE環境でのInstant Failure Detection NIC Port #2 RDMA NIC Port #2 NIC Port #1 NIC Port #1 完全に自動的かつ透過的 Copyright © 2026, Oracle and/or its affiliates 73 Exadata 19.3.0 〜
71. Improved RoCE Network Resilience Exadata RoCE IPは高可用性が必要 • 各サーバーには、異なるリーフ・スイッチに接続された デュアル・ポートのRoCE NICがある オペレータ・エラーにより、リーフ・スイッチのRoCEポートが暗 黙的に無効化され、ネットワーク・トラフィックが停止する 場合がある • データベースの停止が発生 ExaPortMonプロセスがホスト上で実行され、両方のRoCE ポートのライブ・トラフィックを監視 • ストールが検出された場合、IPを稼働可能なポートに移行 • アップストリームの問題が解決されたときに、IPを元のポートに 戻す RoCEネットワークのレジリエンスの向上 Copyright © 2026, Oracle and/or its affiliates 74 Leaf Switch Leaf Switch Spine Switch 192.168.1.1 192.168.1.2 オペレータの 構成エラー Exadata 24.1 〜
72. ExadataでのOracle RAC Cache Fusionの最適化 Copyright © 2026, Oracle and/or its affiliates 75
73. RDMA(メッセージベースのプロトコル)によるパフォーマンス向上 ExadataでのOracle RAC Cache Fusionの最適化 Copyright © 2026, Oracle and/or its affiliates インメモリー・コミット・キャッシュからのUNDOブロックのRDMA読取り カレント・データ・ブロックとトランザクション・ヘッダーのRDMA読取り グローバル・キャッシュの付与後、カレント・リモート・データ・ブロックのRDMA読取りは、10マイクロ秒以下で実施されるメッセージングより 20倍高速に実行 インメモリー・コミット・キャッシュからのRDMA読取り: LMSによって管理されるバッチ・メッセージではなく、トランザクションIDでのRDMAリモート読取り LMSは、一貫性読取りをさらにスケーリング LMSは、コミットされたトランザクションをクリーン・アウトし、現在のブロックをリクエスト元のデータベース・プロセスに返す。 データベース・プロセスは、UNDOブロックRDMA読取りを使用して、リクエストされたSCNの後に変更をロールバック 19c 21c 26ai 26ai 76
74. さまざまなパフォーマンス最適化 • Exafusion • ゼロ・コピー・ブロック送信 • Undo ブロックのRDMA 読み取り • インメモリ・コミット・キャッシュ • 共有データ・ブロックおよびUNDO ヘッダーのRDMA 読み取り • Broadcast-on-Commit Over RDMA • Optimized Object Checkpoints 77 Copyright © 2026, Oracle and/or its affiliates
75. • RAC のキャッシュ・フュージョンを InfiniBand/RoCE 向けに再構成 • OS カーネルを通さずにユーザー空間から 直接通信する仕組みを実装 • Oracle Database に最適化 Exafusion Copyright © 2026, Oracle and/or its affiliates 78 Exadata 12.1.2.1.1 〜 InfiniBand/RoCE 8K OLTP Block Transfers/sec InfiniBand / RoCE Exafusion InfiniBand / RoCE 10 GigE OLTP処理を3 倍高速化
76. Exafusion • 従来のノード間通信 • Oracle RAC のメッセージングは、ネットワーク・ソケットを利用した一般的なネットワーク・モデルを使用して実装 • このネットワーク・モデルでは、すべての通信（送受信）が OS カーネルを経由するため、Oracle RAC インスタンス間でメッセージが交換されるたびに、 ユーザー空間と OS カーネル空間との間でコンテキスト・スイッチとメモリのコピーが必要 • Exafusion • RoCE構成とInfiniBand構成のExadataにおいて、Oracle Database 12c以降で提供される次世代ネットワーク・プロトコル • OS カーネル空間を完全にバイパスしてユーザー空間から direct-to-wire プロトコルでの通信を実現 • コンテキスト・スイッチと OS カーネルのオーバーヘッドを排除することで、往復のメッセージを30 µs（マイクロ秒）未満で処理 • RAC を汎用サーバー上で動作させる従来型のソ ケット通信ベースの実装よりも5倍高速 • Exafusionではメッセージの送受信に関連するCPUコストも低減されるため、キャッシュ・フュージョンのバックグラウンド・プロセス（LMS プロセス）あたり のブロック転送スループットを向上させ、より多くの処理が可能に • メッセージングの高速化は、通常のアプリケーション・パフォーマンスにとって有益なだけではなく、Oracle RACのあらゆる処理を高速化 - ロックの動的なリダイレクト （DRM） - インスタンスや PDB メンバーシップの変更に伴う Oracle RAC の再構成 - インスタンス・リカバリなど • Exafusion の採用は、Zero Copy Block Sends や RDMA の導入など、後述する Exadata 上の RAC のパフォーマンス最適化に おける基盤 • Exafusion および本書で説明する最適化では、追加の OS リソースは不要 79 Copyright © 2026, Oracle and/or its affiliates
77. ゼロ・コピー・ブロック送信 Zero Copy Block Sends • ゼロ・コピー・メッセージングがサポート • RoCE と InfiniBand ネットワーク・アダプタで対応 • ユーザー空間にあるバッファは、HCA（ホスト・チャネル・アダプタ）に登録され、 HCAはユーザー空間にあるバッファの中身を直接通信層に渡すことが可能に • 従来型のメッセージング・プロトコル（OS カーネルが、最初にユーザー空間にあるバッファのコピーを作成、そのコピーを通信層に 渡す）とは異なる • Exadata上のRACのキャッシュ・フュージョンの転送速度が最適化 • バッファをコピーするために必要なCPUサイクルを排除 80 Copyright © 2026, Oracle and/or its affiliates
78. Undo ブロックの RDMA 読み取り Undo Block RDMA Reads • Exadata 上の RAC での Undo ブロック送信は、トランザクションのロールバックなどが発生した際に他の Oracle RAC イン スタンスから UNDO ブロックを取得する必要がある場合、従来のメッセージベースのプロトコルの代わりに、RDMA ベース の転送プロトコルを使用するように最適化 • RDMAを活用することで、フォアグラウンド・プロセスはリモートインスタンスのプロセスを介さずにリモートインスタンス のSGAからUNDOブロックを直接読み取ることが可能に • サーバー側処理（CPU）とコンテキスト・スイッチのオーバーヘッドが排除（非Exadata環境のRACで発生） • 高負荷時やクラスタが不安定な状況であっても、一貫して低く予測可能な読み取りレイテンシを確保 - UNDOブロックの転送が、リモートインスタンス側のプロセス混雑や全体的なCPU負荷の影響を受けなくなるため • RDMAベースの読み取りは通常10マイクロ秒未満で完了、 メッセージベースのプロトコルで達成される最良のレイテンシと比較して、約3倍の性能向上を実現 82 Copyright © 2026, Oracle and/or its affiliates
79. インメモリ・コミット・キャッシュ In-Memory Commit Cache • 一部のワークロードでは、「undo header」ブロック転送が大量に発生 • 従来は、各リモートXIDの状態を確認するために、リモートの「undo header」ブロック参照が必要 • インメモリ・コミットキャッシュは、トランザクションの状態を追跡するためにSGA内に保持される小さなキャッシュ。 クライアントはLMSに対して、複数のXID（最大30件）の状態を問い合わせるメッセージを送信 • LMSは、要求されたXIDの状態をまとめたバッチメッセージで応答 • これにより、LMSへの繰り返しのラウンドトリップが不要となり、LMSの負荷が軽減 83 Copyright © 2026, Oracle and/or its affiliates Instance 2 Buffer Cache Instance 1 XID#1: 0x0146.019.00002995 XID#2: 0x0026.008.00003204 XID#3: 0x008b.011.00003477 XID#4: 0x001e.00c.00003e53 FG LMS Original Protocol: 4x “gc cr block 2-way” waits Instance 2 Commit Cache Instance 1 XID#1: 0x0146.019.00002995 XID#2: 0x0026.008.00003204 XID#3: 0x008b.011.00003477 XID#4: 0x001e.00c.00003e53 FG LMS Commit Cache: single “gc transaction table” wait
80. インメモリ・コミット・キャッシュ In-Memory Commit Cache • Exadataではインメモリ・コミット・キャッシュを実装 • 長時間実行されるバッチ処理や同時実行クエリを持つアプリケーションでは、「undo header」のコンシステント・リード（CR）ブロッ ク転送が大量に発生することがあり、これに対処するため • この機能により、各インスタンスはローカルトランザクションの状態（コミット済みかどうか）をSGA内にキャッシュとして保持し、他の インスタンスからリモート参照可能に - このリモート参照は、インスタンス間で8KBのundoヘッダブロックを転送するよりも大幅に高速 • 複数のトランザクションID（XID）の状態を1回のメッセージで確認できるため、以下を削減 - RACメッセージの往復回数 - コミット・キャッシュ参照リクエストを処理するLMSプロセスのCPU負荷 • インメモリ・コミットキャッシュでは、最大30個のXID参照を1回のラウンドトリップメッセージにまとめることが可能 • 従来は30回必要だった8KBブロック転送を置き換える • この最適化の結果、undoヘッダ転送に関連する「gc cr block 2-way」待機イベントの多くは、より少ない「gc transaction table 2- way」待機イベント（Oracle AI Database 26ai以前のリリースでは「gc transaction table」と呼ばれていた）に置き換えられることが期 待される • 現在の「gc transaction table 2-way」待機は、1回のメッセージで複数のXIDをまとめて参照する処理を表す 84 Copyright © 2026, Oracle and/or its affiliates
81. 共有データブロックおよびUNDOヘッダのRDMA読み取り Shared Data Block and Undo Header RDMA Reads • Cache FusionにおけるRDMAサポートが、データブロック、スペースブロック、UNDOヘッダブロックの読み取りにも対応が拡張 • Oracle Database 21c以降 • LMSのCPU使用率もさらに削減 - この機能強化により、 UNDOブロックのRDMA読み取り最適化と同様に、他インスタンスにキャッシュされたデータへのアクセスが高速化され、RDMA経由でデータを読み取 る際にはLMSプロセスが関与しないため、 • 従来のプロトコル • フォアグラウンドプロセスがブロックを読み取る必要がある場合、ディレクタインスタンスにリクエストを送信 • ディレクタはそのリクエストをホルダーインスタンスに転送し、最終的にホルダーが応答するという、3ウェイのCache Fusion転送（「gc current block 3- way」）が実行される • このパターンは、特に3ノード以上の大規模クラスタにおける読み取り中心のOLTPワークロードで一般的 • このような環境では、各インスタンスのキャッシュが相対的に小さくなるため、必要なデータがローカルに存在する可能性は低い一方で、クラスタ内の どこかにキャッシュされている可能性は高くなる • RDMAベースのプロトコル • RDMAを活用したデータブロックおよびスペースブロックの読み取りでは、 ディレクタインスタンスはリクエスト元に対してロック許可（読み取り権限）と、対象ブロックを保持しているホルダーインスタンスの情報を返す • その後、リクエスト元のフォアグラウンドプロセスは、RDMAを使用してホルダーインスタンスのメモリから直接ブロックを読み取ることが可能になる • ディレクタからホルダーへのメッセージ転送が不要となり、読み取りレイテンシが低減され、ホルダーインスタンス側でブロック送信が不要になり、LMSの CPU負荷も軽減される 85 Copyright © 2026, Oracle and/or its affiliates
82. 共有データブロックおよびUNDOヘッダのRDMA読み取り Shared Data Block and Undo Header RDMA Reads 従来のプロトコル Step 1: フォアグラウンド・プロセスが 要求メッセージをリソース・ディレクター・インスタンスのLMSへ送信 Step 2: ディレクター・インスタンスのLMSは その要求をリソース・ホルダーの LMS へ転送 Step 3: リソース・ホルダーの LMSは カレント・ブロックをリクエスター・インスタンスへ返信 RDMAベースのプロトコル Step 1: フォアグラウンド・プロセスが 要求メッセージを リソース・ディレクター・インスタンスの LMS へ送信 Step 2: ディレクター・インスタンスのLMSは ホルダーインスタンスの SGA からカレント・バッファを直接読み取ることを リクエスターに対し許可するメッセージを返信 Step 3: フォアグランドは ホルダーから RDMA 読み取りを実行 86 Copyright © 2026, Oracle and/or its affiliates Instance 1 (リクエスター) Step 1 Instance 2 (リソース・ディレクター) Instance 3 (リソース・ホルダー) Step 2 Step 3 Instance 1 (リクエスター) Instance 2 (リソース・ディレクター) Instance 3 (リソース・ホルダー) Step 3 Steps 1 & 2
83. 共有データブロックおよびUNDOヘッダのRDMA読み取り Shared Data Block and Undo Header RDMA Reads • RDMAベースのプロトコルでの読み取りの場合 • フォアグラウンド・プロセスでは、従来の“gc current block 3-way”待機イベントの代わりに以下の一連の待機イベントを確認 - “gc current grant 2-way” 待機イベントに続いて、 - 短い “gc current block direct read” 待機イベント - “gc current block direct read” 待機は通常10μ 秒以下であり、 上記の2つの待機イベントの合計待機時間は、従来の3-wayでの転送時間よりも短くなる • リクエスター自身がディレクター・インスタンスの場合、 - メッセージング無しにデータを読み取る許可を自分自身に付与できるため、前述の”gc current grant 2-way” 待機イベントは不要になる - この場合、一回の”gc current block direct read” 待機イベントで素早く要求を処理する - この最適化によって、2ノード・クラスタを含むOracle RACで従来発生していた”gc current block 2-way“待機の一部が置き換えられる • ローカルではないディレクター・インスタンスがホルダー・インスタンスでもあった場合、 - LMS は許可メッセージを返信して、リクエスターはホルダー（ディレクターでもある）からデータをRDMAで読み取る - この場合、ディレクターとホルダー・インスタンスが同一である点を除けば、上述した3-way のシナリオと同じであり、 従来の”gc current block 2-way”待機イベントは、 ”gc current grant 2-way”待機イベントと”gc current block direct read”待機イベントに置き換えられる - この場合、読み取り時間はそれほど改善されないが、LMS がロックを許可するコストはデータブロックを返信するよりも軽いため、 RDMA の最適化はLMS プロセスのCPU 使用量を削減する 87 Copyright © 2026, Oracle and/or its affiliates
84. Broadcast-on-Commit Over RDMA Broadcast-on-Commit Over RDMA • Broadcast-on-Commitプロトコルとは • トランザクションがコミットされる前に、すべてのクラスタインスタンス上のシステム変更番号（SCN）が少なくともコミットSCN以上になることを保証 - トランザクションに対するOracleのコンシステントリード（CR）特性を確保 • このプロトコルの動作 - LGWR プロセスは、すべてのインスタンスのLMSプロセスにSCNを含むメッセージを送信 - メッセージを受信したLMS プロセスは、自身が稼働するインスタンスのSCNを更新して、始めのインスタンス上のLMSプロセスに対してACKメッセージを返信 - Redo I/O が完了すると、LGWRはredo SCN がすべてのインスタンスによって確認応答されたか否かを確認 • 確認応答された場合、LGWRはトランザクションを待機しているフォアグラウンド・プロセスに対してコミット操作が完了したことを通知 - Redo I/O が完了するまでにredo SCN の確認応答がされなかった場合は、全てのACK が戻ってくるまでコミットは完了しない • この場合、フォアグラウンドには長い時間の“log file sync”待機イベントが表示 • Broadcast-on-CommitプロトコルがRDMAを利用するよう最適化 - Oracle Database 21c以降 - RDMAを活用することで、SCNブロードキャストは、より低レイテンシで実行され、LMSプロセスへの負荷も軽減 - 特に、SCNメッセージが通信トラフィックの大部分を占めるOLTP環境や、多数のインスタンスを持つクラスタにおいて有効 • これらのメッセージは、通常、コミット遅延の直接的な原因になることは少ない（多くの場合、REDO I/Oが支配的であるため）が、 全体のメッセージ量を削減することでLMSの負荷が軽減され、負荷スパイクへの耐性向上やスループットの向上に寄与 88 Copyright © 2026, Oracle and/or its affiliates
85. Broadcast-on-Commit Over RDMA Broadcast-on-Commit Over RDMA • 例 • 3インスタンス構成のクラスタで稼働する大規模CRM（OLTP） ワークロードにおける測定では、SCNブロードキャストが全RACメッ セージの12%を占める - SCN messages 9%、SCN ACK messages 3% • RDMAの導入により、これらのブロードキャストはLMSプロセスを介 さずに処理されるようになり、メッセージングのオーバーヘッドとCPU 使用量の双方が削減 • RDMAを利用したBroadcast-on-Commitモードでは、LGWRプロセスが アトミックなRDMA operationにより、クラスタ内の各インスタンスのSCN を直接更新 • LMSプロセスを介さずに処理が行われるため、コミットプロトコルは より高速に • コンテキストスイッチの遅延や他インスタンスのCPU負荷によるボト ルネックとなり得るLMSプロセスを排除できる 89 Copyright © 2026, Oracle and/or its affiliates その他の Cache Fusion メッセージ (88%) SCN Msgs (9%) SCN ACK メッセージ (3%) 以前のリリースでの メッセージ・トラフィックの内訳 その他の Cache Fusion メッセージ Oracle 12cでの メッセージ・トラフィックの内訳 全てのSCNメッセージ がRDMAで置き換え
86. Optimized Object Checkpoints Optimized Object Checkpoints • Exadataスマート・スキャンやパラレル・クエリ（PQ）スキャンが頻繁に発生するワークロードでは、オブジェクトのチェックポイントに関連す るパフォーマンスボトルネックが発生する可能性 • ”enq: KO - fast object checkpoint” や “reliable message”の待機時間が長くなる • 特に、非常に短いスキャンが高い多重度で実行されるアプリケーションでは、チェックポイントの要求頻度が非常に高くなるため、 この傾向が顕著 • オブジェクトのチェックポイントが必要か否かをクラスタ全体に対して素早く確認するために、高速なRDMAベースのチェック機能が追加 • Oracle Database 26ai 以降 • 対象オブジェクトに対してグローバル・キャッシュ上にダーティバッファが存在しなければ、チェックポイント処理自体を完全にスキップ 可能 • このチェックは “gc obj ckpt direct read”という待機イベントのもとで実行され、通常 10μs 秒未満で完了し、 クラスタ内のいかなるバック・グラウンドプロセスも呼び出さない • この最適化により、AI Vector Search のスキャンは非常に短時間である傾向があるため、 Oracle Database 26ai におけるベクター・データベースに対する Exadata Smart Scan のパフォーマンスが大幅に向上 - 社内検証により、この機能が AI Vector Search ワークロードにおけるオブジェクトのチェックポイントの 99% を排除できる ことが確認 90 Copyright © 2026, Oracle and/or its affiliates
87. Exadata RDMA Memory (XRMEM) Copyright © 2026, Oracle and/or its affiliates 91
88. 驚異的なパフォーマンスを実現するRemote Direct Memory Access (RDMA) RDMA • OSやCPUを関与させずに、直接リモートのコンピュータのメモリーへのアクセスを可能にする技術 • ネットワーク・カードは、追加のコピーやバッファリングなしに非常に短い待機時間でメモリーに直接読み書き RDMAはExadataに不可欠な要素 • 大規模なデータ転送のための高スループットおよび低CPU使用率 • 独自のDirect-to-Wireプロトコルにより、ノード間OLTPクラスタ・メッセージングが3倍高速化 • ノード間のトランザクションを調整するための独自のRDMAプロトコル Exadata Storage Server RDMA Exadata Database Server RDMA Exadata Database Server RDMA Copyright © 2026, Oracle and/or its affiliates 92
89. Exadata RDMA Memory (XRMEM) RDMA 技術を革新的に実装した Exadata • 利用目的: storage server の共有メモリキャッシュアクセス • 読み取りのメモリスピード – flash よりもさらに高速 • 共有キャッシュはすべてのデータベース群から利用可能 • ミラーを複数の storage server に渡り行い可用性実現 より高速 GB当たりのコストが上昇 Exadata RDMA Memory パフォーマンス最適化フラッシュ Disk 容量最適化フラッシュ Copyright © 2026, Oracle and/or its affiliates 93
90. Exadata RDMA Memory (XRMEM) Unique: shared memory optimized for Oracle Database • Exadata Storage Serversは、フラッシュ・メモリーの前に XRMEM Data Acceleratorを透過的に追加 • Exadata X9Mと比較して1秒当たり21%高いI/O: 2,520万IOPS • データベースは、通常のI/OのかわりにRDMA I/Oを使用してリモート XRMEMを読み取り • ネットワーク、I/Oソフトウェア、割り込み、コンテキスト・スイッチをバイパス • Exadata X7と比較してレイテンシが17倍改善: 8KBデータベースの読取りではレイテンシーが14マイクロ秒まで短縮 • XRMEMはデータベース全体で自動的に階層化および共有 • 最もホットなデータのキャッシュとして使用することで、 有効容量が10倍向上 • キャッシュ・データは、フォルト・トレランスのためにStorage Server間で 自動的にミラー化 Enabled with Oracle Database 19c and newer Database Server Hot XRMEM Cold Disk Warm Flash Cache Storage Server RoCE / RDMA Copyright © 2026, Oracle and/or its affiliates 94
91. • 効率的 – 実際に利用されるデータだけがXRMEMへ • 適応力 – 結合したXRMEM性能がstorage server群で発揮され、動的にすべてのDB serverで利用可能 • 安全 – XRMEMはdatabase access controls経由でのみ利用可能, OS またはlocal accessは不可能 • シンプル – 追加管理不要、構成のチューニング不要、アプリケーションへの変更不要 • 復元力 –XRMEM に関してミラーを 自動的にstorage server群へ構成 • 著しく短い応答時間 – Database が RDMA を使用し読み取り処理を XRMEM から直接実行 共有型 Exadata RDMA Memory の利点 新しい APPLICATION のクラス 高頻度の取引 | リアルタイムの不正検知 | IoT | 人工知能/機械学習 Copyright © 2026, Oracle and/or its affiliates 95
92. ソフトウェアアーキテクチャ Copyright © 2026, Oracle and/or its affiliates 96
93. Copyright © 2026, Oracle and/or its affiliates 97 • Real Application Clustersにより、DBサーバーを並列稼働させ、高可用性と高拡張性を実現 • Automatic Storage Managementにより、ストレージ・サーバーを並列稼働させ、 高いI/O性能と高可用性・高拡張性を実現 • さらに、Exadata System Softwareが処理の一部をオフロードし、大量データの高速処理を実現 Oracle Exadata アーキテクチャ スケールアウト可能なインテリジェント・ストレージ スケールアウト可能なデータベース・サーバー DBサーバーを並列稼働 最速の内部ネットワーク ストレージを並列稼働
94. Exadata X11M のソフトウエア構成全体像 99 Copyright © 2026, Oracle and/or its affiliates … … … ソフトウェアスタック • DB Server • Oracle Database • ASM • Oracle Clusterware • Exadata System Software • Storage Server • Exadata System Software RoCE Network • DB Server 間や DB Server と Storage Server の通信 • Storage Server 間は原則通信しない →GI 12c 以降、リバランス時のみ通信 • Storage Server をまたがるオペレーションは DB Server に実 装 →Storage Server の完全なスケールアウトを実現
95. 共有ストレージ・共有キャッシュ型で全ノードがアクティブ スケーラビリティ • 全ノードがアクティブで対等に更新可能 • ノード数(CPU数)増加による性能向上 - トランザクション系: 同時ユーザー数の向上 - 分析系: 並列度向上 可用性 • Oracleインスタンスに障害が発生しても正常ノードに よって自動的にリカバリされる • 最低1つのOracleインスタンスが稼働していれば 全データにアクセス可能 • ノードごとのローリング・メンテナンス可能 透過性 • Oracleクライアントから見た挙動が シングル・インスタンスと同じ Oracle Real Application Clusters (RAC) Copyright © 2026, Oracle and/or its affiliates 100 共有ストレージ データ・ベース・サーバー
96. Oracle Real Application Clusters (RAC) Oracle Grid InfrastructureとOracle Database RACを構成するにはOracle DatabaseとOracle Grid Infrastructureの2つのソフトウェアをインストールする。 Oracle Databaseのソフトウェアから起動するのはOracleイ ンスタンスのみで、他の階層はOracle Grid Infrastructure の役割になる。 Oracle Grid Infrastructureの構成要素 • Oracle Clusterware • Oracle Automatic Storage Management • ノード・ローカル・リスナー • Single Client Access Nameリスナー • 仮想IPアドレス ASM ASM Clusterware Clusterware tnslsnr tnslsnr SCANリスナー tnslsnr Copyright © 2026, Oracle and/or its affiliates 101
97. CSSとCRS Cluster Synchronization Services (CSS) • メンバーシップ・サービス • 共有リソースを使用するメンバーを確定させる Cluster Ready Services (CRS) • リソース起動と停止および死活監視 • CSSがクラスタを構成するメンバーを確定させた上 でどのノードで監視対象リソースを起動するかを決 定する - 仮想IPアドレスとOracleリスナー - Oracleインスタンス - ASMインスタンス Oracle Clusterware Clusterware Clusterware CSS CSS CRS CRS Res. 1 Res. 2 Res. 3 Res. 4 Copyright © 2026, Oracle and/or its affiliates 102
98. クラスタ内のデータベースへ接続する際の単一のエイリアス サービスがどの物理サーバーに配置されても同じ設定で接続可能 構築時やノード追加・削除時に個別の追加設定が不要 ネットワーク設定の手間や複雑さを排除することで人為的ミスを削減 より大規模なクラスタへの接続に対応可能 Single Client Access Name (SCAN) 勘定系 DB 顧客 DB 単一のエイリアスで アクセス可能 サービスがどのサーバーに 配置されても同じ設定で 接続可能 ・SCAN名 ・ポート番号 ・サービス名 tnsnames.ora SCAN SCAN が各サービスへの接続を 自動的にリダイレクト 分析DB 常に単一のSCAN名で 接続可能 Exadata 初期デプロイ時 には SCAN を設定する必 要がある Copyright © 2026, Oracle and/or its affiliates 103
99. Exadataストレージ管理の概要 • Exadataストレージ・サーバーには複数の物理ディスクが含まれる • ハード・ディスク・ドライブ(HDD)またはフラッシュ・デバイス • 各物理ディスクは、OS内にLUNと呼ばれる論理表現がある • 物理ディスクとLUNは1対1の関係 • X10M EFのみ、30.72 TBの4つの容量最適化フラッシュ・デバイスのそれぞれ が2つのLUNで構成されるため、LUNが8つになる • セル・ディスクにより、LUN上の領域が、ESSでの使用のために予約 • LUNにはセル・ディスクを1つのみ含めることが可能 • 各セル・ディスクはESSによって管理され、グリッド・ディスクおよびプール・ディスクと呼 ばれる複数のパーティションにさらに細分化可能 • ストレージ管理にASMを使用する場合、グリッド・ディスクが使用 • グリッド・ディスクは、ASMディスク・グループで使用するためにASMに直接公 開されるセル・ディスクから割り当てられた領域 • 各セル・ディスクには複数のグリッド・ディスクを含めることが可能、 • 複数のASMクラスタおよび複数のデータベースで同じ物理ディスクを共有可 能 • ストレージ管理にExascaleを使用する場合、プール・ディスクを使用 • プール・ディスクは、Exascaleストレージ・プールで使用するためにExascaleに 直接公開されるセル・ディスクから割り当てられた領域 • 1つのセル・ディスクには複数のExascaleプール・ディスクを収容可能 • Exascaleは本質的に多数のテナント間でストレージ・プール・リソースを安全 に共有するように設計されているため、これは通常不要 104 Copyright © 2026, Oracle and/or its affiliates
100. アーキテクチャ ASMインスタンス • ASMディスク・グループ内の構成情報(メタデータ)の管理を行うための インスタンス。ファイルのレイアウト情報をデータベース・インスタンスに 提供 ASMディスク • ASM用に定義されたLUNやストレージ・デバイス ASMディスク・グループ • 複数のASMディスクで構成される、Oracle ASMが管理する基本オブ ジェクト • ディスク・グループごとに冗長化レベルを設定可能 障害グループ • 同一コントローラ配下のディスクをまとめた単位 • 異なる障害グループ間でミラーリングし、データ損失を回避 ASMファイル • ASMディスク・グループ内に格納されるファイル • データベース・ファイルなども含まれる AU (アロケーション・ユニット) • 分割したASMファイルをASMディスクに割り当て配置する単位 • Exadataでは4MBのAUを使用 Oracle Automatic Storage Management (ASM) Copyright © 2026, Oracle and/or its affiliates 105 データベース インスタンス ASM インスタンス ASMディスク ASM ディスク・グループ ASMファイル AU(アロケーション・ユニット) 障害グループ
101. 高性能、高可用性、管理容易性を提供するデータベースとして理想的なストレージ管理機能 Oracle Databaseのストレージ仮想化機能 • Oracle Databaseに対するボリューム・マネージャ兼ファイルシステム • エディションに関係なく、シングルまたはクラスタ環境ともに利用可能 • ASMによるファイルシステム機能も提供 I/O性能を最大限引き出しつつ、ストレージ管理工数を 大幅削減 • すべてのストレージ・デバイスにまたがったディスクの仮想化とストライピ ングを自動で行い、アクセスを均一化 • ストレージ・デバイスの増減にあわせた自動リバランス ストレージ筐体をまたがる高可用性と拡張性 • ミラーリング(二重化/三重化)可能 • 冗長構成でファイル破損を検出すると自動修復 • ストレージ・デバイス異常を検出すると自動切り離し • ストレージ・デバイスの増減にあわせた自動リバランス Oracle Automatic Storage Management (ASM) 追加 自動リバランス 削除 管理容易性 1 2 3 4 4 3 1 2 高可用性の担保 ミラーリング 1 2 3 4 高性能の維持 ストライピング Copyright © 2026, Oracle and/or its affiliates 106
102. Stripe And Mirror Everything (S. A. M. E) 「全てのストレージ・デバイスの均等利用を目的に、データをストライプして全てのストレージ・デバイス上に分散配置し、 ミラーリングも行う」という設計手法 • I/O性能の確保：全てのストレージ・デバイスのI/O帯域をフル活用 • 可用性を確保：ミラーリングの採用 • 設計の簡素化：物理的なストレージ構成を隠蔽し、特別な設計は不要 ASMの基本思想 Copyright © 2026, Oracle and/or its affiliates 107 1 2 3 4 3 6 1 7 5 6 7 8 4 2 8 5 異なるデバイスに ミラーリング すべてのデバイスにストライピング
103. Oracle Exadataでのスケール・アウト Copyright © 2026, Oracle and/or its affiliates 108 Storage 1 Storage 2 Storage 3 Database Server 1 Database Server 2 Flash Memory x4 HDD x12 FAILGROUP switch switch Storage n Database Server n ストレージ筐体は2RUサイズのIntel Xeonサーバー • HDD 12台 → ASMディスク12本に見える • Flash Memory 4枚(キャッシュ) 1つのストレージ筐体が1つのASM障害グループ • ミラーは異なるストレージ筐体に格納される • ストレージ筐体ごと停止してもシステム継続 ネットワーク総帯域の増加 RACでスケール・アウト ASMでスケール・アウト
104. cell disk / grid disk / disk group の一般的な構成 Copyright © 2026, Oracle and/or its affiliates 109 Cell disk Grid disk = ASM disk Disk group … disk1 disk2 disk3 disk4 disk12 +RECO DG +DATA DG 外周 内周 • すべてをDATA/RECO で利用 • 起動ディスクは内蔵の M.2 SATA SSD 初期設定では下記2つのディスク・グループだけが作成される X7 〜 X11M Exadata Storage Server = 障害グループ
105. Oracle ASMディスク・グループ • ディスクグループ：ASM内で抽象化されたプライマリ・ストレージ、1つ以上のグリッド・ディスクで構成 • グリッド・ディスク：ASMディスク・グループのメンバーシップに使用可能な個々のディスクとして、ASMに認識 • 以下のOracle ASMディスク・グループで構成 • DATA ：プライマリ・データ・ディスク・グループ • RECO ：プライマリ・リカバリ・ディスク・グループ。Oracle Database高速リカバリ領域(FRA)が収容 • SPARSE ：オプション構成のスパース・ディスク・グループ。Exadataスナップショットのサポートに必要 • XTND ：Exadata XT (拡張)ストレージ・サーバーからストレージを収集するために使用するディスクグループ • Exadata機能（条件処理のオフロードなど）を利用する条件 • ディスク・グループにOracle Exadata Storage Serverのグリッド・ディスクのみが含まれていること • 表がこれらのディスク・グループ内に完全に収まっていること • ディスクグループのcell.smart_scan_capable属性がTRUEに設定されていること 110 Copyright © 2026, Oracle and/or its affiliates
106. ASMからはExadataのディスクは以下のパスで検出される ディスクグループの作成例 • Exadataでは必ずNormal Redundancy(二重化)もしくはHigh Redundancy(三重化)を選択 （High Redundancy が強く推奨） Exadata での ASM ディスクグループ作成方法 CREATE DISKGROUP data HIGH REDUNDANCY DISK 'o/*/data*' ATTRIBUTE 'compatible.rdbms' = ’19.0', 'compatible.asm' = ’19.0', 'cell.smart_scan_capable' = 'TRUE', 'au_size' = '4M'; o/<Storage ServerのIPアドレス>/<GridDisk名> Copyright © 2026, Oracle and/or its affiliates 111 Compatibel version 確認 [grid@jojodb01 ~]$ /u01/app/21.0.0.0/grid/bin/asmcmd lsct DB_Name Status Software_Version Compatible_version Instance_Name Disk_Group +APX CONNECTED 21.0.0.0.0 21.0.0.0.0 +APX1 DBFSC1 +ASM CONNECTED 21.0.0.0.0 21.0.0.0.0 +ASM1 DBFSC1 cdb1db1 CONNECTED 21.0.0.0.0 21.0.0.0.0 cdb1db11 DATAC1 cdb1db1 CONNECTED 21.0.0.0.0 21.0.0.0.0 cdb1db11 RECOC1 _OCR CONNECTED - - jojodb01.jp.osc.oracle.com DBFSC1 [grid@jojodb01 ~]$
107. Enterprise ManagerからのASMディスクグループ管理 112 Copyright © 2026, Oracle and/or its affiliates
108. Oracle Clientに透過的かつ自動的な切り離し、再配置、ブロック修復 • ストレージ・デバイス障害時に自動切り離し • OSシステム・コールがエラーになるストレージ・デバイスをオフライン化、 復旧できない場合は切り離す • 冗長化されていれば処理は継続 • ストレージ・パス障害の切り替えはOSのI/Oタイムアウトに依存 (60秒程度) • Exadataならば数秒でノード障害を切り離し可能 • ストレージ・デバイスの増減にあわせてリバランスして冗長性を回復 • ファイル破損時の自動修復 • 読み取ったファイルの破損を「検出」するのはOracleのプロセスで あるが... • ストレージ・デバイス以外の階層の異常でもストレージのデータを 破損させる場合がある • ASMで冗長化している場合ファイル破損を検出すると、 自動的にミラーから読み取り処理継続し、破損個所を自動修復 ASMのストレージ障害への対処 Copyright © 2026, Oracle and/or its affiliates 113 データベース インスタンス ASM インスタンス 1 2 3 2 3 1 自動切り離し 処理継続 自動修復 自動リバランス Primary Secondary
109. Oracle Flex ASM（ASMインスタンスとデータベース・インスタンスを分離） ASMインスタンス障害発生時の挙動の改善 • 〜GI12.1のASM構成（左図）では、ASMインスタンスが障 害でDownした場合、同一Node上のDBインスタンスもDown する仕様 • GI 12.2 〜は、Flex ASM 構成 Flex ASM構成では、同一Node上のASMインスタンス停止時 は、別Node上のASMインスタンスへ再接続が可能 • ASM インスタンスのカーディナリティを指定 • Exadata のデフォルトのカーディナリティは ALL 114 Copyright © 2026, Oracle and/or its affiliates ディスク・グループ A Node4 Node3 Node2 Node1 ASM ASM ASM ASM DBA DBA DBB DBB ディスク・グループ A Node4 Node3 Node2 Node1 ASM ASM DBA DBA DBB DBB Node5 ASM DBB Node5 ASM DBB 従来のASM構成 (GI 12.1まで） Flex ASM構成（GI 12.2以降） [grid@vmc1-v4hra1 ~]$ srvctl config asm ASM home: <CRS home> Password file: +DATAC1/orapwASM Backup of Password file: +DATAC1/orapwASM_backu ASM listener: LISTENER ASM instance count: ALL Cluster ASM listener: ASMNET1LSNR_ASM [grid@vmc1-v4hra1 ~]$ Oracle Grid Infrastructure 12.2.1.1.0 〜
110. ASMの障害グループ • 障害グループ：同じハードウェアを共有するため同時に停止する可能性があるOracle ASMディスク・グループのディスクのサブセット • ASMは、冗長性を設定する際に障害グループを考慮 • ストレージ・サーバー障害発生時：ASMディスク・グループのメンバーおよび候補で構成されるすべてのグリッド・ディスクが同時に 停止する可能性がある • 1台のストレージ・サーバーが関連するすべてのOracle ASMグリッド・ディスクに、そのセルを表す障害グループを1つ割り当てる • Storage Serverのグリッド・ディスクの障害グループは、単一のセル上のディスクが同じ障害グループに属するようにデフォルトで設定 される • ASMディスク・グループの冗長性レベルは、ディスク・グループの作成時に定義 • 高冗長性（High Redundancy、3重化）、標準冗長性（Normal Redundancy、2重化） • ASMの高冗長性では、2つのセルまたはそのセル内のディスク・セットに障害が発生した場合にフォルト・トレランスが実行 • セルまたはディスクに障害が発生時 • ASMによってディスク・グループの残りのディスクに自動的にリバランス - (データを格納する十分な領域があることが条件) • パフォーマンス・サービス・レベルを満たすために必要なIOPSを残りのディスクで生成できるようにサイジングすること 115 Copyright © 2026, Oracle and/or its affiliates
111. ASMの最大可用性 • 推奨 • 「高冗長性」のOracle ASMディスク・グループ • 自動的にデプロイ可能なファイルの配置構成（ Oracle Exadata Deployment Assistant使用） • 最大可用性アーキテクチャ(MAA)のベスト・プラクティス • DATAとRECOの2つの主要なOracle ASMディスク・グループを使用 • ディスク・グループは、I/O帯域幅とパフォーマンスを最大化し、管理を簡素化するため、 すべてのディスクおよびOracle Exadata Storage Server全体でストライプ化 • DATAおよびRECOディスク・グループは、高冗長性で構成 - 高冗長性のディスク・グループの利点 • 二重パートナ・ディスク障害: ディスク障害に続く、2番目のパートナ・ディスクの障害による、データベース・ASMディスク・グループの損失防止 • Storage Serverのオフライン時のディスク障害: ストレージ・サーバーがオフラインであり、そのいずれかのストレージ・サーバーのパートナ・ディスク障 害が発生した場合のデータベースおよびOracle ASMディスク・グループの損失防止 - ストレージ・サーバーは、Exadataローリング・ストレージ・サーバーのパッチ適用など、Exadataストレージの計画メンテナンスによってオフラインに なる場合がある • ディスクのセクター破損によるディスク障害: 潜在的なディスク・セクター破損が存在し、計画メンテナンスまたはディスク障害のいずれかが原因で パートナ・ストレージ・ディスクを使用できない場合の、データの損失およびI/Oエラーを防止 - 高冗長性ではより多くの領域が必要で、書込みI/Oが3回発生 • 追加で発生する書込みI/OがExadataスマート・Write-Back Flash Cacheに与える影響はごくわずか 116 Copyright © 2026, Oracle and/or its affiliates
112. 従来の課題 • Quarter, Eighth Rack では、投票ディスクの3重化は構成できなかった • Storage Server ローリングアップグレード時や停止を伴うメンテナンス時に他の Storage Server 障害が発生すると、 投票ディスクの過半数が維持できず、クラスター停止につながる Quarter Rack, Eighth Rack での High Redundancy 対応 Exadata 12.1.2.3.0 〜 冗長度 OCR の多重化 投票ディスクの多重化 最低限必要な障害グループの数 Normal 二重化 三重化 3個 High 三重化 五重化 5個 ASM での OCR，投票ディスク管理 VD VD VD Storage Server #1 VD VD High Redundancy 構成で投票ディスクが3つし か無い場合、 Storage Server パッチのローリング適用中に他 の Storage Server 停止が発生すると、 投票ディスクの過半数を維持できない VD 停止 Storage Server #2 Storage Server #3 停止 Storage Server #1 Storage Server #2 Storage Server #3 Copyright © 2026, Oracle and/or its affiliates 117
113. • Exadata では、データベースサーバーに投票ディスク（Voting Disk）を作成することで、従来の課題に対応 • ベストプラクティス：High Redundancy のDATA ディスクグループ に投票ディスクを格納 • Oracle Exadata Deployment Assistant（OEDA）は 自動的に DB サーバーに投票ディスク(128MB)を作成 • Quorum Disk Manager ユーティリティが投票ディスクの作成や 管理を行う • 最低使用要件 • Exadata 12.1.2.3.0 • Grid Infrastructure 12c Release 1 (12.1) release 12.1.0.2.160119 およびpatch: 22722476 と 22682752 Quarter Rack, Eighth Rack での High Redundancy 対応 …. …. …. VD VD VD VD VD Storage Server #1 Storage Server #2 Storage Server #3 DB Server #1 DB Server #2 Copyright © 2026, Oracle and/or its affiliates 118 Exadata 12.1.2.3.0 〜
114. MAAの設定のための最適なファイル配置 自動でデプロイされるファイルの配置構成 • Oracle Databaseファイル ：DATAディスク・グループ • フラッシュバック・ログ・ファイル、アーカイブREDOファイル、バックアップ・ファイル： RECOディスク・グループ • REDOログ・ファイル：最初の高冗長性ディスク・グループ（DATA） • 制御ファイル：最初の高冗長性ディスク・グループ。バックアップ制御ファイルがRECOディスク・グループ内に存在するようにし、RMAN CONFIGURE CONTROLFILE AUTOBACKUP ONを設定する必要がある • サーバー・パラメータ・ファイル(SPFILE) ：最初の高冗長性ディスク・グループ（DATA）。SPFILEバックアップがRECOディスク・グループ内 に存在 • Oracle Exadata Database Machineフル・ラックおよびOracle Exadata Database Machineハーフ・ラック用のOracle Cluster Registry (OCR)および投票ディスク：最初の高冗長性ディスク・グループ（DATA） • Oracle Exadata Database Machineクオータ・ラックまたはエイス・ラックの投票ディスク：最初の高冗長性ディスク・グループ（DATA） 。 高冗長性ディスク・グループのExadataストレージ・セルが5つ未満である場合は、OEDAデプロイメント中にquorumディスクをExadata データベース・サーバーに追加 • 一時ファイル ：最初の高冗長性ディスク・グループ（DATA） • ステージングおよび非データベース・ファイル： ACFSボリューム • Oracleソフトウェア(監査および診断先を含む) ： Exadataデータベース・サーバーのローカル・ファイル・システム 119 Copyright © 2026, Oracle and/or its affiliates
115. ストレージの中断時の高いパフォーマンスの維持 • Exadataは、複数のストレージ層およびキャッシュにわたってデータをインテリジェントに管理することで、 高いパフォーマンスを実現するように設計 • 通常運用時： • Exadataはストレージ層をインテリジェントに管理し、 最も関連性の高いデータが、最も高いパフォーマンスと最も低いレイテンシのストレージを使用 • 計画停止か計画外停止かに関係なく、ストレージの中断が発生した場合： • 高パフォーマンスおよび低I/Oレイテンシを維持 • I/Oレイテンシは主に以下の2つの要因の影響を受ける - 中断への対処に必要なシステム上の追加のI/O負荷 - 中断によって発生したキャッシュ・ミス 120 Copyright © 2026, Oracle and/or its affiliates
116. ストレージの中断時の高いパフォーマンスの維持 • ストレージの中断に関連付けられたI/O負荷の管理 • ストレージ中断イベントが発生した場合 - Exadataは自動的に適切なレスポンスをオーケストレーションして、データの冗長性を効率的に維持またはリストア - ハード・ドライブ・フラッシュ・ドライブに障害が発生 • ExadataはOracle ASMからディスクを自動的に削除（Health Factor for Predictive Failed Disk Drop） • ASMリバランス操作が自動的にトリガーされ、ASMディスク・グループに冗長性がリストア - ハード・ドライブのパフォーマンスの低下、または障害予兆 • ドライブを交換する前にディスクを事前に削除してリバランスを実行し、冗長性を維持（Health Factor for Predictive Failed Disk Drop） - Smart Flash Cacheをライトバック・モードで使用している場合（現在のデフォルト） • キャッシュの内容を記述するメタデータが自動的に維持 • フラッシュ・ドライブの障害がキャッシュに影響を与えた場合 - デバイスの交換後にExadataによってキャッシュが自動的に再移入 - RDMAネットワーク・ファブリックを介した非常に効率的なセル間の直接データ転送を使用して、 生存しているミラーから読み取ることでキャッシュが再移入 - ストレージが短期的な中断後にオンラインに戻る場合 • 冗長性をリストアするための再同期操作を実行するように、ExadataがASMに自動的に指示 • 再同期操作では、ストレージ・エクステントの変更を追跡するビットマップが使用 • ソフトウェア更新やセルの再起動などの短期的な中断の場合、再同期は、変更されたデータのみをコピーして冗長性をリストア 121 Copyright © 2026, Oracle and/or its affiliates
117. ストレージの中断時の高いパフォーマンスの維持 • ストレージの中断に関連付けられたI/O負荷の管理 • ASMは、リバランスや再同期などの非同期操作に関連するI/Oに対して、ASM POWER LIMITと呼ばれる抑制を提供 - ASM POWER LIMITが高すぎる場合、ASM I/Oによってハード・ディスクが過負荷になり、I/Oレイテンシが長くなる可能性 • 高い制限では、ASMエクステント・ロックが増加し、データベースI/Oに影響する可能性 - Exadataでは、デフォルト(推奨)のASM POWER LIMIT値が非常に低く、アプリケーションのI/Oレイテンシへの影響は最小限 • この設定はExachkでも監視され、変動がExachkレポートに記載 • Exadata I/Oリソース管理(IORM)は、 システムI/OとアプリケーションI/Oが区別し、アプリケーションI/Oにインテリジェントに優先順位付け - アプリケーションI/OはExadataキャッシュに優先的にアクセスする - ASMリバランスでは、ハード・ディスクおよび未使用のキャッシュ領域にのみアクセス 122 Copyright © 2026, Oracle and/or its affiliates
118. ストレージの中断時の高いパフォーマンスの維持 • キャッシュ・ミスの最小化 • 通常の操作の過程で、データベース・バッファ・キャッシュに読み取られたデータは、プライマリ・データ・コピーを含むストレージサーバーのExadataキャッ シュ(可用性に応じてフラッシュ・キャッシュ、XRMEMキャッシュのいずれか)にもロードされる - データは常にプライマリ・コピーから読み取られる(使用可能な場合) - プライマリ・コピーを使用できない場合は、セカンダリ・コピーを使用 • プライマリコピー利用不可の場合に備えるために、プライマリ・キャッシュの管理の一環として、セカンダリ・セルのフラッシュ・キャッシュにもデータをロード • Exadataは、セカンダリ・キャッシュを事前にロードすることで、プライマリ・コピーが使用できずにセカンダリ・コピーを使用する必要がある場合に、最も重要なデータが引き 続きキャッシュされているようにする - セカンダリ・データ・コピーも使用できず、データが高冗長性で保護されている場合は、最後の手段として第3のデータ・コピーが使用される • 二重障害の同時発生を必要とするまれなシナリオのため、Exadataには、第3のデータ・コピーは事前にキャッシュされない • Exadataでは、セル間でデータを移動（例：リバランス）するときにキャッシュのコンテンツが保持 - 例：セル1の一部のデータがフラッシュ・キャッシュにロードされ、そのデータがセル2に移動されると、データはセル2のフラッシュ・キャッシュにもロードされる - リバランス操作によって移動されたデータが移動前と同じ方法でキャッシュされる • Exadataは、障害後のフラッシュ・キャッシュ・リカバリを迅速に処理 - プロセス障害の場合、Exadataはフラッシュ・キャッシュを再接続し、以前に移入されたデータで続行可能 - システム障害後にフラッシュ・キャッシュを迅速に再構築するため、Exadata X7以降はM.2ソリッド・ステート・ドライブ(SSD)にフラッシュ・キャッシュ・メタデータを保持する - フラッシュ・ドライブやハード・ドライブの交換後など、新しいストレージ・デバイスが検出されると、Exadataは、新しいストレージを完全に有効にする前に、フラッシュ・キャッ シュが適切にウォームアップされていることを確認 • 新しいストレージに関連付けられたフラッシュ・キャッシュ・ヒット率がシステムの他の部分と同様であることを確認するための広範なヘルス・チェックが含まれる 123 Copyright © 2026, Oracle and/or its affiliates
119. Health Factor for Predictive Failed Disk Drop • 通常のASM： • 1つのディスク障害が発生した場合、ASMはタイムアウト時間(デフォルト3.6時間)を待ってから該当の ディスクのDrop処理を自動的に実施 • Drop完了までの間に別のディスク障害が発生すると、二重障害となりデータロスの可能性がある • Exadata Storage Server • 物理ディスクの障害や障害を予知した場合、 - ASMのタイムアウト時間を待たずにpro-activeにASMディスクグループからディスクをDrop - ASMは即時に障害ディスクに配置されていたデータを他のディスク上にリバランス • Flashモジュールの障害を検知した場合 - Smart Flash Cacheから該当のFlashモジュールをDrop - ASMディスクグループからFlash Grid DiskをDrop 予測障害ディスク・ドロップの状態要因 ASMディスクグループの冗長性を即時回復ことができ、データロスの危険性を削減 Copyright © 2026, Oracle and/or its affiliates 124 Exadata 11.2.3.2.0 〜
120. Health Factor for Predictive Failed Disk Drop ディスクの二重障害によるデータロスを防ぐ機能 • 不必要なdropは起きません 予測障害ディスク・ドロップの状態要因 Disk Group 障害グループA 障害グループB 障害グループC ASM インスタンス ASM インスタンス HDD 障害発生 該当のディスクをディスク グループからdropするよう指示 ディスクグループからディスクをdrop、 リバランス実行 一時的なネットワーク障 害やStorage Server障 害等で、HDDには異常 がない場合 ASMは従来通り該当の ディスクをOFFLINE化。 disk_repair_timeを待機してか ら復旧しなければdrop Copyright © 2026, Oracle and/or its affiliates 125 Exadata 11.2.3.2.0 〜
121. Health Factor for Predictive Failed Disk Drop Proactive Disk Drop は下記のような条件下で動作 • 物理障害(Failed) 時 - HDD - Flash disk • 障害予知(Predictive Failure) 状態 - HDD - Flash disk • パフォーマンスが極端に遅い(Poor Performance)状態 - HDD(Storage Server Patch 11.2.3.2.0以降) - Flash disk 予測障害ディスク・ドロップの状態要因 注意： HDD を物理的に抜いただけでは Failed の状態と認識されません。 この場合の動作は従来どおりとなり ます。(ASM ディスクはオフライン化、 disk_repair_time のタイムアウトを 待ち、Dropされ、ディスクが再度入 るGriddisk,Celldisk の自動再作成 、ASM ディスクのオンライン化もしくは Add が自動的に行われます。 Copyright © 2026, Oracle and/or its affiliates 126 Exadata 11.2.3.2.0 〜
122. • ディスク障害が発生した場合、ディスク交換後のコマンド操作は不要 • ディスクが完全に壊れた状態以外に、障害予知状態にも交換が必要な状態なためアラートが生成され、 ASM Diskgroup より即時 Drop されます。(Proactive Disk Drop機能) • 新しいディスクは自動的に元のASM Diskgroupへ戻る • 1.ディスク障害が発生 • Proactive Disk Drop の場合 disk_repair_timeを待たずに即時にdisk group からdrop • (上記以外のディスク障害、一時的なオフラインやStorage Server障害など)ASMディスクはOFFLINE化 その後、disk_repair_timeがtimeoutすると自動的にdisk group からdrop • Storage Server 側ではディスク障害が発生したことが検知され、アラートが発生 - →OracleサポートにSRを起票してください。ディスク交換スケジュールを調整 • 2.ディスク交換を実施(Oracle のCEによる作業) • Storage Server側では新しいディスクが挿入されたことを検知し、自動的にLUN, celldisk, griddiskを再作成 • ASMではOFFLINE化もしくはDROPしたディスクを再度Disk Groupに追加して、元の状態に戻します(Exadata独自 の機能) Exadata のディスク交換手順 Copyright © 2026, Oracle and/or its affiliates 127 Exadata 11.2.3.2.0 〜
123. • 各 Storage Server 内のディスクのキャッシュとして動作。冗長性は通常通り ASM の冗長性によって確保される。 • 4 MB の Allocation Unit ごとにストライピングとミラーリングが行われている。 • 障害グループ（各 Storage Server）にまたがって primary copy と mirror copy が書き込まれる。 Exadata Smart Flash Cache (Write-Back モード) の動作① Smart Flash Cache Disk Controller Cache Cellsrv Storage Server #1 DB buffer cache DBWR Smart Flash Cache Disk Controller Cache Cellsrv Tertiary copy Primary copy 該当のデータブロックをupdate 最新データはそれぞれの Storage Server の Flash Cache に書き込まれる。 ディスク上には stale なブロックが存在。 DB Server Storage Server #2/#3 Copyright © 2026, Oracle and/or its affiliates 128 Secondary copy
124. • Read 時には、Flash 上の Primary Copy を読み込む • Mirror Copy は基本的には Read 時には使われないので、領域を空ける必要があればディスクに書き込まれ、Flashの 領域がクリアされる Exadata Smart Flash Cache (Write-Back モード) の動作② Smart Flash Cache Disk Controller Cache Cellsrv Server Process Smart Flash Cache Disk Controller Cache Cellsrv Secondary copy Primary copy キャッシュ済みデータを読み込む場合 Mirror データの Age Out Flash 上にキャッシュされた primary copy を読む Flash Cache からHDDに 書き込まれる 青色ブロックを select Storage Server #1 Storage Server #2/#3 DB Server Copyright © 2026, Oracle and/or its affiliates 129
125. Storage Server または Flash 障害時における読み込み時動作 (Exadata 18.1.0 までのリリース) • プライマリ・ミラーの Storage Server または Flash に障害が発生した場合 • Exadata 18.1.x までは、セカンダリ・ミラーを使用するように I/O をリダイレクトするが、 Flash Cache 上に該当のデータが残っていない場合はディスクからの読み込みが必要となり、性能に影響を与える Exadata Smart Flash Cache (Write-Back モード) の動作③ Cellsrv Cellsrv 該当のデータブロックを select Database Server Storage Server Flash Cache Server Process Storage Server または Flash に障害 HDD ディスクからの読み込みとなる ため、性能低下の原因となる キャッシュ ミス発生 Copyright © 2026, Oracle and/or its affiliates 130 〜 Exadata 18.1.0
126. Storage Server または Flash 障害時における Exadata 19.1 以降の動作 (Cell の停止および Flash 障害時の OLTP 高可用性拡張) • プライマリ・ミラーをもつ Storage Server や Flash に障害があっても、 セカンダリ・ミラーを Flash Cache にプリフェッチすることで性能低下を防ぐ • 自動的にアクティブなセカンダリ・ミラーをキャッシュ上のコールド・データと置き換え • Flash デバイスが交換されたときには、最新の状態となるようにウォームアップ Exadata Smart Flash Cache (Write-Back モード) の動作④ Cellsrv Cellsrv 該当のデータブロックを select Database Server Storage Server Flash Cache Server Process 頻繁にアクセスされる OLTP データのセカンダリ・ミラーを バックグラウンドで事前にプ リフェッチ Storage Server または Flash に障害 HDD Exadata Database Machine X6 HC 以降が必要 Write Back Flash Cache 構成時のみ有効 OLTP データのみ対象 キャッシュ・ ミスを防止 Oracle Database 19c 以降が必要 Exadata 19.1.0〜: Smarter OLTP Caching Copyright © 2026, Oracle and/or its affiliates 131
127. セルからセルへのリバランスにおけるフラッシュ・キャッシュ移入の保持 Cell-to-Cell Rebalance Preserves Flash Cache Population • Cell-to-cell Data Transfer が進化し、リバランス前後でFlashCache の状態を保持するようになった • リバランス前にFlashCache にキャッシュされていたデータは、リバランス後も、FlashCache に自動でキャッシュさ れる • リバランス前後で、キャッシュ・ヒット率の低下なしに、アプリケーションを実行できる • 完全に自動的かつ透過的に実施 • 対応バージョン • Exadata: 12.1.2.2.0 • Exadata Bundle Patche: 12.1.0.2 BP11 132 Copyright © 2026, Oracle and/or its affiliates InfiniBand Network ASM Cell01 Cell02 リバランス Exadata 12.1.2.2.0〜
128. リバランス時の Storage Indexの保持 Cell-to-Cell Rebalance Preserves Storage Index • ディスク障害時には障害ディスクに格納されていたデータは他の Cell にリバラ ンスされる • 以前の動き • 障害ディスクに紐づく Storage Index のリージョン情報は失われ、 次回の Smart Scan 時に再構成されていた • ディスク障害時は、リバランス後初回の SmartScan 性能に影響していた • Storage Server 12.1.2.3.0 以降 • 障害ディスクに紐づく Storage Index のリージョン情報も cell to cell リバランス時に 一緒に移動する • ディスク障害時のリバランスが発生してもパフォーマンスを維持 • 最低使用要件: • Oracle Exadata Storage Server Software release 12.1.2.3.0 • Oracle Database 12c Release 1 (12.1) release 12.1.0.2.160119 および patch 22682752 133 A B C 9 3 10 1 8 2 11 9 10 8 10 8 Min B = 5 Max B = 7 Region Index A B C D 3 1 2 9 8 8 6 7 5 Min B = 8 Max B = 9 Min B = 1 Max B = 3 Exadata 12.1.2.3.0〜 Copyright © 2026, Oracle and/or its affiliates
129. Cell-to-Cell Rebalance Preserves Persistent Memory • ディスク障害が発生した場合、リバランスによって Storage Server 間でデータは移動 • リバランスの際に、データの移動元の Storage Server の Persistent Memory 上のデータは、移動先の Storage Server の Persistent Memory 上に移動 • リバランスの際もアプリケーションのパフォーマンスを維持 • Persistent Memory Data Accelerator では、キャッシュされ たデータのレプリケーションは自動で透過的に実施 Cell-to-Cell リバランスによる PMEM Cache ポピュレーションの保持 Exadata 20.1.0 〜 リバランスに要する時間 クエリーのレスポンスタイム Before - Wait for IO from Flash After - Consistent Response from Persistent Memory Exadata X8M モデル以降 Copyright © 2026, Oracle and/or its affiliates 134
130. Exadataは、メンテナンス後も高いI/Oパフォーマンスを独自に提供 Improved Performance Using Partner Cache Reads ストレージ・サーバーのメンテナンス後、 ワークロードの変更により、データベースがハード・ディスクから 一時的に読み取られる場合がある プライマリ・ストレージ・サーバーは、 ミラー・パートナーのフラッシュ・キャッシュからデータを一意に フェッチして、最適なI/Oパフォーマンスを維持しながら、 プライマリミラーのフラッシュ・キャッシュへデータをバックグラウン ドで再移入する プライマリ・ミラーのキャッシュが完全にウォームアップされると、 ミラー・パートナからの読取りが停止 この高可用性機能は、ミッションクリティカルなデータベース・ ワークロードをサポート 135 Copyright © 2026, Oracle and/or its affiliates パートナー・ミラーの フラッシュキャッシュでヒット Partner Storage Server Primary Storage Server メンテナンス直後に高いI/Oパフォーマンスを実現 Database 23aiで 38047996の修正が必要 Exadata 25.2 〜
131. ストレージ障害 • ドライブの障害が報告されているが、物理的な障害でない場合 ✓ ドライブ障害の誤検知(偽陽性)を回避するため、ドライブ電源の自動再投入を実施 （Elimination of False Drive Failures） - High Capacity Disk と Extreme Flash Drive の両方の機能 • ストレージ障害が発生した場合 • データベースのデータを意識した優先順位に基づくリバランスを実行（GI 12.1.0.2 BP5 〜） - 制御ファイル、ログ・ファイル、SPファイル、TDE キー・ストア、OCR、ウォレット、データベース・ファイルの順でリバランスを 実施 (The ASM Priority Rebalance feature - An Example (Doc ID 1968607.1)) • GI 12.2 以上で有効な機能: • ストレージ障害後の冗長性の回復に要する時間を大幅に短縮 （Faster Redundancy Restoration After Storage Loss） - 新規の REBUILD フェーズを最初に実行して REDUNDANCY をリストア(ディスクグループの冗長性を回復)、 その後 BALANCE フェーズでASM ディスク上のエクステントの均等化処理が行われます - 冗長性を優先してリストアするASMリバランスにより、二次的な障害の可能性を大幅に低減 • リバランスの読み込みに Exadata フラッシュ・キャッシュを活用し、冗長性のリストアのパフォーマンスを最大 30 %向上（Cell-to-Cell Rebalance Preserves Flash Cache Population） Exadata: データ保護のための特有な機能 Copyright © 2026, Oracle and/or its affiliates 136 Exadata 12.1.2.1.0 〜 Oracle Grid Infrastructure 12.1.0.2.5 〜 Oracle Grid Infrastructure 12.2.1.1.0 〜 Exadata 12.1.2.2.0 〜
132. リバランス処理の2つのフェーズ（リバランス・フェーズ + コンパクション・フェーズ） リバランス・フェーズ • ASM File（= Data File）単位で、全ASM Diskへ均等に分散し直す • 追加Diskへ移動するFile Extentは、全てのASM Fileが対象 - 最後に作成した（Diskの後ろに位置する）ASM Fileのみではない コンパクション・フェーズ • リバランス・フェーズで File Extent が追加 Disk へ移動することで、 既存 Disk では歯抜け状態になるが、コンパクション処理でその状態を解消 - 各ASM Diskにおいて、後方に位置するFile Extent（AU）から順番に前方の空きスペースへ移動 • Grid Infrastructure 11.2.0.4 or 12.1.0.2以降の Exadata 環境ではコンパクション無効 【参考】 ASMによるデータの分散配置 Copyright © 2026, Oracle and/or its affiliates 137 Oracle Grid Infrastructure 12.2.1.1.0 〜
133. ASM リバランス関連 • Storage Server 間でのデータ転送（cell-to-cell Data Transfer / Cell-to-Cell Offload Support for ASM- Scoped Security） - DB Serverを経由せず、Storage Server 間だけでデータを移動する事が可能 - これにより、InfiniBand/RoCE ネットワークを通じた転送量を従来の二分の一に抑え、 データベースサーバーのメモリ使用量も抑えることが可能 • コンパクション処理の省略（前述の通り） - リバランス処理時間の短縮とDiskに対する負荷軽減（アプリへの影響軽減） • パートナリング・アルゴリズムの最適化(ASM appliance.mode) - Exadata System Software 11.2.3.3.0 において、ASM appliance.mode パラメーターが導入され、ASM Diskgroup 内の ASM Disk のパートナリングのアルゴリズムが最適化 - これにより、ASM Disk が削除された際の冗長性回復の高速化を実現 【参考】 Exadata 特有な機能 Copyright © 2026, Oracle and/or its affiliates 138 Oracle Grid Infrastructure 12.2.1.1.0 〜 Exadata 12.1.1.1.0 〜 Exadata 11.2.3.3.0 〜
134. Oracle ASMの高速ミラー再同期 • Storage Serverやディスクから応答がない場合、ASMは一時的にI/Oをフリーズ(offline化) • Read I/Oはミラーされているデータにリダイレクトされる • 失敗したWrite I/Oはトラッキングされる • ディスクに再度アクセスできた際に、offlineの間のWrite I/Oが再実行される • 高速ミラー再同期(Fast Mirror Resync) ASM ブラウンアウト（一時的な停止）からの保護 Storage Serverの一時停止にも耐えうる設計 • 一時的な障害からの高速復旧 –例)Storage Serverのクラッシュや一時的なハング • 計画停止にも対応 –例)Storage Server・ソフトウェアのアップグレード Storage Server データファイル ASM 1 2 3 4 5 6 1 2 3 4 5 6 3 5 2 6 1 4 AU 一時的にOFFLINE化 Copyright © 2026, Oracle and/or its affiliates 139
135. Cell to Cell Data Transfer Exadata 12.1.1.1.0 よりデータ転送処理を自動かつ透過的に Cell へオフロード可能に • リシンク (高速再同期処理)、 リシルバ (FlashCache や scrub 時の同期処理)、 リバランス (ディスク交換やディスクグループ構成変更時) といった ASM の処理に対して、 データベースサーバーはターゲットの Cell に直接ソースの Cell からデータを読み込んで、ローカルのストレージに書き込 むように指示。 • これにより InfiniBand ネットワークを通じた転送量を従来の 二分の一に抑え、データベースサーバーのメモリ使用量も 抑えることが可能になった。 • Exadata 12.1 では、この機能は Open Security Mode (ASM Scoped Security や DB Scoped Security を構成していないデフォル トのセキュリティ・モード) でのみ有効 Cell-to-Cell データ転送 140 InfiniBand Network ・・・ ・・・ ・・・ cell01 cell02 cell03 ASM Cluster 1 2 db01 db02 Exadata 12.1.1.1.0 〜 Copyright © 2026, Oracle and/or its affiliates
136. Exadata 12.2.1.1.0 より、ASM Scoped Security 構成時においても ASM 処理を Cell へオフロード可能に • Cell に セル・キーを割り当てることにより、オフロード時に認証を実施。 • ２ つの形式のどちらかを選択して構成可能。 - 単純形式： 単一のキーをすべての Cell に割り当て、インバウンド とアウトバンドの両方の Cell-to-Cell トラフィックの 実行時に利用 - LOCAL/REMOTE 形式： Cell ごとにローカル・セル・キーを割り当て 複数のリモート・セル･キーを受け入れる ように構成し、Cell-to-Cell トラフィックの 実行時に利用 ASM Cluster2 VM VM Cell-to-Cell Offload Support for ASM-Scoped Security ASM-Scoped Securityのセル間オフロード・サポート 141 InfiniBand Network ・・・ ・・・ ・・・ cell01 cell02 cell03 1 db01 db02 2 ASM Cluster1 VM VM Exadata 12.2.1.1.0 〜 Copyright © 2026, Oracle and/or its affiliates
137. キーの切り替え(リ･キー)を定期的に行う運用の場合 (1/2) • 単純形式では、すべての Cell で一斉にキーを変更できる状態であれば、 オフロード処理が有効のまま リ・キーを行うことは可能。 • 実行中のオフロード処理は既存のキーでの接続により継続して行われ、新規のオフロード処理に ついては新規接続時に新しいキーが使われて実行される。 • LOCAL/REMOTE 形式では、一斉にではなく 順次 Cell ごとに、 オフロード処理が有効のまま リ･キーを行うことが可能。 • 構成する Cell の台数の規模が大きく、停止している Cell があるような場合でも、常にオフロード処理が行えるように Cell ごとに順次 リ･キーができる。 Cell-to-Cell オフロード処理 LOCAL/REMOTE 形式での構成が有用な場合 142 Copyright © 2026, Oracle and/or its affiliates
138. キーの切り替え(リ･キー)を定期的に行う運用の場合 (2/2) Cell-to-Cell オフロード処理 LOCAL/REMOTE 形式での構成が有用な場合 143 CY2017 Q1 (1-3月) CY2017 Q2 (4 – 6月) CY2017 Q3(7 – 9月) CY2017 Q4 (10 – 12月) cell01 cell02 cell03 cell01-Q1-key: REMOTE-CELL cell02-Q1-key: REMOTE-CELL cell03-Q1-key: LOCAL-CELL cell01-Q1-key: REMOTE-CELL cell02-Q1-key: LOCAL-CELL cell03-Q1-key: REMOTE-CELL cell01-Q1-key: LOCAL-CELL cell02-Q1-key: REMOTE-CELL cell03-Q1-key: REMOTE-CELL cell01-Q1-key: REMOTE-CELL cell02-Q1-key: REMOTE-CELL cell03-Q1-key: LOCAL-CELL cell01-Q3-key: REMOTE-CELL cell02-Q3-key: REMOTE-CELL cell03-Q3-key: REMOTE-CELL cell01-Q1-key: REMOTE-CELL cell02-Q1-key: LOCAL-CELL cell03-Q1-key: REMOTE-CELL cell01-Q3-key: REMOTE-CELL cell02-Q3-key: REMOTE-CELL cell03-Q3-key: REMOTE-CELL cell01-Q1-key: LOCAL-CELL cell02-Q1-key: REMOTE-CELL cell03-Q1-key: REMOTE-CELL cell01-Q3-key: REMOTE-CELL cell02-Q3-key: REMOTE-CELL cell03-Q3-key: REMOTE-CELL cell01-Q1-key: REMOTE-CELL cell02-Q1-key: REMOTE-CELL cell03-Q1-key: REMOTE-CELL cell01-Q3-key: REMOTE-CELL cell02-Q3-key: REMOTE-CELL cell03-Q3-key: LOCAL-CELL cell01-Q1-key: REMOTE-CELL cell02-Q1-key: REMOTE-CELL cell03-Q1-key: REMOTE-CELL cell01-Q3-key: REMOTE-CELL cell02-Q3-key: LOCAL-CELL cell03-Q3-key: REMOTE-CELL cell01-Q1-key: REMOTE-CELL cell02-Q1-key: REMOTE-CELL cell03-Q1-key: REMOTE-CELL cell01-Q3-key: LOCAL-CELL cell02-Q3-key: REMOTE-CELL cell03-Q3-key: REMOTE-CELL cell01-Q3-key: REMOTE-CELL cell02-Q3-key: REMOTE-CELL cell03-Q3-key: LOCAL-CELL cell01-Q3-key: REMOTE-CELL cell02-Q3-key: LOCAL-CELL cell03-Q3-key: REMOTE-CELL cell01-Q3-key: LOCAL-CELL cell02-Q3-key: REMOTE-CELL cell03-Q3-key: REMOTE-CELL 新しいキーの追加 キーの切り替え 古いキーの削除 タイムライン → キーを割り当て Cell-to-Cell オフロード 処理を有効化 このフェーズで、リ･キーを、オ フロード処理が常に有効な 状態のまま、Cell ごとに時 間をずらして実施できること が利点 Copyright © 2026, Oracle and/or its affiliates
139. • Storage Server 側 • MS プロセス - Storage Serverの管理プロセス - ディスク障害を検知するとアラートを生成、 新しいディスクが挿入されたことを検知すると LUN や celldisk, griddisk の再作成など必要な操作を行う • DB Server ASMインスタンス内 • diskmon プロセス - I/O fencing を実装 - CRS(Cluster Ready Services) の一部 • XDMGプロセス(Exadata Automation Manager) - Storage Serverの状態変更を監視しており、ディスク交換が発生すると必要なタスクを実施。 アクセス不可能なディスクやStorage Serverを監視し、ディスクやStorage Serverがアクセス可能になった際に検知する役目。 アクセス可能になると、ONLINE処理を開始。 • XDWKプロセス(Exadata Automation Worker) - XDMGプロセスから要求される自動タスクを実施。 XDWKプロセスは、ONLINE、DROP、ADDといった非同期処理を実施する際に起動。 アクティブでない状態が5分続くとプロセスは停止。 【参考】自動復旧のためのプロセス Copyright © 2026, Oracle and/or its affiliates 144
140. Automatic Tuning of ASM Rebalance Operations ASMディスク・グループのリバランス、再構築(rebuild)、再同期(resync)操作について • ストレージ・サーバー間のエクステントのバランス（rebalance）をとる • ドライブ障害後にディスクを再構築(rebuild)する • ストレージ・サーバーのソフトウエア更新時にディスクを再同期(resync)する リバランス完了の迅速化により、データ保護とパフォーマンスを実現 新しい自動リバランス管理フレームワークにより、ExadataでのASMリバランスが加速 • Exadataストレージ・サーバーは、database I/O profile を継続的に監視し、 データベースI/Oパフォーマンスを保護しながら、 ASM_power_limitを最大レベルに自動的にチューニング • Grid Infrastructure 23aiは、最適なASM_power_limit とリバランス速度を動的に調整 するために、Exadataストレージ・サーバーをポーリング ASMリバランスの自動高速化 Copyright © 2026, Oracle and/or its affiliates 145 ディスク障害後のデータ冗長性の再構築を最大3.6倍高速化 ストレージ・サーバーのローリング・アップグレード中の再同期を最大2倍高速化 既存のクラスタへのストレージ・サーバーの追加を最大で2.6倍高速化 Database I/O ASM Power Limit Polling Exadata System SW 25.1 Exadata Storage Server Exadata Database Server Exadata 25.1 〜
141. ハードディスクの自動スクラブ修復機能 • ハードディスク上の bad sector の検知と修復 • ストレージのディスクパトロール機能のようなもの • 定期実行可能（隔週、毎週、毎日） • メリット: ディスクの信頼性の向上。DatabaseとしてRead/Writeしていない領域も含めて定期的にScrubすることで 障害を未然に防ぐことが可能 • Extreme Flash モデルでは、動作しない（ハードディスクが存在しないため） Automatic Hard Disk Scrub and Repair Exadata 11.2.3.3.0 〜 Disk Controller Cellsrv Disk Controller Cellsrv HDD の sector 異常を検出す るため Storage Server 上で HDD を read ASMインスタンス Bad sector を検出したら、ASMと連 携し、別 Storage Server 上にある ASM のミラーデータを使ってrepair (resilverと呼ばれる) Storage Server #1 Storage Server #2 Copyright © 2026, Oracle and/or its affiliates 146
142. • CellCLI での設定確認、変更方法 • 開始日時と頻度を設定可能 - 開始時間：日付時刻、もしくは now(即時実行) で設定 - 実施頻度：daily / weekly / biweekly / none から選択 • CellCLI での設定確認 (下記例はデフォルト設定の場合) • デフォルトは1970-01-01 9:00開始で二週間おきに実行される - 隔週木曜日朝9:00 自動ハードディスク Scrub の設定方法 CellCLI> ALTER CELL hardDiskScrubStartTime='2013-08-07T21:19:22-07:00 CellCLI> ALTER CELL hardDiskScrubInterval=weekly CellCLI> list cell attributes hardDiskScrubStartTime,hardDiskScrubInterval 1970-01-01T09:00:00+09:00 biweekly Copyright © 2026, Oracle and/or its affiliates 147
143. Disk Type HDD Size 実行時間の目安 High Performance 600 GB 1 時間 High Performance 1.2 TB 2 時間 High Capacity 2 TB 4 時間 40 分 High Capacity 3 TB 6 時間 30 分 High Capacity 4 TB 8 時間 High Capacity 8 TB 13 時間 High Capacity 10 TB 14 時間 High Capacity 14 TB 18 時間 自動ハードディスク Scrub の実行時間 Copyright © 2026, Oracle and/or its affiliates 148 • 実行時間の目安 (マニュアル記載) • 他の I/O が発生していない場合の実行時間の目安。 • DB からの I/O が発生している場合はそちらが優先されるため scrub 時間は変動
144. Adaptive Scrubbing Schedule • デフォルトは2週間毎のスクラブ • Adaptive Scrubbingスケジュール • hardDiskScrubIntervalが biweekly の場合 - disk scrub 時に bad sector を検知した場合、該当ディスクに対して1週間後に再度 scrub を実施 - bad scrub が検知されなくなれば hardDiskScrubInterval の設定値に戻る • hardDiskScrubIntervalが weekly もしくは、daily の場合 - ユーザー定義の hardDiskScrubInterval 値にて disk scrub を実施 自動ハードディスク Scrub の機能追加 Copyright © 2026, Oracle and/or its affiliates 149 Exadata 12.1.2.3.0 〜
145. • Exadata のユーザーデータををセキュアに消去（Exadata 11.2.3.3.0〜） • CellCLI コマンド (DROP CELL ERASE または DROP CELLDISK ERASE )機能 - ERASE オプションを利用することで、ディスク内の既存データは、1 Pass/ 3 Pass/ 7 Passで上書き消去 • 1 Pass：コンテンツのゼロ埋め（フラッシュドライブには使用できない） • 3 Pass：アドレス可能なすべての場所を1つの文字、その補数、ランダムな文字の順で上書きし、最後に結果を検証。デバイス全体を3回上書きして1回読み取るのにかかる時間 とほぼ同じ時間がかかる。NNSA（National Nuclear Security Administration）での推奨方法（フラッシュドライブには使用できない） • 7 Pass：DOD（Department of Defense） での推奨方法 時間がかかりすぎるのが課題 - サポートされるプラットフォームでは 消去方式を Secure Eraser の暗号消去法に自動的に変更して消去を高速化（Exadata 19.1〜） • Exadata X5 以降 • 以前にユーザー・データを暗号化したときに使用した暗号化キーを削除することにより、Instant Secure Erase (ISE)デバイスに存在するすべてのユーザー・データを消去 • 暗号消去法により消去時間は 1 分へ短縮 • Exadata 上のすべてのコンポーネントの情報をセキュアに消去（Exadata 12.2.1.1.0〜） • データだけで無く、OS、Exadata System Software、構成も消去 - ハード・ドライブ、フラッシュ・デバイス、内部USB、ILOM、データベース・サーバー、ストレージ・サーバーのすべてのデータを消去 - InfiniBandスイッチ、イーサネット・スイッチ、PDUを出荷時のデフォルトにリセット • リイメージ（再インストール）処理の際に Secure Eraser が自動実行（Exadata 19.1〜） - 再インストール時に既存データが安全に消去 • 消去証明書を発行 Exadata Secure Eraser Copyright © 2026, Oracle and/or its affiliates 150 Exadata 11.2.2.3.0 〜 Exadata 12.2.1.1.0 〜 Exadata 19.1.0 〜
146. デバイスを安全に消去するために使用する方法 コンポーネント 型またはモデル 消去方法 ハード・ドライブ •Exadata Database Machine X5の8 TBのハード・ドライブ •Exadata Database Machine X6以降のすべてのハード・ドライブ 暗号消去 ハード・ドライブ その他すべてのハード・ドライブ 1/3/7パス消去 フラッシュ・デバイス Exadata Database Machine X5以降のフラッシュ・デバイス 暗号消去 フラッシュ・デバイス その他すべてのフラッシュ・デバイス 7パス消去 M.2デバイス Oracle Exadata Database Machine X7-2以上 暗号消去 永続メモリー(PMEM)デバイス Exadata Database Machine X8M以降 暗号消去 Exadata Secure Eraser Copyright © 2026, Oracle and/or its affiliates 151
147. 各デバイスに対する消去時間について デバイスのタイプ 1pass 3pass 7pass 暗号化 600GBハード・ドライブ 1時間 3時間 7時間 使用不可 1.2TBハード・ドライブ 1.67時間 5時間 11.67時間 使用不可 4TBハード・ドライブ 8時間 24時間 56時間 使用不可 8TBハード・ドライブ 13.17時間 39.5時間 92.17時間 1分 10TBハード・ドライブ 14時間 42時間 98時間 1分 14TBハード・ドライブ 18時間 54時間 126時間 1分 1.6 TBフラッシュ・ドライブ 使用不可 使用不可 5.5時間 1分 3.2 TBフラッシュ・ドライブ 使用不可 使用不可 8時間 1分 永続メモリー(PMEM)デバイス 使用不可 使用不可 使用不可 1分 4GB内部USB 使用不可 30分 使用不可 使用不可 150GB M.2デバイス 使用不可 使用不可 使用不可 1分 ILOM 使用不可 使用不可 使用不可 1分 Exadata Secure Eraser Copyright © 2026, Oracle and/or its affiliates 152
148. データベース・サーバーおよびストレージ・サーバーの安全な消去 • ユーザー・データのみでなく、オペレーティング・システム、Oracle Exadata System Software、ユーザー構成を含む すべてのコンテンツを消去 • ハード・ドライブ、フラッシュ・デバイス、永続メモリー、内部USB、ILOMにも対応 • システム・デバイスが安全に消去された後は、サーバーをブートできなくなる • ILOMは出荷時のデフォルトにリセットされた後、リモートからアクセスできなくなる • ILOMには、シリアル・コンソールを使用してアクセスする • 利用方法 • Secure Eraser ユーティリティを利用 - 例：Patch 34694339: EXADATA 22.1.5.0.0 SECURE ERASER • 上記zipファイルを解凍、ISOからPXEブート • デフォルトではすべてのコンポーネントを消去 • コマンドラインオプションで特定のコンポーネントのみの消去も可能 - secureeraser コマンドを内部的に利用 Exadata Secure Eraser Copyright © 2026, Oracle and/or its affiliates 153 Exadata 12.2.1.1.0 〜 Exadata 19.1.0 〜
149. GB と GiB の違い • 1GB = 109 = 1,000,000,000バイト • 1GiB = 230 = 1,073,741,824バイト • cellcli コマンドで表示されるサイズはGiB単位 SAS 600Gディスクの場合 • 600,000,000,000 bytes • OS上から確認できるサイズ： - 598.9 GB = 557.8 GiB 【ご参考】 Disk のサイズ表記について CellCLI> list celldisk attributes name,size where diskType=HardDisk CD_00_jigenc01 528.734375G CD_01_jigenc01 528.734375G CD_02_jigenc01 557.859375G CD_03_jigenc01 557.859375G CD_04_jigenc01 557.859375G CD_05_jigenc01 557.859375G CD_06_jigenc01 557.859375G CD_07_jigenc01 557.859375G CD_08_jigenc01 557.859375G CD_09_jigenc01 557.859375G CD_10_jigenc01 557.859375G CD_11_jigenc01 557.859375G cellcliコマンドでCelldiskのサイズを表示 ※ HCの例 Copyright © 2026, Oracle and/or its affiliates 154
150. Exascale 155 Copyright © 2026, Oracle and/or its affiliates
151. Exadata Exascaleは、 Exadataの長所と最高のクラウドを提供する 新しいインテリジェントなデータ・アーキテクチャ 156 Copyright © 2026, Oracle and/or its affiliates
152. Exadata Exadata Exascale Delivers the best of Exadata and Cloud 157 Copyright © 2026, Oracle and/or its affiliates Exadata • インテリジェントなAI • インテリジェントなAnalytics • インテリジェントなOLTP Cloud • マルチテナント • プールされたリソース • ハイパー・エラスティック Exadata Exascale Exadata 24.1 〜
153. クライアント VM層 LUNs ロード・ バランサー層 ストレージ・ メタデータ層 ストレージ層 • ストレージはVM内のLUNとして公開 • 標準的なブロックIOプロトコルを使用 • ロード・バランサー層は、 LUN IOをメタデータ・サーバーにルーティング • ストレージ・メタデータ層は、 LUNの分散とミラー化を管理 • ストレージ層はデータを保持 • 更にレイヤーがある場合も... 従来型のクラウドストレージのアーキテクチャ Copyright © 2026, Oracle and/or its affiliates 158 すべての層でレイテンシとボトルネックが増加 Exadata 24.1 〜
154. 中間ストレージ管理層の必要性を独自アーキテクチャで排除 Oracle Database 26aiでは、 インテリジェントなデータ・リクエストを ストレージ・サーバーに直接送信 • 中間層のない直接I/Oアーキテクチャは 本質的に高速 • RDMAリクエストに対応したハードウェアにより、マ イクロ秒のレイテンシと 数百万IOPSのスループットを実現 Exascale アーキテクチャ Copyright © 2026, Oracle and/or its affiliates 159 Exadata Database Cluster 100G RoCE Network Oracle DB 26ai Exadata Exascale Storage Pool SQL オフロード RDMA Exadata 24.1 〜
155. パフォーマンスに加えて、ストレージ容量を独自に最適化 自動的かつ透過的なストレージ • メモリー、フラッシュ、ハード・ディスクを階層化 • クエリーのオフロード、カラムナー・キャッシング、 ストレージ・インデックスなどの実装 • DRAMではパフォーマンス、フラッシュではIOPS、 ディスクでは容量を提供 Exascale アーキテクチャ Copyright © 2026, Oracle and/or its affiliates 160 SQL Offload Exadata Database Server Hot XRMEM Cold Disk Warm Flash Cache Exadata Storage Server RDMA Exadata 24.1 〜
156. Automatic Storage Management利用時のExadataアーキテクチャ • Automatic Storage Management（ASM） は各データベースクラスタ内で稼働 • セルディスクは複数のグリッドディスクに分割さ れ、それらがASMに提示される • グリッドディスクは単一のデータベースクラスタ 専用 • ストレージ容量を再割り当てする際には、 複数のASMディスクグループにまたがる グリッドディスクのリサイズが必要 • ASMは実績ある技術であり、 堅牢で長期的なロードマップを備える 164 Copyright © 2026, Oracle and/or its affiliates Exadata Storage Exadata Smart Features Smart Flash Cache, XRMEM Data Accelerator, Smart Scan, Storage Indexes, Columnar Caching, Bloom filters, 等 Grid Disks Oracle Grid Infrastructure クラスター毎のストレージマネージメント Automatic Storage Management と Disk Groups Oracle Database 11g-26ai Exadata Compute
157. Exascaleアーキテクチャは、ストレージサーバ上にストレージ管理を分散 • Exascaleはストレージ管理を データベースクラスタからストレージサーバへ 移行 • Oracle AI Database 26aiは Exadata Exascaleストレージをネイティブにサ ポート • Direct I/OおよびRDMA操作を使用 165 Copyright © 2026, Oracle and/or its affiliates Exadata Storage Exadata Exascale Services と Exadata スマートストレージ機能 Storage Pools, Vault and Volume Management, redundancy and partnering, caching and tiering, file metadata management, snapshots and clones, data integrity, Smart Flash Cache, XRMEM Data Accelerator, Smart Scan, Storage Indexes, Columnar Caching, Bloom filters, 等 Oracle Grid Infrastructure Oracle AI Database 26ai Exadata Compute すべてのExadata Smart Storage機能 が利用可能
158. ExascaleとASMのハイブリッド導入により、両アーキテクチャの長所を最大限に活用 • ハイブリッド導入により、選択肢と一貫 性を提供 • データベース11g〜19cは引き続きASM を使用 • データベース26aiはExascaleまたはASM のいずれかをサポートし利用可能 • 仮想マシンはデータベース構成にかかわ らず、Exascaleボリュームを使用可能 • ASMとExascaleは同一のストレージサー バ上にデプロイされる 166 Copyright © 2026, Oracle and/or its affiliates Exadata Storage Exadata Exascale Services と Exadata スマートストレージ機能 Grid Disks Oracle Grid Infrastructure ASM and Disk Groups Oracle Database 11g-26ai Exadata Compute Cluster 1 Oracle Grid Infrastructure Oracle AI Database 26ai Exadata Compute Cluster 2
159. Exadata Exascale Storage Pool Exascale アーキテクチャ データベース・エクステント データベース・ファイルを8MBエクステントとして格納: • 優れた順次読取りパフォーマンスを実現するのに 十分な大きさ • CPU、メモリ、I/Oリソースを最大限に活用するため、多 数のディスク、ストレージ・サーバーにデータベースを分 散させるのに十分な小ささ 167 Copyright © 2026, Oracle and/or its affiliates Database Datafile 8MB 8MB 8MB 8MB 8MB 8MB 8MB 8MB 8MB Exascaleは、 データベース・エクステントのジャイアント・プールを 直接管理 Exadata 24.1 〜
160. ストレージ・バケットへのエクステントのマッピング • エクステントはストレージ・バケットにハッシュされる • 複数のエクステントは 同じストレージ・バケットに割り当てることが可能 • Oracle Database 23aiは マッピングテーブルをキャッシュする • エクステントは、 割り当てられたファイル・テンプレートに従って 冗長的に格納される • High Redundancy – 3つの複製 • Normal Redundancy – 2つの複製 Exascale アーキテクチャ Copyright © 2026, Oracle and/or its affiliates 168 自動でかつ透過的 管理不要 Database Datafile 8MB 8MB 8MB 8MB 8MB 8MB 8MB 8MB 8MB Hash(Extent#) Exascale Mapping Table 0 Location Bucket Pri, Sec, Ter 1 2 3 ... … … ... ... ... ... Exadata 24.1 〜
161. マッピング・テーブルは、現在エクステントが格納されている各ストレージ・バケットのディスク・ドライブをトラック Exascale アーキテクチャ Copyright © 2026, Oracle and/or its affiliates 169 マッピング・テーブルには、 すべてのエクステント・ミラーの場所(ストレージサーバー、ディスク・ドライブ)が格納される Mirror Mirror Mirror Exadata Exascale Storage Pool Database Datafile 8MB 8MB 8MB 8MB 8MB 8MB 8MB 8MB 8MB Exascale Mapping Table 0 Location Bucket Pri, Sec, Ter 1 2 3 ... … … ... ... ... ... Hash(Extent#) Exadata 24.1 〜
162. Exascale アーキテクチャ メタデータをスケーリング不要でスケーラビリティを実現 • マッピング・テーブルは、固定数のストレージ・バケットを定義 • ストレージ・バケットの数は？: • 数千台のストレージ・サーバーにデータを分散するのに十分な大きさ • データベース・サーバーのDRAMにマッピング・テーブルをキャッシュ可能な 小ささ • データベースが大きくなる、ないしはデータベース数が増える、ないしは ストレージ・サーバーが追加されると、 既存のストレージ・バケットへのエクステント・ハッシュが増加 • マッピング・テーブルは増大しない 170 Copyright © 2026, Oracle and/or its affiliates Exascale Mapping Table 0 Location Bucket Pri, Sec, Ter 1 2 3 ... … … … … … … データがスケールした際も、メタデータのスケーリングは不要 Exadata 24.1 〜
163. Exadata Exascale Storage Pool Exascale アーキテクチャ マッピング・テーブルはストレージ側で管理される Copyright © 2026, Oracle and/or its affiliates 171 Exascale Mapping Table 0 Location Bucket 1 2 3 ... … … … … … … • エクステントの マッピング・テーブルは ストレージ・サーバー内で 自動的に管理される • エクステントの マッピング・テーブルは 高可用性と拡張性を実現 するために レプリケートされて、 分散されて管理 Exadata 24.1 〜
164. Exascale アーキテクチャ ストレージへのダイレクトI/Oパス Copyright © 2026, Oracle and/or its affiliates 172 Exascale Mapping Table 0 Location Bucket 1 2 3 ... … … … … … … • マッピング・テーブルは、 各データベース・サーバーと 各データベース・インスタンスで 自動的に透過的にキャッシュ される • データベースは、 インテリジェントなI/Oリクエスト をExadataストレージ・サーバー に直接送信可能 Mirror Exadata Exascale Storage Pool Exadata Database Server RDMA Cached Exadata 24.1 〜
165. Exascale アーキテクチャ マッピング・テーブルのインテリジェントなリフレッシュ Copyright © 2026, Oracle and/or its affiliates 173 疎結合アーキテクチャで拡張性を実現 • サーバー間でのデータの再分散 時の分散ロックは不要 • クライアントのデータベースが キャッシュの失効により I/Oを間違ったストレージ・サー バーに送信した場合、 ストレージ・サーバーはI/Oを拒 否し、 データベースにマッピング・テー ブルをリフレッシュするように指 示 • I/Oが正しいストレージサー バーに再送信される I/Oが拒否されると マッピング・テーブル のリフレッシュ指示 Exascale Mapping Table 0 Location Bucket 1 2 3 ... … … … … … … Mirror Exadata Exascale Storage Pool Exadata Database Server Cached Exadata 24.1 〜
166. • ストレージ・プールは同一メディアタイプのストレージサー バー全体にまたがったプールディスク・リソースの集合体 • High Capacity、 Extreme Flash、HC-Z、XT • ストレージ・プールは、 以下のストレージ機能を提供し、断片化を排除: • 多数のテナント、多数のクラスタ−・グリッドに対応する容量 • 複数の冗長性タイプ(NORMALおよびHIGH) • 異なるcontent_type- DATAおよびRECO • データベースのスナップショット、クローン • ストレージプールは、 さまざまな世代のハードウェアを使用し、 さまざまなサイズのディスクを組み込むことが可能 Exascale Storage Pools Copyright © 2026, Oracle and/or its affiliates 174 Exadata High Capacity Storage Server Pool Disk Pool Disk Pool Disk Pool Disk Pool Disk Pool Disk Pool Disk Pool Disk Pool Disk Pool Disk Pool Disk Pool Disk HC Storage Pool Exadata 24.1 〜
167. Exadata Exascale Storage • Exascale Vault とはストレージ・プールによって提供される物理 リソースをホスト・ファイルに表示する論理コンテナ • Vault とは？: • ファイルを含む最上位ディレクトリのように表示 • パス名は“@（アットマーク）”の文字で開始 • 権限を介したアクセス制御を提供 • 明示的な権限無しで他のファイルにアクセスできない 複数のユーザー、クラスタ、テナント間で共有可能 • データベースは、 VaultをOracle Managed Files (OMF)を作 成する記憶域の宛先として使用 • Vault内のファイルは、Redundancy(冗長性)、CONTENT TYPE(コンテンツタイプ)、を複数の異なる構成にすることが可 能 Exascale Vault Copyright © 2026, Oracle and/or its affiliates 175 Tenant A Cluster @Vault_A 100TB Tenant B Cluster @Vault_B 50TB Exadata 24.1 〜
168. Exascale Vault リソース管理 Vaultにはストレージ・リソースが割り当てられる • Storage Size –永続的なストレージの容量 • Performance –読取り/書込みIOPS、スキャンの帯域幅、をマップ • Flash Cache Size • XRMEM Cache Size • Flash Log リソースは独立して動的に変更可能 • 顧客の柔軟性の向上 @OLTP HC Size : 1TB IOPS : 800K Flash Cache Size: 300GB XRMEM Cache Size: 20GB @DW HC Size : 1TB IOPS : 100K Flash Cache Size: 800GB XRMEM Cache Size: 20GB @DEV HC Size : 1TB IOPS : 200K Flash Cache Size: 30GB XRMEM Cache Size: 2GB Copyright © 2026, Oracle and/or its affiliates 176 Exadata I/O Resource Manager (IORM)との統合 Exadata 24.1 〜
169. Exascaleでは開発、テスト用のデータベース(またはPDB)クローンを迅速に作成 • フル・コピーまたはシン・クローンを作成する機能 • ライブ・データベース/ライブ・PDB、または既存のスナップショットから作成 • クローンのクローンから独立 • アップストリームの依存関係なし- 読取り専用テスト・マスターが不要 クローンではExascale redirect-on-write テクノロジを活用 • 変更が発生するまではクローンの親とブロックを共有 • クローニングに必要なストレージ容量を劇的に削減 データベース対応のインテリジェント・クローン 開発・テスト用 シン・クローン 本番 データベース 開発、テスト、リカバリ・コピーでのExadataネイティブ・パフォーマンスを実現 Copyright © 2026, Oracle and/or its affiliates 177 Exadata 24.1 〜
170. Exascale アーキテクチャ スケーラブルな分散クローン Copyright © 2026, Oracle and/or its affiliates 178 データベースがストレージ・サーバー に新しいクローンの作成を指示す ると、各ストレージ・サーバーは スナップショットされたデータへの ローカル・アウトオブプレース書込み を実行 高速、スペース効率が高い、 最小限のコピー Exascaleによりスケーラブルな分散クローンが提供 Exadata Exascale Storage Pool Exadata Database Server Exadata 24.1 〜
171. データベース対応のインテリジェント・クローン 同じコンテナ・データベースに プラガブル・データベースの シン・クローンを作成 異なるコンテナ・データベー スへのプラガブル・データベー スのシン・クローニング プラガブル・データベースの スナップショット・カルーセル - 数分ごとの新しいスナップ ショット ソース・データベースの スナップショット・ファイルを 使用したデータベース全体 のシン・クローン 読取り/書込みが可能なソースPDB/DBへのインスタントに作成できる領域効率に優れたクローン SQL> CREATE PLUGGABLE DATABASE pdb1c FROM pdb1@CDB1_link SNAPSHOT COPY; # gDBClone.bin snap \ –sdbname CDB1 \ –tdbname CLONE SQL> ALTER PLUGGABLE DATABASE pdb1 SNAPSHOT MODE EVERY 2 hours; SQL> CREATE PLUGGABLE DATABASE pdb1c FROM pdb1 SNAPSHOT COPY; Copyright © 2026, Oracle and/or its affiliates 179 Exadata 24.1 〜
172. Exadata Database Server Exadata Database Server ACFS、Linuxファイルシステムでのきわめて高い パフォーマンスI/Oを提供 • 従来のブロックI/Oに対する極めて低いレイテンシと 極めて高いスループット 仮想マシン・イメージをインテリジェントな 共有ストレージに配置可能 • RDMA対応のVMのライブ・マイグレーション基盤を 提供 データベース内のデータに加えて、ファイル・システム 上のデータに対して、領域効率の優れた高パフォー マンス・ボリューム・スナップショット、クローンを提供 Exadata Volumes Copyright © 2026, Oracle and/or its affiliates 180 RDMA対応のブロック・ボリューム Exadata Exascale Storage Customer VM1 Customer VM2 HR RAC Database VM1 Volumes VM2 Volumes @HR_Vault RDMA RDMA Exadata 24.1 〜
173. Improved Free Space Management in Exascale Exascaleストレージ・プールは、ディスク障害発生時に リバランスが正常に完了できることを保証するための 空き領域を予約 必要な空き領域のサイズは、ストレージ・サーバーの数と ディスクドライブ・サイズによって決定 • 3台のストレージ・サーバーの場合、 各ストレージ・サーバーが障害グループになるため、 障害が発生したディスクドライブの内容を 同じサーバー内で再構築することが必要 ファイルの冗長性に関係なく、 ストレージ・プールの空き領域予約サイズは同じ • ストレージプールは異なる冗長性のファイルをサポート Exascaleストレージ・プールのリバランスのための予約済空き領域の削減 Copyright © 2026, Oracle and/or its affiliates 181 0 5 10 15 20 25 30 3 4 5 6 7 8 9 10 20 50 100 Free Space (%) ストレージ・サーバーの台数 リバランスが成功するためにストレージ・プールに 予約されている空き領域 X8M-X10M HC X8M-X9M EF X8M-X10M 1/8th Rack HC X10M EF Exascaleは ストレージ・サーバーが追加されると、 3%の空き領域を予約 3% Exadata 25.1 〜
174. Creating an Exascale Volume Clone Directly from an Existing Volume Exadata System Software 24.1では、 シン・クローン・ボリュームは ボリューム・スナップショットからのみ作成可能 1. ボリュームからボリューム・スナップショットを作成 2. ボリューム・スナップショットからのシン・クローンを作成 同じ時点から複数のシン・クローン・ボリュームを作成する場合に 役立つ Exadata System Software 25.1では、 ボリュームから直接シン・クローンを作成可能に • ボリューム・シン・クローンの作成が高速化- 2つの制御操作で はなく1つの制御操作に ボリュームの単一のシン・クローンが必要な場合に役立つ Exascaleボリュームのシン・クローン作成の簡略化 Copyright © 2026, Oracle and/or its affiliates 182 Exascale Volume Exascale Volume Snapshot Exascale Volume Thin Clone 1 2 Exascale Volume Exascale Volume Thin Clone 1 @>mkvolumesnapshot @>mkvolume --attributes volumeSnapshot= <volume_snapshot_GUID> @>mkvolume --attributes volumeSnapshot=<volume_GUID> Exadata 25.1 〜
175. デルタ・トラッキングを使用してExascaleを独自に再構築し、耐久性を向上 Improved Data Durability with Exascale Delta Tracking ディスクに障害が発生すると、次の2つのアクションが同時に実行される 1. 新しい書込みは、残りのオンライン・ディスクのデルタ（差分）として追跡される 2. システムはすぐに使用可能な他のディスク上のデータ冗長性の再構築を開始 障害が発生したディスクがあとでオンラインに戻った場合は、 格納されたデルタを適用して冗長性を完全に復元することが可能 デルタ・トラッキングにより、複数のディスクに障害が発生した場合でも、 障害が発生した1つのディスクをオンラインに戻しただけで、すべてのデータがリストアされ、耐久性が向上する 183 Copyright © 2026, Oracle and/or its affiliates Exadata 25.2 〜
176. インテリジェントなExascaleストレージ・プールの空き領域管理 Exascale Intelligent Free Space Management ストレージ・プールは、ディスク障害後にデータ冗長性を 再構築するための十分な空き領域維持が必要 すべてのディスクが健全である間に空き容量が最小値を 下回ると、低容量アラートが発行され、 将来のディスク障害によって冗長性の再構築が妨げられ る可能性があることを示す ディスクに障害が発生し、領域が不十分な場合、 冗長性再構築プロセスは一時的に一時停止され、 十分な領域が使用可能になると自動的に冗長性再構 築プロセスが再開される 184 Copyright © 2026, Oracle and/or its affiliates 健全なストレージプール 1 ストレージ・プールの空き 領域が少なくなると警告 2 ディスク障害 再構築一時停止 3 不要なファイルを削除 4 再構築が再開される 5 Exadata 25.2 〜
177. ボリューム間のExascaleボリューム・グループにより、仮想マシン管理が簡素化 Exascale Volume Groups Exascaleボリュームを使用して仮想マシン・イメージを 格納し、より高いVM統合を実現 管理を簡素化するために、escliコマンドを使用して、 VMのすべてのファイル・システム・ボリュームを 単一のボリューム・グループにグループ化可能に 185 Copyright © 2026, Oracle and/or its affiliates @> mkvolumegroup VolGroup Created volume group with id volgrp0001_5537ec085c464abd81ecfbf02c2048f3 @> chvolumegroup volgrp0001_5537ec085c464abd81ecfbf02c2048f3 --attributes volumes="+vol0001_b7194184a5484de5a7b6d4df2fd91cd0" Altered volume group with id volgrp0001_5537ec085c464abd81ecfbf02c2048f3 KVM Host Guest System vault / OS /dev/sda Volume Group Grid home DB home /…/grid /dev/sdb /…/dbhome /dev/sdc 空のボリューム・グループ の作成 新しく作成したボリュー ム・グループにボリューム を追加 Exadata 25.2 〜
178. 関連するボリューム全体で一意のポイントインタイム一貫性スナップショット Exascale Volume Groups 仮想マシンのスナップショットを作成するには、すべてのボリュームにわたってポイントインタイムの 一貫性スナップショットを作成する必要がある mkvolumegroupsnapshotコマンドは、ボリューム・グループを指定すると、ボリューム・スナップショットの 一貫したセットを作成 186 Copyright © 2026, Oracle and/or its affiliates @> mkvolumegroupsnapshot volgrp0001_5537ec085c464abd81ecfbf02c2048f3 Created volume group snapshot with id 1:5537ec085c464abd81ecfbf02c2048f3_20250616T005723 @> lsvolumesnapshot --filter volumeGroupSnapshot="1:5537ec085c…2048f3_20250616T005723" id name vol0001_b7194184a5484de5a7b6d4df2fd91cd0 OS vol0002_fc11fdb2a2f74f0a8ed5b7a4769a07cd DB_HOME vol0003_47772c61e0a24308a207f0c9157fc5d4 GI_HOME 一貫したポイントインタイム・ バックアップまたはクローンの ためのボリューム・グループ・ スナップショットの作成 指定されたボリューム・ グループ・スナップショットIDの ボリューム・スナップショットを リスト Exadata 25.2 〜
179. Exadata Softwareメンテナンス
180. Exadata Live Update 機能による Exadata の可用性の向上 Exadata Live Updateは、システムの再起動なしでセキュリティ(CVE)修正およびその他のLinuxパッケージを適 用 OSの更新中にExadata VM、ハイパーバイザおよびベア・メタルDBノードの高可用性を実現 • Oracle Linux 8 - ESS 23.1→ ESS 24.1.x で実行されているすべてのExadataシステムで動作 • Oracle Linux 7 - ESS 22.1、ESS 23.1 → ESS 24.1.x で実行されているExadata Xen Dom0で動作 • （OS のメジャーアップデートは非対応） Exadata Live Update Improves Exadata High Availability Copyright © 2026, Oracle and/or its affiliates 188 Exadata Database Server Exadata 24.1 〜
181. Simpler Management of Additional Software Packages During Database Server Updates お客様は、セキュリティ、監視、バックアップ・ユーティリティなどのサードパーティ・ソフトウェアを Exadataにインストールする これらのユーティリティには、多くの場合、厳選されたExadataリポジトリに対する追加のLinux RPMの依存関係がある 新しい patchmgr のオプションで、Exadata以外のソフトウェア・パッケージを Exadataデータベース・サーバー更新の一部としてインストールまたは更新可能に データベース・サーバー更新中のサード・パーティ・ソフトウェアの削除および再インストールを 回避することが可能に • patchmgr --precheckを使用してパッケージの依存性を検証 • Exadataデータベース・サーバー・ソフトウェアとお客様追加rpmパッケージを同時に更新 よりシンプルなLinuxパッケージ依存性管理 Copyright © 2026, Oracle and/or its affiliates 189 Exadata Database Server $ patchmgr --precheck | --upgrade [ { --additional-rpms } | --additional-rpms-list } [ --additional-rpms-from-repo ] 3rd Party package dependencies Exadata Software Updates $ patchmgr Exadata 25.1 〜
182. Simpler Management of Additional Software Packages During Database Server Updates 2つの操作フェーズ: 1. Precheck – additional_rpmsのディレクトリに存在する必須パッケージに繰り返しテストが実行され、 依存関係が解決される 2. Upgrade –データベース・サーバーの更新と追加rpmsの更新およびインストールを適用 よりシンプルなLinuxパッケージ依存性管理 Copyright © 2026, Oracle and/or its affiliates 190 $ patchmgr --dbnodes db_group --precheck --iso_repo /u01/exadata_ol8_25.1.0.0.0.241130_linux-x86-64.zip --target_version 25.1.0.0.0.241130 --log_dir auto --additional_rpms /u01/additional_rpms/repo/ $ patchmgr --dbnodes db_group --upgrade --iso_repo /u01/exadata_ol8_25.1.0.0.0.241130_linux-x86-64.zip --target_version 25.1.0.0.0.241130 --log_dir auto --additional_rpms /u01/additional_rpms/repo/ /u01/additional_rpms/repo/ (example contents) • elfutils-debuginfod-client-0.190-2.el8.x86_64.rpm • elfutils-libelf-devel-0.190-2.el8.x86_64.rpm • keyutils-libs-devel-1.5.10-9.0.1-el8.x86_64.rpm • krb5-devel-1.82.2-28.0.1-el8.x86_64.rpm Exadata 25.1 〜
183. Learn More oracle.com/exadata Copyright © 2026, Oracle and/or its affiliates 191