Arcserve / SQL errors 8542 & 8563

[jwpbwt1]

Hope that someone out there can help me w/ this unreproduceable Arcserve issue. A little background. All servers in SAN are NT4sp6a, Arcserve 2000 AE is fully patched.
A while back when backing up a SQL DB, I received the following error in AS job log.
E8542 Failed to receive data from SQL server database agent (ec=10054) and then
E8563 Failed to send data to SQL server database agent.

All SQL db's on that server generated the same error. Of course, there is nothing in SQL server log. Computer Associates response was to cycle SAN, which of course is not the fix.

This cannot be reproduced, but I really need to find out why this happened.
Any thoughts would be appreciated.

Thank You
John

 

[mohamdr]

Hi
No there SQL log you need to go to SQL server machine
and out the agent in debug mode by changing it to 3.

I can't remember the path now but go to Registry and DSAAGENT and select SQL and chnage it you can find it in the doc fodlder on the cd or relase notes it will generate log file in sql agent path paste the error in the thread.

regards,
moahmdr

 

[jwpbwt1]

Thanks,
But this does not tell me what caused this to occur 1 time (and if "planets are aligned properly", it could happen again)

 

[xenotec]

10054 is actually a TCP error...
If the backup had worked previous then there may be an issue with the NIC. Re-cycling the Server may have corrected any problems with the NIC

If it happens again try deleting re-adding the SQL server object using IP address in the backup manager

 

[ACiDelic]

xenotec is correct, 10054 is a network error. However, adding the machine using IP address will not help. You are not supposed to backup the SQL agent using IP address. I believe this is stated in the release notes.

If you are getting random network errors such as 10054 then you network is most likely the cause. In most cases upgrading the NIC driver on both your ARCserve server and your SQL server will clear up network errors. If it is a hardware problem then you may need to replace the hardware.

BTW any network errors encountered during the backup will cause the backup to fail. There is no retry logic if a network error occurs.

 

[jwpbwt1]

Thanks.

I appreciate the insight, and will look into it.

This was a 1 time error, and of course, cannot be reproduced (as that would make my life easier)

 

[dydhda]

I am having exactly the same problem as jwpbwt1, my GFS is failing to backup a SQLserver with E8452 and E8563 as described above, although this happens every time I try to run a backup of the SQL server. (During the GFS or during one off manual backups)

I have set debug to level 3 as moahmdr suggested but still nothing is being written to the the SQLagent log.

I have changed the server that runs the backup - this seems to have caused the problem - although the new server is exactly the same as the old one in terms of domain, subnet and even IP address (the only difference is the machine name).

I have reinstalled the SQLserver agent on the SQL server and have now run out of ideas...

Any help would be gratefully received, dydhda

 

[dydhda]

Sorry - I have realised the debug agent writes to a different log file, dbasql.trc, (see previous post) which I have now located and discovered the following error:

Windows Sockets bind() error.(183)

As before, any advice would be appreciated. Thanks, dydhda

 

[davidmichel]

10054 and 10060 are the most popular error codes.
They are WinSock errors and of not much help in tracking down the problem.

jwpbwt1 - In your case it was not just a blip but a sustained problem that continued to prevent the communication between the ARCserve server and the DB Agent. Keep in mind SAN or no SAN DB Agents communicate via the IP network connection. It could have been a problem with the agent or the network. At the time did you check the agent to see if it was up and running? Does the agent log show any activity at the time? If all looks fine then look to the network.

dydhda - your case is very different in that it consisently fails. Run a test backup of non-SQL data on the drive. Do it with and without the client agent. If it works fine, then you know the problem is specific to the DB Agent.