现在的位置: 首页 > 综合 > 正文

Suse Linux下分区只读问题的解决办法

2013年06月12日 ⁄ 综合 ⁄ 共 3515字 ⁄ 字号 评论关闭

 

问题背景:

我负责的数据库服务器中,有2台是不是会出现分区只读,此时数据库停止写入数据,数据库基本不可用了。我只能关闭数据库,卸载文件系统,重新挂载文件系统,然后再打开数据库就解决了。问题出现的可能点比较多,光纤交换机、存储、服务器硬件、光纤卡、硬盘、操作系统驱动、数据库等都有可能,我从DBA的角度检查了oracle这一块没问题,fsck检查发现文件系统也无损坏,负责服务器硬件的兄弟不给力,HP、SUSE厂商也都说不出问题到底出在哪里?我就只能自己想办法,在网上搜索出下面这篇文章,感觉说得比较全面。

 

服务器信息:HP DL388G8/ DL580G7

操作系统信息:SUSE Linux11SP1

数据库信息: Oracle10.2.0.5

存储及光纤交换机:均为HP系列

出现问题频率:多的每周2次,少的1月一次。

 

解决办法:

升级操作系统至SUSE Linux11SP2版本。

服务器挂载的远端分区(从存储上划分的卷),一开始是直接就扫描不到PV/VG/LV等信息,必须要手工执行PVSCAN/VGSCAN/LVSCAN命令才可以看到信息,后来不能随系统自动挂载,无论怎么修改fstab文件都没反应。

xxx-db:~ # more /etc/fstab
/dev/disk/by-id/cciss-3600508b1001c2b630be086f93f71f626-part1 swap   swap       defaults              0 0
/dev/disk/by-id/cciss-3600508b1001c230b6be086f39f71f626-part2 /  ext3       acl,user_xattr        1 1
proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
debugfs              /sys/kernel/debug    debugfs    noauto                0 0
usbfs                /proc/bus/usb        usbfs      noauto                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
#/dev/oraclevg/oraclelv /oradata             ext3       acl,user_xattr        1 2
/dev/oraclevg/oraclelv  /oradata             ext3       defaults        0 0
#/dev/mapper/36001438009b03d620000500000f90000   /oradata             ext3  defaults        0 0

1、怀疑是文件分区表最后的校验参数过于严格,于是由原来的“1 2”直接修改为“0 0”,结果依然未能解决问题。

2、添加如下脚本

xxx-db:/etc/init.d # more /etc/init.d/after.local
pvscan
vgscan
lvscan
mount /dev/mapper/oraclevg-oraclelv /oradata

解决了文件系统自动挂载问题,这个应该是SUSE系统升级过程中的BUG。

3、之后,没有再次出现分区只读问题,说明系统升级已经解决分区只读问题,后续如果还有问题,我打算再找硬件工程师更新光纤卡驱动和服务器固件。

 

总结:

其实一开始建设系统的时候,就应该做好标准化工作,硬件固件、光纤卡、阵列卡等重要硬件驱动都直接对版本标准化,操作系统版本标准化,这样就可以尽可能低排除oracle数据库以外的问题因素,作为一个DBA,你能涉及的面还是很窄的,你不可能去搞懂所有东西,也没那个精力,所以这个应该是上边领导要关注的事情。如果你很幸运,接管的数据库运行在标准化的硬件上,那你要解决的问题只是数据库的,如果你很悲催,那你可能就要经常被动地陪着各个相关部门的人加班,解决由于非标准化带来的各种千奇百怪的问题。

eygle他们在推动数据库设计和前期规划的标准化,希望Oracle DBA在软件设计甚至需求阶段就介入,这个是伟大的事业,祝愿早日成功。

谁来推动整个IT行业的硬件平台标准化?

 

——————————————————————————————————————————————————————————————

 

解决思路参考出处:

很久以前在网上搜索到的文章,转载出处:http://tc.itkee.com/os/detail-1f8c.html

 

在日常工作中,經常碰到服務器由於各種各樣的原因,出現IO只讀故障,將機器重啓後,故障就可以恢復,找不到具體故障原因。

目前已知的造成硬盤分區只讀的可能原因有:

文件系統錯誤

內核相關硬件驅動bug

FW固件類問題

磁盤壞道

硬盤背板故障

硬盤綫纜故障

HBA卡故障

RAID卡故障

1.文件系統錯誤。

如 ext3 文件系統錯誤,比較少見,ext3 文件系統是linux下非常穩定的文件系統,目前文件系統自身bug 造成的 ext3 文件系統錯誤,非常罕見。

當文件系統自身的校驗機制發現文件系統存在問題時,爲避免文件系統受到進一步的損壞,一般把文件系統設置爲只讀。

tune2fs 命令可以設置當操作系統內核發現有文件系統錯誤時,操作系統對該文件系統如何處理:

-e error-behavior

Change  the  behavior  of  the  kernel code when errors are detected.  In all cases, a filesystem error will cause

e2fsck(8) to check the filesystem on the next boot.  error-behavior can be one of the following:

continue    Continue normal execution.

remount-ro  Remount filesystem read-only.

panic       Cause a kernel panic.

此類只讀,一般可以通過自身的檢查工具,如 fsck ,進行修復。

2.磁盤壞道

A.對於單個硬盤的情況,當硬盤出現壞道,且不能夠被硬盤自身的糾錯機制恢復時,就會報IO錯誤,從而進一步影響上層文件系統導致只讀現象出現。

B.對於有冗餘raid 的情況,多個硬盤出現壞道導致 raid 卡檢驗機制無法恢復時,也會對外報該raid IO 錯誤。

badblocks  命令可以對磁盤壞道情況進行檢查,該命令位於 e2fsprogs 程序包內。

3.FW固件類問題

硬盤 fw bug

硬盤背板、擴展卡 fw bug

HBA卡 fw bug

raid 卡 fw bug

以及各部件 fw bug 不兼容

此類問題,只能夠反饋給相應廠家,由廠家協助處理。

4.內核相關硬件驅動bug

HBA卡、raid卡硬件的內核驅動,如果有bug ,也可能導致硬盤只讀。如硬盤出現錯誤時,驅動的錯誤處理機制 Error Handler 異常;或者對 SATA 協議的實現,不完全遵循標準。用sysctl  命令調整 dev.scsi.logging_level = 64 可以讓內核更多的顯示 scsi 層面的信息,有利於排錯。

5.硬盤背板、硬盤綫纜、HBA卡故障、RAID卡故障

這些部件出現故障,都可以造成硬盤只讀。這些部件,如果故障現象嚴重,還是比較容易判斷和發現,但對於偶爾不穩定,排查有時候會比較困難,一般是替換法處理。Raid 卡廠家一般有提供 linux 操作系統下的命令行工具,如:megacli hpacucli arrconf等

評論補充:

inode資源耗盡,也會導致分區只讀

某個分區出現寫滿問題後,會出現只讀故障。和OS有關係,和硬件關係不大

 

 

 

________________________________________________________________________

版权所有,文章允许转载,但必须以链接方式注明源地址,否则追究法律责任!

Author:   laven54 (lurou)

Email:    laven54@163.com

Blog:      http://blog.csdn.net/laven54

 

 

 

抱歉!评论已关闭.