Denny Lee's Windows Live Space: SQL

Introducing SQLCAT.com

Sun, 03 Feb 2008 21:22:15 GMT

The SQL Customer Advisory Team has put the final touches on the site http://sqlcat.com/ which is our new hub for all things that are part of the SQLCAT! Our new site is a portal to all SQLCAT resources including:

Top 10 Lists: Summary list of Best Practices and Recommendations
Technical Notes: Deep level technical short papers
Technical Spotlights: Technical end-to-end customer case studies
Searchable and Tagger friendly; post comments and provide feedback!
Search all of our SQLCAT Best Practices Whitepapers
Easily find our SQLCAT Blogs and other materials

The site is regularly updated with deep technical information on enterprise SQL implementations.

SQL 2008 Case Study on Auditing, DMF, Encryption, Performance, Resource Governor, and Reporting Services

Tue, 11 Dec 2007 22:36:09 GMT

One of the first case studies for SQL Server 2008 was developed by Caregroup Healthcare Group using various features of SQL Server 2008 for their 2TB patient information system. The case study goes into their use of Advanced Data Auditing, Transparent Data Encryption, Declarative Management Framework, Performance Data Collection, Resource Governor, and Reporting Services to provide a high performance Patient Billing and Lab Results database. For more information, please refer to the Caregroup SQL Server 2008 case study.

Scalable Shared Databases

Mon, 22 Oct 2007 23:50:16 GMT

There have been some questions that have come to my attention concerning the concept of Scalable Shared Databases and comparing it within the context of Oracle RAC. If you want to read the SSD vs. Oracle RAC comparison, you can refer to the link Comparing SQL Server 2005 and Oracle RAC. As well, you can also refer to the SQL Server Books Online content on the subject of Scalable Shared Databases on the subject.

Saying this, the purpose of Scalable Shared Databases is to make use of SAN technology in order to allow you to attach a single read-only database to multiple server instances so that way you can have scale out many concurrent queries of your SQL database to the aforementioned multiple server instances. We have versions of this approach for Analysis Services one specific to using SANs (Scale-Out Querying with Analysis Services using SAN Snapshots) and one not specific to the use of SANs (Scale-Out Querying with Analysis Services). Saying this, you could always rename the concept of Scalable Shared Databases as Scale-Out Querying with SQL Server.

But I digress, extracted directly from the technical (hence most important) link is the Scalable Shared Databases are supported by SQL Server 2005 from Microsoft Support:

Scalable shared databases
Scalable shared databases let you attach a read-only reporting database to multiple server instances over a storage area network (SAN). A reporting database is a read-only database that is built from one or more production databases that are used exclusively for reporting purposes. To be made into a scalable shared database, a reporting database must reside on one or more dedicated read-only volumes. The primary purpose of these read-only volumes is to host the reporting database or a coordinated set of reporting databases. These volumes are known as reporting volumes.

Benefits
Scalable shared databases offer the following benefits: • Provide workload scale-out of reporting databases by using commodity servers. A scalable shared database is a cost-effective way of making read-only data marts or data warehouses available to multiple server instances for reporting purposes, such as running queries or using SQL Server 2005 Reporting Services.
• Provide workload isolation. Each server uses its own memory, CPU, and tempdb database.
• Guarantee the same view of reporting data from all servers if all the server instances are configured identically. For example, all servers would use a single collation.

Note Optionally, you can update the reporting database on a second reporting volume. For more information, see the "Maximize the availability of a scalable shared database" section.

Restrictions
The following restrictions exist for a scalable shared database: • The database must be on a read-only volume.
• The data files can be accessed over an SAN.
• Scalable shared databases are supported only on Microsoft Windows Server 2003 Service Pack 1 (SP1) or a later version of Windows Server 2003.

For the technical details, please refer to Scalable Shared Databases are supported by SQL Server 2005

SQLCAT tracks at 2007 SQL PASS

Wed, 12 Sep 2007 18:53:46 GMT

As you may already know from Brian Moran's SQL Server Magazine article "SQLCAT to Offer Six Sessions at PASS", the SQLCAT team will be providing 6 SQLCAT tracks at the 2007 SQLPASS event in Denver this year. As of today's schedule, below are the SQLCAT tracks schedule:

Wednesday, September 19th 9:45am-11:00am
DBA-410-M
Designing for Petabyte using Lession Learned from Customer Experiences
Lubor Kollar, Microsoft; Kevin Cox, Microsoft
Korbel 1C/1D

Wednesday, September 19th 1:30pm-2:45pm
DBA-411-M
Building High Performance Microsoft SQL Systems Using Lessons Learned From Customer Deployments
Michael Thomassy, Microsoft; Burzin Patel, Microsoft
Korbel 2A/2B

Thursday, September 20th 9:45am-11:00am
DBA-412-M
ISV Configuration & Implementation using Lessons Learned from Customer Deployments
Juergen Thomas, Microsoft; Mike Ruthruff, Microsoft
Korbel 1A/1B

Thursday, September 20th 1:30pm-2:45pm
DBA-413-M
Building Highly Available Microsoft SQL Server implementations using Lessons Learned from Customer Deployments
Prem Mehra, Microsoft; Lindsey Allen, Microsoft; Sanjay Mishra, Microsoft
Korbel 2A/2B

Friday, September 21st 9:45am-11:00am
DBA-416-M
Building & Deploying Large Scale SSRS farms using Lessons Learned from Customer Deployments
Denny Lee, Microsoft; Lukasz Pawlowski, Microsoft
107/109

Friday, September 21st 1:00pm-2:15pm
DBA-415-M
Building & Maintaining Large Cubes Using Lessons Learned from Customer Deployments
Nicholas Dritsas, Microsoft; Eric Jacobson, Microsoft
108/110/112

Using Included Columns in SQL 2005

Tue, 15 May 2007 00:13:55 GMT

Roman Rehak has got a quick and great explanation on the feature of using "INCLUDE" columns at: http://sqljunkies.com/WebLog/roman/archive/2007/05/03/32225.aspx

The purpose of Included columns is to help improve query performance yet at the same time the dB engine will not consider these columns when calculating the number of index key columns or size.
http://msdn2.microsoft.com/en-us/library/ms190806.aspx

A quick way to list out the included columns of indexes on a table, you can use the query below:

declare @table_name varchar(256)
set @table_name = '<Table Name>'
select i.[name] as IndexName, i.[Type_Desc] as IndexType, i.[Is_Unique] as IsIndexUnique, c.[name] as ColumnName, c.[column_id], ic.[Is_Included_Column]
from sys.index_columns ic
inner join sys.columns c
on c.object_id = ic.object_id
and c.column_id = ic.column_id
inner join sys.indexes i
on i.object_id = ic.object_id
and ic.index_id = i.index_id
where ic.object_id = (
select object_id from sys.objects where [name] = @table_name
)

How to experience the data model

Mon, 27 Mar 2006 23:31:04 GMT

For anyone and everyone that would like to know more about how to: "Experience the Data Model", check out Scott Thornton's blog at: http://dataglass.blogspot.com/2006/03/how-to-experience-data-model.html

As he says, the bottom line for building a data model is
1. Increases your chances of the new system fulfilling the actual business needs
2. Decreases your time-to-delivery for a working system
3. Increases reliability, predictability, and maintainability of the new system by encouraging the use of code generators and code templates in strategic ways early on in the design phase

Rock on Scott!

Recursive Query

Sat, 04 Feb 2006 05:03:44 GMT

Use of Recursive Commom Table Expression (CTE)

If you have a parent-child table, a common thing to do is to run a recursive query that can list out all of the parent-child path strings.

For example, if you have a table called Taxonomy, with the format / data below:

TaxonomyID	ParentTaxonomyID	TaxonomyName
2	1	Shoes
3	1	Accessories
20	2	Ladies
21	2	Men
22	2	Kids

And you will want to list out the values:

\Shoes

\Accessories

\Shoes\Ladies

\Shoes\Men

\Shoes\Kids

To do this, you can use Recursive Common Table Expressions (CTE) to quickly get you that query instead of doing a loop query. To do this, the query below sets up the tree to store the parent-child table.

WITH tree (data, id, level, pathstr)
AS (SELECT TaxonomyName, TaxonomyID , 1, CAST(TaxonomyName AS VARCHAR(MAX))
      FROM dbo.Taxonomy
     WHERE TaxonomyID = ParentTaxonomyID
     UNION ALL
    SELECT TaxonomyName, TaxonomyID, t.level + 1, t.pathstr + '\' + TaxonomyName
      FROM dbo.Taxonomy V
      JOIN tree t
        ON t.id = V.ParentTaxonomyID
     where TaxonomyID <> ParentTaxonomyID)

And you can query the tree by:

SELECT SPACE(level) + data as data, id, level, pathstr
FROM tree
ORDER BY pathstr, id

Yukon Replication Presentation

Thu, 27 Oct 2005 05:33:40 GMT

For more information on Yukon Replication, Matt Hollingsworth has a great presentation at:

https://www118.livemeeting.com/cc/mseventsbmo/view?id=1032243908&pw=webcast

Best Practices for Deploying SQL Server 2005 on SANs

Sun, 16 Oct 2005 06:04:39 GMT

A good Technet web cast about deploying SQL Server 2005 on SANs can be found at:

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032275438&Culture=en-US

As well, an I/O and Disk Management course based on SQL Server 200 can be found at:

http://sqldev.net/download/conf/SQLConnections-2005-03-USA/SDB405%20-%20SQL%20Server%202000%20-%20IO%20and%20Disk%20Management%20Internals.zip

As for mirroring with SQL Server 2005, a good resource is:

http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirror.mspx

A great recent addition is the paper by Mike Ruthruff:

http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/pdpliobp.mspx

Yukon SQL Update Performance

Wed, 28 Sep 2005 21:26:49 GMT

An interesting observation on Yukon SQL, sometimes an update statement's performance is quite slow. For example, let's present a SQL table with 3+ million rows with a LogAuditID column , int data type, value of 0 for all columns; the table contains a nonclustered index not on the LogAuditID column. If I wanted to update all of the rows within this table with a value of 1, running the following statement:

update [table] set LogAuditID = 1

is quite slow. On both single proc and multi-proc boxes, this one simple statement can take a long time to run.

But, if you re-write the same statement (taking advantage of the fact that LogAuditID originally is 0), you can run the following statement:

update [table] set LogAuditID = LogAuditID + 1

This statement will take ~4:15 (mm:ss) on a single proc box (faster on a multi-proc box).

Even shorter still, you can specifically indicate to the SQL Server engine to not use the existing indices when performing the audit:

update a set LogAuditID = 1 from [table] a with (index(0))

This particular statement runs in ~3:30 (mm:ss).