Вместо DELETE FROM используйте DROP TABLE и будет счастье и не будет длинной транзакции и не кончатся блокировки (что бы они не кончились при DELETE сначала залочте таблицу в эксплюзивном режиме - потратится все одна блокировка) .

Сразу при пересоздани таблицы приделайте фрагментирование и подумайте не сделать ли его с запасом на будущее.

Когда будете заново заполнять таблицу, то при наличии HDR/RSS вам НЕ надо следовать полезнейшему совету "создайте индексы после заполнения таблицы" резко повышающему скорость заполнения - логирование создания большого индекса может вызовать длинную транзакцию (зависит конечно от количества и длины полей в индексе).

При HDR/RSS cоздайте таблицу с индексами и заполняйте порциями по (10-100 тысяч).

Без HDR/RSS - создаёте таблицу без логирования, заполняете, cоздаёте индексы и переводите таблицу в логируемые.

И всё это время верьте что 71 миллионов это мало, а много это таблица которая в этом году у нас дорастёт до миллиарда строк :)

gaЯковлев Павел,

Так а если в одной транзакции удалять много данных она не будет длинной? Не получится ли это шило на мыло?)
Миллиард записей это конечно юбилей))

"много данных" не бывает. бывает их больше чем логи позволяют.

всё зависит от

- размера одной строки
- сколько строк вы удалите/добавите за раз
- количества у вас логических журналов
- размера одно логического журнала
- настроек блокировки/отката длинной транзакции
- ну и для поолноты - от настройки автодобавки журналов

длинная транзакция это, если по простому, попытка отъесть почти все логи

при достижении порога блокировки все прочие транзакции встают в наивной надежде что если не мешать длинной, то авось она таки успеет завершиться

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

если я не ошибаюсь в понимании (в явном виде ни где не читал), откат несколько менее потребляет логи. по этому порог отката не тупо 50% а выше

если места для отката не хватило - каюк - читайте в это форуме кто как нарвался (в основно поставив один из порогов почти в 100) и чем спася

короче - всё (при нормальных настройках) завист от того сколько данных захотите вставить/удалить/изменить за раз

мы обычно делаем массовые изменения порциями по 1-10-100 тысяч - завист от настроения и фазы луны (журналов к нас 512 по 20 метров + настройка автодобавки и под неё есть место)

возможно у вас очень мало журналов и очень огромные строки, но хоть 1000 ту за раз наверно можете себе позволить

и опять-таки - не мучте систему если удаляете всё - удалите таблицу через DROP TABLE - она логируется как одно действие и занимает в журнала всего байт 100 и так же моментально выпоняется по HDR/RSS

gaКак вообще фрагментируют таблицы большие, когда в них данных много? Что бы не получить long transaction. Выгружают предварительно данные?

командой ALTER FRAGMENT :)

это намёк что всё зависит от того для чего у вас таблица и какие по ней выборки

скажем, лог кликов - изумительно фраментируется по дате клика. один год - один фрагмент.

и плюшки в виде способности оптимизатора при выборке дата >= "2012-01-01 00:00:00" сразу пропускать фраменты в которых дата ранее этого времени.

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

в конце года (скажем декабрь) добавляем дбспейсы/место под данные для нового года, добавляем фрагмент (очень рекомендую FORCE_DDL_EXEC=1) и радуемся.

если такого откровенно удобного столбца нет, то хоть по SERIAL фрагментируйте - поможет от окончания максимального количества страниц в таблице (буквально сегодня нарвались, ибо в системе упреждающего предупреждения бага была и она не оповестила что "конец близок")

и не забывайте фрагметировать индексы так же и в туда же

gaКак вообще фрагментируют таблицы большие, когда в них данных много? Что бы не получить long transaction. Выгружают предварительно данные?

что-то не про то сначала написал (как создать и поддерживать), а не как быть когда припёрло

варианты вам уже описали

- да, тупо выгрузить, дропнуть, залить в новую таблицу с уж правильной фрагментацией

- не хотите выгружать - RAW-mode и вперёд

- не хотите выгружать - добавить до фига места под логи и ALTER FRAGMENT

- не хотите выгружать - добавить до фига место под новую таблицу с правильной фрагментацией и переливать в ней. потом дропнуть старую

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

не в таблице, а в фрагменте, будем всё же точнее описывать ситуацию.

(может конечно в каких-то очень старых версиях нет фрагментов...)