There have been some questions that have come to my attention concerning the concept of Scalable Shared Databases and comparing it within the context of Oracle RAC. If you want to read the SSD vs. Oracle RAC comparison, you can refer to the link Comparing SQL Server 2005 and Oracle RAC. As well, you can also refer to the SQL Server Books Online content on the subject of Scalable Shared Databases on the subject.
Saying this, the purpose of Scalable Shared Databases is to make use of SAN technology in order to allow you to attach a single read-only database to multiple server instances so that way you can have scale out many concurrent queries of your SQL database to the aforementioned multiple server instances. We have versions of this approach for Analysis Services one specific to using SANs (Scale-Out Querying with Analysis Services using SAN Snapshots) and one not specific to the use of SANs (Scale-Out Querying with Analysis Services). Saying this, you could always rename the concept of Scalable Shared Databases as Scale-Out Querying with SQL Server.
But I digress, extracted directly from the technical (hence most important) link is the Scalable Shared Databases are supported by SQL Server 2005 from Microsoft Support:
Scalable shared databases
Scalable shared databases let you attach a read-only reporting database to multiple server instances over a storage area network (SAN). A reporting database is a read-only database that is built from one or more production databases that are used exclusively for reporting purposes. To be made into a scalable shared database, a reporting database must reside on one or more dedicated read-only volumes. The primary purpose of these read-only volumes is to host the reporting database or a coordinated set of reporting databases. These volumes are known as reporting volumes.Benefits
Scalable shared databases offer the following benefits: • Provide workload scale-out of reporting databases by using commodity servers. A scalable shared database is a cost-effective way of making read-only data marts or data warehouses available to multiple server instances for reporting purposes, such as running queries or using SQL Server 2005 Reporting Services.
• Provide workload isolation. Each server uses its own memory, CPU, and tempdb database.
• Guarantee the same view of reporting data from all servers if all the server instances are configured identically. For example, all servers would use a single collation.Note Optionally, you can update the reporting database on a second reporting volume. For more information, see the "Maximize the availability of a scalable shared database" section.Restrictions
The following restrictions exist for a scalable shared database: • The database must be on a read-only volume.
• The data files can be accessed over an SAN.
• Scalable shared databases are supported only on Microsoft Windows Server 2003 Service Pack 1 (SP1) or a later version of Windows Server 2003.
For the technical details, please refer to Scalable Shared Databases are supported by SQL Server 2005
Denny Lee 