I'm using Sybase ASE 15.0.
I have a process displayed by sp_who
by 'sa' user that it seems to be running an 'INSERT' statement
0 18 running sa sa
hostname 0 master tempdb
INSERT 0
When I try to kill this process I get the following message:
1> kill 18
2> go
Msg 6104, Level 16, State 1:
Server 'STADF16', Line 1:
You cannot use KILL to kill your own process.
It appears to be my own process but clearly I'm not running an INSERT statement.
Sybase shutdown and restart has been done, and all OS processes had been killed.
What is this process?
When you run sp_who it creates a temp table to format the output, so you see your own spid inserting in the temp table (#who1result) via a select into statement in the sp_who output every time you execute it. If you check the SQL of sp_who via sp_helptext you'll see the relevant SQL statements. You can of course create your own version of sp_who and exclude your own process should you wish by checking where spid != ##spid against master..sysprocesses instead.
Related
I have a stored procedure in SQL Server that contains 4 insert processes:
Process 1, Lookup data from Chief 1 and insert it to Archive table
Process 2, Lookup data from Chief 2 and insert it to Archive table
Process 3, Lookup data from Chief 3 and insert it to Archive table
Process 4, Lookup data from Chief 4 and insert it to Archive table
All processes work in the stored procedure, so the application only calls to run the one stored procedure.
When I execute using CodeIgniter (SQLSRV) with command:
EXEC getwage_bcmbs #date_start = '2020-04-28'
The process only works up to process #2. Then the result only 2 records in Archive table.
But, when I execute the command in SQL Server Management Studio, the processes normally run until process 4. Then the result are 4 records.
Please can anybody help me? What is the problem? Is it caused by some trouble in the stored procedure or inside SQLSRV?
PHP Version 7.2.18-1 + Ubuntu18.04.1 + deb.sury.org+1
SQL Server 2016
Solved
I currently need to add
SET NOCOUNT ON
to my Store Procedure.
In my SP, I make the process that insert to Temporary table and when continue to process 2, the temporary table will be deleted.
When the temporary table return 0 data to delete, then the SQL Server return message that handled by SQLSRV as a complete process messages. Then the process stop in the process 2.
May be that why my SP not run completely when i call it from SQLSRV. But normally run when i call it using SMSS or SQL Server Client programs
Thanks StackOverflow
I'm trying to alter database name on phppgadmin but i'm always getting this error:
ERROR: database "X" is being accessed by other users
DETAIL: There are 19 other sessions using the database.
Nobody is accessed except me so i don't understand this error.
How can i change the database name, or force it even when there are 19 other sessions using the database ?
Thank you
There may some auto connectivity. you may first terminate all the connection to your DB using below command:
SELECT
pg_terminate_backend(pid)
FROM
pg_stat_activity
WHERE
-- don't kill my own connection!
pid <> pg_backend_pid()
-- don't kill the connections to other databases
AND datname = 'database_name'
;
Before executing this query, you have to REVOKE the CONNECT privileges to avoid new connections:
REVOKE CONNECT ON DATABASE dbname FROM PUBLIC, username;
If you're using Postgres 8.4-9.1 use procpid instead of pid
SELECT
pg_terminate_backend(procpid)
FROM
pg_stat_activity
WHERE
-- don't kill my own connection!
procpid <> pg_backend_pid()
-- don't kill the connections to other databases
AND datname = 'database_name'
;
After the above , try renaming your DB.
reference: Kill a postgresql session/connection
UPDATE
For future reference, you should be able to:
-- disconnect from the database to be renamed
\c postgres
-- force disconnect all other clients from the database to be renamed
SELECT pg_terminate_backend( pid )
FROM pg_stat_activity
WHERE pid <> pg_backend_pid( )
AND datname = 'name of database';
-- rename the database (it should now have zero clients)
ALTER DATABASE "name of database" RENAME TO "new name of database";
Note that table pg_stat_activity column pid was named as procpid in versions prior to 9.2. So if your PostgreSQL version is lower than 9.2, use procpid instead of pid.
reference: PostgreSQL - Rename database
I have a background process running, it can be seen in task Manager while its running. I need to check from my database, whether the process is running or not
I have tried the following query
select * from sys.dm_os_threads
select * FROM sys.dm_os_tasks
But it doesnt show me all process running on the system
I have a background process running, it can be seen in task Manager while its running. I need to check from my database, whether the process is running or not
I hope you are talking about background SQL Server process. Below queries only show information related to SQL Server
All processes running on SQL server can be seen by querying DMV
select * from sys.dm_exec_requests
select * from sys.dm_exec_sessions
select * from sys.dm_exec_connections
You can read books online about the documentation about these DMV's
use this query
select
tblSysProcess.cmd
, tblSysProcess.physical_io IOUsage
, tblSysProcess.cpu as CPUusage
, tblSysProcess.waittype as waitType
, tblSysProcess.waittime as waitTime
, tblSysProcess.lastwaittype as lastWaitType
, tblSysProcess.waitResource as waitResource
, tblSysProcess.dbid as databaseID
, case
when (dbid > 0) then db_name(dbid)
else ''
end as dbName
, memusage as memUsage
, status
from master.dbo.sysprocesses tblSysProcess
where
(
--background process
(tblSysProcess.spid < 50)
)
select db_name(dbid),cmd,spid,status
from
sys.sysprocesses
where
db_name(dbid) = 'dbname' and status = 'background'
So it looks like you're not trying to see a SQL server process but another process on the machine for another application, none of the built in DMVs or functions will be able to show you this information natively. You have a couple of options, one is to write a CLR stored proc or function to check for the process, the other is to use xp_cmdshell to get the tasklist, you can do that like this:
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
GO
EXEC sp_configure 'xp_cmdshell', 1
RECONFIGURE
GO
EXEC xp_cmdshell 'tasklist.exe'
GO
EXEC sp_configure 'xp_cmdshell', 0
RECONFIGURE
That will list out all the running processes on the machine, you could shove that data into a table if you like for further analysis if required, or you can play with the tasklist.exe parameters to just look for the process that you are interested in. Just remember to turn off xp_cmdshell whenever you don't need it as it can be a security risk.
Try This;
EXEC sp_who1
EXEC sp_who2
SELECT *
FROM MASTER..sysprocesses
SELECT *
FROM sys.dm_exec_sessions
WHERE is_user_process = 1
I Configured a distribution in SQL Server 2008 using both Wizard and T-SQL but after it when I want to remove it Using Wizard (right clicking on Replication and choosing 'Disable Publishing and Distribution...') or executing following command with and without its parameters:
exec sp_dropdistributor #no_checks = 1 -- no new results with #ignore_distributor = 1
this Error would be presented:
Msq 21122, Level 16, State 1, Procedure sp_dropdistributiondb Line 124
Cannot drop the distribution database 'lobloblob' because it is
currently in use.
I didn't publish any thing, didn't configure any subscription but gave this error
what should I do ?
Try this:
SELECT spid FROM sys.sysprocesses WHERE dbid = db_id('distribution')
Kill the spid and try again. Now it should work.
I used the following scripts:
SELECT spid FROM sys.sysprocesses WHERE dbid = db_id('distribution')
and found that the session_id of current session (which contains the distribution configuration script) doesn't allow to disable distribution so i suggest this script to kill running spid to drop distribution:
use [master]
declare #spid varchar(10)
select #spid=spid from sys.sysprocesses where dbid = DB_ID('distribution')
while ##ROWCOUNTS <> 0
exec ('KILL ' + #spid)
exec sp_dropdistributor #no_checks = 1
My guess would be that the distribution cleanup job is causing the problem. But, to check, prepare to execute the sp_dropdistributor in one window in SSMS and note the session_id of the window. In a second, prepare to run select session_id from sys.dm_os_waiting_tasks where blocked_session_id = <spid from window 1>. Back in window 1, run the proc and then switch back to window 2 and run the select. it'll tell you the session_ids of the sessions blocking the drop of the database.
I am working in a database where I load data in a raw table by a data loader. But today the data loader got stuck for unknown reasons. Then I stopped the data loader from windows task manager. But then I again tried to load data in the raw table but found its locked and I can't do any operation on it. I tried restarting SQL Server service but it was not resolved. And I have no permission to kill processes on this server.
Below is the message showed by SQL Server.
An exception occurred while executing a Transact-SQL statement or
batch. (Microsoft.SqlServer.ConnectionInfo)
Program Location:
at Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteNonQuery(String
sqlCommand, ExecutionTypes executionType)
at Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteNonQuery(StringCollection
sqlCommands, ExecutionTypes executionType)
at Microsoft.SqlServer.Management.Smo.ExecutionManager.ExecuteNonQuery(StringCollection
queries)
at Microsoft.SqlServer.Management.Smo.SqlSmoObject.ExecuteNonQuery(StringCollection
queries, Boolean includeDbContext)
at Microsoft.SqlServer.Management.Smo.NamedSmoObject.RenameImplWorker(String
newName)
at Microsoft.SqlServer.Management.Smo.NamedSmoObject.RenameImpl(String
newName)
===================================
Lock request time out period exceeded. Either the parameter #objname
is ambiguous or the claimed #objtype (OBJECT) is wrong. (.Net
SqlClient Data Provider)
Server Name: 162.44.25.59
Error Number: 1222
Severity: 16 State: 56
Procedure: sp_rename Line Number: 282
My SQL Server version is 2008 R2.
In the SQL Server Management Studio,
to find out details of the active transaction, execute following command
DBCC opentran()
You will get the detail of the active transaction, then from the SPID of the active transaction, get the detail about the SPID using following commands
exec sp_who2 <SPID>
exec sp_lock <SPID>
For example, if SPID is 69 then execute the command as
exec sp_who2 69
exec sp_lock 69
Now , you can kill that process using the following command
KILL 69
It's been a while, but last time I had something similar:
ROLLBACK TRAN
or trying to
COMMIT
what had allready been done free'd everything up so I was able to clear things out and start again.
To prevent this, make sure every BEGIN TRANSACTION has COMMIT
The following will say successful but will leave uncommitted transactions:
BEGIN TRANSACTION
BEGIN TRANSACTION
<SQL_CODE?
COMMIT
Closing query windows with uncommitted transactions will prompt you to commit your transactions. This will generally resolve the Error 1222 message.
I had these SQL behavior settings enabled on options query execution: ANSI SET IMPLICIT_TRANSACTIONS checked. On execution of your query e.g create, alter table or stored procedure, you have to COMMIT it.
Just type COMMIT and execute it F5
In my case, I was trying to disable a trigger on a table when I received error 1222 "Lock request time out period exceeded."
I followed suggestions in this answer:
Open two query windows in SSMS.
In the first, type/paste the command that is timing out (due to a lock). In the lower right hand corner of SSMS, you should see the username and (in parentheses) the SPID of the connection you're using. Note the SPID of this query window connection. Don't execute this query just yet.
In the second query window, type/paste SELECT * FROM sysprocesses WHERE spid = <SPID you noted in step 2>
Execute the first query that is timing out, and while it is executing (but before it times out) switch over to the second query window and execute it (the SELECT * from sysprocesses... one)
You should get some results in the results pane. Look at the 'blocked' field in the results. In my case, it contained the SPID of the process that was locking the table.
Research the locking process further by executing SELECT * FROM sysprocesses WHERE spid = <SPID from the 'blocked' field in step 5>.
If the locking process can be safely terminated, kill it with kill <locking SPID>