Oracle & Starcraft

最近关于undocumented pga的嘴战打得越来越厉害，从最初Don Burleson在searchoracle上发表“Undocumented secrets for super-sizing your PGA”，然后就招来Jonathan Lewis 的一系列口诛笔伐，再后来连Mike Ault,TOM都卷入这场论战中去了，好不热闹。

Jonathan在他个人的网站上发表了

http://www.jlcomp.demon.co.uk/untested.html

http://www.jlcomp.demon.co.uk/snark.html#Addendum

等两篇文章用其一贯test!test!test!的态度指出了Don的多个错误

TOM也在自己的blog上发表了对undocumented pga的看法

http://tkyte.blogspot.com/2005/08/getting-credible-information.html#c112495300113904568

而在ASKTOM上也有一篇热贴是关于undocumented pga的

http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:47466211228419

Don Burleson大叔又一次成为了ORACLE界的名人，不过这一次依然是反面角色。

几位大拿主要针对Don大叔犯的2个错误进行批评

错误1：

Don说

· sort_area_size=1048576 <– sort_area_size is ignored when pga_aggregate_target is set and when workarea_size_policy =auto.

其实这不能说是个错误，这个问题看起来有点像几位大拿故意刁难Don大叔了，因为几位都举了MTS的例子来反驳Don大叔，搞的Don大叔有苦说不出，其实我觉得这有点小题大做了，Don大叔再怎么糊涂也不会不知道MTS是不采用AUTO PGA MANAGEMENT的。

错误2：

Don说

In a system like the example in Figure 1, the following settings would increase the default sizes for large sorts and hash joins.

· pga_aggregate_target = 1000m

· _pga_max_size = 1000m

· _smm_px_max_size = 333m

With these hidden parameters set we see a 5x large size increase for parallel queries and sorts:

· A RAM sort or hash join may now have up to 50 megabytes (5% of pga_aggegate_target) a 5x increase.

· Parallel queries may now have up to 330 megabytes of RAM (30% of pga_aggegate_target), such that a DEGREE=4 parallel query would have 83 megabytes (333 meg/4).

这个错误犯的就有点无知了，既然题目叫做Undocumented pga，居然连pga的隐含参数都没搞清楚，尤其是不清楚parallel execution slave是由

_smm_max_size限制，而只是简单的拿_smm_px_max_size/degree来估算slave的pga，这种低级错误被广泛传播真是让Don大叔丢尽了老脸，不过Don大叔好像也不为所动，searchoracle上的文章依然被广为阅读，而且号称他所说的都是根据N年的real-world experiences 得出的，并不是其他人用简单实验就能推翻的。

Don和jonathan的斗争一定还会继续下去，希望下次Don大叔不要这么狼狈了。