Best Practices for Optimizing Oracle RDBMS With Solid State Disk-final

Best Practices for Optimizing Oracle RDBMS with Solid State Disk

Written By Guy HarrisonSenior Director of Research and Development Quest Software, Inc.

WHITE PAPER Best Practices for Optimizing Oracle RDBMS with Solid State Disk

1

Contents Contents ......................................................................................................................................................................... 1

Introduction ................................................................................................................................................................... 2

A Brief History of IO ..................................................................................................................................................... 2

The Rise of Solid State Flash Disks ............................................................................................................................ 3

SSD Latency ................................................................................................................................................................ 3

Economics of Solid State Disk ..................................................................................................................................... 4

Fundamentals of Flash SSD Technology .................................................................................................................... 5

Storage Hierarchy .................................................................................................................................................... 5

Write Performance ................................................................................................................................................... 6

Write Endurance ...................................................................................................................................................... 6

Garbage Collection and Wear Leveling ................................................................................................................... 6

SATA, PCI, and SSD Storage Servers .................................................................................................................... 7

The Oracle Database Flash Cache ............................................................................................................................. 7

Architecture .............................................................................................................................................................. 7

Configuration and Monitoring ................................................................................................................................... 8

Other SSD Caching Options ........................................................................................................................................ 8

Options for Exploiting SSD .......................................................................................................................................... 9

Evaluating the Options .............................................................................................................................................. 10

Random Read Test ................................................................................................................................................ 10

OLTP Read/Write Workload ................................................................................................................................... 11

Full Table Scan Performance ................................................................................................................................. 11

Full Table Scans and FusionIO directCache .......................................................................................................... 12

Disk Sort and Hash Operations .............................................................................................................................. 12

Redo Log Optimization ........................................................................................................................................... 14

Best Practice Summary .............................................................................................................................................. 16

Conclusion ................................................................................................................................................................... 17

About the Author ......................................................................................................................................................... 18

References ................................................................................................................................................................... 19


2

Introduction Database performance is ultimately constrained by the need to read and write data from persistent storage – indeed this is the primary purpose of the database. For almost the entire history of modern relational database systems (RDBMS), this persistent storage has been provided by magnetic spinning disks. The relative performance of magnetic disk has been so poor when compared to the rest of the hardware stack that supports the RDBMS, that database performance tuning has focused primarily on minimising this disk IO.

Only now, with the advent of practical solid state disk (SSD) technology, are we experiencing an increase in IO performance to match the improvements we have come to take for granted in CPU and memory access speeds. The arrival of SSD promises to revolutionize database performance management.

Although replacing all magnetic disk with SSD is an unattractively expensive option for many Oracle databases, almost all Oracle databases can benefit dramatically from the judicious use of solid state disk. However, it’s not always obvious how best to leverage limited quantities of SSD in order to get the best performance return from your investment. In this paper, we’ll review the performance characteristics, economics, and architecture of solid state disk with the aim of formulating best practices recommendations for solid state disk deployment in Oracle database systems.

A Brief History of IO Magnetic disk has been a ubiquitous component of mainstream computer equipment for generations of IT profes-sionals. First introduced in the 1950s, the fundamental technology has remained remarkably constant: one or more platters contain magnetic charges that represent bits of information. These magnetic charges are read and written by an actuator arm, which moves across the disk to a specific position on the radius of the platter, and then waits for the platter to rotate to the appropriate location. The time taken to read an item of information is the sum of the time taken to move the head into position (seek time), the time taken to rotate the item into place (rotational latency) and the time taken to transmit the item through the disk controller (transfer time).

Figure 1. Magnetic disk architecture (from http://en.wikipedia.org/wiki/Hard_disk_drive)


3

Moore’s Law – first articulated by Intel founder Gordon Moore – observes that transistor density doubles every 18-24 months. In its broadest interpretation, Moore’s Law reflects the exponential growth that is commonly observed in almost all electronic components – influencing CPU speed, RAM, and disk storage capacity.

While this exponential growth is observed in almost all electronic aspects of computing – including hard disk densities – it does not apply to mechanical technologies such as those underlying magnetic disk IO. For instance, had Moore’s Law been in effect for the rotation speed of disk devices, disks today should be rotating 20 million times faster than in the early 1960s – in fact they are rotating only eight times faster.

So as the other key components of computer performance have been advancing exponentially, magnetic disk drives have been improving only incrementally. Consequently, disk drives today are slower now (when compared to other components or even their own storage capacity) than they were 10 years ago.

The Rise of Solid State Flash Disks Heroic efforts have been made over the years to avoid the increasingly onerous bottleneck of the magnetic disk drive. The most prevalent, and until recently most practical, solution has been to “short stroke” discs: essentially installing more discs than are necessary for data storage in order to increase total IO. This increases the overall IO capacity of the disk subsystem but has a limited effect on latency for individual IO operations.1

Solid state disk technologies have far lower latencies than magnetic disk and – having only electronic components – are accelerating in both performance and capacity, as predicted by Moore’s Law.

The two main categories of Solid State Disk technology are:

• DDR RAM-based SSD, in which memory not very different from computer RAM, is used as the storage me-dium. A capacitor or battery is incorporated so that data can be written to a non-volatile storage medium in the event of a power failure.

• Flash-based SSDs, in which data is stored in NAND flash memory – similar to that used in USB drives and consumer devices. This memory is non-volatile, so it will not lose data in the event of a power failure.

For the purposes of this paper, we will consider only flash-based SSD. DDR RAM-based SSD is not yet a viable economic alternative to magnetic disk for mainstream Oracle databases.

SSD Latency Performance of SSD is orders of magnitude superior to magnetic disk devices — especially for read operations. Figure 2 compares the read latency of various types of SSD and traditional magnetic disk.

1 Short stroking disks can improve IO seek latency by reducing the average distance the actuator arm needs to move across the disk and by concentrating data in the outer sectors of the platter where the overall rotational speed is highest.


4

Figure 2. Seek times for various drive technologies

Flash technology also promises significant reductions in power consumption – a Flash-based SSD device will typically consume about 100th of the power of a magnetic disk per IO operation.

Economics of Solid State Disk The promise of solid state disk has led some to anticipate a day in which all magnetic disk is replaced by solid state disk. While this might someday come to pass, in the short term the economics of storage and the economics of IO are at cross purposes and can only be resolved by combining solid state and magnetic disk technologies.

Figure 3 illustrates the two competing trends: while the cost of IO reduces with solid state technology, the cost per gigabyte increases. The SSD devices that offer good economics of IO offer poorer economies for mass storage. Of course the cost per GB for SSD is dropping rapidly, but no faster than the falling cost of magnetic disk or the growth in database storage demand.

4,000

80

25

15

0 500 1,000 1,500 2,000 2,500 3,000 3,500 4,000 4,500

Magne/c Disk

SATA Flash SSD

PCI Flash SSD

DDR-‐RAM SSD

Seek %me (micoseconds)


5

Figure 3. Economics of storage for solid state and magnetic disk

Since most databases include both hot and cold data – small amounts of frequently accessed data as well as large amounts of idle data – most databases will experience the best economic benefit by combining both solid state and traditional magnetic disk technologies.

Fundamentals of Flash SSD Technology The performance differences between solid state drives and magnetic disks are more complex than simply fast reads. Just as the fundamental architecture of magnetic disk favors certain IO operations, the architecture of solid state drives favor different types of IO. Understanding how an SSD handles the different types of operations helps us make the best decision for solid state drive deployment.

Storage Hierarchy

Flash-based solid state disks have a three-level hierarchy of storage. Individual bits of information are stored in cells. In a single-level cell (SLC) SSD, each cell stores only a single bit. In a multi-level cell (MLC), each cell may store two bits of information. MLC SSD devices consequently have greater storage densities, but lower performance and reliability.

Cells are arranged in pages – typically 4K in size – and pages into blocks of between 128K and 1M.

2.38

1.53

0.05

0.05

0.06

0.09

1.00

6.88

21.88

53.44

0.00 10.00 20.00 30.00 40.00 50.00 60.00

0.00 0.50 1.00 1.50 2.00 2.50

Capacity HDD

Performance HDD

MLC SATA SSD

SLC SATA SSD

PCI SLC SSD

Dollar/GB

Dollar/IO

Dollar/IOP

Dollar/GB


6

Write Performance

The page and block structure are particularly significant for SSD performance because of the special characteristics of write IO in flash technology. Read operations, and an initial write, require only a single page IO. However, chang-ing the contents of a page requires an erase and over-write of a complete block. Even the initial write is significantly slower than a read, but the block erase operation is particularly slow – around two milliseconds.

Figure 4. Flash SSD performance characteristics

Write Endurance

Write IO has another consequence in flash solid state drives: after a certain number of writes, a cell may become unusable. This write endurance limit differs between drives but is typically between 10,000 cycles for a low-end MLC device and up to 1,000,000 cycles for a high-end SLC device.

Garbage Collection and Wear Leveling

Enterprise SSD manufacturers go to great efforts to avoid the performance penalty of the erase operation and the reliability concerns raised by write endurance. Sophisticated algorithms are used to ensure that erase operations are minimized and that writes are evenly distributed across the device.

Erase operations are avoided through the use of free lists and garbage collection. During an update, the SSD will mark the block to be modified as invalid and copy the updated contents to an empty block, retrieved from a “free list.” Later, garbage collection routines will recover the invalid block, placing it on a free list for subsequent operations. Some SSDs will maintain storage above the advertised capacity of the drive to ensure that the free list does not run out of empty blocks for this purpose.

Wear leveling is the algorithm that ensures that no particular block is subjected to a disproportionate number of writes. It may involve moving the contents of “hot” blocks to blocks from the free list and eventually marking overused blocks as unusable.

0 500 1000 1500 2000 2500

Read (4k page seek)

First insert (4k page write)

Update (256K block erase)

Microseconds


7

SATA, PCI, and SSD Storage Servers

Flash solid state drives are typically deployed in one of three form factors:

• SATA-based flash drives are packaged in the same form factor as other SATA drives. They can, therefore, be deployed in any device with a SATA interface.

• PCI-based flash drives connect directly to the PCI interface on the computer motherboard. • Flash storage servers incorporate multiple PCI cards in a rack mounted server with multiple high speed net-

work interface cards.

SATA flash drives are substantially cheaper than PCI or rack mounted servers. However, the SATA interface was designed for slower devices with millisecond latencies and, therefore, imposes significant overhead on solid state disk service times. PCI-based devices can interface directly with the server and provide the most optimal perfor-mance.

The Oracle Database Flash Cache The Oracle database server has always been able to leverage solid state disk devices, which present to the database no differently than traditional devices. However, in Oracle database 11g release 2, Oracle introduced the database flash cache, which allows flash storage to be used as a secondary cache. The database flash cache can be imple-mented with only minimal configuration and offers a convenient way to supplement magnetic storage with a limited amount of flash storage.

The database flash cache can only be used with Oracle version 11Gr2 on Solaris or Oracle Enterprise Linux operating systems.

Architecture

The database flash cache serves as a secondary cache to the Oracle buffer cache. Oracle manages data blocks in the buffer cache using a modified “Least Recently Used” (LRU) algorithm. Simplistically speaking, blocks effectively age out of the buffer cache if they have not been accessed recently. When the flash cache is present, blocks that age out of the data cache are not discarded; they are instead written to the flash cache. Should the blocks be required in the future, they can be read from the flash cache instead of from slower magnetic disk-based database files.

Blocks are written to the flash cache by the database writer (DBWR) process, which is normally responsible for writing modified blocks to data files. However, the DBWR maintains the flash cache as a secondary priority to its primary responsibilities of writing out modified blocks to disk. Should the DBWR be busy with data file writes, it will bypass flash cache maintenance. This “willful neglect” is designed to ensure that the maintenance of the flash cache does not inadvertently cause “free buffer wait” contention, which occurs when the DBWR cannot clear modified blocks from the cache in a timely manner.


8

Figure 5 shows the Oracle database flash cache architecture. An Oracle server process reads blocks from the database files and stores them in the buffer cache (1). Subsequent reads can obtain the data blocks from the buffer cache without having to access the database file (2). When the block ages out of the buffer cache the database writer will load those blocks into the flash cache (3), but only if it does not interfere with writing modified blocks to disk (5). Subsequent reads may now find a block either in the flash cache (4) or the buffer cache (2).

Database Files

Oracle Server Process

Buffer Cache

Database Writer (DBWR)

(3)

(1)

(2)

(1)

Flash Cache

(3)(4)

(5)

Figure 5. Oracle database flash cache architecture

Configuration and Monitoring

The database flash case is configured through the database parameters DB_FLASH_CACHE_FILE and DB_FLASH_CACHE_SIZE. Individual segments (tables, indexes, etc.) may be prioritized or excluded from the flash cache by using the FLASH_CACHE segment properties clause, which takes the values KEEP, NONE, or DEFAULT. Segments that have the KEEP property will be maintained in the flash cache in preference to those with the DEFAULT property.

Oracle exposes the contents of the flash cache in the view V$BH and statistical information about flash cache activity in the view V$SYSSTAT. In addition, new wait events – showing time spent reading from and maintaining the flash cache – have been added to the wait interface views, such as V$SYSTEM_EVENT. These views may be queried to monitor flash cache activity. This information is fully exposed in Quest Software’s Spotlight® on Oracle product.

Other SSD Caching Options Many of the solid-state storage vendors have implemented caching technologies that are conceptually similar to the Oracle database flash cache. SSD cache technologies allow the SSD to act as a cache for any block-based storage medium. From the application or Operating System’s point of view, the SSD and magnetic storage medium appear as a single logical storage device. Under the hood, the caching technology arranges for hot blocks to be stored on the solid state disk device, accelerating read throughput.


9

FusionIO recently released a technology of this type – directCache – which allows a FusionIO card to be bound to – and provide caching for – a physical storage device.

Figure 6 illustrates the directCache architecture; the directCache driver presents the SSD and the storage medium – in this case a LUN exposing a RAID group – to the operating system as a single block device. The FusionIO SSD caches frequently accessed blocks in flash memory, accelerating read performance.

Figure 6. FusionIO directCache architecture

Options for Exploiting SSD Oracle database administrators have a range of options for taking advantage of the performance benefits offered by solid state disk:

1. The entire database might be deployed on SSD. For smaller databases this may be the simplest option. However, this option will often be economically impractical for large databases.

2. Selected data files, tables, indexes, or partitions could be located on solid state disk. This requires substan-tial planning and administration, but is likely to be very effective if the correct segments are selected.

3. For databases that are of a compatible version and operating system type, the Oracle database flash cache could be used. This option is simple to implement and can be very effective for read-intensive, index-based workloads.

4. The temporary tablespace could be relocated to solid state disk storage, accelerating the performance of temporary segment IO, as occurs with disk sort or hashing operations.

5. Redo logs are inherently write intensive and have been suggested as candidates for solid state disk storage. However as we shall see, the nature of redo log IO is not a perfect fit for SSD.


10

Evaluating the Options In order to assess the likely benefits for each of the deployment options outlined above, we executed simple perfor-mance tests that measured the performance of each configuration under appropriate workloads.

Our test system consisted of a Dell R510 dual quad core system with 32 GB of RAM, four directly attached 15K SAS hard disk drives and 1 FusionIO SLC PCI SSD. Unless otherwise stated, the performance comparisons are between a single SAS drive dedicated to a specific datafile or segment, and the FusionIO card dedicated to the same purpose. All ancillary IO (operating system, other datafiles, etc.) were directed to other devices.

Random Read Test

In this test, we compared the performance benefits provided by directly storing a segment on flash solid state disk with the database flash case and with traditional magnetic disk. The workload consisted of index-based reads against a 20 million row table using a small (128M) buffer cache and a 16 GB database flash cache.

Figure 7. Random read performance

Figure 7 summarizes the results. Using the database flash cache resulted in a significant boost in performance – a reduction of 74 percent in elapsed time, while hosting the entire table (and its index) on SSD resulted in a 95 percent reduction.

We did, of course, expect database flash cache performance to lag behind that of direct SSD, as the database flash cache requires that the block be read from magnetic disk at least once. However, the database flash cache does not require that there be sufficient SSD to store the entire segment, so it may be the more practical option in some circumstances.

2,211

583

121

0 500 1000 1500 2000 2500

SAS disk, no flash cache

SAS disk, flash cache

Table on SSD

Elapsed %me (s)

CPU

Other

DB File IO

Flash cache IO


11

OLTP Read/Write Workload

In this test, each row was selected twice and updated once during the test. Commits were issued every 10,000 rows. Figure 8 shows the results of the test.

Figure 8. Read/write performance test

The performance advantage of SSD is somewhat diminished when writes are involved, particularly for the db flash cache. However, the performance advantages were still substantial: 69 percent reduction in elapsed time for the database flash cache and 91 percent reduction when directly mounting the segment on SSD.

Full Table Scan Performance

This test measured the time to perform a full table scan against the test table. Figure 9 shows the results.

Figure 9. Full table scan performance

6,219

1,934

529

0 1000 2000 3000 4000 5000 6000 7000



Table on SSD

Elapsed Time (s)

DB CPU

db file IO

log file IO

flash cache IO

free buffer waits

Other

418

398

72

0 50 100 150 200 250 300 350 400 450



Table on SSD

Elasped %me (s)

CPU

Other

DB File IO

Flash Cache IO


12

Not surprisingly, placing the table on SSD resulted in a dramatic improvement in full table scan performance. However, using the database flash cache did not result in any measurable performance improvement. In Oracle 11g, full table scans typically bypass the buffer cache: the Oracle process reads directly from disk and does not place the blocks thus read into the buffer cache. Since the database flash case is populated from the buffer cache, full table scans cannot normally benefit from the database flash cache.

Full Table Scans and FusionIO directCache

As noted above, some SSD vendors offer caching technologies that operate in a similar way to the Oracle database flash cache, but are independent of Oracle software. These caching layers can accelerate direct path reads from full table scans that bypass the Oracle buffer cache and, therefore, the database flash cache.

Figure 10. FusionIO directCache can accelerate full table scans

Figure 10 shows the effect of implementing FusionIO directCache on full table scan performance. Without di-rectCache, successive table scans do not reduce IO overhead, since Oracle uses direct path reads that bypass its own buffer cache and the database flash cache. However, with directCache, subsequent table scans accelerate as IO requests are satisfied from the SSD. directCache is therefore a compelling solution for databases whose IO includes substantial direct path full table scans.

Disk Sort and Hash Operations

Oracle performs IO to the temporary tablespace when a disk sort or hashing operation occurs — typically as a consequence of ORDER BY or join processing — and there is insufficient PGA (Program Global Area) memory available to allow the join to complete in memory. Depending on the shortfall of memory, Oracle may need to perform a single-pass disk operation or multi-pass operations. The more passes involved, the heavier the overhead of the temporary segment IO.

147

147

147

36

0 20 40 60 80 100 120 140 160

No cache 1st scan

No cache 2nd scan

direct cache on 1st scan

direct cache on 2nd scan

Elapsed %me (s)

CPU

IO

Other


13

Figure 11. Traditional performance profile for disk sorts

Figure 11 shows what we have come to expect from disk sort performance. As memory becomes constrained, temporary segment IO requirements for the operation come to dominate performance and rise sharply as the number of temporary segment passes increase.

When the temporary tablespace is placed on SSD, a completely different performance profile emerges, as shown in Figure 12. While the overhead of single-pass sorts are significantly improved, the overhead of multi-pass disk sorts is drastically reduced. The more temporary segment passes involved, the greater the improvement.

Time

PGA Memory available (MB)

Table/Index IO CPU Time Temp Segment IO

Single pass sort

Mul/ -‐pass sort

Memory sort


14

Figure 12. SSD radically reduces the overhead of multi-pass disk sorts

Redo Log Optimization

The Oracle architecture is designed so that sessions are blocked by IO requests only when absolutely necessary. The most common circumstance is when a transaction entry must be written to the redo log in order to support a COMMIT. The Oracle session must wait in this circumstance in order to ensure that the commit record has actually been written to disk.

Since redo log IO is so often a performance bottleneck, many have suggested locating the redo logs on solid state disk for performance optimization. However, the nature of redo log IO is significantly different from data file IO; redo log IO consists almost entirely of sequential write operations for which magnetic disk is well suited, since there is no seek time and write throughput is limited only by the rotation of the magnetic disk. In contrast the write intensive workload is a worst case scenario for SSD since, as we have seen, write IO is far slower than read IO for solid state devices.

Figure 13 shows how a redo IO constrained workload placing the logs on a solid state disk device resulted in no measurable improvement in performance. In this case the SAS drive was able to support a write rate equal to that of the solid state disk device.

0

500

1000

1500

2000

2500

3000

3500

4000

0 50 100 150 200 250 300

Elap

sed %m

e (s)

Sort Area Size

Temp Tablespace on SAS disk Temp tablespace on SSD

Mul/ -‐pass disk sort .

Single pass disk sort


15

Figure 13. Performance of redo-constrained workload

292.39

291.93

0 50 100 150 200 250 300 350

Flash based redo log

SAS based redo log

Elapsed %me (s)

CPU

Log IO


16

Best Practice Summary Solid state disk technology can provide truly revolutionary improvements in database disk IO.

The economics of solid state disk – the high per-gigabyte costs in particular – may make complete replacement of magnetic disk with solid state disk impractical for larger databases. Many databases have very large, but relatively static data sets for which solid state disk is unnecessarily expensive given the high per-gigabyte costs and relatively low IO demand.

The best results will often be obtained when the solid state disk is combined with magnetic disk to provide both economical storage for static data and high performance retrieval for active data. In this paper we’ve looked at how best to implement solid state disk in Oracle databases, and recommend the following:

1. Use solid state disk strategically to relieve IO bottlenecks: solid state disk should be deployed where accel-eration of IO leads to the greatest application performance benefit. Knowing your IO performance bottlenecks is a necessary prerequisite to the intelligent deployment of solid state disk.

2. When IO bottlenecks are limited to specific segments (tables, partitions, or indexes) then relocating those

segments to solid state disk will almost always be effective in optimizing IO to those segments, regardless of the type of IO to which the segments are subjected.

3. Oracle’s database flash cache – while limited to the latest release of the Oracle 11g and available only on

Oracle operating systems (Oracle Enterprise Linux and Solaris) – offers a very convenient means of exploit-ing limited amounts of solid state disk. The database flash cache can only optimize buffered IO, however, which means that it will not normally optimize full table scans or temporary tablespace IO.

4. Many solid state disk vendors provide caching technologies, such as FusionIO’s directCache. These allow

the solid state disk to act as a secondary cache for any arbitrary storage medium in a similar manner to Ora-cle’s database flash cache but without the limitations of Oracle versions or operating systems. Unlike the database flash cache, these caching options can optimize non-buffered IO and are able to optimize full table scans and temporary segment IO.

5. For databases where temporary segment IO is particularly significant, placing the Oracle temporary table-

space on solid state disk can be very effective. This is particularly true when the IO results from multi-pass temporary segment operations. The lower latency afforded by solid state drives can vary significantly and reduce the overhead of these otherwise IO intensive operations.

6. Oracle’s redo log is a frequent source of intensive IO and, by design, Oracle sessions will normally wait for

redo log IO to complete. However, the nature of redo log IO operations is essentially optimal for magnetic disk but least suitable for solid state disk. Redo log IO consists almost entirely of sequential write opera-tions, which are the worst case for solid state disk and the best case for magnetic spinning disk. Placing redo logs on solid state disk is generally not recommended.


17

Conclusion Almost any Oracle database can benefit from the judicious use of solid state disk. Attaining the benefits of solid state disk does not require a complete conversion from magnetic disk to solid state disk; indeed, for many databases, a combination of magnetic and solid state disk will offer the best balance between economical storage of static data and the economies of access for active data.

Getting the most benefit from solid state disk requires an understanding of the performance characteristics and economics of modern solid state flash drives in order to ensure their optimal deployment. In this paper, we’ve proposed best practices for optimizing Oracle database performance using solid state devices.


18

About the Author Guy Harrison is a senior director of research and development at Quest Software and has more than 20 years of experience in database design, development, administration, and optimization. Guy is an Oracle ACE and the author of “Oracle Performance Survival Guide” (Prentice Hall, 2009) and “MySQL Stored Procedure Programming” (OReilly with Steven Feuerstein) as well as other books, articles, and presentations on database technology. Guy is the architect of Quest's Spotlight® family of diagnostic products and has led the development of Quest’s Toad® for Cloud Databases. Guy can be found on the internet at http://www.guyharrison.net/, via email at [email protected] and is @guyharrison on twitter.


19

References Wikipedia article on SSD: http://en.wikipedia.org/wiki/Solid_state_disk

FusionIO direct cache: http://community.fusionio.com/media/p/1124/download.aspx

Oracle database flash cache: http://download.oracle.com/docs/cd/E11882_01/server.112/e17120/memory005.htm#BABHEDBH

Authors notes on SSD and the Oracle database flash cache: http://guyharrison.net/ssd


20

© 2011 Quest Software, Inc. ALL RIGHTS RESERVED.

This document contains proprietary information protected by copyright. No part of this document may be reproduced or transmitted in any

form or by any means, electronic or mechanical, including photocopying and recording for any purpose without the written permission of

Quest Software, Inc. (“Quest”).

The information in this document is provided in connection with Quest products. No license, express or implied, by estoppel or otherwise, to

any intellectual property right is granted by this document or in connection with the sale of Quest products. EXCEPT AS SET FORTH IN

QUEST'S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST ASSUMES NO

LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS

INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,

OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE,

SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS

INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST

HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest makes no representations or warranties with respect to the

accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product

descriptions at any time without notice. Quest does not make any commitment to update the information contained in this document.

If you have any questions regarding your potential use of this material, contact:

Quest Software World Headquarters LEGAL Dept

5 Polaris Way

Aliso Viejo, CA 92656

www.quest.com

email: [email protected]

Refer to our Web site for regional and international office information.

Trademarks

Quest, Quest Software, the Quest Software logo, AccessManager, ActiveRoles, Aelita, Akonix, AppAssure, Benchmark Factory, Big Brother,

BridgeAccess, BridgeAutoEscalate, BridgeSearch, BridgeTrak, BusinessInsight, ChangeAuditor, ChangeManager, Defender,

DeployDirector, Desktop Authority, DirectoryAnalyzer, DirectoryTroubleshooter, DS Analyzer, DS Expert, Foglight, GPOADmin, Help Desk

Authority, Imceda, IntelliProfile, InTrust, Invirtus, iToken, I/Watch, JClass, Jint, JProbe, LeccoTech, LiteSpeed, LiveReorg, LogADmin,

MessageStats, Monosphere, MultSess, NBSpool, NetBase, NetControl, Npulse, NetPro, PassGo, PerformaSure, Point,Click,Done!,

PowerGUI, Quest Central, Quest vToolkit, Quest vWorkSpace, ReportADmin, RestoreADmin, ScriptLogic, Security Lifecycle Map,

SelfServiceADmin, SharePlex, Sitraka, SmartAlarm, Spotlight, SQL Navigator, SQL Watch, SQLab, Stat, StealthCollect, Storage Horizon,

Tag and Follow, Toad, T.O.A.D., Toad World, vAutomator, vControl, vConverter, vFoglight, vOptimizer, vRanger, Vintela, Virtual DBA,

VizionCore, Vizioncore vAutomation Suite, Vizioncore vBackup, Vizioncore vEssentials, Vizioncore vMigrator, Vizioncore vReplicator,

WebDefender, Webthority, Xaffire, and XRT are trademarks and registered trademarks of Quest Software, Inc in the United States of

America and other countries. Other trademarks and registered trademarks used in this guide are property of their respective owners.

Updated—August, 2011


21

About Quest Software, Inc.

Quest Software (Nasdaq: QSFT) simplifies and reduces the cost of managing IT for more than 100,000 customers worldwide.

Our innovative solutions make solving the toughest IT management problems easier, enabling customers to save time and money

across physical, virtual and cloud environments. For more information about Quest solutions for administration and automation,

data protection, development and optimization, identity and access management, migration and consolidation, and performance monitoring,

go to www.quest.com.

Contacting Quest Software

PHONE 800.306.9329 (United States and Canada)

If you are located outside North America, you can find your local office information on our Web site.

EMAIL [email protected]

MAIL Quest Software, Inc.

World Headquarters

5 Polaris Way

Aliso Viejo, CA 92656

USA

Contacting Quest Support

Quest Support is available to customers who have a trial version of a Quest product or who have purchased a commercial version and have

a valid maintenance contract.

Quest Support provides around-the-clock coverage with SupportLink, our Web self-service.

Visit SupportLink at https://support.quest.com.

SupportLink gives users of Quest Software products the ability to:

Search Quest’s online Knowledgebase

Download the latest releases, documentation and patches for Quest products

Log support cases

Manage existing support cases

View the Global Support Guide for a detailed explanation of support programs, online services, contact information and policies and

procedures.

WPD-OptmzOracleRDBMS-SldStDisk-US-KS

Documents

Best Practices for Optimizing Oracle RDBMS With Solid State Disk-final