88- widely circulated parameter optimization, honey or poison?

I've heard a story : An optimization team is going to recruit a person , The interview in China has basically passed , It happens that a big boss from abroad is on a business trip to China , Want to talk to the candidate in person . In order not to let the foreign boss veto the right candidate who is hard to find , The person in charge in China specially asked the applicant , If the boss asks you to talk about optimization , Never tell him about the case of parameter optimization . The end of the story is the failure of the application , In the middle process, you can make up your own brain .

Today, I saw an article named <Oracle Detailed explanation of tuning parameters > The article , Some parameter optimization methods are introduced , Read more than 1500 Person time , It should be referred to by many people , Let me talk about my opinion ( The labeled screenshot is the original , The following part is my opinion ).

tiger:

The default value for this parameter is 300, It's written in 50 It should be a clerical error of the original author . Normal condition , One session Generally, it will not open more than 300 Cursors , Setting too large makes no sense . If it is true open_cursor The quantity exceeds 300, It is very likely that there is a cursor leak , Developers need to check and fix the code , Close cursor in time . If the setting is large , For example, in the article 20000, It is difficult to find these problems when testing , It will bring hidden dangers to the production system , I don't think this setting is advisable . Set to 1000 It's big enough .

tiger:

Modification of the above two parameters , I have seen many production systems , There are also some cases that lead to poor performance , Several cases have been introduced in my previous official account articles and training courses , In a word, do not change these two parameters , Keep the default . By modifying these two parameters , Let the optimizer scrape through some inefficient indexes , May backfire . The right thing to do is to get into the index , Create efficient indexes .

tiger:

ordinary RAC Heartbeat Network , Most Gigabit networks are possible , If the business partition is not done well , There will be more data exchange between nodes , It is really OK to modify this parameter . But it can not be generalized , If it is infiniband The Internet ( such as oracle Of Exadata), And it's OLAP System , There is no need to modify this parameter .

tiger:

The above parameter appears twice , It is recommended to change to 16. Many people reduce this value , It is also to make the optimizer tend to use indexes , Instead of full scan , That's what the official documents say , But the official documents do not suggest changes ( If 16 It's the best , Then the default parameter may have been changed to 16 了 ). oracle A lot of performance testing , Are the default parameters used , If the default parameter is modified , Then there are more options , oracle It is impossible to perform large-scale performance tests on various non default parameters . Or the above sentence , Try to create efficient indexes , The parameter is only reduced to make it easier for the optimizer to select inefficient indexes , And this change is not conducive to full table scanning ( Most systems are OLTP and OLAP Mixed ).

tiger:

There is no problem with the interpretation of the parameters , But why cancel the use of resource manager ? Use it when you should , Where the setting is inappropriate, it can be adjusted , Instead of just banning it .

Add :

There are many people who like to modify a lot optimizer Optimizer parameters at the beginning ( Include _optimizer Implicit arguments at the beginning ), They are not recommended , Unless these parameters lead to large areas of bug. In most cases, these parameters produce bug It will only affect a small number of special SQL, For these SQL Just make special treatment , It is not recommended to modify these default parameters at the system level .