前言：
非标题党，本文是我2015年初到一家公司工作三个月后的转正述职时讲的案例，入职这家某国产ERP公司数据库技术支持岗位后，每天接触到大量的故障问题，包括数据库宕机、性能优化等，也是我成长最快的几年。
问题现象：
15年的某天，一大早收到了一个紧急恢复的问题：
从工单描述上不难看出，客户非常着急！
问题分析：
与客户沟通，机房异常断电，来电重启应用服务器和数据库服务器后，登录NC系统，输入用户名和密码登录后报错如下：
初步怀疑：
1.数据库或监听没配置自动启动，客户不知道怎么启动；
2.机房断电导致数据库的某个文件损坏，比如控制文件、日志文件、数据文件等。
具体是哪个文件损坏，就要看数据库能启动到哪个阶段了。
验证猜想：
登录数据库服务器，切换到oracle用户，发现没有sqlplus命令？
猜测：难道客户给我连错服务器了?
查看用户是有oracle用户的
[root@zjltdb home]# lsoracle
那看看告警日志吧，也无法找到数据库警告日志？
[root@zjltdb home]# find -name alert_*
空
查看数据库环境变量
确实也有oracle的痕迹，也不会是oracle客户端
继续检查，发现Oracle家目录下没有文件
和客户沟通，数据库服务器数据存储在磁盘柜，停电时，数据库服务器和磁盘柜均异常断电；
继续猜测：
猜测来电启动时，磁盘柜启动速度慢于数据库服务器启动速度，导致数据库服务器启动时无法成功挂载磁盘，导致目录丢失？
查看自动挂载情况
[oracle@zjltdb oracle]$ mount/dev/sda2 on oracle type ext4 (rw)
umount oracle，重新手动挂载
[oracle@zjltdb oracle]$ umount dev/sda2[oracle@zjltdb oracle]$ mount dev/sda2 oracle
/oracle仍然没有文件
让客户重启数据库服务器，启动之后发现/oracle目录仍然没有文件
结论：
/oracle目录下文件并不是没有挂载，而是真没了！
查看三大核心(控制文件，日志文件，数据文件)文件还在，但是不是完整的就不一定了。
[root@zjltdb home]# find / -name *.ctl/oradata/ncdb/control01.ctl/oradata/ncdb/control02.ctl/oradata/ncdb/control03.ctl
[root@zjltdb home]# find / -name redo*/oradata/ncdb/redo01.log/oradata/ncdb/redo02.log/oradata/ncdb/redo03.log
[root@zjltdb home]# find / -name *.dbf/oradata/ncdb/nnc_data01.dbf/oradata/ncdb/nnc_index01.dbf/oradata/ncdb/system01.dbf/oradata/ncdb/undotbs01.dbf......
查看参数文件，监听文件已经丢失
[root@zjltdb home]# find / -name init*空root@zjltdb home]# find / -name listener*空
丢失的文件有：
参数文件，监听文件，TNS文件，Oracle安装目录(包括Oracle命令等)
并且没有有效的备份：
客户说数据库没有启动归档，没有RMAN备份，expdp逻辑备份只备份一个用户，而生产环境下有四个主要用户，其他三个用户均没有任何备份。
解决方案：
重新配置Oracle软件，重新配置参数文件，监听文件等
客户没有安装介质，也不知道具体oracle版本，但是正式数据库和应用服务器上的测试数据库是一起搭建的，客户推测两个数据库版本相同，可以复制应用服务器Oracle_home目录到数据库服务器，也再一次验证了，客户的话不能全信！
一：将测试库的ORACLE_HOME文件拷贝到生产库服务器
[root@cjcdb01 ~]# scp -r 192.0.0.xx:/oracle/* /oracle[root@cjcdb01 ~]# cd /oracle[root@cjcdb01 oracle]# lsorainventory adminproduct
由于两个数据库的SID和目录名不同，需要更改相应的目录名和实例名
二：禁用spfile参数文件
[oracle@cjcdb01 dbs]$ mv spfileerpdb.ora spfileerpdb.ora.bak
三：重命名pfile参数文件
[oracle@cjcdb01 dbs]$ mv initerpdb.ora initncdb.ora
四：修改参数文件
[oracle@cjcdb01 dbs]$ vi initncdb.ora
五：修改监听文件
[oracle@zjltdb admin]$ vim listener.ora
六：启动数据库：
分析启动报错原因：
参数文件记录的数据库版本和控制文件记录的数据库版本不一致，原库版本是10.2.0.3.0，但是拷贝过来的数据库软件属于10.2.0.4.0；
解决方案：
修改参数compatible版本为10.2.4.0
[oracle@zjltdb dbs]$ vim initncdb.ora
七：再次启动数据库
可以成功挂载数据库，但是无法open数据库，原因还是因为数据库版本不匹配
查看警告日志
[oracle@zjltdb trace]$ vim alert_ncdb.log
悲剧了，新拷过来的软件版本比之前的软件版本高，也不是之前客户反馈的相同版本，数据库需要以UPGRADE方式启动。
八：以UPGRADE方式启动数据库
此时数据库状态为OPEN MIGRATE
数据库OPEN MIGRATE状态下无法连接NC用户，只允许sysdba用户连接
继续解决：
没时间在找新的软件包了，只能继续将数据库升级到10.2.0.4.0版本了。
九：执行数据库升级脚本(重新创建数据字典和视图)
升级之前备份所有的数据文件，控制文件，日志文件到本地
SQL >@/oracle/product/10.2/rdbms/admin/catupgrd.sql......
过程比较漫长，大概1小时
十 再次启动数据库，可以正常open
十一 ：启动监听后，进入NC系统，发现NC数据一切正常
十二：让客户尽快做备份
1 expdp对所有用户做逻辑备份2 备份/oracle目录到本地
问题再起？
第二天早上，用户发来消息，NC再次出现无法登录，登录到/oracle目录又变空了，并且用户昨天晚上并没有来得及做任何备份，他说太晚了，想早上在做备份。用户希望可以再做一次恢复。
猜测问题原因：
1 人员恶意删除2 定时计划任务脚本不合理，导致/oracle目录丢失3 /oracle所在磁盘出现问题4 其他
解决方案：
1 重复昨天的恢复操作2 修改oracle环境变量，将oracle_home指向其他磁盘3 全库备份，备份文件拷贝到本地4 启动数据库，启动监停，登录NC，查看NC数据，一切正常
后面/oracle目录又出现文件丢失的问题，因为这次修改了oracle_home目录，所以数据库是没问题的。
建议用户让服务器硬件厂商尽快检查磁盘健康情况；
###chenjuchao 20240415###
欢迎关注我的公众号《IT小Chen》
后记：
后来客户又给我反馈了一个重要现象，linux图形界面进入操作系统后，看到回收站里存在大量文件，手动清空回收站后，发现/oracle目录下所有文件也会自动跟着清空，这也是为什么之前oracle_home家目录文件总丢失的原因，不清楚linux回收站和/oracle目录下文件有什么关联，有清楚的朋友请留言。
