My first book is finally in print. OK. I know. It sounds funny. But my first book was printed in only a limited print run from Red Gate, most of which they gave away at Tech Ed last year. Then they offered it for free in an electronic form. Very few people got a printed copy. Well, if you were waiting around for the dead tree version, it's here! Thanks again to Tony Davis & Brad McGehee for all the work they did. It just wouldn't have been possible without them.
Jamie Laflen and Barclay Hill have published an article in MSDN Magazine outlining the new features in in VSTS:DB GDR. The description of the intent and use of the server project is extremely enlightening. I wasn't aware of the master.dbschema files available for use within a project. Luckily I haven't needed them yet. Another thing I wasn't aware of, if you use the refactoring tools, say rename a table, not only does it save you a lot of typing, but the project will remember that the table was renamed and instead of dropping and recreating it in the next deployment, it will issue SP_RENAME. I'm spreading that word to my team right now. Another good point is that you can make a configuration to work only on your local machine…
Greg Larson posted a really nice query to find worst performing stored procedures in your system. He put in all kinds of attributes to make it customizable, changing the definition of "worst" to different measures,etc. Great query in general. In it he linked to sys.dm_exec_plan_attributes and got the db_id attribute. Duh! So instead of spelunking through the XML to retrieve the database name, I can pull the db_id and use the DB_NAME function. Cleans things up considerably. Thanks Greg. Here's the cleaned up code: WITH XMLNAMESPACES ('http://schemas.microsoft.com/sqlserver/2004/07/showplan' AS sp) SELECT DB_NAME(CAST(pa.value AS INT)) ,s.sql_handle ,s.total_elapsed_time ,s.last_execution_time ,s.execution_count ,s.total_logical_writes ,s.total_logical_reads ,s.min_elapsed_time ,s.max_elapsed_time --,s.query_hash ,p.query_plan ,p.query_plan.value(N'(sp:ShowPlanXML/sp:BatchSequence/sp:Batch/sp:Statements/sp:StmtSimple/sp:QueryPlan/sp:MissingIndexes/sp:MissingIndexGroup/sp:MissingIndex/@Table)[1]', 'NVARCHAR(256)') AS TableName ,p.query_plan.value(N'(/sp:ShowPlanXML/sp:BatchSequence/sp:Batch/sp:Statements/sp:StmtSimple/sp:QueryPlan/sp:MissingIndexes/sp:MissingIndexGroup/sp:MissingIndex/@Schema)[1]', 'NVARCHAR(256)') AS SchemaName ,p.query_plan.value(N'(/sp:ShowPlanXML/sp:BatchSequence/sp:Batch/sp:Statements/sp:StmtSimple/sp:QueryPlan/sp:MissingIndexes/sp:MissingIndexGroup/@Impact)[1]', 'DECIMAL(6,4)') AS ProjectedImpact ,ColumnGroup.value('./@Usage', 'NVARCHAR(256)') AS ColumnGroupUsage ,ColumnGroupColumn.value('./@Name', 'NVARCHAR(256)') AS ColumnName FROM (SELECT TOP 20 s.sql_handle ,s.plan_handle ,s.total_elapsed_time…
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…