DBA Greg14's questions

Estamos tentando nossa primeira atualização lado a lado de um AG de 2 nós (várias sub-redes, edição empresarial) do sql 2016 para 2019. Tenho algumas perguntas sobre a melhor forma de abordar isso:

1. Criamos um novo cluster e AG com sql2019 e usamos o envio de log para preencher e passar para o novo ambiente?
2. Adicionamos 2 novos nós de 2019 (1 em cada sub-rede existente) e os configuramos como secundários no AG existente? Eu sei que normalmente você não pode misturar versões em um AG, mas para uma atualização como essa eu li que é feita sem problemas, desde que você não tente fazer failback para os nós da versão mais antiga.
3. Como os ouvintes do AG são tratados no item 2? Acho que deveríamos ser capazes de usar os ouvintes existentes, já que os novos nós estão nas mesmas sub-redes da versão antiga dos nós SQL.

Não consigo encontrar nenhum guia passo a passo para isso on-line quando estamos lidando com clusters e AGs

minha equipe de desenvolvimento tem usado instantâneos de banco de dados para reverter rapidamente um banco de dados autônomo de 4 TB para um estado anterior depois de executar vários testes. Eles agora precisam do mesmo processo para redefinir esse banco de dados para um estado anterior, mas agora ele está em um grupo de disponibilidade. Não tenho conhecimento de como os instantâneos podem ser usados ​​a esse respeito. o método tradicional de backup e restauração leva mais de 6 horas e não é realmente uma opção para fazer vários testes rapidamente.

Não encontrei nada no google que sugira que haja uma maneira rápida e rápida de redefinir um banco de dados em um grupo de disponibilidade de volta a um estado anterior. Não tenho muita experiência com instantâneos em geral, muito menos como eles podem funcionar em um AG.

estamos executando o SQL 2019 RTM.

Existe uma maneira de os instantâneos do banco de dados poderem ser usados ​​nessa situação para evitar o tempo normal de restauração?

Tentei restaurar diretamente o instantâneo sem tirar o banco de dados do AG, mas recebo este erro:

RESTORE cannot operate on database 'agseed' because it is configured for database mirroring or has joined an availability group. If you intend to restore the database, use ALTER DATABASE to remove mirroring or to remove the database from its availability group.

então tirou o banco de dados do AG e conseguiu restaurar o instantâneo para o primário, mas não há como restaurá-lo "sem recuperação" para propagar o secundário.

Pergunta de duas partes aqui.

Temos uma tabela grande (entre 1-2 milhões de linhas) com operações DML muito frequentes nela. Durante os períodos de baixo volume, temos um trabalho de agente para remover as linhas mais antigas para manter o tamanho das tabelas sob controle. ele usa o CTE abaixo, que está causando muito bloqueio quando roda:

;with agent_cte (queue_id) as 
(
   select top (3000) queue_id
   from Table_A with (updlock, readpast)
   where state in ('success','error','reject','failed','deleted')
   and modify_timestamp <= DATEADD(dd,- 5,getdate())
   order by modify_timestamp asc
)
   delete from agent_cte 
;

Plano de consulta CTE

Eu reescrevi isso para usar uma tabela temporária para acelerar a consulta e reduzir o bloqueio, mas estou encontrando uma grande diferença de desempenho entre usar INe EXISTSdeterminar quais linhas excluir.

INversão:

-- Create temp Table
create table #Table_AToDelete
    (Queue_id uniqueidentifier,
    PRIMARY KEY(Queue_id)
    );

-- grab top 3k queue_id's older than 5 days, insert into temp table
    Insert into #Table_AToDelete
        select top (3000) queue_id
        from Table_A with (nolock)
        where state in ('success','error','reject','failed','deleted')
        and modify_timestamp <= DATEADD(dd,- 5,getdate())

-- delete the rows from table_A based on rows in temp table
    delete 
        from Table_A
        where queue_id in (select queue_id from #Table_AToDelete)

Plano de mesa temporária

Esta versão é executada em 40 a 50 segundos, no entanto, quando substituo a última linha da instrução delete pela seguinte:

where exists(select queue_id from #Table_AToDelete)

Ainda está funcionando depois de 2 minutos, então cancelei.

Então, as perguntas:

1. Já vi tabelas temporárias usadas para ajudar no bloqueio e no desempenho antes, mas não entendo completamente POR QUE isso funcionaria melhor do que usar um CTE? Nós temos um índice em Queue_id.
2. Por que há uma grande diferença de desempenho entre INe EXISTSna exclusão?

Algum feedback sobre como ajustar isso para ter um desempenho melhor ou reduzir ainda mais o bloqueio?

Mais algumas notas:

• Tanto o CTE quanto a tabela temporária estão disponíveis usando colar o plano (links acima).
• Existem FKs para duas outras tabelas com atualização e exclusão em cascata, e o plano CTE gasta mais tempo na exclusão, enquanto a versão da tabela temporária gasta mais tempo na tabela principal.
• De um modo geral, há benefícios de desempenho ao usar uma tabela temporária como esta em comparação com uma CTE?
• Não tenho permissão para postar esquemas de tabelas, então peço desculpas se os planos não forem informações suficientes.

Também vou testar usando uma visão como neste artigo .

Em breve estarei migrando uma instalação do 2008 R2 SSRS para um novo SQL 2019 Always on AG na AWS. Este conterá assinaturas, e eu nunca lidei com elas antes. Eu li a documentação aqui: SSRS e AG's e afirma que os trabalhos do agente que controlam as assinaturas são recriados automaticamente após um failover no novo primário, mas ainda existem no primário antigo.

Para minhas outras migrações do SSRS, escrevi um código que cuida automaticamente da reinicialização do agente SQL e dos serviços do SSRS nos nós apropriados após um failover para usar o novo nó. Eu tenho os mesmos trabalhos em todas as réplicas e também tenho uma etapa de trabalho nelas que verifica se o servidor é o principal. Se não for, o trabalho não será executado.

Como meus trabalhos já estão sincronizados e controlam a execução com base no status da réplica primária, prefiro usar isso para controlar as assinaturas, mas o SQL substituirá os trabalhos existentes para as assinaturas? Ou apenas adicionará empregos que não existem? Não tenho um servidor para testar isso no momento e não consigo encontrar essa situação específica online. Prefiro ter os trabalhos sempre lá e deixar a lógica do trabalho executar os trabalhos com base no estado da réplica. Isso é possível com assinaturas ou preciso sempre desabilitar os trabalhos no primário antigo e permitir que o SQL recrie os trabalhos no novo primário?

Eu também gostaria de renomear os trabalhos do agente sql de seu GUID sem sentido para algo mais intuitivo. Isso atrapalharia os trabalhos em execução se eu fizesse isso?

Farei a transição de alguns ambientes SQL de não produção da edição Enterprise para Developer nos próximos meses. Estou bastante decidido sobre o procedimento que usarei, que é apresentado nesta postagem do blog: Fazendo downgrade do SQL Server Editions

Não consegui encontrar nenhuma informação específica sobre precauções especiais necessárias ao fazer isso em um ambiente com grupos de disponibilidade. Temos um AG de confirmação síncrona de 2 nós. Considerando que estamos indo de Enterprise para Developer, não estou preocupado com o fato de os recursos apenas da Enterprise serem um problema. Meu fluxo de trabalho presumido será:

1. Faça o downgrade do secundário primeiro de acordo com a postagem do blog acima, verifique se tudo está sincronizado depois.
2. Failover para o secundário (agora na edição do desenvolvedor)
3. Faça o downgrade do primário antigo e verifique se os db's estão sincronizados.

É essencialmente o mesmo processo que uso para lançar patches e atualizações, mas não tenho certeza se há considerações especiais para edições de downgrade... Alguém tem algum problema ao fazer isso?

Encontrei alguns posts mais antigos lidando com isso (5 anos ou mais), mas estou confuso sobre o processo ou se essas informações estão desatualizadas, daí minha nova pergunta. Estou no sql 2016 SP2-CU11 Enterprise.

Preciso habilitar o service broker em um banco de dados que está em um grupo de disponibilidade. Seu tamanho é de 1,8 TB, então eu realmente não quero tirá-lo totalmente do AG e resemeá-lo novamente com um novo backup, se puder evitá-lo. Algumas postagens mais antigas dizem que você precisa remover e adicionar completamente o db de volta ao AG, outras fazem referência apenas à execução de algum código para criar endpoints e rotas que eu nunca executei antes.

O processo abaixo é a única maneira de habilitar o service broker em um DB em um AG onde ele não está habilitado?

1. remova a cópia secundária do DB e, em seguida, a cópia primária do AG.

2. Execute o código abaixo para ativar o service broker:

   ALTER DATABASE XXXXXX SET ENABLE_BROKER; VAI

3. Faça um backup completo, restaure-o no secundário sem recuperação.

4. junte o DB ao AG no secundário.

Eu tenho uma tabela com 2,6B linhas e preciso alterar uma coluna de Char(1) para Varchar(64). a tabela tem mais de 300 GB com alguns índices. A coluna em nullable, então a transação que estou executando é:

ALTER TABLE XXXX ALTER COLUMN YYYYY varchar(64) NULL

Eu entendo que esta é uma operação registrada, então eu pré-dimensionei o log de transações para 300 GB pensando que seria suficiente especialmente com backups de log a cada 5 minutos para permitir a reutilização do espaço de log. bem, o log de transações cresceu para 812 GB antes de eu ter que cancelar a transação devido a problemas de espaço em disco.

Também experimentei um aumento muito grande no tamanho do arquivo de dados USADO, que não sei por que isso aconteceria. O tamanho do arquivo de dados usado chegou a cerca de 200 GB (transações muito mínimas são feitas neste banco de dados, então eu sei que o aumento é desse comando alter table).

Eu tenho algumas questões:

1. Por que os arquivos de dados experimentariam um aumento ao mudar apenas de char(1) para varchar(64)? Fiquei com a impressão de que isso não deve alterar a quantidade de dados armazenados, a menos que esse espaço seja realmente necessário desde seu varchar. todos os valores existentes eram nulos ou 1 byte, pois char(1) é o tipo de dados existente, nenhum dado existente precisa ser expandido.
2. Enquanto tentava descobrir como fazer isso melhor, me deparei com esta resposta de Aaron Bertrand e parece que funcionaria no meu caso também. essa seria uma maneira melhor de realizar essa tarefa?
3. esse banco de dados está em um AG de confirmação síncrona de 2 nós e notei que o redo_queue_size chegou a mais de 130 GB, o que significa que o primário estava enviando dados de log em um ritmo mais rápido do que o secundário poderia aplicá-los. Isso significa que o log no primário não pôde ser truncado quando os backups de log foram concluídos. isso é um comportamento normal para algo assim? a instrução alter column é processada como uma grande transação? se assim for, isso explicaria por que o log continuou crescendo.

Eu tenho um AG de 2 nós em um ambiente sem produção e estamos procurando desligar o nó secundário para economia de custos, deixando isso apenas com o nó primário. Eu tenho algumas perguntas baseadas neste processo, e minha pesquisa não respondeu a todas elas. Poderia de alguma forma preencher as lacunas aqui sobre o que é possível/melhor fazer?

1. é possível manter apenas um único nó AG? em caso afirmativo, há uma razão para realmente fazê-lo? Pelo que entendi, não há nenhum benefício em manter o AG se você remover todos os nós secundários, pois ele se torna apenas uma instância autônoma. Se eu mantiver o AG, os logs de transações dos DB's não serão truncados, pois está tentando encontrar um local para enviar os logs, correto?

2. O AG Listener - ponto discutível se removermos o AG completamente, mas se eu mantiver o AG como um único nó, o listener não funcionaria corretamente? Minha equipe de aplicativos precisará fazer alterações no código para usar outra coisa, já que o nome do ouvinte é codificado para ser usado e eles gostariam de evitar isso, se possível. Eu não acho que isso é possível, mas queria verificar.

3. Nó secundário no futuro - podemos ativar o nó secundário sob demanda no futuro, portanto, há um problema em deixar os recursos do cluster no lugar depois de remover o AG ou a remoção exclui os objetos do cluster? Eu acho que eles ficam, mas não encontrei uma resposta sobre isso.

4. Pergunta do SSRS - estamos em uma implantação de expansão, preciso remover o secundário da expansão? Eu preferiria deixá-lo, pois talvez precisemos recriar o secundário no futuro. Eu precisaria atualizar as strings de conexão, etc., para usar o nó primário e não o ouvinte.

Meu fluxo de trabalho assumido é assim com base no que encontrei

1. Conectar-se à réplica primária
2. Exclua todo o AG (isso remove as configurações de AG de todos os DBs, primários e secundários) e coloca os DBs secundários no estado de restauração, deixando os DBs primários acessíveis e completamente separados.
3. os backups de log continuarão no primário normalmente e o truncamento de log acontecerá conforme o esperado.

Eu tenho uma configuração de AG de 2 nós (não é um FCI). Preciso configurar um alerta para acionar um trabalho com base em uma string encontrada no log de erros mostrando que o nó agora é o novo primário.
A string que quero usar é:

'primary_pending' para 'primary_normal'

Isso é o que mostra no log de erros quando o nó secundário se torna primário. Quero que o alerta inicie um trabalho SQL que criei para automatizar nosso SSRS para usar a nova réplica primária.

Abaixo está o alerta que configurei, mas não está sendo acionado corretamente. Eu tenho o alerta configurado para executar o trabalho quando este alerta for acionado.

Quando ocorre um failover, o trabalho não é iniciado. Eu estou supondo que pode ser devido ao número de erro usado. Encontrei um post no blog sobre como usar isso, mas não consigo encontrá-lo novamente. O log de erros não exibe nenhum número de erro na linha com este texto, então acho que esse é o problema.

Como posso obter um alerta para disparar com base no texto encontrado no log de erros ou há uma maneira melhor de fazer isso?

Eu tenho lógica condicional para verificar o status primário/secundário em todos os meus trabalhos, mas não posso usar isso para este trabalho, pois quero que ele execute apenas 1x (quando se tornar primário).

Não tenho certeza de como dizer isso, mas estou procurando qualquer coisa que um DBA possa fazer (coisas fora da mudança de código no aplicativo) para reduzir o impacto para os usuários quando um AG falha.

Temos um AG de 2 nós executando o SQL 2016 SP2 CU10 no modo de confirmação síncrona, conectando-se a um ouvinte.

O que controla a comutação de conexões para o novo nó primário? existe uma maneira de acelerar o switch? Qualquer coisa na cadeia de conexão, configurações de AG, alteração de tempos limite, etc., que ajudaria a tornar a troca mais rápida para os usuários?

Estou testando a nova opção de detecção de nível de banco de dados na edição 2016 do SQL Enterprise SP2 CU7 e ela não parece estar funcionando conforme o esperado. Temos uma configuração de 2 nós, confirmação síncrona, failover automático em ambos os nós. A opção de detecção de integridade no nível do banco de dados está marcada. No nó primário, coloquei offline uma unidade que continha um dos arquivos de dados do banco de dados que está no AG. Executei um select * de uma tabela que lia do disco ausente e obtive o erro 823 esperado, que foi registrado no log de erros. Eu o executei algumas vezes e o log de erros gravou o 823 várias vezes.

O grupo de disponibilidade NÃO falhou como deveria quando isso aconteceu. Esperei cerca de 3 minutos para ver se ocorreria um failover, e isso nunca aconteceu. Como posso descobrir com que frequência a rotina de verificação de integridade de nível de banco de dados está configurada para ser executada? Eu entendo que isso precisa ver o problema em 4 execuções consecutivas de acordo com este artigo: failover de nível de banco de dados aprimorado

Verifiquei o valor do tempo limite da verificação de integridade no AG e era de 30 segundos.

Também revisei o nível de condição de falha no servidor e ele está definido como On CriticalServerErrors, mas pelo que entendi, essa configuração é completamente independente da verificação de integridade do nível do banco de dados e qualquer um deles deve ser capaz de acionar um failover por conta própria . Isso está correto?

A única coisa que posso pensar que está impedindo isso é o tempo limite pendente no gerenciador do WSFC. isso tem um valor de 3 minutos antes de colocar o recurso de cluster offline.

Alguma idéia de onde mais eu deveria estar procurando por que isso não falhou?

Eu migrei uma instalação autônoma do SSRS do SQL Enterprise para um novo nó SQL Standard 2 Basic AG recentemente. Recebi o esperado "erro de implantação não suportada" e resolvi isso removendo as informações do servidor antigo da tabela de chaves no banco de dados do reportserver. Agora tenho apenas 2 linhas nessa tabela, um nome de máquina NULL e Node1. o servidor de relatório funciona perfeitamente bem no Node1 agora, mas quando faço failover para o node2, recebo o erro "recurso de expansão não é suportado" quando vou para o link de URL do serviço da Web ( http://Node2:80/Reportserver ) , mas NÃO quando vou para o link da URL do Portal da Web ( http://node2:80/Reports ). Isso me dá acesso aos fodlers de relatórios,

Se eu restaurar a chave de criptografia, funciona bem, apesar de já ter restaurado a chave de criptografia anteriormente.

Não posso ter o SSRS instalado em ambos os nós de um grupo de disponibilidade básico? Deve ser instalado apenas no Node1? Se sim, ainda poderei acessar o reportserverDB compartilhado?

Esta é minha primeira tentativa com grupos de disponibilidade básicos, não encontrei esse problema com minha última instalação corporativa desde que estava usando a implantação de expansão.

Acabei de pensar em outra coisa... o banco de dados de origem do qual o servidor de relatórios está puxando os dados está em um AG diferente, pois os AGs básicos só podem ter 1 banco de dados neles. se esse banco de dados estiver em um nó diferente, em que reportserver e reportservertempDB estão sendo executados, isso pode ser um problema? o banco de dados de origem também precisaria ser submetido a failover?

Estou passando por uma situação estranha que não consegui resolver. Eu tenho um AG básico de 2 nós executando o sql server 2016 padrão. Estou tentando adicionar o banco de dados do reportserver a um AG, mas ele continua falhando ao ingressar o banco de dados no nó secundário.

Eu fiz o abaixo:

1. recuperou totalmente o banco de dados no node1 (primário), verifique se está no modo de recuperação completa
2. fez um novo backup, E registre o backup imediatamente após ele
3. restaurou o backup completo e de log para o Node2 (secundário), deixando-o no estado de restauração.

De volta ao primário, criei um AG por meio da GUI, mas quando chego ao final, ele fica unindo o DB ao AG no node2. Recebo alguns erros diferentes, que significam essencialmente a mesma coisa:

 "a cópia remota do banco de dados "reportserver" não foi revertida para um ponto no tempo englobado na cópia local"

"o banco de dados espelho "reportserver" tem dados de log de transações insuficientes para preservar a cadeia de backup de log."

Eu sei que isso significa que deve haver backups de log adicionais para restaurar, mas antes disso fiz o backup completo E de log e restaurei ambos para o secundário, portanto, não deve haver outros backups para restaurar ... A única coisa Eu posso pensar é que algo ainda está gravando no log no primário, mas até onde eu sei, mesmo que seja esse o caso, juntar o DB ao AG ainda deve funcionar como a parte atualmente sem backup do o log deve ser transmitido para a réplica secundária durante o processo de sincronização. Eu ignorei a configuração do ouvinte por enquanto. Eu também parei o serviço SSRS em ambos os nós antes de fazer isso.

Alguém já se deparou com isso antes e teve sucesso em corrigi-lo? É porque é o reportserverDB e não pode ser associado ao mesmo AG que o reportservertempDB?

Eu tentei a propagação automática e o modo somente de junção, e o estranho é que a propagação automática NÃO me dá erros durante a configuração do AG, mas o banco de dados nunca aparece no Node2. Quando eu entrar apenas, é quando recebo os erros acima. Estou bastante confuso com isso. Eu tenho 6 outros DBs nesses nós, cada um em seu próprio AG básico, e não tive nenhum problema com eles.

Esta é minha primeira tentativa de configurar o SSRS, então peço desculpas se alguma pergunta parecer básica. Eu pesquisei o máximo que pude e estou confuso sobre as coisas abaixo. Eu tenho meu ambiente descrito abaixo também.

Temos um AG de 2 nós em um WSFC. vamos chamá-los de sql1 e sql2, com listener de sql-listener. SQL 2016 empresarial. Minha intenção é fazer com que todas as conexões de aplicativos executando relatórios sejam enviados ao nó secundário para manter a carga fora do servidor primário. Os nós são configurados em confirmação síncrona, modo primário de leitura/gravação e secundário legível. Perguntas:

1. a implantação do Scale out é necessária em uma configuração como essa? Não consigo fazer com que o Sql2 apareça na tela de expansão no Sql1 para eu adicionar. O visualizador de eventos está dando erros no Sql2 como "o serviço de janelas do servidor de relatório não pode se conectar ao banco de dados do servidor de relatório" e O valor de UrlRoot em RSReportServer.config não é válido. O valor padrão será usado em seu lugar."
2. O erro acima provavelmente é causado pelo uso da conta de serviço virtual integrada e não de uma conta de domínio? ambos os nós têm os bancos de dados do servidor de relatório e são sincronizados no AG. Eu reconfigurei o SSRS usando o gerenciador de configuração em ambos os nós e eles são idênticos em todos os aspectos, exceto que os URLs refletem seus nomes de servidor locais http://sql1:80/ReportServer e http://sql2:80/reportserver . Eu também adicionei uma nova URL com o nome do ouvinte em ambos os servidores, mas o problema permanece. 3.) a string de conexão também deve ser alterada como eu a entendo. Eu adicionei o applicationintent = readonly e alterei a fonte de dados para o ouvinte sql. Isso é tudo o que é necessário para alterar a cadeia de conexão para apontar automaticamente as conexões de entrada para o nó secundário, de acordo com a configuração do AG acima?

Encontrei um problema hoje e, embora tenha conseguido corrigi-lo, não tenho certeza do que causou o problema.

Eu tenho uma coluna que é Varchar(20). Ele é usado para armazenar apenas os dados do ano (2010, 2011, etc.) que está sendo convertido para um tipo de dados Int, mas quando o comando abaixo é executado, ocorre um código de erro.

ALTER TABLE mytable ALTER COLUMN1 int NULL

O erro exibido é:Conversion failed when converting the varchar value '2010. ' to data type int.

Existem 3 linhas na tabela com o valor de 2010 na Coluna1, mas NENHUMA linha com '2010. '(ponto e 10 espaços) como valor. eu corri

select len(Column1) from MyTable where Column1 like '%2010%'

Eu tenho 2 linhas com comprimento 4 e 1 com comprimento 5. Depois de atualizar a linha com comprimento 5 para ter 2010 como valor, a tabela pode ser alterada.

Estou curioso de onde veio o período e os espaços daqui. Também curioso como o aumento de 1 caractere resulta em um ponto e 10 espaços. Estou pensando em algo como um retorno de carro ou alimentação de linha, mas não consigo encontrar nenhum dado para fazer backup disso, é apenas um palpite.