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.

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.

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.

Reason for Database Suspect Mode in SQL Server

Here, i will explain the list of possible reasons which can cause your database to move into SUSPECT mode. Below is the list of such reasons.

• Improper shutdown of the database or database server.
• Hardware Failure.
• Corruption in database file/s.
• There is not enough space available for the SQL Server to recover the database during startup.
• Inaccessible database files or Insufficient memory.
• Missing any Database files
• Sudden Power Outage
• System Failure
• Database files drive letters mistyped/changed during any maintenance work.

If your database is showing in SUSPECT mode, you should check any reason from above list for this issue. Next, i will show you how to recover or repair suspect database in SQL Server.

SQL Server Suspect Database Fix

This section will explain how to bring database ONLINE from SUSPECT mode in SQL Server. To troubleshoot and repair suspect database,  first you need to analyze your database server. You need to check whether all database files are in same location where they should be. if not, get the reason why files have been moved to another drive and by whom. You can move the files to previous location or you can change/update the location of these database files in SQL Server catalogue view using ALTER command. Additionally, you can also check whether all databases files are safe and none of these database files are missing from their respective location.

Related Articles:

• How to get Last Restore Time of your database?
• Understanding Data Files, Pages & Extents
• Understanding SQL Server Recovery Models

Sometimes, database files drive letters got changed as human error during some maintenance work. If this is the case, don’t do anything on the database server and ask your windows or platform team to revert the drive letter name where your database files have been placed to the correct name. You can also do this change if you are authorized to do this.

Once you have checked the drive letters and there is no change in it then you can try to run below SQL statement to bring your database online.

--Change DBNAME with your database name that is showing in suspect mode.
Alter database DBNAME SET ONLINE.

Sometimes databases come online by running above Alter statement if there is no serious issue with the database.

Get information about power outage or any hardware or system failure. If this is the case then first we need to address these issues and then we can recover the databases. If your database is HA enabled and you have system failure then you can use standby database for your business transactions.

If nothing works and all above steps are failed to bring suspect database ONLINE then we will run DBCC CHECKDB T-SQL statement to get all database corruption errors due to which database went in suspect mode:

DBCC CHECKDB ([DBNAME]) WITH NO_INFOMSGS, ALL_ERRORMSGS

Above command will thoroughly check database integrity and return issues and corruption errors in the output section. You can read and review output of above DBCC CHECKDB command to understand the corruption or integrity issue in database.

Once you have enough information about errors then your next step would be Repair this suspected database. If error is showing data files missing then check your data file drive connectivity from storage side if it’s missing then you don’t need to do anything just contact someone from storage or one who manages storage in your environment and ask them to check data file drive is healthy or not. If storage is also ok then we will repair our database using below t-sql codes:

ALTER DATABASE [DBNAME] SET EMERGENCY
go
ALTER DATABASE [DBNAME] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
go
DBCC CHECKDB ([DBNAME], REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;
go
ALTER DATABASE [DBNAME] SET Multi_USER;

Put your db name in place of [DBNAME] in above script. Above alter statement will change database into emergency mode and then repair the corruption present on data pages.

If your database does not come online post running above Alter statement then only option left is to restore your database with the copy of latest backups.

Note: REPAIR_ALLOW_DATA_LOSS is a one way operation i.e. once the database is repaired all the actions performed by these queries can’t be undone. There is no way to go back to the previous state of the database. So as a precautionary step you should take backup of your database before executing above mentioned queries.

I hope you like this article. Please drop your questions and feedbacks in below comment section. You can also follow our Facebook page and Twitter handle to get latest updates.

The post How to Recover or Repair Suspect Database in SQL Server 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.