Dela via

Skillnader i T-SQL mellan SQL Server och Azure SQL Managed Instance

Gäller för:Azure SQL Managed Instance

Den här artikeln sammanfattar och förklarar skillnaderna i syntax och beteende mellan Azure SQL Managed Instance och SQL Server.

SQL Managed Instance ger hög kompatibilitet med SQL Server-databasmotorn och de flesta funktioner stöds i en SQL Managed Instance.

Diagram som visar enkel migrering från SQL Server.

Det finns vissa PaaS-begränsningar som introduceras i SQL Managed Instance och vissa beteendeändringar jämfört med SQL Server. Skillnaderna är indelade i följande kategorier:

De flesta av dessa funktioner är arkitekturbegränsningar och representerar tjänstfunktioner.

Tillfälliga kända problem som identifieras i SQL Managed Instance och som kommer att lösas i framtiden beskrivs i Vad är nytt i Azure SQL Managed Instance?

Anmärkning

Microsoft Entra-ID kallades tidigare Azure Active Directory (Azure AD).

Tillgänglighet

AlwaysOn-tillgänglighetsgrupper

Hög tillgänglighet är inbyggd i SQL Managed Instance och kan inte styras av användare. Följande instruktioner stöds inte:

Säkerhetskopiering

Azure SQL Managed Instance har automatiska säkerhetskopior, så att användarna kan skapa fullständiga databassäkerhetskopior COPY_ONLY . Differentiella säkerhetskopieringar, logg- och filsäkerhetskopior och ögonblicksbilder stöds inte.

  • Med en SQL Managed Instance kan du endast säkerhetskopiera en instansdatabas till ett Azure Blob Storage-konto:
    • Endast BACKUP TO URL stöds.
    • FILE, TAPEoch säkerhetskopieringsenheter stöds inte.
  • De flesta av de allmänna WITH alternativen stöds.
    • COPY_ONLY är obligatoriskt.
    • FILE_SNAPSHOT och CREDENTIAL stöds inte.
    • Bandalternativ: REWIND, NOREWIND, UNLOADoch NOUNLOAD stöds inte.
    • Loggspecifika alternativ: NORECOVERY, STANDBYoch NO_TRUNCATE stöds inte.

Begränsningar:

  • Med en SQL Managed Instance kan du säkerhetskopiera en instansdatabas till en säkerhetskopia med upp till 32 ränder, vilket räcker för databaser upp till 4 TB om säkerhetskopieringskomprimering används.

  • Du kan inte köra BACKUP DATABASE ... WITH COPY_ONLY på en databas som är krypterad med tjänsthanterad transparent datakryptering (TDE). Tjänsthanterad TDE tvingar säkerhetskopieringar att krypteras med en intern TDE-nyckel. Det går inte att exportera nyckeln, så du kan inte återställa säkerhetskopian. Använd automatiska säkerhetskopior och återställning till tidpunkt, eller använd kundhanterad TDE (BYOK) i stället. Du kan också inaktivera kryptering i databasen.

  • Inbyggda säkerhetskopior som görs på en SQL Managed Instance kan endast återställas till en SQL Server 2022-instans. Det beror på att SQL Managed Instance har högre intern databasversion jämfört med andra versioner av SQL Server. Mer information finns i Återställa en databas till SQL Server 2022 från Azure SQL Managed Instance.

  • Om du vill säkerhetskopiera eller återställa en databas till/från en Azure-lagring kan du autentisera med antingen hanterad identitet eller signatur för delad åtkomst (SAS) som är en URI som ger dig begränsad åtkomstbehörighet till Azure Storage-resurser Läs mer om detta. Åtkomstnycklar för dessa scenarier stöds inte.

  • Den maximala randstorleken BACKUP för säkerhetskopiering med kommandot i SQL Managed Instance är 195 GB, vilket är den maximala blobstorleken. Öka antalet ränder i säkerhetskopieringskommandot för att minska den enskilda randstorleken och hålla dig inom den här gränsen.

    Tips/Råd

    Om du vill kringgå den här begränsningen kan du göra följande när du säkerhetskopierar en databas från antingen SQL Server i en lokal miljö eller på en virtuell dator:

    • Säkerhetskopiera till i stället för att DISK säkerhetskopiera till URL.
    • Ladda upp säkerhetskopieringsfilerna till Blob Storage.
    • Återställ till SQL Managed Instance.

    Kommandot Restore i SQL Managed Instance stöder större blobstorlekar i säkerhetskopieringsfilerna eftersom en annan blobtyp används för lagring av de uppladdade säkerhetskopierade filerna.

Information om säkerhetskopieringar med T-SQL finns i SÄKERHETSKOPIERing.

Säkerhet

Granskning

De viktigaste skillnaderna mellan granskning i Microsoft Azure SQL och SQL Server är:

  • Med SQL Managed Instance fungerar granskning på servernivå. Loggfilerna .xel lagras i Azure Blob Storage.
  • Med Azure SQL Database fungerar granskning på databasnivå. Loggfilerna .xel lagras i Azure Blob Storage.
  • Med SQL Server, lokalt eller på virtuella datorer fungerar granskning på servernivå. Händelser lagras i filsystem eller Windows-händelseloggar.

XEvent-granskning i SQL Managed Instance stöder Azure Blob Storage-mål. Fil- och Windows-loggar stöds inte.

De viktigaste skillnaderna i syntaxen CREATE AUDIT för granskning av Azure Blob Storage är:

  • En ny syntax TO URL tillhandahålls för att ange URL:en för Azure Blob Storage-containern där .xel filerna placeras.
  • Syntaxen TO FILE stöds inte eftersom SQL Managed Instance inte kan komma åt Windows-filresurser.

Mer information finns i:

Certifikaten

SQL Managed Instance kan inte komma åt filresurser och Windows-mappar, så följande begränsningar gäller:

  • Filen CREATE FROM/BACKUP TO stöds inte för certifikat.
  • Certifikatet CREATE/BACKUP från FILE/ASSEMBLY stöds inte. Privata nyckelfiler kan inte användas.

Se SKAPA CERTIFIKAT OCH SÄKERHETSKOPIERINGSCERTIFIKAT.

Lösning: I stället för att skapa en säkerhetskopia av certifikatet och återställa säkerhetskopian hämtar du det binära certifikatinnehållet och den privata nyckeln, lagrar den som .sql fil och skapar från binär fil:

CREATE CERTIFICATE
   FROM BINARY = asn_encoded_certificate
WITH PRIVATE KEY (<private_key_options>);

Behörighet

Hanterad identitet, Azure Key Vault och SHARED ACCESS SIGNATURE identiteter stöds. Windows-användare stöds inte.

Se SKAPA AUTENTISERINGSUPPGIFTER OCH ÄNDRA AUTENTISERINGSUPPGIFTER.

Kryptografiska providrar

SQL Managed Instance kan inte komma åt filer, så kryptografiska providers kan inte skapas:

Inloggningar och användare

  • SQL-inloggningar som skapas med hjälp FROM CERTIFICATEav , FROM ASYMMETRIC KEYoch FROM SID stöds. Se SKAPA INLOGGNING. Serverhuvudnamn (inloggningar) skapas på servernivå och användare (databashuvudnamn) skapas på databasnivå. Microsoft Entra-inloggningar som skapats med syntaxen CREATE LOGIN och Microsoft Entra-användare som skapats med syntaxen CREATE USER FROM LOGIN stöds. När du skapar en användare och anger FROM LOGINär den användaren associerad med inloggningen och ärver de serverroller och behörigheter som tilldelats den.

    SQL Managed Instance har stöd för att skapa oberoende databasanvändare baserat på Microsoft Entra-identiteter med syntaxen CREATE USER [AADUser/AAD group] FROM EXTERNAL PROVIDER. Användare som skapats på det här sättet är inte associerade med serverhuvudnamn, även om det finns ett serverhuvudnamn med samma namn i master databasen.

  • Windows-inloggningar som skapats med syntaxen CREATE LOGIN ... FROM WINDOWS stöds inte. Använd Microsoft Entra-inloggningar och -användare.

  • Microsoft Entra-administratören för instansen har obegränsade administratörsbehörigheter.

  • Vissa funktioner stöder inte användning av Microsoft Entra-inloggningar i interaktioner mellan instanser, men endast inom en enda SQL Managed Instance, till exempel SQL Server-replikering. Funktionen länkad server stöder dock autentisering mellan instanser med hjälp av Microsoft Entra-serverhuvudnamn (inloggningar).

  • Det går inte att ange en Microsoft Entra-inloggning mappad till en Microsoft Entra-grupp som databasägare. En medlem i Microsoft Entra-gruppen kan vara databasägare, även om inloggningen inte har skapats i databasen.

  • Personifiering av Microsoft Entra-huvudkonton på servernivå med hjälp av andra Microsoft Entra-huvudnamn stöds, till exempel EXECUTE AS-satsen . Kör som-begränsningar är:

    • EXECUTE AS USER stöds inte för Microsoft Entra-användare när namnet skiljer sig från inloggningsnamnet. Ett exempel är när användaren skapas via syntaxen CREATE USER [myAadUser] FROM LOGIN [john@contoso.com] och personifiering görs via EXEC AS USER = myAadUser. När du skapar en ANVÄNDARE från en Microsoft Entra-inloggning anger du user_name som samma login_name från LOGIN.

    • Endast inloggningar på SQL Server-nivå som ingår i sysadmin rollen kan utföra följande åtgärder som riktar sig mot Microsoft Entra-huvudnamn:

      • KÖR SOM ANVÄNDARE
      • KÖR SOM INLOGGNING

    • För att personifiera en användare med EXECUTE AS-instruktionen måste användaren mappas direkt till Microsoft Entra-inloggning. Användare som är medlemmar i Microsoft Entra-grupper som är mappade till Microsoft Entra-serverhuvudnamn kan inte i praktiken personifieras med EXECUTE AS-instruktionen, även om anroparen har personifierarbehörigheter för det angivna användarnamnet.

  • Databasexport/import med bacpac-filer stöds för Microsoft Entra-användare i SQL Managed Instance med SSMS V18.4 eller senare eller SqlPackage.

    • Följande konfigurationer stöds med hjälp av databasens bacpac-fil:
      • Exportera/importera en databas mellan olika hantera instanser inom samma Microsoft Entra-domän.
      • Exportera en databas från SQL Managed Instance och importera till SQL Database inom samma Microsoft Entra-domän.
      • Exportera en databas från SQL Database och importera till SQL Managed Instance inom samma Microsoft Entra-domän.
      • Exportera en databas från SQL Managed Instance och importera till SQL Server (version 2012 eller senare).
        • I den här konfigurationen skapas alla Microsoft Entra-användare som SQL Server-databashuvudnamn (användare) utan inloggningar. Typen av användare är SQL och visas som SQL_USER i sys.database_principals. Deras behörigheter och roller finns kvar i SQL Server-databasmetadata och kan användas för personifiering. De kan dock inte användas för att komma åt och logga in på SQL Server med sina autentiseringsuppgifter.

  • Endast huvudinloggningen på servernivå, som skapas av SQL Managed Instance-etableringsprocessen, medlemmar av serverrollerna, till exempel securityadmin eller sysadmin, eller andra inloggningar med ALTER ANY LOGIN-behörighet på servernivå, kan skapa Microsoft Entra-serverhuvudkonton (inloggningar) i master databasen för SQL Managed Instance.

  • SQL-autentiseringsbaserade inloggningar måste tilldelas sysadmin rollen för att skapa inloggningar för Microsoft Entra-identiteter.

  • Inloggningen måste vara medlem i samma Microsoft Entra-klientorganisation som Azure SQL Managed Instance finns i.

  • Microsoft Entra-serverhuvudkonton (inloggningar) visas i Object Explorer från och med SQL Server Management Studio 18.0 preview 5.

  • Ett serverhuvudnamn med sysadmin-åtkomstnivå skapas automatiskt för Microsoft Entra-administratören när det har aktiverats på en instans.

  • Under autentiseringen tillämpas följande sekvens för att lösa autentiseringsobjektet:

    1. Om Microsoft Entra-kontot är direkt mappat till en Microsoft Entra-inloggning, som finns i sys.server_principals som typ "E", beviljar du åtkomst och tillämpar behörigheter för inloggningen.
    2. Om Microsoft Entra-kontot är medlem i en grupp som är mappad till en Microsoft Entra-inloggning, som finns i sys.server_principals som typ "X", beviljar du åtkomst och tillämpar behörigheter för inloggningen.
    3. Om Microsoft Entra-kontot finns som direkt mappat till en Microsoft Entra-användare i en databas, som finns i sys.database_principals som typ "E", beviljar du åtkomst och tillämpar behörigheter för Microsoft Entra-databasanvändaren.
    4. Om Microsoft Entra-kontot är medlem i en Microsoft Entra-grupp som mappas till en Microsoft Entra-användare i en databas, som finns i sys.database_principals som typ "X", beviljar du åtkomst och tillämpar behörigheter för Microsoft Entra-gruppanvändaren.

Tjänstnyckel och tjänsthuvudnyckel

Konfiguration

Tillägg för buffertpool

Sammanställning

Standardsortering av instanser är SQL_Latin1_General_CP1_CI_AS och kan anges som en skapandeparameter. Se Sorteringar.

Efterlevnadsnivåer

  • Kompatibilitetsnivåer som stöds är 100, 110, 120, 130, 140, 150 och 160.
  • Kompatibilitetsnivåer under 100 stöds inte.
  • Standardkompatibilitetsnivån för nya databaser är 150. För återställda databaser förblir kompatibilitetsnivån oförändrad om den var 100 och högre.

Se ÄNDRA DATABASkompatibilitetsnivå.

Databasåterspegling

Databasspegling stöds inte.

  • ALTER DATABASE SET PARTNER och SET WITNESS alternativ stöds inte.
  • CREATE ENDPOINT ... FOR DATABASE_MIRRORING stöds inte.

Mer information finns i ALTER DATABASE SET PARTNER and SET WITNESS and CREATE ENDPOINT ... FÖR DATABASE_MIRRORING.

Databasalternativ

  • Flera loggfiler stöds inte.
  • Minnesinterna objekt stöds inte på tjänstnivån Generell användning.
  • Det finns en gräns på 280 filer per instans av generell användning, vilket innebär högst 280 filer per databas. Både data och loggfiler på nivån Generell användning räknas mot den här gränsen. Nivån Affärskritisk stöder 32 767 filer per databas.
  • Databasen får inte innehålla filgrupper som innehåller FILESTREAM-data. Återställningen misslyckas om .bak den innehåller FILESTREAM data.
  • Varje fil placeras i Azure Blob Storage. I/O och dataflöde per fil beror på storleken på varje enskild fil.

CREATE DATABASE-instruktion

Följande begränsningar gäller för CREATE DATABASE:

  • Filer och filgrupper kan inte definieras.

  • En minnesoptimerad filgrupp och fil läggs automatiskt till och kallas XTP.

  • Alternativet CONTAINMENT stöds inte.

  • WITH alternativ stöds inte.

    Tips/Råd

    Som en lösning kan du använda ALTER DATABASE efter CREATE DATABASE för att ange databasalternativ för att lägga till filer eller ange inneslutning.

  • Alternativet FOR ATTACH stöds inte.

  • Alternativet AS SNAPSHOT OF stöds inte.

Mer information finns i SKAPA DATABAS.

ALTER DATABASE-instruktion

Vissa filegenskaper kan inte anges eller ändras:

  • Det går inte att ange en filsökväg i T-SQL-instruktionen ALTER DATABASE ADD FILE (FILENAME='path') . Ta bort FILENAME från skriptet eftersom SQL Managed Instance automatiskt placerar filerna.
  • Det går inte att ändra ett filnamn med hjälp av -instruktionen ALTER DATABASE .
  • Det är inte tillåtet att ändra XTP-fil eller filgrupp.

Följande alternativ anges som standard och kan inte ändras:

  • MULTI_USER
  • ENABLE_BROKER
  • AUTO_CLOSE OFF

Följande alternativ kan inte ändras:

  • AUTO_CLOSE
  • AUTOMATIC_TUNING(CREATE_INDEX=ON|OFF)
  • AUTOMATIC_TUNING(DROP_INDEX=ON|OFF)
  • DISABLE_BROKER
  • EMERGENCY
  • ENABLE_BROKER
  • FILESTREAM
  • HADR
  • NEW_BROKER
  • OFFLINE
  • PAGE_VERIFY
  • PARTNER
  • READ_ONLY
  • RECOVERY BULK_LOGGED
  • RECOVERY_SIMPLE
  • REMOTE_DATA_ARCHIVE
  • RESTRICTED_USER
  • SINGLE_USER
  • WITNESS

Vissa ALTER DATABASE instruktioner (till exempel SET CONTAINMENT) kan misslyckas tillfälligt, till exempel under den automatiserade databassäkerhetskopian eller direkt efter att en databas har skapats. I det här fallet ALTER DATABASE bör instruktionen göras om. Mer information om relaterade felmeddelanden finns i avsnittet Kommentarer.

Mer information finns i ALTER DATABASE.

SQL Server-agent

  • Aktivering och inaktivering av SQL Server Agent stöds för närvarande inte i SQL Managed Instance. SQL Agent körs alltid.
  • Jobbschemautlösare som baseras på en inaktiv CPU stöds inte.
  • SQL Server Agent-inställningarna är skrivskyddade. Proceduren sp_set_agent_properties stöds inte i SQL Managed Instance.
  • Jobb
    • T-SQL-jobbsteg stöds.
    • Följande replikeringsjobb stöds:
      • Transaktionsloggläsare
      • Ögonblicksbild
      • Distributör
    • SSIS-jobbsteg stöds.
    • Andra typer av jobbsteg stöds för närvarande inte:
      • Jobbsteget för sammanslagningsreplikering stöds inte.
      • Köläsare stöds inte.
      • Kommandogränssnittet stöds ännu inte.
    • SQL Managed Instance kan inte komma åt externa resurser, till exempel nätverksresurser via robocopy.
    • SQL Server Analysis Services stöds inte.
  • Meddelanden stöds delvis.
  • E-postavisering stöds, även om det kräver att du konfigurerar en Database Mail-profil. SQL Server-agenten kan bara använda en Database Mail-profil och den måste anropas AzureManagedInstance_dbmail_profile.
    • Pager stöds inte.
    • NetSend stöds inte.
    • Aviseringar stöds inte ännu.
    • Proxyservrar stöds inte.
  • EventLog stöds inte.
  • Användaren måste mappas direkt till Microsoft Entra-serverinloggningen för att skapa, ändra eller köra SQL Agent-jobb. Användare som inte är direkt mappade, till exempel användare som tillhör en Microsoft Entra-grupp som har behörighet att skapa, ändra eller köra SQL Agent-jobb, kommer inte att kunna utföra dessa åtgärder på ett effektivt sätt. Detta beror på SQL Managed Instance-personifiering och KÖR SOM-begränsningar.
  • Funktionen Multi Server Administration för huvud-/måljobb (MSX/TSX) stöds inte.

Information om SQL Server Agent finns i SQL Server Agent.

Tabeller

Följande tabelltyper stöds inte:

Information om hur du skapar och ändrar tabeller finns i SKAPA TABELL och ALTER TABLE.

Funktioner

BULK INSERT/OPENROWSET

SQL Managed Instance kan inte komma åt filresurser och Windows-mappar, så filerna måste importeras från Azure Blob Storage:

  • DATASOURCE krävs i BULK INSERT kommandot när du importerar filer från Azure Blob Storage. Se MASSINFOGNING.
  • DATASOURCE krävs i funktionen när du läser innehållet i OPENROWSET en fil från Azure Blob Storage. Se OPENROWSET.
  • OPENROWSET kan användas för att läsa data från Azure SQL Database, Azure SQL Managed Instance eller SQL Server-instanser. Andra källor som Oracle-databaser eller Excel-filer stöds inte.

CLR (Common Language Runtime)

En SQL Managed Instance kan inte komma åt filresurser och Windows-mappar, så följande begränsningar gäller:

Databas Mail (db_mail)

  • sp_send_dbmail kan inte skicka bifogade filer med hjälp av @file_attachments parametern . Lokala filsystem och externa resurser eller Azure Blob Storage är inte tillgängliga från den här proceduren.
  • Se kända problem som rör @query parameter och autentisering.

DBCC

Odokumenterade DBCC-instruktioner som är aktiverade i SQL Server stöds inte i SQL Managed Instance.

  • Endast ett begränsat antal globala spårningsflaggor stöds. Sessionsnivå Trace flags stöds inte. Se Ange spårningsflaggor med DBCC TRACEON.
  • DBCC TRACEOFF och DBCC TRACEON fungerar med det begränsade antalet globala spårningsflaggor.
  • DBCC CHECKDB med alternativ REPAIR_ALLOW_DATA_LOSS, REPAIR_FAST och REPAIR_REBUILD inte kan användas eftersom databasen inte kan ställas in i SINGLE_USER läge – se ALTER DATABASE-skillnader. Potentiell databasskada hanteras av Azure-supportteamet. Kontakta Azure-supporten om det finns några tecken på att databasen är skadad.

Distribuerade transaktioner

T-SQL- och .NET-baserade distribuerade transaktioner över hanterade instanser är allmänt tillgängliga. Andra scenarier, till exempel XA-transaktioner, distribuerade transaktioner mellan hanterade instanser och andra deltagare med mera, stöds med DTC (Distributed Transaction Coordinator) för Azure SQL Managed Instance, som är tillgängligt i offentlig förhandsversion.

Utökade händelser

Vissa Windows-specifika mål för Extended Events (XEvents) stöds inte:

  • Målet etw_classic_sync stöds inte. Lagra .xel-filer i Azure Blob Storage. Läs mer i Målet etw_classic_sync.
  • Målet event_file stöds inte. Lagra .xel-filer i Azure Blob Storage. Läs mer i Målet event_file.

Externa bibliotek

Externa bibliotek i databasen R och Python stöds i begränsad offentlig förhandsversion. Se Machine Learning Services i Azure SQL Managed Instance.

FILESTREAM och FileTable

  • FILESTREAM-data stöds inte.
  • Databasen får inte innehålla filgrupper med FILESTREAM data.
  • FILETABLE stöds inte.
  • Tabeller kan inte ha FILESTREAM typer.
  • Följande funktioner stöds inte:
    • GetPathLocator()
    • GET_FILESTREAM_TRANSACTION_CONTEXT()
    • PathName()
    • GetFileNamespacePat)
    • FileTableRootPath()

Mer information finns i FILESTREAM och FileTables.

Semantisk fulltextsökning

Semantisk sökning stöds inte.

Länkade servrar

Länkade servrar i SQL Managed Instance stöder ett begränsat antal mål:

  • Mål som stöds är SQL Managed Instance, SQL Database, Azure Synapse SQL serverlösa och dedikerade pooler samt SQL Server-instanser.
  • Mål som inte stöds är filer, Analysis Services och andra RDBMS. Försök att använda inbyggd CSV-import från Azure Blob Storage med eller BULK INSERTOPENROWSET som ett alternativ för filimport eller läsa in filer med hjälp av en serverlös SQL-pool i Azure Synapse Analytics.

Åtgärder:

Länkade servrar på Azure SQL Managed Instance stöder SQL-autentisering och Microsoft Entra-autentisering.

PolyBase

Med datavirtualisering med Azure SQL Managed Instance kan du köra Transact-SQL frågor (T-SQL) mot data från filer som lagras i Azure Data Lake Storage Gen2 eller Azure Blob Storage och kombinera dem med lokalt lagrade relationsdata med hjälp av kopplingar. Filformat för parquet och avgränsad text (CSV) stöds direkt. JSON-filformatet stöds indirekt genom att ange CSV-filformatet där frågor returnerar varje dokument som en separat rad. Det går att parsa rader ytterligare med hjälp av JSON_VALUE och OPENJSON. Allmän information om PolyBase finns i Datavirtualisering med PolyBase i SQL Server.

Med SKAPA EXTERN TABELL SOM SELECT (CETAS) kan du dessutom exportera data från din SQL-hanterade instans till ett externt lagringskonto. Du kan använda CETAS för att skapa en extern tabell ovanpå Parquet- eller CSV-filerna Azure Blob Storage eller Azure Data Lake Storage (ADLS) Gen2. CETAS kan också parallellt exportera resultatet av en T-SQL SELECT-instruktion till den skapade externa tabellen.

Replikering

  • Ögonblicksbilder och dubbelriktade replikeringstyper stöds. Sammanslagningsreplikering, peer-to-peer-replikering och uppdaterbara prenumerationer stöds inte.
  • Transaktionsreplikering är tillgänglig för SQL Managed Instance med vissa begränsningar:
    • Alla typer av replikeringsdeltagare (utgivare, distributör, pull-prenumerant och push-prenumerant) kan placeras på SQL Managed Instance, men utgivaren och distributören måste antingen vara både i molnet eller lokalt.
    • SQL Managed Instance kan kommunicera med de senaste versionerna av SQL Server. Mer information finns i matrisen för versioner som stöds.
    • Transaktionsreplikering har ytterligare nätverkskrav.

Mer information om hur du konfigurerar transaktionsreplikering finns i följande självstudier:

Resursguvernör

Resursguvernör stöds. Det finns dock flera beteendeskillnader:

  • Om du vill ändra konfigurationen av resursguvernören i SQL Managed Instance måste du vara i kontexten för master databasen på den primära repliken.
  • Konfigurationsändringar för resursguvernören som görs på den primära repliken sprids till alla sekundära repliker. Ändringar i den aktuella effektiva konfigurationen på en sekundär replik kanske dock inte är omedelbara. Om du vill göra ändringarna effektiva på en sekundär replik ansluter du till master databasen på en sekundär replik och kör ALTER RESOURCE GOVERNOR RECONFIGURE.
  • Om inställningen är konfigurerad för en arbetsbelastningsgrupp och en batchbegäran överskrider den konfigurerade CPU-tiden i SQL Server REQUEST_MAX_CPU_TIME_SEC utlöses händelsen, cpu_threshold_exceeded men begäran avslutas inte om inte en spårningsflagga är aktiverad. I SQL Managed Instance utlöses samma händelse och begäran avslutas alltid. Mer information finns i REQUEST_MAX_CPU_TIME_SEC.
  • Det maximala antalet resurspooler som du kan skapa är 40.

RESTORE-instruktion

  • Syntax som stöds:
    • RESTORE DATABASE
    • RESTORE FILELISTONLY
    • RESTORE HEADERONLY
    • RESTORE LABELONLY
    • RESTORE VERIFYONLY
  • Syntax som inte stöds:
    • RESTORE LOGONLY
    • RESTORE REWINDONLY
  • Källa:
    • FROM URL (Azure Blob Storage) är det enda alternativ som stöds.
    • FROM DISK / TAPE/backup-enhet stöds inte.
    • Säkerhetskopieringsuppsättningar stöds inte.
  • WITH alternativ stöds inte. Återställningsförsök som WITHDIFFERENTIAL, STATS, REPLACEoch så vidare misslyckas.

En databasåterställningsåtgärd är asynkron och kan försöka igen i Azure SQL Managed Instance. Du kan få ett fel i SSMS om anslutningen misslyckas eller om tidsgränsen upphör att gälla. Azure SQL Managed Instance försöker återställa databasen i bakgrunden och du kan spåra återställningsprocessens förlopp med hjälp av sys.dm_exec_requests och sys.dm_operation_status dynamiska hanteringsvyer.

Följande databasalternativ anges eller åsidosättas och kan inte ändras senare:

  • NEW_BROKER om asynkron meddelandekö inte är aktiverad i filen .bak.
  • ENABLE_BROKER om asynkron meddelandekö inte är aktiverad i filen .bak.
  • AUTO_CLOSE=OFF om en databas i .bak-filen har AUTO_CLOSE=ON.
  • RECOVERY FULL om en databas i den .bak filen har SIMPLE eller BULK_LOGGED en återställningsmodell.
  • En minnesoptimerad filgrupp läggs till och kallas XTP om den inte fanns i källfilen .bak.
  • Alla befintliga minnesoptimerade filgrupper har bytt namn till XTP.
  • SINGLE_USER och RESTRICTED_USER alternativ konverteras till MULTI_USER.

Begränsningar:

  • Säkerhetskopior av de skadade databaserna kan återställas beroende på typen av skada, men automatiserade säkerhetskopieringar tas inte förrän skadan har åtgärdats. Se till att du kör DBCC CHECKDB på sql-källhanterad instans och använd säkerhetskopiering WITH CHECKSUM för att förhindra det här problemet.
  • .BAK Det går inte att återställa filen för en databas som innehåller någon begränsning som beskrivs i det här dokumentet (till exempel FILESTREAM eller FILETABLE objekt) på SQL Managed Instance.
  • .BAK filer som innehåller flera säkerhetskopieringsuppsättningar kan inte återställas.
  • .BAK filer som innehåller flera loggfiler kan inte återställas.
  • Säkerhetskopior som innehåller databaser som är större än 8 TB, aktiva minnesinterna OLTP-objekt eller antalet filer som överskrider 280 filer per instans kan inte återställas på en generell instans.
  • Säkerhetskopior som innehåller databaser som är större än 4 TB eller minnesinterna OLTP-objekt med den totala storleken som är större än den storlek som beskrivs i resursgränser kan inte återställas på en affärskritisk instans. Information om återställningsuttryck finns i RESTORE-instruktioner.

Viktigt!

Samma begränsningar gäller för den inbyggda återställningsåtgärden för tidpunkt. Till exempel kan databasen Generell användning som är större än 4 TB inte återställas på en affärskritisk instans. Affärskritisk databas med minnesinterna OLTP-filer eller fler än 280 filer kan inte återställas på generell användningsinstans.

Tjänstförmedlare

Meddelandeutbyte mellan instanstjänster stöds endast mellan Azure SQL Managed Instances:

  • CREATE ROUTE: Du kan inte använda CREATE ROUTE med ADDRESS annat än LOCAL eller DNS-namn för en annan SQL Managed Instance. Porten är alltid 4022.
  • ALTER ROUTE: Du kan inte använda ALTER ROUTE med ADDRESS annat än LOCAL eller DNS-namn för en annan SQL Managed Instance. Porten är alltid 4022.

Transportsäkerhet stöds, dialogsäkerhet är inte:

  • CREATE REMOTE SERVICE BINDINGstöds inte.

Tjänsthanteraren är aktiverad som standard för nyligen skapade databaser och kan inte inaktiveras. Tjänstutjämningstillståndet för återställda/migrerade databaser ärvs från källdatabasen och kan inte ändras. Följande ALTER DATABASE-alternativ stöds inte:

  • ENABLE_BROKER
  • DISABLE_BROKER

Lagrade procedurer, funktioner och utlösare

Systemfunktioner och variabler

Följande variabler, funktioner och vyer returnerar olika resultat:

  • SERVERPROPERTY('EngineEdition') returnerar värdet 8. Den här egenskapen identifierar unikt en SQL Managed Instance. Se SERVERPROPERTY.
  • SERVERPROPERTY('InstanceName') returnerar NULL eftersom begreppet instans som det finns för SQL Server inte gäller för SQL Managed Instance. Se SERVERPROPERTY('InstanceName').
  • @@SERVERNAME returnerar ett fullständigt DNS-namn som kan anslutas, my-managed-instance.wcus17662feb9ce98.database.windows.nettill exempel . Se @@SERVERNAME.
  • SYS.SERVERS returnerar ett fullständigt DNS-namn som kan anslutas, till exempel myinstance.domain.database.windows.net för egenskaperna "name" och "data_source". Se sys.servers.
  • @@SERVICENAME returnerar NULL eftersom begreppet tjänst som det finns för SQL Server inte gäller för SQL Managed Instance. Se @@SERVICENAME.
  • SUSER_ID stöds. Den returnerar NULL om Microsoft Entra-inloggningen inte finns i sys.syslogins. Se SUSER_ID.
  • SUSER_SID stöds inte. Fel data returneras, vilket är ett tillfälligt känt problem. Se SUSER_SID.

Miljöbegränsningar

Subnät

  • Du kan inte placera några andra resurser (till exempel virtuella datorer) i undernätet där du har distribuerat din SQL Managed Instance. Distribuera dessa resurser med ett annat undernät.
  • Undernätet måste ha tillräckligt många tillgängliga IP-adresser. Minimum är att ha minst 32 IP-adresser i undernätet.
  • Antalet virtuella kärnor och typer av instanser som du kan distribuera i en region har vissa begränsningar och begränsningar.
  • Det finns en nätverkskonfiguration som måste tillämpas på undernätet.

Virtuellt nätverk

  • Virtuella nätverk kan distribueras med hjälp av resursmodell. Den klassiska modellen stöder inte distribution av virtuella nätverk (VNet).
  • När en SQL-hanterad instans har skapats stöds inte flytt av sql-hanterad instans eller VNet till en annan resursgrupp eller prenumeration.
  • För SQL-hanterade instanser som finns i virtuella kluster som skapas före den 22 september 2020 stöds inte global VNet-peering . Du kan ansluta till dessa resurser via ExpressRoute eller VNet-till-VNet via virtuella nätverksgatewayer.

Failover-grupper

Systemdatabaser replikeras inte till den sekundära instansen i en redundansgrupp. Därför är scenarier som är beroende av objekt från systemdatabaserna omöjliga för den sekundära instansen om inte objekten skapas manuellt på den sekundära.

tempdb

  • Den maximala filstorleken för systemdatabasen tempdb får inte vara större än 24 GB per kärna på nivån Generell användning. Den maximala tempdb storleken på en affärskritisk nivå begränsas av lagringsstorleken för SQL Managed Instance. tempdb loggfilens storlek är begränsad till 120 GB på nivån Generell användning. Vissa frågor kan returnera ett fel om de behöver mer än 24 GB per kärna i tempdb eller om de producerar mer än 120 GB loggdata.
  • tempdb är alltid uppdelat i 12 datafiler: 1 primär, även kallad master, datafil och 11 icke-primära datafiler. Det går inte att ändra filstrukturen och det går inte att lägga till nya filer i tempdb.
  • Minnesoptimerade TempDB-metadata, en ny minnesintern databasfunktion för SQL Server 2019, stöds inte.
  • Objekt som skapats i model databasen kan inte skapas tempdb automatiskt efter en omstart eller en redundans eftersom tempdb den ursprungliga objektlistan inte hämtas från model databasen. Du måste skapa objekt tempdb manuellt efter varje omstart eller en redundansväxling.

msdb

Följande scheman i systemdatabasen msdb i SQL Managed Instance måste ägas av respektive fördefinierade roller:

Viktigt!

Om du ändrar fördefinierade rollnamn, schemanamn och schemaägare av kunder påverkas tjänstens normala drift. Ändringar som görs i dessa återställs till de fördefinierade värdena så snart som det har identifierats, eller senast vid nästa tjänstuppdatering för att säkerställa normal tjänståtgärd.

Felloggfiler

SQL Managed Instance placerar utförlig information i felloggar. Det finns många interna systemhändelser som loggas i felloggen. Använd en anpassad procedur för att läsa felloggar som filtrerar bort några irrelevanta poster. Mer information finns i SQL Managed Instance – sp_readmierrorlog.

Det går inte att ändra antalet kvarhållna felloggar.

Relaterat innehåll