home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Neueste VersionenFixList
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Haben Sie Probleme? - Kontaktieren Sie uns.
Kostenlos registrieren anmeldung-x26
Kontaktformular kontakt-x26

DB2 - Problembeschreibung

Problem IC70219 Status: Geschlossen

MAKE DB2HAICU MORE ROBUST AND HAVE IT REMOVE ORPHAN RESOURCES DU RING
DB2HAICU -DELETE IF THEY STILL EXIST.

Produkt:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problembeschreibung:
If you use TSA commands to administer a HADR cluster with 
CT_MANGEMENT_SCOPE not set to 2, you could risk creating orphan 
resources which may cause db2haicu to fail. 
. 
For example, 
On HostA - 
rmrsrc -s "Name like 'db2_<instance>%' " IBM.Application 
rmrsrc -s "Name like '%' " IBM.Test 
rmrg -s "Name like 'db2_<instance>%' " 
. 
This will remove resource groups on both HostA and HostB, but 
only children resources on HostA are removed. 
. 
As a result "db2haicu -delete" will fail as it currently does 
not handle orphan resources. 
. 
The purpose of this APAR is to make db2haicu more robust and 
have it remove orphan resources for the instance in question, 
assuming the orphan  was originally created by db2haicu.
Problem-Zusammenfassung:
If you use TSA commands to administer a HADR cluster with 
CT_MANGEMENT_SCOPE not set to 2, you could risk creating orphan 
resources which may cause db2haicu to fail. 
. 
For example, 
On HostA - 
 
rmrsrc -s "Name like 'db2_<instance>%' " IBM.Application 
rmrsrc -s "Name like '%' " IBM.Test 
rmrg -s "Name like 'db2_<instance>%' " 
. 
This will remove resource groups on both HostA and HostB, but 
only children resources on HostA are removed. 
. 
As a result "db2haicu -delete" will fail as it currently does 
not handle orphan resources. 
. 
The purpose of this APAR is to make db2haicu more robust and 
have it remove orphan resources for the instance in question, 
assuming the orphan  was originally created by db2haicu.
Local-Fix:
In general, you can't delete a resource which is Online (as the 
message suggests). You should stop the instances on each 
server and then remove the resources. 
Or, you can add the Force=1 option to each remove command. For 
completeness, here are the modified instructions with the 
Force=1 option : 
As root user (from either node) : 
export CT_MANAGEMENT_SCOPE=2        <== this should be added to 
your user profile on both nodes 
rmrsrc -s "Name like '<instance>' " IBM.Application  Force=1 
rmrsrc -s "Name like '%' " IBM.Test  Force=1 
rmrg -s "Name like '<instance>' "
verfügbare FixPacks:
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 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows

Lösung
Fixed >= v97 fpk4
Workaround
In general, you can't delete a resource which is Online (as the 
message suggests). You should stop the instances on each 
server and then remove the resources. 
Or, you can add the Force=1 option to each remove command. For 
completeness, here are the modified instructions with the 
Force=1 option : 
As root user (from either node) : 
export CT_MANAGEMENT_SCOPE=2        <== this should be added to 
your user profile on both nodes 
rmrsrc -s "Name like '<instance>' " IBM.Application  Force=1 
rmrsrc -s "Name like '%' " IBM.Test  Force=1 
rmrg -s "Name like '<instance>' "
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
27.07.2010
29.04.2011
29.04.2011
Problem behoben ab folgender Versionen (IBM BugInfos)
9.7.FPk4
Problem behoben lt. FixList in der Version
9.7.0.4 FixList