|  16.04.2009, 19:30 | #1 | 
| Участник | добавление поля в таблицу с огромным количеством записей 
			
			При добавлении нового поля в InventSum Аксапта виснет при синхронизации с SQL. В другие таблицы поля добавлются нормально. Если прервать синхронизацию (насильно выйти из аксапты), то поле будет создано только в приложении, но не в бд -> будут ошибки при выполнении запроса к InventSum. Пробую 2, 3-звенку, разные имена полей и разные EDT (даже без EDT), "проверить/синхронизировать" таблицу перед добавлением, переиндексировать таблицу, заливать проектом - не помогает. В InventSum более 5 миллионов записей. Помогите идеями, пожалуйста. Ax 3.0, build 1951.5160 / 514-513 SP5 / OP023-379, MS SQL 2000 Последний раз редактировалось rpr; 16.04.2009 в 19:35. | 
|  | 
|  16.04.2009, 19:45 | #2 | 
| Участник | Цитата: 
		
			Сообщение от rpr
			   При добавлении нового поля в InventSum Аксапта виснет при синхронизации с SQL. В другие таблицы поля добавлются нормально. Если прервать синхронизацию (насильно выйти из аксапты), то поле будет создано только в приложении, но не в бд -> будут ошибки при выполнении запроса к InventSum. Пробую 2, 3-звенку, разные имена полей и разные EDT (даже без EDT), "проверить/синхронизировать" таблицу перед добавлением, переиндексировать таблицу, заливать проектом - не помогает. В InventSum более 5 миллионов записей. Помогите идеями, пожалуйста. Ax 3.0, build 1951.5160 / 514-513 SP5 / OP023-379, MS SQL 2000 Аксапта не виснет, она ждет, пока SQL изменит таблицу. Если посмотреть активные процессы БД, то видно, что идет alter table. Резюме: дождаться окончания изменения таблицы на SQL сервере. | 
|  | 
|  16.04.2009, 19:55 | #3 | 
| Участник | Цитата: За час ничего не изменилось, попробую оставить на ночь. | 
|  | 
|  16.04.2009, 20:16 | #4 | 
| MCITP |   Цитата: Хотя для 5 млн. (кстати, вы путаете понятие "огромная" и просто "большая" таблица  ) час это уже много, имхо... В любом случае для начала не мешало бы попробовать дождаться... Поставьте на ночь... 
				__________________ Zhirenkov Vitaly | 
|  | 
|  16.04.2009, 20:27 | #5 | 
| Участник | Цитата: X++: USE master;
GO
EXEC sp_who 'active';
GOX++: USE master EXEC sp_lock X++: DBCC INPUTBUFFER (<SPID>) | 
|  | 
|  16.04.2009, 22:26 | #6 | 
| Участник | 
			
			Еще надо контролировать свободное место на дисках под БД. При изменении структуры таблиц сильно увеличивается файл с логом БД. Ну и посмотрите на загрузку дисков через Perfomance monitor. Она должна быть гораздо выше 100%.
		 | 
|  | 
|  16.04.2009, 23:36 | #7 | 
| MCITP |   
				__________________ Zhirenkov Vitaly | 
|  | 
|  17.04.2009, 08:12 | #8 | 
| Участник | Цитата: поэтому убедитесь, что места для новой таблицы достаточно и дождитесь окончания процесса. | 
|  | 
|  17.04.2009, 08:17 | #9 | 
| Программатор | 
			
			Известная вещь в сабже. Сам сижу по 15-20 минут и думаю: происходит чонить или нет. А смотреть и куда то лезть - лень. После пары перекуров - всё ок. ИМХО нужно ждать пока отвиснет...
		 | 
|  | 
|  17.04.2009, 11:58 | #10 | 
| Участник | 
			
			Прошла ночь) - и поле добавилось. Выполнялся "ALTER TABLE". Спасибо за советы)
		 | 
|  | 
|  17.04.2009, 12:13 | #11 | 
| Участник | 
			
			Что-то странное у вас с производительностью. В принципе 5млн записей - детский размер. Может все-таки кто-то блокировал InventSum, а изменение таблицы накладывает блокировку схемы. В результате, большую часть времени операция изменения таблицы ждала пока с InventSum будут сняты все блокировки? В общем, я хочу сказать, что час-два - это еще можно объяснить. Но "ночь" - это уже что-то ненормальное. | 
|  | 
|  17.04.2009, 12:23 | #12 | 
| Участник | |
|  | 
|  17.04.2009, 12:25 | #13 | 
| Участник | 
			
			Например, в enterprise manager, management, activity monitor, Locks by Object
		 | 
|  | 
|  17.04.2009, 12:41 | #14 | 
| Участник | Цитата: Пришлось использовать X++: USE master EXEC sp_lock | 
|  | 
|  17.04.2009, 13:16 | #15 | 
| Участник | 
			
			это первый признак, что сервер был занят по самые помидорки. в следующий раз используйте команду sp_who2 или sp_who для того, чтобы получить список юзеров | 
|  | |
| За это сообщение автора поблагодарили: rpr (1). | |
|  19.04.2009, 13:20 | #16 | 
| Участник |   
			
			есть бесплатная утилитка - http://sqlblocks.narod.ru/index.html ...
		 | 
|  | |
| За это сообщение автора поблагодарили: Logger (2), rpr (1). | |
|  24.04.2009, 04:07 | #17 | 
| Участник | Цитата: 
		
			Сообщение от mazzy
			   Что-то странное у вас с производительностью. В принципе 5млн записей - детский размер. Может все-таки кто-то блокировал InventSum, а изменение таблицы накладывает блокировку схемы. В результате, большую часть времени операция изменения таблицы ждала пока с InventSum будут сняты все блокировки? Вопросы: 1) Такие проблемы с вью - это нормально или нет? 2) Что можно сделать? Пока вижу варианты, которые не очень устраивают (потому что надо убеждать клиента в их необходимости)): - разграничить разработку отчетов и всего остального по времени / приложениям - переписать отчеты (много), чтобы не использовать вью Последний раз редактировалось rpr; 24.04.2009 в 04:10. | 
|  | 
|  24.04.2009, 08:42 | #18 | 
| Участник | Цитата: 
		
			...И становится затруднительно программировать на том же приложении...
		
	 Последний раз редактировалось ice; 24.04.2009 в 08:44. | 
|  | 
|  24.04.2009, 09:07 | #19 | 
| Administrator | 
			
			Я думаю все проще. Бекап рабочей базы периодически разворачивается на разработческую - что очень удобно при отладке - есть все настройки, есть рабочий объемы данных для тестирования производительности и все такое
		 
				__________________ Возможно сделать все. Вопрос времени | 
|  | 
|  24.04.2009, 09:24 | #20 | 
| Участник | |
|  | 
| Теги | 
| sql server, добавление поля, блокировка, синхронизация баз | 
|  | 
| 
 |