Я помітив, що деякі DBA перезапускають 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.
Для мене це стосується сценарію, коли всі компетентні, і ви можете все виправити.
Я не DBA. Я архітектор програмного забезпечення, і це стосується створення цілих схем баз даних з нуля, і, на жаль , робота з сторонніми базами даних, над якими я абсолютно НЕ контролюю.
Люди, які створили та підтримують одну з наших головних сторонніх баз даних, ледве зробили її функціональною.
Я вже згадував, що я також не є експертом з питань безпеки або інженером мережі?
Для мене тоді виникає питання: чи варто перезапускати SQL Server частіше, ніж кожні 3 місяці?
Планування Restarts для обіцянки додаткового дюйма продуктивності - це як танці під дощем.
Можливо, воно прийде, можливо, не стане, але ви точно не знатимете, що спричинило дощ.
Я не кажу , що ви , як ніколи не потрібно перезапустити його , щоб усунути проблему , або перевірити отказоустойчивого, але зробити є проблеми з плануванням перезапускає , щоб невідому проблему продуктивності від випадкового виникнення.
Тільки виключення з цього правила, якщо ви керуєте шахрая третій партії бази даних , де перезавантаження щотижня або дві , здається, єдиний спосіб зберегти це працює , і ви не можете виправити або навіть доторкнутися до неї.
Вже тоді вам слід шукати виправлення, ділитися ними з власником і піднімати пекло, поки це не буде вирішено.