Despite all my love for SQL Server and Yukon(for it's BI features) I am frustrated by it less then optimal clustering features. Now,
since the launch of the SQL Server 2005 Yukon Beta 2 was yesterday, I don't want to be a party pooper or risk a future "red pill" offer.
But, historically Oracle and DB2 have been more advanced in high availability and I hoped that SQL Server would catch up on the clustering side. But even in it's 2005 incarnation it didn't. MySQL seems to have done it, albeit I don't have the details ready.
"My" sort of clustering would have meant a sort of load balancing, at least for read-only operations. Considering reporting or applications like .Text, where reads make up at least 95% of the total load. Probably more than 80% of applications do m ore than 80% of reads. That means that you could cluster 5 boxes in load balancing, of which 1 does the writing - CRUD stuff - and the other 4 do the reading. Of the 4 one could even do the admin stuff(index building, DBCC checking), so that the 1 is free of admin work. If the "writing" box failed, the cluster would just shift the "write" duty to a "read" box and/ot eventually shift the responsability of "admin" work onto another box.
Pretty simple really. One of the the many instances would hold a "write lock", the others a "read-only" lock. No need for super cmplex DLM (distributed lock management) on the database files, no need to duplicate database files, do partitioned views, implement shared disk or other quirky linked server stuff. Done cleanly it would be easy to switch the "write" capabilities off during forced or unforeseen maintainance, letting users view their data, but not modify. Design and testing would could also be done much easier. Downtime, patching would not be a problem on a live server anymore. Consolidation would even be a lot easier.
I blame the possessive DB instance not sharing the database files, nobody else.