Oracle Databaseの高可用性（HA）を実現する構成として、「Oracle RAC（Real Application Clusters）」と「Oracle Restart」の2つが存在します。
両者はGrid Infrastructureを利用する点では共通ですが、設計思想・構成・可用性レベル・ライセンス・運用難易度がまったく異なります。
この記事では、Oracle RACとRestartの仕組み・構成要素・用途・向いている環境を実務ベースで比較・整理し、導入判断の助けとなるよう詳細に解説します。
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
🔷 Oracle Restartとは？
Oracle Restartは、Oracle Databaseを単一ノード構成で運用する際に、以下のような機能を提供するGrid Infrastructureのスタンドアロン構成です。
- データベース、リスナー、ASM（任意構成）の自動起動・停止
- コンポーネント障害発生時の自動再起動
- 起動順序の依存関係管理（ASM → Listener → Database）
✅ クラスタ構成は取らず、1台のサーバ内でOracleリソースを安定的に管理したい場面に適しています。
🔷 Oracle RACとは？
Oracle RAC（Real Application Clusters）は、複数ノードのサーバで1つのデータベースを同時に稼働させ、高可用性とスケーラビリティを同時に実現する構成です。
- 各ノードにDBインスタンスを持ち、共有ストレージを使って1つのDBにアクセス
- ノード障害時は、別ノードで処理継続可能（フェイルオーバー）
- クライアント接続もロードバランシング対応
✅ ミッションクリティカルな業務に適し、可用性だけでなくパフォーマンスも向上します。
🧩 構成の違い：RestartとRACの全体像
🔹 Oracle Restart構成（単一ノード）
+-----------------------------+
| OS（Linux） |
+-----------------------------+
↓
+-----------------------------+
| Grid Infrastructure (Standalone) |
+-----------------------------+
├── ASM（任意）
├── Listener
└── Oracle Database（CDB or non-CDB）
🔹 Oracle RAC構成（クラスタ：2ノード以上）
共有ストレージ（ASM）
▲ ▲
│ │
+-----------------+ +-----------------+
| Node1 | | Node2 |
| - GI（Cluster）| | - GI（Cluster）|
| - ASM | | - ASM |
| - Listener | | - Listener |
| - DB Inst1 | | - DB Inst2 |
+-----------------+ +-----------------+
🔍 Oracle RestartとRACの機能比較表
| 比較項目 | Oracle Restart | Oracle RAC |
|---|---|---|
| 対象構成 | 単一ノード | 複数ノード（2台以上） |
| 高可用性の範囲 | OS/プロセスレベル | ノードレベル（サーバ故障時も継続） |
| データベース数 | 1インスタンス | 複数インスタンス（同一DB） |
| スケールアウト | 不可 | 可能（ノード追加で性能拡張） |
| 使用ストレージ | ローカル or ASM | 共有ディスク（ASM必須） |
| 使用するGrid構成 | Standalone構成 | Clustered構成 |
| OCR/Voting Disk | OCRのみ | OCR + Voting Disk |
| 自動起動 | あり（Restart機能） | あり（Clusterware） |
| 障害時の復旧 | 自動再起動（プロセス単位） | 他ノードへ自動フェイルオーバー |
| 負荷分散 | なし | あり（アプリサービス単位） |
| ライセンス条件 | EEまたはSE2 | EE + RACオプション |
| 運用コスト | 比較的低い | 高い（ソフト・ハード・人的コスト） |
| 管理の複雑さ | やや低い | 高い（RAC特有の管理知識が必要） |
✅ Oracle Restartの特長と活用場面
主なメリット
- DB/リスナー/ASMの自動起動・再起動が可能
- Grid Infrastructureの導入のみで使用可能（RACオプション不要）
- ASMとの連携でストレージ管理も自動化
- コストが低く、導入ハードルが低い
想定シーン
- 単一ノード構成でOracleを使いたい
- サーバ障害時のプロセスレベルの可用性確保ができれば十分
- ASMを使ってストレージを柔軟に管理したい
- 最小構成で商用運用をしたい中小規模システム
✅ Oracle RACの特長と活用場面
主なメリット
- ノード障害時に自動フェイルオーバー
- 負荷分散可能（複数インスタンス）
- ノード追加によるスケーラビリティ
- サービス単位でのクライアント接続制御（TAFなど）
想定シーン
- 24時間365日稼働が必須の基幹業務
- パフォーマンス向上と可用性の両立が必要
- 数千以上の同時接続が発生するWebシステム
- ハード／ライセンスコストが確保できる
🛑 注意：Restart ≠ 簡易版RAC
RestartとRACは似た機能を一部持ちますが、Restartはあくまで「自動再起動の補助」レベルの可用性です。RACのように、サーバそのものが故障しても別ノードで稼働を継続するようなフェイルオーバー機能はありません。
Restartで確保できるのはOS・プロセスレベルでの可用性、RACで確保できるのはノードレベルの可用性です。
🧠 実務での選定判断
| 判断基準 | 推奨構成 |
|---|---|
| 単体サーバで運用（冗長性不要） | Oracle Restart |
| 業務継続性重視（障害時も止めたくない） | Oracle RAC |
| 数十人程度のアクセス、コスト優先 | Oracle Restart |
| 数百〜数千接続、パフォーマンスと可用性重視 | Oracle RAC |
| ストレージの集約・再編成を行いたい | RestartまたはRAC（ASM利用） |
📝 まとめ
| 項目 | Oracle Restart | Oracle RAC |
|---|---|---|
| 可用性レベル | 中（自動再起動） | 高（ノード障害対応） |
| スケーラビリティ | なし | あり（ノード追加） |
| 運用難易度 | 低～中 | 高 |
| コスト | 低～中 | 高 |
| 使用用途 | 中小規模、商用 | 基幹系、ミッションクリティカル |
Oracle Restartはシンプルな単一ノード構成での可用性・自動化を担保し、Oracle RACは大規模システム向けに可用性とスケーラビリティの両立を実現します。
導入にあたっては、コスト・可用性要求・障害発生時の業務影響・将来の拡張性などを総合的に考慮した上で適切な構成を選びましょう。
[参考]
Clusterware管理およびデプロイメント・ガイド
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
コメント