As most of you know, Exchange servers utilize the Extensible Storage Engine (ESE) database. As you have told us loud and clear, Exchange rocks from a performance, scalability, and availability stan...
Published Jul 16, 2009
Version 1.0
Blog Post
Some of the arguments here are very disappointing. Why would someone even consider moving Exchange to an SQL Server back-end? It works fine on the current ESE database and I would leave it at that.
Exchange in itself is by no means a complex product - in the same way Active Directory or indeed SQL Server is not complicated. Most people simply don't have the experience in configuring it - which in itself makes things hard to understand and particularly complex. The Exchange team have made things much easier in Exchange 2007 (admittedly some things need improving - like all software written to stringent deadlines) and I have no doubt they will continue to improve matters in 2010 - the removal of storage groups is a bonus, for example. Trying to move the product to an SQL Server back-end will, in my opinion, simply add complexity to a product which many people don't fully understand.
I agree with the previous poster who went into detail about how the ESE engine is written for Exchange. If we moved to an SQL back-end, who would be coding the database software? The SQL Server team. Who would be making Exchange work with this database product? The Exchange team. How would this removal of the ability to make changes to the database structure impact the product? Lots. How much harder would development be? A lot. How will prices be affected? They're go up.
Don't get me wrong - SQL Server is a great product with great uses. If you want to run database-integrated applications, great. But when you have a product as big as - if not bigger - than SQL Server which could potentially be put into an SQL Server database, it is too much dependency - more than I would like.
The comment regarding ease of backup and restore from SQL Server has no basis to it. Like a previous poster our backup team have deployed Backup Exec 12.5 - and have NEVER had a problem with using GRT to recover data. It is quick and easy. However, an SQL Server DBA should not be charged with backing up Exchange data - either a trained backup admin or an Exchange admin should be doing so. Without any knowledge of Exchange it becomes very difficult to configure a good, working backup - and to restore if disaster strikes.
I love Exchange and would never move away from it, but I would rather see development time go into adding new features - improving the functionality of the Management Console, for example, or improving clustering and co-existence with legacy systems without massive hardware/software investments being necessary (a big problem with 2010) - rather than trying to make an already excellent product work with an as-yet untested database platform.
Exchange in itself is by no means a complex product - in the same way Active Directory or indeed SQL Server is not complicated. Most people simply don't have the experience in configuring it - which in itself makes things hard to understand and particularly complex. The Exchange team have made things much easier in Exchange 2007 (admittedly some things need improving - like all software written to stringent deadlines) and I have no doubt they will continue to improve matters in 2010 - the removal of storage groups is a bonus, for example. Trying to move the product to an SQL Server back-end will, in my opinion, simply add complexity to a product which many people don't fully understand.
I agree with the previous poster who went into detail about how the ESE engine is written for Exchange. If we moved to an SQL back-end, who would be coding the database software? The SQL Server team. Who would be making Exchange work with this database product? The Exchange team. How would this removal of the ability to make changes to the database structure impact the product? Lots. How much harder would development be? A lot. How will prices be affected? They're go up.
Don't get me wrong - SQL Server is a great product with great uses. If you want to run database-integrated applications, great. But when you have a product as big as - if not bigger - than SQL Server which could potentially be put into an SQL Server database, it is too much dependency - more than I would like.
The comment regarding ease of backup and restore from SQL Server has no basis to it. Like a previous poster our backup team have deployed Backup Exec 12.5 - and have NEVER had a problem with using GRT to recover data. It is quick and easy. However, an SQL Server DBA should not be charged with backing up Exchange data - either a trained backup admin or an Exchange admin should be doing so. Without any knowledge of Exchange it becomes very difficult to configure a good, working backup - and to restore if disaster strikes.
I love Exchange and would never move away from it, but I would rather see development time go into adding new features - improving the functionality of the Management Console, for example, or improving clustering and co-existence with legacy systems without massive hardware/software investments being necessary (a big problem with 2010) - rather than trying to make an already excellent product work with an as-yet untested database platform.