Thursday, 13 December 2012

Enable Diagnostics in Oracle apps



How to enable Oracle apps Diagnostics-> Examine, for certain users?
Steps 1
Navigate to System Administrator responsibility> Profile> System>

















Steps 2
Enter profile name: Utilities:Diagnostics
Enter Application User for whom you want to enable Diagnostics-> Examine



















Steps 3
Give Yes at User level and Save the Changes










Note –
You can set Yes at Site level also if you want to enable this option for all Oracle application users

Steps 4
Again navigate to System Administrator responsibilityProfileSystem>
Enter profile name: Hide Diagnostics menu entry
Enter Application User for whom you do not want to hide Diagnostics menu entry

















Steps 5
Give No at User level and Save the Changes










Note –
You can set No at Site level also if you do not want to hide menu entry option for all Oracle application users

Steps 6
Congratulations you have successfully enabled Diagnostics-> Examine
Logout from Oracle Application and login again. Now can see Diagnostics-> Examine option

























Monday, 10 December 2012

How to setup audit trail on oracle apps



General Description
The Audit Trail is an Oracle inbuilt functionality that lets audit specific columns belonging to selected tables. This implementation enhances the security of the system.

Purpose
Purpose of this document is to instruct the user to setup the Oracle AuditTrail on the following tables:
  • FND_PROFILE_OPTION_VALUES (Profile Option Updates)
  • FND_USER (New User Creations or Updates)
  • WF_LOCAL_USER_ROLES (Responsibility Assignments)
Getting Started
For each audited table (i.e. FND_USER), the system will create a shadow table named tablename_A (i.e. FND_USER_A). The maximum size of the shadow table name is 26 characters.
The columns to be audited should be selected carefully to avoid an impact on the performances of the system.

Configure the Profile Options
To enable the Audit Trail, it’s required to set 2 profile options at site level:
System Administrator -> Profile -> System
1. Profile option ‘Sign-On:Audit Level’ set to ‘FORM’


2. Profile Option ‘AuditTrail:Activate’ set to ‘YES’














Enable Audit on the Table Owner
According to which table we want to audit, there can be a different table owner on which the auditing should be enabled.
the table owner can be checked running the following query:

SELECT OWNER, TABLE_NAME
FROM DBA_TABLES
WHERE TABLE_NAME = 'FND_PROFILE_OPTION_VALUES'
OR TABLE_NAME = 'FND_USER'
OR TABLE_NAME = 'WF_LOCAL_USER_ROLES'

The query above will show that the owner of all the tables we want to audit is the user ‘APPLSYS’.
To auditing on the user ‘APPLSYS’ can be enabled in the following way:
System Administrator -> Security -> AuditTrail -> Install
Querying the username ‘APPLSYS’ and making sure that the Audit Checkbox is enabled.



















Create and Audit Group
The Audit Group will contain the list of the tables to be audited for our purpose.
System Administrator -> Security -> AuditTrail -> Groups
The Group State should be set to ‘Enable Requested’
Then we create the table list adding the following User Table Names:
  • FND_PROFILE_OPTION_VALUES
  • Define an Application User
  • WF_LOCAL_USER_ROLES
The User Table Name of the FND_USER table is ‘Define an Application User’.






















Selecting the Columns to Audit in FND_PROFILE_OPTION_VALUES
The columns can be set opening this form:
System Administrator -> Security -> AuditTrail -> Tables
First Table to query is FND_PROFILE_OPTION_VALUES. The columns to audit are in the image below.























  • LEVEL_VALUE_APPLICATION_ID – Set by Default
  • LEVEL_VALUE – Set by Default
  • LEVEL_ID – Set by Default
  • PROFILE_OPTION_ID – Set by Default
  • APPLICATION_ID – Set by Default
  • PROFILE_OPTION_VALUE – Needed to log the old profile option value
  • LAST_UPDATE_DATE – Needed to log Date and Time of when the profile option value was updated
    The other columns are not relevant for the auditing purpose.
Selecting the Columns to Audit in FND_USER
Second Table to query is FND_USER. The columns to audit are in the image below.























  • USER_ID – Set by Default
  • USER_NAME – Needed to log the username updates
  • ENCRYPTED_FOUNDATION_PASSWORD – Needed to identify when a password have been reset or when an account have been locked
  • ENCRYPTED_USER_PASSWORD – Needed to identify when a password have been reset or when an account have been locked
  • DESCRIPTION – Needed to log the accounts description updates
  • END_DATE – Needed to log the updates of the accounts end-date
  • START_DATE – Needed to log the updates of the accounts start-date
  • PASSWORD_LIFESPAN_DAYS – Needed to log the updates of the accounts lifespan
  • EMPLOYEE_ID – Needed to log the updates of the accounts lifespan
  • EMAIL_ADDRESS – Needed to log the updates of the accounts email address
  • The other columns are optional or not relevant for the auditing purpose.
  • (*) LAST_LOGON_DATE – Not to be Audited to avoid logging not needed records 
Selecting the Columns to Audit in WF_LOCAL_USER_ROLES
Third Table to query is WF_LOCAL_USER_ROLES. The columns to audit are in the image below


























Testing the AuditTrail Setup
After enabling the AuditTrail it’s needed to test that everything is working properly. The test can be performed executing the following actions:
  • Create a new user ‘TEST01’
  • Edit the description of the user ‘TEST01’
  • Assign a responsibility to the user ‘TEST01’
  • Set a profile option for the user ‘TEST01’

Running the following queries, the output should contain relevant information related to what was done.

SELECT * FROM APPLSYS.FND_USER_A
SELECT * FROM APPLSYS.WF_LOCAL_USER_ROLES_A
SELECT * FROM APPLSYS.FND_PROFILE_OPTION_VALUE_A

Purging the Auditing Tables
It would be wise to create some policy establishing how often the auditing tables should be purged and where and how the data should be archived.
To Purge the auditing table it’s enough to change the ‘Group State’ of the Audit Group setting the value ‘Disable – Purge Table’
System Administrator -> Security -> AuditTrail -> Groups






















 Then the concurrent program ‘AuditTrail Update Tables’ should be executed again.

Sunday, 9 December 2012

Gather Schema and Tables Statistics


Gather Schema and Tables Statistics

Gather Schema Statistics – Concurrent Program 
Connect as System Administrator
Request – Run
Select - Gather Schema Statistics













Click OK button

Estimate Percent: Using any value larger than 50 will force a compute statistics to be
gathered; any value less than 50 only provide estimated statistics. Computed statistics in
some cases could provide a significant performance improvement for Application
modules.
Click the Schedule button to schedule as per your company needs, As a general rule,
schedule the Gather Schema Statistics concurrent program to run once a week, during off
hours, for your entire database



Gather Table Statistics Concurrent Program 
If you have volatile tables that are updated, inserted into or deleted from frequently, then
you should consider running Gather Table Statistics for those tables more frequently,
perhaps nightly during off hours. In the following figure, we’ve chosen a particular table,
FND_CONCURRENT_REQUESTS, and selected 99 for the percent to analyze to ensure
that the table is analyzed using compute, rather than estimate.













Note- Using these two Concurrent Programs also generates statistics on the associated
indexes.



Thursday, 6 December 2012

Oracle Tutorials - Index - Data Structure for Query Performance


Oracle Tutorials - Index - Data Structure for Query Performance

What Is an Index?
Index is an optional structure associated with a table that allow SQL statements to execute more quickly against a table. Just as the index in this manual helps you locate information faster than if there were no index, an Oracle Database index provides a faster access path to table data. You can use indexes without rewriting any queries. Your results are the same, but you see them more quickly.

How To Create a Table Index?
If you have a table with a lots of rows, and you know that one of the columns will be used often a search criteria, you can add an index for that column to in improve the search performance. To add an index, you can use the CREATE INDEX statement as shown in the following script:
CREATE TABLE tip (id NUMBER(5) PRIMARY KEY,
  subject VARCHAR(80) NOT NULL,
  description VARCHAR(256) NOT NULL,
  create_date DATE DEFAULT (sysdate));
Table created.
 
CREATE INDEX tip_subject ON tip(subject);
Index created.

How To List All Indexes in Your Schema?
If you log in with your Oracle account, and you want to get a list of all indexes in your schema, you can get it through the USER_INDEXES view with a SELECT statement, as shown in the following SQL script:
SELECT index_name, table_name, uniqueness 
  FROM USER_INDEXES WHERE table_name = 'EMPLOYEES';
INDEX_NAME              TABLE_NAME            UNIQUENES
----------------------- --------------------- ---------
EMP_EMAIL_UK            EMPLOYEES             UNIQUE
EMP_EMP_ID_PK           EMPLOYEES             UNIQUE
EMP_DEPARTMENT_IX       EMPLOYEES             NONUNIQUE
EMP_JOB_IX              EMPLOYEES             NONUNIQUE
EMP_MANAGER_IX          EMPLOYEES             NONUNIQUE
EMP_NAME_IX             EMPLOYEES             NONUNIQUE
As you can see, the pre-defined table EMPLOYEES has 6 indexes defined in the default sample database.

What Is an Index Associated with a Constraint?
An index associated with a constraint because this constraint is required to have an index. There are two types of constraints are required to have indexes: UNIQUE and PRIMARY KEY. When you defines a UNIQUE or PRIMARY KEY constraint in a table, Oracle will automatically create an index for that constraint. The following script shows you an example:
CREATE TABLE student (id NUMBER(5) PRIMARY KEY,
  first_name VARCHAR(80) NOT NULL,
  last_name VARCHAR(80) NOT NULL,
  birth_date DATE NOT NULL,
  social_number VARCHAR(80) UNIQUE NOT NULL);
Table created.
  
SELECT index_name, table_name, uniqueness 
  FROM USER_INDEXES WHERE table_name = 'STUDENT';
INDEX_NAME              TABLE_NAME            UNIQUENES
----------------------- --------------------- ---------
SYS_C004123             STUDENT               UNIQUE
SYS_C004124             STUDENT               UNIQUE
The result confirms that Oracle automatically created two indexes for you.


How To Drop an Index?
If you don't need an existing index any more, you should delete it with the DROP INDEX statement. Here is an example SQL script:
CREATE TABLE student (id NUMBER(5) PRIMARY KEY,
  first_name VARCHAR(80) NOT NULL,
  last_name VARCHAR(80) NOT NULL,
  birth_date DATE NOT NULL,
  social_number VARCHAR(80) UNIQUE NOT NULL);
Table created.
 
CREATE INDEX student_birth_date ON student(birth_date);
Index created.
 
SELECT index_name, table_name, uniqueness 
  FROM USER_INDEXES WHERE table_name = 'STUDENT';
INDEX_NAME              TABLE_NAME            UNIQUENES
----------------------- --------------------- ---------
SYS_C004129             STUDENT               UNIQUE
SYS_C004130             STUDENT               UNIQUE
STUDENT_BIRTH_DATE      STUDENT               NONUNIQUE 
 
DROP INDEX STUDENT_BIRTH_DATE;
Index dropped.

Can You Drop an Index Associated with a Unique or Primary Key Constraint?
You can not delete the index associated with a unique or primary key constraint. If you try, you will get an error like this: ORA-02429: cannot drop index used for enforcement of unique/primary key.


What Happens to Indexes If You Drop a Table?
If you drop a table, what happens to its indexes? The answer is that if a table is dropped, all its indexes will be dropped too. Try the following script to see yourself:

What Happens to the Indexes If a Table Is Recovered?
If you dropped a table, and recovered it back from the recycle bin, what happens to its indexes? Are all indexes recovered back automatically? The answer is that all indexes will be recovered, if you recover a dropped table from the recycle bin. However, the indexes' names will not be the original names. Indexes will be recovered with the system assigned names when they were dropped into the cycle bin. 

How To Rebuild an Index?
If you want to rebuild an index, you can use the "ALTER INDEX ... REBUILD statement as shown in the following SQL script:

ALTER INDEX EMP_NAME_IX REBUILD;
Statement processed.

How To See the Table Columns Used in an Index?
You can a list of indexes in your schema from the USER_INDEXES view, but it will not give you the columns used in each index in the USER_INDEXES view. If you want to see the columns used in an index, you can use the USER_IND_COLUMNS view. Here is an example script for you:
SELECT index_name, table_name, column_name 
  FROM USER_IND_COLUMNS WHERE table_name = 'EMPLOYEES';
INDEX_NAME           TABLE_NAME       COLUMN_NAME
-------------------- ---------------- ----------------
EMP_EMAIL_UK         EMPLOYEES        EMAIL
EMP_EMP_ID_PK        EMPLOYEES        EMPLOYEE_ID
EMP_DEPARTMENT_IX    EMPLOYEES        DEPARTMENT_ID
EMP_JOB_IX           EMPLOYEES        JOB_ID
EMP_MANAGER_IX       EMPLOYEES        MANAGER_ID
EMP_NAME_IX          EMPLOYEES        LAST_NAME
EMP_NAME_IX          EMPLOYEES        FIRST_NAME

How To Create a Single Index for Multiple Columns?
If you know a group of multiple columns will be always used together as search criteria, you should create a single index for that group of columns with the "ON table_name(col1, col2, ...)" clause.
  
CREATE INDEX student_names ON student(first_name,last_name);
Index created.



Monday, 3 December 2012

DIFFERENTIAL & CUMULATIVE INCREMENTAL BACKUP


A differential backup, which backs up all blocks changed after the most recent incremental backup at level 1 or 0

A cumulative backup, which backs up all blocks changed after the most recent incremental backup at level 0




The only difference between a level 0 incremental backup and a full backup is that a full backup is never included in an incremental strategy. Thus, an incremental level 0 backup is a full backup that happens to be the parent of incremental backups whose level is greater than 0. When you are planning for the Incremental backup in your system. You have start with incremental level 0 then you can proceed with Differential & cumulative incremental backup

RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;

NOTE: you should consider whether you want to spend more time on backup (or) restore/recovery. 

If you are going for the FASTER BACKUP è differential incremental backup, it will do backup quickly. Since it has to take the backup only from last level 1 backup (if no level 1, then it takes a level 0 backup).  But when you want to restore then you need to have all the differential level 1 backup and LEVEL 0 backup to restore.

If you are going for the FASTER RESTORE è cumulative incremental backup, it will little time in doing the backup. Since it will be taking the backup from the last level 0 backup(it will ignore even though you have the level 1 backup).  During the restore, it requires only one LEVEL 0 backup and last LEVEL 1 cumulative backup.


A level 1 incremental backup can be either of the following types:
èDifferential incremental backup, which backs up all blocks changed after the most recent incremental backup at level 1 or 0

RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;
IF YOU ARE NOT SPECIFYING THE WORD CUMULATIVE, THEN ORACLE WILL TAKE IT AS A DIFFERENTIAL BACKUP

è Cumulative incremental backup, which backs up all blocks changed after the most recent incremental backup at level 0

RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

Sunday, 2 December 2012

How to enable auditing in oracle database?

Following are steps to enable auditing in oracle database
1) In the initialization parameter file add an entry
audit_trail=db
2) Shutdown the database.
3) startup the database using the init file.
4) After logging into the database at the SQL prompt run the following script
SQL>@/rdbms/admin/cataudit.sql
With the help of this script various views are created which will help you to monitor the auditing information:-
a) STMT_AUDIT_OPTION_MAP:-Contains information about auditing option type codes. Created by the SQL.BSQ script at CREATE DATABASE time.
b) AUDIT_ACTIONS:- Contains descriptions for audit trail action type codes
c) ALL_DEF_AUDIT_OPTS:- Contains default object-auditing options that will be applied when objects are created
d) DBA_STMT_AUDIT_OPTS:-Describes current system auditing options across the system and by user
e) DBA_PRIV_AUDIT_OPTS:-Describes current system privileges being audited across the system and by user
f) USER_OBJ_AUDIT_OPTS & DBA_AUDIT_TRAIL describes auditing options on all objects. USER view describes auditing options on all objects owned by the current user.
g) USER_AUDIT_TRAIL & USER_AUDIT_TRAIL:- Lists all audit trail entries. USER view shows audit trail entries relating to current user.
h) DBA_AUDIT_OBJECT & USER_AUDIT_OBJECT:-Contains audit trail records for all objects in the system. USER view lists audit trail records for statements concerning objects that are accessible to the current user.
i) DBA_AUDIT_SESSION & USER_AUDIT_SESSION:-Lists all audit trail records concerning CONNECT and DISCONNECT. USER view lists all audit trail records concerning connections and disconnections for the current user.
j) DBA_AUDIT_STATEMENT & USER_AUDIT_STATEMENT :- Lists audit trail records concerning GRANT, REVOKE, AUDIT, NOAUDIT, and ALTER SYSTEM statements throughout the database, or for the USER view, issued by the user
k) DBA_AUDIT_EXISTS:-Lists audit trail entries produced BY AUDIT NOT EXISTS
5) After completion of the script SQL prompt will return.
6)Run the following commands to enable the various auditing
a)SQL>audit create session;
b)SQL>audit create user;
c)SQL>audit drop user;
d)SQL>audit create user;
e)SQL>audit drop tablespace;
f)SQL>audit grant any role;
g)SQL>audit grant any privelege;
h)SQL>audit alter system;
i)SQL>audit alter session;
j)SQL>audit delete on AUD$ by access;
k)SQL>audit insert on AUD$ by access;
l)SQL>audit update on AUD$ by access;
CAUTION:-
As the table AUD$ which contains all the auditing data is created in the system tablespace,
so as the auditing information grows the size of the system tablespace also increases,
so it is advisable to move this particular table AUD$ to some another tablespace.
THE COMMAND TO MOVE THE TABLE IS:-
SQL>create table AUDX tablespace as select * from AUD$;
SQL>rename AUD$ to AUD$$;
SQL>rename AUDX to AUD$;
TO check whether AUD$ table has shifted to the new tablespace write the following query in the SQL prompt
SQL>select table_name,tablespace_name from dba_tables where table_name=’AUD$’;
 


_________________________________________________________________________________
If you want to audit a specific user run the following:

audit alter table, select table, insert table, update table, delete table, grant table, grant
procedure by USERNAME;

To stop audit for that user run:

noaudit alter table, select table, insert table, update table, delete table, grant table,
grant procedure by USERNAME;

To enable auditing for a specific object do:

AUDIT SELECT, INSERT, UPDATE, DELETE ON SCHEMA.TABLE;

To stop auditing:

NOAUDIT SELECT, INSERT, UPDATE, DELETE ON SCHEMA.TABLE;


To see the results:

SQL> select * from dba_audit_trail;

Thursday, 29 November 2012

Copy and Rename an Oracle Database

Copy and Rename an Oracle Database - (without export/import)


You may find it necessary to duplicate (clone) an Oracle database. One method is to use import/export. This method can work fine, but what if your database is too big? Another method is to make a copy of the current database and rename it. This month I will present an article that explains the steps necessary to copy and rename a database. This article will assume that the original database is called PROD and you want to create a TEST duplicate database.
1.) Copy production database files and init.ora

The first step is to locate and copy all database files to their new location. You can use the view V$DATAFILE in the PROD database to locate these files. Before running the query from V$DATAFILE, ensure that you are connected to the PROD database by selecting from V$DATABASE:
  SQL> select name from v$database;

  NAME
  ---------------------------------------
  PROD


  SQL> select name from v$datafile;

  NAME
  ---------------------------------------
  /u08/app/oradata/PROD/system01.dbf
  /u06/app/oradata/PROD/rbs01.dbf
  /u07/app/oradata/PROD/temp01.dbf
  /u10/app/oradata/PROD/userd01.dbf
  /u09/app/oradata/PROD/userx01.dbf
After recording these files, shutdown the PROD database and perform an operating system copy of all database files to another location and/or machine. In my example, I will copy all datafiles to a new location as shown in the following table:
Old LocationNew Location
/u08/app/oradata/PROD/system01.dbf /u08/app/oradata/TEST/system01.dbf
/u06/app/oradata/PROD/rbs01.dbf /u06/app/oradata/TEST/rbs01.dbf
/u07/app/oradata/PROD/temp01.dbf /u07/app/oradata/TEST/temp01.dbf
/u10/app/oradata/PROD/userd01.dbf /u10/app/oradata/TEST/userd01.dbf
/u09/app/oradata/PROD/userx01.dbf /u09/app/oradata/TEST/userx01.dbf
After copying all files to their new location, startup the PROD database.
From the production database, get a copy of the initPROD.ora file and copy it to initTEST.ora. In the initTEST.ora file, change the value of "db_name" from PROD to TEST. Keep in mind that you may also need to change:
  • audit_file_dest
  • background_dump_dest
  • control_files
  • core_dump_dest
  • log_archive_dest
  • user_dump_dest
If the TEST database is going to be on a different machine, copy the initTEST.ora file to that machine in the proper directory.
2.) Create the script that will re-create the controlfile

Using SVRMGR on the PROD database, create a script that will be able to re-create the controlfile for the database.
  PROD on testdb: svrmgrl
  SVRMGR> connect internal
  Connected.
  SVRMGR> alter database backup controlfile to trace;
  Statement processed.
The above statement will put a text copy of the controlfile in the USER_DUMP_DEST directory. You will need to search for the newest trace file in this directory. In UNIX you can use the "ls -lt" command. Once you find the correct trace file, rename it to cr_control.sql and edit it as follows:
  • Remove everything up to the "START NOMOUNT" statement and everything after the semicolon at the end of the "CREATE CONTROLFILE" statement.
  • Edit the line starting with "CREATE CONTROLFILE" and replace the word "REUSE" with the word "SET" right before the keyword DATABASE.
  • On the same line, modify the database name changing it from PROD to TEST.
  • On the same line, change the keyword NORESETLOGS to RESETLOGS.
Your script should now read:
Edited file cr_control.sql
STARTUP NOMOUNT
CREATE CONTROLFILE SET DATABASE "TEST" RESETLOGS NOARCHIVELOG
    MAXLOGFILES 32
    MAXLOGMEMBERS 5
    MAXDATAFILES 600
    MAXINSTANCES 10
    MAXLOGHISTORY 1000
LOGFILE
  GROUP 1 (
    '/u03/app/oradata/TEST/redo_g01a.log',
    '/u04/app/oradata/TEST/redo_g01b.log',
    '/u05/app/oradata/TEST/redo_g01c.log'
  ) SIZE 200K,
  GROUP 2 (
    '/u03/app/oradata/TEST/redo_g02a.log',
    '/u04/app/oradata/TEST/redo_g02b.log',
    '/u05/app/oradata/TEST/redo_g02c.log'
  ) SIZE 200K,
  GROUP 3 (
    '/u03/app/oradata/TEST/redo_g03a.log',
    '/u04/app/oradata/TEST/redo_g03b.log',
    '/u05/app/oradata/TEST/redo_g03c.log'
  ) SIZE 200K
DATAFILE
  '/u08/app/oradata/TEST/system01.dbf',
  '/u06/app/oradata/TEST/rbs01.dbf',
  '/u07/app/oradata/TEST/temp01.dbf',
  '/u10/app/oradata/TEST/userd01.dbf',
  '/u09/app/oradata/TEST/userx01.dbf'
;
If the TEST database is on a different machine move this file to that machine.
3.) Create the new controlfile for TEST

Make sure that your Oracle environment variable "ORACLE_SID" is set to TEST. (i.e. export ORACLE_SID=TEST). Now use SVRMGR and the CREATE CONTROLFILE script (cr_control.sql) to create your controlfile for TEST:
  TEST on testdb: svrmgrl
  SVRMGR> connect internal
  Connected to an idle instance.
  SVRMGR> @cr_control
  ORACLE instance started.
  Total System Global Area      32798752 bytes
  Fixed Size                       39816 bytes
  Variable Size                 22600856 bytes
  Database Buffers               9994240 bytes
  Redo Buffers                    163840 bytes
  Statement processed.
  SVRMGR>
NOTE: Stay logged into SVRMGR and proceed to the next step.
4.) Open the TEST database

Before opening the TEST database, you will need to perform incomplete recovery. After recovery you can open the database using the RESETLOGS option as show below:
  SVRMGR> alter database recover database until cancel using backup controlfile;
  SVRMGR> alter database recover cancel;
  Statement processed.
  SVRMGR> alter database open resetlogs;
  Statement processed.
  SVRMGR>
You can verify that the database was renamed to TEST by querying from V$DATABASE:
    SVRMGR> select name from v$database;
    NAME
    ---------
    TEST
    1 row selected.
    SVRMGR>