Oracle RAC バックアップとアーカイブ出力先の最適解

RAC

Oracle RAC環境でバックアップやアーカイブログを各ノードのローカルに保存していませんか?本記事では、Oracle RAC バックアップを共有領域(ASM)へ配置すべき理由と、高速リカバリ領域(FRA)を使用するメリットを、ローカル保存が招くリカバリ失敗の実機例と共に詳しく解説します。

💰 【PR】Oracleエンジニアの市場価値、調べてみませんか?

Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか?


結論:RAC運用で推奨される配置ルール

Oracle RACにおいて、バックアップとアーカイブログを共有ストレージ(主にASM)に配置することは、システムの可用性を担保するための鉄則です。

  1. アーカイブ出力先: 全ノードからアクセス可能なASM上の共有領域(FRA)に格納する。
  2. バックアップファイル: ノードを問わずリストアができるよう共有領域に書き出す。
  3. FRA(高速リカバリ領域)の活用: 管理の自動化と、RACインスタンス間での整合性維持のためにFRA(Fast Recovery Area)を使用する。

なぜ共有領域への配置が必要なのか?

Oracle RAC(Real Application Clusters)は複数のインスタンスが1つのデータベースを共有する構成です。各ノードが個別のローカルディスク(例:/u01/app/oracle/arch)にファイルを保存してしまうと、以下の致命的なリスクが発生します。

用語の定義:共有領域とFRA

  • 共有領域(Shared Storage): 全ノードから同時に読み書き可能な領域。主にASM(Automatic Storage Management)が利用されます。
  • FRA(Fast Recovery Area): バックアップ、アーカイブログ、制御ファイル、フラッシュバックログなどを一元管理するOracle推奨の専用領域です。

初心者向け一口メモ:

RACでは「自分のノードで生成したログ」を「他ノード」が読み取れる状態にしておく必要があります。これができないと、片方のノードが壊れた瞬間に、もう片方のノードで復旧作業ができなくなります。


致命的な落とし穴:ローカル保存によるリカバリ失敗の実機例

各ノードのローカルディスクにアーカイブログを出力している環境で、ノード2がダウンしたと仮定した際のリカバリ失敗例を実機ログで確認します。

1. 前提条件

  • 2ノードRAC環境(インスタンス名:v19rac1, v19rac2)
  • 各ノードの LOG_ARCHIVE_DEST_1 がローカルパスに設定されている。

2. リカバリ実行時のエラーログ

ノード1からリカバリを試みると、ノード2側で生成されたログ(Thread 2)にアクセスできず失敗します。

[oracle@v19rac1 ~]$ rman target /

RMAN> recover database;

recoverを26-05-09で開始しています
チャネルORA_DISK_1の使用
メディア・リカバリを開始しています

-- スレッド1(自ノード)のログは見つかる
アーカイブ・ログ・ファイル名=/u01/app/oracle/arch/thread_1_seq_8.arc スレッド=1 順序=8

-- スレッド2(別ノードのローカル)のログが見つからずエラー
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: recoverコマンドが05/09/2026 01:05:22で失敗しました
RMAN-06054: スレッド2、順序3のアーカイブ・ログが必要ですが、アーカイブ・ログが見つかりません

解説:

ノード2が停止しているため、ノード1からはノード2のローカルディスクにあるログファイルを物理的に読み取ることができません。この結果、データベース全体の不整合を解消できず、復旧が完全にストップします。

[oracle@v19rac1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on 土 5月 9 00:00:53 2026
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle. All rights reserved.



Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
に接続されました。
SQL> set lin 1000
SQL> col name for a80
SQL> select inst_id,name from gv$archived_log; ★各ノードのローカルに保存されている

INST_ID NAME
---------- --------------------------------------------------------------------------------
1 /u01/app/oracle/product/19.0.0/dbhome_1/dbs/arch1_5_1199800254.dbf
1 /u01/app/oracle/product/19.0.0/dbhome_1/dbs/arch1_6_1199800254.dbf
1 /u01/app/oracle/product/19.0.0/dbhome_1/dbs/arch1_7_1199800254.dbf
1 /u01/app/oracle/product/19.0.0/dbhome_1/dbs/arch2_1_1199800254.dbf
2 /u01/app/oracle/product/19.0.0/dbhome_1/dbs/arch1_5_1199800254.dbf
2 /u01/app/oracle/product/19.0.0/dbhome_1/dbs/arch1_6_1199800254.dbf
2 /u01/app/oracle/product/19.0.0/dbhome_1/dbs/arch1_7_1199800254.dbf
2 /u01/app/oracle/product/19.0.0/dbhome_1/dbs/arch2_1_1199800254.dbf

8行が選択されました。

SQL> exit
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0との接続が切断されました。
[oracle@v19rac1 ~]$ rman target /

Recovery Manager: Release 19.0.0.0.0 - Production on 土 5月 9 00:03:13 2026
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.

ターゲット・データベース: V19RAC (DBID=3910825081)に接続されました

RMAN> list backup;

リカバリ・カタログのかわりにターゲット・データベース制御ファイルを使用しています

バックアップ・セットのリスト
===================


BS Key Type LV Size Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ --------
1 Full 1.48G DISK 00:01:26 26-05-08
BPキー: 1 ステータス: AVAILABLE 圧縮: NO タグ: TAG20260508T235618
ピース名: /u01/app/oracle/product/19.0.0/dbhome_1/dbs/014nkm92_1_1
バックアップ・セット1のデータファイルのリスト
File LV Type Ckp SCN Ckp時間 Abs Fuz SCN Sparse Name
---- -- ---- ---------- -------- ----------- ------ ----
1 Full 2066092 26-05-08 NO +DATA/V19RAC/DATAFILE/system.257.1199800107
3 Full 2066092 26-05-08 NO +DATA/V19RAC/DATAFILE/sysaux.258.1199800151
4 Full 2066092 26-05-08 NO +DATA/V19RAC/DATAFILE/undotbs1.259.1199800175
5 Full 2066092 26-05-08 NO +DATA/V19RAC/DATAFILE/undotbs2.265.1199800581
7 Full 2066092 26-05-08 NO +DATA/V19RAC/DATAFILE/users.260.1199800177

BS Key Type LV Size Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ --------
2 Full 18.89M DISK 00:00:02 26-05-08
BPキー: 2 ステータス: AVAILABLE 圧縮: NO タグ: TAG20260508T235805
ピース名: /u01/app/oracle/product/19.0.0/dbhome_1/dbs/c-3910825081-20260508-00
SPFILEも含まれます: 修正時間: 26-05-08
SPFILE db_unique_name: V19RAC
含まれている制御ファイル: Ckp SCN: 2066193 Ckp時間: 26-05-08

RMAN> list archivelog all;

データベースdb_unique_name V19RACのアーカイブ・ログ・コピーのリスト
=====================================================================

Key Thrd Seq S Low時間
------- ---- ------- - --------
1 1 5 A 25-04-30
名前: /u01/app/oracle/product/19.0.0/dbhome_1/dbs/arch1_5_1199800254.dbf

2 1 6 A 26-05-08
名前: /u01/app/oracle/product/19.0.0/dbhome_1/dbs/arch1_6_1199800254.dbf

3 1 7 A 26-05-08
名前: /u01/app/oracle/product/19.0.0/dbhome_1/dbs/arch1_7_1199800254.dbf

4 2 1 A 25-04-30
名前: /u01/app/oracle/product/19.0.0/dbhome_1/dbs/arch2_1_1199800254.dbf


RMAN> exit


Recovery Managerが完了しました。
[oracle@v19rac1 ~]$ srvctl stop database -db v19rac
[oracle@v19rac1 ~]$ srvctl start database -db v19rac -startoption mount
[oracle@v19rac1 ~]$ srvctl status database -db v19rac
Instance v19rac1 is running on node v19rac1
Instance v19rac2 is running on node v19rac2
[oracle@v19rac1 ~]$ rman target /

Recovery Manager: Release 19.0.0.0.0 - Production on 土 5月 9 00:06:05 2026
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.

ターゲット・データベース: V19RAC (DBID=3910825081、未オープン)に接続されました

RMAN> restore database;

restoreを26-05-09で開始しています
リカバリ・カタログのかわりにターゲット・データベース制御ファイルを使用しています
チャネル: ORA_DISK_1が割り当てられました
チャネルORA_DISK_1: SID=20 インスタンス=v19rac1 デバイス・タイプ=DISK

チャネルORA_DISK_1: データファイル・バックアップ・セットのリストアを開始しています
チャネルORA_DISK_1: バックアップ・セットからリストアするデータファイルを指定しています
チャネルORA_DISK_1: データファイル00001を+DATA/V19RAC/DATAFILE/system.257.1199800107にリストアしています
チャネルORA_DISK_1: データファイル00003を+DATA/V19RAC/DATAFILE/sysaux.258.1199800151にリストアしています
チャネルORA_DISK_1: データファイル00004を+DATA/V19RAC/DATAFILE/undotbs1.259.1199800175にリストアしています
チャネルORA_DISK_1: データファイル00005を+DATA/V19RAC/DATAFILE/undotbs2.265.1199800581にリストアしています
チャネルORA_DISK_1: データファイル00007を+DATA/V19RAC/DATAFILE/users.260.1199800177にリストアしています
チャネルORA_DISK_1: バックアップ・ピース/u01/app/oracle/product/19.0.0/dbhome_1/dbs/014nkm92_1_1から読取り中です
チャネルORA_DISK_1: ピース・ハンドル=/u01/app/oracle/product/19.0.0/dbhome_1/dbs/014nkm92_1_1 タグ=TAG20260508T235618
チャネルORA_DISK_1: バックアップ・ピース1がリストアされました
チャネルORA_DISK_1: リストアが完了しました。経過時間: 00:01:25
restoreを26-05-09で終了しました

RMAN> recover database; ★リカバリが失敗する

recoverを26-05-09で開始しています
チャネルORA_DISK_1の使用

メディア・リカバリを開始しています

スレッド1 (順序5)のアーカイブ・ログは、ファイル/u01/app/oracle/product/19.0.0/dbhome_1/dbs/arch1_5_1199800254.dbfとしてディスクにすでに存在します
スレッド1 (順序6)のアーカイブ・ログは、ファイル/u01/app/oracle/product/19.0.0/dbhome_1/dbs/arch1_6_1199800254.dbfとしてディスクにすでに存在します
スレッド1 (順序7)のアーカイブ・ログは、ファイル/u01/app/oracle/product/19.0.0/dbhome_1/dbs/arch1_7_1199800254.dbfとしてディスクにすでに存在します
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: recoverコマンドが05/09/2026 00:07:57で失敗しました
RMAN-06053: ログが見つからないためメディア・リカバリが実行できません
RMAN-06025: スレッド2 (順序2)のアーカイブ・ログのバックアップがなく、リストアするための2066590の起動SCNが見つかりました
RMAN-06025: スレッド2 (順序1)のアーカイブ・ログのバックアップがなく、リストアするための2036010の起動SCNが見つかりました

RMAN>

推奨手順:ASM上にFRAを設定する方法

全ノードから透過的にアクセス可能なASMディスク・グループ(例:+DATA)にFRAを設定し、安全なバックアップ運用を構成します。

1. 前提条件と権限

  • 全ノードでASMディスク・グループがマウントされていること。
  • SYSDBA 権限を持つユーザーで実行。

2. FRAの設定手順(SQL*Plus)

全インスタンスに対して一括で設定を反映させます。

-- 1. FRAのサイズを定義(例:100GB)
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 100G SCOPE=BOTH;

-- 2. FRAの場所を共有領域(ASM)に指定
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '+DATA' SCOPE=BOTH;

-- 3. アーカイブログの出力先をFRAに向ける(デフォルトでUSE_DB_RECOVERY_FILE_DESTとなる)
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST' SCOPE=BOTH;
高速リカバリ領域(FRA)の基本と設定方法を徹底解説
Oracle Databaseを運用していると、バックアップやアーカイブログ、障害発生時のリカバリなど、多くの「復旧に関する情報」を扱う必要があります。そのとき重要な役割を果たすのが高速リカバリ領域(FRA:Fast Recovery Ar…

3. 設定確認(実機実行結果)

設定後、どのノードから見ても同じ共有パスにログが出力されていることを確認します。

SQL> set lin 1000
SQL> col name for a80
SQL> select inst_id, name from gv$archived_log;

   INST_ID NAME
---------- --------------------------------------------------------------------------------
         1 +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_1_seq_8.271.1232756971
         1 +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_2_seq_3.274.1232756981
         2 +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_1_seq_8.271.1232756971
         2 +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_2_seq_3.274.1232756981
SQL> set lin 1000
SQL> col name for a80
SQL> select inst_id,name from gv$archived_log; ★ASM上に保存されている

INST_ID NAME
---------- --------------------------------------------------------------------------------
1 +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_1_seq_8.271.1232756971
1 +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_1_seq_9.272.1232756975
1 +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_1_seq_10.273.1232756977
1 +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_2_seq_3.274.1232756981
2 +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_1_seq_8.271.1232756971
2 +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_1_seq_9.272.1232756975
2 +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_1_seq_10.273.1232756977
2 +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_2_seq_3.274.1232756981

18行が選択されました。

SQL> exit
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0との接続が切断されました。
[oracle@v19rac1 ~]$ srvctl stop database -db v19rac
[oracle@v19rac1 ~]$ srvctl start database -db v19rac -startoption mount
[oracle@v19rac1 ~]$ srvctl status database -db v19rac
Instance v19rac1 is running on node v19rac1
Instance v19rac2 is running on node v19rac2
[oracle@v19rac1 ~]$ rman target /

Recovery Manager: Release 19.0.0.0.0 - Production on 土 5月 9 00:32:31 2026
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.

ターゲット・データベース: V19RAC (DBID=3910825081、未オープン)に接続されました

RMAN> list backup;

リカバリ・カタログのかわりにターゲット・データベース制御ファイルを使用しています

バックアップ・セットのリスト
===================


BS Key Type LV Size Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ --------
3 Full 1.50G DISK 00:01:25 26-05-09
BPキー: 3 ステータス: AVAILABLE 圧縮: NO タグ: TAG20260509T002737
ピース名: +DATA/V19RAC/BACKUPSET/2026_05_09/nnndf0_tag20260509t002737_0.269.1232756859
バックアップ・セット3のデータファイルのリスト
File LV Type Ckp SCN Ckp時間 Abs Fuz SCN Sparse Name
---- -- ---- ---------- -------- ----------- ------ ----
1 Full 2076926 26-05-09 NO +DATA/V19RAC/DATAFILE/system.257.1199800107
3 Full 2076926 26-05-09 NO +DATA/V19RAC/DATAFILE/sysaux.258.1199800151
4 Full 2076926 26-05-09 NO +DATA/V19RAC/DATAFILE/undotbs1.259.1199800175
5 Full 2076926 26-05-09 NO +DATA/V19RAC/DATAFILE/undotbs2.265.1199800581
7 Full 2076926 26-05-09 NO +DATA/V19RAC/DATAFILE/users.260.1199800177

BS Key Type LV Size Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ --------
4 Full 18.89M DISK 00:00:02 26-05-09
BPキー: 4 ステータス: AVAILABLE 圧縮: NO タグ: TAG20260509T002904
ピース名: +DATA/V19RAC/AUTOBACKUP/2026_05_09/s_1232756944.270.1232756945
SPFILEも含まれます: 修正時間: 26-05-09
SPFILE db_unique_name: V19RAC
含まれている制御ファイル: Ckp SCN: 2077035 Ckp時間: 26-05-09

RMAN> list archivelog all;

データベースdb_unique_name V19RACのアーカイブ・ログ・コピーのリスト
=====================================================================

Key Thrd Seq S Low時間
------- ---- ------- - --------
6 1 8 A 26-05-08
名前: +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_1_seq_8.271.1232756971

7 1 9 A 26-05-09
名前: +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_1_seq_9.272.1232756975

8 1 10 A 26-05-09
名前: +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_1_seq_10.273.1232756977

9 2 3 A 26-05-09
名前: +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_2_seq_3.274.1232756981

10 2 4 A 26-05-09
名前: +DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_2_seq_4.275.1232757049


RMAN> restore database;

restoreを26-05-09で開始しています
チャネル: ORA_DISK_1が割り当てられました
チャネルORA_DISK_1: SID=19 インスタンス=v19rac1 デバイス・タイプ=DISK

チャネルORA_DISK_1: データファイル・バックアップ・セットのリストアを開始しています
チャネルORA_DISK_1: バックアップ・セットからリストアするデータファイルを指定しています
チャネルORA_DISK_1: データファイル00001を+DATA/V19RAC/DATAFILE/system.257.1199800107にリストアしています
チャネルORA_DISK_1: データファイル00003を+DATA/V19RAC/DATAFILE/sysaux.258.1199800151にリストアしています
チャネルORA_DISK_1: データファイル00004を+DATA/V19RAC/DATAFILE/undotbs1.259.1199800175にリストアしています
チャネルORA_DISK_1: データファイル00005を+DATA/V19RAC/DATAFILE/undotbs2.265.1199800581にリストアしています
チャネルORA_DISK_1: データファイル00007を+DATA/V19RAC/DATAFILE/users.260.1199800177にリストアしています
チャネルORA_DISK_1: バックアップ・ピース+DATA/V19RAC/BACKUPSET/2026_05_09/nnndf0_tag20260509t002737_0.269.1232756859から読取り中です
チャネルORA_DISK_1: ピース・ハンドル=+DATA/V19RAC/BACKUPSET/2026_05_09/nnndf0_tag20260509t002737_0.269.1232756859 タグ=TAG20260509T002737
チャネルORA_DISK_1: バックアップ・ピース1がリストアされました
チャネルORA_DISK_1: リストアが完了しました。経過時間: 00:01:26
restoreを26-05-09で終了しました

RMAN> recover database; ★リカバリが成功する

recoverを26-05-09で開始しています
チャネルORA_DISK_1の使用

メディア・リカバリを開始しています

スレッド1 (順序8)のアーカイブ・ログは、ファイル+DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_1_seq_8.271.1232756971としてディスクにすでに存在します
スレッド1 (順序9)のアーカイブ・ログは、ファイル+DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_1_seq_9.272.1232756975としてディスクにすでに存在します
スレッド1 (順序10)のアーカイブ・ログは、ファイル+DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_1_seq_10.273.1232756977としてディスクにすでに存在します
スレッド2 (順序3)のアーカイブ・ログは、ファイル+DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_2_seq_3.274.1232756981としてディスクにすでに存在します
スレッド2 (順序4)のアーカイブ・ログは、ファイル+DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_2_seq_4.275.1232757049としてディスクにすでに存在します
アーカイブ・ログ・ファイル名=+DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_1_seq_8.271.1232756971 スレッド=1 順序=8
アーカイブ・ログ・ファイル名=+DATA/V19RAC/ARCHIVELOG/2026_05_09/thread_1_seq_9.272.1232756975 スレッド=1 順序=9
メディア・リカバリが完了しました。経過時間: 00:00:02
recoverを26-05-09で終了しました

RMAN> alter database open;

文が処理されました

RMAN>

トラブルシューティング:代表的なORAエラー

症状 / エラーコード原因対処法
ORA-00257FRA(高速リカバリ領域)が満杯。V$RECOVERY_AREA_USAGE を確認。RMANで不要なアーカイブを削除するか、DB_RECOVERY_FILE_DEST_SIZE を拡張する。
RMAN-06059ログファイルが見つからない。特定ノードのローカルにログが出ていないか確認。設定を USE_DB_RECOVERY_FILE_DEST に統一する。
ORA-15041ASMディスクグループの物理空き不足。ASMに物理ディスクを追加するか、古いバックアップを削除して再編成する。

運用・監視・セキュリティ上の注意

メリットと落とし穴

  • メリット: バックアップの保存方針(Retention Policy)に基づいて、Oracleが古いファイルを自動で削除してくれます。
  • 落とし穴(リスク): バックアップジョブが失敗し続け、かつアーカイブが大量に生成されると、FRAが満杯になりDBがハング(停止)します。
  • 戻し方: ローカル出力に戻す場合は LOG_ARCHIVE_DEST_1 を個別のパスに変更しますが、RAC運用の観点からは推奨されません。

FAQ

Q1:RACでローカルディスクにバックアップを取ってはいけないのですか?

A:絶対に避けてください。ノード障害時に「生きているノード」からバックアップファイルにアクセスできず、リストアが不可能になります。

Q2:FRAを使わずにASMの任意のディレクトリに保存しても良いですか?

A:可能ですが、FRAの「自動削除機能」が使えません。手動で削除スクリプトを運用する必要があり、消し忘れによるディスクフルのリスクが増大します。

Q3:FRAのサイズは運用中に変更できますか?

A:はい。ALTER SYSTEM コマンドでオンライン中に即時変更可能です。


まとめ

  • Oracle RACでは、バックアップとログはASM等の共有領域へ配置する。
  • ローカル保存はノード障害時のリカバリ失敗(DB復旧不可)を招くため厳禁。
  • FRA(高速リカバリ領域)を利用して、容量管理の自動化と一貫した復旧体制を構築する。

本記事は Oracle Database 19c を対象に解説します(他バージョンは画面や既定値が異なる場合があります)。

[reference]
Recovery Managerの構成およびアーカイブ

Oracle RAC(Real Application Clusters) とは?仕組みとメリットを初心者向けに解説
「データベースが止まらない」仕組みとして Oracle RAC に興味をお持ちですか?RAC は複数サーバーで単一DBを稼働させ、可用性と拡張性を高める技術です。この記事では、RAC の基本的な仕組み、メリット、そして自分が接続している環境…

💰 【PR】Oracleエンジニアの市場価値、調べてみませんか?

Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか?

コメント

タイトルとURLをコピーしました