Microsoft SQL Server *

Эта статья чисто практическая и посвящена моей грустной истории

Готовясь к Zero Touch PROD для RDS (MS SQL), про который нам прожужжали все уши, я сделал презентацию (POC — Proof Of Concept) автоматизации: набора powershell скриптов. После презентации, когда стихли бурные, продолжительные аплодисменты, переходящие в несмолкаемые овации, мне сказали — все это хорошо, но вот только по идеологическим причинам у нас все Jenkins slaves работают под Linux!

Разве так можно? Взять такого теплого, лампового DBA из под Windows и сунуть его в самое пекло powershell под Linux? Разве это не жестоко?


Пришлось погрузиться в эту странную комбинацию технологий. Разумеется, все мои 30+ скриптов перестали работать. К моему удивлению, за один рабочий день мне все удалось исправить. Пишу по горячим следам. Итак, какие подводные камни могут встретиться вам при переносе powershell скриптов из Windows под Linux?

Привет! Посмотрим на новые штуки в DataGrip 2019.1. Напомним, что функциональность DataGrip включена и в другие наши платные IDE, кроме WebStorm.

Жил-был проект на EF 6 с СУБД MSSQL. И появилась необходимость добавить возможность его работы с СУБД PostgreSQL. Проблем здесь мы не ожидали, ведь есть большое количество статей на эту тему, и на форумах можно найти обсуждение похожих задач. Однако, на деле не все оказалось так просто, и в этой статье мы расскажем об этом опыте, о проблемах, с которыми мы столкнулись в ходе интеграции нового провайдера, и про выбранное нами решение.

Недавно с некоторым удивлением узнал, что в одном из департментов огромной фирмы, где я работаю, запрещен запуск SQL profiler в business hours.

На фотографии макрофото глаз стрекозы. Они имеют фасеточное строение и состоят примерно из 30000 шестиугольных фасетов, что позволяет стрекозе смотреть практически на 360 градусов (за исключением направления «прямо назад»). Полезное умение, если ты стрекоза.

Когда в организации «зоопарк» баз данных, а их унификация на горизонте даже не просматривается, нужно прилагать усилия, чтобы успевать управлять и следить за их работой. Посмотрите ещё раз на стрекозу.

В статье расскажем об инструменте мониторинга Foglight for Databases, который объединяет в одной консоли мониторинг SQL Server, Oracle, MySQL, PostgreSQL, DB2, SAP ASE, MongoDB и Cassandra. В нём также есть лёгкий налёт DevOps в части логирования изменений в конфигурации баз данных. Обо всём по порядку. Под катом много скриншотов.

Базы данных можно реализовать с помощью Excel, GSheet или при помощи больших ORM систем. В своей практике бизнес-аналитика я сталкивался с разными решениями. А поскольку в бизнес-анализ я пришёл из финансов и аудита, то каждый раз встречая новую систему задавался вопросами — чем все они отличаются друг от друга и какие задачи решают? Некоторые ответы нашёл. В этой статье будет рассмотрено два основных назначения баз данных:

1 — учёт операций,
2 — анализ данных

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

Крупные производители популярного софта заботятся о своих заказчиках по-разному. Один из способов — создать программу сертификации. Чтобы, когда заказчики в раздумьях блуждают между аппаратными конфигами для конкретного софта, производитель этого софта мог подойти и с уверенностью показать пальцем: «Бери вот это и все будет хорошо».

Такую программу для своего SQL Server разработал Microsoft — SQL Server Fast Track (DWFT). По ней сертифицируются конфигурации хранилищ данных — те, которые соответствуют требованиям рабочей нагрузки и могут быть внедрены с меньшим риском, стоимостью и сложностью. Звучит прекрасно, но интересно все-таки оценить эти критерии на практике. Для этого мы подробно разберем одну из конфигураций, имеющих сертификацию SQL Server Data Warehouse Fast Track.

Люди издревле любят играть в числа. Доказать что отношение длины пирамиды Хеопса к высоте равна… уже не помню чему. Физики тоже не чужды этого, например есть мистическая формула Койде, связывающая массы электрона, мюона и тау частицы. Есть формула для постоянной тонкой структуры – в отличие от формулы Койде кажущаяся очень искусственной. Насколько обоснованы такие формулы? Я провел эксперимент.

И снова привет!

Коллеги, в последний день января мы запускаем курс «MS SQL Server разработчик», в связи с чем у нас прошёл тематический открытый урок. На нём мы поговорили о том, как MS SQL Server выполняет запрос SELECT, обсудили, в каком порядке и что анализируется, а также немного погрузились в чтение плана запроса.

Преподаватель — Кристина Кучерова, архитектор модели данных в Сбербанке России.

Друзья, в конце января у нас стартует новый курс под названием «MS SQL Server разработчик». В преддверии его запуска мы попросили преподавателя курса, Кристину Кучерову, подготовить авторскую статью. Эта статья будет вам полезна, если у вас есть очень популярная таблица на проде с доступом 24/7 и вдруг неожиданно вы поняли, что срочно нужно добавить индекс и ничего не сломать в процессе.

Итак, что же делать? Традиционный способ CREATE INDEX WITH (ONLINE = ON) вам не подходит, потому что, например, вызывает падение системы и сердечный приступ вашего ДБА, все топы пристально следят за response time вашей системы и в случае увеличения оного приходят к вам и вашему ДБА на разговор по поводу завышенных цифр вашей компенсации за труд.

Скрипты и описанные приёмы были использованы на системе с нагрузкой 400К requests per minute, версии SQL Server 2012 и 2016 (Enterprise).

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

Кейс № 1. Маленькая, но очень популярная таблица

Таблица 50 тыс. записей (небольшая), но очень популярная (несколько тысяч обращений в минуту). Вам нужен новый индекс и минимальное время простоя и блокировок на таблице.
В приложении весь доступ к БД только через процедуры.

При ошибке приложение сделает повторную попытку обратится к таблице.

Введение

Всем привет! Это моя первая статья и пишу я ее от лица младшего инженера-разработчика на языке C#. Так что здесь не будет каких-то подробных сведений о SQL, лишь практические сведения и размышления по решению довольно не очевидной задачи, с которой мне пришлось столкнуться, для таких же новичков, как и я сам.

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

Итак, представим, что у вас есть web-сервис и SQL (MS-SQL) база данных с таблицей html-писем, которые ваш сервис рассылает пользователям. Письма хранятся за некоторое количество лет и удалить их нельзя, так как они нужны для сбора статистики и аналитики. Однако, с каждым годом количество писем растет, база разрастается, а места на SQL-сервере все меньше (в нашем случае еще одним фактором было восстановление базы на тестовую площадку, т.к. его время пропорционально росло) и с этим нужно что-то делать. Благо, в нашем случае есть свободный сервер с кучей свободного места (в реальности его может не быть и конечно это временное решение, но это выходит за рамки статьи). Так возникла задача по переносу большой таблицы (и говоря «большой», я имею в виду реально большую таблицу, все что я видел, пока искал похожие решения, было в районе 60-100Гб, в нашем случае таблица весила более 300 Гб).

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

Каждый день мне приходится добавлять место на одном, двух, трех, пяти, а бывает – и десяти database серверах. Почему? Потому что для них характерен естественный рост баз. Серверов сотни, все они виртуалки с дисками на thin provisioning. Если им заранее выдать много места, то будет обязательно какой нибудь “runaway”, типа апгрейда с переливом таблиц, который пожрет все это место, а если не пожрет, то поднадкусает. Как вы знаете, thin provisioning – это путь в одну сторону, если место сожрано, но то его назад не вернуть.

В итоге большинство серверов болтаются где то у границы 90% space used – именно потому, что на границе 90% срабатывает алерт. Как только я даю немного, именно немного места – сервер отправляется в район 80%-85% used, и через месяц другой место надо добавлять снова. И, тем не менее, много сразу давать не буду – слишком много прецедентов с runaways.

Я так часто делал механическую работу по расширению места на дисках, что мне это надоело и я решил это автоматизировать с помощью Jenkins:

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

Как запустить SQL profiler trace, когда проблему надо ловить с 3:00 до 3:30 утра? Делать это можно с помощью трейса на стороне сервера, но это крайне неудобно. Именно не сложно, а неудобно, и всегда лень. Наконец я решился автоматизировать это раз и навсегда. Вот так:

На днях одна из баз данных MS SQL Server перешла в Suspect, в журнале было сообщение об ошибке:

Msg 7105, Level 22, State 9, Line 14
Database ID 6, page (1:386499), slot 0 for LOB data type node does not exist. This is usually caused by transactions that can read uncommitted data on a data page. Run DBCC CHECKTABLE.

Базу перевели в Emergency и попытались выполнить DBCC CHECKDB, но выполнение сразу же прерывалось:

Msg 8921, Level 16, State 1, Line 13
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 7105, Level 22, State 9, Line 13
Database ID 6, page (1:386499), slot 0 for LOB data type node does not exist. This is usually caused by transactions that can read uncommitted data on a data page. Run DBCC CHECKTABLE.

Всем привет! Решил написать эту статью по одной простой причине — не нашел подробной инструкции по настройке удаленного связанного сервера между серверами teradata и ms sql server.

В Сбербанке данные хранятся на разных серверах: oracle, teradata, mssql. Часто (бывает, по несколько раз день) мне и моим коллегам приходится выполнять действия, которые назвать «эффективными» очень трудно: пишешь запрос, экспортируешь данные в файл, импортируешь его на сервер mssql, работаешь. Временные затраты на один запрос — более 3 часов (около 90 млн строк).


«Эффективная» работа

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



Речь пойдет о компании федерального уровня с большим числом филиалов и подфилиалов. Но, как обычно, все началось давным-давно с одного маленького магазина. С течением лет шло достаточно быстрое и стихийное развитие, появлялись филиалы, подразделения и прочие офисы, а ИТ-инфраструктуре не уделялось в те времена должного внимания, и это тоже частое явление. Конечно же, везде использовалась 1С77, без задела на какие-либо репликации и масштабирование, поэтому, сами понимаете, в конце пришли к тому, что был порожден спрут-франкенштейн с примотанными изолентой щупальцами — в каждом филиале автономный мутант, который с центральной базой обменивался в «наколеночном» режиме лишь несколькими справочниками, без которых ну вообще никак было нельзя, а остальное автономно. Какое-то время довольствовались копиями (десятки их!) филиальных баз в центральном офисе, но данные в них отставали на несколько дней.

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

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

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

Статья о том, как решали задачу оптимизации процесса удаления файлов из шардированной системы. Речь пойдет о проекте для совместного доступа и работы с файлами. Система была стартапом лет 8 назад, потом он успешно выстрелил и был несколько раз продан. В проекте 4 разработчика, которые с проектом с самого начала, что очень ценно. Документацию, традиционно, либо не успели написать, либо она не очень актуальна.

Зачем вам это читать и зачем я все это написала? Хочется рассказать о граблях, которые заботливо лежат внутри системы и бьют так, что звездочки сыпятся из глаз.

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

Если вам приходилось иметь дело с кубом, в котором число мер и измерений over9000 и не хватает трех экранов, чтобы это уместить, то, наверняка, приходилось слышать и стоны пользователей, на тему неудобства работы с этим чудовищем. Ведь пользователи чаще всего работают с одними и теми же измерениями, без которых не обходится почти ни одна выборка. Однако из-за особенности экселя, любящего сортировать по алфавиту все элементы, находящиеся в области Поля сводной таблицы, эти наиболее востребованные объекты часто разбросаны по всему списку, вперемешку с остальными (редко используемыми) элементами.


Приходится десять раз скролить список вверх и вниз, пока пытаешься установить фильтр на трёх (Дата, Товар, Клиент) полях. Работать с этим каждый день никаких нервов не хватит.

Решение банальное и не новое — в начале имен измерений добавлять символ или цифру, влияя тем самым на порядок.

Но пользователи — это одна сторона медали, им такой подход удобен. А как же разработчики?
Ведь оно как должно быть: начинаешь писать в формуле имя измерения, а студия подсказки выдает, верно? Вот только в случае с допсимволами все это выглядит в коде, скажем так… не очень. В VS2017 уже сделали поиск по вхождению, а в предыдущих такого не было и приходилось писать Календарь не с буквы К, а с цифры 5, потому что 5 Календарь. Запросы в других программах приходится писать без подсказок и упомнить какая цифра у какого измерения или поля — тот еще квест.



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

Но выход есть.