Поделиться через

MSSQLSERVER_19407

  • Статья

Область применения: SQL Server

Сведения

Атрибут Значение
Название продукта SQL Server
ИД события 19407
Источник событий MSSQLSERVER
Компонент SQLEngine
Символическое имя HADR_AG_LEASE_EXPIRED
Текст сообщения Срок аренды между группой доступности "%.*ls" и отказоустойчивой кластером Windows Server истек. Между экземпляром SQL Server и отказоустойчивым кластером Windows Server возникла проблема с подключением. Чтобы выяснить, правильно ли выполняется отработка отказа группы доступности, проверьте соответствующий ресурс группы доступности в отказоустойчивом кластере Windows Server.

Описание

Ошибка 19407 возникает в журнале ошибок SQL Server в случае потери связи между SQL Server и отказоустойчивым кластером Windows Server. Обычно выполняется действие для устранения ошибки — отработка отказа на другой узел AlwaysOn.

Аренда представляет собой основанный на времени механизм обмена данными, который выполняется между SQL Server и процессом отказоустойчивого кластера Windows Server (WSFC), в частности процессом RHS.EXE. Эти два процесса периодически взаимодействуют друг с другом для подтверждения того, что другой процесс выполняется и предоставляет ответы. Это взаимодействие происходит с помощью объектов событий Windows и гарантирует, что отработка отказа ресурса группы доступности не происходит без знания WSFC. Если какой-либо из этих процессов перестает отвечать на запросы аренды исходя из предварительно указанного периода аренды, возникает истечение времени ожидания аренды. Подробные сведения см. в разделе "Механика" и рекомендации по аренде, кластеру и времени ожидания проверки работоспособности для групп доступности AlwaysOn. Также см. сведения о том, как это работает: время ожидания аренды AlwaysOn SQL Server

Причины

Так как события Windows являются объектами синхронизации легкого веса, существует относительно небольшое количество внешних факторов, влияющих на них отрицательно. Типичные проблемы, которые могут привести к истечении времени ожидания аренды, связаны с проблемами на уровне системы. Ниже приведен список возможностей, которые могут привести к истечении срока аренды и вызвать перезагрузку или отработку отказа:

  • Высокая загрузка ЦП в системе (около 100%).

  • Условия вне памяти — низкая виртуальная память и /или один из процессов выстраиваются.

  • WSFC идет в автономном режиме из-за потери кворума. Сведения об устранении проблем с потерей кворума см. в статье "Настройка кворума и управление ими" и аварийное восстановление WSFC с помощью принудительного кворума (SQL Server).

  • Регулирование виртуальной машины влияет на производительность и приводит к истечении срока действия аренды.

  • Процесс SQL Server не отвечает при создании большого дампа памяти. Дополнительные сведения о создании дампа стека см. в разделе "Влияние создания дампа". Создание дампа стека может произойти по некоторым из следующих причин:

    • Планировщик nonyielding
    • Время ожидания блокировки
    • Заблокированный планировщик
    • Неразрешенная взаимоблокировка

Действие пользователя

Устранение проблем с высоким уровнем ЦП

  1. Откройте диспетчер задач.

  2. Перейдите на вкладку "Производительность " и убедитесь, что ЦП близки к 100% использованию.

  3. Перейдите на вкладку "Процессы " и сортируйте процессы по столбцу ЦП в порядке убывания, выбрав столбец ЦП .

  4. Определите процесс, использующий большую часть ЦП, и работаем над пониманием и разрешением причины, приводящую к высокой загрузке ЦП.

  5. Если процесс является SQL Server, см. статью "Устранение проблем с высоким использованием ЦП" в SQL Server.

  6. Для проверки использования ЦП в системе можно использовать следующий скрипт PowerShell.

    Get-Counter -Counter "\Processor(_Total)\% Processor Time" -SampleInterval 5 -MaxSamples 30 |
    Select-Object -ExpandProperty CounterSamples | Select-Object TimeStamp, Path, CookedValue

Устранение неполадок, связанных с нехваткой памяти

Если в системе имеются вхождения низкой виртуальной или физической памяти, может быть выстраивается процесс SQL Server или хост-службыRHS.exe ресурсов кластера. Если процесс выстраивается на диск, он не выполняется активно, и время ожидания аренды может быть достигнуто с помощью памяти времени, и виртуальные байты процесса отображаются обратно в физическую память. Низкая виртуальная память может быть вызвана приложениями, драйверами или ОС, используюющими всю память в системе. Используйте следующие методы для устранения этой проблемы:

  1. Проверьте журнал событий приложения или системы для таких ошибок Your system is low on virtual memory. Эта ошибка может отображаться на экране, если вы вошли на сервер.

  2. Откройте диспетчер задач, выберите "Производительность —> память", чтобы проверить, используется ли объем памяти близко к 100 % памяти. Используйте вкладку "Сведения", чтобы определить все приложения, которые могут быть крупнейшими потребителями памяти.

  3. Вы также можете использовать Монитор производительности и отслеживать эти счетчики с течением времени:

    • Process\Working Set — проверка использования памяти отдельных процессов
    • Memory\Available MBytes — проверка общего использования памяти в системе

    Чтобы определить общее использование памяти во всех процессах и доступной памяти в системе, можно использовать следующий сценарий PowerShell. Если вы хотите получить использование памяти отдельных процессов, измените его "\Process(_Total)\Working Set" "\Process(*)\Working Set"на .

    $serverName = $env:COMPUTERNAME
$Counters = @(
  ("\\$serverName" + "\Process(_Total)\Working Set") , ("\\$serverName" + "\Memory\Available Bytes")
)

Get-Counter -Counter $Counters -MaxSamples 30 | ForEach-Object {
    $_.CounterSamples | ForEach-Object {
        [pscustomobject]@{
            TimeStamp = $_.TimeStamp
            Path      = $_.Path
            Value_MB  = ([Math]::Round($_.CookedValue, 3)) / 1024 / 1024
        }
        Start-Sleep -s 5
    }
}

  4. Если вы определяете определенные приложения, использующие большие объемы памяти, рассмотрите возможность остановки или перемещения этих приложений в другой системе или контроля использования памяти.

  5. Если SQL Server потребляет большие объемы памяти, вы можете рассмотреть возможность sp_configure 'max server memory' снижения использования памяти.

Монитор производительности сбор данных для ЦП, памяти и диска

Этот скрипт PowerShell упрощает сбор данных монитора производительности (PerfMon) относительно ЦП, памяти и диска. Скрипт предназначен для гибкого использования, что позволяет настраивать как для стандартных, так и именованных экземпляров SQL Server.

#Replace with your instance name if need to collect PerfMon data for named instance
$InstanceName = 'MSSQLSERVER'

# Replace with your desired location
$Location = "D:\PerfMonLogs"

# Function to create performance counter log
function Create-PerfCounterLog {
    param
    (
        [string]$InstanceName,
        [string]$Location
    )
    $counters = @(
        '\Memory\*',
        '\PhysicalDisk(*)\*',
        '\LogicalDisk(*)\*',
        '\Server\*',
        '\System\*',
        '\Process(*)\*',
        '\Processor(*)\*',
        '\SQLServer:Databases(*)\*',
        '"\SQLServer:Buffer Manager\*"',
        '"\SQLServer:SQL Statistics\*"',
        '"\SQLServer:Transactions\*"',
        '"\SQLServer:Database Mirroring\*"',
        '"\SQLServer:Latches\*"',
        '"\SQLServer:General Statistics\*"',
        '"\SQLServer:Availability Replica(*)\*"',
        '"\SQLServer:Plan Cache(*)\*"'
    )
    if ($InstanceName -eq 'MSSQLSERVER') {
        # This is for the default SQL Server instance
        $logmanCommand = "logman create counter MS_perf_log -f bin -c $counters"

    }
    else {
        # This is for a named SQL Server instance
        $InstanceName = "MSSQL`$$InstanceName"
        $counters = $counters -replace 'SQLServer', $InstanceName
        $logmanCommand = "logman create counter MS_perf_log -f bin -c $counters"

    }

    $Location = $Location + '\MS_perf_log.blg'
    $logmanCommand += " -si 00:00:01 -max 500 -o $Location"

    Start-Process -FilePath "cmd.exe" -ArgumentList "/c $logmanCommand" -Verb RunAs -Wait

}

# Function to start the collector
function Start-PerfCounterLog {
    Start-Process -FilePath "cmd.exe" -ArgumentList "/c logman start MS_perf_log" -Verb RunAs -Wait
}

# Function to stop and delete the collector
function Stop-Delete-PerfCounterLog {
    Start-Process -FilePath "cmd.exe" -ArgumentList "/c logman stop MS_perf_log" -Verb RunAs -Wait
    Start-Process -FilePath "cmd.exe" -ArgumentList "/c logman delete MS_perf_log" -Verb RunAs -Wait
}

# Create folder if not exists - update the file path as per your environment
$folderPath = $Location
if (-not (Test-Path $folderPath)) {
    New-Item -Path $folderPath -ItemType Directory
}

# Create performance counter log
Create-PerfCounterLog -InstanceName $InstanceName -Location $Location

# Start the collector
Start-PerfCounterLog

# If the event has occurred again and captured, then stop the collector
# Uncomment below line when you want to stop and delete the collector
# Stop-Delete-PerfCounterLog

Уменьшение или предотвращение больших дампов памяти процесса SQL Server или кластера

В некоторых случаях процесс SQL Server может столкнуться с исключениями, утверждениями, проблемами планировщика и т. д. В таких случаях SQL Server активирует SQLDumper.exe процесс по умолчанию, чтобы создать мини-модуль с косвенной памятью. Однако если создание дампа занимает много времени, процесс SQL Server перестает отвечать, что может вызвать время ожидания аренды. Распространенные причины для дампа памяти занимает много времени:

  • использование большого объема памяти в процессе
  • подсистема ввода-вывода, в которой записывается дампа, медленная
  • Параметр по умолчанию был изменен с мини-дампа на отфильтрованный или полный дампа

Чтобы избежать истечения времени ожидания аренды, выполните следующие действия в системах группы доступности:

  • Увеличьте время ожидания сеанса, например 120 секунд для всех реплик
  • Изменение автоматической отработки отказа всех реплик на отработку отказа вручную
  • Увеличьте значение LeaseTimeout до 60 000 мс (60 секунд) и измените HealthCheckTimeout на 90 000 мс (90 секунд)

Дополнительные сведения см. в статье "Использование средства Sqldumper.exe для создания файла дампа в SQL Server".

Проверка конфигурации виртуальной машины для чрезмерной подготовки

Если вы используете виртуальную машину, убедитесь, что вы не перепроектируете или перезаключаете ЦП и ресурсы памяти. Превышение производительности ЦП или памяти может привести к нехватке ресурсов гостевой ОС и показать те же проблемы, описанные ранее— высокая загрузка ЦП и низкая память. Часто если вы просматриваете вещи в гостевой ОС, объясняя, почему вы работаете с вычислительными ресурсами, трудно, потому что вещи происходят за пределами самой виртуальной машины. Переполнение ресурсов может вызвать временные остановки обработки, которые, скорее всего, вызывают время ожидания аренды. Дополнительные сведения о том, как устранять перезагрузку, см. в статье "Устранение неполадок с производительностью виртуальных машин ESX/ESXi" (2001003) и Виртуализация — переполнение памяти и обнаружение ее в виртуальной машине.

Проверка миграции или резервного копирования виртуальной машины

Hyper-V, VMware и другие решения виртуальных машин предоставляют возможность перемещения виртуальных машин между узлами (миграция Hyper-V Live и VMware vMotion). В большинстве случаев эти технологии обеспечивают почти мгновенное перемещение. Однако при наличии узких мест в сети или хост-компьютере эти миграции могут быть длительными, что приводит к тому, что виртуальная машина находится в приостановленном, нерабочемом состоянии. Это может привести к истечению срока действия аренды между SQL Server и процессами кластера. Прежде чем устранять проблемы с миграцией виртуальных машин, прежде чем устранять проблемы с временем ожидания аренды.

Решения для резервного копирования виртуальных машин также могут привести к простою виртуальных машин. Если резервное копирование виртуальной машины выполняется в ос узла или любое аналогичное обслуживание выполняется на хост-компьютере, который занимает много времени, они могут привести к проблеме времени ожидания аренды. Причина заключается в том, что в то время как часы тикают, процессы SQL Server и кластера не могут взаимодействовать друг с другом на приостановленной виртуальной машине. Прежде чем изучить проблемы с временем ожидания аренды, необходимо устранить любые задержки, вызванные резервными копиями виртуальных машин или другим обслуживанием.