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.

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

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.

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.

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...

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

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.

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.

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.

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 :).

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.