Dziwne zadanie mi się trafiło. Przed odinstalowaniem serwera SQL  2000 trzeba się upewnić, że już nikt z niego nie korzysta. Ustaliliśmy, że „nikt nie korzysta” jest równoznaczne z „w ciągu tygodnia nikt się do niego nie zaloguje”. Dla pewności potem serwera nie odinstalujemy, tylko przełączymy bazy w offline i znowu trochę poczekamy.

Jak to zrealizować?

• Uruchamiasz profilera. Na szczęście na wersji 2000 jest.  Wybierasz zdarzenia Audit login/logout, podajesz ścieżkę do pliku, określasz czas wyłączenia trace itp.
• Skryptujesz wyklikaną definicję trace (File >> Script trace).
• Otwierasz utworzony skrypt i zmieniasz w nim ścieżkę
• Uruchamiasz go. Od tej pory w tle działa trace.
• Chcesz sprawdzić czy działa i tu pułapka. W wersji 2005+ napisałbym

Select * from sys.traces

Ale w 2000 takiego widoku nie ma. Za to jest procedura:

SELECT * FROM :: fn_trace_getinfo(default)

Czytaj dalej »

Na jednym z serwerów spotkałem problem polegający na tym, że do automatycznego startu skonfigurowany był SQL Server oraz SQL Server Agent. Niestety po resecie serwera wstaje tylko usługa SQL Server, a agent nie startuje. W logu aplikacyjnym można znaleźć informację, że Agent nie wystartował, bo nie mógł podłączyć się do SQL Servera. Na dodatek nie jest to kwestia uprawniwń, czy komunikacji, tylko po prostu opóźnień czasowych i timeoutu przy podłączaniu Agenta do Servera. Łatwo to swtierdzić, bo ręczne uruchomienie SQL Agenta udaje się bez problemów.

Dobrze byłoby móc trochę opóźnić start Agenta, tak by dać czas serverowi na pełne uruchomienie SQL-a. Niestety we właściwościach Agenta w Configuration Tools nic takiego nie ma! Tam nie ma, ale… w panelu sterowania >> narzędzia administracyjne >> usługi (services.msc) znajdziesz odpowiednią opcję.

Wystarczy odszukać SQL Server Agenta i we właściwościach wybrać „Startup type” zmieniając na „Automatic (Delayed Start)”. W każdym razie u mnie działa…

W artykule Okresowe kasowanie starych plików opisałem jak kasować pliki starsze od danej daty. Wykorzystałem tam polecenie forfiles. Poniżej kolejna przydatna instrukcja wykorzystująca fofiles. Usuwa WSZYSTKIE pliki z określonego katalogu wyświetlając przy okazji kilka informacji o tych plikach:

forfiles /P C:\temp /C „cmd /c echo File: @file ; Last modified date: @fdate @ftime && echo. && del @file”

Przypomnijmy, że to raczej „stare” rozwiązania. Nowsze sposoby skorzystają raczej z Powershella, tak jak to opisałem w Powershell: Usuwanie plików starszych niż 1 miesiąc

Czy to możliwe, że SQL server nie pamięta swojego ojca, czyli tego kto go zainstalował? Chyba niestety nie pamięta, ale jak każdy ma swoją metryczkę urodzin, którą są logi instalacyjne. Każde uruchomienie instalatora SQL serwera tworzy folder  o nazwie zgodnej z datą/godziną np.:

C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log\20121220_091600

W tym folderze znajdziesz plik/pliki o nazwie podobnej do:

sql_engine_core_inst_Cpu64_1

A w środku można odnaleźć katalog użytkownika, który instalował SQL-a:

MSI (s) (88:04) [09:25:59:578]: RESTART MANAGER: Session opened.
MSI (s) (88:04) [09:25:59:578]: TRANSFORMS property is now: :SqlRun01.mst;:InstID01.mst;:InstName01.mst
MSI (s) (88:04) [09:25:59:578]: PROPERTY CHANGE: Adding VersionDatabase property. Its value is '405′.
MSI (s) (88:04) [09:25:59:579]: SHELL32::SHGetFolderPath returned: C:\Users\rafal\AppData\Roaming
MSI (s) (88:04) [09:25:59:581]: SHELL32::SHGetFolderPath returned: C:\Users\rafal\Favorites
MSI (s) (88:04) [09:25:59:582]: SHELL32::SHGetFolderPath returned: C:\Users\rafal\AppData\Roaming\Microsoft\Windows\Network Shortcuts

I już masz nazwę użytkownika, który instalował serwer!

Polecam freewarowy program działający z Windows x32 i x64 do przeglądania plików minidump powstajcych podczas Bluescreen : Blue Screen View.

Ten program spodobał mi się bo:

1. Nie wymaga instalacji

2. Pozwala przeglądać pliki dump zdalnie

3. Po podświetleniu pliku minidump w menu można wybrać polecenie Search with Google!

select js.step_name, js.command, j.name from msdb.dbo.sysjobsteps js

join msdb.dbo.sysjobs j on js.job_id = j.job_id

where command like '%atlas%’

W logu aplikacyjnym systemu Windows został onaleziony zapis o  nieudanym uruchomieniu pakietu SSIS:

Package „Nazwa pakietu” failed.

Moje zadanie to odnaleźć kto uruchomił pakiet i dlaczego doszło do błędu. Z pierwszą częścią pytania nie ma większego problemu. W logu aplikacyjnym jest pole User i tam znalał się login użytkownika. Wszystko wskazauje na konto agenta. Teraz wypada wiec odnaleźć joba, który uruchomił ten pakiet.I tu mam problem, bo tych JOBów jest 60,  może i więcej. Z pomocą przychodzi takie polecenie:

select js.step_name, js.command, j.name  from msdb.dbo.sysjobsteps js
join msdb.dbo.sysjobs j on js.job_id = j.job_id
where command like '%nazwa_pakietu%’

No i proszę już ustaliłem, jaki to pakiet miał problem. Dodatkowo w logu aplikacyjnym znalazłem kolejne pisy uściślające przyczynę błędu w pakiecie.

Kawałek kodu, który uruchomi procedurę składowana na SQL i pobierze zwróconą przez nią tabelkę:

SqlConnection sqlConnection = new SqlConnection(strConnectionString);
SqlCommand sqlCommand = new SqlCommand(„sys.xp_fixeddrives”);
sqlCommand.CommandType = CommandType.StoredProcedure;
sqlCommand.Connection = sqlConnection;

SqlDataAdapter dataAdapter = new SqlDataAdapter(sqlCommand);
DataSet ds = new DataSet();

try
{
dataAdapter.Fill(ds, „drives”);
//do something – here loading data from table drives to list of strings
connElem.driveList = (from d in ds.Tables[„drives”].AsEnumerable() orderby d.Field<string>(„drive”) select d.Field<String>(„Name”)).ToList<string>();
}
catch (Exception ex)
{
//error handling
}

Wykorzystujemy stare poczciwe ADO.NET, ale w przypadku zapytań ad-hoc wykonywanych w aplikacji takie rozwiązanie dobrze się sprawuje.