| Executive Summary: SQL Server Magazine contributing editor Brian Moran believes cloud computing is coming to Microsoft SQL Server environments; the question is how soon will DBAs need to adapt to using and managing database services in the cloud instead of onsite in their organizations and data centers. Join in reader discussions about SQL Server and cloud computing and how SQL Server developers can improve performance of the database applications they design and write. |
SQL Server in the Cloud
If you’ve been keeping up with technology news, you’ve surely heard of cloud computing. The “cloud” encompasses computing services—applications, processing, storage, data protection, to name a few—hosted by offsite third-party providers. The upside of cloud computing: 24 × 7 access to applications and data without the overhead of an onsite IT team to maintain them. The downside: potential loss of control of your organization’s data. SQL Server Magazine contributing editor Brian Moran recently pondered whether we’ll eventually see SQL Server applications and data in the cloud (see “Cloud Computing: How Will It Affect Corporate IT?,” InstantDoc ID 99835).
With SQL Server Data Services (SSDS) now in beta, the question makes sense. SSDS is Microsoft’s first attempt to offer on-demand, online data storage and querying services. (For more information, see “SQL Server Data Services,” June 2008, InstantDoc ID 98881 and the Microsoft SQL Server Data Services web page at www.microsoft.com/sql/dataservices/default.mspx.) Although SSDS actually runs on Microsoft’s SQL Server systems, for end users, it isn’t really SQL Server—rather, it’s just a means to store data and access it through querying.
In a cloud-based world where the data service, not the database platform, is king, what becomes of the DBA? Brian’s answer: “It’s reasonable to assume that cloud-based IT services will require fewer professionals to keep them up and running…, \[and\] cloud-based IT services lend themselves to be hosted from locations in which the cost of labor is substantially less than ‘big city,’ white-collar IT salaries.” Reader comments on the article generally agree with Brian’s conclusion, although shawnwjohnson thinks that businesses will choose to keep control of sensitive business and personal data while ceding control of nonsensitive data and applications to the cloud. What do you think? Is it only a matter of time before your company moves its applications and data into the cloud? And if that happens, what career steps will you take to prepare for the shift to cloud computing?
Performance Debate
DBAs aren’t the only SQL Server pros concerned about database performance; SQL Server developers also need to keep application performance in mind as they write database programs. Michael Campbell covered this angle in his article, “Performance Secrets for SQL Server Developers” (July 2008, InstantDoc ID 99148) and got thoughtful feedback from several readers.
Kurt Survance liked the article’s tips overall but disagreed with Michael’s recommendations about configuring Address Windowing Extensions (AWE) memory usage. “As I understand it…, AWE is irrelevant unless a machine has more \[than\] 4GB of RAM, not 2GB as implied here…. I know that there is a lot of disinformation, partial information, and outright wrong information on this topic. Most of it springs from a confusion between physical memory and virtual address space…. I have configured AWE on many systems, and it worked fine. I… never tried enabling AWE on a system with less than 4GB because there seemed to be no point, since any 32-bit process can access 4GB of RAM without AWE.”
Reader Garry Mortimer disputed Michael’s tip about improving performance by using multiple data files, referring to a Microsoft PSS SQL Support blog post stating that the more-data-files-equals-better-I/O-performance meme is an “urban legend” (see blogs.msdn.com/psssql/archive/2007/02/21/sql-server-urban-legends-discussed.aspx). “I’m not sure if your article specifically \[recommends creating\] 0.25 to 1 data file per file group per processor (point 9). If yes, I don’t think I would agree with it as I feel this recommendation is only contained to tempdb…. Most people have this misconception of a worker allocated per data file in SQL. Actually, this one worker per data file is… when you create \[a\] database \[on a\] different drive. Hence, workers do the creation so the database may be created faster due to parallel work streams.” We passed along Garry’s comment to Michael; check the article comments to see how Michael responded.
