|
Problem IC66791
|
Status: Geschlossen |
AFTER MULTIPLE IMMEDIATE TAKEOVERS (IN A WHILE LOOP) THE SUBSEQU ENT TAKEOVER GETS AN ERROR SQL1035N (DATABASE CURRENTLY IN USE.) |
| Produkt: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problembeschreibung: |
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-Zusammenfassung: |
****************************************************************
* 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: |
|
| verfügbare FixPacks: |
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
|
| Lösung |
we fix the problem in db2 v97fp2. Takeovers after error SQL1776N
will get rid of SQL1035 and eventually will succeed. |
| Workaround |
keiner bekannt / siehe Local-Fix |
| Bug-Verfolgung |
Vorgänger : APAR is sysrouted TO one or more of the following: IC66908
Nachfolger : |
| Weitere Daten |
Datum - Problem gemeldet :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
| 02.03.2010
24.03.2010
24.03.2010 |
| Problem behoben ab folgender Versionen (IBM BugInfos) |
9.7.FP2
|
| Problem behoben lt. FixList in der Version |
| 9.7.0.2
|
 |
