Request_session_id = – 2 ?

En av de många fördelar när man jobbar som konsult hos oss är att man får se olika miljöer och olika verksamheter. Ofta kan våra kunder ha likartade problem men så är inte alltid fallet. Ibland stöter man på problem som är rätt ovanliga, märkliga och inte alltid helt lätt att hitta lösningen till heller.

Här kommer ett exempel på detta. Om man upptäcker att loggfilen är större än datafilen bör man kontrollera vad detta beror på. En troliga orsak är att det finns aktiva transaktioner som inte avslutats som man kan se nedan. select name, log_reuse_wait_desc from sys.databases Ger detta resultat name log_reuse_wait_desc DBxxx ACTIVE_TRANSACTION Nästa steg blir då att kontrollera den äldsta transaktionen och förhoppningsvis avsluta den så att inte loggfilen fortsätter växa. För att hitta transaktionen använder man DBCC OPENTRAN, och detta kan ge följande resultat: Oldest active transaction: SPID (server process ID): 60 UID (user ID) : -1 Name : offline index build LSN : (109581:2986:82) Start time : Jan 12 2012 10:31:04:337PM SID : 0x0 DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Som regel vill man avsluta en så gammal transaktionen som i det här fallet , dvs SPID = 60 och detta gör man med KILL. Innan man gör det vill man förstås kontrollera vilken kod som kan vara orsak till den aktiva transaktionen och för detta använder man DBCC INPUTBUFFER. Nu börjar det intressanta. Detta kan nämligen inte vara samma transaktion som vi är ute efter. Kan det då vara en sk. Orphaned MSDTC transactions som är mycket bra beskriven här och som många refererar till t.ex. Paul Randall. Nu finns en chans att vi kan använda request_owner_guid och därefter KILL. SELECT sys.databases.database_id, sys.databases.name, sys.dm_tran_locks.request_owner_guid FROM sys.dm_tran_locks INNER JOIN sys.databases ON sys.dm_tran_locks.resource_database_id = sys.databases.database_id WHERE sys.dm_tran_locks.request_session_id = – 2 Nej, detta hjälper inte med ‘00000000-0000-0000-0000-000000000000’ som request_owner_guid.

Vi testar då till slut att starta om SQL Serverns tjänster och också omstart av msdtc, men inte heller detta hjälper i det här fallet. Nästan direkt efter omstart kommer vår “felaktiga transaktion” som nu leder oss mot fulltext index mha fn_dblog som innebär att vi kan läsa från transaktionsloggen. Nästa steg blir nu att kontrollera alla fulltext index för databasen. Detta visar något mycket märkligt, nämligen att dessa är uppdaterade så länge sedan som under 2009. Normalt skall detta ske vid t.ex. insert. När index är uppdaterade kan man se enkelt med nedastående SQL-sats. SELECT sch.name AS SchemaName, t.name AS TableName, c.name AS FTCatalogName, i.has_crawl_completed, i.crawl_start_date, i.crawl_end_date FROM sys.tables t JOIN sys.fulltext_indexes i ON t.object_id = i.object_id JOIN sys.fulltext_catalogs c ON i.fulltext_catalog_id = c.fulltext_catalog_id JOIN sys.schemas sch ON sch.schema_id = t.schema_id ORDER BY SchemaName, TableName Vad händer då om vi bygger om index’ena med ALTER FULLTEXT CATALOG xxx REBUILD ?.

Jo, crawl_start_date och crawl_end_date uppdateras nu med dagens datum.  Dock har vi kvar våran Active Transaction, men inte länge till. För efter en omstart av SQL Server så är allt nu ok :-). Som sagt, ibland kan en felsökning bestå av många tester och antaganden innan man till slut hittar den slutgilitga orsaken.