Microsoft 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

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

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

Хотите легкого чтива под новый год? Вот крошечные истории про случаи из моей работы или случаи, свидетелем которых я стал.

Недавно поменял работу, на новом месте столкнулся с нечитабельной структурой базы данных MSSQL, в которой таблицы и поля не имеют понятных названий (префикс + число). Например: таблицы называются Data1078, Data2022, а колонки называются f210, f1521. Подобные структуры часто встречаются в коробочных продуктах.

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