{"id":21119,"date":"2026-08-28T18:18:54","date_gmt":"2026-08-28T16:18:54","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-undo-logs-administrator-guide-technik\/"},"modified":"2026-08-28T18:18:54","modified_gmt":"2026-08-28T16:18:54","slug":"mariadb-undo-logs-administratorvejledning-teknik","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/mariadb-undo-logs-administrator-guide-technik\/","title":{"rendered":"MariaDB-undo-logfiler: Baggrundsviden for administratorer"},"content":{"rendered":"<p><strong>MariaDB Undo<\/strong> styrer, hvordan InnoDB gemmer gamle r\u00e6kkeversioner, udf\u00f8rer rollbacks sikkert og leverer konsistente l\u00e6seudsnit, mens skriveoperationer k\u00f8rer. Jeg viser, hvordan undo-logfiler samspiller med History List og Purge, hvorfor lange transaktioner binder hukommelse, og hvordan jeg begr\u00e6nser v\u00e6ksten i <strong>Fortryd<\/strong>-omr\u00e5der.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>MVCC<\/strong> og konsistente l\u00e6sninger: Undo gemmer gamle versioner, og l\u00e6sere blokerer ikke.<\/li>\n  <li><strong>Historikliste<\/strong>: Commits tilf\u00f8jer til historikken, mens \u00bbPurge\u00ab fjerner.<\/li>\n  <li><strong>Lange transaktioner<\/strong>: Bevarer gamle versioner, belaster hukommelsen og forl\u00e6nger ventetiderne.<\/li>\n  <li><strong>Konfiguration<\/strong>: Undo-tablespaces, purge-threads og truncate styrer v\u00e6ksten.<\/li>\n  <li><strong>Overv\u00e5gning<\/strong>: Kontroller tidligt historikl\u00e6ngden, transaktionsalderen og st\u00f8rrelsen p\u00e5 undo-logfilerne.<\/li>\n<\/ul>\n\n<h2>Hvordan Undo-logfiler muligg\u00f8r MVCC<\/h2>\n\n<p>Jeg begynder med det v\u00e6sentligste: Hver \u00e6ndring skriver den forrige version af linjen ind i <strong>Fortryd<\/strong>-Log, s\u00e5 et konsistent \u00f8jebliksbillede forbliver gyldigt. L\u00e6sere f\u00e5r adgang til den relevante \u00e6ldre version, mens skrivere gemmer nye data og opdaterer indekser; p\u00e5 den m\u00e5de forbliver <strong>Parallelisme<\/strong> h\u00f8jt. Linjer k\u00e6der sig sammen med deres forg\u00e6ngere, indtil Purge kan slette dem. Uden denne k\u00e6de ville rollbacks mangle, og l\u00e6sevisninger ville g\u00e5 i uorden. Netop her sl\u00e5r Undo bro mellem transaktionssikkerhed, isolation og p\u00e5lidelig l\u00e6seadgang.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb-serverraum-admin-5847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Undo-logfilerne interne struktur<\/h2>\n\n<p>Under overfladen skelner jeg prim\u00e6rt mellem to typer af \u00bbUndo\u00ab-funktioner: <em>Inds\u00e6t-Fortryd<\/em> og <em>Fortryd opdatering<\/em>. Insert-Undo g\u00f8r det muligt at fortryde inds\u00e6ttelser, der endnu ikke er bekr\u00e6ftet. Update-Undo bevarer \u00e6ldre versioner ved \u00e6ndringer eller sletningsmarkeringer, s\u00e5 snapshots fortsat fungerer. InnoDB markerer slettede r\u00e6kker i f\u00f8rste omgang kun som fjernede (Delete-Mark) og uds\u00e6tter den faktiske sletning, indtil intet snapshot l\u00e6ngere kan se dem. Denne adskillelse er afg\u00f8rende: Rollbacks har brug for pr\u00e6cise tidligere tilstande, mens konsistente l\u00e6sere skal finde en version, der logisk passer til deres starttidspunkt. Derfor henviser r\u00e6kker internt til den forrige version, og indekser indeholder supplerende oplysninger, s\u00e5 Purge senere kan rydde op i indeksposterne.<\/p>\n\n<h2>Historikliste, rydning og lagerplads<\/h2>\n\n<p>Efter hvert commit gemmes historiske \u00e6ndringer i den globale <strong>Historie<\/strong> Liste, som Purge-tr\u00e5den afvikler asynkront. Hvis Purge ikke kan f\u00f8lge med, vokser denne liste og holder gamle linjeversioner kunstigt i live. Det medf\u00f8rer flere l\u00e6seoperationer, mere I\/O og st\u00f8rre undo-tablespaces. I s\u00e5danne situationer tjekker jeg altid isolationsniveauer og \u00e5bne snapshots, for en uheldig <a href=\"https:\/\/webhosting.de\/da\/mysql-isolation-level-hosting-server-consistency-transaktioner\/\">Valg af isolering<\/a> forl\u00e6nger levetiden for gamle versioner. Hvis man ser p\u00e5 rydningshastighed, historikl\u00e6ngde og aktive transaktioner i sammenh\u00e6ng, kan man tidligt opdage flaskehalse og bremse lagerdrift, inden den bliver kritisk.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb_undo_logs_meeting_2387.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Rensemekanisme og indstillingsmuligheder<\/h2>\n\n<p>Purge fungerer <em>efter bedste evne<\/em>: Den indsamler poster, der kan ryddes, fra historiklisten, fjerner sletningsm\u00e6rker permanent, opdaterer sekund\u00e6re indekser og frigiver fortrydelsesomr\u00e5der. I systemer med en h\u00f8j \u00e6ndringshastighed skalerer jeg <strong>Parallelisme<\/strong> (f.eks. via flere purge-workere) og juster batch-strategien, s\u00e5 purge k\u00f8rer kontinuerligt, men ikke for aggressivt. Tommelfingerregler:<\/p>\n<ul>\n  <li>Korte, konstante batcher i stedet for sj\u00e6ldne store k\u00f8rsler \u2013 det udj\u00e6vner I\/O og checkpoints.<\/li>\n  <li>Man skal ikke stille \u00bbPurge\u00ab op mod hukommelse eller log-flushing: Begge metoder skal kunne f\u00f8lge med.<\/li>\n  <li>Jeg skal f\u00f8rst l\u00f8se de lange snapshots, f\u00f8r jeg \u00f8ger batchst\u00f8rrelserne yderligere \u2013 ellers g\u00e5r effekten tabt.<\/li>\n<\/ul>\n<p>Vigtigt: Purge er ikke en erstatning for god transaktionsdisciplin. Selv med h\u00f8j parallelitet forbliver Undo bundet, s\u00e5 l\u00e6nge der findes gamle snapshots. Jeg overv\u00e5ger derfor b\u00e5de Purge-fremskridt og transaktionsalder og justerer arbejdsbyrden, hvis Purge konstant halter bagefter.<\/p>\n\n<h2>Konfiguration af Undo-tablespaces<\/h2>\n\n<p>Afh\u00e6ngigt af ops\u00e6tningen kan undo-oplysninger gemmes i systemtablespace eller i separate <strong>Fortryd<\/strong>-tablespaces. Jeg foretr\u00e6kker at adskille Undo for bedre at kunne kontrollere v\u00e6kst og I\/O. Mange installationer tillader dynamisk v\u00e6kst, i nogle tilf\u00e6lde inklusive frigivelse af plads via Truncate. Det lyder praktisk, men \u00f8ger behovet for overv\u00e5gning, da lange snapshots forhindrer en hurtig nedskalering. Jeg v\u00e6lger placering, st\u00f8rrelse og parallelitet ved rensning, s\u00e5 \u00e6ndringshastigheder og tidsvinduer i den daglige drift h\u00e5ndteres korrekt, og <strong>Restaurering<\/strong> ikke lider.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Indstilling<\/th>\n      <th>Effekt<\/th>\n      <th>Hint<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>innodb_undo_directory<\/td>\n      <td>Placering for <strong>Fortryd<\/strong>-filer<\/td>\n      <td>Separate datamedier afkobler I\/O<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_purge_threads<\/td>\n      <td>Mere <strong>Udrensning<\/strong>-Arbejdere i minedriften<\/td>\n      <td>For\u00f8g ved h\u00f8j \u00e6ndringshastighed<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_undo_log_truncate<\/td>\n      <td>Frig\u00f8r uudnyttet plads<\/td>\n      <td>Fungerer kun, hvis historikken er tom<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_max_undo_log_size<\/td>\n      <td>Gr\u00e6nsev\u00e6rdi for v\u00e6kst<\/td>\n      <td>Tilg\u00e6ngelighed afh\u00e6nger af versionen<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Hukommelseslayout og aspekter vedr\u00f8rende filsystemet<\/h2>\n\n<p>Jeg foretr\u00e6kker at placere separate Undo-tablespaces p\u00e5 hurtige SSD\u2019er, adskilt fra data- og log-I\/O. Hvis filsystemet underst\u00f8tter TRIM\/Discard, kan en Truncate-operation fysisk frigive plads til operativsystemet. Jeg planl\u00e6gger dog stadig med konservative \u00f8vre gr\u00e6nser, fordi frigivelse af plads ikke er garanteret, s\u00e5 l\u00e6nge snapshots binder Undo. Ogs\u00e5 komprimering p\u00e5 filsystemet er kun v\u00e6rd, hvis der er CPU-kapacitet til r\u00e5dighed, og skrivem\u00f8nstrene ikke fragmenterer. Det er stadig vigtigt at holde \u00f8je med latenstops: Hvis Undo vokser p\u00e5 et fuldt udnyttet lagringsmedium, forv\u00e6rres skriveforst\u00e6rkning og checkpoint-pres gradvist.<\/p>\n\n<h2>Overv\u00e5gning og diagnose<\/h2>\n\n<p>Jeg tjekker regelm\u00e6ssigt st\u00f8rrelsen p\u00e5 <strong>Fortryd<\/strong>-Tablespaces, l\u00e6ngden af historiklisten og alderen p\u00e5 \u00e5bne transaktioner. SHOW ENGINE InnoDB STATUS, Performance-Schema og Information-Schema giver klare indikationer. Hvis Undo-omr\u00e5derne vokser, mens Purge kun har ringe effekt, afbryder jeg f\u00f8rst gamle sessioner. Derudover kigger jeg p\u00e5 l\u00e5se, for un\u00f8dvendige <a href=\"https:\/\/webhosting.de\/da\/database-raekkelasning-mysql-samtidighed-optimere-ydeevne-lase\/\">Rorl\u00e5se<\/a> forl\u00e6nger transaktioner og snapshots. Ved at gennemg\u00e5 disse n\u00f8gletal dagligt kan man forhindre pludselige I\/O-spidsbelastninger og forkorte veje i <strong>Hukommelse<\/strong>.<\/p>\n\n<h2>Konsekvenser for ydeevnen ved lange transaktioner<\/h2>\n\n<p>Forl\u00e6ngelse af lange l\u00e6se- eller skrivetransaktioner <strong>Versioner<\/strong> fast, selvom de er logisk for\u00e6ldede. Det udvider Undo-loggen, \u00f8ger scanningsomfanget og \u00f8ger belastningen p\u00e5 cachen. Jeg reducerer s\u00e5danne effekter ved hj\u00e6lp af kortere batches, konsekvent COMMIT og timeouts for sessioner. Rapporter, der tager timevis at l\u00e6se, k\u00f8rer bedre i mindre vinduer eller mod replikater. Hvis man aktiverer autocommit, strammer foresp\u00f8rgselsplaner op og lukker inaktive transaktioner, frig\u00f8r man Purge og aflaster <strong>Forekomst<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb-undo-logs-insight-4723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Rollback-segmenter og parallelitet<\/h2>\n\n<p>Fortrydelsesposter findes i <em>Rollback-segmenter<\/em>, som s\u00e5 at sige stiller slots til r\u00e5dighed for \u00e6ndringer, der er aktive p\u00e5 samme tid. Mange samtidige skrivere drager fordel af et tilstr\u00e6kkeligt antal rollback-segmenter, fordi inds\u00e6ttelser og opdateringer s\u00e5 sj\u00e6ldnere skal dele deres undo-k\u00e6der. Jeg overv\u00e5ger ventem\u00f8nstre p\u00e5 rollback-ressourcer og \u00f8ger antallet af disse, hvor versionen og distributionen tillader det. Symptomer p\u00e5 manglende parallelitet er uventede ventetider i ellers korte opdateringsfaser eller st\u00e6rkt svingende skrivelatenser under belastning. Flere segmenter fordeler presset, men oph\u00e6ver ikke grundreglen: Lange snapshots sl\u00e5r enhver optimering.<\/p>\n\n<h2>Isoleringsniveauer i detaljer<\/h2>\n\n<p>Die <a href=\"https:\/\/webhosting.de\/da\/mysql-isolation-level-hosting-server-consistency-transaktioner\/\">Isoleringsniveau<\/a> bestemmer, hvor l\u00e6nge Undo-versioner er relevante. I REPEATABLE READ bevarer en transaktion sit start-snapshot gennem hele varigheden; Undo forbliver alts\u00e5 potentielt bundet i meget lang tid. I READ COMMITTED oprettes der visningsvinduer for hver s\u00e6tning; dette forkorter i mange arbejdsbelastninger levetiden for gamle versioner betydeligt. SELECT \u2026 FOR UPDATE og LOCK IN SHARE MODE l\u00e6gger l\u00e5se og \u00e6ndrer parallelitetsprofilen \u2013 nyttigt mod \u00bblost updates\u00ab, men kritisk for Undo, hvis l\u00e6sere forbliver \u00e5bne for l\u00e6nge. Jeg anvender derfor m\u00e5lrettet READ COMMITTED d\u00e9r, hvor rapporter eller API-l\u00e6sninger har brug for konsistente, men ikke transaktionsd\u00e6kkende visninger, og holder mig til REPEATABLE READ, n\u00e5r forretningslogikken kr\u00e6ver det.<\/p>\n\n<h2>Gendannelses- og opstarts-scenarier<\/h2>\n\n<p>Ved opstart bruger InnoDB <strong>Fortryd<\/strong>-Oplysninger, der g\u00f8r det muligt at tilbagef\u00f8re ufuldst\u00e6ndige transaktioner p\u00e5 en korrekt m\u00e5de. Dette sikrer konsistente visninger, inden nye klienter g\u00e5r i gang. I s\u00e6rlige tilf\u00e6lde findes der starttilstande, der forkorter kontrollerne, men jeg bruger dem kun i n\u00f8dstilf\u00e6lde. Ren hastighedsfor\u00f8gelse uden diagnose kan have negative konsekvenser, fordi integriteten har f\u00f8rsteprioritet. Hvis man holder \u00f8je med gendannelsestid og omfanget af fortrydelser, kan man tr\u00e6ffe bedre beslutninger om vedligeholdelsesvinduer og <strong>Risiko<\/strong>.<\/p>\n\n<h2>Praktiske retningslinjer for administration<\/h2>\n\n<p>Jeg holder transaktionerne korte, foretager hyppige commit og undg\u00e5r endel\u00f8se l\u00e6sesessioner, s\u00e5 <strong>Udrensning<\/strong> har frit spil. St\u00f8rre masse\u00e6ndringer opdeler jeg i velafvejede batches, s\u00e5 historiklisten ikke vokser. Jeg skalerer purge-tr\u00e5de efter \u00e6ndringshastigheden og tilpasser undo-layoutet til lagerhardwaren. Derudover dokumenterer jeg forretningsprocesser, der kr\u00e6ver lange snapshots, og planl\u00e6gger bevidst tidsvinduer. P\u00e5 den m\u00e5de forbliver brugen af Undo forudsigelig, og <strong>Forsinkelse<\/strong> lav.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mdb_undologs_tech_office_3821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Arbejdsbelastningsm\u00f8nstre og optimering<\/h2>\n\n<p>E-handel, rapportering og indholdssystemer medf\u00f8rer mange \u00e6ndringer og kr\u00e6ver disciplineret <strong>Transaktioner<\/strong>. Jeg indstiller konservative timeouts for l\u00e6sere, optimerer indekser til pr\u00e6cise opdateringer og begr\u00e6nser batchst\u00f8rrelser. Ved h\u00f8j skrivebelastning \u00f8ger jeg paralleliteten ved rensning og regulerer checkpoint-presset. Desuden kontrollerer jeg skrivehastigheden i forhold til <a href=\"https:\/\/webhosting.de\/da\/databasetransaktionslogfiler-gendannelsesprocesser-databasebeskyttelse-sikker\/\">Transaktionslogfiler og gendannelse<\/a>, s\u00e5 gendannelse efter nedbrud forbliver forudsigelig. Dette samspil g\u00f8r det muligt at planl\u00e6gge Undo-volumen og beskytter <strong>Konsistens<\/strong>.<\/p>\n\n<h2>Sikkerhedskopier og replikering<\/h2>\n\n<p>Logiske sikkerhedskopier med konsistente snapshots forl\u00e6nger uundg\u00e5eligt levetiden for gamle versioner \u2013 Undo-stakken vokser, indtil sikkerhedskopieringen er f\u00e6rdig. Jeg planl\u00e6gger s\u00e5danne k\u00f8rsler uden for perioder med h\u00f8j belastning, begr\u00e6nser antallet af samtidige skrivere og s\u00f8rger for tilstr\u00e6kkelig purge-kapacitet. Fysiske sikkerhedskopieringer kan mindske Undo-belastningen, men fritager ikke for omhyggelighed ved snapshots. P\u00e5 replikaer foretr\u00e6kker jeg at k\u00f8re rapporter i READ COMMITTED og afslutter lange inaktive transaktioner, s\u00e5 SQL-Apply ikke kommer bagud. Hvis en replika kommer bagud, stiger undo-belastningen ogs\u00e5 der, da indl\u00e6sningen af mange sletninger\/opdateringer skaber en b\u00f8lge af historik, som purge f\u00f8rst skal arbejde sig igennem.<\/p>\n\n<h2>Runbook: Hurtigt stoppe v\u00e6ksten i antallet af fortrydelser<\/h2>\n\n<ul>\n  <li>Identificering af aktive langdistancel\u00f8bere: Kontroller \u00e5bne transaktionsvarigheder og sessioner med store resultats\u00e6t.<\/li>\n  <li>Afslut konsekvent inaktive transaktioner: Kontroller autocommit, luk glemte mark\u00f8rer.<\/li>\n  <li>For\u00f8g purge-kapaciteten: Aktiver yderligere arbejdere og for\u00f8g batchst\u00f8rrelserne moderat.<\/li>\n  <li>Optimering af Writer-spidsbelastninger: Begr\u00e6ns batchst\u00f8rrelser, indf\u00f8r mikro-commits.<\/li>\n  <li>Udnyt vedligeholdelsesvinduer: Flyt store sletnings- og opdateringsb\u00f8lger til planlagte tidsrum.<\/li>\n  <li>Efter stabilisering: Tillad Undo-Truncate, indtil filsystemets st\u00f8rrelse igen passer til behovet.<\/li>\n<\/ul>\n\n<h2>Kapacitetsplanl\u00e6gning for Undo<\/h2>\n\n<p>Jeg beregner Undo konservativt ud fra \u00e6ndringshastighed, gennemsnitlig linjest\u00f8rrelse og maksimalt snapshot-vindue. En enkel tiln\u00e6rmelse: \u00c6ndringsh\u00e6ndelser pr. sekund \u00d7 gennemsnitlig nyttelast \u00d7 planlagt tidsvindue i sekunder. Medregn sikkerhedsmargen for indeks og metadata. Denne tommelfingerregel giver en fornemmelse af behovet i v\u00e6rst t\u00e6nkelige tilf\u00e6lde og beskytter mod overraskelser, n\u00e5r der udf\u00f8res rapportering, sikkerhedskopiering eller migreringer <em>p\u00e5 samme tid<\/em> Integrere snapshots. I systemer, der er i v\u00e6kst, tjekker jeg hvert kvartal, om \u00e6ndringer i arbejdsbelastningen (nye funktioner, flere mobile klienter, st\u00f8rre spidsbelastninger) \u00e6ndrer behovet.<\/p>\n\n<h2>S\u00e6rlige tilf\u00e6lde: Midlertidige tabeller og DDL<\/h2>\n\n<p>Midligt oprettede InnoDB-tabeller bruger egne omr\u00e5der; \u00e6ndringer heri belaster den almindelige undo-log mindre, men kan alligevel medf\u00f8re en del I\/O ved store sorteringer\/sammenf\u00f8jninger. DDL-operationer som ALTER TABLE skaber ofte massive b\u00f8lger af \u00e6ndringer \u2013 jeg opdeler dem om n\u00f8dvendigt i inkrementelle trin og planl\u00e6gger dem i perioder med lav belastning. Ogs\u00e5 her g\u00e6lder det: Korte, rene transaktioner er bedre end risikable genveje. Hvis en DDL-k\u00f8rsel afbrydes, hj\u00e6lper Undo med at vende tilbage til en konsistent tilstand; det kr\u00e6ver dog tilstr\u00e6kkelig hukommelse og tid, som jeg planl\u00e6gger p\u00e5 forh\u00e5nd.<\/p>\n\n<h2>Eksempel: M\u00e5ling af virkninger<\/h2>\n\n<p>Jeg starter med et baseline-\u00f8jebliksbillede af Undo-st\u00f8rrelsen, som <strong>Historie<\/strong>-l\u00e6ngden og den gennemsnitlige transaktionsvarighed. Derefter foretager jeg m\u00e5lrettede \u00e6ndringer, f.eks. ved at \u00f8ge antallet af purge-tr\u00e5de eller reducere batchst\u00f8rrelserne. Derefter sammenligner jeg n\u00f8gletallene, indtil v\u00e6ksten i undo-transaktioner og latenstiderne kommer i et sundt forhold til hinanden. Hvis jeg st\u00f8der p\u00e5 afvigelser, kigger jeg i foresp\u00f8rgselsplaner og sessionslister for at identificere fastl\u00e5ste l\u00e6sere. Denne cirkul\u00e6re proces giver hurtige resultater uden at <strong>Tilg\u00e6ngelighed<\/strong> at bringe i fare.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb_undo_logs_9876.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Almindelige misforst\u00e5elser<\/h2>\n\n<p>Et commit sletter ikke gamle versioner med det samme; <strong>Udrensning<\/strong> besluttes f\u00f8rst senere. Truncate-indstillinger l\u00f8ser ikke et grundl\u00e6ggende designproblem, hvis transaktioner varer for l\u00e6nge. Store undo-filer betyder ikke n\u00f8dvendigvis korruption; ofte er det en enkelt session, der blokerer. L\u00e6sere blokerer sj\u00e6ldent skrivere, men uhensigtsm\u00e6ssige foresp\u00f8rgsler forl\u00e6nger indirekte snapshots. Den, der udrydder disse fejl, tr\u00e6ffer bedre beslutninger og reducerer <strong>Nedetider<\/strong>.<\/p>\n\n<h2>Resum\u00e9 til dem, der har travlt<\/h2>\n\n<p>F\u00f8re fortrydelseslogfiler <strong>Fortid<\/strong> h\u00e5ndgribelig, s\u00e5 InnoDB sikkert kan fortryde transaktioner, og l\u00e6sere ser ensartede visninger. Jeg holder styr p\u00e5 v\u00e6ksten ved at stramme op p\u00e5 transaktionerne, indstille purge-tr\u00e5de korrekt og placere undo-tablespaces fornuftigt. Overv\u00e5gning af historikl\u00e6ngden, undo-st\u00f8rrelserne og transaktionsalderen afsl\u00f8rer tendenser p\u00e5 et tidligt tidspunkt. Ved afvigelser unders\u00f8ger jeg arbejdsbelastning, l\u00e5sninger og sessioner i stedet for at fokusere p\u00e5 symptomerne. Den, der f\u00f8lger denne rutine, opretholder ydeevne, konsistens og <strong>genstart<\/strong> under fuld kontrol.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb-undo-logs-4982.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>","protected":false},"excerpt":{"rendered":"<p>MariaDB Undo-logfiler forklaret: InnoDB-interne funktioner, rollback, MVCC og administrator-tips til ydeevne og stabilitet.<\/p>","protected":false},"author":1,"featured_media":21112,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21119","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"143","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"MariaDB Undo","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21112","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21119","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=21119"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21119\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21112"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21119"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21119"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21119"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}