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:
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:
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 »
Im bardziej skomplikowana i zabezpieczona jest infrastruktura sieciowa, tym trudniej jest diagnozować występujące problemy. Weźmy na przykład kwestię serwera, do którego nie można się połączyć przez RDP lub do serwera SQL. Jeśli serwer występuje w tej samej sieci, w tym samym segmencie, to jednym z podstawoych testów, jakie mogły by być wykonane jest ping sprawdzający czy serwer w ogóle odpowiada i jest włączony. Niestety jeśli między maszynami znajdują sie zapory sieciowe (firewall), to ping może nie działać (wyłączony ICMP), ale połączenie RDP (port TCP/3389. UDP/3389) lub SQL (tcp/1433) mogą być dostępne.
Do niedawna w takich przypadkach korzystałem z polecenia portqry.exe, np
portqry -n <server_name> -t <protocol> -e <port_number> portqry -n CANTOR10 -t tcp -e 3389
Nie wszyscy są świadomi, że właściwie na nowszych systemach wcale nie ma potrzeby korzystania z zewnętrznego programu. Można korzystać z cmdlet Test-NetConnection:
Test-NetConnection -computer CANTOR10 -protocol tcp -port 3389
Można zaryzykować stwierdzenie, że Test-NetConnection to taki „ping na port”. Niektórzy w celu sprawdzenia otwarcia portu korzystają również z polecenia telnet otwieranego na określony port. Wydaje się jednak, że Test-NetConnection robi to co należy i jak należy w stosunkowo prosty sposób.
