1Z0-043 · Question #178
Which two statements regarding compressed backups in Recovery Manager (RMAN) are true? (Choose two.)
The correct answer is A. Backup compression is disabled by default. E. Backup compression applies to only backup sets. See the full explanation below for the reasoning.
Question
Which two statements regarding compressed backups in Recovery Manager (RMAN) are true? (Choose two.)
Options
- ABackup compression is disabled by default.
- BBackup compression can be used with both backup sets and image copies.
- CBackup compression cannot be enabled using the CONFIGURE command.
- DBackup compression works only if the COMPATIBILITY parameter is set to 9.0.0.0 or higher.
- EBackup compression applies to only backup sets.
- FBackup compression applies to only image copies.
How the community answered
(60 responses)- A83% (50)
- B8% (5)
- C5% (3)
- D2% (1)
- F2% (1)
Community Discussion
8The correct answers are A and E. RMAN backup compression is disabled by default and must be explicitly enabled either per-session in the BACKUP command or persistently via the CONFIGURE command, and it applies exclusively to backup sets because image copies are sector-for-sector duplicates of the source files and cannot be compressed by RMAN at write time. Memory hook: "Sets can be squeezed, copies cannot." This maps to the Oracle Database 10g Administration II exam topic on RMAN backup and recovery configuration, so expect the distractor in B to trip up anyone who confuses the binary backup set format with the image copy format.
Solid on A and E, but worth flagging that if you hit this on exam day and the scenario mentions CONFIGURE COMPRESSION ALGORITHM already set, you can blow past it in about 15 seconds, so do not let the wording slow you down.
Flagged B as a contender, but compression is sets-only, not image copies.
Brenda, that is the exact distractor Oracle plants in the backup and recovery objectives, so lock it in with this hook: backup sets compress, image copies never do, and the exam will test that boundary directly.
I went with A and B at first because I figured compression would obviously work with image copies too, since my senior mentioned RMAN is flexible about backup types. What changed my mind was when he pulled up the docs and showed me that image copies are exact bit-for-bit replicas of the datafiles, so there is no way to apply compression without it no longer being a true copy, which means E is correct and B is out. And A makes sense once you think about it because Oracle defaults to no compression to avoid the extra CPU overhead unless you actually go out of your way to enable it, either per-job or through CONFIGURE. Lesson for me was to not assume that a feature being available means it works across all backup types equally.
The bit-for-bit point is solid, and the CPU-overhead framing for the default is a useful angle to hold onto for stems that try to trick you into thinking the default is compression-on because the feature exists.
A and E hold up. B is the trap most people fall into because it sounds reasonable, compression feels like it should work everywhere, but RMAN compression is a backup set feature only, image copies are block-for-block and have nothing to compress into. As for A, the default-off behavior trips people who assume Oracle enables it automatically given how storage-friendly it is, but you have to ask for it explicitly via AS COMPRESSED BACKUPSET or the CONFIGURE command.
Solid breakdown, and worth hammering home that CONFIGURE COMPRESSION ALGORITHM also lets you pick the algorithm (BASIC, LOW, MEDIUM, HIGH) so candidates should know BASIC is the default algorithm when compression is enabled, not a separate feature toggle.