Zdarza się, że na dysku znajdziesz dzwiwaczny folder, który powstał w trakcie intalacji lub aktualizacji i chcesz go usunąć, ale pojawia się komunikat o braku uprawnień. Jak to? Ja – administrator i brak uprawnień?

Z jakiegoś powodu te „dziwne” foldery są pozabezpieczane! Dobrze się zastanów nim je rzeczywiście usuniesz lub w nich coś pozmieniasz…

No cóż, przyczyna to zwykle zupełnie inny właściciel folderu, brak włączonego dziedziczenia uprawnień i wreszcie brak nadanych uprawnień. Wszystko to można oczywiście naprawić tysiącem kliknięć, ale… można też posłużyć się PowerShellem.

Oto przykład funkcji, którą się posłużyłem – szczegóły poszczególnych kroków niżej: Czytaj dalej »

Jeśli potrzebujesz listę członków grupy AD posłuż się jednym z poleceń:

dsquery group -name „GroupName” | dsget group -members -expand

lub już typowo z PowerShella

Get-AdGroup „GroupName” | Get-AdGroupMember | Select Name

Konfiguracja TSM TDP znajduje się w 2 plikach znajdujących się domyślnie w  „C:\Program Files\Tivoli\TSM\TDPSql”

• tdpsql.cfg – plik zawiera definicje dot. połaczenia do serwera SQL
• dsm.opt – plik zawiera konfiguracje połączenia do serwera TSM

Kiedy chcesz wykonać kopię loga transakcyjnego uruchom:

tdpsqlc BACKUP * LOG /BACKUPMETHOD=LEGACY /CONFIGFILE=.\tdpsql.cfg /TSMOPTFILE=.\dsm.opt

o ile korzystasz z domyślnej lokalizacji plików konfiguracyjnych to można opuścić opcje wskazujące te pliki

Żeby wyświetlić dostępne kopie skorzystaj z:

tdpsql QUERY TSM /CONFIGFILE=.\tdpsql.cfg /TSMOPTFILE=.\dsm.opt

Jeżeli chcesz wyświetlić tylko FULL BACKUP dla bazy my_db użyj:

tdpsql QUERY TSM my_db Full /CONFIGFILE=.\tdpsql.cfg /TSMOPTFILE=.\dsm.opt

W/w polecenie pokazuje tylko ostatnią (aktywną) kopię bazy. Jeśli chcesz wyświetlić wszystkie kopie  dodaj parameter /ALL

tdpsql QUERY TSM master Full /CONFIGFILE=.\tdpsql.cfg /TSMOPTFILE=.\dsm.opt /ALL

Podobnie można wyświetlić wszystkie kopie loga transakcyjnego dla bazy my_db

tdpsqlc query tsm my_db Log=* /CONFIGFILE=.\tdpsql.cfg /TSMOPTFILE=.\dsm.opt /ALL

Można też wyświetlić wszystkie dostępne kopie niezależnie od rodzaju kopii:

tdpsqlc query tsm cQ.OLTP * /CONFIGFILE=.\tdpsql.cfg /TSMOPTFILE=.\dsm.opt /ALL

Jak w takim razie wykonać odtworzenie bazy danych?

Po pierwsze należy wyświetlić dostępne kopie. Tutaj listuję tylko kopie bazy my_db.  Korzystając z plików opt i cfg można siegnąć „krzyżowo” do serwera TSM przechowującego kopie dla innego serwera SQL. W takim przypadku przyda się opcja /FROMSQLSERVER, która pozwoli pobrać backupy wskazanego przez tą opcję serwera SQL

Tutaj będziemy łączyć się do instancji testowej zdefiniowanej w pliku INSTTST.cfg, ale podczas listowania dostępnych kopii interesować nas będą wyłacznie kopie z SQL SERVER01\INSDEV

.\tdpsqlc query tsm my_db full /configfile=.\tdpsql_INSTTST.cfg /tsmoptfile=.\dsm.opt /FROMSQLSERVER=SQLSERV01\INSTDEV

Oczywście jeżeli chcesz zobaczyć wszystkie kopie to dodaj przełącznik /ALL

.\tdpsqlc query tsm my_db full /configfile=.\tdpsql_INSTTST.cfg /tsmoptfile=.\dsm.opt /FROMSQLSERVER=SQLSERV01\INSTDEV /ALL

Polecenie QUERY wraz z informacja o backupie, wyświetla też identyfikator tego backupu. Jest on oznaczony jako OBJECT. Podczas odtwarzania właśnie ten obiekt jest potrzebny. Do odtworzenia należy przekazać praramtery:

• nazwę bazy do odtworzenia – tutaj my_db
• nazwę bazy, do której należy się odtworzyć: my_db_restored
• ewentulane polecenia relocate określające do jakich lokalizacji należy zapisać pliki odtwarzanej bazy danych
• identyfikator kopii do odtworzenia –  opcja object
• plik config definiujący serwer docelowy, na którym nastąpi odtworzenie
• plik opt definiujący połączenie do serwera TSM

.\tdpsqlc restore my_db /into=my_db_restored /relocate=my_db_data /to=”D:\data\my_db_restored.mdf” /relocate=my_db_log /to=L:\logs\my_db_log.ldf /object=”20180105090206\00000C64″ /configfile=.\tdpsql_INSTTST.cfg /tsmoptfile=.\dsm.opt /FROMSQLSERVER=SQLSERV01\INSTDEV

Załóżmy, że masz taki tekst:

message = 'Document "cv.doc" was printed on printer: XEROX'

z tego napisu chcesz wyciąć  tylko nazwę dokumentu cv.doc. Można by to zrobić posługując się zwykłymi poleceniami pracującymi na napisach, ale nie jest to zbyt wygodne rozwiązanie – trzeba się sporo przy tym napracować, a na dodatek kod będzie nieczytelny, trudny do poprawy i niewydajny.

Za to z pomocą mogą przyjść wyrażenia regularne, np

\"(.*)\"

• Kropka to dowolny znak
• * oznacza dowolną ilość wystąpień tego znaku
• Nawiasy służą do grupowania
• \” – oznacza dopasoanie/wyszukiwaniecudzysłowiów

Żeby skorzystać z wyrażeń regularnych zaimportuj moduł re a potem funką findall wyszukaj wystąpień podnapisów zawartych w tekście

import re
matches = re.findall(r'\"(.*)\"',message)
for m in matches:
     print(m)

Można mieć wątpliwości w jaki sposób porównywać ze sobą wartości, bo dostępne są dwie podobne instrukcje:

• operator porównania wartości zmiennych ==

oraz

• operator porównania zmiennych „is”

Najpierw zobaczmy sytuację kiedy oba operatory zwrócą te same wyniki:

a = 'mouse'
b = 'mouse'

#sprawdzam czy a == b
print (a==b)

#sprawdzam czy a i b to ta sama zmienna (operator is)
print (a is b)

#is sprawdza czy 2 zmienne są identyczne - identyfikator zmiennej zwraca funkcja id()
print(id(a),id(b))

W tym przypadku operator == i is zadziałał tak samo, a wywołane na końcu funkcje id() zwracają taką samą liczbę. Co się jednak stanie jeśli zmienimy skrypt o tak:

a = 'mouse'
b = 'mous'
b+='e'

#sprawdzam czy a == b
print (a==b)

#sprawdzam czy a i b to ta sama zmienna (operator is)
print (a is b)

#is sprawdza czy 2 zmienne są identyczne - identyfikator zmiennej zwraca funkcja id()
print(id(a),id(b))

No cóż. Teraz różnice już są! Operator == nadal zwraca True, bo w zmiennej a i b jest taka sama wartość. Jednak porównanie operatorem is zwraca False. Dlaczego? Bo a i b to różne zmienne, które wskazują w różne miejsca w pamięci. Widać to kiedy funkcja id zwraca różne identyfikatory dla tych zmiennych

Podsumowujac

== bada czy wartości zmiennych są sobie równe. Ten operator powinien być używany do testowania czy wartości zmiennych są sobie równe różne itp

is jest bardziej zaawasowanym operatorem. Sprawdza on, czy dwie zmienne wskazują w to samo miejsce w pamięci, czyli innymi słowy czy te dwie zmienne są takie same.

Service Broker jest dość trudny do zdiagnozowania. Mam wrażenie, że jak działa  to jest dobrze, a jak nie działa, to… nie działa i jest niedobrze.

Na całe szczęście, nawet jeśli początkowe metody zawiodą, to jest jeszcze szansa wypatrzenia jakiegoś problemu przy pomocy Profilera.

Zazwyczaj zaczynam od zaznaczenia wszystkiego w grupie broker. I tak np. dzięki zdarzeniu

Broker: Message Undeliverable

udało mi się złapać błąd:

This message could not be delivered because the security context could not be retrieved.

Hmm, ale co to oznacza? Skoro mowa jest o security context to należałoby przejrzeć dostępne certyfikaty, loginy, uprawnienia itp. Przydatna może się okazać druga sesja profilera, w której skorzystamy ze zdarzeń z grupy Security Audit.  Jest tu kilka zdarzeń swiązanych z brokerem. W moim przypadku udało się złapać:

Audit BrokerConversation

Certificate not found

No to jestem w domu! Brakowało certyfikatu!

Często (prawie zawsze) używam właśnie tej metody instalacji SQL. Jeśli jednak w instalacji pojawia się coś nowego, czego do tej pory nie isntalowałem, to plik ini należy w odpowiedni sposób zaktualizować. Nazwy parametrów są zgodne z parametrami, które można przekazaywać do pliku setup.exe i są one omówione w tym artykule:

https://docs.microsoft.com/en-us/sql/database-engine/install-windows/install-sql-server-from-the-command-prompt?view=sql-server-2017