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

Masz plik na dysku ze zdjęciem lub certyfikatem lub czymkolwiek innym. Plik jest binarny. Jak go wstawić do zmiennej lub do tabeli?

USE tempdb
GO

CREATE TABLE MyBinary(Blob VARBINARY(MAX))
GO

DECLARE @Data VARBINARY(MAX)
 SET @Data = (SELECT BulkColumn FROM Openrowset( Bulk 'C:\temp\MyCertificate.cer', Single_Blob) as img)
INSERT MyBinary VALUES(@Data)
GO

W moim przypadku chciałem korzystać z tak zaimportowanego certyfikatu w skrypcie, żeby uruchamiając skrypt na danym systemie nie trzeba było kopiować żadnych dodatkowych plików na czas instalacji. Innymi słowy chciałem mieć zmienną binarną zadeklarowaną w skrypcie. Moja „sztuczka” polegała na wyeksportowaniu danych tabeli MyBinatry i odpowiedniej modyfikacji skryptu. W tym celu:

• Kliknij prawą myszką na bazie danych i wybierze Tasks >> Generate Scripts
• W kreatorze zaznacz tylko tabelę MyBinary
• W następnym oknie kreatora kliknij Advanced i zmień „Schema only” na „Data only”
• W wygenerowanym skrypcie znajdzie się dłuuuuga wartość, która jest reprezentacją kolumny binarnej

Teraz udało mi się więc napisać fragment skryptu w  postaci (część binarna jest dla skrócenia wycięta):

DECLARE @DataCert VARBINARY(MAX)
SET @DataCert = (0x308...129)

No dobrze. A jak teraz tego rodzaju zmienną zapisać w postaci pliku binaranego z powrotem na dysku? Skorzystamy z funkcji OLE, które zazwyczaj ze względu na wymogi bezpieczeństwa są wyłaczone, dlatego skrypt najpierw sprawdzi czy opcja ‚Ole Automation Procedures’ jest wyłączona, zapamięta to, włączy jeśli trzeba, a na końcu przywróci oryginalne ustawienia. Środkowa część skryptu to kilka kolejnych kroków, które należy wykonać aby dane zapisać na dysku:

DECLARE @DataCert VARBINARY(MAX)
SET @DataCert = (0x308...129)

DECLARE @certPath varchar(50) = 'C:\temp\MyCertificate.cer'
DECLARE @handle int

EXEC sp_OACreate 'ADODB.Stream', @handle OUTPUT; 
EXEC sp_OASetProperty @handle, 'Type', 1; 
EXEC sp_OAMethod @handle, 'Open'; 
EXEC sp_OAMethod @handle, 'Write', NULL, @DataCert; 
EXEC sp_OAMethod @handle, 'SaveToFile', NULL, @certPath, 2; 
EXEC sp_OAMethod @handle, 'Close'; 
EXEC sp_OADestroy @handle; 

IF @initialOLEAutomationOption = 0 
BEGIN
 EXEC sp_configure 'Ole Automation Procedures', 0
 RECONFIGURE WITH OVERRIDE
END

Jedna prosta komenda:

Get-winEvent -ComputerName $env:COMPUTERNAME -filterHashTable @{logname =’Microsoft-Windows-FailoverClustering/Operational’; id=1641}| ft -AutoSize -Wrap

Właściwie każdy wie, że takie zdarzenia trafiają do loga. Spryt  polcecenia polega na wyfiltrowaniu tylko tych zdarzeń, które rzeczywiście są potrzebne.

Microsoft już dawno temu poinformował o tym, że Profiler nie będzie dalej rozwijany i zaprosił do korzystania z extended events. Rzeczywiście extendend events mają o wiele wiecej możliwości monitorowania aktywności systemu i dodatkowo robią to znacznie wydajniej. Gdyby ktoś jednak nadal nie był przekonany co do stosowania extended events, to może ten wykres go przekona… ?

Wykres prezentuje ilość zdarzeń, które mogą być monitorowane przy pomocy extended events i przy pomocy profilera. Podczas gdy  ilość extended events od wersji 2008 powiększyła się 4-krotnie, ilość zdarzeń dla profilera stoi na poziomie 180!

Kiedy pracujesz z PowerShell, konsola śledzi i zapamiętuje każdy twój ruch. Dzięki temu można przejrzeć listę wykonywanych do tej pory poleceń naciskając strzałkę w górę. Do przejrzenia wcześniej wykonanych poleceń można sie także posłużyć poleceniem

Get-History

Posiadając listę do tej pory wykonanych poleceń, możesz chcieć ponownie uruchomić jedną z nich. Da się to zrobić powołując się na numer komendy w historii uruchamiając

Invoke-History

Tak to działa w praktyce:

Jeśli chcesz tylko pobrać listę komend i umieścić ją w schowku wykonaj:

Get-History | Select -expand CommandLine | clip

Podczas konfiguracji FILESTREAM dwa razy wykonuje się podobne czynności:

• W SQL Configuration Manger, należy we właściwościach usługi SQL na karcie FILESTREAM wybrać jedną z dostępnych opcji:
  
• A następnie w SQL Management Studio wykonać polecenie SP_CONFIGURE zmieniając ‚filestream access level’

  EXEC sp_configure 'filestream access level',2
  GO
  RECONFIGURE
  GO

Czy te dwa kroki się powielają? Czy można wykonać jeden a drugiego już nie?

Otóż nie!

Pierwsza część wykonuje fragment konfiguracji systemu operacyjnego, którego nie można wykonać z wewnątrz procesu SQL

Druga część odpowiada za włączenie opcji na poziomie silnika bazy danych

Pierwsza część wymaga uprawnień lokalnego administratora, a druga sysadmina.

To cały powód!

FILESTREAM Configuration and Setup Changes in SQL Server 2008 February CTP