作者归档：Lunar

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

发表于 2015 年 5 月 8 日 由 Lunar

一般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数据库服务器上跟换内存条的测试

发表于 2015 年 5 月 8 日 由 Lunar

今天系统组的同事测试了一下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服务器上扩内存或者更换内存的详细步骤

发表于 2015 年 5 月 8 日 由 Lunar

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研究

发表于 2015 年 5 月 8 日 由 Lunar

根据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

发表于 2015 年 5 月 5 日 由 Lunar

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

发表于 2015 年 5 月 5 日 由 Lunar

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的方法一样）

发表于 2015 年 5 月 4 日 由 Lunar

单机数据库转换为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完成转换

发表于 2015 年 5 月 4 日 由 Lunar

将单机数据库转换为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 | 标签为 , | 留下评论

数据库升级和DDL trigger

发表于 2015 年 5 月 3 日 由 Lunar

升级数据库时，比如从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

发表于 2015 年 5 月 2 日 由 Lunar

今天测试数据库的时候，忽然发现使用远程连接的方式会报错： 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 | 标签为 | 留下评论