Problems, Challenges, And Constraints - HP StorageWorks 8000 - NAS User Manual

The redundancy engineered into the VA 7xxx protects against data loss due to write cache failure in all
single failure scenarios. As miniscule as the possibility is, there is a very slight possibility that a catastrophic
failure could destroy both banks of the NVRAM. If both banks of the NVRAM were destroyed, the data in
the write cache of the NVRAM would be lost. Please note that this NVRAM failure scenario is not unique
to NAS devices, but also exists in direct-attach RAID/disk controllers that use NVRAM.
Consider the scenario where the database data files are distributed between the NAS 8000 and the
server's direct–attached storage. A multi-query transaction that modifies data physically located on the
NAS 8000 and also physically located on the server's storage completes without error. The data is
committed on all devices, but the changes are not immediately written to the NAS 8000's hard drives
because they are staged in NVRAM write cache. The changes are written to the server's direct attach
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. 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 SDM 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 SDM) 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

The current implementation of the CIFS protocol on server and clients (not on the NAS 8000) is reported to
have a problem that can affect the "write atomicity" of an Oracle data block. Write Atomicity refers to the
writing of a complete Oracle data block in one "un-interruptible" operation. There is a very slight possibility
of accessing "stale" data when write atomicity is not guaranteed.
Until AutoPath or some HBA Failover mechanism 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.
13