How to Verify which GRC (Oracle Governance Risk and Compliance) Version is Installed ?

APPLIES TO:

Oracle Application Access Controls Governor Version .6.4 and later
Information in this document applies to any platform.

GOAL:

How to verify which GRC version is installed?

SOLUTION:

There are 2 ways to find the GRC version.

1). Login to the application and in the right hand side you see a oval shape icon.
Click to see the current GRC application release

2). To check from database.

select current_build_version from grc_sys_version ( From EGRC 864_500 and above query this table)

select current_build_version from grcc_version ( This is for pre EGRC 864.500 releases query this table)

Oracle GRC Data Backup and Restoration

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.

Cloning, Migrating, Backup Oracle Governance Risk Compliance Manager

APPLIES TO:

Oracle Governance, Risk and Compliance Manager Version 6.0 to 7.8
Information in this document applies to any platform.

SYMPTOMS:

What tools are available or best methods for cloning or migrating Business Processes, Risks, Controls, etc from a test environment to a production environment? Can a backup and restore to another system accomplish a system migration?

CHANGES:

New Installation

CAUSE:

Looking for a method of migrating a GRCM system from one server to another.

SOLUTION:

Backing up the GRCM system includes making a copy of the GRCM file system, Stellent Content Server file system,
Windows registry, IIS web server, and the database. A copy of these should be made at the same point in time,
where there are no updates to the GRCM system. When you restore these from backup they can not be out of sync
or the Business Processes may be corrupt. A restore would be copying over the existing file system, registry, and
database. After a file system restore it is recommended to complete rebuild the search collection on the Stellent
Content Server.
Moving a GRCM installation, Content Server file, Windows Registry, IIS and database to another system requires a
consulting services engagement. There are no tools or supported processes to follow in order to migrate or clone
the installation. If you require assistance for the cloning or migrating of data, the Oracle Consulting Services can be
engaged to assist. Oracle support strongly recommends that all migrations and cloning of data be performed by an
Oracle Consulting Services engagement.
Below are some general steps which in theory could work in cloning GRCM data but that have not been tested and
will NOT be supported in any way. For GRCM data cloning, the typical CMU/archiving steps will not work correctly
since the archive will not archive over any data in a current workflow. For GRCM data, there is usually quite a few
items that are in an active workflow.
1. Shutdown all content server and GRCM services for the Development Instance and the Production Instance.
2. Backup production file system and database if desired. It would probably be good to backup all development data as well.
3 Export out the entire Development database.
4. In Production, import the exported copy of the Development database and overwrite all Production Database
information.
5. Copy over all of the directories and files in the Development content server install directory to the production file
system. (Ex: C:/stellent/idcm1).
6. Edit the content server config files and change host names, installation locations, and DB info to match
Production system.
7. Edit the GRCM config files to match any differences between the Development and Production data like the map
document content id values.
8. Restart all services and check the event viewer for any errors.
9. Rebuild the Content Server index.
10. Check the Web server instance name and host name may need to be changed.

Note that the above steps are not a supported solution, and have not been tested, but rather some general conceptual instructions for cloning GRCM data. If you follow the above steps and run into any problems, Oracle support will NOT assist in resolving the issues.

Check tablespace size with Sysdate in Oracle EBS R12

select substr(A.tablespace_name,1,16) "Tablespace",
MAX(A.contents) "Type",
MAX(A.status) "Status",
(SUM(B.BYTES)*COUNT(DISTINCT B.FILE_ID)/COUNT(B.FILE_ID)/1024/1024)-
(ROUND(SUM(C.BYTES)/1024/1024/COUNT(DISTINCT B.FILE_ID))) "USED SIZE(Mb)",
TO_CHAR(100-(SUM(C.BLOCKS)*100*COUNT(B.FILE_ID)/(SUM(B.BLOCKS)*COUNT
(DISTINCT B.FILE_ID)))/COUNT(DISTINCT B.FILE_ID),'999.99')||'%' "USED USAGE",
ROUND(SUM(C.BYTES)/1024/1024/COUNT(DISTINCT B.FILE_ID)) "FREE SIZE(MB)",
TO_CHAR((SUM(C.BLOCKS)*100*COUNT(B.FILE_ID)/(SUM(B.BLOCKS)*COUNT
(DISTINCT B.FILE_ID)))/COUNT(DISTINCT B.FILE_ID),'999.99')||'%' "FREE USAGE",
SUM(B.BYTES)*COUNT(DISTINCT B.FILE_ID)/COUNT(B.FILE_ID)/1024/1024 "TOTAL SIZE(Mb)",
sysdate
from dba_tablespaces A,
DBA_DATA_FILES B,
DBA_FREE_SPACE C
WHERE A.TABLESPACE_NAME=B.TABLESPACE_NAME
AND A.TABLESPACE_NAME=C.TABLESPACE_NAME
GROUP BY A.TABLESPACE_NAME
order by 1;

How to Check/Validate That RMAN Backups Are Good

How to Check/Validate That RMAN Backups Are Good

I Want to restore and recover the database till time ‘9:00, 22-October-2012

Step 1: The below command just gives the report of backups that are used to do the  restore and recover :

RMAN> run
{
set until time "to_date('2015-20-07:9:00:00','yyyy-dd-mm:hh24:mi:ss')";
restore database preview;
}


Step 2: Then run the below command to check the backup pieces are good :

The below command will read the backup pieces/Copies which has datafiles and if finds any error it will report at the RMAN prompt.

RMAN> run
{
allocate channel c1 type disk;
set until time "to_date('2012-22-10:9:00:00','yyyy-dd-mm:hh24:mi:ss')";
restore database validate;
}


Step 3: Check the archivelogs needed for recovery

Replace the xxx, yyy with the start and end archivelog sequence reported by restore database preview command ran in the step 1.

RMAN> run
2> {
allocate channel c1 type disk;
restore archivelog from sequence 48301 until sequence 48317 validate;
}

How to retrieve the deleted rows in a table

You can use FLASHBACK TABLE to retrieve your rows. But before that you must enable row movement by following query

ALTER TABLE hr.employees ENABLE ROW MOVEMENT;
And there after firing the below query for the particular timestamp when your rows were existing at that time.

FLASHBACK TABLE hr.employees TO TIMESTAMP TO_TIMESTAMP('17-10-2011 12:19:00','DD-MM-YYYY HH24:MI:SS');

Example: select * from apps.PER_CONTACT_RELATIONSHIPS as of timestamp to_timestamp('31-05-2015 04:00:00','DD-MM-YYYY HH24:MI:SS');

FLASHBACK is used to retrive the dropped tables.

Use the following to retrieve the deleted and committed rows

select * from table_name as of timestamp to_timestamp(sysdate-(360/1440))
The above sample SQL will fetch the status of data in the table 6 hours earlier.

Recently changed profile options in Oracle EBS R12

select p.profile_option_name SHORT_NAME, n.user_profile_option_name "PROFILE NAME",

decode(v.level_id, 10001, 'Site', 10002, 'Application',

10003, 'Responsibility', 10004, 'User', 10005, 'Server',

10007, 'SERVRESP', 'UnDef') LEVEL_SET,

decode(to_char(v.level_id), '10001', '',

'10002', app.application_short_name, '10003', rsp.responsibility_key,

'10005', svr.node_name, '10006', org.name, '10004', usr.user_name,

'10007', 'Serv/resp', 'UnDef') "CONTEXT", v.profile_option_value VALUE, v.LAST_UPDATE_DATE  

from fnd_profile_options p,

fnd_profile_option_values v,

fnd_profile_options_tl n,

fnd_user usr,

fnd_application app,

fnd_responsibility rsp,

fnd_nodes svr,

hr_operating_units org

where p.profile_option_id = v.profile_option_id (+)

and p.profile_option_name = n.profile_option_name

--and upper(n.user_profile_option_name) like upper('BNE%')

--and trunc(v.LAST_UPDATE_DATE) > trunc(sysdate-170)

and usr.user_id (+) = v.level_value

and rsp.application_id (+) = v.level_value_application_id

and rsp.responsibility_id (+) = v.level_value

and app.application_id (+) = v.level_value

and svr.node_id (+) = v.level_value

and org.organization_id (+) = v.level_value

and v.LAST_UPDATE_DATE is not null 

order by last_update_date desc, short_name, level_set;