In the Activity Monitor, There is a process(belongs to a single PC) running select statement on tempdb database,it is always running. and i am unable to kill it. What should i do?
That's you, looking in Activity Monitor.
Activity monitor shows database activity. But producing the list of activities is itself an activity. Therefore it appears in the list.
Naturally it will always be shown as running, because at the time it runs, it must be running. Also, if you kill the SPID, next time you refresh activity monitor, it will make a new connection, so you will see it again.
Related
I use RODBC to send queries to an SQL-Server. Sometimes they take too much time to run, so I need to cancel them.
Clicking the red "stop" button in RStudio yields this error message:
R is not responding to your request to interrupt processing so to stop
the current operation you may need to terminate R entirely.
Terminating R will cause your R session to immediately abort. Active
computations will be interrupted and unsaved source file changes and
workspace objects will be discarded.
Do you want to terminate R now?
And if I click yes my session is indeed terminated. (note: using Rgui instead of RStudio doesn't make things better)
However:
when I use another software (named "Query ExPlus") to connect to this same SQL-Server, I have a similar stop button, and clicking it instantly interrupts the query, without any crash.
when I connect to a PostgreSQL database using the RPostgres package I can also interrupt the query at any time.
These two points lead me to think that there should be a way to solve my problem. What can I do?
So far my workaround is:
library(RODBC)
library(R.utils)
withTimeout(mydf <- sqlQuery(myconnection, myquery), timeout=120)
Note: I don't have permission to kill queries from the database side.
I've just stumbled upon the odbc package. It allows to interrupt a query at any time.
Basic usage goes like this:
library(DBI)
myconnection <- dbConnect(odbc::odbc(),
driver = "SQL Server",
server = "my_server_IP_address",
database = "my_DB_name",
uid = "my_user_id",
pwd = "my_password")
dbGetQuery(myconnection, myquery)
I don't have a deep understanding of what happens behind the scenes, but for what I've seen so far in my personal use this package has other advantages over RODBC:
really faster
get the column types from the DB instead of guessing them (see here)
no stringsAsFactors and as.is arguments necessary
Most SQL Server users use SQL Server Management Studio (which is free and can be downloaded from Microsoft) to connect to SQL Server or execute commands from the command line via a tool called SQLCMD.
If you can determine the session id that the SQL Command is being run in you can kill the session which would stop any executing command(s). SQL Server will still need time (could be a 'long' time) to rollback any changes made during the execution of the command.
Terminating a session (depending on the software) can take a while to communicate to SQL Server that the session has been terminated. When I connected to DB2 from SQL Server using linked servers DB2 would buffer the terminate command and it would frequently take up to an hour for DB2 to realize the session had been terminated.
To determine what the session you are running in you can try:
select ##spid;
once you have the spid (lets say 86)
you can then issue (depending on if you have permission to do so)
kill 86;
but as Microsoft notes:
Terminates a user process that is based on the session ID or unit of work (UOW). If the specified session ID or UOW has a lot of work to undo, the KILL statement may take some time to complete, particularly when it involves rolling back a long transaction.
Try to close your "tab query" on SQL Server Management Studio
Then it will appear pop-up,
This Query is currently executing. Do you want to cancel this query ?
Cancel anyway, choose "yes".
try to set your connection prior to query:
sql = odbcConnect('Database name')
Then use same line to run your query:
mydf <- sqlQuery(sql, " myquery ")
Note: The running time is dependant on both database and R server but setting up the connection this way should resolve termination problem.
My dbms_job has been running for nearly thirty days.
The number of total time keeps rising, but I can't find any info of the running job.
When I execute sql that is "select * from dba_jobs;", the result shows no job is running.
I set it to broken, but it doesn't work.
How can I stop this dbms_job safely?
DBA_JOBS lists all the jobs created in the database. You could use DBA_JOBS_RUNNING view to list all jobs that are currently running in the instance.
When I execute sql that is "select * from dba_jobs;", the result shows no job is running.
This shows all the jobs created using DBMS_JOBS package. The job might have created using DBMS_SCHEDULER package.
SQL> select job from user_jobs;
JOB
----------
99
I have created only one job using DBMS_JOBpackage which is called 99.
Others are created using DBMS_SCHEDULERpackage which can be seen using:
SQL> select job_name from user_scheduler_jobs;
As per the documentation-
Stopping a Job
Note that, once a job is started and running, there is no easy way to stop the job.
Its not easy to stop the job.
Don't know which version of Oracle database are you using. But starting with Oracle 10g You use the following query to list the scheduled jobs.
SQL>select * from all_scheduler_jobs;
ALL_SCHEDULER_JOBS
ALL_SCHEDULER_JOBS displays information about the Scheduler jobs accessible to the current user.More...
Use the following query to find the currently running job.
SQL>select job_name, session_id, running_instance, elapsed_time, cpu_used
from user_scheduler_running_jobs;
And to stop-
SQL>EXEC DBMS_SCHEDULER.STOP_JOB (job_name => 'JOB_NAME');
Short of killing the session, you're out of luck.
From the Documentation:
Note that, once a job is started and running, there is no easy way to stop the job.
That's one of the many reasons why you shouldn't use dbms_job anymore. Use dbms_scheduler instead.
checkout SID in "select * from DBA_JOBS_RUNNNG"
thats session ID
kill that session and thats it changes will be rolled back, so it can take "more" time to abort than letting it finish if that bulk update was 90% complete....
There is job on our SQL Server. It was started and stopped after some time. However, the job still appears to be running even if it is not.
I can see it "is running" in Job Activity Monitor and also sysjobactivity (= there is no stop_execution_date field filled, but in fact nothing happens. I do not see it running in Activity Monitor.
How to effectively kill the job without need to restart whole server? Stopping the job via SSMS GUI does not work.
We have a process that was running for 4 hours. Because it was running so long, it was causing other issues in the database, so it was decided to kill the process.
Now, the process is in a suspended state. It also states that it's being blocked by itself after querying sp_who2.
In activity monitor, here's the waitresource information:
objectlock lockPartition=0 objid=xxx subresource=FULL dbid=2 id=lockyyyy mode=X associatedObjectid=xxx
You'll notice that the objid and associatedObjectId are the same value.
Querying the sys.objects table shows NO results for that object id.
Is Sql Server waiting for a lock on an object that doesn't exist anymore? How can I get rid of this process without restarting Sql Server? (our DBA's are not responding to help requests).
Keep in mind, this is a test environment, but it is stopping all development/testing because we are unable to deploy any changes to our database, because one of those changes is affecting one of the objects that the process was accessing.
Edit: more info from activity monitor:
Command = 'KILLED/ROLLBACK'
TASK STATE = 'SUSPENDED'
I have experienced this may times. When you kill a large INSERT/UDPATE/DELETE statement, it can take hours to recover (if it ever does recover) from this state.
run kill <spid> with statusonly.
It will give you a percentage and estimated wait time of the ROLLBACK process.
Sometimes it says 0% or 100% and 0 estimated time. If you are patient, it may recover eventually. If you restart the server, the rollback process will be completed offline, and the database will show IN RECOVERY state and usually will be faster than waiting the server to recover itself.
Be aware that users won't be able to use the database until the recovery process ends, but if the SPID in KILLED/ROLLBACK state is locking other process, it might be an option to restart.
Well, this seems to be lock due to parallel processing inside the tempdb.
You can try kill [processid] if you have the rights to?
Another way is to get more detailed process information with this:
SELECT * FROM sys.sysprocesses WHERE spid = YOURSPID
As the Process runs in DB:2 try this:
SELECT * FROM tempdb.sys.all_objects WHERE object_id = OBJECTID
As I've seen, you have edited your question. If the Spid is in KILLED/ROLLBACK you have to wait until your transaction is rolled back. After that the process will be killed and removed. You can't do anything else, as the transaction security must be given.
I am working on winform application using C# 4.0, back end SQL SERVER 2012.
Some time, my software seems to be hang, because queries become pending, because
one query shows in activity monitor in suspended mode,
this suspended query is run successfully several time but some time this problem occurs.
The activity monitor shows :
Task State : Suspended
command : Update
Application : .net SqlClient Data Provider
Wait time : 5673610..... (unlimited)
Wait Type : LCK_M_X
Wait Resource : keylock hobtid=72057594058768384 dbid=14 id=lock2dbc30880 mode=X associatedObjectId=72057594058768384
What is the reason of a query state become suspended.
how can i stop it to be suspended ?
LCK_M_X indicates that a query is waiting to acquire an exclusive lock somewhere. Try checking other applications or threads using the same database objects to see if there's a race condition or a process that isn't cleaning up after itself.
Perhaps there's another db call or nested proc call in your code somewhere?
Try using Sql Profiler to identify what the lock request is coming from - This may help, but its difficult to say without knowing more.
select * from sys.dm_tran_locks
HTH