AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 14.08.2009, 13:27   #1  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Посоветуйте по чистке CustInvoiceTrans
Ax 4.0, SQL 2005
В нашей базе CustInvoiceTrans - самая большая по занимаемому месту таблица (12.5 Гб, 14 млн.записей). В табличке заполнены текстовые поля:
(1) Name = описание из таблички InventTxt.txt (там или название номенклатуры, или более расширенный текст, в среднем ну пусть будет 50 знаков).
(2) LineHeader = текст вида "Заказ на продажу N такой-то, клиент N такой-то", тоже считаем по 50 знаков.
Отчеты или запросы с этими полями нами нигде не используются.
Вопрос: даст ли реальную экономию места в базе полная очистка этих полей, и как ее можно было бы грубо оценить ? (скажем, в % от занимаемого сейчас места)
Стоит ли такая овчинка выделки?

Последний раз редактировалось Zabr; 14.08.2009 в 13:29.
Старый 14.08.2009, 13:41   #2  
SRF is offline
SRF
Участник
MCBMSS
Axapta Retail User
 
362 / 542 (19) +++++++
Регистрация: 08.08.2007
Записей в блоге: 1
Цитата:
Сообщение от 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 записи (строки)
__________________
Sergey Nefedov

Последний раз редактировалось SRF; 14.08.2009 в 13:50.
Старый 14.08.2009, 13:44   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Zabr Посмотреть сообщение
В нашей базе CustInvoiceTrans - самая большая по занимаемому месту таблица (12.5 Гб, 14 млн.записей). В табличке заполнены текстовые поля:
(1) Name = описание из таблички InventTxt.txt (там или название номенклатуры, или более расширенный текст, в среднем ну пусть будет 50 знаков).
(2) LineHeader = текст вида "Заказ на продажу N такой-то, клиент N такой-то", тоже считаем по 50 знаков.
Дык, ведь... Сам по себе объем не является тормозом для обычных операций. Разве что для полного бэкапа. Или для полной выборки из этих таблиц.

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

Поэтому: если эти поля не входят в индексы - ну и пусть себе живут. Каши не просят.
__________________
полезное на axForum, github, vk, coub.
Старый 14.08.2009, 13:47   #4  
SRF is offline
SRF
Участник
MCBMSS
Axapta Retail User
 
362 / 542 (19) +++++++
Регистрация: 08.08.2007
Записей в блоге: 1
Цитата:
Сообщение от mazzy Посмотреть сообщение
Дык, ведь... Сам по себе объем не является тормозом для обычных операций. Разве что для полного бэкапа. Или для полной выборки из этих таблиц.

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

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

Цитата:
Сообщение от Zabr Посмотреть сообщение
...
Вопрос: даст ли реальную экономию места в базе полная очистка этих полей, и как ее можно было бы грубо оценить ?
__________________
Sergey Nefedov
Старый 14.08.2009, 13:53   #5  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Цитата:
Сообщение от SRF Посмотреть сообщение
Проблема не в производительности, а в занимаемом месте на диске
Да, мой вопрос именно об этом. Я не знаю, как Аксапта выделяет место в базе SQL для текстовых полей. Выдаеляет по фактически занимаемому месту? Тогда имеет смысл почистть. Выделяет по размерности поля, заданной в Daata dictionary? Тогда чистить бесполезно. Произойдет ли освобождение места при чистке уже существующих записей, или это место всё равно останется занятым, и экономия будет достигаться только на новых записях, если эти поля не заполнять? Освободит ли место дефрагментация, если сами записи не удалялись, а только чистились в них эти поля ?
Старый 14.08.2009, 13:59   #6  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Zabr Посмотреть сообщение
Выдаеляет по фактически занимаемому месту?
По фактически занимаемому для строк, выравнянных влево.
http://axapta.mazzy.ru/lib/adjustment/
__________________
полезное на axForum, github, vk, coub.
Старый 14.08.2009, 14:04   #7  
SRF is offline
SRF
Участник
MCBMSS
Axapta Retail User
 
362 / 542 (19) +++++++
Регистрация: 08.08.2007
Записей в блоге: 1
Цитата:
Сообщение от Zabr Посмотреть сообщение
...Выдаеляет по фактически занимаемому месту? Тогда имеет смысл почистть. Выделяет по размерности поля, заданной в Daata dictionary? Тогда чистить бесполезно...
Это зависит от выравнивания, используемого в строковых полях, поскольку на SQL AX создает текстовые поля как varchar, т.е. если выравнивание левое то будет занимать фактически, если правое - то полная размерность поля

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

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

Последний раз редактировалось SRF; 14.08.2009 в 14:05. Причина: P.S. Упс. Опередили.
За это сообщение автора поблагодарили: mazzy (2), Aleksey_M (2).
Старый 14.08.2009, 14:05   #8  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Zabr Посмотреть сообщение
Освободит ли место дефрагментация, если сами записи не удалялись, а только чистились в них эти поля ?
Не то, чтобы освободит.
Фактически занятое место останется прежним. А вот размер базы действительно может уменьшить.

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

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

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

Однако дефрагментацию индексов и таблиц с кластерными индексами выполняет ребилд индексов. А он у вас периодически проводится, насколько я помню. Т.е. остается дефрагментация неиндексированных данных. В принципе провести можно. Но у вас сильного эффекта от этой операции я бы не ожидал.
__________________
полезное на axForum, github, vk, coub.
За это сообщение автора поблагодарили: Zabr (3).
Старый 14.08.2009, 14:12   #9  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Цитата:
Сообщение от Zabr Посмотреть сообщение
Да, мой вопрос именно об этом. Я не знаю, как Аксапта выделяет место в базе SQL для текстовых полей...
Вообще вопрос выделения места в БД непростой. С формальной точки зрения все строковые (не MEMO) поля хранятся как тип VARCHAR - т.е. по фактически занимаемому месту, но там тоже не все просто и есть ньюансы, связанные с организацией страниц, экстентов и т.п.
По вашему вопросу - если очистить эти поля, то мгновенного эффекта это не даст - место останеся выделенным. Чтобы его отдать в пользование нужно как минимум провести реорганизацию таблички - перестроить индексы (rebuild)? а лучше и всех остальных. Там тоже есть ньюансы - есть на таблтчке кластерный индекс или нет, установленный fillfactor ну и т.д.
Мое ИМХО - эффекта на 12Г таблице будет ну очень мало, а гемора прилично. Посмотрите индекса - может есть лишние, они много места занимают.
ps Пока писал - уже 2 сообщения похожих ;-)
Старый 14.08.2009, 14:15   #10  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от SRF Посмотреть сообщение
Грубая оценка выглядит, так - 50 + 50 = 100 символов = 100 байт на каждую строку
Кстати, в ax4.0 используется unicode и nvarchar.
поэтому надо считать 100 символов = 200 байт
__________________
полезное на axForum, github, vk, coub.
За это сообщение автора поблагодарили: SRF (1).
Старый 14.08.2009, 16:12   #11  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от 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 (1), Logger (2).
Старый 14.08.2009, 16:28   #12  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Цитата:
Сообщение от Vadik Посмотреть сообщение
Вообще странно, что не INVENTTRANS с INVENTSETTLEMENT, ну да ладно
Inventsettlement самая большая по числу записей, а Custinvoicetrans - по занимаемому месту в базе. Это специфика сетевой розницы.

Цитата:
Сообщение от Vadik Посмотреть сообщение
Очистка, которую Вы хотите сделать, связана с незначительной, но все же потерей данных. Если есть уверенность в том, что потребность перепечатать все накладые клиенту за прошлые периоды не возникнет и пара сэкономленных гигабайт важны - почему бы и нет?
Может быть, есть смысл посмотреть в сторону других опций типа Reducing Database Size by Using Vardecimal Storage Format или даже следующих версий СУБД (SQL SERVER 2008, data compression)
Поскольку наша торговля - розничная, то накладные не печатаются (тут другие требования к документам). А за ссылку спасибо.
Старый 14.08.2009, 16:32   #13  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Э-э-э. Радикально.
Вадим, ты сам этим советом пользовался? Каких побочных явлений стоит ждать?
__________________
полезное на axForum, github, vk, coub.
Старый 14.08.2009, 16:54   #14  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,689 / 405 (17) +++++++
Регистрация: 23.03.2006
Цитата:
Сообщение от mazzy Посмотреть сообщение
Кстати, в ax4.0 используется unicode и nvarchar.
поэтому надо считать 100 символов = 200 байт
+ символ конца строки
Старый 14.08.2009, 17:26   #15  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Цитата:
Сообщение от mazzy Посмотреть сообщение
Э-э-э. Радикально.
Вадим, ты сам этим советом пользовался? Каких побочных явлений стоит ждать?
Я не Вадим, но немного прояснить могу
Фича хорошая. И не только в качестве меры борьбы с размером базы. Реально уменьшает нагрузку на дисковую подсистему, но увеличивает нагрузку на процессор (не особо критично - до 20% в зависимости от данных), ибо распаковка происходит уже в памяти!
Но поскольку сейчас век многоядренных процов, то ИМХО (да и сточки зреня разработчиков СУБД) нето не сильно сказывается на общей нагрузке процессора.
На Оракле есть доже и по-моему давно.
Единственное что - для 2005 я бы не стал, наверное, использовать ибо работает только на Enterprise редакции, и на Standart уже не развернешь базу! А в 2008 ИМХО круче поюзать PAGE компрессию.
ps Вот интересная статейка - http://www.oszone.net/print/6832/
За это сообщение автора поблагодарили: mazzy (2).
Старый 14.08.2009, 17:59   #16  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Почистил указанные поля в CustInvoiceTrans за 4 месяца прошлого года, это примерно 30% этой таблицы. Очистилось 358 млн.знаков, т.е. около 700 Мб. Как и ожидал, уменьшения размера таблицы MS SQL Management Studio не показал. Посмотрим, даст ли что-то дефрагментация.
Старый 14.08.2009, 18:03   #17  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Zabr Посмотреть сообщение
Почистил указанные поля в CustInvoiceTrans за 4 месяца прошлого года, это примерно 30% этой таблицы. Очистилось 358 млн.знаков, т.е. около 700 Мб. Как и ожидал, уменьшения размера таблицы MS SQL Management Studio не показал. Посмотрим, даст ли что-то дефрагментация.
после удаления она значительно уменьшит занимаемый объем.
__________________
полезное на axForum, github, vk, coub.
Старый 14.08.2009, 18:26   #18  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от mazzy Посмотреть сообщение
Э-э-э. Радикально.
Вадим, ты сам этим советом пользовался?
Пользуюсь
Цитата:
Каких побочных явлений стоит ждать?
При включении пройдет полная реорганизация таблицы, так что стоит запланировать определенный простой. Да, опция недоступна в Standard редакции, так что на ней БД восстановить не удастся. В остальном - для приложения (AX) это изменение проходит прозрачно
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: mazzy (2).
Старый 15.08.2009, 18:24   #19  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Vadik Посмотреть сообщение
Может быть, есть смысл посмотреть в сторону других опций типа Reducing Database Size by Using Vardecimal Storage Format или даже следующих версий СУБД (SQL SERVER 2008, data compression)
часть обсуждения выделена сюда Отсюда вопрос - где эффективнее всего использовать данное сжатие ? OLAP системы ? OLTP системы ?
__________________
полезное на axForum, github, vk, coub.
Старый 16.08.2009, 22:02   #20  
aidsua is offline
aidsua
AX*****
Аватар для aidsua
 
106 / 40 (2) +++
Регистрация: 28.09.2005
Адрес: 2:463/Kyiv
Цитата:
Сообщение от mazzy Посмотреть сообщение
По фактически занимаемому для строк, выравнянных влево.
http://axapta.mazzy.ru/lib/adjustment/
..необходимо добавлять "если не изменено значение на вправо", т.е. уточнить были ли на этих полях подобные модификации.

зы Я не в наезд.. просто программисты разные бывают.
__________________
О, как беден, как груб наш русский язык! [c] А.С.Пушкин
Теги
ax4.0, custinvoicetrans, база данных, как правильно, полезное, сжатие, сжатие базы, чистка

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Метод LineAmountInclTax() на custInvoiceTrans Logger DAX: Программирование 6 05.07.2017 09:31
Создание CustInvoiceJour, CustInvoiceSalesLink, CustInvoiceTrans from X++ DmitrySincerity DAX: Программирование 12 15.12.2008 18:40
Хочу перейти на аксапту, посоветуйте с чего начать? Дедушка DAX: Прочие вопросы 4 04.04.2008 22:34
CustInvoiceTrans кластерный индекс Tarrash DAX: Программирование 25 25.03.2008 10:25
Посоветуйте как мне сделать так чтобы номенклатура в отчете группировалась Hans DAX: Программирование 4 27.12.2005 15:17
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 18:48.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.