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

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

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

Устранение проблем производительности системы базы данных может быть непреодолимой задачей. Важно знать, в чем заключается проблема, но еще более важно понимать механизм реагирования системы на определенный запрос. На производительность ЦП сервера базы данных может повлиять ряд факторов: компиляция и перекомпиляция инструкций SQL, отсутствующие индексы, многопоточные операции, проблемы производительности дисков, узкие места со стороны памяти, процедуры обслуживания, действия по извлечению, преобразованию и загрузке и другие факторы. Использование ЦП само по себе не является проблемой — процессор предназначен для выполнения работы. Ключом к оптимальному использованию процессора является обеспечение того, что процессор выполняет необходимую работу, а не тратит время из-за плохо оптимизированного кода или оборудования с низкой производительностью.

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

По нескольку раз в неделю у меня проcят совета, как эффективно обслуживать рабочую базу данных. Порой вопросы исходят от администраторов баз данных, которые применяют новые решения и ищут помощи в подгонке практики обслуживания под характеристики новых баз данных. Чаще вопросы исходят от людей, которые не являются профессиональными администраторами баз данных, но, по той или иной причине, владеют базой данных или несут за нее ответственность. Я предпочитаю называть их «невольными администраторами баз данных». Задача этой стать состоит в предоставлении учебника по наилучшим вариантам обслуживания баз данных...

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

Администраторы баз данных SQL Server по всему миру сталкиваются с проблемой, которая кажется вечной: устранением неполадок, основной объем которого осуществляется для обнаружения тех или иных проблем с производительностью. Даже наиболее тщательно сконструированная и протестированная система приложений испытывает изменения с течением времени, что может привести к значительным проблемам с производительностью.

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

Мы собираемся обновить большинство наших серверов до SQL Server 2008, и одна из функций, появления которых в производственной среде я жду с нетерпением, – сжатие резервных копий. Я знаю, что могу включить ее по умолчанию для всех баз данных на каждом сервере, но я также слышал, что, возможно, этого не стоит делать. Я не уверен, почему ее может быть нежелательно включать по умолчанию, поскольку кажется, что терять здесь нечего. Не могли бы вы помочь объяснить причины этого?