Experiments in Geekery

[oracle@target dbs]$ rman auxiliary sys@dup target sys@source [...] RMAN> duplicate target database to DUP from active database db_file_name_convert '/u2/data/PROD','/u2/data/DUP' LOG_FILE_NAME_CONVERT '/u2/data/PROD/onlinelog','/u2/data/DUP' nofilenamecheck; Starting Duplicate Db at 25-FEB-15 using target database control file instead of recovery catalog allocated channel: ORA_AUX_DISK_1 channel ORA_AUX_DISK_1: SID=171 device type=DISK RMAN-00571: =================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ======= RMAN-00571: =================================================== RMAN-03002: failure of Duplicate Db command at 02/25/2015 16:04:44 RMAN-05501: aborting duplication of target database RMAN-05531: a mounted database cannot be duplicated while datafiles are fuzzy Using Oracle 11.2.0.3 (anything below 11.2.0.3.6), this is the error if an attempt is made to duplicate from an activ...

During an upgrade of an 11.2.0.3 DB to 11.2.0.4 using DBUA, this error popped up: Errors - Oracle Workspace Manager . ORA-00942: table or view does not exist . ORA-06512: at "WMSYS.OWM_MIG_PKG", line 1575 . ORA-06512: at "WMSYS.OWM_MIG_PKG", line 1592 . ORA-06512: at line 1 . VALID 11.2.0.1.0 00:00:39 This error is referenced in MOS note  1051991.1 and can be ignored: If DBA_REGISTRY shows the status of (in this case) Workspace Manager is VALID, then this error is safe to ignore. Click Ignore and the upgrade will continue.

I find OEM incredibly hard to work with.  Not while it's running as it's actually a nice product from a user perspective, but keeping it working always seems like a huge hassle. This is partly because my knowledge of Weblogic is minimal, and partly because the documentation doesn't really explain where one thing starts and the other ends.  When I'm configuring something, am I configuring Weblogic, or am I configuring OEM?  It's not always clear. So, we come to today's issue. The target:  /EMGC_GCDomain/GCDomain/EMGC_ADMINSERVER/wsm-pm  was showing as down after a restart of the OMS.  I tried starting it from within OEM, which complained because it's not possible to control Weblogic through OEM, which makes sense. I logged in to the Weblogic console, and navigated to GCDomain->Deployments, located wsm-pm in the list, went to the Targets tab and EMGC_AdminServer wasn't in the list of targets!  Sounds like a s imple fix, then.  Click Lo...

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 switch...

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. ...

An interesting discussion on the Oracle-L mailing list recently highlighted the differences between using a query such as this; SELECT COUNT(1) FROM DUAL WHERE EXISTS (SELECT 1 FROM ALL_SYNONYMS WHERE SYNONYM_NAME = :B1 AND OWNER = 'USER'); And this: SELECT COUNT(1) FROM DUAL WHERE EXISTS (SELECT 1 FROM USER_SYNONYMS WHERE SYNONYM_NAME = :B1);  I assumed, naively perhaps, that there wouldn't be that much difference, but how wrong could I be...? Turns out, very much so!  This is the output of autotracing those two queries with a buffer cache flush in between just to be sure there wasn't any untoward advantage in running one first.  Left column is ALL_ and the right column is USER_.  I've highlighted what appear (to me!) to be the biggest differences. buffer is pinned count 1 3 buffer is not pinned count 250 66 bytes received via SQL*Net from client 464 441 bytes sent via SQL*Net to client 24957 24960 calls...