Usando o espelhamento de banco de dados no SQL Server Native Client

  • Artigo

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada de SQL do AzureAzure Synapse AnalyticsPDW (Analytics Platform System)

Observação

Esse recurso será removido em uma versão futura do SQL Server. Evite usar esse recurso em desenvolvimentos novos e planeje modificar os aplicativos que atualmente o utilizam. Use Grupos de disponibilidade AlwaysOn em vez disso.

Importante

O SQL Server Native Client (geralmente abreviado como SNAC) foi removido do SQL Server 2022 (16.x) e do SSMS (SQL Server Management Studio) 19. O SQL Server Native Client (SQLNCLI ou SQLNCLI11) e o Provedor OLE DB herdado da Microsoft para o SQL Server (SQLOLEDB) não são recomendados para um novo desenvolvimento de aplicativo. Alterne para o novo Driver do Microsoft OLE DB para SQL Server (MSOLEDBSQL) ou o Microsoft ODBC Driver for SQL Server mais recente no futuro. Para SQLNCLI que é fornecido como um componente do Mecanismo de Banco de Dados do SQL Server (versões 2012 a 2019), confira esta exceção de Ciclo de Vida de Suporte.

O espelhamento de banco de dados, apresentado no SQL Server 2005 (9.x), é uma solução que visa aumentar a disponibilidade do banco de dados e a redundância de dados. O SQL Server Native Client fornece suporte implícito para espelhamento de banco de dados, portanto, o desenvolvedor não precisa escrever nenhum código ou executar qualquer outra ação depois de configurado para o banco de dados.

O espelhamento de banco de dados, que é implementado para cada banco de dados, mantém uma cópia de um banco de dados de produção do SQL Server em um servidor em espera. Esse servidor é um servidor em espera ativa ou passiva, dependendo da configuração e do estado da sessão de espelhamento de banco de dados. Um servidor em espera ativa dá suporte ao failover rápido sem perda de transações confirmadas, e um servidor em espera passiva dá suporte ao serviço de imposição (com possível perda de dados).

O banco de dados de produção é chamado de banco de dados principal, e a cópia em espera é chamada de banco de dados espelho. O banco de dados principal e o banco de dados espelho precisam residir em instâncias separadas do SQL Server (instâncias do servidor) e, se possível, em computadores separados.

A instância do servidor de produção, chamado servidor principal, se comunica com a instância do servidor em espera, chamado servidor espelho. Os servidores principal e espelho atuam como parceiros dentro de uma sessão de espelhamento de banco de dados. Se o servidor principal falhar, o servidor espelho poderá transformar seu banco de dados no banco de dados principal por meio de um processo chamado failover. Por exemplo, Parceiro_A e Parceiro_B são dois servidores parceiros, com o banco de dados principal inicialmente no Parceiro_A como servidor principal e o banco de dados espelho residindo no Parceiro_B como o servidor espelho. Se o Parceiro_A ficar offline, o banco de dados no Parceiro_B pode fazer failover para se tornar o banco de dados principal atual. Quando o Parceiro_A ingressar novamente na sessão de espelhamento, ele se tornará o servidor espelho e seu banco de dados se tornará o banco de dados espelho.

Configurações alternativas de espelhamento de banco de dados oferecem diferentes níveis de desempenho e segurança de dados, e dão suporte a diversas formas de failover. Para obter mais informações, confira Espelhamento de banco de dados (SQL Server).

É possível usar um alias ao especificar o nome de banco de dados espelho.

Observação

Para obter informações sobre tentativas de conexão inicial e tentativas de reconexão com um banco de dados espelho, confira Conectar clientes a uma sessão de espelhamento de banco de dados (SQL Server).

Considerações sobre programação

Quando o servidor do banco de dados principal falhar, o aplicativo cliente receberá erros em resposta a chamadas API, o que indica que a conexão com o banco de dados foi interrompida. Quando isto acontece, todas as alterações não confirmadas do banco de dados são perdidas e a transação atual é revertida. Se isso ocorrer, o aplicativo deve fechar a conexão (ou liberar o objeto da fonte de dados) e abri-la novamente. A conexão é redirecionada de forma transparente para o banco de dados espelho, que agora atua como servidor principal.

Quando uma conexão é estabelecida, o servidor principal envia a identidade de seu parceiro de failover ao cliente a ser usado quando ocorrer failover. No caso de um aplicativo tentar estabelecer uma conexão depois que o servidor principal falhou, o cliente não sabe a identidade do parceiro de failover. Para que os clientes possam lidar com este cenário, uma propriedade de inicialização e uma palavra-chave de cadeia de conexão associada permitem que o próprio cliente especifique a identidade do parceiro de failover. O atributo do cliente é usado apenas nesse cenário; se o servidor principal estiver disponível, ele não será usado. Se o servidor do parceiro de failover fornecido pelo cliente não se referir a um servidor que está atuando como um parceiro de failover, a conexão será recusada pelo servidor. Para que os aplicativos possam se adaptar a alterações de configuração, a identidade do parceiro de failover real pode ser determinada inspecionando o atributo depois que a conexão for estabelecida. Considere o armazenamento em cache das informações do parceiro para atualizar a cadeia de conexão ou criar uma estratégia de repetição no caso de falha da primeira tentativa de estabelecer uma conexão.

Observação

Especifique explicitamente o banco de dados a ser usado por uma conexão, se desejar usar esse recurso em um DSN, uma cadeia de conexão ou uma propriedade/atributo da conexão. O SQL Server Native Client não tentará fazer failover para o banco de dados parceiro se isso não for feito.

O espelhamento é um recurso do banco de dados. Talvez os aplicativos que usam vários bancos de dados não consigam explorar esse recurso.

Além disso, os nomes de servidor não diferenciam maiúsculas de minúsculas, mas os nomes de banco de dados o fazem. Portanto, certifique-se de usar as mesmas maiúsculas e minúsculas em DSNs e cadeias de conexões.

Provedor OLE DB do SQL Server Native Client

O provedor OLE DB do SQL Server Native Client oferece suporte ao espelhamento de banco de dados por meio de atributos de cadeia de conexão e conexão. A propriedade SSPROP_INIT_FAILOVERPARTNER foi adicionada ao conjunto de propriedades DBPROPSET_SQLSERVERDBINIT e a palavra-chave FailoverPartner é um novo atributo de cadeia de conexão para DBPROP_INIT_PROVIDERSTRING. Para obter mais informações, consulte Usando palavras-chave de cadeia de conexão com o SQL Server Native Client.

O cache de failover é mantido enquanto o provedor é carregado, ou seja, até que CoUninitialize seja chamado ou desde que o aplicativo tenha uma referência a algum objeto gerenciado pelo provedor OLE DB do SQL Server Native Client, como um objeto de fonte de dados.

Para obter detalhes sobre o suporte do provedor OLE DB do SQL Server Native Client para espelhamento de banco de dados, consulte Propriedades de inicialização e autorização.

Driver ODBC do SQL Server Native Client

O driver ODBC do SQL Server Native Client oferece suporte ao espelhamento de banco de dados por meio de atributos de conexão e cadeia de conexão. Especificamente, o atributo SQL_COPT_SS_FAILOVER_PARTNER foi adicionado para uso com as funções SQLSetConnectAttr e SQLGetConnectAttr e a palavra-chave Failover_Partner foi adicionada como um novo atributo de cadeia de conexão.

O cache de failover é mantido enquanto o aplicativo tem pelo menos um identificador de ambiente alocado. Por outro lado, ele é perdido quando o último identificador de ambiente for desalocado.

Observação

O Gerenciador de Driver ODBC foi aprimorado para dar suporte à especificação do nome do servidor de failover.

Confira também

Recursos do SQL Server Native Client
Conectar clientes a uma sessão de espelhamento de banco de dados (SQL Server)
Espelhamento de banco de dados (SQL Server)