Столкнулся вчера с неожиданным для меня поведением бэкапов mssql. Есть сервер баз данных, который регулярно бэкапится по следующей схеме:
◽ раз в неделю полный бэкап
◽ раз в день дифференциальный бэкап
Все эти бэкапы хранятся 4 недели и автоматически удаляются. Настроено штатно через консоль управления сервером с помощью планов обслуживания. То есть никакой экзотики, все очень просто. Периодически делались восстановления из полных копий, все было в порядке.
И тут человек, который со всем этим работает, пишет мне и просит помочь восстановить вчерашний дифференциальный бэкап. У него не получается, выходит ошибка. При этом полный субботний бэкап корректный, база восстанавливается из него.
Подключаюсь и пытаюсь восстановиться. Полный реально рабочий, а вот когда на него льешь diff бэкап, он ругается, говорит вот что:
This differential backup cannot be restored because the database has not been restored to the correct earlier state
Суть в том, что ему не нравится этот полный бэкап и на него он не хочет восстанавливаться. Тут я как-то сразу догадался загрузить в мастер восстановления вообще все бэкапы за последние 4 недели для этой базы и выбрал там восстановление вчерашней копии. Визард автоматом выбрал полный бэкап трехнедельной давности и вчерашний diff. И успешно все восстановил.
А дальше я стал думать и гадать, почему diff бэкапы берут за основу старый полный бэкап, хотя после него уже делались другие полные бэкапы. Я с mssql серверами вообще плохо знаком и работаю с ними по старой памяти в контексте работы 1С. Погуглил англоязычный инет и нашел ответ.
Как понял ситуацию в итоге я. После того, как сделан полный бэкап, в базе обновляется DatabaseBackupLSN. На этот номер LSN ориентируется diff бэкап и берет отсчет от него. Таким образом выстраивается корректная цепочка бэкапов. На этом сервере периодически руками делали полные бэкапы и забирали их, таким образом обновлялась метка DatabaseBackupLSN, но полного бэкапа на сервере не было. Цепочка рвалась. Из-за этого diff бэкап брал более старую метку, когда цепочка без разрывов.
Чтобы таких проблем не было, для одиночных бэкапов надо ставить параметр Copy-only или Архивная копия для копирования в русском переводе. Более подробно все это разъяснено тут - https://dba.stackexchange.com/questions/45876/difference-between-full-backup-and-copy-only-full-backup Я мог что-то не так понять или объяснить, но общий смысл ясен. Проблема в ручных бэкапах, которые делались на сервере и нарушали цепочку выстроенных бэкапов.
#mssql
◽ раз в неделю полный бэкап
◽ раз в день дифференциальный бэкап
Все эти бэкапы хранятся 4 недели и автоматически удаляются. Настроено штатно через консоль управления сервером с помощью планов обслуживания. То есть никакой экзотики, все очень просто. Периодически делались восстановления из полных копий, все было в порядке.
И тут человек, который со всем этим работает, пишет мне и просит помочь восстановить вчерашний дифференциальный бэкап. У него не получается, выходит ошибка. При этом полный субботний бэкап корректный, база восстанавливается из него.
Подключаюсь и пытаюсь восстановиться. Полный реально рабочий, а вот когда на него льешь diff бэкап, он ругается, говорит вот что:
This differential backup cannot be restored because the database has not been restored to the correct earlier state
Суть в том, что ему не нравится этот полный бэкап и на него он не хочет восстанавливаться. Тут я как-то сразу догадался загрузить в мастер восстановления вообще все бэкапы за последние 4 недели для этой базы и выбрал там восстановление вчерашней копии. Визард автоматом выбрал полный бэкап трехнедельной давности и вчерашний diff. И успешно все восстановил.
А дальше я стал думать и гадать, почему diff бэкапы берут за основу старый полный бэкап, хотя после него уже делались другие полные бэкапы. Я с mssql серверами вообще плохо знаком и работаю с ними по старой памяти в контексте работы 1С. Погуглил англоязычный инет и нашел ответ.
Как понял ситуацию в итоге я. После того, как сделан полный бэкап, в базе обновляется DatabaseBackupLSN. На этот номер LSN ориентируется diff бэкап и берет отсчет от него. Таким образом выстраивается корректная цепочка бэкапов. На этом сервере периодически руками делали полные бэкапы и забирали их, таким образом обновлялась метка DatabaseBackupLSN, но полного бэкапа на сервере не было. Цепочка рвалась. Из-за этого diff бэкап брал более старую метку, когда цепочка без разрывов.
Чтобы таких проблем не было, для одиночных бэкапов надо ставить параметр Copy-only или Архивная копия для копирования в русском переводе. Более подробно все это разъяснено тут - https://dba.stackexchange.com/questions/45876/difference-between-full-backup-and-copy-only-full-backup Я мог что-то не так понять или объяснить, но общий смысл ясен. Проблема в ручных бэкапах, которые делались на сервере и нарушали цепочку выстроенных бэкапов.
#mssql
На прошлой неделе прочитал достаточно интересную статью - Почему PostgreSQL не лучше MS SQL, где автор сравнил PostgreSQL и MSSQL для использования с 1С. Она мне показалась интересной, поэтому решил сделать для вас выжимку основной информации оттуда, как я её понял!
◽ MSSQL - 20 лет сотрудничества с 1С. К ней все привыкли, у неё лучшие интерфейсы для управления БД с низким порогом входа как для разработчиков, так и поддержки.
◽ PostgreSQL - настройки в текстовом файле, командная строка Linux, скрипты для обслуживания и бэкапов. Всё это надо изучать, разбираться.
◽ В среднем на MSSQL 1С работает быстрее. Большинство запросов выполняются примерно одинаково. Но бывает так, что на Postgres запросы выполняются значительно медленнее, но обратные ситуации не наблюдаются. То есть Postgres в лучшем случае будет работать так же, разработка под эту БД более требовательна к качеству кода запросов. Ошибок не прощает.
◽ PostgreSQL более экономично относится к памяти, умеет отдавать неиспользованную память обратно системе. MSSQL пожирает всю память, что есть и хочет еще больше.
◽ Бесплатные версии MSSQL и PostgreSQL не сравнимы по функционалу. Последняя уделывает Express версию MSSQL по всем параметрам. Так что по деньгами PostgreSQL будет значительно дешевле, либо вообще бесплатно.
◽ Стоимости MSSQL Enterprise и Postgres Pro Enterprise на одном и том же числе пользователей и железе будут отличаться примерно в 3 раза в пользу Postgres.
◽ У Postgres на Windows много недостатков. Лучше ставить Linux.
◽ У Postgres Pro хорошая русскоязычная поддержка. Реально решают проблемы. Помогают разобрать тормоза конкретных запросов.
Автор статьи - Антон Дорошкевич, руководитель ИТ в компании «Инфософт», в Новосибирске. Является сертифицированным экспертом по эксплуатации PostgreSQL. Уровень сертификата «Эксперт». В течение последних 15-ти лет является эксплуататором больших многокластерных систем на тысячи пользователей и сотни баз – что на MS SQL, что на PostgreSQL.
#1с #postgresql #mssql
◽ MSSQL - 20 лет сотрудничества с 1С. К ней все привыкли, у неё лучшие интерфейсы для управления БД с низким порогом входа как для разработчиков, так и поддержки.
◽ PostgreSQL - настройки в текстовом файле, командная строка Linux, скрипты для обслуживания и бэкапов. Всё это надо изучать, разбираться.
◽ В среднем на MSSQL 1С работает быстрее. Большинство запросов выполняются примерно одинаково. Но бывает так, что на Postgres запросы выполняются значительно медленнее, но обратные ситуации не наблюдаются. То есть Postgres в лучшем случае будет работать так же, разработка под эту БД более требовательна к качеству кода запросов. Ошибок не прощает.
◽ PostgreSQL более экономично относится к памяти, умеет отдавать неиспользованную память обратно системе. MSSQL пожирает всю память, что есть и хочет еще больше.
◽ Бесплатные версии MSSQL и PostgreSQL не сравнимы по функционалу. Последняя уделывает Express версию MSSQL по всем параметрам. Так что по деньгами PostgreSQL будет значительно дешевле, либо вообще бесплатно.
◽ Стоимости MSSQL Enterprise и Postgres Pro Enterprise на одном и том же числе пользователей и железе будут отличаться примерно в 3 раза в пользу Postgres.
◽ У Postgres на Windows много недостатков. Лучше ставить Linux.
◽ У Postgres Pro хорошая русскоязычная поддержка. Реально решают проблемы. Помогают разобрать тормоза конкретных запросов.
Автор статьи - Антон Дорошкевич, руководитель ИТ в компании «Инфософт», в Новосибирске. Является сертифицированным экспертом по эксплуатации PostgreSQL. Уровень сертификата «Эксперт». В течение последних 15-ти лет является эксплуататором больших многокластерных систем на тысячи пользователей и сотни баз – что на MS SQL, что на PostgreSQL.
#1с #postgresql #mssql
Столкнулся на днях с неприятной задачей. В какой-то момент перестали литься бэкапы с MSSQL сервера. Начал выяснять в чём дело. Оказалось, изменили имя сервера, на котором стоял одиночный инстанс MSSQL. Сервер перезагрузили, всё запустилось, 1С заработал. Посчитали, что дело сделано.
Но на самом деле нифига не сделано. Нельзя просто взять и переименовать компьютер, на котором стоит MSSQL сервер. Нужно выполнить переименование и внутри него. Инструкция от microsoft по этой теме. Но она не решает всех проблем.
На сервере отвалились все планы обслуживания. Я и так, и сяк пытался их починить, но не смог. Они используют свои подключения к серверу по имени, которые так просто не изменить. Надо лезть в базу msdb и запросами менять имя со старого на новое. Я решил не рисковать и пересоздал все задания.
Но и этого оказалось мало. Надо было еще в пользователях отредактировать дефолтного админа, который имеет имя SERVER-OLD/Администратор. После этого новые планы заработали.
Написал это, чтобы вы не занимались подобной ерундой. Не надо переименовывать сервера под MSSQL. Либо оставьте как есть, либо сделайте миграцию. На свете куча отважных сисадминов, которые просто берут и делают. Даже бэкапы не сняли перед процедурой.
#mssql
Но на самом деле нифига не сделано. Нельзя просто взять и переименовать компьютер, на котором стоит MSSQL сервер. Нужно выполнить переименование и внутри него. Инструкция от microsoft по этой теме. Но она не решает всех проблем.
На сервере отвалились все планы обслуживания. Я и так, и сяк пытался их починить, но не смог. Они используют свои подключения к серверу по имени, которые так просто не изменить. Надо лезть в базу msdb и запросами менять имя со старого на новое. Я решил не рисковать и пересоздал все задания.
Но и этого оказалось мало. Надо было еще в пользователях отредактировать дефолтного админа, который имеет имя SERVER-OLD/Администратор. После этого новые планы заработали.
Написал это, чтобы вы не занимались подобной ерундой. Не надо переименовывать сервера под MSSQL. Либо оставьте как есть, либо сделайте миграцию. На свете куча отважных сисадминов, которые просто берут и делают. Даже бэкапы не сняли перед процедурой.
#mssql
