добавление поля в таблицу с огромным количеством записей

[rpr]

При добавлении нового поля в InventSum Аксапта виснет при синхронизации с SQL. В другие таблицы поля добавлются нормально.

Если прервать синхронизацию (насильно выйти из аксапты), то поле будет создано только в приложении, но не в бд -> будут ошибки при выполнении запроса к InventSum.

Пробую 2, 3-звенку, разные имена полей и разные EDT (даже без EDT), "проверить/синхронизировать" таблицу перед добавлением, переиндексировать таблицу, заливать проектом - не помогает.

В InventSum более 5 миллионов записей.

Помогите идеями, пожалуйста.

Ax 3.0, build 1951.5160 / 514-513 SP5 / OP023-379, MS SQL 2000

[YellowSubmarine]

Цитата:

Сообщение от 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 сервере.

[rpr]

Цитата:

Сообщение от YellowSubmarine

Аксапта не виснет, она ждет, пока SQL изменит таблицу. Если посмотреть активные процессы БД, то видно, что идет alter table.

Резюме: дождаться окончания изменения таблицы на SQL сервере.

этот процесс имеет статус 'sleeping' в SQL, что означает - SQL сервер ждет ответа от аксапты.

За час ничего не изменилось, попробую оставить на ночь.

[ZVV]

Цитата:

Сообщение от rpr

этот процесс имеет статус 'sleeping' в SQL, что означает - SQL сервер ждет ответа от аксапты.

За час ничего не изменилось, попробую оставить на ночь.

Возможно вы смотрите не ту сессию в БД, Аксапта может иметь 2 и более соединений с сервером SQL в двухзвенке...

Хотя для 5 млн. (кстати, вы путаете понятие "огромная" и просто "большая"
таблица ) час это уже много, имхо...

В любом случае для начала не мешало бы попробовать дождаться... Поставьте на ночь...

[rpr]

Цитата:

Сообщение от ZVV

Возможно вы смотрите не ту сессию в БД, Аксапта может иметь 2 и более соединений с сервером SQL в двухзвенке...

А как лучше всего смотреть сессии в БД? Я запускаю:

USE master;
GO
EXEC sp_who 'active';
GO

и

USE master
EXEC sp_lock

Потом подозрительные сессии смотрю как:

DBCC INPUTBUFFER (<SPID>)

[YellowSubmarine]

Цитата:

Сообщение от rpr

этот процесс имеет статус 'sleeping' в SQL, что означает - SQL сервер ждет ответа от аксапты.

За час ничего не изменилось, попробую оставить на ночь.

Еще надо контролировать свободное место на дисках под БД. При изменении структуры таблиц сильно увеличивается файл с логом БД. Ну и посмотрите на загрузку дисков через Perfomance monitor. Она должна быть гораздо выше 100%.

[ZVV]

Цитата:

Сообщение от YellowSubmarine

... Она должна быть гораздо выше 100%.

Гм...

[mazzy]

Цитата:

Сообщение от rpr

При добавлении нового поля в InventSum Аксапта виснет при синхронизации с SQL. В другие таблицы поля добавлются нормально.

При добавлении поля средствами Аксапты, на сервере может происходить не Alter Table, а создание другой таблицы, копирование данных в нее, удаление исходной и переименование новой.

поэтому убедитесь, что места для новой таблицы достаточно и дождитесь окончания процесса.

[Sada]

Известная вещь в сабже. Сам сижу по 15-20 минут и думаю: происходит чонить или нет. А смотреть и куда то лезть - лень. После пары перекуров - всё ок. ИМХО нужно ждать пока отвиснет...

[rpr]

Прошла ночь) - и поле добавилось. Выполнялся "ALTER TABLE". Спасибо за советы)

[mazzy]

Цитата:

Сообщение от rpr

В InventSum более 5 миллионов записей.
...MS SQL 2000

Цитата:

Сообщение от rpr

Прошла ночь

Что-то странное у вас с производительностью.
В принципе 5млн записей - детский размер. Может все-таки кто-то блокировал InventSum, а изменение таблицы накладывает блокировку схемы. В результате, большую часть времени операция изменения таблицы ждала пока с InventSum будут сняты все блокировки?

В общем, я хочу сказать, что час-два - это еще можно объяснить.
Но "ночь" - это уже что-то ненормальное.

[rpr]

Цитата:

Сообщение от mazzy

Может все-таки кто-то блокировал InventSum, а изменение таблицы накладывает блокировку схемы. В результате, большую часть времени операция изменения таблицы ждала пока с InventSum будут сняты все блокировки?

А как проверить, есть ли блокировки на таблице?

[mazzy]

Цитата:

Сообщение от rpr

А как проверить, есть ли блокировки на таблице?

Например, в enterprise manager, management, activity monitor, Locks by Object

[rpr]

Цитата:

Сообщение от mazzy

Например, в enterprise manager, management, activity monitor, Locks by Object

К сожалению на момент решения проблемы у меня это меню (enterprise manager (SQL 2000), management, current activity) не открывалось - выдавало ошибку, что время ожидания истекло.

Пришлось использовать

USE master
EXEC sp_lock

Вроде бы не было блокировок, но теперь наверняка сказать нельзя. Надо еще одно поле добавить ради эксперимента)

[mazzy]

это первый признак, что сервер был занят по самые помидорки.
в следующий раз используйте команду sp_who2 или sp_who для того, чтобы получить список юзеров

[DocSerzh]

есть бесплатная утилитка - http://sqlblocks.narod.ru/index.html ...

[rpr]

Цитата:

Сообщение от mazzy

Что-то странное у вас с производительностью.
В принципе 5млн записей - детский размер. Может все-таки кто-то блокировал InventSum, а изменение таблицы накладывает блокировку схемы. В результате, большую часть времени операция изменения таблицы ждала пока с InventSum будут сняты все блокировки?

Так все и оказалось. В системе около 20 view, содержащих InventSum, InventDim и InventTrans в различных комбинациях. Они используются во множестве отчетов, которые клиент (пользователь, то бишь) любит запускать и тестировать, а также писать им подобные. Когда такой отчет запущен, синхронизировать таблицы из view, которое он использует, невозможно, а SQL загружается "по самые помидорки". И становится затруднительно программировать на том же приложении.

Вопросы:
1) Такие проблемы с вью - это нормально или нет?
2) Что можно сделать? Пока вижу варианты, которые не очень устраивают (потому что надо убеждать клиента в их необходимости)):
- разграничить разработку отчетов и всего остального по времени / приложениям
- переписать отчеты (много), чтобы не использовать вью

[ice]

Цитата:

...И становится затруднительно программировать на том же приложении...

вы программируете на рабочем приложении? или пользователи играются в разработческом? если второе, то поставьте им отдельное приложение

[sukhanchik]

Цитата:

Сообщение от ice

вы программируете на рабочем приложении? или пользователи играются в разработческом? если второе, то поставьте им отдельное приложение

Я думаю все проще. Бекап рабочей базы периодически разворачивается на разработческую - что очень удобно при отладке - есть все настройки, есть рабочий объемы данных для тестирования производительности и все такое

[ice]

Цитата:

Сообщение от sukhanchik

Я думаю все проще. Бекап рабочей базы периодически разворачивается на разработческую - что очень удобно при отладке - есть все настройки, есть рабочий объемы данных для тестирования производительности и все такое

так надо тестировать на тестовой...