Two weeks ago I published a blog post about Parameter Recommendations for Oracle Database 12.1.0.2. And I took it down a day later. Why that?
I’ve got a lot of input from external sources for the “Parameter” blog post. And I’d like to thank everybody who contributed to it, especially Oracle ACE Ludovico Caldara.
Generally there was a bit of a misunderstanding internally about whether we should “advertise” underscore parameters to cure some misbehavior of the database. In 99% of all cases I’d agree that underscores are not a good solution – especially when it comes to database upgrades as our slide deck still contains a real world example about what happens when you keep old underscore parameters in your spfile. It can not only slow down the entire upgrade but also makes it very hard for Oracle Support to reproduce issues in case of something going the wrong direction.
But in some situations an underscore seems to be the only remedy in cases where a patch is not available for a particular release – the release you are using at the moment. And even if a patch is available or if the fix is available in a future PSU or BP that does not mean necessarily that one can apply it for several reasons.
We still have a lot of very productive discussions going on internally between many groups. That is very good as it means that we have plenty of smart people around, especially in Oracle’s Database Development 🙂
Furthermore we agreed that the Optimizer PM team will take over the part of my (taken down) blog post targeting wrong query results and other optimizer topics. We are in constant exchange and I’ll link it as soon as something gets published.
–Mike
Thanks Mike for this post (and the new one). This is stuff very useful for working around and avoiding customer issues.
How I see parameters is this:
1) Documented parameters
2) Undocumented parameters
3) Undocumented parameters that are documented in MOS (and sanctioned for *specific* use)
With even #1 – fully documented parameters, one should still do the thinking and research first.
No-one should use #2 – completely undocumented parameters in production. If it seems that setting one is needed, then everything should go through a MOS SR, until a better solution is found or Support sanctions use of this parameter (in writing)
#3 – MOS-documented undocumented parameters are sort of a "cache" of #2 parameters, so if a customer hits a known problem with a known workaround, this saves them days or weeks of SR work (and business impact!)
And once again, regardless of where and how a parameter is documented, one should always find out first what the root cause of their problem is – and then also be able to reason why the particular parameter (or patch) would avoid hitting this root cause again.
So, thanks for these articles, despite potential internal controversy – when used correctly, this stuff is super-helpful to many customers out there.
Mike,
Great posts on Oracle 12c. I did several upgrades from 11.2.0.4 to 12.1.0.2 using DBUA. In some cases, the new 12c spfile was modified to include almost 200 undoc parameters that were not in the 11g spfile. Odd thing, it did not happen in every case of a database upgrade, just a couple times. Have you seen/heard of this before? is it expected behaviour? (Yes, i have an Oracle SR opened, but they are not being very helpful!)
Gary D
Never seen such behavior before – can you please mail (or post) the SR number so I can have a look?
And the blog post you are asking for had to be removed per request 😉
Cheers
Mike