sqlshack

tässä artikkelissa tarkastellaan useiden SQL Server-Tapahtumalokitiedostojen käyttöä ja toissijaisen tapahtumalokitiedoston poistamista.

Johdanto

oletuksena SQL Server-tietokanta sisältää ensisijaisen datatiedoston ja tapahtumalokitiedoston. Se on hyvä käytäntö konfigurointi useita tiedostoja ja jakaa tietoja useita tiedostoja. Meillä voi olla näitä tiedostoja erillisillä tallennusasemilla, joilla on useita IO: ta. Se auttaa tiedonhallintaa, parantaa suorituskykyä, suunnittelee varmuuskopiointimenetelmiä filegroupsin mukaan.

meillä voi olla useita tapahtumalokitiedostoja myös tietokannalle.

SQL Server käyttää useita tapahtumalokitiedostoja peräkkäisessä järjestyksessä. Oletetaan, että meillä on kaksi tapahtumalokitiedostoa. SQL Server käyttää yhtä lokitiedostoa kerrallaan ja kun se on täynnä, SQL Server käyttää toista lokitiedostoa. Koska SQL Server ei käytä sitä rinnakkain, emme saa mitään suorituskykyä hyötyä siitä. Ihannetapauksessa meillä pitäisi olla vain yksi tapahtumalokitiedosto tietokantaa kohti.

oletetaan, että meillä on tuotantotietokanta, ja saamme kriittisen hälytyksen, että levyltä loppuu tila. Tutkimusten jälkeen saimme selville, että tämä asema sisältää tapahtumalokitiedoston. Aktiivisten tapahtumien vuoksi tämä SQL Server-tapahtumalokitiedosto on täynnä. Yritimme kutistaa lokitiedostoa, mutta se ei toiminut. Varmuuskopioimme tapahtumalokin, mutta aktiivisten tapahtumien vuoksi se ei voinut vapauttaa tarvittavaa tilaa. Toisen tapahtumalokitiedoston lisääminen erilliselle levylle, jossa on vapaata tilaa, ratkaisee tämän ongelman.

koska SQL Server käyttää sarjatilaa tietojen kirjoittamiseen tapahtumalokitiedostoon, ylimääräinen lokitiedosto pitäisi poistaa myöhemmin. Katsotaanpa tutkia prosessi poistamalla ylimääräinen lokitiedosto.

Luo tietokanta, jossa on useita SQL Server-Tapahtumalokitiedostoja

Yhdistä SQL-instanssiin SQL Server Management studiossa. Napsauta Object Explorer-ruudussa olevaa tietokantojen solmua hiiren kakkospainikkeella ja valitse uusi tietokanta-komento:

se avaa uuden tietokanta-ikkunan. Määritä tietokannan nimi ja lisää toinen tapahtumalokitiedosto. Testaustarkoituksiin olemme poistaneet tapahtumalokitiedostojen automaattisen kasvun käytöstä. Tapahtumalokitiedoston alkuperäinen koko on 8MB:

kun kaikki on asetettu, Luo tietokanta oletusarvoiseen data/lokitiedostohakemistoon napsauttamalla OK-painiketta. Luo taulukko ja lisää tiedot:

Tarkastele virtuaalisen lokitiedoston tilaa SQL Server-tapahtumalokitiedostoissa

artikkelissa, SQL Server-Tapahtumalokiarkkitehtuuri, tutkimme tapahtumalokitiedoston sisäistä. Jokainen tapahtumalokitiedosto koostuu useista virtuaalisista lokitiedostoista. Tapahtumalokitiedosto on useiden virtuaalisten lokitiedostojen (VLF) yhdistelmä. Seuraava kuvakaappaus näyttää lokitiedoston fyysisen ja loogisen arkkitehtuurin:

SQL Server stats a database with minimi VLF based on the initial log size and auto grow file (based on the auto-Grow configuration). Seuraavassa kuvassa näemme vilauksen SQL Serverin tapahtumalokista:

yksittäisen tapahtumalokitiedoston tapauksessa SQL Server käyttää ympyränmuotoista virtuaalista lokitiedoston polkua. Voimme tarkistaa virtuaalisten lokitiedostojen määrän ja niiden tilan käyttämällä seuraavia:

1. DBCC LOGINFO (’tietokanta’) – se on vanha lauseke ja toimii kaikkien SQL Server-versioiden
2. dynaamisen hallinnan näkymän kanssa sys.dm_db_log_info (DBID). Se on saatavilla SQL Server 2016 SP2: sta tai myöhemmin

millä tahansa komennolla voidaan käyttää VLF-tarkistusta. Tässä artikkelissa käytämme dynaamista hallintanäkymää (DMV):

yllä olevassa kuvakaappauksessa olemme varmistaneet, että näytetietokantamme sisältää kaksi tapahtumalokitiedostoa (file_id 2 ja file_id 3).

• File_id 2 on aktiivinen VLF (vlf_active=1 ja vlf_status=2)
• File_id 3 ei ole aktiivista VLF (vlf_active=0 ja vlf_status=2)

lisätään muutama tietueita taulukkoon niin, että aktiivinen VLF muuttuu:

tapahtumalokin tilankäytön seuranta ja VLF-tila tehdään DMV: llä (sys.dm_db_log_space_usage):

• VLF-tila

  1 2	valitse Db_name() Tietokantanimeksi, File_ID transaction_log_file_idiksi, vlf_active, vlf_status FROM sys. dm_db_log_info(Db_id (”MultileLogFiles’));

• tapahtumalokin käyttö (käytetty ja vapaa tila)

  1 2 3 4 5

  valitse total_log_size_in_bytes*1.0/1024/1024 total_log_size_in_MB, used_log_space_in_bytes*1.0/1024/1024 used_log_space_in_MB, (total_log_size_in_bytes-used_log_space_in_bytes)*1.0/1024/1024 AS free_log_space_in_MB FROM sys. dm_db_log_space_usage;

saamme seuraavat lähtö edellä kyselyt:

• vasemmalla puolella näemme, että kun ensisijainen lokitiedosto (file_id 2) tulee täyteen, se siirtyy seuraavaan lokitiedostoon (file_id 3). Tässä vaiheessa meillä on aktiivinen VLF sekä ensisijaisissa että toissijaisissa lokitiedostoissa. Tietokannassa, jossa on täydellinen palautusmalli, tarvitsemme tapahtumalokin varmuuskopion niin, että se merkitsee VLF: n passiiviseksi
• oikeanpuoleinen ulostulo (DMV: n avulla) näyttää tapahtumalokitiedoston käytetyn tilan 8.51 MB. Kuten muistatte, olemme asettaneet 8 Mt kokoa jokaiselle tapahtumalokitiedostolle ja olemme poistaneet lokin automaattisen kasvun. Kun ensisijainen lokitiedosto on täynnä (8 MB), SQL Server vaihtaa toissijaiseen tapahtumalokitiedostoon

poista toissijainen SQL Server-tapahtumalokitiedosto

poistaaksesi toissijaisen tapahtumalokitiedoston (tiedostotunnus 3), käytämme muokattua Alter-tietokantalauseketta.

lisäämme Poista tiedosto lauseke ja määrittää tiedoston, jonka haluamme poistaa:

tämän lausekkeen suorittaminen johtaa seuraavaan virheilmoitukseen:

Huomautus: aktiivista tapahtumalokitiedostoa ei voi poistaa.

aiemmin näimme, että kun ensisijainen lokitiedosto tulee täyteen, SQL Server käyttää toissijaista lokitiedostoa. Meidän täytyy tehdä toissijainen tapahtumaloki tyhjäksi, jotta voimme poistaa sen.

SQL-tietokannassa, jossa on täydellinen palautusmalli, käytämme tapahtumalokin varmuuskopioita, jotta SQL Server voi katkaista lokit. Saatamme tarvita tähän Useita loki varmuuskopioita riippuen tapahtumalokin koosta, aktiivisesta VLF: stä ja aktiivisesta tapahtumasta.

tehdään täydellinen tietokanta-ja tapahtumalokin varmuuskopiointi:

• täydellinen tietokannan varmuuskopiointi

  1	backup Database MultipleLogFiles to disk= ” C:\Temp\MultipleLogFiles.bak’

• tapahtumalokin varmuuskopiointi

  1	varmuuskopioloki Multiplelogitiedostot levylle= ” C:\Temp\MultipleLogFiles_log.trn’

kun varmuuskopiointi on valmis, tarkista VLF-tila. Aktiivisen VLF: n pitäisi olla ensimmäisessä lokitiedostossa(ensisijainen), jotta voimme poistaa toissijaisen lokitiedoston. Olemme varmistaneet, että vain ensisijainen lokitiedosto (file_id 2) on aktiivinen (VLF Status 2):

nyt toissijainen tapahtumalokitiedosto on poistettava ongelmitta. Suoritetaan muokattu Alter database lausunto uudelleen. Toissijainen tapahtumalokitiedosto poistetaan:

kun toissijainen tapahtumalokitiedosto on poistettu, varmista se graafisen käyttöliittymän sekä T-SQL: n avulla järjestelmänäkymän avulla.tietokanta_tiedostot:

poistettu toissijainen tapahtumalokitiedosto on edelleen läsnä seuraavan kuvakaappauksen mukaisesti:

nyt Napsauta tietokantaa hiiren kakkospainikkeella ja tarkastele olemassa olevia tiedostoja. Näemme poistettu tapahtumaloki tiedoston GUI samoin. Mutta miksi?

suoritetaan muokattu Alter database-lauseke uudelleen ja katsotaan poistaako SQL Server jälleen tapahtumalokitiedoston.

saimme viestin, että SQL Server Ei löytänyt määriteltyä lokitiedostoa:

SQL Server poistaa tapahtumalokitiedoston myöhemmän loki-varmuuskopioinnin jälkeen. Otetaan toinen loki varmuuskopio ja tarkistaa, että tapahtumaloki tiedosto on edelleen olemassa:

todentaa tapahtumalokitiedoston sekä GUI-että T-SQL-menetelmillä. Näemme, että poistettu tapahtumaloki tiedosto ei näy nyt.

johtopäätös

tässä artikkelissa selvitimme toissijaisen SQL Server-tapahtumalokin käyttöä ja sen poistamisprosessia. Sinun tulisi välttää useiden tapahtumalokitiedostojen käyttöä, erityisesti tuotantotietokannassa. Sinun pitäisi ottaa tietokannan varmuuskopiointi ennen suunnittelua mitään toimintaa ja tehdä se ei-tuottavuutta tuntia.

• tekijä
• viimeaikaiset viestit

Rajendra on MCSA-sertifioitu ja Microsoft-sertifioitu kouluttaja Intian Gurgaonissa, jolla on 13 vuoden kokemus.Rajendra työskentelee useille suurille yrityksille, jotka keskittyvät suorituskyvyn optimointiin, seurantaan, korkeaan saatavuuteen sekä katastrofien palautumisstrategioihin ja toteutukseen. Hän on kirjoittanut satoja arvovaltaisia artikkeleita SQL Server, Azure, MySQL, Linux, Power BI, Performance tuning, AWS/Amazon RDS, Git, ja niihin liittyviä teknologioita, joita on katsottu yli 10m lukijat tähän mennessä.
hän on luonut yhden suurimmista ilmaisista verkkoartikkelikokoelmista yhdestä aiheesta, 50-osaisen SQL Server Always on Availability Groups-sarjan. Hänen panoksensa SQL Server-yhteisössä, hän on tunnustettu eri palkintoja, kuten arvostetun ”paras kirjailija vuoden” jatkuvasti 2020 ja 2021 sqlshack.
Raj on aina kiinnostunut uusista haasteista, joten jos tarvitset konsultointiapua mistä tahansa hänen kirjoituksissaan käsitellystä aiheesta, hänet voi tavoittaa [email protected]
Katso kaikki viestit käyttäjältä Rajendra Gupta

uusimmat viestit Rajendra Gupta (Näytä kaikki)

• käytä ARM-malleja Azure container-instanssien käyttöönottoon SQL Server Linux-kuvien kanssa-21. joulukuuta 2021
• Etätyöpöytäyhteys AWS RDS SQL Serverille Amazon RDS: llä Custom-14. joulukuuta 2021
• säilytä SQL Server-tiedostot pysyvässä tallennustilassa Azure Container Instansseille-joulukuu 10, 2021