(Возврат на основную страницу)
SQL Server 2005 спустя 6 месяцев
Через шесть месяцев после выхода SQL Server 2005 все еще свободен от серьезных ошибок и известных проблем с безопасностью. Однако несмотря на то, что между выпусками разных версий СУБД прошло пять лет, Microsoft пока не предоставила доказательства повального спроса на SQL Server.
Microsoft не обнародовала подробности внедрения продукта, а показатели продаж в финансовых отчетах компании устойчивы, но не отличаются коренным образом от стабильного роста прибыли от SQL от квартала к кварталу в последние годы.
Главным образом с помощью SQL Server 2005 Microsoft, занимая ведущие позиции в сфере создания баз данных для малого и среднего бизнеса, пытается распространить свое влияние на крупные предприятия — область, где лидируют Oracle Corporation и IBM Corporation. Данная стратегия состоит в расширении и добавлении интеллектуальных бизнесфункций, за которые раньше покупатели платили дополнительно к основной стоимости.
Пока что Microsoft демонстрировала вполне приличный рост. В последнем финансовом квартале, который закончился 31 марта, доходы от SQL Server поднялись на тридцать процентов. Это значение существенно, но не превышает показатели за предыдущие кварталы. Несмотря на отсутствие новой версии в течение нескольких лет продукт, обеспечивающий компании более миллиарда долларов прибыли в год, продолжает показывать устойчивые двузначные результаты роста прибыли.
Принимая во внимание длительный период разработки и тестирования, количество клиентов Microsoft, использующих SQL Server 2005 в рабочей среде, довольно внушительно. Уже сейчас на Webсайте SQL Server в разделе практических примеров применения (case study) собрано более 130 откликов от покупателей. Внутри корпорации Microsoft уже несколько лет эксплуатируются рабочие системы на базе этой версии базы данных.
Однако есть и свидетельства того, что новые интеллектуальные бизнесвозможности не могут удовлетворить потребности крупных компаний. «Он просто оказался медленнее, чем мы думали, — заявил сотрудник одной крупной фирмы в области системной интеграции, попросивший не называть его имени. — Службы анализа и построения отчетов не вызвали такой горячей поддержки, на которую рассчитывали производители. Добавленные интеллектуальные бизнесинструменты не становятся стандартами — приходится одновременно с ними применять другие решения».
Другой партнер Microsoft, компания Wilton, N.H.based Edgewood Solutions, провела опрос среди ITпрофессионалов прямо перед выпуском SQL Server 2005 в 2005 г. Было выяснено, что 55% крупных, 45% средних и 50% малых организаций планировали подождать по крайней мере год перед внедрением SQL Server 2005 в системы с высокой нагрузкой.
Microsoft внедряет новые функции, чтобы большее число покупателей приняло технологию. Одна из наиболее ожидаемых из них — зеркалирование баз данных, которое было формально включено для использования в рабочих системах только с выходом Service Pack 1 (SP1), а между тем является традиционным показателем для крупных фирм, подумывающих о применении продуктов Microsoft. Многие клиенты не будут даже рассматривать возможность развертывания технологии от Microsoft до выхода первого сервисного пакета. Сегодня ожидание SP1 стало менее напряженным, поскольку за последние годы контроль качества и тестирование в Microsoft значительно улучшились. Сервисный пакет, например, не содержит никаких исправлений в области безопасности. Впрочем, поскольку целью Microsoft является продвижение SQL Server 2005 в сектор крупного бизнеса, более длительный цикл продаж может стать для SQL Server новой реальностью.
Управление изменениями схемы данных. Часть 1
Какие методики для управления изменениями схемы данных в SQL Server 2005 считаются лучшими? Какие самые быстрые и при этом наименее трудоемкие способы для обеспечения высокой доступности существуют? Ответить на эти вопросы призвана первая часть данной статьи. По мере развития потребностей производства обычным явлением становится изменение схемы данных. Поскольку SQL Server 2005 поддерживает изменения схемы (такие как добавление полей и ограничений, изменение типов данных полей и их свойств, а также удаление полей и ограничений), мы сосредоточимся на проблемах, касающихся производительности и параллельного выполнения, которые следует иметь в виду при обычных операциях на больших таблицах.
Стратегия резервного копирования для SQL Server
План управления резервными копиями БД подобно страховому полису защищает информационную собственность компании: при наличии хорошей политики резервного копирования данные всегда могут быть восстановлены с минимальными потерями. Администратор БД должен определить, какие требования к резервному копированию присущи каждой из баз данных, чтобы развернуть отвечающее им адекватное решение. В этой статье обсуждаются различные методы резервного копирования БД, которые можно применять для минимизации потерь данных в связи с непредвиденным повреждением базы, крахом системы или отказом оборудования.
К повреждению баз данных могут привести различные события: вышел из строя один из жестких дисков, программист внедрил обновление для приложения, не проведя полное тестирование, что повлекло обширное повреждение данных. Это только две из множества причин, по которым вам может потребоваться восстановить одну из ваших баз данных из резервной копии. При разработке стратегии резервного копирования вам следует создать список возможных сценариев, которые, на ваш взгляд, с наибольшей вероятностью могут привести к необходимости восстановления БД. Они помогут вам спланировать стратегию резервного копирования.
Требования к резервному копированию
Каждая база данных может иметь как общие с остальными требования к резервному копированию, так и свои собственные. Когда вы разрабатываете БД для поддержки новых приложений, вам нужно определить для них требования к резервному копированию. Так, требования для БД, которая поддерживает в режиме онлайн систему заказов, и для БД, которая поддерживает систему отчетов об управлении в режиме «только для чтения» и обновляется раз в месяц, будут различными.
При этом примите во внимание следующее:
• Насколько устойчиво ваше приложение к потере данных?
• Как часто обновляются данные в базе данных?
• Как долго может приложение оставаться в нерабочем состоянии, пока вы восстанавливаете базу данных?
• Насколько велика ваша база данных?
Ответы на эти вопросы помогут вам разработать адекватную стратегию резервного копирования, которая позволит восстановить базу данных в случае повреждения.
Типы резервных копий
Microsoft SQL Server поддерживает четыре типа резервных копий баз данных: Complete, Differential, Transaction log и File/Filegroup. В режиме Complete (полное копирование) в один файл резервной копии сохраняется вся БД целиком. С его помощью можно восстановить ее состояние на момент создания резервной копии.
В режиме Differential (разностное копирование) сохраняются только данные, которые изменились с момента создания последней полной (Complete) копии. Чтобы создать резервную копию типа Differential, нужно сначала провести копирование в режиме Complete. Для восстановления разностной копии вы должны сначала восстановить соответствующую полную копию и только потом — разностную. После этих двух операций ваша БД будет находиться в состоянии, в котором она была на момент создания разностной копии. Применение режима Differential сокращает время и место на жестком диске, необходимые для резервного копирования базы данных.
В режиме Transaction Log (резервное копирование журнала транзакций) сохраняются все транзакции, проведенные с момента снятия последней копии с журнала транзакций. Чтобы его запустить, необходимо сначала выполнить полное резервное копирование БД. Применение Transaction Log позволяет выполнять восстановление состояния базы в заданный момент времени, поэтому при использовании этого режима вы можете задать любые дату и время, охваченные резервной копией, и восстановить базу данных на этот момент. Создание копии в режиме Transaction Log является прекрасным инструментом для резервного копирования любого процесса, который может внести в БД ошибочные изменения.
Резервное копирование типа File/Filegroup позволяет сохранить в файл резервной копии отдельный файл или группу файлов. С помошью этого режима можно сохранять отдельные части базы данных. Обычно копирование типа File/Filegroup используется в очень больших БД, где снятие полной копии занимает слишком много времени.
Стратегия резервного копирования
Когда вы определили требования к резервному копированию для ваших БД, необходимо разработать его стратегию. Ее выбор будет зависеть от типа и сферы применения вашей базы данных. Рассмотрим различные стратегии, которые могут быть применены для трех различных типов баз данных.
Оптимизация производительности модели данных: конфигурация базы данных
Оптимизация производительности базы данных SQL Server начинается с качественных конфигурации и модели базы данных. Несмотря на то, что вы можете достигнуть определенного уровня, настроив БД с помощью различных типов индексов и более мощного аппаратного обеспечения, вам никогда не удастся полностью компенсировать плохую модель данных.
Плохая конфигурация БД или ненадежная модель данных может быть причиной медленного отклика системы, блокированных или взаимоблокированных транзакций, непонятных или неточных результатов в бизнесотчетах, отсутствия синхронизации данных, несогласованных данных и невозможности создать запрос, возвращающий необходимые данные. Например, в таких условиях может замедлиться отклик от сервера баз данных. Или неудачная смесь транзакций, обновляющих данные, от конфликтующих приложений может привести к блокировкам или взаимоблокировкам. Если вы не можете найти перегруженный процессор или две конфликтующие транзакции пытаются эксклюзивно заблокировать один и тот же ресурс, серьезно пересмотрите конфигурацию базы данных и модель данных — источником ваших проблем могут быть именно они.
Чтобы создать базу данных, которая будет работать так, как вы того хотите, сначала обратите внимание на ее основу. Начните с оптимизации операционной системы. Затем сконфигурируйте БД для поддержки хорошей модели данных и обеспечения целостности информации. Активно используя базовые элементы, вы предотвращаете многие проблемы с производительностью до того, как они начались, и готовите почву для дальнейшего повышения быстродействия базы данных.
Подготовка окружения
Настройка производительности SQL Server начинается с операционной системы. Конечно, SQL Server может работать только в Windowsокружении. Это значит, что вы должны тесно сотрудничать с системным администратором Windows. Два основных параметра настройки на сервере баз данных — это файловая система и файл подкачки (page file). Для SQL Server необходимо использовать файловую систему NTFS. Она более устойчивая и безопасная чем FAT, даже если файловая система FAT (возможно) немного быстрее работает на запись. Конфигурируя файл подкачки, следуйте правилу: для виртуальной памяти нужно статично выделить в полтора раза больший объем памяти, чем есть у физической памяти. Если какието компоненты сервера, такие как сетевые адаптеры или жесткие диски, переходят в спящий режим после определенного периода неактивности, отключите такую возможность (или попросите сделать это системного администратора) — вы же не хотите выполнять «холодную» перезагрузку системы для их запуска. В многопротокольной среде необходимо сделать TCP/IP первым в стеке протоколов. И если у вас медленно работает сеть, убедитесь, что установлен тайм-аут для подключения более длительный, чем время, необходимое приложению для подключенияк БД.
В дополнение к подготовке операционной системы для оптимальной работы SQL Server убедитесь, что вы создали отказоустойчивую среду. Для надежности и скорости я рекомендую использовать RAIDмассивы. Хотя это метод дорогостоящий, вы можете более оптимально использовать бюджет, если более тщательно отнесетесь к выбору типа RAID и определите, какая часть базы данных нуждается в более мощной защите.
Оптимизация производительности модели данных: хорошо бы похудеть
При оптимизации модели данных для повышения производительности «мы выбираем тощих» — это стратегия, которой вы должны следовать в отношении таблиц в базе данных. В этом контексте «толщина» (или «худоба») означает количество столбцов в таблице и максимальное количество байт в одной записи (размер записи).
Запомните, что наиболее дорогостоящими операциями в работе баз данных являются дисковые операции ввода/вывода, перекачка данных с диска в кэш и обратно. Все вычисления, поиск, даже простые запросы (такие как SELECT * FROM pubs.dbo.authors) выполняются только после того, как данные скопируются в кэш памяти. Также следует знать, что фундаментальная единица хранения данных в SQL Server — страница, кусок непрерывного пространства на жестком диске размером 8 Кб. (Эти 8 Кб равняются 8192 байтам.) Если отбросить пространство, необходимое для заголовка страницы (page header) и таблицы смещения строк (row offset areas), то остается 8060 байт пространства, доступного для пользовательских данных. Более подробную информацию об использовании дискового пространства в SQL Server можно найти в разделе «Pages and Extents» SQL Server 2000 Books Online — BOL. Таким образом, более «тонкие» таблицы приводят к улучшению производительности, потому что они используют меньше операций ввода/вывода и требуют меньше места для хранения. Чтобы помочь вам улучшить быстродействие баз данных, я представлю концепцию «мы выбираем тощих» и расскажу о проблемах, которые связаны с «толстыми» таблицами, и о том, как эти таблицы «посадить на диету».
Почему худым живется лучше
Оптимизируя модель данных и создавая «тонкие» таблицы, вы должны понимать преимущества нормализации и механизм этого процесса. Моя концепция не требует, чтобы вы преобразовывали каждую связь в вашей модели данных в таблицы с четырьмя или пятью полями. Это означает, что через хорошее понимание ваших данных и требований бизнеса вы сможете нормализовать каждую связь в модели данных в виде третьей нормальной формы (3НФ). Тогда таблицы будут относительно «тонкими».
Описываемый подход имеет практический аспект, связанный с числом строк таблицы, размещенных на странице. Чем больше строк находится на странице, тем больше данных SQL Server передаст с диска в кэш памяти и обратно за одну операцию ввода/вывода. Вообще, чем меньше операций ввода/вывода требуется SQL Server для вычислений или поиска, тем выше производительность.
Динамические представления и функции управления
В SQL Server 2005 введено понятие динамических представлений управления (dynamic management views, DMV) и динамических функций управления (dynamic management function, DMF). Что такое DMV и DMF? Как их использовать для динамического управления объектами? DMV и DMF позволяют с помощью TSQL проникнуть в механизм работы SQL Server и отследить, что и как он делает. Они избавляют от необходимости применять запросы к системным таблицам или другие неудобные методы получения системной информации, которые приходилось применять в SQL Server 2000.
Существует множество динамических представлений и функций управления, которые делятся на две категории. Одни DMV/DMF используются для получения развернутой информации о сервере и работают в масштабе сервера. Другие DMV/DMF служат для получения информации о базе данных и функционируют в масштабе БД. Все DMV/DMF хранятся в базе данных master в схеме sys. Все объекты схемы sys, имя которых начинается с «dm_», являются динамическими. Все динамические представления и функции управления организованы в следующие группы:
• связанные со средой CLR;
• связанные с зеркалированием баз данных;
• связанные с выполнением;
• связанные с полнотекстовым поиском;
• связанные с индексами;
• связанные с вводом/выводом;
• связанные с уведомлениями запросов;
• связанные с репликацией;
• связанные с компонентом Service Broker;
• связанные с операционной системой SQL Server;
• связанные с транзакциями.
(Возврат на основную страницу)