Перевел одну базу под SQL2005. Перевел из-за больших размеров под угрозой отказа регистров. Думал, в качестве доп. ништяков отпадут ошибки транзакций (в основном из-за обращений 1journ). Но чуда не произошло. Подскажите нубу в этом вопросе. Это особенность работы 7ки? Получается, даже в SQL-версии С-ка блокирует таблицу целиком? Или у меня производная по рукам не константа?

Большой размер, это сколько ?

У производителей 77 - "производная по рукам не константа"
Да. В любой версии 77 при проведении документа блокируется весь журнал.

(1) Если под угрозой - то до 2г на файл, сам понимаешь

(3) врят ли.

многие не понимают, что такое "большая база в дбф"

(1) Перед миграцией общий объем был гигов под 7, а один из регистров под 1,9. Теперь поболее. Ща занимаюсь сверткой базы на начало 15го. Но дело тяжело продвигается. В частности, из-за того, что большинство обработок заставляют 1Совский процесс распухать до 4+гигов и последующей ошибкой.

(6) и имя таблички в 1.9 гигов, начинается поди с rg ? да ? И остальные все, много меньше ?

можешь дать скрин файликов с размерами в порядке убывания ?

(8) Сек, поищу базу до миграции

https://www.dropbox.com/s/9w33dagc8almu2f/Скриншот%202015-09-11%2014.42.45.png?dl=0

ууууу.... RG....
Регистры не закрываются... Либо сильно задним число привыкли работать, а полные пересчёты не делают...

(11) Денис, а чем помог бы полный персчет? Разве он уменьшает размер данных? Я думал - просто проверка корректности данных.

Гы.. я так и знал.
База не о чем (скуль для неё не нужен), просто 4 незакрытых регистра, один из которых уже просто не в красную армию.

(12) в данном случае, ничем не поможет, от слова совсем.

Для начала, смотреть , что представляют из себя регистры
9119,
4335,
4343,
8901

Анализировать, делать их "нормально закрывающимися" и жить дальше в дбф, при желании, в скуле.
А так, в скуле те же грабли, только тормозов прибавится

(15) Сейчас хочу проверить вот что.
Топорный метод. Я сделал копию базы. Убрал в ней все движения. И переношу остатки по регистрам на 31,12,14. Есть документик "ОстаткиПоРегистру" он записывает в себя все остатки на дату и при переносе в новую пустую базу его нужно просто провести. Но он те регистры, которые вы указали, таким документом не формируются. Пухнет 1Совский процесс. Хочу проверить, что будет, если в базе источнике SQL-запросом удалить в этих регистрах (в RG и RA таблицах) данные ранее 01,01,15? Регистр по размеру сразу станет на 2/3 меньше (там 13,14,15 года). Потом попробую воспользоваться этим "ОстаткомПоРегистру". Нужно по идее еще удалить индексный файл. Он после удаления записей, как я полагаю, будет неверный. Интересно база не навернется после таких манипуляция?

Вот статья по которой раньше сворачивал базы. Нов это раз прощелкал точку невозврата(((

http://alexeev.pro/?page_id=1282

(0) Снижай время проведения документа.
Прописывайся в отладчик на пару дней и кури прямые запросы.

>>>Убрал в ней все движения.
Что именно вы сделали ?

(10) Можно подрезать крылышки RG. Просто поужать числовые поля разумно. Было как экстренная мера. Нафина НДС с размерностью в 19.2? Это типа хранить 9'999'999'999'999'999.99 рублей?

Че значит, "прощелкал точку невозврата" ?
Копий нету что ле ?

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

(23) Да нам время надо было выиграть.
Ясен пень черевато. У него что период по пол дня закрывается?

Открывается в смысле.

(24) думаю, что да..а в дбф , так вообще не откроется - файло в 2 гига уже. И, если не стояло заплатки от hogik, в итогах уже мусор и таким останкам веры нет

(20) Аналог батника очищающего документы, регистры и т.д в SQL-базе
вот тут структура батника, которым удалял движения в ДБФ версии (потом тии) . Подобные манипуляции проделал в SQL-версии. Проверял - вроде норм. Батник из статьи из первой ссылки в текущей теме.

(22) Очень далеко бывает залезаем в задние числа. Поэтому не могу доверять старым копиям.

(27) ????
че правда ?

прям запускал тот, что в (0) посте ?

врешь же.

(31) Запутался. в нулевой пост из ссылки?

Если ты дропнул все таблички, то никаких итогов у тебя уже нет, если запустил батник из (0) поста в той базе, то у тебя ничего нет, только справочники.
Так что же ты сделал и в какой последовательности ?

Здесь описана методика, которой пользовался ранее (18). Но в этот раз регистры запустил и она не работает.

Имена регистров из (15) посмотри в dd (dds), результаты в студию

(34) что такое "регистры запустил" ?

Там делаешь копию базы. Батником удаляешь все движения. Делаешь ТиИ. Потом переносишь итоги с помощью документа "ОстаткиПоРегистру" проводишь их. Получаешь регистры на дату свертки. Потом так же ОЛЕшкой переносишь доки и восстанавливаешь ГП.

Какие доки ?

если ты переносишь только останки на дату.

(36) Довел их до состояния когда при заполнении волшебного документа "ОстаткиПоРегистру" процесс распухает в 4+гигов.

(38) Да все которые есть после даты свертки

Короче. Верни всё взад, и ответь на (35) .

смотри перенес документы "остаткипоРегистру" на 31,12,14. Столько штук сколько остаточных непустых регистров в базе.
Провел из там. получил заполненные регистры на эту дату. Потом перенес все доки за 15 год. И с 01,01,15 их все проводишь.

(42) сек

и..переносить надо документы с движениями сразу, а не заниматься их перепроведением.
И.. проще в свёртку делать простым удалением ненужного, а не заниматься переносами.

9119 КонтрольОтпуска (Самописный, не мной)
4335 Покупатели
4343 КнигаПродаж
8901 ДляПроводок

(45) Да я один в поле воин. Без опытных коллег, у кого спросить можно, как лучше сделать. Поэтому: нашел способ, проверил, работает, пользуюсь. Не ругайте сильно.

(46)
КонтрольОтпуска , какие измерения ? Кто им пользуется, он вообще нужен ?

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

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

Устранишь эти проблемы, можешь и дальше "тусить" на дбф.
А сейчас, у тебя банально итоги, даже в скуле не откроются,

не перенесутся на след период.

(48) КонтрольОтпуска. Кривой и очень нужный. Используется для контроля выполнения контрактов. У нас особые условия по контролю. Короче тут попа. Для него пара справочников даже специально написана. Штука нужная. Штука кривая. Объяснять что к чему в нем - еще на полдня. И врятли нужно. К тому же писался под одни условия, используется под под другие через зад.
ДляПроводок хз. Надо смотреть.

Вот почему нельзя просто взять и удалить все движения ранее определенной даты во всех таблицах?
Что будет если я тупо в этих регистрах удалю движения до 01,01,15?

Кранты базе (((

Начальник ИТ отдела, мде

(51) Что будет....
Будет дефицит вазелина в окружающих аптеках...

(52) А ща и проверим. На копии разумеется. И на одном 9119 регистре.

(50)КонтрольОтпуска -  переписывай однозначно весь алгоритм проведения.

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

Книги покупок/продаж - просто вырезать из конфы.
на счет ДляПроводок  - хз для чего он у вас и кто его пользует

Работы на один день неспешно с перекурами.
Взять нормальный "Универсальный двигатель регистров" - который "не пухнет" при самозаполнении (например у меня, за деньги, епть!). Заполнить. Не прводить. Как Епрст сказал - в кривом "Покупатели" - закрыть креддок на самого себя.

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

И это - Контроль отпуска - оборотный или остаточный регистр?

(0) 7 ка  работает последовательно. От кройте хранимому записи и увидете принудительный хины tablock

(57) КонтрольОтпуска - остаточный регистр.
Сколько стоит ваша обработка? Может одолею) Тока не загибайте, у меня 2 ипотеки) Денег только на пожрать и остается.
Из проблемных регистров, для функционирования порезанной базы необходим только он. Покупатели, КнигаПродаж и ДляПроводок, думаю, можно не переносить. Долг контрагентов мы все равно не учитываем. В карточках в ТиС висят миллионные долги - никто на них не смотрит. Взаиморасчеты ведутся в бухгалтерии. Посмотрел, мы уже пожимали базу года 2,5 назад. Тогда перенесли только ОстаткиТМЦ, ПартииНаличие и КонтрольОтпуска. Этих регистров хватило для нормального функционирования базы.
Модифицировать регистры я не буду. Мартышкин труд. В течение полугода максимум перейдем на 8ку, за это время они не успеют снова распухнуть.
КонтрольОтпуска был придумал для обеспечения нужд исполнения мун. контрактов. Там заранее неизвестно что и как будут возить (товар обезличен и только в кг). Поэтому делали отдельный справочник а-ля номенклатуры (назвали ТоварТиС). Забивали в свой самописный документ объем по определенному мун.контракту, где позиции из ТоварТиСа. К ТоварТиС при поступлении и реализации привязывали конкретную позицию из справочника "номенклатура". Делали это руками. Привязка эта в документе нигде не хранится. Привязка каждый раз менялась при проведении других документов. Не ахайте. Не я писал. Да и тот человек, который писал, писал это буквально за пару суток в режиме кофе + энергентики. Зла не неё не держу. Но отсюда еще одна проблема: Даже, если я перенесу остатки по этому регистру. Восстановить по нему движения за 15 год я не смогу простым перепроведением. Надо будет запилить обработку, которая записывает в файл движения по регистру и еще одну которая корректно меняет неверные движения в порезанной базе. Хотя это просто проблема времени. Я это одолею. А вот как перенести этот гребаный регистр, кроме как купить у г-на Злопчинского волшебную обработку, я хз (((

Кто-то говорил, что порежу движения в таблице RG и база встанет. Нет не встала. Даже не попросила индексацию. Оставил в ней только движения за нужный период. Но и их оказалось более 800 000 записей. И когда формирую документ, все равно "ОстаткиПоРегистру" вылетают за 4 гига. Хотя я не трогал RA. Может она оттуда автоматически рассчитывает? Нашел копию базы на начало года размер поменьше 4,5 гига. Но тоже вылетает. Я, так понимаю, 1С повиснет, если в результате запроса будет такое количество строк, которое у нас формируется за месяц. Т.е. нужна обработка, которая месяц проходит не за один проход. А делит на несколько и формирует несколько документов.

(58) А где конкретно глянуть где лежат эти хинты? Я нуб, но посмотреть интересно.

(61) *.dds

(62) Спасибо, увидел

Ну так есть у кого двигатель регистров который итоги по регистру делит на несколько документов? Злопчинский что-то пропал. Наверное, решает, сколько с меня нищеброда попросить)))

Еще вопрос можно в теме?
В RG таблице за период все записи уникальны по совокупным значением всех измерений? Т.е., могут ли быть в таблице 2 и более записи, у которых одинаковые значения всех измерений, а разница только в ресурсах? Я подозреваю, что нет. Так как в этом и логика таблицы остатков.

(65) уникальна совокупность период+все измерения.

>>>что порежу движения в таблице RG и база встанет.

Зачет чо..
Если че, в RG - не движения , а промежуточные итоги

(66) Спасибо.
(67) Да я в курсе, что там. Но я полагал, что если не трону именно тот период, на который буду формировать итоги, Ска не будет трогать движения из RA, а сразу обратится к ним в RG. И думал, что возможно 1С пыталась весь этот файл сразу загрузить и если порежу его, то пухнуть не будет. Да глупо. 1С наверняка сразу открывает нужные записи. Но хотел просто проверить.

Теперь думаю, что сам запрос на дату, который включает более 800 000 записей вылетает. Т.е. надо дробить запрос. Да и представить документ, форма которого имеет такое количество строк тяжело. Думаю Ска банально не сможет его "прорисовать".

Всё она сможет. У вас при незакрытом регистре, в RG многократные дубли в каждом периоде. Вы тащите одинаковые записи из периода в период.

Просто сверните этот регистр, избавившись от лишней аналитики.
Размер RG должен быть у вас не 2 гига, а пару метров всего.

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

(70) В RG многократные дубли в каждом периоде.
Каким образом это происходит? Если итоги по не меняются, то логично, что они будут перетекать из периода в период. У нас некоторые контракты заключаются полгода назад, а движения по ним могут начаться только сейчас. Соответственно движения сделанные полгода назад будут повторяться в каждом периоде.

(71) Боюсь аналитика там вся нужная. Никаких лишних измерений нет. Все используются. Можно попробовать, как выше советовали, урезать их разрядность. Я попробую, кстати. Но существенно это не скажется на размере, мне кажется.
Фактически этот регистр помнит, сколько какого конкретного товара, по какому конкретному договору, за какой срок по какой цене мы должны вернуть нашему контрагенту. У одного контрагента может быть несколько договоров с разными сроками, в каждом из которых несколько позиций. Все это нужно помнить. Тут при всем желании в пару мегабайт не уложишься.

Зачем тогда регистр для этого ?
Храните в документе/справочнике.

Ну и это, перечисли измерения регистра

https://www.dropbox.com/s/oczj8omvnpe7mvg/Скриншот%202015-09-15%2010.50.16.png?dl=0

Не мой регистр, еще раз напомню))

Но я посчитал. Наверное вы правы. Что-то совершенно ненужное тянется. Ибо даже если взять 500 контрагентов * по 10 договоров на каждого и по 10 позиций получается всего 50 000. по идее такой длины должен быть период в RG. 800 000 записей - это слишком.

Хотя.. вот еще На один договор может быть по несколько заявок. Одна заявка на одни товары с одним сроком поставки. Другая на другие товары с другими сроками и т.д.

Что такое НачПериода и конПериода там ?
Что такое коддокумента ?

Сам клиентос в регистре не нужен, достаточно иметь договор

(81) Период действия заявки. Нельзя данный товар по этому договору отпускать ни раньше этого срока ни позже.
(81) Ссылка на документ, который вызвал движение. (Залез глянул вот: Регистр.КонтрольОтпуска.КодДокумента = ТекущийДокумент();

(75) а как в документах или справочниках хранить такие объемы информации? И тем более оперативно получить по ним данные на нужные даты?

(82) это же п...ц

Зачем это измерение, если и так есть всегда документ движения регистра ?

У тебя только из-за одного этого измерения, регистр НИКОГДА не закроется ВООБЩЕ.

(83) какие там "объемы" ?

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

Каким документом пишется приход в этот регистр, и каким расход ?

Что пишется в поле КодДокумента при приходе в регистр и что при Расходе ?

дай мд посмотреть

https://www.dropbox.com/s/ogwb2cwktergh1u/1Cv7.MD?dl=0

Чет сделал глобальный поиск "КонтрольОтпуска". Оказалось, что он больше используется, чем я думал.

(89) Везде в поле КодДокумента пишется просто текущий документ вызвавший движение.
Приход пишется документами ЗаявкаПокуп и ВозвратОтПокупателя. Расход только реализацией.

1. Выкинуть нах КодПокупателя из измерения, тому кто это измерение ввёл - дать в репу.
ЗЫ: там всего то пару строк заремить в модулях.

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

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

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

В общем, налицо, полная безграмотность в проектировании регистра, ОН вам вообще зачем ? По нему есть хоть один отчет (внешний) ?

Короче, смело удаляйте эти 3 измерения из регистра и пересчитывайте итоги (только по этому регистру).
Это для начала.
Аналогичные действия с регистром КонтрольОтпускаПоЗаявкам

(94) К Ёпрсту пойти что-ли работать? Накосячишь, максимум в репу даст. Ни четвертования, ни распятия на кресте, ни лишения премии.

(94) 2. Так тут НачПериод и КонПериод не период регистра, а период действия заявки, которая толкнула приход в регистр. Когда реализация проводится она смотрит на эти даты и сравнивает со своей текущей и если попадает, то дает добро на проведение.
(95) Так один из основных самых используемых отчетов на нем завязан. Смотрят сколько по какому договору заказали, сколько поступило и сколько реализовали. Нас нещадно сношают за неисполнение или переисполнение мун. контрактов. Там же, знаете, все до копейки должно сходиться. Да и первую очередь этот регистр ввели для контроля. Чтобы нельзя было принять и отпустить сверх нормы.

(98) реализация не смотрит на эти даты, вообще

Эти измерения нигде у вас не используются

(100) Мда... Попробую на копии сделать.
"Пересчитывайте итоги (только по этому регистру). "
Подскажите, как сделать? Сделать пустую базу такой же структуры и скопировать туда RA таблицу. Запустить ТиИ?

(101) не совсем.
База на дбф или скуле ?
Если скуль, то просто пересчет обработкой,
для дбф, копиряешь все RA и RG в отдельный каталог вместе с индексами
прибиваешь все RA и RG, оставляешь только RA от нужного регистра, заходишь монопольно, ставишь ТА в журнале на первый документ, потом на последний.Далее копируешь RG И RA обратно (окромя RA и RG пересчитываемого регистра) усё.

Для прибития измерений, прибиваешь перед этим RG этого регистра, можешь и руками прибить поля в табличке RA + подменить мд и словарик, чтоб не ждать реструктуризации. Это будет в разы быстрее на любой базе.

(102) Про sql не совсем понял как (мой случай). И про ДБФ спасибо большое. Записал себе в Евернот.

(104) там просто скриптом очистить поля, далее на выбор, либо alter table удалить колонки, либо просто реструктуризацией + truncate RG перед этим, потом обработкой пересчитать итоги.

https://cloud.mail.ru/public/LNWq/EnMpxJgH5

на вот, пересчитаешь этим

(107) огромное спасибо!!! Буду пробовать. Отпишусь.

Думал разберусь сам. Но немного не догоняю. Спрошу чтобы дальше не тупить.
(102) А подобный способ пересчета не сработает в Скуль-базе? Если да, то почему?
(103) Здесь вы описываете не пересчет регистров, а даете совет по ускорению реструктуризации при удалении измерений? RG регистр нужно удалять, чтобы 1Ска не мучилась с удалением столбцов в нем при применении новой конфигурации?
(105) "там просто скриптом очистить поля" - вот здесь не догнал. где именно?
"либо просто реструктуризацией + truncate RG" здесь наверное как в примере с ДБФ сначала truncate RG, а потом реструктуризация?

(109)
1. нет, в скуле всё проще, через qa
2.да
3. достаточно просто сделать truncate table RG***, далее реструктуризация базы (просто лишние измерения поудалять и заремит в модулях), далее любой обработкой пересч1ёт регистра.

(110) Все понял кроме термина "qa".

квери анализер

(112) понял.

(112) Уважаемый Ёпрст. Базу на 31,12,2014, можно сказать, свернул. Сделал на копии и попросил проверить всех, кто работает с базой - все ровно. Должен был в эти выхи успеть все провернуть на актуальном экземпляре, но не успел из-за длительности процесса.
Перенес из итогов по регистрам в пожатую базу только ОтстакиТМЦ и ПартииНаличие. Восстановил там ГП перепроведением всех перенесенных за 15 год документов. Неверно сформированные движения по кривому "КонтрольОтпуска" поправил Скуль-скриптом на основании данных из изначальной базы. Очистил таблицу итогов по нему и воспользовался вашей обработкой. За неё огромное вам спасибо! Все встало. Теперь жду на этой неделе поставку ССД дисков. Установлю их в сервант и на следующих выхах попробую прогнать процесс на них. Надеюсь, что отработает быстрее, и я успею за выходные все пожать и конвертнуть обратно в ДБФ.
По поводу оптимизации регистра.
Посмотрел я на измерения: НачПериод, КонПериод и КодДокумента. Как вы и сказали, они не используется в самой базе. Но они используются в нескольких отчетах. Их я поправлю в ближайшее время. Спасибо вам за ваш опытный взгляд.
Ну и собственно зачем пишу. Выше мне было предложено настучать в бубен человеку, который этот регистр сотворил. Чтобы не стать таким человеком и ввиду отсутствия опытных коллег в этой сфере, подскажите статью, мануал, гайд etc. где написано как правильно! проектировать регистры. И если можно еще хорошую статью о том, как правильно/канонично их сворачивать. Ну или общих словах самое основное.

Давай я тебе базу сверну за 3 часа. С учетом доработки конфигурации. Хочешь в DBF, а хочешь в SQL варианте. В SQL варианте будет раз в 10 быстрее

(115) Лучше покажи как :)

(116) Тут есть возможность сделать все гораздо быстрее. Можно было бы не восстанавливать ГП в пожатой базе, а скуль-скриптом, аналогично тому как я перенес движения для "КонтрольОтпуска" перенести движения для всех регистров. И установить ГП и ТА принудительно на нужную дату. Но я не стал заморачиваться - думал, что успею все за выхи обычным восстановлением сделать.

(115) 3 часа это для sql? ДБФ тогда 30 часов? или sql свернешь за 18 минут?))

(0)
http://www.softpoint.ru/article_id1.htm
Внедрение "Гибких блокировок" поможет.

База 16 GB сворачивается где то за час. Минут 10 формирование  документов переноса остатков. Часа 1.5 удаление документов без ссылок. На SQL удаление документов без ссылок идет существенно быстрее за счет использования прямых запросов.
  Чтобы научить потребуется существенно больше 3 часов. Алгоритмы стандартные см пост Злопчинский
  Универсальный документ по движению регистров, универсальный документ по сохранению периодических реквизитов, прямые запросы по удалению движений документов, обвязка

(120) "Чтобы научить потребуется существенно больше 3 часов. Алгоритмы стандартные см пост Злопчинский"
Ну хотя бы поэтапно напишите, как вы это делаете. Или может где в интернете есть статья?
А то я придумываю велосипед с квадратными колесами(

(119) Большое спасибо! Интересная статья!