Добрый день
Поделитесь своим опытом обслуживания больших БД. У меня такая ситуация - есть база ПО АСУТ 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 часов). Настанет скоро момент,когда ресторится придется раз в месяц и по двое суток. Как можно продлить жизнь БД или ускорить рестор?

Ivan_Pisarevsky,я такую схему хочу с ibreplicator реализовать,разговаривал с разработчиком и Димой Сибиряковым,они одобрили. Я ещё не тестировал репликацию на продуктиве и боюсь просадки производительности.

Гаджимурадов Рустам,
При 24/7 выбираем сутки,договариваемся что товароучет не будет работать,после согласований получаю возможность проводить работы.
Репликация и nbackup не ускорят БД,а b/r провожу именно с этой целью. Nbackup кстати у меня меня есть как альтернатива gbak.
После свипа запускается gstat -h >C:\S-Market\LOG\db_stat_%date%_%VTime%.txt, ну и смотришь данные по счетчикам. Я смотрю сам,а другие через 1с, там есть обработка для этого.
Обрезку данных осуществляю обрезкой старых данных.
Трассировку запустил вчера,так что статистики просто не набрал.
Почему уменьшается время рестора - так база на месте не стоит и "подрастает"

Гаджимурадов Рустам,
База начинает торможить к концу второго месяца после рестора.
Данные по gstat -h смотрю глазами, руки не доходят автоматизировать,т.к. проблема с счетчиками вылезает раз в 2 года.
1с целяется по odbc и тянет запрос из mon$database, потом высчитывается разницу,если больше n - делает оповещение.
Данные обрезаются по документам и продажам,т.к. они есть в OLAP и держать в оперативной базе их не надо.

Гаджимурадов РустамGallemar> База начинает торможить к концу второго месяца после рестора.

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

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

dimitrтормоза через два месяца могли быть вызваны как раз отсутствием пересчета статистики. Сейчас, когда это добавлено, имеет смысл посмотреть возникнет ли снова проблема или нет. Ибо свип + пересчет статистики это вполне достаточная замена рестора с т.з. производительности.
Ок,буду смотреть что станет с БД через пару месяцев. Вообще,в начале работы свип отсутствовал вообще (sweep interval выставили в нуль,а запуск вручную зачем то закомментировали), и база начинала тормозить через три недели,после включения свипа вручную - работала три месяца.

Ivan_Pisarevsky,верно,SSD OCZ Vertex 3 Max Iops, 8 штук, RAID10

heckfi,
по поводу пункта 3 - собираюсь делать репликацию через Ibreplicator, планы вынашивал давно, но пока воздерживался от установки на продуктив. Вызывает опасение возможность сильной просадки по производительности.

Dimitry SibiryakovGallemarИзмерить не получает,но при работе с ПО ощутимо (медленные
выборки,медленные отчеты,медленная запись документов).
А использовать в этот момент gstat и IBAnalyst, конечно же, ни у кого руки не дошли...

Хм,а так я что увижу? Картина по плохим индексам и большим таблицам одна

kdvGallemar,

ibtm ставил? статистика по транзакциям собирается?
Нет

WildSeryGallemar,

Ну вот видишь, сколько ещё всего можно посмотреть и замерить :)
С ibtm была такая проблема - при коннекте более 200 пользователей вылетал с ошибкой,может сейчас этой проблемы не будет,надо пробовать.

kdv,Дима,я могу ошибаться,ставил давно. Может аналогичная твоя программа,я помню что она работала как сниффер,пропускала через себя данные,приходилось менятьеё порт на порт ФБ.

kdv,я транзакции при необходимости смотрю через mon$, завтра гляну ibtm.

kdv,да нет,я на самом деле хороший:) Исправляюсь понемногу.

Таблоид,попался!!!!!:) Почту проверь!!!

Обнаружился старый косяк при обновлении - часть таблиц GTT оказались обычными, при переходе с interbase на firebird часть скриптов не выполнились.

hvlad,да я про потерю производительности. Это возможно одна из причин.

wadmanНе выполнилась та часть скриптов, которая из обычных таблиц делала GTT? Или как это связано с GTT?


Именно