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 |
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.
|
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:
|
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 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:
Usa los siguientes fragmentos de código para ejecutar
|
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
Por ejemplo, si la RAM de tu instancia es de 104 GB
Para este ejemplo, debes reservar 16.4 GB de memoria. Como resultado, para el valor de esta marca, especifica En la siguiente tabla, se muestran los valores y porcentajes recomendados de RAM total para algunos niveles de máquinas virtuales (VM) populares:
Para supervisar el uso de memoria de tu instancia, usa las siguientes metrics:
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 El valor se ignora cuando |
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 |
tempdb |
Ajusta el tamaño de El tipo de espera de la base de datos para la contención 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 |
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:
- Prácticas recomendadas generales para MySQL
- Prácticas recomendadas generales para PostgreSQL
- Prácticas recomendadas generales para SQL Server