Particionamiento de tablas para archivar datos

Guión:

• dos bases de datos: DB_A y DB_Archive con una tabla muy grande llamada tablaA.
• todos los días, los registros de más de 60 días se eliminan de DB_A y se mueven a DB_Archive principalmente para dejar las cosas "separadas" porque la tabla A es muy consultada en DB_A para los registros de los últimos 2 meses.

Quiero deshacerme de este proceso porque es lento y consume muchos recursos. Estoy pensando en implementar el particionamiento de tablas en DB_A con una función de partición en una columna de fecha y almacenar todos los registros <2 meses en una partición y todos los registros> 2 meses en otra partición. Mis preguntas:

• ¿Se comportará este escenario como si tuviera 2 bases de datos diferentes? Si consulto en mi tabla A los registros> getdate () - 30, ¿va a leer la partición de archivo?
• Supuse que también tenía que particionar los índices, ¿verdad?
• ¿Cómo trato el hecho de que mañana mi función de partición "cambiará"? Quiero decir, si creo la función hoy (2 de julio, su rango será el 2 de mayo, pero mañana será el 3 de mayo). ¿Puedo crear una función de partición dinámica?

Con la partición, tendría que hacer una partición por día, lo que coloca el límite Pre-SQL 2012 de 1000 parcelas en una nueva perspectiva, ya que solo permitiría un archivo de 3 años. Con SQL Server 2012 obtienes 15000 particiones, lo que es suficiente para 1 partición por día.

Todos los días agregarías una nueva partición. Si desea mover la partición del día 61 pasado, puede hacerlo de manera eficiente, pero sigue siendo una operación fuera de línea. Consulte Mover una partición a un grupo de archivos diferente de manera eficiente .

Todos sus índices tendrían que estar alineados, consulte Pautas especiales para índices particionados .

Comprar en la partición no es una decisión fácil y puede ser un gran bocado para masticar ... vea Cómo decidir si debe usar la partición de tabla . Específicamente, no debe esperar mejoras de rendimiento de la partición. Debe abordar los problemas de rendimiento en seriest de tiempo agrupando por fecha y hora.

No sé si la función de partición puede ser dinámica, pero lo dudo. Algunas opciones para ti sin ir por esa ruta:

1 - Partición en la fecha del calendario y salir de la partición más antigua cada día

2 - Cree una vista que filtre la fecha y dirija todas sus consultas existentes allí (esto se puede administrar fácilmente cambiando el nombre de la tabla subyacente a otra y nombrando la vista como el nombre de la tabla actual). Esto también se puede optimizar con cambios de índice.

Tenga en cuenta que la primera opción anterior funcionará MUCHO mejor si utiliza el campo de fecha en sus consultas. Si no lo hace, seguirá siendo más rápido que el proceso actual, pero las consultas no tendrán una gran mejora. La partición en general funciona mejor si puede filtrar en su campo de partición y el optimizador sabe qué partición debe mirar.

Esto es lo que debería funcionar para usted: DB_A: tabla A con una partición diferente para cada uno de los últimos 60 días: tabla de etapas para mover datos de la partición más antigua

DB_Archive tableA: almacena todos los datos anteriores a 60 días. (no particionado)

Proceso: 1. antes del final del día: alterar la función de partición - dividir el rango para agregar una nueva partición para el nuevo día. (Nota: en lugar de crear particiones para "la fecha de hoy + 1 día", es posible que desee adelantarse algunos pasos, por ejemplo: "la fecha de hoy + 5 días"

1. Después del final de cada día, primero cambia la partición más antigua en DB_A.tableA a DB_A.stagingTable; Fusiona las particiones más antiguas.

2. Importe datos de DB_A.stagingTable a DB_Archive.tableA. Finalmente trunacte DB_A.stagingTable

Lo anterior se llama Rolling Window y es un escenario bastante común para los VLDB. Consulte este informe técnico de Microsoft sobre particionamiento: tabla de particiones e estrategias de índice o intente esto específicamente en el escenario de la ventana deslizante

Puede usar el enfoque dinámico de archivar y purgar datos en SQL Server. Por favor, siga el siguiente enlace para eso.

http://www.sqlscientist.com/2012/09/auto-maintain-archival-process.html