Oracle 12C RAC 丢失归档数据库启动异常--手动恢复案例
作者简介：
----------------------------------------------------------------------
@ 孙显鹏，海天起点oracle技术专家，十年从业经验
@ 精通oracle内部原理，擅长调优和解决疑难问题
@ 致力于帮助客户解决生产中的问题，提高生产效率。
@ 爱好：书法，周易，中医。微信：sunyunyi_sun
@ 易曰：精义入神，以致用也！
@ 调优乃燮理阴阳何其难也！
----------------------------------------------------------------------
版本： linux 7 + ORACLE 12.1.0.2 rac
现象：
集群正常，数据库无法启动，经过几个dba恢复无果，数据文件异常，数据库无法open。
刚开始数据库mount后查询数据文件头存在不一致的SCN，通过bbed修改对应数据文件头1号文件的SCN号和其他文件一致。
注意12c不同的pdb下的scn是不同的，而且数据文件是在ASM下存储的，需要借助asm转换脚本先把1号块转换到本地
文件系统中，关于这个操作可关注我的ITPUB中写的“ASM 使用bbed修改数据文件头SCN相关文章”。因为操作步骤太
长，这里不一一列出了。
主要是通过bbed修改每个数据文件1号数据块的下面三个地方：
(1)kscnbas (at offset 484) - SCN of last change to the datafile. --最重要的偏移量
(2)kcvcptim (at offset 492) -Time of the last change to the datafile.
(3)kcvfhcpc (at offset 140) - Checkpoint count.
beed ：(如果想深入学习可以下载bbed操作文档)，这里简单介绍bbed需要注意的地方：
命令 d offset 134 count 2
count 后面是字节数，一个字节8位，而一个十六进制字符使用4位表示，所以两位十六进制表示一个字节，如0x06表示一个字节。
修改block时也是以字节为单位，也就是最少一次修改一个字节，也就是两个十六进制。linux 一个字节的低四位在十六
进制的高位存储，高四位在十六进制的低四位存储，比如0x0809---正确的顺序为0908。其他系统依据字节顺序确定。
搞计算机修改二进制或者16进制要和修改10进制一样熟练才行，你看到十六进制要很熟悉，不然可能出错！
bbed修改完成后在参数文件中添加_allow_resetlogs_corruption参数为true，先把数据库打开为不一致状态，步骤如下：
此时mount实例后数据文件状态如下：
set lines 1200 pages 180
col name for a80
select CON_ID,file#, name, status ,creation_time from v$datafile order by con_id
CON_ID FILE# NAME STATUS CREATION_TIME
---------- ---------- -------------------------------------------------------------------------------- ------- -------------------
1 1 +DATA/CDB/DATAFILE/system.346.994269661 SYSTEM 2014-07-07 05:38:57
1 3 +DATA/CDB/DATAFILE/sysaux.348.994269659 RECOVER 2014-07-07 05:39:05
1 4 +DATA/CDB/DATAFILE/undotbs1.367.994268883 RECOVER 2014-07-07 07:03:58
1 6 +DATA/CDB/DATAFILE/users.312.994269999 RECOVER 2014-07-07 05:39:38
1 8 +DATA/CDB/DATAFILE/undotbs2.350.994269639 RECOVER 2016-05-16 12:22:51
1 29 /u01/Oradata/TBS_ZZFJ_2016_01.DBF RECOVER 2016-06-23 15:44:46
1 30 +DATA/CDB/DATAFILE/tbs_dcsj_2016_01.dbf RECOVER 2016-06-23 17:33:29
1 31 +DATA/CDB/DATAFILE/tbs_jddb_file_01.dbf RECOVER 2016-06-23 17:34:07
1 32 +DATA/CDB/DATAFILE/tbs_jddb_2010_01.dbf RECOVER 2016-06-23 17:34:24
1 33 +DATA/CDB/DATAFILE/tbs_jddb_2011_01.dbf RECOVER 2016-06-23 17:34:37
1 34 +DATA/CDB/DATAFILE/tbs_jddb_2012_01.dbf RECOVER 2016-06-23 17:34:43
1 35 +DATA/CDB/DATAFILE/tbs_jddb_2013_01.dbf RECOVER 2016-06-23 17:34:48
1 36 +DATA/CDB/DATAFILE/tbs_jddb_2014_01.dbf RECOVER 2016-06-23 17:35:00
1 37 +DATA/CDB/DATAFILE/tbs_jddb_2015_01.dbf RECOVER 2016-06-23 17:35:09
1 38 +DATA/CDB/DATAFILE/tbs_jddb_2016_01.dbf RECOVER 2016-06-23 17:35:14
1 39 +DATA/CDB/DATAFILE/tbs_dcsj_2010_01.dbf RECOVER 2016-06-23 17:35:21
1 40 +DATA/CDB/DATAFILE/tbs_dcsj_2011_01.dbf RECOVER 2016-06-23 17:35:27
1 41 +DATA/CDB/DATAFILE/tbs_dcsj_2012_01.dbf RECOVER 2016-06-23 17:35:33
1 42 +DATA/CDB/DATAFILE/tbs_dcsj_2013_01.dbf RECOVER 2016-06-23 17:35:40
1 43 +DATA/CDB/DATAFILE/tbs_dcsj_2015_01.dbf RECOVER 2016-06-23 17:35:46
1 44 +DATA/CDB/DATAFILE/tbs_dcsj_2014_01.dbf RECOVER 2016-06-23 17:35:52
1 45 +DATA/CDB/DATAFILE/tbs_zzsj_2016_01.dbf RECOVER 2016-06-23 17:36:08
1 46 +DATA/CDB/DATAFILE/tbs_jddb_main_01.dbf RECOVER 2016-06-23 17:37:48
1 47 +DATA/CDB/DATAFILE/sjjd_01.dbf RECOVER 2016-06-23 18:34:56
1 48 +DATA/CDB/DATAFILE/sjjd_02.dbf RECOVER 2016-06-23 18:34:56
1 49 +DATA/CDB/DATAFILE/tbs_520000_2015_01.dbf RECOVER 2016-06-23 18:36:51
1 50 +DATA/CDB/DATAFILE/tbs_520000_2015_02.dbf RECOVER 2016-06-23 18:36:51
1 51 +DATA/CDB/DATAFILE/tbs_520000_2014_01.dbf RECOVER 2016-06-23 18:37:04
1 52 +DATA/CDB/DATAFILE/tbs_520000_2014_02.dbf RECOVER 2016-06-23 18:37:04
1 53 +DATA/CDB/DATAFILE/tbs_520000_2013_01.dbf RECOVER 2016-06-23 18:37:21
1 54 +DATA/CDB/DATAFILE/tbs_520000_2013_02.dbf RECOVER 2016-06-23 18:37:21
1 55 +DATA/CDB/DATAFILE/tbs_520000_2012_01.dbf RECOVER 2016-06-23 18:37:34
1 56 +DATA/CDB/DATAFILE/tbs_520000_2012_02.dbf RECOVER 2016-06-23 18:37:34
1 57 +DATA/CDB/DATAFILE/tbs_520000_2016_01.dbf RECOVER 2016-06-23 18:37:55
1 133 +DATA/CDB/DATAFILE/tbs_dcsj_2016.292.994270137 RECOVER 2016-12-26 16:39:47
1 134 +DATA/CDB/DATAFILE/tbs_jddb_2017.290.994270223 RECOVER 2016-12-29 15:52:57
1 135 +DATA/CDB/DATAFILE/tbs_jddb_2017.291.994270137 RECOVER 2016-12-29 15:52:58
1 136 +DATA/CDB/DATAFILE/tbs_dcsj_2017.354.994269369 RECOVER 2016-12-29 15:52:58
1 137 +DATA/CDB/DATAFILE/tbs_dcsj_2017.353.994269585 RECOVER 2016-12-29 15:52:59
1 138 +DATA/CDB/DATAFILE/tbs_dcsj_2017.352.994269585 RECOVER 2016-12-29 15:53:00
1 139 +DATA/CDB/DATAFILE/tbs_zzsj_2017.305.994270099 RECOVER 2016-12-29 15:53:01
1 140 +DATA/CDB/DATAFILE/tbs_zzfj_2017.298.994270107 RECOVER 2016-12-29 15:53:02
1 143 +DATA/CDB/DATAFILE/tbs_jddb_2018_01.dbf RECOVER 2018-01-02 10:56:09
1 144 +DATA/CDB/DATAFILE/tbs_jddb_2018_02.dbf RECOVER 2018-01-02 10:56:10
1 145 +DATA/CDB/DATAFILE/tbs_dcsj_2018_01.dbf RECOVER 2018-01-02 10:56:11
1 146 +DATA/CDB/DATAFILE/tbs_dcsj_2018_02.dbf RECOVER 2018-01-02 10:56:11
1 147 +DATA/CDB/DATAFILE/tbs_dcsj_2018_03.dbf RECOVER 2018-01-02 10:56:11
1 148 +DATA/CDB/DATAFILE/tbs_zzsj_2018_01.dbf RECOVER 2018-01-02 10:56:12
1 149 +DATA/CDB/DATAFILE/tbs_zzfj_2018_01.dbf RECOVER 2018-01-02 10:56:13
1 150 +DATA/CDB/DATAFILE/tbs_jddb_main_02.dbf RECOVER 2018-01-02 10:56:13
1 151 +DATA/CDB/DATAFILE/tbs_jddb_main_03.dbf RECOVER 2018-03-13 10:17:11
1 152 +DATA/CDB/DATAFILE/tbs_dcsj_2018_04.dbf RECOVER 2018-03-13 10:28:21
1 160 +DATA/CDB/DATAFILE/tbs_dcsj_2018_05.dbf RECOVER 2018-09-13 16:42:28
1 161 +DATA/CDB/DATAFILE/tbs_jddb_2018_03.dbf RECOVER 2018-09-13 16:43:53
1 162 +DATA/CDB/DATAFILE/tbs_jddb_main_04.dbf RECOVER 2018-09-13 16:44:29
1 163 +DATA/CDB/DATAFILE/tbs_dcsj_2018.285.994270225 RECOVER 2018-11-19 11:41:18
2 5 +DATA/CDB/32EEEBD19A843EFFE0531E00AA0A56E7/DATAFILE/system.344.994271315 SYSTEM 2016-05-16 12:19:18
2 7 +DATA/CDB/32EEEBD19A843EFFE0531E00AA0A56E7/DATAFILE/sysaux.359.994271315 ONLINE 2016-05-16 12:19:18
3 158 +DATA/CDB/4AD6B6C4C63108EAE0531E00AA0A44BA/DATAFILE/scstat.dbf ONLINE 2018-06-27 12:32:24
3 159 +DATA/CDB/4AD6B6C4C63108EAE0531E00AA0A44BA/DATAFILE/scexch.dbf ONLINE 2018-06-27 12:32:27
3 157 +DATA/CDB/4AD6B6C4C63108EAE0531E00AA0A44BA/DATAFILE/sde.dbf ONLINE 2018-06-27 12:32:20
3 156 +DATA/CDB/4AD6B6C4C63108EAE0531E00AA0A44BA/DATAFILE/scgis.dbf ONLINE 2018-06-27 12:32:19
3 155 +DATA/CDB/4AD6B6C4C63108EAE0531E00AA0A44BA/DATAFILE/scdata.dbf ONLINE 2018-06-27 12:32:17
3 154 +DATA/CDB/4AD6B6C4C63108EAE0531E00AA0A44BA/DATAFILE/scconf.dbf ONLINE 2018-06-27 12:32:13
3 142 +DATA/CDB/4AD6B6C4C63108EAE0531E00AA0A44BA/DATAFILE/sysaux.336.994271317 ONLINE 2017-03-16 17:30:47
3 141 +DATA/CDB/4AD6B6C4C63108EAE0531E00AA0A44BA/DATAFILE/system.334.994271317 SYSTEM 2017-03-16 17:30:47
4 106 +DATA/CDB/DATAFILE/gisdbtemp01.dbf ONLINE 2016-08-18 16:15:56
4 98 +DATA/CDB/3A550B1C2568062AE0531F00AA0ADB74/DATAFILE/system.273.994271359 SYSTEM 2016-08-18 16:10:51
4 108 +DATA/CDB/DATAFILE/gisgeo01.dbf ONLINE 2016-08-18 16:16:00
4 109 +DATA/CDB/DATAFILE/users.dbf ONLINE 2016-08-18 16:16:01
4 110 +DATA/CDB/DATAFILE/userso01.dbf ONLINE 2016-08-18 16:16:04
4 111 +DATA/CDB/DATAFILE/sde.dbf ONLINE 2016-08-18 16:22:23
4 112 +DATA/CDB/DATAFILE/sde01.dbf ONLINE 2016-08-18 16:22:26
4 107 +DATA/CDB/DATAFILE/gisgeo.dbf ONLINE 2016-08-18 16:15:57
4 99 +DATA/CDB/3A550B1C2568062AE0531F00AA0ADB74/DATAFILE/sysaux.326.994271351 ONLINE 2016-08-18 16:10:51
4 100 +DATA/CDB/DATAFILE/PDB_1.dbf ONLINE 2016-08-18 16:10:53
4 105 +DATA/CDB/DATAFILE/gisdbtemp_.dbf ONLINE 2016-08-18 16:15:53
4 104 +DATA/CDB/DATAFILE/gisdb01.dbf ONLINE 2016-08-18 16:15:52
4 103 +DATA/CDB/DATAFILE/gisdb.dbf ONLINE 2016-08-18 16:15:48
4 102 +DATA/CDB/DATAFILE/gismeta01.dbf ONLINE 2016-08-18 16:15:27
4 101 +DATA/CDB/DATAFILE/gismeta.dbf ONLINE 2016-08-18 16:15:23
6 132 /u01/Oradata/PDB_3space.dbf ONLINE 2016-10-20 13:40:05
6 131 +DATA/CDB/3F4659A225F74F97E0531F00AA0A238E/DATAFILE/sysaux.360.994271315 ONLINE 2016-10-20 13:40:00
6 130 +DATA/CDB/3F4659A225F74F97E0531F00AA0A238E/DATAFILE/system.356.994271315 SYSTEM 2016-10-20 13:40:00
尝试recover：
SQL> recover database using backup controlfile;
ORA-00279: change 12522979 generated at 08/16/2016 23:00:52 needed for thread 1
竟然需要08/16/2016 23:00:52时候的归档？？
从备份看，只有2018年11月23日的全备而且没有任何归档日志，而且目前这个数据文件我是从该备份恢复，
为了彻底，我把ASM磁盘中对应的文件全部都删除了，怎么需要2016年的归档？
从数据文件建立时间看，上个月建立了一个数据文件，说明备份确实是11月23日备份的。
ORA-00289: suggestion : +FRA
ORA-15173: entry 'ARCHIVELOG' does not exist in directory 'CDB'
ORA-00280: change 12522979 for thread 1 is in sequence #696
Specify log: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00308: cannot open archived log '+FRA'
ORA-17503: ksfdopn:2 Failed to open file +FRA
ORA-15045: ASM file name '+FRA' is not in reference form
ORA-00308: cannot open archived log '+FRA'
ORA-17503: ksfdopn:2 Failed to open file +FRA
ORA-15045: ASM file name '+FRA' is not in reference form
没有任何归档，还需要2106年归档，哎！不知道前面做了什么操作。
尝试open 数据库，resetlog从新开启日志流：
alter database open resetlogs
报错：
ORA-01248: file 98 was created in the future of incomplete recovery
ORA-01110: data file 98: '+DATA/CDB/3A550B1C2568062AE0531F00AA0ADB74/DATAFILE/system.273.994271359'
遇到任何报错，不要着急，一定弄清楚这个报错的真实含义，特别是针对恢复操作，
千万不要尝试这个操作尝试那个操作，不要乱，稳住心神，一步步操作。对于这个报错，
花了我将近20分钟时间，虽然明白这个报错的意思，无法想象什么操作导致了这个报错！
如果能想明白什么操作导致了该错误，处理思路可能更清晰。
先看看这个报错的意思：
$ oerr ora 1248
01248, 00000, "file %s was created in the future of incomplete recovery"
*Cause: Attempting to do a RESETLOGS open with a file entry in the
control file that was originally created after the UNTIL time
of the incomplete recovery.
Allowing such an entry may hide the version of the file that
is needed at this time. The file number may be in use for
a different file which would be lost if the RESETLOGS was allowed.
*Action: If more recovery is desired then apply redo until the creation
time of the file is reached. If the file is not wanted and the
same file number is not in use at the stop time of the recovery,
then the file can be taken offline with the FOR DROP option.
Otherwise a different control file is needed to allow the RESETLOGS.
Another backup can be restored and recovered, or a control file can
be created via CREATE CONTROLFILE.
1248 报错表示以前使用了不完全恢复，但是控制文件里面包含了不完全恢复后建立的数据文件。
处理方法：
1：对于大于PITR时间点的数据文件全部 offline drop，然后打开数据库。
命令如下：
alter database datafile offline drop，等数据库打开后再 online.
或者
2：重建控制文件，但是需要从控制文件中删除大于PITR时间点的数据文件，
注意RAC下重建控制文件需要先将 cluster_database 设置为false，否则会报错。
考虑是12c环境里面有pdb，每个PDB有自己的system 文件那么方法2可能不太好使，我们使用第一个方法。
也就是说有人使用recover database until 08/16/2016 23:00:52 命令操作过。
检查大于08/16/2016 23:00:52 时间点建立的数据文件
set lines 1200 pages 180
col name for a80
select CON_ID,file#, name, status ,creation_time
from v$datafile
where creation_time > to_date('2016-08-16:23:00:52','YYYY-MM-DD:HH24:MI:SS');
CON_ID FILE# NAME STATUS CREATION_TIME
---------- ---------- -------------------------------------------------------------------------------- ------- -------------------
4 98 +DATA/CDB/3A550B1C2568062AE0531F00AA0ADB74/DATAFILE/system.273.994271359 SYSTEM 2016-08-18 16:10:51
4 99 +DATA/CDB/3A550B1C2568062AE0531F00AA0ADB74/DATAFILE/sysaux.326.994271351 ONLINE 2016-08-18 16:10:51
4 100 +DATA/CDB/DATAFILE/PDB_1.dbf ONLINE 2016-08-18 16:10:53
4 101 +DATA/CDB/DATAFILE/gismeta.dbf ONLINE 2016-08-18 16:15:23
4 102 +DATA/CDB/DATAFILE/gismeta01.dbf ONLINE 2016-08-18 16:15:27
4 103 +DATA/CDB/DATAFILE/gisdb.dbf ONLINE 2016-08-18 16:15:48
4 104 +DATA/CDB/DATAFILE/gisdb01.dbf ONLINE 2016-08-18 16:15:52
4 105 +DATA/CDB/DATAFILE/gisdbtemp_.dbf ONLINE 2016-08-18 16:15:53
4 106 +DATA/CDB/DATAFILE/gisdbtemp01.dbf ONLINE 2016-08-18 16:15:56
4 107 +DATA/CDB/DATAFILE/gisgeo.dbf ONLINE 2016-08-18 16:15:57
4 108 +DATA/CDB/DATAFILE/gisgeo01.dbf ONLINE 2016-08-18 16:16:00
4 109 +DATA/CDB/DATAFILE/users.dbf ONLINE 2016-08-18 16:16:01
4 110 +DATA/CDB/DATAFILE/userso01.dbf ONLINE 2016-08-18 16:16:04
4 111 +DATA/CDB/DATAFILE/sde.dbf ONLINE 2016-08-18 16:22:23
4 112 +DATA/CDB/DATAFILE/sde01.dbf ONLINE 2016-08-18 16:22:26
6 130 +DATA/CDB/3F4659A225F74F97E0531F00AA0A238E/DATAFILE/system.356.994271315 SYSTEM 2016-10-20 13:40:00
6 131 +DATA/CDB/3F4659A225F74F97E0531F00AA0A238E/DATAFILE/sysaux.360.994271315 ONLINE 2016-10-20 13:40:00
6 132 /u01/Oradata/PDB_3space.dbf ONLINE 2016-10-20 13:40:05
1 133 +DATA/CDB/DATAFILE/tbs_dcsj_2016.292.994270137 RECOVER 2016-12-26 16:39:47
1 134 +DATA/CDB/DATAFILE/tbs_jddb_2017.290.994270223 RECOVER 2016-12-29 15:52:57
1 135 +DATA/CDB/DATAFILE/tbs_jddb_2017.291.994270137 RECOVER 2016-12-29 15:52:58
1 136 +DATA/CDB/DATAFILE/tbs_dcsj_2017.354.994269369 RECOVER 2016-12-29 15:52:58
1 137 +DATA/CDB/DATAFILE/tbs_dcsj_2017.353.994269585 RECOVER 2016-12-29 15:52:59
1 138 +DATA/CDB/DATAFILE/tbs_dcsj_2017.352.994269585 RECOVER 2016-12-29 15:53:00
1 139 +DATA/CDB/DATAFILE/tbs_zzsj_2017.305.994270099 RECOVER 2016-12-29 15:53:01
1 140 +DATA/CDB/DATAFILE/tbs_zzfj_2017.298.994270107 RECOVER 2016-12-29 15:53:02
3 141 +DATA/CDB/4AD6B6C4C63108EAE0531E00AA0A44BA/DATAFILE/system.334.994271317 SYSTEM 2017-03-16 17:30:47
3 142 +DATA/CDB/4AD6B6C4C63108EAE0531E00AA0A44BA/DATAFILE/sysaux.336.994271317 ONLINE 2017-03-16 17:30:47
1 143 +DATA/CDB/DATAFILE/tbs_jddb_2018_01.dbf RECOVER 2018-01-02 10:56:09
1 144 +DATA/CDB/DATAFILE/tbs_jddb_2018_02.dbf RECOVER 2018-01-02 10:56:10
1 145 +DATA/CDB/DATAFILE/tbs_dcsj_2018_01.dbf RECOVER 2018-01-02 10:56:11
1 146 +DATA/CDB/DATAFILE/tbs_dcsj_2018_02.dbf RECOVER 2018-01-02 10:56:11
1 147 +DATA/CDB/DATAFILE/tbs_dcsj_2018_03.dbf RECOVER 2018-01-02 10:56:11
1 148 +DATA/CDB/DATAFILE/tbs_zzsj_2018_01.dbf RECOVER 2018-01-02 10:56:12
1 149 +DATA/CDB/DATAFILE/tbs_zzfj_2018_01.dbf RECOVER 2018-01-02 10:56:13
1 150 +DATA/CDB/DATAFILE/tbs_jddb_main_02.dbf RECOVER 2018-01-02 10:56:13
1 151 +DATA/CDB/DATAFILE/tbs_jddb_main_03.dbf RECOVER 2018-03-13 10:17:11
1 152 +DATA/CDB/DATAFILE/tbs_dcsj_2018_04.dbf RECOVER 2018-03-13 10:28:21
3 154 +DATA/CDB/4AD6B6C4C63108EAE0531E00AA0A44BA/DATAFILE/scconf.dbf ONLINE 2018-06-27 12:32:13
3 155 +DATA/CDB/4AD6B6C4C63108EAE0531E00AA0A44BA/DATAFILE/scdata.dbf ONLINE 2018-06-27 12:32:17
3 156 +DATA/CDB/4AD6B6C4C63108EAE0531E00AA0A44BA/DATAFILE/scgis.dbf ONLINE 2018-06-27 12:32:19
3 157 +DATA/CDB/4AD6B6C4C63108EAE0531E00AA0A44BA/DATAFILE/sde.dbf ONLINE 2018-06-27 12:32:20
3 158 +DATA/CDB/4AD6B6C4C63108EAE0531E00AA0A44BA/DATAFILE/scstat.dbf ONLINE 2018-06-27 12:32:24
3 159 +DATA/CDB/4AD6B6C4C63108EAE0531E00AA0A44BA/DATAFILE/scexch.dbf ONLINE 2018-06-27 12:32:27
1 160 +DATA/CDB/DATAFILE/tbs_dcsj_2018_05.dbf RECOVER 2018-09-13 16:42:28
1 161 +DATA/CDB/DATAFILE/tbs_jddb_2018_03.dbf RECOVER 2018-09-13 16:43:53
1 162 +DATA/CDB/DATAFILE/tbs_jddb_main_04.dbf RECOVER 2018-09-13 16:44:29
1 163 +DATA/CDB/DATAFILE/tbs_dcsj_2018.285.994270225 RECOVER 2018-11-19 11:41:18
48 rows selected.
第一个就是98号文件。所以打开库第一个就是98号文件报错，那么后面所有的数据文件都会报错，这里有48个文件。
ora-1248 处理步骤：
确定 pdb 号和名字：
con_id pdb_name
3 PDB_3
4 PDB_1
6 PDB_2
因为文件太多，编写脚本如下：
注意对于具体的PDB需要进入PDB容器操作，这个要注意。
ALTER SESSION SET CONTAINER =PDB_1;
select 'alter database datafile ' ||file# ||' offline drop;'
from v$datafile
where creation_time > to_date('2016-08-16:23:00:52','YYYY-MM-DD:HH24:MI:SS')
and CON_ID=4
/
alter database datafile 98 offline drop;
alter database datafile 99 offline drop;
alter database datafile 100 offline drop;
alter database datafile 101 offline drop;
alter database datafile 102 offline drop;
alter database datafile 103 offline drop;
alter database datafile 104 offline drop;
alter database datafile 105 offline drop;
alter database datafile 106 offline drop;
alter database datafile 107 offline drop;
alter database datafile 108 offline drop;
alter database datafile 109 offline drop;
alter database datafile 110 offline drop;
alter database datafile 111 offline drop;
alter database datafile 112 offline drop;
ALTER SESSION SET CONTAINER = CDB$ROOT;
select 'alter database datafile ' ||file# ||' offline drop;'
from v$datafile
where creation_time > to_date('2016-08-16:23:00:52','YYYY-MM-DD:HH24:MI:SS')
and CON_ID=1
/
alter database datafile 133 offline drop;
alter database datafile 134 offline drop;
alter database datafile 135 offline drop;
alter database datafile 136 offline drop;
alter database datafile 137 offline drop;
alter database datafile 138 offline drop;
alter database datafile 139 offline drop;
alter database datafile 140 offline drop;
alter database datafile 143 offline drop;
alter database datafile 144 offline drop;
alter database datafile 145 offline drop;
alter database datafile 146 offline drop;
alter database datafile 147 offline drop;
alter database datafile 148 offline drop;
alter database datafile 149 offline drop;
alter database datafile 150 offline drop;
alter database datafile 151 offline drop;
alter database datafile 152 offline drop;
alter database datafile 160 offline drop;
alter database datafile 161 offline drop;
alter database datafile 162 offline drop;
alter database datafile 163 offline drop;
ALTER SESSION SET CONTAINER =PDB_3;
select 'alter database datafile ' ||file# ||' offline drop;'
from v$datafile
where creation_time > to_date('2016-08-16:23:00:52','YYYY-MM-DD:HH24:MI:SS')
and CON_ID=3
/
alter database datafile 141 offline drop;
alter database datafile 142 offline drop;
alter database datafile 154 offline drop;
alter database datafile 155 offline drop;
alter database datafile 156 offline drop;
alter database datafile 157 offline drop;
alter database datafile 158 offline drop;
alter database datafile 159 offline drop;
ALTER SESSION SET CONTAINER =PDB_2;
select 'alter database datafile ' ||file# ||' offline drop;'
from v$datafile
where creation_time > to_date('2016-08-16:23:00:52','YYYY-MM-DD:HH24:MI:SS')
and CON_ID=6
/
------------------------------------------------------------------------------
alter database datafile 130 offline drop;
alter database datafile 131 offline drop;
alter database datafile 132 offline drop;
再次尝试开始打开库：
SQL> ALTER SESSION SET CONTAINER = CDB$ROOT;
Session altered.
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [kclchkblk_4], [2], [2555998920], [2], [2555803034], [], [], [], [], [], [], []
Process ID: 22301
Session ID: 819 Serial number: 41235
上面错误我们经常见到：
表示数据块里面的SCN大于当前的SCN
处理方法很简单，手动推进SCN，如下操作，注意一定要按照下面步骤操作，否则scn推进很慢：
shut immediate
startup mount
ALTER SESSION SET EVENTS 'IMMEDIATE TRACE NAME ADJUST_SCN LEVEL 1';
继续报错
观察[2555998920], [2], [2555803034] 在发送变化，说明在推进，但是还不够，继续重复上面操作！
经过多次推进SCN，成功open实例：
alter database open resetlogs;
好了数据块打开了！
下面依次ONLINE 对应的数据文件：
继续编写脚本如下：
ALTER SESSION SET CONTAINER =PDB_1;
select 'alter database datafile ' ||file# ||' online;'
from v$datafile
where creation_time > to_date('2016-08-16:23:00:52','YYYY-MM-DD:HH24:MI:SS')
and CON_ID=4
/
alter database datafile 98 online;
alter database datafile 99 online;
alter database datafile 100 online;
alter database datafile 101 online;
alter database datafile 102 online;
alter database datafile 103 online;
alter database datafile 104 online;
alter database datafile 105 online;
alter database datafile 106 online;
alter database datafile 107 online;
alter database datafile 108 online;
alter database datafile 109 online;
alter database datafile 110 online;
alter database datafile 111 online;
alter database datafile 112 online;
ALTER SESSION SET CONTAINER = CDB$ROOT;
select 'alter database datafile ' ||file# ||' online;'
from v$datafile
where creation_time > to_date('2016-08-16:23:00:52','YYYY-MM-DD:HH24:MI:SS')
and CON_ID=1
/
SQL> alter database datafile 133 online;
alter database datafile 133 online
*
ERROR at line 1:
ORA-01190: control file or data file 133 is from before the last RESETLOGS
ORA-01110: data file 133: '+DATA/CDB/DATAFILE/tbs_dcsj_2016.363.994323653'
后面的报错不一一列出，都是类似报错
其实这个报错就是说明，这个数据文件和当前的数据库不是相同的resetlogs，也就是
不是相同的生命周期，不是一个时代的人。 对于这个报错的详细处理方法，可以参照
我的itpub“Oracle跨越resetlogs如何恢复数据库”文档。
注意这个案例还是比较好处理的，因为此时数据库已经打开了，如果数据库都不能打开，
那么需要在控制文件中只保留一个system文件，先想办法打开数据库，然后逐个添加数据文件。
“Oracle跨越resetlogs如何恢复数据库” 这个文档也是12c下的测试，有详细步骤，可做参考。
下面简单说明操作步骤：
1：先尝试重建控制文件
alter database backup controlfile to trace as '/home/oracle/ctl.ora'
编辑ctl.ora 删除不需要的命令。
sqlplus / as sysdba
startup nomount pfile='/home/oracle/pfile.ora' --注意参数文件修改cluster_database
@/home/oracle/ctl.ora
继续报错--is from before the last RESETLOGS,说明和控制文件没什么关系。
接下来处理数据文件
2：使用如下命令从新添加数据文件
alter database create datafile 133 as '+DATA/CDB/DATAFILE/tbs_dcsj_sun001.dbf';
注意如果使用OMF，则需要重命名数据文件，否则报错。
“Oracle跨越resetlogs如何恢复数据库” 这个文档有详细说明。
如下操作：这里只列出修改133号文件,其他数据文件操作相同。
SQL> alter database create datafile 133 as '+DATA/CDB/DATAFILE/tbs_dcsj_sun001.dbf';
Database altered.
SQL> alter database datafile 133 online;
alter database datafile 133 online
*
ERROR at line 1:
ORA-01113: file 133 needs media recovery
ORA-01110: data file 133: '+DATA/CDB/DATAFILE/tbs_dcsj_sun001.dbf'
SQL> recover datafile 133;
Media recovery complete.
SQL> alter database datafile 133 online;
Database altered.
数据文件133 online成功，其他操作相同。
编辑脚本：
ALTER SESSION SET CONTAINER = CDB$ROOT;
select 'alter database create datafile ' ||file# || ' as ''' || name || ''' ;'
from v$datafile
where creation_time > to_date('2016-08-16:23:00:52','YYYY-MM-DD:HH24:MI:SS')
and CON_ID=1
/
需要手动修改每个数据文件的名字，重新命名！！
alter database create datafile 133 as '+DATA/CDB/DATAFILE/tbs_dcsj_sun001.dbf';
alter database create datafile 134 as '+DATA/CDB/DATAFILE/tbs_jddb_2017_01.dbf';
alter database create datafile 135 as '+DATA/CDB/DATAFILE/tbs_jddb_2017_02.dbf';
alter database create datafile 136 as '+DATA/CDB/DATAFILE/tbs_dcsj_2017_03.dbf';
alter database create datafile 137 as '+DATA/CDB/DATAFILE/tbs_dcsj_2017-04.dbf';
alter database create datafile 138 as '+DATA/CDB/DATAFILE/tbs_dcsj_2017_05.dbf';
alter database create datafile 139 as '+DATA/CDB/DATAFILE/tbs_zzsj_2017_06.dbf';
alter database create datafile 140 as '+DATA/CDB/DATAFILE/tbs_zzfj_2017_07.dbf';
alter database create datafile 143 as '+DATA/CDB/DATAFILE/tbs_jddb_2018_001.dbf';
alter database create datafile 144 as '+DATA/CDB/DATAFILE/tbs_jddb_2018_002.dbf';
alter database create datafile 145 as '+DATA/CDB/DATAFILE/tbs_dcsj_2018_001.dbf';
alter database create datafile 146 as '+DATA/CDB/DATAFILE/tbs_dcsj_2018_002.dbf';
alter database create datafile 147 as '+DATA/CDB/DATAFILE/tbs_dcsj_2018_003.dbf';
alter database create datafile 148 as '+DATA/CDB/DATAFILE/tbs_zzsj_2018_001.dbf';
alter database create datafile 149 as '+DATA/CDB/DATAFILE/tbs_zzfj_2018_001.dbf';
alter database create datafile 150 as '+DATA/CDB/DATAFILE/tbs_jddb_main_002.dbf';
alter database create datafile 151 as '+DATA/CDB/DATAFILE/tbs_jddb_main_003.dbf';
alter database create datafile 152 as '+DATA/CDB/DATAFILE/tbs_dcsj_2018_004.dbf';
alter database create datafile 160 as '+DATA/CDB/DATAFILE/tbs_dcsj_2018_005.dbf';
alter database create datafile 161 as '+DATA/CDB/DATAFILE/tbs_jddb_2018_003.dbf';
alter database create datafile 162 as '+DATA/CDB/DATAFILE/tbs_jddb_main_004.dbf';
alter database create datafile 163 as '+DATA/CDB/DATAFILE/tbs_dcsj_2018_009.dbf';
select 'recover datafile ' ||file#|| ';'
from v$datafile
where creation_time > to_date('2016-08-16:23:00:52','YYYY-MM-DD:HH24:MI:SS')
and CON_ID=1
/
recover datafile 133;
recover datafile 134;
recover datafile 135;
recover datafile 136;
recover datafile 137;
recover datafile 138;
recover datafile 139;
recover datafile 140;
recover datafile 143;
recover datafile 144;
recover datafile 145;
recover datafile 146;
recover datafile 147;
recover datafile 148;
recover datafile 149;
recover datafile 150;
recover datafile 151;
recover datafile 152;
recover datafile 160;
recover datafile 161;
recover datafile 162;
recover datafile 163;
select 'alter database datafile ' ||file#|| ' online;'
from v$datafile
where creation_time > to_date('2016-08-16:23:00:52','YYYY-MM-DD:HH24:MI:SS')
and CON_ID=1
/
alter database datafile 133 online;
alter database datafile 134 online;
alter database datafile 135 online;
alter database datafile 136 online;
alter database datafile 137 online;
alter database datafile 138 online;
alter database datafile 139 online;
alter database datafile 140 online;
alter database datafile 143 online;
alter database datafile 144 online;
alter database datafile 145 online;
alter database datafile 146 online;
alter database datafile 147 online;
alter database datafile 148 online;
alter database datafile 149 online;
alter database datafile 150 online;
alter database datafile 151 online;
alter database datafile 152 online;
alter database datafile 160 online;
alter database datafile 161 online;
alter database datafile 162 online;
alter database datafile 163 online;
到此，CDB 全部恢复成功，因为数据文件是11月23日备份的，所以数据基本都在。
接下来使用相同的办法修复PDB：
存在三个pdb,如下：
3 PDB_3
4 PDB_1
6 PDB_2
其中PDB_2 可正常打开，后台日志有警告，但是该PDB可以open，后面可以exp导出数据。
处理其他两个PDB：
ALTER SESSION SET CONTAINER =PDB_1;
select 'alter database create datafile ' ||file# || ' as ''' || name || ''' ;'
from v$datafile
where creation_time > to_date('2016-08-16:23:00:52','YYYY-MM-DD:HH24:MI:SS')
and CON_ID=4
/
注意每个PDB有一个guid,如下：3A550B1C2568062AE0531F00AA0ADB74，从下面也可以看出，该DBA操作不规范。
alter database create datafile 98 as '+DATA/CDB/3A550B1C2568062AE0531F00AA0ADB74/DATAFILE/system.273.994271359';
alter database create datafile 99 as '+DATA/CDB/3A550B1C2568062AE0531F00AA0ADB74/DATAFILE/sysaux.dbf' ;
alter database create datafile 100 as '+DATA/CDB/DATAFILE/PDB_101.dbf' ;
alter database create datafile 101 as '+DATA/CDB/DATAFILE/gismeta01.dbf' ;
alter database create datafile 102 as '+DATA/CDB/DATAFILE/gismeta001.dbf' ;
alter database create datafile 103 as '+DATA/CDB/DATAFILE/gisdb001.dbf' ;
alter database create datafile 104 as '+DATA/CDB/DATAFILE/gisdb002.dbf' ;
alter database create datafile 105 as '+DATA/CDB/DATAFILE/gisdbtemp001.dbf' ;
alter database create datafile 106 as '+DATA/CDB/DATAFILE/gisdbtemp0002.dbf' ;
alter database create datafile 107 as '+DATA/CDB/DATAFILE/gisgeo001.dbf' ;
alter database create datafile 108 as '+DATA/CDB/DATAFILE/gisgeo002.dbf' ;
alter database create datafile 109 as '+DATA/CDB/DATAFILE/users001.dbf' ;
alter database create datafile 110 as '+DATA/CDB/DATAFILE/userso002.dbf' ;
alter database create datafile 111 as '+DATA/CDB/DATAFILE/sde001.dbf' ;
alter database create datafile 112 as '+DATA/CDB/DATAFILE/sde002.dbf' ;
其他操作步骤和CDB一样就不一一写出了。
尝试打开PDB：
alter pluggable database PDB_1 open;
遇到如下内部报错：
ORA-600:[kcbtse_populate_tbskey_5] error
该报错定义为 bug，oracle 解释如下，且给了详细的案例操作。好吧无法修复，只能升级数据库。
下载最新的PSU安装后，继续尝试打开PDB，还是报错，那么这两个PDB 看来是无法修复了。如果能
确定resetglos在数据文件1号块的位置，我觉得修改该resetlogs标志估计可以修复。和客户沟通后，
剩下的PDB数据不重要，这里就不修复了，后面可以尝试这种办法。但是这个BUG还是非常致命的，
所以安装数据库一定要选择最新的版本，且一定要在部署时安装最新的PSU，否则遇到问题可能比较棘手。
oracle 官方描述如下：
BUG TYPE CHOSEN
===============
Code --代码缺陷
== SubComponent: Recovery Manager ==
====================================
DETAILED PROBLEM DESCRIPTION
============================
During a PDB recovery, we hit always ORA-600 [kcbtse_populate_tbskey_5]--报错
DIAGNOSTIC ANALYSIS
===================
Test-Case --这里给出了一个测试案例，供参考：
1. Backup CDB
2. Create a new PDB (no Backup, but redo available)
3. Recover the new PDB
SQL> CREATE PLUGGABLE DATABASE APP62 from APP60 FILE_NAME_CONVERT =
('/u01/oradata/CDB6/APP60','/u01/oradata/CDB6/APP62/');
Pluggable database created.
SQL> alter pluggable database APP62 open;
Pluggable database altered.
SQL> alter system switch logfile;
SQL> shutdown abort
ORACLE instance shut down.
SQL> !rm -f /u01/oradata/CDB6/APP62/*
SQL> startup
ORACLE instance started.
Database mounted.
Database opened.
SQL> alter pluggable database all open;
alter pluggable database all open
*
ERROR at line 1:
ORA-1157: cannot identify/lock data file 24 - see DBWR trace file
ORA-1110: data file 24: '/u01/oradata/CDB6/APP62/APP60_users01.dbf'
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 APP60 READ WRITE NO
4 APP61 READ WRITE NO
5 APP62 MOUNTED <<
SQL>
SQL> alter session set container=APP62;
Session altered.
SQL> alter database create datafile
'/u01/oradata/CDB6/APP62/APP60_users01.dbf' as
'/u01/oradata/CDB6/APP62/APP60_users01.dbf';
Database altered.
SQL> alter database create datafile '/u01/oradata/CDB6/APP62/system01.dbf' as
'/u01/oradata/CDB6/APP62/system01.dbf';
Database altered.
SQL> alter database create datafile '/u01/oradata/CDB6/APP62/sysaux01.dbf' as
'/u01/oradata/CDB6/APP62/sysaux01.dbf';
Database altered.
RMAN> recover pluggable database app62;
Starting recover at 28-AUG-15
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=10 device type=DISK
starting media recovery
media recovery failed
RMAN-571: ===========================================================
RMAN-569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-571: ===========================================================
RMAN-3002: failure of recover command at 08/28/2015 09:58:53
ORA-283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database
recover if needed
datafile 22 , 23 , 24
ORA-283: recovery session canceled due to errors
ORA-600: internal error code, arguments: [kcbtse_populate_tbskey_5], [5],
[0], [22], [], [], [], [], [], [], [], []
--和我们遇到问题一致！
WORKAROUND?
===========
No --没有解决办法
TECHNICAL IMPACT
================
ct not able to recover PDB
RELATED ISSUES (bugs, forums, RFAs)
===================================
similar to Bug 21616423: RMAN RECOVER ORA-600 [KCBTSE_POPULATE_TBSKEY_5],
[3], [0] ---bug 号码
继续：
既然数据库都打开了，验证是否存在其他问题：
col name for a20
select con_id,name,open_mode
from v$containers
/
CON_ID NAME OPEN_MODE
---------- -------------------- ----------
1 CDB$ROOT READ WRITE
2 PDB$SEED READ ONLY
3 PDB_3 READ WRITE
4 PDB_1 MOUNTED
6 PDB_2 MOUNTED
发现temp表空间都没有文件，因为前面曾经重建了控制文件，没有添加临时文件，没关系
手动添加就OK了，但是在给seed容器添加临时数据文件时，因为该pdb为只读，所以先添加一个
再删除报错的就行了。
命令如下：
ALTER TABLESPACE TEMP ADD TEMPFILE '+DATA' size 10g;
查询表空间使用率时报错：
ERROR at line 23:
ORA-12801: error signaled in parallel query server P003, instance rac1:CDB1 (1)
ORA-00600: internal error code, arguments: [kcfrbd_3], [150], [402440], [1], [16384], [16384], [], [], [], [], [], []
其中一个job启动需要执行也报上面的错误，看来数据库还是存在隐患的。
既然有问题，逻辑备份数据库，然后重建库，其实使用上面的恢复操作已经破坏了数据库一致性，在这样的恢复后一定是要重建库的。必须要重建库！
全库导出，重新建库，导入数据：
[oracle@rac1 expbak]$ expdp system/xxxx@cdb directory=expdp_dir dumpfile=expfull_%U.dmp logfile=expdp_full.log parallel=4 full=y;
Export: Release 12.1.0.2.0 - Production on Sat Dec 8 17:42:16 2018
Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Advanced Analytics and Real Application Testing options
WARNING: Oracle Data Pump operations are not typically needed when connected to the root or seed of a container database.
Starting "SYSTEM"."SYS_EXPORT_FULL_01": system/********@cdb directory=expdp_dir dumpfile=expfull_%U.dmp logfile=expdp_full.log parallel=4 full=y
Estimate in progress using BLOCKS method...
Processing object type DATABASE_EXPORT/EARLY_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA
Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/TABLE_DATA
Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA
ORA-39014: One or more workers have prematurely exited.
ORA-39029: worker 1 with process name "DW00" prematurely terminated
ORA-31671: Worker process DW00 had an unhandled exception.
ORA-00600: internal error code, arguments: [kcfrbd_3], [150], [402440], [1], [16384], [16384], [], [], [], [], [], []
Job "SYSTEM"."SYS_EXPORT_FULL_01" stopped due to fatal error at Sat Dec 8 17:42:50 2018 elapsed 0 00:00:34
还是报错，和上面报错基本一致，好吧，使用exp吧，在异常恢复导出数据时exp最好用，
最后一根救命稻草！！如果数据不能成功导出，前面的工作算是失败的！
使用exp 导出：
exp system/xxxxx@cdb BUFFER=102400 file=fulldb.dmp log=fullexp.log full=Y;
exp 涉及用户数据这里不列出了，有部分报错，但是数据都成功导出了。松了一口气！数据最重要了，导出就好了！
导出数据了，接下来重建一个数据库名字为CDB2，先不要破坏CDB库，有可能imp报错，或者遇到其他问题，安全操作。
DBCA 建库--略
然后建立表空间
使用如下脚本建立表空间：
set long 100000000
set pages 20000
select 'CREATE TABLESPACE '|| t.NAME || ' DATAFILE ''+FRA'' size ' || s.sizemb ||'m;'
from v$tablespace t,
(
select t.name, sum (trunc(bytes/1024/1024))+100 sizemb
from v$tablespace t,v$datafile d
where t.ts#=d.ts# and t.con_id=1
group by t.name
) s
where t.con_id=1 and t.name=s.name
/
CREATE TABLESPACE TBS_ZZFJ_2017 DATAFILE '+FRA' size 228m;
CREATE TABLESPACE TBS_JDDB_2012 DATAFILE '+FRA' size 484m;
CREATE TABLESPACE TBS_DCSJ_2012 DATAFILE '+FRA' size 228m;
CREATE TABLESPACE SJJD DATAFILE '+FRA' size 2148m;
CREATE TABLESPACE TBS_JDDB_2017 DATAFILE '+FRA' size 356m;
CREATE TABLESPACE TBS_DCSJ_2017 DATAFILE '+FRA' size 484m;
CREATE TABLESPACE TBS_JDDB_2015 DATAFILE '+FRA' size 868m;
CREATE TABLESPACE TBS_DCSJ_2010 DATAFILE '+FRA' size 228m;
CREATE TABLESPACE TBS_ZZFJ_2016 DATAFILE '+FRA' size 228m;
CREATE TABLESPACE TBS_520000_2012 DATAFILE '+FRA' size 2148m;
CREATE TABLESPACE TBS_520000_2016 DATAFILE '+FRA' size 6116m;
CREATE TABLESPACE TBS_JDDB_2018 DATAFILE '+FRA' size 484m;
CREATE TABLESPACE TBS_JDDB_TEMP DATAFILE '+FRA' size 2200m;
CREATE TABLESPACE TBS_JDDB_2010 DATAFILE '+FRA' size 612m;
CREATE TABLESPACE TBS_DCSJ_2015 DATAFILE '+FRA' size 228m;
CREATE TABLESPACE TBS_JDDB_MAIN DATAFILE '+FRA' size 25128m;
CREATE TABLESPACE TBS_JDDB_FILE DATAFILE '+FRA' size 2328m;
CREATE TABLESPACE TBS_JDDB_2016 DATAFILE '+FRA' size 1508m;
CREATE TABLESPACE TBS_520000_2015 DATAFILE '+FRA' size 8676m;
CREATE TABLESPACE TBS_ZZFJ_2018 DATAFILE '+FRA' size 228m;
CREATE TABLESPACE TBS_ZZSJ_2017 DATAFILE '+FRA' size 228m;
CREATE TABLESPACE TBS_DCSJ_2013 DATAFILE '+FRA' size 228m;
CREATE TABLESPACE TBS_DCSJ_2014 DATAFILE '+FRA' size 228m;
CREATE TABLESPACE TBS_ZZSJ_2016 DATAFILE '+FRA' size 5860m;
CREATE TABLESPACE TBS_520000_2014 DATAFILE '+FRA' size 2148m;
CREATE TABLESPACE TBS_DCSJ_2016 DATAFILE '+FRA' size 30948m;
CREATE TABLESPACE TBS_JDDB_2011 DATAFILE '+FRA' size 2228m;
CREATE TABLESPACE TBS_JDDB_2014 DATAFILE '+FRA' size 484m;
CREATE TABLESPACE TBS_DCSJ_2011 DATAFILE '+FRA' size 228m;
CREATE TABLESPACE TBS_520000_2013 DATAFILE '+FRA' size 2148m;
CREATE TABLESPACE TBS_DCSJ_2018 DATAFILE '+FRA' size 2240m;
CREATE TABLESPACE TBS_JDDB_2013 DATAFILE '+FRA' size 484m;
CREATE TABLESPACE TBS_ZZSJ_2018 DATAFILE '+FRA' size 228m;
仔细检查上面的脚本，因为可能size 列太大，我使用的sum函数！
导入数据：
依据我写的XTTS方案(一体机用户组文档有)中的建立用户的脚本建立对应的用户，这个脚本我在12c下做过测试，
因为imp导入时需要建立用户，我们知道12C下的用户格式为C##开头，如下操作：
select 'create user '||name||' identified by values '''||SPARE4||';'||PASSWORD||''';' from user$
where name in('C##user1','C##user2');
select 'grant '||GRANTED_ROLE||' to '||grantee||';' from dba_role_privs
where grantee in(select username from dba_users where username in('C##user1','C##user2'))
select 'grant '||privilege||' to '||grantee||';' from dba_sys_privs
where grantee in(select username from dba_users where username in('C##user1','C##user2'))
然后导入数据：
imp system/xxx@cdb ignore=y BUFFER=102400 log=/data/db_backup/expbak/endimp.log full=Y file=/data/db_backup/expbak/fulldb.dmp
确认无异常，检查数据库都正常，接下来，删除原来的数据库CDB，重建CDB，开启大页内存，修改了部分系统参数，添加了redo日志文件，
而且前面已经安装了最新的PSU，那么重建PDB下次recover应该不会在遭遇上面的bug，不过这个还需要测试。操作时总是会遇到问题，
一定要实际操作。
再次依据上面的操作步骤，导入数据。
到此，数据库修复完成，可惜有两个PDB没有修复，关于PDB不能recover 的bug后面会在12c2版本做测试，我觉得这个问题很严重，
导致PDB无法recover，一定要测试。
最终帮客户挽救了绝大部分数据。
所以说备份很重要，这个案例如果备份完整，归档没有丢失，那是很好处理。
不过这个案例需要2016年的归档可能有点久远，怀疑这个备份有点问题，有点说不清了，也许前面做了什么异常的操作！
回顾操作步骤：
1：先使用bbed修复数据文件头使SCN一致
2：尝试以不一致状态打开数据库，处理ORA-1248报错和推进SCN，这两个方法我们在异常恢复中经常用到
3：导出数据，重建库，导入数据
我在《把脉oracle数据库》这本书里面，介绍了数据块错误的修复方法的思路，其中包括1号文件，undo，redo，数据块，控制文件，
大家可以参考。另外我使用bbed详细解析了数据块中每个结构，非常详细，比如哪个偏移量什么意思等，其实你看到数据块里面，也
不是很难，说简单点就是一个C语句的结构程序块，我们上学的时候写过比这个更复杂的结构，记得参加国家程序员考试的时候，那时候
的考试非常严格，没有什么题库，全靠个人能力，很难考，现在大部分都是题库，哎！考的都是数据结构，比如链表，堆栈，队列等等，
这些结构对于理解oracle内部原理非常有用。其实oracle数据块的结构还是比较好理解的。后面有时间给大家分享。
这个case就和大家分享到这里。只能作为参考！不能照搬，理解原理最重要！！
最后再次提醒大家，一定要做好备份！备份大于一切！！！
遇到异常情况最忌讳没有思路去操作，一定要清楚每个操作步骤！
2018-12-08
孙显鹏
368
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
