SQL Q & A: En búsqueda del rendimiento

  • Artículo

Reducir la carga de trabajo y funciones espejadas de suavizado es siempre una buena idea, pero la reducción de las bases de datos no es.

Paul S. Randal

Solución de carga de trabajo

P. Estoy trabajando con un equipo de desarrolladores que están cambiando una aplicación para utilizar SQL Server para el almacenamiento de datos. Los datos anteriormente se almacenan localmente en los equipos cliente. ¿Usted me puede dar una lista de consideraciones para los desarrolladores por lo que pueden conducir la cantidad menos posible de la carga de trabajo para SQL Server?

**R.**Por tratar de hacer la aplicación llamada hacia abajo a la capa de datos lo menos posible, está tomando un enfoque excelente. Centrarse en la aplicación es lamentablemente atípico. Lo principal a tener en cuenta es que la aplicación recuperar datos desde SQL Server lo menos posible. Cuando recuperan datos, tienen sólo recuperar los datos que necesita de forma más eficiente posible.

Aquí están algunas cosas para los desarrolladores a considerar sobre la manera en que la aplicación consulta de datos de SQL Server. Prestar atención a estos evitará la carga de trabajo innecesaria y el impacto negativo en la CPU, memoria y E/S:

  • ProcesandoPor los datos que tirar de SQL Server, la aplicación debe evitar procesar la una fila de datos a la vez. Esto es comúnmente llamado RBAR, o fila-por-agonizante-fila, procesamiento. Cualquier momento que SQL Server envía datos a la aplicación, tiene un hilo esperando reconocer los datos enviados a través de la aplicación. Procesamiento RBAR puede conducir a alta ASYNC_NETWORK_IO espera en SQL Server. La aplicación debe caché localmente los datos entrantes y responder rápidamente a SQL Server que tiene los datos.
  • **Filtrado:**La aplicación debe evitar filtrar datos localmente antes de usar o mostrar los datos. Es mucho más eficiente para empujar el predicado del filtro hacia abajo para SQL Server y tener la cantidad mínima de datos que devuelve a la aplicación. SQL Server es muy bueno para filtrar datos, dados los índices no agrupados derecho para apoyar los predicados de filtro.
  • **One Size Fits All (OSFA):**Minimizar la cantidad de columnas de la tabla se volvió a sólo los necesarios. Los desarrolladores también deben evitar tratando de construir un cuadro de diálogo "one size fits all". Utilizando una lista de selección de destino en lugar de seleccionar * reducirá la cantidad de datos que se procesan y regresó. Con menos columnas solicitadas, SQL Server también pueden tener más óptimas formas de llegar a estos datos, que podrían mejorar el rendimiento.
  • **Pedidos:**Si no necesitan los datos que se devuelven a ordenarse con un ORDER BY, entonces evitar especificar orden por como esto puede también cortar una operación de ordenación. Las operaciones de ordenación pueden ser caras porque terminan requiriendo un derrame de tipo costoso para tempdb.
  • **Por si acaso:**Posponer las operaciones selectos hasta que son realmente necesarios. Si una aplicación está emitiendo un SELECT por si acaso, el usuario hace clic en un botón de la aplicación. Entonces podría ser desperdiciada de procesamiento. Es mejor esperar hasta que realmente se pulsa el botón antes de emitir el seleccionar, quitar todos los tratamiento cuando no se pulsa el botón.
  • **Considerar el almacenamiento en caché:**Si está consultando una y otra vez los mismos datos, caché localmente y sólo emitir un nuevo SELECT cuando cambian los datos. Esto es ideal cuando los datos no cambian con frecuencia o si no necesita datos actualizados.

Teniendo en cuenta estos factores puede tener un profundo efecto en la cantidad de trabajo que SQL Server tiene que hacer, especialmente si un solo cambio en la lógica de aplicación consulta se multiplica por cientos o miles de instancias de la aplicación que se ejecute simultáneamente.

Pregunte a su equipo de desarrollo de aplicación para revisar cómo la aplicación está utilizando SQL Server. Esto podría beneficiarse enormemente su carga de trabajo existente. La causa de problemas de rendimiento con demasiada frecuencia se supone que SQL Server, en lugar de la forma que la aplicación está utilizando SQL Server.

Espejo, espejo

P. Hemos estado usando database mirroring desde hace varios años. Recientemente hemos tenido problemas. Se realiza una conmutación por error y la base de datos espejo tomó varias horas en línea, que fue bastante inesperado. ¿Existen los contadores de rendimiento que podemos monitorear para decir si esto volverá a ocurrir?

**R.**Database mirroring ha vuelto muy popular desde que se introdujo correctamente en SQL Server 2005 SP1. Sin embargo, hay un problema generalizado en los sistemas cliente. Parece que hay una suposición de que tan pronto como implementar la creación de reflejo de base de datos, pueda olvidarla y confían en él para trabajar perfectamente cuando se produce un error — traerá siempre protegido de base de datos en línea en el servidor espejo sin pérdida de datos y tiempo de inactividad mínimo.

Si bien esto puede ser cierto en algunos casos, es un supuesto peligroso. Para reducir el riesgo de desastres, es absolutamente esencial para controlar el tamaño de la cola el enviar y la reconstitución de una sesión de duplicación:

  • El tamaño de la cola de enviar muestra cuánto registro de transacciones se ha generado en el servidor principal, pero aún no ha sido enviado al servidor reflejado. Si no es cero, significa el estado espejado no esté sincronizado y no puede existir un failover automático. Además, el tamaño de la cola de envío indica la cantidad de pérdida de datos que se producirá si la base de datos principal sufre un desastre. Necesita controlar esto para asegurar el tamaño de la cola de envío no exceda la pérdida de datos permisible máximo acuerdo de nivel de servicio (SLA) — u objetivo de punto de recuperación (RPO) — para la base de datos que se espejan.
  • El tamaño de la cola de REHACER muestra cuánto registro de transacción existe en la base de datos espejo que aún no ha sido reproducido sobre la base de datos reflejada. Recuerde, sólo registros deban ser endurecido — no reproduce — en la unidad de registro de la base de datos de espejo. Se realiza como un proceso continuo en el servidor espejo. Si se produce un failover espejado, no puede acceder a la base de datos reflejada hasta que todos los registros de transacciones en la cola de REHACER han sido reproducidos en la base de datos reflejada. Esencialmente, esto significa que una recuperación de accidente tiene que ocurrir. Cuanto mayor sea la cola de REHACER, se llevará más tiempo una conmutación por error. Recuerde que en la edición Enterprise, entra en juego la recuperación rápida y la base de datos está disponible después de que ha completado la fase de reconstitución de la recuperación, pero antes el deshacer fase comienza. Necesita controlar esto para asegurar el tamaño de la cola de REHACER no exceda su downtime máximo permisible SLA — u objetivo de tiempo de recuperación (RTO) — para la base de datos que se espejan.

La transacción no enviada más antigua es otra forma de controlar la cantidad instantánea de pérdida de datos que sufriría en caso de un desastre de base de datos principal. Se aplica en todos los modos de creación de reflejo de base de datos, porque incluso si utiliza espejado sincrónico, el principal y el espejo pueden ser desconectados o usted puede pausar espejado.

Puede supervisar las colas enviar y REHACER usando al Monitor de reflejo de base de datos en SQL Server Management Studio para programar las alertas. También puede supervisar directamente mediante contadores los objeto perfmon Database Mirroring registro enviar cola KB y rehacer cola KB.

Si usted encuentra el tamaño de la cola de REHACER creciendo, esto implica que el servidor espejo no puede mantener la cantidad de registro enviado desde el servidor principal. Es posible que no hay carga de trabajo adicional en el servidor espejo que está impidiendo que el registro de base de datos de réplica reproduce tan rápido como sea posible. También puede ser que el hardware físico en el servidor espejo no es tan capaz como en el servidor principal.

Reducirla hasta

P. Uno de nuestros proveedores de aplicaciones es que obliga a que corremos consistencia regular de base de datos (DBCC) SHRINKDATABASE operaciones contra las bases de datos de aplicación y tempdb de control. El vendedor insiste en que esto es necesario para mantener un rendimiento adecuado. ¿Me puede dar algunos consejos?

**R.**Esta pregunta surge con bastante regularidad. Un proveedor de la aplicación podría negarse a que le permiten eliminar las operaciones regulares de encogimiento porque está considerados "necesarios para el funcionamiento". Reducción de bases de datos provoca la fragmentación del índice, consume muchos recursos de CPU y de la entrada-salida. También genera una gran cantidad de registro de transacciones. Esto puede causar problemas de base de datos espejado, grupos de disponibilidad AlwaysOn, replicación y cualquier otra cosa que tiene que enviar registros de alrededor. Hay algunas circunstancias, sin embargo, donde son necesarias operaciones puntuales de encogimiento.

Bases de datos no deben ser reducidas regularmente. Contracción regularmente las bases de datos es malo porque si la base de datos crece repetidamente después de ser reducido, todo lo que trabajo de encogimiento es esfuerzo totalmente inútil. Es semejante a tener reducción automática habilitada para la base de datos.

Muchos equipos de aplicación de proveedor no saben que estas cosas acerca de encogen. Esto es porque se ha portado la aplicación de otro sistema de base de datos y son reacios a escuchar a cualquiera que intente educarlos sobre el funcionamiento de SQL Server.

De vez en cuando voy a involucrados con un cliente y el equipo de proveedor de la aplicación. Las justificaciones del equipo del proveedor de aplicación suelen ser a lo largo de las líneas de las siguientes opciones (parafraseando):

  • Los índices en la base de datos ya están fragmentados, así reduciendo no hacerlo peor.
  • Nadie nunca se quejó de rendimiento antes, así que ¿por?
  • Tenemos que tener una contracción regular porque las operaciones causa la base de datos ampliar mucho y los clientes quieren su espacio en el disco nuevo.
  • Tenemos que tempdb del encogimiento debido a las operaciones de hacer crecer continuamente.

Ninguno de estos son razones válidas para contracción regularmente las bases de datos. De hecho, está documentado en artículo KB 307487 que reducción de tempdb cuando hay actividad de usuario puede provocar daños en tempdb. También, el "trabajando con Tempdb de SQL Server 2005" white paper (aplicable a todas las versiones) afirma que: "Reducción de archivos no es una práctica recomendada".

Cualquier momento que un proveedor reclama reducción es necesario, demuestra ya sea un malentendido fundamental de cómo debe administrar SQL Server o una deficiencia en el comportamiento de la aplicación cubiertos a través de la contracción regular. La mejor forma de colaborar con proveedores que mandato disminución regular es señalar el artículo de Microsoft KB o papel blanco. A continuación, puede argumentar que ellos están adheridas a las mejores prácticas de Microsoft.

Lamentablemente, no hay ninguna forma de prevenir las operaciones de contracción si están proveedor-mandato. Eliminación de la operación de reducción anula un acuerdo de soporte. Lo mejor que puedes hacer es tener un trabajo del Agente SQL Server que se ejecuta cada 15 segundos buscando las conexiones que se están reduciendo las bases de datos y luego matarlos. Matar a una operación de reducción no causa corrupción u otros problemas. Este enfoque puede ayudarle a mantenerse dentro del acuerdo de apoyo, mientras que también previene problemas de rendimiento en el servidor de producción.

Paul S. Randal

Paul S. Randal es el director gerente de SQLskills.com, un director regional de Microsoft y un MVP de SQL Server. Trabajó en el equipo de motor de almacenamiento de SQL Server en Microsoft desde 1999 a 2007. Escribió DBCC CHECKDB y reparación para SQL Server 2005 y fue responsable por el motor de almacenamiento de la base durante el desarrollo de SQL Server 2008. Randal es un experto en recuperación ante desastres, alta disponibilidad y mantenimiento de base de datos y es un presentador regular en conferencias en todo el mundo. Blogs de él en SQLskills.com/blogs/paul, y usted lo puede encontrar en Twitter en twitter.com/PaulRandal.

Contenido relacionado