Exportar (0) Imprimir
Expandir Tudo

Limitação do banco de dados SQL do Azure

Atualizado: fevereiro de 2015

Este tópico descreve em detalhe o mecanismo de limitação do mecanismo, os códigos de erro associados e como direcionar os erros que você possa encontrar.

A tabela a seguir fornece informações sobre o mecanismo de limitação do mecanismo, o código de erro correspondente que é retornado e a recomendação sobre como endereçá-lo.

 

Mecanismo de limitação do mecanismo Código de erro retornado Recomendação

A limitação do mecanismo segue estas etapas para reduzir a carga e proteger a integridade do sistema:

  1. Determina a redução de carga necessária para retornar o sistema para um estado íntegro.

  2. Marca os bancos de dados do assinante que estão consumindo recursos excessivos como candidatos de limitação. Se a limitação do mecanismo estiver ocorrendo devido a um tipo excedido suavemente, alguns bancos de dados podem ser isentos da consideração como candidatos de limitação. Se a limitação de mecanismo for devido a um tipo excedido significativamente, todos os bancos de dados do assinante poderão ser candidatos à limitação com exceção dos bancos de dados do assinante que não receberam nenhuma carga no ciclo de limitação imediatamente antes do ciclo de limitação atual.

  3. Calcula quantos bancos de dados candidatos devem ser limitados para retornar o sistema para um estado íntegro avaliando os padrões históricos de uso de recursos dos bancos de dados candidato.

  4. Limita o número calculado de bancos de dados candidatos até que a carga do sistema seja retornada ao nível desejado. Dependendo se é Limitação de hardware ou Limitação de software, o grau aplicado ou o modo pode variar. Você pode descobrir o grau e o modo de estrangulamento aplicado usando a ID e os valores de código do incidente na mensagem de erro. Todos os bancos de dados que são limitados permanecem assim no mínimo durante um ciclo de limitação (10 segundos), mas geralmente a limitação pode persistir por vários ciclos de limitação para retornar o sistema para um estado íntegro

40501: o serviço está atualmente ocupado. Tente novamente a solicitação depois de 10 segundos. ID do incidente: <ID>. Código: <código>.

noteObservação
Os valores de ID do incidente e Código podem ser usados para determinar quais solicitações são limitadas e se foi uma limitação de software ou hardware. Para obter mais informações, consulte as seções “ID do incidente de limitação” e “Decodificando códigos de motivo” posteriormente neste tópico.

Solicitação de retirada e repetição depois de 10 segundos.

A ID do incidente de limitação no erro 40501 é um valor GUID que identifica exclusivamente um incidente de limitação.

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: <ID>. Code: <code>.

Se você não puder determinar por que a limitação ocorreu ou se persiste, e não souber resolvê-la, entre em contato com o Suporte da Microsoft e indique a ID do incidente (<ID>) na mensagem de erro. O Suporte da Microsoft utilizará a ID do incidente para recuperar mais informações relacionadas ao incidente de limitação. A ID do incidente poderá ser usada para obter as seguintes informações:

  • A hora de início do incidente de limitação.

  • O tipo de limitação (limitação flexível ou limitação rígida).

  • O tipo de recurso (por exemplo, CPU) pelo qual o incidente de limitação ocorreu.

  • Qual usuário estava sendo executado quando ocorreu o incidente de limitação?

Depois de obter a causa original relevante do Atendimento ao Cliente da Microsoft, você poderá fazer as alterações apropriadas no aplicativo.

A seguinte seção descreve como decodificar os códigos de motivo que são retornados pelo seguinte código de erro de limitação de mecanismo.

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: <ID>. Code: <code>.

O código do motivo (<código>) na mensagem de erro é um número decimal que contém informações sobre o modo de limitação e os tipos de recursos excedidos:

  • O modo de limitação enumera os tipos de instrução rejeitados.

  • O tipo de recurso especifica os recursos excedidos. A limitação pode ocorrer em vários tipos de recurso ao mesmo tempo, como a CPU e a ES.

Considere a seguinte mensagem de erro de exemplo como um exemplo, onde o código do motivo é 131075.

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: {5DE17AB8-A6E34BE5-A2E95BB5D4CC4155}. Code: 131075.

O diagrama a seguir demonstra como decodificar os códigos de motivo.

Decodificando c��digos de motivo

Para obter o modo de limitação, aplique o módulo 4 ao código de motivo. A operação do módulo retorna o restante de um número dividido por outro. Para obter o tipo de limitação e o tipo de recurso, divida o código do motivo por 256, como mostra a etapa 1. Em seguida, converta o quociente do resultado em seu equivalente binário, como mostra as etapas 2 e 3. O diagrama lista todos os tipos de limitação e recursos. Compare seu tipo de limitação com os bits do tipo de recurso conforme mostrado no diagrama.

A tabela a seguir fornece uma lista dos modos de limitação.

 

Código do modo de limitação Descrição Tipos de instrução rejeitados Instruções que ainda podem ser processadas

0

Nenhuma limitação

Nenhum

Tudo

1

Rejeitar atualização / inserção

INSERT, UPDATE, CREATE TABLE | INDEX

DELETE, DROP TABLE | INDEX, TRUNCATE

2

Rejeitar todas as gravações

INSERT, UPDATE, DELETE, CREATE, DROP

SELECT

3

Rejeitar tudo

Tudo

Nenhum

Para obter o modo de limitação, aplique o módulo 4 ao código de motivo. 131075 % 4 = 3. O resultado 3 significa que o modo de limitação é "Rejeitar Tudo".

Para obter o tipo de limitação e o tipo de recurso, divida o código de motivo por 256. Em seguida, converta o quociente do resultado para seu equivalente binário. 131075 / 256 = 512 (decimal) e 512 (decimal) = 10 00 00 00 00 (binário). Isso significa que ocorreu limitação no banco de dados devido à CPU (Tipo de recurso 4) e à Limitação rígida (10).

O código de exemplo a seguir usa a classe ThrottlingCondition no bloqueio transitório do aplicativo de tratamento de falhas (também conhecido como “topázio ") no Enterprise Library Integration Pack para o Azure para decodificar o código do motivo do erro do mecanismo de limitação (40501). Para baixar os assemblies do bloqueio Transient Fault Handling Application e o código de motivo para usar a classe ThrottlingCondition, consulte Enterprise Library 5.0 Integration Pack para Azure.

O seguinte código de exemplo solicita a digitação do código do motivo que você recebe no erro de limitação do mecanismo (40501) e exibe o modo de limitação, o tipo de limitação e o tipo de recurso para o código do motivo especificado.

using System;
using Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.Data;

namespace ThrottlingDecoder
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.Write("Enter a throttling code to be decoded: ");
            var rawCode = Console.ReadLine();
            int reasonCode;

            if (Int32.TryParse(rawCode, out reasonCode))
            {
                var throttlingCode = ThrottlingCondition.FromReasonCode(reasonCode);

                Console.WriteLine("\nBreakdown for throttling reason code {0}:\n", reasonCode);

                Console.WriteLine("Throttling mode: {0}", throttlingCode.ThrottlingMode);
                Console.WriteLine("Throttled On CPU: {0}", throttlingCode.IsThrottledOnCpu);
                Console.WriteLine("Throttled On DB Size: {0}", throttlingCode.IsThrottledOnDatabaseSize);
                Console.WriteLine("Throttled On DB Reads: {0}", throttlingCode.IsThrottledOnDataRead);
                Console.WriteLine("Throttled On DB Free space: {0}", throttlingCode.IsThrottledOnDataSpace);
                Console.WriteLine("Throttled On Log Free Size: {0}", throttlingCode.IsThrottledOnLogSpace);
                Console.WriteLine("Throttled On Log Writes: {0}", throttlingCode.IsThrottledOnLogWrite);
                Console.WriteLine("Throttled On Worker Threads: {0}", throttlingCode.IsThrottledOnWorkerThreads);
                
                Console.WriteLine("\nThrottled resources:");

                foreach (var res in throttlingCode.ThrottledResources)
                {
                   if (res.Item2 != ThrottlingType.None) Console.ForegroundColor = ConsoleColor.Red;
                    Console.WriteLine("Resource type {0} is throttled on {1}", res.Item1, res.Item2);
                    if (res.Item2 != ThrottlingType.None) Console.ResetColor();
                }
            }
            else
            {
                Console.WriteLine("Sorry, but the input you provided does not seem to be a valid number.");
            }
            Console.Read();
        }
    }
}

O gateway TDS do Banco de dados SQL repete conexões por aproximadamente 30 segundos antes de relatar uma falha. Se você espera que um alto volume de tráfego do aplicativo, crie uma lógica de repetição em seu aplicativo. Se uma conexão falhar, faça o seguinte:

  • Controle a ociosidade e as desconexões temporárias.

    noteObservação
    Instale a Atualização de confiabilidade 1 para o .NET Framework 4.0 que corrige o problema de o SqlClient retornar conexões inoperantes ao aplicativo. Com essa atualização, o SqlClient verifica se a conexão no pool está inoperante antes de retornar ao aplicativo. Se a conexão estiver inoperante, o SqlClient reconecta-se antes de retorná-la para o aplicativo. Para obter mais informações sobre esse problema, consulte Minimizando erros do pool de conexões no Banco de dados SQL.

  • Tente se conectar ao Banco de dados SQL em intervalos de 10 segundos até que os recursos estejam disponíveis e a conexão seja restabelecida. Dependendo de seu aplicativo, bancos de dados e carga de trabalho de rede, você deverá aumentar o tempo de atraso conforme o necessário.

  • Altere sua carga de trabalho se uma conexão for encerrada novamente. Se uma conexão for encerrada novamente, examine o código de erro, localize o problema real e tente alterar sua carga de trabalho. Você pode implementar uma fila ou um mecanismo de atraso em seu aplicativo cliente para reduzir a carga de trabalho.

    Outra solução poderia ser recriar seu aplicativo e o banco de dados para remover os afunilamentos de recursos. Verifique se o aplicativo não sobrecarrega o tempdb com operações excessivas de DDL ou DML. Além disso, verifique se as transações não bloqueiam nenhum recurso. Quando apropriado, faça o particionamento do banco de dados em vários bancos de dados.

  • Verifique se o código pode se recuperar da limitação. Os usuários devem supor que as conexões possam ser desconectadas a qualquer momento em um aplicativo. Portanto, faça uma solicitação em lote em uma única transação sempre que possível. Isso minimiza os casos em que um lote foi parcialmente concluído e coloca o banco de dados em um estado inesperado/não testado. Para fazer isso, utilize BEGIN TRANS/COMMIT TRANS em torno de cada lote ad hoc, e no início/término de cada procedimento armazenado.

  • Entenda como a lógica de repetição afeta a exatidão de um aplicativo (idempotência). Ao executar atualizações ou inserções, é importante entender o que acontece quando uma conexão é desconectada antes de o sucesso ser retornado. Se a transação for cancelada, repetir a conexão será a etapa correta. Se a transação for realmente confirmada, executar a transação novamente poderá não ser correto. Os usuários que executam as alterações que não são idempotentes podem precisar modificar seu esquema de banco de dados lógico para ser capaz de detectar confirmações da transação repetidas com base na lógica de repetição que está sendo utilizada para proteger contra desconexões.

Use o código de repetição para registrar erros de limitação para distinguir entre a conexão transitória, a limitação e a falha de hardware, sintaxe, procedimentos armazenados ausentes e assim por diante. Isso é particularmente útil em cenários de solução de problemas se você não puder se conectar ao Banco de dados SQL. Nesse caso, os esforços de solução de problemas se concentrarão nas informações registradas em log; e a capacidade de solução de problemas efetivamente correlacionará a qualidade das informações registradas em log. Para obter mais informações sobre como implementar registro em log em aplicativos do Banco de dados SQL, consulte Implementando o registro em log para aplicativos de Banco de dados SQL do Azure.

Consulte também

Mostrar:
© 2015 Microsoft