Restoring the Metrics database and PowerCube incrementally

If you have limited disk space, you can restore both the Metrics database and the PowerCube in increments.

Before you begin

If you plan to restore the PowerCube on a staging server before you copy it to your production server, begin by installing Cognos® Business Intelligence on the staging server. Install and configure the staging server just like the production server. Install the customized version of Cognos® Business Intelligence on the staging server. This server must also have access to the LDAP directory where the Cognos® administrator account resides.

About this task

The Metrics database contains the raw data that is used to generate the PowerCube. Whenever you restore the Metrics database from the backup, you must rebuild the PowerCube to ensure that it contains the full set of data.

If the Metrics database is large and your space for restoring the database and rebuilding the PowerCube is limited, you can complete the process incrementally by restoring subsets of data. Rebuild the PowerCube to add each additional set of data incrementally. Delete the restored data to prepare the database for the next increment. When the PowerCube is rebuilt, complete a final restore on the Metrics database to replace the data that you deleted between increments.
Note: If you prefer to rebuild the entire PowerCube in a single operation, see Rebuilding the entire Metrics database and PowerCube.

If the database is large, it can take a long time to restore it and rebuild the PowerCube. To minimize the impact on your users, restore the PowerCube to a staging server and then copy the completed PowerCube to the production server.

Procedure

  1. Prepare the staging server where you plan to rebuild the PowerCube:
    1. Copy the Transformer_install_path/metricsmodel directory and its contents from the production server where IBM® Cognos® Transformer is installed.

      This directory contains the PowerCube model files that specify how the PowerCube is built. The directory is specified in the cognos.transformer.install.path property in the cognos-setup.properties file.

    2. Create an incremental version of the script that builds the PowerCube:
      1. Go to the Powercube_save_path/metricsmodel directory.
      2. Copy the build-all.sh|bat script to a new file called incremental-build-all.sh|bat in the same directory.
      3. Edit the incremental-build-all.sh|bat file and delete the following statements to avoid accidentally deleting incremental additions to the PowerCube:
        • AIX® and Linux:

          echo delete all existing cube files... rm -rf [POWERCUBE_SAVE_PATH]/*

        • Windows:

          echo delete all existing cube files... del /F /Q "[POWERCUBE_SAVE_PATH]" for /D %%i in ("[POWERCUBE_SAVE_PATH]") do RD /S /Q "%%i"

      4. Save and close the file.
  2. On the database server, restore the first increment of data to the Metrics database. For more information, see your database product documentation.

    For best results, restore data in full-month increments (multiple months are acceptable provided you restore the complete set of data for each month). Restoring data for full months ensures that you do not duplicate data by restoring it twice.

    For example, suppose that you restore data for 1-May-2014 through 12-May-2014 but omit the remainder of the data for that month. In the next increment, you must ensure that you restore only the remaining data for that month (13-May-2014 through 31-May-2014). If you want to restore the entire month in the second increment, you must first delete the partial month that you already restored. Restoring full-month increments avoids this problem.
    Note: If the final set of data comprises an incomplete month, there is no risk of duplication.
    If you restored a partial month's data, you can delete those records from the database. You can identify the records from the timestamp column for each table. Table 1 lists the database tables and corresponding timestamp columns where you can delete records. For example, in the F_TRX_EVENT database table, check the data in the EVENT_TS column and delete the records where the date falls within the time period that you want to delete.
    Table 1. Tables to reference when you are deleting records for partial months

    Column 1 lists the name of a table in the database and column 2 specifies the corresponding timestamp column that you can use to determine which records to delete.

    Table name in database Timestamp column
    F_TRX_EVENT EVENT_TS
    F_USER_EVENT_COUNT UPDATE_TS
    F_ITEM_EVENT_COUNT UPDATE_TS
  3. On the staging server, rebuild the first increment of restored data in the PowerCube:
    1. Go to the Powercube_save_path/metricsmodel directory.
    2. Run the build-all.sh|bat script to rebuild the PowerCube from the first set of restored Metrics data.

      If there is already a PowerCube in the directory, the build-all.sh|bat script deletes it before it builds the new one. When you build the PowerCube incrementally, run this version of the script once only so that you do not delete the incremental copies of the PowerCube.

  4. Complete the following steps for each subsequent increment of data to be restored:
    1. On the database server, delete the previously restored data from the Metrics database to prevent accidental duplication.
    2. On the database server, restore the next increment of data to the Metrics database by following the instructions in your database product documentation.
    3. On the staging server, rebuild the new increment of restored data to the PowerCube by running the incremental-build-all.sh|bat script.

    Repeat this process until the PowerCube is rebuilt.

  5. Move the rebuilt PowerCube to the production server by copying the Powercube_save_path directory and its contents from the staging server:

    The directory is specified in the cognos.cube.path property in the cognos-setup.properties file.

  6. Delete the data from the Metrics database that was previously restored. Deleting this data prevents duplication the next time that you restore the database.