1. The first step to recovery is having the ability to bring the instance down.  We can do this a few different ways: either through Enterprise Manager (SQL Server Management Studio), services, or through Configuration Manager.  Once the instance is brought down we need to bring it up in single user mode using the ‘m’ flag.  I usually do this through the command prompt using ‘net start’ or you could put the trace flag in the startup parameter files; however you feel most comfortable.  Example: Bringing the default instance down and starting it back up in single user mode.



2. Use SQLCMD (2005-2008) or iSQL (2000) to connect to the instance.  Make sure that Object Explorer and applications are not connected to the instance.  You can also do this through SSMS or Query Analyzer. Example: Connect to the instance once in single user mode.



3. Add yourself as a user and grant yourself administrator privileges. Example: Adding a test user and giving it system administrator privileges.



4. Congratulations!  You have successfully given yourself administrator privileges, so now stop SQL Server and start it back up without the single user flag.

Tim Foley, Sr. SQL Server DBA

Recovering System Administrator Privileges is a post from: Remote DBA Experts

The Perils of our Profession
One of the common challenges that all DBAs face, no matter what vendor’s database they work on, is the absolute attention to detail our profession demands. Switch a couple of characters in a script, forget to set your SID, set the wrong flag at the wrong time and the end result usually isn’t very pretty. Many commands we issue on a regular basis are destructive by their very nature. This is the reason why I have a great respect for all technicians who have selected database administration as their chosen profession.

I know they have all experienced that uncontrolled “eye-twitching” at 2 AM when they are ready to hit the final enter key to execute the command. You know what command I’m talking about too. It’s that one command that you really, really, really hope is going to come back with a successful return code and ultimately end with a database that is finally usable. Whether it’s a recovery, a file fix or corrupt data is immaterial, it’s the wait that we are talking about.

There is no longer wait in our profession than waiting for the message below after a database recovery:

SQL> Database opened.

Time always seems to stand still. The longer the recovery, the messier the recovery.  The more critical the database – the longer you wait. You stare at the screen hoping beyond hope that the above message will appear. It’s the ritual cross your fingers, spin around three times, face towards Oracle headquarters and pray to everything that is Larry Ellison wait. I’ve actually caught myself mumbling, “Come on, come on, come on…” I don’t care how sure you are of your capabilities, or how much of an Oracle “Ace” you are – you know the anticipation I’m talking about.

You then either breathe a sigh of relief or you are in absolute disgust when you see an Oracle error message appear. How about the old “File 1 needs more recovery to be consistent” or the “File 2 not restored from a sufficiently old backup”? Those messages are enough to make anyone cringe. I’m an ex-Oracle instructor. I’ve seen those messages A LOT in class. I still cringe.

At a previous job, I once had to run through 36 hours of tapes to restore a multi-terabyte warehouse. A disaster occurred that required us to do a recovery. THAT was the longest wait for a database open message I ever experienced. One of my fellow DBAs asked if I needed a brown paper bag to breathe into.

Or it’s the command that drops the schema in the test environment that will allow you to do a refresh from production. It’s that test database that runs on the same box as production. The environment that makes you do a “SELECT name FROM V$DATABASE” command in SQL*PLUS about 15 times in a row before you finally execute the “DROP USER CASCADE” statement.

Not only must we try to prevent our own mistakes, we must safeguard our environments against the mistakes of others. Operating system administrators, disk storage technicians and application developers are just like us. We are all part of the human community that makes mistakes from time to time.

If you never make mistakes, send me a resume. I’m always looking for a “Patron Saint of Oracle” here at Remote DBA Experts. It will also save us on travel costs because I’m sure you’ll be able to spread your wings and fly here on your own.

But as my old boss Dan Pizzica used to tell me (when I was a VERY junior DBA) “It really doesn’t make a difference who broke the database. You are the technician who is ultimately responsible for fixing it. The buck stops with you. If you can’t protect your environments, you aren’t doing your job.” We all know he’s absolutely correct.

Then there’s the software glitches. The problems that pop up out of the blue and make you go:

“WHAT THE? – How did THAT happen? I’ve done this 317 times in a row and it worked every time.”

For you math majors, here’s my calculation for this:

CLOSER YOU ARE TO PRODUCTION TURNOVER
+ THE GREATER THE VISIBILITY OF THE PROJECT
= THE MORE LIKELY A PREVIOUSLY UNKNOWN SOFTWARE GLITCH WILL OCCUR

I don’t care what software you are using, you will run into the “only occurs on this release, on this version of the operating system, using this particular feature on the third Tuesday of the sixth month when it’s cloudy outside” BUG. Be sure to expect management to stop by and ask “well, why didn’t you test this on the third Tuesday of the sixth month when it was cloudy outside?”

The more complex the database ecosystem, the more paranoid I become. Which is why I’m not a follower of “the database is getting so easy – we won’t need DBAs” mantra that mindless industry pundits profess on a seemingly endless basis.

So now we know that our jobs are somewhat unforgiving and we do make a mistake from time to time. What can we do to reduce the chance of an error occurring?

Poka-Yoke for DBAs!
We recently had a Poka-Yoke contest here at Remote DBA Experts.   We hold contests on a regular basis to jumpstart the creative process on activities that we feel strongly about.   We are big proponents of Poka-Yoke”.  Poka-Yoke is a Japanese term that means “fail-safing” or “mistake- proofing”.   Wikipedia’s definition of Poka-Yoke is: “its purpose is to eliminate product defects by preventing, correcting or drawing attention to human errors as they occur.”

Since I’m a car nut, here’s a couple of automotive Poka-Yoke examples.    You can’t take the keys out of most modern cars until the car is in park.  In addition, most cars won’t allow you to shift out of park until the key is in the “ON” position.   How about gas caps that have the little tether that prevents us from driving off without the cap?   Most gas caps are also attached using a ratchet assembly that ensures proper tightness and prevents over tightening.

Take a look around you, you’ll see dozens of Poka-Yokes during your daily activities:

• The little holes in bathroom sinks that prevent overflows
• Microwaves will stop when the door is opened
• Same thing with dryer doors
• Lawn movers that have a safety bar that must be depressed before they will run
• Disk brakes that begin to make a noise before they are completely ground down
• Rumble strips on roads

The list really is endless.  We have applied the Poka-Yoke process to our daily activities here at Remote DBA Experts.  We have checklists, process documentation, best practices, sign-off sheets – the works. One of the first blogs of this series is a discussion on the importance of good documentation.

I’d be very interested to learn your Poka-Yoke ideas!   If you have a Poka-Yoke idea, please respond and we’ll be glad to discuss it.  Here’s some general ones that I recommend.

The Second Set of Eyes
As I have stated in previous blogs, I have over 20 years of experience using Oracle and have done my fair share of database backups and recoveries. During my career as an Oracle instructor, I have assisted in hundreds of database recoveries in Oracle’s classroom environments. If possible, I still have others review my recovery strategy and recovery steps before I begin the recovery process. I used backup and recovery just as an example. Whatever the process is you are are performing, a second opinion may prevent you from making a mistake. A review from a fellow DBA has saved me more than once. I may be described as having an ego (I have no idea where they get that opinion) but it doesn’t prevent me from asking for help from others.

We were recently correcting a very poor backup script created by a customer’s previous database support vendor. The customer described this particular environment as “if it goes down we lose our ability to make money” application. After our massive set of changes were complete, two of us went line-by-line verifying each line of the backup script. At the end of each script we asked each other “are you OK with this”? Only then did we move on to the next one. I don’t care how much time you have “in the seat” using Oracle, you need to put your ego aside at times and have someone check your work on critical activities.

Concentration
I used to work for a shop that subscribed to “the everybody in one big room” philosophy. I guess it was supposed to allow everyone to work together as a team and become as “one with each other”. It may have achieved that purpose but it sure didn’t allow you to concentrate on your work very well. You could hear so many different conversations they had to pump in white noise. The constant ‘whhhsssssshhhssshhh” noise made me feel like I was a crewmember of the Starship Enterprise. I always wondered when Captain Picard would walk through.

Like all DBA units, our particular area was often populated with various developers and O/S technicians. Many different conversations were occurring, some that could be described as somewhat animated. The environment did not allow you to concentrate on the task at hand. We often had to go into small conference rooms to work on critical tasks.

The point I’m trying to make is that no matter what type of environment you work in; if you can concentrate OK, but if you are like me and you can’t, find a spot where you can. Block off some time, send questions to other DBAs and concentrate on the task at hand. Don’t attempt to answer questions and code a complex script at the same time. May seem obvious, but throughout my career I have personally watched numerous DBAs attempt to multitask when they are working on a critical process. It’s a recipe for a problem. Once you are done, follow rule number one and have someone review your work.

What Database Are You Working IN?
Working in the wrong database is a common problem for database experts as well as their less experienced counterparts. How many times have YOU found yourself running statements in the wrong environment? Feel free to include me in that not so select group. The operating system command SET can be used in Windows systems to display environment variables. The ENV command can be used to display the environment variables in UNIX. Many seasoned database administrators change their UNIX shell prompt in their profile to display the current Oracle SID. Displaying the current Oracle SID in the shell’s prompt provides a continuous reminder to the DBA of the database they are working in.  Google it – you’ll find dozens of scripts by your fellow DBAs.

Setting your SID Automatically During Logon
Here’s an easy recommendation – don’t do it. Many of the servers we work on contain several databases that use different database software releases. It is our standard to not set environments in logon scripts. We create shell scripts that have the database name in their title to set our SID, ORACLE_HOME, etc..

It is a little harder in Windows environments. During installation, Oracle often uses the first database created on the server as the default SID. You can override this configuration, but you’ll need to read the Oracle installation guides to find out how. The manuals will show you how to override the default database on Windows operating systems.

Saving Time VS Creating a Problem
I once watched a fellow DBA perform a rather complex set of administrative tasks to solve a problem. He was rapidly flipping back and forth between at least 15 active screens, copying and pasting and editing and copying and pasting and editing… I describe this particular activity as “Multiple Screen Syndrome”.  He also had several other screens open that were connected to other databases. He was multi-tasking to its highest degree.   Take a break, take a breath and look at what you are doing.

How about the rm -r /u0*/ora*/prod*/*/*.* command in UNIX? It’s the command that drops multiple databases in multiple directories. All in one painful swoop. How many times have you heard of a mistake caused by commands like this causing mass mayhem? When you make a mistake like this, you become immortalized in conversations for years to come. Get a few technicians together after work and ultimately the conversation will include “remember when Bob so-and-so ran that big rm -r command by mistake and wiped out the entire O/S on our production web server? You can’t tell me you haven’t heard stories like this.

My opinion as a database manager is that I would rather you take your time than showcase your multi-tasking and time saving skills. The more complex and critical the activity, the more basic you should become in your plan of attack.  Trust me when I say I won’t be impressed with your time savings “cut and paste” and wildcard expertise if I think it can even remotely be dangerous.

Safety First Mindset
I once saw a DBA log in to a database using a particular schema account. He then logged into a different database using a DBA account and dropped the schema with the same name he was logged into on the first database. I asked him why he logged into the first database using the schema account he just dropped in the second. He stated “Oracle won’t let you drop a schema that is connected. No matter what happens after this, I’m positive that I won’t drop the user in this database by mistake.” I like that Safety First mindset in a DBA.

You need to think Safety First when you are performing any particular complex or critical activity. Take the time and put one or two safeguards in place like the DBA did when he dropped the user.

Other DBAs may call you paranoid, I’ll call you an experienced DBA that would rather be safe than sorry.

Wrapup
The intent of this blog was to not provide you with a laundry list of recommendations. It was intended to help jumpstart your creative juices to think about different methods to protect yourself against problems. If you have any helpful hints, please feel free to respond to this blog with your Safety First Tips and Tricks.

Thanks for Reading,

Chris Foot
Oracle Ace
Director Of Service Delivery

The Art of Being a Successful DBA – Poka-Yoke and Paranoid DBA Best Practices is a post from: Remote DBA Experts

The reason that this blog is short is that I don’t consider myself qualified to instruct others in the Data Administration function. I will state that after twenty years of working as DBA, I can perform the basic functions fairly well when I need to. The intent of this blog is to provide readers with a launching point to start their education and stress the importance of effective data resource management.

I use the title “Data Administrator” loosely to describe the functions these IT specialists provide. I use it for clarity only in this blog because I think it oversimplifies the important role they play. Data Administrators are more aptly titled “Protectors of the organization’s key data assets.” From establishing proper naming conventions to ensuring a common language is used to implementing corporate-wide data management policies, the services they provide range the spectrum. I could easily spend the rest of this year’s blog expanding upon the services they perform and still do them an injustice.

Data administrators view data from the business perspective and must have an understanding of the business to be truly effective. Their expertise allows them to define, describe, organize and categorize data. DAs build models of the data that are a based upon data entity relationships and the business rules that govern them. Data administrators provide the framework that allows disparate business units within an organization to share timely and accurate data. The end result is: higher quality data = better business decisions. Enough said.

Because folks in this profession must understand the business itself to perform their duties, I have never met a DA that didn’t know more about the overall business than any one else in the organization. That includes the business personnel that were responsible for providing that service. You know what surprised me the most after watching a DA interview business unit personnel about data meaning and business rules and processes? How much more that businessperson learned about the service they were providing to their internal and/or external customers.

As a result, if I were a CIO and I wanted to learn more about a particular business function my organization provides, I would include the Data Administrator in the list of people I needed to talk to. No doubt about it.

I have had the good fortune of working with many excellent Data Administrators during my career. I made every effort to learn as much as I could from them. Rebecca Duffy and Jim McQuade come to mind when I think about top-notch Data Administrators that have made an impact on me. I have also had the good fortune of working with Craig Mullins who I feel is one of the few database experts that firmly understands the Data Administration function.

The greatest positive impact I think these folks had upon me was that they were the conduits that allowed me to understand and appreciate the benefits that high quality data driven design provides. They taught me the importance of their chosen profession.

Like all DBAs, I know that the key to creating a high quality database environment is to build it upon a firm foundation. A foundation that consists of a well-designed hardware platform and an operating system and database that were tailored and configured for high performance, high availability and protection against unauthorized access.

I came to understand that high quality data driven design, led by a competent Knowledge Management Worker (Data Administrator to simplify) was the foundation for an application that was easily administered, easily changed, less error prone, needed less rework to add new functionality, and the list goes on and on and on….

Because Data Administration maps the business rules into constraints that can be enforced by the database and turns raw data into information stored in tables, the Data Administrator acts as the intermediary between the business and Database Administration units.

You can plop me down into any database and within 15 minutes I will be able to tell you if the application objects and business rules were designed by someone who understood Data Administration best practices. Since I work for a Remote DBA Services provider, I am provided with that opportunity on a daily basis. When I assess a new customer’s database here at Remote DBA Experts, one of the items on my assessment document is adherence to Data Administration best practices. When I see poor naming conventions, the same piece of data named 10 different ways and stored using every different data type Oracle provides, I immediately begin to become highly concerned about the quality of the rest of the database ecosystem (hardware platform, O/S, database, application). I also know that we are in for a lot of complex data changes in the future.

All this being said, the data administration role, although important, is often undefined in many IT organizations. The smaller the shop, the more prevalent this becomes. Those responsibilities, by default, are usually awarded to the shop’s database administration unit.

If you are employed at an organization that does not have a full-time Data Administration unit, the first question you need to ask is why not? Here’s my two cents. Any organization that is large enough to employ a staff of DBAs, operating system administrators, network engineers and application developers is being shortsighted if it doesn’t have a full service Data Administration Unit.

We previously learned that the services a DA provides ranges the spectrum. As a DBA/DA, the scope of services you can provide will be severely limited by time constraints and knowledge. Most of your time will be spent understanding the Data Modeling process as opposed to defining enterprise-wide information frameworks. You must have the basic understanding of how data is modeled and the logical to physical transformation process. Your responsibilities will require that you work closely with the business folks and application developers. This must be a team effort.

There are dozens of data modeling tools to help you perform the data modeling process. Personally, I am a neophyte Erwin user. Here’s a web page with a more comprehensive listing.  Expand the selection list and you’ll find a bunch of articles to choose from.

I fully understand that small shops can’t afford to employ a full time Data Administrator. So what happens if you are the “chosen one” to perform these services for your organization?

Here’s my quick-start listing:

Realize that the data administration function you are providing is just as important as any database administration service you can perform. You need to spend as much time, if not more, learning this trade. Even if it is only a part-time responsibility, it is a highly important part.

Don’t allow yourself to become overwhelmed. As with anything, start by learning the basics. I’ll provide some resources later in this blog to jumpstart you.

Understand that this topic is complex. I have run across few Data Administrators that didn’t have a passion for their job and weren’t highly intelligent. They will also speak a different language than you do. My first meeting with Jim McQuade started at the same intellectual level and ended by him slowly saying “DO…. YOU….. UNDERSTAND…?” after each sentence. I shook my head in several different directions and said “NOOOO.” But I kept trying and kept learning from him.

You need to learn the basics. Start by beginning to understand the Data Modeling process: normalization, naming conventions, entity relationships, business rules. The book I often refer to is Data Modeling Essentials: Third Edition by Graeme C.Simsion and Graham Witt. An introductory book (Data Admin 101) I think highly of is Data Modeling Made Simple: A Practical Guide for Business & Information Technology Professionals by Steve Hoberman.

Sign up for DAMA and attend their conferences. As I stated previously, start with the basic presentations.

Spend dedicated time on the The Data Administrator Newsletter website. This is the FIRST site I would go to. I can’t stress this recommendation highly enough. The folks that contribute to this site are top notch. While you are on that site, go to the Book Center page and read some of their reviews.

Many of my personal Data Administration books are outdated, so I hope that once word gets about about this blog, real DAs will chime in too.

The key to your success is to start with the basics and understand that there is much to learn before you can perform the DBA/basic DA functions.

Thanks for Reading,

Chris Foot
Oracle Ace
Director Of Service Delivery

The Art of Being a Successful DBA – Learning Data Administration is a post from: Remote DBA Experts

Following proper naming conventions is absolutely critical to us as a remote DBA services provider. We have dozens of DBAs on staff now that are responsible for supporting hundreds (and hundreds) of different database ecosystems. To ensure DBAs can seamlessly tranfer from one environment to another, we must establish standard naming conventions and document everything in our customer’s environments.

Each one of our DBAs can go to any platform and quickly navigate to the script and monitoring tool directories, find the script they are looking for and execute it. I feel that this is so important to the quality of support we provide that we have selected a group of technicians that are responsible for creating, adjusting and auditing naming conventions here at RDBAE. These folks, led by Doug Russel, our Proactive Monitoring Center Team Lead, are responsible for laying the groundwork to ensure that our naming conventions and best practices are being followed.

I’ll continue our discussion on naming conventions by providing you with a few sample recommendations. As always, these recommendations are not intended to be all-inclusive. They are a few examples to help start you in the right direction.

Follow OFA Naming Conventions
OFA stands for Optimal Flexible Architecture. The OFA standard is a set of naming conventions and configuration guidelines that:

• Distributes I/O among different disk drives.
• Facilitates ease of administration by creating naming conventions for mountpoints, directories, file suffixes, database binary directories and database output (i.e, background dump, core dump).
• Improves the DBA’s ability to manage and administer database growth.

These standard naming conventions and placement guidelines are intended to improve database performance by spreading I/O, protect against drive failures and also allow administrators to more easily assume the responsibility of supporting new database environments. In addition, because OFA standards are well documented by the Oracle Corporation, newly hired DBA and consultants are able to more quickly assume administration responsibilities.  To learn more about OFA, do a Google search on the key words “Optimal Flexible Architecture”.  You will find all of the documentation you need!

Create and Standardize Monitoring and Administration Scripts
All DBAs have their own set of favorite Oracle administration and monitoring scripts. They find them on the web, get them from third-party books and trade them like bubble-gum cards. They then tune, tweak and tailor them until they fit their own unique style of administration.  It is highly recommended that database administration units create a set of scripts for daily administration/monitoring, hot and cold backups (RMAN or OS), loads, exports/DataPump and common administrative activities. This library of scripts can then be installed on each server administered by the team. Personalizing the scripts should be highly discouraged. Any modifications to the library can be reviewed during team meetings.

Assign a team member the responsibility of being the script library owner. The script library owner will be responsible for keeping track of all script modifications and ensuring a rigorous review and test plan is executed on the new scripts before they are installed on the supported servers.   Monitoring scripts are even more crtical. They are the foundation of the DBA’s support activities. If your monitoring scripts aren’t working, you are failing in your role as “protector of the organization’s key data assets”.  Here at RDBAE, we have a virtual team that is assigned the responsibility of keeping track of literally dozens, and dozens, of Groundwork monitoring plugins. These technicians use an off-the-shelf code library with full check in/check out features and review capabilities (for approval before release).

All scripts and directories should have names that allow them to be easily recognized. It irks me to no end when I log in to a server, navigate to a script directory and find files named SQL1.SQL, SQL2.SQL, FIXIT.SQL, TUNEIT.SQL… Fix what? Tune what? What the?  Personally, I would prefer to have a SQL file name that is long, but descriptive, as opposed to a name that doesn’t provide me with any clue on its contents.

It is also important to follow a strict naming convention for your output files. Whether the output is from a SQL, DDL or operating system command, the output file should be placed in the appropriate directory and have a descriptive name. The file name should also contain the date the output was created.

For example:
create_mcfinemp1_table_012609.out would be the output from the DDL statement execution that created the MCFINEMP1 table on January 26, 2009.

Object Naming Conventions
This is the area where having a Data Administrator available is certainly beneficial. These are the folks that are trained in naming convention best practices. If you don’t have the good fortune of having a DA available, it will be up to you and your application developer counterparts to create a set of naming convention guidelines. It is important to create a naming convention that contains abbreviation guidelines that are used to shorten object names.

Here’s an example of an index naming convention I have used in the past:

INDEX
Definition: An index is an object that ensures efficient access to the data by using an ordered set of pointers to the table’s data rows.  Indexes can also be used as the physical mechansim to ensure key value uniqueness.
Naming Conventions:
Format #1   -   tb_idx_uu
tb – table name (abbreviated if required)
idx – constant identifying this object as an index
uu – ascending numeric or character index identifier (used to identify multiple indexes per base table)
Example: MCFINEMP_IDX_01 would be the first index on the MCFINEMP table.

There are dozens of guidelines available on the web. In addition, many of the books on Data Administration provide suggested naming conventions. We also have our own personal preferences. For example, many DBAs like to include column name abbreviations in their index names.

What the standard naming conventions are is not as important as creating them and adhering to them religiously. That is the key to success.  These recommendations are not intended to coerce readers into using the provided naming convention examples verbatim but to emphasize the importance of a creating a set of standardized naming conventions and then strictly adhering to them.

Thanks for reading,

Chris Foot
Oracle Ace
Director Of Service Delivery

The Art of Being a Successful DBA – Naming Conventions is a post from: Remote DBA Experts

I’ve been able to learn from my mistakes and make changes in my technical and non-technical approach to database administration to overcome my shortcomings. I’d like to cover some of my personal best practices that have made my life as a DBA more productive and my customers and co-workers happier.

I’d like to take a minute to describe some of the jobs I’ve held and how they have taught me to learn the value of becoming proficient at both the technical and non-technical disciplines required to become a successful DBA. I’ll continue this week’s discussion with what I think is probably the most beneficial set of recommendations I could provide to you as readers. Some of the information is certainly “intuitively obvious” as my old boss used to say but it never hurts to have a refresher. In upcoming blogs, I’ll remove the personal stuff and get down to the business of providing you with information on The Non-Technical Art of Being a Successful DBA. We will then turn our attention to the wonderful world of Oracle and SQL Server database administration Tips, Tricks and Techniques.

There are numerous jobs where you have to be on top of your game at all times. The medical profession and police work come to mind when I think about folks that have to be “mistake free” to keep us all safe and healthy. I often remind myself that the stress I let my job generate for me is nothing compared to what these aforementioned folks must experience.

As Oracle database administration goes, being an Oracle Instructor is about as unforgiving as it gets. You get dropped into a classroom that has twenty PCs running Oracle and twenty students depending upon you to teach them. My first attempts at teaching a dozen years or so ago could be described as “less than stellar.” I had a review from my first class state “this was the most boring person I have ever met.” I felt bad about that until my senior instructor showed me one of his first reviews. It had in big red letters at the top of the page “I HATED YOU.” I felt better after reading that.

I must admit I was a little timid when I started, but those students that attended later classes know that I decided to let my own bombastic personality show through. Let’s say that none of my subsequent classes were ever boring after that.

After that less than glorious start, I worked hard to become a better instructor, eventually winning one of Oracle’s top instructor awards with a 95% student approval rating. How I ever ended up in a teaching profession where the students graded the teacher, I’ll never know. Just as a joke I started one class by stating “Oracle has instituted a new procedure that will allow me to grade your participation and learning skills and send them to your employers.” The look on everyone’s faces was priceless. I still view being asked by Oracle to certify fellow instructors as one the greatest achievements of my career. I took that job very seriously.

I can tell you one thing about Oracle DBA students, they are a rough bunch. I started a DBA I class by blowing up a database create and couldn’t get it to work correctly after a second attempt. This after doing it successfully hundreds of times. A corrupt drive on my PC was the culprit. After turning around and seeing the “who is this idiot” look on my student’s faces, I suddenly felt like a wounded fish in the middle of a pack of hungry piranha.

Oracle instructors describe that problem with a single phrase “losing creditability with the class.” You did that and you were lunchmeat. But I never let that potential loss of creditability prevent me from saying “I don’t know, I’ll get back to you.” Or I would look up the information for the student on the spot. That provided two benefits: answering the question and showing students the importance of knowing where to look for the answers.

Assisting a class of twenty students through backup and recovery labs certainly helped my debugging skills. If you ever want to find out how bullet proof an Oracle database can be, watch 20 installations being abused by students in a backup and recovery class. I always started my backup and recovery class with this statement “The fastest way to lose your job in this profession is to lose data for your company. You can be a Tom Kyte and a Jonathan Lewis X 2, but if you can’t recover a database, you aren’t of any use to your employer.” That always seemed to ensure that they paid attention during the remainder of the class. That was one class where I absolutely pounded information and best practices into their collective heads. We were all worn out by Friday.

I enjoyed teaching and became friends with each and every group of students I taught. I always felt sad when we parted and always worried that I missed that one tidbit of information that could help them.

On-site consulting is also a tough profession. The customer brings you into an environment that you know nothing (or little) about and expects you to be productive and solve their problems – immediately. That is as it should be. They pay a premium and expect good service. It is the consultant’s fault if that doesn’t happen. I liked that job because it was very challenging and forced me to continuously refine my skill sets and talents to keep my customers happy.

But I have had my fair share of sweaty palms at many a client site. I didn’t have the luxury of being an Oracle consultant. They always seemed to have an endless stream of people to draw from for support. I usually ended up in a wiring closet with a manual in one hand and a keyboard in the other. I actually spent three weeks in a wiring closet at one client’s site.

Remote database administration also requires excellent technical and non-technical skills. You must continuously strive to keep your customers happy, all of which hold you to a very high standard.  You must expect that from all of your customers in this profession.   They have handed the keys to their most critical data assets to your firm.   Trust me when I say we at Remote Database Experts don’t take this responsibility lightly.

If you want to be at the top of your game, become a DBA for a remote database administration firm.  Describing competition in the remote DBA industry as fierce is like describing the Titanic as “having a small leak.   It is a very challenging job.

You become successful as a remote DBA services company by providing a superior level of support to your customers. As a technician, it’s a great job! You can be installing a RAC/LINUX environment in the morning and be debugging an Oracle Applications concurrent manager problem in the afternoon. From warehouses to HUGE web databases having thousands of concurrent users and from manufacturing to financials, you work on it all.

The Art of Being a Good DBA
I started off this blog describing some of my jobs not to impress you with my background but to hopefully help you understand how important it is to me to provide you with this first series of non-technical recommendations. These jobs quickly laid bare every hole in both my technical and non-technical approach to database administration. They not only laid them bare but also amplified their negative results. I found that becoming lax in the non-technical areas of database administration and not following my own best practices could create just as much havoc as a technical problem. As I have stated numerous times, some of us are brilliant and some of us are lucky. The rest of us have to be thorough.

To ensure that I did not allow a failure in non-technical areas to complicate my life as a DBA, I needed to learn how to document, communicate and follow my own best practices. I learned the tricks of the trade to reduce the amount of time it took me to administer my environments and ensure I didn’t get paged at night. I found that I could trust some author’s information and not others. I learned that by keeping my recovery skills sharp, I reduced my level of anxiety when I got one of those two in the morning “I think we just formatted one of your Oracle disks by mistake” calls (actually the caller stated they accidentally formatted the entire array consisting of dozens of disks by mistake). The list goes on and on…

To continue, here’s a laundry list of what will be covered in upcoming blogs:

• Why good documentation is so essential and documentation best practices
• Naming conventions
• The benefits of Data Administration
• The key to successful application implementation – Design Review Meetings
• Improving the speed and quality of database administration by keeping your environments organized and uncluttered
• Creating and maintaining tips, tricks and problem resolution libraries
• Script foraging
• Reducing stress and preventing failed recoveries by keeping recovery skills sharp
• The benefits of repeatable processes. If it worked that way once, it’ll probably work that way again
• Proceduralizing the change management and production turnover process
• Time Management and the art of project and process time estimation
• Maintaining good relationships with customers, end-users and fellow technical personnel
• The Foot Rule of Thumb
• Knowing where to look when you don’t know the answer (reprise from earlier blog)
• Using Service Level Agreements to ensure your internal and external customers know what to expect from you
• Monitoring by day so you don’t get called at night
• Monitoring space growth and performance statistics historically
• Paranoid administration best practices. Many of which are stolen from probably the most paranoid (and error free) DBA I have ever met. Jeff “I never met a problem prevention method I didn’t like” Kondas.
• Preventing errors from reoccurring by creating and following Corrective Action Procedures

Some of the topics will require an entire blog to cover while other blogs may group many topics together. The intent of this series of upcoming blogs is to help beginners create an approach to improving in non-technical areas and act as a refresher to those of us that have been in this profession for a while. Some of these recommendations come from problems that have occurred as a result of me not placing the same emphasis on non-technical areas as I did the technical ones. Many of the recommendations come from my experiences working as a mainframe DBA that, as we all know, is a very structured environment that demands rigorous adherence to best practices. The remainder comes from my experiences working as an educator, consultant and services provider.

Thanks for Reading,

Chris Foot
Oracle Ace
Director Of Service Delivery

The Art of Being a Successful DBA is a post from: Remote DBA Experts