I have recently tried a big merge of 2 databases. We recreated the schema from Database 2 into Database 1 and created a script to transfer all data from database 2 into Database 1. This script takes about 35 min to run and have transaction handling with:
BEGIN TRANSACTION
...
IF(##error<>0)
COMMIT TRANSACTION
ELSE
ROLLBACK TRANSACTION
The full script is a bit sensitive but here is some SQL that have the same structure: http://pastebin.com/GWJ3ZnkF
We ran the script and all data was transfered without errors. We tested the systems running with the new combined database (removed access rights to the old database).
But as a last task we wanted to take the old database offline to make sure no one used that database. To do this we used:
ALTER DATABASE <dbname> SET OFFLINE WITH ROLLBACK IMMEDIATE
This was bad. After this line of SQL code all data in the combined database that we just copied was suddenly gone. I first asumed it wasn't really finished so the "Rollback immediate" sounds like it have performed a rollback on my transaction..
But why? Wasn't the transaction allready committed?
Also I tried running the same script again a few times but after every attempt no data was copied even if it said the script was successfull. I have no idea why... did it remember my offline rollback somehow?
What is really happening to my connections?
Sounds like you had a pending transaction uncommitted and you forced it to rollback, loosing some of the work. The rest is explained by how your scripts are structured. Is unlikely your script had a single transaction from start to bottom. Only the last transaction was rolled back, so the database was left now in a state in which it is 'half copied'. Probably your script does various checks and this intermediate state sends the script on the 'ELSE' branches where it does not do the proper work (ie. apparently does nothing).
W/o posting the exact script, is all speculation anyway.
Right now you need to restore the database to a consistent state, the one before your data copy. Use the backup you took before the data move (you did take a backup, right?). for extra credit, make sure your script is idempotent and works correctly on a half-updated database.
I'd double-check to make sure that there are no outstanding transactions. Either go through the file and count the number of BEGIN TRANSACTION vs COMMIT TRANSACTION lines, or add a statement to the end of it to SELECT ##TRANCOUNT to ensure that there are no open transactions remaining.
If your data has been committed, there should be no way it can be lost by disconnecting you.
WITH ROLLBACK IMMEDIATE:
All incomplete transactions will be rolled back and any other
connections to the database will be
immediately disconnected.
Sounds like someone got the 2 databases mixed up or maybe there is an outstanding transaction?.... Can you post your entire script?
Ref: ALTER DATABASE.
Rather than only checking ##ERROR, inspect ##TRANCOUNT as well.
Related
My web application is connected to a SQL Server 2016 Express database, and we have been plagued by data locks in certain areas of the system.
My colleague noticed just today that, when a KILL process was used to kill a long-running transaction, that several transactions that had ostensibly already been committed were rolled-back.
I have checked using #vladV's script on In SQL Server, how do I know what transaction mode I'm currently using? that in fact the database seems to be in auto-commit mode.
So therefore it must be that that something in the database is opening a new transaction and not committing it.
So I found in the database four stored procedures which contain the following
SET IMPLICIT_TRANSACTIONS ON
... code ...
IF ##TRAN_COUNT>0 COMMIT WORK
Am I right in saying that in some/most situations such a stored procedure would leave transactions open, even after exiting the stored procedure, and that this could be the source of the data-lock problems?
And if so, then could I just remedy the code by doing
SET IMPLICIT_TRANSACTIONS OFF
when the stored procedure exits?
Am I right in saying that in some/most situations such a stored procedure would leave transactions open
Some. Depends on what comes after. With IMPLICIT TRANSACTIONS in SQL Server, transactions are not automatically started until you run a query that reads the database.
could I just remedy the code by doing SET IMPLICIT_TRANSACTIONS OFF
No. That won't end any open transactions.
Note that COMMIT doesn't reduce the ##trancount to 0. It decrements it by 1. So if you have multiple BEGIN TRAN statements, or an explicit BEGIN TRAN after an transaction has implicitly begun, then you will need multiple COMMITs.
You might try
WHILE ##trancount > 0 COMMIT TRANSACTION
which will definitely commit any outstanding transactions.
Sometimes when (for example) setting a database offline by executing the following command, an exception will be thrown, because one or more clients is connected:
ALTER DATABASE <dbname> SET OFFLINE
According to this answer one solution is to use with rollback immediate at the end:
ALTER DATABASE <dbname> SET OFFLINE WITH ROLLBACK IMMEDIATE
But why is actually this disconnecting other clients? It sounds like a very non-obvious way to force disconnections, although it works.
You can't take the database offline while other Users have transactions running on it so you're going to have to disconnect the users one way or another to take the database offline.
If you were being polite you could ask all your users to finish doing whatever they were doing before you took the database offline
but if that's not practical including the option
WITH ROLLBACK IMMEDIATE
Means that all current transactions are Rolled back (the database is reset to the point where the transaction started) . You could also use
WITH ROLLBACK AFTER 60 SECONDS
but I've never had to
If you could take a database offline while there were unfinished transactions were running then the database would be in an unstable state with the change neither made nor cancelled
From MSDN
WITH <termination>::=
Specifies when to roll back incomplete transactions when the database
is transitioned from one state to another. If the termination clause
is omitted, the ALTER DATABASE statement waits indefinitely if there
is any lock on the database. Only one termination clause can be
specified, and it follows the SET clauses.
Where termination would be ROLLBACK IMMEDIATE in your case.
I have some very strange problems. I have an application running on Windows 2003 terminal server from multiple clients. The application uses SQL Server 2008 Express as its database.
Yesterday, I connected to the app, closed some sessions on the server that were not responding, and to my surprise, I saw that some data was missing from the database. After a futher search I found that all the database changes made from last week were lost.
It's like the database rolled back all the changes, and returned to the state of one week ago! I can confirm that all the changes were lost. In fact I have inserted a record into a table with identity_insert ON (to manually insert an ID on an autonumeric col) and that record is missing, so there is no way this is a program failure.
Does anyone have any idea of what could have happend here?
EDIT
I have a suspect: could a transaction initiated by a session stays in a unconfirmed state for one week, retain all the database changes and when I close the session rollback all the changes made?
EDIT II
Find this on log:
SQL Server never rolls back a database to a previous state (like this). The database was restored, or the entire disk/VM was rolled back, or DML was executed to create the impression that a rollback happened (but really didn't). Maybe someone executed a sync tool in the wrong direction.
The question does not have information that allows for finding the problem. But it certainly isn't SQL Server rolling back a database.
You can try examining the log using fn_dblog.
From the log it looks like the server has only just started up after a reboot or service restart.
If a database is not cleanly shut down then the database can be left with partially applied transactions. If this happens then the database is recovered on start up.
Any transactions that are incomplete are rolled back. Committed transactions that were not yet applied are rolled forwards. How long this recovery takes depends on the size of the transactions in the log that have not yet been applied to the database.
The transactions may not show up in the log after they have been rolled back following a crash. This depends upon their location in the log and the databases's recovery mode.
If the transaction is at the end of the log it is likely the log will just be rolled back and the transaction removed.
If the transaction is in the middle of the log you might see a LOP_ABORT_XACT in the log.
When using simple recovery there is a good chance the log will be cleared after recovery (since the logs are only kept until the transactions are committed).
See Are log records removed from ldf file for rollbacks? for more details.
I have a database on SqlServer 2012 Enterprise with Recovery model set to 'Simple'.
When data gets pushed into it and I check the resource monitor on the server, I see that MyDB_dat.mdf gets written to with 20MB/sec, and MyDB_log.ldf gets 30MB/sec.
Both files are op separate disks.
I drop all indexes except the clustered ones.
How can I prevent this IO on the Log file? The database is completely redundant so I couldn't care less about the log.
You can't. In simple recovery mode you can still do BEGIN TRAN then COMMIT/ROLLBACK, and more significantly each statement is transactional, so everything has to be written to the log. The thing about simple recovery mode is that the log space is re-used as soon as the transaction (or statement) is complete - there's no waiting until a log backup has been done.
In simple mode Logs truncate when a checkpoint occurs. There is no way to write (or update) in SQL Server without writing to the Log file. The number, and types of indexes only affects how fast, potentially, SQL Server finds the relevant rows. You need a commit followed by a checkpoint (which happens automatically or by having a script issue a 'checkpoint' command) for the log to truncate.
I was investigating the rapid growth of a SQL Server 2005 transaction log when I found that transaction logs will only truncate correctly - if the sys.databases "log_reuse_wait" column is set to 0 - meaning that nothing is keeping the transaction log from reusing existing space.
One day when I was intending to backup/truncate a log file, I found that this column had a 4, or ACTIVE_TRANSACTION going on in the tempdb. I then checked for any open transactions using DBCC OPENTRAN('tempdb'), and the open_tran column from sysprocesses. The result was that I could find no active transactions anywhere in the system.
Are the settings in the log_reuse_wait column accurate? Are there transactions going on that are not detectable using the methods I described above? Am I just missing something obvious?
I still don't know why I was seeing the ACTIVE_TRANSACTION in the sys.databases log_reuse_wait_desc column - when there were no transactions running, but my subsequent experience indicates that the log_reuse_wait column for the tempdb changes for reasons that are not very clear, and for my purposes, not very relevant. Also, I found that running DBCC OPENTRAN, or the "select open_tran from sysprocess" code, is a lot less informative than using the below statements when looking for transaction information:
select * from sys.dm_tran_active_transactions
select * from sys.dm_tran_session_transactions
select * from sys.dm_tran_locks
Here there are explanations how log_reuse_wait_desc is working:
We also need to understand how the log_reuse_wait_desc reporting mechanism works. It gives the reason why log truncation couldn’t happen the last time log truncation was attempted. This can be confusing – for instance if you see ACTIVE_BACKUP_OR_RESTORE and you know there isn’t a backup or restore operation running, this just means that there was one running the last time log truncation was attempted.
So in your case there is no ACTIVE TRANSACTION right now, but it was when log truncation was attempted last time.
There are a couple of links to additional tools/references you can use to help troubleshoot this problem on the References link for this video:
Managing SQL Server 2005 and 2008 Log Files
That said, the information in log_reuse_wait should be accurate. You likely just had a stalled or orphaned transaction that you weren't somehow able to spot.
My answer from The Log File for Database is Full:
As soon as you take a full backup of the database, and the database is not using the Simple recovery model, SQL Server keeps a complete record of all transactions ever performed on the database. It does this so that in the event of a catastrophic failure where you lose the data file, you can restore to the point of failure by backing up the log and, once you have restored an old data backup, restore the log to replay the lost transactions.
To prevent this building up, you must back up the transaction log. Or, you can break the chain at the current point using the TRUNCATE_ONLY or NO_LOG options of BACKUP LOG.
If you don't need this feature, set the recovery model to Simple.
The data is probably accurate. What you need to do is have a regular transaction log backup. Contrary to other advice you should NOT use the NO_TRUNCATE option on 2005 as it clears the log of transactions committed but it doesn't back them up.
What you should be doing is performing a tail-log backup by using the BACKUP LOG statement with NO_TRUNCATE option. You should be applying regular transaction logs throughout the day as well. This should help keep the size fairly manageable.
Hm, tricky. Could it be that the question it self to sys.databases is causing the ACTIVE_TRANSACTION? In that case though, it should be in the MASTER and not the TEMPDB.