某客户Oracle数据库无法启动，请求数据救援。
客户环境：Oracle 12.2单机 CDB（只有一个PDB） Windows 2012 ，block 16k，非归档模式，无备份
故障背景：客户在4.16打算移动pdb数据文件（C盘–>D盘），没有停数据库就复制粘贴数据文件了，之后数据库操作rename命令后C盘数据文件部分丢失，控制文件中数据文件位置改成了D盘，启动数据库启动失败，后客户工程师多次尝试恢复并多次resetlogs均未成功。
故障描述：数据库CDB启动正常，PDB无法启动。
看到是Windows系统后背发凉，Windows系统使用起来不方便，本次处理故障走了很多弯路，下面一一记录分析。
1.首先看到客户现场环境先查了一下checkpoint并尝试重启。
很显然重启失败，要不然也不会要求我们来恢复了。
2.考虑通过隐含参数拉起数据库
_allow_resetlogs_corruption=TRUE
启动数据库报错ORA_00600[kcvfdb_pdb_set_clean_scn]：
重新分步启动后报错ORA-01209：
恢复没成功，此处报错ORA_00600[kcvfdb_pdb_set_clean_scn]错误，这里走的第一个弯路就是直接忽略了，推进了scn。这里错误的意思是：PDB SCN必须改成513165573，现在是513165879。需要通过bbed修改pdb数据文件scn，noresetlogs重建控制文件启动，在修改数据文件的resetlogs SCN。这里忽略了直接按照现场处理故障思路进一步恢复。
3.重建控制文件
重建控制文件后启动报错ORA-01190：
看到这个错误，想到的就是使用bbed吧 resetlogs scn改到与CDB一致
4.bbed修改resetlogs scn
数据文件不是很多总共7个，直接手改
需要注意：Windows系统块头是从2号块开始的
set dba 8,2
assign dba 8.2 kcvfh.kcvfhrlc=dba 1,2 kcvfh.kcvfhrlc
assign dba 8.2 kcvfh.kcvfhrls=dba 1,2 kcvfh.kcvfhrls
p kcvfh.kcvfhrlc
p kcvfh.kcvfhrls
sum apply
这个操作要在数据库完全静止下进行修改，然后重建resetlogs创建控制文件启动数据库
依然报错：ORA-01190
5.再次修改resetlogs报错
查看pdbresetlogs_change#与CDB不一致，重新修改resetlogs scn，将error变成空。
重新启动数据库报错ORA-00600[kcbzib_kcrsds_1]：
6.决定event推进scn
12.2系统event 21307096推进scn
参数文件设置 event=“21307096 trace name context forever, level 1” --level 1 推进100w
重建控制文件，然后resetlogs启动，依然同样报错
7.决定修改checkpoint scn
这里就是就是另一个弯路，在Linux中checkpoint scn 的offset是 kscnbase 484 ，而在windows上是offset 140，多次修改140失败，其实这里应该修改offset 484，它才是scn。
修改完之后验证
重建控制文件启动，数据库成功拉起
