xp_cmdshell иногда я использую вот как.
У нас есть БД в простой модели восстановления. Ночью делается полный бэкап, а раз в час — разностный, но с режимом «присоединение (append)». Так вот, после полного бэкапа вызывается батник с помощью процедуры xp_cmdshell который удаляет разностный бэкап.
Во общем вот такой велосипед. Если что посоветуйте как лучше.
На некоторых да, на некоторых нет. К сожалению, ресурсы ограничены. И кое где БД находится в простой модели восстановления для уменьшения количества записей на диск.
придется сделать полный бэкапов базы (после перевода в полную модель восстановления)
Да забыл упомянуть, что фактически перевод происходит после полного бэкапа.
И сжатие при бэкапе (флаг with compression) дает нагрузку на процессор, поэтому нужно выбирать подходящее время для бэкапа.
Разумеется. Но конечный размер файла намного меньше. А из моего опыта, узкое горлышко зачастую именно дисковая подсистема.
Толи записать 35 ГБ (бэкап с сжатием на самой объемной БД) толи 180 ГБ — без сжатия.
А что вы подразумевали под «журнал транзакций перестает усекаться»?
После бэкапа журнала, место под транзакции попавших в бэкап должно помечаться свободным и перезаписываться. Следовательно, как минимум сразу после бэкапа прироста журнала быть не должно. Разумеется если нет массированной вставки. А если сразу же есть прирост, то я называю «журнал транзакций перестает усекаться»
Тоже расстроился. Хоть я и играл всего раз. Мне по душе были бы другие изменения в лотереи. К примеру:
Поднять минимальный уровень образования. Если сейчас можно со средним подавать, оставить только высшее, и, к примеру, технические специальности. Допустим я не вундеркиндер, но имею техническую вышку. Айтишник в душе. Широкий кругозор.
Все эти программы так или иначе ставят или свои службы или драйвера (для видео) к примеру. Выходит, что лучший способ это заблокировать установку служб, драйверов и т.д. Но это ручной метод.
А вы, я так понял ищите автоматический. На счет этого не знаю.
Попробую реализовать задачу встроенными средствами. По результатам отпишусь.
А чем не понравилось?
У нас есть БД в простой модели восстановления. Ночью делается полный бэкап, а раз в час — разностный, но с режимом «присоединение (append)». Так вот, после полного бэкапа вызывается батник с помощью процедуры xp_cmdshell который удаляет разностный бэкап.
Во общем вот такой велосипед. Если что посоветуйте как лучше.
На некоторых да, на некоторых нет. К сожалению, ресурсы ограничены. И кое где БД находится в простой модели восстановления для уменьшения количества записей на диск.
Да забыл упомянуть, что фактически перевод происходит после полного бэкапа.
Разумеется. Но конечный размер файла намного меньше. А из моего опыта, узкое горлышко зачастую именно дисковая подсистема.
Толи записать 35 ГБ (бэкап с сжатием на самой объемной БД) толи 180 ГБ — без сжатия.
После бэкапа журнала, место под транзакции попавших в бэкап должно помечаться свободным и перезаписываться. Следовательно, как минимум сразу после бэкапа прироста журнала быть не должно. Разумеется если нет массированной вставки. А если сразу же есть прирост, то я называю «журнал транзакций перестает усекаться»
А вы, я так понял ищите автоматический. На счет этого не знаю.