Tranzakciónapló-hibák elhárítása az Azure SQL Database-ben
A következőre vonatkozik: Azure SQL Database
A 9002-ben vagy a 40552-ben megjelenő hibaüzenetek akkor jelenhetnek meg, ha a tranzakciónapló megtelt, és nem tudja elfogadni az új tranzakciókat. Ezek a hibák akkor fordulnak elő, ha az Azure SQL Database által felügyelt adatbázis-tranzakciónapló túllépi a hely küszöbértékeit, és nem tudja folytatni a tranzakciók fogadását. Ezek a hibák hasonlóak az SQL Server teljes tranzakciónaplójával kapcsolatos problémákhoz, de az SQL Serverben, az Azure SQL Database-ben és a felügyelt Azure SQL-példányban eltérő megoldásokkal rendelkeznek.
Megjegyzés:
Ez a cikk az Azure SQL Database-ről szól. Az Azure SQL Database a Microsoft SQL Server adatbázismotor legújabb stabil verzióján alapul, így a tartalom nagy része hasonló, bár a hibaelhárítási lehetőségek és eszközök eltérhetnek az SQL Servertől.
A tranzakciónaplók felügyelt Azure SQL-példányban történő hibaelhárításáról további információt a tranzakciónaplók hibáinak elhárítása a felügyelt Azure SQL-példányban című témakörben talál.
Az SQL Server tranzakciónaplóinak hibaelhárításáról további információt a Teljes tranzakciós napló hibaelhárítása (SQL Server 9002-s hiba) című témakörben talál.
Automatikus biztonsági mentések és a tranzakciónapló
Az Azure SQL Database-ben a tranzakciónaplók biztonsági mentése automatikusan megtörténik. A gyakoriságról, a megőrzésről és további információkról az automatikus biztonsági mentések című témakörben olvashat.
A rendszer kezeli a szabad lemezterületet, az adatbázisfájl-növekedést és a fájlhelyet is, így a tranzakciónaplóval kapcsolatos problémák tipikus okai és megoldásai eltérnek az SQL Servertől.
Az SQL Serverhez hasonlóan az egyes adatbázisok tranzakciónaplója csonkolt, amikor egy napló biztonsági mentése sikeresen befejeződik. A csonkolás üres helyet hagy a naplófájlban, amelyet aztán új tranzakciókhoz használhat. Ha a naplófájl nem csonkolható a napló biztonsági másolatai által, a naplófájl az új tranzakciókhoz igazodik. Ha a naplófájl eléri a maximális korlátot az Azure SQL Database-ben, az új írási tranzakciók sikertelenek lesznek.
A tranzakciónaplók méretéről a következő témakörben olvashat bővebben:
- Az egyetlen adatbázis virtuális magra vonatkozó erőforráskorlátjaiért tekintse meg a virtuális mag vásárlási modelljét használó önálló adatbázisok erőforráskorlátait.
- A rugalmas készletek virtuálismag-erőforráskorlátairól a virtuális mag vásárlási modelljét használó rugalmas készletek erőforráskorlátait tekintheti meg.
- Az egyetlen adatbázishoz tartozó DTU-erőforráskorlátokat a DTU vásárlási modellel rendelkező önálló adatbázisok erőforráskorlátai között találhatja meg.
- A rugalmas készletek DTU-erőforráskorlátait a DTU-vásárlási modellel elérhető rugalmas készletek erőforráskorlátai között találhatja meg.
Tranzakciónapló csonkolásának megelőzése
Ha szeretné felderíteni, hogy mi akadályozza meg a napló csonkolását egy adott esetben, tekintse meg log_reuse_wait_desc
a következőt sys.databases
: . A napló újrafelhasználási várakozása tájékoztatja arról, hogy milyen feltételek vagy okok miatt akadályozza meg a tranzakciónaplót a rendszeres napló biztonsági mentése. For more information, see sys.databases (Transact-SQL).
SELECT [name], log_reuse_wait_desc FROM sys.databases;
Az Azure SQL Database esetében javasoljuk, hogy az adatbázis helyett egy adott felhasználói adatbázishoz csatlakozzon a master
lekérdezés végrehajtásához.
A következő értékek log_reuse_wait_desc
sys.databases
jelezhetik az adatbázis tranzakciónapló-csonkolásának okát:
log_reuse_wait_desc | Diagnosztika | Válasz szükséges |
---|---|---|
SEMMI | Tipikus állapot. Semmi sem blokkolja a napló csonkolását. | Nem. |
ELLENŐRZŐPONT | A napló csonkításához ellenőrzőpontra van szükség. Ritka. | Nincs szükség válaszra, hacsak nem tart fenn. Ha tartós, küldjön egy támogatási kérést az Azure ügyfélszolgálatához. |
NAPLÓ BIZTONSÁGI MENTÉSE | Napló biztonsági mentésre van szükség. | Nincs szükség válaszra, hacsak nem tart fenn. Ha tartós, küldjön egy támogatási kérést az Azure ügyfélszolgálatához. |
AKTÍV BIZTONSÁGI MENTÉS VAGY VISSZAÁLLÍTÁS | Az adatbázis biztonsági mentése folyamatban van. | Nincs szükség válaszra, hacsak nem tart fenn. Ha tartós, küldjön egy támogatási kérést az Azure ügyfélszolgálatához. |
AKTÍV TRANZAKCIÓ | Egy folyamatban lévő tranzakció megakadályozza a naplók csonkolását. | A naplófájl nem csonkítható aktív és/vagy nem véglegesített tranzakciók miatt. Lásd a következő szakaszt. |
REPLIKÁCIÓS | Az Azure SQL Database-ben ez akkor fordulhat elő, ha a módosítási adatrögzítés (CDC) engedélyezve van. | Sys.dm_cdc_errors lekérdezése és a hibák megoldása. Ha nem oldható fel, küldjön támogatási kérelmet az Azure ügyfélszolgálatának. |
AVAILABILITY_REPLICA | A másodlagos replika szinkronizálása folyamatban van. | Nincs szükség válaszra, hacsak nem tart fenn. Ha tartós, küldjön egy támogatási kérést az Azure ügyfélszolgálatához. |
Napló csonkolását megakadályozta egy aktív tranzakció
Az új tranzakciókat nem elfogadó tranzakciónaplók leggyakoribb forgatókönyve egy hosszú ideig futó vagy letiltott tranzakció.
Futtassa ezt a minta lekérdezést a nem véglegesített vagy aktív tranzakciók és azok tulajdonságainak megkereséséhez.
- A tranzakció tulajdonságaival kapcsolatos információkat adja vissza a sys.dm_tran_active_transactions.
- A munkamenet kapcsolati adatait adja vissza a sys.dm_exec_sessions.
- A sys.dm_exec_requests a kérelmek adatait adja vissza (aktív kérelmek esetén). Ez a lekérdezés a blokkolt munkamenetek azonosítására is használható, keresse meg a
request_blocked_by
. További információ: Gyűjtse össze a letiltó információkat. - Az aktuális kérés szövegét vagy bemeneti pufferszövegét adja vissza a sys.dm_exec_sql_text vagy sys.dm_exec_input_buffer DMV-k használatával. Ha a
text
mezősys.dm_exec_sql_text
által visszaadott adatok NULL értékűek, a kérelem nem aktív, de függőben lévő tranzakcióval rendelkezik. Ebben az esetben a mezősys.dm_exec_input_buffer
azevent_info
adatbázismotornak átadott utolsó utasítást tartalmazza.
SELECT [database_name] = db_name(s.database_id)
, tat.transaction_id, tat.transaction_begin_time, tst.session_id
, session_open_transaction_count = tst.open_transaction_count
, transaction_duration_s = datediff(s, tat.transaction_begin_time, sysdatetime())
, input_buffer = ib.event_info
, request_text = CASE WHEN r.statement_start_offset = 0 and r.statement_end_offset= 0 THEN left(est.text, 4000)
ELSE SUBSTRING ( est.[text], r.statement_start_offset/2 + 1,
CASE WHEN r.statement_end_offset = -1 THEN LEN (CONVERT(nvarchar(max), est.[text]))
ELSE r.statement_end_offset/2 - r.statement_start_offset/2 + 1
END ) END
, request_status = r.status
, request_blocked_by = r.blocking_session_id
, transaction_state = CASE tat.transaction_state
WHEN 0 THEN 'The transaction has not been completely initialized yet.'
WHEN 1 THEN 'The transaction has been initialized but has not started.'
WHEN 2 THEN 'The transaction is active - has not been committed or rolled back.'
WHEN 3 THEN 'The transaction has ended. This is used for read-only transactions.'
WHEN 4 THEN 'The commit process has been initiated on the distributed transaction. This is for distributed transactions only. The distributed transaction is still active but further processing cannot take place.'
WHEN 5 THEN 'The transaction is in a prepared state and waiting resolution.'
WHEN 6 THEN 'The transaction has been committed.'
WHEN 7 THEN 'The transaction is being rolled back.'
WHEN 8 THEN 'The transaction has been rolled back.' END
, transaction_name = tat.name
, azure_dtc_state --Applies to: Azure SQL Database only
= CASE tat.dtc_state
WHEN 1 THEN 'ACTIVE'
WHEN 2 THEN 'PREPARED'
WHEN 3 THEN 'COMMITTED'
WHEN 4 THEN 'ABORTED'
WHEN 5 THEN 'RECOVERED' END
, transaction_type = CASE tat.transaction_type WHEN 1 THEN 'Read/write transaction'
WHEN 2 THEN 'Read-only transaction'
WHEN 3 THEN 'System transaction'
WHEN 4 THEN 'Distributed transaction' END
, tst.is_user_transaction
, local_or_distributed = CASE tst.is_local WHEN 1 THEN 'Local transaction, not distributed' WHEN 0 THEN 'Distributed transaction or an enlisted bound session transaction.' END
, transaction_uow --for distributed transactions.
, s.login_time, s.host_name, s.program_name, s.client_interface_name, s.login_name, s.is_user_process
, session_cpu_time = s.cpu_time, session_logical_reads = s.logical_reads, session_reads = s.reads, session_writes = s.writes
, observed = sysdatetimeoffset()
FROM sys.dm_tran_active_transactions AS tat
INNER JOIN sys.dm_tran_session_transactions AS tst on tat.transaction_id = tst.transaction_id
INNER JOIN Sys.dm_exec_sessions AS s on s.session_id = tst.session_id
LEFT OUTER JOIN sys.dm_exec_requests AS r on r.session_id = s.session_id
CROSS APPLY sys.dm_exec_input_buffer(s.session_id, null) AS ib
OUTER APPLY sys.dm_exec_sql_text (r.sql_handle) AS est;
Fájlkezelés több hely felszabadításához
Ha a tranzakciónapló nem csonkolódik az Azure SQL Database rugalmas készleteiben, a rugalmas készlet számára szabad terület felszabadítása a megoldás része lehet. A gyökér feloldása esetén azonban a tranzakciónapló-fájl csonkolását blokkoló feltétel kulcs. Bizonyos esetekben a több lemezterület ideiglenes létrehozása lehetővé teszi a hosszú ideig futó tranzakciók befejezését, így a tranzakciónapló-fájl csonkolását megakadályozó feltételt normál tranzakciónapló-biztonsági mentéssel távolítja el. A szabad hely felszabadítása azonban csak átmeneti mentességet biztosíthat, amíg a tranzakciónapló újra meg nem nő.
Az adatbázisok és rugalmas készletek fájlterületének kezeléséről további információt az Azure SQL Database-ben található adatbázisok fájlterületének kezelése című témakörben talál.
40552-ös hiba: A munkamenet a tranzakciónapló túlzott kihasználtsága miatt megszakadt
40552: The session has been terminated because of excessive transaction log space usage. Try modifying fewer rows in a single transaction.
A hiba elhárításához próbálkozzon a következő módszerekkel:
- A probléma bármilyen DML-műveletben előfordulhat, például beszúrás, frissítés vagy törlés. A szükségtelen írások elkerülése érdekében tekintse át a tranzakciót. Próbálja meg csökkenteni az azonnal végrehajtott sorok számát kötegelés vagy több kisebb tranzakcióra való felosztás implementálásával. További információ: Az SQL Database-alkalmazások teljesítményének javítása kötegelés használatával.
- A probléma az index újraépítési műveletei miatt fordulhat elő. A probléma elkerülése érdekében győződjön meg arról, hogy a következő képlet igaz: (a táblázatban érintett sorok száma) megszorozva (a bájtokban frissített mező átlagos mérete + 80) < 2 gigabájt (GB). Nagy táblák esetén fontolja meg partíciók létrehozását és az indexkarbantartást csak a tábla egyes partícióinál. További információ: Particionált táblák és indexek létrehozása.
- Ha tömeges beszúrásokat hajt végre a segédprogram vagy az
bcp.exe
System.Data.SqlClient.SqlBulkCopy
osztály használatával, próbálja meg-b batchsize
BatchSize
korlátozni a kiszolgálóra másolt sorok számát az egyes tranzakciókban. További információ: bcp Utility. - Ha az utasítással
ALTER INDEX
újraépít egy indexet, használja a ,ONLINE = ON
ésRESUMABLE=ON
aSORT_IN_TEMPDB = ON
beállításokat. Az ismételhető indexek esetén gyakoribb a napló csonkolása. További információ: ALTER INDEX (Transact-SQL).
Megjegyzés:
További információ az erőforrás-szabályozási hibákról: Erőforrás-szabályozási hibák.
Következő lépések
- Az Azure SQL Database blokkolási problémáinak ismertetése és megoldása
- Az Azure SQL Database-zel és az Azure SQL Managed Instance-szel kapcsolatos csatlakozási problémák és egyéb hibák elhárítása
- Átmeneti kapcsolati hibák elhárítása az Azure SQL Database-ben és a felügyelt SQL-példányban
- Videó: Ajánlott adatbetöltési eljárások az Azure SQL Database-ben
Visszajelzés
https://aka.ms/ContentUserFeedback.
Hamarosan: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ:Visszajelzés küldése és megtekintése a következőhöz: