Microsoft SQL Server *

В первой части мы кратко рассмотрели основные возможности SQL Server по in-memory обработке применительно к аналитическим и транзакционным и приложениям, сконцентрировавшись на последних, поскольку in-memory OLTP (Hekaton) является наиболее существенным нововведением в SQL Server 2014. В данной статье мы продолжим обзор функциональности Гекатона на примере ранее созданной БД.

Функциональность In-Memory OLTP (проект Hekaton) призвана ускорить обработку типовых OLTP-операций в SQL Server. Как известно, нагрузку, приходящуюся на сервер баз данных, будь то Microsoft SQL Server или Oracle/MySQL или SAP/Sybase или IBM DB2 и т.д., можно условно разбить на два класса: сбор данных и анализ того, что собрали, потому что зачем в противном случае было собирать? Первый класс задач называется OLTP (On-Line Transactional Processing). Для него характерны короткие обновляющие транзакции, затрагивающие относительно небольшое число таблиц в базе. Примеры таких приложений — операционный день в банке, биллинг в телекоме и т.д. Второй класс задач называется OLAP (On-Line Analytical Processing) и характеризуется массивным длительным чтением, охватывающим значительное количество таблиц и собирающим из них, как правило, по максимуму записей, изобилующим предикатами связывания, сортировки, группирования, агрегатными функциями и т.д. Как правило, структуры данных для разных классов задач разделяют, чтобы не мешали друг другу, и если первая структура базы строится с учетом многочисленных правил Кодда, то вторая, напротив, денормализована и выполняется по схеме «звезда (снежинка)».
Устремление СУБД в память проявилось в начале нового тысячелетия, когда выяснилось, что несмотря на закон Мура тактовая частота и быстродействие процессоров растут отнюдь не по экспоненте, а наоборот, выходят на плоскую прямую насыщения невзирая на ILP и прочие ухищрения. В то же время цены на оперативную память, когда-то неприлично дорогую, катастрофически снижаются и по сравнению с 90-ми упали в тысячи раз. Ага, сказали себе производители серверов баз данных. В 2005-м Oracle прикупил in-memory СУБД TimesTen, IBM в 2007-м — компанию Solid, а в Microsoft в данном случае ничего со стороны брать не стали, потому что решили воспитать в своем коллективе.

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

Задача, которая стоит перед нами, – обеспечить бесперебойную работу и высокую доступность базы данных в клиент-серверном варианте развертывания.
Тип конфигурации — active/passive.

P.S. Вопросы резервирования узлов не относящихся к MSSQL не рассмотрены.

В этой статье я хотел бы поделиться своим первым профессиональным опытом применения Master Data Services (MDS) в MS SQL Server 2012. До недавнего времени я был знаком с этим продуктом, входящим в состав MS SQL Server 2012 (Business Intelligence and Enterprise editions), только в теории и ждал удачного случая, чтобы проверить его на практике, и вот такой случай представился.

В обязанности администратора баз данных входит много разных задач, которые, в основном, направлены на поддержку работоспособности и целостности базы данных. И если целостность данных можно проверить через команду CHECKDB, то с поиском невалидных объектов в схеме не все так гладко.

Если проводить аналогии с Oracle, то в SQL Server нельзя так же легко получить список невалидных объектов:

SELECT owner, object_type, object_name
FROM all_objects
WHERE status = 'INVALID'

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

Сегодня 24 апреля в 10:00 по московскому времени приглашаем вас подключиться к онлайн трансляции ключевого события года в мире серверных и облачный решений – конференции Data Platform Day.



В рамках глобальной стратегии развития Microsoft Cloud OS** Вам будет представлена универсальная платформа SQL Server 2014, устанавливающая новые стандарты в области хранения и управления данными любого типа и объема.

Ведущие эксперты Microsoft и компаний-партнеров продемонстрируют:

• новейшие технологии, обеспечивающие работу критически важных приложений;
• современные решения по сбору, анализу и виртуализации данных, в том числе по работе с Большими Данными (Big Data);
• новые возможности по построению гибридных ИТ-систем.

Подключиться к онлайн-трансляции

Доброго дня,
Перед разработчиком часто возникает задача провести тест базы данных на больших объемах данных, но откуда взять эти самые данные? Ведь всем известно, что структура базы может достигать over 50 таблиц, которые не очень хочется заполнять руками. А если подумать о внешних ключах и составных первичных ключах значения которых связаны с другими таблицами, то голова начинает нагреваться пропорционально старому AMD с отключенным охлаждением.
В интернете существует много решений заполнения базы данный случайными значениями с использованием средств .NET, C++, Java и.д. В данной статье будет освещена тема заполнения базы данных случайными значениями средствами T-SQL под управлением MS SQL Server.

Прочитать в SQL Server табличку из Excel… В самом деле, что может быть проще? Для этого существует масса возможностей. Есть инструмент Integration Services, который бывшие DTS, есть мастер импорта/экспорта, который «за сценой» то же самое, можно по-быстрому сваять собственное ADO.NET-приложение, наконец, если неохота стрелять из пушек по воробьям, можно воспользоваться механизмом прилинкованных серверов, известным, как DTS, еще со времен семерки, который позволяет легко и элегантно увидеть теоретически любой ODBC/OLE DB-достижимый источник в виде таблицы (совокупности таблиц) или результата непосредственного (ad hoc) запроса. Так было до тех пор, пока 64-битная архитектура не перестала быть чем-то из области hi end и пришла на ноутбуки разработчиков и пользователей. Обычный пользователь, наверное, все-таки вряд ли будет ставить себе сервер баз данных, но для разработчика отнюдь не экзотична ситуация, когда на одной х64-машине уживаются 64-битный SQL Server с 32-битным MS Office. В этом случае создание прилинкованного сервера на Excel или Access вызывает проблему, потому что драйвера для них, понятно, 32-битные, которые SQL Server, будучи 64-битным, не понимает. Нет у него в списке известных ему провайдеров ничего похожего, хотя офис со всеми прибамбасами, включая connectivity, на компе стоит.


Рис.1

Соответственно, попытка использовать прилинкованный сервер на Excel, как описано в документации, приводит к ошибке Msg 7302, Level 16, State 1, Line 1
Cannot create an instance of OLE DB provider «Microsoft.ACE.OLEDB.12.0» for linked server…
Возникает извечный вопрос «что делать»?

Сегодня стала доступна новая версия Microsoft SQL Server.

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



Чуть подробнее. Есть некий сервер, назовем его server-sql-001, на котором крутятся базы данных CRM и ERP компании. И есть еще сервер, назовем его server-sql-1c, на котором крутятся БД 1С. Server-sql-001 – это новый брендовый сервер, с современными характеристиками и т.д. А server-sql-1c – это довольно средний по современным меркам сервер. И вот, вся бухгалтерия жаждет переехать на server-sql-001, дабы наступило им счастье, увеличилась производительность и скорость работы отличной желтой программы. Вот и встала задача проверить, а правда ли наступит всем счастье? Или же после переезда пострадает производительность и CRM и ERP и 1С? Вот один из примеров, по которым нам необходимо собрать и проанализировать статистику.

Да, можно средствами системного монитора собрать всю необходимую статистику в excel-файл, затем построить графики и т.д. Но что если сбор статистики продолжает неделю, месяц? А еще с интервалом 10 секунд? Удобно будет работать с таким файлом? Ну смотрите сами.

Речь пойдет о методах получения результатов работы процедуры в виде таблиц для последующей работы с ними в SQL. Думаю, большинство здесь изложенного может пригодиться только в приложениях со сложной SQL логикой и объемными процедурами. Не берусь утверждать, что данные методы самые эффективные. Это всего лишь то, что я использую в своей работе. Всё это работает под Microsoft SQL Server 2008.
Тем, кто знаком с темой предлагаю пролистать пост до пятого метода.

Как правило, в публичном Облаке хранится обезличенная информация, а персонализируюшая часть — в частном. В связи с чем возникает вопрос — как скомбинировать обе части, чтобы по запросу пользователя выдать единый результат? Предположим, имеется таблица клиентов, поделенная вертикально. Обезличенные колонки отнесены в таблицу, расположенную в Windows Azure SQL Database, а колонки с чувствительной информацией (напр., ФИО) остались в локальном SQL Server. Нужно связать обе таблицы по ключу CustomerID. Поскольку они лежат в разных базах на разных серверах, использование SQL-оператора с JOIN не проходит. В качестве возможного решения мы рассмотрели в предыдущем материале сценарий, при котором связывание происходило на локальном SQL Server. Он выступал в качестве своеобразной точки входа для приложений, и облачный SQL Server был заведен на нем как прилинкованный. В этом материале мы рассмотрим случай, когда и локальный, и облачный серверы с точки зрения приложения равноправны, а объединение данных происходит непосредственно в нем, т.е. на уровне бизнес-логики.

Не так давно мы анонсировали бесплатную утилиту SQL Dynamite для поиска по метаинформации в базах данных. Хотим поблагодарить всех за хорошие отызвы, критику, найденные ошибки.
Для вас мы выпустили обновление, исправили найденные ошибки, и добавили поддержку SQLite и Informix.

Новая версия доступна здесь.

В прошлой статье мы обещали рассмотреть вопросы доступа к метаинформации БД. Сегодня поговорим про MS SQL и Sybase.

Процесс поиска и анализа связей различных объектов в СУБД Microsoft SQL Server, Sybase Adaptive Server Enterprise, Sybase Anywhere и SQL Azure прежде всего заключается в работе с метаданными.

Проблема в том что Sybase ASE и MSSQL, изначально имея одинаковую структуру метаданных, прошли долгий путь развития независимо друг от друга. Sybase Anywhere изначально была Watcom SQL и имела кучу отличий от Sybase ASE, а SQL Azure – это вообще облачная СУБД. Тем не менее, структура метаданных в них во многом схожа, в частности имеют одинаковые названия таблицы, содержащие ключевую информацию об объектах (sysobjects, syscomments и syscolumns).

Сколько раз вы испытывали проблемы с производительностью SQL Server'а и решали, куда именно смотреть?

Одна из самых редко используемых методологий устранения проблем с производительностью SQL Server'а называется «Ожидания и очереди» (также известная как «статистика ожиданий»). Основная предпосылка методологии состоит в том, что SQL Server постоянно отслеживает, какие потоки выполнения должны ждать. Вы можете запросить у SQL Server'а эту информацию для того чтобы сократить перечень возможных причин проблем с производительностью. «Ожидания» — это то, что отслеживает SQL Server. «Очереди» — это ресурсы, доступ к которым ожидают потоки. Система обычно фиксирует огромное количество ожиданий, и все они означают ожидание доступа к различным ресурсам. Для примера, ожидание PAGEIOLATCH_EX означает, что поток ожидает чтения страницы данных с диска в буферный пул. Ожидание LCK_M_X означает, что поток ожидает возможности наложить эксклюзивную блокировку на что-то.

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

Использование uuid в качестве первичного ключа для таблиц имеет множество преимуществ, одним из которых является возможность получать идентификаторы для создаваемых в клиентском приложении объектов самостоятельно, без обращения к серверу баз данных. Но использование uuid в качестве первичного ключа имеет и недостаток: guid-ы, сгенерированные клиентским приложением, могут быть недостаточно “дружелюбны” к SQL серверу, что в свою очередь может привести к оверхеду при добавлении новой записи. Возможное удорожание операции insert вытекает из того, что SQL сервер для хранения таблиц, по которым задан первичный ключ, обычно использует структуры известные как b-деревья. При добавлении новой записи в таблицу, SQL сервер, в соответствии с сортировкой по первичному ключу, ищет лист, на котором должна быть размещена вставляемая запись. Учитывая псевдослучайный алгоритм генерации uuid, сортировочный порядок новой записи также случаен и возможна ситуация, что лист, на котором должна быть размещена запись, полностью заполнен. В подобных случаях SQL серверу приходится разделять лист надвое и перестраивать ветви b-дерева, ведущие к этому листу. Чтобы не сталкивать SQL сервер с необходимостью постоянно перестраивать кластерный индекс при добавлении новых записей, можно вести генерацию значений первичного ключа в нарастающей последовательности. Один из вариантов генерации Guid в нарастающем порядке — это привязывать сортировочный порядок сгенерированного Guid к текущему времени. Сгенерированные подобным образом идентификаторы часто называют CombGuid, намекая на то, что строятся они из двух половинок — псевдослучайной части, как у обычных Guid, и строки, привязанной ко времени.

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

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

Как правило, это происходит из-за плохо спроектированной схемы – изначально не рассчитанной на оперирование большими объемами данных.

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

В этой статье я бы хотел описать основные этапы построение системы аналитической отчетности средствами MS SQL Server 2008 R2 в организации, использующей OLTP системы учета на платформе 1С. В статье описан мой первый опыт построения решений Business Intelligence.

Здравствуйте, уважаемые читатели. В данном посте речь пойдет о плагине ssmsboost для SQL Server Management Studio. Быстрый доступ к процедурам, функциям и их коду, работа с сессиями, форматирование и генерация кода для данных, а также другие плюшки плагина в посте.

На этот раз мы поговорим еще об одном улучшении, которое SQL Server 2014 предоставляет в плане создания резервных копий, а именно — о возможности их полноценного шифрования. Возможность защитить резервную копию паролем, чтобы с нее не могли восстановиться неположенные люди, существовала с незапамятных времен, и те, кто достаточно долго имеет дело с SQL Server, должны помнить опцию WITH PASSWORD для команды BACKUP. Однако этот способ не обеспечивал стойкую защиту, и, как отмечалось на mssqltips, Although this does add a level of security if someone really wants to crack the passwords they will find a way, so look for additional ways to secure your data. На практике для защиты резервных копий применялось появившееся в SQL Server 2008 TDE, т.е. база данных прозрачно шифровалась, прежде чем сделать из нее бэкап. Поэтому начиная с SQL Server 2012, параметры PASSWORD и MEDIAPASSWORD не используются при создании резервных копий. Восстановление резервных копий, созданных с применением пароля, остается возможным.
Тем не менее шифрование данных и шифрование резервных копий — это два разных по своему назначению сценария. Очевидно, что при отчуждении резервной копии правилом хорошего тона является ее защитить. Например, если мы переносим базу в другой ЦОД, чтобы исключить утечку в процессе передачи по каналам связи или еще как-либо. Однако шифрование влечет накладные расходы, и если база данных надежно хранится в локальном датацентре, зачем ее шифровать только для того, чтобы сделать бэкап? К счастью, в SQL Server 2014 это стали два независимых процесса. Аналогично шифрованию данных резервную копию можно зашифровать на основе сертификата или асимметричного ключа. Поддерживаются алгоритмы шифрования AES 128, AES 192, AES 256 и Triple DES.

В предыдущем посте была рассмотрена автоматизация процесса дефрагментации индексов. Теперь пришла очередь статистики.

Собственно для чего она нужна?

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

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