Listas de verificación de SQL Server

14

Siguiendo con mi otra pregunta , me gustaría comenzar a pensar en lo que debería analizar a diario / semanalmente / mensualmente en términos de alertas. Espero poder ver los problemas antes de que sucedan (ese es el plan) ...

Hasta ahora, he comenzado a recopilar scripts para lo siguiente (sin orden):

Diario

  • Verifique el tiempo de actividad del sistema (en caso de que necesite verificar algo como DBA)
  • Verifica la última copia de seguridad
  • Verifique las copias de seguridad del registro de transacciones
  • Verifique el estado de los trabajos SQL
  • Verifique el uso promedio de la CPU durante las últimas 24 horas (o 1140 minutos)

Semanal

  • Verifique el historial de copia de seguridad de MSDB
  • Compruebe para ver cuándo se ejecutó CheckDB la última vez
  • Comprobar la fragmentación del índice
  • Verifique las estadísticas del índice (lecturas vs escrituras, etc.)
  • Verifique los cuellos de botella de IO

Mensual

  • Verificar índices faltantes
  • Verifique los índices que ya no se usan

¿Cualquier otra sugerencia? (Soy nuevo en DBA, por lo que cualquier ayuda / consejo siempre es bienvenido)

sql-server-2008 sql-server-2005 maintenance Stuart Blackler
fuente

Respuestas:

3

  1. Copias de seguridad

    • Verificar correos electrónicos de respaldo
    • Cuánto tiempo tardó en ejecutarse la copia de seguridad (duración de la copia de seguridad de la base de datos)
    • Verifique que todas las bases de datos estén siendo respaldadas de acuerdo con un plan de mantenimiento

  2. Espacio libre en disco. Tenga en cuenta las variaciones significativas de la verificación anterior. Los archivos de registro pueden verse afectados dramáticamente por trabajos mensuales

  3. Fracasos laborales. Filtrar la actividad laboral por fallas

  4. Verificaciones del sistema. Busque en los registros de sql cualquier error crítico.

    • Registros de aplicación

  5. Actuación

    • Verifique las estadísticas de rendimiento en todos los servidores
    • Verifique que los contadores estén en el rango normal en todos los servidores de producción

  6. Conectividad

    • Verifique que la aplicación del cliente pueda obtener datos de la base de datos
    • Verifique la velocidad aceptable de acceso a los datos

  7. Replicación. Verifique que cada publicación y distribuidor se esté ejecutando para cada suscripción

Lista de comprobación de DBA de SQL Server

Lista de verificación de Brad DBA segura

Lista de verificación de Oracle DBA (quizás útil)

Lista de verificación de administración de bases de datos DBA de SQL Server

Lista de verificación matutina de DBA

Lista de verificación de MS SQL Server DBA (muchas listas de verificación)

Lista de comprobación de DBA de SQL Server

Garik
fuente
4

La única variación que sugeriría en su lista de verificación es reemplazar la palabra BACKUP con RESTORE. Comprobar que las copias de seguridad completas es un buen comienzo, lo que realmente importa es si puede o no restaurar desde ellas. Alerte sobre una falla en la copia de seguridad, automatice una muestra aleatoria de restauraciones para que sepa que sus copias de seguridad son buenas.

El siguiente paso de una lista de verificación diaria / semanal / mensual es el historial. Una verificación de los contadores de rendimiento x / y / z no tiene sentido sin una línea de base para comparar hoy con ayer. Sin comprender el día de hoy frente a ayer, es imposible predecir el próximo mes.

Mark Storey-Smith
fuente
2

DESCARGO DE RESPONSABILIDAD: No es un DBA de SQL Server

Si es posible, es posible que desee verificar mensualmente los índices que no están siendo utilizados por ninguna consulta. Esto definitivamente querrás hacer por

  • mesas muy grandes
  • tablas con muchos índices
  • índices con muchas columnas (3 o más)
RolandoMySQLDBA
fuente
44
Solo asegúrese de que "no se use" refleje un ciclo comercial completo. He oído hablar de varios casos en los que el DBA decidió eliminar un índice que no se había utilizado en un par de meses, y al día siguiente el informe trimestral del CFO lleva horas en lugar de segundos ... no puede confiar en el index_usage_stats DMV, especialmente si su servidor se reinicia periódicamente, por lo que solo haría esto si mantiene sus propias estadísticas de uso a lo largo del tiempo ...
Aaron Bertrand
2

Verifique con frecuencia la longitud de la cola de E / S para detectar cuellos de botella.

Thomas Stringer
fuente
2

Algo para ayudar a lograrlo ... Idera lanzó una herramienta gratuita para revisar los trabajos de SQL Server que he usado varias veces. Es muy bueno para obtener una buena visión general, aunque tiene algunas limitaciones, ya que es gratuito. Vale la pena consultar: http://www.idera.com/Products/Free-Tools/SQL-job-manager/

Algo que agregaría para el lado de seguridad de la casa ... Un archivo de rastreo específicamente para capturar la actividad de inicio de sesión para las cuentas de usuario. Esto le permitirá encontrar cuentas inactivas fácilmente. Luego también script que monitorea cuando alguien se agrega a roles fijos de servidor / base de datos. Especialmente sysadmin, si no eres el único que administra el servidor / instancia.


fuente
¿Es un archivo de rastreo la mejor manera de hacer esto?
Thomas Stringer
Es la forma más fácil que sé para obtener la información. A menos que ponga un disparador para capturar la información en una tabla o log tal vez. Si se usa SQL 2008, la administración de políticas se puede usar para este propósito.
Un rastro puede ser la mejor manera, @ShawnMelton. Hay una manera de modificar el registro ( sqlservercentral.com/articles/security/sqlserverauditingpart1/… ) para que SQL Server audite todos los inicios de sesión (exitosos y fallidos). No estoy seguro de cuál es el mejor medio, pero siempre he estado preocupado por mantener un rastro funcionando indefinidamente. ¿Tus pensamientos?
Thomas Stringer
Nunca he tenido problemas al ejecutar archivos de rastreo donde afectaban tanto el rendimiento. Habilitando la auditoría C2 aunque lo tengo, no me gusta habilitar eso. Los eventos extendidos ofrecen una alternativa y se supone que son el método preferido para usar archivos de rastreo, más potencia con ellos. Puede verificarlos para ver si hay una opción para los eventos de inicio de sesión, estoy seguro de que la hay. Por lo que entiendo sobre ellos, están excluidos de alguna manera de causar un golpe con el rendimiento.
bonito. Me inclino a estar de acuerdo contigo. Y sí, C2 es definitivamente una de esas situaciones que solo se usan si es necesario.
Thomas Stringer
0
  • comprobar el registro de errores del Agente SQL Server y SQL Server
  • verificar el estado de los servidores reflejados (principal y espejo)
  • verificar cambios en el tiempo de ejecución de trabajos
  • compruebe el nodo activo en el servidor sql agrupado
  • comprobar ESPACIO DISCO
Alex_L
fuente