Archive Database Access

Archive database access allows a database administrator to validate or selectively
recover data from a database dump (an “archive”) by making the dump appear as if it were a
traditional read-only database; this type of database is called an “archive database.”

Unlike a traditional database, an archive database uses the actual database dump as its
main disk storage device, with a minimum amount of traditional storage to represent new or
modified pages that result from the recovery of the database dump. A database dump already
contains the images of many (or even most) of the database pages, therefore, an archive
database can be loaded without having to use Backup Server to transfer pages from the
archive to traditional database storage. Consequently, the load is significantly faster than
a traditional database.

Archive database access lets you perform a variety of operations directly on a database
dump.

The amount of storage needed for a traditional database load must be equal to or greater
than the size of the source database; the loading of the database dump using Backup Server
involves copying pages from the database dump into the storage that has been set aside for
the traditional database.

By contrast, you can create an archive database using a minimal amount of traditional disk
storage. When you load an archive database, the pages residing in the database dump are not
copied by the Backup Server. Instead, SAP ASE creates a map that represents a
“logical-to-virtual” mapping of the pages within the archive. This significantly decreases the
amount of time required to view the data in a database dump, and reduces the storage
requirement for loading the dump.

An archive database does not have to be a complete copy of the original database. Depending
on the optimization used when dumping the database using sp_dumpoptimize,
an archive database may be fully populated (every page in the database is in the database
dump), or partially populated (only allocated pages are stored in the database dump).

Because the database dump is presented as a read-only database, a database administrator
can query it using familiar tools and techniques such as:

Running database consistency checks on the most recent copy of a dump made from a
production database. These checks can be offloaded to a different server to avoid
resource contention in the production environment. If resources are not a concern, the
archive can be checked on the same server on which it was created. Verification on the
archive provides the assurance needed prior to performing a restore operation.

If the integrity of a database dump is in question, loading it into an archive
database can be a quick test for success, and therefore a good tool to identify the
appropriate database dump that should be used to restore a traditional database.

Object-level restoration from the database dump. Lost data is recovered using
select into to copy the to-be-restored rows from the table within
the archive database. Perform the select into operation either
directly in the server hosting the archive database, or by using Component Integration
Services proxy tables if the archive database is available on a different server than
that of the object requiring restoration.

In addition, transaction logs can be loaded into an archive database, thereby providing the
assurance that the same load sequence can be applied when performing a restore operation.
The figure below represents the differences between an archive database and a traditional
database structure.

Components of an Archive Database
An archive database is made up of components working together to create the illusion that a database dump is functioning as a traditional database.

Compressed Dumps for an Archive Database
To use a compressed dump for an archive database, you must create the compressed dump using the with compression = <compression level> option of the dump database or dump tran command, and create a memory pool for accessing the archive database.