前言:
非标题党,本文是我2015年初到一家公司工作三个月后的转正述职时讲的案例,入职这家某国产ERP公司数据库技术支持岗位后,每天接触到大量的故障问题,包括数据库宕机、性能优化等,也是我成长最快的几年。
问题现象:
15年的某天,一大早收到了一个紧急恢复的问题:
从工单描述上不难看出,客户非常着急!
问题分析:
与客户沟通,机房异常断电,来电重启应用服务器和数据库服务器后,登录NC系统,输入用户名和密码登录后报错如下:
初步怀疑:
1.数据库或监听没配置自动启动,客户不知道怎么启动;
2.机房断电导致数据库的某个文件损坏,比如控制文件、日志文件、数据文件等。
具体是哪个文件损坏,就要看数据库能启动到哪个阶段了。
验证猜想:
登录数据库服务器,切换到oracle用户,发现没有sqlplus命令?
猜测:难道客户给我连错服务器了?
查看用户是有oracle用户的
[root@zjltdb home]# ls
oracle
那看看告警日志吧,也无法找到数据库警告日志?
[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]# ls
orainventory
admin
product
由于两个数据库的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目录下文件有什么关联,有清楚的朋友请留言。