A lot has been happening over the course of the last month. It was very nice to take a much needed vacation with the family, upon coming back our team has had the opportunity to upgrade several of our SQL Servers to 2012 (which I’m thoroughly excited about).
While I was out, SQL MVP Chris Shaw, had the opportunity to host T-SQL Tuesday #30 where he discussed Ethics and the DBA. I felt it prudent to blog on this even though I missed the timeline as it seems to be a pretty important topic that will always be around with a lot of opinions.
After reading SQL MVP Chris Shaw’s post, I always had this preconceived notion of what I deemed ethical in my day to day activities as a DBA. I have my own standards that I set high for myself and strive to maintain; have I ever given much thought to a set of authoritative rules for the whole DBA governing body?? It has crossed my mind but like others I think how in the world would one police such a thing and who would be responsible for it?
The institution I work for very well could have a totally different set of standards than the institution you work for so how would that play out? No, to me, the situation is so diverse I don’t see a certain set of ethical standards being derived for DBA’s in general, but I do think that every DBA should have a very high set of standards in place for themselves even if the company where you work does not have any in place. DBA’s in general are responsible for so much and are such an integral part to a company that if standards aren’t in place I truly believe can cause severe damage.
After reviewing the post(s) by so many others I found it interesting to see everyone’s points of views. DBA’s are a brotherhood, we are a close knit community. We have high standards for ourselves which is the way it should be. Take pride in what we do and give it 110%.
To review the SQL Tuesday #30 wrap up on Chris Shaw’s site you can go here.
Recently, I approached a person in a business unit and asked if they had some standard documentation on one of their processes. The reply I received in general terms was, “No we do not have any standard documentation but we do continue to build on our processes”.
Knowing how I am, I began to read into it and I couldn’t get passed that statement. Then it dawned on me, of course everyone is different and we all have different mindsets. My DBA processes I feel must be documented, but others will not necessarily share that same view point – especially in other business units.
I’ve always heard that documenting is an age old battle; most people I know don’t like doing it but for me I do believe it is a necessity. I’m not the best at it but having standards in place within a team or solo act is beneficial for the next person that comes in. One of my old mentors several years ago told me if he walked out to lunch and something happened to him he would want me to be able to pick up a process even if I didn’t know it and look at his documentation and be comfortable in completing the task. Somewhere along the way that kind of stuck with me. Some of the standard documentation we have put in place for the DBA team that I’m on are:
- Backup Procedures
- Job Retention
- Server Installations
- Code Promotions
- Object Naming Conventions
- Job Notifications
The list could go on but those are some high level ones that I just threw out there. Documentation made it on SQL Server Pedia’s “10 Things Every DBA Should Do” – the article came from John Sansom who really has a great blog; I suggest you check him out.
One of the things I like to do when starting new employment is to look at their documentation; some cases it doesn’t really exist. I like to take that and use it to gain knowledge of the systems and what they do. Documentation……”To Document or Not To Document ~ That is the question” To me it is a no brainer.
Drop me a line and let me know what your thoughts are if you think documentation is important or not important and some standards that you may have in place.
In all my years experience with SQL and being a developer before transitioning to become a DBA I will answer for me personally NO. Each developer has their own niche or style that they use when writing code. I’ve seen some pretty wild and insane ways people develop. I worked with one guy several years ago who would name his counters off t.v. shows so every now and then you might have a skipper or a s.s. minnow thrown in. I hope and trust that development teams have set their own standards better than the one we had years ago…..however even with standards I think as a DBA we need to be able to communicate and bridge the gap that it just makes sense that when you receive a data script or migration script that it is in an expected format than everyone adheres and agrees to with no gotchas.
Recently this standard below was presented; given what the business needs are the script will allow for multiple servers that the script will be allow on. This is particular handy since some people may or may not accidentally run the script on an environment it shouldn’t be ran on. This also is helpful in dealing with a CMS server.
IF @@SERVERNAME IN (‘ServerName’,’ServerName’) /*Enter Valid Server Name/Instance*/
PRINT ‘An error has occurred. Rolled back!’
PRINT ‘PLEASE EXECUTE ON ServerName ONLY!’ /*change server name*/
Whatever your choice of a standard is work toward getting things streamlined and laid out so there are not variations of the same kind of step. When it is up front and in your face as a standard it is easier to follow and maintain.