Preguntas más frecuentes sobre Hiperescala de Azure SQL Database

Una base de datos de Hiperescala es una base de datos de SQL Database que utiliza la tecnología de almacenamiento de escalabilidad horizontal de Hiperescala. Una base de datos de hiperescala admite hasta 100 TB de datos y proporciona un alto rendimiento, así como un rápido escalado para adaptarse a los requisitos de la carga de trabajo. La conectividad, el procesamiento de consultas, las características del motor de base de datos, etc., funcionan como cualquier otra base de datos de Azure SQL Database.

El nivel de servicio Hiperescala solo está disponible para bases de datos únicas que usan el modelo de compra basado en núcleo virtual de Azure SQL Database. No está disponible en el modelo de compra basado en DTU.

Los niveles de servicio basados en núcleos virtuales se diferencian en función de la disponibilidad de la base de datos y del tipo de almacenamiento, el rendimiento y el tamaño máximo de almacenamiento, tal como se describe en comparación de límites de recursos.

El nivel de servicio Hiperescala es para todos los clientes que buscan un mayor rendimiento y disponibilidad, copias de seguridad y restauración rápidas o almacenamiento rápido y escalabilidad de procesos. Entre ellos se incluyen clientes que empiezan y van creciendo, los que ejecutan bases de datos críticas, los que se trasladan a la nube para modernizar sus aplicaciones y clientes que ya utilizan otros niveles de servicio en base de datos de Azure SQL. Con Hiperescala, obtendrá:

• Tamaño de la base de datos que puede aumentar de 10 GB a 100 TB.
• Recursos de núcleo virtual de proceso de 2 núcleos virtuales hasta 128 núcleos virtuales
• Copias de seguridad rápidas de bases de datos, independientemente del tamaño de la base de datos (las copias de seguridad se basan en instantáneas de almacenamiento).
• Restauraciones rápidas de bases de datos, independientemente del tamaño de la base de datos (las restauraciones se basan en instantáneas de almacenamiento).
• Mayor rendimiento de registro independientemente del tamaño de la base de datos y del número de núcleos virtuales.
• Escalado horizontal de lectura con una o varias réplicas de solo lectura, que se usan para la descarga de cargas de trabajo de solo lectura o como bases de datos en espera activa.
• Rápido escalado vertical de procesos, en tiempo constante, para que tenga más potencia para acomodar la pesada carga de trabajo, seguida de una reducción vertical, en tiempo constante. Las operaciones de escalado tardan minutos con un solo dígito para el proceso aprovisionado y menos de un segundo para el proceso sin servidor, independientemente del tamaño de la base de datos.
• La opción de pagar por lo que se utiliza con el proceso sin servidor, donde el proceso se factura en función del uso.

El nivel de servicio Hiperescala está disponible en todas las regiones en las que Azure SQL Database está disponible.

Sí. Para obtener más información y conocer los límites en el número de bases de datos por servidor, consulte Límites de recursos de SQL Database para bases de datos individuales y agrupadas en un servidor.

La arquitectura de Hiperescala proporciona un alto rendimiento al tiempo que admite tamaños de bases de datos grandes.

Hiperescala proporciona una rápida escalabilidad según la demanda de la carga de trabajo.

• Escalado y reducción vertical

  Con Hiperescala, puede escalar verticalmente el tamaño de proceso principal en términos de recursos como CPU y memoria y, posteriormente, reducir verticalmente, en tiempo constante. Dado que el almacenamiento es remoto, el escalado y la reducción verticales no constituyen un tamaño de operación de datos.

  La compatibilidad con el proceso sin servidor proporciona escalado vertical y reducción vertical automáticos. El proceso se factura en función del uso.

• Escalado y reducción horizontal

  Con Hiperescala, puede usar tres tipos de réplicas secundarias para satisfacer los requisitos de escalado horizontal de lectura, alta disponibilidad y replicación geográfica. Esto incluye:

  • Hasta cuatro réplicas de alta disponibilidad que tienen el mismo tamaño de proceso que la principal. Sirven como réplicas de espera activa para conmutar por error rápidamente desde la réplica principal. También puede usarlas para descargar cargas de trabajo de lectura desde la réplica principal.
  • Hasta 30 réplicas con nombre con el mismo tamaño de proceso o diferente que la principal, para satisfacer varios escenarios de escalado horizontal de lectura.
  • Una réplica geográfica en otra región de Azure para protegerse frente a interrupciones regionales y habilitar el escalado horizontal de lectura geográfico.

Sí, puede hacerlo.

No, el modelo de programación de aplicaciones sigue siendo el mismo que para cualquier otra base de datos MSSQL. Puede usar la cadena de conexión y los demás modos normales como de costumbre para interactuar con su base de datos de Hiperescala. Una vez que la aplicación usa la base de datos de Hiperescala, la aplicación puede aprovechar características como las réplicas secundarias.

En la réplica principal, el nivel de aislamiento de transacción predeterminado es RCSI (aislamiento de instantánea de lectura confirmada). En las réplicas secundarias del escalado horizontal de lectura, el nivel de aislamiento predeterminado es Instantánea. Es igual que en cualquier otra base de datos de Azure SQL.

Con los nuevos precios simplificados en vigor desde el 15 de diciembre de 2023, se ha reducido el precio del proceso para las bases de datos de Hiperescala recién creadas, todas las bases de datos de Hiperescala sin servidor y todos los grupos elásticos de Hiperescala. Con los nuevos precios simplificados, no es necesario aplicar la Ventaja híbrida de Azure (AHB) para obtener ahorros equivalentes. La Ventaja híbrida de Azure (AHB) solo se puede aplicar a bases de datos únicas de Hiperescala (creadas antes del 15 de diciembre de 2023) con proceso aprovisionado. Para esas bases de datos anteriores, AHB solo se aplica hasta diciembre de 2026, después de lo cual esas bases de datos también se facturarán según los precios nuevos y simplificados. Para obtener más información, consulte el blog de precios de Hiperescala e Hiperescala de Azure SQL Database: precios más bajos y simplificados.

Hiperescala funciona bien con todos los tipos de cargas de trabajo, incluidas las cargas de trabajo OLTP, híbridas (HTAP) y analíticas (data mart).

Si actualmente ejecuta consultas de análisis interactivas mediante SQL°Server como almacenamiento de datos, Hiperescala es una excelente opción porque se pueden hospedar almacenamientos de datos pequeños y medianos (desde unos pocos TB hasta 100 TB) a un menor costo y puede migrar sus cargas de trabajo del almacenamiento de datos de SQL Server a Hiperescala con el mínimo de cambios en el código T-SQL.

Si va a ejecutar análisis de datos a gran escala con consultas complejas y tasas de ingesta sostenidas que superen los 100 MB/s o usar almacenamiento de datos paralelos (PDW), Teradata o cualquier otro almacenamiento de datos con procesamiento paralelo masivo (MPP), Azure Synapse Analytics o Microsoft Fabric podría ser la mejor opción.

De momento, no. Sin embargo, puede reducir verticalmente el proceso y el número de réplicas para reducir el coste durante las horas que no sean punta o usar servicios sin servidor para escalar automáticamente el proceso en función del uso.

En el caso de las cargas de trabajo de lectura, puede crear una réplica con nombre con un tamaño de proceso mayor (más núcleos y memoria) que la principal. Para más información sobre los tamaños de proceso disponibles, consulte los tamaños de almacenamiento y proceso de Hiperescala.

En el caso de las cargas de trabajo de lectura, puede hacerlo mediante réplicas con nombre.

Puede escalar el número de réplicas secundarias de alta disponibilidad entre 0 y 4 mediante Azure Portal o la API de REST. Además, puede crear hasta 30 réplicas con nombre para muchos escenarios de escalado horizontal de lectura.

En las bases de datos de Hiperescala, se proporciona resistencia de los datos en el nivel de almacenamiento. Solo necesita una réplica (la principal) para proporcionar resistencia. Cuando la réplica de proceso está inactiva, se crea automáticamente una nueva réplica sin ninguna pérdida de datos.

Pero si solo existe la réplica principal, puede tardar un minuto o dos en crear una réplica después de la conmutación por error, en comparación con los segundos que tarda en caso de que haya disponible una réplica secundaria de alta disponibilidad. Inicialmente, la nueva réplica tendrá cachés inactivas inicialmente, lo que puede dar lugar a una mayor latencia de almacenamiento y a reducir el rendimiento de las consultas inmediatamente después de la conmutación por error.

En el caso de las aplicaciones críticas que necesiten alta disponibilidad con un impacto mínimo de conmutación por error, debe aprovisionar al menos una réplica secundaria de alta disponibilidad para garantizar que haya una réplica en espera activa que pueda funcionar como destino de conmutación por error.

100 TB.

En Hiperescala, el registro de transacciones es prácticamente infinito, con una restricción de que la parte activa del registro no puede ser superior a 1 TB. La parte activa del registro puede aumentar debido a transacciones de larga duración o a que el procesamiento de captura de datos modificados no sigue el ritmo de la tasa de cambio de datos. Evite transacciones innecesariamente largas y grandes para mantenerse por debajo de este límite. Aparte de esta restricción, no es necesario preocuparse por quedarse sin espacio en el registro en un sistema que tenga un alto rendimiento. No obstante, la velocidad de generación de registros se puede ver limitada por cargas de trabajo de escritura intensamente continuas. La velocidad máxima de generación de registros sostenidos es de 100 MB/s.

La base de datos tempdb está ubicada en el almacenamiento SSD local y tiene un tamaño proporcional al tamaño de proceso (el número de núcleos) que aprovisione. No puede configurar el tamaño de tempdb porque no es usted quien lo administra. Para determinar el tamaño máximo de tempdb de la base de datos, consulte tempdb.

El tamaño de la base de datos crece automáticamente a medida que inserta o ingiere más datos.

10 GB. Se crea una base de datos de Hiperescala con un tamaño inicial de 10 GB y crece según sea necesario en fragmentos de 10 GB.

Cada archivo de datos crece en 10 GB. Varios archivos de datos pueden crecer al mismo tiempo.

En Hiperescala, los archivos de datos se almacenan en el almacenamiento estándar de Azure. Los datos se almacenan completamente en caché en el almacenamiento SSD local, en servidores de página remotos con respecto a las réplicas de proceso. Además, las réplicas de proceso tienen cachés de datos en el almacenamiento SSD local y en memoria, para disminuir la frecuencia de la captura de datos desde servidores de página remotos.

No. Los archivos de datos se agregan automáticamente al grupo de archivos PRIMARY. Las razones comunes para crear grupos de archivos adicionales no se aplican a la arquitectura de almacenamiento de Hiperescala, ni a Azure SQL Database.

No.

Sí, las operaciones de reducción de archivos y bases de datos se encuentran actualmente en versión preliminar. Para obtener más información sobre la versión preliminar, consulte Reducción para Azure SQL Database Hyperscale.

Sí, al igual que en cualquier otra base de datos de Azure SQL DB. Esto incluye la compresión de fila, página y almacén de columnas.

Sí. Las páginas de datos asociadas a una determinada tabla pueden acabar en varios archivos de datos, los cuales forman todos parte del mismo grupo de archivos. El motor de base de datos MSSQL usa una estrategia de relleno proporcional para distribuir los datos entre los archivos de datos.

Sí. Puede trasladar las bases de datos existentes de Azure SQL a Hiperescala. En el caso de las pruebas de concepto (POC), se recomienda hacer una copia de la base de datos y migrarla a Hiperescala.

El tiempo necesario para mover una base de datos existente a Hiperescala consta del tiempo para copiar los datos y el tiempo para reproducir los cambios realizados en la base de datos de origen mientras se copian los datos. El tiempo de la copia de datos es proporcional al tamaño de los datos. El tiempo de reproducción de los cambios será más breve si el movimiento se realiza durante un período de escasa actividad de escritura.

Obtenga código de ejemplo para migrar bases de datos de Azure SQL Database existentes a Hiperescala en Azure Portal, la CLI de Azure, PowerShell y Transact-SQL en Migración de una base de datos existente a Hiperescala.

La migración inversa al nivel de servicio De uso general permite a los clientes que han migrado recientemente una base de datos existente de Azure SQL Database al nivel de servicio Hiperescala retroceder si Hiperescala no satisface sus necesidades. Aunque un cambio de nivel de servicio inicia la migración inversa, básicamente es una operación del tamaño de los datos entre diferentes arquitecturas. De forma similar a la migración a Hiperescala, la migración inversa es más rápida si se realiza durante un período de poca actividad de escritura. Más información sobre las limitaciones de la migración inversa.

Si ha migrado previamente una base de datos existente de Azure SQL Database al nivel de servicio Hiperescala, puede revertir la migración 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 una migración inversa al nivel de servicio De uso general y, a continuación, modifique el nivel de servicio. La migración inversa es una operación del tamaño de los datos.

Las bases de datos creadas originalmente en el nivel de servicio Hiperescala no se pueden migrar a otros niveles de servicio.

Más información sobre cómo revertir la migración desde Hiperescala, incluidas las limitaciones de la migración inversa y las directivas de copia de seguridad afectadas.

Sí. Algunas características de Azure SQL Database aún no están admitidas en Hiperescala. Si algunas de estas características están habilitadas para la base de datos, se puede bloquear la migración a Hiperescala, o bien estas características dejarán de funcionar después de la migración. Esperamos que estas limitaciones sean temporales. Para más información, consulte las limitaciones conocidas.

Sí. Puede usar muchas de las tecnologías de migración existentes para migrar a Hiperescala, incluida la replicación transaccional y cualquier otra tecnología de movimiento de datos (la copia masiva, Azure Data Factory, Azure Databricks, SSIS). Consulte también Azure Database Migration Service, que admite muchos escenarios de migración.

El tiempo de inactividad para la migración a Hiperescala es igual que el tiempo de inactividad al migrar las bases de datos a otros niveles de servicio de Azure SQL Database. Puede usar la replicación transaccional para minimizar el tiempo de inactividad de la migración para bases de datos de pocos TB de tamaño. Para bases de datos de gran tamaño (más de 10 TB), puede considerar la opción de implementar el proceso de migración con ADF, Spark u otras tecnologías de movimiento de datos masivos.

Hiperescala es capaz de consumir 100 MB/s de datos nuevos o modificados, pero el tiempo necesario para trasladar los datos a las bases de datos de Azure SQL Database también se ve afectado por el rendimiento de la red disponible, la velocidad de lectura del origen y el objetivo de nivel de servicio de la base de datos de destino.

Puede hacer que una aplicación cliente lea datos de Azure Storage y cargue la carga de datos en una base de datos de Hiperescala (al igual que con cualquier otra base de datos de Azure SQL Database). Actualmente, Polybase no se admite en Azure SQL Database. Como alternativa a proporcionar una carga rápida, puede usar Azure Data Factory o usar un trabajo de Spark en Azure Databricks con el conector de Spark para SQL. Este conector admite la inserción masiva.

También es posible leer datos de forma masiva desde el almacén de blobs de Azure mediante BULK INSERT o OPENROWSET: Ejemplos de acceso masivo a datos en Azure Blob Storage.

El modelo de recuperación simple o de registro masivo no se admite en Hiperescala. Se requiere el modelo de recuperación completa para proporcionar alta disponibilidad y recuperación a un momento dado. Sin embargo, la arquitectura de registro de Hiperescala proporciona una mejor tasa de ingesta de datos en comparación con otros niveles de servicio de Azure SQL Database.

No. Hiperescala es una arquitectura de procesamiento múltiple simétrico (SMP) y no un procesamiento paralelo masivo (MPP) ni una arquitectura multimaestro. Solo se pueden crear varias réplicas para escalar horizontalmente cargas de trabajo de solo lectura.

Sí. Azure Database Migration Service admite muchos escenarios de migración.

Consulte Contrato de nivel de servicio para Azure SQL Database. Se recomienda agregar réplicas secundarias de alta disponibilidad para cargas de trabajo críticas. Esto proporciona una conmutación por error más rápida y reduce el posible impacto en el rendimiento inmediatamente después de la conmutación por error.

Sí.

Sí, Hiperescala admite la configuración con redundancia de zona. Se requiere al menos una réplica secundaria de alta disponibilidad y el uso del almacenamiento con redundancia de zona o redundancia geográfica para habilitar la configuración con redundancia de zona para Hiperescala.

Sí. Para obtener más información, consulte Gupos elásticos de Hiperescala y Blog: disponibilidad general de grupos elásticos de Hiperescala.

No hay copias de seguridad tradicionales completas, diferenciales y de registro de transacciones para las bases de datos de Hiperescala. En su lugar, hay instantáneas de almacenamiento normales de archivos de datos, con una cadencia de instantánea independiente para cada archivo. El registro de transacciones generado se conserva tal y como está durante el período de retención configurado. En el momento de la restauración, los registros de transacciones pertinentes se aplican a las instantáneas de almacenamiento restauradas. Independientemente de la cadencia de instantánea, esto genera una base de datos coherente en sus transacciones sin pérdidas de datos en el momento indicado dentro del período de retención. En efecto, la copia de seguridad de la base de datos en Hiperescala es continua.

Sí.

El RPO de la restauración a un momento dado es de 0 min. La mayoría de las operaciones de restauración a un momento dado se completan en 60 minutos independientemente del tamaño de la base de datos. El tiempo de restauración puede ser mayor para las bases de datos de mayor tamaño, y si la base de datos ha experimentado una actividad de escritura importante antes y hasta el punto de restauración en el tiempo. Cambiar la redundancia de almacenamiento al emitir una restauración puede dar lugar a tiempos de restauración más largos, ya que la restauración se basa en el tamaño de los datos y, por tanto, el tiempo será proporcional al tamaño de la base de datos.

No. El subsistema de almacenamiento administra las copias de seguridad y utiliza las instantáneas de almacenamiento. No afectan la carga de trabajo del usuario.

Sí. La restauración geográfica es totalmente compatible si se usa almacenamiento con redundancia geográfica. Este es el valor predeterminado para las bases de datos nuevas. A diferencia de la restauración a un momento dado, la restauración geográfica requiere una operación de tamaño de datos. Los archivos de datos se copian en paralelo, por lo que la duración de esta operación depende sobre todo del tamaño del archivo más grande en la base de datos, en lugar del tamaño total de la base de datos. Los tiempos de la restauración geográfica se reducirán de manera significativa si la base de datos se restaura en la región de Azure que está emparejada con la región de la base de datos de origen.

Sí. La replicación geográfica se puede configurar para bases de datos de Hiperescala.

No. El formato de almacenamiento de las bases de datos de Hiperescala es diferente de cualquier versión de SQL Server y no podría controlar las copias de seguridad ni tener acceso a ellas. Para sacar los datos de una base de datos de Hiperescala, puede extraer datos mediante cualquier tecnología de movimiento de datos, es decir, Azure Data Factory, Azure Databricks, SSIS, etc.

Sí. A partir del 4 de mayo de 2022, las copias de seguridad de todas las bases de datos nuevas se cobran según el almacenamiento de copia de seguridad consumido y la redundancia de almacenamiento seleccionada según las tarifas especificadas en la página de precios de Azure SQL Database. En el caso de las bases de datos de Hiperescala creadas antes del 4 de mayo de 2022, las copias de seguridad solo se cobrarán si la retención de copia de seguridad está establecida en un valor superior a siete días. Para obtener más información, consulte Copias de seguridad de Hiperescala y redundancia de almacenamiento.

La información sobre cómo medir el tamaño del almacenamiento de copia de seguridad se recoge en Copias de seguridad automatizadas.

Para determinar la factura de almacenamiento de copia de seguridad, el tamaño del almacenamiento de copia de seguridad se calcula periódicamente y se multiplica por la tasa de almacenamiento de copia de seguridad y el número de horas desde el último cálculo. Para calcular una estimación de la factura de copia de seguridad durante un período de tiempo, multiplique el tamaño del almacenamiento de copia de seguridad facturable por cada hora del período por la tasa de almacenamiento de copia de seguridad y sume todos los importes por hora. Para consultar las métricas pertinentes de Azure Monitor durante varios intervalos por hora mediante programación, use la API de REST de Azure Monitor. La facturación de la copia de seguridad en el nivel de proceso sin servidor es la misma que en el nivel de proceso aprovisionado.

Los costos de copia de seguridad serán mayores para las cargas de trabajo que agregan, modifican o eliminan grandes volúmenes de datos en la base de datos. Por el contrario, las cargas de trabajo que son principalmente de solo lectura pueden tener costes de copia de seguridad más pequeños.

La información sobre cómo minimizar los costos de almacenamiento de copia de seguridad se recoge en Copias de seguridad automatizadas.

El límite de rendimiento del registro de transacciones se establece en 100 MB/s para cualquier tamaño de proceso de Hiperescala. La capacidad de lograr esta tasa depende de varios factores, entre los que se incluyen el tipo de carga de trabajo, la configuración y el rendimiento del cliente, y tener la capacidad de proceso suficiente en la réplica de proceso principal para generar los registros a esta velocidad.

Las IOPS y la latencia de E/S variarán según los patrones de carga de trabajo. Si los datos a los que se accede se almacenan en caché en RBPEX en la réplica de proceso, verá un rendimiento de E/S similar al de los niveles de servicio Crítico para la empresa o Premium.

No. El proceso no está acoplado con la capa de almacenamiento. Esto elimina el impacto en el rendimiento de la copia de seguridad.

Como el almacenamiento se comparte y no hay ninguna replicación física directa entre la réplica de proceso principal y las secundarias, el rendimiento de la réplica principal no se verá afectado directamente al agregar réplicas secundarias. Sin embargo, es posible que se limiten las cargas de trabajo de escritura continua e intensiva en la principal para permitir que la aplicación del registro en las réplicas secundarias y en los servidores de páginas se ponga al día. Esto evita un rendimiento de lectura deficiente en las réplicas secundarias y una recuperación prolongada después de la conmutación por error a una réplica secundaria de alta disponibilidad.

Sí. Sin embargo, al igual que en otras bases de datos de Azure SQL DB, es posible que las conexiones finalicen por errores transitorios muy poco frecuentes, lo que puede anular las consultas de larga duración y revertir las transacciones. Una causa de los errores transitorios es cuando el sistema desplaza rápidamente la base de datos a un nodo de ejecución diferente para garantizar la disponibilidad continua de los recursos de proceso y almacenamiento, o para realizar un mantenimiento planeado. La mayoría de estos eventos de reconfiguración se completan en menos de 10 segundos. Las aplicaciones que se conectan a la base de datos deben crearse para esperar y tolerar estos errores transitorios poco frecuentes mediante la implementación de la lógica de reintento. Además, considere la posibilidad de configurar una ventana de mantenimiento que coincida con la programación de la carga de trabajo para evitar errores transitorios debidos al mantenimiento planeado.

Para la mayoría de los problemas de rendimiento, especialmente los que no tienen el origen en el rendimiento del almacenamiento, se aplican los pasos de diagnóstico y solución de problemas habituales de SQL. Para obtener información sobre el diagnóstico de almacenamiento específico de Hiperescala, vea Diagnóstico de la solución de problemas de rendimiento de Hiperescala de SQL.

La cantidad máxima de memoria que una base de datos sin servidor puede escalar verticalmente es de 3 GB/núcleo virtual por el número máximo de núcleos virtuales configurados, en comparación con más de 5 GB/núcleo virtual por el mismo número de núcleos virtuales en el proceso aprovisionado. Consulte los límites de recursos de Hiperescala sin servidor para más información.

El proceso de escalado o reducción vertical en el nivel del proceso aprovisionado tarda hasta dos minutos independientemente del tamaño de los datos. En el nivel de proceso sin servidor, donde el proceso se escala automáticamente en función de la demanda de la carga de trabajo, el tiempo de escalado suele ser de menos de un segundo, pero en ocasiones puede tardar tanto tiempo como al escalar el proceso aprovisionado.

No. Una base de datos permanece con conexión durante las operaciones para escalar o reducir verticalmente.

El escalado o la reducción vertical del proceso aprovisionado provoca que las conexiones existentes se bloqueen cuando se produce una conmutación por error al final de la operación de escalado. En el proceso sin servidor, el escalado automático no provoca normalmente el bloqueo de una conexión, pero sí se puede producir de manera ocasional. La adición o eliminación de réplicas secundarias no da lugar a que la conexión se elimine en la réplica principal.

El usuario final realiza el escalado en el proceso aprovisionado. El servicio realiza el escalado automático en el proceso sin servidor.

Sí. El tamaño de la base de datos de tempdb y la caché RBPEX de los nodos de proceso se escalan verticalmente de forma automática a medida que aumenta el número de núcleos. Para más información, consulte Tamaños de almacenamiento y proceso de Hiperescala.

No. Solo la réplica de proceso principal acepta solicitudes de lectura y escritura. Las réplicas de proceso secundarias aceptan únicamente solicitudes de solo lectura.

Hiperescala admite réplicas de alta disponibilidad (HA), réplicas con nombre y réplicas geográficas. Consulte Réplicas secundarias de Hiperescala para más información.

Entre 0 y 4. Si quiere ajustar el número de réplicas, puede hacerlo a través de Azure Portal o la API REST.

Puede conectarse a estas réplicas de proceso adicionales de solo lectura estableciendo la propiedad ApplicationIntent de la cadena de conexión en ReadOnly. Las conexiones marcadas con ReadOnly se enrutan automáticamente a una de las réplicas secundarias de alta disponibilidad, si están presentes. Para obtener información, consulte Uso de réplicas de solo lectura para descargar cargas de trabajo de consulta de solo lectura.

Puede ejecutar la siguiente consulta de Transact-SQL: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). El resultado es READ_ONLY si está conectado a una réplica secundaria de solo lectura y READ_WRITE, si está conectado a la réplica principal. El contexto de la base de datos debe establecerse en el nombre de su base de datos, no en la base de datos de master.

No. Solo puede conectarse a réplicas secundarias de alta disponibilidad especificando ApplicationIntent=ReadOnly. Sin embargo, puede usar puntos de conexión dedicados para réplicas con nombre.

No. Una nueva conexión con intención de solo lectura se redirige a una réplica secundaria de alta disponibilidad arbitraria.

Esto no ocurre en el nivel de proceso aprovisionado. Las réplicas secundarias de alta disponibilidad se usan como destinos de conmutación por error de alta disponibilidad, por lo que deben tener la misma configuración que la principal para proporcionar el rendimiento esperado después de la conmutación por error. En el modo sin servidor, el proceso se escala automáticamente para cada réplica de alta disponibilidad en función de su demanda de carga de trabajo individual. Cada secundaria de alta disponibilidad es capaz aún de escalar automáticamente a los núcleos máximos configurados para dar cabida a su rol posterior a la conmutación por error. Las réplicas con nombre ofrecen la posibilidad de escalar cada réplica de forma independiente.

No. La base de datos tempdb está configurada según el tamaño de proceso aprovisionado, y las réplicas secundarias de alta disponibilidad son del mismo tamaño, lo que incluye tempdb, como proceso principal. En las réplicas con nombre, tempdb tiene un tamaño adaptado al proceso de la réplica, por lo que puede ser menor o mayor que tempdb de la réplica principal.

No. Las réplicas de proceso de bases de datos de Hiperescala tienen el almacenamiento compartido, lo que significa que todas las réplicas de proceso ven las mismas tablas, índices y otros objetos de base de datos. Si desea índices adicionales optimizados para lecturas en la réplica secundaria, debe primero agregarlos a la réplica principal. Aún puede crear tablas temporales (nombres de tabla con el prefijo # o ##) en cada réplica secundaria para almacenar datos temporales. Las tablas temporales son de lectura y escritura.

La latencia de los datos desde el momento en que se confirma una transacción en el servidor principal hasta que se puede leer en una secundaria depende de la velocidad de generación de registros actual, el tamaño de las transacciones, la carga en la réplica y otros factores. La latencia de los datos típica para las transacciones pequeñas es de decenas de milisegundos; sin embargo, no hay límite superior en la latencia de los datos. Los datos de una réplica secundaria determinada siempre son coherentes en sus transacciones, por lo que las transacciones de mayor tamaño tardan más tiempo en propagarse. Sin embargo, en un momento dado, la latencia de datos y el estado de la base de datos pueden ser diferentes para las distintas réplicas secundarias. Las cargas de trabajo que necesitan leer los datos confirmados inmediatamente deben ejecutarse en la réplica principal.

No, las réplicas con nombre no se pueden usar como destinos de conmutación por error para la réplica principal. Agregue réplicas de alta disponibilidad con ese fin.

Dado que cada réplica con nombre puede tener un objetivo de nivel de servicio diferente y, por tanto, usarse para distintos casos de uso, no hay ninguna manera integrada de dirigir el tráfico de solo lectura enviado a la réplica principal a un conjunto de réplicas con nombre. Por ejemplo, puede tener ocho réplicas con nombre y puede querer dirigir la carga de trabajo de OLTP solo a las réplicas con nombre 1 a 4, mientras que las cargas de trabajo de análisis de Power BI usan las réplicas con nombre 5 y 6 y la carga de trabajo de ciencia de datos usa las réplicas 7 y 8. En función de la herramienta o el lenguaje de programación que use, las estrategias para distribuir dicha carga de trabajo pueden variar. Para ver un ejemplo de creación de una solución de enrutamiento de cargas de trabajo para permitir que un back-end de REST se escale horizontalmente, consulte el ejemplo de escalabilidad horizontal de OLTP.

No, como las réplicas con nombre usan los mismos servidores de páginas que la réplica principal, deben estar en la misma región.

Una réplica con nombre no puede afectar a la disponibilidad de la réplica principal. Las réplicas con nombre, en circunstancias normales, no suelen afectar al rendimiento de la principal, pero puede ocurrir si hay cargas de trabajo intensivas en ejecución. Al igual que una réplica de alta disponibilidad, una réplica con nombre se mantiene sincronizada con la principal mediante el servicio de registro de transacciones. Si, por cualquier motivo, una réplica con nombre no puede consumir el registro de transacciones lo suficientemente rápido, comenzará a pedir a la réplica principal que ralentice (limite) su generación de registros para que pueda ponerse al día. Aunque este comportamiento no afectará a la disponibilidad de la principal, puede afectar al rendimiento de las cargas de trabajo de escritura en la principal. Para evitar esta situación, asegúrese de que las réplicas con nombre tengan suficientes recursos libres (principalmente CPU) para que puedan procesar el registro de transacciones sin retraso. Por ejemplo, si la principal está procesando numerosos cambios de datos, se recomienda tener las réplicas con nombre con al menos el mismo objetivo de nivel de servicio que la principal para evitar la saturación de la CPU de las réplicas y, por tanto, forzar la ralentización de la réplica principal.

Las réplicas con nombre seguirán estando disponibles para el acceso de solo lectura, como de costumbre.

De manera predeterminada, las réplicas con nombre no tienen sus propias réplicas de alta disponibilidad. Una conmutación por error de una réplica con nombre requiere crear primero una nueva réplica, que normalmente tarda entre 1 y 2 minutos. Sin embargo, las réplicas con nombre también pueden beneficiarse de una mayor disponibilidad y de conmutación por error más corta proporcionada por las réplicas de alta disponibilidad. Para agregar réplicas de alta disponibilidad para una réplica con nombre, puede usar el parámetro ha-replicas con AZ CLI o el parámetro HighAvailabilityReplicaCount con PowerShell o la propiedad highAvailabilityReplicaCount con la API REST. El número de réplicas de alta disponibilidad se puede establecer durante la creación de una réplica con nombre y se puede cambiar (solo mediante la CLI de zonas de disponibilidad, PowerShell o la API de REST) en cualquier momento después de crear la réplica con nombre. Los precios de las réplicas de alta disponibilidad para las réplicas con nombre son los mismos que las réplicas de alta disponibilidad para las bases de datos de hiperescala anormales.

Sí. La clave maestra de columna se almacena en la base de datos de usuario y se puede validar si se ejecuta la consulta SELECT * FROM sys.column_master_keys. Las réplicas con nombre y las réplicas secundarias de alta disponibilidad leen datos de la misma capa de almacenamiento o servidores de página que la base de datos de Hiperescala principal. Ambos tipos de réplicas se sincronizan con la base de datos de Hiperescala principal a través del servicio de registro. Un cambio de clave se considera una transacción y se replica automáticamente en la réplica con nombre y la réplica secundaria de alta disponibilidad.

La función DATABASEPROPERTYEX(), cuando se ejecuta dentro del contexto de una réplica con nombre, puede asignar a replica_id su réplica con nombre correspondiente. Sin embargo, actualmente no es factible vincular a replica_id su réplica con nombre correspondiente para cada registro de la vista de administración dinámica sys.dm_database_replica_states cuando se consulta desde la réplica principal. La consulta de ejemplo siguiente se puede ejecutar dentro del contexto de una réplica con nombre para identificar el nombre de la réplica, el identificador de réplica y los detalles de sincronización.

  SELECT replica_id, DB_NAME() AS 'Database/Replica name', 
  synchronization_state_desc, log_send_queue_size/1024.0/1024.0 AS log_send_queue_size_gb,
  last_sent_time, last_received_time, last_commit_time, secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE replica_id = DATABASEPROPERTYEX(DB_NAME(),'REPLICAID');

Contenido relacionado

Para obtener más información sobre el nivel de servicio Hiperescala, vea Nivel de servicio Hiperescala.