Скорочення бази даних нижче початкового розміру

У мене є база даних розробників SQL-сервера 2005 року, яка представляє 30 ГБ копії прямої трансляції. Ми видалили деякі дані, які не потрібні у програмі розробки, що знижує кількість використаних файлів даних до 20 Гб. Таким чином, у нас є близько 33% невикористаних.

Мені потрібно повернути простір, який дозволить нам мати другий БД розробки на сервері (на основі скороченої версії); однак я не можу повернути пробіл, я зробив наступне:

• Початковий розмір файлу SMS2_Data- 30 Гб.

  DBCC SHRINKFILE (N'SMS2_Data' , 0, TRUNCATEONLY)

  слідом за ним

  DBCC SHRINKFILE (N'SMS2_Data' , 19500)

Ніякої радості. Я спробував створити резервну копію, створивши нову БД з низьким початковим розміром, потім відновивши, не радість, оскільки початковий розмір буде перезаписаний. Також спробували:

ALTER DATABASE SMS2HazSub MODIFY FILE (NAME = 'SMS2_Data', SIZE = 20000) 

Це помилилося, сказавши:

Не вдалося змінити файл. Зазначений розмір менше, ніж поточний розмір.

Я спробував 20800, а потім продовжував іти до 29000 (29 Гб), і це все ще не дозволить мені змінити його.

Зробили усадочною потім змінив режим відновлення з FULLдо SIMPLEі назад. Ніякої радості.

Я думав, що це стосується якихось TEXTполів. У нас близько 6 по всій системі. Тож як тест я скинув їх усіх, а потім зменшив файл і все ще не змінився.

Залишився єдиний варіант - повторно імпортувати дані до іншої БД. Це не практично, так як це потрібно було б зробити на прямій БД, що несе в собі занадто великий ризик. Ми напіврегулярно захоплюємо копію живого БД і перезаписуємо dev / test. У нас є щось на кшталт 500 столів. Мені б хотілося, щоб це було зроблено так, щоб не було ризику експорту даних до нової БД.

Я спробував перемістити дані в інший файл, і він скопіював усі, крім 5% даних. Це те, що спонукає мене спробувати скинути всі текстові стовпці.

Сервер перебуває в режимі сумісності 90, але є SP2. Зараз я робив наступні 3 рази: перевстановлюю всі таблиці, створює резервну базу даних, зменшує файл, зменшує базу даних. Ще немає радості.

EXECUTE sp_spaceused повертає:

database_name   database_size   unallocated space
SMS2Tests       31453.94 MB     13903.16 MB

reserved     data         index_size   unused
16545568 KB  10602264 KB  4254360 KB   1688944 KB

Як уже згадували деякі люди, ви можете створити нову базу даних і "скопіювати" речі зі старої бази даних. Це був би найкращий варіант для вас. Однак я помітив, що ви хочете робити це досить регулярно. Тож ваш найкращий варіант - порівняння даних Redgate та порівняння Redgate . Обидва є частиною пакету Redgate SqlToolbelt .

Отже, що ви робите:

1. Створіть порожній БД з невеликим початковим розміром.
2. Використовуйте Redgate Compare для копіювання структури DB, функцій тощо зі старого db
3. Використовуйте порівняння даних Redgate для копіювання даних зі старої бази даних в нову
4. Ви працюєте над базою даних розробників, а потім у будь-який час ви робите просто Порівняння даних та регулярно оновлюєте БД Dev, або якщо ви вносите будь-які зміни в db, ви можете розгорнути ці зміни, використовуючи Redgate Compare, а потім виконати Redgate Data Compare.

Що добре з Порівнянням даних, це те, що після копіювання цих 30 Гб даних (ви можете це робити, починаючи лише з деяких таблиць) через деякий час, потрібно просто «підготувати» лише деякі зміни, а не цілі 30 Гб даних. Це означає, що це зробить набагато менший вплив на обидві бази даних, тоді як це скопіювало б його нормально.

Тут є кілька можливостей.

Перш за все, ви перебуваєте на SQL 2005 SP3 чи пізнішої версії? Деякі повідомили про проблеми SHRINKFILE у попередніх версіях (див. Http://www.sqlservercentral.com/Forums/Topic981292-146-6.aspx#bm985164 )

По-друге, чи можете ви перевірити, що база даних встановлена ​​в режимі сумісності 90, а не в режимі 80? Це, мабуть, було проблемою для SQL 2000, але обмеження було знято в SQL 2005. Якщо ваша база даних все ще встановлена ​​на сумісність в режимі 80, це все ще може бути проблемою.

По-третє, це може бути проблема з даними LOB (текст, ntext, varchar (max)). Дивіться чудову статтю Пола Рандалла тут

Я припускаю, що ви розумієте, що насправді робить SHRINKing, і що це може негативно вплинути на вашу ефективність:

• SHRINK працює шляхом сліпого переміщення сторінок від кінця файла до початку
• Таким чином, він може жахливо фрагментувати індекси, що може спричинити значні проблеми з ефективністю
• Оскільки його така оперативна робота з інформацією, скорочення може зайняти значний час

Зазвичай я б рекомендував відслідковувати скорочення за допомогою повного реіндекса (який поверне частину простору, щойно звільненого), але це не здається, що ви навіть зможете дістатися до цієї точки.

Якщо ви дивитесь на зменшений SPID на моніторі активності, чи здається, що він щось робить? (Змінюються лічильники IO та процесора) Або заблоковано? Єдине інше, що я можу придумати, - це якщо в базі даних є інша активність, що блокує зменшення. Переконайтеся, що в даний час в базі даних не використовуються інші активні павуки.

Під час цього процесу перехід у режим простого відновлення також є хорошою ідеєю, щоб журнал не надто зростав.

Якщо ви дійсно хочете це зробити:

• встановити для режиму відновлення просто
• пам'ятайте про: DBCC SHRINKDATABASE (MyDatabase, TRUNCATEONLY);

SHRINKDATABASE лише скоротить базу даних (у кращому випадку) до свого MinSize, так що вам не допоможе.

Коли ви намагаєтеся зменшити FILE через інтерфейс SSMS, використовуючи параметри за замовчуванням, він використовує "DBCC SHRINKFILE (N'MyDB ', 0, TRUNCATEONLY)". Ця команда лише зменшить файл (у кращому випадку) до останнього виділеного обсягу.

Якщо ви хочете зменшити файл під MinSize, просто змініть параметр на DBCC SHRINKFILE0 від розміру, до якого ви хочете спробувати зменшити файл у МБ. Ненульове число скаже SHRINKFILE зменшити файл, якщо це можливо. Так DBCC SHRINKFILE('MyDB', 300, TRUNCATEONLY)буде зменшено файл до 300 Мб, якщо в базі даних є місце.

Ви можете побачити MinSize, виконавши це:

DBCC TRACEON(3604)
go
DBCC PAGE('MyDB', 1, 0, 3) with tableresults
go

MinSize в МБ обчислюється таким чином: (MinSize * 8) / 1024

Якщо у базі даних є, скажімо, 20003 (mb) фактичних datat, то "SIZE = 20000" було б занадто мало. Спробуйте з 21000 або 25000, подивіться, чи це працює. (І пам’ятайте, 1 ГБ = 1024 МБ.)

Спробуйте

DBCC SHRINKDATABASE (N'SMS2_Data' , 0)

Я використовував це в базі даних SQL 2005, яку я маю тут, і виділений простір для файлу даних перейшов від 10,2 ГБ до 3 ГБ.

Fyi, це тривалий процес, і для моєї бази даних було потрібно трохи більше 19 хвилин.

Я припускаю, що у вас є один файл бази даних з логічним іменем SMS2_Data. У базі даних також є один або кілька файлів журналу транзакцій.

Виникла проблема, яку неможливо виправити на поточній копії бази даних. Важливою інформацією, яку ви заявляєте, є те, що "оригінальний розмір файлу бази даних - 30 ГБ". На жаль, цей файл не можна скоротити менше, ніж його початковий розмір.

Як ви вже відчували, SHRINKDB і SHRINKFILE не дають вам того, що ви хочете. Ці команди слідують правилу розміру менше, ніж початковий розмір. Отже, ви можете лише скоротити базу даних до початкового розміру і не менше.

Резервне копіювання та відновлення бази даних до існуючої меншої бази даних також не працює. Коли ви робите відновлення бази даних, файли бази даних відновлюються до розмірів файлів такими, якими вони були під час резервного копіювання. І модель відновлення (проста, повна тощо) не має відношення до цього питання.

І, останній пункт про погані новини. Ви можете розглянути можливість додавання до бази даних інших, менших файлів бази даних, перенести всі дані з файлу об'ємом 30 ГБ, а потім видалити їх. На жаль, це не працюватиме, оскільки ви не можете видалити початковий файл із бази даних.

Отже, найкраще рішення - скопіювати дані в іншу базу даних. Тут у вас є кілька варіантів, і, можливо, ви вже їх знаєте. Першим кроком є ​​створення нової бази даних розміром, меншим за розмір даних. Потім ви можете розширити розмір бази даних до потрібного розміру.

Ви можете розглянути SSIS як спосіб передачі даних з однієї бази даних в іншу. Ви знайдете завдання з копіювальною базою даних, яке допоможе вам вирішити. Ви можете скористатися наступними кроками:

1. Створіть нову базу даних меншого розміру, ніж вихідна база даних
2. Настройте пакет SSIS із завданням бази даних передачі. Поставте завдання використовувати онлайн-передачу.
3. Запустіть пакет SSIS.
4. Пакет SSIS може змінити розмір бази даних відповідно до розміру вихідної бази даних. Зменшіть цю базу даних, оскільки вона має менший розмір оригінального файлу.

Див. Додаткову інформацію про завдання бази даних передачі SSIS .

Деякий невикористаний простір у базі даних є нормальним.
Якщо у вас багато великих записів (скажімо, довгих рядків), на сторінках даних може бути багато невикористаного місця (оскільки один запис зазвичай не розділений між сторінками).
Інша справа - коефіцієнт заповнення - спочатку кластерні індекси не створюються на 100% повними, щоб уникнути розбиття сторінок (дорога операція) при наступних вставках.
Якщо з бази буде видалено безліч даних, раніше зайнятий цими даними простір автоматично не буде повернутий - він залишатиметься виділеним у таблиці.

Спробуйте зателефонувати DBCC DBREINDEX (table_name, '', 100)до кожної таблиці вашої бази даних - вона відновить усі індекси зі 100% -ним коефіцієнтом заповнення, тому дані розмістяться максимально компактно. Потім спробуйте скоротити базу даних ще раз.

Я виявив, що скорочення бази даних SQL Server може бути проблемою. Таке враження, що вам належить виконати пісенний та танцювальний рутин.

Я зазвичай проходжу цей процес:

Резервне зменшення бази даних Резервне копіювання журналу та файлів бази даних окремо. Резервне копіювання Повторюйте, поки воно остаточно не скоротиться.

Мені довелося робити цей процес кілька разів до трьох разів, щоб він нарешті спрацював. У нас була база даних розміром понад 68 Гб, із 98% невикористаного простору. Пройшов цей пісенно-танцювальний порядок кілька разів, але він нарешті зменшився до рівня менше 1 Гб.

Я б спробував спочатку зменшити початковий розмір файлу mdf до 29 000 МБ, потім до 28 000, виявивши близьке звернення.

Нерозумно очікувати зменшення розміру файлів бази даних на 30%, видаливши 30% даних.

Ви можете оцінити, скільки невикористаного простору у вашій базі даних

execute sp_spaceused

в контексті вашої бази даних (використовуйте своє ім'яdatabaename;)
Чи можете ви розмістити результат її виконання?

Оновлення:
я розмістив відповідне запитання на ньому:

• стиснення, дефрагментація, рекультивація простору, скорочення бази даних проти зменшення файлів