When restoring a SQL Server Database, I notice that there are 3 different Recovery States to choose from:
Restore with Recovery
Restore with No Recovery
Restore with Standby
I've always left it at it's default value, but what do they all mean?
(Preferably in layman's terms)
GateKiller,
In simple terms (and not a copy-paste out of the SQLBOL) so you can understand the concepts:
RESTORE WITH RECOVERY uses the backup media file (eg. fulldata.bak) to restore the database to back to the time that backup file was created. This is great if you want to go back in time to restore the database to an earlier state - like when developing a system.
If you want to restore the database TO THE VERY LATEST DATA, (i.e. like if your doing a system Disaster Recovery and you cannot lose any data) then you want to restore that backup AND THEN all the transaction logs created since that backup. This is when you use RESTORE NORECOVERY. It will allow you to restore the later transaction logs right up to the point of failure (as long as you have them).
RECOVERY WITH STANDBY is the ability to restore the database up to a parital date (like NORECOVERY above) but to allow the database still to be used READONLY. New transaction logs can still be applied to the database to keep it up to date (a standby server). Use this when it would take too long to restore a full database in order to Return To Operations the system. (ie. if you have a multi TB database that would take 16 hours to restore, but could receive transaction log updates every 15 minutes).
This is a bit like a mirror server - but without having "every single transaction" send to the backup server in real time.
You can set a Microsoft SQL Server database to be in NORECOVERY, RECOVERY or STANDBY mode.
RECOVERY is the normal and usual status of the database where users can connect and access the database (given that they have the proper permissions set up).
NORECOVERY allows the Database Administrator to restore additional backup files such as Differential or Transactional backups. While the database is in this state then users are not able to connect or access this database.
STANDBY is pretty much the same as NORECOVERY status however it allows users to connect or access database in a READONLY access. So the users are able to run only SELECT command against the database. This is used in Log Shipping quite often for reporting purposes. The only drawback is that while there are users in the database running queries SQL Server or a DBA is not able to restore additional backup files. Therefore if you have many users accessing the database all the time then the replication could fall behind.
From Books On line, i think it is pretty clear after you read it
NORECOVERY
Instructs the restore operation to not roll back any uncommitted transactions. Either the NORECOVERY or STANDBY option must be specified if another transaction log has to be applied. If neither NORECOVERY, RECOVERY, or STANDBY is specified, RECOVERY is the default.
SQL Server requires that the WITH NORECOVERY option be used on all but the final RESTORE statement when restoring a database backup and multiple transaction logs, or when multiple RESTORE statements are needed (for example, a full database backup followed by a differential database backup).
Note When specifying the NORECOVERY option, the database is not usable in this intermediate, nonrecovered state.
When used with a file or filegroup restore operation, NORECOVERY forces the database to remain in the restoring state after the restore operation. This is useful in either of these situations:
A restore script is being run and the log is always being applied.
A sequence of file restores is used and the database is not intended to be usable between two of the restore operations.
RECOVERY
Instructs the restore operation to roll back any uncommitted transactions. After the recovery process, the database is ready for use.
If subsequent RESTORE operations (RESTORE LOG, or RESTORE DATABASE from differential) are planned, NORECOVERY or STANDBY should be specified instead.
If neither NORECOVERY, RECOVERY, or STANDBY is specified, RECOVERY is the default. When restoring backup sets from an earlier version of SQL Server, a database upgrade may be required. This upgrade is performed automatically when WITH RECOVERY is specified. For more information, see Transaction Log Backups .
STANDBY = undo_file_name
Specifies the undo file name so the recovery effects can be undone. The size required for the undo file depends on the volume of undo actions resulting from uncommitted transactions. If neither NORECOVERY, RECOVERY, or STANDBY is specified, RECOVERY is the default.
STANDBY allows a database to be brought up for read-only access between transaction log restores and can be used with either warm standby server situations or special recovery situations in which it is useful to inspect the database between log restores.
If the specified undo file name does not exist, SQL Server creates it. If the file does exist, SQL Server overwrites it.
The same undo file can be used for consecutive restores of the same database. For more information, see Using Standby Servers.
Important If free disk space is exhausted on the drive containing the specified undo file name, the restore operation stops.
STANDBY is not allowed when a database upgrade is necessary.
Related
I want to set up a secundary copy of a large ERP production database, which would be used as read-only database for reporting purposes. Regular backup jobs on production DB are already configured: a full backup every night and regular transaction log backups every 15 minutes.
I'm restoring a full backup and then applying transaction log backups (with STANDBY option). The restore of transaction log is successful, but I always get a message at the end that the system objects could not be updated:
Processed 7 pages for database ..., file ... on file 1.
System objects could not be updated in database ... because it is read-only.
System objects could not be updated in database ... because it is read-only.
RESTORE LOG successfully processed 7 pages in 0.029 seconds (1.633 MB/sec).
It seems that the restore is successful. However, the warning (error?) regarding the system objects is confusing. Is it something I should pay attention to? What is the reason for the error? I couldn't find any similar problem on the Microsoft support forums...
Update: SQL Server version is 11.0.7469.6 (2012 with all service packs and hotfixes)
If you don't mind I'll suggest you a workaround(There might be a solution)
step 1. Restore the full backup to a new database and ensure the backup is successful(by accessing some objects).
step 2. restore the transaction backups 2(some count let say 3 or some number) at a time and make db to recovery state then query the same objects which were done at step 1.
step 3. repeat the process until all the backups were restored successfully.
Also check the following link, might work.
Can I use the "backup" transact sql command (sql-server 2008)
when my database is used (read/write) by other users.
Or I must switch to single_user mode before doing this?
Yes, it will let you do that. There are considerations though, regarding full and precise restoration of the data should a restore operation become necessary.
Best you read up on the whole thing so you can choose the best back-up method for your situation.
Yes, you can use the "backup" T-SQL command even the database is used (read/write) by other users.
For example, you are going to make a full database backup by T-SQL command:
BACKUP DATABASE Test TO DISK ='D:/Test.bak'
Suppose someone is working with the table at this moment. So, the transaction "A" started before the full backup began, made some changes after the checkpoint and committed before the backup completed.
In this case, the full backup includes all transaction log records starting from the latest active transaction. This implies that the full backup includes the whole transaction "A" with all changes that were made after the checkpoint to apply those changes during the database recovery process.
I accidentally deleted a row in a table and want to restore it. I've found a solution here: How to recover deleted records in MS SQL server
I've tried to restore database from backup taken after delete. But I can't restore database with STOPAT option:
RESTORE LOG database FROM DISK = N'X:\database.BAK' WITH
STOPAT = N'2011-02-12T00:00:00', RECOVERY
I have following error:
Msg 3117, Level 16, State 4, Line 1
The log or differential backup cannot be restored because no files are
ready to rollforward.
Msg 3013, Level 16, State 1, Line 1
RESTORE LOG is terminating abnormally.
I've tried to restore database from
backup taken after delete.
You cannot recover deleted records from a backup taken after the delete. You need:
the latest full backup taken before the delete
all the log backups taken between the last full backup until the first log backup taken one after the delete
the database must be in full recovery mode
You may have an differential backup thrown in to reduce the log backup chain length, but this is optional.
Only if all the conditions above are satisfied, then you can go ahead and follow the procedure. If you are missing any of the above, then that record is lost. As a rule of thumb, don't follow blog articles or forum answers, including this one, follow instead the product documentation: How to: Restore to a Point in Time (Transact-SQL)
If your database was in full recovery mode then you can try to read transaction log and recover data from there using commercial tool such as ApexSQL Log or sql server commands such as DBCC LOG or fn_log.
Also you can try looking at these posts for more details:
How to undo a delete operation in SQL Server 2005?
How to view transaction logs in SQL Server 2008
Taken from this link -
A differential backup, though only containing changed data pages since the last full database backup, can only be restored in conjuntion with a full backup similar to using log backups. You don't have the ability to restore only single tables or objects, but you can restore at the database, filegroup, file, and page level. You can also restore up to a particular point in time from any of the backups (assuming you've restored the required preceding full, diff, logs).
Possibly the best solution for you in this case would be to restore the database using a different database name, then moving only the data you want into your existing database? Not sure if that's exactly what you're trying to achieve though.
Yes, it's possible to recover deleted records from SQL Server database using various methods, which, on the other hand, requires different prerequisites. Some of them involve native SQL Server features, others 3rd party tools.
Anyway, in some cases the deleted data is not lost even your database is not using the Full recovery model. For more information, check the Recover deleted SQL data from a backup or from online database files online article.
Disclaimer: I work as a Product Support Engineer at ApexSQL
I was wondering how you can recover data from your logfile.
I'm using sql 2005 (full backup).
The problem is that a service cleared my data last night (which it shouldn't have).
and now I want to recover those rows that were deleted before.
can anyone tell me how I can do this?
As long as you have a backup of your database from before the delete and then all transaction log backups that have been made since the last database backup then you will be able to restore to a point in time.
The first thing to do is take a backup of the transaction log.
Then you restore your last database backup and all transaction log backups since then up to the point in time just before the delete.
See this MSDN Article on how to do it.
I would suggest that you leave your existing database in place as it is and restore the backups to a new database. Then you can write some scripts to transfer the required data back into your live database.
First of all, your database must be in the full recovery model and you must have a full chain of transaction log backups - a series of log records having an unbroken sequence of log sequence numbers (LSNs)
The log backup chain is started when a full database backup is made or the recovery model is switched from SIMPLE to FULL and a full backup is made. After that, transaction log backups are created on regular basis. The log backup chain can be broken only in two ways:
Overwriting the backup set
Switching from FULL to SIMPLE or BULK LOGGED recovery models
Breaking the log backup chain can lead to missing transaction information
You can restore to a point in time using:
SQL Server Management Studio, as shown in the link Robin provided
Using T-SQL and the STOPAT option
Syntax
RESTORE LOG database_name
FROM <backup_device>
WITH STOPAT = time, RECOVERY…
Use a third party tool, such as ApexSQL Log which can not only restore to a specific point in time, but selectively roll back only the transdactions you selected
You can find the steps for all listed options here: Restore a database to a point in time
Disclaimer: I work for ApexSQL as a Support engineer
Your data can be recovered only in case:
1) database uses full recovery model;
2) you have full backup that you make before accidental deleting;
3) you have have NOT recover or backup again this database yet.
If this is correct, you should:
1) make transaction log backup;
2) restore database from full backup WITH NORECOVERY option;
3) restore transaction log using STOPAT option.
To restore transaction log files to a point-in-time your database must run under full recovery model. So firstly you have to restore the latest full database backup:
RESTORE DATABASE *database* FROM DISK = 'D:/Full.bak' WITH NORECOVERY, REPLACE
The next step is to restore the last differential database backup:
RESTORE DATABASE *database* FROM DISK = 'D:/Diff.bak' WITH NORECOVERY
And then restore all transaction log backups that have made since last differential backup in correct sequence
RESTORE LOG *database* FROM DISK = 'D:/log1.bak' WITH NORECOVERY
RESTORE LOG *database* FROM DISK = 'D:/log2.bak' WITH NORECOVERY
RESTORE LOG *database* FROM DISK = 'D:/log3.bak' WITH NORECOVER
The last one transaction log backup that must be restored is the transaction log backup that have been made after the failure occurred with stopat option. After stopat option, you should set up the time to which you want to restore your database.
RESTORE LOG *database* FROM DISK = 'D:/log4.bak' WITH STOPAT = '2015-11-26 16:22:40.000', RECOVERY
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.