Microsoft SQL Server *

По материалам статьи Craig Freedman

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

Недавно мне пришлось объяснять это нашим братьям меньшим на работе, и я решил написать текст, который может пригодиться. В конце вы найдете ссылку на полезный скрипт для MSSQL, а также Postgres и MySQL.

В идеальном мире, если в таблице миллион записей, а разных значений например всего 100K, то на каждое значение приходится по 10 записей. Но что делать, если в список ваших значений затесалось особое значение, например, NULL, пробел или 'n/a'? Для SQL optimizier это головная боль. Для вас тоже.

Картинка иллюстрирует людей со значением 'n/a' в поле SSN

По материалам статьи 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. Применяя этот метод, будьте осторожны и учитывайте возможные риски, связанные с тем, что отсутствие дампов может ввести в заблуждение при оценке состояния сервера. Обязательно согласуйте отключение дампов со всеми заинтересованными сторонами, прежде чем вносить какие-либо изменения.
Конечно, увеличение тайм-аута проверки статуса сервера и тайм-аута проверки работоспособности может быть альтернативным вариантом реакции на череду дампов, но в типичном продуктиве в случае аварии, когда требуется быстрый отклик и быстрая отработка отказа, такой вариант не подходит (нежелательно ждать генерации дампа перед отработкой отказа или длительное создание дампа само может стать причиной отработки отказа).
Ниже показаны несколько флагов трассировки, которые позволяют отключить создание дампа в наиболее часто встречающихся случаях. В других случаях, следует обратиться к документации Майкрософт, которая описывает соответствующие флаги трассировки и поведение сервера после их включения.

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

Всем привет, меня зовут Александр, я работаю в команде СЭД компании ДОМ.РФ.

В этой статье я расскажу, как Always On Availability Groups помогает значительно сократить требуемое технологическое окно за счёт оптимальной процедуры отката со стороны БД, также как подружить СЭД с группами доступности. Во второй части статьи речь пойдет о том, как мы провели дедубликацию файлов в СЭД на уровне БД и сократили объем БД на 8Тб без потери информации, и как нам помогли в этом группы доступности.

О лицензировании MS SQL по подключениям (CAL)

Лицензирование у Майкрософт непростое и многие считают, что в трехзвенной архитектуре могут существенно сэкономить, лицензируя в Microsoft SQL Server только одно подключение сервера приложений, не учитывая подключения клиентов к серверу приложений. Об ошибках, допускаемых при лицензировании по клиентам далее подробнее.

В процессе подготовки инструмента для автоматического определения субъекта РФ по точке (тип данных Point) потребовалась таблица вида "Субъект РФ" - "geography::Object".

Предыстория: есть большой автопарк (>1000 ТС), который отправляет свои координаты на сервер в составе данных "Машина" - "Момент времени UTC" - "geography::Point". На сервере есть вторая таблица определенных событий по транспортному средству в составе данных "Машина" - "Момент времени (местное время)" - "Событие". Две задачи - перевести время во второй таблице из местного в UTC и далее использовать обе таблицы для дальнейшей автоматизации аналитики по событиям ТС в привязке к субъектам РФ.

Поиск в гугле по фразе "geojson субъекты РФ" привел на страницу https://gist.github.com/max107/6571147 - на ней в формате JSON перечислены субъекты и списки точек координат - границ.

Если вы пробежитесь по тексту, то структура этого JSON такая: на верхнем уровне один блок - один субъект. На следующем уровне вниз - блоки с нумерацией от 0 до, кажется, 19. Это означает, что субъект состоит из нескольких областей и каждая из них - это отдельный полигон (многоугольник). В файле нет Крыма, Севастополя. В файле не выделены Москва и СПб. Крым я дорисую сам, а Мск и СПб для моих задач не принципиальны.

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

Скорее всего есть более простые способы решения этой задачи, но, решая её поэтапно, удалось более детально разобраться в структуре объектов, попробовать методы работы с пространственными данными.

Так случилось, что продукт, который мы разрабатываем работает с несколькими реляционными базами данных. Сейчас это MS SQL, Postgres и Oracle. Были запуски под много чем от MySQL до покойного, наверное, Firebird и экзотических Sybase с DB2, но сказ не об этом.

Если с MS SQL и Postgres все более мене понятное-привычное, то с Oracle каждый раз нас ждут какие-то сюрпризы. Проницательный читатель сразу заметит, что "руки у нас кривые" и мы "попросту не умеем его готовить", но если, уважаемому читателю захочется узнать чем varchar (а точнее varchar2) в Богоподобном Oracle отличается от его собратьев, то прошу под кат.

1. Введение

1.1. Для кого эта статья?

1.2. Как вы можете применить эти знания?

1. Процесс создания баз данных станет для вас легче и понятнее.
2. Понимание связей между таблицами поможет вам легче освоить нормализацию, что является очень важным при проектировании базы данных.
3. Разобраться с чужой базой данных будет значительно проще.
4. На собеседовании это будет очень хорошим плюсом.

2. Благодарности

3.1. Как организовываются связи?

3.2. Виды связей

1. Многие ко многим.
2. Один ко многим.
   
   • с обязательной связью;
   • с необязательной связью;
3. Один к одному.
   
   • с обязательной связью;
   • с необязательной связью;

Предисловие

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

В свете указанных обстоятельств Совет Европейского союза разработал специальный нормативно-правовой акт — Закон о цифровой операционной устойчивости (Digital Operational Resilience Act, сокращенно — DORA). Принятый в ноябре 2022 года, данный закон направлен на создание единой правовой основы, способствующей усилению защиты финансовых учреждений и иных операторов рынка от различных видов угроз, связанных с работой информационных и телекоммуникационных технологий (ИКТ).

Четыркина Дарья перевела статью, в которой детально рассмотрели положения Закона о цифровой операционной устойчивости, проанализировали его влияние на архитектуру и эксплуатацию баз данных, а также предложить практические подходы и рекомендации по подготовке организаций к выполнению предъявленных требований.