Post GI / RDBMS Installation Configuration Steps

Introduction

This is the third article in a series of blog posts on building a test environment to closely match a Production environment so we could then upgrade the test environment from Oracle Database 12.1 to Oracle Database 12.2. In the first post, I covered performing a silent installation of the grid infrastructure software. In the second post, I followed that by performing a similar silent installation of the RDBMS software. In this post, I’ll be covering the rest of the configuration work for this environment.

Listener Configuration

The first stage in configuring this environment was to get the listener configured and running. I copied the listener.ora from the GI home on Production to the test environment and updated host names appropriately, and also copied the sqlnet.ora and tnsnames.ora from the database home on Production to the test environment and updated those files appropriately as well. I started the listener to ensure it was working as expected:

Parameter Files for ASM and the Database

The next step is to copy the relevant parameter files from the Production environment – one for ASM and one for the Production database. The database had an SPFILE on disk, but ASM did not, so to be sure I copied the environment as it currently stood, I created the ASM parameter file from memory and copied it to the test environment:

Of course, creating a PFILE this way means that all the underscore parameters etc. are included, so I needed to remove all of those and the setting for ASM_DISKGROUP for now, as I haven’t yet created any diskgroups on the test environment. I also had to create the relevant directories under diag.

For the Production database, I created a pfile from the SPFILE so I could edit it as needed, and copied that to test as well:

Of course, there are no diskgroups so the ORA-15110 error is expected. In this environment, the customer had set up four disks using multipathing, so I could use the devices mpath[b-e] to create ASM disks:

Left that running for 15 hours (it’s a decent sized database!) and came back to realize I’d made two mistakes. One of them is obvious, and the other less so:

The obvious one is of course I left that damn word “standby” in there, so I’d built another standby! D’uh!

The less obvious one is that the archives weren’t in that location, so none of the archived files were copied across.

So the first thing I had to do was copy all the relevant archive log files to the test environment. I then set the LOG_ARCHIVE_DEST parameter as needed, issued the RECOVER DATABASE USING BACKUP CONTROLFILE command and activated the standby as a primary. The system was now ready and waiting for the customer to start testing with.