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