1Z0-058 · Question #104
You need to set up a three-Instance RAC database. The data files and fast recovery area will be stored in ASM diskgroups called +data and +fra, respectively. The ASM disk groups will be mounted on…
The correct answer is A. Cluster File System with each instance writing to a shared location C. the ASM diskgroup +fra with the db_recovery_file_dest parameter set to the same value on all. The primary consideration when configuring archiving is to ensure that all archived redo logs can be read from every node during recovery, and if possible during backups. During recovery, because the archived log destinations are visible from the node that performs the…
Question
You need to set up a three-Instance RAC database. The data files and fast recovery area will be stored in ASM diskgroups called +data and +fra, respectively. The ASM disk groups will be mounted on all ASM Instances. Which are the two best location options for archivelogs so that they can be accessed during recovery without DBA intervention?
Options
- ACluster File System with each instance writing to a shared location
- BCluster File System with each instance writing to a separate location as long as all the locations
- Cthe ASM diskgroup +fra with the db_recovery_file_dest parameter set to the same value on all
- Da raw or block device
How the community answered
(16 responses)- A81% (13)
- B6% (1)
- D13% (2)
Explanation
The primary consideration when configuring archiving is to ensure that all archived redo logs can be read from every node during recovery, and if possible during backups. During recovery, because the archived log destinations are visible from the node that performs the recovery, Oracle RAC can successfully recover the archived redo log data. The fast recovery area for an Oracle RAC database must be placed on an Oracle ASM disk group, a cluster file system, or on a shared directory that is configured through a network file system file for each Oracle RAC instance. In other words, the fast recovery area must be shared among all of the instances of an Oracle RAC database. The preferred configuration for Oracle RAC is to use Oracle Automatic Storage Management (Oracle ASM) for storing the fast recovery area, using a different disk group for your recovery set than for your data files. The location and disk quota must be the same on all instances. Oracle recommends that you place the fast recovery area on the shared Oracle ASM disks. In addition, you must set the DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE parameters to the same values on all instances. Oracle Database 2 Day + Real Application Clusters Guide
Topics
Community Discussion
6
Grace U.Dec 19, 2025A and C are your two best picks here, because both give every node in the cluster a way to reach the archivelogs without someone having to manually copy or redirect anything. A shared Cluster File System location and the +fra ASM diskgroup both satisfy that single requirement that matters most in RAC recovery, which is that any instance can find those logs on its own the moment it needs them.
Anjali D.Dec 20, 2025Grace nailed the core point, though I'd add that between A and C, the +fra ASM diskgroup tends to be the safer pick in practice because a shared CFS adds a dependency on the underlying cluster filesystem staying healthy, and if that layer hiccups during recovery you have compounded failure modes to deal with.
Prof. SaraNov 29, 2025Option B is the classic trap because the sentence gets cut off mid-thought and students assume the implied ending makes it valid, but a shared single path on the CFS (option A) is cleaner and eliminates the cross-instance path mapping headache that B quietly introduces. Lock in A and C, since the +fra diskgroup mounted on all ASM instances with a uniform db_recovery_file_dest is exactly the kind of "zero-intervention" recovery path the question is testing you on.
Imani T.Dec 1, 2025Solid breakdown, though worth flagging that "zero-intervention" only holds if all nodes have the same ASM_DISKGROUPS initialization parameter actually listing +fra, because a diskgroup mounted on the cluster but missing from that parameter on even one instance will silently route archivelogs to a different destination and bite you on a targeted instance recovery.
Anjali D.Jan 2, 2026Our group landed on A and C as the two best options, and I think that holds up. The key phrase in the question is "without DBA intervention," which means recovery needs to find the archivelogs automatically, so any solution where logs are scattered across separate instance-specific locations falls apart unless someone manually registers them. Option A works because a shared CFS location gives every node read access to all archivelogs regardless of which instance wrote them. Option C is arguably the cleanest fit for this scenario since +fra is already mounted on all ASM instances and setting db_recovery_file_dest to the same value cluster-wide means RMAN tracks everything in one unified recovery area. Anyone want to weigh in on whether B could ever be viable with a catalog, or is that too much of a stretch for what the question is asking?
Imani T.Nov 26, 2025A is solid and C is the one you really want burned into your brain before test day. The whole point is that every node needs to reach those archivelogs during recovery without someone SSHing around manually copying files, so a shared CFS location or ASM with a consistent db_recovery_file_dest covers that requirement cleanly. B is the trap answer because it sounds reasonable until you read the fine print, separate locations mean the recovering instance may not know where another instance wrote its logs, and that is exactly the kind of manual intervention the question is telling you to eliminate. D with raw devices is a dead end for archivelog sharing in RAC, that approach died out before most people studying this exam even started their IT careers. Lock in A and C, skip the noise.