Databases Reference
In-Depth Information
ancing act to manage this information into a single condensed chapter. If you were hop-
ing to read this chapter and become a guru in systems design issues for database servers,
you will probably be disappointed. What we do hope, however, is that this chapter will
present a summary review of the major systems issues, after which you'll feel comfort-
able to follow what the gurus constantly rave about.
In essence there is a core set of systems attributes that database designers need to
understand:
•
Performance modeling for CPU processing power
•
CPU architecture basics
•
Client server architectures
•
Multiprocessors and nonuniform memory access (NUMA)
•
Balancing resources correctly for database servers
•
Operating system choices
•
Storage area networks (SANs) and network attached storage (NAS)
•
Storage reliability and availability using a reliable array of inexpensive disks
(RAID)
•
Database availability strategies, such as Real Application Clusters (RAC) and
High Availability Disaster Recovery (HADR)
•
Database memory management
Through the remainder of this chapter we will discuss each of these with the goal of
providing the reader with a little more than conversational understanding of each.
13.1
What You Need to Know about CPU Architecture
and Trends
13.1.1 CPU Performance
The most widely known measure of CPU performance is the CPU clock rate. CPUs
operate by performing instructions. Each instruction requires some number of clock
cycles to execute. Clock speed is generally measured today in giga-Hertz (GHz) or bil-
lions of cycles per second. The faster the clock cycles the faster the CPU can perform
instructions. At least that's the crude theory. In practice the analysis is weak but still pro-
vides a rough guideline.
For a given CPU architecture, it is indeed possible to compare CPUs according to
their clock rates. However, across different CPU architectures the same instruction
(such as ADD) may require more instructions on one chip than another. As a result, a
CPU with a slower clock rate may actually process faster because it requires fewer clock
