SQL Server 2008 - Particionamiento e índices agrupados

Así que permítanme comenzar diciendo que no tengo control total sobre mi diseño de base de datos, por lo que muchos de los aspectos del sistema actual no se pueden cambiar para los propósitos de este escenario.

Los comentarios sobre cómo deberíamos repensar aspectos del diseño son probablemente correctos pero inútiles :)

Tengo una tabla muy grande, de aproximadamente 150 campos de ancho y aproximadamente 600m de filas, que impulsa una gran cantidad de procesos. Esto está en una situación de depósito de datos, por lo que no tenemos NINGUNA actualización / inserción fuera del proceso de carga programado, por lo que está muy indexado.

Se tomó la decisión de intentar particionar esta tabla, y tengo algunas preocupaciones sobre la indexación de una tabla particionada. No tengo ninguna experiencia con la partición, por lo que se agradece cualquier entrada o enlace. No pude localizar específicamente lo que busco en BOL o msdn.

Actualmente nos agrupamos en un campo que llamaremos IncidentKeyque es varchar(50)único y no único: podríamos tener entre 1 y 100 registros con el mismo IK(sin comentarios, por favor). A menudo obtenemos nuevos datos en IncidentKeyregistros antiguos , por lo que tampoco son secuenciales.

Entiendo que necesito incluir mi campo de partición IncidentDate, en mi clave de índice agrupada para que la partición funcione correctamente. Estoy pensando que lo sería IncidentKey, IncidentDate.

La pregunta es, ¿cómo funcionará la mecánica de un índice agrupado en una clave de 2 partes en una tabla particionada, si un registro en una partición "nueva" debe estar antes de un registro en una partición "antigua" en el índice agrupado?

Por ejemplo, tengo 5 registros:

IncidentKey    Date

ABC123        1/1/2010
ABC123        7/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010
XYZ999        7/1/2010

Si obtengo un nuevo registro ABC123, 2/1/2011, deberá estar en el índice agrupado ANTES XYZ999, 1/1/2010 . ¿Como funciona esto?

Asumo fragmentación y punteros, pero no puedo encontrar ninguna información sobre el almacenamiento físico y la configuración de índices agrupados no particionados en tablas particionadas con claves de dos partes.

Una tabla particionada es realmente más como una colección de tablas individuales unidas. Entonces, en su ejemplo de agrupación por IncidentKeyy partición por IncidentDate, digamos que la función de partición divide las tablas en dos particiones para que 1/1/2010 esté en la partición 1 y 7/1/2010 sea la partición dos. Los datos se distribuirán en el disco como:

Partition 1:
IncidentKey    Date
ABC123        1/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010

Partition 2:
IncidentKey    Date
ABC123        7/1/2010
XYZ999        7/1/2010

En un nivel bajo, realmente hay dos conjuntos de filas distintos. Es el procesador de consultas que da la ilusión de una sola tabla al crear planes que buscan, escanean y actualizan todos los conjuntos de filas juntos, como uno solo.

Cualquier fila en cualquier índice no agrupado tendrá la clave de índice agrupado a la que corresponde, por ejemplo ABC123,7/1/2010. Dado que la clave de índice agrupado siempre contiene la columna de clave de partición, el motor siempre sabrá en qué partición (conjunto de filas) del índice agrupado buscar este valor (en este caso, en la partición 2).

Ahora, siempre que se trate de particiones, debe considerar si sus índices NC estarán alineados (el índice NC está particionado exactamente igual que el índice agrupado) o no alineado (el índice NC no está particionado o está particionado de manera diferente del índice agrupado) . Los índices no alineados son más flexibles, pero tienen algunos inconvenientes:

• los índices no alineados requieren grandes cantidades de memoria para ciertos planes de consulta
• índices no alineados evitan operaciones eficientes de cambio de partición

El uso de índices alineados resuelve estos problemas, pero trae su propio conjunto de problemas, porque esta opción de diseño físico de almacenamiento se ondula en el modelo de datos:

• los índices alineados significan que las restricciones únicas ya no se pueden crear / aplicar (a excepción de la columna de partición)
• todas las claves foráneas que hacen referencia a la tabla particionada deben incluir la clave de partición en la relación (ya que la clave de partición está, debido a la alineación, en cada índice), y esto a su vez requiere que todas las tablas que hacen referencia a la tabla particionada contengan un valor de columna de clave de partición. Piense en Orders-> OrderDetails, si las órdenes tienen OrderID pero están particionadas por OrderDate, OrderDetails debe contener no solo OrderID, sino también OrderDate, para declarar adecuadamente la restricción de clave externa.

Estos efectos que encontré rara vez se mencionaron al comienzo de un proyecto que implementa particiones, pero existen y tienen graves consecuencias.

Si cree que los índices alineados son un caso raro o extremo, considere esto: en muchos casos, la piedra angular de las soluciones de particionamiento y ETL es el cambio rápido de las tablas de preparación. Las operaciones de cambio requieren índices alineados.

Ah, una cosa más: todo mi argumento sobre las claves externas y el efecto dominó de agregar el valor de la columna de partición a otras tablas se aplica igualmente a las combinaciones .

Cuando un índice agrupado tiene múltiples particiones, cada partición tiene una estructura de árbol B que contiene los datos para esa partición específica. Por ejemplo, si un índice agrupado tiene cuatro particiones, hay cuatro estructuras de árbol B; uno en cada partición. Árbitro. Estructuras de índice agrupadas

Pautas especiales para índices particionados

Puede reconstruir particiones específicas de un índice particionado.

p.ej

ALTER INDEX IX_TransactionHistory_TransactionDate
ON Production.TransactionHistory
REBUILD Partition = 5;
GO