HIS主服务器加内存，搞定了

lfree

另外我修改接口网卡的bond0的MTU=9000.

这个修改要注意,有些交换机不支持.
或者使用一些scp命令传输文件有问题.

[ 本帖最后由 lfree 于 2009-11-4 14:39 编辑 ]

fals

原帖由 lfree 于 2009-11-4 11:39 发表

pga_aggregate_target                 big integer 1G 原来512M

在这个参数下运行，单台服务器的session达到了多少？没超过500吧？

lfree

原帖由 fals 于 2009-11-5 08:33 发表


在这个参数下运行，单台服务器的session达到了多少？没超过500吧？

最大在650上下(单台).

fals

原帖由 lfree 于 2009-11-5 14:41 发表


最大在650上下(单台).

在这个数字上没有报过12560错误？

看起来在UNIX下Oracle的客户端和服务器的数据处理机制完全不一样啊

lfree

上个星期四,做了应用分割,因为我们使用终端服务器,我仅仅能解决这部分,占很大的比例.

做法很简单:
建立两个服务:
一个连接实例1优先,另外一个连接实例2优先.
修改各个终端服务器的tnsnames.ora 配置,测试OK.

现在查询:

WITH system_event AS
   (SELECT CASE
             WHEN wait_class IN ('User I/O', 'System I/O')
             THEN event ELSE wait_class
            END  wait_type, e.*
       FROM v$system_event e)
SELECT wait_type, SUM(total_waits) / 1000 waits_1000,
      ROUND(SUM(time_waited_micro) / 1000000 / 3600, 2)
            time_waited_hours,
       ROUND(SUM(time_waited_micro) / SUM(total_waits) / 1000, 2)
             avg_wait_ms,
       ROUND(  SUM(time_waited_micro)
             * 100
             / SUM(SUM(time_waited_micro)) OVER (), 2)
          pct
FROM (SELECT wait_type, event, total_waits, time_waited_micro
      FROM system_event e
      UNION
      SELECT 'CPU', stat_name, NULL, VALUE
      FROM v$sys_time_model
      WHERE stat_name IN ('background cpu time', 'DB CPU')) l
WHERE wait_type <> 'Idle'
GROUP BY wait_type
ORDER BY SUM(time_waited_micro) DESC;


如图:
Cluster 等待下降许多,原来升级前接近10%,没有分割前5%上下,现在仅仅3%.

lfree

另外我发现升级后存在的问题,我觉得我增加太快了.
从1.2G->3G.

军惠的系统没有很好的绑定,导致shared pool一直在不断的增加,原来仅仅占500-600M,现在接近2G.
实例1的:

Total System Global Area    3221225472 bytes
Fixed Size                     2076208 bytes
Variable Size               1946157520 bytes
Database Buffers            1258291200 bytes
Redo Buffers                  14700544 bytes

看来动态分配内存在绑定没有做好的情况下,并不是很好,实际上shared pool 仅仅500-600M就差不多了.

lfree

还有就是增加内存后一些与磁盘Io相关的平均等待时间都变大了.

比如:
log file sync原来一般12ms上下,现在达到了24ms.
db file sequential read 平均等待现在基本在8-9ms,以前都是5-7ms之间.

不知道为什么?

lfree

今天又死了一次.
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 32 bytes of shared memory ("shared pool","select f.file#, f.block#, f....","sql area","tmp")
Tue Nov 10 08:43:39 2009
WARNING: inbound connection timed out (ORA-3136)

lfree

感觉是shared poll的问题,军惠没有很好的使用绑定,太糟糕了.

fals

楼上你可以检查一下客户端程序的ini文件，在database这一节里应该有下面的这个设置：

dbparm="disablebind=0"

注意看一下这个disablebind的值是不是设为0了？设为0就是定义绑定变量了。如果设置为0之后，在服务器后台做跟踪还发现SQL没有使用绑定变量的话，那就确认是程序的问题。

在天健的产品里，以及总后直接发下来的版本里，都不存在绑定的问题，这个我可以非常负责任的确认！！