Get involved with the development process

I recently was involved with a production database performance problem that was narrowed to a problem with some code that had just been implemented days before. It seems that new records placed into a certain table go through a process where a five-digit alphanumeric 'unique' key is generated, then the table is searched to see if the 'unique' key already exists. If it does, an new 'unique' key is generated and searched for again. This process happened 800-2000 times for each record. With about 200 users in the system, you can see how quickly this ridiculous process became unmanageable. This process is so illogical, that even non-DBA's shook their heads when it was described to them.

No DBA, no matter how unseasoned, would allow code like this into a production environment without questioning it. How about using a database sequence to generate truly unique keys? Or using the dbms_random procedure? It became apparent that no DBA was involved in the development process. The lesson here is that if the application is placed on top of a database, there needs to be a DBA resource involved in the development process from the beginning. If you are a DBA in this situation, get involved or learn to spend most of your time cleaning up messes like this.

Complacency Kills?

I have a military background and the first thing you get taught in counter-terrorism training is that 'complacency kills'. Complacency means that you start feeling secure and unaware of potential danger. This may sound a bit extreme, but I ran into complacency in the DBA world just last week. I was interviewing a potential candidate to fill a full-time Sr. DBA position. On paper, this candidate looked good. They had worked in both large and small shops doing a variety of tasks. During the interview, though, they were not able to recall how to perform the most basic of tasks or speak in detail on processes and procedures. Another glance at this candidate's resume showed that they had worked in a large shop since 2007 and were the senior member of a team of four. It had become apparent that this person had gone from a well-rounded DBA to a 'button pusher' all because of complacency. This person was obviously more concerned with collecting a paycheck than keeping their skills current. In the world of IT, this is a death sentence. Once you lose your interest in the technology, you may as well look to another career field that you are interested in.

Saving a buck?

I was recently approached by some project managers who were facing implementing a new database to support a third-party application. To save the cost of new Oracle licensing fees, they wanted to add the new database into an existing database system. Seems like a good idea at the time, and I could go ahead and agree being as I will not be here in the long run to deal with the side affects as I am a consultant, but would it be the right thing to do? Probably not. The right thing was to not recommend coupling an existing production system with one whose performance characterisitics are not known. Another alternative would be to run it for a few months without a license just to determine the performance characteristics to determine if it could cohabitate with an existing database comfortably, but I could not recommend that.

Bragging rights?

I was recently sent to help a company who's onsite DBA wanted to point out upon meeting me that they had "18 years of experience". This person then proceeded to impress me by not being able to build a two-node RAC cluster when given two weeks and all resources including root access on the servers. After several more "impressions", this person resigned and has not been heard from since. I should have kept in touch because wherever this person goes, there is a contracting opportunity. Bottom line, if you are too concerned with talking the talk, you probably can't walk the walk.

Welcome to Ora-vent

Sometimes those of us who work in the Oracle realm; whether we are DBA's, developers, or architects, need to get stuff of our chests, stuff that only fellow Oracle guys would understand. That's what this blog is for. All I ask is that you keep it clean. Other than that, have at it. I do reserve the right to decide what and what not to post, however. Thanks.