2012-01-30 7 views
5

Tengo una tabla CurrentStatus en mi base de datos (base de datos de suscripción en una duplicación de mezcla) Las columnas son StatusID {Primary Key + Clustered Index}, StatusName, StatusDate, UserID,CreatedDate, ModifiedDate, ModifiedBy, AllowDelete,AllowUpdatesimple consulta de actualización está tomando demasiado tiempo

CurrentStatus tabla como 26000 filas

actualizaciones y borrados en esta tabla son De repente, toma demasiado tiempo, por ejemplo, 1 minuto 30 segundos o incluso 5 minutos.

La consulta siguiente lleva más de un minuto en ejecutarse.

update StatusMaster set StatusName='OK' where StatusID = 22 

Había previamente 5 índices en la tabla (incluso entonces la consulta utilizada para ejecutar rápida). Ahora bien, como la actualización/consultas de eliminación no se están ejecutando, he eliminado todos los índices y se mantiene sólo dos índices 1) Índice agrupado en StatusID 2) Índice de replicación en la columna rowguid que es un índice único no agrupado creado por la replicación de forma automática.

Cuando realizo una copia de seguridad y restauro la base de datos, las consultas en la misma tabla funcionan bien.

Una cosa más es que tengo consultas complejas que se ejecutan cada 2 minutos desde alrededor de 20 máquinas en el servidor.

¿Qué causa que estas consultas consuman tanto tiempo para ejecutarse?

Click here for Execution plan

+0

es la replicación ejecutándose cuando realizó estas pruebas? Si el DB es un suscriptor, en realidad no debería eliminar \ actualizar sus datos, ¿verdad? – Diego

+0

No publique en MAYÚSCULAS. Es grosero, y parece que estás "gritando". –

+1

@Diego sí la replicación se está ejecutando + su duplicación de la fusión así que insertar la actualización puede funcionar en cualquiera de suscriptores y editores – Thakur

Respuesta

6

que recomendamos que actualice sus estadísticas a través del comando UPDATE STATISTICS, por ejemplo:

UPDATE STATISTICS StatusMaster 
+0

, esto ha ayudado a reducir el tiempo de ejecución pero aún tarda 20 segundos impares – Thakur

+0

a veces demora 1 segundo y, a veces, más de 15 segundos, el consumo de memoria en el servidor es de 2.5 gb de 4 gb y la utilización del procesador es del 45% – Thakur

+0

Es posible que la columna 'StatusID' tenga una cardinalidad baja, por lo que está haciendo una exploración de tabla. ¿Qué dice tu plan de ejecución? – RedFilter

2

Después de una gran cantidad de inserciones, eliminaciones, actualizaciones, etc., se puede obtener la tabla fragmentada y su los índices no pueden ser optimizados. Sugeriría que vuelvas a indexar y actualizar estadísticas.

Cuando realiza una copia de seguridad y la restaura, creo que está logrando lo mismo que haría el re-índice y la actualización de las estadísticas.

Probablemente deba programar un mantenimiento como este de forma recurrente para mantener el rendimiento.

+0

He reconstruido los índices y actualicé las estadísticas, pero aún estoy frente al problema – Thakur

0

La última vez cuando algunas consultas simples tomaron una cantidad anormal de tiempo [en nuestra pequeña empresa], esto fue causado por la corrupción de la matriz RAID en el servidor SQL [afortunadamente no productivo].

+0

¿cómo puedo encontrar si mi matriz RAID está dañada? – Thakur

+0

Pregunta a la persona que administra esa computadora, donde se encuentra el servidor SQL. Debe verificar los registros de eventos de Windows y, si están presentes, los registros de estado del controlador RAID. No digo que este sea su caso: no tengo experiencia con la replicación y no puedo decir qué efecto puede causar esto; Acabo de insinuar que a veces los retrasos extraños son causados ​​por problemas de hardware. – Arvo

+0

Como esta tabla está en replicación, y recibo errores en 4 a 5 servidores, no creo que sea un problema de RAID – Thakur

Cuestiones relacionadas