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

[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

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

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

[Vadik]

Цитата:

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

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

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

[maximka]

Цитата:

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

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

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

[maximka]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[maximka]

Цитата:

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

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

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

Цитата:

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

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

[egorych]

Цитата:

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

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

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

[Cheslav]

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

[maximka]

Цитата:

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

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

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

[egorych]

Цитата:

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

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

Ошибочка - не профайлер нужен, а счетчики производительности! Не путайте горячее с мягким!
Почитайте тут - http://www.sql.ru/articles/mssql/031...COUNTERs.shtml

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

[maximka]

Цитата:

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

Ошибочка - не профайлер нужен, а счетчики производительности! Не путайте горячее с мягким!
Почитайте тут - http://www.sql.ru/articles/mssql/031...COUNTERs.shtml

Не внимательно писал: счетчики тоже смотрели, на основе данных по счетчикам решили, что дело не в дисках)

[maximka]

Цитата:

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

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

Да, в основном, конечно, все что завязано на InventTrans

Цитата:

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

Ну вот как раз эта тулза и юзает лог от SQL Profiler'а. Но либо мы не умеем ее готовить, либо она не подходит для нашего случая, потому что ни с ее помощью, ни с помощью анализа логов вручную (после некоторой обработки и группировки) узких мест в коде и архитектуре не нашли: выявили ТОП длительных запросов типа: select ... from inventtrans where... или insert into inventrans ..., но толку от этого было мало, так как процент времени выполнения данных запросов от общего числа был мал.

[Alexius]

Цитата:

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

выявили ТОП длительных запросов типа: select ... from inventtrans where... или insert into inventrans ..., но толку от этого было мало, так как процент времени выполнения данных запросов от общего числа был мал.

То есть даже не пытались ничего с ними сделать ?
На мой взгляд в профайлере в первую очередь стоит смотреть не на Duration, а на Reads, если в топовых запросах с помощью индексов удастся уменьшить этот показатель, то с большой вероятностью полегчает и остальным.
Если индексы не помогают, значит нужно "править в консерватории", т.е. искать код АХ и оптимизировать.

PS. Война с производительностью вечна