Every day, a job is connecting to a 2005 SQL Server and performs a dump transaction with truncate_only (or no_log) and breaks my transactions backups sequence.
I checked the Agent and the task scheduler, none of them is hosting such a job.
It occurs every day at 2:38PM, this I know from the server log showing this kind of error :
BACKUP LOG WITH TRUNCATE_ONLY or WITH NO_LOG is deprecated. The simple recovery model should be used to automatically truncate the
transaction log.
After digging in the profiler I could not see any column showing the IP of the sessions, either, I could continuously pull data from this query :
select * from
sys.dm_exec_connections A,
sys.sysprocesses B
where A.session_id = B.spid
But I wonder if I can catch the job since the transaction segment is very small.
On an other side, it would be nice if I could hang the backup itself by locking the transaction file, so I would have the time to see which process is stuck trying to dump the transaction.
Any ideas?
Configure Auditing or a Trace to track the additional information.
You can then look back over the output logs and see where it came from.
Related
I have a SQL Server database and have a linked server connection to an Oracle DB.
I had the following query running on my SQL Server:
INSERT INTO dbo.my_table_on_sql_server
SELECT *
FROM OPENQUERY (linkedservername, ‘SELECT * FROM target_table’)
The target_table has 50 million rows and I'm aware the query takes time to execute but has successfully completed before.
This time though, my PC had an automatic restart in the middle of the query. SSMS 2017 automatically reopened as soon as the PC fired back up, but I could not longer see the query running. my_table_on_sql_server has no data.
I'd like to understand what happens in SQL Server in the event of such a situation. Am I correct in assuming that the query was killed / rolled back? Is there any query running in the background? I've seen some related answers on this forum but wanted to specifically understand this for linked servers, as I use them a lot to retrieve data from other DBs for my job.
I'm more concerned about the Oracle DB as I don't want my query to impact any performance upstream. I only have a read-only access permission to the Oracle DB.
Thank you!
On shutdown the query will be aborted, and the INSERT rolled back. The rollback may happen during shutdown, or after restart, and may take some time to complete.
There's no automatic retry or anything that will access the linked server Oracle after the shutdown.
I'm helping with a rather ad-hoc disaster recovery, and we've restored a database backup from a few weeks ago and then restored transactions from a transaction log backup.
We did this using SQL Server Management Studio - right click on database, restore full backup but leave in recovery mode, right click again, restore transaction log, etc.
I'm now trying to verify that we had no gaps in our logs. Is it safe to assume that if the SQL Server Management Studio allowed me to restore the logs without errors, then there were no gaps in the logs (e.g. the log chain is complete)?
In other words - would SQL let me restore logs if there were gaps? I assume it would warn me or stop me in that case.
Thanks for any help you can offer ....
We're on SQL 2005 but I think the rules about log chains are similar through all versions.
According to the document Working with Transaction Log Backups from Microsoft:
If a log backup becomes missing or damaged, start a new log chain by creating a full or differential database backup and then backing up the transaction log to start a new log chain. We recommend that you retain transaction logs backups that come before a missing log backup, in case you ever want to restore the database to a point in time within those backups. For information about how to help protect your backups, see Security Considerations for Backup and Restore.
and Creating Transaction Log Backups states:
If a transaction log is damaged, work that is performed since the most recent log backup is lost. This highlights the importance of putting the log files on fault-tolerant storage.
My free reading of this is:
Considering a lost file a kind of file damage, if Management Studio or any other tool allows you to restore the logs without errors, you can be sure the log chain is complete until the last transaction log backup you're applying. You must be sure it is the last transaction log backup available for that database, but that is other thing to think about.
If you don't trust my reading (and the documentation is not too clear on this point), you can make a simple test to be sure: Say you have 10 transaction logs to apply... deliberately delete the 7th (or a random, but not the first nor the last) transaction log, and try your disaster recovery method.
If you get a error saying something like "a transaction log file backup is missing", you can be sure and trust me.
You are correct. SQL will not apply a transaction log backup if it can't be applied, you would have gotten an error.
Oracle has SQL commands that one can issue so that a transaction does not get logged. Is there something similar for SQL Server 2008?
My scenario: We need Tx logs on servers (Dev, QA, Prod), but maybe we can do without them on developer machines.
You can't do without transaction logs in SQL Server, under any circumstances. The engine simply won't function.
You CAN set your recovery model to SIMPLE on your dev machines - that will prevent transaction log bloating when tran log backups aren't done.
ALTER DATABASE MyDB SET RECOVERY SIMPLE;
There is a third recovery mode not mentioned above. The recovery mode ultimately determines how large the LDF files become and how ofter they are written to. In cases where you are going to be doing any type of bulk inserts, you should set the DB to be in "BULK/LOGGED". This makes bulk inserts move speedily along and can be changed on the fly.
To do so,
USE master ;
ALTER DATABASE model SET RECOVERY BULK_LOGGED ;
To change it back:
USE master ;
ALTER DATABASE model SET RECOVERY FULL ;
In the spirit of adding to the conversation about why someone would not want an LDF, I add this: We do multi-dimensional modelling. Essentially we use the DB as a large store of variables that are processed in bulk using external programs. We do not EVER require rollbacks. If we could get a performance boost by turning of ALL logging, we'd take it in a heart beat.
SQL Server requires a transaction log in order to function.
That said there are two modes of operation for the transaction log:
Simple
Full
In Full mode the transaction log keeps growing until you back up the database. In Simple mode: space in the transaction log is 'recycled' every Checkpoint.
Very few people have a need to run their databases in the Full recovery model. The only point in using the Full model is if you want to backup the database multiple times per day, and backing up the whole database takes too long - so you just backup the transaction log.
The transaction log keeps growing all day, and you keep backing just it up. That night you do your full backup, and SQL Server then truncates the transaction log, begins to reuse the space allocated in the transaction log file.
If you only ever do full database backups, you don't want the Full recovery mode.
What's your problem with Tx logs? They grow? Then just set truncate on checkpoint option.
From Microsoft documentation:
In SQL Server 2000 or in SQL Server
2005, the "Simple" recovery model is
equivalent to "truncate log on
checkpoint" in earlier versions of SQL
Server. If the transaction log is
truncated every time a checkpoint is
performed on the server, this prevents
you from using the log for database
recovery. You can only use full
database backups to restore your data.
Backups of the transaction log are
disabled when the "Simple" recovery
model is used.
If this is only for dev machines in order to save space then just go with simple recovery mode and you’ll be doing fine.
On production machines though I’d strongly recommend that you keep the databases in full recovery mode. This will ensure you can do point in time recovery if needed.
Also – having databases in full recovery mode can help you to undo accidental updates and deletes by reading transaction log. See below or more details.
How can I rollback an UPDATE query in SQL server 2005?
Read the log file (*.LDF) in sql server 2008
If space is an issue on production machines then just create frequent transaction log backups.
My application (C++ using SQL Native Client with SQL Server 2000) is consistently finding its way into a hanging state. I believe this is because a transaction is left uncommitted someplace on a table and a SELECT query on that table, as a result of the open transaction, is blocking.
Unfortunately, I'm really having trouble determining where the hanging transaction might be in my code. Is there any way to get SQL Server to indicate what queries have been run on an uncommitted transaction?
if you have admin (sa) proviliges, you can run sp_Who, or sp_Who2
to show all server activity, by Spid, Run
Exec sp_Who2 [SpidNumber]
to just see the one session you are interested in...
To directly see open transactions, run
DBCC OPENTRAN (T-SQL)
Displays information about the oldest active transaction and the oldest distributed and nondistributed replicated transactions, if any, within the specified database. Results are displayed only if there is an active transaction or if the database contains replication information. An informational message is displayed if there are no active transactions.
Syntax
DBCC OPENTRAN
( {'database_name' | database_id}
) [ WITH TABLERESULTS [, NO_INFOMSGS]
]
Sql Server should, however, automatically rollback any open transaction when a user session is terminated.
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.