数据库规划方案讨论

ligengocp

最初由 ttdb 发布
[B]

我觉得这个，你是完全 搞错了

Library cache
+
Data dictionary cache
+
User Global Area
=shared_pool

OLTP Application Issues
• Make sure that code is shared.
• Use bind variables rather than literals for optimally
shared SQL.

DSS Application Issues
• Parse time is less important.
• Bind variables are problematic.

说得是oltp需要更多的shared_pool
而复杂长时间查询，shared_pool并不重要

从Hybrid Systems里头
Memory Use
The following parameters will have higher values for daytime (that is, OLTP):
• SHARED_POOL_SIZE
• DB_BLOCK_BUFFERS
• SORT_AREA_SIZE

也可以得出结论
[/B]

   为什么我对shared_pool如此敏感？？是因为我曾经在上面吃过很多苦头。我在一个数据仓库项目中，需要执行很多的SQL语句，且每个SQL语句都是对几个大表进行JION操作，而且语法非常傻（这些SQL由某程序自动生成，我无法优化），1500M多的shared_pool消耗得非常快（半小时就没有空闲空间了）后来我将OPTIMIZE——MODE由CHOOSE改为FIRST ROW（使其在查询前对表的部分数据进行analysis），shared_pool消耗得慢一些。但当执行这种SQL语句达10个小时以上，还是会被消耗完。
   所以，我的意思是，虽然你的系统中没有像我这般傻的SQL语句，但如果有查询很多，且查询时间很长（6，7个小时以上）时，你的shared_pool大一些比较好。

    关于shared_pool消耗过快，我曾经还发布过贴子：
http://www.itpub.net/showthread.php?s=&threadid=2095

    可以看到，那些SQL语句，在共享池中进行PARSE时，肯定要耗费大量内存的。所以，我已经优化了程序，将很傻很长的SQL语句
用比较简单的语法代替。但长时间的查询肯定是有的，所以我将shared_pool留得与DB_BUFFER差不多大（前者250M，后者350M）基本上平时我观察shared_pool末使用率在70%左右。
     相反我在做数据仓库以前所做OLTP项目中，shared_pool都是默认值，像你512M的内存，一般就为几十M左右，从末出过问题。

此外，temp表空间你最好不要设置成自动增长，我曾经有一次TEMP表空间文件增长到5G，我还不知道。
TEMP表空间好像是查询时有ORDER BY时会使用，不知是否正确，还望指正。

ttdb

嗯，
但我觉得肯定不是 语句parse使你的 shared_pool 用掉不少

有时间，你不妨去找找为什么

Yong Huang

On OLTP, it's a bad idea to always increase shared pool when its free memory (from v$sgastat) is low because there may be too many SQLs not using bind variables. But for data warehouses, its free memory becomes a more meaningful indicator.

Any sorting uses temp tablespace, including order by, group by, sort merge join. You don't want to leave its datafile autoextensible because you don't want a file larger than 2G (somewhere there's still such limit).

Other comments. If I remember right, UGA is in PGA for dedicated server and in SGA for MTS. Too large log buffer may cause log file sync wait. Usually larger than 1M is a waste of memory and harmful in pre-8i (according to Steve Adams). "Larger values reduce log file I/O" should be changed to "Larger values reduce the number of log file I/Os but may increase the time of every I/O".

Yong Huang

最初由 ligengocp 发布
[B]
   所以，我的意思是，虽然你的系统中没有像我这般傻的SQL语句，但如果有查询很多，且查询时间很长（6，7个小时以上）时，你的shared_pool大一些比较好。
...
此外，temp表空间你最好不要设置成自动增长，我曾经有一次TEMP表空间文件增长到5G，我还不知道。
TEMP表空间好像是查询时有ORDER BY时会使用，不知是否正确，还望指正。 [/B]

你这种吃SHARE——POOL的情况不是由于长时间运行某些QUERY的缘故。这是由于你的SQL语句是自动生成的，对ORACLE来说，多数情况下将无法重用已有语句。这时如果SHARE——POOL还有剩余空间，新的PARSE语句将使用它，直到消耗光SHARE POOL，再使用LRU， PADE OUT 以前语句。

另外一个可以原音重现的系统是：
large_pool_size 为0，
使用MTS
sort_area_size很大

我在一个数据仓库项目中，需要执行很多的SQL语句，且每个SQL语句都是对几个大表进行JION操作，而且语法非常傻（这些SQL由某程序自动生成，我无法优化），1500M多的shared_pool消耗得非常快（半小时就没有空闲空间了）后来我将OPTIMIZE——MODE由CHOO

对于TEMP是否应该AUTOEXTEND 问题，我的经验是应该AUTOEXTEND，同时设定EXTEND的最大maxsize,如1G，可以避免一些可能。

对于REDO BUFFER，我也认为并不是越大越好，它无论如何不应大于3M。因为LGWR在1/3满，到1M时，。。。写LOG。

另外我注意到大家都没提到LARGE_POOL_SIZE，PARALLEL——AUTOMATIC——TUNING，这两个对内存的影响也很大。根据情况有可能应将parallel_automatic_tuning 设为TRUE，并将适当增大SHARE——pOOL——SIZE，以便ORACLE自动分配LARGE——POOL——SIZE。

还有，由于系统性能调优首先与应用相关。大家在提供相应案例时，还得多多介绍一下应用，以便分析。

biti_rainy

我觉得这个参数不应该给的太大
应该少于1M比较好
因为这个参数并不是所有用户公用的而是属于每个session的
并发大的时候可能有问题
比如存在mts或者需要比较大的时候
不能单独对某个session设置
那么就设置SORT_AREA_retaind_SIZE,小于SORT_AREA_SIZE

feng_xin

最初由 hahaer 发布
[B]你这种吃SHARE——POOL的情况不是由于长时间运行某些QUERY的缘故。这是由于你的SQL语句是自动生成的，对ORACLE来说，多数情况下将无法重用已有语句。这时如果SHARE——POOL还有剩余空间，新的PARSE语句将使用它，直到消耗光SHARE POOL，再使用LRU， PADE OUT 以前语句。

另外一个可以原音重现的系统是：
large_pool_size 为0，
使用MTS
sort_area_size很大




对于TEMP是否应该AUTOEXTEND 问题，我的经验是应该AUTOEXTEND，同时设定EXTEND的最大maxsize,如1G，可以避免一些可能。

对于REDO BUFFER，我也认为并不是越大越好，它无论如何不应大于。因为LGWR在1/3满，到1M时，。。。写LOG。

另外我注意到大家都没提到LARGE_POOL_SIZE，PARALLEL——AUTOMATIC——TUNING，这两个对内存的影响也很大。根据情况有可能应将parallel_automatic_tuning 设为TRUE，并将适当增大SHARE——pOOL——SIZE，以便ORACLE自动分配LARGE——POOL——SIZE。

还有，由于系统性能调优首先与应用相关。大家在提供相应案例时，还得多多介绍一下应用，以便分析。 [/B]

在使用DEDICATED方式时，不用设置LARGE_POOL_SIZE，在使用MTS方式时，要考虑规划LARGE_POOL_SIZE的值

在DEDICATED方式，不能认为不用设置LARGE——POOL——SIZE，尤其是一些HYBID或DSS系统，需要设置PARALLEL——AUTOMATIC——TUNING让系统自动从SHARE POOL 里分得一部分成为LARGE POOL，或者手工设置。这对于减少SHARE POOL的FRAGMENT很有好处。

zjfan

如果没有java的应用，java_pool_size可以设为0 ， 如果有java的应用（如java 存储过程之类），不设java_pool_size的话，应用如报错

bodyguard

词            意义                关联
undo:        <--------Point                          回滚段   rollback,数据库恢复的后滚阶段
redo                    Point-------->               重做日志，数据库恢复的前滚阶段

bodyguard

唉，一提交样子就变了。