Sql server lesson10

 Backups are taken to reduce the risk of data loss.
 Because it is more common to back up a database than to restore
one, the backup engine is optimized for backup process.
 The only two parameters required for a backup are the name of the
database and the backup device. UP to 64 devices could be used for
a backup.
 Because the backup process is not concerned with the ordering of
pages, multiple threads can be used to write pages to the backup
devices.
 When a backup is initiated, the backup engine grabs pages from the
data files as quickly as possible, without regard to the order of
pages.
 The limiting factor for the speed of a backup is the performance of
the device where the backup is being written.
 The backup engine is optimized for the backup process.

 SQL SERVER performs the steps of the backup procedure as
follows:
1) Locks the database , blocking all transactions
2) Places a mark in the transaction log.
3) Releases the database lock
4) Extracts all pages in the data files and writes them to the backup
device
5) Locks the database, blocking all transactions
6) Places a mark in the transaction log.
7) Releases the database lock.
8) Extracts the portion of the log between the marks and appends it to
the backup.

 Design and implement a well thought backup strategy to suit the
needs of your organization.
 Perform backups more often.
 Decrease backup times by using a compression.
 Use various media for backups.
 Increase number of backup copies.
 Keep backup copies at different places.
 Allocate only a single backup per file.
 Use of meaningful names for the backup files.

 Full Backup
 Captures all pages within a database that contain data.
 Pages that do not contain data are not included in the backup.
 The database is fully operational during a full backup. The
operations that are not allowed during the full backup are:
 Adding or removing a database file.
 Shrinking a database.
 Partial Backup
 Captures only the filegroups that can change. Read only filegroups
are not included to minimize the size of the backup.
 Differential Backup
 Captures all extents that have changed since the last full backup.
The primary purpose of a differential backup is to reduce the
number of transaction log backups that need to be restored. A
differential backup has to be applied to a full backup and can’t exist
until a full backup has been created.

 Transaction Log
 Every change made to a database has an entry made to the
transaction log.
 Filegroup
 Individual file or a filegroup backup.

 Full backups capture all the used pages across the entire database.
 A full backup captures all pages within a database that contain data.
 Pages that do not contain data are not included in the backup.
 A backup is never larger, and in most cases is smaller, than the database for
which it is created.
 A full backup is the basis for recovering a database and must exist before you
can use a differential or transaction log backup.
 Backing up a database to multiple files can lead to a significant reduction in
backup time, particularly for large databases.
 An example of a multiple files (striped backup) is:
BACKUP DATABASE AdventureWorks
TO
DISK = 'AdventureWorks_1.bak',
DISK = ' AdventureWorks_2.bak'


 Every change made to a database has an entry made to the transaction log.
 Each row is assigned a unique number internally called the
Log Sequence Number (LSN).
 LSN Is an integer value that starts at 1 when the database is created and
increments to infinity.
 LSN Is never reused for a database and always increments.
 LSN provides a sequence number for every change made to a database.
 The contents of a transaction log are broken into two basic parts:
 Inactive : contains all the changes that have been committed to the
database.
 Active : contains all the changes that have not yet been committed.
 When a transaction log backup is executed, SQL Server starts with the lowest
LSN in the transaction log and starts writing each successive transaction log
record into the backup. As soon as SQL Server reaches the first LSN that has
not yet been committed (that is, the oldest open transaction), the transaction
log backup completes.


 The portion of the transaction log that has been backed up is then
removed, allowing the space to be reused.
 A transaction log backup gathers all committed transactions in the log
since the last transaction log backup.
 Based on the sequence number, it is possible to restore one transaction
log backup after another to recover a database to any point in time by
simply following the chain of transactions as identified by the LSN
 If an LSN gap is introduced, you must create a full backup before you can
start backing up the transaction log.
 Before you can issue a transaction log backup, You must execute a full
backup.

BACKUP LOG { database_name | @database_name_var }
TO <backup_device> [ ,...n ]
[ <MIRROR TO clause> ] [ next-mirror-to ]
[ WITH { <general_WITH_options> |<log-specific_optionspec> } [ ,...n ] ][;]


 The primary purpose of a differential backup is to reduce the number of
transaction log backups that need to be restored.
 A differential backup captures all extents that have changed since the last
full backup.
 For Example : If a full backup was taken at midnight and a differential
backup occurred every four hours, both the 4 A.M. backup and the 8 A.M.
backup would contain all the changes made to the database since midnight.
 A differential backup has to be applied to a full backup and can’t exist until a
full backup has been created.
 Each database in the header has a special page called the Differential
Change Map (DCM).
 DCM keeps the counter of changes occurred since last full backup.
 A FULL BACKUP zeroes out the contents of the DCM.

 COPY_ONLY Option
 The COPY_ONLY option allows to create a backup that can be used
to create the development or test environment as it does not affect
the database state or set of backups in production.
 A FULL BACKUP with the COPY_ONLY option does not reset the
differential change map page and therefore has no impact on
differential backups.
 A TRANSACTION LOG BACKUP with the COPY_ONLY option does
not remove transactions from the transaction log.


 File or filegroup backups are used to reduce the footprint of a
backup, as it only targets a portion of a database to be backed up.
 Because for successful recovery of a database, you need all the
files underneath a filegroup, but not an individual files.
 Filegroup backups can be used in conjunction with differential and
transaction log backups to recover a portion of the database in the
event of a failure.
 The database can remain online and accessible to applications
during the restore operation. Only the portion of the database being
restored is off-line.

 Partial Backup
 To reduce the size of a backup to only the filegroups that can
change, you can perform a partial backup.
 When a partial backup is executed, SQL Server backs up the
primary filegroup, all read/write filegroups, and any explicitly
specified read-only filegroups.
 Partial backups are performed by specifying the
READ_WRITE_FILEGROUPS option as follows :
BACKUP DATABASE database_name
READ_WRITE_FILEGROUPS [,<file_filegroup_list>]
TO <backup_device>

 Page Corruption
 When SQL Server encountered a corrupt page, SQL Server detects
and quarantines corrupted pages using Checksum
ALTER DATABASE <dbname> SET PAGE_VERIFY CHECKSUM
 When SQL Server writes a page to disk, a checksum is calculated for the
page. When you enable page verification, each time a page is read from
disk, SQL Server computes a new checksum and compares it to the
checksum stored on the page. If the checksums do not match, SQL Server
returns an error and logs the page into a table in the MsDb database.
 SQL Server has a protection mechanism in place to protect your database
from massive corruption. You are limited to a total of 1,000 corrupt pages
in a database. When you reach the corrupt page limit, SQL Server takes the
database off-line and places it in a SUSPECT state to protect it from further
damage.

 Maintenance Plans
 Maintenance plans provide a mechanism to graphically create job
workflows that support common administrative functions such as
backup, re-indexing, and space management.
 The most common tasks performed by maintenance plans are database
backups.
 Tasks that are supported by maintenance plans are:
 Backing up of databases and transaction logs
 Shrinking databases
 Re-indexing
 Updating of statistics
 Performing consistency checks.
 Instead of writing the code to back up a database, you can configure a
maintenance plan to perform the backup operations that you need to
support your disaster recovery requirements.

 Maintenance Plans (continue…)
 Executing Maintenance Plans:
1) Loads the SQL Server Integration Services (SSIS) engine.
2) Then the .NET Framework interprets the tasks within the
package, constructs the necessary backup statements, and
executes the code generated.

 Certificates and Master Keys
 Transparent Data Encryption (TDE) allows us to encrypt the
entire database without requiring any changes to the structure of
the database.
 It protects the database in situations where someone breaches
physical and login security and obtains access to the .mdf (data)
files or .bak (backup) files.
 Without TDE or another third-party encryption solution, the files
could be taken offsite and attached or restored.
 SQL Server offers two levels of encryption:
 Database-level
 Cell-level.
Both use the key management hierarchy.
 When TDE is enabled on database, all backups are encrypted.

 Certificates and Master Keys (continue…)
 ENCRYPTING A DATABASE
1) Implementing TDE is in creating a Master key.
USE MASTER
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD =
'some password ' ;
2) Create a Certificate.
USE MASTER
GO
CREATE CERTIFICATE tdeCertificate WITH SUBJECT =
'TDE Certificate ' ;
If we want to restore an encrypted database to another server, the
certificate used to encrypt the database needs to be loaded to the other
server to enable the database to be restored.

3) We can back up the certificate and private key as follows:
-- Backup the certificate
-- Required if restoring encrypted databases to another server
-- Also required for server rebuild scenarios
USE MASTER
GO
BACKUP CERTIFICATE tdeCertificate TO FILE =
‘D:tdeCertificate.backup'
WITH PRIVATE KEY (
FILE = 'e:tdeCertificatePrivateKey.backup',
ENCRYPTION BY PASSWORD = ‘certsPassword ‘)

5) Create the database encryption key (DEK), used for encrypting the
database with Transparent Data Encryption:
-- Create a Database Encryption Key
-- AES encryption algorithm with a 128-bit key
USE [AdventureWorks2008]
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE tdeCertificate
GO
4) Optionally, enable SSL on the server to protect data in transit.
Perform the following steps in the user database. These require
CONTROL permissions on the database.
6) Enable TDE This command starts a background thread
(referred to as the encryption scan), which runs asynchronously.
ALTER DATABASE myDatabase SET ENCRYPTION ON

 SQL Server Encryption Key Hierarchy with TDE and EKM

 Service Master Key (SMK)
 The Service Master Key is the root of the SQL Server encryption
hierarchy. It is generated automatically the first time it is needed
encrypt another key. By default , the service Master Key is encrypted
using the windows data protection API and using the local machine
key.
 Each time that you change the SQL Server service account or
service account password , the service master key is regenerated.
 The first action that you should take after an instance is started is to
back up the service master key.
 You should also back up the service master key immediately
following a change to the service account or service account
password.
BACKUP SERVICE MASTER KEY TO FILE = ‘path_to_file’
ENCRYPTION BY PASSWORD = ‘password’

 Database Master Key (DMK)
 Database master key (DMK) is the root of the encryption hierarchy in
a database.
 To ensure that you can access certificates, asymmetric keys, and
symmetric keys within a database, you need to have a backup of the
DMK.
BACKUP MASTER KEY TO FILE =‘path_to_file’
ENCRYPTION BY PASSWORD = ‘password’
 Before you can back up a DMK, it must be open. By default , a DMK
is encrypted with the service master key. If the DMK is encrypted only
with a password, you must first open the DMK by using the following
command:
USE <database name>;
OPEN MASTER KEY DECRYPTION BY PASSWORD=
‘<SpecifyStrongPasswordHere>’;

 Certificates
 Certificates are used to encrypt data as well as digitally sign code
modules. Although you could create a new certificate to replace the
digital signature in the event of the loss of a certificate, you must
have the original certificate to access any data that was encrypted
with the certificate.
 Certificates have both a public and a private key. You should back up
a certificate immediately after creation by using the following
command.
BACKUP CERTIFICATE certname TO FILE = 'path_to_file'
[ WITH PRIVATE KEY
( FILE = 'path_to_private_key_file' ,
ENCRYPTION BY PASSWORD = 'encryption_password'
[ , DECRYPTION BY PASSWORD = 'decryption_password' ] ) ]
 You can back up just the public key by using the following command:
BACKUP CERTIFICATE certname TO FILE = 'path_to_file'
 If you restore a backup of a certificate containing only the public key, SQL
Server generates a new private key.

 Validating a Backup
 To validate a backup , execute the following command:
RESTORE VERIFYONLY FROM <back device>
When a backup is validated, SQL Server performs the following checks:
 Calculates a checksum for the backup and compares to the checksum
stored in the backup file.
 Verifies that the header of the backup is correctly written and valid.
 Transits the page chain to ensure that all pages are contained in the
database and can be located.


 All restore sequence begin with either a full backup or
filegroup backup.
 When restoring backups, you have the option to terminate
the restore process at any point and make the database
available for transactions.
 After the database of filegroup being restored has been
brought online, you can’t apply any additional differential or
transaction log backups to the database.


 The generic syntax for restoring a full backup is:
RESTORE DATABASE { database_name | @database_name_var }
[ FROM <backup_device> [ ,...n ] ]
[ WITH { [ RECOVERY | NORECOVERY |
STANDBY = { standby_file_name | @standby_file_name_var } ]
| , < general_WITH_options > [ ,...n ]
| , < replication_WITH_option >
| , < change_data_capture_WITH_option >
| , < service_broker_WITH options >
| , < point_in_time_WITH_options — RESTORE_DATABASE >
} [ ,...n ] ]
<general_WITH_options> [ ,...n ]::=
--Restore Operation Options
MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name'
[ ,...n ] | REPLACE | RESTART | RESTRICTED_USER
 When a RESTORE command is issued, if the database does not
already exist within the instance, SQL SERVER creates the database
along with all files underneath the database.
 The REPLACE option is used to force the restore over the top of an
existing database.

 Database state after the
Restore has Completed
 If you want the database to be online and accessible for transactions
after the RESTORE operation has completed, you need to specify the
RECOVERY option.
 When a RESTORE is issued with the NORECOVERY option, the
restore completes, but the database is left in a RECOVERING state
such that subsequent differential and / or transaction log backups can
be applied.
 The Standby option can be used to allow you to issue SELECT
statements against the database while still issuing additional
differential and / or transaction log restores.
 If you restore a database with the STANDBY option an additional file
is created to make the database consistent as of the last restore that
was applied.

 Restoring a Differential Backup
 A differential restore uses the same command syntax as a full
database restore.
 When the full backup has been restored, you can then restore the most
recent differential backup.

 Restoring a Transaction Log Backup
RESTORE LOG { database_name | @database_name_var }
[ <file_or_filegroup_or_pages> [ ,...n ] ]
[ FROM <backup_device> [ ,...n ] ]
[ WITH {[ RECOVERY | NORECOVERY |
STANDBY = {standby_file_name | @standby_file_name_var }]
| , <general_WITH_options> [ ,...n ]
| , <replication_WITH_option>
| , <point_in_time_WITH_options —RESTORE_LOG> } [ ,...n ] ]
<point_in_time_WITH_options—RESTORE_LOG>::=
| { STOPAT = { 'datetime' | @datetime_var }
| STOPATMARK = { 'mark_name' | 'lsn:lsn_number' }
[ AFTER 'datetime' ]
| STOPBEFOREMARK = { 'mark_name' | 'lsn:lsn_number' }
[ AFTER 'datetime' ]
 The STOPAT command allows to specify a date and time to which SQL
Server restores.
 The STOPATMARK and STOPBEFOREMARK options allows to specify
either an LSN or a transaction log MARK to use for the stopping point in
the restore operation.

 Restore a Corrupt Page
 Page corruption occurs when the contents of a page are not consistent.
Usually occurs when disk controller begins to fail.
 Strategy for recovery :
 Index files – drop and re-create
 Data files - restore.
 Page restore has several requirements :
 The database must be in either the Full or Bulked – logged recovery
model.
 You must be able to create a transaction log backup.
 A page restore can apply only to a read/write filegroup.
 You must have a valid full, file, or filegroup backup available.
 The page restore cannot be executed at the same time as any other
restore operation.

 Page Restore Process
1) Retrieve the PageID of the damaged page.
2) Using the most recent full, file, or filegroup backup, execute the
following command:
RESTORE DATABASE database_name
PAGE = 'file:page [ ,...n ]' [ ,...n ]
FROM <backup_device> [ ,...n ]
WITH NORECOVERY
3) Restore any differential backups with the NORECOVERY option.
4) Restore any additional transaction log backups with the
NORECOVERY option.
5) Create a transaction log backup.
6) Restore the transaction log backup from step #5 using the WITH
RECOVERY option.

 Best Effort Restore
 Because pages are restored in sequential order, as soon as the first
page has been restored to a database, anything that previously
existed is no longer valid.
 If a problem with the backup media was subsequently encountered
and the restore aborted, you would be left with an invalid database
that could not be used.
 SQL Server has the ability to continue the restore operation even if the
backup media is damaged. When it encounters an unreadable section
of the backup file, SQL Server can continue past the source of
damage and continue restoring as much of the database as possible.
 This feature is referred to as best effort restore.
 To restore from backup media that has been damaged, you need to
specify the CONTINUE_AFTER_ERROR option for a RESTORE
DATABASE or RESTORE LOG command


 A Database Snapshot is a point-in-time, read-only, copy of a
database.
 Database Snapshot is available only in SQL Server 2008 Enterprise.
 Database Snapshot is not compatible with FILESTREAM. If you
create a Database Snapshot against a database with FILESTREAM
data, the FILESTREAM filegroup is disabled and not accessible.
CREATE DATABASE database_snapshot_name
ON
(NAME = logical_file_name,
FILENAME = 'os_file_name') [ ,...n ]
AS SNAPSHOT OF source_database_name

Reverting Data Using
A Database Snapshot
RESTORE DATABASE <database_name> FROM
DATABASE_SNAPSHOT = <database_snapshot_name>
 Only a single Database Snapshot can exist for the source database.
 Full-text catalogs on the source database must be dropped and then re-
created after the revert completes.
 Because the transaction log is rebuilt, the transaction log chain is
broken.
 Both the source database and Database Snapshot are off-line during
the revert process.
 The source database cannot be enabled for FILESTREAM

Backup Type TSQL
Full Backup BACKUP DATABASE {databasename} TO
{device}.
Transaction log
(Incremental) Backup
BACKUP LOG {databasename} TO {device}.
Differential Backup BACKUP DATABASE {databasename} TO
{device} WITH DIFFERENTIAL
Filegroup Backup BACKUP DATABASE {databasename} FILE =
{filename}, FILEGROUP = {filegroup} TO
{device}
Filegroup Differential
Backup
BACKUP DATABASE {databasename}
FILEGROUP = {filegroup} TO {device} WITH
DIFFERENTIAL
Summary Backup Types

System Database Backups
Database Description
Master Must be backed up after creating, altering or dropping a
database; altering a data or log file; changing logins;
changing configuration options; altering linked servers,
remote servers, etc. Rather than trying to keep track of
changes and only backing up MASTER after changes, it is
usually backed up daily.
Msdb Must be backed-up if the SQL Server Agent is being used to
backup configuration and historical data. It is typically
backed up daily.
Model The model database needs to be backed up only after
changes have been made to it.
Tempdb TEMPDB is never backed up as it is recreated each time
SQL Server is restarted.

Backup History
System Views Description
dbo.backupfile Contains one row for each data or log file that is
backed up
dbo.backupmediafamily Contains one row for each media family
dbo.backupmediaset Contains one row for each backup media set
dbo.backupset Contains a row for each backup set
dbo.backupfilegroup Contains one row for each filegroup in a database at
the time of backup
dbo.logmarkhistory Contains one row for each marked transaction that
has been committed
dbo.suspect_pages Contains one row per page that failed with an 824
error (with a limit of 1,000 rows)
 The history of every SQL Server backup is written to the MSDB database.
This can be accessed easily via using the following system views.

BACKUP DATABASE { database_name | @database_name_var }
TO <backup_device> [ ,...n ]
[ <MIRROR TO clause> ] [ next-mirror-to ]
[ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]
<backup_device>::= { { logical_device_name | @logical_device_name_var }
| { DISK | TAPE } = { 'physical_device_name' | @physical_device_name_var } }
<MIRROR TO clause>::= MIRROR TO <backup_device> [ ,...n ]
<general_WITH_options> [ ,...n ]::=
--Backup Set Options
COPY_ONLY | { COMPRESSION | NO_COMPRESSION }
| DESCRIPTION = { 'text' | @text_variable }
| NAME = { backup_set_name | @backup_set_name_var }
| PASSWORD = { password | @password_variable }
| { EXPIREDATE = { 'date' | @date_var }
| RETAINDAYS = { days | @days_var } }

--Media Set Options
{ NOINIT | INIT } | { NOSKIP | SKIP } | { NOFORMAT | FORMAT }
| MEDIADESCRIPTION = { 'text' | @text_variable }
| MEDIANAME = { media_name | @media_name_variable }
| MEDIAPASSWORD = { mediapassword | @mediapassword_variable }
| BLOCKSIZE = { blocksize | @blocksize_variable }
--Error Management Options
{ NO_CHECKSUM | CHECKSUM }
| { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

Sql server lesson10

Recommended

Recommended

More Related Content

What's hot

What's hot (9)

Similar to Sql server lesson10

Similar to Sql server lesson10 (20)

More from Ala Qunaibi

More from Ala Qunaibi (13)

Recently uploaded

Recently uploaded (20)

Sql server lesson10