• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 841
  • Last Modified:

SQL 2008 R2 Mirroring: Edition comparison

Hi

I am trying to come up with a solution for a client and after reading multiple sources of information I am still not 100%.

What I am trying to achieve:

They will have an SQL 2008 R2 Server (edition to be decided) hosting 2 databases: Sage 200 and BES.

These databases should not be too heavily utilized, as Sage 200 will have a single user license and BES is only for 13-15 users.

We need to ensure near instant DR for these databases.

Was going to propose setting up a second SQL Server at a DR site (have one available) with database mirroring over a VPN. 10Mb connection at DR site and 100Mb connection at HQ.

The idea is should HQ go down, we can make the DR SQL the principal database until HQ comes back up, then failback (manual/automatic failover not too important at this stage)

Questions I have are:

-Will this work, in principal?
-Is there a better way to achieve this?
-Any "gotchas" to look out for?
0
bikerhong
Asked:
bikerhong
  • 4
  • 4
1 Solution
 
DBAduck - Ben MillerPrincipal ConsultantCommented:
In principle it should work the way you describe it.

The edition considerations are such:

Mirroring asynchronous -Enterprise
Mirroring synchronous - Standard

The log stream can be compressed so the bandwidth should be fine in your case.

If you want automatic failover you have to put a Witness in the mix.
0
 
bikerhongAuthor Commented:
How about Log Shipping? Would that work?
0
 
DBAduck - Ben MillerPrincipal ConsultantCommented:
You can use Log Shipping on either edition, and there is no automatic failover, but you could use it.

In SQL 2008 R2 you can use Backup Compression in either Standard or Enterprise and copy the logs to the other location and restore.
0
NEW Veeam Backup for Microsoft Office 365 1.5

With Office 365, it’s your data and your responsibility to protect it. NEW Veeam Backup for Microsoft Office 365 eliminates the risk of losing access to your Office 365 data.

 
bikerhongAuthor Commented:
Thanks - one last question which I cant seem to get an answer to:

Can you log ship more than 1 database and 1 instance?

I.E if I had 2 databases on 1 instance and 1 database on a second instance, could I log ship the lot?
0
 
DBAduck - Ben MillerPrincipal ConsultantCommented:
Yes, you can log ship each database individually to another instance or the same instance (with a different db name).
0
 
bikerhongAuthor Commented:
What I meant was is it possible to log ship more than 1 database from 2 different instances on the same principal server?

Read somewhere that log shipping is limited to one source instance only - but cannot find confirmation.
0
 
jaLoudenCommented:
Hi,

In log shipping you can have once principle (the source) database, and mulitple targets (stand by dbs). For example if you had a database called  Tom on server a you could log ship this to a standy by database on Server B, and Server B.

You can not have a single target getting logs from two different sources.

hope that helps.

Cheers
JL
0
 
bikerhongAuthor Commented:
Yes but how about having a Server A with Database 1 in Instance 1 & Database 2 in Instance 2 being log shipped to Server B with Database 1a in Instance 1a and Database 2a in Instance 2a?
0
 
DBAduck - Ben MillerPrincipal ConsultantCommented:
Every concoction that you can think of with Log Shipping can be done except the scenario above where you want to Ship to a single target from multiple sources.

So when you go database to database on any instances (with the caveat that they be the same version of SQL if you are going to do ReadOnly/Standby) you can do any combination.

1 source to 4 targets - yes
1 source to 1 target wherever - yes

You can think of a Log Ship like a backup and restore.  You are merely restoring logs to another restore of a database and just not recovering until you are ready to use it as a principal.  I have even log shipped over the internet with FTP being the transfer mechanism.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now