我们的备份出了问题。 我做了什么
closures数据库
恢复备份
重启数据库
之后，我得到了这个错误
ORA-01122: Datenbank-Datei 2 bringt Fehler bei Verifizierungspruefung ORA-01110: Datendatei 2: 'D:\ORACLE\ORA92ABO\ABO\UNDOTBS01.DBF' ORA-01207: Datei neuer als Kontrolldatei - alte Kontrolldatei 控制文件在C：\ oracle …和数据库文件在d：\ oracle \ ora92abo …
我的猜测是备份d：\ oracle文件和c：\ controlfile数据库重新启动之间的backupprogramm。 所以在数据库运行的备份之间有一段时间。
猜猜这很糟糕。
我GOOGLE了UNDOTBS01.DBF与克隆有关，目前我们不需要/需要。
编辑：备份方法的详细信息
第1步：closures通过
spool d:\oracle\01shutdon.log connect / AS SYSDBA shutdown immediate exit
第二步：数据传输
用syncback将数据库文件夹备份到NAS，用xcopy将控制文件备份到NAS
第三步：重启
spool d:\oracle\02startup.log connect / AS SYSDBA startup exit
好的，这里是做什么。 显然在这里取代你自己的价值观。
您确实需要掌握并阅读一些RMAN文档…
首先 – 当你做了恢复，你还恢复控制文件？ 我知道这是显而易见的，但无论如何检查。
在Oracle中，有一个叫SCN的系统控制号。 每次执行COMMIT时，SCN都会前进1.数据库的SCN保存在每个DBF的头文件和控制文件中。 这个错误意味着你的UNDO表空间（克隆，不pipe是回滚 – 撤消 – 一个事务）数据文件具有比控制文件更高的SCN。 也就是说，控制文件比DBF要旧。
你究竟做了多less备份？ 与RMAN一起吗？ 或者你是否正在复制运行数据库的DBF …？ 好消息是，如果你有一个好的备份，那里就不会有空中交易，你需要担心。
你可以通过两种方法之一来解决这个问题。 首先，您可以继续尝试启动它 – 每次启动尝试都会将SCN增加1，因此最终控制文件将通过DBF。 可能还要等一下。 或者你可以尝试重新创build控制文件 。 find另一个Oracle，一个工作，并做ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS 'c:\temp\mycontrolfile.ctl' ; 用DB名称和DBF的新位置编辑该文件，启动并运行该脚本，它将生成一个新的控制文件。 那么你应该可以OPEN RESETLOGS一个OPEN RESETLOGS 。
但是，如果你的备份是坏的，你就什么都做不了。