|
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
|
||||
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) Большое спасибо! Интересная статья!
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |