Начальное заполнение

Поиск  Пользователи  Правила  Войти
Страницы: 1 2 След.
RSS
Начальное заполнение
 
#1
Нравится0
06.05.2014 10:30:51
Почему не происходит "Начальное заполнение", галочки стоят (снимал их, применял, снова ставил, применял).
Изменения в доках фиксируются, но только как первый раз, весь док. целиком.
Хватит ли 7 часов для Начального заполнения БД~ 100GB (ВСЕ ОбъЕКТЫ)?

версия 1.0.5.5
УТ 10.3
MSSQL 2012
 
 
 
#2
Нравится0
06.05.2014 10:31:59
Вы разместили в теме "Управление IT-отделом 8", наверное имели ввиду "Журнал регистрации изменений во внешней БД MS SQL". Тему перенес.
Выполнение первоначального заполнения этап очень долгий во время, которого, подсистема переберет ВСЕ объекты и запишет их текущее состояния со ВСЕМИ реквизитами. Если информационная база достаточно большая, то лучше этот шаг пропустить.
Автоматизация сегодня - Ваш успех завтра
 
 
 
#3
Нравится0
07.05.2014 10:32:36
как запустить процесс начального заполнения?
Сегодня обнаружил что автоматическое сжатие истории каждые 5 мин. не происходит.
Только в рукопашную запускается "сжатие истории". Как автоматизировать "сжатие истории"?
 
 
 
#4
Нравится0
23.05.2014 10:34:57
Добрый день! У нас установлена конфигурация УТ 10.3 с модулем 1С:Рарус CRM 1.4 (Управление торговлей и взаимоотношениями с клиентами 1.1.20.1). Конфигурация доработана, но доработок немного, и в основном это новые реквизиты в документах или печатные формы. Купили ваш журнал регистрации. Установили все по инструкции база 1С клиент-серверная на PostgreSQL, база журнала регистрации на MS SQL Server Express.
При попытки начального заполнения журнала, обработка заполнения зависает на пункте обработки бизнесс процессов, хотя галочка с регистрации этих объектов вообще снята. Как вариант может быть заполнение зависает после обработки всех объектов(среди которые "бизнесс процессы" последний).
Ждал около 24 часов заполнения, потом выключил в диспетчере задач. Пробовал выделять только один тип документов для начального заполнения, причем таких документов в базе всего 3, результат тот же.
Подскажите, пожалуйста, в чем может быть причина?
 
 
 
#5
Нравится0
23.05.2014 10:35:27
Этап начального заполнения не является обязательным.
И для больших баз этот этап мы даже НЕ РЕКОМЕНДУЕМ проводить.
Есть подозрение, что резервов MS SQL Express маловато для первоначального заполнении. Все таки эта версия содержит ограничения и по производительности и по размеру файлов.
Просто не делайте на этой базе первоначальное заполнение и все.
Автоматизация сегодня - Ваш успех завтра
 
 
 
#6
Нравится0
23.05.2014 10:35:52
Мне нужно сделать первоначальное заполнение, чтобы контролировать изменение документов хотя бы последней недели рабочей. А то, что не хватает размера базы Express версии SQL, быть не может, ведь я выделяют для начального заполнения только счета на оплату, которых в базе ВСЕГО 3 ШТУКИ, то есть подсистема должна записать в базу данные всего о 3-х документах.
 
 
 
#7
Нравится0
23.05.2014 10:36:14
Хорошо, проверим.
Автоматизация сегодня - Ваш успех завтра
 
 
 
#8
Нравится0
27.05.2014 10:36:39
cherleon пишет:Мне нужно сделать первоначальное заполнение, чтобы контролировать изменение документов хотя бы последней недели рабочей. А то, что не хватает размера базы Express версии SQL, быть не может, ведь я выделяют для начального заполнения только счета на оплату, которых в базе ВСЕГО 3 ШТУКИ, то есть подсистема должна записать в базу данные всего о 3-х документах.
Добавлю также, что у меня зависает и "Сжатие истории", а значит и "Очистка истории".
Жду результата проверки, вопрос очень актуальный и нужный для меня. Заранее спасибо.
 
 
 
#9
Нравится0
18.11.2014 10:38:05
У нас база большая, но начальное заполнение провести просто необходимо иначе все "разборы полетов" между пользователями - филькина грамота.
Что удалось понять:
1. Первоначальный образ объектов льется в справочник-кэш и потом "разгребается в скуль" (сжимается) регламентным заданием.
2. Ясно то, что за ночь сия процедура не пройдет и мы имеем ОООчень длительную транзакцию попутно с добавленим данных пользователей...что не есть гуд...

Поэтому нужна консультация автора по следующей идее:
1. Предположим мы делаем копию базы(фиксируем состояние объектов) и производим в ней операцию первоначального заполнения (конечно она не связана с базой(журналом) на журнал на скуле)
2. Ясно, что образ данных падает в кэш копии и он оч. большой (регламентное задание не включаем)
3. В основной базе (продуктивной) включаем журнал на регистрацию событий пользователей и попутно через OLE (ну COM-соединение) вбрасываем в кэш основной базы из кэша базы-копии наши образы объектов малыми порциями, а стандартное регламентное задание продуктивной базы стандартно сжимает записи в скуль...
4. Да пусть хоть неделю работает...))

Вопрос: нормально ли ляжет история в журнал на скуле? где засада?
Конечно смотрел код, но не все ясно с идеологией, поэтому слово автора необходимо.
 
 
 
#10
Нравится0
18.11.2014 10:38:41
Да, будет нормально.

Можно так же делать небольшими порциями только пройтись по дереву метаданных.
Сначала сделать справочники: Организации, Номенклатура, ... можно по одному, можно сразу несколько объектов метаданных.
Потом пройтись так же по документам.

Да и вообще, если разобраться даже в больших базах не так много именно важной информации, для которой необходимо делать первоначальный образ. В основном это часто используемые справочники типа Номенклатуры, Единицы измерения, Контрагенты, Договоры и Организации, а так же документы, за 3 последних месяца. Это поступление и реализация. Если образ для объекта создан не будет, то он будет создан при первом изменении объекта после внедрения журнала.

Совет. Не обязательно делать ПОЛНЫЙ образ всех объектов. Есть объекты где это не нужно, например, справочник Банки и аналогичные, а есть где это не только не нужно, но и противопоказано, например, регистр сведений типа АдресныйКлассификатор, где изменения данных вообще не критичны, но если их добавлять в образ, то это огромный объем не нужной информации.
Автоматизация сегодня - Ваш успех завтра
 
 
 
Страницы: 1 2 След.
Читают тему