R
Rob Fitzpatrick
Guest
I'm going over my notes from NEXT today and thinking about the discussions around the road to high availability in 12.x, and how proutil increaseto plays a part in that. In short, if some database restarts are done today to increase startup params, and if in the future those params can be adjusted online, then fewer restarts should be required. But I think that assumes an increased param's data structure is in the same state as it would be had it been that size since the database was started. Examples: increaseto -B n increases the size of the buffer pool but does not also increase the size of the buffer hash table. A database who buffer pool was increased online by a large amount could experience greater BHT latch contention than if it had been started at the larger amount. The same applies to increaseto -B2 n. similarly, increaseto -L n increases the size of the lock table but does not also increase the size of the lock hash table to the size it would have been had the database been started with the larger -L value. increaseto for cache-related parameters (omsize, mtpmsize, cscsize) only increases the size of the secondary caches, which doesn't yield the same benefit as a database start that makes the primary cache that size. Just wondering whether there are roadmap plans for proutil increaseto, not just to add the ability to use it with more parameters, but to make it a better substitute for a database restart.
Continue reading...
Continue reading...