201930 应陆科之邀，记录关于数据库恢复（一）

如201929文所说，我们最近做了3次数据库的恢复。
原gs核心下发库（2003 32位操作系统）挂了。
幸亏它在虚拟机上。

第一次：
通过虚拟机的解挂重新挂载，终于在2012 64位服务器上恢复出来了。
这次，是通过冷备恢复的。
即原服务器里的数据库文件、控制文件一起带过来。
然后据他们说，就是简单修改下文件路径即可：

alter database rename file 'D:\app\administrator\oradata\sid\system01.dbf'
to 'E:\**\system01.dbf';

但是，恢复出的文件出了问题，提示：

Jerry说，理论上不会出现这种问题，因为通过

select * from v$transportable_platform order by platform_name;

查出来windows 32位和64位平台的字节序编码是一致的。
但是，Jerry还是提醒我，以后用expdp数据泵进行数据的导入导出。

少杰给出方案:

0. shutdown immediate
1.STARTUP UPGRADE 
2.spool utl.log
3.@?\rdbms\admin\utlirp.sql
4.spool off
5.shutdown immediate
6. startup
7. spool utlrp.log
8.@?\rdbms\admin\utlrp.sql
9.  spool off   

但是，当时，因为只对数据文件进行了路径修改，对临时文件没有进行路径修改，所以，其实执行第3步的时候，是报错了的，但是当时我不懂，就一直做下去。
然后执行好了一查失效对象：

select count(*) from dba_invalid_objects;

竟然有9000多个。。。

这可不行，于是，网上找材料，重新编译失效对象：

sql>Spool recompile.sql
sql>select 'alter '||object_type|| ' ' || owner ||'.'||object_name || ' compile;' from dba_objects where status='INVALID';
sql>Spool off
sql>@recompile.sql

这个方法果真不错，失效对象减为2000多个了。
但是，因为一方面，tnsnames没有设置到位，另一方面，临时文件没有进行重定位，失效对象没法减少。

而且，最重要的是：

select * from dba_registry;

发现好多失效组件。少杰说，这么多失效组件，数据库没法上线。
还叮嘱我，在执行0-9命令时，如果有报错了，就不应该继续执行下去的。。。
好吧。。。
我还是太年轻。。。