Yukon comes in out of the cold

10.11.2005
To many of us, it's like Election Day. After months of those agonizingly annoying and patronizing election smear ads, the big day is finally here, and I can look forward to watching a football game without the mention of Corzine or Forrester. Too bad that's not the day I'm talking about. I'm talking about SQL Server 2005 Day.

Months and months of early beta, middle beta, medium-rare beta, gold well done, RTM, release candidate, and whatever other iterations have finally culminated into a fully baked database dish: SQL Server 2005, which Contributing Editor Sean McCown recently had a chance to try out. If you've got a previous incarnation, then upgrading is pretty much mandatory. Not only is SQL05 -- previously code-named Yukon -- a better database; Microsoft will nag and pummel you until you upgrade anyway, so it's best to do so on your own terms and schedule.

For those using some other SQL database, however, the question is more difficult: To jump to Microsoft or not? SQL05 makes switching difficult to resist. Man oh man, does it ever pack the sleek and curvaceous features. Scalability and performance alone make the leap worth a look. Redmond has gone to significant trouble to architect the new platform for truly large enterprise deployments -- and, yeah, "truly large" does mean several instances and advanced technologies such as clustering and HPC (high-performance computing). But at least those capabilities are there, newly refined and tested. And eventually, you'll find fail-over clustering and database mirroring. Those were supposed to be in the first release; Redmond now estimates they'll be added "soon."

Performance, too, is beefed up, and not only because this is a fully 64-bit-aware application. You'll also find support for intelligent partitioning, although the "intelligent" part really seems to mean how smart the DBA is. And, yes, everyone's favorite whipping boy, security, has been tended to as well. New support for advanced encryption, crypto-key management, and more advanced administration are all here and happy.

And last but definitely not least, SQL's programmability has been -- well, let's say changed. T-SQL (Transactional SQL) has been upgraded, but far more ominous is a new and much, much deeper integration capability with .Net. This is partially to expand the applicability of SQL Server in the market but also because SQL Server forms much of the backdrop for the slew of advanced Vista ventures Microsoft announced at the Microsoft Professional Developers Conference earlier this year. WWF (Windows Workflow Foundation), WCF (Windows Communication Foundation), and WPF (Windows Presentation Foundation) can all function independently of one another, but when they've been implemented in a project, SQL Server is at least a recommended choice for back-end data repositories and in many instances, a requirement.

That's required Microsoft to tack a whole slew of SQL Server hooks into Visual Studio 2005, which also saw the light of day last week. No, you don't technically need to use VS 2005 to manage or programmatically access SQL Server 2005, but if you're in an MS-oriented dev project, you'd be nuts not to.

Usually, that doesn't matter much to us sys administrators. We're managing the servers and network; let the programmers worry about their tools. But Visual Studio has gotten serious dings for a slew of beta bugs that Microsoft simply closed out and never fixed in order to get the product out the door. All this information is off blog fodder, so take it with a grain of salt, but enough fodder got fed to get me worried, especially given that a big part of the new VS is to sell you integrated Team Foundation services: Bugs can conveniently affect everyone instead of inefficiently plaguing only one programmer at a time.

If your programmers are embarking on platform upgrades that include SQL Server 2005 and Visual Studio 2005, then you'd best read up on these platforms' architectures and administration capabilities. (Both products have a good selection of articles on their respective Web sites, but for immediate help, get familiar with their support forums.) Then make sure you've got a fast and automatic backup running -- and running often. Nothing's worse than a frustrated support call from an overcaffeinated programmer who thinks he or she has just lost six or seven hours' worth of work.