Microsoft SQL Server *

Можно конечно взять сторонние утилиты, например какой-нибудь опенсорсный ILSpy, сохранить сборку на диск и потом декомпилировать.


Но хочется просто подключиться к БД и посмотреть все сборки и что там внутри.

И к тому же, есть очень много качественных Opensource компонент на все случаи программистской жизни, да и писать на C# удобно и легко :)

Итак.

24 сентября была представлена первая редакция CTP выпуска SQL Server 2019, и, позвольте сказать, что он переполнен всевозможными улучшениями и новыми возможностями (многие из которых можно найти в форме предварительного просмотра в базе данных SQL Azure). У меня была исключительная возможность познакомиться с этим чуть раньше, позволившая мне расширить представление об изменениях, пусть даже поверхностно. Вы можете также ознакомиться с последними публикациями от команды разработчиков SQL Server и обновленной документацией.

Не вдаваясь в подробности, я собираюсь обсудить следующие новые функций ядра: производительность, поиск и устранение неполадок в работе, безопасность, доступность и разработка. На данный момент у меня есть немного больше подробностей, чем у других, и часть из них уже подготовлена к публикациям. Я вернусь к этому разделу, как и к множеству других статей и документации и опубликую их. Спешу сообщить, что это не всеобъемлющий обзор, а только часть функционала, которую я успел «пощупать», вплоть до CTP 2.0. Еще есть много всего, о чем стоит рассказать.

— Видишь SSAS-суслика?
— Нет…
— И я не вижу. А он есть!


(Кадр из к/ф «ДМБ»)

Поддержка относительно новой табличной (табулярной) модели данных, в противовес устоявшейся многомерной OLAP, встроена в целый ряд продуктов компании Microsoft. Начиная с SQL-сервера (SS) и заканчивая Excel. И если с SS всё понятно – в нём содержится отдельный сепаратный продукт SQL Server Analysis Services (SSAS). А как же решена поддержка языка DAX-запросов и прочей табулярной функциональности в Power BI, SharePoint или Excel? Поищем «суслика» на примере Power BI Desktop.

У вас есть база данных MS SQL Server, которую нужно перенести на другой физический комп. Вы уже сделали бэкап и радостно приступаете к восстановлению. Но тут обнаруживается, что на том компе, куда нужно перенести базу, установлена более старая версия MS SQL Server. Stack Overflow уверяет вас, что всё плохо. Но так ли это на самом деле?

В июне мы провели митап по Microsoft SQL Server — докладчики из Яндекс.Денег, «Лаборатории Касперского», AwaraIT и SpbDev поделились с коллегами опытом. А теперь выкладываем видео в общий доступ.

Под каждым видео — таймкоды ключевых мест, но советуем смотреть, слушать и внимать целиком.

Data-driven подписки в SSRS

Юля: Так, кто вчера менял мою процедуру?
Лёша: не я
Максим: не я
— Ребят, может Git заведём ?
Серёжа: давно пора!
прошло 2 недели…

Юля: ребяяят?
— Юль, а ты не коммитила?
Юля: damn нет(…

Вот так всё и началось. Ну а что, каждый символ и каждую строчку коммитить?

А может всё это будет происходить само?) На этом моменте в голову начинают приходить
DDL-триггеры, Temporal table и картина складывается. Решено, будем хранить версии внутри
SQL Server'a !)

Неделю или две назад я увидел сообщение на форуме RabbitMQ Users, о том, как наладить отправку сообщений из SQL Server в RabbitMQ. Поскольку мы плотно с этим работаем в Derivco, я оставил там некоторые предложения, а также сказал, что пишу в блоге о том, как это можно сделать. Часть моего сообщения была не совсем верной — по крайней мере, до этого момента (сорри, Бро, был очень занят).

Потрясающая штука, этот ваш SQL Server. С его помощью очень легко поместить информацию в базу данных. Получить данные из базы с помощью запроса столь же просто. А вот получить только что обновленные или вставленные данные уже немного сложнее. Подумайте о событиях в реальном времени; совершена покупка — кого-то нужно уведомить об этом в тот же момент, как только это произошло. Возможно, кто-то скажет, что такие данные должны выталкиваться не из базы данных, а откуда-то еще. Безусловно, так оно и есть, но довольно часто у нас попросту нет выбора.

Некоторое время назад передо мной была поставлена задача написать процедуру, которая выполняет прореживание котировок рынка Форекс (точнее, данных таймфреймов).

Формулировка задачи: данные поступают на вход с интервалом в 1 секунду в таком формате:

• Название инструмента (код пары USDEUR и пр.),
• Дата и время в формате unix time,
• Open value (цена первой сделки в интервале),
• High value (максимальная цена),
• Low value (минимальная цена),
• Close value (цена последней сделки),
• Volume (громкость, или объём сделки).

Необходимо обеспечить пересчёт и синхронизацию данных в таблицах: 5 сек, 15 сек, 1 мин, 5 мин, 15 мин, и т.д.

Описанный формат хранения данных имеет название OHLC, или OHLCV (Open, High, Low, Close, Volume). Он применяется часто, по нему сразу можно построить график «Японские свечи».


Под катом я описал все варианты, какие смог придумать, как можно прореживать (укрупнять) полученные данные, для анализа, например, зимнего скачка цены биткоина, а по полученным данным вы сразу построите график «Японские свечи» (в MS Excel такой график тоже есть). На картинке выше этот график построен для таймфрейма «1 месяц», для инструмента «bitstampUSD». Белое тело свечи означает рост цены в интервале, чёрное — снижение цены, верхний и нижние фитили означают максимальную и минимальную цены, которые достигались в интервале. Фон — объём сделок. Хорошо видно, что в декабре 2017 цена вплотную приблизилась к отметке 20К.

Решение будет приведено для двух движков БД, для Oracle и MS SQL, что, в некотором роде, даст возможность сравнить их на этой конкретной задаче (обобщать сравнение на другие задачи мы не будем).

Привет! Этот пост о том, что нового в DataGrip 2018.2. C этой версии поддержка баз данных есть в CLion и AppCode. В WebStorm её можно включить, если вы параллельно используете DataGrip.



— Лог всех запросов
— Новый форматер кода
— Запуск хранимых процедур
— Миграция исходников
— План запроса в виде диаграммы
— Редактирование SQL
— Редактор данных
— Улучшения в пользовательском интерфейсе

Привет! Сегодня я выпустил новую версию ThinkingHome.Migrator — инструмента для версионной миграции схемы базы данных под платформу .NET Core.

Пакеты опубликованы в NuGet, написана подробная документация. Вы уже можете пользоваться новеньким мигратором, а я расскажу, как он появился, почему у него номер версии 3.0.0 (хотя это первый релиз) и зачем он нужен, когда есть EF Migrations и FluentMigrator.

Поводом написать эту статью стал весьма достойный обзор Как мы тестировали VMware vSAN... компании КРОК. Обзор-то достойный, но в нем есть фраза, с которой я борюсь уже больше десятка лет. Админы СХД, виртуализаторы и интеграторы раз за разом повторяют: "Задержки в 5 мс — это отличный показатель". Даже цифра в 5 мс десять лет не меняется. Я это слышал вживую от весьма уважаемых админов уже не меньше десятка раз. От менее уважаемых — десятки, а уж сколько раз читал в интернете… Нет, нет, нет. Для OLTP нагрузок 5 мс, особенно так, как их обычно измеряют — это epic fail. Мне приходилось объяснять причины этого уже много раз, на этот раз я решил собрать свои мысли в переиспользуемую форму.

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

Многие знают и используют встроенную функцию ISNULL(X, Y), которая заменяет первый аргумент на второй в случае, если он (первый) NULL. Менее употребима обратная встроенная функция NULLIF(X, Y), которая возвращает NULL, если первый аргумент равен второму. Комбинация этих двух функций позволяет избежать использования конструкций IF-ELSE или CASE-WHEN, что делает код компактнее. Если интересно посмотреть пару примеров — добро пожаловать под кат.

Привет! В этом туториале рассмотрим несколько популярных сценариев.

— Копирование источника данных внутри одного проекта.
— Общий источник данных для разных проектов внутри одной IDE.
— Копирование источника данных в другую IDE, на другой компьютер, в другую галактику.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Error and Transaction Handling in SQL Server. Part One – Jumpstart Error Handling» автора Erland Sommarskog.

1. Введение

Эта статья – первая в серии из трёх статей, посвященных обработке ошибок и транзакций в SQL Server. Её цель – дать вам быстрый старт в теме обработки ошибок, показав базовый пример, который подходит для большей части вашего кода. Эта часть написана в расчете на неопытного читателя, и по этой причине я намеренно умалчиваю о многих деталях. В данный момент задача состоит в том, чтобы рассказать как без упора на почему. Если вы принимаете мои слова на веру, вы можете прочесть только эту часть и отложить остальные две для дальнейших этапов в вашей карьере.

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

Все статьи описывают обработку ошибок и транзакций в SQL Server для версии 2005 и более поздних версий.

tl;dr В этой статье мы рассмотрим случай, когда лучше переместить самый селективный атрибут из префикса составного индекса в суффикс.

А также рассмотрим, что такое pipeline и как с его помощью select-ить данные уже отсортированными.

Давным-давно, в далёкой галактике, пред-предыдущий администратор вашего SQL Server задал в нём linked server, используя специально для этой цели созданный аккаунт со сгенерированным паролем. Теперь вам с этим линком нужно что-то сделать, например перенести его на другой SQL Server; но просто так это не сделать, потому что никто не знает пароля от того аккаунта. Знакомая ситуация?

Хотя MSSQL не хранит пароли для своих аккаунтов, а хранит только их хэши, — с linked server-ами так не получится, потому что для успешной аутентикации перед внешним сервером нужно обладать паролем в открытом виде. Пароли для linked server-ов хранятся в зашифрованном виде в таблице master.sys.syslnklgns:



Но не всё так просто.

Предисловие

Приветствую вновь тебя, уважаемый читатель Хабра!

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

Данная статья является дополнением к статье Исследуем базы данных с помощью T-SQL, а также вкратце рассказывает о созданной базе данных по администрированию SRV и о проектах-утилитах, которые предназначены помочь в работе DBA MS SQL Server.

Предисловие

Довольно часто пользователи, разработчики, администраторы и т д СУБД MS SQL Server встречаются с проблемами производительности БД или СУБД в целом.

В данной статье будут даны общие рекомендации по настройке оптимизации как БД, так и всей СУБД в целом. Также будут даны основные рекомендации по взаимодействию приложения .NET и MS SQL Server. Будут даны примеры решения на большинство из приведенных ниже рекомендаций.

В данной статье не будут рассматриваться оптимизация аппаратных ресурсов, самой ОС и использование разных встроенных фич для СУБД и ОС в целом, т к это заняло бы целую книгу.

Предисловие

Достаточно нередко бывают ситуации, когда транзакция в MS SQL Server бывает забытой тем, кто ее запустил. Самый частый пример этому — запуск скрипта в SSMS, где явно открывается транзакция инструкцией begin tran, затем происходит ошибка, а вот commit или rollback tran не происходит, а инициатор запуска благополучно отошел надолго от этого запроса. В результате с течением времени возникает все больше флуктуации в плане блокировок на запросы, которые запрашивают доступ к заблокированным ресурсам (таблицам, ресурсам сервера (ОЗУ, ЦП, система ввода-вывода).

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

Привет, Хабр! Представляю вам перевод статьи «VLFs — The Forgotten Foe» автора Monica Rathbun.

Сколько из вас проверяет количество файлов виртуального журнала (VLF), которые есть в ваших журналах транзакций?


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