Preguntas frecuentes acerca de Instancia administrada de Azure SQL (P+F)

Para obtener una lista de las características admitidas en Instancia administrada de SQL, consulte Características de Instancia administrada de Azure SQL.

Para conocer las diferencias de sintaxis y comportamiento entre Instancia administrada de Azure SQL y SQL Server, consulte Diferencias de T-SQL de SQL Server.

Para conocer las características disponibles de hardware, consulte las diferencias técnicas en las configuraciones de hardware. Para ver los niveles de servicio disponibles y sus características, consulte las diferencias técnicas entre los niveles de servicio.

Cualquier cliente puede optar a cualquier nivel de servicio. Las ediciones Estándar y Enterprise que se tratan con Software Assurance se pueden intercambiar mediante la Ventaja híbrida de Azure (AHB) para el nivel de servicio De uso general (que incluye la actualización del nivel de servicio de uso general de nueva generación, actualmente en versión preliminar) o Crítico para la empresa mediante las siguientes relaciones de intercambio: 1 edición Estándar = 1 De uso general, 1 edición Enterprise = 1 Crítico para la empresa, 1 edición Enterprise = 4 De uso general y 4 De uso general = 1 edición Enterprise. Para obtener más información, consulte los derechos específicos de AHB.

Para ver la lista de tipos de suscripción admitidos, consulte Tipos de suscripción admitidos.

Las instancias administradas se pueden crear en la mayoría de las regiones de Azure. Consulte las regiones admitidas para SQL Managed Instance. Si necesita crear una instancia administrada en una región que no se admite actualmente, envíe una solicitud de soporte técnico a través de Azure Portal.

SQL Managed Instance tiene dos límites predeterminados: límite en el número de subredes que puede usar y límite en el número de núcleos virtuales que puede aprovisionar. Los límites varían entre tipos de suscripción y regiones. Para ver la lista de limitaciones de recursos regionales por tipo de suscripción, consulte la tabla de Limitaciones de recursos regionales. Estos son límites moderados que se pueden aumentar a petición. Si necesita aprovisionar más instancias administradas en sus regiones actuales, puede enviar una solicitud de soporte técnico para aumentar la cuota a través de Azure Portal. Para más información, consulte Solicitud de aumentos de cuota para Azure SQL Database.

El límite de 100 bases de datos por SQL Managed Instance es un límite fijo que no se puede cambiar en los niveles de servicio de uso general y crítico para la empresa. Puede tener hasta 500 bases de datos en el nivel de servicio de uso general de nueva generación.

Puede considerar la posibilidad de migrar a otros tipos de Azure que se ajusten a su carga de trabajo: Hiperescala de Azure SQL Database o SQL Server en Azure Virtual Machines.

Puede considerar la po0sibilidad de migrar a las opciones optimizadas de memoria o CPU de SQL Server en Azure Virtual Machines o Azure SQL Database.

Para ver los defectos y los problemas conocidos, consulte Problemas conocidos.

Para ver características nuevas y en vista previa, consulte las Novedades.

Puede aprovisionar una instancia administrada desde Azure Portal, PowerShell, la CLI de Azure y las plantillas de ARM.

Sí, puede aprovisionar una instancia administrada en una suscripción existente si esa suscripción pertenece a los tipos de suscripción admitidos.

Se trata de una limitación actual del componente subyacente que comprueba el nombre de la subred con respecto a la expresión regular ^[a-zA-Z_][^\/:*?"<>|`'^]*(?<![.\s])$. Actualmente se admiten todos los nombres que pasan la expresión regular y son nombres de subred válidos.

Puede escalar la instancia administrada desde Azure Portal, PowerShell, la CLI de Azure o las plantillas de ARM.

Sí, puede hacerlo. Para obtener instrucciones, consulte Traslado de recursos entre regiones.

Puede eliminar instancias administradas desde Azure Portal, PowerShell, la CLI de Azure o las API REST de Resource Manager.

El tiempo esperado para crear una instancia administrada o cambiar los niveles de servicio (núcleos virtuales, almacenamiento) depende de varios factores. Consulte Operaciones de administración.

La restauración de cada base de datos se garantiza durante todo el período de retención definido, incluso las bases de datos que se crearon y, a continuación, se eliminaron después de tan solo unos segundos. Al crear, eliminar o restaurar una base de datos, se realizan copias de seguridad en intervalos de tiempo diferentes para conservar los datos, de tal manera que se puedan restaurar durante el período de retención especificado. Si se una base de datos se elimina antes de que se haya completado una operación de copia de seguridad, la operación de eliminación podría bloquearse con el siguiente error:

Message database 'backup_restore_db_lkg_native_restore' already exists. Choose a different database name.

Para evitar que se genere el error, compruebe el estado de la operación de eliminación antes de volver a crear una base de datos con el mismo nombre. Para obtener más información, consulte sys.dm_operation_status. Una vez que el estado de la operación indique Completado es posible restaurar o crear una base de datos que tenga el mismo nombre.

Es probable que el error se genere en los siguientes casos de uso:

• Si se eliminan varias bases de datos para crearlas de nuevo con el mismo nombre de forma consecutiva. Cuando se elimina una base de datos, se hace una copia de seguridad sincronizada de la parte final restante del registro de transacciones antes de que finalice la operación de eliminación, tal y como se muestra en la imagen:

  

  No es posible crear una base de datos con el mismo nombre hasta que se haga la copia de seguridad de la parte final del registro y la operación de eliminación finalice. El carácter secuencial de la operación de eliminación coloca las bases de datos eliminadas de forma consecutiva en una cola, lo que puede prolongar el proceso de eliminación de las bases de datos y retrasar la creación de bases de datos nuevas con el mismo nombre.

• Si una base de datos se restaura y descarta antes de finalizar una copia de seguridad completa. Cuando se restaura una base de datos, el primer paso del proceso consiste en utilizar una nueva copia de seguridad completa de la base de datos. Si el usuario intenta restaurar una base de datos y la elimina inmediatamente antes de que se complete la operación de copia de seguridad, no podrá eliminar la base de datos y crear otra base de datos con el mismo nombre hasta que la copia de seguridad completa finalice y la eliminación de la base de datos se lleve a cabo. En función del tamaño de la base de datos, la operación de copia de seguridad completa puede tardar horas.

Es posible que la suscripción no sea apta para la SQL Managed Instance gratuita. De lo contrario, hay un límite de una instancia gratuita por suscripción. Debe quitar una instancia gratis existente para crear otra. Si ha eliminado recientemente la instancia gratuita, el banner de la oferta gratuita tarda hasta una hora en volver a aparecer.

Es probable que se haya agotado el crédito del mes. Vaya a SQL Managed Instance en Azure Portal y compruebe el estado para ver si la instancia está en un estado detenido debido a créditos insuficientes.

Esta funcionalidad no está disponible actualmente.

Sí, puede restaurar una copia de seguridad automatizada desde Azure Storage o Restaurar una copia de seguridad de base de datos mediante SQL Server Management Studio (SSMS).

A pesar de las limitaciones de los recursos, SQL Managed Instance gratuita está diseñada para permitirle probar las cargas de trabajo sin ningún impacto. El rendimiento que experimenta al usar SQL Managed Instance gratuita es idéntico al rendimiento de una versión de producción de la instancia.

SQL Managed Instance gratuita ofrece 4 y 8 opciones de núcleo virtual. Si la empresa requiere una instancia de con más recursos, cree una SQL Managed Instance de pago completo.

Las opciones de copia de seguridad no se pueden cambiar para SQL Managed Instance gratuita.

Actualmente, la suscripción de Estudiante no es válida. Para las suscripciones aptas, revise los requisitos previos de la oferta de SQL Managed Instance gratuita.

No se admite el cambio de nombre de la instancia administrada.

Sí, se puede cambiar la zona DNS predeterminada .database.windows.net de SQL Managed Instance por la suya. Sin embargo, la parte del nombre de host de la instancia administrada de su FQDN debe seguir siendo la misma.

Para usar otra zona DNS en lugar de la predeterminada, por ejemplo, .contoso.com, haga lo siguiente:

• Use la herramienta de cliente de red de SQL Server (CliConfg) para definir un alias. Puede usar el nombre de host de la instancia administrada o el nombre de host de la instancia administrada seguido de un nombre de dominio personalizado. La herramienta CliConfg agrega aliases en el registro en "HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo" o "HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\ConnectTo", en función de si usa la versión de 64 bits (C:\Windows\System32\cliconfg.exe) o la versión de 32 bits (C:\Windows\SysWOW64\cliconfg.exe), para que pueda hacerlo utilizando la directiva de grupo o un script. Use ambos para asegurarse de que los programas de 32 y 64 bits puedan resolver el alias.
• Use el registro CNAME en DNS con el nombre de host de la instancia administrada que apunta a la FQDN de la instancia administrada. En este caso, se necesita TrustServerCertificate=TRUE cuando se usa la autenticación con Microsoft Entra ID (anteriormente Azure Active Directory).
• Use UN registro en DNS con el nombre de host de la instancia administrada que apunta a la dirección IP de la instancia administrada. No se recomienda usar la dirección IP, ya que puede cambiar sin previo aviso. En este caso, se necesita TrustServerCertificate=TRUE al usar la autenticación de Microsoft Entra.

Azure SQL Managed Instance ofrece los mismos niveles de rendimiento por proceso y por tamaño de almacenamiento que otras opciones de implementación de Azure SQL Database. Si desea consolidar los datos en una sola instancia o simplemente necesita una característica admitida exclusivamente en Instancia administrada de SQL, puede migrar los datos mediante la funcionalidad de exportación e importación (BACPAC). Estas son otras maneras de considerar la migración de SQL Database a SQL Managed Instance:

• Uso de un origen de datos externo
• Uso de SQLPackage
• Uso de BCP

Una opción es exportar una base de datos a un archivo BACPAC y, a continuación, importar dicho archivo. Este enfoque es aconsejable si la base de datos tiene menos de 100 GB.

La replicación transaccional se puede utilizar si todas las tablas de la base de datos tienen claves principales y no hay objetos OLTP en memoria en la base de datos.

Para migrar la instancia de SQL Server, vea Guía de SQL Server a Azure SQL Managed Instance.

Para obtener información sobre la migración desde otras plataformas, vea Guía de Azure Database Migration.

Para obtener una comparación del rendimiento entre una instancia administrada y SQL Server, un buen punto de partida es leer los procedimientos recomendados para la comparación de rendimiento entre la Instancia administrada de Azure SQL y SQL Server.

Consulte Causas clave de las diferencias de rendimiento entre SQL Managed Instance y SQL Server. El tamaño del archivo de registro de transacciones puede afectar al rendimiento de SQL Managed Instance de uso general. Para más información, consulte Impacto del tamaño del archivo de registro en el rendimiento de una instancia de uso general.

Puede optimizar el rendimiento de la instancia administrada con las opciones siguientes:

• Ajuste automático, que proporciona un alto rendimiento y cargas de trabajo estables gracias al ajuste continuo del rendimiento basado en la inteligencia artificial y el aprendizaje automático.
• OLTP en memoria, que mejora el rendimiento y la latencia en las cargas de trabajo de procesamiento transaccional y ofrece información empresarial más rápida.
• Aplicación de algunos de los procedimientos recomendados para el ajuste de aplicaciones y bases de datos.
• Si la carga de trabajo consta de muchas transacciones pequeñas, cambie el tipo de conexión de proxy a modo de redirección para obtener una latencia más baja y un rendimiento más alto.

Para mejorar el rendimiento en una instancia De uso general, considere la posibilidad de aumentar el tamaño del archivo de datos. Para optimizar el rendimiento del almacenamiento en una instancia De uso general, consulte Instrucciones sobre procedimientos recomendados de almacenamiento para el nivel De uso general.

Consulte Análisis de estadísticas de espera en SQL Managed Instance. Las estadísticas de espera son información que puede ayudarle a comprender por qué la duración de la consulta es larga e identificar las consultas que están a la espera de algo en el motor de base de datos.

Para ver todas las opciones posibles de supervisión y alerta sobre el consumo y el rendimiento de SQL Managed Instance, consulte la entrada de blog sobre opciones de supervisión de Azure SQL Managed Instance. Para ver la supervisión del rendimiento en tiempo real de SQL Managed Instance, consulte Supervisión de rendimiento en tiempo real para la Instancia administrada de Azure SQL.

Consulte Supervisión y ajuste del rendimiento.

Consulte Supervisión del rendimiento en tiempo real para Azure SQL Managed Instance.

Sí, se admite SQL Profiler en SQL Managed Instance. Para más información, consulte SQL Profiler. En su lugar, sin embargo, debe considerar eventos extendidos para la actividad de "seguimiento" con menos impacto en la instancia supervisada. Para obtener más información, consulte los eventos extendidos.

No, no se admite. Puede usar DMV y Almacén de consultas junto con SQL Profiler y XEvents para supervisar las bases de datos.

Consulte Supervisión del uso de CPU en SQL Server y Azure SQL.

Sí. Para obtener instrucciones, consulte Creación de alertas para SQL Managed Instance. Para más sugerencias y trucos, consulte el blog.

No, las métricas de alertas están disponibles solo para una instancia administrada. Las métricas de alertas para bases de datos individuales en una instancia administrada no están disponibles.

El tamaño de almacenamiento de Instancia administrada de SQL depende del nivel de servicio seleccionado (De uso general, de uso general de nueva generación o Crítico para la empresa). Para conocer las limitaciones de almacenamiento de estos niveles de servicio, consulte Límites de recursos.

La cantidad mínima de almacenamiento disponible de una instancia es de 32 GB. El almacenamiento se puede agregar en incrementos de 32 GB hasta el tamaño de almacenamiento máximo. Los primeros 32 GB son gratis.

Sí, puede comprar el almacenamiento de complementos, independientemente del proceso que tenga, hasta cierto punto. Consulte Tamaño máximo de almacenamiento reservado de instancia en la tabla.

Para optimizar el rendimiento del almacenamiento, consulte Procedimientos recomendados de almacenamiento en el nivel De uso general.

No, el almacenamiento de copia de seguridad no se deduce del espacio de almacenamiento de su instancia administrada. El almacenamiento de copia de seguridad es independiente del espacio de almacenamiento de la instancia y su tamaño no está limitado. El almacenamiento de copia de seguridad está limitado por el período de tiempo durante el que se conserva la copia de seguridad de las bases de datos de la instancia; se puede configurar en un total de 35 días. Para más información, consulte Copias de seguridad automatizadas.

Para seguir la realización de copias de seguridad automatizadas en una instancia de SQL Managed Instance, revise Supervisión de la actividad de copia de seguridad.

Sí, puede crear una copia de seguridad completa de solo copia en su instancia de Azure Blob Storage, pero solo se puede restaurar en la Instancia administrada. Para obtener información, vea Copias de seguridad de solo copia. Sin embargo, no es posible realizar copias de seguridad de solo copia si la base de datos está cifrada mediante TDE administrado por el servicio, ya que no se puede obtener acceso al certificado que se usa para el cifrado. En ese caso, use la característica de restauración a un momento dado para mover la base de datos a otra instancia administrada o cambie a una clave administrada por el cliente.

Sí, se admite y está disponible para las versiones de SQL Server 2005 y posteriores. Para usar la restauración nativa, cargue el archivo.bak en Azure Blob Storage y ejecute comandos T-SQL. Para obtener más información, consulte Restauración nativa desde la URL.

Sí, pero solo para SQL Server 2022, durante el período de soporte estándar de SQL Server 2022. Es posible que, en el futuro, se introduzcan algunas características en Azure SQL Managed Instance que requieran cambios en el formato de la base de datos, lo que hará que las copias de seguridad sean incompatibles con la versión más reciente de SQL Server. El acceso a este tipo de características requiere la participación explícita.

Las bases de datos del sistema no se replican en la instancia secundaria de un grupo de conmutación por error. Por lo tanto, los escenarios que dependen de objetos de las bases de datos del sistema son imposibles en la instancia secundaria, a menos que los objetos se creen manualmente en la secundaria. Para solucionar el problema, consulte el artículo Habilitación de escenarios que dependen de objetos de las bases de datos del sistema.

Las reglas NSG y UDR necesarias se documentan aquí, y el servicio las establece automáticamente. Tenga en cuenta que estas reglas son solo las únicas que necesitamos para mantener el servicio. Para conectarse a la instancia y usar diferentes características, deberá establecer reglas adicionales específicas de las características que necesita mantener.

SQL Managed Instance es responsable de establecer reglas en los puertos de administración. Esto se logra a través de la funcionalidad denominada configuración de subred asistida por servicio. El objetivo es garantizar un flujo ininterrumpido del tráfico de administración con el fin de cumplir un contrato de nivel de servicio.

Sí. Puede analizar el tráfico que llega a través del grupo de seguridad de red mediante la configuración de los registros de flujo de Network Watcher.

Sí. Después de aprovisionar una instancia administrada, puede establecer un NSG que controle el acceso de entrada al puerto 1433. Es aconsejable limitar su intervalo de IP tanto como sea posible.

No. No se admite por distintos motivos:

• El tráfico de enrutamiento que representa una respuesta a una solicitud de administración entrante sería asimétrico y no podría funcionar.
• El enrutamiento del tráfico a Azure Storage se vería afectado por las restricciones de rendimiento y latencia, por lo que de este modo no podremos ofrecer la calidad y disponibilidad de servicio esperadas.
• Estas configuraciones son propensas a errores y no son compatibles.

Sí. La manera más sencilla de lograrlo es agregar la regla 0/0 a una UDR asociada a la subred de instancia administrada para enrutar el tráfico a través de la NVA.

La subred debe tener un número de direcciones IP disponibles suficiente. Para determinar el tamaño de la subred de red virtual para SQL Managed Instance, consulte Determinación del tamaño e intervalo de subred necesarios para SQL Managed Instance.

En caso de que no haya suficientes direcciones IP en la subred donde se aprovisiona la instancia de SQL Managed Instance, cree una subred y mueva la instancia a ella. También se recomienda crear la nueva subred con más direcciones IP asignadas para que las operaciones de actualización futuras eviten situaciones similares. Obtenga información sobre cómo mover Azure SQL Managed Instance entre subredes.

No. Puede usar una subred vacía o una subred que ya contenga instancias administradas.

No si esta contiene instancias administradas. Se trata de una limitación de la infraestructura de redes de Azure. Solo se permite agregar espacio de direcciones adicional a una subred vacía.

Sí. Una instancia de SQL Managed Instance se puede mover a otra subred dentro de la misma red virtual o en una red virtual diferente mediante una conexión en línea. Obtenga información sobre cómo mover Azure SQL Managed Instance entre subredes.

No es necesario. Puede crear una red virtual para Azure SQL Managed Instance o configurar una red virtual existente para Azure SQL Managed Instance.

No. Actualmente no se admite la colocación de una instancia administrada en una subred que ya contiene otros tipos de recursos.

No se admite. El nombre de host de la instancia administrada se asigna al equilibrador de carga delante del clúster virtual de la instancia administrada. Puesto que un clúster virtual puede hospedar varias instancias administradas, no se puede enrutar una conexión a la instancia administrada adecuada sin especificar su nombre. Para más información sobre la arquitectura del clúster virtual de Instancia administrada de SQL, consulte Arquitectura de conectividad del clúster virtual.

Actualmente, solo los puntos de conexión privados a las instancias administradas garantizan direcciones IP estáticas.

En situaciones poco frecuentes pero necesarias, podríamos realizar una migración en línea de una instancia administrada a un nuevo clúster virtual o a un grupo de máquinas virtuales diferente dentro del clúster virtual, debido a los cambios en la pila de tecnología que pretenden mejorar la seguridad y confiabilidad del servicio. La migración a un nuevo grupo de máquinas virtuales o clúster virtual provoca el cambio de dirección IP que está asignada al nombre de host de la instancia administrada. El servicio de instancia administrada no solicita compatibilidad con direcciones IP estáticas y se reserva el derecho a cambiar la dirección IP sin previo aviso como parte de los ciclos de mantenimiento regular.

Por el motivo anterior, solo se debe obtener acceso a los puntos de conexión públicos y locales de red virtual a través de sus nombres de dominio asociados. No se recomienda para nada confiar en la inmutabilidad de las direcciones IP, ya que hacerlo puede provocar una falta de disponibilidad prolongada mientras el servicio es correcto.

Si necesita una dirección IP estática accesible desde fuera de la virtual network, puede implementar Azure Firewall con una dirección IP pública de front-end y configurar una regla NAT para traducir el tráfico entrante al punto de conexión privado de una instancia administrada. A continuación, configure la resolución DNS o configure alias de cliente para que los clientes SQL se conecten a la dirección IP pública del firewall a través del nombre de dominio completo de la instancia administrada.

Sí, se puede habilitar un punto de conexión público para permitir que el tráfico entrante desde Internet llegue a SQL Managed Instance. Para más información, consulte Use Instancia administrada de Azure SQL de forma segura con puntos de conexión públicos y Configuración de un punto de conexión público en Instancia administrada de Azure SQL.

No, el uso de un puerto personalizado no está disponible. En el caso de los puntos de conexión de redes virtuales, SQL Managed Instance usa el número de puerto predeterminado 1433, mientras que para los públicos, usa el 3342.

El emparejamiento de red virtual global (emparejamiento de VNet) y Azure Virtual WAN son métodos recomendados para conectar dos instancias administradas en regiones diferentes. El emparejamiento de circuito de ExpressRoute es una opción alternativa. Si ninguna opción es posible en su entorno, el único método de conectividad es una conexión VPN de sitio a sitio. Configuración de una VPN de sitio a sitio mediante Azure Portal, PowerShell o la CLI de Azure

La compatibilidad con el emparejamiento de red virtual global (emparejamiento de VNet) para clústeres virtuales recién creados se agregó a Azure SQL Managed Instance el 22 de septiembre de 2020. Por lo tanto, se admite el emparejamiento de redes virtuales para instancias administradas creadas en subredes vacías después del 22 de septiembre de 2020. En el caso de las instancias implementadas antes de esta fecha, la compatibilidad con el emparejamiento se limita a las redes de la misma región, debido a las restricciones del emparejamiento de red virtual global. Para obtener más información, consulte la sección correspondiente de Preguntas más frecuentes (P+F) acerca de Azure Virtual Network.

Para usar el emparejamiento de red virtual global con instancias creadas antes de septiembre del 2020, considere la posibilidad de configurar una ventana de mantenimiento o mover la instancia a una nueva subred, ya que cualquier opción moverá la instancia a un nuevo clúster virtual que admita el emparejamiento de red virtual global.

Consulte cómo comprobar si se admite el emparejamiento de red virtual global en el clúster virtual si fuera necesario.

Para mitigar los riesgos de filtración de datos, es aconsejable que los clientes apliquen un conjunto de valores y controles de seguridad:

• Activar el cifrado de datos transparente (TDE) en todas las bases de datos.
• Desactivar Common Language Runtime (CLR). Se recomienda hacerlo también en el entorno local.
• Use la autenticación de Microsoft Entra solamente.
• Acceder a la instancia con una cuenta de DBA con pocos privilegios.
• Configurar el acceso del jumpbox de JIT para la cuenta de sysadmin.
• Activar la auditoría de SQL e integrarla en los mecanismos de alerta.
• Active Detección de amenazas en el conjunto de Microsoft Defender para SQL.
• Aplique una directiva de punto de conexión de servicio a la subred para controlar el tráfico saliente a Azure Storage.
• CREATE EXTERNAL TABLE AS SELECT (CETAS) está deshabilitado de forma predeterminada. Para habilitar CETAS a través de la opción de configuración del servidor allowPolyBaseExport, consulte CREATE EXTERNAL TABLE AS SELECT (CETAS).

Sí. Vea Resolución de nombres DNS privados en Azure SQL Managed Instance.

Sí. Vea Resolución de nombres DNS privados en Azure SQL Managed Instance.

La configuración de la zona horaria se puede establecer la primera vez que se aprovisiona una instancia administrada. No se admite el cambio de zona horaria de una instancia administrada existente. Para más información, consulte las limitaciones de zona horaria.

Las soluciones alternativas incluyen la creación de una nueva instancia administrada con la zona horaria adecuada, y la posterior realización de una copia de seguridad y una restauración de forma manual, o lo que recomendamos, realizar una restauración a un momento dado entre instancias.

Sí, los clientes pueden crear inicios de sesión que sean miembros del rol sysadmin. Los clientes que asumen el privilegio sysadmin también asumen la responsabilidad de operar la instancia, lo que puede afectar negativamente al compromiso del contrato de nivel de servicio. Para agregar un inicio de sesión al rol de servidor sysadmin, vea Autenticación de Microsoft Entra.

Sí, Azure SQL Managed Instance admite Cifrado de datos transparente (TDE). Para obtener más información, consulte Cifrado de datos transparente para SQL Managed Instance.

Sí, el escenario de Azure Key Vault para BYOK está disponible para Azure SQL Managed Instance. Para obtener más información, consulte Cifrado de datos transparente con una clave administrada por el cliente.

Sí, puede hacerlo. Para migrar una base de datos de SQL Server cifrada, debe exportar e importar los certificados existentes en SQL Managed Instance y, después, realizar una copia de seguridad completa de la base de datos y restaurarla en Instancia administrada.

También puede usar Azure Database Migration Service para migrar las bases de datos cifradas de TDE.

Puede girar el protector de TDE de SQL Managed Instance mediante Azure Cloud Shell. Para obtener instrucciones, consulte Cifrado de datos transparente en SQL Managed Instance con su propia clave desde Azure Key Vault.

Sí, no es preciso descifrar la base de datos para poder restaurarla en Instancia administrada de SQL. Tiene que especificar la clave o el certificado utilizados como un protector de clave de cifrado en el sistema de origen a SQL Managed Instance para poder leer los datos desde el archivo de copia de seguridad cifrado. Existen dos formas posibles de hacerlo:

• Cargar el protector de certificado en SQL Managed Instance. Solo se puede hacer mediante PowerShell. El script de ejemplo describe todo el proceso.
• Cargar el protector de clave asimétrica en Azure Key Vault y apuntar SQL Managed Instance hacia este. Este enfoque es similar al caso de uso del cifrado de datos transparente de Bring Your Own Key (BYOK), que también usa la integración de Key Vault para almacenar la clave de cifrado. Si no quiere usar la clave como protector de la clave de cifrado y solo quiere que esté disponible para SQL Managed Instance y así poder restaurar las bases de datos cifradas, siga las instrucciones para configurar BYOK TDE y no active la casilla Hacer que la clave seleccionada sea el protector de TDE predeterminado.

Una vez que el protector de cifrado está disponible para Instancia administrada de SQL, puede continuar con el procedimiento de restauración de base de datos estándar.

SQL Managed Instance ofrece el modelo de compra basado en núcleo virtual.

Puede ahorrar costos con las ventajas de SQL Azure de las siguientes maneras:

• Maximice las inversiones existentes en licencias locales y ahorre hasta un 55 % con Ventaja híbrida de Azure.
• Confirme una reserva de recursos de proceso y ahorre hasta un 33 % con Ventaja de instancia reservada. Combínela con Ventaja híbrida de Azure para ahorrar hasta un 82 %.
• Ahorre hasta un 55 % en comparación con la lista de Ventaja de precios para desarrollo/pruebas de Azure, que ofrece tarifas con descuento para las cargas de trabajo de desarrollo y pruebas en curso.

Para poder beneficiarse de la Ventaja de instancia reservada, el tipo de suscripción debe ser un Contrato Enterprise (números de oferta: MS-AZR-0017P o MS-AZR-0148P) o un contrato individual con precios de pago por uso (números de oferta: MS-AZR-0003P o MS-AZR-0023P). Para más información sobre las reservas, consulte Ventaja de instancia reservada.

Puede cancelar, intercambiar o reembolsar reservas con ciertas limitaciones. Para más información, consulte Autoservicio de intercambios y reembolsos de reservas de Azure.

Para explorar las opciones de precios de SQL Managed Instance, consulte la página de precios.

Puede hacerlo con la solución Microsoft Cost Management. Navegue a Suscripciones en Azure Portal y seleccione Análisis de costos.

Use la opción Costos acumulados y luego filtre por Tipo de recurso, como microsoft.sql/managedinstances.

Puede usar herramientas de cliente de Microsoft o de terceros compatibles para obtener acceso a SQL Managed Instance y no se le cobrará ningún costo adicional en la factura de Azure. Sin embargo, si algunas de las herramientas requieren una licencia, debe tener un software con licencia legal. Esto se rige por contratos independientes que tiene con cada fabricante de herramientas individual.

Obtiene la misma cantidad de espacio de almacenamiento de copia de seguridad gratis que el espacio de almacenamiento de datos reservado adquirido, independientemente del período de retención de copia de seguridad establecido. Si el consumo del almacenamiento de copia de seguridad se encuentra dentro del espacio de almacenamiento de copia de seguridad asignado gratuito, las copias de seguridad automatizadas en SQL Managed Instance no tendrán ningún costo adicional para usted, por lo que serán gratuitas. Superar el uso del almacenamiento de copia de seguridad por encima del espacio libre conllevará un costo adicional. Consulte la sección Almacenamiento de copia de seguridad de la página de precios para obtener más información. Se explica más información técnica sobre las copias de seguridad automatizadas de SQL Managed Instance en Consumo de almacenamiento de copia de seguridad.

Puede supervisar el costo del almacenamiento de copia de seguridad a través de Azure Portal. Para obtener instrucciones, consulte Supervisión de los costos de las copias de seguridad automatizadas.

Para optimizar los costos de almacenamiento de copia de seguridad, consulte el artículo sobre la optimización de la copia de seguridad en SQL Managed Instance.

Casos prácticos de Instancia administrada de SQL:

• Komatsu
• KMD
• PowerDETAILS
• Allscripts

Para comprender mejor las ventajas, los costos y los riesgos asociados con la implementación de Azure SQL Managed Instance, también hay un estudio de Forrester: the Total Economic Impact of Microsoft Azure SQL Database Managed Instance.

La Directiva de contraseña de Instancia administrada de SQL para inicios de sesión de SQL hereda las directivas de la plataforma Azure que se aplican a las máquinas virtuales que forman el clúster virtual que contiene la instancia administrada. En este momento no es posible cambiar ninguno de estos valores, ya que estos se definen en Azure y los hereda la instancia administrada.

En cada inicio de sesión se tiene que establecer la contraseña y cambiarla una vez que alcance la antigüedad máxima.

Sí, los campos CHECK_POLICY y CHECK_EXPIRATION se pueden controlar en el nivel de inicio de sesión. Puede comprobar la configuración actual ejecutando el siguiente comando de T-SQL:

SELECT *
FROM sys.sql_logins

Después, puede modificar valores de inicio de sesión especificados ejecutando:

ALTER LOGIN <login_name> WITH CHECK_POLICY = OFF;
ALTER LOGIN <login_name> WITH CHECK_EXPIRATION = OFF;

(Reemplace "Test" por el nombre de inicio de sesión deseado y ajuste los valores de directiva y expiración).

Consulte la Rotación de certificados en Azure SQL Database y SQL Managed Instance.

Consulte Planeación de eventos de mantenimiento en SQL Managed Instance.

Puede votar por una nueva característica de SQL Managed Instance o crear una nueva idea de mejora en el Foro de comentarios de SQL Managed Instance. De este modo, puede contribuir al desarrollo del producto y ayudarnos a priorizar nuestras posibles mejoras.

Para obtener información acerca de cómo crear una solicitud de soporte técnico de Azure, consulte Creación de una solicitud de soporte técnico de Azure.

Todas las regiones, ofertas y tipos de suscripción tienen habilitado el conjunto de características a partir de noviembre de 2023.

El conjunto de características está disponible para las instancias de las subredes aptas. Si no ve nuevas características, es probable que la subred en la que se implemente la instancia administrada de SQL no sea apta.