Неделю назад разжились новым сервером. На нем крутится MS SQL и сервер 1С.
Главное отличие от старого сервера - довольно большой объем оперативной памяти и SSD диски.
Перенесли все базы со старого сервера. Работает заметно шустрее старого.
Но меня беспокоит один момент.
Вот есть базы, живые, рабочие, в них пользователи каждый день документы заносят, в них обновления ставятся, в общем, работа кипит. :)
А файлы на диске, в которых эти базы хранятся имеют дату последнего обновления, ну, например, 3 дня назад. Или неделю назад.
И MDF, и LDF.
Наверное, в теории это возможно, если MS SQL хватает RAM, чтобы туда все нужное загрузить и с этим работать в памяти.
Как-то несколько смущает все вот это. А если сбой какой?
Тем более, что сервер перезагружался 6 апреля - насколько я понимаю, сервер должен был дампы на диск сбросить, и у всех рабочих баз дата последнего изменения должна самое раннее на 6 апреля выставиться. Но нет, там есть файлы и с 1 апреля, и с 3 апреля, и с 5, и с 6.
Есть, конечно, и более свежие, в т.ч. от сегодняшнего числа.
Вопрос: насколько нормально такое поведение?
Сервер реально сбрасывает данные в файлы, но просто почему-то не обновляет атрибут LastWriteTime?
Есть ли вообще какой-то параметр настройки MS SQL, который регламентирует частоту сброса данных в файлы?
Главное отличие от старого сервера - довольно большой объем оперативной памяти и SSD диски.
Перенесли все базы со старого сервера. Работает заметно шустрее старого.
Но меня беспокоит один момент.
Вот есть базы, живые, рабочие, в них пользователи каждый день документы заносят, в них обновления ставятся, в общем, работа кипит. :)
А файлы на диске, в которых эти базы хранятся имеют дату последнего обновления, ну, например, 3 дня назад. Или неделю назад.
И MDF, и LDF.
Наверное, в теории это возможно, если MS SQL хватает RAM, чтобы туда все нужное загрузить и с этим работать в памяти.
Как-то несколько смущает все вот это. А если сбой какой?
Тем более, что сервер перезагружался 6 апреля - насколько я понимаю, сервер должен был дампы на диск сбросить, и у всех рабочих баз дата последнего изменения должна самое раннее на 6 апреля выставиться. Но нет, там есть файлы и с 1 апреля, и с 3 апреля, и с 5, и с 6.
Есть, конечно, и более свежие, в т.ч. от сегодняшнего числа.
Вопрос: насколько нормально такое поведение?
Сервер реально сбрасывает данные в файлы, но просто почему-то не обновляет атрибут LastWriteTime?
Есть ли вообще какой-то параметр настройки MS SQL, который регламентирует частоту сброса данных в файлы?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
вот из-за такой логики большинство проблем и бывает в ИТ
я не понимаю, в чем проблема остановить продуктив, затем на тестовой базе провести эксперимент - выключить сервер и посмотреть на результат после включения
заодно узнаете необходимость в UPS, батарейке на контроллере или еще что то полезное
как вообще можно проектировать инфрактруктуру без практической проверки поведения
я не понимаю, в чем проблема остановить продуктив, затем на тестовой базе провести эксперимент - выключить сервер и посмотреть на результат после включения
заодно узнаете необходимость в UPS, батарейке на контроллере или еще что то полезное
как вообще можно проектировать инфрактруктуру без практической проверки поведения
(6) модель восстановления выбирается в зависимости от требований к отказоустойчивости, времени восстановления, объема допустимой к потери информации (косвенная корреляция есть с объемом базы и количеством пользователей) и квалификации админа
ну вот как вы сможете выбрать simple если например на резервный сервер будете передавать бэкапы логов механизма ?
simple говорит как бы за себя - он проще в настройке и понимании
recovery interval в той постановке как вы формулируете лучше от греха подальше вообще не трогать, т.е. 0 , так как вы ленитесь прочитать предоложительно, и этот параметр также значительно зависит от выше перечисленных факторов, если вы не можете потерять больше 5 минут данных, то как вы будете выставлять цифры типа 10?
не надо искать изотерические знание - прорабатывайте сначала решаемую задачу, ее ограничения, а затем ищите способы решения
и как правило при активном желании расширения кругозороа всё самой наладится
ну вот как вы сможете выбрать simple если например на резервный сервер будете передавать бэкапы логов механизма ?
simple говорит как бы за себя - он проще в настройке и понимании
recovery interval в той постановке как вы формулируете лучше от греха подальше вообще не трогать, т.е. 0 , так как вы ленитесь прочитать предоложительно, и этот параметр также значительно зависит от выше перечисленных факторов, если вы не можете потерять больше 5 минут данных, то как вы будете выставлять цифры типа 10?
не надо искать изотерические знание - прорабатывайте сначала решаемую задачу, ее ограничения, а затем ищите способы решения
и как правило при активном желании расширения кругозороа всё самой наладится
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот