I have some SSIS jobs running in the production server which we usually take that server by Windows' Remote Desktop Connection to monitor the jobs. The problem in our case is If we sign out the server in remote connection, all the sql server jobs getting failed until we reestablish a remote connection but the jobs work fine if we close the remote connection explicitly by the (x) mark on the Remote Connection interface
Any idea on this issue
Presumably those jobs are being executed under the current users account rather than a system service account ? I suspect the problem is that "signing out" essentially logs the current user off the box, terminating all their current processes, whereas just closing the RDP session does not log them out and so the job continues running.
Related
I have an application that runs 24/7 and is connected to an sql database (sql server).
However, the application crashes most night with the following error message
*An existing connection was forcibly closed by the remote host.
*
the db resides on a different server than the application, so I first suspected a network connectivity issue that happened at night.
I ran a script overnight, to ping the db server every 5 minutes and tell me if there were such network connectivity loss, but over the course of 1 week, I only had 1 failed ping.
My next guess is that there could be a database connectivity issue, but i am not sure how I can automate a similar test on the database connection itself (I do not have access to the database server).
I created a UDL file, to test my connection manually (and that works fine), but I would like to such a test to run every 5 minutes overnight, and let me know in a log file, if and when the connection may have failed.
Thanks for your help!
ran script to test network connectivity overnight between appl and db server.
Network connection seems good 24/7 between the application and the db server.
I would now like to run a similar test at 1 or 5 minutes internals on the db connection itself, but I am unaware of how to do that.
I can test manually with a udl file, but I need to help to automate the test and output results in a log file.
Thanks
I have a dotnet exe app in a server which runs in sql server. during the factory production time my application were unable to connect to db for 1 to 2 minutes and then it gains connectivity at this unresponsive time when i accessed sql server management studio, i got the below error:
Taken from the answer over here.
This usually happens when there are too many open transactions that are blocking read access to your database server. You can try restart your server which will usually solve the issue.
I have a web application using a SQL Server account, and recently started getting intermittent:
Login failed for user 'xxxx'. Reason: Password did not match that for the login provided. [CLIENT: <local machine>].
The login works >99% of the time.
Server is in mixed mode, uses a SQL Server account, and the box is not a member of a domain, and is not part of any farm.
The password has not been changed for the account since initial
deployment which occurred months ago and the box has been bounced
several times since.
IIS and SQL Server are on the same box.
TCP is the selected communications method.
SQL Server 2016
Windows Server 2012
I have had a problem in the past with a desktop application and connection pooling where if a connection in the pool became invalid for some reason, the app failed when it went to use it. But we got a different errors in that situation.
Before you suggest that a pooling issue is at play, consider the following:
If there were a problem with pooling, why would the connection be attempted at all? Once a connection is in the pool, the connection attempt doesn't show up in the SQL Log, it just gets reused. If the connection was bad, and the application tried to use it, then the application would receive an exception reflecting that problem--the connection doesn't try to log in to the server again.
If this is an effort to spin up a new connection via the pool, why would it succeed the first time, then fail on a subsequent time, and then succeed again? It can't be user error since the connection string is in the web.config.
Here is a picture of the SQL Log entries for the login problem.
Succeeded at 8:47
Failed at 8:58
Succeeded at 9:10
I would love to say that I actually solved the root problem, however the answer to this was to switch to a local NT user account.
After turning off pooling to eliminate it from the equation, I was still getting intermittent login failures using a SQL account, despite it being in the web.config. The app pool was set to never recycle, so I was at a standstill with regard to solving the situation.
Out of desperation I changed the login to use a trusted connection, and everything worked flawlessly. (I haven't turned pooling back on yet.)
Got a question on SQL Server 2012 Management Studio.
Is there a way to set up/customize the Management Studio so that if I don't use it for 30 minutes (approximately) it won't boot me out of the application and make me sign in all over again?
I don't want to keep it on forever, but an extra 30 minutes/1 hour would be nice. Not sure if that's possible.
You can use sp_who or sp_who2 to see what your SPID is while connected. If your management studio is connected you will show up as a user in the list. If something is killing your connection it is either your client configuration at connection time (connection timeout) or something configured to kill connections at the server (Group Policy on the network). By default your connection just goes into "Sleeping" status if no client connection timeout is issued at the time of connection. Connections don't typically get killed because it affects caching session for that spid to just drop it.
I'm connecting to a remote sql server instance with the following connection string
"Network Library=DBMSSOCN;Data Source=xx.xxx.x.xxx,1433;Initial Catalog=MyDatabase;User Id=MyUserId;Password=MyPassword;Connect Timeout=120;"
Sql Server Browser is running
Local and remote connections are allowed using TCP/IP only
The application randomly fails to connect citing the following SqlException
TCP Provider, error: 0 - A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
Code to connect as follows
using (SqlConnection connection = new SqlConnection(m_ConnectionString))
{
connection.Open(); // falls over here
}
I thought about Firewall config on port 1433 but why would the Firewall sometimes permit connections and sometimes not?
Is Sql Server Agent required to be running? And if so why as the description of Sql Server Agent on MSDN is not obvious in this respect?
Thanks!
EDIT: Tried adding an explicit rule on the Firewall to open up 1433 and so far so good, but could be randomness again so hard to say if I fix or not yet
No, SQL Server Agent does not need to be running. SQL Server agent is only needed to execute scheduled tasks on the SQL server.
This is probably a network issue. Can you ping the server? If so, try to ping it continuously with /t and see if all packets arrive.
It could also be a problem with the SQL server load. Is the server idle or under load?
Could you test the application locally on the SQL server or on the same LAN to see if the problem persists?
Well you don't need SQL Server Agent running now, the error suggest you are getting a timeout from the scenario.
There are various reasons why you may be blocked. Perhaps the firewall is configured to allow only a certain number of connections at a port at one time. Or the database itself is limiting the number of connections. Your internet is slow and you are hitting the 120 seconds timeout. The list goes on. :)
Your SQL Server database is going to sleep. The first time you try to connect to it, it has to restart and your connection times out.
Make sure the option "Auto Close" is set to "False". This prevents it from shutting itself down after the last connection is closed.
http://itknowledgeexchange.techtarget.com/sql-server/auto-close-is-almost-as-bad-as-auto-grow/