I am unable to kill some SQL Server agent jobs. The task state continues to be running and the command stays in KILLED/ROLLBACK. The job executes queries against OSI's PI system via OLEDB linked server and Oracle. The only way I have found so far to kill these jobs is by restarting SQL server (not a preferred method).
I found following article
https://connect.microsoft.com/SQLServer/feedback/details/187192/openquery-to-linked-server-hangs-leaving-spid-with-open-tran-that-cannot-be-killed-then-templog-ldf-grows-without-limit-requires-sql-server-restart-on-production-servers
Apparently several people have this issue using openquery through a linked server that is not SQL Server. I'm reposting the work-around that BReuter posted on above article:
posted by BReuter on 1/30/2007 at 2:21 PM
*I have experianced the exact behavior and have found a combination of software which stablized our environment.
There were three key ingredients I found:
1) Make sure you do not have ANY linked servers using Microsoft OLEDB Provider for Oracle, instead use Oracle Provider for Oracle(version 9.2.0.4 is what I have in production).
2) Do not allow the linked server to run "in process". This took some research, but it is possible to run the linked server out of the SQL memory space by following the directions below.
3) I'm running SQL 2005 SP1 on W2K3, but I believe the OLEDB Provider is the key and not the OS or DB version.
The default security settings are too tight to run the Oracle OLEDB provider (OraOLEDB) out-of-process. Further, the default settings for MS DTC do not allow network communication.
Control Panel-> Administrative Tools-> Component Services
Drill to Component Services-> Computers
a. Right-click My Computer-> Properties
MSDTC tab -> Security Configuration button (screenshot below)
a. Network DTC Access – checked.
b. Allow Inbound / Outbound – checked.
c. No Authentication Required – This simulates the windows 2000 security settings.
d. Enable XA transactions – the type of transaction implemented by OraOLEDB provider.
Drill to Component Services-> Computers-> My Computer-> DCOM Config
a. Right-click MSDAINITALIZE-> Properties
Security tab (screenshot below)
a. Access Permissions -> Customize.
b. Press “Access Permissions” Edit button.
c. Give the SQL Server Service account “Local Access” permission.
d. Repeat for “Launch and Activation”.*
If they are large transactions, it might be that the server is actually still performing the rollback which might take some time.
This page
http://www.jaygeiger.com/index.php/2015/03/03/how-to-kill-a-frozen-linked-sql-server-connection/
provides a workaround.
It consist in manual TCP connection termination. It's not an ideal solution but it's the best one I know. It's better than having to restart the entire SQL Server.
Btw. I found that link at https://connect.microsoft.com/SQLServer/feedback/details/187192/openquery-to-linked-server-hangs-leaving-spid-with-open-tran-that-cannot-be-killed-then-templog-ldf-grows-without-limit-requires-sql-server-restart-on-production-servers page mentioned in Ahd's post
for me killing the OLEDB external resources did not worked and i unfortunately had to restart the SQL server instance to fix this issue always
i my cases it have select with OPENQUERY from oracle linked servers or SharePoint lists which simply has a simple error like bad password and it cannot resolve the error and goes and never come back until you restart the service
Transactions that get stuck in KILLED/ROLLBACK can be canceled by killing transactions on local server. If the query is cross-server and you don't want to wait for the rollback, you have to go to the remote server and kill the transaction as well as kill it on the local server.
This applies to any database system.
Related
Please look into the below error which I am facing. I am trying to create a new job. While configuring the step 1 for this job I am trying to set an SSIS dtsx package under SSIS db. But it doesn't allow me to select my SQL Server Database Engine under the Server drop down. It shows an empty drop down. Please let me know what could be wrong.
When you click the Server drop down, it kicks off a network scan asking any server running the SQL Browser service if they have any SQL Server instances it can talk to. The browser service can be off and SQL Server works just fine, it just means it isn't broadcasting that it is available. Some folks have a misguided belief that, much like hiding under the covers so monsters cannot find you, not advertising that you have a SQL Server instance running you're more "secure."
But the Browser service is running. Ok, then what about firewall, networking rules and potentially user account controls - it's likely that one of those is blocking packets somewhere.
In the job step configuration, you can enter a name for the step. Choose the SQL Server Integration Services Package type, enter the name of the server and select the package.
This article will help you to tackle with SSIS/SQL:
mssqltips
I had to manually enter the SQL Server name inside the Server dropdown shown in the above screenshot to fix the problem.
Let me begin by saying, I am aware of this thread and others around the web that seek to trouble shoot this issue.
The solutions posted there do not apply to my issue. I have spent 5 hours trying to resolve this before deciding to ask the question.
The problem:
When I attempt to log into SSMS (or connect from a java application) using SQL Authentication I get this error:
A connection was successfully established with the server, but then an
error occurred during the login process. (provider: Shared Memory
Provider, error: 0 - No process is on the other end of the pipe.)
(Microsoft SQL Server, Error: 233)
Although it does work, it is not an option for me to use integreated authentication.
The database I am attempting to connect to is on the same machine as my SSMS instance. There is no network, this is a stand-alone system.
NAMED PIPES is ENABLED in my configuration, I HAVE rebooted since, TCP IP is a higher priority than named pipes in my configuration.
I have even gone as far as to uninstall SQL Server and reinstall it, to no avail.
The details of my SQL Server instance are as follows:
Microsoft SQL Server Management Studio - 10.0.2531.0
Microsoft Analysis Services Client Tools - 10.0.1600.22
Microsoft Data Access Components (MDAC) - 6.1.7601.17514
Microsoft MSXML - 3.0 5.0 6.0
Microsoft Internet Explorer - 9.0.8112.16421
Microsoft .NET Framework - 2.0.50727.5466
Operating System - 6.1.7601
Configuration details are as follows:
http://i45.tinypic.com/vxdz7c.png
http://i45.tinypic.com/vxdz7c.jpg
I connect from java using this code.
Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
String connectionUrl = "jdbc:sqlserver://localhost;database=AdventureWorks;integratedSecurity=false;User=JIMBO; Password=JIMBO;";
Connection con = DriverManager.getConnection(connectionUrl);
But please remember, this error also occurs when I atttempt to log in to SSMS directly.
Thanks in advance.
-Jim
To force TCP/IP being used replace localhost with 127.0.0.1 in your connection string.
As you are using a username and password make sure SQL authentication is enabled. By default only Windows integrated is enabled on sqlserver 2008.
With SqlServer authentication keep in mind that a password policy is in place to enforce security.
Forcing the TCP/IP connection (by providing 127.0.0.1 instead of localhost or .) can reveal the real reason for the error. In my case, the database name specified in connection string was incorrect.
So, here is the checklist so far:
Make sure Named Pipe is enabled in configuration manager (don't forget to restart the server).
Make sure SQL Server Authentication (or Mixed Mode) is enabled.
Make sure your user name and password are correct.
Make sure the database you are connecting to exists.
My resolution was to login using the Windows Login then go to security>Logins locate the troubled ID And retype the used password. The restart the services...
Adding "user instance=False" to connection string solved the problem for me.
<connectionStrings>
<add name="NorthwindEntities" connectionString="metadata=res://*/Models.Northwind.csdl|res://*/Models.Northwind.ssdl|res://*/Models.Northwind.msl;provider=System.Data.SqlClient;provider connection string="data source=.\SQLEXPRESS2008R2;attachdbfilename=|DataDirectory|\Northwind.mdf;integrated security=True;user instance=False;multipleactiveresultsets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />
</connectionStrings>
This problem was caused for me by this error which appeared just prior in the application error log.
"A read operation on a large object failed while sending data to the client. A common cause for this is if the application is running in READ UNCOMMITTED isolation level. This connection will be terminated."
I was storing PDFs in a SQL table and when attempting to SELECT from that table it spit out that error, which resulted in the error mentioned in your question.
The solution was to delete the columns that had large amounts of text, in my case Base64 encoded files.
perhaps this comes too late, but still it could be nice to "document it" for others out there.
I received the same error after experimenting and testing with Remote Desktop Services on a MS Server 2012 with MS SQL Server 2012.
During the Remote Desktop Services install one is asked to create a (local) certificate, and so I did. After finishing the test/experiments I removed the Remote Desktop Services. That's when this error appeared (I cannot say whether the error occured during the test with RDS, I don't remember if I used/tried the SQL Connection during the RDS test).
I am not sure how to solve this since the default certificate does not work for me, but the "RDS" certificate does.
BTW, the certificates are found in App: "SQL Server Configuration Manager" -> "SQL Server Network Configuration" -> Right click: "Protocols for " -> Select "Properties" -> Tab "Certificate"
My default SQL Certificate is named: ConfigMgr SQL Server Identification Certificate, has expiration date: 2114-06-09.
Hope this can give a hint to others.
/Kim
For me it was because only Windows Authentication was enabled. To change security authentication mode. In SQL Server Management Studio Object Explorer, right-click the server, and then click Properties. On the Security page, under Server authentication, select the new server authentication mode, and then click OK.
Change Server Authentication Mode - MSDN - Microsoft
https://msdn.microsoft.com/en-AU/library/ms188670.aspx
This Might help as reference
I had the same issue, after multiple trial of suggested solution on this site and others, I found a solution for my scenario. The account was locked out
How to Check if the account is Locked out...
Login to the server using higher privileged account (like SA or admin rights)
Expand security ==> select the login name ==>open the property window of the login ==> select the status page on the property window
Make sure This 3 Things
1, permission to connect database is GRANTED
2, Login is ENABLED
3, Status
SQL server authentication
Login is not locked out (Uncheck the box)
Thanks
Tsige
I just executed connection.close() by adding it as first statement and it was solved. Then i removed the line.
One follow up to this. I had installed SQL Server 2014 with only Windows Authentication. After enabling Mixed Mode, I couldn't log in with a SQL user and got the same error message as the original poster. I verified that named pipes were enabled but still couldn't log in after several restarts. Using 127.0.0.1 instead of the hostname allowed me to log in, but interestingly, required a password reset prompt on first login:
Once I reset the password the account worked. What's odd, is I specifically disabled password policy and expiration.
Another cause is if the user's default database is unavailable.
I had an account that was used for backing up two databases. When the backup user's default database was taken off-line, the "no process on the other end of the pipe" error started.
Came here looking for a solution to a similar issue, which I just introduced by changing Schannel settings of our IIS server using "IIS Crypto" by Nartac... By disabling the SHA-1 hash, the local SQL Server was not able to be reached anymore, even though I didn't use an encrypted connection (not useful for an ASP.Net site accessing a local SQL Express instance using shared memory).
Thanks Count Zero for pointing me in the right direction :-)
So, lesson learned: do not disable SHA-1 on your IIS server if you have a local SQL Server instance.
For me the issue seems to have been caused by power failure. Restarting the server computer solved it.
Does SQL Server has an external log file or internal table for attempted connections, or is that kind of info put somewhere in the Windows Event Log?
You can enable connection logging. For SQL Server 2008, you can enable Login Auditing. In SQL Server Management Studio, open SQL Server Properties > Security > Login Auditing select "Both failed and successful logins".
Make sure to restart the SQL Server service.
Once you've done that, connection attempts should be logged into SQL's error log. The physical logs location can be determined here.
Another way to check on connection attempts is to look at the server's event log. On my Windows 2008 R2 Enterprise machine I opened the server manager (right-click on Computer and select Manage. Then choose Diagnostics -> Event Viewer -> Windows Logs -> Applcation.
You can filter the log to isolate the MSSQLSERVER events.
I found a number that looked like this
Login failed for user 'bogus'. The user is not associated with a trusted SQL Server connection. [CLIENT: 10.12.3.126]
If you'd like to track only failed logins, you can use the SQL Server Audit feature (available in SQL Server 2008 and above). You will need to add the SQL server instance you want to audit, and check the failed login operation to audit.
Note: tracking failed logins via SQL Server Audit has its disadvantages. For example - it doesn't provide the names of client applications used.
If you want to audit a client application name along with each failed login, you can use an Extended Events session.
To get you started, I recommend reading this article: http://www.sqlshack.com/using-extended-events-review-sql-server-failed-logins/
I have a web application which is currently running on Windows XP operating system with SQL Server 2005 database and IIS 6.0.
Now, we are trying to upgrade it to IIS 7.0 on Windows Server 2008 and SQL server 2008 database.
When I run the application then it is throwing "A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)" randomly at different database calls.
I have verified using "sp_who" that only one connection which I am using is opened.
Can anyone tell me, what could be the cause of this issue?
This blog post by Michael Aspengren explains the error message "A transport-level error has occurred when sending the request to the server."
Maybe the database is set to auto-close? This used to be the default for databases created on the older MSDE/Express edition.
ALTER DATABASE YourDatabaseName SET AUTO_CLOSE OFF;
More:
The SQL Server 2005 Express Edition Overview states:
Features like Auto-Close and the ability to copy databases as files are enabled by default in SQL Server Express ...
I can't remember which service pack changed the default, but the New Database UI in the SP3 version of Management Studio Express defaults the Auto Close setting to false.
This is an error that occurrs when connecting to database due to a lower layer network-related error that you cannot handle from Sql Server.
It would be great that the API used to conenct handled this error but AFAIK it is not. The only way to solve this is to retry connecting to the database when this error occurrs.
You should try to reconnect at least a couple of times more to get sure that the error is not persistent and if it is the case then throw the exception. My experience tells me that trying to reconnect, the 99.9% of times you will succed.
Often, it's the database being offline/closed or the SQL Instance being restarted/offline
In my case. We have DELL R720, NICs are on board and PCI Broadcom NetXtreme Gigabit Ethernet cards. We run into two issues.
Network speed is very slow for HyperV VMs. The solution is to disable the "Virtual Machine queues" of the HyperV host Broadcom nic property windows. It is in the Advanced tab.
SQL client having this transport level issue. It only happened once in every 10-15 min. At the same time the RDP service kick out client from time to time also. The solution is to disable the "Large Send Offload V2" of the HyperV host Broadcom nic property windows. It is in the Advanced tab.
Check if you have MultipleActiveResultSets=true; set in your connection string.
Transport level errors are often linked to the connection to sql server being broken ... usually network.
Timeout Expired is usually thrown when a sql query takes too long to run. Is this the scenario in your case? Like stored proc taking too much time to execute or are there are batch jobs that are executed?
Use clearpool(urSQLconnection), along with dispose. This will clear the dirty connection. and you can open new connection.
Got this trying to execute commands from multiple threads on one connection object in .net, that was a stupid mistake. Locking it or using a separate connection per thread fixes that.
In my case it was McAffee that was pre-installed. Can tell if it was conflict with other solutions or not. The connection was on VPN, on WiFI. Maybe this will help someone in future.
I've got a trio of Windows servers (data1, data2 and datawitness) that aren't part of any domain and don't use AD. I'm trying to set up mirroring based on the instructions at http://alan328.com/SQL2005_Database_Mirroring_Tutorial.aspx. I've had success right up until the final set of instructions where I tell data1 to use datawitness as the witness server. That step fails with the following message:
alter database MyDatabase set witness = 'TCP://datawitness.somedomain.com:7024'
The ALTER DATABASE command could not be sent to the remote server instance 'TCP://datawitness.somedomain.com:7024'. The database mirroring configuration was not changed. Verify that the server is connected, and try again.
I've tested both port 7024 as well as 1433 using telnet and both servers can indeed connect with each other. I'm also able to add a connection to the witness server from SQL Server Manager on the primary server. I've used the Configuration Manager on both servers to enabled Named Pipes and verify that IP traffic is enabled and using port 1433 by default.
What else could it be? Do I need any additional ports open for this to work? (The firewall rules are very restrictive, but I know traffic on the previously mentioned ports is explicitly allowed)
Caveats that are worth mentioning here:
Each server is in a different network segment
The servers don't use AD and aren't part of a domain
There is no DNS server configured for these servers, so I'm using the HOSTS file to map domain names to IP addresses (verified using telnet, ping, etc).
The firewall rules are very restrictive and I don't have direct access to tweak them, though I can call in a change if needed
Data1 and Data2 are using SQL Server 2008, Datawitness is using SQL Express 2005. All of them use the default instance (i.e. none of them are named instances)
After combing through blogs and KB articles and forum posts and reinstalling and reconfiguring and rebooting and profiling, etc, etc, etc, I finally found the key to the puzzle - an entry in the event log on the witness server reported this error:
Database mirroring connection error 2 'DNS lookup failed with error: '11001(No such host is known.)'.' for 'TCP://ABC-WEB01:7024'.
I had used a hosts file to map mock domain names for all three servers in the form of datax.mydomain.com. However, it is now apparent that the witness was trying to comunicate back using the name of the primary server, which I did not have a hosts entry for. Simply adding another entry for ABC-WEB01 pointing to the primary web server did the trick. No errors and the mirroring is finally complete.
Hope this saves someone else a billion hours.
I'd like to add one more sub answer to this specific question, as my comment on Chris' answer shows, my mirror was showing up as disconnected (to the witness) Apperently you need to reboot (or in my case i just restarded the service) the witness server.
As soon as i did this the mirror showed the Witness connection as Connected!
See: http://www.bigresource.com/Tracker/Track-ms_sql-cBsxsUSH/