Рекомендации по SQL Server


Повысьте производительность SQL Server, следуя советам передовых методов хранения SQL Server в выпуске SQL Server Pro за этот месяц.

Пункты, выделенные ниже полужирным шрифтом, соответствуют названию статьи в мартовском выпуске ежемесячного онлайн-журнала SQL Server Pro, основанного на подписке.

Во многих системах баз данных ограничивающим фактором производительности является ввод / вывод (I / O). Имея это в виду, вы оцените важность рекомендаций Майкла Отли по хранению SQL Server. Пожалуйста, не откладывайте банальное название, это важный материал! Статья открывается обзором файлов данных и журналов, а также некоторыми передовыми практиками для них:

Размещайте файлы данных и журналов на разных дисках

Включите AutoGrow (не уверен, что согласен с этим)

Отключить AutoShrink

Включить мгновенную инициализацию файла

Далее рассматриваются различные типы дисковых RAID-массивов: RAID 0 (чередование), RAID 1 (зеркальное отображение), RAID 5 (чередование с контролем четности) и RAID 10 (зеркальное отображение с чередованием). Обсуждается важность типов RAID с точки зрения производительности и защиты.

Затем проверяется база данных Tempdb. Он может использоваться всеми другими базами данных, а также самим SQL Server внутри компании, поэтому часто это самая активная база данных. В статье для tempdb предлагается:

Файлы журнала и данных размещаются на разных дисках.

RAID 1 или 10 используется для повышения его производительности

Соответствующего размера, чтобы избежать событий AutoGrow

Разделить на несколько файлов

Твердотельные диски (SSD) все чаще используются для повышения производительности. В статье обсуждаются преимущества переноса индексов, данных, журналов и tempdb на твердотельные накопители, при этом подчеркивается их более короткий жизненный цикл по сравнению с жесткими дисками.

Наконец, описывается важность базовых показателей производительности, т. Е. Обеспечения поддержки в устранении неполадок и выявлении тенденций роста. Различные счетчики системного монитора, относящиеся к хранилищу, обсуждаются вместе с их типичными значениями (чтобы вы могли определить, если что-то не так).

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

Последние проблемы относятся к SQL Server 2014, а в этом месяце мы подробнее рассмотрим в разделе «Дополнительные вопросы о SQL Server 2014 In-Memory OLTP». Ответы на вопросы включают:

Будет ли он включен в стандартную версию? (неожиданно)

Это то же самое, что и старая возможность PINTABLE? (нет, замков и защелок нет)

Решит ли это какие-либо проблемы с производительностью? (нет, неплохой дизайн и тд)

Могу ли я запустить инструмент ARM на версиях баз данных до 2014 года? (да, но нужен SSMS 2014)

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

Как вы можете быть уверены, что ваши изменения улучшили производительность? Майкл К. Кэмпбелл показывает, что на это можно ответить, создав простые базовые показатели производительности с помощью SQL Server Profiler. В статье представлены пошаговые инструкции вместе со снимками экрана о том, как Profiler можно использовать для измерения агрегированных показателей производительности до (т. Е. Базового уровня) и после изменения. Предоставляется некоторый полезный код SQL, чтобы определить, действительно ли изменение выгодно. Теперь не должно быть оправдания тому, что вы знаете, к лучшему ли ваши изменения!

В редакции убедительно утверждается, что «ПК еще не мертв». Суть аргумента заключается в том, что смартфоны и планшеты становятся все более популярными в потребительском пространстве, но ПК имеют преимущество в бизнес-пространстве. Кроме того, ПК, как правило, намного лучше справляются с созданием контента. Я подозреваю, что будущее покажет, что эти устройства дополняют друг друга, а не являются конкурентами.

Задача прошлого месяца «Идентификация подпоследовательности в последовательности» предоставила три итеративных решения. В этом месяце головоломка была пересмотрена с помощью трех основанных на наборах решений, два из которых медленнее, чем самое быстрое итеративное решение, а одно столь же быстрое. Решения на основе наборов основаны на: FOR XML PATH, COUNT и NOT EXISTS. Решения на основе наборов обычно предпочтительны, поскольку они хорошо подходят для реляционной модели, используют меньше кода и, как правило, более элегантны. Как всегда, статьи Ицика Бен-Гана дают много пищи для размышлений, и обе части этой статьи размещены на сайте SQL Server Pro и доступны всем.

Аллен Уайт утверждает, что знание большего количества инструментов позволит решать больший круг проблем с использованием наиболее подходящего инструмента. Он демонстрирует это в другой статье «Создание таблиц базы данных в PowerShell с SMO», которую можно найти в Интернете. Автор показывает, как PowerShell можно использовать для создания таблиц, взаимодействуя с объектами управления SQL Server (SMO). Признавая, что PowerShell — не лучший инструмент для создания таблиц, эта статья сформирует основу для серии с примерами, которые труднее реализовать в SQL Server Management Studio. Я не могу отделаться от мысли, что нужно было предоставить лучший начальный пример — по сути, он использует не тот инструмент …

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

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

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

Проверить базу данных (DBCC CHECKDB)

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

Изменить параметры сортировки на уровне базы данных

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

Изменить сортировку на уровне таблицы

Изменение сопоставления представлений

Восстановите индексы

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

Журнал этого месяца выглядел неоднозначно. Мне понравилась статья с рекомендациями по хранению данных, содержащая множество предложений по повышению производительности системы. Конечно, все, что есть в SQL Server 2014, следует приветствовать. Я не уверен, что многие люди найдут предмет из коллекции интересным, но будьте уверены, однажды он может оказаться для вас незаменимым. В статье о резервных копиях не хватало подробностей. Тем не менее, в целом журнал этого месяца мне показался интересным.


Добавить комментарий