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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 04.08.2011, 14:40   #1  
maximka is offline
maximka
Сам.AX
Аватар для maximka
Самостоятельные клиенты AX
 
96 / 24 (1) +++
Регистрация: 26.10.2006
Адрес: Тюмень
? Поддержание быстродействия растущей БД
AX 4.0, MSSQL 2008
В условиях постоянно растущей базы возникает вопрос: как сделать так, чтобы общая скорость работы системы и отдельных операций не увеличивалась?
Каждый год удалять "лишние" документы (различные заказы, проводки..)?
Средствами MSSQL дробить данные БД горизонтально на файлы и старые (с реже используемыми данными) файлы кидать на отдельный диск?
Каждый год покупать новый сервак?

Что делаете вы?
__________________
ѣ
Старый 04.08.2011, 15:21   #2  
Cheslav is offline
Cheslav
Участник
 
90 / 15 (1) ++
Регистрация: 04.08.2003
Цитата:
Сообщение от maximka Посмотреть сообщение
В условиях постоянно растущей базы
Что делаете вы?
Это сколько в гигабайтах?
Старый 04.08.2011, 15:57   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,123 / 4006 (192) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от maximka Посмотреть сообщение
AX 4.0, MSSQL 2008
Каждый год удалять "лишние" документы (различные заказы, проводки..)?
Во-первых, чистить логи http://axapta.mazzy.ru/lib/dbgrowthsolution/

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

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

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

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

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

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

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

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

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

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

В старых версиях аксапты реальный рост базы происходил в таблице InventSettlement при списании по среднему. Это да. Но допиленная очистка складских сопоставлений вполне помогала. В последних версиях эту фичу победили.
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
За это сообщение автора поблагодарили: Electrician (1).
Старый 08.08.2011, 16:17   #4  
maximka is offline
maximka
Сам.AX
Аватар для maximka
Самостоятельные клиенты AX
 
96 / 24 (1) +++
Регистрация: 26.10.2006
Адрес: Тюмень
Цитата:
Сообщение от mazzy Посмотреть сообщение
Резюме:
Если вы смотрите на брутто-рост вашей базы в enterprise manager, то не пугайтесь. быстрый рост дают как правило логи. Просто регулярно чистите их.
Да нет, конечно, это далеко не самое главное.
А вообще вопрос актуальный у клиентов? Или все кластеры закупили с запасом на лет 10?
__________________
ѣ
Старый 08.08.2011, 16:22   #5  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,564 / 4942 (170) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от maximka Посмотреть сообщение
Да нет, конечно, это далеко не самое главное.
А вообще вопрос актуальный у клиентов? Или все кластеры закупили с запасом на лет 10?
В среднем, каждые лет 5 требуется перевнедрение системы (просто потому что бизнес меняется быстро и становиться проще заново внедриться, чем копаться в залежах накопившегося кода). При перевнедрении, обычно переносяться только остатки, без исторических данных.
Ну а 5 лет продержаться тупо апгрейдя железо - вполне реально...
На крайняк - можно без перевнедрения с нового года поставить новую БД и перенести туда одни остатки...

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

Последний раз редактировалось fed; 08.08.2011 в 16:29.
Старый 08.08.2011, 17:04   #6  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,123 / 4006 (192) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от fed Посмотреть сообщение
При перевнедрении, обычно переносяться только остатки, без исторических данных.
Если же используется ОЛАП, то зачастую настраивается два источника данных - старая система для старых данных и новая для новых. Хотя готов согласится, что это тот еще гемор...
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
Старый 08.08.2011, 18:15   #7  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,496 / 1656 (62) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от maximka Посмотреть сообщение
Да нет, конечно, это далеко не самое главное.
А вообще вопрос актуальный у клиентов?
У Вас интерес чисто академический (обо всем и ни о чем конкретно) или практический ? Задачу \ проблему можете сформулировать ?
__________________
-ТСЯ или -ТЬСЯ ?
Старый 09.08.2011, 10:25   #8  
maximka is offline
maximka
Сам.AX
Аватар для maximka
Самостоятельные клиенты AX
 
96 / 24 (1) +++
Регистрация: 26.10.2006
Адрес: Тюмень
Цитата:
Сообщение от Vadik Посмотреть сообщение
У Вас интерес чисто академический (обо всем и ни о чем конкретно) или практический ? Задачу \ проблему можете сформулировать ?
4 года жили на железе, которое не справлялось с объемом данных за полгода, поэтому каждый год почти под нуль чистили базу. Недавно купили хорошее железо, работает удовлетворительно, но кто его знает, как оно себя поведет через с большими данными...
__________________
ѣ
Старый 09.08.2011, 13:34   #9  
maximka is offline
maximka
Сам.AX
Аватар для maximka
Самостоятельные клиенты AX
 
96 / 24 (1) +++
Регистрация: 26.10.2006
Адрес: Тюмень
Цитата:
Сообщение от mazzy Посмотреть сообщение
Если же используется ОЛАП, то зачастую настраивается два источника данных - старая система для старых данных и новая для новых. Хотя готов согласится, что это тот еще гемор...
Мы так и делаем)) И это еще хорошо, что у нас одна валюта
__________________
ѣ
Старый 09.08.2011, 16:22   #10  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,501 / 1000 (37) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от maximka Посмотреть сообщение
4 года жили на железе, которое не справлялось с объемом данных за полгода, поэтому каждый год почти под нуль чистили базу.
В чем выражалось это самое "не справлялось"? И о каких объемах данных (в гигабайтах) идет речь? Т.е. какой размер базы данных за полгода?

Цитата:
Сообщение от maximka Посмотреть сообщение
Недавно купили хорошее железо, работает удовлетворительно, но кто его знает, как оно себя поведет через с большими данными...
Опять же, зависит от того, что Вы вкладываете в понятие "не справлялось". Может, Вам всего-лишь тюнинг индексов надо было провести...
Старый 10.08.2011, 07:04   #11  
maximka is offline
maximka
Сам.AX
Аватар для maximka
Самостоятельные клиенты AX
 
96 / 24 (1) +++
Регистрация: 26.10.2006
Адрес: Тюмень
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
В чем выражалось это самое "не справлялось"? И о каких объемах данных (в гигабайтах) идет речь? Т.е. какой размер базы данных за полгода?
Не справлялась СУБД - почти все операции выполнялись крайне медленно, влияя тем самым как на комфорт работы, так и на возможность выполнения конкретных бизнес-процессов в принципе. База в конце года - до 250 Гб, а есть разница?
Цитата:
Опять же, зависит от того, что Вы вкладываете в понятие "не справлялось". Может, Вам всего-лишь тюнинг индексов надо было провести...
Делали, все делали. Профайлер загоняли до полусмерти
__________________
ѣ
Старый 10.08.2011, 14:09   #12  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Цитата:
Сообщение от maximka Посмотреть сообщение
Не справлялась СУБД - почти все операции выполнялись крайне медленно, влияя тем самым как на комфорт работы, так и на возможность выполнения конкретных бизнес-процессов в принципе. База в конце года - до 250 Гб, а есть разница?
ИМХО - все как-то неконкретно! Есть счетчики производительности - они четко (ну в большинстве случаев) показывают где есть затык! Если у Вас дисковые очереди зашкаливают, то тут хоть заиндексируйся - нужно менять систему хранения ну и т.д. - т.е. что хочу сказать - нужно локализовать причину и дальше смотреть как ее решить!
__________________
Axapta 3.0 sp - хз какой, kr2
Старый 10.08.2011, 14:17   #13  
Cheslav is offline
Cheslav
Участник
 
90 / 15 (1) ++
Регистрация: 04.08.2003
Параметры серверов в студию! :-))
Старый 10.08.2011, 14:52   #14  
maximka is offline
maximka
Сам.AX
Аватар для maximka
Самостоятельные клиенты AX
 
96 / 24 (1) +++
Регистрация: 26.10.2006
Адрес: Тюмень
Цитата:
Сообщение от egorych Посмотреть сообщение
ИМХО - все как-то неконкретно! Есть счетчики производительности - они четко (ну в большинстве случаев) показывают где есть затык! Если у Вас дисковые очереди зашкаливают, то тут хоть заиндексируйся - нужно менять систему хранения ну и т.д. - т.е. что хочу сказать - нужно локализовать причину и дальше смотреть как ее решить!
На старом железе после долгого анализа работы профайлера, проблему точно выяснить не удалось, но сошлись на том, что проблема не в дисках. Поэтому решили просто взять сервак с нормальными процессорами и памятью.
Сейчас-то все гут И чувствую, если начнутся тормоза, то опять же выяснить особо ничего не удастся (если только внешнюю организацию не пригласить для анализа), поэтому и задал вопрос так как я его задал...
__________________
ѣ
Старый 10.08.2011, 15:59   #15  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Цитата:
Сообщение от maximka Посмотреть сообщение
На старом железе после долгого анализа работы профайлера, проблему точно выяснить не удалось, но сошлись на том, что проблема не в дисках. Поэтому решили просто взять сервак с нормальными процессорами и памятью.
Ошибочка - не профайлер нужен, а счетчики производительности! Не путайте горячее с мягким!
Почитайте тут - http://www.sql.ru/articles/mssql/031...COUNTERs.shtml
__________________
Axapta 3.0 sp - хз какой, kr2
Старый 10.08.2011, 17:40   #16  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,501 / 1000 (37) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от maximka Посмотреть сообщение
Не справлялась СУБД - почти все операции выполнялись крайне медленно, влияя тем самым как на комфорт работы, так и на возможность выполнения конкретных бизнес-процессов в принципе.
Т.е. "тормозили" основные рабочие процессы, когда от сервера требовалось выбрать одну..две записи?

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

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

Цитата:
Сообщение от maximka Посмотреть сообщение
Делали, все делали. Профайлер загоняли до полусмерти
Для анализа индексов в MS SQL есть специальная утилита: Database Engine Tuning Advisor.

Ее идея в том, что она записывает trace (лог команд, но не всех, а отобранных по спец.критериям) и далее по этому trace анализирует частоту выполнения тех или иных команд и какие индексы могли бы их ускорить. После этого выдает свои рекомендации.
Старый 11.08.2011, 13:47   #17  
maximka is offline
maximka
Сам.AX
Аватар для maximka
Самостоятельные клиенты AX
 
96 / 24 (1) +++
Регистрация: 26.10.2006
Адрес: Тюмень
Цитата:
Сообщение от egorych Посмотреть сообщение
Ошибочка - не профайлер нужен, а счетчики производительности! Не путайте горячее с мягким!
Почитайте тут - http://www.sql.ru/articles/mssql/031...COUNTERs.shtml
Не внимательно писал: счетчики тоже смотрели, на основе данных по счетчикам решили, что дело не в дисках)
__________________
ѣ
Старый 11.08.2011, 14:04   #18  
maximka is offline
maximka
Сам.AX
Аватар для maximka
Самостоятельные клиенты AX
 
96 / 24 (1) +++
Регистрация: 26.10.2006
Адрес: Тюмень
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Т.е. "тормозили" основные рабочие процессы, когда от сервера требовалось выбрать одну..две записи?
Да, в основном, конечно, все что завязано на InventTrans

Цитата:
Для анализа индексов в MS SQL есть специальная утилита: Database Engine Tuning Advisor. Ее идея в том, что она записывает trace (лог команд, но не всех, а отобранных по спец.критериям) и далее по этому trace анализирует частоту выполнения тех или иных команд и какие индексы могли бы их ускорить. После этого выдает свои рекомендации.
Ну вот как раз эта тулза и юзает лог от SQL Profiler'а. Но либо мы не умеем ее готовить, либо она не подходит для нашего случая, потому что ни с ее помощью, ни с помощью анализа логов вручную (после некоторой обработки и группировки) узких мест в коде и архитектуре не нашли: выявили ТОП длительных запросов типа: select ... from inventtrans where... или insert into inventrans ..., но толку от этого было мало, так как процент времени выполнения данных запросов от общего числа был мал.
__________________
ѣ
Старый 12.08.2011, 12:44   #19  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
461 / 243 (9) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от maximka Посмотреть сообщение
выявили ТОП длительных запросов типа: select ... from inventtrans where... или insert into inventrans ..., но толку от этого было мало, так как процент времени выполнения данных запросов от общего числа был мал.
То есть даже не пытались ничего с ними сделать ?
На мой взгляд в профайлере в первую очередь стоит смотреть не на Duration, а на Reads, если в топовых запросах с помощью индексов удастся уменьшить этот показатель, то с большой вероятностью полегчает и остальным.
Если индексы не помогают, значит нужно "править в консерватории", т.е. искать код АХ и оптимизировать.

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

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Установка текущего SID-а в БД sukhanchik DAX: Администрирование 0 16.09.2009 07:58
Получить параметры соединения с БД if_maks DAX: Программирование 5 17.03.2009 16:19
Подключение АОС к новой БД AxaptaUser DAX: Администрирование 4 07.04.2008 16:09
2 AOS + 2 БД = 1 сервер renat DAX: Администрирование 2 22.07.2003 09:20
Создание точной копии БД для анализа ошибок Maxim Gorbunov DAX: База знаний и проекты 1 18.12.2001 15:24
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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