Посоветуйте по чистке CustInvoiceTrans

[mazzy]

Цитата:

Сообщение от Zabr

В нашей базе CustInvoiceTrans - самая большая по занимаемому месту таблица (12.5 Гб, 14 млн.записей). В табличке заполнены текстовые поля:
(1) Name = описание из таблички InventTxt.txt (там или название номенклатуры, или более расширенный текст, в среднем ну пусть будет 50 знаков).
(2) LineHeader = текст вида "Заказ на продажу N такой-то, клиент N такой-то", тоже считаем по 50 знаков.

Дык, ведь... Сам по себе объем не является тормозом для обычных операций. Разве что для полного бэкапа. Или для полной выборки из этих таблиц.

Вот если эти поля входят в индексы. Тогда да, вставка, обновление и удаление могут серьезно затормозиться. Кроме того, увеличивается время на пересчет статистики.

Поэтому: если эти поля не входят в индексы - ну и пусть себе живут. Каши не просят.

[SRF]

Цитата:

Сообщение от mazzy

Дык, ведь... Сам по себе объем не является тормозом для обычных операций. Разве что для полного бэкапа. Или для полной выборки из этих таблиц.

Вот если эти поля входят в индексы. Тогда да, вставка, обновление и удаление могут серьезно затормозиться. Кроме того, увеличивается время на пересчет статистики.

Поэтому: если эти поля не входят в индексы - ну и пусть себе живут. Каши не просят.

Проблема не в производительности, а в занимаемом месте на диске

Цитата:

Сообщение от Zabr

...
Вопрос: даст ли реальную экономию места в базе полная очистка этих полей, и как ее можно было бы грубо оценить ?

[Zabr]

Цитата:

Сообщение от SRF

Проблема не в производительности, а в занимаемом месте на диске

Да, мой вопрос именно об этом. Я не знаю, как Аксапта выделяет место в базе SQL для текстовых полей. Выдаеляет по фактически занимаемому месту? Тогда имеет смысл почистть. Выделяет по размерности поля, заданной в Daata dictionary? Тогда чистить бесполезно. Произойдет ли освобождение места при чистке уже существующих записей, или это место всё равно останется занятым, и экономия будет достигаться только на новых записях, если эти поля не заполнять? Освободит ли место дефрагментация, если сами записи не удалялись, а только чистились в них эти поля ?

[mazzy]

Цитата:

Сообщение от Zabr

Выдаеляет по фактически занимаемому месту?

По фактически занимаемому для строк, выравнянных влево.
http://axapta.mazzy.ru/lib/adjustment/

[aidsua]

Цитата:

Сообщение от mazzy

По фактически занимаемому для строк, выравнянных влево.
http://axapta.mazzy.ru/lib/adjustment/

..необходимо добавлять "если не изменено значение на вправо", т.е. уточнить были ли на этих полях подобные модификации.

зы Я не в наезд.. просто программисты разные бывают.

[SRF]

Цитата:

Сообщение от Zabr

...Выдаеляет по фактически занимаемому месту? Тогда имеет смысл почистть. Выделяет по размерности поля, заданной в Daata dictionary? Тогда чистить бесполезно...

Это зависит от выравнивания, используемого в строковых полях, поскольку на SQL AX создает текстовые поля как varchar, т.е. если выравнивание левое то будет занимать фактически, если правое - то полная размерность поля

Цитата:

Сообщение от Zabr

...Произойдет ли освобождение места при чистке уже существующих записей, или это место всё равно останется занятым, и экономия будет достигаться только на новых записях, если эти поля не заполнять? Освободит ли место дефрагментация, если сами записи не удалялись, а только чистились в них эти поля ?...

Тут не уверен, но по идее в случае левого выравнивания полей должно произойти освобождение места, кстати попробуйте проверить на какой-нибудь тестовой табличке.

А вообще не проще ли удалить поля физически, в смысле, повесить на какой-нибудь конфигурационный ключ и отключить его, вель я как понял вы не собираетесь дальше пользоваться этим полями.

[mazzy]

Цитата:

Сообщение от Zabr

Освободит ли место дефрагментация, если сами записи не удалялись, а только чистились в них эти поля ?

Не то, чтобы освободит.
Фактически занятое место останется прежним. А вот размер базы действительно может уменьшить.

SQL хранит данные в страницах. Причем, SQL сознательно заполняет страницы не полностью (тут длинная теория почему именно так. см. BOL).
А с диска читаются именно страницы (на самом деле наборы из подряд идущих страниц - кластера).

Это значит, что если страницы заполненны не полностью, то диск все равно тратит время и ресурсы на чтение полного кластера. Поэтому чем выше степень заполнения страниц, чем меньше фрагментация, тем меньше дисковых операций будет выполнено для чтения того же набора данных. (Однако высокая степень заполнения может ухудшить время операций вставки и обновления. См. все ту же теорию).

Насколько я помню, у вас была очень высокая степень фрагментированности данных. Дефрагментация вам действительно может помочь.

Однако дефрагментацию индексов и таблиц с кластерными индексами выполняет ребилд индексов. А он у вас периодически проводится, насколько я помню. Т.е. остается дефрагментация неиндексированных данных. В принципе провести можно. Но у вас сильного эффекта от этой операции я бы не ожидал.

[egorych]

Цитата:

Сообщение от Zabr

Да, мой вопрос именно об этом. Я не знаю, как Аксапта выделяет место в базе SQL для текстовых полей...

Вообще вопрос выделения места в БД непростой. С формальной точки зрения все строковые (не MEMO) поля хранятся как тип VARCHAR - т.е. по фактически занимаемому месту, но там тоже не все просто и есть ньюансы, связанные с организацией страниц, экстентов и т.п.
По вашему вопросу - если очистить эти поля, то мгновенного эффекта это не даст - место останеся выделенным. Чтобы его отдать в пользование нужно как минимум провести реорганизацию таблички - перестроить индексы (rebuild)? а лучше и всех остальных. Там тоже есть ньюансы - есть на таблтчке кластерный индекс или нет, установленный fillfactor ну и т.д.
Мое ИМХО - эффекта на 12Г таблице будет ну очень мало, а гемора прилично. Посмотрите индекса - может есть лишние, они много места занимают.
ps Пока писал - уже 2 сообщения похожих ;-)