关于数据库的调整（不只是调优）问题

chao_ping

最初由 ggf0626 发布
[B]我想如果是针对4031的问题，你可以参照METALINK上的NOTES
Note:62143.1
Note:146599.1

减少LITERAL SQL，使用绑定变量；
1、        查找并减少LITERAL SQL（同时设置SESSION_CACHED_CURSORS和CURSOR_SHARING参数，如SESSION_CACHED_CURSORS=50，CURSOR_SHARING=FORCE）
2、        检查HASH链长度
3、        检查高的版本数目（_SQLEXEC_PROGRESSION_COST=0适用8.1.5/8.1.6/8.1.7）
4、        检查消耗内存多的语句

1、        DBMS_SHARED_POOL.KEEP包allows one to 'KEEP' packages, procedures, functions, triggers (7.3+) and sequences (7.3.3.1+) and is fully described in <Note:61760.1>
2、        用DBMS_JOB在空闲时做ALTER SYSTEM FLUSH SHARED_POOL;

因为这个问题本身很难找到一下子解决的方法，又不可能根本的重写应用，可能需要找目前的原因，然后设一些参数缓和一下。 [/B]

lunar如果有他的解决问题的思路，进步会快很多的。

Fenng

为什么不用statspack做个时间段的分析，从整体上入手比较好一些吧，这么头疼医头的，
讨论来讨论去的也是一样

Fenng

最初由 ggf0626 发布
[B]1,在OPS 8.1.5，8.1.6和8.1.7中，一定要在init<sid>.ora文件中设置
_SQLEXEC_PROGRESSION_COST=0

2,do u need to set gc_files_to_locks
3,lm_ress and lm_locks ,query v$resource_limit
4,  _lm_direct_sends         = lkmgr
5,why not set log_checkpoint_interval=1000000 [/B]

后学末进，不敢多言。
不过窃以为，既然Oracle都不在正式文档中说明的参数，还是不要贸然使用为好，一个系统的性能不是靠几个神奇的参数就能调整好的。

eygle

最初由 ttdb 发布
[B]http://asktom.oracle.com/pls/ask ... 088445659,%7Bsga%7D

建议去 asktom 用 ora-4031关键词搜索一下，可以知道不少东西 [/B]

很好的讲解，可是第一个算出来的结果为什么还有不同
v$sgastat中的varaiable size比v$sga中的要小，怎么回事？

是不是版本不同的关系？

还有这个牛人的redo buffers竟然这么大
NAME                     VALUE
-------------------- ---------
Fixed Size               39816
Variable Size        151544820
Database Buffers     838860800
Redo Buffers          41943040

lunar2000

最初由 chao_ping 发布
[B]
lunar如果有他的解决问题的思路，进步会快很多的。 [/B]

是的，chao_ping，我知道呢
你们大家真好，我所有的思路都是你们给的，我学习oracle的路上，都是你们帮助我的，太感谢大家了，如果说我在我的工作岗位有所贡献的话，也都是大家的帮助，真的。真挚的感谢。

lunar2000

最初由 ttdb 发布
[B]http://asktom.oracle.com/pls/ask ... 088445659,%7Bsga%7D

一个解析 SGA得很详细的贴子，刚刚去搜索asktom来的，呵呵，太好了

还有这个
http://asktom.oracle.com/pls/ask ... %20and%20%7B4031%7D

建议去 asktom 用 ora-4031关键词搜索一下，可以知道不少东西 [/B]

是的，呵呵，去metalink和ask tom search了一下，收获不小

cgh_chen

我想月儿应该看到过这篇文章。
http://metalink.oracle.com/metal ... T&p_id=146599.1

个人意见还是实例2，3 的shared_pool_size 太少。
不知道报4031错误的，具体是哪个实例。

lunar2000

最初由 cgh_chen 发布
[B]我想月儿应该看到过这篇文章。
http://metalink.oracle.com/metal ... T&p_id=146599.1

个人意见还是实例2，3 的shared_pool_size 太少。
不知道报4031错误的，具体是哪个实例。 [/B]

是这样的，三个都有（通过alert.log看到的）。这篇文章我看过了，老实说，一个月前，我曾在metalink上就4031错误看过一些文档，包括这个146599，但是因为没有到现场，而且处理问题和思考问题的思路有很缺乏，仅仅是找出人家大体的几种解决问题的说法，至于自己该选用哪一个，始终犹豫不觉。

最不希望的就是通过升级数据库（从Oracle 81700升级到Oracle 81720或者Oracle 81740）。

犹豫是生产机，泰国局方不同意在问题发生的时候restart database（事实上，这也不是长久之计呀）。

ggf0626

最初由 Fenng 发布
[B]

不过窃以为，既然Oracle都不在正式文档中说明的参数，还是不要贸然使用为好，一个系统的性能不是靠几个神奇的参数就能调整好的。 [/B]

其实，并没有说这样能提高性能。
只是对于OPS，2，3，4这几个参数都需要关注一下。

我认为_SQLEXEC_PROGRESSION_COST=0
至少比_db_handles_cached = 0安全一些，跟4031有关。

具体怎么做还是要实实在在的检查一下SHARE POOL。

实际上我没有任何实战经验，还请各位前辈多指教。

ggf0626

最初由 lunar2000 发布
[B]

是这样的，三个都有（通过alert.log看到的）。这篇文章我看过了，老实说，一个月前，我曾在metalink上就4031错误看过一些文档，包括这个146599，但是因为没有到现场，而且处理问题和思考问题的思路有很缺乏，仅仅是找出人家大体的几种解决问题的说法，至于自己该选用哪一个，始终犹豫不觉。

最不希望的就是通过升级数据库（从Oracle 81700升级到Oracle 81720或者Oracle 81740）。

犹豫是生产机，泰国局方不同意在问题发生的时候restart database（事实上，这也不是长久之计呀）。

[/B]

奇怪，升级到8174应该是最直接也最合理的办法。
因为对应4031有几个BUG，要么升级，要么设隐含参数WORKAROUND。

对于到底有没有HIT BUG，我觉得应该请ORACLE工程师诊断才对。