(Возврат на основную страницу)

Содержание номера за Октябрь 2007 год

Когда оптимизатор запросов SQL Server ошибается

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

SQL Server 2005: версионность данных и производительность

Версионность данных является одной из самых важных возможностей SQL Server 2005. Различные подключения, читающие данные, могут получать различные значения из одной и той же записи, как в Oracle. Это может быть достигнуто за счет использования уровня изолированности SNAPSHOT ISOLATION LEVEL или снимков базы данных DATABASE SNAPSHOTS.

В этой статье мы измерим, насколько эти две новые возможности SQL Server 2005 влияют на производительность чтения и записи данных.

Динь!!! Динь!!! Динь!!! Учения по восстановлению после аварии

Одна старая поговорка утверждает: «пока не попробуешь — не узнаешь». Я бы сказал, что планирование послеаварийного восстановления — тот самый случай.

Проблема

Мне было бы удивительно слышать, что какая­то компания, деятельность которой базируется на использовании информационных технологий, не имеет плана послеаварийного восстановления. Возможно, разные планы могут носить более или менее формальный характер, но в центре внимания многих таких планов — серверы SQL Server и необходимость быстро их восстанавливать, чтобы поддержать работоспособность предприятия. Но протестирован ли ваш план? Как насчет ситуации, когда ключевых сотрудников нет в городе? Или когда у вас нет прямого доступа к вашим серверам SQL Server или к локальной сети? Сыграет ли ваш план восстановления данных свою роль или он рассыплется как карточный домик?

Решение

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

Управление исходным кодом и базы данных

Многие DBA-администраторы, должно быть, слышали или задавали сами вопрос о механизме управления исходным кодом для баз данных SQL Server. Идея кажется блестящей. После реализации схемы базы данных можно было бы без труда вернуться обратно к ее конкретному варианту, сравнить этот вариант с текущей версией и получить массу информации для ревизии или возврата объекта базы данных в предыдущую версию.

Но с чего же начать процесс управления исходным кодом для базы данных SQL Server? Такая система имеет специфические проблемы, которые необходимо решить, в зависимости от того, какую из следующих методик разработки баз данных вы выбираете:

1.  Хранение схемы базы данных в базе данных.

2.  Хранение схемы базы данных в виде файлов с кодом создания объектов, которые при исполнении формируют базу данных.

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

Большинство доступных систем управления исходным кодом работает с файлами и, следовательно, не работает непосредственно с базами данных SQL Server. Схема базы данных может быть сохранена в файлах в интересах управления исходным кодом, но тогда из­за необходимости транслировать объекты схемы в файлы возникает вопрос: совпадает ли схема, представленная в базе данных, со схемой, представленной в файлах?

Как деинсталлировать копию SQL Server 2005 вручную

В этой статье содержится информация о том, как модифицировать реестр. Обязательно создайте резервную копию реестра, прежде чем вносить в него изменения. Убедитесь в том, что вы знаете, как можно восстановить реестр в случае возникновения проблем. Чтобы получить дополнительную информацию о том, как можно создать резервную копию, восстановить и модифицировать реестр, перейдите по следую­щей ссылке к статье с указанным номером из базы знаний Microsoft Knowledge Base: 256986 (http://support.microsoft.com/kb/256986/) Description of the Microsoft Windows registry.

В данной статье рассказывается о том, как выполнить деинсталляцию автономной копии Microsoft SQL Server 2005 вручную. Если вы будете следовать шагам, перечисленным в данной статье, то подготовите систему таким образом, что сможете повторно инсталлировать SQL Server.

Насколько полезны индексы

Наличие индексов для таблиц позволяет повысить производительность запросов TSQL. Однако индексы также увеличивают объем работы, которую должен выполнять сервер SQL Server при осуществлении операций вставки, обновления или удаления записей. Со временем обеспечиваемая индексами производительность может снизиться, поскольку индексы оказываются фрагментированными.

Раз вы являетесь DBA­администратором, вам необходимо понимать, как именно приложения используют доступные индексы, чтобы можно было удостовериться в том, что это делается оптимальным образом и не приводит к тому, что сервер SQL Server выполняет лишнюю работу. В этой статье я рассмотрю одно динамическое административное представление (Dynamic Management View, DMV), из которого вы можете извлечь данные, которые помогут вам понять, как используются ваши индексы.

(Возврат на основную страницу)