К именам файлов бэкапов (SQL Server) приписываю дату создания, например: db_backup_full_20060815.bak. Нужно программно удялять файлы бэкапов с датой, которая старше текущей на заданное в процедуре количество дней. Сейчас я это делаю с помощью команды del, но очень некрасивым способом :


где @retaindays - заданное количество дней, после которых архивные копии можно удалять. Естественно, что таким способом я могу удалить только те файлы , которые строго соответствуют условию [текущая дата] - [заданное количество дней]. Если же бэкап по каким-то причинам не прошел (например, из-за ошибок сети), то на следующий день запущенная процедура нужных файлов для удаления уже не увидит (не найдет по дате, зашитой в имя файла), что, естественно, может повлечь за собой переполнение диска устаревшими архивами. Следовательно, нужно как-то реализовать такой нехитрый алгоритм.


С уважением, kkv

Biz©а чо, в сиквел-сервере нет штатной процедуры для этого ? апупеть ...В SQL Server есть штатное средство бэкапирования, здесь же стоит задача управлять файлами на уровне операционной системы.

ScareCrowсиквелу можно указать - сколько хранить быкапы.. Можно. Только при этом все файлы будут накладываться друг на друга и перезатираться будут не самые ранние, а сразу все бэкапы из одного устройства . Там просто указывается опция WITH INIT (с перезаписью) и RETAINDAYS (через какое количество дней это можно сделать).

С уважением, kkv

GeT, спасибо, буду пробовать.

С уважением, kkv

Anatoly Podgoretsky kkv Biz©[quot ScareCrow]сиквелу можно указать - сколько хранить быкапы..
Можно. Только при этом все файлы будут накладываться друг на друга и перезатираться будут не самые ранние, а сразу все бэкапы из одного устройства . Там просто указывается опция WITH INIT (с перезаписью) и RETAINDAYS (через какое количество дней это можно сделать).
Сам придумал или тебе кто то это сказал?
И BOL читал, и на практике проверял. Так что полегче насчет "придумал".
автор INIT

Specifies that all backup sets should be overwritten , but preserves the media header. If INIT is specified, any existing backup set data on that device is overwritten.

The backup media is not overwritten if any one of the following conditions is met:

All backup sets on the media have not yet expired. For more information, see the EXPIREDATE and RETAINDAYS options.

The backup set name given in the BACKUP statement, if provided, does not match the name on the backup media. For more information, see the NAME clause.
Use the SKIP option to override these checks. For more information about interactions when using SKIP, NOSKIP, INIT, and NOINIT, see the Remarks section.

Note If the backup media is password protected, SQL Server does not write to the media unless the media password is supplied. This check is not overridden by the SKIP option. Password-protected media may be overwritten only by reformatting it. For more information, see the FORMAT option.

В догонку. Это вполне стандартная задача перезатирать старые бэкапы, но при этом внутри устройства бэкапа нельзя удалить отдельный бэкап . Поэтому и разрабатываются подобные административные процедуры. Кстати, порыскал по форуму и нашел практически свою задачу - backup и время хранения .

С уважением, kkv

Green22 kkv
Чем вам ваше старое решение не нравится???
А тем и не нравится что удаление файлов происходит не по временному диапазону, а по точному соответствию имени файла (см. 1-й пост топика).

С уважением, kkv

Biz©любая достойная система бэкапа имеет средства для очистки всего старого, што уже не входит в задаваемый ретеншн период ...
Давайте не будем обсуждать достоинства и недостатки SQL Server, ибо это тема даже не для соответствующего форума, а для форума "Сравнение СУБД". Просто это такая политика - бэкапы делаются на устройства и если указывать опцию with noinit, то файлы будут добавляться туда до тех пор пока место на диске не закончится. Поэтому и сделана опция with init которая в сочетании с опциями retaindays, expiredate, skip, noskip препятствует (или наоборот, позволяет обходить это ограничение) перезаписывать все бэкапы из одного устройства через какой-то определенный промежуток времени. Предполагается, что АБД периодически архивирует бэкапы куда-то на внешние носители, а потому перезатирать нужно сразу все бэкапы из одного устройства. Еще раз повторюсь - внутри одного устройства нельзя удалить отдельный бэкап . Либо все, либо ничего. Рассматривать этот факт как недостаток или, напротив, как достоинство системы, (фактор, дисциплинирующий АБД) - это предмет длительной дискуссии. Если же вы еще раз внимательно перечитаете этот постинг с соответствующими ссылками, то поймете почему подобная задача периодически возникает у администраторов баз данных.

Biz© kkvТолько при этом все файлы будут накладываться друг на друга и перезатираться будут не самые ранние, а сразу все бэкапы из одного устройства. Там просто указывается опция WITH INIT (с перезаписью) и RETAINDAYS (через какое количество дней это можно сделать).
вобще-то даже в африке INIT - это "инициализация", т.е. то што вы и имеете - удаление всего содержимого ... нет ли там чеголибо типа with replace, with overwrite и т.п. ?
Опция with replace, разумеется, имеется, только она относится не к backup database, а к команде restore database, что в данном случае "ария из совершенно другой оперы".

P.S. И вообще, разговор изначально шел не о достоинствах или недостатках SQL Server, а о способах удаления устаревших файлов с помощью команд операционной системы. В принципе, я уже приблизительно понял идею как это реализовать, просто сейчас у меня эта задача, находится, как говорится, в фоновом режиме.

С уважением, kkv

Anatoly PodgoretskyЕсть, Maintnance Plan - именно он занимается удалением старых архивов базы и логов и работает нормально, у меня годами в папке архивы за две последнии недели, никакиъ ручек и скриптов. MS SQL сервер все делает сам и делает великолепно, помнит всю историю архивов. Удалять с помощью файловых операций находится на грани непрофессионализма. Убеждать автора не собираюсь, каждый ССЗБ
Это все замечательно, как вы сказали, работает, спорить не буду. Но только в случае статичности системы. В реальной же жизни базы иногда переезжают с одного сервера на другой, появляются новые базы, да и сами планы резервного копирования/восстановления тоже отнюдь не постоянны. Для каждой базы перенастраивать свой план исполнения? Кому как, а мне лично больше по душе написать один раз хранимую процедуру, в которую помимо бэкапов вложить еще кучу всякой другой сопутствующей работы и просто из джобов автоматически ее вызывать с соответствующими параметрами. Это особенно актуально тогда, когда само количество администрируемых баз отнюдь не три-пять, а гораздо больше.

С уважением, kkv

Anatoly Podgoretsky... кроме того даже в случае файловых операций, сервер их в состоянии выполнять, без всяких бат файлов.
Вот ты прицепился к сиквелу! Да причем тут SQL Server вообще?! Нужно было проще поставить вопрос, а именно спросить что-то типа: "мне надо программно удалять файлы старше некоторой даты, покажите набор команд из консоли", при этом не уточняя для чего именно и в какой среде. Разговор идет не о возможностях сиквела, а об несколько усложненных способах работы с файлами средствами самой операционной системы. Подобные задачи могут возникнуть абсолютно в любой СУБД или при программировании абсолютно на любом языке. И все они решаются путем обращения к командам ОС, в данном случае SQL Server просто посылает команду del на консоль (xp_cmdschell). Сервер баз данных не умеет, да и не должен уметь выполнять работу операционной системы, у него своей работы хватает. Для того и было разработано средство обращения сервера к командой строке xp_cmdschell, ведь все равно файловые операции будет выполнять именно ОС на понятном ей языке, а вовсе никакой не SQL Server (Oracle, DB2, Access, FoxPro и т.д.). К тому же речи о бат-файлах не было вообще, я говорил о хранимой процедуре, это далеко не одно и тоже. А почему мне нужен именно такой подход, а не через Maintenance Plan я уже объяснял выше, но попробую чуточку добавить. Вот, например, в моем случае бэкапы делаются трех видов: полный, дифферинциальный и журнала транзакций. При удалении устаревшего полного бэкапа нужно автоматически удалять и все последующие дифферинциальные бэкапы и бэкапы логов транзакций (без полного бэкапа это просто лишние файлы на диске, воспользоваться ими уже будет невозможно). Причем нужно не просто удалить все последующие дифы и логи, но до первого сделанного full-бэкапа. Можно ли такое реализовать с помощью Maintenance Plan? Сильно сомневаюсь... А бэкапчики у меня будь здоров, по 130 Гб, да и диффы с логами тоже нельзя сквозь пальцы рассматривать - в сумме по ним набегает порядка 80 гигов. Если все это вовремя не удалять, то никаких дисков не напасешься. И это только один пример, могу привести еще много причин по которым я не использую Maintenance Plan, но это уже совершенно другая тема и для другого форума. Maintenance Plan - отличный инструмент администрирования, но далеко не всегда и далеко не все задачи можно решать с его помощью. Целесообразность его применения нужно рассматривать в каждом конкретном случае.

Anatoly PodgoretskyМне кажется, что ты неправильным путем идешь.Когда кажется - креститься надо. Предложи тогда свой, правильный путь, а не только голословно навешивая ярлыки непрофессионализма только лишь потому что с помощью Maintenance Plan "никаких ручек и скриптов".

Anatoly PodgoretskyТы бы все таки задал этот в форуме по MS SQL там подскажут более оптимальный путь.Выше я уже приводил ссылку где разбиралась аналогичная задача. Даже не просто аналогичная, а практически та же самая. Так что ответ на свой вопрос я уже получил, заодно и почерпнув новые знания. Нашел я, правда, этот топик уже после того, как создал свой. Видимо там тоже идут неправильным путем...

С уважением, kkv

Мне нужно было просто понять саму идею как с помощью команд ОС удалить старые файлы. Можно, конечно, написать расширенную ХП на каком-нибудь языке, можно даже запускать какой-то левый скрипт (потом постоянно мучиться с каталогами), можно. Но только зачем? Гораздо проще запихнуть эти команды в тело хранимки и не париться. А насчет абстрактности вопроса как-то не подумал, что начнут обсуждать не мой вопрос, а рассматривать способы как это сделать по-другому.

С уважением, kkv

Biz©off-top: очередной раз убеждаюсь, што пока ещё "ф топку этот m$ сиквел" ...:)
Каждый видит только то, что он хочет видеть.

С уважением, kkv

Biz©не смешите мои тапочки расхожими измышлениями ... это мысли администратора о продукте с неудовлетворительными штатными средствами администрирования ...Я уже говорил выше, что дискуссии о достоинствах и недостатках системы это в "Сравнение СУБД". На тему сравнения SQL Server и Oracle разбито столько копий, что хватит еще ни на одно поколение программистов и администраторов.

Biz©кста, совсем не пнял столь неуёмное желание запихнуть некую последовательность команд оси внутрь базы ... эт примерно как некоторые узеры додумываются держать графические файлы в вордовских документах ...
ну да лана ... эт ваши проблемы ...
Совершенно неуместная аналогия. Пишется самая обыкновенная системная административная процедура, на вход которой поступают такие параметры как имя базы данных, файловый каталог, количество дней, тип бэкапирования и т.д. Внутри самой процедуры кроме бэкапирования выполняется дополноительно куча всякой мелкой сопутствующей работы. Так как подобная последовательнось действий входит в план администрирования почти всех баз, то имеется самый прямой смысл использовать такой способ, особенно тогда, когда само количество таких баз становится внушительным. У меня при таком подходе все базы совершенно спокойно могут переезжать с места на место, да и вообще настройки становятся очень гибкими по отношению к разным изменениям. И способ этот, к вашему сведению, придуман не мной, а описан в очень умных книжках по администрированию SQL Server. Так что делать скоропалительные выводы о качестве системы и методах работы с нею, при этом не утрудив себя углублением в суть вопроса, - это не мои, а именно ваши проблемы.

С уважением, kkv

Anatoly PodgoretskyУ тебя единственная особенность, это миграция баз, вероятнее всего при этом у тебя происходит потеря истории, это единственная на мой взгляд причина для отказа от штатных средст. Ни размер, ни количество не могут являться основание, удаление файлов не ресурсо емкая, и очень быстрая операция для ОС.
Я не ошибаюсь? Или что то еще опустил?
В данном конкретном случае меня больше волнует программное удаление не только устаревших full-бэкапов, но и удаление соответствующих этому бэкапу диффов и логов.

Anatoly PodgoretskyА вот потеря истории сводит на нет возможности сервера по данной части.
Потеря истории может как-то сказаться на процессе восстановления баз? Я ведь восстанавливаю не из истории бэкапов, а из самих бэкапов.

--null--так вроде есть в MS SQL Server доступ к OLE - можно с помощью sp_OACreate
получить доступ к FileSystemObject и проделать все необходимые действия. Наверное :-)Согласен полностью, буду двигаться и в этом направлении.