Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se a:SQL Server
Banco de Dados SQL do Azure
Instância Gerenciada de SQL do Azure
Azure Synapse Analytics
Sistema de Plataforma de Análise (PDW)
Banco de dados SQL no Microsoft Fabric
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 com MultiSubnetFailover
Sempre especifique MultiSubnetFailover=Sim quando o destino for Banco de Dados SQL do Azure, Instância Gerenciada de SQL do Azure, SQL Database no Microsoft Fabric, um ouvinte de grupo de disponibilidade Always On ou uma Instância de Cluster de Failover do SQL Server.
Quando o nome do servidor na sua cadeia de conexão resolve para mais de um endereço IP, MultiSubnetFailover=Yes diz ao OLE DB Driver for SQL Driver para abrir conexões para todos esses endereços ao mesmo tempo e usar o primeiro que responder. Sem ele, o motorista tenta os endereços um de cada vez. Um endereço que não responde fica parado até que o timeout TCP do sistema operacional expire, o que pode esgotar o timeout antes que o driver chegue a um endereço que atende. Após um failover, o endereço que o driver tenta primeiro pode ser aquele que não atende mais ao banco de dados, então uma conexão que teria sucesso contra outro endereço falha com um timeout.
MultiSubnetFailover=Sim muda a rapidez com que o cliente encontra a réplica que atende ao banco de dados. Isso não muda o tempo que o servidor leva para fazer failover.
MultiSubnetFailover=Sim é seguro em alvos de IP único. Quando o DNS se resolve para um único endereço, o driver faz uma única tentativa de conexão, então a configuração não custa nada quando não é necessária.
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.
Use as diretrizes a seguir para conectar-se a um servidor em um grupo de disponibilidade ou Instância de Cluster de Failover:
Defina a propriedade de conexão MultiSubnetFailover para Sim.
Para conectar-se a um grupo de disponibilidade, especifique o ouvinte do grupo de disponibilidade como o servidor em sua cadeia de conexão.
Você não pode usar MultiSubnetFailover sobre um protocolo que não seja TCP.
Conectar a uma instância do SQL Server configurada com mais de 64 endereços IP causa uma falha de conexão.
Você não pode usar MultiSubnetFailover com espelhamento de banco de dados. O driver retorna um erro quando o servidor informa que o banco de dados está espelhado. O espelhamento de banco de dados está obsoleto em todas as versões suportadas do SQL Server. Use Grupos de disponibilidade AlwaysOn em vez disso.
O tipo de autenticação, Autenticação SQL Server, Autenticação Kerberos ou Autenticação Windows, não afeta o comportamento de uma aplicação que utiliza a propriedade de conexão MultiSubnetFailover.
Você pode aumentar o valor do Tempo de Conexão para acomodar o tempo de failover e reduzir as tentativas de retentativa de conexão com a aplicação. O padrão é 15 segundos. A mesma configuração é chamada de Timeout quando você a configura em
IDBInitialize::Initialize, e ela mapeia para aDBPROP_INIT_TIMEOUTpropriedade. Para Banco de Dados SQL do Azure serverless com autopausa ativada, use um Tempo de Conexão de pelo menos 60 segundos. Um banco de dados pausado automaticamente é retomado na primeira tentativa de conexão, e essa tentativa pode falhar com o erro 40613 enquanto o banco de dados recomeça, então a aplicação deve tentar novamente. Para mais informações, consulte Pausa automática e retomada automática.Não há suporte para transações distribuídas.
Se o roteamento somente de leitura não estiver em vigor, a conexão com uma réplica secundária de um grupo de disponibilidade falhará nas seguintes situações:
- Se o local de réplica secundário não for configurado para aceitar conexões.
- Se uma aplicação usar ApplicationIntent=ReadWrite e a localização da réplica secundária estiver configurada para acesso somente leitura.
Uma conexão falha se uma réplica primária estiver configurada para rejeitar cargas de trabalho somente leitura e a cadeia de conexão contiver ApplicationIntent=ReadOnly.
Atualização do espelhamento de banco de dados
Um erro de conexão ocorre se o cadeia de conexão contiver tanto as palavras-chave MultiSubnetFailover quanto Failover_Partner. Um erro também ocorre se você usar MultiSubnetFailover e o SQL Server retornar uma resposta do parceiro de failover indicando que faz parte de um par de espelhamento de banco de dados.
Se você atualizar um aplicativo Driver do OLE DB para SQL Server que atualmente usa espelhamento de banco de dados para um cenário multi-sub-redes, remova a propriedade de conexão Failover_Partner e substitua-a por MultiSubnetFailover configurado para Sim. Substitua o nome do servidor na cadeia de conexão por um ouvinte do grupo de disponibilidade. Se um cadeia de conexão usar Failover_Partner e MultiSubnetFailover=Sim, o driver gera um erro. No entanto, se um cadeia de conexão usa Failover_Partner e MultiSubnetFailover=Não (ou ApplicationIntent=ReadWrite), a aplicação utiliza espelhamento de banco de dados.
O driver retorna um erro se você usar espelhamento de banco de dados na réplica primária do grupo de disponibilidade, e se você usar MultiSubnetFailover=Yes na cadeia de conexão que se conecta a uma réplica primária em vez de a um ouvinte de grupo de disponibilidade.
Definir MultiSubnetFailover programaticamente
As propriedades de conexão equivalentes são:
- SSPROP_INIT_MULTISUBNETFAILOVER
- DBPROP_INIT_PROVIDERSTRING
Um OLE DB Driver for SQL Driver for SQL Server pode usar um dos seguintes métodos para definir a opção MultiSubnetFailover:
-
IDBInitialize::Initialize
Utiliza o conjunto de propriedades previamente configurado para inicializar a fonte de dados e criar o objeto fonte de dados. Especifique MultiSubnetFailover como propriedade do provedor ou como parte da cadeia de propriedades estendidas. -
IDataInitialize::GetDataSource
Recebe 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 valor VARIANT_TRUE ou VARIANT_FALSE, ou a propriedade DBPROP_INIT_PROVIDERSTRING com valor contendo MultiSubnetFailover=Sim ou MultiSubnetFailover=Não.
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);
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:
Sempre ligado. 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.
ApplicationIntent
O Driver do OLE DB para SQL Server suporta a palavra-chave de cadeia de conexão ApplicationIntent. 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.
Definir o ApplicationIntent programaticamente
As propriedades de conexão equivalentes são:
- SSPROP_INIT_APPLICATIONINTENT
- DBPROP_INIT_PROVIDERSTRING
Um Driver do OLE DB para SQL Server pode usar um dos seguintes métodos para especificar a intenção da aplicação:
-
IDBInitialize::Initialize
Utiliza o conjunto de propriedades previamente configurado para inicializar a fonte de dados e criar o objeto 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
Recebe 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 valor ReadWrite ou ReadOnly, ou a propriedade DBPROP_INIT_PROVIDERSTRING com valor contendo ApplicationIntent=ReadOnly ou ApplicationIntent=ReadWrite.
Você pode especificar a intenção da aplicação no campo Propriedades da Intenção da Aplicação da aba Todos na caixa de diálogo Propriedades do Enlace de Dados .
Quando você estabelece conexões implícitas, a conexão implícita usa a configuração de intenção de aplicação da conexão pai. Da mesma forma, múltiplas sessões criadas a partir da mesma fonte de dados herdam a configuração de intenção da aplicação da fonte.