Microsoft SQL Server *

Судя по ряду пояснений здесь, и обсуждению на форумах, компания Embarcadero Technologies, производитель инструментов разработчиков приложений и баз данных (Delphi, InterBase, DBArtisan и др.), была приобретена компанией Idera, специализирующейся на инструментах для баз данных. Сумма сделки, исходя из доступных данных — 425 миллионов долларов.

Интересно вспомнить, что сама Embarcadero Technologies в 2006-2007 годах была приобретена частным фондом инвестиций и снята с листинга (т.е. она была публичной, торговалась на бирже, а стала закрытой, частной компанией), затем (в 2008-2009) Embarcadero приобрела за 20 миллионов долларов инструменты разработчика CodeGear (Delphi, C++Builder, InterBase) у Borland. И вот через 6 лет продажа за 425, т.е. примерно раза в 4 увеличили стоимость.

Хочу рассказать читателям хабра-сообщества как используя CLR библиотеку Microsoft.SqlServer.Types можно формировать тайлы для электронной карты. В статье пойдёт речь о генерации списка картографических тайлов для их дальнейшего рендеринга. Будет описан алгоритм генерации тайлов по геометрии объектов, хранящейся в базе данных MS SQL 2008. Весь процесс рендеринга шаг за шагом будет рассмотрен на примере в конце статьи.

Содержание

---

Проблема
Исходные данные
Решение
Хранилище тайлов
Этапы подготовки тайлов
Используемые функции
Пример с ломаной линией
Проверка пересечения
Таблицы для хранения образов тайлов
Размещение иконки на тайле
Объединение тайлов
Отрисовка геометрии на тайле
Заключение

Я хочу рассказать о рефакторинге схем баз данных MS SQL Server.

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

— Martin Fowler

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

Вероятно, вы знаете, что обслуживание баз данных это целый комплекс процедур: создание бэкапов, проверка целостности, обслуживание индексов, статистики и т.д. На просторах сети (да и на Хабре в том числе) на эту тему написано множество статей и рекомендаций. Однако занимаясь внедрением «1С: Предприятие», нам частенько приходится сталкиваться с тем, что обслуживание баз данных настраивается либо неправильно, либо по очень упрощённой схеме. Например, чтобы не заморачиваться с управлением журналами транзакций, для «боевых» баз устанавливается Простая модель восстановления (Simple Recovery model). И это несмотря на то, что потеря информации за пару часов уже критична для компании. Иногда задача по сжатию файлов БД включается в регулярное обслуживание («шобы не росло»), или после обновления индексов идёт уничтожение статистики и прочие подобные ляпы. Так происходит потому, что чаще всего в компаниях нет опытного администратора БД и обслуживанием приходится заниматься кому-то из сотрудников ИТ-службы – «невольному» администратору баз данных (DBA). При этом такой DBA не всегда осознаёт все риски и возложенную на него ответственность.

Зачастую, когда разработчики сталкиваются с созданием модели данных, тип первичного ключа выбирается «по привычке», и чаще всего это автоинкрементное целочисленное поле. Но в реальности это не всегда является оптимальным решением, так как для некоторых ситуаций более предпочтительным может оказаться GUID. На практике возможны и другие, более редкие, типы ключа, но в данной статье мы их рассматривать не будем.

Я долго созревал, чтобы написать данную статью и выложить свое приложение. Надеюсь вам будет интересно.

О чем данная статья

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

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

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

Кому подойдет данная статья:

• Тем, у кого MS SQL Express и нет возможности запускать с помощью Job задачи
• Тем, кто в ближайшем будущем планирует перейти с MS SQL 2008 на более новую версию и не хочет настраивать зеркалирование БД, а сразу на новой версии настроить AlwaysOn
• Тем, у кого нет средств для поднятия еще резервных серверов и приходится обходиться тем, что есть.
• У кого нет сжатых сроков на время восстановления БД. Главное – это результат
• Кому лень что-то делать
• Просто любопытным людям.

Оглавление:

Теория о резервном копирование

1. Журнал транзакций
2. Разностная копия БД
3. Системные базы данных
4. План бекапирования
5. Общие рекомендации по резервному копированию

Используем приложение

1. Настройка уведомления администратора
2. Дополнительные уведомления для администратора
3. Решение проблем при настройке DatabaseMail
4. Настраиваем резервное копирование с помощью приложения для SQL Standart
5. Настраиваем резервное копирование с помощью приложения для SQL Express
6. Удаление задач из БД
7. Удаление копий БД

Как восстанавливать резервные копии

Возникла задача пометить на удаление документы за 1 год. Эта операция выполняется перед бесследным удалением и включает выставление отметки и удаление движения по регистрам. Пробное удаление штатными средствами одного месяца заняло 4 часа. Это означало, что 12 месяцев удалялись бы 48 часов (2 суток). Забегая вперед, скажу, что прямым доступом к 1С документы удаляются за 30-40 минут. Обращение к MSSQL выполнялось через .Net framework и компонент .Net Bridge.

Определение имен таблиц MSSQL

Структура базы данных 1С весьма запутана и состоит из малозначимых для человека названий. 1С содержит функцию определения структуры хранения по имени объекта. В основу разработки положена эта функция ПолучитьСтруктуруХраненияБазыДанных, которая согласно русскому названию возвращает описание структуры. В этой структуре важны 2 поля Назначение, которое должно быть равно «Основная», и название таблицы ИмяТаблицыХранения.

Данная статья будет про то, как одна дружная команда веб разработчиков, не имея в своём составе опытного SQL разработчика, добавила Check Constraint в таблицу и прошлась по нескольким простым, но не сразу очевидным граблям. Будут разобраны особенности синтаксиса T-SQL, а также нюансы работы ограничений (СONSTRAINT’ов), не зная которые, можно потратить не мало времени на попытки понять, почему что-то работает не так. Так же будет затронута особенность работы SSDT, а именно как генерируется миграционный скрипт, при необходимости добавить или изменить ограничения (CONSTRAINT’ы).

Дабы читатель поскорей понял, стоит читать статью или нет, я сначала рассмотрю абстрактную задачу, по ходу решения которой будут заданы вопросы «А почему так?». Если вы сразу будете знать ответ, то смело бросайте чтение и переходите к следующей статье.

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

Первое с чего стоит начать — проверить ошибку на воспроизводимость.
Попробуем снять копию командой:

BACKUP DATABASE [SDB] TO DISK=N'\\FS1\Backup\sdb_full.bak' WITH COPY_ONLY

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

• Отказоустойчива (обеспечение непрерывной работы системы в случае отказа составных ее составных частей)
• С балансировкой нагрузки и высокой утилизацией ресурсов (при текущем функционировании равномерное распределение нагрузки и использование по возможности всех ресурсов, в том числе зарезервированных под отказ)
• Легко расширяема (масштабируема)

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

Небольшой, но интересный анонс для тех, кто пользуется Azure SQL DB.
1-го июля вышел в публичное тестирование Index Advisor для Azure SQL Database.

Index Advisor – инструмент, доступный всем пользователям Azure SQL DB (V12) для создания non-clustered индексов. Index Advisor (IA) выдаёт список рекомендуемых индексов для вашей базы данных. Помогает их создать, а также автоматически протестировать! Анализируя нагрузку запросов и характер доступа к данным, IA выбирает те индексы, которые, по его мнению, принесут наибольший прирост производительности индивидуально для вашего сценария.

Чаще всего deadlock описывают примерно следующим образом:
Процесс 1 блокирует ресурс А.
Процесс 2 блокирует ресурс Б.
Процесс 1 пытается получить доступ к ресурсу Б.
Процесс 2 пытается получить доступ к ресурсу А.
В итоге один из процессов должен быть прерван, чтобы другой мог продолжить выполнение.
Но это простейший вариант взаимной блокировки, в реальности приходится сталкиваться с более сложными случаями. В этой статье мы расскажем с какими взаимными блокировками в MS SQL нам приходилось встречаться и как мы с ними боремся.

Абстракции? Кому нужны абстракции?
EF наикрутейшая ORM от MS. habrahabr.ru/post/157267 это действительно круто. Разработать такую систему очень затратно по всем направлениям. CodeFirs вещь, знания проектирования БД, да какой там! Не нужны сами знания SQL – и это круто. Но так ли все радужно?
Julie Lerman может много рассказать msdn.microsoft.com/en-us/magazine/ff898427.aspx

Ничего не напоминает?

В предыдущей части были рассмотрены основы уровней изоляции транзакций. Здесь я постараюсь копнуть чуть глубже и рассказать при помощи каких инструментов MS SQL Server реализует уровни изоляции.

Как вы могли видеть в предыдущем разделе, существует два способа поддержания изоляции:

• Основанный на блокировке ресурсов
• Основанный на создании версионной копии ресурсов.

Режимы, основанные на создании копии данных, достаточно просты для понимания и думаю не требуют особого внимания. При желании углубиться в детали их реализации, я могу предложить обратиться к не плохому описанию на MSDN. Я же хочу рассмотреть, как реализован механизм, основанный на блокировках.

Мне часто приходилось сталкиваться с тем, что люди прекрасно понимают, что такое транзакции в базе данных и для чего они нужны, но при этом не всегда умеют ими правильно пользоваться. Безусловно, для достижения 80-го уровня сакрального знания нужно иметь не один год опыта и прочесть множество толстенных книг по SQL. Поэтому в этой статье я даже не буду пытаться описать всё, что может быть связано с транзакциями в MS SQL. Я хочу затронуть один простой, но очень важный вопрос, который разработчики часто упускают из вида – уровни изоляции транзакций.
Несмотря на то, что тема очень проста, во многих источниках она освящается плохо – информации либо очень мало, либо очень много. Т.е. прочитав 5-6 кратких теоретических определений невозможно их применить на практике. Для уверенного понимания предмета статьи нужно обращаться к специализированной литературе, но там информации на столько много, что далеко не каждый может уделить необходимое время для её усваивания.
Сегодня я хочу поделиться своим простым рецептом, который помог мне раз и на всегда запомнить особенности уровней изоляции транзакций и по сей день помогает без проблем принимать взвешенные решения о выборе необходимого уровня.

Пока готовится подробный обзор функционала MS Datazen и Pyramid Analytics, мы решили разместить небольшую статью по решению локальной задачи для SQL Server Reporting Services.

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

«24 Hours of PASS» — это ежегодная онлайн-конференция о MS SQL Server, проводимая по эгидой профессиональной ассоциации PASS, и длящаяся 24 часа. Вот прям буквально 24 часа: докладчики из разных частей света сменяют друг-друга в марафоне вебинаров (конечно же, это отсылка к 24 часам Ле-Мана).

Усилиями Андрея Коршиков, уже несколько лет проводится русскоязычная версия «24 часа PASS». Последняя состоялась в середине марта, и если вы ещё не успели посмотреть все 24 часа видео (кстати, вот плей-лист на YouTube), то именно для вас я и сделал этот обзор.

• SQL Server 2014 In-Memory OLTP — Сергей Олонцев
• Размер имеет значение: 10 способов уменьшить размер БД — Дмитрий Короткевич
• Внутри оптимизатора запросов: Соединения — Дмитрий Пилюгин
• Оптимизация SSAS-кубов — Евгений Полоничко
• Тяп-ляп и в продакшн! — Алексей Ковалёв
• Оффлайн-разработка баз данных и тестирование с SSDT — Андрей Завадский
• Deadlocks 3.0. Final Edition — Денис Резник
• BIML — лучший друг для SSIS-разработчика — Андрей Коршиков
• Power BI Q&A — Константин Хомяков
• Azure Data Factory — облачный ETL — Сергей Лунякин
• Все что вы хотели узнать о Workspace memory — Мария Закурдаева
• Быстрый анализ производительности SQL Server за 1,5 часа — Кирилл Панов
• Внутреннее устройство страниц и экстентов SQL Server — Алексей Князев

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



Содержание

1. MS Excel Power Query
2. MS Power BI
3. Pyramid Analytics
4. Компоненты аналитики MS SQL server (MDS, SSIS, SSAS)
5. Главный инструмент аналитика

Доброго времени суток, уважаемые Хабровчане.

     В качестве краткой предыстории: год назад, придя на новое место работы в качестве руководителя отдела разработки БД (на базе Microsoft SQL Server), я испытал глубочайший шок от увиденного. Крупная компания, сложное веб-приложение, многомиллионные контракты, а разработка ведется на production-БД, баг-репорты поступают и обрабатываются по методике «кто громче крикнет» или «надо сделать прям вчера». Естественно ни о системе контроля версий, continuous integration, процедурах и workflow речи и не шло.

     Сегодня ситуация сильно изменилась (хотя, кого я обманываю — только начинает меняться) и я хотел бы поделиться как техническими, так и процедурными деталями решений, которые мы используем сейчас. Технические детали на 90% касаются непосредственно разработки для Microsoft SQL Server, а вот процедурные изменения у нас коснулись и веб-девелоперов, и инженеров, и аналитиков, и тестеров.

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

     Кому интересны подробности — добро пожаловать под кат.
Warning: очень много текста, описания процедур и процессов (которые, может, никому и не интересны).

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

Однако, как только у нас появляется отдельная система для хранения очереди сообщений (мы используем RabbitMQ), сразу возникают проблемы с транзакционностью. Например, если мы хотим сохранить в БД отметку о том, что мы отправили сообщение в Rabbit, не так уж и просто гарантировать, чтобы отметка была сохранена только в случае успешной отправки сообщения. О том, как мы справлялись с этой проблемой читайте под катом.