| |
 |
|
Oracle Tips by Burleson |
Finding the source of bandwidth bottlenecks
The first step in applying SSD to RAC is to locate the root cause of
the I/O contention. The most common cause of I/O bandwidth
saturation in Oracle RAC is a poorly performing I/O subsystem.
However, more detailed exploration is warranted to see what specific
data files contribute to the saturation of the storage. The source
of Oracle I/O saturation may be due to one of these causes:
- Non-database processes read from the same device as Oracle
data files
- Another database sharing the same file systems (Oracle RAC)
- A poorly tuned I/O subsystem (e.g. RAID5 for high-update
data files).
There are two approaches to I/O monitoring Oracle RAC for disk
bandwidth bottlenecks:
Monitor enqueues at the disk level – Use OS tools, such as iostat of
vendor-based disk monitors
Monitor at the Oracle instance level – Use an AWR or STATSPACK
report to monitor buffer busy waits and high access times for each
instance.
As a review, the hallmark feature of RAC is the ability for many
Oracle instances to simultaneously read the Oracle files. This
complicates the process of locating high concurrent access data
files because the file I/O on each of the RAC instances must be
interrogated.
Because Oracle file I/O is measured at the instance level, finding
bandwidth bottlenecks may mean reading AWR reports on dozens of RAC
nodes. To simplify the process of identification, most Oracle
professionals will measure I/O at the disk level using native I/O
monitors such as SAR and iostat. They would then look for disk
enqueues, a condition where read/write requests are waiting for
access to the disk.
In the example below, a SAR command was issued to locate the disk
enqueues:
root > sar –d –f /var/adm/sa/sa16
In the SAR output, review the avque column seeking high device
backlogs:
SunOS prod1 5.6 Generic_105181-23 sun4u 05/16/01
01:00:00 device %busy avque r+w/s blks/s avwait avserv
sd22 100 72.4 2100 2971 0.0 87.0
sd23 0 0.0 0 0 0.0 0.0
sd24 0 0.0 0 0 0.0 0.0
sd25 100 72.4 2100 2971 0.0 87.0
Because of the transient nature of disk enqueues, many Oracle
professionals also use disk vendor specific time-series tools (e.g.
the EMC Symmetrics console) to track disk enqueues over time.
The above book excerpt is from:
Oracle RAC
& Grid Tuning with Solid State Disk
Expert Secrets for High Performance Clustered Grid Computing
ISBN:
0-9761573-5-7
Mike Ault, Donald K. Burleson
http://www.rampant-books.com/book_2005_2_rac_ssd_tuning.htm
Market Survey of SSD vendors for
Oracle:
There are many vendors who offer rack-mount solid-state disk that
work with Oracle databases, and the competitive market ensures that
product offerings will continuously improve while prices fall.
SearchStorage notes that SSD is will soon replace platter disks and that
hundreds of SSD vendors may enter the market:
"The number of vendors in this category could rise to several
hundred in the next 3 years as enterprise users become more familiar
with the benefits of this type of storage."
As of June 2008, many of the major hardware vendors (including Sun and
EMC) are replacing slow disks with RAM-based disks, and
Sun announced that all
of their large servers will offer SSD.
As of June 2008, here are the major SSD vendors for Oracle databases
(vendors are listed alphabetically):
2008 rack mount SSD Performance Statistics
SearchStorage has done a comprehensive survey of rack mount SSD
vendors, and lists these SSD rack mount vendors, with this showing the
fastest rack-mount SSD devices (as of May 15, 2008):
| manufacturer |
model |
technology |
interface |
performance metrics and notes |
|
Texas Memory Systems |
RamSan-400 |
RAM SSD |
Fibre
Channel
InfiniBand
|
3,000MB/s random
sustained external throughput, 400,000 random IOPS |
|
Violin Memory |
Violin 1010 |
RAM SSD
|
PCIe
|
1,400MB/s read,
1,00MB/s write with ×4 PCIe, 3 microseconds latency |
|
Solid Access Technologies |
USSD 200FC |
RAM SSD |
Fibre Channel
SAS
SCSI
|
391MB/s random
sustained read or write per port (full duplex is 719MB/s), with
8 x 4Gbps FC ports aggregated throughput is approx 2,000MB/s,
320,000 IOPS |
|
Curtis |
HyperXCLR R1000 |
RAM SSD |
Fibre Channel
|
197MB/s sustained
R/W transfer rate, 35,000 IOPS |
Choosing the right SSD for Oracle
When evaluating SSD for Oracle databases you need
to consider performance (throughput and response time), reliability (Mean Time Between failures) and
TCO (total cost of ownership). Most SSD vendors will provide a
test RAM disk array for benchmark testing so that you can choose the
vendor who offers the best price/performance ratio.
Burleson Consulting does not partner with any SSD vendors and we
provide independent advice in this constantly-changing market. BC
was one of the earliest adopters of SSD for Oracle and we have been
deploying SSD on Oracle database since 2005 and we have experienced SSD
experts to help any Oracle shop evaluate whether SSD
is right for your application. BC experts can also help you choose
the SSD that is best for your database. Just
call 800-766-1884 or e-mail.:
 for
SSD support details. DRAM SSD
vs. Flash SSD
With all
the talk about the Oracle “flash cache”, it is important to note that there
are two types of SSD, and only DRAM SSD is suitable for Oracle database
storage. The flash type SSD suffers from serious shortcomings, namely
a degradation of access speed over time. At first, Flash SSD is 5
times faster than a platter disk, but after some usage the average read time
becomes far slower than a hard drive. For Oracle, only rack-mounted
DRAM SSD is acceptable for good performance:
|
|
Avg. Read speed
|
Avg. write speed
|
|
Platter disk
|
10.0 ms.
|
7.0 ms.
|
|
DRAM SSD
|
0.4 ms.
|
0.4 ms.
|
|
Flash SSD
|
1.7 ms.
|
94.5 ms.
|
|
|
