Just nu i M3-nätverket
Gå till innehåll

SQLSTATE 42000 Error 22029


_DS_

Rekommendera Poster

Ett av mina backupjobb har slutat att fungera.

 

Är det någon som har en aning OM, eller ännu hellre VAR, det finns en lista e.dyl. över olika felmedddelanden från SQL Server???

 

Jag har skapat olika "histories" och "reports" över felmeddelandet, men jag lyckas inte få ut någon vettig information ur texterna.

 

Länk till kommentar
Dela på andra webbplatser

Magnus Ahlkvist

SQLSTATE 42000 betyder "Syntax error or Access violation"

 

Om det är ett backupjobb som är skapat med EM så är det troligast att backupjobbet försöker skriva en backup-fil till en katalog i filsystemet som SQL Agent-processen inte har access till.

Kolla filrättigheterna på katalogen du försöker backupa till, och prova att sätta "Everyone - Full Control". Kör jobbet, och se om det fortfarande strular. Om det funkar då, sätt om rättigheterna så att SQL Agent-processen har rättigheter (den körs som default under Local System) att skriva i katalogen.

 

 

--

Snäll ibland. Rättvis nästan jämt. Elak för det mesta.

 

Länk till kommentar
Dela på andra webbplatser

Tack för ditt förslag. Dessvärre var redan rättigheterna "Everyone - Full control".

 

När jag undersökte jobbet med sp_help_job fick jag fram följande:

 

TSQL:

EXECUTE master.dbo.xp_sqlmaint N'-PlanID 299F5CCE-29F5-4923-BDCE-804C32E2CEAD -Rpt "E:\XXX\XXX\XXX.txt" -DelTxtRpt 4WEEKS -WriteHistory -VrfyBackup -BkUpMedia DISK -BkUpLog "E:\XXX" -DelBkUps 6DAYS -CrBkSubDir -BkExt "TRN

 

Databasename: master (det är alltså INTE mastern som ska backas. Alla andra job har också mastern som databasae.

Jobägare: domänadmin

last_outcome_message:

The job failed. The Job was invoked by Schedule 46 (Schedule 1). The last step to run was step 1 (Step 1).

 

Det var ytterligare lite information det... Hoppas att någon vill/kan hjälpa mig.

 

 

Länk till kommentar
Dela på andra webbplatser

Magnus Ahlkvist

Är domänadmin med i rollen system administrators i SQL Server?

Annars tror jag inte att man har rätt att köra xp_sqlmaint.

 

 

 

--

Snäll ibland. Rättvis nästan jämt. Elak för det mesta.

 

Länk till kommentar
Dela på andra webbplatser

Jag ställde om så att "sa" är ägare till jobbet. Det hjälpte inte. Exakt samma fel uppstår. "sa" bör väl ändå ha högsta prioritet/rättighet???

 

sp_help_pleeeease

 

Länk till kommentar
Dela på andra webbplatser

Magnus Ahlkvist

Har du provat att i EM ta bort jobbet och skapa om det?

Det ser lite konstigt ut på slutet av TSQL:en.

Jag har inte någon SQL Server som jag kan nå från den här datorn (har semester), så jag kan inte kolla vad en sp_help_job presenterar i våra servrar.

 

 

--

Snäll ibland. Rättvis nästan jämt. Elak för det mesta.

 

Länk till kommentar
Dela på andra webbplatser

Tack för ytterligar ett förslag.

 

Till en början ingick jobbet i ett annat jobb. För c:a två veckor sedan slutatde jobbet för en specifik databas att fungera. Då skapades ett nytt jobb som endast utförde trn-backup på just den databas som inte fungerade i "kombinationsjobbet". Jobbet är alltså nyskapat.

 

Vad är det som verkar konstigt i TSQL:en?(Jag vet inte riktigt hur det ska se ut, så det är därför jag frågar.)

 

Länk till kommentar
Dela på andra webbplatser

Magnus Ahlkvist

Avslutningen ser mysko ut: "TRN

 

Men jag vet som sagt inte hur det SKA se ut, eftersom jag inte har någon SQL Server i närheten som jag kan köra sp_help_job på

 

--

Snäll ibland. rättvis nästan jämt. Elak för det mesta.

 

Länk till kommentar
Dela på andra webbplatser

TRN är den filändelse jag satt att alla trans-loggar ska ha. Vårt andra, fungerande jobb, har samma avslut...

 

Jag har fått reda på något som troligtvis spelar EXTREMT stor roll. Innan SQL Server 2000 fanns dito -97. Då vår data överfördes till 2000 gjordes detta med DTS, vilket på något vis gjorde att samtliga tabeller blev dubblerade i just den databas jag försöker köra jobbet på. Dessa dubletter har tydligen tagits bort för inte så länge sedan. Resultat: trans-loggarna på denna databas kan ej backas...

 

Länk till kommentar
Dela på andra webbplatser

Magnus Ahlkvist

Kör en full backup på databasen så ska det gå att köra backup på transaktionsloggen. Annars har du något fuffens i DB:n och skulle kunna prova att köra DBCC CHECKDB för att se om du har några inkonsistenser.

 

--

Snäll ibland. rättvis nästan jämt. Elak för det mesta.

 

Länk till kommentar
Dela på andra webbplatser

Resultat: DBCC CHECKDB

 

CHECKDB found 0 allocation errors and 0 consistency errors in database 'xxxxxx'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

 

Verkar inte var anågot fel där.

 

Länk till kommentar
Dela på andra webbplatser

Arkiverat

Det här ämnet är nu arkiverat och är stängt för ytterligare svar.

×
×
  • Skapa nytt...