S M's questions

Minha organização está implementando um aplicativo de replicação interessante para coletar dados de vários bancos de dados do SQL Server e jogá-los em um data lake do Azure. Alguns dos bancos de dados estão em clusters de grupo de disponibilidade. Nossos AGs são configurados para executar backups na réplica secundária.

Por causa disso, minha equipe foi informada de que o aplicativo precisará de metadados de backup para serem sincronizados entre os membros do AG. Em outras palavras:

• o servidor A faz um backup do log de transações do banco de dados foo a cada 15 minutos
• o servidor B faz backups do log de transações da barra do banco de dados a cada 15 minutos
• o servidor A, após a conclusão de seus backups, extrai os metadados de backup do log de transações de B e os adiciona ao msdb
• o servidor B, após a conclusão de seus backups, extrai os metadados de backup do log de transações de A e os adiciona ao msdb

Dessa forma, diz o fornecedor, qualquer que seja a réplica em que um banco de dados esteja, seu aplicativo poderá acessar backups de log de transações e preencher quaisquer lacunas que possam existir se não conseguir acompanhar a captura de dados alterados. O script fornecido por eles usa RESTORE VERIFYONLY…WITH LOADHISTORY para carregar os metadados de backup no msdb. Felizmente, é apenas o backup t-log mais recente para um banco de dados em qualquer AG. Pelo menos por agora.

Nossos clusters AG não têm armazenamento compartilhado para backups, portanto, os backups de outras réplicas apareceriam com caminhos UNC. Pela minha experiência, as pessoas raramente fazem backup usando caminhos UNC e presumo que haja uma boa razão para isso.

1. Quão preocupado devo me preocupar com isso?
2. Quanta contenção de recursos isso poderia criar? Fiz um teste de verificação em um backup t-log para um de nossos bancos de dados do tamanho de terabytes e ele foi concluído em alguns segundos, mas acho que devo ficar paranóico com isso.
3. Se precisarmos executar uma restauração, o servidor de banco de dados realmente tentará mexer nos arquivos de backup nas outras réplicas?
4. Se a resposta para o número 3 for sim, existe uma maneira de marcar o registro para que o aplicativo possa usá-lo, mas o SQL Server irá ignorá-lo? Normalmente não mantemos backups por mais de 72 horas (eles são desviados pelo NetBackup), então isso não é um problema?
5. Existe uma maneira melhor do que RESTORE VERIFYONLY…WITH LOADHISTORY para carregar os metadados?

Temos um SQL Server 2017 AG de dois nós. Há um trabalho que analisa as configurações de crescimento automático para nossos bancos de dados e garante que eles não estejam configurados para usar uma porcentagem. No último dia, ele está dizendo continuamente que está atualizando as configurações de um banco de dados específico. Isso não aconteceu antes. Após investigação, descobri que sys.master_files no nó 01 diz que o arquivo de log de transações para o banco de dados crescerá em incrementos de 512 MB, mas sys.master_files do nó 02 diz que crescerá em incrementos de 10% O servidor 02 é o primário. Em ambas as réplicas, is_percent_growth é limpo em sys.database_files para este banco de dados. Observando as propriedades do arquivo no SSMS, ambas as réplicas mostram crescimento automático de 512 MB, provavelmente porque o SSMS procura em sys.database_files (uma suposição de minha parte).

Não houve failovers neste AG.

Perguntas

1. Como poderia haver uma diferença de opinião entre sys.master_files e sys.database_files no nó 02?
2. Como as configurações de crescimento automático do banco de dados ficaram fora de sincronia entre as duas réplicas?
3. Como posso limpar o sinalizador is_percent_growth no nó 02 para não ter mais falsos positivos? Idealmente, eu gostaria de fazer isso sem deixar o AG offline.

Eu li https://stackoverflow.com/questions/4174520/sql-server-sys-master-files-vs-sys-database-files que explica a diferença entre sys.master_files e sys.database_files, mas não t explicar as circunstâncias aqui.

Eu estava passando por um de nossos bancos de dados para responder a uma pergunta do chefe e espiei um procedimento armazenado. Como de costume, cliquei com o botão direito do mouse no SSMS, cliquei em Script stored procedure as... then create e, para minha surpresa, tudo o que encontrei foi a instrução CREATE PROCEDURE:

Para verificar novamente, pedi a outra pessoa que olhasse e eles obtiveram a mesma coisa. Eles estavam conectados como proprietário do banco de dados, eu estava conectado como sysadmin. eu corri em seguida

select
m.definition
from sys.procedures p
left join sys.sql_modules m on p.object_id=m.object_id
where p.name in ('spPUpdateContactUserLockout', 'spPLINK_SYNC_CONTACT');

e consegui isso (observe que incluí outro proc armazenado para fins de comparação)

Eu não vi isso antes. Sempre. Eu não achava que alguém poderia criar um procedimento armazenado sem definir um corpo, e existem vários desses procedimentos em vários bancos de dados nesta instância. Neste ponto estou preocupado, mas não tenho certeza se não preciso estar ou se deveria estar mais preocupado do que estou atualmente.

Esta instância é o SQL Server 2017 Standard x64 RTM-CU11 e estou usando o SSMS 17.9. Qualquer insight é apreciado!