04. november 2004 - 13:53Der er
15 kommentarer og 1 løsning
Problemer med at afvikle job under SQL Server Agent
Jeg har en Pakke under DTS som skal afvikles engang i døgnet, dette har jeg så opsat en schedul for, men efter at have flytte min database, og min dts pakke kan jeg ikke få det til at virke mere. Jeg får følgende fejl i loggen for jobbet:
The job failed. The Job was invoked by User sa. The last step to run was step 1 (test_update).
Executed as user: SQL-SERVER\Administrator. DTSRun: Loading... DTSRun: Executing... DTSRun OnStart: DTSStep_DTSActiveScriptTask_13 DTSRun OnError: DTSStep_DTSActiveScriptTask_13, Error = -2147220421 (8004043B) Error string: The task reported failure on execution. Error source: Microsoft Data Transformation Services (DTS) Package Help file: sqldts80.hlp Help context: 1100 Error Detail Records: Error: -2147220421 (8004043B); Provider Error: 0 (0) Error string: The task reported failure on execution. Error source: Microsoft Data Transformation Services (DTS) Package Help file: sqldts80.hlp Help context: 1100 DTSRun OnFinish: DTSStep_DTSActiveScriptTask_13 DTSRun: Package execution complete. Process Exit Code 1. The step failed.
DTS pakken virker fint hvis jeg afvikler den manuelt. Nogen der kan hjælpe?
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
Ja. Hvis du laver en pakke via Enterprise manager på din lokale maskine, en pakke der gemmes på en extern server, så vil den afvikles på din maskine hvis du kører den i design, eller ved at køre den fra Local Packages-noden. Men hvis du laver et schedule vil den køres at Server Agent på den externe maskine. Derfor kan det let ske at connections eller adgang til filsystemet ikke virker ens.
En løsning er at du logger ind på den externe server, via RDP elller TS, og kører den i design på den externe maskine, for så vil du få ret præcise fejlmeldinger.
Endelig kan man forsøge at opstille et lokal miljø der svarer til serverens hvilket gør fremtidig udvikling lettere.
Mit problem opstod i forbindelse med at jeg flyttet alt fra min sql-server ober på en ny sqwl-server. Det køre fint fra design, men lige så snart jeg køre det via sql-server agenten får jeg ovenstående fejl.
Agenten afvikler pakkerne på samme maskine som SQL-serveren ligger på, så du skal designe dem på den maskine for at være sikker på det.
Har du misforstået mig?
Der kunne da også være andre forklaringer, men prøv dette først.
Derefter kan du undersøge hvilken bruger servicen SQLSERVERAGENT kører under, og om den bruger har rettigheder nok til at afvikle pakken. Det skal være en administratorkonto. Desuden kan du angive hvilken bruger der skal benyttes til connections.
Se under SQL Server Agent's properties, første fane og sidste fane.
Det ser ud til at det er nogle ActiveX scripts der giver problemer, check hvilke connections der findes i dem, og om de er gyldige på serveren. Check også om der anvendes COM-objecter som evt ikke findes på den nye server. Se om filsystemet tilgås, og om der er rettigheder til det
Så er det nok et spørgsmål om hvilken bruger der kører Agenten.
... Derefter kan du undersøge hvilken bruger servicen SQLSERVERAGENT kører under, og om den bruger har rettigheder nok til at afvikle pakken. Det skal nok være en administratorkonto. Desuden kan du angive hvilken bruger der skal benyttes til connections.
Se under SQL Server Agent's properties, første fane og sidste fane.
SQL Server Agenten kan godt afvikle DTS pakker, jeg lavede en simpel pakke som jeg godt kunne afvikle. Iøvrigt er der ind tastet en administrator konto på begge de faneblade du omtaler.
De activeX scripts jeg bruger tilgår alle filsystemet (De flytter nogle filer, eller kontrollere om filerne er der.)Hvis jeg bruger et activeX script der ikke prøvet at tilgå filsystemet virker det fint. Så det må være et rettighedsproblem, men det drev den prøver at tilgå har jeg givet alle fuld rettighed. Jeg fatter ikke rigtig hvad der sker, for det hele virker fint år jag afvikler det manuelt.
Nå, men så er problemet jo lokaliseret. Det er Agenten der ikke har adgang til filsystemet.
Nu er jeg mildest talt ikke ekspert i sikkerhed, men jeg ville sætte Service startup Account til System, og Connection account til sa, bare for at teste om det virker så. Jeg tror ikke at du kan give Agenten højere status end det.
Og dog: Måske afvikles ActiveX via Windows Script Host eller lignende, og så kan det være der problemet er.
Må jeg gætte på at det er en Server 2003 vi snakker om? Den er kendt for at INTET er tilladt indtil du giver lov.
Jeg gætter nu, du skal nok have fat i en med mere forstand på sikkerhed.
Opret evt et nyt spm. med en header der fortæller mere præcist hvad det handler om.
Jeg ved ikke om vi kan komme videre her, men jeg har fundet frem til følgende. De filer jeg prøver at tilgå ligger på en anden server (Jeg har mappet drevet), begge server er i samme domain. Hvis jeg prøver at tilgå filer på sql-serveren virker det fint, men ikke når jeg vil tilgå filerne på den anden server. Det skal lige siges igen at alt virker fint når jeg ikke bruger SQL server agenten.
Idanielsen: Smid et svar så er der point, og mange tak for din hjælp!
YES, så fandt vi frem til det. Tålmodighed lønner sig
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
