Linux服务器重启后crs_stat -t 命令无法正常使用以及解决思路

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

1、

[[email protected]:/home/grid]$crsctl status res -t
-bash: crsctl: command not found

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

[[email protected]:/home/grid]$env |grep gri
USER=grid
ORACLE_BASE=/oracle/app/grid
MAIL=/var/spool/mail/grid
PATH=.:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/grid/bin:/home/grid/bin:/oracle/app/11.2.0/grid/bin
PWD=/home/grid
PS1=[[email protected]:$PWD]$
HOME=/home/grid
LOGNAME=grid
ORACLE_HOME=/oracle/app/11.2.0/grid
[[email protected]:/home/grid]$

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

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

[[email protected] ~]$ df -lh
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        95G  4.5G   86G   5% /
tmpfs           996M   72K  996M   1% /dev/shm
/dev/sdb1        50G  8.3G   39G  18% /oradata
/dev/sdb2        20G  7.4G   12G  40% /soft

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

[[email protected] ~]# more /etc/fstab 

#
# /etc/fstab
# Created by anaconda on Fri May 19 04:21:30 2017
#
# Accessible filesystems, by reference, are maintained under ‘/dev/disk‘
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=a6cc0566-d29b-44fa-8741-b78170483210 /                       ext4    defaults        1 1
UUID=8a211faf-b2d7-4384-9c9d-fc25cb79f19b /oradata                ext4    defaults        1 2
UUID=08d48193-8c4e-40e9-a333-47fe86568029 /soft                   ext4    defaults        1 2
UUID=6e9b041a-1687-430f-9209-c06b6558e6fe swap                    swap    defaults        0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

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

[[email protected] ~]# sudo blkid
/dev/sda1: UUID="a6cc0566-d29b-44fa-8741-b78170483210" TYPE="ext4"
/dev/sda2: UUID="6e9b041a-1687-430f-9209-c06b6558e6fe" TYPE="swap"
/dev/sdb1: UUID="8a211faf-b2d7-4384-9c9d-fc25cb79f19b" TYPE="ext4"
/dev/sdb2: UUID="08d48193-8c4e-40e9-a333-47fe86568029" TYPE="ext4"
/dev/sdc1: UUID="07af4d45-14d3-4a8f-89ae-53a276f7c01e" TYPE="ext4"
/dev/asm_grid1: TYPE="oracleasm"
/dev/asm_system: TYPE="oracleasm"
/dev/asm_recovery: TYPE="oracleasm"
/dev/asm_data01: TYPE="oracleasm"
/dev/asm_data02: TYPE="oracleasm"
[[email protected] ~]# more /etc/fstab

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

[[email protected] ~]# lsblk -f
NAME   FSTYPE  LABEL                  UUID                                 MOUNTPOINT
sda                                                                        
├─sda1 ext4                           a6cc0566-d29b-44fa-8741-b78170483210 /
└─sda2 swap                           6e9b041a-1687-430f-9209-c06b6558e6fe [SWAP]
sdb                                                                        
├─sdb1 ext4                           8a211faf-b2d7-4384-9c9d-fc25cb79f19b /oradata
└─sdb2 ext4                           08d48193-8c4e-40e9-a333-47fe86568029 /soft
sdd                                                                        
└─sdd1                                                                     
sde                                                                        
└─sde1                                                                     
sdf                                                                        
└─sdf1                                                                     
sdg                                                                        
└─sdg1                                                                     
sdh                                                                        
└─sdh1                                                                     
sr0    iso9660 RHEL_6.5 x86_64 Disc 1

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

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

Linux UUID的作用及意义

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

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

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

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

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

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

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

[[email protected] ~]# more /etc/fstab 

#
# /etc/fstab
# Created by anaconda on Fri May 19 04:21:30 2017
#
# Accessible filesystems, by reference, are maintained under ‘/dev/disk‘
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=a6cc0566-d29b-44fa-8741-b78170483210 /                       ext4    defaults        1 1
UUID=8a211faf-b2d7-4384-9c9d-fc25cb79f19b /oracle                 ext4    defaults        0 0
UUID=07af4d45-14d3-4a8f-89ae-53a276f7c01e /oradata                ext4    defaults        0 0
UUID=08d48193-8c4e-40e9-a333-47fe86568029 /soft                   ext4    defaults        0 0
UUID=6e9b041a-1687-430f-9209-c06b6558e6fe swap                    swap    defaults        0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

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

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

[[email protected] ~]# mount
/dev/sda1 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sdb2 on /soft type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/sdc1 on /oradata type ext4 (rw)
/dev/sdb1 on /oracle type ext4 (rw)

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

[[email protected] ~]# reboot

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

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

[[email protected]:/home/grid]$crs_stat -t
Name           Type           Target    State     Host        
------------------------------------------------------------
ora....TA01.dg ora....up.type ONLINE    ONLINE    udevasm     
ora....TA02.dg ora....up.type ONLINE    ONLINE    udevasm     
ora....VERY.dg ora....up.type ONLINE    ONLINE    udevasm     
ora....STEM.dg ora....up.type ONLINE    ONLINE    udevasm     
ora.GRID1.dg   ora....up.type ONLINE    ONLINE    udevasm     
ora....ER.lsnr ora....er.type ONLINE    ONLINE    udevasm     
ora.asm        ora.asm.type   ONLINE    ONLINE    udevasm     
ora.cssd       ora.cssd.type  ONLINE    ONLINE    udevasm     
ora.diskmon    ora....on.type OFFLINE   OFFLINE               
ora.evmd       ora.evm.type   ONLINE    ONLINE    udevasm     
ora.ons        ora.ons.type   OFFLINE   OFFLINE               
ora.udevasm.db ora....se.type OFFLINE   OFFLINE

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

[[email protected] ~]# lsblk -f
NAME   FSTYPE  LABEL                  UUID                                 MOUNTPOINT
sda                                                                        
├─sda1 ext4                           a6cc0566-d29b-44fa-8741-b78170483210 /
└─sda2 swap                           6e9b041a-1687-430f-9209-c06b6558e6fe [SWAP]
sdb                                                                        
├─sdb1 ext4                           8a211faf-b2d7-4384-9c9d-fc25cb79f19b /oracle
└─sdb2 ext4                           08d48193-8c4e-40e9-a333-47fe86568029 /soft
sdc                                                                        
└─sdc1 ext4                           07af4d45-14d3-4a8f-89ae-53a276f7c01e /oradata
sdd                                                                        
└─sdd1                                                                     
sde                                                                        
└─sde1                                                                     
sdf                                                                        
└─sdf1                                                                     
sdg                                                                        
└─sdg1                                                                     
sdh                                                                        
└─sdh1                                                                     
sr0    iso9660 RHEL_6.5 x86_64 Disc 1

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

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

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

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

有关在linux系统中fstab配置文件详解说明

参考：http://xiaocao13140.blog.51cto.com/6198256/1930572

有关在Linux磁盘分区UUID的获取及其UUID的作用

参考：http://xiaocao13140.blog.51cto.com/6198256/1930571

时间： 2024-10-13 16:19:38

Linux服务器重启后crs_stat -t 命令无法正常使用以及解决思路的相关文章

rsyslog 服务器重启后 发现不能接受到外部日志 只能接受本地日志 关闭防火墙即可

rsyslog 服务器重启后 发现不能接受到外部日志 只能接受本地日志  关闭防火墙即可 1 关闭防火墙: # systemctl stop firewalld 2 将SELINUX设置为disabled # setenforce 0 # sed -i 's#SELINUX=enforcing#SELINUX=disabled#g' /etc/selinux/config

PHPWAMP自启异常，服务器重启后Apache等服务不会自动重启的原因分析

在使用"PHPWAMP自动任务"时,不少学生遇到如下问题: "phpwamp绿色集成环境重启动电脑(服务器)后,不会自动启动网站服务" (如果是其他环境或是自己搭建时遇到此问题,也是可以用此法解决) 此文章内容符合: 为什么网站服务由手动变成自动后还是无法重启? 为什么我把服务设置成自动后,开机又变回手动了? 为什么服务器(电脑)重启后服务不会自动跟着重启? windows服务器重启后网站服务不会自动重启的原因分析. 为什么服务设置成自动后,重启动服务器(电脑)服务

服务器重启后Oracle监听服务没有自动启动的解决方案

最近一直在被这样一个问题烦恼,就是服务器断电重启后,Oracle监听服务没有正常自动启动(监听服务已经设置为自启动). 具体是这样的,监听服务设置为开机自启动,Oracle数据库服务设置为开机延时启动,按道理这个应该符合“先启动监听,后启动数据库服务”这个条件,但是每次断电重启后都是数据库服务正常启动了,监听服务没能启动. 查阅了一下,有这么两个说法,感觉还是挺有道理: 1.一般设置了开机自启动的服务要手动,基本是注册表不一致造成: 2.登录账号跟你安装Oracle的账号不一样,没权限启动. 针

SMB服务器重启后自动挂载失效

上周五公司停电,这周回来上班后发现公司SMB服务器无法访问,SSH到服务器,df一下,发现挂载记录丢失,如下图,正常情况下应该有一条/dev/sdb1挂载在mnt的记录. 既然挂载丢失,手动挂载一下下,mount /dev/sdb1 /mnt可恢复访问,但服务器重启后现象依旧,难道自动挂载记录也丢失了,我们来看一下fstab: 发现挂载记录还在,那运行一下mount -a吧,看挂载是否有问题: 果不其然,报错了,看来问题还是出在挂载这一块,仔细检查了下fstab文件,终于找到问题所在了,原来是磁

检查Linux服务器性能的关键十条命令

检查Linux服务器性能的关键十条命令 概述 通过执行以下命令,可以在1分钟内对系统资源使用情况有个大致的了解. uptime dmesg | tail vmstat 1 mpstat -P ALL 1 pidstat 1 iostat -xz 1 free -m sar -n DEV 1 sar -n TCP,ETCP 1 top 其中一些命令需要安装sysstat包,有一些由procps包提供.这些命令的输出,有助于快速定位性能瓶颈,检查出所有资源(CPU.内存.磁盘IO等)的利用率(uti

Linux服务器启动后只读解决办法

今天处理一个服务器,远程死活连接不上,只好跑信息中心去看了下服务器. Linux服务器启动之后,提示: give root password for maintenance (or type control-d to continue:) 输入root 密码后,进入系统了. 具体如下图: 但是系统是只读的. 这里可以看出来是 home 分区出了问题没有挂载上.我想修改fstab文件,但是系统是只读的,没有办法修改. mount -o remount , rw / 然后系统就可以写了. 这时修改

linux操作系统重启后 解决nginx的pid消失问题

重启了linux服务器之后,进程性的 nginx -s stop后再次启动nginx -s reload ,总是会报错误nginx: [error] open() "/alidata/server/nginx/logs/nginx.pid" failed (2: No such file or directory),这应该是因为把nginx进程杀死后pid丢失了,下一次再开启nginx -s reload时无法启动,重装可以解决这个问题,但是太麻烦了. issued a nginx -

服务器重启后 django无法连接mysql数据库的解决方法

问题描述: 远程linux服务器,centOS7系统 采用uwsgi+django+pymysql的方式连接mysql数据库. 在服务器重启之后, 启用uwsgi之后(直接运行django运行命令也是一样python manage.py runserver), 无法连接到数据库. 报错: cryptography is required for sha256_password or caching_sha2_password 解决方法: 1. 手动连接数据库一次 mysql -u root -p

服务器重启后SQL Server Agent由于"The EventLog service has not been started" 启动失败

案例环境: 操作系统   : Microsoft Windows Server 2003 Standard Edtion SP2 数据库版本 : SQL Server 2005 Standard Edition SP4 案例描述: 服务器重启过后,MSSQLSERVER服务自动重启了,但是SQLSERVERAGENT服务启动失败(当然SQL Agent服务的启动类型为自动启动(Automatic)),在这台服务器第二次遇到这种情况,第一次遇到时没太注意,以为只是特殊案例,直到在这台服务器第二次遇