Система управления реляционными базами данных
По материалам статьи Craig Freedman
В этой статье будет дан краткий обзор трех интересных свойств итераторов, которые влияют на исполнение запроса: использование памяти, отсутствие или наличие блокировок и поддержка динамических курсоров.
По материалам статьи Craig Freedman: The Building Blocks of Query Execution
SQL Server декомпозирует запросы, преобразуя их в набор стандартных блоков-примитивов, которые принято называть операторами или итераторами. Каждый итератор служит для выполнения одной операции, например, просмотр (сканирование), изменение, фильтрация или соединение данных таблиц, а также соединение двух наборов данных. Всего известно несколько дюжин таких примитивных итераторов. Итераторы могут иметь одну или несколько дочерних записей и могут объединяться в деревья, которые принято называть планом исполнения запроса. Любая инструкция SQL выполняется по соответствующему плану запроса. Для одной инструкции на практике может существовать много правильных планов исполнения запроса. Оптимизатор запросов старается найти лучший (например, самым дешевый) план запроса для каждой инструкции.
По материалам статьи Craig Freedman: Semi-join Transformation
В предыдущих статьях я приводил примеры полу-соединений (semi-joins). Вспомним, что полу-соединение возвращает строку из таблицы, если для этой строки есть хотя бы одна совпадающая строка во второй таблице. Вот простой пример:
По материалам статьи из блога Craig Freedman: Parallel Nested Loops Join
SQL Server распараллеливает соединение вложенных циклов (Nested Loops Join), распределяя в случайном порядке строки внешней таблицы по потокам вложенных циклов. В данном случае, речь идёт о строках, которые поступают первыми, и мы их видим вверху, на графическом плане запроса. Например, если на входе соединения вложенных циклов имеется два потока, каждый поток получит приблизительно половину строк. Потоки проходятся по строкам внутренней таблицы соединения (то есть, по строкам, поданным во вторую очередь, мы их видим ниже в плане запроса), точно по такому же алгоритму, как это было бы реализовано в сценарии с последовательной обработкой строк. Таким образом, для каждой обрабатываемой потоком строки внешней таблицы, поток обеспечивает соединение своей внутренней таблицы, используя эту строку в качестве источника коррелированных параметров. Это позволяет потокам работать независимо друг от друга. При этом для внутренней таблицы соединения вложенных циклов SQL Server не добавляет операторы параллелизма и работу с ней не распараллеливает.
Перевод Ирины Наумовой
Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp
По материалам статьи: «Resolving PAGELATCH Contention on Highly Concurrent INSERT Workloads».
Авторы: Thomas Kejser, Lindsey Allen, Arvind Rao и Michael Thomassy
Недавно, мы проводили лабораторные испытания в Microsoft Enterprise Engineering Center, при которых использовалась большая рабочая нагрузка, характерная для OLTP систем. Целью этой лабораторной работы было определить, что случится при увеличении числа процессоров с 64 до 128, при обслуживании Microsoft SQL Server интенсивной рабочей нагрузки (примечание: эта конфигурация была ориентирована на релиз Microsoft SQL Server 2008 R2). Рабочая нагрузка представляла собой хорошо распараллеленные операции вставки, направляемые в несколько больших таблиц.
Рабочая нагрузка масштабировалась до 128 процессорных ядер, но в статистике ожиданий было очень много кратких блокировок PAGELATCH_UP и PAGELATCH_EX. Средняя продолжительность ожидания была десятки миллисекунд, и таких ожиданий было очень много. Такое их количество оказалось для нас неожиданностью, ожидалось, что продолжительность не будет превышать несколько миллисекунд.
В этой технической заметке вначале будет описано, как диагностировать подобную проблему и как для разрешения подобной проблемы использовать секционирование таблиц.
Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp
По материалам технической статьи Майкрософт: A Case Study: Fast and Reliable Backup and Restore of a VLDB over the Network
Статья была опубликована рание на SQL.RU Публикуется повторно ввиду недоступности сайта.
Автор: Томас Грохсер (Thomas H. Grohser)
При содействии: Линдсей Аллен (Lindsey Allen)
Техническая экспертиза статьи: Sanjay Mishra, Lubor Kollar, Stuart Ozer, Thomas Kejser, Juergen Thomas, James Podgorski, Burzin Patel
Перевод: Александр Гладченко, Ирина Наумова
Дата издания: июнь 2009г.
Тематика статьи: SQL Server 2008
Резюме: Размер базы данных непрерывно растёт, темп этого роста, а также её доступность и готовность фиксируется в соглашение о качестве сервиса - SLA. Одновременно с ростом повышается важность быстрого и надежного резервного копирования и планового восстановления в текущем окружении. Этот документ посвящён проблемам проектирования устойчивого резервного копирования и решений по восстановлению очень больших баз данных (VLDB). На реальном примере, в этой статье демонстрируется, как лучше всего использовать резервное копирование и возможности по восстановлению, которыми обладает SQL Server 2008, что должно помочь при создании планов резервного копирования и восстановления VLDB по сети.
По материалам статьи Джо Чанг (Joe Chang): I/O Queue Depth Strategy for Peak Performance (IO Queue Depth Strategy)
Статья была опубликована рание на SQL.RU Публикуется повторно ввиду недоступности сайта.
В большинстве случаев для SQL Server применяются незамысловатые модели управления глубиной очередей ввода-вывода. Ниже представлены основанные на практике рекомендации по оптимизации очереди ввода-вывода, при использовании более развитых моделей дисковых подсистем, SSD - дисков и высокопроизводительных систем хранения.
Автор, наконец, нашёл время для тестирования массива твердотельных дисков (SSD), собирая в массивы от нескольких до 20 устройств, управляемых двумя контроллерами с 4x4 портами Serial Attached SCSI (SAS). Во время предварительных тестов, когда глубина очереди обращения к дискам была очень высокой, он наблюдал большую задержку обращения к дискам, которая во время проведения ряда операций для чтения превышала 100ms и достигала более 400ms для операций записи.
Таким образом, возникают следующие вопросы:
Опубликовано 23 февраля 2022 года
Автор статьи Gianluca Sartori
В этой статье описывается, как отловить все запросы, выполняемые на сервере, и сохранить данные событий xEvents в таблицу SQL Server. Последнее вызывает трудности при использовании стандартных целей для сессии расширенных событиях. В документации рекомендуется использовать два возможных метода для извлечения информации из сеанса:
Недавно столкнулся с проблемой "спама" в MSSQL и чтобы не забыть как решать эту проблему, написал эту статью.
Сегодня SQL используют уже буквально все на свете: и аналитики, и программисты, и тестировщики, и т.д. Отчасти это связано с тем, что базовые возможности этого языка легко освоить.
Однако работая с большим количеством junior-ов, мы раз от раза находим в их решениях одни и те же ошибки. Реально — иногда просто создается ощущение, что они копируют друг у друга код.
Кстати, иногда такая же участь постигает и специалистов более высокого полета.
Сегодня мы решили собрать 7 таких ошибок в одном месте, чтобы как можно меньше людей их совершали.
Начинающие разработчики часто используют курсоры с параметрами по умолчанию. Это продолжается до тех пор, пока кто-нибудь из старших разработчиков или администраторов баз данных не подскажет, что с параметром FAST_FORWARD все будет работать гораздо быстрее. Возможно, вы и сами исследовали этот вопрос и читали пост Аарона Бертрана (Aaron Bertrand) о бенчмарке производительности курсоров с различными параметрами. Признаюсь, в течение многих лет мне было все равно, почему FAST_FORWARD иногда ускорял мои запросы. В названии было слово "FAST", и мне было этого достаточно.
Всем привет.
Я пишу код, временами мне это нравится, а иногда даже получается. Пока по миру не шарахнул карантин я временами выступал на каком-нибудь офлайновом мероприятии, меня слушали, а мне это нравилось. Но вот уже два года как планета погрузилась в карантинный строй; я привык думать, что мои коллеги не люди, а кружочки вписанные в прямоугольник в окне одной из коммерческих звонилок.
А славы и света софитов хочется-то!
Вот заходишь на ютуб и восхищаешься докладами и каналами других разрабов. Видишь эти сотни и тысячи просмотров и постепенно заражаешься идеей, что и сам так можешь.
И я попробовал.
За последние три месяца записал 10 двухчасовых стримов на темы которые разобрал за время своей карьеры. Получалось по-разному, стрим такой формат, где очень много может пойти не так, а я его еще и усложнил для себя лайвкодингом. Временами что-то шло не так, но, если честно, я даже удивлен, что за 20 часов эфира у меня не случилось ничего действительно катастрофического, после чего я бы стал искать кнопку “удалить канал” и гуглить смену фамилии.
Под катом немного об идеях с которыми я делал видео и немного текста про каждую из тем.
В феврале Microsoft выпустила обновления безопасности для закрытия 70 уязвимостей, ни одна из которых не была классифицирована как Критическая, а 1 уязвимость была обнародована публично (0-day). Впервые за 5 лет в выпуске обновлений нет критических уязвимостей.
Помимо стандартного набора затронутых продуктов – Windows, Office, SharePoint, Visual Studio, .NET – обновления этого выпуска также затрагивают Microsoft Teams, PowerBI, SQL Server, Dynamics 365 on-premise и Azure Data Explorer.
Максимальный рейтинг по шкале CVSS среди всех закрытых уязвимостей составил 8.8 из 10 (в среднем на протяжении последнего года этот параметр был 9.6).
В этой статье я расскажу о самых важных моментах февральского вторника обновлений.
Тип varchar(max) часто используется как в обычных, так и во временных таблицах. Да, с ним можно не беспокоиться о длине строк или появления ошибки "Произойдет усечение строковых или двоичных данных" (String or binary data would be truncated).
Но стоит ли использовать varchar(max) повсюду?
Подробнее о varchar(n) вы можете прочитать здесь, а в этой статье мы сравним типы varchar(max) и varchar(n).
В SQL Server используется стоимостной оптимизатор запросов (cost-based optimizer), который ищет оптимальный план в течение времени, выделенного для компиляции запроса. При оптимизации плана учитывается информация о таблицах, участвующих в запросе, существующих индексах, а также статистика распределения данных. Поиск оптимального плана также включает в себя минимизацию количества физических чтений.
Иногда возникает вопрос, почему оптимизатор не учитывает содержимое буферного пула, ведь это, безусловно, может помочь ускорить выполнение запроса. В этой статье разберемся, почему.
Здравствуйте!
Хочу рассказать об кластеризации (группировке) геокоординат на стороне БД. Хотелось бы все это сделать в максимально простом виде, используя школьную математику. На работе появилась задача "отображение тепловой карты пожаров в МО". Пожары представлены виде географических координат. Нужно сгруппировать пожары, которые находятся в определенном радиусе, и на основе этих данных построить тепловую карту.
Развитие происходит по спирали: когда-то люди не умели правильно индексировать, потом (в основном) научились, потом пришли noSQL и все снова забыли знание древних. Что вы будете делать, когда последние из старых DBA отплывут в Валинор?
Снова и снова и сталкиваюсь с полным набором антипаттернов индексирования. Я их перечислю, но! Для каждого антипаттерна есть исключение, когда именно это и стоит делать. Поэтому кликбейтно сформулированное правило верно в 95% случаях, но если вы хотите копнуть глубже, то прочитайте про исключения.
И в конце полезные скрипты для MSSQL, Postgres и MySQL.
Если вы разбираетесь "почему тормозит база" и у вас есть трейс, созданный MS SQL profiler, то что вы делаете первым делом? Правильно, сохраняете его в таблицу, чтобы поразбираться с ним с помощью родного SQL, а не в GUI.
Очень хотелось бы сделать group by TextData, но увы - так не получится из-за разных параметров у процедур и кверей. А выразительных способностей SQL не хватет, чтобы эффективно 'нормализовать' трейс.
Но ведь можно скрестить ежа и ужа, SQL и Python, и решить задачу в несколько строк! Полезные скрипты ниже.
Приветствую, уважаемые хаброжители!
Так как занимаюсь переводом кода с MS SQL в Postgre SQL с начала 2019 года, то решил продолжить сравнение этих двух СУБД.
В прошлой публикации мы рассматривали отличия в быстродействии MS SQL и PostgreSQL для 1C.
Сегодня давайте сравним основные конструкции синтаксиса MS SQL и PostgreSQL для правильного чтения кода, а также для того, чтобы быстро изменить код из MS SQL для PostgreSQL или наоборот.
Начнем рассмотрение с сопоставления типов.
Недавно мне пришлось объяснять это нашим братьям меньшим на работе, и я решил написать текст, который может пригодиться. В конце вы найдете ссылку на полезный скрипт для MSSQL, а также Postgres и MySQL.
В идеальном мире, если в таблице миллион записей, а разных значений например всего 100K, то на каждое значение приходится по 10 записей. Но что делать, если в список ваших значений затесалось особое значение, например, NULL, пробел или 'n/a'? Для SQL optimizier это головная боль. Для вас тоже.
Картинка иллюстрирует людей со значением 'n/a' в поле SSN