Имя: Пароль:
1C
1C 7.7
v7: Обрезание регистров. Удаление документов: что быстрей ?
0 buhkiller
 
03.04.12
18:21
1. С начала до точки обрезания 50% (1)
2. С точки обрезания назад 50% (1)
Всего мнений: 2

За четыре года надо почистить дбф - базу. Остатки готовы, теперь думаю как быстрей удалить проведенные документы.
1 viktor_vv
 
03.04.12
18:28
Сколько их там примерно ?
2 viktor_vv
 
03.04.12
18:29
Откатить ТА назад, до первого документа.
3 МихаилМ
 
03.04.12
18:29
если пересчета итогов не будет

то всеравно.

иначе 2

С точки обрезания назад
4 buhkiller
 
03.04.12
18:30
(1) 80 тысяч
5 Ёпрст
 
03.04.12
18:48
быстрее прямым запросом
6 Злой Бобр
 
03.04.12
19:54
(0) Откатываем ТА в самое начало. Дальше в транзакциях удаляем порциями по 100+ документов, в зависимости от железа. Дальше восстанавливаем ТА со всеми вытекающими.
7 Злопчинский
 
03.04.12
20:10
Если остатки готовы - ВВЕСТИ ДОКУМЕНТЫ ОСТАТКОВ.
потом тупо прибить файлы документов и регитсров.
ТИИ с правильными действиями по неразрешенным ссылкам.
провести документы ввода остатков.
8 Ёпрст
 
04.04.12
08:45
(7) какой ты наивный, шо  п..ц.

Во первых, большинство режет базу за какие-то определенные периоды, это раз
при этом нужна аналитика в прошлых периодах, это два.
9 Злой Бобр
 
04.04.12
09:35
(7) Замечательно. Человечек режет на 1 января наверное, а ты предлагаешь тупо убить все и вся. Тогда уж сразу предлагай сапасаться вазелином. Ну а что б вазелин зря непропал, перед тем как убить все - неделать бекапов.
10 Он
 
04.04.12
10:00
Гы. Присоединяюсь к (0)
Мне надо > 800 000 удалить

(5)
1. Прямым запросом update ISMARK = 1 в Журнал
2. Delete движения в регистрах
3. Delete в DT, DH

Что упустил?
11 dk
 
04.04.12
10:12
(10) в журнале значится ismark, а в dt и dh delete? )
12 Boroda
 
04.04.12
10:14
(10) Кроме остатков, надо бы еще посмотреть, нет ли документов формирующих периодические значения, и если есть, то м.б. надо будет создавать документ аналогичный остаткам.
13 Он
 
04.04.12
10:16
(11) А он там есть? )
14 Он
 
04.04.12
10:16
(12) Замётанно
15 viktor_vv
 
04.04.12
10:18
(12) Ну периодику можно не документом. Из Wrap.ert можно взять кусок переноса периодики на дату.
16 Ёпрст
 
04.04.12
10:19
(10) делете в  в DT, DH не надо, раз ты просто помечаешь документ на удаление..
+ должен занулить все флаги по регистрам + аппкоде + счетчик движений..

+ прибить периодику, установленную этим документом
+ прибить проводки


(11) нет
17 viktor_vv
 
04.04.12
10:23
Ну табличные части таки можно и прибить, особенно у тех документов, где они могут быть здоровые.
Если потом стандартным удалением помеченных воспользоваться, пошустрее будет.
18 expertus
 
04.04.12
10:28
Сначала ввод остатков, потом (6). Более скоростного варианта не бывает.

С начала до точки обрезания
19 Он
 
04.04.12
10:29
(16) Что - записи в DT, DH останутся? Или ТИИ их чикнет?
APPCODE = 0  
ACTCNT = 0
RF* = 0 ?
20 Он
 
04.04.12
10:31
(18) ?
21 Ёпрст
 
04.04.12
10:32
(19) останутся
22 Ёпрст
 
04.04.12
10:32
(18) какая детская наивность
23 Ёпрст
 
04.04.12
10:35
(19) + флаг последовательности еще в 0
24 Он
 
04.04.12
10:36
(21) Дык чикнуть надо. Нафига они?

Ещё видимо 1SBLOB прошерстить надо.
25 Ёпрст
 
04.04.12
10:43
(24) смысл тогда в пустышках какой?
порежь тогда хотя бв табличную часть тока
26 Он
 
04.04.12
10:47
(25) Что штатно делает 1С с DT, DH:
1. При пометке на удаления дока
2. При удалении помеченных
?
27 Ёпрст
 
04.04.12
10:49
(26)
1.ничего
2.удаляет
28 Азат
 
04.04.12
10:50
(27) разве в ДБФ удаляет?
29 Он
 
04.04.12
10:53
(27) Вопрос с DT, DH снят. Ступил малешко.
30 viktor_vv
 
04.04.12
11:00
(28) Ну физически нет. Ставит признак в служебное поле. Удаляет физически при сжатии таблиц.
31 Magistr001
 
04.04.12
11:01
все равно часть документов останется: потому что были выписки по расчетному счету на основании доков, удаленных в прошлом периоде, а если урежешь прямым запросом, то в выписках повиснут "дыры"
32 Magistr001
 
04.04.12
11:02
например: режем на 31-12-2011 док отгрузка товаров был 25-12-2011 а выписка по нему 20-01-2012 и на что будет ссылаться выписка?
33 Magistr001
 
04.04.12
11:05
кстати, у меня еще есть связанные между собой доки например Акт на слив ГСМ и Приходная в пути - приходные в пути сидят в декабре, а акты приняли в феврале, и те и те сделали движения и по регистрам и по счетам - делаю на последнем дне дока приходные в пути сторнирующие доки ввода остатков по счету и по регистру. ну и оставляю все доки протоколов цен аж с сентября чтоб периодику не трогать, а в последнюю резку ваще выкинул модуль  удаления периодики - меньше мороки.
34 Ёпрст
 
04.04.12
11:06
(32) читай внимательнее - документы метятся на удаление, не удаляются
35 Magistr001
 
04.04.12
11:06
Я к чему: прямые запросы это конечно быстро - только потом гимора больше.
36 Он
 
04.04.12
11:06
(32) На док, помеченный на удаление.

Ещё вопрос к гуру Скуля:
2005-й
База сначала упала в Suspect.
После перезагрузки оказалась In Recovery.

Что делать, кроме как убить её и восстановить с бекапа?
37 Magistr001
 
04.04.12
11:06
проще действительно транзакциями по сотке доков.
38 Он
 
04.04.12
11:09
(37) Сколько времени штатно будет удалятся под лям доков:?
39 Ёпрст
 
04.04.12
11:11
40 viktor_vv
 
04.04.12
11:12
(37) Да не, на его объеме застрелится ждать. Лучше как и планирует. Пометить доки прямыми запросами плюс по максимуму удалить некритические данные, а потом штатное удаление помеченных. Правда тут тоже вопрос сколько будет идти.
41 Magistr001
 
04.04.12
11:14
бери железо пошустрее и ...вперед. Я каждый год режу с 2006, так что нет таких проблем - вся резка занимает с отладкой и выверкой максимум выходной.
42 Mikeware
 
04.04.12
11:19
(41) Мозг включать не пробовал?
43 Mikeware
 
04.04.12
11:27
(36) подождать, пока восстановится.
44 Он
 
04.04.12
11:49
(43) Я на копии ждать не стал.
Вопрос был на будущую соломку. Вдруг на рабочей будет тоже. Сисы не в курсах.
45 Он
 
04.04.12
12:16
И так:
1. Прямым запросом update ISMARK = 1 APPCODE, ACTCNT, DS4302, RF* = 0 в  Журнал
2. Delete движения в регистрах

Что сделать с 1SCONST ?
DOCID = "" ?
46 Ёпрст
 
04.04.12
12:23
(45)
база какая у тебя ? Тис ? Комплексная? Бухня ? Пуб ?

ЗЫ:еще флаг последовательности надо занулять
47 0xFFFFFF
 
04.04.12
12:24
(7) Тогда уж проще создать пустую базу и занести остатки. Только историю откуда взять?
48 Злой Бобр
 
04.04.12
12:25
На самом деле тема обрезания возникает постоянно, с обострениями под конец и начало года. Воспользоваться поиском и найти 99% ответов на еще непоставленные глупые вопросы. Потом определится с религией - резать самому или найти денег и пусть кто-то сделает. Все. Больше ничего придумать нельзя.
49 Он
 
04.04.12
12:26
(46) ТиС обезображенная до неузнаваемости.

F=DS4302    |DocStream flag      |N   |1     |0    
Оно?
50 Ёпрст
 
04.04.12
12:28
для периодики так будетс

|delete
|from _1sconst
|where docid IN(SELECT Жур.iddoc FROM _1sjourn as Жур where Жур.ismark =1)    ";
51 Ёпрст
 
04.04.12
12:29
(49) ага.. тока это, проще об этом не думать - писать запрос из 1с с использованием 1cpp, там есть метапарсер имён
52 Он
 
04.04.12
12:58
ТА на первый док и удаление с конца дало прирост скорости на порядок.
С моими куцыми знаниями прямых на написание потрачу гораздо больше времени.
Поизучаю прямые на других задачах.
53 Ёпрст
 
04.04.12
13:20
(52) зря ты так думаешь
За то время что будет штатно удалять, можно написать всё, тем более, что готовых примеров пруд пруди
54 Mikeware
 
04.04.12
14:06
(45)
1.формируещь ввод остатков.
1.1 попутно формируешь список документов, которые в этих остаках фигурируют
2. формируешь список документов, устанавливающих значения периодики на дату обрезки.
2.1. если есть документы рагьше даты обрезки - добавляешь их в список 1.1
3. проверяешь ссылкидокументов после даты обрезки - если есть ссылки на документыы раньше даты - добавляешь их в список 1.1
4. удаляешь движения всех документов до даты обрезки, и итоги регистров до этой даты.
5. документы раньше датыобрезки - удаляешь, если они не входят в список  1.1. если входят - снимаешь флаг проведенности, но устанавливаешь признак архивности (чтоб не провели).
6. после в процессе - реиндексируешься.

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