HP StorageWorks 8000 NAS - Manual (Page 14)

hot backups using NAS 8000 snapshots
A hot backup (also known as an inconsistent backup) is usually performed by issuing an “alter tablespace”
command and placing the tablespaces (all, or whatever the backup plan calls for) into “backup mode”. In
this mode, changes to the tablespace are “logged” by the Oracle engine, but not actually written to the
tablespace until it is returned to “active mode”. Performing a hot backup leaves the database in an active
state, available for user access. Being an inconsistent backup implies that if a restore operation were
performed using this backup, a database recovery (along with succeeding transaction logs), would be
required. The first step would be to place the tablespace(s) in "backup" mode via the 'alter tablespace'
command. The snapshot is scheduled via the Command View NAS management GUI, and takes only a
moment to actually occur. Once the snapshot has been taken, the tablespace(s) are put back into "normal"
mode and an 'alter system switch logfile' command is executed to ensure that the archive log can be
applied to the database in the event of a recovery. The snapshot(s) are then backed up and can be deleted.
The database remains available while the snapshot(s) are being taken, and while the snapshot(s) are being
backed up. Be sure to backup the redo/archived logs so that the database can be recovered in the event
that a restore from an inconsistent backup is necessary.
hot backups without NAS 8000 snapshots
A hot backup can also be performed without utilizing NAS 8000 snapshots. This may be necessary if there
is not enough space available in the volume group for the snapshot to be created. In this scenario, the DBA
will place the tablespace(s) into backup mode as described above and Oracle will journal changes to the
tablespaces rather than applying them. When the backup completes, be sure to execute an ALTER SYSTEM
SWITCH LOGFILE command after the tablespace(s) are taken out of backup mode to make sure that the
alter tablespace command that took the tablespace out of backup mode is written to the archive log
immediately. This ensures that the archive log can be applied to the database in the event of a crash.
cold backups using NAS 8000 snapshots
A cold backup (also known as a consistent backup) is performed when the database is shutdown normally
and the database data files are made available for backing up (copying, writing to tape media, etc).
Because the database is shutdown, it is no longer available for user access. As well, since the database is
shutdown, the SCN numbers in all of the data files will match, and therefore, a restore operation performed
with this backup would not require a database recovery. Once the database has been stopped, a
snapshot is taken of the file volume(s) containing the database data files. This happens very quickly. After
the snapshot is taken, the database can be restarted, and the snapshot backed up to some other media,
such as magnetic tape. Using this scenario, the time the database is unavailable may be reduced from
hours to mere minutes. Once the backup has completed, the snapshot(s) can be deleted.
cold backups without NAS 8000 snapshots
A cold backup can be performed without utilizing the snapshot feature of the NAS 8000 in the event that
there is not enough available space in the volume group(s) to permit a snapshot operation. However, the
database will be unavailable for the length of time that the backup takes to complete. This could be from
several minutes to several hours depending upon the amount of data to be backed-up and the target media
for the backup.
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
14