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.

• 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 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.