Jak znaleźć przyczyny awarii pakietu SSIS w agencie SQL

Podziel się teraz:

W tym artykule omówimy, jak uzyskać listę pakietów związanych z SSIS, problemy z połączeniem w magazynie danych, problem z dostępem do kluczy w plikach i poziom ochrony pakietu, szybkość źródła SSIS i logikę logów.

Błąd pakietu SSISJeśli nie zastosujemy niezbędnych funkcji w naszym pakiecie SSIS, to wyjścia konsoli lub dzienniki zdarzeń systemu Windows będą pokazywać niewielką liczbę błędów. Ale jeśli włączymy funkcję logowania w SSIS, to jest to zupełnie inny scenariusz. Ogólnie rzecz biorąc, możemy pracować z pięcioma różnymi miejscami, które obejmują dzienniki z komponentu SSIS, dzienniki z audytu rejestrowania SSIS, dziennik zdarzeń i historie zadań, dzienniki z podstawowych źródeł danych i dziennik audytu.

SQL Server Praca agentaJeżeli twój SQL Server Zadanie agenta jest uruchamiane z pakietem SSIS, więc najpierw musimy sprawdzić błędy w dziennikach zdarzeń systemu Windows oraz w historii agenta SQL. Możemy wypełnić panel obsługi zdarzeń dodatkowymi logikami obsługi błędów. Zarówno na poziomie zadania sterującego, jak i pakietu, możemy zdefiniować obsługę zdarzeń dla błędów. Ta funkcja jest najbardziej przydatna w przypadku tworzenia niestandardowych zdarzeń i logiki ich obsługi.

W dziennikach kontroli początkowe metody zwykle dają ogólne błędy, a jeśli czujesz potrzebę przeanalizowania większej ilości informacji, istnieje opcja podana przez SQL server aby umożliwić audyt dziennika SSIS, który generuje błędy w pliku XML, dzienniki zdarzeń systemu Windows, profiler śledzenia SQL Server or SQL Server dziennik bazy danych. Można to zrobić, uzyskując dostęp do ustawień i konfigurując dostawców dzienników SSIS.

Pakiety związane z SSIS

Czasami istnieje potrzeba uzyskania listy pakietów związanych z SSIS w naszym SQL Server. W tym celu możemy użyć następującego zapytania.

--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

Niestandardowe logiki dziennika

SQL Server zapewnia niestandardową logikę dziennika, którą można zaimplementować w komponencie skryptu lub zadaniach skryptowych SSIS. Przykładem może być obsługa pliku tekstowego przy użyciu danych lub wartości ze zmiennej podczas wykonywania pakietu SSIS.

Jeśli mówimy o bazowych źródłach danych i ich dziennikach, istnieją pewne błędy, które można znaleźć w tych bazowych źródłach danych i aby je rozwiązać, powinniśmy zagłębić się w szczegóły, sprawdzając dzienniki błędów odpowiedniego źródła danych. Domyślnie dzienniki znajdują się w folderze ERRORLOG w obszarze LOG.

Szybkość źródła SSIS

Należy zauważyć, że szybkość źródła SSIS nie jest wprost proporcjonalna do złożoności czasu zapytania. Szybkość, z jaką dane są zwracane, ma wpływ na szybkość źródła SSIS. Komponenty źródłowe nie są źródłem naszych danych. Powinniśmy skupić się na optymalizacji naszych zapytań, ponieważ to ostatecznie dostroi SSIS.

Naprawa SQL

Na koniec sugerujemy skorzystanie z SQL Server stały narzędzie jak DataNumen SQL recovery co pomaga w zachowaniu danych utraconych w wyniku nagłego awarii bazy danych.

Wprowadzenie autora:

Upton Mark jest ekspertem w dziedzinie odzyskiwania danych w DataNumen, Inc., która jest światowym liderem w technologiach odzyskiwania danych, w tym odzyskiwanie dostępu i oprogramowanie do odzyskiwania tekstu. po więcej informacji odwiedź www.datanumen.com

Podziel się teraz:

Możliwość dodawania komentarzy nie jest dostępna.