Felsök mssql-django

Diagnostisera och lösa vanliga problem med mssql-django serverdelen för SQL Server, Azure SQL Database, Azure SQL Managed Instance och SQL-databas i Microsoft Fabric.

mssql-django 2.0 stöder standardsökvägen för pyodbc-drivrutinen och en valbar drivrutinssökväg för mssql-python. För mer information, se Välj databasdrivrutinen för mssql-django.

Anslutningsproblem

Det här avsnittet beskriver de vanligaste anslutningsfelen och hur du löser dem.

ODBC-drivrutinen hittades inte i sökvägen för pyodbc

Symtom:

django.core.exceptions.ImproperlyConfigured: 'ODBC Driver 18 for SQL Server' is not a recognized ODBC driver

Or:

Error: ('01000', "[01000] [unixODBC][Driver Manager]Can't open lib 'ODBC Driver 18 for SQL Server'")

Möjliga orsaker och lösningar:

• ODBC-drivrutinen är inte installerad

  Installera Microsoft ODBC-drivrutinen för SQL Server när du använder standardvägen pyodbc. Nedladdningslänkar finns i Ladda ned ODBC-drivrutin för SQL Server. MSSQL-python-sökvägen använder inte en externt installerad ODBC-drivrutin.

• Flera installerade drivrutinsversioner

  Ange det exakta drivrutinsnamnet eller sökvägen i settings.py:

  DATABASES = {
      "default": {
          "ENGINE": "mssql",
          "NAME": "<database>",
          "USER": "<user_id>",
          "PASSWORD": "<password>",
          "HOST": "<server>",
          "PORT": "1433",
          "OPTIONS": {
              "driver": "ODBC Driver 17 for SQL Server",
          },
      },
  }
  

  I Linux anger du den fullständiga sökvägen:

  "OPTIONS": {
      "driver": "/opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.10.so.6.1",
  },
  

• Kontrollera installerade drivrutiner

  • På Linux/macOS kör du odbcinst -q -d.
  • På Windows kontrollerar du ODBC-datakällor i Administrationsverktyg.

mssql-python avvisar ett anslutningsalternativ

Symtom:

Ett alias som sätter "python_driver": "mssql_python" misslyckas under anslutningsuppbyggnaden efter att du flyttat pyodbc-anslutningssträngsnyckelord till OPTIONS["extra_params"], med ett av dessa fel:

mssql_python.exceptions.ConnectionStringParseError: Connection string parsing failed:
  Unknown keyword 'longasmax' is not recognized

mssql_python.exceptions.ConnectionStringParseError: Connection string parsing failed:
  Reserved keyword 'driver' is controlled by the driver and cannot be specified by the user

Nyckelordsnamnet i meddelandet skrivs med gemener, så ett nyckelord som du skrev som LongAsMax visas då som longasmax. ConnectionStringParseError är inte en del av DB-API undantagshierarkin, så Django omlindar det inte som ett django.db.utils fel.

Möjliga orsaker och lösningar:

• Endast pyodbc-nyckelord i extra_params

  Sökvägen för mssql-python validerar extra_params mot en lista över tillåtna värden. DRIVER och APP reserveras för föraren och visar formuläret Reserved keyword . DSN, SERVERNAME, LongAsMax och nyckelord som endast gäller för pyodbc, såsom ColumnEncryption, WSID, AnsiNPW, QuotedId, Regional, Current Language, UseFMTONLY, Description, Network Library, Connect Timeout och Unknown keyword, finns inte i tillåtelselistan och ger formen MARS_Connection. Ta bort nyckelordet, eller använd standardvägen pyodbc för ett alias som behöver det ODBC-alternativet.

• Drivrutinsalternativ förväntas styra mssql-python

  Sökvägen mssql-python ignorerar driver, dsn, host_is_server och unicode_results. HOST och PORT blir SERVER=<server>,<port>, och ett tomrum HOST blir localhost.

MSSQL-Python-beroendet är för gammalt

Symtom:

Ett alias som sätter "python_driver": "mssql_python" misslyckas vid anslutningsuppbyggnad med ett av dessa fel:

django.core.exceptions.ImproperlyConfigured: mssql-python 1.15.0 or newer is required; you have 1.14.0

django.core.exceptions.ImproperlyConfigured: The 'python_driver' connection option requests mssql-python, but the module could not be imported: No module named 'mssql_python'. Install it with 'pip install "mssql-python>=1.15.0"'.

Den andra formen innebär att modulen mssql_python inte alls är importerbar.

Lösning: Installera mssql-python>=1.15.0. mssql-django 2.0 deklarerar mssql-python>=1.15.0, så en normal pip install mssql-django löser en kompatibel version på stödda plattformar.

Driver 17s reservlösning är inte tillämplig på mssql-python

Symtom:

Ett alias som sätter "python_driver": "mssql_python" misslyckas ändå även om Microsoft ODBC Driver 17 för SQL Server är installerat.

Det finns inget tydligt fel i detta fall. Sökvägen för mssql-python ignorerar alternativet driver utan att ge något meddelande, så anslutningen misslyckas med det underliggande fel som uppstår. Om du flyttade drivrutinsnamnet istället extra_params får du ett Reserved keyword 'driver' felmeddelande. Se mssql-python avvisar ett anslutningsalternativ.

Lösning: Använd standardvägen för pyodbc om aliaset måste använda en externt installerad ODBC-drivrutin 17. Sökvägen för mssql-python återgår inte till drivrutin 17 och ignorerar alternativet driver. Den vägen behöver inte en separat installerad ODBC-drivrutin.

Anslutningen nekades

Symtom:

django.db.utils.OperationalError: ('08001', '[08001] ... TCP Provider: Error code 0x2749 ...')

Möjliga orsaker och lösningar:

• TCP/IP är inte aktiverat på SQL Server

  • Öppna Konfigurationshanteraren för SQL Server.
  • Under SQL Server Nätverkskonfiguration aktiverar du TCP/IP.
  • I TCP/IP-egenskaper aktiverar du DEN IP-adress som används för anslutningen.
  • Starta om SQL Server-tjänsten.

• Brandvägg som blockerar port 1433

  • Kontrollera att brandväggsregler tillåter inkommande anslutningar på port 1433.
  • För Azure SQL lägger du till din klient-IP i brandväggsinställningarna för Azure portalen.

• Fel servernamn eller port

  Kontrollera värdena för HOST och PORT i konfigurationen.

Inloggningen misslyckades

Symtom:

django.db.utils.OperationalError: ('28000', "[28000] [Microsoft][ODBC Driver 18 for SQL Server][SQL Server]Login failed for user '<user_id>'. (18456) (SQLDriverConnect); [28000] [Microsoft][ODBC Driver 18 for SQL Server][SQL Server]Login failed for user '<user_id>'. (18456)")

På mssql-python-vägen:

django.db.utils.OperationalError: Driver Error: Invalid authorization specification; DDBC Error: [Microsoft][SQL Server]Login failed for user '<user_id>'.

Möjliga orsaker och lösningar:

• Felaktiga autentiseringsuppgifter

  Verifiera användarnamnet och lösenordet.

• Databasen i NAME existerar inte

  På SQL Server visar mssql-python-vägen samma OperationalError signal med samma meddelande som ett dåligt lösenord, så meddelandet i sig säger inte vilket du träffar. Bekräfta att databasen finns innan du ändrar inloggningsuppgifterna. Peka NAME mot master för att testa inloggningen för sig: om det fungerar är inloggningsuppgifterna korrekta och problemet ligger i databasen. pyodbc-sökvägen rapporterar det här fallet separat som Cannot open database "<database>" requested by the login. The login failed. (4060).

  Azure SQL Database rapporterar detta fall annorlunda. mssql-python-sökvägen utlöser Driver Error: General error; DDBC Error: [Microsoft][SQL Server]Cannot open server "<server>" requested by the login. The login failed. Meddelandet anger servernamnet, men servernamnet är korrekt. Kolla NAME istället.

• Användaren finns inte

  Bekräfta att inloggningen har mappats till en användare i måldatabasen.

• SQL Server autentisering inaktiverad

  Aktivera autentisering i blandat läge eller använd Windows eller Microsoft Entra autentisering.

Tidsgräns för anslutning

Symtom:

django.db.utils.OperationalError: ('HYT00', '[HYT00] [Microsoft][ODBC Driver 18 for SQL Server]Login timeout expired')

Möjliga orsaker och lösningar:

• Nätverksfördröjning

  Öka connection_timeout i ALTERNATIV.

• Azure SQL Database serverless med auto-pause aktiverat

  En automatiskt pausad databas återupptas vid första anslutningsförsöket, och det försöket kan misslyckas med fel 40613 medan databasen återupptas. Ställ connection_timeout in på minst 60 och försök igen vid första anslutningen. För mer information, se Azure SQL Database serverless och Automatisk paus och automatisk återupptagning.

• Servern är överbelastad

  Öka connection_retries och connection_retry_backoff_time.

  "OPTIONS": {
      "driver": "ODBC Driver 18 for SQL Server",
      "connection_timeout": 30,
      "connection_retries": 5,
      "connection_retry_backoff_time": 10,
  },
  

Migreringsproblem

Dessa fel uppstår under Django-migreringsåtgärder mot SQL Server.

Råa SQL- och GROUP BY-problem

Dessa fel uppstår när råa eller annoterade frågor med en GROUP BY klausul passerar backends platshållaromskrivningssteg.

IndexError med GROUP BY med escapade %% och riktiga parametrar

Symtom:

IndexError: Replacement index N out of range for positional args tuple

Frågan fungerar utan klausulen GROUP BY och fungerar utan den undkomna %% literalen, men misslyckas när båda finns tillsammans med en reell %s parameter.

Lösning: Uppgradera till en nuvarande mssql-django version. Backend begränsar regex för omskrivning av platshållare till %% och %s endast så att undkomna %% literals bevaras ordagrant och inga fantomplaceholdere injiceras.

NotImplementedError för IntegerChoices i råa GROUP BY-queries

Symtom:

NotImplementedError: Not supported type <enum '...'> (StatusChoices.IN_PROGRESS)

Samma enum-värde fungerar i ORM-frågor och i råa frågor utan GROUP BY, men misslyckas när det skickas som parameter till en råfråga som innehåller en GROUP BY klausul.

Lösning: Uppgradera till en nuvarande mssql-django version. Backenden använder isinstance för kontroll av parametertyper i sökvägen GROUP BY, så IntegerChoices (en underklass av int) binds korrekt. bool binder fortfarande bit, och vanlig int är oförändrad.

Problem med Regex-uppslagning

__regex eller __iregex returnerar inga rader

Symtom: Frågan körs utan fel och returnerar en tom resultatuppsättning, även om raderna matchar mönstret.

Product.objects.filter(name__regex=r"^Widget \d+$")  # no rows, though "Widget 42" exists

Orsak: dbo.REGEXP_LIKE ignorerar bokstavligt tomrum i mönstret. Mönstret matchas som om det vore ^Widget\d+$, vilket inget värde som innehåller ett mellanslag kan uppfylla. Inget höjs, så det tomma resultatet ser ut som ett data-problem.

Lösning: Skriv whitespace som en escape eller en karaktärsklass:

Product.objects.filter(name__regex=r"^Widget\s\d+$")
Product.objects.filter(name__regex=r"^Widget[ ]\d+$")

Cannot find ... dbo.REGEXP_LIKE

Symtom:

django.db.utils.ProgrammingError: ('42000', '[42000] [Microsoft][ODBC Driver 18 for SQL Server][SQL Server]Cannot find either column "dbo" or the user-defined function or aggregate "dbo.REGEXP_LIKE", or the name is ambiguous. (4121) (SQLExecDirectW)')

På sökvägen mssql-python:

django.db.utils.ProgrammingError: Driver Error: Syntax error or access violation; DDBC Error: [Microsoft][SQL Server]Cannot find either column "dbo" or the user-defined function or aggregate "dbo.REGEXP_LIKE", or the name is ambiguous.

Orsak: CLR-assembleren är inte installerad i databasen du söker i. Det installeras per databas, inte per server.

Lösning: Kör python manage.py install_regex_clr <database> mot den databasen. Kör om den efter att ha tagit bort och återskapat databasen. Se Konfigurera regex-uppslag.

Problem med datum och tid

Now() värden förskjuts när USE_TZ=True

Symtom:

Tidsstämplar skrivna med Django Now(), auto_noweller auto_now_add flyttas när SQL Server värdtidszonen inte är UTC.

Lösning: Uppgradera till en nuvarande mssql-django version. Backenden genererar SQL med tidszonsstöd Now(), bevarar datetimeoffset-offsetar och läser tidszonsdata via zoneinfo och tzdata.

AttributeError vid anrop till .explain()

Symtom:

AttributeError: ... explain_format ...

Lösning: Uppgradera till en nuvarande mssql-django version. Backenden hanterar explain-metadata för varje Django-version som stöds.

Det går inte att ändra AutoField

Symtom:

django.db.utils.ProgrammingError: Cannot alter column to or from an IDENTITY column

Lösning: SQL Server stöder inte ändring av ett fält från eller till AutoField. Skapa en ny modell med önskad fälttyp, migrera data manuellt och släpp sedan den gamla tabellen. Lösningar finns i Databasmigreringar med mssql-django.

Det går inte att byta namn på grund av en begränsning för främmande nyckel

Symtom:

django.db.utils.ProgrammingError: ... could not drop constraint ...

Lösning: SQL Server kräver att begränsningarna för sekundärnyckeln släpps innan kolumner byts namn. Använd SeparateDatabaseAndState i migreringen. Ett exempel finns i Databasmigreringar med mssql-django.

Kodningsproblem

Kodningsfel uppstår vanligtvis i pyodbc-sökvägen när pyodbc misstolkar teckendata från SQL Server.

Unicode-kodningsfel

Symtom:

UnicodeDecodeError: 'utf-8' codec can't decode byte ...

Lösning: Konfigurera pyodbc kodning i ordboken OPTIONS . mssql-python-sökvägen ignorerar unicode_results.

"OPTIONS": {
    "driver": "ODBC Driver 18 for SQL Server",
    "unicode_results": True,
},

Problem med FreeTDS

FreeTDS kräver pyodbc-specifik konfiguration som skiljer sig från Microsoft ODBC-drivrutinen.

host_is_server fel

Symtom:

Anslutningen misslyckas när du använder FreeTDS utan att ange host_is_server.

Lösning: Ange host_is_server till True när du använder FreeTDS:

"OPTIONS": {
    "driver": "FreeTDS",
    "host_is_server": True,
},

Mer information om FreeTDS-konfiguration finns i Anslutningsalternativ för mssql-django.

Problem med testdatabasen

Att skapa och ta bort testdatabaser kan misslyckas beroende på vilken autentiseringsmetod du använder.

Det går inte att skapa en testdatabas med hanterad identitet

Symtom:

django.db.utils.DatabaseError: ('42000', '[42000] ... EXECUTE permission denied on object ...')

Or:

django.db.utils.OperationalError: ('28000', ... login failed ...)

Testköraren kan inte skapa eller förstöra testdatabasen när du använder ActiveDirectoryMsi (hanterad identitet) autentisering. Den här begränsningen finns eftersom:

• Autentiseringsuppgifter för hanterad identitet hämtas från värdmiljön (till exempel Azure virtuell dator och App Service).

• Testköraren försöker ansluta med inloggningsuppgifterna för databasen test vid nedmonteringen.

• Hanterad identitet kan beviljas roller på databasnivå, men skapande och borttagning av testdatabaser kräver vanligtvis behörigheter på servernivå som testlöpare ofta inte har.

Autentiseringsmetoder som påverkas:

• ActiveDirectoryMsi (Azure-hanterad identitet)
• ActiveDirectoryServicePrincipal (endast när den konfigureras på servernivå)

Autentiseringsmetoder som stöds (testdatabasens skapande fungerar):

• ActiveDirectoryPassword
• ActiveDirectoryIntegrated
• SQL-autentisering (användarnamn/lösenord)

Avvägningar för autentisering för testmiljöer

Lösningar:

• För utveckling: Använd --keepdb flaggan för att hoppa över granskning av testdatabaser:

  python manage.py test --keepdb
  

• För CI/CD-pipelines: Skapa en dedikerad testdatabas i förväg och ge den hanterade identiteten CREATE TABLE och ALTER behörigheterna:

  -- Connect as a server admin, then:
  USE [test_database_name];
  
  -- Grant permissions for managed identity (replace with your identity name)
  CREATE USER [your-app-identity] FROM EXTERNAL PROVIDER;
  GRANT CREATE TABLE TO [your-app-identity];
  GRANT ALTER ON SCHEMA::dbo TO [your-app-identity];
  

• Alternativ: Använd SQL-autentisering för testmiljöer eller växla till ActiveDirectoryPassword för CI/CD-testlöpare.

Rollback-procedurer

När en migrering misslyckas halvvägs kan du använda den här återställningssekvensen för att återgå till ett känt bra tillstånd:

1. Stoppa programskrivningar för att undvika ytterligare schemaavvikelser.

2. Granska migreringstillstånd:

   python manage.py showmigrations
   python manage.py sqlmigrate <app_label> <migration_number>
   

3. Återställ till den senaste kända goda migreringen:

   python manage.py migrate <app_label> <previous_migration>
   

4. Om schema- och migreringshistoriken avviker, reparerar du tillståndet noggrant med --fake endast när du har verifierat det faktiska databasschemat.

5. Kör migreringarna igen i en testmiljö först och försök sedan igen i produktion.

Problem med Docker och container

Containeravbildningar kräver uttrycklig installation av ODBC-drivrutiner och byggberoenden när du använder standardmetoden med pyodbc. mssql-python-lösningen har ingen separat installation av ODBC-drivrutinen, men den behöver fortfarande unixODBC-körningsmiljön eftersom bakänden importerar pyodbc när Django läser in den.

ODBC-drivrutinen hittades inte i containern

Symtom:

Error: ('01000', "[01000] [unixODBC][Driver Manager]Can't open lib 'ODBC Driver 18 for SQL Server'")

Möjliga orsaker och lösningar:

• ODBC-drivrutinen är inte installerad i containeravbildningen

  Slim- eller Alpine-basavbilder innehåller inte ODBC-drivrutinen. Lägg till Microsoft APT-arkivet och installera msodbcsql18 i din Dockerfile när du använder pyodbc. Se Distribuera till App Service för ett komplett Dockerfile-exempel.

• Paket saknas unixodbc-dev

  Hjulet pyodbc länkar mot libodbc.so. Installera unixodbc-dev (Debian/Ubuntu) eller unixODBC-devel (RHEL/Fedora) innan du installerar Python paket.

• apt-get autoremove rensad libgssapi-krb5-2 efter installation av drivrutinen

  msodbcsql18 laddar libgssapi-krb5-2 vid körning utan att deklarera det som ett beroende. Biblioteket installeras vanligtvis som ett beroende av curl, så om du rensar curl med --auto-remove, eller kör apt-get autoremove efteråt, tas det bort. Avbildningen byggs utan fel och därefter misslyckas alla anslutningar. Installera libgssapi-krb5-2 explicit, och ta inte bort automatiskt efter drivrutinsinstallationen.

Drivrutin 17 rapporterades saknad när du installerade version 18

Symtom:

Error: ('01000', "[01000] [unixODBC][Driver Manager]Can't open lib 'ODBC Driver 17 for SQL Server' : file not found (0) (SQLDriverConnect)")

Felet namnger version 17, men odbcinst -q -d visar version 18 registrerad och dpkg -l msodbcsql18 visar att den är installerad.

Orsak: Version 18 är registrerad men startar inte, så mssql-django faller tillbaka till version 17, som inte är installerad. Reservlösningen rapporterar den drivrutin som den försökte med i andra hand, inte den som misslyckades.

Lösning: Installera libgssapi-krb5-2 och bygg om. Se den föregående anteckningen om automatisk borttagning om hur biblioteket försvinner.

Felladdning av pyodbc-modul i en container

Symtom:

django.core.exceptions.ImproperlyConfigured: Error loading pyodbc module: libodbc.so.2: cannot open shared object file: No such file or directory

Orsak: Avbildningen har ingen unixODBC-körmiljö. mssql-django importerar pyodbc när Django laddar backenden, så det här felet uppstår även i mssql-python-kodvägen innan något anslutningsförsök görs.

Lösning: Installera unixodbc (eller unixodbc-dev).

mssql-python-drivrutinen laddas inte

Symtom:

django.db.utils.OperationalError: Driver Error: Connection operation failed; DDBC Error: Failed to load the driver.

Orsak: Drivrutinen som medföljer mssql-python behöver Kerberos körningsbibliotek, som slimmade basavbilder inte innehåller.

Lösning: Installera libkrb5-3 och libgssapi-krb5-2.

pyodbc kan inte bygga på smala bilder

Symtom:

error: command 'gcc' failed: No such file or directory

Or:

fatal error: sql.h: No such file or directory

Lösning: Installera byggberoenden före pip install:

RUN apt-get update && apt-get install -y --no-install-recommends \
    gcc \
    g++ \
    unixodbc-dev

Du kan också använda en flerstegsversion för att hålla den slutliga avbildningen liten:

# Build stage
FROM python:3.12-slim AS builder
RUN apt-get update && apt-get install -y --no-install-recommends gcc g++ unixodbc-dev
COPY requirements.txt .
RUN pip wheel --no-cache-dir --wheel-dir /wheels -r requirements.txt

# Runtime stage
FROM python:3.12-slim
RUN apt-get update && apt-get install -y --no-install-recommends \
    curl gnupg2 unixodbc \
    && curl -fsSL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor -o /usr/share/keyrings/microsoft-prod.gpg \
    && curl -fsSL https://packages.microsoft.com/config/debian/12/prod.list > /etc/apt/sources.list.d/mssql-release.list \
    && apt-get update \
    && ACCEPT_EULA=Y apt-get install -y --no-install-recommends msodbcsql18 libgssapi-krb5-2 \
    && apt-get purge -y curl gnupg2 \
    && rm -rf /var/lib/apt/lists/*
COPY --from=builder /wheels /wheels
RUN pip install --no-cache-dir /wheels/*

Containern kan inte ansluta till SQL Server

Symtom:

django.db.utils.OperationalError: ('08001', '... TCP Provider: Error code 0x2749 ...')

Möjliga orsaker och lösningar:

• Docker Compose-tjänstnamnet används inte som värd

  När du använder Docker Compose anger du DB_HOST till tjänstnamnet (till exempel db), inte localhost eller 127.0.0.1.

• SQL Server containern är inte klar

  Det tar flera sekunder att starta den SQL Server containern. Lägg till en hälsokontroll eller startfördröjning:

  services:
    db:
      image: mcr.microsoft.com/mssql/server:2022-latest
      healthcheck:
        test: /opt/mssql-tools18/bin/sqlcmd -S localhost -U sa -P "$$MSSQL_SA_PASSWORD" -No -Q "SELECT 1" || exit 1
        # $$ escapes the $ sign in Docker Compose YAML
        interval: 10s
        retries: 10
        start_period: 10s
    web:
      depends_on:
        db:
          condition: service_healthy
  

• Portmappningskonflikter

  Om en annan instans av SQL Server körs på värddatorn, ändra den exponerade porten (till exempel 1434:1433) och uppdatera din Django-konfiguration därefter.

Azure SQL återställning efter tillfälliga fel

Serverdelen mssql-django upptäcker automatiskt Azure SQL Database- och Azure SQL Managed Instance-anslutningar genom att fråga SERVERPROPERTY('EngineEdition'). När serverdelen körs mot Azure SQL försöker den ansluta igen vid tillfälliga fel (till exempel tillfälliga resursgränser eller korta nätverksavbrott).

Du kan justera det här beteendet med alternativen connection_retries och connection_retry_backoff_time:

"OPTIONS": {
    "driver": "ODBC Driver 18 for SQL Server",
    "connection_retries": 5,
    "connection_retry_backoff_time": 5,
},

De här inställningarna gäller endast för inledande anslutningsetablering. Serverdelen försöker inte köra misslyckade frågor igen. Om en fråga misslyckas på grund av ett övergående fel efter att anslutningen har upprättats, förs undantaget vidare till din programkod. Använd logik för återförsök på programnivå (till exempel django-retry-db eller ett anpassat mellanprogram) för motståndskraft på frågenivå.

Långsamma frågor och planregressioner

Dessa problem behöver vanligtvis analys på serversidan tillsammans med frågegranskning på Django-nivå.

Frågan går långsammare eller börjar få timeout

Symtom:

Samma frågeuppsättning blir långsammare över tid eller börjar ta tid efter en distribution, indexändring eller statistikuppdatering.

Möjliga orsaker och lösningar:

• Börja med inbyggda prestandarapporter

  För SQL Server och Azure SQL Managed Instance öppnar du Instrumentpanelen för prestanda i SQL Server Management Studio. För Azure SQL Database öppnar du Query Performance Insight för Azure SQL Database. Dessa verktyg är vanligtvis ett bättre första steg än ad hoc DMV-frågor eftersom de snabbt visar dyra frågor, väntetider och resurstryck.

• Planera regression

  Använd Query Store för att hitta den långsamma frågan och kontrollera om den har flera planer. Börja med vyerna Regressed Queries och Top Resource Consuming Queries som beskrivs i Metodtips för övervakning av arbetsbelastningar med Query Store.

• Ineffektiv exekveringsplan

  Öppna en aktuell körningsplan för satsen och kontrollera om det finns tabell- eller indexgenomsökningar, omfattande nyckeluppslag, hash-spill eller felaktiga raduppskattningar. Bakgrund finns i Översikt över körningsplan.

• Fel flaskhals har identifierats

  Om frågan inte är CPU-bunden använder du Query Store väntestatistik och Identifiera flaskhalsar för att skilja cpu, minne, disk-I/O, blockering och anslutningstryck.

• Korrigering som har tillämpats i fel lager

  Använd den minsta effektiva korrigeringen: lägg till eller justera index, uppdatera statistik, minska antalet valda kolumner och rader eller dela upp stora skrivoperationer i batchar. Om du behöver en akut åtgärd kan en DBA tillfälligt tvinga fram en känd fungerande plan i Query Store medan du åtgärdar grundorsaken.

Använda dbshell för interaktiva frågor

Djangos hanteringskommando dbshell öppnar ett interaktivt SQL-gränssnitt som är anslutet till databasen:

python manage.py dbshell

Serverdelen använder sqlcmd när du konfigurerar Microsoft ODBC-drivrutin eller isql när du använder FreeTDS. Kontrollera att verktyget finns på din PATH:

• Windows: sqlcmd ingår i SQL Server verktyg, eller så kan du ladda ned det separat.
• Linux och macOS: Installera mssql-tools18 från Microsoft-lagringsplatsen.

Relaterat innehåll

• konfigurationsreferens för mssql-django
• Anslutningsalternativ för mssql-django
• Prova logik och anslutningsåterhämtning igen med mssql-django
• Begränsningar och funktioner som inte stöds i mssql-django
• Prestandaöversikt
• Insikter om frågeprestanda för Azure SQL Database
• Övervaka prestanda med hjälp av Query Store
• Analysera en faktisk körningsplan
• Felsöka wiki
• FAQ