|
После подключения к хранилищу начинается реструктуризация |
☑ |
0
break
13.03.15
✎
10:05
|
Всем привет! Порядок действий такой ((8.2.17.153):
- Объединяю копию рабочей базы с cf хранилища,
- подключаю к хранилищу
- сравниваю с конфигурацией хранилища, отличий нет
- начинаю обновлять базу и вот тут начинается реструктуризация, похоже всех объектов с пересчетом итогов, и это затягивается на полдня. Почему срабатывает реструктуризация, если конфигурации не отличаются?
Как ускорить подключение и готовность базы?
|
|
1
break
13.03.15
✎
10:06
|
База серверная, в процессе реструктуризации ее раздувает почти в двое
|
|
2
Лефмихалыч
13.03.15
✎
10:10
|
(0) отличия есть, просто они между конфигурацией поставщика и конфигурацией БД
|
|
3
break
13.03.15
✎
10:10
|
(2) самописка
|
|
4
Лефмихалыч
13.03.15
✎
10:11
|
(3) похер
|
|
5
break
13.03.15
✎
10:13
|
(4) в поле конфигурация поставщика пусто, или это не там смотрю?
|
|
6
Лефмихалыч
13.03.15
✎
10:14
|
при сравнении объекты сопоставляются по имени, при загрузке измененной конфигурации объекты сопоставляются по внутреннему ИД. Подключение к хранилилщу - это загрузка конфигурации.
Если есть реструктуризация, значит в конфигурации поставщика, БД или/и хранилища различаются ИД каких-то объектов с идентичными именами
|
|
7
break
13.03.15
✎
10:29
|
(6) т.е. чтобы от этого избавиться и ид совпадали, надо из рабочей конфы создать новое хранилище?
|
|
8
Лефмихалыч
13.03.15
✎
10:31
|
(7) один из вариантов.
Еще можно натянуть на хранилище конфу БД, чтобы объекты с разными ИД, но одинаковыми именами, создались удалились и создались заново. Так ты историю в хранилище не потеряешь
|
|
9
vde69
13.03.15
✎
10:34
|
(7) правильно делать так
1. делается SQL бекап с рабочей
2. этот бекап поднимаем в отдельную базу
3. из этой отдельной базы создаем хранилище
еще, что влияет
1. наличие УФ если основной режим обычный, тогда все УФ будут распознаны как "измененые"
|
|