中英双语外贸网站源码,扬州网站建设企业,刘晓忠 网站建设,wordpress防盗图前提#xff1a;在Linux系统中安装ASM#xff0c;安装完ASM和Oracle数据库时都是正常使用的#xff0c;但在重启服务器后Oracle相关命令不识别。1、[gridudevasm:/home/grid]$crsctl status res -t
-bash: crsctl: command not found2、查看环境变量是否正常#xff0c;命令… 前提在Linux系统中安装ASM安装完ASM和Oracle数据库时都是正常使用的但在重启服务器后Oracle相关命令不识别。1、[gridudevasm:/home/grid]$crsctl status res -t
-bash: crsctl: command not found2、查看环境变量是否正常命令如下[gridudevasm:/home/grid]$env |grep gri
USERgrid
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[gridudevasm:$PWD]$
HOME/home/grid
LOGNAMEgrid
ORACLE_HOME/oracle/app/11.2.0/grid
[gridudevasm:/home/grid]$3、通过查询结果初步判断环境变量是正常的然后通过另外一个角度去考虑是不是Oracle程序本身安装有问题因为昨天系统才安装过ASM和Oracle数据库测试都是正常的应该讲没有啥问题才对但是突然间想起在服务器重启的时候启动界面提示要加载文件系统而且时间很长截图如下4、通过在启动时提示的信息就是查看文件系统是否有问题想起之前硬盘挂载在不同的路径下命令如下[oracleudevasm ~]$ 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% /soft5、通过上面命令查询结果发现问题所在因为sdb1我调整挂载在/oracle路径下的原来的sdc1是挂载/oradata路径由于sdc1mount在/oradata路径下没有设置在开机时启动而且sdb1是默认的启动从而导致在启动的sdc1挂载失败影响Oracle相关程序启动所以命令失败无法找到去查看fstab内容。[rootudevasm ~]# 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
#
UUIDa6cc0566-d29b-44fa-8741-b78170483210 / ext4 defaults 1 1
UUID8a211faf-b2d7-4384-9c9d-fc25cb79f19b /oradata ext4 defaults 1 2
UUID08d48193-8c4e-40e9-a333-47fe86568029 /soft ext4 defaults 1 2
UUID6e9b041a-1687-430f-9209-c06b6558e6fe swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid5,mode620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 06、通过命令查看后并没有发现oracle路径下的设备再通过查询UUID块设备下有哪些设备[rootudevasm ~]# sudo blkid/dev/sda1: UUIDa6cc0566-d29b-44fa-8741-b78170483210 TYPEext4 /dev/sda2: UUID6e9b041a-1687-430f-9209-c06b6558e6fe TYPEswap /dev/sdb1: UUID8a211faf-b2d7-4384-9c9d-fc25cb79f19b TYPEext4 /dev/sdb2: UUID08d48193-8c4e-40e9-a333-47fe86568029 TYPEext4 /dev/sdc1: UUID07af4d45-14d3-4a8f-89ae-53a276f7c01e TYPEext4 /dev/asm_grid1: TYPEoracleasm /dev/asm_system: TYPEoracleasm /dev/asm_recovery: TYPEoracleasm /dev/asm_data01: TYPEoracleasm /dev/asm_data02: TYPEoracleasm [rootudevasm ~]# more /etc/fstab 7、再通过lsblk -f 命令查询块设备下详细的信息如下[rootudevasm ~]# 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总可以使同一块卡挂载在同一个地方。原因3Ubuntu中的许多关键功能现在开始依赖于UUID9、通过第6步和第7步中可以把相关的修改成之前配置想要的内容修改内容如下[rootudevasm ~]# 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
#
UUIDa6cc0566-d29b-44fa-8741-b78170483210 / ext4 defaults 1 1
UUID8a211faf-b2d7-4384-9c9d-fc25cb79f19b /oracle ext4 defaults 0 0
UUID07af4d45-14d3-4a8f-89ae-53a276f7c01e /oradata ext4 defaults 0 0
UUID08d48193-8c4e-40e9-a333-47fe86568029 /soft ext4 defaults 0 0
UUID6e9b041a-1687-430f-9209-c06b6558e6fe swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid5,mode620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0注意后面的数字修改成0 0如果不设置0的话服务器在启动的时候就会检测如果硬盘满的话就会导致操作系统无法正常启动此处应该让系统禁止检测10、注意再mount 一下判断是否挂载成功如果挂载有问题会导致系统无法正常启动[rootudevasm ~]# 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,gid5,mode620)
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、重启一下服务器判断设备挂载是否成功 [rootudevasm ~]# reboot重启时服务器系统启动时间快就没有之前那种提示要加载文件系统内容12、系统启动成功后用grid用户查看ASM状态[gridudevasm:/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 命令查询块设备下详细的信息如下[rootudevasm ~]# 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 转载于:https://blog.51cto.com/xiaocao13140/1930577
