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.

SQL Server Backup & Recovery Interview Questions

Question- What is Minimal Logging and how is it different from Full Logging?

Answer- Minimal logging involves logging only information that is required to recover the transaction without supporting point-in-time recovery. Under the full recovery model, all bulk operations are fully logged. However, you can minimize logging for a set of bulk operations by switching the database to the bulk-logged recovery model temporarily for bulk operations.

Minimal logging is more efficient than full logging, and it reduces the possibility of a large-scale bulk operation filling the available transaction log space during a bulk transaction. However, if the database is damaged or lost when minimal logging is in effect, you cannot recover the database to the point of failure.

Question- Can you name few operations that logs Minimally during bulk-recovery model?

Answer- The following operations, which are fully logged under the full recovery model, are minimally logged under bulk-logged recovery model:

1. Bulk import operations (bcp, BULK INSERT, and INSERT… SELECT).
2. SELECT INTO operations
3. CREATE INDEX operations
4. ALTER INDEX REBUILD or DBCC DBREINDEX operations.
5. DROP INDEX new heap rebuild

Question- If I change my database recovery model from FULL to SIMPLE, does transactions will be logged in to log file?

Answer- Yes, Transactions will be logged in SIMPLE recovery model as well. The difference is all logged transactions will be cleared during checkpoint operation in this recovery model. Read more about Checkpoint operations & SQL Server Recovery Models.

Question- If yes in above question then how is SIMPLE RECOVERY Model different from FULL Recovery Model?

Answer- All logged transactions will be cleared during checkpoint operation and transaction log backup is not allowed so point-in-time recovery is not possible in SIMPLE recovery model. Whereas transaction backup is allowed in full recovery model and point-in-time recovery is also supported. Logs got cleared only after taking log backup or switching the recovery model to SIMPLE.

Question- Can we achieve point-in-time recovery in Bulk-logged Recovery Model?

Answer- Yes, if there is no bulk operation performed on your database and you have all log backups. Point-in-time recovery is not possible if your recovery point falls falls in-between any bulk operations. .

Question- How differential backup works? or

How differential backup captures only updated data since full backup in its dump file?

Answer- Differential Changed Map is a page type that stores information about extents that have changed since the last full backup. Database engine reads just the DCM pages to determine which extents have been modified and captures those extents in differential backup file.

Question- Why cannot we serve copy-only backup  as a differential base or differential backup?

Answer- The differential changed map page is not updated by a copy-only backup. Therefore, a copy-only backup cannot serve as a differential base or differential backup. A copy-only backup does not affect subsequent differential backups.

Question- Why a database log file is growing like anything that is running in SIMPLE Recovery Model?

Answer- It means some transactions are active and running on your database.  As we know logs are captured in simple recovery model as well so that active transaction is getting logged there. The inactive portion in log file clears during checkpoint operation.

Question- Can we restore a database till the specific time?

Answer- Yes, if database is running in full recovery model and database has log backups till that specific time. We can use STOPAT clause to recover till a specific time.

Question- Suppose we are running Daily full backup at 8PM in night and every half an hour transaction log backup. Now your database is crashed at 3.41PM. How will you recover your database to the point it was crashed?

Answer- Below steps we will perform in a sequence manner to recover this database to the point it was crashed.

• First we will run tail log backup to capture all transactions that are not captured in previous log backups at the point database was crashed.
• Restore last night Full backup with NORECOVERY that was taken at 8PM.
• Apply all transaction log backup since last night full backup with norecovery.
• Apply tail log backup on the database with recovery and with STOPAT parameter. 

Question- Take the same scenario as above, now you found that there is one log file let’s say at 2 PM got corrupted and not restorable. What will be the impact on your database recovery?

Answer-  We cannot recover this database till that point it was crashed and we would have last data till 1.30PM considering log backup runs on every half an hour.

Question- Suppose we are running Weekly Sunday full backup at 8PM, daily differential backup at 10PM and every half an hour transaction log backup. Now your database is crashed on Saturday 3.11PM. What would be your fastest way to recover this database in point in time?

Answer-  We will perform below steps to recover this database in point-in-time:

1. Try to run tail log backup at the point database was crashed.
2. Restore latest Weekly Sunday Full backup with NORECOVERY that was taken at 8PM.
3. Restore Friday night differential backup with NORECOVERY that was taken at 10PM.
4. Apply all transaction log backup since Friday differential backup with norecovery.
5. Apply tail log backup on the database with recovery and with STOPAT parameter. 

Question- In addition to above question, suppose you came to know that Friday night differential backup was corrupted then what would be your strategy to recovery the database in point-in time?

Answer- We will perform below steps to recover this database in point-in-time:

1. Try to run tail log backup at the point database was crashed.
2. Restore latest Weekly Sunday Full backup with NORECOVERY that was taken at 8PM.
3. Restore Thursday night differential backup with NORECOVERY that was taken at 10PM.
4. Apply all transaction log backup since Thursday night differential backup with norecovery.
5. Apply tail log backup on the database with recovery and with STOPAT parameter. 

Question- Suppose you came to know that differential backups ran on Monday and Wednesday are corrupted and you have only Tuesday and Thursday differential backups along with full backup and all log backups. Explain your sequence to restore the database?

Answer- We will follow same sequence that we follow in previous question. We will apply weekly full backup then Thursday differential backup along with all transaction log backups.

Question- How will you restore tempdb?

Answer- We should not restore tempdb as it’s a temporary database and created everytime we restart SQL Server service.

Question- What is COPY_ONLY full backup and how it is different from regular full backups?

Answer- Difference between regular full and copy-only full backup is that copy-only full backup does not break the differential chain. Neither of them breaks the log chain as neither of them truncates the log file. A copy-only backup cannot serve as a differential base or differential backup and does not affect the differential base.

Please Like, Share and comment us about your feedback. I hope you like this article. You can comment your questions in below section. Please follow our facebook page and Twitter handle to get latest updates.

Read More Interview Q&A:

• SQL Server Interview Q&A on Alwayson Availability Group
• SQL Server Interview Q&A on Indexes

The post SQL Server Backup & Recovery Interview Questions & Answers 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.

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.