Posts
2025-10-24 · 3 min
Kiedy baza ma miliardy stron danych, pełny restore bywa jak przeszczep serca.
Ale czasem wystarczy precyzyjna operacja – przywrócenie tylko uszkodzonej strony.
PAGE restore to chirurgiczna procedura SQL Servera: przywraca fragment, nie zatrzymując całego organizmu.
🧩 Idea
Każdy obiekt w SQL Server składa się z 8-KB stron.
Gdy jedna z nich zostanie uszkodzona (błąd I/O, dysk, checksum), silnik oznacza ją jako suspect i pozwala na przywrócenie tylko tej strony z backupu — bez pełnego przywracania całej bazy czy pliku danych.
2025-10-23 · 2 min
SQL Server przypomina organizm, który potrafi sam utrzymać czystość.
Gdy rekord zostaje usunięty, jego duch nie znika od razu — pozostaje w strukturze danych, jak ślad po zmarłej komórce.
Dopiero Ghost Cleanup Task przychodzi, by po cichu posprzątać, przywracając równowagę systemu.
To układ odpornościowy SQL Servera – działa w tle, gdy nikt nie patrzy, i dba o to, by baza nie zarosła martwymi danymi.
🔍 Zajrzyj w DMV
1
2
3
4
5
6
7
| -- znajdź indeksy zawierające ghost records
SELECT
object_name(object_id) AS TableName,
index_id,
ghost_record_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED')
WHERE ghost_record_count > 0;
|
„Porządek nie polega na braku chaosu, lecz na jego kontrolowaniu.” — Kant
2025-10-22 · 3 min
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.
2025-10-21 · 2 min
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ść.
2025-10-20 · 5 min
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ść.
2025-10-19 · 2 min
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ę.
2025-10-18 · 3 min
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.
2025-10-17 · 3 min
Każdy wykres to historia.
CPU, I/O, pamięć, zapytania – wszystkie mówią, co naprawdę dzieje się na serwerze.
Dobry DBA nie reaguje na alarm, tylko rozumie, dlaczego on się pojawił.
Mój ulubiony zestaw: Telegraf + InfluxDB + Grafana.
Z tego powstaje cockpit — SQLManiak Monitoring.
Nie dashboard „bo ładny”, tylko mapa świadomości systemu, w której każda metryka ma znaczenie.
„Wiedza zaczyna się tam, gdzie kończą się zgadywania.”
Od reakcji do obserwacji
Większość problemów z wydajnością nie pojawia się nagle.
One dojrzewają. Rosną cicho, pomiędzy kolejnymi BACKUP, CHECKDB, i zbyt długim SELECT *.
Bez monitoringu widzimy tylko skutek – czerwony alert, rosnące czasy odpowiedzi, spadek PLE.
2025-10-16 · 3 min
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.”
2025-10-15 · 2 min
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.
