The Transaction Log (SQL Server) (Suomi)

  • 10/23/2019
  • 11 minutes to read
    • M
    • D
    • f
    • M
    • s
    • +8

Applies to: SQL Server (all supported versions)

Every SQL Server database has a transaction log that records all transactions and the database modifications made by each transaction.,

tapahtumaloki on tietokannan kriittinen osa. Jos järjestelmässä on vika, tarvitset lokin palauttaaksesi tietokantasi johdonmukaiseen tilaan.

lisätietoja tapahtumalokin arkkitehtuuri ja sisäosat, katso SQL Server tapahtumalokin Arkkitehtuurin ja Hallinnan Opas.

Varoitus

Älä koskaan poista tai siirrä tätä lokia, ellet täysin ymmärrä sen seurauksia.

Vihje

Tiedossa hyviä kohtia, josta alkaa soveltaa tapahtumalokit aikana tietokannan elvytys on luonut tarkastuspisteitä., Lisätietoja on tietokannan tarkastuspisteissä (SQL Server).

operaatiot, joiden tukena on tapahtumaloki

tapahtumaloki, tukevat seuraavia operaatioita:

  • yksittäisten liiketoimien takaisinperintä.
  • kaikkien keskeneräisten tapahtumien palauttaminen SQL Serverin käynnistyessä.
  • liikkuvan palautetun tietokannan, tiedoston, filegroupin tai sivun eteenpäin epäonnistumispisteeseen.
  • tukee transaktioreplikaatiota.
  • korkean saatavuuden ja katastrofien palautusratkaisujen tukeminen: aina saatavuusryhmissä, tietokannan peilaus ja lokien toimitus.,

yksilöllisen liiketoimen takaisinperintä

Jos sovellus antaa ROLLBACK – lausuman tai jos tietokantamoottori havaitsee virheen, kuten yhteyden menetyksen asiakkaan kanssa, lokitietoja käytetään peruuttamaan keskeneräisen tapahtuman tekemät muutokset.,

takaisin kaikki keskeneräisiä siirtoja, kun SQL-Palvelin on käynnistynyt

Jos palvelin kaatuu, tietokannat voidaan jättää tila, jossa joitakin muutoksia oli koskaan kirjoitettu puskuri välimuistin tiedostoja, ja saattaa olla joitakin muutoksia puutteellisia kauppojen tiedostoja. Kun esimerkiksi SQL Server käynnistetään, se suorittaa elpyminen kunkin tietokannan. Kaikki lokiin tallennetut muutokset, joita ei välttämättä ole kirjoitettu datatiedostoihin, rullataan eteenpäin., Kaikki tapahtumalokissa havaitut epätäydelliset tapahtumat rullataan sitten takaisin, jotta tietokannan eheys säilyy. Lisätietoja on Restore and Recovery Overview-sivustolla (SQL Server).

liikkuvan palautetun tietokannan, tiedoston, filegroupin tai sivun eteenpäin epäonnistumispisteeseen

kun tietokantatiedostoihin vaikuttava laitteistohäviö tai levyvika, voit palauttaa tietokannan epäonnistumispisteeseen., Palautat ensin viimeisen täyden tietokannan varmuuskopion ja viimeisen differentiaalitietokannan varmuuskopion ja palautat sitten tapahtumapäiväkirjan varmuuskopioiden myöhemmän sekvenssin epäonnistumispisteeseen.

kun palautat jokaisen lokin varmuuskopion, tietokantamoottori toistaa kaikki lokiin kirjatut muutokset rullaamaan kaikki tapahtumat eteenpäin. Kun viimeinen loki varmuuskopiointi on palautettu, tietokantamoottori käyttää lokitietoja kääntääkseen takaisin kaikki tapahtumat, jotka eivät olleet täydellisiä siinä vaiheessa. Lisätietoja on Restore and Recovery Overview-sivustolla (SQL Server).,

Tukeva kaupallisen replikointi

Kirjaudu Reader-Agentti valvoo tapahtumalokin kunkin tietokannan määritetty kaupallisen replikointi ja kopioi tapahtumat merkitty replikointi kaupasta kirjaudu jakelu tietokantaan. Katso lisätietoja Transaktioreplikaation toiminnasta.

korkean saatavuuden ja katastrofien palautusratkaisujen tukeminen

valmiuspalvelinratkaisut, aina saatavuusryhmissä, tietokantojen peilaus ja lokien toimitus, luottavat vahvasti tapahtumalokiin.,

always on availability groups-skenaariossa jokainen tietokannan päivitys, ensisijainen kopio, toistetaan välittömästi erillisinä, täydellisinä kopioina tietokannasta, toissijaisina replikoina. Ensisijainen kopio lähettää jokaisen lokitiedon välittömästi toissijaisiin jäljennöksiin, jotka soveltavat saapuvia lokitietoja saatavuusryhmän tietokantoihin ja vierittävät sitä jatkuvasti eteenpäin. Lisätietoja on aina lokien toimitusskenaariossa kohdassa Failover Cluster Instances

. ensisijainen palvelin lähettää ensisijaisen tietokannan aktiivisen tapahtumalokin yhteen tai useampaan kohteeseen., Jokainen toissijainen palvelin palauttaa lokin paikalliseen toissijaiseen tietokantaan. Lue lisää lokin toimituksesta.

tietokantaa peilaavassa skenaariossa jokainen päivitys tietokantaan, päätietokantaan, toistetaan välittömästi erillisenä, täydellisenä kopiona tietokannasta, mirror-tietokannasta. Pääasiallinen palvelin esimerkiksi lähettää jokainen kirjaa välittömästi mirror server-esiintymä, joka koskee saapuvan lokitietueet peili tietokanta, jatkuvasti liikkuvan eteenpäin. Lisätietoja on Tietokantakehityksessä.,

tapahtumalokin ominaisuudet

SQL Server Database Engine transaction login ominaisuudet:

  • tapahtumaloki toteutetaan erillisenä tiedostona tai tiedostokokonaisuutena tietokannassa. Lokivälimuistia hallitaan erikseen datasivujen puskurivälimuistista, jolloin SQL Server-Tietokantamoottorissa on yksinkertainen, nopea ja vankka koodi. Lisätietoja on Tapahtumapäiväkirjan fyysisessä arkkitehtuurissa.

  • lokitietojen ja sivujen muotoa ei ole pakko noudattaa datasivujen muotoa.,

  • tapahtumaloki voidaan toteuttaa useissa tiedostoissa. Tiedostot voidaan määritellä laajentaa automaattisesti asettamalla FILEGROWTH arvo log. Tämä vähentää tilanpuutteen mahdollisuutta tapahtumalokissa ja vähentää samalla hallinnollisia yleiskustannuksia. Lisätietoja: ALTER DATABASE (Transact-SQL) File and Filegroup Options.

  • mekanismi käyttää tilaa sisällä lokitiedostot on nopea ja on minimaalinen vaikutus kaupan läpijuoksu.,

lisätietoja tapahtumalokin arkkitehtuuri ja sisäosat, katso SQL Server tapahtumalokin Arkkitehtuurin ja Hallinnan Opas.

tapahtumalokin typistäminen

Log typistäminen vapauttaa lokitiedostossa tilaa tapahtumalokin uudelleenkäytettäväksi. Sinun täytyy säännöllisesti katkaista tapahtumaloki, jotta se ei täytä varattu tila. Useat tekijät voivat viivästyttää lokin katkaisua, joten lokin koon seurannalla on merkitystä. Jotkin toiminnot voidaan kirjata minimaalisesti, jotta niiden vaikutus tapahtumalokin kokoon pienenee.,

Log typistäminen poistaa inaktiiviset virtuaalilokitiedostot (VLFs) SQL Server-tietokannan loogisesta tapahtumalokista vapauttaen tilaa loogisessa lokissa fyysisen tapahtumalokin uudelleenkäyttöä varten. Jos tapahtumalokia ei koskaan typistetä, se lopulta täyttää kaikki fyysisille lokitiedostoille osoitetut levytilat.

jotta vältyttäisiin tilan loppumiselta, ellei log-typistystä jostain syystä viivytetä, typistyminen tapahtuu automaattisesti seuraavien tapahtumien jälkeen:

  • yksinkertaisen palautusmallin mukaan tarkistuspisteen jälkeen.,
  • Alle täyden palautuksen mallia tai bulk-kirjautunut elpyminen malli, jos tarkastuspiste on tapahtunut edellisen varmuuskopioinnin jälkeen, katkaisu tapahtuu, kun log backup (paitsi jos se on kopio-vain log backup).

lisätietoja, Katso tekijät, jotka voivat viivästyttää log typistystä, myöhemmin tästä aiheesta.

Huomautus

Log typistäminen ei pienennä fyysisen lokitiedoston kokoa. Fyysisen lokitiedoston fyysisen koon pienentämiseksi sinun on kutistettava lokitiedosto. Tietoja fyysisen lokitiedoston koon pienentämisestä on osoitteessa Hallitse Tapahtumalokitiedoston kokoa.,
muista kuitenkin tekijät, jotka voivat viivästyttää lokin katkaisua. Jos tallennustilaa tarvitaan uudelleen lokin kutistamisen jälkeen, tapahtumaloki kasvaa uudelleen ja siten tuo suorituskyvyn yläpuolella log grow-toiminnan aikana.

tekijät, jotka voivat viivästyttää lokin typistymistä

kun lokiasiakirjat pysyvät aktiivisina pitkään, tapahtumalokin typistyminen viivästyy ja tapahtumaloki voi täyttyä, kuten aiemmin tässä pitkässä aiheessa mainittiin.,

Tärkeää

lisätietoja siitä, miten vastata koko tapahtumalokin, katso Vianmääritys Koko tapahtumalokin (SQL Server Virhe 9002).

oikeasti Log-typistystä voi lykätä monestakin syystä. Opi mikä, jos mikä, estää log typistymisen querying log_reuse_wait ja log_reuse_wait_desc sarakkeet sys.tietokantojen luettelonäkymä. Seuraava taulukko kuvaa näiden sarakkeiden arvoja.,

vain sisäiseen käyttöön vain sisäiseen käyttöön td >

toiminnot, jotka voidaan kirjata minimaalisesti

minimaalisiin hakkuisiin kuuluu kirjaaminen vain tiedot, joita tarvitaan liiketoimen perimiseksi takaisin tukematta point-in-Time-palautusta., Tämä aihe tunnistaa toiminnot, jotka ovat minimaalisesti Kirjautunut irtotavarana-logged recovery model (sekä alla yksinkertainen recovery model, paitsi kun varmuuskopio on käynnissä).

Note

minimaalista kirjausta ei tueta muistioptimoiduissa taulukoissa.

Huom.

Alle täyden palautuksen mallia, kaikki irtotavarana toiminnot ovat täysin kirjautunut. Voit kuitenkin minimoida kirjautumisen joukko irtotavarana toimintoja vaihtamalla tietokannan irtotavarana Kirjautunut hyödyntämismalli väliaikaisesti irtotavarana toimintaa.,Minimaalinen hakkuut on tehokkaampaa kuin koko hakkuut, ja se vähentää mahdollisuutta laajamittainen irtotavarana toiminta täyttö saatavilla tapahtumalokin tilaa aikana suurin liiketoimi. Kuitenkin, jos tietokanta on vahingoittunut tai kadonnut, kun minimaalinen hakkuut on voimassa, et voi palauttaa tietokannan kohta epäonnistumista.

seuraavat toiminnot, jotka ovat täysin kirjautunut alle täyden palautuksen mallia, ovat vähän kirjautunut alle yksinkertainen ja bulk-kirjautunut elpyminen malli:

  • Bulk-tuonti-toiminnot (bcp, BULK LISÄÄ ja LISÄÄ… VALITA)., Lisätietoja siitä, milloin irtotavaran tuonti taulukkoon on minimaalisesti Kirjautunut, Katso edellytykset vähäiselle kirjaamiselle Irtotavaran tuonnissa.

Kun kaupallisen replikointi on käytössä, BULK INSERT toiminnot ovat täysin kirjautunut jopa alle Bulk-Kirjautunut toipumisen malli.

  • valitse operaatioihin.

Kun kaupallisen replikointi on käytössä, SELECT INTO toiminnot ovat täysin kirjautunut jopa alle Bulk-Kirjautunut toipumisen malli.,

  • Osittainen päivityksiä suuri arvo tietotyyppejä käyttäen .WRITE lauseke PÄIVITTÄÄ ilmoitus, kun asetat tai lisäämällä uusia tietoja. Huomaa, että minimaalista kirjaamista ei käytetä, kun olemassa olevia arvoja päivitetään. Lisätietoja suurista tietotyypeistä on Tietotyypeissä (Transact-SQL).

  • WRITETEXT ja UPDATETEXT-lausekkeet, kun tekstiin, ntext-tekstiin ja kuvadatan tyyppisiin sarakkeisiin lisätään tai lisätään uusia tietoja. Huomaa, että minimaalista kirjaamista ei käytetä, kun olemassa olevia arvoja päivitetään.,

    Varoitus

    WRITETEXT ja UPDATETEXT lausunnot ovat epätarkkoja; vältä niiden käyttöä uusissa sovelluksissa.

  • Jos tietokanta on asetettu yksinkertainen tai bulk-kirjautunut elpyminen malli, jotkut indeksi DDL toiminta on minimaalisesti kirjautunut, onko operaatio suoritetaan offline-tai online. Vähän kirjautunut indeksi toiminnot ovat seuraavat:

    • LUO INDEKSI-operaatiot (mukaan lukien indeksoitu näkemyksiä).

    • ALTER INDEX REBUILD tai DBCC DBREINDEX operations.,

      Varoitus

      DBCC DBREINDEX lausunto on vanhentunut; Älä käytä sitä uusia sovelluksia.

      Huom.

      – Indeksi rakentaa toiminta käyttää minimial hakkuut mutta voi viivästyä, kun siellä on samanaikaisesti suorittamalla varmuuskopiointi. Tämä viive johtuu synkronointivaatimuksista, jotka koskevat minimaalisesti kirjattuja puskurin pool-sivuja käytettäessä yksinkertaista tai irtotavarana kirjattua palautusmallia.

    • DROP INDEX new heap rebuild (tarvittaessa). Indeksisivu deallocation aikana DROP INDEX toiminta on aina täysin Kirjautunut.,n tietokanta on vaurioitunut (SQL Server)

    tapahtumalokin palauttaminen (Full Recovery Model)

    • Palauta tapahtumalokin varmuuskopiointi (SQL Server)

    Katso myös

    SQL Server Transaction Log Architecture and Management Guide
    Control Transaction strength strength
    conditions for Minimal Logging in Bulk Import
    Back Up and Restore of SQL Server Databases
    Restore and Recovery Overview (SQL Server)
    tietokannan tarkistuspisteet (SQL Server)
    Katso tai muuta tietokannan ominaisuuksia
    recovery models (SQL Server)
    transaction log backups (SQL Server)
    sys.,dm_db_log_info (Transact-SQL)
    sys. dm_db_log_space_usage (Transact-SQL)

log_reuse_wait arvo log_reuse_wait_desc arvo Kuvaus
0 MIKÄÄN ei tällä Hetkellä on olemassa yksi tai useampi uudelleenkäytettäviä virtuaalinen lokitiedostot (VLFs).
1 CHECKPOINT Ei checkpoint on tapahtunut sitten viime lokin katkaisu, tai pää-log ei ole vielä edenneet virtuaalinen log file (VLF). (Kaikki palautusmallit)
Tämä on rutiininomainen syy viivyttää lokin katkaisua., Lisätietoja on tietokannan tarkastuspisteissä (SQL Server).
2 LOG_BACKUP ennen kuin tapahtumaloki voidaan katkaista. (Vain täydet tai irtotavarana kirjatut palautusmallit)
kun seuraava lokin varmuuskopiointi on valmis, osa lokitilasta saattaa tulla uudelleenkäytettäväksi.
3 ACTIVE_BACKUP_OR_RESTORE tietojen varmuuskopiointi tai palautus on käynnissä (kaikki palautusmallit).
jos tietojen varmuuskopiointi estää lokin katkaisun, varmuuskopiointioperaation peruuttaminen voi auttaa välittömään ongelmaan.,
4 ACTIVE_TRANSACTION a transaction is active (all recovery models):
a long-running transaction might exist at the start of the log backup. Tällöin tilan vapauttaminen saattaa vaatia uuden lokin varmuuskopioinnin. Huomaa, että pitkäaikaiset liiketoimet estävät lokin katkaisun kaikissa palautusmalleissa, mukaan lukien yksinkertainen palautusmalli, jossa tapahtumaloki yleensä katkaistaan kullakin automaattisella tarkastuspisteellä.
kauppaa lykätään., Lykätty transaktio on käytännössä aktiivinen transaktio, jonka peruuttaminen on estetty jonkin resurssin puuttumisen vuoksi. Lisätietoja lykättyjen tapahtumien syistä ja siitä, miten ne siirretään pois laskennallisesta tilasta, Katso Laskennalliset tapahtumat (SQL Server).
pitkään jatkuneet tapahtumat saattavat myös täyttää tempdb: n tapahtumalokin. Tempdb käytetään implisiittisesti käyttäjä liiketoimia sisäisiä esineitä, kuten työ taulukot lajittelu, työn-tiedostojen hajautus, kohdistin pöydät, työ -, ja rivi versiointi., Vaikka käyttäjä tapahtuma sisältää vain tietojen lukeminen (SELECT kyselyt), sisäisiä objekteja voidaan luoda ja käyttää alle käyttäjä liiketoimia. Silloin tempdb-tapahtumaloki voidaan täyttää.
5 DATABASE_MIRRORING tietokannan peilaus on keskeytetty, tai korkean suorituskyvyn tilassa peilitietokanta on merkittävästi päätietokannan takana. (Vain full recovery model)
Lisätietoja, katso Tietokantapeilaus (SQL Server).,
6 REPLIKAATIO Aikana kaupallisen kopioivat, liiketoimien kannalta julkaisut ovat edelleen toimittamatta jakeluun tietokantaan. (Vain täydellinen palautusmalli)
tietoja transaktioreplikaatiosta, KS.SQL Server replikaatio.
7 DATABASE_SNAPSHOT_CREATION tietokantakuva luodaan. (Kaikki talteenottomallit)
Tämä on rutiininomainen ja tyypillisesti lyhyt, viivästyneen lokin katkaisun syy.
8 LOG_SCAN log scan tapahtuu., (Kaikki talteenottomallit)
Tämä on rutiininomainen ja tyypillisesti lyhyt, viivästyneen lokin katkaisun syy.
9 AVAILABILITY_REPLICA toissijainen kopio saatavuus konserni soveltaa tapahtumaloki kirjaa tämän tietokannan vastaava toissijainen tietokanta. (Full recovery model)
Lisätietoja, Katso yleiskatsaus aina Saatavuusryhmissä (SQL Server).,
10 vain sisäiseen käyttöön
11
12
13 oldest_page jos tietokanta on määritetty käyttämään epäsuoria tarkastuspisteitä, tietokannan vanhin sivu saattaa olla vanhempi kuin checkpoint log sequence number (LSN). Tällöin vanhin sivu voi viivyttää lokin katkaisua. (Kaikki palautusmallit)
tietoja epäsuorista tarkastuspisteistä on tietokannan tarkastuspisteissä (SQL Server).,
14 OTHER_TRANSIENT Tämä arvo on tällä hetkellä käytetä.
16 XTP_CHECKPOINT on tehtävä muistissa oleva OLTP-tarkastuspiste.Muistioptimoiduissa taulukoissa automaattinen tarkastuspiste otetaan, kun tapahtumalokitiedosto tulee suuremmaksi kuin 1.,5 Gt viimeisestä tarkastuspisteestä lähtien (sisältää sekä levypohjaisia että muistioptimoituja taulukoita)
Lisätietoja katso Checkpoint-toiminto Muistioptimoiduille taulukoille ja (https://blogs.msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/)

Leave a Comment