W świecie SQL do raportu dotyczącego wielkości baz danych, zupełnie naturalne jest wykorzystanie poleceń języka TSQL.

W świecie SSAS odpowiednikiem tego języka jest XMLA. Czy to nie dziwne, że polecenia/zapytania buduje się w XML. No cóż – tak to ktoś wymyślił i nie zmienimy tego. Na pewno nie da się do SSAS wysłać zapytania SQL.

Co w takim razie zrobić kiedy trzeba zaraportować wielkość baz danych w SSAS? Z pomocą przyjdzie moduł, za pomocą którego można w bardzo prosty sposób (jeśli choć trochę się zna powershella) wysłać zapytanie do SSAS i skonsumować wynik w postaci obiektów o intuicyjnych właściwościach. Oto funkcja, która pobiera informacje o bazach danych SSAS i raportuje ich rozmiar i status:

function Get-SSASDBSize
{
    param($ServerName="localhost")
    $loadInfo = [Reflection.Assembly]::LoadWithPartialName("Microsoft.AnalysisServices")

    $server = New-Object Microsoft.AnalysisServices.Server
    $server.connect($ServerName)
    if ($server.name -eq $null) {
     Write-Output ("Server '{0}' not found" -f $ServerName)
     return
    }

    foreach ($d in $server.Databases )
    {
     Write-Output ( "{0}; {1}; {2};  {3}MB" -f $ServerName, $d.Name, $d.State, ($d.EstimatedSize/1024/1024).ToString("#,##0") )
    } 
}

Prawda, że krótkie? Po kolei: Czytaj dalej »

Czasami instalujemy SQL na tym co mamy. Pojawił się serwer i ktoś oczekuje, że zainstalujesz na nim silnik bazy danych. Istalujesz i już. Czasami jednak i na szczęście zdarza się to coraz częściej klient jest zainteresowany nie tylko zainstalowaniem serwera ale i jego wydajnością. Kluczowym parametrem determinującym pracę serwera jest prędkość dysków. Chyba dla każdego dysku da się tak zbudować test, w którym ten dysk wypada najlepiej i… to jest pewnie to, co robią producenci. Nam, administratorom, zależy jednak raczej na empirycznym i dość obiektywnym sptawdzeniu wydajności systemu dyskowego.

Jednym z programów, który może dla nas taką wstępną analizę przeprowadzić jest Disk Speed – https://gallery.technet.microsoft.com/DiskSpd-A-Robust-Storage-6ef84e62

Programu nie trzeba instalować – to wielka zaleta, bo instalacja programu na systemie produkcyjnym to czynność, którą ty – administrator bazy – być może musiałbyś uzgodnić z administratorem systemu operacyjnego. Program dostępny po prostu w postaci pliku exe jest wiec w tej sytuacji wygodniejszy.

Zaraz dokładniej omówię parametry, ale zrobimy to na przykładzie konkretnego testu:

.\diskspd.exe -b64K -d30 -t8 -o8 -h -r -w20 -L -c2G test_002.dat> diskspeed_report.txt

-b64K – oznacza rozmiar bloków w jakich są wykonywane operacje. Ponieaż zalecany rozmiar dysku dla SQL to 64 KB (rozmiar extentu = 8 * 8 KB) to wybór tej wartości przy testowaniu dysku pod SQL jest trafny Czytaj dalej »

Od dzisiaj na platformie Udemy dostępny jest kurs „Analiza danych w Python i PANDAS”. Z tej okazji przez krótki czas kurs będzie dostępny za darmo! To taki give-back dla społeczności, bez której samodzielne rozwiązywanie wielu problemów byłoby koszmarne.

Jeśli zdążyłeś/aś to poniższy link pozwoli na darmowe zapisanie się na szkolenie. Jeśli kurs został już sklasyfikowany jako płatny, to z tym linkiem możesz go kupić w najniższej możliwej cenie.

Zapisz się na kurs Analiza danych w Python i PANDAS!

A co w samym  kursie?

• Przygotowanie środowiska do analizy danych
• Wprowadzenie do modułu PANDAS
• Obiekt Data Series
• Obiekt Dara Frame
• Modyfikacja danych
• Multiindex i tabele przestawne
• Grupowanie danych
• Łączenie danych z wielu obiektów data frame
• Wykresy
• Export i import danych

W sumie ponad 13 godzin materiału wideo, a do każdej lekcji quiz i zadania do samodzielnego rozwiązania (z propozycją rozwiązań)

Zapraszam do świata Data Science!

Pełny komunikat błedu:

Winsock Error 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

Właściwie objaw Service Brokera był taki, że „nie działa”. W takim przypadku, jeśli tylko nie widać innych błędów (jak np. przepełniony log bazy danych z brokerem), należy będąc w tej bazie danych uruchomić polecenie:

SELECT * FROM sys.transmission_queue

Ostatnia kolumna z opisem statusu zawierała w/w komunikat. Komunikacja wysyłana przez service broker po prostu czeka, aż komunikaty uda się przesłać. Potencjalne przyczyny to:

• wyłączony docelowy host
• firewall między maszynami
• firewall lokalnie włączony na zdalnej maszynie
• itp – generalnie zawsze błąd na poziomie łączności na porcie

W tym przypadku został włączony firewall… Po zdefiniowaniu reguły na firewall komunikaty zaczęły po prostu spływać same 🙂

Pełny komunikat błędu:

Dialog security is unavailable for this conversation because there is no security certificate bound to the database principal (Id: 5). Either create a certificate for the principal, or specify ENCRYPTION = OFF when beginning the conversation.

Kiedy Service Broker nawiązuje połączenie to wykonuje to za pomocą kilku obiektów bazy danych takich jak sama usługa Service Broker, kolejka, konwersacja itp. Te obiekty mają swojego właściciela – jak wszystko w bazie danych więc jest to całkiem normalne. Jednak w Service Broker pod spodem działają certyfikaty – te służą do uwierzytelnienia. Niestety, jeśli coś majstrowałeś przy certyfikatach to takie powiązanie mogło się stracić. A jest ono dosyć proste

• obiekt należy do użytkownika
• użytkownik ma być zbindowany do certyfikatu

Sprawa będzie prosta.

Użytkownik powinien był być utworzony jakoś tak:

CREATE USER  …   WITHOUT LOGIN;

a certyfikat jakoś tak:

CREATE CERTIFICATE …   AUTHORIZATION [tutaj nazwa użytkownika] FROM  FILE=’…’

U mnie zadziałało od strzału!

Pomocny link:

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/8591016f-a1ca-43be-ab33-fddbcdec06b0/error-message-dialog-security?forum=sqlservicebroker

Pełna treść komunikatu z błędem to:

Connection handshake failed. The certificate used by the peer is invalid due to the following reason: Certificate not found. State 89

Istotne przy konfiguracji usług związanych z Service Brokerem opartym o certyfikaty jest to, że często nie liczy się nazwa certyfikatu, ale jego thumbprint (odcisk palca). Kiedy dwa serwery nawiązują połączenie jeden z nich mówi:

• chcę się połączyć z Tobą korzystając z certyfikatu XYZ
• a drugi serwer odpowiada – fajnie mam certyfikat XYZ i mam do niego klucz prywatny,  zacznijmy od autoryzacji….

W moim przypadku na tych dwóch rozmawiających serwerach były zainstalowane certyfikaty o tej samej nazwie, ale niestety były to kompletnie inne certyfikaty! Ich odciski palców się nie zgadzały!

Aby sprawdzić czy certyfikaty są takie same wykonałem na obu instancjach:

select * from sys.certificates

a potem porównałem pole thumbprint. Ponieważ się nie zgadzały wyeksportowałem certyfikat z jednego serwera (BACKUP CERTIFICATE – tylko klucz publiczny) i odtworzyłem go na drugim (CREATE CERTIFICATE…. FROM FILE=’..’). Ponieważ do certyfikatu był przywiązany jeszcze login, to i ten login  musiałem usunąć i odtworzyć.

Certyfikat występował w moim przypadku w bazie master (poziom instancji) i w bazie skonfigurowanej pod service broker. Wymieniłem go w obu miejscach

Pomocny link:

https://social.msdn.microsoft.com/Forums/Lync/en-US/7b4d9350-cf72-4d25-83d5-db39f1bb1c01/connection-handshake-failed-the-certificate-used-by-the-peer-is-invalid-due-to-the-following?forum=sqldatabasemirroring

Pewna aplikacja wymaga na serwerze podstawowego dostępu do serwera i do KAŻDEJ bazy danych, która znajduje się na serwerze.

Jakimś pomysłem mogłoby być stworzenie loginu z podstawowymi uprawnieniami na bazie (może nawet bez żadnych dodatkowych uprawnień – po prostu rola public) oraz użytkownika zmapowanego do tego loginu. Ten użytkownik też może być przypisany do podstawowej roli w bazie. Co jednak za tym idzie nowe bazy tworzone lub odtwarzane na tym serwerze musiałby mieć dodawanego tego użytkownika, a więc może jakiś job?

Jest jednak prostsze rozwiązanie. Loginowi wystarczy nadać uprawnienie CONNECT ANY DATABASE. Jeden GRANT na poziomie instancji i sprawa załatwiona!