序言:

非标题党,本文是我2015年初到一家公司工作三个月后的转正述职时讲的案例中标麒麟linux,入职这家某国产ERP公司数据库技术支持岗位后,每晚接触到大量的故障问题,包括数据库宕机、性能优化等,也是我成长最快的几年。

问题现象:

15年的某日,一大早收到了一个紧急恢复的问题:

从工单描述上不难看出,顾客十分着急!

问题剖析:

与顾客沟通,机房异常断电,来电重启应用服务器和数据库服务器后,登陆NC系统,输入用户名和密码登陆后报错如下:

初步怀疑:

1.数据库或窃听没配置手动启动,顾客不晓得如何启动;

2.机房断电造成数据库的某个文件受损,例如控制文件、日志文件、数据文件等。

具体是那个文件受损,就要看数据库能启动到那个阶段了。

验证推测:

登陆数据库服务器,切换到oracle用户,发觉没有sqlplus?

猜想:莫非顾客给我连错服务器了?

查看用户是有oracle用户的

[root@zjltdb home]# lsoracle

oracle12c启动监听_linux下启动oracle监听_linux下启动oracle监听

那瞧瞧告警日志吧,也难以找到数据库警告日志?

[root@zjltdb home]# find / -name alert_*

查看数据库环境变量

确实也有oracle的痕迹,也不会是oracle顾客端

linux下启动oracle监听_linux下启动oracle监听_oracle12c启动监听

继续检测,发觉Oracle家目录下没有文件

和顾客沟通,数据库服务器数据储存在c盘柜,停水时,数据库服务器和c盘柜均异常断电;

继续推测:

推测来电启动时,c盘柜启动速率慢于数据库服务器启动速率,造成数据库服务器启动时未能成功挂载c盘,致使目录遗失?

查看手动挂载情况

linux下启动oracle监听_linux下启动oracle监听_oracle12c启动监听

[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一直没有文件

linux下启动oracle监听_linux下启动oracle监听_oracle12c启动监听

让顾客重启数据库服务器,启动以后发觉/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@cjcdb01dbs]$viinitncdb.ora

oracle12c启动监听_linux下启动oracle监听_linux下启动oracle监听

五:更改窃听文件

[oracle@zjltdb admin]$ vim  listener.ora

linux下启动oracle监听_linux下启动oracle监听_oracle12c启动监听

六:启动数据库:

linux下启动oracle监听_linux下启动oracle监听_oracle12c启动监听

剖析启动报错缘由:

参数文件记录的数据库版本和控制文件记录的数据库版本不一致,原库版本是10.2.0.3.0,并且拷贝过来的数据库软件属于10.2.0.4.0;

解决方案:

更改参数compatible版本为10.2.4.0

[oracle@zjltdb dbs]$ vim  initncdb.ora

linux下启动oracle监听_linux下启动oracle监听_oracle12c启动监听

七:再度启动数据库

linux下启动oracle监听_linux下启动oracle监听_oracle12c启动监听

可以成功挂载数据库,并且难以open数据库,缘由还是由于数据库版本不匹配

查看警告日志

[oracle@zjltdb trace]$ vim alert_ncdb.log

linux下启动oracle监听_linux下启动oracle监听_oracle12c启动监听

惨剧了,新拷过来的软件版本比之前的软件版本高,也不是之前顾客反馈的相同版本,数据库须要以UPGRADE形式启动。

八:以UPGRADE形式启动数据库

linux下启动oracle监听_oracle12c启动监听_linux下启动oracle监听

此时数据库状态为OPENMIGRATE

数据库OPENMIGRATE状态下难以联接NC用户,只容许sysdba用户联接

linux下启动oracle监听_linux下启动oracle监听_oracle12c启动监听

继续解决:

没时间在找新的软件包了linux下启动oracle监听,只能继续将数据库升级到10.2.0.4.0版本了。

九:执行数据库升级(重新创建数据字典和视图)

升级之前备份所有的数据文件,控制文件,日志文件到本地

SQL >@/oracle/product/10.2/rdbms/admin/catupgrd.sql......

过程比较漫长,大约1小时

十再度启动数据库,可以正常open

oracle12c启动监听_linux下启动oracle监听_linux下启动oracle监听

十一:启动窃听后,步入NC系统,发觉NC数据一切正常

十二:让顾客尽早做备份

1 expdp对所有用户做逻辑备份2 备份/oracle目录到本地

问题再起?

第二天早晨,用户发来消息ubuntu linux,NC再度出现难以登陆,登陆到/oracle目录又变空了,但是用户今天下午并没有来得及做任何备份,他说太晚了,想晚上在做备份。用户希望可以再做一次恢复。

推测问题缘由:

1 人员恶意删除2 定时计划任务不合理,导致/oracle目录丢失3 /oracle所在磁盘出现问题4 其他

解决方案:

1 重复昨天的恢复操作2 修改oracle环境变量,将oracle_home指向其他磁盘3 全库备份,备份文件拷贝到本地4 启动数据库,启动监停,登录NC,查看NC数据,一切正常

前面/oracle目录又出现文件遗失的问题,由于此次更改了oracle_home目录,所以数据库是没问题的。

建议用户让服务器硬件厂商尽早检测c盘健康情况;

###chenjuchao20240415###

欢迎关注我的公众号《IT小Chen》

自序:

后来顾客又给我反馈了一个重要现象,linux图形界面步入操作系统后,看见回收站里存在大量文件,自动清空回收站后linux下启动oracle监听,发觉/oracle目录下所有文件也会手动跟随清空,这也是为何之前oracle_home家目录文件总遗失的缘由,不清楚linux回收站和/oracle目录下文件有哪些关联,有清楚的同学请留言。

本文原创地址://lrxjmw.cn/mgcegssjkjsz.html编辑:刘遄,审核员:暂无