Nvram Usage And Nvram Failures - HP StorageWorks 8000 - NAS User Manual

refer to the NAS 8000 Users Guide and the whitepaper NAS 8000 Backup Strategy (located off of the
NAS 8000 home page) for further details on these solutions.
There are four types of backup provided by SQL Server. In each backup scenario, the database remains
available for user, although some operations are not allowed during a backup. These operations include
(among others) creating new database files, or deleting database files, creating indexes, and performing a
non-logged operation such as a fast bulk copy. A full database backup involves backing up the entire
database, that is, all of the data files and all of the transaction logs. A file backup backs up a file or a file
group. A differential database backup backs up the changes in to the database since the last full backup,
including changes to the transaction logs while the backup was in progress. A transaction log backup
backs up the database's transaction log. If there is space available on the NAS 8000, the NAS 8000 can
be used not only to house the database data and log files, but can also be the target of the backup as a
disk file. The backup of the database to a disk file will be much faster than backing up the database to a
tape drive. Once the backup to the disk file is complete, the backup can be moved off of the NAS 8000
disks onto tape. In this manner, the length of time that the SQL database is in "backup mode" can be
minimized and potential database contention can also be minimized. Because SQL Server controls this
process, the use of the NAS 8000 snapshot feature is not recommended for a SQL backup. However, it is
possible to use the NAS 8000 snapshot feature to backup all of the data on the NAS 8000, including SQL
databases, as a separate process from a database backup. For more information on NAS 8000
snapshots, please refer to the NAS 8000 User's Guide as well as to the constraint section below.

nvram usage and nvram failures

The NAS 8000 storage subsystem (VA 7xxx) uses dual battery backed-up, mirrored NVRAM to increase
write performance to the hard drives. The NVRAM is mirrored across both controllers in the VA enclosure.
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, some form of database restore and
recovery would be necessary. The degree of the restore and recovery is dependent upon the backup
methodology used. 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 SQL Server
Windows 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 SDM 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
12