Você pode alternar o modo de recuperação para simples de completo em uma configuração de cluster Always ON?

O DBA está correto - se o banco de dados fizer parte de um Grupo de Disponibilidade (AG), ele deverá estar no modelo de recuperação FULL. Isso ocorre devido à maneira como os AGs funcionam - eles enviam blocos de log de transações do servidor primário para o(s) servidor(es) secundário(s). Portanto, todos os registros de log detalhados fornecidos pelo modelo de recuperação FULL são necessários.

Você pode remover o banco de dados do AG durante o carregamento de dados inicial.

ALTER AVAILABILITY GROUP [YourAG]
REMOVE DATABASE [YourDatabaseName];

No entanto, a desvantagem (potencialmente importante) disso é que o secundário precisará ser "reinicializado" assim que o carregamento de dados for concluído. Isso significa usar a "propagação automática" para replicar todo o banco de dados primário para o(s) servidor(es) secundário(s) ( Habilitar a propagação automática em um grupo de disponibilidade existente ) ou fazer um backup do primário, restaurá-lo em cada um dos secundários e, em seguida, re-adicionando o banco de dados ao AG ( Preparar um banco de dados secundário para um grupo de disponibilidade Always On ).

Dependendo do tamanho do banco de dados após o carregamento de dados, isso pode não ser "grande coisa" ou pode ser um verdadeiro aborrecimento. Mas sim, essa é a outra opção disponível para o DBA basicamente.

Aliás, quanto a isso:

estamos vendo no monitor de atividade uma pilha de consultas em estado de espera

Você não mencionou a espera real, mas a menos que seja HADR_SYNC_COMMITou WRITELOG, remover do AG / alternar para a recuperação SIMPLE pode não ajudar.

Mesmo que essas sejam suas esperas, esteja ciente de que você está tratando um sintoma. Se o aplicativo precisar despejar dados como esse quando estiver no ar, você provavelmente não poderá usar o AG ou os modelos de recuperação.

Talvez seu aplicativo possa reduzir a quantidade de dados de log gerados agrupando algumas de suas transações em lotes maiores .

Ou talvez você precise investigar a velocidade da rede entre os servidores primário e secundário (tendo em mente como medir corretamente a taxa de transferência do AG ).

Esses são apenas alguns remédios possíveis. Tudo isso é apenas para dizer que é melhor, a longo prazo, descobrir a causa raiz desse negócio de "estado de espera que leva a erros de aplicativo" agora e não mais tarde.

As esperas que você mostrou são esperas de bloqueio, indicativas de uma cadeia de bloqueio clássica.

Observe que a coluna "Bloqueado por" é 131 para todas as linhas na captura de tela. Isso é um "ID de sessão" (primeira coluna do Monitor de Atividade). Continue seguindo essa cadeia até encontrar o bloqueador de leads ("Bloqueado por" ficará em branco) e olhe na coluna "Tipo de espera" para ver o que está esperando. É aí que você deve concentrar seus esforços para desvendar a causa raiz.

Sobre esta atualização:

Aparentemente, o padrão para fazer um backup do diretório de log foi definido como um valor grande. Quando isso começou para limpar o log (coisa de log incremental?), isso faz com que todo o sistema gagueje e causou o problema. Essa é a minha teoria atual. Agora ele mudou para 5 minutos e até agora, tudo o que vemos é uma gagueira e recuperação do nosso lado. Eu faço meu engenheiro coletar mais dados reais (o bloco real, se ele puder pegá-lo).

Parece que o aumento do uso de recursos quando ocorrem backups de log de transações está interferindo em sua carga de trabalho. Uma solução para isso seria executar logs de transações com mais frequência, como o DBA fazia. Você pode até executar os backups a cada minuto se eles terminarem rápido o suficiente.

Dito isso, a solução original de comutação para recuperação SIMPLE é uma opção viável se for viável reinicializar o secundário após a conclusão da carga inicial.