Page 156 - DCAP508_DATABASE_ADMINISTRATION

Database Administration

Notes The source database cannot be configured as a scalable shared database.
To create a database snapshot on a mirror database, the database must be in the
synchronized mirroring state.

Limitations on Database Snapshots

The following limitations apply to database snapshots:

A database snapshot must be created and remain on the same server instance as the source
database.

Database snapshots always work on an entire database.
Database snapshots are dependent on the source database. Therefore, using database
snapshots for reverting a database is not a substitute for your backup and restore strategy.
Performing all your scheduled backups remains essential. If you must restore the source
database to the point in time at which you created a database snapshot, implement a
backup policy that enables you to do that.
When a page getting updated on the source database is pushed to a snapshot, if the snapshot
runs out of disk space or encounters some other error, the snapshot becomes suspect and
must be deleted.
Snapshots are read-only.

Snapshots of the model, master, and tempdb databases are prohibited.
You cannot change any of the specifications of the database snapshot files.
You cannot drop files from a database snapshot.
You cannot back up or restore database snapshots.

You cannot attach or detach database snapshots.
You cannot create database snapshots on FAT32 file system or RAW partitions. The sparse
files used by database snapshots are provided by the NTFS file system.

Full-text indexing is not supported on database snapshots. Full-text catalogs are not
propagated from the source database.
A database snapshot inherits the security constraints of its source database at the time of
snapshot creation. Because snapshots are read-only, inherited permissions cannot be
changed and permission changes made to the source will not be reflected in existing
snapshots.
A snapshot always reflects the state of filegroups at the time of snapshot creation: online
filegroups remain online, and offline filegroups remain offline. For more information,
see “Database Snapshots with Offline Filegroups” later in this topic.
If a source database becomes RECOVERY_PENDING, its database snapshots may become
inaccessible. After the issue on the source database is resolved, however, its snapshots
should become available again.

Reverting is unsupported for read-only filegroups and for compressed filegroups. Attempts
to revert a database containing either of these types of filegroups fail.
In a log shipping configuration, database snapshots can be created only on the primary
database, not on a secondary database. If you switch roles between the primary server
instance and a secondary server instance, you must drop all the database snapshots before
you can set the primary database up as a secondary database.

150 LOVELY PROFESSIONAL UNIVERSITY