No Change for Distributed Partitioning

Partitioned tables are strictly for local partitioning, breaking up a database on a single server to reduce the impact of maintenance operations and improve query performance. For distributed partitioning, which spreads load across multiple servers, administrators and architects must still use a mechanism called distributed partitioned views, which was introduced in SQL Server 2000. To use this mechanism, administrators create independent base tables on multiple servers. They then create a view that spans the separate tables. The view shields users and developers from the implementation details of the base tables (such as the names of those tables and how table data are distributed among them), effectively providing an alias for the underlying base tables.

However, maintenance of distributed partitioning schemes is tricky and laborious. Administrators carry out maintenance on the individual base tables, rather than performing a single operation on the view. To change the partitioning scheme (for example, to go from two to three servers), administrators must create new tables, manually move data, and update the definition of the view spanning the distributed tables, among other operations. Furthermore, distributed partitioning schemes generally yield performance gains only for certain types of applications, such as applications whose queries typically access data on a single partition.