Particionamiento en un solo grupo de archivos

Tengo algunas tablas muy grandes en mi base de datos, pero una parte sustancial de estos datos es "antigua".

Debido a circunstancias más allá de mi control, no estoy autorizado a eliminar estos datos "antiguos". La otra limitación es que no puedo modificar la base de datos, lo que significa agregarle grupos de archivos. Tal como están las cosas en este momento, todo reside en el PRIMARYgrupo de archivos.

Estaba pensando en dividir estas tablas en unas pocas particiones, como "nuevo", "antiguo", "archivado" y similares. Tengo una columna de "estado" que me gustaría utilizar para este propósito.

Dado el escenario y las limitaciones descritas, me preguntaba si la partición tiene algún sentido aquí. En otras palabras, si mi tabla está particionada de esta manera, pero todas las particiones se encuentran en el mismo grupo de archivos, SQL Server será lo suficientemente inteligente como para encontrar esa área especial en el archivo subyacente donde residen mis "nuevos" datos y no tocar el área con datos "antiguos"?

Para decirlo de otra manera, si, digamos, el 80% de mis datos son "viejos". ¿Tiene SQL Server un mecanismo para evitar acceder al 100% de los archivos subyacentes y acceder solo al 20% que contiene datos "nuevos" (suponiendo, por supuesto, que especifique mi columna de partición en la WHEREcláusula de las consultas).

Supongo que para responder esto, uno necesitaría entender cómo se implementa internamente la partición. Agradezco cualquier puntero.

Existen dos ventajas para particionar una tabla en el mismo grupo de archivos:

1. Permitir que partes de un índice grande se reconstruyan gradualmente, lo que permite un mantenimiento más eficiente. Revise el ALTER INDEX [foo] REBUILD PARTITION=npara más detalles.
2. Aprovechando la eliminación de particiones y (posiblemente) el bloqueo de nivel de partición para mejorar el mantenimiento de consultas. Discuto esto en mi blog .

Hay varias cosas a tener en cuenta si está particionando.

• Si su tabla tiene un índice agrupado (y realmente debería), su clave de partición debe ser parte del índice agrupado.
• Para evitar problemas de rendimiento, debe alinear sus particiones. Esto significa que todos sus índices deben incluir su clave de partición, ya sea como una inclusión o como parte del índice en sí.
• Las reconstrucciones de índice para particiones están fuera de línea en las versiones actuales de SQL Server (2005-2012). Si sus particiones son demasiado grandes y su reconstrucción por partición, esto podría conducir a problemas de bloqueo.

Recomiendo hacer una investigación exhaustiva sobre la partición antes de implementarlo. Kendra Little tiene una excelente lista de recursos donde puede comenzar.

La respuesta es sí". Tiene un mecanismo en cualquier consulta que filtra las entradas en función de la lógica utilizada para definir las particiones.

Sin embargo, debe tener el filtro adecuado o se escaneará toda la partición. Esto normalmente implicaría tener filtros de fecha (en su caso) para elegir la partición.

Una forma de aplicar esto es tener vistas que accedan solo a una partición, con la lógica correcta en la vista.