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 »

Service Broker to fantastyczne rozwiązanie na pokładzie platformy SQL, o ile działa….

W moim przypadku wysłanie komunikatu ze instancji A do B kończyło się tym, że w sys.transmission_queue na „A” nie był logowany żaden bład, ale wiadomość nie była wysyłana.

No cóż – trzeba było włączyć profiler (najlepiej po obu stronach i analizować).

Na instancji B nie było tak źle. Widać było, że komunikaty chodzą, ale… się dublują i generalnie wszystkie były odrzucane jako duplikaty:

This message could not be delivered because it is a duplicate.

Ten komunikat mówi mniej więcej tyle, że taka wiadomość już raz do instancji B dotarła, ale z jakiegoś powodu nie udało się jej potwierdzić. Najczęściej jest to związane z niepoprawnie ustawionym routingiem. Dla przypomnienia:

• należy zdefiniować w bieżącej bazie danych route do zdalnego serwisu
• oraz w bazie msdb lokalny routing dla lokalnego serwisu

Jednak dlaczego nie można potwierdzić otrzymania komunikatu? Mój routing był ustawiony dobrze! Odpowiedź udało się znaleźć w profilerze na instancji A. Pełny komunikat o błedzie to:

The message could not be delivered because it could not be classified. Enable broker message classification trace to see the reason for the failure.

O jaką klasyfikację chodzi? To się udało odczytać w kolejnej pozycji wyłapanej przez profilera:

Event Class „Broker:Message Classify”

Lokalnego routingu nie można było przeczytać, bo service broker w bazie danych msdb był wyłączony…. rzeczywiśce parę godzin wcześniej musiałem na tej instancji odtworzyć bazę msdb i przy tej okacji flaga BROKER_ENABLED została wygaszona. Wystrczyło włączyć brokera na bazie msdb na instancji A i komunikacja Service Brokera ruszyła z kopyta!

Z powershellem można wszystko! Czy aby na pewno? Program regedit.exe pozwala edytować cały rejestr, podczas gdy w powershellu dostępne są tylko dwie części:

• HKLM
• HKLU

A co z HKEY_CLASSES_ROOT? Nie można? Da się!

Wykorzystaj do tego polecenie New-PSDrive:

New-PSDrive -Name HKCR -PSProvider Registry -Root HKEY_CLASSES_ROOT

Python ma ciekawe rozwiązanie dotyczące przepisywania wartości. Jest to szczególnie prawdziwe w przypadku, gdy za jednym zamachem chcesz przypisać kilka wartości. Instrukcja

my_tuple = (1,2,3,4)

to tzw. tuple packing – wartości 1,2,3,4 są konwertowane do tuple i zapisywane w zmiennej.

Instrukcja

(a,b,c,d) = my_tuple
print(a,b,c,d)

to tzw. tuple unpacking. Jest tworzony roboczy tuple (a,b,c,d) i do niego do każdej kolejnej wartości z tego tuple są przypisywane kolejne wartości z my_tuple, więc w efekcie a ma wartość 1, b ma wartość 2, c ma wartość 3, a d ma wartość 4

Dla ułatwienia (bo Pythonowcy lubią upraszczać sprawy) podczas wykonywania można pisać nawiasy, ale nie trzeba. Tutaj do a1, a2, a3, a4 najpierw przypisują wartości w sposób tradycyjny, a potem już wykonuję równoważne polecenia: Czytaj dalej »