Recomendaciones 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 puedes volver a utilizar el ID de una instancia borrada durante algunos días después de que esta haya sido borrada.
No inicies una operación administrativa antes de que haya finalizado la operación anterior.

Las instancias de Cloud SQL no aceptan una solicitud de operación nueva 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 Cloud Console 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.

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. Reorganiza tu índice o establece un programa para volver a compilar tu índice según la frecuencia con la que cambien tus datos.
Actualiza las estadísticas con regularidad. Si las estadísticas están desactualizadas, el optimizador de consultas de SQL podría generar planes de consulta deficientes. Actualiza las estadísticas especialmente después de que se hayan cambiado grandes cantidades de datos.
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.

Arquitectura de datos

Práctica recomendada Más información
Fragmenta tus instancias cuando sea 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 una mayor cantidad de instancias más pequeñas.
No uses demasiadas tablas de base de datos.

Demasiadas tablas de base de datos pueden afectar el tiempo de respuesta de la instancia.

Implementación de aplicaciones

Práctica recomendada Más información
Implementa prácticas adecuadas de administración de la conexión, como agrupación de conexiones y retirada exponencial. El uso de estas técnicas mejora el uso de los recursos 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. Cambiar el tipo de máquina de una instancia es la aproximación más cercana a una actualización de mantenimiento. Asegúrate de que la aplicación intente volver a conectarse a la base de datos, preferentemente con una retirada exponencial durante al menos 10 minutos para garantizar que la aplicación reanude su funcionamiento luego de un evento de mantenimiento. Para obtener más información, consulta la sección sobre cómo administrar conexiones de bases de datos.
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 Cloud Console, 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 autenticación de Cloud SQL, asegúrate de usar la versión más reciente. Consulta Mantén el proxy de autenticación de Cloud SQL 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.

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.

Configuración global

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.

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 relacionadas con la cantidad de procesadores lógicos disponibles.

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 tener el mismo conjunto de crecimiento de archivos.

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 de 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.
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 la 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.