問題背景：
我負責的數據庫服務器中，有2台是不是會出現分區只讀，此時數據庫停止寫入數據，數據庫基本不可用了。我只能關閉數據庫，卸載文件系統，重新掛載文件系統，然後再打開數據庫就解決了。問題出現的可能點比較多，光纖交換機、存儲、服務器硬件、光纖卡、硬盤、操作系統驅動、數據庫等都有可能，我從DBA的角度檢查了Oracle這一塊沒問題，fsck檢查發現文件系統也無損壞，負責服務器硬件的兄弟不給力，HP、SUSE廠商也都說不出問題到底出在哪裡？我就只能自己想辦法，在網上搜索出下面這篇文章，感覺說得比較全面。
服務器信息：HP DL388G8/ DL580G7
操作系統信息：SUSE Linux11SP1
數據庫信息： Oracle10.2.0.5
存儲及光纖交換機：均為HP系列
出現問題頻率：多的每周2次，少的1月一次。
解決辦法：
升級操作系統至SUSE Linux 11SP2版本。
服務器掛載的遠端分區（從存儲上劃分的卷），一開始是直接就掃描不到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行業的硬件平台標准化？
