One of my customers is a software company and they use Oracle database for their product. One of the things we need to do when they certify an Oracle version is to create silent installation scripts. These scripts are for Windows and used for demo and testing environments. I did that for 11.2 and for 12.1 and now it’s 12.2’s turn.
This post is following a question I found on LinkedIn. A DBA pasted a strange test case in 126.96.36.199 and I managed to reproduce it in 188.8.131.52 (non-multitenant) and 12.2 (multitenant). But that’s not where the story ends, I wanted to understand what’s going on, so I did some research about it and the result is this post.
A few months ago we hit an Oracle bug related to streams replication crash after creating an index (bug 21320182). There is a patch so we installed the patch in test and it seemed to solve the problem, but we never patched the production.
Today we hit this issue in production after creating an index we needed. It’s important to say that we wanted to patch the prod a while ago, but we didn’t get approval for maintenance window.
This week I worked on a messy patch. I have a RAC environment with 184.108.40.206 and an old PSU and all kind of one-off patches and I wanted to install the latest PSU (180417). It sounds simple, but it’s not so simple. The thing is that I have 4 database running from the same ORACLE_HOME, all of them are RAC, while some of them are stand-alone, some are primary for standby located on a different RAC and some are standby for a primary located on a different RAC. And the problem with that is that you cannot install a PSU on the primary first, either together or patch the standby first.
In our first BCOUG Tech Day conference, I presented my session “Look Inside the Locking Mechanism”. I presented this topics before a few times and prepared a few demos to show different locking scenarios.
During the BCOUG Tech Day I did the same, while the only difference was that for the demo I used Oracle 12.2 PDB (I think in previous times I always used 11.2). During one of the demos I noticed something strange.
Over the years I ran into all kind of weird and wonderful backup and restore scenarios. This case has challenged me for a while now and I finally had the chance to check it properly and figure out what’s going on. So here is the story.
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).