As every year since 2016, we’re having the ODC Appreciation Day around October. If you don’t know what “ODC Appreciation Day” is, it is Tim Hall’s initiative to simply say thank you. It started as “OTN (Oracle Technology Network) appreciation day” and then changed to “ODC (Oracle Developer Community) Appreciation Day” when Oracle rebranded OTN. It is meant to acknowledge that we, as a community, appreciate what the people at Oracle community are doing for us by writing these posts and add the hashtag #ThanksODC.
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.
I had a bad night last Thursday.
After patching two test RAC databases and one production RAC with 180417 DB Bundle Patch (and some one-offs), I got to the point where it was time to update the most critical RAC system.
We were really looking forward to this as we had hit a few bugs that this DBBP and one-offs should fix. But boy, did that go wrong…
Lately I started patching a client’s database (184.108.40.206) to the latest PSU (180417). This is a RAC environment with streams and all kind of other features, so over the time we hit quite a lot of different bugs. When we planned this PSU (we installed the bundle patch version), we added about 7 one-off patches (some are recommended by Oracle and some we had to add because the bugs affected us quite badly).
This week I worked on a messy patch. I have a RAC environment with 220.127.116.11 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.
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.
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”.