Недостатки MARS (несколько активных результирующих наборов)?


кто-нибудь знает о каких-либо недостатках MARS (несколько активных результирующих наборов)? Кто-нибудь знает какую-либо причину, по которой следует избегать использования Марса, например, случаи, когда курсоры более полезны, чем Марс.

3 69

3 ответа:

есть, по-видимому, по крайней мере два известных (потенциальных) недостатка (из этого (1) блог команды):

  1. очевидно, что это может вызвать потенциальные проблемы для любых устаревших систем, которые не были предназначены для работы против Mars enabled design -"существующий код, оптимизированный для работы в мире, отличном от Марса, может показать небольшое снижение производительности при запуске без изменений с помощью MARS"

  2. "С Марса вы можете отправить несколько пакеты с несколькими инструкциями на сервер. Сервер будет чередовать выполнение таких пакетов, что означает, что если пакеты изменяют состояние сервера с помощью инструкций SET или USE, например, или используют инструкции управления транзакциями TSQL (BEGIN TRAN, COMMIT, ROLLBACK), вы и сервер можете запутаться в том, что является вашим фактическим намерением."

Я еще не пробовал дизайн с поддержкой MARS, но я очень близок к этому в своем текущем проекте. У нас есть небольшая проблема с конкурирующими (а иногда и зависимыми) операциями запроса (например, ленивая загрузка данных конфигурации из той же базы данных, что и активный набор записей).

там больше информации на сайте MSDN (2) здесь

[ (1) http://blogs.msdn.com/sqlnativeclient/archive/2006/09/27/774290.aspx]
[ (2) http://msdn.microsoft.com/en-us/library/ms131686.aspx]

  • это занимает немного больше ресурсов сервера, чем делать одно соединение за один раз.
  • вы должны быть запущены SQL Server 2005 или более поздней версии. Так что это может быть проблемой в legacy (ack!) окружающая среда.

в зависимости от чего? нет никаких реальных недостатков.

Они не поддерживают точки сохранения транзакций. но я не считаю это недостатком.