In Oracle distributed transactions, the three most distributed stages are submitted first.

Before learning about Oracle distributed transactions, we need to clarify several concepts, which is necessary for us to better master Oracle distributed transactions. Next, let's look at a few

Before learning about Oracle distributed transactions, we need to clarify several concepts, which is necessary for us to better master Oracle distributed transactions. Next, let's look at a few

Before learning about Oracle distributed transactions, we need to clarify several concepts, which is necessary for us to better master Oracle distributed transactions. Next, let's first look at several concepts and then learn the three phases of Oracle distributed transactions.

1) Local Coordinator: in Oracle distributed transactions, you must refer to the data on other nodes to complete this part of the site.
2) Global Coordinator: The initiator of the Oracle distributed transaction, responsible for coordinating the distributed transaction.
3) Commit Point Site: the Site that first executes the COMMIT or ROLLBACK operation in Oracle distributed transactions. Generally, the Site that stores key data should be used as the Commit Point Site. Because the Commit Point Site is different from other sites and never enters the prepared State, there is no IN-DOUBT transaction.

You can set the initialization parameter COMMIT_POINT_STRENGTH. in Oracle distributed transactions, the Commit Point Site is determined based on the size of this value. The status information of Oracle distributed transactions also exists in the database. Generally, the key database is used as the commit point site, and the database with a high value of commit_point_strength is the commit point site. In Oracle distributed transactions, the three most distributed stages are submitted first.

The two-phase commit of Oracle distributed transactions is divided into three processes:

1. PREPARE the Oracle distributed transaction (prepare phase)
· The local database Global Coordinator sends a COMMIT notification to other databases
· Compare the SCN numbers of all databases and use the highest SCN number as the global SCN Number of the Oracle Distributed Transaction
· Write online logs to all databases
· Add a distribution lock to the table modified by Oracle distributed transactions to prevent reading and writing
· Databases send prepared notifications to Global Coordinator
All databases involved in Oracle distributed transactions must undergo the above preparations before they can enter the next stage.

2. commit phase of Oracle distributed transactions (commit phase)
· The local database Global Coordinator notifies the commit point site to be submitted first. After the commit point site is submitted, release the resources it occupies and notify Global Coordinator to complete the submission.
· Local database Global Coordinator notifies other databases to submit
· The commit node adds a message to the log, indicating that the Oracle distributed transaction has been committed and Global Coordinator is notified. At this time, the data of all databases remains consistent.

3. FORGET PHASE)
· Local database Global Coordinator notifies commit point site that all databases have been submitted
· Commit point site clears records and status information of Oracle distributed transactions and notifies Global Coordinator
· Global Coordinator clears records and status information of local Oracle distributed transactions
At this time, the two-phase commit of Oracle distributed transactions is complete.

If an exception occurs in the database or network before the Oracle distributed transaction is committed in two phases, the application reports an error and the Oracle distributed transaction is in the IN_DOUBT state. Once the database or network returns to normal, the system (reco process) automatically processes Oracle distributed transactions in the IN_DOUBT state. IN some cases, the administrator needs to manually handle Oracle distributed transactions IN the IN_DOUBT state: · IN _ DOUBT State Oracle distributed transactions, locking key tables, resulting IN application failure.