In keeping with the spirit of the holiday sale season, this week I’m giving you two editorials for the same, low, low price of one. Yeah, they’re both free, but don’t look a gift horse in the mouth. I had too many ideas floating around in my head, so I decided to cheat and write mini commentaries on two topics. I hope that at least one will spark your imagination. Happy New Year!
First: Managing SQL Server 2005 and 2000 Together A reader recently asked my opinion about how to roll his own log-shipping solution for shipping SQL Server 2000 logs to SQL Server 2005. As the reader pointed out, attempting to restore transaction logs by using WITH STANDY will produce an error message. The reader asked, “Does Microsoft plan to fix this? It seems to me that if Microsoft is going to support SQL Server 2000 databases at all in SQL Server 2005, it should commit to do a complete job. If Microsoft defines supporting WITH STANDBY SQL Server 2000 restores as ‘out of scope’ for SQL Server 2005, that seems to me to be a self-serving rationalization, given the SQL Server 2000 restore functionality the company has already chosen to support in SQL Server 2005. What’s your opinion? What’s Microsoft's position?”
My opinion is that I wish Microsoft had provided this support. I don’t know Microsoft’s official position, but I’m going to use this question as a way to pivot to the real point of this mini-editorial. I’d like to publish a list of the most annoying integration problems that SQL Server customers are facing when trying to manage a consolidated environment of both SQL Server 2005 and 2000 instances. So bring it on. Share your secrets. What’s your toughest management challenge? Send your responses to me at [email protected], and I’ll compile and publish the most helpful list of gotchas in an upcoming editorial.
Second: Benefits of the Security Development Lifecycle Several weeks ago I wrote about SQL Server security and mentioned the great strides that Microsoft has made. I also referred to the independent study “Microsoft SQL Server Runs the Security Table,” written by the Enterprise Strategy Group, which points out how favorably Microsoft compares to other players in the database space with respect to security vulnerabilities. (You can read the report at http://www.microsoft.com/presspass/itanalyst/docs/ESGNov2006SQLServerSecurity.pdf .)
This week, I want to encourage you to read another paper about this same topic. In “Which Database is More Secure? Oracle vs. Microsoft,” (at http://www.databasesecurity.com/dbsec/comparison.pdf ), author David Litchfield of NGSSoftware concludes that SQL Server is fundamentally more secure at this time than Oracle. Litchfield also seems to suggest that much of the difference is because of Microsoft’s adoption of its Security Development Lifecycle (SDL). I mentioned the SDL in passing when I explored this topic several weeks ago. Among other efforts, Microsoft’s SDL represents the company’s commitment to ensure that security is “baked in” to all its products from the earliest design stages. Sure, Microsoft has had a number of black eyes over the years in the security space. But the SDL has allowed the company to make much progress. Read Litchfield’s white paper. I think you’ll find it interesting.