(Возврат на основную страницу)
Кимберли Л. Трипп
Как лучше всего использовать неполное протоколирование
Пол С. Рэндал
Ошибки ввода/вывода, зеркалирование баз данных и другое
Бен Холл
Использование утилиты SQL Data Generator вместе с модульными тестами
Шон Калдерон
Недорогой мониторинг вашего SQL Server средствами Службы Отчетов (SQL Server Reporting Services). Часть 1
Как лучше всего использовать неполное протоколирование*
В поисках того, что же является самым главным для предотвращения катастрофы, люди часто увлекаются технологиями. Хотя необходимо лишь разобраться в существующих технологиях, чтобы выбрать лучшую, одна единственная технология редко предлагает полное решение. При построении надежной, готовой к катастрофе стратегии, необходимо учитывать много важных фактов, включая выбор наиболее подходящей вам модели восстановления базы данных. Ваш выбор модели восстановления может оказать сильнейшее действие на данные, которые вы сможете восстановить после сбоя — и это не самое лучшее время, чтобы узнать, что до сбоя вы выбрали неверную модель восстановления.
В SQL Server 2000 существовало три модели восстановления базы данных: Full (Полная), Bulk_Logged (Неполное протоколирование) и Simple (Простая). Microsoft создала эти модели во многом для связывания воедино концепций занесения данных в журналы, восстановления и производительности. Однако многие администраторы БД ошибочно полагают, что эти модели работают просто как опции баз данных, которые существовали до SQL Server 2000, типа SELECT INTO/Bulk Copy и Trunc. Log on Chkpt. Хотя сходство между этими моделями восстановления и прежними опциями баз данных и существует, прямой связи между ними нет. В табл. 1 перечисляются модели восстановления SQL Server 2000 и опровергаются общепринятые заблуждения о том, как каждая модель сравнивается с предыдущими установками опций баз данных. Например, полная модель восстановления это не то же самое, что установка SELECT INTO/Bulk Copy и Trunc. Log on Chkpt. Полная модель теперь поновому, а для некоторых операций более подробно, сохраняет информацию в журнал событий. Возможно, вы узнали это на собственном горьком опыте, когда наблюдали, как ваши операторы стали дольше выполняться и занимать больше места в журналах событий, по сравнению с предыдущими версиями. Но самая непонятная модель восстановления это, наверное, неполное протоколирование, результат выполнения которой похож на настройки опции SELECT INTO/Bulk Copy, но предоставляет другие возможности восстановления. Давайте внесем ясность в процесс восстановления при помощи неполного протоколирования, и, возможно, вы решите, почему вам стоит использовать модели восстановления полную и с неполным протоколированием, предварительно узнав больше о слабых местах неполного протоколирования, на которые необходимо обратить внимание.
*Данная статья основана на главе 9 «Основы восстановления баз данных» книги «Microsoft SQL Server 2000 High Availability» (Microsoft Press, 2003) Аллана Хирта (Allan Hirt) (технические консультанты: Кэтан Кук (Cathan Cook), Кимберли Л. Трипп (Kimberly L. Tripp) и Франк МакБат (Frank McBath)). — Прим. ред.
Ошибки ввода/вывода, зеркалирование баз данных и другое
Использование утилиты SQL Data Generator вместе с модульными тестами
Бен Холл, один из создателей утилиты SQL Data Generator, продолжает придумывать способы, позволяющие использовать этот генератор для того, чтобы обеспечить тестовые данные для модульного тестирования в условиях, когда выдвигаются самые разные требования. Независимо от того, какую библиотеку — NUnit, XUnit, MbUnit или MSTest — вы используете, теперь у вас есть возможность получить столько данных, сколько необходимо.
Утилита SQL Data Generator
С помощью утилиты SQL Data Generator фирмы Red Gate можно легко и быстро создавать большие объемы тестовых данных. Теперь у вас есть возможность встроить средства генерации таких данных в процесс модульного и интеграционного тестирования.
Мне хотелось бы продемонстрировать, как бы я использовал утилиту SQL Data Generator (SDG) в модульных тестах для тестирования не только на уровне доступа к данным (Data Access Layer, DAL), но также на бизнесуровне (Business Layer, BU). Этот инструмент можно использовать для тестирования самого разного программного кода, созданного с применением различных языков программирования.
Воспользовавшись предоставленным в этой статье кодом, а также утилитой SQL Data Generator, вы в состоянии протестировать масштабируемость и производительность любого кода платформы .NET, обрабатывающего данные.
Автоматизация генерации данных
Инсталляция утилиты SQL Data Generator обеспечивает возможность генерировать данные в среде с пользовательским интерфейсом или с помощью командной строки. Пользовательский интерфейс позволяет определять структуру, компоновать и генерировать данные, а также сохранять все настройки для последующего использования в виде файла проекта. В файле проекта хранится XMLкод, содержащий все столбцы всех таблиц базы данных. Для каждого столбца таблицы запоминаются все связанные с ним настройки, такие как выбранный генератор и его свойства, например, выражение, которое используется для генератора RegEx. Наряду с пользовательским интерфейсом инсталлируется приложение командной строки. Это приложение вырабатывает данные, основываясь на информации, взятой из сохраненного проекта. Однако приложение командной строки лишено интерфейса API. Отсутствие интерфейса API могло бы препятствовать включению приложения командной строки в автоматизированный процесс.
В качестве возможного решения проблемы я создал на языке C# оболочку для этого консольного приложения, которую вы можете получить (включая исходный код), скачав ее с сайта Codeplex (http://www.codeplex.com/SDGGeneators). Созданная мной оболочка позволяет интегрировать утилиту SQL Data Generator в модульные тесты, а ее дополнительное преимущество заключается в том, что она не зависит от библиотеки, то есть будет работать со всеми версиями NUnit, XUnit, MbUnit или даже MSTest.
Чтобы приступить к использованию такой инфраструктуры тестирования, вам надо будет скачать с сайта CodePlex сборку SDG.UnitTesting.dll. Предлагаемое мной решение включает два проекта, SDG.UnitTesting.SimpleTalk и SDG.UnitTesting.SimpleTalk.Tests; первый проект послужит «рабочим» кодом, который я хочу протестировать, тогда как второй проект включает модульные тесты. Средствами Visual Studio я добавил в проект SDG.UnitTesting.SimpleTalk.Tests ссылку на проект SDG.UnitTesting.SimpleTalk с тем, чтобы можно было создавать объекты, которые будут тестироваться. Кроме того, в проект SDG.UnitTesting.SimpleTalk.Tests я включил ссылку на скачанную вами сборку SDG.UnitTesting.dll.
На этой стадии у меня есть возможность воспользоваться одним из двух способов для выполнения утилиты SQL Data Generator.
Способ, основанный на использовании атрибутов. Снабдите тестовые методы атрибутами, чтобы указать, какой проект утилиты SQL Data Generator необходимо выполнить перед прогоном теста.
Способ, предусматривающий использование POCOоболочки. Этот способ позволяет создать в программном коде объект и обратиться к его методу Execute(), чтобы сгенерировать данные.
Недорогой мониторинг вашего SQL Server средствами Службы Отчетов (SQL Server Reporting Services). Часть 1
На рынке представлено множество прекрасных систем мониторинга производительности SQL Server, они представлены во всем разнообразии форм и размеров. Обычно уровень функциональности прямо пропорционален цене. Большинство этих систем позволяют отследить необходимые данные о производительности для эффективного мониторинга ваших систем, но стоить это будет дорого.
Очень часто администраторы БД ограничены возможностями средств, которые они могут использовать. У них может не быть подходящего оборудования для поддержки коммерческих средств мониторинга производительности. После установки эти системы начинают неизбежно пожирать ресурсы. И ресурсы процессора, потребляемые этими системами, могут быть значительными. Также, эти средства могут обладать недостаточно гибкими настройками и собирать кучу ненужной вам в повседневной работе информации. Другой, часто очень важный, вопрос связан с установкой ПО на ваши серверы. Ограничения по оборудованию или процедурные ограничения могут сделать непривлекательным даже то ПО, которое вы можете себе позволить. Многие среды требуют некоторой минимальной конфигурации и контроля за изменениями для коммерческого ПО мониторинга. И усилия, прилагаемые для настройки ПО, во многих случаях превосходят выгоду от его использования. И наконец, цена этих систем делает их недоступной для малого и среднего бизнеса. Часто люди, ответственные за принятие решения, не понимают метрик, следовательно, они не переносят, когда приходится тратить деньги на их мониторинг.
К счастью, существует недорогая альтернатива коммерческим системам мониторинга производительности. Операционные системы Microsoft собирают данные о производительности и оперативно предоставляют эту информацию пользователям или разработчикам в System monitor. Приложение perfmon.exe предоставляет вам доступ к мониторингу тысяч метрик. Более того, эти метрики могут быть направлены в таблицы данных SQL Server.
В данной статье будет описаны основные шаги, необходимые вам для построения собственной системы мониторинга SQL Server Hardware Performance (Производительность Оборудования SQL Server) средствами, которые обычно доступны большинству администраторов БД и разработчикам. Затраты на установку минимальные (несколько часов усилий), а в результате — продукт, который является и гибким и точно настраиваемым. Я также затрону несколько приемов для анализа данных. Хороший анализ данных мониторинга может помочь в решении проблем и планировании будущего обновления оборудования.
(Возврат на основную страницу)