Diagnostikanslutning för databasadministratörer

2025-08-28

gäller för:SQL Server Azure SQL Database Azure SQL Managed Instance

SQL Server tillhandahåller en särskild diagnostikanslutning för administratörer när standardanslutningar till servern inte är möjliga. Med den här diagnostikanslutningen kan en administratör komma åt SQL Server för att köra diagnostikfrågor och felsöka problem även när SQL Server inte svarar på standardanslutningsbegäranden.

Den här dedikerade administratörsanslutningen (DAC) stöder kryptering och andra säkerhetsfunktioner i SQL Server. DAC tillåter endast att användarkontexten ändras till en annan administratörsanvändare.

SQL Server gör alla försök att få DAC att ansluta, men i extrema situationer kanske det inte lyckas.

Ansluta med DAC

Som standard tillåts anslutningen endast från en klient som körs på servern. Nätverksanslutningar tillåts inte om de inte konfigureras med hjälp av den sp_configure lagrade proceduren med serverkonfigurationsalternativet fjärradministratörsanslutningar .

Endast medlemmar i SQL Server-sysadmin-rollen kan ansluta med hjälp av DAC.

DAC:en är tillgänglig och stöds via sqlcmd kommandotolken med hjälp av en särskild administratörsväxel (-A). Mer information om hur du använder sqlcmdfinns i sqlcmd – Använd med skriptvariabler. Du kan också ansluta prefix admin: till instansnamnet i formatet sqlcmd -S admin:<instance_name>. Du kan också initiera en DAC från en SQL Server Management Studio-frågeredigerare genom att ansluta till admin:<instance_name>.

Så här etablerar du en DAC från SQL Server Management Studio:

Koppla från alla anslutningar till den relaterade SQL Server-instansen, inklusive Object Explorer och alla öppna frågefönster.
På menyn väljer du Fråga om ny >> databasmotor
I dialogrutan Anslutning i fältet Servernamn anger du admin:<server_name> om du använder standardinstansen eller admin:<server_name>\<instance_name> om du använder en namngiven instans.

DAC-port

SQL Server lyssnar efter DAC på TCP-port 1434 om det är tillgängligt eller en TCP-port dynamiskt tilldelad vid start av databasmotorn. Felloggen innehåller portnumret som DAC lyssnar på. Som standard accepterar DAC-lyssnaren endast anslutning på den lokala porten. Ett kodexempel som aktiverar fjärradministrationsanslutningar finns i Serverkonfiguration: fjärradministratörsanslutningar.

När fjärradministrationsanslutningen har konfigurerats aktiveras DAC-lyssnaren utan att starta om SQL Server och en klient kan nu ansluta till DAC via fjärranslutning. Du kan göra så att DAC-lyssnaren accepterar anslutningar via fjärranslutning även om SQL Server inte svarar genom att först ansluta till SQL Server med hjälp av DAC lokalt och sedan köra den sp_configure lagrade proceduren för att acceptera anslutning från fjärranslutningar.

I klusterkonfigurationer är DAC inaktiverat som standard. Användare kan köra alternativet fjärradministratörsanslutning sp_configure för för att aktivera DAC-lyssnaren för åtkomst till en fjärranslutning. Om SQL Server inte svarar och DAC-lyssnaren inte är aktiverad kan du behöva starta om SQL Server för att ansluta till DAC. Därför rekommenderar vi att du aktiverar konfigurationsalternativet fjärradministratörsanslutningar i klustrade system.

DAC-porten tilldelas dynamiskt av SQL Server under starten. När du ansluter till standardinstansen undviker DAC att använda en SSRP-begäran (SQL Server Resolution Protocol) till SQL Server Browser Service vid anslutning. Den ansluter först via TCP-port 1434. Om det misslyckas gör det ett SSRP-anrop för att hämta porten. Om SQL Server Browser inte lyssnar efter SSRP-begäranden returnerar anslutningsbegäran ett fel. Se felloggen för att hitta portnumret DAC lyssnar på. Om SQL Server har konfigurerats för att acceptera fjärradministrationsanslutningar måste DAC initieras med ett explicit portnummer:

sqlcmd -S tcp:<server>,<port>

SQL Server-felloggen visar portnumret för DAC, som är 1434 som standard. Om SQL Server är konfigurerat för att endast acceptera lokala DAC-anslutningar ansluter du med hjälp av loopback-adaptern med följande kommando:

sqlcmd -S 127.0.0.1,1434

Begränsningar

Eftersom DAC endast finns för att diagnostisera serverproblem i sällsynta fall finns det vissa begränsningar för anslutningen:

För att garantera att det finns resurser tillgängliga för anslutningen tillåts endast en DAC per instans av SQL Server. Om en DAC-anslutning redan är aktiv nekas alla nya begäranden om att ansluta via DAC med fel 17810.
För att spara resurser lyssnar INTE SQL Server Express på DAC-porten om den inte startas med spårningsflagga 7806.
DAC försöker först ansluta till standarddatabasen som är associerad med inloggningen. När den har anslutits kan du ansluta till master databasen. Om standarddatabasen är offline eller på annat sätt inte är tillgänglig returnerar anslutningen fel 4060. Det lyckas dock om du åsidosätter standarddatabasen master för att ansluta till databasen i stället med hjälp av följande kommando:
```
sqlcmd -A -d master
```
Vi rekommenderar att du ansluter till master databasen med DAC eftersom master det garanterat är tillgängligt om instansen av databasmotorn startas.
SQL Server förbjuder körning av parallella frågor eller kommandon med DAC. Till exempel genereras fel 3637 om du kör någon av följande instruktioner med DAC:
- RESTORE...
- BACKUP...
Endast begränsade resurser garanteras vara tillgängliga med DAC. Använd inte DAC för att köra resursintensiva frågor eller frågor som kan blockera andra frågor. Detta förhindrar att DAC förvärrar befintliga serverproblem. För att undvika potentiella blockeringsscenarier, om du måste köra frågor som kan blockera, kör du frågan under ögonblicksbildsbaserade isoleringsnivåer om möjligt. Annars anger du transaktionsisoleringsnivån till READ UNCOMMITTED och anger LOCK_TIMEOUT värdet till ett kort värde, till exempel 2 000 millisekunder eller båda. Detta förhindrar att DAC-sessionen blockeras. Beroende på vilket tillstånd SQL Server är i kan DAC-sessionen dock blockeras på en spärr. Du kanske kan avsluta DAC-sessionen med hjälp av CTRL-C men det är inte garanterat. I så fall kan ditt enda alternativ vara att starta om SQL Server.
För att garantera anslutning och felsökning med DAC reserverar SQL Server begränsade resurser för att bearbeta kommandon som körs på DAC. Dessa resurser räcker vanligtvis bara för enkla diagnostik- och felsökningsfunktioner, till exempel de som anges nedan.

Även om du teoretiskt sett kan köra alla Transact-SQL-instruktioner som inte behöver köras parallellt på DAC,rekommenderar vi starkt att du begränsar användningen till följande diagnostik- och felsökningskommandon:

Köra frågor mot dynamiska hanteringsvyer för grundläggande diagnostik, till exempel sys.dm_tran_locks för låsningsstatus, sys.dm_os_memory_cache_counters för att kontrollera hälsotillståndet för cacheminnen samt sys.dm_exec_requests och sys.dm_exec_sessions för aktiva sessioner och begäranden. Undvik dynamiska hanteringsvyer som är resursintensiva ( till exempel sys.dm_tran_version_store genomsöker det fullständiga versionsarkivet och kan orsaka omfattande I/O) eller som använder komplexa kopplingar. Information om prestandakonsekvenser finns i dokumentationen för den specifika vyn för dynamisk hantering.
Fråga katalogvyer.
Grundläggande DBCC-kommandon som DBCC FREEPROCCACHE, DBCC FREESYSTEMCACHE, DBCC DROPCLEANBUFFERS och DBCC SQLPERF. Undvik resursintensiva kommandon som DBCC CHECKDB, DBCC DBREINDEX eller DBCC SHRINKDATABASE.
KILL <spid>Transact-SQL kommando. Beroende på tillståndet för SQL Server KILL kanske kommandot inte lyckas. Det enda alternativet kan vara att starta om instansen, när det gäller SQL Server eller Azure SQL Managed Instance. Följande är några allmänna riktlinjer:
- Kontrollera att SPID har dödats genom att SELECT * FROM sys.dm_exec_sessions WHERE session_id = <spid>;fråga . Om den inte returnerar några rader innebär det att sessionen avbröts.
- Om sessionen fortfarande finns där kontrollerar du om det finns uppgifter som tilldelats den här sessionen genom att köra frågan SELECT * FROM sys.dm_os_tasks WHERE session_id = <spid>;. Om du ser uppgiften där är det troligt att sessionen för närvarande avlivas. Detta kan ta lång tid och kanske inte lyckas alls.
- Om det inte finns några uppgifter i den sys.dm_os_tasks här sessionen, men sessionen är kvar sys.dm_exec_sessions efter att KILL kommandot har körts, innebär det att du inte har någon tillgänglig arbetare. Välj en av de aktiviteter som körs (en uppgift som visas i sys.dm_os_tasks vyn med en sessions_id <> NULL) och avsluta den session som är associerad med den för att frigöra arbetaren. Det kanske inte räcker att döda en enda session: du kanske måste döda flera.

Begränsning i Azure SQL Database

När du ansluter till Azure SQL Database med DAC måste du också ange databasnamnet i anslutningssträngen med hjälp -d av alternativet .

Begränsning i Azure SQL Managed Instance

DAC fungerar inte över en privat slutpunkt för Azure SQL Managed Instance. På SQL-hanterade instanser lyssnar DAC på port 1434. Eftersom privata slutpunkter till SQL-hanterade instanser endast tillåter anslutningar på port 1433 kan du inte använda en privat slutpunkt för att upprätta en DAC-anslutning. Du måste vara i samma virtuella nätverk som den SQL-hanterade instansen för att kunna ansluta till DAC.

Examples

I det här exemplet ser en administratör att servern contoso-server inte svarar och vill diagnostisera problemet. För att göra detta aktiverar sqlcmd användaren kommandotolken och ansluter till servern contoso-server med hjälp av -A för att ange DAC.

sqlcmd -S contoso-server -U sa -P <StrongPassword> -A

Administratören kan nu köra frågor för att diagnostisera problemet och eventuellt avsluta sessionerna som inte svarar.

Ett liknande exempel som ansluter till SQL Database skulle använda följande kommando, inklusive parametern -d för att ange databasen:

sqlcmd -S serverName.database.windows.net,1434 -U sa -P <StrongPassword> -d AdventureWorks

Feedback

Var den här sidan till hjälp?