flareco ltd alter database adventureworks set partner force_service_allow_data_loss slide 1

FlareCo Ltd

DATABASE MIRRORING

ALTER DATABASE AdventureWorks SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

Slide 1

FlareCo Ltd Database Mirroring. What is it?

• Is a mixture of replication and log shipping• It moves database transactions from one SQL Server database to another

SQL Server database on a different instance of SQL Server. • This mirrored copy is a standby copy and can not be accessed directly; it is

used only for a failover situation

Slide 2 Database Mirroring

FlareCo Ltd Database Mirroring: How does it work?

• At least 2 instances of SQL Server• Primary server is the "principal"

– This is the LIVE database• Secondary server is the "mirror.“

– This is the STANDBY • As transactions are written to the principal database they are also sent

and written to the mirrored database.


FlareCo Ltd Three modes of operation

• High Availability: – synchronizes transaction writes on both servers and enables automated

failover. – Needs a witness server to act as arbiter.

• High Protection: – synchronizes transaction writes on both servers, but failover is manual.

• High Performance: – Doesn’t care if the writes are synchronized on both servers, so is faster.– assumes that everything is going to complete successfully on the mirror.


FlareCo Ltd Relative merits

• Automatic failover to a secondary copy of your data is the real benefit of Database Mirroring.– So most implementation will probably use the High Availability mode.

• The other options still offer a built-in process for failing over, but require manual intervention


FlareCo Ltd The process

• Without Mirroring:• When a user makes a change to a database:

– Change is stored in the Log Buffer– Log Buffer is written to the Transaction Log

• This is called Hardening– Changes that have been written to the Transaction Log are Flushed (written)

to the database


FlareCo Ltd The process

• With Mirroring:• When a user makes a change to a database:

– SQL Server stores the change in the database’s log file– Log buffer is written to the transaction log AND principal server copies log

buffer to the mirror server– Mirror server hardens the transaction log– Changes are then flushed to the principal server’s database– Changes in the transaction log on the mirror server are replayed against the

mirror database, making it a copy of the principal


FlareCo Ltd

PRACTICAL EXERCISE

Slide 8

FlareCo Ltd

• First we shall produce a copy on the mirror server by backing up the sales database from the principal machine

• Then we shall set up the mirror environment


FlareCo Ltd The backup


FlareCo Ltd Backup the Database File

Slide 11

Note name and

directory for backup

Database Mirroring

FlareCo Ltd Backup the Transaction Log


FlareCo Ltd Restore the backup


FlareCo Ltd


FlareCo Ltd Set up the mirroring


FlareCo Ltd Click on Configure Security


FlareCo Ltd


FlareCo Ltd Leave accounts clear


FlareCo Ltd


FlareCo Ltd Don’t start Mirroring


FlareCo Ltd

LOG SHIPPING

Slide 25

FlareCo Ltd A note about recovery models

• full recovery, • simple recovery and • bulk-logged recovery. • The recovery models determine how much data loss is acceptable in case

of a failure and what types of backup and restore functions are allowed.

Slide 26 Log Shipping

FlareCo Ltd Simple

• The simple recovery model allows you to recover data only to the most recent full database or differential backup. Transaction log backups are not available because the contents of the transaction log are truncated each time a checkpoint is issued for the database.


FlareCo Ltd Full

• The full recovery model uses database backups and transaction log backups to provide complete protection against failure. Along with being able to restore a full or differential backup, you can recover the database to the point of failure or to a specific point in time. All operations, including bulk operations such as SELECT INTO, CREATE INDEX and bulk-loading data, are fully logged and recoverable.


FlareCo Ltd Bulk Logged

• Bulk-Logged• The bulk-logged recovery model provides protection against failure

combined with the best performance. • SELECT INTO, bulk-load operations, CREATE INDEX as well as text and

image operations are not logged• Under the bulk-logged recovery model, a damaged data file can result in

having to redo work manually based on the operations that are not fully logged


FlareCo Ltd Use Simple when

– Your data is not critical. – Losing all transactions since the last full or differential backup is not an

issue. – Data is derived from other data sources and is easily recreated. – Data is static and does not change often. – Space is limited to log transactions. (This may be a short-term reason,

but not a good long-term reason.)


FlareCo Ltd Bulk Logged when

– Data is critical, but logging large data loads bogs down the system. – Most bulk operations are done off hours and do not interfere with

normal transaction processing. – You need to be able to recover to a point in time.


FlareCo Ltd Full when

– Data is critical and no data can be lost. – You always need the ability to do a point-in-time recovery. – Bulk-logged activities are intermixed with normal transaction

processing. – You are using replication and need the ability to resynchronize all

databases involved in replication to a specific point in time.


FlareCo Ltd Log Shipping

• Copies transactions from a Primary Server to one or more Secondary Servers.


FlareCo Ltd Server roles in Log Shipping

• Primary– The production server

• All log shipping takes place on this machine

• Secondary– Holds the standby copy of the database

• Initialise by restoring a backup from the primary– Use NORECOVERY or STANDBY option– STANDBY allows users read-only access to the database while backups are

restored

• Monitor– Tracks log shipping details


FlareCo Ltd Jobs

• Four jobs are involved in Log Shipping• Backup

– Runs on primary server every 2 mins by default

• Copy– Runs on each secondary server just after the backup completes

• Restore– Restores on the secondary servers

• Alert– Optional – runs on the monitor server– Raises alerts on primary and secondary servers


FlareCo Ltd Mirroring vs Log Shipping

Mirroring Log Shipping

Database log buffer is copied from one server to another and then replayed

Transaction log backups are sent to one or more secondary servers and then restored on each secondary server

One copy of original database Multiple copies on multiple servers

Provides immediate restore Delayed restore – Allows you to avoid logical errors


FlareCo Ltd

LOG SHIPPING PRACTICAL EXERCISE

Slide 37

FlareCo Ltd

• Change the Recovery model to FULL• Backup the AdventureWorks database from the principal and restore it on

the secondary server• Ship the logs to the second instance


FlareCo Ltd Changing the Recovery Model


FlareCo Ltd Backup the database


FlareCo Ltd Backup the Transaction Log


FlareCo Ltd Restore the database to the secondary server


FlareCo Ltd Configure Log Shipping


FlareCo Ltd


FlareCo LtdClick OK to configure the log

shipping


FlareCo Ltd Test the shipping


FlareCo Ltd

Slide 50

Wait 5 minutes and then check to see that your record has been shipped t o the secondary database

Log Shipping

FlareCo Ltd

THE END

Slide 51

flareco ltd alter database adventureworks set partner force_service_allow_data_loss slide 1

Documents

database slide

database file slide

principal slide

backup slide

mirror database

principal database

transaction log slide

loss slide