Tablespace with UNRECOVERABLE or NONRECOVERABLE operations
Metric data tablespaces require different backup strategies that are described in the following sections.
Each of these methods uses a traditional hot
backup for metric data tablespaces that are not yet placed in READ
ONLY mode. However, they differ in how they approach the backup of
READ ONLY tablespaces.
To minimize effort during recovery, back up all metric data tablespaces that are recently placed in READ ONLY mode first. It must then be followed by a traditional hot backup of any metric data tablespaces that are being loaded.
Each
of these methods uses a traditional hot backup for metric data tablespaces.
To minimize effort during recovery, back up all metric data tablespaces, followed by a traditional hot backup of any metric data tablespaces that are being loaded.
Traditional Tivoli Netcool Performance Manager backup method
The traditional backup method backs up READ
ONLY tablespaces one time to a more permanent storage area (that is,
a separate disk location or tape pool), where they are retained until
the corresponding data is purged. Backing up the READ ONLY tablespaces
one time minimizes your regular backup window, as there is less data
to process on any given backup run. However, this method requires
more management overhead, as the backups must be retained and managed
by using an RMAN catalog database until the data is purged.
The
traditional backup method backs up tablespaces to a more permanent
storage area (that is, a separate disk location or tape pool), where
they are retained until the corresponding data is purged. Backing
up the tablespaces minimizes your regular backup window, as there
is less data to process on any given backup run. However, this method
requires more management overhead, as the backup files must be retained
and managed.
Alternative Tivoli Netcool Performance Manager backup method
The alternative backup method backs up READ
ONLY tablespaces that follow a periodic reset of READ ONLY tablespaces.
Using this method minimizes your regular backup window, as there is
less data to process until the next reset, and simplifies management
requirements as no RMAN catalog database is required. However, this
method requires sufficient backup resources to perform a regular full
backup of all your READ ONLY tablespaces.
Restricting backups by set type
No
matter, which backup method you select, there are some additional
options, which can help you. There are sample backup scripts, which
use set types to reset and back up subsets of the READ ONLY data.
When you call the sample scripts, you can specify the following types as options from the command line:
- Individual set type (NRAW, BASE, 1DRA, 1DGA, 1WRA, 1WGA, 1MRA, or 1MGA)
- A combination of the 1DRA, 1DGA, 1WRA, 1WGA, 1MRA, and 1MGA set types (ALLAGG)
- A combination of all the set types (ALL)
The ability to restrict to a particular set type or group of set types is useful in several situations:
- Scenario 1
- You have different data retention requirements for certain set
types, and want to back up these set types to separate (that is, different
tape pools).
- Example 1 - You perform a backup by using the sample scripts and the default value of ALL (a combination of all the set types). This approach requires you to set the tape retention to the set type that has the longest retention requirement. As you are backing up shorter term (NRAW/BASE) and longer term (aggregated) data to the same tape pool, many tapes must be retained whose data is not used during a recovery operation.
- Example 2 - You perform three backups by using NRAW, BASE, and ALLAGG options. You can use the NRAW and BASE option to allocate the backups to the same tape pool as they have the same data retention requirements. You can use the ALLAGG option to allocate the backup to a separate tape pool. This approach returns the tapes that contain the NRAW and BASE data to their tape pool at the end of their retention window (that is, 90 days). It also returns the tapes that contain the ALLAGG data to their tape pool at the end of their retention window (that is, three years).
- Scenario 2
- You used the alternative backup method, but do not have sufficient
backup resources to complete the backup in the time available. You
can reset only a portion of the READ ONLY tablespaces and back up
those tablespaces instead.
- Example 1 - You have a 10 TB database with roughly 5 TB of raw/base data and 5 TB of aggregated data. With your backup resources, you can back up 5 TB of data during your backup window, and you want to perform a monthly backup of your READ ONLY tablespaces. In this case, you can reset and back up only the NRAW and BASE data on the first weekend of the month. You then perform a reset and backup of the aggregation data on the third weekend of the month. With this approach, you can perform full monthly backups of all READ ONLY tablespaces without requiring more backup resources.