问题一:关于ORA-04031的问题
环境:
3个instance的OPS
OS: Tru 64 unix 4.0f (3台机器的物理内存都为2G)
DB: Oracle 8.1.7.0.0 EE
描述问题:
每个实例的init.ora 主要配置如下:
processes = 150
shared_pool_size = 52428800
large_pool_size = 614400
java_pool_size = 0
control_files = /dev/rdrd/drd1, /dev/rdrd/drd2
db_block_buffers = 100108
db_block_size = 4096
log_buffer = 163840
log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800
(BTW,这是香港的ORACLE SUPPORT帮我们公司装的,呵呵)
前一端时间,数据库总是报错:
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 4248 bytes of shared memory ("shared
显现就是,用户不能建立连接,连接上的用户似乎可以“正常操作”,还有就是这种现象“自生自灭”,就是不用人工干预,过一个小时左右,就自动缓解了,问题发生的频率似乎没有规律(以上是守在生产机傍的同事对问题的陈述)
我建议,暂时如下修改init.ora:
processes = 150
shared_pool_size = 200M
large_pool_size = 614400
java_pool_size = 20M
control_files = /dev/rdrd/drd1, /dev/rdrd/drd2
db_block_buffers = 100108
db_block_size = 4096
log_buffer = 163840
log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800
运行一段时间后,数据库还是出现上述错误,仅仅是出现的频率减缓了。现场人员陈述说,出现问题时,几乎没什么特殊的操作,主要的操作是select(而且是很简单的select,最多在where中有一个and或者or,几乎没有设计到两个表以上的连接查询),而且表结构非常简单,但可能数据量大,每秒钟200个左右的select。
查看metalink后,我觉得,我们似乎遭遇了bug 1397603,(就是在SGA中没有可用的连续内存的错误),在生产机上不方便总是靠shutdown,然后在startup来缓解这种问题(我们是电信业务)。看到许多关于解决问题需要升级到8.1.7.2.0的建议,不知是否该升级,升级是否应该升到哪个版本(我想升级到81740),因为要去一趟现场很不容易(在国外),另外关于这个问题还有升级数据库的问题,大家有什么其他的建议和经验么,我没做过,害怕,呵呵。
谈到升级,引出了我的第二个感到疑惑的问题--------升级数据库后,我们还应该做什么?
环境:
2个instance的OPS
OS: Tru 64 unix 4.0f (3台机器的物理内存都为2G)
DB: Oracle 8.1.7.4.0 EE (p2401838_8174_TRU64)
描述问题:
客户反映不能在上面创建触发器,当发出“create trigger。。。“时报错:
ORA-00604: error occurred at recursive SQL level 1
ORA-29702: error occurred in Cluster Group Service operation
我起初认为可能和init.ora的配置有关,但是,还没等拿到关于init.ora的配置,客户就反馈回来,他已经解决了问题,主要看了关于建立触发机器的文档,然后照着是做了两件事情:
1. grant create trigger to the user
2. execute the script dbmsstdx.sql
然后就可以了。
我真的感到诧异和费解,因为首先该用户有connect和resource权限,所以,他做的第一件事情另我费解;
然后,这个dbmsstdx.sql ,我认为应该是:
The dbms*.sql and prvt*.plb Scripts The dbms*.sql and prvt*.plb
scripts create objects for predefined Oracle packages that extend the Oracle server
functionality. These programs simplify the task of administering the database.
Most SQL scripts are run during the execution of the catproc.sql script. A few
additional scripts must be executed by the database administrator.
An example is the dbmspool.sql script, which enables you to display the sizes of
objects in the shared pool and mark them to be kept or removed in the SGA in order to
reduce shared pool fragmentation.
那么,为什么这个脚本需要手工运行呢?
无意中想起了,这个ops是升过级的,从81700升级到81740,然后还打了patch,这个有影响么?
综上所述,很快要出差了,希望大家能解惑答疑,还希望有经验的朋友能给点经验,将不胜感谢。
环境:
3个instance的OPS
OS: Tru 64 unix 4.0f (3台机器的物理内存都为2G)
DB: Oracle 8.1.7.0.0 EE
描述问题:
每个实例的init.ora 主要配置如下:
processes = 150
shared_pool_size = 52428800
large_pool_size = 614400
java_pool_size = 0
control_files = /dev/rdrd/drd1, /dev/rdrd/drd2
db_block_buffers = 100108
db_block_size = 4096
log_buffer = 163840
log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800
(BTW,这是香港的ORACLE SUPPORT帮我们公司装的,呵呵)
前一端时间,数据库总是报错:
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 4248 bytes of shared memory ("shared
显现就是,用户不能建立连接,连接上的用户似乎可以“正常操作”,还有就是这种现象“自生自灭”,就是不用人工干预,过一个小时左右,就自动缓解了,问题发生的频率似乎没有规律(以上是守在生产机傍的同事对问题的陈述)
我建议,暂时如下修改init.ora:
processes = 150
shared_pool_size = 200M
large_pool_size = 614400
java_pool_size = 20M
control_files = /dev/rdrd/drd1, /dev/rdrd/drd2
db_block_buffers = 100108
db_block_size = 4096
log_buffer = 163840
log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800
运行一段时间后,数据库还是出现上述错误,仅仅是出现的频率减缓了。现场人员陈述说,出现问题时,几乎没什么特殊的操作,主要的操作是select(而且是很简单的select,最多在where中有一个and或者or,几乎没有设计到两个表以上的连接查询),而且表结构非常简单,但可能数据量大,每秒钟200个左右的select。
查看metalink后,我觉得,我们似乎遭遇了bug 1397603,(就是在SGA中没有可用的连续内存的错误),在生产机上不方便总是靠shutdown,然后在startup来缓解这种问题(我们是电信业务)。看到许多关于解决问题需要升级到8.1.7.2.0的建议,不知是否该升级,升级是否应该升到哪个版本(我想升级到81740),因为要去一趟现场很不容易(在国外),另外关于这个问题还有升级数据库的问题,大家有什么其他的建议和经验么,我没做过,害怕,呵呵。
谈到升级,引出了我的第二个感到疑惑的问题--------升级数据库后,我们还应该做什么?
环境:
2个instance的OPS
OS: Tru 64 unix 4.0f (3台机器的物理内存都为2G)
DB: Oracle 8.1.7.4.0 EE (p2401838_8174_TRU64)
描述问题:
客户反映不能在上面创建触发器,当发出“create trigger。。。“时报错:
ORA-00604: error occurred at recursive SQL level 1
ORA-29702: error occurred in Cluster Group Service operation
我起初认为可能和init.ora的配置有关,但是,还没等拿到关于init.ora的配置,客户就反馈回来,他已经解决了问题,主要看了关于建立触发机器的文档,然后照着是做了两件事情:
1. grant create trigger to the user
2. execute the script dbmsstdx.sql
然后就可以了。
我真的感到诧异和费解,因为首先该用户有connect和resource权限,所以,他做的第一件事情另我费解;
然后,这个dbmsstdx.sql ,我认为应该是:
The dbms*.sql and prvt*.plb Scripts The dbms*.sql and prvt*.plb
scripts create objects for predefined Oracle packages that extend the Oracle server
functionality. These programs simplify the task of administering the database.
Most SQL scripts are run during the execution of the catproc.sql script. A few
additional scripts must be executed by the database administrator.
An example is the dbmspool.sql script, which enables you to display the sizes of
objects in the shared pool and mark them to be kept or removed in the SGA in order to
reduce shared pool fragmentation.
那么,为什么这个脚本需要手工运行呢?
无意中想起了,这个ops是升过级的,从81700升级到81740,然后还打了patch,这个有影响么?
综上所述,很快要出差了,希望大家能解惑答疑,还希望有经验的朋友能给点经验,将不胜感谢。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/747/viewspace-483420/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/747/viewspace-483420/