Início / dba / Perguntas / 330826
Accepted
gotqn
Asked: 2023-09-01 22:55:54 +0800 CST

SQL Server – problema de memória após atualização para 2022 CU7

  • 772

Em uma das instâncias do SQL Server não consigo executar nenhuma consulta. Achei que fosse devido a alguma carga pesada, então tento executar sp_execeute whoisactivee obter:

insira a descrição da imagem aqui]

Ontem à noite, o DBA realizou a atualização para o SQL Server 2022 CU5 e me disse que há um problema que foi resolvido com o CU7. Então, a atualização para CU7 foi realizada, mas nada mudou.

O DBA me enviou isto:

insira a descrição da imagem aqui

e depois disso:

insira a descrição da imagem aqui

mas não tenho certeza do que está acontecendo. O DBA interrompeu o armazenamento de consultas e todas as sessões de eventos estendidas, mas nada mudou. Agora, o DBA acha que o problema é causado por isso , mas deve ser corrigido no CU4 e causa problemas durante a atualização, não depois dela.

O DBA abriu ticket para MS, mas gostaria de saber se alguém sabe o que pode estar causando isso?

Vou anexar os dados de rastreamento. Um pouco mais de informação - temos uma instância do SQL Server 2022 CU5 e outra executando as réplicas com CU7.

O outro DBA acredita que o problema está nas réplicas sempre ativas, então elas são interrompidas - as réplicas travavam constantemente.

sql-server

1 respostas

  1. Best Answer

    Com base nos logs que foram carregados, o log de erros tem o primeiro problema como Dump0062 (que é preocupante por si só), qualquer coisa que aconteça depois disso é suspeita de ser um problema real, pois pode ser um efeito colateral desse problema, deixando o SQL Server em um estado inconsistente.

    Dito isto, o problema inicial parece ser com o UCS:

    (Inline Function) sqllang!ListBase::Append
(Inline Function) sqllang!SEList<CSbPrioritySchedulableUnit,0>::Append
sqllang!CSbPriorityScheduler::Append
(Inline Function) sqllang!CSbDestinationManager::NotifyDestinationStatusChange
sqllang!CSbDestinationManager::CDestination::HandleEvent
sqllang!CSbDestinationManager::CDestination::Subscribe
sqllang!CSbDestinationManager::SubscribeToDestination
sqllang!CSbServiceManager::SubscribeSession
sqllang!CSbServiceManager::RegisterSession
sqllang!CSbTransmitter::RegisterSession
sqllang!CSbMsgDispatcher::RegisterWithTransmitter
sqllang!CSbTransmission::RegisterWithTransmitter
(Inline Function) sqllang!CSbDeliverySM::SendMessages
sqllang!CSbDeliverySM::HandleEvent
sqllang!CSbTransmission::IdempotentWork
sqllang!CSbTransmission::IdempotentInvoke
sqllang!CSbTransmission_Task::IdempotentInvoke
sqllang!CSbTaskManager::HandleReusableTask
sqllang!CSbTask::TaskStart
sqllang!CSbTask::BeginTaskStart
SqlDK!SOS_Task::Param::Execute
SqlDK!SOS_Scheduler::RunTask
SqlDK!SOS_Scheduler::ProcessTasks
SqlDK!Worker::EntryPoint
SqlDK!ThreadScheduler::RunWorker

    Acontece que isso é EXCEPTION_ACCESS_VIOLATIONconhecido como AV. Isso faz com que o SQL Server seja encerrado ( SQL Server is terminating this process.), portanto, nada depois disso não precisa ser investigado.

    Com base nos logs (e na configuração percebida deles), o erro, a causa mais provável, é uma condição de corrida ou acesso não seguro de thread às estruturas de dados. Se isso estiver acontecendo apenas em um único servidor (e todos os outros estiverem corrigidos), pode fazer sentido executar uma verificação de memória (apenas por segurança). Se isso estiver acontecendo em todos os servidores, provavelmente é um problema de produto.

    Se isso não estava acontecendo nos patches de nível inferior, pode fazer sentido desinstalar as CUs que foram instaladas e ver se isso ocorre novamente.

    • 6

relate perguntas