DBCC SHRINKDATABASE (Transact-SQL)

• 07/17/2017
• 8 perc olvasás
• • p
  • M
  • j
  • i
  • K
  • +12

Ezekre vonatkozik: SQL Server (minden támogatott verzió) Azure SQL Database Azure Synapse Analytics

A megadott adatbázisban lévő adat- és naplófájlok méretének csökkentése.

Transact-SQL szintaxis konvenciók

Szintaxis

DBCC SHRINKDATABASE ( database_name | database_id | 0 ) 

-- Azure Synapse AnalyticsDBCC SHRINKDATABASE ( database_name ) 

Argumentumok

database_name | database_id | 0
A zsugorítandó adatbázis neve vagy azonosítója. A 0 azt adja meg, hogy az aktuális adatbázist használja.

target_percent
Az adatbázisfájlban az adatbázis zsugorítása után meghagyott szabad hely százalékos aránya.

NOTRUNCATE
A fájl végéről a kijelölt oldalakat a fájl elején lévő nem kijelölt oldalakra helyezi át. Ez a művelet tömöríti az adatokat a fájlban. target_percent opcionális. Az Azure Synapse Analytics nem támogatja ezt az opciót.

A fájl végén lévő szabad hely nem kerül vissza az operációs rendszerhez, és a fájl fizikai mérete nem változik. Így a NOTRUNCATE megadásakor az adatbázis látszólag nem zsugorodik.

A NOTRUNCATE csak az adatfájlokra alkalmazható. A NOTRUNCATE nem érinti a naplófájlt.

TRUNCATEONLY
A fájl végén lévő összes szabad helyet átadja az operációs rendszernek. Nem mozgat lapokat a fájlon belül. Az adatfájl csak az utolsó kijelölt kiterjedésig zsugorodik. Figyelmen kívül hagyja a target_percent értéket, ha a TRUNCATEONLY opcióval van megadva. Az Azure Synapse Analytics nem támogatja ezt az opciót.

A TRUNCATEONLY a naplófájlt érinti. Ha csak az adatfájlt szeretné csonkítani, használja a DBCC SHRINKFILE parancsot.

WITH NO_INFOMSGS
A 0 és 10 közötti súlyossági szintű információs üzenetek elnyomása.

Eredményhalmazok

A következő táblázat az eredményhalmaz oszlopait ismerteti.

Az oszlop neve	Megnevezés
DbId	Az adatbázis azonosítószáma, amelyet az adatbázis-motor zsugorítani próbált.
FileId	Az adatbázis-motor által zsugorítani próbált fájl azonosítószáma.
CurrentSize	A fájl által jelenleg elfoglalt 8 kB-os oldalak száma.
MinimumSize	A fájl által minimálisan elfoglalható 8 kB-os oldalak száma. Ez az érték megfelel a fájl minimális méretének vagy eredetileg létrehozott méretének.
UsedPages	A fájl által jelenleg használt 8 kB-os oldalak száma.
EstimatedPages	A 8 kB-os oldalak száma, amelyre az adatbázis-motor becslése szerint a fájl zsugorítható lenne.

Megjegyzések

Egy adott adatbázis összes adat- és naplófájljának zsugorításához hajtsa végre a DBCC SHRINKDATABASE parancsot. Egy adott adatbázis egy-egy adat- vagy naplófájljának zsugorításához hajtsa végre a DBCC SHRINKFILE parancsot.

Az adatbázisban lévő szabad (ki nem osztott) hely aktuális mennyiségének megtekintéséhez futtassa a sp_spaceused parancsot.

A DBCC SHRINKDATABASE műveletek a folyamat bármely pontján leállíthatók, és az elvégzett munka megmarad.

Az adatbázis nem lehet kisebb, mint az adatbázis konfigurált minimális mérete. A minimális méretet az adatbázis eredeti létrehozásakor adja meg. Vagy a minimális méret lehet az utolsó, kifejezetten a fájlméret megváltoztatása művelettel beállított méret. Az olyan műveletek, mint a DBCC SHRINKFILE vagy az ALTER DATABASE példák a fájlméret-módosító műveletekre.

Tegyük fel, hogy egy adatbázis eredetileg 10 MB méretűre van létrehozva. Ezután 100 MB-ra nő. Az adatbázis legkisebb mérete akkor is 10 MB-ra csökkenthető, ha az adatbázisban lévő összes adat törlésre került.

A DBCC SHRINKDATABASE futtatásakor vagy a NOTRUNCATE opciót, vagy a TRUNCATEONLY opciót adja meg. Ha ezt nem teszi meg, az eredmény ugyanaz lesz, mintha a DBCC SHRINKDATABASE műveletet NOTRUNCATE opcióval, majd a DBCC SHRINKDATABASE műveletet TRUNCATEONLY opcióval futtatja.

A zsugorított adatbázisnak nem kell egyfelhasználós üzemmódban lennie. Más felhasználók is dolgozhatnak az adatbázisban, amikor az zsugorodik, beleértve a rendszeradatbázisokat is.

Nem zsugoríthat egy adatbázist, miközben az adatbázisról biztonsági mentés készül. Fordítva, nem készíthet biztonsági mentést adatbázisról, miközben az adatbázis zsugorítása folyamatban van.

Hogyan működik a DBCC SHRINKDATABASE

A DBCC SHRINKDATABASE az adatfájlokat fájlonként zsugorítja, de a naplófájlokat úgy zsugorítja, mintha az összes naplófájl egy összefüggő naplóállományban létezne. A fájlok mindig a végétől kezdve zsugorodnak.

Tegyük fel, hogy van néhány naplófájl, egy adatfájl és egy mydb nevű adatbázis. Az adat- és naplófájlok egyenként 10 MB méretűek, az adatfájl pedig 6 MB adatot tartalmaz. Az adatbázis-motor kiszámítja az egyes fájlok célméretét. Ez az érték az a méret, amelyre a fájlt zsugorítani kell. Ha a DBCC SHRINKDATABASE a target_percent értékkel van megadva, az adatbázis-motor a célméretet úgy számítja ki, hogy az a zsugorítás után a fájlban szabadon maradt hely target_percent értéke.

Ha például a mydb zsugorításához 25 target_percent értéket ad meg, az adatbázis-motor az adatfájl célméretét 8 MB-ra számítja (6 MB adat plusz 2 MB szabad hely). Így az Adatbázis-motor az adatfájl utolsó 2 MB-nyi adatát az adatfájl első 8 MB-nyi szabad helyére helyezi át, majd zsugorítja a fájlt.

Tegyük fel, hogy a mydb adatfájl 7 MB adatot tartalmaz. A 30-as target_percent megadása lehetővé teszi, hogy ez az adatfájl a 30-as szabad százalékra zsugorodjon. A 40-es target_percent megadása azonban nem zsugorítja az adatfájlt, mivel az adatbázis-motor nem zsugorít egy fájlt kisebb méretűre, mint amekkorát az adatok jelenleg elfoglalnak.

Ezt a problémát máshogy is elképzelhetjük: A 40 százalék keresett szabad hely + 70 százalék teljes adatfájl (7 MB a 10 MB-ból) több mint 100 százalék. Bármilyen 30-nál nagyobb target_size nem zsugorítja az adatfájlt. Azért nem fog zsugorodni, mert a kívánt szabad hely százalékos aránya plusz az adatfájl által jelenleg elfoglalt százalék több mint 100 százalék.

Naplófájlok esetében az adatbázis-motor a target_percent értéket használja a teljes napló célméretének kiszámításához. Ezért a target_percent a zsugorítási művelet után a naplóban lévő szabad hely mennyisége. A teljes napló célméretét ezután lefordítja az egyes naplófájlok célméretére.

DBCC SHRINKDATABASE megpróbál minden egyes fizikai naplófájlt azonnal a célméretre zsugorítani. Tegyük fel, hogy a logikai logikai fájl egyetlen része sem marad a virtuális naplókban a naplófájl célméretén túl. Ekkor a fájl sikeresen lecsökken, és a DBCC SHRINKDATABASE mindenféle üzenet nélkül befejeződik. Ha azonban a logikai napló egy része a célméreten túl a virtuális naplókban marad, az adatbázis-motor a lehető legtöbb helyet felszabadítja, majd tájékoztató üzenetet ad ki. Az üzenet leírja, hogy milyen műveletekre van szükség ahhoz, hogy a logikai logika a fájl végére kikerüljön a virtuális naplókból. A műveletek végrehajtása után a DBCC SHRINKDATABASE segítségével felszabadítható a fennmaradó hely.

A naplófájl csak a virtuális naplófájl határáig zsugorítható. Ezért előfordulhat, hogy egy naplófájlnak a virtuális naplófájl méreténél kisebb méretűre történő zsugorítása nem lehetséges. Lehet, hogy akkor sem lehetséges, ha nem használják. A virtuális naplófájl méretét az adatbázis-motor dinamikusan választja ki a naplófájlok létrehozásakor vagy bővítésekor.

A legjobb gyakorlatok

Az adatbázis zsugorításának tervezésekor vegye figyelembe a következő információkat:

• A zsugorítási művelet egy olyan művelet után a leghatékonyabb, amely kihasználatlan helyet hoz létre, például egy tábla törlése vagy egy tábla elhagyása művelet után.
• A legtöbb adatbázisnak szüksége van némi szabad helyre, hogy a szokásos napi műveletekhez rendelkezésre álljon. Előfordulhat, hogy többször zsugorít egy adatbázist, és azt veszi észre, hogy az adatbázis mérete ismét növekszik. Ez a növekedés azt jelzi, hogy a zsugorított helyre van szükség a rendszeres műveletekhez. Ezekben az esetekben az adatbázis ismételt zsugorítása felesleges művelet.
• A zsugorítási művelet nem őrzi meg az adatbázisban lévő indexek töredezettségi állapotát, és általában bizonyos mértékig növeli a töredezettséget. Ez az eredmény egy újabb ok arra, hogy ne zsugorítsuk ismételten az adatbázist.
• Hacsak nincs különleges követelménye, ne állítsa az AUTO_SHRINK adatbázis-opciót ON-ra.

Hibaelhárítás

Elképzelhető, hogy a zsugorítási műveleteket blokkolja egy olyan tranzakció, amely sorverzió-alapú elszigetelési szint alatt fut. Például egy sorverzió-alapú elkülönítési szint alatt futó nagy törlési művelet van folyamatban, amikor a DBCC SHRINK DATABASE művelet végrehajtásra kerül. Ilyen esetben a zsugorítási művelet megvárja a törlési művelet befejezését, mielőtt zsugorítaná a fájlokat. Amikor a zsugorítási művelet várakozik, a DBCC SHRINKFILE és a DBCC SHRINKDATABASE műveletek kiírnak egy tájékoztató üzenetet (5202 az SHRINKDATABASE és 5203 az SHRINKFILE esetében). Ez az üzenet az első órában ötpercenként, majd a következő órában minden következő órában kiíródik az SQL Server hibanaplójába. Ha például a hibanapló a következő hibaüzenetet tartalmazza:

DBCC SHRINKDATABASE for database ID 9 is waiting for the snapshot transaction with timestamp 15 and other snapshot transactions linked to timestamp 15 or with timestamps older than 109 to finish. 

Ez a hiba azt jelenti, hogy a 109-nél régebbi időbélyegzővel rendelkező pillanatfelvétel tranzakciók blokkolják a zsugorítási műveletet. Ez a tranzakció az utolsó tranzakció, amelyet a zsugorítási művelet befejezett. Ez azt is jelzi, hogy a sys.dm_tran_active_snapshot_database_transactions (Transact-SQL) dinamikus kezelési nézet transaction_sequence_num vagy first_snapshot_sequence_num oszlopai 15 értéket tartalmaznak. A nézetben a transaction_sequence_num vagy a first_snapshot_sequence_num oszlop olyan számot tartalmazhat, amely kisebb, mint a zsugorítási művelet által befejezett utolsó tranzakció (109). Ha ez így van, a zsugorítási művelet megvárja, amíg ezek a tranzakciók befejeződnek.

A probléma megoldásához a következő feladatok valamelyikét végezheti el:

• Végezze el a zsugorítási műveletet blokkoló tranzakciót.
• Végezze el a zsugorítási műveletet. Minden elvégzett munka megmarad.
• Nem tesz semmit, és hagyja, hogy a zsugorítási művelet megvárja a blokkoló tranzakció befejezését.

Jogosultságok

Elvárja a sysadmin fix kiszolgálói szerepkör vagy a db_owner fix adatbázis szerepkör tagságát.

Példák

A. Adatbázis kicsinyítése és a szabad hely százalékos megadása

A következő példa csökkenti az UserDB felhasználói adatbázis adat- és naplófájljainak méretét, hogy az adatbázisban 10 százalék szabad hely legyen.

DBCC SHRINKDATABASE (UserDB, 10); GO 

B. Adatbázis csonkítása

A következő példa a AdventureWorks mintaadatbázis adat- és naplófájljait az utolsó kijelölt terjedelemre zsugorítja.

DBCC SHRINKDATABASE (AdventureWorks2012, TRUNCATEONLY); 

C. Azure Synapse Analytics adatbázisának zsugorítása

DBCC SHRINKDATABASE (database_A);DBCC SHRINKDATABASE (database_B, 10); 

Lásd még

ALTER DATABASE (Transact-SQL)
DBCC (Transact-SQL)
DBCC SHRINKFILE (Transact-SQL)
Adatbázis zsugorítása

.