Поведение MS SQL server при длительных запросах. #681131

Есть большой запрос. В нем несколько вложенных полностью повторяющих друг друга (да, можно вытащить во временные таблицы, но это пока отложим). Допустим во время выполнения первого вложенного запроса в базе одни данные, во время другого - другие. Вопрос - что будет в результатах запроса (насколько помню 1С использует грязное чтение)?  Будет ли сервер пытаться актуализировать результаты первого вложенного запроса после изменения данных в базе или это мой бред?

Есть большой запрос. В нем несколько вложенных полностью повторяющих друг друга (да, можно вытащить во временные таблицы, но это пока отложим). Допустим во время выполнения первого вложенного запроса в базе одни данные, во время другого - другие. Вопрос - что будет в результатах запроса (насколько помню 1С использует грязное чтение)?  Будет ли сервер пытаться актуализировать результаты первого вложенного запроса после изменения данных в базе или это мой бред?

Есть большой запрос. В нем несколько вложенных полностью повторяющих друг друга (да, можно вытащить во временные таблицы, но это пока отложим). Допустим во время выполнения первого вложенного запроса в базе одни данные, во время другого - другие. Вопрос - что будет в результатах запроса (насколько помню 1С использует грязное чтение)?  Будет ли сервер пытаться актуализировать результаты первого вложенного запроса после изменения данных в базе или это мой бред?

Есть большой запрос. В нем несколько вложенных полностью повторяющих друг друга (да, можно вытащить во временные таблицы, но это пока отложим). Допустим во время выполнения первого вложенного запроса в базе одни данные, во время другого - другие. Вопрос - что будет в результатах запроса (насколько помню 1С использует грязное чтение)?  Будет ли сервер пытаться актуализировать результаты первого вложенного запроса после изменения данных в базе или это мой бред?

>>насколько помню 1С использует грязное чтение что есть по-вашему "грядное стение от 1С"??

*грязное

Хватит уже клоуничать. Если ты не знаешь этого, не надо показывать свою тупость. Ты её и так показал. Тут уже на усмотрение сервера. По моим наблюдениям, одинаковые запросы с одинаковыми параметрами выполняются один раз

запрос выполняется в транзакции, поэтому запрашиваемые таблицы блокируются на время транзакции, и если в запросе получают из одних таблиц данные - они не меняются во время запроса.

Садись, два. И не вылезай больше, пока матчасть не выучишь.

и так - что, по-вашему, есть "грязное чтение"? На клоунов от 1С реагируйте отдельно.

>>>запрос выполняется в транзакции, поэтому запрашиваемые таблицы блокируются на время транзакции, Почем нынче грибочки то у вас там ?

Это не грибы давно уже....

тютютю, не скатывайтесь в срачь товарищи

Грязное чтение. Идет запись данных в базу в транзакции. Транзакция еще не закрыта. Но запросами эти данные уже читаются. Проверял. Именно так и работает.

как же без этого...мартышки в клетке...банка пауков...дамский коллектив....они просто бледнеют перед страстями уютного коллективчика 1с-ников :-)

Не верю.

Сильно зависит от получившегося плана запроса. Вполне возможно, что будет чтение данных 1 раз.

А если поставить "Для изменения" в запросе?

Мда... что-то подобное подозревал. Просто запрос на Postgre выполняется 20 минут, а на тех же данных в MS SQL server уже больше часа... Буду переписывать на временные таблицы.

Странно.

об этом в ни слова.

Да, для изменения не использую. Там запрос не в проведении документа. Скорость работы не сильно важна.

Вообще, хотя я могу ошибаться, у мс скл по умолчанию рид коммитед, получается 1с сознательно снижает уровень изоляции?

Спорить не буду. Но в проверял.

23+ Правда давно :)

"для изменения" не поможет.

нет. дело в другом

>>Просто запрос на Postgre выполняется 20 минут, а на тех же данных в MS SQL server уже больше часа... блокировки?

Ну если хотите могу и запрос выложить :) Но это для любителей поковыряться в портянках :-D

давайте запрос, и флаги трассировки ms sql server

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

Вообщем два одинаковых вложенных запроса будут выполняться много раз, и данные могут отличаться. Что бы этого избежать, надо использовать "управляемые блокировки", но соответственно никто не сможет с этими таблицами работать

Думай как оптимизировать запрос Тут оптимизации непочатый край

А как еще связать по вхождению?  По условию "Входит" связь не делается :)

>>Грязное чтение. Идет запись данных в базу в транзакции. Транзакция еще не закрыта. Но запросами эти данные уже читаются. это как раз особенности 3хзвеной архитектуры. Это не "грязное" чтение, а запрос на чтение данных опережает завершение транзакции на SQL-сервере, т.к. 1с пользует NOLOCK, игнорирующее все блокировки напрочь. По идее, НачатьТранзакцию в отчете должно согласовываться с 1совым же перепроведением докумнета (движения по которому тоже в транзакции) на уровне 1С-сервера еще, но насколько надежно это работает.. Т.е., получается, ПОЧТИ работает, но далеко не всегда...

ЗаказПокупателя.Проект В ИЕРАРХИИ(Проекты.Ссылка)

В Иерархии в условиях связи использовать нельзя.

только этим действием процентов 5 скорости выйграешь. Вообще обращение через точку в запросе очень тяжелое.

Можно

Знаю :( А что делать? Ладно, попробую сейчас по максимуму использовать физические таблицы. Может что-то изменилось с 8.1, но если так, то это здорово.

Укажи связь, как произвольное выражение и напиши ЗаказПокупателя.Проект В ИЕРАРХИИ(Проекты.Ссылка) Возвращаемое значение булево, для связи хватит - должно работать.

Не понял. "это как раз особенности 3хзвеной архитектуры". В середине 90 было модно писать трехзвенки. И сам грешен был, но такой особенности не замечал.

в иерархии?

Не дает.

Вопрос слишком общий, в чем проблема то?

В :)

Тока хотел написать попробуй "В"

Здесь не совсем чистое "грязное" чтение. Со стороны 1С-сервера есть иммитация блокировки таблиц (НачатьТранзакцию), и он же и должен в первую очередь ослеживать пересечения обращений к данным. Т.е. никакого "грязного" чтения для ИБ на строне 1С-сервера нет. А получается - даже если поставить в транзакции запись (причем только перепроведение документа дает такой эффект) на документ и транзакцию на чтение данных в отчет - это не даст 100% гарантии блокировок. Потому как со ст ороны SQL - да, чистое "грязное" чтение без учета наложенных блокировок. Поэтому и есть очередная шизофрения 1С: - обращение в техподдержку дает ответ "используйте транзакцию" - и они правы, если смотреть со стороны 1Сс-сервера (а все оветы 1С затрагивают всегда и исключительно положение на 1Сс-сервере). Транзакция должна работать. - однако, на SQL в силу непонятной реализации этих "транзакций" на 1С-сервере, происходит именно СПЕЦИАЛЬНО указанное "грязное" чтение. Откуда и расхождения. Т.е. они или могут быть, или могут не быть - при прочих равных.

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

конечно нужно проверять, но такой запрос сама 1с может разбить на части. т.к. нарушена куча правил написания запросов сам оптимизатор плана может понизить уровень изоляции тк для запроса, который выполняется час держать час блокировки не гуд. вест текст не осилил, но если в объединениях используются одинаковые таблицы и используется скл >=2008 этот запрос должен работать вечно если не отключен параллелизм.

, Кому из студентов что не ясно??

А теперь по-русски и с интонацией. Ничего не понял.

я просил не флаги трассировки, а не листинги.

данный вопрос не стоит выеденного яйца. Запрос разбить на части и все вложенные - загнать во временные таблицы. Где возможно - использовать виртуальные. Но по блокировкам это никакого отношения не имеет, разве что - будет другой запрос, будет другой и лпан выполнения этого запроса на SQL. Но таблицы, блокировки и данные останутся прежними.

что непонятно?? по пунктам.

Ююэтот запрос должен работать вечно это почему еще?!

из-за взаимоблокировок. в скл 2000,2005 выдавалась ошибка "intra query parallelism" в скл 2008 запрос выполняется бесконечно долго.

Слова знакомые. Смысл не улавливаю. Напиши проще. 1с читает то то и то то, вредительски меняет так-то и выдает что-то еще.

скажи, где непонятно. В какой строчке.

там все подробно и разжеванно написано ))

>>из-за взаимоблокировок. если вы про деадлоки, то это не совсем "взаимоблокировки". Речь об этом?

> если вы про деадлоки, то это не совсем "взаимоблокировки".

не спугни, я еще не всё узнал про трехзвенку..

ЗЫ: можно сообщение в не скрывать ? А то текст запроса "перекосило" - ничего не видать там теперь.

в скл 2000,2005 - deadlocks в скл версии > 2005  - скорее всего нет. возможно зависит от уровня совместимости.

А так:

ага, так видно.. что вот это ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Проекты КАК Проекты полный пэ...

А я вот не верю. Пруф можно?

Да там много... "пердимоноклей", я, честно говоря, даже вдумываться не стал. Но, для любителей пооптимизировать код, вот запросец, работает 10 минут:

+ Там Понедельник-Воскресенье ресурсы, остальное Измерения. В базе всего 800к записей.

Связь по справочнику Проекты. Но только по условию вхождения элементов в группы.

Грязное чтение (read uncommited) используется только вне транзакций. В транзакциях - в зависимости от типа транзакции (автоматическая/управляемая). В управляемых - read commited. Да, этот уровень не гарантирует актуальность прочитанных данных. Если это критично, то это должны гарантировать правильно наложенные управляемые блокировки. Повторяемость чтения гарантируется в транзакциях с автоматическими блокировками.

а что вы еще можете? компенсируете невежество ржанием.

>>Повторяемость чтения гарантируется в транзакциях с автоматическими блокировками. не гарантируется. Т.к. здесь важна не "повторяемость чтения", а порядок чтения одним пользователем данных и перезаписи этих же данных совсем другого процесса и пользователя.

>>В транзакциях - в зависимости от типа транзакции (автоматическая/управляемая). что за "управляемая транзакция" в 1С?? Если далее по тексту "...Если это критично, то это должны гарантировать правильно наложенные управляемые блокировки."

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

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

Транзакция - в 1С одна, и вид у неё один. А вот режимов управления блокировками - два. Причем если переключать режим в транзакции с "автоматического" на "управляемый" - прокатывает, наоборот, с "управляемого" на "автоматический" - вызывается исключение (сиречь ошибка). И управляемые блокировки - мало того, что нужно полностью переписать всю конфу (все проведения, чтения и т.д. из базы) с учетом управляемых блокировок, так еще это нужно сделать так, чтобы таким образом наложенные блокировки не привели к существенно большим тормозам или вообще к деадлокам.

2) ну тогда да, что я и расписал в ( 79) )) 1) вы тоже не разделяете 1С-архитектуру на три разных малосвязанных звена? ))

Писательский талант проснулся?

кому надо - давно уже прочитали и примеры, и факты. И не спорят. А кому невежество милее - постят всякую ахинею под лозунгом "1С - это круто!" )))

о чем вы?

Про 1С - тут другой талант работает.

Я попытался ответить ТС на его вопросы. Что хотел ты - я не понял. Выговориться, наверное.

восьмерошный так называемый "сервер" работает криво и практически без связи по управлению данными с SQL-сервером (по тем же блокировкам, неустановка хинтов и т.д.)

Так понятно? Хотя сейчас набегут "1С - это круто!" расстаскивать это мое сообщение на цитаты ))) Так как более емкое и "сложное" ими не осилилось ))

Спасибо. Бесценная информация.

пожалуйста. Только непонятно, зачем было писать "Что хотел ты - я не понял." )) Раз и так согласен.

Понимание - это дар.

и все пользователи и покупатели 1С это терпят и платят? :-О Или кто-нибудь подал в суд на разработчиков и у него есть факты достаточные, чтобы обосновать злой умысел или упущенную выгоду? А хинты так, вообще, без необходимости ставить не рекомендуется.

Если лень читать, то вот перевод "Указывает, что заявления может прочитать строки , которые были изменены другими транзакциями , но еще не были зафиксированы ."

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

>>и все пользователи и покупатели 1С это терпят и платят? да. а куда деваться? Игла она и есть игла. >>А хинты так, вообще, без необходимости ставить не рекомендуется ну вот 1С и пошла по пути" а зачем?!", почему и меем в результате все то, что описано здесь, и плюс еще масса "удовольствий" при работе в 1С.

>. когда ж тебя забанят уже? будь моя воля, я бы банил всех неофитов. Чтобы темы не изгаживали своим "1С - это круто!!!" Как сказал - получил бан.

+100500

и что? все уже расписали. А я еще и разжевал.

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

>>аль статейки или книжки, или дока и пофигуратор вы сколько 1С занимаетесь, чтобы спрашивать про "книжки, где все написано про 1С"? )) А все остальное - опыт, форумы, MSDN, снова форумы, и опять опыт...