Ошибка 22029
Прив!
На серваке SQL Server 2005 настроен план обслуживания с лог шиппингом на резерв. На резерве журналы Лог-шиппинга не восстанавливаются, база остаётся не актуальной. Глянул в список Job'ов: job'ы ответсвенные за восстановление из журналов выкидывают ошибку:
Executed as user: xxxxxxxx\xxxxxxx. sqlmaint.exe failed. [SQLSTATE 42000] (Error 22029). The step failed.
На сайте Микрософта описывают причину подобной ошибки связанную с наличием строки "-S" на пути SQLServer'a (2000). Такого на серваке нет.
В истории плана обслуживания никаких ошибок не выдаётся. Журналы копируются со статусом ОК.
Решить проблему хочется без пересоздания плана обслуживания.
В чём может быть фигня?
На серваке SQL Server 2005 настроен план обслуживания с лог шиппингом на резерв. На резерве журналы Лог-шиппинга не восстанавливаются, база остаётся не актуальной. Глянул в список Job'ов: job'ы ответсвенные за восстановление из журналов выкидывают ошибку:
Executed as user: xxxxxxxx\xxxxxxx. sqlmaint.exe failed. [SQLSTATE 42000] (Error 22029). The step failed.
На сайте Микрософта описывают причину подобной ошибки связанную с наличием строки "-S" на пути SQLServer'a (2000). Такого на серваке нет.
В истории плана обслуживания никаких ошибок не выдаётся. Журналы копируются со статусом ОК.
Решить проблему хочется без пересоздания плана обслуживания.
В чём может быть фигня?
Пересоздание плана обслуживания не помогает=\
А причем тут вообще пересоздание плана?
Например человек который разбирался с этой проблемой, свое решение описал так:
Например человек который разбирался с этой проблемой, свое решение описал так:
Цитата:
I've resolved my issue with this problem. My maint. plan was failing with essentially the same problem. I stopped backing up my trans log with my database. Once I did that, my backup plan was successful. I didn't need a separate trans log backup on the databases I was backing up.
There were two things that led me to this conclusion. First, I ran the query below and reviewed the messages for the failed backups. I noticed that all of them were on the trans log and not the database:
select database_name, activity, start_time, message
from msdb..sysdbmaintplan_history
where error_number = 0 <-- this line optional
Secondly, I read 'Transaction Log Backups' in BOL. It indicated to me that I only needed the trans log backup if I was attempting to recover up to a point in time after the db backup was taken. If I have to backup the trans. log, I intend to do it in a separate maint. plan to begin outside of the db backup.
I hope this makes sense.
Sidney
There were two things that led me to this conclusion. First, I ran the query below and reviewed the messages for the failed backups. I noticed that all of them were on the trans log and not the database:
select database_name, activity, start_time, message
from msdb..sysdbmaintplan_history
where error_number = 0 <-- this line optional
Secondly, I read 'Transaction Log Backups' in BOL. It indicated to me that I only needed the trans log backup if I was attempting to recover up to a point in time after the db backup was taken. If I have to backup the trans. log, I intend to do it in a separate maint. plan to begin outside of the db backup.
I hope this makes sense.
Sidney
Взято здесь
И в этой же теме, второй участник пишет что причиной ошибки может быть банальная нехватка места.
прост в посте , не помню где, писали что помогало пересоздание плана
да .. кажется всему виной "Low disk size".
чем могут эти джобы плана обслуживания наполнять сервак если все восстанавливаемые базы хранятся на другом жёстком диске с 60Гб свободного места??
да .. кажется всему виной "Low disk size".
чем могут эти джобы плана обслуживания наполнять сервак если все восстанавливаемые базы хранятся на другом жёстком диске с 60Гб свободного места??
Да без вопросов. Давай админский доступ на серв - и я тебе все подскажу. И почищу :)