ORACLE 9i-23ai

数据库oracle

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

by

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

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

by

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”

by

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

by

在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

by

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

三言两语Database 360 (DB360)

by

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

Little about partition segment

by

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

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

by

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

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

by

前不久有个朋友从遇到了个问题，在数据库启动过程种出现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

by

之前记录过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

by

环境是一套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