Nuestro equipo de expertos pasados ciertos días de investigación y recopilar de información, encontramos los datos necesarios, queremos que resulte útil para ti en tu proyecto.
Solución:
He escrito aqui
Los planes de mantenimiento no son malos, pero cuando su entorno crece, la flexibilidad y la funcionalidad limitadas que brindan 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 en grandes organizaciones.
- Es de código abierto y los problemas se pueden plantear en github / issues con la posibilidad de que se solucione 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 versiones más nuevas 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 índices, incluso puede cronometrar el proceso, por ejemplo, si se ejecuta más de X cantidad de tiempo, abortarlo.
Una de las principales ventajas de una solución basada en scripts 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 los usuarios) en 150 servidores sería una pesadilla. Mantenerlos una vez en su lugar es igualmente complicado.
Una solución basada en scripts es mucho más fácil de implementar y mantener a lo largo del tiempo. Los guiones de Ola son bastante completos y cubren la mayoría de las necesidades. Representan un gran punto de partida para que cualquier organización pueda modificarlos para que coincidan con sus propios requisitos únicos.
En nuestro caso, tenemos alrededor de 40 instancias SQL en nuestro entorno DEV, y usamos 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. Los casos especiales son manejados por nuestras modificaciones.
No estoy 100% seguro de sus scripts, pero los scripts personalizados son mucho mejores que los planes de mantenimiento. Los planes integrados reconstruirán todos los índices de una tabla, sin importar la poca fragmentación. Si tiene Always On, creará una tormenta de tráfico.
Scripts personalizados que puede reconstruir cualquier cosa por encima del 20% o cualquiera que sea su umbral. Menos índices reconstruidos a la vez. Menos datos Always On para enviar a secundarios. Reconstrucción más rápida porque está reconstruyendo menos índices. Se requiere una ventana de mantenimiento más corta.
La última vez que utilicé planes de mantenimiento, tenía una tabla de 300 millones de filas y Always On estaría atrasado cada vez que comenzaban las reconstrucciones de índices y los problemas con el registro de transacciones se desbordaban. Volví a los guiones y todo desapareció.
valoraciones y comentarios
Recuerda que tienes concesión de comentar si diste con la solución.