Jak sprawdzić rzeczywiste wykorzystanie plików danych i logu transakcyjnego?
Praktyczne zapytania T-SQL pokazujące rozmiar, zajętość i wolne miejsce w plikach danych oraz logu transakcyjnym SQL Server.
DBA
Autogrowth jest włączony, a plik bazy nadal się nie rozszerza. Jak to możliwe?
Autogrowth w SQL Server nie gwarantuje, że plik bazy danych zawsze się rozszerzy. Sprawdź najczęstsze przyczyny, zapytania diagnostyczne i dobre praktyki zarządzania przestrzenią.
SQL Server Agent, Backup i Restore: dwa praktyczne przewodniki dla DBA
Dwa praktyczne e-booki dla administratorów SQL Server: automatyzacja i kontrola jobów SQL Server Agent oraz kompletna strategia backupu, restore, RPO, RTO i procedur awaryjnych.
SQL Server Backup: zielony job to jeszcze nie strategia odtwarzania
Zielony status joba backupu w SQL Server Agent to dopiero początek. Prawdziwa strategia zaczyna się wtedy, gdy umiemy odtworzyć bazę do właściwego punktu w czasie i w akceptowalnym czasie.
Filozofia świadomego DBA
Świadomy DBA to nie tylko operator poleceń.
To filozof systemu – ktoś, kto rozumie przyczynę przed reakcją.
SQL Server to narzędzie, ale też nauczyciel.
Uczy pokory wobec złożoności, dyscypliny w dokumentowaniu i cierpliwości w analizie.
Pokazuje, że każda decyzja ma koszt, a każda optymalizacja ma kontekst.
Świadomość zaczyna się tam, gdzie kończy się rutyna.
Widzisz nie tylko wynik zapytania, ale jego wpływ na tempdb.
Nie tylko CPU, ale scheduler, który za nim stoi.
Nie tylko alert, ale przyczynę, która go wywołała.
Wewnętrzne mechanizmy pamięci SQL Server – co się dzieje w Buffer Pool
Za każdą operacją stoi pamięć: Buffer Pool, Memory Clerks, Lazy Writer i PLE (Page Life Expectancy).
To serce SQL Servera – a każdy spadek PLE to zawał.
Zrozumienie, jak SQL zarządza stronami danych, to klucz do prawdziwego tuningu.
„Co nie zmieści się w pamięci, wróci po zemstę z dysku.”
🧠 Architektura pamięci SQL Server
SQL Server ma własny system zarządzania pamięcią – niezależny od systemu operacyjnego.
Dzięki temu może reagować szybciej i bardziej precyzyjnie na obciążenie.
Resource Governor – ogranicz CPU, nie ludzi
Resource Governor – ogranicz CPU, nie ludzi
Nie każdy proces zasługuje na 100% CPU.
Nie każdy użytkownik powinien mieć wolną autostradę do rdzeni.
Resource Governor to strażnik równowagi – ustawia granice, zanim chaos stanie się faktem.
SQL Server potrafi być aż zbyt uprzejmy.
Jeśli aplikacja klienta zacznie mielić raporty z JOIN-ami jak spaghetti, serwer grzecznie rzuci w to wszystkie swoje wątki – a reszta użytkowników zostaje w korku.
Resource Governor mówi: dość.
Audyt uprawnień – kto, co i kiedy?
Zaufanie jest dobre, ale SERVER AUDIT jest lepszy.
Audyt pozwala Ci wiedzieć, kto nadał, odebrał lub zmienił uprawnienia w Twojej bazie.
Nie potrzebujesz narzędzi firm trzecich — wszystko masz wbudowane w SQL Server.
Wystarczy kilka poleceń: CREATE SERVER AUDIT, CREATE DATABASE AUDIT SPECIFICATION, i masz pełny ślad bezpieczeństwa.
„Bez logu nie ma dowodu. Bez dowodu nie ma bezpieczeństwa.”
Dlaczego audyt?
Uprawnienia to władza. A każda władza powinna zostawiać ślady.
W systemach z wieloma administratorami (lub z zespołem deweloperów z prawami sysadmina) często nie sposób ustalić, kto co zmienił.
Audyt pozwala przywrócić porządek i odpowiedzialność.
FCI czy AlwaysOn AG – jak SQL trzyma fason po awarii
FCI (Failover Cluster Instance) chroni instancję, AG (AlwaysOn Availability Groups) chroni dane.
Oba mają swoje miejsce, oba swoje pułapki.
FCI to wspólny storage i klasyczna niezawodność. AG to elastyczność, replikacja i odczyty.
„Awaria to egzamin z tego, jak myślałeś, zanim się zaczęła.”
Architektura i filozofia
FCI to jeden serwer logiczny rozłożony na kilka węzłów klastra.
Jeśli jeden padnie – cały SQL „przenosi się” na inny, korzystając z tego samego storage’u.
To oznacza: zero utraty danych, ale pełna zależność od wspólnego magazynu.
W skrócie – chronisz instancję, nie bazę.
Backup VLDB >4TB – jak nie wpaść w pułapkę
Przy małej bazie backup to prosty przycisk.
Przy bazie 4 TB i więcej — to strategia.
SQL Server potrafi wykonać kopię dowolnej wielkości bazy, ale granicą staje się infrastruktura: I/O, sieć, tempdb, a czasem… ludzkie złudzenie, że „backup się zrobi”.
W świecie VLDB (Very Large Database) backup nie jest operacją — to proces logistyczny.
Wymaga planowania, testów, segmentacji i chłodnej kalkulacji: ile danych, w jakim czasie, dokąd i po co.
Ghost Records – duchy w bazie danych
W bazie danych straszy.
Nie w horrorze, ale w DMV: sys.dm_db_index_physical_stats.
Gdy kasujesz wiersz, SQL Server nie usuwa go od razu — zostawia ducha (ghost record), który czeka, aż ghost cleanup task wykona egzorcyzm.
To dzięki temu ROLLBACK może przywrócić dane, a DELETE nie musi blokować świata.
System woli oznaczyć rekord jako „martwy”, niż ryzykować chaos w strukturze stron danych.
„To, czego nie widzisz, nie znaczy, że tego nie ma — zwłaszcza w bazie danych.”
DELETE vs TRUNCATE – kiedy SQL Server naprawdę sprząta
Oba polecenia usuwają dane. Ale jedno robi to z manierą, drugie z miotłą.DELETE i TRUNCATE wyglądają podobnie — efekt końcowy to pusta tabela.
Pod maską SQL Server jednak wykonuje zupełnie inne operacje.
DELETE – chirurg z lupą
DELETE działa wiersz po wierszu. Każdy usunięty rekord jest logowany w transakcyjnym logu (transaction log), dzięki czemu można cofnąć operację (ROLLBACK).
To daje precyzję — można użyć WHERE, aktywują się TRIGGERY, a relacje z kluczami obcymi są respektowane.
Ale cena jest jasna: log rośnie, a wydajność spada proporcjonalnie do liczby usuwanych wierszy.
Co widzi Query Processor zanim Ty klikniesz Execute?
Kiedy wpisujesz SELECT i wciskasz „Execute”, zaczyna się coś magicznego. Ale nie w takiej kolejności, jak myślisz.
SQL Server nie jest naiwnym tłumaczem Twojego kodu – to kompilator logiki zapytań, który widzi świat zupełnie inaczej. Zanim linijka SELECT dotrze do procesora zapytań, tekst T-SQL zostaje zanalizowany, przepisany, znormalizowany i zoptymalizowany. Efektem nie jest „wykonanie kodu”, ale plan zapytania – precyzyjna instrukcja dla silnika relacyjnego, jak dobrać dane możliwie najtaniej.
I właśnie tu pojawia się pierwszy paradoks: SQL Server wcale nie zaczyna od SELECT.
Najpierw patrzy na FROM – ustala źródła danych, sprawdza połączenia (JOIN), a następnie przechodzi przez kolejne etapy:
Dlaczego plik log nie maleje po SHRINK i co z tym zrobić
Masz wrażenie, że SHRINKFILE na pliku log nic nie daje? Tu jest kompletna mapa pułapek: VLF, otwarte transakcje, brak backupów logu i nieuśpione replikacje.
PIOSEE: framework incydentów dla DBA + szablon do kopiuj‑wklej
Praktyczny szablon rozwiązywania incydentów (Problem–Information–Options–Select–Execute–Evaluate) z przykładami dla SQL Server.
SQL Agent: runbook do alertów i historii — wydłuż, czyść, monitoruj
Krótkie i skuteczne: jak wydłużyć historię zadań, sprzątać ją automatycznie, oraz zakładać alerty i operatorów bez klikania.
tempdb: kiedy i jak naprawdę ją shrinkować (bez mitów)
Jak diagnozować rozrost tempdb i bezpiecznie ją przyciąć – krok po kroku, z gotowymi skryptami i checklistą weryfikacji.