Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
selis76 Member Откуда: Сообщений: 368 |
Готовил новую базу из рабочей путем очистки данных. SQL Server 2008 Естественно появилось куча фрагментированных таблиц (с индексами мне все понятно)(база 1С) Сначала попытался сделать shrinkdatabase с опцией перемещения данных в новый файл данных , но она не смогла перенести какие то блоки "Cannot move all contents of file ххххх to other places to complete the emptyfile operation" Как понял это нормально This is because the primary file has contain the metadata and can not be moved but the file other data has been move to the new files. И эти блоки как раз около high watermark. В итоге понял что нужно какое то средство экспорта импорта базы аналогичное как в Oracle , которое восстанавливает данные таблиц и ребилдит индексы. Есть конечно конфигуратор 1С с экспортом импортом , но экспорт импорт 1С хорош для небольших объемов баз и для начального развертывания. Посмотрел bcp и export import wizard , вроде бы они могут это сделать. Но операция восстановления должна делать trancate, потом заполнение данными таблиц, а дальше rebuid индексов а я чтото этих операций в параметрах не увидел. Написание большого скрипта не вдохновляет Вопрос - если ть ли какое то простое универсальное средство или готовый скрипт, которое может сделать операцию экспорта импорта с эффектом дефрагментации таблиц? |
2 окт 15, 13:06 [18225958] Ответить | Цитировать Сообщить модератору |
пьяный тюлень Member Откуда: Сообщений: 100 |
А чем DBCC DBREINDEX не подходит? |
2 окт 15, 13:10 [18225990] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Есть просто https://msdn.microsoft.com/en-us/library/ms189858.aspx Без всяких импортов-экспортов |
||
2 окт 15, 13:10 [18225993] Ответить | Цитировать Сообщить модератору |
selis76 Member Откуда: Сообщений: 368 |
Я именно про дефрагментацию таблиц интересуюсь а не индексов. С индексами все понятно |
2 окт 15, 13:25 [18226135] Ответить | Цитировать Сообщить модератору |
Shakill Member Откуда: мск Сообщений: 1882 |
а что такое дефрагментация таблиц? |
||
2 окт 15, 13:29 [18226158] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
в 2008 есть ALTER TABLE..REBUILD ALTER TABLE (Transact-SQL) |
||
2 окт 15, 13:30 [18226159] Ответить | Цитировать Сообщить модератору |
Кот Матроскин Member Откуда: Москва Сообщений: 8933 |
Они у Вас в куче, что ли, без кластерного индекса? |
||
2 окт 15, 13:36 [18226206] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
1. pages made empty by the delete operation remain allocated to the heap 2. page density |
||||
2 окт 15, 13:45 [18226274] Ответить | Цитировать Сообщить модератору |
selis76 Member Откуда: Сообщений: 368 |
Посмотрел - 1С создает кластерные индексы почти на каждую таблицу, а что это меняет с точки зрения выделения блоков. Неужели перестройка кластерного индекса чтото решит? |
||||
2 окт 15, 18:23 [18228244] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
То и меняет, что у вас почти нет "просто таблиц", т. е. куч, а сплошные "кластерные таблицы", к-ые и имеют в виду, говоря о кластерных индексах. А дефрагментируют их, перестраивая (REBUILD INDEX), и вообще, вам же типа с индексами все ясно... ---- Теперь ответьте на вопрос, с чем вы боретесь и что под фрагментацией подразумеваете. И заодно с чего вы решили, что она есть, и чем она вам мешает. Сейчас навыясняется интересное... (я ставлю на то, что ТС желает просто размер базы уменьшить, причем готов ради этого все нафиг ФРАГМЕНТИРОВАТЬ, благородно обозвав свои действия ДЕФРАГМЕНТАЦИЕЙ) |
||||
2 окт 15, 19:38 [18228645] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
Если у табоицы нет кластерного инедкса, можно его построить и удалить - тогда куча окажется перетроенной (и дефрагментированной).
|
||||
2 окт 15, 20:41 [18228959] Ответить | Цитировать Сообщить модератору |
selis76 Member Откуда: Сообщений: 368 |
Да удаление частичное - грубо говоря убирал движения и документы по определенным юрлицам |
||
5 окт 15, 10:30 [18234850] Ответить | Цитировать Сообщить модератору |
selis76 Member Откуда: Сообщений: 368 |
Я вроде в начала описал ситуацию - после удаления части данных хотел сделать shrink database с опцией перемещения в другой файл данных (иначе бы она сократила бы файл до первого занятого блока). Shrink database полностью с задачей не справился, чтото оставил причем ближе к концу файла. Но вообще попробую сначала сделать полную реиндексацию и посмотрю насколько сработает shrinkdatabase |
||
5 окт 15, 10:39 [18234903] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9633 |
|
||
5 окт 15, 10:49 [18234962] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
я и исхожу из вашего начального описания. вы хотите базу пожать, а не "дефрагментировать". ибо шринком вы как раз и добьетесь еще бОльшей фрагментации индексов, а кучам вообще на это дело все равно, внутри страницы ничего же не уплотняется. так что вы только что подтвердили, что моя ставка верна
вы с самим собой боретесь что ли? вы только что базу пожали, страницы откуда-то там с конца файла ушли в его начало. индексы при этом фрагментировались, т.к. логический порядок следования страниц никто не отслеживал и упорядочились они абы как. теперь вы собираетесь перестроить индексы, чтобы страницы шли по порядку. для этого будет для каждого индекса построен новый, прежде чем дропнут старый. т.е. снова базу раздуете. так вы решите, вам что надо-то, дефрагментацию или сжатие базы? |
||||||
5 окт 15, 11:36 [18235365] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Вы бы сначала определились с конечной целью - нужно ли вам дефрагментировать или же нужно все свободные страницы удалить из файла |
||
5 окт 15, 11:40 [18235394] Ответить | Цитировать Сообщить модератору |
selis76 Member Откуда: Сообщений: 368 |
Если точно нужно убрать все свободные страницы из файла, поскольку при удалении данных из 100 гб освободилось 80 гб. Под фрагментацией я понимаю наличие свободных промежутков между экстентами если это называется как то по другому (кстати как?). Если экстенты в конце файла это мешает shrink. Собственно устроило бы если экстенты уехали в начало файла |
||
5 окт 15, 12:35 [18235756] Ответить | Цитировать Сообщить модератору |
selis76 Member Откуда: Сообщений: 368 |
вы с самим собой боретесь что ли? вы только что базу пожали, страницы откуда-то там с конца файла ушли в его начало. индексы при этом фрагментировались, т.к. логический порядок следования страниц никто не отслеживал и упорядочились они абы как. теперь вы собираетесь перестроить индексы, чтобы страницы шли по порядку. для этого будет для каждого индекса построен новый, прежде чем дропнут старый. т.е. снова базу раздуете. так вы решите, вам что надо-то, дефрагментацию или сжатие базы?[/quot] А Rebuild индексов можно делать с использованием tempdb, как понимаю это спасает от таких проблем. Но в любом случае какой тогда порядок грамотного освобождения свободного пространства в моем случае (допустим все таблицы имеют кластерный индекс)? Полный ребилд индексов с использованием Tempdb (интересно экстенты переберутся в конец?), попытка Shrink и все? |
||
5 окт 15, 12:40 [18235798] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
С такой задачей справляется шринк Если страницы действительно свободны |
||
5 окт 15, 12:41 [18235805] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
нет. что сортировать будет/не будет в темпдб, это именно сортировка. а новый индекс он строит в той же базе, в ее файле данных. так что это выделение нового места в только что ужатом файле.
такого нет. есть или бездумное освобождение места, т.е. шринк, когда страницы из конца файла в начало перемещаются, или наоборот, упорядочивание их, чтобы физический порядок логическому следовал, тут не смотрят на то, будет ли новое место выделено или в имеющемся свободном удастся расположить. обычно рекомендуют перестраивать индексы, но не шринковать базу, т.к. важна скорость чтения, а не размер пустого места в базе. а если у вас индексы вообще все в память умещаются и там висят, то дефрагментировать не надо. или все запросы в основном с точечным поиском, тогда тоже не надо. а пустое место, если база не будет read only, займут вновь прибывшие данные, т.е. нет смысла шринковать, если только не собираетесь больше данные менять/загружать |
||||
5 окт 15, 12:55 [18235902] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |