XACT_ABORT and Transaction

Specifies whether SQL Server automatically rolls back the current transaction when a Transact-SQL statement raises a run-time error. The THROW statement honors SET XACT_ABORT. RAISERROR does not. New applications should use THROW instead of RAISERROR. When SET XACT_ABORT is ON, if a Transact-SQL statement raises a run-time error, the entire transaction is terminated and rolled... » read more

Begin Tran with Error

Transactions are intended to run completely or not at all. The only way to complete a transaction is to commit, any other way will result in a rollback. Therefore, if you begin and then not commit, it will be rolled back on connection close (as the transaction was broken off without marking as complete). As... » read more

Copy Data from PROD to DEV

PROD DB -> Localhost DB -> DEV DB Create database on Localhost On Localhost, create Linked Server to PROD DB Copy data from PROD DB to Localhost DB Once the data is in Localhost, create a SQL backup of the Localhost database Copy the backup file to DEV DB and restore the database to DEV... » read more

AlwaysOn and Transaction Log

Availability Groups must retain all transaction log records until they have been distributed to all secondary replicas. Slow synchronization to even a single replica will prevent log truncation. If the log records cannot be truncated your log will likely begin to grow. This becomes a maintenance concern because you either need to continue to expand... » read more

AlwaysOn Synchronous vs Asynchronous

Availability modes There are two availability modes, synchronous commit and asynchronous commit. Selecting a mode is equivalent to selecting whether you want to favor data protection or transaction performance. Both availability modes follow the same work flow, with one small yet critical difference. With synchronous commit mode, the application does not receive confirmation that the... » read more