oracle db_cache_size 数据库重启后不生效,memory_target设置不当导致数据库无法启动解决...

今天在做一个问题排查的时候碰到了另外一个有些“奇怪的”问题。

我们在测试库中已经禁用了SGA自动存储管理,结果在spfile文件里丢掉了shared_pool_size的配置

测试环境的参数类似下面的样子

sga_max_size                        big integer 12000M

sga_target                            big integer 0

shared_pool_size                    big integer 0

db_cache_size                        big integer 6G

pga_aggregate_target                big integer 3147483648

这种配置应该是有问题的,把shared_pool_size的部分给丢掉了。结果查看当前测试库的情况,发现shared_pool多多少少的给了2G。

COMPONENT                      CURRENT_M      MIN_M      MAX_M SPECCIFIED_M LAST_OPER LAST_OPER_TYP  GRANULE_M

------------------------------ ---------- ---------- ---------- ------------ --------- ------------- ----------

shared pool                          2000        992      2000        2000 MANUAL    GROW                  16

large pool                            304        304        512          304 DEFERRED  SHRINK                16

java pool                            512        512        512          304          STATIC                16

streams pool                            0          0          0            0          STATIC                16

DEFAULT buffer cache                6224      6144      6352        6144 MANUAL    SHRINK                16

KEEP buffer cache                      0          0          0            0          STATIC                16

RECYCLE buffer cache                    0          0          0            0          STATIC                16

DEFAULT 2K buffer cache                0          0          0            0          STATIC                16

DEFAULT 4K buffer cache                0          0          0            0          STATIC                16

DEFAULT 8K buffer cache                0          0          0            0          STATIC                16

DEFAULT 16K buffer cache                0          0          0            0          STATIC                16

DEFAULT 32K buffer cache                0          0          0            0          STATIC                16

Shared IO Pool                          0          0          0            0          STATIC                16

如果问题到这里,可能就告一段落了。

但是我又认真看了一下,发现还是有问题。SGA有12G左右,分给shared_pool 2G,buffer_cache 6G,加上large_pool,java_pool的还不到9G,剩下的部分到哪去了?

从总体的sga的概览来看

SQL> show sga

Total System Global Area 1.1742E+10 bytes

Fixed Size                  2251264 bytes

Variable Size            5200938496 bytes  --这个部分还是有很大的差别。按照目前的shared_pool+large_pool+java_pool+stream_pool<3G,剩下的2G可能就是最后的可能,没有分配的内存空间。

Database Buffers        6526337024 bytes

Redo Buffers              12193792 bytes

带着这种疑问来查问题,可能你看到很多细节都是潜在的问题。

首先来看进程的情况。结果就发现按照常理进程的owner应该显示是用户名,但是现在却是进程号。

xxxxxx    6545 25419  0 12:44 pts/7    00:00:00 grep smon

3068    21040    1  0 Oct22 ?        00:01:21 ora_smon_TESTCUS1

最后确认了下,原来如果用户名超出8位的时候就会显示为进程号,不是问题。

最后在spfile中先写入shared_pool_size=4G,然后重启数据库的时候,就报错了。

SQL> startup

ORA-00838: Specified value of MEMORY_TARGET is too small, needs to be at least 13920M

SQL>

从开始查问题的时候就没有注意到这个参数,memory_target是在11g引入的。算是sga自动存储管理的加强版本,能够自动管理sga和pga。

如果大体了解了memory_target和报错的部分,可能一下子就明朗了。

因为当前的Memory_target的值就是12G和sga_max_size是一致的。

这个时候memory_target是12G,而同时pga是3G,那么分配给sga的部分就只有不到9G,这样的情况就相当于设置了sga_max_size=9G

这个时候重新分析下报错信息。我们把shared_pool从2G调整到了4G。这样的话memory_target的大小按照配置应该需要

shared_pool_size(4G)+db_cache(6G)+stream pool(0)+large_pool(300M)+java_pool(300M)+pga(3G)=13600M左右,和报错的部分基本符合。所以到此为止就可以判定是memory_target的设置不当导致了这个问题。

memory_target的设置还是需要重启数据库实例的。重启后查看就没有问题了。

看来很多问题都在一些细节上注意,这个memory_target从一开始就没有注意到,根据客户dba的反馈,他们是直接使用dbca来建的库,可能就是这个时候引入了这个新特性,然后在后期做了buffer size的变更。才发现这个很潜在的问题。

0b1331709591d260c1c78e86d0c51c18.png

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值