Práticas recomendadas gerais

As instâncias do Cloud SQL não aceitam novas solicitações de operação até que tenham concluído a operação anterior. Se você tentar iniciar uma nova operação antes do tempo, a solicitação falhará. Isso inclui reinicializações de instâncias.

O status da instância no console do Google Cloud não mostra se uma operação está em execução. A marca de verificação verde indica apenas que a instância está no estado RUNNABLE. Para ver se há alguma operação em execução, acesse a guia Operações e verifique o status da operação mais recente.

Se a configuração de instância ativar aumento automático de armazenamento estiver desativada ou o limite de aumento automático de armazenamento estiver ativado, verifique se pelo menos 20% do espaço está disponível para acomodar qualquer operação crítica de manutenção de banco de dados que o Cloud SQL possa realizar.

Para receber alertas quando o espaço em disco disponível estiver abaixo de 20%, crie uma política de alertas com base em métricas para a métrica de utilização de disco com uma posição acima do limite e um valor de 0,8. Para mais informações, consulte Criar políticas de alertas baseadas em métricas.

Veja a porcentagem de CPU disponível que sua instância está usando na página de detalhes da instância no console do Google Cloud. Para mais informações, consulte Métricas. Também é possível monitorar o uso da CPU e receber alertas em um limite especificado usando Criar políticas de alertas de limite de métrica.

Para evitar o uso excessivo, aumente o número de CPUs da instância. É necessário reiniciar a instância para alterar as CPUs. Se a instância já tiver o número máximo de CPUs, será necessário dividir o banco de dados em várias instâncias.

Ao procurar sinais de esgotamento da memória, use principalmente a métrica . Para evitar erros de memória insuficiente, recomendamos que essa métrica permaneça abaixo de 90%.

Também é possível usar a métrica total_usage para observar a porcentagem da memória disponível que sua instância do Cloud SQL está usando, incluindo a memória usada pelo contêiner do banco de dados e a memória alocada pelo cache do sistema operacional.

Ao observar a diferença entre as duas métricas, é possível identificar a quantidade de memória que é utilizada pelos processos em comparação com a quantidade de cache usada pelo sistema operacional. É possível reaproveitar a memória nesse cache.

Para prever problemas de falta de memória, verifique as duas métricas e interprete-as juntas. Se as métricas parecerem altas, a instância pode estar com pouca memória. Isso pode ocorrer por causa de uma configuração personalizada, da instância com tamanho menor que a carga de trabalho ou de uma combinação desses fatores.

Dimensione a instância do Cloud SQL para aumentar o tamanho da memória. É necessário reiniciar a instância para alterar o tamanho dela. Se a instância já estiver no tamanho máximo de memória, será necessário fragmentar seu banco de dados em várias instâncias. Para saber como monitorar as duas métricas no console do Google Cloud, consulte Métricas.

• vCPU: 40
• Memória: 262144 MB
• MAXDOP: 8
• Limite de custo para carregamento em paralelo: 120
• arquivos tempdb: 8. Pré-dimensionado para evitar o crescimento automático.
• Arquivos do banco de dados do usuário: crescimento automático definido em 64-128 MB. Pré-dimensionado para evitar o crescimento automático.
• Armazenamento: >= 4TB para as melhores IOPS

Teste vários tipos e tamanhos de E/S. O tamanho da E/S emitido para o armazenamento em disco permanente proveniente do SQL Server afeta as IOPS e a capacidade. A carga de trabalho do SQL Server é limitada quando atinge o limite de IOPS ou de capacidade. O tipo de armazenamento usado no Cloud SQL é o PD SSD, que é adequado para cargas de trabalho de alto desempenho em nível empresarial.

Personalize a VM para maximizar o desempenho da seguinte maneira:

• Um tamanho de disco de 4 TB ou mais fornece mais capacidade e IOPS.
• Uma vCPU maior fornece mais IOPS e capacidade. Ao usar uma vCPU mais alta, monitore o banco de dados aguardando o paralelismo, que também pode aumentar.
• Para um desempenho ideal, emita E/S em paralelo, para alcançar uma maior profundidade da fila de E/S.

Defina autogrow em MB em vez de como porcentagem, usando incrementos adequados ao requisito. Além disso, gerencie proativamente o crescimento antes que o crescimento automático seja iniciado.

Além disso, verifique se o recurso Ativar crescimento automático de armazenamento do Cloud SQL está ativado, para que o Cloud SQL possa adicionar espaço de armazenamento se o banco de dados e a instância ficarem sem espaço.

• Clone um banco de dados e execute DBCC CHECKDB nesse clone.
• Restaure um backup para outra instância e execute DBCC CHECKDB nos bancos de dados da instância restaurada. Para mais informações sobre como restaurar uma instância, consulte Restaurar uma instância.

Use os seguintes snippets de código para executar DBCC CHECKDB em um banco de dados:

• (Recomendado) Execute DBCC CHECKDB com EXTENDED_LOGICAL_CHECKS. Essa é uma verificação abrangente, mas consome muitos recursos.

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

• Execute DBCC CHECKDB com PHYSICAL_ONLY:

        USE DATABASE_NAME
        DBCC CHECKDB WITH PHYSICAL_ONLY,
        NO_INFOMSGS, ALL_ERRORMSGS
        

Mantenha a contagem da tabela de instâncias abaixo de 10.000. Um número muito grande de tabelas de banco de dados pode afetar o tempo de upgrade.

Backups e exportações são maneiras de fornecer redundância e proteção de dados. Cada uma protege contra diferentes cenários e complementam-se em uma estratégia robusta de proteção de dados.

Os backups são leves e fornecem uma forma de restaurar os dados na instância para o estado em que você fez o backup. No entanto, os backups têm algumas limitações. Se você excluir a instância, os backups também serão excluídos. Não é possível fazer backup de um único banco de dados ou tabela. E se a região em que a instância está localizada estiver indisponível, não será possível usar o backup para restaurá-la, nem mesmo em uma região disponível.

As exportações levam mais tempo para serem estruturadas. Isso ocorre porque um arquivo externo que pode ser usado para refazer seus dados é criado no Cloud Storage. Elas não serão afetadas se você excluir a instância. Além disso, é possível exportar apenas um único banco de dados ou até mesmo uma tabela, dependendo do formato de exportação escolhido.

Ao usar o recurso de backup de exportação em uma instância Enterprise ou Standard SQL Server, evite criar um arquivo GZ, porque ele tenta compactar um backup que já está nativamente compactado pelo SQL Server.

Uma instância do Cloud SQL criada no console do Google Cloud ou pelo Terraform permite a prevenção contra exclusão acidental por padrão.

Use o recurso de exportação no Cloud SQL para exportar seus dados e aumentar a proteção. Use o Cloud Scheduler com a API REST para automatizar o gerenciamento de exportações. Para cenários mais avançados, use o Cloud Scheduler com o Cloud Run functions para automação.

Se você não especificar um valor para essa configuração, o SQL Server vai consumir o máximo de memória possível até atingir 100%. Se o uso da memória de uma instância do Cloud SQL para SQL Server ficar muito alto, você poderá ter problemas de desempenho. Para mais informações sobre o uso de memória do SQL Server, consulte Monitorar o uso da memória.

Recomendamos usar a seguinte fórmula para definir a flag do banco de dados
max server memory:

• Reserve 1,4 GB de memória para o SO e os agentes.
• Se a RAM no servidor for menor ou igual a 16 GB, reserve 1 GB de memória para cada 4 GB de RAM.
• Se a RAM no servidor for maior que 16 GB, deixe 4 GB de memória e reserve 1 GB de memória para cada 8 GB de RAM que for maior que 16 GB.

Por exemplo, se a RAM da sua instância for de 104 GB
(106496 MB), reserve:

• 1,4 GB de memória para o SO e os agentes
• 4 GB de memória, porque 104 GB é maior que 16 GB
• 11 GB de memória, porque há 88 GB de RAM que são maiores que 16 GB (104-16=88) e 88 dividido por 8 é 11.

Para este exemplo, é necessário reservar 16,4 GB de memória. Como resultado, para o valor dessa flag, especifique 89702 MB
[(104-16,4) * 1024 = 89702].

A tabela a seguir mostra valores e porcentagens recomendadas de RAM total para alguns níveis de máquina virtual (VM) conhecidos:

Para monitorar o uso da memória da sua instância, use as seguintes métricas:

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

Saiba mais em Monitorar instâncias do Cloud SQL.

Esse é o limite em que o otimizador SQL executa uma consulta com o uso de paralelismo. O valor padrão de 5 pode fazer com que consultas demais sejam executadas em paralelo, aumentando o tempo de espera do banco de dados em linhas de execução paralelas. Para reduzir esse tipo de contenção, aumente o valor.

O valor é ignorado quando maxdop é definido como 1.

Para reduzir as esperas do banco de dados devido ao paralelismo, ajuste esse valor com base em recomendações específicas relacionadas ao número de processadores lógicos disponíveis. Avalie o desempenho com cuidado se essa opção for definida como 1.

Evite um número muito grande de planos de uso único no cache do plano. Para melhorar a eficiência do cache do plano para cargas de trabalho que contêm muitos lotes ad hoc, defina essa opção como 1.

Pré-dimensione tempdb para que o crescimento automático não seja necessário. Todos os arquivos em tempdb devem ter o mesmo tamanho e o mesmo nível de crescimento de arquivos definido.

O tipo de espera do banco de dados para a contenção tempdb aparece como PAGELATCH_UP. Para reduzir a contenção, adicione mais arquivos.

Se o número de processadores for menor ou igual a 8, use o mesmo número de arquivos que os processadores lógicos. Se o número de processadores for maior que oito, use oito arquivos de dados. Se a contenção continuar, aumente o número de arquivos em múltiplos de quatro até que não haja mais contenção.

No entanto, se você espera um tempo de resposta previsível para uma consulta executada com frequência ou se o aplicativo apresenta frequentemente tempos limite de solicitação do cliente enquanto aguarda atualizações de estatísticas, considere ativar e desativar essa opção Auto Update Statistics.