In part 9 of our webcast series titled: Implementing Database Mirroring, we covered the steps from setup to failover to monitoring. There were lots of great questions and I think we could easily go back and do a couple more hours on database mirroring, failover combinations – including manual failover and client application questions. Having said that, there were a few interesting scenarios that came up that I thought I’d add a bit more details about here. For simplicity I created sections…<\/SPAN><\/FONT><\/P> Where to go for more information on Database Mirroring and SQL Server SP1 <\/SPAN><\/FONT><\/B><\/STRONG><\/P> Datab<\/FONT>ase Mirroring between Editions<\/SPAN><\/FONT><\/B><\/STRONG><\/P><\/DIV> Database Mirroring is supported in both the Standard Edition (SE) and the Enterprise Engine (EE) Edition(s): Enterprise, Enterprise Eval and Developer. In the EE Editions all configurations (synchronous and asynchronous) are supported: High Availability (sync), High Protection (sync) and High Performance (async). In the SE, only the synchronous forms of Database Mirroring are supported: High Availability and High Protection. One thing that is true however, (and I learned this as well – durin the webcast in Part 9 – thanks to the question submitted and Mark being present…thanks Mark!), is that even while synchronous mirroring is supported in both SE and EE, you can only create a mirroring partnership between servers of the same edition.<\/SPAN><\/FONT><\/P> Database Mirroring between Platforms<\/SPAN><\/FONT><\/B><\/STRONG><\/P><\/DIV> Database Mirroring is supported in both the Standard Edition (SE) and the Enterprise Engine (EE) Edition(s): Enterprise, Enterprise Eval and Developer. In the EE Editions all configurations are supported: High Availability, High Protection and High Performance. In the SE, only the synchronous forms of Database Mirroring are supported: High Availability and High Protection but not the asynchronous High Performance configuration. One thing that is true however, (and I learned this as well in Part 9 – thanks Mark!), is that even while synchronous mirroring is supported in both SE and EE, you can only create a mirroring partnership between servers of the same edition.<\/SPAN><\/FONT><\/P><\/DIV><\/DIV> Combining Database Mirroring with Other Technologies<\/SPAN><\/FONT><\/B><\/STRONG><\/P><\/DIV> The Books Online has a section targeting exactly this discussion. Review this section in the SQL Server 2005 Books Online (April Update): Database Mirroring and Other Features and Components<\/a>. Additionally, I’ve provided a few comments for you to review as well as links to some of the specific BOL topics that exist on these combinations.<\/SPAN><\/FONT><\/P><\/DIV> Database Mirroring with Failover Clustering<\/SPAN><\/FONT><\/B><\/STRONG><\/P><\/DIV> These two technologies CAN be combined but there are multiple things with which you should be aware. First, a failover of a cluster is SLOWER than a failover of a Mirror pair… as a result, it is likely that your secondary server will come online as the new principal in the time that it takes your principal (which is on a cluster) to recover. In a lot of cases, this is good because this keeps you online longer and results in less downtime but it may also be undesireable when your primary is now running at your alternate operations site – which is unstaffed. So, in some cases you may want to prevent automatic failover and instead only use the secondary mirror when you absolutely have to (i.e. NOT just when the cluster fails). If this is the case then you might prefer running with the High Protection configuration of Database Mirroring instead of the High Availability configuration. <\/SPAN><\/FONT><\/P> This will allow you to manually failover when desired.<\/SPAN><\/FONT><\/P> As another option – you can increase the timeout for Database Mirroring failover to 90 seconds. If the cluster comes back online within 90 seconds then the automatic detection\/failover of the High Availabilty configuration will not occur unless the cluster does not <\/STRONG>come back online (as the principal) within x<\/STRONG><\/EM> seconds. You can configure the Database Mirroring Failover timeout by using ALTER DATABASE.<\/SPAN><\/FONT><\/P> ALTER DATABASE dbname SET PARTNER TIMEOUT x<\/SPAN><\/FONT><\/P><\/DIV> Please note, this is only one timeout of many. There are many different types of timeouts in the system that can cause a failover. However, a hard error code generally starts the failure procedure sooner. Mark pointed this out in his failure detection slides in our TechNet webcast series, Part 8.<\/SPAN><\/FONT><\/P> Review this section in the SQL Server 2005 Books Online (April Update): Database Mirroring and Failover Clustering<\/a>.<\/SPAN><\/FONT><\/P><\/DIV> Database Mirroring with Replication<\/SPAN><\/FONT><\/B><\/STRONG><\/P><\/DIV> These two technologies CAN be combined together but not all configurations are supported and where supported, there are specific setup requirements. From the BOL: <\/SPAN><\/FONT>Replication supports mirroring the publication database for merge replication and for transactional replication with read-only Subscribers or queued updating Subscribers. Immediate updating Subscribers, Oracle Publishers, Publishers in a peer-to-peer topology, and republishing are not supported. <\/SPAN><\/FONT><\/I><\/EM><\/P><\/DIV> Database Mirroring with Log Shipping<\/SPAN><\/FONT><\/B><\/STRONG><\/P><\/DIV> These two technologies CAN be combined together but it will require a bit of manual configuration to continue log shipping when a mirror becomes the new principal. <\/SPAN><\/FONT><\/P><\/DIV> Review this section in the SQL Server 2005 Books Online (April Update): Database Mirroring and Log Shipping<\/a>.<\/SPAN><\/FONT><\/P><\/DIV><\/DIV><\/BLOCKQUOTE> And – there are others in the BOL. Please reference the sections listed above for more details.<\/SPAN><\/FONT><\/P><\/DIV>
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n