Jun 18, 2026, 9:47 AM

2026-06-18 07:47:40 +00:00
parent 444b86a7c0
commit 71ddc1e1fb
1 changed files with 787 additions and 0 deletions
@@ -94,3 +94,790 @@ Spotkanie kontrolne (follow-up) prawdopodobnie zostanie zaplanowane na przyszły
 - Wymagane testy i ostateczna decyzja między architekturami (push vs pull).
 - Zmiana wymaga przejścia formalnego procesu i zakomunikowania interesariuszom.
 - Otwarte ryzyko: weryfikacja czy wdrożenie wymusi restart lub downtime.
+
+
+Okej — zrobię Ci **pełny, spójny raport DBA** z całej analizy: skryptu + warningów + planu wykonania + realnych rekomendacji.
+
+To będzie coś, co możesz praktycznie potraktować jako:
+✅ dokument techniczny  
+✅ materiał do review / knowledge sharing  
+✅ podstawę do decyzji produkcyjnej
+
+***
+
+# 📘 RAPORT: Optymalizacja migracji kolumny (SQL Server)
+
+## 🔍 1. Cel skryptu
+
+Skrypt służy do:
+
+👉 masowej zmiany typu kolumn (np. `VARCHAR(9)`)  
+👉 w wielu tabelach  
+👉 z podziałem na strategię:
+
+| przypadek          | metoda                   |
+| ------------------ | ------------------------ |
+| małe tabele (≤20M) | `ALTER COLUMN`           |
+| duże tabele (>20M) | migracja “shadow column” |
+
+***
+
+## 🧱 2. Mechanizm dla dużych tabel
+
+Dla dużych tabel stosowany jest wzorzec:
+
+1. `ADD new_column`
+2. kopiowanie danych batchami:
+   ```sql
+   UPDATE TOP (99000)
+   ```
+3. (później) drop + rename
+
+👉 to jest **poprawny enterprise pattern**
+
+***
+
+# 📊 3. Diagnoza planu wykonania
+
+Na podstawie XML i operatorów:
+
+## ✅ Fakty
+
+* tabela: `REPORT_XML_STACK`
+* liczba wierszy: **\~52 841 100**
+* typ: **HEAP (brak clustered index)**
+* batch: `TOP (99000)`
+* używane:
+  * `Table Scan`
+  * `Parallelism`
+  * `Sort`
+  * `Table Update`
+  * `Index Update`
+
+***
+
+## ❗ KLUCZOWY PROBLEM
+
+### ❌ 1. FULL / LARGE TABLE SCAN
+
+```xml
+PhysicalOp="Table Scan"
+```
+
+➡️ SQL Server czyta **dużą część 52M wierszy** dla każdego batcha
+
+👉 to jest główne wąskie gardło
+
+***
+
+## ❗ 2. Słaby indeks filtrowany
+
+Masz:
+
+```sql
+ON (DUNS_NBR_NEW1)
+WHERE DUNS_NBR_NEW1 IS NULL
+```
+
+### Problem:
+
+* wszystkie wartości = `NULL`
+* brak selektywności
+* brak sensownego porządku
+
+👉 indeks istnieje, ale **nie prowadzi planu**
+
+***
+
+## ❗ 3. Batch `TOP (99000)` bez ORDER
+
+```sql
+UPDATE TOP (99000)
+```
+
+➡️ brak deterministycznego wyboru wierszy
+
+👉 skutki:
+
+* sort
+* niespójne batchowanie
+* trudniejsza optymalizacja
+
+***
+
+## ⚠️ 4. Warning: CONVERT()
+
+```
+Type conversion may affect cardinality estimate
+```
+
+### Wniosek:
+
+👉 **prawdziwy, ale drugorzędny**
+
+bo:
+
+* CAST jest tylko w SET
+* nie w predicate
+
+👉 NIE jest główny problem
+
+***
+
+## ⚙️ 4. Dodatkowe obserwacje
+
+### Parallelism
+
+* `Gather Streams`
+* wiele wątków
+* dodatkowy overhead
+
+***
+
+### Sort przed update
+
+* koszt \~13 CPU w planie
+* wynika z braku uporządkowania danych
+
+***
+
+### Heap
+
+* brak uporządkowania fizycznego
+* więcej IO
+* trudniejsze update’y
+
+***
+
+# 🎯 4. ROOT CAUSE
+
+Największy problem to:
+
+> ❗ SQL Server nie ma dobrej ścieżki dostępu do „następnych 99000 rekordów do update”
+
+czyli:
+
+* słaby indeks
+* brak ORDER
+* heap
+* TOP
+
+***
+
+# 🚀 5. STRATEGIA OPTYMALIZACJI
+
+## 🥇 PRIORYTET 1 — popraw indeks
+
+Zamiast:
+
+```sql
+ON (DUNS_NBR_NEW1)
+```
+
+zrób indeks **na kluczu tabeli**:
+
+```sql
+CREATE NONCLUSTERED INDEX IX_REPORT_XML_STACK_MIGRATION
+ON dbo.REPORT_XML_STACK (ID)                -- <- KLUCZ!
+INCLUDE (DUNS_NBR)
+WHERE DUNS_NBR_NEW1 IS NULL
+  AND DUNS_NBR IS NOT NULL;
+```
+
+### Efekt:
+
+✅ fast seek  
+✅ brak full scan  
+✅ mniej IO  
+✅ brak sort
+
+***
+
+## 🥇 PRIORYTET 2 — zmień UPDATE
+
+Zamiast:
+
+```sql
+UPDATE TOP (99000)
+```
+
+użyj:
+
+### ✅ wersja CTE
+
+```sql
+;WITH batch AS
+(
+    SELECT TOP (20000)
+           ID,
+           DUNS_NBR
+    FROM dbo.REPORT_XML_STACK
+    WHERE DUNS_NBR_NEW1 IS NULL
+      AND DUNS_NBR IS NOT NULL
+    ORDER BY ID
+)
+UPDATE T
+SET T.DUNS_NBR_NEW1 = CAST(B.DUNS_NBR AS VARCHAR(9))
+FROM dbo.REPORT_XML_STACK T
+JOIN batch B ON B.ID = T.ID
+OPTION (RECOMPILE);
+```
+
+***
+
+## 🥇 PRIORYTET 3 — zmniejsz batch
+
+Z:
+
+```sql
+TOP (99000)
+```
+
+👉 testuj:
+
+* 10k
+* 20k
+* 50k
+
+### Korzyści:
+
+✅ mniejszy log  
+✅ mniej blokad  
+✅ bardziej stabilny runtime
+
+***
+
+## 🥇 PRIORYTET 4 — dodaj RECOMPILE
+
+```sql
+OPTION (RECOMPILE)
+```
+
+👉 bo dataset się zmienia (NULL → NOT NULL)
+
+***
+
+## 🥈 PRIORYTET 5 — kontrola parallelism
+
+Test:
+
+```sql
+OPTION (RECOMPILE, MAXDOP 1)
+```
+
+👉 często:
+
+* mniej overhead
+* bardziej przewidywalne batchy
+
+***
+
+## 🥈 PRIORYTET 6 — lock strategy
+
+### obecnie:
+
+```sql
+TABLOCK
+```
+
+### alternatywa (bardziej OLTP-friendly):
+
+```sql
+WITH (UPDLOCK, READPAST)
+```
+
+***
+
+## 🥈 PRIORYTET 7 — statystyki
+
+```sql
+UPDATE STATISTICS dbo.REPORT_XML_STACK IX_REPORT_XML_STACK_MIGRATION;
+```
+
+👉 ważne dla planu
+
+***
+
+# 🧠 6. FINALNY WZORZEC (PROD READY)
+
+```sql
+SET NOCOUNT ON;
+SET XACT_ABORT ON;
+
+DECLARE @Rows int = 1;
+
+WHILE @Rows > 0
+BEGIN
+    ;WITH batch AS
+    (
+        SELECT TOP (20000)
+               T.ID,
+               T.DUNS_NBR
+        FROM dbo.REPORT_XML_STACK AS T
+             WITH (INDEX(IX_REPORT_XML_STACK_MIGRATION), UPDLOCK, READPAST)
+        WHERE T.DUNS_NBR_NEW1 IS NULL
+          AND T.DUNS_NBR IS NOT NULL
+        ORDER BY T.ID
+    )
+    UPDATE T
+       SET T.DUNS_NBR_NEW1 = CAST(B.DUNS_NBR AS VARCHAR(9))
+    FROM dbo.REPORT_XML_STACK AS T
+    JOIN batch AS B
+      ON B.ID = T.ID
+    OPTION (RECOMPILE, MAXDOP 1);
+
+    SET @Rows = @@ROWCOUNT;
+
+    PRINT CONCAT('Updated rows: ', @Rows);
+END
+```
+
+***
+
+# 📉 7. Oczekiwany efekt po optymalizacji
+
+| obszar      | efekt                 |
+| ----------- | --------------------- |
+| IO          | ↓ znacząco            |
+| CPU         | ↓ (mniej sort/scan)   |
+| log         | ↓                     |
+| czas batcha | ↓                     |
+| stabilność  | ↑                     |
+| blokady     | ↓ (jeśli bez TABLOCK) |
+
+***
+
+# ✅ 8. TL;DR
+
+👉 największy problem:
+
+> ❌ batch TOP + heap + słaby indeks → table scan
+
+👉 najważniejsze fixy:
+
+1. ✅ indeks na kluczu (ID) + INCLUDE
+2. ✅ batchowanie po ORDER BY ID
+3. ✅ mniejszy TOP
+4. ✅ RECOMPILE
+
+👉 warning o CAST:
+
+> ℹ️ istnieje, ale nie jest głównym problemem
+
+Super — to jest bardzo dobry drugi kawałek Twojego frameworka 🔥  
+I teraz możemy zrobić **pełną analizę architektury (Step 8)**, bo to jest kluczowy moment: *odtwarzanie constraints, indeksów i obiektów* po migracji.
+
+***
+
+# 📘 TL;DR (co robi Step 8)
+
+👉 Ten fragment:
+
+* zbiera **skrypty odtwarzające** (constraints, indexy, statystyki, view-indexy)
+* wrzuca je do kolejki (`Step8Queue`)
+* sortuje wg kolejności zależności
+* wykonuje je **sekwencyjnie przez cursor**
+
+👉 to jest poprawny pattern typu **rebuild pipeline**
+
+***
+
+# 🧠 Co działa BARDZO dobrze
+
+## ✅ 1. Kolejka wykonania (Step8Queue)
+
+To jest bardzo dobry design:
+
+```sql
+CREATE TABLE Step8Queue (...)
+```
+
+👉 masz:
+
+* centralny queue
+* kontrolę kolejności
+* możliwość debugowania
+* możliwość DRY RUN
+
+💡 to jest **bardziej kontrolowalne niż dynamiczne wykonania ad-hoc**
+
+***
+
+## ✅ 2. Priorytety (ExecutionOrder)
+
+```sql
+CASE ObjectType
+    WHEN 'PK/UNIQUE' THEN 1
+    WHEN 'DEFAULT'   THEN 3
+    WHEN 'FOREIGN_KEY' THEN 5
+    WHEN 'INDEX' THEN 7
+```
+
+👉 bardzo ważne — bo:
+
+| obiekt | zależność         |
+| ------ | ----------------- |
+| PK     | musi być pierwszy |
+| FK     | potrzebują PK     |
+| INDEX  | na końcu          |
+
+✅ to jest poprawna kolejność odbudowy
+
+***
+
+## ✅ 3. DryRun mode
+
+```sql
+IF @DryRun = 1
+```
+
+👉 super ważne przy takich operacjach
+
+***
+
+## ✅ 4. TRY/CATCH + logowanie
+
+```sql
+BEGIN TRY
+EXEC ...
+END TRY
+BEGIN CATCH
+EXEC dbo.usp_LogError
+```
+
+👉 dobrze, bo:
+
+* nie wywala całego procesu
+* masz audit
+
+***
+
+# ⚠️ Problemy i miejsca do poprawy (ważne)
+
+Teraz sedno — co bym poprawił jako DBA produkcyjny:
+
+***
+
+# ❌ 1. Cursor = wąskie gardło (ale… tu jest OK)
+
+Masz:
+
+```sql
+CURSOR FAST_FORWARD
+```
+
+👉 normalnie powiedziałbym: "cursor zły"
+
+ALE w tym przypadku:
+
+* tworzysz obiekty (DDL)
+* kolejność jest ważna
+* trzeba sekwencyjnie
+
+👉 ✅ cursor jest tu **UZASADNIONY**
+
+***
+
+# ❌ 2. Brak jawnej transakcji per obiekt
+
+Masz:
+
+```sql
+SET XACT_ABORT ON;
+```
+
+ALE nie masz:
+
+```sql
+BEGIN TRAN
+COMMIT
+```
+
+### Problem
+
+Jeśli obiekt:
+
+* padnie w połowie (np. index CREATE)
+* i nie rollbacknie się poprawnie
+
+👉 możesz mieć niespójny stan
+
+***
+
+## ✅ Fix
+
+Dodać per-obiekt:
+
+```sql
+BEGIN TRY
+    BEGIN TRAN
+
+    EXEC sp_executesql @stmt1
+
+    COMMIT
+END TRY
+BEGIN CATCH
+    IF XACT_STATE() <> 0 ROLLBACK
+```
+
+***
+
+# ❌ 3. PRINT zamiast realnego logowania
+
+Masz:
+
+```sql
+PRINT @OBJT1 + '---' + @stmt1
+```
+
+👉 PRINT:
+
+* znika przy dłuższych operacjach
+* tnie się
+* nie jest audytowalny
+
+***
+
+## ✅ Fix
+
+Zostaw PRINT, ale dodaj:
+
+```sql
+INSERT INTO MyprintLog (...)
+VALUES (...)
+```
+
+PRZED wykonaniem, nie tylko po
+
+***
+
+# ❌ 4. Brak retry logic
+
+DDL potrafi failować przez:
+
+* blocking
+* deadlock
+* metadane
+
+👉 obecnie:
+
+* jeden fail = log + jedziemy dalej
+
+***
+
+## ✅ Fix (mini retry)
+
+```sql
+DECLARE @retry INT = 0;
+
+WHILE @retry < 3
+BEGIN
+    BEGIN TRY
+        EXEC sp_executesql @stmt1
+        BREAK
+    END TRY
+    BEGIN CATCH
+        SET @retry = @retry + 1
+        WAITFOR DELAY '00:00:02'
+    END CATCH
+END
+```
+
+***
+
+# ❌ 5. Literówka w ObjectType
+
+Masz:
+
+```sql
+'Foregin_sweep_Key'
+```
+
+👉 może powodować:
+
+* brak dopasowania
+* złe sortowanie
+
+***
+
+# ❌ 6. ORDER BY w INSERT (niezdeterminowane)
+
+```sql
+INSERT INTO Step8Queue
+SELECT ...
+ORDER BY ...
+```
+
+👉 SQL Server ignoruje `ORDER BY` w INSERT bez TOP
+
+***
+
+## ✅ Fix
+
+Sortuj tylko przy SELECT w cursorze (już robisz ✅)
+
+***
+
+# ❌ 7. Brak walidacji duplikatów
+
+Nie masz:
+
+```sql
+PRIMARY KEY na Step8Queue
+```
+
+👉 możesz mieć:
+
+* duplikaty create scriptów
+* ponowne wykonanie DDL
+
+***
+
+## ✅ Fix
+
+Dodaj:
+
+```sql
+ALTER TABLE Step8Queue
+ADD CONSTRAINT PK_Step8Queue UNIQUE(ObjectType, ObjectName, ParentTable);
+```
+
+***
+
+# ❌ 8. Brak kontroli zależności między tabelami
+
+Sortowanie:
+
+```sql
+ORDER BY ExecutionOrder, ObjectType
+```
+
+ALE:
+
+👉 dwa FK między tabelami mogą się „gryźć”
+
+***
+
+## ✅ advanced fix (opcjonalne)
+
+Topologiczne sortowanie zależności FK  
+(albo retry loop — prostsze)
+
+***
+
+# ❌ 9. Możliwy błąd: VARCHAR(MAX) dla CreateScript
+
+Może powodować:
+
+* duże użycie tempdb / memory
+
+👉 OK przy małej liczbie obiektów  
+👉 przy tysiącach → problem
+
+***
+
+# 🔥 Najważniejszy problem architektoniczny
+
+## Step 8 zakłada, że wszystko się odtworzy „bez oporu”
+
+w praktyce:
+
+* FK mogą failować
+* PK mogą failować
+* index może failować
+
+👉 i Twój flow:
+
+```
+FAIL → log → NEXT
+```
+
+czyli:
+
+❗ możesz skończyć ze środowiskiem:
+
+* bez FK
+* bez indeksów
+* częściowo odtworzonym
+
+***
+
+# ✅ Lepszy pattern (produkcyjny)
+
+## podejście 2-fazowe
+
+### FAZA 1 – CREATE (niekrytyczne błędy OK)
+
+* PK, INDEX, DEFAULT, CHECK
+
+### FAZA 2 – FK (retry loop)
+
+```sql
+WHILE EXISTS (FK do odtworzenia)
+BEGIN
+   spróbuj odtworzyć
+   jeśli fail → zostaw
+END
+```
+
+👉 aż nic się nie da już zrobić
+
+***
+
+# 📊 FINALNA OCENA
+
+| obszar             | ocena |
+| ------------------ | ----- |
+| architektura       | ⭐⭐⭐⭐⭐ |
+| bezpieczeństwo     | ⭐⭐⭐⭐  |
+| odporność na błędy | ⭐⭐⭐   |
+| wydajność          | ⭐⭐⭐⭐  |
+| produkcyjność      | ⭐⭐⭐⭐  |
+
+***
+
+# 🚀 Co bym zrobił jako DBA (konkrety)
+
+## ✅ MUST HAVE
+
+1. transakcja per obiekt
+2. logging pre + post
+3. poprawa indeksów migracji (z poprzedniego wątku)
+
+***
+
+## ✅ SHOULD HAVE
+
+4. retry logic
+5. eliminacja literówek
+6. unique constraint na queue
+
+***
+
+## ✅ NICE TO HAVE
+
+7. FK retry loop
+8. dependency-aware ordering
+
+***
+
+# 🧠 Finalny wniosek
+
+👉 Step 8 jest:
+
+✅ dobrze zaprojektowany  
+✅ zgodny z enterprise patternem  
+❗ ale wymaga hardeningu pod produkcję
+
+***
+
+# 👍 Jeśli chcesz
+
+Mogę Ci:
+
+✅ przepisać cały Step 8 w wersji **production-grade (hardcore DBA)**  
+✅ dodać retry engine + dependency resolver  
+✅ zrobić wersję z checkpointami (resume after fail)  
+✅ dodać metryki: ile % zrobione
+
+Powiedz tylko — zrobimy z tego narzędzie, którego będziesz używać latami 👍