　　本来今天是搞一台ＩＢＭ的破ＰＣ机，结果客户的数据库出现了问题．请我去帮忙．为了维护用户关系，自然过去看看了．其实，在没有看到问题之前，我心里也没有底．

首先检测故障现象：当然是sqlplus /nolog，　conn sys/XXXX as sysdba, startup ...然后报找不到控制文件的错误．然后赶紧重新使用startup nomount命令，发现可以启动．　

询问出现故障的原由：　维护人员，在加表空间的时候，发现添加数据库的路径不对，然后删除该数据库文件，结果删错了文件，出现数据库不能启动．但是有昨天的冷备份．

初步判断：是不是删除表空间，造成数据库结构变化，出现数据文件和控制文件不一致？

具体做法：

修改现有控制文件的名字，将昨天冷备份的控制文件拷贝到该路径下，测试，结果情况和原出的一样．

后来发现自己想错了，应该是参数文件和控制文件的关系．肯定是控制文件和参数文件不一致．

接下来开始分析参数文件：

create pfile from spfile；／／转储参数文件

查看参数文件，检查控制文件的位置．也没错啊？怎么回事？该吃中午饭了．．．．

吃中午饭的时候，哪个程序开发的人告诉我，其实昨天，他在删除表空间的时候．其实只报修复一个表空间文件，可是他不知道，然后就删除ＯＲＣＬＥ数据库所有的文件，准备用以前备份的ＴＡＲ包进行恢复．其实，现在数据库里面的东西已经不是现在的数据了．．．．

听了这些话，我眉头一皱，看来只能对数据库进行冷备份还原了．然后准备将所有的文件名进行改名，用ＴＡＲ包恢复，把所有的东西覆盖，可是８００Ｇ的数据量，要恢复很常时间．于是，我测试着除了数据文件，其他文件进行替换．可是我发现使用ＯＲＡＣＬＥ用户，进行ＦＴＰ的时候，不让传文件？这是什么原因呢？

进入操作系统：su , cd /. ls -l,最后发现存放数据文件的文件夹已经更改为ＲＯＯＴ用户权限，我一下子矛塞顿开了，

肯定是权限不对，造成参数文件不能调用控制文件．

chown -R oracle:oinstall /data，　修改数据文件权限，然后将控制文件修改到昨天备份的状态．

启动数据库，结果数据库启动了．

经过分析：

该软件公司的哥们，一定是用ＲＯＯＴ用户进行备份ＴＡＲ包，在ＲＯＯＴ用户下解压ＴＡＲ包，造成权限更改．所以，问题就迎刃而解了．

总结：

首先备份重于一切

其次在搞数据库之前，问问自己在做什么？什么叫做＂无知者无畏＂！

ITPub博客

恢复800G数据量数据库一则