8/13/2019 Disaster Recovery Strategy_PR

1/1

QWe've been evaluating the disaster recovery strategyat my organization, and I think database mirroring is the

right way to go for our situation. The server I'm trying to protect has a lot of unrelated databases (the result of a

prior server consolidation proect!, and I'd like to use database mirroring for all of them. The "uestion I'm struggling

to answer is how many databases will I be able to mirror before performance starts to degrade#

A The answer to this "uestion is one I use very fre"uently$ It depends% The published guidelines say not to mirror

more than & databases per instance, but & is ust a rough guess at what the maimum will be for most users. )ou

need to consider the following factors for your hardware setup$

*ow much memory do the principal and mirror instances have# (Ideally, this should be the same.!

*ow much processing power do the principal and mirror instances have# (This should also be the same.!

*ow much bandwidth does the I+ subsystem have on the mirror instance# (This should be the same as on

the principal.!

*ow much transaction log does the workload on each of the databases generate#

*ow much network bandwidth is available between the principal and the mirror instances#

The last two factors are the most critical. If the network bandwidth available between the two instances is not enough

to handle the combined transaction log generation rate per second from all the databases being mirrored, then

performance will drop on the principal databases. -/ -erver 01 helps alleviate some of this burden with log

stream compression.

The net most critical thing to consider is the memory and thread re"uirements for mirroring. 2ach mirrored database

takes one thread plus some memory. n low3powered servers, lots of mirrored databases may be too much load on

the server when combined with the regular workload.

)ou also need to consider how you're going to run database mirroring. In synchronous mode, transactions on the

principal database cannot commit until all the transaction log records have been copied to the mirrored database's

transaction log. Therefore, any delay caused by an overloaded network could cause a workload performance issue on

the principal.

In asynchronous mode, transactions can commit on the principal without having to wait, but a network delay could

cause the amount of transaction log waiting to be sent to the mirror to grow. This can cause issues with transaction

log size. Worse, any unsent transaction log will be lost in the event of failure4so the more unsent transaction log, the

more potential there is for data loss in a recovery situation.

-cenarios can vary greatly, and I've seen some interesting eamples in real production environments. 5or instance, I

saw one environment with &6 databases, all of which had very small amounts of activity and not all at the same

time. 7ll &6 database are mirrored with no problems.

n the contrary, I've seen a setup that has only three heavily loaded databases, but without a good network

connection. In that scenario, they can barely mirror one database before the lack of network bandwidth causes

workload degradation.

The key to success is to, first, do the log generation calculation. If it seems that the available network bandwidth willsupport the number of databases you want to mirror, you may be 8. Test your configuration before you put it into

production and make sure to include all operations that could generate transaction log4especially any database

maintenance you may do.

Paul S. Randalis the 9anaging :irector of -/skills.comand a -/ -erver 9;.