15
Jun2012
Lessons Learned at the Tip of the Spear
Oracle P6 v8.2 EPPM Deployment Hurdles
Part 1 – TNSNAMES.ORA
Before software can be used for its intended purpose, some poor soul has to install and configure it…
You’ve just entered the Geek Zone.
Any typical scheduler might ask “What the heck kind of a word is tnsnames and what does it have to do with project management scheduling?” Somebody obviously needs to ‘buy’ a vowel or two.
Second part first – If you have ever installed Primavera, you have probably experienced the woes of seeing the “Connection Unsuccessful” screen when configuring a database alias. The ability for you to do your job relies on a database that must be up, running and fully functional at all times. If you use Primavera 8.2 for your scheduling, there is a high likelihood that your software attaches to an Oracle database. A typical/average P6 user creates and updates data that is locked in a server somewhere out in cyberspace, about which you know very little. Safe to say, whether you know it or not, ALL P6 users want to know about crucial items that affect their database.
Now the first part of the question; TNS is an acronym invented by Oracle. The prefix TNS refers to something called a ‘Transparent Nework Substrate’ (TNS). The suffix, ‘names’ is important for 2 reasons: One – it describes the subject and two – very important – it implies plurality. Oracle designed this file to contain connection string information to enable connection to many databases.
What is TNSNAMES?
TNSNAMES.ora is a special code file which is a part of a root communication method that Oracle uses to identify database files from any other directory full of files on a network. The file works like a ‘Table of Contents’ for data driven applications. It contains the network names (and/or IP Addresses) of any data source computer which might house data files which can be accessed by your Oracle based software. You can open the tnsnames.ora file with a text editor (like notepad). Upon doing so, you can see sentences written in what appears to be fairly simple code structure.
How do I get a TNSNAMES.ora File?
TNSNAMES.ora is born when the newly installed Oracle database product gets installed for the very first time. The bouncing baby file goes to a “house” called ORACLE_HOME, with a couple of simultaneously born sibling files – (it takes a village…). These files are shepherded by the good DBA (Database Administrator), who makes sure that they are kept as pure as the wind-driven snow at all times. As long as the files keep the good karma they were born with, life for database centric computer applications is very, very good.
What could happen?
Here is where the fun begins. (‘Fun’ that is, for those of us who like to have lemon juice squeezed into our paper cuts). Most of the ‘homes’ of these vulnerable, tender little offshoots are weakly guarded and have no alarm systems. With as little as one stroke of any common keyboard, a perfect little file can instantly join the legion of ne’r-do-wells in the intergalactic bit-bucket of cyberspace. Once befouled, the wayward TNSNAMES file becomes suddenly empowered to bring every database application end user storming (Yea, verily! Even ALL AT ONCE!) into the office of the nearest computer geek for help. The miserable cacophony will sound something like: “I don’t know what happened! Everything worked yesterday… I didn’t do anything!”
Lesson from the Tip of the Spear
As an Oracle software user, you may at some point be told by a well meaning helpdesk representative, directed by an error message, or otherwise tempted just to go look and experiment with TNSNAMES.ora. Sadly, as in the story of Faust, the story really can have a tragic ending. Like signing his contract with the devil, making “enhancements” to the TNSNAMES.ora, is both entirely too easy and terribly risky.
The moral of the story: If you are not absolutely sure of your actions, resist the temptation to edit these critical database files. Instead, seek the help of a qualified IT resource to administer your Oracle data system needs. Additionally, though this may seem obvious, make sure that your IT team is knowledgeable, qualified to work with Oracle products and immune to temptation, as well.
You’ll be thankful that you wisely considered the possibility of losing all of your schedule data and that of the rest of your team.
August 6, 2013 at 4:22 pm
[…] (…read Part 1 >HERE< […]