Имя: Пароль:
1C
1С v8
Реструктуризация регистра бухгалтерии при изменении плана счетов
0 senior
 
03.11.15
11:31
Изменил структуру регистра бух. При просмотре SQL запросов видно, что реструктуризация осуществляется неспешно путем чтения и записи партиями по 1000 строк, при этом загрузка железа 3-5%. Есть варианты как это побороть, устал ждать
1 cons74
 
03.11.15
11:38
(0) Во-первых, это ты зря. Бух регистр менял.
Во-вторых, в поиск "реструктуризация ускорить". Но там вроде не много способов и чуда я бы не ждал.
2 Necessitudo
 
03.11.15
11:39
3 senior
 
03.11.15
12:20
(1) почему зря
4 Aloex
 
03.11.15
12:30
(0) Жди, после реструктуризации, пойдет пересчет итогов.
5 senior
 
03.11.15
12:31
мне больше всего непонятно почему размер одной порции данных выбран такой маленький
6 Ненавижу 1С
 
гуру
03.11.15
12:33
интересно, что ты решил там изменить?
7 Aloex
 
03.11.15
12:35
(0) >>при этом загрузка железа 3-5%

Посмотри загрузку файловой системы на сервере SQL.
8 Лефмихалыч
 
03.11.15
13:01
(0) в скуле переименовать текущую таблицу регистра. Создать новую с такой же структурой и именем, как у текущей. Провести реструктуризаяца штатно. Потом скулём же поправить структуру старой талбицы, чтобы совпадала с новой. Новую убить, старую переименовать обратно.


Только бэкап сделай прямо сейчас. Два. И разложи по разным машинам.
9 senior
 
03.11.15
13:30
(6) добавил субконто
10 senior
 
03.11.15
13:30
(8) я уже прочитал про этот вариант, да как-то опасаюсь, вдруг там сопутствующие изменения в др. таблицах
11 МихаилМ
 
03.11.15
13:33
+(8)
чтобы подсмотреть профайлером, что делает 1с, в таблице должны быть данные.

иначе 1с не будет делать пресечет
12 Ненавижу 1С
 
гуру
03.11.15
13:41
(9) четвертое?
13 senior
 
03.11.15
13:45
(12) сорри, в теме неправильно указал, изменен план счетов, субконто на один из счетов
14 Eugene_life
 
03.11.15
14:15
(13) Жди теперь, ничего ты не сделаешь быстрее чем дождаться.
Если регистр большой, то может реструктуризация идти десятки часов, а пересчет итогов - и еще больше.
15 hhhh
 
03.11.15
14:24
(13) 1000 - это вроде самое оптимальное. Слишком большой размер транзакции тоже плохо, будет гораздо медленнее выполняться.