За последние годы многие компании сократили размер своих ИТ-отделов. Многим администраторам баз данных приходится отвечать за работу большего числа баз 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.
На рис. 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).
Может показаться, что этих рекомендаций слишком много и что они требуют слишком многого, но потратив достаточное время на их проработку, вы получите огромную выгоду. Ваши системы будут работать ровнее, работа будет организована намного лучше, а вы будете чувствовать себя увереннее, и вообще - вы станете более опытным администратором базы данных.