SQL Server Magazine

Editor's Note: Contributing editor and SQL Server Most Valuable Professional (MVP) Brian Moran talked recently with Paul Flessner, Microsoft's vice president of SQL Server and middleware, about the evolution of SQL Server and its role in corporate IT environments. Flessner will be the keynote speaker at PASS 2000 North America Conference and Expo October 25 through 28 in San Francisco (for more information, visit the PASS Web site at http://sqlpass.org). Following is an excerpt from the interview. You can read the entire interview at www.sqlmag.com, InstantDoc ID 8993.

Brian Moran: Paul, we'd like to help readers understand the evolution path that SQL Server 2000 is on and the types of changes we might see in the Yukon [the code name for the post-2000 SQL Server release] time frame. We also want to drill down into interoperability features of all versions of SQL Server.

Paul Flessner: We can talk about SQL Server 2000 design points and what we're trying to accomplish, which will lead us into a good discussion about futures. We wanted to accomplish a couple of things in SQL Server 2000. The feedback about SQL Server 7.0 was pretty clear. A lot of customers said they really liked the feature set and thought it was competitive. They said, "You don't have every feature that the competitors do, but you have a good feature set to cover the key areas of the market, including OLTP [online transaction processing] and decision support." We're starting to work in the area of knowledge management with our full-text search feature, among others. We got very positive feedback about the upgrade experience, backward compatibility, and just the overall quality. I was talking with a customer the other day about upgrading to SQL Server 2000, and he said, "Well, you've got a high bar because on a 1 to 10 scale in terms of quality, SQL Server 7.0 is a 12." So we knew that we'd done a good job, but in some areas, customers were pushing us to keep going forward.

We also concentrated on providing more Internet support in SQL Server 2000. The Internet exploded while we built SQL Server 7.0. We started writing code for 7.0 in mid-1995, then shipped it at the very end of 1998. So we had to get some Internet features in pretty quickly. Everybody loves what we're doing in data warehousing, but they want more out-of-the-box ease of integration. Customers also told us that they felt we're listening to them. We're running 5 to 10 customers through our development shop each week now, and we sit and listen to them.

Moran: I recognize that you're soliciting great feedback from the customers you bring in and you're engineering the product to meet those needs. But I think that the common SQL Server user often feels that Microsoft is off doing its own thing and that a clear feedback channel to Microsoft's corporate level isn't available.

Flessner: We can always do more. We do provide some forums; MSDN [Microsoft Developer Network] is the biggest. You do have to subscribe to MSDN at some cost, but I don't believe the cost is prohibitive for any professional database developer or administrator. That's our broad-reach model, and you can ask questions and get answers in that forum. Having said that, maybe I need to get more feedback on our reach.

Moran: Talk about scalability for a moment. Obviously, the TPC [Transaction Performance Processing Council] numbers shook everything up. I think the results took Oracle by surprise. Now Oracle's response is that scale-out partitioning is nice, but the Microsoft solution isn't really practical for many needs today because of the way in which you need to implement the partitioning. And, of course, Oracle claims its product can still scale up much higher in a single SMP box. So, when might we see TPC-C scores based on a 64GB Windows 2000 Datacenter Server running 32 nodes or 32 CPUs? [For more information about SQL Server's TPC results, see Michael Otey, Editorial, "SQL Server Is Tops," June 2000].

Flessner: I want to back up to a higher level. There are two fundamental ways for a database to scale and two fundamental design points in the product's architecture. One is a shared-everything type of architecture, or a scale-up strategy. Those scenarios are the ones in which you see the big 32-way, 64-way, and 96-way SMP numbers that Oracle and Sun like to talk about. The shared-everything model is great for many—and even most—applications. But in terms of scalability, this model is restrictive. I can't quote specific numbers that show where throughput falls off as it relates to processors because the model is absolutely workload-dependent. But [the throughput fall-off] isn't the hardware's fault, and it's not the operating system's fault. The definition of the database architecture causes the scalability limitations in the shared-everything model. [For more information about shared-everything and shared-nothing architectures, see Michael Otey, Editorial, "Scaling Up vs. Scaling Out," July 2000.]

Let me give you an example. You hear a lot about parallelism in a database. We have parallel operations such as create index, query, scan, sort, and a parallel read operation for the inserts and updates. What we don't talk about is serial I/O, serial log access, and serial buffer management. Every time you finish one of those parallel operations, you go back to a serialized operation. The more processors you have, the faster they queue up and wait for one of those serialized operations.

So it's a fact of life that SMP scaling—hardware scaling—doesn't scale. Every application hits a knee in the curve, and then it just flattens out. All you're doing at that point is paying a lot of money to Sun and Oracle, and they're happy to take it. They're so happy to take it that they do anything they can to disparage our model of economics, both at the SMP level and the scale-out strategy, which is the second part of the discussion.

The shared-nothing or scale-out strategy is a proven model in the dot-com world and in the ISV [independent software vendor] world. Look at SAP's scale-out strategy. The middle tier is the common model. You do your connection management and business logic at the middle tier, and you don't have to worry about the state of the data; that's managed at the back end. But if you need more connections or you need more throughput, you just add an application server. The economics of that have been proven over and over. We're advocating a proven model that has been around for 20 years.

Moran: The limitation today with this model is the manageability of the scale-out partition. Also, certain types of applications might lend themselves to the partitioning model, but other applications might not. In other words, federated databases in SQL Server 2000 aren't a catch-all solution for every problem.

Flessner: I've made it clear in my talks, even at the Windows 2000 launch, that this solution is a down payment on our scale-out strategy. What you get is transparency in query updates. You don't get transparency for manageability. So, I'm not overselling [the scale-out strategy]; it's not for all customers. It's for a very select, high-end set of customers that absolutely demand this level of scalability.

   Prev. page   [1] 2     next page