Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a:Azure SQL Database
Azure SQL Database Hiperescala es una base de datos en la nube rentable y de alto rendimiento.
Azure SQL Database se basa en el motor de base de datos SQL. Hiperescala difiere de otros niveles de servicio de Azure SQL Database:
- A diferencia de otros niveles de servicio, Hiperescala no tiene ninguna tarifa de licencia de software SQL, lo que le da una ventaja de precio significativa sobre otros niveles de servicio Azure SQL Database para bases de datos de alto rendimiento.
- La arquitectura de hiperescala es distinta: proporciona copias de seguridad casi instantáneas, restauraciones rápidas y alto rendimiento para lecturas y escrituras.
- Hiperescala proporciona un escalado de proceso rápido a petición sin movimiento de datos.
- Las estrategias de escalado horizontal de lectura son sencillas, con hasta 30 réplicas con nombre con capacidad de proceso independiente y configurable, además de réplicas integradas de alta disponibilidad y réplicas geográficas configurables por todo el mundo.
El nivel de servicio Hiperescala es adecuado para todos los tipos de carga de trabajo. Los recursos de proceso y almacenamiento en Hiperescala superan considerablemente los recursos disponibles en los niveles de uso general y crítico para la empresa Azure SQL Database.
Puede convertir una base de datos existente en Azure SQL Database a Hiperescala fácilmente o migrar desde cualquier base de datos de SQL Server a Hiperescala. Para migrar otras bases de datos a Azure SQL Database, consulte guías de migración de bases de datos de Azure.
El nivel de servicio Hiperescala solo está disponible actualmente para Azure SQL Database y no para Azure SQL Managed Instance.
¿Cuáles son las funcionalidades de Hiperescala?
El nivel de servicio Hiperescala de Azure SQL Database proporciona las siguientes funcionalidades adicionales:
- Escalado vertical rápido: escale verticalmente los recursos de proceso para dar cabida a cargas de trabajo pesadas cuando sea necesario y, a continuación, reducir verticalmente los recursos de proceso cuando no sea necesario.
- Rápido escalado horizontal: aprovisione una o varias réplicas de solo lectura para la descarga de la carga de trabajo de lectura y para su uso como esperas activas.
- Escalado vertical, reducción vertical y facturación automáticos para el proceso en función del uso con proceso sin servidor.
- Precio/rendimiento optimizado para un grupo de bases de datos Hyperscale con distintas demandas de recursos con grupos elásticos.
- Almacenamiento autoescalable con soporte de hasta 128 TB de base de datos o 100 TB de grupo elástico.
- Mayor rendimiento general debido a una mayor capacidad de proceso de los registros de transacciones y tiempos más rápidos de confirmación de estas, independientemente de los volúmenes de datos.
- Copias de seguridad de base de datos rápidas (basadas en instantáneas de archivos) independientemente del tamaño sin efecto de la E/S en recursos del proceso.
- Copias o restauraciones rápidas de base de datos (basadas en instantáneas de archivos) en minutos en lugar de horas o días.
El nivel de servicio Hiperescala elimina muchos de los límites prácticos que tradicionalmente se ven en las bases de datos en la nube. Donde la mayoría de las otras bases de datos están limitados por los recursos disponibles en un único nodo, las bases de datos en el nivel de servicio Hiperescala no tienen límites de este tipo. Con su arquitectura de almacenamiento flexible, el almacenamiento crece a medida que sea necesario. De hecho, las bases de datos de Hiperescala no se crean con un tamaño máximo definido. Una base de datos de Hiperescala aumenta según sea necesario, y se le cobra solo la capacidad de almacenamiento que use. Para cargas de trabajo de lectura intensiva, el nivel de servicio Hiperescala proporciona rápida escalabilidad horizontal mediante el aprovisionamiento de réplicas adicionales según sea necesario para descargar las cargas de trabajo de lectura.
Además, el tiempo necesario para crear copias de seguridad de bases de datos o para escalar o reducir verticalmente ya no está ligado al volumen de los datos en la base de datos. Las copias de seguridad de las bases de datos de Hiperescala se realizan de manera prácticamente instantánea. También puede escalar o reducir verticalmente una base de datos de decenas de terabytes en cuestión de minutos en el nivel de proceso aprovisionado o usar sin servidor para escalar el proceso automáticamente. Esta funcionalidad le libra de la preocupación de estar atado por las opciones de la configuración inicial.
Para más información sobre los tamaños de proceso para el nivel de servicio Hiperescala, consulte Características de los niveles de servicios.
Para más información acerca de los niveles de servicios Uso general y Crítico para la empresa en el modelo de compra basado en núcleo virtual, consulte los niveles de servicio Uso general y Crítico para la empresa. Para ver una comparación del modelo de compra basado en vCore con el modelo de compra basado en DTU, consulte Compare los modelos de compra basados en vCore y DTU de Azure SQL Database.
Quién debe tener en cuenta el nivel de servicio Hiperescala
El nivel de servicio Hiperescala está diseñado para todos los clientes que requieren un mayor rendimiento y disponibilidad, copias de seguridad y restauración rápidas y escalabilidad de proceso y almacenamiento rápidos. Hiperescala es ideal para los clientes que se mueven a la nube para modernizar sus aplicaciones o para los clientes que ya usan otros niveles de servicio en Azure SQL Database. El nivel de servicio Hiperescala admite una amplia gama de cargas de trabajo de base de datos, desde OLTP puro hasta análisis puros. Está optimizado para cargas de trabajo OLTP y de procesamiento híbrido transaccional y analítico (HTAP).
Modelo de precios de Hiperescala
En el caso de las bases de datos de alto rendimiento, Hiperescala ofrece una ventaja de precio significativa frente a otros niveles de servicio Azure SQL Database. Para obtener más información, consulte Blog: anuncio de precios de Hiperescala de Azure SQL Database que se hizo en Ignite 2023. Para obtener más información sobre los cambios de precios, consulte Blog: Azure SQL Database Hiperescala: precios más bajos y simplificados.
El nivel de servicio Hiperescala solo está disponible en el modelo de núcleo virtual y viene en dos niveles de proceso. La facturación de Hiperescala se basa en el nivel de proceso aprovisionado o sin servidor:
Nivel de proceso aprovisionado:
El coste de proceso de vCore refleja la capacidad de proceso total que se aprovisiona de forma continua para la aplicación. El precio de la unidad de proceso de Hiperescala es por réplica.
Nivel de proceso sin servidor:
La facturación de proceso sin servidor se basa en el uso. Para obtener más información, consulte Nivel de proceso sin servidor para Azure SQL Database.
No se especifica el tamaño máximo de datos al configurar una base de datos de Hiperescala. En el nivel de hiperescala, se paga el almacenamiento según la asignación real. El almacenamiento se asigna automáticamente entre 10 GB y 128 TB y crece según sea necesario. Para más información, consulta ¿En qué incrementos crece el tamaño de mi base de datos?
Ventajas de escala y rendimiento
Hiperescala separa el motor de base de datos principal de los componentes que proporcionan almacenamiento a largo plazo y durabilidad para los datos. Esta arquitectura permite escalar rápidamente los recursos de proceso, sin movimiento de datos y escalar el almacenamiento (hasta 128 TB) independientemente del proceso. Para obtener más información, incluido un diagrama de arquitectura, consulte Arquitectura de Hiperescala.
- Gracias a la capacidad de aumentar o disminuir rápidamente los nodos de ejecución adicionales de solo lectura, la arquitectura de Hiperescala permite obtener importantes funcionalidades de escalado de lectura y también puede liberar el nodo de ejecución principal para atender más solicitudes.
- Puedes provisionar el cómputo para nodos secundarios o usar computación sin servidor. En cualquier caso, puedes ampliarlas o reducirlas rápidamente gracias a la arquitectura de almacenamiento compartido de Hyperscale.
- Las réplicas secundarias de nodos de ejecución de alta disponibilidad de Hiperescala siguen el nivel de proceso del nodo principal, lo que permite realizar conmutaciones por error de bajo impacto.
- Cuando se usan nodos de proceso primarios o secundarios sin servidor, se escalan automáticamente en función de la demanda de carga de trabajo.
La base de datos principal de Hiperescala de Azure SQL Database administra cargas de trabajo tanto de lectura como de escritura, pero puede crear fácilmente réplicas de solo lectura como parte de la estrategia de su aplicación:
- Puede ajustar el número total de réplicas secundarias de alta disponibilidad de 0 a 4, en función de los requisitos de disponibilidad y escalabilidad.
- Puede crear hasta 30 réplicas con nombre para admitir cargas de trabajo de escalado horizontal de lectura.
- Puede lograr el escalado horizontal de lectura distribuido geográficamente en los centros de datos globales de Azure mediante el uso de replicación geográfica.
Alta disponibilidad de la base de datos en Hiperescala
Como en todos los demás niveles de servicio, Hiperescala garantiza la durabilidad de los datos para las transacciones confirmadas, independientemente de la disponibilidad de la réplica de proceso. El grado de tiempo de inactividad debido a que la réplica principal no esté disponible depende del tipo de conmutación por error (planeada frente a no planeada), de si la redundancia de zona está configurada y de la presencia de al menos una réplica de alta disponibilidad. En una conmutación por error planeada (como un evento de mantenimiento), el sistema crea la nueva réplica principal antes de iniciar una conmutación por error o usa una réplica de alta disponibilidad existente como destino de conmutación por error. En una conmutación por error no planeada (como un error de hardware en la réplica principal), el sistema usa una réplica de alta disponibilidad como destino de la conmutación por error, si existe, o crea una réplica principal a partir del grupo de capacidad de proceso disponible. En el último caso, la duración del tiempo de inactividad es mayor debido a pasos adicionales necesarios para crear la nueva réplica principal.
Puede elegir una ventana de mantenimiento para hacer que los eventos de mantenimiento impactantes sean predecibles y menos perjudiciales para la carga de trabajo.
Para el Acuerdo de Nivel de Servicio de Hiperescala, consulte SLA para Azure SQL Database.
Búfer de caché y extensión resistente del búfer de caché
En Azure Hiperescala de base de datos, hay una separación distinta entre el proceso y el almacenamiento. El almacenamiento contiene todas las páginas de una base de datos y puede asignarse a varios equipos a medida que crece la base de datos. El nodo de proceso, sin embargo, solo almacena en caché lo que se está utilizando recientemente. Las páginas más activas del proceso se mantienen en memoria en una estructura denominada grupo de búferes (BP). También se almacena en el SSD local, la extensión de reserva de búfer resiliente (RBPEX), para que los datos puedan recuperarse más rápidamente en caso de que se reinicie el proceso de proceso.
En un sistema en nube, el proceso puede trasladarse a diferentes máquinas según sea necesario. La capa de proceso puede tener múltiples réplicas. Una réplica es principal y recibe todas las actualizaciones, mientras que las demás son réplicas secundarias. Si se produce un error en la réplica principal, el sistema promueve a principal una de las réplicas secundarias de alta disponibilidad en un proceso denominado conmutación por error. Es posible que la réplica secundaria no tenga una memoria caché en su BP y RBPEX optimizada para la carga de trabajo principal.
Cebado continuo
La preparación continua es un proceso que recopila información sobre a qué páginas se accede con más frecuencia (son más populares) en todas las réplicas de proceso. El proceso agrega esta información y las réplicas secundarias de alta disponibilidad utilizan la lista de páginas más populares que corresponden a la carga de trabajo típica del cliente. Este proceso rellena continuamente tanto el BP como el RBPEX con las páginas de uso más frecuente para adaptarse a los cambios en la carga de trabajo del cliente.
Sin cebado continuo, tanto BP como RBPEX no son heredados por nuevas réplicas de alta disponibilidad y solo se reconstruyen durante la carga de trabajo del usuario. El cebado continuo ahorra tiempo y evita un rendimiento incoherente, ya que no hay que esperar a que las cachés vuelvan a estar completamente hidratadas. Con la preparación continua, las nuevas réplicas secundarias de alta disponibilidad comenzarán inmediatamente a preparar su BP y RBPEX. Esto ayudará a mantener el rendimiento de forma más consistente cuando se produzcan fallos.
La preparación continua funciona de ambas maneras: las réplicas secundarias de alta disponibilidad almacenarán en caché las páginas que se usan en la réplica principal y las páginas principales almacenarán en caché las páginas con la carga de trabajo de las réplicas secundarias.
El cebado continuo está disponible actualmente en el nivel informático aprovisionado Hyperscale.
Copia de seguridad y restauración
Las operaciones de copia de seguridad y restauración de bases de datos de Hiperescala se basan en instantáneas de archivos. Este enfoque hace que estas operaciones se realicen casi instantáneas. Dado que la arquitectura hiperescala usa la capa de almacenamiento para la copia de seguridad y restauración, reduce la carga de procesamiento y el impacto en el rendimiento en las réplicas de proceso. Para más información, consulte Copias de seguridad de hiperescala y redundancia de almacenamiento.
Recuperación ante desastres para bases de datos Hiperescala
Para restaurar una base de datos de Hiperescala en Azure SQL Database a una región distinta de la hospedada actualmente, realice una restauración geográfica. Este método funciona para operaciones de recuperación ante desastres, simulacros, reubicación o cualquier otro motivo. La restauración geográfica solo está disponible cuando se elige almacenamiento con redundancia geográfica (RA-GRS) para la redundancia de almacenamiento.
Para obtener más información, consulte Restauración de una base de datos de Hiperescala en otra región.
Comparación de los límites de recursos
Los niveles de servicio basados en núcleo virtual difieren en la disponibilidad de la base de datos, el tipo de almacenamiento, el rendimiento y el tamaño máximo de almacenamiento. En la tabla siguiente se describen estas diferencias:
| ㅤ | De uso general | Crítico para la empresa | Hiperescala |
|---|---|---|---|
| Más adecuado para | Opciones de proceso y almacenamiento equilibradas orientadas al presupuesto. | Aplicaciones de OLTP con una alta tasa de transacciones y latencia de E/S baja. Alta resiliencia a errores y conmutaciones por error rápidas mediante el uso de varias réplicas de espera activa. | El nivel de servicio recomendado y predeterminado para todas las cargas de trabajo OLTP y HTAP nuevas y modernas. Es el mejor para la mayor variedad de cargas de trabajo, incluidas las que tienen requisitos de escalado de lectura y almacenamiento altamente escalable. Ofrece una mayor resistencia a los errores al permitir la configuración de más de una réplica secundaria de alta disponibilidad. |
| Tamaño de proceso | 2 a 128 núcleos virtuales | 2 a 128 núcleos virtuales | De 2 a 192 núcleos virtuales3 |
| Tipo de almacenamiento | Almacenamiento remoto Premium (por instancia) | Almacenamiento SSD local extremadamente rápido (por instancia) | Almacenamiento desacoplado con caché de unidad de estado sólido local (por réplica de proceso) |
| Tamaño de almacenamiento | 1 GB - 4 TB | 1 GB - 4 TB | 10 GB - 128 TB |
| IOPS máx. | 320 IOPS por núcleo virtual con 16 000 IOPS como máximo | 4000 IOPS por núcleo virtual con 327 680 IOPS como máximo | 5.500 IOPS por núcleo virtual con un máximo de 544.000 IOPS locales de SSD. Hiperescala es una arquitectura de varios niveles con almacenamiento en caché en varios niveles. Las IOPS efectivas dependen de la carga de trabajo. |
| Memoria/núcleo virtual | 5,1 GB | 5,1 GB | 5,1 GB o 10,2 GB |
| Copias de seguridad | Una opción de almacenamiento con redundancia local (LRS), almacenamiento con redundancia de zona (ZRS) o almacenamiento con redundancia geográfica (GRS) Retención de 1 a 35 días (7 días de forma predeterminada), con hasta 10 años de retención a largo plazo disponible |
Una opción de almacenamiento con redundancia local (LRS), almacenamiento con redundancia de zona (ZRS) o almacenamiento con redundancia geográfica (GRS) Retención de 1 a 35 días (7 días de forma predeterminada), con hasta 10 años de retención a largo plazo disponible |
Una opción de almacenamiento con redundancia local (LRS), almacenamiento con redundancia de zona (ZRS) o almacenamiento con redundancia geográfica (GRS) Retención de 1 a 35 días (7 días de forma predeterminada), con hasta 10 años de retención a largo plazo disponible |
| Disponibilidad | Una réplica, sin réplicas de escalado horizontal de lectura. Alta disponibilidad con redundancia de zona | Tres réplicas, una réplica de escalado horizontal de lectura. Alta disponibilidad con redundancia de zona | Varias réplicas, hasta 4 réplicas de escalado horizontal de lectura. Alta disponibilidad con redundancia de zona |
| Precios y facturación |
El núcleo virtual, el almacenamiento reservado y el almacenamiento de copia de seguridad se cobran. No se cobran IOPS. |
El núcleo virtual, el almacenamiento reservado y el almacenamiento de copia de seguridad se cobran. No se cobran IOPS. |
Se cobran el núcleo virtual de cada réplica, el almacenamiento de datos asignados y el almacenamiento de copia de seguridad. No se cobran IOPS. |
| Modelos de descuento2 |
reservas de Azure Ventaja híbrida de Azure2 Suscripciones de Enterprise y ofertas de Desarrollo/pruebas - Pago por uso |
reservas de Azure Ventaja híbrida de Azure2 Suscripciones de Enterprise y ofertas de Desarrollo/pruebas - Pago por uso |
Dado que Hiperescala no tiene ninguna tarifa de licencia de software sql1, Ventaja híbrida de Azure no está disponible para las nuevas bases de datos de Hiperescala2. |
| Tablas en memoria | No | Sí | No |
1 Los precios simplificados para Hiperescala de SQL Database comenzaron en diciembre de 2023. Revise el blog de precios de Hiperescala para más información.
2 a partir de diciembre de 2023, Ventaja híbrida de Azure no está disponible para las nuevas bases de datos de Hiperescala o en suscripciones de desarrollo y pruebas. Las bases de datos únicas de Hiperescala existentes con proceso aprovisionado pueden seguir usando Ventaja híbrida de Azure para ahorrar en costos de proceso hasta diciembre de 2026. Para obtener más información, revise el blog de precios de Hiperescala.
3 Actualmente, las opciones de núcleo virtual 160 y 192 son una característica en versión preliminar.
Recursos de proceso
En la tabla siguiente se comparan los recursos de proceso en diferentes configuraciones de hardware y niveles de proceso para Hiperescala de Azure SQL Database. Para Azure SQL Database que no es de tipo Hiperescala, consulte modelo de compra de vCore: Azure SQL Database.
| Configuración de hardware | Unidad Central de Procesamiento (CPU) | Memoria |
|---|---|---|
| Serie estándar (Gen5) |
Proceso aprovisionado - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)*, Intel® 8272CL (Cascade Lake) 2,5 GHz*, Intel Xeon® Platinum 8370C (Ice Lake)*, AMD EPYC™ 7763v (Milán)*, AMD EPYC 9004 (Génova)*, Intel®® Xeon® Platinum 8573C (Emerald Rapids)* procesadores)* - Aprovisionamiento de hasta 128 núcleos virtuales (Hyper-Threaded) Proceso sin servidor - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)*, Intel® 8272CL (Cascade Lake) 2,5 GHz*, Intel Xeon® Platinum 8370C (Ice Lake)*, AMD EPYC™ 7763v (Milán)*, AMD EPYC 9004 (Génova)*, Intel®® Xeon® Platinum 8573C (Emerald Rapids)* procesadores)* - Escalabilidad automática de hasta 80 núcleos virtuales (Hyper-Threaded) - La proporción de memoria a núcleo virtual se adapta dinámicamente al uso de memoria y CPU en función de la demanda de la carga de trabajo y puede llegar a un máximo de 24 GB por núcleo virtual. Por ejemplo, en un momento dado, una carga de trabajo podría usar y ser facturada por 240 GB de memoria y solo 10 vCores. |
Proceso aprovisionado - 5,1 GB por núcleo virtual - Aprovisionamiento de hasta 625 GB Proceso sin servidor - Escalabilidad automática de hasta 24 GB por núcleo virtual. - Escalabilidad automática de hasta 240 GB máx. |
| Serie Premium |
Proceso aprovisionado - Intel® Xeon® Platinum 8370C (Ice Lake)*, AMD EPYC™ 7763v (Milán)*, AMD EPYC 9004 (Génova)*, Procesadores Intel® Xeon® Platinum 8573C (Emerald Rapids)* - Aprovisionamiento de hasta 192 núcleos virtuales (hyperthreading). |
5,2 GB por núcleo virtual |
| Serie Premium optimizada para memoria |
Proceso aprovisionado - Intel® Xeon® Platinum 8370C (Ice Lake)*, AMD EPYC™ 7763v (Milán)*, AMD EPYC 9004 (Génova)*, Procesadores Intel® Xeon® Platinum 8573C (Emerald Rapids)* - Aprovisionamiento de hasta 80 núcleos virtuales (hyperthreading). |
10,2 GB por núcleo virtual |
* Para una configuración de hardware y tamaño de proceso determinado, los límites de recursos son los mismos independientemente del tipo de CPU (Intel® Broadwell, Skylake, Ice Lake, Cascade Lake, Emerald Rapid o AMD Milan, Génova). En la vista de administración dinámica sys.dm_user_db_resource_governance, generación de hardware para bases de datos que utilizan:
- Los procesadores Intel® SP-8160 (Skylake) aparecen como Gen6
- Intel® 8272CL (Cascade Lake) aparece como Gen7
- Intel® Xeon® Platinum 8370C (Ice Lake) o AMD EPYC™ 7763v (Milán) aparecen como Gen8
- AMD EPYC™ 9004 (Génova) aparece como Gen9 o Intel® Xeon® Platinum 8573C (Emerald Rapids) aparecen como Gen10
Para obtener más información, consulte los límites de recursos de bases de datos únicas y grupos elásticos.
Creación y administración de bases de datos de Hiperescala
Puede crear y administrar bases de datos de Hiperescala mediante el portal de Azure, Transact-SQL, PowerShell y el CLI de Azure. Para más información, vea Inicio rápido: Creación de una base de datos de Hiperescala.
| Operación | Detalles | Más información |
|---|---|---|
| Creación de una base de datos de Hiperescala | Las bases de datos de hiperescala solo están disponibles con el modelo de compra basado en núcleos virtuales. | Busque ejemplos para crear una base de datos de Hiperescala en Quickstart: Creación de una base de datos de Hiperescala en Azure SQL Database. |
| Convertir una base de datos existente en Hiperescala | Puede convertir una base de datos existente a una de nivel Hiperescala de Azure SQL Database. La duración de la conversión depende del tamaño de los datos. | Para obtener más información, vea Convertir una base de datos existente en Hiperescala. |
| Migración inversa de una base de datos de Hiperescala al nivel de servicio De uso general | Si anteriormente migró una Azure SQL Database existente a Hiperescala, puede revertir la migración de la base de datos al nivel de servicio De uso general en un plazo de 45 días a partir de la migración original a Hiperescala. Si desea migrar la base de datos a otro nivel de servicio, como Crítico para la empresa, primero realice la migración inversa al nivel de servicio De uso general y, a continuación, cambie el nivel de servicio. |
Más información sobre cómo revertir la migración desde Hiperescala, incluidas las limitaciones de la migración inversa. |
Limitaciones
Estas limitaciones se aplican actualmente al nivel de servicio Hiperescala. El equipo del producto está trabajando activamente para eliminar tantas de estas limitaciones como sea posible.
| Incidencia | Descripción |
|---|---|
| La reducción se bloquea cuando el TDE está deshabilitado | Actualmente, Azure SQL Database Hiperescala no admite operaciones de reducción de archivos y bases de datos cuando se deshabilita Cifrado de datos transparente (TDE). |
| Restauración de la base de datos desde otros niveles de servicio | No se puede restaurar una base de datos que no es de Hiperescala como una base de datos de Hiperescala. Tampoco puede restaurar una base de datos de Hiperescala como una base de datos que no sea hiperescala. En el caso de las bases de datos migradas a Hiperescala desde otros niveles de servicio de Azure SQL Database, las copias de seguridad previas a la migración se conservan durante el período de retención de copia de seguridad de la base de datos de origen, incluidas las directivas de retención a largo plazo. Puede restaurar una copia de seguridad previa a la migración dentro del período de retención de copia de seguridad de la base de datos a través de la línea de comandos. Puede restaurar estas copias de seguridad a cualquier nivel de servicio que no sea de Hiperescala. |
| Migración de bases de datos con objetos OLTP en memoria | Hiperescala admite un subconjunto de objetos OLTP en memoria, incluidos los tipos de tablas optimizadas para memoria, las variables de tablas y los módulos compilados de forma nativa. Sin embargo, cuando hay presente cualquier objeto OLTP en memoria en la base de datos que se está migrando, no se admite la migración desde los niveles de servicio Premium y Crítico para la empresa a Hiperescala. Para migrar dicha base de datos a Hiperescala, debe quitar todos los objetos OLTP In-Memory y sus dependencias. Una vez migrada la base de datos, puede volver a crear estos objetos. En este momento no se admiten tablas optimizadas para memoria, duraderas y no duraderas, en Hiperescala, y se deben cambiar a tablas de disco. |
| Comprobación de la integridad de la base de datos |
DBCC CHECKDBy DBCC CHECKFILEGROUP actualmente no son compatibles con bases de datos Azure SQL Database Hyperscale. Como solución alternativa, usa DBCC CHECKTABLE ('TableName') WITH TABLOCK. Para más información sobre la administración de la integridad de datos en Azure SQL Database, consulte Integridad de datos en Azure SQL Database. |
| Trabajos elásticos | No se admite el uso de una base de datos de Hiperescala como base de datos de trabajo. Sin embargo, los trabajos elásticos pueden tener como destino bases de datos de Hiperescala de la misma manera que cualquier otra base de datos de Azure SQL Database. |
| Sincronización de Datos | No se admite el uso de una base de datos de Hiperescala como base de datos central o de metadatos de sincronización. Sin embargo, una base de datos de Hiperescala puede ser una base de datos miembro en una topología de Data Sync. |
| Hardware de la serie Premium del nivel de servicio Hiperescala | La serie premium y el hardware de la serie premium optimizado para memoria no admiten actualmente el nivel de proceso sin servidor. Sin servidor solo se admite en hardware de la serie estándar (Gen5). |
| Disponibilidad regional | El hardware de las series premium y premium optimizada para memoria del nivel de servicio de Hiperescala está disponible en regiones de Azure limitadas. Para obtener una lista, consulte Disponibilidad de la serie Premium de Hiperescala. |
Contenido relacionado
- Preguntas más frecuentes sobre Hiperescala
- Compare el modelo de compra vCore y los modelos de compra basados en DTU de Azure SQL Database
- Administración de recursos en Azure SQL Database
- Límites de recursos para bases de datos únicas que utilizan el modelo de compra en núcleos virtuales
- Comparación de características: Azure SQL Database y Azure SQL Managed Instance
- Arquitectura de funciones distribuidas de Hiperescala
- Administración de una base de datos de Hiperescala
- Referencia de configuración modificable para Azure SQL Database