Nuevo DBA en la nube: administración de Azure SQL Database después de la migración

Se aplica a:Azure SQL Database

El cambio del entorno autocontrolado y autoadministrado tradicional a un entorno PaaS puede parecer un poco abrumador al principio. Como desarrollador de aplicaciones o DBA, deseará conocer las capacidades básicas de la plataforma que le ayudarán a mantener la disponibilidad, el rendimiento, la seguridad y la resistencia de la aplicación. Ese es precisamente el objetivo de este artículo. El artículo organiza brevemente los recursos y ofrece instrucciones sobre cómo usar mejor las funcionalidades clave de Azure SQL Database con bases de datos únicas y agrupadas para administrar y mantener la aplicación, que se ejecute de forma eficaz y lograr mejores resultados en la nube. Por lo general, el público al que va dirigido este artículo estará formado por personas que:

• Evalúan la migración de sus aplicaciones a Azure SQL Database (y modernizan así las suyas).
• Estén en proceso de migrar sus aplicaciones (escenario de migración en curso).
• Hayan completado recientemente la migración a Azure SQL Database (nuevo DBA en la nube).

En este artículo se tratan algunas de las características básicas de Azure SQL Database como una plataforma que puede aprovechar fácilmente al trabajar con bases de datos únicas y agrupadas en grupos elásticos. son los siguientes:

• Supervisión de bases de datos mediante el Portal de Azure
• Recuperación ante desastres y continuidad empresarial (BCDR)
• Seguridad y cumplimiento normativo
• Supervisión y mantenimiento inteligentes de la base de datos
• Movimiento de datos

Nota:

Microsoft Entra ID era conocido anteriormente como Azure Active Directory (Azure AD).

Supervisión de bases de datos mediante el Portal de Azure

En Azure Portal, puede supervisar el uso de una base de datos individual. Para ello, debe seleccionarla y hacer clic en el gráfico Supervisión. Al hacer esto, se abrirá la ventana Métrica que se puede cambiar haciendo clic en el botón Editar gráfico. Agregue las siguientes métricas:

• Porcentaje de CPU
• Porcentaje de DTU
• Porcentaje de E/S de datos
• Porcentaje de tamaño de base de datos

Una vez agregadas estas métricas, podrá verlas en el gráfico Supervisión con más información en la ventana Métrica. Las cuatro métricas muestran el porcentaje de uso medio, en relación con la DTU de la base de datos. Consulte los artículos sobre el modelo de compra basado en DTU y el modelo de compra basado en núcleo virtual para obtener más información sobre los niveles de servicio.

También se pueden configurar alertas en las métricas de rendimiento. Seleccione el botón Agregar alerta de la ventana Métrica. Siga el asistente para configurar la alerta. Tiene la opción de que se genere una alerta si la métrica supera un umbral determinado, o si no llega a él.

Por ejemplo, si espera que crezca la carga de trabajo de una base de datos, puede configurar una alerta por correo electrónico cada vez que la base de datos alcance el 80% en cualquiera de las métricas de rendimiento. Esto se puede usar como advertencia prematura para saber cuándo puede tener que cambiar al tamaño de proceso inmediatamente superior.

Las métricas de rendimiento también pueden ayudarle a determinar si puede cambiar a un tamaño de proceso inferior. Suponga que usa una base de datos Estándar S2 y todas las métricas de rendimiento muestran que, de media, la base de datos no usa más del 10 % en ningún momento. Es probable que la base de datos funcione bien en Estándar S1. Sin embargo, tenga en cuenta las cargas de trabajo que tienen picos o fluctúan antes de tomar la decisión de cambiar a un tamaño de proceso inferior.

Recuperación ante desastres y continuidad empresarial (BCDR)

Las capacidades de recuperación ante desastres y continuidad empresarial le permiten continuar con su actividad empresarial del modo habitual en caso de desastre. El desastre podría ser un evento de nivel de base de datos (por ejemplo, alguien elimina erróneamente una tabla de vital importancia) o un evento de nivel de centro de datos (una catástrofe regional, como un tsunami).

Cómo crear y administrar copias de seguridad en SQL Database

En Azure SQL Database no se crean copias de seguridad porque no es necesario. SQL Database realiza copias de seguridad de las bases de datos automáticamente por usted, por lo que ya no tiene que preocuparse de programar, realizar y administrar copias de seguridad. La plataforma realiza una copia de seguridad completa cada semana, una copia de seguridad diferencial cada pocas horas y una copia de seguridad de registro cada 5 minutos para garantizar que la recuperación ante desastres sea eficaz y la pérdida de datos mínima. La primera copia de seguridad completa se realiza cuando se crea una base de datos. Estas copias de seguridad están disponibles durante un período determinado denominado "período de retención", que varía según el nivel de servicio que elija. SQL Database proporciona la capacidad de restaurar a un momento dado dentro de este período de retención mediante la recuperación a un momento dado (PITR).

Nivel de servicio	Período de retención en días
Básico	7
Estándar	35
Premium	35

Además, la característica de retención a largo plazo (LTR) permite mantener archivos de copia de seguridad durante un período de tiempo mucho mayor (hasta 10 años) y restaurar los datos a partir de estas copias de seguridad en cualquier momento de dicho período. Además, las copias de seguridad de base de datos se mantienen en almacenamientos con replicación geográfica para garantizar la resistencia ante una catástrofe regional. También puede restaurar estas copias de seguridad en cualquier región de Azure en cualquier momento dentro del período de retención. Para más información, consulta Introducción a la continuidad empresarial.

Cómo se garantiza la continuidad empresarial en caso de un desastre en el nivel de centro de datos o una catástrofe regional

Las copias de seguridad de base de datos se almacenan en almacenamiento con replicación geográfica para garantizar que, durante un caso de desastre regional, puedas restaurar la copia de seguridad en otra región de Azure. Esto se denomina restauración geográfica. El RPO (objetivo de punto de recuperación) para la restauración geográfica suele ser inferior a < 1 hora y el ERT (tiempo estimado de recuperación), de algunos minutos a horas.

En el caso de las bases de datos críticas, Azure SQL Database ofrece replicación geográfica activa, que crea una copia secundaria con replicación geográfica de la base de datos original en otra región. Por ejemplo, si la base de datos se hospeda inicialmente en la región Oeste de EE. UU. de Azure y quiere resiliencia ante desastres regionales, crea una réplica geográfica activa de la base de datos desde Oeste de EE. UU. para Este de EE. UU. Cuando se produzca el desastre en la región Oeste de EE. UU., puedes conmutar por error a la región Este de EE. UU.

Además de la replicación geográfica activa, los grupos de conmutación por error proporcionan una manera cómoda de administrar la replicación y la conmutación por error de un grupo de bases de datos. Puedes crear un grupo de conmutación por error que contenga varias bases de datos en las mismas regiones o en diferentes regiones. A continuación, puedes iniciar una conmutación por error de todas las bases de datos del grupo de conmutación por error en la región secundaria. Para más información, consulta Grupos de conmutación por error.

Para lograr resistencia para errores de centro de datos o zona de disponibilidad, asegúrate de que la redundancia de zona está habilitada para la base de datos o el grupo elástico.

Supervisa activamente la aplicación para que se produzca un desastre e inicia una conmutación por error a la región secundaria. Puede crear hasta cuatro réplicas geográficas activas de este tipo en diferentes regiones de Azure. Aún es mejor. También puede obtener acceso de solo lectura a estas réplicas geográficas activas secundarias. Esto resulta muy útil para reducir la latencia de un escenario de aplicación distribuida geográficamente.

¿Qué aspecto tiene la recuperación ante desastres con SQL Database?

La configuración y la administración de la recuperación ante desastres se pueden realizar con tan solo unos clics en Azure SQL Database al usar la replicación geográfica activa o los grupos de conmutación por error. Todavía tendrás que supervisar la aplicación y la base de datos en busca de cualquier desastre regional y conmutar por error a la región secundaria para restaurar la continuidad empresarial.

Para obtener más información, consulta Introducción a la recuperación ante desastres de Azure SQL Database.

Seguridad y cumplimiento normativo

SQL Database se toma la seguridad y la privacidad muy en serio. La seguridad en SQL Database está disponible en el nivel de base de datos y en el nivel de plataforma, y se entiende mejor cuando se clasifica por categorías en varias capas. Cada capa le proporciona seguridad óptima para su aplicación y le permite controlarla. Las capas son:

• Identidad y autenticación (autenticación de SQL y autenticación con Microsoft Entra ID [anteriormente Azure Active Directory]).
• Supervisión de la actividad (Auditoría y detección de amenazas).
• Protección de datos reales (Cifrado de datos transparente [TDE] y Always Encrypted [AE]).
• Control del acceso a datos confidenciales y con privilegios (seguridad de nivel de fila y Enmascaramiento dinámico de datos).

Microsoft Defender para la nube ofrece administración de seguridad centralizada de todas las cargas de trabajo que se ejecutan en Azure, de forma local y en otras nubes. Puede ver si se han configurado en todos los recursos elementos de protección esenciales de SQL Database como la auditoría y el Cifrado de datos transparente [TDE], y crear directivas basadas en sus propios requisitos.

Qué métodos de autenticación de usuario se ofrecen en SQL Database

En SQL Database, se ofrecen dos métodos de autenticación:

• Autenticación de Microsoft Entra
• Autenticación de SQL

No se admite la autenticación de Windows. Microsoft Entra ID es un servicio de administración centralizada de identidades y accesos. Con esto puede proporcionar cómodamente un acceso de inicio de sesión único (SSO) al personal de su organización. Esto significa que las credenciales se comparten entre todos los servicios de Azure, lo que simplifica la autenticación.

Microsoft Entra ID admite la autenticación multifactor y se puede integrar fácilmente con Windows Server Active Directory. Esto también permite que SQL Database y Azure Synapse Analytics ofrezcan la autenticación multifactor y cuentas de usuario de invitado en un dominio de Microsoft Entra. Si ya usa una instancia de Active Directory en el entorno local, puede federarla con Microsoft Entra ID para extender su directorio a Azure.

La autenticación de SQL solo admite el nombre de usuario y la contraseña para autenticar a los usuarios en cualquier base de datos de un servidor determinado.

Si usted...	SQL Database / Azure Synapse Analytics
Ha utilizado AD en SQL Server local	Federe AD con Microsoft Entra ID y use la autenticación de Microsoft Entra. La federación le permite usar el inicio de sesión único.
Necesita aplicar la autenticación multifactor	Exija la autenticación multifactor como directiva mediante el acceso condicional de Microsoft y use la autenticación multifactor de Microsoft Entra.
Ha iniciado sesión en Windows con sus credenciales de Microsoft Entra desde un dominio federado	Utilice la autenticación integrada de Microsoft Entra.
Ha iniciado sesión en Windows con sus credenciales desde un dominio no federado con Azure	Utilice la autenticación integrada de Microsoft Entra.
Tiene servicios de nivel intermedio que necesitan conectarse a SQL Database o Azure Synapse Analytics	Utilice la autenticación integrada de Microsoft Entra.
Tener un requisito técnico para usar la autenticación de SQL	Use autenticación de SQL

Cómo se limita o controla el acceso de conectividad a mi base de datos

Existen varias técnicas a su disposición que podría utilizar para alcanzar la organización óptima de la conectividad para su aplicación.

• Reglas de firewall
• Puntos de conexión de servicio de red virtual
• Direcciones IP reservadas

Firewall

Un firewall impide el acceso al servidor desde una entidad externa al permitir que solo entidades específicas accedan al servidor. De forma predeterminada, todas las conexiones a las bases de datos del servidor están prohibidas, excepto (de manera opcional) las conexiones que proceden de otros servicios de Azure. Con una regla de firewall puede abrir el acceso al servidor únicamente a las entidades (por ejemplo, una máquina de desarrollador) que apruebe al permitir la dirección IP de ese equipo a través del firewall. También permite especificar un intervalo de direcciones IP al que quiere permitir el acceso al servidor. Por ejemplo, las direcciones IP de una máquina de desarrollador de su organización pueden agregarse a la vez mediante la especificación de un intervalo en la página Configuración del firewall.

Puede crear reglas de firewall en el nivel de servidor o el nivel de base de datos. Las reglas de firewall de IP en el nivel de servidor pueden crearse mediante Azure Portal o con SSMS. Para más información acerca de cómo configurar una regla de firewall en el nivel de servidor y en el de base de datos, consulte el tema sobre la creación de reglas de firewall de IP en SQL Database.

Puntos de conexión del servicio

De forma predeterminada, su base de datos está configurada para "Permitir que los servicios y recursos de Azure accedan a este servidor", lo que significa que todas las máquinas virtuales de Azure pueden intentar conectarse a su base de datos. Estos intentos siguen teniendo que autenticarse. Si no desea que la base de datos sea accesible para las direcciones IP de Azure, puede deshabilitar "Permitir que los servicios y recursos de Azure accedan a este servidor". Asimismo, puede configurar puntos de conexión de servicio de red virtual.

Los puntos de conexión de servicio (SE) le permiten exponer los recursos críticos de Azure solo a su propia red privada virtual en Azure. Al hacerlo, básicamente se elimina el acceso público a sus recursos. El tráfico entre su red virtual y Azure se mantiene en la red troncal de Azure. Sin SE obtendrá un enrutamiento de paquetes de tunelización forzada. La red virtual fuerza el tráfico de Internet a su organización y el tráfico del servicio de Azure para que sigan la misma ruta. Con los puntos de conexión de servicio, puede optimizar esto, ya que los paquetes fluyen directamente de la red virtual al servicio en la red troncal de Azure.

Direcciones IP reservadas

Otra opción es aprovisionar direcciones IP reservadas para las máquinas virtuales e incluir esas direcciones IP específicas de las máquinas virtuales en la configuración de firewall del servidor. Mediante la asignación de direcciones IP reservadas, se evita el problema de tener que actualizar las reglas del firewall con el cambio de direcciones IP.

A qué puerto debo conectarme en SQL Database

Puerto 1433. SQL Database se comunica a través de este puerto. Para conectarse desde una red corporativa, tiene que agregar una regla de salida en la configuración del firewall de su organización. Como norma, evite exponer el puerto 1433 fuera del límite de Azure.

Cómo puedo supervisar y regular la actividad en mi servidor y mi base de datos en SQL Database

Auditoría de SQL Database

Con SQL Database, puede activar la auditoría para realizar el seguimiento de los eventos de base de datos. La auditoría de SQL Database registra eventos de base de datos y los escribe en un archivo de registro de auditoría en su cuenta de Azure Storage. La auditoría es especialmente útil si desea obtener información sobre posibles infracciones de seguridad y directivas, mantener el cumplimiento normativo, etc. Permite definir y configurar determinadas categorías de eventos que cree que necesitan auditoría y, en función de ello, puede obtener informes preconfigurados y un panel para obtener una visión general de los eventos que se producen en la base de datos. Puede aplicar estas directivas de auditoría en el nivel de base de datos o en el nivel de servidor. Para obtener instrucciones sobre cómo activar la auditoría para el servidor o la base de datos, vea: Habilitación de la auditoría de SQL Database.

Detección de amenazas

Con la detección de amenazas, obtendrá la capacidad de actuar fácilmente sobre las infracciones de seguridad o directivas que la auditoría detecte. No es necesario ser un experto en seguridad para resolver posibles amenazas o infracciones en el sistema. La detección de amenazas también tiene algunas capacidades integradas, como la detección de SQL Injection. SQL Injection es un intento de modificar o poner en peligro los datos y una manera bastante común de atacar una aplicación de base de datos en general. La detección de amenazas ejecuta varios conjuntos de algoritmos que detectan posibles vulnerabilidades y ataques de inyección de SQL, así como patrones de acceso de base de datos anómalos (por ejemplo, el acceso desde una ubicación inusual o una entidad de seguridad desconocida). Los responsables de seguridad u otros administradores designados reciben una notificación por correo electrónico si se detecta una amenaza en la base de datos. Cada notificación proporciona detalles de la actividad sospechosa y recomendaciones acerca de cómo investigar más y mitigar la amenaza. Para obtener información sobre cómo activar la detección de amenazas, consulte: Habilitar la detección de amenazas.

Cómo puedo proteger mis datos en general en SQL Database

El cifrado proporciona un mecanismo seguro para proteger los datos confidenciales de los intrusos. Los datos cifrados son inútiles para el intruso sin la clave de descifrado. Por lo tanto, agrega una capa de protección adicional sobre las capas de seguridad existentes integradas en SQL Database. Existen dos aspectos sobre la protección de datos en SQL Database:

• Sus datos en reposo en archivos de datos y de registro
• Sus datos en curso

De forma predeterminada, en SQL Database, los datos en reposo de los archivos de datos y de registro en el subsistema de almacenamiento siempre están completamente cifrados a través del Cifrado de datos transparente [TDE]. También se cifran las copias de seguridad. Con TDE, no existen cambios necesarios en la aplicación que accede a estos datos. El cifrado y el descifrado se producen de forma transparente, de ahí el nombre. Para proteger los datos confidenciales en curso y en reposo, SQL Database proporciona una característica denominada Always Encrypted (AE). AE es una forma de cifrado en el cliente que cifra las columnas confidenciales de la base de datos (para lo que están en texto cifrado para los administradores de la base de datos y los usuarios no autorizados). El servidor recibe los datos cifrados con los que comenzar. La clave de Always Encrypted también se almacena en el lado del cliente, de modo que solo los clientes autorizados pueden descifrar las columnas confidenciales. Los administradores del servidor y de los datos no pueden ver los datos confidenciales, ya que las claves de cifrado se almacenan en el cliente. AE cifra las columnas confidenciales de la tabla de extremo a extremo, desde los clientes no autorizados hasta el disco físico. AE admite comparaciones de igualdad en la actualidad, por lo que los DBA pueden seguir consultando las columnas cifradas como parte de los comandos SQL. Always Encrypted puede utilizarse con diversos almacenes de claves, como Azure Key Vault, el almacén de certificados de Windows y módulos de seguridad de hardware local.

Características	Always Encrypted	Cifrado de datos transparente
Cifrado	Completa	Datos en reposo
El servidor puede acceder a datos confidenciales	No	Sí, ya que el cifrado es para los datos en reposo
Operaciones permitidas de T-SQL	Comparación de igualdad	Toda el área expuesta de T-SQL está disponible
Cambios de aplicación necesarios para usar la característica	mínimo	Muy mínimo
Granularidad de cifrado	Nivel de columna	Nivel de base de datos

Cómo se limita el acceso a la información confidencial en mi base de datos

Cada aplicación tiene cierta información confidencial en la base de datos debe protegerse para que no sea visible para todos los usuarios. Determinados empleados de la organización necesitan ver estos datos, pero otros no deberían poder verlos. Un ejemplo es el salario de los empleados. Aunque un administrador debe poder acceder a la información de salario de sus subordinados directos, los miembros del equipo individuales no deben tener acceso a la información de salario de sus compañeros. Otro escenario es el de los desarrolladores de datos, que pueden interactuar con datos confidenciales durante las fases de desarrollo o pruebas, por ejemplo, los números de la seguridad social de los clientes. Una vez más, no es necesario exponer esta información a los desarrolladores. En estos casos, los datos confidenciales deben enmascararse o no exponerse en absoluto. SQL Database ofrece dos enfoques para impedir que usuarios no autorizados puedan ver datos confidenciales:

Enmascaramiento dinámico de datos es una característica de enmascaramiento de datos que permite limitar la exposición de información confidencial ocultándola a los usuarios sin privilegios en el nivel de aplicación. Debe definir una regla de enmascaramiento que pueda crear un patrón de enmascaramiento (por ejemplo, mostrar solo los cuatro últimos dígitos de un número del seguro social de identificación nacional: XXX-XX-0000 y marcar la mayoría como Xs) e identificar qué usuarios se excluirán de la regla de enmascaramiento. El enmascaramiento ocurre sobre la marcha y hay varias funciones de enmascaramiento disponibles para las distintas categorías de datos. El enmascaramiento dinámico de datos permite detectar datos confidenciales en la base de datos y aplicarles el enmascaramiento automáticamente.

La seguridad de nivel de fila le permite controlar el acceso en el nivel de fila. Esto quiere decir que determinadas filas de una tabla de base de datos se ocultan en función del usuario que ejecuta la consulta (pertenencia a un grupo o contexto de ejecución). La restricción de acceso se realiza en el nivel de base de datos en lugar de en una capa de aplicación para simplificar la lógica de la aplicación. Para empezar, debe crear un predicado de filtro y filtrar las filas que no se muestran y la directiva de seguridad. A continuación, debe definir quién tiene acceso a estas filas. Por último, el usuario final ejecuta la consulta y, en función de los privilegios del usuario, ve esas filas restringidas o no puede verlas.

Cómo se administran las claves de cifrado en la nube

Hay opciones de administración de claves para Always Encrypted (cifrado de cliente) y el Cifrado de datos transparente (cifrado en reposo). Se recomienda la rotación periódica de las claves de cifrado. La frecuencia de rotación debe alinearse con la normativa y con los requisitos de cumplimiento internos de la organización.

Cifrado de datos transparente (TDE)

Hay una jerarquía de dos claves en TDE: los datos de cada base de datos del usuario se cifran mediante una clave de cifrado única para la base de datos AES-256 simétrica (DEK), que a su vez se cifra con una clave maestra RSA 2048 asimétrica única para el servidor. La clave maestra se puede administrar de las siguientes maneras:

• Automáticamente a través de la plataforma: SQL Database.
• Mediante Azure Key Vault como el almacén de claves.

De forma predeterminada, el servicio SQL Database administra la clave maestra de Cifrado de datos transparente para su comodidad. Si la organización quiere tener control sobre la clave maestra, existe la opción de usar Azure Key Vault como el almacén de claves. Al usar Azure Key Vault, su organización asume el control sobre el aprovisionamiento de claves, la rotación y el control de permisos. La rotación o cambio del tipo de una clave maestra TDE es rápida, ya que solo se vuelve a cifrar la DEK. Para organizaciones con separación de roles entre la seguridad y la administración de datos, un administrador de seguridad puede aprovisionar el material de clave para la clave maestra TDE en Azure Key Vault y proporcionar un identificador de Azure Key Vault al administrador de base de datos que se usará para el cifrado en reposo en un servidor. Key Vault está diseñado de modo que Microsoft no pueda ver ni extraer ninguna de sus claves de cifrado. También obtiene una administración centralizada de claves para su organización.

Always Encrypted

También hay una jerarquía de dos claves en Always Encrypted; una columna de datos confidenciales se cifra mediante una clave de cifrado de 256 columnas (CEK) AES, que a su vez se cifra con una clave maestra de columna (CMK). Los controladores de cliente proporcionados para Always Encrypted no tienen limitaciones en la longitud de las claves CMK. El valor cifrado de la CEK se almacena en la base de datos y la CMK se almacena en un almacén de claves de confianza, como el almacén de certificados de Windows, Azure Key Vault o un módulo de seguridad de hardware.

• Tanto la CEK como la CMK se pueden rotar.
• La rotación de la CEK es una operación de tamaño de datos, que puede llevar mucho tiempo en función del tamaño de las tablas que contienen las columnas cifradas. Por lo tanto, es recomendable planear las rotaciones de la CEK en consecuencia.
• No obstante, la rotación de CMK no interfiere con el rendimiento de la base de datos y puede hacerse con roles separados.

El diagrama siguiente muestra las opciones de almacén de claves para las claves maestras de columna en Always Encrypted

Cómo puedo optimizar y proteger el tráfico entre mi organización y SQL Database

El tráfico de red entre su organización y SQL Database suele enrutarse a través de la red pública. Sin embargo, si decide optimizar esta ruta de acceso y hacerla más segura, puede explorar Azure ExpressRoute. ExpressRoute le permite esencialmente ampliar la red corporativa a la plataforma de Azure a través de una conexión privada. Al hacerlo, no pasa por la red pública de Internet. También obtiene mayores niveles de seguridad, confiabilidad y optimización de enrutamiento, lo que se traduce en menores latencias de red y velocidades mucho más rápidas de lo que experimentaría normalmente a través de la red pública de Internet. Si piensa transferir un fragmento de datos importante entre su organización y Azure, el uso de ExpressRoute puede proporcionarle ventajas económicas. Puede elegir entre tres modelos de conectividad diferentes para la conexión de su organización a Azure:

• Colocación de intercambio en la nube
• Conexión universal
• Conexión de punto a punto

ExpressRoute permite ampliar el límite de ancho de banda que adquiere hasta el doble sin ningún cargo adicional. También es posible configurar conectividad entre regiones mediante ExpressRoute. Para ver una lista de proveedores de conectividad de ExpressRoute, consulte: Asociados de ExpressRoute y ubicaciones de emparejamiento. En los artículos siguientes se describe ExpressRoute con más detalle:

• Introducción a Express Route
• Requisitos previos
• Flujos de trabajo

SQL Database cumple con los requisitos de regulación y cómo ayuda eso con el cumplimiento de mi propia organización

SQL Database cumple con un gran número de regulaciones de cumplimiento. Para ver el conjunto más reciente de cumplimientos que ha realizado SQL Database, visite Microsoft Trust Center y profundice en los cumplimientos importantes para su organización, con el fin de ver si SQL Database se incluye en los servicios de Azure compatibles. Es importante tener en cuenta que aunque SQL Database puede estar certificada como un servicio conforme, contribuye al cumplimiento del servicio en la organización pero no lo garantiza automáticamente.

Supervisión y mantenimiento inteligentes de la base de datos después de la migración

Una vez que se ha migrado la base de datos a SQL Database, su objetivo será supervisar la base de datos (por ejemplo, comprobar el uso de los recursos o realizar comprobaciones de DBCC) y realizar un mantenimiento regular (por ejemplo, volver a generar o reorganizar índices, estadísticas, etc.). Afortunadamente, SQL Database es inteligente en el sentido de que usa las tendencias históricas y las métricas y estadísticas registradas para ayudarle de manera proactiva a supervisar y mantener la base de datos, de modo que su aplicación siempre se ejecute de forma óptima. En algunos casos, Azure SQL Database puede realizar automáticamente las tareas de mantenimiento en función de la configuración. Existen tres facetas para la supervisión de la base de datos en SQL Database:

• Supervisión y optimización del rendimiento.
• Optimización de la seguridad.
• Optimización de los costos.

Supervisión y optimización del rendimiento

con la información de rendimiento de consultas, puede obtener recomendaciones adaptadas para la carga de trabajo de la base de datos, de modo que sus aplicaciones puedan seguir funcionando siempre con un nivel óptimo. También se puede configurar para que estas recomendaciones se apliquen automáticamente y no tenga que preocuparse de realizar tareas de mantenimiento. Con SQL Database Advisor, puede implementar automáticamente las recomendaciones de índices en función de la carga de trabajo, lo que se conoce como ajuste automático. Las recomendaciones evolucionan junto con los cambios de la carga de trabajo de las aplicaciones para proporcionarle sugerencias más relevantes. También tienen la opción de revisar estas recomendaciones manualmente y aplicarlas a su entera discreción.

Optimización de la seguridad

SQL Database proporciona recomendaciones de seguridad accionables para ayudarle a proteger sus datos, así como detección de amenazas para identificar e investigar actividades sospechosas de la base de datos que puedan suponer una amenaza para la base de datos. Evaluación de vulnerabilidades es un servicio de examen e informes de la base de datos que le permite supervisar el estado de seguridad de las bases de datos a escala e identificar los riesgos de seguridad y desfase respecto a una línea de base de seguridad definida por el usuario. Después de cada examen, se proporciona una lista personalizada de pasos procesables y scripts de corrección, así como un informe de evaluación que puede usarse para ayudar a cumplir con los requisitos de cumplimiento.

Con Microsoft Defender para la nube, debe identificar las recomendaciones de seguridad en todos los ámbitos y aplicarlas rápidamente.

Optimización de costos

la plataforma Azure SQL analiza el historial de uso en las bases de datos de un servidor para evaluar y recomendarle opciones de optimización de costos. Este análisis suele tardar unas dos semanas en analizar y generar recomendaciones accionables. Un grupo elástico es una de esas opciones. La recomendación aparece en el portal como un banner:

También puede ver este análisis en la sección "Advisor":

Cómo se supervisa el rendimiento y la utilización de recursos en SQL Database

En SQL Database puede aprovechar la información inteligente de la plataforma para supervisar el rendimiento y ajustarlo en consecuencia. Puede supervisar el rendimiento y la utilización de recursos en SQL Database utilizando los métodos siguientes:

Azure portal

Azure Portal muestra el uso de una base de datos al seleccionar la base de datos y hacer clic en el gráfico del panel Información general. Puede modificar el gráfico para mostrar varias métricas, incluido el porcentaje de CPU, el porcentaje de DTU, el porcentaje de E/S de datos, el porcentaje de las sesiones y el porcentaje de tamaño de base de datos.

En este gráfico también puede configurar alertas por recurso. Estas alertas le permiten responder a condiciones de los recursos con un correo electrónico, escribir a un punto de conexión HTTP/HTTPS o realizar una acción. Para más información, consulte Creación de alertas.

Vistas de administración dinámica

puede consultar la vista de administración dinámica sys.dm_db_resource_stats para devolver el historial de estadísticas de consumo de recursos de la última hora y la vista de catálogo del sistema sys.resource_stats para devolver el historial de los catorce últimos días.

Información de rendimiento de consultas

Información de rendimiento de consultas le permite ver un historial de las consultas de consumo de recursos principales y las consultas de larga ejecución para una base de datos específica. Puede identificar rápidamente las principales consultas por la utilización de recursos, la duración y la frecuencia de ejecución. Puede realizar un seguimiento de las consultas y detectar la regresión. Esta característica requiere que Almacén de consultas esté habilitado y activo para la base de datos.

Azure SQL Analytics (versión preliminar) en registros de Azure Monitor

Los registros de Azure Monitor permiten recopilar y visualizar las métricas de rendimiento clave de Azure SQL Database, que admiten hasta 150 000 instancias de bases de datos y 5000 grupos elásticos de SQL por área de trabajo. Puede utilizarlo para supervisar y recibir notificaciones. Puede supervisar SQL Database y las métricas de los grupos elásticos de varias suscripciones de Azure y puede utilizar los grupos elásticos para identificar problemas en cada capa de un pila de aplicación.

Estoy observando problemas de rendimiento: En qué se diferencia la metodología para solucionar problemas de SQL Database de la de SQL Server

Una parte importante de las técnicas de solución de problemas que usaría para el diagnóstico de problemas de rendimiento de la base de datos y de las consultas siguen siendo la misma. Después de todo, el mismo motor de base de datos alimenta la nube. Sin embargo, la plataforma (Azure SQL Database) cuenta con "inteligencia" integrada. Puede ayudarle a solucionar problemas y a diagnosticar problemas de rendimiento aún más fácilmente. Puede realizar algunas de estas acciones correctivas en su nombre y, en algunos casos, corregirlas de forma proactiva automáticamente.

El enfoque para solucionar problemas de rendimiento puede suponer una ventaja considerable si se usan características inteligentes, como Información de rendimiento de consultas (QPI) y Database Advisor, juntas de modo que la diferencia de la metodología varíe en ese aspecto (ya no necesita hacer el trabajo manual de pulir los detalles esenciales que pueden ayudarle a solucionar el problema en cuestión). La plataforma hace el trabajo duro por usted. Un ejemplo de ello es QPI. Con QPI, puede profundizar hasta el nivel de consulta y examinar las tendencias históricas, así cómo averiguar cuándo se produjo exactamente la regresión de la consulta. Database Advisor le ofrece recomendaciones sobre aspectos que pueden ayudarle a mejorar el rendimiento general, como la falta de índices, la pérdida de índices, la parametrización de las consultas, etc.

Con la solución de problemas de rendimiento, es importante identificar si es solo la aplicación o la base de datos que la respalda, lo que influye en el rendimiento de la aplicación. A menudo el problema de rendimiento se encuentra en el nivel de aplicación. Puede ser la arquitectura o el patrón de acceso a datos. Por ejemplo, supongamos que tiene una aplicación con un exceso de intercambio de información que es sensible a la latencia de red. En este caso, la aplicación sufre porque habrá muchas solicitudes devueltas y enviadas ("exceso de intercambio de información") entre la aplicación y el servidor y, en una red congestionada, estas idas y venidas aumentan muy rápido. Para mejorar el rendimiento en este caso, puede usar consultas por lotes. El uso de lotes resulta de gran ayuda porque ahora sus solicitudes se procesan en un lote; ello le ayuda a reducir la latencia de ida y vuelta, y mejora el rendimiento de la aplicación.

Asimismo, si observa una degradación del rendimiento general de la base de datos, puede supervisar las vistas de administración dinámica sys.dm_db_resource_stats y sys.resource_stats para comprender el consumo de CPU, E/S y memoria. El rendimiento puede verse afectado porque la base de datos tiene escasez de recursos. Es posible que necesite cambiar el tamaño de proceso o el nivel de servicio en función de las peticiones de carga de trabajo que se expanden o contraen.

Para obtener un conjunto completo de recomendaciones para ajustar los problemas de rendimiento, consulte el tema sobre el ajuste de la base de datos.

¿Cómo me aseguro de que estoy usando el nivel de servicio y el tamaño de proceso adecuados?

SQL Database ofrece varios niveles de servicio: Básico, Estándar y Premium. Con cada nivel de servicio obtiene un rendimiento predecible garantizado asociado a ese nivel de servicio. En función de la carga de trabajo, puede que tenga ráfagas de actividad donde el uso de recursos podría alcanzar el techo del tamaño de proceso actual en el que se encuentra. En tales casos, resulta útil empezar evaluando si los ajustes pueden ser de ayuda (por ejemplo, agregar o modificar un índice). Si sigue teniendo problemas de límite, considere la posibilidad de cambiar a un nivel de servicio o tamaño de proceso superior.

Nivel de servicio	Escenarios de casos de uso comunes
Basic	Aplicaciones con pocos usuarios y una base de datos que no tienen grandes requisitos de simultaneidad, escalabilidad y rendimiento.
Estándar	Aplicaciones con requisitos de simultaneidad, escalabilidad y rendimiento considerables, y una demanda de E/S de baja a media.
Premium	Aplicaciones con una gran cantidad de usuarios simultáneos, y altas demandas de CPU/memoria y E/S. Las aplicaciones confidenciales con una alta latencia, un alto rendimiento y una alta simultaneidad pueden usar el nivel Premium.

Para asegurarse de que se encuentra en el tamaño de proceso adecuado, puede supervisar el consumo de recursos de consulta y base de datos a través de uno de los métodos mencionados anteriormente en "¿Cómo se supervisa el rendimiento y la utilización de recursos en SQL Database?". Si encuentra que sus consultas o bases de datos se ejecutan constantemente con un alto consumo de CPU/memoria, etc., puede considerar la posibilidad de escalar verticalmente a un tamaño de proceso superior. De forma similar, si observa que, incluso durante las horas de máxima actividad, no usa tantos recursos, considere la posibilidad de reducir verticalmente desde el tamaño de proceso actual.

Si tiene un patrón de aplicación de SaaS o un escenario de consolidación de bases de datos, considere la posibilidad de usar un grupo elástico para optimizar los costos. Un grupo elástico es una excelente manera de lograr la consolidación de bases de datos y la optimización de costos. Para obtener más información sobre cómo administrar varias bases de datos mediante un grupo elástico, consulte: administración de grupos y bases de datos.

Con qué frecuencia es necesario ejecutar comprobaciones de integridad de base de datos en mi base de datos

SQL Database utiliza algunas técnicas inteligentes que permiten controlar ciertas clases de datos dañados automáticamente y sin pérdida de datos. Estas técnicas se han integrado en el servicio, que las usa cuando es necesario. De forma regular, se prueban las copias de seguridad de la base de datos en el servicio, para lo cual se restauran y se ejecuta DBCC CHECKDB en ellas. Si hay problemas, SQL Database los resuelve proactivamente. Reparación de página automática se usa para corregir páginas que están dañadas o que tienen problemas de integridad de datos. Las páginas de base de datos siempre se comprueban con el valor de SUMA DE COMPROBACIÓN predeterminado que comprueba la integridad de la página. SQL Database supervisa y revisa proactivamente la integridad de los datos de la base de datos y, si surgen problemas, los aborda con la prioridad más alta. Además, puede ejecutar sus propias comprobaciones de integridad como desee. Para más información, consulte Data Integrity in SQL Database (Integridad de datos en SQL Database).

Movimiento de datos después de la migración

Cómo se exportan e importan datos como archivos BACPAC desde SQL Database mediante Azure Portal

• Export: puede exportar su base de datos en Azure SQL Database como un archivo BACPAC desde Azure Portal.

  

• Import: también puede importar datos como un archivo BACPAC en la base de datos en Azure SQL Database mediante Azure Portal.

  

Cómo se pueden sincronizar los datos entre SQL Database y SQL Server

Hay varias maneras de conseguir este objetivo:

• Sincronización de datos : esta característica le ayuda a sincronizar los datos bidireccionalmente entre varias bases de datos de SQL Server y SQL Database. Para la sincronización con bases de datos de SQL Server, debe instalar y configurar el agente de sincronización en un equipo local o en una máquina virtual y abrir el puerto TCP de salida 1433.
• Replicación de transacciones : con la replicación de transacciones puede sincronizar sus datos de la base de datos de SQL Server a Azure SQL Database, de modo que la instancia de SQL Server es el publicador y Azure SQL Database es el suscriptor. Por ahora, solo se admite esta configuración. Para obtener más información sobre cómo migrar sus datos de la base de datos de SQL Server a Azure SQL con el tiempo de inactividad mínimo, consulte el tema sobre el uso de la replicación de transacciones.

Pasos siguientes

Obtenga información sobre SQL Database.