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

[Vadik]

Цитата:

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

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

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

[maximka]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[maximka]

Цитата:

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

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

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

Цитата:

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

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

[egorych]

Цитата:

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

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

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

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

Цитата:

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

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

Да, в основном, конечно, все что завязано на 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. Война с производительностью вечна