Particionamiento de tablas para archivar datos

13

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?
Diego
fuente
No creo que una función dinámica sea una buena idea, incluso si estuviera permitida (no lo creo) ... podemos entrar en más detalles en breve, pero creo que probablemente debería particionar según la fecha del calendario y alejarse una partición a la vez ... Pero hay una variedad de opciones aquí.
JNK
Escribí un ejemplo en la línea de lo que quieres hacer el año pasado. Fue un caso algo especial en el que queríamos mantener x días de datos en una matriz rápida (costosa) y mover los datos de archivo a un almacenamiento más barato. Si puedo desinfectar un script de ejemplo, lo publicaré, de lo contrario, será solo un resumen del proceso.
Mark Storey-Smith
hola marca, sí, por favor, y si puedes compartir tu experiencia también. fue exitoso?
Diego
Funciona, pero finalmente fue innecesario (tomamos una ruta más simple). ¿Quizás podría ampliar por qué existe el límite de 60 días en su caso? Ayudaría a todos a orientarte en la dirección correcta.
Mark Storey-Smith

Respuestas:

6

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.

Remus Rusanu
fuente
El nuevo límite está disponible en 2008 SP2 y 2008 R2 SP1. blogs.msdn.com/b/hanspo/archive/2010/11/29/…
Jon Seigel
@ Jon: la implementación en 2008 SP2, 2008R2 SP1 viene con una gran advertencia . As explained in this white paper, there are implications on certain features, including performance. . El soporte de SQL 2012 viene sin advertencias.
Remus Rusanu
Gracias por señalar eso; Es cierto que hay algunas advertencias para usarlo en 2008/2008 R2, pero es una opción disponible si es necesario.
Jon Seigel
Gracias por tu comentario. Leeré el comentario material más adelante
Diego
2

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.

JNK
fuente
Me gustaría evitar las operaciones manuales "cada día"
Diego
2

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

Dharmendar Kumar 'DK'
fuente
0

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

Asif Ghanchi
fuente
1
¿Podría incluir en su respuesta los puntos principales de esa publicación? Ya sabes, los enlaces van y vienen y cuando se van, tu publicación solo tendrá un enlace muerto.
dezso