De ce planurile de întreținere Sql Server 2005 utilizează o bază de date greșită pentru dbcc checkdb?

Aceasta este o problemă pe care am văzut alți oameni în afară de mine și nu am găsit o explicație bună.

Să presupunem că aveți un plan de întreținere cu o sarcină pentru a verifica baza de date, ceva de genul:

USE [MyDb]
GO
DBCC CHECKDB with no_infomsgs, all_errormsgs

Dacă te duci să te uiți în jurnalele tale după executarea sarcinii, s-ar putea să vezi ceva de genul:

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.

În loc să verifice MyDb, a verificat masterul și msssqlsystemresource.

De ce?

Soluționarea mea este să creez un job Agent de Sql Server cu acest lucru:

dbcc checkdb ('MyDb') with no_infomsgs, all_errormsgs;

Asta întotdeauna funcționează bine.

08/15/2008 04:26:04,spid54,Unknown,DBCC CHECKDB (MyDb) WITH all_errormsgs no_infomsgs executed by NT AUTHORITY\SYSTEM found 0 errors and repaired 0 errors. Elapsed time: 0 hours 26 minutes 3 seconds.
0
fr hi bn

3 răspunsuri

Dacă utilizați un plan de întreținere, probabil că ar fi mai bine să utilizați sarcina de verificare a integrității bazei de date. Dacă într-adevăr doriți să vă rulați propria întreținere scrisă în t-sql, atunci rulați-o folosind un pas într-un loc de muncă, nu într-un plan de întreținere și codul de mai sus va funcționa bine. Ca și Stu, declarația GO este directiva clientului nu un cuvânt cheie sql și pare a fi respectată numai de către isql, wsql, osql, etc, clienții și agentul sql. Cred că funcționează în pachetele DTS. Evident, nu în DTSX, deși.

0
adăugat

Aveți o sarcină de verificare a integrității bazei de date și ați făcut dublu clic pe el și alegeți MyDb și când planul rulează, verifică doar masterul? ciudat. Ești sigur că nu mai ai un alt plan?

0
adăugat

Pentru început, rețineți întotdeauna că GO nu este un cuvânt cheie SQL; este doar un separator de lot care este (în general) implementat/recunoscut de client, nu de server. Deci, în funcție de context și client, într-adevăr nu există nicio garanție că baza de date curentă este păstrată între loturi.

0
adăugat