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 Instance en de oplossingsdatum of mogelijke tijdelijke oplossing. Zie het overzicht en wat er nieuw is voor meer informatie over Azure SQL Managed Instance.
Notitie
Microsoft Entra-id is de nieuwe naam voor Azure Active Directory (Azure AD). Op dit moment wordt de documentatie bijgewerkt.
Bekende problemen
Heeft een tijdelijke oplossing
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 sys.fn_xe_file_target_read_file-functie .
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 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 De system_health-sessie gebruiken voor meer informatie, waaronder een T-SQL-script om de system_health sessie te maken die kan worden gewijzigd om uw eigen equivalent te system_healthmaken.
Procedure sp_send_dbmail kan mislukken wanneer @query de parameter wordt gebruikt voor beheerde exemplaren met nov22FW
Procedure sp_send_dbmail kan mislukken wanneer @query de parameter wordt gebruikt en dit is van invloed op exemplaren waarvoor de functiegolf van november 2022 is ingeschakeld. Fouten treden op wanneer de opgeslagen procedure wordt uitgevoerd onder het sysadmin-account.
Dit probleem wordt veroorzaakt door een bekende fout met betrekking tot het sp_send_dbmail gebruik van imitatie.
Tijdelijke oplossing: zorg ervoor dat u aanroept sp_send_dbmail 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 maakte de Chileense regering een officiële aankondiging over een zomertijd (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 betreffende tijdzones voor uw beheerde exemplaren wilt wijzigen, moet u rekening houden met de beperkingen en de richtlijnen in de documentatie volgen.
Het wijzigen van het verbindingstype 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: Verwijder de failovergroep en maak deze opnieuw nadat u het verbindingstype hebt gewijzigd.
Procedure sp_send_dbmail tijdelijk kan mislukken wanneer @query de parameter wordt gebruikt
Procedure sp_send_dbmail kan tijdelijk mislukken wanneer @query de parameter wordt gebruikt. Wanneer dit probleem optreedt, mislukt elke tweede uitvoering van de procedure sp_send_dbmail met een fout Msg 22050, Level 16, State 1 en bericht Failed to initialize sqlcmd library with error number -2147467259. Als u deze fout goed 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 het sp_send_dbmail gebruik van imitatie en groepsgewijze verbindingen.
U kunt dit probleem omzeilen door code voor het verzenden van e-mail naar een logica voor opnieuw proberen die afhankelijk is van de uitvoerparameter @mailitem_id. Als de uitvoering mislukt, is de parameterwaarde NULL, waarmee wordt aangegeven sp_send_dbmail dat het nog één keer moet worden aangeroepen om een e-mailbericht te verzenden. Hier volgt een voorbeeld van deze logica voor opnieuw proberen.
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 niet worden uitgevoerd na de schaalbewerking van het beheerde exemplaar
Met SQL Managed Instance-schaalbewerkingen, waaronder het wijzigen van de servicelaag of het aantal vCores, worden de instellingen van de serververtrouwensgroep op de back-end opnieuw ingesteld en worden gedistribueerde transacties uitgeschakeld. Als tijdelijke oplossing verwijdert en maakt u een 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 <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 kan er een probleem zijn met service-principal die wordt gebruikt voor toegang tot Microsoft Entra ID-services (voorheen Azure Active Directory) en Azure Key Vault (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 met SQL beheerde exemplaar voordat u updateopdrachten uitvoert, of als u dit probleem al hebt ondervonden na updateopdrachten, gaat u naar Azure Portal, opent u de beheerpagina van SQL Managed Instance Active Directory. 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 dit 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: Start failover 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 vaste SQL Agent-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 werken. 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 de maximale geheugenlimieten toe voor objecten die zijn geoptimaliseerd voor geheugen. Met SQL Managed Instance kan werkbelasting meer geheugen gebruiken voor OLTP-bewerkingen in het geheugen, wat van invloed kan zijn op de beschikbaarheid en stabiliteit van het exemplaar. 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 limieten bereiken.
Tijdelijke oplossing: Bewaak het OLTP-opslaggebruik in het geheugen met behulp van SQL Server Management Studio om ervoor te zorgen dat de workload 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.
Fout geretourneerd tijdens het verwijderen van een bestand dat niet leeg is
Met SQL Server en SQL Managed Instance kan een gebruiker geen bestand verwijderen dat niet leeg is. Als u een niet-mptig 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 geretourneerd. Sql Managed Instance probeert het bestand te verwijderen en de bewerking mislukt na 30 minuten met Internal server error.
Servicelaag wijzigen en exemplaarbewerkingen maken worden geblokkeerd door doorlopende databaseherstel
Een doorlopende RESTORE instructie, een migratieproces van data migration service en ingebouwd herstel naar een bepaald tijdstip, blokkeert het bijwerken van een servicelaag of 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 exemplaren in exemplaargroepen worden niet beïnvloed. Bewerkingen in servicelagen maken of wijzigen mislukken niet of er treedt een time-out op. Ze gaan verder zodra het herstelproces is voltooid of geannuleerd.
Tijdelijke oplossing: wacht totdat 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 Bedrijfskritiek servicelaag moet mogelijk na een failover opnieuw worden geconfigureerd
De Resource Governor-functie waarmee u de resources die zijn toegewezen aan de gebruikersworkload kunt beperken, kan een aantal 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 deze regelmatig uit of als onderdeel van een SQL Agent-taak waarmee de SQL-taak wordt uitgevoerd wanneer het exemplaar wordt gestart als u Resource Governor gebruikt.
Dialoogvensters tussen databases van Service Broker moeten opnieuw worden geïnitialiseerd na de upgrade van de servicelaag
Dialoogvensters voor servicebroker tussen databases stoppen met het leveren van berichten aan de services in andere databases nadat de servicelaagbewerking is gewijzigd. De berichten gaan niet verloren en ze zijn te vinden in de wachtrij met afzenders. Elke wijziging van vCores of de opslaggrootte van exemplaren in SQL Managed Instance zorgt ervoor dat een waarde in de service_broke_guid weergave sys.databases voor alle databases wordt gewijzigd. Elke DIALOG gemaakt met behulp van een BEGIN DIALOG-instructie die verwijst naar Service Brokers in een andere database stopt met het leveren van berichten aan de doelservice.
Tijdelijke oplossing: stop alle activiteiten die gebruikmaken van dialoogvensters tussen databases en 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.
Opslagruimte overschrijden met kleine databasebestanden
CREATE DATABASE, ALTER DATABASE ADD FILEen RESTORE DATABASE instructies kunnen mislukken omdat het exemplaar 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. Schijfgrootten kunnen 128 GB, 256 GB, 512 GB, 1 TB of 4 TB zijn. De 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 geen 8 TB nodig heeft, de Azure-limiet van 35 TB voor opslaggrootte overschrijden vanwege de 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, kunt u proberen een aantal van de kleinere bestanden leeg te maken en te verwijderen met behulp van de DBCC SHRINKFILE-instructie of over te schakelen naar de Bedrijfskritieke laag, 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 de weergave om de werkelijke databasenaam op te lossen 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 verwijzen naar een huidig exemplaar, kunnen soms het IP-adres van een lokaal exemplaar niet omzetten. Deze fout is een tijdelijk probleem.
Transactiebereik op twee databases binnen hetzelfde exemplaar wordt niet ondersteund
(Opgelost in maart 2020) De TransactionScope klasse 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=mypassword;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=mypassword;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 sql Verbinding maken ion. ChangeDatabase(String) om een andere database te gebruiken in een verbindingscontext in plaats van twee verbindingen te gebruiken.
Geen oplossing
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 in de sectie Beveiliging, Aanmeldingen) of in de systeemweergave sys.syslogins. De indeling van de aanmeldingsnaam ziet er uit '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.
msdb tabel voor handmatige back-ups behoudt de gebruikersnaam niet
We hebben onlangs ondersteuning geïntroduceerd voor automatische back-ups, msdbmaar de tabel bevat momenteel geen gebruikersnaamgegevens.
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 EXECUTE AS USER of EXECUTE AS LOGIN van de volgende Microsoft Entra-principals wordt niet ondersteund:
- Aliased Microsoft Entra-gebruikers. De volgende fout wordt in dit geval geretourneerd:
15517. - Microsoft Entra-aanmeldingen en -gebruikers op basis van Microsoft Entra-toepassingen of service-principals. 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 Replicatie voor meer informatie.
tempdb structuur en inhoud wordt opnieuw gemaakt
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-overschakeling uitvoert en eventuele wijzigingen die zijn tempdb aangebracht, blijven 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 exemplaarontoegankelijkheid met behulp van de listener van de failovergroep tijdens het schalen
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 is, d.w.z. alleen-lezen-listener, 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 door de aanmelding is aangevraagd, niet openen. De aanmelding is mislukt. (Microsoft SQL Server, Fout: 40532)".
Het probleem wordt opgelost door het opnieuw ontwerpen van schaalbewerkingen.
Opgelost
Het uitvoeren van query's op een externe tabel mislukt met een 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. U kunt de servicelaag of het prestatieniveau van de database bijwerken.' 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 de opdracht uit te voeren sp_configure .
Externe tabellen met betrekking tot de functie Elastische query van Azure SQL Database worden niet ondersteund in SQL Managed Instance, maar het maken en opvragen van deze tabellen is niet expliciet geblokkeerd. Met ondersteuning voor externe PolyBase-tabellen zijn nieuwe controles geïntroduceerd, waardoor query's van elk type externe tabel in beheerde exemplaren worden geblokkeerd, 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 in dit artikel om verbinding te maken met een gekoppelde server van SQL Managed Instance naar SQL Database. Als u een gekoppelde serververbinding tot stand wilt brengen van SQL Managed Instance naar SQL Synapse, raadpleegt u de 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:
Tijdelijke oplossing: voer de volgende opdrachten (eenmaal per exemplaar) uit waarmee query's in externe tabellen worden ingeschakeld:
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
In bepaalde omstandigheden kan handmatige back-up worden gemaakt van databases die zijn gemaakt op een beheerd exemplaar zonder CHECKSUM, mogelijk niet hersteld. In dergelijke gevallen probeert u de back-up opnieuw te herstellen totdat u slaagt.
Tijdelijke oplossing: maak handmatige back-ups 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 opgelost 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 inzender van SQL Managed Instance wordt toegepast op een resourcegroep (RG), wordt deze niet toegepast op SQL Managed Instance en heeft dit geen effect.
Tijdelijke oplossing: stel de rol Inzender voor SQL Managed Instance in voor gebruikers op abonnementsniveau.
SQL Agent-taken kunnen worden onderbroken door opnieuw opstarten van agentproces
(Opgelost in maart 2020) SQL Agent maakt een nieuwe sessie 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 niet ondersteund in sp_send_db_mail
De @query parameter in de sp_send_db_mail procedure werkt niet.
Misleidend foutbericht in De Azure-portal die de recreatie van de service-principal voorstelt
Op de Active Directory-beheerpagina van Azure Portal voor Azure SQL Managed Instance kan het volgende foutbericht worden weergegeven, 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 Azure Portal, kiest u Beheerde identiteiten in de vervolgkeuzelijst Toepassingstype, selecteert u Toepassen en typt u de naam van het beheerde exemplaar in het zoekvak. Als de exemplaarnaam wordt weergegeven in de lijst met resultaten, 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 hebt geselecteerd in het foutbericht, is de service-principal van het beheerde 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 de instructies te volgen.
Bijdragen aan inhoud
Als u wilt bijdragen aan de Documentatie van Azure SQL, raadpleegt u de handleiding voor docs-inzenders.
Volgende stappen
Zie service-updates voor SQL Managed Instance voor een lijst met updates en verbeteringen van SQL Managed Instance.
Zie Service-updates voor updates en verbeteringen in alle Azure-services.