Oracle Database Tips by Donald Burleson
Does this Mean to Oracle?
In the first round of testing using Oracle9i and
the TPC-H benchmark, there was a test where the memory allocation to
the database block buffers was reduced, and with the SSD drives,
performance increased by several percent.
In an effort to gauge the importance of setting
db cache size when using SSD assets, in run five
of the TPC-H on SSD, the
was reduced by 50% from one
gigabyte to 500 megabytes. The results were surprising in that the
overall run time was reduced by eight percent with most queries
showing some improvement in runtime.
In the TPC-C study, tests were run with fully
cached data. Subsequently, memory was reduced to 50% then to 25% of
original settings. Overall, there was an increase in transactions per
second and a decrease in average response and transaction times. In
fact, with the increased memory available for users, the test was able
to scale up to nearly 1000 direct connected users with no loss in
response time or transaction times on only a 2-node, dual CPU setup.
This means that reading from disk is no longer a
performance robber. With SSD, the disks are eliminated and they are
replaced with high performance memory. Figure 7.3 shows the response
Figure 7.4 represents the same graph for the SATA
In this case, one picture, or chart in this case,
is worth a thousand words.
What does this mean for the Oracle database of the
The database cache will hold only a working size
set of data
No more huge disk farms
No more disk failures, RAID arguments or struggling
The Program Global Area will take over as the main memory area, allowing unlimited sorts,
hashes, sort-merge joins
More users will be able to use the same equipment
since more memory can be allocated to the process areas and less to
Smaller, more efficient code bases for the Oracle
database, reduced dependence on fancy LRU and aging algorithms.
Essentially, the relationship between the amount
of data stored on SSD and the size of SGA caching areas is an inverse
one. As the amount of data on SSDs goes up, the amount needed for
database caching will decrease.
What about the other memory areas? As redo logs
and undo segments go virtual, the redo log buffer will probably be
phased out, eliminating it from the Oracle memory footprint. The undo
segment will become the undo memory area. The roles of the various
other pools, such as the SQL and JAVA pools, will still be used to
ensure code is shared; however, whether they will still be utilized in
the same fashion is not clear.
Once the database becomes virtualized into SSD,
the entire internal structure of Oracle and the other databases will
have to change. They will have to eliminate many of the structures,
latches, locks that protected users from slow disks, delayed writes
and many other evils associated with disks. The result should be a
nearly quantum leap in processing speed.
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.
||For HTML-DB development support just call to get an
Oracle Certified professional for all HTML-DB development