With the Import Data Pump parameter SQLFILE you can specify the name of a file into which all of the SQL DDL is written that Import would have executed, based on other parameters. The SQL is not actually executed, and the target system remains unchanged. The file is written to the directory object specified in the DIRECTORY parameter, unless another directory_object is explicitly specified here. Any existing file that has a name matching the one specified with this parameter is overwritten.
Syntax: SQLFILE=[directory_object:]file_name
Example:

1. By using ps -ef  at unix prompt.

% ps -ef | grep expdp oracle    8874  8704  1 07:00 pts/2    00:00:03 expdp                DIRECTORY=my_dir ..

2. By this sql script.

SQL> conn /as sysdba
Connected.
SQL> select to_char(sysdate,’YYYY-MM-DD HH24:MI:SS’) “DATE”, s.program, s.sid,
2         s.status, s.username, d.job_name, p.spid, s.serial#, p.pid
3    from v$session s, v$process p, dba_datapump_sessions d
4   where p.addr=s.paddr and s.saddr=d.saddr;

DATE                PROGRAM                                                                 SID STATUS   USERNAME
——————- —————————————————————- ———- ——– ———–
2009-11-16 16:38:23 impdp.exe                                                               127 ACTIVE   SYSTEM
2009-11-16 16:38:23 ORACLE.EXE (DM00)                                                       130 ACTIVE   SYSTEM
2009-11-16 16:38:23 ORACLE.EXE (DW01)                                                       135 ACTIVE   SYSTEM

When the Oracle Database is been created, the sql.bsq script is run which creates a rle called PUBLIC. “create role public “

But you cannot see from DBA_ROLES view that the role exists

SQL> select * from dba_roles where role=’PUBLIC’;
no rows selected

The DBA_ROLES view is created during the execution of the catalog.sql script:

create or replace view DBA_ROLES (ROLE, PASSWORD_REQUIRED)
as
select name, decode(password, null, ‘NO’, ‘EXTERNAL’, ‘EXTERNAL’,
‘GLOBAL’, ‘GLOBAL’, ‘YES’)
from  user$
where type# = 0 and name not in (‘PUBLIC’, ‘_NEXT_USER’);

You see how the PUBLIC role is hidden from DBA_ROLES view.

In SYS.USER$, there are 2 types of objects: role (0) or user (1).

SQL> select user#, name from sys.user$ order by 1;

USER# NAME
———- ——————————
0 SYS
1 PUBLIC
2 CONNECT
3 RESOURCE
4 DBA
5 SYSTEM
6 SELECT_CATALOG_ROLE
7 EXECUTE_CATALOG_ROLE
8 DELETE_CATALOG_ROLE
9 EXP_FULL_DATABASE
10 IMP_FULL_DATABASE
11 OUTLN
12 RECOVERY_CATALOG_OWNER
13 GATHER_SYSTEM_STATISTICS
14 LOGSTDBY_ADMINISTRATOR
15 AQ_ADMINISTRATOR_ROLE
16 AQ_USER_ROLE

When we create a user if the create session role is granted to public. then the created user can connect without giving it the create session role.

E.g:-

1. We create a user.

SQL> create user USER123 identified by USER123;

User created.

2. Try to connect that user.

SQL> connect USER123/USER123;
ERROR:
ORA-01045: user USER123 lacks CREATE SESSION privilege; logon denied

Warning: You are no longer connected to ORACLE.

3. Grant create session to public;

SQL> grant create session to public;
SP2-0640: Not connected
SQL> conn /as sysdba
Connected.
SQL> grant create session to public;

Grant succeeded.

4. Try to connect again. It is been connected,

SQL> connect USER123/USER123;
Connected.

In fact the user, though not granted the CREATE SESSION privilege directly
got it from the PUBLIC role that had this privilege been granted previously.

SQL> select * from user_sys_privs;

USERNAME                       PRIVILEGE                            ADM
—————————— ———————————— —
PUBLIC                         CREATE SESSION                       NO

So when you grant some privileges or roles to PUBLIC, this means that any
newly created user is automatically granted these without requiring any
explicit GRANT statement.

That’s it.

CREATE OR REPLACE PROCEDURE kill_drop_user (in_username IN VARCHAR2,
sleep_interval IN NUMBER DEFAULT 10)
AS
PRAGMA AUTONOMOUS_TRANSACTION;
cannot_drop_user EXCEPTION;
PRAGMA EXCEPTION_INIT(cannot_drop_user, -1940);
user_count    NUMBER := -1;
BEGIN
SELECT count(*) INTO user_count FROM dba_users WHERE username = in_username;
IF user_count = 0 THEN
DBMS_OUTPUT.PUT_LINE(‘User ‘ || in_username || ‘ does not exist.’);
RETURN;
END IF;
FOR i IN (SELECT sid, serial# FROM v$session WHERE username = in_username) LOOP
EXECUTE IMMEDIATE ‘alter system kill session ‘ || ”” || i.sid || ‘,’ || i.serial# || ”’ immediate’;
DBMS_OUTPUT.PUT_LINE(‘Killing user ‘ || i.sid || ‘, ‘ || i.serial#);
END LOOP;
LOOP
BEGIN
DBMS_OUTPUT.PUT_LINE(‘Attempting to drop user ‘ || in_username || ‘…’);
EXECUTE IMMEDIATE ‘DROP USER ‘ || in_username || ‘ CASCADE’;
EXIT WHEN SQLCODE <> -1940;
EXCEPTION
WHEN cannot_drop_user THEN
–DBMS_OUTPUT.PUT_LINE(SQLERRM);
DBMS_OUTPUT.PUT_LINE(‘Waiting ‘ || sleep_interval || ‘ seconds for resource clean-up…’);
DBMS_LOCK.SLEEP(sleep_interval);
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE(‘Inner: ‘ || SQLERRM);
END;
END LOOP;
DBMS_OUTPUT.PUT_LINE(‘Exiting loop with SQLCODE: ‘ || SQLCODE);
DBMS_OUTPUT.PUT_LINE(‘User ‘ || in_username || ‘ has been dropped.’);
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE(‘Outer: ‘ || SQLERRM);
END;
/

Configuring the Sample Code

This script is intended to be run by the SYS user of the database.
Running the Sample Code

1. Copy the sample code below into a file named kill_drop_user.sql.
2. Open SQL*Plus and connect as user SYS to your database

SQL> CONNECT sys/change_on_install@orcl AS SYSDBA

3. Create a user called TEST with password TEST

SQL> GRANT connect, resource TO test IDENTIFIED BY test;

4. Create the procedure kill_drop_user

SQL> @”C:\scripts\kill_drop_user.sql”

5. Open three (3) SQL*Plus sessions and connect as user TEST.
6. Execute the PL/SQL script

SQL> SET serveroutput ON size 1000000
SQL> SET timing ON
SQL> EXEC kill_drop_user(‘TEST’);

The above script may be a good help for you.

Partho Konar

So these are the steps i followed.

1.  Create A Backup Control File Script.

First you need to obtain a script that will create a copy of the existing control file.

connect with sysdba .. conn /as sysdba then issue the command

ALTER DATABASE BACKUP CONTROLFILE TO TRACE ;

This creates a file in the trace file directory. The file usually has the extension ‘.trc’ and will be located either in the directory defined by the parameter ‘user_dump_dest’, or if this parameter is undefined it will be in $ORACLE_HOME/rdbms/log. Edit this file with your favourite editor and remove the crud. Then rename it as “ctrl<NEW_SID>.sql,” where <NEW_SID> will be the ORACLE_SID of the copied database.

2.Modify The Script Created In The Previous Step.

The CREATE CONTROLFILE command in the script ctrl<NEW_SID>.sql contains SQL, which might look something like this:

CREATE CONTROLFILE SET DATABASE “LDMPRD” RESETLOGS ARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 32
MAXINSTANCES 16
MAXLOGHISTORY 1815
LOGFILE
GROUP 1 ‘E:\ORACLE\ORADATA\LDMPRD\REDO03.LOG’  SIZE 500M,
GROUP 2 ‘E:\ORACLE\ORADATA\LDMPRD\REDO02.LOG’  SIZE 500M,
GROUP 3 ‘E:\ORACLE\ORADATA\LDMPRD\REDO01.LOG’  SIZE 500M
DATAFILE
‘D:\ORACLE\ORADATA\LDMPRD\SYSTEM01.DBF’,
‘D:\ORACLE\ORADATA\LDMPRD\ELSERV1.DBF’,
‘D:\ORACLE\ORADATA\LDMPRD\TEMP01.DBF’,
‘D:\ORACLE\ORADATA\LDMPRD\TOOLS01.DBF’,
‘D:\ORACLE\ORADATA\LDMPRD\INDX01.DBF’,
‘D:\ORACLE\ORADATA\LDMPRD\DR01.DBF’,
‘D:\ORACLE\ORADATA\LDMPRD\ELESIVER01.DBF’,
‘D:\ORACLE\ORADATA\LDMPRD\TEMP02.DBF’
CHARACTER SET WE8ISO8859P1
;

Where the string LDMPRD is the Oracle SID of the original database. This should be changed to LDMDEV. As the new database i want to create is the clone of LDMPRD. Remember to ser the keyword “SET” not reuse. We have to take only the script something mentioned above. as there are other things mentioned in the trace file.

it should look like this :- and named something like ctrl_LDMDEV.sql.

CREATE CONTROLFILE SET DATABASE “LDMDEV” RESETLOGS ARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 32
MAXINSTANCES 16
MAXLOGHISTORY 1815
LOGFILE
GROUP 1 ‘E:\ORACLE\ORADATA\LDMDEV\REDO03.LOG’  SIZE 500M,
GROUP 2 ‘E:\ORACLE\ORADATA\LDMDEV\REDO02.LOG’  SIZE 500M,
GROUP 3 ‘E:\ORACLE\ORADATA\LDMDEV\REDO01.LOG’  SIZE 500M
DATAFILE
‘D:\ORACLE\ORADATA\LDMDEV\SYSTEM01.DBF’,
‘D:\ORACLE\ORADATA\LDMDEV\ELSERV1.DBF’,
‘D:\ORACLE\ORADATA\LDMDEV\TEMP01.DBF’,
‘D:\ORACLE\ORADATA\LDMDEV\TOOLS01.DBF’,
‘D:\ORACLE\ORADATA\LDMDEV\INDX01.DBF’,
‘D:\ORACLE\ORADATA\LDMDEV\DR01.DBF’,
‘D:\ORACLE\ORADATA\LDMDEV\ELESIVER01.DBF’,
‘D:\ORACLE\ORADATA\LDMDEV\TEMP02.DBF’
CHARACTER SET WE8ISO8859P1
/

3. Copy The Existing Database To The New Location.

This will be a cold copy. So obviously you should make sure that the database is shutdown and all services are stopped before attempting to copy the database.

If the copy is on the same host, you can use the DOS copy command (once the instance is shutdown). Or you can just copy and paste via mouse also.

On the target host you need to copy all parameter files and all files mentioned above to their new location. Make sure you preserve ownership and permissions.

4.Set Up Parameter Files For The New Database

There may be several parameters that need to be edited in new_sid here it is LDMDEV In particular you will need to edit the control_files parameter so that it points to the name and location that you want to use for the new control files. You will also have to change the DB_NAME parameter in init<NEW_SID>.ora. Change it to the newname for your database. Usually this corresponds the LDMDEV. As well as i modified the db_unique_name also. Any ‘ifile’ parameters will need to be edited to point to the new name of the include file in the new location. We have to crease other dump directoried so that it point to new oracle_sid.

5  Create The Control File For The New Database.

Now edit the file like ctrl_LDMDEV.sql and strip out everything up to and including the STARTUP NOMOUNT command. Remove the ALTER DATABASE OPEN command and everything after it. This leaves a command which just creates the controlfile.

6  Create The Services For NEW_SID i.e LDMDEV

Create the services “OracleService<Sid>” and the “OracleStart<Sid>” for “NEW_SID” with the following command:

oradim -new -sid LDMDEV -intpwd <password> -startmode auto -pfile <path_name>

7 Run ‘CREATE CONTROLFILE’ For <NEW_SID> i.e LDMDEV

Make sure that your current directory is the one that contains ctrl<NEW_SID>.sql
ctrl_LDMDEV.sql. or you can specify the full pathe also.

Set your ORACLE_SID to <NEW_SID>

Startup SVRMGRL and enter the following:

CONNECT INTERNAL
STARTUP NOMOUNT PFILE=<full path>\init<NEW_SID>.ora
@ctrl_LDMDEV.sql
ALTER DATABASE OPEN RESETLOGS;
create spfile from pfile;

(note. if we create the oracle service then it will say that the database is already running while doing the step :- STARTUP NOMOUNT PFILE=<full path>\init<NEW_SID>.ora.

8. Then we need to create appropriate listener.ora and tnsnames.ora file so the the client users can connect the the database.

May be it will help you to clone a database in windows environment.

Partho Konar.

now in the unix prompt if we do
ls -ltr
we will get that file (emp.lst) in the current working directory.

That’s it..

=====================
DB_BLOCK_BUFFERS
SHARED_POOL_SIZE
SORT_AREA_SIZE
DBWR_IO_SLAVES
ROLLBACK_SEGMENTS
SORT_AREA_RETAINED_SIZE
DB_BLOCK_LRU_EXTENDED_STATISTICS
SHARED_POOL_RESERVED_SIZE

Latches are simple, low-level serialization mechanisms to protect shared data structures in the system global area (SGA). For example, latches protect the list of users currently accessing the database and protect the data structures describing the blocks in the buffer cache. A server or background process acquires a latch for a very short time while manipulating or looking at one of these structures. The implementation of latches is operating system dependent, particularly in regard to whether and how long a process will wait for a latch.

A latch is a type of a lock that can be very quickly acquired and freed.
Latches are typically used to prevent more than one process from
executing the same piece of code at a given time. Associated with each
latch is a cleanup procedure that will be called if a process dies while
holding the latch. Latches have an associated level that is used to
prevent deadlocks. Once a process acquires a latch at a certain level it
cannot subsequently acquire a latch at a level that is equal to or less
than that level (unless it acquires it nowait).

Latches vs Enqueues

Enqueues are another type of locking mechanism used in Oracle.
An enqueue is a more sophisticated mechanism which permits several concurrent
processes to have varying degree of sharing of “known” resources. Any object
which can be concurrently used, can be protected with enqueues. A good example
is of locks on tables. We allow varying levels of sharing on tables e.g.
two processes can lock a table in share mode or in share update mode etc.
One difference is that the enqueue is obtained using an OS specific
locking mechanism. An enqueue allows the user to store a value in the lock,
i.e the mode in which we are requesting it. The OS lock manager keeps track
of the resources locked. If a process cannot be granted the lock because it
is incompatible with the mode requested and the lock is requested with wait,
the OS puts the requesting process on a wait queue which is serviced in FIFO.
Another difference between latches and enqueues is that
in latches there is no ordered queue of waiters like in enqueues. Latch
waiters may either use timers to wakeup and retry or spin (only in
multiprocessors). Since all waiters are concurrently retrying (depending on
the scheduler), anyone might get the latch and conceivably the first one to
try might be the last one to get.

How to identify contention for internal latches?

Relevant data dictionary views to query
———————————————

V$LATCH
V$LATCHHOLDER
V$LATCHNAME

Each row in the V$LATCH table contains statistics for a different type
of latch. The columns of the table reflect activity for different types
of latch requests. The distinction between these types of requests is
whether the requesting process continues to request a latch if it
is unavailable:

willing-to-wait If the latch requested with a willing-to-wait
request is not available, the requesting process
waits a short time and requests the latch again.
The process continues waiting and requesting until
the latch is available.

no wait If the latch requested with an immediate request is
not available, the requesting process does not
wait, but continues processing.

V$LATCHNAME key information:
—————————————

GETS Number of successful willing-to-wait requests for
a latch.

MISSES Number of times an initial willing-to-wait request
was unsuccessful.

SLEEPS Number of times a process waited a requested a latch
after an initial wiling-to-wait request.

IMMEDIATE_GETS Number of successful immediate requests for each latch.

IMMEDIATE_MISSES Number of unsuccessful immediate requests for each latch.

Calculating latch hit ratio
—————————-

To get the Hit ratio for latches apply the following formula:

“willing-to-wait” Hit Ratio=(GETS-MISSES)/GETS
“no wait” Hit Ratio=(IMMEDIATE_GETS-IMMEDIATE_MISSES)/IMMEDIATE_GETS

This number should be close to 1. If not, tune according to the latch name

Some Useful SQL scripts to get latch information

/*
** Display System-wide latch statistics.
*/
column name format A32 truncate heading “LATCH NAME”
column pid heading “HOLDER PID”
select c.name,a.addr,a.gets,a.misses,a.sleeps,
a.immediate_gets,a.immediate_misses,b.pid
from v$latch a, v$latchholder b, v$latchname c
where a.addr = b.laddr(+)
and a.latch# = c.latch#
order by a.latch#;

/*
** Given a latch address, find out the latch name.
*/
column name format a64 heading ‘Name’
select a.name from v$latchname a, v$latch b
where b.addr = ‘&addr’
and b.latch#=a.latch#;

/*
** Display latch statistics by latch name.
*/
column name format a32 heading ‘LATCH NAME’
column pid heading ‘HOLDER PID’
select c.name,a.addr,a.gets,a.misses,a.sleeps,
a.immediate_gets,a.immediate_misses,b.pid
from v$latch a, v$latchholder b, v$latchname c
where a.addr = b.laddr(+) and a.latch# = c.latch#
and c.name like ‘&latch_name%’ order by a.latch#;

Some important latches are :-

Cache buffers chains latch

Cache buffers LRU chain latch

Redo allocation latch

Redo copy latch

Library cache latch

Library cache pin latch

Shared pool latch

Row cache objects latch

A transaction that has made only a few changes but has been idle for
a long time could cause a rollback segment to grow and finally cause an

ORA-1650 “unable to extend rollback segment %s by %s in tablespace %s”

OR

ORA-1562 “failed to extend rollback segment number %s”

This can cause for instance stuck backup jobs. In such cases it is
necessary to find the session that holds the blocking transaction.

Query to find blocking transaction
———————————-

In order to find the blocking session perform the following query from sqlplus:
(connect as SYS or AS SYSDBA):

SELECT s.sid, s.serial#, t.start_time, t.xidusn,s.username
FROM V$session s, V$transaction t, V$rollstat r
WHERE s.saddr=t.ses_addr
AND t.xidusn=r.usn
AND ((r.curext=t.start_uext-1) OR
((r.curext=r.extents-1) AND t.start_uext=0));

Example output:

SID SERIAL# START_TIME XIDUSN USERNAME
— ——- ————— —— ———-
8 13 8/22/2000 14:15:10 2 SCOTT

Check if the transaction can be ended or whether the transaction needs
to be killed and take the necessary action.

This feature is available in Oracle 9 and Oracle 10. To remove a parameter from spfile and
reset it to default value run the following command:

alter system reset “log_archive_start” scope=spfile sid=’*';

Take note that you must supply the SID= option to the ALTER SYSTEM command.

And if it is a pfile we just need to remove that line.