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

OGG 12.2 extract not moving when redo log files are placed on RAW device AIX (解决办法)

近期在配置OGG环境中遇到了个问题,相同ogg和oracle rdbms版本,HPUX和Linux 平台运行正常, 只是AIX 平台的ogg extract进程没有进度, 启动时initial就要好久,同时也未报错, redo文件使用的是RAW device(裸设备), OGG release 12.2 , Oracle RDBMS release 11.2.0.3. 在OGG 12以前我们都知道存在一个参数RawDeviceOffset,但是12版本中该参数不存在了

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,这时重新同步一下即可。

Oracle GoldenGate 12.2 For Oracle New Feature: 集成的datapump internal

在以前的OGG版本中做oracle的表的初始化工作中, 通常为了捕捉在初始化过程中的数据变化, Source 端会在expdp 前启用extract进程,然后使用expdp 配合flashback_scn参数导出,在Target 端impdp 后,replicat 配置HANDLECOLLISIONS 参数做初始化的工作丢掉“重复或已存在的”更新,或者使用AFTERCSN参数定位的trail 文件中expdp那个时间点的scn ,从那个scn后开始应用变化, 在ogg 12.2 中引入了新特性把上面的一系列工作集成到了数据库内

如何修复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查看两节点并没有区别 .。。。

Troubleshooting ORA-07445 [intel_fast_memcpy.A()+18]

前不久有个朋友从遇到了个问题,在数据库启动过程种出现ora-7445, 然后数据库CRASH, 环境11.1.0.7 windows 版本, 临时禁用了smon tx recovery打开数据库, 没有再继续跟踪,这里记录一下.
ORA-07445: exception encountered: core dump [intel_fast_memcpy.A()+18] [ACCESS_VIOLATION] [ADDR:0x19DC0000] [PC:0x52B428E] [UNABLE_TO_WRITE] []

Frequent generate a lot of cdmp* directories contain *bucket trace in bdump(二 ) root cause

之前记录过Frequent generate a lot of cdmp* directories contain *bucket trace in bdump , 当时根据现象与该bug 很相似,该bug解决的只是不生成cdump还是会生成trace 文件,所以要分析生成trace的根本原因。之前数据库在诊断问题时也启用过相关trace event(见下面) , 但是instance memroy 级别实例重启后不再生效

ORA-32701 error in alert.log M000 hang event ‘not in wait’ during flush AWR

环境是一套11.2.0.3 2nodes RAC on hpux-ia31, alert中出现ora-32701 hangmgr错误, 从trace文件中发现是m000进程是mmon的辅助进程,用于flush AWR相关数据,有一个wait event: enq: WF – contention, 这也是flush AWR数据时相关的enqueue等待,但是blocker进程是not in wait