Analisando a documentação da Microsoft para aplicar um patch SQL em um AG .
é feita referência à redução/minimização do tempo de inatividade e perda de dados e não à prevenção total do tempo de inatividade. Posso esperar conseguir aplicar um patch sem nenhum tempo de inatividade?
Por favor, eu apreciaria sua opinião.
Obrigado
Eu gostaria de receber alguns conselhos, por favor.
Preciso corrigir um ambiente do SQL 2019 Availability Group com duas réplicas locais.
Alto nível de medidas que pretendo tomar:
É realmente essencial alterar o modo de confirmação síncrono para assíncrono no primário antes de começar?
Minha preocupação em fazer isso é que a instância em questão tem mais de 300 bancos de dados, alguns dos quais são muito grandes. Se eu alterar o modo de disponibilidade para assíncrono, quando eu terminar de aplicar patches no secundário e fizer failover do AG para o secundário corrigido, precisarei retomar a movimentação de dados no novo secundário (ou seja, o antigo primário) em cada banco de dados . Para uma instância com mais de 300 bancos de dados, esse é um processo demorado.
A minha pergunta é, portanto:
Além disso, se por qualquer motivo eu não conseguir garantir o tempo de inatividade para a tarefa, e o primário estiver em uso enquanto o secundário estiver sendo corrigido. Correrei o risco de perda de dados se deixar o modo de disponibilidade como síncrono durante o processo de correção?
Por favor, informe-nos.
obrigado.
Três perguntas, por favor:
Podemos ter um único DAG em 3 clusters WSFC, ou seja, abrangendo 3 AGs?
Em caso afirmativo, é possível configurá-lo de forma que dois AGs estejam no mesmo domínio do Active Directory enquanto um terceiro esteja em um domínio AD diferente?
Se não for recomendado configurar um único DAG em três AGs, é possível configurar um entre dois AGs em dois domínios AD diferentes?
Obrigado
Eu apreciaria alguns conselhos, por favor? Tivemos uma situação em que o log do TEMPDB estava cheio e não conseguimos nos conectar à réplica primária do nosso SQL 2019 AG do SSMS. No entanto, conseguimos nos conectar à réplica secundária, onde iniciamos um failover do primário para o secundário. O failover reverteu as transações em andamento no tempdb primário e, portanto, qualquer transação que causou o preenchimento do log foi revertida e o log foi liberado. Conseguimos então nos conectar a essa réplica e fazer um failback como principal.
Minha pergunta é: uma reinicialização dos serviços SQL em cada nó do servidor seria benéfica para evitar o preenchimento do templog novamente - ou seja, para recriar tempdbs vazios e limpos?
Estou tentando criar várias instâncias SQL, cada uma com seu próprio AG (e ouvinte) em 2 clusters do Windows em um AG distribuído da seguinte maneira:
Dois sites - Primário e DR
Cada site possui uma configuração WSFC - PrimCluster e DRCluster.
PrimCluster tem dois nós - PrimNodeA e PrimNodeB
DRCluster tem dois nós - DRNodeA e DRNodeB
Cada nó possui duas réplicas SQL AG, cada uma com um AG (com seu próprio ouvinte), como segue:
em PrimNodeA e B - Instance1_P_AG
em PrimNodeA e B - Instance2_P_AG
em DRNodeA e B - Instância1_DR_AG
em DRNodeA e B - Instance2_DR_AG
Configuração DAG assíncrona entre os dois clusters.
Cada AG local está no modo de disponibilidade síncrona e mantém seus próprios bancos de dados de AG.
todos os secundários são ilegíveis
Esta é minha primeira experiência com múltiplas instâncias SQL em um cluster, cada uma configurada com AG e DAG entre os dois clusters.
Minha pergunta, por favor:
Em outras palavras, preciso de vários DAGs ou apenas um entre Instance1_P_AG e Instance1_DR_AG cobrirá todas as instâncias em cada cluster?
Além disso, eu apreciaria um link para um artigo sobre múltiplas instâncias SQL em um DAG.
Obrigado
Existe uma maneira rápida de encontrar instâncias do SQL Server em todo o nosso SQL Estate, que contenham bancos de dados inteiros criptografados (SQL TDE) ou colunas de tabelas de banco de dados?
Obrigado
Estou usando o SQL 2019, o SSISDB está instalado. Meu cliente cria um pacote SSIS usando o assistente de importação/exportação para importar um arquivo Excel, e isso só foi bem-sucedido depois que tive que instalar a versão de 32 bits do Microsoft Access Database Engine 2016 Redistributable.
No entanto, quando ele tenta executar o pacote a partir de um trabalho do SQL Agent, ele recebe a seguinte mensagem:
"...Descrição: O provedor OLE DB solicitado Microsoft.ACE.OLEDB.16.0 não está registrado. Se o driver de 64 bits não estiver instalado, execute o pacote no modo de 32 bits...."
Devo instalar também a versão de 64 bits no mesmo servidor em que já instalei a versão de 32 bits? Não consigo encontrar uma opção no SSMS para configurar o trabalho para ser executado com a opção de 32 bits.
Por favor, informe por favor.
obrigado
Por favor, há algum benefício em instalar SSIS, SSAS e SSRS em um servidor separado da instância do SQL Engine?
Além das implicações adicionais da licença, há outras considerações para a decisão?
Eu apreciaria links para quaisquer artigos de pesquisa úteis sobre isso, por favor.
obrigado
Alguém sabe por que a porta em que meu SQL Server está escutando não seria registrada no meu log de erros? O TCP/IP está ativado e a porta de escuta padrão 1433 está configurada.
Estou com esse problema em dois servidores:
A porta 1433 está aberta em ambas as máquinas host - netstat -na
Espero ver uma entrada para a porta de escuta no meu log de erros, alguém saberia por que ela pode estar faltando?
obrigado
Eu tenho o SQL 2019 Enterprise Edition corrigido para CU18 instalado em um cluster Windows 2022 de 2 nós e configurado com um Grupo de Disponibilidade. Tenho investigado um comportamento incomum e persistente dos nós do cluster quando um nó Primário é reinicializado.
O comportamento é que quando um nó Primário é reinicializado, como esperado, ocorre um failover automático para a réplica secundária anterior (confirmação síncrona), no entanto, os serviços SQL no nó reinicializado demoram entre 10 a 30 minutos para iniciar. O serviço do mecanismo no Configuration Manager permanece no estado 'Alteração pendente' durante esse atraso e, quando finalmente é iniciado, o agente deve ser iniciado manualmente.
Durante o atraso, não há log de erros produzido, nenhum processo do SQL Server no Gerenciador de Tarefas, nenhum log relacionado no Visualizador de Eventos.
Pesquisei bastante na internet mas ainda não encontrei nada que me ajudasse. Atualmente, estou usando o Process Monitor para monitorar o que acontece durante o atraso. Descobri que nenhum processo sqlservr é capturado pelo Procmon até que o serviço do mecanismo sql seja iniciado. No entanto, também descobri que a maioria dos processos sql capturados durante esse atraso são processos sqlceip com vários resultados. Alguns resultados são 'NAME NOT FOUND' (Operação = RegOpenKey e Path é fornecido) ou 'PATH NOT FOUND' (Operation = Create File), ou 'BUFFER OVERFLOW' (Operation = RegQueryValue) etc. Eu também capturei os processos SQL antes de reiniciar o nó e todos os resultados do sqlceip foram 'SUCESSO'
Então, meu palpite é que durante o período de atraso, o sqlceip está tentando fazer algumas coisas e não um coelho feliz devido a alguns motivos, causando o atraso. Agora, como não sei bem como lidar com esses resultados e porque já vi o SQL Telemetry (sqlceip) causar um problema em um SQL FCI antes, estou pensando em removê-lo completamente. Tentei desativá-lo em Relatório de erros e uso em programas iniciais, mas ainda tenho os processos no Procmon.
Agradeço qualquer sugestão útil sobre como investigar/corrigir esse problema, por favor. Como eu disse, estou pensando em remover/diabilizar o sqlceip completamente se eu souber como fazer isso.
Obrigado
Eu apreciaria alguns conselhos, por favor.
Configurei a propagação automática para meu SQL 2019 Availability Group. Meus dois nós de cluster têm, cada um, 8 GB de RAM e 4 processadores. Os bancos de dados menores na instância são adicionados com êxito ao AG sem problemas. No entanto, um banco de dados de 30 GB continua exibindo um aviso sobre espaço livre em disco insuficiente para dados e arquivos de log quando tento adicioná-lo ao AG. O armazenamento de arquivos de dados tem cerca de 70 GB livres e o armazenamento de logs cerca de 74 GB livres.
Eu ignoro a mensagem e continuo adicionando o banco de dados ao AG e obtive comportamentos diferentes da seguinte forma:
Às vezes, parece ter sido adicionado com sucesso ao AG, pois o painel do SSMS mostra o AG como íntegro. No entanto, o DMV sys.dm_server_hadr_automatic_seeding mostra o status de propagação em um nó às vezes como CONCLUÍDO (failure_state_desc = NULL) enquanto o outro nó FAILED (failure_state_desc = Verifique se a propagação é necessária). Às vezes, ambos os nós como FAILED.
Algumas vezes eu tive um errorlog de despejo SQL
Em uma ocasião, parecia bem-sucedido, mas não consegui atualizar a conexão do nó secundário no SSMS e recebi um errorlog de despejo SQL
Em todas as ocasiões, descobri que a utilização de memória no Gerenciador de tarefas atinge mais de 4 GB. Minha memória máxima configurada do SQL Server é de cerca de 5 GB.
Observe que o sistema legado para esta nova implantação não usa tecnologia AG e usa tamanhos muito menores de espaço em disco para dados e arquivos de log e é executado com êxito em sua versão mais antiga do SQL.
Minhas perguntas por favor:
Eu fiz algumas pesquisas sobre o assunto, mas apreciaria alguns conselhos, se alguém puder fornecer alguns.
obrigado
O armazenamento físico subjacente em meus bancos de dados do SQL Server 2019 Availability Group precisa ser alterado em um dos nós do meu cluster.
O nome da unidade e o caminho do arquivo permanecem os mesmos para os arquivos do banco de dados, nada mais mudando.
Existe alguma coisa que eu preciso ter cuidado, sendo uma réplica do AG em um cluster do Windows?
Meu plano é:
Eu perdi alguma coisa que eu deveria estar ciente?
Além do Availability Group Listener, há algum outro objeto de ouvinte do SQL Server que esteja configurado e esteja no Active Directory?
O ponto de extremidade de comunicação (que escuta na porta 5022) precisa ser conectado à conta de serviço SQL e isso está no SQL. Que outra configuração de "ouvinte" deveria haver?
Obrigado
Alguém pode gentilmente me explicar isso por favor. Meu entendimento é que não podemos executar backups diferenciais na réplica secundária de um AG, portanto, se os requisitos de negócios exigirem backups diferenciais, não podemos escolher nossa preferência de backup como secundária.
No entanto, o sistema legado para o sistema em que estou trabalhando executa backups diferenciais nos bancos de dados AG e a preferência de backup é definida como 'Preferir secundário'. A versão do SQL no sistema legado é o SQL 2016 SP3 e a nova em que estou trabalhando é o SQL 2019.
Obrigado
Ao tentar associar um banco de dados a um AG na réplica secundária, recebo o erro:
A cópia remota do banco de dados "ABC" não foi transferida para um ponto no tempo incluído na cópia local do log do banco de dados. (Microsoft SQL Server, erro: 1412)
Procurei esse erro e segui a "correção" para restaurar backups completos e t-log sem modo de recuperação na réplica secundária, mas ainda recebo o erro.
É uma instalação do SQL 2019 com serviços SQL em execução com a mesma conta de serviço gerenciado de grupo em ambas as réplicas. No entanto, estou tentando adicionar o banco de dados de teste ao AG conectado como minha conta do Windows, que possui privilégios de administrador de sistema. Isso pode ser a causa do problema? Preciso fazer login no SQL como gmsa para poder adicionar bancos de dados ao AG? Mas a autenticação não é de modo misto, é do Windows.
Agradeço alguma orientação sobre isso, por favor.
Obrigado
Eu preciso de ajuda, por favor.
Eu tenho um cluster do Windows de 2 nós configurado com WSFC (nome do cluster = ABCCluster ). Nó 1 chamado Nó1 Nó 2 chamado Nó2
Instância do SQL 2019 instalada e denominada INSTANCE Availability Group configurada e denominada INSTANCE_AG Availability Group listener pré-configurada e denominada AGL_INSTANCE
No Failover Cluster Manager, Cluster Events, recebo o seguinte erro:
Falha no registro do recurso de nome de rede de cluster de um ou mais nomes DNS associados porque o acesso para atualizar a zona DNS segura foi negado. Nome da rede do cluster: ' INSTANCE_AG_AGL_INSTANCE ' Zona DNS: 'our.domain.com' Certifique-se de que o objeto de nome do cluster (CNO) tenha permissão para a zona DNS segura
Pergunta 1: De onde vem esse estranho nome de cluster, ou seja, ' INSTANCE_AG_AGL_INSTANCE '? O nome do cluster no Failover Cluster Manager é ABCCluster
Pergunta 2: O nome do ouvinte pré-configurado foi anexado a esse estranho nome de cluster. A pré-configuração do ouvinte tem algo a ver com esta mensagem de erro?
Pergunta 3: Como está agora, o failover automático para o AG aconteceu da réplica do Nó1 para a réplica do Nó2 quando interrompi o serviço SQL no Nó1 (que anteriormente era a réplica primária no AG). No entanto, quando paro o serviço no Nó2, ele não retorna automaticamente ao Nó1. Em vez disso, o Nó1 permanece no estado 'RESOLVING' por algum tempo até que o serviço SQL seja iniciado novamente no Nó2 e, em seguida, a réplica do Nó1 seja resolvida como 'secundária'. Portanto, tenho apenas um failover automático unidirecional.
Eu apreciaria todas as idéias sobre o que estou fazendo de errado, por favor.
Obrigado
Estou tentando resolver algum mistério em dois dos meus ambientes. Ambas são implantações do SQL 2019, porém uma possui o Kerberos configurado (ou seja, os SPNs são registrados para a instância e a porta), enquanto a outra não. Eu tenho tentado investigar como isso aconteceu, mas ainda não cheguei ao fundo disso.
Basicamente, gostaria de entender o requisito para implantações futuras. Devo criar manualmente (ou solicitar a criação) dos SPNs ou há alguma maneira de criá-los automaticamente? Por exemplo, eles poderiam ter sido criados durante a construção da camada do aplicativo?
Eu apreciaria se alguém é capaz de lançar alguma luz sobre isso para mim, por favor. É claro que tenho pesquisado tudo sobre autenticação Kerberos e SPNs, mas se houver algum artigo específico sobre essa questão específica, gostaria de um link para ele, por favor.
Obrigado
Por favor, alguém pode me ajudar com um link para onde baixar uma cópia .bak do banco de dados Stack Overflow que posso restaurar para treinamento em minha instância do SQL Server 2019 recém-instalada?
obrigada
Você poderia aconselhar, por favor, ou me indicar um artigo apropriado que possa ajudar.
Preciso atualizar uma instância do SQL 2008 R2 para o SQL 2019. Estou propondo fazer backup dos bancos de dados na instância de origem e restaurar em um novo servidor host mais atualizado. Qual é a melhor maneira de fazer as restaurações desses muitos bancos de dados sem fazê-los um de cada vez? obrigada
Acabei de fazer um boo-boo na minha instância SQL pessoal. Eu queria mover os arquivos tempdb para C:\tempdb.mdf e C:\templog.ldf, respectivamente. O comando alter database ...modify file... foi executado com sucesso. No entanto, o que eu não percebi é que não posso criar um arquivo em C:\ , apenas pastas podem ser criadas lá. Portanto, após executar o comando modify file e reiniciar o serviço, os novos arquivos não foram criados, ou seja, C:\tempdb.mdf e C:\templog.ldf.
Quando tentei obter as propriedades do banco de dados tempdb para ver para onde os arquivos estavam apontando, descobri que não conseguia obter as propriedades nem me conectar à instância do banco de dados. Portanto, embora eu possa reiniciar os serviços no Config Manager, não consigo me conectar à instância usando SSMS ou SQLCMD. Eu recebo o erro que o arquivo não pode ser encontrado.
Além de reinstalar a instância (já que não tenho backup do banco de dados mestre), existe alguma outra maneira de corrigir esse problema, por favor?
Obrigada.