一次异常断电，导致的controlfile损坏（checkpoint_change#不一致）。问题的分析与处理。
很多人经常喜欢下载一个漏洞扫描硬件，这扫扫，那扫扫，自然也扫出很多“高危漏洞”。看到这些高危漏洞，你是不是有点小紧张呢？那么看完这篇文章，你会了解这Oracle patch的原理，也就豁然了。 而事实上，漏洞扫描软件，也真的没有做到高大上的功能，它们并没有技术能力发现Oracle软件自身的漏洞。很多漏洞都是在一些黑客攻击之后，Oracle原厂自行修复，并提供相应的补丁来防止相关风险的发生。很多扫描软件，不但没有做到高大上，在Oracle漏洞方面，做的却非常业余。
性能分析过程中，经常会遇到生产库出现SQL的性能问题，但是，我们没有办法在生产库上做很多动作，需要将这个SQL的对应的表结构信息，统计信息导入到测试库进行测试（没有真实的测试数据，只有统计信息）
近日遇到一个RAC节点hang导致节点被重启的问题，最后经过分析，发现在系统运行一段时间后，系统内存就会耗尽，原本256G的内存，最后只剩几百M。 最后，查看meminfo，发现了问题，PageTables占用了168G的内存, 加上SGA和PGA的使用，刚刚好250G左右。 PageTables是内存表，是不共享的，在内存很大的情况下，如果很大process访问内存的话，就会每个process都copy一份PageTables，最终导致大量内存自耗的情况
1. 近日遇到一个小问题，在standby上连接controlfile进行全库备份，备份完成后，通过list bakcup，查询到的数据文件路径是“u01/data/****” 2. 但是在连接到catalog，并sync之后，发现数据文件的路径变成“+DATA/ora10g/datafile/***”， 这是Primary数据库的实际路径。 3. 为什么会发生这种情况呢？ 这个问题是由于Standby数据库创建过程中，standby没有使用和primary相同的ASM存储，及ASM路径，而是使用的文件系统存放datafile。 这会涉及到db_file_name_convert和log_file_name_convert两个参数。
在RMAN中手动配置一条信息，但是由于笔误，错误的增加一行 CONFIGURE信息 但是希望删除的过程，遇到了问题，通过各种clear的方式，都不能成功删除，最后通过重建控制文件解决。
错误ORA-15031的提示，还是很明显的，无法识别对应的voting磁盘，正常解决思路，就是检查磁盘是否正常挂载，权限是否正确等，需要逐项检查。
近日，连续收到ASM磁盘dismount，并且是错误“Waited 15 secs for write IO to PST”的问题，这是ASM特有的心跳超时检测，ASM instance会定期检查每个asm disk是不是能正常反馈。所以决定针对这个问题，做个小总结。
最近连续有客户问我，如果修改SSH，会对oracle RAC有什么影响。这个问题，我也看过资料，对oracle RAC的运行是没有影响的，但是“说”是没有力度的。今天正好相对比较空闲，全程针对SSH进行测试，并将测试过程记录下来，与大家分享一下。
由于多个客户几次问到，RAC环境中，node2的归档日志，写入到node1的archive路径中。 这个问题导致一些客户在使用OGG的情况下，有时无法正确读取日志的问题。 那是什么原因导致的这个问题呢？
近日遇到错误ORA-00600 [kjctr_pbmsg:badbmsg2]，并且导致RAC节点实例重启 ORA-00600: internal error code, arguments: [kjctr_pbmsg:badbmsg2], [0x9FFFFFFFFC996B58], [0x9FFFFFFFFC9976B8] LMS1 (ospid: 12379): terminating the instance due to error 484
oracle提供一个参数ASM_PREFERRED_READ_FAILURE_GROUPS，来实现ASM优先读取的功能，是以FAILURE_GROUP为单位实现的。 所以，我们可以将不同性能的存储（磁盘），分别划分到不同的FAILURE_GROUP，然后根据这个参数来指定优先读取哪个FAILURE_GROUP
OSwatcher作为Oracle官方推荐的OS层面运行状态检测的脚本工具。在Exadata是默认已经安装。 但是Exadata是如何在系统启动后，自动启动OSwatcher呢？我们如何去修改OSwatcher的参数，来调整监控和日志保存的策略呢？ 本文正是介绍，从系统启动到OSwatcher运行，中间经历过的脚本调用，以及如何修改OSwatcher参数的。
在同一个主机上，搭建dataguard，在最后执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;时，主库直接挂掉，报错是redo log损坏。
近日遇到一个问题，就是ASM diskgroup无法挂载，通过分析之后，发现有会快存在，但是由于没有备份，没有办法重建diskgroup并从backup恢复--所以所以所以....备份很重要啊！不然，哭！！是早晚的事情！
近日在Exadata VM上测试IORM，发现CELL的磁盘空间不够了，没有办法，自己给CELL添加新磁盘，并创建新的Lun,celldisk和griddisk.
在日常维护中，如果涉足一些需要重启cell的操作，我们如何能在不影响业务的情况下进行这个操作呢，这里有分以下几步来完成。
Exadata关于磁盘部分，新增加了lun，celldisk，griddisk的概念. 由于遇到一个问题，在物理硬盘添加后，没有自动创建celldisk及griddisk，所以这里做了一个实验，并记录。 我主要记录了在一个正在运行的Exadata机器， 它的一个磁盘正常删除并添加的完整过程。
关于Hugepages的设置方法和相关概念已经在“原理概念篇”介绍完成，下面我会针对几种情况进行测试，并分析测试结果。
而在Linux中，内存都是以页的形式划分的，默认情况下每页是4K，这就意味着如果物理内存很大，则映射表的条目将会非常多，会影响CPU的检索效率。因为内存大小是固定的，为了减少映射表的条目，可采取的办法只有增加页的尺寸，这时Hugepages就是一个很好的技术选择。
DBFS是oracle Exadata提供的一种的集群文件系统，他是通过创建一个表空间，并将该表空间通过一系列操作，挂载成为文件系统，为Exadata各个节点提供文件系统服务。
近日遇到Exadata 的磁盘故障，在更新完physical disk后，其中一个griddisk没有自动添加的到ASM实例中,在问题解决后，整理出整个问题分析的思路。
近日入到一个RAC问题，一个节点无法启动，经过分析后解决，解决过程如下。
重建控制文件时DBA需要知道，但是也许整个职业生涯都不会再生产系统上遇见。 首先强调，备份是最安全，快捷，有效的恢复方式，一个DBA，如果没有规划好有效的备份，终有一天，他会被噩梦惊醒。
oracle数据库特种恢复技术（二）—块内篇链接：http://www.itpub.net/thread-1507766-1-1.html oracle数据库特种恢复技术（三）—转换篇链接：http://www.itpub.net/thread-1507774-1-1.html Oracle数据库特种恢复技术（四）—实验篇链接：http://www.itpu
asm
按照OracleDocument中的描述，v$sysstat存储自数据库实例运行那刻起就开始累计全实例(instance-wide)的资源使用情况。
oracle执行计划解释 相关详细内容
ORION (Oracle I/O Calibration Tool) 是校准用于 Oracle 数据库的存储系统 I/O 性能的独立工具。校准结果对于了解存储系统的性能有很大帮助，不仅可以找出影响 Oracle 数据库性能的问题，还能测量新数据库安装的大小。由于 ORION 是一个独立工具，用户不需要创建和运行 Oracle 数据库。
发现其中 OCR does not have any global interfaces set 这个提示。于是我怀疑是他的网络设置问题。
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
