Я не хороший у SQL, але у мене є база даних, яку потрібно підтримувати.
Тут майже не залишилось місця, тому я вирішив видалити всі дані, скажімо, 2008 року. Після виконання запиту на видалення (очищено близько 10 000 000 рядків) та очищення журналу транзакцій я з’ясував, що мій дії не впливали на розмір бази даних. Я ще маю щось робити?
Відповіді:
Хоча скорочення небезпечно справді з причин, зазначених тут. Між відповіддю Джимбо та відповіддю Джона є щасливе середовище ... Ви завжди повинні серйозно задуматися про те, чи хочете ви зменшити свою базу даних.
В ідеальному світі - ви б створили свою БД з великою кількістю вільного простору. Я називаю це "правильним розміром" вашої бази даних. Ви б дозволили цьому вільному простору бути там, а не прагнути повернути його і зберегти загальний розмір прямо на використаний розмір .. Чому? Тому що ваша база даних з часом знову зростатиме. Тоді ви знову скорочуватиметесь .. І ви будете застрявати в цій жахливій схемі марних скорочень, що супроводжуються зростаннями - і весь час, як мало хто вказував, ви будете збільшуючи фрагментацію вашого індексу.
Я веду щоденник про це, де я закликав людей " Не торкайся цієї кнопки зменшення! ", Але іноді ... Іноді потрібно. Якщо у вас є велика база даних, ви просто звільнили значне місце і не сподіваєтесь на неї знову врости - ну тоді добре вважати скорочення як разовою операцією, поки ви зможете піклуватися про фрагментацію свого індексу згодом шляхом відновлення. їх. Операція скорочення може зайняти багато часу, тому ви хочете запланувати її на час, коли ви можете заплатити цю ціну скороченої роботи. Підхід створення порожнього БД та копіювання даних у нього працює - але це може стати дуже складним при великих базах даних та великій кількості даних.
Якщо ви плануєте додавати цей простір до БД за допомогою звичайних моделей використання та зростання в майбутньому, ви можете просто захотіти залишити місце там.
Також
Ви сказали, що "очистили" журнал транзакцій. Мені буде цікаво дізнатися, як ви це зробили, але, читаючи публікацію, про яку я поділився, та інші в серії, ви побачите поради щодо управління журналом транзакцій. Але коротше - якщо ви перебуваєте в режимі повного відновлення, вам слід регулярно робити резервні копії журналу, щоб журнал повторно використовував себе. Інакше - без резервного копіювання журналу, перебуваючи в повному режимі - файл журналу постійно зростає та зростає та зростає, і завжди зберігає те, що ви зробили, тому що ви сказали SQL, що ви не просто хочете підтримувати цей журнал для відновлення аварійних ситуацій, але хочете зберегти вручну створити резервну копію для відтворення транзакцій / скасування транзакцій для відновлення до певного моменту для цілей відновлення ... Якщо ви просто і бачите, щоб журнал надмірно зростав,BEGIN TRAN ... do work.... COMMIT TRANчи ви просто видали одну велику DELETEзаяву та видалили цілий безлад даних за одну неявну транзакцію.)
Я також припускаю, що ви шукаєте це вільне місце у вашій файловій системі. Якщо ви шукаєте його в SQL та в тому великому файлі, який у вас є - можливо, ви чекаєте завершення очищення привидів, якщо шукаєте відразу після операції. Блоги Пола Рандала про очищення від привидів .
Видалення рядків у базі даних не зменшить фактичний розмір файлу бази даних.
Вам потрібно ущільнити базу даних після видалення рядків.
SQL Server 2005 DBCC SHRINKDATABASE (Transact-SQL)
Запустивши це, вам потрібно буде відновити індекси. Зменшення зазвичай спричиняє фрагментацію індексу, і це може бути значною вартістю продуктивності.
Я також рекомендую після зменшення файлів повторно рости файли, щоб у вас було вільного місця. Таким чином, при появі нових рядків вони не запускають автоматичний ріст. Автозростання коштує від продуктивності і чогось ви хочете уникати (шляхом належного розміру бази даних), коли це можливо.
НЕ ПІДТРИМУЙТЕ СВОЮ БАНКУ!
"Чому це відбувається? Операція скорочення файлів даних працює на одному файлі за один раз і використовує растрові карти GAM (див. Inside The Storage Engine: GAM, SGAM, PFS та інші карти розподілу), щоб знайти найвищу сторінку, виділену в Потім він переміщує його якнайбільше до передньої частини файлу, і так далі, і т. д. У випадку вище, він повністю змінив порядок кластерного індексу, переймаючи його від ідеально дефрагментованого до ідеально фрагментованого. "
http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx
"Подивіться на іронію бази даних Shrinking. Одна людина скорочує базу даних, щоб отримати простір (думаючи, що це сприятиме продуктивності), що призводить до збільшення фрагментації (зниження продуктивності). Щоб зменшити фрагментацію, один індекс відновить, що призводить до розміру база даних збільшується набагато більше, ніж початковий розмір бази даних (до скорочення). Ну, зменшуючись, людина не здобув того, що шукав, як правило ".
Коли ви видаляєте дані, SQL Server залишає простір для подальшого використання для вставки нових даних. Вам потрібно скоротити базу даних. Ви можете знайти більше інформації тут .
Я знайшов це, тому що я просто видалив купу резервних таблиць, тому що моя база даних "вимкнулася". Я постійно переглядав властивість "Розмір", думаючи, чому цього не стає менше? . Прочитавши це, ні, я не хочу скорочувати базу даних. Що я хочу зробити, це "повернути" місце для щойно видаленого мотлоху. Те, що мені потрібно було подивитися, - це "Доступний простір". Я думаю, може, це те, що комусь іншому, можливо, теж слід буде дивитись на це?
Варто також зазначити, що якщо у таблиці є індекси на ній, фрагментація може існувати після видалення великих пробілів даних. Сьогодні у мене була таблиця, на якій було розміщено ~ 70 млн записів, що займає близько 13 ГБ. Я очистив її до 1639 записів (решта були згенеровані однією помилкою), але таблиця все ще займала близько 4,5 ГБ. Після того як я відновив усі індекси на таблиці, він зайняв лише 85 сторінок (680 кб). Після цього я використав інкрементальний термоусадочний файл, щоб повернути простір (і виправив помилку в системі, щоб запобігти повторенню).