Distinguished engineer Peter Spiro, leader of Microsoft's core SQL Server engine team and an 8-year veteran of the database group, talks with SQL Server MVP Brian Moran about stomping bugs, expanding programmability, adding function, and simplifying administration on the way to a better, faster, stronger data-management platform.
Brian Moran: The next version of SQL Server—code-named Yukon—and other Microsoft products have been delayed because of comprehensive debugging and security-checking activities that froze development companywide for several months earlier this year. What did you learn from this exercise that will help you ensure the quality and security of the Yukon release and any service packs, SQLXML releases, and so on that the company rolls out in the meantime?
Peter Spiro: The full SQL Server team—developers, testers, program managers, and management—spent 3 months working on security, and only security. We identified different pieces of code and how vulnerable they might be, and we went line by line through the entire code base with teams of developers. Even though we were looking for security, we also found places where the code wasn't as efficient as it could be, little nits here and there. So we did a lot of code cleanup beyond the security check, improving the quality as well as the security of the product.
In the process, we also developed some interesting tools, which we plan to reuse in the development of future versions, that automate the checking of buffer overruns and other types of coding errors that might create vulnerabilities. Security vulnerabilities often occur because different people are working on different sections of the code and have different assumptions about what's being checked or passed in. Some of our new tools validate those assumptions from the top of the stack to the bottom, automating more internal checks. As we improved the security that was already in place, we also identified some security features that need to be added in different parts of the product. We went beyond cleanup to a whole new mind-set about security and quality.
BM: Liberty, the 64-bit version of SQL Server that's in beta testing right now and that's due out this fall, has been generating a lot of buzz. Some people think a 64-bit database is automagically going to solve all their performance problems, but that isn't the case for many customers. What customers are going to see the most benefit from 64-bit?
PS: You're exactly right, Liberty isn't a panacea for all performance problems. Generally, applications that benefit from more memory will do better on the 64-bit machines. We did some interesting things in SQL Server that are going to make it perform nicely on 64-bit machines. Most databases' internal components use a lot of memory. Generally, they use the memory in different ways. So, for example, a procedure cache might use memory to roll back transactions. If you're doing hash joins, you need memory. The log manager needs memory, the buffer pool needs memory, and so on. Most subsystems have their own algorithms and data structures that use memory and, in fact, compete with each other because they've evolved over time. So, one thing we did in SQL Server 7.0 was put a lot of thought into integrated memory management and usage. Rather than have competing subsystems, we built a system where all the different subsystems that use memory cooperate with each other. We have one mechanism in the buffer pool that controls all the memory. We have different policies for different memory spaces and hand out memory on the fly.
We put a lot of work into this integrated memory model, and when you go to large amounts of memory, this architecture will pay off even more. The buffer pool's going to get a huge amount of memory with 64-bit, but we don't have to change data structures. We just need a few query processor algorithms or procedure cache algorithms because the subsystems have already hooked in and integrated with each other. Beyond just getting a bigger buffer pool with 64-bit, which is what a large system will give you, applications will get a kind of multiplicative performance win by having all the different subsystems using this larger memory space without having to change their algorithms.
BM: So this subsystem work has enabled you to make SQL Server more self-tuning—capable of monitoring current system behavior and of responding appropriately?
PS: Absolutely. In fact, as we designed SQL Server 7.0, we drew on 20 years of research and knowledge. And when we finally re-implemented a lot of the core server internals, we took best-of-breed thought from previous products and previous research—particularly about integrated memory management—to make SQL Server 7.0 extremely easy to use and self-managing. This architecture gives SQL Server cleaner internals for using memory, and lets you monitor different behaviors without having to tweak a bunch of knobs to manage the subsystems' different memory branches.
Also remember that as we built SQL Server 7.0, we knew 64-bit was coming. So we designed a lot of the data systems, data structures, and algorithms—for example, the buffer pool and the hashing tables—with 64-bit in mind. To prepare most products to run on 64-bit hardware, you'd normally need lots of people sifting through the entire product, changing data structures and algorithms. We assigned just a couple of people to prepare for 64-bit because we did all the work up front to make sure both the data structures and the algorithms were able to handle large amounts of memory. What we've had to concentrate on as we use more CPUs is eliminating the bottlenecks. If you have plenty of CPUs and memory, you have plenty of processing power. You just have to watch for internal synchronization points.
Prev. page
[1]
2
3
next page 
