1. Performing backup and recovery
11: Monitoring and performance tuning
Performing backup and recovery
Module 9

2. Module Agenda Data recovery basics Data recovers models
9/10/ :16 AM
Module Agenda
Data recovery basics
Data recovers models
Understanding database backup methods
Data recovery strategies
Backup and recovery with Azure
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

3. Lesson 1
Data recovery basics

4. Lesson 1: Data recovery basics
Understanding common database errors and recovery
Backup and recovery tools
Comparison of backup tools

5. Understanding database backups
Types of database errors
Common database errors that will make you resort to backups include:
Statement failure—when a program encounters a failure in the handling of a statement
User or application error—when objects are dropped or data is deleted accidentally
Process failure—when a background process, user process, or server process encounters an abnormal disconnection or process termination
Media failure—when reading from or writing to a database file fails
Network failure—when a network segment fails or a phone connection aborts
Instance failure—when an instance ceases to run due to a hardware or software failure

6. Comparison of data recovery methods
10: Backup and recovery
Comparison of data recovery methods
Statement failure: Oracle and SQL Server automatically recover and return control
Process failure: PMON in Oracle and SQLOS in SQL Server automatically roll back the current transaction and release held resources
Instance failure: Oracle and SQL Server recover on instance startup
User or application error: Oracle and SQL Server offer point-in-time recovery options
Media failure: Oracle and SQL Server offer file-level recovery
Network failure
PMON in Oracle and SQLOS in SQL Server recover aborted transactions
RECO in Oracle and MSDTC in SQL Server recover from failures during a two-phase commit of distributed transactions
Lets look at how the various tools and features map back to the common issues:
Statement Failure: SQL Server will roll back failed transactions. (SQL has transactional consistency so it can roll things back when required). The DBA can turn on tracing to log such errors. Stored Procedures can raise alerts for such errors (for example they can send an with the offending query). Redgate also has good tools for taking actions upon failures.
Process Failures: Recovery in SQL Server automatically rolls back the current transaction and release held resources. It can also be used to report such errors.
Note that SQL Server is its own OS. It is like a separate abstraction layer running on top of the Windows OS.
Instance Failure: After an instance failure SQL Server recovers on startup – it rolls back any incomplete transactions when it restarts. Note that SQL Server allows you to specify how long to wait before roll back – do not set that setting too long. For example if you set it to 1 hour it would result in a VERY long delay to the SQL Server restart if transactions needed to be rolled back.
User/App Error. To help recover from user or application error, SQL Server provides point-in- time recovery options
Media failure: SQL Server offers file-level recovery
Network Failure: SQL Server uses MSDTC (Microsoft Distributed Transaction Coordinator) to protect distributed transactions. This mechanism recovers from failures by rolling back transactions across the machines involved (if necessary) during two-phase commit of the distributed transactions.

7. Data Recovery Backup and recovery tools
Oracle Recovery Manager (RMAN)—part of Oracle, used to back up and recover database files
SQL Server backup and restore components—in conjunction with SQL Server Agent, you can set up, schedule, automate backups, and perform recovery
BACKUP and RESTORE commands can be used in applications, T-SQL scripts, stored procedures, and triggers.
Backup history is maintained in the RMAN recovery catalog. The equivalent system catalog tables are in the msdb database in SQL Server.
Consider encryption/compression – both tools provide it in some approach
There are a number of backup and recovery tools and features that work together to support data recovery.
SQL Server Agent runs out of band and controls jobs and handles job errors, etc. This together with SQL Server backup and restore components allows you to automate backups and perform recovery.
SQL Server Agent is quite sophisticated--it can call backups, triggers and more.
We have a database engine that allows us to run command-line scripts against SQL Server. It is very scriptable.
Note that the MSDB database is where backup and restore history is kept.
Encrypted and compressed backups are now supported by SQL Server. If using this feature ensure that you have good key management.
Encryption allows you to prevent rogue admins from accessing databases from backups

8. Resources
Understanding How Restore and Recovery of Backups Work in SQL Server
Working with Restore Sequences for SQL Server Databases

9. Lesson 2
Data recovery models

10. Lesson 2: Data recovery models
Overview of recovery models
Simple recovery model
Bulk-logged recovery model
Full recovery model
Demo: Setting recovery models

11. Data Recovery Recovery models Available recovery models include:
11: Backup and Recovery
Data Recovery
Recovery models
Available recovery models include:
Full
Bulk logged
Simple
Recovery models determine the amount of logging at the database or command level
Recovery models provide much needed control over logging and speed up bulk operations while providing recoverability to transaction-heavy systems
Next 3 slides have details on recovery model exposure to loss.
SQL Server backup and restore operations occur within the context of the recovery model of the database.
Recovery models are designed to control transaction log maintenance.
A recovery model is a database property that controls how transactions are logged, whether the transaction log requires (and allows) backing up, and what kinds of restore operations are available.
Three recovery models exist: simple, full, and bulk-logged.
Typically, a database uses the full recovery model or simple recovery model. A database can be switched to another recovery model at any time.

12. Data Recovery Simple Recovery Model
Inactive part of transaction log is automatically truncated, if not held by open transactions
No need for transaction log backups
Simplifies database backup and restore plans
Changes since the most recent backup are unprotected
No transaction log backups = no point in time recovery
Work loss exposure:
Changes since the most recent backup are unprotected. In the event of a disaster, those changes must be redone.
Recover to point in time?
Can recover only to the end of a backup.

13. Data Recovery Bulk-logged Recovery Model
Minimally logs most bulk operations*
Fully logs all other transactions
Switching between full and bulk-logged is useful before and after large bulk operations
Requires transaction log backups
Point-in-time recovery is not supported
* except during backups, where everything is logged.
Bulk operations include:
Index creation or rebuilds;
Bulk imports:
bcp in / out
BULK INSERT
INSERT ... SELECT xxx FROM
SELECT INTO
Partial updates to large value data types:
UPDATE … SET xxx .WRITE
Text, NText, and Image inserts/appends using the WRITETEXT and UPDATETEXT (deprecated);
Work loss exposure:
If the log is damaged or bulk-logged operations occurred since the most recent log backup, changes since that last backup must be redone.
Otherwise, no work is lost.
Recover to point in time?
Can recover to the end of any backup. Point-in-time recovery is not supported.

14. Data Recovery Full Recovery Model
Prevents data loss in the broadest range of failure scenarios.
If the tail of the log is damaged, changes since the most recent log backup must be redone.
Includes both database backups and transaction log backups.
Can recover to an arbitrary point in time.
Work loss exposure:
Normally none.
If the tail of the log is damaged, changes since the most recent log backup must be redone.
Recover to point in time?
Can recover to a specific point in time, assuming that your backups are complete up to that point in time. For information about using log backups to restore to the point of failure.

15. Demo
Recovery model

16. Demo: Recovery model In this demonstration, you will learn to:
10: Backup and recovery
Demo: Recovery model
In this demonstration, you will learn to:
Locate the recovery model option for a database.
Make changes through the SSMS GUI or with scripts.
Demonstration Steps
Open SQL Server Management Studio Object Explorer, and then click Databases.
On the View menu, select Object Explorer Details.
Note the Recovery Model and Compatibility Level columns in the detail view. (Scroll to the right if necessary.)
From the Object Explorer Details, right-click AdventureWorks2016, and then select Properties.
Select the Options page in the left pane.
Change the recovery model near the top of the window to Full.
Click the Script button at the top of the Properties dialog.
Click the Cancel button.
Review the T-SQL used to change the recovery model, and then execute the script.

17. Resources
Choosing the Recovery Model for a Database

18. Lesson 3
Database backup types

19. Lesson 3: Database backup types
Overview of backup methods
Full backup and simple recovery method
Full backup and full recovery model
Differential backup
Partial backups

20. Understanding Database Backups
11: Backup and Recovery
Understanding Database Backups
Backup methods
Full Backup
Differential Backup
Database
Filegroup
Transaction Log Backup
Tail Log
Partial Backup (Piecemeal)
Mirrored Backup
Copy-only Backup
It is important to understand the types of SQL Server backups.
More details in the next slides.

21. Understanding Database Backups
11: Backup and Recovery
Understanding Database Backups
Full Backup and Simple Recovery Model
A full database backup is to capture all the data that is stored in the database
The backup engine accomplishes this task by extracting every extent in the database that is allocated to an object
This backup method is always available, regardless of the recovery model you configure for a database
It is important to understand how the types of SQL Server backups operate depending on the recovery model, and thus required exposure to loss of data.
The purpose of a full database backup is to capture all the data that is stored in the database. The backup engine accomplishes this task by extracting every extent in the database that is allocated to an object. You can then use a full backup by itself to re- create the entire database.
Note that this backup method is always available, regardless of the recovery model you configure for a database.

22. Understanding Database Backups
11: Backup and Recovery
Understanding Database Backups
Full Backup and Full Recovery Model
A log backup backs up the active portion of the log:
It starts at the Log Sequence Number (LSN) at which the previous log backup completed
Then backs up all subsequent transactions until the backup encounters an open transaction
Together with Full backups, these provide full protection from work- loss exposure

23. Understanding Database Backups
11: Backup and Recovery
Understanding Database Backups
Differential Backup
Reduces the number of Tlog backups that need to be restored
Is always available, regardless of the recovery model
Captures all the extents that have changed since the last full backup
A differential backup captures all the extents that have changed since the last full backup. And the main purpose of a differential backup is to reduce the number of transaction log backups that need to be restored. You use a differential backup along with a full backup.
If a full backup does not exist, you cannot create a differential backup. As with a full backup, you can perform a differential backup of a database no matter what recovery model is specified for the database

24. Demo
Differential and log backups and database restoration

25. Demo: Differential and log backups and database restoration
10: Backup and recovery
Demo: Differential and log backups and database restoration
-- Back up the Tail of the Log after some failure in the database files
BACKUP LOG [AdventureWorks2016]
TO DISK = N'E:\MSSQL13.INST01\MSSQL\Backup\AW2008_Trx1.TRN'
WITH NO_TRUNCATE , NOFORMAT, NOINIT,
NAME = N'AdventureWorks2016-Transaction Log Backup',
SKIP, NOREWIND, NOUNLOAD, NORECOVERY , STATS = 10 GO
-- Review the script. The full backup is restored with NORECOVERY and the log backup is restored with RECOVERY.
RESTORE DATABASE [AdventureWorks2016]
FROM DISK = N'E:\MSSQL13.INST01\MSSQL\Backup\AdventureWorks2016_backup_2016_01_01_105752_ bak'
WITH FILE = 1, NORECOVERY, NOUNLOAD, REPLACE, STATS = 10
RESTORE LOG [AdventureWorks2016]
FROM DISK = N'E:\MSSQL13.INST01\MSSQL\Backup\AW2016_Trx1.TRN'
WITH FILE = 1, NOUNLOAD, STATS = 10
In this demonstration, you will learn to:
Create a tail log backup.
Restore a database to every committed transaction.
Demonstration Steps
Open a new Query window and execute the following T-SQL script:
USE AdventureWorks2016 GO
IF EXISTS
(SELECT *
FROM sys.objects
WHERE object_id = OBJECT_ID(N'[HumanResources].[Employee4]')
AND type = N'U')
DROP TABLE [HumanResources].[Employee4]
CREATE TABLE [HumanResources].[Employee4]
(emp_id int NOT NULL,
last_name varchar(50) NULL,
first_name varchar(50) NULL,
job_title varchar(50) NULL,
hire_date date NULL,
vac_hours numeric(6,2) NULL,
sick_hours numeric(6,2) NULL,
active_fg bit NOT NULL DEFAULT 1 )
INSERT INTO [HumanResources].[Employee4]
(emp_id, last_name, first_name, job_title, hire_date, vac_hours,
sick_hours, active_fg)
VALUES
(More notes on the next slide)

26. Demo
Maintenance Plan backup

27. Demo: Maintenance Plan backup
10: Backup and recovery
Demo: Maintenance Plan backup
In this demonstration, you will learn to:
Create a maintenance plan using SQL Server Management Studio.
Schedule the plan for future execution.
Use SQL Server Agent – Job Activity Monitor to monitor the execution status.
Demonstration Steps
Open SQL Server Configuration Manager by going to Start → All Programs → Microsoft SQL Server 2014 → Configuration Tools.
Launch the SQL Server Agent (INST01) service, if it is not started already.
From SQL Server Management Studio, expand the Management folder within the Object Explorer for INST01.
Right-click Maintenance Plans and select the New Maintenance Plan option.
Enter AW2012MaintPlan in the Name property of the New Maintenance Plan window.
Click OK.
Enter AdventureWorks2012 Maintenance Plan in the Description property.
From the Toolbox, now visible below the Object Explorer, drag a Back Up Database Task object to the designer surface.
Double-click the task object to open the editor window.
Click the New Connection button, and then enter SQLTBWS\INST01 in the Connection Name and Select or Enter a Server Name text boxes.
Use Windows NT Integrated security.
Click the drop-down arrow next to Database(s), and select the radio button next to These Databases.
Check the AdventureWorks2015 database.
Select the checkbox to Verify backup integrity.
(More notes on the next slide)

28. Resources
Backup Overview (SQL Server)
Create a Maintenance Plan

29. Lesson 4
Data recovery strategies

30. Lesson 4: Data recovery strategies
Factors affecting restore strategies
Availability requirements
Storage requirements
Data usage requirements
Technical requirements
Point in time restore
Data recovery advisor

31. Data Recovery Factors affecting backup restore strategy decisions
11: Backup and Recovery
Data Recovery
Factors affecting backup restore strategy decisions
Availability Requirements
Storage Requirements
Data usage Requirements
Technical Requirements
Next 4 slides have details on questions that need answering to understand how to design a recovery strategy. Unhide and show if needed for audience.
There are several factors affecting a restore strategy decisions and it is important to understand potential data loss risks. We call it restore strategy as your RPO and RTO drive the backups that must be configured.
For example:
For financial transactions you cannot tolerate any loss.
If availability is important you need to plan for fast recovery.
You can trade off between transaction rate and transaction logs (Tlogs)
Understand how long you can be down so you do not overprotect the data
Is data mission-critical? Perhaps it is OK to be down but NOT OK to lose data (for example, stock trades)
The nature of data access – can you afford to take data offline to do a restore?
What storage resources can you use – local backups then to tape or cloud ?
Cost of hardware and software and related budgets – compare the cost of storage for backups vs. need
Load Requirements. Manage Scheduler schedules – no more than one scheduler per processor using hidden schedulers. This allows backups to run with low impact.

32. Data Recovery Restoring a Database to a point within a Backup 40074A
11: Backup and Recovery
Data Recovery
Restoring a Database to a point within a Backup
The illustration shows a restore to a recovery point in the middle of a transaction log that was taken at time t9.
Changes in the remainder of this backup and the subsequent log backup that was taken at time t10 are discarded
Restoring a Database to a Point Within a Backup (

33. Data Recovery Native backup and recovery solution
The Database Recovery Advisor is a feature to easily allow SSMS users to do point-in-time database restore and Database Page restores from the GUI.
Overview of the Database Recovery Advisor
The Database Recovery Advisor is a SQL Server feature to make it easier for SSMS users to do point-in-time database restore and Database Page restores.
This improvement intends to enhance the user experience around the Database Restore operation by visually presenting the backup history of database on a time-line and allowing the user to select a feasible point-in-time for database restoration. The Restore Plan generation will be automated while exposing some restore related options.
This improvement will add a new Page Level Restore Dialog for user databases and updates the existing Database Restore dialog. The users will be able to figure out which data pages are corrupt directly from the dialog and will be able to do Page Restores from the backups.
Reference:

34. Data Recovery Third-party backup and recovery solutions
System Center Data Protection Manager (DPM) provides a centralized backup solution for SQL Server
Third-party backup and recovery tools interface RDBMS native backup and restore components with media management. Some examples include:
Veritas NetBackup
Red Gate’s SQL Backup Pro
Dell’s LightSpeed
Idera’s SQL Safe Backup
System Center supports centralized backups if required.
There are also several third-party tools available as shown here.

35. Resources Recovery Advisor: An Introduction
Restoring a Database to a Point Within a Backup
System Center Data Protection Manager

36. Lesson 5
Backup and recovery with Azure

37. Lesson 5: Backup and recovery with Azure
Overview of enhanced backup to Azure
Demo: Backup database to Azure blob storage
Demo: SQL Server Managed Backup to Azure

38. Enhanced backup to Azure
SQL Server Managed Backup to Microsoft Azure -
SQL Server Backup to URL -
File-Snapshot Backups for Database Files in Azure -
Managed backup
Granular control of the backup schedule;
Local staging support for faster recovery and resilient to transient network issues;
Support for system databases;
Support simple recovery mode.
Backup to Azure block blobs
Cost savings on storage;
Significantly improved restore performance; and
More granular control over Azure storage.
File-Snapshot Backups for Database Files in Azure
Fastest method for creating backups and running restores
Uses SQL Server db files on Azure Blob Storage

39. Demo
Backup database to Azure blob storage

40. Demo: Backup database to Azure blob storage
-- Backup database to the backup container
BACKUP DATABASE[AdventureWorks2016]
TO URL = '<your blob service endpoint>/backup/AdventureWorks2016Test1.bak'
WITH CREDENTIAL = 'mycredential'; GO
Configure credential and certificate for Azure
Backup the databases
Drop the database
Restore the database from Azure
Create an encrypted backup and restore with it back

41. Demo
SQL Server Managed Backup to Azure

42. Demo: SQL Server Managed Backup to Azure
Use msdb; GO
EXEC msdb.managed_backup.sp_backup_config_basic
@enable_backup = 1,
@database_name = 'yourdatabasename',
@container_url = '
@retention_days = 30
Configure a managed backup
Display backup events
Disable managed backup
See tutorial at

43. Resources Enable SQL Server Managed Backup to Microsoft Azure
SQL Server Backup and Restore with Microsoft Azure Blob Storage Service
File-Snapshot Backups for Database Files in Azure
Restoring From Backups Stored in Microsoft Azure

44. Module Review Data recovery basics Data recovers models
9/10/ :16 AM
Module Review
Data recovery basics
The SQL Server Migration Assistant (SSMA), Microsoft Assessment and Planning Toolkit (MAP) tool, and SQL Server Integration Services (SSIS) combined with Oracle client drivers (and others) can be used in support of the following aspects of an Oracle or SAP migration:
Migration process & tooling
Data deployment
Cloud migration
Data recovers models
Understanding database backup methods
Data recovery strategies
Backup and recovery with Azure
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

45. 9/10/ :16 AM
© 2016 Microsoft Corporation. All rights reserved. Microsoft, SQL Server, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.