Admin: System Maintenance

Overview

This section describes system maintenance tasks to be undertaken to ensure an RPI’s optimal health and performance.

Backup

To prevent data loss in the broadest range of failure scenarios, regularly back up the most important files/folders/databases 

1. In SQL Server, for all databases, it is recommended that you utilize the Full Recovery Model: http://msdn.microsoft.com/en-us/library/ms190217(v=sql.105).aspx:

   • <ClientDataWarehouse>

   • Pulse

   • Pulse_Logging

   • Interaction_xxx databases

   • InteractionAudit_xxx databases

2. The important files and folders are as follows:

   • C:\inetpub\wwwrpi\*

   • C:\Program Files\Redpoint Global\*

Creating a Recovery Point

To create an RPI recovery point, from which a system can be restored, please follow these steps:

1. Stop the following RPI Windows services:

   • Execution

   • Node Manager

2. In SQL Server back up the following databases:

   • Pulse

   • Pulse_Logging

   • Interaction_xxx

   • InteractionAudit_xxx

3. In Windows File Explorer, back up the following folders:

   • At the RPI application server:

     • C:\inetpub\wwwrpi\*

     • C:\Program Files\Redpoint Global\*

   • At the RPI Realtime server (if applicable):

     • C:\inetpub\*rpi\*

Restore Procedure

To restore RPI from a recovery point, please follow these steps:

1. Using Server Workbench, take all cluster nodes offline.

2. Stop all cluster nodes’ Redpoint  Interaction Node Manager Services.

3. In IIS, stop any RPI-related websites.

4. In SQL Server restore the following databases from the backup:

   • Pulse

   • Pulse_Logging

   • Interaction_xxx

   • InteractionAudit_xxx

5. In Windows File Explorer, restore the following folders from the backup:

   • At the RPI application server:

     • C:\inetpub\wwwrpi\*

     • C:\Program Files\Redpoint Global\*

   • At the RPI Realtime server (if applicable):

     • C:\inetpub\*rpi\*

6. Start all cluster nodes’ Redpoint  Interaction Node Manager Services.

7. In IIS, start any RPI-related sites.

8. Using Server Workbench, put all cluster nodes back online.

If you restore from a recovery point, all activities undertaken and artifacts created within RPI since the original recovery point backup was created will be lost.

Monitoring

1. Using a Network Monitoring Tool, monitor the following Windows services (automatic restart where appropriate):

   • RPI Node Manager Service

   • RPI Execution Service

2. Using a Network Monitoring Tool, monitor the status of following URL (if inaccessible, client applications will be unable to connect to Interaction): https://<ExternalServerName>/Interaction

3. SSL Certificate Expiration Monitoring

SQL Server

1. In SQL Server, periodically identify and create essential indexes missing on database tables: http://msdn.microsoft.com/en-us/library/ms345417(v=sql.105).aspx. This is recommended only for the <ClientDataWarehouse> and NOT the three Interaction databases.

2. In SQL Server, for all four databases, periodically remedy index fragmentation by either reorganizing or rebuilding indexes: http://msdn.microsoft.com/enus/library/ms189858(v=sql.105).aspx

3. In SQL Server, for all four databases, periodically update the distribution of statistics that are used by SQL Server to optimize navigation through tables during the processing of Transact-SQL statements: http://msdn.microsoft.com/enus/library/ms178678(v=sql.105).aspx  

4. In SQL Server, for all four databases, periodically check the allocation and structural integrity of user and system tables as well as indexes in the databases: http://msdn.microsoft.com/en-us/library/ms180226(v=sql.105).aspx  

Changing the Data Warehouse Schema

There may arise occasions where a given client’s data warehouse’s schema needs to change.  A

SQL Server stored procedure (op_RenameDefaultSchema) is provided in each client’s

Interaction operational database.  This can be executed, using the following syntax, to make the change: exec dbo.op_RenameDefaultSchema 'oldschema', 'newschema'

The decision to separate the Offer History schema from the main Data Warehouse schema is one that should be made during the planning stages of your RPI deployment. Configuring a separate Offer History schema after the application is live and assets have been built could result in audience and interaction execution errors and is not recommended.