DBAs and system architects know that Disaster Recovery (DR) is about more than just a failover tool: it is about having real-time status information, the ability to easily and quickly run DR Tests, and ways of utilizing standby infrastructure for value-adding activities. 

One method of getting extra value from your DR infrastructure is to utilize your standby database for reporting and analytics. We've been listening to your suggestions and today I’m proud to present two new highly-requested features for our SQL Server DR solution: (1) Scheduled Standby Reporting State and (2) Log Backup Retention.

1. Scheduled Standby Reporting

This new feature enables you to easily create and configure an agile standby database that serves both DR needs (with a great RPO/RTO) and can also be used to offload analytical queries from the primary. Reporting has never been this easy!

The challenge with reporting from SQL Server standby environments is that it is not possible to simultaneously maintain a connection to a database and restore transaction logs to it, even if the database is in Read-Only (RO) mode. To manage regular log application and RO access at the same time, it would typically be necessary to implement a system of CRON jobs, custom scripts and/or log application scheduling through SMSS (SQL Server Management Studio), all of which would switch the database between states as well as manage log file transfer and application.

Using StandbyMP for your SQL Server DR, you can now take advantage of the new ‘Scheduled Standby Reporting’ feature to simplify and automate this entire process. Simply specify a time(s) when you expect to run your reporting queries, and StandbyMP will do everything else for you; automatically managing database state transitions, log file transfer and apply, and monitoring changes. 

          [Image: Scheduled Standby Reporting at 8 pm on Saturdays for 1 hour]

2. Log Backup Retention

With log backup retention, you can configure how long you would like to keep log backups (transaction log backups), allowing you to utilize log backups for other backup tasks or uses.

StandbyMP is well-suited to managing your warm standby requirements, however taking (and storing) backups should also be a part of your second-line DR strategy. You now have the option to utilize log backup files on the primary or standby as part of your backup plan. This eliminates the need to do a copy-only transaction log backup as part of your backup strategy. 

                      [Image: Log Backup Retention set for 12hrs on primary and 72hrs on standby] 

Easily configure how long you want to keep the log backups. Then, feel free to copy these and retain them for your backups, or to use them on additional systems not managed by StandbyMP. Avoid having to take the same backup more than once, streamline your process and reduce the load on your database - done!

Next Steps

StandbyMP for SQL Server just keeps getting better! We recommend current customers update as soon as possible on our download site. For potential customers, why not take a trial of our smarter alternative to Log Shipping and Basic Availability Groups? You’ll be amazed at how easy it is to set up a new environment or migrate from Log Shipping.

About Dbvisit StandbyMP for SQL Server:

Dbvisit StandbyMP is a smarter, more automated alternative to Log Shipping and Basic Availability Groups that saves you time and delivers enhanced standby database functionality, all from a highly intuitive GUI, and backed by industry-leading DBA support.