The operation cannot be performed on database “DBNAME” because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group.

As per above error details, we cannot restore a database that is part of always on availability group directly. Here, I will explain step by step process to restore such databases.

Restore Databases in Availability Group

If you need to restore an availability group database, you need to first evict that database from availability group and then restore that database and finally you can re-add it to the always on availability group. So, there are three steps involved in restoring an AOAG database.

1. Remove identified database from Availability Group.
2. Restore that database.
3. Add database to Availability Group post restore operation.

Let’s explain each steps in detail in order to restore an alwayson database.

Remove Database from Availability Group

First step is to remove the identified database from AOAG configuration to restore AOAG database. If you have to restore primary database in AOAG configuration then you should remove it from the primary replica that will automatically remove this database from AOAG configuration on secondary replica as well. You don’t need to separately remove secondary database from AOAG configuration. We can use below T-SQL statement to remove your primary database from AOAG configuration.

--Change name of AG_Techyaz to your Availability group.
--Change database name from Techyaz to your primary database.
ALTER AVAILABILITY GROUP AG_Techyaz REMOVE DATABASE Techyaz

You can use GUI method as well to remove primary database from AOAG configuration. Read attached article to understand step by step process to remove a database from Availability group using GUI method.

Restore Database

Once primary database will be removed from availability group, It will disappear from Availability Database folder showing under your Availability group name on both replicas. Now, next step will be database restore. Go ahead to restore your database.
Here, we have to restore our database till 25 Jan 8 AM to recover point in time data. You can use your backup files as per your requirement. You can use either GUI method  in SSMS or T-SQL method to restore your database. Run below command to restore this database.

--Restore primary database with the help of your backup file.
RESTORE DATABASE Techyaz
FROM Disk= ‘F:\Backups\Techyaz_Full.bak’
WITH NORECOVERY, REPLACE;

--Restore log backup till the time you want to recover the database.
RESTORE LOG Techyaz
FROM Disk= ‘F:\Backups\Techyaz_TLog.trn’
WITH NORECOVERY, REPLACE, STOPAT = 'Jan 25, 2018 8:00 AM';

--Bring database Online.
RESTORE DATABASE Techyaz WITH RECOVERY;

Once your database will be restored and comes online, we will go ahead to add this database to availability group again.

Add database to Availability Group

If you want to re-add this database to availability group then you must perform this step otherwise your database will not have any HA or DR capability. I would recommend to first prepare your corresponding secondary database before starting to add it to availability group. If you have a plan to prepare secondary database during adding it to availability group then the processing will take lot of time for huge databases.

To prepare the secondary database, you first need to take a full backup and immediate transaction log backup of your newly restored primary database. Copy these files to secondary replica and restore corresponding secondary database in norecovery mode. Below are high level steps you need to perform to add this database to AOAG configuration.

1. Run full backup and immediate transaction log backup of primary database on primary replica.
2. Copy both full backup and log backup files to secondary replica.
3. Restore corresponding secondary database with the help of above copied files in norecovery mode with REPLACE option.
4. Now, run below T-SQL command to add this database to existing availability group. If you want to add this database to existing AOAG configuration using GUI method in SSMS, visit attached link where I have described it in step by step process.

-- Connect to the server instance that hosts the primary replica.
-- Add an existing database to the availability group.
ALTER AVAILABILITY GROUP AG_Techyaz ADD DATABASE Techyaz;
GO

Make sure to configure your secondary database on secondary replica as we have done from step 1 to step 3.
If you don’t want to add this database to availability group then you can ignore this step and use your database for transactions. You can also remove its corresponding database that is in restoring state on secondary replica. If you want to use that database from secondary replica for any purpose you can bring it online by running below command on secondary replica.

--Run on secondary replica in case you don't want to configure this database in AOAG rather want to use it for transactions.
RESTORE DATABASE Techyaz WITH RECOVERY;

Now, you are done with database restore in Alwayson Availability Group. Validate it by launching dashboard report or looking in to SSMS to get AOAG health for newly added or restored database.
I hope you like this article. Please comments us and follow our facebook page and Twitter handle to get latest updates.

Read More:

• Understanding Backup Preferences in Alwayson Availability Group
• AOAG Listener Error 19471: The handle is Invalid
• Secondary Replica Showing in Resolving State after AOAG Automatic Failover
• Fix Error 976: Cannot Connect to Secondary Replica

The post Restore a Database Participating in Alwayson Availability Group appeared first on Techyaz.com.

Shrink failed for LogFile ‘Logfile_Name”.
Backup, file manipulation operations (such as ALTER DATABASE ADD FILE) and encryption changes on a database must be serialized. Reissue the statement after the current backup or file manipulation operation is completed. (Microsoft SQL Server, Error: 3023)

Here is the screenshot of this error:

We get this error when there is a conflict between backup operation and Shrink operation. SQL Server are designed to follow some rules during Backup and Shrink operations. These are given below:

1. We can run only one database backup at a time. When a full database backup occurs, differential or incremental backups cannot occur at the same time.
2. Only one log backup can happen at a time. A log backup is allowed when a full database backup is occurring.
3. You cannot add or drop files to a database while a backup is occurring.
4. You cannot shrink files while database backups are happening.
5. There are limited recovery model changes allowed while backups are occurring.

When any of these conflicting operations are performed, the commands will be receiving the SQL Server error 3023, SQL Server error 3013 and SQL Server error 3041 messages.

You might also get below error when you perform another database backup if backup is already running for your database.

Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

Or if you try to run a differential backup for a database for which full backup is already running, you will get below error code:

Backup Error: 3041, Severity: 16, State: 1.
BACKUP failed to complete the command BACKUP DATABASE MyDatabase WITH DIFFERENTIAL. Check the backup application log for detailed messages.

Solution to fix such issues is to examine the schedules of the various database maintenance activities, and then adjust the schedules so that these operations or commands do not conflict with each other.

Make sure to not run any operation that will conflict with each other. If you get such errors check your SQL Server Agent jobs and wait till that job will be completed. In my case, database backup was running while I was trying to shrink a log file. I did wait for some time and then tried again to shrink that file and this time SQL Server allowed me to run this shrink operation.

Here, i have explained how to fix Microsoft SQL Server error 3023,  error 3013 and error 3041. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

The post Fix SQL Server Error 3023: Shrink failed for LogFile “Log File Name” appeared first on Techyaz.com.

Before going ahead, we need to understand the rules/points that are very important in order to decide the backup preferences in AOAG configuration. Below are the important points you should consider during designing backup strategy of availability databases.

• Regular Full Backups are not allowed from secondary replicas. Only COPY_ONLY full backups are allowed on secondary replicas. That means you cannot run regular Full backup from any of the secondary replica. Remember that copy-only backups do not impact the log chain or clear the differential bitmap.
• Differential backups are not supported on secondary replicas. If you must run differential backups for your availability databases, you should not choose backup preferences as secondary replicas.
• Only regular Log backups are supported on secondary replicas. COPY_ONLY log backups are not supported on secondary replicas.
• Secondary replica must be in SYNCHRONIZED or SYNCHRONIZING state to backup a secondary database.
• Log backup chain is supported across all replicas regardless of where the log backup is taken (primary or secondary replicas) or the mode of the replication (asynchronous or synchronous).
• In a distributed availability group, backups can be performed on secondary replicas in the same availability group as the active primary replica, or on the primary replica of any secondary availability groups.

How SQL Server Decides Which Replica will execute Backup – Backup Preferences ?

It’s little complex process to determine where backup jobs should run.  If you are confused about this question, then keep reading to get the answer.

To decide on which replica, you should run your backup job depends on your Backup Preferences setting. To address this, configure the availability group to specify which availability replicas where you would prefer backups to be performed.

If you choose backup preferences as secondary only then you can create jobs on only secondary replicas or if you choose to run it on primary replica, then you can configure it on primary replica only. But if you decided to go with default option that is preferred secondary then you should schedule backup jobs on all replicas.  Although, Microsoft suggests to create scripted backup-jobs for every availability database on every server instance that hosts an availability replica that is a candidate for performing backups.

Suppose you have chosen secondary only preference and you have 3 secondary replicas then question might arise how database engine will decide that on which replica backup should run. Database engine decides where should run backup based on preferred backup replica settings and backup priority settings. I have explained about these settings later in this article.

AOAG (AlwaysOn Availability group) has a function named sys.fn_hadr_backup_is_preferred_replica  to determine which replica is set as preferred backup replica.  If the out of this function returns 1 it means current instance is the preferred backup replica and backup will run on this instance. If returns 0, it means backup will not run on that replica.  We can use this function in a backup script to determine job should run on which replica, so only one of the scheduled jobs actually proceeds to the backup stage.

In the event of a failover, none of the scripts or jobs needs to be modified. Also, if you reconfigure an availability group to add an availability replica, managing the backup job requires simply copying or scheduling the backup job. If you remove an availability replica, simply delete the backup job from the server instance that hosted that replica. Microsoft has given a sample code logic for this function that can be used to develop backup script.

If sys.fn_hadr_backup_is_preferred_replica( @dbname ) <> 1
BEGIN
-- If this is not the preferred replica, exit (probably without error).
END
-- If this is the preferred replica, continue to do the backup.

If you use the Maintenance Plan Wizard to create a given backup job, the job will automatically include the scripting logic that calls and checks the sys.fn_hadr_backup_is_preferred_replica function.

If you want to check the preferred backup replica for any availability database, you can get it by running below command. If the output of this function returns 1 it means current instance is the preferred backup replica and backup will run on this instance. If returns 0, it means backup will not run on that replica.

--Get the backup preference replica for availability database TechYaz.
SELECT sys.fn_hadr_backup_is_preferred_replica ('TechYaz');
GO

I have executed same function on my secondary replica. You can see the output is showing as 1, it means this replica is set to run backups.

Configure Backup of Availability Databases to Run only from Secondary Replicas using GUI

1. Connect to the server instance that hosts the primary replica, and click the server name to expand the server tree. You would not be able to change Backup Preferences from any secondary replicas. If you open the AOAG name property, you will find all options greyed out.
2. Expand the Alwayson High Availability node and the Availability Groups
3. Click the availability group whose backup preferences you want to configure, and select the Properties.
4. In the Availability Group Properties dialog box, select Backup Preferences You can see backup preference is set to Prefer Secondary, now we need to change it to Secondary only option. The details about each type of backup preference is given in the screenshot and AOAG backup preference property window.

5. There are 4 backup preferences in AOAG that are given below with their capabilities. Choose any as per your requirements. Now I will add one more replica to this availability group as per our requirement and set backup preference to secondary only so that backups always run from either of the both secondary replicas. It is not mandatory for you to add additional replica.

6. Use the Replica backup priorities grid to change the backup priority of the availability replicas. Backup Priority (Lowest=1, Highest=100) specifies your priority for performing backups on this replica relative to the other replicas in the same availability group. In my case backup will run on the replica that has priority 60% and if this will not be available then backup will run on the replica that has priority of 50%. Backup will never run on primary replica irrespective of backup priority settings because we have chosen to run backups only on secondary replica.
   
   We have also an option Exclude Replica to exclude any replica where you don’t want to run backups. This is useful for remote availability replicas to which you never want to run backups there.
   You should click on checkbox for your respective replica name for which you want to exclude the backup as shown in above screenshot.

7. Click on OK button to apply the changes.

Configure SQL Server Backup in AOAG to Run with default backup preference using T-SQL

I have shown you how to change backup preference setting to run backups from secondary replicas using GUI. We can do the same using T-SQL commands as well. Here i will show you how to change backup preference using T-SQL. As we have changed the backup preference to secondary only option where backups will never run from primary replica. Now we can revert this change to default option using T-SQL. Prefer Secondary is default option in which backups run from secondary replica and if only primary replica is online then it will run from primary replica only.

Connect to the server instance that hosts the primary replica and run below command.

--Choose backup preference as per your choice and pass that value in AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SECONDARY | NONE }
ALTER AVAILABILITY GROUP AG_AOAGName SET (AUTOMATED_BACKUP_PREFERENCE = SECONDARY)
GO

Now your backup preference would be set to Prefer Secondary and backups will run from primary replica if only primary replica will be online.

Related Articles:

• Fix: Secondary Replica Stucked in to Resolving state
• Fix: Connectivity Issue after AOAG Automatic Failover
• Understanding SQL Server Recovery Models
• Fix: Listener Issue Error 19471

I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Understanding Backup Preferences for AlwaysOn Availability Group Databases appeared first on Techyaz.com.

• Full Backup
• Differential Backup
• Transaction Log Backup
• Copy-Only Backup
• File Backup
• Partial Backup

Full Backup

Full database backup captures dump of whole database including transaction logs. Full backup is supported in all three recovery models. Below is T-SQL script that can be used to run a full backup of SQL Server database.

-- Back up the TechYaz database to new media set.
  BACKUP DATABASE TechYaz
  TO DISK = 'D:\Backups\TechYaz_25Aug2017.bak'
  WITH FORMAT;
  GO

Differential Backup

A differential backup depends on the most recent full database backup. A differential backup captures only the data that has changed since that full backup. If your database does not have any full backup yet, you will not be able to run its differential backup. A base full backup is required to run the differential backup. Differential backup is faster because it does not capture full database dump but only the extents that are updated since last full backup.  Database engine reads details about updated extents from Differential Changed Map page type and capture those page ids only into the backup.  Read more about these page types on attached article. Differential backup can be used in all recovery models. Below is T-SQL script that can be used to run a differential backup of SQL Server database.

-- Create a full database backup first by running above commands.
  -- Create a differential database backup
  BACKUP DATABASE TechYaz
  TO DISK= 'D:\Backups\TechYaz_25Aug2017.drn'
  WITH DIFFERENTIAL;
  GO

Transaction Log Backup

Transaction log backup works only in full and bulk-logged recovery model. We cannot run log backup in simple recovery model. We must have at least a full database backup to run transaction log backup. If full backup is not performed since the database creation, log backup cannot be executed. We should frequently run log backup to minimize work loss exposure and to truncate the transaction log that make free space in database log file. Run below T-SQL code to run log backup.

-- Create a full database backup first.
  -- Create a log database backup by running below command.
  BACKUP LOG TechYaz
  TO DISK = 'D:\Backups\TechYaz_25Aug2017.trn'
  GO

Copy Only Backup

A copy-only backup is independent of the sequence of conventional SQL Server backups. It is just like conventional full backup without affecting the sequence of existing backup chain. Usually, taking a backup changes the database and affects how later backups are restored. However, occasionally, it is useful to take a backup for a special purpose without affecting the overall backup and restore procedures for the database. Copy-only backups serve this purpose. There are two types of copy-only backups.

• Copy-only full backup
• Copy-only transaction log backup

You cannot use copy-only full backup as a differential backup base. It means you cannot run differential backup considering copy only full backup as its base neither you can restore any differential backup on top of copy only full backup. A copy-only log backup preserves the existing log archive point and, therefore, does not affect the sequencing of regular log backups. The transaction log is never truncated after a copy-only backup.
Copy-only backups are recorded in the is_copy_only column of the backupset table. Below T-SQL can be used to run copy only backups.

--Run Copy-Only Full backup
  BACKUP DATABASE TechYaz
  TO DISK = 'D:\BACKUP\TechYaz_25Aug2017_Copy.bak'
  WITH COPY_ONLY;

--Run Copy-Only Log backup
  BACKUP LOG TechYaz
  TO DISK = 'D:\Backup\TechYaz_25Aug2017_LogCopy.trn'
  WITH COPY_ONLY;

File Backup

As per Book Online, A full file backup backs up all the data in one or more files or filegroups. The files in a SQL Server database can be backed up and restored individually. Also, you can specify a whole filegroup instead of specifying each constituent file individually. Note that if any file in a filegroup is offline (for example, because the file is being restored), the whole filegroup is offline and cannot be backed up. A file backup can serve as the differential base for differential file backups. File backups can increase the speed of recovery by letting you restore only damaged files, without restoring the rest of the database.

--Backup the files in the TechYaz_FG secondary filegroup.
  BACKUP DATABASE TechYaz
  FILE = 'TechYaz_Data',
  FILE = 'Techyaz_Data1'
  TO DISK = 'D:\Backups\TechYaz_25Aug2017_filebck.bak';
  GO

--Back up the files in TechYaz_FG filegroup.
  BACKUP DATABASE Sales
  FILEGROUP = 'TechYaz_FG'
  TO DISK = 'D:\Backups\TechYaz_25Aug2017_filegrp.bak';
  Go

--Back up the files in TechYaz_FG filegroup.
  BACKUP DATABASE Sales
  FILEGROUP = 'TechYaz_FG'
  TO DISK = 'D:\Backups\TechYaz_25Aug2017_filegrp.drn';
  With DIFFERENTIAL

Partial Backup

A partial backup resembles a full database backup, but a partial backup does not contain all the filegroups. A partial backup includes all the read/write files in a database: the primary filegroup and any read/write secondary filegroups, and also any specified read-only files or filegroups. A Partial backup can be issued for either a Full or Differential backup. This can not be used for Transaction Log backups. Partial backups are not supported by SQL Server Management Studio or the Maintenance Plan Wizard.

--Backup Partial Full Backup
  BACKUP DATABASE TechYaz READ_WRITE_FILEGROUPS
  TO DISK = 'D:\Backups\TechYaz_25Aug2017_Partial.bak';
  GO

--Backup Partial Differential Backup
  BACKUP DATABASE TechYaz READ_WRITE_FILEGROUPS
  TO DISK = 'D:\Backups\TechYaz_25Aug2017_DFNPartial.drn';
  WITH DIFFERENTIAL
  GO

I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Understanding SQL Server Backups appeared first on Techyaz.com.

• Simple
• Full
• Bulk-Logged

Simple Recovery Model

Simple recovery model is used for databases that are not critical or the database is static and data is not changing. We generally use SIMPLE model for lower life cycle databases. Main reason for this is point in time recovery is not possible because transaction log backup is not allowed in this recovery model and database engine automatically clears transactional logs during checkpoint operation. If you want to understand checkpoint operation, you should read attached article.

A common myth is that when a database is configured in Simple recovery model then transactions will not be logged in transaction log files. This is not true and every transaction is logged to the transaction log file. Only difference is that, when that transactions will complete and data is written to disk all logs will flush and be available to log another transaction in same log file. This way you can also deal with the space issue.

Log Shipping, AlwaysOn Availability group and Point-in-Time Restores are not possible in this SIMPLE model because transaction log backups are not allowed in this recovery model. We can recover any database that are running in SIMPLE model till last full or differential backups only. Run below command if you want to view or change the recovery model of the database.

--Check the Recovery Model of the database YourDB_Name
SELECT name, recovery_model_desc  
   FROM sys.databases  
      WHERE name = 'YOURDB_NAME' ;  
GO
--Change Recovery Model to SIMPLE
ALTER DATABASE DBNAME SET RECOVERY SIMPLE
GO

Full Recovery Model

Point in time recovery is possible in full recovery model that is why we use this recovery model for all production and critical databases. Every transactions that are logged in this recovery model can be backed up. Transaction log backup will capture all the logs and clears all the inactive portions of the transaction log file.  You can handle your log file space management by scheduling frequent transaction log backups.

You can also clear the transaction logs from log files by switching the recovery model from Full to Simple but this is never recommended for any production database. If you change the SQL Server recovery model from Full to Simple, logs will be flushed from log file without getting captured into transaction log backup. That will break the log sequence and you will end up losing the point in time recovery for your database. That is why switching recovery model from full to simple is not recommended for production database.

As transaction log backups are allowed in this recovery model so you can recover your database till point in time and there will be no data loss in this recovery model.

--Change SQL Server Recovery Model to FULL
ALTER DATABASE DBNAME SET RECOVERY FULL
GO

Bulk-Logged Recovery Model

Bulk-logged recovery model works similar to Full recovery model except few exceptions during bulk operations. You can use this recovery model if you have to run BULK operations on your database. Bulk-logged recovery model minimally logged such bulk operations to reduce the transaction log space.

Point in time recovery is not possible if you have performed any bulk operation during that time due to the nature of minimally logged operation. If you haven’t performed any bulk operation then point in time recovery can be achieved. Microsoft does not suggest to run any database in bulk-logged recovery model if you don’t have to run any bulk operations.

Best practice is that you change a database recovery model to the bulk-logged immediately before running bulk operations and restore it back to the full recovery model when those operations complete. Also you should run a log backup before switching to bulk-logged recovery model and again take the log backup once you return back to full recovery model post completing bulk operation. Your backup strategy remains the same and it will not break your log sequence. Run below command to change the recovery model to bulk-logged.

--Change Recovery Model to BULK-Logged
ALTER DATABASE DBNAME SET RECOVERY FULL
GO

Change Recovery Model using GUI

1. Connect to SQL Server Instance. in Object Explorer, click the server name to expand the server tree.
2. Expand Databases folder and click on the database for which either you want to change the recovery model of view the recovery model.
3. Right-click on that database, and then click Properties, which opens the Database Properties dialog box.
4. In the Select a page pane, click Options.
5. The current recovery model is displayed in the Recovery model list box.
6. Optionally, to change the recovery model select a different model list. The choices are Full, Bulk-logged, or Simple.
7. Click OK.

I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Understanding SQL Server Recovery Model appeared first on Techyaz.com.

Related Articles:

• Understanding SQL Server Wait Types
• How to deal with Resource Semaphore Wait type?
• What is BACKUPBUFFER Wait type?
• How to Reduce SQL Server Wait type PREEMPTIVE_OS_WRITEFILEGATHER?
• How to Improve SQL Server Bulk Data Load Performance?

ASYNC_IO_COMPLETION wait type occurs when a task is waiting for asynchronous I/Os to finish.  This wait type is normally seen with few other wait types like BACKUPBUFFER, BACKUPIO etc. This is clear indication of DISK IO issue. You can also get the Average disk queue length or current disk queue length value at the same time when you are getting this wait type. Compare both counters and if these counters have high value then you should look into your storage subsystem. Identify disk bottlenecks, by using Perfmon Counters, Profiler, sys.dm_io_virtual_file_stats and SHOWPLAN.

Any of the following will reduce this wait type occurrence:

1. Add additional IO bandwidth.
2. Balancing IO across other drives. If you are running your backups on same drive in which you have placed your database files. Make sure to keep separate drive for data, log and backups.
3. Reducing IO with appropriate indexing. This can cause major performance issue if you don’t have proper indexes.
4. Check for bad query plans that are consuming most of resources.
5. Check memory pressure if your server has enough memory to run resource extensive operations.

We can also correlate this wait type between Memory pressure and Disk IO subsystem issues.

If you like this tip, you can follow us on our facebook page and on Twitter handle to get latest updates.

The post Understanding ASYNC_IO_COMPLETION Wait type in SQL Server appeared first on Techyaz.com.

Today I was working on an issue in which backup job was showing in executing state since last 2 days.Initially my observation was either it was hung in middle of its process or it was processing very slow. Later, i decided to see the wait types for this process. When i was gathering this info, i saw the wait type backupbuffer for this transaction.

What is BACKUPBUFFER Wait Type

This wait type Occurs when a backup task is waiting for data, or is waiting for a buffer in which to store data. This type is not typical, except when a task is waiting for a tape mount. This wait stats will occur when you are taking the backup on the tape or any other extremely slow backup system.This wait type can be seen with one more wait type i.e. ASYNC_IO_COMPLETION.

These both wait types indicate that the issue is with storage/disk subsystem. Solution is to either ask your storage team to look in this or change your disk/storage subsystem and run your backup on a healthy and fast storage subsystem. There are other options as well where you should focus if your storage subsystem is ok. Below is the list of options you should look into to overcome from this wait type.

• Add additional IO bandwidth to accommodate the load.
• Balancing IO across other drives. If you are running your backups on same drive in which you have placed your database files. Make sure to keep separate drive for data, log and backups.
• Reducing Disk IO pressure with appropriate indexing. This can cause major performance issue if you don’t have proper indexes.
• Check for bad query plans that are consuming most of resources.
• Check memory pressure if your server has enough memory to run resource extensive operations.

Related Articles:

• Understanding SQL Server Wait Types
• What is Resource Semaphore Wait type?
• How to Improve Bulk Data Load Performance?
• Should We Clear Wait Stats Data from DMV sys.dm_os_wait_stats?

If you like this tip, you can follow us on our facebook page and on Twitter handle to get latest updates.

The post How to fix BACKUPBUFFER Wait Types? appeared first on Techyaz.com.

Related Articles:

• Understanding SQL Server Recovery Models
• Read Different Types of SQL Server Backups
• SQL Server Backup and Recovery Interview Questions
• How to get Last Restore Time of your database?

Point in Time Restore

1-This topic is relevant only for databases that are using full or bulk-logged recovery mode. Under the bulk-logged recovery model, if a log backup contains bulk-logged changes, point-in-time recovery is not possible to a point within that backup. The database must be recovered to the end of the transaction log backup.
2-Restore the last full database backup and, if any, the last differential database backup without recovering the database (RESTORE DATABASE database_name FROM backup_device WITH NORECOVERY).
3-Apply each transaction log backup in the same sequence in which they were created, specifying the time at which you intend to stop restoring log (RESTORE DATABASE database_name FROM WITH STOPAT=time, RECOVERY).
4-The basic syntax is:

RESTORE LOG database_name FROM WITH STOPAT =time, RECOVERY

T-SQL Code:

-- Restore the full database backup.
RESTORE DATABASE AdventureWorks
FROM disk='backup file location'
WITH NORECOVERY;
GO
-- Restore the required Log backup with STOPAT keyword.
RESTORE LOG AdventureWorks
FROM disk='backup file location'
WITH RECOVERY, STOPAT = 'Apr 15, 2005 12:00 AM';
GO

I hope you like this article. Please follow our facebook page and Twitter handle to get latest updates.

The post Understanding Point in Time Recovery in SQL Server appeared first on Techyaz.com.