Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a:SQL Server
Base de Dados SQL do Azure
Azure SQL Managed Instance
Azure Synapse Analytics
Sistema de Plataforma de Análise (PDW)
Base de dados SQL no Microsoft Fabric
Este artigo discute o suporte do Driver OLE DB para SQL Server para grupos de disponibilidade Always On. Para mais informações sobre grupos de disponibilidade Always On, consulte Availability Group Listeners, Connectivity do Cliente e Failover de Aplicações (SQL Server),Criação e Configuração de Grupos de Disponibilidade (SQL Server),Clustering por Failover e Grupos de Disponibilidade Sempre Ligados (SQL Server), e Ativos Secundários: Réplicas Secundárias Legíveis (Always On Availability Groups).
Pode especificar o ouvinte do grupo de disponibilidade de um dado grupo de disponibilidade na cadeia de conexão. Se um Driver OLE DB para aplicação SQL Server estiver ligado a uma base de dados num grupo de disponibilidade que faz failover, a ligação original é interrompida e a aplicação tem de abrir uma nova ligação para continuar o trabalho após o failover.
Se não estiver a ligar-se a um ouvinte de grupo de disponibilidade, e se vários endereços IP estiverem associados a um nome de host, o OLE DB Driver para SQL Server irá iterar sequencialmente por todos os endereços IP associados à entrada DNS. Isto pode ser demorado se o primeiro endereço IP devolvido pelo servidor DNS não estiver ligado a nenhuma placa de interface de rede (NIC). Ao ligar-se a um ouvinte de grupo de disponibilidade, o OLE DB Driver para SQL Server tenta estabelecer ligações a todos os endereços IP em paralelo e, se uma tentativa de ligação for bem-sucedida, o driver descarta quaisquer tentativas de ligação pendentes.
Observação
Aumentar o tempo de espera da ligação e implementar lógica de retentativa de ligação aumentará a probabilidade de uma aplicação se ligar a um grupo de disponibilidade. Além disso, como uma ligação pode falhar devido a um failover de grupo de disponibilidade, deve implementar lógica de retentativa de ligação, tentando novamente uma ligação falhada até que esta se reconecte.
Ligação com MultiSubnetFailover
Especifique sempre MultiSubnetFailover=Sim quando o destino for Base de Dados SQL do Azure, Azure SQL Managed Instance, base de dados SQL 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 ligação resolve para mais do que um endereço IP, o MultiSubnetFailover=Yes diz ao OLE DB Driver for SQL Driver for SQL Server para abrir ligações a todos esses endereços ao mesmo tempo e usar o primeiro que responder. Sem ela, o condutor tenta os endereços um de cada vez. Um endereço que não responde bloqueia até que o timeout TCP do sistema operativo expire, o que pode esgotar o timeout da ligação antes do driver chegar a um endereço que atende. Após um failover, o endereço que o driver tenta primeiro pode ser aquele que já não serve a base de dados, pelo que uma ligação que teria sucesso contra outro endereço falha com um timeout em vez disso.
MultiSubnetFailover=Sim altera a rapidez com que o cliente encontra a réplica que serve a base de dados. Isso não altera o tempo que o servidor demora a fazer failover.
MultiSubnetFailover=Sim é seguro em alvos de IP único. Quando o DNS resolve para um único endereço, o driver faz uma única tentativa de ligação, por isso a definição não custa nada quando não é necessária.
Para mais informações sobre palavras-chave de cadeia de ligação, consulte Utilização de Palavras-chave de Stringas de Ligação com o Driver OLE DB para SQL Server.
Use as seguintes diretrizes para se ligar a um servidor num grupo de disponibilidade ou numa Instância de Cluster de Failover:
Defina a propriedade de ligação MultiSubnetFailover para Sim.
Para se ligar a um grupo de disponibilidade, especifique o ouvinte do grupo de disponibilidade do grupo de disponibilidade como o servidor na sua cadeia de ligação.
Não podes usar MultiSubnetFailover sobre um protocolo que não seja TCP.
A ligação a uma instância do SQL Server configurada com mais de 64 endereços IP causa uma falha de ligação.
Não podes usar MultiSubnetFailover com espelhamento de base de dados. O driver devolve um erro quando o servidor informa que a base de dados está espelhada. O espelhamento de bases de dados está obsoleto em todas as versões suportadas do SQL Server. Em vez disso, use os grupos de disponibilidade Always On.
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 ligação MultiSubnetFailover.
Pode aumentar o valor do Connect Timeout para acomodar o tempo de failover e reduzir as tentativas de ligação à aplicação. O padrão é 15 segundos. A mesma definição chama-se Timeout quando a defines em
IDBInitialize::Initialize, e é mapeada para aDBPROP_INIT_TIMEOUTpropriedade. Para Base de Dados SQL do Azure serverless com autopausa ativada, use um Connect Timeout de pelo menos 60 segundos. Uma base de dados em pausa automática recomeça na primeira tentativa de ligação, e essa tentativa pode falhar com o erro 40613 enquanto a base de dados recomeça, pelo que a aplicação tem de tentar novamente. Para mais informações, veja Pausa automática e retomada automática.Transações distribuídas não são suportadas.
Se o encaminhamento apenas de leitura não estiver em vigor, a ligação a uma localização secundária de réplica num grupo de disponibilidade falha nas seguintes situações:
- Se a localização da réplica secundária não estiver configurada para aceitar ligações.
- Se uma aplicação usar ApplicationIntent=ReadWrite e a localização da réplica secundária estiver configurada para acesso apenas de leitura.
Uma ligação falha se uma réplica primária estiver configurada para rejeitar cargas de trabalho apenas de leitura e a cadeia de ligação contiver ApplicationIntent=ReadOnly.
Atualização a partir do espelhamento de bases de dados
Ocorre um erro de ligação se o cadeia de ligação contiver tanto as palavras-chave MultiSubnetFailover como Failover_Partner. Também ocorre um erro se usar MultiSubnetFailover e o SQL Server devolver uma resposta do parceiro de failover, indicando que faz parte de um par de espelhamento de base de dados.
Se atualizar uma aplicação OLE DB Driver for SQL Server que atualmente usa espelhamento de base de dados para um cenário multi-sub-rede, remova a propriedade de ligação Failover_Partner e substitua-a por MultiSubnetFailover definido para Sim. Substitua o nome do servidor na cadeia de ligação por um ouvinte de grupo de disponibilidade. Se um cadeia de ligação usar Failover_Partner e MultiSubnetFailover=Sim, o driver gera um erro. No entanto, se um cadeia de ligação usar Failover_Partner e MultiSubnetFailover=Não (ou ApplicationIntent=ReadWrite), a aplicação utiliza espelhamento de base de dados.
O driver devolve um erro se usar espelhamento de base de dados na réplica primária do grupo de disponibilidade, e se usar MultiSubnetFailover=Yes na cadeia de ligação que se liga a uma réplica primária em vez de a um ouvinte de grupo de disponibilidade.
Definir MultiSubnetFailover programaticamente
As propriedades equivalentes de ligação são:
- SSPROP_INIT_MULTISUBNETFAILOVER
- DBPROP_INIT_PROVIDERSTRING
Uma aplicação do OLE DB Driver for SQL Server pode usar um dos seguintes métodos para definir a opção MultiSubnetFailover:
-
IDBInitialize::Inicialize
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 fornecedor ou como parte da cadeia de propriedades estendidas. -
IDataInitialize::GetDataSource
Aceita uma cadeia de ligaçã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.
Example
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);
Especifique a intenção da aplicação
Podes especificar a palavra-chave ApplicationIntent na tua cadeia de ligação. Os valores atribuíveis são ReadWrite (o padrão) ou ReadOnly.
Quando defines ApplicationIntent=ReadOnly, o cliente solicita uma carga de trabalho de leitura ao ligar. O servidor faz cumprir a intenção no momento da ligação e durante uma USE instrução da base de dados.
A ApplicationIntent palavra-chave não funciona com bases de dados legadas de apenas leitura.
Alvos do ReadOnly
Quando uma ligação escolhe ReadOnly, a ligação é atribuída a qualquer uma das seguintes configurações especiais que possam existir para a base de dados:
Sempre ligado. Uma base de dados pode permitir ou não a leitura de cargas de trabalho na base de dados do grupo de disponibilidade alvo. Esta escolha é controlada usando a
ALLOW_CONNECTIONScláusula dasPRIMARY_ROLEinstruções eSECONDARY_ROLETransact-SQL.
Se nenhum desses alvos especiais estiver disponível, a base de dados regular é consultada.
A ApplicationIntent palavra-chave permite o encaminhamento apenas de leitura.
Encaminhamento de apenas leitura
O encaminhamento apenas de leitura é uma funcionalidade que pode garantir a disponibilidade de uma réplica somente de leitura de uma base de dados. Para permitir o encaminhamento apenas de leitura, aplicam-se todas as seguintes condições:
Deve ligar-se a um ouvinte do grupo de disponibilidade Always On.
A
ApplicationIntentpalavra-chave da cadeia de ligação deve ser definida paraReadOnly.O administrador da base de dados deve configurar o grupo de disponibilidade para permitir o encaminhamento apenas de leitura.
Várias ligações que usam roteamento apenas de leitura podem não se ligar todas à mesma réplica de apenas leitura. Alterações na sincronização da base de dados ou alterações na configuração de encaminhamento do servidor podem resultar em ligações do cliente a diferentes réplicas somente de leitura.
Pode garantir que todos os pedidos apenas de leitura se ligam à mesma réplica de somente leitura ao não passar um ouvinte de grupo de disponibilidade para a Server palavra-chave da cadeia de ligação. Em vez disso, especifique o nome da instância de apenas leitura.
O encaminhamento só de leitura pode demorar mais do que ligar ao primário. Isto acontece porque o encaminhamento apenas de leitura liga-se primeiro ao primário e depois procura o melhor secundário legível disponível. Devido a estes múltiplos passos, deve aumentar o seu login tempo para pelo menos 30 segundos.
Intenção do aplicativo
O OLE DB Driver for SQL Server suporta a palavra-chave de cadeia de ligação ApplicationIntent. Para mais informações sobre palavras-chave de cadeia de ligação, consulte Utilização de Palavras-chave de Stringas de Ligação com o Driver OLE DB para SQL Server.
Definir o ApplicationIntent programaticamente
As propriedades equivalentes de ligação são:
- SSPROP_INIT_APPLICATIONINTENT
- DBPROP_INIT_PROVIDERSTRING
Uma aplicação do OLE DB Driver for SQL Server pode usar um dos seguintes métodos para especificar a intenção da aplicação:
-
IDBInitialize::Inicialize
Utiliza o conjunto de propriedades previamente configurado para inicializar a fonte de dados e criar o objeto fonte de dados. Especifique a intenção da aplicação como propriedade do fornecedor ou como parte da cadeia de propriedades estendidas. -
IDataInitialize::GetDataSource
Aceita uma cadeia de ligaçã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 ReadWrite ou ReadOnly, ou a propriedade DBPROP_INIT_PROVIDERSTRING com o valor contendo ApplicationIntent=ReadOnly ou ApplicationIntent=ReadWrite.
Pode especificar a intenção de aplicação no campo Propriedades de Intenção de Aplicação do separador Todos na caixa de diálogo Propriedades do Enlace de Dados .
Quando estabeleces ligações implícitas, a ligação implícita usa a definição de intenção de aplicação da ligação principal. De forma semelhante, múltiplas sessões criadas a partir da mesma fonte de dados herdam a definição de intenção de aplicação da fonte.