FlareCo Ltd 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. Slide 3 Database Mirroring

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. Slide 4 Database Mirroring

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 Slide 5 Database Mirroring

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 Slide 6 Database Mirroring

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 Slide 7 Database Mirroring

FlareCo Ltd 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 Slide 9 Database Mirroring

FlareCo Ltd The backup Slide 10 Database Mirroring

FlareCo Ltd Backup the Database File Slide 11 Note name and directory for backup Database Mirroring

FlareCo Ltd Backup the Transaction Log Slide 12 Database Mirroring

FlareCo Ltd Restore the backup Slide 13 Database Mirroring

FlareCo Ltd Slide 14 Database Mirroring

FlareCo Ltd Slide 15 Database Mirroring

FlareCo Ltd Slide 16 Database Mirroring

FlareCo Ltd Set up the mirroring Slide 17 Database Mirroring

FlareCo Ltd Click on Configure Security Slide 18 Database Mirroring

FlareCo Ltd Slide 19 Database Mirroring

FlareCo Ltd Slide 20 Database Mirroring

FlareCo Ltd Leave accounts clear Slide 21 Database Mirroring

FlareCo Ltd Slide 22 Database Mirroring

FlareCo Ltd Slide 23 Database Mirroring

FlareCo Ltd Don’t start Mirroring Slide 24 Database Mirroring

FlareCo Ltd 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. Slide 27 Log Shipping

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. Slide 28 Log Shipping

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 Slide 29 Log Shipping

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.) Slide 30 Log Shipping

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. Slide 31 Log Shipping

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. Slide 32 Log Shipping

FlareCo Ltd Log Shipping Copies transactions from a Primary Server to one or more Secondary Servers. Slide 33 Log Shipping

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 Slide 34 Log Shipping

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 Slide 35 Log Shipping

FlareCo Ltd Mirroring vs Log Shipping MirroringLog 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 databaseMultiple copies on multiple servers Provides immediate restoreDelayed restore – Allows you to avoid logical errors Slide 36 Log Shipping

FlareCo Ltd 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 Slide 38 Log Shipping

FlareCo Ltd Changing the Recovery Model Slide 39 Log Shipping

FlareCo Ltd Backup the database Slide 40 Log Shipping

FlareCo Ltd Backup the Transaction Log Slide 41 Log Shipping

FlareCo Ltd Restore the database to the secondary server Slide 42 Log Shipping

FlareCo Ltd Configure Log Shipping Slide 43 Log Shipping

FlareCo Ltd Slide 44 Log Shipping

FlareCo Ltd Slide 45 Log Shipping

FlareCo Ltd Slide 46 Log Shipping

FlareCo Ltd Slide 47 Log Shipping

FlareCo Ltd Click OK to configure the log shipping Slide 48 Log Shipping

FlareCo Ltd Test the shipping Slide 49 Log 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 Slide 51