因not open force loggning 引起的DG ora-1578 报错

         因not open force loggning 引起的DG ora-1578 报错

       前天，部署实施公司xx生产中心录入库一套DG，但是在之前，这其中的一台primary 是我N就之前的一台测试机。记得当时我是通过寂寞方式安装的版本 11.2g 03小版本。本来这这也没什么，可以前段时间，因为项目，部门经理突然把正式数据导入，就这样，变成了公司的正式库运行生产。 为此，我狂汗，咋也不提前说一下。就这样，我的测试机变成了生产，由于N就前的机子，我也忘记了，这台主 当时做了什么操作。

       周一上班，因其他事需处理，我也没远程看看这台xx生产中心库的性能，及设置什么的。 上午高峰期，也就这样过了。

     下午，突然，RTX 闪烁这急忙忙的头像，Y的，点开一下，测试部，质检部，ETL部，xx数据生产部 都在呐喊，怎么连接不进去了？  我也赶紧远程看看这xx服务器，Y的，ORA-04031 报错？ 

Errors in file /u01/app/oracle/diag/rdbms/xxxdb_p/gtadb/trace/gtadb_ora_29163.trc  (incident=4220):
ORA-04031: unable to allocate 56 bytes of shared memory ("streams pool","unknown object","streams pool","fixed allocation callback")
Incident details in: /u01/app/oracle/diag/rdbms/xxxdb_p/gtadb/incident/incdir_4220/gtadb_ora_29163_i4220.trc
Thu Dec 26 18:29:08 2013
Dumping diagnostic data in directory=[cdmp_20131226182908], requested by (instance=1, osid=29163), summary=[incident=4220].
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Error ORA-4031 occured during Initialization of Bufq KUPC$C_1_20131225143407 
Starting background process QMNC
Thu Dec 26 18:29:09 2013
QMNC started with pid=37, OS id=29200 

看看这库到底分配了多少内存：

NAME     TYPE VALUE
------------------------------------ ----------- ------------------------------
lock_sga     boolean FALSE
pre_page_sga     boolean FALSE
sga_max_size     big integer 512M
sga_target     big integer 512M

NAME     TYPE VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target     big integer 5904M

在看看 dev/shm 共享内存:

tmpfs                 9.8G     0  9.8G   0% /dev/shm

再通过系统看了看 物理内存及swap:

             total       used       free     shared    buffers     cached
Mem:      12299044   12233492      65552          0      15948   11230976
-/+ buffers/cache:     986568   11312476
Swap:     25165812      76372   25089440

top - 13:28:07 up 1 day,  3:40,  5 users,  load average: 14.78, 16.62, 17.17
Tasks: 314 total,   8 running, 306 sleeping,   0 stopped,   0 zombie
Cpu(s): 64.5%us,  1.7%sy,  0.0%ni,  8.3%id, 25.4%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  12299044k total, 12230484k used,    68560k free,    16032k buffers
Swap: 25165812k total,    76372k used, 25089440k free, 11230472k cached

此时CPU ：Cpu(s): 97.8%us,  2.1%sy,  0.0%ni,  0.0%id,  0.1%wa,  0.0%hi,  0.0%si,  0.0%st  我也过去:

看见这情况，知道了大概，通过系统登录，Y的，也登陆不了，原来公司的一种数据同步软件在实时数据同步，原来cpu 这大，这同步软件虽说也是通过对oracle 日志分析提出的数据，其通过自己的一个专有column值变动达到数据同步，同时也做大量得 select count(*)  tab 操作。

 临时通过 alter system flush shared_pool ; 还是不行！ 依旧登陆不了！  最后杀掉不必要的服务进程还是不行，最后 我恨，只能stop 监听了。 管理登陆，还是不行，通过执行alter system flush shared_pool ； 确保这ora-04031 错。最后最后，我直接干掉oracle 进程，库关了！(心情凉透了，万一起不来咋办？ 幸好，周末晚上，这库我备了控制文件，开了归档）。

 调整内存大小，重启了一下，连接OK 。 虽说有点小怨言部门经理。其他不说了! 连接正常，可以开工了，RTX 通知可用，看看时间，只发了5分钟，没造成大的影响。

   考虑的这primay cpu 很大，部门经理要求部署一台standby，读写分离，分担负载。

 开始搭建了，按照那些记忆，一点点的配置起来，查看库基本信息： 归档、密码文件、参数文件、监听测试、数据文件，日志文件、备份、 拷贝、 duplicate、查看备库进程、模式 、修改日志。ok都弄好了！查看trace文件，一切正常。

突然瞄了一下trace 日志： Y的，怎么又坏块，刚跑的dg， 日志如下：

Thu Dec 26 20:20:22 2013
Errors in file /u01/app/oracle/diag/rdbms/gtadb_s/gtadb2/trace/gtadb2_ora_16302.trc  (incident=24222):
ORA-01578: ORACLE ?版.?..?.(?.欢??18, ?.. 399904)
ORA-01110: ?版.?.欢 18: '/u01/app/oracle/datafile/gta_input_data_07.dbf'
ORA-26040: ?版.?..浣跨. NOLOGGING ?.」?.浇?
Thu Dec 26 20:20:25 2013
Errors in file /u01/app/oracle/diag/rdbms/gtadb_s/gtadb2/trace/gtadb2_ora_16306.trc  (incident=24223):
ORA-01578: ORACLE ?版.?..?.(?.欢??17, ?.. 410498)
ORA-01110: ?版.?.欢 17: '/u01/app/oracle/datafile/gta_input_data_06.dbf'
ORA-26040: ?版.?..浣跨. NOLOGGING ?.」?.浇?
Thu Dec 26 20:21:05 2013
Sweep [inc][28066]: completed
Sweep [inc][28065]: completed
Sweep [inc][24223]: completed
Sweep [inc][24222]: completed

看了一下，再看看表18:15，这坏块估计是那个开发的，在创建表，索引是估计加了nologging引起，先不管，回家再说，这段时间比较累,先补补觉！

第二天上班，再看看trace 文件：

Thu Dec 26 23:00:02 2013
Errors in file /u01/app/oracle/diag/rdbms/gtadb_s/gtadb2/trace/gtadb2_ora_20463.trc  (incident=24577):
ORA-01578: ORACLE ?版.?..?.(?.欢??17, ?.. 410512)
ORA-01110: ?版.?.欢 17: '/u01/app/oracle/datafile/gta_input_data_06.dbf'
ORA-26040: ?版.?..浣跨. NOLOGGING ?.」?.浇?
Thu Dec 26 23:00:05 2013
Sweep [inc][24577]: completed
Thu Dec 26 23:00:17 2013
DDE: Problem Key 'ORA 1578' was completely flood controlled (0x6)
Further messages for this problem key will be suppressed for up to 10 minutes
Thu Dec 26 23:00:24 2013
DDE: Problem Key 'ORA 1578' was completely flood controlled (0x6)
Further messages for this problem key will be suppressed for up to 10 minutes
Thu Dec 26 23:16:02 2013

又报后面的错，　百度了一下DDE: Problem Key 'ORA 1578' was completely flood controlled (0x6)　，和猜测一样，说是trace 文件比较频繁，所以。。。。。

开始动手了：

 通过 v$archived_gap,v$recovery_log,v$recover_file 都显示no row 

通过DBV FILE 体检一下,

SQL> l
  1  SELECT SEGMENT_TYPE,OWNER||'.'||SEGMENT_NAME
  2  FROM DBA_EXTENTS
  3  WHERE FILE_ID = 17 AND 410512 BETWEEN BLOCK_ID
  4* AND BLOCK_ID+BLOCKS -1

SEGMENT_TYPE||'.'||SEGMENT_NAME
--------------------------------------------------------------------------------
INDEX.IUM46669939

看来看，原来是一条索引，好办， 同时心想，难道我忘记了forcelogging？ 创建dg 的时候？？

于是，毫不犹豫的 v$database 看了一下，还真是！ 于是毫不犹豫在primary 上执行 alter database force logging!

通知通过user_indexes 查看这索引到底属于那张表：

SQL> select index_name,index_type,TABLE_OWNER,table_name,logging,TABLESPACE_NAME from user_indexes where index_name='IUM46669939';


INDEX_NAME       INDEX_TYPE   TABLE_OWNER  TABLE_NAME LOG TABLESPACE_NAME
------------------------------ --------------------------- ------------------------------ ------------------------------ --- ------------------------------
IUM46669939       NORMAL   INPUT  TBL_ZZ_I_PERF YES GTA_INPUT_DATA

最后，通过沟通，查看，这张表上午基本没有操作，于是毫不犹豫 rebuild  indexes , 强制切换日志，查看备库，ok ! 问题解决。

当然，如果是控制文件，或者其他就更具不同 而解决了！ 不管bbed ，aul 或者dul ,  我觉得，备份对于DBA 来说，重于一切！

DBA 必须将两份文件保持为最新状态： 一份是好的简历，一份是最近的备份！ --我觉得比较赞！