6. Database Tailoring and Retrofitting Techniques › 6.2 Tailoring the Database › 6.2.3 Tailoring Archive Files
6.2.3 Tailoring Archive Files
This level of tailoring involves changing database file
definitions describing offline storage.
A file in the CA MICS database may be archived in three
ways - audit files may be created, weekly history files may
be created, and monthly history files may be created. A
sample pattern, using the example of the NPANCP file, might
be:
Audit Files Weekly History Monthly History
--------------- --------------- ---------------
no audit file 53 weeks of 24 months of
is produced weekly history monthly history
is kept is kept
It is necessary here to review the purpose of each
offline archive mechanism.
- Audit archives exist to give the user the ability to
recall detail data for long periods. The audit files
cause DETAIL (or DAYS if the DETAIL timespan is
inactive) online files to be copied to tape. Ten
cycles of online data (minus the data for the current
week) are copied to tape by the CA MICS WEEKLY or the
stand-alone AUDIT operational jobs. No old data is
merged. Each week's audit file is a new generation of
the generation data group (tape) data set for the
file's audit data set.
Typically, large numbers of audit generation data
groups are kept. The purpose of audit data is to be
able to reconstruct activity in the finest detail
available should a security breach or major processing
anomaly be detected after the fact.
NOTE: Audit archives may be updated weekly, or can be
updated more frequently (e.g., 3 times per week)
if you are using the stand-alone AUDIT job
option.
In this case, prefix.MICS.PARMS(EXECDEF)
must be modified to include the following:
USERDEF AUDITCWK YES
The USERDEF AUDITCWK YES parameter specification
overrides the standard, default audit archive
processing which drops data from the current
week in order to reduce processing time and
conserve CA MICS tape database space. When you
run AUDIT more frequently than once each week,
you are almost certain to be doing so in order
to spread a large amount of audit archive data
over two or more audit cycles, and by specifying
USERDEF AUDITCWK YES
you ensure that CA MICS will process the
audit archive data according to your
requirements.
- Weekly histories exist to give the user the ability
to produce reports at the weeks granularity for
long periods. Such analyses may be done for
capacity planning or performance analysis purposes.
Previous histories are merged, giving, every week, a
new history of the duration indicated.
- Monthly histories exist to give the user the ability
to produce reports at the months granularity for
even longer periods. Such analyses may be done for
capacity planning or performance analysis purposes.
Previous histories are merged, giving, every month, a
new history of the duration indicated.
The definition of what files exist offline and how many
periods in each is done in three places.
- Archiving active or inactive: The archive group active
or inactive configuration applies to all database units
in the CA MICS database complex where the component is
installed.
- Number of history cycles to keep and audit archive
override: The cutoff limit for the number of cycles of
weekly or monthly history data to keep is local to the
database unit. It can be zero to deactivate history
archive processing. Audit archive can be deactivated
with the AUDIT(NO) parameter. Each database unit in
which the component is installed may have a different
specification.
- Number of generations: The number of generation data
groups for any archive group is local to the database
unit. Each database unit in which the component is
installed may have a different specification.
Whether a file exists or not in an archive process, is
determined by a combination of the FILE statement of the
CA MICS Component Generator (MCG) description for the
component, and the FILE statement in
prefix.MICS.PARMS(DBMODEL) specifying cutoff limits and
activation parameters. A file marked eligible for archiving
in the MCG description can be deactivated in DBMODEL. To
activate a file for archiving, it must be marked eligible in
the MCG description and have a cutoff limit greater than zero
or the AUDIT keyword defined in DBMODEL. This specification
is used to create executable SAS code that produces the
archives and the prototype library members that contain JCL
for the archive files to be included (or not) in the WEEKLY,
MONTHLY, AUDIT, HISTW, or HISTM operational jobs.
For the example NPA component, assume that
sharedprefix.MICS.GENLIB(cccGENIN) contains a statement that
describes the NPANCP file. It is:
FILE NCP 00 1 Y Y Y Y N N Y Y NCP Activity File
| | |
| | +- monthly history active
| +--- weekly history active
+----- audit inactive
The number of periods of a file that CA MICS will contain
within a history IN WHICH THE FILE EXISTS is specified in the
unit-level prefix.MICS.PARMS library. This specification is
used to produce macros that limit the amount of offline
history data saved. For NPA, the period definitions in
prefix.MICS.PARMS(DBMODEL) (for a database unit in which NPA
is generated) will contain a FILE statement for the NPANCP
file, giving the number of histories to be archived in each
history group:
FILE NPANCP 01 10 53 06 00 00 053 024
| |
53 weeks of history are kept -+ |
24 months of history are kept -----+
For audit archive, since no AUDIT keyword is specified,
the definition from cccGENIN is taken, which is audit
archive inactive.
The number of generations of archive data to be saved is
specified in prefix.MICS.PARMS(JCLDEF). This specification
is used to produce the IDCAMS statements necessary to
maintain the required number of GDG indexes in the user's
catalog for the archive files. For example, the statements
in JCLDEF might be defined as:
AUDITGDG 53 ------ 53 generations of audit archive
HISTWGDG 7 ------ 7 generations of weekly history
HISTMGDG 2 ------ 2 generations of monthly history
Generation data group index levels apply to all components
in a database unit. Generation data group index levels
must be specified in the JCLDEF PARMS member, even if all
files in all components installed in the database unit have
the associated archive function deactivated.
It is possible to tailor the space used by an offline
database through the file retention definitions in the
DBMODEL member of the PARMS library. To carry 60 weeks
worth of weekly history instead of 53 weeks, change the FILE
statement in DBMODEL to:
FILE NPANCP 01 10 53 06 00 00 060 024
---
|
+-- changed parameter
However, having the file inactive in the weekly history
by the FILE statement in sharedprefix.MICS.GENLIB(cccGENIN)
would force the weekly retention to zero.