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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 02.12.2004, 20:19   #1  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Часто жалуются на очень быстрый рост базы данных при работе Microsoft Axapta (до 10 Гб в месяц). Дело в том, что Аксапта при работе создает различные логи. Эти логи помогают выполнять "разбор полетов", но никак не влияют на работу самой Аксапты. В этом совете приводится список таблиц, которые можно безболезненно очищать при работе Аксапты. Благодарю Вадима Гончаренко и Максима Горбунова за ценные дополнения к этому совету.

Подробнее...
http://axapta.mazzy.ru/hints/dbgrowthsolution/
__________________
полезное на axForum, github, vk, coub.
Старый 03.12.2004, 11:51   #2  
Sergik is offline
Sergik
Участник
 
136 / 10 (1) +
Регистрация: 25.08.2004
Адрес: Москва
Спасибо, Сергей за очень полезные советы по очистке таблиц.

В нашем случае суммарный "вес" всех указанных таблиц (за исключением InventSettlement и исторических данных в таблицах закупок и продаж) в общем росте базы данных составляет приблизительно 15 % от общего объема.

Это действительно не мало в абсолютном исчислении, поэтому мы в рабочей базе данных также периодически чистим наиболее существенные из них (в нашем случае это SalesParmLine и SysDataBaseLog).

Выравнивание влево также может дать в нашем случае приблизительно 5 % экономии.

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

Но все эти действительно полезные операции, как следует из вышесказанного, не влияют качественно на снижение общего размера базы данных, поэтому, на мой взгляд, основной стратегией при быстром росте базы данных является проектирование адекватной технической архитектуры системы с учетом перспектив развития (горизонта планирования). Периодическая очистка таблиц здесь - хорошее средство качественного администрирования системы.
Старый 03.12.2004, 12:44   #3  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от serge kotov
В нашем случае суммарный "вес" всех указанных таблиц (за исключением InventSettlement и исторических данных в таблицах закупок и продаж) в общем росте базы данных составляет приблизительно 15 % от общего объема.
..

Таблицы закупок и продаж активно используются в отчетах для анализа ретроспективы бизнеса и поэтому пока не могут быть очищены.
Сергей, у вас ОЧЕНЬ сильно кастомизирована SalesLine . Количество записей в ней тоже, разумеется, недетское

Кстати, а что мешает использовать для анализа не ее, а, например, CustInvoiceTrans?
__________________
-ТСЯ или -ТЬСЯ ?
Старый 03.12.2004, 13:22   #4  
Sergik is offline
Sergik
Участник
 
136 / 10 (1) +
Регистрация: 25.08.2004
Адрес: Москва
Исторические реалии во-первых Не раз уж мысль проскальзывала, эх если бы делать всё сначала, то уж тогда бы...

Во-вторых, сложность с текущими отгрузками.

А в принципе согласен с этой идеей.
Старый 03.12.2004, 14:14   #5  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от serge kotov
Выравнивание влево также может дать в нашем случае приблизительно 5 % экономии.
Выравнивание влево дает экономию в индексах.
Индексы занимают меньше экстентов, следовательно меньше медленных дисковых операций. К тому же больше попаданий в кэш.
__________________
полезное на axForum, github, vk, coub.
Старый 03.12.2004, 15:21   #6  
Sergik is offline
Sergik
Участник
 
136 / 10 (1) +
Регистрация: 25.08.2004
Адрес: Москва
Наверное должно быть так, и мы попытались это оценить, но достоверной разницы в скорости обработки, связанной с индексами при левом и правом выравнивании не получили... впрочем здесь не проводили точного исследования, так что вопрос для нас остался открытым.
Старый 03.12.2004, 15:25   #7  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Да, исследования не помешали бы.

В свое время, еще на 2.5 изменение выравнивания уменьшило базу на 30%. Но это были времена, когда откорреспондированные проводки в LedgerTrans не группировались, когда LedgerTrans была самой емкой таблицей...
__________________
полезное на axForum, github, vk, coub.
Старый 03.12.2004, 15:32   #8  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от serge kotov
Наверное должно быть так, и мы попытались это оценить, но достоверной разницы в скорости обработки, связанной с индексами при левом и правом выравнивании не получили... впрочем здесь не проводили точного исследования, так что вопрос для нас остался открытым.
Это один из тех "кирпичей", из которых складывается общая производительность. Что касается места, занимаемого под данные и индексы, было немного здесь. Что касается скорости обработки, то в вашей БД параметр "процент попаданий в кэш" смысла особого не имеет, так как самые большие таблицы целиком в памяти сидят - чтение (Disk reads) практически отсутствует. Подождите еще год - размер БД удвоится, вернемся к этой теме
__________________
-ТСЯ или -ТЬСЯ ?
Старый 03.12.2004, 15:47   #9  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Vadik
Что касается скорости обработки, то в вашей БД...
Комментарий по поводу ВАШЕЙ БД.
Речь идет об этом случае http://axapta.mazzy.ru/articles/axapta_itanium/

А вообще говоря, процент хитов - важный показатель, за который стоит биться.
__________________
полезное на axForum, github, vk, coub.
Старый 03.12.2004, 16:48   #10  
Sergik is offline
Sergik
Участник
 
136 / 10 (1) +
Регистрация: 25.08.2004
Адрес: Москва
Цитата:
Сообщение от mazzy
mazzy:
А вообще говоря, процент хитов - важный показатель, за который стоит биться.

vadik:
Подождите еще год - размер БД удвоится, вернемся к этой теме
Сейчас кстати состояние счетчика SQL Server\Buffer Manager\Buffer Cache Hit Ratio крутится вокруг 99.85 +-0.03 Так что настроение

Надеюсь через год не вернемся, через 9 месяцев уже запланирован второй в связку Вот только SQL SERVER 2000 EE похоже может адресовать не более 64 GB
Старый 03.12.2004, 17:20   #11  
komar is offline
komar
Шаман форума
Аватар для komar
Ex AND Project
 
5,571 / 600 (32) +++++++
Регистрация: 24.05.2002
Да, а должностных лиц вообще искоренять надо. Вместе с кривыми постановщиками и программистами.
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately.
Старый 21.12.2004, 13:06   #12  
Sergik is offline
Sergik
Участник
 
136 / 10 (1) +
Регистрация: 25.08.2004
Адрес: Москва
Цитата:
Сообщение от serge kotov
Вот только SQL SERVER 2000 EE похоже может адресовать не более 64 GB
Дополнение: SQL Server 2000 64-bit может адресовать 512 GB к счастью.

http://www.microsoft.com/sql/64bit/p...o/overview.asp
 

Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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