What happen before and after user Commit Fire in Oracle:
The COMMIT statement ends a transaction successfully. All changes made by all SQL statements since
the transaction began are recorded permanently in the database. Before the COMMIT statement is
issued, the changes may not be visible to other transactions.
You can commit a transaction by using either of the following statements, which make the
changes permanent:
SQL> COMMIT;
3 things that happen Before Commit:
1. Oracle generates undo records in the undo segment buffers in the SGA. As you know, the
undo records contain the old values of the updated and deleted table rows.
2. Oracle generates redo log entries in the redo log buffers in the SGA.
3. Oracle modifies the database buffers in the SGA.
3 things that happen AFTER Commit:
1. The transaction tables in the redo records are tagged with the unique system change number
(SCN) of the committed transaction.
2. The log writer writes the redo log information for the transaction from the redo log buffer to
the redo log files on disk, along with the transaction’s SCN. This is the point at which a commit
is considered complete in Oracle.
3. Any locks that Oracle holds are released, and Oracle marks the transaction as complete.
the transaction began are recorded permanently in the database. Before the COMMIT statement is
issued, the changes may not be visible to other transactions.
You can commit a transaction by using either of the following statements, which make the
changes permanent:
SQL> COMMIT;
3 things that happen Before Commit:
1. Oracle generates undo records in the undo segment buffers in the SGA. As you know, the
undo records contain the old values of the updated and deleted table rows.
2. Oracle generates redo log entries in the redo log buffers in the SGA.
3. Oracle modifies the database buffers in the SGA.
3 things that happen AFTER Commit:
1. The transaction tables in the redo records are tagged with the unique system change number
(SCN) of the committed transaction.
2. The log writer writes the redo log information for the transaction from the redo log buffer to
the redo log files on disk, along with the transaction’s SCN. This is the point at which a commit
is considered complete in Oracle.
3. Any locks that Oracle holds are released, and Oracle marks the transaction as complete.
===============================================================================
Oracle Database issues an implicit COMMIT before and after any data definition language (DDL) statement. Oracle recommends that you explicitly end every transaction in your application programs with a COMMIT or ROLLBACK statement, including the last transaction, before disconnecting from Oracle Database. If you do not explicitly commit the transaction and the program terminates abnormally, then the last uncommitted transaction is automatically rolled back.
Until you commit a transaction:
· You can see any changes you have made during the transaction by querying the modified tables, but other users cannot see the changes. After you commit the transaction, the changes are visible to other users' statements that execute after the commit
· You can roll back (undo) any changes made during the transaction with the ROLLBACK statement
Note:
Most of the people think that when we type commit data or changes of what you have made has been written to data files, but this is wrong when you type commit it means that you are saying that your job has been completed and respective verification will be done by oracle engine that means it checks whether your transaction achieved consistency when it finds ok it sends a commit message to the user from log buffer but not from data buffer, so after writing data in log buffer it insists data buffer to write data in to data files, this is how it works.
Before a transaction that modifies data is committed, the following has occurred:
· Oracle has generated undo information. The undo information contains the old data values changed by the SQL statements of the transaction
· Oracle has generated redo log entries in the redo log buffer of the System Global Area (SGA). The redo log record contains the change to the data block and the change to the rollback block. These changes may go to disk before a transaction is committed
· The changes have been made to the database buffers of the SGA. These changes may go to disk before a transaction is committed
Note:
The data changes for a committed transaction, stored in the database buffers of the SGA, are not necessarily written immediately to the data files by the database writer (DBWn) background process. This writing takes place when it is most efficient for the database to do so. It can happen before the transaction commits or, alternatively, it can happen some times after the transaction commits.
When a transaction is committed, the following occurs:
1. The internal transaction table for the associated undo table space records that the transaction has committed, and the corresponding unique system change number (SCN) of the transaction is assigned and recorded in the table
2. The log writer process (LGWR) writes redo log entries in the SGA's redo log buffers to the redo log file. It also writes the transaction's SCN to the redo log file. This atomic event constitutes the commit of the transaction
Note:
The default behavior is for LGWR to write redo to the online redo log files synchronously and for transactions to wait for the redo to go to disk before returning a commit to the user. However, for lower transaction commit latency application developers can specify that redo be written asynchronously and that transaction do not need to wait for the redo to be on disk.
The syntax of Commit Statement is
COMMIT [WORK] [COMMENT ‘your comment’];
· WORK is optional.
The WORK keyword is supported for compliance with standard SQL. The statements COMMIT and COMMIT WORK are equivalent.
Examples
Committing an Insert
INSERT INTO table_name VALUES (val1, val2);
COMMIT WORK;
· COMMENT
Comment is also optional. This clause is supported for backward compatibility. Oracle recommends that you used named transactions instead of commit comments. Specify a comment to be associated with the current transaction. The 'text' is a quoted literal of up to 255 bytes that Oracle Database stores in the data dictionary view DBA_2PC_PENDING along with the transaction ID if a distributed transaction becomes in doubt. This comment can help you diagnose the failure of a distributed transaction.
Examples
The following statement commits the current transaction and associates a comment with it:
COMMIT
COMMENT 'In-doubt transaction Code 36, Call (415) 555-2637';
Use this clause to specify the priority with which the redo information generated by the commit operation is written to the redo log. This clause can improve performance by reducing latency, thus eliminating the wait for an I/O to the redo log. Use this clause to improve response time in environments with stringent response time requirements where the following conditions apply:
The volume of update transactions is large, requiring that the redo log be written to disk frequently.
The application can tolerate the loss of an asynchronously committed transaction.
The latency contributed by waiting for the redo log write to occur contributes significantly to overall response time.
You can specify the WAIT | NOWAIT and IMMEDIATE | BATCH clauses in any order.
Examples
To commit the same insert operation and instruct the database to buffer the change to the redo log, without initiating disk I/O, use the following COMMIT statement:
COMMIT WRITE BATCH;
Note:
If you omit this clause, then the behavior of the commit operation is controlled by the COMMIT_WRITE initialization parameter, if it has been set. The default value of the parameter is the same as the default for this clause. Therefore, if the parameter has not been set and you omit this clause, then commit records are written to disk before control is returned to the user.
The WAIT parameter ensures that the commit will return only after the corresponding redo is persistent in the online redo log. Whether in BATCH or IMMEDIATE mode, when the client receives a successful return from this COMMIT statement, the transaction has been committed to durable media. A crash occurring after a successful write to the log can prevent the success message from returning to the client. In this case the client cannot tell whether or not the transaction committed.
The NOWAIT parameter causes the commit to return to the client whether or not the write to the redo log has completed. This behavior can increase transaction throughput. With the WAIT parameter, if the commit message is received, then you can be sure that no data has been lost.
Caution:
With NOWAIT, a crash occurring after the commit message is received, but before the redo log record(s) are written, can falsely indicate to a transaction that its changes are persistent.
If you omit this clause, then the transaction commits with the WAIT behavior.
The IMMEDIATE parameter causes the log writer process (LGWR) to write the transaction's redo information to the log. This operation option forces a disk I/O, so it can reduce transaction throughput.
The BATCH parameter causes the redo to be buffered to the redo log, along with other concurrently executing transactions. When sufficient redo information is collected, a disk write of the redo log is initiated. This behavior is called "group commit", as redo for multiple transactions is written to the log in a single I/O operation.
If you omit this clause, then the transaction commits with the IMMEDIATE behavior.
Use this clause to manually commit an in-doubt distributed transaction or a corrupt transaction.
· In a distributed database system, the FORCE string [, integer] clause lets you manually commit an in-doubt distributed transaction. The transaction is identified by the 'string' containing its local or global transaction ID. To find the IDs of such transactions, query the data dictionary view DBA_2PC_PENDING. You can use integer to specifically assign the transaction a system change number (SCN). If you omit integer, then the transaction is committed using the current SCN.
· The FORCE CORRUPT_XID 'string' clause lets you manually commit a single corrupt transaction, where string is the ID of the corrupt transaction. Query the V$CORRUPT_XID_LIST data dictionary view to find the transaction IDs of corrupt transactions. You must have DBA privileges to view the V$CORRUPT_XID_LIST and to specify this clause.
· Specify FORCE CORRUPT_XID_ALL to manually commit all corrupt transactions. You must have DBA privileges to specify this clause.
Examples
Forcing an in doubt transaction. Example The following statement manually commits a hypothetical in-doubt distributed transaction. Query the V$CORRUPT_XID_LIST data dictionary view to find the transaction IDs of corrupt transactions. You must have DBA privileges to view the V$CORRUPT_XID_LIST and to issue this statement.
COMMIT FORCE '22.57.53';
=========================================================
Comments
Post a Comment
Oracle DBA Information