Månadsrapporten tar en halvtimme och gör systemet segt för alla? Varför det händer och hur du löser det

Sista arbetsdagen i månaden. Klockan åtta på morgonen startar ekonomiavdelningen månadens försäljningsrapport. Fem minuter senare kan lagret inte skriva ut följesedlar, och säljarna ringer IT och säger att systemet har gått ner. Ingen vet vad som händer, så någon på ekonomi klickar på ”Skapa” en gång till. Nu körs två rapporter.

Scenariot är påhittat, men nästan varje företag med ett eget affärssystem känner igen det. Och oftast är det inte servern det är fel på. Det är sättet rapporterna är byggda på.

1. 08:00Ekonomi startar månadsrapporten
2. 08:05Lagret kan inte skriva ut följesedlar
3. 08:20Säljarna säger att systemet har gått ner
4. 08:25Någon startar rapporten igen
5. 08:40Rapporten får timeout och börjar om

Varför en enda rapport stoppar alla

Tänk dig en butik som stänger för inventering medan kunderna fortfarande står i kö vid kassan. Affärssystem gör så hela tiden:

• Rapporterna och det dagliga arbetet använder samma databas. Rapporten läser miljontals rader, och samma disk, minne och processor ska samtidigt betjäna lagret, säljarna och alla andra.
• Läsning blockerar skrivning. På SQL Server kan en lång läsning som standard hålla uppe alla som vill ändra samma data, och tvärtom. Rapporten väntar på lagret, lagret väntar på rapporten.
• Allt räknas om från början. För att få fram förra månadens summa lägger rapporten ihop fem års fakturor varje gång. Så länge det fanns lite data märkte ingen det.
• Applikationen hämtar allt till minnet. I stället för att låta databasen summera och skicka tillbaka hundra rader laddar applikationen all data och räknar själv.
• Användaren väntar framför skärmen. Rapporten körs medan webbläsaren väntar. När webbläsaren ger upp klickar användaren igen, och samma arbete körs dubbelt.

Vad det kostar

Ett enkelt exempel med påhittade, men realistiska siffror:

Personer som arbetar i applikationen	40
Förlorad tid varje gång en rapport gör allt segt	30 minuter
Hur ofta det händer (månadsbokslut, moms, ledningsmöte, ad hoc)	4 gånger i månaden
Förlorade timmar per månad	80
Med 30 € i timmen	2 400 € i månaden, nästan 29 000 € om året

Det är bara det som går att räkna. Till det kommer leveranser som går iväg för sent, en ekonomiavdelning som stannar kvar på kvällen för att inte störa någon, och beslut som fattas på gamla siffror eftersom ingen vågar köra rapporten under arbetstid.

Lösningar, den billigaste först

Den goda nyheten är att du sällan behöver ett nytt system. Ordningen är oftast densamma:

Lösning	Vad den innebär	Insats
1. Frågan och index	Rapporten frågar databasen på rätt sätt och får bara det den behöver	Dagar
2. Läsning blockerar inte skrivning	En databasinställning så att rapporten och lagret slutar vänta på varandra	Timmar till dagar, med tester
3. Rapporten körs i bakgrunden	Användaren klickar, jobbar vidare och får ett mejl med en länk när rapporten är klar	Dagar
4. Förberäknade summor	Summor per dag, kund och artikel räknas ut en gång, på natten	Dagar till veckor
5. En separat kopia för rapporter	Rapporterna läser från en kopia av databasen, det dagliga arbetet använder originalet	Dagar, beroende på plattform

1. Frågan och index. Det här är nästan alltid det första steget, och ofta det sista. En rapport som läser hela tabellen för att ett index saknas, eller en rapport som skickar tusentals frågor för en enda sida, kan gå från en halvtimme till under en minut. De vanligaste orsakerna har vi beskrivit i artiklarna om långsamma applikationer och EF Core-prestanda.

2. Läsning blockerar inte skrivning. SQL Server har ett alternativ (Read Committed Snapshot Isolation) som låter en rapport läsa en konsekvent bild av datan utan att stoppa någon som skriver. I Azure SQL Database är det påslaget som standard, på din egen SQL Server avslaget. Det är en enda inställning, men den ändrar hur databasen beter sig, så den testas innan den går live.

3. Rapporten körs i bakgrunden. I stället för att någon väntar framför skärmen hamnar rapporten i en kö och skapas när det finns kapacitet, en i taget. Den som beställde den får ett mejl när den är klar. Inga fler dubbelklick och timeouts, och de tyngsta rapporterna kan vänta till kvällen.

4. Förberäknade summor. De flesta rapporter frågar samma sak: hur mycket, per dag, kund, artikel eller region. De summorna kan räknas ut en gång, på natten eller efter varje ändring, och rapporten läser sedan några tusen rader i stället för några miljoner.

5. En separat kopia för rapporter. Om du använder Azure SQL Database på nivån Premium eller Business Critical betalar du redan för en skrivskyddad kopia av databasen som applikationen inte använder. Rapporterna skickas dit med en inställning i anslutningssträngen:

"ConnectionStrings": {
  "App":     "Server=tcp:company.database.windows.net;Database=Erp;...",
  "Reports": "Server=tcp:company.database.windows.net;Database=Erp;ApplicationIntent=ReadOnly;..."
}

Det dagliga arbetet använder App, rapporterna använder Reports, och de slåss inte längre om samma resurser. Data kan komma fram till kopian en stund senare än till originalet, vilket inte spelar någon roll för en månadsrapport. På en egen SQL Server går något liknande att göra, men det beror på utgåva och licenser, så det kontrolleras först.

I vilken ordning

1. MätVilka rapporter som gör ont, och varför
2. FrågorIndex och färre anrop
3. BakgrundIngen väntar framför skärmen
4. Summor och kopiaBara om det fortfarande behövs

Först mäter man, som alltid. Mätningen visar vilka tre eller fyra rapporter som orsakar det mesta av problemen, och ofta är det mindre arbete än det såg ut. Först när frågorna är i ordning är det värt att prata om bakgrundskörning, förberäknade summor och en separat databas. Ett nytt rapportverktyg eller en större server kommer sist, om alls.

Så arbetar vi

ProCoding är en .NET-studio från Split i Kroatien. Långsamma rapporter och en databas som håller uppe alla andra är precis det vi åtgärdar: i .NET-applikationer, SQL Server och Azure SQL, från frågor och index till bakgrundskörning och skrivskyddade kopior av databasen. Mer om vad vi gör i Azure finns på sidan Azure för .NET-applikationer.

Vi börjar med att mäta era rapporter, och du får en lista över orsaker och lösningar, rangordnade efter vad som lönar sig mest. Sedan åtgärdar vi dem, eller så gör ditt team det, det som passar dig bäst. Det första steget är ett kostnadsfritt samtal på 30 minuter.

Källor

• Read queries on replicas (read scale-out), Microsoft Learn
• SET TRANSACTION ISOLATION LEVEL, Microsoft Learn
• Background tasks with hosted services in ASP.NET Core, Microsoft Learn