Joe Huang, March 31, 2016 - 5:05 am UTC
Thanks Connor,
OK, let go of OPTIMIZER_INDEX_COST_ADJ.
As you said, I've check our system, and both of the 'optimizer_mode' at session and system level is set to 'ALL_ROWS'. Is there's any other way to let the optimizer to take USE_HASH into consideration more?
March 31, 2016 - 6:35 am UTC
Not *directly* to my knowledge. You'd need to tinker with SREADTIM, MREADTIM , MBRC to make full scans more attractive, which will most probably make nested loops less attractive.
But I'll ask around
Plan Baslines
Narendra, March 31, 2016 - 11:53 am UTC
Hello Joe,
Is there any reason you want to achieve this by tweaking optimizer only? If this is for a sql, using SQL Plan Baseline or SQL Profile is one way to make the query use the desired plan.
March 31, 2016 - 1:27 pm UTC
Thanks for your input.
I *think* Joe wants a bias toward hash joins over nested loops, across the whole database...but for particular queries, then baselines and/or profiles would be a good match.
Disabling Nested Loop across whole Database
Narendra, March 31, 2016 - 3:30 pm UTC
Hello Conor,
I might be wrong but I can't imagine why would anyone want to disable nested loop at a database level. That would almost certainly have negative side-effects, not just for the application tables but for data dictionary access too. I believe nested loop join is the most fundamental/basic join method in Oracle (or probably in any RDBMS) and don't think there is a way to disable it
Joe Huang, April 05, 2016 - 7:48 am UTC
Connor and Narendra, thanks for your helps!
I don't mean to disable nested loops, I just want a bias toward hash joins over nested loops at database level. However, we did not find a way to archieve this yet. As you guys said, the *SQL Profiles* could solve my problem. It really works, and maybe it is much more safty in some case.
Thanks again.