站内搜索
Oracle证书
分类目录
- ASM (30)
- Database (86)
- backup&recovery (21)
- expdp/impdp (5)
- Installation and Deinstall (31)
- network (7)
- ORA-600 or ORA-7445 (6)
- Performence Tuning (13)
- troubleshoooting (2)
- Dataguard (7)
- EBS (3)
- Exadata (120)
- FAQ (19)
- POC和性能调整 (11)
- 体系架构 (19)
- 内部机制 (22)
- 安装和升级 (14)
- 性能指标 (8)
- Exadata V1 (1)
- Exadata V2 (1)
- Exadata X2-2 (2)
- Exadata X3-2 (1)
- Exadata X4-2 (1)
- FAQ (1)
- 故障诊断 (3)
- 日常运维 (15)
- 硬件配置 (43)
- Exadata V1 (6)
- Exadata V2 (6)
- Exadata X2-2 (6)
- Exadata X3-2 (8)
- Exadata X4-2 (8)
- FAQ (1)
- FAQ (16)
- Internal (21)
- Linux (20)
- MYSQL (8)
- OGG (1)
- ORA-600/7445 (2)
- ORA-XXXXX (5)
- Oracle 11.1 & Oracle11.2 (6)
- ORACLE 12C (21)
- Oracle 8 & Oracle 8i (1)
- RAC (47)
- SAP (2)
- Scripts (6)
- 未分类 (1)
- 虚拟化 (1)
文章归档
-
近期文章
- 针对最近黑客攻击数据库的解决方案和预防建议
- CentOS7.2(RHEL 7.2)的CPU占用高(%system 占用高)
- Oracle 12.1 RAC 系列 – 配置第二个网络和相应的SCAN2
- Oracle 12.1 RAC 系列-安装新主机,识别老存储和恢复数据库
- Oracle 12.2的Sharding-1-基础概念
- 11.2 RAC 系列-安装新主机,识别老存储-3-配置老存储的数据库
- 11.2 RAC 系列-安装新主机,识别老存储-2-准备识别数据库
- 11.2 RAC 系列-安装新主机,识别老存储-1-识别ASM磁盘
- 2016年1月PSU列表
- 单实例数据库转换为RAC数据库–使用rconfig转换
近期评论
- tom 发表在《exadata巡检报告的模板》
- cyx 发表在《关于我》
- 李科胜 发表在《EBS克隆–db和app分开在两个服务器上》
- xiao 发表在《exadata巡检报告的模板》
- Chris Sun 发表在《使用Oracle 11.2的DBMS_RESOURCE_MANAGER.CALIBRATE_IO对Exadata X5(HC)进行测试》
月归档:2015 年五月
数据库升级和DDL trigger
升级数据库时,比如从9i或者10g升级到11.2,官方文档强调需要禁用DDL trigger。 这里尤其要说的是OGG的DDL TRIGGER,如果升级前不禁用,很坑爹,具体参见《OGG DDL trigger造成升级数据库后大量SYS对象失效和数据库DDL失效》 那么什么是DDL trigger呢? 我们来做个测试: 这里我们看到了,TRIGGER_TYPE为BEFORE EVENT,这个显然是DDL trigger。 那么还有哪些类似的呢,我们来查看一下: 上面trigger type,从名字也很容易看出,至少两种: BEFORE EVENT和AFTER EVENT。 如果查询trigger event,你会看到有明显的DDL字样的类型的trigger: 上述具体含义可以查询Oracle官方文档,大概解释如下: 那么文档中所说的禁用DDL trigger到底是哪一种呢?下面我们测试一下,如果不禁用DDL trigger会是什么情况。 首先我们查询当前数据库中的trigger_type in (‘BEFORE EVENT’,’AFTER EVENT’)的DDL: 下面我们只把TRIGGERING_EVENT为DDL的trigger进行disable,然后执行数据库升级操作,之后来看看效果: 升级过程后续会单独写一个BLOG,这里不赘述。 升级过程没有任何报错,完美升级结束后,我们来检查一下数据库无效对象,发现确实有4个无效对象。 不过,数据库所有组件正如我们看到的升级过程一样,都是有效的,且已经升级成功: 上面看到有3个是OGG的,不用想,这个坑爹的OGG DDL功能造成的,另外一个SYS的DDLCTXINFO,这个比较眼生,检查它是什么来路: 可见,还是OGG DDL的东西,于是清理上述4个无效对象: 再次检查,已经没有无效对象,且数据库组件全部有效: 总结: 1,数据库升级前,一定要检查OGG用户的DDL功能是否已经被禁用,如果没有,麻利儿禁用它 … 继续阅读
ORA-12537: TNS:connection closed
今天测试数据库的时候,忽然发现使用远程连接的方式会报错: listener.log的日志如下: 这个报错,只解决上应该跟OS的什么配置有关系,但是不清楚哪里的配置问题。 正常的系统,使用strace跟踪,相关log如下: 这个有问题的系统使用strace跟踪,相关log如下: 上述较大的不同在于fcntl(9, F_GETFD)相关的内容,这个东西我也不懂,c语言都还给老师了…… :( 于是查询官方文档,根据MOS介绍,逐一核对文件权限: 检查oracle用户的权限: 1,grid的是正确的: oracle的是错误的: 使用root修改 再次检查已经正确了: 2,oracle用户的ORACLE_HOME所在文件系统不支持setuid/suid( 也不支持 nosetuid/nosuid 设置),例如: 我这里正常的: 再次测试还是连接不上: 3,检查oracle用户的$ORACLE_HOME应该为755(注意,不要带 -R !!!): 这次可以了: 把节点2也修改了:
ORA-00600[kfioTranslateIO03] 和ORA-00600[17090]的解决
今天玩VM,发现数据库不能启动了: 检查alert日志,报错如下: 很久没玩这个VM,隐约记得上次好像测试修改权限了 然后,根据报错查询官网: ORA-00600: internal error code, arguments: [kfioTranslateIO03], [], [], [], [], [], [], [], [], [], [], [] 果然是权限问题,因此检查相关权限并修改。 使用root: 现在启动数据库就不报错了: