Dela via

Samla in data för att felsöka anslutningsproblem med SQL Server

  • Artikel

Den här artikeln hjälper dig att identifiera rotorsaken till anslutningsproblem med SQL Server genom att ställa relevanta frågor baserat på specifika kategorier. Även om artikeln Rekommenderade krav och checklista för felsökning av ANSLUTNINGsproblem med SQL Server innehåller de viktigaste objekten som ska samlas in, kan frågorna i den här artikeln hjälpa dig att begränsa orsaken till anslutningsproblemen och felsöka dem effektivt.

Kommentar

Alla frågor gäller inte för alla problem. De här frågorna kan dock hjälpa dig att felsöka anslutningsproblem.

Med hjälp av informationen i den här artikeln kan du se Översikt över konsekventa autentiseringsproblem i SQL Server för typen av fel när du kan nollställa problemets exakta karaktär.

Metod för att samla in data

Om du vill samla in data kan du använda verktyg som PSR (Problem Steps Recorder), Nätverksspårning och NETLOGON-spårning. Det här avsnittet innehåller detaljerade steg för att installera och konfigurera en kombination av alla dessa verktyg.

Följ dessa steg samtidigt på både klient- och serverdatorerna. Om programmet är en arkitektur på 3 nivåer eller n-nivå kör du även installationen på mellanliggande servrar.

  1. Installera WireShark på alla berörda datorer eller använd det inbyggda NETSH kommandot (Windows 2008 eller senare versioner). Ingen omstart krävs.

  2. Aktivera NETLOGON-felsökningsloggning på klienten och alla servrar genom att köra följande kommando:

    NLTEST /DBFLAG:2080FFFF

  3. Gör om möjligt något av följande steg:

    • Starta om klientdatorn.
    • Be användaren att logga ut och logga in igen.
    • Stäng och öppna klientprogrammet igen.

  4. Starta Problem steps Recorder (psr.exe) på klientdatorn och välj sedan Starta post.

    Det här verktyget samlar in alla användaråtgärder som föregår problemet och sparar resultatet i en .zip fil.

  5. Starta nätverksinsamlingen på alla datorer.

  6. Om du använder NETSH kör NETSH TRACE START CAPTURE=YES TRACEFILE=C:\TEMP%computername%.ETL du kommandot (använd ett lämpligt fil- eller sökvägsnamn).

  7. Rensa DNS-cachen (Domain Name System) på alla datorer genom att IPCONFIG /FLUSHDNS köra kommandot .

  8. Rensa NETBIOS-cachen på alla datorer genom att NBTSTAT /RR köra kommandot .

  9. Rensa klientens Kerberos-biljetter genom att KLIST purge köra kommandot .

  10. Rensa biljetter på varje server genom att KLIST -li 0x3e7 purge köra kommandot .

    Kommentar

    Skriv kommandot . Kopiera inte och klistra in på kommandoraden eftersom bindestrecket kan konverteras till ett långt (em) bindestreck. KLIST är skiftlägeskänsligt.

  11. Återskapa problemet.

  12. Stoppa inspelningen av psr.exe .

  13. Stoppa nätverksinsamlingarna. Spara den inspelade filen genom att köra kommandot NETSH: NETSH TRACE STOP med hjälp av ett beskrivande namn. Namnet på filen kan till exempel vara SQLProd01.netmon.cap.

  14. Vänta tills kommandotolken visas igen och stäng sedan fönstret. Stäng inte kommandotolken innan kommandotolken visas.

  15. Kopiera NETLOGON-loggen till C:\windows\debug\netlogon.log och ge filen ett beskrivande namn. Till exempel SQLProd01.netlogon.log.

  16. Inaktivera loggning genom att NLTEST /DBFLAG:0x0 köra kommandot .

Samla in data för att kategorisera problemen

Följande uppsättning frågor är utformade för att hjälpa dig att hitta den kategori som ett problem faller i, vilket vägleder dig mot rätt riktning för felsökning. Välj varje listruta för relaterade frågor.

Innan du går in på de specifika frågorna kontrollerar du att alla krav som krävs för SQL Server-anslutningarna har uppfyllts. Mer information om förutsättningarna finns i Rekommenderade krav och checklista för felsökning av anslutningsproblem med SQL Server.

Frågor om bredare perspektiv
  • Påverkar problemet endast databasanslutningar, eller påverkar det även webb- och filresursanslutningar? Många fall rapporteras till SQL Server-teamet eftersom de inträffar på databasservern. Det kan dock vara möjligt att problemet inte är relaterat till databasen alls och kan kräva mer allmänt Stöd för Windows eller Active Directory.
  • Finns det en förtroenderelation mellan användardomänen, klientdomänen eller serverdomänen om de är olika? Är det externt, skog, enkelriktad, dubbelriktad eller ingen?
  • Fungerar anslutningen korrekt om alla resurser finns i samma domän?
  • Är problemet tillfälligt eller periodiskt eller är det konsekvent?
  • Uppstår problemet bara om fler än en användare använder programmet? Inträffar det oftare om fler användare använder det?
  • Uppstår problemet bara vid vissa tidpunkter på dagen eller vissa dagar i veckan?
  • Uppstår problemet bara när en säkerhetskopia görs eller om databasen indexeras om?
  • Påverkar problemet fler än en server?
  • Påverkar problemet bara en nod i ett n-nodkluster? Om ja, kan det vara mer effektivt att överväga att återskapa den specifika noden.
  • Påverkar problemet bara en eller två klienter av flera? Om ja, kanske återuppbyggnad skulle vara mer effektivt.
  • Påverkar problemet endast namngivna pipes och inte TCP (eller vice versa)?
  • Uppstår problemet när du använder en SQL Server-inloggning och TCP/IP?
  • Finns det ett arbetsfall som kan jämföras med det misslyckade fallet? Hur skiljer sig systemen åt?
Klientdator

Använd följande frågor för att samla in data om de olika komponenterna på klientdatorn. Dessa data kan vara användbara för att identifiera problemen.

  • Vad är operativsystemets namn, version och version (WinVer)?

  • Vad är namnet och versionen av SQL Server-drivrutinen eller -providern?

  • Vad är datornamnet och IP-adressen?

  • Vad är datorns domänstatus? Vad är domännamnet om det är anslutet till en domän?

  • Vilken programkörningsmiljö används? Till exempel Internet Information Services (IIS), Windows Forms, Web Sphere eller SQL Server Integration Services -jobb (SSIS).

  • Vilket programspråk används?

  • Vad används anslutningssträng?

  • Vilken typ av autentisering används för att ansluta till servern? Till exempel New Technology LAN Manager (NTLM), Kerberos, SQL eller Azure Active Directory (AAD).

  • Delegerar programmet användarautentiseringsuppgifter till serverdelsdatabasen om programmet är en server eller tjänst?

  • Används begränsad delegering?

  • Vad är programtjänstkontot och domänen?

  • Vilken typ av tjänst används? Är det fysiskt, virtuellt eller moln? Till exempel IaaS, Webbapp, Webbroll eller Power BI.

  • Vad är klientdrivrutinen? Är det Java Database Connectivity (JDBC) eller körs det på Linux eller Mac?

    Kommentar

    Arbetsflödena är för närvarande mer Windows-orienterade.

  • Påverkar problemet endast äldre leverantörer, till exempel Provider=SQLOLEBD eller Driver={SQL Server}, och inte SQL Native Client och senare drivrutiner (eller vice versa)?

  • Uppstår problemet bara i ett program eller i flera program?

  • Misslyckas en UDL-fil (Universal Data Link) när den försöker ansluta till andra SQL Server-baserade servrar, eller misslyckas den bara med den server som har problemet?

  • Loggar användaren in på den SQL Server-baserade servern och försöker ansluta med hjälp av SQL Server Management Studio (SSMS)?

  • Uppstår problemet bara när du använder NETBIOS-namnet på servern och inte när du använder det fullständigt kvalificerade domännamnet (FQDN) (eller vice versa)? Fungerar det med hjälp av IP-adressen?

  • Har klienten som kör Windows 10 Enterprise Edition funktionen Credential Guard aktiverad? Om ja, kan detta påverka fullständiga delegeringsscenarier.

Logginformation

Använd följande frågor för att samla in data om loggfilerna:

  • Vad är det exakta felmeddelandet i anropsstacken?
  • Samlades loggen in från FILERNA SQL Server ERRORLOG och ERRORLOG.1 ?
  • Samlades programhändelseloggarna in från klienten och servern?
  • Samlades klientprogrammets loggfiler och konfigurationsfiler in? Till exempel web.config, rsreportserver.config, *.config eller *.ini.
  • Finns det en tillgänglig visuell representation av nätverket som visar datorer, routrar och så vidare?
Nya eller befintliga problem

Avser att avgöra om problemet är en ny utveckling eller om det har bevarats ett tag:

  • Har problemet alltid funnits (ny installation) eller fungerade programmet korrekt under en tid innan det nyligen bröts?
  • Vilka ändringar gjordes i miljön om programmet fungerade korrekt? Till exempel installerade uppdateringar, uppgraderade domänkontrollanter, ändringar i brandväggsinställningarna, inaktiverade domänkontrollanter eller en flytt till en annan organisationsenhet i domänen.
Serverdator

För en länkad server samlar du in serverinformation för både mellannivåservern och serverdelsservern. För ett problem med IIS-till-SQL-delegering samlar du in information på webbservern, inklusive inställningarna web.config och autentisering.

  • Vad är namnet på operativsystemets namn, version och version (Winver)?
  • Vad är namnet och versionen av databasen?
  • Vad heter datorn?
  • Vad är IP-adressen?
  • Vad är domännamnet om datorn är domänansluten?
  • Vad är SQL Server-tjänstkontot och domänen?
  • Vad är namnet på SQL Server-instansen?
  • Vilka protokoll är aktiverade?
  • Vilken port lyssnar servern på?
  • Vad är namnet på serverpipan? Du hittar den här informationen i felloggen.
  • Vilken typ av miljö används? Är det fysiskt, virtuellt eller moln? Till exempel IaaS (SQL på en virtuell Azure-dator (VM)) eller PaaS (Azure SQL Database, SQL Managed Instance (MI)).
  • Distribueras databasen som fristående, klustrad, speglad eller med Always On?
  • Vad är redundanspartnerns namn och IP-adress?
  • Vad är namnet på det virtuella klustret eller lyssnarnamnet och porten?
  • Vilken är den virtuella IP-adressen eller lyssnarens IP-adress?
  • Vilket operativsystem är databasen installerad på? Är det Windows, Linux eller Mac? Detta kan påverka datainsamlingen.
  • Vilken är databasens plats? Är det i Azure?
  • Vilken är serverns aktuella status när det gäller den senaste Service Pack- och kumulativa uppdateringen? Det är ingen idé att felsöka ett problem som redan har åtgärdats.
  • Har SQL Server nyligen uppgraderats för att stödja TLS (Transport Layer Security) 1.2? Uppdaterades klienterna också? Har TLS 1.0 inaktiverats?
  • Vilken är den aktuella statusen för SQL Server-tjänsten? Körs den?
  • Vad är statusen för SQL Browser-tjänsten? Körs den?
  • Vad är problemets specificitet för ett tjänstkonto? Löser det problemet att köra servern med ett annat tjänstkonto?
Användarinformation

Samla in följande användarinformation:

  • Loggar användaren in på klientdatorn direkt eller kommer den åt den via fjärranslutning? Använder användaren till exempel en webbläsare?
  • Är användaren en tjänst, till exempel SQL Agent? Används processidentiteten eller används en lagrad autentiseringsuppgift?
  • Vilken typ av autentisering används för att ansluta till klientprogrammet? Är det Windows, Forms-autentisering eller AAD?
  • Ansluter användaren till servern med integrerad säkerhet?
  • Vad är användarnamnet och domännamnet?

Om användaren är fjärransluten till klientprogrammet samlar du in följande information:

  • Vad är datornamnet och IP-adressen?
  • Är datorn domänansluten? Om ja, vad är domännamnet?
  • Ansluter användaren via ett VPN eller en proxyserver? Uppstår problemet om någon av metoderna är direkt anslutna?
  • Är servern lastbalanserad om användaren ansluter till en webbserver?
  • Används klibbiga sessioner eller sessionstillhörighet?
  • Loggar användaren in på en terminalserver eller jump box och kommer åt programmet?
  • Påverkar problemet endast användare i vissa organisationsenheter ??
  • Har användaren, klienten eller servern flyttats till en annan organisationsenhet (OU) i Active Directory?
  • Påverkar problemet endast icke-administrativa användare?
  • Påverkar problemet alla eller bara vissa användare i en viss domän?

Se även

Ansvarsfriskrivning för information från tredje part

De produkter från andra tillverkare som diskuteras i denna artikel tillverkas oberoende av Microsoft. Produkternas funktion eller tillförlitlighet kan därför inte garanteras.