Search BC Sites

Free Oracle Tips   HTML Text

Free Oracle App Server Tips   HTML Text

Privacy Policy

Redneck

Dress Code

Oracle tuning

Oracle training

Oracle support

Remote Oracle

Oracle Tips by 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:

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.

For more details and scripts, see my new book " Oracle Tuning: The Definitive Reference", over 900 pages of BC's favorite tuning tips & scripts.  You can buy it direct from the publisher for 30%-off and get instant access to the code depot.