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:

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_descsys.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 az event_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:

  1. 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.
  2. 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.
  3. Ha tömeges beszúrásokat hajt végre a segédprogram vagy az bcp.exeSystem.Data.SqlClient.SqlBulkCopy osztály használatával, próbálja meg -b batchsizeBatchSize korlátozni a kiszolgálóra másolt sorok számát az egyes tranzakciókban. További információ: bcp Utility.
  4. Ha az utasítással ALTER INDEX újraépít egy indexet, használja a , ONLINE = ONés RESUMABLE=ON a SORT_IN_TEMPDB = ONbeá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