Práticas recomendadas gerais

Esta página fornece práticas recomendadas para obter o melhor desempenho, durabilidade e disponibilidade do Cloud SQL.

Se ocorrerem problemas com a sua instância do Cloud SQL, reveja o seguinte durante a resoluçã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 suas instâncias estão abrangidas pelo ANS do Cloud SQL.
Configure um período de manutenção para a sua instância principal para controlar quando podem ocorrer atualizações disruptivas. Consulte o artigo Período de manutenção.
Se eliminar e recriar instâncias regularmente, use uma data/hora no ID da instância para aumentar a probabilidade de os novos IDs de instância serem utilizáveis.
Não inicie uma operação administrativa antes de a operação anterior estar concluída.

As instâncias do Cloud SQL não aceitam novos pedidos de operação até concluírem a operação anterior. Se tentar iniciar uma nova operação prematuramente, o pedido de operação falha. Isto inclui reinícios de instâncias.

O estado da instância na Google Cloud consola não reflete 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 uma operação está em execução, aceda ao separador Operações e verifique o estado da operação mais recente.

Configure o armazenamento para acomodar a manutenção crítica da base de dados.

Se a definição da instância ativar aumentos automáticos de armazenamento estiver desativada ou o limite de aumento automático de armazenamento estiver ativado, certifique-se de que tem, pelo menos, 20% de espaço disponível para acomodar quaisquer operações de manutenção críticas da base de dados que o Cloud SQL possa realizar.

Para receber alertas quando o espaço em disco disponível for inferior a 20%, crie uma política de alertas baseada em métricas para a métrica de utilização do disco com uma posição acima do limite e um valor de 0,8. Para mais informações, consulte o artigo Crie políticas de alerta baseadas em métricas.
Evite a utilização excessiva da CPU.

Pode ver a percentagem de CPU disponível que a sua instância está a usar na página de detalhes da instância na Google Cloud consola. Para mais informações, consulte Métricas. Também pode monitorizar a utilização da CPU e receber alertas a um limite especificado através da criação de políticas de alerta de limite de métricas.

Para evitar a utilização excessiva, pode aumentar o número de CPUs da sua instância. A alteração dos CPUs requer o reinício de uma instância. Se a sua instância já tiver o número máximo de CPUs, tem de dividir a base de dados em várias instâncias.
Evite o esgotamento da memória.

Quando procurar sinais de esgotamento da memória, deve usar principalmente a métrica de utilização. Para evitar erros de falta de memória, recomendamos que esta métrica permaneça abaixo dos 90%.

Também pode usar a métrica total_usage para observar a percentagem de memória disponível que a sua instância do Cloud SQL está a usar, incluindo a memória usada pelo contentor da base de dados e a memória alocada pela cache do sistema operativo.

Ao observar a diferença entre as duas métricas, pode identificar a quantidade de memória usada pelos processos em comparação com a quantidade usada pela cache do sistema operativo. Pode reutilizar a memória nesta cache.

Para prever problemas de falta de memória, verifique ambas as métricas e interprete-as em conjunto. Se as métricas forem elevadas, a instância pode ter pouca memória. Isto pode dever-se a uma configuração personalizada, ao facto de a instância ser demasiado pequena para a carga de trabalho ou a uma combinação destes fatores.

Dimensione a sua instância do Cloud SQL para aumentar o tamanho da respetiva memória. A alteração do tamanho da memória da instância requer o reinício da instância. Se a sua instância já tiver o tamanho máximo de memória, tem de fragmentar a base de dados em várias instâncias. Para saber mais sobre a monitorização de ambas as métricas na Google Cloud consola, consulte o artigo Métricas.
Defina as definições do SQL Server para que funcionem de forma ideal para o Cloud SQL. Consulte as definições do SQL Server.
Ajuste a instância de forma ideal para execuções de teste. A tabela seguinte lista os valores de configuração adequados para execuções de teste.
  • vCPU: 40
  • Memória: 262144 MB
  • MAXDOP: 8
  • Limite de custo para paralelismo: 120
  • Ficheiros tempdb: 8. Tamanho predefinido para evitar o crescimento automático.
  • Ficheiros da base de dados de utilizadores: crescimento automático definido em 64-128 MB. Com tamanho predefinido para evitar o crescimento automático.
  • Armazenamento: >= 4TB para os melhores IOPS
Determine a capacidade do subsistema de E/S antes de implementar o SQL Server.

Teste vários tipos e tamanhos de E/S. O tamanho da E/S emitida para o armazenamento em disco persistente proveniente do SQL Server afeta os IOPS e o débito. A carga de trabalho do SQL Server é limitada quando atinge o limite de IOPS ou o limite de débito. O tipo de armazenamento usado no Cloud SQL é um SSD de disco persistente, que é adequado para cargas de trabalho de nível empresarial de elevado desempenho.

Personalize a VM para maximizar o desempenho da seguinte forma:

  • Um tamanho do disco de 4 TB ou superior oferece mais débito e IOPS.
  • Uma vCPU mais elevada oferece mais IOPS e débito. Quando usar um número mais elevado de vCPUs, monitorize os tempos de espera da base de dados para paralelismo, que também podem aumentar.
  • Para um desempenho ideal, emita E/S em paralelo para alcançar uma profundidade da fila de E/S mais elevada.
Evite a fragmentação de índices e a falta de índices. Reorganize o índice ou configure uma programação para recriar o índice consoante a frequência com que os dados são alterados. Além disso, defina um fator de preenchimento adequado para reduzir a fragmentação. Monitorize o SQL Server para índices em falta que podem oferecer um desempenho melhorado.
Atualize as estatísticas regularmente. Se as estatísticas estiverem desatualizadas, o otimizador de consultas SQL pode gerar planos de consultas abaixo do ideal. Atualize as estatísticas, especialmente após a alteração de grandes quantidades de dados. Use o repositório de consultas para monitorizar e resolver problemas do SQL Server que tem planos de consultas abaixo do ideal.
Impedir que os ficheiros da base de dados se tornem desnecessariamente grandes.

Defina autogrow em MBs em vez de como uma percentagem, usando incrementos adequados ao requisito. Além disso, faça a gestão proativa do crescimento antes de o crescimento automático entrar em vigor.

Além disso, certifique-se de que a funcionalidade Ativar aumentos automáticos de armazenamento do Cloud SQL está ativada para que o Cloud SQL possa adicionar espaço de armazenamento se a base de dados e a instância ficarem sem espaço.

Detete problemas de integridade da base de dados executando DBCC CHECKDB pelo menos uma vez por semana. DBCC CHECKDB verifica a integridade de todos os objetos numa base de dados. Ao executar o comando DBCC CHECKDB semanalmente, pode garantir que as suas bases de dados não estão danificadas. DBCC CHECKDB é uma operação que requer muitos recursos e que pode afetar o desempenho da sua instância.
Não execute o DBCC CHECKDB num servidor de produção.
Em alternativa, recomendamos que use uma das seguintes opções em vez de executar o comando DBCC CHECKDB num servidor de produção:
  • Clonar uma base de dados e executar DBCC CHECKDB na base de dados clonada.
  • Restaure uma cópia de segurança para outra instância e, em seguida, execute DBCC CHECKDB nas bases de dados da instância restaurada. Para mais informações sobre como restaurar uma instância, consulte o artigo Restaure uma instância.

Use os seguintes fragmentos do código para executar DBCC CHECKDB numa base de dados:

  • (Recomendado) Execute o comando DBCC CHECKDB com EXTENDED_LOGICAL_CHECKS. Esta é uma verificação abrangente, mas que requer mais recursos. 
          USE DATABASE_NAME
      DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS,
      DATA_PURITY,NO_INFOMSGS, ALL_ERRORMSGS
  • Corrida DBCC CHECKDB com PHYSICAL_ONLY: 
          USE DATABASE_NAME
      DBCC CHECKDB WITH PHYSICAL_ONLY,
      NO_INFOMSGS, ALL_ERRORMSGS

Otimize o desempenho

Para manter os seus dados seguros e as suas aplicações a funcionar sem problemas com as tabelas OLTP na memória, considere aplicar as seguintes práticas recomendadas:

Prática recomendada Mais informações
Aderir às práticas recomendadas da Microsoft para tabelas otimizadas para memória
  • Cópias de segurança regulares: certifique-se de que agendou cópias de segurança regulares para as suas bases de dados. No caso de danos nos dados, isto permite-lhe restaurar os dados para o último estado seguro conhecido.
  • Validação da cópia de segurança: uma vez que as opções de reparação DBCC não estão disponíveis para tabelas otimizadas para memória, é recomendável testar a cópia de segurança executando restauros periódicos. Se ocorrerem problemas de integridade dos dados numa tabela otimizada para memória, tem de restaurar a partir da última cópia de segurança segura conhecida.

Para mais informações sobre as limitações, consulte as funcionalidades do SQL Server não suportadas para OLTP na memória.

Segurança

Prática recomendada Mais informações
Preferir IP privado A menos que seja necessário o acesso ao IP público, é preferível usar o IP privado. Isto ajuda a minimizar as ligações de rede não autorizadas à sua base de dados.
Evite 0.0.0.0/0 nas redes autorizadas Evite incluir 0.0.0.0/0 em Redes autorizadas , uma vez que isto permite o acesso a partir da Internet global sem restrições.
Evite redes autorizadas excessivamente grandes Evite usar prefixos CIDR pequenos em Redes autorizadas , uma vez que isto permite o acesso a partir de um número potencialmente excessivo de anfitriões. Recomendamos um prefixo CIDR não inferior a /16 e, de preferência, superior a /19.

Arquitetura de dados

Prática recomendada Mais informações
Divida as instâncias grandes em instâncias mais pequenas, sempre que possível. Quando possível, usar muitas instâncias do Cloud SQL mais pequenas é melhor do que uma instância grande. A gestão de uma instância grande e monolítica apresenta desafios que não são colocados por um grupo de instâncias mais pequenas.
Não use demasiadas tabelas de base de dados.

Mantenha o número de tabelas da instância inferior a 10 000. Um número excessivo de tabelas de base de dados pode afetar o tempo de atualização da base de dados.

Colação da base de dados Quer esteja a instalar uma nova instância do SQL Server, a restaurar uma cópia de segurança da base de dados ou a associar um servidor a bases de dados de clientes, é importante compreender os requisitos de localidade, a ordem de ordenação e a sensibilidade a maiúsculas e minúsculas e a acentos dos dados com os quais está a trabalhar. Quando seleciona uma ordenação para o servidor, a base de dados, a coluna ou a expressão, está a atribuir determinadas caraterísticas aos seus dados. Estas caraterísticas afetam os resultados de muitas operações na base de dados. Por exemplo, quando cria uma consulta usando ORDER BY, a ordem de classificação do conjunto de resultados pode depender da ordenação que é aplicada à base de dados ou ditada numa cláusula COLLATE ao nível da expressão da consulta. Leia mais acerca das intercalações de bases de dados e do suporte Unicode.
Design de consultas Para um desempenho ideal da base de dados ou da consulta, certifique-se de que não está a usar um grande número de tabelas na mesma consulta (dezasseis ou mais).
Monitorização de consultas As consultas podem degradar-se ao longo do tempo. É importante monitorizar o desempenho da aplicação e das consultas ao longo do tempo. Um dos motivos para esta degradação são as desistências de hash.
As junções de hash recursivas ou as saídas de hash causam uma redução no desempenho num servidor. Se vir muitos eventos de aviso de hash numa rastreabilidade, atualize as estatísticas das colunas que estão a ser unidas. Leia mais sobre hash bailouts.

Implementação de aplicações

Prática recomendada Mais informações
Use boas práticas de gestão de ligações, como a pool de ligações e a retirada exponencial. A utilização destas técnicas melhora a utilização de recursos da sua aplicação e ajuda a manter-se dentro dos limites de ligação do Cloud SQL. Para mais informações e exemplos de código, consulte o artigo Gerir ligações à base de dados.
Teste a resposta da sua aplicação a atualizações de manutenção, que podem ocorrer em qualquer altura durante o período de manutenção. Experimente a manutenção self-service para simular uma atualização de manutenção. Durante a manutenção, a sua instância fica indisponível durante um breve período e as ligações existentes são interrompidas. Os implementos de manutenção de testes dão-lhe uma melhor compreensão de como a sua aplicação processa a manutenção agendada e a rapidez com que o sistema consegue recuperar.
Teste a resposta da sua aplicação a comutações por falha, que podem ocorrer em qualquer altura. Pode iniciar manualmente uma comutação por falha através da Google Cloud consola, da CLI gcloud ou da API. Consulte a secção Iniciar comutação por falha.
Evite transações grandes. Mantenha as transações pequenas e curtas. Se for necessária uma atualização de base de dados grande, faça-a em várias transações mais pequenas em vez de numa transação grande.
Se estiver a usar o proxy Auth do Cloud SQL, certifique-se de que está a usar a versão mais atualizada. Consulte o artigo Manter o proxy Auth do Cloud SQL atualizado.

Importação e exportação de dados

Prática recomendada Mais informações
Acelere as importações para tamanhos de instâncias pequenos. Para instâncias pequenas, pode aumentar temporariamente a CPU e a RAM de uma instância para melhorar o desempenho quando importa grandes conjuntos de dados.
Se estiver a exportar dados para importação no Cloud SQL, certifique-se de que usa o procedimento adequado. Consulte o artigo Exportar dados de um servidor de base de dados gerido externamente.

Cópia de segurança e recuperação

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

As cópias de segurança e as exportações são formas de fornecer redundância e proteção de dados. Cada uma protege contra cenários diferentes e complementa-se numa estratégia de proteção de dados robusta.

As cópias de segurança são simples e oferecem uma forma de restaurar os dados na sua instância para o estado em que se encontravam no momento em que fez a cópia de segurança. No entanto, as cópias de segurança têm algumas limitações. Se eliminar a instância, as cópias de segurança também são eliminadas. Não pode fazer uma cópia de segurança de uma única base de dados ou tabela. Além disso, se a região onde a instância está localizada estiver indisponível, não pode restaurar a instância a partir dessa cópia de segurança, mesmo numa região disponível.

As exportações demoram mais tempo a criar, porque é criado um ficheiro externo no Cloud Storage que pode ser usado para recriar os seus dados. As exportações não são afetadas se eliminar a instância. Além disso, pode exportar apenas uma única base de dados ou até uma tabela, consoante o formato de exportação que escolher.

Quando usar a funcionalidade de exportação de cópias de segurança numa instância do SQL Server Enterprise ou Standard, evite criar um ficheiro de arquivo GZ, uma vez que tenta comprimir uma cópia de segurança que já está comprimida nativamente pelo SQL Server.

Proteja a sua instância e cópias de segurança contra eliminação acidental.

Uma instância do Cloud SQL que criar na Google Cloud consola ou através do Terraform ativa a prevenção de eliminação acidental por predefinição.

Use a funcionalidade de exportação no Cloud SQL para exportar os seus dados para proteção adicional. Use o Cloud Scheduler com a API REST para automatizar a gestão de exportações. Para cenários mais avançados, use o Cloud Scheduler com funções do Cloud Run para automatização.

Definições do SQL Server

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

Definições de configuração global

Definição Recomendação
max worker threads Mantenha o valor predefinido de 0. Esta definição define o número de threads disponíveis para o SQL Server com base no número de CPUs. O valor é calculado automaticamente pelo motor do SQL Server no arranque.
max server memory (mb)

Este indicador limita a quantidade de memória que o Cloud SQL pode atribuir aos respetivos conjuntos internos.

Recomendamos que deixe o Cloud SQL gerir o valor desta flag. Se tiver de gerir manualmente este valor, use a fórmula descrita mais adiante nesta secção.

Se não definir um valor para esta flag, o Cloud SQL gere o valor automaticamente com base no tamanho da RAM da sua instância. Se não definir um valor para a flag e redimensionar a instância, o Cloud SQL ajusta automaticamente o valor da flag para cumprir as nossas recomendações para o novo tamanho da instância. Esta operação de redimensionamento também remove qualquer valor definido manualmente para esta flag. Isto ajuda a sua base de dados a usar os recursos de forma mais eficaz, ajudando a evitar a atribuição excessiva, reduzindo a probabilidade de uma falha devido a problemas de falta de memória e ajudando a evitar a degradação do desempenho da sua instância.

Se preferir gerir o valor desta flag, defina-o manualmente. Como resultado, o Cloud SQL desativa a gestão automática. Se estiver a redimensionar a instância, o valor introduzido manualmente é rejeitado. O redimensionamento da instância reativa a gestão automática de flags. Se, após alterar o tamanho, quiser controlar manualmente o valor da flag, tem de introduzir um novo valor para reativar o controlo manual. Pondere rever o valor para corresponder aos valores recomendados para um novo tamanho.

Se tiver de gerir manualmente o valor da flag, recomendamos que use a seguinte fórmula para definir a flag da base de dados max server memory (mb):

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

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

  • 1,4 GB de memória para o SO e os agentes
  • 4 GB de memória, porque 104 GB é superior a 16 GB
  • 11 GB de memória, porque existem 88 GB de RAM que são superiores a 16 GB (104-16=88) e 88 dividido por 8 é 11

Para este exemplo, tem de reservar 16,4 GB de memória. Como resultado, para o valor deste sinalizador, especifique 89702 MB
[(104-16,4) * 1024 = 89702].

A tabela seguinte tem valores e percentagens recomendados da RAM total para alguns níveis de máquinas virtuais (VMs) populares:

Nível da instância (MB) max server memory (mb) % (total)
3840 1440 37
4096 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 monitorizar a utilização de 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

Para mais informações, consulte o artigo Monitorize instâncias do Cloud SQL.

Definições da base de dados a modificar

Para um desempenho ideal da base de dados do SQL Server, defina as seguintes definições do SQL Server conforme sugerido na tabela seguinte.

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

Este é o limite no qual o otimizador de SQL executa uma consulta usando o paralelismo. O valor predefinido de 5 pode fazer com que sejam executadas demasiadas consultas em paralelo, o que aumenta o tempo de espera da base de dados em threads paralelos. Para reduzir este tipo de contenda, aumente o valor.

O valor é ignorado quando maxdop está definido como 1.

max degree of parallelism (MAXDOP)

Para reduzir os tempos de espera da base de dados devido ao paralelismo, ajuste este valor com base em recomendações específicas sobre o número de processadores lógicos disponíveis. Meça cuidadosamente o desempenho se definir esta opção como 1.

Para mais informações, consulte max degree of parallelism (MAXDOP).

optimize for ad hoc workloads

Evite ter um grande número de planos de utilização única na cache de planos. Para melhorar a eficiência da cache de planos para cargas de trabalho que contêm muitos lotes ad hoc de utilização única, defina esta opção como 1.

tempdb

Defina o tamanho prévio de tempdb para que não precise de aumentar automaticamente. Todos os ficheiros em tempdb devem ter o mesmo tamanho e ter o mesmo conjunto de crescimento de ficheiros definido.

O tipo de espera da base de dados para a contenção de tempdb aparece como PAGELATCH_UP. Para reduzir a contenção, adicione mais ficheiros.

Se o número de processadores for igual ou inferior a 8, use o mesmo número de ficheiros que processadores lógicos. Se o número de processadores for superior a 8, use 8 ficheiros de dados. Se a contenção continuar, aumente o número de ficheiros em múltiplos de 4 até não haver mais contenção.

Consoante a sua carga de trabalho, também pode querer modificar as seguintes definições.

Definição Recomendação
Close Cursor on Commit Enabled O valor predefinido é off, o que significa que os cursores não são fechados automaticamente quando confirma uma transação.
Default Cursor Esta opção controla o âmbito de um cursor usado no código T-SQL. Se alterar esta definição, avalie o código da aplicação para verificar se existem efeitos adversos.
Page Verify Esta opção permite que o SQL Server calcule uma soma de verificação para uma página da base de dados antes de ser escrita 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 validar a integridade da página. O valor recomendado é checksum.
Parameterization O valor predefinido é simple. A parametrização simples permite que o SQL Server substitua valores literais numa consulta por parâmetros. A Microsoft fornece diretrizes sobre como alterar este valor e usá-lo com guias de planos.

Definições da base de dados a reter

Para um desempenho ideal da base de dados do SQL Server, mantenha os valores predefinidos das seguintes definições do SQL Server.

Definição Valor predefinido a manter
Auto Close False. Quando esta definição está ativada, abre e fecha ligações e limpa o procedimento após cada ligação. Isto pode causar uma degradação do desempenho em bases de dados acedidas com frequência.
Auto Shrink False. A ativação desta opção pode levar à fragmentação da base de dados e do índice, bem como a outros problemas de desempenho, alguns dos quais são abordados neste blogue do SQL Server.
Date Correlation Optimization Enabled False. A ativação desta opção permite que o otimizador encontre e otimize relações entre datas em duas tabelas relacionadas. O acompanhamento no SQL Server tem alguma sobrecarga de desempenho.
Legacy Cardinality Estimation False. Em alguns casos, o SQL Server não consegue calcular com precisão as cardinalidades quando esta definição está ativada.
Parameter Sniffing ON. A deteção de parâmetros de tabelas de bases de dados pode ajudar a criar planos de execução para reutilização. Se as tabelas tiverem dados distribuídos de forma desigual, os planos de execução resultantes podem originar problemas de desempenho. Com esses dados, use outras opções da Query Store em vez de modificar esta definição.
Query Optimizer Fixes False. Quando ativada, pode afetar o desempenho do estimador de cardinalidade do SQL Server. Se optar por ativá-la, teste para garantir que não existe regressão de consultas.
Auto Create Statistics True. Esta opção permite que o SQL Server crie estatísticas de coluna única que podem melhorar as estimativas de cardinalidade para planos de consultas.
Auto Update Statistics True. Esta opção permite que o SQL Server atualize as estatísticas desatualizadas através de um limite de recompilação baseado na cardinalidade da tabela.
Auto Update Statistics Asynchronously False. Quando esta opção está ativada, direciona o otimizador de consultas SQL para usar as estatísticas desatualizadas para a execução da consulta atual, enquanto atualiza as estatísticas de forma assíncrona para beneficiar cargas de trabalho futuras.

No entanto, se esperar um tempo de resposta previsível para uma consulta executada com frequência ou se a sua aplicação tiver frequentemente limites de tempo limite de pedidos do cliente enquanto aguarda atualizações de estatísticas, considere ativar esta opção e desativar Auto Update Statistics.

Target Recovery Time (Seconds) 60. Esta definição estabelece um limite superior para o tempo de recuperação de uma base de dados ao limpar as páginas sujas com maior ou menor frequência para o disco a partir do conjunto de buffers. Para cargas de trabalho altamente transacionais, um valor inferior para esta definição, combinado com os IOPS de armazenamento perto do valor máximo, pode contribuir para um gargalo de desempenho.

Definições de flags de rastreio

As flags de rastreio no SQL Server são usadas para definir determinadas caraterísticas, alterar o comportamento das bases de dados do SQL Server ou depurar problemas no SQL Server.

Algumas flags de rastreio do SQL Server são suportadas no Cloud SQL e podem ser definidas através de flags de base de dados. As definições recomendadas são as seguintes.

Sinalização de rastreio Recomendado
1204 Yes, exceto para servidores com cargas de trabalho intensivas que geram muitos bloqueios.

Devolve os recursos e os tipos de bloqueios que participam num impasse, bem como o comando atualmente afetado.
1222 Yes, exceto para servidores com cargas de trabalho intensivas que geram muitos bloqueios.
1224 No. Isto pode resultar numa maior utilização de memória e causar pressão de memória na base de dados.
2528 No. A verificação paralela de objetos é a predefinição e é recomendada. O grau de paralelismo é calculado automaticamente pelo motor de base de dados.
3205 No. As unidades de fita para cópias de segurança são uma funcionalidade do Cloud SQL para SQL Server.
3226 No, a menos que precise de cópias de segurança frequentes, como cópias de segurança de TLOG.
3625 No. Uma vez que a conta raiz não tem acesso de administrador do sistema, pode não conseguir ver todas as mensagens de erro.
4199 No. Isto afeta o estimador de cardinalidade e pode levar a uma regressão de consultas.
4616 No. Esta restrição diminui a segurança em torno das funções da aplicação. Tem de ser validado com base nos requisitos da aplicação.
7806 Yes. Se o servidor de base de dados deixar de responder, a ligação de administrador dedicada (DAC) pode ser a única forma de estabelecer uma ligação para diagnósticos.