前提:在Linux系统中安装ASM,安装完ASM和Oracle数据库时都是正常使用的,但在重启服务器后Oracle相关命令不识别。

1、截图如下:

Linux服务器重启后crs_stat -t 命令无法正常使用_服务器

2、查看环境变量是否正常,命令如下:

Linux服务器重启后crs_stat -t 命令无法正常使用_系统启动_02

3、通过查询结果初步判断环境变量是正常的,然后通过另外一个角度去考虑,是不是Oracle程序本身安装有问题,因为昨天系统才安装过ASM和Oracle数据库,测试都是正常的,应该讲没有啥问题才对,但是突然间想起在服务器重启的时候,启动界面提示要加载文件系统,而且时间很长,截图如下:

Linux服务器重启后crs_stat -t 命令无法正常使用_服务器_03

4、通过在启动时提示的信息,就是查看文件系统是否有问题,想起之前硬盘挂载在不同的路径下,命令如下:

Linux服务器重启后crs_stat -t 命令无法正常使用_重启_04

5、通过上面命令查询结果,发现问题所在,因为sdb1我调整挂载在/oracle路径下的,原来的sdc1是挂载/oradata路径,由于sdc1mount在/oradata路径下没有设置在开机时启动,而且sdb1是默认的启动,从而导致在启动的sdc1挂载失败,影响Oracle相关程序启动,所以命令失败无法找到,去查看fstab内容。

Linux服务器重启后crs_stat -t 命令无法正常使用_系统启动_05

6、通过命令查看后,并没有发现oracle路径下的设备,再通过查询UUID块设备下有哪些设备

Linux服务器重启后crs_stat -t 命令无法正常使用_系统启动_06

7、再通过lsblk -f 命令查询块设备下详细的信息如下:

Linux服务器重启后crs_stat -t 命令无法正常使用_服务器_07

通过上述几个命令可以判断出是由于sdc1分区没有自动挂载导致Oracle程序没有办法启动

8、修改/etc/fstab配置文件,让sdc1设备在开机自动启动,最好通过UUID来挂载,因为:

Linux UUID的作用及意义

原因1:它是真正的唯一标志符

UUID为系统中的存储设备提供唯一的标识字符串,不管这个设备是什么类型的。如果你在系统中添加了新的存储设备如硬盘,很可能会造成一些麻烦,比如说启动的时候因为找不到设备而失败,而使用UUID则不会有这样的问题。

原因2:设备名并非总是不变的

自动分配的设备名称并非总是一致的,它们依赖于启动时内核加载模块的顺序。如果你在插入了USB盘时启动了系统,而下次启动时又把它拔掉了,就有可能导致设备名分配不一致。

使用UUID对于挂载移动设备也非常有好处──例如我有一个24合一的读卡器,它支持各种各样的卡,而使用UUID总可以使同一块卡挂载在同一个地方。

原因3:Ubuntu中的许多关键功能现在开始依赖于UUID

9、通过第6步和第7步中,可以把相关的修改成之前配置想要的内容,修改内容如下:

Linux服务器重启后crs_stat -t 命令无法正常使用_系统启动_08

注意:后面的数字修改成0 0,如果不设置0的话,服务器在启动的时候就会检测,如果硬盘满的话,就会导致操作系统无法正常启动,此处应该让系统禁止检测

10、注意:再mount 一下,判断是否挂载成功,如果挂载有问题会导致系统无法正常启动

Linux服务器重启后crs_stat -t 命令无法正常使用_服务器_09

11、重启一下服务器判断设备挂载是否成功 

Linux服务器重启后crs_stat -t 命令无法正常使用_系统启动_10

重启时,服务器系统启动时间快,就没有之前那种提示要加载文件系统内容

12、系统启动成功后用grid用户查看ASM状态:

Linux服务器重启后crs_stat -t 命令无法正常使用_系统启动_11

13、此时说明硬盘设置成自动重启正常,再用lsblk -f 命令查询块设备下详细的信息如下

Linux服务器重启后crs_stat -t 命令无法正常使用_服务器_12

通过上述说明,则可以判断我们设置成自动启动成功

总结:

1、在发现命令无法使用的时候,就要首先从可能导致这个命令的原因找问题,如果首先问题判断没有问题,再去判断其它方面的问题

2、系统在启动时会给我们一些详细的启动参数内容,如果有问题的也会详细打印出来,最好看一下系统启动的日志内容

3、在mount设备时,必须要让系统自己挂载,这样可以避免一些程序上面的问题,同时在使用UUID时也要注意,防止系统在启动时无法正常启动