En SolidQ tenemos mucha experiencia en alta disponibilidad, y eso incluye database mirroring y AlwaysOn. Tanto si tienes implementada cualquiera de estas tecnologías como si estás pensando en hacerlo, te interesa esta sesión en la que hablaremos no tanto de cómo implementarlo, sino de qué problemas podemos encontrarnos con ellos funcionando así como cómo resolverlos. La idea es que salgas de aquí con la seguridad de como de robusta es esta tecnología y si realmente cubre tus necesidades.

1. Diagnóstico y Resolución de problemas en Database
Mirroring 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

2. 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

3. 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

4. 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

5. Monitorización de DB Mirroring
5
Eventos de SQL Server configurables (warnings)
Eventos 32042, 32043, 32040 y 32044 respectivamente

6. 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

7. 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

8. Monitorización de DB Mirroring
Threads
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

9. Monitorización de DB Mirroring
Escenarios 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
Secundario
común
N principales

10. 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

11. DEMO
11
Operaciones inválidas en el
log

12. 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

13. Hotfix AlwaysOn
No 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

14. Monitorizacion Alwayson
Modelo 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

15. Monitorizacion AlwaysOn
Modelo 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

16. Monitorizacion Alwayson
Modelo de evaluación de estado de salud: Políticas
16
Algoritmo de evaluación
Start
Ejecutar políticas
definidas AlwaysOn
Alguna 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

17. Monitorizacion Alwayson
Modelo 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?

18. Monitorizacion Alwayson
Modelo de evaluación de estado de salud
18

19. Monitorizacion Alwayson
Modelo 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)

20. Monitorización
Modelo 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

21. Monitorizacion Alwayson
Modelo de evaluación de estado de salud: PowerShell equivalencia
21
Test-SqlAvailabilityGroup
Test-SqlAvailabilityReplica
Test-SqlDatabaseReplicaState

22. DEMO
22
Previniendo problemas con
DMF, PowerShell y alertas

23. Chequeo estado AlwaysOn
Detección de Failover AlwaysOn
23
Frecuencia de chequeo configurable
– Propiedad HealthCheckTimeout
• En milisegundos
• Por defecto 60000
ALTER SERVER CONFIGURATION SET FAILOVER
CLUSTER PROPERTY HealthCheckTimeout = ###;

24. Chequeo estado AlwaysOn
Detecció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

25. Chequeo estado AlwaysOn
Detección de Failover AlwaysON
25
ALTER SERVER CONFIGURATION SET FAILOVER
CLUSTER 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”

26. Monitorización AlwaysOn
Buenas 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

27. 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 command
like '%HADR%' or command like '%DB%' or command
like '%BRKR%'

28. 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 intentar
obtener 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)

29. 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

30. DEMO
30
Bloqueos en réplicas de
solo lectura

31. ¿Preguntas?
31

32. ¡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

33. 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