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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 16.05.2007, 11:27   #1  
sergeypp is offline
sergeypp
Ищу людей. Дорого.
Аватар для sergeypp
 
433 / 174 (6) ++++++
Регистрация: 08.11.2003
Адрес: Казань
Существуют ли механизмы свертывания базы?
Возвращаюсь к старой теме (http://forum.mazzy.ru/index.php?showtopic=7148) под новым соусом )..
Проводил еще раз подобное исследование. Как будет рости база при 500 магазинов. На текущий момент их 42. Ожидается вливание других сетей в нашу розничную сеть.
Поднял бакап за 3 февраля. Сверяю с бакапом от 3 мая. Разница 3 месяца.
Выбрал таблицы, размер которых увеличился. В соответствии со статьей (http://axapta.mazzy.ru/lib/dbgrowthsolution/) исключил все таблицы, которые можно чистить.
Среди остальных таблиц определили те, чей рост непосредственно зависит от увеличения кол-ва магазинов и их продаж и те, чей рост косвенно зависит от роста кол-ва магазинов
В результате получилась примерная статистика. За 3 месяца работы 42 магазнов
таблицы дали следующий прирост
непосредственные - 3517424 Кб
косвенные - 130552 Кб
В сумме 3517424 + 130552/2 = 3582700 Кб или 3500 Мб
Получается что за 1 месяц 1 магазин дает прирост в 27,77 Мб
Т.е. при 500 магазинах. прирост базы получается 13884 Мб. За год это 162,7 Гб
Цифры пугают.

Есть ли какие нибудь механизмы свертки данных, что бы избежать такого роста БД.
Можно конечно изменить топологию системы. Оставить центральный сервер, куда будет сливаться консолидированная информация, а все магазины поделить на 7-10 дивизионов и для каждого поставить свой сервер. Тогда возникает масса вопросов: как синхронизировать информацию, как ее консолидировать, как организовать работу сводного планирования..
Старый 16.05.2007, 11:50   #2  
Doctor Watson is offline
Doctor Watson
Участник
 
4 / 10 (1) +
Регистрация: 22.01.2007
Если база на Оракле, то есть стандартный механизм в самой СУБД.
Старый 16.05.2007, 11:59   #3  
sergeypp is offline
sergeypp
Ищу людей. Дорого.
Аватар для sergeypp
 
433 / 174 (6) ++++++
Регистрация: 08.11.2003
Адрес: Казань
нет MSSQL 2000 и интересуют механизмы собственной самой Аксапты и желательно без уменьшения производительности
Старый 16.05.2007, 12:07   #4  
Yprit is offline
Yprit
Злыдни
Аватар для Yprit
Злыдни
 
419 / 93 (4) ++++
Регистрация: 22.02.2004
Адрес: СПб
Я озадачивался похожими вопросами и в результате пришел к следующей схеме:
1) Данные в базе хранятся за период, необходимый для принятия оперативных решений
2) Историческая информация сливается в ХД и доступна через ОЛАП
3) Вводится регламент по периодической "очистке базы от данных".

Т.е. дополнительных штатных способов уменьшения размеры базы, кроме как описанных у Сергея, я не нашел.
Старый 16.05.2007, 12:16   #5  
Doctor Watson is offline
Doctor Watson
Участник
 
4 / 10 (1) +
Регистрация: 22.01.2007
Цитата:
Сообщение от Yprit Посмотреть сообщение
Я озадачивался похожими вопросами и в результате пришел к следующей схеме:
1) Данные в базе хранятся за период, необходимый для принятия оперативных решений
2) Историческая информация сливается в ХД и доступна через ОЛАП
3) Вводится регламент по периодической "очистке базы от данных".

Т.е. дополнительных штатных способов уменьшения размеры базы, кроме как описанных у Сергея, я не нашел.
+1
На SQL делали так же в свое время.
Старый 16.05.2007, 12:42   #6  
komar is offline
komar
Шаман форума
Аватар для komar
Ex AND Project
 
5,571 / 600 (32) +++++++
Регистрация: 24.05.2002
Цитата:
Сообщение от Yprit Посмотреть сообщение
Я озадачивался похожими вопросами и в результате пришел к следующей схеме:
1) Данные в базе хранятся за период, необходимый для принятия оперативных решений
2) Историческая информация сливается в ХД и доступна через ОЛАП
3) Вводится регламент по периодической "очистке базы от данных".

Т.е. дополнительных штатных способов уменьшения размеры базы, кроме как описанных у Сергея, я не нашел.
Из штатного - периодическая очистка всевозможных временных таблиц, объединение общих таблиц при помощи виртуальных компаний, отключение лишних ключей. Но все равно это не заменит ХД - это единственно правильный вариант.
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately.
Старый 16.05.2007, 13:04   #7  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Цитата:
Сообщение от sergeypp Посмотреть сообщение
Как будет рости база при 500 магазинов. На текущий момент их 42. ..... За год это 162,7 Гб Цифры пугают.
У нас 40 магазинов, полтора года, база 130 Гб. Если у вас Axapta Retail от Коруса, то могу кое-что посоветовать применительно конкретно к этому решению. И еще вопрос: у вас в Аксапту информация о ежедневных продажах магазинов сливается с какой точностью? С точностью до чека? С точностью до товара ? Есть ли дублирование информации о продажах в разных таблицах ? (например, в Axapta Retail данные о продажах лежат в спец.таблицах + в заказах (salestable,salesline) + в накладных по заказам)). Тогда можно уменьшить базу путем уменьшения точности хранения за старые периоды и устранения дублирования.
Старый 16.05.2007, 14:58   #8  
sergeypp is offline
sergeypp
Ищу людей. Дорого.
Аватар для sergeypp
 
433 / 174 (6) ++++++
Регистрация: 08.11.2003
Адрес: Казань
2 Yprit
Что понимается под ХД ? хранилище данных?
2 Zabr
да. у нас Retail от Коруса. по поводу точности хранения сейчас более граммотно ответит наш программист..
Старый 16.05.2007, 15:07   #9  
Yprit is offline
Yprit
Злыдни
Аватар для Yprit
Злыдни
 
419 / 93 (4) ++++
Регистрация: 22.02.2004
Адрес: СПб
Цитата:
Сообщение от sergeypp Посмотреть сообщение
2 Yprit
Что понимается под ХД ? хранилище данных?
Да, именно оно
Старый 16.05.2007, 18:19   #10  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Цитата:
Сообщение от sergeypp Посмотреть сообщение
2 Yprit
да. у нас Retail от Коруса. по поводу точности хранения сейчас более граммотно ответит наш программист..
ОК.
Тогда несколько советов по уменьшению базы в Axapta Retail :

1) по периодам, по которым сдан бух.баланс, удалить в базе записи документов для экспорта во внешние системы (если, конечно, он у вас включен) - это таблички, оканчивающиеся на _EXT. Их у вас может оказаться несколько миллионов (или даже десятков миллионов).

2) по закрытым периодам удалить строки реализации (таблица RetailCashReportLine), удалить связанные с этой реализацией заказы (SalesTable, SalesLine), но оставив накладные по ним. Это тоже вероятно миллионы записей. Предварительно посмотрите, где у вас используется историческая информация из RetailCashReportLine - у нас это только пара отчетов, наверняка и у вас тоже только отчеты. В таком случае, эти отчеты нужно слегка переделать, чтобы они брали данные не из RetailCashReportLine, а из строк накладных по реализации.

3) если у вас используются автозаказы и заполняется таблица для их расчета - InventRemains, то можете удалять все её записи, которые старее, чем период расчета средней продаваемости. Там тоже может быть несколько миллионов записей.

4) отключите запись логов изменений по тем таблицам, в которых очень много записей и исследованием логов которых вы никогда не занимались - скоре всего и далее они вам не потребуются.

5) если при удалении закупок/заказов они не удаляются из базы, а переносятся в аннулированные, то имеет смысл их тоже периодически чистить

6) проверьте, как у вас настроены права на перемещения между складами и магазинами. Если у вас слишком много людей имеет неизвестно зачем права на перемещение между любыми складами, то таблица USERRIGHTSINVENTLOCATION у вас распухнет немеряно. Например, у нас, несмотря на предпринятые меры по оптимизации прав, размер этой таблицы - 1 млн. 700 тыс записей (!), что составляет в базе около 250 Мб. (Так уж криво реализованы эти права).

7) если у вас регулярно и часто используются терминалы сбора данных, то посмотрите, фиксируются в Аксапте логи их работы. Вы можете неожиданно обнаружить, что соотв. табличка CMSTERMINALLOG отжирает сотни мегабайт (или даже гигабайты) места в базе.

Последний раз редактировалось Zabr; 16.05.2007 в 18:23. Причина: дополнение
Старый 16.05.2007, 21:55   #11  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от sergeypp Посмотреть сообщение
Выбрал таблицы, размер которых увеличился.
А какие самые быстрорастущие?

Цитата:
Сообщение от sergeypp Посмотреть сообщение
Есть ли какие нибудь механизмы свертки данных, что бы избежать такого роста БД.
Нет.
Есть такие вещи как делать бухпроводки с сверткой (по умолчанию) или без свертки. Но это, скорее всего, не то.

Так, какие таблицы самые быстрорастущие?
__________________
полезное на axForum, github, vk, coub.
Старый 17.05.2007, 10:01   #12  
sergeypp is offline
sergeypp
Ищу людей. Дорого.
Аватар для sergeypp
 
433 / 174 (6) ++++++
Регистрация: 08.11.2003
Адрес: Казань
2 Mazzy
Вот список лидеров.

PHP код:
INVENTTRANS    1092424
SALESLINE    378704
LEDGERTRANS    368968
CUSTINVOICETRANS    289360
INVENTTRANSPOSTING    279896
INVENTSUM    260384
FACTURETRANS_RU    236024
TAXTRANS    197192
INVENTJOURNALTRANS    141784
CUSTCONFIRMTRANS    133688
LEDGERJOURNALTRANS    123232
CUSTINVOICEJOUR    94584
CUSTTRANS    86792
SALESTABLE    77912
INVENTDIM    60720
CUSTPACKINGSLIPTRANS    56360
LEDGERBALANCESDIMTRANS    52416
DLVREQUESTLINE    50896
CUSTSETTLEMENT    49584
TAXJOURNALTRANS    46480
INVENTJOURNALTRANSTEMPLATE    42848
CUSTCONFIRMJOUR    41120
RCASHTRANS    38632
WMTRANSFERPARMLINE    37552
LEDGERJOURNALTABLE    32696
PURCHLINE    31640
DLVDOCUMENTQTY    31088
SYSTRACETABLESQL    29744
CUSTPACKINGSLIPJOUR    27312
TRANSACTIONLOG    26200
SDS    25760
CUSTINVOICESALESLINK    25480
PRICEBASEDATA    24640
VENDINVOICETRANS    21920
INVENTJOURNALTABLE    18744
SALESPARMSUBTABLE    18640
CSETCHEQUETABLE    17704
CUSTCONFIRMSALESLINK    17560
SYSLASTVALUE    17184
CSETCHEQUELINE    16360
CUSTTRANSOPEN    15864
CUSTPAYMSCHED    15176
FACTUREJOUR_RU    15168
CUSTVENDTRANSPOSTINGLOG_RU    13968
LEDGERBALANCESTRANS    13360
CUSTPAYMSCHEDLINE    12576
INVENTJOURNALREPORTTABLE_RU    12464
CUSTQUOTATIONTRANS    11968
VENDPURCHORDERTRANS    11112
DLVTRIPREQUESTLINE    10168
DLVREQUEST    10112 
Это прирост в Кб. Отсюда я исключил таблицы-логи.
Старый 17.05.2007, 10:17   #13  
sergeypp is offline
sergeypp
Ищу людей. Дорого.
Аватар для sergeypp
 
433 / 174 (6) ++++++
Регистрация: 08.11.2003
Адрес: Казань
Цитата:
Сообщение от Zabr Посмотреть сообщение
1) по периодам, по которым сдан бух.баланс, удалить в базе записи документов для экспорта во внешние системы (если, конечно, он у вас включен) - это таблички, оканчивающиеся на _EXT. Их у вас может оказаться несколько миллионов (или даже десятков миллионов).

2) по закрытым периодам удалить строки реализации (таблица RetailCashReportLine), удалить связанные с этой реализацией заказы (SalesTable, SalesLine), но оставив накладные по ним. Это тоже вероятно миллионы записей. Предварительно посмотрите, где у вас используется историческая информация из RetailCashReportLine - у нас это только пара отчетов, наверняка и у вас тоже только отчеты. В таком случае, эти отчеты нужно слегка переделать, чтобы они брали данные не из RetailCashReportLine, а из строк накладных по реализации.

3) если у вас используются автозаказы и заполняется таблица для их расчета - InventRemains, то можете удалять все её записи, которые старее, чем период расчета средней продаваемости. Там тоже может быть несколько миллионов записей.

4) отключите запись логов изменений по тем таблицам, в которых очень много записей и исследованием логов которых вы никогда не занимались - скоре всего и далее они вам не потребуются.

5) если при удалении закупок/заказов они не удаляются из базы, а переносятся в аннулированные, то имеет смысл их тоже периодически чистить

6) проверьте, как у вас настроены права на перемещения между складами и магазинами. Если у вас слишком много людей имеет неизвестно зачем права на перемещение между любыми складами, то таблица USERRIGHTSINVENTLOCATION у вас распухнет немеряно. Например, у нас, несмотря на предпринятые меры по оптимизации прав, размер этой таблицы - 1 млн. 700 тыс записей (!), что составляет в базе около 250 Мб. (Так уж криво реализованы эти права).

7) если у вас регулярно и часто используются терминалы сбора данных, то посмотрите, фиксируются в Аксапте логи их работы. Вы можете неожиданно обнаружить, что соотв. табличка CMSTERMINALLOG отжирает сотни мегабайт (или даже гигабайты) места в базе.
1. Таблиц оканчивающихся на _EXT в базе нет.
2. В таблице RETAILCASHREPORTLINE данных нет
3. Таблицы InventRemains у нас нет
4. А расскажите как?. чего то я не соображу что это ((
5. В курсе
6. В таблице USERRIGHTSINVENTLOCATION нет данных
7. Таблицы CMSTERMINALLOG не существует

Видимо у нас очень разнятся версии..
Старый 17.05.2007, 10:19   #14  
sergeypp is offline
sergeypp
Ищу людей. Дорого.
Аватар для sergeypp
 
433 / 174 (6) ++++++
Регистрация: 08.11.2003
Адрес: Казань
значит механизмов свертывания таблиц INVENTTRANS,LEDGERTRANS и INVENTSUM как таковых не существует?
Старый 17.05.2007, 12:08   #15  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Цитата:
Сообщение от sergeypp Посмотреть сообщение
1. Таблиц оканчивающихся на _EXT в базе нет.
2. В таблице RETAILCASHREPORTLINE данных нет
3. Таблицы InventRemains у нас нет
4. А расскажите как?. чего то я не соображу что это ((
5. В курсе
6. В таблице USERRIGHTSINVENTLOCATION нет данных
7. Таблицы CMSTERMINALLOG не существует

Видимо у нас очень разнятся версии..
Оофигеть. Два совсем разных КорусАксаптаРитейла.

По п.4. Администрирование - Настройки - Журнал базы данных - Ctrl+N. Для всех таблиц настраивается, что писать в логи: создание-изменение-удаление, как для записи в целом, так и по отделным полям. Логи могут занимать немеряно места.
Старый 17.05.2007, 12:23   #16  
Yprit is offline
Yprit
Злыдни
Аватар для Yprit
Злыдни
 
419 / 93 (4) ++++
Регистрация: 22.02.2004
Адрес: СПб
Цитата:
Сообщение от sergeypp Посмотреть сообщение
значит механизмов свертывания таблиц INVENTTRANS,LEDGERTRANS и INVENTSUM как таковых не существует?
Стандартных механизмов свертки по-моему нет. InventSum я лично режу по признаку closed, но
1) Это можно делать, только осознавая все последствия в виде "отваливания" стандартного функционала и
2) За такие советы сильно топчет ногами Сергей, в принципе, обоснованно

Насколько я вижу, у Вас достаточно большое поле для деятельности на строках закупок, заказов, складских журналов и пр.
Старый 17.05.2007, 12:39   #17  
sergeypp is offline
sergeypp
Ищу людей. Дорого.
Аватар для sergeypp
 
433 / 174 (6) ++++++
Регистрация: 08.11.2003
Адрес: Казань
2 Zabr
Ну Вы наверное знаете нашу версию.. Вы в аське с нашим программистом общаетесь. Александр.. компания ДОМО..
2 Yprit. При расчете я исключил эти таблицы.. Сейчас будут устанавливаться сроки для хранения оперативной информации в этих таблицах. Остальное будет бакапиться и резаться.
Я могу выложить полный список всех таблиц с их приростами.. и какие таблицы я суммировал, если это конечно кому-то интересно..
А по поводу отваливания, с этим Вы сталкивались уже??
Старый 17.05.2007, 12:53   #18  
Yprit is offline
Yprit
Злыдни
Аватар для Yprit
Злыдни
 
419 / 93 (4) ++++
Регистрация: 22.02.2004
Адрес: СПб
Цитата:
Сообщение от sergeypp Посмотреть сообщение
А по поводу отваливания, с этим Вы сталкивались уже??
Можно ли чистить InventSum?
Старый 17.05.2007, 14:13   #19  
sergeypp is offline
sergeypp
Ищу людей. Дорого.
Аватар для sergeypp
 
433 / 174 (6) ++++++
Регистрация: 08.11.2003
Адрес: Казань
А в пределах темы
Цитата:
Поэтому правильный алгоритм такой:
1. Найти записи в InventSum для которых InventSum.isAllFieldsZero() == true
2. Найти количество записей InventTrans для каждой записи из InventSum
3. Если количество записей в InventTrans == 0, то InventSum удалять можно.
Найти количество записей InventTrans для каждой записи из InventSum - по каким полям связка??
Старый 17.05.2007, 14:16   #20  
sergeypp is offline
sergeypp
Ищу людей. Дорого.
Аватар для sergeypp
 
433 / 174 (6) ++++++
Регистрация: 08.11.2003
Адрес: Казань
И еще сразу вопрос.. за год прирост 160 Гиг.. еще терпимо, а что делать через 3 года?
Существуют ли решения, при которых одна база сворачивалась и настройки переносились в новую с первоначальными остатками.. само собой историю за прошлый период смотрят в старой базе?.. я конечно понимаю.. что многое полетит, но как вариант "лекарства" возможно?.. еще раз повторяюсь .. реализовывался ли такой вариант?
Теги
архивирование, полезное

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Принципы построения базы данных Гужанов Павел DAX: Администрирование 11 05.09.2008 16:47
Утилиты для работы с журналом базы данных vc DAX: База знаний и проекты 0 10.05.2008 17:40
Размер базы Sergo DAX: Функционал 13 30.10.2006 12:17
Создание полной копии Приложения и базы Perc DAX: Администрирование 5 09.03.2005 07:33
Распределенные базы ???? Alex1009 DAX: Функционал 19 01.12.2004 13:30
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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