关于数据文件头的一些问题

今天忽然想到一个问题,数据库使用裸设备,且一个主机上有2个instance,如果划分lv的时候没有注意名称上的区别,那么在使用的时候,是否会出现一个lv已经分配给了某一个instance,由于instance之间是独立了,裸设备也是不经过os层面,不会锁定的,因此可以把这个lv分配给另一个instance呢?
测试一下,发现oracle还是会报错的:

由于os层面不可能锁定lv,估计是在oracle级能够识别出来这个文件是,把数据文件头dump出来发现,确实在数据文件头有相关的标识表示数据文件已经被某一个数据库使用,在数据文件头已经有了db id的信息:

在这里,我们看到了:
Db ID=264392167=0xfc24de7, Db Name=’TESTDB’
说明这个数据文件归dbid为264392167所有。

另外还有一个比较有意思的现象:rdata_1g_240是加到数据库中做数据文件的,rdata_1g_237是尚未加入到数据库中的裸设备,由于一次错误的操作,在数据库open的状态下,将rdata_1g_237 dd到了rdata_1g_240,但是这个时候还能在rdata_1g_240的表空间上面建表,insert数据,数据库没有挂,这是怎么回事呢?

其实这也是数据文件头的关系,此时我create表,insert数据,commit,甚至flush buffer cache,但是都不会有任何报错,也就是说,写数据写入到数据文件,还是可以的。

但是一旦做checkpoint,就直接当数据库了,因为做checkpoint,会检查其数据文件头的情况,此时会发现数据文件头已经被破坏。

注意上面的error字段为WRONG FILE TYPE,正常的应该为YES。

要解决这个问题,只能startup mount,在对被破坏的数据文件offline drop,再open数据库后,drop tablespace。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据