Zdarza się, że programista aplikacji z jakiej ma również skorzystać skrypt powershell przewidział wyłacznie interfejs wymiany danych w postaci web service. Zobacz, jak łatwo można korzystać z web service z poziomu Powershell.

Tutaj skorzystamy z publicznie dostępnych web service http://www.webservicex.net

Po pierwsze należy utworzyć obiekt WebServiceProxy, który zostanie zainicjowany adresem web service. W tym przypadku sięgamy po webservice podający dane na temat lotnisk:

$a = New-WebServiceProxy 'http://www.webservicex.net/airport.asmx?WSDL’

Teraz w dokumentacji web service należałoby zobaczyć, jakie metody można wywoływać dla utworzonego web service proxy. Tutaj skorzystaliśmy z GetAirportInformationByCountry:

$a.GetAirportInformationByCountry(’Poland’)

Informacja zwrócona przez web service to oczywiście XML, jednak powershell domyślnie zaprezentuje go w postaci zwykłego tekstu. Aby jednak zobaczyć XML należy zrzutować ten tekst na [xml]. Tak utworzony XML ma element główny o nazwie NewDataSet a w nim element o nazwie Table. Korzystając więc z metody web service getAirportInformationByAirportCode można w czytelny sposób wyświetlić informacje o lotnisku w Poznaniu lub Katowicach:

(([xml]$a.getAirportInformationByAirportCode(’POZ’)).NewDataSet).Table
(([xml]$a.getAirportInformationByAirportCode(’KTW’)).NewDataSet).Table

Członkowie ODS PTI (Oddział Dolnośląski Polskiego Towarzystwa Informatycznego) mogą uzyskać darmowy dostęp do szkoleń!

• PowerShell dla administratora Windows – szkolenie, na którym możesz nauczyć się tworzyć skrypty z wykorzystaniem języka skryptowego PowerShell. W skład szkolenia wchodzi ponad 6 godzin nagrań video oraz quizy i zadania do samodzielnego rozwiązania
• SQL Server – wprowadzenie. Instalacja i narzędzia – szkolenie wprowadzające w tematykę SQL, prezentuje podstawy pracy z bazą danych MS SQL 2016 oraz pokazuje, jak zainstalować SQL Server i jak korzystać z podstawowych narzędzi administratora baz danych. Szkolenie jest dedykowane dla osób nie znających SQL. Około 2,5 godziny materiału video
• SQL Server – zapytania. Querying – szkolenie, które na przykładzie MS SQL Server uczy samodzielnego pisania zapytań SQL. Lekcje rozpoczynają się od przedstawienia najbardziej podstawowego polecenia SELECT, poprzez zaprezentowanie typów i funkcji SQL, a kończą się omówieniem JOIN, podzapytań i operacji na zbiorach danych. Około 5 godzin materiału video

Informacja ze strony aktualności ODS PTI

Niby zdefiniowanie serwera zlinkowanego do Oracle nie powinno być trudne. Jest sporo tutoriali, które pokazują jak to zrobić. Kiedy jednak coś nie chce zadziałać – robi się ciekawie.

Oto na co należy zwrócić uwagę:

1. Allow inprocess

we właściwościach profilera zaznacz Allow inprocess. Ta zmiana wymaga niestety późniejszego wykonania restartu SQL

2. TNS_ADMIN

Uruchom CMD, wpisz polecenie SET, wyświetlające zdefiniowane zmienne środowiskowe. Wśród tych zmiennych powinna występować również zmienna TNS_ADMIN wskazująca na lokalizację pliku definiującego lokalizację baz danych Oracle

3. PATH

W podobny sposób zweryfikuj czy katalog w którym jest zainstalowany Oracle oraz podkatalog bin znajdują się w ścieżce. Zależnie od katalogu w jakim zainstalowano Oracle ścieżka ta może się różnić:

Path=D:\applications\Oracle;D:\applications\Oracle\bin;…. and the others

4. Uprawnienia

Upewnij się, że konto MSSQL ma dostęp do katalogów i lokalizacji wskazanych w poprzednich punktach.

Kiedy wysyłasz wynik zapytania jako załącznik do maila korzystając z procedury sp_send_db_mail dzieją się dwie brzydkie rzeczy:

• do wygenerowanego pliku dołaczany jest tekst np 3 row(s) affected
• między nagłówkiem a danymi pojawia się kreska rozdzielająca te dwa elementy ———————————–

Z pierwszym problemem dosyć łatwo sobie można poradzić. W przekazywanym parametrze @query zamiast samego zapytania, np.:

SELECT id, name FROM database.dbo.table

zapisz

SET NOCOUNT ON;
SELECT id, name FROM database.dbo.table

Gorzej jednak z pomijaniem kreseczek… trzeba użyć sztuczki. Po pierwsze rezygnujemy z generowania nagówka dodając do sp_send_db_mail parametr: @query_result_header = 0

A jak teraz dodać warunek? Zapytanie zmień na UNION dwóch zapytań. Pierwsze z nich wygeneruje to co ma być w załączniku, a drugie zwróci właściwe dane. W efekcie mamy więc:

SET NOCOUNT ON;
SELECT 'id' AS id, 'name' AS name 
UNION ALL
SELECT id, name FROM database.dbo.table

Podczas wysyłania maila z załącznikiem (który jest wynikiem zapytania) pojawiał się bład:

Failed to initialize sqlcmd library with error number -2147024809

O co chodzi? Otóż polecenie wysyłające maila:

 EXEC msdb..sp_send_dbmail @profile_name='SQLProfile'
 , @recipients = @EmailRecipient
 , @subject = @EmailSubject
 , @body = @EmailContent
 , @body_format = 'HTML'
 , @query=@EmailQuery
 , @attach_query_result_as_file=1
 , @query_attachment_filename = 'Results.csv'
 , @query_result_separator = ','
 , @from_address = 'sql-team@company.com'
 , @reply_to = 'sql-team@company.com'

wykonywało query zdefiniowane tak:

SELECT name from dbo.table

sęk w tym, że w czasie wysyłania maila wcale nie jest to takie jasne w jakiej bazie danych jesteśmy… Wystarczyło zmienić zapytanie na następującą postać żeby zadziałało:

SELECT name from mydatabase.dbo.table

Zazwyczaj, konta w AD nie mają przypadkowych nazw. Nazwy muszą być nadawane zgodnie z przyjętą polityką. Np nazwy użytkowników mogą zawierać pierwsze litery nazwiska, a nazwy kont serwisowych mogą określać  środowiska w jakich są wykorzystywane, jakie usługi będą z nich korzystać, na jakich serwerach itp.

W takim przypadku dość łatwo przeprowadzić inwentaryzację kont wykorzysywanych przez daną aplikację na danym serwerze lub w danym środowisku. Wystarczy do tego takie polecenie:

Get-ADUser -Filter "name -like 'sys*sql*p'" | Select name| Sort name

Zakładając, że konwencja nazewnicza

• kontom wykorzystywanym przez usługi określa nazwy rozpoczynające się od SYS
• kontom wykorzystywanym przez SQL określa występowanie w nazwie liter SQL
• kontom wykorzystywanym w środowisku produkcyjnym nadaje nazwy kończące się na P

powyższe polecenie wyświetli najprawdopodobniej właśnie konta usług SQL w środowisku produkcyjnym. Filtry mogą być oczywiście o wiele bardziej złożone!

Dawno dawno temu kiedy chciałeś uruchomić usługę w systemie Linux dodawałeś plik o nazwie

S<XY><Name> oraz K<XY>Name

w katalogu /etc/init.d a potem w folderach /etc/rc[12345].d tworzyłeś link do odpowiednich plików. Pliki S* były uruchamiane podczas przechodzenia systemu do danego, określonego przez numer katalogu tzw. run-level, w celu uruchomienia usługi a pliki K miały za zadanie kończyć pracę tych usług. Liczby <XY> określały natomiast kolejność w jakiej usługi będą uruchamiane. Proste i logiczne.

W miarę ewolucji RedHat/Fedory, postanowiono jednak skorzystać z mechanizmów charakterystycznych dla systemd. Generalnie init.d ani rc2.d, rc3.d itd. nie są wykorzystywane.

Podczas definiowania nowej usługi należy korzystać z plików o nazwach

<ServiceName>.service

znajdujących się w

/etc/systemd/system

Jeśli instalujesz nowy serwis to należy w tym folderze utworzyć nowy plik, którego zawartość może wyglądać np. tak (przykład dla usługi Sybase): Czytaj dalej »