Я заметил, что некоторые администраторы баз данных перезагружают SQL Server очень часто, иногда даже ночью. Я считаю, что они делают это, чтобы освободить память или, возможно, ускорить запросы. Я знаю, что после перезапуска планы запросов должны быть перекомпилированы, но даже с учетом того, что мне интересно, есть ли чистая выгода для этой практики.
Правда ли, что ежедневный перезапуск SQL Server заставляет его работать быстрее?
Ответы:
Перезапуск сервера, вероятно, является одним из самых вредных факторов для производительности. Это означает, что вы принудительно устанавливаете холодный кеш для данных, холодный кеш для планов запросов, и все внутренние кэши SQL Server также обнуляются в процессе. Не говоря уже о том, что, отбрасывая всю статистику, собранную в оперативной статистике DMV, вы уменьшаете свои шансы когда-либо успешно что-то исследовать.
Официальных указаний, подтверждающих эту практику, не существует, я никогда не видел, чтобы это упоминалось в каких-либо авторитетных работах с хорошей практикой, я никогда не слышал о том, чтобы авторитетный эксперт упоминал это как практику. Не делай этого.
В то время как другие ответы хороши, им не хватает важной части: файлового кэша Windows.
В 64-битной Windows нет ограничения на объем памяти, который Windows будет использовать для кэширования файлов. Windows может полностью истощить вашу систему памяти, и в этот момент вы начнете переключаться на диск. Это было задокументировано в нескольких местах:
Перезапуская SQL Server, вы заставляете SQL отказываться от памяти, тем самым позволяя Windows получать больше, и подкачка временно останавливается. SQL снова запустится при использовании памяти, близкой к нулю, и постепенно увеличится, а когда в памяти снова не хватит памяти, перезапуск временно поможет. Перезапуская всю ОС, вы также прекратите использование файлового кэша Windows.
Реальное исправление: прекратите копировать файлы с сервера Windows или ограничьте объем файлового кэша, используемого службой динамического файлового кэша, как описано в этих постах выше.
Если это ускоряет запросы, может быть задействован анализ параметров . Если план дерьма кэшируется и применяется к несоответствующим последующим вызовам, то чудо перезагрузки позволяет кэшировать общий / правильный план. Если это так, есть бесконечно лучшие способы исправления поведения, как указали другие. Но до тех пор, пока они не перестанут перезагружать блок, невозможно выполнить анализ первопричин.
Не следует перезапускать SQL Server, если вы не изменили свойства службы или не установили трассировки запуска, которые вы хотите вступить в силу немедленно.
Как @RemusRusanu указал много моментов, он очищает много кешей и заставляет SQL Server выполнять много ненужной работы при запуске .
Похоже, этот сервер не является выделенным сервером SQL Server / базой данных. Рекомендуется, чтобы рабочий сервер базы данных имел только одну цель - быть сервером базы данных. В этом случае вы должны выделить достаточно памяти и ресурсов для ОС и отдать все остальное SQL Server. Это приведет к тому, что вы не будете голодать ни для каких других приложений или серверных ролей.
Я согласен с мнением, что если вы все делаете правильно, вам может не потребоваться перезагрузка / перезапуск сервера MSSQL.
Для меня это относится к сценарию, где каждый компетентен, и вы можете исправить все.
Я не администратор базы данных. Я архитектор программного обеспечения и часть, которая включает в себя строительство всей базы данных схем с нуля , и, к сожалению , не работает с 3 - Databases партии , что я абсолютно NO контроль над.
Люди, которые создали и поддерживают одну из наших основных сторонних баз данных, едва сделали ее функциональной.
Я упоминал, что я тоже не эксперт по безопасности или сетевой инженер?
Для меня тогда возникает вопрос: должен ли я перезапускать SQL Server чаще, чем каждые 3 месяца?
Планирование перезапуска для обещания дополнительного дюйма производительности, как танцы для дождя.
Может быть, это придет, может быть, не будет, но вы не будете знать наверняка, что вызвало дождь.
Мне не нравится говорить, что вам НИКОГДА не нужно перезапускать его для устранения проблемы или проверки восстановления после сбоя, но у меня есть проблема с планированием перезапусков, чтобы предотвратить случайное возникновение неизвестной проблемы с производительностью.
Только исключение из этого правила, если вы управляете мошенника третьей партии базы данных , где перезагрузку каждую неделю или две , кажется, единственный способ сохранить это работает , и вы не можете исправить или даже прикоснуться к ней.
Даже тогда вы должны искать исправления, делиться ими с владельцем и поднимать ад, пока они не будут решены.