By: Sergey Gigoyan | Updated: 2015-11-18 | Comments (9) | Related: More > tietokannan hallinto
ongelma
SQL Server sallii useamman kuin yhden tapahtumalokitiedoston käytön, mutta herää kysymys, onko se tarpeellista ja mitä hyötyä on useista tapahtumalokitiedostoista. On harhaluulo keskuudessa jotkut kehittäjät, että ottaa multipletransaction lokitiedostot voivat lisätä suorituskykyä, koska SQL Server voi käyttää niitä rinnakkain. SQL Server käyttää tällä hetkellä vain yhtä tapahtumalokitiedostoa, eikä tässä tapauksessa ole rinnakkaisuutta. Joskus vianmääritystä varten voidaan tarvita useampi kuin yksi lokitiedosto. Niin, yleensä ei ole tarvetta olla enemmän kuin yksi lokitiedosto.Mietitäänpä tapausta, kun Tietokannassamme on enemmän kuin yksi lokitiedosto ja meidän pitäisi säilyttää vain yksi.Tällä vinkillä pyritään kuvaamaan, miten tarpeettomat lokitiedostot poistetaan oikein ja säilytetään vain yksi.
ratkaisu
ennen kuin aletaan havainnollistaa tarpeettomien lokitiedostojen poistamista, kuvataan lyhyesti, miten SQL Server toimii lokitiedostojen kanssa: kun tietokannassa on enemmän kuin yksi lokitiedosto, SQL Server kirjoittaa ensimmäiseen,kunnes se on täynnä, sitten siirtyy toiseen ja niin edelleen. Kun viimeinen lokitiedosto tulee täyteen SQL Server palaa takaisin ensimmäiseen ja sykli jatkuu.Kuitenkin, kuten mainitsimme, joskus voidaan tarvita enemmän kuin yksi lokitiedosto. Esimerkiksi kun levy, jossa lokitiedosto on paikallistettu tulee täyteen ja meidän täytyy luoda toinen lokitiedosto toiseen paikkaan, mutta vianmäärityksen jälkeen ongelma,meidän pitäisi poistaa toinen lokitiedosto, koska ei ole mitään hyötyä on enemmän kuin yksi lokitiedosto.Oletetaan, että meillä on tietokanta, jossa on kaksi lokitiedostoa, ja tehtävämme on poistaa toinen.Seuraava skripti luo TestDB-tietokannan, jossa on kaksi lokitiedostoa ja testattava taulukko. Ajaa se itse, sinun täytyy korvata”D:\SQL Data” olemassa oleva kansiopolku.
USE GOCREATE DATABASE ON PRIMARY ( NAME = N'TestDB', FILENAME = N'D:\SQL DATA\TestDB.mdf' , SIZE = 4096KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB ) LOG ON ( NAME = N'TestDB_log1', FILENAME = N'D:\SQL DATA\TestDB_log1.ldf' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 10%), ( NAME = N'TestDB_log2', FILENAME = N'D:\SQL DATA\TestDB_log2.ldf' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)GOUSE TestDBGOCREATE TABLE TestTable(ID INT IDENTITY(1,1),Value BIGINT)--Change recovery model for TestDB to FULL (if your model database is in FULL recovery model, TestDB has been already created in this mode)ALTER DATABASE TestDB SET RECOVERY FULL
nyt ymmärretään tapahtumalokin fyysinen rakenne: sisäisesti tapahtumalokitiedosto koostuu virtuaalisesta lokitiedostosta (VLF), jotka ovat tapahtumalokitiedoston hallintayksikkö. Se tarkoittaa, että kun tietokantamoottori kasvaa tai kutistuu lokitiedosto, se tekee sen täydellisellä VLFs: llä (esimerkiksi se ei voi kutistua puolta VLF: stä). Virtuaalisten lokitiedostojen koko sekä niiden lukumäärä fyysisessä lokitiedostossa ei ole kiinteä ja sitä hallinnoidaan dynaamisesti tietokantamoottorilla. Seurataksesi tapahtumalokitiedostoa sisäisesti käytämme” DBCC LOGINFO ” – komentoa, joka tarjoaa tietoa virtuaalisista lokitiedostoista. Alla olevassa komentosarjassa käytimme tätä komentoa tietokantaamme varten:
--Getting log files infoDBCC LOGINFO('TestDB')
ja tulos on seuraava:
FileID on lokitiedostotunnisteet tietokantaamme. Tila osoittaa, että VLF on uudelleenkäytettävä tai ei (mahdolliset arvot: 0-Kyllä, 2-Ei). Kuten näemme, on vain yksi VLF withStatus=2. Nyt kun lisäämme dataa testattavaan ja seuraamme, miten lokitiedostot kasvavat:
USE TestDBGO--Checking log information before insertionSELECT file_id, name, type_desc, physical_name, size, max_sizeFROM sys.database_files--Inserting data into TestTable;WITH ValueTable AS(SELECT 1 nUNION ALL SELECT n+ 1FROM ValueTableWHERE n
tämän esimerkin voimme nähdä, että molemmat lokitiedostot kasvoivat ja nyt on VLFs ”Status=2” toisessa lokitiedostossa (FileID=3) myös:
nyt meidän täytyy poistaa TestDB_log2.ldf-tiedosto. Huomaa, että voimme poistaa vain toissijaiset lokitiedostot. SQL Server ei salli ensisijaisen lokitiedoston poistamista.Jokaisessa tietokannassa on vain yksi ensisijainen lokitiedosto ja ensimmäinen lokitiedosto, joka luodaan tietokannan luontikommentissa, pidetään ensisijaisena.Jos yritämme poistaa toisen lokitiedoston:
USE masterGO--Remove TestDB_log2 fileALTER DATABASE TestDB REMOVE FILE TestDB_log2
saamme seuraavan viestin:
voimme poistaa tapahtumalokitiedoston vain, kun se on tyhjä, joten meidän on ensin tyhjennettävä it.To jos teet sen, meidän pitäisi varmuuskopioida tapahtumaloki. Koska meidän ”TestDB” tietokanta on vasta luotu ja ei ole täyttä varmuuskopiot, meidän täytyy antaa täydellinen tietokanta varmuuskopio TestDB tietokantaan, jonka jälkeen voimme julkaista tapahtumalokin varmuuskopiointi:
--Full backupBACKUP DATABASE TestDB TO DISK =N'D:\SQL DATA\TestDB.bak'--Transaction log backupBACKUP LOG TestDB TO DISK =N'D:\SQL DATA\TestDB.trn'
tapahtumalokin varmuuskopiointi katkaisee lokitiedoston (on joitakin poikkeuksia, jotka eivät kuulu tämän kohdan soveltamisalaan). Lokin katkaisu poistaa passiiviset virtuaaliset lokitiedostot loogisen lokin alusta ja vapauttaa tilaa lokitiedostossa. Typistys ei kuitenkaan pienennä fyysisen lokitiedoston kokoa. Se vapauttaa siinä vain tilaa, joka voidaan käyttää uudelleen. Ajetaan ”DBCC LOGINFO” uudelleen:
kuten näemme, ”TestDB_log2: ssa ei ole virtuaalisia lokitiedostoja.ldf ” tiedosto Status=2 Ja nyt lokitiedostomme on tyhjä ja valmis poistettavaksi:
--Remove TestDB_log2 fileALTER DATABASE TestDB REMOVE FILE TestDB_log2
poisto onnistui.
kuitenkin kun tarkistamme lokitiedot uudelleen, huomaamme loogisen lokitiedoston olevan edelleen olemassa:
--Checking log informationSELECT file_id, name, type_desc, physical_name, size, max_sizeFROM sys.database_files
jos teemme toisen loki varmuuskopiointi, tiedosto poistetaan:
--Transaction log backupBACKUP LOG TestDB TO DISK =N'D:\SQL DATA\TestDB.trn'--Checking log informationSELECT file_id, name, type_desc, physical_name, size, max_sizeFROM sys.database_files
seuraavat vaiheet
- pidä tämä vinkki mielessä, kun haluat määrittää tapahtumalokin käytön ja kuinka tarpeettoman lokitiedoston voi poistaa.
- tarkista nämä resurssit:
- tietokannan hallinto | tapahtumaloki
- https://technet.microsoft.com/en-us/library/ms191433(v=sql.105).aspx
- https://technet.microsoft.com/en-us/library/ms179355(v=sql.105).aspx
- https://technet.microsoft.com/en-us/library/ms345414(v=sql.105).aspx
tietoa tekijästä
Sergey Gigoyan on tietokanta ammattilainen yli 10 vuoden kokemus, jossa keskitytään tietokannan suunnittelu, kehittäminen, suorituskyvyn viritys, optimointi, korkea saatavuus, BI ja DW suunnittelu.Katso kaikki vinkkini
artikkeli päivitetty viimeksi: 2015-11-18