cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Running KILL

oneeyeman1
Participant
0 Likes
1,054

Hi, ALL,

This is a follow-up to

https://community.sap.com/t5/technology-q-a/debugging-software-that-connects-to-sap-ase/qaa-p/144014....

 

So I tried to use Google. Turns out comparing to other DBMSes, like SQL Server, Postgres or MySQL, SAP ASE does not clean up if the connection is broken unexpectedly, just as I suspected in the last post in the linked thread.

 

So, when I tried googling, it suggest to do following:

1. Run sp_who to identify the (still) running process.

2. Run "KILL <spid>" to kill the process that is stuck.

 

So I ran "dbisql", connect as "sa" and then ran "sp_who". It succeeded and gave me the spid of the process that is stuck.

Next I I tried to run "KILL" on that spid. However I got an error saying that I can't kill the process that I started.

 

What do I do?

I presume that even if I create a user in the "sa" domain, it will not be able to kill the process, because it started as "sa"?

 

Or not?

 

And if not - how to create a user in "sa" domain?

 

Thank you.

 

View Entire Topic
bo2l
Product and Topic Expert
Product and Topic Expert
0 Likes

The process you see 'Running' should be your current dbisql process but not the mentioned 'hanging/zombie' process from gdb.
The Error '6104 - You cannot use KILL to kill your own process' will raise when you are trying to kill your current process.

You can verify your current spid by execute this command in dbisql:
select @@spid

To verify if there are hanging process in ASE server you can run:
select * from master..syslogshold
go

Are there spids returned? Check the timestamp to find which corresponds to the process of when gdb connected ASE. Then try to kill that spid.

oneeyeman1
Participant
0 Likes

@bo2l,

Thx for the reply.

 

Yes, I tried to run "SELECT @@spid" and it returned the one process that was running from "sp_who".

 

I also tried to run the second query but it didn't return any records.

 

So, what does it mean?

This is what happened:

1. I ran my C++ code with gdb and hit a problem inside transaction.

2. I interrupted that session without COMMIT/ROLLBACK, fixed the issue and restarted the gdb session.

3. At this point the program got stuck in side BEGIN TRANSACTION.

 

After googling, I saw that the way forward is "sp_who/KILL".

 

Do you know what can I do to identify the cause of my second gdb session to be stuck?

 

Thank you.

 

bo2l
Product and Topic Expert
Product and Topic Expert
0 Likes
I don't know much about the gdb/programming, but if syslogshold doesn't return any process and sp_who doesn't return other spids likely to be the 'gdb' process then the process should just not exist in ASE. From ASE perspective you can try restarting the server if possible.
oneeyeman1
Participant
0 Likes

@bo2l,

Thank you for the reply.

"select * from master..syslogshold" does not return any records.

I got that sequence trying to google.

 

Restarting the server does not help. Running the program still stuck in the "BEGIN TRANSACTION".

Any other idea?

 

Thank you.