Oracle9i Supplied PL/SQL Packages and Types Reference Release 2 (9.2) Part Number A96612-01 |
|
DBMS_TRANSACTION , 2 of 2
Subprogram |
---|
This procedure is equivalent to following SQL statement:
SET TRANSACTION READ ONLY
DBMS_TRANSACTION.READ_ONLY;
This procedure is equivalent to following SQL statement:
SET TRANSACTION READ WRITE
DBMS_TRANSACTION.READ_WRITE;
This procedure is equivalent to following SQL statement:
ALTER SESSION ADVISE ROLLBACK
DBMS_TRANSACTION.ADVISE_ROLLBACK;
This procedure is equivalent to following SQL statement:
ALTER SESSION ADVISE NOTHING
DBMS_TRANSACTION.ADVISE_NOTHING;
This procedure is equivalent to following SQL statement:
ALTER SESSION ADVISE COMMIT
DBMS_TRANSACTION.ADVISE_COMMIT;
This procedure is equivalent to following SQL statement:
SET TRANSACTION USE ROLLBACK SEGMENT <rb_seg_name>
DBMS_TRANSACTION.USE_ROLLBACK_SEGMENT ( rb_name VARCHAR2);
Parameter | Description |
---|---|
rb_name |
Name of rollback segment to use. |
This procedure is equivalent to following SQL statement:
COMMIT COMMENT
<text>
DBMS_TRANSACTION.COMMIT_COMMENT ( cmnt VARCHAR2);
Parameter | Description |
---|---|
cmnt |
Comment to associate with this commit. |
This procedure is equivalent to following SQL statement:
COMMIT FORCE <text>, <number>"
DBMS_TRANSACTION.COMMIT_FORCE ( xid VARCHAR2, scn VARCHAR2 DEFAULT NULL);
Parameter | Description |
---|---|
xid |
Local or global transaction ID. |
scn |
System change number. |
This procedure is equivalent to following SQL statement:
COMMIT
Here for completeness. This is already implemented as part of PL/SQL.
DBMS_TRANSACTION.COMMIT;
This procedure is equivalent to following SQL statement:
SAVEPOINT <savepoint_name>
Here for completeness. This is already implemented as part of PL/SQL.
DBMS_TRANSACTION.SAVEPOINT ( savept VARCHAR2);
Parameter | Description |
---|---|
savept |
Savepoint identifier. |
This procedure is equivalent to following SQL statement:
ROLLBACK
Here for completeness. This is already implemented as part of PL/SQL.
DBMS_TRANSACTION.ROLLBACK;
This procedure is equivalent to following SQL statement:
ROLLBACK TO SAVEPOINT <savepoint_name>
Here for completeness. This is already implemented as part of PL/SQL.
DBMS_TRANSACTION.ROLLBACK_SAVEPOINT ( savept VARCHAR2);
Parameter | Description |
---|---|
savept |
Savepoint identifier. |
This procedure is equivalent to following SQL statement:
ROLLBACK FORCE <text>
DBMS_TRANSACTION.ROLLBACK_FORCE ( xid VARCHAR2);
Parameter | Description |
---|---|
xid |
Local or global transaction ID. |
This procedure sets "discrete transaction mode" for this transaction.
DBMS_TRANSACTION.BEGIN_DISCRETE_TRANSACTION;
DISCRETE_TRANSACTION_FAILED exception; pragma exception_init(DISCRETE_TRANSACTION_FAILED, -8175); CONSISTENT_READ_FAILURE exception; pragma exception_init(CONSISTENT_READ_FAILURE, -8176);
When in-doubt transactions are forced to commit or rollback (instead of letting automatic recovery resolve their outcomes), there is a possibility that a transaction can have a mixed outcome: Some sites commit, and others rollback. Such inconsistency cannot be resolved automatically by Oracle; however, Oracle flags entries in DBA_2PC_PENDING
by setting the MIXED
column to a value of 'yes'.
Oracle never automatically deletes information about a mixed outcome transaction. When the application or DBA is certain that all inconsistencies that might have arisen as a result of the mixed transaction have been resolved, this procedure can be used to delete the information about a given mixed outcome transaction.
DBMS_TRANSACTION.PURGE_MIXED ( xid VARCHAR2);
Parameter | Description |
---|---|
xid |
Must be set to the value of the |
When a failure occurs during commit processing, automatic recovery consistently resolves the results at all sites involved in the transaction. However, if the remote database is destroyed or re-created before recovery completes, then the entries used to control recovery in DBA_2PC_PENDING
and associated tables are never removed, and recovery will periodically retry. Procedure PURGE_LOST_DB_ENTRY
enables removal of such transactions from the local site.
DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY ( xid VARCHAR2);
WARNING: PURGE_LOST_DB_ENTRY should only be used when the other database is lost or has been re-created. Any other use may leave the other database in an unrecoverable or inconsistent state. |
Before automatic recovery runs, the transaction may show up in DBA_2PC_PENDING
as state "collecting", "committed", or "prepared". If the DBA has forced an in-doubt transaction to have a particular result by using "commit force" or "rollback force", then states "forced commit" or "forced rollback" may also appear. Automatic recovery normally deletes entries in any of these states. The only exception is when recovery finds a forced transaction which is in a state inconsistent with other sites in the transaction; in this case, the entry is left in the table and the MIXED
column has the value 'yes'.
However, under certain conditions, it may not be possible for automatic recovery to run. For example, a remote database may have been permanently lost. Even if it is re-created, it gets a new database ID, so that recovery cannot identify it (a possible symptom is ORA-02062
). In this case, the DBA may use the procedure PURGE_LOST_DB_ENTRY
to clean up the entries in any state other than "prepared". The DBA does not need to be in any particular hurry to resolve these entries, because they are not holding any database resources.
The following table indicates what the various states indicate about the transaction and what the DBA actions should be:
NOTE 2: Examine and take any manual action to remove inconsistencies; then use the procedure |
Parameter | Description |
---|---|
xid |
Must be set to the value of the |
This function returns the local (to instance) unique identifier for current transaction. It returns null if there is no current transaction.
DBMS_TRANSACTION.LOCAL_TRANSACTION_ID ( create_transaction BOOLEAN := FALSE) RETURN VARCHAR2;
Parameter | Description |
---|---|
create_transaction |
If true, then start a transaction if one is not currently active. |
This function returns local (to local transaction) unique positive integer that orders the DML operations of a transaction.
DBMS_TRANSACTION.STEP_ID RETURN NUMBER;
|
Copyright © 2000, 2002 Oracle Corporation. All Rights Reserved. |
|