数据库由于异常宕机导致故障,重启后无法正常运行,出现ORA-00600 6008错误,数据库Open之后,很快会Crash。6008错误通常出现在索引块上。 用户数据库定期做了逻辑备份,但是在这样的时候,并不认可通过逻辑备份的恢复,因为会损失较多数据。值得我们借鉴的是,逻辑备份绝对不能作为唯一的数据库备份手段,这是相当危险的。
昨天,一个客户的数据库系统出现故障,RAC无法启动,大量的错误信息,经过分析检查,最后我们通过强制手段打开数据库,帮助用户挽回了数据损失。
在很多错误信息或提示中,总能看到KKS的身影,可是没有文档表明其具体含义。 我在这里整理收集一下能够读到的文档信息: KKS层的代码管理是 kks.c 文件,其含义为Kernel Kompile Shared (cursors).
这里边说出了我最近的一些想法,做技术的很容易陷入墨守的成规之中,而我真诚的喜爱变化,从变化中寻找机会,这就是我想说的。
在客户系统中,由于空间问题,想要将expdp的逻辑导出文件存储到ASM磁盘组中。 经过测试,expdp导出文件完全可以放在ASM磁盘组中,但是日志文件需要放在文件系统上。
今天接收到一则Oracle 8i的数据库故障,恢复数据过程并不特别复杂,只是Oracle 8i的东西基本上快忘的差不多了。 数据库是在一个ORA-1631错误持续报出后出现的问题, Oracle的一个数据对象的最大区数量超过,数据段将无法扩展。
不清楚为何一次简单的断电导致了如此严重的后果,庆幸的是,客户有一份及时的备份,通过备份和归档日志,成功的恢复了数据库。 有备份,一切很简单。
在Oracle Database 11gR2 中,asmcmd有了大量的改进和增强,即使11.2.0.2和11.2.0.1比较,也有很多不同。 在ASM元数据的备份与恢复方面,Oracle增加了两个命令:md_backup 和md_restore。 md 是metadata的缩写,这一工具极大的简化了ASM的元数据维护。
在Oracle数据库中,不同平台上存在的种种限制,可能导致数据库异常,我认为这是Oracle数据库的不足,这些确定性的约束,应当在软件中体现出来,并且应当能够进行一定程度的避免,当然可能要 付出一点代价。 在客户的Windows 2000 Server + Oracle 8.1.7 环境中,遭遇到文件越界( > 16G ),导致读写失败的案例。
前一段时间,在帮助用户恢复一个数据库时,用到了_smon_internal_errlimit参数。 客户数据库遭受存储损坏无法打开,数据文件存在大量坏块,我们强制打开数据库后遇到了如下错误
X$KTUXE是数据库中非常神秘的一个对象表,当然其本质上是C定义的一个结构体,在数据库中可以看到其结构
我们知道,从Oracle 9i开始,Shared Pool可以被分割为多个子缓冲池(SubPool)进行管理,以提高并发性,减少竞争。 Shared Pool的每个SubPool可以被看作是一个Mini Shared Pool,拥有自己独立的Free List、内存结构以及LRU List。同时Oracle提供多个Latch对各个子缓冲池进行管理,从而避免单个Latch的竞争(Shared Pool Reserved Area同样进行分割管理)。SubPool最多可以有7个,Shared Pool Latch也从原来的一个增加到现在的7个。如果系统有4个或4个以上的CPU,并且SHARED_POOL_SIZE大于250MB,Oracle可以把Shared Pool分割为多个子缓冲池(SubPool)进行管理,在Oracle 9i中,每个SubPool至少为128MB。