10 Replies Latest reply: Jan 26, 2010 4:04 AM by Timur Akhmadeev RSS

    Reason for "control file sequential read" waits?

    650635
      Hi,

      We have a 10.2.0.4.0 2.node RAC database on Windows 2003 (all 64-bit).

      Looking at the "top 5 timed events" section of the AWR reports (always for 1 hour), we always see "CPU time" as the number one event (due to our application, some issues hopefully being looked at right now by developers..) but recently I am seeing "control file sequential read" as the number two event, with 3,574,633 waits and time of 831s. I was hoping to find out what was causing this high number of waits. I started by trying to find a particular query that experienced this wait often, so I ran this SQL:
      select sql_id, count(*)
      from dba_hist_active_sess_history
      where event_id = (select event_id from v$event_name where name = 'control file sequential read')
      group by sql_id
      order by 2 desc ;
      As I was hoping for, the top sql_id returned truly stands out, with a count of 14,182 (the next sql_id has a count of 68). This is the sql text for this id:
      WITH unit AS( 
                SELECT UNIQUE S.unit_id
                FROM STOCK S, HOLDER H
                WHERE  H.H_ID = S.H_ID 
                  AND  H.LOC_ID  = :B2 
                  AND  S.PROD_ID   = :B1 
                  ) 
      SELECT  DECODE((SELECT COUNT(*) FROM unit), 1, unit_ID, NULL) 
       FROM   unit
      WHERE   ROWNUM = 1
      ;
      (Ok, slightly strange code, but I've already got them to change it.)

      My question is:

      Why/what does this code have to read from the control file?


      Regards,

      Ados

      PS - I also checked the block number in p2 of dba_hist_active_sess_history for this sql_id and event_id, and it is always one of 5 blocks in the controlfile. I dumped the controlfile, but don't see anything interesting (although admittedly, this is the first time I've dumped a controlfile so have no idea really what to do!).
        • 1. Re: Reason for "control file sequential read" waits?
          729338
          Hi,

          I am not sure if 'control file sequential read' is due to this SQL. Is your control files located on different disks. If you have all your control files on a disk with high disk I/O then access to control file for updating the SCN etc may result in this wait.

          HTH
          • 2. Re: Reason for "control file sequential read" waits?
            Timur Akhmadeev
            Hi,
            Ados wrote:
            WITH unit AS( 
                      SELECT UNIQUE S.unit_id
                      FROM STOCK S, HOLDER H
                      WHERE  H.H_ID = S.H_ID 
                        AND  H.LOC_ID  = :B2 
                        AND  S.PROD_ID   = :B1 
            ) 
            SELECT  DECODE((SELECT COUNT(*) FROM unit), 1, unit_ID, NULL) 
            FROM   unit
            WHERE   ROWNUM = 1
            ;
            This query contains subquery factoring clause; and since it references the unit twice in the main part, big chances are subquery factoring is being materialized into global temporary table in the SYS schema with name SYS_TEMP_% and is accessed twice in the execution plan later (check for TEMP TABLE TRANSFORMATION step presence). The step of filling this intermediate table requires you to write into the temporary tablespace - and it is done via direct write. Each direct write to the segment (i.e. directly to the file on disk) requires a datafile status check - is it online or offline - which is done by control file access. Hence, you see those waits. This is one of the many things why subquery factoring is not good for production OLTP environments.
            • 3. Re: Reason for "control file sequential read" waits?
              650635
              Hi Timur,

              Excellent answer, I think that's correct. Here's a sample explan plan for the statement:
              ----------------------------------------------------------------------------------------------------------------
              | Id  | Operation                        | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
              ----------------------------------------------------------------------------------------------------------------
              |   0 | SELECT STATEMENT                 |                             |     1 |    13 |     7  (15)| 00:00:01 |
              |   1 |  SORT AGGREGATE                  |                             |     1 |       |            |          |
              |   2 |   VIEW                           |                             |     1 |       |     2   (0)| 00:00:01 |
              |   3 |    TABLE ACCESS FULL             | SYS_TEMP_0FD9D662B_2BEB461B |     1 |     3 |     2   (0)| 00:00:01 |
              |   4 |  TEMP TABLE TRANSFORMATION       |                             |       |       |            |          |
              |   5 |   LOAD AS SELECT                 |                             |       |       |            |          |
              |   6 |    HASH UNIQUE                   |                             |     1 |    23 |     5  (20)| 00:00:01 |
              |   7 |     TABLE ACCESS BY INDEX ROWID  | STOCK                       |     1 |    13 |     2   (0)| 00:00:01 |
              |   8 |      NESTED LOOPS                |                             |     1 |    23 |     4   (0)| 00:00:01 |
              |   9 |       TABLE ACCESS BY INDEX ROWID| HOLDER                      |     1 |    10 |     2   (0)| 00:00:01 |
              |* 10 |        INDEX RANGE SCAN          | HOLDER_LOCATION_ID_I        |     1 |       |     1   (0)| 00:00:01 |
              |* 11 |       INDEX RANGE SCAN           | STOCK_HOLD_PRO_I            |     1 |       |     1   (0)| 00:00:01 |
              |* 12 |   COUNT STOPKEY                  |                             |       |       |            |          |
              |  13 |    VIEW                          |                             |     1 |    13 |     2   (0)| 00:00:01 |
              |  14 |     TABLE ACCESS FULL            | SYS_TEMP_0FD9D662B_2BEB461B |     1 |     3 |     2   (0)| 00:00:01 |
              ----------------------------------------------------------------------------------------------------------------
              One thing though:
              Timur Akhmadeev wrote:
              This query contains subquery factoring clause; and since it references the unit twice in the main part, big chances are subquery factoring is being materialized into global temporary table in the SYS schema with name SYS_TEMP_% and is accessed twice in the execution plan later (check for TEMP TABLE TRANSFORMATION step presence).
              Does the fact that the unit was referenced twice dictate this behaviour (or indeed, did it have an influence over your correct assumption)? I just wonder if this is a "rule", or just a general behaviour that has been obvserved over time, or what? Indeed, if I change the query to only reference the unit once in the main part, this TEMP TABLE TRANSFORMATION behaviour is not seen.

              I hope you can find a second to enlighten me some more!!

              Thanks again for a great answer!

              Regards,

              Ados
              • 4. Re: Reason for "control file sequential read" waits?
                Timur Akhmadeev
                Ados wrote:
                Does the fact that the unit was referenced twice dictate this behaviour (or indeed, did it have an influence over your correct assumption)? I just wonder if this is a "rule", or just a general behaviour that has been obvserved over time, or what? Indeed, if I change the query to only reference the unit once in the main part, this TEMP TABLE TRANSFORMATION behaviour is not seen.
                The behavior of subquery factoring materialization when referenced twice or more in the main part is not a strong rule - it just usually happens so. Though some MOS notes (IIRC) states this is a "rule", it isn't strict and I have some examples for that:
                SQL> explain plan for
                  2  with t as (select * from dual)
                  3  select * from t t1, t t2;
                 
                Explained
                SQL> @xp
                SQL> select * from table(dbms_xplan.display);
                 
                PLAN_TABLE_OUTPUT
                ------------------------------------------------------------------------------------------------------------------------
                Plan hash value: 735651981
                ---------------------------------------------------------------------------
                | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
                ---------------------------------------------------------------------------
                |   0 | SELECT STATEMENT   |      |     1 |     4 |     4   (0)| 00:00:01 |
                |   1 |  NESTED LOOPS      |      |     1 |     4 |     4   (0)| 00:00:01 |
                |   2 |   TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
                |   3 |   TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
                ---------------------------------------------------------------------------
                 
                10 rows selected
                SQL> explain plan for
                  2  with t1 as (select to_clob('x') from t)
                  3  select * from t1, t1 t2;
                 
                Explained
                SQL> @xp
                SQL> select * from table(dbms_xplan.display);
                 
                PLAN_TABLE_OUTPUT
                ------------------------------------------------------------------------------------------------------------------------
                Plan hash value: 818485285
                -------------------------------------------------------------------------------------
                | Id  | Operation            | Name | Rows  | Cost (%CPU)| Time     | Pstart| Pstop |
                -------------------------------------------------------------------------------------
                |   0 | SELECT STATEMENT     |      |    64 |    42   (0)| 00:00:01 |       |       |
                |   1 |  MERGE JOIN CARTESIAN|      |    64 |    42   (0)| 00:00:01 |       |       |
                |   2 |   PARTITION HASH ALL |      |     8 |     6   (0)| 00:00:01 |     1 |     8 |
                |   3 |    TABLE ACCESS FULL | T    |     8 |     6   (0)| 00:00:01 |     1 |     8 |
                |   4 |   BUFFER SORT        |      |     8 |    36   (0)| 00:00:01 |       |       |
                |   5 |    PARTITION HASH ALL|      |     8 |     5   (0)| 00:00:01 |     1 |     8 |
                |   6 |     TABLE ACCESS FULL| T    |     8 |     5   (0)| 00:00:01 |     1 |     8 |
                -------------------------------------------------------------------------------------
                 
                13 rows selected
                • 5. Re: Reason for "control file sequential read" waits?
                  650635
                  Ok, great.

                  Thanks again Timur.


                  Regards,

                  Ados
                  • 6. Re: Reason for "control file sequential read" waits?
                    Jonathan Lewis
                    Timur Akhmadeev wrote:
                    Each direct write to the segment (i.e. directly to the file on disk) requires a datafile status check - is it online or offline - which is done by control file access.
                    Timur,

                    Although subquery materialization does result in CF read waits, I' not convinced that it's because of the direct path writes. There are several other reasons for direct path writes which don't cause the wait (e.g. use of temporary lobs, simple inserts into global temporary tables). I suspect the CR read wait is connected (for reasons I don't know) to the /*+ append */ mechanism that is used to populate the GTT created for materialization.

                    Further to your comment about using the subquery twice - I wrote [+*a note about this*+|http://jonathanlewis.wordpress.com/2007/07/26/subquery-factoring-2/] with my best guess a couple of years ago. The only fairly confident conclusion I came to was that it would not be materialized unless the non-merged but inline view was used at least+ twice in the query.

                    Regards
                    Jonathan Lewis
                    http://jonathanlewis.wordpress.com
                    http://www.jlcomp.demon.co.uk

                    To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}
                    {noformat} (lowercase, curly brackets, no spaces) so that the text appears in 
                    fixed format
                    .
                    
                    
                    "Science is more than a body of knowledge; it is a way of thinking" 
                    Carl Sagan                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        
                    • 7. Re: Reason for "control file sequential read" waits?
                      Timur Akhmadeev
                      Jonathan,

                      thanks for being suspicious. I've made a quick test in 11.2.0.1 and it shows no CF read on SFQ materialization:
                      SQL> !/usr/sbin/lsof -p 14017 | grep oradata
                      oracle  14017 oracle   10u   REG  253,0 734011392   2065673 /u01/app/oracle/oradata/test11g2/system01.dbf
                      oracle  14017 oracle   11u   REG  253,0 148119552   2065682 /u01/app/oracle/oradata/test11g2/users01.dbf
                      oracle  14017 oracle   13u   REG  253,0 148119552   2065682 /u01/app/oracle/oradata/test11g2/users01.dbf
                      oracle  14017 oracle   14u   REG  253,0 387981312   2065675 /u01/app/oracle/oradata/test11g2/undotbs01.dbf
                      oracle  14017 oracle   15u   REG  253,0 140517376   2065676 /u01/app/oracle/oradata/test11g2/temp01.dbf
                      oracle  14017 oracle   16u   REG  253,0 140517376   2065676 /u01/app/oracle/oradata/test11g2/temp01.dbf
                      
                      SQL> with tmp as (select count(*) from t1)
                        2  select count(*) from tmp t1, tmp t2;
                      
                        COUNT(*)
                      ----------
                               1
                      
                      SQL> !/usr/sbin/lsof -p 14017 | grep oradata
                      oracle  14017 oracle   10u   REG  253,0 734011392   2065673 /u01/app/oracle/oradata/test11g2/system01.dbf
                      oracle  14017 oracle   11u   REG  253,0 148119552   2065682 /u01/app/oracle/oradata/test11g2/users01.dbf
                      oracle  14017 oracle   13u   REG  253,0 148119552   2065682 /u01/app/oracle/oradata/test11g2/users01.dbf
                      oracle  14017 oracle   14u   REG  253,0 387981312   2065675 /u01/app/oracle/oradata/test11g2/undotbs01.dbf
                      oracle  14017 oracle   15u   REG  253,0 140517376   2065676 /u01/app/oracle/oradata/test11g2/temp01.dbf
                      oracle  14017 oracle   16u   REG  253,0 140517376   2065676 /u01/app/oracle/oradata/test11g2/temp01.dbf
                      
                      SQL> select * from table(dbms_xplan.display_cursor(null,null));
                      
                      PLAN_TABLE_OUTPUT
                      -------------------------------------------------------------------------------------------------------------------------
                      SQL_ID  85y2bgjccqvsn, child number 0
                      -------------------------------------
                      with tmp as (select count(*) from t1) select count(*) from tmp t1, tmp
                      t2
                      
                      Plan hash value: 340169489
                      
                      -------------------------------------------------------------------------------------------------------
                      | Id  | Operation                  | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
                      -------------------------------------------------------------------------------------------------------
                      |   0 | SELECT STATEMENT           |                          |       |       |   256 (100)|          |
                      |   1 |  TEMP TABLE TRANSFORMATION |                          |       |       |            |          |
                      |   2 |   LOAD AS SELECT           |                          |       |       |            |          |
                      |   3 |    SORT AGGREGATE          |                          |     1 |       |            |          |
                      |   4 |     TABLE ACCESS FULL      | T1                       | 52569 |       |   252   (1)| 00:00:04 |
                      |   5 |   SORT AGGREGATE           |                          |     1 |       |            |          |
                      |   6 |    MERGE JOIN CARTESIAN    |                          |     1 |       |     4   (0)| 00:00:01 |
                      |   7 |     VIEW                   |                          |     1 |       |     2   (0)| 00:00:01 |
                      |   8 |      TABLE ACCESS FULL     | SYS_TEMP_0FD9D6640_80492 |     1 |    13 |     2   (0)| 00:00:01 |
                      |   9 |     BUFFER SORT            |                          |     1 |       |     4   (0)| 00:00:01 |
                      |  10 |      VIEW                  |                          |     1 |       |     2   (0)| 00:00:01 |
                      |  11 |       TABLE ACCESS FULL    | SYS_TEMP_0FD9D6640_80492 |     1 |    13 |     2   (0)| 00:00:01 |
                      -------------------------------------------------------------------------------------------------------
                      whereas the same case in 10.2.0.4.3 does access to control files:
                      SQL> !/usr/sbin/lsof -p 540 | grep oradata
                      oracle  540 oracle10   10u   REG    3,6 838868992 3728292 /u02/oradata/db/system01.dbf
                      oracle  540 oracle10   12u   REG    3,6 361766912 3728300 /u02/oradata/db/users01.dbf
                      
                      with tmp as (select count(*) from t)
                        2  select * from tmp t1, tmp t2;
                      
                        COUNT(*)   COUNT(*)
                      ---------- ----------
                               8          8
                      
                      SQL> !/usr/sbin/lsof -p 540 | grep oradata
                      oracle  540 oracle10   10u   REG    3,6  838868992 3728292 /u02/oradata/db/system01.dbf
                      oracle  540 oracle10   12u   REG    3,6  361766912 3728300 /u02/oradata/db/users01.dbf
                      oracle  540 oracle10   13u   REG    3,6    7061504 3728284 /u02/oradata/db/control01.ctl
                      oracle  540 oracle10   14u   REG    3,6    7061504 3728285 /u02/oradata/db/control02.ctl
                      oracle  540 oracle10   15u   REG    3,6    7061504 3728286 /u02/oradata/db/control03.ctl
                      oracle  540 oracle10   16u   REG    3,6 2621448192 3728299 /u02/oradata/db/temp01.dbf
                      oracle  540 oracle10   17u   REG    3,6 2621448192 3728299 /u02/oradata/db/temp01.dbf
                      
                      SQL> select * from table(dbms_xplan.display_cursor(null,null));
                      
                      PLAN_TABLE_OUTPUT
                      --------------------------------------------------------------------------------------------------------------------------
                      SQL_ID  bybqc0fnzvcsc, child number 0
                      -------------------------------------
                      with tmp as (select count(*) from t) select * from tmp t1, tmp t2
                      
                      Plan hash value: 1488995274
                      
                      ------------------------------------------------------------------------------------------------------------------------
                      | Id  | Operation                  | Name                      | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
                      ------------------------------------------------------------------------------------------------------------------------
                      |   0 | SELECT STATEMENT           |                           |       |       |    10 (100)|          |       |       |
                      |   1 |  TEMP TABLE TRANSFORMATION |                           |       |       |            |          |       |       |
                      |   2 |   LOAD AS SELECT           |                           |       |       |            |          |       |       |
                      |   3 |    SORT AGGREGATE          |                           |     1 |       |            |          |       |       |
                      |   4 |     PARTITION HASH ALL     |                           |     8 |       |     6   (0)| 00:00:01 |     1 |     8 |
                      |   5 |      TABLE ACCESS FULL     | T                         |     8 |       |     6   (0)| 00:00:01 |     1 |     8 |
                      |   6 |   MERGE JOIN CARTESIAN     |                           |     1 |    26 |     4   (0)| 00:00:01 |       |       |
                      |   7 |    VIEW                    |                           |     1 |    13 |     2   (0)| 00:00:01 |       |       |
                      |   8 |     TABLE ACCESS FULL      | SYS_TEMP_0FD9D6601_AA6349 |     1 |    13 |     2   (0)| 00:00:01 |       |       |
                      |   9 |    BUFFER SORT             |                           |     1 |    13 |     4   (0)| 00:00:01 |       |       |
                      |  10 |     VIEW                   |                           |     1 |    13 |     2   (0)| 00:00:01 |       |       |
                      |  11 |      TABLE ACCESS FULL     | SYS_TEMP_0FD9D6601_AA6349 |     1 |    13 |     2   (0)| 00:00:01 |       |       |
                      ------------------------------------------------------------------------------------------------------------------------
                      So, all in all it may be a bug or change in behavior. I found just 1 more or less similar issue on the MOS - [Bug 7515779|https://supporthtml.oracle.com/ep/faces/secure/km/DocumentDisplay.jspx?id=7515779.8&h=Y]. Though it's not the same, I have a feeling the bug fix might have affected this particular case. If this is true, then 10.2.0.5 will behave just like 11.2.0.1. There is, BTW, one-off patch for 10.2.0.4 @ Linux x86-64. Unfortunately I have 32-bit Linux, otherwise, I'd install and test my assumption.
                      • 8. Re: Reason for "control file sequential read" waits?
                        user12068799
                        There is, BTW, one-off patch for 10.2.0.4 @ Linux x86-64. Unfortunately I have 32-bit Linux, otherwise, I'd install and test my assumption.
                        Today I've tested the bug-fix and it indeed has eliminated control file access during subquery factoring materialization.

                        Edited by: user12068799 on Jan 23, 2010 3:36 AM
                        Oh, that crappy MOS SSO once again...

                        Timur Akhmadeev.
                        • 9. Re: Reason for "control file sequential read" waits?
                          Jonathan Lewis
                          user12068799 wrote:
                          There is, BTW, one-off patch for 10.2.0.4 @ Linux x86-64. Unfortunately I have 32-bit Linux, otherwise, I'd install and test my assumption.
                          Today I've tested the bug-fix and it indeed has eliminated control file access during subquery factoring materialization.
                          Timur,

                          Thanks for testing and reporting back.
                          Has this patch also changed the number of "control file sequential read" waits and CF locks associated with "insert /*+ append */" ?

                          Regards
                          Jonathan Lewis
                          http://jonathanlewis.wordpress.com
                          http://www.jlcomp.demon.co.uk

                          To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}
                          {noformat} (lowercase, curly brackets, no spaces) so that the text appears in 
                          fixed format
                          .
                          
                          
                          "Science is more than a body of knowledge; it is a way of thinking" 
                          Carl Sagan                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            
                          • 10. Re: Reason for "control file sequential read" waits?
                            Timur Akhmadeev
                            Jonathan Lewis wrote:
                            Has this patch also changed the number of "control file sequential read" waits and CF locks associated with "insert /*+ append */" ?
                            I don't have the patched version anymore, but I assume yes. Here are results of trace 10046 level 8 & 10704 level 1 in 10.2.0.4.3 / 11.2.0.1:
                            PARSING IN CURSOR #2 len=45 dep=0 uid=41 oct=2 lid=41 tim=1234862469795926 hv=974719105 ad='3943a0b0'
                            insert /*+ append */ into t select * from t
                            END OF STMT
                            PARSE #2:c=0,e=109,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1234862469795916
                            ksqcmi: CF,0,0 mode=4 timeout=900
                            ksqcmi: returns 0
                            WAIT #2: nam='control file sequential read' ela= 60 file#=0 block#=1 blocks=1 obj#=-1 tim=1234862469797358
                            WAIT #2: nam='control file sequential read' ela= 23 file#=1 block#=1 blocks=1 obj#=-1 tim=1234862469797442
                            WAIT #2: nam='control file sequential read' ela= 23 file#=2 block#=1 blocks=1 obj#=-1 tim=1234862469797493
                            WAIT #2: nam='control file sequential read' ela= 24 file#=0 block#=16 blocks=1 obj#=-1 tim=1234862469797553
                            WAIT #2: nam='control file sequential read' ela= 30 file#=0 block#=18 blocks=1 obj#=-1 tim=1234862469797613
                            ksqcmi: XR,4,0 mode=2 timeout=0
                            ksqcmi: returns 0
                            PARSING IN CURSOR #2 len=43 dep=0 uid=60 oct=2 lid=60 tim=1264499276695229 hv=2473566350 ad='3adc5218' sqlid='9267dc29qz84f'
                            insert /*+ append */ into t select * from t
                            END OF STMT
                            PARSE #2:c=1000,e=2738,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=570131543,tim=1264499276695221
                            WAIT #2: nam='Disk file operations I/O' ela= 1023 FileOperation=2 fileno=5 filetype=2 obj#=-1 tim=1264499276706518
                            ksqcmi: XR,4,0 mode=2 timeout=0
                            ksqcmi: returns 0
                            WAIT #2: nam='Disk file operations I/O' ela= 273 FileOperation=2 fileno=5 filetype=2 obj#=-1 tim=1264499276721483
                            WAIT #2: nam='direct path write' ela= 5552 file number=5 first dba=5034 block cnt=22 obj#=-1 tim=1264499276727224
                            WAIT #2: nam='direct path write' ela= 6283 file number=5 first dba=5056 block cnt=32 obj#=-1 tim=1264499276754771
                            WAIT #2: nam='Disk file operations I/O' ela= 135 FileOperation=2 fileno=3 filetype=2 obj#=-1 tim=1264499276766599
                            
                            SQL> select file#, substr(name,1,45) from v$datafile;
                            
                                 FILE# SUBSTR(NAME,1,45)
                            ---------- -----------------------------------------------
                                     1 /u01/app/oracle/oradata/test11g2/system01.dbf
                                     2 /u01/app/oracle/oradata/test11g2/sysaux01.dbf
                                     3 /u01/app/oracle/oradata/test11g2/undotbs01.db
                                     4 /u01/app/oracle/oradata/test11g2/apex01.dbf
                                     5 /u01/app/oracle/oradata/test11g2/users01.dbf
                            As you can see, both CF read & CF lock have been eliminated.