Přejmenování sloupce trvá třicet sekund. Migrační skript zapisuje do minuty. Nasazení do pracovního prostředí proběhlo bez chyby. Nasazení do produkčního prostředí proběhlo bez chyby. O tři hodiny později se spustí monitorovací upozornění, protože služba Java vrací chybné odpovědi, dávková úloha COBOL se zastavila s chybou SQL a kanál pro generování sestav přestal načítat záznamy. Sloupec byl přejmenován. Aplikacím to nikdo neřekl.
Toto není hypotetický případ. Moderní informační systémy se skládají z databází obklopených širokou škálou softwarových aplikací v závislosti na těchto databázích. V prostředích integrace podnikových aplikací jsou databáze sdíleny aplikacemi, které přispívají různé nezávislé strany, a vývojáři těchto aplikací mají často malou nebo žádnou kontrolu nad tím, kdy a jak se schéma databáze v průběhu času vyvíjí. Databáze a softwarové aplikace nemusí být vždy synchronizované a tato nekonzistence vede ke ztrátě dat, selhání programů a sníženému výkonu. Řešením není pomalejší proces vydávání. Jde o kompletní analýzu dopadu před spuštěním migračního skriptu.
Před změnou schématu znát každou závislou osobu
SMART TS XL mapuje všechny závislosti aplikací, kanálů a mezi jazyky před spuštěním migračního skriptu.
ZJISTĚTE VÍCE…Ne všechny změny schématu jsou stejné
Prvním úkolem v jakékoli analýze dopadu schématu je klasifikace navrhované změny. Změna, která přidá do tabulky volitelný sloupec, se zásadně liší od změny, která přejmenuje existující sloupec, i když obě zahrnují stejnou syntaxi ALTER TABLE. Jedna je zpětně kompatibilní; druhá je nefunkční pro každého příjemce, který odkazuje na původní název sloupce.
Zásadní změny způsobují selhání u stávajících příjemců bez jakékoli akce ze strany příjemce. Vyžadují koordinované nasazení, každý závislý proces musí být aktualizován před změnou schématu nebo současně se změnou, nebo musí být příjemce aktualizován jako první a nasazen za vrstvou kompatibility, dokud schéma nedožene změnu.
Nezávažné změny jsou zpětně kompatibilní. Stávající uživatelé nadále fungují beze změny. Noví uživatelé mohou využívat nový prvek schématu vlastním tempem.
Klasifikace určuje rozsah analýzy, požadovanou koordinaci nasazení a složitost vrácení zpět:
| Změnit typ | Vypínací | Primární cíl dopadu | Úroveň rizika |
|---|---|---|---|
| Přidat sloupec s povolenou hodnotou Null | Ne | Pouze nový kód | Nízké |
| Přidat sloupec NOT NULL bez výchozího nastavení | Ano | Všechny příkazy INSERT | kritický |
| Přejmenovat sloupec | Ano | Každý SELECT, INSERT, UPDATE, který na něj odkazuje | kritický |
| Vypustit sloupec | Ano | Každý odkaz kdekoli | kritický |
| Rozšíření datového typu (INT na BIGINT) | Částečný | Aplikace, které kontrolují délku nebo typ pole | Střední |
| Úzký datový typ (VARCHAR 500 až 100) | Ano | Aplikace ukládají hodnoty déle, než je nový limit | Vysoký |
| Přidat index | Ne | Pouze výkon, dotazy zůstávají platné | Nízké |
| Index přetažení | Částečný | Výkon dotazu; správnost není ovlivněna | Střední |
| Přejmenovat tabulku | Ano | Každý odkaz kdekoli | kritický |
| Přidat omezení cizího klíče | Částečný | Existující data musí splňovat omezení | Středně vysoká |
| Změnit hodnotu Nullable na NOT NULL | Ano | Aplikace vkládají do daného sloupce hodnotu NULL | Vysoký |
| Upravit podpis uložené procedury | Ano | Všichni volající procedury | kritický |
| Zrušit uloženou proceduru | Ano | Všichni volající procedury | kritický |
| Přejmenovat zobrazení | Ano | Všichni uživatelé zobrazení | kritický |
| Změnit definici zobrazení | Částečný | Spotřebitelé dotčených sloupců | Středně vysoká |
Pravidlo nasazení: Každá kritická změna vyžaduje před nasazením kompletní inventuru závislých prvků. Každá vysoce riziková změna vyžaduje postupné zavádění s ověřováním v každé fázi. Každá středně riziková změna vyžaduje minimálně kontrolu primárních cílů dopadu. Nízkorizikové změny lze nasadit se standardním testováním, ale měly by být i tak zaznamenávány.
Čtyři vrstvy závislostí: Kde se odehrává dopad schématu
Nejzávažnější chybou v analýze dopadu změny schématu je její zacházení jako s problémem relevantním pouze pro databázi. Dopad přejmenování sloupce sahá daleko za samotnou databázi a přesahuje čtyři odlišné vrstvy závislostí, z nichž každá vyžaduje k výčtu odlišné analytické techniky.
Vrstva 1: Vnitřní závislosti databáze
Nejviditelnější vrstva. V rámci samotné databáze může změna schématu ovlivnit:
Pohledy , které provádějí výběr (SELECT) ze změněné tabulky. Pohled, který obsahuje přejmenovaný sloupec ve svém seznamu SELECT, vrátí po přejmenování chybu nebo nesprávné výsledky v závislosti na tom, zda je pohled materializován.
Uložené procedury a funkce , které odkazují na sloupec ve svých příkazech SELECT, INSERT, UPDATE nebo DELETE.
Triggery , které se spustí při INSERT nebo UPDATE změněné tabulky a ve své logice odkazují na konkrétní názvy sloupců.
Zkontrolujte omezení a vypočítané sloupce , které odkazují na sloupec podle názvu.
Vztahy cizích klíčů , které by odstranění sloupce zneplatnilo.
Tyto závislosti lze dotazovat přímo z katalogu databáze. SQL Server poskytuje sys.sql_dependencies a sys.dm_sql_referenced_entitiesPostgreSQL poskytuje pg_dependSpolečnost Oracle poskytuje ALL_DEPENDENCIESNásledující dotazy vypisují interní závislé prvky databáze pro konkrétní tabulku a sloupec:
sql
-- SQL Server: all objects referencing a specific column
SELECT
OBJECT_NAME(d.object_id) AS dependent_object,
o.type_desc AS object_type,
OBJECT_NAME(d.referenced_major_id) AS referenced_table,
COL_NAME(d.referenced_major_id,
d.referenced_minor_id) AS referenced_column
FROM sys.sql_dependencies d
JOIN sys.objects o ON o.object_id = d.object_id
WHERE d.referenced_major_id = OBJECT_ID('dbo.Customers')
AND d.referenced_minor_id = COLUMNPROPERTY(
OBJECT_ID('dbo.Customers'), 'CustomerName', 'ColumnId')
ORDER BY o.type_desc, dependent_object;sql
-- PostgreSQL: views and functions depending on a specific column
SELECT
dep.classid::regclass AS dependency_type,
dependent.relname AS dependent_object,
a.attname AS referenced_column,
source.relname AS source_table
FROM pg_depend dep
JOIN pg_class source ON source.oid = dep.refobjid
JOIN pg_class dependent ON dependent.oid = dep.objid
JOIN pg_attribute a ON a.attrelid = dep.refobjid
AND a.attnum = dep.refobjsubid
WHERE source.relname = 'customers'
AND a.attname = 'customer_name';sql
-- Oracle: full dependency chain for objects referencing a table
SELECT
name AS dependent_object,
type AS object_type,
referenced_name,
referenced_type
FROM user_dependencies
WHERE referenced_name = 'CUSTOMERS'
ORDER BY type, name;Tyto dotazy kompletně pokrývají vrstvu 1. Nedotýkají se vrstev 2 až 4.
Vrstva 2: Závislosti aplikačního kódu
Druhá vrstva je místem, kde vzniká většina produkčních incidentů a kde dotazy do databázového katalogu neposkytují vůbec žádný přehled. Aplikační kód, který interaguje s databází, tak činí prostřednictvím:
Dotazy JDBC a ODBC v aplikacích Java a .NET, kde se názvy sloupců zobrazují jako řetězcové literály v dotazech SQL vložených do zdrojového kódu.
Mapování ORM v Hibernate, Entity Framework, SQLAlchemy a ActiveRecord, kde jsou názvy tabulek a sloupců mapovány na pole objektů. Přejmenování sloupce vyžaduje jak změnu schématu, tak změnu konfigurace ORM, a pokud je změna konfigurace vynechána, ORM tiše namapuje nový název sloupce na staré pole, což vede k hodnotám null nebo chybám mapování.
Vložený SQL v programech v COBOLu , kde se SQL objevuje v blocích EXEC SQL / END-EXEC v kódu COBOL PROCEDURE DIVISION. Toto je nejdůležitější a nejčastěji přehlížený typ závislosti v podnikových prostředích. Příkaz:
cobol
EXEC SQL
SELECT CUST-NAME, CUST-ADDR, CUST-PHONE
INTO :WS-CUST-NAME, :WS-CUST-ADDR, :WS-CUST-PHONE
FROM CUSTOMERS
WHERE CUST-ID = :WS-CUST-ID
END-EXECnení SQL, ale zdrojový kód COBOL obsahující vložený příkaz SQL. Standardní nástroj pro závislostí SQL nebo dotaz do katalogu databáze tento odkaz nenajde, protože existuje ve zdrojovém souboru COBOL, nikoli v definici objektu SQL. Jeho nalezení vyžaduje analýzu zdrojového kódu COBOL.
Dynamický SQL sestavený z šablon řetězců, kde se názvy sloupců sestavují za běhu. Tyto nelze nalézt statickou analýzou literálů SQL, vyžadují buď dynamickou analýzu (spuštění aplikace za testovacích podmínek), nebo pečlivou ruční kontrolu vzorů konstrukce řetězců.
Resolvery GraphQL a serializátory API které mapují názvy sloupců databáze na názvy polí odpovědi. API, které zpřístupňuje customerName ze sloupce s názvem customer_name Přes přímé mapování sloupců se sloupec přeruší při přejmenování sloupce, a to i v případě aktualizace SQL dotazu aplikace, protože mapování serializátoru také odkazuje na původní název.
Vrstva 3: Závislosti ETL, Pipeline a datové platformy
Třetí vrstva zahrnuje každý proces přesunu dat, který se dotýká změněné tabulky nebo sloupce:
Úlohy ETL (ať už napsané ve vlastním kódu, spravované pomocí Informatica, Talend nebo SSIS, nebo vyjádřené jako Airflow DAG), které vybírají (SELECT) ze změněné tabulky pro transformaci a načítání do následných systémů.
Konfigurace Change Data Capture (CDC) (Debezium, Oracle GoldenGate, SQL Server CDC), které streamují změny na úrovni řádků ze zdrojové databáze. Konfigurace CDC odkazují na konkrétní názvy tabulek a sloupců, přejmenování sloupce vytvoří událost změny s novým názvem sloupce, kterou příjemci CDC v následných procesech nemusí rozpoznat.
Procesy načítání datových skladů a datových jezer , které zplošťují relační struktury do sloupcových formátů. Přejmenování sloupce u zdroje vyžaduje odpovídající přejmenování ve schématu datového skladu, skriptu pro načítání a v každém analytickém dotazu nebo řídicím panelu, který na daný sloupec odkazuje.
Dotazy na tvorbu sestav vložené do nástrojů BI (sešity Tableau, datové sady Power BI, definice Looker LookML), které přímo odkazují na názvy sloupců. Tyto dotazy často nejsou dokumentovány a objeví se pouze tehdy, když sestava přestane fungovat po změně schématu.
Vrstva 4: Následné a partnerské závislosti
Nejvzdálenější vrstva: systémy mimo přímou kontrolu organizace, které spotřebovávají data odvozená ze změněné databáze.
Externí uživatelé API které přijímají odpovědi obsahující názvy polí mapované z názvů sloupců. Pokud veřejné API obsahuje customer_name v jeho odpovědi a toto pole je generováno přímým mapováním sloupců, přejmenování přeruší kontrakt API pro každého externího příjemce.
Partnerské datové kanály , které přijímají výpisy ze změněné tabulky ve formátu plochého souboru, CSV nebo XML, kde pozice nebo názvy polí jsou definovány schématem extraktu.
Systémy pro dodržování předpisů a regulační reporting , kde jsou specifické definice sloupců odkazovány ve specifikacích regulačních reportů, které mohly být dohodnuty s externím orgánem.
Hledání závislostí v kódu aplikace: Techniky analýzy
Vrstva 1 je samoobslužná prostřednictvím katalogových dotazů. Vrstvy 2 až 4 vyžadují různé techniky v závislosti na jazyku a architektuře:
Vyhledávání řetězců (rychlé, neúplné): Grep nebo ripgrep napříč kódovou základnou pro název tabulky, název sloupce nebo obojí. Rychlé a snadno automatizovatelné. Mine dynamicky konstruovaný SQL a generuje falešně pozitivní výsledky v komentářích a dokumentaci.
praštit
# Find all files referencing a specific column
rg "customer_name|CUST-NAME|customerName" \
--type java --type py --type cs --type cbl \
--glob "!**/test/**" \
-l # list files only, for scope assessment
# More precise: find SQL contexts specifically
rg "(?i)(SELECT|INSERT|UPDATE|WHERE).*customer_name" \
--type java --type pyAnalýza založená na AST (přesnější, jazykově specifická): Analyzuje zdrojový kód do abstraktního syntaktického stromu a prochází jím, aby našel literály řetězců SQL, anotace ORM a konfigurace mapování. Přesnější než vyhledávání řetězců, ale vyžaduje samostatný analyzátor pro každý jazyk.
Sémantická analýza toku dat (nejpřesnější, nejdražší): Statická analýza programu využívající analýzu toku dat k extrakci všech možných interakcí s databází, které může aplikace provést. Tato technika, formalizovaná ve výzkumu IEEE o analýze dopadu změn schématu, sleduje data od konstrukce databázového dotazu přes přiřazení proměnných až po bod provedení a identifikuje odkazy na sloupce SQL, i když jsou sestaveny z částí, a nikoli zapsány jako kompletní literály. Výzkum ukazuje, že tato analýza musí být kontextově citlivá, aby se dosáhlo vysoké přesnosti, a že rozdělení programu výrazně zkracuje dobu analýzy při zachování úplnosti.
Praktické doporučení: Pro rychlé posouzení rozsahu používejte vyhledávání řetězců. Před kritickými změnami používejte AST nebo sémantickou analýzu pro autoritativní výčet. Nikdy neimplementujte přejmenování nebo odstranění sloupců pouze na základě vyhledávání řetězců, riziko falešně negativních výsledků je příliš vysoké.
Dopad schématu ve vícejazyčných podnikových prostředích
Ve standardní moderní webové aplikaci, backendu Java, frontendu Reactu nebo databázi PostgreSQL je rozsah závislostí změny schématu omezen zdrojovým kódem aplikace. Přejmenování sloupce ovlivňuje řetězce SQL ve vrstvě Java a mapování polí API v serializátoru. Obojí lze nalézt prohledáváním stejné kódové základny.
Podniková prostředí se staršími mainframe systémy se liší ve všech ohledech. Na sloupec DB2 v jádrovém bankovním systému finanční instituce se může odkazovat:
- Programy v COBOLu s vestavěným SQL, které zpracovávají denní transakce na účtech
- Kroky úlohy JCL, které generují extrahované soubory, jejichž rozvržení se mapuje na sloupec
- Mikroslužby Java, které volají uložené procedury odkazující na sloupec
- Datové kanály Pythonu, které dotazují DB2 přímo přes JDBC pro reporting
- SQL zobrazení používaná nástroji BI pro manažerské dashboardy
- Transakční programy CICS, které zobrazují hodnotu sloupce na obrazovkách terminálů
Tyto reference existují v pěti různých jazycích, ve třech různých běhových prostředích (mainframe, cloud, platforma BI) a spravují je týmy, které spolu možná nikdy přímo nekomunikují. Přejmenování sloupce, na kterém se dohodne databázový tým a tým Java Service, může být pro tým COBOL, tým pro tvorbu reportů a tým BI neznámé, dokud jejich systémy selžou.
Techniky statické analýzy programů identifikují dopad změn schématu relační databáze na objektově orientované aplikace pomocí analýzy toku dat k extrakci všech možných interakcí s databází. Stejný princip byl rozšířen na COBOL, JCL, Python a SQL současně, přičemž analýza vloženého SQL kódu ve zdrojovém kódu COBOL, bloků EXEC SQL v programech JCL, parametrizovaných dotazů ve skriptech Pythonu a objektů SQL v databázi vytváří kompletní mapu závislostí mezi jazyky, která umožňuje analýzu dopadu změn schématu ve více jazycích zvládnout.
Integrace CI/CD: Automatizace analýzy dopadů
Manuální analýza dopadu před každou změnou schématu je lepší než žádná analýza. Automatizovaná analýza dopadu jako CI/CD brána je lepší než manuální analýza, spouští se pokaždé, bez závislosti na disciplíně vývojářů, a blokuje nasazení, když je analýza neúplná.
yaml
# GitHub Actions: schema impact gate
name: Schema Change Impact Analysis
on:
pull_request:
paths:
- 'migrations/**'
- 'schema/**'
- '**/*.sql'
jobs:
schema-impact:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Detect schema changes
id: detect
run: |
git diff origin/main...HEAD -- migrations/ schema/ \
> schema_changes.diff
# Classify: any breaking changes?
if grep -qiE \
"DROP COLUMN|RENAME|ALTER.*NOT NULL|DROP TABLE|DROP PROCEDURE" \
schema_changes.diff; then
echo "breaking=true" >> $GITHUB_OUTPUT
echo "Breaking schema changes detected"
else
echo "breaking=false" >> $GITHUB_OUTPUT
fi
- name: Block on breaking change without impact sign-off
if: steps.detect.outputs.breaking == 'true'
run: |
# Check for required impact analysis label on PR
if ! gh pr view ${{ github.event.pull_request.number }} \
--json labels --jq '.labels[].name' \
| grep -q "impact-analysis-complete"; then
echo "ERROR: Breaking schema change requires impact-analysis-complete label"
echo "Complete the impact analysis checklist before merging"
exit 1
fi
env:
GH_TOKEN: ${{ github.token }}
- name: Run catalog dependency check
run: |
psql ${{ secrets.DB_URL }} -f scripts/check_dependencies.sql \
| tee dependency_report.txt
if grep -q "DEPENDENT_COUNT > 0" dependency_report.txt; then
echo "Dependents found -- review dependency_report.txt"
fiVýše uvedená brána dělá tři věci: detekuje, zda jsou přítomny nějaké vzorce změn, vyžaduje, aby kontrolor dokončil a označil analýzu dopadu před povolením sloučení, a spustí dotaz na závislosti katalogu pro výčet závislých prvků v databázi. Požadavek na označení je klíčovým kontrolním bodem pro lidskou potřebu, nelze jej obejít kanálem, což znamená, že analýza dopadu musí proběhnout a být zdokumentována před sloučením kódu.
Co obsahuje kompletní zpráva o dopadu schématu
Výstupem analýzy dopadu schématu je strukturovaná zpráva, kterou mohou poradní sbory pro změny, architekti a správci databází použít k autorizaci nasazení. Kompletní zpráva obsahuje:
1. Definice navrhované změny , přesný implementovaný příkaz DDL, ovlivněná tabulka a sloupec a důvod změny.
2. Změňte klasifikaci z taxonomie rizik: ochranná nebo neochranná, úroveň rizika a specifickou kategorii dopadu (riziko ztráty dat, riziko selhání dotazu, riziko výkonu).
3. Interní závislé objekty databáze , výstup katalogizačního dotazu: každý pohled, uložená procedura, funkce a trigger, který odkazuje na změněný objekt, s jeho aktuální definicí a požadovanou změnou.
4. Závislé prvky kódu aplikace podle jazyka, s cestou k souboru, číslem řádku, kde je to možné, a nalezeným konkrétním odkazem SQL. Uspořádané podle týmu nebo služby, pokud kódovou základnu spravuje více týmů.
5. Závislé prvky ETL a kanálu podle názvu kanálu, úlohy a konkrétního odkazu na změněný sloupec nebo tabulku.
6. Následné a závislé subjekty partnera , podle názvu systému, datového kanálu nebo smlouvy API, s názvem pole, jak se zobrazuje v následném rozhraní.
7. Požadované změny na závislou položku , pro každou nalezenou závislou položku, konkrétní změna potřebná k zachování správnosti po nasazení změny schématu.
8. Pořadí nasazení , pořadí, ve kterém musí být závislé komponenty aktualizovány a změny schématu nasazeny, aby byla zachována konzistence. Zásadní změny obvykle vyžadují: (1) nasazení vrstvy kompatibility nebo výchozí hodnoty, (2) aktualizaci veškerého kódu aplikace tak, aby odkazoval na nový název sloupce, (3) nasazení kódu aplikace, (4) ověření, (5) nasazení změny schématu, (6) ověření, (7) odstranění vrstvy kompatibility.
9. Požadované testovací případy , jeden validační test na závislý typ a regresní testy pro všechny upravené uložené procedury.
10. Plán vrácení zpět , reverzní DDL a veškerá migrace dat potřebná k obnovení předchozího stavu schématu, pokud je nutné nasazení vrátit zpět.
Disciplína při hlášení: Zpráva o dopadu, která existuje, ale na jejímž základě se nejedná, je horší než žádná zpráva. Vytváří zdání náležité péče, zatímco skutečné riziko není zmírněno. Každá položka na seznamu závislých rizik musí být buď před nasazením aktualizována, nebo explicitně akceptována jako známé riziko s pohotovostním plánem.
Jak SMART TS XL Poskytuje analýzu dopadu schémat napříč jazyky
Standardní dotazy do katalogu databáze vyjmenovávají závislé prvky vrstvy 1, pohledy, uložené procedury a triggery v rámci databáze. Nástroje pro vyhledávání kódu aplikací vyjmenovávají některé závislé prvky vrstvy 2 v rámci jednoho jazyka. Žádný jednotlivý nástroj nepokrývá všechny čtyři vrstvy napříč všemi jazyky.
SMART TS XLJe statická analýza kódu Současně analyzuje vložený SQL v COBOL zdrojových souborech, řetězce dotazů JDBC v Java službách, modely SQLAlchemy v Python pipeline a definice objektů SQL. Když je navrženo přejmenování sloupce DB2, SMART TS XL identifikuje každý blok SQL kódu COBOL EXEC odkazující na daný sloupec, každý řetězec dotazu Java JDBC obsahující název sloupce, každý dotaz Pythonu používající daný sloupec a každý pohled SQL nebo uloženou proceduru, která na něj odkazuje, a to v jednom kroku analýzy v celém vícejazyčném portfoliu.
Mapování závislostí aplikace rozšiřuje analýzu nad rámec přímých odkazů na sloupce na strukturální řetězec závislostí: pokud služba Java volá uloženou proceduru, která odkazuje na změněný sloupec, mapa závislostí představuje jak závislost Java-procedura, tak závislost procedura-sloupec, takže služba Java je viditelná v rozsahu dopadu, i když její kód neobsahuje žádný přímý odkaz na sloupec.
Funkce analýzy dopadů používá tento graf závislostí mezi jazyky k zodpovězení konkrétní otázky, která předchází každé změně schématu: vzhledem k této navrhované změně vyjmenovat všechny komponenty, které budou ovlivněny, v každém jazyce, v každé vrstvě. Odpovědí je strukturovaný, vyjmenovaný seznam, který se přímo mapuje na výše uvedenou šablonu zprávy o dopadech, nikoli odhad, nikoli nejlepší vzpomínka vývojáře na to, co by mohlo být ovlivněno, ale strukturální odvození ze skutečného kódu.
Díky funkci podnikového vyhledávání je možné dotazovat inventář závislostí v průběhu celého životního cyklu správy změn: lze tak najít každý program, který odkazuje na konkrétní sloupec v jazycích COBOL, Java, Python a SQL současně, během několika sekund, napříč miliony řádků kódu.
Pro týmy spravující změny schémat v prostředích, která zahrnují starší modernizace U programů, kde může být databáze sdílena mezi modernizovanou mainframovou aplikací v COBOLu a moderními službami Java, které ji nahrazují, není analýza dopadu napříč jazyky volitelná. Během modernizačního přechodu jsou současně v produkci starší i moderní vrstvy. Změna schématu, která je z pohledu služby Java bezpečná, může být pro programy v COBOLu, které s ní stále běží, neznámá. SMART TS XL vidí obě strany této hranice současně.
Změny schématu nenarušují aplikace. Neanalyzované změny schématu ano.
Chyba nasazení na začátku této příručky, přejmenování sloupce, které přerušilo službu Java, dávková úloha COBOL a kanál reportingu tři hodiny po spuštění neměly žádný problém s migračním skriptem. Skript se spustil správně. Sloupec byl přejmenován přesně podle plánu. Selhala však analýza, která měla předcházet: výčet všech aplikací, které odkazovaly na původní název sloupce, ověření, zda byly všechny aktualizovány, a ověření, zda sekvence nasazení zachovala konzistenci mezi databází a každým příjemcem.
Analýza dopadu schématu není byrokratický kontrolní bod. Je to práce, která přemění riskantní nasazení na bezpečné, a to převedením neznámého rozsahu změny na výčtový, ověřitelný seznam všeho, co bude ovlivněno. Migrační skript trvá minutu. Analýza dopadu trvá tak dlouho, jak by měla. Produkční incident, kterému se zabrání, trvá dny.
