The nice folks at the Inland Empire .NET User Group have invited me to come and speak to them. This is a great speaking opportunity for me as they are about 20 minutes from my house.
I won’t be speaking there until December 9, 2008 (it’s amazing just how far in advance some of this stuff gets scheduled).
I’ll be giving two presentations at the meeting. The first will be the ever popular Query Tuning, and the second will be a talk on the SQL Server 2008 Resource Governor. The address and directions to the meeting can be found on the IE .NET User Group web site. If you are going to attend there meetings they have an RSVP link on the site.
Microsoft has now released the the majority of the upgrade exams from SQL Server 2005 to SQL Server 2008.
Now, I know that this has absolutely nothing to do with SQL Server, and if you read slashdot this is probably going to be old news for you.
But apparently scientists have taken some pictures which show planets outside of the phones in our solar system.
Here’s a blog about it from BadAstronomy.
This article on Spiegel.de has some great images (it’s in German or Dutch or something) but they have an amazing overlay of images of one of the planets from a few years ago as well as the most recent position, including the track of the planet which I think is just an awsome image. This have another planetary system graphic which shows the HR 8799 system compared to our system (the defination is in English on this one).
If you run across any other images feel free to post links to them below.
Here’s another pic of the planet which orbits Fomalhaut with it’s position from 2004 and 2006.
This is just amazing stuff that we are seeing today.
MSDTC (aka Microsoft Distributed Transaction Control) is a piece of software which a lot of people use, but they don’t really know what it does, or how it works.
MSDTC is used by SQL Server and other applications when they want to make a distributed transaction between more than one machine. A distributed transaction is simple a transactions which spans between two or more machines. The basic concept is that machine 1 starts a transaction, and does some work. It then connects to machine 2 and does some work. The work on machine 2 fails, and is cancled. The work on machine 1 needs to then be rolled back.
DTC is for the most part a black box. It just sort of works without much interaction exept for the initial setup.
The only time that DTC needs to be used is when more than one physical computer is going to be involved in an explicet distributed transaction. If you are going from one instance to another on the same server DTC will not be needed. If you are going from one instance to another within a cluster you will want to have DTC available as you may have to go between nodes of the cluster as you have no guarantee that the instances will be on the same physical node.
I hope this helps explain DTC a little bit at least. If you have specific questions about DTC, feel free to post them below and I’ll try and find the answers for you.
I have just been informed that there will be a Lanch Party for the SQLServerPedia.com/Wiki website at PASS on Wednesday the 19th. If you will be attending PASS be sure to swing by Booth 414 (Quest Software’s booth) and pick up your party invite.
Details for the location are on the invite, so be sure and pick one up on Wednesday.
If you haven’t been able to make it to a party that Quest has put on in the past, they tend to go all out.
So you are RDPed into your SQL Server, and you are trying to copy a script from your desktop to the server, or from the server to your desktop. But you can’t for some reason. All you get is what’s in the local buffer.
One option is to log out of the machine and log back in. But this option sucks.
Another option which is much easier is to kill the rdpclip.exe process which is being run by your username on the server you are RDPed into. Then from the Run window relaunch the rdpclip.exe process. This should then allow you to copy the data into the clipboard again, and then paste it on the remote machine.
While dealing with a SQL Server Service Broker issue I needed a quick easy way to see how backlogged the service broker was. So I came up with this little query which is surprisingly effective.
select far_service, state_desc, count(*) messages
group by state_desc, far_service
ORDER BY far_service, state_desc
Hopefuly you find this helpful.
This morning I posted by first article up on SearchWinIT.com called “Does your SQL Server database improve SharePoint performance?“. It is all about getting the most out of your SharePoint environment by getting the most out of your SQL Server.
I’m happy to say that the webcast which I did with Jason Hall on Thursday October 30, 2008 has been archived for after the fact viewing. They say that it is up there for a limited time, so I’m not sure how long it will actually be available for.
You can find the webcast over in Quest Software’s Events section.
A while back I was talking to a Microsoft Support Engineer and he had mentioned that in a high load Service Broker environment such as ours there can be some impressive performance improvement can be achieved by reusing the service broker sessions.
The cost of creating and closing a new conversation for every message is about 4x, while the performance increase when receiving messages is about 10x. Remus Rusanu talks more about the numbers and shows a solution for reusing conversations on his blog posting Reusing Conversations.
I liked Remus’s solution, but an issue that I had with it was that I didn’t want to have a different conversation for each spid. If I used this method I would end up having hundreds of conversations open and I’d need a job to close them. Within our application any number of events can trigger a service broker message to be sent off. We usually have a few hundred threads logging in and out of the database at any one time.
This required that I take Remus’s solution and make it more flexible before moving it into our environment. The solution that I’ve come up with supports a single conversation for each process within our application. And at random intervals those conversations are closed, and new ones are started. Continued »