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

1.1 Инсталляция программного обеспечения

Администраторы баз данных должны участвовать не только в инсталляциях SQL Server, но в инсталляциях операционной системы (ОС) и другого программного обеспечения. Он должен проверять, чтобы опции были установлены правильно, а ненужные компоненты не были инсталлированы и сконфигурированы. Кроме инсталляции ОС или помощи при её инсталляции администратор баз данных отвечает за правильную инсталляцию SQL Server 2000. Прежде чем приступать к инсталляции SQL Server 2000 необходимо выполнить некоторые подготовительные операции. Эту подготовку можно разделить на три фазы[6, С.50]:

Проверка аппаратного обеспечения.

Подготовка программного обеспечения.

Конфигурирование учетных записей служб SQL Server 2000.

На рисунке Б.1 приложения Б приведен список минимальных и рекомендуемых требований к аппаратной части компьютера Мамаев, Е. Microsoft SQL Server 2000. Наиболее полное руководство [Текст] Е. Мамаев / С.Пб.: «БХВ-Петербург», 2005 г. С. 51, выдвигаемых SQL Server 2000. Рекомендуемые требования приведены из расчета на небольшие системы. При работе с большими объемами данных эти показатели вырастают на несколько порядков. Например, редакция SQL Server 2000 Enterprise Edition допускает использование серверов с 32 процессорами и объемом памяти до 64 Гбайт. Приведенные в таблице цифры касаются требований самого SQL Server 2000 без учета требований предъявляемых ОС и прочим ПО. Эти моменты следует обязательно учесть при выборе компьютера, на который будет инсталлироваться SQL Server 2000.

Следующий шаг подготовки к инсталляции SQL Server 2000 это выбор и подготовка программного обеспечения. Первым этапом подготовки программного обеспечения является установка ОС, различные редакции SQL Server 2000 предъявляют разные требования к ОС в таблице 1 приложения В приведен перечень соответствий редакции SQL Server и ОС. При установке SQL Server 2000 на компьютер под управлением операционной системы Windows NT Server требуется установка Service Pack версии 5.0 или более поздней. При размещении SQL Server 2000 на компьютере с операционной системой Windows 2000 или более поздней не требуется устанавливать никакого дополнительного программного обеспечения. В SQL Server 2000 добавлена поддержка технологии XML. Однако доступ к данным с использованием этой технологии осуществляется средствами Microsoft Internet Information Server (IIS). Поэтому, если предполагается обеспечить доступ к данным посредством технологии XML, следует дополнительно установить Microsoft Internet Information Server, а это налагает дополнительные требования к ресурсам компьютера.

Последний этап подготовки к установке заключается в создании учетных записей пользователей, из-под которых будут запускаться службы SQL Server. В принципе можно не создавать новые учетные записи, а использовать уже существующие, например, администратора домена. Более того, учетная запись локальной системы задается при установке операционной системы, и создавать ее не нужно. Каждая служба Windows NT и Windows 2000 может запускаться под своей собственной учетной записью. Служба будет иметь права доступа, предоставленные администратором учетной записи. Для запуска служб SQL Server 2000 используются три типа учетных записей [6, С.53]:

локальная система;

локальный пользователь;

пользователь домена.

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

локальная установка;

удаленная установка;

автоматическая установка.

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

Проектирование системы составляет основную долю мероприятий по инсталляции, ведь тщательное проектирование системы SQL Server позволит вам избежать дорогостоящих простоев, вызванных как реорганизацией системы, так и переинсталляцией SQL Server с другими настройками, а так же сэкономит средства, затраченные на приобретение программного обеспечения. К наиболее важным факторам, влияющим на проектирование системы, относятся требования к уровню обслуживания. Эти требования обычно формулируются в соглашении об уровне обслуживания (SLA, service level agreement) Гарсиа, М. Ф. Microsoft SQL Server 2000. Справочник администратора. [Текст] /М. Ф. Гарсиа, Дж. Рединг, Э. Уолен, С.А. ДеЛюк / - Пер. с англ. - М.: «Эком» , 2002 г. С. 82. В соглашении об уровне обслуживания включаются такие условия как: производительность - спецификация минимально доступной производительности системы, мощность - классифицируется по различным категориям, таким как мощность места на диске, мощности пользователей, мощности сетевых соединений и т.д., обеспечение работоспособности - спецификация утверждающая, что система должна быть доступна для пользователей в некоторые заранее определенные периоды времени. Еще одной важной частью проектирования является проектирование размещения базы данных. Под этим надо понимать физическое размещение журналов транзакций и файлов данных. Эта задача - одна из самых важных при проектировании системы, потому что изменить принятые ранее решения, относящиеся к размещению, будет очень сложно.

1.2 Конфигурирование аппаратуры и программного обеспечения

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

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

Основой подсистемы ввода-вывода являются дисковые накопители. Дисковые накопители, называемые также «жесткие диски» с точки зрения производительности являются, чуть ли не самой медленной подсистемой компьютера. На скорость обмена данными в этой подсистеме влияет много факторов. Учитывая эти факторы, администратор, конфигурируя подсистему ввода-вывода, должен знать, что время необходимое для выполнения операции ввода-вывода представляет собой сумму длительности исполнения следующих этапов[4, С.135]:

времени, необходимого для поиска нужной дорожки,

задержки вращения,

времени, необходимого электронным схемам для передачи данных с дискового накопителя на его контроллер,

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

При проектировании системы ввода-вывода администратор должен тщательно спланировать состав и настройку подсистемы ввода-вывода, так как настройка этой подсистемы связана с мощность. Планирование мощности имеет две формы: предварительное и последующее. В задачи предварительного планирования мощности, известного также под названием планирование состава системы (sizing), входит прогнозирование требований к аппаратуре, при соблюдении которых система сможет исполнять необходимую работу в заданные сроки Там же. С. 125. На архитектурах «клиент-сервер» и технологии реляционных баз данных коем и является наш SQL Server выросла потребность в предварительной оценке размера системы и предварительном планировании мощности. Предварительное планирование мощности серверов с применением метода моделирования это долгий и дорогой процесс и себе его могут позволить только крупные компании, поэтому для 90% точности планирования проще использовать исторический опыт и общие знания об использовании системы, а также некоторые простые расчеты. К примеру, для расчета кэша можно воспользоваться формулой:

размер кэша = (размер блока кэша) х (количество блоков в кэше) Там же. С. 138

для расчета минимального объема памяти, необходимого для системы:

минимальная память = (системная память) + (пользовательская память) + (память процесса базы данных) Там же. С. 138

Проектируя или принимая участие в проектировании системы, администратор должен руководствоваться также и требованиями отказоустойчивости системы, и её масштабируемости. Также как и инсталляция, конфигурирование должно быть тщательно и подробно задокументировано.

1.3. Документирование

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

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

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

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

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

Для системных администраторов, администраторов баз данных и системных операторов можно завести по отдельному файлу. Сотрудники из каждой категории администраторов должны иметь возможность изменять свой тип файла-журнала, но все они должны иметь возможность просматривать любые типы журналов.

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

1.3.1 Документация о конфигурации

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

Конфигурация аппаратуры. Подробные записи о том, какая аппаратура у вас имеется, как она сконфигурирована, и информация обо всей добавленной аппаратуре (например, о добавленных жестких дисках или о памяти).

Программные компоненты. Подробные записи о том, какие программные компоненты были добавлены в систему и как была сконфигурирована каждая из этих компонент. Жизненно важны сведения о том, какие были установлены подкомпоненты и какие настройки (опции) были заданы.

Конфигурация базы данных. Эта информация должна содержать компоновку и схему базы данных (database layout And schema), имена и местоположения всех файлов данных, сведения о том, к каким группам относятся те или иные файлы, и сведения о том, как были созданы группы файлов Там же. С. 38. Эта информация позволит вам выяснить, какие именно группы файлов были потеряны при отказе массива дисков.

Сведения о настройке программного обеспечения. Эта информация должна содержать сведения обо всех параметрах конфигурации системы и базы данных. При каждом изменении настроек здесь нужно регистрировать все новые настройки.

1.3.2 Системный журнал

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

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

Изменения системы. Администратор баз данных должен записывать все изменения, произошедшие с аппаратурой, с операционной системой и с системой базы данных. Записи должны следовать в хронологическом порядке и должны быть полными (но не содержать несущественных подробностей).

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

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

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

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

1.3.3 Документация о структуре системы

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

1.3.4 Планы обычного технического обслуживания

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

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

1.3.5 Планы восстановления после аварий

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

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

Те же системы, для которых требуется более надежное обеспечение непрерывной работы, нуждаются в решениях с большей отказоустойчивостью (например, можно запустить службы MSGS - Microsoft Cluster Services). Для систем, простой которых принесет миллионные убытки, вы должны реализовать более объемлющие решения. Эти решения обычно подразумевают создание резервной системы в другом географическом регионе страны, благодаря чему работа не прекратится даже в случае природной катастрофы. Резервные системы могут обеспечивать работоспособность даже при выходе из строя основного центра обработки данных на дни и недели. Такие типы аварийных планов должны документироваться наиболее тщательно, чтобы каждый техник смог осуществить перенос работы на резервный сервер.

2. Безопасность SQL Server 2000

Администратор баз данных также отвечает за безопасность системы, он должен следить за защитой системы и в случае несанкционированного доступа реагировать в соответствии с должностной инструкцией. Безопасность системы начинается с управления пользователями. Управление пользователями и системой безопасности в среде Microsoft SQL Server 2000 является одной из наиболее характерных задач администратора баз данных[10].

инсталляция программный мониторинг доступ

2.1 Система безопасности SQL Server 2000 и разграничение доступа

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

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

Из вышесказанного следует, как важно правильно спроектировать права доступа пользователей к базам данных.

2.1.1 Архитектура системы безопасности SQL Server 2000

Система безопасности SQL Server 2000 базируется на пользователях и учетных записях. Пользователи проходят два этапа проверки системой безопасности.

На первом этапе пользователь идентифицируется по имени учетной записи и паролю, т.е. проходит аутентификацию. Если данные введены правильно, пользователь подключается к SQL Server. Подключение к SQL Server, или регистрация, не дает автоматического доступа к базам данных. Для каждой базы данных сервера регистрационное имя (или учетная запись - login) должно отображаться в имя пользователя базы данных (user).

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

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

На уровне сервера система безопасности оперирует следующими понятиями: аутентификация, учетная запись, встроенные роли сервера .

На уровне базы данных используются такие понятия, как: пользователь базы данных, фиксированная роль базы данных , пользовательская роль базы данных, роль приложения .

SQL Server 2000 поддерживает два метода аутентификации: средствами Windows NT/2000, смешанный режим аутентификации[10, С. 83].

При аутентификации Windows NT подлинность пользователя проверяется операционной системой. Операционная система работает с учетными записями, которые содержат все данные о пользователе, включая его имя, пароль, членство в группах, каталог по умолчанию ит.д. Каждая учетная запись имеет уникальный идентификатор или, как его называют по-другому, идентификатор безопасности, с помощью которого пользователь регистрируется в сети. Доступ ко всем ресурсам сети производится на основе идентификатора учетной записи. Когда пользователь пытается получить доступ к ресурсу (в том числе к SQL Server 2000), операционная система ищет его уникальный идентификатор и сравнивает тип разрешенного доступа с типом запрашиваемого доступа. Если конфликтов нет, то доступ предоставляется. В этом случае сервер не проверяет пользователя, т.к. «знает», что пользователь уже прошел проверку и получил право работать в сети. Однако на доступ к самому серверу, базам данных и объектам внутри них сервер все равно выполняет проверку.

Смешанный режим аутентификации позволяет пользователям регистрироваться как средствами Windows, так и средствами SQL Server. На стороне сервера вся информация о пользователях хранится в системной базе master в таблице Syslogins. Для каждого пользователя указывается имя учетной записи, уникальный идентификатор SQL Server, пароль и другая информация. При попытке пользователя подключиться к серверу система безопасности потребует ввести имя учетной записи и ее пароль. Затем сравнит введенные данные с информацией, хранящейся в системных таблицах. Если данные совпадают, то доступ предоставляется. В противном случае пользователь получает сообщение об ошибке и соединение не устанавливается.

Смешанная аутентификация применяется клиентами, для которых недоступна регистрация средствами Windows, например, пользователями Novell NetWare, Unix и т.д. При подключении к SQL Server 2000 через Интернет регистрация в домене не выполняется, поэтому в данном случае также необходимо использовать аутентификацию SQL Server. Кроме того, аутентификация SQL Server необходима при работе сервера под управлением Windows 98.

2.1.2 Компоненты системы безопасности SQL Server 2000

Система безопасности SQL Server 2000 основывается на учетных записях, пользователях , ролях и группах (см. Приложение Е).

2.1.3 Администрирование системы безопасности SQL Server 2000

При установке SQL Server 2000 имеется возможность выбрать один из двух режимов аутентификации: средствами Windows; средствами Windows или средствами SQL Server 2000[10].

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

Во втором режиме системным администратором, входящим в роль sysadmin или securityadmin, должна быть создана и сконфигурирована учетная запись в SQL Server 2000 для каждого пользователя. Эта запись будет содержать собственное имя, имя экземпляра сервера и пароль. Две такие записи с именем BULTIN\Administrators и sa создаются автоматически, включаются также во встроенную роль сервера sysadmin, в результате системные администраторы получают полный доступ ко всем базам данных с именем пользователя dbo. Если функции системного администратора и администратора баз данных выполняют разные люди, следует исключить учетную запись BULTIN\Administrators. Запись sa не следует использовать, так как она предназначена для совместимости со старыми версиями SQL Server и для входа в сервер, если администратора баз данных создается отдельная учетная запись сервера sysadmin.

3 Резервное копирование и восстановление баз данных SQL Server 2000, мониторинг и аудит системы SQL Server 2000