THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Kalen Delaney

Did You Know? or rather, What Did You Wish You Knew?

Thank you so much for all the responses to the DBA Blunders post! As I mentioned, however, that question was asked on behalf of a friend of mine. Now I have a question of my own.

I am currently training a group of new junior DBAs. One of them has already started assisting with some client operations, but is still closely supervised.

For those of you that are SQL Server DBAs:

What did you wish you knew BEFORE your first day on the job?

(I'm particularly looking for what you consider to be gaps in your education, but anything that answers the question is fine!)

THANKS!!

~Kalen

Published Friday, May 30, 2008 9:48 AM by Kalen Delaney
Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Josh Jones said:

For me, I wish I'd had better knowledge about operational tasks done via T-SQL, i.e. DBCC commands, sp_who2, sp_lock, sp_adduser, etc. I was introduced to SQL Server via Enterprise Manager (7.0), and it took a very long time for me to learn/realize how much more flexible I could be with good knowledge of basic T-SQL commands to manage SQL Server.

May 30, 2008 12:16 PM
 

Denis Gobo said:

I second that, not using EM to add a column was a big step forward instead of watching the hourglass spin.

May 30, 2008 12:21 PM
 

Jeff said:

I wish I knew how big of a pain some of the odd ball MS databases were. Biztalk, Sharepoint etc. They are going to end up on your SQL servers sooner or later.

May 30, 2008 1:16 PM
 

Chuck said:

I thought I was fairly proficient in T-SQL (thinking in terms of sets, not using CURSORs, etc.), but when the manager at my first DBA job demonstrated an aggregation using SELECT SUM(CASE WHEN foo >= value THEN 1 ELSE 0 END) ... my eyes grew wide with astonishment.  Truly a "Eureka!" moment for me.

May 30, 2008 2:32 PM
 

James Luetkehoelter said:

For me it was a lot of the default behaviours of the engine and EM - in particular backup/recovery. For instance, that "backup location" box that makes it looks like you're backing up to a specific file rather than striping the backup amongst all the files. A lot of things like that, which it seems like you don't learn until you get burned.

And I echo other thoughts - a quicker path to the TSQL behind the GUI commands. I love that SQL 2005 has the "Script" button on 98% of all screens...I point newbies to that immediately - never execute it in the GUI, use the GUI to create the script, then save the script. Quicker learner curve for TSQL manipulation of the instance...

May 30, 2008 6:57 PM
 

Saggi Neumann said:

1. Know that changing schema using SSMS or Enterprise Manager isn't always the most efficient way.

2. Knowing that I can get the script used by SSMS/EM before it's actually executed.

3. Know that the best way to learn about much of the internals of managing databases is to run a profiler while doing things in SSMS/EM.

4. Have someone tell me there is a way to undo mistakes if I just BEGIN TRAN .... ROLLBACK before I actually do something (The new SSMS toolpack makes this the default in every new query window opened...)

5. Maybe have a workflow for troubleshooting, like the checklists pilots have in the cockpit. As wel all know, when in emergency, our brains don't work as good as we'd like them to. This is a nice start:

http://sqlcat.com/presentations/archive/2008/04/18/troubleshooting-sql-server-2005-2008-performance-and-scalability-flowchart.aspx

May 31, 2008 2:34 AM
 

Julia said:

Apart from technical stuff, I'd say you need to learn things that help you keep to the DBA equivalent of the hypocratic oath - isn't that 'do no harm'?  I guess examples would be why you don't want to 'select * from huge_table', what's likely to cause log files to blow out, and, from personal experience, not to run scripts with implicit transactions set to on when you don't understand what that really means.  When I've had to interview candidates for DBA roles, I'm generally looking for someone who knows the pitfalls and is unlikely to do anything stupid.

The other big thing for me when I started as a DBA was that, if I didn't know if something was the right thing to do, I either looked it up or asked someone else what they thought.  I've since mentored a junior DBA and the main thing I wanted him to learn was not to be afraid to say 'no' when people asked for changes on the database servers, and, if in doubt, to run it by someone else.

Disaster recovery drills are also a great idea - as a junior sys admin, I had to write DR documentation for a few different systems, and you learn a heap from doing that.  Has the added bonus that you gain a lot of confidence.

June 3, 2008 11:11 AM
 

Julia said:

Oh and, if you are going to use EM (or SSMS), to never EVER click OK to close a dialog if you didn't mean to change a setting.

June 3, 2008 11:13 AM
 

K. Brian Kelley said:

I wish I had known a lot more about replication. The other DBAs had gotten a bad taste for it, but then, there were some fundamental flaws in the way they implemented it. Had I known replication better then, some of our processes likely would have been changed to use it and be more efficient than the methods which were chosen.

June 4, 2008 3:03 PM
 

Zack Jones said:

This is an interesting post. Having been a developer that worked with databases for the past 10 years I now find myself in the role as the DBA. I wish I knew more about things to look for to ensure my databases are running as efficiently as possible. Fortunatley I haven't inherited databases with millions of rows but some day I hope they will grow into that :).

June 5, 2008 8:24 AM
 

Ervin Steckl said:

Just like Zack Jones I also had been a developer before I was working as a DBA (I am still a developer in my spare time). I would send every developer for a year to work as a DBA just to see what their programs are doing, what environment they must to integrate in etc. Many times can I hear complaints like this: "My program is working perfectly in my test environment, why are you unable to set up your environment just like that?" Then after some investiagtion it comes out that in the test environment there is no planned security (they user the "Everyone - Full Control" security "model", which is not possible in a production environment and then the investigation begins: which specific permissions does the program need?

And, I would somehow teach the developers to give up some of their pride and ask (and co-operate with) the DBA about certain things including (but not restricted to) query tuning, data access methods and so on. Often these are not concerned during the development phase and later the developers are resentful when they are told what should be done instead of what they have done in their programs.

I myself have also learned a lot during being in a DBA position so since then I can create more efficient programs.

June 18, 2008 5:25 AM

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

Favorite Non-technical Sites or Blogs

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement