Suporte ao Driver do OLE DB para SQL Server para alta disponibilidade e recuperação de desastre
Aplica-se a:
SQL ServerBanco de Dados SQL do AzureInstância Gerenciada de SQL do AzureAzure Synapse AnalyticsPDW (Analytics Platform System)
Este artigo discute o suporte do Driver do OLE DB para SQL Server para Grupos de disponibilidade AlwaysOn. Para obter mais informações sobre Grupos de Disponibilidade Always On, consulte Ouvintes do Grupo de Disponibilidade, Conectividade do Cliente e Failover do Aplicativo (SQL Server), Criação e Configuração de Grupos de Disponibilidade (SQL Server), Clustering de Failover e Grupos de Disponibilidade Always On (SQL Server) e Secundárias Ativas: Réplicas Secundárias para Leitura (Grupos de Disponibilidade Always On).
Você pode especificar o ouvinte de um determinado grupo de disponibilidade na cadeia de conexão. Se um aplicativo do Driver do OLE DB para SQL Server estiver conectado com um banco de dados em um grupo de disponibilidade que executa failover, a conexão original será interrompida e o aplicativo deverá abrir uma nova conexão para continuar o trabalho após o failover.
Se você não estiver se conectando a um ouvinte do grupo de disponibilidade e se vários endereços IP forem associados com um nome de host, o Driver do OLE DB para SQL Server iterará em sequência por todos os endereços IP associados à entrada DNS. Isso pode demorar muito se o primeiro endereço IP retornado pelo servidor DNS não estiver associado a nenhuma NIC (placa de interface de rede). Ao conectar-se a um ouvinte de grupo de disponibilidade, o Driver do OLE DB para SQL Server tenta estabelecer conexões com todos os endereços IP paralelamente e, se uma conexão tentar continuar, o driver descartará qualquer tentativa de conexão pendente.
Observação
O aumento do tempo limite de conexão e a implementação de lógica de repetição de conexão aumentarão a probabilidade de um aplicativo se conectar a um grupo de disponibilidade. Além disso, como uma conexão pode falhar devido a um failover de grupo de disponibilidade, você deve implementar lógica de repetição de conexão, repetindo uma conexão com falha até se reconectar.
Conectando-se ao MultiSubnetFailover
Sempre especifique MultiSubnetFailover=Yes quando for se conectar a um ouvinte do grupo de disponibilidade Always On do SQL Server ou uma instância de cluster de failover do SQL Server. O MultiSubnetFailover permite o failover mais rápido para todos os Grupos de Disponibilidade AlwaysOn e instâncias de cluster de failover no SQL Server e reduzirá significativamente o tempo de failover para topologias Always On de uma ou várias sub-redes. Durante um failover de várias sub-redes, o cliente tentará conexões em paralelo. Durante um failover de sub-rede, o Driver do OLE DB para SQL Server tentará novamente a conexão TCP.
A propriedade de conexão MultiSubnetFailover indica que o aplicativo está sendo implantado em um grupo de disponibilidade ou instância de cluster de failover e que o Driver do OLE DB para SQL Server tentará se conectar ao banco de dados na instância primária do SQL Server tentando se conectar a todos os endereços IP do grupo de disponibilidade. Quando MultiSubnetFailover=Yes é especificado para uma conexão, o cliente repete as tentativas de conexão TCP mais rápido do que os intervalos de retransmissão TCP padrão do sistema operacional. Isso permite uma reconexão mais rápida depois de failover de um Grupos de Disponibilidade Always On ou uma Instância de Cluster de Failover e é aplicável a grupos de disponibilidade únicos e de várias sub-redes e Instâncias de Cluster de Failover.
Para saber mais sobre palavras-chave da cadeia de conexão, confira Usando palavras-chave da cadeia de conexão com o OLE DB Driver para SQL Server.
A especificação de MultiSubnetFailover=Yes durante a conexão a algo que não seja um ouvinte de grupo de disponibilidade ou uma Instância de Cluster de Failover pode resultar em um impacto de desempenho negativo e não há suporte para isso.
Use as diretrizes a seguir para conectar-se a um servidor em um grupo de disponibilidade ou Instância de Cluster de Failover:
Use a propriedade de conexão MultiSubnetFailover quando estiver se conectando a uma ou várias sub-redes; isso melhorará o desempenho em ambos os casos.
Para conectar-se a um grupo de disponibilidade, especifique o ouvinte do grupo de disponibilidade como o servidor em sua cadeia de conexão.
Conectar-se a uma instância do SQL Server configurada com mais de 64 endereços IP causará uma falha de conexão.
O comportamento de um aplicativo que usa a propriedade de conexão MultiSubnetFailover não é afetado com base no tipo de autenticação: SQL Server Autenticação, Autenticação Kerberos ou Autenticação do Windows.
Você pode aumentar o valor de loginTimeout para acomodar o tempo de failover e reduzir as tentativas de repetição de conexão do aplicativo.
Não há suporte para transações distribuídas.
Se o roteamento somente leitura não estiver em ação, conectar-se a um local de réplica secundária em um grupo de disponibilidade apresentará falha nas seguintes situações:
Se o local de réplica secundário não for configurado para aceitar conexões.
Se um aplicativo usar ApplicationIntent=ReadWrite (discutido abaixo) e o local de réplica secundária estiver configurado para acesso somente leitura.
Uma conexão falhará se uma réplica primária for configurada para rejeitar cargas de trabalho somente leitura e a cadeia de conexão contiver ApplicationIntent=ReadOnly.
Atualizando para usar clusters de várias sub-redes a partir do espelhamento de banco de dados
Um erro de conexão ocorrerá se as palavras-chave de conexão MultiSubnetFailover e Failover_Partner estiverem presentes na cadeia de conexão. Um erro também ocorrerá se a palavra-chave MultiSubnetFailover for usada e o SQL Server retornar uma resposta de parceiro de failover indicando que ela faz parte de um par de espelhamento de banco de dados.
Se você atualizar um aplicativo do OLE DB Driver para SQL Server que atualmente usa o espelhamento de banco de dados em um cenário de várias sub-redes, deverá remover a propriedade de conexão Failover_Partner e substituí-la por MultiSubnetFailover definido como Yes e substituir o nome do servidor da cadeia de conexão por um ouvinte de grupo de disponibilidade. Se uma cadeia de conexão usa Failover_Partner e MultiSubnetFailover=Yes, o driver gerará um erro. No entanto, se uma cadeia de conexão usar Failover_Partner e MultiSubnetFailover=No (ou ApplicationIntent=ReadWrite), o aplicativo usará o espelhamento de banco de dados.
O driver retornará um erro se o espelhamento de banco de dados for usado no banco de dados primário no AG e se MultiSubnetFailover=Yes for usado na cadeia de conexão que se conecta a um banco de dados primário, em vez de ao ouvinte de um grupo de disponibilidade.
Especificar a intenção do aplicativo
Você pode especificar a palavra-chave ApplicationIntent na sua cadeia de conexão. Os valores atribuíveis são ReadWrite (o padrão) ou ReadOnly.
Quando você define ApplicationIntent=ReadOnly, o cliente solicita uma carga de trabalho de leitura ao se conectar. O servidor impõe a intenção no momento da conexão e durante uma instrução do banco de dados USE.
A palavra-chave ApplicationIntent não funciona com bancos de dados herdados somente leitura.
Destinos de ReadOnly
Quando uma conexão escolhe ReadOnly, ela é atribuída a qualquer uma das configurações especiais que podem existir para o banco de dados:
Always On. Um banco de dados pode permitir ou não cargas de trabalho de leitura no banco de dados do grupo de disponibilidade de destino. Essa opção é controlada usando a cláusula
ALLOW_CONNECTIONSdas instruções do Transact-SQLPRIMARY_ROLEeSECONDARY_ROLE.
Se nenhum desses destinos especiais estiver disponível, o banco de dados regular será lido.
A palavra-chave ApplicationIntent permite o roteamento somente leitura.
Roteamento somente leitura
O roteamento somente leitura é um recurso que pode garantir a disponibilidade de uma réplica somente leitura de um banco de dados. Para habilitar o roteamento somente leitura, todos os itens a seguir se aplicam:
Você deve se conectar a um ouvinte do grupo de disponibilidade Always On.
A palavra-chave de cadeia de conexão
ApplicationIntentdeve ser definida comoReadOnly.O grupo de disponibilidade deve ser configurado pelo administrador de banco de dados para permitir o roteamento somente leitura.
Várias conexões que usam roteamento somente leitura podem se conectar à mesma réplica somente leitura. Alterações na sincronização de banco de dados ou alterações na configuração de roteamento de servidor podem resultar em conexões de cliente com réplicas somente leitura diferentes.
Você pode garantir que todas as solicitações somente leitura conectem-se à mesma réplica somente leitura, não transmitindo um ouvinte de grupo de disponibilidade à palavra-chave de cadeia de conexão Server. Em vez disso, especifique o nome da instância somente leitura.
O roteamento somente leitura pode levar mais tempo do que se conectar ao principal. Isso é porque o roteamento somente leitura se conecta primeiro à instância primária e, em seguida, procura a melhor instância secundária legível disponível. Devido a essas várias etapas, você deve aumentar seu tempo limite do login para no mínimo 30 segundos.
OLE DB
O Driver do OLE DB para SQL Server dá suporte às palavras-chave ApplicationIntent e MultiSubnetFailover.
As duas palavras-chave do OLE DB da cadeia de conexão foram adicionadas para dar suporte a Grupos de disponibilidade AlwaysOn no Driver do OLE DB para SQL Server:
- ApplicationIntent
- MultiSubnetFailover
Para saber mais sobre palavras-chave da cadeia de conexão no OLE DB Driver para SQL Server, confira Usando palavras-chave da cadeia de conexão com o OLE DB Driver para SQL Server.
Tentativa de aplicativo
As propriedades de conexão equivalentes são:
SSPROP_INIT_APPLICATIONINTENT
DBPROP_INIT_PROVIDERSTRING
Um aplicativo do Driver do OLE DB para SQL Server pode usar um dos métodos para especificar uma intenção de aplicativo:
IDBInitialize::Initialize
IDBInitialize::Initialize usa o conjunto previamente configurado de propriedades para inicializar a fonte de dados e criar o objeto de fonte de dados. Especifique a tentativa de aplicativo como uma propriedade de provedor ou como parte da cadeia de caracteres de propriedades estendidas.IDataInitialize::GetDataSource
IDataInitialize::GetDataSource usa uma cadeia de conexão de entrada que pode conter a palavra-chave Application Intent.IDBProperties::SetProperties
Para definir o valor da propriedade ApplicationIntent, chame IDBProperties::SetProperties passando a propriedade SSPROP_INIT_APPLICATIONINTENT com o valor da propriedade "ReadWrite" ou "ReadOnly" ou DBPROP_INIT_PROVIDERSTRING com o valor contendo "ApplicationIntent=ReadOnly" ou "ApplicationIntent=ReadWrite".
Você pode especificar a tentativa de aplicativo no campo Propriedades de Tentativa de Aplicativo da guia Tudo na caixa de diálogo Propriedades de Vínculo de Dados.
Quando forem estabelecidas conexões implícitas, a conexão implícita usará a configuração de tentativa de aplicativo da conexão pai. Da mesma forma, várias sessões criadas a partir da mesma fonte de dados herdarão a configuração de tentativa de aplicativo da fonte de dados.
MultiSubnetFailover
As propriedades de conexão equivalentes são:
SSPROP_INIT_MULTISUBNETFAILOVER
DBPROP_INIT_PROVIDERSTRING
Um aplicativo do Driver do OLE DB para SQL Server pode usar um dos seguintes métodos para definir a opção MultiSubnetFailover:
IDBInitialize::Initialize
IDBInitialize::Initialize usa o conjunto previamente configurado de propriedades para inicializar a fonte de dados e criar o objeto de fonte de dados. Especifique a tentativa de aplicativo como uma propriedade de provedor ou como parte da cadeia de caracteres de propriedades estendidas.IDataInitialize::GetDataSource
IDataInitialize::GetDataSource usa uma cadeia de conexão de entrada que pode conter a palavra-chave MultiSubnetFailover.IDBProperties::SetProperties
Para definir o valor da propriedade MultiSubnetFailover, chame IDBProperties::SetProperties passando a propriedade SSPROP_INIT_MULTISUBNETFAILOVER com o valor VARIANT_TRUE ou VARIANT_FALSE ou a propriedade DBPROP_INIT_PROVIDERSTRING com um valor contendo "MultiSubnetFailover=Yes" ou "MultiSubnetFailover=No".
Exemplo
DBPROP rgPropMultisubnet;
rgPropMultisubnet.dwPropertyID = SSPROP_INIT_MULTISUBNETFAILOVER;
rgPropMultisubnet.dwOptions = DBPROPOPTIONS_REQUIRED;
rgPropMultisubnet.dwStatus = DBPROPSTATUS_OK;
rgPropMultisubnet.colid = DB_NULLID;
V_VT(&(rgPropMultisubnet.vValue)) = VT_BOOL;
V_BOOL(&(rgPropMultisubnet.vValue)) = VARIANT_TRUE;
DBPROPSET PropSet;
PropSet.rgProperties = &rgPropMultisubnet;
PropSet.cProperties = 1;
PropSet.guidPropertySet = DBPROPSET_SQLSERVERDBINIT;
IDBProperties* pIDBProperties = NULL;
hr = pIDBInitialize->QueryInterface(IID_IDBProperties, (void **)&pIDBProperties);
pIDBProperties->SetProperties(1, &PropSet);
Consulte Também
Recursos do Driver do OLE DB para SQL Server
Uso de palavras-chave de cadeia de conexão com o Driver do OLE DB para SQL Server
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários