Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

9
SQL Ser ver Storage and
Index Str uctures
Indexes are a critical part of your database planning and system maintenance. They provide SQL
Server (and any other database system for that matter) with additional ways to look up data and
take shortcuts to that data’s physical location. Adding the right index can cut huge percentages of
time off your query executions. Unfortunately, too many poorly planned indexes can actually increase
the time it takes for your query to run. Indeed, indexes tend to be one of the most misunderstood
objects that SQL Server offers, and therefore, they also tend to be one of the most mismanaged.
We will be studying indexes rather closely in this chapter from both a developer’s and an administrator’s
point of view, but in order to understand indexes, you also need to understand how data
is stored in SQL Server. For that reason, we will also take a look at SQL Server’s data-storage
mechanism.
SQL Ser ver Storage
Data in SQL Server can be thought of as existing in something of a hierarchy of structures. The
hierarchy is pretty simple. Some of the objects within the hierarchy are things that you will deal
with directly, and will therefore understand easily. A few others exist under the covers, and while
they can be directly addressed in some cases, they usually are not. Let’s take a look at them one by one.
The Database
OK — this one is easy. I can just hear people out there saying, “Duh! I knew that.” Yes, you probably
did, but I point it out as a unique entity here because it is the highest level of storage (for a given
server). This is also the highest level at which a lock can be established, although you cannot explicitly
create a database-level lock.
A lock is something of a hold and a place marker that is used by the system. As you do development
using SQL Server — or any other database for that matter — you will find that understanding
and managing locks is absolutely critical to your system.