站内搜索
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)
2024 年十月 S M T W T F S « Nov 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 文章归档
-
近期文章
- 针对最近黑客攻击数据库的解决方案和预防建议
- 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)进行测试》
分类目录归档:backup&recovery
使用DUL和ODU抽取Exadata上的oracle数据库(抽取磁盘上的数据文件)
之前研究过dul和odu,发现不能识别磁盘,当时犯了一个错误,因为普通环境(非exadata环境),都是在主机上运行扫描磁盘的工作,因此我之前也在exadata的主机上扫描磁盘,发现不行,具体参见: 在Exadata上,为什么 DUL 和 ODU不能读取ASM数据库的数据,但是Kfed却可以? 今天在exadata的存储节点(cell节点)上配置了一下,发现dul和odu都可以直接扫描磁盘,以后有exadata上oracle数据库损坏时,请联系我,O(∩_∩)O哈哈 具体测试如下: 这里我使用control+C终止了,因为磁盘太大了,扫描时间太久,上面的信息已经可以证明,至少可以扫描 至于normal external等其他问题,以后再说。 扫描文件具体如下: 这里 IDX_DATA1.dat 就是dul扫描出来的一些信息,之后使用命令抽成文件就依据这些。 再看看ODU: 这里报错是因为cell上磁盘空间很小,稍微一折腾就满了(存放ODU抽取文件的是根,100%了): 先别急删除,进去看看数据; 可以看到,odu也抽出了数据, 并且,可以看到,已经抽取了几个dbf的数据文件。
[FAQ]-使用duplicate克隆数据库
帮一个朋友整理的,顺便发到blog。 . 使用duplicate克隆数据库: 将宝宝数据库科隆为Lunar数据库 这部分东西不是新东西,clone在8i就是可以手工做的,在9i还是10g(忘记了),就被封装成duplicat命令了。 之前的测试参见无所不能的duplicate–克隆数据库 . 不过一般我更喜欢手工用rman做,每一步都透明,每一步都可控可回退可追查可修改。 duplicate自动化了,但是出问题后就是整体全部重来,万一有问题,比较耽误时间。 具体步骤如下: 在备库创建目录: 宝宝数据库的参数文件: Lunar数据库使用的参数文件: 创建监听: 创建tnsnames.ora文件 重启监听 测试连接: 创建口令文件: 开始duplicate: 克隆完成,创建临时文件:
[FAQ]-使用rman备份做同机克隆和异机恢复
帮一个朋友整理的,顺便发到blog。 . 数据库克隆操作文档 一.前提说明: 1. 本测试是在同一台机器上完成,而在同一台机器中ORACLE_SID不可相同,所以涉及到克隆库修改ORACLE_SID问题 2. 为了使得本次操作能够更好的让客户了解其过程,使用了传统的rman备份来实现,而没有使用duplicate相关命令实现 3. 如果在不同机器上使用rman备份做异机恢复,就不用修改SID,保持跟以前一样就可以(步骤差不多,比同机克隆更简单) . 二.整体思路: 1. 关闭lunar 2,使用pfile.lunar.bak(DB_NAME=lunar)nomount database 3,恢复控制文件 4,恢复数据文件(SET NEWNAME) 5,shutdown abort(lunar) 6,export ORACLE_SID=lunar 7,使用pfile.lunar.bak(DB_NAME=lunar)nomount database 8,重建控制文件(SET DATABASE “lunar”) 9,catalog start with 10,recover database 11,alter database open resetlogs . 三.详细步骤 1,备份数据库lunar … 继续阅读
ADG备库由于控制文件,归档损坏等原因,不能switchover,failover和active standby database时
昨天损坏的备库,今天准备激活,然后做升级测试。 备库由于归档损坏,已经不能用常规手段switchover和failover,甚至直接激活也不能: 重启数据库后,重建控制文件,然后open resetlogs: 激活数据库: 最后在备库添加temp文件:
oracle一些块损坏和常见数据库损坏的相关概念和处理
最近帮朋友做了一个公开课(大概2小时吧),大概介绍了一下oracle一些块损坏和常见数据库损坏的相关概念和处理。 这里谈到的东西很少,很多内容细讲都是一门学问,我这里介绍的只是大概的概念,冰山一角。对于oracle大牛们来说,不算是什么,O(∩_∩)O哈哈~ 下周打算给公司的同事们介绍一下。 目前pdf可以下载了Oracle常见错误处理-lunar 后续朋友整理好录音等东西,也会上传到这里,与你共勉,请多指教 :)。 本次公开交流的内容已经放到优酷了:
ORA-00704 ORA-00604 ORA-01502: index ‘SYS.I_ACCESS1’ or partition of such index is in unusable state
如何处理下面的错误? ORA-00704 ORA-00604 ORA-01502: index ‘SYS.I_ACCESS1’ or partition of such index is in unusable state 方法跟ORA-00704 ORA-00604 ORA-01502 SYS.I_DEPENDENCY1损坏或者不可用的是一样的,这里不赘述,简单模拟损坏并修复的过程如下: I_DEPENDENCY2损坏的处理 11.2中I_DEPENDENCY1损坏的处理 例如: 相应的trace如下: 解决问题: 然后将数据库启动到限制模式,rebuild该index:
I_DEPENDENCY2损坏的处理
我们知道,在10.2中如果SYS.I_DEPENDENCY1损坏或者不可用时,数据库open时就会报如下类似错误: 10g中I_DEPENDENCY1损坏的处理 11.2中I_DEPENDENCY1损坏的处理 那么如果I_DEPENDENCY2有问题时,什么结果呢? 我们还是在10.2.0.1中测试: 测试结果,数据库可以正常open,但是alert后报错,显示如下: 修复的方法很简单,直接将该索引的状态设置为失效,然后rebuild,具体操作,参考ORA-00704 ORA-00604 ORA-01502 SYS.I_DEPENDENCY1损坏或者不可用
11.2中I_DEPENDENCY1损坏的处理
上一篇,我们测试了10.2中,i_dependency1失效的过程和处理方法。 参考10g中I_DEPENDENCY1损坏的处理 I_DEPENDENCY2损坏的处理 这里,我们在11.2中模拟i_dependency1失效(测试环境使用11.2.0.3): 11.2中:先看一下,数据库中跟依赖关系相关的表都有哪些: 可以看到,10g是18个,11.2是24个。 10g和11g中,DEPENDENCY$表都存在两个索引,这两个索引损坏时对数据库的影响是不同的,他们分别定义如下: 他们存储在哪些block中: 10g和11g的DEPENDENCY$ 和 I_DEPENDENCY1、I_DEPENDENCY2定义都一致的,只是处理方法不同。 现在我们在11.2.0.3模拟i_dependency1失效,看看什么效果: 相应的alert.log信息如下: 说明已经标示 SYS.I_DEPENDENCY1 为无效了。 现在启动数据库看看: 没错,就是这个结果,从11.2开始,类似I_DEPENDENCY1这样的index的失效不会数据库不能open了。 而在10.2中,需要open upgrade模式。 现在修复这个索引: 注意 :11.2跟10.2还有一个小区别(感觉无关紧要):11.2多取了一个字段“type#”: 那么11.2为什么可以直接open呢? 首先,我们来看一下,当 I_DEPENDENCY1 正常时,数据库open的相关动作: 该语句执行7次,七次的执行计划都是上面这样的。 当I_DEPENDENCY1为UNUSABLE时,该语句仍然执行7次,但是7次的执行计划都类似下面的,走“TABLE ACCESS FULL DEPENDENCY$”。 这说明oracle 11.2的二进制代码多了一个判断的功能,当发现I_DEPENDENCY1为UNUSABLE时自动修改了执行计划(没有验证其他类似索引是否都是这样的): 推测:11.2的代码里面写死了一个判断当open数据库时,如果遇到类似DEPENDENCY$这样的表的索引失效了,那么直接对DEPENDENCY$进行全表扫描。
ORA-00704 ORA-00604 ORA-01502 SYS.I_DEPENDENCY1损坏或者不可用
有朋友问起ORA-00704 ORA-00604 ORA-01502: index ‘SYS.I_DEPENDENCY1’ or partition of such index is in unusable state错误怎么处理。 11.2中I_DEPENDENCY1损坏的处理 I_DEPENDENCY2损坏的处理 当SYS.I_DEPENDENCY1损坏或者不可用时,就会报如下类似错误: 首先说一下,10g中的处理方式,有两种: 1,直接在10g中修复 2,使用11.2将数据库拉起来到upgrade模式,然后修复 先看一下,数据库中跟依赖关系相关的表都有哪些: 这里,我们关心的是DEPENDENCY$的索引信息,可以看到,DEPENDENCY$表存在两个索引。 这两个索引损坏时对数据库的影响是不同的,他们分别定义如下: 9i、10g、11.1以前,一些核心对象的定义就在$ORACLE_HOME/rdbms/admin/sql.bsq中。 比如tab$,obj$,ind$等等的定义都在其中。 从11.2开始,创建一些重要的核心基表的脚本仍然是sql.bsq,但是已经将各种对象的创建分类到不同的脚本: dependency$,i_dependency1和i_dependency1的定义如下(10.2和11.2没有区别): 下面我们看一下他们使用了哪些block: 下面我们在10.2总模拟i_dependency1失效(测试环境使用10.2.0.1): 执行alter index i_dependency1 unusable后,alert.log的信息如下: ind$的flags字段的定义(该定义可以查询基表定义,10.2中在sql.bsq,11.1以后,在dcore.bsq): 通过对比,可以发现实际上对于ind$.flags的定义并没有改变,只是内部操作有所变化。 这些标示很有用,比如orcacle 9204有监控SYS的XXX索引的bug会导致数据库不能open,可以通过这个标示来修复。 再比如,10g以前online 创建索引中断后很麻烦,也可以通过修改这个来修复。 10.2以后可以通过dbms_repair.online_index_clean来清理索引状态。不过该功能没有记录在10.2的官方文档中(但是用desc … 继续阅读