Database Reference
In-Depth Information
Row 1 fetched. Hit enter to continue fetching ...
FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER
------------- --------------- -----------
SELECT BASIC YES
1 Row(s) processed.
The value of
V$SESSION.FAILED_OVER
was previously
NO
and is now
YES
. This confirms that
TAF succeeded. How about the remaining properties of the previous database session? They
are all lost. Date format, client identifier, module, and action now have default values.
DBB> SELECT sid, serial#, audsid, logon_time, client_identifier,
module, action
FROM v$session
WHERE username='APP_USER'
/
Row 1 fetched. Hit enter to continue fetching ...
SID SERIAL# AUDSID LOGON_TIME CLIENT_IDENTIFIER MODULE ACTION
--- ------- ------ ------------------- ----------------- -------- ------
133 15197 110008 05.08.2007 14:49:23 perl.exe
1 Row(s) processed.
The auditing identifier of the new session is 110008. Perl DBI automatically registers the
module name
perl.exe
with the DBMS.
Failover at the End of a Transaction
While we're at it, we might also verify that
DISCONNECT
SESSION
POST_TRANSACTION
allows ongoing
transactions to complete and then initiates session reestablishment through TAF. A test case
for such a scenario follows:
1.
Starts a transaction by deleting a row.
Runs another
DELETE
statement that blocks on a TX enqueue due to a row locked by
another session.
2.
3.
Gets marked for disconnection while waiting for the lock.
4.
Succeeds in finishing the transaction and reconnects.
The first step of the scenario is to start a transaction with
DELETE
.
DBB> DELETE FROM hr.employees WHERE employee_id=190
/
1 Row(s) Processed.
As a DBA using SQL*Plus (or
dbb.pl
, in case you appreciate its automatic column sizing
feature), check that APP_USER has an open transaction and lock the row with
EMPLOYEE_ID=180
in
HR.EMPLOYEES.
5
5.
An export dump containing the sample schema HR is included in the source code depot.
