Wednesday, April 16, 2008

Here's a quickie just before we head off to SQL Connections in Orlando (see here for all out pre/post cons and sessions).

On one of the internal MS forums was the question - how can I tell through T-SQL the last time SQL Server restarted (i.e. the current 'uptime')? The answer relies on the fact that all the background tasks that start when SQL Server starts must record a 'login time'.

You can get this from:

SELECT [login_time] FROM sysprocesses WHERE spid = 1;
GO

Or more simply:

SELECT MIN ([login_time]) FROM sysprocesses;
GO

Pretty neat trick!

As with the last few conferences, I'll try to blog every day during SQL Connections under the Conference Questions Pot-Pourri category.

Hope to see a bunch of you there!

PS Some people have suggested that checking the creation date of tempdb will also do the trick. That's not a *guaranteed* method as PSS could have used T3609 to recover tempdb instead of recreating it (if they're troubleshooting some tempdb issue). In that case the creation date of tempdb will *not* be the time the server started. Checking the time in sysprocesses is the only infallible method.

Wednesday, April 16, 2008 5:27:19 PM (Pacific Standard Time, UTC-08:00)  #    Comments [7]  | 
Tuesday, April 01, 2008

 

(And this isn't an April Fool...) I'm very pleased to announce that I've been made a SQL Server MVP for 2008. For the eight years or so before leaving the SQL team last August, I was involved a lot with the SQL Server MVPs. It's going to be *really* interesting being on the 'other side of the fence' in the MVP community and be part of the group providing the product feedback instead of the group receiving the product feedback!

As the MVP award is based on community participation, I have to thank all of those who read my blog posts, and those who post questions on the various forums and websites I post on - keep'em coming!

Thanks!

Tuesday, April 01, 2008 8:08:22 AM (Pacific Standard Time, UTC-08:00)  #    Comments [9]  | 
Monday, March 31, 2008

(Redmond, WA: For immediate release worldwide)

Today, in a surprise development that has stunned industry analysts, SQLskills.com announced a new technology for DBAs that will help in the never-ending battle against human-error and unforeseen disasters. The patent-pending Time-Setback technology allows DBAs of SQL Server to literally rewind time and avoid disasters before they happen.

Renowned SQL expert Kimberly Tripp said in an interview earlier today: "This will be a real boost for harried DBAs. All this time I've been going on and on and on about how DBAs should have a comprehensive backup strategy to cope with disasters. Now they can just forget all of that, throw caution to the wind, and rely on a Time-Setback device!"

Asked how the R&D department developed the technology, a spokesman for the company said "We got the idea after reading Harry Potter and The Prisoner of Azkaban, where Hermione is given a Time-Turner device from Professor Dumbledore. We figured there had to be some scientific basis for it, just like all those books that explain how Star Trek and the X-Files are based on real physics too. So, we had a crack at creating it and it worked! I'm not sure the color's quite right though. Maybe we'll change that in V2. Anyway, cool eh?"

A further disclosure, from a major software company, explained that it is in talks with SQLskills.com to purchase almost a thousand of the devices to hand out to developers to "ensure we ship this year and don't have to change the name". The spokesman wouldn't name the product when pressed.

The device will launch on April 1st, 2008, and will be available for immediate delivery. Although the company has only manufactured 4 of the devices, it will use one of them to do just-in-time manufacturing as orders stream in. For further details, please send email to: AprilFools@SQLskills.com

(Redmond, WA: For immediate release worldwide)

Monday, March 31, 2008 1:55:52 PM (Pacific Standard Time, UTC-08:00)  #    Comments [2]  | 

Fixed now - thanks so much!

Folks - a couple of people have setup their systems to refresh *all* our category feeds every five minutes - this is putting an undue load on our server (and screws up our server stats). I know I post a lot but not *that* often. I've WHOIS'd the IP addresses - one person is in Brazil and another in Korea - I can't limit how often you do this but I can ban your ISP's IP addresses if you continue to put this load on us - which I don't want to do. Please change your refresh rate to be 60 minutes or just subscribe to a whole blog feed rather than all the category feeds.

Thanks!

Monday, March 31, 2008 3:50:53 AM (Pacific Standard Time, UTC-08:00)  #    Comments [2]  | 
Tuesday, February 19, 2008

A few short notes this morning regarding the blogs and other stuff.

We had a big outage over the weekend, which rather embarrassingly manifested itself as 'out-of-disk-space' errors for anyone trying to get to any of our blogs. As you all know we preach about pro-active monitoring of data and log file space, so this didn't look good IMHO. All I can say is that it was the website and blogs log drive on the hosting company's server that filled up, not something we have control over. Needless to say, their process has been fixed so that it shouldn't happen again. Sorry about that (and thanks to all of you who dropped me mail to let me know).

Now Kimberly and I have recovered from six straight weeks of teaching, we'll be making progress on other projects. I've had a bunch of people ask where the annotated slide decks are (see this post). We've been a little busy with our teaching projects the last few months (see the previous post) but we're working on getting the first deck ready - it'll be Disaster Recovery: From Planning to Practice to Post-Mortem.

As far as products go, I've had some good feedback from some people who've bought the DDM we have available. If anyone's interested in writing a review (or has already posted one - good, bad, or ugly) please let me know. I'd also like suggestions for new features for V2 as well.

Thanks!

Tuesday, February 19, 2008 1:10:31 PM (Pacific Standard Time, UTC-08:00)  #    Comments [1]  | 
Thursday, February 14, 2008

Last year I posted on my old blog about the active SQL Server team blogs. I just happened to post on February 14th and so in every class Kimberly teaches, she makes fun of how romantic I was to post that on Valentine's Day. So what better thing to post this year than an update to that old post!

Again, this is a list of 'active' blogs, not just one-post wonders, or blogs that are inactive but have a ton of fantastic info archived on them. I've grouped them by rough area and updated the list from last year, removing some that have been inactive for many months. I've also added a list of non-SQL team blogs that I follow too. Eventually I'll put this on our blogs page too - http://www.SQLskills.com/blogs.asp.

Enjoy (and Happy Valentine's Day again Kimberly! )

General SQL Server

Compact/Express

Data Programmability

Storage Engine

Service Broker

Relational Engine

Analysis Services / Data Mining

Reporting Services

Sync Services / Replication

SSIS / DTS

Manageability / Tools

SQLskills.com Team

Select MVPs I Read

Thursday, February 14, 2008 9:58:20 AM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  | 
Thursday, February 07, 2008

After many reminders (thanks Adam Machanic!) I've added Conor and Simon to the two aggregated feeds over all the SQLskills.com blogs.

There are two feeds:

  1. SQL Server 2008 Category Posts
  2. All posts

The amount of content is really growing as Simon and Conor also seem to not sleep like me :-)

Enjoy!

Thursday, February 07, 2008 5:03:30 AM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  | 
Tuesday, January 29, 2008

This has been causing some problems on the various groups and forums over the last few days so I thought I'd repost this from my old Storage Engine blog. The questions have been around attaching 2005 databases to 2000 servers - even databases that are in 80 compat mode - and it doesn't work. Why?

The confusion is between database compatibility level and database version. Here's a quick explanation of the difference.

Database version

The database version is a number stamped in the boot page of a database that indicates the SQL Server version of the most recent SQL Server instance the database was attached to. The database version number does not equal the SQL Server version. For example, doing the following:

SELECT @@version;
GO

on one SQL Server instance on my laptop returns:

Microsoft SQL Server 2005 - 9.00.3054.00 (Intel X86)   Feb 13 2007 23:02:48   Copyright (c) 1988-2005 Microsoft Corporation  Developer Edition on Windows NT 5.1 (Build 2600: Service Pack 2)

However, the database version is 611. You can see the database version but if you attach a database from an earlier version of SQL Server, you'll see these numbers in the error log as SQL Server reports what upgrade steps its doing. You can also see by doing the following:

USE master;
GO

SELECT DatabaseProperty ('dbccpagetest', 'version');
GO

Some things to note about database version:

  • SQL Server is not up-level compatible. You cannot attach a database that was created on (or has been upgraded to) SQL Server 2005 to any earlier version of SQL Server (also true for trying to attach a 2000 database to 7.0, and so on).
  • You cannot attach a database that was created on an earlier version without going through the proper upgrade procedures. Forcibly attaching a database using various hacky methods will result in all kinds of weird errors, and possibly crashes.

Database compatibility level

The database compatibility level determines how certain database behaviors work. For instance, in 90 compatibility, you need to use the OUTER JOIN syntax to do an outer join, whereas in earlier compatibility levels, you can use '*=' and '=*'. Contrary to popular myth, all of the behavioral differences ARE documented - in the Books Online section for sp_dbcmptlevel - the SP used to set the compatibility level.

There are 5 supported compatibility levels support by SQL Server 2005:

60 = SQL Server 6.0

65 = SQL Server 6.5

70 = SQL Server 7.0

80 = SQL Server 2000

90 = SQL Server 2005

You can see the compatibility level of all databases by doing:

SELECT name AS 'DB Name', compatibility_level AS 'Compatibility Level'
FROM master.sys.databases;
GO

Some things to note about compatibility levels:

  • A database created on SQL Server 2005 will have a default compatibility level of 90, unless the model database has a different compatibility level, in which case the new database inherits the compatibility level of model.
  • New features may work under older compatibility levels but beware of SET options.
  • An upgraded database retains its compatibility level. For example, a database that was created on SQL Server 2000, and didn't have its compatibility level altered, will stay in 80 compatibility level when its upgraded to SQL Server 2005.

Summary

This was just a quick - and by no means comprehensive - explanation of the difference between the two terms. Basically, there's no relationship between them.

Tuesday, January 29, 2008 3:51:14 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  | 
Monday, January 28, 2008

A bit more traffic on the thread (see previous post here) prompted me to give my thoughts on the many sweeping generalizations that plague the computer industry and make it difficult sometimes to give advice in forums and blogs. I'd like to repost here (with a few tweaks for clarity).

Some examples of questions that breed sweeping generalizations:

  • Should you have clustered indexes on all tables? The well-known clustered-index debate as Kimberly likes to call it.
  • Should you rebuild or reorganize indexes to remove fragmentation?
  • Which high-availabilty solution should you use?

The problem - as with most advice - is that it's extremely hard to make generalizations. This is both because:

  1. without lots of evidence many people (quite rightly) don't believe sweeping generalizations as they may have been bitten by one in the past
  2. nearly every situation is different so many generalizations are useless

What I'd love to see, (and I tried to do this when at MS, and like to think I do it here or when teaching classes or conferences) is for people to provide the justification for generalizations, plus some idea of the exceptions and the circumstances under which they arise.

As for this case (whether to create multiple files because there are multiple cores/CPUs), I think we've about done this one to death. The sweeping generalizations here are:

  1. for non-tempdb you usually don't need multiple files, unless you have a very high-end workload of the specific nature I described in my first post (rare)
  2. for tempdb you usually do, as long as your workload merits it on a multi-core/cpu box
  3. IO vendors may recommend it for increased IO throughput *on their specific hardware*
  4. there exist sweeping generalizations from various sources that dispute all of the above

Unfortunately, you're not going to get a definitive, authoritative answer to a design/strategy question such as this and you'll continue to find contradictions to anything anyone says on the forums, and even MS contradicting itself (sigh).

What I would suggest is the following:
1) go with the majority opinion of responses to questions asked, based on the respondents collective experience with many customers, databases, and workloads
2) do your own testing, on your own hardware, with your own workload and see what works for you (but beware that testing in a vacuum can prove or disprove anything you want - which is why you see so many contradictory statements)

One last thing on MS - it's a very big company, with lots of groups. Anyone can sponsor a whitepaper, write a blog post/MSDN article/technet article and publish it, or reply on a forum as a visible MS person and it has the 'official stamp' of coming from MS. When I was in the product group I was continually dismayed by the misinformation, bad advice, contradictions, and baseless assertions that I saw coming from MS employees who were just trying to be helpful.

Once something's published on the internet, it's *incredibly* hard to undo the damage done. There's a fundamental element of mistrust sometimes on forums and newsgroups which can be wearying when you're trying to help people out. It can be very hard to convince people that someone else's advice isn't the best to follow - I remember several times arguing with people about how CHECKDB works or what a corruption error message means and finally having to resort to 'I wrote that code - I'm afraid you *are* wrong' - which I really hate doing.

Anyway - rant over :-)

Monday, January 28, 2008 9:35:24 PM (Pacific Standard Time, UTC-08:00)  #    Comments [5]  | 

This kind of follows on from my previous post about making sure you have character column lengths that can handle data from different countries (e.g. city names that may be longer in one country than another). A question on the forums today asked what info there is available to help in designing a global-ready database.

It turns out that there's a wealth of information right there under your nose - type in 'globalization' in the Index of Books Online. It'll get you to a section titled 'International Considerations for SQL Server' that has a link to a sub-section for every component of SQL Server! Very impressive. For instance, the one for the Database Engine has everything you need (I've made these links to the latest online BOL entries on MSDN):

Check it out and save yourself some pain when your database/application suddenly needs to support customers outside your home country.

Monday, January 28, 2008 12:33:25 AM (Pacific Standard Time, UTC-08:00)  #    Comments [2]  | 
Wednesday, January 16, 2008

Despite the fact that I was in the Storage Engine, and there's always been humorous rivalry between the Storage Engine team and the Relational Engine (a.k.a. the Query Processor) team, I did actually get along with some of the QP guys :-)

One of my good friends, Conor Cunningham, has been wanting to get back into blogging and we're extremely pleased that he's now blogging on SQLskills.com - see his new blog at http://www.SQLskills.com/blogs/conor. Before Conor left Microsoft last year to head home to Texas (the Seattle rain gets the non-natives or rain-hardened Scots eventually), he was the Development Lead of the Query Optimizer team and influenced much of the Query Processor architecture. Conor's probably forgotten more about how the Optimizer works than I'll ever know! :-)

So - I for one will be following his blog avidly.

Welcome Conor!

Wednesday, January 16, 2008 9:48:14 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  | 
Thursday, October 25, 2007

Ok - this post is a little strange and fun. I was thinking about word length and how it relates to designing software/schemas to support multiple-languages. How far do you have to go in your research to figure out the maximum string length to support? So I started digging about and found some interesting things about words. Here are some examples.

  • If you're putting together a schema to support hospital patient records, you might have a field for disease name. In that case, you'd have to allow for pnuemonoultramicroscopicsilicovolcanoconiosis which has 45 letters (caused by breathing in siliceous volcanic dust). A field for surgical procedure would have to support hepaticocholangiocholecystenterostomies which has 37 letters (creating a connection between the gall bladder and the hepatic duct). What about a field for how a measurement was obtained - electroencephalographically with 27 letters (using an electroencephalograph).
  • A schema to support chemical names could really be unlimited given the nature of systematic names for chemicals. The longest one in the dictionary is an acid called tetramethyldiaminobenzhydrylphosphinous with 39 letters (and given a few minutes I could probably draw its chemical structure by following the systematic method I learned at school :-)). The longest published chemical name is a kind of tobacco mosaic virus - ACETYLACETYL-SERYL-TYROSYL-SERYL-ISO-LEUCYL-THREONYL-SERYL-PROLYL-SERYL-GLUTAMINYL-PHENYL-ALANYL-VALYL-PHENYL-ALANYL-LEUCYL-SERYL-SERYL-VALYL-TRYPTOPHYL-ALANYL-ASPARTYL-PROLYL-ISOLEUCYL-GLUTAMYL-LEUCYL-LEUCYL-ASPARAGINYL-VALYL-CYSTEINYL-THREONYL-SERYL-SERYL-LEUCYL-GLYCYL-ASPARAGINYL-GLUTAMINYL-PHENYL-ALANYL-GLUTAMINYL-THREONYL-GLUTAMINYL-GLUTAMINYL-ALANYL-ARGINYL-THREONYL-THREONYL-GLUTAMINYL-VALYL-GLUTAMINYL-GLUTAMINYL-PHENYL-ALANYL-SERYL-GLUTAMINYL-VALYL-TRYPTOPHYL-LYSYL-PROLYL-PHENYL-ALANYL-PROLYL-GLUTAMINYL-SERYL-THREONYL-VALYL-ARGINYL-PHENYL-ALANYL-PROLYL-GLYCYL-ASPARTYL-VALYL-TYROSYL-LYSYL-VALYL-TYROSYL-ARGINYL-TYROSYL-ASPARAGINYL-ALANYL-VALYL-LEUCYL-ASPARTYL-PROLYL-LEUCYL-ISOLEUCYL-THREONYL-ALANYL-LEUCYL-LEUCYL-GLYCYL-THREONYL-PHENYL-ALANYL-ASPARTYL-THREONYL-ARGINYL-ASPARAGINYL-ARGINYL-ISOLEUCYL-ISOLEUCYL-GLUTAMYL-VALYL-GLUTAMYL-ASPARAGINYL-GLUTAMINYL-GLUTAMINYL-SERYL-PROLYL-THREONYL-THREONYL-ALANYL-GLUTAMYL-THREONYL-LEUCYL-ASPARTYL-ALANYL-THREONYL-ARGINYL-ARGINYL-VALYL-ASPARTYL-ASPARTYL-ALANYL-THREONYL-VALYL-ALANYL-ISOLEUCYL-ARGINYL-SERYL-ALANYL-ASPARAGINYL-ISOLEUCYL-ASPARAGINYL-LEUCYL-VALYL-ASPARAGINYL-GLUTAMYL-LEUCYL-VALYL-ARGINYL-GLYCYL-THREONYL-GLYCYL-LEUCYL-TYROSYL-ASPARAGINYL-GLUTAMINYL-ASPARAGINYL-THREONYL-PHENYL-ALANYL-GLUTAMYL-SERYL-METHIONYL-SERYL-GLYCYL-LEUCYL-VALYL-TRYPTOPHYL-THREONYL-SERYL-ALANYL-PROLYL-ALANYL-SERINE - with 1185 letters.
  • Probably the one that's going to catch most people out is place names. The bank Kimberly and I use won't allow a town/city name of more than 30 characters. That's fine for the USA, where the longest place name has 24 letters (Winchester-on-the-Severn in Maryland or Washington-on-the-Brazos in Texas). However, if the back-end database is coded to only support 30 characters, that wouldn't work around the world:
    • In Wales, there are two longest names are Llanfairpwllgwyngyllgogerychwyrndrobwyllllantysiliogogogoch with 58 letters and Gorsafawddachaidraigodanheddogleddolonpenrhynareurdraethceredigion wth 66 letters.
    • In New Zealand, there's a hill called Taumatawhakatangihangakoauauotamateaturipukakapikimaungahoronukupokaiwhenuakitanatahu - 85 letters and that name used to be in general use.

Pretty interesting - or as my kids like to say supercalafragalisticexpialidocious! (34 letters :-))

I'd be interested to hear of longest words in other languages apart from English - please leave a comment. Thanks

Thursday, October 25, 2007 11:38:59 AM (Pacific Standard Time, UTC-08:00)  #    Comments [6]  | 
Wednesday, October 17, 2007

Thanks for your patience and to all those who emailed to let me know. All the SQLskills.com blogs have been updated to the latest dasBlog version and everything's working again. I'd appreciate you taking the time to go back and re-enter any comments you tried to over the last few days.

Thanks!

Wednesday, October 17, 2007 4:52:22 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  | 
Thursday, October 11, 2007

It gives me great pleasure to announce two new additions to the SQLskills team - Stacia Misner and Simon Sabin. Stacia's a BI expert who will be working alongside Liz Vitt, and Simon's a developer expert who will be working alongside Bob Beauchemin. Bringing Stacia and Simon on-board really strengthens the capabilities of the SQLskills team as we now have two widely-known and respected Subject Matter Experts in each of the three areas we operate in:

  • DBA/ITPro - me and Kimberly
  • BI - Liz and Stacia
  • Developer - Bob and Simon

Their blogs are at http://www.sqlskills.com/blogs/stacia and http://sqlblogcasts.com/blogs/simons/, respectively (with a SQLskills.com-hosted blog for Simon coming soon) and their bios are below (in their own words).

Welcome!

Stacia Misner

Stacia Misner has over 23 years of experience with improving business practices through technology and has been providing consulting and education services for Microsoft’s business intelligence technologies since 2000. Prior to becoming an independent consultant, she spent nearly six years at Aspirity  (acquired by Hitachi Consulting) as a member of their Microsoft Gold-Certified Business Intelligence practice for which she developed and delivered a variety of BI courses including Microsoft’s SQL Server Accelerator for Business Intelligence, SQL Server 2005 Business Intelligence Ascend, and Business Intelligence Voyage courses.  Stacia has presented at the Professional Association for SQL Server (PASS), Microsoft’s TechEd, and SQL Server Magazine’s SQL Server 2005 roadshows. She has 8 years of experience in business intelligence architecture and implementation, data warehousing, OLAP, ETL, and reporting and analysis, as well as 15 years of experience in technical project management. Stacia is a Microsoft Certified IT Professional – Business Intelligence Developer, and a Microsoft Certified Technology Specialist – SQL Server 2005 Business Intelligence Development.

Stacia Misner is the author of:

and co-author of:

Simon Sabin

Simon runs his own database consultancy company Onarc Consulting. He specialises in SQL Server focusing on the areas of search, distributed architectures, business intelligence and application development. He has worked with SQL Server since 1998, and has always focused on high-performance, reliable systems.

Simon graduated from Nottingham University in 1996 and joined CMG as a consultant working on many varied systems over 7 years. He has spent the last 2 ½ years working for the largest Internet job board company in the UK developing a passion for search and the discoverability of data.

He was awarded MVP status by Microsoft in 2006, and is a regular speaker at SQL Server events, as well as writing for the SQL Server Central and Simple-Talk.com websites. In 2007 he co-founded SQLBits aimed at delivering SQL Server to the masses with the first free conference held in October 2007 for over 300 professionals.

Thursday, October 11, 2007 1:09:17 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  | 
Wednesday, October 10, 2007

It's not like me to post on security - that's one of Kimberly's areas - but this is an interesting example of a real-life injection attack :-)

Wednesday, October 10, 2007 9:59:48 AM (Pacific Standard Time, UTC-08:00)  #    Comments [1]  | 
Monday, October 08, 2007

Lots of people have been asking for us to create some aggregate feeds of the various blogs on the SQLskills site - well, now I've done it.

The three new feeds are:

SQLskills BI Team Blog

SQLskills SQL Server 2008 Category Aggregate Feed

SQLskills All Blogs Aggregate Feed

http://pipes.yahoo.com/pipes/pipe.run?_id=vv9PBOp13BGAc67kLO2fWQ&_render=rss. There's no FeedBurner equivalent for this feed as its larger than the maximum feed size that FeedbBurner can handle (512k).

Enjoy!

Monday, October 08, 2007 5:35:39 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  | 
Friday, August 31, 2007

Well, now I'm no longer a 'Softie'. It feels a little strange after having been on the SQL team for 8.5 years but I'm really jazzed about all the stuff we'll be doing over the next year and more here at SQLskills. We're taking a small vacation before diving in - first thing I'll be doing when I return is revamping and updating all of my content from the SQL Server Storage Engine blog and reposting the updates here. After that I'll be posting a bunch on Katmai and working through my backlog of blog topics. I can't wait to get started - stay tuned...

Cheers

[Edit: Technorati Profile]
Friday, August 31, 2007 6:33:43 PM (Pacific Standard Time, UTC-08:00)  #    Comments [5]  | 

Theme design by Jelle Druyts

Pick a theme: