Po odtworzeniu bazy danych SSISDB job kończył się błędem:

’EXECUTE AS LOGIN’ failed for the requested login '##MS_SSISServerCleanupJobLogin##’.  The step failed.

No cóż – po odtworzeniu jest to możliwe, więc może trzeba na nowo zmapować usera z loginem?

USE SSISDB

ALTER USER [##MS_SSISServerCleanupJobUser##] with LOGIN = [##MS_SSISServerCleanupJobLogin##]

pełnego sukcesu jeszcze nie ma – ale zmienił się komunikat o błędzie, co oznacza, że trop jest dobry!

Executed as user: ##MS_SSISServerCleanupJobLogin##. The EXECUTE permission was denied on the object 'cleanup_server_retention_window’, database 'SSISDB’, schema 'internal’. [SQLSTATE 42000] (Error 229).  NOTE: The step was retried the requested number of times (3) without succeeding.  The step failed.

Na taki błąd może pomóc nadanie uprawnień!

grant execute on internal.cleanup_server_retention_window to [##MS_SSISServerCleanupJobLogin##]

grant execute on internal.cleanup_server_project_version to  [##MS_SSISServerCleanupJobLogin##]

No i proszę wszystko działa – klient zadowolny!

Jakiś czas temu opisywałem dwa modele serwisowania SQL:

Update dla SQL Server. GDR/QFE

Było to w czasach kiedy, kiedy Microsoft zalecał instalowanie Service Pack na produkcji a instalowanie Cummulative Updates miało być wykonywane generalnie tylko w przypadku, gdy taka akcja była zalecana przez Microsoft. Cummulative Updates były uważane za gorzej przetestowane, więc niezalecane do instalowania w produkcji.

Wiele się zmieniło od tego czasu. Obecnie Microsoft zaleca instalowanie Cummulative Updates, ale nadal pozwala na instalowanie Service Pack. To ma się zmienić w wersji 2017. Od tej pory czysty „Service Pack” nie będzie już publikowany, zamiast tego:

• przez pierwszy rok od wersji RTM pakiety Cummulative Updates będą publikowane raz na miesiąc
• później CU będą publikowane co kwartał przez kolejne 4 lata
• w sumie więc życie produktu będzie trwało 5 lat
• CU będą publikowane w tygodniu z 3-cim wtorkiem

Warto znać pojęcia jakimi posługuje się Microsoft podczas opisywania wsparcia dla SQL:

• Mainstream Support – 5-letni okres przez który będą wydawane aktualizacje w postaci CU (jeśli decydujesz się nie korzystać z CU możesz pozostać z gołym GDR, do którego będą publikowane tylko security updates)
• Extended Support – kolejne 5 lat, podczas którego będą publikowane tylko security updates i krytyczne patche funkcjonalne
• Premium Assurance – dodatkowo płatne 6 lat supportu

Więcej szczegółów znajduje się pod adresem:

Announcing the Modern Servicing Model for SQL Server

Oto mój „problem”: Na tablecie tworzę pewne dokumenty (grafiki), które chciałbym w miarę na bieżąco mieć na telefonie i komputerze. Niestety program z którego korzystam na tablecie nie pozwala mi otwierać i zapisywać dokumentów z Google Drive :(, bo gdyby otwieranie z GDrive działało to problemu by nie było….

Idealnie byłoby mieć lokalnie na tablecie folder, który sam wysyłałby się na GDrive, a stamtąd był synchonizowany z komputerem (żaden problem po zainstalowaniu „Backup and Sync from Google”) oraz na telefon, gdzie jakimś cudem ten plik również będzie kopiował pliki do lokalnego folderu.

No i znalazłem taki software! To „Autosync Google Drive„. Jest za darmo i robi dokładnie to czego chciałem. Jak narazie sprawuje się bez zarzutu i śmiało polecam! Na dodatek jest też bliźniak dla tego programu synchronizujący Microsoft One Drive!

Konto Gmail jest na prawdę fajne. Działa dobrze – żeby nie powiedzieć niezawodnie, znalezienie właściwego maila u mistrzów wyszukiwania to też żaden problem. Sęk w tym, że nie zawsze szukamy maila po słowie, które powinno się znaleźć w wiadomości, czasami istotne jest zalezienie dużych maili (z  dużymi załącznikami) lub  maili starszuych niż pewien okres. Znalazłem na to rozwiązanie:

• larger:5m – wpisz w polu wyszukiwania a znalezione zostaną maile większe niż 5 MB
• older_than:1y – wpisz w polu wyszukiwania i znajdziesz maile starsze niż rok

A tak przy okazji bardzo lubię zajrzeć do osi czasu, co pozwala mi zobaczyć co i kiedy robiłem. No cóż telefon z włączonym GPS + Android i wozisz ze sobą służbę bezpieczeństwa:

https://www.google.com/maps/timeline?pb

Oto pełna lista słów i  konstrukcji, które pozwalają szukać w GMail (lista pochodzi z https://support.google.com/mail/answer/7190?hl=en): Czytaj dalej »

Execution policy w powershellu kontrolujemy poleceniem Set-ExecutionPolicy, a sprawdzamy Get-ExecutionPolicy. Może sie jednak trafić w specyficznych warunkach, że chcesz te dane odczytać bezpośrednio z rejestru. W przypadku Execution policy ustawianego lokalnie na komputerze (scope LocalMachine) odpowiednia informacja znajduje się w rejestrze i można ją tam śmiało sprawdzić nawet nie dotykając powershella:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

Ok ok, wiemy, że wyczyszczenie cache procedur na serwerze może „dobić serwer”, bo wszystkie skompilowane plany zapytań trzeba zbudować od nowa, ale – to polecenie można też uruchomić z mniejszym impaktem. Idziemy po kolei rozpoczynając od bomby a kończąc na komarze:

DBCC FREEPROCCACHE;

czyści cache dla całej instancji – duży impakt

DBCC FLUSHPROCINDB (8)

czyści cache dla jednej bazy danych (tutaj dla bazy z database_id = 8). Duży impakt dla bazy ale znacznie mniejszy dla serwera, chociaż jak pomyślisz o konieczności skompilowania procedur, to będą one kompilowane przez instancję, więc potencjalnie inne procesy z innych baz danych będą miały ograniczony dostęp do CPU przynajmniej przez chwilę

DBCC FREEPROCCACHE (0x05000800A7B3526C4FD15055A40000000000000000000000);

usunie jeden plan wykonania dla jednego zapytania. Identyfikator planu zapytania znajdziesz w sys.dm_exec_cached_plans. Ten widok można łączyć z funkcją sys.dm_exec_sql_text(plan_handle), co pozwoli odnaleźć plan dla zapytania o znanym tekście. Impakt minimalny

Ładnie opisuje to Glenn Berry o tutaj

Ostatnimi czasy intensywnie pracuję z Service Brokerem i jak to bywa w takim związku, poznaję jego humory i sposoby rozwiązywania problemów. W tym wpisie chcę udokumentować kilka objawów i rozwiązań z Service Brokerem: Czytaj dalej »