WebFOCUS Online Help > ReportCaster Development and Administration > Maintenance Functions for a FOCUS Repository > Repository Table Maintenance Procedures
In this section: Reference: |
The FOCUS Repository tables used by ReportCaster make use of internal indices for fast retrieval of information. However, over time system performance may be affected, especially if many records have been added and deleted. This is because WebFOCUS does not automatically recognize the internal space freed up by the deletions, and therefore uses new space to store subsequent records.
Standard FOCUS maintenance procedures should be followed periodically to keep ReportCaster running at its optimum performance level. There are two types of FOCUS Repository table maintenance procedures that are of importance to ReportCaster:
This procedure should be used to maintain peak performance on tables that have had many records deleted but are expected to have many new records added. You should plan on rebuilding the BOTLOG and BOTLOG2 tables after purging old records so that new log records can be stored efficiently.
This procedure should be used when a large number of records have been removed from a table and many new record additions are not anticipated. For example, if a large number of addresses are deleted from the Repository and many new address additions are not expected, using this procedure can return free space to the operating system.
It is not necessary to rebuild or reorganize all of ReportCaster's FOCUS Repository tables. Which tables should be managed and how often the procedures should be performed varies from one site to the next. The following table provides some guidelines.
|
Table |
Purpose |
Notes |
|---|---|---|
|
BOTADDR |
Distribution List storage. |
Contains one record per list. |
|
BOTDEST |
Distribution information. |
Contains one record per destination. Can have many records for each list. |
|
BOTTSKEX |
User security information. |
Contains one record per Task. |
|
BOTUPROF |
User profiles and capabilities. |
Contains one record per scheduling user. |
|
BOTLOG |
Job log storage. |
Contains one record per job run. |
|
BOTLOG2 |
Job log message storage. |
Contains many records per job run. |
|
BOTPARMS |
Optional report parameters for job execution. |
Optionally stores one record per parameter per Task. |
|
BOTSCHED |
Schedule information for each job. |
One record per schedule. |
|
BOTTELL |
User subscription information. |
Used by optional Two-Way Email feature. Contains one record for each user subscription. |
|
BOTJOURN |
Journal of all Two-Way Email events. |
Contains many records per job run. |
|
BOTTASK |
Individual Task information. |
Contains one record for each Task in a schedule. |
|
BOTPACK |
Packet ID that uniquely identifies each schedule. |
Contains one record per schedule. |
|
BOTGRP |
Group name and description. |
Contains one record per group. |
|
BOTGUSER |
User IDs within each group name. |
Contains one record per user per group. |
The ReportCaster Console, ReportCaster Interface, and ReportCaster configuration file purge option (Log Purge Period) deletes all log records, or log records that are older than a specified date. These log records are deleted from the BOTLOG and BOTLOG2 tables. Since BOTLOG2 contains one record per message per job run, this file can become very large. It is recommended that you follow up log purges with either a rebuild or a reorganization of these FOCUS Repository tables.
The following procedures and examples describe how to rebuild and reorganize FOCUS Repository tables on:
For example,
drive:\ibi\srv76\wfs\bin\edastart.bat -x EX focexec > path\rcreorg.log
where:
Is the drive where your WebFOCUS Reporting Server configuration is located.
Is the procedure name that includes the rebuild or reorganization command.
Is the location of the log file.
Note: The command should appear on a single line in the batch file.
Note: On Windows-based systems, the intermediate dump file for the reorganization defaults to the root of the WebFOCUS Reporting Server's configuration directory (for example, ibi\srv76\wfs). This cannot be controlled.
The following are examples of rebuilding and reorganizing the BOTDEST table on Windows.
The following example shows how to rebuild the BOTDEST table on Windows.
-TYPE Beginning ReportCaster FDS file rebuild... -* duplicate the steps between these comments for each file to rebuild COPY d:\ibi\srv76\wfs\catalog\botdest.foc d:\ibi\fds_backup\botdest.foc -* -RUN USE CLEAR USE d:\ibi\srv76\wfs\catalog\botdest.foc END REBUILD REBUILD BOTDEST NO -TYPE File botdest rebuilt. -**************************************************************** -RUN -TYPE ReportCaster FDS rebuild complete.
The following example shows how to reorganize the BOTDEST table on Windows.
-TYPE Beginning ReportCaster FDS file reorganization... -* duplicate the steps between these comments for each file to reorg COPY d:\ibi\srv76\wfs\catalog\botdest.foc d:\ibi\fds_backup\botdest.foc -* -RUN USE CLEAR USE d:\ibi\srv76\wfs\catalog\botdest.foc END REBUILD REORG DUMP BOTDEST NO -* Dump complete. Remove old file then begin load. !ERASE d:\ibi\srv76\wfs\catalog\botdest.foc -RUN USE CLEAR USE d:\ibi\srv76\wfs\catalog\botdest.foc NEW AS BOTDEST END FILEDEF BOTDEST DISK d:\ibi\srv76\wfs\catalog\rebuild.ftm REBUILD REORG LOAD BOTDEST -RUN !ERASE d:\ibi\srv76\wfs\catalog\rebuild.ftm -TYPE File botdest reorganized. -**************************************************************** -RUN -TYPE ReportCaster FDS reorganization complete.
For example,
edaconf/bin/edastart -x EX focexec > /apps/ibi/rcreorg.log
where:
Is the location of your WebFOCUS Reporting Server configuration. The default value is /home/ibi/srv76/wfs.
Is the procedure name that includes the rebuild or reorganization command.
Replace COPY with !cp
Replace ERASE with !rm
Note: On UNIX-based systems, the intermediate dump file for the reorganization defaults to the root of the WebFOCUS Reporting Server's configuration directory (for example, /home/ibi/srv76/wfs). This cannot be controlled.
The following are examples of rebuilding and reorganizing the BOTDEST table on z/OZ.
Use this example if the FOCUS Repository table has had many records deleted and you want to be able to use this internal space for new records. Any disk allocations (primary and secondary) in use at the start of this procedure will remain afterwards. However, the file itself will not grow in size until its internal space is used up.
DYNAM ALLOC DD BOTDEST DA qualif.BOTDEST.FOCUS SHR REU DYNAM ALLOC DD BOTDESTX DA qualif.BOTDESTX.FOCUS NEW DYNAM COPY BOTDEST BOTDESTX REBUILD BOTDEST NO
where:
Is the high-level qualifier of your FOCUS Repository table.
Use this example if the FOCUS Repository table has had many records deleted and many new record additions are not anticipated.
DYNAM ALLOC DD BOTDEST DA qualif.BOTDEST.FOCUS SHR REU
DYNAM ALLOC DD BOTDESTX DA qualif.BOTDESTX.FOCUS NEW
DYNAM COPY BOTDEST BOTDESTX
REBUILD
REORG
DUMP
BOTDEST
NO
DYNAM DELETE qualif.BOTDEST.FOCUS
DYNAM FREE DD BOTDEST
DYNAM ALLOC DD BOTDEST DA qualif.BOTDEST.FOCUS NEW -
SPACE TRACKS 5,5
REBUILD
REORG
LOAD
BOTDESTwhere:
Is the high-level qualifier of your FOCUS Repository table.
| WebFOCUS |