DB2 Archive log backup failing

Had a client/server who was unable to do any DB2 Archive log backup. Attempts to run it would fail and when I looked into the logs the failure was seen against the key log lines below. I’ve named the log file and component where this log exists.

CommserveJobManager.log

2100 2944 02/16 11:40:11 111111 Servant [---- SCHEDULED BACKUP REQUEST ----], taskid [15821] Clnt[aaaaa003] AppType[DB2 on Unix][62] BkpSet[AA1] SubClnt[AA1_Archive_logs] BkpLevel[Full][1]

CommserveSrvDB2Agent.log

13720 26b4 02/16 11:40:16 111111 SrvDb2Agent::AgentAttach() - 1: dataAgentAttach-> HostName=aaaaa003.bbbbb.ccc*aaaaa003*8400*8402 start...
13720 26b4 02/16 11:40:16 111111 ** CVSession::attach(ulPortArg):
	- RemoteHost=aaaaa003.bbbbb.ccc.
	- RemoteProcess=todo.
	- AuthenticateClient failed. Error=9000026.

13720 26b4 02/16 11:40:16 111111 SrvDb2Agent::AgentAttach() - 0: dataAgentAttach() failed: m_cvsOA.getLastError: Err Number=9000026 sLastErr=[CVSession::authenticateClient]:Remote system [aaaaa003.bbbbb.ccc]. Failed authentication returned from server..
13720 26b4 02/16 11:40:16 111111 SrvDb2Agent::RunClient() - 0: AgentAttach() failed.
13720 26b4 02/16 11:40:16 111111 SrvDb2Agent::ExitHere() - 1: JobObjectInitialize(111111) started...

Failed authentication messages could indicate that like the message says, the network password used by the Commserve and Client to communicate is different, thus the communication fails. i.e. Client could have a network password stored on it’s configuration that doesn’t match the one for this client stored in the Commserve database.

OR

Something might be wrong with the communication between the Commserve and the Client (in either direction).

So I would recommend checking out that the communication is fine and that the Commserve is resolving the client correctly and accessing the correct IP address for the client.

If this all checks out fine, and communication from Client to CS is fine (in both directions). You might have to force a network password reset/sync. The easiest way I find to do this is to do a LOCAL uninstall on the problem client (to ensure that the backup history for client is retained in the Commserve) and perform a reinstall on the client using the Simpana DVD3 media. Ensuring to install again using the same details the client is displayed as in the Commserve. During the reinstall the network password is put in sync again.

In the case of the client here, we had to reinstall it. Post the reinstall the client and backup attempts worked fine.  This would affect all Simpana iDA’s on the client too, thus impact all backups for the client.

One thought on “DB2 Archive log backup failing

  1. michaelf Post author

    I should probably point out another situation in which I have seen the error above. An situation where Simpana 9 upgrade to Simpana 10 on a client where DB2 was/is installed. Where the DB2 instances haven’t been restarted post the upgrade. DB2 instances/services MUST be restarted during an upgrade so that the new libraries and software is being used post the upgrade or else you will get errors about network password being incorrect. Since the old libraries will be looking for old Simpana 9 regkey entries which no longer exist post the upgrade.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>