This weekend was SQL Saturday #33 in Charlotte NC and also the first one I attended. It's been a long weekend, but I wanted to get my thoughts down while they're still fresh. Be warned, it's been a long weekend, so my grammar and attempts to reign in my propensity for verbosity have both gone out the window.

Background

Sorry SQL Saturday? Tarwn and SQL? We have questions and we know how painful it is for you to write short blog posts...

SQL What?

SQL Saturday is...

Do you benefit from compressed backups if your data is compressed already? This was a question that was asked recently; I thought that the question was interesting and decided to do some testing.

Here is what we will do; we will create two databases with only one table. In one database we will use page level compression and in the other database we won't use compression. After that we will backup each database twice, once with backup compression and once without backup compression. After that, we will do restore from these backups. After doing all these, we will find out if data com...

To sync or async...

Over the weekend on twitter, the topic of high availability over a Wide Area Network (WAN) came up. The limit of 140 characters doesn’t do this topic justice, so a follow up is a good idea. We’re going to focus on selecting an operating mode of mirroring that the business can handle then the mirror is spread over a WAN. This also came out of the conversations when synchronous mirroring (High Availabi...

Chaos or order?

Managing objects in large and small installations of SQL Server can be a job in itself at times. In particular, for the DBA, objects we create on the instances we manage more often than not are found littered over the user and system databases. These objects more often are found in the master database in SQL Server. Really, why not put them there? We are the “masters” over the database server right? SSMS has this quality to it that when we connect to it, we get the master database glaring us in the face by default just like a booby. So o...

I do not know if there is already code for table sizes (as used in SQL Server 2008 reports) but what I've seen on the net people are using cursors and temporary tables (completely unnecessary).

NOTE (added later):

In order to update table sizes in sys.dm_db_partition_stats you can execute next DBCC (all tables for current database):

DBCC UPDATEUSAGE (0) WITH NO_INFOMSGS, COUNT_ROWS