What a Difference a Space Makes

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 startup 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 managing (or in this case mis-managing) a RAC clustered database. I impressed 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 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 to the 3rd bullet point in particular … picture the following steps in a detailed workplan:

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 if this diatrab is point 2. One would assume 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 AFTER calling oraenv, to issue the following command:

echo $ORACLE_SID

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 flavour 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 workplan, 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.