Защо не трябва да компресирате вашите файлове с данни
Един от най-горещите ми проблеми се отнася до компресирането на файлове с данни. Въпреки че притежавах кода за компресиране, когато бях в Microsoft, нямах възможност да го пренапиша, за да го направя по-хубав. Наистина не харесвам компресията.
Моля, не бъркайте компресията на регистъра на транзакциите с компресията на файла с данни. Компресирането на регистрационен файл е необходимо, ако вашият регистрационен файл е нараснал извън границите си или когато се отървете от прекомерната фрагментация на виртуални регистрационни файлове (вижте тук (на английски) и тук (на английски) отличните статии на Кимбърли). Въпреки това, свиването на регистрационния файл на транзакциите трябва да бъде рядка операция и никога не трябва да бъде част от редовна програма за поддръжка, която изпълнявате.
Компресирането на файлове с данни трябва да се прави още по-рядко, ако изобщо се прави. И ето защо - компресирането на файл с данни причинявасериознафрагментация на индекса. Позволете ми да демонстрирам това с прост скрипт, който можете да стартирате сами. Скриптът по-долу ще създаде файл с данни, ще създаде 10MB таблица "неща" в началото на файла с данни, ще създаде 10MB "производствен" клъстерен индекс и след това ще анализира фрагментацията на новия клъстерен индекс.
Логическата фрагментация на клъстерирания индекс преди компресиране е близо до идеалните 0,4%.
Сега ще изпусна таблицата за пълнене, ще стартирам свиване, за да освободя място, и ще проверя отново за фрагментация на клъстерен индекс:
Еха! След компресиране логическата фрагментация е почти 100%. Операцията на свиваненапълнофрагментира индекса, премахвайки всякакъв шанс за ефективно сканиране на диапазон на този индекс, като гарантира, че всички I/O сканиране на превантивен диапазон са I/O от една страница.
Защослучи ли се това Операцията за компресиране на файл с данни работи върху един файл наведнъж и използва глобалната карта за разпределение (GAM) (вижте Вътре в системата за съхранение: GAM, SGAM, PFS и други карти за разпределение), за да намерите най-новата страница, разпределена във файл. След това премества тази страница възможно най-близо до началото на файла и повтаря тази операция отново и отново. В ситуацията по-горе това напълно обърна реда на клъстерирания индекс, превръщайки го от напълно дефрагментиран в напълно фрагментиран.
Същият код се използва в командите DBCC SHRINKFILE, DBCC SHRINKDATABASE и autoshrink - те са еднакво лоши. И заедно с фрагментирането на индекса, компресирането на файлове с данни генерира много I/O, използва много време на процесора и генерираголямброй записи в регистъра на транзакциите - защото всичко, което прави, се регистрира напълно.
Компресирането на файлове с данни никога не трябва да бъде част от редовната поддръжка и НИКОГА, НИКОГА не трябва да активирате автоматично компресиране. Опитах се да го премахна от SQL Server 2005 и SQL Server 2008, когато бях в състояние да го направя - единствената причина, поради която все още е там, е обратната съвместимост. Не попадайте в капана на създаването на план за поддръжка, който възстановява всички индекси и след това се опитва да възстанови мястото, заето от повторното изграждане на индекса, като изпълнява свиване - това е игра с нулева сума, в която всичко, което правите, е да генерирате записи в регистъра на транзакциите с нулева реална полза от производителността.
Кога може датрябвада започнете да компресирате? Например, ако сте изтрили по-голямата част от много голяма база данни и е малко вероятно базата данни да се разраснеили ако трябва да изчистите файл, преди да го изтриете?
Препоръчвам следния метод:
- Създайте нова файлова група
- Преместете всички включени таблици и индекси в новата файлова група, като използвате синтаксиса CREATE INDEX ... WITH (DROP_EXISTING = ON) ON, за да преместите таблиците и да ги дефрагментирате едновременно
- Изтрийте старата файлова група, която сте възнамерявали да свиете така или иначе (или я свийте до максимум, ако това е основната файлова група)
Ако нямате абсолютно никакъв избор и трябва да изпълните операция за компресиране на файл, бъдете готови да причините фрагментация на индекса и трябва да предприемете стъпки, за да го почистите по-късно, ако причини проблеми с производителността. Единственият начин да премахнете фрагментацията на индекса, без да увеличавате файла с данни, е да използвате DBCC INDEXDEFRAG или ALTER INDEX ... REORGANIZE. Тези команди изискват допълнителна една 8K страница, вместо да се налага да създавате изцяло нов индекс в случай на операция за възстановяване.
В крайна сметка - опитайте се да избягвате компресиране на файлове на всяка цена!
Можете да помогнете и да прехвърлите средства за развитието на сайта