Does anyone know of any documentation on the performance of partition
merge/split? Does the merge or split of a partition cause any locking
on the partitioned table? If you were merging or splitting a large
volume of data rebalancing your partitioned table would you
potentially lock users out?

Yes, performing partition maintenance during application operation can cause
blocking and perhaps deadlocks. Here's what the Books Online says:

<Excerpt
href="ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/tsqlref9/html/70866dac-0a8f-4235-8108-51547949ada4.htm">

ALTER PARTITION FUNCTION repartitions any tables and indexes that use the
function in a single atomic operation. However, this operation occurs
offline, and depending on the extent of repartitioning, may be
resource-intensive.

</Excerpt>

You mention rebalancing so I assume your goal is to distribute data roughly
evenly over multiple partitions so that you can more easily manage smaller
data subsets instead of one huge table. In that case, I would think you
would have a good idea of data distribution beforehand so you wouldn't need
to adjust partition boundaries. In general, partitioning changes should be
treated like schema changes and not done during normal operation.

Planning is important if you want to maximize partition maintenance
performance. For example, in a sliding window scenario one should plan
partitioning so that a SPLIT does not require data movement. SPLIT and
MERGE can be very fast, requiring only meta data changes. Conversely,
splitting a partition with a lot of data can be resource intensive and
reduce availability.

--
Hope this helps.

Dan Guzman
SQL Server MVP

<eavery@cdc.gov> wrote in message
news:1173381926.029740.307570@30g2000cwc.googlegro ups.com...
> Does anyone know of any documentation on the performance of partition
> merge/split? Does the merge or split of a partition cause any locking
> on the partitioned table? If you were merging or splitting a large
> volume of data rebalancing your partitioned table would you
> potentially lock users out?
>

I'm assuming that

"However, this operation occurs
offline, and depending on the extent of repartitioning, may be
resource-intensive. "

means that effected indexes/tables etc are locked until the
repartitioning is finished.
(Versus on-line which would allow users to proceed).

As far as the indexes go, it maybe cheaper to drop the index, change
the function, then re-create the index.