案例：12cr1启用bct的情况下增量备份有时会很慢

发表于2021年10月24日由lixiangyu

该案例来自某银行客户exadata x7，12.1.0.2的数据库版本，客户备份策略为每周1次0级备份，6次增量备份，增量备份的完成时间不稳定，有时会很慢很慢。

首先非常怀疑BCT并没有生效，没生效的原因常见的首先想到的就是数据文件增量备份次数超过了_bct_bitmaps_per_file 继续阅读 →

发表在 Oracle, Oracle troubleshooting | 标签为 | 留下评论

案例：ORA-15096: lost disk write detected

发表于2021年10月22日由lixiangyu

案例背景：4节点extend rac，存储raid 5校验异常，修复之后SOLDATA磁盘组无法mount，报错ORA-15096: lost disk write detected。 继续阅读 →

发表在 Oracle, Oracle Recover | 留下评论

案例：一则非常巧合的ORA-15042恢复

发表于2021年10月21日由lixiangyu

今天跟大家分享一个ASM磁盘组损坏的案例，此案例来至于一个网友。由于是保密客户，不能拿到数据，所以这里只是在自己的环境中模拟此现象并给出解决方案。 继续阅读 →

发表在 Oracle, Oracle Recover | 标签为 , , | 留下评论

ASM Virtually addressed metadata- Continuing Operations Directory

发表于2021年10月21日由lixiangyu

Continuing Operations Directory简称COD，是ASM的4号文件，该文件的作用是记录一些持续性的操作，当操作意外终止时，可以利用COD来实现继续完成或者回滚，如果说ACD是ASM实例的redo的话，那么COD就是ASM实例的undo。
COD的持续性操作类型分为Background operation和Rollback operation。 继续阅读 →

发表在 Oracle, Oracle Recover | 标签为 , , , , | 留下评论

ASM Virtually addressed metadata-Active Change Directory

发表于2021年10月21日由lixiangyu

Active Change Directory简称ACD，是ASM的3号文件，我们都知道redo日志记录了数据文件数据块的每一次原子性变化，而ACD它描述了ASM元数据块每一次原子性变化，可以认为ACD是ASM实例的redo。redo根据database实例分为多个thread，同样ACD根据ASM实例也分为多个thread，每个thread为ACD分配了42个M，假如磁盘组AU为1M，那么thread 1使用0-41号extent，thread 2使用42-83号extent，以此类推 继续阅读 →

发表在 Oracle, Oracle Recover | 标签为 , | 留下评论

ASM Virtually addressed metadata-Disk directory

发表于2021年10月21日由lixiangyu

Disk directory是asm的2号文件，对于磁盘组中的每一个磁盘都有对应的磁盘条目记录该asm磁盘的磁盘号，磁盘状态，磁盘名称，所在failgroup，创建时间，磁盘repair time等等信息，x$kfdsk部分信息来自于Disk directory。可以通过2号文件的File directory去定位Disk directory所在位置 继续阅读 →

发表在 Oracle, Oracle Recover | 标签为 , | 留下评论

ASM Virtually addressed metadata-File Directory

发表于2021年10月21日由lixiangyu

前面一一介绍了Physically addressed metadata，现在来聊聊ASM的Virtually addressed metadata，它与Physically addressed metadata不同，虽然也是元数据，但是是以ASM文件的形式存在，由于ASM条带化的特性，所以Virtually addressed metadata是分布在磁盘组的所有磁盘上的。本小节为大家介绍的是ASM非常重要的元数据–ASM的1号文件(File Directory)，它描述了ASM磁盘中所有ASM文件(包括File Directory自身的所有。 继续阅读 →

发表在 Oracle, Oracle Recover | 标签为 , , | 留下评论

ASM Physically addressed metadata-Partner and Status Table

发表于2021年10月20日由lixiangyu

Partner and Status Table(PST)位于asm磁盘的第二个AU(AU1),也属于Physically addressed metadata，PST对于ASM非常重要，它记录了该磁盘组所有磁盘的磁盘号、磁盘之间的partner关系、failgroup信息、PST心跳信息以及磁盘状态，磁盘的第二个AU(AU1)为PST保留，但并不是磁盘组内的所有磁盘都有PST，磁盘组冗余级别不同，PST的个数也不同，如下： 继续阅读 →

发表在 Oracle, Oracle Recover | 标签为 , | 留下评论

ASM Physically addressed metadata-Free space table和Allocation table

发表于2021年10月20日由lixiangyu

 

Allocation Table(AT)和Free space table(FST)都属于Physically addressed metadata，我们在介绍它们之前，先介绍一下asm磁盘的Stride的概念,每个asm磁盘根据不同的磁盘大小，可以分成多个Stride，Stride的大小定义在磁盘头kfdhdb.mfact(单位AU) 继续阅读 →

发表在 Oracle, Oracle Recover | 标签为 , | 留下评论

ASM Physically addressed metadata-disk header

发表于2021年10月20日由lixiangyu

 

在asm世界里，几乎所有计数都是从0开始，比如磁盘号、AU号、asm块号、file extent号等等。asm磁盘的磁盘头属于Physically addressed metadata，总是位于第一个AU的第一个block上（AU#=0，BLK#=0)。磁盘头记录了该磁盘以及磁盘组的一些基本信息，如：磁盘号、磁盘组名、失败组名、磁盘冗余级别、磁盘头状态等等，除此之外磁盘头还记录了au大小、扇区大小、最小ASM兼容版本和最小数据库兼容版本等磁盘属性，以及一些指向其他重要ASM元数据的指针信息，可以说磁盘头对于asm磁盘来说非常的重要。 继续阅读 →

发表在 Oracle, Oracle Recover | 标签为 , | 留下评论