补充实际计算推进SCN的方法
在实际这类工作中，我们实际应该是要认真计算好需要推进SCN的值，而不应图省事直接给一个很大的值。后者不但是技术水平不成熟的表现，而且是不负责任的行为。
ORA-00600: internal error code, arguments: [2662], [2], [1424107441], [2], [1424142235], [8388617], [], []
select 2*power(2,32)+1424142235 from dual;
10014076827
ORA-00600: internal error code, arguments: [2662], [2], [1424142249], [2], [1424142302], [8388649], [], []
select 2*power(2,32)+1424143000 from dual;
10014077592
2662 后面 5个参数，用 A B C D E 表示
总结公式：c * power(2,32) + d {+ 可适当加一点，但不要太大！} ##之前不知道这个算法，我将SCN推进了比较小，数据库还是无法恢复。使用这个算法后，数据库则恢复。
c代表：Arg [c] dependent SCN WRAP
d代表：Arg [d] dependent SCN BASE
oradebug setmypid
oradebug dumpvar sga kcsgscn_
oradebug poke 0x060012658 8 10014077592
oradebug dumpvar sga kcsgscn_
alter database open;
注意：
网上大量的恢复文章，步骤都不正确，混淆视听，经过确认，只要上面的三步即可恢复。
不需要如下：恢复数据库
1）recover database using backup controlfile until cancel;
2）alter database open resetlogs;
回到顶部
四、数据库导出
导出数据库的时候有个ora-01552的关于undo表空间的报错
解决方法：
1、表空间管理改为自动管理auto（因为之前看文档，要将undo管理，改为手动）
2、新建表空间
3、将新的表空间切换为默认表空间，弄完后则可expdp导出
回到顶部
五、事后总结
1、在做这次数据库恢复时，从网上选取了多种恢复方法，最后得到只有oradebug poke推进SCN的方法适合11.2.0.4版本，其他方法已经不适用；
2、数据库处于整个系统的终端，对数据库做的各种安全保护手段都不为过
1）必须对数据库做定期备份（RMAN/DUMP）
2）必须对日志文件使用日志组的方式，这样可以保证，同一组内的一个redo log损坏，可以有后备的redo log继续工作；
3）必须开启归档日志。