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

[Zabr]

Ax 4.0, SQL 2005
В нашей базе CustInvoiceTrans - самая большая по занимаемому месту таблица (12.5 Гб, 14 млн.записей). В табличке заполнены текстовые поля:
(1) Name = описание из таблички InventTxt.txt (там или название номенклатуры, или более расширенный текст, в среднем ну пусть будет 50 знаков).
(2) LineHeader = текст вида "Заказ на продажу N такой-то, клиент N такой-то", тоже считаем по 50 знаков.
Отчеты или запросы с этими полями нами нигде не используются.
Вопрос: даст ли реальную экономию места в базе полная очистка этих полей, и как ее можно было бы грубо оценить ? (скажем, в % от занимаемого сейчас места)
Стоит ли такая овчинка выделки?

[SRF]

Цитата:

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

Ax 4.0, SQL 2005
В нашей базе CustInvoiceTrans - самая большая по занимаемому месту таблица (12.5 Гб, 14 млн.записей). В табличке заполнены текстовые поля:
(1) Name = описание из таблички InventTxt.txt (там или название номенклатуры, или более расширенный текст, в среднем ну пусть будет 50 знаков).
(2) LineHeader = текст вида "Заказ на продажу N такой-то, клиент N такой-то", тоже считаем по 50 знаков.
Отчеты или запросы с этими полями нами нигде не используются.
Вопрос: даст ли реальную экономию места в базе полная очистка этих полей, и как ее можно было бы грубо оценить ? (скажем, в % от занимаемого сейчас места)
Стоит ли такая овчинка выделки?

В чем подвох? Ответ содержится в самом вопросе.

Грубая оценка выглядит, так - 50 + 50 = 100 символов = 100 байт на каждую строку, записей 14 млн. => 1400 млн. байт, т.е. порядка 1.2 Гб, т.е. 10%, а стоит ли овчинка выделки, решать Вам

P.S. Вот еще не давно обсуждалась тема размер 1 записи (строки)

[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/

[SRF]

Цитата:

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

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

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

Цитата:

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

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

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

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

[mazzy]

Цитата:

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

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

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

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

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

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

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

[egorych]

Цитата:

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

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

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

[mazzy]

Цитата:

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

Грубая оценка выглядит, так - 50 + 50 = 100 символов = 100 байт на каждую строку

Кстати, в ax4.0 используется unicode и nvarchar.
поэтому надо считать 100 символов = 200 байт

[Vadik]

Цитата:

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

Ax 4.0, SQL 2005
В нашей базе CustInvoiceTrans - самая большая по занимаемому месту таблица (12.5 Гб, 14 млн.записей)

Вообще странно, что не INVENTTRANS с INVENTSETTLEMENT, ну да ладно

Цитата:

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

Очистка, которую Вы хотите сделать, связана с незначительной, но все же потерей данных. Если есть уверенность в том, что потребность перепечатать все накладые клиенту за прошлые периоды не возникнет и пара сэкономленных гигабайт важны - почему бы и нет?
Может быть, есть смысл посмотреть в сторону других опций типа Reducing Database Size by Using Vardecimal Storage Format или даже следующих версий СУБД (SQL SERVER 2008, data compression)

[Zabr]

Цитата:

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

Вообще странно, что не INVENTTRANS с INVENTSETTLEMENT, ну да ладно

Inventsettlement самая большая по числу записей, а Custinvoicetrans - по занимаемому месту в базе. Это специфика сетевой розницы.

Цитата:

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

Очистка, которую Вы хотите сделать, связана с незначительной, но все же потерей данных. Если есть уверенность в том, что потребность перепечатать все накладые клиенту за прошлые периоды не возникнет и пара сэкономленных гигабайт важны - почему бы и нет?
Может быть, есть смысл посмотреть в сторону других опций типа Reducing Database Size by Using Vardecimal Storage Format или даже следующих версий СУБД (SQL SERVER 2008, data compression)

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

[mazzy]

Цитата:

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

Reducing Database Size by Using Vardecimal Storage Format

Э-э-э. Радикально.
Вадим, ты сам этим советом пользовался? Каких побочных явлений стоит ждать?

[ice]

Цитата:

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

Кстати, в ax4.0 используется unicode и nvarchar.
поэтому надо считать 100 символов = 200 байт

+ символ конца строки

[egorych]

Цитата:

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

Э-э-э. Радикально.
Вадим, ты сам этим советом пользовался? Каких побочных явлений стоит ждать?

Я не Вадим, но немного прояснить могу
Фича хорошая. И не только в качестве меры борьбы с размером базы. Реально уменьшает нагрузку на дисковую подсистему, но увеличивает нагрузку на процессор (не особо критично - до 20% в зависимости от данных), ибо распаковка происходит уже в памяти!
Но поскольку сейчас век многоядренных процов, то ИМХО (да и сточки зреня разработчиков СУБД) нето не сильно сказывается на общей нагрузке процессора.
На Оракле есть доже и по-моему давно.
Единственное что - для 2005 я бы не стал, наверное, использовать ибо работает только на Enterprise редакции, и на Standart уже не развернешь базу! А в 2008 ИМХО круче поюзать PAGE компрессию.
ps Вот интересная статейка - http://www.oszone.net/print/6832/

[Zabr]

Почистил указанные поля в CustInvoiceTrans за 4 месяца прошлого года, это примерно 30% этой таблицы. Очистилось 358 млн.знаков, т.е. около 700 Мб. Как и ожидал, уменьшения размера таблицы MS SQL Management Studio не показал. Посмотрим, даст ли что-то дефрагментация.

[mazzy]

Цитата:

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

Почистил указанные поля в CustInvoiceTrans за 4 месяца прошлого года, это примерно 30% этой таблицы. Очистилось 358 млн.знаков, т.е. около 700 Мб. Как и ожидал, уменьшения размера таблицы MS SQL Management Studio не показал. Посмотрим, даст ли что-то дефрагментация.

после удаления она значительно уменьшит занимаемый объем.

[Vadik]

Цитата:

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

Э-э-э. Радикально.
Вадим, ты сам этим советом пользовался?

Пользуюсь

Цитата:

Каких побочных явлений стоит ждать?

При включении пройдет полная реорганизация таблицы, так что стоит запланировать определенный простой. Да, опция недоступна в Standard редакции, так что на ней БД восстановить не удастся. В остальном - для приложения (AX) это изменение проходит прозрачно

[mazzy]

Цитата:

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

Может быть, есть смысл посмотреть в сторону других опций типа Reducing Database Size by Using Vardecimal Storage Format или даже следующих версий СУБД (SQL SERVER 2008, data compression)

часть обсуждения выделена сюда Отсюда вопрос - где эффективнее всего использовать данное сжатие ? OLAP системы ? OLTP системы ?

[aidsua]

Цитата:

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

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

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

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