When you configure auto-archive across three servers (collection, reporting, and remote storage), all event log databases progress through three states: hot, warm, and cold. With this architecture, a hot database of uncompressed logs exists only on the collection server. The reporting server holds compressed warm databases; the remote storage server holds only cold databases. When a cold database is restored with the restore shell script, it is restored in a warm state. When it is restored manually with LMArchive utility, it is restored in a defrosted state.
The following four event log storage states describe uncompressed, compressed, backed up and moved, and restored databases, respectively:
A hot database state is the state of the single uncompressed database in the event log store of a collection server where newly processed events are inserted. You can configure the maximum number of new records to store in a hot database (Maximum Rows) before compressing it into a warm database. You can schedule auto-archiving to move warm databases from the collection server to the configured reporting server hourly. (A hot database also exists on the reporting server for inserting self-monitoring events.)
The warm database state is the state of databases retained in the event log store of the reporting server. If you configure daily auto-archiving between the reporting server and a remote storage server, warm databases are retained until they are moved to the remote storage server; then they are auto-deleted from the reporting server. If you do not configure auto-archiving between the reporting server and a remote storage server, warm databases can remain on the reporting server until their age in days reaches the configured value for Max Archive Days or when the configured Archive Disk Space threshold is reached, whichever comes first. When one of these thresholds is met, the database is deleted and its state changed to cold. Without auto-archiving, you must manually back up warm databases with a third party tool before they are deleted and then run LMArchive utility to notify CA User Activity Reporting Module of the names of the databases you backed up and moved. The warm state is also applied when a recatalog is performed with the restore-ca-elm.sh script or the Recatalog button after restoring a cold database.
A cold database state applies to a database on the remote storage server. A record of a cold database is created on the reporting server when the database is auto-archived to the remote management server and deleted from the reporting server. If handled manually, a record of the cold database is created when the LMArchive utility is run with the -notify arch option. You can query the archive catalog of a reporting server to identify cold databases to restore.
A defrosted database state is the state applied to a physical cold database that has been restored to the archive directory after the Administrator runs the LMArchive utility with the -notify rest option to notify CA User Activity Reporting Module that it has been restored. Defrosted databases are retained for the number of hours configured for the Export Policy.
You can query databases in every state. A normal query returns event data from the hot and warm databases on the reporting server and defrosted databases, if they exist. A federated query returns event data from all servers in the federation, including the federated collection servers that include hot databases. An archive query returns a list of databases that no longer exist on the reporting server, that is, databases in a cold state. The physical databases represented by an archive query can exist on the remote storage server used for on-site storage or in off-site storage.
|
Copyright © 2013 CA.
All rights reserved.
|
|