An archive database has the following limitations:
An archive database is read-only.
An archive database is automatically in single-user mode when any command is run that results in changes to the archive database, such as dbcc commands.
An archive database uses only database dumps or transaction log dumps on disk. Tape dumps are not supported.
The database dump or transaction log dumps must be visible from the server that is hosting the archive database. Remote dumps are not supported.
For an archive database to access compressed dumps, the dump must have been created using the with compression option rather than the “compress::” option.
The checkpoint process does not automatically checkpoint an archive database. Use the checkpoint command to checkpoint an archive database.
You cannot use sp_dbrecovery_order to specify an archive database in the database recovery sequence. Archive databases are recovered last, in their dbid order.
When pages are cached in an archive database, the cached pages stay in the memory pool with the same page size as the server. So, on a 2K server, the pages are always cached in a 2K pool. On a 16K server, the pages are always cached in a 16K pool.
You cannot bind an archive database, or any object within that database, to a user-defined cache. Objects within an archive database default to the default data cache.
disk resize does not work on any device used by an archive database and that maps to a database dump or a transaction log.
disk refit does not rebuild the master database’s sysusages entries from any devices that are used by an archive database. This applies both to dump devices and those used for the modified pages section. Existing sysusages entries for an archive database remain however.
An archive database cannot be replicated.
An archive database does not fail over on a high-availability server.
Free-space thresholds cannot be established on an archive database.
