虽然Oracle的最新版本都已经要到12.2了，但是在国内的生产环境，因为各种原因，尤其是政府部门和传统企业，其数据库版本却没有迭代到最新的Oracle数据库版本，本人就负责的就有10g的生产库，并且还存着核心数据（之前听同行说他们生产环境还有9i的库，不敢轻易触碰。。。。。。）。这次的经验和教训是：
1、本人一开始学习的版本是11.2.0.4，相比之前的版本新特性很多，切忌套用到旧版本；
2、RAC架构的数据库，停库的时候一定要保留一个节点，一次关闭一个实例，这或许会成为你救命的稻草；
3、最浅显的错误有时候是最难以发现的，故障诊断的时候一开始就应该从最一般的原因开始诊断。
最近负责的一个RAC双节点的数据库，版本是11.1.0.7，alert日志中报了三年多的ORA-04030错误，具体如下：
Oracle是这么解释这个错误的：
即操作系统pga资源紧张，查了一下系统pga和sga的大小：
pga_aggregate_target 20G
sga_target 25G
memory_max_target 45G
结果在查询的时候还查到了 memory_max_target居然不是0，而是设置成了45G，当时就想，不是ASMM管理方式吗，怎么会加个 memory_max_target，感觉有点画蛇添足啊？接着查了一下pga和sga的实际使用量，发现pga最高的使用量不过7G，sga不到40G，乍一看感觉不出什么问题。因为这个问题没有严重影响系统的正常运行，一时半会儿又看不出什么问题，于是乎就把这个问题放着了。
大概过了一个半月，遇到了系统每两个月一次的负载高峰期，数据库响应时间异常长，事后对AWR进行分析的时候看到了服务器物理内存大小为64G，突然想起4030错误会不会是数据库内存设置过大超过了物理内存？！于是又查看了一下sga_max_size的大小，居然是45G！这样一来，sga_max_size加上 pga_aggregate_target的大小就超过了实际物理内存的大小，会不会就是问题所在？
待续
1、本人一开始学习的版本是11.2.0.4，相比之前的版本新特性很多，切忌套用到旧版本；
2、RAC架构的数据库，停库的时候一定要保留一个节点，一次关闭一个实例，这或许会成为你救命的稻草；
3、最浅显的错误有时候是最难以发现的，故障诊断的时候一开始就应该从最一般的原因开始诊断。
最近负责的一个RAC双节点的数据库，版本是11.1.0.7，alert日志中报了三年多的ORA-04030错误，具体如下：
点击(此处)折叠或打开
- DDE: Problem Key 'ORA 4030' was flood controlled (0x6) (incident: 1193848)
- ORA-04030: out of process memory when trying to allocate 368 bytes (kxs-heap-p,rworalo : rwordops)
- Further messages for this problem key will be suppressed for up to 10 minutes
点击(此处)折叠或打开
- [oracle@hhu ~]$ oerr ora 04030
- 04030, 00000, "out of process memory when trying to allocate %s bytes (%s,%s)"
- // *Cause: Operating system process private memory was exhausted.
- // *Action:
pga_aggregate_target 20G
sga_target 25G
memory_max_target 45G
结果在查询的时候还查到了 memory_max_target居然不是0，而是设置成了45G，当时就想，不是ASMM管理方式吗，怎么会加个 memory_max_target，感觉有点画蛇添足啊？接着查了一下pga和sga的实际使用量，发现pga最高的使用量不过7G，sga不到40G，乍一看感觉不出什么问题。因为这个问题没有严重影响系统的正常运行，一时半会儿又看不出什么问题，于是乎就把这个问题放着了。
大概过了一个半月，遇到了系统每两个月一次的负载高峰期，数据库响应时间异常长，事后对AWR进行分析的时候看到了服务器物理内存大小为64G，突然想起4030错误会不会是数据库内存设置过大超过了物理内存？！于是又查看了一下sga_max_size的大小，居然是45G！这样一来，sga_max_size加上 pga_aggregate_target的大小就超过了实际物理内存的大小，会不会就是问题所在？
待续
