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

Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Войти
 
Страницы: Пред. 1 2
RSS
Начальное заполнение
 
Да, уже пробовал делать отдельно. Иначе не было бы такой извращенной идеи))
Просто один из справочников в 75000 элементов сжимается ОООчень долго, а у нас еще номенклатура под 700000...как то так...
Может будет с вашей стороны совет по увеличению производительности?

Может быть для вас будет важной такая информация:
Ваш журнал у нас использовался в версии до 2.0.0 база достигла размера 25 Гб
Возникла нештатная ситуация с нагрузкой на процессор скуля до 100% (виновник - регламентое задание по сжатию журнала)
Было принято решение апнуть журнал до версии 2.0.3.1 (там что то было обещано по производительности... )
Обновка не встала, не выполнился скрипт на изменение таблицы:
Ошибка выполнения запроса:
ALT ER TABLE [dbo].[journ_rec] ALTER COLUMN nametp nvarchar(150);

{Обработка.внНастройкаЖурналаРегистрации.МодульМенеджера(83)}: Ошибка при вызове метода контекста (Execute)
Command.Execute();
по причине:
Произошла исключительная ситуация (Microsoft OLE DB Provider for SQL Server): Время ожидания запроса истекло
Ошибка выполнения запроса:
ALT ER TABLE [dbo].[journ_rec] ALTER COLUMN namerec nvarchar(150);

{Обработка.внНастройкаЖурналаРегистрации.МодульМенеджера(83)}: Ошибка при вызове метода контекста (Execute)
Command.Execute();
по причине:
Произошла исключительная ситуация (Microsoft OLE DB Provider for SQL Server): Время ожидания запроса истекло
Ошибка выполнения запроса:
ALT ER TABLE [dbo].[journ_rec] ALTER COLUMN typerec tinyint;

{Обработка.внНастройкаЖурналаРегистрации.МодульМенеджера(83)}: Ошибка при вызове метода контекста (Execute)
Command.Execute();
по причине:
Произошла исключительная ситуация (Microsoft OLE DB Provider for SQL Server): Время ожидания запроса истекло
Подсистема <Журнал регистрации изменений во внешней БД MS SQL Server> обновлена на версию 2.0.1.6

Поэтому приняли решение начать с нуля, вот отсюда и весь "колхоз".. ))
Да, кстати при сжатии кэша запрос производится на весть объем кэша, а почему не порциями скажем хотя бы по 5000 позиций?
Например если я проведу заполнение только по одному справочнику в 700000 позиций, то все это разгребаться будет долговато...

И еще, получается журнал хранит полные образы объектов в случае их изменения и показывает только отличия при просмотре?
 
Можно было выполнить этот же запрос просто на MS SQL и там бы таймаута не было, либо увеличить в настройках время работы запроса и поставить "0" тогда запрос выполнялся бы до тех пор пока не выполнится.
Надо было раньше написать, с этой проблемой но коль так, то теперь все по новой...

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

Все тормоза идут именно при сжатии. Сейчас у нас каждая запись добавляется
INSERT INTO ... VALUES ...
Хотим сделать массовый INSERT во временную таблицу, а уже ее копировать в таблицу основной БД в транзакции.
Пока тестов не было, но по оценкам это может увеличить скорость в несколько раз (а то и десятков раз).

По поводу загрузки MS SQL на 100%. Тут все сложно... Мы думали как сделать процесс сжатия наиболее безболезненным в крупных ИБ. Основное, что пришло на ум и в данный момент в планах:

1) Добавить переменную, типа "Количество обрабатываемых данных за регламентное задание". Т.е. обрабатываем в кэше N-записей, после чего прекращаем работу, результат - уменьшение нагрузки на MS SQL. Сейчас происходит сжатие всех данных, которые есть на момент начала задания. Т.е. если было массовое перепроведение в течение дня, то ловим загрузку MS SQL в 100% при порционности от этого уйдем, но будет другая проблема, скорость обработки.
2) Я уже сказал про временные таблицы. Их добавление позволит увеличить производительность.
3) После добавления п.1 можно уменьшить интервал работы регламентного задания с минимальным временем, т.к. будет выполнятся обработка только N-записей, где N будет задаваться в настройках, то нагрузка должна будет уменьшится.

Эти три пункта по нашему мнению смогут существенно увеличить производительность и количество обрабатываемой информации.
Автоматизация сегодня - Ваш успех завтра
 
Добрый день!
Сейчас стал добавлять объекты в форме "Регистрируемые объекты"
Снимок1 - как было в изначальном ТЗ. Сохранил. Закрыл.
Снимок2 - опять вошел и вижу два нижних крыжика стоит
Это так и должно быть? По идее ни на что влиять не должны, но сам факт. Если так надо, то тогда интересно ЧТО еще выставляется автоматом не интерактивно?
 
Добрый день.
Там нет ничего.
Пустые ветки ни на что не влияют.
Автоматизация сегодня - Ваш успех завтра
 
Еще одно неудобство. Список регистрируемых объектов слишком растянут. У меня не умещается ни сама форма, ни список. Очень неудобно. Нельзя ли список сделать автонастраиваемым ("прилепленным" к краям формы)?
 
Ок. Посмотрим, что можно сделать для того, чтобы все помещалось.
Автоматизация сегодня - Ваш успех завтра
 
Еще небольшая проблема:
1. Всё делаю по инструкции (прикрепленный файл)
2. Первый запуск - крыжик снимается
3. Выхожу с Предприятия, в конфигураторе ОПЯТЬ ставлю крыжик. Запускаю. Крыжик более не чистится

это только при первом запуске при уже накатанной конфигурации "Журнал..." со всеми установленными изменениями по инструкции по установке
замечено на всех первых 8 базах.
 
Добрый день.
Хорошо, проверим.
Автоматизация сегодня - Ваш успех завтра
Страницы: Пред. 1 2
Читают тему