一次异常断电,导致的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号