Pedram Rezaei's Ramblings : SQL

Store any data in SQL Server 2008 (Katmai)

pedramr — Mon, 04 Jun 2007 17:51:00 GMT

SQL Server 2008 (aka Katmai) allows seamless transition between relational and nonrelational data, enabling users to access documents as data, encode complex XML hierarchies within XML, and query across relational and text data. So how is this achieved?

There is a new FileStream data type which allows large binary data to be stored in the file system and yet remain an integral part of the database with transactional consistency. And yes, you read correct: with transactional consistency!

This enables scale-out of large binary data to be managed by the database and yet stored on cheaper storage and file systems.

Applications can use a new storage type “VARBINARY(MAX) FILESTREAM” to define table columns and store large binary data as files in the file system instead of as a SQL BLOB. Applications can use T-SQL SELECT/INSERT/UPDATE/DELETE statements to query and modify FILESTREAM data.

The FILESTREAM type leverages Win32 rich set of streaming APIs which is proven to be more efficient and faster the larger the data gets.

More on this and other new features of SQL Server 2008 later!

In the meantime, if you are thirsty to see more, then why not downloading the first Community Technology Preview (CTP) of SQL Server 2008 from here or here?

Oh, and if you haven’t guessed by now, Katmai is the code name for SQL Server 2008.

SQL Server 2005 Database Mirroring

pedramr — Thu, 05 Apr 2007 16:51:00 GMT

Customers often raise the following concerns and questions regarding the Database Mirroring feature of SQL Server 2005. In here, Don Vilen a Program Manager for SQL Server Database Mirroring and I have responded to some of these concerns and questions:

1) performance - synchronous mirroring has well documented performance statistics for instance index rebuild takes longer than before...

Synchronous mirroring guarantees zero data loss; the method it uses is to keep two copies of the database identical in structure, copy the log from one to the other, and replay the log operations on the second copy. So yes, everything that goes into the log must be sent to the mirror. Most log records can be sent to the mirror in a partially asynchronous manner, but when a COMMIT record is put into the log, all pending log records must be sent to the mirror and the COMMIT record must be written on the mirror before we can acknowledge the COMMIT to the client who committed his transaction.

Regarding index rebuild: if rebuilding is necessary on a large table, consider table/index partitioning where you can rebuild indexes on only the partitions that need it, thereby reducing the impact. It is worth mentioning that partitions are only available in the Enterprise Edition.

2) mirroring occurs at the database level – what about queries that require data from multiple databases?

Yes, Database Mirroring occurs at the database level. Some customers mirror multiple databases, but they must then manage the failover manually so that all databases involved failover at the same time. Failover Clustering may be a good solution for this as it works at the instance level rather than the database level.

3) mirroring relies on good network infrastructure and low latency- which is not always provided - low latency can significantly drag down the performance of the principal

Yes, you need good infrastructure (unfortunately we are not able to overcome either the laws of physics or the laws of information theory). An alternative is to use asynchronous mirroring as it handles network delays somewhat ‘better’, though it does not provide a guarantee of zero data loss or automatic failover. For asynchronous operations, you may want to consider SQL Replication.

4) if mirror server is down, logs will grow on principal which could cause disk space issues on the server.

Yes, as with replication we need the information to remain in the log until we can send it over to the mirror. If this takes too long, some intervention will have to be made, perhaps having to stop the mirroring session. We will need the log records to catch the mirror up to the principal.

5) imagine a setup in which the principal server is in one room and the witness and mirror in the other. What happens if the communication between the rooms fails?

For the Principal to remain the Principal it must have 2 of the 3 ‘votes’ in the mirroring session. Otherwise it might be carrying on as the Principal while the Mirror has also become the Principal. In this scenario, work is being done at both sides of the mirror which would be an undesirable situation. Put the witness nearer the preferred principal, so that if the communication fails between principal and mirror, that the witness will still see the preferred principal and therefore ‘vote’ for the principal to remain the principal, rather than have it see the preferred mirror and not see the preferred principal so it would vote for the mirror to become the principal with the mirror now having 2 of the 3 votes so it will become the principal. This is exactly what the witness is for and how a distributed system like this must prevent the ‘split-brain’ problem where both sides of the mirror assume the other side is dead and so they should take over and continue.

6) failover clustering or database mirroring?

In database mirroring, as the name suggests, the protection is offered at the database level, whereas, failover clustering provides protection at the SQL Server instance level. Another major difference is that in the case of database mirroring both the mirror and the principal get their own SQL Server instance with distinct names. However, in the case of clustering all nodes are given one virtual server name and IP address. It is also important to mention that unlike clustering, database mirroring does not require proprietary hardware and does not have a potential failure point with shared storage.

Where to go if you need more information? Ron Talmage has produced a comprehensive whitepaper on Database Mirroring in SQL Server 2005.

SQL Server 2005 Compact Edition is now available

pedramr — Tue, 16 Jan 2007 11:51:00 GMT

SQL Server 2005 Compact edition runs as an in-process application, with a very small footprint (less than 2 MB disk footprint) offering you a good subset of the T-SQL features, and replication features of a full blown SQL install. DB Size is capped at 4GB, should you want to be able to deal with that amount of data on a portable device.

- SQL Server Compact Edition is tightly integrated with Microsoft Visual Studio

- As the database is embedded in the application, little or no management is required.

- It even has self healing and management technologies built in to handle “instant off” and dead battery scenarios in mobile devices.

- ...

System requirements: http://www.microsoft.com/sql/editions/compact/sysreqs.mspx

SQL Server 2005 Compact on Microsoft.com: http://www.microsoft.com/sql/editions/compact/default.mspx

Download SQL Server 2005 Compact: http://www.microsoft.com/sql/editions/compact/downloads.mspx

SQL Service Broker: The Impatient Way!

pedramr — Fri, 29 Dec 2006 21:34:00 GMT

For those of you who are interested in creating your first SQL Server 2005 Service Broker conversation but are impatient as I am, just grab the code below and give it a try:

-- Enable service broker
alter database [YOUR_DB_NAME] set enable_broker

-- Create a message type. You can also specify

-- An XML schema to validate messages of this type:

create message type TestMessageType

validation = none

-- Create a send and a receive queue

create queue TestSendQueue

create queue TestReceiveQueue

-- Now create a contract for our message type.

-- A contract defines the message type

-- which can be used by a service broker conversation.

-- You can also specify who (initiator or target)

-- can send messages of this message type

create contract TestContract

(TestMessageType sent by any)

-- We now need services. A service is particular task that

-- allows us to send and receive messages

create service TestSendService

on queue TestSendQueue (TestContract)

create service TestReceiveService

on queue TestReceiveQueue (TestContract)

-- The next step is to start a dialog between

-- services on a specific contract

declare @conversationHandle uniqueidentifier

begin dialog conversation @conversationHandle

from service TestSendService

to service 'TestReceiveService'

on contract TestContract

with encryption = off

-- Now try and send a message using the above conversation

-- The first step is to get the conversation handle (it is important

-- to note that the same conversation handle returned

-- by the BEGIN DIALOG statement could also be used - just

-- drop the GO statement)

declare @conversationHandle uniqueidentifier

select @conversationHandle = conversation_handle

from sys.conversation_endpoints

where far_service = 'TestReceiveService';

send on conversation @conversationHandle

message type TestMessageType

(N'Test Message (' + cast(newid() as varchar(36)) + ')')

-- Now receive from the queue

receive convert(nvarchar(max), message_body)

from TestReceiveQueue

Good luck!