Ligue Clientes a uma Sessão de Espelhamento de Base de Dados (SQL Server)

Aplica-se a: SQL Server

Para se ligar a uma sessão de espelhamento de base de dados, um cliente pode usar tanto o SQL Server Native Client como o .NET Framework Data Provider for SQL Server. Quando configurados para uma base de dados SQL Server, estes fornecedores de acesso a dados suportam totalmente o espelhamento de bases de dados. Para informações sobre considerações de programação para a utilização de uma base de dados espelhada, veja Utilização do Espelhamento de Base de Dados. Além disso, a instância atual do servidor principal deve estar disponível e o login do cliente deve ter sido criado na instância do servidor. Para mais informações, consulte Resolver problemas de utilizadores órfãos (SQL Server). As ligações de cliente a uma sessão de espelhamento de base de dados não envolvem a instância do servidor testemunha, caso esta exista.

Estabelecer a Ligação Inicial a uma Sessão de Espelhamento de Base de Dados

Para a ligação inicial a uma base de dados espelhada, o cliente deve fornecer uma cadeia de ligação que forneça minimamente o nome de uma instância de servidor. Este nome de servidor necessário deve identificar a instância principal atual do servidor principal e é conhecido como o nome inicial do parceiro.

Opcionalmente, a cadeia de ligação pode também fornecer o nome de outra instância de servidor, que deverá identificar a instância atual do servidor espelho, para uso caso o parceiro inicial não esteja disponível durante a primeira tentativa de ligação. O segundo nome é conhecido como o nome do parceiro de failover.

A cadeia de ligação deve também fornecer um nome de base de dados. Isto é necessário para permitir tentativas de failover por parte do fornecedor de acesso aos dados.

Ao receber uma cadeia de ligação, o fornecedor de acesso a dados armazena o nome inicial do parceiro e o nome do parceiro de failover, se forem fornecidos, numa cache na memória volátil do cliente (para código gerido, a cache é direcionada para o domínio da aplicação). Uma vez armazenado em cache, o nome inicial do parceiro nunca é atualizado pelo fornecedor de acesso aos dados. Quando o cliente fornece o nome do parceiro de ativação pós-falha, o fornecedor de acesso aos dados também armazena temporariamente esse nome do parceiro de ativação pós-falha, caso não consiga estabelecer ligação utilizando o nome inicial do parceiro.

Uma sessão de espelhamento de base de dados não protege contra problemas de acesso ao servidor específicos dos clientes, como quando um computador cliente tem problemas de comunicação com a rede. Uma tentativa de ligação a uma base de dados espelhada também pode falhar por várias razões que não estão relacionadas com o fornecedor de acesso aos dados; Por exemplo, uma tentativa de ligação pode falhar porque a instância principal do servidor está inativa, como acontece quando a base de dados está a fazer failover, ou devido a um erro de rede.

Ao tentar ligar-se, o fornecedor de acesso a dados começa por usar o nome inicial do parceiro. Se a instância de servidor especificada estiver disponível e for a instância principal atual, a tentativa de ligação normalmente tem sucesso.

Se essa tentativa não resultar, o fornecedor de acesso aos dados tenta o nome do parceiro de failover, se disponível. Se qualquer nome de parceiro identificar corretamente o servidor principal atual, o fornecedor de acesso a dados normalmente consegue abrir a ligação inicial. Ao concluir esta ligação, o fornecedor de acesso a dados descarrega o nome da instância do servidor espelho atual. Este nome é armazenado na memória cache como o nome do parceiro de ativação pós-falha, substituindo o nome do parceiro de ativação pós-falha fornecido pelo cliente, caso exista. A partir desse momento, o .NET Framework Data Provider for SQL Server não atualiza o nome do parceiro de failover. Em contraste, o SQL Server Native Client atualiza a cache sempre que uma ligação ou reinício subsequente devolve um nome de parceiro diferente.

A figura seguinte ilustra uma ligação de cliente ao parceiro inicial, Partner_A, para uma base de dados espelhada chamada Db_1. Esta figura mostra um caso em que o nome inicial do parceiro fornecido pelo cliente identifica corretamente o servidor principal atual, Partner_A. A tentativa inicial de ligação é bem-sucedida, e o fornecedor de acesso aos dados armazena o nome do servidor espelho ( atualmente Partner_B) como o nome do parceiro de failover na cache local. Finalmente, o cliente liga-se à cópia principal da base de dados Db_1.

A tentativa inicial de ligação pode falhar, por exemplo, devido a um erro de rede ou a uma instância de servidor inativa. Como o parceiro inicial não está disponível, para que o fornecedor de acesso aos dados tente ligar-se ao parceiro de failover, o cliente deve ter fornecido o nome do parceiro de failover na cadeia de ligação.

Nesse caso, se o nome do parceiro de failover não estiver disponível, a tentativa de ligação original continua até que seja atingido o tempo limite da ligação de rede ou seja devolvido um erro (tal como acontece numa base de dados não espelhada).

Quando o nome do parceiro de failover é fornecido na cadeia de ligação, o comportamento do fornecedor de acesso a dados depende do protocolo de rede e do sistema operativo do cliente, da seguinte forma:

• No caso de TCP/IP, as tentativas de ligação são controladas por um algoritmo de repetição das tentativas de ligação específico do espelhamento de bases de dados. O algoritmo de retentativa de ligação determina o tempo máximo (o tempo de retentativa) atribuído para abrir uma ligação numa dada tentativa de ligação.

• Para outros protocolos de rede

  Se ocorrer um erro ou se o parceiro inicial não estiver disponível, a tentativa inicial de ligação aguarda até que o período de tempo de espera da ligação à rede expire ou o período de tempo de espera de login expire no fornecedor de acesso aos dados. Normalmente, esta espera é da ordem dos 20 a 30 segundos. Em seguida, se o fornecedor de acesso a dados não tiver excedido o tempo limite, tenta estabelecer ligação ao parceiro de ativação pós-falha. Se o período de timeout da ligação expirar antes da ligação ser bem-sucedida ou se o parceiro de failover não estiver disponível, a tentativa de ligação falha. Se o parceiro de failover estiver disponível dentro do período limite de início de sessão e for então o servidor principal, a tentativa de ligação normalmente é bem-sucedida.

Cadeias de Ligação para uma Base de Dados em Espelho

A cadeia de ligação fornecida pelo cliente contém informação que o fornecedor de acesso a dados utiliza para se ligar à base de dados. Esta secção descreve as palavras-chave especificamente relevantes para estabelecer ligação a uma base de dados espelhada através de uma ligação ODBC com o controlador SQL Server Native Client.

Atributo de Rede

A cadeia de ligação deve conter o atributo Rede para especificar o protocolo de rede. Isto garante que o protocolo de rede especificado persiste entre ligações a diferentes parceiros. O melhor protocolo para ligar a uma base de dados espelhada é o TCP/IP. Para garantir que o cliente solicita TCP/IP para cada ligação aos parceiros, uma cadeia de ligação fornece o seguinte atributo:

Network=dbmssocn;   

Em alternativa, para garantir que o cliente solicita pipes nomeados para cada ligação aos parceiros, uma cadeia de ligação fornece o seguinte atributo:

Network=dbnmpntw;   

Atributo do Servidor

A cadeia de ligação deve conter um atributo do servidor que forneça o nome inicial do parceiro, o que deve identificar a instância atual do servidor principal.

A forma mais simples de identificar a instância do servidor é especificar o seu nome, <server_name>[\<SQL_Server_instance_name>]. Por exemplo:

Server=Partner_A;

or

Server=Partner_A\Instance_2;

No entanto, quando o nome do sistema é utilizado, o cliente deve realizar uma consulta DNS para obter o endereço IP do servidor e uma consulta ao SQL Server Browser para obter o número de porta do servidor onde o parceiro reside. Essas pesquisas e consultas podem ser ignoradas especificando o endereço IP e o número da porta do parceiro no atributo Server, em vez de especificar o nome do servidor. Isto é recomendado para minimizar a possibilidade de atrasos externos ao ligar-se a esse parceiro.

Para especificar o endereço IP e a porta, o atributo Servidor assume a seguinte forma, Server=<ip_address>,<porta>, por exemplo:

Server=123.34.45.56,4724;   

Atributo da Base de Dados

Além disso, a cadeia de ligação deve especificar o atributo Database para fornecer o nome da base de dados espelhada. Se a base de dados não estiver disponível quando o cliente tentar ligar-se, é criada uma exceção.

Por exemplo, para se ligar expressamente à base de dados AdventureWorks na Partner_A principal do servidor, um cliente utiliza o seguinte cadeia de ligação:

" Server=Partner_A; Database=AdventureWorks "

Atributo do Parceiro de Failover

Para além do nome do parceiro inicial, o cliente também pode especificar o nome do parceiro de contingência, que deve identificar a instância atual do servidor espelho. O parceiro de failover é especificado através de uma das palavras-chave do atributo "failover partner". A palavra-chave para este atributo depende da API que está a usar. A tabela seguinte lista estas palavras-chave:

A forma mais simples de identificar a instância do servidor é pelo nome do seu sistema, <server_name>[\<SQL_Server_instance_name>].

Alternativamente, o endereço IP e o número de porta podem ser fornecidos no atributo Parceiro de Failover . Se a tentativa inicial de ligação falhar durante a primeira ligação à base de dados, a tentativa de ligação ao parceiro de failover será libertada da dependência do DNS e do SQL Server Browser. Assim que uma conexão for estabelecida, o nome do parceiro de failover será substituído pelo nome do parceiro de failover, pelo que, se ocorrer um failover, as conexões redirecionadas requererão DNS e o SQL Server Browser.

Exemplo de Cadeia de Ligação

Por exemplo, para ligar explicitamente usando TCP/IP à base de dados AdventureWorks em Partner_A ou Partner_B, uma aplicação cliente que utilize o Driver ODBC poderia fornecer as seguintes cadeia de ligação:

"Server=Partner_A; Failover_Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"  

Em alternativa, o cliente pode usar o endereço IP e o número de porta para identificar o parceiro inicial, Partner_A; por exemplo, se o endereço IP for 250.65.43.21 e o número de porta for 4734, a cadeia de ligação seria:

"Server=250.65.43.21,4734; Failover_Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"  

Algoritmo de Retentativa de Ligação (para Ligações TCP/IP)

Para uma ligação TCP/IP, quando ambos os nomes dos sistemas parceiros estão na cache, o fornecedor de acesso a dados segue um algoritmo de repetição de tentativas de ligação. Isto é verdade tanto para fazer a ligação inicial à sessão como para reconectar após perder uma ligação estabelecida. Uma vez aberta uma ligação, completar os passos de pré-login e de login demora mais tempo.

Se uma tentativa de ligação falhar ou se o tempo limite para nova tentativa expirar antes de ter êxito, o fornecedor de acesso a dados tenta o outro parceiro. Se uma ligação não for aberta até este ponto, o fornecedor tenta alternadamente os nomes iniciais e de failover dos parceiros, até que uma ligação seja aberta ou o período de login expire. O tempo de espera predefinido para iniciar sessão é de 15 segundos. Recomendamos que o período de espera de login seja de pelo menos 5 segundos. Especificar um período de time-out mais curto pode impedir que qualquer tentativa de ligação tenha sucesso.

O tempo de nova tentativa é uma percentagem do período de início de sessão. O tempo entre tentativas de conexão aumenta em cada ronda sucessiva. Na primeira ronda, o tempo de repetição para cada uma das duas tentativas é de 8 por cento do período total de login. Em cada nova tentativa, o algoritmo de novas tentativas aumenta o tempo máximo de repetição no mesmo valor. Assim, os intervalos entre as primeiras oito tentativas de ligação são os seguintes:

8%, 8%, 16%, 16%, 24%, 24%, 32%, 32%

O tempo até nova tentativa é calculado com base na seguinte fórmula:

RetryTime=PreviousRetryTime+( 0.08 *LoginTimeout)

Onde PreviousRetryTime é inicialmente 0.

Por exemplo, se usar o período padrão de tempo de espera de login de 15 segundos, LoginTimeout= 15. Neste caso, o número de tentativas de repetição previsto nas três primeiras rondas é o seguinte:

A figura seguinte ilustra estes tempos de repetição para tentativas de ligação sucessivas, cada uma das quais expira.

Para o período padrão de tempo de início de sessão, o tempo máximo atribuído às três primeiras rondas de tentativas de ligação é de 14,4 segundos. Se cada tentativa usasse todo o tempo estipulado, apenas 0,6 segundos permaneceriam antes do período de login expirar. Nesse caso, a quarta ronda seria encurtada, permitindo apenas uma última tentativa rápida de ligar usando o nome inicial do parceiro. No entanto, uma tentativa de ligação pode falhar antes de esgotado o tempo de repetição atribuído, sobretudo nas rondas posteriores. Por exemplo, a ocorrência de um erro de rede pode fazer com que uma tentativa termine antes de o tempo de repetição expirar. Se tentativas anteriores falharem devido a um erro de rede, haveria tempo adicional disponível para a quarta ronda e, talvez, para rondas adicionais.

Outra causa de uma tentativa falhada é uma instância de servidor inativa, como acontece quando uma instância de servidor está envolvida em falhas sobre a sua base de dados. Neste caso, é aplicado um atraso antes de nova tentativa para evitar que os clientes sobrecarreguem os parceiros com uma sucessão rápida de tentativas de conexão.

Atrasos nas novas tentativas durante a comutação por falha

Se um cliente tentar ligar-se a um parceiro que está a falhar, o parceiro responde imediatamente que está inativo. Neste caso, cada série de tentativas de ligação é muito mais breve do que o tempo atribuído para novas tentativas. Isto significa que podem ocorrer muitas tentativas de ligação antes de o tempo limite de início de sessão expirar. Para evitar sobrecarregar os parceiros com uma rápida série de tentativas de ligação durante uma comutação por falha, o fornecedor de acesso a dados adiciona um breve intervalo antes de nova tentativa após cada ciclo de repetição de tentativas. A duração de um determinado atraso de repetição é determinada pelo algoritmo de atraso de repetição. Após a primeira ronda, o atraso é de 100 milissegundos. Após cada uma das três tentativas seguintes, o intervalo até nova tentativa duplica para 200, depois 400 e 800. Para todas as tentativas seguintes, o intervalo entre tentativas é de 1 segundo até que a tentativa de ligação seja bem-sucedida ou atinja o tempo limite.

A figura seguinte ilustra como o atraso entre tentativas afeta as tentativas de ligação durante um failover manual, em que os parceiros trocam de papéis. O período de espera de login é de 15 segundos.

Restabelecer a ligação a uma sessão de espelhamento da base de dados

Se uma ligação estabelecida a uma sessão de espelhamento de base de dados falhar por qualquer motivo, por exemplo, devido a uma comutação por erro do espelhamento da base de dados, e a aplicação tentar restabelecer a ligação ao servidor inicial, o fornecedor de acesso a dados pode tentar restabelecer a ligação utilizando o nome do parceiro de comutação por erro armazenado na cache do cliente. No entanto, a reconexão não é automática. A aplicação deve tomar conhecimento do erro. Depois, a aplicação precisa de fechar a ligação falhada e abrir uma nova ligação usando os mesmos atributos da cadeia de ligação. Neste ponto, o fornecedor de acesso a dados redireciona a ligação para o parceiro de failover. Se a instância do servidor identificada por este nome for atualmente o servidor principal, a tentativa de ligação geralmente tem sucesso. Se não estiver claro se uma transação foi comprometida ou revertida, a aplicação deve verificar o estado da transação, da mesma forma que ao reconectar-se a uma instância de servidor autónoma.

A reconexão assemelha-se a uma ligação inicial para a qual a cadeia de ligação forneceu um nome de parceiro de failover. Se a primeira tentativa de ligação falhar, as tentativas de ligação alternam entre o nome inicial do parceiro e o nome do parceiro de failover até que o cliente se ligue ao servidor principal ou o fornecedor de acesso a dados expire.

Se as ligações usarem TCP/IP, o algoritmo de retentativa de ligação determina o tempo atribuído às tentativas de ligação em cada ronda.

Impacto do Redirecionamento numa Aplicação Cliente

Após um failover, o fornecedor de acesso aos dados redireciona a ligação para a instância atual do servidor principal. No entanto, o redirecionamento é transparente para os clientes. Para um cliente, uma ligação redirecionada parece ser uma ligação à instância do servidor identificada pelo nome inicial do parceiro. Quando o parceiro inicial é atualmente o servidor espelho, o cliente pode parecer estar ligado ao servidor espelho e a atualizar a base de dados espelhada. Na verdade, no entanto, o cliente foi redirecionado para o parceiro de failover, que é a base de dados principal atual, e o cliente está a atualizar a nova base de dados principal.

Após ser redirecionado para o parceiro de failover, um cliente pode experienciar resultados inesperados ao usar uma instrução Transact-SQL USE para usar uma base de dados diferente. Isto pode acontecer se a instância atual do servidor principal (o parceiro de failover) tiver um conjunto diferente de bases de dados do servidor principal original (o parceiro inicial).

O Impacto de um Nome de Parceiro de Failover Obsoleto

O administrador da base de dados pode mudar o parceiro de failover a qualquer momento. Portanto, um nome de parceiro de failover fornecido pelo cliente pode estar desatualizado ou obsoleto. Por exemplo, considere um parceiro de failover chamado Partner_B que é substituído por outra instância de servidor, Partner_C. Agora, se um cliente fornecer Partner_B como nome do parceiro de failover, esse nome fica obsoleto. Quando o nome do parceiro de failover fornecido pelo cliente está obsoleto, o comportamento do fornecedor de acesso a dados equivale ao caso em que o nome do parceiro de failover não é fornecido pelo cliente.

Por exemplo, considere uma situação em que um cliente usa uma cadeia de ligação para uma série de quatro tentativas de ligação. No cadeia de ligação, o nome inicial do parceiro é Partner_A, e o nome do parceiro de failover é Partner_B:

"Server=Partner_A; Failover Partner=Partner_B; Database=AdventureWorks"  

A tabela seguinte mostra quatro configurações de parceiros e indica para cada uma se esta cadeia de ligação funciona para ligar o cliente pela primeira vez.

Conteúdo relacionado

• Espelhamento de Base de Dados (SQL Server)
• Possíveis falhas durante o espelhamento de bases de dados