When you create a job using DBMS_SCHEDULER.CREATE_JOB you can specify a schema for the job (job_name => ‘my_schema.my_job’). What does it mean?
In an Oracle Data Guard configuration, the primary and standby databases can have different configurations. It’s very common to have a smaller server for the standby database (less CPUs, less memory, etc.) and it’s quite trivial to configure. But what about RAC?
This is not my tip, but Connor Mcdonald‘s. I attended a couple of his sessions at Open World 18 and had to write about this small but really useful feature that he mentioned (thanks Connor).
If you read my post Restoring Standby Database, you know that one of the problems I had was that the new control file refused to open the database with resetlogs even though the database was consistent.
One of my clients is restoring their database backup to another server for some testing. They do it periodically so we can also verify that the backup is good (which is great!). In a few cases, after the restore I saw that the restored database has an incarnation that the original database doesn’t have (and not the one created by the “open resetlogs” after the recovery). This actually caused a problem during the restore, but this restore has a few issues (I started a post about that as well).
Even after years of working with something, you can always learn new stuff. Today I tried to create a standby database using the duplicate command. When you duplicate a database you need to connect to both instances (primary as target and standby as auxiliary) using SQL*Net (and not “/”). Since the standby is in nomount, the listener blocks connections to it, so when trying to connect to it using the listener we get “ORA-12528: TNS:listener: all appropriate instances are blocking new connections”.
Every day you can learn something new, even after 20 years in the field. For some reason, I was always under the impression that within a single schema, objects must have a unique name. Apparently, this is not the case.