Actualmente nos encontramos con algunos problemas de rendimiento ya que nuestra base de datos se está volviendo demasiado grande. Hay datos almacenados de los últimos 10 años y no veo una razón por la cual los datos de más de 2 años deban almacenarse en las mismas tablas que los datos nuevos.

Ahora que no tengo una experiencia muy profunda en la administración de bases de datos, estoy buscando las mejores formas de archivar datos antiguos.

Informacion

• Hay alrededor de 310'000'000 registros en la base de datos en total.

• La base de datos necesita 250 GB en el disco duro.

• La versión del servidor es SQL Server 2008 con nivel de compatibilidad SQL Server 2005 (90), pero estamos planeando actualizar a SQL Server 2012 pronto

He pensado en dos posibilidades:

Nueva base de datos

Cree una base de datos similar a la del servidor de producción e inserte todos los datos antiguos en la nueva base de datos.

• Desventaja: dado que los servidores vinculados no están permitidos en nuestro entorno, sería difícil unir los datos antiguos si fuera necesario

Esquema de historia

Cree un nuevo esquema fe [hist] con las mismas tablas que en la base de datos de producción. Inserte todos los datos antiguos en estas nuevas tablas en el nuevo esquema.

• Ventaja: fácil unión, si se necesitaran datos antiguos en el futuro

• ¿Prefieres una de las soluciones sobre la otra?
  • ¿Por qué?
• ¿Hay mejores posibilidades?
• ¿Existen herramientas existentes con las cuales esta tarea es fácilmente posible?
• ¿Alguna otra idea?

Gracias por adelantado

Editar

Pregunta adicional:

¿La tabla de archivo recién creada también necesitaría claves primarias / externas?

¿O deberían tener las columnas pero sin claves / restricciones?

Creo que la respuesta a muchas de sus preguntas es que depende. ¿Qué problemas de rendimiento tienes? Parece inusual que una base de datos tenga problemas de rendimiento solo por crecer a 250 GB de tamaño.

¿Quizás sus consultas están realizando escaneos de tablas en toda la tabla de hechos incluso cuando solo se necesita una pequeña porción (por ejemplo, el último año) del rango de fechas? Si hay una consulta en particular que es más importante para optimizar, considere publicar su esquema, consulta y un plan de ejecución real en otra pregunta para ver si se puede optimizar.

¿Prefieres una de las soluciones sobre la otra?

Generalmente prefiero la base de datos de historia, y creo que Guy describe buenas razones para esto en su respuesta .

La principal desventaja que veo para una base de datos de historial (a diferencia de un esquema) es que ya no puede usar claves externas para su tabla de archivo. Esto puede estar bien para usted, pero es algo a tener en cuenta.

La desventaja que enumeró para este enfoque no es precisa; podrá realizar consultas a través de bases de datos en el mismo servidor fácilmente y el optimizador de consultas generalmente maneja muy bien las consultas entre bases de datos.

¿Hay mejores posibilidades?

Si necesita consultar los datos de archivo regularmente, podría considerar la partición de la tabla por fecha . Sin embargo, este es un gran cambio que puede tener muchas implicaciones de rendimiento, tanto positivas (p. Ej., Eliminación de particiones, carga de datos más eficiente) como negativas (p. Ej., Búsquedas individuales más lentas, mayor potencial de sesgo de hilo en consultas paralelas). Por lo tanto, no tomaría esta decisión a la ligera si se trata de una base de datos muy utilizada.

¿La tabla de archivo recién creada también necesitaría claves primarias / externas? ¿O deberían tener las columnas pero sin claves / restricciones?

Recomendaría tener al menos la clave primaria y los índices únicos para que pueda obtener los beneficios de integridad de datos que proporcionan. Por ejemplo, esto evitará que inserte accidentalmente un año de datos en la tabla de historial dos veces. Y como beneficio adicional, puede mejorar el rendimiento si necesita consultar la tabla de historial.

¿Alguna otra idea?

Dado que está utilizando la edición Enterprise y planea actualizar a SQL 2008+, puede considerar la compresión de datos para esta tabla. La compresión ciertamente reducirá el espacio en el disco, pero dependiendo del disco de su servidor y los recursos de la CPU también puede mejorar el rendimiento de las consultas para las lecturas al reducir la E / S del disco y mejorar la utilización de la memoria (se ajustan más datos en la memoria caché a la vez).

Preferiría tener un esquema histórico o una segunda base de datos histórica sobre un servidor vinculado cualquier día. Ahorra costos de licencia, es más fácil de administrar y consultar. Luego, también puede usar un esquema más simple y soltar algunos de los índices haciendo que la base de datos sea más pequeña

Pero dado que tiene la edición Enterprise, tiene la tercera opción, que es dividir sus tablas , lo que, cuando se implementa, hace que sea más fácil archivar los datos y consultar los datos antiguos es transparente para sus usuarios y no necesitará realizar cambios en la aplicación .

En mi experiencia, una segunda base de datos sería la opción preferida por dos razones.

1. Puede restaurar los datos de una copia de seguridad histórica y luego eliminar las tablas e índices que no necesita.
2. Puede mover esto a un servidor diferente para fines de informes, esto tiene los beneficios de no usar los recursos del servidor primario

Aún necesitaría eliminar todos los datos históricos de la base de datos primaria, pero esto podría programarse en.

Ignorando la licencia por ahora, ya que no es donde paso mi tiempo.

En mi humilde opinión, la base de datos de archivo es más sencilla de implementar y mantener. Son entidades distintas, poco acopladas. El movimiento de datos y los controles de carga / recursos tienen límites claros. Puede pasar fácilmente a una instancia o servidor diferente para una mejor gestión del rendimiento y el costo no es un problema importante. Tenga en cuenta que más simple! = Más barato o menos esfuerzo. En realidad, tiene muchas más tareas, pero todas son tareas simples con dos excepciones importantes:

1. aplicación de restricciones: no existen restricciones de bases de datos cruzadas en SQL Server, por lo que debe decidir si eso es un factor decisivo.
2. las consultas cruzadas de bases de datos utilizan consultas distribuidas que aún dependen de OLEDB, que está en desuso. Eso significa que puede encontrar problemas con los nuevos tipos de datos y, si tiene problemas de rendimiento, es poco probable que se solucionen

El esquema de archivo o simplemente la tabla de archivo es un poco más complejo de implementar pero mucho más fácil de usar. Todos los objetos en la misma base de datos significa que no tiene que replicar y mantener controles de acceso. Sin consultas cruzadas de bases de datos, lo que facilita el ajuste del rendimiento, la supervisión, la resolución de problemas, etc.

El particionamiento de tablas es una gran solución y ofrece muchos de los beneficios de una tabla / esquema de archivo, pero proporciona transparencia a los usuarios / consultas. Dicho esto, es el más complejo de implementar y requiere atención continua que no es fácil para un principiante.

Algunas consideraciones importantes:

• ¿Las consultas devuelven datos históricos / en frío regularmente o se accede con poca frecuencia a los datos en frío?
• ¿Los datos históricos son inmutables o se actualizan / eliminan regularmente?
• 310m de filas es "moderada" (suponiendo que todo en 1 tabla) depende del tamaño de la fila. ¿Tiene datos de tamaño de fila? ¿Cuántos GB son esa fila de 310m?
• ¿Cuál es la tasa de crecimiento de esa tabla?
• ¿Puede modificar el código de la aplicación y sus consultas SQL?

Estas son consideraciones importantes ya que pueden tener un impacto significativo en la solución que elija o incluso pueden no permitir ciertas soluciones. Por ejemplo, si sus datos históricos se modifican / actualizan regularmente (más de una vez por semana), el uso de una base de datos separada significa que debe usar DTC para esas consultas o administrar manualmente la seguridad de las transacciones (no es trivial para garantizar que siempre sea correcta). El costo es significativamente mayor que los datos históricos inmutables.

Además, si está pensando en actualizar, considere 2016 y la nueva función Stretch Database: https://msdn.microsoft.com/en-us/library/dn935011.aspx

Preferiría dividir la base de datos en una base de datos lógica separada por las siguientes razones:

1. Requisitos de recursos

Al dividir esto en una base de datos separada, puede almacenarse en un disco diferente y monitorearse a una velocidad diferente a los datos de producción principales.

2. Rendimiento

Al dividir los datos en una base de datos separada, la base de datos de producción principal se reduce en tamaño, lo que ayuda al rendimiento general.

3. Copias de seguridad más simples

La copia de seguridad de los datos archivados puede no considerarse tan esencial como los registros "en vivo / actuales" en la base de datos SQL principal. Esto puede significar que los datos archivados podrían ser respaldados con menos frecuencia. También debido a la naturaleza secuencial de cómo se registran los datos archivados, es posible hacer copias de seguridad de secciones de la base de datos archivadas una vez y luego nunca más. Por ejemplo, una vez que los datos de archivo se escriben en la base de datos de archivos de cambio para 2014, nunca más habrá ningún cambio en esos datos.

Nota: Creo que la respuesta a muchas de sus preguntas depende de sus circunstancias, la naturaleza de los datos y los problemas de rendimiento que estaba teniendo.