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

Jak SQL wyznaczy średnią z 10 NULL i 20 ?

NULL zostanie pominięte, mamy więc (10+20)/2 = 15

My jednak chcielibyśmy mieć NULL rozpatrywane jako zero: (10 + 0 + 20) / 3 = 10

Jak zaimplementować taką interpretację NULL w raporcie SSRS?

Na początku zakładam tabelę z przykładowymi danymi:

zakładam tabelę z przykładowymi danymi:

use tempdb
go
 
create table test
(
 [year] int,
 [quarter] int,
 [value] int
)
go
 
insert test values
 (2018,1,10),
 (2018,2,20),
 (2018,3,30),
 (2018,4,40),
 (2019,1,100),
 (2019,2,200),
 (2019,3,NULL),
 (2019,4,NULL)

teraz tworzę raport, który pracuje na tych danych, z grupowaniem po roku. Definicja data set:

SELECT [year],[quarter],[value] FROM test

wygląd raportu:

grupowanie: Czytaj dalej »

Konfigurując połączenie z Internetem  dla maszyn wirtualnych pracujących pod kontrolą Hyper-V, w pierwszej kolejności tworzy się definicję wirtualnej sieci

Tutaj została utworzona siec INTERNAL, która jest siecią typu Internal, tzn. powstaje nowa wirtualna sieć, do której wpięta zostanie maszyna wirtualna i fizyczna maszyna hostująca maszynę wirtualną. Wpięcie maszyny wirtualnej do tej sieci odbywa się w ustawieniach maszyny: Czytaj dalej »

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!