PTL_SQL's questions

Estou planejando remover vários bancos de dados grandes de um AG, mas não tenho um ambiente de teste adequado para testar meu script. Só tenho um ambiente de teste para bancos de dados que são muito menores em tamanho.

O que pretendo fazer, no entanto, é:

1. selecione os vários bancos de dados grandes em Detalhes do Object Explorer e faça o script removendo-os em uma planilha de consulta e, em seguida, execute a coleção de instruções alter com script na planilha de consulta de uma só vez. Em seguida, faça algo semelhante para remover os bancos de dados 'Restoring' na réplica secundária de uma só vez.
2. ou selecionar os vários bancos de dados grandes no Object Explorer e simplesmente removê-los diretamente com um clique no SSMS. Da mesma forma, excluir os bancos de dados 'Restaurando' no secundário com um clique no SSMS Object Explorer Details.

Minha preocupação é que eles são grandes bancos de dados, alguns deles têm cerca de 2 TB cada e cerca de 300 deles. O Automatic Seeding é usado para adicioná-los. Há algo com que eu precise me preocupar ao fazer a remoção do AG, de tantos bancos de dados grandes com um clique?

Gostaria que me informassem sobre quaisquer questões que precisem ser destacadas ao realizar isso, por favor.

Obrigado

Estou recebendo o seguinte alerta apenas para um arquivo de rastreamento: O arquivo 'xxx.trc' não é um arquivo de rastreamento reconhecível.

Posso selecionar todos os outros arquivos de rastreamento usando fn_trace_gettable.

É seguro excluir este arquivo de 0 bytes para interromper o alerta?

obrigado

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:

• Alterar o modo de failover de automático para manual no primário
• Corrigir réplica secundária primeiro
• Failover do AG para o secundário corrigido
• Corrigir o novo secundário (ou seja, o antigo primário)
• failback para o primário antigo

É 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:

• Se eu conseguir garantir um tempo de inatividade para a tarefa e não tiver transações acontecendo durante o processo de patch, é seguro continuar o processo sem mudar para o modo de confirmação assíncrona? Nesse caso, tudo o que preciso fazer é mudar para failover manual, aplicar patch no secundário, fazer failover para o secundário corrigido, aplicar patch no novo secundário (ou seja, primário antigo) e fazer failback para o primário antigo.

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:

• Para criar o DAG, preciso criar um par DAG por AG da seguinte forma:
• Instância1_P_AG e Instância1_DR_AG
• Instância2_P_AG e Instância2_DR_AG

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:

• um com um SQL 2008 configurado - posso me conectar remotamente à instância do servidor de gerenciamento usando o SSMS. No entanto, não consigo me conectar a partir do aplicativo que estou testando a conectividade
• o outro é um SQL 2016 - também posso me conectar remotamente a ele a partir do servidor de gerenciamento e do aplicativo do qual estou testando a conectividade.

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:

• A propagação automática é conhecida por consumir muita memória e/ou espaço em disco?
• Em caso afirmativo, existe alguma maneira de contornar esse problema se eu ainda quiser usar a propagação automática?
• devo procurar a especificação dos nós ou apenas melhor usar a propagação manual?

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 é:

• faça backups COMPLETOS dos bancos de dados como estão (ou seja, no AG, não os removendo)
• Encerre os serviços em ambos os nós
• Confirme que não consigo me conectar a nenhum nó no SSMS
• Troque o armazenamento e copie fisicamente os arquivos do banco de dados do armazenamento antigo para o novo
• Iniciar os serviços

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