Disclaimer

Monday 4 November 2024

killing session in Oracle

 

Killing session :- INACTIVE and MACHINE 

set lines 300 pages 300 ;
col module for a40 ;
col machine for a10 ;

select sid , machine ,SQL_ID, module ,username , to_char(logon_time,'DD-MON-YYYY HH24:mi:ss') , last_call_et/60 from v$session where username is not null and status='INACTIVE' and machine='PRDBIDB' order by machine, logon_time;

spool kolap.sql
select '!kill -9 '||p.spid||chr(10)||
'alter system kill session '''||s.sid||','||s.serial#||''';'
  from v$session s, v$process p
  where s.paddr=p.addr
and s.username is not null 
and s.status='INACTIVE' and s.machine='PRDBIDB' and  s.last_call_et/60 > 10;

spool off ;
@kolap.sql



Killing session: INACTIVE and MACHINE NOT LIKE

SQL> select 'alter system kill session '''|| sid || ','|| serial# || '''  immediate ;'
from v$session
where username is not null
and status='INACTIVE'
and logon_time < trunc(sysdate)
and logon_time > trunc(sysdate-1)
and last_call_et/60 > 60
and MACHINE not like 'siebmtsh@PRDSAOM%'
order by machine, logon_time;


Kill Session: SID
set pages 300 lines 300 ;
select '!kill -9 '||p.spid||chr(10)||
'alter system kill session '''||s.sid||','||s.serial#||''';'
  from v$session s, v$process p
  where  s.username is not null and s.username <> 'SYS'
and s.sid=&sid 
  and s.paddr=p.addr
 ;


Kill Session: SNIPED
SQL> 
select '!kill -9 '||p.spid||chr(10)||
'alter system kill session '||''''||s.sid||','||to_char(s.serial#)||''''||';'
from v$session s,v$process p
where s.username is not null
and  s.status = 'SNIPED'
and s.paddr=p.addr;


Kill Session: SQL ID

set serveroutput off ;
set heading off ;
set pages 0 ;
spool ksqlid.sql
select distinct '!kill -9 '||p.spid||chr(10)||
'alter system kill session '''||s.sid||','||s.serial#||''' immediate;'
from v$session_wait w,v$session s,v$sql q,v$process p
where s.sql_id='&SQL_ID'
and w.sid=s.sid
and p.addr=s.paddr
and s.SQL_HASH_VALUE=q.HASH_VALUE
and s.username is not null;
spool off ;


Kill Session: with Time

select 'alter system kill session '''||s.sid||','||s.serial#||''' immediate ;'
  from v$session s
  where s.username like upper('%&USERNAME%')
 and   s.LAST_CALL_ET/60 > '&time_in_min'
 and s.username is not null and s.username <> 'SYS'
and event='&event'
   ;



spool killt.sql
select 'alter system kill session '''||s.sid||','||s.serial#||''' immediate ;'
  from v$session s
  where username is not null and (program  like '%Toad%' or module like '%SQL*Plus%' )
 and   s.LAST_CALL_ET/60 > '&time_in_min'
and Status='INACTIVE';
spool off ;

@killt.sql




Kill Session: Long Running

set serveroutput off ;
 set heading off ;
 set pages 0 ;
 spool klong.sql
 select distinct '!kill -9 '||p.spid||chr(10)||
 'alter system kill session '''||s.sid||','||s.serial#||''';'
 from v$session s,v$process p
 where p.addr=s.paddr
 and s.sid in (select l.sid
from gv$session_longops l, gv$session s
where
s.sid=l.sid
and s.serial#=l.serial#
and totalwork <> SOFAR)
;
 spool off ;



Kill Session: Event

spool kill_n.log
select 'alter system kill session '''||s.sid||','||s.serial#||'''   immediate ;'
from v$session s
where 
s.event='library cache lock' ;

spool off ;
@kill_n.log


Kill Session :-  Blocking 

set pages 300 lines 300 ;
spool kb.sql
select '!kill -9 '||p.spid||chr(10)||
'alter system kill session '''||s.sid||','||s.serial#||'''  immediate ;'
  from v$session s, v$process p
  where  s.username is not null and s.username <> 'SYS'
and s.sid in ( select distinct  blocking_session from v$session
  and s.paddr=p.addr
 ;
spool off ;


Kill Session: Event

set lines 300 pages 0 
set serveroutput off ;
set heading off ;
spool ke.sql
select distinct '!kill -9 '||p.spid||chr(10)||
'alter system kill session '''||s.sid||','||s.serial#||''' immediate ;'
from v$session_wait w,v$session s,v$sql q,v$process p
where w.event like '%&event%'
and w.sid=s.sid
and p.addr=s.paddr
and s.SQL_HASH_VALUE=q.HASH_VALUE
and s.status='ACTIVE'
and last_call_et/60 > &time
and s.username is not null
and  s.type<>'BACKGROUND';
spool off ;



set pages 3000 lines 300 ;
set heading off ;
set feedback off ;
set serveroutput off ;

spool kill_inct.txt;
select '!kill -9 '||p.spid||chr(10)||
'alter system kill session '''||s.sid||','||s.serial#||''';'
  from v$session s, v$process p
  where s.status='INACTIVE'
    and s.username is not null and s.username <> 'SYS'
  and s.paddr=p.addr
 ;
spool off ;





Wait Events and queries to identify wait in Oracle database

 
Do You Have a Wait Problem?

It’s easy to find out the percentage of time a database has spent waiting for resources instead of actually executing. 


1) Issue the following query to find out the relative percentages of wait times and actual CPU processing in the database:

SQL> select metric_name, value
 from v$sysmetric
 where metric_name in ('Database CPU Time Ratio',
 'Database Wait Time Ratio') and
 intsize_csec =
 (select max(INTSIZE_CSEC) from V$SYSMETRIC);

METRIC_NAME                 VALUE
————————————------------ -----------
Database Wait Time Ratio   11.371689
Database CPU Time Ratio    87.831890

Note:- If the query shows a very high value for the Database Wait Time Ratio, or if the Database Wait Time Ratio is much greater than the Database CPU Time Ratio, the database is spending more time waiting than processing and you must dig deeper into the Oracle wait events to identify the specific wait events causing this.





2) Identifying SQL Statements with the Most Waits
----------------------------------------------------------------

Problem
You want to identify the SQL statements responsible for the most waits in your database.

Solution
Execute the following query to identify the SQL statements that are experiencing the most waits in your
database:

SQL> 
 select ash.user_id,
 u.username,
 s.sql_text,
 sum(ash.wait_time +
 ash.time_waited) ttl_wait_time
 from v$active_session_history ash,
 v$sqlarea s,
 dba_users u
 where ash.sample_time between sysdate - 60/2880 and sysdate
 and ash.sql_id = s.sql_id
 and ash.user_id = u.user_id
 group by ash.user_id,s.sql_text, u.username
 order by ttl_wait_time
/


The preceding query ranks queries that ran during the past 30 minutes, according to the total time waited by each query.


SQL> select event, count(*) from v$session_wait group by event;

SQL> select event, state, seconds_in_wait siw from v$session_wait where sid = 81;

EVENT                                    STATE        SIW
---------------------------------------- ----------- ------
enq: TX - row lock contention            WAITING      976






3) Examining Wait Events by Class
---------------------------------------

SQL> 
 
 select wait_class, name
 from v$event_name
 where name LIKE 'enq%'
 and wait_class <> 'Other'
 order by wait_class
 /


WAIT_CLASS              NAME
-------------------- --------------------------
Administrative       enq: TW - contention
Concurrency          enq: TX - index contention





4) To view the current waits grouped into various wait classes, issue the following query:


SQL> 

  select wait_class, sum(time_waited), sum(time_waited)/sum(total_waits)
  sum_waits
  from v$system_wait_class
  group by wait_class
  order by 3 desc;



WAIT_CLASS       SUM(TIME_WAITED)              SUM_WAITS
---------------- ---------- ----------------- -----------------
Idle             249659211                     347.489249
Commit           1318006                       236.795904
Concurrency      16126                         4.818046
User I/O         135279                        2.228869
Application      912                           .0928055
Network          139                           .0011209




select a.event, a.total_waits, a.time_waited, a.average_wait
from v$system_event a, v$event_name b, v$system_wait_class c
where a.event_id=b.event_id
and b.wait_class#=c.wait_class#
and c.wait_class in ('Application','Concurrency')
order by average_wait desc;



select a.sid, a.event, a.total_waits, a.time_waited, a.average_wait
from v$session_event a, v$session b
where time_waited > 0
and a.sid=b.sid
and b.username is not NULL
and a.event='enq: TX - row lock contention';


SID          EVENT                        TOTAL_WAITS  time_waited average_wait
---------- ------------------------------ ------------ ----------- ------------
68           enq: TX - row lock contention 24           8018        298



The output shows that the session with the SID 68 is waiting for a row lock that’s held by another transaction.



5. Minimizing read by other session Wait Events
--------------------------------------------------------
Problem
Your AWR report shows that the read by other session wait event is responsible for the highest number of waits. 
You’d like to reduce the high read by other session waits.

Solution
The main reason you’ll see the read by other session wait event is that multiple sessions are seeking to read the same data blocks, whether they are table or index blocks, and are forced to wait behind the session that’s currently reading those blocks. 

You can find the data blocks a session is waiting for by executing the following command:

SQL> 

select p1 "file#", p2 "block#", p3 "class#" from v$session_wait where event = 'read by other session';

You can then take the block# and use it in the following query, to identify the exact segments (table or index) that are causing the read by other session waits.

SQL> 

select relative_fno, owner, segment_name, segment_type
from dba_extents
where file_id = &file
and &block between block_id
and block_id + blocks - 1;





6. Finding Out Who’s Holding a Blocking Lock
------------------------------------------------------

In order to find out whether a session is being blocked by the locks being applied by another session, you can execute the following query:

SQL> 

select s1.username || '@' || s1.machine
 || ' ( SID=' || s1.sid || ' ) is blocking '
 || s2.username || '@' || s2.machine || ' ( SID=' || s2.sid || ' ) ' AS blocking_status
 from v$lock l1, v$session s1, v$lock l2, v$session s2
 where s1.sid=l1.sid and s2.sid=l2.sid
 and l1.BLOCK=1 and l2.request > 0
 and l1.id1 = l2.id1
 and l2.id2 = l2.id2 ;


BLOCKING_STATUS
--------------------------------------------------------------------
HR@MIRO\MIROPC61 ( SID=68 ) is blocking SH@MIRO\MIROPC61 ( SID=81 )



SQL> select sid,type,lmode,request,ctime,block from v$lock;
SID   TY      LMODE      REQUEST     CTIME      BLOCK
---- -------- ----------- ----------- -------- -------
127   MR        4            0       102870      0
81    TX        0            6       778         0
191   AE        4            0       758         0
205   AE        4            0       579         0
140   AE        4            0       11655       0
68    TM        3            0       826         0
68    TX        6            0       826         1


The key column to watch is the BLOCK column—the blocking session will have the value 1 for this column. 

In our example, session 68 is the blocking session, because it shows the value 1 under the BLOCK column. 

Thus, the V$LOCK view confirms our initial finding in the “Solution” section of this recipe. 

The blocking session, with a SID of 68, also shows a lock mode 6 under the LMODE column, indicating that it’s holding this lock in the exclusive mode—this is the reason session 81 is “hanging,” unable to perform its update operation. 

The blocked session, of course, is the victim—so it shows a value of 0 in the BLOCK column. 

It also shows a value of 6 under the REQUEST column, because it’s requesting a lock in the exclusive mode to perform its update of the column. The blocking session, in turn, will show a value of 0
for the REQUEST column, because it isn’t requesting any locks—it’s already holding it.
If you want to find out the wait class and for how long a blocking session has been blocking others,
you can do so by querying the V$SESSION view, as shown here:



SQL> 
select blocking_session, sid, wait_class,
seconds_in_wait
from v$session
where blocking_session is not NULL
order by blocking_session;


BLOCKING_SESSION SID WAIT_CLASS           SECONDS_IN_WAIT
----------------- -------- ------------- ----------------
68                81 Application          7069


The query shows that the session with SID=68 is blocking the session with SID=81, and the block started 7,069 seconds ago.


SQL> alter system kill session '68, 1234';



5-17. Identifying Recently Locked Sessions
--------------------------------------------------

All locks held in the database during the previous five minutes.


SQL> 

select to_char(h.sample_time, 'HH24:MI:SS') TIME,h.session_id,
decode(h.session_state, 'WAITING' ,h.event, h.session_state) STATE,
h.sql_id, h.blocking_session BLOCKER
from v$active_session_history h, dba_users u
where u.user_id = h.user_id
and h.sample_time > SYSTIMESTAMP-(2/1440);




7. To find the most important wait events in the last 15 minutes, issue the following query:
-----------------------------------------------------------------------------------

SQL> 
select event,
sum(wait_time +
time_waited) total_wait_time
from v$active_session_history
where sample_time between
sysdate – 30/2880 and sysdate
group by event
order by total_wait_time desc;



8. To find out which of your users experienced the most waits in the past 15 minutes, issue the following query:

SQL> 
select s.sid, s.username,
sum(a.wait_time +
a.time_waited) total_wait_time
from v$active_session_history a,
v$session s
where a.sample_time between sysdate – 30/2880 and sysdate
and a.session_id=s.sid
group by s.sid, s.username
order by total_wait_time desc;


9. Execute the following query to find out the objects with the highest waits.
---------------------------------------------------------------------

SQL>select a.current_obj#, o.object_name, o.object_type, a.event,
sum(a.wait_time +
a.time_waited) total_wait_time
from v$active_session_history a,
dba_objects d
where a.sample_time between sysdate – 30/2880 and sysdate
and a.current_obj# = d.object_id
group by a.current_obj#, d.object_name, d.object_type, a.event
order by total_wait_time;



10. You can identify the SQL statements that have been waiting the most during the last 15 minutes with this query.
---------------------------------------------------------------------

SQL> 
select a.user_id,u.username,s.sql_text,
sum(a.wait_time + a.time_waited) total_wait_time
from v$active_session_history a,
v$sqlarea s,
dba_users u
where a.sample_time between sysdate – 30/2880 and sysdate
and a.sql_id = s.sql_id
and a.user_id = u.user_id
group by a.user_id,s.sql_text, u.username;



11. Minimizing Latch Contention
----------------------------------------
SQL> 
select event, sum(P3), sum(seconds_in_wait) seconds_in_wait
from v$session_wait
where event like 'latch%'
group by event;

The previous query shows the latches that are currently being waited for by this session. 

To find out the amount of time the entire instance has waited for various latches, execute the following SQL statement.

SQL> 
select wait_class, event, time_waited / 100 time_secs
from v$system_event e
where e.wait_class <> 'Idle' AND time_waited > 0
union
select 'Time Model', stat_name NAME,
round ((value / 1000000), 2) time_secs
from v$sys_time_model
where stat_name not in ('background elapsed time', 'background cpu time')
order by 3 desc;


WAIT_CLASS                   EVENT                  TIME_SECS
-------------------- ---------------------------- -----------------
Concurrency          library cache pin                 622.24
Concurrency          latch: library cache              428.23
Concurrency          latch: library cache lock         93.24
Concurrency          library cache lock                24.20
Concurrency          latch: library cache pin          60.28



Contention due to the library cache latches as well as shared pool latches is usually due to applications not using bind variables. 

If your application can’t be recoded to incorporate bind variables,
all’s not lost. You can set the CURSOR_SHARING parameter to force Oracle to use bind variables, even if your application hasn’t specified them in the code. When you set the CURSOR_SHARING parameter to FORCE, Oracle converts all literals to bind variables.




12. You can also directly query data dictionary views such as V$SQL to determine which SQL statements are using excessive I/O—for example:
----------------------------------------------------
SELECT *
FROM
(SELECT
parsing_schema_name
,direct_writes
,SUBSTR(sql_text,1,75)
,disk_reads
FROM v$sql
ORDER BY disk_reads DESC)
WHERE rownum < 20;



13. To determine which sessions are currently waiting for I/O resources, query V$SESSION:
-----------------------------------------------------------------------------------
SELECT
username
,program
,machine
,sql_id
FROM v$session
WHERE event LIKE 'db file%read';



14. To view objects that are waiting for I/O resources, run a query such as this:
---------------------------------------------------------------------------------
SELECT
object_name
,object_type
,owner
FROM v$session a
,dba_objects b
WHERE a.event LIKE 'db file%read'
AND b.data_object_id = a.row_wait_obj#;















How to check query plan changed or not from AWR

 
declare
  ar_hint_table    sys.dbms_debug_vc2coll;
  ar_profile_hints sys.sqlprof_attr := sys.sqlprof_attr();
  cl_sql_text      clob;
  i                pls_integer;
begin
  with a as (
  select
           rownum as r_no
         , a.*
  from
           table( dbms_xplan.display_awr('cbna05g7zqazc', 3794164291, null, 'OUTLINE' )
           ) a
  ),
  b as (
  select
           min(r_no) as start_r_no
  from
           a
  where
           a.plan_table_output = 'Outline Data'
  ),
  c as (
  select
           min(r_no) as end_r_no
  from
           a
         , b
  where
           a.r_no > b.start_r_no
  and      a.plan_table_output = '  */'
  ),
  d as (
  select
           instr(a.plan_table_output, 'BEGIN_OUTLINE_DATA') as start_col
  from
           a
         , b
  where
           r_no = b.start_r_no + 4
  )
  select
           substr(a.plan_table_output, d.start_col) as outline_hints
  bulk collect
  into
           ar_hint_table
  from
           a
         , b
         , c
         , d
  where
           a.r_no >= b.start_r_no + 4
  and      a.r_no <= c.end_r_no - 1
  order by
           a.r_no;

  select
           sql_text
  into
           cl_sql_text
  from
           sys.dba_hist_sqltext
  where
           sql_id = 'cbna05g7zqazc';

  -- this is only required
  -- to concatenate hints
  -- splitted across several lines
  -- and could be done in SQL, too
  i := ar_hint_table.first;
  while i is not null
  loop
    if ar_hint_table.exists(i + 1) then
      if substr(ar_hint_table(i + 1), 1, 1) = ' ' then
        ar_hint_table(i) := ar_hint_table(i) || trim(ar_hint_table(i + 1));
        ar_hint_table.delete(i + 1);
      end if;
    end if;
    i := ar_hint_table.next(i);
  end loop;

  i := ar_hint_table.first;
  while i is not null
  loop
    ar_profile_hints.extend;
    ar_profile_hints(ar_profile_hints.count) := ar_hint_table(i);
    i := ar_hint_table.next(i);
  end loop;

  dbms_sqltune.import_sql_profile(
    sql_text    => cl_sql_text
  , profile     => ar_profile_hints
  , name        => 'SQLP_cbna05g7zqazc_3794164291'
  -- use force_match => true
  -- to use CURSOR_SHARING=SIMILAR
  -- behaviour, i.e. match even with
  -- differing literals
  , force_match => false
  );
end;
/







Sunday 3 November 2024

SET COLSEP ' | ' - column separator in Query

 


SQL> column service_name format a20
SQL> column network_name format a20
SQL> set colsep ' | '
SQL> select service_id, name as service_name, network_name,
  2    (select count(*) from v$active_services where name = A.nameas active
  3  from v$services A order by name;
 
SERVICE_ID | SERVICE_NAME     | NETWORK_NAME     |     ACTIVE
---------- | ---------------- | ---------------- | ----------
         4 | plt              | plt              |          1
         5 | pltp             | pltp             |          1
         3 | pltXDB           | pltXDB           |          1
         1 | SYS$BACKGROUND   |                  |          1
         2 | SYS$USERS        |                  |          1

Oracle RAC Clusterware Startup Sequence in detail

 
Once the Operating system starts and finish the boot scrap process it reads /etc/init.d file via the initialization daemon called init or init.d. 

The init tab file is the one it triggers oracle high availability service daemon.

1. When a node of an Oracle Clusterware cluster starts, OHASD is started by platform-specific means like init.d in Linux. 
   OHASD is the root for bringing up Oracle Clusterware. 
   OHASD has access to the OLR (Oracle Local Registry) stored on the local file system. 
   OLR provides needed data to complete OHASD initialization.

2. OHASD brings up GPNPD and CSSD ( Cluster synchronization Service Daemon ). 
   CSSD has access to the GPNP Profile stored on the local file system. 
   This profile contains the following vital bootstrap data:
a. ASM Diskgroup Discovery String
b. ASM SPFILE location (Diskgroup name)
c. Name of the ASM Diskgroup containing the Voting Files


3. The Voting Files locations on ASM Disks are accessed by CSSD with well-known pointers in the ASM Disk headers and CSSD is able to complete initialization and start or join an existing cluster.

4. OHASD starts an ASM instance and ASM can now operate with CSSD initialized and operating. 
   The ASM instance uses special code to locate the contents of the ASM SPFILE, assuming it is stored in a Diskgroup.

5. With an ASM instance operating and its Diskgroups mounted, access to Clusterware’s OCR is available to CRSD.

6. OHASD starts CRSD with access to the OCR in an ASM Diskgroup.

7. Clusterware completes initialization and brings up other services under its control.






==================================================

  1. System Boot and Init Process

    • When the operating system completes the boot process, it reads the /etc/init.d scripts through the init or init.d daemon. These scripts manage service startups on Linux systems.
    • The inittab file configuration triggers the Oracle High Availability Services Daemon (OHASD). On Linux, this means that as part of the system startup, OHASD is one of the first Clusterware processes to start.
  2. OHASD Initialization and OLR Access

    • OHASD is the root daemon for initializing Oracle Clusterware. It has privileged access to the Oracle Local Registry (OLR) stored on each node’s local file system.
    • OLR contains vital configuration data specific to the node, including information needed for initial Clusterware setup and node-specific details. This data enables OHASD to complete its initialization.
  3. Starting GPNPD and CSSD Daemons

    • Once OHASD is operational, it starts the Grid Plug and Play Daemon (GPNPD) and Cluster Synchronization Services Daemon (CSSD).
    • CSSD has access to the GPNP Profile (also stored locally on each node), which includes essential bootstrap data such as:
      • ASM Diskgroup Discovery String: Information to discover ASM disks on startup.
      • ASM SPFILE Location: Specifies the diskgroup where the ASM SPFILE (Server Parameter File) is stored.
      • ASM Diskgroup Name for Voting Files: Identifies the ASM diskgroup that contains the Voting Disk(s), which are critical for cluster node coordination.
  4. CSSD and Voting Files

    • CSSD reads the GPNP Profile to locate the Voting Files stored in ASM disk headers. Voting Files are used for node membership and are crucial for cluster health monitoring.
    • With these pointers, CSSD completes its initialization and either starts a new cluster or joins an existing one.
  5. Starting ASM Instance and Diskgroup Mounting

    • With CSSD running, OHASD proceeds to start the ASM (Automatic Storage Management) instance.
    • ASM operates in coordination with CSSD to manage and access storage. It uses the SPFILE located in the specified diskgroup for initialization.
    • Once the ASM instance is active, it mounts the necessary ASM diskgroups, including the ones containing the Voting Files and OCR (Oracle Cluster Registry).
  6. CRSD Initialization and OCR Access

    • With ASM and its diskgroups mounted, access to the Oracle Cluster Registry (OCR) is now available. OCR, which is typically stored in an ASM diskgroup, contains cluster-wide configuration data necessary for CRSD operations.
    • OHASD starts the Cluster Ready Services Daemon (CRSD), which relies on OCR for retrieving information about cluster resources, dependencies, and node roles.
  7. Completion of Clusterware Initialization

    • After CRSD starts, Oracle Clusterware completes the remainder of its initialization. CRSD then begins managing high-availability resources, such as database instances, listeners, and other services under Oracle Clusterware control.

Key Points on OLR, Voting Files, and Cluster Components

  • OLR: Essential for node-specific configuration and available locally to OHASD. If OLR is lost or corrupted, OHASD may fail to start correctly on that node, and the node may need recovery or reconfiguration.

  • Voting Files: These are central to node membership and fencing decisions, helping to avoid split-brain scenarios. CSSD relies on the Voting Files for its initialization and operation, while CRSD uses OCR for managing cluster resources.

  • ASM Instance: Plays a dual role, storing both Voting Files and OCR if they’re ASM-managed. ASM mounts the required diskgroups to provide Clusterware components with access to these files.

  • Cluster Resource Management: CRSD uses OCR data to start and monitor all Oracle RAC resources, completing the initialization sequence and ensuring high availability.

In summary, each component in the Oracle Clusterware startup process depends on previous components, creating a cascading initialization. If any critical part (like OLR, Voting Files, or ASM diskgroups) is missing or corrupted, it can impact the whole startup sequence, potentially leading to node isolation or cluster inaccessibility until recovery steps are taken.



GPNP Profile Internals in Oracle RAC

 
GPnP ( Grid Plug and Play ) profile in Oracle RAC

The GPnP profile is a XML file located at location <GRID_HOME/gpnp/<hostname>/profiles/peer as profile.xml. 

Each node of the cluster maintains a copy of this profile locally and is maintained by GPnP daemon along with mdns daemon.

Now before understanding why Oracle came up with GPnP profile, we need to focus on what it contains.

GPnP defines a node’s meta data about network interfaces for public and private interconnect, the ASM server parameter file, and CSS voting disks. 

This profile is protected by a wallet against modification. 

If you have to manually modify the profile, it must first be unsigned with $GRID_HOME/bin/gpnptool, modified, and then signed again with the same utility, however there is a very slight chance you would ever be required to do so.

Now we’ll use the gpnptool with get option to dump this xml file into standard output. 

Below is the formatted output for the ease of readability.

<?xml version=”1.0″ encoding=”UTF-8″?>
<gpnp:GPnP-Profile Version=”1.0″ xmlns=”http://www.xyz/gpnp-profile&#8221;
xmlns:gpnp=”http://xyz/gpnp-profile&#8221;
xmlns:orcl=”http://xyz/gpnp-profile&#8221;
xmlns:xsi=”http://xyz/XMLSchema-instance&#8221;
xsi:schemaLocation=”http://xyz/gpnp-profile gpnp-profile.xsd”
ProfileSequence=”3″ ClusterUId=”002c207a71cvaljgkcea7bea5b3a49″
ClusterName=”Cluster01″ PALocation=””>
<gpnp:Network-Profile>
<gpnp:HostNetwork id=”gen” HostName=”*”>
<gpnp:Network id=”net1″ IP=”xxx.xx.x.x” Adapter=”bond0″ Use=”public”/>
<gpnp:Network id=”net2″ IP=”xxx.xxx.x.x” Adapter=”bond1″
Use=”cluster_interconnect”/>
</gpnp:HostNetwork>
</gpnp:Network-Profile>
<orcl:CSS-Profile id=”css” DiscoveryString=”+asm” LeaseDuration=”400″ />
<orcl:ASM-Profile id=”asm” DiscoveryString=””
SPFile=”+DATA/prod/asmparameterfile/registry.253.699915959″ />
<ds:Signature…>…</ds:Signature>
</gpnp:GPnP-Profile>


So from the above dump we can see that GPnP profile contains following information:-

1) Cluster Name
2) Network Profile
3) CSS-Profile tag
4) ASM-Profile tag

Now that we have understood the content of a GPnP profile, we need to understand how the Clusterware uses this information to start. 

From 11gr2 you have the option of storing the OCR and Voting disk on ASM, but clusterware needs OCR and Voting disk to start crsd & cssd and both these files are on ASM which itself is a resource for the node. so how does the clusterware starts, which files it accesses to get the information needed to start clusterware, to resolve this Oracle came up with two local operating system files OLR & GPnP.

When a node of an Oracle Clusterware cluster restarts, OHASD is started by platform-specific means.OHASD has access to the OLR (Oracle Local Registry) stored on the local file system. OLR provides needed data (Would explain in another post) to complete OHASD initialization

OHASD brings up GPnP Daemon and CSS Daemon. 

CSS Daemon has access to the GPNP Profile stored on the local file system.


The Voting Files locations on ASM Disks are accessed by CSSD with well-known pointers in the ASM Disk headers and CSSD is able to complete initialization and start or join an existing cluster.


OHASD starts an ASM instance and ASM can now operate with CSSD initialized and operating. 

The ASM instance uses special code to locate the contents of the ASM SPFILE, assuming it is stored in a Diskgroup.


With an ASM instance operating and its Diskgroups mounted, access to Clusterware’s OCR is available to CRSD.

OHASD starts CRSD with access to the OCR in an ASM Diskgroup.And thus Clusterware completes initialization and brings up other services under its control.

Thus with the use of GPnP profile several information stored in it along with the information in the OLR several tasks have been automated or eased for the administrators.





killing session in Oracle

  Killing session :- INACTIVE and MACHINE  set lines 300 pages 300 ; col module for a40 ; col machine for a10 ; select sid , machine ,SQL_ID...