Wednesday, December 03, 2008

One sandwich short of a picnic

I had an issue at work the other day, something that seems kind of odd to me. You see in Sql Server 2000 you could setup a view with an order by. Of course this required a TOP 100 PERCENT to be specified at the top of the query. You could then take that view and base new views off of it and all results would be ordered by the original view. In Sql Server 2005 (SP1 or even SP2) everything changed, now you could no longer get the correct order by if you coupled it w/ the TOP 100 PERCENT in your view, but then again, if you do not use a the TOP keyword you can't save your view. The solution to how to get around the issue is in the following blog article.

A proposed solution has been placed on the MSDN site so you can vote on it. It seems the proposal is to do away with the ability to create ordered by views which technically go against the rules of rational theory....

Friday, June 06, 2008

Watch those servers

If you're an active DBA, you'll find that your mornings are spent reviewing failed jobs and checking to see what else needs watching. At my company we were fortunate to purchase Idera's Diagnostic Manager. It is a good tool for reviewing your databases at a quick glance and identify any areas that need attention, ie. Space constratins, failed jobs and other critical processes.

Not everyone has the ability to go out and spend thousands of dollars on a monitoring solution. That's why I really liked the following article by David Bird over at Sql Server Central (one of my favorite Sql Sites) titled SQL Overview IV - DBA's Morning Review ( In it he describes a set of reports that you can use to review your servers quickly during the morning and spend more time fixing problems than reviewing things. I Plan to implement many of these solutions in my own environment and see how well it stacks up to our paid solution. I will report back and let you all know!

Change your Recovery Model

On occasion you may be tasked with switching your recovery model for a database. This task is very trivial and you may already know how to do this via Sql Server Enterprise Manager or even Management Studio. But you can do this via Tsql as well (as with all things sql server related)

The syntax is basically

The recovery Models available are, Simple, BulkLogged and Full.

The Simple Recovery model is as you guessed the basic recovery model which pretty much allows you to recover your database from a full backup. The simple recovery model is ideal for test and development databases where data loss is not generally a concern. You may wish never to use this model in a production environment unless the business is willing to loose up all data changes since the last Full or Differential backup. In this model you do not have to maintain the Transaction log as nothing is generally written to it.

The BulkLogged Recovery model will log every event except those that are Bulk transactons. This has almost the same recoverability as a Full Recovery model. With this recovery model you can do full, differential and log backups, you are also capable of restoring up to the minute so long as your last change was not a bulk logged operation, in which case those changes will remain lost. You will need to schedule a regular backup for your transaction log for those operations that are not Bulk transactions.

The Full Recovery model offers the highest amount of protection against data loss. This model allows you to recover any piece of data up to the minute (prividing you have the last backup). You can do full, differential and log backups. You can restore any of the backups for returning to your point in time. Such as a FULL backup followed by a Differential and finally your set of Log backups until the point in time when the failure occurred. In this recovery model you will want to schedule a regular log backup for your transaction, otherwise your database log files will grow and grow.

Friday, March 07, 2008

Defrag or don't defrag that is the question!

Back in 2005 I wrote a quick 'n' dirty post (really) about how to maintain indexes. That applied to Sql Server 2000 well enough but did not even touch what was happening with Sql Server 2005. Instead of writing a separate article on 2005, which now come to think about it, I may want to. I instead opted to update my older post, and it now reads more like an article. I've included the link below so that it's quick / easier to find. In this article I also posted up my own defrag monitor script, which should be helpful in locating defraged indexes and that way you can easily defragment only the ones that matter.

Good Luck!