Řešení potíží s připojením a dalších chyb

Platí pro:Azure SQL Database Azure SQL Managed InstanceSQL Database v rámci Fabric

Při selhání připojení ke službě Azure SQL Database, databázi SQL v Microsoft Fabric nebo službě Azure SQL Managed Instance se zobrazí chybové zprávy.

Jako vždy používejte osvědčené postupy a pokyny k návrhu aplikace .

Poznámka:

Pomocí nástroje Azure SQL Connectivity Checker můžete zjišťovat a opravovat širokou škálu chyb připojení.

Postup řešení běžných potíží s připojením

  1. Ujistěte se, že je na aplikačním serveru povolený protokol TCP/IP jako klientský protokol. Na aplikačních serverech, kde nemáte nainstalované SQL nástroje, ověřte, zda je povolen protokol TCP/IP spuštěním programu cliconfg.exe (klientský síťový nástroj SQL Server).

  2. Zkontrolujte připojovací řetězec aplikace a ujistěte se, že je správně nakonfigurovaná. Ujistěte se například, že připojovací řetězec určuje správný port (1433) a plně kvalifikovaný název serveru. Viz Získání informací o připojení pomocí aplikace SQL Server Management Studio.

  3. Zkuste zvýšit hodnotu časového limitu připojení. Doporučujeme použít časový limit připojení nejméně 30 sekund.

  4. Otestujte připojení mezi aplikačním serverem a datovou službou Azure SQL Database pomocí Quickstart: Použití SSMS pro připojení a dotazování na Azure SQL Database nebo Azure SQL Managed Instance, souboru UDL, příkazu ping nebo telnetu. Další informace najdete v tématu Řešení potíží s připojením a diagnostika problémů s připojením.

    Poznámka:

    Jako krok pro řešení potíží můžete také otestovat připojení na jiném klientském počítači.

  5. Osvědčeným postupem je, že aplikace připojené ke cloudu musí používat logiku opakování.

Pokud tyto kroky váš problém nevyřeší, zkuste shromáždit další data a kontaktovat podporu. Pokud je vaše aplikace cloudová služba, povolte protokolování. Tento krok vrátí časové razítko UTC selhání. Další informace o povolení protokolování najdete v tématu Povolení protokolování diagnostiky pro aplikace ve službě Aplikace Azure Service. Sql Database navíc vrátí ID trasování. Tyto informace můžou využívat služby zákaznické podpory Microsoftu.

Selhání připojení způsobená vlastními přepisy v souborech DNS nebo hosts.

Pokud má vaše aplikace trvalé selhání přihlášení (chyby 18456, 40532 nebo 40615), které jsou izolované na konkrétní klientské sítě, zatímco služba Azure SQL je funkční, příčinou může být vlastní konfigurace DNS, která připojuje plně kvalifikovaný název domény serveru na zastaralou IP adresu Azure SQL brány.

Proč se to stane

Azure SQL Database používá flotilu regionálních bran. Azure pravidelně vyřadí a nahradí brány v rámci normálních operací, včetně aktualizace hardwaru, škálování a migrace řízené stavem. Autoritativní DNS Azure pro <server>.database.windows.net se automaticky aktualizuje tak, aby odrážely aktuální aktivní brány.

Když vaše prostředí přepíše toto rozlišení DNS (prostřednictvím položky souboru hostitelů, statického CNAME záznamu nebo privátní zóny DNS, která mapuje plně kvalifikovaný název domény serveru na konkrétní IP adresu), klient se k této IP adrese připne. Pokud se brána na této IP adrese později vyřadí nebo znovu přiřadí, připojení přejdou na nesprávný koncový bod. Brána Azure SQL ověří příchozí FQDN na cílovém serveru a při nesouladu způsobí selhání přihlášení.

Important

Pokusy o přihlášení, které vedou přímo k IP adrese (nebo k zastaralé IP adrese přes obcházení DNS), jsou navrženy tak, aby selhaly. Brána Azure SQL ke směrování připojení k zamýšlenému serveru vyžaduje správný FQDN (plně kvalifikovaný název domény).

Detekovat přepsání DNS

Z ovlivněného klienta spusťte následující kontroly.

  1. Zkontrolujte přepsání v souboru místních hostitelů:

    :: Windows
type C:\Windows\System32\drivers\etc\hosts | findstr /i "database.windows.net"

    # Linux or macOS
grep -i "database.windows.net" /etc/hosts

  2. Porovnání rozlišení DNS klienta s autoritativním DNS Azure.

    :: Client or recursive resolver
nslookup <server>.database.windows.net

:: Authoritative public DNS
nslookup <server>.database.windows.net 208.67.222.222

    # PowerShell
Resolve-DnsName -Name "<server>.database.windows.net" -DnsOnly

    Pokud klientský resolver vrátí jinou IP adresu než autoritativní DNS, je aktivní přepsání DNS.

  3. Zkontrolujte překrytí CNAME zóny nebo privátní DNS zóny.

    nslookup -type=CNAME <server>.database.windows.net

    az network private-dns record-set list \
  --resource-group <ResourceGroup> \
  --zone-name database.windows.net \
  --output table

Oprava přepsání

  1. Odeberte přepsání. Odstraňte položku souboru hostitelů, odeberte statický záznam CNAME nebo odstraňte privátní záznam DNS zóny, který připne FQDN serveru ke konkrétní IP adrese.

  2. Vyprázdněte mezipaměti DNS na klientovi a všechny zprostředkující překladače:

    :: Windows
ipconfig /flushdns

    # Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

  3. Ověřte, že se teď DNS překládá na aktuální bránu Azure:

    nslookup <server>.database.windows.net

    Ověřte, že vrácená IP adresa spadá do publikovaných rozsahů IP adres brány pro oblast vašeho serveru. Seznam najdete v části IP adresy brány v architektuře připojení.

  4. Znovu otestujte připojení pomocí nástroje Azure SQL Connectivity Checker nebo SQL Server Management Studio (SSMS).

Zabránit tomuto problému

  • Nikdy nepřipínejte plně kvalifikované názvy domén serveru Azure SQL na konkrétní IP adresy v souborech hostitelů, statických záznamech CNAME nebo privátních zónách DNS. Azure SQL brány jsou dynamické a v průběhu času se mění.
  • Pokud používáte seznamy povolených adres firewallu na základě IP adres brány, měli byste povolit všechny IP rozsahy bran pro vaši oblastí místo jednotlivých IP adres. Pokud je to možné, použijte Sql.<region> značku služby.
  • Pro privátní připojení místo přepsání DNS použijte Azure Private Link nebo privátní koncové body. Privátní koncové body poskytují stabilní privátní IP adresy ve vaší virtuální síti a směrují se přímo do brány.
  • Přihlaste se k odběru upozornění služby Service Health pro Azure SQL Database, abyste dostávali oznámení o migracích bran ve vaší oblasti.

Stručná referenční dokumentace

Příznak Pravděpodobná příčina Oprava
Selhání přihlášení (18456, 40532, 40615) omezena na konkrétní klientské sítě, zatímco stav služby je normální Soubor hostitelů nebo statický CNAME připne úplný název domény k vyřazené nebo nesprávné IP adrese brány. Odstraňte přepsání, vyprázdněte DNS, ověřte vyřešení a znovu otestujte.
nslookup vrátí IP adresu, která není v publikovaných rozsazích bran pro danou oblast. Přepsání DNS (soubor hostitelů, CNAME nebo privátní zóna DNS) je aktivní. Odeberte položku přepsání a vyprázdněte mezipaměti DNS.
Připojení fungují z některých sítí, ale z jiných selžou Na neaktuální IP adresu je připnuta pouze síť s přepsáním. Porovnejte řešení DNS na selhávajících a fungujících sítích a odstraňte přepsání na selhávající síti.
Připojení selže po oznámení o migraci brány Azure Statické mapování DNS stále odkazuje na vyřazenou bránu Odeberte statické mapování a povolte všechny rozsahy IP adres brány pro oblast.
Cannot open server nebo server not found po žádné změně konfigurace Rotace brány vyřadila IP adresu, která byla pevně zakódována v DNS. Odeberte přemapování DNS a použijte dynamické Azure autoritativní řešení.

Implementace logiky opakování

Důrazně doporučujeme použít ve vašich klientských aplikacích logiku pro opakování, která umožní znovu navázat připojení poté, co pomine přechodná chyba a dojde k jejímu vyřešení. Doporučujeme, abyste před prvním opakováním zpozdili 5 sekund. Pokud se opět pokusíte po zpoždění kratším než 5 sekund, hrozí riziko zahlcení cloudové služby. U každého dalšího opakování by se zpoždění mělo exponenciálně zvětšit až na 60 sekund.

Příklady kódu logiky opakování najdete tady:

Další informace o zpracování přechodných chyb připojení ve vaší aplikaci naleznete v části Řešení problémů s přechodnými chybami připojení.

Diskuze o době blokování pro klienty, kteří používají ADO.NET, je k dispozici ve správě fondu připojení (ADO.NET).

Přechodné chybové zprávy (40197, 40613 a další)

Když ve službě SQL Database dojde k vysokému zatížení, infrastruktura Azure dokáže dynamicky rekonfigurovat servery. Toto dynamické chování může způsobit, že váš klientský program ztratí připojení k databázi nebo instanci. Tento druh chybového stavu se nazývá přechodná chyba. K událostem rekonfigurace databáze dochází kvůli plánovaným událostem (např. upgrade softwaru) nebo neplánovaným událostem (např. chybové ukončení procesu nebo vyrovnávání zatížení). Většina událostí rekonfigurace je krátkodobá a měla by být dokončena maximálně za 60 sekund. Dokončení těchto událostí však může občas trvat delší dobu, například když velká transakce způsobí dlouhotrvající obnovení. Následující tabulka uvádí různé přechodné chyby, které můžou aplikace obdržet při připojování ke službě Azure SQL Database.

Seznam kódů přechodných chyb

Kód chyby Závažnost Popis
926 14 Database 'replicatedmaster' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server error log for more information.

Tato chyba může být zaznamenána do protokolu chyb služby SQL Managed Instance na krátkou dobu během závěrečné fáze rekonfigurace, zatímco starý primární uzel uzavírá svůj protokol.
Jiné nepřehledné scénáře zahrnující tuto chybovou zprávu jsou popsány v dokumentaci k chybám MSSQL.
4060 16 Cannot open database "%.&#x2a;ls" requested by the login. The login failed.

Další informace naleznete v tématu Chyby 4000 až 4999
40197 17 The service has encountered an error processing your request. Please try again. Error code %d.

Tato chyba se zobrazí, když je služba nefunkční kvůli upgradům softwaru nebo hardwaru, selháním hardwaru nebo jiným problémům s obnovením služeb. Kód chyby (%d) vložený do zprávy chyby 40197 poskytuje další informace o druhu selhání nebo přepnutí v případě selhání, k němuž došlo. Některé příklady kódů chyb jsou vloženy do zprávy chyby 40197 jsou 40020, 40143, 40166 a 40540.
Opětovným připojením se automaticky připojíte ke správné kopii databáze. Aplikace musí zachytit chybu 40197, protokolovat vložený kód chyby (%d) ve zprávě pro řešení potíží a pokusit se znovu připojit k SQL Database, dokud nebudou prostředky k dispozici a vaše připojení se znovu nevytvoří. Další informace najdete v části Přechodné chyby.
40501 20 The service is currently busy. Retry the request after 10 seconds. Incident ID: %ls. Code: %d.

Další informace najdete tady: .
• Správa prostředků.
• Limity prostředků pro elastické fondy využívající nákupní model DTU
• Omezení založená na virtuálních jádrech pro izolované databáze.
• Omezení založená na virtuálních jádrech pro elastické pooly.
• Limity prostředků služby Azure SQL Managed Instance
40613 17 Database '%.&#x2a;ls' on server '%.&#x2a;ls' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them with the session tracing ID of '%.&#x2a;ls'.

K této chybě může dojít, pokud už existuje existující vyhrazené připojení správce (DAC) vytvořené k databázi. Další informace najdete v části Přechodné chyby.
49918 16 Cannot process request. Not enough resources to process request. The service is currently busy. Please retry the request later.

Další informace najdete tady: .
• Správa prostředků.
• Limity prostředků pro elastické fondy využívající nákupní model DTU
• Omezení založená na virtuálních jádrech pro izolované databáze.
• Omezení založená na virtuálních jádrech pro elastické pooly.
• Limity prostředků služby Azure SQL Managed Instance
49919 16 Cannot process create or update request. Too many create or update operations in progress for subscription "%ld".

Služba je zaneprázdněna zpracováním více žádostí o vytvoření nebo aktualizaci pro vaše předplatné nebo server. Žádosti jsou aktuálně blokované pro optimalizaci prostředků. Dotaz sys.dm_operation_status pro čekající operace. Počkejte, než budou dokončeny probíhající žádosti o vytvoření nebo aktualizaci, nebo smažte jednu z čekajících žádostí a zkuste to znovu později. Pokud se zdá, že jsou vaše operace zablokované, počkejte na dokončení dalších probíhajících operací nebo je v případě potřeby zrušte. Můžete například zrušit kopírování databáze nebo vytvoření geografické repliky odstraněním vytvářené databáze nebo repliky. Pokud se nepodaří zrušit zdánlivě zablokovanou operaci, otevřete žádost o podporu u Microsoftu.
49920 16 Cannot process request. Too many operations in progress for subscription "%ld".

Služba je zaneprázdněna zpracováním více požadavků pro toto předplatné. Žádosti jsou aktuálně blokované pro optimalizaci prostředků. Dotaz sys.dm_operation_status pro stav operace. Počkejte na dokončení čekajících požadavků nebo odstraňte některý z čekajících požadavků a zkuste žádost zopakovat později. Pokud se zdá, že jsou vaše operace zablokované, počkejte na dokončení dalších probíhajících operací nebo je v případě potřeby zrušte. Můžete například zrušit kopírování databáze nebo vytvoření geografické repliky odstraněním vytvářené databáze nebo repliky. Pokud se nepodaří zrušit zdánlivě zablokovanou operaci, otevřete žádost o podporu u Microsoftu.
4221 16 Login to read-secondary failed due to long wait on 'HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING'.

Replika není k dispozici pro přihlášení, protože verze řádků chybí pro transakce, které byly v testovacím prostředí při recyklaci repliky. Tento problém lze vyřešit vrácením zpět nebo potvrzením aktivních transakcí na primární replice. Výskyty této podmínky je možné minimalizovat tím, že se v primárním počítači zabrání dlouhým transakcím zápisu.
615 21 Could not find database ID %d, name '%.&#x2a;ls'

To znamená, že mezipaměť v paměti se nesynchronizuje s instancí SQL Serveru a vyhledávání načítají zastaralé ID databáze.

Přihlašovací údaje SQL používají mezipaměť v paměti k mapování názvů databází na ID. Mezipaměť by se měla synchronizovat s back-endovou databází a aktualizovat ji vždy, když dojde k připojení a odpojení databáze k instanci SERVERU SQL.
Tato chyba se zobrazí, když se při pracovním postupu odpojení nepodaří včas vyčistit mezipaměť v paměti a následné dotazy do databáze ukazují na zastaralé ID databáze.
Zkuste se znovu připojit k SQL Database, dokud nebudou prostředky k dispozici a připojení nebude znovu navázáno. Další informace najdete v části Přechodné chyby.

Postup řešení přechodných problémů s připojením

  1. Na řídicím panelu služby Microsoft Azure zkontrolujte případné známé výpadky, ke kterým došlo během doby, během které aplikace hlásí.
  2. Aplikace, které se připojují ke cloudové službě, jako je Azure SQL Database, by měly očekávat pravidelné události rekonfigurace a implementovat logiku opětovných pokusů, která tyto chyby zpracuje, místo toho, aby zobrazovaly uživatelům chyby aplikace.
  3. Vzhledem k tomu, že databáze přistupuje k limitům prostředků, může se zdát, že se jedná o přechodný problém s připojením. Viz Omezení prostředků.
  4. Pokud potíže s připojením budou pokračovat nebo pokud doba trvání, po kterou se u vaší aplikace zobrazí chyba, překročí 60 sekund nebo pokud se v daném dni zobrazí více výskytů chyby, vytvořte podpora Azure žádost výběrem možnosti Získat podporu na webu podpory Azure.

K tomuto problému dochází, pokud se aplikace nemůže připojit k serveru.

Pokud chcete tento problém vyřešit, vyzkoušejte kroky (v uvedeném pořadí) v části Kroky k opravě běžných problémů s připojením.

Server nebo instance nebyla nalezena nebo nebyla přístupná (chyby 26, 40, 10053)

Chyba 26: Chyba při vyhledání zadaného serveru

System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections.(provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)

Chyba 40: Nepodařilo se otevřít připojení k serveru

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

Chyba 10053: Při příjmu výsledků ze serveru došlo k chybě na úrovni přenosu

10053: A transport-level error has occurred when receiving results from the server. (Provider: TCP Provider, error: 0 - An established connection was aborted by the software in your host machine)

K těmto problémům dochází v případě, že se aplikace nemůže připojit k serveru.

Pokud chcete tyto problémy vyřešit, vyzkoušejte kroky (v uvedeném pořadí) v části Kroky a opravte běžné problémy s připojením.

Nejde se připojit k serveru kvůli problémům s bránou firewall

Chyba 40615: Nejde se připojit k < názvu serveru >

Pokud chcete tento problém vyřešit, nakonfigurujte nastavení brány firewall ve službě SQL Database prostřednictvím webu Azure Portal.

Chyba 5: Nejde se připojit k < názvu serveru >

Pro vyřešení tohoto problému se ujistěte, že je port 1433 otevřený pro odchozí připojení na všech firewallech mezi klientem a internetem.

Nejde se přihlásit k serveru (chyby 18456, 40531)

Přihlášení uživatele uživatelské< jméno >se nezdařilo.

Login failed for user '<User name>'.This session has been assigned a tracing ID of '<Tracing ID>'. Provide this tracing ID to customer support when you need assistance. (Microsoft SQL Server, Error: 18456)

Pokud chcete tento problém vyřešit, požádejte správce služeb, aby vám poskytl platné uživatelské jméno a heslo.

Správce služby obvykle může pomocí následujícího postupu přidat přihlašovací údaje:

  1. Přihlaste se k serveru pomocí aplikace SQL Server Management Studio (SSMS).

  2. Pokud chcete zkontrolovat, jestli je přihlašovací jméno zakázané, spusťte v master databázi následující dotaz SQL:

    SELECT name, is_disabled FROM sys.sql_logins;

  3. Pokud je odpovídající název zakázaný, můžete se rozhodnout ho povolit pomocí následujícího příkazu:

    ALTER LOGIN <User name> ENABLE;

  4. Pokud přihlašovací uživatelské jméno SQL neexistuje, upravte a spusťte následující dotaz SQL a vytvořte nové přihlášení SQL:

    CREATE LOGIN <SQL_login_name, sysname, login_name>
WITH PASSWORD = '<password, sysname, Change_Password>';
GO

  5. V nástroji SSMS Průzkumník objektů rozbalte položku Databáze.

  6. Vyberte databázi, ke které chcete uživateli udělit oprávnění.

  7. Klepněte pravým tlačítkem myši na položku Zabezpečení a potom vyberte Nový, Uživatel.

  8. Ve vygenerovaném skriptu s využitím zástupných symbolů pomocí kroků nahraďte parametry šablony SSMS a spusťte jej, například:

    CREATE USER [<user_name, sysname, user_name>]
FOR LOGIN [<login_name, sysname, login_name>]
WITH DEFAULT_SCHEMA = [<default_schema, sysname, dbo>];
GO

-- Add user to the database owner role
EXEC sp_addrolemember N'db_owner', N'<user_name, sysname, user_name>';
GO

    Můžete také použít sp_addrolemember k mapování konkrétních uživatelů na konkrétní databázové role.

    Poznámka:

    Ve službě Azure SQL Database zvažte novější syntaxi ALTER ROLE pro správu členství v rolích databáze.

Další informace naleznete v tématu Autorizace přístupu k databázi.

Chyby, ke kterým došlo při vypršení časového limitu připojení

System.Data.SqlClient.SqlException (0x80131904): Vypršel časový limit připojení

System.Data.SqlClient.SqlException (0x80131904): Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=3; handshake=29995;

System.Data.SqlClient.SqlException (0x80131904): Vypršel časový limit

System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

System.Data.Entity.Core.EntityException: Základní zprostředkovatel selhal při otevření

System.Data.Entity.Core.EntityException: The underlying provider failed on Open. -> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. -> System.ComponentModel.Win32Exception: The wait operation timed out

Nejde se připojit k < názvu serveru >

Cannot connect to <server name>.ADDITIONAL INFORMATION:Connection Timeout Expired. The timeout period elapsed during the post-login phase. The connection could have timed out while waiting for server to complete the login process and respond; Or it could have timed out while attempting to create multiple active connections. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=231; handshake=983; [Login] initialization=0; authentication=0; [Post-Login] complete=13000; (Microsoft SQL Server, Error: -2) For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=-2&LinkId=20476 The wait operation timed out

K těmto výjimkám může dojít buď kvůli problémům s připojením nebo dotazem. Pokud chcete ověřit, že problémy s připojením způsobily tuto chybu, přečtěte si téma Potvrzení, jestli je chyba způsobená problémem s připojením.

K vypršení časového limitu připojení dochází, protože se aplikace nemůže připojit k serveru. Pokud chcete tento problém vyřešit, vyzkoušejte kroky (v uvedeném pořadí) v části Kroky k opravě běžných problémů s připojením.

Řešení potíží se selháním připojení privátního koncového bodu

Připojení k Azure SQL Database prostřednictvím privátního koncového bodu mohou selhat kvůli vypršení časového limitu připojení nebo chybám při handshake před přihlášením. Projděte si následující kroky v pořadí. Každý krok vyřeší odlišný režim selhání.

Krok 1: Ověření privátního koncového bodu a DNS záznamu

Ověřte, že je soukromý koncový bod nastaven a že se DNS překládá na soukromou IP adresu.

Zaškrtnutí Jak
Stav připojení privátního koncového bodu je schválen. Na portálu Azure přejděte na sql server a pak Networking>Private access.
Privátní IP adresa je přidělená Otevřete prostředek privátního koncového bodu a na stránce Přehled si poznamenejte IP adresu (například 10.0.1.4).
DNS se překládá na privátní IP adresu. Spusťte nslookup <server>.database.windows.net. Výsledek musí sledovat řetězec CNAME k <server>.privatelink.database.windows.net a rozlišit na privátní IP adresu. Pokud se místo toho zobrazí veřejná IP adresa, zkontrolujte privátní zónu privatelink.database.windows.net DNS nebo pravidla podmíněného předávání.

Krok 2: Přidání pravidla brány firewall na úrovni serveru pro výchozí IP adresu

I u privátního koncového bodu Azure SQL Database stále vynucuje pravidla brány firewall protokolu IP na úrovni serveru vůči zdrojové IP adrese, kterou brána vidí.

  1. Identifikujte výchozí IP adresu. Pro místní provoz směrovaný přes bránu VPN nebo ExpressRoute je výchozí IP adresa obvykle bránou nebo privátní IP adresou překladu adres (NAT) uvnitř virtuální sítě. Z Azure se jedná o privátní IP adresu virtuálního počítače nebo front-endovou IP adresu nástroje pro vyrovnávání zatížení.

  2. Přidejte pravidlo brány firewall na úrovni serveru pro danou IP adresu nebo podsíť:

    EXECUTE sp_set_firewall_rule
    @name = N'AllowPrivateEndpointSubnet',
    @start_ip_address = '10.0.1.0',
    @end_ip_address = '10.0.1.255';

Poznámka:

Přepínač Povolit službám a prostředkům Azure přístup k tomuto serveru nepokrývá provoz, který přichází z vaší vlastní virtuální sítě prostřednictvím privátního koncového bodu. Musíte přidat explicitní pravidlo.

Krok 3: Otevřete správné porty na perimetrických nebo místních firewallech

Požadované porty závisí na zásadách připojení:

Zásady připojení Porty, které chcete povolit Notes
Redirect (výchozí hodnota uvnitř Azure) 1433 - 65535 (příchozí do virtuální sítě privátního koncového bodu a odchozí z klientské virtuální sítě) Po počátečním handshaku na 1433 je klient přesměrován na port ve vyšším rozsahu. Pokud jsou vysoké porty zablokované, handshake proběhne úspěšně, ale časový limit vyprší při přesměrování.
Proxy (výchozí mimo Azure) 1433 pouze Veškerý provoz prochází bránou na portu 1433. Pravidla brány firewall jsou jednodušší, ale latence je vyšší.
Výchozí Řídí se výše uvedenými pravidly. Uvnitř Azure jsou zásady připojení Redirect. Mimo Azure je to Proxy.

Pokud je připojení úspěšné z virtuální sítě, ale selže z lokální sítě, lokální firewall patrně blokuje vyšší porty v rozsahu 1433-65535. Otevřete rozsah portů nebo změňte zásady připojení serveru na Proxy. Další informace najdete v tématu Použití zásad přesměrování připojení s privátními koncovými body.

Krok 4: Ověření symetrického směrování pro scénáře UDR, NVA a překladu adres (NAT)

Pokud provoz do privátního koncového bodu SQL prochází síťovým virtuálním zařízením,Azure Firewall nebo bránou NAT Gateway, musí návratový provoz dodržovat stejnou cestu. Asymetrické směrování způsobuje resetování protokolu TCP nebo tiché poklesy.

Klíčová fakta:

  • Azure vytvoří systémovou trasu /32 pro každou IP adresu privátního koncového bodu (například 10.0.1.4/32 s typem následného směru InterfaceEndpoints). Trasa definovaná uživatelem může systémovou trasu přepsat pouze předponou, která je stejná nebo konkrétnější (například jiná /32).

  • Pokud směrujete odchozí provoz do síťového virtuálního zařízení, síťové virtuální zařízení musí použít překlad zdrojových síťových adres (SNAT), aby se pakety vrátily zpět do síťového virtuálního zařízení, a ne přímo do klienta. Bez SNAT je návratová cesta asymetrická.

  • Zásady sítě privátních koncových bodů (podpora skupin zabezpečení sítě (NSG) a tras definovaných uživatelem (UDR) v podsíti privátního koncového bodu) jsou ve výchozím nastavení zakázané. Pokud chcete u provozu privátního koncového bodu použít pravidla skupiny zabezpečení sítě nebo trasy definované uživatelem, povolte v podsíti síťové zásady:

    az network vnet subnet update \
  --name <SubnetName> \
  --vnet-name <VNetName> \
  --resource-group <ResourceGroup> \
  --private-endpoint-network-policies Enabled

Pokud připojení funguje bez NVA, ale při směrování přes NVA vyprší časový limit, /32 systémová trasa odesílá zpětný provoz přímo klientovi a vynechává tabulku stavu NVA. Přidejte UDR pro IP adresu privátního koncového bodu, která ukazuje na NVA, a povolte SNAT na NVA.

Krok 5: Ověření kompletního připojení pomocí Network Watcher

Pokud předchozí kroky vypadají správně, ale připojení stále selžou, použijte k izolaci selhání Azure Network Watcher:

Nástroj Co vám to řekne
Řešení potíží s připojením Testuje připojení TCP z virtuálního počítače k virtuálnímu <server>.database.windows.net:1433 počítači a hlásí selhání připojení (NSG, trasa nebo DNS).
Další skok Ukazuje, kterou položku směrovací tabulky následuje paket do IP adresy soukromého koncového bodu. Potvrzuje, zda je platná systémová trasa /32 nebo trasa definovaná uživatelem.
Efektivní trasy Zobrazí sloučenou směrovací tabulku síťové karty virtuálního počítače, včetně systémových tras pro privátní koncové body (další typ skoku InterfaceEndpoints).

Stručná referenční dokumentace

Příznak Pravděpodobná příčina Oprava
nslookup vrátí veřejnou IP adresu. Chybně nakonfigurovaná zóna DNS nebo podmíněné předávání Vytvořte nebo propojte privátní DNS zónu privatelink.database.windows.net a ověřte podmíněný směrovač.
Cannot open server "nenalezena nebo není přístupná" Pro výchozí IP adresu chybí pravidlo brány firewall na úrovni serveru. Přidejte pravidlo firewallu pro zdrojovou IP adresu s sp_set_firewall_rule nebo to proveďte na portálu.
Handshake uspěje a poté dojde k vypršení časového limitu Přesměrování vyšších portů (nad 1433, až 65535) je blokováno firewallem v místním prostředí. Otevřete úplný 1433-65535 rozsah nebo přepněte zásady připojení na Proxy.
Připojení funguje bez síťového virtuálního zařízení, ale s ním vyprší časový limit. Asymetrické směrování. Síťové virtuální zařízení nepoužívá SNAT nebo chybí přepsání UDR /32. Přidejte /32 uživatelsky definovanou trasu směřující k NVA, povolte SNAT na NVA a povolte zásady sítě pro privátní koncové body.
Přerušované resetování protokolu TCP NSG (skupina zabezpečení sítě) v podsíti privátního koncového bodu blokuje návratový provoz nebo zásady sítě privátních koncových bodů nejsou povolené. Povolte síťové zásady privátních koncových bodů a zkontrolujte pravidla NSG.

Chyby ukončení síťového připojení

Klientské knihovny SQL se připojují ke službě Azure SQL Database a azure SQL Managed Instance pomocí síťového protokolu TCP. Klientská knihovna používá ke správě připojení TCP komponentu nižší úrovně, která se nazývá zprostředkovatel TCP. Když zprostředkovatel PROTOKOLU TCP zjistí, že vzdálený hostitel neočekávaně ukončí existující připojení TCP, klientská knihovna vyvolá chybu. Vzhledem k tomu, že se jedná o chybu klienta, a ne o chybu sql serveru, není zahrnuté žádné číslo chyby SQL. Místo toho je číslo chyby 0 a použije se chybová zpráva od zprostředkovatele TCP.

Mezi příklady chyb ukončení síťového připojení patří:

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) An existing connection was forcibly closed by the remote host

A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

The client was unable to establish a connection because of an error during connection initialization process before login. Possible causes include the following: the client tried to connect to an unsupported version of SQL Server; the server was too busy to accept new connections; or there was a resource limitation (insufficient memory or maximum allowed connections) on the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

A connection was successfully established with the server, but then an error occurred during the login process. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

K chybám při ukončení připojení může dojít, pokud je databáze nebo elastický pool dočasně nedostupný. Dochází k nim také z důvodu různých problémů v síťové infrastruktuře mezi databázovým serverem a klientskou aplikací, včetně bran firewall, síťových zařízení atd. Tyto problémy můžou být přechodné nebo trvalé. Obecně platí, že aplikace by měly před zvážením trvalých selhání použít pevný počet pokusů o opakování těchto chyb.

Chyby zásad správného řízení prostředků

Azure SQL Database používá implementaci zásad správného řízení prostředků založenou na správci prostředků k vynucení limitů prostředků. Přečtěte si další informace o správě prostředků ve službě Azure SQL Database.

Nejběžnější chyby zásad správného řízení prostředků jsou uvedené jako první s podrobnostmi a za nimi následuje tabulka chybových zpráv zásad správného řízení prostředků.

Chyby 10928 a 10936: ID prostředku: 1. Limit požadavků pro [databázi nebo elastický fond] je %d a byl dosažen.

Pokud dosáhnete limitu na úrovni databáze, zobrazí se podrobná chybová zpráva v tomto případě: Resource ID : 1. The request limit for the database is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance.

Pokud dosáhnete limitu elastického fondu, zobrazí se podrobná chybová zpráva v tomto případě: Resource ID : 1. The request limit for the elastic pool is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance. Limity elastického fondu jsou vyšší než limity databáze. Další informace najdete v tématu Správa prostředků ve službě Azure SQL Database. Může dojít k limitům, když více databází ve fondu používá prostředek (například pracovních prostředků) souběžně.

Tato chybová zpráva označuje, že byl dosažen limit počtu pracovníků pro databázi nebo elastickou skupinu. Místo zástupného symbolu %d bude k dispozici maximální hodnota souběžných pracovních procesů pro cíl služby databáze nebo elastického fondu.

Poznámka:

Počáteční nabídka služby Azure SQL Database podporovala pouze dotazy s jedním vláknem. V té době byl počet žádostí vždy ekvivalentní počtu pracovníků. Chybové zprávy 10928 a 10936 v Azure SQL Database obsahují formulaci "Limit požadavku [...] je N a bylo dosaženo" pro účely zpětné kompatibility. Dosažený limit ve skutečnosti představuje počet pracovníků. Pokud je nastavení maximálního stupně paralelismu (MAXDOP) rovno nule nebo větší než jedna, může být počet pracovních procesů mnohem vyšší než kolik je požadavků, a limit může být dosažen mnohem dříve, než když se nastavená hodnota MAXDOP rovná jednomu.

Přečtěte si další informace o relacích, pracovních pracovníkech a požadavcích.

V případě potřeby se připojte pomocí Vyhrazeného Správního Připojení (DAC).

Jestliže je aktivní událost, kde je dosažen limit pracovníků, může se při připojení pomocí aplikace SQL Server Management Studio (SSMS) zobrazit chyba 10928. Jedna relace se může připojit pomocí diagnostické připojení pro správce databáze (DAC), i když byl dosažen limit pracovníků.

Vytvoření připojení k DAC z aplikace SSMS:

  • V nabídce vyberte Soubor > Nový > dotaz databázového enginu.
  • V dialogovém okně připojení v poli Název serveru zadejte admin:<fully_qualified_server_name> (například admin:servername.database.windows.net).
  • Vybrat možnosti >>
  • Vyberte kartu Vlastnosti připojení
  • Do pole Připojit k databázi: zadejte název databáze.
  • Vyberte Připojit.

Pokud se zobrazí chyba 40613, Database '%.&#x2a;ls' on server '%.&#x2a;ls' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of '%.&#x2a;ls'může to znamenat, že k DAC je již připojena jiná relace. K DAC se může najednou připojit pouze jedna relace pro jednu databázi nebo elastický fond.

Pokud po výběru možnosti Připojit dojde k chybě 'Nepodařilo se připojit k serveru', může být relace DAC přesto úspěšně navázána, pokud používáte verzi SSMS starší než 18.9. Dřívější verze aplikace SSMS se pokusily poskytnout IntelliSense pro připojení k DAC. To se nezdařilo, protože DAC podporuje pouze jeden pracovní proces a IntelliSense vyžaduje samostatný pracovní proces.

V SSMS nemůžete použít DAC připojení s Průzkumníkem objektů.

Vyhodnoťte využití max_worker_percent

Chcete-li zjistit statistiku spotřeby prostředků pro vaši databázi po dobu 14 dnů, proveďte dotaz na zobrazení sys.resource_stats systémového katalogu. Sloupec max_worker_percent zobrazuje procento pracovníků použitých vzhledem k limitu pracovníků pro vaši databázi. Připojte se k databázi na logickém master serveru a odešlete dotaz sys.resource_stats.

SELECT start_time, end_time, database_name, sku, avg_cpu_percent, max_worker_percent, max_session_percent 
FROM sys.resource_stats;

Ze sys.dm_db_resource_stats zobrazení dynamické správy můžete také dotazovat statistiky o spotřebě prostředků z poslední hodiny. Připojte se přímo k databázi a dotazujte se sys.dm_db_resource_stats.

SELECT end_time, avg_cpu_percent, max_worker_percent, max_session_percent
FROM sys.dm_db_resource_stats;

Snižte využití pracovníků, pokud je to možné

Blokující řetězce můžou způsobit náhlý nárůst počtu pracovníků v databázi. Velký objem souběžných paralelních dotazů může způsobit velký počet pracovních procesů. Zvýšení maximálního stupně paralelismu (MAXDOP) nebo nastavení MAXDOP na nulu může zvýšit počet aktivních pracovních procesů.

Při řešení incidentu s nedostatečnými pracovníky postupujte následovně:

  1. Prozkoumejte, jestli k blokování dochází nebo jestli můžete identifikovat velký objem souběžných pracovních procesů. Spuštěním následujícího dotazu zkontrolujte aktuální požadavky a zkontrolujte blokování, když databáze vrací chybu 10928. Možná se budete muset připojit pomocí vyhrazeného připojení správce (DAC) ke spuštění dotazu.

    SELECT
    r.session_id, r.request_id, r.blocking_session_id, r.start_time, 
    r.status, r.command, DB_NAME(r.database_id) AS database_name,
    (SELECT COUNT(*) 
        FROM sys.dm_os_tasks AS t 
        WHERE t.session_id=r.session_id and t.request_id=r.request_id) AS worker_count,
    i.parameters, i.event_info AS input_buffer,
    r.last_wait_type, r.open_transaction_count, r.total_elapsed_time, r.cpu_time,
    r.logical_reads, r.writes, s.login_time, s.login_name, s.program_name, s.host_name
FROM sys.dm_exec_requests as r
JOIN sys.dm_exec_sessions as s on r.session_id=s.session_id
OUTER APPLY sys.dm_exec_input_buffer (r.session_id,r.request_id) AS i
WHERE s.is_user_process=1;
GO

    1. Vyhledejte řádky s blocking_session_id, abyste identifikovali blokované relace. Vyhledejte každé blocking_session_id v seznamu, abyste zjistili, zda je daná relace také blokovaná. Sledování hodnot blocking_session_idsession_id vás nakonec povede k hlavnímu blokování: relace, která není blokovaná, ale blokuje. Vylaďte dotaz head blockeru.

      Návod

      Podrobnější informace o řešení potíží s dlouhotrvajícími nebo blokujícími dotazy najdete v tématu Vysvětlení a řešení problémů s blokováním.

    2. Pokud chcete identifikovat velký objem souběžných pracovních procesů, zkontrolujte celkový počet požadavků a worker_count sloupec pro každý požadavek. Worker_count je počet pracovníků v okamžiku vzorkování a během provádění požadavku se může v průběhu času měnit. Vylaďte dotazy, aby se snížilo využití prostředků, pokud příčinou zvýšeného počtu pracovníků jsou souběžné dotazy, které běží s optimální úrovní paralelismu. Další informace najdete v části Ladění dotazů a optimalizace.

  2. Vyhodnoťte maximální stupeň paralelismu (MAXDOP) pro databázi.

Zvýšení limitů pracovníků

Pokud databáze nebo elastický fond konzistentně dosáhne svého limitu pracovního procesu i přes blokování, optimalizaci dotazů a ověření nastavení MAXDOP, zvažte vertikální navýšení kapacity databáze nebo elastického fondu, abyste zvýšili limit pracovního procesu.

Vyhledejte limity prostředků pro Azure SQL Database podle úrovně služby a velikosti výpočetních prostředků:

Zjistěte více o správě prostředků pracovníků v Azure SQL Database.

Chyba 10929: ID prostředku: 1

10929: Resource ID: 1. The %s minimum guarantee is %d, maximum limit is %d and the current usage for the database is %d. However, the server is currently too busy to support requests greater than %d for this database. See http://go.microsoft.com/fwlink/?LinkId=267637 for assistance. Otherwise, please try again later.

Chyba 40501: Služba je momentálně zaneprázdněná

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: %ls. Code: %d.

Chyba 40501 je chyba omezení systému, která značí překročení zdrojových limitů.

Další informace o omezeních prostředků najdete v tématu Správa prostředků ve službě Azure SQL Database.

Chyba 40544: Databáze dosáhla kvóty velikosti

40544: The database has reached its size quota. Partition or delete data, drop indexes, or consult the documentation for possible resolutions. Incident ID: <ID>. Code: <code>.

K této chybě dochází v případě, že databáze dosáhla kvóty velikosti.

Následující kroky vám můžou pomoct vyřešit problém nebo vám poskytnout další možnosti:

  1. Zkontrolujte aktuální velikost databáze pomocí řídicího panelu na webu Azure Portal.

    Poznámka:

    Pokud chcete zjistit, které tabulky spotřebovávají nejvíce místa, a proto jsou potenciálními kandidáty na vyčištění, spusťte následující dotaz SQL:

    SELECT o.name,
 SUM(p.row_count) AS 'Row Count',
 SUM(p.reserved_page_count) * 8.0 / 1024 AS 'Table Size (MB)'
FROM sys.objects o
JOIN sys.dm_db_partition_stats p on p.object_id = o.object_id
GROUP BY o.name
ORDER BY [Table Size (MB)] DESC;
GO

  2. Pokud aktuální velikost nepřekračuje maximální podporovanou velikost pro vaši edici, můžete pomocí příkazu ALTER DATABASE zvětšit nastavení MAXSIZE.

  3. Pokud už databáze přesahuje maximální podporovanou velikost vaší edice, zkuste provést jeden nebo několik následujících kroků:

    • Proveďte běžné aktivity čištění databáze. Například vyčistěte nežádoucí data pomocí zkrácení nebo odstranění nebo přesunutí dat pomocí služby Služby Integrace SQL Serveru (SSIS) nebo nástroje pro hromadné kopírování (bcp).
    • Rozdělte nebo odstraňte data, odstraňte indexy nebo navštivte dokumentaci pro možná řešení.
    • Informace o škálování databáze najdete v tématu Škálování prostředků izolované databáze a Škálování prostředků elastického fondu.

Chyba 40549: Relace je ukončena, protože máte dlouhotrvající transakci

40549: Session is terminated because you have a long-running transaction. Try shortening your transaction.

Pokud se opakovaně setkáte s touto chybou, zkuste problém vyřešit pomocí následujícího postupu:

  1. Spusťte následující dotaz a zobrazte všechny otevřené relace, které mají vysokou hodnotu ve sloupci duration_ms.

    SELECT
    r.start_time, DATEDIFF(ms,start_time, SYSDATETIME()) as duration_ms, 
    r.session_id, r.request_id, r.blocking_session_id,  
    r.status, r.command, DB_NAME(r.database_id) AS database_name,
    i.parameters, i.event_info AS input_buffer,
    r.last_wait_type, r.open_transaction_count, r.total_elapsed_time, r.cpu_time,
    r.logical_reads, r.writes, s.login_time, s.login_name, s.program_name, s.host_name
FROM sys.dm_exec_requests as r
JOIN sys.dm_exec_sessions as s on r.session_id=s.session_id
OUTER APPLY sys.dm_exec_input_buffer (r.session_id,r.request_id) AS i
WHERE s.is_user_process=1
ORDER BY start_time ASC;
GO

    Řádky, ve kterých sloupec input_buffer zobrazuje dotaz čtený z sys.fn_MSxe_read_event_stream, můžete ignorovat: tyto požadavky souvisejí s relacemi rozšířených událostí.

  2. blocking_session_id Zkontrolujte sloupec a zjistěte, jestli blokování přispívá k dlouhotrvajícím transakcím.

    Poznámka:

    Další informace o řešení potíží s blokováním ve službě Azure SQL Database najdete v tématu Vysvětlení a řešení blokujících problémů.

  3. Zvažte dávkování dotazů. Informace o dávkování najdete v tématu Použití dávkování ke zlepšení výkonu aplikace Azure SQL Database a Azure SQL Managed Instance.

Chyba 40551: Relace byla ukončena kvůli nadměrnému využití databáze tempdb.

40551: The session has been terminated because of excessive TEMPDB usage. Try modifying your query to reduce the temporary table space usage.

Chcete-li tento problém vyřešit, postupujte takto:

  1. Změňte dotazy tak, aby se snížilo využití dočasného prostoru tabulky.
  2. Dočasné objekty odstraňte, jakmile už je nepotřebujete.
  3. Ořízte tabulky nebo odeberte nepoužívané tabulky.

Chyba 40552: Relace byla ukončena kvůli nadměrnému využití místa v protokolu transakcí

40552: The session has been terminated because of excessive transaction log space usage. Try modifying fewer rows in a single transaction.

Při řešení tohoto problému zkuste použít následující metody:

Chyba 40553: Relace byla ukončena kvůli nadměrnému využití paměti

40553: The session has been terminated because of excessive memory usage. Try modifying your query to process fewer rows.

Pokud chcete tento problém obejít, zkuste dotaz optimalizovat.

Podrobný postup řešení potíží najdete v tématu Je můj dotaz v cloudu v pořádku?

Další informace o dalších chybách nedostatku paměti a ukázkových dotazech najdete v tématu Řešení chyb nedostatku paměti ve službě Azure SQL Database.

Tabulka chybových zpráv správy prostředků

Kód chyby Závažnost Popis
10928 20 Resource ID: %d. The %s limit for the database is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance.

ID prostředku označuje prostředek, který dosáhl limitu. Když je ID zdroje = 1, znamená to, že bylo dosaženo limitu počtu pracovníků. Další informace najdete v tématu Chyba 10928: ID prostředku 1. Limit požadavků pro databázi je %d a tento limit již byl dosažen. Pokud je ID prostředku = 2, znamená to, že bylo dosaženo limitu relace.
Další informace o limitech prostředků:
• Správa prostředků ve službě Azure SQL Database
• Limity prostředků pro nákupní model DTU
• Omezení založená na virtuálních jádrech pro izolované databáze.
• Limity prostředků služby Azure SQL Managed Instance
10936 20 Resource ID: %d. The %s limit for the elastic pool is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance.

ID prostředku označuje prostředek, který dosáhl limitu. Když je ID zdroje = 1, znamená to, že bylo dosaženo limitu počtu pracovníků. Další informace najdete v chybě 10936: ID prostředku: 1. Limit požadavku pro elastický fond je %d a byl dosažen.< a1/>. Pokud je ID prostředku = 2, znamená to, že limit relace byl dosažen.
Další informace o limitech prostředků:
• Správa prostředků ve službě Azure SQL Database
• Limity prostředků pro elastické fondy využívající nákupní model DTU
• Omezení založená na virtuálních jádrech pro elastické pooly.
• Limity prostředků služby Azure SQL Managed Instance
10929 20 Resource ID: %d. The %s minimum guarantee is %d, maximum limit is %d, and the current usage for the database is %d. However, the server is currently too busy to support requests greater than %d for this database.

ID prostředku označuje prostředek, který dosáhl limitu. Pro pracovní vlákna je ID prostředku = 1. Pro relace je identifikátor prostředku = 2. Další informace najdete tady: .
• Správa prostředků ve službě Azure SQL Database
• Limity prostředků pro elastické fondy využívající nákupní model DTU
• Omezení založená na virtuálních jádrech pro izolované databáze.
• Omezení založená na virtuálních jádrech pro elastické pooly.
• Limity prostředků služby Azure SQL Managed Instance
V opačném případě zkuste to znovu později.
40544 20 The database has reached its size quota. Partition or delete data, drop indexes, or consult the documentation for possible resolutions.

Informace o škálování databáze najdete v tématu Škálování prostředků izolované databáze a Škálování prostředků elastického fondu.
40549 16 Session is terminated because you have a long-running transaction. Try shortening your transaction.

Informace o dávkování najdete v tématu Použití dávkování ke zlepšení výkonu aplikace Azure SQL Database a Azure SQL Managed Instance.
40550 16 The session has been terminated because it has acquired too many locks. Try reading or modifying fewer rows in a single transaction.

Informace o dávkování najdete v tématu Použití dávkování ke zlepšení výkonu aplikace Azure SQL Database a Azure SQL Managed Instance.
40551 16 The session has been terminated because of excessive tempdb usage. Try modifying your query to reduce the temporary table space usage.

Pokud používáte dočasné objekty, šetřete místo v tempdb databázi odstraňováním dočasných objektů poté, co je sezení již nepotřebuje. Další informace o tempdb omezeních ve službě SQL Database najdete v tématu Databáze tempdb ve službě SQL Database.
40552 16 The session has been terminated because of excessive transaction log space usage. Try modifying fewer rows in a single transaction.

Informace o dávkování najdete v tématu Použití dávkování ke zlepšení výkonu aplikace Azure SQL Database a Azure SQL Managed Instance.
Pokud provádíte hromadné vkládání pomocí bcp.exe nástroje nebo System.Data.SqlClient.SqlBulkCopy třídy, zkuste použít -b batchsize nebo BatchSize možnosti omezit počet řádků zkopírovaných na server v každé transakci. Pokud znovu sestavíte index pomocí ALTER INDEX příkazu, zkuste použít tuto REBUILD WITH ONLINE = ON možnost. Informace o velikostech transakčních protokolů pro model nákupu virtuálních jader najdete zde:
• Omezení založená na virtuálních jádrech pro izolované databáze.
• Omezení založená na virtuálních jádrech pro elastické pooly.
• Limity prostředků služby Azure SQL Managed Instance
40553 16 The session has been terminated because of excessive memory usage. Try modifying your query to process fewer rows.

Snížení počtu ORDER BY a GROUP BY operací v kódu Transact-SQL snižuje požadavky na paměť dotazu. Informace o škálování databáze najdete v tématu Škálování prostředků izolované databáze a Škálování prostředků elastického fondu. Další informace o chybách nedostatku paměti a ukázkových dotazech najdete v tématu Řešení chyb nedostatku paměti ve službě Azure SQL Database.

Chyby elastického fondu

Následující chyby souvisejí s vytvářením a používáním elastických fondů:

Kód chyby Závažnost Popis Nápravná akce
1132 17 The elastic pool has reached its storage limit. The storage usage for the elastic pool cannot exceed (%d) MBs.

Pokus o zápis dat do databáze při dosažení limitu úložiště elastického fondu Informace o limitech prostředků najdete tady:
• Limity prostředků pro elastické fondy využívající nákupní model DTU
• Omezení založená na virtuálních jádrech pro elastické pooly.
 Pokud je to možné, zvažte zvýšení DTU nebo přidání úložiště do elastického fondu, pokud je to možné, abyste zvýšili limit úložiště, snížili úložiště používané jednotlivými databázemi v rámci elastického fondu nebo z elastického fondu odebrali databáze. Informace o škálování elastického fondu najdete v tématu Škálování prostředků elastického fondu. Další informace o odebrání nepoužívaného místa z databází najdete v tématu Správa prostoru souborů pro databáze ve službě Azure SQL Database.
10929 16 The %s minimum guarantee is %d, maximum limit is %d, and the current usage for the database is %d. However, the server is currently too busy to support requests greater than %d for this database.

Informace o limitech prostředků najdete tady:
• Limity prostředků DTU pro elastické fondy
• Omezení založená na virtuálních jádrech pro elastické pooly.
V opačném případě zkuste to znovu později. DTU / vCore min na databázi; DTU / vCore max na databázi. Celkový počet souběžných pracovníků ve všech databázích v elastickém fondu se pokusil překročit limit fondu.		 Pokud je to možné, zvažte zvýšení DTU nebo virtuálních jader elastického fondu, abyste zvýšili limit pracovního procesu, nebo z elastického fondu odeberte databáze.
40844 16 Database '%ls' on Server '%ls' is a '%ls' edition database in an elastic pool and cannot have a continuous copy relationship. Není relevantní
40857 16 Elastic pool not found for server: '%ls', elastic pool name: '%ls'. Specified elastic pool does not exist in the specified server. Zadejte platný název elastického fondu.
40858 16 Elastic pool '%ls' already exists in server: '%ls'. Specified elastic pool already exists in the specified server. Zadejte nový název elastického fondu.
40859 16 Elastic pool does not support service tier '%ls'. Specified service tier is not supported for elastic pool provisioning. Zadejte správnou edici nebo nechte úroveň služby prázdnou, aby se použila výchozí úroveň služby.
40860 16 Elastic pool '%ls' and service objective '%ls' combination is invalid. Elastic pool and service tier can be specified together only if resource type is specified as 'ElasticPool'. Zadejte správnou kombinaci elastické skupiny a úrovně služby.
40861 16 The database edition '%.*ls' cannot be different than the elastic pool service tier which is '%.*ls'. The database edition is different than the elastic pool service tier. Nezadávejte edici databáze, která je odlišná od úrovně služby elastického fondu. Edici databáze není nutné zadávat.
40862 16 Elastic pool name must be specified if the elastic pool service objective is specified. Elastic pool service objective does not uniquely identify an elastic pool. Pokud používáte cíl služby elastického fondu, zadejte název elastického fondu.
40864 16 The DTUs for the elastic pool must be at least (%d) DTUs for service tier '%.*ls'. Attempting to set the DTUs for the elastic pool below the minimum limit. Zopakujte nastavení DTU elastického fondu na minimální limit.
40865 16 The DTUs for the elastic pool cannot exceed (%d) DTUs for service tier '%.*ls'. Attempting to set the DTUs for the elastic pool above the maximum limit. Zkuste znovu nastavit DTU pro fond s pružnou kapacitou tak, aby nepřesáhly maximální limit.
40867 16 The DTU max per database must be at least (%d) for service tier '%.*ls'. Attempting to set the DTU max per database below the supported limit. Zvažte použití úrovně služby elastického fondu, která podporuje požadované nastavení.
40868 16 The DTU max per database cannot exceed (%d) for service tier '%.*ls'. Attempting to set the DTU max per database beyond the supported limit. Zvažte použití úrovně služby elastického fondu, která podporuje požadované nastavení.
40870 16 The DTU min per database cannot exceed (%d) for service tier '%.*ls'. Attempting to set the DTU min per database beyond the supported limit. Zvažte použití úrovně služby elastického fondu, která podporuje požadované nastavení.
40873 16 The number of databases (%d) and DTU min per database (%d) cannot exceed the DTUs of the elastic pool (%d). Attempting to specify DTU min for databases in the elastic pool that exceeds the DTUs of the elastic pool. Zvažte zvýšení DTU elastického fondu nebo snížení minimálního počtu DTU na databázi nebo snížení počtu databází v elastickém fondu.
40877 16 An elastic pool cannot be deleted unless it does not contain any databases. The elastic pool contains one or more databases and therefore cannot be deleted. Odeberte databáze z elastického fondu, abyste je mohli odstranit.
40881 16 The elastic pool '%.*ls' has reached its database count limit. The database count limit for the elastic pool cannot exceed (%d) for an elastic pool with (%d) DTUs. Attempting to create or add database to elastic pool when the database count limit of the elastic pool has been reached. Pokud je to možné, zvažte zvýšení DTU elastického fondu, abyste zvýšili limit jeho databází, nebo odeberte databáze z elastického fondu.
40889 16 The DTUs or storage limit for the elastic pool '%.*ls' cannot be decreased since that would not provide sufficient storage space for its databases. Attempting to decrease the storage limit of the elastic pool below its storage usage. Zvažte snížení využití úložiště jednotlivých databází v elastickém fondu nebo odebrání databází z fondu, aby se snížil limit DTU nebo úložiště.
40891 16 The DTU min per database (%d) cannot exceed the DTU max per database (%d). Attempting to set the DTU min per database higher than the DTU max per database. Ujistěte se, že minimum DTU na databáze nepřekračuje maximální počet DTU na databázi.
TBD 16 The storage size for an individual database in an elastic pool cannot exceed the max size allowed by '%.*ls' service tier elastic pool. The max size for the database exceeds the max size allowed by the elastic pool service tier. Nastavte maximální velikost databáze v mezích maximální velikosti povolené úrovní služby elastického fondu.

Nelze otevřít databázi "master" požadovanou pro přihlášení. Přihlášení se nezdařilo.

K tomuto problému dochází, protože účet nemá oprávnění pro přístup master k databázi. Ve výchozím nastavení se ale SQL Server Management Studio (SSMS) pokusí připojit k master databázi.

Pokud chcete tento problém vyřešit, postupujte následovně:

  1. Na přihlašovací obrazovce aplikace SSMS vyberte Možnosti a pak vyberte Vlastnosti připojení.

  2. Do pole Připojit k databázi zadejte výchozí název databáze uživatele jako výchozí přihlašovací databázi a pak vyberte Připojit.

    Snímek obrazovky s dialogem Připojit v aplikaci SSMS, zobrazující kartu Vlastnosti připojení

Chyby při režimu pouze pro čtení

Pokud se pokusíte zapisovat do databáze, která je určená jen pro čtení, zobrazí se chyba. V některých scénářích nemusí být příčina stavu databáze jen pro čtení okamžitě jasná.

Chyba 3906: Nepodařilo se aktualizovat databázi database databaseName, protože databáze je jen pro čtení.

Při pokusu o úpravu databáze jen pro čtení se vyvolá následující chyba.

Msg 3906, Level 16, State 2, Line 1
Failed to update database "%d" because the database is read-only.

Existuje několik možných vysvětlení, proč je databáze určená jen pro čtení.

Po ručním převzetí služeb při selhání se aplikace stále připojují k původní repliky.

V Azure SQL Database se po přepnutí na jinou repliku může vaše aplikace stále připojovat k předchozí primární replice kvůli DNS. Směrování připojení skupiny převzetí služeb při selhání se implementuje pomocí DNS.

Potenciální původní příčiny:

  1. Během přepnutí při selhání se aktualizují koncové body skupiny, aby ukazovaly na nový primární a sekundární server změnou cíle příslušné položky DNS. Ve výchozím nastavení se položky DNS vytvářejí s hodnotou TTL 30 sekund, což znamená, že klienti DNS ukládají tyto položky do mezipaměti po dobu 30 sekund. V důsledku toho se aktualizace záznamů DNS nešírují okamžitě; položky budou zastaralé, dokud nebudou všichni klienti a zprostředkující uzly aktualizovat jejich mezipaměti. Proto může trvat od 0 do přibližně 10 minut (v závislosti na topologii sítě), než se přihlášení ke koncovým bodům skupiny převzetí služeb při selhání směrují do nových cílů po převzetí služeb při selhání. Vyprázdnění mezipamětí DNS může nebo nemusí pomoct s problémem, protože mezilehlé síťové uzly, které reagují na požadavky DNS, ukládají výsledky DNS do mezipaměti po určitou dobu.

    Doporučeným alternativním řešením tohoto problému je jednoduše počkat, až se položky DNS aktualizují v klientovi. V současné době by toto alternativní řešení vedlo k problému, který se vyřeší uvnitř 10 minut.

  2. Některé klientské knihovny SQL používají funkci označovanou jako sdružování připojení, která znovu používá připojení ke stejnému zdroji dat, místo aby je zavřela a znovu otevřela pokaždé, když je potřeba nové připojení k databázi. Konkrétně je sdružování připojení ve výchozím nastavení povolené ve ADO.NET. V kombinaci s problémem popsaným v 1 může sdružování připojení způsobit, že nově otevřená připojení znovu použijí připojení ke staré databázi, čímž zabrání aplikaci v připojení k nové primární databázi na neomezenou dobu.

Řešení:

Po převzetí služeb při selhání skupiny existují tři možná řešení tohoto problému DNS:

  1. Upravte aplikaci tak, aby volala SQLConnection.ClearAllPools nebo SQLConnection.ClearPool(conn) v případě výskytu chyby "jen pro čtení".
  2. V připojovacím řetězci aplikace určete Pooling=False pro zakázání sdružování připojení. To by mělo být otestováno, protože by to mohlo výrazně ovlivnit výkon, pokud aplikace často otevírá a zavírá připojení.
  3. Další možností, jak se vyhnout zpoždění replikace NEBO ukládání do mezipaměti DNS, je přímé připojení pomocí názvu logického serveru Azure SQL Database (původního sekundárního serveru, nyní nového primárního) v časovém intervalu po výskytu 3906.

Možná jste připojení k replice jen pro čtení.

U služby Azure SQL Database i Azure SQL Managed Instance můžete být připojeni k replice databáze jen pro čtení. V tomto případě vrátí následující dotaz pomocí funkceREAD_ONLYDATABASEPROPERTYEX():

SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability');
GO

Pokud se připojujete pomocí aplikace SQL Server Management Studio, ověřte, jestli jste zadali ApplicationIntent=ReadOnly na kartě Další připojovací parametrypřipojení.

Pokud je připojení z aplikace nebo klienta pomocí připojovacího řetězce, ověřte, jestli připojovací řetězec uvedl ApplicationIntent=ReadOnly. Další informace najdete v části Připojení k replice jen pro čtení.

Databáze může být nastavená jen pro čtení.

Pokud používáte Azure SQL Database, je možné, že samotná databáze byla nastavená na jen pro čtení. Stav databáze můžete ověřit pomocí následujícího dotazu:

SELECT name, is_read_only
FROM sys.databases
WHERE database_id = DB_ID();

Stav jen pro čtení pro databázi ve službě Azure SQL Database můžete upravit pomocí příkazu ALTER DATABASE Transact-SQL. Aktuálně nemůžete nastavit databázi ve spravované instanci na jen pro čtení.

Ověřte, jestli příčinou chyby je problém s připojením.

Pokud chcete zjistit, zda je příčinou chyby problém s připojením, zkontrolujte výpis zásobníku pro rámce, které ukazují volání k otevření připojení, například takovéto (věnujte pozornost odkazu na třídu SqlConnection).

System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
 at System.Data.SqlClient.SqlConnection.Open()
 at AzureConnectionTest.Program.Main(String[] args)
ClientConnectionId:<Client connection ID>

Když je výjimka vyvolána problémy s dotazem, všimnete si zásobníku volání, který se podobá následujícímu (je zde odkaz na třídu SqlCommand). V takovém případě vylaďte dotazy.

  at System.Data.SqlClient.SqlCommand.ExecuteReader()
  at AzureConnectionTest.Program.Main(String[] args)
  ClientConnectionId:<Client ID>

Další informace o vyladění výkonu najdete tady:

Související obsah

  • Last updated on