I'm following instructions here to save database state and restore it from any state i previously saved. I cannot however get the RESTORE given in the example there working. I always get a message
This log file contains records logged
before the designated mark. The
database is being left in the
Restoring state so you can apply
another log file.
I think the problem is with the FILE version, but from what I see in the example, it should be N in DB and N-1 in Log, and that's how I always set it. Any help would be appreciated.
It sounds like you need to apply more transaction logs. You have to first restore the database with a full backup to some point in the past. You may then restore zero or more differential backups (in order) to skip forward as far as possible. Finally, you have to restore every transaction log that has log records beginning from the start of the most recently restored backup (full or differential) all the way up to the restore time in question.
RESTORE DATABASE Blah FROM DISK = 'blah 201105210000.bak' WITH NORECOVERY;
RESTORE LOG Blah_Log FROM DISK = 'blah 201105210100.trn' WITH NORECOVERY;
RESTORE LOG Blah_Log FROM DISK = 'blah 201105210200.trn' WITH NORECOVERY;
RESTORE LOG Blah_Log FROM DISK = 'blah 201105210300.trn' WITH NORECOVERY;
RESTORE LOG Blah_Log FROM DISK = 'blah 201105210400.trn' WITH NORECOVERY;
RESTORE LOG Blah_Log FROM DISK = 'blah 201105210500.trn' WITH STOPAT 'x', RECOVERY;
My syntax may not be perfect but the concept is solid, you have to restore all the transaction logs in order. If you pick a t-log that is too early you get a message about that, or if you pick one that is too late you'll get a different message. The message you posted indicates to me that the t-log you're trying to apply has log records entirely before the transaction id of the last restore applied. Find more t-logs from after that.
If t-logs shouldn't be missing but are, look in the SQL jobs or maintenance plans to see if you have two t-log backups going on different schedules. If this was happening, you must collect all the t-logs from both the backups as only all together can they be a proper and unbroken chain that will let you restore up to the point in time you want.
I couldn't get the example to work either unless I changed the last statement to the name of the transaction, rather than the description. (SQL Server Express 2017)
RESTORE LOG AdventureWorks2012
FROM AdventureWorksBackups
WITH FILE = 4,
RECOVERY,
STOPATMARK = 'ListPriceUpdate';
When the STOPAT argument is specified, SQL Server (2008 Express at least) appears to assume the NORECOVERY option even when RECOVERY is specified. I assume that's why it generates the message (not an actual error, correct?). To complete the operation, an additional step may be added to the process.
...
RESTORE LOG Blah_Log FROM DISK = 'blah 201105210500.trn' WITH STOPAT 'x' WITH NORECOVERY;
RESTORE DATABASE Blah_Log WITH RECOVERY;
Related
I am getting one issue though with my log files. I restore my full and any diffs if I have any successfully. However with my Logs I get the following error message. Is this because I would need to take backups of my copy version of my DB.
SET #LogBackupSQL = 'RESTORE LOG '+#DatabaseNameCopy+' FROM DISK = '''+#LogbackupFile+''' WITH REPLACE, FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5,'
error message
The tail of the log for the database "ns_lots_of_vlfs_Copy" has not been backed up. Use BACKUP LOG WITH NORECOVERY to backup the log if it contains work you do not want to lose. Use the WITH REPLACE or WITH STOPAT clause of the RESTORE statement to just overwrite the contents of the log.
i'm working on huge DB, and while insert\work with big files, log file increase to 60GB and over, and eat all my drive so it can't continue processing.
i tried shrink log file but it work afterwards, and while working it increase again so i thought to move the log file (only) to my 2nd drive where i got more space.
i tried by Detach and Attach but it didnt work , error :
An error occurred when attaching the database(s). Click the hyperlink
in the Message column for details.
i also tried manually by alter command:
ALTER DATABASE [databasename]
MODIFY FILE ( NAME = filename , FILENAME = "new file location and name");
but it make the DB "recovery pending" and i had to restore it back from backup.
any other options?
Since you restored from backup, you can add the MOVE command to your restore command to move the log file to a new drive during the restore.
USE [master]
GO
RESTORE DATABASE [YourDatabase] FROM DISK = 'c:\mssql\backup\Full.bak'
WITH CHECKSUM,
MOVE 'YourDatabase_Log' TO 'E:\newdir\Log.ldf',
RECOVERY, REPLACE;
In order to keep your log file from growing too much, you need to increase the frequency of your log backups, assuming you aren’t on SIMPLE RECOVERY MODEL. Shrinking without backing up is not going to do much, if anything at all. When you backup a log file, the committed transactions are backed up and cleared from the log, freeing up space. As you have witnessed your log file will continue to grow based on the workload. Thus, regular shrinking of the log file isn’t really going to help you.
We're currently migrating our LIMS (Laboratory Information Management System) from Oracle to MS-SQL, and I'm having difficulty in a a certain area. We run three separate instances: Production, Development & Test. The Prod instance is the live one, being used by the laboratories, the dev instance is where I mess around developing new features, and the test instance is where those new features get tested before deployment to production. This being the case, I periodically copy (using backup/restore) the production database to the other two instances, so that I'm working with the same configuration as the operators. However, the production DB contains a large amount of archived data which I don't need in the dev/test instances, so I don't include those tables in the backup - this saves me tens of minutes in the process. Oracle is good for this because you can specify the tables to be included in a backup. However, AFAIK this isn't possible in MS-SQL, but what can be done is to put the active and archive tables into different filegroups. These can then be backed up separately.
I've successfully created a backup of my PRIMARY filegroup, but I'm having great difficulty restoring it. Sometimes the command completes but the database remains inaccessible and I'm told that the restore has not completed - other times it just refuses to execute the command. This seems to be related to the transaction log, but this stretches my knowledge.
The backup command I'm using is:
BACKUP DATABASE production FILEGROUP='PRIMARY' TO DISK='C:\Temp\db.bak' WITH FORMAT,COPY_ONLY
The restore command I'm trying is:
RESTORE DATABASE development FROM DISK='C:\Temp\db.bak' WITH REPLACE,NORECOVERY and it tells me that 'The backup set holds a backup of a database other than the existing 'development' database'.
At the moment the source and dest are in the same instance of SQL Server, but in future they will be on completely different machines, possibly with no direct connectivity (so I have to go via some type of file transfer). Both are configured with Full recovery.
I've found a few similar questions, but they haven't really helped me. Is this a reasonable way to create this partial clone of my production database? How do I get my restore command to work as I need it to?
You are on the right track, but you need to backup the tail log as well since you are in FULL recovery model, and restore the log files since the last backup of the filegroup. If the log backups are happening infrequent (like every hour) then you only need to take the tail log backup and restore this single log file after you restore the filegroup. You also need to add WITH PARTIAL and FILEGROUP = 'PRIMARY' to the restore command.
It would look something like this:
BACKUP DATABASE production FILEGROUP='PRIMARY' TO DISK='C:\Temp\db.bak' WITH FORMAT
GO
BACKUP LOG productionLog TO DISK 'C:\Temp\tail.trn'
GO
RESTORE DATABASE development FILEGROUP = 'Primary' FROM DISK='C:\Temp\db.bak' WITH PARTIAL,NORECOVERY
RESTORE LOG FROM DISK 'C:\Temp\tail.trn' WITH RECOVERY
Thanks very much for the suggestion - it's moved me on but I'm still having problems. I'm now using the following commands:
BACKUP DATABASE Prod FILEGROUP='PRIMARY' TO DISK='C:\Temp\Temp\prod.bak' WITH FORMAT;
BACKUP LOG Prod TO DISK='C:\Temp\Temp\prod.trn';
RESTORE DATABASE Test FILEGROUP='PRIMARY' FROM DISK='C:\Temp\Temp\prod.bak' WITH PARTIAL,RECOVERY;
RESTORE LOG Test FROM DISK='C:\Temp\Temp\prod.trn' WITH RECOVERY;
and I get the following response:
Processed 376 pages for database 'Prod', file 'Prod' on file 1.
Processed 2 pages for database 'Prod', file 'Prod_log' on file 1.
BACKUP DATABASE...FILE=<name> successfully processed 378 pages in 0.082 seconds (36.013 MB/sec).
Processed 7 pages for database 'Prod', file 'Prod_log' on file 6.
BACKUP LOG successfully processed 7 pages in 0.007 seconds (7.254 MB/sec).
Msg 3154, Level 16, State 4, Line 3
The backup set holds a backup of a database other than the existing 'Test' database.
Msg 3013, Level 16, State 1, Line 3
RESTORE DATABASE is terminating abnormally.
Msg 3154, Level 16, State 4, Line 4
The backup set holds a backup of a database other than the existing 'Test' database.
Msg 3013, Level 16, State 1, Line 4
RESTORE LOG is terminating abnormally.
If I use WITH REPLACE instead of WITH PARTIAL I get a different error message:
The database cannot be recovered because the log was not restored.
The roll forward start point is now at log sequence number (LSN) 35000000203200001. Additional roll forward past LSN 35000000203200001 is required to complete the restore sequence.
This RESTORE statement successfully performed some actions, but the database could not be brought online because one or more RESTORE steps are needed. Previous messages indicate reasons why recovery cannot occur at this point.
RESTORE DATABASE ... FILE=<name> successfully processed 378 pages in 0.024 seconds (123.046 MB/sec).
Msg 4326, Level 16, State 1, Line 4
The log in this backup set terminates at LSN 35000000092800001, which is too early to apply to the database. A more recent log backup that includes LSN 35000000203200001 can be restored.
Msg 3013, Level 16, State 1, Line 4
RESTORE LOG is terminating abnormally.
If I use WITH NORECOVERY on the database restore, that command succeeds but the RESTORE LOG then gives me:
RESTORE DATABASE ... FILE=<name> successfully processed 378 pages in 0.032 seconds (92.285 MB/sec).
Msg 4326, Level 16, State 1, Line 4
The log in this backup set terminates at LSN 35000000092800001, which is too early to apply to the database. A more recent log backup that includes LSN 35000000203200001 can be restored.
Msg 3013, Level 16, State 1, Line 4
RESTORE LOG is terminating abnormally.
In any case, the destination database is stuck in the 'Restoring' state.
I have a database that has a 28gig transaction log file. Recovery mode is simple. I just took a full backup of the database, and then ran both:
backup log dbmcms with truncate_only
DBCC SHRINKFILE ('Wxlog0', TRUNCATEONLY)
The name of the db is db_mcms and the name of the transaction log file is Wxlog0.
Neither has helped. I'm not sure what to do next.
Thank you to everyone for answering.
We finally found the issue. In sys.databases, log_reuse_wait_desc was equal to 'replication'. Apparently this means something to the effect of SQL Server waiting for a replication task to finish before it can reuse the log space.
Replication has never been used on this DB or this server was toyed with once upon a time on this db. We cleared the incorrect state by running sp_removedbreplication. After we ran this, backup log and dbcc shrinkfile worked just fine.
Definitely one for the bag-of-tricks.
Sources:
http://social.technet.microsoft.com/Forums/pt-BR/sqlreplication/thread/34ab68ad-706d-43c4-8def-38c09e3bfc3b
http://www.eggheadcafe.com/conversation.aspx?messageid=34020486&threadid=33890705
You may run into this problem if your database is set to autogrow the log & you end up with lots of virtual log files.
Run DBCC LOGINFO('databasename') & look at the last entry, if this is a 2 then your log file wont shrink. Unlike data files virtual log files cannot be moved around inside the log file.
You will need to run BACKUP LOG and DBCC SHRINKFILE several times to get the log file to shrink.
For extra bonus points run DBBC LOGINFO in between log & shirks
'sp_removedbreplication' didn't solve the issue for me as SQL just returned saying that the Database wasn't part of a replication...
I found my answer here:
http://www.sql-server-performance.com/forum/threads/log-file-fails-to-truncate.25410/
http://blogs.msdn.com/b/sqlserverfaq/archive/2009/06/01/size-of-the-transaction-log-increasing-and-cannot-be-truncated-or-shrinked-due-to-snapshot-replication.aspx
Basically I had to create a replication, reset all of the replication pointers to Zero; then delete the replication I had just made.
i.e.
Execute SP_ReplicationDbOption {DBName},Publish,true,1
GO
Execute sp_repldone #xactid = NULL, #xact_segno = NULL, #numtrans = 0, #time = 0, #reset = 1
GO
DBCC ShrinkFile({LogFileName},0)
GO
Execute SP_ReplicationDbOption {DBName},Publish,false,1
GO
Don't you need this
DBCC SHRINKFILE ('Wxlog0', 0)
Just be sure that you are aware of the dangers: see here: Do not truncate your ldf files!
And here Backup Log with Truncate_Only: Like a Bear Trap
This answer has been lifted from here and is posted here in case the other thread gets deleted:
The fact that you have non-distributed LSN in the log is the problem.
I have seen this once before not sure why we dont unmark the
transaction as replicated. We will investigate this internally. You
can execute the following command to unmark the transaction as
replicated
EXEC sp_repldone #xactid = NULL, #xact_segno = NULL, #numtrans = 0, #time = 0, #reset = 1
At this point you should be able to truncate the log.
I've had the same issue in the past. Normally a shrink and a trn backup need to occur multiple times. In extreme cases I set the DB to "Simple" recovery and then run a shrink operation on the log file. That always works for me. However recently I had a situation where that would not work. The issue was caused by a long running query that did not complete, so any attempts to shrink were useless until I could kill that process then run my shrink operations. We are talking a log file that grew to 60 GB and is now shrunk to 500 MB.
Remember, as soon as you change from FULL to Simple recovery mode and do the shrink, dont forget to set it back to FULL. Then immediately afterward you must do a FULL DB backup.
If you set the recovery mode on the database in 2005 (don't know for pre-2005) it will drop the log file all together and then you can put it back in full recovery mode to restart/recreate the logfile. We ran into this with SQL 2005 express in that we couldn't get near the 4GB limit with data until we changed the recovery mode.
I know this is a few years old, but wanted to add some info.
I found on very large logs, specifically when the DB was not set to backup transaction logs (logs were very big), the first backup of the logs would not set log_reuse_wait_desc to nothing but leave the status as still backing up. This would block the shrink. Running the backup a second time properly reset the log_reuse_wait_desc to NOTHING, allowing the shrink to process.
Have you tried from within SQL Server management studio with the GUI. Right click on the database, tasks, shrink, files. Select filetype=Log.
I worked for me a week ago.
Try creating another full backup after you backup the log w/ truncate_only (IIRC you should do this anyway to maintain the log chain). In simple recovery mode, your log shouldn't grow much anyway since it's effectively truncated after every transaction. Then try specifying the size you want the logfile to be, e.g.
-- shrink log file to c. 1 GB
DBCC SHRINKFILE (Wxlog0, 1000);
The TRUNCATEONLY option doesn't rearrange the pages inside the log file, so you might have an active page at the "end" of your file, which could prevent it from being shrunk.
You can also use DBCC SQLPERF(LOGSPACE) to make sure that there really is space in the log file to be freed.
Try to use target size you need insted of TRUNCATEONLY in DBCC:
DBCC SHRINKFILE ('Wxlog0', 1)
And check this to articles:
http://msdn.microsoft.com/en-us/library/ms189493(SQL.90).aspx
http://support.microsoft.com/kb/907511
Edit:
You can try to move allocated pages to the beginning of the log file first with
DBCC SHRINKFILE ('Wxlog0', NOTRUNCATE)
and after that
DBCC SHRINKFILE ('Wxlog0', 1)
Put the DB back into Full mode, run the transaction log backup (not just a full backup) and then the shrink.
After it's shrunk, you can put the DB back into simple mode and it txn log will stay the same size.
I had the same problem. I ran an index defrag process but the transaction log became full and the defrag process errored out. The transaction log remained large.
I backed up the transaction log then proceeded to shrink the transaction log .ldf file. However the transaction log did not shrink at all.
I then issued a "CHECKPOINT" followed by "DBCC DROPCLEANBUFFER" and was able to shrink the transaction log .ldf file thereafter
You cannot shrink a transaction log smaller than its initially created size.
I tried all the solutions listed and none of them worked. I ended up having to do a sp_detach_db, then deleting the ldf file and re-attaching the database forcing it to create a new ldf file. That worked.
We have a warm sql backup. full backup nightly, txn logs shipped every so often during the day and restored. I need to move the data files to another disk. These DB's are in a "warm backup" state (such that I can't unmark them as read-only - "Error 5063: Database '<dbname>' is in warm standby. A warm-standby database is read-only.
") and am worried about detaching and re-attaching.
How do we obtain the "warm backup" status after detach/attach operations are complete?
The only solution I know is to create a complete backup of your active database and restore this backup to a copy of the database in a 'warm backup' state. First create a backup from the active db:
backup database activedb to disk='somefile'
Then restore the backup on another sql server. If needed you can use the WITH REPLACE option to change the default storage directory
restore database warmbackup from disk='somefile'
with norecovery, replace ....
Now you can create backups of the logs and restore them to the warmbackup with the restore log statement.
It looks like you didn't complete the restore task , just do the restore task only for the TRANSACTOINAL LOG .Then it will be fine immediately when you finish that.