It depends. ha ha.
You also need to think about what data-loss requirements the customer wants for the publisher, and whether you're already taking log backups (I'm guessing you are).
Database mirroring can be set to have zero data-loss (as long as the mirror stays synchronized), but depending on the transaction log generation rate and the network bandwidth available, waiting for the log records to be hardened on the mirror before the transactions can commit on the principal may slow the workload down. Depends on what kind of transactions you're doing (long or short) whether this will have a noticeable effect on the overall response time.
With log shipping, it's just backup-copy-restore, repeat. So if you're already taking log backups, you're not going to be impacting performance at all. If you're not used to taking log backups, you may run into issues with transaction log size management.
Be aware that mirroring requires the FULL recovery model, so it could impact your database maintenance, especially if you're used to using the BULK_LOGGED recovery model. Depending on the network bandwidth available, this could also lead to log size management issues.
Both require network bandwidth, but in different ways. Log shipping is a burst every time a log backup is copied, database mirroring is more sustained, obviously depending on the log generation rate again. I'd need ot know a lot more to be able to tell whether the amount of extra bandwidth required for either would impact the movement of data in the replication stream and so affect latency there.
With log shipping, you'd have to manually failover to the log shipping secondary in the event of a failure, and there's the potential for data loss (all data since last log backup that was copied from the primary). And then you'd need to kick-start repl again.
With database mirroring, you can set it to failover automatically and you can specifically set the failover partner in the repl agent jobs to startup automatically on the new principal (which is also the new publisher). The trickiness is making sure that the datbase mirroring failover doesn't occur before the local cluster failover gets a chance to happen. You can do this by changing the mirroring partner timeout value. I blogged about this at http://www.sqlskills.com/BLOGS/PAUL/post/Search-Engine-QA-3-Database-mirroring-failover-types-and-partner-timeouts.aspx.
I wrote a whitepaper for Microsoft that describes how to use mirroring and tranasactional replication together: see http://www.sqlskills.com/BLOGS/PAUL/post/SQL-Server2008-New-whitepaper-on-combining-transactional-replication-and-database-mirroring.aspx.
All other things being equal, I'd recommend database mirroring because of the ease of management with potential for less dataloss. You may have some other requirements I'm not aware of that would prevent that though.
Hope this helps.
First, have you tried running the SQL installer with the SKUUPGRADE=1
switch?
Second, the easiest way I can think of to move if that does not work would be to:
- Install web edition side by side
- Take down the site
- Detach the database files (mdf and ldf) from the Express DB
- Attach the database files (mdf and ldf) to the web edition DB
- Bring site back up
Best Answer
I'm using log shipping extensively with SQL Server Standard edition. Replication also works fine with Standard edition. (Here are the SQL versions that support log shipping out of the box. Here is a less extensive chart with how the versions of SQL Server support replication.)
Since you're using Express, you don't have access to SQL Server Agent, which limits your possibilities. SQL Express can't be a publisher or a distributor because it needs the agent for that. And if you use a wizard to set up log shipping, it creates Agent jobs to run it.
You can, however, log ship to and from Express manually using Windows Task Scheduler. Basically, create a task scheduler job to use SQLCMD to back up the logs and move them to a share and/or restore the logs. (If you need to query the secondary database you'll need to restore it in Standby rather than Norecovery.)
You can also Replicate from SQL Standard edition to Express, as long as the server running Express is the subscriber rather than the publisher or distributor.