Problem Background:
In my database server, are two partitions Read-Only? At this time, the database stops writing data, and the database is basically unavailable. I can only close the database, unmount the file system, Remount the file system, and then open the database. There are many possible problems, including optical fiber switches, storage, server hardware, optical fiber cards, hard disks, operating system drivers, and databases, I checked Oracle from the DBA's point of view and found that the file system was not damaged during the fsck check, HP and SUSE vendors cannot tell where the problem is? I can only search for the following article on the internet, and I feel that it is comprehensive.
Server Information: HP DL388G8/DL580G7
Operating System Information: SUSE Linux11SP1
Database Information: Oracle10.2.0.5
Storage and optical fiber switch: HP Series
Problem frequency: twice a week, less than January 1.
Solution:
Upgrade the operating system to SUSE Linux 11SP2.
The remote partition (volume divided from storage) mounted on the server cannot directly scan PV, VG, LV, and other information at the beginning, you must manually run the PVSCAN, VGSCAN, and LVSCAN commands to view the information. Later, the information cannot be automatically mounted with the system. No matter how you modify the fstab file, no response is returned.
Xxx-db :~ # More/etc/fstab
/Dev/disk/by-id/cciss-3600508b1001c2b630be086f93f71f626-part1 swap defaults 0 0
/Dev/disk/by-id/cciss-3600508b1001c230b6be086f39f71f626-part2/ext3 acl, user_xattr 1 1
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 verification parameter of the file partition table is too strict, so the original "1 2" is directly changed to "0 0", and the problem still cannot be solved.
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 automatic mounting of the file system. This should be a BUG During the SUSE system upgrade.
3. After that, the partition read-only problem does not occur again. It indicates that the system upgrade has solved the partition read-only problem. If there is still a problem in the future, I plan to ask the hardware engineer to update the optical fiber card driver and the server firmware.
Summary:
In fact, when building a system, we should do a good job of standardization, hardware firmware, optical fiber card, array card and other important hardware drivers are directly standardized on the version, operating system version standardization, in this way, we can minimize the problem factors beyond the oracle database. As a DBA, you can still have a narrow scope. You cannot understand everything and do not have the energy, therefore, this should be a concern of the above leaders. If you are lucky to take over the database and run it on standardized hardware, the only problem you need to solve is the database. If you are sad, then, you may have to work with people from various departments passively to solve various strange problems caused by non-standardization.
Eygle is promoting the standardization of database design and pre-planning. It is a great undertaking for Oracle DBAs to intervene in the software design and even the demand stage.
Who will promote the standardization of hardware platforms in the IT industry?