Microsoft SQL Server *

В феврале 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.

Говорят, что вакцины стали жертвами собственной эффективности. Будто если бы мы видели, как странновато одетый кучер раз в неделю забирал бы трупы нескольких соседей, умерших, как и десятки до них, довольно неприятной смертью, может, и вакцинировались бы охотнее.

Я не ученый вирусолог/эпидемиолог/фармацевт, я зарабатываю себе не хлеб тем, что пишу программы. Иногда мне кажется, что делаю это довольно успешно. Сегодня в очередной раз я услышал фразу, что привел в эпиграфе, а вчера в баре под укоризненные взгляды друзей рассказывал, как я отбился в проекте от использования какой-то нереляционки и у меня в голове щелкнуло и я сел набирать этот текст.

С середины прошлого века мы работаем над реляционными базами данных. И они прекрасны. Но сейчас все чаще любят использовать NoSQL всех видов и мастей. И они иногда неплохо ложатся и затыкают собой какое-то мелкое место в проекте. Если я ценю свои данные и мне нужна какая-то надежность, то мне нужны ACID гарантии. Если это всего лишь кеш, данные из которого нужны чтобы ускорить приложение то я с радостью возьму Redis или аналоги. Ведь если он упадет или данные рассогласуются я смогу их восстановить из нормальной базы.

По материалам статьи Sean Gallardy «Demystifying Dumps: Non-Yielding Scheduler

23 августа 2021 г

Одним из наиболее распространенных случаев, приводящих к генерации дампа памяти в SQL Server, является «ступор» при выполнении задачи на планировщике: non-yielding scheduler (для краткости называемый NYS). Что же это значит? Почему он вызывает дамп памяти? Где можно найти что-нибудь, что можно исследовать для поиска источника ступора? Хорошие вопросы, давайте на них ответим.

На очереди SQL-секция конференции ЮMoneyDay, и она очень мощная, потому что уже проверена осенним митапом про базы данных. Даже если были на нём — в докладах много нового.

Начнём с антифрода: как мы онлайн и офлайн обрабатываем транзакции, храним данные на Microsoft SQL Server и используем движок Business Rule Engine. Далее поделимся, зачем мы взялись за управление метаданными и почему продолжаем развивать это направление.

Заглядывайте под кат!

По материалам статьи Esther Xin «Prevent SQL Server Dump Generation in Hot Cases: Common Ways & Scenarios»
14 ноября 2021г.
В этой статье будут описаны способы предотвращения создания дампа SQL Server для наиболее часто встречающихся видов исключений. В промышленной среде это позволит продержаться до решения проблемы, в случае, когда генерация дампов сильно мешает нормальной работе. Подразумевается, что у вас уже есть файл дампа, пригодный для расследования RCA. Также, вы должны быть уверены, что причиной создания дампов является одно и то же исключение, о чём говорит одинаковый стек вызовов для потока, приведшего к дампу.

В продуктиве, особенно когда SQL Server является частью кластера (SQL AG или FCI), в качестве быстрого решения для защиты от сбоев, вызванных процессом генерации дампа, поддержка Майкрософт может предложить рассмотреть возможность отключения процесса создания дампа.
Главной опасностью того, что файл дампа не будет генерироваться после того, как произойдёт исключение, является невозможность дальнейшего поиска и устранения проблем на основании содержащейся в дампе информации. Кроме того, само отключение возможности создания дампа не может избавить от возникновения исключения в процессе SQL Server. Применяя этот метод, будьте осторожны и учитывайте возможные риски, связанные с тем, что отсутствие дампов может ввести в заблуждение при оценке состояния сервера. Обязательно согласуйте отключение дампов со всеми заинтересованными сторонами, прежде чем вносить какие-либо изменения.
Конечно, увеличение тайм-аута проверки статуса сервера и тайм-аута проверки работоспособности может быть альтернативным вариантом реакции на череду дампов, но в типичном продуктиве в случае аварии, когда требуется быстрый отклик и быстрая отработка отказа, такой вариант не подходит (нежелательно ждать генерации дампа перед отработкой отказа или длительное создание дампа само может стать причиной отработки отказа).
Ниже показаны несколько флагов трассировки, которые позволяют отключить создание дампа в наиболее часто встречающихся случаях. В других случаях, следует обратиться к документации Майкрософт, которая описывает соответствующие флаги трассировки и поведение сервера после их включения.

Автоматизация приема приглашений к обмену документами в кабинете ЭДО

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

Понедельник, 9 утра, сообщение в рабочем чате: "Всё сломалось, почините". Согласитесь, неприятная ситуация, особенно когда это ваш первый месяц работы, а сломалось что-то в функционале, с которым вы ещё ни разу не контактировали, да и не трогал его уже никто месяцами.

По материалам статьи Craig Freedman: Query Failure with Read Uncommitted

Опубликовано 23 марта 2019 г., впервые опубликовано в MSDN 12 июня 2007 г.

В предыдущих статьях были рассмотрены практически все уровни изоляции, за исключением Read Uncommitted или NOLOCK. Эта статья завершает серию обсуждением того, что может приключиться, если читать данные ещё не зафиксированных транзакций. О вреде NOLOCK написано уже немало. Например, вы могли об этом почитать у Любора Коллара (Lubor Kollar) из «SQL Server Development Customer Advisory Team» и в (ныне уже недоступном) блоге Тони Роджерсона (Tony Rogerson).

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