Это проблема, которую я видел у других людей, кроме себя, и я не нашел хорошего объяснения.
Допустим, у вас есть план обслуживания с задачей проверки базы данных, что-то вроде этого:
USE [MyDb]
GO
DBCC CHECKDB with no_infomsgs, all_errormsgs
Если вы посмотрите в журналы после выполнения задачи, вы увидите что-то вроде этого:
08/15/2008 06:00:22,spid55,Unknown,DBCC CHECKDB (mssqlsystemresource) executed by NT AUTHORITY\SYSTEM found 0 errors and repaired 0 errors. Elapsed time: 0 hours 0 minutes 0 seconds.
08/15/2008 06:00:21,spid55,Unknown,DBCC CHECKDB (master) executed by NT AUTHORITY\SYSTEM found 0 errors and repaired 0 errors. Elapsed time: 0 hours 0 minutes 0 seconds.
Вместо проверки MyDb проверяется master и msssqlsystemresource.
Почему?
Моим обходным решением является создание задания агента Sql Server Agent Job с этим:
dbcc checkdb ('MyDb') with no_infomsgs, all_errormsgs;
Это всегда работает нормально.
08/15/2008 04:26:04,spid54,Unknown,DBCC CHECKDB (MyDb) WITH all_errormsgs<c/> no_infomsgs executed by NT AUTHORITY\SYSTEM found 0 errors and repaired 0 errors. Elapsed time: 0 hours 26 minutes 3 seconds.
Для начала, всегда помните, что GO
не является ключевым словом SQL; это просто разделитель пакетов, который (как правило) реализуется/распознается клиентом, а не сервером. Поэтому, в зависимости от контекста и клиента, нет никакой гарантии, что текущая база данных будет сохранена между партиями.
Если вы используете план обслуживания, вам, вероятно, лучше использовать задачу проверки целостности базы данных. Если вы действительно хотите запустить собственное обслуживание, написанное на t-sql, то запустите его с помощью шага в задании, а не в плане обслуживания, и приведенный выше код будет работать нормально. Как сказал Стю, оператор GO - это директива клиента, а не ключевое слово sql, и, похоже, ее соблюдают только клиенты isql, wsql, osql и т.д. и sql-агент. Я думаю, что это работает в пакетах DTS. Очевидно, не в DTSX, однако.