powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Обслуживание больших (>250 Гб) баз
25 сообщений из 98, страница 1 из 4
Обслуживание больших (>250 Гб) баз
    #38607827
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый день
Поделитесь своим опытом обслуживания больших БД. У меня такая ситуация - есть база ПО АСУТ S-Market ( http://s-market.ru/), размер в данный момент 210 Гб, число коннектов 270-300. Т.к. наша торговая сеть расширяется, увеличивается кол-во магазинов и следовательно число работающих в БД и её размер расширяется. Приходится делать бэкап-рестор,но интервал между ними постоянно уменьшается,а время рестора увеличивается. Для того,чтобы жилось спокойно провожу такие работы по БД:
1. Само собой бэкап-рестор раз в 2-3 месяца (чаще не могу - база работает 24/7,реже - база начинает подтормаживать,ну и рестор идет 14 часов)
2. Каждый день sweep (sweep interval давно уже в 0), после него проверка через gtat-h на предмет застрявших транзакций
3. Каждый день после sweep пересчет селективности индексов (запустил совсем недавно,пока не понятно есть польза или нет от него)
4. Обрезка таблиц перед каждым бэкап-рестором (получаем 10-30 Гб уменьшения БД)
5. Запущена трассировка на поиск медленных запросов (недавно,так что пока ничего не "поймала")
6. Firebird.conf переписан под конфигурацию сервера
Теневые копии и репликацию не использую.
Моё беспокойство в чем - база растет,время между b/r уменьшается, время рестора увеличивается (за год с 8 до 14 часов). Настанет скоро момент,когда ресторится придется раз в месяц и по двое суток. Как можно продлить жизнь БД или ускорить рестор?
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38607895
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemarрепликацию не используюКак вариант увеличения доступности сделать фаиловер кластер на репликации. Пока проводишь сервисные работы на основной ноде, работает вторая, закончил обслуживание, вернул репликацию, базы выровнялись и можешь снова переключать юзеров на основную ноду. Если клиентская часть программы в будет уметь переключаться, то юзер вообще ничего не заметит, если нет, ну потратится минутка на переконнект, ни о каком даунтаме в полдня речь уже не идет.

Как вообще можно говорить о работе 24х7 если нет кластера?
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38607904
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan_Pisarevsky,я такую схему хочу с ibreplicator реализовать,разговаривал с разработчиком и Димой Сибиряковым,они одобрили. Я ещё не тестировал репликацию на продуктиве и боюсь просадки производительности.
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38607936
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar> 1. Само собой бэкап-рестор раз в 2-3 месяца (чаще не могу - база работает
Gallemar> 24/7,реже - база начинает подтормаживать,ну и рестор идет 14 часов)

А как вообще периодичность рестора выбирается и осуществляется, если 24х7?
Обычно, 24х7 - это, на самом деле, такая фикция, не мешающая рестору.
Ну и плюс есть nbackup (хоть и не буду его советовать) и репликация.

> 2. Каждый день sweep, после него проверка через gtat-h на предмет застрявших транзакций

А вот расскажи-ка про этот пункт поподробней - вручную делается или автоматизировано?

> 4. Обрезка таблиц перед каждым бэкап-рестором (получаем 10-30 Гб уменьшения БД)

Удаление старых записей что ли?

> 5. Запущена трассировка на поиск медленных запросов
> (недавно,так что пока ничего не "поймала")

Так ты какой фильтр по времени-то поставил? Уменьши.

> база растет,время между b/r уменьшается

А почему оно уменьшается, кстати?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38607945
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустам,
При 24/7 выбираем сутки,договариваемся что товароучет не будет работать,после согласований получаю возможность проводить работы.
Репликация и nbackup не ускорят БД,а b/r провожу именно с этой целью. Nbackup кстати у меня меня есть как альтернатива gbak.
После свипа запускается gstat -h >C:\S-Market\LOG\db_stat_%date%_%VTime%.txt, ну и смотришь данные по счетчикам. Я смотрю сам,а другие через 1с, там есть обработка для этого.
Обрезку данных осуществляю обрезкой старых данных.
Трассировку запустил вчера,так что статистики просто не набрал.
Почему уменьшается время рестора - так база на месте не стоит и "подрастает"
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38607978
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar> Репликация и nbackup не ускорят БД,а b/r провожу именно с этой целью

Странная цель. Тем более, если ничего в этой части
(мусор, счётчики) особо не тормозит, о чём тебе уже говорили.

> ну и смотришь данные по счетчикам. Я смотрю сам,

В смысле глазами или парсишь?

> а другие через 1с, там есть обработка для этого.

В смысле, 1С конкретно к FB привязывается или свю внутреннюю
слежубную инфу сообщает? Я просто не в курсе, аж интересно стало.

> Обрезку данных осуществляю обрезкой старых данных.

Дык я и спрашиваю - в чём она заключается? Это архивные данные,
которые в оперативном бэкапе не нужны (ибо есть в архивах) ?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608000
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустам,
База начинает торможить к концу второго месяца после рестора.
Данные по gstat -h смотрю глазами, руки не доходят автоматизировать,т.к. проблема с счетчиками вылезает раз в 2 года.
1с целяется по odbc и тянет запрос из mon$database, потом высчитывается разницу,если больше n - делает оповещение.
Данные обрезаются по документам и продажам,т.к. они есть в OLAP и держать в оперативной базе их не надо.
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608037
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar> База начинает торможить к концу второго месяца после рестора.

Это глазами видно и измеряемо? При ежедневном свипе-то?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608040
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
roadster

Модератор: Не надо устраивать тут филиал ПТ, пришел в наш раздел, говори по делу.
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608049
NikolayV81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar База начинает торможить к концу второго месяца после рестора.

Маловероятно конечно, но такое впечатление что по симптомам смахивает на чрезмерную фрагментацию fs.
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608052
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
тормоза через два месяца могли быть вызваны как раз отсутствием пересчета статистики. Сейчас, когда это добавлено, имеет смысл посмотреть возникнет ли снова проблема или нет. Ибо свип + пересчет статистики это вполне достаточная замена рестора с т.з. производительности.
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608055
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitr> тормоза через два месяца могли быть вызваны как раз отсутствием пересчета статистики.

Насколько я понимаю, стабильная периодическая проблема с индексами
может быть при высокой нагрузке и индексах по датам. Да и то - шибко
постараться надо, наверное.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608064
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar1. Само собой бэкап-рестор раз в 2-3 месяцаЭто ни разу не само-собой. Это путь в никуда, и ты это уже начинаешь ощущать.
Мониторь запросы, когда "база начинает подтормаживать" и делай выводы.
Возможно тебе достаточно пару индексов перестроить, а не всю БД пересоздавать.
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608098
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамGallemar> База начинает торможить к концу второго месяца после рестора.

Это глазами видно и измеряемо? При ежедневном свипе-то?

Измерить не получает,но при работе с ПО ощутимо (медленные выборки,медленные отчеты,медленная запись документов).
Если свип убрать база начнет тормозить уже через пару-тройку недель.
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608108
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrтормоза через два месяца могли быть вызваны как раз отсутствием пересчета статистики. Сейчас, когда это добавлено, имеет смысл посмотреть возникнет ли снова проблема или нет. Ибо свип + пересчет статистики это вполне достаточная замена рестора с т.з. производительности.
Ок,буду смотреть что станет с БД через пару месяцев. Вообще,в начале работы свип отсутствовал вообще (sweep interval выставили в нуль,а запуск вручную зачем то закомментировали), и база начинала тормозить через три недели,после включения свипа вручную - работала три месяца.
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608123
NikolayV81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GallemarГаджимурадов РустамGallemar> База начинает торможить к концу второго месяца после рестора.

Это глазами видно и измеряемо? При ежедневном свипе-то?

Измерить не получает,но при работе с ПО ощутимо (медленные выборки,медленные отчеты,медленная запись документов).
Если свип убрать база начнет тормозить уже через пару-тройку недель.

как вариант, на вскидку, b/r создаёт файл в котором таьблицы/индексы и прочие данные расположены упорядочено, если есть запросы идущие natural-ом, то из-за особенностей ввода вывода даже на маленьких табличках, может идти постепенное уменьшение производительности ( после b/r всё работает шустро, но fullscan по размазанной по файлу/диску таблице, в которой пограничная длина строки сильно замедляется ).
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608130
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NikolayV81> по размазанной по файлу/диску таблице,
NikolayV81> в которой пограничная длина строки сильно замедляется

Это ппц сколько бреда в одном посте про SSD можно написать...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608131
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NikolayV81из-за особенностей ввода выводаУ автора вроде на ssd все.
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608153
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan_Pisarevsky,верно,SSD OCZ Vertex 3 Max Iops, 8 штук, RAID10
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608168
NikolayV81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамNikolayV81> по размазанной по файлу/диску таблице,
NikolayV81> в которой пограничная длина строки сильно замедляется

Это ппц сколько бреда в одном посте про SSD можно написать...


Не увидел в теме, беру свои слова обратно...
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608251
heckfi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Gallemar, могу порекомендовать следующее

1.поддерживайте статистику БД в актуальном состоянии, особенно по тем таблицам, по которым большой % изменений I/U/D от общего объема таблицы;

2. также следует следить за выполняющимися SQL, отыскивать медленные, проводить их анализ и оптимизацию. Возможно, существующие индексы становятся неэффективными или опять же, виновата статистика;

3. задумайтесь о репликации данных на slave-server, в перспективе нужно иметь отказоустойчивый кластер.
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608256
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
heckfi,
по поводу пункта 3 - собираюсь делать репликацию через Ibreplicator, планы вынашивал давно, но пока воздерживался от установки на продуктив. Вызывает опасение возможность сильной просадки по производительности.
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608276
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar,

ibtm ставил? статистика по транзакциям собирается?
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608277
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
heckfi, могу порекомендовать следующее

1. почитать предыдущие ответы, а не только первый пост.
2. присоединиться к советам, опровергнуть их или дописать свои, но не выступать в качестве К.О.
...
Рейтинг: 0 / 0
Обслуживание больших (>250 Гб) баз
    #38608278
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GallemarИзмерить не получает,но при работе с ПО ощутимо (медленные
выборки,медленные отчеты,медленная запись документов).
А использовать в этот момент gstat и IBAnalyst, конечно же, ни у кого руки не дошли...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25 сообщений из 98, страница 1 из 4
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Обслуживание больших (>250 Гб) баз
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]