1Z0-058 · Question #134
orcl1, orcl2, and orcl3 are tnsnames that connect to predefined instances of a three-instance RAC database which uses ASM for shared storage. The database is in archivelog mode. Examine the Exhibit…
The correct answer is A. The database can be either mounted or open on all three instances. connectStringSpec Use the connectStringSpec subclause to specify the user name, password, and net service name for connecting to a target, recovery catalog, or auxiliary database. The connection is necessary to authenticate the user and identify the database. You must have…
Question
orcl1, orcl2, and orcl3 are tnsnames that connect to predefined instances of a three-instance RAC database which uses ASM for shared storage. The database is in archivelog mode. Examine the Exhibit for the tnsnames.ora entries for orcl1, orcl2, and orcl3. You plan to execute the following RMAN commands to back up the database:
RUN{ ALLOCATE CHANNEL CH1 DEVICE TYPE DISK CONNECT 'user1/pwd1@orcl1'; ALLOCATE CHANNEL CH2 DEVICE TYPE DISK CONNECT 'user2/pwd2@orcl2'; ALLOCATE CHANNEL CH3 DEVICE TYPE DISK CONNECT 'user3/pwd3@orcl3'; BACKUP DATABASE PLUS ARCHIVELOG; } What should be the database mode on each of the three instances for this backup to succeed?
Exhibit
Options
- AThe database can be either mounted or open on all three instances.
- BThe database must be open on all three instances.
- CThe database must be open on any one instance and mounted on the other two instances.
- DThe database must be mounted on any one of the instances and the other instances will be
How the community answered
(44 responses)- A82% (36)
- B5% (2)
- C2% (1)
- D11% (5)
Explanation
connectStringSpec Use the connectStringSpec subclause to specify the user name, password, and net service name for connecting to a target, recovery catalog, or auxiliary database. The connection is necessary to authenticate the user and identify the database. You must have SYSDBA privileges to CONNECT to a target or auxiliary database. Do not connect to the recovery catalog database as user SYS. RMAN connections to a database are specified and authenticated in the same way as SQL*Plus connections to a database. The only difference is that RMAN connections to a target or auxiliary database require the SYSDBA privilege. The AS SYSDBA keywords are implied and cannot be explicitly specified. See Oracle Database Administrator's Guide to learn about database connection options when using Oracle® Database Backup and Recovery Reference 11g Release 2 (11.2)
Topics
Community Discussion
8The answer is A, and here is why that makes sense once you think about how RMAN works with RAC and ASM. RMAN only needs the database to be at least mounted on each instance where a channel is allocated, because mounted means the control file is open and RMAN can read the file headers and catalog information it needs to do the backup. Since the storage is shared through ASM, it does not matter which instance physically reads each datafile, so open is not a requirement, just an option. Option B is too restrictive because it rules out a perfectly valid mounted state, and options C and D imply some kind of mixed requirement that RMAN does not actually enforce here. As long as every instance with an allocated channel is at least mounted, RMAN has what it needs to complete the BACKUP DATABASE PLUS ARCHIVELOG successfully.
Nina nailed the core point, though I would add that in practice most groups doing BACKUP DATABASE PLUS ARCHIVELOG in RAC keep all instances open anyway because the archivelog piece needs to sweep logs from every instance, and mounted-only nodes can complicate that sweep depending on your archivelog destination config.
Good one to pause on, because RAC changes the rules slightly from what you learn in single-instance RMAN, and the mnemonic to carry is "MO works, MO is enough" (Mounted or Open). Can you explain why a mounted but not open instance still gives RMAN everything it needs to read datafiles and archived logs from ASM shared storage, and does that change at all if the BACKUP DATABASE PLUS ARCHIVELOG clause is involved?
The mounted state is enough because RMAN authenticates via the catalog or target connection and gets the file locations from the control file, which is already available the moment instance recovery completes and the mount stage finishes, so you never needed OPEN to read datafiles or ASM paths, and BACKUP DATABASE PLUS ARCHIVELOG does not change that requirement since the archivelogs are also on shared ASM and visible to any mounted instance with the right channel configuration.
Our group got tripped up here until someone remembered RAC RMAN just needs mounted or open, not exclusively open. Answer is A, and that matched my actual exam last spring.
A is right, and the reason it works is that RMAN is flexible enough to use any instance that can see the shared ASM storage, whether it is mounted or open, because the actual data blocks are on the shared disks and not tied to any one instance's state. Just remember that at least one instance has to be available in either of those modes so the backup session has somewhere to connect.
Saw almost this exact scenario on my 1Z0-058 and panicked for a second because I kept thinking "open, it has to be open" but then remembered that RMAN in a RAC environment just needs the instances to be at least mounted, not necessarily open, so A is your answer. The ASM shared storage handles the rest and RMAN does not care if some nodes are sitting in mount mode as long as it can reach them.
Solid instinct, and worth pinning down the exact mechanism: RMAN coordinates through the catalog or control file rather than through the database layer, which is exactly why mount mode is sufficient and why you do not need every instance open, though you do want at least one node open if you are running a backup that requires reading datafiles rather than just the control file or archived logs.
