By: Sergey Gigoyan | Updated: 2015-11-18 | Comments (9) | Related: More > Adatbázisfelügyelet
probléma
az SQL Server lehetővé teszi egynél több tranzakciós naplófájl használatát, de felmerül a kérdés, hogy szükséges-eés mi az előnye a több tranzakciós naplófájlnak. Van egy tévhit között egyes fejlesztők, hogy miután multipetransaction log fájlokat növelheti a teljesítményt, mert az SQL Server tudja használni őket párhuzamosan. Az SQL Server jelenleg csak egy tranzakciós naplófájlt használ, ebben az esetben nincs párhuzamosság. Néha több naplófájl is lehetszükséges a hibaelhárításhoz. Tehát általában nincs szükség egynél több naplófájlra.Vegyünk egy esetet, amikor az adatbázisunk több naplófájlt tartalmaz, és csak egyet kell megtartanunk.Ennek a tippnek az a célja, hogy leírja, hogyan lehet helyesen eltávolítani a felesleges naplófájlokat, és csak egyet megtartani.
megoldás
mielőtt elkezdenénk bemutatni, hogyan lehet eltávolítani a felesleges naplófájlokat, röviden írjuk le, hogyan működik az SQL Server a naplófájlokkal: ha az adatbázisnak egynél több naplófájlja van,az SQL Server addig írja az elsőt, amíg meg nem telik, majd átvált a másodikra és így tovább. Miután az utolsó naplófájl megtelt, az SQL Server visszatér az elsőhöz, és a ciklus folytatódik.Azonban, mint említettük, néha egynél több naplófájlra lehet szükség. Például amikor a lemez, ahol a naplófájl találhatómegteljesedik, és létre kell hoznunk a második naplófájlt egy másik helyen, de a probléma elhárítása után törölnünk kell a második naplófájlt,mert nincs szükség egynél több naplófájlra.Most tegyük fel, hogy van egy adatbázisunk két naplófájllal, a mi feladatunk pedig a második eltávolítása.A következő parancsfájl létrehozza a TestDB adatbázist két naplófájllal és TestTable táblával. Ahhoz, hogy egyedül futtassa, ki kell cserélnie”D:\SQL adatok” meglévő mappaútvonallal.
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
most értsük meg a tranzakciós napló fizikai szerkezetét: a belső tranzakciós naplófájl a következőkből áll: virtuális naplófájlok (VLF), amelyek a tranzakciós naplófájl kezelési egységei. Ez azt jelenti, hogy amikor az database engine növekszik vagy összezsugorodik a naplófájl, akkor ezt Teljes VLF-ekkel teszi (például nem tudja összezsugorítani a VLF felét). A virtuális naplófájlok mérete, valamint azok száma a fizikai naplófájlban nincs rögzítve, és dinamikusan kezeli az adatbázismotor. Nyomon követésea tranzakciós naplófájl belülhasználjuk a” DBCC LOGINFO ” parancsot, amely információkat nyújt a virtuális naplófájlokról. Az alábbi szkriptben ezt a parancsot használtuk az adatbázisunkhoz:
--Getting log files infoDBCC LOGINFO('TestDB')
az eredmény pedig a következő:
A FileID az adatbázisunk naplófájl-azonosítója. Az állapot azt jelzi, hogy VLF újrafelhasználható vagynem (lehetséges értékek: 0 – Igen, 2-nem). Mint láthatjuk, csak egy VLF vanstatus=2. Most, amikor beillesztjük az adatokat a Teszttáblába, és figyelemmel kísérjük a naplófájlok növekedését:
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
ezzel a példával láthatjuk, hogy mindkét naplófájl nőtt, és most a második naplófájlban (FileID=3) is vannak “Status=2” VLF-ek:
most el kell távolítanunk a TestDB_log2-t.ldf fájl. Ne feledje, hogy csak a másodlagos naplófájlokat tudjuk eltávolítani. Eltávolításaz elsődleges naplófájlt az SQL Server nem engedélyezi.Minden adatbázisnak csak egy elsődleges naplófájlja van, és az első naplófájl, amelyet az adatbázis-létrehozási parancsfájl hoz létre, elsődlegesnek tekinthető.Ha megpróbáljuk eltávolítani a második naplófájlt:
USE masterGO--Remove TestDB_log2 fileALTER DATABASE TestDB REMOVE FILE TestDB_log2
a következő üzenetet kapjuk:
a tranzakciós naplófájlt csak akkor tudjuk eltávolítani, ha az üres, ezért először ki kell üríteni it.To ha megteszed, vissza kell írnunk a tranzakciós naplót. Mivel a” TestDB ” adatbázisunk újonnan jött létre, és nincsenek teljes biztonsági mentések, teljes adatbázis-biztonsági mentést kell kiadnunk a TestDB adatbázishoz, amely után kiadhatunk egy tranzakciós napló biztonsági mentést:
--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'
a tranzakciónapló biztonsági mentése csonkolja a naplófájlt (van néhány kivétel, amelyek nem tartoznak a thistip hatálya alá). A napló csonkítása törli az inaktív virtuális naplófájlokat a logikai napló elejéről, és helyet szabadít fel a naplófájlban. A csonkolás azonban nem csökkenti a fizikai naplófájl méretét. Csak helyet szabadít fel benne, amelyet újra fel lehet használni. Futtassuk újra a “DBCC LOGINFO” – t:
mint látható, nincsenek virtuális naplófájlok a “TestDB_log2.ldf ” fájl Status=2 és most a log fájl üres és készen áll az eltávolításra:
--Remove TestDB_log2 fileALTER DATABASE TestDB REMOVE FILE TestDB_log2
az Eltávolítás sikeres.
amikor azonban újra ellenőrizzük a naplózási információkat, látni fogjuk, hogy a logikai naplófájl még mindig létezik:
--Checking log informationSELECT file_id, name, type_desc, physical_name, size, max_sizeFROM sys.database_files
ha újabb naplómentést készítünk, a fájl törlődik:
--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
következő lépések
- tartsa szem előtt ezt a tippet a tranzakciós napló használatának meghatározásához és a szükségtelen naplófájl eltávolításához.
- nézze meg ezeket a forrásokat:
- Adatbázisfelügyeleti / tranzakciós napló
- 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
A szerzőről
Sergey Gigoyan több mint 10 éves tapasztalattal rendelkező adatbázis-szakember, amelynek középpontjában az adatbázis-tervezés, a fejlesztés, a teljesítményhangolás, az optimalizálás, a magas rendelkezésre állás, a BI és a DW tervezés áll.az összes tippem megtekintése
a cikk utolsó frissítése: 2015-11-18