System Administration Utilities and Scripts

17 System Administration Utilities and Scripts

Learn about the syntax and parameters for the Oracle Communications Billing and Revenue Management (BRM) system administration utilities and scripts.

Topics in this document:

load_pin_event_record_map

Use this utility to load the event record file (BRM_home/sys/data/config/pin_event_record_map) into the BRM database.

The event record file contains a list of event types to exclude from being recorded in the database. For more information, see "Managing Database Usage".

Note:

At the time you load the event record file, if any events of a type specified in the file already exist in the database, these events remain in the database.

After running this utility, you must stop and restart the Connection Manager (CM).

Location

BRM_home/bin

Syntax

load_pin_event_record_map [-d] [-v] | [-r] pin_event_record_map

Parameters

-d

Logs debugging information.

-v

Displays detailed information as the event record map is created.

-r

Returns a list of the events in the pin_event_record_map file configured to not be recorded.

Note:

This option must be used by itself and does not require the file name.

pin_event_record_map

The file containing the event types to exclude from the database.

Specify to not record the event type by setting its flag value to 0 in the file. To temporarily record an event type, change the event's flag value to 1 and reload the file.

The following example shows the event record file format where the event type is followed by its flag value:

/event/session : 1
/event/customer/nameinfo : 0
/event/billing/deal/purchase : 0
/event/billing/product/action/purchase : 0
/event/billing/product/action/modify : 0

Note:

The record file includes one default event type, /event/session, set to be recorded. Never exclude this event type or any event type that is updated more than once during the same session from recording. If such events are configured not to record, an error occurs when the system tries to update the same event during the same session. To eliminate the error, remove the event causing the error from the record map file.

Results

The utility notifies you only if it encounters errors. Look in the default.pinlog file for errors. This file is either in the directory from which the utility was started or in a directory specified in the utility configuration file.

partition_utils

Use the partition_utils utility to do the following:

Add partitions
Purge objects without removing partitions
Remove partitions
Enable delayed partitions
Update partitions
Restart a partition_utils job
Find the maximum POID for a date

For more information, see "Partitioning Tables" and "About Purging Data".

Note:

Before you use this utility, configure the database connection parameters in the BRM_home/apps/partition_utils/partition_utils.values file. See "Configuring a Database Connection".
After you start this utility, do not interrupt it. It might take several minutes to complete an operation depending on the size of your database.

You can run the partition_utils utility in the following modes:

Location

BRM_home/bin

Adding Partitions

Applies the new partition allocations across all of the partitioned tables of the type specified.

Note:

To use this utility to add a partition for a storable class other than event, bill, invoice, item, journal, newsfeed, sepa, or user activity, you must enable partitioning for that storable class. See "Converting Nonpartitioned Classes to Partitioned Classes".

Syntax for Adding Partitions

partition_utils    -o add -t realtime|delayed|prepaid -s start_date 
                   -u month|week|day -q quantity 
                   [-c storable_class] [-w width]
                   [-f] [-p] [-b] [-h]

Parameters for Adding Partitions

-o add

Adds partitions.

-t realtime|delayed|prepaid

Adds real-time, delayed-event, or prepaid-event partitions. Only event tables can have delayed-event partitions.

Note:

Conversion Manager does not support the migration of data to the EVENT_T tables.

-s start_date

Specifies the starting date for the new partitions. The format is MMDDYYYY.

start_date must be the day after tomorrow or later. You cannot create partitions starting on the current day or the next day. For example, if the current date is January 1, the earliest start date for the new partition is January 3 (for example, 01032024).

-u month|week|day

Specifies the time unit for partitions.

-q quantity

Specifies the number of partitions to add.

If a partition with a future date already exists in the table, this adds more partitions than the specified quantity.

For example, if you want to create one partition with a February 1 start date and the table already contains a P_R_02282032 partition, the P_R_02282032 partition is split into two partitions named P_R_02012032 and P_R_02282032.

-c storable_class

Specifies the class of objects to be stored in the partition. The default is /event.

If you are adding a partition for a storable class other than an event, bill, invoice, item, or journal, you must enable partitioning for that storable class. See "Converting Nonpartitioned Classes to Partitioned Classes".

-w width

Specifies the number of units in a partition, such as 3.

-f

Forces the creation of a partition when start_date falls within the time period of the current partition. The existing partition is split in two: one new partition containing objects created before the specified start date and the other new partition containing objects created on or after the specified start date.

Note:

Before forcing partitions, stop all BRM server processes.
The -f parameter works differently when you remove partitions. In that case, it forces the removal of objects associated with open items.

-p

Writes a SQL statement of the operation to the partition_utils.log file without performing any action on the database. See "Running the partition_utils Utility in Test Mode".

-b

Creates backdated partitions.

-h

Displays the syntax and parameters for this utility.

Purging Partitions

Deletes processed events and non-balance impact events from partitions where the complete partition lies between the start date and end date.

Only event, item, bill, invoice, journal, newsfeed, and sepa objects can be purged without removing their partitions. To purge other types of objects, see "Removing Partitions".

Syntax for Purging Objects without Removing Partitions

partition_utils  -o purge [-s start_date] -e end_date [-c storable_class] [-t realtime|delayed|prepaid] 
                 [-p] [-h]

Parameters for Purging Objects without Removing Partitions

-o purge: Purges event, item, bill, invoice, journal, newsfeed, and sepa objects without removing their partitions. The event objects must be associated with closed items. To enable this utility to purge event objects associated with open items, see "Enabling Open Items to Be Purged".
-s start_date: Specifies the start of the date range containing the objects you want to purge. The date is inclusive. The format is MMDDYYYY. If start_date is not specified, all objects created on or before end_date are purged.
-e end_date: Specifies the end of the date range containing the objects you want to purge. The date is inclusive. The format is MMDDYYYY.

Note:

If the specified start and end dates do not match the partition boundaries, only objects in partitions that are completely within the date range are purged.
-c storable_class: Specifies the objects to purge by base storable class. The default is /event.
-t realtime|delayed|prepaid: Purges real-time objects, delayed-event objects, or prepaid objects. To purge all object types, use the -t parameter without any options. If this parameter is omitted from the syntax, an error occurs.
-p: Writes a SQL statement that shows the partitions that will be removed to the partition_utils.log file without performing any action on the database. See "Running the partition_utils Utility in Test Mode".
-h: Displays the syntax and parameters for this utility.

Removing Partitions

Drops the subset of real-time, delayed-event, or prepaid partitions that occur between the specified start date and end date.

Note:

To remove bill, event, invoice, item, journal, newsfeed, and sepa objects that:

Meet the purging criteria, see "Purging Partitions".
Do not meet the purging criteria, use the -f parameter to remove the partitions that contain them. See "Purging Objects by Removing Partitions".

For information about purging criteria, see "Objects Purged by Default".

Syntax for Removing Partitions

partition_utils  -o remove -s start_date -e end_date [-t realtime|delayed|prepaid] [-c storable_class] 
                 [-f] [-p] [-h]

The only way to purge objects other than bill, event, invoice, item, journal, newsfeed, and sepa from your database is to remove their partitions by using the -f parameter.

Parameters for Removing Partitions

-o remove

Removes partitions.

-s start_date

Specifies the start of the date range for the objects you want to remove. The format is MMDDYYYY.

By default, start_date must be at least 45 days ago. You can change this limitation by editing the BRM_home/apps/partition_utils/partition_utils.values file. See "Customizing Partition Limitations".

If the specified dates do not match the partition boundaries, only objects in partitions that are completely within the date range are removed. See "About Purging Database Objects".

Note:

The object's oldest partition is kept by default. To force the removal of the oldest partition, you must set start_date to 01011970.

-e end_date

Specifies the end of the date range for objects you want to remove. The format is MMDDYYYY.

By default, end_date must be at least 45 days ago. You can change this limitation by editing the BRM_home/apps/partition_utils/partition_utils.values file. See "Customizing Partition Limitations".

-c storable_class

Specifies the partition to remove by base storable class. The default is /event.

When you remove a partition, it removes partitions in all partitioned tables for the specified base storable class and its subclasses.

-t realtime|delayed|prepaid

Removes real-time, delayed-event, or prepaid partitions. The default is to remove all partition types.

-f

Forces the removal of partitions whether or not the objects in the partitions satisfy the purging criteria. For information about purging criteria, see "Objects Purged by Default".

Caution:

Operations using the -f parameter cannot be undone and will remove objects that are being used. Use with caution.

-p

Writes a SQL statement that shows the partitions that will be removed to the partition_utils.log file without performing any action on the database. See "Running the partition_utils Utility in Test Mode".

-h

Displays the syntax and parameters for this utility.

Enabling Delayed Partitions

Enables delayed partitions for the specified event storable class and all of its parent storable classes.

Syntax for Enabling Delayed Partitions

partition_utils  -o enable -t delayed -c storable_class [-p] [-h]

Parameters for Enabling Delayed Partitions

-o enable -t delayed

Enables delayed-event partitions.

-c storable_class

Specifies the event storable class for which you want to add delayed-event partitions. Delayed-event partitions cannot be used for non-event storable classes.

To add delayed-event partitions for all subclasses of an event, use the percent sign (%) as a wildcard (for example, -c /event/session/%).

-p

Writes a SQL statement of the operation to the partition_utils.log file without performing any action on the database. See "Running the partition_utils Utility in Test Mode".

-h

Displays the syntax and parameters for this utility.

Updating Partitions

Ensures that future partitions are synchronized across all partitioned tables of given class. To partition new tables appropriately, update partitions after adding a new subclass or after adding an array or substruct to an existing class.

Syntax for Updating Partitions

partition_utils  -o update [-c storable_class] [-p] [-h]

Parameters for Updating Partitions

-o update: Aligns partitions across all object tables for a single base storable class. All real-time and delayed-event partitions get the same real-time partitioning scheme as their base table (EVENT_T for event base storable class tables, ITEM_T for item base storable class tables, and so on).
-c storable_class: Specifies the class of objects to update. The default is /event.
-h: Displays the syntax and parameters for this utility.

Restarting a partition_utils Job

Runs the last operation that was unsuccessful due to an error, or it cleans its status.

Syntax for Restarting a partition_utils Job

partition_utils  -o restart [-b] [-h]

Parameters for Restarting a partition_utils Job

-o restart: Restarts the previous operation that was unsuccessful due to an error or abnormal termination.
-b: Bypasses running the previous operation and instead cleans the status of it.
-h: Displays the syntax and parameters for this utility.

Finding the Maximum POID for a Date

Returns the maximum POID for the specified date and partition type.

Syntax for Finding the Maximum POID for a Date

partition_utils  -o maxpoid -s date -t realtime|delayed|prepaid [-p] [-h]

Parameters for Finding the Maximum POID for a Date

-o maxpoid: Returns the maximum POID for the specified date.
-s date: Specifies the date for which the maximum POID is to be found. The format is MMDDYYYY.
-t realtime|delayed|prepaid: Gets the maximum POID in only real-time partitions, only delayed-event partitions, or only prepaid partitions.
-p: Writes a SQL statement of the operation to the partition_utils.log file without performing any action on the database. See "Running the partition_utils Utility in Test Mode".
-h: Displays the syntax and parameters for this utility.

Results

If the utility does not notify you that it was successful, look in the partition_utils.log file to find any errors. This file is either in the directory from which the utility was started or in a directory specified in the utility configuration file. The partition_utils.log file includes SQL statements if you use the -p parameter.

partitioning.pl

Use this script to manage all the nonpartitioning-to-partitioning upgrade tasks. Run it from a UNIX prompt.

For more information, see "Converting Nonpartitioned Classes to Partitioned Classes".

Note:

This script needs the partition.cfg configuration file in the directory from which you run the utility.

Location

BRM_home/bin

Syntax

perl partitioning.pl [-c | -n | -a | -h ]

Parameters

-c: Creates the database objects required for the upgrade, including the following:

The UPG_LOG_T table that logs all the information about the upgrade
The pin_upg_common package that contains all the common routines for the upgrade

-n

Displays the event tables that will be partitioned during the upgrade.

Tables selected for partitioning are listed in the TABLES_TOBE_PARTITIONED_T table, which is created during the upgrade process. This table contains two columns:

table_name: The name of the table to be partitioned.
partition_exchanged: The value of the exchanged partition. This value is used by the upgrade scripts to perform the table partitioning.

Use the INSERT statement to partition tables and use 0 for the partition_exchanged value. For example, to insert MY_CUSTOM_EVENT_TABLE, run the following SQL statement:

INSERT INTO TABLES_TOBE_PARTITIONED_T (table_name, partition_exchanged)
VALUES ('MY_CUSTOM_EVENT_TABLE',0); COMMIT;

Note:

To prevent a listed table from being partitioned, use the SQL DELETE statement to delete its name from TABLES_TOBE_PARTITIONED_T.

-a

Partitions the tables listed in the TABLES_TOBE_PARTITIONED_T table.

To partition additional tables, see "Converting Nonpartitioned Classes to Partitioned Classes".

-h

Displays the syntax and parameters for this utility.

Results

The utility does not notify you if it was successful. Look in the UPG_LOG_T table to find any errors.

pin_close_items

Use this utility to close open item objects processed in past billing cycles. Run it from a UNIX prompt.

This utility calls the BRM_home/apps/partition_utils/sql_utils/oracle/pin_close_items.plb stored procedure.

Before you use this utility, configure the database connection parameters in the partition_utils.values file in BRM_home/apps/partition_utils. See "Configuring a Database Connection".

For more information, see "Closing Open Item Objects Processed in Past Billing Cycles".

Note:

This utility needs the partition_utils.values configuration file in the directory from which you run the utility.

Location

BRM_home/apps/partition_utils

Syntax

pin_close_items [-h]

Parameters

-h: Displays the syntax and parameters for this utility.

Results

The utility does not notify you if it was successful. Look in the BRM_home/apps/partition_utils/pin_close_items.log file to find any errors.

pin_ctl

Use this utility to start and stop BRM components.

Note:

To connect to the BRM database and configure the processes, this utility requires a configuration file in the directory from which you run the utility. This configuration file must be called pin_ctl.conf, which is different from most BRM configuration file names.

Syntax

pin_ctl action component [-c file_name] [-collectdata] [-debug] [-i]

Parameters

action

Specifies the type of action to be run. See "Parameters for Actions".

For example, to start the CM, use the following command:

pin_ctl start cm

component

Specifies the process on which the action is performed. See "Parameters for Components".

-c file_name

Specifies a configuration file to use instead of the default. Use this parameter to run different configurations of the same system.

-collectdata

Gets diagnostic data when starting, stopping, or checking the status of a component.

-debug

Displays debugging information.

-i

Allows the utility to ask whether you want to proceed. This is especially useful when running stop, halt, and clear.

Parameters for Actions

clear

Deletes log entries associated with the component (not the file).

Note:

The log file is not deleted, just the entries.

cstart

Clears the component logs and, if the component is not running, starts the component.

If the component is already running, the command clears the log file; the component continues running.

Note:

You are not prompted to clear logs.

halt

Searches for the specified component and runs the kill -9 command.

restart

Stops the component, waits for completion, then restarts the component.

start

Starts the component if it is not running.

If you specify all for component, it starts the components specified in the pin_ctl.conf file. For information, see "Customizing the List of Components to Start or Stop".

status

Returns the status of component as Running or NotRunning.

stop

Stops the component if it is running.

If you specify all for component, it stops the components specified in the pin_ctl.conf file. For information, see "Customizing the List of Components to Start or Stop".

Parameters for Components

You can perform an action on any of the following components:

all: Applies the action to the components specified in the pin_ctl.conf file. By default, the components are the following:

Oracle Data Manager (DM)
Email DM
Connection Manager
CM Master Process
Invoice formatter

You can modify the list of components specified in the pin_ctl.conf file. See "Customizing the List of Components to Start or Stop".

answer: Paymentech answer simulator
batch_controller: Batch Controller
cm: Connection Manager
cm_proxy: CM Proxy
cmmp: Connection Manager Master Process
dm_eai: Enterprise Application Interface (EAI) DM
dm_email: Email DM
dm_fusa: Paymentech DM
dm_invoice: Invoice DM
dm_ldap: LDAP DM
dm_oracle: Oracle DM
dm_vertex: Vertex tax calculation DM
eai_js: EAI Java Server
formatter: Invoice formatter

pin_db_alert.pl

Use this utility to monitor the following database key performance indicators (KPIs) in Oracle databases:

Age of event and audit tables
Size of audit tables
Invalid or missing procedures, triggers, or indexes

You configure this utility to alert you when one of these components has returned a certain status.

For more information, see "Monitoring Key Performance Indicators".

Note:

To connect to the BRM database, this utility needs a configuration file in the directory from which you run the utility.

Location

BRM_home/diagnostics/pin_db_alert

Syntax

pin_db_alert.pl

Parameters

This utility has no parameters.

pin_del_closed_accts

Use this utility to delete closed accounts from BRM. This utility calls the PCM_OP_CUST_DELETE_ACCT opcode to delete closed accounts that are older than the specified retention period. For more information, see:

To connect to the BRM database, the pin_del_closed_accts utility needs a configuration file in the directory from which you run the utility. See "Connecting BRM Utilities".

Location

BRM_home/bin

Syntax

pin_del_closed_accts  -subord [-leaf]
                      -members_sharing
                      -members_billing
                      -file file_name
                      -force
                      [-verbose] [-help]

Parameters

-subord [-leaf]

Deletes the remaining closed nonpaying child accounts that are parents of other child accounts at the different levels of the hierarchy. It does not delete the top-level parent account in the hierarchy.

To delete the top-level parent account, run the utility without any parameters after deleting all the paying and nonpaying child accounts at different levels in the hierarchy.

Add the -leaf option to delete closed nonpaying child accounts at the bottom of the hierarchy.

-members_sharing: Deletes member accounts from sharing groups; for example, discount and charge sharing groups.

-members_billing: Deletes closed paying accounts in a hierarchy that are used for billing purposes.

-file file_name: Deletes the accounts specified in the input file, where file_name is the name and location of the file that contains the list of accounts for deletion. The account details in this file must be in flist format.

Note:

Running the pin_del_closed_accts utility with this parameter deletes all the accounts specified in the input file even if the accounts are not older than the retention period. When you use this parameter, ensure that the input file contains only the closed accounts that need to be deleted.

-force: Deletes closed accounts that still have active open sessions.

-verbose: Displays information about successful or failed processing as the utility runs.

-help: Displays the syntax and parameters for this utility.

Results

The pin_del_closed_accts utility notifies you when it successfully deletes the closed accounts and the associated customer data.

If the utility does not notify you that it was successful, look in the utility log file (default.pinlog) to find any errors. The log file is either in the directory from which the utility was started or in a directory specified in the configuration file.

After you resolve the errors, you can delete the closed accounts by running the pin_del_closed_accts utility again.

pin_sub_balance_cleanup

Use this utility to purge expired account sub-balances from the BRM database. For more information, see "About Purging Account Sub-Balances".

Note:

When you delete sub-balances from the database, events that impacted those sub-balances cannot be rerated. Ensure you no longer need the expired sub-balances before deleting them.
You must run this utility from the BRM_home/apps/pin_subscription directory. This directory contains the pin.conf file that has the parameters required for this utility.

Note:

Location

BRM_home/bin

Syntax

pin_sub_balance_cleanup  -n number_of_days | -d date 
                         [-t] [-verbose] [-test]

Parameters

-n number_of_days

Specifies the number of days prior to which sub-balances are deleted. For example, specify 60 to delete expired sub-balances older than 60 days.

-d date

The date prior to which sub-balances are deleted. Use the format MM/DD/YYYY. For example, specify 06/30/2003 to delete expired sub-balances older than June 30, 2003.

-t

Deletes expired sub-balances with temporary credit limits.

Use this parameter with the -d date or -n number_of_days parameter.

-test

Finds the sub-balances that meet the criteria but does not purge them from the BRM database.

-verbose

Displays information about successful or failed processing as the utility runs.

Results

The utility does not notify you if it was successful. Look in the (BRM_home/apps/pin_subscription/pin_subscription.pinlog) file to find any errors.

pin_unlock_service

Use this utility to unlock a locked CSR account. See "Unlocking a Locked CSR Account".

Note:

The pin_unlock_service utility needs a configuration (pin.conf) file in the same directory from which you run the utility. The pin.conf file required for running this utility is located in the BRM_home/apps/pin_unlock_service directory.
Make sure that the account in the pin.conf file is not locked.

Location

BRM_home/bin

Syntax

pin_unlock_service

Parameters

This utility accepts parameters through command prompts only. After each entry, press the Enter key to confirm your selection. For more information, see "Unlocking a Locked CSR Account".

Results

This utility notifies you of all the results in the command console. Look in the pin_unlock_service.pinlog file for errors. This file is either in the directory from which the utility was started or in a directory specified in the utility configuration file.

pin_virtual_gen

Use this utility to convert event storable classes in the BRM schema to use virtual columns. After you run this utility, the poid_type columns of event tables in the BRM database are virtual-column enabled.

For more information, see "Generating Virtual Columns on Event Tables".

To connect to the BRM database and to specify logging information, this utility uses the Infranet.properties file in the directory from which you run the utility.

Specify the log level by setting the infranet.log.level property in the Infranet.properties file. The default is 1. Valid values are 1, 2, and 3. Regardless of the log level set, status messages are printed to stdout and to the log file. Errors are logged and printed to stderr.

Location

BRM_home/apps/pin_virtual_columns

Syntax

pin_virtual_gen { { -gentasks [-execute] | -readtasks [-execute] } { [create|pre_export|post_export|verify_types|create_types] } } | -showtasks [minID maxID] }

Parameters

-gentasks create [-execute]

Generates tasks and stores them in the database.

Runs tasks after saving to the database.

-readtasks create [-execute]

Reads previously stored tasks from the database.

Runs tasks after reading from the database.

-gentasks create

Creates virtual columns and supporting columns in the BRM database.

Use this in conjunction with showtasks to display the tasks that will be run for creating the virtual columns before running them. The following example shows how to create the tasks for creating virtual columns, display them, and then run them:

pin_virtual_gen -gentasks create
pin_virtual_gen -showtasks
pin_virtual_gen -readtasks create -execute

-showtasks minID maxID

Reads corresponding tasks from the database and displays task details.

minID and maxID specify the tasks to show within an ID range. The command shows tasks that have an ID greater than minID or less than maxID.

All tasks are displayed when an ID range is not provided.

-gentasks pre_export [-execute]

Removes virtual columns temporarily.

-gentasks post_export [-execute]

Restores virtual columns that were temporarily removed.

-gentasks verify_types [-execute]

Verifies whether storable class type names exist in the data dictionary of the BRM database schema.

-gentasks create_types [-execute]

Creates the names of custom storable class types and stores them in the data dictionary of the BRM database schema.

-help

Displays the syntax and parameters for this utility.

Results

The utility notifies you when it runs successfully. Otherwise, look in the vcol.pinlog file for errors. This file is either in the directory from which the utility was started or in a directory specified in the Infranet.properties file.

purge_audit_tables.pl

Use this script to archive unneeded shadow objects in audit tables. Use it to:

Generate audit table reports
Create history tables
Move audit tables to history tables
Archive audit tables
Restore archived audit tables

The different versions of shadow objects that are valid for archiving are moved to the history tables so they can be accessed for future reference. In addition, when versions of an object are removed from audit tables, all subclasses of the shadow objects are also removed automatically by the script.

Note:

This script does not delete objects from the database; it only purges the object rows stored in a table.
To connect to the BRM database, this script needs a configuration file in the directory from which you run the script.

For more information, see "Purging Archived Audit Data" in BRM Developer's Guide.

Location

BRM_home/sys/archive/oracle

Syntax

purge_audit_tables.pl  report -t objects -d date -l /@connection |
                       create -t objects -l /@connection |
                       archivedirect -t objects -d date -c commit_size -l /@connection |
                       archiveindirect -t objects -d date -c commit_size -l /@connection |
                       renametohist -t objects -l /@connection |
                       updfromhist -t objects -d date -c commit_size -l /@connection |
                       help

The following purging actions are supported:

report Syntax

Generates audit table reports.

This generates a file named purge_tables.report, which provides information about the tables for the specified objects, including the number of rows in each table that are eligible for purging, and whether history tables exist for them. You create a report to determine which mode of archiving to use for the specified object: archivedirect or archiveindirect.

purge_audit_tables.pl  report -t objects -d date -l /@connection

-t objects

Specifies a comma-separated list of shadow objects on which to report.

Shadow objects use an au prefix. For example, a change to a field marked for auditing in the /profile object results in the /au_profile shadow object.

Note:

Do not specify child objects for an object; they are included automatically by the script. For example, the /au_profile/serv_extracting object is reported on when you list the /au_profile object.

-d date

Specifies the cutoff date for purging data.

This date determines which versions of the audit object are eligible for purging. If a version of an object is valid at the cutoff date, and there is at least one older version of the same object, the valid object is kept and all older versions are marked for purging and moved to the history tables.

The format is YYYY:MM:DD.

-l /@connection

Specifies how to connect to your database. For example:

perl purge_audit_tables.pl report -t au_account -d 2005:02:23 -l /@subdb

create Syntax

Creates empty history tables for the specified objects and their child objects.

purge_audit_tables.pl create -t objects -l /@connection

-t objects

Specifies a comma-separated list of objects for which to create history tables. History tables are prepended by H_ as shown in Table 17-1.

Table 17-1 Audit and History Tables Format

/service Object Audit Tables	/service Object History Tables
AU_SERVICE_T	H_SERVICE_T
AU_SERVICE_ALIAS_T	H_SERVICE_ALIAS_T
AU_SERVICE_EXTRACTING_T	H_SERVICE_EXTRACTING_T

Note:

Do not specify the child objects for a table; they are handled automatically by the script.

-l /@connection

Specifies how to connect to your database. For example:

purge_audit_tables.pl create -t au_account -l /@subdb

archivedirect Syntax

Archives audit tables for the specified objects and their child objects by copying the data directly to the history tables and then removing it from the audit tables.

purge_audit_tables.pl archivedirect -t objects -d date -c commit_size -l /@connection

-t objects

Specifies a comma-separated list of objects to archive audit tables for.

Shadow objects use an au prefix. For example, a change to a field marked for auditing in the /profile object results in the /au_profile shadow object.

Note:

Do not specify child objects for an object; they are included automatically by the script. For example, the /au_profile/serv_extracting object is reported on when you list the /au_profile object.

-d date

Specifies the cutoff date for purging data.

The format is YYYY:MM:DD.

-c commit_size

Specifies the number of rows to save to the database at one time.

-l /@connection

Specifies how to connect to your database.

Sample archivedirect command

purge_audit_tables.pl archivedirect -t au_account -d 2005:03:29 -c 1000 -l /@subdb

archiveindirect Syntax

Archives audit tables for the specified objects and their child objects by copying the data first to temporary tables, then to the history tables. If successful, the old audit table data is removed.

Note:

Do not delete the temporary tables if the data was not copied successfully to the history tables. Errors might have occurred when the data was moved to the temporary tables from the main tables; therefore, manually transfer the data back to the main audit tables. Then, delete the temporary tables and run the script again.

purge_audit_tables.pl archiveindirect -t objects -d date -c commit_size -l /@connection

-t objects

Specifies a comma-separated list of objects to archive audit tables for.

Shadow objects use an au prefix. For example, a change to a field marked for auditing in the /profile object results in the /au_profile shadow object.

Note:

Do not specify child objects for an object; they are included automatically by the script. For example, the /au_profile/serv_extracting object is reported on when you list the /au_profile object.

-d date

Specifies the cutoff date for purging data.

The format is YYYY:MM:DD.

-c commit_size

Specifies the number of rows to save to the database at one time.

-l /@connection

Specifies how to connect to your database.

Sample archiveindirect command

purge_audit_tables.pl archiveindirect -t au_account -d 2005:02:23 -c 1000 -l /@subdb

renametohist Syntax

Renames the specified audit tables to their corresponding history tables and re-creates the audit tables without any indexes. This option also creates the script files used to create, rename, rebuild, and drop indexes that were in the audit tables. You can run the following scripts manually when necessary.

create_index_script.sql
rename_index_script.sql
rebuild_index_script.sql
drop_index_script.sql

purge_audit_tables.pl  renametohist -t objects -l /@connection

-t objects: Specifies a comma-separated list of objects for which to rename audit tables to history tables and recreate empty audit tables.

Note:

You do not need to specify child objects for an object; they are included automatically by the script. For example, the /au_profile/serv_extracting child object is reported on if you list the /au_profile object.
-l /@connection: Specifies how to connect to your database.

Sample renametohist Command

purge_audit_tables.pl  renametohist -t au_account -l /@subdb

updfromhist Syntax

Retrieves the data for a given object and its child objects from the history tables and transfers it back to the audit tables.

purge_audit_tables.pl updfromhist -t objects -d date -c commit_size -l /@connection

-t objects

Specifies a comma-separated list of shadow objects to retrieve the data from the history tables and update in the corresponding audit tables.

Shadow objects use an au prefix. For example, a change to a field marked for auditing in the /profile object results in the /au_profile shadow object.

Note:

Do not specify child objects for an object; they are included automatically by the script. For example, the /au_profile/serv_extracting object is reported on when you list the /au_profile object.

-d date

Specifies the cutoff date for retrieving data.

The format is YYYY:MM:DD.

-c commit_size

Specifies the number of rows to save to the database at one time.

-l /@connection

Specifies how to connect to your database. For example:

purge_audit_tables.pl  updfromhist -t au_account -d 2005:03:29 -c 1000 -l /@subdb

help Syntax

Displays the syntax for this script.

Results

The utility notifies you only if it encounters errors.

pin_create_server_cert

Use this utility to create an Oracle wallet and a Transport Layer Security (TLS) certificate for testing purposes. All BRM applications use this wallet to send the trusted server certificate when a client application requests a PCM connection through TLS. For more information, see "Working with SSL/TLS Certificates and Oracle Wallets".

Location

BRM_home/bin

Syntax

pin_create_server_cert

Results

Creates an Oracle wallet and a server certificate in BRM_home/wallet/server.