其他分享
首页 > 其他分享> > 051-试题1 ORA-01555

051-试题1 ORA-01555

作者:互联网

UNDO参数设置:

undo retention  15Mins ,

Undo tablespace : UNDOTBS1

Size 115M

Auto-Extensible  NO

Retention Gurantee    NO

题目:

In an OLTP system, the user SCOTT has started a query on a large table in the peak transactional hour
that performs bulk inserts. The query runs for more than 15 minutes and then SCOTT receives the
following error:
ORA-01555: snapshot too old
What could be the reason for this error?
A.The query is unable to get a read-consistent image.
B.There is not enough space in Flash Recovery Area.
C.There is not enough free space in the flashback archive.
D.The query is unable to place data blocks in undo tablespace

 

参考答案 A

解析:

Concepts/Definitions

The ORA-1555 errors can happen when a query is unable to access enough undo to build
a copy of the data at the time the query started. Committed "versions" of blocks are
maintained along with newer uncommitted "versions" of those blocks so that queries can
access data as it existed in the database at the time of the query. These are referred to as
"consistent read" blocks and are maintained using Oracle undo management.


Terminology

Two key concepts are briefly covered below which help in the understanding of ORA-01555, Read Consistency and Delayed Block Cleanout.

1. Read Consistency

This is documented in the Oracle Database Concepts manual and so will not be discussed further. However, for the purposes of this article this should be read and understood if not understood already. Oracle Server has the ability to have multi-version read consistency which is invaluable to you because it guarantees that you are seeing a consistent view of the data (no 'dirty reads').

2. Delayed Block Cleanout

This is best illustrated with an example: Consider a transaction that updates a million row table. This obviously visits a large number of database blocks to make the change to the data. When the user commits the transaction Oracle does NOT go back and revisit these blocks to make the change permanent. It is left for the next transaction that visits any block affected by the update to 'tidy up' the block (hence the term 'delayed block cleanout').

Whenever Oracle changes a database block (index, table, cluster) it stores a pointer in the header of the data block which identifies the rollback segment used to hold the rollback information for the changes made by the transaction. (This is required if the user later elects to not commit the changes and wishes to 'undo' the changes made.)

Upon commit, the database simply marks the relevant rollback segment header entry as committed. Now, when one of the changed blocks is revisited Oracle examines the header of the data block which indicates that it has been changed at some point. The database needs to confirm whether the change has been committed or whether it is currently uncommitted. To do this, Oracle determines the rollback segment used for the previous transaction (from the block's header) and then determines whether the rollback header indicates whether it has been committed or not.

If it is found that the block is committed then the header of the data block is updated so that subsequent accesses to the block do not incur this processing.

This behaviour is illustrated in a very simplified way below. Here we walk through the stages involved in updating a data block.

ORA-01555 Explanation

There are two fundamental causes of the error ORA-01555 that are a result of Oracle trying to attain a 'read consistent' image. These are:

    The rollback information itself is overwritten so that Oracle is unable to rollback the (committed) transaction entries to attain a sufficiently old enough version of the block.
    The transaction slot in the rollback segment's transaction table (stored in the rollback segment's header) is overwritten, and Oracle cannot rollback the transaction header sufficiently to derive the original rollback segment transaction slot.

Both of these situations are discussed below with the series of steps that cause the ORA-01555. In the steps, reference is made to 'QENV'. 'QENV' is short for 'Query Environment', which can be thought of as the environment that existed when a query is first started and to which Oracle is trying to attain a read consistent image. Associated with this environment is the SCN (System Change Number) at that time and hence, QENV 50 is the query environment with SCN 50.

 

参考MOS  :

Master Note for ORA-1555 Errors (文档 ID 1307334.1)

ORA-01555 "Snapshot too old" - Detailed Explanation (文档 ID 40689.1)

end

标签:transaction,rollback,01555,Oracle,query,051,block,ORA
来源: https://blog.csdn.net/xxzhaobb/article/details/95003959