New hidden parameters in Oracle 11.2
By Mike Dietrich on Mar 09, 2011
We really welcome every external review of our slides. And also recommendations from customers visiting our workshops.
So it happened to me more than a week ago that Marco Patzwahl, the owner of MuniqSoft GmbH, had a very lengthy train ride in Germany (as the engine drivers go on strike this week it could have become even worse) and nothing better to do than reviewing our slide set. And he had plenty of recommendations.
Besides that he pointed us to something at least I was not aware of and added it to the slides:
In patch set 188.8.131.52 a new behaviour for datafile write errors has been implemented. With this release ANY write error to a datafile will cause the instance to abort. Before 184.108.40.206 those errors usually led to an offline datafile if the database operates in archivelog mode (your production database do, don't they?!) and the datafile does not belong to the SYSTEM tablespace. Internal discussion found this behaviour not up-to-date and alligned with RAC systems and modern storages. Therefore it has been changed and a new underscore parameter got introduced.
This is the default setting´and the new behaviour beginning with Oracle 220.127.116.11
If you would like to revert to the pre-18.104.22.168 behaviour you'll have to set in your init.ora/spfile this parameter to false. But keep in mind that there's a reason why this has been changed.
You'll find more info in MOS Note: 7691270.8 and this topic in the current version of the slides on slide 255.
Thanks to Marco for the review!!
And then I received an email from Kurt Van Meerbeeck today. Kurt is pretty well known in the Oracle community. And he's the owner of jDUL/DUDE, a database unloading tool which bypasses the Oracle database engine and access data directly on the block level.
Kurt visited the upgrade workshop two weeks ago in Belgium and did highlight to me that since Oracle 22.214.171.124 even though you haven't set neither SGA_TARGET nor MEMORY_TARGET (or set it to 0) the database might still do memory resize operations.
Reason why this behaviour has been changed: Prevention of ORA-4031 errors.
ORA-04031: unable to allocate string bytes of shared memory
Cause: More shared memory is needed than was allocated in the shared pool.
Action: If the shared pool is out of memory, either use the DBMS_SHARED_POOL package to pin large packages, reduce your use of shared memory, or increase the amount of available shared memory by increasing the value of the initialization parameters SHARED_POOL_RESERVED_SIZE and SHARED_POOL_SIZE. If the large pool is out of memory, increase the initialization parameter LARGE_POOL_SIZE.
But on databases with extremly high loads this can cause real trouble. Further information can be found in MOS Note:1269139.1 . And the parameter set to TRUE by default is called
This can be found now in the slide set as well on slide number 240.
And thanks to Kurt for this information!!