Beta-Testing Service Packs Is a Tough Job
I just read Brian Moran's interview with Microsoft Vice President of SQL Server Gordon Mangione ("Securing SQL Server," May 2003, InstantDoc ID 38537) and wanted to share another reason why SQL Server support staffs don't immediately apply service packs. Just because a service pack is available doesn't mean that it's completely tested and error free for your systems. We applied SQL Server 2000 Service Pack 3 (SP3) on a server last week, for example, and immediately found that applications that used to run in 2 minutes were taking more than 55 minutes to complete. We ran and reran sp_updatestats and didn't find any improvement. Then we ran UPDATE STATISTICS table with FULLSCAN (supposedly a solution if sp_updatestats doesn't help) and again found no improvement. After studying all other possible causes, including memory settings, I finally uninstalled SQL Server 2000 SP3 (an uninstall function sure would have been nice), then reinstalled SQL Server 2000 SP2. The problem immediately went away, and we had our 2-minute response time back. You might argue that we could have tuned our applications and added indexes to solve the performance problem under SP3. Probably true. However, when I upgrade my server to the new and improved service pack, I shouldn't have to retune the performance of software that's installed at more than 100 customer sites. You can see why a DBA might be reluctant to install new service packs when they're first available. Beta-testing service packs isn't a cost-efficient endeavor.
—Ted Henderson
thenderson555@aol.com
Authentication Mode Isn't Up to Customer
Microsoft's ongoing emphasis on not using mixed-mode authentication is frustrating. If that's the company's recommended best practice, as Microsoft Vice President of SQL Server Gordon Mangione said in "Securing SQL Server" (May 2003, InstantDoc ID 38537), then it needs to do a better job of motivating third-party software vendors to support Windows authentication. A lot of third-party vendors don't currently support Windows authentication, and when you ask them when they'll add such support, your question is met with silence. We have no discretion in choosing our authentication mode—our third-party vendors make that decision for us.
—Kay Conheady
kconheady@birdseyefoods.com
Using 32-Bit Tools to Migrate to 64-Bit
In Michael Otey's April 2003 article "The 64-Bit Question" (InstantDoc ID 37779), he says, "Alternatively, you can migrate by using the Copy Database Wizard, which besides moving the database, copies your database logins to the new master database." I believe that the 64-bit SQL Server Data Transformation Services (DTS) components aren't compatible with the 32-bit components, so the Copy Database Wizard won't work.
—Gaurav Bindlish
gaurav_bindlish@mumbai.tcs.co.in
You can use the 32-bit Copy Database Wizard and DTS components to access and copy data from the 32-bit versions of SQL Server to the 64-bit version. You can also use all your current 32-bit database-access components and applications to connect to the 64-bit version of SQL Server. However, because the on-disk formats are the same, you'd probably want to simply detach, then reattach any databases that you want to migrate.
—Michael Otey
Prev. page
[1]
2
next page 
