Существуют ли механизмы свертывания базы?

[sergeypp]

Возвращаюсь к старой теме (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 дивизионов и для каждого поставить свой сервер. Тогда возникает масса вопросов: как синхронизировать информацию, как ее консолидировать, как организовать работу сводного планирования..

[Doctor Watson]

Если база на Оракле, то есть стандартный механизм в самой СУБД.

[sergeypp]

нет MSSQL 2000 и интересуют механизмы собственной самой Аксапты и желательно без уменьшения производительности

[Yprit]

Я озадачивался похожими вопросами и в результате пришел к следующей схеме:
1) Данные в базе хранятся за период, необходимый для принятия оперативных решений
2) Историческая информация сливается в ХД и доступна через ОЛАП
3) Вводится регламент по периодической "очистке базы от данных".

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

[Doctor Watson]

Цитата:

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

Я озадачивался похожими вопросами и в результате пришел к следующей схеме:
1) Данные в базе хранятся за период, необходимый для принятия оперативных решений
2) Историческая информация сливается в ХД и доступна через ОЛАП
3) Вводится регламент по периодической "очистке базы от данных".

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

+1
На SQL делали так же в свое время.

[komar]

Цитата:

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

Я озадачивался похожими вопросами и в результате пришел к следующей схеме:
1) Данные в базе хранятся за период, необходимый для принятия оперативных решений
2) Историческая информация сливается в ХД и доступна через ОЛАП
3) Вводится регламент по периодической "очистке базы от данных".

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

Из штатного - периодическая очистка всевозможных временных таблиц, объединение общих таблиц при помощи виртуальных компаний, отключение лишних ключей. Но все равно это не заменит ХД - это единственно правильный вариант.

[Zabr]

Цитата:

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

Как будет рости база при 500 магазинов. На текущий момент их 42. ..... За год это 162,7 Гб Цифры пугают.

У нас 40 магазинов, полтора года, база 130 Гб. Если у вас Axapta Retail от Коруса, то могу кое-что посоветовать применительно конкретно к этому решению. И еще вопрос: у вас в Аксапту информация о ежедневных продажах магазинов сливается с какой точностью? С точностью до чека? С точностью до товара ? Есть ли дублирование информации о продажах в разных таблицах ? (например, в Axapta Retail данные о продажах лежат в спец.таблицах + в заказах (salestable,salesline) + в накладных по заказам)). Тогда можно уменьшить базу путем уменьшения точности хранения за старые периоды и устранения дублирования.

[sergeypp]

2 Yprit
Что понимается под ХД ? хранилище данных?
2 Zabr
да. у нас Retail от Коруса. по поводу точности хранения сейчас более граммотно ответит наш программист..

[Yprit]

Цитата:

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

2 Yprit
Что понимается под ХД ? хранилище данных?

Да, именно оно

[Zabr]

Цитата:

Сообщение от 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 отжирает сотни мегабайт (или даже гигабайты) места в базе.

[mazzy]

Цитата:

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

Выбрал таблицы, размер которых увеличился.

А какие самые быстрорастущие?

Цитата:

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

Есть ли какие нибудь механизмы свертки данных, что бы избежать такого роста БД.

Нет.
Есть такие вещи как делать бухпроводки с сверткой (по умолчанию) или без свертки. Но это, скорее всего, не то.

Так, какие таблицы самые быстрорастущие?

[sergeypp]

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 


Это прирост в Кб. Отсюда я исключил таблицы-логи.

[sergeypp]

Цитата:

Сообщение от 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 не существует

Видимо у нас очень разнятся версии..

[sergeypp]

значит механизмов свертывания таблиц INVENTTRANS,LEDGERTRANS и INVENTSUM как таковых не существует?

[Zabr]

Цитата:

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

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

Видимо у нас очень разнятся версии..

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

По п.4. Администрирование - Настройки - Журнал базы данных - Ctrl+N. Для всех таблиц настраивается, что писать в логи: создание-изменение-удаление, как для записи в целом, так и по отделным полям. Логи могут занимать немеряно места.

[Yprit]

Цитата:

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

значит механизмов свертывания таблиц INVENTTRANS,LEDGERTRANS и INVENTSUM как таковых не существует?

Стандартных механизмов свертки по-моему нет. InventSum я лично режу по признаку closed, но
1) Это можно делать, только осознавая все последствия в виде "отваливания" стандартного функционала и
2) За такие советы сильно топчет ногами Сергей, в принципе, обоснованно

Насколько я вижу, у Вас достаточно большое поле для деятельности на строках закупок, заказов, складских журналов и пр.

[sergeypp]

2 Zabr
Ну Вы наверное знаете нашу версию.. Вы в аське с нашим программистом общаетесь. Александр.. компания ДОМО..
2 Yprit. При расчете я исключил эти таблицы.. Сейчас будут устанавливаться сроки для хранения оперативной информации в этих таблицах. Остальное будет бакапиться и резаться.
Я могу выложить полный список всех таблиц с их приростами.. и какие таблицы я суммировал, если это конечно кому-то интересно..
А по поводу отваливания, с этим Вы сталкивались уже??

[Yprit]

Цитата:

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

А по поводу отваливания, с этим Вы сталкивались уже??

Можно ли чистить InventSum?

[sergeypp]

А в пределах темы

Цитата:

Поэтому правильный алгоритм такой:
1. Найти записи в InventSum для которых InventSum.isAllFieldsZero() == true
2. Найти количество записей InventTrans для каждой записи из InventSum
3. Если количество записей в InventTrans == 0, то InventSum удалять можно.

Найти количество записей InventTrans для каждой записи из InventSum - по каким полям связка??

[sergeypp]

И еще сразу вопрос.. за год прирост 160 Гиг.. еще терпимо, а что делать через 3 года?
Существуют ли решения, при которых одна база сворачивалась и настройки переносились в новую с первоначальными остатками.. само собой историю за прошлый период смотрят в старой базе?.. я конечно понимаю.. что многое полетит, но как вариант "лекарства" возможно?.. еще раз повторяюсь .. реализовывался ли такой вариант?