SQL Server: Десятка главных секретов экспертов по SQL Server

За последние годы многие компании сократили размер своих ИТ-отделов. Многим администраторам баз данных приходится отвечать за работу большего числа баз SQL Server. Но хуже всего то, что часто в компании нет выделенного администратора базы данных — вольно или невольно эту работу делает кто-то другой. Иногда администратору базы данных приходится работать в авральном режиме, гася постоянно возникающие «пожары». Такая работа трудна, опасна и плохо совместима с нормальной жизнью. Никому не понравится находиться в постоянном напряжении и стрессе.

Один из выходов состоит в том, чтобы потратить немного времени на улучшение среды SQL Server чтобы ее можно было легче понимать и управлять ею. Основываясь на своем опыте работы консультантом по SQL Server, я предлагаю десять способов, которые позволят администратору базы данных SQL Server получить контроль над своей средой и снизить вероятность «пожаров». Список составлен в порядке увеличения важности совета.

10. Выполните инвентаризацию

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

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

Есть много инструментальных средств, позволяющих выполнить инвентаризацию SQL Server, — от простых утилит типа SQLPing3 и SQLRecon до Microsoft Assessment and Planning Toolkit и Quest Discovery Wizard.

9. Стандартизуйте конфигурации

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

Решение заключается в максимальной стандартизации конфигурации в плане имен дисков, вариантов конфигурации сервера, параметров настройки базы данных, параметров обслуживания базы данных и настройки защиты и т. п. В SQL Server 2008 появилась функциональность управления на основе политик, позволяющая определять и приводить в исполнение политики. Лара Руббелке (Lara Rubbelke), специалист по технологии SQL Server в Microsoft, также разработала каркас EPM (Enterprise Policy Management Framework), который позволяет легко реализовать эту функциональность на экземплярах SQL Server 2005 и SQL Server 2000. Загрузить EPM Framework можно с сайта CodePlex (www.codeplex.com). На рис. 1 показан пример отчета EPM Framework.

Рис. 1. Отчет Enterprise Policy Management Framework

8. Разберитесь с подсистемой ввода-вывода

Есть несколько обстоятельств, связанных с подсистемой ввода-вывода, которые могут затронуть ваши экземпляры SQL Server. Вы должны знать о них и их возможном влиянии.

• Работоспособность подсистемы ввода-вывода, а именно пропускная способность операций чтения-записи и размер дискового пространства. Подсистема должна справляться с пиковыми рабочими нагрузками и обладать достаточным запасом дискового пространства для роста объема данных. Выявляя узкие места подсистемы ввода-вывода и перемещая данные и/или журналы в другие ее части подсистемы ввода-вывода, можно более равномерно распределять нагрузку.
• Избыточность подсистемы ввода-вывода, то есть уровень RAID и способность создавать зеркальные резервные копии с чередованием и поддерживать какие-либо формы зеркального отображения или репликации (на уровне подсистемы ввода-вывода, а не SQL Server). Важно защитить данные и журналы от сбоев дисков и других возможных проблем. При этом всегда нужно найти компромисс:решение на основе RAID-10 обеспечивает лучшую избыточность, чем RAID-5, но оно дороже. За более подробной информацией отсылаю вас к «белой книге» «Physical Database Storage Design».
• Правильность конфигурации подсистемы ввода-вывода в смысле размера блоков чередования в RAID, размера кластеров в файловой системе NTFS и выравнивания разделов. Подробнее читайте в блоге запись «Are your disk partition offsets, RAID stripe sizes, and NTFS allocation units set correctly?».

7. Создайте собственный план обслуживания

Всякий раз, читая курсы по обслуживанию баз данных, я всегда начинаю с того, что говорю:«Нельзя просто запустить базу данных в производственной среде и уйти». Со временем индексы становятся фрагментированными, что ведет к снижению производительности. Статистические данные устаревают, что приводит к созданию плохих планов запросов и низкой производительности. Работа подсистем ввода-вывода может нарушаться, и никто не отменял потребности в регулярном резервном копировании.

Все эти проблемы решаются при наличии всеобъемлющего плана обслуживания, учитывающего особенности ваших баз данных. Нестандартный план намного лучше, чем универсальный, который не учитывает специфических потребностей вашей среды. В моей статье в журнале TechNet Magazine за август 2008 г.  «Лучшие советы по эффективному обслуживанию баз данных» рассказывается создание хорошего плана обслуживания. Создание собственного плана обслуживания лучше начать с всеобъемлющего и бесплатного сценария от Ола Халленгрен (Ola Hallengren). Именно его я рекомендую своим клиентам.

6. Позаботьтесь о защите своей системы

Очень важно потратить достаточно времени на активное обнаружение проблем с безопасностью, чтобы предотвратить нарушения защиты и не думать о них. В другой моей статье в журнале TechNet Magazine «Распространенные проблемы безопасности и решения SQL Server» перечислены 10 самых распространенных проблем безопасности и способы их решения. Также не забывайте устанавливать самые свежие исправления и выявлять уязвимости.

5. Дружите со своими разработчиками

Одна из главных точек напряженности в любом ИТ-отделе часто находится между командами администраторов баз данных и разработчиков. Эти две команды обычно не понимают приоритеты и заботы друг друга — от сроков разработки до решений в области проектирования SQL Server. Обычное дело — различное отношение к поведению и проблемам с производительностью, а также к обязанностям по развертыванию и поддержке.

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

4. Разработайте всеобъемлющую стратегию восстановления в случае аварий

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

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

Также нужно реализовать технологии, позволяющие своевременно узнать о возникновении проблем, таких как контрольные суммы страниц, проверки согласованности, уведомления Агента SQL и System Center Operations Manager. Эта инфраструктура восстановления поможет вам защитить данные за счет резервного копирования, доставки журналов, репликации и зеркального отображения базы данных, а в случае сбоев позволит перейти на резервную зеркальную систему или другой узел в кластере. Есть две «белых книги» Microsoft, которые могут помочь вам в этом: “High Availability with SQL Server 2008» и «Proven SQL Server Architectures for High Availability and Disaster Recovery».

3. Проверьте регулярные резервные копии

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

Более подробные сведения можно найти в двух моих статьях в журнале TechNet Magazine за 2009 г.: “Понимание резервных копий SQL Server» и «SQL Server: Восстановление после аварий с помощью резервных копий.”

2. Организуйте мониторинг и обеспечьте поддержку высокой производительности

Забота о производительности занимает большую часть рабочего времени администратора базы данных, но есть много способов упростить этот процесс:

• определите базовые уровни производительности, чтобы можно было увидеть, действительно ли меняется производительность;
• разбейте систему на отдельные части, чтобы можно было измерять производительность локально, исключив влияние внешних факторов или других подсистем;
• используйте методологию определения ожиданий и очередей, чтобы быстро и точно выявлять причины проблем с производительностью;
• выполняйте мониторинг системы, используя изоляцию отдельных компонентов, счетчики производительности и статистику ожидания. Так вы вовремя узнаете, когда производительность начнет ухудшаться. Используйте имеющийся в SQL Server 2008 сборщик данных (Data Collector) и Performance Dashboard — в SQL Server 2005;
• внедрите план обслуживания;
• тщательно спланируйте и реализуйте стратегию индексации, используя такие инструменты, как Помощник по настройке ядра СУБД (Database Engine Tuning Advisor, DTA), динамические представления (DMV) для определения недостающих индексов и оценки исп��льзования имеющихся индексов.

1. Знайте, где нужно искать информацию

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

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

Другой быстрый способ поиска помощи — сообщество SQL Server на Twitter. Разместите свой вопрос с тегом #sqlhelp, который отслеживают много экспертов по SQL Server (включая меня).

Посещайте посвященные SQL Server конференции, такие как ежегодная встреча PASS Community Summit, проводимый раз в два года семинар SQL Server Connections или более частые конференции SQL Saturdays. Следите за блогами, которые ведут специалисты SQL Server. Узнать, какие блоги наиболее активны и ценны, можно с помощью рейтинга блогов, который ведет обладающий званием MVP Томас ЛаРок (Thomas LaRock).

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

Связанные материалы

• SQL в вопросах и ответах Обслуживание журналов и индексов
• SQL в вопросах и ответах: Перенос, настройка производительности, резервное копирование и зеркалирование баз данных
• SQL в вопросах и ответах Советы по восстановлению поврежденных данных, советы по сжатию баз данных и многое другое