Transformación efectiva de datos de una base de datos SQL a otra en un entorno en vivo

Question

Tenemos una situación de base de datos un poco desordenada.

Nuestro sistema de back-office principal está escrito en Visual Fox Pro con datos locales (¡sí, lo sé!)

Para trabajar eficazmente con los datos en nuestros sitios web, hemos optado por exportar datos regularmente a una base de datos SQL. Sin embargo, el proceso que hace esto básicamente borra las tablas cada vez y vuelve a insertarlas.

Esto significa que tenemos dos bases de datos SQL: una en la que escribe nuestro proceso de exportación de FoxPro y otra en la que nuestros sitios web leen.

Esta pregunta se refiere a la transformación de una base de datos SQL a la otra (SqlFoxProData - > SqlWebData).

Para una tabla en particular (una de nuestras tablas de aplicaciones principales), debido a que se producen varias transformaciones de datos durante este proceso, no se trata de declaraciones sencillas de ACTUALIZAR, INSERTAR y ELIMINAR usando autouniones, sino que tenemos que usar cursores en su lugar (¡Lo sé!)

Esto ha estado funcionando bien durante muchos meses, pero ahora estamos comenzando a encontrar problemas de rendimiento cuando se realiza una actualización (esto puede suceder regularmente durante el día)

Básicamente, cuando estamos actualizando SqlWebData.ImportantTable desde SqlFoxProData.ImportantTable, está ocasionando tiempos de espera de conexión / puntos muertos u otros problemas ocasionales en los sitios web en vivo.

He trabajado mucho para optimizar las consultas, el almacenamiento en caché, etc., pero he llegado a un punto en el que estoy buscando otra estrategia para actualizar los datos.

Una idea que se me ha ocurrido es tener dos copias de la tabla importante (A y B), algún concepto de qué tabla está actualmente 'activa', actualizar la tabla no activa y luego cambiar la tabla activa actual

es decir los sitios web leen desde ImportantTableA mientras estamos actualizando ImportanteTableB, luego cambiamos sitios web para leer desde ImportanteTableB.

La pregunta es, ¿es esto factible y una buena idea? He hecho algo así antes, pero no estoy convencido de que sea necesariamente bueno para la optimización / indexación, etc.

Cualquier sugerencia es bienvenida, sé que esta es una situación complicada ... y el objetivo a largo plazo sería lograr que nuestra aplicación FoxPro apunte a SQL.

(Estamos usando SQL 2005 si ayuda)

Debo agregar que la consistencia de los datos no es particularmente importante en la instancia, ya que los datos siempre están un poco desactualizados

Answer 1

Hay muchas maneras de desollar a este gato.

Primero atacaría los problemas de bloqueo. Es extremadamente raro que use CURSORES, y creo que mejorar el rendimiento y bloquear el comportamiento allí podría resolver muchos de sus problemas.

Espero resolverlo utilizando dos tablas de preparación separadas. Uno para la exportación de FoxPro en SQL y uno transformado en el formato final en SQL de lado a lado. Luego, ya sea intercambiando el final para la producción usando sp_rename, o simplemente usando 3 transacciones INSERT / UPDATE / DELETE para aplicar todos los cambios de la tabla final a la producción. De cualquier manera, habrá algún bloqueo allí, pero ¿de qué tamaño estamos hablando?

Answer 2

Debería poder mantener un db para el sitio web y simplemente replicar a esa tabla desde la otra tabla sql db.

Esto supone que no actualiza ningún dato del sitio web en sí.

Answer 3

" Para una tabla en particular (una de nuestras tablas de aplicaciones principales), debido a que varias transformaciones de datos tienen lugar durante este proceso, no es una declaración sencilla de ACTUALIZAR, INSERTAR y ELIMINAR usando autouniones, pero estamos tener que usar cursores en su lugar (¡lo sé!) "

No puedo pensar en un caso en el que necesite realizar una inserción, actualización o eliminación con un cursor. Si puede escribir la selección para el cursor, puede convertirla en una inserción, actualización o eliminación. Puede unirse a otras tablas en estas declaraciones y usar la declaración de caso para el procesamiento condicional. Tomarse el tiempo para hacer esto de una manera basada en un conjunto puede resolver su problema.

Una cosa que puede considerar si tiene muchos datos para mover. De vez en cuando creamos una vista de los datos que queremos y luego tenemos dos tablas: una activa y otra en la que se cargarán los datos. Cuando los datos se terminan de cargar, como parte de su proceso, ejecute un comando simple para cambiar la tabla que usa la vista a la que acaba de cargar. De esa manera, los usuarios solo están inactivos durante un par de segundos como máximo. No creará problemas de bloqueo cuando intenten acceder a los datos mientras carga.

También puede considerar el uso de SSIS para mover los datos.

Answer 4

¿Tiene la opción de hacer que las actualizaciones sean más atómicas, en lugar de la opción "borrar y volver a insertar"? Creo que Visual Fox Pro admite disparadores, ¿verdad? Para sus tablas de claves, ¿puede agregar un activador a la actualización / inserción / eliminación para capturar la ID de los registros que cambian y luego mover (o eliminar) solo esos registros?

¿O qué tal escribir todos los cambios en una base de datos fuera de línea y dejar que la replicación de SQL Server se encargue de la sincronización?

[lo siento, esto habría sido un comentario, ¡si tuviera suficiente reputación!]

Answer 5

Basado en su respuesta a Ernie arriba, usted preguntó cómo replicar bases de datos. Aquí está Instrucciones de Microsoft sobre la replicación en SQL2005.

Sin embargo, si está preguntando sobre la replicación y cómo hacerlo, me indica que tiene un poco de experiencia en el servidor SQL. Dicho esto, es bastante fácil estropear las cosas y, si bien estoy dispuesto a aprender por experiencia, si se trata de datos de misión crítica, es mejor que contrate a un DBA o, al menos, pruebe el # $ @ # $ % de esto antes de implementarlo realmente.