If you have looked at pretty much any Microsoft provided T/SQL code you have probably seen an N in front of a string value when setting a variable much like this.
WHERE name = N'master'
What this N does is tell the SQL Server that the data which is being passed in is uni-code and not character data. When using only the Latin character set this is not really needed. However if using characters which are not part of the basic Latin character set then the N is needed so that SQL knows that the data being given it is uni-code data.
The path that Microsoft is going says yes. They are moving all there samples and defaults to using uni-code. In reality uni-code may not be needed in your environment. If you are storing only Latin characters (the US alphabet characters) then you probably don’t need to store uni-code characters. However if you are planning on moving your operations to support customers who do not speak English then you will want to setup your database and application to use the uni-code data types (nvarchar, nchar, ntext).
It doesn’t take much extra to use uni-code data types, however do keep in mind that it does require more disk space to use uni-code data types. For each character saved two bytes of disk space are used instead of one byte. While this may not seam like much space if you will have a large table with a large ntext field this can use a lot of space quickly.
I know that this is normally a technical blog, but with the US Thanksgiving day holiday coming tomorrow I wanted to be sure to point out that time needs to be made out of our busy work schedules to make sure that we spend time with our families. It’s very important that we find a good balance between work and family.
Microsoft announced at TechEd in Barcelona, Spain that the SQL Server 2008 November CTP would be made available this month. Read more here.
Microsoft has just posted the URL to download the new CTP. http://www.microsoft.com/downloads/details.aspx?FamilyId=3BF4C5CA-B905-4EBC-8901-1D4C1D1DA884&displaylang=en
I’ve published a new tip over at SearchSQLServer.com entitled Update SQL Server table statistics for performance kick.
When you setup your data center, something that seams to be getting overlooked these days is the data center environmentals. We all know that we need batteries and a generator for the power to keep the servers online, and that we need AC to keep them cool. But I’ve seen a disturbing number of very large data centers who do not have the AC on the generators. This creates a problem when the power goes out. While it’s great that the servers will stay online the data center will quickly get up into the 100+ degree range (F). This can quickly lead to data integrity issues is the hard drives start to fail.
Just a couple of days ago a client of mine who hosts there servers at a company (who shall remain nameless) and their power when out for about 3 hours. The temperature went up to 120 degrees in the data center, because the AC system which they brag about having wasn’t on the generator. They actually called all their clients asking the clients to power down any systems which aren’t mission critical in order to save heat. Frankly, I was surprised that the machines didn’t start to power them selves down. I guess the HP servers are built a little more robust than I thought (not that I really want to try again).
There are a several benefits of moving to 64bit hardware. 64bit hardware supports more CPUs than 32bit hardware. In addition the 64bit hardware can access way more memory than 32bit hardware. 64bit hardware can use up to 2 TB of data, while 32bit hardware will typically max out at 64 Gigs. What is especially important in that 64bit hardware does not have the AWE requirement that 32bit hardware does so all the memory can be addressed natively without having to go through the AWE driver. In addition to allowing software to access more than 2 Gigs of memory natively it allows allows SQL Server to use more procedure cache as I’ve spoken about.
The 64bit system architecture also processes math functions much faster than the 32bit system architecture. Some software is especially excellent at utilizing this additional power including SQL Server and Exchange server.
Working in IT can be a fun and exciting career, however it can also be an extremely demanding one. When working in IT you have to find a balance between work and family. Without finding that balance you’ll end up with either a very unhappy employer or a very unhappy family.
Myself I am very lucky that my wife works in IT and is very understanding about the occasional long hours. Not everyone is as lucky as I am to have someone at home who works in the field. I can’t give advise on how to find the balance, mostly because it will be different for everyone. I just know that it is very important to find this balance because without it, in time the work will not seam important.
If you have ever seen the BACKUPTHREAD wait type in the sysprocesses table or sp_who2 output and wondered what it is, I have found the answer.
The basic explanation is “Used when waiting for a backup thread to complete. Wait time may be very long (minutes, hours).” Basically what this means is that there is a backup running and something is waiting for it to complete.
When i saw this show up I was running a restore. That restore had three entries in the sysprocesses table. The first was the main kpid, with two child kpids. The parent kpid was the wait type of BACKUPTHREAD while it was waiting for the child kpid to finish processing. In my case the wait time was short, and it seamed to switch from this wait type to an IO wait type.
Service Broker is a transaction message queueing system build into Microsoft SQL Server. It provides you with in order, guaranteed single read, message processing that is handled and managed with T/SQL code. This makes it extremely easy to send and process messages either within a single database, or send those messages to a remote database on another server for processing. Messages are sent as XML documents so a message payload can contain a single field of data or a multiple row record set as a single message.
For those familiar with Microsoft Message Queue you will find that Service Broker is very similar to MSMQ but is native to the Microsoft SQL Server.
Server Broker can route messages from database to database, or server to server. Messages can be processed or routed to another server for processing there. Queues can be setup to hold messages for processing by an application or job, or have the messages processed as soon as they arrive by an activation procedure which is simply a procedure which is fired as messages arrive. Activation procedures can be run as a single thread or several threads pulling from the same queue at once.
Look for a future blog posting on configuring and using the service broker to send and process messages.