SQLShack

ez a cikk több SQL Server tranzakciónapló-fájl használatát és a másodlagos tranzakciónapló-fájl eltávolításának folyamatát vizsgálja.

Bevezetés

alapértelmezés szerint az SQL Server-adatbázis elsődleges adatfájlt és tranzakciós naplófájlt tartalmaz. Ez egy jó gyakorlat, amely több adatfájlt konfigurál, és több adatfájlra osztja az adatokat. Ezeket az adatfájlokat külön tároló meghajtókban lehet elhelyezni, hogy több IO legyen. Segíti az adatkezelést, javítja a teljesítményt, a fájlcsoportok szerinti biztonsági mentési megközelítéseket tervezi.

egy adatbázishoz több tranzakciós naplófájl is rendelkezhet.

az SQL Server a több tranzakciós naplófájlt egymás után használja. Tegyük fel, hogy két tranzakciós naplófájlunk van. Az SQL Server egyszerre egy naplófájlt használ, és ha megtelt, az SQL Server egy másik naplófájlt használ. Mivel az SQL Server nem használja párhuzamosan, nem kapunk semmilyen teljesítmény-előnyt. Ideális esetben adatbázisonként csak egy tranzakciós naplófájl legyen.

tegyük fel, hogy van egy termelési adatbázisunk, és kritikus figyelmeztetést kapunk, hogy a lemezből kifogy a hely. A vizsgálat után rájöttünk, hogy ez a meghajtó tartalmaz egy tranzakciós naplófájlt. Az aktív tranzakciók miatt ez az SQL Server tranzakciós naplófájl megtelt. Megpróbáltuk zsugorítani a naplófájlt, de nem működött. Biztonsági másolatot készítünk a tranzakciós naplóról is, de az aktív tranzakciók miatt nem tudta felszabadítani a szükséges helyet. Egy másik tranzakciós naplófájl hozzáadása egy külön lemezre, ahol szabad hely van, megoldja ezt a problémát.

mivel az SQL Server soros módot használ az adatok tranzakciós naplófájlba történő írásához, a további naplófájlt később el kell távolítanunk. Vizsgáljuk meg egy további naplófájl eltávolításának folyamatát.

hozzon létre egy adatbázist több SQL Server tranzakciós Naplófájllal

csatlakozzon egy SQL példányhoz az SQL Server Management Studio alkalmazásban. Kattintson a jobb gombbal az adatbázisok csomópontra az Object Explorer ablaktáblában, majd kattintson az új adatbázis parancsra:

megnyitja az új adatbázis ablakot. Adja meg az adatbázis nevét, és adjon hozzá egy másik tranzakciós naplófájlt. Tesztelés céljából letiltottuk a tranzakciós naplófájlok automatikus növekedését. A tranzakciónapló fájl kezdeti mérete 8 MB:

miután minden be van állítva, kattintson az OK gombra egy adatbázis létrehozásához az alapértelmezett adat – / naplófájl könyvtárban. Hozzon létre egy táblázatot, és helyezze be az adatokat:

a virtuális naplófájl állapotának megtekintése az SQL Server tranzakciós naplófájljaiban

az SQL Server tranzakciós napló architektúrája című cikkben a tranzakciós naplófájl belsejét vizsgáltuk. Minden tranzakciós naplófájl több virtuális naplófájlból áll. A tranzakciós naplófájl több virtuális naplófájl (VLF) kombinációja. A következő képernyőkép a naplófájl fizikai és logikai architektúráját mutatja:

fizikai és logikai architektúrája az SQL Server stats egy adatbázis minimális VLF alapján a kezdeti napló mérete és az auto grow fájl (az auto-Grow konfiguráció alapján). A következő képen bepillantást nyerünk az SQL Server tranzakciós naplófájljába:

egyetlen tranzakciós naplófájl esetén az SQL Server körkörös virtuális naplófájl elérési utat használ. A virtuális naplófájlok számát és állapotát az alábbiak segítségével ellenőrizhetjük:

1. DBCC LOGINFO (‘Database’) – ez egy régi utasítás, és az összes SQL Server verzióval működik
2. dinamikus menedzsment nézet sys. dm_db_log_info (DBID). Elérhető az SQL Server 2016 SP2 vagy újabb

bármelyik parancs használható a VLF ellenőrzéshez. Ehhez a cikkhez a dinamikus menedzsment nézetet (DMV):

a fenti képernyőképen ellenőriztük, hogy a mintaadatbázisunk két tranzakciós naplófájlt tartalmaz (file_id 2 és file_id 3).

• a File_id 2-nek aktív VLF-je van (vlf_active=1 és vlf_status=2)
• a File_id 3-nak nincs aktív VLF-je (vlf_active=0 és vlf_status=2)

helyezzen be még néhány rekordot a táblázatba, hogy az aktív VLF megváltozzon:

a tranzakciónapló – területhasználat figyelése és a VLF állapota a DMV-vel történik (sys. dm_db_log_space_usage):

• VLF állapot

  1 2	válassza ki a DB_name() adatbázisnevet, a File_ID mint transaction_log_file_ID, vlf_active, vlf_status a sys.dm_db_log_info (DB_ID (‘MultileLogFiles’));

• tranzakciós napló használata (használt és szabad terület)

  1 2 3 4 5

  válassza a total_log_size_in_bytes * 1 lehetőséget.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 mint free_log_space_in_MB FROM sys. dm_db_log_space_usage;

a fenti lekérdezések következő kimenetét kapjuk:

• a bal oldalon azt látjuk, hogy amint az elsődleges naplófájl (file_id 2) megtelik, a következő naplófájlra (file_id 3) lép. Ezen a ponton aktív VLF van mind az elsődleges, mind a másodlagos naplófájlokban. Egy teljes helyreállítási modellel rendelkező adatbázisban szükségünk van egy tranzakciós napló biztonsági mentésére, hogy a VLF inaktívként legyen megjelölve
• a jobb oldali kimenet (DMV használatával) a használt tranzakciós napló fájlt mutatja terület 8,51 MB. Mint emlékszik, minden tranzakciós naplófájlhoz 8 MB méretet állítottunk be, és letiltottuk a napló automatikus növekedését. Amikor az elsődleges naplófájl megtelt (8 MB-nál), az SQL Server átvált a másodlagos tranzakciós naplófájlra

a másodlagos SQL Server tranzakciós naplófájl eltávolítása

a másodlagos tranzakciós naplófájl (3.fájlazonosító) eltávolításához a szerkesztett Alter database utasítást fogjuk használni.

hozzáadjuk a fájl eltávolítása záradékot, és megadjuk az eltávolítani kívánt fájlt:

ennek az utasításnak a végrehajtása a következő hibaüzenetet eredményezi:

Megjegyzés: Az aktív tranzakciós naplófájl nem távolítható el.

korábban láttuk, hogy amint az elsődleges naplófájl megtelt, az SQL Server a másodlagos naplófájlt használja. Üressé kell tennünk a másodlagos tranzakciós naplót, hogy eltávolíthassuk.

a teljes helyreállítási modellt tartalmazó SQL adatbázisban tranzakciónapló-mentéseket használunk, így az SQL Server le tudja csonkítani a naplókat. Ehhez több naplómentésre is szükség lehet a tranzakciós napló méretétől, az aktív VLF-től és az aktív tranzakciótól függően.

végezzünk el egy teljes adatbázis-és tranzakciós napló biztonsági mentést:

• teljes adatbázis mentés

  1	backup adatbázis MultipleLogFiles lemezre=’C:\Temp\MultipleLogFiles.bak’

• tranzakciós napló biztonsági mentése

  1	backup log Multilogfiles lemezre=’C:\Temp\MultipleLogFiles_log.trn’

a biztonsági mentés befejezése után ellenőrizze a VLF állapotát. Az aktív VLF-nek az első naplófájlban kell lennie(elsődleges), hogy eltávolíthassuk a másodlagos naplófájlt. Ellenőriztük, hogy csak az elsődleges naplófájl (file_id 2) aktív (VLF állapot 2):

most a másodlagos tranzakciós naplófájlt gond nélkül el kell távolítani. Hajtsuk végre újra a szerkesztett Alter database utasítást. A másodlagos tranzakciós naplófájl eltávolításra kerül:

miután eltávolította a másodlagos tranzakciós naplófájlt, ellenőrizze azt a GUI, valamint a T-SQL használatával a system view sys segítségével.database_files:

az eltávolított másodlagos tranzakciós naplófájl továbbra is jelen van az alábbi képernyőkép szerint:

Most kattintson a jobb gombbal az adatbázisra, és tekintse meg a meglévő fájlokat. Az eltávolított tranzakciós naplófájlt a GUI-ban is látjuk. De miért?

naplófájl ellenőrzése hajtsuk végre újra a szerkesztett Alter database utasítást, és nézzük meg, hogy az SQL Server ismét eltávolítja-e a tranzakciós naplófájlt.

azt az üzenetet kaptuk, hogy az SQL Server nem találja a megadott naplófájlt:

Hibaüzenet az SQL Server eltávolítja a tranzakciós naplófájlt egy későbbi naplómentés után. Vegyünk egy másik naplófájlt, és ellenőrizzük, hogy a tranzakciós naplófájl még létezik-e:

ellenőrizze a tranzakciónapló fájlt mind GUI, mind T-SQL módszerekben. Látjuk, hogy az eltávolított tranzakciós naplófájl most nem jelenik meg.

következtetés

ebben a cikkben a másodlagos SQL Server tranzakciós napló használatát és eltávolításának folyamatát vizsgáltuk. Kerülje a több tranzakciós naplófájl használatát, különösen a termelési adatbázisban. Minden tevékenység megtervezése előtt készítsen biztonsági másolatot az adatbázisról, és tegye meg nem termelékenységi órákban.

• szerző
• Legutóbbi hozzászólások

mint egy MCSA certified és a Microsoft Certified Trainer Gurgaon, India, 13 éves tapasztalattal, Rajendra dolgozik a különböző nagyvállalatok összpontosítva teljesítmény optimalizálás, monitoring, magas rendelkezésre állás, és katasztrófa-helyreállítási stratégiák és végrehajtása. Több száz hiteles cikk szerzője az SQL Server, az Azure, a MySQL, a Linux, a Power BI, a Performance tuning, az AWS/Amazon RDS, a Git és a kapcsolódó technológiák területén, amelyeket eddig több mint 10 millió olvasó nézett meg.
az egyik legnagyobb ingyenes online cikkgyűjtemény alkotója egyetlen témában, az SQL Server Always On Availability Groups című 50 részes sorozatával. Az SQL Server közösséghez való hozzájárulása alapján számos díjjal ismerték el, köztük a rangos “az év legjobb szerzője” 2020-ban és 2021-ben folyamatosan az SQLShack-en.
Raj mindig érdeklődik az új kihívások iránt, így ha tanácsadói segítségre van szüksége az írásaiban szereplő bármely témában, el lehet érni rajendrában.gupta16 @ gmail.com
Rajendra Gupta összes hozzászólásának megtekintése

Rajendra Gupta legújabb hozzászólásai (az összes megtekintése)

• ARM sablonok használata az Azure konténerpéldányok telepítéséhez SQL Server Linux képekkel – December 21, 2021
• Távoli asztali hozzáférés AWS RDS SQL Server számára Amazon RDS Custom-December 14, 2021
• az SQL Server fájlok tárolása az Azure Konténerpéldányok állandó tárolójában-December 10, 2021