I got an invite to take part in a lab at the Microsoft Technology Center in Waltham. I took advantage of it. I'll use this post to describe the experience so that anyone else with the opportunity will know what to expect. [caption id="attachment_333" align="alignnone" width="450" caption="They knew I was coming"] [/caption] First, you recieve a very explicit set of pre-requisites. You need to install the SQL Server Upgrade Assistant, a tool that Microsoft licensed Scalability Experts to create for them. You have to run this against a small database, >25gb. The tool backups up all the databases from the server (so you need to put it on to a test box, rather than try to move an entire production system worth of databases). It then starts a trace that captures all the…
A question came up on SQL Server Central as to why or how Profiler could bring down the production server. I was aware of the fact that Profiler caused problems and that's why you should always use a server-side trace on production systems. Duh! Of course.... But why? I didn't have an answer. I just "knew" what everyone told me. So I set out to do some research. Initially I hit my favorite source of information on SQL Server (and it should be yours too) the Books Online. Here is what I was reading on the architecture of Profiler. Good, but not enough. I still want more information, so I've gone out a'wanderin' through the interwebs. First, Linchi Shea has this great set of tests comparing Profiler to server side…
I received my evaluation results this afternoon (thanks so much Marcella). I had about 35 people attend the session and 11 took the time to respond. Overall, the session seems to have been well received. I had one person ding me for finishing early. I did finish early, but then we actually went over time on the Q&A session, so I think it was a wash. For my first time presenting in this type of environment, I find this to be useful feedback. I can see where Andy Warren is coming from in suggesting some questions that would be specifically helpful to the speaker would be nice. The questions are primarily aimed at determining whether or not the topic will be useful next year and whether or not the speaker…
Gee, thanks TJay. I have apparently been tagged to take part in a quiz started by Chris Shaw. It's an experiment in learning where a series of people answer the same question, hopefully spreading some useful knowledge. The question: What are the largest challenges that you have faced in your career and how did you overcome those? This is tough. You could answer based purely on technical issues, what was my toughest technical challenge. You could talk about career issues, tough bosses, ignorant co-workers, incompetent subordinates, clueless clients. You could also talk about shifting jobs as companies fail or are mismanaged or you move. You could also talk about missed opportunities, when you faced the large scale challenges and didn't quite rise to the occasion. Anyway... My Answers) 1) My…
I'm working on the chapter on blocking in the new book. Explaining blocking of course means explaining locks. Prior to 2005, to understand locks, you went to sp_lock. Not anymore. Now you can query sys.dm_tran_locks. It's so much more sophisticated than the old system procedure. Best of all, the information within it is simply a view into the internal locking infrastructure, so you're not placing extra load or extra processing on the system to marshal this data. A simple query to get basic locking information would look like this:  SELECT tl.request_session_id            ,tl.resource_database_id            ,tl.resource_associated_entity_id            ,tl.resource_type            ,tl.resource_description            ,tl.request_mode            ,tl.request_status  FROM sys.dm_tran_locks tl That just outputs roughly the same information as sp_lock. Lots more detail, not available in sp_lock, is available if you need it. Things…
From the Data Dude himself. This is great news. I've been working with the CTP's for several months now, telling the other DBA's on my team that they had to wait until it was completely ready for release. It's been a long wait, but I'm sure it's worth it. My congratulations to the team. I met several of you at the PASS Summit. I really apreciate the work you've put into this great tool. It really makes a difference in how we develop and deploy databases. The changes in the GDR are making a great utility even better. Thanks Mr. Drapers. Thanks also to Jamie Laflen, especially for helping validate some of the ideas I presented at PASS. Thanks to all the rest of the team, whose names I don't…
Next year is going to be in Seattle again... Argggh! Another six hour flight. More jet lag. YUCK! Money review. Yawn. But you'd be horrified how much all this stuff costs at the convention center. BTW, I'm pretty excited to be presenting. I know someone else who pointed at their ribbons and said "The only ones that count are MVP and Speaker." I feel the same way about my Speaker ribbon (I don't have the other one). More so because, of 70 or so available slots, more than 500 abstracts were submitted. If you want to thank any particular set of volunteers, I'd go for the program committee. They bust butt. Of course, if your abstract didn't get picked, you might not be too happy with those guys, but look at what…
When I wrote the book "Dissecting SQL Server Execution Plans" I knew I was going to get things wrong. Several people have pointed out things over the last couple of months. They've all been in the details. None of them were serious errors of fact. Andy Warren just found a huge one. In the section on Table Hints I detail how to apply an INDEX() hint. It's on page 123 in the electronic version or 124 of the first print version. I state that index number starts at 0 with the clustered index. That's just flat wrong. A clustered index is always 1. A 0 indicates a heap. Other indexes will have values greater than 1. If you were to supply a 0 to the INDEX() hint, as shown in the book, it forces either…
I finally finished my initial set of tests with the GDR CTP release. It's great! They've solved so many of the deployment problems that we had been experiencing that it's now hard to wait until they actually release the product. The bad news is, it completely changes my presentation at PASS. I'm still going to cover 2005/2008, but now I'm going to cover the GDR as well. I have one hour to hit both processes... That's not going to be easy. Anyway, they've broken everything down to either work locally only or as part of the larger project. It all gets checked into source control. It all comes back out. No manual processes (like checking in the .user file) necessary. Thank you Gert Drapers, wherever you are.
I've mentioned it before and I think it's worth mentioning again, Microsoft Connect really works. I've seen bugs and enhancements listed there receive enough attention that they were in the next release or service pack of the product in question. That brings me to DBPro. We use DBPro for all our database development. It's a great tool. However, it's still a bit to geared toward the individual user and not the team, despite it's moniker (Visual Studio Team Edition for Database Professionals). One thing that really does bother me is how it stores some settings, such as Target Connection in the .user file within a project. This means that each individual sets the connection for the project each time they check it out after another user has had it. Another…