Heim  >  Artikel  >  Datenbank  >  因not open force loggning 引起的DG ORA-1578 报错

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

WBOY
WBOYOriginal
2016-06-07 17:35:471025Durchsuche

前天,部署实施公司xx生产中心录入库一套DG,但是在之前,这其中的一台primary 是我N就之前的一台测试机。记得当时我是通过寂寞方

前天,部署实施公司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

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

NAMETYPEVALUE
------------------------------------ ----------- ------------------------------
lock_sgabooleanFALSE
pre_page_sgabooleanFALSE
sga_max_sizebig integer 512M
sga_targetbig integer 512M

NAMETYPEVALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_targetbig 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 文件:

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Vorheriger Artikel:MySQL Cluster 安装Nächster Artikel:Oracle Index 和null 研究