Ускорение добавления регистра? #452800

Есть база. В ней много документов. Возникла нужда в новом регистре и документе. Как понимаете, штатным способом это будет долговато. Родилась идейка. Берём чистую базу с тем же md. В нём добавляем нужные данные. Потом в рабочую просто вставляем новые таблицы, поле в _1sjournal и подменяем MD. Могут ли быть после этого какие-то негативные последствия? Кто-то пробовал? Я ничего не упустил?

ты забыл про вазелин

Его ещё заслужить надо :-) Я имею в виду - технические детали.

Должно прокатить..Но я чето очкую )))

+ по сабжу..Я так не пробовал

Не, ну разумеется, сначала проверю на копии :-) Просто интересно, чего я ещё не знаю.

вот я и говорю - намажь заранее, а то потом недадут

Эта ветка и есть намазывание. ЧТобы потом не понадобился

ну он же на копии

Могут, есть человеческий фактор :) Ченить забудешь и грохнешь базу :))) При этом накой тебе так извращаться? Ты мд-ешник не подставишь, пока в базе юзвера :) ...Так что вазелину бери побольше :) При этом не факт что база спустя недельку не грохнетси :)

Для чего - у нас база крутится 24*7. Поэтому для такого обновления нужно специально выбирать время и останавливать работу. Чтобы не забыть  - завёл эту ветку.

А dd?

Во, один пункт уже забыл :-)

И шо, вы ужо и итоги вообще не пересчитываете? И какого у вас размеру база? И база DBF or SQL?

а распределенка есть? ... сделал бы полную копию и замерил по-времени сколько займет обновление. Или база гигов двадцать-больше? Будет жить, если и ссылочная целостность не нарушится, иначе - наступаешь на ТИИ и всё уходит в глубокое досвидание, а твоя "экономия времени" оканчивается встречей НГ с красной задницей вместо красной морды.

А причём тут итоги для новго регистра? База sql, 20Г Распределенка есть. Это како-то повлияет?

не итоги а ссылки и их целостность. Если есть распределенка = только штатно, или будешь прыгать со своим нештатным "ускорением" по всем распределенкам, проделывая ровно то-же, что и в ЦБ, сразу после, или чуть погодя, когда обмен "ляжет", а "лечь" может конкретно и надолго.

Как раз в периферийку можно грузить долго и счастливо, не заморачиваясь :-) А ссылки какие? Я же не удаляю ничего, а только добавляю новое. На них ссылок просто нет.

Кроме того, периферийку можно заново поднять из основной...:-)

Да ты успокойся, я уже сто раз так делал, и все время прокатывало!

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

Нормально всё будет.

+ Только еще в _1SJOURN не забудь колонку добавить.

Не понятно, что значит добавляем нужные данные. Добавить необходимые (новые) поля в таблицы и сами таблицы получится 100%. Я так всегда делаю, если таблицы большие. Для этого есть старый добрый FOXPRO. Если в новом регистре будут движения только нового документа - способ самый быстрый. А вот если в новом регистре должны отражаться еще и движения уже существующих документов, то тут ещё колдовать придется.

+ на SQL не пробовал (там и так всё быстро обновляется).

"там и так всё быстро обновляется" - ты базы-то хоть видел большие? Быстро унего в скуле обновляется... Юморист.

а большие это какие?

На несколько десятков гигов хотя бы.

это не ответ. Несколько это сколько 10 десятков, 15 десятков или сколько?

У автора, на сколько я помню, 20 гигов. Это что-то изменило?

Вот когда в ДБФ базу с одним только справочником номенклатуры размером под 900 Мбай, пытаешься вставить какое-нибудь поле, так вот это будет долго.

Ты, вообще, о чем сейчас? Или так, поговорить?

Подожди, пошел смотреть размер

Делай штатно и незаморачивайся. При больших изменениях у меня базы по 60-100 Гиг обновляются за 1-2 часа (пересчет итогов). Проверь что б у всех документов была заполнена дата - итоги пересчитывет быстрее.

При SQL базе в 23Г последний раз 3 новых документы добавлял летом, и времени на это ушло по минуте на документ.

+ Новый регистр делался 14 минут на той же базе

Соглашусь с . Зачем при SQL варианте чего-то мудрить. Много времени не съэкономишь. Засеки на своей машине сколько времени уйдет на обновление, если устроит, то и не придумывай ничего.

Если просто добавлять документ, то да, быстро. А вот если его еще надо в список отбора по контрагентам или еще куда, то уже совсем другое время...

Я незнаю что можно добавлять что б обновлялось больше 2-х часов. Основное время это пересчет, само изменение МД занимает копейки и неактуально.

Не ссорьтесь, горячие парни :-) Добавление одного регистра у меня прошло за час 20. Документ добавился на удивление быстро.

24*7? И даже 1го января с 00.00?

На твоей машиен или на рабочем сервере?

И неужели тебя это время не устраивает и хочешь заняться исследованиями?

Документов у вас в базах сколько, шустрики?

Нет, с 3-го с 8.00:-) На сервере. Это простейший регистр.

Количестом документов уже же как-то мерялись

А основное время уходит не на регистр. А на проставление нолика в каждую строчку _1SJOURN. Так что структура регистра - по барабану.

Вдумчиво прочитай .

Я в курсе, мне говорили :-))

Вот и молодца :)

На сколько быстрее будут ручные манипуляции?

В десятки, а то и в сотни раз.

Если скрипт написать, то за 2 минуты управится.

Для примера: доюавление регистра в базе, в которой чуть больше 16 лямов документов, на серваке, картинка которого в личке, добавление регистра штатными средствами - около 4-х часов. Ручками - несколько минут.

Если сравнивать 4 часа и несколько минут, тогда конечно. А так, отправил всех на час обедать и пусть вносятся штатными средствами.

В том-то и дело, что в час фиг укладываешься. Да и пользователей от базы на час оторвать - проблема.

Уговорил, пиши, потом поделишься.

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

"Ночью обновись и забудь." - ключевое слово 24*7

"Ночью обновись и забудь" - везет тебе. У тебя ночью в базе пользователи не работают... А что там писать-то? CREATE TABLE и ALTER TABLE ? В чем проблема?

У вас что там - база пентагона крутится? Или отгрузки склад фигачит? Собственно если и работают то думаю не в ЦБ а в ПБ, и это вовсе немешает обновить ЦБ.

Такого не бывает. Всё равно есть дни и время, когда можно вклиниться с обновлением.

Жэсть :)

Бывает. Когда все работают в ЦБ и переломить юзеров прогам неподсилу.

А ты предположи, что на подстанции тупо свет отключили, или у вас свой дизель-генератор? А если всякого рода случаи предполагать, то надо сразу и для ИТ служб время выделять для профилактических работ.

А почему ты считаешь, что только ЦБ может быть большой?

"или у вас свой дизель-генератор?" - именно так.

Производство и отгрузки. Работают в центре.

есть. В воскресенье с 21 до 23.

А какой мощности? На всех пользователей хватает?

А схема резервного питания только для ИТ службы или ещё на что-нибудь?

А дизель постоянно работает или заводится только при пропадании основного питания?

Такое бывает только до первой серьезной проблемы с базой. А после решения хотя бы одной подобной проблемы руководство сразу же идет на встречу службам АСУ и организационно находят время для профилактических работ на информационной системе.

да тупо отрубаеш сетьевой из сервака и все... хотите не хотите а сервак мне чинить есче Н часов, хрен минут...

Сетьевой = витая пара...

будут ждать как миленькие... и  чтоб через каждые 5 мин. не спрашивали "когда все запуститься?" - рявкнуть, мол будите отвлекать мол ченить попутаеш и вообче в следующем году тада стартанут. Тада вообче в твою сторону дышать побоятся :))

Похоже скрипта так и не дождемся. Такого, чтобы дать ему новый MD, название рабочего каталога базы 1с, а он тебе через пару минут: Пожалуйста, сделан новый документ ..., регистр ..., объединение MD выполнено, можете работать.

Дождёмся. Когда я его напишу и отлажу.

Спасибо, я так и думал, что ты не успокоишься

не успокаиваешься как раз ты.

Да я не в том смысле... Просто чего-то сегодня уже лень что-то новое начинать.