(Возврат на основную страницу)
В телеконференциях довольно часто спрашивают, чем именно занимаются админи-страторы БД? Ответы можно услышать самые разные, от «прогулок по воде» до «разглядывания узоров на потолке». Ясно, что первая цитата — из ответа активно работающего администратора, а вторая прозвучала из уст тех, кто очень тесно связан с администраторами БД.
Итак, чем же занимается администратор БД на самом деле? В организациях без администратора БД недооценивают пользу, которую он приносит (или может принести). Многие администраторы задействованы далеко не в полную силу, поэтому все больше распространяется мнение, что администраторы бездельничают. Очень трудно втиснуть всех администраторов в одну категорию. В этой статье я расскажу о разных типах администраторов, которые часто приходилось наблюдать в жизни, и попытаюсь описать их работу. Имейте в виду, что у администраторов есть тонны других ролей и обязанностей.
Администратор рабочей системы
Большую часть рабочего дня такой администратор проводит в попытках избавить себя от работы. Дело в том, что ни один администратор в здравом уме не будет выполнять ежедневное резервное копирование БД вручную, а автоматизирует эту задачу, спланировав ее с помощью агента SQL Server (SQL Server agent). Основные задачи истинного рабочего администратора как, правило, следующие.
• Установка SQL Server. Обычно рабочий администратор устанавливает SQL Server в соответствии с корпоративными стандартами. Он также может разработать метод автоматической установки SQL Server. В его обязанности также входит развертывание пакетов обновлений (service pack).
• Установка и развертывание БД. Настоящий администратор рабочей системы предпочитает устанавливать и обновлять БД с помощью готовых сценариев.
• Создание планов резервного копирования. В зависимости от бизнес-требований компании (то есть в зависимости от ценности корпоративных данных) находит самое экономически выгодное решение, а также создает и реализует план резервного копирования. Администратор начинает бить тревогу при малейшей угрозе безопасности компании.
• Тестирование сценариев восстановления после аварий. регулярно выполняет тестирование плана резервного копирования и проверку целостности резервных копий корпоративных данных. Стоит ли говорить, что польза от резервной копии определяется возможностью восстановления данных с ее помощью.
• Управление безопасностью. В сотрудничестве с администратором-программистом, планировщиком продукта и отделом безопасности определяет, насколько БД будет открыта для доступа приложений. Как правило, администратор рабочей системы является в этом случае «хранителем» БД, контролирующим доступ к ней.
• Оценка производительности компьютеров. Вычисляет производительность компьютеров и использует результаты тестов в качестве обоснования для определения конфигурации компьютера для развертывания БД.
• Принятие в эксплуатацию законченных решений от администраторов-программистов. Взаимодействует с администраторами-программистами для предотвращения возможных проблем при передаче продукта в эксплуатацию.
• Настройка производительности. Осуществляет настройку БД на физическом уровне. Он может делать это путем настройки структуры и организации файлов, планирования перестройки индексов или изменения аппаратной конфигурации сервера.
Здесь я преднамеренно умолчал об одной из ключевых особенностей функций администратора рабочей системы: он не занимается управлением данными. Он контролирует реализацию данных только на физическом уровне, но не модели данных или структуры данных в таблице. Известно, что теперь появляется совсем немного настоящих рабочих администраторов БД. С выходом SQL Server 2000 большинство администраторов превратились в так называемых «гибридных» администраторов — новый тип, который мы обсудим чуть позже.
Администратор-программист
Администратор-программист (разработчик) тесно связан с разработчиками проекта. В общем случае, неплохо поддерживать соотношение разработчиков и администраторов-программистов 3:1. В некоторых известных мне проектах требовалось соотношение 1:2, поскольку администрированием БД занималось больше сотрудников. Это обычная практика для проектов, где используется Analysis Services, в которых администратор БД вынужден создавать кубы и процессы ETL. Вот несколько типичных примеров задач, которые выполняет администратор-разработчик.
• Моделирование данных. Создание физической модели данных и модификация ее по мере необходимости. Обычно это подразумевает тесное сотрудничество с аналитиком данных и планировщиками продукта. Получается, что некоторые администраторы-программисты тесно сотрудничают с аналитиком, чтобы определить структуру логической модели данных. На это уходит куча времени, и в большинстве компаний предпочитают, чтобы логическую и концептуальную модели создавали аналитики, поскольку прикладная логика компании известна им лучше, чем администраторам.
• Создание пакетов DTS. Это новая задача для администраторов БД SQL Server версии 7.0 и выше, в которую входит создание процессов для загрузки и трансформации данных.
• Создание установочных сценариев. Естественно, сюда относится создание базовых установочных сценариев для создания таблиц, индексов, хранимых процедур и первоначальных данных, а также разного рода обновлений. Управление созданием БД — одна из самых трудных задач, на выполнение которых уходит значительная часть времени администратора.
• Написание хранимых процедур. Это самый противоречивый элемент в описании работы администратора. Истинный администраторпрограммист занимается написанием, настройкой и модификацией хранимых процедур. Как правило, администраторы помогают лишь при создании сложных запросов, оставляя написание простых запросов на усмотрение разработчиков. Лично у меня по этому вопросу сложилось ощущение, что лучше помочь написать 10 хранимых процедур с оператором select, чем написать хоть одну самому.
• Оптимизация производительности. Обычно администратор-разработчик занимается оптимизацией производительности на уровне запросов и индексов. При этом с помощью Profiler он ведет поиск медленных запросов и оказывает различную помощь при написании запросов. Кроме того, он может анализировать планы исполнения, чтобы определить, где нужно построить индекс для повышения производительности.
«Гибридный» администратор
Остальная часть статьи будет посвящена обсуждению нового типа администраторов БД, который развивался на моих глазах в течение последних нескольких лет. Время шло, граница между основными типами администраторов БД становилась все более размытой, и уже практически ни один администратор не мог назвать себя только администратором рабочей станции или администратором-программистом. Так родился новый тип администратора — «гибридный» администратор. Это оптимальный тип, поскольку такой администратор может сопровождать проект с разработки и до развертывания. В сущности, сфера его ответст- венности образована комбинацией всех вышеупомянутых задач, составляющих работу двух рассмотренных типов администраторов.
Среди прочих навыков администраторов нового типа следует отметить:
• загрузку тестовых данных;
• управление взаимодействием на основе XML;
• изучение CLR для написания хранимых процедур.
Организация работы администратора
Когда все задачи администраторов разложены по полочкам, возникает вопрос: а перед кем администраторы отчитываются за выполнение своих задач? Мне довелось видеть множество самых разных организационных диаграмм для каждого типа администраторов. Я предпочитаю централизованную группу администраторов БД, выполняющую поддержку, разработку и анализ БД. Я также видел проекты, где администраторы БД отчитывались перед группой технической поддержки (как правило, это те же самые лю- ди, которые занимаются поддержкой серверов под управлением Windows). Мне такая модель не нравится, поскольку ей присуще разделение администраторов на программистов и пользователей. Следствием такого разделения может быть ситуация, когда администратор рабочей станции спрашивает администратора-программиста: «во имя всего святого, как мне все это запустить в эксплуатацию?»
Мне приходилось видеть и более противоречивые модели, где ответственными администраторами были администраторы-разработчики. Оказалось, что этот тип администраторов БД отчитывается перед организацией разработчиков, что лишь расширяет пропасть между специалистами по поддержке и разработчиками. Эти две группы администраторов БД должны взаимодействовать и постоянно снабжать друг друга отзывами о текущей работе и о том, что администратор рабочей станции видит в серверной комнате.
Майкл Р. Хоутэк (Michael R. Hotek)
Сегодня многие пользуются новым синтаксисом SQL для внедрения умолчаний (default), ограничений (check) и внешних ключей (foreign key) непосредственно в таблицы.
Теперь выполнить эту операцию через определение таблицы даже легче, чем с помощью графического интерфейса Enterprise Manager. Однако у такого подхода есть один недостаток: он не позволяет извлечь определения ограничений и умолчаний. Представьте: вам необходимо выполнить какую-то работу по обслуживанию БД новой компании или клиента. Начав осваиваться с содержимым этой БД, вы тут же испытали потрясение, обнаружив, что она состоит более чем из 700 таблиц. Чтобы как-то разобраться с ними, нужно сначала хотя бы с некоторыми поработать. В конце концов все упирается в умолчания. Команда Defaults в Enterprise Manager показала лишь несколько определений умолчания. Но известно, что умолчаний больше, чем показывает Enterprise Manager. После запроса к таблице sysobjects становится ясно, что их число превышает 250. Что же делать? Многие запускают старый добрый текстовый процессор или достают лист бумаги, и начинают одно за другим выписывать все определения умолчаний. Тут возникает еще одна проблема. Как узнать, какое определение к какому столбцу относится? Выяснить это с помощью Enterprise Manager практически невозможно. Здесь приходит на ум одно из самых замечательных высказываний из когда-либо мной услышанных. Оно прозвучало из уст моего учителя математики: «лучший математик — это математик, недостаточно ленивый, чтобы игнорировать свою работу, но достаточно ленивый, чтобы найти способ облегчить ее…». Будучи человеком ленивым, я, несомненно, хотел бы, чтобы большую часть работы или даже всю сделал за меня компьютер. В конце концов, для этого они и созданы! Так что вопрос на 10 долларов: как найти все определения умолчания и получить согласованный список умолчаний БД вместе с их определениями? Ответ заключается в тех же системных таблицах. Но все не так просто.
Санхай Агравал (Sanjay
Agrawal)
Сурахит Чодхури (Surajit Chaudhuri)
Любор Коллар (Lubor Kollar)
Вайвек Нарасайа (Vivek Narasayya)
Здесь представлен мастер Index Tuning Wizard из Microsoft SQL Server 2000, который, анализируя предоставленный пользователем образец рабочей нагрузки, упрощает задачу выбора индексов для таблицы и, при необходимости, генерирует сценарии для создания выбранных индексов. Мастер поддерживает различные режимы для настройки как индексов, так и индексированных представлений.
подбирать индексы и индексированные представления так сложно...
Определение набора индексов, подходящего для конкретной СУБД, — задача не из легких. В БД можно создать множество простых и составных индексов, но механизмы использования индексов для обработки запросов сложны. Количество индексов, принципиально возможных в какой-либо БД, очень велико, а количество индексированных (материализованных) представлений для той же БД — и того больше. Для обработки запроса может использоваться представление, основанное на любом подмножестве таблиц, на которые ссылается запрос. Более того, для любого подмножества используемых запросом таблиц можно определить индексированное представление с любым подмножеством условий, определенных для этого подмножества таблиц в запросе. На самом деле число возможных индексов еще больше, поскольку в индексированном представлении могут присутствовать сгруппированные столбцы и выражения с агрегированием (например SUM). Наконец, подобно таблице, в представлении можно определить один кластерный и несколько некластерных индексов.
Индексы и индексированные представления нельзя выбирать отдельно друг от друга, поскольку присутствие индекса может сделать индексированное представление более привлекательным для оптимизатора и наоборот. Игнорирование подобных взаимодействий снижает качество рекомендаций мастера. Более того, для исполнения запроса могут быть полезны и индексы, и индексированные представления, поэтому выбор одних без учета других может привести к выдаче избыточных рекомендаций, влекущих за собой рост издержек на хранение и обновление. Наконец, при настройке физической структуры БД приходится искать компромисс между требованиями, обеспечивающими повышение производительности различных запросов и модификаций, которые должна поддерживать СУБД. Таким образом, поиск подходящей физической структуры тоже является трудной задачей.
В Microsoft SQL Server 2000 всех этих проблем можно избежать, воспользовавшись мастером ITW (Index Tuning Wizard), который рекомендует верное сочетание индексов и индексированных представлений для обработки данного набора запросов и модификаций. Принимать решения мастеру помогает анализ статистики использования и консультации с обработчиком запросов, что позволяет оценить потенциальную выгоду использования индексов и индексированных представлений.
Кэйлин Дилани (Kalen Delaney)
Сервер может по-разному обновлять строки в таблицах, автоматически и незаметно для пользователя выбирая для каждой операции самую быструю стратегию.
Для выбора стратегии SQL Server определяет количество обновляемых строк, способ обращения к ним (использование сканирования или индекса, во втором случае — еще и вид индекса), а также выявляет, будут ли обновлены ключи индекса. В SQL Server 7.0 обновление осуществляется двумя способами: «на месте» (update in-place) или путем удаления с последующей вставкой. Обновлением «на месте» называют такое обновление, при котором SQL Server меняет последовательность байтов в строке, не перемещая данные.
В SQL Server 7.0 обновлением данных могут управлять как обработчик запросов, так и механизм хранения. Вопрос о том, который из них управляет процессом, актуален не только для обновления, но и для других операций по модификации данных.
Более ранние выпуски SQL Server (до 7.0) могли выполнять как немедленное (прямое), так и отложенное обновление. Часто «прямое» обновление ошибочно отождествляют с обновлением «на месте». В результате делается вывод, что для отложенного обновления, в отличие от обновления «на месте», необходимо переместить строку. На самом деле, «отложенное» означает, что обновление осуществляется в два прохода. При первом для хранения информации используется журнал транзакций, в котором SQL Server регистрирует все выполняемые им изменения, помечая их как NO-OP. Эта пометка означает, что, хотя операция не была выполнена, запись в журнале сделана. Во время второго прохода SQL Server повторно считывает журнал и выполняет все зарегистрированные в нем изменения. Кроме того, более ранние выпуски SQL Server при перемещении каждой строки обновляли все некластерные индексы сведениями о ее новом местонахождении. Поскольку все изменения, включая изменения некластерных индексов, приходилось регистрировать дважды, отложенные операции интенсивно работали с журналом. До сих пор отложенное обновление является одним из самых медленных видов обновлений в SQL Server 6.x.
В SQL Server 7.0 отложенных обновлений нет. SQL Server выполняет все обновления в прямом режиме, не используя журнал транзакций для промежуточного хранения информации. Но слово «прямой» вовсе не означает, что обновление происходит «на месте». Помимо этого, в SQL Server 7.0 из-за особого способа сопровождения некластерных индексов издержки при перемещении строк невелики, даже если в таблице существует несколько некластерных индексов.
Майк Поуп (Mike Pope)
В статье описано, как с помощью системы разработки Microsoft Visual InterDev Web создавать запросы с параметрами и динамические запросы к БД.
Рассматриваются следующие вопросы:
• привязка данных с помощью компонента Recordset DTC (Design Time Component);
• передача параметров запросу;
• динамическое создание операторов SQL.
При разработке Web-страницы, использующей привязку данных, часто бывает возможно «подогнать» запрос к БД под структуру доступных данных лишь в период выполнения. Например, можно создать Web-страницу, выводящую имена сотрудников данного отдела. При запросе этой страницы пользователь вводит (или выбирает) нужный отдел. Далее можно использовать введенную информацию для построения корректного запроса к БД и вывода результатов.
Обычно эта задача решается с помощью запросов с параметрами (parameterized queries), которые могут быть двух типов.
• хранимые процедуры, которые практически всегда принимают какой-либо параметр и возвращают результаты запроса.
• операторы SQL с заполнителями (например знаками вопроса), которые в период выполнения заменяются значениями, вводимыми пользователем. Такой оператор может иметь следующий вид:
SELECT emp_id, emp_lname FROM employees WHERE dept_id = ?
Элемент управления (компонент) периода разработки (design-time control, DTC) Recordset из Visual InterDev 6.0 поддерживает запросы с параметрами для многих БД (но не для всех, в частности, не для Microsoft Access). Эти запросы также не поддерживаются для привязки данных на стороне клиента.
Третий способ «подгонки» запросов под условия периода выполнения — создание запросов «на лету» (что мы будем называть динамическими запросами [dynamic queries]). Например, можно создать «скелет» оператора SQL следующего вида:
SELECT emp_id, emp_lname FROM employees
Затем на основе введенной пользователем информации можно добавить конструкцию WHERE и исполнить запрос.
(Возврат на основную страницу)