Skip to content

Read only routing con SQL Server y AlwaysOn Availability Groups

SQLServerLogo

La característica de AlwaysOn Availability Groups en SQL Server es sin dudas una de las más útiles y efectivas técnicas de alta disponibilidad dentro del producto. Con ella no solo podemos aumentar la disponibilidad de los datos en casos de falla de servidores, sino además contar con copias de solo lectura, que nos permiten redirigir operaciones de lectura intensiva a estas copias, descargando a la copia principal.

Ya en varios post anteriores me refería a la implementación y catacterísticas de AlwaysOn Availability Groups. En este post quiero mencionar una configuración necesaria para aprovechar completamente las réplicas activas que definamos.

Se trata del Read Only Routing, que establece el mecanismo por el cual, si la configuración es apropiada y la cadena de conexión se forma correctamente, las operaciones de lectura pueden ser automáticamente dirigidas a una o varias de las réplicas activas disponibles. Incluso a partir de SQL Server 2016 este mecanismo permite una forma de balance de carga entre las réplicas.

Es importante tener en cuenta que el uso de Read Only Routing no dirige a las copias de lectura cualquier operación de lectura, sino solo las que provengan de conexiones que fueron declaradas solo para leer (ApplicationIntent=ReadOnly)

El detalle completo de la implementación de Read Only Routing lo pueden obtener de este documento de Microsoft:

Configure Read-Only Routing for an Availability Group (SQL Server)

Pero algo también importante es poder, una vez configurado el Read Only Routing, verificar la configuración y asegurarnos que los nodos indicados son los correctos. Para esta tarea, les dejo un script que he desarrollado personalmente y que nos indica, por cada grupo de disponibilidad, las réplicas existentes y el orden de acceso para operaciones de lectura.:

–Validar read only routing con AlwaysOn Availability Groups
SELECT AG.name as AvailabilityGroup,r.replica_server_name,r.availability_mode_desc,r.failover_mode_desc,
r.primary_role_allow_connections_desc,r.secondary_role_allow_connections_desc
,RL.routing_priority,RRO.read_only_routing_url
FROM sys.availability_groups AG
JOIN sys.availability_replicas R ON AG.group_id=R.group_id
JOIN sys.availability_read_only_routing_lists RL ON R.replica_id=RL.replica_id
JOIN sys.availability_replicas RRO ON RRO.replica_id=RL.read_only_replica_id
ORDER BY AG.name,replica_server_name,routing_priority

 

 

 

 

Ya está disponible el Microsoft SQL Server 2016

SQL2016

El 1 de junio de 2016 Microsoft ha finalmente liberado la versión final del SQL Server 2016. Las muchas mejoras del producto se presentan en áreas como BI, seguridad, escalabilidad, soporte de otras plataformas e infinidad de nuevas características. En próximas notas irá profundizando en cada uno de estos temas.

Pero ahora quiero dejarles el link al sitio oficial donde podrán descargar el Microsoft SQL Server 2016 en su versión trial, para que vayan implementando este nuevo motor:

SQL Server 2016 – Versión de evaluación

 

 

 

La sabiduría de la fuerza

A menos de un mes del estreno de un nuevo episodio de Star Wars (The Force Awakens), les dejo este link que resume las frases más célebres de Yoda. Todas ellas son muy interesantes ¡Que la fuerza los acompañe!

¡Superamos las 100.000 visitas!

100000Visitas

Gracias a todos los que con su visita, día a día, dan vida a este blog, colaborando y aportando sus experiencias, conocimientos e inquietudes.

Listar roles de servidor y de base de datos en SQL Server

SQLServerLogo

Les dejo aquí dos comandos útiles para listar los roles fijos y del usuario definidos a nivel de servidor en una instancia de SQL Server y los roles del base de datos y de aplicación para una base de datos determinada

Para obtener una lista de todos los roles existentes a nivel de instancia:

SELECT *
FROM sys.server_principals
WHERE type = ‘R’

Para obtener una lista de los roles de bases de datos:

SELECT Name,  uid isapprole
FROM sysusers
WHERE issqlrole = 1 or isapprole = 1

Sincronizar correo de Microsoft Office 365 con un Samsung Galaxy S5 y Android 5.0 a traves de una conexión Wifi

Office365

Como usuario de los servicios de la nube de Office 365 poseo cuentas de correo provistas a través de Exchange Online. El servicio es realmente excelente y siempre ha superado mis expectativas. Pero una de las cuestiones que últimamente dificultaron el uso de mis cuentas de correo fue la imposibilidad de sincronizar los mails a través de WiFi con mi teléfono móvil, un Samsung Galaxy S5 con Android 5.0.

En la versión de software original del teléfono (Android 4.3 KitKat) la sincronización de correo con la aplicación nativa del teléfono funcionaba perfectamente. Pero luego del upgrade a Android 5.0, inmediatamente dejó de funcionar. Lo extraño es que usando la red móvil (en mi caso Movistar de Argentina) el mail funcionaba normalmente. Lo mismo si utilizo el cliente de Outlook para Android (con esta App se sincroniza correctamente tanto en WiFi como con red móvil) He comprobado además que son solamente las cuentas de Office 365 y de Outlook.com las afectadas.

Investigando en distintos foros y realizando múltiples pruebas he llegado finalmente a aplicar una solución que resuelve este problema y que quería compartir con ustedes:

Se trata de una configuración muy simple y limpia, que es eliminar de las propiedades del APN la dirección del proxy server, que en mi caso tenía un valor prefijado por la operadora. Les muestro los pasos:

Screenshot_2015-05-15-11-46-33 Screenshot_2015-05-15-11-46-42 Screenshot_2015-05-15-11-46-49 Screenshot_2015-05-15-11-46-59 Screenshot_2015-05-15-11-47-16

Como podrán ver se trata de un bug del sistema operativo Android, que utiliza para las redes WiFi una configuración que no corresponde a esta categoría. Algunos usuarios mencionan que con el upgrade a Android 5.1 esto se resuelve, pero por ahora en Android 5.0 tenemos esta alternativa.

El cambio realizado no parece haber afectado la conectividad del teléfono a la red de datos móvil (Movistar Argentina) Sigo accediendo normalmente y me conecto a la red 4G (LTE) como lo hacía antes del cambio.

Habilitar la compresión de backups para bases con log shipping

SQLServerLogo

La compresión de backups es una característica muy útil de SQL Server, que reduce drásticamente los archivos que se generan durante la copia de seguridad. Este procedimiento es usado normalmente en los backups diarios que forman parte de una política de protección de datos, pero también puede ser aplicado a otras funcionalidades del servidor que dependen de archivos de backup. Entre estas funcionalidades está la técnica de log shipping, que consiste en tomar copias periódicas del log de transacciones y restaurarlas en un servidor secundario. En este procedimiento se transfieren continuamente backups del log de transacciones, muchas veces voluminosos durante períodos de alta actividad de una base de datos, o por operaciones de mantenimiento como reconstrucción de índices.

La compresión de backups de log shipping puede hacerse directamente en la interfaz gráfica del SQL Server Management Studio desde SQL Server 2008 para la edición Enterprise. Pero lo que pocos saben es que también se pueden comprimir estos backups en la edición standard de SQL Server, desde la versión SQL Server 2008 R2, si se implementa mediante TSQL y procedimientos del sistema.

El comando necesario para habilitar la compresión de backups generados por el job de backup del proceso de log shipping es el siguiente:

exec sys.sp_change_log_shipping_primary_database @database = ‘BaseDatos’,
@backup_compression = 1

reemplazando el valor correspondiente al nombre de la base de datos primaria. Este comando debe ejecutarse en el servidor primario de log shipping.

Para comprobar el estado actual de compresión de una base en log shipping podemos usar:

exec sys.sp_help_log_shipping_primary_database @database = ‘BaseDatos’

La ganancia de espacio que se obtiene con esta compresión es extremadamente alta. He obtenido resultados donde backups de 80Gb. terminan reducidos a menos de 15Gb. La penalidad es un mayor uso de CPU durante la generación del backup y la restauración. Pero considerando que la CPU es el recurso que normalmente más abunda en los servidores modernos y que el subsistema de discos es en general el mayor cuello de botella, esta carga adicional por la compresión no parece ser relevante.

Para más información sobre el uso de la técnica de log shipping, les recomiendo los siguientes posts:

Script para monitorear el funcionamiento del proceso de log shipping en SQL Server

Comparación de técnicas de alta disponibilidad con SQL Server

Backup de bases de datos a Windows Azure desde SQL Server

SQLServerLogo

El Backup de nuestras bases de datos en SQL Server es una de las partes fundamentales de todo plan de contingencia y recuperación ante desastres. Las operaciones de Backup deben ser parte de un plan cuidadosamente diseñado y bien documentado. Ese plan debe incluir además la disposición física de los backups, para protegernos de eventos naturales como incendio o inundación y de posibles robos. Esta última cuestión es muchas veces dejada de lado y nos encontramos con copias de seguridad almacenadas en el mismo servidor o en equipos contiguos, que corren el mismo riesgo que la base principal de recibir distintos daños.

Pero ahora tenemos nuevas herramientas que pueden resolver este problema de forma simple, confiable y económica. Los servicios en la nube de Windows Azure ofrecen entre otras posibilidades el crear almacenamientos virtuales, con disponibilidad asegurada y redundancia completa. De esta forma, lo que allí depositemos estará siempre al alcance, crecerá con nuestras necesidades de espacio y no será afectado por falla alguna.

En SQL Server 2014 se incluye una nueva funcionalidad que permite el backup de bases directamente a un Windows Azure Storage a través de la misma semántica e instrucciones presentes para el Backup en otros medios. Un ejemplo simple es el siguiente:

BACKUP DATABASE AdventureWorks2012
TO URL = ‘https://mystorageaccount.blob.core.windows.net/mycontainer/AdventureWorks2012.bak’
WITH CREDENTIAL = ‘mycredential’ ,COMPRESSION ,STATS = 5;
GO

Como ven se trata de algo simple y a la vez tremendamente poderoso por el nivel de protección que este Backup recibirá. En una próxima nota publicaré un video completo de como realizar este Backup, incluyendo todos los pasos a ejecutar tanto en el portal de Azure como dentro del SQL Server. Para que puedan seguir profundizando en el tema les recomiendo el siguiente link:

SQL Server Backup to URL

Diferencias entre las ediciones standard y enterprise de SQL Server

SQLServerLogo

Al momento de determinar la versión de SQL Server que más se adapta a las necesidades y requerimientos de nuestra infraestructura debemos comparar estas ediciones en todas sus funcionalidades y características. En este artículo encontrarán un análisis puntual de las diferencias entre las ediciones standard y Enterprise de SQL Server 2014 para el servicio de base de datos, dividido en distintas áreas de evaluación:

Soporte de hardware

Una de las diferencias importantes en este aspecto es que la edición Standard soporta un máximo de 4 sockets o 16 núcleos, mientras que la edición Enterprise solo está limitada por la cantidad de núcleos admitidos por el sistema operativo, por lo que no plantea un límite particular. Algo similar ocurre con la memoria que en la edición Standard permite hasta 128Gb. y no existe límite alguno en la versión Enterprise.

En la edición Enterprise se soporta también el agregado en caliente de memoria y de procesadores (Hot add)

Optimización

Existen importantes diferencias en las posibilidades de optimización y en las características de almacenamiento y mejoras del rendimiento. Las funciones que solo aparecen en la edición Enterprise son por ejemplo el particionamiento de tablas e índices, la compresión de datos y el uso automático de las vistas indexadas en los planes de ejecución.

En esta categoría también aparece la gran incorporación a la versión 2014 de SQL Server, que se denomina In-Memory OLTP y que no es otra cosa que la implementación de tablas almacenadas en memoria. Con esta función podemos obtener ganancias de rendimiento de ordenes de magnitud y realizar el diseño de nuestras bases con perspectivas mucho más amplias. El uso de In-Memory OLTP está reservado para la edición Enterprise de SQL Server 2014.

Alta disponibilidad

Seguramente el area que presenta las diferencias más destacables es el de alta disponibilidad. En este caso, para la edición Enterprise aparece la característica de AlwaysOn Availability Groups, que solo está disponible en esta edición.

Sobre la técnica de “Database Mirror” existe una diferencia entre las ediciones, ya que la Enterprise soporta cualquier configuración de esta característica, mientras que la Standard soporta solo el modo “High Safety” (sincrónico)

Para más información sobre la comparación entre técnicas de alta disponibilidad y detalles del uso de AlwaysOn Availability Groups les recomiendo estos posts:

Comparación de tecnicas de alta disponibilidad con SQL Server

SQL Server 2012: Requisitos para la implementación de alta disponibilidad con AlwaysOn

AlwaysOn Availability Groups de SQL Server 2012 vs. Database Mirror de SQL Server 2008

Experiencias en la implementación de Always On Availability Groups con SQL Server 2012

Nuevas características de Microsoft SQL Server 2014

Componentes de SQL Server

Pese a que ambas ediciones incluyen los componentes de business intelligence (Integration Services, Analysis Services y Reporting Services) la edición Enterprise incorpora algunos elementos avanzados. Sobre Integration Services por ejemplo se agregan conectores de datos optimizados para Oracle, Teradata y SAP y las transformaciones relacionadas con lógica difusa.

En Analysis Services la edición Enterprise incorpora optimizaciones para el procesamiento de esquemas estrella (star join query optimization) y en Reporting services tenemos las suscripciones basadas en datos y los reportes con Power View.

Seguridad

La mayor diferencia entre las ediciones Standard y Enterprise a nivel de seguridad es la posibilidad de encriptación de datos que nos brinda solo la edición Enterprise a través de la funcionalidad de TDE (Transparent Data Encription).

Conclusiones

Existen muchas más diferencias que no están explícitamente enumeradas en este artículo y que pueden ser de importancia al momento de definir que edición del producto utilizar. También debemos considerar que estas diferencias cambian entre versiones de SQL Server y no son las mismas por ejemplo para SQL Server 2008.

Para el detalle completo y la comparación de funciones de cada edición les recomiendo el siguiente link:

Features Supported by the Editions of SQL Server 2014

Modificar la ubicación de la base de datos del Management Datawarehouse en SQL Server

SQLServerLogo

El componente de Data Collection de SQL Server nos permite registrar en forma continua la actividad del servidor, así como otros parámetros importantes de funcionamiento. Esta información es recolectada por diversos procesos y depositada en una base de datos, denominada Management Datawarehouse, desde la cual se generan reportes muy detallados que son muy importantes al momento de monitorear un servidor y detectar posibles problemas.

La base de datos del Management Data Warehouse puede ser reubicada, de acuerdo a necesidades de espacio en disco, de rendimiento o de organización de archivos. Para realizar esta tarea serán necesarios los siguientes pasos:

Mover base de datos del Management Data Warehouse

Mover base de datos del Management Data Warehouse

  1. Deshabilitar el proceso de recolección de datos (Data collection)
  2. Realizar un dettach de la base de datos del Management Data Warehouse
  3. Realizar un attach de los archivos de esta base de datos en la nueva ubicación requerida
  4. Habilitar la recolección de datos nuevamente

Luego de estos pasos todo funcionará correctamente y los eventos serán incorporados a la base de datos en su nueva ubicación.

Para mayor información sobre el componente de Data Collection de SQL Server les recomiendo los siguientes links:

Data Colletion

Configure the Management Data Warehouse