¿Cuáles son los pros y los contras de los scripts de Ola en comparación con el uso del plan de mantenimiento?

9

¿Podrían ayudarme a comprender las ventajas y desventajas de utilizar la solución de Ola sobre el plan de mantenimiento? He preparado una presentación basada en SQL Pass ( http://www.pass.org/DownloadFile.aspx?File=ebae1b31 ) que presentaré.

También estoy preparando algunos escenarios que la solución de Ola aborda y la solución del plan de mantenimiento no. ¿Pueden por favor ayudarme a explicar esto más técnicamente?

Por cierto, estamos gestionando más de 150 servidores (combinación de 2008/2012/2014/2016) con la solución de Ola en al menos el 75% de ellos. Me gustó este artículo de Brent Ozar. Pero en uno de los comentarios, Brent ha recomendado utilizar una solución basada en script para la cantidad de servidores que tenemos. https://www.brentozar.com/archive/2012/04/maintenance-plans-roombas-suck-good-way/

sql-server ola-hallengren

— Palmadita
fuente

¿Estamos hablando de copias de seguridad, mantenimiento de índices / estadísticas, verificación de corrupción o todo lo anterior?

— nkdbajoe

Todos ellos. Script de solución de mantenimiento completo de Ola. He resuelto problemas de reconstrucciones innecesarias de índices y actualizaciones de estadísticas en el plan de mantenimiento utilizando los scripts de Ola. Solo quería algo más de munición técnica de otros DBA por ahí. Gracias.

— Pat

2

Personalmente, creo que la mejor solución es una solución que cumpla con los requisitos de su negocio y su capacidad para resolverlo una vez que haya un error. La solución de Ola no es mala en general, pero todavía prefiero mi propia solución personalizada para mi entorno. Por ejemplo, para el mantenimiento del índice, quiero tener ejecuciones paralelas para ahorrar tiempo. La solución de Ola no funciona aquí. Quiero tener una actualización de estadísticas incrementales, la solución de Ola tampoco funciona aquí.

— jyao

¿Tienes algún dato que demuestre que son mejores o simplemente vas con lo que crees que es mejor? La mejor manera de resolver el problema es obtener algunos datos de rendimiento para poder mostrar por qué un método es mejor

— Joe W

Para el mantenimiento del índice, muchas veces el factor limitante es su SAN y subsistema de almacenamiento. Dependiendo de su configuración SAN, es posible que no vea ninguna mejora en las reconstrucciones paralelas.

— Alen

13

He escrito aqui

Los planes de mantenimiento no son malos, pero cuando su entorno crezca, la flexibilidad y funcionalidad limitadas que proporcionan los planes de mantenimiento no serán suficientes.

Para agregar más,

La solución de mantenimiento de Ola es ampliamente aceptada en la comunidad y las grandes organizaciones .
Su fuente abierta y los problemas se pueden plantear en github / issues con una probabilidad de solucionarlo muy rápido.
Es flexible y escalable (incluso si desea implementarlo en cientos de servidores, simplemente use Install-DbaMaintenanceSolution de dbatools).
Microsoft tardó casi una década en arreglar la GUI del plan de mantenimiento, que tenía errores :-)
tiene una amplia documentación y preguntas frecuentes, y se actualiza constantemente para adaptarse a las nuevas versiones del servidor sql.
en la versión de vista previa , incluso puede ejecutar copias de seguridad en paralelo.
para la solución de mantenimiento de índice, incluso puede cronometrar el proceso, por ejemplo, si se ejecuta más de X cantidad de tiempo, abortarlo.

— Kin Shah
fuente

5

Una de las principales ventajas de una solución basada en script es la facilidad de implementación, algo que es claramente relevante en su caso, ya que tiene más de 150 servidores. Intentar implementar varios planes de mantenimiento (es decir, al menos 2, uno para las bases de datos del sistema y otro para las bases de datos de usuarios) en 150 servidores sería una pesadilla. Mantenerlos una vez en su lugar es igual de complicado.

Una solución basada en script es mucho más fácil de implementar y mantener con el tiempo. Los guiones de Ola son bastante completos y cubren la mayoría de las necesidades. Representan un excelente punto de partida para que cualquier organización pueda modificarlo para que coincida con sus propios requisitos únicos.

En nuestro caso, tenemos alrededor de 40 instancias de SQL en nuestro entorno DEV, y utilizamos scripts Ola modificados con la función de conexiones múltiples de SSMS para poder implementar cambios en el régimen de mantenimiento en las 40 instancias con un solo clic. Cualquier caso especial es manejado por nuestras modificaciones.

— Miguel
fuente

3

No estoy 100% seguro de sus scripts, pero los scripts personalizados son mucho mejores que los planes de mantenimiento. Los planes integrados reconstruirán cada índice en una tabla, sin importar la poca fragmentación. Si tiene Always On, creará una tormenta de tráfico.

Scripts personalizados, puede reconstruir cualquier cosa por encima del 20% o cualquiera que sea su umbral. Menos índices reconstruidos a la vez. Menos datos siempre disponibles para enviar a las secundarias. Reconstrucción más rápida porque está reconstruyendo menos índices. Se requiere una ventana de mantenimiento más corta.

La última vez que usé planes de mantenimiento, tenía una tabla de 300 millones de filas y Always On estaría atrasado cada vez que se iniciaran las reconstrucciones de índices y se desbordaran los problemas con el registro de transacciones. Volví a los guiones y todo desapareció.

— Alen
fuente

1

Originalmente escribí el mío para SQL 2005 en 2007. Usé lo que los libros en línea tenían como base y lo cambié un poco. En aquel entonces parecía que la mayoría de la gente estaba usando los planes y ahora parece haberse revertido. Y antes de comenzar a hacer cosas de DBA, el DBA anterior que tenía antes tenía scripts personalizados para SQL 2000. Lo único que diferente fue que reconstruí todo. Fue más rápido reconstruir cualquier cosa por encima del 20% o 30% que reorganizar también. Para las copias de seguridad siempre hemos utilizado productos de terceros

— Alen,

1

Además de lo anterior, mi razón favorita es poder cambiar el tipo de copia de seguridad automáticamente para que una nueva base de datos tenga una copia de seguridad completa la primera vez que se ejecuta el trabajo de copia de seguridad de registro en lugar de esperar hasta que se ejecute el siguiente trabajo de copia de seguridad completa.

— SQLDBAWithABeard
fuente

0

Los planes de mantenimiento funcionarán bien la mayor parte del tiempo. Los guiones de Ola Hallengren funcionarán bien la mayor parte del tiempo.

En casos muy raros, es posible que tenga que cultivar el suyo.

Como dijo Jyao, se trata de con lo que te sientas más cómodo trabajando. Si su compañero de trabajo se siente más cómodo con los planes de mantenimiento, ¿por qué cambiar las bragas?

Si ha estado basado en datos durante más de 20 años, ya ha escrito sus propios scripts de mantenimiento. Justo cuando estabas aprendiendo a conducir, probablemente hubo un joven punk en pantalones cortos y chanclas de carga que apareció y dijo: "Oye, viejo tonto, los planes de mantenimiento son mejores, ¡y quítate los pantalones, te ves ridículo! ".

Luego, probablemente hubo una batalla de 4 años en la que el joven optimista se deslizó en un plan de mantenimiento cada vez que pudo. Ahora este otro joven punk con jeans ajustados y una corbata de moño le dice que regrese a los guiones. Es suficiente para volverte canoso.

Tres cosas a considerar:

¿Son estos ejemplos de superioridad Hallengrenita realmente aplicables a su entorno?

¿Te causará un problema real si usa planes de mantenimiento?

Si lo convence de usar los guiones de Hallengren y hay un problema, ¿podrá resolverlo él mismo o tendrá que llamarlo?

— James
fuente

Responda a las dos primeras preguntas Sí. Ya hemos visto problemas con los planes de mantenimiento y los resolví con la solución de Ola. También hubo una tarea de registro de contracción (??) en el servidor de producción que deshabilité de inmediato. Tercera pregunta, no lo sé. No estoy seguro de si podrá resolver los problemas creados por el Plan de mantenimiento en sí. Cuando le pregunté en caso de que veamos problemas, ¿qué debemos hacer? Su respuesta fue llamar al soporte de Microsoft. (??)

— Pat

@ Pat, ahh, parece que ha alcanzado su límite bajo el Principio de Peter. Tenga cuidado al intentar mejorarlo; no es probable que aprecie la ayuda.

— James