髒讀Dirty reads
A transaction reads data that has been written by another transaction that has not been committed yet.
一個事務讀取另一個尚未提交的事務寫入的資料。

Oracle Database never permits dirty reads, which occur when a transaction reads uncommitted data in another transaction
Oracle資料庫永遠不允許髒讀，即不可能出現一個事務讀取另一個事務中未提交的資料。

可以簡單理解成ORACLE資料庫沒有髒讀的概念，因為實際中oracle資料庫永遠不會出現髒讀的現象。

Consistent mode
A consistent read get is a retrieval of a read-consistent version of a block. This retrieval may use undo data. For example, if an uncommitted transaction has updated two rows in a block, and if a query in a separate session requests the block, then the database uses undo data to create a read-consistent version of this block (called a consistent read clone) that does not include the uncommitted updates. Typically, a query retrieves blocks in consistent mode.
一致的讀取獲取塊的讀取一致版本。這個檢索可以使用撤消資料。例如，如果未提交的事務更新了塊中的兩行，並且如果單獨會話中的查詢請求該塊，則資料庫使用撤銷資料來建立此塊的讀一致版本（稱為一致讀取克隆）不包括未提交的更新。通常，查詢以一致模式檢索塊。
--具體理解：因為未提交，所以資料塊上沒有事務提交後的SCN，資料塊上的SCN還是事務開始之前的SCN，這時select時刻點的SCN大於資料塊的SCN，但是資料塊對應事務沒有提交，所以還是去回滾段中讀取資料塊的前映象。

Oracle Database maintains data consistency by using a multiversion consistency model and various types of locks and transactions. In this way, the database can present a view of data to multiple concurrent users, with each view consistent to a point in time. Because different versions of data blocks can exist simultaneously transactions can read the version of data committed at the point in time required by a query and return results that are consistent to a single point in time.
Oracle資料庫透過使用多版本一致性模型和各種型別的鎖和事務來維護資料一致性。透過這種方式，資料庫可以向多個併發使用者呈現資料檢視，每個檢視與時間點一致。由於不同版本的資料塊可以同時存在，因此事務可以讀取在查詢所需的時間點提交的資料的版本，並返回與單個時間點一致的結果。

In Oracle Database, each user must see a consistent view of the data, including visible changes made by a user's own transactions and committed transactions of other users. For example, the database must not permit a dirty read, which occurs when one transaction sees uncommitted changes made by another concurrent transaction.
Oracle Database always enforces statement-level read consistency, which guarantees that the data returned by a single query is committed and consistent with respect to a single point in time. Depending on the transaction isolation level, this point is the time at which the statement was opened or the time the transaction began. The Flashback Query feature enables you to specify this point in time explicitly.
The database can also provide read consistency to all queries in a transaction, known as transaction-level read consistency. In this case, each statement in a transaction sees data from the same point in time, which is the time at which the transaction began.
在Oracle資料庫中，每個使用者都必須看到資料的一致檢視，包括使用者自己的事務所做的可見更改以及其他使用者的已提交事務。例如，資料庫不允許髒讀，當一個事務看到另一個併發事務所做的未提交更改時，就會發生這種情況。
Oracle資料庫始終強制執行語句級別的讀取一致性，這保證了單個查詢返回的資料已被提交併且與單個時間點一致。根據事務隔離級別，這一點是開啟語句的時間或事務開始的時間。閃回查詢功能使您可以明確指定此時間點。
資料庫還可以為事務中的所有查詢提供讀取一致性，稱為事務級讀取一致性。在這種情況下，交易中的每個陳述都會看到來自同一時間點（即交易開始的時間點）的資料。

A system change number (SCN) is a logical, internal time stamp used by Oracle Database. SCNs order events that occur within the database, which is necessary to satisfy the ACID properties of a transaction. Oracle Database uses SCNs to mark the SCN before which all changes are known to be on disk so that recovery avoids applying unnecessary redo. The database also uses SCNs to mark the point at which no redo exists for a set of data so that recovery can stop.
SCNs occur in a monotonically increasing sequence. Oracle Database can use an SCN like a clock because an observed SCN indicates a logical point in time and repeated observations return equal or greater values. If one event has a lower SCN than another event, then it occurred at an earlier time with respect to the database. Several events may share the same SCN, which means that they occurred at the same time with respect to the database.
Every transaction has an SCN. For example, if a transaction updates a row, then the database records the SCN at which this update occurred. Other modifications in this transaction have the same SCN. When a transaction commits, the database records an SCN for this commit.
Oracle Database increments SCNs in the system global area (SGA). When a transaction modifies data, the database writes a new SCN to the undo data segment assigned to the transaction. The log writer process then writes the commit record of the transaction immediately to the online redo log. The commit record has the unique SCN of the transaction. Oracle Database also uses SCNs as part of its instance recovery and media recovery mechanisms.
系統更改號（SCN）是Oracle資料庫使用的邏輯內部時間戳記。 SCNs訂購資料庫內發生的事件，這是滿足事務的ACID屬性所必需的。 Oracle資料庫使用SCN標記SCN，在此之前知道所有更改都在磁碟上（寫入了online redo），以便恢復避免應用不必要的重做。資料庫還使用SCN標記一組資料不存在重做的點，以便可以停止恢復。
SCN以單調遞增的順序發生。 Oracle資料庫可以像使用時鐘一樣使用SCN，因為觀察到的SCN指示了一個邏輯時間點，並且重複的觀察返回相等或更大的值。如果一個事件的SCN低於另一個事件，那麼它發生在相對於資料庫更早的時間。幾個事件可能共享同一個SCN，這意味著它們同時發生在資料庫上。
每筆交易都有一個SCN。例如，如果一個事務更新了一行，那麼資料庫將記錄發生此更新的SCN。這個事務中的其他修改具有相同的SCN。當一個事務提交時，資料庫為這個提交記錄一個SCN。
Oracle資料庫在系統全域性區域（SGA）中增加SCN。當事務修改資料時，資料庫將新的SCN寫入分配給該事務的撤銷資料段。日誌寫入程式會立即將事務的提交記錄寫入線上重做日誌。提交記錄具有事務的唯一SCN。 Oracle資料庫還使用SCN作為其例項恢復和媒體恢復機制的一部分。
--當事務修改資料時，資料庫將新的SCN寫入分配給該事務的撤銷資料段：具體的理解就是當一個事務開始時，會記錄事務開始的SCN和修改前的資料到UNDO中

As the database retrieves data blocks on behalf of a query, the database ensures that the data in each block reflects the contents of the block when the query began. The database rolls back changes to the block as needed to reconstruct the block to the point in time the query started processing.
The database uses a mechanism called an SCN to guarantee the order of transactions. As the SELECT statement enters the execution phase, the database determines the SCN recorded at the time the query began executing. In Figure 9–1, this SCN is 10023. The query only sees committed data with respect to SCN 10023.
In Figure 9–1, blocks with SCNs after 10023 indicate changed data, as shown by the two blocks with SCN 10024. The SELECT statement requires a version of the block that is consistent with committed changes. The database copies current data blocks to a new buffer and applies undo data to reconstruct previous versions of the blocks. These reconstructed data blocks are called consistent read (CR) clones.
In Figure 9–1, the database creates two CR clones: one block consistent to SCN 10006 and the other block consistent to SCN 10021. The database returns the reconstructed data for the query. In this way, Oracle Database prevents dirty reads.
當資料庫以查詢方式檢索資料塊時，資料庫確保每個塊中的資料反映的是查詢開始時的內容。資料庫根據需要回滾對塊的更改，以將塊重建為查詢開始處理的時間點。
資料庫使用稱為SCN的機制來保證事務的順序。當SELECT語句進入執行階段時，資料庫確定查詢開始執行時記錄的SCN。在圖9-1中，這個SCN是10023，查詢關於SCN 10023已提交的資料。
在圖9-1中，10023之後的SCN塊表示更改的資料，如SCN 10024所示的兩個塊所示。SELECT語句需要與已提交的更改一致的塊版本。資料庫將當前資料塊複製到一個新的緩衝區，並應用撤銷資料來重建以前版本的資料塊。這些重建的資料塊被稱為一致讀（CR）克隆。
在圖9-1中，資料庫建立兩個CR克隆：一個塊與SCN 10006一致，另一個塊與SCN 10021一致。資料庫返回查詢的重構資料。透過這種方式，Oracle資料庫可以防止髒讀。
--查詢關於SCN 10023已提交的資料：具體的理解就是只能看到SCN 10023或之前SCN號已提交的資料

The database uses information in the block header, also called an interested transaction list (ITL), to determine whether a transaction was uncommitted when the database began modifying the block. The block header of every segment block contains an ITL.
資料庫使用塊頭中的資訊，也稱為感興趣事務列表（ITL），來確定在資料庫開始修改塊時事務是否未提交。每個segment塊的塊標題包含一個ITL。

Entries in the ITL describe which transactions have rows locked and which rows in the block contain committed and uncommitted changes. The ITL points to the transaction table in the undo segment, which provides information about the timing of changes made to the database.
In a sense, the block header contains a recent history of transactions that affected each row in the block. The INITRANS parameter of the CREATE TABLE and ALTER TABLE statements controls the amount of transaction history that is kept.
ITL中的條目描述哪些事務處於行鎖定狀態，哪些行包含已提交和未提交的更改。 ITL指向還原段中的事務表，該事務表提供有關對資料庫所做更改的時間的資訊。
從某種意義上說，塊標題包含了影響塊中每一行的事務的最近歷史記錄。 CREATE TABLE和ALTER TABLE語句的INITRANS引數控制保留的事務歷史記錄的數量。

The undo segments contain the old values of data that have been changed by uncommitted or recently committed transactions. Thus, multiple versions of the same data, all at different points in time, can exist in the database. The database can use snapshots of data at different points in time to provide read-consistent views of the data and enable nonblocking queries.
回滾段包含未提交或最近提交的事務更改的舊資料值。因此，在資料庫中可以存在多個版本的相同資料，所有這些版本都在不同的時間點。資料庫可以使用不同時間點的資料快照來提供資料的一致性檢視並啟用非阻塞查詢。

In general, it is desirable to retain old undo data as long as possible. After a transaction commits, undo data is no longer needed for rollback or transaction recovery. The database can retain old undo data if the undo tablespace has space for new transactions. When available space is low, the database begins to overwrite old undo data for committed transactions
通常，儘可能保留舊的撤消資料是可取的。事務提交後，撤銷資料不再需要回滾或事務恢復。如果撤消表空間有新的事務空間，資料庫可以保留舊的撤消資料。當可用空間不足時，資料庫將開始覆蓋已提交事務的舊撤消資料

ORA-01555: snapshot too old: rollback segment number string with name "string" too small
Cause: rollback records needed by a reader for consistent read are overwritten by other writers
Action: If in Automatic Undo Management mode, increase undo_retention setting. Otherwise, use larger rollback segments
ORA-01555：快照太老：回滾段名稱字串的字串太小
原因：閱讀器讀取一致性所需的回滾記錄被其他作者覆蓋
操作：如果在“自動還原管理”模式下，增加undo_retention設定。否則，使用更大的回滾段

ORA-01555:快照過舊錯誤，除了sql執行時間過長外，還可能是undo空間不夠或undo_retention值過小或undo_retention值足夠但是GUARANTEE沒有啟用

個人理解
這個塊的scn小於sql程式本身的scn且未提交，則要去讀取回滾段，這個時候不會報ORA-01555，因為回滾段裡面沒有提交的資料是不會被覆蓋的
這個塊的scn大於sql程式本身的scn，也要去回滾段讀取，這個時候資料塊一定是提交了（當一個事務提交時，資料庫為這個提交記錄一個SCN），則提交時間肯定是大於sql開始執行時間點小於執行到讀取該塊的時間點，所以sql執行時間小於undo_retention且GUARANTEE啟用則沒有問題不會報ORA-01555。

如果一個select查詢耗時2小時時，從select開始到這個塊被訪問時，這個塊已經被修改了5次並且都提交了
1、如果這5次記錄都還在undo中，但是INITRANS只是4時（MAXTRANS是4則INITRANS最大也只能是4，預設情況下INITRANS to 1，MAXTRANS to 255），會報錯。
2、如果只有4次記錄還在undo中，一次被覆蓋了，會報錯ORA-01555

實驗過，10G容量級別的大量insert操作了30分鐘，但是不commit，會發現redo log不停的切換產生歸檔日誌，且datafile不停增加。再直接shutdown abort，startup的時候發現很快，不需要30分鐘。
前滾回滾過程應該是這樣的：資料庫記錄了最新的SCN、增量checkpoint的SCN、redo log的最大SCN，透過增量checkpoint的SCN開始應用redo log直到redo log的最大SCN乃至最新的SCN，這樣就完成了前滾，在回滾的時候直接讀取undo中這個會話最初的scn和前映象直接回滾，不會一個個資料塊去undo，否則10G都已經寫入資料檔案那回滾得多久啊

參考oracle官方文件關於髒讀、一致性讀、undo中已提交資料塊的理解

相關文章