个人简介
偶尔有空上来看看
文章分类
文章存档
最近访客
相关博文
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
分类： oracle
2021-02-07 23:33:11
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
想想这个测试环境还有个 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)
很久前，自己笔记本上搭建了一套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
[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.
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' ;
8、crsctl replace votedisk ' crsnew'
crsctl query css votedisk确认。
但是在第7步没有成功，提示权限不对，检查/etc/oracle/ocr.loc，修改为 ocrnew也不行
总是提示：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)
给主人留下些什么吧！~~