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

[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

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

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

[maximka]

Цитата:

Сообщение от Владимир Максимов

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

Не справлялась СУБД - почти все операции выполнялись крайне медленно, влияя тем самым как на комфорт работы, так и на возможность выполнения конкретных бизнес-процессов в принципе. База в конце года - до 250 Гб, а есть разница?

Цитата:

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

Делали, все делали. Профайлер загоняли до полусмерти

[egorych]

Цитата:

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

Не справлялась СУБД - почти все операции выполнялись крайне медленно, влияя тем самым как на комфорт работы, так и на возможность выполнения конкретных бизнес-процессов в принципе. База в конце года - до 250 Гб, а есть разница?

ИМХО - все как-то неконкретно! Есть счетчики производительности - они четко (ну в большинстве случаев) показывают где есть затык! Если у Вас дисковые очереди зашкаливают, то тут хоть заиндексируйся - нужно менять систему хранения ну и т.д. - т.е. что хочу сказать - нужно локализовать причину и дальше смотреть как ее решить!

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

Цитата:

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

Не справлялась СУБД - почти все операции выполнялись крайне медленно, влияя тем самым как на комфорт работы, так и на возможность выполнения конкретных бизнес-процессов в принципе.

Т.е. "тормозили" основные рабочие процессы, когда от сервера требовалось выбрать одну..две записи?

Цитата:

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

База в конце года - до 250 Гб, а есть разница?

Ну, не то, чтобы определяющая... Просто по размеру базы можно прикинуть размер самых больших таблиц. Если речь идет об оперативной работе, то, вероятно, где-то под 20..30ГБ.

При таких размерах критически важным становится размер кеша MS SQL сервера, который напрямую зависит от объема оперативной памяти. Если оперативки недостаточно, то это может стать причиной тормозов. Впрочем, тут лучше счетчики посмотреть.

Цитата:

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

Делали, все делали. Профайлер загоняли до полусмерти

Для анализа индексов в MS SQL есть специальная утилита: Database Engine Tuning Advisor.

Ее идея в том, что она записывает trace (лог команд, но не всех, а отобранных по спец.критериям) и далее по этому trace анализирует частоту выполнения тех или иных команд и какие индексы могли бы их ускорить. После этого выдает свои рекомендации.