Post on 03-Jul-2015
description
Diagnóstico y Resolución de problemas en DatabaseMirroring y evolución a AlwaysON
400
REL40007
@enriquecatala Enrique Catala Bañuls
Mentor ecatala@solidq.com
MVP - MCT – MAP – Technical
Ranger
Rubén Garrigós
Mentor rgarrigos@solidq.com
MCT – MCAD – MCSD – MCITP
EN CUMPLIMIENTO CON LA LEY 15/1999 DE PROTECCION DE DATOS DE
CARÁCTER PERSONAL, PONEMOS EN TU CONOCIMIENTO QUE
ESTA SESIÓN VA A SER GRABADA
POR SOLIDQ Y QUE ESTA GRABACIÓN PODRÍA SER UTILIZADA COMO MATERIAL
DE MARKETING Y HACERSE PUBLICA A TRAVÉS DE DIVERSOS MEDIOS, COMO
POR EJEMPLO NUESTRA PAGINA WEB.
TENIENDO EN CUENTA QUE TU IMAGEN PUEDE APARECER EN ESA GRABACIÓN,
SI NO DESEAS APARECER, ROGAMOS NOS LO COMUNIQUES POR LOS MEDIOS
QUE YA CONOCES.
COMUNICADO
2
Agenda
3
1. Monitorización de DB Mirroring
2. Operaciones inválidas en el log
3. Monitorización AlwaysOn
4. Chequeo de estado AlwaysOn
5. Buenas practicas
6. Bloqueos en réplicas de solo lectura
Monitorización de DB Mirroring
4
Eventos SQL Server del 1400 al 1500
1480 Cambio de rol en mirroring
1440 Activo como principal
1441 Activo como secundario
1442 Mirror inactivo
1443 Mirror finalizado
1432 Reparación de página en curso
1461 Reparación de página con éxito
1481 Reparación de página fallida
Monitorización de DB Mirroring
5
Eventos de SQL Server configurables (warnings)
Eventos 32042, 32043, 32040 y 32044 respectivamente
Monitorización de DB Mirroring
6
Contadores básicos de rendimiento de DB Mirroring– Log Harden Time (ms)
– Redo Queue KB
– Send/Receive Ack Time
– Log Send Queue KB
– Transaction Delay
Baseline
Límites variables– WAN/LAN
– Físico vs Virtual
– Mirror para HA o para DR
– Mirror dedicado o compartido
Monitorización de DB Mirroring
7
Eventos WMI DATABASE_MIRRORING_STATE_CHANGE
Alertas con lógica y que reaccionen a ciertos eventos – Reintentar volver a poner en marcha la sesión si se ha suspendido
– Destruir el mirror si estamos casi sin espacio en el log del principal
Monitorización de DB MirroringThreads
8
Revisar que no agotamos los workers de SQL Server
Threads en una sesión de database mirroring– Principal • 1 thread global y 2 treads por cada BBDD en mirror
– Secundario• 1 thread global y 2 threads por base de datos
• EE +1 thread redo por cada 4 cores
Es en los thread redo donde podemos encontrarnos con una operación inválida en el secundario
Podemos diagnosticarlos en base al cambio de estado a SUSPENDED en el principal y secundario
Monitorización de DB MirroringEscenarios N a 1
9
Más apropiado para DR que para HA
Problemas por collations distintos
Colisiones de logins, de bbdd, jobs…
N a 1 N a M instancias/virtuales
No subestimar– Tener en cuenta la IO agregada
– Capacidad de CPU para hacer los REDO
Peor escenario– El secundario común convertido en
principal común de todos
Secundariocomún
N principales
Operaciones inválidas log
10
Cuando una operación es introducida en el log, se transmite de forma “ciega” al secundario– Independiente de que la réplica sea síncrona o asíncrona
– Lo único que podemos garantizar es que se ha escrito en el log del secundario pero el redo se hace siempre de forma asíncrona
– La situación puede ser difícil de solucionar una vez ha ocurrido el error
Añade o modifica un fichero de la base de datos– En una ruta que no existe en el secundario
– En un disco que no existe en el secundario
– En un disco con capacidad insuficiente en el secundario
DEMO
11
Operaciones inválidas en el log
Agenda
12
1. Monitorización de DB Mirroring
2. Operaciones inválidas en el log
3. Monitorización AlwaysOn
4. Chequeo de estado AlwaysOn
5. Buenas practicas
6. Bloqueos en réplicas de solo lectura
Hotfix AlwaysOnNo imperativos pero recomendables
13
KB 2654347 para .NET 3.5 SP1– ApplicationIntent
– Enrutamiento de solo lectura
– MultiSubnetFailover
KB 2544514 para .net 4 (4.0.2)
Para Windows Server 2008 y 2008 R2– Son unos cuantos (Windows update!)
2494036, 2616514, 2531907, 2687741, 976097, 980915, 2578103, 2578113
Monitorizacion AlwaysonModelo de evaluación de estado de salud
14
Se ha potenciado el modelo de evaluación de
estado de salud en dos pilares:
– Políticas de administración declarativa
– Powershell
Monitorizacion AlwaysOnModelo de evaluación de estado de salud: Políticas
15
Availability Group State
Availability Replica
Database Replica State
Server
– IsHadrEnabled
– ClusterQuorumState
– HadrManagerStatus
– ClusterQuorumType
Nunca olvides asignar una categoría AlwaysOn
Monitorizacion AlwaysonModelo de evaluación de estado de salud: Políticas
16
Algoritmo de evaluación
StartEjecutar políticas
definidas AlwaysOnAlguna política en
error?Marcar categoria
como Warning
NO
Marcar categoria como Error
YES
End
Reportar categoria como saludable
¿Alguna política en Warning?
YES
NO
Se obtienen condiciones AlwaysOn
Monitorizacion AlwaysonModelo de evaluación de estado de salud
17
¿Dónde creéis que se evalúa el estado?
– ¿En la réplica principal?
– ¿En cualquier secundaria?
– ¿En todas por igual?
Monitorizacion AlwaysonModelo de evaluación de estado de salud
18
Monitorizacion AlwaysonModelo de evaluación de estado de salud
19
Availability group errors (any replica)
Availability group warnings (any replica)
Availability group errors (primary)
Availability group warnings (primary)
Availability replica errors (any replica)
Availability replica warnings (any replica)
Availability database errors (any replica)
Availability database warnings (any replica)
MonitorizaciónModelo de evaluación de estado de salud: PowerShell
20
Necesario módulo SQLPS
Todo automatizado en 3 cmdlets:
– Test-SqlAvailabilityGroup
– Test-SqlAvailabilityReplica
– Test-SqlDatabaseReplicaState
Flag –AllowUserPolicies importante
Monitorizacion AlwaysonModelo de evaluación de estado de salud: PowerShell equivalencia
21
Test-SqlAvailabilityGroup
Test-SqlAvailabilityReplica
Test-SqlDatabaseReplicaState
DEMO
22
Previniendo problemas con DMF, PowerShell y alertas
Chequeo estado AlwaysOnDetección de Failover AlwaysOn
23
Frecuencia de chequeo configurable
– Propiedad HealthCheckTimeout
• En milisegundos
• Por defecto 60000
ALTER SERVER CONFIGURATION SET FAILOVERCLUSTER PROPERTY HealthCheckTimeout = ###;
Chequeo estado AlwaysOnDetección de Failover AlwaysOn
24
Resource DLL ahora llama
sp_server_diagnostics
– 3 ejecuciones por cada HealthCheckTimeout
– Fallos de conexión o devolución datos causarán
Failover
– Conexión dedicada para evaluación
sp_server_diagnostics configurable
– Siguiente slide
Chequeo estado AlwaysOnDetección de Failover AlwaysON
25
ALTER SERVER CONFIGURATION SET FAILOVERCLUSTER PROPERTY FailureConditionLevel = #;
Level Condition Failover or Restart Conditions
0 No automatic failover or restart No automatic failover or restart
ever
1 Failover or restart on server down SQL Server service is down
2 Failover or restart on server unresponsive SQL Server instance is not
responsive
3 Failover or restart on critical server errors
(default)
sp_server_diagnostics returns
“system error”
4 Failover or restart on moderate server
errors
sp_server_diagnostics returns
“resource error”
5 Failover or restart on any qualified failure
condition
sp_server_diagnostics returns
“query_processing error”
Monitorización AlwaysOnBuenas prácticas
26
1. Despliega políticas en todos los servidores
2. Crea al menos un job de evaluación
PowerShell que te envíe correos
3. Crea alertas que te envíen correos
1. Detecta cambios de estado y avísate
2. Detecta situaciones anómalas de rendimiento
y avísate
Bloqueos en réplicas de solo lectura
27
Afecta solo a las réplicas secundarias en solo lectura
Threads en los grupos de disponibilidad– Distinta aproximación a la de Database Mirroring
– Request queue y worker pool compartido por todas las bbdd de la instancia
– Se reduce la cantidad media de threads depende de la carga
– Tamaño del pool > bases de datos activas * 2 < bases de datos activas * 5 < (max worker thread – 40)
– Los backups y filestream generan threads adicionales
select * from sys.dm_exec_requests where commandlike '%HADR%' or command like '%DB%' or commandlike '%BRKR%'
Bloqueos en réplicas de solo lectura
28
Cuando una replica está marcada como solo lectura– Pequeña sobrecarga de 14 bytes para el puntero a las
versiones
– Similar a habilitar Snapshot Isolation/RCSI pero sin el row versioning en origen
– El row versioning se genera en el secundario en tempdb
El bloqueo del thread de redo ocurre al intentarobtener un bloqueo de modificación de esquema(SCH-M) que queda bloqueado por un bloqueo de estabilidad de esquema (SCH-S)– En un futuro se podrá configurar el matar la query (log
shipping style)
Bloqueos en réplicas de solo lectura
29
Para su detección – sys.dm_exec_requests
– Evento de proceso bloqueado en profiler
– Evento extendido log_redo_blocked
– Contador de rendimiento Recovery Queue
Prevención– Reducir la duración de las consultas
– Planificar las operaciones DDL en ventana de mantenimiento
– Usar tablas temporales
Reacción– Job que mate las queries que bloquean
DEMO
30
Bloqueos en réplicas de solo lectura
¿Preguntas?
31
¡Gracias!
Siéntate a comer con nosotros o tómate un café y aclara tus
dudas
@enriquecatala
Mentor
Enrique Catala Bañuls
Mentor
Rubén Garrigós
32
Si quieres disfrutar de las mejores sesiones de
nuestros mentores de España y Latino América,
ésta es tu oportunidad.
http://summit.solidq.com/madrid/
Síguenos:
33