Showing posts with label Backup and Restore. Show all posts
Showing posts with label Backup and Restore. Show all posts

Friday, May 8, 2015

SQL Server 2008/2012: Automate restore all transaction log backup files

Hi,
It's been a long time since I posted something on this blog. Had been working a lot on the IBM DB2 databases for the last couple of years. So it was business as usual in SQL Server. Hence, nothing noteworthy in SQL Server to blog about. But here's one script that saved me several hours yesterday.

On one of my servers we had to recover 10 databases using last night's full backup and all subsequent log backups. So in the middle of the night it was going to be huge challenge to manually pick every log backup file to restore.

So wrote this script to create commands to RESTORE log backup files which can be then run in a query window.

Please follow the instructions below to use the script.

1) Set the database name to the variable @dbname
2) Copy all the transaction log backups to a new directory. You can choose to start copying the files
    that  were taken a few minutes before the full backup was taken. You can choose to copy the last
    file you want to be restored based on the recovery point of time.
3) In the following line set the directory where you copied the log backup files to.

    insert into #dir
    exec xp_cmdshell 'dir "C:\Backup\Adventure*.trn" /b'

4) In the following line set the directory to where the log backup files have been copied.
SET @cmd='use master; RESTORE LOG ['+@dbname+'] FROM  DISK = 
        N''C:\Backup\'+@filename+''' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 10'
select (@cmd)

5) Copy the output which should have the RESTORE commands and run them in a new query    
    window.
6) Lastly run the following command to bring the database out of restoring state.

RESTORE DATABASE dbname WITH RECOVERY

############################################################################
use master
set nocount on
DECLARE @filename varchar(2000), @cmd varchar(8000), @dbname varchar(100)

-----------------------Enter the Database name in the next line
SET @dbname='New'

IF  EXISTS (SELECT name FROM tempdb.sys.tables WHERE name like '#dir%') 
begin
   DROP table #dir
end
create table #dir (filename varchar(1000))

-----------------------Enter the path to TRN File in the xp_cmdshell line
insert into #dir
exec xp_cmdshell 'dir "C:\Backup\Adventure*.trn" /b'

delete from #dir where filename is null
DECLARE filecursor CURSOR FOR 
select * from #dir order by filename asc

OPEN filecursor
FETCH NEXT FROM filecursor INTO @filename 

WHILE @@FETCH_STATUS = 0 
BEGIN
SET @cmd='use master; RESTORE LOG ['+@dbname+'] FROM  DISK = N''C:\Backup\'+@filename+''' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 10'
print @cmd
FETCH NEXT FROM filecursor INTO @filename
END 
CLOSE filecursor  
DEALLOCATE filecursor
drop table #dir

############################################################################

Wednesday, March 21, 2012

Msg 3154, Level 16, State 4

Msg 3154, Level 16, State 4, Line 1
The backup set holds a backup of a database other than the existing 'AdventureWorks' database.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

Some of these messages related to backups and restores in MSQL Server are misleading.
This error occurs due to following reason

The instance where you trying to restore the backup file already has a database with the same name. So you need to use the option 'WITH REPLACE' option in the restore command. Else drop the existing database first and then restore the backup file.

Tuesday, March 13, 2012

Request large buffers failure on backup device

SQL error 3013: BACKUP DATABASE is terminating abnormally.
SQL error 18210: BackupVirtualDeviceSet::Initialize: Request large buffers failure on backup device 'SQLBACKUP_687FEF8A-0BE6-485A-AE9C-7BABDA668AF8'. Operating system error 0x8007000e(Not enough storage is available to complete this operation.).

BackupVirtualDeviceSet::Initialize: Request large buffers failure on backup device 'D:/SQLBakups/LOG/xxxxxxx. Operating system error 0x8007000e(Not enough storage is available to complete this operation.).

I was in the process of setting log shipping and started receiving the above mentioned error while I was restoring the database backup on the secondary server.

I checked the memory consumption and found that the server had enough memory and all the buffers had enough memory.

Then found the following link that talks more about this issue while backing up and restoring. It seems that this is related to the low size of MemToLeave area for SQL Server.
http://www.johnsansom.com/sql-server-memory-configuration-determining-memtoleave-settings/

Ran the following query and found that it was very low.

WITH VAS_Summary AS
(
    SELECT Size = VAS_Dump.Size,
    Reserved = SUM(CASE(CONVERT(INT, VAS_Dump.Base) ^ 0) WHEN 0 THEN 0 ELSE 1 END),
    Free = SUM(CASE(CONVERT(INT, VAS_Dump.Base) ^ 0) WHEN 0 THEN 1 ELSE 0 END)
    FROM
    (
        SELECT CONVERT(VARBINARY, SUM(region_size_in_bytes)) [Size],
            region_allocation_base_address [Base]
            FROM sys.dm_os_virtual_address_dump
        WHERE region_allocation_base_address <> 0
        GROUP BY region_allocation_base_address
        UNION
        SELECT
            CONVERT(VARBINARY, region_size_in_bytes) [Size],
            region_allocation_base_address [Base]
        FROM sys.dm_os_virtual_address_dump
        WHERE region_allocation_base_address = 0x0 ) AS VAS_Dump
        GROUP BY Size
    )
SELECT
    SUM(CONVERT(BIGINT, Size) * Free) / 1024 AS [Total avail mem, KB],
    CAST(MAX(Size) AS BIGINT) / 1024 AS [Max free size, KB]
FROM VAS_Summary WHERE Free <> 0

First I restarted the SQL Server instance and that seemed to do the trick. The restores went fine and the Log shipping was configured. But the next day the restores started to fail with the same error.

So this time I modified the startup parameters for SQL Server and increase the MemToLeave to 512 MB and that seems to have fixed the problem and haven't seen any issue since then.
Then found the
 

Wednesday, February 1, 2012

Get last backup information

Get the last full and log backup information for SQL Server 2005/2008

SELECT sdb.Name AS DatabaseName, sdb.recovery_model_desc,
COALESCE(CONVERT(VARCHAR(30), MAX(bus.backup_finish_date), 120),'-') AS LastBackUpTime
FROM sys.databases sdb
LEFT OUTER JOIN msdb.dbo.backupset bus ON bus.database_name = sdb.name and bus.type='D'
GROUP BY sdb.Name, sdb.recovery_model_desc
order by sdb.Name


SELECT sdb.Name AS DatabaseName,sdb.recovery_model_desc,
COALESCE(CONVERT(VARCHAR(30), MAX(bus.backup_finish_date), 120),'-') AS LastBackUpTime
FROM sys.databases sdb
LEFT OUTER JOIN msdb.dbo.backupset bus ON bus.database_name = sdb.name and bus.type='L'
where sdb.recovery_model_desc='FULL'
GROUP BY sdb.Name, sdb.recovery_model_desc
order by sdb.Name

If you need  commands to give the location of the backups then please leave a comment.





Monday, January 16, 2012

SQL Server 2005/2008 : Error: 9002, Severity: 17, State: 2


Error: 9002, Severity: 17, State: 2
The transaction log for database 'mydatabase' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

The transaction log file will get full in one of the following two situations.

1) If the log file has been configured with preset max size limit then the file is full.
2) If the log file has been configured with unlimited size then perhaps the disk is full.

If it is the second situation then first free up some space in the disk by moving some files or deleting some files.

Now lets look why the file got full. First thing that you need to check is the log_reuse_wait_desc column in the sys.databases.

select name, recovery_model_desc, log_reuse_wait_desc from sys.databases

There are several reasons that could come up in this column and some of them are noted here.
NOTHING
CHECKPOINT
LOG_BACKUP
ACTIVE_BACKUP_OR_RESTORE
ACTIVE_TRANSACTION
DATABASE_MIRRORING
REPLICATION
DATABASE_SNAPSHOT_CREATION
LOG_SCAN
OTHER_TRANSIENT


If the database in question is TEMPDB then the process to resolve it would be different and also the reasons for which TEMPDB gets full are different. But let me discuss the most common reason why a user DBs log file gets full. 

LOG_BACKUP
In most cases you will see the reason noted in 'log_reuse_wait_desc' is given as 'LOG_BACKUP'. This means that the database is in FULL recovery model and is waiting for a log backup to be taken.

If you have scheduled a regular log backup job then check its status and wait for it to finish before you shrink the log file. If you check the free space in the log file then you will indeed see a lot of unused space but you can not shrink it. Once the log backup completes you can shrink the file.

But if the data file is not as big as the log file then instead of doing a log backup, I will do the following.

1) Change the recovery model to SIMPLE
2) Shrink the log file.
3) Change the recovery model to FULL
4) Take a full backup and subsequently schedule log backups.

Sometimes the above steps take a lot less time to complete than taking a log backup and then shrinking the file. But please keep in mind that when you do this you have essentially broken the log chain and will have to resync the database if it is configured for log shipping. 

The question of whether to truncate the log or not is dependent on the DB size. If it is not too big then truncate it and take a full backup. Otherwise it is best to take log backups.

ACTIVE_TRANSACTION
Other prominent reason that I have seen is 'ACTIVE_TRANSACTION'. In this case, it would be best if you first add a new log file to the database or extend it. Then run the DBCC OPENTRAN on that database and check the open transactions. This should give you more information about the transaction that is consuming most of the log space and has not yet completed. 

If the reason given is ACTIVE_BACKUP_OR_RESTORE then refer to my earlier post to find what is the expected time to finish the current backup or restore.

http://saveadba.blogspot.com/2011/10/backup-and-restore-progress.html
If the reason is related to either replication or mirroring then first check the status of replication or mirroring to ensure that they are upto speed and don't have any latency. This should help in reducing the log reuse wait time.





Friday, October 14, 2011

SQL Server : Backup and restore progress

Ever wondered how long it would take to complete a backup or restore that is currently in progress. Use the following command to find that. It gives you a rough estimate of the amount of time required to complete it.


SELECT command,
            s.text,
            start_time,
            percent_complete,
            CAST(((DATEDIFF(s,start_time,GetDate()))/3600) as varchar) + ' hour(s), '
                  + CAST((DATEDIFF(s,start_time,GetDate())%3600)/60 as varchar) + 'min, '
                  + CAST((DATEDIFF(s,start_time,GetDate())%60) as varchar) + ' sec' as running_time,
            CAST((estimated_completion_time/3600000) as varchar) + ' hour(s), '
                  + CAST((estimated_completion_time %3600000)/60000 as varchar) + 'min, '
                  + CAST((estimated_completion_time %60000)/1000 as varchar) + ' sec' as est_time_to_go,
            dateadd(second,estimated_completion_time/1000, getdate()) as est_completion_time
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) s
WHERE r.command in ('RESTORE DATABASE', 'BACKUP DATABASE', 'RESTORE LOG', 'BACKUP LOG')

SQL Server Get status of Backup
SQL Server Get status of Restore
SQL Server Get Backup completion
SQL Server Get Restore completion. 

Wednesday, January 19, 2011

Too many backup devices specified for backup or restore; only 64 are allowed. RESTORE HEADERONLY is terminating abnormally. (Microsoft SQL Server, Error: 3205)

Too many backup devices specified for backup or restore; only 64 are allowed.
RESTORE HEADERONLY is terminating abnormally. (Microsoft SQL Server, Error: 3205)

According to Microsoft this error can occur when all the following conditions are true: 
  • You want to restore a database backup that spans across multiple backup devices, and you have not specified more than 64 backup devices.
  • You created the database backup on a computer that is running SQL Server 2000 Service Pack 3 (SP3) (Build 2000.80.869.0) or a later build of SQL Server 2000 SP3.
  • You try to restore the database backup on a computer that is running a build of SQL Server 2000 SP3 that is earlier than 2000.80.869.0.
Ref : http://support.microsoft.com/kb/833710

But today I was trying to restore a database backup that was taken from SQL Server 2005 instance and I restoring this to a SQL Server 2000 instance and I got this error. Unfortunately, I had split the backup into 10 stripes because the database was pretty large. So my initial thoughts suggested that this is due to the fact that I had 10 striped backup files. So I spent sometime in creating a new backup with just one file. But the error kept coming. Upon further research, I found that a lot of folks saw this error when they tried to restore a backup from a 2005 instance to database on 2000 instance.

So the error seems to be misleading in some ways. Due to the fact that the structure of the backup header files were changed in SQL Server 2005, you can not restore it to a SQL Server 2000 instance.
It might be worth trying the detach-attach method to work around this problem. One could also try to use the SSIS export/import method to get the data to a 2000 instance.

For now, I decided to upgrade my instance to 2005 and restore the DB.

Ref :
http://social.msdn.microsoft.com/forums/en-US/sqldatabaseengine/thread/46e3ecf9-6eab-4aa0-9453-11e7269efb6e/
http://dbaspot.com/forums/sqlserver-server/378212-error-too-many-backup-devices-specified.html
http://www.sqlcoffee.com/Troubleshooting023.htm