解决方案
根据技术的反馈，客户技术在数据库长时间无法正常启动下进行了恢复操作：
执行命令recover database……：
***之前客户还进行了控制文件的恢复。***
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 14602094204016 generated at 08/11/2021 16:25:57 needed for thread 1
ORA-00289: suggestion : /data/archivelog/1_99974_953044806.dbf
ORA-00280: change 14602094204016 for thread 1 is in sequence #99974
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/oracle/app/db/oradata/db/redo05.log
ORA-00310: archived log contains sequence 99975; sequence 99974 required
ORA-00334: archived log: '/oracle/app/db/oradata/db/redo05.log'
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oracle/app/db/oradata/db/system01.dbf'
……数据库执行了恢复，但是提示：ORA-01194: file 1 needs more recovery to be consistent
我们根据客户的操作和提示信息，先查询数据库文件头状态：
SQL> select file#,FUZZY,CHECKPOINT_CHANGE# from v$datafile_header;
FILE# FUZ CHECKPOINT_CHANGE#
---------- --- ----------------------
1 YES 14602094204016
2 YES 14602094204016
3 YES 14602094204016
4 YES 14602094204016
5 YES 14602094204016
6 YES 14602094204016
7 YES 14602094204016
8 YES 14602094204016
9 YES 14602094204016
10 YES 14602094204016
11 YES 14602094204016
……所有文件FUZZY=YES,结合之前的报错，数据库需要进行恢复。
查询redo文件，确认一下数据库需要从哪些REDO进行恢复?
SQL>set linesize 200
SQL>select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ---------------- ------------------- ------------ -------------------
1 1 99984 1048576000 512 1 NO CURRENT 14602112020769 2021-08-11 18:15:57 2.8147E+14
2 1 99983 1048576000 512 1 YES ACTIVE 14602105859246 2021-08-11 17:53:01 1.4602E+13 2021-08-11 18:15:57
3 1 99973 1048576000 512 1 YES INACTIVE 14602094169603 2021-08-11 16:15:34 1.4602E+13 2021-08-11 16:25:57
4 1 99974 1048576000 512 1 YES ACTIVE 14602094204016 2021-08-11 16:25:57 1.4602E+13 2021-08-11 16:32:32
5 1 99975 1048576000 512 1 YES ACTIVE 14602094213822 2021-08-11 16:32:32 1.4602E+13 2021-08-11 16:41:22
12 1 99982 1048576000 512 1 YES ACTIVE 14602105843303 2021-08-11 17:43:08 1.4602E+13 2021-08-11 17:53:01
7 1 99977 1048576000 512 1 YES ACTIVE 14602094248871 2021-08-11 16:47:04 1.4602E+13 2021-08-11 16:50:25
8 1 99978 1048576000 512 1 YES ACTIVE 14602094253721 2021-08-11 16:50:25 1.4602E+13 2021-08-11 17:08:57
9 1 99979 1048576000 512 1 YES ACTIVE 14602102201232 2021-08-11 17:08:57 1.4602E+13 2021-08-11 17:18:32
10 1 99980 1048576000 512 1 YES ACTIVE 14602104641094 2021-08-11 17:18:32 1.4602E+13 2021-08-11 17:23:13
11 1 99981 1048576000 512 1 YES ACTIVE 14602105100571 2021-08-11 17:23:13 1.4602E+13 2021-08-11 17:43:08
6 1 99976 1048576000 512 1 YES ACTIVE 14602094240649 2021-08-11 16:41:22 1.4602E+13 2021-08-11 16:47:04我们可以看到，v$datafile_header的CHECKPOINT_CHANGE#=14602094204016,v$log的FIRST_CHANGE# =14602094204016，即需要从logfile group#=4的redo文件进行恢复：
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 14602094204016 generated at 08/11/2021 16:25:57 needed for thread 1
ORA-00289: suggestion : /data/archivelog/1_99974_953044806.dbf
ORA-00280: change 14602094204016 for thread 1 is in sequence #99974
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/oracle/app/db/oradata/db/redo04.log
……在执行这一步时，由于磁盘问题，导致IO很慢，进行了漫长的等待，中间直接取消。--IO异常
和客户确认IO恢复正常后继续：
SQL> set linesize 200
SQL> select file#, CHECKPOINT_CHANGE# ,FUZZY from v$datafile_header;
FILE# CHECKPOINT_CHANGE# FUZ
---------- ------------------ ---
1 14602112020769 YES
2 14602112020769 YES
3 14602112020769 YES
4 14602112020769 YES
5 14602112020769 YES
6 14602112020769 YES
7 14602112020769 YES
8 14602112020769 YES
9 14602112020769 YES
10 14602112020769 YES
11 14602112020769 YES
......
FILE# CHECKPOINT_CHANGE# FUZ
---------- ------------------ ---
397 14602112020769 YES
398 14602112020769 YES
399 14602112020769 YES
400 14602112020769 YES
401 14602112020769 YES
402 14602112020769 YES
403 14602112020769 YES
404 14602112020769 YES
405 14602112020769 YES
406 14602112020769 YES
406 rows selected.
SQL> col FIRST_CHANGE# format 99999999999999999999
SQL> col NEXT_CHANGE# format 99999999999999999999
SQL> set linesize 200
SQL> select * from v$log order by FIRST_CHANGE# ;
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- --------------------- ------------------- --------------------- -------------------
3 1 99973 1048576000 512 1 YES INACTIVE 14602094169603 2021-08-11 16:15:34 14602094204016 2021-08-11 16:25:57
4 1 99974 1048576000 512 1 YES ACTIVE 14602094204016 2021-08-11 16:25:57 14602094213822 2021-08-11 16:32:32
5 1 99975 1048576000 512 1 YES ACTIVE 14602094213822 2021-08-11 16:32:32 14602094240649 2021-08-11 16:41:22
6 1 99976 1048576000 512 1 YES ACTIVE 14602094240649 2021-08-11 16:41:22 14602094248871 2021-08-11 16:47:04
7 1 99977 1048576000 512 1 YES ACTIVE 14602094248871 2021-08-11 16:47:04 14602094253721 2021-08-11 16:50:25
8 1 99978 1048576000 512 1 YES ACTIVE 14602094253721 2021-08-11 16:50:25 14602102201232 2021-08-11 17:08:57
9 1 99979 1048576000 512 1 YES ACTIVE 14602102201232 2021-08-11 17:08:57 14602104641094 2021-08-11 17:18:32
10 1 99980 1048576000 512 1 YES ACTIVE 14602104641094 2021-08-11 17:18:32 14602105100571 2021-08-11 17:23:13
11 1 99981 1048576000 512 1 YES ACTIVE 14602105100571 2021-08-11 17:23:13 14602105843303 2021-08-11 17:43:08
12 1 99982 1048576000 512 1 YES ACTIVE 14602105843303 2021-08-11 17:43:08 14602105859246 2021-08-11 17:53:01
2 1 99983 1048576000 512 1 YES ACTIVE 14602105859246 2021-08-11 17:53:01 14602112020769 2021-08-11 18:15:57
1 1 99984 1048576000 512 1 NO CURRENT 14602112020769 2021-08-11 18:15:57 281474976710655
SQL> col member format a60
SQL> select * from v$logfile;
GROUP# STATUS TYPE MEMBER IS_
---------- ------- ------- ------------------------------------------------------------ ---
2 ONLINE /oracle/app/db/oradata/db/redo02.log NO
3 ONLINE /oracle/app/db/oradata/db/redo03.log NO
1 ONLINE /oracle/app/db/oradata/db/redo01.dbf NO
20 STANDBY /oracle/app/db/oradata/db/standby20.log NO
21 STANDBY /oracle/app/db/oradata/db/standby21.log NO
22 STANDBY /oracle/app/db/oradata/db/standby22.log NO
23 STANDBY /oracle/app/db/oradata/db/standby23.log NO
4 ONLINE /oracle/app/db/oradata/db/redo04.log NO
5 ONLINE /oracle/app/db/oradata/db/redo05.log NO
6 ONLINE /oracle/app/db/oradata/db/redo06.log NO
7 ONLINE /oracle/app/db/oradata/db/redo07.log NO
8 ONLINE /oracle/app/db/oradata/db/redo08.log NO
9 ONLINE /oracle/app/db/oradata/db/redo09.log NO
10 ONLINE /oracle/app/db/oradata/db/redo10.log NO
11 ONLINE /oracle/app/db/oradata/db/redo11.log NO
12 ONLINE /oracle/app/db/oradata/db/redo12.log NO根据上面的信息，继续用group#=1的redo进行数据前滚恢复：
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 14602112020769 generated at 08/11/2021 18:15:57 needed for thread 1
ORA-00289: suggestion : /data/archivelog/1_99984_953044806.dbf
ORA-00280: change 14602112020769 for thread 1 is in sequence #99984
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/oracle/app/db/oradata/db/redo01.dbf
Log applied.
Media recovery complete.所有REDO全部完成前滚,确认数据文件头FUZZY=NO：
SQL> select file#, CHECKPOINT_CHANGE# ,FUZZY from v$datafile_header;
FILE# CHECKPOINT_CHANGE# FUZ
---------- ------------------ ---
1 14602128369466 NO
2 14602128369466 NO
3 14602128369466 NO
4 14602128369466 NO
5 14602128369466 NO
6 14602128369466 NO
7 14602128369466 NO
8 14602128369466 NO
9 14602128369466 NO
10 14602128369466 NO
11 14602128369466 NO
......
FILE# CHECKPOINT_CHANGE# FUZ
---------- ------------------ ---
397 14602128369466 NO
398 14602128369466 NO
399 14602128369466 NO
400 14602128369466 NO
401 14602128369466 NO
402 14602128369466 NO
403 14602128369466 NO
404 14602128369466 NO
405 14602128369466 NO
406 14602128369466 NO
406 rows selected.最后，open resetlogs方式打开数据库：
SQL> alter database open resetlogs;
Database altered.数据库确认恢复成功
