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

parrotao · 发表于 2002-9-25 15:21

关于log_buffer
看看http://www.ixora.com.au/tips/tuning/log_buffer_size.htm

还是让cluster来的解释吧

hjwhl · 发表于 2002-9-25 16:27

建议你把shared_pool_size 增到尽可能大,如1G;shared_pool_size可考虑增加到1M以上.

parrotao · 发表于 2002-9-25 16:44

这样你就彻底废掉了

最初由 hjwhl 发布
[B]建议你把shared_pool_size 增到尽可能大,如1G;shared_pool_size可考虑增加到1M以上. [/B]

eygle · 发表于 2002-9-25 20:12

最初由 hjwhl 发布
[B]建议你把shared_pool_size 增到尽可能大,如1G;shared_pool_size可考虑增加到1M以上. [/B]

不用1G，只要800M，保你死掉

hotian · 发表于 2002-9-26 16:41

是不是可以考虑用MTS模式。
OPS没做过，不懂，就当瞎说了！

TOM · 发表于 2002-9-26 17:40

最初由 eygle 发布
[B]

不用1G，只要800M，保你死掉 [/B]

斑竹可不可以介绍一下，为什么会彻底死掉呢

hooman · 发表于 2002-9-26 23:26

按照楼主说的情况, SHARED POOL 碎片化应该很严重了才对,
在这种状况下, 增大SHARED_POOL_SIZE 只会导致碎片更加严重, LATCH contention 急剧增加.....

我们这里原来一个8.0.5 下的系统就是这样, SHARED_POOL_SIZE 一大过200M, 启动一次跑几天就不行了.

8i 下好一点, 可能也差不多罢

ArthurXu · 发表于 2002-9-27 04:27

千改万改，不入改应用，从SQLAREA中察看并分析开销大的SQL语句比调整一个系统的参数有效多了。
还有就是系统参数一次不宜改太多，不可步骤太大，我的意思是在已经相对稳定的系统上，如果是没有调整过，就弄一个比较成熟的模版，不要经常改来改去，对一个系统来说，稳定高于一切，等同于中国国策！
还有就是，如果一个SQL语句要读几千上万次的磁盘，而且经常执行，和系统部分参数不当比，谁都可以知道什么是主要原因，即使要调整，也要等应用先稳定下来，才可能调整出比较合适的系统参数。

总之，如果系统参数不是太差，就开始准备调整应用，不过要花很多的时间和精力哦！

lunar2000 · 发表于 2002-9-27 08:33

最初由 ArthurXu 发布
[B]千改万改，不入改应用，从SQLAREA中察看并分析开销大的SQL语句比调整一个系统的参数有效多了。
还有就是系统参数一次不宜改太多，不可步骤太大，我的意思是在已经相对稳定的系统上，如果是没有调整过，就弄一个比较成熟的模版，不要经常改来改去，对一个系统来说，稳定高于一切，等同于中国国策！
还有就是，如果一个SQL语句要读几千上万次的磁盘，而且经常执行，和系统部分参数不当比，谁都可以知道什么是主要原因，即使要调整，也要等应用先稳定下来，才可能调整出比较合适的系统参数。

总之，如果系统参数不是太差，就开始准备调整应用，不过要花很多的时间和精力哦！ [/B]

所言极是，但是改应用谈何容易，呵呵（我说了不算的，sigh..）

lunar2000 · 发表于 2002-9-27 08:34

最初由 ArthurXu 发布
[B]千改万改，不入改应用，从SQLAREA中察看并分析开销大的SQL语句比调整一个系统的参数有效多了。
还有就是系统参数一次不宜改太多，不可步骤太大，我的意思是在已经相对稳定的系统上，如果是没有调整过，就弄一个比较成熟的模版，不要经常改来改去，对一个系统来说，稳定高于一切，等同于中国国策！
还有就是，如果一个SQL语句要读几千上万次的磁盘，而且经常执行，和系统部分参数不当比，谁都可以知道什么是主要原因，即使要调整，也要等应用先稳定下来，才可能调整出比较合适的系统参数。

总之，如果系统参数不是太差，就开始准备调整应用，不过要花很多的时间和精力哦！ [/B]

我记得8i下面32位的Oracle最多支持1.7G的sga

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

浏览过的版块