Версия для печати темы

Автор: Валери Четверг, 26 Марта 2009, 9:32

Проблема в следующем.
Есть 2 W2K3(x64)_SP2, на которых развёрнуты SQL2005(x64)_SP3.
На одном из них созданы задачи бэкапов, которые по шедулеру создают бэкапы на расшаренном диске второго сервера.(Аналогичная задача успешно крутиться на другой паре W2K3+SQL2000, 2005-будет заменой, переход не завершен)
С некоторых пор бэкап SQL2005 перестал проходить, а точнее файлы данных появляются на втором сервере, но в логах ошибки(ниже опишу).
Замечено, что если в месте назначения удалить файл *.dat и запустить задачу, бэкап пройдёт удачно.
Привожу подробности:
Сервер который запускает задачу задачу бэкапа базы NZZUP_test -NZDB2, бэкапится на NZDB, а вот, собственно задача :
BACKUP DATABASE [NZZUP_test] TO DISK = N'\\nzdb\MSSQL\Backup\NZZUP_test\chet\NZZUP_test_Chet.dat' WITH NOFORMAT, INIT, NAME = N'NZZUP_test-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO
В случае, если в папке \\nzdb\MSSQL\Backup\NZZUP_test\chet лежит уже ранее созданный файл NZZUP_test_Chet.dat в конце операции возникает ошибка(однако файл обновляется!)
в апликэйшен логах:

MSSQLSERVER ID18210
BackupDiskFile::RequestDurableMedia: failure on backup device '\\nzdb\MSSQL\Backup\NZZUP_test\chet\NZZUP_test_Chet.dat'.
Operating system error 64(error not found).
MSSQLSERVER ID3041
BACKUP failed to complete the command BACKUP DATABASE NZZUP_test.
Check the backup application log for detailed messages.

Если в задании бэкапа указать локальный диск nzdb2, то наличие старого файла *.dat не "мешает"

Толком по "Operating system error 64(error not found)."
нагуглить смог что-то вроде этого: http://www.sqlmonster.com/Uwe/Forum.aspx/sql-server/17004/Backup-Failure-Operating-system-error-64 , а именно:

The OS error 64 usually indicates the network problems.
Intermittent loss of connectivity to the share. To ensure that the
backups for the database are taken properly, I recommend you backup to
the local drive and then create a NT job to move the job to the share
upon completion of the SQL Backup. If the Nt copy job fails, then we
can be sure that the problem is because of network connectivity.

Однако, ведь, быкапы ранее создавались!
Это первое, а второе, на 2000-м скуле таких проблем не возникало.Тем более, что и микрософт не против сети: http://support.microsoft.com/kb/555128

Автор: Egor Четверг, 26 Марта 2009, 20:30

А если примапить папку?

Автор: Валери Пятница, 27 Марта 2009, 7:54

To Egor:
А как же рекомендация http://support.microsoft.com/kb/555128 :
3) The remote share should only be accessed via UNC name. Mapped drives may not be consistently visible to the SQL Service.
???

Автор: Валери Пятница, 27 Марта 2009, 8:01

Интересное кино,получается: в шару на обычный XP, бэкап идёт без проблем(повторяю при наличии в папке файла предид. бэкапа)

Автор: Валери Пятница, 27 Марта 2009, 15:07

Ну вот...кажется отвечаю сам себе!

Оказалось это произошло после установки Symantec AntiVirus Corporate Edition (пришлось поставить,на sql так как пришлось побороться с W32.Downdup.B, который как-то прополз в сеть).
При отключении автоматической защиты, бэкапы проходят!!!
Отсюда вопрос...(сам так и не нашёл в настройках автоматической защиты)что можно "подкрутить" в нём, чтоб защиту не отключать.Быть может кто сталкивался?
Т.К. На XP x32, бэкапит нормально при включённой автоматической защите.
Хотя может это надо перенести в другую рубрику???

Автор: Валери Пятница, 27 Марта 2009, 16:50

И снова ...тихо сам с собою...
Что "подкрутить" нашёл...
На Клиенте SAV(который совершает операцию SQL backup на "сеть")В Настройке -Файловая система: автоматическая защита-ОТКЛЮЧИТЬ Параметры осмотра сети.
На Клиенте SAV(на который пишется бэкап)В Настройке -Файловая система: автоматическая защита-Параметры-Исключения-Папки и Файлы-Добавить папку назначения бэкапов.
В службе поддержки (русской) SAV (супостаты пока молчат) пока объяснили, что файл слишком велик и пока промониториться... тут всё и рушиться на SQL2005 x64. Однако на возражение, что при записи на XP x32, этого не происходит, "пожали плечами" и посоветовали списываться с semea@symantec.com.
Так что тему вероятно можно сворачивать

Автор: Egor Вторник, 31 Марта 2009, 13:18

А ты на сервер устанавливаешь антивирусный клиент???!!!
Слов нет...

Автор: Валери Вторник, 31 Марта 2009, 15:54

To Egor:
Прорвалась как-то зараза: http://www.symantec.com/security_response/writeup.jsp?docid=2008-123015-3826-99 , пришлось поставить и на сервер..., до этого не было...
не от хор. жизни...
А что прикажешь поставить на одну железяку антивир. сервер чтоль?

Автор: Egor Вторник, 31 Марта 2009, 21:18

Так точно. Мало того, чтобы избежать совершенно непредвиденных... проблем, и на TS, тоже рекомендуется ставить серверную часть антивиря. НО не SA, он для этого совершенно не приспособлен, а что-нибудь типа OfficeScan.

ЗЫ Хоть ты и военный, но совершенно салабон

Автор: Валери Среда, 01 Апреля 2009, 8:08

За что заплачено, то и ставим!

Автор: Egor Среда, 01 Апреля 2009, 12:59

Валера, своя-то голова у тебя всегда на месте была. Я, с такой проблемой, сталкивался лет 5 назад (еще на 8 версии SAV). С тех пор, зарекся ставить на сервера клиентскую часть. Максимум, это на файловую помойку, но там надо строго ограничивать сканирование только шарами для клиентов и не более.

ЗЫ Кстати, на эту твою проблему у меня тогда ушло минут 15. Все просто: Посмотрел таск-манагер, увидел, что реал-тайм монитор антивиря кушает много ресурсов. Системным монитором, посмотрел, на что они (ресурсы) используются и уперся в имя файла базы данных. Сложить 2 и 2 не составило большого труда. Отключил клиента, проверил. После этого клиента снес Жалко, не сообразил, что кто-то может еще сталкнуться с таким. Хотя, в этом есть свой плюс: как была у симантека проблема со сканом больших файлов, так и осталась. И ничего они с этим сделать не могут. Надо будет запомнить.

ЗЫЫ Знал-бы прикуп... соломки подстелил