Tym razem przytrafił się problem z uruchomieniem Reporting Services. Podczas startu  w pliku loga pojawiał się wpis:

ERROR: Error creating HTTP endpoint. System.IO.FileLoadException: The process cannot access the file because it is being used by another  process. (Exception from HRESULT: 0x80070020)

Kilka razy ostatnimi czasy walczyłem z SSRS nie startującym z tego powodu, że uprawnienia nie były wystarczające. Dlatego pierwszy test to dopisanie użytkownika RS do grupy lokalnych administratorów. Ale tym razem to nie pomogło.

No więc może przeczytajmy dokładnie komunikat o błędzie.  Czy ktoś może rzeczywiście używać portu, który chciałem przypisać do RS?

Netstat -a

wyświetlił port jako LISTENING mimo zatrzymanego SSRS. A więc coś tam jest. A co takiego?

Netstat -anb

to polecenie pokazuje też jaki program nasłuchuje na danym porcie. Tym razem trafił się tomcat.exe… Wobec tego zmiana numeru portu powinna pomóc! Po zmianie numeru portu SSRS startuje.

Polecenie DBCC CHECKDB(’baza’) WITH NO_INFOMSGS kończy się błędem podobnym do:

DBCC results for 'TableWithDocuments’.

Msg 7904, Level 16, State 2, Line 1
Table error: Cannot find the FILESTREAM file „00000430-00018275-0025” for column ID 12 (column directory ID 10403222-f031-4fb6-bf65-0dc85ff92593) in object ID 1022331424, index ID 1, partition ID 72059854113556480, page ID (1:3846), slot ID 27.

Zapytanie do tabeli z filestream kończy się błędem:

FILESTREAM file named with GUID '31312df2-3tt7-4951-b96b-56b244d8b2cc’ that belongs to FILESTREAM data file ID 0x0 does not exist or cannot be opened.

Co ciekawe odtwarzane backupy również mają w/w błędy, chociaż przed, jak i po backupach baza była wielokrotnie sprawdzana przez CHECKDB… Czyżby CHECKDB źle działało i nie wykryło wcześniej błędu przez co dane zawarte w backupach zawierają błędy? A może CHECKDB działa ppoprawnie, ale mechanizm wykonania kopii zapasowej jest uszkodzony i sporządza złe backupy?

Ani to ani to! Otóż na komputerze pracuje antywirus, który co po niektóre pliki rozpoznał jak zawirusowane i przesunął je do kwarantanny. W takim dziwny przypdaku sprawdź więc, czy pliki FILESTREAM nie trafiły do kwarantanny.

Jakim cudem do sieci trafiły zainfekowane pliki? Podczas audytu często do sprawdzenia poprawności działania systemów antywirusowych tworzy się „niby wirusy” (http://www.mobilo24.eu/test-programu-antywirusowego-eicar-czy-dziala-skanowanie-w-czasie-rzeczywistym/). W tym przypadku sztucznie zawirusowane pliki zostały zapisane do bazy danych do FILESTREAM. Specjalnie skonfigurowany program antywirusowy pomijał pliki FILESTREAM podczas skanowania. Jednak w pewnym momencie zainstalowano inny program antywirusowy, który skanował wszystko. Ten antywirus usunał niby-zakażone pliki FILESTREAM. Kiedy próbowaliśmy odtwarzać bazę z kopii, antywirus na bieżąco usuwał, jego zdaniem, zakażone pliki.

W tym przypadku więc działa i CHECKDB i BACKUP i nawet program antywirusowy. Zawinił hmmm… czynnik biologiczny, czyli audytor, a może FILESTREAM mógłby lepiej współpracować z antywirusem?? Ale to może dopiero w wersji SQL 2020

Poniżej kilka zapytań, które pomogą wykonać pierwsze kroki przy troulbeshootingu tabel wykorzystujących filestream:

Parę informacji o grupie plików typu FILESTREAM:

select * from sys.data_spaces where type=’FD’;

Gdzie znajdują się pliki i katalogi, w których SQL server przechowuje dane FILESTREAM:

select * from sys.database_files where type = 2;

Jakie tabele korzystają z filestream:

select * from sys.tables where filestream_data_space_id is not null

Jakie kolumny tabel zawierają dane przechowywane w FILESTREAM:

select * from sys.columns where is_filestream =1

Połączenie oby wyników powyżej razem – które tabele i jakie kolumny tych tabel korzystają z filestream

select t.name, c.name from sys.columns c

join sys.tables t ON t.object_id=c.object_id

where is_filestream=1

I wreszczie próbny odczyt danych z kolumny typu FILESTREAM:

SELECT *, CAST (FileContent AS VARCHAR(MAX))FROM MyTable

Gdyby coś było nie tak z rekordem (np. ktoś usunął plik z dysku), to w/w zapytanie się nie uda i pozwoli ci ustalić, który rekord zawiera braki.

Należy sprawdzić czy procedura „mail” z bazy danych X jest wykorzystywana przez jakąkolewiek inną procedurę w jakiejkolwiek innej bazie danych na instancji.

Pomysł był następujący:

1. Przejdźmy przez wszystkie bazy danych

2. W każdej wylistujmy wszystkie procedury

3. Dla każdej procedury pobierz jej tekst

4. Przeszukaj ten tekst w poszukiwaniu danego słowa i wyświetl wynik

Jeśli masz ochotę skorzystać, to w skrypcie poniżej odkomentuj ostatnią linijkę i zmień wywołanie procedury podając inne szukane przez Ciebie słowo.

Slowo w procedurach

Administrator danych chce wyłączyć databaase mail xps. Polecenie proste

sp_configure 'database  mail xps’, 0
GO
RECONFIGURE
GO

ale… może najpierw sprawdźmy, czy ktoś używa poleceń sp_send_dbmail!

Można przejrzeć logi:

W poprzednim wpisie pokazałem jak przeszukać errorlog w poszukiwaniu pewnego słowa. Error log poddlega roll over, więc np. po restarcie SQL powstaje nowy plik, a porzprzedni jest przekopiowywany na nazwę z nr 1, ten z nr 1 na 2 itd.

Oto skrypt, który wyszuka wskazanych słów we WSZYSTKICH logach:

–Kto wylaczył trace – informacja zapisana w error logu

Służy do tego procedura

xp_readerrorlog <numer_loga>, <rodzajLoga>, <szukane słowo1>, <szukane słowo 2>

Log errorlog podlega procesowi roll over. Numer loga pozwala określić, który log ma być przeszukany,

Masz 2 rodzaje logów: Errorlog SQL servera i  SQLAGENT.OUT – log sql server agenta. Aby przeszukać log SQL-a wpisz jako <RodzajLoga> 1. Aby przeszukać log agenta wpisz 2.

Możesz szukać tylko jednego słowa – wtedy podaj <szukane słowo 1>. Jeśli chcesz zawęzić wynik wpisz jeszcze <szukane słowo 2>

http://blog.sqltechie.com/2011/03/xpreaderrorlog-parameter-detail.html