views:

400

answers:

4

I have a dotnet applicaton that executes a set of insert,update,delete statements in transactionaly manner

The code is like this

try
{
mytrans = mycon.begintransaction();
//execute sql statements
mytrans.commit();
}
catch(Exception)
{
mytrans.rollback();
}

The problem is that sometimes we faced timeout exceptions in rollback and I found that the database size (mdf file) increased!!! So it means Sql will not make implicit rollback? if so how can I recover from this error and go to the original state???

+1  A: 

Any SQL that may have executed will not have yet been committed. If your Rollback for some reason timeouts that won't result in a commit. Hence eventually the DB will realise its all gone pearshaped and will discard the changes.

An increase in MDF size is not an indication that the transaction has been committed. However the results of the transaction need to be put somewhere. The committing of transaction should require the smallest change possible in the DB. Hence pages may be allocated and data written and then on commit just a few other bits pointing in all the right places are tweaked.

If there is a rollback those last few bits are not tweaked and those allocated pages simply become free pages to be used for other things. You can't expect the DB to just shrink again.

AnthonyWJones
+1  A: 

The fundamental concept of transactions demands that transactions that are not committed do not affect the state of the database.

File size does not mean anything. RDBMS data structures are far more complex than simply adding a line to a file - they include logs and indices, so the file can grow and shrink quite independently from the amount of data in the DB.

Michael Borgwardt
So it means the transaction that is not commited will be implicitly rollback, is not it? if so What is the aim of rollback method
Ahmed Said
Yes, a transaction that is not committed is implicitly rolled back when the DB connection is closed (possibly by a timeout). The point of the rollback method is to give your program control over this, since there could be situations where a rollback is caused not by technical problems but by program logic, i.e. the program starts a transaction, does some stuff, then decides to roll back the transaction and do something else instead using the same DB connectionc.
Michael Borgwardt
Ok but my logic says first I am shifting current tables to hisorical tables and then do some processing during this shifting I faced primary key violation exception so the programs tried to rollback and timeout exception occured, after that I found there is redundant values exist in specific historical table!!! this means the sql failed to rollback ( I think so)
Ahmed Said
How do you "shit tables"? By moving individual rows, or by doing something to the entire tables? The latter would be very unusual and could conceivably expose an error in the transaction handling. Or it could be some sort of autocommit happening.
Michael Borgwardt
just insert into from current tables to historical, then truncate current tables
Ahmed Said
A: 

Page slits can survive rollbacks:

http://sqlfool.com/2009/04/page-splitting-rollbacks/

AlexKuznetsov
A: 

Once a Rollback has started it MUST complete. Whether you are still connected or not, SQL Server will still complete the Rollback. Failure to complete a rollback leaves your database transactionaly corrupt and in need of recovery.

RBarryYoung

related questions