Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

274
CHAPTER 8 ■ TRANSACTIONS
that knows the outcome of the transaction, and it is now responsible for broadcasting the outcome
to the other sites. If an error occurs right now—the network fails, Site 1 loses power,
whatever—Site 2 and Site 3 will be left “hanging.” They will have what is known as an in-doubt
distributed transaction. The 2PC protocol attempts to close the window of error as much as
possible, but it cannot close it entirely. Sites 2 and 3 must keep that transaction open, awaiting
notification from Site 1 of the outcome. If you recall from the architecture discussion in
Chapter 5, it is the function of the RECO process to resolve this issue. This is also where the
COMMIT and ROLLBACK with the FORCE option come into play. If the cause of the problem was a
network failure between Sites 1, 2, and 3, then the DBAs at Sites 2 and 3 could actually call
the DBA at Site 1, ask him for the outcome, and apply the commit or rollback manually, as
appropriate.
There are some, but not many, limitations to what you can do in a distributed transaction,
and they are reasonable (to me, they seem reasonable anyway). The big ones are as follows:
• You cannot issue a COMMIT over a database link. That is, you cannot issue a
COMMIT@remote_site. You may commit only from the site that initiated the transaction.
• You cannot do DDL over a database link. This is a direct result of the preceding issue.
DDL commits. You cannot commit from any other site other then the initiating site,
hence you cannot do DDL over a database link.
• You cannot issue a SAVEPOINT over a database link. In short, you cannot issue any transaction
control statements over a database link. All transaction control is inherited from
the session that opened the database link in the first place; you cannot have different
transaction controls in place in the distributed instances in your transaction.
The lack of transaction control over a database link is reasonable, since the initiating site
is the only one that has a list of everyone involved in the transaction. If in our three-site configuration,
Site 2 attempted to commit, it would have no way of knowing that Site 3 was
involved. In Oracle, only Site 1 can issue the commit command. At that point, it is then permissible
for Site 1 to delegate responsibility for distributed transaction control to another site.
We can influence which site will be the actual commit site by setting the COMMIT_POINT_
STRENGTH (a parameter) of the site. A commit-point strength associates a relative level of
importance to a server in a distributed transaction. The more important the server (the more
available the data needs to be), the more probable that it will coordinate the distributed
transaction. You might want to do this in the event that you need to perform a distributed
transaction between your production machine and a test machine. Since the transaction
coordinator is never in doubt as to the outcome of a transaction, it would be best if the production
machine coordinated the distributed transaction. You do not care so much if your test
machine has some open transactions and locked resources. You certainly do care if your production
machine does.
The inability to do DDL over a database link is actually not so bad at all. First, DDL is
“rare.” You do it once at installation or during an upgrade. Production systems don’t do DDL
(well, they shouldn’t do DDL). Second, there is a method to do DDL over a database link, in
a fashion, using the job queue facility, DBMS_JOB or, in Oracle 10g, the scheduler package,
DBMS_SCHEDULER. Instead of trying to do DDL over the link, you use the link to schedule a
remote job to be executed as soon as you commit. In that fashion, the job runs on the remote
machine, is not a distributed transaction, and can do the DDL. In fact, this is the method by
which the Oracle Replication Services perform distributed DDL to do schema replication.