BM: Although SQL Server does a great job of responding to the environment and tuning itself, a lot of professional DBAs still think SQL Server is unsophisticated and less tunable than other database management systems (DBMSs) because it doesn't have all those knobs to tweak. What's your response to such criticisms?
PS: I've been working with databases for almost 20 years, and as we built these engines in the mid-'80s, we added functionality and added more knobs so that we could tune that functionality for more efficient performance. In the process, we developed products that could solve any problem, but only half a dozen people in the world could tune the system so that it operated correctly and efficiently. When I came to Microsoft, we made a big push early on to rebuild algorithms and data structures to make the system more self-tuning. If we needed to build a log manager, we asked how much memory we needed to enter transactions and what we needed to do as we grouped log records to write them to the log. We knew all the steps that we skipped in previous systems, and instead of saying, "We'll set this parameter, and we'll set that parameter," we incorporated the 10 to 15 years of experience into taking care of, say, 80 percent of the tuning right off the bat.
BM: Even if you get perfect ability to tune the knobs exactly, if the workload changes, your tuning work is suddenly obsolete. For TPC-C benchmark tests, for example, many elements are static, but these elements aren't static in the real world.
PS: Exactly. The dot-com whirlwind forced people to get their solutions to market immediately. The industry pressed companies to get these systems online before they fully knew the type or volume of transactions they'd see or how many users they'd have to support. The system could be—and often was—completely different six months down the line. Even as we look at some of Microsoft's own internal business applications, such as accounting, the load changes from morning to night. So, you can add enough memory so that you can manage the three to four different workloads during peak system usage, but that memory will be wasted at night. You could probably get a few percentage points improvement if you wanted, but you'd have to pay a lot for extra hardware, consulting, and so on. And you'd need to be tweaking the system in the morning, at midday, and at night. We don't think customers want to play that game. With SQL Server, they can save a lot of money and still solve their business problems and meet their business needs.
BM: Using distributed partitioned views, Microsoft has posted fantastic TPC-C benchmark scores on scale-out hardware. But customers find distributed partitioned views difficult to manage, and performance can be a problem. What are Microsoft's plans for helping customers manage scale-out implementations?
PS: At the beginning of development for Yukon, we had to set our priorities. We looked at what our customers were doing, how they were solving their business problems, and decided to focus on programmability and scale-up solutions rather than on the scale-out architecture. We also looked at the hardware coming down the line, which was going to make scaling up more feasible and attractive to customers. With today's hardware, you don't see many applications that can't effectively run on an 8-way system. And if you look further out, when Yukon will be available (the beta is slated for the first half of 2003), we're looking at 64-bit machines and 64-way machines. So, we just couldn't see much demand for scale-out and clustering solutions.
That said, not pursuing advances in distributed partitioned views and clustering was a difficult choice for us because lots of people in my group, including myself, have strong clustering backgrounds. And we recognize that distributed partitioned views are difficult for customers to use. Ease of use is what Microsoft is about. So if we're going to pursue clusters—and we definitely have that goal for the future—we want to do it right. We'll guarantee and automate the moving of data from one machine to another when one cluster node becomes overcrowded or when the response time becomes poor. Until then, distributed partitioned views are a stopgap measure for people who are using multiple machines.
BM: Adding the .NET Common Language Runtime (CLR) to the SQL Server engine in the Yukon release will add tremendous value and programmability to the database. But I fear it will also allow talented developers who don't necessarily understand database-centric issues to write inefficient code. Today, if a Visual Basic (VB) or C++ developer writes code or a stored procedure that's not very efficient, a DBA can fix the problem because they can read the language. How will DBAs be able to debug, troubleshoot, and performance-tune inefficient procedural code written in languages they aren't familiar with?
PS: Microsoft is going to provide great tool support for logging stored procedures and so on. We'll also have white papers and other documentation that can help identify possible problem areas and shorten the learning curve. DBAs are going to have a learning curve for a couple of years, which is a natural outcome of making the database more accessible to more people who don't have 20 years of experience writing database applications.
BM: SQL Server Profiler is my best friend when I'm tuning, letting me see what's happening at the engine level and identify exactly what's consuming the most resources. In Yukon, are we going to see an enhanced Profiler that can monitor very low-level activity that's happening in a non-T-SQL language, or will Profiler remain mostly limited to monitoring server classes for T-SQL?
Prev. page
1
[2]
3
next page 
