Práticas recomendadas gerais

Nesta página, você verá as práticas recomendadas para conseguir melhor desempenho, durabilidade e disponibilidade do Cloud SQL.

Se ocorrerem problemas na sua instância do Cloud SQL, verifique o seguinte durante a solução de problemas:

Configuração e administração de instâncias

Prática recomendada Mais informações
Leia e siga as diretrizes operacionais para garantir que as instâncias estejam cobertas pelo SLA do Cloud SQL.
Configure uma janela de manutenção para sua instância principal para controlar quando as atualizações disruptivas podem ser feitas. Consulte Janela de manutenção.
Se você exclui e recria instâncias regularmente, use um carimbo de data e hora no código da instância para aumentar a probabilidade de que novos códigos sejam utilizáveis.
Não inicie uma operação administrativa antes que a operação anterior seja concluída.

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.

Configure o armazenamento para acomodar a manutenção crítica do banco de dados.

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.
Evite o uso excessivo da CPU.

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.
Evite exaustão de memória.

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.
Definir as configurações do SQL Server para que elas funcionem corretamente no Cloud SQL. Consulte Configurações do SQL Server.
Ajuste a instância de maneira ideal para execuções de teste. A tabela a seguir lista os valores de configuração adequados para execuções de teste.
  • 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
Determine a capacidade do subsistema de E/S antes de implantar o SQL Server.

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.
Evite a fragmentação de índice e a ausência de índices. Reorganize seu índice ou configure uma programação para recriar seu índice, dependendo da frequência com que seus dados estão mudando. Além disso, defina um fator de preenchimento apropriado para reduzir a fragmentação. Monitore o SQL Server quanto a índices ausentes que possam oferecer melhor desempenho.
Atualize as estatísticas regularmente. Se as estatísticas estiverem desatualizadas, o otimizador de consultas SQL poderá gerar planos de consulta abaixo do ideal. Atualize as estatísticas, especialmente após grandes quantidades de dados terem sido alteradas. Use o armazenamento de consultas para monitorar e resolver problemas em um SQL Server com planos de consulta abaixo do ideal.
Evite o crescimento desnecessário do banco de dados.

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.

Execute DBCC CHECKDB pelo menos uma vez por semana para detectar problemas de integridade do banco de dados. DBCC CHECKDB verifica a integridade de todos os objetos em um banco de dados. Ao executar DBCC CHECKDB semanalmente, você garante que seus bancos de dados não estão corrompidos. DBCC CHECKDB é uma operação que consome muitos recursos e pode afetar o desempenho da instância.
Não execute DBCC CHECKDB em um servidor de produção.
Recomendamos que você use uma das seguintes opções em vez de executar DBCC CHECKDB em um servidor de produçã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

Arquitetura de dados

Prática recomendada Mais informações
Divida suas instâncias grandes em instâncias menores, quando possível. Usar várias instâncias pequenas do Cloud SQL é melhor do que uma única instância grande. Gerenciar uma instância grande e monolítica apresenta desafios que não existem quando se usa um grupo de instâncias menores.
Não use muitas tabelas de banco de dados.

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.

Ordenação do banco de dados Ao instalar uma nova instância do SQL Server, restaurar um backup de banco de dados ou conectar um servidor a bancos de dados de clientes, é importante entender os requisitos de localidade, a ordem de classificação e a diferenciação de maiúsculas e minúsculas dos dados com que você está trabalhando. Ao selecionar uma ordenação para seu servidor, banco de dados, coluna ou expressão, você atribui algumas características aos dados. Essas características afetam os resultados de muitas operações no banco de dados. Por exemplo, ao criar uma consulta usando ORDER BY, a ordem de classificação do conjunto de resultados pode depender da ordenação que é aplicada ao banco de dados ou ditada em um cláusula COLLATE no nível da expressão da consulta. Saiba mais sobre ordenações de banco de dados e suporte a unicode.
Design de consulta Para melhorar o desempenho do banco de dados ou da consulta, verifique se você não está usando um grande número de tabelas na mesma consulta (16 ou mais).
Monitoramento de consultas O desempenho das consultas pode cair com o tempo. É importante monitorar periodicamente o desempenho do aplicativo e da consulta. Um motivo para essa queda de desempenho é a ocorrência de hash bailout.
Mesclagens de hash recursivas ou bailouts reduzem o desempenho em um servidor. Se forem observados muitos eventos de aviso de hash em um trace, atualize as estatísticas nas colunas que estão sendo mescladas. Mais informações sobre hash bailouts.

Implementação do aplicativo

Prática recomendada Mais informações
Use boas práticas de gerenciamento de conexão, como o pooling de conexões e a retirada exponencial. Com essas técnicas, seu aplicativo aproveita melhor os recursos e torna mais fácil permanecer dentro dos limites de conexão do Cloud SQL. Para mais informações e amostras de código, consulte Como gerenciar conexões de banco de dados.
Teste a resposta do aplicativo às atualizações de manutenção, que podem acontecer a qualquer momento durante a janela de manutenção. Teste a manutenção de autoatendimento para simular uma atualização de manutenção. Durante a manutenção, sua instância ficará indisponível por um breve período, e as conexões atuais serão descartadas. Testar os lançamentos de manutenção permite uma melhor compreensão de como seu aplicativo lida com a manutenção programada e com que rapidez o sistema pode se recuperar.
Teste a resposta da sua aplicação a failovers, que podem acontecer a qualquer momento. É possível iniciar manualmente um failover usando o console do Google Cloud, a CLI gcloud ou a API. Consulte Como iniciar um failover.
Evite transações grandes. Faça transações pequenas e curtas. Se for necessária uma grande atualização de banco de dados, faça isso em várias transações menores, em vez de em uma transação grande.
Se você estiver usando o proxy do Cloud SQL Auth, verifique se sua versão é a mais recente. Consulte Como manter o Cloud SQL Auth atualizado.

Importação e exportação de dados

Prática recomendada Mais informações
Acelere as importações para instâncias pequenas. Em instâncias pequenas, aumente a CPU e a RAM temporariamente para melhorar o desempenho ao importar conjuntos de dados grandes.
Se você estiver exportando dados para importação no Cloud SQL, certifique-se de usar o procedimento adequado. Consulte Como exportar dados de um servidor de banco de dados gerenciado externamente.

Backup e recuperação

Prática recomendada Mais informações
Proteja seus dados com a funcionalidade apropriada do Cloud SQL.

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.

Proteger sua instância e seus backups contra exclusão acidental.

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.

Configurações do SQL Server

Algumas configurações do SQL Server são recomendadas para o Cloud SQL. Os tópicos a seguir descrevem algumas recomendações.

Configurações de configuração global

Configuração Recomendação
max worker threads Mantenha o valor padrão de 0. Essa configuração define o número de linhas de execução disponíveis para o SQL Server com base no número de CPUs. O valor é calculado automaticamente pelo mecanismo do SQL Server na inicialização.
max server memory (MB)

Essa flag limita a quantidade de memória que o Cloud SQL pode alocar para os pools internos.

Se você não definir um valor para essa flag, o Cloud SQL vai gerenciar o valor automaticamente com base no tamanho da RAM da sua instância. Além disso, se você redimensionar a instância, o Cloud SQL vai ajustar o valor da flag automaticamente para atender às nossas recomendações sobre o novo tamanho da instância.

Recomendamos que você não especifique um valor para essa flag nas suas instâncias. Se você definir o valor como maior que 80%, poderá haver instabilidade, degradação de desempenho e falhas no banco de dados devido a problemas de falta de memória.

Se você preferir gerenciar o valor dessa flag, defina-a manualmente. Como resultado, o Cloud SQL desativa o gerenciamento automático. Se você estiver redimensionando a instância, considere revisar o valor para corresponder aos valores recomendados para um novo tamanho.

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:

Nível da instância (MB) Memória máxima do servidor (MB) % (Total)
3840 1440 37
4096 1632 39
5792 2912 50
8192 4704 57
11584 7248 62
16384 10848 66
23168 16800 72
32.768 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 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.

Configurações do banco de dados a serem modificadas

Para ter o melhor desempenho possível com o banco de dados do SQL Server, defina as seguintes configurações do SQL Server conforme sugerido abaixo.

Configuração Recomendação
cost threshold for parallelism

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.
max degree of parallelism (MAXDOP)

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.

optimize for ad hoc workloads

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.

tempdb

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.

Dependendo da carga de trabalho, talvez você queira modificar as seguintes configurações também.

Configuração Recomendação
Close Cursor on Commit Enabled O valor padrão é off, o que significa que os cursores não são fechados automaticamente quando você confirma uma transação.
Default Cursor Essa opção controla o escopo de um cursor usado no código T-SQL. Se você alterar essa configuração, avalie se há efeitos adversos no código do aplicativo.
Page Verify Essa opção permite que o SQL Server calcule uma soma de verificação para uma página do banco de dados antes que ela seja gravada no disco e armazene a soma de verificação no cabeçalho da página. Quando uma página é lida novamente, a soma de verificação é recalculada para verificar a integridade da página. O valor recomendado é checksum.
Parameterization O valor padrão é simple. A parametrização simples permite que o SQL Server substitua valores literais em uma consulta por parâmetros. A Microsoft fornece diretrizes sobre como alterar esse valor e usá-lo com guias de plano.

Configurações do banco de dados que devem ser mantidas

Para otimizar o desempenho do banco de dados SQL Server, mantenha os valores padrão das configurações do SQL Server a seguir.

Configuração Valor padrão que deve ser mantido
Auto Close False. Essa configuração, quando ativada, abre e fecha conexões e transfere o procedimento após cada conexão. Isso pode causar uma queda no desempenho dos bancos de dados acessados com frequência.
Auto Shrink False. A ativação pode levar à fragmentação do banco de dados e do índice, além de outros problemas de desempenho. Alguns deles são discutidos neste blog do SQL Server.
Date Correlation Optimization Enabled False. A ativação dela pode permitir que o otimizador encontre e otimize relações entre datas em duas tabelas relacionadas. O rastreamento dessa ação no SQL Server gera uma sobrecarga no desempenho.
Legacy Cardinality Estimation False. Em alguns casos, o SQL Server não consegue calcular as cardinalidades com precisão quando essa configuração está ativada.
Parameter Sniffing ON. A detecção de parâmetros em tabelas de banco de dados pode ajudar a criar planos de execução para reutilização. Se as tabelas tiverem dados distribuídos de maneira desigual, os planos de execução resultantes poderão levar a problemas de desempenho. Com essas informações, use outras opções do Armazenamento de consultas em vez de modificar essa configuração.
Query Optimizer Fixes False. Quando ativada, ela pode afetar o desempenho do estimador de cardinalidade do SQL Server. Se você optar por ativá-la, faça um teste para garantir que não haja regressão de consulta.
Auto Create Statistics True. Essa opção permite que o SQL Server crie estatísticas de coluna única que podem melhorar as estimativas de cardinalidade em planos de consulta.
Auto Update Statistics True. Essa opção permite que o SQL Server atualize as estatísticas desatualizadas usando um limite de recompilação baseado na cardinalidade da tabela.
Auto Update Statistics Asynchronously False. Essa opção, quando ativada, direciona o otimizador de consultas SQL para usar as estatísticas desatualizadas da execução atual da consulta, enquanto atualiza as estatísticas de forma assíncrona para beneficiar cargas de trabalho futuras.

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.

Target Recovery Time (Seconds) 60. Essa configuração estabelece um limite superior no tempo de recuperação de um banco de dados transferindo as páginas sujas, com mais ou menos frequência, para o disco do pool de buffer. Em cargas de trabalho altamente transacionais, um valor menor dessa configuração, combinado com as IOPS de armazenamento próximas ao valor máximo, pode contribuir para um gargalo de desempenho.

Configurações de sinalização de trace

As sinalizações de trace no SQL Server são usadas para definir determinadas características, alterar o comportamento dos bancos de dados do SQL Server ou depurar problemas no SQL Server.

Algumas sinalizações de trace do SQL Server são compatíveis com o Cloud SQL e podem ser definidas usando sinalizações de banco de dados. As configurações recomendadas são as seguintes.

Sinalização de trace Recomendado
1204 Yes, exceto para servidores com uso intensivo de carga de trabalho que geram muitos impasses.

Retorna os recursos e os tipos de bloqueios que participam de um impasse e o comando afetado no momento.
1222 Yes, exceto para servidores com uso intensivo de carga de trabalho que geram muitos impasses.
1224 No. Isso pode resultar em mais uso de memória e causar pressão sobre a memória no banco de dados.
2528 No A verificação paralela de objetos é padrão e recomendada. O grau de paralelismo é calculado automaticamente pelo mecanismo do banco de dados.
3205 No. As unidades de fita para backups são um recurso do Cloud SQL para o SQL Server.
3226 No, a menos que você precise de backups frequentes, como backups de TLOG.
3625 No. Como a conta raiz não tem acesso de administrador do sistema, talvez não seja possível ver todas as mensagens de erro.
4199 No. Isso afeta o estimador de cardinalidade e pode levar à regressão de consulta.
4616 No. Essa restrição diminui o nível de segurança dos papéis do aplicativo. Precisa de validação com base nos requisitos do aplicativo.
7806 Yes. Se o servidor de banco de dados deixar de responder, a conexão de administrador dedicada (DAC, na sigla em inglês) poderá ser a única maneira de fazer uma conexão para diagnóstico.