2011-06-07 8 views
10

Tarda unos 5-10 minutos en actualizar una tabla de informes preparada. Queremos actualizar esta tabla constantemente (tal vez una vez cada 15 minutos o continuamente).¿Cómo reconstruyo periódicamente una tabla de informes a la que se accede con frecuencia?

Consultamos esta tabla de informes con mucha frecuencia (muchas veces por minuto) y no puedo mantenerla inactiva durante un período de tiempo prolongado. Está bien si los datos tienen 15 minutos de antigüedad.

No puedo soltar la tabla y volver a crearla. No puedo eliminar los contenidos de la tabla y volver a crearla.

¿Hay alguna técnica que deba usar, como intercambiar dos tablas (leer de una mientras construimos la otra) o poner este proceso de 5-10 minutos en una transacción grande?

+0

Cuando implementó su solución, ¿usó sp_getapplock? Y, si lo hiciste, ¿el sp_getapplock SÓLO incluía el DROP y CREATE de tus SYNONYM (s)? – mg1075

Respuesta

13

Use synonyms?. En la creación esto apunta a la tabla A.

CREATE SYNONYM ReportingTable FOR dbo.tableA; 

15 minutos más tarde se crea TableB y redefinir el sinónimo

DROP SYNONYM ReportingTable; 
CREATE SYNONYM ReportingTable FOR dbo.tableB; 

El sinónimo es simplemente un puntero a la tabla real: de esta manera el manejo de la tabla real renombra etc se simplifica y abstrae y todo el código/clientes usaría ReportingTable

Editar, 24 Nov 2011

sinónimos están disponibles en todas las ediciones: partitio n switching es Enterprise/Developer solamente.

edición, febrero de 2012

Puede cambiar las tablas enteras en edición estándar (tal vez Express, no probado)

ALTER TABLE .. SWITCH .. 

Esto sería más elegante que los sinónimos si la tabla de destino está vacía.

edición, febrero de 2012 (2)

Además, se puede girar a través de esquemas según Caching joined tables in SQL Server

+0

Si el sinónimo está constantemente en uso, ¿es posible recrearlo sin errores? ¿Requiere esto un mecanismo de reintento? –

+0

@Chris Simpson: el sinónimo no está en uso * per se *. DROP it y calls break: no bloqueará ni bloqueará nada. Envolver el DROP/CREATE en una transacción debería solucionarlo: sigue siendo más liviano que jugar con las tablas – gbn

+0

Eso es interesante. Entonces, DROP estaría permitido porque el sinónimo ya se resolvió en una tabla real en una consulta en ejecución. Tenía curiosidad sobre el ajuste de los cambios de esquema en las transacciones y encontré su respuesta a esta: http://stackoverflow.com/questions/4166989/alternate-synonym-in-sql-server-in-one-transaction, sería beneficioso. ¿aquí? –

0

Tener dos tablas parece la solución más simple.

+0

¿Y hay una forma fácil de cambiar entre ellos, o darse cuenta de cuál usar? Si tengo que modificar todas mis consultas de lectura para apuntar a dos tablas, esto parece muy extremo. – Jason

+0

Cambiaría el nombre de las tablas, dentro de una transacción. – MRAB

+0

los nombres de objeto aún deben ser únicos independientemente de la transacción – gbn

1

Sí, debe intercambiar tablas, y si no lo hizo, considere usar un servidor diferente u otra partición física para la tabla de informes.

El enfoque recomendado para los informes casi en tiempo real es descargar las lecturas del sistema operativo y separar la actividad de escritura de la actividad de lectura en el sistema de informes.

Has hecho la primera parte, al menos lógicamente, al tener una tabla preparada. El intercambio entre una tabla de solo lectura para los usuarios y una tabla separada para las actualizaciones elimina los conflictos de escritura y lectura entre las transacciones. El costo es la latencia del caché para los usuarios, pero si es necesario, debería ser posible realizar los pasos necesarios para minimizar el tiempo de preparación y cambiar las tablas con mayor frecuencia.

Para obtener más información sobre opciones de diseño en informes en tiempo real, recomiendo un documento bien escrito por Wayne Eckerson, Best Practices in Operational BI.

0

En nuestro proyecto, se utilizaron dos tablas y crear/alterar la visión de cambiar.

Cuestiones relacionadas