T-SQL skillnader mellan SQL Server & Azure SQL Managed Instance

  • Artikel
  • 21 minuter för att läsa

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.

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 kommer att åtgärdas i framtiden beskrivs i Vad är nytt?.

Tillgänglighet

Always On-tillgänglighetsgrupper

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

Backup

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

  • Med en SQL Managed Instance kan du bara backa upp en instansdatabas till ett Azure Blob Storage-konto:
    • Endast BACKUP TO URL stöds.
    • FILESäkerhetskopieringsenheterna , TAPE och stöds inte.
  • De flesta av de WITH allmänna alternativen stöds.
    • COPY_ONLY är obligatoriskt.
    • FILE_SNAPSHOT stöds inte.
    • Bandalternativ: REWIND NOREWIND , , och UNLOAD stöds NOUNLOAD inte.
    • Loggspecifika alternativ: NORECOVERY STANDBY , NO_TRUNCATE och stöds inte.

Begränsningar:

  • Med en SQL Managed Instance kan du säkerhetskopiera en instansdatabas till en säkerhetskopia med upp till 32 remsor, vilket är tillräckligt för databaser upp till 4 TB om komprimering av säkerhetskopior används.

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

  • Interna säkerhetskopior som tas på en hanterad instans kan inte återställas till en SQL Server. Det beror på att Managed Instance har högre intern databasversion jämfört med någon version av SQL Server.

  • Om du vill säkerhetskopiera eller återställa en databas till/från en Azure-lagring måste du skapa en signatur för delad åtkomst (SAS) en URI som ger dig begränsad åtkomstbehörighet till Azure Storage resurser Läs mer om detta. Det finns inte stöd för att använda åtkomstnycklar för dessa scenarier.

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

    Tips

    För att komma runt den här begränsningen kan du göra följande när du SQL Server en databas från en lokal miljö eller på en virtuell dator:

    • Back up to DISK i stället för att backa upp till URL .
    • Upload säkerhetskopierade filer till Blob Storage.
    • Återställ till SQL Managed Instance.

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

Information om säkerhetskopieringar med T-SQL finns i BACKUP.

Säkerhet

Granskning

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

  • Med SQL Managed Instance fungerar granskning på servernivå. .xelLoggfilerna lagras i Azure Blob Storage.
  • Med Azure SQL Database fungerar granskning på databasnivå. .xelLoggfilerna 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- Windows loggar stöds inte.

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

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

Mer information finns i:

Certifikat

SQL Managed Instance kan inte komma åt filresurser 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ÄKERHETSKOPIERA CERTIFIKAT.

Lösning: I stället för att skapa en säkerhetskopia av ett certifikat och återställa säkerhetskopian hämtar du certifikatets binära innehåll och privata nyckel, lagrar det som .sql-filoch skapar från binärt :

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

Autentiseringsuppgift

Endast Azure Key Vault SHARED ACCESS SIGNATURE och identiteter stöds. Windows användare stöds inte.

Se CREATE CREDENTIAL och ALTER CREDENTIAL.

Kryptografiska providers

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

Inloggningar och användare

  • SQL inloggningar som skapats FROM CERTIFICATE med hjälp av , och FROM ASYMMETRIC KEY FROM SID stöds. Se SKAPA INLOGGNING.

  • Azure Active Directory (Azure AD) serverhuvudnamn (inloggningar) som skapats med syntaxen CREATE LOGIN eller syntaxen CREATE USER FROM LOGIN [Azure AD Login] stöds. Dessa inloggningar skapas på servernivå.

    SQL Managed Instance har stöd för Azure AD-databashuvudnamn med syntaxen CREATE USER [AADUser/AAD group] FROM EXTERNAL PROVIDER . Den här funktionen kallas även för användare av inneslutna databaser i Azure AD.

  • Windows inloggningar som skapats CREATE LOGIN ... FROM WINDOWS med syntaxen stöds inte. Använd Azure Active Directory inloggningar och användare.

  • Azure AD-administratören för instansen har obegränsad administratörsbehörighet.

  • Användare som inte är administratörer på Azure AD-databasnivå kan skapas med hjälp av CREATE USER ... FROM EXTERNAL PROVIDER syntaxen. Se SKAPA ANVÄNDARE... FRÅN EXTERN PROVIDER.

  • Azure AD-serverhuvudnamn (inloggningar) stöder SQL funktioner inom en SQL Hanterad instans. Funktioner som kräver interaktion mellan instanser, oavsett om de finns i samma Azure AD-klientorganisation eller olika klienter, stöds inte för Azure AD-användare. Exempel på sådana funktioner är:

    • SQL transaktionsreplikering.
    • Länkserver.

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

  • Personifiering av Azure AD-huvudnamn på servernivå med hjälp av andra Azure AD-huvudnamn stöds, till exempel EXECUTE AS-satsen. EXECUTE AS-begränsningar är:

    • EXECUTE AS USER stöds inte för Azure AD-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 [ ] och personifiering görs via john@contoso.com EXEC AS USER = myAadUser. När du skapar en ANVÄNDARE från ett Azure AD-serverhuvudkonto (inloggning) anger du user_name som samma login_name från LOGIN.

    • Endast de SQL Server (inloggningar) som ingår i rollen kan utföra följande åtgärder som riktar sig sysadmin mot Azure AD-huvudnamn:

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

    • För att personifiera en användare med EXECUTE AS-instruktionen måste användaren mappas direkt till Azure AD-serverhuvudnamnet (inloggning). Användare som är medlemmar i Azure AD-grupper som är mappade till Azure AD-serverhuvudnamn kan effektivt 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 Azure AD-användare i SQL Managed Instance med Antingen SSMS V18.4eller senare eller SQLPackage.exe.

    • Följande konfigurationer stöds med hjälp av bacpac-databasfilen:
      • Exportera/importera en databas mellan olika hanterade instanser inom samma Azure AD-domän.
      • Exportera en databas från SQL Managed Instance och importera till SQL Database inom samma Azure AD-domän.
      • Exportera en databas från SQL Database och importera till SQL Managed Instance inom samma Azure AD-domän.
      • Exportera en databas från SQL-instans och importera till SQL Server (version 2012 eller senare).
        • I den här konfigurationen skapas alla Azure AD-användare som SQL Server databashuvudnamn (användare) utan inloggningar. Typen av användare visas som och SQL visas som i SQL_USER 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 huvudkontoinloggningen på servernivå, som skapas av etableringsprocessen för SQL Managed Instance, medlemmar i serverrollerna, till exempel eller , eller andra inloggningar med behörigheten ALTER ANY LOGIN på servernivå kan skapa securityadmin Azure AD-serverhuvudnamn (inloggningar) i huvuddatabasen sysadmin för SQL Managed Instance.

  • Om inloggningen är SQL huvudkonto kan endast inloggningar som ingår i rollen använda create-kommandot för att skapa sysadmin inloggningar för ett Azure AD-konto.

  • Azure AD-inloggningen måste vara medlem i en Azure AD i samma katalog som används för Azure SQL Managed Instance.

  • Azure AD-serverhuvudnamn (inloggningar) visas i Object Explorer börjar med SQL Server Management Studio 18.0 förhandsversion 5.

  • Ett serverhuvudnamn med sysadmin-åtkomstnivå skapas automatiskt för Azure AD-administratörskontot när det har aktiverats på en instans.

  • Under autentiseringen tillämpas följande sekvens för att matcha autentiseringsobjekt:

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

Tjänstnyckel och huvudnyckel för tjänsten

Konfiguration

Buffertpooltillägg

Sortering

Standardinstans-sorteringen är SQL_Latin1_General_CP1_CI_AS och kan anges som en parameter för skapande. Se Sorteringar.

Efterlevnadsnivåer

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

Se ALTER DATABASE Compatibility Level.

Databasspegling

Databasspegling stöds inte.

  • ALTER DATABASE SET PARTNER - SET WITNESS och -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 ... (ÄNDRA DATABASUPPSÄTTNINGSPARTNER och ANGE VITTNE OCH SKAPA SLUTPUNKT... FÖR DATABASE_MIRRORING.

Databasalternativ

  • Flera loggfiler stöds inte.
  • Minnesbaserade objekt stöds inte på den Generell användning tjänstnivån.
  • Det finns en gräns på 280 filer per Generell användning instans, vilket innebär högst 280 filer per databas. Både data och loggfiler på Generell användning nivå räknas mot den här gränsen. Den Affärskritisk stöder 32 767 filer per databas.
  • Databasen får inte innehålla filgrupper som innehåller filströmsdata. Återställningen misslyckas om .bak 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.

  • Alternativet CONTAINMENT stöds inte.

  • WITH -alternativ stöds inte.

    Tips

    Som en lösning kan du använda ALTER DATABASE efter för att ange CREATE DATABASE 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 CREATE DATABASE.

ALTER DATABASE-instruktion

Vissa filegenskaper kan inte anges eller ändras:

  • En filsökväg kan inte anges i ALTER DATABASE ADD FILE (FILENAME='path') T-SQL-instruktionen. Ta FILENAME bort från skriptet eftersom SQL hanterad instans automatiskt placerar filerna.
  • Det går inte att ändra ett filnamn med hjälp av ALTER DATABASE -instruktionen.

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 tillfälligt misslyckas, till exempel under den automatiserade säkerhetskopieringen av databasen eller direkt efter att en databas har skapats. I det här ALTER DATABASE fallet 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 PROCESSOR stöds inte.
  • SQL Server Agentinställningar är skrivskyddade. Proceduren stöds sp_set_agent_properties inte i SQL Hanterad instans.
  • 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 inte för närvarande:
      • Steget för sammanslagningsreplikeringsjobbet stöds inte.
      • Köläsare stöds inte.
      • Kommandogränssnittet stöds inte ännu.
    • 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 Agent 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.
    • Proxys stöds inte.
  • EventLog stöds inte.
  • Användaren måste mappas direkt till Azure AD-serverhuvudkonto (inloggning) för att skapa, ändra eller köra SQL agentjobb. Användare som inte är direkt mappade, till exempel användare som tillhör en Azure AD-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å begränsningar för managed instance-personifiering och EXECUTE AS.
  • Funktionen Multi Server Administration för master-/måljobb (MSX/TSX) stöds inte.

Information om SQL Server Agent finns i SQL Server Agent.

Tables

Följande tabelltyper stöds inte:

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

Funktioner

Massinfogning/OPENROWSET

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

  • DATASOURCE krävs i kommandot BULK INSERT när du importerar filer från Azure Blob Storage. Se BULK INSERT.
  • DATASOURCE krävs i funktionen OPENROWSET när du läser innehållet i en fil från Azure Blob Storage. Se OPENROWSET.
  • OPENROWSETkan 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

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

Database Mail (db_mail)

  • sp_send_dbmail kan inte skicka bifogade filer med @file_attachments parametern . Lokalt filsystem och externa resurser eller Azure Blob Storage inte tillgänglig 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 Spårningsflaggor.
  • 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 kan inte användas eftersom databasen inte kan anges i läge – se SINGLE_USER ALTER DATABASE differences. Potentiella fel i databasen hanteras av Azure-supportteamet. Kontakta Azure-supporten om det finns tecken på att databasen är skadad.

Distribuerade transaktioner

Partiellt stöd för distribuerade transaktioner är för närvarande i offentlig förhandsversion. Distribuerade transaktioner stöds under följande villkor (alla måste vara uppfyllda):

  • alla transaktionsdeltagare är Azure SQL Managed Instances som ingår i serverförtroendegruppen.
  • transaktioner initieras antingen från .NET (TransactionScope-klassen) eller Transact-SQL.

Azure SQL Managed Instance stöder för närvarande inte andra scenarier som regelbundet stöds av MSDTC lokalt eller i Azure Virtual Machines.

Extended Events

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 R- och Python-bibliotek i databasen stöds i begränsad offentlig förhandsversion. Se Machine Learning Services i Azure SQL Managed Instance (förhandsversion).

Filestream och FileTable

  • Filströmsdata 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 och SQL Server instanser.
  • Distribuerade skrivbara transaktioner är endast möjliga mellan hanterade instanser. Mer information finns i Distribuerade transaktioner. MS DTC stöds dock inte.
  • 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 som ett alternativ för filimport eller läsa in filer med hjälp av en BULK INSERT OPENROWSET serverlös SQL-pool i Azure Synapse Analytics.

Åtgärder:

  • Skrivtransaktioner mellan instanser stöds endast för hanterade instanser.
  • sp_dropserver stöds för att ta bort en länkad server. Se sp_dropserver.
  • Funktionen OPENROWSET kan endast användas för att köra frågor på SQL Server instanser. De kan antingen hanteras, lokalt eller på virtuella datorer. Se OPENROWSET.
  • Funktionen OPENDATASOURCE kan endast användas för att köra frågor på SQL Server instanser. De kan antingen hanteras, lokalt eller på virtuella datorer. Endast SQLNCLI värdena SQLNCLI11 , och stöds SQLOLEDB som provider. Ett exempel är SELECT * FROM OPENDATASOURCE('SQLNCLI', '...').AdventureWorks2012.HumanResources.Employee. Se OPENDATASOURCE.
  • Länkade servrar kan inte användas för att läsa filer (Excel, CSV) från nätverksresurser. Försök att använda BULK INSERT, OPENROWSET som läser CSV-filer från Azure Blob Storage eller en länkad server som refererar till en serverlös SQL-pool i Synapse Analytics. Spåra dessa begäranden på SQL feedbackobjekt för hanterad instans|

Länkade servrar på Azure SQL Managed Instance stöder SQL autentisering AAD autentisering.

PolyBase

Arbetet med att aktivera Polybase-stöd i SQL Managed Instance pågår. Under tiden kan du som en lösning använda länkade servrar till en serverlös SQL-pool i Synapse Analytics eller SQL Server för att fråga efter data från filer som lagras i Azure Data Lake eller Azure Storage.
Allmän information om PolyBase finns i PolyBase.

Replikering

  • Replikeringstyper för ögonblicksbilder och dubbelriktade stöds. Sammanslagningsreplikering, peer-to-peer-replikering och uppdatbara prenumerationer stöds inte.
  • Transaktionsreplikering är tillgängligt för offentlig förhandsversion på SQL Managed Instance med vissa begränsningar:
    • Alla typer av replikeringsdeltagare (Publisher, 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 både lokalt.
    • SQL Managed Instance kan kommunicera med de senaste versionerna av SQL Server. Mer information finns i versionsmatrisen som stöds.
    • Transaktionsreplikering har vissa ytterligare nätverkskrav.

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

RESTORE-instruktion

  • Syntax som stöds:
    • RESTORE DATABASE
    • RESTORE FILELISTONLY ONLY
    • RESTORE HEADER ONLY
    • RESTORE LABELONLY ONLY
    • RESTORE VERIFYONLY ONLY
  • Syntax som inte stöds:
    • RESTORE LOG ONLY
    • RESTORE REWINDONLY ONLY
  • Källa:
    • FROM URL (Azure Blob Storage) är det enda alternativ som stöds.
    • FROM DISK/TAPE/backup-enheten stöds inte.
    • Säkerhetskopieringsuppsättningar stöds inte.
  • WITH -alternativ stöds inte. Återställningsförsök WITH DIFFERENTIAL som , , STATS REPLACE osv. misslyckas.
  • ASYNC RESTORE: Återställningen fortsätter även om klientanslutningen bryts. Om anslutningen har tagits bort kan du kontrollera statusen för en återställningsåtgärd och för en CREATE- och sys.dm_operation_status DROP-databas. Se sys.dm_operation_status.

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

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

Begränsningar:

  • Säkerhetskopior av de skadade databaserna kan återställas beroende på typen av skada, men automatiska säkerhetskopieringar tas inte förrän felen har åtgärdats. Se till att du kör DBCC CHECKDB på källan SQL Managed Instance och använd säkerhetskopiering för att förhindra det här WITH CHECKSUM problemet.
  • Återställning av fil för en databas som innehåller begränsningar som beskrivs i det här dokumentet (till exempel eller objekt) kan inte .BAK FILESTREAM FILETABLE återställas 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 minnesbaserade OLTP-objekt eller antal filer som överstiger 280 filer per instans kan inte återställas på en Generell användning-instans.
  • Säkerhetskopior som innehåller databaser som är större än 4 TB eller minnes minnesbaserade OLTP-objekt med en total storlek som är större än den storlek som beskrivs i resursbegränsningar kan inte återställas på Affärskritisk instans. Information om återställningsutsatser finns i RESTORE-instruktioner.

Viktigt

Samma begränsningar gäller för inbyggd återställning till tidpunkt. Till exempel kan Generell användning databas som är större än 4 TB inte återställas på Affärskritisk instansen. Affärskritisk en databas med minnes minnes in memory OLTP-filer eller fler än 280 filer kan inte återställas på en Generell användning instans.

Service Broker

Utbyte av service broker-meddelanden mellan instanser stöds endast mellan Azure SQL Managed Instances:

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

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

  • CREATE REMOTE SERVICE BINDINGstöds inte.

Service Broker är aktiverat som standard och kan inte inaktiveras. Följande ALTER DATABASE-alternativ stöds inte:

  • ENABLE_BROKER
  • DISABLE_BROKER

Lagrade procedurer, funktioner och utlösare

  • NATIVE_COMPILATION stöds inte på den Generell användning nivån.
  • Följande sp_configure alternativ stöds inte:
    • allow polybase export
    • allow updates
    • filestream_access_level
    • remote access
    • remote data archive
    • remote proc trans
    • scan for startup procs
  • Följande alternativ sp_configure ignoreras och har ingen effekt:
    • Ole Automation Procedures
  • sp_execute_external_scripts stöds inte. Se sp_execute_external_scripts.
  • xp_cmdshell stöds inte. Se xp_cmdshell.
  • Extended stored procedures stöds inte, och detta inkluderar sp_addextendedproc och sp_dropextendedproc . Den här funktionen stöds inte eftersom den är på en utfasningsväg för SQL Server. Mer information finns i Utökade lagrade procedurer.
  • sp_attach_db, sp_attach_single_file_db och sp_detach_db stöds inte. Se sp_attach_db, sp_attach_single_file_dboch sp_detach_db.

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 hanterad instans. Se SERVEREGENSKAPER.
  • SERVERPROPERTY('InstanceName')returnerar NULL eftersom begreppet instans som det finns för SQL Server inte gäller för SQL hanterad instans. Se SERVERPROPERTY('InstanceName').
  • @@SERVERNAME returnerar ett fullständigt DNS-namn som kan anslutas, till exempel my-managed-instance.wcus17662feb9ce98.database.windows.net. Se @SERVERNAME @.
  • SYS.SERVERS returnerar ett fullständigt DNS-"anslutningsbart" namn, till exempel för myinstance.domain.database.windows.net egenskaperna "name" och "data_source". Se SYS. SERVRAR.
  • @@SERVICENAMEreturnerar 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. Det returnerar NULL om Azure AD-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

Undernä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.

VNET

  • VNet kan distribueras med hjälp av resursmodell – klassisk modell för VNet stöds inte.
  • När en SQL hanterad instans har skapats stöds inte 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 2020-09-22 global peering inte. Du kan ansluta till dessa resurser via ExpressRoute eller VNet-till-VNet via VNet-gatewayer.

Redundansgrupper

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

TEMPDB

  • Den maximala filstorleken tempdb för får inte vara större än 24 GB per kärna på en Generell användning nivå. Den maximala tempdb storleken på en Affärskritisk-nivå begränsas av lagringsstorleken SQL hanterad instans. Tempdb loggfilens storlek är begränsad till 120 GB Generell användning nivån. Vissa frågor kan returnera ett fel om de behöver mer än 24 GB per kärna i eller om de producerar mer än tempdb 120 GB loggdata.
  • Tempdb delas alltid upp i 12 datafiler: 1 primär, kallas även master, datafil och 11 icke-primära datafiler. Filstrukturen kan inte ändras och nya filer kan inte läggas till i tempdb .
  • Minnesoptimerade tempdb metadata, en ny funktion SQL Server databas i minnet från 2019, stöds inte.
  • Objekt som skapats i modelldatabasen kan inte skapas automatiskt i efter en omstart eller redundans eftersom inte får sin tempdb tempdb första objektlista från modelldatabasen. Du måste skapa objekt i tempdb manuellt efter varje omstart eller en redundans.

MSDB

Följande MSDB-scheman i den SQL instansen måste ägas av deras respektive fördefinierade roller:

Viktigt

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

Felloggar

SQL Managed Instance placerar utförlig information i felloggarna. 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 vissa irrelevanta poster. Mer information finns i SQL Managed Instance – sp_readmierrorlog eller SQL Managed Instance-tillägg (förhandsversion) för Azure Data Studio.

Nästa steg