I'm using SQL Server 2012 and I'm stuck with a strange problem.
I tried to restore a database snapshot to a database. Usually it doesn't take much time to restore, but now it took 5 minutes and is still restoring, so I stopped query execution. It was trying to stop the query execution for more that 5 minutes, so i closed SSMS using task manager.
Then I tried to kill the restore process using KILL.
Now I am able to can connect to that server, but the list of databases is not opening. I mean: whoever is connected to this server, they are not able to get the databases. When I checked the sysprocesses table, it is showing lastwaittype as LCK_M_S.
None of my users can see databases. Looks like I kind of messed up. I cannot restart SQL Server as others are connected to the server.
How do I solve this? Please help.
EDIT:
i tried this approach and when i checked with
select db_name(dbid), * from sysprocesses where blocked <> 0
i got two records,
do you think because of these two rest of the process are getting locked up.
I'm guessing there still is some hidden lock on the sysdatabases table in the master database. This could very well be caused by the KILL of the restore command.
The article here might help you:
http://ellisweb.net/2012/02/clearing-out-a-mysterious-table-lock-lck_m_s-in-sql-server-2008/
It basically advises you to identify where the hidden lock is coming from, and then issuing a KILL on that process ID.
Try restarting the instance. Can't hurt if your users can't see any of the databases anyway.
Related
I have a SQL Server database and have a linked server connection to an Oracle DB.
I had the following query running on my SQL Server:
INSERT INTO dbo.my_table_on_sql_server
SELECT *
FROM OPENQUERY (linkedservername, ‘SELECT * FROM target_table’)
The target_table has 50 million rows and I'm aware the query takes time to execute but has successfully completed before.
This time though, my PC had an automatic restart in the middle of the query. SSMS 2017 automatically reopened as soon as the PC fired back up, but I could not longer see the query running. my_table_on_sql_server has no data.
I'd like to understand what happens in SQL Server in the event of such a situation. Am I correct in assuming that the query was killed / rolled back? Is there any query running in the background? I've seen some related answers on this forum but wanted to specifically understand this for linked servers, as I use them a lot to retrieve data from other DBs for my job.
I'm more concerned about the Oracle DB as I don't want my query to impact any performance upstream. I only have a read-only access permission to the Oracle DB.
Thank you!
On shutdown the query will be aborted, and the INSERT rolled back. The rollback may happen during shutdown, or after restart, and may take some time to complete.
There's no automatic retry or anything that will access the linked server Oracle after the shutdown.
I have a SQL Server Report instance that is acting strange. I can do everything but overwrite an existing report. I can open a current report, run it, and save it as a different report no problem, but any attempt to save an existing one times out after 2 minutes. Looking at the Report Server logs I can confirm it is a timeout that it is returning.
Has anyone experienced this before, and more importantly, figured out how to solve this?
Ended up going through a direct connection rather than the shared connection. There was a contention with one of the meta tables being locked, and this proved to be not a solution, but at least a work-around.
I am running several DB instances on the dedicated Azure SQL Server. All instances are S0. They all run the same processes yet one of them got into trouble (never happened before). The automated SP which purges old records from tables periodically did not seem to be able to finish. It has been running over 12 hours now (should finish in minutes) and I can't figure out how to stop it (obviously restart is not available).
I tried to KILL the process (the SP in question) but that did not seem to work (see below). Any help appreciated. No need to worry about the data but trying not to go nuclear on this and delete the whole database.
Try renaming the database and rename it back or alter the database to different SLO and revert it. The other option is to turn ON / OFF RCSI with rollback immediate
I have a very strange and complicated situation. I have data being erased from one of my SQL Server tables, and I am not sure by what application. I would like to be able to track this.
As I am sure you are wondering how I could find myself in this situation, here is some background. We have 2 servers, Web and Database running IIS6 and SQL Server 2005 respectively. They were setup by the previous developer who left the company without giving me any sort of introduction to the system so I am left "hunting" for everything.. I have been able to figure out most of the system on my own except for this, which remains a mystery. All I know for sure is this:
Data is being erased at a set time every day (I have setup a TRIGGER to capture this)
It is not a SQL Server Agent Job
It is not a Windows Scheduled Task
It is not a Windows Service
All database logins are done with the sa user so login history cannot help me... (again, I didn't set this up)
How the heck do I debug something like this? If anything, I want to know if this is coming from something running on the database server, or from a request from an outside source. Please help :-)
As you know the time it happens you should set up a SQL Profiler trace at that time to catch the statements being sent.
This will show you the SQL being sent, the spid of the connection, user name, application name sent by the connection and other useful info to track down the culprit.
In case the time that it happens is not convenient for you to do this you can script SQL traces (which is more lightweight than running the full GUI anyway)
Edit: Be careful when using it not to record so much information that you bog down the server. You can filter for activity on the database of interest for example.
Every morning we have a process that issues numerous queries (~10000) to DB2 on an AS400/iSeries/i6 (whatever IBM calls it nowadays), in the last 2 months, the operators have been complaining that our query locks a couple of files preventing them from completing their nightly processing. The queries are very simplisitic, e.g
Select [FieldName] from OpenQuery('<LinkedServerName>', 'Select [FieldName] from [LibraryName].[FieldName] where [SomeField]=[SomeParameter]')
I am not an expert on the iSeries side of the house and was wondering if anyone had any insight on lock escalation from an AS400/Db2 perspective. The ID that is causing the lock has been confirmed to be the ID we registered our linked server as and we know its most likely us because the [Library] and [FileName] are consistent with the query we are issuing.
This has just started happening recently. Is it possible that our select statements which are causing the AS400 to escalate locks? The problem is they are not being released without manual intervention.
Try adding "FOR READ ONLY" to the query then it won't lock records as you retrieve them.
Writes to the files on the AS/400 side from an RPG/COBOL/JPL job program will cause a file lock (by default I think). The job will be unable to get this lock when you are reading. The solution we used was ... don't read the files when jobs are running. We created a big schedule sheet in excel and put all the sql servers' and as/400's jobs on it in times slots w/ color coding for importance and server. That way no conflicts or out of date extract files either.
You might have Commitment Control causing a lock for a Repeatable Read. Check the SQL Server ODBC connection associated with <linkedServerName> to change the commitment control.