Имя: Пароль:
1C
1C 7.7
v7: Ошибки вып транзакций в sql-версии
0 never_sleep
 
11.09.15
11:58
Перевел одну базу под SQL2005. Перевел из-за больших размеров под угрозой отказа регистров. Думал, в качестве доп. ништяков отпадут ошибки транзакций (в основном из-за обращений 1journ). Но чуда не произошло. Подскажите нубу в этом вопросе. Это особенность работы 7ки? Получается, даже в SQL-версии С-ка блокирует таблицу целиком? Или у меня производная по рукам не константа?
1 Ёпрст
 
11.09.15
12:11
Большой размер, это сколько ?
2 ДенисЧ
 
11.09.15
12:12
У производителей 77 - "производная по рукам не константа"
Да. В любой версии 77 при проведении документа блокируется весь журнал.
3 ДенисЧ
 
11.09.15
12:13
(1) Если под угрозой - то до 2г на файл, сам понимаешь
4 Ёпрст
 
11.09.15
12:22
(3) врят ли.
5 Ёпрст
 
11.09.15
12:22
многие не понимают, что такое "большая база в дбф"
6 never_sleep
 
11.09.15
12:23
(1) Перед миграцией общий объем был гигов под 7, а один из регистров под 1,9. Теперь поболее. Ща занимаюсь сверткой базы на начало 15го. Но дело тяжело продвигается. В частности, из-за того, что большинство обработок заставляют 1Совский процесс распухать до 4+гигов и последующей ошибкой.
7 Ёпрст
 
11.09.15
12:27
(6) и имя таблички в 1.9 гигов, начинается поди с rg ? да ? И остальные все, много меньше ?
8 Ёпрст
 
11.09.15
12:28
можешь дать скрин файликов с размерами в порядке убывания ?
9 never_sleep
 
11.09.15
12:29
(8) Сек, поищу базу до миграции
10 never_sleep
 
11.09.15
12:46
11 ДенисЧ
 
11.09.15
12:47
ууууу.... RG....
Регистры не закрываются... Либо сильно задним число привыкли работать, а полные пересчёты не делают...
12 never_sleep
 
11.09.15
12:51
(11) Денис, а чем помог бы полный персчет? Разве он уменьшает размер данных? Я думал - просто проверка корректности данных.
13 Ёпрст
 
11.09.15
12:52
Гы.. я так и знал.
База не о чем (скуль для неё не нужен), просто 4 незакрытых регистра, один из которых уже просто не в красную армию.
14 Ёпрст
 
11.09.15
12:53
(12) в данном случае, ничем не поможет, от слова совсем.
15 Ёпрст
 
11.09.15
12:55
Для начала, смотреть , что представляют из себя регистры
9119,
4335,
4343,
8901

Анализировать, делать их "нормально закрывающимися" и жить дальше в дбф, при желании, в скуле.
А так, в скуле те же грабли, только тормозов прибавится
16 never_sleep
 
11.09.15
13:11
(15) Сейчас хочу проверить вот что.
Топорный метод. Я сделал копию базы. Убрал в ней все движения. И переношу остатки по регистрам на 31,12,14. Есть документик "ОстаткиПоРегистру" он записывает в себя все остатки на дату и при переносе в новую пустую базу его нужно просто провести. Но он те регистры, которые вы указали, таким документом не формируются. Пухнет 1Совский процесс. Хочу проверить, что будет, если в базе источнике SQL-запросом удалить в этих регистрах (в RG и RA таблицах) данные ранее 01,01,15? Регистр по размеру сразу станет на 2/3 меньше (там 13,14,15 года). Потом попробую воспользоваться этим "ОстаткомПоРегистру". Нужно по идее еще удалить индексный файл. Он после удаления записей, как я полагаю, будет неверный. Интересно база не навернется после таких манипуляция?
17 never_sleep
 
11.09.15
13:13
Вот статья по которой раньше сворачивал базы. Нов это раз прощелкал точку невозврата(((
18 never_sleep
 
11.09.15
13:13
19 trdm
 
11.09.15
13:14
(0) Снижай время проведения документа.
Прописывайся в отладчик на пару дней и кури прямые запросы.
20 Ёпрст
 
11.09.15
13:16
>>>Убрал в ней все движения.
Что именно вы сделали ?
21 trdm
 
11.09.15
13:17
(10) Можно подрезать крылышки RG. Просто поужать числовые поля разумно. Было как экстренная мера. Нафина НДС с размерностью в 19.2? Это типа хранить 9'999'999'999'999'999.99 рублей?
22 Ёпрст
 
11.09.15
13:18
Че значит, "прощелкал точку невозврата" ?
Копий нету что ле ?
23 Ёпрст
 
11.09.15
13:18
(21) сам понимаешь, что это полумера.
Иметь 4 незакрывающиеся регистра, даже в скуле чревато
24 trdm
 
11.09.15
13:20
(23) Да нам время надо было выиграть.
Ясен пень черевато. У него что период по пол дня закрывается?
25 trdm
 
11.09.15
13:20
Открывается в смысле.
26 Ёпрст
 
11.09.15
13:24
(24) думаю, что да..а в дбф , так вообще не откроется - файло в 2 гига уже. И, если не стояло заплатки от hogik, в итогах уже мусор и таким останкам веры нет
27 never_sleep
 
11.09.15
13:24
(20) Аналог батника очищающего документы, регистры и т.д в SQL-базе
вот тут структура батника, которым удалял движения в ДБФ версии (потом тии) . Подобные манипуляции проделал в SQL-версии. Проверял - вроде норм. Батник из статьи из первой ссылки в текущей теме.
28 never_sleep
 
11.09.15
13:26
(22) Очень далеко бывает залезаем в задние числа. Поэтому не могу доверять старым копиям.
29 Ёпрст
 
11.09.15
13:27
(27) ????
че правда ?
30 Ёпрст
 
11.09.15
13:27
прям запускал тот, что в (0) посте ?
31 Ёпрст
 
11.09.15
13:27
врешь же.
32 never_sleep
 
11.09.15
13:28
(31) Запутался. в нулевой пост из ссылки?
33 Ёпрст
 
11.09.15
13:29
Если ты дропнул все таблички, то никаких итогов у тебя уже нет, если запустил батник из (0) поста в той базе, то у тебя ничего нет, только справочники.
Так что же ты сделал и в какой последовательности ?
34 never_sleep
 
11.09.15
13:30
Здесь описана методика, которой пользовался ранее (18). Но в этот раз регистры запустил и она не работает.
35 Ёпрст
 
11.09.15
13:31
Имена регистров из (15) посмотри в dd (dds), результаты в студию
36 Ёпрст
 
11.09.15
13:31
(34) что такое "регистры запустил" ?
37 never_sleep
 
11.09.15
13:32
Там делаешь копию базы. Батником удаляешь все движения. Делаешь ТиИ. Потом переносишь итоги с помощью документа "ОстаткиПоРегистру" проводишь их. Получаешь регистры на дату свертки. Потом так же ОЛЕшкой переносишь доки и восстанавливаешь ГП.
38 Ёпрст
 
11.09.15
13:33
Какие доки ?
39 Ёпрст
 
11.09.15
13:33
если ты переносишь только останки на дату.
40 never_sleep
 
11.09.15
13:33
(36) Довел их до состояния когда при заполнении волшебного документа "ОстаткиПоРегистру" процесс распухает в 4+гигов.
41 never_sleep
 
11.09.15
13:33
(38) Да все которые есть после даты свертки
42 Ёпрст
 
11.09.15
13:35
Короче. Верни всё взад, и ответь на (35) .
43 never_sleep
 
11.09.15
13:35
смотри перенес документы "остаткипоРегистру" на 31,12,14. Столько штук сколько остаточных непустых регистров в базе.
Провел из там. получил заполненные регистры на эту дату. Потом перенес все доки за 15 год. И с 01,01,15 их все проводишь.
44 never_sleep
 
11.09.15
13:35
(42) сек
45 Ёпрст
 
11.09.15
13:39
и..переносить надо документы с движениями сразу, а не заниматься их перепроведением.
И.. проще в свёртку делать простым удалением ненужного, а не заниматься переносами.
46 never_sleep
 
11.09.15
13:40
9119 КонтрольОтпуска (Самописный, не мной)
4335 Покупатели
4343 КнигаПродаж
8901 ДляПроводок
47 never_sleep
 
11.09.15
13:42
(45) Да я один в поле воин. Без опытных коллег, у кого спросить можно, как лучше сделать. Поэтому: нашел способ, проверил, работает, пользуюсь. Не ругайте сильно.
48 Ёпрст
 
11.09.15
13:45
(46)
КонтрольОтпуска , какие измерения ? Кто им пользуется, он вообще нужен ?

Покупатели  - тут всё ясно, не закрывается по КредДокументы
КнигаПродаж  - тут тоже всё ясно, просто не ведёте книжки покупок/продаж, надо просто вырезать его проведение и прибить

ДляПроводок - это что за зверь ? Аналогичные вопросы, как и к КонтрольОтпуска .

Устранишь эти проблемы, можешь и дальше "тусить" на дбф.
А сейчас, у тебя банально итоги, даже в скуле не откроются,
49 Ёпрст
 
11.09.15
13:45
не перенесутся на след период.
50 never_sleep
 
11.09.15
13:55
(48) КонтрольОтпуска. Кривой и очень нужный. Используется для контроля выполнения контрактов. У нас особые условия по контролю. Короче тут попа. Для него пара справочников даже специально написана. Штука нужная. Штука кривая. Объяснять что к чему в нем - еще на полдня. И врятли нужно. К тому же писался под одни условия, используется под под другие через зад.
ДляПроводок хз. Надо смотреть.
51 never_sleep
 
11.09.15
14:00
Вот почему нельзя просто взять и удалить все движения ранее определенной даты во всех таблицах?
Что будет если я тупо в этих регистрах удалю движения до 01,01,15?
52 ДенисЧ
 
11.09.15
14:08
Кранты базе (((
53 akaBrr
 
11.09.15
14:23
Начальник ИТ отдела, мде
54 ДенисЧ
 
11.09.15
14:24
(51) Что будет....
Будет дефицит вазелина в окружающих аптеках...
55 never_sleep
 
11.09.15
14:30
(52) А ща и проверим. На копии разумеется. И на одном 9119 регистре.
56 Ёпрст
 
11.09.15
14:49
(50)КонтрольОтпуска -  переписывай однозначно весь алгоритм проведения.

На регистр Покупателей можно забить, если в свёртке забить на креддоки - повесить все взаиморасчеты на ввод останков (наверняка у вас никто не смотрит взаиморасчеты в разрезе кредитных документов, раз он не закрывается как надо)

Книги покупок/продаж - просто вырезать из конфы.
на счет ДляПроводок  - хз для чего он у вас и кто его пользует
57 Злопчинский
 
11.09.15
17:53
Работы на один день неспешно с перекурами.
Взять нормальный "Универсальный двигатель регистров" - который "не пухнет" при самозаполнении (например у меня, за деньги, епть!). Заполнить. Не прводить. Как Епрст сказал - в кривом "Покупатели" - закрыть креддок на самого себя.

"Контроль отпуска" - СЛУШАЙ ЕПРСТА! - это вариант скорее всего контроля отгрузок по контрактам. План отгрузок или фиксирование отгрузок выполняется. А закрытие плана или "подтверждение" факта (тоже зтипа закрытие) - не делается.

И это - Контроль отпуска - оборотный или остаточный регистр?
58 rsv
 
11.09.15
20:41
(0) 7 ка  работает последовательно. От кройте хранимому записи и увидете принудительный хины tablock
59 never_sleep
 
14.09.15
10:55
(57) КонтрольОтпуска - остаточный регистр.
Сколько стоит ваша обработка? Может одолею) Тока не загибайте, у меня 2 ипотеки) Денег только на пожрать и остается.
Из проблемных регистров, для функционирования порезанной базы необходим только он. Покупатели, КнигаПродаж и ДляПроводок, думаю, можно не переносить. Долг контрагентов мы все равно не учитываем. В карточках в ТиС висят миллионные долги - никто на них не смотрит. Взаиморасчеты ведутся в бухгалтерии. Посмотрел, мы уже пожимали базу года 2,5 назад. Тогда перенесли только ОстаткиТМЦ, ПартииНаличие и КонтрольОтпуска. Этих регистров хватило для нормального функционирования базы.
Модифицировать регистры я не буду. Мартышкин труд. В течение полугода максимум перейдем на 8ку, за это время они не успеют снова распухнуть.
КонтрольОтпуска был придумал для обеспечения нужд исполнения мун. контрактов. Там заранее неизвестно что и как будут возить (товар обезличен и только в кг). Поэтому делали отдельный справочник а-ля номенклатуры (назвали ТоварТиС). Забивали в свой самописный документ объем по определенному мун.контракту, где позиции из ТоварТиСа. К ТоварТиС при поступлении и реализации привязывали конкретную позицию из справочника "номенклатура". Делали это руками. Привязка эта в документе нигде не хранится. Привязка каждый раз менялась при проведении других документов. Не ахайте. Не я писал. Да и тот человек, который писал, писал это буквально за пару суток в режиме кофе + энергентики. Зла не неё не держу. Но отсюда еще одна проблема: Даже, если я перенесу остатки по этому регистру. Восстановить по нему движения за 15 год я не смогу простым перепроведением. Надо будет запилить обработку, которая записывает в файл движения по регистру и еще одну которая корректно меняет неверные движения в порезанной базе. Хотя это просто проблема времени. Я это одолею. А вот как перенести этот гребаный регистр, кроме как купить у г-на Злопчинского волшебную обработку, я хз (((
60 never_sleep
 
14.09.15
11:06
Кто-то говорил, что порежу движения в таблице RG и база встанет. Нет не встала. Даже не попросила индексацию. Оставил в ней только движения за нужный период. Но и их оказалось более 800 000 записей. И когда формирую документ, все равно "ОстаткиПоРегистру" вылетают за 4 гига. Хотя я не трогал RA. Может она оттуда автоматически рассчитывает? Нашел копию базы на начало года размер поменьше 4,5 гига. Но тоже вылетает. Я, так понимаю, 1С повиснет, если в результате запроса будет такое количество строк, которое у нас формируется за месяц. Т.е. нужна обработка, которая месяц проходит не за один проход. А делит на несколько и формирует несколько документов.
61 never_sleep
 
14.09.15
11:45
(58) А где конкретно глянуть где лежат эти хинты? Я нуб, но посмотреть интересно.
62 ДенисЧ
 
14.09.15
11:59
(61) *.dds
63 never_sleep
 
15.09.15
07:37
(62) Спасибо, увидел
64 never_sleep
 
15.09.15
07:38
Ну так есть у кого двигатель регистров который итоги по регистру делит на несколько документов? Злопчинский что-то пропал. Наверное, решает, сколько с меня нищеброда попросить)))
65 never_sleep
 
15.09.15
07:48
Еще вопрос можно в теме?
В RG таблице за период все записи уникальны по совокупным значением всех измерений? Т.е., могут ли быть в таблице 2 и более записи, у которых одинаковые значения всех измерений, а разница только в ресурсах? Я подозреваю, что нет. Так как в этом и логика таблицы остатков.
66 Ёпрст
 
15.09.15
07:50
(65) уникальна совокупность период+все измерения.
67 Ёпрст
 
15.09.15
07:52
>>>что порежу движения в таблице RG и база встанет.

Зачет чо..
Если че, в RG - не движения , а промежуточные итоги
68 never_sleep
 
15.09.15
08:00
(66) Спасибо.
(67) Да я в курсе, что там. Но я полагал, что если не трону именно тот период, на который буду формировать итоги, Ска не будет трогать движения из RA, а сразу обратится к ним в RG. И думал, что возможно 1С пыталась весь этот файл сразу загрузить и если порежу его, то пухнуть не будет. Да глупо. 1С наверняка сразу открывает нужные записи. Но хотел просто проверить.
69 never_sleep
 
15.09.15
08:03
Теперь думаю, что сам запрос на дату, который включает более 800 000 записей вылетает. Т.е. надо дробить запрос. Да и представить документ, форма которого имеет такое количество строк тяжело. Думаю Ска банально не сможет его "прорисовать".
70 Ёпрст
 
15.09.15
08:13
Всё она сможет. У вас при незакрытом регистре, в RG многократные дубли в каждом периоде. Вы тащите одинаковые записи из периода в период.
71 Ёпрст
 
15.09.15
08:14
Просто сверните этот регистр, избавившись от лишней аналитики.
Размер RG должен быть у вас не 2 гига, а пару метров всего.
72 Ёпрст
 
15.09.15
08:15
Для этого, нужно посмотреть, что за измерения там, и какие движения делают туда документы - с каким набором измерений идёт приход в этот регистр и с каким расход.
73 never_sleep
 
15.09.15
08:33
(70) В RG многократные дубли в каждом периоде.
Каким образом это происходит? Если итоги по не меняются, то логично, что они будут перетекать из периода в период. У нас некоторые контракты заключаются полгода назад, а движения по ним могут начаться только сейчас. Соответственно движения сделанные полгода назад будут повторяться в каждом периоде.
74 never_sleep
 
15.09.15
08:43
(71) Боюсь аналитика там вся нужная. Никаких лишних измерений нет. Все используются. Можно попробовать, как выше советовали, урезать их разрядность. Я попробую, кстати. Но существенно это не скажется на размере, мне кажется.
Фактически этот регистр помнит, сколько какого конкретного товара, по какому конкретному договору, за какой срок по какой цене мы должны вернуть нашему контрагенту. У одного контрагента может быть несколько договоров с разными сроками, в каждом из которых несколько позиций. Все это нужно помнить. Тут при всем желании в пару мегабайт не уложишься.
75 Ёпрст
 
15.09.15
08:49
Зачем тогда регистр для этого ?
Храните в документе/справочнике.
76 Ёпрст
 
15.09.15
08:50
Ну и это, перечисли измерения регистра
77 never_sleep
 
15.09.15
08:52
78 never_sleep
 
15.09.15
08:53
Не мой регистр, еще раз напомню))
79 never_sleep
 
15.09.15
08:58
Но я посчитал. Наверное вы правы. Что-то совершенно ненужное тянется. Ибо даже если взять 500 контрагентов * по 10 договоров на каждого и по 10 позиций получается всего 50 000. по идее такой длины должен быть период в RG. 800 000 записей - это слишком.
80 never_sleep
 
15.09.15
09:01
Хотя.. вот еще На один договор может быть по несколько заявок. Одна заявка на одни товары с одним сроком поставки. Другая на другие товары с другими сроками и т.д.
81 Ёпрст
 
15.09.15
09:03
Что такое НачПериода и конПериода там ?
Что такое коддокумента ?

Сам клиентос в регистре не нужен, достаточно иметь договор
82 never_sleep
 
15.09.15
09:06
(81) Период действия заявки. Нельзя данный товар по этому договору отпускать ни раньше этого срока ни позже.
(81) Ссылка на документ, который вызвал движение. (Залез глянул вот: Регистр.КонтрольОтпуска.КодДокумента = ТекущийДокумент();
83 never_sleep
 
15.09.15
09:07
(75) а как в документах или справочниках хранить такие объемы информации? И тем более оперативно получить по ним данные на нужные даты?
84 Ёпрст
 
15.09.15
09:09
(82) это же п...ц
85 Ёпрст
 
15.09.15
09:09
Зачем это измерение, если и так есть всегда документ движения регистра ?
86 Ёпрст
 
15.09.15
09:10
У тебя только из-за одного этого измерения, регистр НИКОГДА не закроется ВООБЩЕ.
87 Ёпрст
 
15.09.15
09:12
(83) какие там "объемы" ?
88 never_sleep
 
15.09.15
09:17
(85) Я подозревал что из-за это измерения получу люлей))
Предыдущая программистка по-ходу не знала, что можно получить документ движения без создания этого поля. Надо искать в коде, где она к нему обращается и менять. Потом удалять это измерение из регистра.
89 Ёпрст
 
15.09.15
09:20
Каким документом пишется приход в этот регистр, и каким расход ?

Что пишется в поле КодДокумента при приходе в регистр и что при Расходе ?
90 Ёпрст
 
15.09.15
09:21
дай мд посмотреть
91 never_sleep
 
15.09.15
09:23
92 never_sleep
 
15.09.15
09:29
Чет сделал глобальный поиск "КонтрольОтпуска". Оказалось, что он больше используется, чем я думал.
93 never_sleep
 
15.09.15
09:41
(89) Везде в поле КодДокумента пишется просто текущий документ вызвавший движение.
Приход пишется документами ЗаявкаПокуп и ВозвратОтПокупателя. Расход только реализацией.
94 Ёпрст
 
15.09.15
10:02
1. Выкинуть нах КодПокупателя из измерения, тому кто это измерение ввёл - дать в репу.
ЗЫ: там всего то пару строк заремить в модулях.

2. Выкинуть нах НачПериод и КонПериод из измерений регистра,
наказание, аналогично п.1

ЗЫ: Приход в регистр делается по реквизитам шапки дока, а расход ВСЕГДА: в НачПериод - начало месяца от даты дока, КонПериода - конец месяца даты дока, который толкает регистр.
Отсюда - ад и израиль, тому кто это придумал - гвоздь в голову.

Либо удалить нах эти измерения, которые нигде не используются, либо исправлять движения расхода.
95 Ёпрст
 
15.09.15
10:02
В общем, налицо, полная безграмотность в проектировании регистра, ОН вам вообще зачем ? По нему есть хоть один отчет (внешний) ?
96 Ёпрст
 
15.09.15
10:09
Короче, смело удаляйте эти 3 измерения из регистра и пересчитывайте итоги (только по этому регистру).
Это для начала.
Аналогичные действия с регистром КонтрольОтпускаПоЗаявкам
97 akaBrr
 
15.09.15
10:16
(94) К Ёпрсту пойти что-ли работать? Накосячишь, максимум в репу даст. Ни четвертования, ни распятия на кресте, ни лишения премии.
98 never_sleep
 
15.09.15
10:32
(94) 2. Так тут НачПериод и КонПериод не период регистра, а период действия заявки, которая толкнула приход в регистр. Когда реализация проводится она смотрит на эти даты и сравнивает со своей текущей и если попадает, то дает добро на проведение.
(95) Так один из основных самых используемых отчетов на нем завязан. Смотрят сколько по какому договору заказали, сколько поступило и сколько реализовали. Нас нещадно сношают за неисполнение или переисполнение мун. контрактов. Там же, знаете, все до копейки должно сходиться. Да и первую очередь этот регистр ввели для контроля. Чтобы нельзя было принять и отпустить сверх нормы.
99 Ёпрст
 
15.09.15
10:33
(98) реализация не смотрит на эти даты, вообще
100 Ёпрст
 
15.09.15
10:37
Эти измерения нигде у вас не используются
101 never_sleep
 
15.09.15
11:37
(100) Мда... Попробую на копии сделать.
"Пересчитывайте итоги (только по этому регистру). "
Подскажите, как сделать? Сделать пустую базу такой же структуры и скопировать туда RA таблицу. Запустить ТиИ?
102 Ёпрст
 
15.09.15
11:50
(101) не совсем.
База на дбф или скуле ?
Если скуль, то просто пересчет обработкой,
для дбф, копиряешь все RA и RG в отдельный каталог вместе с индексами
прибиваешь все RA и RG, оставляешь только RA от нужного регистра, заходишь монопольно, ставишь ТА в журнале на первый документ, потом на последний.Далее копируешь RG И RA обратно (окромя RA и RG пересчитываемого регистра) усё.
103 Ёпрст
 
15.09.15
11:52
Для прибития измерений, прибиваешь перед этим RG этого регистра, можешь и руками прибить поля в табличке RA + подменить мд и словарик, чтоб не ждать реструктуризации. Это будет в разы быстрее на любой базе.
104 never_sleep
 
15.09.15
12:04
(102) Про sql не совсем понял как (мой случай). И про ДБФ спасибо большое. Записал себе в Евернот.
105 Ёпрст
 
15.09.15
12:36
(104) там просто скриптом очистить поля, далее на выбор, либо alter table удалить колонки, либо просто реструктуризацией + truncate RG перед этим, потом обработкой пересчитать итоги.
106 Ёпрст
 
15.09.15
12:41
107 Ёпрст
 
15.09.15
12:41
на вот, пересчитаешь этим
108 never_sleep
 
15.09.15
13:49
(107) огромное спасибо!!! Буду пробовать. Отпишусь.
109 never_sleep
 
15.09.15
17:43
Думал разберусь сам. Но немного не догоняю. Спрошу чтобы дальше не тупить.
(102) А подобный способ пересчета не сработает в Скуль-базе? Если да, то почему?
(103) Здесь вы описываете не пересчет регистров, а даете совет по ускорению реструктуризации при удалении измерений? RG регистр нужно удалять, чтобы 1Ска не мучилась с удалением столбцов в нем при применении новой конфигурации?
(105) "там просто скриптом очистить поля" - вот здесь не догнал. где именно?
"либо просто реструктуризацией + truncate RG" здесь наверное как в примере с ДБФ сначала truncate RG, а потом реструктуризация?
110 Ёпрст
 
15.09.15
18:09
(109)
1. нет, в скуле всё проще, через qa
2.да
3. достаточно просто сделать truncate table RG***, далее реструктуризация базы (просто лишние измерения поудалять и заремит в модулях), далее любой обработкой пересч1ёт регистра.
111 never_sleep
 
15.09.15
18:43
(110) Все понял кроме термина "qa".
112 Ёпрст
 
15.09.15
18:54
квери анализер
113 never_sleep
 
15.09.15
18:55
(112) понял.
114 never_sleep
 
28.09.15
11:26
(112) Уважаемый Ёпрст. Базу на 31,12,2014, можно сказать, свернул. Сделал на копии и попросил проверить всех, кто работает с базой - все ровно. Должен был в эти выхи успеть все провернуть на актуальном экземпляре, но не успел из-за длительности процесса.
Перенес из итогов по регистрам в пожатую базу только ОтстакиТМЦ и ПартииНаличие. Восстановил там ГП перепроведением всех перенесенных за 15 год документов. Неверно сформированные движения по кривому "КонтрольОтпуска" поправил Скуль-скриптом на основании данных из изначальной базы. Очистил таблицу итогов по нему и воспользовался вашей обработкой. За неё огромное вам спасибо! Все встало. Теперь жду на этой неделе поставку ССД дисков. Установлю их в сервант и на следующих выхах попробую прогнать процесс на них. Надеюсь, что отработает быстрее, и я успею за выходные все пожать и конвертнуть обратно в ДБФ.
По поводу оптимизации регистра.
Посмотрел я на измерения: НачПериод, КонПериод и КодДокумента. Как вы и сказали, они не используется в самой базе. Но они используются в нескольких отчетах. Их я поправлю в ближайшее время. Спасибо вам за ваш опытный взгляд.
Ну и собственно зачем пишу. Выше мне было предложено настучать в бубен человеку, который этот регистр сотворил. Чтобы не стать таким человеком и ввиду отсутствия опытных коллег в этой сфере, подскажите статью, мануал, гайд etc. где написано как правильно! проектировать регистры. И если можно еще хорошую статью о том, как правильно/канонично их сворачивать. Ну или общих словах самое основное.
115 ProxyInspector
 
28.09.15
11:37
Давай я тебе базу сверну за 3 часа. С учетом доработки конфигурации. Хочешь в DBF, а хочешь в SQL варианте. В SQL варианте будет раз в 10 быстрее
116 never_sleep
 
28.09.15
14:39
(115) Лучше покажи как :)
117 never_sleep
 
28.09.15
14:49
(116) Тут есть возможность сделать все гораздо быстрее. Можно было бы не восстанавливать ГП в пожатой базе, а скуль-скриптом, аналогично тому как я перенес движения для "КонтрольОтпуска" перенести движения для всех регистров. И установить ГП и ТА принудительно на нужную дату. Но я не стал заморачиваться - думал, что успею все за выхи обычным восстановлением сделать.
118 never_sleep
 
28.09.15
14:56
(115) 3 часа это для sql? ДБФ тогда 30 часов? или sql свернешь за 18 минут?))
119 gallam
 
28.09.15
15:02
(0)
http://www.softpoint.ru/article_id1.htm
Внедрение "Гибких блокировок" поможет.
120 ProxyInspector
 
28.09.15
15:22
База 16 GB сворачивается где то за час. Минут 10 формирование  документов переноса остатков. Часа 1.5 удаление документов без ссылок. На SQL удаление документов без ссылок идет существенно быстрее за счет использования прямых запросов.
  Чтобы научить потребуется существенно больше 3 часов. Алгоритмы стандартные см пост Злопчинский
  Универсальный документ по движению регистров, универсальный документ по сохранению периодических реквизитов, прямые запросы по удалению движений документов, обвязка
121 never_sleep
 
28.09.15
16:10
(120) "Чтобы научить потребуется существенно больше 3 часов. Алгоритмы стандартные см пост Злопчинский"
Ну хотя бы поэтапно напишите, как вы это делаете. Или может где в интернете есть статья?
А то я придумываю велосипед с квадратными колесами(
122 never_sleep
 
28.09.15
16:16
(119) Большое спасибо! Интересная статья!
Здесь можно обсудить любую тему при этом оставаясь на форуме для 1Сников, который нужен для работы. Ymryn