Методический вопрос по SQL базе
 

Есть ооочень запущенная контора с УТ 11.1 на SQL2008. Работает 24\7. Перерыв максимум ночь с субботы на воскресение. Данные в базе с 2009 года, соответственно база еле ползает. Предложение забить остатки в чистую базу гневно отвергнуто! ))) Им нужен как минимум 2017 год в текущей базе. Данные удаляются со скоростью месяц за 2 часа. По сути в базе сворачивать только взаиморасчеты, на остальное ....
Собственно вопрос - есть способ относительно быстрой обрезки части базы? Причем после обрезки база скорее всего будет файловой (контора в людях сильно похудела и Скуль по сути не нужен)

сколько доков в 2017?
Как вариант - в чистой базе сгенерить остатки и перенести документы с их движениями.
ЗЫ данные удаляются со скоростью месяц за 2 часа: как думаешь, сколько нужно пересчитать итогов при удалении движений документа за лохматый год? отключи итоги и посмотри на скорость

Это скорость удаления с отключенными итогами.
Перенести документы не особая проблема, но нет зазора на работы. Пока будут переноситься данные набьют другие.

Я смотрел в сторону скриптов на SQL "срезающих" данные из базы. Потом проверка базы на пустые движения, перенос остатков и документов за текущий день. Кто нибудь такое делал?

(2)Если есть знание структур таблиц, то конечно надо "резать" запросами. На 7.7 прямыми запросами практически мгновенно удалял документы и регистры, на 8-ке так пока не умею.
Как другой вариант - создай документы остатков по взаиморасчетам, но не проводи их. И очисть все регистры накопления (кроме взаиморасчетных), а взваиморасчетные только до даты сверткм. А потом уже проведешь документы начальных остатков и будешь удалять неделю или сколько получится ни на что не влияющие документы. Хотя чистить регистры может будет и не быстрее, я не пробовал. Но это просто в качетве идеию

(2) [em]Это скорость удаления с отключенными итогами[/em] - сколько доков в месяце? [em]нет зазора на работы[/em] работает такая схема: создаёшь узел и в момент, когда начинаешь перенос включаешь авторегистрацию на нем, после окончания основного переноса итерациями переносишь зарегистрированные догоняя текущее состояние. Когда отставание будет минимальным (в идеале нулевым) - переключаешь рубильник
А так да - средствами SQL резать на уровне таблиц. ПолучитьСтруктуруХраненияБазыДанных и вперед.
PS кто-то из франчей такие услуги оказывал (ИжТиСи? Софтпойнт?) - попробуй с ними связаться

"данные в базе с 2009 года, соответственно база еле ползает."
Не факт, что это умозаключение верно.
Работа с текущими данными (текущими остатками и тп) при даже простом обслуживании скуля не должна существенно зависеть от "истории" - только от объёма движений в месяц.
Так что скорее всего на самом деле не просто с 2009 года, а куча мусора, пересорта, незакрытых ошибочных остатков. Но при обрезке эту проблему всё равно придётся решать.

[quote=Пудель;45319837]а куча мусора, пересорта, незакрытых ошибочных остатков[/quote] похоже на то. а если еще и последовательность в каком-то давнем году осталась...

[quote=bma1;45320582] Цитата: Сообщение от Пудель а куча мусора, пересорта, незакрытых ошибочных остатков похоже на то. а если еще и последовательность в каком-то давнем году осталась... [/quote]

Мусора там горы. Регистры не закрываются. Остатки в минусах и прочеее. Я же писал - ооочень запущеный вариант. А еще в ней топталось как минимум 4 "специалиста" и такие конструкции висят в фоне - красотища!

0-Minipuh63 >В свертке регистров и обрезкой их в SQL ничего сложного нет: создать ввод остатков, запросом в SQL удалить старые даннные, пересчитать итоги.
Только если регистр не закрывается - толку мало.
Для начала оцените размер таблиц - какие самые большие?