I want to use a trigger when a session is killed / ended. Is it possible?
My program is connecting a table and update "online" field when it is online. If my program crashed or my mssql connection killed, i want to update "online" field...
For example: When my program is online, it gets spid and update SERVICE_TABLE(spid, online)
SEVICE_TABLE
------------
id
spid
online
when a session is killed / ended, trigger look up SERVICE_TABLE. Is killed spid in SERVICE_TABLE, update "online" field to false.
We have a similar situation. I've basically added a "lastseen" to our equivalent of the service table. A background process in the client updates this field every minute. (Be sure to create a new database connection every time you update the field.)
If the "lastseen" field is more than 5 minutes in the past, we assume the application has gone the way of the Hindenburg.
There are no DDL logout triggers in SQL Server (though there are login ones). Service Broker can be used to process the AUDIT_LOGOUT events though.
Does this help?
Related
I have a Oracle job that is executing every second and updating the T_USER table, I am wondering if during the execution of the job the table is blocked and other processes like a Web. app. that is using this DB will be blocked.
Oracle uses row-level locking. Therefore you have to look at different situations:
1.) The web app and your job affect different rows: You are fine.
2.) The web app and your job affect the same row and the locking time (the time between the UPDATE and the COMMIT) is short you should be fine. Oracle will serialize the execution.
3.) Either your job or the web app will hold locks for a long time. This will be noticeable: Oracle will wait for the transaction to complete. The job or app might hang during this time but should work fine. If the lock time is hours than you might run into problems with timeouts or impatient users.
4.) Your job and your app update multiple rows and hold locks for these rows for a longer time and job and app affect the same rows. This is dangerous. You might run into deadlocks because your job is holding a lock on Row A and wants to update Row B and your app is holding a lock on Row B and wants to update Row A. In such a situation Oracle will raise an exception for one of the two sessions - either the job or the app. This is pretty annoying because it can be very hard to reproduce and to analyze.
You have to decide yourself which case you actually fall under.
Quick question: Does exiting out of TOAD (for Oracle) while it is trying to cancel a pending query harmful?
Should I be letting this dialog box run its course?
I did have the screenshot but am unable to post pics until I have 10 reps.
EDIT: It has been going for around 30 minutes now.
EDIT2: I should mention it is not an update query, purely search.
Thanks,
When this happens and I've already waited long enough (and the Cancel button has no effect), I open Task Manager and apply "End Process Tree" command on the Toad.exe process.
If a database connection is lost, all uncommitted changes made are automatically rolled back by the database. So it is not harmful.
Once I investigated this by looking up the sessions list. It looks like this happens when Toad somehow loses the connection to the server in the midst of executing a query.
When you wonder why the query is taking so long (when it shouldn't) and click the Cancel button, Toad enters a state of "limbo" where it's waiting for the result of the cancel operation from the server (not aware of connection loss).
The problem is that there is no way to stop this waiting and go back to normal. This is a bug in Toad. There is no other way around this. I am not sure when they will fix it, if at all.
I just had same problem.
LIKE THIS FOR DAYS
One solution to cancel the running process (processing or canceling) in TOAD which take time (keep processing for longer hours and same going for hours) is
JUST disable the internet connection which auto cancels the toad process.
Later go to Session > Test connection to reconnect to servers
These steps helped me at least:
Session -> TestConnection (Reconnect)
This step will take some time, have patience (You may get TOAD: Not Responding)
Debug -> Halt Execution
At least You do not have to forcibly kill the process from TASK MANAGER.
Keep querying :)
If you've got the sys / dba level access to the target database then go and kill the toad session, I wrote the following query to identify and kill my toad session which was running for 30 mins and wasting my precious time.
SQL> select sid, username, serial#, status from v$session where machine like '%ACC%';
SID USERNAME SERIAL# STATUS
989 SYS 1307 INACTIVE
991 PIN 15780 ACTIVE
SQL> alter system kill session '991,15780' immediate;
ORA-00031: session marked for kill
And boom !! Toad returned the session and control :)
Regards,
Sayeed Shaikh
I'm running Firebird 2.5 (and have also tried earlier versions) on Windows. Every day after 12:00PM running insert/update queries on one specific table hang, but complete successfully by 12:35 or so, no matter when started. It does seem that Firebird is doing some kind of maintenance on the table and it takes half an hour to complete, during which time the table cannot be written to (but the reads are fast). The table itself is really small, some 10000 rows, compared to millions of rows we have in other tables - and other tables do not get stuck.
I haven't been able to find any reason or solution. I tried dumping the table and restoring it, which didn't help, I tried switching between superserver and classic, changed versions with no success.
Has anyone experienced a problem like this?
No. Firebird doesn't have any internal maintenance procedures bind to some specified time of a day. Seems, there is some task on your server scheduled to run at 12:00 PM. Or there are network users of the server who start doing some heavy access at 12:00 PM.
The only maintenance FB does is "garbage collection" (geting rid of old record versions) and this is done on "when needed" basis (usually when records were selected, see the GCPolicy in firebird.conf) not on some predefined time.
Do you experience this hang only on during these certain hours or is it always slow to insert to that table? Have you checked the server load during the slowdown (ie in the task manager, is the CPU maxed out)? Anyway, here is some ideas to check:
What constraints / triggers do you have on the table? If they involve some extensive checks (ie against the other tables which contain millions of rows) this could be the reason inserts take so long.
Perhaps there is some other service which is triggered at that time? Ie do you have a cron job to make backup of the DB at that time? Or perhaps some other system service which runs at that time with higher priority slows down the server?
Do you have trace service active for the table? See fbtrace.conf in FireBird root directory. If it is active, extensive logging might be the cause of slowdown, if it isn't active, using it might help you to find the cause.
What are the setings for ForcedWrites / UnflushedWrites (see firebird.conf)? Does changing them make difference?
Is there something logged for this troublesome timeframe in firebird.log?
To me it looks like you have a process which starts at 12:00 and does something which locks the entire table. Use the monitoring table or the trace manager to see if there is any connection or active transaction which looks suspicious.
I also think your own transaction are started with the WAIT clause without a LOCK TIMEOUT, you might want to change this to NO WAIT or WAIT with a LOCK TIMEOUT, so that your transactions either fail immediately or after the timeout.
My suggestion is to use the TRACE API in 2.5 to track down what is happening near or around that time. That should help get you more information as to what is happening.
I use this for debugging http://upscene.com/products.misc.fbtm.php kinda buggy itself, but when it is working it is a god send.
Are some Client-Connections going DOWN at 12:00 PM? I had a similar problem on a 70.000 records sized table:
Client "A" has a permanently open DB Connection like "select * from TABLE". This is a "read only transaction" but reason enough for the server to generate Record-Versions. Why?
Client "B" made massive Updates to this Table, the Server tries to preserve the world like it was when "A" startet her "select". This is normal for Transaction able DB-Servers, and its implemented by creating Record Copies of the record-data before its updated.
So in my case for this TABLE 170.000 Record Versions existed. You can measure this by
gstat -r -t TABLE db.fdb | grep versions
If Client "B" goes down, the count of Record-Versions is NOT growing any more. Client "A" is the guilty one, freezing all this versions, forces the server to hold it. Finally if Client "A" goes down (or for example a firewall rule cuts all pending connections) Firebird is happy to start the process of getting rid of the now useless Record-Versions.
This "sweep"?! is bad programmed (even 2.5.2) cpu is 3% it do only <10.000 Versions / Minute so this TABLE has a performance of about 2%.
I have a SQL Server 2005 database that keeps locking and won't release. My application cannot commit updates to the database because there are tasks that are waiting to be processed and my app keeps crashing. If I look on activity monitor, waiting tasks just keeps going up and up until I kill the process. The problem is I can see what is in activity monitor that is causing the lock but I do not have enough information it just says blocked by session ID.
Is there any way by using TSQL to find out what that process is exactly and what is it doing? i.e. query for locks on database with long wait time and how to force them to release, or prevent them?
Try sp_lock #ProcessID then pick out the exclusive locks (mode = X or IX). You can then find out the offending objects using SELECT object_name(id). The ID is obtained from the ObjId column.
Use the Deadlock Graph event in Profiler: See Track Down Deadlocks Using SQL Server 2005 Profiler
Can someone tell me what the statuses mean in SQL Server's sp_who command? Why might a spid be suspended? What does it mean to be "runnable"?
Thanks!
Pretty easy to find answer online. Link
dormant. SQL Server is resetting the session.
running. The session is running one or more batches. When Multiple Active Result Sets (MARS) is enabled, a session can run multiple batches. For more information, see Using Multiple Active Result Sets (MARS).
background. The session is running a background task, such as deadlock detection.
rollback. The session has a transaction rollback in process.
pending. The session is waiting for a worker thread to become available.
runnable. The session's task is in the runnable queue of a scheduler while waiting to get a time quantum.
spinloop. The session's task is waiting for a spinlock to become free.
suspended. The session is waiting for an event, such as I/O, to complete.
I believe that part of the confusion on this is that there are statuses outside of the list shown above that are seen. Three that come to mind are
Sleeping
Awaiting Command
Other