|
Problem IC66791
|
Status: Closed |
AFTER MULTIPLE IMMEDIATE TAKEOVERS (IN A WHILE LOOP) THE SUBSEQU ENT TAKEOVER GETS AN ERROR SQL1035N (DATABASE CURRENTLY IN USE.) |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
With an HADR pair set up, If multiple takeover are issued in a
tight loop on both primary and standby, db is then put into "db
is in use" state and subsequent deactivate or takeover requests
get back an error SQL1035.
This issue appears right after the takeover gets back an error
SQL1776N The command cannot be issued on an HADR standby
database. Reason code = "2".
A snapshot output of the while loop run --
DB20000I The TAKEOVER HADR ON DATABASE command completed
successfully.
SQL1770N Takeover HADR cannot complete. Reason code = "4".
SQL1770N Takeover HADR cannot complete. Reason code = "4".
SQL1770N Takeover HADR cannot complete. Reason code = "4".
SQL1776N The command cannot be issued on an HADR standby
database. Reason
code = "2".
SQL1035N The database is currently in use. SQLSTATE=57019
SQL1035N The database is currently in use. SQLSTATE=57019
SQL1035N The database is currently in use. SQLSTATE=57019
SQL1035N The database is currently in use. SQLSTATE=57019
SQL1035N The database is currently in use. SQLSTATE=57019 |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* any hadrware with release before db2 v97fp2 *
****************************************************************
* PROBLEM DESCRIPTION: *
* With an HADR pair set up, If multiple takeover are issued in *
* a tight loop on both primary and standby, db is then put *
* into "db is in use" state and subsequent deactivate or *
* takeover requests get back an error SQL1035. *
* This issue is right after the takeover gets back an error *
* SQL1776N The command cannot be issued on an HADR standby *
* database. Reason code = "2". *
****************************************************************
* RECOMMENDATION: *
* upgrade to db2 v97fp2 *
**************************************************************** |
| Local Fix: |
|
| available fix packs: |
DB2 Version 9.7 Fix Pack 2 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
we fix the problem in db2 v97fp2. Takeovers after error SQL1776N
will get rid of SQL1035 and eventually will succeed. |
| Workaround |
not known / see Local fix |
| BUG-Tracking |
forerunner : APAR is sysrouted TO one or more of the following: IC66908
follow-up : |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 02.03.2010
24.03.2010
24.03.2010 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FP2
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.2
|
 |
