Есть некая БД, в которой находится таблица с одним из реквизитов типа ntext.
Посколько по устареванию данных содержимое этого реквизита становится не нужным, а сами строки таблицы — нужны, то выполняется регламент по очистке полей: update table set field = '' where условие
База потихоньку разрастает и периодически шринкается. Замечено, что после этого регламета размер базы не уменьшается.
При экспорте данных в чистую таблицу — размер становится вполне соответствующим разумным представлениям.
Как можно сжать такую БД штатными или нештатными средствами?
Здравствуйте, DenisCh, Вы писали:
DC>Есть некая БД, в которой находится таблица с одним из реквизитов типа ntext.
ntext — моветон. Тип данных устарел еще версию назад.
DC>Посколько по устареванию данных содержимое этого реквизита становится не нужным, а сами строки таблицы — нужны, то выполняется регламент по очистке полей: update table set field = '' where условие
А почему не
update table set field = null
?
DC>База потихоньку разрастает и периодически шринкается. Замечено, что после этого регламета размер базы не уменьшается. DC>При экспорте данных в чистую таблицу — размер становится вполне соответствующим разумным представлениям.
DC>Как можно сжать такую БД штатными или нештатными средствами?
Сжатие (шринк) работающей базы — плохая практика. Распределение нового дополнительного места из файловой системы очень дорогая операция. Зачем вообще базу сжимать?
Здравствуйте, _d_m_, Вы писали:
DC>>Есть некая БД, в которой находится таблица с одним из реквизитов типа ntext. ___>ntext — моветон. Тип данных устарел еще версию назад.
Не моя база, не я её автор. Для перехода на другой тип данных придётся переписывать приложение.
DC>>Посколько по устареванию данных содержимое этого реквизита становится не нужным, а сами строки таблицы — нужны, то выполняется регламент по очистке полей: update table set field = '' where условие ___>А почему не ___>
___>update table set field = null
___>
___>?
Делал, результат тот же.
DC>>Как можно сжать такую БД штатными или нештатными средствами? ___>Сжатие (шринк) работающей базы — плохая практика. Распределение нового дополнительного места из файловой системы очень дорогая операция. Зачем вообще базу сжимать?
База стала велика, подтормаживает. Хочется комфортной работы.
Здравствуйте, DenisCh, Вы писали:
___>>А почему не ___>>
___>>update table set field = null
___>>
___>>?
DC>Делал, результат тот же.
Это как-бы было замечание по дизайну БД, ладно, забудь.
DC>>>Как можно сжать такую БД штатными или нештатными средствами? ___>>Сжатие (шринк) работающей базы — плохая практика. Распределение нового дополнительного места из файловой системы очень дорогая операция. Зачем вообще базу сжимать?
DC>База стала велика, подтормаживает. Хочется комфортной работы.
Размер файлов БД на скорость не влияет. Вот фрагментция — да. См. BOL — ALTER INDEX
Сжатие типов данных больших объектов
При реорганизации одного или нескольких индексов типы данных больших объектов (LOB), содержащиеся в кластеризованном индексе или базовой таблице, подвергаются сжатию по умолчанию. Типы данных image, text, ntext, varchar(max), nvarchar(max), varbinary(max) и xml являются типами данных больших объектов. Сжатие этих данных может способствовать более эффективному использованию места на диске.
Реорганизация указанного кластеризованного индекса подвергает сжатию все столбцы типа LOB, содержащиеся на конечном уровне (строки данных) в кластеризованном индексе.
Реорганизация некластеризованного индекса подвергает сжатию все столбцы типа LOB, являющиеся неключевыми (включенными) столбцами в индексе.
При указании ALL реорганизуются все индексы, связанные с указанной таблицей или представлением, и подвергаются сжатию все столбцы LOB, связанные с кластеризованным индексом, базовой таблицей или некластеризованным индексом с включенными столбцами.
Предложение LOB_COMPACTION пропускается, если отсутствуют столбцы LOB.
Здравствуйте, _d_m_, Вы писали:
DC>>База стала велика, подтормаживает. Хочется комфортной работы. ___>Размер файлов БД на скорость не влияет.
Если база целиком в память влезает — ещё как влияет.
___>Вот фрагментция — да. См. BOL — ALTER INDEX
Знаком я с этим
___>Реорганизация указанного кластеризованного индекса подвергает сжатию все столбцы типа LOB, содержащиеся на конечном уровне (строки данных) в кластеризованном индексе.
Кроме того, индекса по этому ntext нет. Или для сжатия его нужно строить?
Здравствуйте, DenisCh, Вы писали:
DC>Здравствуйте, _d_m_, Вы писали:
DC>>>База стала велика, подтормаживает. Хочется комфортной работы. ___>>Размер файлов БД на скорость не влияет.
DC>Если база целиком в память влезает — ещё как влияет.
А причем здесь размер файла БД? Важен объем реальных данных. Сервер читает страницы и экстенты БД в память, а не целые файлы.
___>>Вот фрагментция — да. См. BOL — ALTER INDEX
DC>Знаком я с этим
Как стало видно — недостаточно.
___>>Реорганизация указанного кластеризованного индекса подвергает сжатию все столбцы типа LOB, содержащиеся на конечном уровне (строки данных) в кластеризованном индексе.
DC>Кроме того, индекса по этому ntext нет. Или для сжатия его нужно строить?
Читай внимательно! Еще раз для тех кто в танке:
Реорганизация указанного кластеризованного индекса подвергает сжатию все столбцы типа LOB, содержащиеся на конечном уровне (строки данных) в кластеризованном индексе.
Здравствуйте, _d_m_, Вы писали:
DC>>Кроме того, индекса по этому ntext нет. Или для сжатия его нужно строить? ___>Читай внимательно! Еще раз для тех кто в танке:
А если внимательно почитать меня (с), то может стать понятно, что я эту операцию уже проделал. Безрезультатно.
Здравствуйте, _d_m_, Вы писали:
DC>>Есть некая БД, в которой находится таблица с одним из реквизитов типа ntext.
___>ntext — моветон. Тип данных устарел еще версию назад.
А какой нынче в моде?
Здравствуйте, DenisCh, Вы писали:
DC>Здравствуйте, _d_m_, Вы писали:
DC>>>Кроме того, индекса по этому ntext нет. Или для сжатия его нужно строить? ___>>Читай внимательно! Еще раз для тех кто в танке:
DC>А если внимательно почитать меня (с), то может стать понятно, что я эту операцию уже проделал. Безрезультатно.
1. alter index rebuild аналогичен dbcc dbreindex, а не dbcc indexdefrag.
2. А я и не обещал заметного роста производительности — я лишь сказал, что за место шринка лучше делать alter index. Повторяю последний раз: шринк делать на рабочей БД — плохая практика. Бывает, конечно когда по каким либо причинам файл журнала транзакций становиться слишком велик. Но это не тот случай.
Здравствуйте, Clerk, Вы писали:
DC>>>Есть некая БД, в которой находится таблица с одним из реквизитов типа ntext.
___>>ntext — моветон. Тип данных устарел еще версию назад. C>А какой нынче в моде?
