Diseño de base de datos SQL Server para datos "archivados pero disponibles"

Tenemos esta gran base de datos (> 1TB) que pretendemos "reducir". La base de datos gira en torno a una entidad principal, llamémosla "Visita". Para la discusión, digamos que es una base de datos para una práctica médica.

Hay un total de 30 "tipos" de visita, como procedimiento, anual, seguimiento, inmunización, etc. Cada uno de ellos es una tabla secundaria para "Visita", por ejemplo, "visit_immuno".

La base de datos ha acumulado unos 12 años de datos desde 2000. Alguien ha propuesto que mantengamos unos 3 años de datos en la versión "en vivo" y que el resto viva en una base de datos "old_data". La fecha SOLO se almacena en la tabla "Visita" ya que está normalizada. La tabla Visita también contiene una ROWVERSIONcolumna y una columna BIGINTde pseudoidentidad (agrupada). Para todos los efectos, supongamos que la clave de agrupación está poblada por una SECUENCIA (SQL Server 2012 Enterprise): la nombraremos cid.

El visit.dateno es siempre en el mismo orden que la clave de agrupación, por ejemplo, cuando un médico va en las visitas extendidas y regresa con su "maletín" de datos, que se combinó en la tabla principal. También hay algunos cambios a la tabla "visita" que hará que la ROWVERSIONcolumna que se va fuera de sincronía con los dos cidy datecolumnas - en pocas palabras, ni ROWVERSIONtampoco cidharían claves de partición adecuados para ello.

La regla empresarial para eliminar datos de la "vida" es que visit.datedebe ser mayor de 36 meses yvisit_payment debe existir un registro secundario . Además, la base de datos "old_data" no contiene ninguna de las tablas base, excepto visit%.

Entonces terminamos con:

Live DB (uso diario): todas las tablas DB de datos antiguos: datos anteriores para las visit%tablas

La propuesta requiere una base de datos combinada que sea un shell que contenga sinónimos para TODAS las tablas base en Live DB(exceptovisit% ) más Vistas que UNIONEN TODAS en las visit%tablas en las dos bases de datos.

Suponiendo que se crean los mismos índices en la base de Old-Datadatos, ¿las consultas funcionarán bien en las vistas UNION-ALL ? ¿Qué tipo de patrones de consulta podrían disparar el plan de ejecución para UNION-ALL? vistas ?

Por conveniencia, suponga que se llama a LiveDbla base de datos en vivo y se llama a la base de datos achiveArchiveDb

• Agregue una vista UNION ALL al LiveDbapuntar a las tablas en la ArchiveDbbase de datos a través de un sinónimo (no es necesario hacer un db combinado con sinónimos)
• "Particionar" visit.datey desnormalizar esta columna visit_paymentstambién si aún no está allí (esto mejora el rendimiento de la unión compartida)
• Solo archiva las dos tablas grandes si es posible (reduce la posibilidad de que se dispare el optimizador). Mantenga la vista UNION ALL y las otras tablas LiveDbpara que todas las uniones a las tablas más pequeñas se mantengan locales
• Agregue una restricción CHECK en las tablas en ambos LiveDby ArchiveDb eso describe el rango devisit.date contenido en la tabla. Esto ayuda al optimizador a eliminar la tabla de archivo de las búsquedas y escaneos que contienen la columna visit.data. Tendrá que actualizar periódicamente esta restricción.
• En la vista UNION ALL, agregue un criterio WHERE que se filtre en visit.data . Esto se suma a la sugerencia que ya proporcionó en la restricción de verificación. Esto maximiza la posibilidad de que los filtros se presionen
• Si tiene EE, particione la tabla en la base de datos de archivo (pero NO en la base de datos en vivo). Si desea ser realmente elegante, use la copia de seguridad / restauración a nivel de grupo de archivos de las bases de datos de archivo para ahorrar en tiempos de copia de seguridad.
• Considera poner AchiveDb en modo de recuperación SIMPLE si aún no lo está. No es probable que necesite copias de seguridad del registro de transacciones deArchiveDb
• Use INSERT ... WITH (TABLOCK) SELECT ... WITH (ROWLOCK) para forzar un registro mínimo en el destino al mover datos entre LiveDbyArchiveDb

Todo lo anterior no garantiza que el optimizador eliminará las tablas de archivo de las búsquedas y escaneos, pero lo hace más probable.

Cuando la eliminación no ocurre. Estos son los efectos que puede ver (esta lista puede estar incompleta). Para las búsquedas, obtendrá una búsqueda adicional en cada consulta (esto activa IOPS). Para los escaneos, los resultados pueden ser desastrosos para el rendimiento, ya que puede terminar escaneando tanto el archivo como las tablas en vivo. Estas son las formas típicas en que puede activar el optimizador:

• Si une las visit%tablas y no las incluye visit.dataen los criterios de unión (es por eso que desea desnormalizar). Debido a esto, es posible que desee modificar algunas de sus consultas
• Si obtiene una combinación hash entre visit.datay otra tabla (por ejemplo, una dimensión de fecha), es posible que no obtenga la eliminación correcta de tablas
• Si intenta agregar datos sobre las tablas archivadas
• Si filtra algo, PERO visit.data, por ejemplo, busque directamente en la tecla de la vista.

Para el último escenario, puede protegerse contra los peores efectos agregando otra restricción de verificación en el cid- si esto es posible. Usted mencionó que la secuencia de cid"no limpio" con respecto a las fechas y la progresión de las filas en la tabla. Sin embargo, ¿podría mantener una tabla que contenga la información: "No hay cidmás de este número desde este visit.data" o similar? Esto podría generar una restricción adicional.

Otra cosa a tener en cuenta es que las consultas paralelas pueden generar MUCHOS más hilos una vez que consulta la vista particionada (ya que ambas "sub-tablas" estarán expuestas a las mismas optimizaciones paralelas). Por esas razones, es posible que desee limitar MAXDOP en el servidor o las consultas que son paralelas.

Por cierto, si conoce bien las consultas, es posible que ni siquiera necesite los mismos índices en las dos bases de datos (esto supone que está 100% seguro de que obtendrá la eliminación correcta de tablas). Incluso podría considerar el uso de almacenes de columnas para ArchiveDb.

La forma en que lo hemos hecho es escribir los datos antiguos en lotes en una base de datos recién creada y eliminar los datos antiguos de db en vivo. De esa manera, ambos db son accesibles. También puede hacer una copia de seguridad de la base de datos recién creada y restaurarla en otro lugar para eliminar la gran huella de los servidores de producción. Espero que sea una solución aceptable para sus necesidades.