Crsd start fail and crsd.log show “Policy Engine is not initialized yet”& evmd.log show “[gipcretConnectionRefused] [29]”

最近一套数据库的2节点半夜突然crash,被1节点驱逐, AGENT 启动DB失败,手动重启CRS启动失败,后来发现日志中的现象与MOS中多篇bug很像但又不是,节点2CRS启动失败,AIX环境,crs日志显示”Policy Engine is not initialized yet”,evmd.log 显示”[gipcretConnectionRefused] [29]”

Troubleshooting: ORA-00600: [kkpo_rcinfo_defstg:delseg], [xxxx] & ora-600 [25027] & ora-600 [ktadrprc-1]

因为某些原因数据字典表不一致,导到该表在查询或导出时都会提示ora-600 [kkpo_rcinfo_defstg:delseg] 错误,因为数据库使用延迟段创建,手动分配segment时提示ORA-600 [25027],对分区做MOVE时会提示ORA-600 [ktadrprc-1], 使用hcheck脚本检查会提示Orphaned TABPART$

Oracle 12.2.0.1 SQL HINT

source: v$sql_hint NAME VERSION VERSION_OUTLINE INVERSE —————————————- ————————- ————————- —————————————————————- APPEND 8.1.0 NOAPPEND NOAPPEND 8.1.0 APPEND NO_MONITORING 8.0.0 NO_SQL_TUNE 10.2.0.1 DEREF_NO_REWRITE 8.1.0 NESTED_TABLE_GET_REFS 8.1.0 PRESERVE_OID 10.2.0.1 NESTED_TABLE_SET_SETID 8.1.5 NESTED_TABLE_FAST_INSERT 10.1.0.3 INLINE_XMLTYPE_NT 10.2.0.1 REF_CASCADE_CURSOR 9.2.0 NO_REF_CASCADE NO_REF_CASCADE 9.2.0 REF_CASCADE_CURSOR FORCE_XML_QUERY_REWRITE 9.2.0 11.1.0.6 NO_XML_QUERY_REWRITE NO_XML_QUERY_REWRITE 9.2.0 11.1.0.6 FORCE_XML_QUERY_REWRITE IGNORE_WHERE_CLAUSE 9.2.0 OPAQUE_TRANSFORM 10.1.0.3 OPAQUE_XCANONICAL 10.1.0.3 SYS_DL_CURSOR 9.2.0 SQLLDR … Read more

Oracle 12C new feature: more detail from scheduler job view

我喜欢在PROCEDURE中增加一些DBMS_OUTPUT输出调试过程,但是只有在控制台运行才可以看到输出, 在11g及之前的版本中使用DBMS_SCHEDLER创建的JOB已经增加了DBA_SCHEDULER_JOB_RUN_DETAILS 视图可以记录一些运行的日志信息如error#,在12C的版本中再增强,同样记录了procedure中使用的DBMS_OUTPUT的输出和ERROR的具体文本…

Lots of Long transaction caused by database link, and undo hdr show DBA for that slot is 0x00000000

部署GOLDENGATE时发现,当前库中存在较多的长事务,在v$transaction中显示状态一直是ACTIVE, 对于长事务的对OGG的BR或启动抽取位置有较大影响, 奇怪的是这些长事务的起动时间甚至都有3天以上,而且当前会话状态已是INACITVE.而且查看UNDO SEGMENT HEADER上对应的SLOT 的DBA是0x00000000。

DBV not always correct, as in an extreme case the use of raw device

RAW DEVICE可以在增加数据文件时不指定文件大小,可用空间这样通常是RAW Device的实际大小, 但是文件头上不会写入可用块数,表空间块大小会写入, 这种情况下DBV工具无法从文件头正确的获取blocks数,所以产生错误的扫描块数结果。在不指定大小的情况下,如果RAW Device曾经文件头上有记录之前的blocks,RAW device在新加入数据库时也不会擦写该位置,这样后期在使用DBV时的结果就不正确。

Scripts: format Library Cache Lock/pin wait event p3 value

SQL> exec lbc_p3(1571747577004035);
———————————————
……………………..Library cache P3 value: 1571747577004035
………………….Library cache P3 value HEX: 5957f00010003
…………………………………Object id: 365951
…………………………………Namespace: 1
……………………………….RequestMode: exclusive mode

EM agent 12.1 割接主机后重部署 agent is blocked, and “out-of-sync with repository”

ORACLE DB 有时出于硬件维护等情况需要更换主机操作,但IP,DB实例等都未改变, 这时在割接后的机器需要重新部署EM_AGENT , 我通常是离线安装, 离线安装EM ANGENT 12参考我之前的笔记Acquiring Management Agent Software for HPUX&AIX in the Offline Mode(离线安装EM agent),OMS 端原target 不需要删除在重新填加, 但是重部署后的EM_agent 通过emctl status agent 状态会是blocked,这时重新同步一下即可。

如何修复ORA-01111, ORA-01110, ORA-01157 errors on Standby database

在oracle DATAGUARD环境,STANDBY_FILE_MANAGEMENT 参数控制standby database的文件管理。当启用自动备用文件管理时(AUTO),Primary数据库上的操作系统文件添加和删除将在备用数据库上复制。将此参数设置为MANUAL可能会导致MRP进程crash,也可能因为备库的映射错误或磁盘空间不足等原因,中止应用产生gap, 在standby db 的alert日志中可以发现备用数据库出现ORA-01111、ORA-01110、ORA-01157错误,备数据库中创建的文件为UNNAMED or MISSING的文件名。 下面记录修复方法. 错误日志 Errors in file /u01/app/oracle/diag/rdbms/orclstdy/orclstdy/trace/orclstdy_mrp00_11317.trc: ORA-01111: name for data file 11 is unknown – rename to correct file ORA-01110: data file 11: ‘/u01/app/oracle/product/11.2.0.4/db/dbs/UNNAMED00011’ ORA-01157: cannot identify/lock data file 11 – see DBWR trace file ORA-01111: name for data file 11 is unknown – rename to … Read more

goldengate 12.2 install and upgrade using Opatch

ogg 12.2 的安装方式和11是略有差别,之前是解压就OK, 现在是OGG提供了OUI 的安装方式,也可以静默方式,之前的升级是解压覆盖,现在多了一种选择可以像DB一样使用opatch安装,这里简单的记录下安装并给OGG安装PSU的过程。

三言两语Database 360 (DB360)

以后说起360可以脑子里除了闪过一个卖鞋的一个杀毒的,恐怕还要多个DB圈玩意了,360安全卫士相信你并不陌生,界面简捷扫描后打个分,简单说就是”傻瓜式”的操作, 如果数据库上出了这么个东东,你想不想要?还真有个DB360, but not free.

Little about partition segment

前几天看了篇日志自己一直没注意的小细节,利用开会儿的功夫做了个测试,因为维护的环境数据库中存在数万数十万的分区表, 平时维护时确实应该注意。环境11.2.0.4 这里就展示两个内容
1, 表上不同的分区初始化segment大小,在split partition时的segment大小继承方式。
2, truncate partition 会使手动unusable的分区索引变为usable.

Using ‘opatch lsinventory’ show patched is real? (看到的补丁信息真的靠谱么?)

去年在排查SCN 天花板问题修改相关的几个参数时,发现了这个问题,尤其如果是从别人手中接手的数据库,通常从opatch lsinventory 检查数据库的版本和补丁信息,在12C 的版本中也可以使用DBMS_QOPATCH, 但是有一个库发现之前别人挖了个坑实际安装补丁时应试是出错了,但是从opatch lsinventory查看两节点并没有区别 .。。。