Les quiero recomendar un artículo muy completo publicado por Microsoft con respecto a la configuración de seguridad en bases de datos Azure SQL mediante identidades de Azure AD. Podemos ver la forma de configurar tanto el acceso administrativo como la creación de usuarios contenidos dentro de las bases de datos.
Siempre es conveniente tener disponible el listado de últimas actualizaciones para cada versión de SQL Server. Esta información es continuamente actualizada por Microsoft, por lo que la mejor alternativa es consultar directamente la documentación oficial:
La administración y ejecución de paquetes de Integration Services desde aplicaciones .NET tradicionalmente ha implicado el uso de librerías de objetos, como la Microsoft.SqlServer.Dts.Runtime. Pero muchas veces, nos puede ser útil un mecanismo mas liviano de interacción, incluso si lo debemos utilizar desde plataformas que no sean .NET.
Es en esos casos en donde aparece la posibilidad de ejecutar paquetes a traves de una serie de stored procedures incluídos en la base de catálogo de Integration Services. Con estos procedimientos, podremos crear instancias de ejecución, comenzar, detener y verificar el estado de ejecución. También es posible enviar parámetros a los paquetes y muchas otras tareas más.
Les dejo a continuación un link oficial de Microsoft con el listado de procedimientos disponibles y una descripción de su función:
En circunstancias excepcionales podemos encontrarnos ante el caso de un servidor SQL Server que no responde, generalmente por causa de un muy alto uso de CPU producto de alguna consulta o proceso mal implementado.
En estos casos resulta muy complicado conectarse al servidor, lo que necesitamos justamente para diagnosticar y resolver la falla.
Afortunadamente contamos con una posibilidad para conectarnos al servidor con un tipo de conexión especial que permite el acceso aun en casos de muy alta carga. Se trata de la conexión dedicada del administrador (DAC – Dedicated admin connection)
Para utilizar esta forma de conexión es importante considerar lo siguiente:
- Si usamos el SQL Server Management Studio, solo se puede usar la DAC para una conexión desde la opción de File/New/Database Engine Query (Archivo/Nuevo/Consulta de base de datos). Si intentamos generar una consulta por otros medios, o conectarnos al servidor con el Object Explorer, obtendremos un error.
- Solo podrán usar este tipo de conexión los logins que sean miembros del rol sysadmin.
- Al crear una nueva consulta de base de datos, se nos presentará el diálogo para elegir el servidor e indicar las credenciales. Se debe usar:
- En el nombre del servidor, para la instancia por default: ADMIN:servidor
- En el nombre del servidor, para una instancia nombrada: ADMIN:servidor\instancia
Una vez realizada la conexión, a través de la ventana de nueva consulta, podrán operar con el servidor de manera de detectar el motivo que produce la falta de respuesta del equipo.
El siguiente artículo indica con detalle este tipo de conexiones y explica también como habitar esta funcionalidad en un servidor:
https://4sysops.com/archives/dedicated-administrator-connection-dac-in-sql-server-2008-r2/
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.:
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
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
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!
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.
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
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:
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.
Horacio A. Gonzalez 