Introduction:
This document summarizes a best-practice approach to managing data backup and restoration for
Oracle’s Governance, Risk and Compliance (GRC) solution. This document is intended to share ideas and techniques that you might find valuable. Oracle provides this information to you solely for your evaluation. It is not Oracle’s formal guidance, and Oracle cannot provide additional information or support. For additional information or support, contact your Specialized Oracle GRC Implementation Partner.
Like any business application, Oracle GRC deserves a backup and restoration plan that is both
appropriate and pragmatic. Neither too little nor too much ought to be done; the former would expose
the organization to excess risk while the latter would be an inefficient use of resources.
In most cases, the most significant determinant of a plan’s scope and effort is the answer to the
following question: does the application require “high availability”? High availability applications are
generally those that must perform critical business processes in extremely short time frames (usually on the order of minutes, seconds, or less) or at extremely high volumes (e.g., thousands or millions of transactions per hour, 24/7). High availability features are intended to enable these service levels, protect against unplanned downtime, and minimize planned downtime. These features could include Process Death Detection and Restart, Server Clustering, Load Balancing, Failover, Rolling Upgrades, Rolling Configuration Changes, and Dynamic Discovery.
Oracle GRC is rarely considered a high availability application because in most cases short periods of unavailability would not affect the organization’s performance. Consequently, a backup, restoration, and maintenance plan for the GRC solution need not include high availability elements. Instead, a more costeffective set of tactics is usually indicated, as described below.
Backup GRC :
As a standard practice, both on a periodic basis and before patches are applied, backups should be taken so that the application can be restored if necessary. The following steps should be considered for GRC backup:
1. Identify GRC's file repositories:
a. Log into GRC.
b. Navigate to the Manage Application Configuration page.
c. Note the directories specified in the "Transaction ETL Path" field and "Report Repository Path" field.
2. Shut down the GRC application in the following order:
a. If Webtier is used (in rare cases where load balancing is necessary):
1. Stop GRC's Webtier server.
2. Before proceeding, run the ./opmnctl status command, tail the log file and
'grep' for the server's process(s) to verify that Webtier has stopped.
b. If OBIEE is run as a managed server (for GRCI):
1. Stop GRC's ManagedServer(s).
2. Before proceeding, tail the log file and
'grep' for the server's process(s) to verify that the server has stopped.
c. Stop GRC's AdminServer.
1. Before proceeding, tail the log file and 'grep' for the server's process(s) to verify that the server has stopped.
3. Backup GRC :
a. Perform a routine data backup:
1. Back up the GRC schema.
2. If GRCI is installed: Back up the DA schema.
3. Back up the contents of the file repository directories noted above in
Step 1.c.
b. If you have just installed GRC or applied a GRC patch: Perform a routine application
server backup:
1. Backup the <Middleware_Home> folder (if using Weblogic) or <Tomcat_Home> folder (if using Tomcat).
2. If using GRCI with OBIEE: Backup the BI schemas
3. If using Weblogic 12c: Backup the weblogic schemas
c. Note the date and version of the backups in your records.
Restore GRC to the environment from which backup was made
1. Prepare GRC's application server(s):
a. Verify that the environment to be restored is at the same patch level as that of the
backup. If not, deploy the right patch.
b. If the application server(s) are running well: Shut down the GRC application in the
following order:
1. If Webtier is used (in rare cases where load balancing is necessary):
i. Stop GRC's Webtier server.
ii. Before proceeding, run the ./opmnctl status command, tail the log file and 'grep' for the server's process(s) to verify that the Webtier has stopped.
2. If OBIEE is run as a managed server (for GRCI):
i. Stop GRC's ManagedServer(s).
ii. Before proceeding, tail the log file and 'grep' for the server's process(s)
to verify that the server has stopped.
3. Stop GRC's AdminServer.
i. Before proceeding, tail the log file and 'grep' for the server's process(s)
to verify that the server has stopped.
c. If the application server(s) are not running well:
1. Restore the application server (<Middleware_Home> or <Tomcat_Home>) from
backup made in Step 3.b above (under 'Backup GRC').
2. If using GRCI with OBIEE: Restore the BI schemas
3. If using Weblogic 12c: Restore the weblogic schemas
2. Restore GRC data:
a. Restore the GRC schema from backup.
b. If GRCI is installed: restore the DA schema from backup.
c. Restore the entire contents of the Transaction ETL Path from the backup that was
made at the same time as the GRC schema backup. The restored folder structure must
be identical to what it was when the backup was taken.
d. Restore the entire contents of the Report Repository Path from the backup that was
made at the same time as the GRC schema backup. The restored folder structure must
be identical to what it was when the backup was taken.
3. Rename grc.log to grc.log.<current_date>. When GRC application is started it will create a new
log file.
4. Start the GRC application:
a. Start GRC's AdminServer.
1. Before proceeding, tail the AdminServer and GRC log files to verify that the
server is running.
b. If OBIEE is run as a managed server (for GRCI):
1. Start GRC's ManagedServer(s).
2. Tail the ManagedServer(s) and GRC log files to verify that the server(s) are
running before proceeding.
c. If Webtier is used (in rare cases where load balancing is necessary):
1. Start GRC's Webtier.
2. Run the ./opmnctl status command, tail the Webtier and GRC log files to verify
that Webtier is running before proceeding.
5. Verify that all servers are running.
6. Verify that you can log into the GRC application.
Conclusion:
Oracle GRC can be used for many tasks. The frequency of changes to the solution’s data is different for every customer. Other factors to consider include the frequency of backups, the cost/benefit of having a secondary site, and the cost of any additional hardware, resources, and maintenance needed. Options for backup and restoration are offered in this document as a guide; ultimately each customer will have different requirements. Your Specialized Oracle GRC Implementation Partner is equipped to help you specify the backup and restoration plan that is right for you.
This document summarizes a best-practice approach to managing data backup and restoration for
Oracle’s Governance, Risk and Compliance (GRC) solution. This document is intended to share ideas and techniques that you might find valuable. Oracle provides this information to you solely for your evaluation. It is not Oracle’s formal guidance, and Oracle cannot provide additional information or support. For additional information or support, contact your Specialized Oracle GRC Implementation Partner.
Like any business application, Oracle GRC deserves a backup and restoration plan that is both
appropriate and pragmatic. Neither too little nor too much ought to be done; the former would expose
the organization to excess risk while the latter would be an inefficient use of resources.
In most cases, the most significant determinant of a plan’s scope and effort is the answer to the
following question: does the application require “high availability”? High availability applications are
generally those that must perform critical business processes in extremely short time frames (usually on the order of minutes, seconds, or less) or at extremely high volumes (e.g., thousands or millions of transactions per hour, 24/7). High availability features are intended to enable these service levels, protect against unplanned downtime, and minimize planned downtime. These features could include Process Death Detection and Restart, Server Clustering, Load Balancing, Failover, Rolling Upgrades, Rolling Configuration Changes, and Dynamic Discovery.
Oracle GRC is rarely considered a high availability application because in most cases short periods of unavailability would not affect the organization’s performance. Consequently, a backup, restoration, and maintenance plan for the GRC solution need not include high availability elements. Instead, a more costeffective set of tactics is usually indicated, as described below.
Backup GRC :
As a standard practice, both on a periodic basis and before patches are applied, backups should be taken so that the application can be restored if necessary. The following steps should be considered for GRC backup:
1. Identify GRC's file repositories:
a. Log into GRC.
b. Navigate to the Manage Application Configuration page.
c. Note the directories specified in the "Transaction ETL Path" field and "Report Repository Path" field.
2. Shut down the GRC application in the following order:
a. If Webtier is used (in rare cases where load balancing is necessary):
1. Stop GRC's Webtier server.
2. Before proceeding, run the ./opmnctl status command, tail the log file and
'grep' for the server's process(s) to verify that Webtier has stopped.
b. If OBIEE is run as a managed server (for GRCI):
1. Stop GRC's ManagedServer(s).
2. Before proceeding, tail the log file and
'grep' for the server's process(s) to verify that the server has stopped.
c. Stop GRC's AdminServer.
1. Before proceeding, tail the log file and 'grep' for the server's process(s) to verify that the server has stopped.
3. Backup GRC :
a. Perform a routine data backup:
1. Back up the GRC schema.
2. If GRCI is installed: Back up the DA schema.
3. Back up the contents of the file repository directories noted above in
Step 1.c.
b. If you have just installed GRC or applied a GRC patch: Perform a routine application
server backup:
1. Backup the <Middleware_Home> folder (if using Weblogic) or <Tomcat_Home> folder (if using Tomcat).
2. If using GRCI with OBIEE: Backup the BI schemas
3. If using Weblogic 12c: Backup the weblogic schemas
c. Note the date and version of the backups in your records.
Restore GRC to the environment from which backup was made
1. Prepare GRC's application server(s):
a. Verify that the environment to be restored is at the same patch level as that of the
backup. If not, deploy the right patch.
b. If the application server(s) are running well: Shut down the GRC application in the
following order:
1. If Webtier is used (in rare cases where load balancing is necessary):
i. Stop GRC's Webtier server.
ii. Before proceeding, run the ./opmnctl status command, tail the log file and 'grep' for the server's process(s) to verify that the Webtier has stopped.
2. If OBIEE is run as a managed server (for GRCI):
i. Stop GRC's ManagedServer(s).
ii. Before proceeding, tail the log file and 'grep' for the server's process(s)
to verify that the server has stopped.
3. Stop GRC's AdminServer.
i. Before proceeding, tail the log file and 'grep' for the server's process(s)
to verify that the server has stopped.
c. If the application server(s) are not running well:
1. Restore the application server (<Middleware_Home> or <Tomcat_Home>) from
backup made in Step 3.b above (under 'Backup GRC').
2. If using GRCI with OBIEE: Restore the BI schemas
3. If using Weblogic 12c: Restore the weblogic schemas
2. Restore GRC data:
a. Restore the GRC schema from backup.
b. If GRCI is installed: restore the DA schema from backup.
c. Restore the entire contents of the Transaction ETL Path from the backup that was
made at the same time as the GRC schema backup. The restored folder structure must
be identical to what it was when the backup was taken.
d. Restore the entire contents of the Report Repository Path from the backup that was
made at the same time as the GRC schema backup. The restored folder structure must
be identical to what it was when the backup was taken.
3. Rename grc.log to grc.log.<current_date>. When GRC application is started it will create a new
log file.
4. Start the GRC application:
a. Start GRC's AdminServer.
1. Before proceeding, tail the AdminServer and GRC log files to verify that the
server is running.
b. If OBIEE is run as a managed server (for GRCI):
1. Start GRC's ManagedServer(s).
2. Tail the ManagedServer(s) and GRC log files to verify that the server(s) are
running before proceeding.
c. If Webtier is used (in rare cases where load balancing is necessary):
1. Start GRC's Webtier.
2. Run the ./opmnctl status command, tail the Webtier and GRC log files to verify
that Webtier is running before proceeding.
5. Verify that all servers are running.
6. Verify that you can log into the GRC application.
Conclusion:
Oracle GRC can be used for many tasks. The frequency of changes to the solution’s data is different for every customer. Other factors to consider include the frequency of backups, the cost/benefit of having a secondary site, and the cost of any additional hardware, resources, and maintenance needed. Options for backup and restoration are offered in this document as a guide; ultimately each customer will have different requirements. Your Specialized Oracle GRC Implementation Partner is equipped to help you specify the backup and restoration plan that is right for you.
How to pull toxic combinations or SOD violations from Oracle GRC database?
ReplyDeleteCan you please provide your input?
Thanks!