MrTCS's questions

Temos um AG de três nós. Dois nós em um data center local, um em um site de DR de sub-rede diferente. Estou correto que o nome do cluster deve ter dois IPs, assim como o ouvinte?

Além disso, existe uma maneira de definir os proprietários preferenciais do nome do cluster e da testemunha para que ele não tente fazer failover para o site de DR se os nós primários estiverem ativos?

Informações Adicionais: Tivemos uma interrupção ao aplicar patches em um nó secundário, não conseguimos descobrir por que uma reinicialização secundária fez com que o AG & Cluster ficasse inativo. Abrimos um tíquete de suporte com a Microsoft e eles recomendaram que alterássemos os possíveis proprietários do Grupo de clusters para excluir DR. Então, o que parece ter acontecido é que o Grupo de Cluster tentou fazer failover para o site de DR, não pôde ficar online porque não havia IP de sub-rede. Isso demorou o suficiente para que o quórum fosse perdido porque a testemunha não estava online e o secundário estava reiniciando.

Estou tentando restaurar um banco de dados de um ambiente Prod (11.0.6020.0) para um servidor de ambiente inferior (11.0.3128.0). Percebo que o mais baixo tem um SP mais antigo, estamos trabalhando para corrigir isso agora. A restauração ainda deve funcionar, mas há meses, mas estou recebendo a seguinte mensagem de erro. Habilitamos recentemente este banco de dados para CDC, não estou especificando keep_cdc na restauração. Alguém já viu esse erro antes e sabe como resolver?

Msg 22841, nível 16, estado 1, procedimento sp_cdc_vupgrade, linha 320 [Linha inicial do lote 0] Não foi possível atualizar os metadados do banco de dados 'DBName' habilitado para Change Data Capture. A falha ocorreu ao executar a ação 'alter cdc.change_tables index change_tables_unique_idx with (drop_existing = on)'. O erro retornado foi 4922: 'linha 102, estado 9, ALTER TABLE ALTER COLUMN column_id falhou porque um ou mais objetos acessam esta coluna.'. Use a ação e o erro para determinar a causa da falha e reenvie a solicitação.

RESTORE DATABASE [DBName] 
FROM  DISK = @FileToRestore WITH  
MOVE  'DBName' to 'W:\Data\DBName\DBName.mdf',
MOVE  'AmexDB_log' to 'W:\Logs\DBName\DBName_Log.ldf',
NOUNLOAD, REPLACE , FILE = 1, STATS = 10
GO

Estamos tendo problemas de pressão de memória ( RESOURCE_SEMAPHOREesperas) em um de nossos servidores, mas há muito poucas conexões ativas acontecendo ao mesmo tempo. Logicamente, não parece que as conexões adormecidas se manteriam na memória, mas estou me perguntando se elas realmente o fazem? O IderaDM mostra várias conexões adormecidas com alto uso de memória.

Este é um servidor SQL 2008 SP3 com 27 Gb de memória. Normalmente, há apenas duas a 10 chamadas ativas acontecendo a qualquer momento e uma boa parte delas está tendo esperas resource_semaphore. Este servidor mantém nossos bancos de dados de terceiros, portanto não podemos alterar a maioria das chamadas/processos.

Então, é possível que as conexões adormecidas estejam retendo a memória ou devo procurar em outro lugar?