SQL Server

Usar PERFMON para detectar problemas de rendimiento de SQL

En este quinto video blog vamos a aprender a usar el monitor de rendimiento de Windows (PERFMON) para medir el rendimiento de SQL Server y poder detectar cuando hay algún problema. Es importante conocer previamente el estado normal de nuestros servidores para ser capaces de identificar cuando estamos ante un problema de rendimiento.

En el video hemos visto como usar en perfmon las métricas de uso de CPU combinadas con los lotes por segundo que procesa SQL Server así como la velocidad de lectura y escritura de los discos. Además de estas métricas también podemos revisar las compilaciones y recompilaciones de nuestro SQL Server cuyo valor ideal será un 10% o menos del total de lotes por segundo.

Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Rendimiento, SQL Server, Videos, 0 comentarios

Como usar la clasificación de datos en SQL Server

Ayer vimos como para cumplir con los reglamentos de protección de datos tipo RGPD lo primero que debemos hacer es una correcta clasificación de los datos. En ese post os expliqué también como SQL Server incorpora de forma nativa tanto en sus versiones On Premise como en las versiones de Azure una herramienta para clasificar los datos por tipo y sensibilidad.

Eso es justo lo que quiero enseñaros en el video de hoy. En poco menos de 5 minutos os voy a enseñar como acceder a esta opción, como la clasificación automática de los datos es capaz de identificar nuestras columnas más sensibles y como podemos nosotros añadir nuevas columnas a esta clasificación. Además os voy a mostrar el reporte que podremos obtener después con los datos que han sido clasificados.

Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, SQL Server, Videos, 1 comentario

RGPD en SQL y Azure: Clasificación y Cifrado de datos

No es sorpresa para ninguno de vosotros si os digo que hoy en día, cumplir con la protección de datos es más importante que nunca. Y no es para menos, el incumplimiento de estas normas puede acarrear sanciones para la empresa de hasta 20 millones de euros o el 4% de la facturación global anual, lo que sea más. La Regulación General de Protección de Datos (RGPD) ha establecido nuevas normas y expectativas para las empresas en lo que respecta a la gestión de datos personales y en este artículo, nos centraremos en cómo SQL Server puede ayudarnos a cumplir con ellas. Para ello vamos a centrarnos por un lado en la detección y clasificación de datos sensibles y por otro en las distintas soluciones nativas de cifrado y protección de estos datos.

¿Qué es el RGPD?

Antes de entrar a ver las actuaciones que tenemos que llevar a cabo en SQL Server para cumplir con la normativa, es importante que definamos los conceptos básicos que debemos conocer sobre la RGPD. No te asustes, no voy a entrar en mucho detalle, esto no es un blog legal. 

El RGPD (GDPR por sus siglas en inglés) es una ley europea que obliga a las empresas a proteger los datos personales, no solo de sus clientes y empleados sino de toda persona que tenga algún tipo de interacción con ellos. Aunque entró en vigor en 2016 y es de obligado cumplimiento desde 2018, no es raro encontrarnos con escenarios que no están completamente adaptados a ella, ya sea porque son empresas de reciente creación o porque hasta ahora no habían tenido esta necesidad.

Dentro de los datos que vamos a necesitar proteger para cumplir con el reglamento encontramos los siguientes:

  • Datos identificativos: nombre, apellidos, dirección, email, teléfono, firma, DNI y, en definitiva, cualquier dato que sirva para identificarnos.
  • Datos personales: Fecha de nacimiento, estado civil, edad, nacionailidad, sexo, religión, etc…
  • Datos sociales: Aficiones, estilo de vida, posesiones, características de la casa, etc…
  • Datos académicos y profesionales: historial académico, experiencia profesional, puesto de trabajo, profesión, pertenencia a asociaciones profesionales, etc…
  • Datos comerciales: licencias, suscripciones a publicaciones, revistas, medios de comunicación, etc…
  • Datos financieros: Cuenta bancaria, prestamos, ingresos y nivel de renta, tarjetas, planes de pensiones, datos de la nomina u otros ingresos, tributaciones, etc…

Clasificación de Datos Sensibles para cumplir la RGPD

La clasificación de datos es un primer paso fundamental en cualquier estrategia de protección de datos. Como es lógico, antes de afrontar ninguna tarea de protección de los datos deberemos clasificarlos, detectar los que son sensibles y los que están amparados por la legislación. Tanto SQL Server como las bases de datos SQL en Azure ofrecen una funcionalidad integrada para la clasificación de datos que nos permite identificar y categorizar los datos que se deben proteger.

La clasificación de datos en SQL Server se realiza a través de dos componentes principales: Etiquetas de Sensibilidad y Etiquetas de Información. Las Etiquetas de Sensibilidad nos permiten clasificar los datos según su nivel de sensibilidad, mientras que las Etiquetas de Información nos permiten categorizar los datos según el tipo de información que contienen.

Opciones Nativas de Cifrado para cumplir la RGPD

SQL Server ofrece varias herramientas nativas de cifrado para proteger nuestros datos. Estas herramientas proporcionan una capa adicional de seguridad y nos ayudan a cumplir con los requisitos de la RGPD. Ya hemos hablado de ellas en este blog de una manera detallada en este artículo, por lo que hoy vamos a hacerlo desde el punto de vista del cumplimiento normativo.

Lo primero que tenemos que tener claro es la clasificación de las medidas de cifrado según su funcionalidad. Por un lado tendremos el cifrado en tránsito que protegerá la información de un potencial atacante a la escucha durante su movimiento por la red. El otro de los tipos de cifrado es en reposo, es decir, proteger los datos de lecturas no deseadas mientras estén almacenados. En un escenario ideal implementaremos una o varias de estas técnicas de cifrado para lograr la máxima protección. 

Cifrado en tránsito

SQL Server imprenta de forma nativa la opción de usar un certificado para la conexión de manera que podamos tener un cifrado TLS en tránsito. Para ello deberemos instalar el certificado en el servidor de SQL Server y posteriormente configurarlo para su uso en SQL Server en las propiedades del servicio del motor de base de datos. Encontraremos en estas propiedades una pestaña certificados donde configurarlo (implica reinicio del servicio). En Azure no será necesario realizar ninguna acción adicional, ya que todas las conexiones implementan el uso de TLS. Sin embargo, sí es recomendable desactivar el uso de TLS 1.0 y TLS1.1 siempre que sea posible ya que por defecto están habilitados. 

Cifrado en reposo

Otra de las opciones que tenemos disponible en SQL Server es Transparent Data Encryption (TDE). TDE cifra los datos en reposo, lo que significa que los datos se cifran cuando se almacenan en el disco. Esto protege los datos contra el acceso no autorizado en caso de que los archivos de la base de datos sean robados. Sin embargo no protege los datos sensibles de su lectura para usuarios con acceso a la base de datos. Con esta opción solo nos vamos a garantizar que nadie que no disponga del certificado y la clave correctas pueda restaurar o adjuntar nuestra base de datos.

Para proteger los datos contra las lecturas de usuarios no autorizados, aunque si tengan acceso a la base de datos tenemos dos opciones, DDM y Always Encrypted. DDM o Dynamic Data Masking es la opción más básica y menos completa. Esta opción enmascara los datos para los usuarios que no tengan un permiso específico para desenmascararlos pero el dato está almacenado en disco sin ningún cifrado. Además esta opción permitirá la lectura en plano de los datos a cualquier administrador con permisos de sysadmin sin posibilidad de ocultación. 

Si queremos realmente un cifrado completo de los datos y que no puedan ser visibles para los administradores (pero si para los usuarios autorizados) tenemos Always Encrypted. Always Encrypted es una característica que protege los datos confidenciales almacenados en las bases de datos de SQL Server. Los datos están cifrados en todo momento, tanto en reposo como en tránsito, lo que significa que los datos están protegidos tanto cuando se almacenan en la base de datos como cuando se transmiten entre la base de datos y la aplicación.

Conclusión

Cumplir con la RGPD puede no ser sencillo, pero SQL Server ofrece las herramientas y funcionalidades necesarias para hacerlo de manera efectiva. Al utilizar la clasificación de datos y las herramientas nativas de cifrado, podemos proteger nuestros datos sensibles y asegurarnos de que estamos cumpliendo con las regulaciones de protección de datos.

Recuerda, la protección de datos no es solo una obligación legal, sino también una responsabilidad ética. Al proteger los datos de nuestros clientes, no solo cumplimos con la ley, sino que también construimos confianza y lealtad con nuestros clientes. Y eso, al final del día, es lo que realmente importa. Trabaja con el responsable de los datos y el departamento legal para obtener los mejores resultados. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, SQL Server, 1 comentario
Azure Data Studio vs SQL Server Management Studio (SSMS)

Azure Data Studio vs SQL Server Management Studio (SSMS)

La primera elección a la que nos vamos a enfrentar cuando vamos a trabajar con SQL Server o una instancia o base de datos de Azure por primera vez es la herramienta que vamos a usar. Existen multitud de soluciones pero las principales, y desarrolladas por Microsoft, para esta tarea son SQL Server Management Studio (SSMS) o Azure Data Studio (aquí no hay siglas, nadie usa ADS). No os dejéis llevar por los nombres, ambas soluciones nos van a permitir conectarnos de la misma manera tanto a SQL Server como a instancias o bases de datos de Azure SQL. Así que, la decisión entre una u otra será por otros aspectos que las diferencian, y eso justo es lo que hoy voy a tratar de aclararos.

¿Qué son SSMS y Azure Data Studio?

SQL Server Management Studio (SSMS) es una aplicación de código cerrado pero gratuita desarrollada por Microsoft para permitir la interacción de usuarios y administradores a las bases de datos SQL Server ya sea en instalaciones On Premise como en la nube de Azure. Además, nos permite conectarnos a otros servicios de la familia de SQL Server como son SSAS, SSRS y SSIS. Gracias a esta herramienta dispondremos de una interfaz gráfica para realizar de manera gráfica cualquier operación que necesitemos sobre SQL Server y sus objetos. Dispondremos también de la posibilidad de generar código para consulta T-SQL, DMX, MDX y DAX.

Azure Data Studio, por su parte, también es una herramienta gratuita de Microsoft pero en este caso es de código abierto. Se basa en Visual Studio Code que a su vez se basa en el Framework Electron. Esto hace que, si quieres, puedas colaborar en el código de Azure Data Studio en GitHub. Si lo comparamos con SSMS estaremos ante una aplicación visualmente más moderna, más ligera y extensible. En el caso de Azure Data Studio, al igual que en Visual Studio Code, podremos instalar componentes ya sean de Microsoft o de terceros para ampliar las funcionalidades que nos ofrece. Por ejemplo, podemos agregar compatibilidad con bases de datos MySQL o PostgreSQL. 

Compatibilidad Multiplataforma

SSMS lleva en el mercado desde SQL Server 2005, y aunque ha ido mejorando y añadiendo funcionalidades (ya va por la versión 20.1), en esencia es la misma aplicación Win32 para escritorios Windows. No tiene soporte para MacOS ni para Linux y eso restringe su uso a servidores o estaciones clientes con un sistema operativo Windows.

Azure Data Studio, por el contrario, al estar basado en Visual Studio es multiplataforma y podremos instalarlo en equipos Windows, Linux o Mac (no como SSMS que solo es compatible con Windows).

¿A quién va dirigido SSMS y Azure Data Studio?

SSMS es una aplicación dirigida a desarrolladores SQL Server y administradores de bases de datos o profesionales de sistemas que deban administrar Servidores SQL Server. Incluye todas las opciones de administración de forma gráfica y nos permite adaptar cualquier configuración con unos pocos clics de ratón. Gracias al soporte ampliado de las nuevas versiones, además, vamos a poder administrar de la misma manera Azure Managed Instances, Azure Databases o pools de Azure Synapse SQL. Por último, como ya hemos comentado, también vamos a poder usar SSMS para conectar con SSAS, SSRS y SSIS.

Azure Data Studio, por el contrario, es una aplicación centrada en su uso por profesionales de datos y BI y desarrolladores por lo que prescinde de todas las opciones de administración que nos brinda SSMS. Esto hace que sea una aplicación mucho más ligera como hemos comentado antes. No quiere decir que desde Azure Data Studio no vayamos a poder administrar nuestros servidores, si vamos a poder, simplemente tendremos que hacerlo por comandos T-SQL. Mucho más engorroso, ¿verdad?. Si nos gustase eso administraríamos Servidores Oracle y ganaríamos más dinero. Con Azure Data Studio tendremos la posibilidad de conectarnos a SQL Server On Premise, Azure Database, Azure Managed Instance, Azure Synapse así como a MySQL y a PostgreSQL. Sin embargo, y esto es una cosa que no entiendo, no tiene soporte para bases de datos NOSQL como la propia CosmoDB de Azure.

Características

En cuanto a la comparativa propiamente dicha, como venimos comentando, está entre las funciones que cada una de las aplicaciones nos brinda. Vamos primero a ver las características comunes a ambas aplicaciones y luego sus diferencias. Ambas tienen un editor de consultas que admite T-SQL, DMX, MDX, DAX y XMLA (SSAS) y se apoyan en IntelliSense para facilitarnos la tarea. También disponen de un explorador para visualizar jerárquicamente los objetos que componen nuestra base de datos. 

Como diferencias, SSMS dispone de un gran arsenal de herramientas pensadas para administradores y usuarios más avanzados de SQL Server entre las que podemos destacar las relacionadas con la seguridad, el mantenimiento y el Agente de SQL Server. Disponemos también de Query Store y una serie de informes predefinidos para las bases de datos que nos aportarán información muy valiosa.

Azure Data Studio, cuenta en su haber con otras características exclusivas como los cuadernos Jupyter, integración con GitHub y con Copilot y la posibilidad de instalar extensiones. Además soporta los lenguajes de programación Python, R y Scala.

Para cerrar este apartado, quiero destacar la integración entre SSMS y Azure Data Studio. Si disponemos de ambas aplicaciones instaladas, desde SSMS vamos a poder abrir Azure Data Studio directamente para poder trabajar con los cuadernos Jupyter. 

SSMS_AzureDataStudio

Tampoco sería justo dejar de mencionar que, si bien Azure Data Studio no está pensado para administrar servidores, poco a poco se van añadiendo funcionalidades para este fin. En el momento de escribir estas líneas, podemos encontrar cómo Preview funcionalidades avanzadas hasta ahora exclusivas de SSMS.

AzureDataStudio_Manage

Conclusión

Azure Data Studio y SSMS son dos poderosísimas herramientas desarrolladas por Microsoft para facilitarnos nuestras interacciones diarias con SQL y Azure. Elegir una u otra dependerá de nuestras necesidades ya que no están pensadas para el mismo público objetivo y por tanto no disponen de exactamente las mismas funcionalidades. En mi caso trabajo siempre con ambas aplicaciones abiertas y depende la tarea que tenga que realizar en ese momento uso la que mejor se adapte. Espero que gracias a este artículo vosotros podáis tomar la mejor decisión informada y veáis cubiertas vuestras necesidades. Como siempre, estamos aquí para ayudarte. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, SQL Server, 1 comentario

¿Cómo usar QueryStore en SQL o Azure?

En este tercer Video Blog nos adentramos en QueryStore, una de las herramientas más potentes que Microsoft pone a nuestra disposición de manera nativa para monitorizar el rendimiento de nuestras bases de datos SQL ya sea en SQL Server o en Azure.

Como ya os prometí en el post de ayer donde vimos la teoría que rodea a esta herramienta, hoy vamos a aprovechar las ventajas del formato de Video Blog para ver todas las opciones de visualización de datos y configuración de la herramienta que necesitamos para convertirnos en verdaderos profesionales del rendimiento en SQL.

Vistas de QueryStore

QueryStore pone a nuestra disposición varias vistas con diferente información de lo más útil.

  • Regresed Queries: Nos va a permitir localizar las consultas que han sufrido una degradación de rendimiento.
  • Overall Resource Consumption: Muestra el consumo de los diferentes recursos a lo largo del tiempo en diferentes gráficos de barras.
  • Top Resource Consuming Queries: Nos va a mostrar las consultas que más recursos han consumido de un recurso que nosotros elijamos en un periodo a elegir entre 5 minutos y varios años.
  • Queries With Forced Plans: Aquí podremos encontrar las consultas a las que les hemos forzado un plan de ejecución en concreto.
  • Queries With High Variation: Esta vista nos mostrará las consultas con gran variación en su consumo de recursos, ya sea a mejor o peor.
  • Query Waits Statistics: Este informe es uno de los más importantes y por el que yo siempre empiezo a mirar. En el vamos a ver cuales son los recursos que causan cuellos de botella en el rendimiento de nuestras consultas.
  • Tracked Queries: En este último dashboard vamos a poder hacer seguimiento del rendimiento de una consulta en concreto que nosotros elijamos.

Objetivos de la optimización en QueryStore

El fin principal de esta herramienta no es otro que ayudarnos a mejorar el rendimiento de nuestras consultas. Es importante remarcar, que una buena optimización no solo mejorará los tiempos de nuestros procesos sino que, además, reducirá el consumo de recursos permitiéndonos un gran ahorro en infraestructura tanto si tenemos servidores locales como en la nube. En este último escenario, donde el pago por uso parece ya un estándar este ahorro de recursos puede marcar la diferencia entre que nuestro proyecto sea o no rentable.

Conclusión

QueryStore es una gran herramienta que nos va a permitir optimizar el rendimiento de las consultas y ahorrar costes tanto en SQL Server como en Azure SQL. A través de sus diferentes informes vamos a ser capaces de localizar y poner solución a los problemas de nuestro servidor. Espero que este artículo te haya proporcionado una visión profunda del almacén de consultas en SQL Server y Azure. Como siempre, estamos aquí para ayudarte. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, Rendimiento, SQL Server, Videos, 1 comentario

Query Store en SQL Server y Azure

Todos los que nos dedicamos al mundo de las bases de datos, ya sea como administradores o como usuarios, siempre deberíamos estar buscando formas de mejorar el rendimiento y la eficiencia de las consultas. Por eso, hoy vamos a explorar una herramienta muy poderosa que puede ayudarnos a hacer precisamente eso: el almacén de consultas o Query Store disponible de forma nativa tanto en SQL Server como en Azure.

¿Qué es el Query Store?

El almacén de consultas es una característica que permite rastrear y revisar el historial de ejecución de consultas en SQL Server y Azure. Es como la “caja negra” de los aviones pero para nuestras consultas SQL en SQL Server o Azure. Gracias a esta información de Query Store vamos a lograr una visión detallada de cómo se están ejecutando nuestras consultas a lo largo del tiempo y con ello, localizar problemas o puntos de mejora en el rendimiento.

Beneficios de Query Store

Query Store ofrece muchos beneficios, vamos a centrarnos en los principales. Lo principal para mi es que nos permite identificar consultas de alto consumo de recursos. Esto, por sí solo ya sería un motivo de peso para valorar configurarlo en nuestros sistemas pero, además, nos va a facilitar ver cómo cambia el rendimiento de las consultas con el tiempo y entender cómo las diferentes configuraciones afectan el rendimiento de las consultas.

Configuración en SQL Server

En SQL Server, el almacén de consultas se puede habilitar a nivel de base de datos. Una vez habilitado, comenzará a recopilar datos sobre las consultas ejecutadas en la base de datos. Y ya está, desde ese preciso momento podemos usar esta información para identificar consultas problemáticas y tomar medidas para mejorar su rendimiento. Pero, no nos saltemos pasos, vamos a ver en detalle la ventana de configuración y repasar sus opciones.

QueryStore

Como podemos ver la configuración es bastante sencilla. Deberemos indicar algo más de media docena de parámetros y aplicar los cambios. Como es habitual, tenemos un cuadro de texto bajo las opciones donde se nos especifica que hace cada una de esas configuraciones. Profundizaremos en esta configuración en futuros post así que no vamos a complicar más esta explicación.

Configuración en Azure

En Azure es incluso más sencillo, Query Store es una característica incorporada y habilitada por defecto tanto en Azure SQL Database como en Azure SQL Managed Instance. Al igual que en SQL Server, nos proporciona información valiosa sobre el rendimiento de nuestras consultas. Además, como pudimos ver en la beta presentada este fin de semana en el evento Global Azure Spain, se integra con Azure Copilot para que podamos preguntar directamente a la IA de Microsoft cuáles son los problemas y obtener toda la información en lenguaje natural.

Uso de Query Store 

Una vez habilitado Query Store en SQL Server o de manera automática en las bases de datos de Azure ya dispondremos de los informes correspondientes dentro del apartado Query Store en la base de datos. 

QueryStore_2

Podéis apreciar en la imagen que, una vez en nuestro SSMS no hay diferencias entre la base de datos de Azure y la que está en mi instancia local. Los informes son los mismos y van a tener la misma información. Si queréis profundizar más sobre los distintos informes y su funcionamiento estad atentos al blog que mañana publicaremos un video donde os lo enseñaré en detalle.

Conclusión

El almacenamiento de consultas es una herramienta poderosa para la administración de bases de datos en SQL Server y Azure. Nos permite rastrear y analizar el rendimiento de nuestras consultas, lo que nos ayuda a optimizar nuestras bases de datos y mejorar la eficiencia. Si aún no estás utilizando el almacenamiento de consultas, te animamos a que lo explores y veas cómo puede beneficiar a tu entorno de base de datos.

Esperamos que este artículo te haya proporcionado una visión profunda del almacén de consultas en SQL Server y Azure. Como siempre, estamos aquí para ayudarte en tu viaje de administración de bases de datos. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, Rendimiento, SQL Server, 2 comentarios

¿Sirven de algo los bloqueos de recursos en Azure?

Volvemos con nuestros video blogs esta vez con un vídeo sobre los bloqueos de recursos en Azure. Esta opción nos va  a permitir generar un bloqueo sobre un objeto de Azure para evitar que se pueda borrar. De esta manera, cuando alguien intente borrar nuestra base de datos o instancia gestionada desde el portal de Azure obtendrá un error indicando que el recurso está bloqueado.

Bloqueo de Recursos en Azure

Azure ofrece una característica llamada bloqueos que nos permite proteger nuestros recursos contra modificaciones o eliminaciones accidentales. Los bloqueos de recursos pueden ser aplicados a cualquier recurso de Azure, desde suscripciones y grupos de recursos hasta servicios individuales.

Plano de Control y Plano de Datos

Para entender cómo funcionan los bloqueos de recursos, primero debemos entender la diferencia entre el plano de control y el plano de datos en Azure.

El plano de control es responsable de las operaciones de gestión en Azure. Esto incluye acciones como la creación, modificación y eliminación de recursos. Cuando aplicamos un bloqueo de recursos, estamos interactuando con el plano de control.

Por otro lado, el plano de datos se encarga de las operaciones que se realizan en los recursos una vez que están creados. Esto incluye acciones como la lectura y escritura de datos en una base de datos o el envío de mensajes a través de un bus de servicio. Este plano de datos queda fuera del «paraguas» de protección de los bloqueos de recursos.

Aplicando Bloqueos de Recursos

Los bloqueos de recursos se pueden configurar para permitir solo lecturas o para evitar todas las modificaciones. Un bloqueo de solo lectura permitirá que los usuarios vean y consulten los recursos, pero no podrán hacer cambios. Un bloqueo de no modificación, por otro lado, evitará cualquier cambio en el recurso, incluyendo la eliminación.

Conclusión

La protección de nuestros recursos en Azure es esencial para mantener la integridad y seguridad de nuestros datos. Los bloqueos de recursos nos ofrecen una forma eficaz de prevenir borrados y modificaciones no deseadas, asegurando que nuestros recursos permanezcan seguros y protegidos. Sin embargo, esto debe ser combinado por una buena política de permisos en SQL Server o, de lo contrario una operación desde el plano de datos acabará con nuestros sistemas.

Recuerda, como administradores de bases de datos, nuestra prioridad es siempre la seguridad y la protección de nuestros recursos. Asegúrate de utilizar todas las herramientas a tu disposición para mantener tus recursos de Azure seguros. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, Videos, 0 comentarios