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

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

Что непонятно - откуда из "нескольких десятков записей" набирается аж 30Гб.
Если это хвост несобранного мусорных версий при постоянных апдейтах - то просто писец какой-то, так нельзя.

Нужно промониторить разрыв OAT-OIT на предмет некорректной работы с транзакциями, тут уже говорили про это.

Еще было упоминание топикстартера про периодическое удаление неактуальных записей.
Непонятен объем удаления и частота этого действия. Удаление большого кол-ва записей создает кучу мусора которую придется убирать. Лучше удалять мелкими порциями и сразу после порции в следующей транзакции делать селект на только что удаленное - что бы явно вызвать сборку мусора. Таким образом мы не накапливаем большой вал а грызем его потихоньку, и это не вызовет длительных тормозов. Выполняя удаление устаревших записей не раз в месяц а несколько раз в день мы уменшим раздувание и сдувание базы.

Уменьшение размера БД путем backup/restore - это не та операция которой нужно поддерживать размер БД в приемлемом размере.

Ivan_PisarevskyЕсли вы 30 гиг за час не успеваете, что-то с железом у вас тухляк.
...
Короче, купи нормальный сервак и "буде тебе щастье".

Давайте решать проблемы некорректного софта наращиванием железа.
Если ему вдруг начнет хватать железа что бы перебэкапить 30 гигов за час - это же не нормальный повод продолжать в этом духе, в то время как там может собственно данных на 30мб а остальное ненужный мусор. избавившись от которого задача вообще станет выглядеть по другому.

rdb_devfraksНа сколько я понял это база в которую весьма часто пишется текущие показания каких-то датчиков, апдейты записей - это перезапись на новое текущее значение.

Что непонятно - откуда из "нескольких десятков записей" набирается аж 30Гб.
Если это хвост несобранного мусорных версий при постоянных апдейтах - то просто писец какой-то, так нельзя.


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

сколько таблиц истории

столько там записей

какие таблицы дают такой объем

сколько хранится по времени

сколько НАДО хранить по времени (а не сколько получается технологически)

в каких таблицах скапливаются версии

почему они там скапливаются

Ivan_PisarevskyfraksДавайте решать проблемы некорректного софта наращиванием железа.Давайте не будем вырывать фразы из контекста. Б/р базы в 30 гиг вполне реально уложить в полчаса, причем на лоу левел железе (двухпроцовая супермикра, 10 рэйд на 4 ССД). Собственно про это и есть фраза. Как уложить цикл обслуживания БД в технологическое окно в 1 час? купить железку.


Тут речь не про то как администрировать черный ящик с определенными параметрами, и тогда да, кроме наращивания железа делать нечего.
Вопрос стоит в том что для нормальной работы софта может не требоваться укладываться бэкап-рестор в полчаса, может он вообще не нужен в процессе эксплуатации, может там эти 30 Гиг не данных а всякого мусора и эффективнее подмести и прогуливаться раз в день с пылесосом чем утаптывать мусор ногами и потом заводить вездеходы что бы по этому мусору можно было хоть как-то перемещаться.

Мне надо бежать, поэтому сразу скажу на какую мысль я пытался навести.
Удалять таблицы целиком - это не есть хорошо, используется только потому что так быстрее.
Но это влечет за собой всякие административные действия.

Если есть определенность сколько данных надо хранить в истории то можно сделать например так:
новые значения пишутся в таблицу, триггер на ней перекидывает прыдыдущие данные в историю + удаляет ровно столько записей сколько вставил, на расcтоянии ID-DELTA. Таким образом в таблице истории хранится постоянное кличество записей, база не растет и ее не надо чистить, она подчищается постоянно сама.

Если не получается изменить пишушюю прогу - можно сделать отдельный удалятор, запускаемый по крону допустим раз в час или чаще. Он например смотрит на генератор PK на таблице истории и удаляет из нее записи с где ID < (GEN_ID(ID, 0)-DELTA).
Коммитит. И делает селект по этому же условию. Получает NULL но зато мусор собран.

Ну и в этой же программе-удаляторе можно помониторить OAT-OIT.