Сергей (Все сообщения пользователя)

Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Войти
 
Выбрать дату в календареВыбрать дату в календаре

Страницы: 1
Начальное заполнение
 
Да, уже пробовал делать отдельно. Иначе не было бы такой извращенной идеи))
Просто один из справочников в 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 позиций, то все это разгребаться будет долговато...

И еще, получается журнал хранит полные образы объектов в случае их изменения и показывает только отличия при просмотре?
Начальное заполнение
 
У нас база большая, но начальное заполнение провести просто необходимо иначе все "разборы полетов" между пользователями - филькина грамота.
Что удалось понять:
1. Первоначальный образ объектов льется в справочник-кэш и потом "разгребается в скуль" (сжимается) регламентным заданием.
2. Ясно то, что за ночь сия процедура не пройдет и мы имеем ОООчень длительную транзакцию попутно с добавленим данных пользователей...что не есть гуд...

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

Вопрос: нормально ли ляжет история в журнал на скуле? где засада?
Конечно смотрел код, но не все ясно с идеологией, поэтому слово автора необходимо.
Страницы: 1