Prácticas recomendadas generales

En esta página, se proporcionan las prácticas recomendadas para obtener rendimiento, durabilidad y disponibilidad óptimos de Cloud SQL.

Si se producen problemas con tu instancia de Cloud SQL, revisa lo siguiente cuando trates de solucionarlos:

Configuración y administración de instancia

Práctica recomendada Más información
Lee y sigue los lineamientos operativos para asegurarte de que tus instancias estén cubiertas por el ANS de Cloud SQL.
Configura un período de mantenimiento para tu instancia principal a fin de controlar cuándo pueden ocurrir las actualizaciones con interrupciones. Consulta Período de mantenimiento.
Si borras y vuelves a crear instancias con regularidad, usa una marca de tiempo en el ID de instancia para aumentar la probabilidad de que puedan usarse ID de instancia nuevos.
No inicies una operación administrativa antes de que haya finalizado la operación anterior.

Las instancias de Cloud SQL no aceptan solicitudes de operación nuevas hasta haber completado la operación anterior. Si intentas iniciar una operación nueva de forma prematura, fallará la solicitud de operación. Esto incluye reinicios de la instancia.

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

Configura el almacenamiento para adaptar el mantenimiento fundamental de la base de datos.

Si la configuración para habilitar los aumentos de almacenamiento automáticos está inhabilitada o si el límite de aumento de almacenamiento automático está habilitado, asegúrate de tener al menos un 20% disponible de espacio para alojar cualquier operación crítica de mantenimiento de base de datos que Cloud SQL pueda realizar.

A fin de recibir alertas sobre el espacio disponible en el disco que sea inferior al 20%, crea una política de alertas basada en métricas para la métrica de uso del disco con una posición de límite superior y un valor de 0.8. Para obtener más información, consulta Crea políticas de alertas basadas en métricas.
Evita el uso excesivo de tu CPU.

Puedes ver el porcentaje de CPU disponible que está utilizando tu instancia en la página de detalles de la instancia en la consola de Google Cloud. Para obtener más información, consulta Métricas. También puedes supervisar el uso de CPU y recibir alertas en un límite especificado mediante Crea políticas de alertas de límite de métricas.

Para evitar el uso excesivo, puedes aumentar la cantidad de CPU para tu instancia. Para cambiar las CPU, se debe reiniciar la instancia. Si la instancia ya tiene la cantidad máxima de CPU, debes fragmentar la base de datos en varias instancias.
Evita el agotamiento de la memoria.

Cuando busques signos de agotamiento de memoria, debes usar principalmente la métrica de uso. Para evitar errores de memoria insuficiente, te recomendamos que esta métrica permanezca 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 usada por el contenedor de la base de datos y la memoria asignada por la caché del sistema operativo.

Si observas la diferencia entre las dos métricas, puedes identificar cuánta memoria usan los procesos y cuánto usa la caché del sistema operativo. Puedes volver a usar la memoria en esta caché.

Para predecir problemas de memoria insuficiente, verifica ambas métricas y, luego, impleméntalas. Si las métricas parecen altas, es posible que la instancia tenga poca memoria. Esto puede deberse a una configuración personalizada, a que la instancia tiene un tamaño insuficiente 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 la instancia, se debe reiniciar la instancia. Si tu instancia ya tiene el tamaño máximo de memoria, debes fragmentar la base de datos en varias instancias. Para obtener más información sobre cómo supervisar ambas métricas en la consola de Google Cloud, consulta Métricas.
Establece la configuración de SQL Server a fin de que funcione de manera óptima para Cloud SQL. Consulta Configuración de SQL Server.
Ajusta la instancia de forma óptima para ejecuciones de pruebas. En la siguiente tabla, se enumeran los valores de configuración adecuados para las ejecuciones de prueba.
  • CPU virtual: 40
  • Memoria: 262144 MB
  • MAXDOP: 8
  • Umbral de costo para paralelismo: 120
  • Archivos temporales: 8. Cambia el tamaño para evitar el crecimiento automático.
  • Archivos de base de datos de usuarios: El crecimiento automático se establece en 64-128 MB. Cambia el tamaño para evitar el crecimiento automático.
  • Almacenamiento: >= 4TB para obtener las mejores IOPS
Determina la capacidad del subsistema de E/S antes de implementar SQL Server.

Prueba diferentes tipos y tamaños de E/S. El tamaño de la E/S emitida al almacenamiento en disco persistente proveniente de SQL Server afecta las IOPS y la capacidad de procesamiento. La carga de trabajo de SQL Server se limita cuando alcanza el límite de IOPS o de capacidad de procesamiento. El tipo de almacenamiento que se usa en Cloud SQL es PD SSD, que es adecuado para cargas de trabajo de nivel empresarial de alto rendimiento.

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

  • Un disco de 4 TB o más proporciona más capacidad de procesamiento y también IOPS.
  • Una CPU virtual más alta proporciona más IOPS y capacidad de procesamiento. Cuando uses una CPU virtual más alta, supervisa la espera de la base de datos en busca de paralelismo, que también podría aumentar.
  • Para obtener un rendimiento óptimo, emite E/S en paralelo a fin de lograr una mayor profundidad de colas de E/S.
Evita la fragmentación del índice y los índices faltantes. Reorganiza tu índice o establece un programa para volver a compilar tu índice según la frecuencia con la que cambien tus datos. Además, configura un factor de relleno adecuado para reducir la fragmentación. Supervisa SQL Server para detectar índices faltantes que podrían ofrecer un mejor rendimiento.
Actualiza las estadísticas con regularidad. Si las estadísticas están desactualizadas, el optimizador de consultas en SQL podría generar planes de consulta deficientes. Actualiza las estadísticas especialmente después de que se hayan cambiado grandes cantidades de datos. Usa el almacén de consultas para supervisar y solucionar problemas del SQL Server que tiene planes de consultas subóptimos.
Evita que los archivos de la base de datos se vuelvan demasiado grandes.

Configura autogrow en MB, en lugar de como un porcentaje, con incrementos apropiados para el requisito. Además, administra de forma proactiva el crecimiento antes de que se inicie el crecimiento automático.

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

Ejecuta DBCC CHECKDB para detectar los problemas de integridad de la base de datos al menos una vez a la semana. DBCC CHECKDB verifica la integridad de todos los objetos de una base de datos. Si ejecutas DBCC CHECKDB semanalmente, puedes asegurarte de que tus bases de datos no estén dañadas. DBCC CHECKDB es una operación de uso intensivo de recursos que puede afectar el rendimiento de tu instancia.
No ejecutes DBCC CHECKDB en un servidor de producción.
Te recomendamos que uses una de las siguientes opciones en lugar de ejecutar DBCC CHECKDB en un servidor de producción:
  • Clona una base de datos y ejecuta DBCC CHECKDB en la base de datos clonada.
  • Restablece una copia de seguridad a otra instancia y, luego, ejecuta DBCC CHECKDB en las bases de datos de la instancia restablecida. Para obtener más información sobre cómo restablecer una instancia, consulta Restablece una instancia.

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

  • Ejecuta DBCC CHECKDB para EXTENDED_LOGICAL_CHECKS (recomendado). Esta es una verificación integral, pero con un uso intensivo de los 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

Arquitectura de datos

Práctica recomendada Más información
Divide tus instancias grandes en instancias más pequeñas, de ser posible. Siempre que sea posible, el uso de varias instancias más pequeñas de Cloud SQL es mejor que usar una instancia grande. Gestionar una instancia grande y monolítica presenta desafíos que no ocurren con un grupo de instancias más pequeñas.
No uses demasiadas tablas de base de datos.

Mantén el recuento de tablas de tu instancia en menos de 10,000. Demasiadas tablas de base de datos pueden afectar el tiempo de actualización de la base de datos.

Intercalación de la base de datos Ya sea que instales una instancia nueva de SQL Server, restablezcas una copia de seguridad de una base de datos o conectes un servidor a las bases de datos de clientes, es importante comprender los requisitos de configuración regional, el orden y la distinción de acentos y entre mayúsculas y minúsculas de los datos con los que trabajas. Cuando seleccionas una intercalación para tu servidor, base de datos, columna o expresión, asignas ciertas características a tus datos. Estas características afectan los resultados de muchas operaciones en la base de datos. Por ejemplo, cuando construyes una consulta mediante ORDER BY, el orden del conjunto de resultados puede depender de la intercalación que se aplica a la base de datos o que se dicta en una cláusula COLLATE a nivel de expresión de la consulta. Obtén más información sobre las intercalaciones de bases de datos y la compatibilidad con Unicode.
Diseño de consultas Para obtener un rendimiento óptimo de las bases de datos o las consultas, asegúrate de no usar una gran cantidad de tablas dentro de la misma consulta (dieciseis o más).
Supervisión de consultas Es posible que las consultas se degraden con el tiempo. Es importante supervisar el rendimiento de las aplicaciones y las consultas a lo largo del tiempo. Un motivo de esta degradación son los rescates de hash.
Las uniones de hash o rescates de hash recurrentes hacen que el rendimiento sea menor en un servidor. Si ves muchos eventos de advertencia de hash en un seguimiento, actualiza las estadísticas en las columnas que se unen. Obtén más información sobre los rescates de hash.

Implementación de la aplicación

Práctica recomendada Más información
Implementa prácticas adecuadas de administración de conexiones, como la agrupación de conexiones y la retirada exponencial. El uso de estas técnicas mejora el uso de los recursos por parte de tu aplicación y te ayuda a mantenerte dentro de los límites de conexión de Cloud SQL. Para obtener más información y ejemplos de códigos, consulta la página Administra conexiones de bases de datos.
Verifica la respuesta de tu aplicación a las actualizaciones de mantenimiento, que pueden ocurrir en cualquier momento durante el período de mantenimiento. Prueba el mantenimiento de autoservicio para simular una actualización de mantenimiento. Durante el mantenimiento la instancia deja de estar disponible durante un período breve y las conexiones existentes se descartan. La prueba de los lanzamientos de mantenimiento te permite comprender mejor cómo tu aplicación controla el mantenimiento programado y qué tan rápido se puede recuperar el sistema.
Verifica la respuesta de tu aplicación a las conmutaciones por error, que pueden ocurrir en cualquier momento. Puedes iniciar una conmutación por error de forma manual con la consola de Google Cloud, la CLI de gcloud o la API. Consulta Inicia la conmutación por error.
Evita las transacciones grandes. Mantén las transacciones pequeñas y cortas. Si se requiere una actualización grande de la base de datos, hazla en varias transacciones más pequeñas en lugar de en una transacción grande.
Si usas el proxy de Cloud SQL Auth, asegúrate de usar la versión más reciente. Consulta Mantén el proxy de Cloud SQL Auth actualizado.

Importación y exportación de datos

Práctica recomendada Más información
Acelera las importaciones para tamaños de instancia más pequeños. Para las instancias pequeñas, puedes aumentar temporalmente la CPU y la RAM de una instancia a fin de mejorar el rendimiento cuando importas conjuntos de datos grandes.
Si exportas datos para importarlos a Cloud SQL, asegúrate de usar el procedimiento adecuado. Consulta Exporta datos desde un servidor de base de datos administrado de forma externa.

Copia de seguridad y recuperación

Práctica recomendada Más información
Protege tus datos con la funcionalidad de Cloud SQL adecuada.

Las copias de seguridad y las exportaciones son modos de brindar redundancia y protección de datos. Cada uno brinda protección frente a situaciones diferentes y se complementan en una estrategia sólida de protección de datos.

Las copias de seguridad son livianas; proporcionan una forma de restablecer los datos en tu instancia al estado en el que se encontraban cuando se creó la copia de seguridad. Sin embargo, las copias de seguridad tienen algunas limitaciones. Si borras la instancia, también se borrarán las copias de seguridad. No puedes realizar una copia de seguridad de una sola tabla o base de datos. Si la región donde se encuentra la instancia no está disponible, no podrás restablecer la instancia desde esa copia de seguridad, incluso en una región disponible.

Las exportaciones tardan más tiempo en crearse porque se genera un archivo externo en Cloud Storage que puede usarse para recrear tus datos. Las exportaciones no se ven afectadas si borras la instancia. Además, puedes exportar solo una base de datos única o incluso una tabla, según el formato de exportación que elijas.

Cuando uses la función de copia de seguridad de exportación en una instancia de Enterprise o Standard SQL Server, evita crear un archivo GZ porque intenta comprimir una copia de seguridad ya comprimida por SQL Server.

Protege la instancia y las copias de seguridad contra la eliminación accidental.

Una instancia de Cloud SQL que creas en la consola de Google Cloud o a través de Terraform habilita la prevención de eliminación accidental de forma predeterminada.

Usa la función de exportación en Cloud SQL para exportar tus datos y obtener una protección adicional. Usa Cloud Scheduler con la API de REST para automatizar la administración de exportaciones. En situaciones más avanzadas, Cloud Scheduler con Cloud Functions para la automatización

Configuración de SQL Server

Se recomienda usar algunas opciones de configuración de SQL Server para Cloud SQL. En los siguientes temas, se describen algunas recomendaciones.

Parámetros de configuración global

Parámetro de configuración Recomendación
max worker threads Conserva el valor predeterminado de 0. Esta configuración define la cantidad de subprocesos disponibles para SQL Server en función de la cantidad de CPU. El motor de SQL Server calcula el valor de forma automática en el inicio.
max server memory (MB)

Si no especificas un valor para esta configuración, con el tiempo, SQL Server consume tanta memoria como pueda hasta que alcance el 100%. Si el uso de memoria de una instancia de Cloud SQL para SQL Server es demasiado alto, es posible que tengas problemas de rendimiento. Para obtener más información sobre el uso de memoria para SQL Server, consulta Supervisa el uso de memoria.

Te recomendamos usar la siguiente fórmula para establecer la marca de base de datos
max server memory:

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

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

  • 1.4 GB de memoria para el SO y los agentes
  • 4 GB de memoria, porque 104 GB son mayores que 16 GB.
  • 11 GB de memoria, porque hay 88 GB de RAM que es mayor a 16 GB (104-16=88) y 88 dividido por 8 es 11

Para este ejemplo, debes reservar 16.4 GB de memoria. Como resultado, para el valor de esta marca, especifica 89702 MB
[(104-16.4) * 1,024 = 89702].

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

Nivel de la instancia (MB) Memoria máxima del servidor (MB) % (Total)
3840 1440 37
4,096 1632 39
5792 2912 50
8192 4704 57
11584 7248 62
16384 10848 66
23168 16800 72
32768 25200 76
46336 37072 80
65568 53888 82
92704 77648 83
131136 111248 84
185440 158784 85
262272 226000 86
370880 321056 86
524544 455488 86
741792 645600 87

Para supervisar el uso de memoria de tu instancia, usa las siguientes metrics:

  • 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 Supervisa instancias de Cloud SQL.

Configuración de la base de datos que se va a modificar

Para obtener un rendimiento óptimo de la base de datos de SQL Server, establece la siguiente configuración de SQL Server, como se sugiere a continuación.

Configuración Recomendación
cost threshold for parallelism

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

El valor se ignora cuando maxdop se establece en 1.

max degree of parallelism (MAXDOP)

Para reducir las esperas de la base de datos debido al paralelismo, ajusta este valor en función de las recomendaciones específicas sobre la cantidad de procesadores lógicos disponibles. Mide el rendimiento con cuidado si configuras esta opción como 1.

optimize for ad hoc workloads

Evita tener una gran cantidad de planes de uso único en la caché del plan. A fin de mejorar la eficiencia de la caché del plan para las cargas de trabajo que contienen muchos lotes ad hoc de uso único, establece esta opción en 1.

tempdb

Ajusta el tamaño de tempdb para que no necesite crecer de forma automática. Todos los archivos en tempdb deben tener el mismo tamaño y el mismo crecimiento de archivos establecido.

El tipo de espera de la base de datos para la contención tempdb aparece como PAGELATCH_UP. Para reducir la contención, agrega más archivos.

Si la cantidad de procesadores es menor o igual que 8, usa la misma cantidad de archivos que los procesadores lógicos. Si la cantidad de procesadores es mayor a 8, usa 8 archivos de datos. Si la contención continúa, aumenta la cantidad de archivos por múltiplos de 4 hasta que no haya más contención.

Según tu carga de trabajo, tal vez sea recomendable que también modifiques la siguiente configuración.

Configuración Recomendación
Close Cursor on Commit Enabled El valor predeterminado es off, lo que significa que los cursores no se cierran de forma automática cuando confirmas una transacción.
Default Cursor Esta opción controla el alcance de un cursor que se usa en el código de T-SQL. Si cambias esta configuración, evalúa el código de la aplicación en busca de efectos adversos.
Page Verify Esta opción permite que SQL Server calcule una suma de verificación para una página de base de datos antes de que se escriba en el disco y almacene la suma de verificación en el encabezado de la página. Cuando se vuelve a leer una página, la suma de verificación se vuelve a calcular para verificar la integridad de dicha página. El valor recomendado es checksum.
Parameterization El valor predeterminado es simple. La parametrización simple permite que SQL Server reemplace valores literales de una consulta por parámetros. Microsoft proporciona lineamientos sobre cómo cambiar este valor y usarlo con guías de planes.

Configuración de la base de datos que se conservará

Para obtener un rendimiento óptimo de la base de datos de SQL Server, conserva los valores predeterminados de la siguiente configuración de SQL Server.

Configuración Valor predeterminado que se conservará
Auto Close False. Este parámetro de configuración, cuando se activa, abre y cierra conexiones y limpia el procedimiento después de cada conexión. Esto puede degradar el rendimiento en bases de datos a las que se accede con frecuencia.
Auto Shrink False. Si la activas, puedes fragmentar la base de datos y el índice, y otros problemas de rendimiento, algunos de los cuales se analizan en este blog de SQL Server.
Date Correlation Optimization Enabled False. Habilitarla puede permitir que el optimizador encuentre y optimice relaciones entre fechas en dos tablas relacionadas. El seguimiento de esto en SQL Server conlleva una sobrecarga de rendimiento.
Legacy Cardinality Estimation False. En algunos casos, SQL Server no puede calcular con precisión las cardinalidades cuando esta configuración está habilitada.
Parameter Sniffing ON. La búsqueda de parámetros desde las tablas de bases de datos puede ayudar a crear planes de ejecución para la reutilización. Si las tablas tienen datos distribuidos de manera desigual, los planes de ejecución resultantes pueden generar problemas de rendimiento. Con estos datos, usa otras opciones del Almacén de consultas en lugar de modificar esta configuración.
Query Optimizer Fixes False. Cuando está habilitado, puede afectar el rendimiento del estimador de cardinalidad de SQL Server. Si eliges habilitarlo, realiza una prueba para asegurarte de que no haya regresión de consultas.
Auto Create Statistics True. Esta opción permite que SQL Server cree estadísticas de una sola columna que puedan mejorar las estimaciones de cardinalidad para los planes de consultas.
Auto Update Statistics True. Esta opción permite que SQL Server actualice las estadísticas desactualizadas mediante un umbral de recopilación basado en la cardinalidad de la tabla.
Auto Update Statistics Asynchronously False. Esta opción, cuando se habilita, indica al optimizador de consultas en SQL que use las estadísticas inactivas para la ejecución actual de la consulta, mientras actualiza las estadísticas de forma asíncrona a fin de beneficiar las futuras cargas de trabajo.

Sin embargo, si esperas un tiempo de respuesta predecible para una consulta ejecutada con frecuencia o si tu aplicación experimenta con frecuencia tiempos de espera de solicitudes del cliente mientras espera las actualizaciones de estadísticas, considera habilitar esta opción y, luego, inhabilitar Auto Update Statistics.

Target Recovery Time (Seconds) 60. Este parámetro de configuración establece un límite superior en el tiempo de recuperación de una base de datos, ya que limpia las páginas sucias con mayor o menor frecuencia en el disco del grupo de búferes. En el caso de las cargas de trabajo altamente transaccionales, un valor más bajo para este parámetro de configuración, combinado con las IOPS de almacenamiento cerca del valor máximo, puede contribuir a un cuello de botella en el rendimiento.

Configuración de la marca de seguimiento

Las marcas de seguimiento en SQL Server se usan para establecer ciertas características, modificar el comportamiento de las bases de datos de SQL Server o depurar problemas en SQL Server.

Algunas marcas de seguimiento de SQL Server son compatibles con Cloud SQL y se pueden configurar mediante marcas de base de datos. La configuración recomendada es la siguiente.

Marca de seguimiento Recomendado
1204 Yes, excepto para los servidores con uso intensivo de cargas de trabajo que generan muchos interbloqueos.

Muestra los recursos y los tipos de bloqueos que participan en un interbloqueo y también el comando que se ve afectado actualmente.
1222 Yes, excepto para los servidores con uso intensivo de cargas de trabajo que generan muchos interbloqueos.
1224 No. Esto puede generar más uso de memoria y causar presión en la base de datos.
2528 No. La verificación paralela de objetos es la opción predeterminada y se recomienda. El motor de base de datos calcula automáticamente el grado de paralelismo.
3205 No. Las unidades de cinta para copias de seguridad son una característica de Cloud SQL para SQL Server.
3226 No, a menos que necesites copias de seguridad frecuentes, como las de TLOG.
3625 No. Debido a que la cuenta raíz no tiene acceso de administrador del sistema, es posible que no pueda ver todos los mensajes de error.
4199 No. Esto afecta el estimador de cardinalidad y puede generar una regresión de consulta.
4616 No. Esta restricción reduce la seguridad en torno a los roles de la aplicación. Debe validarse según los requisitos de la aplicación.
7806 Yes. Si el servidor de la base de datos deja de responder, la conexión de administrador dedicada (DAC) puede ser la única forma de establecer una conexión para el diagnóstico.

¿Qué sigue?

Para obtener más información sobre las prácticas generales por motor de base de datos, consulta: