Experiments in Geekery

A thing that I repeatedly forget is how to do this.  I'm writing it down in the vague hope that I'll remember next time. Take running database, already monitored by OEM 12c.  Install new version of Oracle Home using OUI.  Try to use OEM 12c to upgrade database, but find that OEM doesn't know about the new home. How do you add the new home?  "Add target" menu doesn't work.  Where is it? Instructions are here:  https://docs.oracle.com/cd/E24628_01/doc.121/e24473/discovery.htm#EMADM13141 The secret is to create a new job, of the "Discover Promote Oracle Home Target" type.  Add in the path to the Oracle Home, let the job run, and voila.  Your new Oracle Home is now available.

Last week, we initiated a planned switchover of our primary and standby dataguard instances.  11.2.0.3, physical standby.  Dead easy. The database change went absolutely perfectly.  No problems.  Brilliant.  A 5 step process and everything did as the Oracle docs said they should. The problem... the problem was everything else. Some background: The company has been using active data guard to populate a read-only standby for about 9 months, and since it was installed have never done a switchover (or a failover).  Almost all client jobs are cron- & script-based (running on the DB host), or run manually. A week before the switch, I'd gone through a list of apps with a senior developer and checked that they all referenced a DNS name rather than an IP address.  That's a relatively short list of about 10 apps of various types and sizes. Come the switch, most things went as smoothly as you'd hope!  The vast majority of the Tomcat apps switched without a hitch.  One ap

There's an awful lot of stuff written out there about this topic, so this will be relatively brief. However, none of the posts I'll be linking to answered my question or solved my problem, that's why I'm putting this here. DST ended in the UK on Sunday 26th October with the clocks going back one hour.  From that point on, my audit log purge job, which runs daily through DBMS_SCHEDULER has been running an hour early!  I wouldn't normally have noticed as it runs in a quiet time but I happened to be looking at some other logs and spotted it wasn't right. The Oracle DBMS_SCHEDULER docs seem to have the information to sort this out: Repeating jobs with frequencies smaller than daily follow their frequencies exactly across daylight savings adjustments. For example, suppose that a job is scheduled to repeat every 3 hours, the clock is moved forward from 1:00 a.m. to 2:00 a.m., and the last time the job ran was midnight. Its next scheduled time will be 4:00 a.m.