softwarerкак именно синхронизируются передача данных клиенту с работой продолжающей гнать данные ХП? Кто и что делает в момент, когда единственный выходной буфер заполнен?
Может Вам просто переслать эту книгу, чем ее цитировать ? Там очень много про внутреннюю жизнь MSSQL.
Оттуда жеSQL Server has two input buffers (read buffers) and one output buffer per client. Double-buffering is needed for the reads because while SQL Server reads a stream of data from the client connection, it must also look for a possible attention. (This allows that "Query That Ate Cleveland" to be canceled directly from the issuer. Although the ability to cancel a request is extremely important, it's relatively unusual among client/server products.) Attentions can be thought of as "out-of-band" data, although they can be sent with network protocols that do not explicitly have an out-of-band channel. The SQL Server development team experimented with double-buffering and asynchronous techniques for the output buffers, but these didn't improve performance substantially. The single network output buffer works nicely. Even though the writes are not posted asynchronously, SQL Server doesn't need to bypass the operating system caching for these as it does for writes to disk.

Because the operating system provides caching of network writes, write operations appear to complete immediately with no significant latency. If, however, several writes are issued to the same client and the client is not currently reading data from the network, the network cache eventually becomes full and the write blocks. This is essentially a throttle. As long as the client application is processing results, SQL Server has a few buffers queued up and ready for the client connection to process. But if the client's queue is already stacked up with results and is not processing them, SQL Server stalls sending them and the network write operation to that connection has to wait. Since the server has only one output buffer per client, data cannot be sent to that client connection until it reads information off the network to free up room for the write to complete. (Writes to other client connections are not held up, however; only those for the laggard client are affected.)

Stalled network writes can also affect locks. For example, if READ COMMITTED isolation is in effect (the default), a share lock can normally be released after SQL Server has completed its scan of that page of data. (Exclusive locks used for changing data must always be held until the end of the transaction to ensure that the changes can be rolled back.) However, if the scan finds more qualifying data and the output buffer is not free, the scan stalls. When the previous network write completes, the output buffer becomes available and the scan resumes. But as I stated earlier, that write won't complete until the client connection "drains" (reads) some data to free up some room in the pipe (the virtual circuit between SQL Server and client connection).

If a client connection delays processing results that are sent to it, concurrency issues can result because locks are held longer than they otherwise would be. A kind of chain reaction occurs: if the client connection has not read several outstanding network packets, further writing of the output buffer at the SQL Server side must wait because the pipe is full. Since the output buffer is not available, the scan for data might also be suspended because no space is available to add qualifying rows. Since the scan is held up, any lock on the data cannot be released. In short, if a client application does not process results in a timely manner, database concurrency can suffer.

The size of the network output buffer can also affect the speed at which the client receives the first result set. As mentioned earlier, the output buffer is sent when the batch, not simply the command, is done, even if the buffer is not full. If two queries exist in the same batch and the first query has only a small amount of data, its results are not sent back to the client until the second query is done or has supplied enough data to fill the output buffer. If both queries are fast, waiting for both queries to finish is not a problem. But suppose the first query is fast and the second is slow. And suppose the first query returns 1000 bytes of data. If the network packet size is 4096 bytes, the first result set must wait in the output buffer for the second query to fill it. The obvious solution here is to either make the first command its own batch or make the network packet size smaller. The first solution is probably best in this case, since it is typically difficult to fine-tune your application to determine the best buffer size for each command. But this doesn't mean that each command should be its own batch. Quite the contrary. In fact, under normal circumstances, grouping multiple commands into a single batch is most efficient and is recommended because it reduces the amount of handshaking that must occur between client and server.

softwarerЭтот фрагмент беседы пошел с фразы о том, что если процедура возвращает ref cursor, этот рекордсет может быть использован как клиентом, так и другой серверной ХП, в то время как в MSSQL придется выбирать - то ли "неявный рекордсет", который может быть принят клиентом, то ли курсор, который можно передать в другую ХП. Вы предложили возвращать временную таблицу, которая доступна и так, и эдак. Я постулировал то, что обсуждаем выше - дополнительные накладные расходы.Если Вы про это ChAпроцедура для возврата данных в вызывающую процедуру или клиенту может быть одна и та же, просто в вызывающей процедуре придется делать возврат рекордсета во временную таблицу или через OPENQUERY, хотя в случае множественных результатов могут быть проблемы.То здесь говорится совсем не то. Речь только о том, что процедура одна, например
. В случае возврата клиенту она просто вызывается как , в этом случае все накладные расходы не больше, чем вызвать с клиента Но если же надо "задержать" результат на сервере, то ему приходится эмулировать поведение клиента. Так как в MSSQL нет массивов, то проще всего сделать это через временную таблицу . При этом излишних расходов немногим больше, чем в предыдущем случае. Ровно настолько, что сервер является собственным клиентом и создает для хранения промежуточных результатов временную таблицу. Вы же почему-то упорно считаете, что это " существенные накладные расходы". И все мои попытки донести, что расходы если и есть, то они не настолько уж значительные, чтобы этим заморачиваться всерьез. Типа, суслик есть, но я его не вижу :)
В конце концов, в некоторых ситуациях, когда вы в процедуре только читаете данные, по примеру выше, то можно использовать табличные функции, которые возвращают рекордсет. Фактически, это view c параметром, и при включении его в другой запрос, он раскрывается для оптимизатора

softwarerя абсолютно уверен, что в ходе эксплуатации ИС оптимальный план одного и того же запроса меняется, и "я лучше знаю" становится тормозом.Говоря Вашими же словами - "может стать", но не обязательно становится. Дальнейшее обсуждение этого нюанса, IMHO, бесперспективно. Давайте закончим его обсуждение на том, что зафиксируем разность наших позиций.

softwarerдля уменьшения пространства решений нужно отвадить оптимизатор от явно неверных решений и дать ему выбирать между "хорошими" и "еще более лучшими". Ну а жестко рубить - это отличный способ потерять оптимальный план и довольствоваться "лучшим из худших".
Кстати, хорошо, что Вы снова вернулись к этой мысли. Мне хотелось бы понять, как можно "отвадить оптимизатор от явно неверных решений". Как пнуть его в нужную сторону, я понимаю, а вот как отвадить - нет, или не понимаю, что именно Вы имеете в виду под "отвадить".
softwarerжестко рубить - это отличный способ потерять оптимальный план и довольствоваться "лучшим из худших".Похоже здесь тоже стоит зафиксировать разность наших позиций. Напомню, я против чересчур навязчивого управление оптимизатором через хинты, но есть ситуации, когда без них его поведение становится нежелательным, как правило, это сложные запросы, а не тривиальное слияние пары-тройки таблиц. И если я не найду других способов вернуть его поведение к более адекватному, то я воспользуюсь хинтами.

softwarerНо программисты, считающие себя умнее оптимизатора, принимают такие решения гораздо чаще. Поэтому я однозначно за "мягкие" решения.По этому вопросу полностью "за", была бы возможность, я строжайше запрещал бы пользоваться хинтами, пока опыт разработчик БД на конкретной платформе меньше года, как минимум.

softwarerНе готов оценить "удобство реализации на клиенте". Мне кажется, в этом случае:

1. Необходима механика уборки мусора
2. Необходимо всюду пихать "and session_id = :my_session_id"
3. Накладные расходы на отношение к временной по сути таблице как к постоянной

Здесь я предполагаю, что механизм длинной транзакции с итоговым rollback-ом неприменим - поправьте, если я ошибаюсь.В случае "псевдовременной":
1. Да, хотя не особо актуально, если добавить идентификатор фильтра.
2. Если доступ через view, то нет, пользователь работает в своей "песочнице".
3. Да, нет, собственно. Вы похоже опять почему-то считаете, что это большие расходы.
4. Длинные транзакции вполне допустимы, с учетом подхода в пункте 2, хотя смысл в длинных транзакциях просто отсутствует.

Yo.!!http://support.microsoft.com/default.aspx?scid=kb;en-us;305977
Блин, он опять вытащил этот старый жупел :( Это уже просто патология какая-то...

softwarer Оттуда жеIf a client connection delays processing results that are sent to it, concurrency issues can result because locks are held longer than they otherwise would be. A kind of chain reaction occurs: if the client connection has not read several outstanding network packets, further writing of the output buffer at the SQL Server side must wait because the pipe is full. Since the output buffer is not available, the scan for data might also be suspended because no space is available to add qualifying rows. Since the scan is held up, any lock on the data cannot be released. In short, if a client application does not process results in a timely manner, database concurrency can suffer.
Ага. Вот этого я ожидал после предыдущего письма. Виноват, гипотеза насчет накопления данных на сервере была вызвана предположением, что уж вышеописанным-то образом делать не станут.

Что ж, так действительно становятся понятнее некоторые странные ранее аргументы трехзвенщиков. Прошу прощения за неверное предположение, не ожидал, что архитекторы MSSQL допустят такую зависимость.Я делаю правильный вывод из Вашей фразы, что накапливают - плохо и не накапливают - тоже плохо ? Что есть тогда хорошо ? Или, лучше, как поступает Oracle ? Можно цитату на аналогичную тему из документации ?

И, кстати, давайте не будем трогать трехзвенщиков в контексте нашего обсуждения ? Это совершенно отдельная и большая тема. И не думаю, что они работают только на платформе MSSQL и только поэтому используют то, что Вы называете "странными аргументами". Так что предлагаю закрыть пока эту нить.

softwarer ChAГоворя Вашими же словами - "может стать", но не обязательно становится. Безусловно, для каждого отдельного запроса - "может стать". Мне следовало выразиться четче, примерно так: из многих "может стать" некоторые наверняка станут.Предлагаю эту нить обсуждения также завершить. Ничего нового для себя мы из нее не выясним.

softwarer ChAМне хотелось бы понять, как можно "отвадить оптимизатор от явно неверных решений". Как пнуть его в нужную сторону, я понимаю, а вот как отвадить - нет, или не понимаю, что именно Вы имеете в виду под "отвадить".в Oracle хватает хинтов со смыслом "вот здесь вот этого не делать".Хотя бы парочку примеров таких запретительных хинтов с кратким пояснением можете привести ? В MSSQL(2000) ничего похожего нет, либо я не в курсе. softwarerнапример, оптимизатор может принимать неверное решение из-за отсутствия информации о количестве строк во временной таблице или в результате табличной функции, и здесь хинт cardinality, не запрещая оптимизатору выбирать оптимальный путь, исправит ситуацию.В Oracle есть временные таблицы и табличные функции ? Или подразумевается MSSQL ? Если второе, то статистика как по временной таблице так и по табличной функции, в общем случае, существует, во втором случае - косвенно, через раскрытие функции оптимизатором до базовых таблиц. Хинт cardinality отсутствует, и не то, чтобы было сильно жаль, но его наличие могло бы быть полезным в определенных случаях.
Таких хинтов, насколько понимаю, в Oracle на порядок больше, чем у MSSQL, что в значительной степени сложилось, как предполагаю, исторически. Когда оптимизатор был еще не очень качественным и требовалось много подсказок, чтобы он либо шел, либо не шел в заданном направлении. Большинство из них наверняка сейчас выглядят анахронизмом, так как оптимизатор и так вполне справляется в большинстве случаев.

softwarer ChAИ если я не найду других способов вернуть его поведение к более адекватному, то я воспользуюсь хинтами.
Напомню, я в данном случае не возражаю против хинтов (хотя конечно по-разному отношусь к разным хинтам и их уместности). Мы вроде бы говорили о жестком разбиении запроса на подзапросы.В некотором смысле это тоже хинт. Более того, я знаю, как в некоторых ситуациях хинтами добиваться использования оптимизатором внутренних временных таблиц. Можно также считать, что это своеобразный хинт "наоборот" о котором Вы поминали в Oracle, я явно говорю оптимизатору, что туда ходить не надо, пусть и таким своеобразным способом. На всякий, еще раз процитирую ChAкоторый вполне может сам использовать внутренние временные таблицы, если найдет это полезным. А если я создаю эти таблицы явно и буду их использовать, то это, в принципе, ничем не отличается от того, что делает сервер.Как следствие, сервер будет терять гораздо меньше времени на построение или перестройку плана в следующий раз. И вызвано это следующим ChAвстречался с запросами, компиляция которых настолько превышает время выполнения, что приходится делать телодвижения, дабы избегать таких несуразностей. В том числе, переписывая запрос, вплоть до разбиения его на последовательность более простых. Разумеется, это не частое явление, но изредка бывает . А если учесть, что запросы все равно время от времени перекомпилируются, например, при изменении табличных статистик, то можно заранее подстраховаться и сделать поведение более предсказуемым.Прошу обратить внимание на подчеркнутую фразу и не считать это постоянной практикой, так же как наличие хинтов не подразумевает их обязательного использования. Но если мы идем определенным путем, то он выбран в здравом уме и твердой памяти, с четким осознанием последствий, о чем упоминается уже не в первый раз. Патологические случаи предлагаю не рассматривать.
Возможно, в Oracle все гораздо лучше и при любых условиях хинты не используются, либо - невероятно редко, а запросы никогда не упрощаются разбиением на подвыборки, какими бы сложными они не были. Ну, тогда остальным придется только завидовать.

softwarer ChA1. Да, хотя не особо актуально, если добавить идентификатор фильтра.
Ээ.. не понял. Либо мы убираем мусор, либо он потихоньку забивает таблицу. Третьего варианта я не вижу.Я, по моему, согласился, что он необходим, разве нет ? Просто отсутствует необходимость сразу же все удалять, а можно отложить этот процесс на окончание текущей или начало следующей сессии, либо время от времени устраивать чистку от "мусора" хоть на основе расписаний, хоть степени активности. В принципе, я лично, за использование временных таблиц в подобной ситуации, но такой подход сложился отчасти по историческим причинам и в принятии решения по этому поводу я, к сожалению, участия не принимал.
Кстати, временные таблицы тоже придется чистить. Либо пересоздавать, причем на самом верхнем уровне, если хотим, чтобы к ним можно было обращаться не из взаимосвязанных по коду процедур. Увы, но временная таблица, созданная в процедуре, "умирает" по окончанию выполнения этой процедуры.

softwarer ChA2. Если доступ через view, то нет, пользователь работает в своей "песочнице".
Признаться, не доводилось слышать, чтобы где-нибудь был реализован параметризованный updateable view.Зачем параметризованные-то ? Естественно, пользователю даны права только на использования VIEW v.

softwarer ChA3. Да, нет, собственно. Вы похоже опять почему-то считаете, что это большие расходы.
Да, я полагаю накладные расходы на работу с временными таблицами меньшими, нежели с постоянными. Данные во временных таблицах не обязаны пережить падение сервера, а следовательно нет потребности постоянно дергать диск. Данные разных сессий не путаются между блоками/страницами, нет необходимости выставлять-поддерживать-проверять блокировки.Вообще говоря, опять же ненамного. Нет необходимости дергать диск, зато активно пользуем ОЗУ, хотя это, в принципе, и не факт, так как в случае большой временной таблицы, чего желательно избегать, при недостатке ОЗУ может быть тот же самый псевдосвоппинг. Если множество изменений делать в единой транзакции, то диск точно так же не будет дергаться, пока мы не озаботимся ее фиксацией.

Если в физическом смысле, то данные разных сессий и так не будут путаться между, если сделать правильный кластерный индекс. На логическом уровне клиенту все равно, он видит и работает только со своими данными.

Блокировки, к сожалению, даже в этом случае используются, хотя и менее активно. Некоторые ставятся практически всегда, типа Schema-stability, другие в определенных случаях, например, потенциальной параллелизации запросов с использованием временных таблицы. Тут ничего более внятного сказать на данный момент не могу, так как этот вопрос меня не особо интересовал. По принципу, если их ставят, значит так нужно и есть разумное объяснение этому поведению. Я не претендую на то, что лучше разработчиков MSSQL знаю, когда их надо применять, а когда нет. Мне пока достаточно понимать, как и зачем я использую свои собственные блокировки.