Anyone using OEM for scheduling backups?

Question

I'd like to see a poll for the number of users using OEM for taking database backups. Had some interesting conversations with some colleagues via social media and it seems like some DBAs don't trust OEM for their backups even though the feature works IMO.
Are you using OEM to do backups?
Edited by: DBA on May 3, 2012 1:02 PM

Answer 1

I have 91 scheduled recurring backup jobs running through OEM 12c BP1. They work quite well. I've only noticed a few problems and nitpicks:
1) Occasionally, for unknown reasons, a backup job against a newly-added database target will fail stating that the backup cannot be run since the database is closed. The database is not closed, it's up and running fine. Changing the backup job to run using SYS as SYSDBA credentials resolves this problem.
2) Identification of failed backups is not as customizable as I would like. For example, if I have a full "backup database plus archivelog" running, and during the course of that backup an archivelog backup runs and deletes archived logs, OEM will report that the backup job has failed since RMAN throws an error about not being able to backup an archivelog it expected to find. I dealt with this by adding SKIP INACCESSIBLE to the backup statement. I'm not totally comfortable about that but I monitor for offline datafiles so I consider this only a minimal risk. Our custom backup scripts used to catch this warning and ignore it.
3) It's really annoying that, after creating a backup job through the target Availability -> Schedule Backup tool, I cannot then run a 'Create Like' against that backup job to create a nearly identical one against a different database target. You have to schedule each of them from the Schedule Backup tool. Clicky clicky clicky clicky.
4) A backup job created through the 'Schedule Backup' tool has a job type of 'Database Backup', therefore when the job fails a high-availability incident is created, so you can configure incident rules to receive notification of this event. This is good. Unfortunately a backup job created from the Jobs page has a job type of 'RMAN Script' does NOT create an incident on job failure out of the box. I've had difficulty configuring incident rules to catch failures for RMAN Script job types. This is not good.
5) The repeating schedule options for jobs are limited compared even to something like cron. I can schedule a job for a day of the week, or a day of the month, but cannot easily schedule a job for "the first Tuesday of each month". This can be worked around.
6) After creating and submitting a backup job through the Schedule Backup tool, you cannot edit the RMAN script without recreating the job. You can only edit the RMAN script before submitting the job. I deal with this by having my backups run stored scripts in the recovery catalog, and make the changes there if I need to change something.
7) It is very annoying that if I 'stop' a repeating job (instead of suspend), there is no way to resume that job. It has to be recreated. This is my own user error -- I just don't click the stop button. Not OEM's fault but I'd rather not even have that button.
8) No ability to sequence jobs. You can sequence steps within a job, but then the entire job succeeds or fails as a unit. If you want to back up database A then immediately back up database B afterwards, you have to create a multi-task job. The multi-task job has the same problem as item #4 above such that it does not create a "backup failed" incident when the backup fails.
Even with all of these gripes, I am quite pleased with the backups I have running through OEM.