Bekende problemen met Azure SQL Managed Instance
van toepassing op:
Azure SQL Managed Instance
Dit artikel bevat de momenteel bekende problemen met Azure SQL Managed Instanceen de oplossingsdatum of mogelijke tijdelijke oplossing. Zie Wat is Azure SQL Managed Instance?en Wat is er nieuw in Azure SQL Managed Instance?
Notitie
Microsoft Entra ID voorheen Azure Active Directory (Azure AD) werd genoemd.
Bekende problemen
Heeft een tijdelijke oplossing
Fout 8992 bij het uitvoeren van DBCC CHECKDB op een SQL Server-database die afkomstig is van SQL Managed Instance
Mogelijk ziet u de volgende fout wanneer u de DBCC CHECKDB-opdracht uitvoert op een SQL Server 2022-database nadat u een index of een tabel met een index hebt verwijderd, en de database afkomstig is van Azure SQL Managed Instance, zoals na het herstellen van een back-upbestand of vanuit de functie voor het koppelen van beheerde exemplaren:
_Msg 8992, Level 16, State 1, Line <Line_Number>an
Check Catalog Msg 3853, State 1: Attribute (%ls) of row (%ls) in sys.sysrowsetrefs does not have a matching row (%ls) in sys.indexes._
Als u het probleem wilt omzeilen, verwijdert u eerst de index of de tabel met de index, van de brondatabase in Azure SQL Managed Instance en herstelt of koppelt u de database opnieuw aan SQL Server 2022. Als het niet mogelijk is de database opnieuw te maken vanaf de Azure SQL Managed Instance, neem dan contact op met Microsoft-ondersteuning voor hulp bij het oplossen van dit probleem.
Lijst met langetermijnback-ups in Azure Portal toont back-upbestanden voor actieve en verwijderde databases met dezelfde naam
Back-ups op lange termijn kunnen worden weergegeven en beheerd op de azure-portalpagina voor een azure SQL Managed Instance op tabblad Back-ups. De pagina bevat actieve of verwijderde databases, basisinformatie over hun langetermijnback-ups en een koppeling voor het beheren van back-ups. Wanneer u de koppeling Beheren selecteert, wordt er een nieuw zijvenster geopend met een lijst met back-ups. Vanwege een probleem met de filterlogica bevat de lijst back-ups voor zowel actieve database als verwijderde databases met dezelfde naam. Dit vereist speciale aandacht bij het selecteren van back-ups voor verwijdering, om te voorkomen dat back-ups voor een verkeerde database worden verwijderd.
Tijdelijke oplossing: gebruik weergegeven back-uptijd (UTC) informatie in de lijst om back-ups te onderscheiden die behoren tot databases met dezelfde naam die op de instantie in verschillende tijdvakken bestonden. U kunt ook PowerShell-opdrachten Get-AzSqlInstanceDatabaseLongTermRetentionBackup en Remove-AzSqlInstanceDatabaseLongTermRetentionBackupof CLI-opdrachten az sql midb ltr-backup list en az sql midb ltr-backup delete gebruiken om langetermijnback-ups te beheren door de DatabaseState parameter en DatabaseDeletionTime retourwaarde te gebruiken om back-ups voor een database te filteren.
Het event_file doel van de system_health-gebeurtenissessie is niet toegankelijk
Wanneer u de inhoud van het event_file doel van de system_health gebeurtenissessie probeert te lezen, krijgt u fout 40538: 'Een geldige URL die begint met 'https://' is vereist als waarde voor elk opgegeven bestandspad. Dit gebeurt in SQL Server Management Studio of bij het lezen van de sessiegegevens met behulp van de functie sys.fn_xe_file_target_read_file.
Deze wijziging in gedrag is een onbedoeld gevolg van een recente vereiste beveiligingsoplossing. We onderzoeken de haalbaarheid van een extra wijziging waarmee klanten de system_health sessie op Azure SQL Managed Instance veilig kunnen blijven gebruiken. Ondertussen kunnen klanten dit probleem omzeilen door hun eigen equivalent van de system_health-sessie te maken met een event_file doel in Azure Blob Storage. Zie system_healthvoor meer informatie, inclusief een T-SQL-script om de system_health-sessie te creëren die kan worden aangepast om uw eigen equivalent van te maken.
Procedure sp_send_dbmail kan mislukken wanneer de parameter @query
Procedure sp_send_dbmail kan mislukken wanneer @query parameter wordt gebruikt. Fouten treden op wanneer de opgeslagen procedure wordt uitgevoerd onder het sysadmin-account.
Dit probleem wordt veroorzaakt door een bekende fout met betrekking tot de wijze waarop sp_send_dbmail imitatie gebruikt.
tijdelijke oplossing: zorg ervoor dat u sp_send_dbmail aanroept onder het juiste aangepaste account dat u hebt gemaakt en niet onder het sysadmin-account.
Hier volgt een voorbeeld van hoe u een toegewezen account kunt maken en bestaande objecten kunt wijzigen die e-mail verzenden via sp_send_dbmail.
USE [msdb]
GO
-- Step 1: Create a user mapped to a login to specify as a runtime user.
CREATE USER [user_name] FOR LOGIN [login_name]
GO
EXEC msdb.dbo.sp_update_jobstep @job_name=N'db_mail_sending_job', @step_id=db_mail_sending_job_id , @database_user_name=N'user_name'
GO
-- Step 2: Grant DB Mail permissions to the user who created it.
ALTER ROLE [DatabaseMailUserRole] ADD MEMBER [user_name]
GO
-- Step 3: If the database of the job step is not msdb, the permission error cannot be avoided even if it is a member of the role, so set it to msdb.
EXEC msdb.dbo.sp_update_jobstep @job_name=N'db_mail_sending_job', @step_id=db_mail_sending_job_id , @database_name=N'msdb'
GO
-- Step 4: Set a principal in the email profile
EXEC msdb.dbo.sysmail_add_principalprofile_sp @principal_name=N'user_name', @profile_name=N'profile_name', @is_default=0
GO
Tussentijdse richtlijnen voor tijdzone-updates voor Chili in 2022
Op 8 augustus 2022 heeft de Chileense regering een officiële aankondiging gedaan over een Daylight-Saving Time (DST) tijdzonewijziging. Vanaf 12:00 uur zaterdag 10 september 2022 tot 12:00 uur zaterdag, 1 april 2023, gaat de officiële tijd 60 minuten vooruit. De wijziging is van invloed op de volgende drie tijdzones: Pacific SA Standard Time, Easter Island Standard Time en Magallanes Standard Time. Azure SQL Managed Instances die gebruikmaken van betrokken tijdzones weerspiegelen de wijzigingen pas nadat Microsoft een update van het besturingssysteem heeft uitgebracht om dit te ondersteunen, en de Azure SQL Managed Instance-service absorbeert de update op het niveau van het besturingssysteem.
tijdelijke oplossing: als u de betrokken tijdzones voor uw beheerde exemplaren moet wijzigen, moet u rekening houden met de beperkingen en de richtlijnen in de documentatie volgen.
Het verbindingstype wijzigen heeft geen invloed op verbindingen via het eindpunt van de failovergroep
Als een exemplaar deelneemt aan een failovergroep, wordt het wijzigen van het verbindingstype van het exemplaar niet van kracht voor de verbindingen die tot stand zijn gebracht via het listenereindpunt van de failovergroep.
tijdelijke oplossing: failovergroep verwijderen en opnieuw maken nadat u het verbindingstype hebt gewijzigd.
Procedure sp_send_dbmail kan tijdelijk mislukken wanneer parameter @query wordt gebruikt
Procedure sp_send_dbmail tijdelijk kan mislukken wanneer @query parameter wordt gebruikt. Wanneer dit probleem optreedt, mislukt elke tweede uitvoering van procedure sp_send_dbmail met fout Msg 22050, Level 16, State 1 en bericht Failed to initialize sqlcmd library with error number -2147467259. Als u deze fout correct wilt kunnen zien, moet de procedure worden aangeroepen met de standaardwaarde 0 voor de parameter @exclude_query_output, anders wordt de fout niet doorgegeven.
Dit probleem wordt veroorzaakt door een bekende fout met betrekking tot de wijze waarop sp_send_dbmail imitatie en groepsgewijze verbindingen gebruikt.
U kunt dit probleem omzeilen door de code voor het verzenden van e-mails in te voegen in een herhaal-logica die afhankelijk is van de uitvoerparameter @mailitem_id. Als de uitvoering mislukt, is de parameterwaarde NULL, waarmee wordt aangegeven sp_send_dbmail nog één keer moet worden aangeroepen om een e-mailbericht te verzenden. Hier is een voorbeeld van deze herhaal-logica:
CREATE PROCEDURE send_dbmail_with_retry AS
BEGIN
DECLARE @miid INT
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
@mailitem_id = @miid OUTPUT
-- If sp_send_dbmail returned NULL @mailidem_id then retry sending email.
--
IF (@miid is NULL)
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
END
Gedistribueerde transacties kunnen worden uitgevoerd nadat het beheerde exemplaar uit de serververtrouwensgroep is verwijderd
serververtrouwensgroepen worden gebruikt om een vertrouwensrelatie tot stand te brengen tussen beheerde exemplaren die vereist zijn voor het uitvoeren van gedistribueerde transacties. Nadat u het beheerde exemplaar uit de serververtrouwensgroep hebt verwijderd of de groep hebt verwijderd, kunt u mogelijk nog steeds gedistribueerde transacties uitvoeren. Er is een tijdelijke oplossing die u kunt toepassen om ervoor te zorgen dat gedistribueerde transacties zijn uitgeschakeld en dat is door de gebruiker geïnitieerde handmatige failover op het beheerde exemplaar.
Gedistribueerde transacties kunnen na het schalen van een beheerd exemplaar niet worden uitgevoerd.
SQL Managed Instance-schaalbewerkingen, zoals het wijzigen van de servicelaag of het aantal vCores, stellen de instellingen van de serververtrouwensgroep op de backend opnieuw in en schakelen lopende gedistribueerde transactiesuit. Verwijder en maak als tijdelijke oplossing nieuwe serververtrouwensgroep in Azure Portal.
Kan sql Managed Instance niet maken met dezelfde naam als de logische server die u eerder hebt verwijderd
Er wordt een DNS-record van <name>.database.windows.com gemaakt wanneer u een logische server maakt in Azure voor Azure SQL Database en wanneer u een met SQL beheerd exemplaar maakt. De DNS-record moet uniek zijn. Als u een logische server voor SQL Database maakt en deze vervolgens verwijdert, is er een drempelwaardeperiode van zeven dagen voordat de naam uit de records wordt vrijgegeven. In die periode kan een met SQL beheerd exemplaar niet worden gemaakt met dezelfde naam als de verwijderde logische server. Gebruik als tijdelijke oplossing een andere naam voor het met SQL beheerde exemplaar of maak een ondersteuningsticket om de naam van de logische server vrij te geven.
Service-principal heeft geen toegang tot Microsoft Entra-id en AKV
In sommige gevallen bestaat er mogelijk een probleem met service-principal die wordt gebruikt voor toegang tot Microsoft Entra ID (voorheen Azure Active Directory) en Azure Key Vault-services (AKV). Dit probleem heeft als gevolg hiervan invloed op het gebruik van Microsoft Entra-verificatie en TDE (Transparent Data Encryption) met SQL Managed Instance. Dit kan optreden als een onregelmatig verbindingsprobleem of het niet kunnen uitvoeren van instructies zoals CREATE LOGIN/USER FROM EXTERNAL PROVIDER of EXECUTE AS LOGIN/USER. Het instellen van TDE met een door de klant beheerde sleutel voor een nieuw Azure SQL Managed Instance werkt mogelijk ook niet in bepaalde omstandigheden.
tijdelijke oplossing: als u wilt voorkomen dat dit probleem optreedt in uw sql Managed Instance, voordat u updateopdrachten uitvoert of als u dit probleem al hebt ondervonden na updateopdrachten, gaat u naar de pagina Overzicht van uw met SQL beheerde exemplaar in Azure Portal. Selecteer onder Instellingen, Microsoft Entra ID om toegang te krijgen tot de SQL Managed Instance beheerderspagina voor Microsoft Entra ID. Controleer of u het foutbericht 'Managed Instance heeft een service-principal nodig voor toegang tot Microsoft Entra-id' ziet. Klik hier om een "Service Principal" te maken. Als u dit foutbericht hebt aangetroffen, selecteert u het en volgt u de stapsgewijze instructies die worden opgegeven totdat deze fout is opgelost.
Beperking van handmatige failover via portal voor failovergroepen
Als een failovergroep meerdere exemplaren in verschillende Azure-abonnementen of -resourcegroepen omvat, kan handmatige failover niet worden gestart vanuit het primaire exemplaar in de failovergroep.
Tijdelijke oplossing: een failover starten via de portal vanuit het geo-secundaire exemplaar.
SQL Agent-rollen hebben expliciete EXECUTE-machtigingen nodig voor niet-sysadmin-aanmeldingen
Als niet-sysadmin-aanmeldingen worden toegevoegd aan een SQL Agent vaste databaserollen, bestaat er een probleem waarbij expliciete EXECUTE-machtigingen moeten worden verleend aan drie opgeslagen procedures in de master-database om deze aanmeldingen te laten functioneren. Als dit probleem optreedt, wordt het foutbericht The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229) weergegeven.
tijdelijke oplossing: nadat u aanmeldingen hebt toegevoegd aan een vaste SQL Agent-databaserol (SQLAgentUserRole, SQLAgentReaderRole of SQLAgentOperatorRole), voert u voor elk van de aanmeldingen die aan deze rollen zijn toegevoegd, het volgende T-SQL-script uit om expliciet EXECUTE-machtigingen te verlenen aan de vermelde opgeslagen procedures.
USE [master];
GO
CREATE USER [login_name] FOR LOGIN [login_name];
GO
GRANT EXECUTE ON master.dbo.xp_sqlagent_enum_jobs TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_is_starting TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_notify TO [login_name];
Oltp-geheugenlimieten in het geheugen worden niet toegepast
De servicelaag Bedrijfskritiek past in sommige gevallen niet correct maximale geheugenlimieten toe voor objecten die zijn geoptimaliseerd voor geheugen. Met SQL Managed Instance kan de werklast mogelijk meer geheugen gebruiken voor in-memory OLTP-bewerkingen, wat de beschikbaarheid en stabiliteit van de instance kan beïnvloeden. OLTP-query's in het geheugen die de limieten bereiken, mislukken mogelijk niet onmiddellijk. De query's die meer OLTP-geheugen in het geheugen gebruiken, mislukken sneller als ze de limietenbereiken.
tijdelijke oplossing: Het oltp-opslaggebruik in het geheugen bewaken met SQL Server Management Studio om ervoor te zorgen dat de werkbelasting niet meer dan het beschikbare geheugen gebruikt. Verhoog de geheugenlimieten die afhankelijk zijn van het aantal vCores of optimaliseer uw workload om minder geheugen te gebruiken.
Verkeerde fout geretourneerd tijdens het proberen te verwijderen van een bestand dat niet leeg is
SQL Server en SQL Managed Instance een gebruiker niet toestaan een bestand te verwijderen dat niet leeg is. Als u een niet-leeg gegevensbestand probeert te verwijderen met behulp van een ALTER DATABASE REMOVE FILE instructie, wordt de fout Msg 5042 – The file '<file_name>' cannot be removed because it is not empty niet onmiddellijk gegeven. Sql Managed Instance probeert het bestand te verwijderen en de bewerking mislukt na 30 minuten met Internal server error.
Wijzigingen in de servicelaag en het aanmaken van instanties worden geblokkeerd door een lopend databaseherstel.
Een doorlopende RESTORE-verklaring, een Data Migration Service-migratieproces en ingebouwd herstel naar een bepaald tijdstip blokkeren het bijwerken van een servicelaag, het wijzigen van de grootte van de bestaande instantie en het maken van nieuwe instanties totdat het herstelproces is voltooid.
Het herstelproces blokkeert deze bewerkingen op de beheerde exemplaren en exemplaarpools in hetzelfde subnet waarop het herstelproces wordt uitgevoerd. De instanties in instancegroepen worden niet beïnvloed. Bewerkingen voor het maken of wijzigen van servicelagen mislukken niet en krijgen geen time-out. Ze worden voortgezet zodra het herstelproces is voltooid of geannuleerd.
tijdelijke oplossing: wacht tot het herstelproces is voltooid of annuleer het herstelproces als de bewerking voor het maken of bijwerken van de servicelaag een hogere prioriteit heeft.
Resource Governor op de servicelaag Bedrijfskritiek moet mogelijk opnieuw worden geconfigureerd na een failover.
De Resource Governor-functie waarmee u de resources die zijn toegewezen aan de workload van de gebruiker kunt beperken, kan een bepaalde werkbelasting van de gebruiker onjuist classificeren na een failover of een door de gebruiker geïnitieerde wijziging van de servicelaag (bijvoorbeeld de wijziging van de maximale vCore- of maximale opslaggrootte van het exemplaar).
tijdelijke oplossing: voer ALTER RESOURCE GOVERNOR RECONFIGURE periodiek uit of als onderdeel van een SQL Agent-taak die de SQL-taak uitvoert wanneer het exemplaar wordt gestart als u Resource Governor-gebruikt.
Dialogen tussen databases voor de Service Broker moeten opnieuw worden geïnitialiseerd na een upgrade van de servicelaag.
Dialoogvensters van de Service Broker tussen databases stoppen met het leveren van berichten aan de services in andere databases na de wijziging van de dienstlaag. De berichten gaan niet verlorenen ze zijn te vinden in de wachtrij met afzenders. Elke wijziging van vCores of de opslaggrootte van exemplaren in SQL Managed Instance leidt ertoe dat een service_broke_guid-waarde in de sys.databases view voor alle databases wordt gewijzigd. Alle DIALOG die zijn gemaakt met behulp van een BEGIN DIALOG instructie, die verwijzen naar Service Brokers in een andere database, stoppen met het leveren van berichten aan de doelservice.
tijdelijke oplossing: stop alle activiteiten die gebruikmaken van dialooggesprekken tussen databases voor Service Broker voordat u een servicelaag bijwerkt en initialiseer ze daarna opnieuw. Als er nog berichten zijn die niet worden bezorgd nadat een servicelaag is gewijzigd, leest u de berichten uit de bronwachtrij en verzendt u deze opnieuw naar de doelwachtrij.
Het overschrijden van opslaglimieten door kleine databasebestanden
CREATE DATABASE, ALTER DATABASE ADD FILEen RESTORE DATABASE instructies kunnen mislukken omdat de instantie de limiet van Azure Storage kan bereiken.
Elk exemplaar voor algemeen gebruik van SQL Managed Instance heeft maximaal 35 TB opslagruimte die is gereserveerd voor Azure Premium Disk Space. Elk databasebestand wordt op een afzonderlijke fysieke schijf geplaatst. Schijven kunnen 128 GB, 256 GB, 512 GB, 1 TB of 4 TB zijn. Ongebruikte ruimte op de schijf wordt niet in rekening gebracht, maar de totale som van Azure Premium Disk-grootten mag niet groter zijn dan 35 TB. In sommige gevallen kan een beheerd exemplaar dat in totaal niet 8 TB nodig heeft, de Azure-limiet van 35 TB voor de opslaggrootte overschrijden vanwege interne fragmentatie.
Een exemplaar voor algemeen gebruik van SQL Managed Instance kan bijvoorbeeld één groot bestand hebben dat 1,2 TB groot is op een schijf van 4 TB. Het kan ook 248 bestanden hebben die elk 1 GB zijn en die op afzonderlijke schijven van 128 GB worden geplaatst. In dit voorbeeld:
- De totale toegewezen schijfopslaggrootte is 1 x 4 TB + 248 x 128 GB = 35 TB.
- De totale gereserveerde ruimte voor databases op de instantie is 1 x 1,2 TB + 248 x 1 GB = 1,4 TB.
In dit voorbeeld ziet u dat in bepaalde omstandigheden, vanwege een specifieke distributie van bestanden, een exemplaar van SQL Managed Instance de limiet van 35 TB kan bereiken die is gereserveerd voor een gekoppelde Azure Premium Disk, wanneer u dit niet verwacht.
In dit voorbeeld blijven bestaande databases werken en kunnen ze zonder problemen groeien zolang er geen nieuwe bestanden worden toegevoegd. Nieuwe databases kunnen niet worden gemaakt of hersteld omdat er onvoldoende ruimte is voor nieuwe schijfstations, zelfs niet als de totale grootte van alle databases de limiet voor de instantiegrootte niet bereikt. De fout die in dat geval wordt geretourneerd, is niet duidelijk.
U kunt het aantal resterende bestanden identificeren met behulp van systeemweergaven. Als u deze limiet bereikt, probeert u leeg te en verwijdert u enkele van de kleinere bestanden met behulp van de DBCC SHRINKFILE-instructie of schakelt u over naar de laag Bedrijfskritiek, die deze limiet niet heeft.
GUID-waarden weergegeven in plaats van databasenamen
Verschillende systeemweergaven, prestatiemeteritems, foutberichten, XEvents en vermeldingen in foutenlogboeken geven GUID-database-id's weer in plaats van de werkelijke databasenamen. Vertrouw niet op deze GUID-id's omdat deze in de toekomst mogelijk worden vervangen door werkelijke databasenamen.
tijdelijke oplossing: gebruik sys.databases weergave om de werkelijke databasenaam te bepalen aan de hand van de naam van de fysieke database, die is opgegeven in de vorm van GUID-database-ID's:
SELECT name AS ActualDatabaseName,
physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;
CLR-modules en gekoppelde servers kunnen soms niet verwijzen naar een lokaal IP-adres
CLR-modules in SQL Managed Instance en gekoppelde servers of gedistribueerde query's die naar een huidig exemplaar verwijzen, kunnen soms het IP-adres van een lokaal exemplaar niet oplossen. Deze fout is een tijdelijk probleem.
Transactiebereik op twee databases binnen hetzelfde exemplaar wordt niet ondersteund
(opgelost in maart 2020) De klasse TransactionScope in .NET werkt niet als twee query's worden verzonden naar twee databases binnen hetzelfde exemplaar onder hetzelfde transactiebereik:
using (var scope = new TransactionScope())
{
using (var conn1 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=<password>;Encrypt=true"))
{
conn1.Open();
SqlCommand cmd1 = conn1.CreateCommand();
cmd1.CommandText = string.Format("insert into T1 values(1)");
cmd1.ExecuteNonQuery();
}
using (var conn2 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=<password>;Encrypt=true"))
{
conn2.Open();
var cmd2 = conn2.CreateCommand();
cmd2.CommandText = string.Format("insert into b.dbo.T2 values(2)"); cmd2.ExecuteNonQuery();
}
scope.Complete();
}
tijdelijke oplossing (niet nodig sinds maart 2020): gebruik SqlConnection.ChangeDatabase(String) om een andere database in een verbindingscontext te gebruiken in plaats van twee verbindingen te gebruiken.
Geen oplossing
Differentiële back-ups worden niet gemaakt wanneer een exemplaar is gekoppeld aan SQL Server
Wanneer u een koppeling configureert tussen SQL Server en Azure SQL Managed Instance, worden automatische back-ups van volledige en transactielogboeken gemaakt op het beheerde exemplaar, ongeacht of deze de primaire rol heeft. Er worden momenteel echter geen differentiële back-ups gemaakt, wanneer dit kan leiden tot langere hersteltijden dan verwacht.
Verhoogd aantal systeemaanmeldingen dat wordt gebruikt voor transactionele replicatie
De Azure SQL Managed Instance-service maakt systeemaanmelding voor transactionele replicatie. Deze aanmelding vindt u in SSMS (in Objectverkenner, onder Security, Logins) of in de systeemweergave sys.syslogins. De indeling van de aanmeldingsnaam ziet eruit als 'DBxCy\WF-abcde01234QWERT'en de aanmelding heeft een openbare serverfunctie. Onder bepaalde voorwaarden wordt deze aanmelding opnieuw gemaakt en wordt deze niet verwijderd vanwege een fout in de vorige aanmelding van het systeem. Dit kan leiden tot een verhoogd aantal aanmeldingen. Deze aanmeldingen vormen geen beveiligingsrisico. Ze kunnen veilig worden genegeerd. Deze aanmeldingen mogen niet worden verwijderd omdat er ten minste één van deze wordt gebruikt voor transactionele replicatie.
Microsoft Entra-aanmeldingen en -gebruikers worden niet ondersteund in SSDT
SQL Server Data Tools bieden geen volledige ondersteuning voor Microsoft Entra-aanmeldingen en -gebruikers.
Imitatie van Microsoft Entra-aanmeldingstypen wordt niet ondersteund
Imitatie met behulp van EXECUTE AS USER of EXECUTE AS LOGIN van de volgende Microsoft Entra-principals wordt niet ondersteund:
- Microsoft Entra-gebruikers met een alias. De volgende fout wordt in dit geval geretourneerd:
15517. - Microsoft Entra-aanmeldingen en -gebruikers gebaseerd op Microsoft Entra-toepassingen of serviceprincipes. De volgende fouten worden in dit geval geretourneerd:
15517en15406.
Transactionele replicatie moet opnieuw worden geconfigureerd na geo-failover
Als transactionele replicatie is ingeschakeld voor een database in een failovergroep, moet de beheerder van SQL Managed Instance alle publicaties op de oude primaire server opschonen en opnieuw configureren op de nieuwe primaire server nadat een failover naar een andere regio plaatsvindt. Zie Replicationvoor meer informatie.
tempdb structuur en inhoud wordt opnieuw gecreëerd
De tempdb-database wordt altijd gesplitst in 12 gegevensbestanden en de bestandsstructuur kan niet worden gewijzigd. De maximale grootte per bestand kan niet worden gewijzigd en nieuwe bestanden kunnen niet worden toegevoegd aan tempdb. De tempdb-database wordt altijd opnieuw gemaakt als een lege database wanneer het exemplaar wordt gestart of een failover uitvoert, en wijzigingen die zijn aangebracht in tempdb worden niet behouden.
Foutenlogboeken blijven niet behouden
Foutlogboeken die beschikbaar zijn in SQL Managed Instance, blijven niet behouden en de grootte ervan is niet opgenomen in de maximale opslaglimiet. Foutlogboeken worden mogelijk automatisch gewist als er een failover optreedt. Er zijn mogelijk hiaten in de geschiedenis van het foutenlogboek, omdat SQL Managed Instance meerdere keren is verplaatst op verschillende virtuele machines.
Tijdelijke onbereikbaarheid van de instance via de failover groep listener tijdens een schaalbewerking.
Voor het schalen van een beheerd exemplaar moet het exemplaar soms worden verplaatst naar een ander virtueel cluster, samen met de bijbehorende dns-records die door de service worden onderhouden. Als het beheerde exemplaar deelneemt aan een failovergroep, wordt de DNS-record die overeenkomt met de bijbehorende listener voor failovergroepen (listener voor lezen/schrijven, als het exemplaar de huidige geo-primaire alleen-lezen-listener is, als het exemplaar de huidige geo-secundaire is) verplaatst naar het nieuwe virtuele cluster.
In het ontwerp van de huidige schaalbewerking worden de DNS-records van de listener verwijderd uit het oorspronkelijke virtuele cluster voordat het beheerde exemplaar zelf volledig wordt gemigreerd naar het nieuwe virtuele cluster, wat in sommige situaties kan leiden tot langere tijd waarin het IP-adres van het exemplaar niet kan worden omgezet met behulp van de listener. Gedurende deze tijd kan een SQL-client die probeert toegang te krijgen tot het exemplaar dat wordt geschaald met behulp van het listener-eindpunt aanmeldingsfouten verwachten met het volgende foutbericht: 'fout 40532: kan de server 'xxx.xxx.xxx.xxx' die is aangevraagd door de aanmelding, niet openen. De aanmelding is mislukt. (Microsoft SQL Server, Fout: 40532)".
Het probleem wordt opgelost door het opnieuw ontwerpen van schaalbewerkingen.
Opgelost
Tabel voor handmatige back-ups in msdb behoudt de gebruikersnaam niet
(opgelost in augustus 2023) We hebben onlangs ondersteuning geïntroduceerd voor automatische back-ups in msdb, maar de tabel bevat momenteel geen gebruikersnaamgegevens.
Query op externe tabel mislukt met niet-ondersteund foutbericht
Het uitvoeren van query's op externe tabellen kan mislukken met het algemene foutbericht 'Query's over externe tabellen worden niet ondersteund met de huidige servicelaag of het prestatieniveau van deze database. Overweeg om de servicelaag of het prestatieniveau van de database te upgraden. Het enige type externe tabel dat wordt ondersteund in Azure SQL Managed Instance, zijn externe PolyBase-tabellen (in preview). Als u query's op externe PolyBase-tabellen wilt toestaan, moet u PolyBase inschakelen op een beheerd exemplaar door sp_configure opdracht uit te voeren.
Externe tabellen met betrekking tot de Elastic Query-functie van Azure SQL Database worden niet ondersteund in SQL Managed Instance, en het maken en uitvoeren van queries op deze tabellen is niet expliciet geblokkeerd. Met ondersteuning voor PolyBase-externe tabellen zijn nieuwe controles geïntroduceerd, die query's van elk type externe tabel in een beheerde instantie blokkeren, tenzij PolyBase is ingeschakeld.
Als u externe tabellen voor niet-ondersteunde elastische query's gebruikt om query's uit te voeren op gegevens in Azure SQL Database of Azure Synapse vanuit uw beheerde exemplaar, moet u in plaats daarvan de functie Linked Server gebruiken. Volg de instructies uit dit artikelom een gekoppelde serververbinding tot stand te brengen vanuit SQL Managed Instance naar SQL Database. Als u een gekoppelde serververbinding tot stand wilt brengen van sql Managed Instance naar SQL Synapse, controleert u stapsgewijze instructies. Aangezien het configureren en testen van een gekoppelde serververbinding enige tijd in beslag neemt, kunt u een tijdelijke oplossing gebruiken om het uitvoeren van query's op externe tabellen met betrekking tot de functie Elastische query in te schakelen:
Workaround: voer de volgende opdrachten (eenmaal per exemplaar) uit waarmee query's op externe tabellen mogelijk worden gemaakt:
sp_configure 'polybase enabled', 1;
GO
RECONFIGURE;
GO
Bij het gebruik van SQL Server-verificatie worden gebruikersnamen met @niet ondersteund
Gebruikersnamen met het @-symbool in het midden (bijvoorbeeld 'abc@xy') kunnen zich niet aanmelden met BEHULP van SQL Server-verificatie.
Handmatige back-up herstellen zonder CHECKSUM kan mislukken
(Opgelost in juni 2020) In bepaalde gevallen kan het zijn dat een handmatige back-up van databases, die op een beheerd exemplaar zonder CHECKSUM is gemaakt, niet kan worden hersteld. In dergelijke gevallen probeert u de back-up opnieuw te herstellen totdat u slaagt.
tijdelijke oplossing: handmatige back-ups maken van databases op beheerde exemplaren waarvoor CHECKSUM is ingeschakeld.
Agent reageert niet meer bij het wijzigen, uitschakelen of inschakelen van bestaande taken
In bepaalde omstandigheden kan het wijzigen, uitschakelen of inschakelen van een bestaande taak ertoe leiden dat de agent niet meer reageert. Het probleem wordt automatisch verholpen bij detectie, wat resulteert in een herstart van het agentproces.
Machtigingen voor resourcegroep die niet zijn toegepast op SQL Managed Instance
Wanneer de Azure-rol 'SQL Managed Instance Contributor' wordt toegepast op een resourcegroep (RG), wordt deze niet op de SQL Managed Instance zelf toegepast en heeft dit geen effect.
Workaround: stel de SQL Managed Instance Contributor-rol in voor gebruikers op abonnementsniveau.
SQL Agent-taken kunnen worden onderbroken door opnieuw opstarten van agentproces
(opgelost in maart 2020) SQL Agent een nieuwe sessie maakt telkens wanneer een taak wordt gestart, waardoor het geheugenverbruik geleidelijk toeneemt. Om te voorkomen dat de interne geheugenlimiet wordt bereikt, waardoor de uitvoering van geplande taken wordt geblokkeerd, wordt het agentproces opnieuw gestart zodra het geheugenverbruik de drempelwaarde heeft bereikt. Dit kan ertoe leiden dat de uitvoering van taken die worden uitgevoerd op het moment van opnieuw opstarten wordt onderbroken.
@query parameter wordt niet ondersteund in sp_send_db_mail
De parameter @query in de sp_send_db_mail procedure werkt niet.
Misleidend fout bericht in het Azure-portaal dat suggereert om de service-principal opnieuw aan te maken
De Active Directory-beheerder-pagina voor Azure SQL Managed Instance op het Azure Portal kan het volgende foutbericht weergeven, ook al bestaat de Service Principal al:
'Managed Instance heeft een service-principal nodig voor toegang tot Microsoft Entra ID (voorheen Azure Active Directory). Klik hier om een service-principal te maken"
U kunt dit foutbericht negeren als service-principal voor het beheerde exemplaar al bestaat en/of Microsoft Entra-verificatie op het beheerde exemplaar werkt.
Als u wilt controleren of Service Principal bestaat, gaat u naar de pagina Bedrijfstoepassingen in de Azure Portal, kiest u Beheerde identiteiten in de vervolgkeuzelijst Applicatietype, selecteert u Toepassenen typt u de naam van de beheerde instantie in het zoekvak. Als de exemplaarnaam in de resultatenlijst verschijnt, bestaat de Service-Principal al en zijn er geen verdere acties nodig.
Als u de instructies uit het foutbericht al hebt gevolgd en de koppeling daarin hebt geselecteerd, is de Service Principal van het beheerde exemplaar opnieuw aangemaakt. Wijs in dat geval leesmachtigingen voor Microsoft Entra-id toe aan de zojuist gemaakte service-principal, zodat Microsoft Entra-verificatie goed werkt. U kunt dit doen via Azure PowerShell door instructieste volgen.
Bijdragen aan inhoud
Als u wilt bijdragen aan de Documentatie van Azure SQL, raadpleegt u de handleiding Docs-inzender.
Verwante inhoud
Zie sql Managed Instance-service-updatesvoor een lijst met updates en verbeteringen van SQL Managed Instance.
Zie Service-updatesvoor updates en verbeteringen van alle Azure-services.