loan
很久前，自己笔记本上搭建了一套12c的RAC，但是后来一直很少用，占空间很大又舍不得删，前一阵发现起不来了，今天抽空尝试修复一下，结果引发了一系列问(
惨)题(案）。
日志如下：
集群起不来，后台日志中看到 ORA-600[kfrValAcd30]，先用官方的ORA-600工具lookup一下，但是没找到(找不到的概率是95%)。百度一下，大概了解到是磁盘损坏导致的，很可能，因为虚机有时暴力关机。
检查crs状态，执行crsctl stat res -t -init，看到crsd、cssd无法启动，mdns、gipc、gpnp都正常。
手工启动 crsd 试试：
[root@rac2 ~]# crsctl start res ora.crsd -init
CRS-2672: Attempting to start 'ora.crf' on 'rac2'
CRS-2672: Attempting to start 'ora.asm' on 'rac2'
CRS-2676: Start of 'ora.crf' on 'rac2' succeeded
CRS-5017: The resource action "ora.asm start" encountered the following error:
ORA-00600: internal error code, arguments: [kfrValAcd30], [CRS], [1], [90], [2143], [91], [2164], [], [], [], [], []
去mos上搜了一下其他文档，都说是磁盘组损坏，必须重建。
开始科学搜索模式，对于一个全新问题，只能先看看别人经验了，
查了一番，发现解决这个问题需要了解asm底层结构，而且常规办法通常不管用。
自己对asm了解不多，前一阵凑巧自己整坏了一个磁盘，学习了一下kfed这个工具。
反正是测试环境，先kfed read /dev/asmdiskb正常，kfed repair /dev/asmdiskb 还是没解决（因为问题不在asm磁盘头）。
对这个报错不知到底反应了哪方面的问题，仔细看了看报错信息
NOTE: attached to recovery domain 1
Wed Jan 06 08:21:43 2021
NOTE: crash recovery of group CRS will recover thread=1 ckpt=85.784 domain=1 inc#=2 instnum=1
Errors in file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_ora_12129.trc (incident=107409):
ORA-00600: internal error code, arguments: [kfrValAcd30], [
CRS], [1],
[85], [784],
[87], [784], [], [], [], [], []
Incident details in: /u01/app/grid/diag/asm/+asm/+ASM1/incident/incdir_107409/+ASM1_ora_12129_i107409.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
和别人的比对，猜测其中的 CRS 应该是指磁盘组名称（这太简单了吧），既然说是CRS (存放ocr vote的)磁盘组有问题那么利用 CRS 备份恢复，不就得了，于是关闭节点2。
以下 8 步恢复集群磁盘组：
1、ocrconfig -showbackup 找到最新的备份文件
2、crsctl stop crs -f 强制关闭集群
3、dd if=/dev/zero of=/dev/asmdiskb bs=1M count=100 格式化现有的磁盘
4、crsctl start crs -excl -nocrs 启动到独占模式且不打开ocr vote
5、编辑一个pfile
*.asm_diskgroups='OCRNEW', 'DATA'#Manual Mount
*.asm_diskstring='/dev/asm*'
*.asm_power_limit=1
*.diagnostic_dest='/u01/app/12.1.0/grid'
*.instance_type='asm'
*.large_pool_size=12M
*.remote_login_passwordfile='EXCLUSIVE'
保存为/tmp/asm.ora
6、sqlplus / as sysasm
shu immediate
startup pfile='/tmp/asm.ora'
CREATE DISKGROUP crsnew EXTERNAL REDUNDANCY DISK '/dev/asmdiskb' ATTRIBUTE 'compatible.asm'='12.1.0.0.0','au_size'='1M' ;
7、ocrconfig -restore /u01/app/12.1.0/grid/cdata/rac-cluster/backup00.ocr
8、crsctl replace votedisk '+crsnew'
crsctl query css votedisk确认。
但是在第7步没有成功，提示权限不对，检查/etc/oracle/ocr.loc，修改为+ocrnew也不行
总是提示：
[root@rac2 ~]# oerr prot 35
00035, 1, "The configured OCR locations are not accessible"
// *Cause: The configured Oracle Cluster Registry (OCR) locations did not
// exist, were not mounted correctly, did not have the required
// permissions, or did not have sufficient disk space.
// *Action: Ensure that the locations exist, that they are mounted correctly and
// visible to all nodes in the cluster, that their permissions are
// correct, and that they have sufficient disk space. If using an
// Oracle Automatic Storage Management (Oracle ASM) OCR location,
// check for entries in the Oracle ASM alert log file for more
// details.
想想这个测试环境还有个+FRA盘，将其删除作为OCR磁盘组试试，也不行，修改ocr.loc，将其指定到+DATA上仍然不行，打算要放弃了。
再看看别人的文章，尝试读取磁盘信息，kfed read /dev/asmdiskb aun=1一直试到6，忽然发现有个别人提到的信息出现：
[root@rac2 ~]# kfed read /dev/asmdiskb aun=3|grep ckpt
kfracdc.
ckpt.seq:
85; 0x018: 0x00000055
kfracdc.
ckpt.blk:
784 ; 0x01c: 0x00000310
再看看ckpt，完全靠猜：这个信息是不是与数据库所期望的不一致导致打不开？
改它
kfed
read /dev/asmdiskb aun=3 >/tmp/k.txt ##读出来
vi /tmp/k.txt 将85 784 修改为 87 784 ##依据上面的报错提示
kfed merge /dev/asmdiskb aun=3 text=/tmp/k.txt ##写回去
crsctl start res ora.crsd -init ##再启动crs
还是报错。
但是值变了，原先的87 784 变为88 787。
为此，专门建立4个窗口，反复执行上面的修改。一共处理了以下这么多次：
一开始都是+CRS上的几个，后来+DATA上也有好几个。
终于crsd启动成功了，没白忙活。
接下来，尝试启动数据库。
srvctl start database -d orcl
一大堆报错，这个有经验，手工单独启动看看
提示ORA-38760，哦，关闭闪回就应该可以了。
startup mount force
alter database flashback off;
alter database open 还是提示ORA-38760。
MOS里搜一下，果然，
之前做测试创建了一个 gurantee restore point，放到了+FRA磁盘组，这个磁盘组在恢复过程中被删掉了，需要转储控制文件，从里面找到这个grp，然后删掉它。
SQL> oradebug setmypid
SQL> oradebug dump controlf 3;
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_ora_28895.trc
grep guarantee
orcl2_ora_28895.trc
然后删除这个还原点
drop restore point rp_1;
再启动数据库，正常打开。
检查crs状态，居然有个Stuck Archiver状态
SQL> show parameter log_archive_dest_1
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1 string location=+fra
log_archive_dest_10 string
log_archive_dest_11 string
归档参数也需要修改一下
alter system set
log_archive_dest_1='location=+data';
启停rac两个主机都正常了，又可以开心的玩耍了（已做快照）。
总结：
ASM 知识严重不足的情况下，强制修改几个ckpt数值让数据库认为磁盘没问题后正常打开数据库，生产环境一定不要这么做，还是重新搭建，然后rman恢复；
OCR磁盘组丢失的故障处理还需要进一步练习一下；
PROT-35 这个问题比较陌生，需要再查查资料；
进一步增强了ORA-38760的处理经验；
技术强就会快速解决，技术弱就靠备份托底；
参考：
https://cloud.tencent.com/developer/article/1654283
http://www.killdb.com/2020/04/21/ora-00600-kfrvalacd30/
STARTUP Database failed ORA-38760 to turn on Flashback Database (Doc ID 1554596.1)
