Comments on: The Power of Next-Generation Archiving Continues to Amaze http://www.mimosasystems.com/blog/archiving/the-power-of-next-generation-archiving-continues-to-amaze/ Fri, 05 Mar 2010 01:02:08 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: Barry Murphy http://www.mimosasystems.com/blog/archiving/the-power-of-next-generation-archiving-continues-to-amaze/comment-page-1/#comment-5 Barry Murphy Thu, 07 Aug 2008 15:48:00 +0000 http://www.mimosasystems.com/blog/archiving/the-power-of-next-generation-archiving-continues-to-amaze/#comment-5 Heath:<br/><br/>Thanks for your comment. In one sense, you are correct – there is an actual “load” on the production system. However, the load is so negligible as to be zero when compared to MAPI or journaling. Microsoft publishes requirements and makes recommendations for disk I/o requirements for environments using log shipping technologies (see Mailbox Storage design : http://technet.microsoft.com/en-us/library/bb738147(EXCHG.80).aspx). Every time data is read from or written to Exchange, disk I/O is generated. Understanding the sources of Exchange disk I/O helps you plan and configure your disk subsystem in a way that maximizes performance. The I/O pattern is 100% sequential writes during normal operations and 100% sequential reads during recovery operations on the transaction log volumes. The load on Exchange to replicate the closed transaction log files is extremely low. Mimosa has run many tests and I/O stats come back with near negligible impact on the I/O subsystem. Importantly, it wouldn’t impact the live database performance as the transaction log files should be on a separate spindle of drives. Furthermore, this is the same method that Exchange 2007 uses for CCR, LCR, and SCR. Log Shipping has also been used with Microsoft SQL and many other databases for many years with negligible impact. If absolutely necessary, we can schedule Log Shipping to run after hours. Heath:

Thanks for your comment. In one sense, you are correct – there is an actual “load” on the production system. However, the load is so negligible as to be zero when compared to MAPI or journaling. Microsoft publishes requirements and makes recommendations for disk I/o requirements for environments using log shipping technologies (see Mailbox Storage design : http://technet.microsoft.com/en-us/library/bb738147(EXCHG.80).aspx). Every time data is read from or written to Exchange, disk I/O is generated. Understanding the sources of Exchange disk I/O helps you plan and configure your disk subsystem in a way that maximizes performance. The I/O pattern is 100% sequential writes during normal operations and 100% sequential reads during recovery operations on the transaction log volumes. The load on Exchange to replicate the closed transaction log files is extremely low. Mimosa has run many tests and I/O stats come back with near negligible impact on the I/O subsystem. Importantly, it wouldn’t impact the live database performance as the transaction log files should be on a separate spindle of drives. Furthermore, this is the same method that Exchange 2007 uses for CCR, LCR, and SCR. Log Shipping has also been used with Microsoft SQL and many other databases for many years with negligible impact. If absolutely necessary, we can schedule Log Shipping to run after hours.

]]> By: Heath http://www.mimosasystems.com/blog/archiving/the-power-of-next-generation-archiving-continues-to-amaze/comment-page-1/#comment-4 Heath Wed, 06 Aug 2008 11:03:00 +0000 http://www.mimosasystems.com/blog/archiving/the-power-of-next-generation-archiving-continues-to-amaze/#comment-4 You comment that there is zero impact on the Exchange server. This is false. If you are reading the Transaction log files, then this is putting an IO load on the Transaction Drive subsystem. In fact when Exchange is running it never reads the Transaction drive it only adds data (writes). So if you have to re-read the logs this is a 100% impact which then has to be committed to the network subsystem. What is worse this is occurring during core operational hours rather than being scheduled for off peak times! You comment that there is zero impact on the Exchange server. This is false. If you are reading the Transaction log files, then this is putting an IO load on the Transaction Drive subsystem. In fact when Exchange is running it never reads the Transaction drive it only adds data (writes). So if you have to re-read the logs this is a 100% impact which then has to be committed to the network subsystem. What is worse this is occurring during core operational hours rather than being scheduled for off peak times!

]]>