Mam 2 zaplanowane zadania na moim komputerze z programem SQL Server 2005, które są uruchamiane każdego ranka (około 2:00). Te prace sprawdziły się dobrze (głównie) przez lata i chociaż miałem kilka problemów, które musiałem przezwyciężyć ten problem, całkowicie mnie denerwują.SSIS: Po prostu zaczęto uzyskiwać "Klucz nie jest prawidłowy do użycia w określonym stanie". błąd w moim zaplanowanym pakiecie SSIS
Dwa poranki temu jeden z moich paczek rozpoczął raportowanie następujący błąd:
Executed as user: [Service Acount]. ...n 9.00.4035.00 for 32-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
Started: 1:15:01 AM Error: 2012-10-17 01:15:03.98
Code: 0xC0016016
Source:
Description: Failed to decrypt protected XML node "DTS:Password"
with error 0x8009000B "Key not valid for use in specified state.".
You may not be authorized to access this information. This error
occurs when there is a cryptographic error. Verify that the
correct key is available. End Error Error: 2012-10-17 01:15:03.99
Code: 0xC0016016
Source:
Description: Failed to decrypt protected XML node "DTS:Password"
with error 0x8009000B "Key not valid for use in specified state.".
You may not be authorized to access this information. This error
occurs when there is a cryptographic error. Verify that the
correct key is available. End Error Error: 2012-10-17 01:15:04.01
Code: 0xC0016016
Source:
Description: Failed to ... The package execution fa... The step failed.
To wydaje się być wspólny problem, jednak żaden z zaleceniami, które znalazłem albo zastosować do mojego scenariusza, ani czy moje wystąpienie wydaje się pasować do większości innych przypadków, w których tak się dzieje. Oto ważne szczegóły dotyczące mojej implementacji.
- Ten pakiet eksportuje dane z systemu iSeries do SQL Server tabel danych 2005.
- Ten proces działa poprawnie, ale zawiesza się na jednym, określonym eksporcie tabeli. W rzeczywistości działa on bez problemu przez ponad 2 godziny przed śmiercią. Po sprawdzeniu wszystkich właściwości powiązanych z z tym krokiem widzę, że nie ma nic innego w tym kroku niż w innych krokach eksportowania tabeli, innych niż mapowanie eksportu tabeli/kolumny .
- Pakiet
ProtectionLeveljest ustawiony naDontSaveSensitive, a poświadczenia iSeries są przechowywane w pliku konfiguracyjnym, do którego dostęp uzyskuje SQL Server. - Mogę wykonać awaryjny krok na mojej maszynie, w OFERTACH. Niezależnie od tego nie działa on na serwerze, chociaż serwer używa dokładnie tych samych poświadczeń.
- Jak już wspomniałem, mam dwie paczki. Są to faktycznie te same rzeczy, z wyjątkiem tego, że jeden eksportuje dane z jednej bazy danych iSeries, a drugi eksportuje dane o wartości prawie dokładnie takiej samej z innego serwera iSeries DB. Pierwszy pakiet nie ma żadnych problemów, nawet jeśli używa tych samych poświadczeń systemu iSeries.
- Żeby było jasne, nic na moim serwerze nie zmieniło się w ciągu kilku miesięcy (o czym jestem świadoma). To właśnie zaczęło się wczoraj.
Wszelkie wskazówki lub przemyślenia byłyby niezwykle pomocne. Ten eksport jest niezwykle ważny i wielu użytkowników/pracowników polega na tych danych do codziennej pracy.
Jakieś aktualizacje, które zostały zastosowane do twojego serwera? Czy próbowałeś zapisać pakiet bezpośrednio od BIDS do docelowej lokalizacji (Save As daje tę opcję)? – rvphx
Nie wierzę, że jakiekolwiek aktualizacje zostały przekazane do serwera (systemu operacyjnego). Kontroluję wszelkie aktualizacje do SQL Server i nie mam żadnych zainstalowanych. Ponadto, buduję projekt lokalnie na moim komputerze, a następnie zdalnie wprowadzam go do maszyny SQL Server i importuję do bazy danych (nie do lokalizacji opartej na plikach). – RLH
Czy próbowałeś zmienić poziom ochrony pakietu podczas jego importowania? do serwera SQL? Czasami podczas importowania paczki, ta rzecz zostaje pomieszana. – rvphx