ORACLE Database Transaction isolation level

Transaction isolation level: the degree of isolation between one transaction's modification to the database and another transaction in parallel. When two concurrent transactions access the same row in the database table at the same time, there may be three problems: 1. Fantasy read: Transaction T1 reads a statement with the specified where condition and returns the result set. At this time, transaction T2 inserts a new row, which meets the where condition of T1. Then T1 uses the same condition to query again. The records inserted by T2 are displayed in the result set. This new record is an illusion. 2. Repeatable reading: Transaction T1 reads a row of records, and then transaction T2 modifies the records that T1 just read, and then T1 queries again. It is found that the records read for the first time are different, this is called non-repeated read.
3. Dirty read: Transaction T1 updates a record and has not submitted the modifications. This T2 reads the updated data, and then T1 performs the rollback operation to cancel the modification, therefore, the row read by T2 is invalid, that is, dirty data. To solve these problems, the SQL standard defines the following transaction isolation levels: www.2cto.com READ UNCOMMITTED, unrepeatable READ, and dirty READ. Read committed: Allows fantasies to READ, cannot READ repeatedly, and does not allow dirty reads to repeatable read, non-repeated read and dirty read SERIALIZABLE fantasy read, non-repeated read, and dirty read are not allowed
The Oracle Database supports read committed and SERIALIZABLE transaction isolation levels. Therefore, Oracle does not support the SERIALIZABLE transaction isolation level defined by the dirty read SQL standard, however, Oracle uses the read committed setting isolation level by default. set transaction isolation level [read uncommitted | read committed | repeatable read | SERIALIZABLE] is an example of how oracle sets the serializable isolation level:


The left side is transaction T1, and the right side is transaction T2. Because the T2 level is SERIALIZABLE, even after transaction T1 commits data, transaction T2 still cannot see the data submitted by T1, fantasy and non-repeated read are not allowed. Then how can we check the newly added records of T1? The above T1 and T2 are executed concurrently. When T1 executes insert, the transaction T2 has started, because the T2 level is SERIALIZABLE, therefore, the dataset queried by T2 is the data of the database before the start of the T2 transaction. That is, the impact of insert and update operations on transaction T1 after transaction T2 does not affect transaction T2. Now you can re-start transaction T3 to see the newly added records of T1. Www.2cto.com when the following events occur, the transaction starts: 1. Connect to the database and execute the first DML statement. 2. After the previous transaction ends, another DML statement is entered by JACKALMA.