December 19, 2018 at 8:15 am
Hello,
I have a general question regarding best practices for creating a batch process in SQL Server 2016.
All code is residing in the database procedures. I need to make sure that there is a easy way to restart the process in case of failure. A typical batch process will insert/Update multiple rows in multiple tables. In case of a failure how to roll back and restart? Since this is a very complex batch, it is not one big unit where I can have all the code within one begin/end transaction.
My first thought was to take a backup of all the tables that will be affected by this batch. Incase of failure data can be restored from backup and batch can be restarted. There may be 5 or 6 tables that are growing and the upper limit could be half a million records or so in each of the tables.
Is there a better way to implement this process?
Thank you for your valuable time and input.
Regards,
MMuthu
December 19, 2018 at 8:22 am
Miru Seshadri - Wednesday, December 19, 2018 8:15 AMHello,
I have a general question regarding best practices for creating a batch process in SQL Server 2016.
All code is residing in the database procedures. I need to make sure that there is a easy way to restart the process in case of failure. A typical batch process will insert/Update multiple rows in multiple tables. In case of a failure how to roll back and restart? Since this is a very complex batch, it is not one big unit where I can have all the code within one begin/end transaction.
My first thought was to take a backup of all the tables that will be affected by this batch. Incase of failure data can be restored from backup and batch can be restarted. There may be 5 or 6 tables that are growing and the upper limit could be half a million records or so in each of the tables.
Is there a better way to implement this process?Thank you for your valuable time and input.
Regards,
MMuthu
Is your process the only process which modifies these tables?
December 19, 2018 at 8:26 am
Yes, at the time of modification. It is a batch and will be run during off hours.
Thanks
MMuthu
December 21, 2018 at 6:32 pm
Preprocess all your data in staging tables. When you're ready to update the final tables from the staging tables, start with ...
SET XACT_ABORT ON;
BEGIN TRANSACTION
--Jeff Moden
Change is inevitable... Change for the better is not.
December 26, 2018 at 5:50 am
Thank you Jeff. I will try that.
What is the difference between Xact Abort and Rollback transaction? Currently, I have all my data processing code in a Try block with a begin transaction. In the catch block, I have a rollback transaction. Would that be different than XACT ABORT ?
Thank you.
MMuthu
December 26, 2018 at 9:13 am
Miru Seshadri - Wednesday, December 26, 2018 5:50 AMThank you Jeff. I will try that.
What is the difference between Xact Abort and Rollback transaction? Currently, I have all my data processing code in a Try block with a begin transaction. In the catch block, I have a rollback transaction. Would that be different than XACT ABORT ?
Thank you.
MMuthu
XACT_ABORT auto-magically does the rollback and forces discontinuation of the code in multi-statement transactions. You still need the rollback check in the CATCH block to ensure that there's no transaction still in-process, just in case.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 6 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply