SQL Server - la Fusión de las tablas de gran tamaño sin bloqueo de los datos

Question

Tengo un conjunto muy grande de datos (~3 millones de registros) que necesita para combinarse con las actualizaciones y nuevos registros en un horario diario.Tengo un procedimiento almacenado que realmente rompe el récord establecido en 1000 registro trozos y se utiliza el MERGE comando con tablas temporales en un intento de evitar el bloqueo de la mesa, mientras los datos se están actualizando.El problema es que no se exactamente de ayuda.La tabla sigue "bloquea" y en nuestro sitio web que utiliza la información que recibe los tiempos de espera al intentar acceder a los datos.Incluso he intentado dividir en 100 grabar trozos e incluso trató de un WAITFOR DELAY '000:00:5' a ver si es de ayuda para hacer una pausa entre la fusión de los fragmentos.Es todavía muy débil.

Estoy buscando alguna sugerencia, mejores prácticas o ejemplos sobre cómo combinar grandes conjuntos de datos sin el bloqueo de las tablas.

Gracias

Answer 1

Cambiar su front-end para el uso NOLOCK o READ UNCOMMITTED, al hacer la selecciona.

Usted no puede NOLOCK de MEZCLA,INSERT o UPDATE, ya que los registros deben ser bloqueado con el fin de realizar la actualización.Sin embargo, usted puede NOLOCK la SELECCIONA.

Tenga en cuenta que debe utilizar con precaución.Si las lecturas están bien, entonces adelante.Sin embargo, si la lee requerir la actualización de datos, entonces usted necesita para ir por un camino diferente y averiguar exactamente por qué la fusión de 3M registros está causando un problema.

Yo estaría dispuesto a apostar que la mayoría del tiempo es dedicado a la lectura de datos desde el disco durante el comando combinar y/o de trabajo en torno a situaciones de memoria baja.Usted puede ser mejor simplemente relleno de más memoria ram en su servidor de base de datos.

Una cantidad ideal sería disponer de suficiente memoria ram para tirar toda la base de datos en memoria como sea necesario.Por ejemplo, si usted tiene una de 4 gb de la base de datos, a continuación, asegúrese de que tiene 8GB de RAM..en un servidor x64 de curso.

Answer 2

Me temo que he bastante la experiencia opuesta.Estamos realizando actualizaciones e inserciones en donde la fuente de la tabla, sólo una fracción del número de filas de la tabla de destino, que estaba en los millones.

Cuando combinamos la fuente de los registros de la tabla a través de toda la operativa de la ventana y, a continuación, se realiza la COMBINACIÓN de una vez, vimos a un 500% de aumento en el rendimiento.Mi explicación para esto es que usted está pagando por el frente el análisis de la COMBINACIÓN de comandos sólo una vez en lugar de una y otra vez en un bucle ajustado.

Además, estoy seguro de que la fusión de 1,6 millones de filas (fuente) en 7 millones de filas (destino), en contraposición a 400 filas en 7 millones de filas de más de 4.000 operaciones distintas (en nuestro caso) aprovecha las capacidades del motor de SQL server mucho mejor.De nuevo, una buena parte de la obra está en el análisis de los dos conjuntos de datos y esto se hace sólo una vez.

Otra pregunta que tengo que preguntar es así es si usted es consciente de que la COMBINACIÓN de comando realiza mucho mejor con índices en tanto las tablas de origen y destino?Me gustaría referirme a las siguientes link:

http://msdn.microsoft.com/en-us/library/cc879317(v=SQL.100).aspx

Answer 3

Desde la experiencia personal, el principal problema de MEZCLA es que desde que se hace la página de bloqueo que impide cualquier concurrencia en su Inserta dirigida a una tabla.Así que si van por este camino es fundamental que el lote todas las actualizaciones que se llegará a una tabla en un solo escritor.

Por ejemplo:tuvimos una tabla en la que INSERTAR tomó un loco 0,2 segundos por entrada, la mayor parte de este tiempo aparentemente se desperdicia en la transacción de enganche, así que nos cambiamos en el uso de COMBINACIÓN y algunas pruebas rápidas mostraron que nos permitió insertar 256 entradas en 0,4 segundos o incluso 512 en 0,5 segundos, hemos probado esta con los generadores de carga y todo parecía estar bien, hasta que llego a la producción y todo bloqueado al infierno en los bloqueos de página, lo que resulta en una mucho menor que el caudal total que el individuo se Inserta.

La solución no sólo era el lote de las entradas de un solo productor en una operación de COMBINACIÓN, sino también en lote, el lote de productores individuales DB en una sola operación de COMBINACIÓN a través de un nivel adicional de cola (anteriormente también una única conexión por DB, pero el uso de MARTE intercalar todos los productores de la llamada al procedimiento almacenado haciendo la COMBINACIÓN real de la transacción), de esta manera pudimos manejar muchos miles de Inserciones por segundo sin problema.

Tener el NOLOCK en todos los front-end lee es una necesidad absoluta, siempre.