Microsoft SQL Server *

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

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

Предисловие

Исторически сложилось так, что придя на новое рабочее место, мне было поручено создать несколько отчетов используя Microsoft Reporting Services. До моего прихода, компания, в которой я работаю по сей день, использовала для построения отчетов Sybase DataWindow. Но в момент моего прихода было принято решение о переходе на Reporting Services, таким образом мне выпала честь пройтись этим тернистым путем и набить не одну шишку. В процессе создания отчетов накопилось достаточно много полезных советов новичкам, некоторыми из них хочу сегодня поделиться.

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

Думаю каждому разработчику баз данных (и не только их) приходилось обновлять/добавлять данные в конфигурационных таблицах. Я хочу поделится с Вами как я упростил работу с конфигурационными данными в таблицах с помощью T4.
Проще говоря данной статьей я хочу показать как вот этот SQL скрипт:

SET IDENTITY_INSERT dbo.Config ON
INSERT INTO dbo.Config(ID, ColorId, CategoryId, Name)
VALUES(2, 2, 4, N'Зеленый автобус')
SET IDENTITY_INSERT dbo.Config OFF

INSERT INTO dbo.CarDetail(ConfigID, DetailID, Count)
VALUES(2, 2, 4)
INSERT INTO dbo.CarDetail(ConfigID, DetailID, Count)
VALUES(2, 1, 1)
INSERT INTO dbo.CarDetail(ConfigID, DetailID, Count)
VALUES(2, 3, 3)

превратить в код C#:

var config = new ConfigTable();
config.Color = "Green";
config.Category = "Bus";
config.Name = "Зеленый автобус";
config.Id = 2;

config.Details.Add("Wheel", 4);
config.Details.Add("Engine", 1);
config.Details.Add("Door", 3);

После очередной просьбы рассказать как составить план обслуживания sql-баз используемый 1С: Предприятием, решил поделиться опытом со всеми сразу.
Зачем это надо — если в sql не обслуживать базы данных, то его смысл теряется вовсе. Основной инструмент — индексы и их надо держать в актуальном состоянии. Каких-то догматов я не встретил не в практике, не в нете, не на курсах в самой 1С, а потому делюсь своим опытом.

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

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

Расскажу, как это можно сделать быстро и просто.
Для решения задачи нам необходимы Crystal Reports 2008 и Visual Studio 2010 (можно использовать и более ранние версии продуктов).

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

• Статья на MSDN
• Видео на Techdays
• Статья на Technet

Хабр также не отстаёт – здесь есть хороший пост по отслеживанию изменений в SQL Server.

Однако вопрос о написании актуального и полного руководства по аудиту SQL Server остается открытым (у нас в планах написать такое руководство – наподобие этого и этого).

Пока же в этом посте мы рассмотрим возможности по аудиту SQL Server’a с помощью нашей программы NetWrix SQL Server Change Reporter. Программа выпускается в двух версиях: базовой бесплатной и расширенной коммерческой. Сначала мы рассмотрим, что есть в базовой версии программы, а затем более подробно остановимся на расширенной версии.
Тем более, недавно мы выпустили новую версию нашего решения для аудита изменений SQL Server – NetWrix SQL Server Change Reporter 2.5. В новой версии мы добавили поддержку аудита содержимого баз данных – той функции, которую давно ждали пользователи.
Заинтересованных приглашаем под кат.

SQLServer Integration Services (сокращенно SSIS) формально определяется как набор графических, консольных утилит и программных объектов, которые предназначены для извлечения, преобразования и консолидации данных из разнородных источников (MySQL, Oracle, Hadoop, XML, dbf, Excel, …).
В данной статье я перечислю TOP-10 (с моей точки зрения) полезностей, появившихся в версии 2012.

Примечание переводчика

Данная работа является переводом части работы Chris Anley Advanced SQL Injection In SQL Server Applications. (прямая ссылка для скачивания)
В последующих статьях, при наличии свободного времени, данный перевод будет доведен до конца.

P.S. Перевод будет интересен более в образовательных и исторических целях.

Оригинальное название статьи: Продвинутые SQL-инъекции в приложениях, использующих язык SQL.

Аннотация

В данной статье подробно рассматриваются общие способы «SQL-инъекции», для известной платформы Microsoft Internet Information Server/Active Server Pages/SQL Server. В ней обсуждаются различные варианты использования инъекции SQL в приложениях и объясняются методы проверки данных, а также защита баз данных, в которых могут быть использованы инъекции.

Зайдя сегодня с утра в менеджер пакетов NuGet в Visual Studio, обнаружил, что в cписке обновлений появилась prerelease версия Entity Framework 6. Заинтересовавшись, что же нового нас ждет решил узнать подробнее об этом обновлении. Информации пока не много, но кое-что узнать удалось.

Предыдущий способ переноса резервной копии базы с локального компьютера на виртуальную машину с SQL Server в Облаке использовал Azure Storage, который не является NTFS-видимым. Таким образом, перед восстановлением бэкап базы нужно было скопировать из Azure Storage на виртуальный диск, чтобы установленный на виртуалке SQL Server его увидел. В случае БД значительного объема это ведет к неоправданному расходу пространства в Azure Storage и, как следствие, к дополнительным затратам: сначала бэкап загружается в облачное хранилище, а затем копируется в vhd, который хранится там же. Чтобы избежать этих затрат, в этой статье мы рассмотрим иной способ. Локально будет создан отдельный vhd, на котором будет размещен бэкап базы. Затем vhd будет загружен в Azure Storage и приаттачен в качестве дополнительного диска облачной виртуалки. С него будет произведено восстановление резервной копии.

В предыдущем примере мы тренировались загружать файлы в Azure Storage при помощи REST API и залили туда бэкап базы данных AdventureWorks2012.
Остается скачать его в облачную виртуальную машину и восстановить на установленном в ней SQL Server. В этом плане работа с Azure Storage совершенно симметрична что со стороны on-premise клиента, что со стороны облачной виртуалки — они передают друг другу файлы через Azure Storage. Один туда закачивает, второй считывает.

Теперь, когда мы имеем созданную в Облаке с установленным на нее SQL Server и умеем со стороны клиента с ним соединяться, как с локальным SQL Server, остается наполнить его данными. Предположим, в рамках гибридного сценария часть БД планируется перенести на Azure SQL VM. В этой статье будет рассматриваться сценарий, когда БД обособляется в виде файла (или нескольких файлов) посредством создания ее резервной копии, detach, data-tier application и т.д., файл доставляется на Azure SQL VM и превращается обратно в базу путем восстановления из бэкапа, attach, deploy/import data-tier application и т.д. Первое и последнее действие не вызывают вопросов у DBA. Осталось понять, как лучше доставить отчужденный файл с базой (.bak, .mdf, .bacpac, …) на облачную виртуалку с SQL Server.

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

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

Большинство испорченных файлов, встречающихся нам в работе, относятся к офисным (документы, таблицы, презентации) либо графическим форматам. Также их отличительной чертой является относительно небольшой размер (существенно меньше 10Мб). Связано это с двумя причинами. Во-первых, с огромным количеством пользователей, которые создают и используют файлы этих форматов. Во-вторых, обычно такие мелкие и, как часто считается, не особо важные файлы не попадают в сферу покрытия корпоративного обеспечения сохранности данных. Подобные файлы часто хранятся на переносных хранилищах данных (USB Flash, а иногда и дискеты), что тоже весьма плачевно отражается на их сохранности. При обработке данного класса файлов обычно не возникает проблем связанных с размером входных данных – входной файл при желании можно целиком спроецировать в оперативную память и работать прямо в ней.

Также существенный процент попадающих к нам на восстановление файлов составляют различные базы данных. Размер их обычно колеблется от сотен мегабайт до десятков гигабайт. Обычно такие файлы попадают под действие корпоративных мероприятий по обеспечению сохранности данных, но и это не дает абсолютной гарантии, что данные будут сохранны при тотальном сбое. Большинство этих файлов нецелесообразно или невозможно хранить в памяти. Поэтому при их обработке в оперативной памяти сначала формируется некоторая разметка расположения данных в файле, по которой на следующем шаге восстановления читаются данные, пригодные к восстановлению и формируются выходные данные. В случае потенциально большого объема, занимаемого разметкой файла, а также, если в процессе восстановления надо будет связывать разрозненные куски данных, формирующих один объект (пример – письма в БД хранилища Exchange Server) – используется временная база данных, хранящая разметку.

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

Часто возникает задача восстановить базу по цепочке бэкапов на резервном/тестовом сервере, на котором непосредственный бэкап базы не проводился, отсутствуют записи в msdb, но есть сами бэкапы, снятые с продуктивного сервера. Вариант с восстановлением копии базы msdb может не подойти если должны существовать разные наборы джобов для основного сервера и того, на котором мы планируем восстановление. Если файлов с бэкапами немного, то восстановить логический порядок следования файлов нетрудно, особенно если бэкапы принадлежат логшиппингу. В этом случае все тривиально — в имени файла хранятся и время, и дата (стоит только помнить, что время в именах файлов хранится в UTC). Но что делать, если в бэкапах нет структуры или файлов очень много, и организовать их простым способом не представляется возможным или как можно просто определить начиная с какого файла логшипинга начинать донакатку?

В предыдущем посте мы создали в Azure виртуальную машину из галереи с предустановленной на ней пробной версией SQL Server 2012. К машине можно подключиться через удаленное соединение и выполнять административные задачи, в том числе администрировать SQL Server, т.к. на ней изначально имеются все необходимые компоненты, включая SSMS. С практической стороны наиболее распространенными являются не чисто облачные, а гибридные сценарии, когда данные частью хранятся в Облаке, а частью — в on-premise БД. Для их совместной обработки потребуется «сопрячь» свежесозданный SQL Server в Azure с on-premise SQL Server. Для начала было бы неплохо увидеть SQL Server на облачной виртуалке из локальной SSMS.

blogs.technet.com/b/isv_team/archive/2012/10/08/3524623.aspx

Этот пост для тех, кто сталкивался с проблемой производительности, при расчете медианы в OLAP кубе.
Одним из главных достоинств OLAP технологии является скорость получения результатов при обращении к базе. Расчеты происходят «на лету». Однако с медианой, не все так просто.
Для справки: медиана — вид средней. Это величина, которая находиться в середине ряда значений отсортированного по возрастанию. Например, для ряда значений {1, 2, 5, 6, 9} медианой является 5.

Рассмотрим ситуацию на примере OLAP сервера от Microsoft — SSAS 2008 (SQL Server Analysis Services).

Более развернутый и иллюстрированный вариант статьи Георгия Гаджиева про создание виртуальной машины Windows Server 2008R2 + SQL Server 2012 из галереи образов.

blogs.technet.com/b/isv_team/archive/2012/10/05/3524343.aspx