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:

Configuring ASM

In theory, you might think that we should now be able to start ASM with the modified PFILE. Unfortunately, doing so causes an error:

The problem is that the CRS resources have not yet been started:

Now let’s try starting ASM again:

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:

So now we can create the diskgroup:

Duplicating the Database

So now we’re all ready to duplicate the database from its last backup. I already had a script for building the standby for this customer, so I just changed the backup directory and used that:

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.

Pete

After 22 years of working at Oracle in just about every role except Marketing and Support, I am now working as a Senior Managed Services Consultant with Red Stack Tech, specializing in Oracle Database technology, High Availability and Disaster Recovery solutions. I am also a member of the OakTable Network, and have presented at RMOUG Training Days, Hotsos Symposia, Oracle OpenWorld conferences, and other user group events. I have co-authored the Expert Oracle Enterprise Manager 12c and Practical Oracle Database Appliance books published by Apress, and am one of the authors of the Building Database Clouds in Oracle Database 12c book published by Addison Wesley.

Leave a Reply

Your email address will not be published. Required fields are marked *