5 Managing, Backing Up, and Restoring Services Gatekeeper

Configuring Services Gatekeeper to Avoid Server Failure

See ”Avoiding and Recovering From Server Failure” in Fusion Middleware Manager Startup and Shutdown for Oracle WebLogic Server for more information on ensuring that the WebLogic Server component of your Services Gatekeeper installation is properly configured to avoid failures, and recover from them in the event one occurs.

Backing Up an Oracle Enterprise Database

If you store your Services Gatekeeper data in an Oracle Enterprise Database, see the section on backup and recovery in the Oracle Database Documentation Library for more information about backing up and restoring Services Gatekeeper data.

• For Oracle Enterprise Database 11g R2 users, see "Backup and Recovery User's Guide" here:

  http://docs.oracle.com/cd/E11882_01/backup.112/e10642/toc.htm

  and "Backup and Recovery Reference" here:

  http://docs.oracle.com/cd/E11882_01/backup.112/e10643/toc.htm

  for more information.

• For Oracle Enterprise Database 12c users, see "Backup and Recovery User's Guide" here:

  http://docs.oracle.com/cd/E16655_01/nav/portal_4.htm#backup_and_recovery

  and "Backup and Recovery Reference" here:

  http://docs.oracle.com/cd/E16655_01/backup.121/e17631/toc.htm

  for more information.

Backing up a MySQL Database

If you store your Services Gatekeeper data in a MySQL database, see "MySQL Backup and Recovery" here:

http://dev.mysql.com/doc/refman/5.7/en/backup-and-recovery.html

for more information about backing up and restoring Services Gatekeeper data.

Backing Up a JavaDB Database

JavaDB offers two methods of backing up a JavaDB database:

• Offline backup - Stop the database and use operating system commands to simply copy the database directory. The database is unavailable during this process.

• Online backup - Using the JavaDB backup commands. The database is read-only during this process.

For details see ”Backing up and restoring databases" on the Apache web site:

https://db.apache.org/derby/docs/10.1/adminguide/cadminhubbkup98797.html

About Cleaning Database Tables

Table 5-1 lists the database tables that you must periodically clean to prevent them from growing too large and adversely affecting performance. See your database documentation for instructions on deleting rows from these tables.

About Cleaning EDR Analytics Tables

Clean the EDR analytics tables listed in Table 5-1 if you use the EDR analytics feature and have EdrAanalyticMBean.StoreHistory set true. The cleaning interval depends on the amount of traffic stored in your database. However, these tables tend to grow quickly and require daily maintenance.

About Cleaning the SLEE_CHARGING Table

The SLEE_CHARGING table cleaning interval depends on the amount of charging traffic, so it is difficult to specify a recommended interval. There is usually one row in this table per plug-in transaction. A row can contain up to 300 bytes of data.

Operators export charging data from the SLEE_CHARGING table to a file either by using a scheduled script or by integrating with a billing system such as Oracle Communications Billing and Revenue Management.

Charging data is contained in CDRs, which are a type of event data record (EDR). CDRs are integrated by EDR listeners. You can also listen for alarms by setting up an SNMP/EDR listener. If you do so, disable CDR and alarm storage in the database by setting the StoreAlarms or Store CDRs attributes to false for the EDR Service.

For more information about

• EDRs, CDRs, and alarms, see "Managing and Configuring EDRs, CDRs, and Alarms".

• ”Creating EDR Listeners”, see Services Gatekeeper Extension Developer's Guide.

• Generating SNMP MIB Files, see "Generating SNMP MIB Files".

• Setting the expiration of data stored in the database tables, see "Configuring Storage Expiration".

Creating a Script to Clean SLEE_CHARGING

If your Services Gatekeeper implementation has high traffic, such that these three tables are updated with millions of records per day, Oracle recommends that you create a script to clean them and run it for two to three hours. This script would ideally copy all data that arrived after the last cleaning to another table and then delete everything currently in the table. This script does not require a server restart.

To clean the SLEE_CHARGING table, create a shell script or PERL/SQL combination such as the following:

1. Set up a repository for the data in the SLEE_CHARGING data. To do so, create a table called SLEE_CHARGING_BACKUP.

2. Create a SQL query that:

   1. Selects all data in the SLEE_CHARGING table that is more than 15 minutes old.

      For example, if you run the script every 3 hours, the script would capture 2 hours and 45 minutes worth of data.

   2. Insert the selected data/rows into the SLEE_CHARGING_BACKUP table.

   3. Delete the same data from the SLEE_CHARGING table.

The steps a and b can easily be combined in one SQL query, for example:

insert into slee_charging_bkup(list all columns~ )
select list all the columns~
from slee_charging
where stored_ts millisecs calculated~

Archive the data into a new table called SLEE_STATISTICS_DATA as shown in Example 5-1:

create table slee_statistics_data_tmp1(
slee_name,
timestamp,
type_id,
transactions,
source_entity,
source_app_id,
datetime,
primary key ( timestamp, type_id )
)
organization index
nocompress
as select slee_name, timestamp, type_id, transactions, source_entity, source_app_id,
to_date(to_char(timestamp'1970-01-01 00:00:00.00' + numtodsinterval(timestamp/1000,'SECOND'), 
'DD-MON-YYYY HH24:MI:SS'),'DD-MON-YYYY HH24:MI:SS') from slee_statistics_data;