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?

Bekende problemen

Heeft een tijdelijke oplossing

Backupperiode voor bewaren wijzigen bij het gratis aanbod

U kunt het bewaarbeleid voor back-ups van uw databases alleen wijzigen in het gratis met SQL beheerde exemplaar met behulp van REST API-, PowerShell - en Azure CLI-opdrachten . Het is niet mogelijk om het bewaarbeleid voor back-ups te wijzigen via Azure Portal.

Aanmelden bij lees-secundaire is mislukt vanwege een lange wachttijd op 'HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING'

Deze fout kan worden weergegeven als een uitzondering voor het Microsoft OLE DB-stuurprogramma 19 voor SQL Server wanneer u verbinding probeert te maken met een alleen-lezen secundaire replica van een failovergroep of een database die gerepliceerd wordt via de koppeling Beheerd exemplaar.

Deze fout treedt op wanneer de secundaire replica niet beschikbaar is voor aanmeldingen, omdat rijversies ontbreken voor transacties die in-flight waren toen een secundaire replica opnieuw werd opgestart, of gerecycled, voor onderhoud of vanwege een failover. Wanneer een exemplaar opnieuw wordt opgestart of een failover uitvoert, worden de versiegegevens die in tempdb zijn opgeslagen, gewist. Hierdoor worden secundaire leesquery's afgebroken als er langlopende actieve transacties zijn gestart vóór de failover of het opnieuw opstarten.

U kunt dit probleem oplossen door actieve transacties op de primaire replica terug te draaien of door te voeren. Om deze fout te voorkomen, minimaliseert u langlopende schrijftransacties op de primaire replica.

Tussentijdse richtlijnen voor tijdzone-updates voor Paraguay in 2024

Op 14 oktober 2024 kondigde de Regering van Paraguay een permanente wijziging aan in het tijdzonebeleid van het land. Paraguay blijft het hele jaar door op zomertijd (DST), waarbij UTC-3 effectief wordt gebruikt als standaardtijd. Als gevolg hiervan gaan klokken niet vooruit met 60 minuten om 12:00 uur op 23 maart 2025, zoals eerder was gepland. Deze wijziging is van invloed op de tijdzone Standard Time van Paraguay. Microsoft heeft gerelateerde Windows-updates uitgebracht in februari en maart 2025. Azure SQL Managed Instance weerspiegelt momenteel deze update niet. Exemplaren die de getroffen tijdzone gebruiken, weerspiegelen de wijzigingen pas nadat de Azure SQL Managed Instance-service de update op het niveau van het besturingssysteem absorbeert.

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.

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 koppelingsfunctie voor SQL Managed Instance:

Msg 8992, Level 16, State 1, Line <Line_Number>
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 om de database opnieuw te maken vanuit de Azure SQL Managed Instance-bron, neem dan contact op met de Microsoft-ondersteuning om dit probleem op te lossen.

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 met Azure SQL beheerd exemplaar op het 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-AzSqlInstanceDatabaseLongTermRetentionBackup of CLI-opdrachten az sql midb ltr-backup list en az sql midb ltr-backup delete gebruiken om langetermijnback-ups te beheren met behulp van de parameter DatabaseState en DatabaseDeletionTime retourwaarde om back-ups voor een database te filteren.

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

EXECUTE 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.
EXECUTE 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
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
    @principal_name = N'user_name',
    @profile_name = N'profile_name',
    @is_default = 0;
GO

Gedistribueerde transacties kunnen worden uitgevoerd nadat u sql managed instance uit de serververtrouwensgroep hebt 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 met SQL beheerde exemplaar hebt verwijderd uit de serververtrouwensgroep 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 SQL-exemplaar .

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 ziet:

Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.

Als u dit foutbericht hebt aangetroffen, selecteert u het en volgt u de stapsgewijze instructies die worden opgegeven totdat deze fout is opgelost.

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 instructie, een migratieproces van de Data Migration Service en ingebouwd herstel naar een bepaald tijdstip, blokkeert het bijwerken van de servicelaag, het wijzigen van het formaat van het bestaande exemplaar en het maken van nieuwe exemplaren 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 een leesbare secundaire replica dient na een failover opnieuw te worden geconfigureerd

De resource governor-functie waarmee u de resources die zijn toegewezen aan de gebruikersworkload kunt beperken, kan sommige gebruikersworkloads 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 of als onderdeel van een SQL Agent-taak uit die de SQL-taak uitvoert wanneer de leesbare secundaire replica 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.

Service Broker-dialogen tussen databases stoppen met het afleveren van berichten aan de services in andere databases na het wijzigen van de serviceniveau. 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 het exemplaar de Azure Storage-limiet voor de servicelaag Algemeen gebruik kan bereiken, maar niet de upgrade van de servicelaag Next-gen Algemeen gebruik of de servicelaag Bedrijfskritiek.

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 met SQL 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 teruggegeven, 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.

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 volledige back-ups en transactielogboekback-ups gemaakt op het beheerde SQL-exemplaar, ongeacht of deze zich in de primaire rol bevinden. 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 teruggegeven: 15517.
• Microsoft Entra-aanmeldingen en -gebruikers gebaseerd op Microsoft Entra-toepassingen of serviceprincipes. De volgende fouten worden in dit geval geretourneerd: 15517 en 15406.

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.

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.

Opgelost

Het wijzigen van het verbindingstype heeft geen invloed op verbindingen via het eindpunt van de failovergroep

(Opgelost in november 2025)

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 onbereikbaarheid van de instance via de failover groep listener tijdens een schaalbewerking.

(Opgelost in april 2025)

Voor het schalen van een met SQL 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 SQL-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 SQL-exemplaar zelf volledig wordt gemigreerd naar het nieuwe virtuele cluster, wat in sommige gevallen 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:

Error 40532: Cannot open server "xxx.xxx.xxx.xxx" requested by the login. The login failed. (Microsoft SQL Server, Error: 40532).

Het probleem wordt opgelost door het opnieuw ontwerpen van schaalbewerkingen.

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.

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 omstandigheden kan handmatige back-up van databases die zijn gemaakt op een met SQL beheerd exemplaar zonder CHECKSUM, mogelijk niet worden hersteld. In dergelijke gevallen probeert u de back-up opnieuw te herstellen totdat u slaagt.

Tijdelijke oplossing: Maak handmatige back-ups van databases op met SQL beheerde exemplaren waarvoor CHECKSUM is ingeschakeld.

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.

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 needs a Service Principal to access Microsoft Entra ID ([formerly Azure Active Directory](/entra/fundamentals/new-name)). Click here to create a Service Principal

U kunt dit foutbericht negeren als service-principal voor het beheerde SQL-exemplaar al bestaat en/of Microsoft Entra-verificatie op het beheerde SQL-exemplaar werkt.

Als u wilt controleren of service-principal bestaat, gaat u naar de pagina Bedrijfstoepassingen in Azure Portal, kiest u Beheerde identiteiten in de vervolgkeuzelijst Toepassingstype , selecteert u Toepassen en typt u de naam van het beheerde SQL-exemplaar 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 uit het foutbericht hebt geselecteerd, is de service-principal van het beheerde SQL-exemplaar opnieuw gemaakt. 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.

Het event_file doel van de system_health-gebeurtenissessie is niet toegankelijk

(Gedeeltelijk opgelost in mei 2025) 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.

Oorspronkelijk is dit probleem opgetreden in SQL Server Management Studio (SSMS) of bij het lezen van de sessiegegevens met behulp van de sys.fn_xe_file_target_read_file-functie .

In mei 2025 is dit probleem opgelost voor het lezen van sessiegegevens van SSMS. Het probleem wordt niet opgelost bij het lezen van gebeurtenisgegevens met behulp van de sys.fn_xe_file_target_read_file functie.

Deze wijziging in gedrag is een onbedoeld gevolg van een vereiste beveiligingsoplossing. Klanten kunnen 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.

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.