killing an Oracle database session dangerous - oracle

I have inherited a database and every night i get buzzed in the middle of the night for locking issues.This database has severe locking issues and the usual drill is to bounce the application tier one by one so the locks get released . I am tired of doing this and came across a documentation where i can go ahead and kill the blocking session .
I am just wondering if i go ahead and kill the database blocking session after a session blocks for a time more then the predefined threshold
do i have the risk of corrupting the database ?
if so how ?
Even if i assume that i am corrupting the database then restarting the application server also is equally risky and more painful for me too.
So what option do i choose here kill automatically the blocking session until the time the developer fixes the code that is causing the blocking ?
regards
Nick

Seems like the exact purpose the Resource Manager directive MAX_IDLE_BLOCKER_TIME was created for.
Example

No , killing a session won't corrupt database as it will be rolled back and generate UNDO , when you killed it , it gives the "marked for kill " message,
do it the normal way "alter system kill session "sid, serial#' , not the "kill -9 .."

Related

Would killing all sessions in Oracle solve my issue?

I'm thinking of killing all my oracle sessions:
Kill all sessions of a user
to solve my Issue on DBA about not being able to replace a package body.
Would you recommend doing this?
"Recommend"? I would (kind of), but you should pay attention to who is using your package because you might kill that user in the middle of some processing. That would release the package and you'll be able to compile it, but - not everyone will be happy about it.
If you're about to kill yourself only (pure suicide, eh?), go ahead - you'll easily reconnect afterwards.
That's why you should deploy changes during OFF hours.

PostgreSQL idle queries, why doesn't the close method kill them? (ruby adapter)

I am seeing a ton of idle queries in psql in the pg_stat_activity table. I am using the Ruby adapter, and creating a new connection every time. But after the query has been run, I close the connection by calling the close or finish method. But I still see a lot of idle queries.
I know idle queries are actually idle processes spun by PG, but I can't find any source explicitly saying this is a bad thing. Some answers on SO suggest that the best way to deal with this is using a cron job to kill the idle process.
Is that the right way do it? Why doesn't the close method kill the process?

Does Apache Derby have a graceful shutdown?

I have a program that starts up the Derby Network Server using the NetworkServerControl API and when I want to shut down the network server, I want to be done gracefully so that no new transactions will start, but all current transactions are given a set amount of time to finish. I see that the API has a shutdown command, but it does not say anything about current ongoing transactions from client connections and whether or not it just kills the process immediately. Does the Derby Network Server handle current and new transactions automatically, or is there a method to stop new client connections and transactions?
I was thinking (and this might be completely wrong) that I could use call setMaxThreads(0) to stop JDBC client connections, but I am not sure what will happen to ongoing transactions if I do.
Thanks in advance.
Consider using table locks to do this. Write a special program which takes table locks on all your important tables, then shuts down the network server.
http://db.apache.org/derby/docs/10.8/ref/rrefsqlj40506.html
DriverManager.getConnection("jdbc:derby:MyDbTest;shutdown=true");
This will close the database gracefully.

Remove deadlock without killing session

Is there any workaround to remove deadlock without killing the session?
From the Concepts Guide:
Oracle automatically detects deadlock situations and resolves them by rolling back one of the statements involved in the deadlock, thereby releasing one set of the conflicting row locks.
You don't have to do anything to remove a deadlock, Oracle takes care of it automatically. The session is not killed, it is rolled back to a point just before the trigger statement. The other session is unaffected (i-e it still waits for the lock until the rolled back session either commits or rolls back its transaction).
In most situations deadlocks should be exceptionally rare. You can prevent all deadlocks by using FOR UPDATE NOWAIT statements instead of FOR UPDATE.
See also
Discussion about removing deadlock on AskTom
Deadlocks are automatically cleared in Oracle by cancelling one of the locked statements. You need not do it manually. One of the sessions will get "ORA-00060" and it should decide whether to retry or roll back.
But from you description it looks like you have a block, not deadlock.
Anyway, blocking session should somehow release its lock -- by commiting or rolling back its transaction. You can just wait for it (possibly for a long time). If you can change code of your application -- you probably can rewrite it to release lock or avoid it. Otherwise, you have to kill session to immediately unlock resources.
No, Oracle 10g does not seem to resolve deadlocks automatically in practice. We did have dealocks and we had to clear the sessions manually.
This page can help in identifying if you have deadlocks
Identifying and Resolving Oracle ITL Deadlock

Session timeout in web applications

The session timeout in web applications typically denotes the idle time - i.e. the period of time when the user doesn't work with the application.
Now, what if there is an automated script written that posts a request every 5 minutes - wouldn't that user's session go on endlessly? This being the case, won't this approach heavily load the application affecting its performance in the long run?
Running an automated call to the server, say via an AJAX request, will keep the session alive. Typically that's the point though. An interesting side effect of this is that if the request happens predictably and regularly, you can use it as a "ping" to determine if the user's browser is still open. If one or two pings are missed, you can close the session earlier and actually free up resources sooner than if you just let the session time out.
Yes, and Yes.
This is why if you're going to write an application for the web, you really want to find a way to implement it without using server side sessions. Usually, you will be able to find ways to implement the same functionality using cookies -- then the session data is client-side so who cares if they stay active permanently.
I did something similar for an application that relies heavily on session data.
What I did was set the IIS timeout to a relatively low number, say 10 minutes, then have a timed AJAX call that pings a blank page every 5 minutes.
This overhead on this is actually fairly low, as all you are doing is requesting a blank page, and if a person closes their browser, the session ends in 10 minutes.
You want to keep session as small as possible. That said, if everyone starts doing that, of course it will load your application, with(out) session. If you think your users are compelled to do that, consider why, as either your application is missing an important feature or is forcing them into something.
Now, regardless of that, if you are expecting lots of users to be active at the same time, so much than a single server won't do, then you would will end up having the session out of process. If the session is in Sql Server, it is just saved data, so in that case we wouldn't be talking about memory usage.
Well... I guess "It Depends" The first question you should ask yourself is whether you even need session.
If you have an automated process, my guess is that you don't really need to use session.
In that case, either turn it off or don't worry about it.
I guess your session table would be a little bit larger, but on the other hand you won't be tearing down and recreating the session. I don't see how this would "heavily load" the application. I suppose it would depend on the application itself and how much memory is used to maintain session state.
It would allow the use's session to go on endlessly, as long as they have their browser open. If need to keep a session alive for an extended period of time, you could also track the sessions via the DB and not in memory.
Also, if you are worried about the indefinite open session, you could implement a timeout from when the session opened and if there is an extended idle time.

Resources