|
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';
GO X++: 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
|
|
24.04.2009, 04:07 | #14 |
Участник
|
Цитата:
Сообщение от mazzy
Что-то странное у вас с производительностью.
В принципе 5млн записей - детский размер. Может все-таки кто-то блокировал InventSum, а изменение таблицы накладывает блокировку схемы. В результате, большую часть времени операция изменения таблицы ждала пока с InventSum будут сняты все блокировки? Вопросы: 1) Такие проблемы с вью - это нормально или нет? 2) Что можно сделать? Пока вижу варианты, которые не очень устраивают (потому что надо убеждать клиента в их необходимости)): - разграничить разработку отчетов и всего остального по времени / приложениям - переписать отчеты (много), чтобы не использовать вью Последний раз редактировалось rpr; 24.04.2009 в 04:10. |
|
24.04.2009, 08:42 | #15 |
Участник
|
Цитата:
...И становится затруднительно программировать на том же приложении...
Последний раз редактировалось ice; 24.04.2009 в 08:44. |
|
24.04.2009, 09:07 | #16 |
Administrator
|
Я думаю все проще. Бекап рабочей базы периодически разворачивается на разработческую - что очень удобно при отладке - есть все настройки, есть рабочий объемы данных для тестирования производительности и все такое
__________________
Возможно сделать все. Вопрос времени |
|
24.04.2009, 09:24 | #17 |
Участник
|
|
|
24.04.2009, 12:18 | #18 |
Участник
|
у нас 3 приложения - рабочее, тестовое и для разработки. Программисты клиента разрабатывают и запускают отчеты там же, где и мы (внедрители, так сказать) программируем. И тестируют их там, куда периодически надо переносить проекты.
|
|
24.04.2009, 14:13 | #19 |
Участник
|
тогда никакой проблемы нет согласовать ваши действия, во время переносов проектов надо прекратить тестирование, связанное с изменяемыми таблицами
|
|
24.04.2009, 09:47 | #20 |
Administrator
|
Не... стоп... Исходное сообщение было:
Поле вряд ли на тестовой добавляется. А вот какой размер разработческой БД - это уже другой вопрос.
__________________
Возможно сделать все. Вопрос времени |
|
Теги |
sql server, добавление поля, блокировка, синхронизация баз |
|
|