There are only two points you have to consider -
a) does a non-default value have any effect on the actual activity at the
time of execution
b) does a non-default value have any effect on the cost of the query, and
would that make any critical plans change in an undesirable way.
Both points can be investigated with some very simple modelling, though the
"actual activity" testing may require a little though to cover variations
like parallel execution, direct path reads in general, possible effects on
"small" tables; and the "costing" testing needs to consider the effects of
system statistics (dbms_stats.xxx_system_stats) and/or the calibrate_io
calls.
Once you've done the tests that are most relevent to your application and
setup you may still find that leaving everything to default is the safest
strategy.
Regards
Jonathan Lewis
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, 15 Jan 2021 at 22:17, Moustafa Ahmed <moustafa_dba@xxxxxxxxxxx>
wrote:
Hello
There are many opinions out there about the right value for
db file multiblock read count
And the more I look it seems like it started to be of less significance
than 10 years ago!
Say a value of *1024* which is considerably high
On Exadata and a DW system
What would be the concerns with that?
