Troubleshooting
Problem
"FedStart Failed" is reported in db2diag.log at certain intervals (about every 2 hours). Sometimes resulting in poor performance or running out of some resource at a data source.
Symptom
"FedStart Failed" show in db2diag.log at certain intervals (about 2 hours). You see automatic queries against all columns in all nicknames in all DB2 federated databases, sometimes resulting in poor performance or running out of some resource (for example, temporary storage) at a data source.
The error messages looks similar to the following:
2010-12-27-10.09.15.742656-360 I1383626A520 LEVEL: Error
PID : 655950 TID : 2572 PROC : db2sysc
INSTANCE: iidev20 NODE : 000 DB : DBXXXXXX
APPHDL : 0-1448 APPID: *LOCAL.iidev20.101227160916
AUTHID : AUTHXXXX
EDUID : 2572 EDUNAME: db2agent (DBXXXXXX)
FUNCTION: DB2 UDB, Query Gateway, sqlqgPassthruPrepare, probe:30
MESSAGE : ZRC=0x80260160=-2144992928=SQLQG_ERROR "Error constant for gateway."
DATA #1 : String, 15 bytes
FedStart Failed
Cause
When health monitor or auto table maintenance is turned on. To collect statistics, a certain DB2 internal process will try to access all remote data sources specified by server objects in passthru mode.
Periodically "FedStart Failed" may be caused by several reasons:
1) there are obsolete server objects in user's catalog (not used in applications, and the connection to the servers is broken)
2) incorrect user mapping or no user mapping is set for the server object so that the remote user name or password is wrong.
3) the user name and password are same for federated database and data source database but there is no user mapping defined for the server object. Accessing nicknames or remote tables in passthru will fail, even if the federated database and the data source database reside in the same DB2 instance.
Usually, when no user mapping defined, Federation Server will try to use the inbound credential to access remote database. The inbound credential is available if user explicitly specify username/password when connect to the federated database, as shown in below diagram.
(user/passwd) (user/passwd)
Client -----------> federated db ------------> data source db
inbound outbound
When health monitor or auto table maintenance initiates the task, it will be something like below.
A DB2 internal process ---> federated db ---> data source db
Note: The 'DB2 internal process' referenced above is one working for the federated database and here Federation Server acts as a client to the data source database.
When no explicit user name/password can be received from the DB2 internal process, DB2 performs user authentication by a security facility outside the database system (such as OS). This means DB2 will send the user name and password to outside facility for validation when the credential is provided in the connection request. However, DB2 cannot retrieve the password back from that outside facility.
If there is no user mapping defined, health monitor or auto table maintenance may not work correctly as it is not possible for Federation Server to get right user name and password for accessing the data source database.
Resolving The Problem
First of all, these messages can usually be ignored.
To get rid of the messages, try below operations:
1) Remove obsolete server object or make sure the connection to corresponding data source is available. You can check all server options by issuing the following SQL statement:
SELECT * FROM SYSCAT.SERVEROPTIONS
2) Create user mapping for all server objects even if the user name and password are same for federated database and data source database.
3) Check and turn off the health indicators for Federation:
db.fed_servers_op_status
db.fed_nicknames_op_status
db.tb_runstats_req
To turn off the two health indicators, using below SQL statements:
UPDATE ALERT CONFIGURATION FOR DATABASE ON FEDDB USING db.fed_servers_op_status SET THRESHOLDSCHECKED NO
UPDATE ALERT CONFIGURATION FOR DATABASE ON FEDDB USING db.fed_nicknames_op_status SET THRESHOLDSCHECKED NO
UPDATE ALERT CONFIGURATION FOR DATABASE ON FEDDB USING db.tb_runstats_req SET THRESHOLDSCHECKED NO
4) Turn off the auto_runstats database configuration parameter by issuing below SQL statement:
UPDATE DB CFG FOR FEDDB USING AUTO_RUNSTATS OFF
5) Leave auto_runstats on but change auto_runstats maintenance policy to exclude nicknames. This can be done using an IBM-provided stored procedure. For information on the stored procedure, see
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.admin.ha.doc/doc/t0051354.html
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21459247