Avoiding huge rollback [message #434738] |
Thu, 10 December 2009 08:10 |
prajjwal
Messages: 28 Registered: January 2008 Location: kolkata
|
Junior Member |
|
|
Hi,
My question is.. I am doing a large select insert into a table T1.. To start with T1 does not have any data.. Say, for some reasons, I am not using an append nologging hint.. Meanwhile somebody kills my session... The transaction has to go through a huge rollback!!
Since, T1 had no data to start with, the rollback is least important to me.... Would have been great if there was some kind of interim commit option available with a session kill... I could have atleast truncated T1 to reach to the inital state!! However, this is seriously not possible and is very much against RDBMS principles.. seems there is no escape to this huge rollback..
Is there any technique to reach to the initial point without such a big rollback? ..just curious
Regards,
Prajjwal
|
|
|
Re: Avoiding huge rollback [message #434740 is a reply to message #434738] |
Thu, 10 December 2009 08:18 |
cookiemonster
Messages: 13960 Registered: September 2008 Location: Rainy Manchester
|
Senior Member |
|
|
Insert the data in smaller chunks and commit after each.
This won't be as efficient as the way you're currently using.
I really wouldn't worry about this, under normal circumstances your session should never be killed and if that is happening on even a semi-regular basis then I'd suggest you've got a much bigger problem to worry about.
|
|
|
|
Re: Avoiding huge rollback [message #434752 is a reply to message #434738] |
Thu, 10 December 2009 09:18 |
cookiemonster
Messages: 13960 Registered: September 2008 Location: Rainy Manchester
|
Senior Member |
|
|
test the novices insert statement on a test db before letting it anywhere near production?
If someone runs a huge insert there is no nice way to kill it.
We have code review procedures and test procedures to try and make sure situations like that never arise.
|
|
|
|
Re: Avoiding huge rollback [message #434804 is a reply to message #434757] |
Thu, 10 December 2009 19:49 |
rleishman
Messages: 3728 Registered: October 2005 Location: Melbourne, Australia
|
Senior Member |
|
|
You've stumbled on one of the very good reasons why we have DBAs.
The DBA is responsible for EVERY piece of SQL running on the database. You - as the DBA - need to implement policies that stop novices from running SQL that YOU cannot manage.
|
|
|