分类目录归档:Database

使用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的数据文件。

发表在 ASM, backup&recovery, DUL ODU, Exadata | 标签为 , , , | 留下评论

ORA-00604和ORA-04024错误的处理方法

一般Oracle的bootstrap index(引导表的索引和一些核心对象)都可以尝试类似方法处理,比如下面查询语句中的I_OBJxxxxx。 . 测试环境 11.2.0.3数据库: 在数据库中长开启时,不能操作一些bootstrap index,例如: 有些bootstrap索引在upgrade模式下也不可以修改,有些可以: 可以启动到升级模式,这模式数据库会自动增加一些类似屏蔽system trigger等的操作 可以执行部分bootstrage对象的操作,例如: 升级模式自动添加的参数如下: 此时,数据字典因为遭到破坏,很多相关查询等功能都失效了: 且启动时会报错ORA-00604 ORA-04024: 正常关闭数据库也关闭不了,应该是需要执行某些核心递归SQL时遇到问题了,只能shutdown abort: 然后以升级模式启动数据库,修复这些索引:. 执行迷你升级脚本进行修复: 这里我们看到SYS.I_OBJ#_INTCOL#索引为unusable,不能在升级模式下被修复 但是,10g以后,这个索引是可以通过event 38003屏蔽的: 这里我们已经修复了损坏的索引。 在此基础上,我们重新执行迷你升级脚本: 然后正常启动数据库: 删除第一次执行迷你升级脚本因为异常而中断残留在数据库中的临时索引: 至此,完美恢复!

发表在 ORA-600 or ORA-7445 | 标签为 , | 留下评论

SPA(SQL性能分析器)的使用-2-Unpack STS和生成SPA Report

SPA(SQL性能分析器)的使用-1-收集和迁移SQL Tuning Set SPA(SQL性能分析器)的使用-2-Unpack STS和生成SPA Report 1,查看当前STS中的SQL数量: 删除一些没用的: 2,在新库创建Lunar_11201STS_LUNAR SQLSET集 —(2)使用LUNAR用户,创建STS:Lunar_11204STS_LUNAR —(2)使用LUNARSPA用户,将源库的LUNAR.Lunar_11201STS_LUNAR的SQL优化器映射到LUNARSPA.Lunar_11204STS_LUNAR 使用LUNARSPA用户执行remap: 至此,SPA在新库的数据已经准备完毕,可以开始生成SPA报告了。 常见报告的就提步骤如下: 1)创建SPA任务 2)生成11.2.0.1的SPA Trail,采用STS转化方式 5 执行比较任务(一般取Elapsed Time、CPU Time、Buffer Get等指标) 6 生成SPA报告 生成的报告一般如下:

发表在 Performence Tuning | 留下评论

SPA(SQL性能分析器)的使用-1-收集和迁移SQL Tuning Set

SPA(SQL性能分析器)的使用-1-收集和迁移SQL Tuning Set SPA(SQL性能分析器)的使用-2-Unpack STS和生成SPA Report . SPA(SQL Performance Analyzer , SQL 性能分析器),是11g引入的新功能,主要用于预测潜在的更改对 SQL 查询工作量的性能影响。 一般有几种情况下,我们会建议做SPA: 1,OS版本发生变化 2,硬件发生变化 3,数据库版本的升级 4,实施某些优化建议 5, 收集统计信息 6,更改数据库参数 等等 . SPA的主要实施步骤如下: 1, 在生产系统上捕捉SQL负载,并生成SQL Tuning Set; 2, 创建一个中转表,将SQL Tuning Set导入到中转表,导出中转表并传输到测试库; 3, 导入中转表,并解压中转表的数据到SQL Tuning Set; 4, 创建SPA任务,先生成10g的trail,然后在11g中再生成11g的trail; … 继续阅读

发表在 Performence Tuning | 标签为 | Comments Off on SPA(SQL性能分析器)的使用-1-收集和迁移SQL Tuning Set

数据库升级和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功能是否已经被禁用,如果没有,麻利儿禁用它 … 继续阅读

发表在 Database | 标签为 | 留下评论

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也修改了:

发表在 network, troubleshoooting | 标签为 | 留下评论

ORA-00600[kfioTranslateIO03] 和ORA-00600[17090]的解决

今天玩VM,发现数据库不能启动了: 检查alert日志,报错如下: 很久没玩这个VM,隐约记得上次好像测试修改权限了 然后,根据报错查询官网: ORA-00600: internal error code, arguments: [kfioTranslateIO03], [], [], [], [], [], [], [], [], [], [], [] 果然是权限问题,因此检查相关权限并修改。 使用root: 现在启动数据库就不报错了:

发表在 ORA-600 or ORA-7445 | 标签为 , | 留下评论

配置Exadata上的万兆模块和测试万兆

Exadata上配置万兆非常简单,就是设置一下网卡,然后绑定即可 根据文档描述,万兆光口对应的接口如下: Exadata Database Machine X5-2的eth4和eth5 不同的机器,可能接口名称不同,可以在机器上看,也可以核对文档来识别。 . (1)Exadata上,有两个光口,是千兆万兆自适应的,但是10Gib模块需要单独购买。 (2)Exadata上,4个电口是百兆,千兆,万兆自适应的 下面的是一个例子: 例如,电口的eth0(用于连接内置的Cisco): 连接了万兆的eth4: 然后设置一下IP,按照linux上绑定网卡的方法将eth4和eth5绑定即可。 万兆配置好了,测试了一下万兆的效率(还没时间做测试跨机房): 下载了iperf安装在exadata上: 测试了一下,每秒基本上可以达到7Gb(大概7Gb/8≈700MB/s):

发表在 Database | 标签为 , , | 留下评论

Exadata上精彩的硬件告警(准确的说,应该是SUN ILOM的)

昨天Exadata上发出了一封靓丽的告警邮件,如下图: 没见过这么漂亮的邮件,清晰的告诉你是什么部件(可惜我还不认识那个大大的就是CPU……汗……) 又惊又喜的傻Lunar以为硬件坏了,高兴的是,SUN的ILOM的告警做的真棒啊 但是奇怪的是才用了没多久啊,而且比较爱惜的,怎么回事? 后来,在oracle官网搜索这个硬件, 发现是CPU边上的一个部件,貌似PCIe“故障”了。系统组的同事log了SR,等待回复。 晚上回家,按照以往的管理,我也到ILOM上搜索了一下,然后按照官方文档收集了ILOM的snapshot和一些必要信息传到SR上,SR的回复我没看懂: ” 也就是说,33%的可能是是硬件损坏…… 在oracle官网找到如下方法判断,下面的输出是ILOM 3.2以上的输出(老版本的输出本文后面有例子) 收集的信息,跟SR上老外的回复差不多,也是每个部件都有33%的可能性是硬件损坏…… 按照以往的理解,猜测是“先兆损坏”,通常这种情况,工程师可能会把硬件进行一次插拔,如果没问题就算了,如果有问题,可能就是硬件损坏。 于是又到ILOM上检查,什么硬件,根据文档说明和ILOM的指示,大概知道是什么东西了(虽然每个东西长什么样子,我没见过……基本上从毕业后就没有拆过机箱,摸过螺丝的Lunar感觉很无奈……): . /SYS/MB ————-这个表示是主板 /SYS/MB/P0 ————这个表示是CPU /SYS/MB/RISER2/PCIE2 ———-这个就是文档中说的那个拗口的“PCIe 竖隔板”,2表示槽位2 . 找到硬件工程师问了一下,这个问题是因为我们插入万兆模块的时候,报的告警,不过奇怪的是为什么oracle文档中没有写明“更换万兆模块需要关机?” 行了,知道了不是硬件问题,clear即可,这个文档上有,照做即可: 检查清除结果: 顺便介绍一下老版本的ILOM输出(ILOM 3.2以前): —举例1: 输出类似 FRU : /SYS/FANBD/FM0,这个就指出了损坏的FRU是具体对应到主机上的哪一个物理组件(full physical path) —“/SYS” 底架(chassis),我理解可能是主机架,就是拆开挡板后,所有东西都插在上面的那个主机箱的含义。 —“FANBD” 风扇模块 (fan … 继续阅读

发表在 Database | 标签为 , , , , | 留下评论

[FAQ]-使用duplicate克隆数据库

帮一个朋友整理的,顺便发到blog。 . 使用duplicate克隆数据库: 将宝宝数据库科隆为Lunar数据库 这部分东西不是新东西,clone在8i就是可以手工做的,在9i还是10g(忘记了),就被封装成duplicat命令了。 之前的测试参见无所不能的duplicate–克隆数据库 . 不过一般我更喜欢手工用rman做,每一步都透明,每一步都可控可回退可追查可修改。 duplicate自动化了,但是出问题后就是整体全部重来,万一有问题,比较耽误时间。 具体步骤如下: 在备库创建目录: 宝宝数据库的参数文件: Lunar数据库使用的参数文件: 创建监听: 创建tnsnames.ora文件 重启监听 测试连接: 创建口令文件: 开始duplicate: 克隆完成,创建临时文件:

发表在 backup&recovery | 标签为 , | 一条评论