What a Difference a Space Makes

I had a very interesting experience in my “RACing up the Miles” session this morning. There were about 70 people in the room, and I hope they enjoyed the session as much as I did. I discussed a wee bit of architecture about RAC and concentrated on a very basic beginner’s primer to management activities with srvctl and crsctl. The session was intended to give attendees a start-up understanding of RAC with little more. I mentioned a bit about separate SGAs, block ownership, and cache fusion. That’s it… I then moved on to a brief introduction to managing the RAC database and associated suite of services.

I mentioned the technical mess one can get one’s self into when managing (or in this case mis-managing) a RAC clustered database. I pressed upon the attendees how much damage one can do to a RAC environment by doing something wrong. I delved into Pythian-specific but general industry-wide approaches to working with any technical facet of a server’s environment, likening it to crossing your T’s and dotting your I’s. I advised the following and, once the words came out of my mouth, I noticed a swell of heads nodding and acknowledgement smiles on many attendees’ faces:

• When preparing work to be carried out on a server/database, do not be afraid to spend 3 hours preparing for some work that will end up taking less than 5 minutes to execute.
• Go out of your way to check, re-check, and check again to ensure unforeseen circumstances will have less of a likelihood for derailing well-planned technical efforts.
• Once commands are executed, plan for a follow-up check to ensure what you just did had the expected effect on the environment when the work is being performed.

To speak of the 3rd bullet point in particular, picture the following steps in a detailed work plan:

1. log into nislo server as oracle
2. . oraenv [answering PROD to the request for ORACLE_SID]
3. cd scripts
4. sqlplus / as sysdba
5. @20120423_updates

The rub of this diatrab is point 2. One would assume that after that as executed, the ORACLE_SID of the session would be set to PROD. Imagine the horror of discovering it is set incorrectly. A better approach would be to issue the command echo $ORACLE_SID AFTER calling oraenv.

Suppose the output of that command was DTRAG, an entirely unexpected situation.Keeping these suggestions in mind, the 5-point list of commands from above would change to the following:

1. log into nislo server as oracle
2. . oraenv [answering PROD to the request for ORACLE_SID
3. echo $ORACLE_SID [intervene if anything other than PROD is displayed]
4. cd scripts
5. sqlplus / as sysdba
6. select name from v$database; [expecting output to indicate PROD]
7. confirm connection is as expected
8. @20120423_updates

The flavor of all of the above was echoed throughout my presentation, reminding and re-iterating that the attendees, as they cut their teeth with this RAC offering, are careful, methodical, organized, and cautious as they start the journey into clustered-database land. I stressed throughout the presentation the importance of being overly cautious as one manipulates the components of Oracle’s RAC offering.

What had happened in the above-mentioned work plan is that the DBA, instead of entering the command “. oraenv”, neglected to incude the dot and leading space before the command. The ORACLE_SID was set (as requested) to PROD then, once the command finished, it was set back to DTRAG where it had been all along… What a difference a space makes.