Именно взаимоблокировки, с соответсвующей записью в логе. Причина, видимо, обычно как раз указанная вами (и приводимая тут самой ms), но, похоже, и они сами в этом не слишком уверены. Так что это не просто "чтобы не скушал много" - это бы лвдно, если ядер с запасом, но это вынужденная мера против внутрипроцессных клинчей со всеми вытекающими.
Не понимаю, про какую цену речь, а на сервере с 24 ядрами и maxdop=12 регулярные дурные блокировки на многопоточных запросах будут возникать регулярно.
UPD: добавлю, что в свежих релизах это так и ниасилено. Все, что MS родили - чуть больше диагностики добавили в 2016sp2 (см. тут п.19). Объяснения примерно такие. И да, не видел буквально ни одной инсталляции без хорошего ограничения maxdop, где бы это не стреляло постоянно.
Этим маринкам и виталикам верить нельзя. Накрайняк переспросить три раза у разных (возможно, будут четыре новых ответа). Ну или эскалировать на следующий уровень, но банки этому отчаянно сопротивляются.
Boolean. Если вы мапнули NUMBER(1) в boolean (проблема 1), то весь PL/SQL с IF flag = 1 THEN перестаёт компилироваться. Это не сложно, но объёмно.
Это как раз делается вообще тривиально, даже без отлова/переписывания таких запросов. Достаточно определить оператор =(int,bool) и при необходимости симметричный <>() - проблема полностью закрыта: все такие сравнения работают с нативной скоростью, т.е. полностью аналогично записи, например, if/where (not) flag, к чему подлежащими функциями и сводятся; они и светятся в explain (и точно так же оптимизируются, соответственно, потому что это оно уже для планировщика и есть).
Это верно, конечно, и очень многое другое верно. Бывшие ораклоиды вздрагивают, вспоминая 600-е ошибки, начиная прямо со всеми нежно любимой communication link failed в ответ вообще на что угодно - абсолютно валидное или просто так, от скуки. Все так. Но я же отвечал на конкретную претензию по хинтам, которая, на мой взгляд, совершенно не обоснована.
ЗЫ т.к. комментировать могу лишь раз в час, сразу отвечу и @Dhwtj: вот эти set'ы и есть та дичь, которую я упомянул. Только это нифига не альтернатива нормальным хинтам, и вообще применимость имеет очень ограниченную - это просто очень, очень далеко от нормальных хинтов. Про pg_hint_plan уже написал в комменте, на который вы отвечаете - совсем не всегда и не везде можно собрать и поставить ее клиентам.
Но ведь и на pg ровно то же самое, вот только хинтов там отродясь нет. И если нельзя поставить что-то неванильное (pg_hint_plan, ага) - только пытаться обмануть pg. Часто это означает, что приходится долго вымучивать всякую дичь. Так что в этом плане и Оракл, и MSSQL - просто дружелюбные милые лапочки.
Никак. pg сразу на ранних этапах планирования заменяет "expr in (1,2,3)" и "expr not in (1,2,3)" на "expr=any(array[1,2,3])" и "expr<>all(array[1,2,3])".
Так что и абзац из статьи, соответственно, не имеет смысла, т.к. это не аналогичная проблема, а ровно та же самая: > аналогичная проблема существует и для выражений вида WHERE x IN (...), WHERE x = ANY(ARRAY[...]), WHERE x <> ALL(ARRAY[...])
Ну если такой цели не было, то естественно, что выполнена именно поставленная цель, и на ее выполнение был затрачен выделенный (очень скромный, кстати) бюджет.
Москва и облась: мегафон только вчера 5G включил, билайн уже несколько месяцев как, но почему-то не всем.
С той частью, где говорится про 8, согласен, но 6 железно без проблем. 16 - нет, конечно, уже железно будут блокироваться.
Именно взаимоблокировки, с соответсвующей записью в логе. Причина, видимо, обычно как раз указанная вами (и приводимая тут самой ms), но, похоже, и они сами в этом не слишком уверены. Так что это не просто "чтобы не скушал много" - это бы лвдно, если ядер с запасом, но это вынужденная мера против внутрипроцессных клинчей со всеми вытекающими.
Не понимаю, про какую цену речь, а на сервере с 24 ядрами и maxdop=12 регулярные дурные блокировки на многопоточных запросах будут возникать регулярно.
UPD: добавлю, что в свежих релизах это так и ниасилено. Все, что MS родили - чуть больше диагностики добавили в 2016sp2 (см. тут п.19). Объяснения примерно такие. И да, не видел буквально ни одной инсталляции без хорошего ограничения maxdop, где бы это не стреляло постоянно.
Так же отвратительно, как и ваша половина ядер.
...и получите постоянные взаимоблокировки внутри одного (!) запроса в подарок. Практический беспроблемный максимум - 6...8, не более.
Сам и поправлюсь: Калининым Тверь называлась, а не Калининградом. Облажамши я. Простите меня, если сможете.
Стартер ветки про область ничего и не писал, а вот упомянутый им Солнечногорск расположен как раз на пути от Москвы к Твери.
Это он Тверь так называет (советское название)
Скорее не верят в вероятность неразумного выбора без принуждения.
Так с гугломаркета стандартно они ставятся, зачем та AppGallery вообще нужна - непонятно.
Тогда придется демонстрировать не "Hello World", а "Превед Медвед".
Этим маринкам и виталикам верить нельзя. Накрайняк переспросить три раза у разных (возможно, будут четыре новых ответа). Ну или эскалировать на следующий уровень, но банки этому отчаянно сопротивляются.
Это как раз делается вообще тривиально, даже без отлова/переписывания таких запросов. Достаточно определить оператор =(int,bool) и при необходимости симметричный <>() - проблема полностью закрыта: все такие сравнения работают с нативной скоростью, т.е. полностью аналогично записи, например, if/where (not) flag, к чему подлежащими функциями и сводятся; они и светятся в explain (и точно так же оптимизируются, соответственно, потому что это оно уже для планировщика и есть).
Это верно, конечно, и очень многое другое верно. Бывшие ораклоиды вздрагивают, вспоминая 600-е ошибки, начиная прямо со всеми нежно любимой communication link failed в ответ вообще на что угодно - абсолютно валидное или просто так, от скуки. Все так. Но я же отвечал на конкретную претензию по хинтам, которая, на мой взгляд, совершенно не обоснована.
ЗЫ т.к. комментировать могу лишь раз в час, сразу отвечу и @Dhwtj: вот эти set'ы и есть та дичь, которую я упомянул. Только это нифига не альтернатива нормальным хинтам, и вообще применимость имеет очень ограниченную - это просто очень, очень далеко от нормальных хинтов. Про pg_hint_plan уже написал в комменте, на который вы отвечаете - совсем не всегда и не везде можно собрать и поставить ее клиентам.
Но ведь и на pg ровно то же самое, вот только хинтов там отродясь нет. И если нельзя поставить что-то неванильное (pg_hint_plan, ага) - только пытаться обмануть pg. Часто это означает, что приходится долго вымучивать всякую дичь. Так что в этом плане и Оракл, и MSSQL - просто дружелюбные милые лапочки.
Никак. pg сразу на ранних этапах планирования заменяет "expr in (1,2,3)" и "expr not in (1,2,3)" на "expr=any(array[1,2,3])" и "expr<>all(array[1,2,3])".
Так что и абзац из статьи, соответственно, не имеет смысла, т.к. это не аналогичная проблема, а ровно та же самая:
> аналогичная проблема существует и для выражений вида
WHERE x IN (...),WHERE x = ANY(ARRAY[...]),WHERE x <> ALL(ARRAY[...])Ну если такой цели не было, то естественно, что выполнена именно поставленная цель, и на ее выполнение был затрачен выделенный (очень скромный, кстати) бюджет.
В mssql - да. В pg это так и не осилили.
Он так давно и называется - ПСБ. Пятое место по активам. Еще и в списке системно значимых.