Tuned-adm and Oracle

“Tuned” in RHEL7/OEL7 is tuning daemon for automatically tuning the system via the use of tuning profile. It can also be configured to react to changes to improve performance of the server and also to make system settings persistent.

“tuned-adm” is a command line tool that provides a number of different profiles to improve performance.

Below are the profiles provided and supported in RHEL 7 :-

  1. throughput-performance
  2. latency-performance
  3. network-latency
  4. network-throughput
  5. virtual-guest
  6. virtual-host

Apart from the provided profile, we can create custom profiles. All the profile are stored in /usr/lib/tuned/ in RHEL7.

The recommended profile for Oracle database workloads is “throughput-performance”.

In my virtualbox, by default “vitual-guest” was set as active profile

[root@racnode1 ~]# cd /usr/lib/tuned/
[root@racnode1 tuned]# tuned-adm active
Current active profile: virtual-guest

If tuned is not installed, install it using yum

#yum install tuned

Enabled tuned to ensure it is started upon boot time

# systemctl enable tuned.service

Start the tuned service

#systemctl start tuned.service

To check the status of tuned service

#systemctl status tuned.service

Now, create new “oracle” profile to be used

1. Create oracle directory –

[root@racnode1 ~]# mkdir /usr/lib/tuned/oracle

2. Create tuned.conf –

[root@racnode1 ~]# cd /usr/lib/tuned/oracle
[root@racnode1 oracle]# vi tuned.conf
[root@racnode1 oracle]# more tuned.conf
#
# tuned configuration
#
[main]
include=throughput-performance

[sysctl]
vm.swappiness = 1
vm.dirty_background_ratio = 3
vm.dirty_ratio = 80
vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 100
kernel.shmmax = 4398046511104
kernel.shmall = 1073741824
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 6815744
fs.aio-max-nr = 1048576
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
kernel.panic_on_oops = 1

[vm]
transparent_hugepages=never

[root@racnode1 oracle]#

3. Activate the newly added oracle profile –

[root@racnode1 oracle]# tuned-adm profile oracle
[root@racnode1 oracle]# sysctl -a | grep vm.swappiness
vm.swappiness = 1
[root@racnode1 oracle]# sysctl -a | grep vm.dirty_ratio
vm.dirty_ratio = 80
[root@racnode1 oracle]#

4. To check the profile list –

[root@racnode1 ~]# tuned-adm list

One of the benefits of tuned is the profiles can be applied dynamically.
To configure dynamic tuning behavior, edit the dynamic_tuning parameter in the /etc/tuned/tuned-main.conf file.

If we are using tuned profile (as shown above) which make system settings persistent, it is recommended to remove all the oracle related entries from /etc/sysctl.conf as the entries are susceptible of being overwrittern, replaced or removed all together.

Hope the article is helpful!!

Advertisements

12cR1 RAC Installation on OEL7

To build Oracle Clusterware Database at Home, I believe , RAC ATTACK is the best place to learn. Its is a free curriculum and platform for hands-on learning labs related to Oracle RAC. While reviewing the article, I thought to perform 12cR1 RAC installation on OEL 7.2.

Attached is the document :- 12c_RAC_on_OEL7

The attached article is inspired by

RAC ATTACK :- https://en.wikibooks.org/wiki/RAC_Attack_-_Oracle_Cluster_Database_at_Home/RAC_Attack_12c

Tim Hall’s article :- https://oracle-base.com/articles/12c/oracle-db-12cr1-rac-installation-on-oracle-linux-7-using-virtualbox 

Deploying Oracle RAC Database 12c on RHEL 7 – Best Practices :- https://www.redhat.com/en/resources/deploying-oracle-rac-database-12c-rhel-7-best-practices

Big Thank you to RAC Attack members!!!

I hope the document helps some of you. Please feel free to comment.

Its all about learning 🙂

Online Partition Move fails with ORA-00932 – 12.1.0.2

Oracle 12c introduced feature to move table partitions and sub-partitions as online operations.So, this blog is related to this feature and the issue I faced.

The database was upgraded from 11.2.0.4 to 12.1.0.2 and this issue is seen in upgraded databases only.

Lets start!!!

SQL> create table sales_part
    (product char(25),channel_id number,cust_id number,
    amount_sold number, time_id date)
    partition by range (time_id)
    (
    partition sale_jan values less than (to_date('01-02-2015','dd-mm-yyyy')),
    partition sale_feb values less than (to_date('01-03-2015','dd-mm-yyyy')),
    partition sale_mar values less than (to_date('01-04-2015','dd-mm-yyyy')),
    partition sale_apr values less than (to_date('01-05-2015','dd-mm-yyyy')),
    partition sale_may values less than (to_date('01-06-2015','dd-mm-yyyy')),
    partition sale_jun values less than (to_date('01-07-2015','dd-mm-yyyy')),
    partition sale_jul values less than (to_date('01-08-2015','dd-mm-yyyy')),
    partition sale_aug values less than (to_date('01-09-2015','dd-mm-yyyy')),
    partition sale_sep values less than (to_date('01-10-2015','dd-mm-yyyy')),
    partition sale_oct values less than (to_date('01-11-2015','dd-mm-yyyy')),
    partition sale_nov values less than (to_date('01-12-2015','dd-mm-yyyy')),
    partition sale_dec values less than (to_date('01-01-2016','dd-mm-yyyy'))
   ) 
   TABLESPACE USERS;

SQL> insert into sales_part
    select
    'Oracle Enterprise Edition' as product,
     mod(rownum,5) as channel_id,
     mod(rownum,1000) as cust_id ,
     5000 as amount_sold,
     to_date
     ('01.' || lpad(to_char(mod(rownum,6)+4),2,'0') || '.2015' ,'dd.mm.yyyy')
     as time_id
     from dual connect by level commit;

Commit complete.

SQL> create index idx_sale_local on sales_part (cust_id,time_id)local tablespace users;

Index created.

SQL> create index idx_sale_global on sales_part (channel_id)  tablespace users;

Index created.

SQL>                        
SQL> exec dbms_stats.gather_table_stats('ANAND','SALES_PART', cascade => true);

PL/SQL procedure successfully completed.

SQL>

Table and Index details

SQL>@partition_table 

TABLE_NAME      PARTITION_NAME            HIGH_VALUE                                                                            LAST_ANALYZED      TABLESPACE_NAM   NUM_ROWS
--------------- ------------------------- ------------------------------------------------------------------------------------- ------------------ -------------- ----------
SALES_PART      SALE_JAN                  TO_DATE(' 2015-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA      02-OCT-15          USERS                   0
SALES_PART      SALE_FEB                  TO_DATE(' 2015-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA      02-OCT-15          USERS                   0
SALES_PART      SALE_MAR                  TO_DATE(' 2015-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA      02-OCT-15          USERS                   0
SALES_PART      SALE_APR                  TO_DATE(' 2015-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA      02-OCT-15          USERS               33333
SALES_PART      SALE_MAY                  TO_DATE(' 2015-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA      02-OCT-15          USERS               33334
SALES_PART      SALE_JUN                  TO_DATE(' 2015-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA      02-OCT-15          USERS               33334
SALES_PART      SALE_JUL                  TO_DATE(' 2015-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA      02-OCT-15          USERS               33333
SALES_PART      SALE_AUG                  TO_DATE(' 2015-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA      02-OCT-15          USERS               33333
SALES_PART      SALE_SEP                  TO_DATE(' 2015-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA      02-OCT-15          USERS               33333
SALES_PART      SALE_OCT                  TO_DATE(' 2015-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA      02-OCT-15          USERS                   0
SALES_PART      SALE_NOV                  TO_DATE(' 2015-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA      02-OCT-15          USERS                   0
SALES_PART      SALE_DEC                  TO_DATE(' 2016-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA      02-OCT-15          USERS                   0

12 rows selected.

SQL> @index
Enter value for owner: ANAND
Enter value for table_name: SALES_PART

TABLE_OWNER     TABLE_NAME            INDEX_OWNER     INDEX_NAME            TABLESPACE_NAME   NUM_ROWS      CLUST STATUS                   INDEX_TYPE
--------------- --------------------- --------------- --------------------- --------------- ---------- ---------- ------------------------ ------------
ANAND           SALES_PART            ANAND           IDX_SALE_GLOBAL       USERS               200000       6084 VALID                    NORMAL
ANAND           SALES_PART            ANAND           IDX_SALE_LOCAL                            200000     199784 N/A                      NORMAL

SQL> @partition_index
Enter value for index_name: IDX_SALE_LOCAL
Enter value for owner: ANAND

Index                                                                                                                   Number
Name                  PARTITION_NA STATUS                   TABLESPACE_NAME INITIAL_EXTENT NEXT_EXTENT PCT_INCREASE    of Rows
--------------------- ------------ ------------------------ --------------- -------------- ----------- ------------ ----------
IDX_SALE_LOCAL        SALE_JAN     USABLE                   USERS                                                            0
                      SALE_FEB     USABLE                   USERS                                                            0
                      SALE_MAR     USABLE                   USERS                                                            0
                      SALE_APR     USABLE                   USERS                    65536     1048576                   33333
                      SALE_MAY     USABLE                   USERS                    65536     1048576                   33334
                      SALE_JUN     USABLE                   USERS                    65536     1048576                   33334
                      SALE_JUL     USABLE                   USERS                    65536     1048576                   33333
                      SALE_AUG     USABLE                   USERS                    65536     1048576                   33333
                      SALE_SEP     USABLE                   USERS                    65536     1048576                   33333
                      SALE_OCT     USABLE                   USERS                                                            0
                      SALE_NOV     USABLE                   USERS                                                            0
                      SALE_DEC     USABLE                   USERS                                                            0

Now I plan to move Partition SALE_JUN to tablespace DEMO.

SQL> alter table anand.sales_part move partition sale_jun online tablespace demo
  2  update indexes (
  3  anand.idx_sale_local (partition sale_jun tablespace demo)
  4  );
alter table anand.sales_part move partition sale_jun online tablespace demo
                  *
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-00932: inconsistent datatypes: expected NUMBER got BINARY

After searching for the issue in MOS and reviewing DOC Id 2028583.1, I applied patch 15894842 and 20123899

Oracle Database 12c                                                  12.1.0.2.0
There are 1 products installed in this Oracle Home.

List of Bugs fixed by Installed Patches:

Bug        Fixed by  Installed at                   Description
            Patch
---        --------  ------------                   -----------
20123899   20123899  Fri Oct 02 10:32:54 UTC 2015   INSERT IN TO STAT TABLE FAILS WITH ORA-932
                                                    INCONSISTENT DATATYPES
15894842   15894842  Fri Oct 02 10:31:52 UTC 2015   INSERT IN TO STAT TABLE FAILS WITH ORA-00932
                                                    INCONSISTENT DATATYPES

Even after applying the above patches, the online partition move failed with the same error. This time I traced the session –

SQL> alter session set events '932 trace name errorstack level 3';

Session altered.

SQL>alter table anand.sales_part move partition sale_jun online tablespace demo
    update indexes (
     anand.idx_sale_local (partition sale_jun tablespace demo)
     );
 alter table anand.sales_part move partition sale_jun online tablespace demo
                   *
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-00932: inconsistent datatypes: expected NUMBER got BINARY

The trace file showed

*** 2015-10-02 10:56:40.306
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=3, mask=0x0)
----- Error Stack Dump -----
ORA-00932: inconsistent datatypes: expected NUMBER got BINARY
----- Current SQL Statement for this session (sql_id=8qwf072kqbt3g) -----
insert into histgrm$ select :1, col#, row#, bucket, endpoint, intcol#, epvalue, ep_repeat_count, epvalue_raw, spare1, spare2 from histgrm$ where obj# = :2

----- Call Stack Trace -----

So the issue is related to HISTGRM$ table. After spending few minutes searching for issue in MOS, I found the below useful documents:-

Bug 20703000 : INSERT INTO STAT TABLE HISTGRM$ FAILS WITH ORA-00932: INCONSISTENT DATATYPES
Moving Table Partition With CLOB Creates ORA-604 , ORA-932 (Doc ID 2040742.1)

After applying the patch 20703000, online partition move worked fine and below is the changed sql on histgrm$

PARSING IN CURSOR #140348537646088 len=257 dep=1 uid=0 oct=2 lid=0 tim=41782225111 hv=216722248 ad='8635af20' sqlid='66x6dxn6fpuu8'
insert into histgrm$ (obj#, col#, row#, bucket, endpoint, intcol#, epvalue,  ep_repeat_count, epvalue_raw, spare1, spare2 ) 
select :1, col#, row#, bucket, endpoint, intcol#, epvalue, ep_repeat_count, epvalue_raw, spare1, spare2 from histgrm$ where obj# = :2
END OF STMT

Hope this helps!!

PDB Saved state – 12.1.0.2

Prior to 12.1.0.2 version, whenever container database was restarted,the pluggable databases within the container database remained in MOUNT state. Startup trigger were written to open the database in READ-WRITE/READ-ONLY mode.Starting from 12.1.0.2, this can be done with PDB save state feature

SQL> show pdbs

    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ----------------- ---------- ----------
	 2 PDB$SEED			     READ ONLY  NO
	 3 ALPDB			     READ WRITE NO

Lets create a new PDB

SQL> 
SQL> create pluggable database hydb admin user anand identified by anand123 role = (dba)
  2  file_name_convert =('/u01/app/oracle/oradata/orcl/pdbseed/','/u01/app/oracle/oradata/orcl/hydb/')
  3  storage (maxsize 500M);
create pluggable database hydb admin user anand identified by anand123 role = (dba)
*
ERROR at line 1:
ORA-65113: value of MAX_PDB_STORAGE property for the PDB is too low

SQL> create pluggable database hydb admin user anand identified by anand123 role = (dba)
    file_name_convert =('/u01/app/oracle/oradata/orcl/pdbseed/','/u01/app/oracle/oradata/orcl/hydb/')
    storage (maxsize 1G);
  2    3

Pluggable database created.  

Check status

SQL> @cdb_pdbs

    PDB_ID	 DBID PDB_NAME	     STATUS
---------- ---------- -------------- ----------
	 3 2221989451 ALPDB	     NORMAL
	 2  385653993 PDB$SEED	     NORMAL
	 4 4008421982 HYDB	     NEW

SQL> show pdbs

    CON_ID CON_NAME		  OPEN MODE  RESTRICTED
---------- -------------- ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 ALPDB			  READ WRITE NO
	 4 HYDB 			  MOUNTED
SQL>  

SQL> alter pluggable database hydb open;

Pluggable database altered.

SQL> show pdbs

    CON_ID CON_NAME	      OPEN MODE  RESTRICTED
---------- ------------   ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 ALPDB			  READ WRITE NO
	 4 HYDB 			  READ WRITE NO     
SQL> select a.name,b.state from v$pdbs a , dba_pdb_saved_states b
  2  where a.con_id = b.con_id;

no rows selected

DBA_PDB_SAVED_STATES can be used to check PDBs in saved state. We have none PDBs in saved state as per the above output.

SQL> alter pluggable database hydb save state;

Pluggable database altered.

SQL> select a.name,b.state from v$pdbs a , dba_pdb_saved_states b
  2  where a.con_id = b.con_id;

NAME				 STATE
------------------------------- --------------
HYDB				 OPEN

Now lets, restart the container

SQL> shu abort
ORACLE instance shut down.

SQL> SQL> 
SQL> startup
ORACLE instance started.

Total System Global Area  838860800 bytes
Fixed Size		    2929936 bytes
Variable Size		  562039536 bytes
Database Buffers	  268435456 bytes
Redo Buffers		    5455872 bytes
Database mounted.
Database opened.
SQL> show pdbs

    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ------------------ ---------- ----------
	 2 PDB$SEED			       READ ONLY  NO
	 3 ALPDB			       MOUNTED    
	 4 HYDB 			       READ WRITE NO
SQL> 

To discard the save state

SQL> alter pluggable database HYDB discard state;

Pluggable database altered.

SQL> select a.name,b.state from v$pdbs a , dba_pdb_saved_states b
  2  where a.con_id = b.con_id;

no rows selected

SQL> shu immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  838860800 bytes
Fixed Size		    2929936 bytes
Variable Size		  562039536 bytes
Database Buffers	  268435456 bytes
Redo Buffers		    5455872 bytes
Database mounted.
Database opened.
SQL> show pdbs

    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ----------------- ---------- ----------
	 2 PDB$SEED			       READ ONLY  NO
	 3 ALPDB			       MOUNTED    
	 4 HYDB 			       MOUNTED
SQL> 

latch: cache buffers chains and rollback

I had an interesting encounter with latch: cbc contention early this week. During my oncall I received page for Load of 206.81 exceeded threshold of 150. After I logged into server , the server load average was continously increasing and all the top PIDs were of oracle processes. After logging into database, I saw multiple sessions waiting on latch: cache buffer chains wait event

load average: 258.52, 244.27, 226.15

select username,sql_id,event,count(*) from v$session where event like 'latch%' group by username,sql_id,event order by 4;
 
USERNAME                  SQL_ID        EVENT                            COUNT(*)
------------------------- ------------- ------------------------------ ----------
USER_EAS4                5j9xrj07xqysz latch free                              1
USER_EAS7                4f6dfhuxbz18y latch free                              1
USER_EAS7                a1wwm6tpukyh8 latch free                              1
USER_EAS7                c1sa78t1rvxkq latch free                              1
USER_EAS7                gc4xfk544n98v latch free                              2
USER_EAS7                bmhmdqvt9c2qz latch free                              2
USER_EAS7                4ycfn45y3vj5p latch free                              8
USER_EAS7                4ycfn45y3vj5p latch: cache buffers chains            23
USER_EAS7                9cg18w6mfqphn latch: cache buffers chains            51
USER_EAS7                9cg18w6mfqphn latch free                            144

sql monitor report of one session for sqlid 9cg18w6mfqphn

Global Stats
=======================================================
| Elapsed |   Cpu   | Concurrency |  Other   | Buffer |
| Time(s) | Time(s) |  Waits(s)   | Waits(s) |  Gets  |
=======================================================
|    2243 |    2132 |        0.00 |      111 |   260M |
=======================================================
 
SQL Plan Monitoring Details (Plan Hash Value=2956480150)
=============================================================================================================================================================
| Id   |               Operation               |         Name         |  Rows   | Cost |   Time    | Start  | Execs |   Rows   | Activity | Activity Detail |
|      |                                       |                      | (Estim) |      | Active(s) | Active |       | (Actual) |   (%)    |   (# samples)   |
=============================================================================================================================================================
|    0 | SELECT STATEMENT                      |                      |         |      |           |        |     1 |          |          |                 |
|    1 |   FILTER                              |                      |         |      |           |        |     1 |          |          |                 |
|    2 |    PARTITION RANGE SINGLE             |                      |      18 |  133 |           |        |     1 |          |          |                 |
|    3 |     TABLE ACCESS BY LOCAL INDEX ROWID | MESSAGE_DEMO_CTC     |      18 |  133 |           |        |     1 |          |          |                 |
| -> 4 |      INDEX RANGE SCAN                 | MESSAGE_DEMO_CTC_ID6 |      18 |  133 |      2246 |     +1 |     1 |        0 |   100.00 | Cpu (2194)      |
=============================================================================================================================================================

AWR performance trend for the sqlid for past 5 days:-

@awr_sqlid_perf_trend 9cg18w6mfqphn 5 .25
 
TIME                 EXECUTIONS   ET_S_1EXEC CPU_TIME_S_1EXEC IOWAIT_S_1EXEC CLWAIT_S_1EXEC APWAIT_S_1EXEC CCWAIT_S_1EXEC ROWS_PROCESSED_1EXEC BUFFER_GETS_1EXEC  DISK_READS_1EXEC
------------------- ----------- ------------ ---------------- -------------- -------------- -------------- -------------- -------------------- ----------------- -----------------
23.09.2015 00:15:00          12      117.923          117.667           .001           .000           .000           .000                 .000      23049569.333              .083
23.09.2015 00:30:00          14     1284.493         1280.963           .002           .000           .000           .000                 .000     243817703.571             1.214
23.09.2015 00:45:00          26     1579.532         1574.306           .016           .000           .000           .000                 .000              .000             5.962
23.09.2015 01:00:00          41     1729.918         1718.699           .002           .000           .000           .000                 .000      26916357.415              .317
23.09.2015 01:15:00          26     3850.767         3739.324           .011           .000           .000           .000                 .000              .000             1.731
23.09.2015 01:30:00          27     4565.527         3868.424           .017           .000           .000           .000                 .000      82060590.481             4.407
 

At the first glance it seemed to me as the sql was newly introduced to the database as AWR showed it from the same day, even though I had asked from 5 days snapshots.

The buffer gets per execution for the sql was too high and with multiple sessions with the same sqlid caused latch cbc and in turn high load. So, had to find what was causing this high buffer gets.

The execution plan for sql looked fine. The stats were fine and the index picked by the optimizer was fine too.At this point came in “latchprofx” by Tanel Poder 🙂

SELECT * FROM (
        SELECT
            event
          , TRIM(TO_CHAR(p1, 'XXXXXXXXXXXXXXXX')) latch_addr
          , TRIM(ROUND(RATIO_TO_REPORT(COUNT(*)) OVER () * 100, 1))||'%' PCT
          , COUNT(*)
        FROM
            v$active_session_history
        WHERE
           event = 'latch: cache buffers chains'
       AND session_state = 'WAITING'
       GROUP BY
           event
        , p1
       ORDER BY
           COUNT(*) DESC
   )
   WHERE ROWNUM <= 10
  /  

EVENT                                  LATCH_ADDR        PCT              COUNT(*)
-----------------------------------  ----------------- ---------------- ----------
latch: cache buffers chains           7B9A57DB50        92.2%                 448
latch: cache buffers chains           7AE4EBCD68        2.5%                   12
latch: cache buffers chains           7B682705B8        1%                      5
latch: cache buffers chains           7B6FB0AFD0        .8%                     4
latch: cache buffers chains           7ADA39D6B8        .4%                     2
latch: cache buffers chains           7AE4D206F8        .2%                     1
latch: cache buffers chains           7B4A1A04B0        .2%                     1
latch: cache buffers chains           7B475726C0        .2%                     1
latch: cache buffers chains           7ACB819888        .2%                     1
latch: cache buffers chains           7AC6958BA8        .2%                     1

@latchprofx sid,name,sqlid,object % 7B9A57DB50 100000
 
-- LatchProfX 1.21 by Tanel Poder ( http://www.tanelpoder.com )
 
  SID NAME                                SQLID                      OBJECT       Held       Gets  Held %     Held ms Avg hold ms
----- ----------------------------------- --------------- ----------------- ---------- ---------- ------- ----------- -----------
 7155 cache buffers chains                9cg18w6mfqphn            1ECA461B          4          4     .00       2.025        .506
 1696 cache buffers chains                4ycfn45y3vj5p            1ECA461B          3          3     .00       1.519        .506
 8689 cache buffers chains                9cg18w6mfqphn            1ECA461B          3          3     .00       1.519        .506
 3809 cache buffers chains                9cg18w6mfqphn            1ECA461B          3          3     .00       1.519        .506
 3969 cache buffers chains                9cg18w6mfqphn            1ECA461B          3          3     .00       1.519        .506
 2742 cache buffers chains                9cg18w6mfqphn            1ECA461B          2          2     .00       1.013        .506
 2482 cache buffers chains                4ycfn45y3vj5p            1ECA461B          2          2     .00       1.013        .506
  439 cache buffers chains                9cg18w6mfqphn            1ECA461B          2          2     .00       1.013        .506
 1514 cache buffers chains                9cg18w6mfqphn            1ECA461B          2          2     .00       1.013        .506
 6894 cache buffers chains                9cg18w6mfqphn            1ECA461B          2          2     .00       1.013        .506
 6524 cache buffers chains                9cg18w6mfqphn            1ECA461B          2          2     .00       1.013        .506
 6101 cache buffers chains                9cg18w6mfqphn            1ECA461B          2          2     .00       1.013        .506
 3545 cache buffers chains                9cg18w6mfqphn            1ECA461B          2          2     .00       1.013        .506

All rows point to object “1ECA461B”

@dba 1ECA461B
 
    RFILE#     BLOCK# DUMP_CMD
---------- ---------- ------------------------------------------------
       123     673307 -- alter system dump datafile 123 block 673307

select name from v$datafile where file#=123;
 
NAME
---------------------------------------------------------------
+DATA01/usrprd04/datafile/undotbs1.1134.818027637

Ok, so something related to undo!!!!.

The alert log showed ORA-01555 for an Insert SQL in the same table

Wed Sep 23 02:44:32 2015
ORA-01555 caused by SQL statement below (SQL ID: 72pwjk9bxyygw, Query Duration=13521 sec, SCN: 0x0891.8fff8587):
 
                        INSERT INTO message_demo_ctc (.....)  select ........
						
Wed Sep 23 02:45:26 2015
Completed checkpoint up to RBA [0x2a16.2.10], SCN: 9421305667060

User/Pid                   Megs Used MINUTES_ACTIVE MODULE                                             Recs upd/del
-------------------- --------------- -------------- -------------------------------------------------- ------------
USER_EAS7/(3858)             392.82            264 cli@mesagae_demo_ctc.php                              3,945,675

Once the rollback completed, eventhing was back to normal. The buffer gets for sqlid ‘9cg18w6mfqphn’ was down to 24,950 from ~652617k. We had waited for almost 30-40mins for the rollback, could have killed the SID and SMON would have made rollback using parallel processes, which could have been faster.