Fick några larm efter 17:30. 2 AG maskiner i utvecklingsmiljön hade dålig med utrymme på tempdb. När jag väl loggade in (inom några minuter) så var det drygt 4MB (av 5GB) ledig per datafil 😦

Började felsöka fel. Försökte kolla vem (vilken session) det är som håller på att ta slut på utrymme. Det kördes rensning i 3 system som jag flyttade dit i tisdags.

Men, varför var det slut på den andra AG maskinen?

Kollade loggarna och kände igen larmet. Samma larm som jag hade missat för exakt 2 veckor sedan. (som jag missade nu med. Fast gick det inte långt innan jag behagade kolla loggarna!
The version store is full. New version(s) could not be added. A transaction that needs to access the version store may be rolled back.

Via andra skript hittade jag felet på 3:e servern, den hade en öppen session sedan igår efter 17. Det på gick en delete kommando.

Den sessionen hade blockerat en annan session. Dödade sessionerna för att se om det hjälper. Nä det gjorde det inte.

Körde till slut kommandon jag hade sett i bloggen för 2 veckor sedan.

USE [master]
GO
ALTER AVAILABILITY GROUP [AGName]
MODIFY REPLICA ON N” WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = NO))
GO

Det hände inget. Temodb var fortfarande full på bägge maskinerna.

Backuperna startade.

Valde några kolumner till på AG dashboard. Såg senare att jag hade valt fel kolumn, redo rate istället för redo queue size (som jag brukar välja). Det var inga höga siffror, drygt 11 MB och tänkte, varför krånglar så lite data med mig?

Siffrorna ändrades inte (det var drygt 500 på ena databasen i AG och drygt 11000 på den andra databasen).

Körde resume. Hände inget. Samma siffror. När går backuperna klart?

När väl backuperna var klara så tänkte jag kolla storleken på tempdb. Tänkte att jag får starta om tjänsterna i värsta fall. Tempdb var återställd på bägge 🙂

Men samma siffror, vad fan, varför ändras inte siffrorna? Det brukar ju vara blankt (noll) eller så ändras i alla fall.

Körde resume på bägge AG replikornaoch körde följande nu när tempdb var återställd:

USE [master]
GO
ALTER AVAILABILITY GROUP [AGName]
MODIFY REPLICA ON N” WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL))
GO

Först efter det så jag mitt misstag, hade valt redo rate istället för
redo queue size.

Valde redo queue size och det fanns ingen data i kön. Klant!

Tempdb var fullt 17:30-19:45.

Var det (SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)) , de dödade sessionerna, eller backuperna som återställde tempdb? Eller var det kombination av dessa?

Det kan inte ha varit för mycket data i kön. Har ju andra larm som larmar om det ligger mer än 5 GB i kön (redo queue size) och sådana larm fick jag aldrig.

Har fått larm på 5-15 GB i kön utan att tempdb blivit full. Från andra sidan har vi inte haft dryga 24 timmar öpnna delete sessioner heller!

I morse var det annat fel. Kl 04 skulle det skickas ut ett mejl från ett system, ett av de system jag flyttade i tisdags. Det felade.

Loggade in 05:45 och kollade på jobbet. Proceduren som jobbet kickade igång hade en hårdkodning @profile_name i sp_send_dbmail. Gamla servernamnet stod där. Det går inte att sätta en profilnamn på AG direkt.

Kommenterade bort @profile_name och startade jobbet. Det funkade.

Kollade de andra jobben som skickar mejl. Det var en procedur till som hade en servernamn hårdkodad. Fixade det med.

Nä, nu är det dags att ta helg igen!