| |
 |
|
Oracle Database Tips by Donald Burleson
|
Monitoring the Diskless Database
Currently, DBAs spend an inordinate amount of time
worrying about disk I/O, backups, and other topics that with the
advent of a diskless Oracle environment will simply cease to exist. As
more of the Oracle environment is virtualized, the monitoring has to
change to more CPU cycle monitoring and effective use of CPU
resources. This trend can already be identified with the larger
footprint being taken by such topics as CPU costing. Soon, query cost
will be counted not in terms of I/O to a disk but in CPU ticks and
memory cycles.
What will be eliminated?
-
Monitoring the cache: It will be automatically
sized and tuned for the current working set only.
-
Monitoring I/O speeds: Transfers will be at near
memory speeds.
-
Monitoring for contention: With no moving parts
and hence greatly reduced latency, the SSD technology increases
bandwidth by several orders of magnitude.
-
Monitoring redo logs: They will simply be memory
areas to be sized according to retention needs only.
-
Monitoring undo segments: These will also become
memory structures
-
Monitoring backups: The SSD technology backs
itself up. Offline backups of the backing store will not affect
database performance.
The DBA's job as it is known today will undergo a
profound change with more focus on tuning and optimization than
worrying with physical hardware and backups.
But What About Now?
All of this information on improvements in the
future is great, but what about now? What about the DBA that gets a
RamSAN system? Does his job have to change? No. All monitoring that
is done now can be done against the RamSAN system. The SSD is treated
identically to a standard disk drive.
This means all of the DBA's scripts will still
function as they always have. Monitoring tools will still act the
same, but of course, they will report much better performance.
Changing memory sizes should be done in a controlled fashion by
reducing cache memory and testing performance until peak performance
is reached. Preliminary testing shows the need to establish a working
set size System Global Area (SGA) database
cache which will vary from database to database.
See
code depot for complete scripts
This is an excerpt from the book
Oracle RAC & Tuning with Solid State Disk.
You can get it for more than 30% by buying it directly from the
publisher and get immediate access to working code examples.
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 January 2015, 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.
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:
| manufacturer |
model |
technology |
interface |
performance metrics and notes |
|
IBM |
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.
|
|
|
|
|
