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

[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]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

[maximka]

Цитата:

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

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

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

Цитата:

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

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