En esta presentación vemos los aspectos de administración de SQL Azure, así como aspectos de monitoreo de desempeño.
Saludos.
Ing. Eduardo Castro
Microsoft SQL Server MVP
http://tinyurl.com/comunidadwindows
6. ¿Quién es el administrador de la aplicación?
• Web y aplicaciones departamentales
•
•
•
Azure
App
SQL
Azure
Muchas pequeñas aplicaciones distintas
1 DB por aplicación
1: N (~ 10) App Admin App
• Tier 1 / Misión Crítica
•
•
•
Pequeño # (decenas)
01:01 Admin App
Muy gestionado
SQL
Azure
Azure Aplicación
No los roles tradicionales (desarrolladores?)
Altamente automatizado
Multi-tenant (1 inquilino por DB o Federaciones)
100s - 10,000 s inquilinos
Experiencia para el monitoreo, solución de
problemas, administración es la clave
SQL
Azure
Azure Aplicación
• CSV
•
•
•
•
•
Azure
App
SQL
Azure
SQL
Azure
SQL
Azure
SQL
Azure
SQL
Azure
SQL
Azure
SQL
Azure
7. Los nuevos servicios de datos SQL
• Base de datos como un servicio
• Se centran en la combinación de las mejores características de SQL Server
que se ejecuta con escalabilidad y con facilidad de uso
• Alta compatibilidad con los actuales
• Oferta de SQL Server
• En V1, se enfoca en las cargas de trabajo web / departamental
8. Plataforma de datos: dispositivos para la nube
RDBMS
Servicio
Protección
Minería
Sincronizar
Reporting
Cargar
Almacenamiento en caché
Pregunta
Análisis
Integración
Buscar
Copia de seguridad
Modelo y el desarrollo y la gestión basada en políticas
Tipo
Lugar
En
Memoria
Multi
Oscuro
Relacional
BLOB
XML
Expediente
9. Las opciones de base de datos
Valor:
H / w Control total - tamaño /
escala
100% de la superficie API
Roll-su-propio HA / DR / escala
Valor:
100% de la superficie API
su-propio HA / DR / escala
Dedicado
En las instalaciones
SQL Server u otro s / w en las instalaciones
Web @ máquina gobierno
Seguridad DB @ servidor / OS
Valor:
Recursos
Auto HA, tolerancia a fallos
Escala sin fricción
Autoabastecimiento
Subconjunto de área de
superficie API
Hosted
SDS
Servidor virtual DB
Recursos gobernabilidad @ DB
Security @ DB / Servidor Virtual
Hosted SQL Server
Recursos gobernabilidad @ VM
Seguridad DB @ servidor / OS
Compartido
Bajo
"Friction" / Control
Alto
10. SQL Azure Conceptos
• Modelo de aprovisionamiento
– Cuenta, servidor de base de datos
• Modelo de seguridad tradicional SQL
– Autenticar los inicios de sesión, se asignan a los usuarios y roles
– Autorizar a usuarios y roles a los objetos de SQL
• Modelo de programación SQL familiar
– Modelo relacional tradicional SQL Server
– Utiliza ADO.Net, ODBC
– Las solicitudes deben ser conscientes de partición de bases de datos más
grandes
11. Ampliación plataforma de datos SQL para la nube
• Servicios iniciales - capacidades básicas RDBMS como un servicio (SDS), sincronización de
datos y Data Hub
• Futuras ofertas
• Otros capacidades de la plataforma de datos como un servicio: BI / DSS, DW
• Nuevos servicios: Datos de referencia, el centro de datos seguro
• Habilitar nuevos usos de los datos para entregar valor de negocio diferenciadas
Modelo de programación
Symmetric
Data Hub Aggregation
12. Modelo de aprovisionamiento
• Cada cuenta tiene cero o más servidores
– Portal común de Azure
– Instrumento de facturación
Cuenta
• Cada servidor tiene una o más bases de datos
– Contiene los metadatos de las bases de datos
– Unidad de autenticación
– Unidad de geolocalización
• Cada base de datos tiene objetos de SQL estándar
– Unidad de coherencia
– Contiene los usuarios, tablas, vistas, índices, etc ...
Servidor
Base de
datos
14. Arquitectura
• Infraestructura compartida SQL
–Cada base de datos de usuario se replica en varios servidores
–Las solicitudes de cliente se direccionan a la corriente de "base de datos principal"
• Tecnología HA State-of-the-art
–Detección automática de fallo; solicitud del cliente redirigido a la nueva primaria
–Equilibrio de carga entre recursos compartidos
• Gateway proporciona el punto de entrada TDS, la capacidad de aprovisionamiento
Punto de entrada de TDS, el aprovisionamiento
Máquina 1
Máquina 2
Máquina 3
Machine 4
SQL Instancia
SQL Instancia
SQL Instancia
SQL Instancia
SQL DB
Usuario
DB1
Usuario
DB5
Usuario
DB3
SQL DB
Usuario
DB4
Usuario
DB1
Usuario
DB2
Usuario
DB3
SQL DB
SQL DB
Usuario
DB4
Usuario
DB5
Usuario
DB2
Usuario
DB3
Usuario
DB4
Alta disponibilidad de la tela: conmutación por error y equilibrio de carga
Usuario
DB1
Usuario
DB2
Usuario
DB3
Usuario
DB4
15. Arquitectura de Alto Nivel
SQL Data Services Gateway Tier
Analizador
de Protocolo
Analizador
de Protocolo
Analizador
de Protocolo
Analizador
de Protocolo
Analizador
de Protocolo
Analizador
de Protocolo
Analizador
de Protocolo
Servicios de
Gestión
Servicios de
Gestión
Servicios de
Gestión
Servicios de
Gestión
Servicios de
Gestión
Servicios de
Gestión
Servicios de
Gestión
Servicios de
particiones
Servicios de
particiones
Servicios de
particiones
Servicios de
particiones
Servicios de
particiones
Servicios de
particiones
Servicios de
particiones
Servicios de datos de SQL back-end
SQL Server
SQL Server
SQL Server
SQL Server
SQL Server
SQL Server
SQL Server
Distribuido
Tela Data
Distribuido
Tela Data
Distribuido
Tela Data
Distribuido
Tela Data
Distribuido
Tela Data
Distribuido
Tela Data
Distribuido
Tela Data
Mgmt.
Servicios
Mgmt.
Servicios
Mgmt.
Servicios
Mgmt.
Servicios
Mgmt.
Servicios
Mgmt.
Servicios
Mgmt.
Servicios
16. SQL Data Services topología de red
Las aplicaciones utilizan las
bibliotecas de cliente de SQL
estándar: ODBC,
OLEDB, ADO.Net, ...
Aplicación
TDS (tcp: 1433)
Equilibrador de
carga
Sesiones del equilibrador de
carga hacia delante "adheridos" a
nivel de protocolo TDS
TDS (tcp: 1433)
Entrada
Entrada
Entrada
Entrada
Entrada
Entrada
TDS (tcp: 1433)
Nodo de
Datos
Nodo de
Datos
Nodo de
Datos
Nodo de
Datos
Nodo de
Datos
Nodo de
Datos
Escalabilidad y disponibilidad: Tela, Failover, replicación y balanceo de carga
17. La ampliación de escalabilidad con SQL Azure
• ¿Cómo puedo obtener el máximo rendimiento de
mi nivel de datos?
• ¿Qué pasa si mi aplicación tiene datos de gran tamaño
los requisitos de almacenamiento?
La ampliación con SQL Direcciones Azure estos requisitos
18. Una Escala Ejemplo de salida Architecture
ASP.Net
Aplicación
Tabique
Consciente
App Tier
Datos
Particiones
"Fragmentos"
Cliente
123
19. Instalación de software y parches
• Responsabilidades de Microsoft
– Instalación de software, parches y actualización
– Interrupción mínima del servicio
• Responsabilidades del DBA
– Instalar, actualizar su propio esquema
– Solicitud de soporte y modelo de gestión de varios servidores
20. Monitoreo y Resolución de Problemas
• Responsabilidades SQL Azure
– Servicio de Salud se controla continuamente
• Hardware, disponibilidad, uso de recursos y etc
– La auto-recuperación
• Failover automático
• Balanceo de carga
– Equipo dedicado de operación MS 24/7
– Tablero de servicio para mostrar el estado de salud día al día
• Responsabilidades del DBA
– Relájese y sólo tiene que utilizar el servicio
21. Alta disponibilidad y recuperación ante desastres
• Responsabilidades SDS
– Proporcionar capacidad automática HA locales
– Proporciona capacidad de DR
– Base de datos se copian automáticamente con fácil recuperación para
recuperación en caso de errores del sistema
• Responsabilidades del DBA
– Exportación de datos para protegerse contra errores del usuario
– "Clone" una base de datos
– Poner a disposición de "self-service" restauración de base de datos
22. Base de datos admin
• Apoyar los patrones comunes de solicitud
y la funcionalidad de TSQL
• Apoyar las tareas comunes de DBA
– Centrarse en la administración de datos lógicos
– Administración física proporcionada por el servicio de
23. Administración Lógico
•
•
•
•
•
•
•
•
Diseño de esquemas de base de datos
Usuario de base de datos y Gestión de permisos
Gestión de índices
Optimizar consultas
Gestión de Estadísticas
Data Import / Export
Reportes
...
DBA conocimiento es compatible con el on-premise
SQL
24. Lógico vs Administración Física
• Soportado
•
•
•
•
•
•
Crear / eliminar base de datos
Crear / DROP TABLE
Crear / eliminar el usuario
Reconstrucción de índices
Actualización de las estadísticas
...
• No compatible
• Ubicación de archivos de base de
datos
• Gestión de grupo de archivos
• Opciones de configuración del
servidor
• Mirroring
• ...
25. Disponibilidad retos en sistemas de nubes
• Los fallos de hardware y software son
inevitables
• La gente comete errores operacionales que
causan fallas
• A escala de la nube fallas de baja frecuencia
ocurren todos los días
Necesidad: tolerancia a fallos automática
para mantener la disponibilidad local
26. Solución de alta disponibilidad para bases de datos SQL
Lógico
Base de datos
DB
Ack
Valor
Ack
S
Multiple Física
Replicas
Leer
Escribir
P
Escribir
Ack
Escribir
S
• Lecturas se efectuara en la primario
• Escribe se replican secundarias
• Cada réplica es una copia de seguridad
de forma independiente
27. Alto Disponibilidad bajo el capó
Nodo Principal Director
Partition Manager
Promover a la
educación primaria
Que replica
perdido?
Global Mapa
de particiones
• Capacidades críticas:
– Crear nueva réplica
– Sincronización de datos
– Manténgase coherente
– Detectar fallos
– Conmutación por error
Nodo abajo
Vuelva a configurar
Nodo de datos
101
Nodo de datos
102
Datos nodo
103
Nodo de datos
104
Nodo de datos
105
P
S
P
S
P
S
S
S
P
S
S
S
P
S
S
P
S
S
S
Tejido
28. Ventajas para el cliente de alta disponibilidad
•
•
•
•
•
•
•
Sin costo administrativo adicional
Propiedades ACID son mantenidos por el sistema
Conmutaciones por error son totalmente automatizado
El enrutamiento dinámico de conexiones
No cargos adicionales por redundancia de base de datos
RPO = 0,RTO = 30 seg
99.9% de disponibilidad SLA
29. Administración Física vs Lógico
Ejemplo
Base de datos
Configuración de HA
Transparente Conmutaciones por error
Cargar Equilibrio
Creación de esquemas y Administración
Seguridad
Pregunta Optimización
Función de Administración de Aplicaciones pone más énfasis en la
gestión de lógica
30. App administración Responsabilidades
Ciclo de vida
App esquema
App de la
Salud
App de
Seguridad
Plan, Escenario, Despliegue
Monitoreo
Importación, exportación, fluj
os de trabajo
Esquema edición
Diagnóstico
Patch, Upgrade
Copia de seguridad,
Restaurar, recuperar
Informes de Cumplimiento
Ad-hoc consultas
Correcciones
Eliminar Retirarse
Gestión de usuarios
31. Características Solución de problemas
• Resúmenes y puntos de vista globales
– SQL Azure Gestión integración portal
• Solución de problemas
– Cobertura limitada DMV
– Extender DMV cobertura
– Base de datos Extended Eventos
• Solución de problemas histórico
– Tabla de eventos (Logging)
33. SQL Azure Portal de administración
Cliente Quejas:
– ¿Cómo puedo fácilmente administrar mis bases de datos de SQL Azure?
– ¿Cómo puedo encontrar con gran facilidad en los planes de consulta y
solucionar problemas de mi pregunta?
Solución:
– El SQL Azure Portal de administración simplifica la gestión y resolución de
problemas de bases de datos.
•
•
•
•
La experiencia de gestión de base de datos
Detalles de rendimiento de consulta
Los planes de consultas
Soporte de la mesa de eventos
35. Vivir Solución de problemas utilizando DMV
Quejas de Clientes:
– Tengo una gran carga de trabajo, pero estoy viendo un número bastante
bajo de conexiones y sesiones para mi aplicación. ¿Cómo puedo saber lo
que T-SQL se está ejecutando y si puedo mejorar las cosas?
Solución:
– Nuevos DMV que permiten conocer los planes en caché, activación y el
uso de procedimientos almacenados y rendimiento.
37. Nuevos DMV
DMV
Descripción
sys.dm_exec_query_memory_grants
Consultas de espera para la memoria antes de que puedan ser ejecutadas.
sys.dm_exec_cached_plans
Los planes de ejecución que se encuentran actualmente en el caso.
sys.dm_db_missing_index_details
Falta índices que aumentarían el rendimiento de las consultas.
sys.dm_db_missing_index_columns
Falta columnas de la tabla para un índice dado.
sys.dm_db_missing_index_groups
Índices que faltan se encuentran en un grupo de índices que faltan específica, excluyendo los
índices espaciales.
sys.dm_db_missing_index_group_stats
Grupos de índices que faltan, con exclusión de los índices espaciales.
sys.dm_db_index_usage_stats
Información sobre el uso de un índice.
sys.dm_db_index_physical_stats
Información sobre la distribución física de un índice determinado (consumo de espacio etc).
sys.dm_db_index_operational_stats
Información sobre el rendimiento de un índice determinado.
sys.dm_exec_procedure_stats
Uso de procedimientos almacenados en la base de datos.
sys.dm_exec_trigger_stats
Uso de disparadores en la base de datos.
38. Solución de problemas históricos con tabla de eventos
Quejas de Clientes:
– Mi aplicación experimenta problemas hace unos días. ¿Es potencialmente
relacionada con un estancamiento en SQL Azure?
Solución:
– Tabla de eventos proporciona el registro de eventos históricos dentro de la
lógica principal
– Eventos tipos:
•
•
•
•
Conexiones exitosas
Errores de conexión
Limitación
Interbloqueos
39. DMVs y monitoreo
• 10 DMVs:
select * from sys.all_views
where name like '%dm%'
– DMV mapeadas al contexto de base de datos
– Trabaja igual que SQL Server 2008 DMVs
40. DMV Tamaño de la base de datos
select
sum(reserved_page_count)*8.0/1024 AS [Storage_in_MB]
from
sys.dm_db_partition_stats
41. Consultas intensivas en CPU
select
highest_cpu_queries.total_worker_time,
q.text AS [Query_Text],
highest_cpu_queries.plan_handle
from
(select top 50
qs.plan_handle,
qs.total_worker_time
from
sys.dm_exec_query_stats qs
order by qs.total_worker_time desc) as highest_cpu_queries
cross apply sys.dm_exec_sql_text(plan_handle) as q
order by highest_cpu_queries.total_worker_time desc
42. Consultas intensivas en IO
select top 25
(total_logical_reads/execution_count) as avg_logical_reads,
(total_logical_writes/execution_count) as avg_logical_writes,
(total_physical_reads/execution_count) as avg_phys_reads,
Execution_count,
sql_handle,
plan_handle
from sys.dm_exec_query_stats
order by
(total_logical_reads + total_logical_writes) Desc
43. Tamaño de los objetos en base de datos
SELECT sys.objects.name, SUM(reserved_page_count) * 8.0 / 1024
FROM sys.dm_db_partition_stats, sys.objects
WHERE sys.dm_db_partition_stats.object_id = sys.objects.object_id
GROUP BY sys.objects.name;
45. TOP 5 de consultas
SELECT TOP 5 query_stats.query_hash AS "Query Hash",
SUM(query_stats.total_worker_time) / SUM(query_stats.execution_count) AS "Avg CPU Time",
MIN(query_stats.statement_text) AS "Statement Text"
FROM
(SELECT QS.*,
SUBSTRING(ST.text, (QS.statement_start_offset/2) + 1,
((CASE statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE QS.statement_end_offset END
- QS.statement_start_offset)/2) + 1) AS statement_text
FROM sys.dm_exec_query_stats AS QS
CROSS APPLY sys.dm_exec_sql_text(QS.sql_handle) as ST) as query_stats
GROUP BY query_stats.query_hash
ORDER BY 2 DESC;
GO
47. Deadlocks
select * from sys.event_log
where database_name = 'mi_basededatos'
and event_type='deadlock'
order by start_time desc
48. Resumen
• Administración de Aplicaciones
• Manejar una aplicación de SQL Azure
• Solucionar problemas en SQL Azure
Notas del editor
Now this is out of the way we can talk about the actual solutions.The first class of failures we need to address is the failures of individual servers, media and network devices. Add to these local operational errors made by humans. While each of these individually are quire rare at cloud scale they happen daily. So dealing with them individually is unrealistic. So we need a system that can these automatically without causing application downtime. We call this the High Availability solution.…
When your application accesses a database what it sees is a logical database. It looks and feels just like a regular physical database you use on premise. But internally the client transactions are redirected to a set of three databases called quorum. Of the three one is primary and two are secondary replicas. In addition we independently backup each replica to the attached storage for extra protection. This backup is only accessible to the Azure ops team. It is important to note that the replicas are never created on the same physical node or even in the same rack. This is to ensue that the failure of a node or network device will cause what we call quorum loss. When your read the request is completed on the primary and returned to the client. However, when you write the transaction commit needs to be replicated and acked on at least of the secondaries before returning to the client. This way we guarantee that there is always at least two of the three are up to date and if the primary fails there is always a secondary that has the most recent data.
Partition Manager is a highly available service running in the cluster (7 nodes)Every node is assigned three partitionsThe state in Partition Manager can be recreated from the local partition state on the nodesPlacement of replicas Node crashesNotify manager that node is downLook up which replicas were lostIf primary need to promote a secondaryReconfigureShrink replica set to continue operationsRemove failed secondariesInitiate replica creationAdd to quorum
Full benefits of replicated databases without administration cost of configuring and managing complicated hardware, VM or software setupsThe system guarantees database consistency Failovers happen regularly but fully automation and transparent to the application The routing to the current primary are automatically updated after failover The database cost absorbs the local redundancyFinally, you don’t have to worry about the data loss and the connections are restored within 30 secA formal SLA we support is 99.9%, which means 40 min of maximum downtime per month.