Procedura składowana SSIS wykorzystuje tabelę tymczasową 2008 i 2014

Question

Obecnie piszę pakiet SSIS, który pobiera dane z procedury składowanej za pośrednictwem źródła OLE DB. Procedura przechowywana zawiera dość nieprzyjemne zapytanie, które udało mi się poprawić przy użyciu tabel tymczasowych. Jeśli przełączę te tabele tymczasowe na zmienne tabel, logiczny odczyt wynosi od około 1,3 miliona do około 56 milionów. Jestem dość niekomfortowy z 1,3 miliona, ale nie ma sposobu, żebym był zadowolony z 56 milionów odczytów logicznych. Tak więc nie mogę naprawdę przekonwertować tabel tymczasowych na zmienne tabel.

Jednak SSIS (lub raczej SQL Server) nie może rozwiązać metadanych dla tego zapytania, więc pakiet nie zostanie uruchomiony. Znalazłem kilka różnych rozwiązań w Internecie, ale żaden z nich nie działa na obu serwerach SQL Server 2008 i SQL Server 2014. Obecnie jesteśmy w trakcie aktualizacji wszystkich naszych serwerów do 2014 r., A ten konkretny pakiet działa w roku 2008 w DEV, 2014 w QA, a 2008 w produkcji obecnie. Jesienią, warstwa PROD będzie 2014, a poziom DEV będzie promowany po pewnym czasie. Niestety, nie mogę się doczekać, aż te uaktualnienia wydadzą ten pakiet SSIS. Dane muszą zacząć działać w przyszłym tygodniu. W związku z tym muszę znaleźć sposób, aby metadane zostały rozwiązane dla obu środowisk. Oto, co starałem dotąd:

1. Dodaj obojętne wybierz w bloku IF 1=0 która zwraca prawidłowego metadanych. Działa to w 2008, ale nie w 2014.

2. Użyj SET FMTONLY OFF na początku procedury przechowywanej. Działa to w 2008 r., Ale nie w 2014 r. Ponadto powoduje, że procedura składowana jest uruchamiana raz dla każdej zwróconej kolumny (w tym przypadku ponad 30), co jest rozwiązaniem wyłączającym, nawet jeśli zadziałało.

3. Użyj EXEC ... WITH RESULT SETS ((...));. Działa to w 2014, ale nie w roku 2008.

4. Wdróż procedurę przechowywaną, która zwraca właściwe metadane, zbuduj i wdróż pakiet SSIS, a następnie zmodyfikuj procedurę składowaną do odpowiedniej wersji. Wydaje się, że nie działa to w żadnym środowisku, co komplikowałoby inne aplikacje ETL opracowane w ramach naszego ETL.

Jeśli nie mogę nic wymyślić, mógłbym wdrożyć różne procedury składowane i pakiety na różnych poziomach, ale bardzo bym wolał od tego. Po pierwsze, komplikowałoby to przyszłe wydania i musiałem również zapewnić, że nie zapomnę o aktualizacji procedury przechowywanej i pakietu po aktualizacji serwerów.

Mogę również tworzyć prawdziwe tabele w bazie danych, które zastąpią te tabele tymczasowe. Nie podoba mi się to rozwiązanie, ale jest to coś, co mógłbym znieść. Jeśli to zrobię, prawdopodobnie przełożę się na korzystanie z WITH RESULT SETS w przyszłości.

Jednak osobiście nie przejmuję się żadnym z tych rozwiązań, więc zastanawiałem się, czy istnieje jakieś obejście, które przeoczyłem, które może działać nieco lepiej.

Answer 1

Pomimo twojej niechęci, myślę, że dokonałeś właściwego wyboru, a dedykowany obszar postoju jest właściwą drogą. Większość ETLów produkcyjnych, z którymi współpracowałem, ma dedykowaną bazę danych, która nie ma nic przeciwko tabelom. Dzięki temu możesz lepiej kontrolować pamięć masową, co sprawia, że ​​wydajność jest bardziej niezawodna, a całość ogólnie łatwiejsza do utrzymania. Na przykład można utworzyć dedykowany, ciągły blok szybkiej przestrzeni dyskowej dla tych tabel z własną grupą plików itp. Wolałbym raczej widzieć 2 oddzielne SP, opierające się na kilku tabelach fizycznych, niż naprawdę paskudnie jedno.

To powiedziawszy, nie znając żadnych szczegółów, jest to tylko moje doświadczenie, więc zastrzeżenie dla przyszłych czytelników: Podobnie jak w przypadku wszystkich baz danych, należy mierzyć rzeczywistą wydajność swojego scenariusza (przed i po), a nie przyjmować żadnych założeń na podstawie planu kwerendy - może to wprowadzać użytkownika w błąd.