首先声明，我是一个菜鸟。一下文章中现出技术误导情况盖不责负
题问背景：
我责负的据数库服务器中，有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
文章结束给大家分享下程序员的一些笑话语录：
IBM和波音777
波音777是有史以来第一架完全在电脑虚拟现实中设计制造的飞机，所用的设备完全由IBM公司所提供。试飞前，波音公司的总裁非常热情的邀请IBM的技术主管去参加试飞，可那位主管却说道:“啊，非常荣幸，可惜那天是我妻子的生日，So..”..
波音公司的总载一听就生气了:“胆小鬼，我还没告诉你试飞的日期呢!”