HP StorageWorks 8000 NAS - Manual (Page 15)

disks. Before the data is flushed from the write cache of the NAS 8000, there is a catastrophic failure that
destroys all NVRAM in the NAS 8000. When the NAS 8000 is recovered and the database is restarted,
the data will be in an inconsistent state because data located on the server from the transaction was
modified, but data located on the NAS 8000 was not. In this case, the best method of recovery would be
to perform a change-based recovery to recover the database to some stable state prior to the catastrophic
failure. Depending upon VA 7xxx configuration settings, at most ten seconds of write-cached data are
vulnerable. Default settings would have no more than four seconds of write cache data vulnerable.
Although the possibility of this failure scenario is extremely small, it must be considered if the storage design
for a database implementation calls for the data to be distributed between the Oracle server and the NAS
8000. Note that as mentioned before, this vulnerability exists (depending upon the RAID controller used)
even when data is distributed between the server’s direct attach disks and a direct attach RAID controller.
In fact, the NAS 8000’s use of mirrored NVRAM is safer than any direct-attach RAID or hard drive
controller that uses un-mirrored NVRAM. The redundancy designed into the VA arrays greatly reduces the
chances for this type of failure, but does not eliminate them altogether.
The VA 7xxx has a tunable parameter, Data Resiliency, which can be used to “tune” the use of NVRAM.
This parameter is accessed from the Command View VA GUI. Access to the Command View VA GUI can
be gained from the 'Status' tab, the 'Storage' Tab, or the 'Support' tab in the Command View NAS GUI.
Data Resiliency is found (in Command View VA) under the 'Configuration' Tab, under the 'Array Settings'
button. Setting Data Resiliency to “High Performance” is not recommended for a NAS 8000 that is storing
database data files, as “High Performance” minimizes flushing the write cache to the hard drives and
thereby would place more data “at risk” in the above scenario. The “Normal” Data Resiliency setting is the
factory default. It forces a flush of Write Cache to the hard drives at a maximum of every four seconds.
The “Restricted” setting is the same as “Normal”, but allows the “immediate report” feature of write cache
to be disabled as well as flushing the write cache for the associated LUN before completing the write
request. The “Secure” Data Resiliency setting forces write cache to be flushed to the hard drives at a
maximum of every one second, as well as allowing the “immediate report” feature of write cache to be
disabled (like the restricted setting). In order for a write command to disable the “immediate report”
feature, the Data Resiliency setting of the array must be ‘Restricted’ or ‘Secure’ and the FUA (Force Unit
Access) bit in the write command must be set. It is recommended that the DBA and the NAS 8000
administrator discuss the merits of each Data Resiliency setting based on the environment and the
applications using the NAS 8000. If database data files are stored on both the Oracle server and on the
NAS 8000 it is recommended that Data Resiliency be set to ‘Secure’ as this will further reduce the
vulnerability to multiple NVRAM failure. In order to totally remove the possibility for the data corruption,
place all of the data/log files that can change on the NAS 8000 or all of the data/log files that can
change on the Oracle server.
problems, challenges, and constraints
Until HP AutoPath or some form of HBA Failover is implemented in the NAS 8000, it will be necessary to
reboot the NAS 8000 in order for the secondary controller to provide access to a failed controllers data.
Oracle Parallel Server is currently not supported.
Clustered configurations of the NAS 8000 are currently being tested and are not yet supported.
It is not permissible to use HP Virus Guard Real Time Protection on a file volume that contains an nfs export.
However, it is possible to perform a scheduled virus scan on file volumes with nfs exports. Performing a
virus scan during periods of heavy database traffic can cause excessive system performance degradation.
Additionally, if a file volume that is being protected by the Real Time Protection agent of Virus Guard, is
located in the same volume group as file volumes containing nfs exports, there may be significant
performance degradation if there is traffic on the nfs mount. It is always best, when possible, to ensure that
any file volumes with SMB/CIFS shares being protected by Virus Guard Real Time Protection are
not
located in volume groups containing any file volumes with nfs exports.
product information
15