Shulou(Shulou.com)05/31 Report--

How to analyze the Oracle physical reading logic reading consistency reading current mode reading, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

A brief Analysis of Oracle physical Reading Logic Reading consistency Reading current Mode Reading Summary

There are many concepts in ORACLE database, such as physical read (Physical Reads), logical read (Logical Reads), consistent read (Consistant Get), current mode read (DB Block Gets) and so on. If you don't understand or confuse these concepts, it is undoubtedly an obstacle for you to understand some knowledge deeply, but these concepts are really confusing. Now let's summarize and learn some knowledge points in this area. Sort out their relationship and characteristics. I hope it will be helpful to you.

Physical read (Physical Reads)

The operation of reading blocks from disk to memory is called physical reads, and physical reads occur when these blocks are not present in the Cache Buffer in the SGA. Operations such as full table scan and disk sorting may also produce physical reads, also because the ORACLE database needs to access more data blocks, while some data blocks are not in memory and need to be read from disk.

Logical read (Logical Reads)

Concept 1: logical reads refer to the number of blocks that ORACLE reads from memory. Generally speaking, logical reads = db block gets + consistent gets

Concept 2: logical reading refers to reading blocks from Buffer Cache. According to the mode of accessing the data block, it can be divided into current mode read (Current Read) and consistent read (Consistent Read).

The two concepts are essentially the same, but the wording is not the same.

Consistent read (Consistant Get)

ORACLE is a multi-user system. When a session starts reading data before it finishes reading, other sessions may modify the data it is about to read. If the session reads the modified data, it will cause data inconsistency. Consistency reading is to ensure the consistency of data. On all blocks in Buffer Cache, there is the SCN when the block was last modified. If a transaction needs to modify the data in the block, it first saves a copy of the pre-modified data and the block of SCN in the rollback segment, and then updates the data of the block in Buffer Cache and its SCN, and identifies it as "dirty" data. When other processes read the block, they first compare the SCN on the block with the process's own SCN. If the SCN on the data block is less than or equal to the SCN of the process itself, the data on the data block is read directly; if the SCN on the data block is greater than the SCN of the process itself, the modified block read data is found in the rollback segment. In general, normal queries are consistent reads.

Current mode read (DB Block Gets)

Personally, I think the current mode reading (db block gets) is the most difficult concept to understand. Usually, db block gets can be understood as the result of DML operation.

Current mode read (db block gets) means that the read block is the current latest data. There is only one current block in the Buffer Cache at any time. The current read usually occurs when the data is modified or deleted. At this point, the process puts a row-level lock on the data and identifies the data as "dirty" data. Current mode generates db block gets, which is generally generated during DML operations, and query mode generates consistent gets (consistent read), which is generally generated during query. The sum of the two of them is generally called logical reading, logical read.

An interesting phenomenon is that in ask tom or some data, you will find that Oracle 8i can also see db block gets in SELECT queries, but ORACLE 10 and above generally have a db block gets of 0 in SELECT statements.

After understanding the concepts, if you still have some questions and puzzles, let's understand them with practical examples. As follows:

SQL > show user;USER is "SYS"

SQL > create table test 2 as 3 select * from dba_objects

Table created.

SQL > alter session set sql_trace=true

System altered.

SQL > set autotrace on;SQL > select object_type, count (1) from test 2 group by object_type

OBJECT_TYPE COUNT (1)-EDITION 1INDEX PARTITION 264CONSUMER GROUP 25SEQUENCE 223TABLE PARTITION 240SCHEDULE 3QUEUE 35RULE 1JAVA DATA 328...

43 rows selected.

Execution Plan---Plan hash value: 1435881708

| Id | Operation | Name | Rows | Bytes | Cost (% CPU) | Time |- -| 0 | SELECT STATEMENT | | 75101 | 806k | 284K (2) | 00:00:04 | 1 | HASH GROUP BY | | 75101 | 806k | 284K (2) | 00:00:04 | 2 | TABLE ACCESS FULL | TEST | | 75101 | 806k | 281 (1) | 00:00:04 |-Note--dynamic sampling used for this statement (level=2) |

Statistics--- 48 recursive calls 0 db block gets 1109 consistent gets 1029 physical reads 0 redo size 1694 bytes sent via SQL*Net to client 545 bytes received via SQL*Net from client 4 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 43 rows processed

SQL > select object_type, count (1) from test 2 group by object_type

OBJECT_TYPE COUNT (1)-- EDITION 1INDEX PARTITION 264CONSUMER GROUP 25SEQUENCE 223TABLE PARTITION 240. ..

43 rows selected.

Execution Plan---Plan hash value: 1435881708

| Id | Operation | Name | Rows | Bytes | Cost (% CPU) | Time |- -| 0 | SELECT STATEMENT | | 75101 | 806k | 284K (2) | 00:00:04 | 1 | HASH GROUP BY | | 75101 | 806k | 284K (2) | 00:00:04 | 2 | TABLE ACCESS FULL | TEST | | 75101 | 806k | 281 (1) | 00:00:04 |-Note--dynamic sampling used for this statement (level=2) |

Statistics--- 0 recursive calls 0 db block gets 1034 consistent gets 0 physical reads 0 redo size 1694 bytes sent via SQL*Net to client 545 bytes received via SQL*Net from client 4 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 43 rows processed

SQL > set autotrace offSQL > alter session set sql_trace = false

Session altered.

SQL > SELECT T.value 2 | |'/'3 | | Lower (Rtrim (I.INSTANCE, Chr (0)) 4 | |'_ ora_' 5 | | P.spid 6 | | '.trc' TRACE_FILE_NAME 7 FROM (SELECT P.spid 8 FROM v$mystat M, 9 v$session S) 10 v$process P 11 WHERE M.statistic# = 1 12 AND S.sid = M.sid 13 AND P.addr = S.paddr) P, 14 (SELECT T.INSTANCE 15 FROM v$thread T 16 v$parameter V 17 WHERE V.name = 'thread' 18 AND (V.value = 0 19 OR T.thread# = To_number (V.value) I, 20 (SELECT value 21 FROM v$parameter 22 WHERE name =' user_dump_dest') T

TRACE_FILE_NAME----/u01/app/oracle/diag/rdbms/gsp/gsp/trace/gsp_ora_24900.trc

When the SQL statement is executed for the first time, the consistent read (consistent gets) is 1109, the physical read (physical reads) is 1029, and the current mode read (db block gets) is 0. 5. If you execute the above SQL statement again, you will find that the physical read (physical reads) will be reduced to 0, because in the last query, ORACLE has read all the data blocks of the table test into buffer cache. Of course, the actual situation of the production environment will be much more complicated.

Let's format the trace file with the tkprof tool, and then we'll analyze the out_24900.prf file.

[oracle@DB-Server trace] $tkprof gsp_ora_24900.trc out_24900.prf aggregate=no

TKPROF: Release 11.2.0.1.0-Development on Thu Sep 22 10:12:15 2016

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

Before we analyze, let's take a look at some concepts and terms.

Count = number of times OCI procedure was executed

Cpu = cpu time in seconds executing

Elapsed = elapsed time in seconds executing

Disk = number of physical reads of buffers from disk # physical read

Query = number of buffers gotten for consistent read # consistent read

Current = number of buffers gotten in current mode (usually for update) # current mode read

Rows = number of rows processed by the fetch or execute call

Call: the processing of each SQL statement is divided into three parts

Parse: this step includes syntax checking and semantic checking (including checking for correct authorization and the existence of tables, columns, and other referenced objects), as well as transforming SQL statements, generating execution plans, and so on.

Execute: this step is really for ORACLE to execute the statement. For insert, update, delete operations, this step modifies the data, and for select operations, it simply determines the selected record.

Fetch: returns the records obtained in the query statement, in which only the select statement will be executed.

Count: the number of times this statement has been parse, execute, fetch.

Cpu: this statement is the time in seconds of cpu consumed by all parse, execute, and fetch.

Elapsed: all the total time spent in parse, execute, fetch in this statement.

Disk: the number of blocks physically read from a data file on disk.

Query: the number of consistent reads in consistent read mode.

Current: the number of db blocks gets read in current mode, that is, the current mode.

Rows: the number of records returned by all SQL statements, excluding the number of records returned in the subquery. For select statements, the record is returned at the fetch step, and for insert, update, and delete operations, the record is returned at the execute step.

As shown in the screenshot below (figure 1 and figure 2 are connected together, because the screenshots are too long, separate screenshots, and the two pictures have the same part), because we did not collect statistics during the experiment, you will see that there is a dynamic sample in the trac file (if you are creating a table and doing a statistical collection, the results will be different). In addition, physical reading and consistency reading are as follows Consistent with the data in the above execution plan.

Disk (physical read) = 747282 = 1029

Query (consistent read) = 1035 read 74 = 1109

If we continue to analyze the formatted prf file, we will see that the query (consistency read) of the second query is 1034 and the disk (physical read) is zero. Let's learn about physical read and consistent read, so let's take a look at the example of current mode read (db block gets).

SQL > create table t 2 (id number (10) 3)

Table created.

SQL > set autotrace on;SQL > insert into t 2 values (1000)

1 row created.

Execution Plan- -| Id | Operation | Name | Rows | Bytes | Cost (% CPU) | Time |- -| 0 | INSERT STATEMENT | | 1 | 100 | 1 (0) | 00:00:01 | | 1 | LOAD TABLE CONVENTIONAL | T |- -

Statistics--- 1 recursive calls 7 db block gets 1 consistent gets 0 physical reads 748 redo size 836 bytes sent via SQL*Net to client 783 bytes received via SQL*Net from client 3 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 1 rows processed

SQL > insert into t 2 values (1001)

1 row created.

Execution Plan- -| Id | Operation | Name | Rows | Bytes | Cost (% CPU) | Time |- -| 0 | INSERT STATEMENT | | 1 | 100 | 1 (0) | 00:00:01 | | 1 | LOAD TABLE CONVENTIONAL | T |- -

Statistics--- 1 recursive calls 1 db block gets 1 consistent gets 0 physical reads 308 redo size 837 bytes sent via SQL*Net to client 783 bytes received via SQL*Net from client 3 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 1 rows processed

How to calculate the consistency reading?

How to calculate the consistency reading? I checked the data, generally consistent to read consistent gets ~ = numrows/arraysize + blocks, exactly consistent reads calculation ~ = ceil (get the number of rows (card) / arraysize) + used blocks, and this is not absolutely equal, but approximately equal to the relationship. But this is not the official information, but the introduction of asktom and some technical blogs. Let's verify it.

SQL > exec dbms_stats.gather_table_stats (user, 'TEST')

PL/SQL procedure successfully completed.

SQL > SQL > set autotrace traceonly statSQL > select * from test

72271 rows selected.

Statistics--- 448 recursive calls 0 db block gets 5846 consistent gets 1031 physical reads 0 redo size 8296071 bytes sent via SQL*Net to client 53521 bytes received via SQL*Net from client 4820 SQL* Net roundtrips to/from client 3 sorts (memory) 0 sorts (disk) 72271 rows processedSQL > /

72271 rows selected.

Statistics--- 0 recursive calls 0 db block gets 5789 consistent gets 0 physical reads 0 redo size 8296071 bytes sent via SQL*Net to client 53521 bytes received via SQL*Net from client 4820 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 72271 rows processed

SQL > set autotrace off;SQL > set serveroutput on;SQL > exec show_space ('TEST',USER); Free Blocks.. 0Total Blocks.. 1152Total Bytes.. 9437184Total MBytes.. 9Unused Blocks.. 121Unused Bytes.. 991232Last Used Ext FileId. 1Last Used Ext BlockId. 89344Last Used Block. seven

PL/SQL procedure successfully completed.

SQL > show arraysize; arraysize 15SQL > select ceil (72271 from dual 15) + 1152-121 from dual

CEIL (72271amp 15) + 1152-121 Murray-5850

SQL > SELECT COUNT (DISTINCT dbms_rowid.rowid_block_number (ROWID)) AS blocks FROM TEST

BLOCKS- 1030

SQL > SELECT ceil (72271amp 15) + 1030 FROM DUAL

CEIL (72271 Compact 15) + 1030-5849

Whether it's 5849 or 5850, it's a little different from 5879 or 5846? That is to say, the above formula cannot use the equal sign. With regard to this, in fact, in https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:880343948514, you will see that what is introduced here is also an approximate equal relation, not an absolute equal relation. I want to go a little deeper here, but my knowledge is limited. From the above formula, we can see that consistent reading has a lot to do with arraysize. So let's test and verify, first adjust the araraysize to 50.

SQL > set autotrace off;SQL > set arraysize 50SQL > set autotrace traceonly stat;SQL > select * from test

72271 rows selected.Statistics--- 0 recursive calls 0 db block gets 2456 consistent gets 0 physical reads 0 redo size 7668743 bytes sent via SQL*Net to client 16418 bytes received via SQL*Net from client 1447 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 72271 rows processed

SQL > SQL > SELECT ceil (72271) + 1030 FROM DUAL;CEIL (72271) + 1030-2476SQL >

As shown above, the consistency reading has been reduced from 5789 to 2456. If you are interested, you can do some experiments. In addition, because in Oracle, the data is finally fetched from buffer cache, so every time there is a physical reads, there must be a logical reads. That is to say, physical reading (physical reads) must be less than logical reading (logical reads=db block gets + consistent gets), that is to say, physical reading must be smaller than consistent reading, but there are also cases where physical reading is larger than logical reading.

PURPOSE

In some circumstances, you can find that tkprof report shows more physical reads than logical reads, which isn't the current result as the physical reads are normally included in logical reads.

SCOPE & APPLICATION

This article will be useful for the DBA's and customers who are concerned by the tuning of Requests.

Why Physical reads are greater than Logical reads

Sometimes, you can find the following content in tkprof report:

Physical Reads = Disk (total)

Logical Reads = Query (total) + Current (total)

Call

Count

Cpu

Elapsed

Disk

Query

Current

Rows

-

-

-

-

-

-

-

-

Parse

one

0.67

1.10

0

0

0

0

Execute

one

0.00

0.00

0

0

0

0

Fetch

2202

167.48

678.70

579441

283473

17418

33014

-

-

-

-

-

-

-

-

Total

2204

168.15

679.81

579441

283473

17418

33014

The 'disk' column is then greater than the' query' + 'current' columns. This isn't usual.

To find the root cause of the problem, you must generate a 10046 event trace file level 8 and check for direct read waits in it.

In 10046 raw trace, you will find "direct path read" and "direct path write" waits like the example below:

WAIT # 1: nam='direct path read' ela= 10076 p1x 4 p2m 29035 p 3i 1

With P1 = file#, P2 = start block#, P3 = num blocks

The "direct path read" waits account explains the difference between logical and physical reads.

In Oracle 9.2 and above, TKProf will print waits associated with each SQL statement in the output file.

Explanation:

The reason for more physical reads than logical reads is due to the number of direct reads block access. Direct path reads are generally used by Oracle when reading directly into PGA memory (as opposed to into the buffer cache).

They may happen on different actions:

Sort IO on disk.

Read by parallel Query Slaves when scanning is done.

Blocks read by anticipation (readahead).

Such reads are done without loading blocks into the Buffer Cache. They can be single or multiblock reads.

Utilizing Direct Path Reads in this manner prevents the Oracle Buffer cache from beeing overloaded.

Oracle uses this optimisation when it considers that its not necessary to share the blocks between different sessions.

Finally, let's take a look at a case of skyrocketing consistent reading on hot meters. In fact, this is the art of Oracle 9i&10g programming: going deep into database architecture. Let's repeat it here, hoping to deepen your understanding of consistent reading. First, prepare to test the data environment.

SQL > show user;USER is "TEST" SQL > create table t (x int)

Table created.

SQL > insert into t values (1)

1 row created.

SQL > commit

Commit complete.

SQL > exec dbms_stats.gather_table_stats (user,'T')

PL/SQL procedure successfully completed.

SQL > set autotrace on statistics;SQL > select * from t

X1

Statistics--- 0 recursive calls 0 db block gets 7 consistent gets 0 physical reads 0 redo size 523 bytes sent via SQL*Net to client 523 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed

SQL >

As shown above, the general consistency read is 7, but we are ready to execute the following SQL in a session window, frequently modifying table T

SQL > begin 2 for i in 1. 100000 3 loop 4 update t set x end; 1; 5 commit; 6 end loop; 7 end; 8 /

PL/SQL procedure successfully completed.

At the same time as the above session is executed, we immediately execute the following SQL in another session window, and you will see a surge in consistent reads.

SQL > alter session set isolation_level=serializable

Session altered.

SQL > set autotrace on statistics;SQL > select * from t

X1

Statistics--- 1 recursive calls 0 db block gets 23681 consistent gets 0 physical reads 0 redo size 523 bytes sent via SQL*Net to client 523 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed

Set the session to use the SERIALIZABLE isolation level so that no matter how many times you run the query in the session, you will get the query results at the beginning of the transaction.

The Art of Oracle 9i&10g programming: going deep into database architecture

In sql tuning, a key indicator is consistent gets. If this indicator is very low, it is generally believed that the execution of sql statements is very efficient, otherwise it will be very inefficient. However, we know very little about this indicator, and we are ignorant of the way it is calculated. For logical reading, it is generally based on Logical Reads= Consistent Gets + DB Block Gets

If we know that logical reads is 1000, we may mistakenly think that the query read 1000008k (about 8m).

After reading the blog https://viveklsharma.wordpress.com/2010/03/04/consistent-gets-myth/, I found that my understanding was wrong, and I couldn't help but test it locally and benefited a lot.

First, let's create a table with 2000 pieces of data.

N1@TEST11G > create table test_consistent_get as select * from all_objects where rownum between 1 and 2000

Table created.

And then collect statistics.

N1@TEST11G > exec dbms_stats.gather_table_stats (user,'TEST_CONSISTENT_GET')

PL/SQL procedure successfully completed.

Check that the corresponding data block is 30

N1@TEST11G > select num_rows,blocks,table_name,last_analyzed,global_stats from user_tables where table_name='TEST_CONSISTENT_GET'

NUM_ROWS BLOCKS TABLE_NAME LAST_ANAL GLO

2000 30 TEST_CONSISTENT_GET 20-APR-15 YES

N1@TEST11G > set autot trace

Let's take a look at the execution plan, and it's obvious that we took a full table scan. But what we need to focus on is consistent gets in the statistics.

N1@TEST11G > select * from test_consistent_get

Execution Plan

Plan hash value: 1444268095

-

| | Id | Operation | Name | Rows | Bytes | Cost (% CPU) | Time |

-

| | 0 | SELECT STATEMENT | | 2000 | 164k | 10 (0) | 00:00:01 |

| | 1 | TABLE ACCESS FULL | TEST_CONSISTENT_GET | 2000 | 164k | 10 (0) | 00:00:01 |

-

Statistics

1 recursive calls

0 db block gets

163 consistent gets

0 physical reads

0 redo size

199754 bytes sent via SQL*Net to client

1883 bytes received via SQL*Net from client

135 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

2000 rows processed

You can see that the data block occupied by this table is 30, but the consistent gets is 163. obviously, it is not to say that the full table scan has read 163 to 8k of data into the cache.

We can use rowid to get the corresponding data blocks and the data in them.

N1@TEST11G > select dbms_rowid.ROWID_BLOCK_NUMBER (rowid) blkno, count (*) cnt

From test_consistent_get

Group by dbms_rowid.ROWID_BLOCK_NUMBER (rowid) order by 1

BLKNO CNT

--

263827 88

263828 84

263829 81

263830 76

263831 81

263832 80

263833 82

263834 77

263835 73

263836 78

263837 79

263838 79

263839 81

263841 82

263842 77

263843 81

263844 80

263845 81

263846 78

263847 78

263848 76

263849 78

263850 78

263851 76

263852 81

263853 15

26 rows selected.

26 related data blocks can be obtained by rowid. Check the segment header and find that the corresponding data block is 263826, which is not within the range of the data block corresponding to the above rowid.

N1@TEST11G > select header_block,blocks, extents from dba_segments where segment_name='TEST_CONSISTENT_GET'

HEADER_BLOCK BLOCKS EXTENTS

263826 32 4

The corresponding zone and block information are as follows:

N1@TEST11G > select EXTENT_ID, FILE_ID, BLOCK_ID, BLOCKS from dba_extents where SEGMENT_NAME='TEST_CONSISTENT_GET'

EXTENT_ID FILE_ID BLOCK_ID BLOCKS

--

0 4 263824 8

1 4 263832 8

2 4 263840 8

3 4 263848 8

The following statement calculates the value of the consistent gets for each data block.

N1@TEST11G >

Variable b1 number

Exec: b1VO15

Compute sum of total_cnt on report

Compute sum of touch_cnt on report

Break on report

Select blkno, total_cnt, final_cnt, rows_remaining

Case when rows_remaining=0 then touch_cnt+1 else touch_cnt end touch_cnt

From (

Select blkno, total_cnt, final_cnt, rows_remaining

Case when total_cnt = final_cnt then ceil (final_cnt/:b1) else ceil (final_cnt/:b1) + 1 end touch_cnt

From (

Select blkno, cnt total_cnt

Case when rownum=1 or lag (rows_remaining) over (order by blkno) = 0

Then cnt else (cnt- (: b1-lag (rows_remaining) over (order by blkno)) end final_cnt

Rows_remaining

From (

Select blkno, cnt, rr

Lead (rr) over (order by blkno) next_rr

Lead (blkno) over (order by blkno) next_blk

Ceil (rr/:b1) touch_cnt

Mod (rr,:b1) rows_remaining

From (

Select dbms_rowid.ROWID_BLOCK_NUMBER (rowid) blkno, count (*) cnt

Sum (count (*)) over (order by dbms_rowid.ROWID_BLOCK_NUMBER (rowid)) rr

From test_consistent_get

Group by dbms_rowid.ROWID_BLOCK_NUMBER (rowid) order by 1)

BLKNO TOTAL_CNT FINAL_CNT ROWS_REMAINING TOUCH_CNT

--

263827 88 88 13 6

263828 84 82 7 7

263829 81 73 13 6

263830 76 74 14 6

263831 81 80 5 7

263832 80 70 10 6

263833 82 77 2 7

263834 77 64 4 6

263835 73 62 26

263836 78 65 5 6

263837 79 69 9 6

263838 79 73 13 6

263839 81 79 4 7

263841 82 71 11 6

263842 77 73 13 6

263843 81 79 4 7

263844 80 69 9 6

263845 81 75 0 7

263846 78 78 3 6

263847 78 66 66

263848 76 67 76

263849 78 70 10 6

263850 78 73 13 6

263851 76 74 14 6

263852 81 80 5 7

263853 15 5 5 2

--

Sum 2000 159

You can see that for this full table scan scenario, consistent gets is not a measure of the number of blocks for cache, but the number of times.

For example, for the above data block 263827, the number of data bars is 88 and the arraysize is 15, you can briefly explain how the consistent gets value is calculated.

For block 263827, put it in PGA and get 15 rows, which can be understood as consistent gets=1

For block 263827, I get it again from PGA, and I get 15 rows, which is when consistent gets=2

And so on.

For block 263827, you get it again from PGA, and you get 13 rows, which is when consistent gets=6

Or it can be calculated basically according to this formula, number of rows of data / number of arraysize+ blocks = consistent gets

For example, in this example, 2000 shock 1530 is about 163.3, so 163is reliable.

When the arraysize is not 20 and 30, the corresponding consistent gets will also be reduced. A simple simulation.

N1@TEST11G > set arraysize 20

N1@TEST11G > set autot trace exp stat

N1@TEST11G > select * from test_consistent_get

Statistics

1 recursive calls

0 db block gets

128 consistent gets

0 physical reads

0 redo size

195334 bytes sent via SQL*Net to client

1509 bytes received via SQL*Net from client

101 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

2000 rows processed

N1@TEST11G > set autot off

N1@TEST11G > select 2000 take 20 minutes 30 from dual

2000, 2000, 20, 30.

-

one hundred and thirty

N1@TEST11G > set arraysize 30

N1@TEST11G > set autot trace stat

N1@TEST11G > select * from test_consistent_get

Statistics

0 recursive calls

0 db block gets

96 consistent gets

0 physical reads

0 redo size

191044 bytes sent via SQL*Net to client

1146 bytes received via SQL*Net from client

68 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

2000 rows processed

N1@TEST11G > set autot off

N1@TEST11G > select 2000 jump 30 minutes 30 from dual

2000 Universe 3030

-

96.6666667

This is the answer to the question on how to analyze Oracle's physical reading logic reading consistency reading current mode reading. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.