Ever look at a screen’s output and get that puckered feeling in the pit of your stomach? If you have been working in this profession for any amount of time, you know the feeling I’m talking about. The feeling that makes you think you would rather be living in Montana making woodcarvings at a roadside stand than being a DBA. I’ll be taking a somewhat lighthearted look at the perils of our profession and discuss ways to reduce problem occurrences.
The Foot Rule of Thumb
The Foot Rule of Thumb is pretty simple. You need to experiment and create your own rules of thumb. A while back I wrote a series of interview questions for an online magazine. The questions were the basis for a podcast interview with Jonathan Lewis. What impressed me the most about the interview with Jonathan was the amount of time he spent researching how the database worked. He stated that he became an expert by spending time investigating the database’s intricacies and documenting the results.
Setting up a Successful Test System in Oracle
Let’s continue our discussion on the Art of Being a Successful DBA. The intent of this blog is to help administrators design and standardize on a formalized design review process. The goal of the design review process is to identify and address application design, process flow, program logic and SQL statement problems early in the development lifecycle. Identifying these issues early in the development life cycle allows them to be more easily addressed than if they were to be identified during later stages. That last statement bears repeating. Like any other issue you face, no matter what it is (personal, professional, whatever), the sooner you identify it, the easier it is to correct.
Our blog has received a 7.8 out of 10 “Very Good” rating from the editors at Blogged. The Editor reviews are provided by professional editors who evaluate a blog based on: Frequency of Updates, Relevance of Content, Site Design and Writing Style.
I absolutely and firmly believe that Data Administrators are the unsung heroes of the Information Technology profession. This blog will be shorter than most of the upcoming blogs you will see from me. As a writer, I’m not noted for “keeping it brief”. I used to be an Oracle instructor and I like to pack as many facts as I can into these things. After reading a few of my upcoming blogs, you’ll probably agree.
Ever fumble around at 2 AM looking for that SQL statement you wrote a while back? You know, that one special script that will give you just the information you need to solve the problem and go back to bed? I must admit, I have done my fair share of moonlight script hunting. This blog will provide you with a few recommendations on naming convention best practices.
Let’s start our series on Art of Being a Successful DBA by covering the art of good documentation. Although the importance of a well thought out and detailed documentation library is blatanly obvious, creating documentation is the task most often postponed by an overworked DBA unit.
One of the benefits of my 20-year career (I think) is that most of the jobs I have held can be described as somewhat “unforgiving”, shall we say… What these jobs taught me is that I needed more than just technical expertise to become successful in my chosen profession. I quickly learned that becoming proficient at the various disciplines I will be discussing in upcoming blogs was just as challenging to me as honing my technical skill sets.
You got the job because you’re a quick learner, have the ability to understand complex systems, and most importantly, you can troubleshoot. However you became an Oracle Apps DBA, you’re one now, so the fun starts. I started this blog to assist young Oracle Apps DBA professionals who might need a little more detail in their solutions and good discussion into basic, fundamental Oracle architecture and other Oracle App subjects.