tags:

views:

102

answers:

5

Today we're using a shared SQL Server database and that is perfect as I don't know anything about SQL Server maintenance. But for economic reasons we're need to upgrade to a dedicated server.

Given that I don't have time to read the entire documentation, What do I absolutely need to know about SQL Server to not screw this up?

Resource suggestions appreciated!

+3  A: 

Backing up!

Martijn Laarman
+1  A: 

The answer probably has to do with how data-intensive your application is. If it's like most business applications, you're probably OK reading a couple quick start guides and winging it (as long as you back up regularly ... that's important, so read up on that carefully). SQL Server is generally pretty self-tuning, and if you're not talking millions of rows and high TPS, you're probably fine for a little while.

If it is a data-intensive application, or has high availability or throughput needs ... get a DBA, even just on contract. Don't put all your eggs in a basket you can't carry.

Ian Varley
If we could get a DBA we would, but in a startup there's more hats then people.
Niels Bosma
A: 

In order of importance:

  1. How to schedule backups
  2. How to create indexes
  3. How to rebuild indexes

The Profiler and Tuning wizard can help you with 2 and 3.

If you are programming the database and not just administering it, I'd reccommend Robert Vieira's book. It's a great introduction.

Lance Fisher
+1  A: 

Oh, it's the accidental DBA!

Brent Ozar has a handful of useful articles: http://www.brentozar.com/sql/

Don't forget about SQLServerPedia - http://sqlserverpedia.com/wiki/Main_Page

Cheers!

MarlonRibunal
+1  A: 

In terms of backing up, don't forget to backup the transaction log as well as the database, unless you'd like your transaction log to grow until it takes over the entire drive.

I'd also redup an indexing, and statistics and rebuilding each.

Also you should probably get a good understanding of how database security works.

If at all possible get a dev server as well as a prod one. Much much better to test changes on dev than directly in production! Then limit prod access to only a couple of people and make all changes to prodcution happen through tested scripts.

HLGEM