What if the Linux partition read-only causes the database to stop writing data?

In the Linux server, the Linux partition read-only phenomenon causes the database to be unable to input data. How to deal with this situation? The following small series will introduce you to the Linux partition read-only system that causes the database to stop writing data.

question:

I am responsible for the database server, there are not two there will be a read-only partition, then stop writing data database, database basically unusable. I can only close the database, unmount the file system, remount the file system, and then open the database to solve it. There are many possible problems. Fiber switch, storage, server hardware, fiber card, hard disk, operating system driver, database, etc. are all possible. I checked Oracle from the perspective of DBA, and fsck checked the file system. No damage, the brothers responsible for the server hardware are not strong, HP, SUSE vendors can not tell where the problem is? I can only find my own way, search the following article on the Internet, I feel more comprehensive.

Server Information: HP DL388G8/DL580G7

Operating System Information: SUSE Linux11SP1

Database Information: Oracle10.2.0.5

Storage and Fabric Switch: Both are HP series

The frequency of problems occurs: 2 times a week, less once a month.

Solution:

Upgrade the operating system to SUSE Linux 11SP2.

The remote partition mounted by the server (the volume divided from the storage) cannot directly scan the PV/VG/LV information at the beginning, and must be manually executed by the PVSCAN/VGSCAN/LVSCAN command. Seeing the information, it can't be automatically mounted with the system, no matter how to modify the fstab file.

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. It is suspected that the final check parameter of the file partition table is too strict, so it is directly changed from the original “1 2” to “0 0”, the result is still not Can solve the problem.

2, add the following script

xxx-db:/etc/init.d # more /etc/init.d/after.local

pvscan

vgscan

lvscan

mount /dev/mapper/oraclevg-oraclelv /oradata

Solved the file system automount problem, this should be during the SUSE system upgrade process BUG.

3, after, there is no partition read-only problem, indicating that the system upgrade has solved the partition read-only problem, if there are still problems, I plan to find hardware engineers to update the fiber-optic card driver and server firmware.

Summary:

In fact, when building a system, you should do standardization work. Hardware firmware, fiber card, array card and other important hardware drivers are directly standardized on the version, operating system version. Standardization, so that problems outside the oracle database can be excluded as low as possible.

The above is the introduction of the Linux partition read-only cause the database to stop writing data. Just upgrade your system to solve this problem.