On the Oracle Database Appliance, the default deployment only gives you a single control file.

I find this a little puzzling. The single control file causes a policy violation in the automatically configured Enterprise Manager DB Console and Oracle's recommendation is still, as far as I can tell, that you should always have at least two control files on separate drives and file systems. Personally, I've always had three copies, just to be on the safe side.

The ODA is configured with ASM and does have a good bit of storage redundancy using triple mirrored drives. Is it OK to run with a single control file in this configuration?

Adding a second control file to the same disk group might not make much sense, would multiplexing the control files to the SSD disk group or perhaps the OS drives of each node make more sense?


KISS principle: Do you have the storage that itself offers you the required availability level (i.e. disk array)? And you do have RMAN backups with a recovery catalog (you need it anyway, for DUPLICATE), don't you? If yes and yes, my version is: no secondary control file at all, one member per each redo group, as there are no secondary datafiles (quite obviously, even for system01.dbf) or no secondary archivelogs.

Otherwise your database is unnecessarily doing stuff that belongs on the storage level. I would just leave storage things on the storage level - the mirror is done there, and it is done effectively. Or, if you want cross-site mirror, do it on ASM level. Database is occupied with database-related processing. The software mirroring on database level only makes sense if you use bare hard disks.

Most people conservatively stick to having three control files, though. Probably Oracle support would also recommend you to use three.

Not only I've never practically benefited from having a second or a third control file; I'm unable to think of a scenario when secondary copy would be justified (i.e. it provides some benefit for the lack of simplicity). Logical corruption in control file would be propagated to a second control file, just as in case of hardware mirroring. Physical corruption wouldn't be propagated in either case. If storage fails, you lose redo or data - you need to restore via RMAN anyway. You lose control file, you can restore it with RESTORE CONTROLFILE, which only costs extra minute at most. If you've lost redo, the recovery is incomplete. If you didn't lost redo (but lost all control files), the recovery is complete de facto, but Oracle insists on OPEN RESETLOGS (loss-less in such case).

  • KISS does not apply to fault tolerant designs, at least not in the conventional way. Managed complexity in standardized component units (think lego bricks .. independent, solid, uniform and thus easily replaceable.. well relatively) appear to be the method of choice if you want to maintain four nines or better. – Roy Aug 31 '16 at 19:54
  • I'm not sure about DUPLICATE for normal cloning, I use storage supported hot cloning for that sort of thing, but I do use DUPLICATE DATABASE TO STANDBY when deploying Data Guard, which works fine with RMAN controlfile repository. I use the ODAs in a distributed redundancy model where a centralized database repository for RMAN would not really make sense. – Roy Aug 31 '16 at 21:11
  • I guess it comes down to how much you trust ASM and it's ability to maintain working copies under various scenarios. Don't have too much faith in RESTORE CONTROLFILE or USING BACKUP CONTROLFILE. If your sole control file is fubar, the autobackup tends to fry your controlfilecopy. Rather than aiming to use a backup controlfile once you find one, lacking an RMAN repository database you will likely be better of rebuilding from a control file trace and hope you get complete media recovery before attending to resurrection of the the backup catalog. – Roy Aug 31 '16 at 21:17
  • I agree my answer is too practical and it needs more FUD. – kubanczyk Sep 1 '16 at 13:52

Just make sure auto controlfile backup is turned on. If you added or dropped a datafile(s) before the controlfile was backed up, and you had a hardware failure which resulted in the single CF not be accessible, it would be a pain to restore...not impossible, just a huge pain and a time sink during a sensitive time resuming services.

Cheers, JD

  • Agreed, though better not to mess up all copies of the control file in the first place. Maybe I'm just old fashioned, but having 3 control files have been best practice for a good two decades; as it is simple, effective and incurs little overhead. Which is why I am somewhat surprised over ODA product management team defaulting, without ceremony, to just the one copy in their implementation. After all, redo is multiplexed by default and it would seem sensible to at least have plexes on +DATA (spindle) and +REDO (SSD) by default, backup controfile defaults to +RECO – Roy Aug 31 '16 at 21:27

All things considered, I don't see a reason for not having more control files on (any generation of) the ODA.

While you may never need the additional copies, they are unlikely to cause any harm, and the time spent is offset by not needing to change any habits, documents or processes - or having to fiddle with the OEM policies to accept only one control file.

Since OAK software release 12.x ODA uses ACFS, which requires some extra consideration when creating the multiplexed control files, thankfully David Hueber have put up a post explaining the process, available on his blog

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.