Felsöka anslutningsproblem och andra fel

gäller för:Azure SQL DatabaseAzure SQL Managed InstanceSQL-databas i Fabric

Du får felmeddelanden när anslutningen till Azure SQL Database, SQL Database i Microsoft Fabric eller Azure SQL Managed Instance misslyckas.

Tillämpa som alltid metodtips och designriktlinjer under programdesignprocessen .

Steg för att åtgärda vanliga anslutningsproblem

1. Kontrollera att TCP/IP är aktiverat som ett klientprotokoll på programservern. På programservrar där du inte har SQL-verktyg installerade kontrollerar du att TCP/IP är aktiverat genom att köra cliconfg.exe (SQL Server Client Network-verktyget).

2. Kontrollera programmets anslutningssträng för att kontrollera att den är korrekt konfigurerad. Kontrollera till exempel att anslutningssträngen anger rätt port (1433) och fullständigt kvalificerat servernamn. Se Hämta anslutningsinformation med SQL Server Management Studio.

3. Försök att öka tidsgränsvärdet för anslutningen. Vi rekommenderar att du använder en tidsgräns för anslutningen på minst 30 sekunder.

4. Testa anslutningen mellan programservern och Azure SQL Database med hjälp av Snabbstart: Använd SSMS för att ansluta till och fråga Azure SQL Database eller Azure SQL Managed Instance, en UDL-fil, ping eller telnet. Mer information finns i Felsöka anslutningsproblem och diagnostik för anslutningsproblem.

   Anmärkning

   Som ett felsökningssteg kan du även testa anslutningen på en annan klientdator.

5. Som bästa praxis måste molnanslutna program använda logik för återförsök.

Om de här stegen inte löser problemet kan du försöka samla in mer data och sedan kontakta supporten. Om ditt program är en molntjänst aktiverar du loggning. Det här steget returnerar en UTC-tidsstämpel för felet. Mer information om hur du aktiverar loggning finns i Aktivera diagnostikloggning för appar i Azure App Service. Dessutom returnerar SQL Database spårnings-ID:t. Microsofts kundtjänst kan använda den här informationen.

Anslutningsfel som orsakas av anpassade DNS- eller värdfilsidosättningar

Om ditt program har beständiga inloggningsfel (fel 18456, 40532 eller 40615) som är isolerade till specifika klientnätverk medan Azure SQL-tjänsten är felfri kan orsaken vara en anpassad DNS-konfiguration som fäster serverns FQDN på en inaktuell Azure SQL gateway-IP.

Varför händer detta

Azure SQL Database använder en flotta av regionala gatewayer. Azure drar regelbundet tillbaka och ersätter gatewayer som en del av normala åtgärder, inklusive maskinvaruuppdatering, skalning och hälsodriven migrering. Den Azure auktoritativa DNS för <server>.database.windows.net uppdateras automatiskt för att återspegla de aktuella aktiva gatewayerna.

När din miljö åsidosätter den här DNS-upplösningen (via en värdfilspost, en statisk CNAME-post eller en privat DNS-zon som mappar serverns FQDN till en specifik IP-adress), fästs klienten på IP-adressen. Om gatewayen vid den IP-adressen senare dras tillbaka eller omtilldelas går anslutningarna till fel slutpunkt. Den Azure SQL gatewayen verifierar inkommande FQDN mot målservern och ett matchningsfel orsakar inloggningsfel.

Identifiera en DNS-åsidosättning

Kör följande kontroller från den berörda klienten.

1. Kontrollera om det finns åsidosättningar i den lokala värdfilen:

   :: Windows
   type C:\Windows\System32\drivers\etc\hosts | findstr /i "database.windows.net"
   

   # Linux or macOS
   grep -i "database.windows.net" /etc/hosts
   

2. Jämför klient-DNS-upplösning med Azure-auktoritativ DNS:

   :: Client or recursive resolver
   nslookup <server>.database.windows.net
   
   :: Authoritative public DNS
   nslookup <server>.database.windows.net 208.67.222.222
   

   # PowerShell
   Resolve-DnsName -Name "<server>.database.windows.net" -DnsOnly
   

   Om klientlösaren returnerar en annan IP-adress än den auktoritativa DNS:en är en DNS-åsidosättning aktiv.

3. Kontrollera CNAME- eller privata DNS-zoners åsidosättningar.

   nslookup -type=CNAME <server>.database.windows.net
   

   az network private-dns record-set list \
     --resource-group <ResourceGroup> \
     --zone-name database.windows.net \
     --output table
   

Åtgärda åsidosättningen

1. Ta bort åsidosättningen. Ta bort värdfilposten, ta bort den statiska CNAME-posten eller ta bort den privata DNS-zonposten som fäster serverns FQDN på en specifik IP-adress.

2. Töm DNS-cacheminnen på klienten och eventuella mellanliggande lösare.

   :: Windows
   ipconfig /flushdns
   

   # Linux (systemd-resolved)
   sudo systemd-resolve --flush-caches
   
   # macOS
   sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   

3. Kontrollera att DNS nu matchar den aktuella Azure gatewayen:

   nslookup <server>.database.windows.net
   

   Bekräfta att den returnerade IP-adressen ligger inom de publicerade gateway-IP-intervallen för serverns region. Listan finns i avsnittet Gateway-IP-adresser i Anslutningsarkitektur.

4. Testa anslutningen igen med hjälp av Azure SQL Connectivity Checker eller SQL Server Management Studio (SSMS).

Förhindra det här problemet

• Fäst aldrig Azure SQL server-FQDN på specifika IP-adresser i värdfiler, statiska CNAME-poster eller privata DNS-zoner. Azure SQL gatewayer är dynamiska och ändras över tid.
• Om du använder tillåtna brandväggslistor baserat på gateway-IP-adresser tillåter du alla gateway-IP-intervall för din region i stället för enskilda IP-adresser. Använd Sql.<region> tjänsttaggen där det är möjligt.
• För privat anslutning använder du Azure Private Link eller privata slutpunkter i stället för DNS-åsidosättningar. Privata slutpunkter tillhandahåller stabila privata IP-adresser i ditt virtuella nätverk och dirigerar direkt till gatewayen.
• Prenumerera på Service Health-aviseringar för Azure SQL Database för att ta emot meddelanden om gatewaymigreringar i din region.

Snabbreferens

Implementera logik för återförsök

Vi rekommenderar starkt att klientprogrammen använder omprövningslogik så att de kan återupprätta en anslutning efter att ha gett den tillfälliga feltiden att korrigera sig själv. Vi rekommenderar att du fördröjer i 5 sekunder innan du försöker igen. Ett nytt försök efter en fördröjning som är kortare än 5 sekunder riskerar att överbelasta molntjänsten. För varje efterföljande återförsök bör fördröjningen växa exponentiellt, upp till högst 60 sekunder.

Kodexempel på omprövningslogik finns i:

• Anslut elastiskt till SQL med ADO.NET
• Anslut elastiskt till SQL med PHP-

Mer information om hur du hanterar tillfälliga fel i ditt program finns i Felsöka tillfälliga anslutningsfel.

En diskussion om blockeringsperioden för klienter som använder ADO.NET finns i Anslutningspool (ADO.NET).

Tillfälliga felmeddelanden (40197, 40613 och andra)

Azure-infrastrukturen har kapacitet att dynamiskt omkonfigurera servrar vid ökad arbetsbelastning i SQL Database-tjänsten. Den här dynamiska funktionen kan göra att ditt klientprogram förlorar anslutningen till databasen eller instansen. Den här typen av felvillkor kallas för ett tillfälligt fel. Databasomkonfigurationshändelser inträffar på grund av en planerad händelse (till exempel en programvaruuppgradering) eller en oplanerad händelse (till exempel en processkrasch eller belastningsutjämning). De flesta omkonfigurationshändelser är kortvariga och bör slutföras på högst 60 sekunder. Dessa händelser kan dock ibland ta längre tid att slutföra, till exempel när en stor transaktion orsakar en långvarig återställning. I följande tabell visas olika tillfälliga fel som program kan ta emot när de ansluter till Azure SQL Database.

Lista över tillfälliga felkoder

Steg för att lösa tillfälliga anslutningsproblem

1. Kontrollera microsoft Azure Service-instrumentpanelen om det finns kända avbrott som inträffade under den tid då programmet rapporterar.
2. Program som ansluter till en molntjänst som Azure SQL Database bör förvänta sig regelbundna omkonfigurationshändelser och implementera omprövningslogik för att hantera dessa fel i stället för att visa programfel för användare.
3. När en databas närmar sig sina resursgränser kan det verka vara ett tillfälligt anslutningsproblem. Se Resursbegränsningar.
4. Om anslutningsproblemen fortsätter, eller om varaktigheten för programmet påträffar felet överskrider 60 sekunder eller om du ser flera förekomster av felet under en viss dag, skickar du en Azure Support begäran genom att välja Hämta support på Azure-supportwebbplatsen.

Ett nätverksrelaterat eller instansspecifikt fel uppstod när en anslutning till servern upprättades

Problemet uppstår om programmet inte kan ansluta till servern.

Lös problemet genom att prova stegen (i den ordning som visas) i avsnittet Steg för att åtgärda vanliga anslutningsproblem .

Servern/instansen hittades inte eller var inte tillgänglig (fel 26, 40, 10053)

Fel 26: Fel vid lokalisering av angiven server

System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections.(provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)

Fel 40: Det gick inte att öppna en anslutning till servern

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

Fel 10053: Ett transportnivåfel har inträffat när resultat från servern tas emot

10053: A transport-level error has occurred when receiving results from the server. (Provider: TCP Provider, error: 0 - An established connection was aborted by the software in your host machine)

Dessa problem uppstår om programmet inte kan ansluta till servern.

Lös dessa problem genom att prova stegen (i den ordning som visas) i avsnittet Steg för att åtgärda vanliga anslutningsproblem .

Det går inte att ansluta till servern på grund av brandväggsproblem

Fel 40615: Det går inte att ansluta till < servernamnet >

Lös problemet genom att konfigurera brandväggsinställningar på SQL Database via Azure-portalen.

Fel 5: Det går inte att ansluta till < servernamnet >

Lös problemet genom att kontrollera att port 1433 är öppen för utgående anslutningar i alla brandväggar mellan klienten och Internet.

Det går inte att logga in på servern (fel 18456, 40531)

Inloggningen misslyckades för användarens< användarnamn >

Login failed for user '<User name>'.This session has been assigned a tracing ID of '<Tracing ID>'. Provide this tracing ID to customer support when you need assistance. (Microsoft SQL Server, Error: 18456)

Lös problemet genom att kontakta tjänstadministratören och ange ett giltigt användarnamn och lösenord.

Vanligtvis kan tjänstadministratören använda följande steg för att lägga till inloggningsuppgifterna:

1. Logga in på servern med hjälp av SQL Server Management Studio (SSMS).

2. Kontrollera om inloggningsnamnet är inaktiverat genom att köra följande SQL-fråga i master databasen:

   SELECT name, is_disabled FROM sys.sql_logins;
   

3. Om motsvarande namn är inaktiverat kan du välja att aktivera det med hjälp av följande instruktion:

   ALTER LOGIN <User name> ENABLE;
   

4. Om SQL-inloggningsanvändarnamnet inte finns redigerar du och kör följande SQL-fråga för att skapa en ny SQL-inloggning:

   CREATE LOGIN <SQL_login_name, sysname, login_name>
   WITH PASSWORD = '<password, sysname, Change_Password>';
   GO
   

5. I SSMS Object Explorer, expandera Databaser.

6. Välj den databas som du vill ge användaren behörighet till.

7. Högerklicka på Säkerhet och välj sedan Ny, Användare.

8. I det genererade skriptet med platshållare följer du stegen för att ersätta SSMS-mallparametrar och kör det, till exempel:

   CREATE USER [<user_name, sysname, user_name>]
   FOR LOGIN [<login_name, sysname, login_name>]
   WITH DEFAULT_SCHEMA = [<default_schema, sysname, dbo>];
   GO
   
   -- Add user to the database owner role
   EXEC sp_addrolemember N'db_owner', N'<user_name, sysname, user_name>';
   GO
   

   Du kan också använda sp_addrolemember för att mappa specifika användare till specifika databasroller.

   Anmärkning

   I Azure SQL Database bör du överväga den nyare ALTER ROLE-syntaxen för att hantera databasrollmedlemskap.

Mer information finns i Auktorisera databasåtkomst.

Tidsgränsen för anslutningen har upphört att gälla

System.Data.SqlClient.SqlException (0x80131904): Tidsgränsen för anslutningen har upphört att gälla

System.Data.SqlClient.SqlException (0x80131904): Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=3; handshake=29995;

System.Data.SqlClient.SqlException (0x80131904): Tidsgränsen har upphört att gälla

System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

System.Data.Entity.Core.EntityException: Den underliggande providern misslyckades i Open

System.Data.Entity.Core.EntityException: The underlying provider failed on Open. -> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. -> System.ComponentModel.Win32Exception: The wait operation timed out

Det går inte att ansluta till < servernamnet >

Cannot connect to <server name>.ADDITIONAL INFORMATION:Connection Timeout Expired. The timeout period elapsed during the post-login phase. The connection could have timed out while waiting for server to complete the login process and respond; Or it could have timed out while attempting to create multiple active connections. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=231; handshake=983; [Login] initialization=0; authentication=0; [Post-Login] complete=13000; (Microsoft SQL Server, Error: -2) For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=-2&LinkId=20476 The wait operation timed out

Dessa undantag kan inträffa antingen på grund av anslutningsproblem eller frågeproblem. Information om hur du bekräftar att anslutningsproblem har orsakat det här felet finns i Bekräfta om ett fel orsakas av ett anslutningsproblem.

Tidsgränser för anslutning inträffar eftersom programmet inte kan ansluta till servern. Lös problemet genom att prova stegen (i den ordning som visas) i avsnittet Steg för att åtgärda vanliga anslutningsproblem .

Felsöka anslutningsfel för privat slutpunkt

Anslutningar till Azure SQL Database via en privat slutpunkt kan misslyckas med anslutningstidsgränser eller handskakningsfel under inloggning. Gå igenom följande steg i ordning. Varje steg löser ett distinkt felläge.

Steg 1: Verifiera den privata slutpunkten och DNS-matchningen

Bekräfta att den privata slutpunkten har etablerats och att DNS matchar den privata IP-adressen.

Steg 2: Lägg till en brandväggsregel på servernivå för din utgående IP-adress

Även med en privat slutpunkt tillämpar Azure SQL Database fortfarande IP-brandväggsregler på servernivå mot den käll-IP som gatewayen ser.

1. Identifiera din utgående IP-adress. För lokal trafik som dirigeras via en VPN-gateway eller ExpressRoute är den utgående IP-adressen vanligtvis gatewayen eller den privata NAT-IP-adressen i det virtuella nätverket. Inifrån Azure är det den virtuella datorns privata IP-adress eller en ip-adress för lastbalanserarens klientdel.

2. Lägg till en brandväggsregel på servernivå för ip-adressen eller undernätet:

   EXECUTE sp_set_firewall_rule
       @name = N'AllowPrivateEndpointSubnet',
       @start_ip_address = '10.0.1.0',
       @end_ip_address = '10.0.1.255';
   

Steg 3: Öppna rätt portar på gränsen eller lokala brandväggar

Vilka portar som krävs beror på anslutningsprincipen:

Om en anslutning lyckas inifrån det virtuella nätverket men misslyckas lokalt blockerar den lokala brandväggen sannolikt de högre portarna i 1433-65535 intervallet. Öppna portintervallet eller ändra serverns anslutningsprincip till Proxy. Mer information finns i Använda omdirigeringsanslutningsprincip med privata slutpunkter.

Steg 4: Verifiera symmetrisk routning för UDR-, NVA- och NAT-scenarier

Om trafik till den privata SQL-slutpunkten passerar genom en virtuell nätverksinstallation (NVA), Azure Firewall eller NAT-gateway måste returtrafiken följa samma sökväg. Asymmetrisk routing orsakar TCP-återställningar eller förlorade paket.

Viktiga fakta:

• Azure skapar en /32-systemväg för varje privat slutpunkts-IP (till exempel 10.0.1.4/32 med nästa hopptyp InterfaceEndpoints). En användardefinierad väg (UDR) kan bara åsidosätta den här systemvägen med ett lika stort eller mer specifikt prefix (ett annat /32).

• Om du dirigerar utgående trafik till en NVA måste NVA tillämpa källnätverksadressöversättning (SNAT) så att returpaketen kommer tillbaka till NVA i stället för att gå direkt till klienten. Utan SNAT är retursökvägen asymmetrisk.

• Nätverksprinciper för privata slutpunkter (NSG- och UDR-stöd i det privata slutpunktsundernätet) är inaktiverade som standard. Om du vill tillämpa NSG- eller UDR-regler på privat slutpunktstrafik aktiverar du nätverksprinciper i undernätet:

  az network vnet subnet update \
    --name <SubnetName> \
    --vnet-name <VNetName> \
    --resource-group <ResourceGroup> \
    --private-endpoint-network-policies Enabled
  

Om en anslutning fungerar utan en NVA men får tidsavbrott när den /32 dirigeras via en, skickar systemvägen returtrafik direkt till klienten och kringgår NVA-tillståndstabellen. Lägg till en /32 UDR för den privata slutpunkts-IP-adressen som pekar på NVA och aktivera SNAT på NVA.

Steg 5: Använd Network Watcher för att bekräfta anslutningen från slutpunkt till slutpunkt

Om föregående steg ser korrekta ut men anslutningarna fortfarande misslyckas använder du Azure Network Watcher för att isolera felet:

Snabbreferens

Fel vid avslutning av nätverksanslutning

SQL-klientbibliotek ansluter till Azure SQL Database och Azure SQL Managed Instance med hjälp av TCP-nätverksprotokollet. Ett klientbibliotek använder en komponent på lägre nivå som kallas TCP-provider för att hantera TCP-anslutningar. När TCP-providern upptäcker att en fjärrvärd oväntat avslutar en befintlig TCP-anslutning genererar klientbiblioteket ett fel. Eftersom felet är ett klientfel och inte ett SQL-serverfel ingår inget SQL-felnummer. I stället är felnumret 0 och felmeddelandet från TCP-providern används.

Exempel på fel vid avslutning av nätverksanslutningar är:

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) An existing connection was forcibly closed by the remote host

A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

The client was unable to establish a connection because of an error during connection initialization process before login. Possible causes include the following: the client tried to connect to an unsupported version of SQL Server; the server was too busy to accept new connections; or there was a resource limitation (insufficient memory or maximum allowed connections) on the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

A connection was successfully established with the server, but then an error occurred during the login process. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

Anslutningsavslutsfel kan inträffa eftersom databasen eller den elastiska poolen inte är tillgänglig för tillfället. De uppstår också på grund av olika problem i nätverksinfrastrukturen mellan databasservern och klientprogrammet, inklusive brandväggar, nätverksinstallationer osv. Dessa problem kan vara tillfälliga eller permanenta. Som allmän vägledning bör program använda ett fast antal återförsök för dessa fel innan de överväger permanenta fel.

Resursstyrningsfel

Azure SQL Database använder en implementering av resursstyrning baserat på Resource Governor för att framtvinga resursgränser. Läs mer om resurshantering i Azure SQL Database.

De vanligaste resursstyrningsfelen visas först med information, följt av en tabell med felmeddelanden om resursstyrning.

Felen 10928 och 10936: Resurs-ID: 1. Begärandegränsen för [databasen eller den elastiska poolen] är %d och har nåtts

Om gränsen på databasnivå har nåtts, lyder det detaljerade felmeddelandet i det här fallet: Resource ID : 1. The request limit for the database is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance.

Om gränsen för den elastiska poolen har nåtts läser det detaljerade felmeddelandet i det här fallet: Resource ID : 1. The request limit for the elastic pool is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance. Elastiska poolgränser är högre än databasgränserna. Mer information finns i Resurshantering i Azure SQL Database. Gränser kan uppstå när flera databaser i poolen använder en resurs (till exempel arbetare) samtidigt.

Det här felmeddelandet anger att arbetsgränsen för databasen eller den elastiska poolen har nåtts. Det maximala värdet för samtidigt aktiva arbetare för tjänstmålet för databasen eller den elastiska poolen kommer att visas i stället för platshållaren %d.

Anslut med den dedikerade administratörsanslutningen (DAC) om det behövs

Om en liveincident pågår där arbetsgränsen nås kan du få fel 10928 när du ansluter med SQL Server Management Studio (SSMS). En session kan ansluta med hjälp av diagnostikanslutningen för databasadministratörer (DAC) även när det maximala arbetströskelvärdet har uppnåtts.

Så här upprättar du en anslutning med DAC från SSMS:

• På menyn väljer du Fil > Ny > Fråga om databasmotor
• I dialogrutan Anslutning i fältet Servernamn anger du admin:<fully_qualified_server_name> (till exempel admin:servername.database.windows.net).
• Välj alternativ >>
• Välj fliken Anslutningsegenskaper
• I rutan Anslut till databas: skriver du namnet på databasen
• Välj Anslut.

Om du får fel 40613 Database '%.*ls' on server '%.*ls' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of '%.*ls'kan detta tyda på att en annan session redan är ansluten till DAC. Endast en session kan ansluta till DAC för en enskild databas eller en elastisk pool i taget.

Om du stöter på felet "Det gick inte att ansluta till servern" efter att du har valt Anslut kan DAC-sessionen fortfarande ha upprättats om du använder en version av SSMS-versioner före 18.9. Tidiga versioner av SSMS försökte erbjuda IntelliSense-stöd för anslutningar till DAC. Detta misslyckades eftersom DAC endast stöder en enskild arbetare och Intellisense kräver en separat arbetare.

Du kan inte använda en DAC-anslutning med Object Explorer i SSMS.

Granska användningen av din max_worker_percent

För att hitta resursförbrukningsstatistik för din databas under 14 dagar, fråga systemkatalogvyn sys.resource_stats. Kolumnen max_worker_percent visar procentandelen arbetare som används i förhållande till arbetsgränsen för databasen. Anslut till master databasen på den logiska servern för att fråga sys.resource_stats.

SELECT start_time, end_time, database_name, sku, avg_cpu_percent, max_worker_percent, max_session_percent 
FROM sys.resource_stats;

Du kan också fråga efter resursförbrukningsstatistik från den senaste timmen från vyn sys.dm_db_resource_stats dynamisk hantering. Anslut direkt till databasen för att fråga sys.dm_db_resource_stats.

SELECT end_time, avg_cpu_percent, max_worker_percent, max_session_percent
FROM sys.dm_db_resource_stats;

Lägre arbetsanvändning när det är möjligt

Blockeringskedjor kan orsaka en plötslig ökning av antalet arbetare i en databas. En stor mängd samtidiga parallella frågor kan orsaka ett stort antal arbetare. Om du ökar maxgraden av parallellitet (MAXDOP) eller ställer in MAXDOP till noll kan du öka antalet aktiva arbetare.

Sortera en incident med otillräckliga arbetare genom att följa dessa steg:

1. Undersök om blockering sker eller om du kan identifiera en stor mängd samtidiga arbetare. Kör följande fråga för att undersöka aktuella begäranden och kontrollera om det finns blockeringar när din databas returnerar fel 10928. Du kan behöva ansluta med den dedikerade administratörsanslutningen (DAC) för att köra frågan.

   SELECT
       r.session_id, r.request_id, r.blocking_session_id, r.start_time, 
       r.status, r.command, DB_NAME(r.database_id) AS database_name,
       (SELECT COUNT(*) 
           FROM sys.dm_os_tasks AS t 
           WHERE t.session_id=r.session_id and t.request_id=r.request_id) AS worker_count,
       i.parameters, i.event_info AS input_buffer,
       r.last_wait_type, r.open_transaction_count, r.total_elapsed_time, r.cpu_time,
       r.logical_reads, r.writes, s.login_time, s.login_name, s.program_name, s.host_name
   FROM sys.dm_exec_requests as r
   JOIN sys.dm_exec_sessions as s on r.session_id=s.session_id
   OUTER APPLY sys.dm_exec_input_buffer (r.session_id,r.request_id) AS i
   WHERE s.is_user_process=1;
   GO
   

   1. Leta efter rader med en blocking_session_id för att identifiera blockerade sessioner. Hitta var och en blocking_session_id i listan för att avgöra om sessionen också är blockerad. Om du följer blocking_session_id och session_id-värdena så kommer du så småningom att ledas till huvudblockeraren: en session som inte är blockerad men som blockerar. Justera huvudblockeringsfrågeinställningarna.

      Tips/Råd

      Mer detaljerad information om hur du felsöker tidskrävande eller blockerande frågor finns i Förstå och lösa blockeringsproblem.

   2. Om du vill identifiera en stor mängd samtidiga arbetare granskar du antalet förfrågningar överlag och worker_count kolumnen för varje begäran. Worker_count är antalet arbetare vid den tidpunkt som samplas och kan ändras över tid när begäran körs. Justera frågor för att minska resursanvändningen om orsaken till ökad personal är samtidiga frågor som körs i optimal grad av parallellitet. Mer information finns i Query Tuning/Hinting.

2. Utvärdera maxgränsen för parallellitet (MAXDOP) för databasen.

Öka arbetsgränser

Om databasen eller den elastiska poolen konsekvent når sin arbetsgräns trots att den hanterar blockering, optimering av frågor och validering av MAXDOP-inställningen kan du överväga att skala upp databasen eller den elastiska poolen för att öka arbetsgränsen.

Hitta resursgränser för Azure SQL Database efter tjänstnivå och beräkningsstorlek:

• Resursbegränsningar för enskilda databaser med hjälp av vCore-inköpsmodellen
• Resursbegränsningar för elastiska pooler med hjälp av vCore-inköpsmodellen
• Resursgränser för enskilda databaser med hjälp av DTU-inköpsmodellen
• Resursbegränsningar för elastiska pooler med hjälp av DTU-köpmodellen

Läs mer om resursstyrning i Azure SQL Database för arbetare.

Fel 10929: Resurs-ID: 1

10929: Resource ID: 1. The %s minimum guarantee is %d, maximum limit is %d and the current usage for the database is %d. However, the server is currently too busy to support requests greater than %d for this database. See http://go.microsoft.com/fwlink/?LinkId=267637 for assistance. Otherwise, please try again later.

Fel 40501: Tjänsten är upptagen för närvarande

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: %ls. Code: %d.

Fel 40501 är ett motorbegränsningsfel, en indikation på att resursgränserna överskrids.

Mer information om resursbegränsningar finns i Resurshantering i Azure SQL Database.

Fel 40544: Databasen har nått sin storlekskvot

40544: The database has reached its size quota. Partition or delete data, drop indexes, or consult the documentation for possible resolutions. Incident ID: <ID>. Code: <code>.

Det här felet uppstår när databasen har nått sin storlekskvot.

Följande steg kan antingen hjälpa dig att lösa problemet eller ge dig fler alternativ:

1. Kontrollera databasens aktuella storlek med hjälp av instrumentpanelen i Azure-portalen.

   Anmärkning

   Om du vill identifiera vilka tabeller som förbrukar mest utrymme och därför är potentiella kandidater för rensning kör du följande SQL-fråga:

   SELECT o.name,
    SUM(p.row_count) AS 'Row Count',
    SUM(p.reserved_page_count) * 8.0 / 1024 AS 'Table Size (MB)'
   FROM sys.objects o
   JOIN sys.dm_db_partition_stats p on p.object_id = o.object_id
   GROUP BY o.name
   ORDER BY [Table Size (MB)] DESC;
   GO
   

2. Om den aktuella storleken inte överskrider den maximala storlek som stöds för din utgåva kan du använda ALTER DATABASE för att öka MAXSIZE-inställningen.

3. Om databasen redan har passerat den maximala storlek som stöds för din utgåva kan du prova ett eller flera av följande steg:

   • Utför normala databasrensningsaktiviteter. Du kan till exempel rensa oönskade data med hjälp av trunkering/ta bort eller exportera data med služba SSIS (SSIS) eller bulkkopieringsverktyget (bcp).
   • Partitionera eller ta bort data, ta bort index eller se i dokumentationen för möjliga lösningar.
   • Information om databasskalning finns i Skala resurser för en enskild databas och Skala elastiska poolresurser.

Fel 40549: Sessionen avslutas eftersom du har en tidskrävande transaktion

40549: Session is terminated because you have a long-running transaction. Try shortening your transaction.

Om det här felet uppstår upprepade gånger kan du försöka lösa problemet genom att följa dessa steg:

1. Kör följande fråga för att se alla öppna sessioner som har ett högt värde för duration_ms kolumnen:

   SELECT
       r.start_time, DATEDIFF(ms,start_time, SYSDATETIME()) as duration_ms, 
       r.session_id, r.request_id, r.blocking_session_id,  
       r.status, r.command, DB_NAME(r.database_id) AS database_name,
       i.parameters, i.event_info AS input_buffer,
       r.last_wait_type, r.open_transaction_count, r.total_elapsed_time, r.cpu_time,
       r.logical_reads, r.writes, s.login_time, s.login_name, s.program_name, s.host_name
   FROM sys.dm_exec_requests as r
   JOIN sys.dm_exec_sessions as s on r.session_id=s.session_id
   OUTER APPLY sys.dm_exec_input_buffer (r.session_id,r.request_id) AS i
   WHERE s.is_user_process=1
   ORDER BY start_time ASC;
   GO
   

   Du kan ignorera rader där input_buffer kolumnen visar en fråga som läser från sys.fn_MSxe_read_event_stream: dessa begäranden är relaterade till utökade händelsesessioner.

2. blocking_session_id Granska kolumnen för att se om blockering bidrar till långvariga transaktioner.

   Anmärkning

   Mer information om felsökning av blockering i Azure SQL Database finns i Förstå och lösa blockeringsproblem.

3. Överväg att gruppera dina frågor. Information om batchbearbetning finns i Använda batchbearbetning för att förbättra prestanda för Azure SQL Database- och Azure SQL Managed Instance-program.

Fel 40551: Sessionen har avslutats på grund av överdriven tempdb-användning

40551: The session has been terminated because of excessive TEMPDB usage. Try modifying your query to reduce the temporary table space usage.

För att kringgå det här problemet, följ dessa steg:

1. Ändra frågorna för att minska den tillfälliga användningen av tabellutrymme.
2. Släpp temporära objekt när de inte längre behövs.
3. Trunkera tabeller eller ta bort tabeller som inte används.

Fel 40552: Sessionen har avslutats på grund av överdriven användning av transaktionsloggutrymme

40552: The session has been terminated because of excessive transaction log space usage. Try modifying fewer rows in a single transaction.

Prova att lösa problemet med hjälp av följande metoder:

• Problemet kan inträffa på grund av åtgärder för att infoga, uppdatera eller ta bort. Försök att minska antalet rader som bearbetas direkt genom att implementera batchprocessning eller dela upp i flera mindre transaktioner.
• Problemet kan uppstå på grund av åtgärder för att återskapa index. Om du vill undvika det här problemet kontrollerar du antalet rader som påverkas i tabellen * (genomsnittlig storlek på fältet som uppdateras i byte + 80) < 2 gigabyte (GB).
• För ett återskapande av index bör den genomsnittliga storleken på fältet som uppdateras ersättas med den genomsnittliga indexstorleken.
• Mer information finns i Felsöka en fullständig transaktionslogg i Azure SQL Database och Felsöka en fullständig transaktionslogg i Azure SQL Managed Instance.

Fel 40553: Sessionen har avslutats på grund av överdriven minnesanvändning

40553: The session has been terminated because of excessive memory usage. Try modifying your query to process fewer rows.

Försök att optimera frågan för att undvika det här problemet.

En djupgående felsökningsprocedur finns i Fungerar min fråga bra i molnet?

Mer information om andra minnesfel och exempelfrågor finns i Felsöka minnesfel med Azure SQL Database.

Tabell med felmeddelanden för resursstyrning

Fel i elastisk pool

Följande fel är relaterade till att skapa och använda elastiska pooler.

Det går inte att öppna databasen "master" som begärdes vid inloggningen. Inloggningen misslyckades

Det här problemet beror på att kontot inte har behörighet att komma åt master databasen. Men som standard försöker SQL Server Management Studio (SSMS) ansluta till master databasen.

Följ dessa anvisningar för att lösa problemet:

1. På inloggningsskärmen i SSMS väljer du Alternativ och sedan Anslutningsegenskaper.

2. I fältet Anslut till databas anger du användarens standarddatabasnamn som standardinloggningsdatabas och väljer sedan Anslut.

   

Skrivskyddade fel

Om du försöker skriva till en databas som är skrivskyddad, så får du ett felmeddelande. I vissa fall kanske orsaken till databasens skrivskyddade status inte är omedelbart tydlig.

Fel 3906: Det gick inte att uppdatera databasen 'databaseName' eftersom databasen är skrivskyddad.

När du försöker ändra en skrivskyddad databas utlöses följande fel.

Msg 3906, Level 16, State 2, Line 1
Failed to update database "%d" because the database is read-only.

Det finns flera möjliga förklaringar till varför en databas är skrivskyddad.

Efter en manuell redundansväxling ansluter programmen fortfarande till den gamla repliken

Efter en redundansväxling till en annan replik i Azure SQL Database kanske programmet fortfarande ansluter till den tidigare primära repliken på grund av DNS. Routning av failoverklusteranslutning utförs med DNS.

Potentiella rotorsaker:

1. Under redundansväxlingen uppdateras slutpunkterna för redundansgrupper så att de pekar på lämpliga nya primära och nya sekundära servrar genom att ändra målet för lämplig DNS-post. Som standard skapas DNS-poster med en TTL på 30 sekunder, vilket innebär att DNS-klienter cachelagrade dessa poster i 30 sekunder. Därför sprids inte uppdateringar av DNS-posterna omedelbart. poster blir inaktuella tills alla klienter och mellanliggande noder har uppdaterat sina cacheminnen. Det kan därför ta allt från 0 till cirka 10 minuter (beroende på nätverkstopologi) innan inloggningar till slutpunkter för redundansgrupper dirigeras till sina nya mål efter en redundansväxling. Tömning av DNS-cacheminnen kanske eller kanske inte hjälper problemet, eftersom mellanliggande nätverksnoder som svarar på DNS-begäranden även cachelagrar DNS-resultat under en tid.

   Den rekommenderade lösningen för det här problemet är att bara vänta tills DNS-posterna uppdateras på klienten. För närvarande skulle den här lösningen leda till att problemet löser sig inom 10 minuter.

2. Vissa SQL-klientbibliotek använder en funktion som kallas "anslutningspooler" som återanvänder anslutningar till samma datakälla i stället för att stänga och öppna dem igen när en ny databasanslutning behövs. I synnerhet är anslutningspooler aktiverade i ADO.NET som standard. När det kombineras när problemet beskrivs i 1 kan anslutningspooler orsaka att nyligen öppnade anslutningar återanvänder en anslutning till den gamla databasen, vilket förhindrar att programmet ansluter till den nya primära databasen på obestämd tid.

Lösningar:

Det finns tre möjliga lösningar på det här DNS-problemet efter en failover av en redundansgrupp:

1. Ändra programmet så att det anropar SQLConnection.ClearAllPools eller SQLConnection.ClearPool(conn) när ett läs-skyddat fel påträffas.
2. I programanslutningssträngen anger du Pooling=False för att inaktivera anslutningspooler. Detta bör testas eftersom det kan påverka prestanda avsevärt om programmet öppnas och stänger anslutningar ofta.
3. Ett annat alternativ för att undvika fördröjningar i DNS-replikering eller cachelagring är att ansluta direkt med det logiska servernamnet för Azure SQL Database (från den ursprungliga sekundära servern, som nu är den nya primära) under en viss tidsperiod efter att fel 3906 har påträffats.

Du kanske är ansluten till en skrivskyddad databasreplika

För både Azure SQL Database och Azure SQL Managed Instance kan det hända att du är ansluten till en databas på en skrivskyddad replik. I det här fallet returnerar följande fråga med READ_ONLY :

SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability');
GO

Om du ansluter med SQL Server Management Studio kontrollerar du om du har angett ApplicationIntent=ReadOnly på fliken Ytterligare anslutningsparametrari anslutningsalternativen.

Om anslutningen kommer från ett program eller en klient som använder en anslutningssträng kontrollerar du om anslutningssträngen har angett ApplicationIntent=ReadOnly. Läs mer i Anslut till en skrivskyddad replik.

Databasen kan vara inställd på skrivskyddat läge

Om du använder Azure SQL Database kan själva databasen ha angetts till skrivskyddad. Du kan kontrollera databasens status med följande fråga:

SELECT name, is_read_only
FROM sys.databases
WHERE database_id = DB_ID();

Du kan ändra skrivskyddad status för en databas i Azure SQL Database genom ALTER DATABASE Transact-SQL. Du kan för närvarande inte ställa in en databas i en hanterad instans till skrivskyddad.

Bekräfta om ett fel orsakas av ett anslutningsproblem

Kontrollera om ett fel orsakas av ett anslutningsproblem genom att granska stackspårningen för bildrutor som visar anrop för att öppna en anslutning som följande (observera referensen till klassen SqlConnection ):

System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
 at System.Data.SqlClient.SqlConnection.Open()
 at AzureConnectionTest.Program.Main(String[] args)
ClientConnectionId:<Client connection ID>

När undantaget utlöses av frågeproblem ser du en anropsstack som liknar följande (observera referensen till klassen SqlCommand ). I den här situationen optimerar du dina sökfrågor.

  at System.Data.SqlClient.SqlCommand.ExecuteReader()
  at AzureConnectionTest.Program.Main(String[] args)
  ClientConnectionId:<Client ID>

Mer information om finjusteringsprestanda finns i:

• Så här underhåller du Azure SQL-index och statistik
• Finjustera program och databaser för prestanda i Azure SQL Database
• Övervaka prestanda med dynamiska hanteringsvyer
• Använda Query Store i Azure SQL Database

Relaterat innehåll

• Anslutningsarkitektur
• Azure SQL Database- och Azure Synapse Analytics-nätverksåtkomstkontroller
• Felsöka en fullständig transaktionslogg i Azure SQL Database
• Felsöka en fullständig transaktionslogg i Azure SQL Managed Instance
• Felsöka tillfälliga anslutningsfel
• Analysera och förhindra dödlägen i Azure SQL Database och Fabric SQL Database