oracle性能问题?(一定给分!!)

时间:2022-05-28 08:59:02
我们的oracle是8。0。6版的装在unix机上。开发人员通过client端连接进行开发。
问题:经常出现过程运行不了(非常非常的慢)最后报如下的错:
    ERROR at line 1:
ORA-04031: unable to allocate 4256 bytes of shared memory ("shared
pool","unknown object","sga heap","Sort Segment e")
ORA-06512: at "PMEXP.PMC27REPORT", line 263
ORA-06512: at line 1
是不是share pool区分配的太小的原因。我们的是:
  shared_pool_size = 3500000
我的理解仅限于此。希望DBA高手给点详细的有建设的意见。

保证给分!!!

11 个解决方案

#1


一般都是这个的原因。
再分大点看看如何?



#2


太小了,9000000差不多

#3


sorry
我看错了。是90000000。
会不会还有其它的原因呀!!!

#4


90000000我看也不一定够用,hehe

#5


shared_pool_size = 3500000是以字节为单位的,你才分配3m多,太少了,怎么也要100m左右

#6


问题的原因看起来是该内存分配的太小

另外想确认两个问题:
1:  你们是否使用了MTS,如果使用了这个,需要加大  large_pool_size
2:如果没有使用mts,确认你们的程序是否有问题;还有就是是否每使用bind  var,大量的sql被进行了parse

#7


回复:biti_rainy(biti_rainy)
是的我们是用了dbms_sql.bind_variable和parse。
能给详细解释一下对系统的消耗马。

#8


shared_pool_size 太小

#9


是shared_pool_size = 太小。
ORACLE  SGA  的分配 
2001-08

ORACLE 8.0.X 版本

SGA=((db_block_buffers * block size)+(shared_pool_size+large_pool_size+log_buffers)+1MB

ORACLE 8.1.X 版本

SGA=((db_block_buffers * block size)+(shared_pool_size+large_pool_size+java_pool_size+log_buffers)+1MB

理论上SGA可占OS系统物理内存的1/2——1/3,我们可以根据需求调整

我推荐SGA=0.45*(OS RAM)

假设服务器运行ORACLE 8.1.X 版本, OS系统内存为2G MEM, db_block_size 是8192 bytes, 
除了运行ORACLE数据库外, 没有其它的应用程序或服务器软件.

这样SGA合计约为921M ( 0.45*2048M ), 

设shared_pool_size 320M (320*1024*1024 bytes)

设database buffer cache 500M (64000*8192 bytes)

 initorasid.ora文件里具体各参数如下:

shared_pool_size = 335544320
# 320 M

db_block_buffers = 64000
# 500 M

log_buffer = 524288
# 512k (128K*CPU个数)

large_pool_size = 62914560
# 60 M

java_pool_size = 20971520
# 20 M

sort_area_size = 524288
# 512k (65k--2M)

sort_area_retained_size = 524288
# MTS 时 sort_area_retained_size = sort_area_size
SUN Solaris里/etc/system文件里的几个参数同样跟内存分配有关
ORACLE安装时缺省的设置: 建议修改的设置:
set shmsys:shminfo_shmmax=4294967295 set shmsys:shminfo_shmmin=1 set shmsys:shminfo_shmmni=100 set shmsys:shminfo_shmseg=15 set semsys:seminfo_semmns=200 set semsys:seminfo_semmni=70 set ulimit=3000000  set semsys:seminfo_semmni=315set semsys:seminfo_semmsl=300set semsys:seminfo_semmns=630set semsys:seminfo_semopm=315set semsys:seminfo_semvmx=32767set shmsys:shminfo_shmmax=4294967295set shmsys:shminfo_shmmni=315set shmsys:shminfo_shmseg=10set shmsys:shminfo_shmmin=1
其中这些参数的含义
shmmax - 共享内存段,建议设大点, 达到最大SGA
shmmin - 最小的共享内存段.
shmmni - 共享内存标志符的数量.
shmseg - 一个进程可分配的最大内存段数.
shmall - 最大可允许的内存数,比SGA还要大.
semmns - 信号灯,跟ORACLE的PROCESS数有关.
semmsl - 一个信号灯中最大的信号灯数.

#10


看来可能真是share pool分配的太小。
可惜我不是DBA,不然可以改大点看看能不能解决问题!!!!
谢谢各位。
来着有分

#11


由于oracle对于sql语句的解析是按照  字符串  来解析的
你查询 v$sql视图
看看是否有大量的类似这样的语句: 

select * from xxx where a = 'ww';
select * from xxx where a = 'qq';

就是这种有值不一样的形式上一样的
如果这样的话,可以考虑在init文件中使用参数:   cursor_sharing = true;

另外,增加 shared_pool_size当然也是一个办法
但如果是程序的问题,千万别让你无限制的增加下去,呵呵

#1


一般都是这个的原因。
再分大点看看如何?



#2


太小了,9000000差不多

#3


sorry
我看错了。是90000000。
会不会还有其它的原因呀!!!

#4


90000000我看也不一定够用,hehe

#5


shared_pool_size = 3500000是以字节为单位的,你才分配3m多,太少了,怎么也要100m左右

#6


问题的原因看起来是该内存分配的太小

另外想确认两个问题:
1:  你们是否使用了MTS,如果使用了这个,需要加大  large_pool_size
2:如果没有使用mts,确认你们的程序是否有问题;还有就是是否每使用bind  var,大量的sql被进行了parse

#7


回复:biti_rainy(biti_rainy)
是的我们是用了dbms_sql.bind_variable和parse。
能给详细解释一下对系统的消耗马。

#8


shared_pool_size 太小

#9


是shared_pool_size = 太小。
ORACLE  SGA  的分配 
2001-08

ORACLE 8.0.X 版本

SGA=((db_block_buffers * block size)+(shared_pool_size+large_pool_size+log_buffers)+1MB

ORACLE 8.1.X 版本

SGA=((db_block_buffers * block size)+(shared_pool_size+large_pool_size+java_pool_size+log_buffers)+1MB

理论上SGA可占OS系统物理内存的1/2——1/3,我们可以根据需求调整

我推荐SGA=0.45*(OS RAM)

假设服务器运行ORACLE 8.1.X 版本, OS系统内存为2G MEM, db_block_size 是8192 bytes, 
除了运行ORACLE数据库外, 没有其它的应用程序或服务器软件.

这样SGA合计约为921M ( 0.45*2048M ), 

设shared_pool_size 320M (320*1024*1024 bytes)

设database buffer cache 500M (64000*8192 bytes)

 initorasid.ora文件里具体各参数如下:

shared_pool_size = 335544320
# 320 M

db_block_buffers = 64000
# 500 M

log_buffer = 524288
# 512k (128K*CPU个数)

large_pool_size = 62914560
# 60 M

java_pool_size = 20971520
# 20 M

sort_area_size = 524288
# 512k (65k--2M)

sort_area_retained_size = 524288
# MTS 时 sort_area_retained_size = sort_area_size
SUN Solaris里/etc/system文件里的几个参数同样跟内存分配有关
ORACLE安装时缺省的设置: 建议修改的设置:
set shmsys:shminfo_shmmax=4294967295 set shmsys:shminfo_shmmin=1 set shmsys:shminfo_shmmni=100 set shmsys:shminfo_shmseg=15 set semsys:seminfo_semmns=200 set semsys:seminfo_semmni=70 set ulimit=3000000  set semsys:seminfo_semmni=315set semsys:seminfo_semmsl=300set semsys:seminfo_semmns=630set semsys:seminfo_semopm=315set semsys:seminfo_semvmx=32767set shmsys:shminfo_shmmax=4294967295set shmsys:shminfo_shmmni=315set shmsys:shminfo_shmseg=10set shmsys:shminfo_shmmin=1
其中这些参数的含义
shmmax - 共享内存段,建议设大点, 达到最大SGA
shmmin - 最小的共享内存段.
shmmni - 共享内存标志符的数量.
shmseg - 一个进程可分配的最大内存段数.
shmall - 最大可允许的内存数,比SGA还要大.
semmns - 信号灯,跟ORACLE的PROCESS数有关.
semmsl - 一个信号灯中最大的信号灯数.

#10


看来可能真是share pool分配的太小。
可惜我不是DBA,不然可以改大点看看能不能解决问题!!!!
谢谢各位。
来着有分

#11


由于oracle对于sql语句的解析是按照  字符串  来解析的
你查询 v$sql视图
看看是否有大量的类似这样的语句: 

select * from xxx where a = 'ww';
select * from xxx where a = 'qq';

就是这种有值不一样的形式上一样的
如果这样的话,可以考虑在init文件中使用参数:   cursor_sharing = true;

另外,增加 shared_pool_size当然也是一个办法
但如果是程序的问题,千万别让你无限制的增加下去,呵呵