Бэкап

После того, как на каталог с файлами бэкапов поставил атрибут "сжатый" (Win2000AS SP3), 2000-ый SQL с SP3 стал выдавать ошибку в job-history:
"Executed as user: domen\admin. Write on 'C:\BU\baza' failed, status = 33.
See the SQL Server error log for more details. [SQLSTATE 42000] (Error 3202)
BACKUP DATABASE is terminating abnormally. [SQLSTATE 42000] (Error 3013).
The step failed."
А если утром ручками запутитть job, то онв роде проходит. Посмотрел в планировщике - в этот промежуток времени ночью ничего такого, что могло бы мешать бэкапу не делается. Не думаю, что бэкап нельзя делать в сжатые папки. Или...?

status = 33 означает

"The process cannot access the file because another process has locked a portion of the file."
Т.е. именно компрессия и мешает бэкапу, т.к. происходит в фоновом режиме. И в планировщике разумеется фоновая деятельность не отображается.
Вывод - если уж так хочется чтобы бэкап занимал меньше места, то делайте сжатие уже готового файла бэкапа.

А почему же тогда он проходит, если ручками запускать?

вообще сомнительно, по 2-м причинам:
- комперессия - это совершенно "прозрачный" механизм нтфс, гарантированный и про подобные претензии (другой процесс мешает сжать) слышу в первый раз
- я стандартно ставлю этот атрибут на папки бэкапа, иногда на папки с данными (!!),, а также атрибут шифрования на папки с данными, но с такой проблемой не сталкивался

имеются в виду папки сиквелсервера data и backup

Скрость бэкапирование не постоянная, нагруэка на систему тоже. Т.е. объем данных передаваемых на компрессию перед записью на диск такой, что система справляется с его обработкой.

неубедительно ...
если "система справляется с его обработкой" - она просто тормозит при этом...
нтфс - многопоточная фс, и процессы сжатия и криптования там совершенно никак не могут повлиять на течение других процессов, единственнное - только притормозить их
вы ставите под сомнение наверно самое большое достижение в виндеНТ - ее файловую систему! :))

2[-==-]
а у тебя случаем один бэкап на другой в один и тот же файл по времени не накладывается? - просто других объяснений придумать трудно, если 33 ошибка - это действительно то, что Glory написал

если "система справляется с его обработкой" - она просто тормозит при этом...
Вот вот, именно что "просто тормозит при этом". А BACKUP не будет ждать систему "вечно".

имелось в виду: если "система справляется не с его обработкой" ...

>Вот вот, именно что "просто тормозит при этом". А BACKUP не будет ждать систему "вечно".<
вечно не нужно, но на дискету например ждет, на сетевые папки независимо от загрузки сети - ждет ... вообще, неужели где-то есть требования к скорости устройства для бэкапа?

ок, у тебя работает бэкап в сжатые папки? если да, то у меня работает, у тебя работает, у другого человека не работает ... полная недетерминированность какая-то, и это уже после СП3 !

и опять же вопрос автора - "А почему же тогда он проходит, если ручками запускать?" - при этом совсем остается без ответа

нее, причина в другом ...

ок, у тебя работает бэкап в сжатые папки?

У меня не работает. При базе в 55Гб в произвольный момент бэкапа происходила именно эта ошибка (было и несколько случаев успешного завершения). После отключения сжатия ошибка пропала.

Есть два НО.
1. Диск на который писался бэкап был IDE ATA66. Правда на мой взгляд пропускная способность диска тут все таки не причем.
2. Возможно на работу с компрессованным диском влияют какие-то установки в реестре и можно каким-то образом увеличить скорость работы системы с такими дисками.

и опять же вопрос автора - "А почему же тогда он проходит, если ручками запускать?" - при этом совсем остается без ответа
Это вопрос из разряда почему время выполнения запроса разное в разное время суток.

55гб! к сожалению у меня нет сейчас возможности поработать с бд такого размера, да и тест бы видимо весьма затянулся

но вот то, что процесс компрессии может конфликтовать с записью файла бэкапа - поверить трудно, поскольку сжатые файлы бд работают, а там, сам понимаешь, постоянно идет запись/чтение, и при том все сжимается/разжимается на лету

>о вопрос из разряда почему время выполнения запроса разное в разное время суток.<
нет, если это происходит стабильно и устойчиво, то это закономерность, а возможно и ключ к решению вопроса ... а МС сайт/саппорт не терзали на эту тему?