月归档:2015 年五月

收集ASM信息的脚本

当ASM中某些磁盘状态异常,比如应该是“MEMBER”的,却是“CANDIDATE”或者其他等各种盘头异常,或者ASM实例异常,可以使用下面脚本收集ASM信息(来源于MOS)

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

使用dd备份和恢复ASM中的数据文件头

今天看了飞总微博上的备份ASM中数据文件头(http://www.xifenfei.com/5888.html),觉得有意思 佩服飞总专业的钻研精神,那么多X$的internal视图……O(∩_∩)O哈哈~ 这里用大家随处可见的(除了extent分布的x$kffxp需要百度和google外),其余都是文档中有详细记载的常用ASM视图来实现同样功能:

发表在 ASM | 标签为 , | 一条评论

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 | 标签为 , | 留下评论

Exadata X5-2数据库服务器上跟换内存条的测试

今天系统组的同事测试了一下Exadata X5-2数据库服务器上的内存能识别的种类 因为目前公司富裕的内存条只有“Hynix Semiconductor” DDR4 16GB的,因此,就测试的这个,结果是可以识别,没有问题。 这个也在情理之中,因为Exadata的cell节点上也用这款内存条: 上面的另一款samsung的就是比较标准的高端内存条了,不过16GB的,网上查了不贵,1k~2k RMB,但是貌似32GB的DDR4 SAMSUNG的很少见…… . 这里我同事把服务器上原有的8跟32GB samsung DDR4 2133内存条换掉,插入了12根Hynix Semiconductor的DDR4 16GB和 4根samsung DDR4 16GB内存条,结果服务器识别没问题: 顺便说一下cell节点的内存设备信息: 存储节点上使用的内存条种类:

发表在 安装和升级 | 标签为 , | 留下评论

Exadata X5-2服务器上扩内存或者更换内存的详细步骤

Exadata X5-2服务器上扩内存或者更换内存的paper研究 Exadata上服务器内存条的使用限制: 1, 服务器支持3种类型的内存条: (1)32-GB quad-rank (QR) Load-Reduced DIMMs (LRDIMMs) (2)8-GB single-rank (SR) 或者16-GB dual-rank (DR) Registered DIMMs (RDIMMs) 2,不能混用前面两种,即要么都是32-GB quad-rank (QR) Load-Reduced DIMMs (LRDIMMs),要么都是 8-GB single-rank (SR) 或者16-GB dual-rank (DR) Registered DIMMs (RDIMMs) 3,根据文档,更换内存条的过程是:Within a memory channel, DIMMs … 继续阅读

发表在 安装和升级 | 标签为 , , | 留下评论

Exadata X5-2服务器上扩内存或者更换内存的paper研究

根据Oracle白皮书的记录,Oracle Sun Server X5-2数据库服务器的配置如下: 注意上面: 256GB DDR4-2133 RAM (8x 32GB DIMMS; Memory Expansion kit provides up to 24x 32GB DIMMS in groups of 8) 也就是每台数据库服务器出厂缺省配置是256GB内存(8个32GB DIMM,具体型号是 DDR4-2133 RAM),可以扩展到最大24*32=768GB LRDIMM是较新一代的内存设备,能够保证即使在单条内存32GB容量甚至更高的情况下,服务器上每个内存通道依然能够布满至3条内存条 这里的8组(P0:CHA,CHB,CHC,CHD P1:CHA,CHB,CHC,CHD),也就是每组上面可以最多插入3根内存条,因此一共可插入24跟内存条,每个内存条32GB 具体如下图: 在服务器上如何查看当前内存的使用情况呢: 当前已经插入的内存条有8根,每根都是32GB:32*8=256GB 服务器上每个CPU支持的一对内存模块最多内存容量为192GB(6*32GB): 服务器上每个CPU支持的一对内存模块最多内存插槽为6个: 24*32=768GB,也就是当前系统最大可以插入24根32GB的内存条,也就是最多支持768GB内存: 内存频率是2133: 全部内存信息如下: 具体更换步骤参见 … 继续阅读

发表在 安装和升级 | 标签为 , , | 留下评论

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

11.2单机数据库转换为RAC-2-手工方式(与9i,10g,11.1的方法一样)

单机数据库转换为RAC,方法很多,前面的已经讲过使用rconfig的方法(11.2以后Oracle推荐的方法)。 但是我还是喜欢手工转换,感觉还是简单省事的,整个过程15分钟左右(主要是启动和关闭数据库的时间): 首先将单机数据库的pfile修改为RAC的pfile,具体如下: 然后使用这个pfile启动数据库: 然后添加thread 2的redo log group: 创建thread 2使用的UNDO TABLESPACE: 然后enable这个thread 2: 最后,执行创建RAC的一些必要试图的脚本: @?/rdbms/admin/catclust.sql 有些人说这个可以不执行,也有很多GV$的视图,但是实际上这个脚本是必须执行的,否则会缺少一部分GI需要视图 比如V$BH等等,具体可以查看catclust.sql脚本 都做完以后,就可以启动数据库了: 这里看到已经是RAC数据库了,RAC中最好使用spfile文件,因此我们也创建spfile,例如: 然后把这数据库加入到CRS,就可以由CRS来管理了:

发表在 RAC | 留下评论

11.2单机数据库转换为RAC-1-使用rconfig完成转换

将单机数据库转换为RAC数据库,有好几种方法: 1,使用DBCA 2,手工添加thread(这个方法最经典,从9i到10g,到11.1,到11.2都可以,不过11.2以后,Oracle不推荐使用这个方法) 3,使用rconfig 4,ODA上有专门的工具进行转换,号称无敌脚本,O(∩_∩)O哈哈~(本次我没有测试,因为上面的方法已经足够多选择了) . rconfig功能还是比较强大的,除了单机转换为RAC,还可以单机转换为Standalone,Standalone转换为RAC,RAC转换为Standalone等等。 . 这里我们使用Oracle 11.2推荐的方法,体验一下rconfig的强大之处。 首先,我们要从一个单机数据库备份,然后恢复到到RAC环境中: 然后将这个数据库恢复到已经安装了GI的环境中,就是普通的将数据文件恢复到ASM的操作,没什么难度,主要命令如下: . 在ORACLE_HOME下有一个xml脚本,通常我们只需要修改这个脚本,就可以完成转换: 即: $ORACLE_HOME/assistants/rconfig/sampleXMLs/ConvertToRAC_AdminManaged.xml 1,我们先复制一个过来,进行修改: 其中,Convert verify=”ONLY”表示只测试转换过程,不实际转换。 Convert verify=”YES”,表示真实的执行转换。 测试过程这里略过了,我们看一年他是如何转换的。 我这里xml的内容如下: 具体的转换过程如下: 从这里我们清晰的看到,rconfig进行转换的时候,主要执行了如下步骤: 转换结果如下,lunar数据库已经是RAC数据库了,且已经在两个节点都启动了: 但是我个人并不喜欢rconfig的操作,原因是,他要进行backup as copy database的操作。 那么,就意味着,如果数据库巨大的话,需要的空间也会是双倍的 但是用传统的方法,手工添加第二个实例就不会有这个需求,比如我的数据库30T,怎么弄?

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