Database Reference
In-Depth Information
is not available within the database buffer pool, it must make a request to the storage
array for the needed information.
The storage array looks within its cache to see if the data needed is available to it. It
also uses proprietary algorithms to keep the storage array data cache populated with the
information you are most likely to need. Notice how memory is being used once again to
boost performance by helping to minimize I/O. When the storage array cannot resolve
the request, it then makes a request to retrieve the information from the physical drives.
Newer storage arrays, such as the EMC VMAX, IBM V7000, and NetApp FAS6200,
would look within the SSD drives. (I am using flash and SSD interchangeably for
purposes of this example.) According to Wikipedia ( http://en.wikipedia.org/wiki/Solid-
state_drive ), a solid-state drive (SSD) “is a data storage device using integrated circuit
assemblies as memory to store data persistently.” As mentioned previously, solid-state
storage should be thought of as cheap memory rather than expensive disks.
As you can see from the definition at Wikipedia, SSD drives are just another form of
memory cache. The storage array uses additional proprietary algorithms to keep the
SSD drives populated with the information you are most likely to need. When the SSD
drives cannot resolve the request, they then look to the SATA/SCSI drives for the data.
Depending on the storage array, it might contain SATA drives or SCSI drives. Blending
SSD drives with SATA or SCSI drives together gives you better performance at a much
more reasonable cost.
As this example illustrates, the trend within storage arrays is to minimize the amount of
physical I/O that might be needed by leveraging memory. Any time you have memory-to-
memory access happening, your database will perform faster.
Database Indexes
Another powerful tool we use to speed up a database's performance is the strategic
placement of indexes. Indexes can greatly reduce the amount of physical I/O needed to
retrieve the necessary data to resolve a query. This is an overly simplified way of
explaining how a database retrieves data, but it illustrates the point I am trying to make.
When a database retrieves data, it can do so in one of two ways. The database performs
a full table scan or an index seek. A full table scan is the equivalent of starting at the
beginning of a book and reading every page of the topic until the very end. An index
read is the equivalent of using the index in the topic and jumping right to the page you
need. The index has the effect of greatly minimizing the amount of I/O the database has
to perform. Unlike a book index, which points you to the page you need to go look up, a
database index can sometimes provide all the data that is needed to resolve a query
without going out to the actual source table itself for the data. We will provide an
example of how an index works in the next section of this chapter.
 
Search WWH ::




Custom Search