Microsoft SQL Server *

Как известно, MSSQL не предоставляет возможность создания/использования перечислений, что зачастую влечет за собой неявный, ненадежный, некрасивый, сложно поддерживаемый код. Можно спорить о том, что в реляционной БД перечисления как таковые места иметь не могут, но множество раз в моей (и не только моей) практике рождались подобные строчки:

select * from Process where ProcessType = 1 /* Suspended */

После перехода на SQL Server с Oracle удивляет многое. Трудно привыкнуть к автоматическим транзакциям – после update не нужно набирать commit (что приятно), зато в случае ошибки не сможешь набрать rollback (что просто кошмарно). Трудно привыкнуть к архитектуре, в которой журнал используется и для отката, и для наката транзакций. Трудно привыкнуть к ситуации «писатель блокирует читателей, читатель блокирует писателей», а когда привыкнешь – ещё труднее отвыкнуть. И совсем не последнее место в рейтинге трудностей играет засилье кластеризованных индексов. По умолчанию первичный ключ таблицы – именно кластеризованный индекс, и поэтому почти у всех таблиц он есть.

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

Июль уже подходит к концу, а на «хабре» до сих пор никто не вспомнил о CTP релизе MSSQL Server 2014.
Релизу будущего года присвоен позывной «Hekaton». Его появление было заявлено еще на конференции PASS 2012 года и тогда это было только название in-memory движка OLTP. Теперь это название целого релиза с встроенной поддержкой и оптимизацией обработки транзакций непосредственно в оперативной памяти.

Исследуя обширные пространства интернета мне пришлось потрудиться над тем как же все таки создать не тяжеловесный код на asp.net c# для обработки так называемых «свиных ушей», которые содержат классическую модель родитель-потомок в базе данных. Сразу оговорюсь база в SQL Server 2008, который уже имеет возможность работы с иерархическими данными в ОТВ (CTE — английский вариант аббревиатуры).

Здравствуйте.

Понадобилось мне использовать для анализа данных OLAP кубы. Эту технологию я активно изучал и использовал в 2001-2002 годах и даже сертифицировался по ней. Но потом долгое время не прикасался к ней. И вот совсем недавно попробовал воспользоваться 2012 SQL Server’ом, но не тут то было: многое и того что появилось в новом сервере оказалось мне совершенно не знакомым.

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

Ролик ознакомительный, возможно, некоторые вещи сделаны неправильно, но пример вполне рабочий. Предполагается, что читатель (зритель) уже знаком с понятиями многомерного куба, измерений, мер и для чего это используется.

Связь многие ко многим и MS SQL Server Analysis Services

Данный пост я хочу посвятить такой, как выяснилось, несложной проблеме, как обработка OLAP-кубом связей многие-ко-многим с помощью MS SQL Server Analysis Services.

Многие знают, что начиная с версии 2005 в SQL Server существует встроенная возможность посылать электронные письма, которую администраторы баз данных часто используют для отправки срочных оповещений, например, при сбое задач, выполняемых по расписанию. Однако лишь немногим известно, что посылать письма в SQL Server можно прямо из SQL-запросов, функций и хранимых процедур. И если вы один раз уже настроили почту в SQL Server, то на отправку письма у вас уйдет всего минута, а целую рассылку можно организовать за 15-20 минут. Называется эта система Database Mail (DBMail), и сегодня я хотел бы поделиться опытом ее использования.

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

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

1. Размер резервной копии

Оценить размер резервной копии можно с помощью хранимой процедуры sp_spaceused

К примеру вот такой запрос:

USE your_database;
GO
EXEC sp_spaceused @updateusage = N'TRUE';
GO

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

Данной статьей хотелось бы показать шаги и предложить некоторые рекомендации в процессе создания BI-решения с использованием практически всего стека BI компании Microsoft. В создании BI-решения будут использованы SQL Server, SQL Service Integration Services, SQL Server Analysis Services.

Для примера мы выбрали разработку нашей компании RetailIQ — BI-систему глубокого анализа чеков розничных продаж, поставок и складских запасов для сети аптек. Для общего понимания контекста темы: все данные выгружаются из учетных систем (1С, М-Аптека и т.д.), верифицируются, складываются в специальную базу данных с последующим построением многомерных OLAP-кубов. Из источников (учетных систем) с помощью ETL мы перекачиваем данные в хранилище, на основе которого строим куб, о котором дальше пойдет речь.

В предыдущих статьях по миграции в «облачный» SQL Server мы рассмотрели различные возможности передачи резервной копии базы в Облако. На всякий случай следует сразу напомнить, что речь идет о IaaS-подходе, т.е. развертывании SQL Server на виртуальной машине Windows Azure. Альтернативный PaaS-подход принципиально отличен, т.к. Windows Azure SQL Database (SQL Azure) не поддерживает функциональности в виде штатных команд T-SQL backup/restore. Также нет возможности отсоединять и присоединять файлы БД (detach/attach). Там следует применять другие методы, такие, как DAC, BCP, SSIS, SQL Azure Sync и т.д. В данной статье мы продолжаем обзор способов, относящихся к IaaS, и, коль скоро в нем нет проблемы сделать/поднять бэкап, основной рабочий момент состоит в том, чтобы оптимально передать резервную копию базы в Облако и обратно. В этом плане он ничем не отличается от загрузки или скачивания любого блоба в/из Azure Storage. Нами были рассмотрены использование Blob Service REST API (http://msdn.microsoft.com/en-us/library/dd135733.aspx), который является очень простым по своей идее, но достаточно кропотливым в реализации, поскольку требует аккуратно сформировать тело PUT-запроса. Упростить процесс позволяет обертка, предоставляемая Azure SDK (http://msdn.microsoft.com/en-us/library/dd179380.aspx), который имеет в своем составе готовые классы, инкапсулирующие подготовительную работу, которую требуется выполнять вручную в случае использования «сырого» REST API. Наконец, мы рассмотрели процесс передачи резервной копии на отдельном vhd-диске, который присоединяется к облачной виртуалке. С выходом Cumulative Update 2 к SQL Server 2012 SP1 этот процесс еще более упростился, т.к. теперь стало возможным создавать резервные копии базы непосредственно в Azure Storage с помощью штатных команд T-SQL и, соответственно, восстанавливаться с них. Вся не относящаяся к функциональности SQL Server служебная работа по передаче резервной копии в Облако встроена внутрь T-SQLных команд. От нас потребуется только иметь учетную запись хранения (Windows Azure Storage Account), которая будет использоваться для промежуточного хранения резервной копии.

Имеется довольно наболевшая для программистов организаций-пользователей MS Project задачка — получение заметок ответственных лиц. Заметки имеют значительную ценность (при правильной постановке задачи управления), потому что без исходной информации проблемы не классифицировать и правильное решение не принять. Их, заметки, конечно, надо выводить в отчеты.

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

Не претендую на оригинальность, однако аналоги данного решения почему-то не нашел, пришлось собирать самому. Кроме того, я не очень глубокий спец по MS SQL, поэтому, буде возникнут дельные комментарии — прошу комментировать.

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

7. Производительность скалярных UDF оставляет желать лучшего

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

Посмотрите этот пост о принудительном использовании параллелизма – в частности, список того, что приводит к генерации «однопоточного» плана выполнения запроса. Скорее всего, использование скалярных UDF (прим. переводчика: а для серверов младше 2008 R2 и не только скалярных) приведёт к тому, что ваш запрос будет выполняться в одном потоке (*грустно вздыхает*).

Доброго дня. Решил что опыт обработки данных AD посредством SQL будет полезен не только мне, тем более внятного мануала на русском я так и не нашел.

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

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

Собственно, вопрос заключается в том как создать «гипотетический» индекс? Просто для того, чтобы проверить действительно ли такой индекс будет полезен при выполнении запроса.

Привет! Это наш первый материал на Хабре. В нем мы собираемся рассказать о нашем опыте миграции сложного портала с применением метода Database Attach. Enjoy!

Немного о том, кому, скорее всего, будет интересно это читать

Решив поделиться своим опытом миграции одного портала, мы ориентировались, прежде всего, на тех, кто не спрашивает «Зачем мигрировать?», не задается вопросом «А может быть сразу на 2013?», а также на тех, кто знает не понаслышке ужасные слова Windows Workflow Foundation, Event Handlers, Jobs, Content Types, Future Receivers, различный Site, List и т.п. термины и думает, как сделать, чтобы это заработало в SharePoint 2010.

Введение

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

Transact SQL великолепный язык, функциональности которого более чем достаточно для решения большинства часто возникающих задач. Однако иногда возникают задачи, которые с его помощью решать долго и/или неудобно. Пожалуй, самым ярким примером является продвинутый парсинг строк, в котором приходится использовать регулярные выражения или просто хитрый и закрученный алгоритм. Начиная с SQL Server 2005, эта проблема решается созданием хранимой процедуры/функции CLR. Но этот подход требует перекомпиляции и развертывания сборки при внесении изменений. А так хочется, не покидая Management Studio, изменять поведение своих процедур.
Естественным образом возникает желание встроить в T-SQL поддержку какого-нибудь скриптового языка, чтобы выполнять код на лету. Благодаря DLR (Dynamic Language Runtime) в .Net Framework 4 у нас появилась такая возможность. Исключительно в силу личных пристрастий автора в качестве такого языка был выбран IronPython.
Под катом пошаговая инструкция и демонстрация результата.

Исторически сложилось так, что MS SSRS выбирался руководством компаний в которых я работал/ю как средство построения корпоративной отчетности. Конечно-же, чаще всего он не выбирался, а доставался в комплекте с MS SQL Server'ом. А так как он уже есть, то его нужно использовать и чаще всего не по назначению, а как придется. Поэтому и приходилось использовать Reporting Services для не совсем тривиальных задач. Под катом несколько вариантов такого применения.

Продолжаем рассматривать полезные советы для начинающих, при создании отчетов в Microsoft Reporting Services.
Начало можно найти здесь: Microsoft Reporting Services советы начинающим.
Заинтересовавшихся, прошу под кат…