Cloud Control 12c Database Backup Jobs (Continued)

 

I’ve been rather critical of the way Cloud Control handles database backup jobs, as can be seen in these two previous posts.

Yesterday I found out I schedule database backups in Cloud Control the “wrong way”…

So typically, when I am sorting out a new database, I do something like this:

  • If the host doesn’t already have an agent, push one out the to server.
  • Discover the targets. For existing hosts, this may just be discovering a new database.
  • Tell Cloud Control to used the RMAN catalog for backups. (Oracle Database > Availability > Backup & Recovery > Recovery Catalog Settings)
  • Set the default location for the backups and any other stuff. (Oracle Database > Availability > Backup & Recovery > Backups Settings)
  • Finally schedule the backup. (Oracle Database > Availability > Backup & Recovery > Schedule Backups…)

Notice how all the backup-related things come from the same location (Oracle Database > Availability > Backup & Recovery). Obvious right? Wrong!

So it turns out, if you schedule the backup using the (Oracle Database > Availability > Backup & Recovery > Schedule Backups…) screen, you do schedule a backup job, it works and it is visible in the (Enterprise > Job > Activity) screen, but it is not a “real” Cloud Control job. It is actually created using the job type of “Backup”, which is not a supported job type, rather than the job type “RMANScript”.

If you schedule a backup in this way, you can’t:

  • use the job library.
  • do a create-like of an existing job.
  • edit most of the details about the job after it’s created, including the RMAN script.
  • describe the job using EMCLI.

So what is the solution? Well, you do all the prep in the same way, but you don’t actually schedule the job using the (Oracle Database > Availability > Backup & Recovery > Schedule Backups…) screen. You do it directly from the (Enterprise > Job > Activity) screen. If you do it from here, then you get to pick the “RMANScript” job type and suddenly everything works much better and things seem a lot more consistent. Basically, you’ve created a “real” Cloud Control job.

So in my latest round of [enchancement requests | bug reports] I got the answer back from development that I was doing it wrong, which is good to know, and they want to close the SR. My response to that was, why do you let me do it the “wrong way”? Why does the (Oracle Database > Availability > Backup & Recovery > Schedule Backups…) screen not schedule a “real” Cloud Control job? It seems odd to me that you build a product that lets you do things inconsistently. It’s probably a throw back to the old DBConsole stuff, but that doesn’t make it any less annoying.

I’m going to recreate all my backup jobs to make them use the “RMANScript” job type, which will solve my EMCLI issues, but I really think this mess should get cleaned up. I wonder how many other people out there are not creating “real” Cloud Control jobs for their database backups?

I’m going add this blog post to my SR and see what the response is…

Cheers

Tim…

I love Cloud Control 12c, but the job management is really annoying!

 

Cloud Control 12c is a great product. Yes, it is suffering from bloat, but generally it is a really great tool. I’m always encouraging people to ditch the DBControl and switch to Cloud Control!

Having said that, one area that annoys the hell out of me is the job management, which feels really clumsy. I started to write this post, then felt a bit guilty because I hadn’t actually bothered to raise an enhancement request, so that’s what I’ve just done!

My main gripes are the following.

  • Editing Jobs: You can edit some parameters of jobs, but not all. This is really frustrating and often means you have to delete and recreate a job in order to make a minor change.
  • Create Like: There is still no support for “Create Like” of a database backup job. Most of our jobs are database backup jobs, so this omission is quite annoying.
  • Run Now: There is no “Run Now” type of functionality on the scheduled jobs. You either have to create a new one-off job (with out Create Like), or alter the schedule, then remember to alter it back once the job has finished. A “Run Now” option that doesn’t affect the normal schedule would be really handy.
  • Backup Destination: If you use “CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/path/to/backup/%U’;” from RMAN, or use the Backup Settings screen in Cloud Control, which does the same thing, the path used for the backup works fine. If on the other hand you use the “Over Default Settings” option while creating the database backup job, the settings seem to be completely ignored. This should either work, or be removed as an option because it catches me out all the time!

OK, the last one is a bug, not an enhancement request, but I thought I would throw that into the mix anyway. :)

We are in the process of upgrading and moving databases at the moment, so amending the backup jobs is a big thing for us. Yesterday afternoon, evening and night was littered with a chorus of expletives in relation to Cloud Control job management, which gave me the activation energy to post this rant. :)

Note. Even as I rant, I am still convinced centralising your jobs in Cloud Control is a good thing!

Cheers

Tim…

Update: My enhancement request is being split into three separate SRs and they are being put forward to the development team as formal enhancement requests. Fingers crossed they will get implemented.

The fourth point is a “problem between keyboard and chair”. I misunderstood what this feature was supposed to do. My bad. :)