Oracle Database Tips by Donald Burleson

What 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 db_cache_size  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 time curve:

Figure 7.4 represents the same graph for the SATA setup:

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 future?

• 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 with backups

• 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 the database

• 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.

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.

Oracle RAC & Tuning with Solid State Disk Expert Secrets for High Performance Clustered Grid Computing Includes Oracle10g! Get immediate access to working code examples Buy it now for 30% off - Only $9.95

---

HTML-DB support:

For HTML-DB development support just call to get an Oracle Certified professional for all HTML-DB development projects.