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

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

Один из выходов заключается в том, чтоб издержать малость времени на улучшение среды SQL Server чтоб ее можно было легче осознавать и управлять ею. Основываясь на собственном опыте работы консультантом по SQL Server, я предлагаю 10 методов, которые позволят админу базы данных 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.

SQL Server: 10-ка основных секретов профессионалов по SQL Server

Рис. 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. Проверьте постоянные запасные копии

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

Более подробные сведения можно отыскать в 2-ух моих статьях в журнальчике 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 в вопросах и ответах Советы по восстановлению покоробленных данных, советы по сжатию баз данных и почти все другое

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.