Sådan finder du årsagerne til SSIS-pakkefejl i SQL Agent

I denne artikel vil vi diskutere, hvordan man får en liste over pakker relateret til SSIS, forbindelsesproblemer i datalager, nøgleadgangsproblemer i filer og beskyttelsesniveau for pakke, SSIS-kildehastighed og loglogik.

SSIS-pakkefejlHvis vi ikke anvender nødvendige funktioner i vores SSIS-pakke, viser konsoludgange eller Windows-hændelseslogfiler et lille antal fejl. Men hvis vi aktiverer logfunktionen i SSIS, er det et helt andet scenario. Generelt kan vi arbejde med fem forskellige steder, der inkluderer logfiler fra SSIS-komponent, logfiler fra SSIS-logning, hændelseslog og jobhistorik, logfiler fra de underliggende datakilder og revisionslog.

SQL Server Agent jobHvis din SQL Server Hvis agentjobbet kører med SSIS-pakken, skal vi først kontrollere fejlene i Windows' hændelseslogfiler og i SQL-agentens historik. Vi kan udfylde hændelsespanelets håndtering med flere logikker til brugerdefineret fejlhåndtering. Både på kontrolopgaveniveau og pakkeniveau kan vi definere hændelseshåndteringen for fejl. Denne funktion er den mest kraftfulde til oprettelse af brugerdefinerede hændelser og deres håndteringslogik.

I revisionslogfiler giver typiske indledende metoder generelle fejl, og hvis du føler behov for at analysere mere information, er der en mulighed givet af SQL server for at aktivere SSIS-log-revisionen, som outputfejl i en XML-fil, hændelseslogfiler i windows, profiler sporing af SQL Server or SQL Server databaselog. Det kan gøres ved at få adgang til indstillingen og konfigurere log-udbydere af SSIS.

Pakker relateret til SSIS

Der er til tider behov for at få en liste over pakker, der er relateret til SSIS i vores SQL Server. Til dette formål kan vi bruge følgende forespørgsel.

--packages related to SSIS in SQL DB
SELECT 
          DIR.foldername AS Directory-Name
          PKG.name AS Name-Of-Package,
          PKG.[description] AS Package-Description,
          --using switch case to categorize results
          CASE PKG.packagetype
          WHEN 0 THEN ‘Client is default’
          WHEN 1 THEN ‘Input/Output Wizard’
          WHEN 2 THEN ‘Data Transform Service Designer’
          WHEN 3 THEN ‘Replicated’
          WHEN 5 THEN ‘SSIS’
          WHEN 6 THEN ‘Plan for Maintenance’
          ELSE ‘unidentified’
          END AS packagetype,
          GL.name AS Name-Of-Owner,
          PKG.isencrypted AS ‘Encrypter-Or-Not’,
          PKG.createdate AS ‘Date-Created’,
          PKG.vercomments AS ‘Comments-Of-Version’,
          DATALENGTH(PKG.packagedata) AS ‘Size-Of-Package’,
          CONVERT(varchar(25), vermajor)+’.’+
          CONVERT(varchar(25),verminor)+’.’+
          CONVERT(varchar(25),verbuild) AS ‘Package version’

FROM 
          msdb.dbo.sysssispackages as PKG
INNER JOIN
         msdb.dbo.sysssispackagefolders as DIR
ON
         DIR.folderid = PKG.folderid
INNER JOIN
         sys.syslogin AS LG
ON 
         GL.sid = PKG.ownersid
ORDER BY 
         PKG.name
--ordered by names of packages

Tilpassede logik

SQL Server giver brugerdefinerede loglogik, der kan implementeres i scriptkomponent eller scriptopgaver i SSIS. Et eksempel kan være vedligeholdelse af tekstfiler ved hjælp af data eller værdier fra variabel under udførelse af SSIS-pakke.

Hvis vi taler om underliggende datakilder og deres logfiler, er der nogle fejl, der kan findes i disse underliggende datakilder, og for at løse dem, bør vi gå ned i detaljer ved at kontrollere logfiler over fejl fra den respektive datakilde. Som standard er logfiler i ERRORLOG-mappen under LOG.

SSIS kildehastighed

Det skal bemærkes, at SSIS-kildehastighed ikke er direkte proportional med forespørgselens tidskompleksitet. Den hastighed, hvormed data returneres, er det, der påvirker SSIS-kildehastigheden. Kildekomponenter er ikke kilden til vores data. Vi bør fokusere på at optimere vores forespørgsler, fordi det i sidste ende vil afstemme SSIS.

SQL-reparation

I sidste ende foreslår vi, at du bruger SQL Server fastsætte værktøj som DataNumen SQL recovery hvilket hjælper med at bevare de tabte data på grund af pludselige nedbrud i databasen.

Forfatter Introduktion:

Upton Mark er en datagendannelsesekspert i DataNumen, Inc., som er verdens førende inden for datagendannelsesteknologier, herunder adgangsgendannelse og softwareprodukter til ordgendannelse. For mere information besøg www.datanumen.com

Kommentarer er lukket.