SQL-Ex blog

Общие знания

Расширенные события были введены в 2008.

Это был отстой. Серьезно. Они совсем не были готовы к использованию. Поверьте мне. Я пытался использовать их, но это было просто нефункционально. 2008R2 не улучшил ситуацию. Кое-кто, в частности, Jonathan Kehayias увидели заложенный в них потенциал, и начали использовать их. В отличие от меня, оставшегося на позициях трассировки.

Затем Майкрософт пофиксили Extended Events. 2012 совершенно изменил ландшафт. Изменения были потрясающими. Я начал использовать их с энтузиазмом.

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

Поколоночное хранение и общие знания

Поколоночные индексы были введены в SQL Server 2012.

Это был отстой.

ОК, это действительно сильно. Они были потрясающими. Однако тот факт, что они были только на чтение, серьезно ограничивало их принятие. Общие знания очень быстро утвердились, так что большинство их нас никогда бы их не использовало. Их было ужасно поддерживать. Да, в определенных проблемных областях (вы знаете эти небольшие проблемные области, называемые "анализом данных") они были полезны. Тем не менее, большинство из нас не выдели выигрыша, а мороки было много.

Затем в SQL Server 2014 были введены обновляемые поколоночные индексы. Мир изменился, но никто этого не заметил. Почему?

Общие знания.

Сформировавшиеся знания утверждали, что поколоночные индексы - это не для вас.

Но это неправда. Теперь, когда мы имеем кластеризованное поколоночное хранения и некластеризованное поколоночное хранение, можно свихнуться. Доступ к вашим данным по большей части идет через аналитические каналы? Замечательно, используйте кластеризованное поколоночное хранение. Но иногда вам требуется поиск закладки. Не проблема, добавьте некластеризованный индекс b-tree к кластеризованному поколоночному индексу. Узнайте больше об индексах поколоночного хранения.

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

Поскольку общие знания уже сформировались.

Это общие знания

Общие знания - это ловушка. Не верите мне?



Каждый знает

• Это общие знания, что ожидаемый срок жизни ваших страниц (Page Life Expectancy) должен быть больше 300, или на сервере есть проблемы.


• Каждый знает, что лучший способ справиться с чрезмерным параллелизмом - это установить MAXDOP = 1 на ваших серверах.


• Ожидания CXPACKET - это абсолютно бесполезная статистика ожиданий, которую следует игнорировать.


• Никогда не пишите запросы с более чем 3-мя или 4-мя соединениями.

Я могу продолжить, но хватит. Каждое из этих утверждений либо полностью ложно или справедливо при серьезных оговорках. Например, ожидания CXPACKET бесполезны... до SQL Server 2016SP1 (или CU - не помню точно). Короче говоря, после него при всех современных версиях SQL Server и Azure SQL Database ожидания CXPACKET являются надежными показателями проблем в вашей системе. Не игнорируйте их.

Тем не менее, все эти «общие знания» постоянно увековечиваются. Я не могу поверить своим глазам, когда вижу утверждение, что трех соединений - это слишком много. Этот миф восходит к SQL Server 6.5, не говоря уже о сегодняшнем дне. Тем не менее, это так.

Почему?

Вы тому причиной.

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

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

Потому что следующая вещь, которую большинство людей делают после того, как они что-то узнают, это повторение. "Босс, нашел решение проблемы. Поставить FAST 1 в каждый запрос, и он будет работать быстрей", или любой другой укоренившийся миф. Затем он добавляется в наши документы "Лучшая практика", встраивается в инструменты мониторинга и повторяется всякий раз при ответе на вопрос джуниор DBA или онлайн.

Заключение

Но я понимаю. Недостаточно времени в ваших дне/неделе/месяце/году, чтобы идти в ногу с технологиями. Я извиняюсь, но вам просто нужно выделить немного времени. Посещайте вашу локальную группу пользователей за счет личного времени. Заходите на SQLSaturday. Читайте блоги доверенных экспертов отрасли, кто находится в курсе изменений технологии. Все, что переоценит "общие знания" в вашей голове.

Делайте это, поскольку иначе вы просто наносите себе вред. Дело не в том, что вы не поспеваете за крутыми юнцами. А потому, что вы игнорируете инструменты, которые улучшат вашу организацию. Расширенные события - это удивительная технология. Поколоночное хранение в корне меняет доступ к данным и игры с настройкой производительности. Выясните, как вы можете его использовать. От этого выиграет и ваша организация, и ваша карьера.