Проблема в следующем.
Есть 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
А если примапить папку?
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.
???
Интересное кино,получается: в шару на обычный XP, бэкап идёт без проблем(повторяю при наличии в папке файла предид. бэкапа)
Ну вот...кажется отвечаю сам себе!
И снова ...тихо сам с собою...
Что "подкрутить" нашёл...
На Клиенте SAV(который совершает операцию SQL backup на "сеть")В Настройке -Файловая система: автоматическая защита-ОТКЛЮЧИТЬ Параметры осмотра сети.
На Клиенте SAV(на который пишется бэкап)В Настройке -Файловая система: автоматическая защита-Параметры-Исключения-Папки и Файлы-Добавить папку назначения бэкапов.
В службе поддержки (русской) SAV (супостаты пока молчат) пока объяснили, что файл слишком велик и пока промониториться... тут всё и рушиться на SQL2005 x64. Однако на возражение, что при записи на XP x32, этого не происходит, "пожали плечами" и посоветовали списываться с semea@symantec.com.
Так что тему вероятно можно сворачивать
А ты на сервер устанавливаешь антивирусный клиент???!!!
Слов нет...
To Egor:
Прорвалась как-то зараза: http://www.symantec.com/security_response/writeup.jsp?docid=2008-123015-3826-99 , пришлось поставить и на сервер..., до этого не было...
не от хор. жизни...
А что прикажешь поставить на одну железяку антивир. сервер чтоль?
За что заплачено, то и ставим!
Валера, своя-то голова у тебя всегда на месте была. Я, с такой проблемой, сталкивался лет 5 назад (еще на 8 версии SAV). С тех пор, зарекся ставить на сервера клиентскую часть. Максимум, это на файловую помойку, но там надо строго ограничивать сканирование только шарами для клиентов и не более.
ЗЫ Кстати, на эту твою проблему у меня тогда ушло минут 15. Все просто: Посмотрел таск-манагер, увидел, что реал-тайм монитор антивиря кушает много ресурсов. Системным монитором, посмотрел, на что они (ресурсы) используются и уперся в имя файла базы данных. Сложить 2 и 2 не составило большого труда. Отключил клиента, проверил. После этого клиента снес Жалко, не сообразил, что кто-то может еще сталкнуться с таким. Хотя, в этом есть свой плюс: как была у симантека проблема со сканом больших файлов, так и осталась. И ничего они с этим сделать не могут. Надо будет запомнить.
ЗЫЫ Знал-бы прикуп... соломки подстелил
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)