What if Microsoft Exchange Server had the built-in capability to keep a standby server online for disaster recovery? This server would be readily available if the primary Exchange server went down, and it could quickly open a new copy of the Exchange database with up-to-the-minute data intact. This idea is not that far-fetched and is known to database administrators as "log shipping."
Microsoft added the log-shipping feature to Microsoft SQL Server 2000 as an alternate disaster-recovery and availability option. Log shipping creates one or more database copies on a secondary server; to keep that server current, the primary database server copies transaction log files to the secondary server. In SQL Server 2000, this functionality lets database administrators keep warm copies of key databases (I use the term "warm" because "hot" implies transaction-level currency--something that log shipping can't fully deliver) in case the server that hosts the database is unavailable or experiences data loss.
So, why should Exchange administrators care whether this functionality is available in SQL Server? We should care because this leading-edge technology will be available in future Exchange versions. In 1998, I participated with Microsoft's Exchange development team in a proof-of-concept project in which we accomplished log-shipping functionality with Exchange Server 5.5. We used a simple Windows NT service to look at the Exchange transaction-log directory and to trigger when the system created new log-file generations. The system then copied the "closed" transaction log to another server running an Extensible Storage Engine (ESE) process that applied the log files to a copy of the Exchange database. Although I can't elaborate on the project, I can say that the proof of concept was successful: We recovered an Exchange database.
More important, the future of the Exchange database engine is related to the SQL Server engine. As I reported earlier this year, the Exchange JET/ESE developers are working as part of the SQL Server development team. The cross-pollination that is taking place as part of this joint effort has great implications for both products. Developers are combining must-have features in both products, such as page and log checksumming in ESE and log shipping in SQL, to create a better storage platform for the Microsoft .NET generation of products. Soon, we’ll all benefit from Microsoft's decision to combine these two database technologies. Although you might not be able to provide log shipping for Exchange today, I'm optimistic we'll see this functionality in future Exchange releases as the SQL/ESE synergy begins to pay off.
