A large number of incorrect information was found in the SQL Server Agent log for the log of job execution failures
From the content of the log, it is impossible to connect to the storage engine during job execution.
It is strange that the storage engine is the native, and has started normally, the content of the hidden is the name of the server, why the SQL Agent is not connected to the machine?
First of all think of a question is: will this machine name corresponding to not the native IP and other machines, so not connected?
So I changed the Hosts file, mapped the machine name to 127.0.0.1, and the result of Ping machine name is 127.0.0.1, then rerun the job, or error, tragedy,
Could it be that the SQL agent of this machine could not recognize the machine name and use IP?
This problem I do not know how to verify, but I think of a workaround, I created a UDL file in this machine, found in the connection tag in the server host name to connect to the database, the same error is reported, but also can not find the instance, but changed to 127.0.0.1 or "." Just fine, (note: There is no problem in SSMs, either host name or IP, you can access the database)
Therefore, the operating system may be an exception to the environment, resulting in SQL SERVR agent and UDL can not access the host name to the storage engine,
To find the cause (but not the root cause), start to solve the problem, right-click the SQL Server Agent service, select "Connect" in the properties, and then modify the local host Server alias (default is empty) to IP, click OK, rerun the job, problem solved.
Although this problem has been solved, but there are still two questions not resolved, please ask the reader to answer it:
1. Why the SQL Agent service suddenly does not have access to the storage engine through the host name
2.SSMS Why is it possible to access the storage engine through host name and IP, unlike the way the proxy service accesses the database?
"Case sharing" SQL job service does not connect to the storage engine