Prácticas recomendadas generales

Las instancias de Cloud SQL no aceptarán nuevas solicitudes de operación hasta que hayan completado la operación anterior. Si intentas iniciar una nueva operación antes de tiempo, la solicitud de operación fallará. Esto incluye reinicios de instancias.

El estado de la instancia en la consola Google Cloud no refleja si una operación se está ejecutando. La marca de verificación verde solo indica que la instancia está en el estado RUNNABLE. Para ver si una operación está en curso, ve a la pestaña Operaciones y comprueba el estado de la operación más reciente.

Si el ajuste de instancia Habilitar aumentos automáticos del almacenamiento está inhabilitado o el límite de aumento automático del almacenamiento está habilitado, asegúrese de que tiene al menos un 20% de espacio disponible para dar cabida a las operaciones de mantenimiento críticas de la base de datos que pueda realizar Cloud SQL.

Para recibir una alerta cuando el espacio de disco disponible sea inferior al 20%, crea una política de alertas basada en métricas para la métrica Utilización del disco con la posición Por encima del umbral y el valor 0,8. Para obtener más información, consulta Crear políticas de alertas basadas en métricas.

Puedes ver el porcentaje de CPU disponible que está usando tu instancia en la página de detalles de la instancia de la Google Cloud consola. Para obtener más información, consulta Métricas. También puedes monitorizar el uso de la CPU y recibir alertas cuando se alcance un umbral específico con la opción Crear políticas de alertas de umbral de métricas.

Para evitar que se sobreutilice, puedes aumentar el número de CPUs de tu instancia. Para cambiar las CPUs, es necesario reiniciar la instancia. Si tu instancia ya tiene el número máximo de CPUs, debes fragmentar tu base de datos en varias instancias.

Cuando busques señales de agotamiento de la memoria, debes usar principalmente la métrica Uso. Para evitar errores de falta de memoria, te recomendamos que esta métrica se mantenga por debajo del 90%.

También puedes usar la métrica total_usage para observar el porcentaje de memoria disponible que usa tu instancia de Cloud SQL, incluida la memoria que usa el contenedor de la base de datos y la memoria asignada por la caché del sistema operativo.

Al observar la diferencia entre las dos métricas, puedes identificar cuánta memoria usan los procesos y cuánta usa la caché del sistema operativo. Puedes reutilizar la memoria en esta caché.

Para predecir problemas de falta de memoria, comprueba ambas métricas e interprétalas conjuntamente. Si las métricas son altas, es posible que la instancia tenga poca memoria. Esto puede deberse a una configuración personalizada, a que la instancia no tenga el tamaño adecuado para la carga de trabajo o a una combinación de estos factores.

Escala tu instancia de Cloud SQL para aumentar el tamaño de su memoria. Para cambiar el tamaño de la memoria de una instancia, es necesario reiniciarla. Si tu instancia ya tiene el tamaño máximo de memoria, debes fragmentar tu base de datos en varias instancias. Para obtener más información sobre cómo monitorizar ambas métricas en la Google Cloud consola, consulta Métricas.

• vCPU: 40
• Memoria: 262144 MB
• MAXDOP: 8
• Umbral de coste para el paralelismo: 120
• Archivos tempdb: 8. Se ha definido el tamaño previamente para evitar que crezca automáticamente.
• Archivos de base de datos de usuarios: crecimiento automático definido en 64-128 MB. Tamaño predefinido para evitar el crecimiento automático.
• Almacenamiento: >= 4TB para obtener los mejores IOPS

Prueba varios tipos y tamaños de E/S. El tamaño de las E/S emitidas al almacenamiento en disco persistente procedentes de SQL Server afecta a las IOPS y al rendimiento. La carga de trabajo de SQL Server se limita cuando alcanza el límite de IOPS o el límite de rendimiento. El tipo de almacenamiento que se usa en Cloud SQL es SSD de disco persistente, que es adecuado para cargas de trabajo empresariales de alto rendimiento.

Personaliza la VM para maximizar el rendimiento de la siguiente manera:

• Un tamaño de disco de 4 TB o más proporciona un mayor rendimiento y más IOPS.
• Cuanto mayor sea el número de vCPUs, mayor será el número de IOPS y el rendimiento. Cuando se usa una vCPU más alta, se monitorizan las esperas de la base de datos para el paralelismo, que también puede aumentar.
• Para obtener un rendimiento óptimo, emite E/S en paralelo para conseguir una mayor profundidad de cola de E/S.

Defina autogrow en MB en lugar de como porcentaje, con incrementos adecuados para el requisito. Además, gestiona de forma proactiva el crecimiento antes de que se active el crecimiento automático.

Además, asegúrate de que la función Habilitar aumentos automáticos de almacenamiento de Cloud SQL esté habilitada para que Cloud SQL pueda añadir espacio de almacenamiento si la base de datos y la instancia se quedan sin espacio.

• Clona una base de datos y ejecuta DBCC CHECKDB en la base de datos clonada.
• Restaura una copia de seguridad en otra instancia y, a continuación, ejecuta DBCC CHECKDB en las bases de datos de la instancia restaurada. Para obtener más información sobre cómo restaurar una instancia, consulta Restaurar una instancia.

Usa los siguientes fragmentos de código para ejecutar DBCC CHECKDB en una base de datos:

• (Recomendado) Ejecuta DBCC CHECKDB con EXTENDED_LOGICAL_CHECKS. Se trata de una comprobación exhaustiva, pero requiere más recursos.

        USE DATABASE_NAME
        DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS,
        DATA_PURITY,NO_INFOMSGS, ALL_ERRORMSGS
        

• Ejecuta DBCC CHECKDB con PHYSICAL_ONLY:

        USE DATABASE_NAME
        DBCC CHECKDB WITH PHYSICAL_ONLY,
        NO_INFOMSGS, ALL_ERRORMSGS
        

• Copias de seguridad periódicas: asegúrate de programar copias de seguridad periódicas de tus bases de datos. En caso de que los datos se dañen, podrás restaurarlos al último estado seguro conocido.
• Verificación de la copia de seguridad: como las opciones de reparación de DBCC no están disponibles para las tablas optimizadas para memoria, se recomienda que pruebe la copia de seguridad ejecutando restauraciones periódicas. Si se producen problemas de integridad de datos en una tabla optimizada para memoria, debe restaurar la última copia de seguridad segura conocida.

Para obtener más información sobre las limitaciones, consulta Funciones de SQL Server no admitidas para OLTP en memoria.

El número de tablas de tu instancia no debe superar las 10.000. Si una base de datos tiene demasiadas tablas, puede afectar al tiempo de actualización de la base de datos.

Las copias de seguridad y las exportaciones son formas de proporcionar redundancia y protección de datos. Cada una de ellas protege contra diferentes situaciones y se complementan entre sí en una estrategia de protección de datos sólida.

Las copias de seguridad son ligeras y te permiten restaurar los datos de tu instancia al estado que tenían en el momento en que se creó la copia de seguridad. Sin embargo, las copias de seguridad tienen algunas limitaciones. Si eliminas la instancia, también se eliminarán las copias de seguridad. No puedes crear copias de seguridad de una sola base de datos o tabla. Además, si la región en la que se encuentra la instancia no está disponible, no podrás restaurarla a partir de esa copia de seguridad, aunque sea en una región disponible.

Las exportaciones tardan más en crearse porque se crea un archivo externo en Cloud Storage que se puede usar para recrear tus datos. Las exportaciones no se verán afectadas si eliminas la instancia. Además, solo puedes exportar una base de datos o una tabla, en función del formato de exportación que elijas.

Cuando uses la función de exportación de copias de seguridad en una instancia de SQL Server Enterprise o Standard, no crees un archivo GZ, ya que intenta comprimir una copia de seguridad que ya está comprimida de forma nativa por SQL Server.

Las instancias de Cloud SQL que creas en la Google Cloud consola o mediante Terraform tienen habilitada la prevención de eliminación accidental de forma predeterminada.

Usa la función de exportación de Cloud SQL para exportar tus datos y obtener una protección adicional. Usa Cloud Scheduler con la API REST para automatizar la gestión de las exportaciones. Para casos más avanzados, puedes usar Cloud Scheduler con funciones de Cloud Run para la automatización.

Esta marca limita la cantidad de memoria que Cloud SQL puede asignar a sus grupos internos.

Te recomendamos que dejes que Cloud SQL gestione el valor de esta marca. Si tienes que gestionar este valor manualmente, usa la fórmula que se indica más adelante en esta sección.

Si no asignas un valor a esta marca, Cloud SQL gestionará el valor automáticamente en función del tamaño de la RAM de tu instancia. Si no defines un valor para la marca y cambias el tamaño de tu instancia, Cloud SQL ajustará automáticamente el valor de la marca para cumplir nuestras recomendaciones sobre el nuevo tamaño de la instancia. Esta operación de cambio de tamaño también elimina cualquier valor que se haya definido manualmente para esta marca. De esta forma, tu base de datos puede utilizar los recursos de forma más eficaz, ya que se evita la asignación excesiva, se reduce la probabilidad de que se produzca un fallo debido a problemas de falta de memoria y se evita que el rendimiento de tu instancia se vea afectado.

Si prefieres gestionar el valor de esta marca, configúralo manualmente. Por lo tanto, Cloud SQL desactiva la gestión automática. Si cambias el tamaño de la instancia, se descartará el valor introducido manualmente. Al cambiar el tamaño de la instancia, se reactiva la gestión automática de las marcas. Si, después de cambiar el tamaño, quieres controlar manualmente el valor de la marca, tendrás que introducir un valor nuevo para reactivar el control manual. Te recomendamos que revises el valor para que coincida con los valores recomendados de un nuevo tamaño.

Si debes gestionar manualmente el valor de la marca, te recomendamos que uses la siguiente fórmula para definir la marca de base de datos max server memory (mb):

• Reserva 1,4 GB de memoria para el SO y los agentes.
• Si la RAM del servidor es igual o inferior a 16 GB, reserva 1 GB de memoria por cada 4 GB de RAM.
• Si la RAM del servidor es superior a 16 GB, deja 4 GB de memoria y reserva 1 GB de memoria por cada 8 GB de RAM que supere los 16 GB.

Por ejemplo, si la RAM de tu instancia es de 104 GB
(106496 MB), reserva lo siguiente:

• 1,4 GB de memoria para el SO y los agentes
• 4 GB de memoria, ya que 104 GB es más que 16 GB
• 11 GB de memoria, ya que hay 88 GB de RAM, que es más que 16 GB (104 - 16=88), y 88 dividido entre 8 es 11

En este ejemplo, debes reservar 16,4 GB de memoria. Por lo tanto, para el valor de esta marca, especifica 89702 MB
[(104 - 16,4) * 1024 = 89702].

En la siguiente tabla se muestran los valores y porcentajes recomendados de la RAM total para algunos niveles de máquinas virtuales (VMs) populares:

Para monitorizar el uso de memoria de tu instancia, utiliza las siguientes métricas:

• database/memory/usage
• database/sqlserver/memory/buffer_cache_hit_ratio
• database/sqlserver/memory/memory_grants_pending
• database/sqlserver/memory/page_life_expectancy

Para obtener más información, consulta Monitorizar instancias de Cloud SQL.

Es el umbral en el que el optimizador de SQL ejecuta una consulta mediante el paralelismo. El valor predeterminado de 5 puede provocar que se ejecuten demasiadas consultas en paralelo, lo que aumenta el tiempo de espera de la base de datos en los subprocesos paralelos. Para reducir este tipo de contención, aumenta el valor.

El valor se ignora cuando maxdop se define como 1.

Para reducir los tiempos de espera de la base de datos debido al paralelismo, ajusta este valor en función de las recomendaciones específicas sobre el número de procesadores lógicos disponibles. Mide el rendimiento con cuidado si estableces esta opción en 1.

Para obtener más información, consulta max degree of parallelism (MAXDOP).

Evita tener un gran número de planes de un solo uso en la caché de planes. Para mejorar la eficiencia de la caché del plan en cargas de trabajo que contienen muchos lotes ad hoc de un solo uso, defina esta opción en 1.

Asigna un tamaño previo a tempdb para que no tenga que crecer automáticamente. Todos los archivos de tempdb deben tener el mismo tamaño y el mismo crecimiento de archivo.

El tipo de espera de la base de datos para la contención de tempdb se muestra como PAGELATCH_UP. Para reducir la contención, añade más archivos.

Si el número de procesadores es igual o inferior a 8, usa el mismo número de archivos que de procesadores lógicos. Si el número de procesadores es superior a 8, usa 8 archivos de datos. Si la contención continúa, aumenta el número de archivos en múltiplos de 4 hasta que no haya más contención.

Sin embargo, si espera un tiempo de respuesta predecible para una consulta que se ejecuta con frecuencia o si su aplicación experimenta con frecuencia tiempos de espera de solicitudes de clientes mientras espera actualizaciones de estadísticas, considere habilitar esta opción e inhabilitar Auto Update Statistics.