Ta bort extra logfil

Att ta bort en extra logfil är inte alltid så lätt…

Följande scenario inträffade nyligen:

• Kund gör stora uppdateringar i sin databas men upptäcker att logfilen börjar växa snabbt. Då disken börjar bli full skapar man en extra logfil på en annan disk med gott om plats.
• Då databasen ingår i en Availability Group måste den nya logfilen skapas även på den sekundära servern. Detta skedde dock inte då den sekundära servern inte hade exakt samma diskuppsättning som den primära servern och den nya/extra logfilen skapades på en disk som endast existerade på den primära servern.
• När uppdateringen var klar ville man såklart ta bort den nya logfilen då det inte finns några prestandafördelar i att ha flera logfiler. Försök gjordes genom att köra kommandot DBCC SHRINKFILE med EMPTYFILE dock utan framgång, filen gick inte att ta bort, felmeddelande: “The file ‘XXXXX_FILE2_log’ cannot be removed because it is not empty”
• SQL Service kontaktades för att lösa problemet och först kontrollerades status på vlf med
  SELECT * FROM sys.dm_db_log_info (db_id()). Här kunde man se att den andra logfilen (som vi vill få bort) hade aktiva vlf:er.
• Log backup kördes några gånger för att se om dessa entrys försvann. Det hjälpte dock inte.
• Kontroll av log_reuse_wait_desc i sys.databases gjordes och status för databasen var: AVAILABILITY_REPLICA. Vårt problem har alltså att göra med det faktum att databasen är med i en Availability Group.
• Det visar sig nu att speglingen stannat och det gick inte att få igång den igen då den nya logfilen inte kunde skapas på den sekundära servern. Enda vägen framåt var att ta bort databasen från Availability Gruppen.
• Databasen togs bort från Availability Gruppen, efter det gick det bra att ta bort den extra logfilen.
• En snabb kontroll i utforskaren visade att logfilen var borta. En kontroll genom högerklick/Properties/Files på databasen visade dock att filen var kvar !!?? En extra kontroll i sys.master_files visade även den att logfilen var kvar, dock med status offline.
• Nu börjar detta kännas lite olustigt. Så länge vi har metadata som inte stämmer överens med verkligheten kan det få stora konsekvenser om vi tex startar om instansen och SQL Server börja leta efter den borttagna logfilen….vi riskerar att databasen inte kommer upp som den skall.
• Försök gjordes igen att köra ALTER DATABASE [XXXXX] REMOVE FILE [XXXXX_FILE2_log] men returnerade bara följande:
  “One or more files listed in the statement could not be found or could not be initialized.”
• Efter en stunds betänketid beslutades att köra en log backup. Detta visade sig vara det som behövdes för att metadata i SQL Server återigen skulle vara korrekt. YES!!
• Nu var det bara att återigen lägga in databasen i Availability Gruppen. Allt ovanstående gjordes utan avbrott och utan att slutanvändarna märkte någonting.

-Ibland kan ett problem med till synes rutinmässig lösning vara svårare än man tror…