Поддержание быстродействия растущей БД

[maximka]

AX 4.0, MSSQL 2008
В условиях постоянно растущей базы возникает вопрос: как сделать так, чтобы общая скорость работы системы и отдельных операций не увеличивалась?
Каждый год удалять "лишние" документы (различные заказы, проводки..)?
Средствами MSSQL дробить данные БД горизонтально на файлы и старые (с реже используемыми данными) файлы кидать на отдельный диск?
Каждый год покупать новый сервак?

Что делаете вы?

[Cheslav]

Цитата:

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

В условиях постоянно растущей базы
Что делаете вы?

Это сколько в гигабайтах?

[mazzy]

Цитата:

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

AX 4.0, MSSQL 2008
Каждый год удалять "лишние" документы (различные заказы, проводки..)?

Во-первых, чистить логи http://axapta.mazzy.ru/lib/dbgrowthsolution/

Во-вторых, четко различать документы/проводки и черновики. Документы/проводки влияют на итоги. Черновики на итоги не влияют (или влияют только на прогнозные итоги). Заказы и журналы - суть черновики. Черновики можно удалять в любой момент.

Никогда не храните данные в заказах и в журналах - их могут удалить в любой момент. Всегда переносите данные в документы и проводки.

В-третьих, Четко следите за проводками, которые можно безболезненно удалить. Например, InventSettlement (where InventSettlement.Cancelled==NoYes::Yes)

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

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

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

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

Другое дело - свертка данных.
Такая штука есть в Навике. Штука забавная. Но очень плохо дружит с локализацией.
В Аксапте свертка есть в одном месте - операция свертки InventSum в периодических операциях \ Очистка \ Очистка складских сопоставлений. Нужно проверять как эта свертка дружит с последними "расширениями" складской аналитики в русском функционале.

В целом, свертка данных - очень тягомотное занятие.

=============
Резюме:
Если вы смотрите на брутто-рост вашей базы в enterprise manager, то не пугайтесь. быстрый рост дают как правило логи. Просто регулярно чистите их.

В старых версиях аксапты реальный рост базы происходил в таблице InventSettlement при списании по среднему. Это да. Но допиленная очистка складских сопоставлений вполне помогала. В последних версиях эту фичу победили.

[maximka]

Цитата:

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

Резюме:
Если вы смотрите на брутто-рост вашей базы в enterprise manager, то не пугайтесь. быстрый рост дают как правило логи. Просто регулярно чистите их.

Да нет, конечно, это далеко не самое главное.
А вообще вопрос актуальный у клиентов? Или все кластеры закупили с запасом на лет 10?

[fed]

Цитата:

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

Да нет, конечно, это далеко не самое главное.
А вообще вопрос актуальный у клиентов? Или все кластеры закупили с запасом на лет 10?

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

P.S. Замечу что аксапта изначально не разрабатывалась и не проектировалась под архивацию и свертку. И разработка подобного механизма с ноля может оказаться дороже перевнедрения с вводом одних остатков...

[mazzy]

Цитата:

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

При перевнедрении, обычно переносяться только остатки, без исторических данных.

Если же используется ОЛАП, то зачастую настраивается два источника данных - старая система для старых данных и новая для новых. Хотя готов согласится, что это тот еще гемор...

[maximka]

Цитата:

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

Если же используется ОЛАП, то зачастую настраивается два источника данных - старая система для старых данных и новая для новых. Хотя готов согласится, что это тот еще гемор...

Мы так и делаем)) И это еще хорошо, что у нас одна валюта

[Vadik]

Цитата:

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

Да нет, конечно, это далеко не самое главное.
А вообще вопрос актуальный у клиентов?

У Вас интерес чисто академический (обо всем и ни о чем конкретно) или практический ? Задачу \ проблему можете сформулировать ?

[maximka]

Цитата:

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

У Вас интерес чисто академический (обо всем и ни о чем конкретно) или практический ? Задачу \ проблему можете сформулировать ?

4 года жили на железе, которое не справлялось с объемом данных за полгода, поэтому каждый год почти под нуль чистили базу. Недавно купили хорошее железо, работает удовлетворительно, но кто его знает, как оно себя поведет через с большими данными...

[Владимир Максимов]

Цитата:

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

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

В чем выражалось это самое "не справлялось"? И о каких объемах данных (в гигабайтах) идет речь? Т.е. какой размер базы данных за полгода?

Цитата:

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

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

Опять же, зависит от того, что Вы вкладываете в понятие "не справлялось". Может, Вам всего-лишь тюнинг индексов надо было провести...

[Cheslav]

Параметры серверов в студию! :-))