Sybase. Настольная книга администратора

Syb ase I

• Подробное изложение основных операций администрирования серверов Sybase Полезные подсказки, конкретные советы и неожиданные приемы, знание которых превратит вас из новичка в признанного корифея Идеальная настольная книга для администраторов сложных систем баз данных, состоящих из нескольких серверов • Рассматривается Sybase SQL Server версий 4.9.2, System 10 и System 11

Sybase НАСТОЛЬНАЯ

КНИГА

АДМИНИСТРАТОРА

Брайан

Хичкок

Издательство "Лори"

www.books-shop.com

Sybase DBA companion Brian Hitchcock Copyright 1997 All rights reserved Sybase Настольная книга администратора Брайан Хичкок Переводчик Дм.Григорьев Научный редактор А.Головко Корректоры Т.Килимник, И.Красненкова Верстка М.Алиевой Copyright © 1997 Prentice"Hall, Inc. A Simon & Schuster Company Upper Saddle River, New Jersey 07458 ISBN 0"13"652389"7 © Издательство "ЛОРИ", 2000

Изд. N : OAI (03) ЛР N : 070612 30.09.97 г. ISBN 5"85582"066"1 Подписано в печать 10.04.2000 Формат 84x108/16 Бумага офсет N1 Гарнитура Нью"Баскервиль Печать офсетная Печ.л. 28 Тираж 3200 Заказ N 2221. Цена договорная Издательство "ЛОРИ". Москва, ул. А. Живова, д. 10, стр. 1 Телефон для оптовых покупателей: (095)259"01"62 WWW.LORY"PRESS.RU Отпечатано с готовых диапозитивов в ООО ПФ <<Полиграфист>>, 160001, г. Вологда, ул. Челюскинцев, 3. Тел.: (8172) 72+55+31, 72+61+75, факс 72+60+72

www.books-shop.com

Содержание

1

SQL Server: общий обзор Введение Версии SQL Server SQL Server 4.9.2 SQL Server System 10 SQL Server System 11 Microsoft SQL Server 4.2 и 6.0 Будущие версии SQL Server Основные концепции РСУБД Реляционные базы данных Язык структурированных запросов SQL Объекты баз данных Значения NULL Транзакции Восстановление после сбоев Блокировка Многопользовательская среда Концепции РСУБД и SQL Server 4.9.2 Сервер Базы данных Сопровождение сервера Масштабируемость Производительность Тиражирование данных SQL Server System 10 Сервер архивации (Backup Server) Совместимость с предыдущими версиями Пользовательские роли Новые системные базы данных Обеспечение безопасности SQL Server System 11 Многопроцессорные конфигурации Именованные кэш+буферы Настройка размеров блоков ввода+вывода Журнал транзакций Сегментированные таблицы Мониторинг и настройка сервера Совместимость с предыдущими версиями

2 2 3 3 3 4 4 5 5 5 6 7 8 8 9 10 10 10 20 23 36 40 44 45 45 46 46 47 47 47 48 48 48 48 50 50 50

www.books-shop.com

2

Будущие версии SQL Server Масштабируемость Производительность Поддержание работоспособности Поддержка принятия решений Распределенные базы данных Домыслы и рассуждения Заключение Возьмите на заметку

51 51 51 51 51 52 52 52 52

Преимущества System 11

53

Достоинства System 11 Масштабируемость Именованные кэш+буферы данных Конфигурирование сервера Администрирование сервера Стоит ли торопиться? Новые возможности System 11 Возможности, так и не появившиеся в System 11 Заключение 3

Масштабируемость System 11 Множественные сетевые ядра (MNE) System 11 Поисковые ядра SQL Server System 11 и сетевой ввод+вывод Сеансы работы пользователей и серверные ядра Оптимальное количество серверных ядер Диспетчеризация ядер в SQL Server Сервер на однопроцессорных вычислительных платформах Журнал транзакций System 1 1 . . Пользовательские кэш+буферы журнала повтора Буферная область журнала повтора Старейшая незавершенная транзакция Особенности работы с журналами повтора Формат команд работы с ULC+буфером и примеры их использования Управление блокировками в System 11 "Грязное чтение" Конфигурация режима повышения уровня изолированности Диспетчер параллельных блокировок

4

54 54 54 54 54 54 55 56 56 57 ..58 58 59 60 60 61 61 61 61 63 63 64 64 69 69 70 70

Именованные кэш*буферы System 11

71

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

72 72 72 74 75 76 76 77 79

www.books-shop.com

Выбор объектов, связываемых с именованными буферами данных Формат команд работы с именованными буферами данных и примеры их использования Диспетчер кэш+буфера и большие блоки ввода+вывода Буферные области В каких ситуациях следует использовать большие блоки ввода+вывода? Создание буферных областей с большими блоками ввода+вывода Особенности внутренней организации буферных областей Использование больших блоков ввода+вывода Формат команд работы с буферными областями и примеры их использования Оптимизация запросов и диспетчер кэш+буфера System 11 Введение Упреждающее считывание в кэш+буфер Считывание в буфер с немедленным удалением Оптимизация запросов и стратегия использования кэш+буфера Стратегии использования кэш+буфера — теория и практика Другие методы улучшения оптимизации запросов 5

6

Настройка конфигурации SQL Server System 11

80 80 80 80 82 83 84 84 85 98 98 98 98 99 100 100 101

Конфигурационный файл Преимущества использования конфигурационных файлов Конфигурационные файлы и восстановление сервера после сбоев Использование конфигурационных файлов Конфигурационные файлы и именованные кэш+буферы Структура конфигурационного файла Сообщения об ошибках в конфигурационном файле при запуске сервера Процедура SP_CONFIGURE Использование sp_configure в предыдущих версиях сервера Необходимые полномочия Формат команды sp_configure Сообщения об ошибках при чтении конфигурационного файла Подкоманда read: осторожно! Структура вывода команды sp_configure Вывод sp_configure Подкоманды read и verify команды sp_configure Выводимые значения параметров Совместимость с предыдущими версиями Процедура sp_configure и выдача сообщений в журнал регистрации ошибок Процедура sp_configure и выдача сообщений в журнал регистрации ошибок при работе с конфигурационными файлами Заключение: общие рекомендации по конфигурированию сервера

128

Администрирование SQL Server System 11

129

Дампы баз данных , Загрузка дампов баз данных версии System 10 Автономное и оперативное состояние баз данных Формат команд, вызывающих переключение базы данных между автономным и оперативным режимом, и примеры их использования

102 104 105 105 106 106 108 111 111 113 113 114 115 115 116 124 124 125 125 125

130 130 131 133

www.books-shop.com

7

8

Процедура sp_sysmon Введение Общий обзор Системные таблицы sysattributes syspartitions syslogshold Сегментирование таблиц Сегментирование таблиц: детали Когда используется сегментирование таблиц Создание сегментированной таблицы Ограничения Практическое использование

136 136 136 136 136 137 137 137 138 138 138 139 139

Системные базы данных SQL Server

141

Системные базы данных База данных sybsystemprocs База данных sybsecurity База данных master База данных master и серверное устройство master Выбор размера серверного устройства master Сегмент журнала транзакций (logsegment) базы данных master Зеркальное отображение устройства master и его название Команда disk init и серверное устройство master Устройство master и серверные устройства, используемые по умолчанию Загрузка дампа базы данных master Перенос устройства master в раздел диска большего размера Очистка содержащейся в базе данных master информации о конфигурации сервера Системные базы данных и серверные устройства Зеркальное отображение системных баз данных

142 142 142 143 143 143 144 144 145 146 147 147 149 150 150

Внутренняя организация сервера

151

Введение Особенности различных версий SQL Server SQL Server 4.9.2 SQL Server System 10 SQL Server System 11 Обзор процесса установки сервера Нумерация портов серверной машины Названия серверных устройств Дисковые накопители Стандартная схема разбиения дисков Дисковые разделы в операционных системах компьютеров фирмы Sun Разбиение дисков различного размера Форматированные и неформатированные разделы дисков . . . .

152 152 152 152 153 153 153 154 154 155 156 157 157

www.books-shop.com

Логические дисковые устройства SQL Server Разбиение дисков на разделы Контроллеры дисков Распределение компонентов баз данных по дискам и дисковым контроллерам Журнал транзакций Размещение нескольких баз данных на одном сервере Размещение системных баз данных Инициализация серверных устройств Сегменты баз данных Зачем требуются сегменты Сегмент журнала транзакций Большие объекты должны помещаться в отдельном сегменте Сегменты и команда сервера create database Сегменты и команда сервера alter database Создание сегмента, определенного пользователем Сегменты и планирование емкости устройств Расширение пространства пользовательского сегмента Заключительные замечания по сегментам баз данных Размещение журналов транзакций Размещение журнала транзакций на отдельном серверном устройстве Совместное размещение журнала транзакций с другими сегментами базы данных Определение оптимального размера журнала транзакций Зеркальное резервирование серверных устройств Расширение баз данных, находящихся на зеркальных устройствах При зеркальном резервировании отображаются устройства, а не отдельные базы данных Выбор конфигурации устройств и сегментов сервера Почему не следует торопиться расширять пространство базы данных Заключение 9

Восстановление сервера после сбоев Введение Особенности различных версий SQL Server SQL Server 4.9.2 SQL Server System 10 SQL Server System 11 Выбор стратегии защиты от сбоев зависит от стоимости простоя сервера Отсутствие журнала транзакций — отсутствие базы данных Восстановление баз данных производится с точностью до отдельной транзакции Использование резервного сервера В базе данных master нет места пользователям! Использование команды dbcc Зеркальное резервирование данных

158 158 163 166 166 167 168 169 175 175 175 176 176 177 178 179 181 181 183 183 183 184 187 200 200 202 204 205 207 208 208 208 209 209 209 210 218 218 223 . 223 228

www.books-shop.com

Архивация данных Чем больше серверных устройств, тем лучше . . Общие рекомендации по восстановлению сервера Сервер архивации (Backup Server) Дампы баз данных Дампы журналов транзакций Логические дампы и программа SQL BackTrack компании DataTools Типы сбоев и порядок восстановления сервера 10 Производительность сервера и его настройка Введение Особенности различных версий SQL Server SQL Server 4.9.2 SQL Server System 10 SQL Server System 11 Работа с процедурой sp_sysmon Подробнее о работе с sp_sysmon Основные компоненты выдачи sp_sysmon. Загрузка ядра сервера (Kernel Utilization) Управление задачами (Task Management) Управление транзакциями (Transaction Management) Управление блокировками (Lock Management) Управление кэш+буфером данных (Data Cache Management) Управление кэш+буфером процедур (Procedure Cache Management) Управление контрольными точками (Recovery Management) Управление дисковым вводом+выводом (Disk I/O Management) Выдача sp_sysmon Рекомендации по конфигурированию кэш+буферов Не злоупотребляйте теорией Некоторые практические рекомендации Индексы и запросы Распределение сегментов баз данных по серверным устройствам Распределение таблицы по нескольким устройствам Архивация данных Сервер поддержки принятия решений Стандартный набор тестовых транзакций SQL Monitor Встроенные средства анализа производительности SQL Server Настройка сервера независимо от приложений Сокращение периодов недоступности сервера 11 Планирование конфигурации SQL Server Введение Особенности различных версий SQL Server Информационная система в целом Отдельный сервер баз данных

229 229 230 231 232 234 235 238 243 244 244 244 244 244 244 245 246 247 248 248 249 249 251 251 251 252 258 259 260 262 264 265 265 267 269 270 272 274 276

277 278 278 278 281

www.books-shop.com

Реальный пример: информационная система в целом Реальный пример: отдельный сервер баз данных Планирование конфигурации глобальной информационной системы 12 Эксплуатация SQL Server

286 291 295 297

Введение 298 Особенности различных версий SQL Server 298 SQL Server 4.9.2 298 SQL Server System 10 298 SQLServer System 11 298 Пороги 298 Файл интерфейсов 301 Преобразование файла интерфейсов SunOS в формат системы Solaris 304 Файл интерфейсов в формате Solaris 304 Преобразование строки файла интерфейсов Solaris в формат SunOS 305 Преобразование строки файла интерфейсов SunOS в формат Solaris 305 Файл интерфейсов в формате SunOS 305 Сетевое взаимодействие серверов 306 Преобразование командных файлов SQL и выдачи утилиты defncopy в хранимые процедуры 308 Системная таблица sysusages . 308 Состав объектов сегмента базы данных 313 Журнал регистрации ошибок 314 Создание новых баз данных и эксплуатация сервера 322 Модификация системных таблиц SQL Server вручную 322 Команда bср 323 Свободное пространство базы данных 323 Ошибка 1105: переполнение журнала транзакций или другого сегмента базы данных 324 13 Установка и обновление SQL Server Введение Особенности различных версий SQL Server SQL Server 4.9.2 SQL Server System 10 SQL Server System 11 Установка SQL Server Подготовка к установке сервера Установка SQL Server System 11 Установка SQL Server System 10 Установка SQL Server 4.9.2 Основные операции после установки сервера Обновление SQL Server: общий обзор Введение Особенности различных версий SQL Server

329 330 330 330 330 330 330 331 338 342 342 343 348 348 348

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Руководство по установке, перечень особенностей текущей версии сервера и сопроводительное письмо к очередной EBF+версии Служба технической поддержки компании Sybase Возможные риски при переходе на новую версию Обновление EBF+версии. Переход на новую главную версию SQL Server Подготовка перехода с SQL Server 4.9.2 на System 11 (либо System 10) Обновление SQL Server 4.9.2 на System 11 (либо System 10) Основные операции после перехода от SQL Server 4.9.2 к System 11 (или System 10) Возврат к SQL Server 4.9.2 после его неудачного обновления на System 10 или 11 Обновление SQL Server 4.9.2 на сервер System 10 Полное обновление SQL Server System 10 до версии System 11 Обновление SQL Server System 10 до System 11 путем загрузки дампов баз данных System 10 14 Командные файлы Командные файлы общего назначения Особенности различных версий SQL Server SQL Server 4.9.2 SQL Server System 10 SQL Server System 11 Выдача дампов журналов транзакций баз данных (dumplog) . . . Запись нескольких дампов баз данных SQL Server 4.9.2 на одну ленту (dumpdb_492) Внимание! Загрузка дампов баз данных в SQL Server 4.9.2 (loaddb_492) Обновление статистики оптимизатора по всем таблицам сервера (update_statistics_all_tables) Построение командного файла создания баз данных (dump_db_create) Выполнение dbcc+проверок (checkdb) Выдача содержимого системных таблиц (dump_systables) Хранимая процедура, генерирующая командный файл создания базы данных (p_dbcreate) Проверка состояния зеркальных пар устройств (хранимая процедура p_mirror) Проверка использования дискового пространства серверного устройства (хранимая процедура p_devspace) Построение списка всех сегментов баз данных, находящихся на всех устройствах сервера (хранимая процедура p_servermap). Выдача дампов баз данных (dumpdb) Загрузка баз данных (loaddb) Отслеживание хода загрузки дампа базы данных (хранимая процедура p_dbload) Командный файл запуска сервера Командные файлы эксплуатации SQL Server System 11 Дампы баз данных System 11 (dump_listof_dbs)

349 349 350 350 351 352 356 359 363 365 365 366 367 368 368 368 369 369 369 372 372 374 377 380 381 382 384 386 386 388 390 393 393 394 395 395

www.books-shop.com

Выдача дампов журналов транзакций (logdump_listof_dbs) 398 Принудительная очистка журнала транзакций (trunclog_listof_dbs) . 401 Удаление старых файлов (remove_old_files) 404 Обновление статистики оптимизатора (update_listof_dbs) 406 Выполнение dbcc+проверок (dbcc_listof_dbs) 408 Поиск сообщений об ошибках в журнале регистрации ошибок SQL Server (scan_errorlog) 412 Выдача конфигурации сервера (dump_server_config) 413 Контроль активности пользователей (monitor_report) 416 Запуск процедуры sp_sysmon (execute_sp_sysmon) . . . . . . . . 417 Автоматический перезапуск сервера 419 Строки описания командных файлов в таблице crontab 419

www.books-shop.com

www.books-shop.com

Предисловие Проблемы, обсуждаемые в книге, близко касаются каждого занимающегося поддержкой сер" веров баз данных Sybase. На ближайших нескольких страницах мы рассмотрим следующие во" просы: Назначение книги Кому предназначена эта книга Что нужно знать и как правильно читать эту книгу Что вы узнаете из этой книги Используемые обозначения Основные термины Назначение книги Основная цель книги — помочь всем, кто отвечает за нормальное функционирование SQL Server System 11, System 10 и 4.9.2, в их практической работе. Кому предназначена эта книга Как видно из названия, книга в первую очередь адресована администраторам баз данных. Одна" ко она окажет несомненную пользу и руководителям фирм, планирующим расширение своих ин" формационных систем, а также руководителям финансовых служб компаний, в обязанности которых входит оплата труда персонала и оборудования, требующегося для этих систем. Воз" можно, начинающим администраторам баз данных будет интереснее познакомиться с богатым практическим опытом автора, а детально рассмотренные процедуры выполнения конкретных операций позволят сэкономить немало времени даже высококвалифицированному администра" тору сервера. Предполагается, что читатель достаточно хорошо знаком с SQL Server компании Sybase и командами управления сервером. Поэтому полное описание формата использованных команд сервера не приводится. Книгу не следует рассматривать как учебник, предназначенный для первоначального знакомства с базами данных Sybase. Мы рады порекомендовать читателю пре" восходные вводные курсы Sybase и подчеркнуть, что в нашей книге подробно объясняются по" ложения лекционных материалов и руководств Sybase, а также приводятся важные дополнительные подробности. Что нужно знать и как правильно читать эту книгу Книга основана на опыте практической эксплуатации Sybase SQL Server на компьютерах фирмы Sun в операционной системе Solaris 2.x. Автор предпринял все от него зависящее, чтобы содер" жание книги в полной мере относилось и к максимально широкому кругу платформ, поддержи" ваемых Sybase SQL Server. В частности, описание сервера и конкретных процедур работы с ним

www.books-shop.com

применимо к каждому серверу Sybase, работающему в любой из версий операционной системы UNIX. Все случаи существенной связи изложения с особенностями операционной системы Sola" ris явно отмечены в тексте. Скорее всего, читателю не удастся немедленно воспользоваться всем материалом книги, и лишь некоторые ее разделы будут иметь непосредственное отношение к вашим текущим проб" лемам. Однако не стоит пренебрегать остальными частями книги — при серьезных сбоях серве" ра вы найдете в этой книге четкий и подробный перечень возможных способов локализации и устранения возникших проблем. Что вы узнаете из этой книги Содержащаяся в книге информация имеет самое непосредственное отношение к практиче" ской деятельности любого администратора баз данных, занимающегося сопровождением сер" вера баз данных Sybase. В некоторых разделах книги учитываются особенности системы Solaris. Подробное описание функций использованных команд дает читателю возможность легко подобрать эквивалентные команды практически для любой версии операционной систе" мы UNIX, поддерживаемой Sybase SQL Server. Материал всех разделов книги ориентирован на непосредственное практическое примене" ние. Рассматриваемые процедуры разбиты на последовательности конкретных действий, дета" льное изложение которых учитывает потребности администраторов баз данных любого уровня — от старшего администратора сервера до новичка. Книга позволит значительно уско" рить процесс обучения последнего, поскольку в ней подробно излагаются основные процедуры обеспечения работоспособности сервера. В книге встречаются основанные на практическом опыте автора описания реально имев" ших место ситуаций. Эти описания, отмеченные в тексте знаком ;") , призваны обратить внима" ние на материал соответствующего раздела, помогая читателю оценить вероятность возникновения аналогичных событий в своей системе баз данных и их возможные последст" вия. Подобные примеры наглядно демонстрируют ту высокую цену, которую порой приходится платить за пренебрежение представленными рекомендациями, кажущимися на первый взгляд слишком подробными и даже параноидальными. Катастрофические сбои с серверами баз данных имеют обыкновение происходить в разгар рабочего дня и нередко заканчиваются увольнением администратора сервера. Входящая в комплект Sybase SQL Server документация (и в том числе компакт"диски SyBooks и AnswerBase) отличается превосходным качеством. В ней подробно рассматривается эксплуа" тация отдельного сервера соответствующей версии. Однако при практической работе с различ" ными версиями SQL Server, их установке и особенно при переходе на новую версию сервера, читателю придется столкнуться с целым рядом проблем, не нашедших должного освещения в руководствах Sybase. Эти проблемы подробно рассматриваются в книге, которая по сути стано" вится связующим звеном между реальными информационными системами, одновременно со" держащими несколько серверов различных версий, и фирменной документацией Sybase, ориентированной на особенности отдельных версий SQL Server. Руководства Sybase дают ис" черпывающую информацию по особенностям любой команды каждой конкретной версии сер" вера, при этом они ни на йоту не позволяют приблизиться к пониманию особенностей практической эксплуатации крупных систем баз данных. По мере расширения информационной системы вашей компании читателю рано или позд" но придется познакомиться с семейством программных продуктов Sybase версии System 11. Независимо от того, будете вы устанавливать новый SQL Server System 11 или переводить су" ществующие серверы с SQL Server 4.9.2 или System 10 на System 11, в процессе установки SQL Server System 11 неизбежно появятся новые проблемы, вызванные большим числом новых возможностей этой версии сервера. Сервер System 11 значительно сложнее в установке, чем

www.books-shop.com

очередная EBF"версия вашего нынешнего сервера (компания Sybase регулярно исправляет ошибки, обнаруженные в поддерживаемых версиях SQL Server, внося необходимые изменения в программный код сервера и присваивая ему новый номер EBF"уровня, о чем мы будем говорить в дальнейшем). В книге подробно рассматривается процесс установки SQL Server версий 4.9.2, Sys" tem 10 и System 11, а также разбираются существенные различия между этими версиями. Реально существующие системы баз данных Sybase представляют собой нетривиальную ком" бинацию самых разных сочетаний аппаратных платформ, операционных систем, программно" го обеспечения промежуточного слоя (middleware) и т.д. В задачи автора не входило обсуждение всего спектра проблем, возникающих в системах, одновременно использующих оборудование и программное обеспечение многих фирм"производителей. В книге рассматрива" ются особенности эксплуатации систем баз данных, имеющих несколько серверов Sybase (раз" личных версий), работающих в операционной системе UNIX. Как отмечалось выше, большинство практических примеров относится к системе Solaris; однако мы старались по воз" можности избежать использования специфических средств этой системы и сделать изложение применимым к любой другой версии UNIX. В книге настолько обстоятельно объясняется на" значение используемых команд и возможностей Solaris, что читателю не составит труда найти эквивалент в используемой им версии UNIX. В книге не рассматривается теория баз данных и не сравниваются возможности различных конкурирующих систем баз данных. Автор предполагает, что читатель остановил свой выбор на Sybase SQL Server. Разумеется, при выборе конкретной системы управления базами данных книга позволит составить ясное представление о возможностях крупных информационных сис" тем, основанных на программных продуктах Sybase, и требованиях, предъявляемых в процессе планирования и эксплуатации таких систем. Мы не сравниваем различные аспекты существую" щих СУБД — прежде всего потому, что книга адресована читателю, занимающемуся практиче" скими вопросами эксплуатации реально существующей системы баз данных Sybase. Используемые обозначения

В тексте книги команды Sybase SQL Server выделяются так: disk init При описании допустимого синтаксиса этих команд используется следующий шрифт: sp_helpdb имя_базы_данных sp_helpusersa sp_addsegment название_сегмента, название_серверного_устройства sp_addsegment myseg0, server_device_1 Названия хранимых процедур, включенных компанией Sybase в комплект поставки SQL Ser" ver, имеют формат sр_<название_хранимой_процедуры> sp_helpdevice Хранимые процедуры, не поставляемые и не поддерживаемые компанией Sybase (например, представленные в главе 14), всегда имеют название вида р_<название_хранимой_процедуры> p_devspace Названия баз данных, сегментов баз данных, таблиц данных и их столбцов (полей) выделя" ются курсивом: база данных master сегмент system системная таблица syslogins столбец segmap

www.books-shop.com

Команды операционной системы набраны следующим шрифтом: prtvtoc Значком ;") отмечаются описания реальных событий, предназначенные для осмысления чи" тателем. Основные термины При описании Sybase SQL Server и основанных на нем информационных систем используются многочисленные термины, некоторые из них приведены ниже. • Сервер (server) — под словом "сервер" в книге подразумевается один из сер" веров компании Sybase. Чаще всего имеется в виду именно SQL Server, хотя в некоторых случаях речь идет об одном из серверов стандарта Sybase Open Server (например, входящем в состав SQL Server System 11 сервере архива" ции Backup Server). • Серверная машина, или серверный компьютер (server machine) — подразуме" вается комплект аппаратных средств (процессор, память, диски, сетевые адаптеры и т.д.), образующих компьютер, на котором работает SQL Server. • Логическое устройство сервера (server logical device) — дисковое или ленточ" ное виртуальное устройство, используемое сервером. Отметим, что SQL Ser" ver способен использовать только явно назначенные ему устройства, которые далеко не всегда соответствуют определенному физическому диску. • Серверное устройство (server device) — то же самое, что и логическое устройство сервера. • Дисковод (spindle) — синоним термина "физический диск", или "дисковый на" копитель". • Физическое устройство (physical device) — реальный физический диск или устройство записи на магнитную ленту, известное операционной системе серверной машины. Физическое устройство далеко не всегда можно одно" значно отождествить с логическим серверным устройством (logical device), например расположенным на одном из разделов физического диска. • Пользователь 'sa' (SQL Server user 'sa') — имя пользователя сервера, имеющего системные полномочия. Как правило, имя 'sa' используется администратором сервера. • Системный администратор серверной машины (system administrator) — лицо, отвечающее за установку, эксплуатацию и ремонт аппаратно"программных средств компьютера, используемого сервером и другими программными про" дуктами Sybase. • Информационная система (database system) — весь набор серверных машин, серверов, сетевого оборудования, компьютеров"клиентов, резервных систем и т.д., в процессе совместной эксплуатации обеспечивающих поддержку дея" тельности вашей компании. • Переключение по отказу (fail over) — процесс перехода на резервный сервер при отказе основного сервера информационной системы, а также процесс автоматического переключения сервера на вторичное устройство зеркальной пары при отказе основного серверного устройства пары.

www.books-shop.com

Рассматриваемые версии SQL Server

Между версиями 4.9.2, System 10 и System 11 Sybase SQL Server существуют значительные разли" чия, однако практически весь материал книги в равной мере относится ко всем версиям сервера Sybase, за исключением разделов, где рассматриваются особенности установки отдельных вер" сий SQL Server. Основные процедуры планирования и документирования конфигурации серве" ра, резервирования и восстановления баз данных, распределения их сегментов по серверным устройствам, построения эффективной схемы дисковых разделов, а также многие другие имеют практически одинаковый смысл в различных существующих версиях SQL Server. Очень немно" гие информационные системы используют лишь какую"то одну версию SQL Server, поскольку в большинстве подобных систем происходит непрерывный процесс установки новых серверов с одновременным обновлением части существующих серверов версий 4.9.2 и System 10 на SQL Ser" ver версии System 11.

www.books-shop.com

www.books-shop.com

Благодарности Эта книга посвящается всем сотрудникам групп SOtool Development, Support и ENS, входящих в состав службы Sun Service. Их таланты и достижения настолько многообразны, что приходится ограничиться перечислением имен: Синди Беккетт, Джордж Брандетсас, Кери Бреттелл, Рибек" ка Берджесс, Эриндем Чакраборти, Линда Хеллоран, Фрэнки Лю, Джессика Дай, Зянг Ванг и Юн Ионг. Все они никогда не переставали искать выход даже из самых безнадежных ситуаций. Дипак Элур и Шерон Гилбрет хватило мудрости воздержаться от участия в реализации нынеш" ней версии, но и они способствовали ее появлению. В то время как усилия всей компании были направлены на осуществление новых широко разрекламированных проектов, перечисленная выше команда продолжала поддерживать стремительно устаревающую, но очень важную инфор" мационную систему, обновляя ее по частям параллельно с процессом эксплуатации. Особенно досталось от автора Линде Хеллоран, которой всегда удавалось приводить бредовые идеи ее шефа в соответствие с реальностью и затем успешно воплощать их в жизнь. Мне и Линде при" шлось пройти через немало испытаний. Когда нам больше не придется работать вместе, мне бу" дет ее недоставать. Автор глубоко благодарен всем, кто сделал возможным осуществление этого проекта. Они создали плодотворную среду, позволившую мне узнать много нового из того, что в конечном итоге нашло отражение на страницах книги. Особого упоминания заслуживает Кери Бреттелл — верный союзник, способный преврати" ться в опасного недруга. Она поддерживала мои усилия на протяжении двух лет работы над проектом, и именно ее помощь позволила довести начатое дело до конца. Теперь, когда время реакции сервера действительно составляет доли секунды, я надеюсь, что в глубине души ей приятно видеть наш проект настолько успешно завершенным — ведь она посвятила ему так много времени. Тиен Нгуен и Зян Ван приняли на себя основной поток моих бесконечных запросов на мо" дернизацию серверной машины и установку дополнительных дисков. Они вправе называть меня Брайаном, которому никогда не хватает дисков, и именно они заставили все эти диски ра" ботать. Брет Батчер научил автора писать командные файлы и работать с сервером из дома. Рон Ша не переставал верить в меня и заказывать для меня все новые компьютеры. Мне так долго не хватало хорошего менеджера, но все эти ожидания окупились сполна. Мич Акаматцу, Тим Хикки и Тим Уэйл добавили мне как минимум 10 лет жизни. Именно они помогли мне вырваться из суеты повседневной жизни и написать эту книгу. Шерил Дайн не переставала верить, что ваш покорный слуга может и должен написать но" вую книгу. Ее многочисленные идеи и советы не дали мне остановиться на полпути. Я надеюсь, что и другие проекты принесут ей столь же глубокое чувство личного удовлетворения, служа" щее лучшей наградой за наши усилия. Проекты, подобные этой книге, требуют участия многих людей, большинство из которых даже не осознает, насколько они были полезны. После всего пережитого ими Скотт и Джейд By стали живым доказательством того, что люди способны выдержать любой натиск тех, у кого нет чести и совести, и вернуться к норма" льной жизни. Их успех воодушевляет меня. Кто"то же должен выжить.

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Эми, Джоди, Терри, Сьенна и Джеки — у меня до сих пор перед глазами ваши улыбки, а в ушах слышится ваш смех. Настанет время, и другие полюбят вас так же сильно, как я. Хелен Рут помогала мне многие годы. Все происшедшее стало возможно благодаря ей. Эрик Роберт и Кристофер Ной продолжают расти, предоставляя мне немного времени для работы над книгами. И во время ее написания каждый из них успел научиться пилотировать свой собственный космический корабль с мощным Пентиумом внутри, и я уверен, что эти ко" рабли откроют им дорогу в новые неизведанные миры. Кристофер наконец"то научился гово" рить "нет", и это ничуть не менее важно. Однажды поздно вечером, глядя в полумрак спальни и услышав, что я собираюсь пойти и поработать, Эрик вдруг сказал: "Это твоя вторая книга — и опять про Sybase". Его способность констатировать факты в подобной ситуации просто обезо" руживает. Остается только надеяться, что унаследованное стремление к точности принесет Эрику больше пользы, чем вреда. Френсис Гризвольд поддерживала меня эмоционально. Только тот, кто уже сделал что"то по" добное, сможет объяснить, как много вам еще предстоит пройти. Надеюсь, что Патрик и Роберт Эрик столь же счастливы, как и я. Они любимы, а это очень важно в сегодняшнем мире. Марк Тауб стал тем человеком, который посоветовал мне написать еще одну книгу. Донна и Джерри дали полезные советы по поводу налогов с гонорара. Оглядываясь на свою прошлую жизнь, я вижу, что нужно было просто решиться выйти из тьмы к солнцу. Сайко, к востоку от ГленнзФерри, шт. Айдахо, октябрь 1996 г.

www.books-shop.com

Глава 1

SQL Server: общий

обзор

www.books-shop.com

Введение Sybase SQL Server — высокопроизводительная реляционная система управления базами данных (РСУБД) с разнообразными возможностями, позволяющими обслуживать множество одновременно работающих пользователей и гарантирующими сохранность ответственной деловой информации. В книге рассказывается о различных версиях Sybase SQL Server; ниже мы подробнее остановимся на особенностях каждой из них. Эти особенности рассматриваются и во вводных частях последующих глав, что позволяет читателю легко понять, в какой мере материал главы относится к той или иной версии SQL Server. Мы часто будем называть SQL Server просто "сервером"; если в тексте встречается слово "сервер", речь идет именно о SQL Server, а не файл"сервере, сетевом сервере или другой при" кладной программе. Версии SQL Server В книге рассматриваются три последние версии SQL Server: версия 4.9.2, System 10 и System 11. Как показано на рис. 1.1, области применения этих версий во многом перекрываются: целый ряд возмож" ностей SQL Server 4.9.2 поддерживается в System 10 и System 11. При создании очередных версий SQL Server основное внимание разработчиков было направлено на использование новых возможностей аппаратного обеспечения и операционных систем, появившихся с момента выхода прежней версии. Очередной основной версией Sybase SQL является Server SQL Server System 11.1. Поскольку в момент написания книги эта версия еще не вышла в свет, мы не будем останавливаться здесь и в последую" щих главах на ее особенностях. Ориентированная на системы с массово"параллельной обработкой (также называемые массово"параллельными процессорами, или МПП) версия Sybase Navigation Server, ныне получившая название Sybase MPP (Massively Parallel Processing), представляет собой РСУБД, предназначенную для выполнения самых сложных запросов к особо крупным массивам дан" ных. Navigation Server представляет собой множество отдельных SQL"серверов, каждый из которых работает на своем компьютере. Подробное рассмотрение Navigation Server выходит за рамки данной книги. После краткого описания каждой из трех перечисленных выше версий SQL Server мы остановим" ся на основных возможностях этой системы, а затем подробнее рассмотрим их эволюцию в конкрет" ных версиях SQL Server и перечислим новые возможности каждой новой версии.

Рис. 1.1. Семейство SQL+серверов и бизнес+систем Sybase

www.books-shop.com

SQL Server 4.9.2 SQL Server 4.9.2 — самая старая из версий Sybase SQL Server, рассматриваемых в книге. В свое время существовали и более ранние версии, на сегодняшний день SQL Server 4.9.2 является наиболее старой версией, все еще активно использующейся во многих местах. Существует две разновидности SQL Server 4.9 с номерами версий 4.9.1 и 4.9.2; единственная разница между ними заключается в уровне EBF (Emergency Bug Fix level). Этим термином Sybase обозначает номер последнего исправления, вне" сенного в двоичные выполняемые файлы программных модулей сервера. В подавляющем большинст" ве случаев все ныне эксплуатируемые серверы SQL Server 4.9 соответствуют версии 4.9.2, и в дальнейшем мы будем считать серверы 4.9 и 4.9.2 идентичными. SQL Server 4.9.2 поддерживает все важнейшие функциональные возможности РСУБД; за редкими исключениями, основные черты SQL Server 4.9.2 встретятся читателю и в самых последних версиях серверов Sybase, по"прежнему построенных на базе набора возможностей сервера 4.9.2. SQL Server System 10 Первоначально системе SQL Server System 10 предполагалось дать название Sybase SQL Server 5.0. Од" нако, узнав о планах главного конкурента Sybase — корпорации Oracle выпустить Oracle 7.0, новей" шую на тот момент версию РСУБД Oracle, стратеги из отдела маркетинга Sybase решили обвести вокруг пальца всех участников рынка систем управления базами данных, изменив номер очередной версии с 5.0 на 10.0. Так на свет появился Sybase SQL Server System 10. Появление слова "система" в на" звании сервера также было маркетинговым приемом, обусловленным одновременным выходом в свет сразу нескольких взаимосвязанных программных продуктов. Увы, реальные технические воз" можности новой версии не оправдали всех рекламных обещаний. Уже через несколько лет после по" явления System 10 серьезные проблемы с масштабируемостью этой версии стали критическими и крайне негативно отразились на репутации всей компании Sybase в целом. Все это способствовало в конечном счете созданию намного более надежной и тщательно протестированной новой версии — System 11. Здесь уместно заметить, что Oracle является далеко не единственным конкурентом Sybase. Сегодня уже нельзя сбрасывать со счетов насущную и глобальную угрозу со стороны Microsoft, о чем мы будем говорить ниже. В System 10 был реализован ряд новых возможностей: курсоры, пользовательские роли, улучшен" ная система безопасности и аудита. Реализованная версия языка SQL была приведена в соответст" вие со спецификациями ANSI; запросы стали по"другому анализироваться и обрабатываться оптимизатором запросов. Все операции по созданию дампов хранящихся в SQL Server данных и за" грузке этих данных возложены на отдельный процесс операционной системы — сервер архивации (Backup Server). System 10 SQL Server больше не способен выполнять резервное копирование и за" грузку данных без помощи сервера архивации. Наконец, в состав сервера System 10 были включены две новые системные базы данных. В первой из них — sybsystemprocs —. содержатся все системные хра" нимые процедуры, такие, как процедура sp_who. Вторая системная база данных — sybsecurity " испо" льзуется для хранения всей информации, необходимой для поддержки новых возможностей аудита, появившихся в System 10. SQL Server System 11 System 11 — последняя на данный момент главная версия Sybase SQL Server, призванная обеспечить масштабируемость Sybase SQL Server для многопроцессорных систем и в полной мере воспользовать" ся возможностями современных вычислительных систем. По мере увеличения нагрузки на сервер можно постепенно наращивать аппаратные ресурсы вычислительной системы, что дает заметные преимущества. Если число пользователей вашего сервера удваивается, System 11 позволяет найти вы" ход из ситуации с помощью простого удвоения количества имеющихся процессоров при сохранении прежнего времени реакции системы. Как хорошо знает любой администратор баз данных, время ре" акции существующей системы никогда не удовлетворяет ее пользователей. System 11 дает возмож" ность решить и эту проблему, сократив время реакции за счет приобретения дополнительных процессоров при сохранении прежнего числа пользователей. System 11, как и System 10, представляет собой целое семейство взаимосвязанных программных продуктов. При разработке System 11 главный упор был сделан на улучшение масштабируемости сер" вера; в ее состав были также включены новые версии других программных продуктов — таких, как сервер тиражирования (Replication Server). Семейство программных продуктов System 11 позволяет значительно повысить уровень производительности баз данных Sybase. Итак, главное преимущество System 11 — это высокая производительность на многопроцессор" ных системах. Архитектура однопроцессорных систем не позволяет воспользоваться

www.books-shop.com

преимуществами хорошей масштабируемости System 11 и увеличить производительность. Перенос большинства современных РСУБД на многопроцессорные аппаратные платформы настолько повы" шает их производительность, что этот процесс уже не остановить. Разумеется, выход на новый уровень производительности сопряжен с определенными издержка" ми, которые отнюдь не сводятся к стоимости приобретения новых процессоров. Sybase System 11 SQL Server обеспечивает широкие возможности мониторинга производительности и настройки, не" мыслимые в предыдущих версиях системы. С одной стороны, администраторам System 11 требуется соблюдать большую осторожность при работе с практически неограниченным числом допустимых комбинаций параметров настройки, появившихся в вашем распоряжении. К примеру, если предыду" щие версии сервера имели около 30 конфигурационных параметров, то System 11 SQL Server под" держивает более сотни подобных параметров, позволяющих создавать и настраивать такие объекты, как именованные кэш"буферы и множественные области буферов. В результате админист" ратор базы данных получает ничем не ограниченный простор для настройки своей базы данных (а также для серьезных ошибок в процессе настройки). С другой стороны, теперь ваша роль как ад" министратора базы данных стала еще более важной и ответственной, чем прежде. Только попробуй" те представить себе, как пользователи будут самостоятельно искать ошибку в конфигурации тридцать первого из 102 созданных вами именованных кэш"буферов. В итоге администраторы баз данных смогут еще глубже погрузиться в мир таинственных и сложных вещей, недоступных просто" му смертному. Итак, выход в свет System 11 внес самый значительный вклад в стабильность и успех вашей карьеры с тех пор, как вы открыли для себя язык SQL. Microsoft SQL Server 4.2 и 6.0 Несмотря на то, что данная книга посвящена Sybase SQL Server, читатель должен понимать один весь" ма противоречивый аспект развития программных продуктов Sybase. В не столь отдаленном про" шлом Microsoft и Sybase достигли соглашения о совместном использовании ряда ключевых технологических решений, связанных с ядром сервера. В соответствии с этим соглашением Sybase за" нималась разработкой и маркетингом Sybase SQL Server для различных аппаратных платформ, и в том числе для многочисленных версий системы UNIX, в то время как на долю Microsoft выпало рас" пространение Microsoft SQL Server для Windows NT. Однако, как это часто бывает, через некоторое время пути обеих компаний разошлись. Все, что действительно необходимо знать читателю об этой увлекательной и не вполне ясной истории, — это то, что Sybase" и Microsoft"версии SQL Server 4.9.2 были разработаны в рамках единого проекта и поэтому практически идентичны, за очевидным иск" лючением аспектов, связанных с реализацией версий сервера для конкретных операционных систем и аппаратных платформ. Расторгнув союз с Sybase, Microsoft самостоятельно продолжила работу над своей версией серве" ра, получившей название Microsoft SQL Server 6.0 для Windows NT и отличающейся от Sybase SQL Server в некоторых существенных вопросах. Microsoft SQL Server 6.0 приблизительно соответствует Sybase SQL Server System 10, и это — хорошая новость для читателя. По мере того как Microsoft про" должает вбирать в себя все формы жизнедеятельности на планете, любой опытный администратор Sybase SQL Server пользуется редкой привилегией не опасаться этого, поскольку он уже обладает практически всеми знаниями, необходимыми для эффективного сопровождения Microsoft SQL Server. Каким бы ни оказался окончательный исход противостояния Microsoft и Sybase, читатель мо" жет не сомневаться в успехе собственной карьеры. За исключением тех случаев, когда в книге явно упоминается Microsoft SQL Server, под словами "сервер" и SQL Server мы будем подразумевать Sybase"версию SQL Server. Будущие версии SQL Server Конкретные особенности будущих версий любой программы становятся более четкими только после того, как она выйдет в свет и пользователи смогут накопить некоторый опыт ее эксплуатации. В на" стоящее время обсуждается целый ряд новых возможностей, которые должны будут появиться в буду" щих версиях SQL Server. Назвать сейчас хотя бы примерные сроки фактической реализации этих возможностей в готовом программном продукте представляется весьма проблематичным. Вероятно, имеет смысл уделить некоторое время анализу перспектив, но ни в коем случае не следует опираться в своих планах на скорую реализацию какой"либо из них. Более подробное описание "обещаний Sybase" мы вынуждены отложить до конца настоящей главы, поскольку для их лучшего понимания не" обходимо сперва познакомиться с основными возможностями самой System 11.

www.books-shop.com

Основные концепции РСУБД Читатель должен ясно представлять себе основные возможности любой реляционной системы управ" ления базами данных (РСУБД) и их реализацию в Sybase SQL Server. Для начала рассмотрим общие черты современных РСУБД с точки зрения администратора базы данных. Реляционные базы данных Точное определение понятия реляционной базы данных стало предметом длительной дискуссии в на" учных журналах; в качестве рабочего определения можно принять, что в таких базах данных все дан" ные хранятся в таблицах (рис. 1.2). Результат любого запроса к реляционной базе данных также является таблицей. Если, к примеру, требуется найти всех клиентов из штата Калифорния, соответст" вующий список будет выдан в форме таблицы, состоящей из столбцов и строк. Разместив в них дан" ные, можно очень легко связать данные из одной таблицы с данными из другой таблицы, что позволяет осуществлять доступ к этим данным самыми разными способами. Еще одной важной осо" бенностью реляционных баз данных является то, что ядро базы данных — набор основных програм" мных модулей, управляющих хранением и выборкой данных, — совершенно свободно при выборе способа выполнения своих функций. Другими словами, пользователь не знает заранее, каким конк" ретно образом будет обрабатываться выданный им запрос. В реляционных базах данных реальные структуры хранения данных в дисковых файлах непосредственно не влияют на структуру запросов, используемых для обработки этих данных. psycho_books title

title_id

published

made_money

year_published

DBA_Handbook

1

yes

no

1995

DBA Companion 2 CSP Training 3

yes no

no no

1996 NULL

select * from psycho_books where year_published != NULL title

titlejd

published

made_money

year_published

DBA_Handbook

1

yes

no

1995

DBA Companion 2

yes

no

1996

select title, year_published from psycho_books title year_published DBA_Handbook 1995 DBA Companion 1996 CSP Training NULL Рис. 1.2. Таблицы реляционной базы данных Язык структурированных запросов SQL Поскольку в реляционных базах данных информация хранится в таблицах, связанных друг с другом множеством различных способов, доступ к данным этих таблиц также можно производить разными способами. Стандартным средством доступа к реляционным данным стал язык структурированных за" просов (Structured Query Language, SQL). Возможность работать с реляционными базами данных раз" личных компаний"разработчиков, используя единый язык запросов, послужила еще одной причиной популярности реляционных баз данных. Сам по себе язык SQL далек от совершенства, но он намного облегчает доступ к реляционным данным по сравнению с ситуацией, в которой каждый поставщик баз данных должен был бы разрабатывать свои собственные средства доступа к данным. Существова" ние стандарта SQL значительно облегчает интеграцию РСУБД различных поставщиков в единые се" тевые информационные системы.

www.books-shop.com

Направляя серверу набор команд SQL, мы посылаем запрос (query). Под этим термином подразу меваются любые SQLкоманды, даже те, которые служат для ввода новых данных. Подробное рас смотрение языка SQL потребовало бы слишком много времени. Ниже перечислены необходимые читателю важнейшие SQLкоманды обработки данных: Select Предназначена для чтения данных из таблицы или нескольких таблиц. Insert Позволяет внести в таблицу новые данные. Update Осуществляет модификацию информации, хранящейся в таблице. Delete Служит для удаления данных из таблицы. Несмотря на достаточно широкие возможности стандартного SQL, каждая компанияразработ чик баз данных не преминула реализовать свои собственные расширения этого языка, несовмести мые с версиями SQL конкурирующих компаний. Конечно, фирмыпоставщики оправдывают существование нестандартных расширений несовершенством самого стандарта SQL, но к подобным заявлениям не следует относиться слишком серьезно. Главная задача любого поставщика баз дан ных — сделать так, чтобы его РСУБД чемто отличалась от аналогичных продуктов конкурентов. В итоге, несмотря на существование единого стандарта SQL, нам приходится не только помнить о расширениях SQL, реализованных в РСУБД различных поставщиков, но и все чаще иметь дело с не сколькими подобными несовместимыми расширениями одновременно, занимаясь интеграцией гете рогенных сетевых информационных систем. Объекты баз данных РСУБД содержат множество объектов, предназначенных для хранения данных, а также для их обра ботки и верификации. Здесь мы рассмотрим некоторые разновидности объектов баз данных, пока занные на рис. 1.3. title

title_id

published

made_money

year_published

1

yes

no

1995

2

yes

no

1996

3

no

no

NULL

таблица + поля (title, title_id, published, made_money, year_published) ++ каждая строка таблицы содержит описание одной книги правило + допустимые значения поля published + Y, N значение по умолчанию ++ если made_money = NULL то madejnoney = N хранимая процедура ++ заменяет year_published на year_published + 1 ++ все строки таблицы обновляются одновременно триггер ++ при вставке вычисляет new_total для всех изданных книг ++ срабатывает при добавлении каждой новой записи индекс ++ создает индекс по полю titlejd ++ компоненты индекса выглядят следующим образом: 1, указатель на запись с titl_id=1 id = 1 NULL ++ в строке с titlejd = 3 значение поля year_published неизвестно Рис. 1.3. Объекты базы данных

www.books-shop.com

Таблица Таблица (table) — это основной объект базы данных, состоящий из набора строк данных (записей). Столбцы таблицы называются полями; каждое поле используется для хранения одного из атрибутов объекта, описываемого данной таблицей. Правило Правило (rule) — объект, указывающий допустимые значения или формат данных в столбце таблицы. Например, все табельные номера сотрудников должны состоять из шести цифр. Значение по умолчанию Значение по умолчанию (default) — объект, определяющий, какое значение будет установлено для поля, не имеющего никакого значения в момент записи данных в таблицу. К примеру, если при внесе" нии нового сотрудника в таблицу сотрудников компании его зарплата не указана, система может по умолчанию назначить ему зарплату в $0.00. Хранимая процедура Стандартный способ использования SQL — пересылка всех SQL"запросов на сервер для обработки. Количество запросов, а вместе с ним и трафик в сети стремительно возрастают с увеличением слож" ности приложения и ростом числа пользователей. Хранимая процедура (stored procedure) представ" ляет собой готовый набор SQL"предложений, хранящийся на сервере. Для выполнения всех команд процедуры достаточно направить на сервер ее название. Использование хранимых процедур, поми" мо снижения сетевого трафика, повышает производительность сервера, поскольку такие процедуры хранятся в скомпилированном виде, что избавляет сервер от необходимости выполнять повторный синтаксический анализ каждой команды. Хранимые процедуры доступны всем пользователям серве" ра. Вместо программирования бизнес"правил в каждом из приложений, их можно реализовать как хранимые процедуры, используемые всеми приложениями. В результате облегчается сопровождение прикладной системы, поскольку теперь все приложения гарантированно используют один и тот же набор централизованно хранимых бизнес"правил. Триггер Триггер (trigger) — это хранимая процедура, выполняющаяся в ответ на наступление того или иного события. Типичным примером служит триггер, вызываемый при каждом обновлении таблицы, ска" жем, для проверки корректности внесенных изменений. Индекс По мере роста размеров таблиц данных поиск необходимой информации становится все более мед" ленным. Для ускорения поиска данных можно выделить ряд ключевых полей в отдельную структуру данных, называемую индексом (index) и состоящую из упорядоченного набора значений ключевых полей и указателей на записи данных, соответствующих каждому значению ключа. Значения ключе" вых полей представляют собой подмножество данных, хранящихся в каждой записи таблицы. После создания индекса сервер может просмотреть его в поиске необходимых значений ключевых полей и найти указатели на все необходимые строки данных. Значения ключевых полей в индексе упорядоче" ны, поэтому поиск необходимого значения выполняется намного быстрее. Индекс, как правило, со" держит лишь небольшой фрагмент каждой строки данных, и его размер оказывается намного меньше размеров соответствующей таблицы. Таким образом, индекс — это небольшой упорядоченный набор значений отдельных ключевых полей таблицы. Предположим, необходимо найти имя сотрудника с табельным номером 1002. При отсутствии индекса серверу потребовалось бы просмотреть всю табли" цу сотрудников в поисках единственной записи с табельным номером, равным 1002. После создания индекса с полем табельного номера в качестве ключа, сервер может быстро найти значение 1002 и, прочитав указатель записи таблицы, соответствующей данному значению, выбрать из этой записи имя сотрудника. Значения NULL В качестве рабочего определения примем, что поле имеет значение NULL, если его значение неиз" вестно. К примеру, если при вводе в базу данных новый сотрудник еще не имеет табельного номера, какое значение его табельного номера должно быть указано в подобной ситуации? Все связанное со значениями NULL и их реальным смыслом остается предметом оживленной дискуссии в научной литературе, которую вряд ли удастся когда"либо завершить. На практике подобные значения встре" чаются довольно часто, и необходимо ясно понимать их роль в каждом конкретном приложении.

www.books-shop.com

В приведенном примере значение NULL выглядит вполне безобидно (и будет изменено сразу, как то" лько сотрудник получит табельный номер), но встречаются и другие ситуации. Представьте себе, что вы отвечаете за систему контроля заказов, принятых от клиентов. Переговоры с вашим крупнейшим клиентом еще не завершены, условия будущего крупного заказа пока не известны, и при вводе этого заказа в базу данных поле общей суммы заказа будет установлено в NULL. Но как подобное значение должно обрабатываться сервером, например, при вычислении общей суммы невыполненных зака" зов? Что в данной ситуации реально означает значение NULL как для сервера, так и для вашей компа" нии? Очень важно вовремя включить в базу данных хотя бы предварительную информацию о намечающемся крупном заказе, иначе о нем не смогут узнать другие отделы компании, для которых подобные сведения представляют несомненный интерес. Транзакции Очень часто транзакцию определяют как отдельную законченную операцию, выполняемую в РСУБД. Такая формулировка не отражает всей важности транзакций для администратора базы данных, кото" рая обеспечивает нормальную деловую активность компании. Рассматриваемая вне контекста конк" ретной деловой активности, транзакция сама по себе не имеет значения или смысла. В реляционных базах данных Sybase транзакция является элементарной частью процесса восстановления после сбо" ев. Другими словами, всегда можно быть уверенным в том, что любая транзакция либо успешно завер" шится, либо окажется полностью отмененной. Поэтому с точки зрения конкретной деловой активности транзакция должна представлять собой минимально возможный набор изменений дан" ных, не приводящий базу данных в недопустимое или бессмысленное состояние. Хорошим примером здесь может служить обновление банковского счета. Едва ли клиенты банка будут удовлетворены практикой, когда регистрация внесенных средств и обновление счетов клиентов станут выполняться как отдельные транзакции. С точки зрения базы данных, любая из этих двух операций может оказать" ся либо успешно завершенной, либо отмененной. Однако реальный смысл выполняемых операций диктует необходимость их осуществления в рамках единой транзакции, включающей в себя как офор" мление внесенных средств, так и их зачисление на счет. Таким образом, реальное значение транзакции определяется ее ролью в деловой активности, поддерживаемой реляционной базой данных. И хотя администратор этой базы данных проводит бесконечные часы за обеспечением целостности выполняемых транзакций, вся ответственность за то, что эти транзакции действительно отражают операции, допустимые с точки зрения бизнес"пра" вил, целиком лежит на разработчиках конкретных запросов, обрабатываемых сервером. Необходи" мо ясно понимать, что восстановление базы данных выполняется с точностью до отдельных транзакций, и если какая"то из этих транзакций не соответствует действующим бизнес"правилам, то даже полное восстановление базы данных может привести ее в состояние, когда принятые средства клиента будут оформлены, но не зачислены на его счет. Для системы базы данных понятие транзакции дает возможность определить минимальный на" бор изменений данных, переводящий базу данных из одного допустимого состояния в другое. Поэ" тому, если все выполняемые транзакции либо успешно завершаются, либо полностью отменяются, база данных постоянно находится в состоянии, корректном с точки зрения существующих биз" нес"процессов (рис. 1.4). Успешное завершение транзакции называется фиксацией, если произве" денные изменения вносятся в базу данных на окончательной основе. Архитектура сервера призвана гарантировать возможность восстановления каждой зафиксированной транзакции при сбоях как са" мого сервера, так и вычислительной системы, на которой он работает, — при условии аккуратного выполнения всех рекомендуемых процедур резервирования и восстановления данных. Процедура отмены результатов транзакции, в силу тех или иных причин оказавшейся незавершенной, называ" ется откатом этой транзакции. При этом база данных возвращается в состояние, соответствующее моменту начала транзакции. Восстановление после сбоев Важнейшей отличительной чертой баз данных, отвечающих требованиям систем для делового при" менения, является поддержка средств, гарантирующих восстановление данных после сбоев — разуме" ется, при условии надлежащего использования этих средств и исключения внешних факторов, угрожающих сохранности данных (таких, как случайная порча магнитной ленты). Полноценные сис" темы управления базами данных позволяют легко создавать дампы базы данных, обеспечивающие возможность последующего полного восстановления содержащейся в базе данных информации и воз" вращения базы данных в допустимое состояние (рис. 1.5). Здесь мы должны снова вспомнить о тран" закциях, поскольку сервер базы данных гарантирует восстановление только тех изменений, которые

www.books-shop.com

Рис. 1.4. Транзакции

время t1 t2 загрузка данных из дампа позволяет восстановить состояние базы данных на момент создания этого дампа

t3

Рис. 1.5. Восстановление после сбоев стали результатом полностью завершенных транзакций. Другими словами, механизмы восстановле" ния базы данных дают возможность вернуть ее к состоянию, учитывающему результаты всех завер" шенных транзакций. Блокировка Предположим, что хранящаяся в базе данных информация должна соответствовать определенным бизнес"правилам. Естественно ожидать, что при любом обращении к базе данных она находится в со" стоянии, допустимом с точки зрения этих бизнес"правил. Поэтому при выполнении незавершенной транзакции другие пользователи базы данных не должны видеть изменения в данных, внесенные вы" полняемой транзакцией. Для этого сервер использует механизм блокировок (locks), накладываемых

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Рис. 1.6. Блокировка на модифицируемые элементы базы данных (рис. 1"6). Обработка любого другого запроса на выборку или изменение блокированного элемента базы данных будет задержана до завершения предыдущей транзакции. Если какому"либо системному процессу была предоставлена блокировка на элемент базы данных, то говорят, что этот процесс удерживает блокировку, запрещающую доступ других процес" сов к этому элементу базы данных. Таким образом, блокировки позволяют базе данных исключить до" ступ одного пользователя к изменениям, внесенным другими транзакциями, до момента полного завершения этих транзакций. Многопользовательская среда Важная особенность полноценных коммерческих баз данных — способность поддерживать одновре" менную работу множества пользователей. Это является еще одним характерным различием между на" стоящими системами делового назначения и однопользовательскими базами данных, работающими на персональных компьютерах. В таких системах РСУБД должна обладать различными механизмами блокировок, обеспечивающими перевод базы данных из одного допустимого состояния в другое по" сле завершения каждой пользовательской транзакции. Необходимо иметь в виду, что для повышения производительности многие системы позволяют варьировать используемый уровень непротиворечи" вости данных. Как мы увидим в дальнейшем, System 11 поддерживает так называемые операции "гряз" ного чтения" (dirty reads), открывающие пользователям возможность видеть изменения, сделанные другими незавершенными транзакциями. Концепции РСУБД и SQL Server 4.9.2 Рассмотрим, как различные основные концепции РСУБД реализованы в SQL Server на примере вер" сии 4.9.2, а затем обсудим дополнительные возможности SQL Server System 10 и System 11. Сервер SQL Server представляет собой единый системный процесс, способный одновременно поддерживать несколько баз данных. После установки SQL Server уже содержит одну или несколько баз данных, и в первую очередь системную базу данных master, хранящую информацию о пользователях сервера, его конфигурации и других базах данных, содержащихся на сервере. В новых версиях SQL Server в его со" став включено еще несколько дополнительных системных баз данных. На одном компьютере может функционировать несколько разных серверов, но обычно в этом нет необходимости, поскольку один сервер способен управлять многими базами данных. Необходимость установки нескольких серверов иногда возникает при эксплуатации программного обеспечения третьих фирм. К примеру,

www.books-shop.com

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

Рис. 1.7. Серверный компьютер Серверный компьютер Серверная машина (рис. 1.7) состоит из аппаратного обеспечения и операционной системы (ОС), поддерживающих функционирование SQL Server. Основные компоненты серверной машины пере" числены ниже. Процессор Процессор серверной машины выполняет все программы, запускаемые на этом компьютере. Если серверный компьютер представляет собой систему с симметричным мультипроцессированием (СМП), то SQL Server может использовать несколько процессоров одновременно.

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

www.books-shop.com

память. Программа установки сервера проверяет имеющуюся конфигурацию ядра системы и при не" обходимости вносит необходимые изменения в конфигурационные параметры. Сетевая аппаратура Архитектура SQL Server ориентирована на работу через сеть. Другими словами, все соединения с SQL Server устанавливаются исключительно по сети; пользователь не может сначала войти в серверный компьютер, а затем напрямую обратиться к серверу. Даже при работе на одном компьютере с серве" ром, все равно придется устанавливать с ним соединение, используя протоколы доступа к сети. Контроллеры Дисковые накопители подключаются к серверной машине через контроллеры, обеспечивающие чте" ние и запись данных на физическом уровне. Каждый контроллер способен поддерживать лишь ограни" ченное число дисков без снижения общей производительности системы, и поэтому имеющиеся контроллеры ни в коем случае не должны быть перегружены. Проверьте, какое количество дисков мо" жет подключаться в вашей системе к одному контроллеру. Современные контроллеры способны управ" лять большим числом дисков; главное, чтобы контроллер не становился узким местом в системе. Дисковые накопители SQL Server хранит файлы базы данных и служебные файлы, необходимые при установке и сопровож" дении сервера, на дисковых накопителях, физически подключенных к серверному компьютеру. Накопители на магнитной ленте Серверная машина обязательно должна включать в себя по крайней мере один накопитель на магнит" ной ленте для создания резервных копий файлов баз данных и служебных файлов сервера, хранящих" ся на ее дисках. SQL Server способен создавать резервные копии баз данных как на дисках, так и на ленте; однако в некоторых случаях такие копии должны сбрасываться именно на ленту. Имея резерв" ные копии файлов на магнитной ленте, вы можете восстановить сервер и всю хранящуюся в нем ин" формацию после сколь угодно серьезного аппаратного сбоя. Подчеркнем, что в результате некоторых сбоев резервные копии, находящиеся на дисках, могут оказаться недоступными. В последнее время появилось множество новых возможностей создания резервных копий раз" личных файлов. Эти возможности в первую очередь ориентированы на информационные системы, состоящие из большого числа отдельных компьютеров. Целый ряд компаний предлагает аппаратное и программное обеспечение для резервирования данных на многих компьютерах через компьютер" ную сеть. Подобный подход может оказаться весьма эффективным для обычного резервирования данных, поскольку файлы всех индивидуальных систем будут копироваться по сети на отдельный компьютер. Такие системы резервирования обычно находятся в ведении отдельной службы, осуще" ствляющей копирование данных с каждого компьютера лишь один раз на протяжении каждого цик" ла резервирования данных всех компьютеров сети. Эта служба в силу различных причин технического и политического характера может оказаться неспособной обеспечить выполнение не" стандартных операций резервирования данных. Например, при восстановлении базы данных или осуществлении специальных системных работ может потребоваться многократное создание резерв" ных копий в течение одного дня, в то время как регулярное сетевое копирование данных произво" дится один раз в день. Более того, необходимость срочного создания резервной копии может возникнуть как раз в тот момент, когда сеть не будет функционировать. Накопитель на магнитной ленте, напрямую подключенный к серверному компьютеру, позволит найти выход из всех описан" ных выше ситуаций. И еще один аргумент в пользу магнитной ленты. Существующие 32"битные версии UNIX не под" держивают дисковые файлы длиной более 2 Гбайт, в то время как размеры многих баз данных пре" вышают 2 Гбайт. Такую базу данных нельзя скопировать в один дисковый файл, и может потребоваться сбросить ее дамп прямо на магнитную ленту. Заметим, что входящий в состав SQL Server System 10 и 11 сервер архивации (Backup Server) способен создавать дампы базы данных в виде нескольких дисковых файлов. Однако при работе с сервером версии 4.9.2 или недостатке сво" бодного дискового пространства для размещения дампов крупных баз данных вам все равно понадо" бится накопитель на магнитной ленте. Распределение оперативной памяти серверного компьютера Оперативная память серверной машины служит для размещения ядра SQL Server и с другими целями (рис. 1,8), Операционная система Наряду с аппаратными средствами, операционная система представляет собой важнейший компо" нент серверной машины, без которого этот компьютер окажется практически бесполезным. Для того

www.books-shop.com

все остальные процессы, работающие на серверной машине Рис. 1.8. Схема использования оперативной памяти серверного компьютера чтобы быть уверенным в соответствии используемой версии SQL Server серверному компьютеру, не" обходимо иметь подробную информацию о составе аппаратных средств компьютера и версии его операционной системы. ОС серверного компьютера постоянно обновляется с помощью так называе" мых заплаток (иногда используется термин патч (patch)), предназначенных для исправления обнару" женных ошибок и добавления в систему новых функциональных возможностей. В зависимости от версии SQL Server и версии используемой операционной системы в эту систему может потребоваться внести различные наборы заплаток. Аругие системные процессы Здесь речь идет о различных процессах, выполняющихся на серверной машине. Каждый такой про" цесс требует определенных ресурсов центрального процессора, оперативной и дисковой памяти, что может отрицательно сказаться на производительности SQL Server. При установке и конфигурирова" нии сервера важно ясно представлять, какие именно процессы будут работать на серверной машине. В большинстве баз данных, находящихся в промышленной эксплуатации, SQL Server должен быть единственным основным процессом, выполняющимся на серверной машине. SQL Server SQL Server выполняется на серверном компьютере как единый системный процесс, обслуживающий все обращения пользователей к серверу. При работе SQL Server единый серверный процесс разделя" ется на множество отдельных потоков (threads), представляющих собой своего рода мини"процессы. SQL Server самостоятельно контролирует все аспекты, связанные с подключением пользователей к серверу и разделением между ними имеющихся ресурсов. Подобная архитектура оказывается более эффективной, поскольку ОС наблюдает лишь один системный процесс, и в результате SQL Server спо" собен быстрее открывать и завершать сеансы работы пользователей, чем если бы каждый такой се" анс представлял отдельный системный процесс. SQL Server обладает многопоточной архитектурой. Несмотря на то, что каждый пользователь сервера контролируется непосредственно серверным про" цессом, количество одновременно открытых сеансов работы пользователей ограничено конфигура" цией ядра операционной системы — конкретно, максимальным числом дескрипторов файлов, разрешенным каждому системному процессу. Любая очередная основная версия SQL Server представляет собой новый вариант сервера, суще" ственно отличающийся по функциональным возможностям от своего предшественника. В этой кни" ге мы рассматриваем три основные (главные) версии SQL Server: 4.9.2, System 10 и System 11. Каждая из главных версий состоит из нескольких младших версий (релизов), выпускаемых в процес" се исправления ошибок, обнаруженных на сервере. Каждому из младших релизов присваивается определенный номер уровня EBF (Emergency Bug Fix). Важно подчеркнуть, что речь идет о регуляр" но выпускаемых младших релизах, призванных решить проблемы, обнаруженные при эксплуатации SQL Server на некоторых из большого числа различных аппаратных платформ, поддерживаемых си" стемой. Администратор базы данных должен знать номер уровня EBF используемой версии сервера; этот номер потребуется, например, при обращении в службу технической поддержки Sybase.

www.books-shop.com

SQL Server использует: Центральный процессор Оперативную память Дисковые накопители для баз данных для дампов баз данных для необходимых файловых структур Сетевой адаптер Накопители на магнитной ленте

Рис. 1.9. SQL Server на серверном компьютере SQL Server использует самые разные ресурсы серверного компьютера (рис. 1.9) — центральный процессор для выполнения программных модулей сервера, диски для хранения файлов баз данных и сетевой адаптер для взаимодействия с программами"клиентами. Кроме того, сервер использует ди" ски и накопители на магнитных лентах при создании резервных копий баз данных. Поисковое ЯДРО После запуска выполняемого модуля SQL Server в действие вступает его поисковое ядро (engine). Если сервер работает на многопроцессорной системе, серверный процесс (и в том числе поисковое ядро) может выполняться на любом из имеющихся процессоров. При конфигурировании сервера ад" министратор базы данных определяет, какое количество поисковых ядер способно одновременно выполняться при работе сервера. Основываясь на значении соответствующего конфигурационного параметра, сервер автоматически запускает необходимое количество поисковых ядер. Каждое ядро представляет собой отдельный серверный процесс операционной системы, в свою очередь способ" ный выполняться на любом свободном процессоре. Обычно не имеет особого смысла запускать не" сколько поисковых ядер на однопроцессорной системе, либо запускать больше ядер, чем имеется процессоров в многопроцессорной системе. Как правило, при наличии N процессоров SQL Server конфигурируется с N1 поисковыми ядрами. Если на серверной машине должны выполняться и дру" гие процессы, запуск отдельного ядра на каждый процессор может оказаться невозможным, и количе" ство одновременно работающих ядер придется сократить по сравнению с правилом N1. При работе SQL Server с несколькими ядрами одно из них контролирует сетевой ввод"вывод для всех остальных серверных процессов. Разумеется, правило N+1 не следует применять на однопроцессорных системах — нуле+ вому количеству поисковых ядер соответствует нулевая производительность сервера. Использование памяти сервером Распределенная серверу область оперативной памяти серверного компьютера состоит из нескольких разделов, используемых различными компонентами SQL Server (рис. 1.10). Обратите внимание, что распределение этой области памяти производится непосредственно в момент запуска сервера; после запуска сервер больше не может запрашивать у операционной системы дополнительные области па" мяти.

www.books-shop.com

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

Доступ к серверу исключительно по сети При разработке SQL Server его архитектура сознательно строилась на основе сетевого доступа (рис. 1.11). С точки зрения сервера, любые соединения с программами"клиентами должны устанавли" ваться только по сети. Клиенты — это программы пользователей, начинающих сеанс работы с серве" ром, и другие серверы, обращающиеся с запросами. Даже если программа"клиент работает на той же машине, что и сам сервер, они должны взаимодействовать через сетевые протоколы. Не существует способа доступа к серверу без указания сетевого адреса серверного компьютера и номера порта, рас" пределенного серверу при его запуске. Номер порта необходим серверу, чтобы знать, откуда именно ожидать запросов на соединение, поступающих от программ"клиентов. Администратор базы данных должен хорошо знать формат файла сетевых интерфейсов, определяющий имена каждого сервера, с которым система может взаимодействовать по сети. Файл сетевых интерфейсов Поскольку любое взаимодействие SQL Server с программами"клиентами происходит через сеть, край" не важно ясно представлять процесс установления соединений по сети. Значительная часть проблем, которые приходится решать администратору баз данных, связаны с пользователями, которым не уда" ется подключиться к серверу. SQL Server использует определенный порт на серверной машине (об" суждение термина "порт" выходит за рамки данной книги). Самое существенное заключается в том, что для подключения к серверу пользователю необходимо соединиться именно с этим портом. В сети может одновременно функционировать несколько серверов и работать множество пользователей. Каждый серверный компьютер обладает уникальным сетевым адресом (IP"адресом). Файл сетевых интерфейсов позволяет сопоставить название сервера и комбинацию из сетевого адреса компьютера

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

www.books-shop.com

16

Рис. 1.11. Сетевой доступ к SQL Server # PSYCH0492 query tcp sun+ether psycho 1025 # PSYCH010 query tcp sun+ether thebirds 1025 # PSYCH011 query tcp sun+ether rearwindow 1025

Для простоты изложения файл интерфейсов показан в формате SunOS. В операционной системе Solaris используется другой формат файла интерфейсов (см. главу 12). Рис. 1.12. Файл интерфейсов (для SQL Server 4.9.2 в среде SunOS) компьютера и номером порта. Затем прикладная программа определит по имени серверной машины ее сетевой адрес и направит запрос на соединение с прочитанным из файла номером порта этой машины. Важно еще раз подчеркнуть, что подобный механизм соединения с SQL Server используется абсолютно во всех случаях. Даже если приложение работает прямо на серверном компьютере, ему все равно при" дется прочитать файл интерфейсов, имя которого было указано при установке данного приложения на компьютер. Таким образом, на одной машине может существовать несколько файлов интерфейсов. Каждый такой файл содержит описание SQL"серверов, что позволяет администратору базы данных определять, к каким серверам смогут обращаться пользователи определенных приложений. Необходимо понимать, что если удаленный сервер не указан в файле интерфейсов, используе" мом данной программой"клиентом, клиент не сможет соединиться с этим сервером (рис. 1.13). Файл интерфейсов, доступный клиенту, полностью определяет, к каким серверам может обращаться этот клиент. С точки зрения программы"клиента, сервер, не указанный в файле интерфейсов, попросту не существует.

www.books-shop.com

Если файл интерфейсов содержит лишь следующие строки:

# PSYCH0492 query tcp sun+ether psycho 1025 для программ+клиентов будет доступен только сервер PSYCH0492

Рис. 1.13. Ограничение доступа пользователя с помощью файла интерфейсов

SQL Server PSYCH0492 работает на машине psycho и использует порт с номером 1025

Рис. 1.14. Роль файла интерфейсов в установлении соединения с сервером Роль файла интерфейсов РОЛЬ файла интерфейсов при установлении сетевого соединения с сервером показана на рис. 1.14. После того как пользователь программы"клиента выдаст команду на соединение с сервером, выполня" ется чтение файла интерфейсов. Если файл интерфейсов не найден, программа"клиент не может по" лучить доступ ни к одному серверу. После чтения содержимого файла интерфейсов производится поиск сервера с указанным именем; каждому имени сервера в файле ставится в соответствие сетевое имя серверной машины и номер порта. Используя эту информацию, программа"клиент может под" ключиться по сети к указанному порту нужной машины и установить соединение с сервером.

www.books-shop.com

Пользователи Сначала имена и пароли пользователей определяются на уровне сервера, затем заносятся в базу дан" ных, и лишь после этого пользователям базы данных предоставляются права доступа к самим данным и объектам базы данных (рис. 1.15). Обратите внимание на то, что сервер обеспечивает хранение па" ролей только для пользователей сервера, но не для пользователей базы данных. SQLServer создание пользователя сервера

база данных

объекты базы данных

создание пользователя базы данных посредством внесения пользователя сервера в базу данных

пользователю базы данных предоставляются права доступа к объектам базы данных

Рис. 1.15. Пользователи SQL Server Разработчики некоторых приложений предпочитают, чтобы при всех обращениях пользовате" лей приложений к SQL Server указывалось одно и то же имя пользователя сервера. Подобная прак" тика облегчает администрирование приложения, но может создать немало проблем для администратора сервера. Дело в том, что сервер собирает подробную информацию по каждому по" льзователю, и если все пользователи будут обращаться к серверу под одним именем пользователя сервера, то администратор сервера не сможет определить, действия какого именно пользователя приводят к снижению производительности сервера. Таким образом, облегчение администрирова" ния пользователей впоследствии может затруднить решение проблемы снижения производительно" сти сервера. Подобная практика серьезно снижает защиту всей системы от несанкционированного доступа. В некоторых организациях каждый пользователь сервера должен подключаться к серверу только под своим индивидуальным системным именем. Задача администратора базы данных выбрать, что предпочтительнее — безопасность системы или администрирование большого числа индивидуаль" ных пользователей сервера. Другими словами, если администратор базы данных не обладает доста" точными ресурсами для контроля за сеансами работы индивидуальных пользователей, он может сознательно пойти на работу большого числа пользователей под одним или несколькими общими системными именами.

Серверные устройства Все компоненты SQL Server хранятся на дисковых накопителях, подключенных к серверному компь" ютеру. Программные компоненты сервера записаны в обычных файлах операционной системы, а структуры хранения данных и сами данные записываются в специальные области диска, называемые серверными устройствами (server devices, см. рис. 1.16). Sybase SQL Server может создавать серверные устройства как в виде обычных файлов операционной системы, так и в виде физических разделов же" сткого диска. Компания Sybase не осуществляет поддержку серверов, в которых серверные устройст" ва создаются в виде файлов, поскольку возможность восстановления данных после сбоев требует немедленной записи на диск результатов зафиксированных транзакций. При использовании файло" вых серверных устройств сбрасываемые на диск данные сначала попадают в буферы операционной системы, и сервер не имеет возможности проконтролировать факт их записи на диск. При авариях в вычислительной системе содержимое буферов операционной системы вместе со всеми находящими" ся в них результатами зафиксированных транзакций будет утрачено, и эти результаты не удастся вос" становить при восстановлении всей базы данных. Как правило, в качестве серверных устройств следует использовать физические разделы жестких дисков.

www.books-shop.com

Серверный компьютер

База данных 1

База данных 2

База данных 3

Рис. 1.16. Серверные устройства SQL Server Любой физический жесткий диск серверного компьютера может быть разбит (partitioned) на несколько разделов (partitions, см. рис. 1.17), большая часть которых обычно предназначается для хранения данных. Раздел жесткого диска либо включается в файловую структуру операционной си" стемы, либо используется как физический неформатированный раздел с небуферизованным досту" пом (raw partition). Неформатированные разделы находятся вне контроля операционной системы, что дает серверу возможность непосредственно контролировать все распределенные ему разделы дисков. Необходимо тщательно следить, чтобы разделы дисков, включенные в файловую систему, не использовались сервером в качестве неформатированных разделов, и наоборот. Подчеркнем, что единственная разница между небуферизованным разделом диска и разделом файловой систе" мы состоит в способе доступа к такому разделу. На уровне операционной системы доступ к диску может происходить как в блоковом, так и в байтовом режиме. Блоковый режим доступа к диску ис" пользуется при буферизованных обращениях к файловой системе, когда блоки перед их записью на диск формируются в буферах операционной системы. Байтовый доступ к диску применяется при непосредственной записи на диск без буферизации. Очень важно постоянно следить, чтобы доступ к каждому разделу каждого диска осуществлялся в соответствии с назначением этого разде" ла. Здесь легко совершить серьезную оплошность, которая не будет сопровождаться сообщениями сервера об ошибках. Различные аспекты использования серверных устройств подробно рассматри" ваются в главе 8. В операционной системе Solaris разделы дисков называются секциями (slices) раздел '0' = цилиндр О

раздел '2' = весь диск

каждый из разделов '1, '3', '4', '5', '6' занимает по 1/5 пространства диска, оставшегося после создания разделов '0' и 7'

раздел 7 = 50Мбайт.

Рис. 1.17. Разделы жесткого диска

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

при выполнении сервером резервного копирования базы данных

сервер использует одно из заранее сконфигурированных устройств вывода дампов

вывод резервной копии базы данных на диск

Магнитная лента Рис. 1.18. Прочие серверные устройства

вывод резервной копии базы данных на магнитную ленту

Термин "серверное устройство" также применяется к устройствам, используемым для создания дампов базы данных и загрузки ранее созданных дампов. Такие устройства могут представлять собой файлы операционной системы или накопители на магнитной ленте (рис. 1.18). Базы данных Каждый SQL Server способен одновременно поддерживать несколько баз данных. Приложениям тре" буется одна или несколько баз данных, используемых для хранения данных, логически связанных друг с другом. Различные приложения могут работать с несколькими базами данных, управляемыми одним сервером. Администратор баз данных индивидуально устанавливает такие параметры каждой из этих баз данных, как режим восстановления после сбоев, доступ только для чтения и т.д. Для нор" мальной работы SQL"сервера ему необходимы три системные базы данных — master, model и tempdb (рис. 1.19). Базы данных master и model служат исключительно для поддержания работоспособности сервера и не используются для хранения пользовательских данных, поэтому к их безопасности и регу" лярному резервному копированию следует относиться с особой тщательностью. Все остальные базы данных создаются пользователями по завершении процесса установки сервера.

Рис. 1.19. Базы данных SQL Server

www.books-shop.com

База данных master База данных master создается при первоначальной установке сервера на компьютере и представляет сердце сервера. Именно здесь хранятся системные таблицы с конфигурацией сервера, со списком его пользователей и устройств, а также с другой важнейшей информацией. Ни в коем случае не следует разрешать пользователям хранить свои данные в базе данных master. Эта база данных является важ" нейшим компонентом сервера, и необходимо постоянно следить за регулярным созданием ее резерв" ных копий. База данных model База данных model также создается при установке сервера и содержит шаблоны структуры базы дан" ных, используемые сервером при создании каждой новой базы данных. При внесении изменений в шаблоны эти изменения отражаются во всех базах данных, созданных впоследствии. Если все базы данных сервера должны обладать какими"либо общими элементами, то перед созданием этих баз дан" ных подобные элементы полезно включить в базу данных model База данных tempdb База данных tempdb представляет собой базу данных для хранения временных объектов. Она также со" здается в процессе установки сервера и используется сервером при выполнении сортировок данных и других сложных многоступенчатых операций. Содержимое базы данных tempdb не сохраняется при резервном копировании баз данных сервера, и сервер не обеспечивает восстановление этой базы данных после сбоев. Администратор базы данных может расширять базу данных tempdb, чтобы предо" ставить серверу достаточное пространство для хранения промежуточных результатов работы. При каждом запуске сервера производится полный сброс содержимого базы данных tempdb. Пользователи сервера также могут создавать свои временные таблицы в базе данных tempdb для хранения результа" тов запросов. Пользовательские базы данных Эти базы данных создаются для хранения данных, необходимых конкретным пользовательским при" ложениям. Transact+SQL Transact"SQL — это версия языка SQL, предложенная компанией Sybase. В то время как главной целью при разработке языка SQL было создание стандартного интерфейса между пользователем и данны" ми, каждая компания"поставщик РСУБД предпочла обзавестись своей собственной версией SQL, об" ладающей нестандартными расширениями, необходимыми для реализации возможностей, не включенных в стандартную версию SQL. С одной стороны, подобные нестандартные возможности предоставляют большую свободу выбора разработчикам прикладных систем, с другой стороны, их ис" пользование в большинстве случаев исключает переносимость созданного программного кода на базы данных других поставщиков (и даже на предыдущие версии баз данных того же самого постав" щика). Поэтому использовать нестандартные расширения SQL следует с осторожностью. Созданная Sybase версия SQL получила название Transact"SQL; она также обладает многими подобными расши" рениями. Необходимо отметить, что проблемы с несовместимостью порой оказываются более серь" езными, чем это может показаться на первый взгляд. Несколько лет назад Sybase могла по праву называть хранимые процедуры и триггеры уникальными особенностями Transact"SQL, теперь и дру" гие компании"поставщики РСУБД включили в свои версии SQL аналогичные расширения, обеспечи" вающие те же самые возможности и (в случае хранимых процедур и триггеров) имеющие те же самые названия. Однако это еще не означает, что хранимая процедура, написанная на Transact"SQL компа" нии Sybase, будет переносима в РСУБД любого другого поставщика, даже если реализованная там вер" сия SQL также поддерживает хранимые процедуры. Открытые системы, стандарты и искоренение закрытых интерфейсов обеспечат всех нас работой на много лет вперед. Объекты баз данных SQL Server поддерживает множество объектов, характерных для реляционных баз данных, — табли" цы, столбцы, правила, значения по умолчанию и типы данных, определяемые пользователем (рис. 1.3). Существуют также хранимые процедуры и триггеры, относящиеся к числу выполняемых объектов баз данных. Хранимая процедура представляет собой набор команд на языке Transact"SQL, постоянно находящихся в памяти сервера и запускаемых на выполнение при указании имени

www.books-shop.com

процедуры. Направив серверу имя необходимой процедуры, можно выполнить значительный объем обработки данных, не загружая сеть непроизводительным трафиком. Кроме того, хранимые процеду" ры защищены механизмами безопасности сервера. Другими словами, администратор базы данных может явно ограничить круг пользователей той или иной хранимой процедуры и даже потребовать, чтобы все обращения к серверу производились только через хранимые процедуры. В подобной ситуа" ции администратору становится известен набор запросов, направляемых на сервер, что дает ему воз" можность настроить сервер на наиболее эффективную обработку именно этих запросов. Хранимые процедуры могут обеспечивать соблюдение бизнес"правил, причем все приложения должны будут ис" пользовать одни и те же бизнес"правила. Такой подход значительно упрощает контроль за соблюде" нием бизнес"правил по сравнению с их реализацией в программном коде каждого отдельного приложения. Наконец, сервер сможет ограничиться построением плана выполнения хранимой про" цедуры только лишь перед ее первым вызовом; во всех последующих случаях серверу не придется вы" полнять повторную компиляцию хранимой процедуры. Таким образом, хранимые процедуры позволяют значительно повысить производительность сервера. Триггеры — это хранимые процедуры, активизируемые в ответ на запросы вида select, update, in" sert или delete; они срабатывают всякий раз, когда указанный запрос затрагивает одну или несколь" ко строк таблицы. Триггеры очень часто используются для поддержания ссылочной целостности. Термин "ссылочная целостность" подразумевает, что информация из одной таблицы оказывается связана с информацией из другой таблицы. Хорошим примером служат таблица заказов order и таб" лица order_detail с детальной информацией об этих заказах. Каждая строка таблицы order соответ" ствует отдельному заказу; одно или несколько полей строки содержат номер заказа. Тот же самый номер заказа должен быть указан в каждой записи таблицы order_detail с детальной информацией о заказах. Для соблюдения взаимосогласованности данных между таблицами order и order_detail необ" ходимо проследить, чтобы при внесении изменений в одну из таблиц соответствующие изменения вносились и в другую таблицу. К примеру, при изменении номера заказа в таблице order этот номер нужно изменить во всех записях таблицы order_detail, относящихся к данному заказу. В этом и за" ключается принцип ссылочной целостности, для обеспечения которой можно использовать тригге" ры, срабатывающие при внесении изменений в одну из таблиц и автоматически изменяющие данные всех связанных с ней таблиц. Разумеется, ссылочную целостность можно реализовать и не" посредственно во всех приложениях, использующих связанные таблицы. Триггеры, аналогично хра" нимым процедурам, позволяют избежать многократного программирования идентичных операций, а также гарантируют автоматическое соблюдение правил ссылочной целостности во всех запросах, затрагивающих такие таблицы, и обеспечивают централизованный контроль за используемыми биз" нес"правилами. Sybase SQL Server поддерживает кластеризованные и некластеризованные индексы. В Sybase SQL Server кластеризованный индекс означает, что все записи таблицы физически упорядочены в соот" ветствии с ключевым полем кластеризованного индекса. Таким образом, каждая таблица может иметь только один кластеризованный индекс и произвольное число некластеризованных индексов. Любопытной особенностью некластеризованного индекса является то, что указатели на записи таб" лицы, содержащиеся в листьях (концевых узлах) дерева индекса оказываются упорядоченными по ключевому полю этого индекса. Поэтому любой запрос, использующий только значения столбцов таблицы, входящих в некластеризованный индекс, может быть полностью выполнен путем просмот" ра этого индекса. В подобной ситуации принято говорить, что запрос целиком покрывается неклас" теризованным индексом; подобные запросы обрабатываются намного быстрее по сравнению с запросами, выбирающими равное число записей из самой таблицы. Для покрываемых запросов не" кластеризованный индекс по сути представляет собой кластеризованный индекс включенных в него столбцов таблицы. Это обстоятельство можно использовать при настройке сервера, если разнести табличные данные и некластеризованные индексы этих таблиц на разные дисковые накопители. При этом покрываемые запросы будут обрабатываться на одном диске, а все остальные — одновре" менно на другом диске. Пользователи Каждая база данных содержит информацию о том, кому из пользователей сервера разрешено пользо" ваться этой базой данных, и какие права доступа имеет каждый пользователь базы данных к каждому ее объекту. Таким образом, не все пользователи сервера являются пользователями базы данных (рис. 1.15). Пользователь сервера становится пользователем базы данных при его внесении в базу данных. После этого пользователю базы данных могут быть предоставлены права доступа к объектам базы

www.books-shop.com

данных и содержащейся в ней информации. Необходимо иметь в виду, что сервер хранит пароли пользователей сервера, но не пользователей базы данных. Сервер обладает развитой системой прав доступа и позволяет предоставлять пользователям раз" личный уровень доступа к данным и различные права модификации этих данных. Многообразие уровней защиты данных может заметно затруднить работу администратора базы данных, и поэтому имеет смысл придерживаться настолько простой схемы защиты, насколько это возможно. Напри" мер, все пользователи базы данных могут быть разделены на группы, или роли, с присвоением каж" дой такой группе определенного набора прав доступа (рис. 1.20). При добавлении новых пользователей базы данных их можно включать в одну из существующих групп, автоматически на" значая пользователю все полномочия, предусмотренные для данной группы. SQLServer база данных master

создание пользователя сервера

добавление пользователя сервера в базу данных пользовательская база данных добавление пользователя в группу группа пользователей имеет права доступа к объекту базы данных

пользователь базы данных имеет права доступа к объекту базы данных Рис. 1.20. Группы пользователей SQL Server Сопровождение сервера SQL Server требует постоянного и тщательного ухода, включающего множество разнообразных опе" раций. Администрирование сервера Пользователь 'sa' Пользователь SQL Server с системным именем 'sa' обладает полным контролем за сервером и имеет право доступа к любой базе данных и любому объекту (хранимой процедуре, триггеру и т.д.) этой базы данных. Обычно большинство объектов баз данных принадлежит именно пользователю 'sa', что упрощает выполнение многих задач по администрированию сервера. Отметим, что и все другие объ" екты, принадлежащие остальным пользователям, также доступны пользователю 'sa', поскольку этот пользователь может выступать в качестве любого другого пользователя сервера.

Владелец базы данных Другим выделенным пользователем сервера является владелец базы данных (database owner, dbo). Строго говоря, сервер не позволяет одному пользователю быть одновременно пользователем базы данных и ее владельцем. Обычно владельцем базы данных является пользователь сервера, создавший эту базу данных, но полномочия владельца могут быть переданы и другому пользователю сервера. В большинстве случаев владельцем всех баз данных сервера становится пользователь 'sa', что заметно облегчает администрирование сервера. Однако некоторые организации предпочитают разделить обязанности администратора сервера и администратора данных, хранящихся на сервере. В подобной ситуации каждая база данных может принадлежать определенному пользователю, отвечающему за вы" полнение всех операций над содержащимися в ней данными.

www.books-shop.com

Установка сервера Для установки SQL Server служит специальная программа, включенная Sybase в комплект поставки сервера. Программа установки автоматически создает на серверном устройстве master (специальной области дискового пространства) системные базы данных master, model и tempdb, а также устанавливает целый ряд системных хранимых процедур, необходимых для поддержания работоспособности серве" ра и контроля за его работой, создает пользователя сервера с именем 'sa', запускает сервер, создает журнал, или файл регистрации, ошибок и выполняет ряд других операций (рис. 1.21). Обратите вни" мание, что установка SQL Server версии 4.9.2 выполняется с помощью программы sybconfig, в то время как для установки SQL Server System 10 и 11 используется программа sybinit. программы sybconfig/sybinit входят в комплект поставки SQL Server

программа sybinit также устанавливает базу данных sybsystemprocs, необходимую для SQLServer System 10 и 11

Рис. 1.21. Установка SQL Server 4.9.2 Утилита isql Для подключения к серверу Sybase предлагает использовать утилиту isql (интерактивный SQL), ра" ботающую исключительно в текстовом режиме и обладающую весьма ограниченными возможностя" ми. Утилита isql всегда находится в вашем распоряжении и интенсивно используется в процессе установки, конфигурирования и эксплуатации SQL Server. Она позволяет подключиться к серверу и выполнить любую команду администрирования сервера или команду языка Transact"SQL. Переменные среды Читателю необходимо познакомиться с некоторыми переменными среды, или переменными окруже" ния, операционной системы. Переменная DSQUERY содержит имя SQL Server, к которому програм" ма"клиент будет обращаться по умолчанию, т.е. когда имя сервера не указано явно (рис. 1.23). Переменная среды серверной машины DSLISTEN используется сервером при его запуске, если серверу явно не указано его имя. Другими словами, переменная DSLISTEN содержит имя сервера, устанавливаемое по умолчанию при запуске сервера. После запуска сервер обращается к файлу интерфейсов серверной машины, чтобы определить номер порта, который ему предстоит использовать. Таким образом, наличие ло" кального файла интерфейсов необходимо для нормальной работы как программ"клиентов, так и сер" веров. Здесь нет ничего удивительного, поскольку каждый сервер может выступать в роли клиента другого сервера. Всем клиентам нужен интерфейсный файл, и серверы не являются здесь исключе" нием. Переменная среды SYBASE указывает местоположение базового (либо инсталляционного) ката" лога для программ Sybase и используется и клиентами, и серверами. Если программе"клиенту или серверу не указан полный путь к файлу интерфейсов, программа будет искать этот файл в каталоге, заданном переменной SYBASE.

www.books-shop.com

Серверный компьютер psycho

PSYCH0492 SQL Server PSYCH0492 работает на машине psycho и использует порт с номером 1025 # PSYCH0492 query tcp sun+ether psycho1025

Рис. 1.22. Утилита Isql

если имя сервера не указано явно, утилита isql использует значение переменной DSQUERY isql +Upsycho +Pshower

Серверный компьютер psycho

программа+клиент пользователя

SQL Server PSYCH0492 работает на машине psycho и использует порт с номером 1025 # PSYCH0492 query tcp sun+ether psycho1025

значение переменной DSQUERY, установленное в среде пользовательского процесса: %echo $DSQUERY PSYCH0492

Рис. 1.23. Переменная среды DSQUERY Запуск и останов сервера Для запуска SQL Server необходимо выполнить командный файл, вызывающий выполняемый про" граммный модуль сервера с различными параметрами (рис. 1.24). Останов же SQL Server осуществля" ется одним из двух следующих способов. Если сервер находится в работоспособном состоянии и к нему можно подключиться, то для его останова достаточно ввести команду shutdown (рис. 1.25). Если же сервер недоступен, то вам придется соответствующей командой операционной системы уничтожить системный процесс SQL"сервера (рис. 1.26).

www.books-shop.com

на серверной машине выполнить командный файл с именем RUN PSYCH0492. Его распечатка приведена ниже: #!/bin/sh # имя сервера: PSYCH0492 f порт dslisten: # раздел для устройства master: /dev/rsd1h # размер устройства master: 15360 DSLISTEN=PSYCH0492; export DSLISTEN /dba/sybase/bin/dataserver +d/dev/rsd1h +e/dba/sybase/install/errorlog_PSYCH0492 Рис. 1.24. Запуск SQL Server

Рис. 1.25. Останов SQL Server

на серверной машине определить идентификатор промесса SQL+сервера с помощью команды ps:

команду kill следует использовать лишь в крайнем случае, если совершенно необходимо остановить сервер, и это не удается сделать другими способами

Рис. 1.26. Останов сервера посредством уничтожения процесса SQL+сервера

www.books-shop.com

Проверка непротиворечивости базы данных (команда dbcc) Для нормальной работы SQL Server необходимо, чтобы структуры данных всех баз данных находи" лись в корректном и взаимно согласованном состоянии. Порча любой страницы данных или наруше" ние межстраничных связей может привести к аварийному останову сервера или порче других данных. Поэтому администратор базы данных должен периодически запускать команду dbcc (data" base consistency check) для поиска и исправления ошибок в структурах данных. При нерегулярном вы" полнении проверок с помощью команды dbcc можно оказаться в ситуации, когда базу данных не удастся восстановить даже по ее резервной копии. Sybase предоставляет команду dbcc (рис. 1.27). Ад" министратор базы данных самостоятельно определяет, какие именно возможности dbcc ему следует использовать и как часто должны выполняться проверки непротиворечивости. В идеале полный на" бор dbcc"проверок должен выполняться перед созданием каждого очередного дампа базы данных; од" нако это редко удается реализовать на практике. команда dbcc проверяет все страницы: + базы данных в целом

+таблиц + индексов

Рис. 1.27. Утилита dbcc Транзакции По умолчанию каждая отдельная команда SQL, направляемая на SQL Server для обработки, рассмат" ривается сервером как самостоятельная транзакция. Для того чтобы сервер рассматривал несколько SQL"предложений как единую транзакцию, необходимо предварительно сообщить серверу о начале транзакции, а после ввода последней команды SQL указать, что транзакция завершена. Подобную особенность следует учитывать при разработке приложений, а также во время непосредственной ра" боты с сервером. Если доступ к серверу осуществляется через приложение, посылающее на сервер на" бор SQL"предложений в виде единой транзакции, то либо все эти команды окажутся успешно выполненными, либо будут отвергнуты. Наоборот, при непосредственном подключении к серверу по" следовательный ввод тех же самых SQL"предложений по отдельности (т.е. без их объединения в тран" закцию) превратит каждую команду в самостоятельную транзакцию, и в случае невозможности успешного завершения некоторых команд только они окажутся отвергнутыми. В подобной ситуации результаты предыдущих успешно выполненных команд придется отменять вручную. Журналы транзакций В каждой базе данных, включая системные, ведется журнал транзакций, или журнал повтора, позво" ляющий SQL Server при необходимости восстановить результаты всех завершенных (зафиксирован" ных) транзакций. Для этого содержимое журналов транзакций должно регулярно сбрасываться (копироваться) в резервные копии. По мере того как выполняемая транзакция модифицирует дан" ные в кэш"буферах, исходные значения этих данных (исходная копия, или исходный вид записи) и их новые значения (конечная копия) заносятся в журнал транзакций (рис. 1.28). В этот момент соответ" ствующие разделы журнала транзакций также находятся в кэш"буфере, и информация из них перено" сится на диск только после фиксации транзакции. Записанные на диске журналы транзакций позволяют серверу при восстановлении базы данных полностью воспроизвести каждое изменение, сделанное в базе данных после создания последнего дампа базы данных. В результате сервер спосо" бен восстановить состояние базы данных на момент завершения последнего имеющегося журнала транзакций. Одновременно это означает, что при отсутствии резервных копий некоторых журналов транзакций, записанных после создания последнего дампа базы данных, эту базу данных удастся вос" становить только на момент начала записи первого отсутствующего журнала. 4—2221

www.books-shop.com

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

транзакция psycho l

транзакция psycho ll

транзакция

psycho II

Рис. 1.28. Журнал транзакций Многие из обсуждаемых в книге проблем производительности сервера оказываются так или ина" че связаны с необходимостью записывать каждую выполняемую транзакцию в журнал транзакций. Страницы данных В SQL Server нет единого термина для обозначения отдельных элементов дискового пространства и оперативной памяти. Чаще всего эти элементы называются страницами, или страницами данных. SQL Server устанавливает размеры страниц равными 2 Кбайт, или 2048 байт. Иногда одна 2"килобай" тная страница также называется блоком данных. В любом случае все данные записываются, читаются и обрабатываются сервером в виде порций по 2 Кбайт. Термин "страница данных" не означает, что она содержит исключительно данные. Речь идет об обрабатываемой сервером информации, включа" ющей в себя данные индексов, команды хранимых процедур, и, разумеется, таблицы данных пользо" вателя. Кэш*буфер данных Все операции над данными SQL Server выполняет только в специальной области оперативной памя" ти, называемой кэш"буфером данных (рис. 1.29). Он занимает часть всей распределенной серверу па" мяти; именно здесь находятся данные при их создании, выборке, модификации и удалении (SQL"командами insert, select, update и delete соответственно). Вся хранящаяся в базах данных инфор" мация физически находится на дисках, подключенных к серверному компьютеру, и для выполнения любой операции над данными страницы данных должны быть предварительно считаны с диска в кэш"буфер данных. После завершения обработки данных, когда внесенные в них изменения окажутся зафиксированными (т.е. приобретут статус постоянных), сервер запишет в журнал транзакций всю информацию, необходимую для восстановления состояния базы данных до начала транзакции и по" сле ее завершения. Когда кэш"буфер полностью заполнится данными, те страницы данных, которые не использовались в последнее время, окажутся вытесненными на диск. Разумеется, размер кэш"буфе" ра данных оказывает существенное влияние на производительность сервера, поскольку каждый эле" мент информации, запрашиваемый (и тем более модифицируемый) пользователем обязательно должен пройти через этот буфер. Алгоритм LRU/MRU Как отмечалось выше, все понадобившиеся серверу страницы данных перед обработкой считывают" ся в кэш"буфер данных (оперативную память). Однако размеры этого буфера не бесконечны, и через некоторое время серверу придется решать, какие страницы данных следует оставить в памяти, а ка" кие можно записать обратно на диск. Подобное решение принимается сервером с использованием

www.books-shop.com

выборка или модификация данных осуществляется сервером только после их переноса в кэш+буфер данных

зафиксированные (постоянные) изменения данных записываются обратно на диск Рис. 1.29. Кэш*буфер данных SQL Server алгоритма LRU/MRU, основанного на вытеснении из памяти давно не использовавшихся (Least Recently Used, LRU) страниц и сохранении страниц, использованных самыми последними (Most Recently Used, MRU). Такой подход основан на предположении, что давно не использовавшиеся стра" ницы вряд ли потребуются в ближайшем будущем, а страницы, недавно требовавшиеся серверу, веро" ятно, скоро вновь понадобятся ему. При обращении к странице данных сервер сперва ищет эту страницу в буфере и в случае успеха ставит ее первой среди недавно использованных страниц. При этом все остальные страницы буфера сдвигаются в противоположный его конец, содержащий наименее используемые страницы (рис. 1.30). Если необходимой страницы в буфере нет, сервер читает ее с диска и также помещает в начало буфера как самую свежую из последних использованных страниц. Все остальные страницы вновь должны сдвинуться в конец буфера; при переполнении буфера последняя из давно не исполь" зуемых страниц удаляется из буфера обратно на диск перед включением в него свежей страницы (рис. 1.31). серверу требуется страница данных номер 5, уже находящаяся в буфере

Рис. 1.30. Обращение к странице, уже находящейся в кэш*буфере данных

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

серверу требуется страница данных номер 12, отсутствующая в буфере

Рис. 1.31. Обращение к странице, не найденной в кэш+буфере данных Логические и физические операции ввода+вывода Перенос страницы кэш"буфера в его начало (рис. 1.30) представляет собой пример логической опера" ции ввода"вывода. Чтение страницы с диска и ее запись на диск (рис. 1.31) являются физическими операциями ввода"вывода, выполняемыми намного медленнее по сравнению с логическим вво" дом"выводом. С точки зрения производительности, операции физического ввода"вывода являются крайне дорогостоящими, и сокращение количества таких операций при обработке каждого запроса — одна из основных целей настройки производительности сервера. Перемещение страниц буфера В ситуации, когда все необходимые серверу страницы данных находятся в буфере, они постоянно пе" ремещаются из одного конца буфера в другой. Необходимость выгрузки какой"либо страницы на диск появляется только в случае, если серверу потребовалась новая страница, которой нет в буфере. Диспетчер буфера данных Диспетчер кэш"буфера данных следит за всеми страницами, в данный момент находящимися в буфе" ре, с помощью хеш"таблицы, содержащей идентификатор каждой страницы буфера (рис. 1.32). Хеш"таблица значительно ускоряет поиск необходимых серверу страниц, поскольку просмотр хеш"таблицы выполняется намного быстрее по сравнению с просмотром всех страниц буфера.

Рис. 1.32. Диспетчер кэш+буфера данных Блокировки Сервер базы данных должен поддерживать одновременную работу многих пользователей, каждый из которых направляет серверу свои SQL"запросы с обращениями к определенным страницам данных. Часто возникают ситуации, когда нескольким пользователям требуются одни и те же данные. Мы сталкиваемся с серьезной проблемой: каждый пользователь вправе считать, что база данных коррект" но отражает состояние деловых операций компании на определенный момент времени. К примеру,

www.books-shop.com

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

Рис. 1.33. Механизм блокировок Для SQL"сервера компании Sybase проблема блокировок имеет особую актуальность. Дело в том, что Sybase SQL Server обеспечивает блокировку только целых страниц данных и не поддерживает блокировку на уровне отдельных записей. Однако одна 2"килобайтная страница данных может со" держать значительное число записей данных (причем несколько пользователей нередко обращают" ся к разным записям одной страницы данных одновременно). В приведенном выше примере это означает, что для внесения единственной новой строки данных в таблицу соответствующему запро" су придется запросить блокировку целой страницы данных. После получения этой блокировки ника" кой другой процесс не сможет иметь доступ ни к одной из записей с этой страницы. Влияние подобного ограничения на производительность сервера часто обсуждается в литературе. Оно может оказаться особенно заметным, если в приложении используются короткие записи данных, значите" льное количество которых находится на одной странице данных. Подобная ситуация реализуется, к примеру, в классических системах оперативной обработки транзакций (On"Line Transaction Proces" sing, OLTP), предъявляющих особо высокие требования к производительности сервера. Здесь меха" низм постраничной блокировки способен привести к большому числу излишних блокировок и вызвать серьезное снижение производительности.

www.books-shop.com

серверный компьютер

прямая запись дампа базы данных на магнитную ленту

запись на магнитную ленту файлов сервера и ранее созданных дисковых файлов с дампами базы данных

Рис. 1.34. Резервирование базы данных Резервирование данных Создание резервных копий обслуживаемых сервером баз данных — неотъемлемая составная часть нормальной эксплуатации SQL"сервера. Процесс резервирования данных можно разделить на неско" лько регулярно выполняемых операций, представленных на рис. 1.34.

Дампы базы данных Один SQL Server способен поддерживать несколько баз данных; при этом информация из каждой базы данных резервируется по отдельности. Другими словами, для каждой базы данных (включая сис" темные) необходимо создавать отдельный дамп, причем только для баз данных, которые требуется восстанавливать после сбоев. Это позволяет сократить объем и количество создаваемых дампов баз данных, ограничив их лишь данными, представляющими реальную ценность. Если информацию, по" лучаемую из внешнего источника, резервировать не нужно, она может быть помещена в отдельную базу данных сервера, не включенную в обычную последовательность регулярного резервирования данных. SQL Server способен сбросить на диск или ленту дамп любой имеющейся на сервере базы дан" ных. Такой дамп содержит все объекты базы данных, имевшиеся в базе данных на момент создания дампа, и может быть прочитан только самим сервером. В большинстве случаев создание дампа отни" мает значительное время, поэтому не имеет смысла выполнять подобную операцию, когда с серве" ром работают пользователи. Обычно дампы баз данных создаются в периоды наименьшей нагрузки на сервер, чаще всего ранним утром. Дампы журналов транзакций Помимо дампов баз данных, сервер способен создавать дампы журналов транзакций, также сбрасыва" емые в дисковые файлы или непосредственно на магнитную ленту. Журнал транзакций представляет собой особую таблицу данных, непосредственно не связанную с другими таблицами базы данных и ис" пользуемую только для хранения записей, вносимых в журнал при выполнении каждого запроса, мо" дифицирующего хранящуюся в базе данных информацию. В журнале транзакций для каждой транзакции фиксируются исходные значения данных (исходные копии записей) и их измененные значения (конечные копии). Журналы транзакций хранятся отдельно от самой базы данных, чтобы позволить серверу при необходимости как можно быстрее получить доступ к записям регистрации транзакций, не занимаясь просмотром других структур базы данных. Поскольку журнал транзакций содержит только изменения, внесенные в базу данных каждой транзакцией, журналы транзакций оказываются значительно компактнее самих баз данных, и созда" ние дампов журналов транзакций занимает намного меньше времени. Это позволяет записывать дампы журналов транзакций во время работы пользователей (рис. 1.35). Важно подчеркнуть, что дампы базы данных отражают состояние базы данных только на момент создания дампа, и все по" следующие изменения резервируются исключительно в дампах журналов транзакций. Таким обра" зом, журналы транзакций дают в наше распоряжение механизм, позволяющий отразить в восстанавливаемой базе данных все изменения, сделанные после создания ее последнего дампа.

www.books-shop.com

дампы журналов транзакций

минимальная активность пользователей Рис. 1.35. Резервирование базы данных В процессе создания дампа журнала транзакций в файл дампа копируется текущее содержание этого журнала, после чего из рабочей копии журнала транзакций удаляются все записи о завершен" ных транзакциях. Точнее, записи о завершенных транзакциях удаляются вплоть до записи самой старой незавершенной транзакции (рис. 1.36). Транзакция является незавершенной, если она не была ни зафиксирована, ни подвергнута откату. Таким образом, создание дампа журнала транзакций освобождает в журнале место для регистрации новых транзакций. Регистрация транзакций в журна" ле — необходимое условие восстановления базы данных после сбоев. Поэтому, исчерпав свободное место в журнале транзакций, сервер приостанавливает обработку новых запросов. При эксплуата" ции любой базы данных, обеспечивающей работоспособность особо важных приложений, в перио" ды между записью ее полных дампов необходимо как можно чаще создавать дампы журналов транзакций. Любое приложение является особо важным, во всяком случае, с точки зрения его пользователей. Дампы файлов операционной системы Дампы баз данных и журналов транзакций являются ключевыми элементами процедуры резервирова" ния данных сервера. Не забывайте и о необходимости периодического резервирования некоторых журнал транзакций

дамп журнала транзакций

дополнительное свободное пространство •

Рис. 1.36. Очистка журналов транзакций

www.books-shop.com

файлов операционной системы серверной машины, в число которых следует включить файлы с про" граммным обеспечением Sybase, любые дисковые файлы с дампами баз данных и журналов транзак" ций, командные файлы установки и конфигурирования сервера и т.д. Восстановление данных Восстановление отдельной базы данных или всего сервера происходит на основе резервных копий данных и файлов сервера, созданных до момента сбоя. При отсутствии таких копий восстановление данных невозможно. Загрузка базы данных Загрузка базы данных из дампа приводит к полному уничтожению текущей копии восстанавливаемой базы данных. Загрузка базы данных возможна только при отсутствии работающих с ней пользовате" лей. После загрузки дампа базы данных ее состояние восстанавливается на момент создания дампа. Загрузка журналов транзакций Для восстановления базы данных после сбоя необходимо загрузить самый свежий из имеющихся пол" ных дампов базы данных. После этого в восстанавливаемую базу данных вносятся все изменения, со" храненные в дампах журналов транзакций (сохраняя последовательность, в которой эти дампы были созданы). Затем в базу данных загружается информация из текущего журнала транзакций (рис. 1.37). Успешное выполнение всех перечисленных выше операций позволит восстановить состояние базы данных непосредственно на момент сбоя. При отсутствии дампов журналов транзакций восстановле" ние базы данных возможно только на момент последнего полного дампа. Необходимо также иметь в виду, что дампы журналов транзакций образуют единую последовательность, простирающуюся во времени от момента создания последнего полного дампа базы данных и до момента сбоя. Дампы жур" налов транзакций должны загружаться строго в той последовательности, в которой они были созда" ны; при отсутствии хотя бы одного дампа процесс загрузки журналов транзакций завершится на первой транзакции из отсутствующего дампа. дампы журналов транзакций

полное восстановление базы данных загрузка полного дампа базы данных

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

загрузка дампов журналов транзакций Рис. 1.37. Порядок загрузки при полном восстановлении базы данных. Причина, по которой загрузка журналов транзакций возможна только до первого отсутствующе" го дампа, довольно проста. В процессе загрузки сервер повторяет все транзакции, внесенные в дамп журнала транзакций, и тем самым последовательно восстанавливает состояние базы данных вплоть до момента записи очередного дампа журнала транзакций. При отсутствии одного из дампов сервер не способен восстановить состояние базы данных на момент записи этого дампа, соответствующий началу следующего (возможно, имеющегося в наличии) дампа журнала транзакций. В результате вся записанная в последующие дампы информация теряет смысл, поскольку сервер не имеет возможно" сти привести базу данных в состояние, к которому следовало бы применить транзакции из сохра" нившихся журналов (рис. 1.38).

www.books-shop.com

сценарий 1: частичное восстановление из+за отсутствия или утраты всех дампов журналов транзакций

база данных восстановлена только на момент последнего полного дампа; утрачены все изменения, сделанные между 01:00 и 14:00

сценарий 2: частичное восстановление из+за отсутствия текущего журнала транзакций база данных восстановлена только на момент последнего дампа журнала транзакций; утрачены все изменения, сделанные между 12:00 и 14:00

загрузка дампов

дальнейшее восстановление невозможно

сценарий 3: частичное восстановление из+за частичного отсутствия дампов журналов транзакций база данных восстановлена только на момент последнего полного дампа; утрачены все изменения, сделанные между 01:00 и 14:00 дальнейшее восстановление невозможно

загрузка дампов журналов транзакций

Рис. 1.38. Частичное восстановление базы данных Зеркальное отображение дисков SQL Server поддерживает режим зеркального отображения серверных устройств, при котором сер" вер поддерживает точную копию каждого отображаемого устройства на другом диске (рис. 1.39). Назначение Напомним читателю, что серверное устройство представляет собой область физического диска, рас" пределенную серверу. Зеркальное отображение следует рассматривать как еще одну форму резерви" рования данных. При возникновении проблем с основным серверным устройством сервер автоматически переведет его в автономное состояние и переключится на зеркальную копию, исполь" зуя ее в качестве нового основного устройства. Зеркальное отображение позволяет серверу сохра" нить постоянную работоспособность даже в случае сбоя серверного устройства (либо диска, на котором оно находилось). Без зеркального отображения сбой любого серверного устройства приве" дет к прекращению работы всех баз данных, использовавших это устройство. Отказ главного устрой" ства (master device) означает полный останов сервера.

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

www.books-shop.com

серверное устройство sdlb

дисковый раздел с небуферизованным доступом /dev/rsd6b

главное серверное устройство

вторичное серверное устройство (зеркальная копия)

Основное серверное устройство sdlb и его зеркальная копия, или встроенное устройство (/dev/rsd6b), вместе образуют единую зеркальную пару, по+прежнему рассматриваемую сервером как единое логическое серверное устройство с именем 'sdlb'. Рис. 1.39. Зеркальное отображение серверных устройств Зеркальное отображение средствами сервера или операционной системы? Зеркальное отображение дисков может выполняться не только средствами Sybase SQL Server, но и на уровне операционной системы. Главное преимущество зеркального отображения на уровне операци" онной системы заключается в том, что средства ОС позволяют осуществлять зеркальное резервиро" вание всех дисков серверного компьютера, в том числе и не используемых сервером. Кроме того, средства ОС способны обнаружить возникновение более широкого спектра проблем с дисковыми на" копителями, чем SQL Server. Основная ответственность за организацию зеркального отображения средствами ОС ложится на системного администратора серверной машины, который не всегда ясно понимает, какие компоненты сервера должны дублироваться в первую очередь. Кроме того, систем" ный администратор может оказаться недостаточно подготовленным к решению этой задачи. Масштабируемость Масштабируемость обозначает способность сервера справляться с постоянно возрастающим числом пользователей и нагрузкой при одновременном расширении возможностей аппаратного обеспече" ния вычислительной системы, на которой работает этот сервер. Предположим, что на однопроцес" сорной машине сервер обеспечивает приемлемое время реакции для 100 одновременно работающих пользователей. При добавлении в систему второго процессора хорошо масштабируемый сервер смо" жет либо обслуживать 200 пользователей при сохранении прежнего времени реакции, либо сокра" тить время реакции вдвое при прежнем числе пользователей. Поисковые ядра Системный процесс, представляющий собой работающий программный модуль сервера, называется поисковым ядром (server engine). На одном компьютере может быть запущено несколько поисковых ядер одновременно (каждое из них будет выступать в качестве отдельного системного процесса), со" вместно использующих оперативную память серверной машины и ее пространство дисков (рис. 1.40). На однопроцессорной системе запуск нескольких поисковых ядер приведет лишь к их конкуренции за единственный процессор, и в результате резкого возрастания страничного обмена производитель" ность системы может упасть практически до нуля. С появлением многопроцессорных систем параллельный запуск нескольких серверных ядер способен значительно повысить общую производительность сервера. Оптимальное соотношение между числом одновременно работающих ядер и количеством имеющихся процессоров зависит от конкретного приложения и конкретной системы, и единственным способом его определения слу" жит метод проб и ошибок, т.е. варьирование числа ядер с одновременным контролем за произво" дительностью сервера.

www.books-shop.com

серверный компьютер

каждое поисковое ядро представляет собой отдельный системный процесс, работающий на серверном компьютере

операционная система контролирует переключение серверных процессов между имеющимися процессорами

SQL Server распределяет запросы пользователей между поисковыми ядрами все поисковые ядра выполняются на общем поле оперативной памяти и дисков

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

Сетевой ввод*вывод Во всех версиях SQL Server, за исключением System 11, поисковое ядро с номером 0 (т.е. поисковое ядро, запущенное первым) обслуживает все без исключения операции сетевого ввода"вывода, осуще" ствляемые всеми остальными поисковыми ядрами. Напомним, что подключение пользователя к сер" веру, направление серверу запросов на обработку и пересылка пользователю результатов выполнения запросов осуществляются только по сети. В результате при увеличении количества поль" зователей и одновременно выполняемых запросов серверу приходится чаще ожидать завершения операций сетевого ввода"вывода. Поскольку такие операции выполняются через ядро 0, всем осталь" ным поисковым ядрам для завершения своих операции сетевого ввода"вывода приходится дожидать" ся освобождения ядра 0 (рис. 1.41). В подобной ситуации добавление новых процессоров и новых поисковых ядер не приведет к повышению производительности, поскольку новые ядра также будут бесполезно дожидаться освобождения ядра 0. Таким образом, насыщение сетевого ввода"вывода слу" жит одним из факторов, ограничивающих масштабируемость Sybase SQL Server.

Журнал транзакций В каждой обслуживаемой сервером базе данных ведется свой журнал транзакций, где регистрируются все изменения, вносимые в базу данных. Поэтому обработка практически всех модифицирующих базу данных запросов с неизбежностью включает в себя запись в журнал транзакций. Журнал транзакций является обычной таблицей, и все новые записи заносятся в журнал транзакций на последнюю стра" ницу этой таблицы. Поскольку SQL Server способен устанавливать блокировки только на уровне це" лых страниц, все текущие транзакции, кроме одной, вынуждены ожидать предоставления им блокировки к последней странице журнала транзакций (рис. 1.42). Увеличение числа одновременно работающих поисковых ядер также не может служить выходом из положения, поскольку это увели" чит количество незавершенных транзакций, ожидающих регистрации в последней странице журнала транзакций.

www.books-shop.com

Рис. 1.41. Перегрузка сетевого ввода*вывода

Рис. 1.42. Конкуренция при записи в журнал транзакций Кэш буфер данных Перед обработкой все данные считываются сервером в кэш"буфер (оперативную память), что также ограничивает масштабируемость сервера в силу двух следующих причин. Во"первых, при обращении к странице данных сервер проверяет ее наличие в кэш"буфере, про" сматривая хеш"таблицу, поддерживаемую диспетчером буфера и содержащую информацию обо всех таблицах данных, находящихся в буфере. Просмотр хеш"таблицы выполняется значительно быстрее по сравнению с просмотром всего содержимого буфера. С ростом числа одновременно работающих поисковых ядер возрастает и поток обращений к буферу, в то время как диспетчер буфера успевает отразить в единой хеш"таблице ограниченное количество произошедших в буфере изменений. Уве" личение числа ядер лишь усугубляет эту проблему (рис. 1.43). Во"вторых, процесс использования кэш"буфера данных при наличии большого количества одно" временно работающих серверных ядер обладает некоторыми особенностями. Пусть какому"то из за" просов достаточно одной страницы таблицы данных, и эта страница уже находится в буфере, в то время как второй запрос выполняет полный просмотр большой таблицы, все страницы которой не смогут поместиться в буфере одновременно. По мере считывания новых страниц с диска они после" довательно перемещаются от начала буфера в его конец и затем отправляются обратно на диск. Ра" зумеется, при этом единственная страница, необходимая первому запросу, также окажется

www.books-shop.com

хеш+таблица отслеживает информацию обо всех страницах данных, в данный момент находящихся в буфере

одновременно работающие поисковые ядра начинают конкурировать за доступ к хеш+таблице

Рис. 1.43. Конкуренция за доступ к кэш*буферу данных выгруженной на диск (рис. 1.44). Подобная ситуация реализуется при одновременной работе на сер" вере как приложений оперативной обработки транзакций (On"Line Transaction Processing, или OLTP), так и систем поддержки принятия решений (Decision Support System, DSS). OLTP"приложе" ния (к примеру, система приема заказов) обычно генерируют короткие запросы к одним и тем же страницам данных, но требуют быстрой обработки таких запросов. Системы поддержки принятия решений, наоборот, отличаются сложными запросами, включающими просмотр большого количест" ва страниц данных. К примеру, в такой системе приложение генерации отчетов регулярно просмат" ривает все заказы, принятые за определенный период времени, и вычисляет общие объемы продаж. Естественно, выполнение DSS"запроса займет длительное время, и все это время новые страницы таблицы продаж, непрерывно считываемые DSS"запросом с диска, будут быстро вытеснять из памя" ти те несколько страниц, которые необходимы OLTP"запросам. Таким образом, серверу придется постоянно считывать эти страницы с диска, что не только существенно замедлит обработку OLTP"запросов, но и снизит общую производительность сервера из"за резкого увеличения объемов физического ввода"вывода. Добавление новых поисковых ядер только увеличит количество одновре" менно обрабатываемых запросов и количество разных страниц данных, запрашиваемых ими.

страница 12 читается с диска и помещается в начало буфера страницы 1 +7 сдвигаются к концу буфера страница 8 удаляется из буфера на диск Поскольку DSS+запросу необходимо произвести сканирование большой таблицы, сервер последовательно читает страницы этой таблицы с диска и помещает их в начало буфера, в результате чего все остальные страницы сдвигаются в конец буфера и постепенно выгружаются из памяти. Поэтому OLTP+запросам приходится постоянно дожидаться повторной загрузки в память необходимых им нескольких страниц. Рис. 1.44. Конкуренция между OLTP* и DSS*приложениями за доступ к кэш*буферу данных

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Рис. 1.45. Конкуренция при добавлении новых записей в таблицу Добавление данных в таблицы Каждая новая строка данных добавляется сервером в конец соответствующей таблицы, т.е. на ее по" следнюю страницу (некоторые схемы индексирования позволяют избежать этого). Здесь мы опять сталкиваемся с ситуацией, рассмотренной при обсуждении доступа к журналу транзакций, когда мно" жественные запросы начинают конкурировать за право доступа к последней странице таблицы дан" ных. Увеличение числа ядер только усугубляет эту проблему (рис. 1.45). Производительность Оптимизатор запросов Оптимизатор запросов используется сервером для предварительной оценки "стоимости" выполнения каждого полученного запроса. Стоимость обработки запроса складывается из объема операций вво" да"вывода, необходимых для выполнения запроса, и всех других операций, которые придется выпол" нить серверу. Оценка стоимости учитывает количество просматриваемых таблиц и число строк в этих таблицах, наличие индексов, ускоряющих выборку небольшого числа записей, возможные стра" тегии объединения структур данных и т.д. Оптимизатор запросов должен принять во внимание все подобные факторы и найти оптимальный способ выполнения запроса. Как правило, деятельность оп" тимизатора запросов сводится к уменьшению количества операций физического ввода"вывода, необ" ходимых для считывания данных с диска в кэш"буфер. Оптимизатор запросов также принимает во внимание и операции логического ввода"вывода, представляющие собой обращения к страницам дан" ных, уже находящимся в буфере, однако по своей стоимости физический ввод"вывод намного превы" шает логический. Успешная работа оптимизатора запросов зависит от множества факторов. Поскольку сервер всецело полагается на оптимизатор запросов при анализе каждого полученного за" проса, к числу основных обязанностей администратора базы данных относится поддержание струк" тур служебных данных сервера, позволяющих оптимизатору запросов эффективно справляться со своими обязанностями. В первую очередь, необходимо регулярно обновлять статистические данные, собираемые сервером обо всех таблицах всех баз данных, обслуживаемых сервером. На основе этой статистической информации оптимизатор запросов оценивает количество записей таблицы, выбира" емых каждой частью рассматриваемого запроса. Если подобная информация будет отсутствовать либо окажется устаревшей, оптимизатор запросов может принять решения, весьма далекие от опти" мальных, что неблагоприятно отразится на производительности сервера. Хранимые процедуры Каждый запрос, полученный сервером, обязательно должен быть проанализирован оптимизатором запросов. Одно это делает использование хранимых процедур крайне важным средством повышения производительности сервера. Хранимые процедуры обрабатываются оптимизатором запросов во время компиляции, которая обычно выполняется только при их создании. После завершения

www.books-shop.com

запрос приложения

тексты всех SQL+запросов передаются по сети

по сети передается только команда 'exec sproc1'

Рис. 1.46. Хранимые процедуры компиляции план выполнения входящих в хранимую процедуру запросов запоминается сервером и затем используется при каждом последующем вызове этой процедуры. Это также означает, что SQL"команды хранимой процедуры постоянно находятся в памяти SQL Server и для их выполнения клиенту достаточно одной команды, направленной на сервер (рис. 1.46). Хранимые процедуры позво" ляют клиентам избежать передачи по сети полных текстов SQL"запросов, тем самым значительно со" кращая объем сетевого трафика. Индексы Использование индексов дает серверу возможность значительно ускорить поиск необходимых дан" ных. Рассмотрим различные типы индексов, поддерживаемые SQL Server. Кластеризованные индексы При создании кластеризованного индекса таблицы сервер физически упорядочивает строки этой таблицы в соответствии со значениями столбца таблицы, указанного в качестве ключа при создании индекса (рис. 1.47). К примеру, при создании кластеризованного индекса таблицы сотрудников ком" пании, в котором в качестве ключа будет использоваться поле табельного номера, сервер разместит записи таблицы на диске по порядку табельных номеров сотрудников. При последующем добавлении в таблицу каждого нового сотрудника сервер проверит значение его табельного номера и, записывая новую строку на диск, физически вставит ее на нужное место между существующими записями. Разработчики некоторых приложений могут предполагать, что табельный номер каждого нового сотрудника обязательно должен на единицу превышать максимальный из уже существующих номе" ров. В подобном случае каждая новая запись обязательно будет добавляться на последнюю страницу таблицы. Это немедленно приведет к конфликту за блокировку доступа к этой странице и замедле" нию обработки запросов сервером, поскольку в каждый момент только один запрос сможет рабо" тать с этой страницей, Для решения подобной проблемы в некоторых приложениях к каждой строке данных добавляется специальное поле, содержащее случайное число, сгенерированное сер" вером. Затем серверу дается команда на создание кластеризованного индекса не по табельным номе" рам сотрудников, а по полю со случайными значениями. В результате записи таблицы оказываются

www.books-shop.com

кластеризованный индекс с ключом Еmр# (табельный номер)

страницы табличных данных

корневая страница индекса

листовые страницы кластеризованного индекса

указатели на страницы следующего уровня

страницы кластеризованного индекса Рис. 1.47. Кластеризованный индекс размещенными в случайном порядке, и каждая новая строка данных попадает в произвольное место таблицы, тем самым исключая конфликт за доступ к последней странице. Это пример того, как про" думанное использование индексов позволяет избежать снижения производительности сервера. Рас" смотренный пример наглядно демонстрирует, что стратегия индексирования таблицы существенно зависит от ее содержания и характера получаемых запросов. Проблема повышения производитель" ности сервера с помощью построения оптимальных индексов является весьма запутанной и требует тщательного мониторинга работы сервера. Кластеризованные индексы исключительно эффективны при обработке запросов на выборку за" писей, в которых значения поля должны находиться в определенном интервале (при условии, что это поле является ключом кластеризованного индекса). К примеру, необходимо найти всех сотруд" ников, табельные номера которых находятся в промежутке между X и Y. Сервер с помощью класте" ризованного индекса быстро найдет строку таблицы с табельным номером X, после чего прочитает в кэш"буфер данных все страницы данных таблицы вплоть до записи с табельным номером Y. Подоб" ный метод обработки запроса окажется намного быстрее последовательного поиска записей с нуж" ными значениями табельных номеров, осуществляемого по страницам данных. Для каждой таблицы может быть создан только один кластеризованный индекс. Более того, при вставке каждой новой записи в эту таблицу серверу придется освободить место на диске для этой за" писи, что потребует перемещения значительного числа существующих записей. При создании клас" теризованного индекса к существующей таблице необходимо иметь достаточно свободного места для новой копии этой таблицы, поскольку после выполнения сортировки таблицы сервер действи" тельно разместит на диске ее новую копию, упорядоченную в соответствии с только что созданным индексом.

www.books-shop.com

Emp#, First_Name (табельный номер, имя сотрудника)

страницы некластеризованного индекса Рис. 1.48. Некластеризованный индекс Некластеризованные индексы Любая таблица может иметь несколько некластеризованных индексов, не требующих соответствия между порядком записей в таблице и порядком значений ключевых полей такого индекса. При созда" нии некластеризованного индекса упорядочиваются только сами значения ключей. Рядом с каждым ключом запоминается указатель на соответствующую строку таблицы данных (рис. 1.48). При поиске определенной строки таблицы сервер сначала находит в индексе указатель на страницу и лишь после этого считывает в память саму строку данных. Если все необходимые серверу данные уже содержатся в ключе индекса, сервер не будет обращаться к табличным записям. Подобные запросы, которые можно выполнить исключительно с помощью значений ключей некластеризованного индекса, назы" ваются покрываемыми. Обработка покрываемых запросов выполняется особенно быстро, поскольку для покрываемых запросов некластеризованный индекс по сути является кластеризованным индек" сом таблицы, образованной из ключевых полей индекса. При добавлении в таблицу новых записей или модификации ключевых полей существующих за" писей серверу необходимо отразить сделанные изменения во всех некластеризованных индексах, связанных с данной таблицей. Поиск оптимального соотношения между преимуществами некласте" ризованных индексов (ускорение доступа к данным) и затратами на их сопровождение представляет собой нелегкую задачу.

www.books-shop.com

сегменты отсутствуют ++ любой объект может размещаться на любом диске

конфигурация с использованием сегментов

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

Рис. 1.49. Сегменты Сегменты Объекты баз данных размещаются сервером на дисках. По мере того как эти объекты увеличивают" ся в размерах и требуют все больше места, сервер будет использовать дополнительное дисковое пространство, размещая все объекты базы данных на одном и том же диске. Администратор базы данных может повысить производительность сервера, заранее побеспокоившись о размещении от" дельных объектов базы данных на различных дисках (рис. 1.49). К примеру, данные и индексы час" то используемой таблицы можно разнести на разные диски, что позволит серверу одновременно просматривать индекс при обработке одного запроса и выбирать данные из таблицы для другого за" проса. Подобная конфигурация дискового пространства требует использования сегментов — назва" ний, присваиваемых области дискового пространства, находящейся на одном или нескольких серверных устройствах. После назначения сегментов администратор базы данных может создавать объекты базы данных в определенных сегментах. При правильной конфигурации дисковое про" странство сегмента будет использоваться только объектами данных, помещенными администрато" ром базы данных в этот сегмент. Тиражирование данных Подробное обсуждение принципов тиражирования, или репликации, данных выходит за рамки на" шей книги. Отметим лишь, что Sybase предлагает специальный программный продукт под названием Replication Server (сервер тиражирования), поддерживающий при совместном использовании с SQL Server репликацию данных между узлами распределенных информационных систем. Хотя процедуры репликации данных и их реализация на сервере тиражирования достаточно сложны, администрато" ру баз данных необходимо знать о существовании Replication Server, т.к. в дальнейшем будет обсужда" ться взаимосвязь этой программы с SQL Server. Отметим, что при переходе к новой версии SQL Server в системе, использующей сервер тиражирования, необходимо принять во внимание ряд допол" нительных обстоятельств. Работа сервера тиражирования основана на отслеживании журнала транзакций основной базы данных с помощью диспетчера передачи транзакций (Log Transfer Manager, LTM) — одного из ком" понентов сервера тиражирования. Обнаружив транзакцию, модифицирующую данные в основной таблице, диспетчер передачи транзакций направляет серверу тиражирования запись регистрации этой транзакции. Сервер тиражирования определяет, какие именно данные должны быть переданы по сети, после чего на основании записей журнала транзакций воспроизводит исходную транзакцию в копии основной таблицы на вторичном сервере (рис. 1.50).

www.books-shop.com

Рис. 1.50. Sybase Replication Server SQL Server System 10 С выходом в свет SQL Server System 10 в ряде компонентов сервера произошли существенные измене" ния, значительно расширившие его возможности. Сервер архивации (Backup Server) До появления System 10 создание и загрузка дампов баз данных и журналов транзакций осуществля" лись непосредственно сервером, что негативно сказывалось на его производительности. В System 10 процесс создания и загрузки дампов вынесен из SQL Server в сервер архивации (рис. 1.51), представ" ляющий собой отдельный системный процесс, выполняющийся параллельно с SQL Server. Запуск сервера архивации и мониторинг его работы также производятся отдельно, однако сервер архива" ции должен быть включен в файл интерфейсов сервера. Кроме того, сервер архивации представляет собой отдельный программный продукт, но поставляется совместно с SQL Server. SQL Server спосо" бен выполнять создание дампов либо их загрузку только после установки и запуска способного взаи" модействовать с ним сервера архивации.

www.books-shop.com

SQL Server использует сервер архивации при создании и загрузке любых дампов Сервер архивации является отдельным системным процессом

Рис. 1.51. Сервер архивации (Backup Server)

Совместимость с предыдущими версиями Базы данных SQL Server System 10 несовместимы с базами данных, созданными сервером вер" сии 4.9.2; в частности, в сервер System 10 нельзя загрузить дамп базы данных, созданный сервером предыдущей версии. Все базы данных, обслуживаемые сервером System 10, должны обязательно быть в формате System 10. Переход от сервера 4.9.2 к System 10 требует внесения изменений в существую" щие системные и пользовательские базы данных. После завершения перехода на System 10 все дампы баз данных, созданные в предыдущей версии сервера, оказываются бесполезными. Единственный возможный способ миграции от SQL Server 4.9.2 к System 10 заключается в уста" новке сервера System 10, создании баз данных, по размерам не уступающих существующим базам дан" ных сервера 4.9.2, и последовательном переносе всех объектов баз данных из сервера 4.9.2 в System 10 с помощью заранее подготовленных командных файлов либо вручную. Перенос объектов баз данных включает в себя копирование данных из таблиц сервера 4.9.2 в файлы утилитой Ьср с последующей загрузкой данных из этих файлов в аналогичные таблицы сервера System 10 с помо" щью версии утилиты bср, входящей в состав сервера System 10. Несмотря на всю громоздкость по" добной процедуры, обычно существуют достаточно веские причины, делающие переход на новую версию сервера желательным. Пользовательские роли В System 10 появилась концепция ролей пользователей. Каждому пользователю сервера может быть одновременно присвоено несколько ролей, определяющих круг операций, разрешенных этому поль" зователю. Некоторые из пользовательских ролей описаны ниже: sa_role Роль sa_role дает пользователю возможность выполнять некоторые обязанности системного адми" нистратора (пользователя 'sa'), но не наделяет ее владельца всеми правами пбльзователя 'sa'. Она не дает, например, возможности создавать новых пользователей сервера или изменять пароли существу" ющих пользователей. sso_role Роль sso_role дает пользователю возможность выполнять обязанности ответственного за безопас" ность системы (System Security Officer, SSO), в частности добавлять новых пользователей сервера и изменять пароли ранее созданных пользователей. Обладатель роли sso_role имеет право при необ" ходимости изменить пароль пользователя 'sa'.

www.books-shop.com

operator_role Эта роль требуется каждому пользователю, которому необходимо создавать дампы базы данных. С практической точки зрения, в большинстве систем администратору базы данных необходимо обладать всеми тремя перечисленными выше ролями — sa_role, sso_role и operator_role. Разделение этих ролей далеко не всегда является оправданным; лишь в очень крупных информаци" онных системах количество пользователей достаточно велико для того, чтобы поручить отдельному сотруднику отвечать за регистрацию новых пользователей сервера. ' Новые системные базы данных Для размещения системных хранимых процедур в System 10 используется новая системная база дан" ных sybsystemprocs. Ранее системные процедуры (такие, как процедура sp_who) хранились в базе дан" ных master. System 10 также поддерживает развитые возможности аудита, основанные на использовании таблиц базы данных sybsecurity. Новые системные базы данных SQL Server System 10 представлены на рис. 1.52.

база данных master

база данных mode/

база данных tempdb

база данных sybsystemprocs

база данных sybsecurity

используется для размещения системных хранимых процедур, в предыдущей версии сервера находившихся в базе данных master предназначена для поддержки аудита работы сервера

Рис. 1.52. Системные базы данных System 10 Обеспечение безопасности System 10 поддерживает блокировку работы отдельных пользователей сервера, что дает возможность администратору базы данных заблокировать доступ пользователя к серверу вместо полного удаления этого пользователя, избежав тем самым ряда проблем, возникающих при повторном использовании системного идентификатора ранее существовавшего пользователя. Подобные проблемы могут воз" никнуть, например, при переносе дампов баз данных между различными серверами. Сервер System 10 обладает средствами аудита на основе специальной базы данных sybsecurity, кото" рые позволяют отслеживать характер использования различных объектов баз данных и выполнять другие операции. Средства аудита весьма полезны при решении вопросов безопасности сервера, од" нако они не обеспечивают контроль за его производительностью. Более того, использование средств аудита негативно отражается на общей производительности сервера и при возникновении проблем с базой данных аудита может привести к полной остановке работы сервера. SQL Server System 11 В Sybase SQL Server System 11 появилось множество новых возможностей, причем использование не" которых из них представляет собой весьма нетривиальную задачу. Обсудим кратко основные черты этих нововведений, чтобы показать читателю процесс непрерывной эволюции Sybase SQL Server.

www.books-shop.com

Более подробно новые возможности System 11 будут обсуждены в главах 2"6. Все рассматриваемые из" менения в System 11 призваны решить проблемы с неудовлетворительной масштабируемостью Sys" tem 10 и позволить серверу эффективно использовать возможности современных вычислительных систем с симметричным мультипроцессированием (SMP). По мере того как производители аппарат" ных средств предлагали системы с большим количеством процессоров, становилось все более оче" видным несовершенство архитектуры сервера System 10 и предыдущих версий, серьезно ограничивающее его производительность на таких системах. Другими словами, несмотря на широкое распространение многопроцессорных платформ, производительность SQL Server System 10 продол" жала оставаться примерно на одном уровне. Необходимо отметить, что на однопроцессорных компьютерах сервер System 11 едва ли спосо" бен проявить свои преимущества в производительности. System 11, по сравнению с System 10, позво" ляет значительно повысить производительность сервера, но только на многопроцессорных вычислительных платформах. Приложения, производительность которых ограничена не ресурсами процессора, а другими факторами, могут вообще не ускориться от перехода на System 11. Масштаби" руемость позволяет добиться лучшей производительности только при условии, что дополнительные поисковые ядра постоянно загружены работой.

Многопроцессорные конфигурации До появления System 11 из всех одновременно работающих поисковых ядер лишь одно ядро было способно непосредственно взаимодействовать с сетью (рис. 1.41). В результате прежние версии сер" вера не могли полностью использовать ресурсы дополнительных процессоров, поскольку значитель" ную часть времени эти процессоры ожидали освобождения ядра, отвечающего за операции сетевого ввода"вывода. System 11 не имеет подобного ограничения. Именованные кэш+буферы Все версии SQL Server, предшествовавшие System 11, использовали один общий кэш"буфер, который занимал все пространство распределенной серверу области оперативной памяти серверной машины, оставшееся свободным после загрузки выполняемого кода сервера и создания в памяти необходимых структур для контроля за сеансами работы пользователей, серверными устройствам и т.д. Некоторая часть кэш"буфера предназначалась для размещения хранимых процедур, а вся остальная память испо" льзовалась в качестве кэш"буфера данных, в котором SQL Server выполнял все операции по обработке информации, хранящейся в базах данных сервера. Любые необходимые серверу данные перед их об" работкой загружались в кэш"буфер данных; при заполнении буфера давно не использовавшиеся стра" ницы данных выгружались обратно на диск, и освободившееся место позволяло загрузить в буфер новые страницы. Подобная организация памяти была эффективной только при условии, что кэш"бу" фер способен вместить большинство часто используемых страниц данных (в идеальном случае — все такие страницы). Если какой"то один запрос загружает в буфер большое количество страниц данных, то практически все ранее находившиеся там страницы должны быть выгружены на диск. При этом серверу приходится выполнять большой объем непроизводительных физических операций ввода"вы" вода, что существенно замедляет его работу. SQL Server System 11 позволяет администратору базы данных присвоить имена отдельным областям кэш"буфера данных и затем назначить объектам базы данных индивидуальные области буфера (рис. 1.53). В результате определенная таблица базы данных или индекс после загрузки в кэш"буфер будут оставаться там продолжительное время, даже при ин" тенсивном страничном обмене в какой"то другой именованной области буфера. Настройка размеров блоков ввода+вывода System 11 позволяет администратору базы данных устанавливать для различных операций ввода"выво" да индивидуальные размеры блоков ввода"вывода в пределах от 2 до 16 Кбайт (от 1 до 8 страниц дан" ных размером по 2 Кбайт, см. рис. 1.54). В некоторых ситуациях (например, загрузке больших объемов данных) эта возможность позволяет значительно повысить производительность сервера. Предыдущие версии SQL Server осуществляли все операции ввода"вывода исключительно блоками по 2 Кбайт. Журнал транзакций Каждая выполненная сервером транзакция должна внести произведенные изменения в журнал тран" закций, поэтому конкуренция за право доступа к этому журналу всегда серьезно ограничивала произ" водительность сервера. Всем одновременно обрабатываемым запросам приходилось дожидаться своей очереди на получение единоличного доступа к журналу транзакций. В System 11 для каждого

www.books-shop.com

все остальные объекты баз данных

Рис. 1.53. Именованные буферы данных System 11

Рис. 1.54. Именованные буферы данных System 11 и буферные области с большими блоками ввода*вывода пользователя в кэш"буфере создается отдельный буфер журнала транзакций (User Log Cache, ULC; см. рис. 1.55). После заполнения пользовательского буфера журнала транзакций или завершения транзакции содержимое индивидуального буфера журнала транзакций заносится на диск в общий журнал. Подобный подход значительно увеличивает количество пользователей, одновременно под" держиваемых сервером, а на многопроцессорных системах исключает конкуренцию за доступ к жур" налу транзакций даже при очень большом числе работающих пользователей.

Рис. 1.55. Пользовательский буфер журнала транзакций (ULC) в System 11

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Сегментированные таблицы При одновременном добавлении многими пользователями данных в одну и ту же таблицу возникает проблема, аналогичная конкуренции за доступ к журналу транзакций. Sybase SQL Server поддержива" ет блокировку доступа только на уровне страниц данных, поэтому всем пользователям, кроме одного, придется ожидать возможности внести свою строку в последнюю страницу данных таблицы. Дело в том, что при отсутствии кластеризованного индекса все новые строки добавляются сервером именно в последнюю страницу таблицы. System 11 решает эту проблему с помощью сегментирования таблиц. При этом новые строки могут добавляться в различные участки таблицы, а не исключительно в ее ко" нец (рис. 1.56).

Рис. 1.56. Сегментирование таблиц в System 11

Мониторинг и настройка сервера Сервер System 11 предоставляет администратору огромное число новых возможностей настройки и контроля за его работой, что одновременно является и важным преимуществом, и серьезной пробле" мой. С переходом на System 11 в вашем распоряжении появляются сотни параметров настройки, о су" ществовании которых большинство из нас даже не догадывалось. Администраторы баз данных теперь могут придумать множество новых способов положить конец нормальной работе своих серве" ров. В итоге вместе с широкими возможностями System 11 взваливает на наши плечи и серьезный но" вый груз ответственности. Подумайте о хорошем: обилие новых методов настройки сервера никогда не позволит начальству или пользователям загнать вас в угол — всегда останется возможность про+ изнести нечто вроде "По всей видимости, выбор точки очистки (wash point) свободного буфера оказался недостаточно оптимальным". Ни один уважающий себя специалист по компьютерам не решится на атаку при наличии у него столь эшелонированных линий обороны. Подумайте о плохом: представьте себе, что начальство поручает вам вернуть к жизни сервер, сконфигурированный одним администратором, недавно попавшим в аварию. Вы должны в сжатые сроки изучить установки 300 параметров конфигурации, разобраться с назначением бесчисленных именованных кэш+буферов и проконтролировать все частич+ но заполненные сегменты таблиц. Впрочем, и здесь не все так ужасно: благодаря Sys+ tem 11 вам в обозримом будущем едва ли грозит безработица. Совместимость с предыдущими версиями Дампы баз данных System 11 не могут быть загружены сервером System 10 или SQL Server 4.9.2. Сер" вер System 11 способен загружать дампы, созданные сервером System 10. Поэтому при переходе от System 10 к System 11 достаточно создать дампы всех баз данных System 10, после чего загрузить их в базы данных сервера System 11. По завершении загрузки каждой базы данных сервер System 11 авто" матически преобразует их.

www.books-shop.com

Будущие версии SQL Server В будущих версиях SQL Server и других сопутствующих продуктов семейства System 11 ожидается по" явление множества новых возможностей. Рассмотрим некоторые из этих возможностей, о которых можно часто услышать от представителей компании Sybase. Как всегда, нам остается только догадыва" ться о точном времени выхода каждой будущей версии. Масштабируемость Для дальнейшего расширения масштабируемости SQL Server в нем должна появиться возможность поручать отдельным поисковым ядрам выполнение определенных задач. Вместе с реализованной в System 11 поддержкой именованных кэш"буферов диспетчером логической памяти это позволит ад" министратору сервера выделить одно или несколько поисковых ядер сервера для доступа к набору объектов баз данных или именованных буферов. Подобная возможность особенно важна в информа" ционных системах со смешанной нагрузкой, одновременно поддерживающих как OLTP"приложения, так и DSS"приложения, поскольку теперь приложениям различных типов могут быть назначены инди" видуальные поисковые ядра сервера. Сервер сможет также принимать во внимание приоритеты каж" дой из выполняемых задач, что в целом позволит распределить важному приложению набор выделенных поисковых ядер, работающих с выделенными областями кэш"буфера и имеющих опреде" ленный приоритет. Производительность В будущих версиях SQL Server должна появиться система управления ресурсами (resource governor), призванная ограничить объем системных ресурсов, доступных каждой отдельной транзакции, запро" су или пакетному заданию. Система управления ресурсами может быть сконфигурирована так, чтобы ограничивать общий объем операций ввода"вывода, время выполнения, объем выбранных данных и т.д. Система управления ресурсами поддерживает динамическое изменение своей конфигурации, что позволяет изменять действующие ограничения в зависимости от времени суток, дня недели или како" го"либо другого характерного периода деловой активности. Система управления ресурсами также предоставит в распоряжение администратора широкий спектр различных действий, предпринимае" мых при выходе пользовательского процесса за установленные пределы ресурсов. Поддержание работоспособности Новые версии сервера будут поддерживать распараллеливание обычных операций обеспечения рабо" тоспособности сервера (таких, как dbcc"проверки, сортировки, создание индексов и восстановление баз данных). Распараллеливание таких операций позволит администратору сервера воспользоваться наличием в системе нескольких процессоров и поисковых ядер. Средства восстановления данных смогут обеспечить восстановление баз данных на определен" ный момент времени и дадут пользователям возможность сохранить частичный доступ к базе дан" ных в процессе ее восстановления. Несмотря на отсутствие конкретной информации по перспективным возможностям средств восстановления, здесь предполагается ряд весьма интерес" ных новых сценариев резервирования и восстановления данных. Sybase также обещает расширить способности сервера архивации, включив в него поддержку восстановления отдельных объектов базы данных и отдельных сегментов таблиц данных. Кроме того, ходят слухи о будущей интеграции независимого программного пакета SQL BackTrack со средствами резервирования и восстановления данных сервера. Сейчас трудно сказать, идет ли здесь речь о включении этого программного про" дукта компании DataTools в состав сервера либо о каком"то другом решении. Наконец, будущие вер сии сервера должны обеспечить поддержку ролей, определяемых пользователем, а также новых механизмов безопасности, позволяющих лучше контролировать права доступа, полученные пользо" вателями в соответствии с присвоенными им ролями. Поддержка принятия решений Новые версии сервера будут включать более эффективную поддержку систем принятия решений (Decision Support Systems, DSS), называемых хранилищами данных (data warehouses). Поддержка DSS"приложений означает наличие средств полного распараллеливания обработки запросов, вклю" чая интеграцию этих средств с оптимизацией запросов на основе анализа издержек, а также новые методы настройки производительности сервера, основанные на возможностях диспетчера логиче" ской памяти (Logical Memory Manager), уже реализованных в System 11. Поддержка параллельной об" работки запросов, скорее всего, будет включать в себя распараллеливание просмотра индексов и

www.books-shop.com

таблиц, сортировок данных, соединения таблиц, а также вычисление агрегатных функций (таких, как sum, min, max, avg). Распределенные базы данных Здесь речь в первую очередь идет о новых возможностях репликации данных с помощью сервера ти" ражирования Sybase (Sybase Replication Server), упрощающих конфигурирование основных и вторич" ных данных с помощью механизмов, получивших название модели "публикации" данных и "подписки" на их изменения (publish and subscribe model). Помимо средств синхронизации мобильных баз дан" ных, на сервере тиражирования должна появиться поддержка событий, а также новых типов данных и транзакций. Расширится число параметров настройки сервера. Домыслы и рассуждения ЕСЛИ описанные выше возможности будущих версий серверов Sybase по крайней мере подтверждают" ся большинством имеющихся слухов, то рассматриваемые в данном разделе предположения основа" ны на еще менее достоверной информации. Реализация блокировок на уровне записей давно остается желанной мечтой пользователей, и в рассуждениях на эту тему нет недостатка. Возможность блокировки отдельных записей сделала бы ненужными некоторые появившиеся в System 11 новые возможности, призванные предотвратить конфликты за доступ к последней странице журнала тран" закций и последним страницам таблиц. Поэтому построчная блокировка относится к числу наиболее спорных и интересных из всех потенциальных возможностей будущих версий SQL Server. Среди дру" гих подобных возможностей следует назвать средства восстановления особо крупных баз данных (Very Large Databases, VLDB), поддержку сложных типов данных, появление средств кластеризации серверов, работающих на отдельных серверных машинах, позволяющих им совместно выполнять сложные запросы. Заключение В процессе развития сервера Sybase от SQL Server 4.9.2 к System 11 выход в свет каждой новой версии сопровождался многими существенными изменениями в режимах работы сервера, параметрах его конфигурации и настройки. С течением времени сервер продолжает усложняться, но его совершен" ствование не должно становиться самоцелью. И принципы построения сервера Sybase, и основные обязанности его администратора по своей сути не претерпели существенных изменений. Главное — ясно понимать роль сервера в поддержке деловой активности вашей компании. Основная задача сер" вера и его администратора — вовремя снабжать владельца сервера данными, необходимыми для успешного ведения бизнеса. Так ли уж важно, насколько остроумно сделан конфигурационный файл самого сервера? Возьмите на заметку В настоящее время широко распространены три версии SQL Server: версия 4.9.2, System 10 и Sys" tem 11. В System 10 у сервера появился ряд новых возможностей, например аудит работы сервера и резервирование данных с помощью отдельного сервера архивации (Backup Server). System 11 призва" на в первую очередь обеспечить удовлетворительную масштабируемость SQL Server на многопроцес" сорных вычислительных системах. Каждая версия сервера существенно отличается от предыдущих; однако многие возможности но" вой версии могут и не проявиться на вашей конкретной системе. Разумеется, администратору базы данных следует знать о важнейших отличиях каждой версии сервера, но не следует стремиться ис" пользовать все нововведения только потому, что они стали доступными. System 11 также содержит в себе большое число нововведений, далеко не все из них немедленно потребуются читателю. Те немногие новые возможности System 11, которые действительно нужны в каждой системе, обычно оказываются задействованными автоматически при установке новой вер" сии сервера. Хорошая масштабируемость System 11 положительно скажется на производительности приложений, ограниченных ресурсами процессора, причем только при работе сервера на системах с полной аппаратной и программной поддержкой симметричного мультипроцессирования (SMP).

www.books-shop.com

Глава 2

Преимущество Sуsеem 11

www.books-shop.com

Несмотря на все преимущества новой версии сервера Sybase и несомненный выигрыш в произво" дительности, который они обещают, мы должны повторить два замечания, сделанные в конце пре" дыдущей главы. Во"первых, все новые возможности System 11 в первую очередь предназначены для улучшения масштабируемости сервера на многопроцессорных системах. Если многопроцессорная конфигурация не поддерживается архитектурой компьютера или используемой версией операцион" ной системы, либо в компьютере попросту не установлены дополнительные процессоры, то пере" ход на System 11 едва ли приведет к выигрышу в производительности. Во"вторых, вероятно, читателю вообще не потребуется ни одна из возможностей System 11, об" суждаемых в этой и следующих главах. Разумеется, полезно знать об их существовании, но необяза" тельно читателю использовать эти возможности, если в них нет необходимости. Не следует стремиться задействовать все возможности сервера только потому, что они существуют — дожди" тесь, когда они реально потребуются вам. При обсуждении новых возможностей System 11 мы объе" диним их в несколько групп: масштабируемость, именованные кэш"буферы, конфигурация и средства администрирования. В каждой из этих групп отдельные нововведения будут рассматривать" ся в порядке убывания важности. Нам не удастся рассказать здесь обо всех деталях, связанных с особенностями System 11. Реализа" ция многих возможностей новой версии и их практическое использование требуют подробного изу" чения системной документации Sybase. Новые возможности System 11 рассматриваются в следующем порядке: Достоинства System 11 Масштабируемость Множественные сетевые ядра System 11 (Multiple Network Engines, MNE) Журналы транзакций System 11 Управление блокировками и System 11 Именованные кэш+буферы данных Диспетчер кэш"буфера и именованные буферы Диспетчер кэш"буфера и большие блоки ввода"вывода Оптимизация запросов и диспетчер кэш"буфера System 11 Улучшенная оптимизация запросов Конфигурирование сервера Конфигурирование SQL Server System 11 Администрирование сервера Дампы баз данных Хранимая процедура sp_sysmon Системные таблицы Сегментирование таблиц данных Стоит ли торопиться? Перед тем как воспользоваться любой из перечисленных выше возможностей, читателю следует тща" тельно оценить, стоит ли потенциальный выигрыш всех дополнительных административных затрат на конфигурирование сервера и его сопровождение. Стремясь облегчить этот непростой выбор, при обсуждении каждой новой возможности System 11 мы постараемся отметить, следует ли читателю немедленно реализовать ее на практике. Некоторые нововведения (они отмечены звездочкой *) действительно нужно рассмотреть со всей серьезностью, другие вполне могут подождать, пока в них не возникнет реальная необходимость. Как вы очень скоро увидите, лишь два из всех рассматриваемых нововведений (улучшенная оптими" зация запросов и особенности дампов баз данных) способны непосредственно отразиться на работо" способности сервера. Это не означает, что все другие новые возможности бесполезны. Еще раз подчеркнем, что к их использованию следует приступать, ясно понимая, что вы делаете и зачем. При переходе от SQL Server 4.9.2 к System 11 следует обязательно установить так называемые поро" ги последнего уровня (last"chance thresholds, см. главу 12).

www.books-shop.com

Новые возможности System 11 Масштабируемость Множественные сетевые ядра (MNE) Сервер автоматически переключается в режим множественных сетевых ядер, как только администра" тор сервера запускает второе поисковое ядро сервера. Журналы транзакций System 11 Сервер автоматически создает для каждого пользователя индивидуальный буфер журнала транзакций (User Log Cache, ULC) размером в 2 Кбайт. Без серьезных на то оснований не следует изменять уста" новленный по умолчанию размер ULC"буфера. Управление блокировками и System 11 Для каждого поискового ядра сервер создает отдельный набор блокировок с ожиданием (spinlocks). Не следует без серьезных причин изменять установленные по умолчанию параметры других новых режимов блокировок, обеспечивающие поддержку уровней изолированности с возможностью повы" шения (promotion) этих уровней. Производительность Диспетчер кэш буфера и именованные буферы Сервер автоматически создает кэш"буфер данных, используемый по умолчанию, функционально эк" вивалентный буферу данных прежних версий сервера.

Диспетчер кэшбуфера и большие блоки вводавывода Сервер автоматически устанавливает размер блока используемого по умолчанию буфера данных рав" ным 2 Кбайт. Таким образом, весь используемый по умолчанию кэш"буфер данных будет представ" лять собой единую буферную область с блоками размером в 2 Кбайт. Оптимизация запросов и диспетчер кэш буфера System 11 При отсутствии проблем с производительностью, которые можно было бы решить за счет использо" вания блоков ввода"вывода большего размера, рассмотрение этого аспекта System 11 можно отложить до лучших времен. Улучшенная оптимизация запросов * Обработка подзапросов сервером System 11 отличается от их обработки в предыдущих версиях. При переходе на System 11 все существующие хранимые процедуры, триггеры и представления (особенно те, что содержат подзапросы) необходимо удалить и создать заново, поскольку в противном случае они будут обрабатываться по"старому, и скорость их выполнения может даже замедлиться. Сегментирование таблиц Как правило, сегментирование позволяет ускорить обработку лишь очень немногих таблиц. В вашем сервере может вообще не найтись ни одной таблицы, способной выиграть от сегментирования, поэ" тому не следует использовать эту возможность без серьезной необходимости. Эксплуатация сервера Конфигурирование SQL Server System 11 Разумеется, администратор базы данных должен уметь использовать конфигурационный файл для за" дания конфигурации сервера, но на практике вам не придется вручную создавать подобные файлы. При установке System 11 (или переходе к ней с предыдущей версии сервера) файл с именем <имя_сервера>.сfg создается автоматически. Каждое изменение конфигурации сервера, сделан" ное с помощью хранимой процедуры sp_conf igure, будет автоматически отражено сервером в кон" фигурационном файле <имя_сервера>. cfg. При каждом запуске сервера он автоматически будет использовать самую свежую версию файла <имя_сервера>.сfg. Таким образом, контроль за конфи" гурацией сервера System 11 выполняется аналогично предыдущим версиям.

Дампы баз данных * После загрузки базы данных из дампа она находится в автономном (off"line) состоянии. Вам придется добавить во все командные файлы, выполняющие загрузку баз данных, команду перевода загружен" ных баз данных в активное (on"line) состояние.

www.books-shop.com

Хранимая процедура sp_sysmon Вам потребуется осуществлять мониторинг производительности сервера (например, чтобы выяс" нить, какими новыми возможностями следует воспользоваться), но едва ли к этой продолжительной и трудоемкой процедуре стоит приступать в первую очередь. Системные таблицы Администратор базы данных должен не только знать о существовании подобных таблиц, но и регу" лярно сохранять их резервные копии в процессе создания полной копии рабочей конфигурации сер" вера. Однако без особых причин нет необходимости выполнять с этими таблицами какие"либо другие операции. Возможности, так и не появившиеся в System 11 К сожалению, ряд полезных усовершенствований по"прежнему остается за рамками System 11. Не" смотря на многочисленные слухи о скором появлении блокировок на уровне записей, System 11 не поддерживает эту важную возможность. Хотя в System 11 и существует параметр 'максимальное число записей на странице данных', задаваемый в команде create table, его использование служит лишь бледным подобием настоящей построчной блокировки. Давно обсуждаемая система управления ресурсами (resource governor) стала бы весьма желатель" ным нововведением, но в составе версии 11.0 она отсутствует. Возможность снятия всех ограничений при обновлении на месте (update"in"place) также обсужда" ется достаточно давно, но System 11 не поддерживает ее в полном объеме, и в версии 11.0 Sybase SQL Server здесь остаются некоторые весьма существенные ограничения. Заключение Итак, SQL Server System 11 обладает рядом новых важных особенностей, в первую очередь призван" ных улучшить масштабируемость сервера на многопроцессорных платформах. При использовании однопроцессорной серверной машины переход к новой версии сервера вряд ли повысит его произво" дительность. Кроме того, очень легко злоупотребить гибкостью System 11, получив в результате лишь снижение эффективности сервера и значительное усложнение процесса его эксплуатации.

www.books-shop.com

Глава 3

Масштабируемость System 11

www.books-shop.com

Множественные сетевые ядра (MNE) System 11 Предыдущие версии SQL Server поддерживали одновременную работу нескольких поисковых ядер. Каждое ядро представляет собой программный модуль сервера, выполняющийся в качестве отдель" ного системного процесса. До появления System 11 взаимодействие этих ядер было реализовано весь" ма примитивно. Главная проблема заключалась в том, что вся работа с сетью обеспечивалась одним выделенным серверным ядром, и это существенно ограничивало масштабируемость сервера. По мере увеличения количества процессоров серверной машины и одновременно работающих серверных ядер все ядра должны были ждать завершения ядром с номером 0 очередной операции сетевого вво" да"вывода. System 11 поддерживает режим множественных сетевых ядер, в котором любое поисковое ядро может выполнять сетевой ввод"вывод. Это делает работу всех ядер сервера значительно более эффективной и качественно улучшает масштабируемость сервера. Поисковые ядра SQL Server Поисковым ядром называется программный модуль (двоичный выполняемый код) сервера, запущен" ный в качестве отдельного процесса операционной системы. Все ядра сервера разделяют между со" бой блокировки доступа и другие серверные ресурсы. Каждое ядро — это отдельный системный процесс, независимо от того, сколько процессоров и поисковых ядер имеется в системе. Серверные ядра взаимодействуют друг с другом через разделяемую область оперативной памяти; кроме того, ядра используют механизм блокировок с ожиданием (spinlocks), или семафоров, для контроля за тем, каким ядром используется тот или иной сегмент разделяемой памяти в данный момент времени. В си" туации, когда одному ядру требуется структура разделяемой памяти, заблокированная другим ядром, первое ядро переходит в состояние ожидания, постоянно проверяя наличие блокировки. При запуске сервер автоматически активизирует количество поисковых ядер, равное количеству активных ядер (online engines), указанному в конфигурационном файле сервера. Количество актив" ных ядер может отличаться от количества процессоров, физически доступных в серверной машине. Как правило, установка количества ядер сервера равным количеству процессоров серверного компь" ютера не позволяет достичь оптимальной производительности сервера. Как и в предыдущих верси" ях SQL Server, количество автоматически запускаемых ядер устанавливается командой sp_configure "max online engines", <количество_ядер>. Сервер версии System 11 не позволит установить количество активных ядер, превышающее коли" чество процессоров серверной машины. Приведенная ниже распечатка получена на двухпроцессор" ной системе: 1> sp_configure "max online engines" 2> go Parameter Name Default Memory Used Config Value Run Value max online engines 1 147 1 1 (return status = 0) 1> sp_configure "max online engines", 2 2> go Parameter Name Default Memory Used max online engines 1 147

Config Value 2

Run Value 1

Configuration option changed. The SQL Server must be rebooted before the change in effect since the option is static. (Значение параметра конфигурации изменилось. Поскольку используется статиче# ский параметр, для активизации нового значения необходимо перезапустить SQL Server.) (return status = 0) 1> sp_configure "max online engines", 3 2> go

Msg 5846, Level 16, State 1:

Server 'PSYCHO', Procedure 'sp_configure', Line 329: Illegal value '3' specified for configuration option 'max online engines'. The legal values are between '1' and '2'.

www.books-shop.com

Для параметра конфигурации 'max online engines' указано недопустимое значение Допустимые значения параметра должны находиться в интервале между '1' и ' 2 ' . Msg 5849, Level 16, State 1: Server 'PSYCHO', Procedure 'sp_configure', Line 329: Verification failed for parameter 'max online engines'. Ошибка при проверке параметра 'max online engines'. (return status = 1) System 11 и сетевой ввод+вывод Как отмечалось выше, в SQL Server 4.9.2 и System 10 весь сетевой ввод"вывод должен был пройти че" рез ядро 0, вне зависимости от того, чем занимались в данный момент остальные ядра сервера (рис. 3.1). В результате все операции сетевого ввода"вывода были вынуждены ожидать освобождения ядра 0 даже при неполной загрузке остальных ядер. При больших объемах сетевого ввода"вывода до" бавление новых процессоров не помогало повысить производительность сервера, что серьезно огра" ничивало его масштабируемость. Поскольку SQL Server основан на сетевой архитектуре клиент"сервер, высокая производительность сервера немыслима без эффективной поддержки сетево" го ввода"вывода.

Поисковое ядро1

Поисковое ядро 2

Поисковое ядро З

Поисковое ядро О

Рис. 3.1. Сетевой ввод*вывод в версиях сервера, предшествующих System 11 SQL Server в System 11 распределяет сетевой ввод"вывод среди всех доступных ядер, причем теку" щие запросы на выполнение операций сетевого ввода"вывода направляются на ядро с наименьшим на данный момент числом пользовательских сеансов. Отметим, что хотя запросы каждого пользова" тельского сеанса работы могут выполняться на любом из имеющихся процессоров, весь сетевой ввод"вывод, генерируемый пользовательским сеансом, обслуживается одним и тем же серверным яд" ром, которому этот сеанс был назначен при подключении пользователя к серверу. В подобной ситуа" ции говорят, что пользовательский сеанс, или задача, связываются с определенным ядром сервера; весь генерируемый на протяжении сеанса сетевой трафик обслуживается связанным ядром. Заме" тим, что при установлении соединения с сервером пользователь первоначально оказывается связан" ным с ядром 0 (рис. 3.2) и лишь затем связывается с другим ядром на все оставшееся время сеанса (рис. 3.3). Большинство аппаратных платформ с симметричным мультипроцессированием (Sun Solaris, DEC, RS6000, AIX, HP) поддерживает подобную миграцию сетевых связей. Тем не менее сле" дует специально убедиться, что ваша серверная платформа позволяет воспользоваться этим эффек" тивным средством повышения производительности сервера.

Поисковое ядро 1

Поисковое ядро 2

Поисковое ядро

3

Поисковое ядро 0

Рис. 3.2. Сетевой ввод*вывод при подключении пользователя к серверу System 11 6—2221

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Рис. 3.3. Миграция пользовательского сеанса между ядрами сервера System 11 При всех своих достоинствах миграция сетевых связей вовсе не гарантирует, что сер+ верное ядро с малым числом пользовательских сеансов в данный момент не окажется занятым обработкой сложного и длительного запроса. В результате серверное ядро, обслуживающее одного очень активного пользователя, получит весь объем операций се+ тевого ввода+вывода, в то время как другое ядро с сотней неактивных сеансов будет простаивать. Таким образом, несмотря на то, что сервер System 11 действительно обес+ печивает намного более эффективную поддержку сетевого ввода+вывода, в нем решены далеко не все потенциальные проблемы с равномерным распределением подобной нагрузки. Сеансы работы пользователей и серверные ядра В предыдущих версиях SQL Server количество одновременно установленных соединений с пользова" телями ограничено максимальным количеством дескрипторов файлов, доступных каждому отдельно" му системному процессу. В SQL Server 4.9.2 и System 10 только поисковое ядро 0 было способно обслуживать сетевой ввод"вывод, поэтому разрешенное операционной системой максимальное число дескрипторов файлов определяло максимальное число пользовательских сеансов. Аналогичное огра" ничение сохраняется и в System 11, однако здесь пользовательские сеансы могут обслуживаться каж" дым из множественных сетевых ядер (MNE), вследствие чего удвоение количества параллельно работающих ядер удваивает и максимальное число пользовательских сеансов. Например, операционная система разрешает каждому системному процессу иметь не более 1024 дескрипторов файлов. Тогда сервер с одним ядром сможет поддерживать максимум 1024 поль" зовательских сеанса (реальное число сеансов окажется немного меньшим, поскольку часть дескрип" торов используется самим сервером). При наличии в системе трех сетевых ядер максимальное число сеансов составит 3 х 1024 = 3072, хотя каждому отдельному серверному процессу по"прежнему потребуется не более 1024 дескрипторов. Оптимальное количество серверных ядер Разумеется, не имеет смысла одновременно запускать больше сетевых ядер, чем имеется процессоров в серверной машине. Более того, количество сетевых ядер не должно превышать количества процес" соров, которое администратор системы может выделить для нужд SQL Server. Если количество одно" временно работающих сетевых ядер будет превышать количество доступных процессоров, то операционной системе придется переключать каждый из имеющихся процессоров между нескольки" ми серверными ядрами. Процесс переключения системных процессов использует значительные ре" сурсы системы, и в результате производительность сервера может снизиться по сравнению с конфигурацией, имеющей меньше поисковых ядер. При определении оптимального количества множественных сетевых ядер необходимо выяснить, насколько сильно загружены существующие поисковые ядра. Заметим, что это не эквивалентно от" слеживанию уровня загрузки имеющихся процессоров, поскольку загрузка процессора определяется на уровне операционной системы, и в результате система может сообщить о 100%"ной загрузке про" цессора ядром, в действительности ожидающим очередного запроса. Поэтому необходимо прежде всего определить базовую производительность существующих ядер, а затем добавить в систему не" сколько новых ядер и снова проследить за их производительностью. Увеличение количества

www.books-shop.com

серверных ядер может привести к возрастанию объема оперативной памяти, распределяемой серве" ру, поэтому начинайте с небольшого количества ядер и убедитесь, что вам действительно необходи" мо запустить дополнительные ядра. Более подробно процедура определения оптимального числа ядер для конкретной серверной системы будет обсуждаться в главе 10. В большинстве случаев мы говорим об увеличении количества ядер, однако в некоторых случаях для достижения оптимальной производительности может потребоваться снижение их количества. Например, подобная ситуация может возникнуть при выходе из строя нескольких процессоров либо в результате запуска на серверной машине системных процессов, не относящихся к SQL Server. При переносе сервера на новую аппаратную платформу, даже однотипную с существующей, необходимо убедиться в наличии у новой системы необходимых ресурсов для сохранения прежнего количества серверных ядер. Если новая серверная машина имеет другое количество процессоров или отличает" ся по объему оперативной памяти, вероятно, возникнет необходимость пересмотреть количество одновременно запускаемых серверных ядер. Диспетчеризация ядер в SQL Server Хотя генерируемый каждым пользовательским сеансом сетевой ввод"вывод обслуживается в SQL Ser" ver только серверным ядром, связанным с этим сеансом, все поступающие пользовательские запросы динамически распределяются сервером между доступными серверными ядрами. Как только для про" должения обработки какой"либо из выполняемых сервером задач потребуется обратиться к поиско" вому ядру, сервер направит эту задачу на одно из свободных ядер. Однако сервер не способен контролировать переключение имеющихся поисковых ядер между процессорами серверного компь" ютера; распределение одновременно работающих ядер между имеющимися процессорами выполня" ется планировщиком заданий операционной системы. В этом отношении между серверами версий 4.9.2, System 10 и System 11 нет различий. Сервер на однопроцессорных вычислительных платформах Преимущества множественных сетевых ядер System 11 способны повысить производительность сер" вера только на многопроцессорных платформах. Но даже и при наличии в компьютере нескольких процессоров используемая версия операционной системы может не обладать степенью поддержки режима симметричного мультипроцессирования, достаточной для параллельной работы нескольких серверных ядер. Перед тем как приступать к изучению и конфигурированию режима множественных сетевых ядер, проверьте, действительно ли он поддерживается аппаратными и программными сред" ствами вашей вычислительной системы. Журнал транзакций System 11 В System 11 реализован существенно более эффективный алгоритм регистрации выполненных запро" сов в журнале транзакций, а также перемещения страниц журнала между кэш"буфером и диском. Эти особенности System 11 позволяют устранить конфликты при обращениях к журналу транзакций, воз" никавшие в предыдущих версиях сервера и ограничивавшие его производительность. Для каждой базы данных SQL Server ведет отдельный журнал транзакций, также называемый журналом повтора. В этот журнал заносятся все изменения, произведенные в базе данных, что по" зволяет восстановить после сбоя результаты всех зафиксированных транзакций. Однако существова" ние единого журнала повтора для всей базы данных ограничивает масштабируемость сервера. Все записи о выполненных транзакциях заносятся на последнюю страницу журнала повтора. В прежних версиях сервера каждый из одновременно выполнявшихся пользовательских запросов должен был дожидаться своей очереди на запись в последнюю страницу журнала повтора (рис. 3.4). С широким распространением многопроцессорных платформ, на которых параллельно функционировали не" сколько серверных ядер, конкуренция за блокировку доступа к последней странице журнала повтора превратилась в серьезную проблему. Пользовательские кэш+буферы журнала повтора В System 11 проблема одновременной записи в журнал повтора решена: для каждого серверного про" цесса создается индивидуальный кэш"буфер журнала повтора (User Log Cache, ULC). Все записи жур" нала повтора, генерируемые процессом, первоначально помещаются в ULC этого процесса (рис. 3.5), а затем по мере необходимости постепенно вытесняются сервером в общий дисковый файл журнала повтора.

www.books-shop.com

Рис. 3.4. Доступ к журналу повтора в предшествующих версиях сервера

Рис. 3.5. Доступ к журналу повтора в System 11 Ha однопроцессорных системах механизм индивидуальных ULC"буферов вряд ли будет способст" вовать заметному повышению производительности; на многопроцессорных компьютерах он сущест" венно улучшает масштабируемость сервера, позволяя нескольким серверным ядрам не образовывать очередь за право внести запись в журнал повтора. ULC"буферы поддерживаются System 11 по умол" чанию, и нет необходимости конфигурировать их вручную. Сброс содержимого ULC"буферов в дисковый файл журнала повтора производится сервером ав" томатически либо после завершения текущей транзакции, либо при обращении транзакции к другой базе данных, либо при заполнении буфера, либо в процессе создания контрольной точки. Механизм ULC"буферов не позволяет избежать конкуренции за доступ к последней странице жур" нала повтора в момент фиксации параллельно обрабатывавшихся транзакций. До момента фикса" ции все транзакции могут выполняться без подобных конфликтов. Во многих случаях запросы неоднократно выполняют запись в журнал повтора еще до фиксации внесенных изменений. В Sys" tem 11 обращение к последней странице физического файла журнала повтора оказывается отложен" ным до момента фиксации транзакции, что приводит к существенному снижению конкуренции за доступ к этой странице. Отметим также, что запись в ULC"буфер производится только после моди" фикации хотя бы одной строки таблицы данных; поэтому даже весьма сложные и продолжительные транзакции могут не обращаться к буферу журнала повтора, пока они ограничиваются выборкой ин" формации из таблиц базы данных. Во многих случаях пользователи или пользовательские приложения создают серьезные пробле" мы администратору базы данных, подключившись к серверу, открыв транзакцию и затем... отбыв в отпуск. Поскольку при создании дампа журнала повтора сервер способен отбросить сохраненные за" писи только до первой незавершенной транзакции, администратор сервера не может выполнять пе" риодическую очистку журнала повтора без уничтожения пользовательского процесса или перезапуска сервера. Как только в журнале повтора свободное место будет окончательно исчерпано, сервер прекратит обработку любых запросов, за исключением выборки данных командой select. Ме" ханизм ULC"буферов позволяет избавиться от подобной проблемы, так как команда "begin tran" бу" дет перенесена из буфера в журнал только после фиксации транзакции.

www.books-shop.com

Поскольку заполнение буфера журнала повтора приводит к преждевременному сбросу его содер" жимого на диск до завершения всей транзакции, размер буфера может оказать заметное влияние на работу сервера. Администратор сервера может варьировать размеры ULC"буферов, но только на уровне всего сервера; другими словами, все ULC"буферы сервера одинаковы по размеру и по умолча" нию имеют минимально возможную длину в 2 Кбайт. Выбранная администратором длина не может превышать 2 Гбайт и устанавливается командой sp_configure "user log cache size", 4096 При определении оптимального размера ULC"буферов необходимо принять во внимание неско" лько факторов. Размер буфера устанавливается на уровне сервера одинаковым для всех пользовате" лей, независимо от конкретных решаемых ими задач. С одной стороны, буфер не должен быть слишком большим (больше самой длинной транзакции, когда"либо выполняемой пользователями), поскольку зарезервированная за ним память не может использоваться сервером для чего"то еще. С другой стороны, если размеры буфера недостаточны для обработки типичных транзакций без не" однократного сброса записей журнала повтора на диск до завершения транзакции, то излишние об" ращения к последней странице журнала повтора приведут к конфликту между серверными ядрами и тем самым сведут на нет все преимущества ULC"буферов. Таким образом, размер ULC"буферов сле" дует устанавливать, руководствуясь длиной типичных транзакций, а не особо сложных и редко вы" полняемых запросов. На практике здесь чаще всего приходится действовать методом проб и ошибок. Буферная область журнала повтора В предыдущих версиях сервера вся проходящая сквозь сервер информация, включая записи журнала повтора, обрабатывалась в виде страниц длиной 2 Кбайт. Благодаря появившемуся в System 11 поня" тию больших блоков ввода"вывода, этого ограничения больше не существует; в зависимости от кон" фигурации сервера, запись файла журнала повтора может выполняться блоками длиной от 2 до 16 Кбайт. Аналогично величине ULC"буферов, размер буфера ввода"вывода журнала повтора устанав" ливается на уровне сервера одинаковым для всех журналов повтора. По умолчанию буфер ввода"выво" да каждого журнала повтора имеет размер в 4 Кбайт; установленная величина буфера ввода"вывода журнала повтора каждой базы данных выдается в журнал ошибок сервера. Задание величины выводного буфера журнала повтора само по себе не отразится на работе сер" вера. Даже если сервер сконфигурирован с 4"килобайтным выводным буфером журнала повтора, за" пись журнала 4"килобайтными блоками возможна только при наличии в используемом этим журналом повтора кэш"буфере данных буферной области с длиной блока в 4 Кбайт. Администратору сервера необходимо последовательно проконтролировать каждый журнал повтора и создать буфер" ную область с блоками соответствующего размера в каждом именованном кэш"буфере, связанном с одним из журналов повтора, а также в кэш"буфере по умолчанию (при наличии журналов повтора, которым не назначены именованные кэш"буферы). При отсутствии буферной области с 4"килобайтными блоками сервер будет использовать сконфи" гурированную по умолчанию буферную область с 2"килобайтными блоками. Для создания требуемой буферной области необходимо использовать системную хранимую процедуру sp_poolconfig. Раз" мер выводного буфера журнала повтора определяется при загрузке сервера на основании информа" ции, содержащейся в таблице sysattributes. В случае, если один из журналов повтора связан с именованным кэш"буфером, не имеющим буферной области с длиной блока требуемого размера, размер блока (выводного буфера) устанавливается равным 2 Кбайт. Указанный размер может быть изменен динамически во время работы сервера с помощью процедуры sp_logiosize. Как всегда, оптимальный размер блока определяется экспериментально посредством тщательного мониторинга работы сервера. Старейшая незавершенная транзакция При наличии в журнале повтора информации о незавершенных (открытых) транзакциях очистка жур" нала возможна только до момента начала старейшей открытой транзакции. В ситуации, когда эта тран" закция будет оставаться открытой в течение неопределенно долгого времени, произойдет полное заполнение журнала повтора, и сервер перестанет обрабатывать все запросы, за исключением запро" сов на выборку данных командой select. До появления System 11 у администратора сервера не было пря" мого способа определить, какой именно пользователь несет ответственность за незавершенную транзакцию, вызывающую переполнение журнала повтора. Единственным выходом из подобной ситуа" ции являлся перезапуск сервера с целью уничтожения всех открытых транзакций. В System 11 включе" на новая системная таблица syslogshold, содержащая для каждой базы данных сервера информацию о

www.books-shop.com

64

Глава 3

содержании старейшей незавершенной транзакции и промежутке времени, в течение которого эта транзакция считается активной. Необходимо отметить, что сервер считает активными только тран закции, модифицировавшие содержимое хотя бы одной из таблиц данных, поскольку до внесения первого изменения в базу данных транзакции не генерируют никаких записей журнала повтора. Особенности работы с журналами повтора Несмотря на новые средства поддержки журналов повтора, появившиеся в System 11, эти журналы попрежнему остаются источником разнообразных проблем для администратора баз данных. Поско льку любая транзакция, заполнившая свой буфер журнала повтора, должна записать содержимое бу фера в последнюю страницу дискового файла журнала повтора, при наличии большого числа подобных транзакций сервер сталкивается с проблемой конкуренции за доступ к журналу повтора, хорошо знакомой читателю по предыдущим версиям SQL Server. Использование больших блоков вводавывода во многих случаях лишь снижает производитель ность сервера, т.к. сервер сбрасывает буфер журнала повтора на диск после завершения каждой транзакции, не дожидаясь заполнения буфера. Поэтому при обработке большого числа коротких транзакций использование больших блоков заставит сервер записывать на диск намного больше данных, чем это реально необходимо. В комплект поставки сервера не входит готовая системная процедура просмотра содержимого таблицы syslogshold. Разумеется, подобную процедуру легко создать самостоятельно, но всю необходи мую информацию из таблицы syslogshold можно получить с помощью обычной команды select (см. пример в следующем разделе главы). Важно понять, что возможность выявить пользователя серве ра, несущего ответственность за старейшую незавершенную транзакцию, ни в коей мере не гаранти рует решения проблемы, поскольку команда kill способна уничтожить пользовательский процесс далеко не во всех его возможных состояниях. Вполне реальна ситуация, когда перезапуск сервера окажется единственным способом избавиться от найденного вами пользовательского процесса. Формат команд работы с ULC*буфером и примеры их использования

Определение текущего размера ULCбуфера 1> sp_configure 'user log cache size' 2> go Parameter Name Default Memory Used user log cache size 2048 0

Config Value 2048

Run Value 2048

(return status = 0) Задание текущего размера ULC буфера в конфигурационном файле сервера [User Environment] number of user connections = 50 stack size = DEFAULT stack guard size = DEFAULT systemwide password expiration = DEFAULT permission cache entries = DEFAULT user log cache size = DEFAULT user log cache spinlock ratio = DEFAULT Изменение размера ULC буфера 1> sp_configure 'user log cache size', 2060 2> go Parameter Name Default Memory Used Config Value Run Value user log cache size 2048 0 2060 2048 Configuration option changed. The SQL Server must be rebooted before the change in effect since the option is static. (Значение параметра конфигурации изменилось; для активизации нового значения статического параметра конфигура# ции необходимо перезапустить SQL Server.) (return status = 0)

www.books-shop.com

Регистрация изменения размера ULC буфера в журнале ошибок сервера 00:96/05/30 15:34:34.35 server 'iso_l' (ID = 1).

00:96/06/12 10:13:08.41 server The configuration option 'user log cache size' has been changed by 'sa' from '2048' to '2060' 00:96/06/12 10:13:08.47 server Configuration file

' /export/home/sybase/11.0.1/VERTIGOll.cfg' has been written and the previous version has been renamed to ' /export /home/sybase/ 11.0.1/VERTIGO11.017 ' Конфигурационный файл сервера после изменения размера ULC буфера [User Environment] number of user connections = 5 0 stack size = DEFAULT stack guard size = DEFAULT

systemwide password expiration = DEFAULT permission cache entries = DEFAULT user log cache size = 2060 user log cache spinlock ratio = DEFAULT

Новый размер ULC буфера активизируется после перезапуска сервера 1> sp_configure 'user log cache size' 2> go Parameter Name Default Memory Used user log cache size 2048 0

Config Value 2060

Run Value 2060

(return status = 0)

Определение размера буфера ввода вывода журнала повтора текущей базы данных 1> sp_logiosize 2> до The transaction log for database 'master' will use I/O size of 2 kbytes. Ввод#вывод в журнал повтора базы данных 'master' будет осуществляться блоками по 2 Кбайт. (return status = 0 ) Определение размера буферов ввода вывода журналов повтора всех баз данных сервера 1> sp_logiosize 'all' 2> go Cache name: default data cache Data base Log I/O Size Master

2 Kb

Model Psycho_db

2 Kb 2 Kb

Sybsecurity Sybsystemprocs Tempdb

2 Kb 2 Kb 2 Kb

(return status = 0 )

Неудачная попытка увеличить размер буфера ввода вывода журнала повтора с 2 Кбайт до 8 Кбайт 1> use psycho_db 2> go 1> sp_logiosize 2> go The transaction log for database 'psycho_db' will use I/O size of 2 kbytes.

www.books-shop.com

Ввод#вывод в журнал повтора базы данных 'master' будет осуществляться блоками по 2 Кбайт. (return status = 0) 1> sp_logiosize '8' 2> go Unable to change the log I/O size. The memory pool for the specified log I/O size does not exist. Изменение размера блока ввода#вывода журнала повтора невозможно из#за отсутствия буферной области с блоками указанного размера. (return status = 0)

Создание в общем кэш буфере требуемой буферной области с блоками в 8 Кбайт 1> sp_helpcache 2> до Cache Name Config Size Run Size Overhead default data cache 0.00 Mb 28.77 Mb 1.47 Mb Memory Available For Memory Configured Named Caches To Named Caches 28.77 Mb 0.00 Mb There is 28.77 Mb of memory left over that will be allocated to the default cache 28.77 Мбайт незадействованной памяти будет распределено для кэш#буфера, используемого по умолчанию Cache Name

Cache Binding Information Entity Name Type Index Name

Status

(return status = 0) 1> sp_poolconfig 'default data cache', '2M', '8K' 2> go 00:96/06/12 10:31:46.39 server Configuration file '/export/home/sybase/ll.O.l/VERTIGOll.cfg' has been written previous version has been renamed to '/export/home/sybase/11.0.1/VERTIGO11.018' (return status = 0) 1> sp_cacheconfig 'default data cache' 2> go Cache Name Status Type Config Value default data cache Active Default 0.00 Mb Total 0.00 Mb Cache: default data cache, Status: Active, Config Size: 0.00 Mb, Run Size: 28.77 Mb IO Size Wash Size Config Size 2 Kb 512 Kb 0.00 Mb 8 Kb 408 Kb 2.00 Mb

and the

Run Value 28.77 Mb 28.77 Mb

Type: Default Run Size 26.77 Mb 2.00 Mb

(return status = 0)

Успешное увеличение размера буфера ввода*вывода журнала повтора с 2 Кбайт до 8 Кбайт 1> sp_logiosize '8' 2> до The transaction log for database 'psycho_db' will use I/O size of 8 kbytes. ВВОД#ВЫВОД В журнал повтора базы данных 'master' будет осуществляться блоками по 8 Кбайт. (return status = 0)

www.books-shop.com

Новое значение параметра loglosize (8 Кбайт вместо 2 Кбайт по умолчанию) отражается в таблице sysattributes Class attribute object_type object_cinfo object 2 О Т NULL 8 Object_infol object_info2 object_info3 int_value NULL NULL NULL 8 Char_value text_value image_value comments NULL NULL NULL NULL

В конфигурационном файле сервера для размера ULC буфера восстанавливаем значение по умолчанию (изменение станет действительным только после перезапуска сервера) [User Environment] number of user connections = 50 stack size = DEFAULT stack guard size = DEFAULT systemwide password expiration = DEFAULT permission cache entries = DEFAULT user log cache size = DEFAULT user log cache spinlock ratio = DEFAULT ПРИМЕЧАНИЕ. Значение DEFAULT можно указывать только при непосредственном редактиро вании конфигурационного файла, но не при работе с процедурой sp_conf igure.

Перезапуск сервера с модифицированным конфигурационным файлом 00:96/06/12 10:42:43.47 server Recovering database 'psycho_db' 00:96/06/12 10:42:43.48 server Recovery dbid'6 ckpt (10248,19) old# est tran= (10248,18) 00:96/06/12 10:42:43.51 server 1 transactions rolled back. 00:96/06/12 10:42:44.11 server The transaction log in the database 'psycho_db' will use I/O size of 8 Kb. 00:96/06/12 10:42:44.15 server Database 'psycho_db' is now online.

Проверка используемого значения размера ULC буфера 1> sp_configure 'user log cache size' 2> go Parameter Name Default Memory Used user log cache size 2048 0 (return status = 0) Просмотр таблицы syslogshold 1> select * from syslogshold 2> go dbid reserved spid 11 0 0 Starttime Jan 1 1900 12:00AM

page 11971

Config Value 2048

xactid 0x000000000000

Run Value 2048

masterxactid 0x000000000000

name $replication_truncation__point

(1 row affected) ПРИМЕЧАНИЕ. Представленная выше запись оказалась в таблице, поскольку база данных с dbid=l1 — это системная база данных сервера тиражирования Sybase (Replication Server System Data base, RSSD), которая также подвергается репликации. Взаимодействие команды begin /ran с таблицей syslogshold 1> begin tran psycho 2> go 1> use master 2> go

www.books-shop.com

Глава

68 1> select * from syslogshold 2> go dbid reserved spid Starttime

page

3

xactid name

masterxactid

(0 rows affected) ПРИМЕЧАНИЕ: Поскольку команда begin tran не заполняет ULCбуфер, она не отражается в таб лице syslogshold. Таблица syslogshold при обработке длительной транзакции 1> select * from syslogshold 2> go dbid reserved spid page xactid masterxactid 11 0 0 11971 0x000000000000 0x000000000000 Starttime name Jan 1 1900 12:00AM $replication_truncation_point (1 row affected) 1> use cmsdb 2> go 1> begin tran psycho

2> go 1> update service_orders set so_number = so_number + 1 2> go 1> 2> 1> 2>

use master go select * from syslogshold go dbid reserved spid 11 0 0 5 0 1 77107 Starttime Jan 1 1900 12:00AM Jan 12 1996 10:48AM

page xactid masterxactid 11971 0x000000000000 0x000000000000 Ox00012d33000e 0x000000000000 name $replication_truncation_point psycho

(2 rows affected) ПРИМЕЧАНИЕ: dbid = 5 — это идентификатор базы данных, обрабатываемой длительной тран закцией, a spid  1 — идентификатор пользователя, выполняющего указанную транзакцию. Поиск пользовательского процесса в таблице sysprocesses по его идентификатору spid из таблицы syslogshold 1> select * from sysprocesses where spid=l 2> go spid kpid enginenum status suid hostname 1 341639182 0 sleeping 1 psycho program_name hostprocess cmd cpu physical_io Isql 13925 UPDATE 17 14325 memusage blocked dbid uid gid 3 0 5 1 0 tran_name time_blocked network_pktsz Psycho NULL 512 (1 row affected)

www.books-shop.com

Транзакция завершена, но по прежнему остается открытой 1> begin tran psycho 2> go 1> update service_orders set so_number = so_number + 1 2> go (20958 rows affected) 1> use master 2> go 1> select * from syslogshold 2> go dbid reserved spid page xactid masterxactid 11 0 0 11971 0x000000000000 0x000000000000 5 0 1 77107 Ox00012d33000e 0x000000000000 starttime name Jan 1 1900 12:00AM $replication_truncation_point Jan 12 1996 10:48AM psycho (2 rows affected) Откат открытой транзакции 1> use cmsdb 2> go 1> rollback tran psycho 2> go 1> use master 2> go 1> select * from syslogshold 2> go dbid reserved spid page xactid 11 0 0 11971 0x000000000000 Starttime name Jan 1 1900 12:00AM $replication_truncation_point

masterxactid 0x000000000000

(1 row affected) Управление блокировками в System 11 Механизм блокировок дает каждой из одновременно обрабатываемых сервером транзакций возмож" ность работать с базой данных, находящейся в непротиворечивом состоянии. Блокировки запреща" ют транзакции изменить хотя бы одну из записей таблицы, если другая транзакция уже приступила к просмотру этой таблицы. В System 11 сервер поддерживает режим "грязного чтения" (dirty reads), по" зволяет конфигурировать механизм повышения уровня блокировок, или уровня изолированности (lock promotion), а в его составе появился специальный диспетчер параллельных блокировок (parallel lock manager). Конфигурирование механизма повышения уровня блокировок требует хорошего пони" мания деталей различных уровней блокировок и синтаксиса соответствующих команд, подробно опи" сываемых в системной документации Sybase. "Грязное чтение" Обычно сервер не разрешает транзакциям чтение изменений, внесенных, но еще не зафиксирован ных другими транзакциями. В System 11 администратор базы данных может разрешить серверу вы полнение операций "грязного чтения", при которых считывается содержимое страниц данных, содержащих незафиксированные изменения. Разрешение операций "грязного чтения" позволяет по высить производительность сервера, поскольку запросы на выборку данных теперь не должны дожи даться завершения транзакций, модифицирующих эти данные. При этом нет никаких гарантий, что выбранные данные находятся в допустимом состоянии. Более того, эти данные могут измениться бук вально в следующую секунду в процессе продолжения работы модифицирующей их транзакции, либо в результате ее отката. Разрешение "грязного чтения" называется "уровнем изолированности 0". По умолчанию сервер использует уровень изолированности 3, гарантирующий корректность данных, выбираемых любой

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

транзакцией. Изменение уровня изолированности возможно как на уровне всего пользовательского сеанса, так и для отдельного SQL"предложения. Еще раз подчеркнем, что разрешение "грязного чтения" грозит неприятными последствиями. Прежде всего, обычные пользовательские запросы могут дать неверные результаты. К примеру, вы" числение средней зарплаты сотрудника даст неправильный результат, если в процессе усреднения данных часть этих данных окажется модифицированной. Администратору сервера следует тщатель" но сопоставить выигрыш от повышения производительности с потенциальными потерями из"за по" лучения некорректных результатов и разъяснить пользователям причины, приводящие к неправильной обработке их запросов. Для того чтобы сервер мог выбирать записи таблицы в про" цессе их модификации другой транзакцией, эта таблица должна иметь уникальный индекс. Отсутст" вие подобного индекса может привести к аварийному завершению запроса на выборку данных; более подробную информацию по данной проблеме можно найти в документации сервера. Конфигурация режима повышения уровня изолированности До появления версии System 11 при обработке каждого запроса, блокирующего более 200 страниц таблицы данных, сервер автоматически распространял блокировку на всю обрабатываемую таблицу. В результате ни один другой процесс не мог обращаться к этой таблице, что становилось еще одной причиной снижения эффективности множественных серверных ядер при обработке больших таб" лиц. В System 11 администратор базы данных может настраивать параметры режима повышения уров" ня блокировок на уровне всего сервера, отдельных баз данных и отдельных таблиц этих баз данных. Сервер System 11 повышает уровень блокировки в зависимости от отношения количества блокируе" мых страниц к полному числу страниц таблицы. Администратор сервера также может установить зна" чения нижнего и верхнего порогов (low watermark/high watermark, LWM/HWM) повышения уровня блокировок. Если вычисленный процент блокируемых страниц оказывается меньше величины ниж" него порога (LWM), сервер автоматически установит блокировку на уровне таблицы по достижении этого порога. Аналогично, блокировка на уровне таблицы будет установлена по достижении верхнего порога (HWM), если значение порога окажется ниже указанного в конфигурации сервера процентно" го отношения блокируемых страниц, вызывающего повышение уровня изолированности. Диспетчер параллельных блокировок В предшествующих версиях SQL Server все серверные ядра использовали один общий набор блокиро" вок, что не могло не ограничивать общую производительность сервера. В System 11 каждое серверное ядро обладает своим индивидуальным набором структур поддержки блокировок; администратор сер" вера получил возможность конфигурировать соответствующий кэш"буфер каждого серверного ядра. Параллельные блокировки (в отличие от единой блокировки в предыдущих версиях) используются и для управления доступом к самим структурам управления блокировками. System 11 позволяет задавать продолжительность интервала ожидания, до истечения которого сервер не начинает поиск взаимо" блокирующих процессов, или тупиков (deadlocks). Другими словами, теперь до начала поиска тупи" ков блокированный процесс некоторое время находится в состоянии ожидания, и при своевременном самопроизвольном разрешении тупиковой ситуации этот процесс способен продол" жить свою работу. В результате интервал ожидания освобождает сервер от проверки каждого блоки" рованного процесса на возникновение ситуации взаимного блокирования. Предыдущие версии сервера начинали поиск взаимоблокирующих процессов немедленно после блокирования серверно" го процесса.

www.books-shop.com

Глава 4

Именованные кэш*буферы System 11

www.books-shop.com

Именованные кэш+буферы данных и диспетчер буфера Введение SQL Server способен обрабатывать данные только при условии, что соответствующая страница данных находится в оперативной памяти (кэш"буфере данных) серверной машины. Перед выполнением любых команд (select, insert, update или delete) все необходимые серверу страницы данных считываются с дис" ка в оперативную память (обращения к физическому дисковому накопителю называются физическими операциями ввода"вывода), за исключением тех страниц, которые уже находятся в кэш"буфере данных (перемещение страниц из одной области памяти в другую называется логической операцией ввода"вы" вода). Разумеется, логический ввод"вывод выполняется намного быстрее физического ввода"вывода, тем более что физический ввод"вывод способен вызвать конфликт между несколькими серверными процессами при одновременном обращении к одному и тому же дисковому накопителю. Поэтому для повышения производительности SQL Server стремится хранить наиболее часто используемые страни" цы данных в оперативной памяти. Вероятность найти нужную страницу в оперативной памяти возрас" тает с увеличением размера буфера данных; однако она существенно зависит от характера запросов, обрабатываемых сервером. Характерные для OLTP"приложений короткие транзакции обычно исполь" зуют сравнительно небольшое количество страниц данных. Практически все транзакции в подобных приложениях обращаются к одним и тем же нескольким таблицам данных. Наоборот, сложные и длите" льные запросы при составлении отчетов и выполнении других операций, типичных для систем поддер" жки принятия решений, часто требуют выборки весьма значительных массивов данных, далеко не во всех случаях способных поместиться в кэш"буфер сервера. Использование кэш+буфера данных в прежних версиях SQL Server До появления System 11 все версии сервера имели только один кэш"буфер данных, куда загружались все считываемые с диска страницы данных. Еще раз подчеркнем, что любая операция обработки дан" ных (select, insert, update или delete) требует обязательной загрузки в кэш"буфер всех испо" льзуемых страниц данных. При конфигурации серверу распределяется общее количество мегабайт оперативной памяти, в котором первоначально резервируется определенное пространство для раз" личных внутренних структур данных сервера (обеспечивающих поддержку пользовательских сеансов и серверных устройств), а также для стека, программного кода и системного ядра сервера. Затем про" цент еще не занятого пространства распределенной серверу памяти, установленный администрато" ром, выделяется для кэш"буфера хранимых процедур, а все оставшееся свободное пространство занимается кэш"буфером данных (рис. 4.1).

область оперативной памяти серверного компьютера, отведенная серверу Рис. 4.1. Кэш*буфер данных в прежних версиях сервера Работа кэш"буфера данных управляется диспетчером буфера (рис. 4.2), отслеживающим ссылки на находящиеся в памяти страницы данных. Хеш"таблица содержит идентификаторы всех находя" щихся в буфере страниц данных и позволяет серверу быстро найти в памяти требуемую страницу данных без полного просмотра содержимого всех страниц буфера. Каждая страница данных буфера связана с двумя соседними страницами; любая выбранная страница перед обработкой переносится сервером в начало буфера. Таким образом, наиболее часто используемые страницы оказываются в начале буфера, которое также называется областью недавно использованных страниц (most recently

www.books-shop.com

кэш+буфер данных

хеш+таблица

Рис. 4.2. Логическая структура диспетчера буфера прежних версий SQL Server used, MRU). По мере того как все новые обрабатываемые страницы перемещаются в начало буфера, все остальные страницы смещаются к концу буфера в область давно не использовавшихся страниц (least recently used, LRU). Если поиск требуемой страницы в буфере оказывается успешным, то даже при целиком заполненном буфере сервер ограничивается перестановкой страниц внутри буфера (логическим вводом"выводом). При необходимости считать новую страницу с диска в полностью за" полненный буфер (физический ввод"вывод), сервер должен предварительно освободить место для нее, записав на диск последнюю страницу буфера. Все оставшиеся страницы смещаются к концу бу" фера, и новая страница помещается на освободившееся место в начале буфера. Рассмотренная структура буфера данных не обеспечивает должной масштабируемости сервера, т.е. его способности увеличивать производительность путем добавления в систему дополнительных процессоров, обеспечивающих работу большего числа серверных ядер. При наличии общего буфера данных с ним связаны все процессы сервера. К примеру, на многопроцессорном сервере одновре" менно обрабатываются как OLTP", так и DSS"приложения. OLTP"приложение использует малое чис" ло страниц данных, и при оценке его производительности предполагается, что эти страницы будут постоянно находиться в буфере данных. С другой стороны, DSS"запросы регулярно требуют выбор" ки массивов данных, превосходящих размеры буфера. В процессе обработки данных подобные за" просы полностью обновляют содержимое буфера, выгружая на диск все страницы, необходимые OLTP"приложениям. Таким образом, каждой очередной ОLTP"ранзакции приходится заново счи" тывать с диска все необходимые ей страницы, что намного увеличивает время выполнения транзак" ции, одновременно существенно замедляя общий темп работы сервера. Увеличение числа процессоров и серверных ядер не позволит найти выход из этой ситуации; бо" лее того, между параллельно работающими поисковыми ядрами станут возникать конфликты за до" ступ к единственной хеш"таблице буфера данных. В System 11 диспетчер буфера способен поддерживать несколько именованных кэш"буферов дан" ных и выполнять ввод"вывод блоками большого размера. Администратор сервера может создавать в оперативной памяти именованные буферы данных, предназначенные для обработки страниц назна" ченных им объектов базы данных (рис. 4.3), и тем самым выделить OLTP" и DSS"приложениям отде" льные изолированные области буфера. Каждый именованный буфер данных обладает

Рис. 4.3. Именованные кэш*буферы System 11

www.books-shop.com

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

Именованный кэш+буфер Как и в предыдущих версиях сервера, при установке SQL Server System 11 автоматически создается единый кэш"буфер данных, называемый кэш"буфером, используемым по умолчанию, или общим буфе" ром данных. System 11 позволяет администратору базы данных создавать дополнительные буферы, получившие название именованных кэш"буферов и представляющие собой отдельные области едино" го кэш"буфера данных. Поэтому создание каждого нового именованного буфера приводит к сокраще" нию общего буфера данных. Именованные буферы обеспечивают возможность выделить объектам базы данных индивидуальную область оперативной памяти, исключив тем самым возможность вы" грузки страниц данных этих объектов из памяти при обработке других объектов данных. Другими словами, таблицам DSS" и OLTP"приложений могут быть назначены разные именованные буферы, и страницы OLTP"приложений больше не станут выгружаться из памяти при каждом DSS"запросе, что снимет проблему взаимного влияния приложений различных типов. Для создания именованных буферов пользователь должен обладать ролью sa_role. Именован" ные буферы создаются как непосредственно, так и при внесении изменений в конфигурационный файл сервера; однако в любом случае все сделанные изменения активизируются только после пере" запуска сервера. Каждый именованный буфер характеризуется своим размером, названием и режи" мом работы (статусом) — смешанным (mixed), "только для страниц данных" (data"only) и "только для журналов транзакций" (log"only). Статус буфера определяет, какие объекты баз данных могут им об" служиваться. По умолчанию буфер обладает смешанным статусом и в нем размещаются как страни" цы данных, так и страницы журналов транзакций. Соответственно, буфер для страниц данных содержит исключительно страницы данных, не связанные ни с одним журналом транзакций, а бу" фер для журналов повтора может содержать только записи журналов транзакций. Вплоть до момен" та назначения только что созданному именованному буферу одного или нескольких объектов баз данных, этот буфер не содержит страниц данных. Именованному буферу может быть назначена таб" лица, табличный индекс или даже вся база данных. Именованный буфер, которому не назначено объектов данных, не может использоваться сервером, и его существование приводит к сокращению общего размера памяти на величину незадействованного буфера. Назначение объекта базы данных именованному буферу называется связыванием объекта с этим буфером. Все объекты базы данных, которым не назначены именованные буферы, автоматически связываются с общим буфером данных. Наоборот, при связывании базы данных с именованным бу" фером все объекты базы данных по умолчанию назначаются этому буферу. На практике нередко воз" никают весьма сложные схемы связей между объектами данных и именованными буферами данных. К примеру, после назначения базы данных одному именованному буферу некоторые объекты этой базы данных могут быть связаны с другими именованными буферами. Таблица данных и ее индексы вполне могут обслуживаться различными буферами. Даже кластеризованный индекс таблицы дан" ных может быть связан с разными именованными буферами. Связь объекта данных с именованным буфером заносится сервером в отдельную строку систем" ной таблицы sysattributes. Важно подчеркнуть, что эта таблица является единственным местом серве" ра, где регистрируется информация о связи объектов данных с именованными буферами данных. Подобную информацию нельзя получить из конфигурационного файла или с помощью процедуры sp_configure. На работающем сервере список объектов данных, связанных с конкретным имено" ванным буфером, можно распечатать командой sp_helpcache <имя_6уфера>. Если сервер нахо" дится в неработоспособном состоянии, администратор базы данных можете оказаться в одной из двух ситуаций. Представим себе, что вам необходимо восстановить работоспособность сервера — либо после сбоя системы, либо при переходе на новый сервер. Если вы располагаете полной инфор" мацией, необходимой для восстановления сервера и загрузки дампа базы данных, прогноз вполне благоприятен. Поскольку системная таблица sysattributes входит в состав каждой пользовательской базы данных, информация о назначении объектов базы данных именованным буферам будет автома" тически восстановлена в процессе загрузки базы данных из дампа. Но возможна и другая ситуация, когда в вашем распоряжений нет полного набора дампов и других необходимых файлов, и вы либо вообще не можете восстановить пользовательскую базу данных, либо способны восстановить ее то" лько на некоторый момент времени, предшествующий моменту сбоя. В подобной ситуации возмож" но восстановить только связи объектов данных с именованными буферами, существовавшие к моменту времени, на который удается выполнить восстановление базы данных.

www.books-shop.com

Таким образом, содержимое таблицы sysattributes должно быть частью конфигурации сервера, по" скольку отсутствие информации о связях не позволит осуществить полное восстановление конфигу" рации сервера. Помимо информации о связях объектов таблица sysattributes содержит значительный объем посторонней информации. Лучшим методом сохранения информации о связях является со" хранение выдачи команды sp_helpcache, отражающей все связи между объектами баз данных и всеми именованными буферами, сконфигурированными на сервере. При восстановлении базы дан" ных после сбоя или при ее переносе с другого сервера администратор базы данных должен проана" лизировать содержимое таблицы sysattributes восстановленной или перенесенной базы данных на предмет связей, существовавших между именованными буферами и объектами базы данных до ее восстановления либо переноса. Необходимо отметить, что информация о связи всей базы данных как целого с именованным буфером регистрируется только в таблице sysattributes системной базы данных master. При переносе базы данных с другого сервера необходимо предварительно прове" рить существование подобной связи, обратившись к базе данных master исходного сервера. На прак" тике это означает, что перед переносом базы данных необходимо получить на исходном сервере распечатку выдачи команды sp_helpcache. Приведенный ниже пример показывает, насколько запутанным может оказаться подоб+ ный процесс. Вы решаете перенести ваш сервер на другую машину, исключив при этом одну из пользовательских баз данных. У вас есть конфигурационный файл исходного сервера и дампы всех пользовательских баз данных. После успешного переноса баз дан+ ных вы запускаете новый сервер, считая, что после исчезновения одной базы данных оставшиеся базы данных получат в свое распоряжение больше ресурсов сервера. Одна+ ко этого не происходит, и причину проблемы удается установить только после подробно+ го анализа всех выполненных действий. Поскольку использованная копия конфигурационного файла содержала описания всех именованных буферов исходного сервера, в новом сервере появился ряд именованных буферов, не связанных с объекта+ ми данных. Ранее эти буферы использовались для обслуживания объектов базы данных, исключенной из состава нового сервера. В результате, распределенная незадействован+ ным буферам оперативная память осталась. Администратор сервера должен ясно пред+ ставлять себе назначение каждого именованного буфера и объем ресурсов сервера, распределенных этому буферу. Необходимо постоянно помнить, что конфигурационный файл сервера даже в сочетании с выдачей команды sp_conf igure не отражает полной информации о фактической конфигурации сервера. Параметры именованных кэш"буферов могут быть изменены и после создания самих буферов, од" нако при этом существует ряд ограничений. Общий кэш"буфер может иметь только смешанный ста" тус. Именованный буфер смешанного статуса нельзя превратить в буфер журнала повтора, если с ним по"прежнему связаны объекты данных других типов. Размер именованного буфера не может быть меньше установленной по умолчанию величины в 512 Кбайт. Разумеется, в то же самое время именованный буфер не может быть больше всей области памяти, доступной для размещения новых именованных буферов данных. Более того, не советуем даже приближаться к этому пределу, поско" льку на сервере всегда должен быть общий буфер данных. Он не только обеспечивает буферизацию страниц данных всех несвязанных объектов данных, но и используется процедурами восстановле" ния данных. Таким образом, именованные буферы данных ни в коем случае не должны занимать весь объем кэш"буфера данных, иначе размеры общего буфера сократятся до нуля, и сервер попро" сту перестанет функционировать. Процедура удаления именованного кэш"буфера также связана с некоторыми ограничениями. Пе" ред удалением именованного буфера необходимо отменить все связи объектов с удаляемым буфе" ром. Область памяти, которая была занята удаленным буфером, снова распределяется общему буферу; однако это произойдет только после перезапуска сервера. Даже после удаления именованно" го буфера страницы объектов данных, связанных с этим буфером, по"прежнему остаются в памяти (хотя теперь они становятся элементами общего буфера). При перезапуске сервера осуществляется полный сброс на диск содержимого всех буферов данных и модификация структуры буферных обла" стей.

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

www.books-shop.com

повтора), который автоматически конфигурируется в процессе создания самого сервера и первона" чально охватывает всю оперативную память сервера, распределенную под кэш"буфер данных. При со" здании каждого именованного буфера ему отводится область памяти, ранее входившей в состав общего буфера; удаление именованного буфера возвращает отведенную память в состав этой области. Общий буфер нельзя удалить или вытеснить из памяти путем расширения размеров именованных бу" феров, поскольку он является единственным буфером данных, доступным серверу при выполнении операций восстановления данных, т.е. загрузки дампов базы данных и дампов журналов повтора. Во всех остальных отношениях общий буфер аналогичен остальным буферам данных и к нему полно" стью применима вся изложенная выше информация о процессах связывания объектов данных. Связи объектов данных с именованными буферами Назначение объекта данных именованному буферу — необходимое условие использования этого бу" фера. Каждому именованному буферу может быть назначена таблица данных, индекс, журнал повто" ра, либо вся база данных (рис. 4.4). Таблица и связанные с нею некластеризованные индексы могут быть связаны с различными именованными буферами данных; даже кластеризованный индекс может быть связан с буфером отдельно от соответствующей ему таблицы данных. В каждый момент времени объект базы данных может быть связан только с одним именованным буфером; любой именованный буфер способен поддерживать несколько объектов данных. При связывании базы данных с именован" ным буфером все ее объекты также назначаются этому буферу; затем любой объект связанной базы данных может быть назначен другому именованному буферу. В случае изменения конфигурации име" нованных буферов либо их отсутствии после восстановления сервера все объекты данных, ранее свя" занные с удаленными буферами, автоматически связываются с общим кэш"буфером данных. При связывании объекта данных с именованным буфером и объект, и буфер должны фактически сущест" вовать. Журнал повтора может быть связан только с буфером журнала повтора, либо буфером сме" шанного типа, причем буферу журнала повтора назначаются только журналы повтора. При связывании всей базы данных с именованным буфером необходимо перейти в базу данных master. все остальные объекты баз данных

кэш+буфер данных сервера Рис. 4.4. Назначение объектов данных именованным кэш*буферам Ни сама база данных master, ни какой"либо из ее объектов не могут быть связаны с именованным буфером данных. Любая системная таблица (а также ее индекс), входящая в состав пользователь" ской базы данных, связывается с именованным буфером без каких"либо дополнительных ограниче" ний. Примером может служить таблица sysindexes и ее индекс, которые интенсивно используются серверными процессами и часто являются хорошими кандидатами на связывание с именованным бу" фером данных. Необходимо подчеркнуть, что в момент назначения системной таблице пользовате" льской базы данных именованного буфера эта база данных должна находится в однопользовательском режиме. Хеш*таблицы При необходимости установить, находится ли конкретная страница базы данных в оперативной па" мяти, сервер сначала просматривает хеш"таблицу общего буфера данных, а затем — все хеш"таблицы именованных буферов. Использование хеш"таблиц значительно ускоряет поиск нужной страницы по сравнению с последовательным просмотром всех цепочек страниц данных, находящихся в оператив" ной памяти. При работе множественных серверных ядер на системах с симметричным мультипроцес" сированием значительно возрастает вероятность возникновения конфликтов за доступ к

www.books-shop.com

хеш"таблице общего буфера данных. Использование именованных буферов позволяет решить подоб" ную проблему, поскольку каждый такой буфер имеет собственную хеш"таблицу, и при правильном на" значении объектов баз данных именованным буферам, имеющимся в системе, различные серверные ядра будут одновременно работать с хеш"таблицами различных буферов данных. Отметим, что концепция именованных буферов никак не связана с сегментированием объектов баз данных. Сегментирование отражает особенности размещения объекта базы данных на одном или нескольких серверных устройствах, в то время как именованные буферы данных обозначают определенные области оперативной памяти сервера. Независимо от характера сегментирования базы данных любая ее страница перед обработкой должна быть считана в кэш"буфер данных (опера" тивную память). Лишь в этот момент сервер начинает учитывать наличие и распределение имено" ванных буферов данных; не существует связи между распределением объектов базы данных по сегментам (серверным устройствам, расположенным на физических дисковых накопителях) и име" нованными буферами, в которые помещаются страницы этих объектов данных при их чтении в опе" ративную память. Команды создания, удаления и модификации именованных кэш+буферов Создание именованного буфера Для создания именованного буфера в интерактивном режиме достаточно ввести команду 1> sp_cacheconf ig 'psycho_cachel' , ' 1 0 М ' 2> go Размер создаваемого буфера может указываться в страницах (Р), килобайтах (К), мегабайтах (М) или гигабайтах (G). Поскольку создание именованного буфера или изменение его параметров отно" сится к числу статических изменений в конфигурации сервера, для активизации подобных измене" ний необходимо перезапустить сервер. Именованные буферы также могут создаваться путем внесения изменений в конфигурационный файл сервера с его последующим перезапуском: [Named Cache: psycho_cache1 ] cache size = 10M cache status = mixed cache Связывание объектов баз данных с именованными буферами Связи объектов баз данных с именованными буферами нельзя установить с помощью конфигурацион" ного файла сервера, поскольку вся информация о подобных связях хранится в системной таблице " sysattributes, которая имеется в каждой пользовательской базе данных. Для получения полной сводки о конфигурации связей объектов с именованными буферами необходимо распечатать содержимое таб" лиц sysattributes каждой пользовательской базой данных с помощью системной хранимой процедуры sp_helpcache. Для назначения таблицы данных именованному буферу, созданному в приведенном выше приме" ре, необходимо ввести команды 1> sp_bindcache 'psycho_cachel ' , 'psycho_database' , 'psycho_tablel ' 2> go Для назначения индекса таблицы данных тому же именованному буферу введите команды 1> sp_bindcache ' psycho_cachel ' , 'psycho_database' , 'psycho_tablel ' , 'psycho_tablel_index2 ' 2> go В каждом из этих примеров таблица и индекс данных находятся в базе данных psycho_database. Команды, позволяющие отменить назначенные связи объектов с буферами данных, выглядят сле" дующим образом: 1> sp_unbindcache 'psycho_cachel' , 'psycho_tablel ' 2> go 1> sp_unbindcache 'psycho_cachel' , 'psycho_tablel_index2 ' 2> go Учтите, что при отмене связей объектов с буферами нет необходимости указывать, какой базе данных принадлежат эти объекты. Вы также можете отменить все связи, назначенные определенному буферу, с помощью команды

www.books-shop.com

1> sp_unbindcache 'psycho_cachel' 2> go

Удаление именованного буфера Для удаления именованного кэш"буфера достаточно установить его размер равным нулю: 1> sp_cacheconfig 'psycho_cachel', О 2> go Подобная команда, на первый взгляд, должна создавать именованный буфер. Перед удалением буфера рекомендуется отменить все связи объектов, назначенные этому буферу, и тем самым уда" лить из системной таблицы sysattributes все записи, относящиеся к удаляемому буферу. Подобная опе" рация не является обязательной, в случае ее невыполнения сервер будет обрабатывать оставшиеся в таблице sysattributes записи регистрации связей совершенно по"другому. Если при удалении именован" ного буфера в таблице sysattributes остаются записи о связях объектов баз данных с этим буфером, то вместо удаления таких записей сервер помечает их как "недействительные". После перезапуска сер" вер игнорирует все недействительные записи таблицы sysattributes, назначая соответствующие объек" ты общему буферу данных. Строки с прежними связями остаются в таблице sysattributes, и в случае создания именованного буфера с тем же именем им автоматически будет возвращен статус "действи" тельных", что означает безусловное восстановление ранее существовавших связей. Именно по этой причине перед удалением именованного буфера рекомендуется явно отменять все назначенные ему связи, выполняя следующую последовательность команд: 1> sp_unbindcache_all 'psycho_cachel' 2> go 3> sp_cacheconfig 'psycho_cachel', О 4> go Именованный буфер также можно уничтожить, удалив описывающие его строки из конфигура" ционного файла сервера и перезапустив сервер.

Получение информации о состоянии именованных буферов Перечень всех именованных кэш"буферов, существующих на сервере, а также всех связанных с ними объектов баз данных выдается командой 1> sp_helpcache '200 М' 2> до Каждому именованному буферу требуется определенное количество памяти, используемой слу" жебными структурами данных, обеспечивающими работоспособность буфера. Процедура sp_help" cache также позволяет определить количество дополнительной памяти, необходимой для именованного буфера указанного размера: 1> sp_helpcache 2> до 10.38 Mb of overhead memory will be needed to manage a cache of size 200M Для буфера длиной 200 Мбайт потребуется 10.38 Мбайт дополнительной памяти (return status = 0) В приведенном выше примере мы вычислили количество дополнительной памяти, используемой именованным буфером размером в 200 Мбайт. Именованные буферы и конфигурация сервера Для сохранения полной информации о конфигурации сервера в дополнение к копии конфигурацион" ного файла необходимо получить распечатки выдачи процедур sp_conf igure и sp_helpcache. Вы" дача sp_configure содержит информацию об общей конфигурации сервера, а также об установленных по умолчанию значениях параметров и о распределении памяти сервера, но не содер" жит сведений о конфигурации именованных буферов и о связях объектов баз данных с этими буфера" ми. Конфигурационный файл, помимо информации об общей конфигурации сервера, содержит сведения о структуре именованных буферов, но не позволяет выяснить, каким именованным буферам назначены конкретные объекты данных, — эта информация выдается процедурой sp_helpcache. Перечень связей объектов базы данных с именованными буферами можно также получить, просмат" ривая таблицы sysattributes этой базы данных.

www.books-shop.com

Использование именованных буферов Научившись создавать именованные кэш"буферы и управлять их конфигурацией, мы можем перейти к рассмотрению вопросов оптимального использования подобных буферов. Не следует забывать, что вся распределенная именованным буферам память исключается из состава общего буфера данных, поддерживающего операции восстановления данных и все остальные объекты баз данных сервера, которым не назначены именованные буферы. Разумеется, при создании новых именованных буферов необходимо следить за тем, чтобы размер общего буфера данных не становился слишком малым. Кро" ме того, для обеспечения работы каждого именованного буфера необходима определенная дополни" тельная область серверной памяти, что также ограничивает максимальное число именованных буферов. Не следует рассматривать именованные буферы как способ преодолеть нехватку оперативной па" мяти серверной машины за счет создания сложной структуры именованных кэш"буферов. Если все необходимые серверу компоненты базы данных можно разместить в оперативной памяти, то их рас" пределение по именованным буферам играет второстепенную роль. В подобной ситуации потенциа" льный выигрыш от использования именованных буферов связан исключительно с ослаблением конкуренции множественных серверных ядер за доступ к хеш"таблице общего буфера. Большое значение имеет и правильный выбор размера именованного буфера. Предположим, что необходимо создать именованный буфер для размещения часто используемой таблицы просмотра, страницы которой запрашиваются в произвольном порядке (любой запрос может в произвольный момент времени обратиться к любой странице таблицы). Если созданный кэш"буфер окажется слиш" ком мал, чтобы вместить всю таблицу просмотра, то выделение таблицы просмотра из общего буфе" ра в индивидуальный именованный буфер лишь увеличит объем физического ввода"вывода, поскольку серверу придется постоянно загружать в именованный буфер новые страницы таблицы и выгружать из него на диск страницы, просмотренные ранее. Напомним, что операции физического ввода"вывода обходятся значительно дороже (т.е. выполняются намного медленнее) логического ввода"вывода, представляющего собой перемещение страниц внутри буфера. Если общий буфер дан" ных превосходит по своим размерам именованный буфер таблицы просмотра (как это должно быть в нормальной ситуации), то, по всей видимости, лучше оставить таблицу просмотра в общем буфе" ре. Имейте в виду, что при одновременной обработке сервером больших запросов, приводящих к полной перезаписи общего буфера данных, страницы таблицы просмотра будут постоянно выгружа" ться из общего буфера, и здесь применение индивидуального буфера может оказаться оправданным. Таким образом, при создании индивидуального буфера следует выяснить назначение буфера и оце" нить его оптимальный размер, а затем сопоставить потенциальный выигрыш от создания буфера с затратами времени на мониторинг и поддержание его работоспособности. Постарайтесь также оце" нить, как скоро увеличение размеров таблицы просмотра заставит вас расширить ее именованный буфер, и насколько сильно скажется на производительности сервера уменьшение размеров общего буфера. Каждый именованный буфер представляет собой выделенную область памяти сервера, использу" емую только при обработке связанных с ней объектов баз данных, и поэтому в подобных буферах должны размещаться лишь часто используемые объекты. При оценке выгоды создания именованно" го буфера следует принимать во внимание как запросы, получающие гарантию найти свои страницы данных в создаваемом буфере, так и те запросы, которым придется чаще производить обмен данных между диском и оставшимся пространством общего буфера. Чем большая область памяти распределена именованным буферам, тем менее гибкой становится конфигурация сервера. Если вследствие увеличения доли памяти, резервируемой для буфера храни" мых процедур, оставшаяся память сервера окажется недостаточной для размещения всех именован" ных буферов, указанных в конфигурационном файле, запуск сервера станет невозможным. Подобная проблема не возникала в предыдущих версиях SQL Server, поскольку там не существовало именованных кэш"буферов. К тому же самому приводит и создание конфигурационного файла, в ко" тором общий объем именованных буферов превысит размеры памяти, доступной для кэш"буферов данных. При восстановлении сервера все серверные процессы могут использовать только общий кэш"бу" фер данных. Подобная операция часто требует повторного выполнения значительного количества транзакций, сохраненных в дампах журналов повтора, и ее продолжительность может заметно уве" личиться при существенном сокращении размеров общего буфера данных из"за наличия на сервере излишнего числа именованных буферов.

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Часто можно услышать, что механизм именованных буферов обеспечивает поддержку на одном сервере как OLTP+, так и DSS+приложений. К подобным утверждениям следует от+ носиться с долей скептицизма. Разумеется, именованные буферы позволяют предотвра+ тить выгрузку из памяти страниц данных OLTP+запросов при просмотрах больших таблиц, типичных для приложений поддержки принятия решений (DSS). Эффективная поддержка подобных приложений далеко не ограничивается созданием индивидуальных кэш+буферов. Нормальная работа полноценной и активно используемой DSS+системы требует создания весьма специфической структуры индексов, сильно отличающейся от структуры индексов таблиц приложений оперативной обработки транзакций (OLTP). По+ этому сама по себе возможность разнести объекты данных в различные буферы данных принесет весьма ограниченную пользу без создания необходимых индексных структур и т.д. На практике крайне трудно добиться удовлетворительной поддержки одним серве+ ром и OLTP+, и OSS+приложений, даже при использовании именованных кэш+буферов данных. Выбор объектов, связываемых с именованными буферами данных Хотя процесс выбора объектов базы данных, которым необходимо назначить именованные буферы данных, совсем не прост и существенно зависит от особенностей эксплуатации конкретного сервера, здесь все же можно дать ряд рекомендаций общего характера. Одним из потенциальных кандидатов на индивидуальный буфер является база данных tempdb. Хорошим кандидатом может оказаться любая часто используемая таблица просмотра, а также системная таблица sysindexes, существующая в каждой пользовательской базе данных (независимо от конфигурации базы данных, значительной части за" просов пользователей приходится обращаться к таблице sysindexes). Наконец, обработка любой часто используемой таблицы может заметно ускориться при назначении данным таблицы и ее индексам различных именованных кэш"буферов. Отметим, что подобная операция совершенно не эквивалент" на размещению таблицы и ее индексов на различных сегментах серверных устройств. Формат команд работы с именованными буферами данных и примеры их использования Поскольку процесс создания именованных буферов тесно связан с конфигурацией буферных облас" тей и больших блоков ввода"вывода, мы решили объединить все примеры в единую последователь" ность операций, представленную в разделе "Формат команд работы с буферными областями и примеры их использования". Диспетчер кэш+буфера и большие блоки ввода+вывода Каждый именованный кэш"буфер, и в том числе общий буфер данных, может иметь конфигурацию с множественными буферными областями. Буферная область (buffer pool) представляет собой набор связанных друг с другом страниц данных. Каждый именованный буфер обязательно имеет буферную область с 2"килобайтными блоками; кроме того, часть пространства буфера может быть выделена для буферной области с блоками в 4, 8 и 16 Кбайт (рис. 4.5). В предыдущих версиях SQL Server все опера" ции ввода"вывода выполнялись исключительно блоками в 2 Кбайт, и обмен страниц с буфером дан" ных осуществлялся только отдельными страницами размером в 2 Кбайт. В System 11 размер блока ввода"вывода варьируется от 2 до 16 Кбайт (т.е. до 8 страниц данных на блок); соответственно, буфер данных может либо продолжать обмениваться с диском отдельными 2"килобайтными страницами данных, либо выполнять страничный обмен блоками, содержащими до 8 страниц. Важно подчерк" нуть, что большие блоки ввода"вывода имеют отношение только к физическому вводу"выводу (пере" мещению страниц между кэш"буфером и диском), в то время как логический ввод"вывод (обращения к уже находящимся в буфере страницам данных) по"прежнему осуществляется сервером постранично. Буферные области Для использования больших блоков ввода"вывода, появившихся в System 11, необходимо создать в именованных кэш"буферах данных буферные области с блоками соответствующего размера. Каждый именованный кэш"буфер, включая общий кэш"буфер данных, состоит по крайней мере из одной

www.books-shop.com

блоки в 2 Кбайт блоки в 4 Кбайт блоки в 8 Кбайт блоки в 16 Кбайт

область оперативной памяти серверного компьютера, отведенная серверу Рис. 4.5. Буферные области System 11 буферной области. Под буферной областью здесь подразумевается набор указателей на находящиеся в памяти страницы данных. Эти указатели (иногда их также называют буферами, или буферными бло" ками) используются для поиска страниц данных в памяти кэш"буфера данных. При создании нового именованного кэш"буфера сервер создает в нем буферную область указанного вами размера с блоками длиной в 2 Кбайт. Затем администратор базы данных может выделить в именованном буфере допол" нительные буферные области с блоками разного размера — 4, 8 или 16 Кбайт. Таким образом, только что созданный именованный кэш"буфер размером в 10 Мбайт первоначально состоит из 5120 2"кило" байтных буферных блоков. Выделив затем в этом буфере 2"мегабайтную буферную область, состоя" щую из 64 16"килобайтных буферных блоков, мы получим именованный буфер, состоящий из двух буферных"областей: области с 2"килобайтными блоками (ее размер составит 8 Мбайт) и области с 16"килобайтными блоками, занимающей оставшиеся 2 Мбайт. Каждый именованный кэш"буфер мо жет иметь не более одной буферной области с блоками определенной длины; таким образом, любой кэш"буфер состоит максимум из четырех буферных областей с блоками размером в 2, 4, 8 и 16 Кбайт. Пример гипотетической конфигурации именованных кэш"буферов и их буферных областей показан на рис. 4.6.

Рис. 4.6. Пример конфигурации буферных областей в System 11 Буферная область характеризуется двумя параметрами: общим размером области и длиной буферного блока. Не следует думать, что 2+килобайтная буферная область имеет общий размер в 2 Кбайт, поскольку в данном случае речь идет о размере буферного блока (составляющем 2 Кбайт). К сожалению, подобные проблемы лингвистического ха+ рактера нередко возникают при чтении официальной системной документации Sybase, где можно встретить выражения типа "минимальный размер буферной области состав+ ляет 512 Кбайт, а максимальный размер буфера этой области равен 16 Кбайт". Это означает, что любая буферная область в любом кэш+буфере должна иметь размер не менее 512 Кбайт независимо от размера буферов в этой области, а самый большой бу+ фер имеет размер 16 Кбайт.

www.books-shop.com

При обмене страницами данных между диском и именованным кэш"буфером сервер автоматиче" ски определяет оптимальный размер блока ввода"вывода и использует его при физическом обмене с диском. Это может произойти, если существует буферная область, имеющая достаточное количест" во свободных буферных блоков нужного размера. В ситуации, когда серверу необходимо прочитать одну 2"килобайтную страницу данных, она будет помещена в свободный буферный блок размером 2 Кбайт. Когда серверу нужно поместить в память сразу большое число страниц данных, он попыта" ется использовать 16"килобайтные блоки. Если буферная область с блоками по 16 Кбайт отсутствует, она не будет автоматически создана сервером (при отсутствии свободного буферного блока нужного размера сервер использует любые другие свободные буферные блоки). Размер буферного блока, фактически используемый сервером, можно увидеть в распечатке плана выполнения запроса, выда" ваемой с помощью команды set showplan. Анализ подобной распечатки (ее состав существенно рас" ширен в System 11) окажется крайне полезным, поскольку можно узнать, как именно сервер будет обрабатывать каждый конкретный запрос. К примеру, даже при существовании буферной области с блоками желаемого размера оптимизатор запросов может принять решение не использовать ее (ска" жем, при небольшом числе выбираемых страниц данных). Существование множественных буферных областей не изменяет LRU/MRU алгоритм функцио" нирования кэш"буфера данных, сводящийся к вытеснению давно не использовавшихся страниц дан" ных (рис. 4.7). Каждая буферная область именованного кэш"буфера имеет отдельную LRU/MRU"цепочку страниц, перемещаемую независимо от страниц данных других буферных облас" тей того же самого кэш"буфера. При полном отсутствии свободных буферных блоков сервер выгру" жает на диск наиболее давно не использовавшиеся (least recently used, LRU) страницы. Помимо индивидуальной цепочки страниц данных, каждая буферная область имеет и свою собственную хеш"таблицу. >>

Рис. 4.7. Цепочки страниц в буферных областях В каких ситуациях следует использовать большие блоки ввода+вывода? Администратор базы данных должен ясно понимать, когда имеет смысл воспользоваться большими блоками ввода"вывода, появившимися в System 11. Применение буферных областей с 16"килобайтны" ми блоками позволяет значительно ускорить выполнение многих операций поддержания работоспо" собности сервера, например bср или dbcc. Такие буферные области заметно повысят эффективность обработки запросов, модифицирующих все (или почти все) записи таблицы данных, в которых сер" вер выполняет полный последовательный просмотр таблицы, не перескакивая через несколько стра" ниц при переходе от одной строки данных к другой. Большие блоки ввода"вывода существенно ускоряют любые запросы, выбирающие большую часть страниц таблицы данных в том же порядке, в котором эти страницы физически размещаются на диске. Секрет прост: при необходимости сервер способен прочитать с диска 8 страниц подряд за одну операцию ввода"вывода, тем самым исключив физический ввод"вывод до момента полной обработки всех 8 прочитанных страниц данных. Использование больших блоков ввода"вывода может повысить скорость обработки запросов, включающих в себя соединения крупных таблиц данных, полный просмотр таких таблиц, а также сканирование по диапазону. Любые обращения к журналу повтора базы данных ускоряются при на" личии буферной области с 4"килобайтными блоками. Нужно заметить, что буферные области с боль" шими блоками ввода"вывода можно создавать по мере необходимости (например, только на время запуска администратором базы данных больших пакетных задач в часы наименьшей загрузки

www.books-shop.com

сервера). Подобная стратегия позволяет ускорить выполнение необходимых операций по поддержа" нию работоспособности сервера и сократить время его недоступности для других пользователей. Создание буферных областей с большими блоками ввода+вывода Механизм больших блоков ввода"вывода не принесет пользы, если администратор сервера заранее не побеспокоится о создании буферных областей с блоками требуемого размера с помощью команд сле" дующего вида: 1> sp_poolconfig psycho_cache , '6М', '8К' 2> до В данном примере создается буферная область общим размером в 6 Мбайт, состоящая из буфер" ных блоков размером по 8 Кбайт каждый. Такую буферную область иногда называют 8"килобайтной буферной областью (8К buffer pool). Как и в команде sp_cacheconf ig, в sp_poolconf ig использу" ются следующие единицы измерения: 2"килобайтные страницы (Р), килобайты (К), мегабайты (М) и гигабайты (G). Сразу после создания именованного кэш"буфера все его пространство автоматически конфигурируется в виде единой буферной области с блоками по 2 Кбайт, после чего администратор сервера может выделить в пространстве буфера дополнительные буферные области. Таким обра" зом, создание дополнительных буферных областей не увеличивает общие размеры буфера. Все ска" занное выше полностью применимо и к общему (используемому по умолчанию) кэш"буферу данных. Другим способом создания буферных областей является внесение строк описания этих областей в конфигурационный файл сервера с последующим его перезапуском. Строки описания буферной об" ласти, созданной в рассмотренном примере, приведены ниже: [Named Cache: psycho_cache] cache size = 10M cache status = mixed cache [8K I/O Buffer Pool] pool size = 6M Создание или модификация буферных областей, в отличие от именованных буферов, является динамической модификацией конфигурации сервера и не требует его перезапуска (только лишь в том случае, если соответствующий именованный буфер уже существует). Если вы сконфигурируете в работающем сервере новый именованный буфер командой sp_cacheconf ig и затем сразу создади" те в этом буфере буферную область, то созданная область не может быть активизирована до момен" та перезапуска сервера из"за отсутствия именованного буфера, содержащего эту область. Размер буферных областей именованного кэш"буфера может быть изменен в любой момент, что позволяет передать часть пространства буфера из одной области в другую. К примеру, команда sp_poolconfig psycho_cache, '1M', '4К', '8К' передаст 1 Мбайт пространства буфера из буферной области с 8"килобайтными блоками в об" ласть с 4"килобайтными блоками, в результате чего размер первой области сократится с 6 до 5 Мбайт. Разумеется, подобная команда не изменяет общий объем именованного буфера. Имейте в виду, что пространство буфера передается сервером из одной области в другую только целыми бло" ками: сервер передает максимальное количество буферных блоков, которое способно поместиться в области пространства указанного размера. Поскольку изменение параметров буферной области является динамической реконфигурацией сервера, подобная операция способна повлиять на ход обработки текущих запросов, выполняемых сервером в данный момент. Предположим, вы запускаете утилиту Ьср для копирования данных табли" цы, которой назначен именованный кэш"буфер, и большая часть указанного буфера сконфигурирова" на в виде буферной области с блоками по 16 Кбайт. При удалении этой буферной области ее пространство поступит в стандартную буферную область с блоками по 2 Кбайт, и утилита bср будет вынуждена выполнить оставшийся физический ввод"вывод короткими 2"килобайтными блоками, что существенно замедлит ее работу. Для удаления буферной области достаточно ввести команду вида sp_poolconfig psycho_cache, 0, '8К' устанавливающую размер буферной области с 8"килобайтными блоками равным нулю. Использовав" шееся этой областью пространство кэш"буфера будет автоматически распределено буферной области с размером блока в 2 Кбайт.

www.books-shop.com

Существует целый ряд ситуаций, требующих изменения конфигурации буферных областей — на" пример, при недостатке свободных буферов необходимого серверу размера либо при переходе от OLTP"приложений к эпизодической обработке DSS"запросов. Разумеется, модификация параметров буферных областей связана с целым рядом ограничений. Общая величина всех буферных областей именованного кэш"буфера не может превышать размеров этого буфера. Каждый кэш"буфер должен включать в себя буферную область с 2"килобайтными бло" ками, размеры которой не могут быть менее 512 Кбайт. Допустимые размеры блоков буферной обла" сти составляют 2, 4, 8 или 16 Кбайт, причем все вновь создаваемые буферные области с блоками большего размера создаются за счет пространства исходной области с 2"килобайтными блоками. Особенности внутренней организации буферных областей Итак, буферная область представляет собой упорядоченную последовательность буферных блоков определенного размера (например, 2 Кбайт). Каждый буферный блок (иногда также называемый бу" фером) может содержать от одной до восьми страниц данных (для буферных блоков размером в 16 Кбайт). До выхода в свет System 11 все буферные блоки имели размер в 2 Кбайт и содержали ровно одну страницу данных, вследствие чего вместо термина "буферный блок" практически всегда говори" ли о "страницах данных". Разница между этими двумя понятиями становится существенной благодаря появлению в System 11 возможности создания отдельных буферных областей с блоками в 2, 4, 8 и 16 Кбайт. Сервер по"прежнему осуществляет выборку всех данных 2"килобайтными страницами, но при наличии буферных областей с блоками большего размера физический ввод"вывод страниц осуще" ствляется теперь по нескольку страниц одновременно. Последовательность буферных блоков в каж" дой буферной области изменяется в соответствии с LRU/MRU"алгоритмом вытеснения из памяти наименее используемых блоков. При этом последний прочитанный с диска блок помещается в начало буфера вместе с другими блоками, недавно потребовавшимися серверу, а давно не использовавшийся блок оказывается в самом конце буфера и сбрасывается на диск, если серверу нужно поместить новый блок в буфер. Отметим, что при работе с большими блоками ввода"вывода сервер одновременно чи" тает с диска и записывает на диск несколько страниц данных, количество которых определяется раз" мером буферного блока. Сервер записывает на диск содержимое кэш"буфера данных, если необходимо освободить буферный блок или в момент создания контрольной точки. В System 11 администратор сервера может установить так называемую точку очистки (wash point) блоков именованного кэш"буфера, определяющую, насколько далеко к концу буфера могут перемеща" ться модифицированные ("грязные") страницы данных без записи их содержимого на диск. Страницы всех буферных блоков, находящихся между точкой очистки и концом цепочки, являются "чистыми" (т.е. не содержат не сохраненных на диске изменений), и их не надо записывать на диск при выгрузке из буфера. При наличии в кэш"буфере свободных, или чистых, буферных блоков страничный обмен выполняется сервером намного быстрее. При выборе точки очистки необходимо соблюсти разумный компромисс. Если точка очистки установлена слишком близко к началу буферной цепочки, будет про" изводиться излишне частая запись содержимого модифицированных ("грязных") буферных блоков на диск. Если точка очистки сильно смещена в конец цепочки, найти требуемое количество чистых бло" ков невозможно. В последнем случае серверу придется записать на диск содержимое выгружаемых блоков, что также приведет к увеличению объема физического ввода"вывода. Использование больших блоков ввода+вывода Оптимальная конфигурация кэш"буфера данных сервера, большая часть пространства которого рас" пределена общему буферу, а несколько именованных кэш"буферов занимают лишь незначительную часть всей доступной памяти, способна избавить администратора сервера от многих неприятностей. Наоборот, создание сложной структуры именованных буферов и буферных областей может привести к целому ряду проблем. При создании нового именованного буфера распределяемое ему пространство берется из 2"кило" байтной буферной области общего кэш"буфера. Создание в общем буфере одной или нескольких бу" ферных областей с большими буферными блоками может заблокировать создание новых именованных буферов (см. рис. 4.8). Хранимая процедура способна использовать буферную область с большими блоками только при условии существования этой области в момент компиляции процедуры. Изменения в структуре име" нованных буферов или буферных областей в пределах этих буферов могут привести к необходимо" сти повторной компиляции всех хранимых процедур, способных воспользоваться новыми буферными областями.

www.books-shop.com

буферная область с блоками в 2 Кбайт создаваемая по умолчанию

все операции ввода+вывода выполняются блоками по 2 Кбайт

именованный кэш+буфер 1 Рис. 4.8. Именованные кэш*буферы занимают память, ранее распределенную общему кэш*буферу данных Сервер лишен возможности автоматически создавать необходимые ему буферные области и име" нованные кэш"буферы, а также связывать объекты данных с этими буферами. Даже если оптимиза" тор запросов обнаружит предпочтительность буферной области с блоками определенного размера, при отсутствии какой"либо из необходимых структур буфера данных серверу придется использовать имеющиеся структуры с блоками другого размера. К примеру, при отсутствии в именованных кэш"буферах дополнительных буферных областей сервер сможет выполнять ввод"вывод только стан" дартными 2"килобайтными блоками. Многие ситуации, в которых использование дополнительных буферных областей кажется луч" шим способом преодоления возникших проблем, в действительности имеют еще более эффектив" ное и простое решение — увеличение памяти серверной машины. Если необходимо одновременно поддерживать OLTP" и DSS"приложения, самым надежным решением может быть вынесение запро" сов какого"то одного типа на дополнительную серверную машину (кстати говоря, это существенно увеличит общий объем памяти всей системы). Вместо бесконечных попыток найти оптимальный ба" ланс между буферными областями различных размеров постарайтесь выделить достаточное количе" ство буферов, размер которых адекватен реальной нагрузке на сервер. Разумеется, вам придется установить в серверную машину необходимое количество оперативной памяти либо перераспреде" лить часть нагрузки дополнительному серверному компьютеру. Динамическая конфигурация буферных областей вместе с изучением необходимой доку+ ментации, приобретением практического опыта использования соответствующих команд и устранением неизбежных ошибок требуют больших затрат времени со стороны адми+ нистратора базы данных. Значительная часть этих усилий может в любой момент стать источником дополнительных проблем. Удастся ли вам быстро восстановить после сбоя сервер, содержащий множество именованных буферов вместо единственного общего буфера, так необходимого в этот трудный момент? Будет ли у вас (или администратора другой базы данных, срочно вызванного на подмогу) достаточно времени разобраться во всех подробностях конфигурации отказавшего сервера? Формат команд работы с буферными областями и примеры их использования До создания первого именованного буфера на сервере имеется только общий кэш"буфер данных. Явно установленных связей между объектами баз данных и кэш"буферами не существует. Примеча" ние: для общего кэш"буфера данных значение "Config Size = 0.00" является нормальным. 1> sp_helpcache 2> до Cache Name Config Size Run Size Overhead 28.58 Mb 1.18 Mb default data cache 0.00 Mb Memory Available For Memory Configured To Named Caches Named Caches 22.58 Mb 0.00 Mb

www.books-shop.com

There is 22.58 Mb of memory left over that will be allocated to the default cache 22.58 Мбайт незадействованной памяти будет распределено для кэш#буфера, используемого по умолчанию Cache Binding Information Cache Name Entity Name Type Index Name Status (return status = 0)

Создание именованного кэш буфера 1> sp_cacheconfig psycho_cache1, '10M' 2> go 0 The change is completed. The SQL Server must be rebooted for the change to take effect. Изменение внесено в конфигурацию сервера и будет активизировано после перезапуска SQL Server. (return status = 0 )

Запись о создании именованного кэш буфера заносится в журнал регистрации ошибок 00:96/06/05 19:17:04.13#Server configuration file '/home/sybase/11.0.1/PSYCHOll.cfg' has been written and the previous version has been renamed to '/home/sybase/11.0.1/PSYCHO11.002'

Получение информации о существующих кэш буферах командой sp_helpcache Значение "Run Size = 0.00" сообщает, что указанный буфер пока не создан. 1> sp_helpcache 2> до Cache Name Config Size Run Size Overhead default data cache 0.00 Mb 28.58 Mb 1.18 Mb Psycho_cache1 10.00 Mb 0.00 Mb 0.00 Mb Memory Available For Memory Configured Named Caches To Named Caches 22.58 Mb 10.00 Mb There is 12.58 Mb of memory left over that will be allocated to the default cache 12.58 Мбайт незадействованной памяти будет распределено для кэш#буфера, используемого по умолчанию Cache Binding Information Cache Name Entity Name Type Index Name Status (return status = 0)

Получение информации о существующих кэш буферах командой sp_cacheconfig ПРИМЕЧАНИЕ. Статус Pend/Act означает, что указанный буфер пока не создан. Команда sp_cacheconf ig сообщает более детальную информацию о каждом именованном буфере и сконфи гурированных буферных областях, в то время как выдача команды sp_helpcache подробнее описы вает распределение памяти и сообщает о размерах дополнительной памяти (overhead), используемой буфером. 1> sp_cacheconfig 2> go

Cache Name default data cache

Status Active

Type Default

Config Value 0.00 Mb

Run Value 22.58 Mb

www.books-shop.com

Psycho cachel

Pend/Act

10.00 Mb 0.00 Mb Mixed 10.00 Mb Total 22.58 Mb Cache: default data cache, Status: Active, Type: Default Config Size: 0.00 Mb, Run Size: 22.58 Mb IO Size Wash Size Config Size Run Size 2 Kb 512 Kb 0.00 Mb 22.58 Mb (return status = 0) Получение информации об определенном именованном кэш буфере 1> sp_helpcache psycho_cache1 2> go Cache Name Config Size Run Size Overhead psycho_cachel 10.00 Mb 0.00 Mb 0.00 Mb

Cache Name

Cache Binding Information Entity Name Type

Index Name

Status

(return status = 0) Изменения, внесенные в конфигурационный файл при создании именованного кэш буфера [Named Cache:psycho_cache1] cache size = 10M cache status = mixed cache Попытка создания буферной области в именованном буфере завершилась неудачей, поскольку указанного буфера на самом деле еще не существует. 1> sp_poolconfig psycho_cache1, '6М', '8К' 2> go

The source pool request to move Размеры исходной недостаточны для

(1p buffers, total size 0) is not large enough to satisfy the 6144Kb of memory буферной области (1#страничные буферные блоки, общий размер 0) выполнения запроса на перемещение 6144 Кбайт оперативной памяти

(return status = 1) После перезапуска сервера "Config Size" становится равным "Run Size", что отражает факт создания именованного кэш буфера. 1> sp_helpcache 2> до Cache Name Config Size Run Size Overhead default data cache 0.00 Mb 12.56 Mb 0.65 Mb Psycho_cache1 10.00 Mb 10.00 Mb 0.53 Mb Memory Available For Named Caches 22.58 Mb

#

Memory Configured To Named Caches 10.00 Mb

There is 12.58 Mb of memory left over that will be allocated to the default cache 12.58 Мбайт незадействованной памяти будет распределено для кэш#буфера, используемого по умолчанию Cache Binding Information Cache Name Entity Name Type Index Name Status (return status = 0) Теперь в именованном буфере можно создать буферную область размером в 6 Мбайт с блоками АЛИНОЙ в 8 Кбайт 1> sp_poolconfig psycho_cache1, '6М', '8К'

www.books-shop.com

2> до (return status = 0) Запись об изменении конфигурационного файла заносится в журнал регистрации ошибок 00:96/06/05 19:24:53.30#Server configuration file ' /home/sybase/11.0.1/PSYCHO11 .cfg' has been written and the previous version has been renamed to ' /home/sybase/11.0.1/PSYCHO11.003 ' Проверка конфигурации буферных областей в именованном буфере 1> sp_poolconfig psycho_cachel 2> go Cache Name Status Type Config Value Run Value Psycho_cachel Active Mixed 10.00 Mb 10.00 Mb _ Total _ 10.00 Mb _ 10.00 Mb

_

Cache : psycho_cache1 , Status: Active, Type: Mixed Config Size: 10.00 Mb, Run Size: 10.00 Mb IO Size Wash Size Config Size Run Size 2 Kb 512 Kb 0.00 Mb 4.00 Mb 8 Kb 2048 Kb 6.00 Mb 6.00 Mb (return status=0) . Описание именованных кэш буферов в конфигурационном файле сейчас выглядит следующим образом: [Named Cache :default data cache] cache size = DEFAULT cache status = default data cache [Named Cache :psycho_cachel] cache size = 10M cache status = mixed cache [8K I/O Buffer Pool] pool size = 6.0000M wash size = DEFAULT Связывание таблицы данных с именованным кэш буфером 1> sp_bindcache psycho_cache , admindb, def_actions 2> go (return status = 0) Выдача информации об объектах данных, назначенных именованному буферу. Значение "Status = V" характеризует связь как действительную. 1> sp_helpcache psycho_cache1 2> go Cache Name Config Size Run Size Overhead psycho_cache1 10.00 Mb 10.00 Mb # 0.53 Mb ############### cache Binding Information  Cache Name Entity Name Type Index Name Status psycho_cachel admindb.dbo.def_actions table V (return status = 0) Связь объекта с буфером отражается в таблице sysattrtbutes пользовательской базы данных. Для подобных записей устанавливается значение "class = 3".

1> select * from sysattributes 2> go class 3 0

attribute

object_type Т

object_cinfo NULL

object 1280007591

www.books-shop.com

(17 rows affected)

Подтверждение связанности объекта 1> select object_name(1280007591) 2> go def_actions (1 row affected)

Создание второго именованного буфера 1> sp_cacheconfig psycho_cache2, '1М' 2> go 0' The change is completed. The SQL Server must be rebooted for the change to take effect. Изменение внесено в конфигурацию сервера и будет, активизировано после перезапуска SQL Server. (return status = 0 )

Запись об изменении конфигурационного файла заносится в журнал регистрации ошибок 00:96/06/05 19:39:41.36#Server configuration file '/home/Sybase/11.0.1/PSYCHO11.cfg' has been written and the previous version has been renamed to '/home/sybase/11.0.1/PSYCH011.004'

Проверка конфигурации именованных кэш буферов. Вновь созданный буфер имеет статус Pend/Act и содержит только основную буферную область с 2 килобайтными блоками. 1> sp_cacheconfig 2> go Cache Name default data cache psycho_cachel psycho_cache2

Status Active Active Pend/Act

Type Default • Mixed Mixed Total

Config Value 0.00 Mb 10.00 Mb 1.00 Mb 11.00 Mb

Run Value 12.56 Mb 10.00 Mb 0.00 Mb 22.56 Mb

Cache: default data cache, Status: Active, Type: Default Config Size: 0.00 Mb, Run Size: 12.56 Mb IО Size Wash Size Config Size Run Size 2 Kb 512 Kb 0.00 Mb 12.56 Mb Cache:

psycho_cache1, Status: Active, Type: Mixed Config Size: 10.00 Mb, Run Size: 10.00 Mb Config Size Run Size IО Size Wash Size 2 Kb 512 Kb 0.00 Mb 4.00 Mb 6.00 Mb 6.00 Mb 8 Kb 2048 Kb (return status = 0)

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Описание именованных кэш буферов в конфигурационном файле приобретает следующий вид: [Named Cache: default data cache] cache size = DEFAULT cache status = default data cache [Named Cache :psycho_cache1] cache size = 10M cache status = mixed cache [8K I/O Buffer Pool] pool size = 6.0000M wash size = DEFAULT [Named Cache :psycho_cache2] cache size = 1M cache status = mixed cache

Перезапуск сервера: в журнал регистрации ошибок записываются размеры именованных кэш буферов и конфигурация их буферных областей 00:96/06/05 19:49:44.84 kernel Network and device connection limit is 1014. 00:96/06/05 19:49:44.86 server Number of proc buffers allocated: 3039. 00:96/06/05 19:49:44.94 server Number of blocks left for proc headers: 3086. 00:96/06/05 19:49:44.94 server Memory allocated for the default data cache cache: 11768 Kb 00:96/06/05 19:49:44.96 server Size of the 2K memory pool: 11768 Kb 00:96/06/05 19:49:44.96 server Memory allocated for the psycho_cachel cache: 10240 Kb 00:96/06/05 19:49:44.96 server Size of the 2K memory pool: 4096 Kb 00:96/06/05 19:49:44.97 server Size of the 8K memory pool: 6144 Kb 00:96/06/05 19:49:44.97 server Memory allocated for the psycho_cache2 cache: 1024 Kb 00:96/06/05 19:49:44.97 server Size of the 2K memory pool: 1024 Kb 00:96/06/05 19:49:44.98 kernel Initializing virtual device 0,

Проверка конфигурации именованных кэш буферов после перезапуска сервера 1 > sp_helpcache 2 > go Cache Name Config Size Run Size Overhead default data cache 0.00 Mb 11.49 Mb 0.60 Mb psycho_cachel 10.00 Mb 10.00 Mb 0.53 Mb psycho_cache2 1.00 Mb 1.00 Mb 0.11 Mb Memory AvailableFor Memory Configured Named Caches To Named Caches 22.52 Mb 11.00 Mb There is 11.52 Mb of memory left over that will be allocated to the default cache 11.52 Мбайт незадействованной памяти будет распределено для кэш#буфера, используемого по умолчанию

www.books-shop.com

 Cache Binding Information  Cache Name Entity Name Type Index Name Status psycho_cachel admindb.dbo.def_actions table V (return status = 0) Проверка конфигурации именованных кэш буферов командой sp_cacheconfig. Вновь созданный буфер имеет статус "Active". 1> sp_cacheconfig 2> go Status Type Config Value Cache Name Run Value Active Default 0.00 Mb default data cache 11.49 Mb Active Mixed 10.00 Mb 10.00 Mb psycho_cachel Mixed psycho_cache2 Active 1.00 Mb 1.00 Mb Total 11.00 Mb 22.49 Mb Cache: default data cache, Status: Active, Type: Default Config Size: 0.00 Mb, Run Size: 11.49 Mb IO Size Wash Size Config Size Run Size 2 Kb 512 Kb 0.00 Mb 11.49 Mb Cache: psycho_cachel, Status: Active, Type: Mixed Config Size: 10.00 Mb, Run Size: 10.00 Mb Wash Size Config Size TO Size Run Size 512 Kb 2 Kb 0.00 Mb 4.00 Mb 2048 Kb 6.00 Mb 8 Kb 6.00 Mb Cache: psycho_cache2, Status: Active, Type: Mixed Config Size: 1.00 Mb, Run Size: 1.00 Mb IO Size Wash Size Config Size Run Size 2 Kb 204 Kb 0.00 Mb 1.00 Mb (return status = 0)

Для удаления именованного кэш буфера его размер достаточно установить равным нулю Удаляемому буферу не назначено никаких объектов баз данных 1> sp_cacheconfig psycho_cache2, 'О' 2> go The change is completed. The SQL Server must be rebooted for the change to take effect. Изменение внесено в конфигурацию сервера и будет активизировано после перезапуска SQL Server. (return status = 0 )

Запись об изменении конфигурационного файла заносится в журнал регистрации ошибок 00:96/06/05 19:51:49.62#Server configuration file '/home/sybase/ll.O.l/PSYCHOll.cfg' has been written and the previous version has been renamed to '/home/sybase/11.0.1/PSYCHO11.007'

Проверка конфигурации именованных кэш буферов Значение "Config Size = 0.00" указывает на то, что соответствующий буфер будет удален после перезапуска сервера. 1> sp_helpcache 2> go Cache Name Config Size Run Size Overhead default data cache 0.00 Mb 11.49 Mb 0.60 Mb

www.books-shop.com

psycho_cachel 10.00 Mb 10.00 Mb 0.53 Mb psycho_cache2 0.00 Mb 1.00 Mb 0.11 Mb Memory Available For Memory Configured Named Caches To Named Caches 22.52 Mb 10.00 Mb There is 12.52 Mb of memory left over that will be allocated to the default cache 12.52 Мбайт незадействованной памяти будет распределено для кэш#буфера, используемого по умолчанию ################# Cache Binding Information ############# Cache Name Entity Name Type Index Name Status psycho_cachel admindb.dbo.def_actions table V (return status = 0) Проверка конфигурации именованных кэш буферов КОМаНдОЙ sp_cacheconfig

Статус Act/Del означает, что указанный буфер будет удален после перезапуска сервера. 1> sp_cacheconfig 2> go Cache Name default data cache psycho_cachel psycho_cache2 _ Total _

Status Active Active Act/Del 10.00

Type Config Value Run Value Default 0.00 Mb 11.49 Mb Mixed 10.00 Mb 10.00 Mb Mixed 0.00 Mb 1.00 Mb Mb _ 22.49 Mb

Cache: default data cache, Status: Active, Type: Default Config Size: 0.00 Mb, Run Size: 11.49 Mb IO Size Wash Size Config Size Run Size _ 2 Kb _ 512 Kb _ 0.00 Mb _ 11.49 Mb Cache : psycho_cachel , Status: Active, Type: Mixed Config Size: 10.00 Mb, Run Size: 10.00 Mb IO Size Wash Size Config Size Run Size 2 Kb 512 Kb 0.00 Mb 4.00 Mb _ 8 Kb _ 2048 Kb _ 6.00 Mb _

_

_

6.00

Mb

_

Cache : psycho_cache2 , Status: Act/Del, Type: Mixed Config Size: 0.00 Mb, Run Size: 1.00 Mb IO Size Wash Size Config Size Run Size 2 Kb 204 Kb 0.00 Mb 1.00 Mb (return status = 0)

Описание именованных кэш буферов в конфигурационном файле приобретает следующий вид: [Named Cache: default data cache] cache size = DEFAULT cache status = default data cache [Named Cache :psycho_cachel] cache size = 10M cache status = mixed cache [8K I/O Buffer Pool] pool size = 6.0000M wash size = DEFAULT

Удаление именованного кэш буфера, имеющего связанный объект базы данных 1> sp_cacheconfig psycho_cachel , 'О'

www.books-shop.com

2> go The change is completed. The SQL Server must be rebooted for the change to take effect. Изменение внесено в конфигурацию сервера и будет активизировано после перезапуска SQL Server. (return status = 0)

Запись об изменении конфигурационного файла заносится в журнал регистрации ошибок 00:96/06/05 19:56:03.67#Server configuration file ' /home/sybase/11. 0.1/PSYCHOll.cfg' has been written and the previous version has been renamed to ' /home/sybase/11.0.1/PSYCHO11.008 '

Строки описания именованных кэш буферов в конфигурационном файле теперь выглядят так: [Named Cache: default data cache] cache size = DEFAULT cache status = default data cache

Проверка конфигурации именованных кэш буферов Значение "Config Size = 0.00" указывает на то, что соответствующий буфер будет удален при перезапу ске сервера. Связь объекта данных с удаленным буфером попрежнему существует. 1> sp_helpcache 2> до Cache Name Config Size Run Size Overhead default data cache 0.00 Mb 11.49 Mb 0.60 Mb psycho_cachel 0.00 Mb 10.00 Mb 0.53 Mb psycho_cache2 0.00 Mb 1.00 Mb 0.11 Mb Memory Available For Memory Configured Named Caches To Named Caches 22.52 Mb 10.00 Mb There is 12.52 Mb of memory left over that will be allocated to the default cache 12.52 Мбайт незадействованной памяти будет распределено для кэш#буфера, используемого по умолчанию ################## Cache Binding Information  Cache Name Entity Name Type Index Name Status Psycho_cachel admindb.dbo.def_actions table V (return status =0) . • Проверка конфигурации именованных кэш.буферов Статус Act/Del означает, что указанный буфер будет удален при перезапуске сервера. 1> sp_cacheconfig 2> go Cache Name Status Type Config Value Run Value Default default data cache Active 0.00 Mb 11.49 Mb Psycho_cachel Act/Del Mixed 0.00 Mb 10.00 Mb Psycho cache2 Act/Del Mixed 0.00 Mb 1.00 Mb Total 0.00 Mb 22.49 Mb Cache: default data cache, Status: Active, Type: Default Config Size: 0.00 Mb, Run Size: 11.49 Mb IO Size Wash Size Config Size Run Size

2 Kb

512 Kb

0.00 Mb

11.49 Mb

www.books-shop.com

Cache: psycho_cachel, Status: Act/Del, Type: Mixed Config Size: 0.00 Mb, Run Size: 10.00 Mb IO Size Wash Size Config Size Run Size 2 Kb 512 Kb 0.00 Mb 4.00 Mb 8 Kb 2048 Kb 6.00 Mb 6.00 Mb Cache: psycho_cache2, Status: Act/Del, Type: Mixed Config Size: 0.00 Mb, Run Size: 1.00 Mb IO Size Wash Size Config Size Run Size 2 Kb 204 Kb 0.00 Mb 1.00 Mb (return status = 0)

Проверка конфигурации именованного буфера Буферные области удаленного буфера продолжают существовать. 1> sp_poolconfig psycho_cachel 2> go Config Value Cache Name Status Type Psycho cachel 0.00 Mb Act/Del Mixed Total 0.00 Mb

Run Value 10.00 Mb 10.00 Mb

Cache: psycho_cachel, Status: Act/Del, Type: Mixed Config Size: 0.00 Mb, Run Size: 10.00 Mb IO Size Wash Size Config Size Run Size 2 Kb 204 Kb 0.00 Mb 1.00 Mb 8 Kb 2048 Kb 6.00 Mb 6.00 Mb (return status = 0) Информация о связи объекта остается в таблице sysattrtbutes без изменений class attribute object_type object_cinfo object 3 0 Т NULL 1280007591 object_infol object_info2 object_info3 int_value NULL NULL NULL 1 char_value text_value image_value comments psycho_cachel NULL N ULL NULL

Перезапуск сервера: в журнал регистрации ошибок выводится сообщение только о создании общего кэш буфера донных 00:96/06/05 20:00:32.05 server Number of proc buffers allocated: 3042. 00:96/06/05 20:00:32.16 server Number of blocks left for proc headers: 3091. 00:96/06/05 20:00:32.16 server Memory allocated for the default data cache cache: 21320 Kb 00:96/06/05 20:00:32.21 server Size of the 2K memory pool: 23120 Kb 00:96/06/05 20:00:32.21 kernel Initializing virtual device 0,

В журнал регистрации ошибок также выводится сообщение о недействительной связи объекта

00:96/06/05 20:00:37.60 server Recovering database 'admindb' 00:96/06/05 20:00:37.61 server

www.books-shop.com

Recovery dbid 4 ckpt (31286,32) 00:96/06/05 20:00:37.61 server Recovery no active transactions before ckpt. 00:96/06/05 20:00:38.90 server Cache binding for database '4', object '1280007591', index '0' is being marked invalid in Sysattributes 00:96/06/05 20:00:38.92 server The transaction log in the database 'admindb' will use I/O size of 2 Kb. 00:96/06/05 20:00:38.97 server Database 'admindb' is now online. Модифицированная запись таблицы sysattributes Значение девятого параметра (int_value) теперь равняется нулю. class attribute object_type object_cinfo object Т NULL 3 0 1280007591 int_value object_infol object_info2 object_info3 NULL NULL 0 NULL text_value image_value comments char value Psycho_cachel NULL NULL NULL Проверка конфигурации именованных кэш буферов 1> sp_helpcache 2> go Config Size Cache Name Run Size Overhead default data cache 28.58 Mb 0.00 Mb 1.18 Mb Memory Available For Memory Configured Named Caches To Named Caches 22.58 Mb 0.00 Mb There is 22.58 Mb of memory left over that will be allocated to the default cache 22.58 Мбайт незадействованной памяти будет распределено для кэш#буфера, используемого по умолчанию Cache Binding Information Cache Name Entity Name Type Index Name Status (return status =0) 1> sp_cacheconfig 2> go Cache Name Status Config Value Type Run Value default data cache Active Default 0.00 Mb 22.58 Mb Total 22.58 Mb 0.00 Mb Cache: default data cache, Status: Active, Type: Default Config Size: 0.00 Mb, Run Size: 22.58 Mb IO Size Wash Size Config Size Run Size 2 Kb 512 Kb 0.00 Mb 22.58 Mb (return status = 0) Заново создаем кэш буфер, удаленный ранее 1> sp_cacheconfig psycho_cachel, '10М' 2> до

О The change is completed. The SQL Server must be rebooted for the change to take effect. Изменение внесено в конфигурацию сервера и будет активизировано после перезапуска SQL Server, (return status = 0 )

www.books-shop.com

До перезапуска сервера проверим состояние именованных кэш буферов Значение "Status = I" свидетельствует о недействительности связи. 1> sp_helpcache 2> до Cache Name Config Size Run Size default data cache 0.00 Mb 22.58 Mb Psycho_cachel 10.00 Mb 0.00 Mb

Overhead 1.18 Mb 0.00 Mb

Memory Available For Memory Configured Named Caches To Named Caches 22.58 Mb 10.00 Mb There is 12.58 Mb of memory left over that will be allocated to the default cache 12.58 Мбайт незадействованной памяти будет распределено для кэш#буфера, используемого по умолчанию ################# Cache Binding Information  Cache Name Entity Name Type Index Name Status psycho_cachel admindb.dbo.def_actions table I (return status = 0)

Перезапуск сервера: размеры именованного буфера и его буферной области снова появляются в журнале регистрации ошибок 00:96/06/06 08:16:02.02 server Memory allocated for the default data cache cache: 12866 Kb 00:96/06/06 08:16:02.04 server Size of the 2K memory pool: 12866 Kb 00:96/06/06 08:16:02.04 server Memory allocated for the psycho_cachel cache: 10240 Kb 00:96/06/96 08:16:02.06 server Size of the 2K memory pool: 10240 Kb 00:96/06/06 08:16:02.06 kernel Initializing virtual device 0,

Снова проверим состояние именованных кэш буферов Обратите внимание: связям объекта с удаленным и затем вновь созданным именованным буфером возвращается действительный статус. Именно поэтому перед удалением буфера рекомендуется отме нить все связи объектов с этим буфером. В противном случае подобные связи могут случайно восста новиться впоследствии. 1> sp_helpcache 2> gо Cache Name Config Size Run Size Overhead default data cache 0.00 Mb 12.56 Mb 0.65 Mb psycho_cachel 10.00 Mb 10.00 Mb 0.53 Mb Memory Available For Memory Configured Named Caches To Named Caches 22.58 Mb 10.00 Mb There is 12.58 Mb of memory left over that will be allocated to the default cache 12.58 Мбайт незадействованной памяти будет распределено для кэш#буфера, используемого по умолчанию  Cache Binding Information  Cache Name Entity Name Type Index Name Status Psycho_cachel admindb.dbo.def_actions table V (return status = 0)

www.books-shop.com

Запись журнала регистрации ошибок характеризует связь как действительную 00:96/06/06 08:16:07.49 server Recovering database 'admindb'. 00:96/06/06 08:16:07.50 server Recovery dbid 4 ckpt (31287,2) 00:96/06/06 08:16:07.50 server Recovery no active transactions before ckpt. 00:96/06/06 08:16:08.80 server Cache binding for database '4' object '1280007591', index '0' is being marked valid in Sysattributes. 00:96/06/06 08:16:08.82 server The transaction log in the database 'admindb' will use I/O size of 2 Kb. 00:96/06/06 08:16:08.87 server Database 'admindb' is now online. Выдача команды sp_help для таблицы, связанной с именованным кэш буфером 1> select db_name() 2> go admindb (1 row affected) 1> sp_help def_actions 2> go Name Owner Type Def_actions dbo user table Data_located_on_segment When_created Default Jun 29 1994 8:13PM Column_name Type Length Prec path#key varchar NULL 20 Nulls Identity Default_name Rule_name NULL 0 NULL

Scale NULL

Column_name Type Prec Scale Length partner_code varchar NULL NULL 15 Nulls Default name Identity Rule name 1 NULL NULL 0 Attribute class attribute char value comments int_value buffer manager cache binding 1 psycho_cach NULL Index_name index_description Def_actions_idx clustered,unique located on default Index_keys index_max_rows_per_page Path_key,segnum 0 No defined keys for this object. Object is not partitioned. (1 row affected, return status = 0)

www.books-shop.com

Оптимизация запросов и диспетчер кэш+буфера System 11 Введение Возможности оптимизатора запросов System 11 значительно расширены по сравнению с предыдущи" ми версиями сервера. В частности, оптимизатор запросов System 11 способен взаимодействовать с диспетчером кэш"буфера и при оптимизации принимает во внимание существование больших блоков ввода"вывода. Оптимизатор запросов может быть также настроен на реализацию упреждающего счи" тывания с диска (prefetch) или считывания с немедленным удалением (fetch"and"discard). В подавляю" щем большинстве случаев установленные по умолчанию параметры новых режимов работы оптимизатора являются оптимальными, и возможность использования новых стратегий обработки запросов вовсе не означает, что оптимизатор обязательно прибегнет к ним. Упреждающее считывание в кэш+буфер Использование в System 11 больших блоков ввода"вывода приводит к тому, что оптимизатор запросов может выбрать стратегию упреждающего считывания данных (считывать в буфер больше данных, чем необходимо в данный момент (рис. 4.9)). Упреждающее считывание (prefetch) позволяет повы" сить производительность сервера, поскольку для большинства запросов очередная обрабатываемая страница данных обычно находится недалеко от предыдущей. При использовании больших блоков ввода"вывода в буфер одновременно считывается несколько последовательных страниц данных. Упреждающее считывание существенно сокращает число операций физического ввода"вывода, но то" лько при обработке достаточно кластеризованных массивов данных. Для некоторых запросов упреж" дающее чтение настолько повышает эффективность обработки, что вместо использования индекса оптимальной стратегией выполнения становится полный табличный просмотр. По умолчанию сер" вер сконфигурирован на реализацию упреждающего считывания, однако возможность практическо" го использования больших блоков ввода"вывода определяется наличием буферных областей с блоками подходящего размера. страница данных, реально необходимая серверу

16+килобайтный буферный блок именованный кэш+буфер

при упреждающем чтении в кэш+буфер одновременно загружается 8 страниц данных

Рис. 4.9. Стратегия упреждающего чтения Считывание в буфер с немедленным удалением Еще одна новая стратегия обработки запросов — считывание с немедленным удалением (fetch"and"dis" card, см. рис. 4.10). Считываемые страницы данных помещаются в LRU"конец буфера, где обычно на" ходятся наименее используемые страницы, и тем самым немедленно становятся непосредственными кандидатами на удаление из буфера. Подобная стратегия принципиально отличается от обычного LRU/MRU"алгоритма обработки страниц в буфере, когда только что прочитанные страницы оказы" ваются в начале буфера среди других страниц, недавно понадобившихся серверу, и до момента вы" грузки этих страниц из буфера они должны последовательно пройти сквозь весь буфер вплоть до LRU"конца (и тем самым вытеснить из буфера все ранее находившиеся там страницы). Считывание с немедленным удалением позволяет исключить вытеснение из буфера других страниц, что оказывает" ся весьма полезным при выборке информации из больших массивов данных, типичной для обработ" ки DSS"запросов. Таким образом, стратегия считывания с немедленным удалением является еще одним средством, позволяющим предотвратить вытеснение страниц OLTP"приложений при одно" временном выполнении DSS"приложений.

www.books-shop.com

точка очистки

новые страницы данных обычно загружаются в начало буфера

при

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

Рис. 4.10. Считывание с немедленным удалением

Оптимизация запросов и стратегия использования кэш+буфера При поиске наиболее эффективного (т.е. связанного с минимальным объемом физического ввода"вы" вода) пути выполнения запроса оптимизатор сравнивает два возможных подхода. Во"первых, оптими" затор запросов принимает во внимание подсказки (hints), предоставленные пользователем. Во"вторых, оптимизатор запросов сопоставляет стоимость различных стратегий использования кэш"буфера, выраженную в количестве операций физического и логического ввода вывода. Пользова" тельские подсказки позволяют влиять на применение больших блоков ввода"вывода, считывание с не" медленным удалением и соединения больших таблиц. Разнообразные подсказки могут даваться на уровне объекта, сеанса или отдельного запроса, причем подсказка объектного уровня отменяет под" сказку на уровне сеанса и т.д. Подробная информация об иерархии команд стратегии использования кэш"буфера и их синтаксисе содержится в документации сервера. Например, при обработке OLTP"запросов пользователь может запретить использование боль" ших блоков ввода"вывода на уровне соответствующих объектов базы данных, обеспечив считывание страниц этих объектов в буферные области с малой длиной блока. Стратегии опережающего чтения и чтения с немедленным удалением задаются с помощью команды sp_cachestrategy. Расширения фор" мата SQL"предложения select позволяют устанавливать желаемый объем опережающего считывания данных (размер блоков ввода"вывода) непосредственно для индивидуального запроса. Окончатель" ное решение, принятое оптимизатором на основании пользовательских подсказок и других сообра" жений, можно узнать с помощью команды showplan. При задании стратегии использования кэш"буфера с помощью подсказок необходимо иметь в ввиду, что каждое изменение подобной стратегии по отношению к данным таблицы или индекса приводит к автоматической перекомпиляции всех хранимых процедур, использующих эту таблицу или индекс. В процессе минимизации физического и логического ввода"вывода оптимизатор запросов прини" мает во внимание большое количество различных факторов. Самый важный из них — оптимизация физического ввода"вывода, которая обходится серверу намного дороже логического ввода"вывода. Оптимизатор принимает во внимание параметры таблиц данных, используемых каждым отдельным запросом, и именованных буферов, с которыми связаны эти таблицы. Затем оптимизатор определя" ет, имеет ли смысл использовать большие блоки ввода"вывода и проверяет наличие буферных облас" тей с подходящей длиной блока в соответствующих кэш"буферах. При обработке соединений больших таблиц сервер стремится сделать меньшую из этих таблиц внутренней таблицей соедине" ния и поместить ее в именованный кэш"буфер, а внешнюю таблицу большого размера (страницы ко" торой будут использоваться не так часто) обрабатывать с помощью стратегии считывания в буфер с немедленным удалением из буфера. При анализе запроса оптимизатор оценивает, какое количество записей данных будет возвраще" но этим запросом пользователю. При значительном количестве выбираемых записей оптимизатор стремится использовать большие блоки ввода"вывода. Для этого необходимо наличие в именован" ном кэш"буфере, назначенном таблице данных, буферной области с блоком подходящего размера. Если выбирается небольшое количество записей, сервер остановится на использовании стандарт" ной буферной области с 2"килобайтными страницами, чтобы минимизировать объем физического и логического ввода"вывода. Еще раз подчеркнем, что даже при выборе оптимизатором запросов ре" жима больших блоков ввода"вывода сервер не создаст необходимые буферные области

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

автоматически. Подобная операция должна быть выполнена администратором сервера до направле" ния запроса на сервер. В System 11 оптимизатор запросов может обрабатывать одновременные соединения до восьми таблиц (чаще всего подобные операции встречаются в DSS"приложениях). Предыдущие версии сер" вера поддерживали соединения максимум четырех таблиц. В System 11 также появился ряд новых флагов трассировки, позволяющих проследить за деталя" ми процесса оптимизации запросов. Использование этих флагов во время разработки приложений позволяет тщательно проконтролировать процесс оптимизации создаваемых запросов и внести в эти запросы необходимые изменения. Мы рекомендуем читателю ознакомиться с описанием в сис" темной документации сервера флагов трассировки 302 и 310. Стратегии использования кэш*буфера — теория и практика Администратор System 11 способен почти бесконечно усложнять конфигурацию сервера, выбирая все более запутанные стратегии работы с кэш"буферами. Здесь чрезвычайная гибкость System 11 ста" новится источником реальной опасности. В процессе оптимизации сервера достаточно легко прийти к настолько громоздкой структуре именованных буферов, буферных областей, связей объектов дан" ных с буферами и стратегий использования буферов, что ни один нормальный администратор базы данных не сможет в ней разобраться. Выгода от любого усложнения конфигурации сервера обязате" льно должна оправдывать потенциальные негативные последствия. Лучше всего не торопиться и придерживаться максимальной простоты. Не пытайтесь совместить в одном сервере OLTP" и DSS"си" стемы, поскольку подобный подход непродуктивен и в итоге окажется намного дороже разделения несовместимых приложений на отдельные серверы. Попытки одновременно реализовать несколько принципиально различных стратегий использования кэш"буферов лишь отложат полноценное реше" ние проблемы несовместимости структур данных и методов обработки запросов. Разумеется, сложные методы настройки процесса выполнения запросов позволяют до+ биться хороших результатов при сравнительном тестировании серверов разных фирм. Но так ли все это необходимо на реальном сервере, от стабильного функционирования которого зависит работа множества пользователей? Несмотря на богатый выбор новых возможностей, в конфигурацию большинства реальных сис" тем лучше всего не вносить излишние изменения, воспользовавшись устанавливаемыми по умолча" нию значениями параметров конфигурации. Обилие режимов настройки производительности вовсе не означает, что вы немедленно должны все их перепробовать. Наоборот, использование любого нового способа оптимизации сервера должно быть тщательно подготовлено. Обязательно восполь" зуйтесь командой showplan до и после внесения изменений в конфигурацию и убедитесь, что внесен" ные изменения действительно способствовали улучшению работы сервера. Другие методы улучшения оптимизации запросов Последняя версия сервера Sybase содержит многочисленные нововведения в области оптимизации запросов сервером, и в особенности оптимизации подзапросов. Подробное обсуждение всех вне" сенных в оптимизатор запросов изменений может занять отдельную книгу, поэтому мы отсылаем читателя к публикации Sybase "Новое в SQL Server 11" ("What's New in SQL Server 11?"). После пере" хода на новую версию сервера необходимо проанализировать все изменения в оптимизации запро" сов и определить, насколько эти изменения сказываются на реальных запросах, обрабатываемых вашим сервером. В частности, как мы уже отмечали выше, после перехода на сервер System 11 следует обязатель" но учитывать существование новой схемы обработки подзапросов. Для ее использования необхо" димо удалить и затем воссоздать заново все хранимые процедуры, триггеры и представления данных, содержащие вложенные запросы. Более подробное обсуждение этой проблемы читатель найдет в главе 13.

www.books-shop.com

Глава 5

Настройка конфигурации SOL Server Sustem 11

www.books-shop.com

По сравнению с предшествующими версиями SQL Server System 11 имеет намного больше пара" метров конфигурации — 120 по сравнению с прежними 30. Разумеется, это обеспечивает админист" ратору сервера большую гибкость в настройке сервера на выполнение конкретных задач. С другой стороны, обилие параметров настройки затрудняет анализ и документирование особенностей реаль" ных конфигураций сервера, а также контроль за их работой. Решить эту проблему в некоторой сте" пени помогает специальный конфигурационный файл со значениями всех параметров конфигурации. Он появился только в составе рассматриваемой версии сервера. Помимо конфигура" ционного файла, сервер System 11 также поддерживает режим конфигурации с помощью системной хранимой процедуры sp_conf igure, известной по предыдущим версиям. Процедура sp_conf igu" ге позволяет модифицировать значения отдельных параметров конфигурации, в то время как кон" фигурационный файл дает возможность вносить и документировать изменения в целых группах параметров. В главе 11 "Установка параметров конфигурации" Руководства системного администратора Sybase SQL Server (Sybase SQL Server System Administration Guide) приводится весьма полезная таблица, содержа" щая полный список конфигурационных параметров System 11 вместе с названиями аналогичных па" раметров предыдущих версий сервера Sybase. Конфигурационный файл Конфигурационный файл содержит значения всех параметров конфигурации сервера, объединен" ных по группам в соответствии с ролью, выполняемой тем или иным параметром. Некоторые пара" метры могут фигурировать одновременно в нескольких группах конфигурационного файла. После изменения указанных в конфигурационном файле значений параметров для активизации новых зна" чений требуется перезапуск сервера. Конфигурация сервера, помимо конфигурационного файла, по"прежнему сохраняется в систем" ных таблицах sysconfigures и syscurconfigs базы данных master, а также в конфигурационном блоке глав" ного серверного устройства master. Значения параметров конфигурационного файла определяют объем ресурсов серверного компь" ютера, распределяемых серверу при его запуске. Имя необходимого конфигурационного файла мож" но явно указать при запуске сервера с помощью нового параметра "с команды dataserver, запускающей двоичный выполняемый модуль сервера. При отсутствии в командной строке имени конфигурационного файла сервер ищет в каталоге, задаваемом переменной среды SYBASE, файл с именем вида <имя_сервера>.сfg. При неправильной установке переменной SYBASE возможны си" туации, когда либо серверу не удастся найти необходимый файл, либо сервер может случайно про" читать конфигурационный файл предыдущей версии System 11 (System 11.0 вместо System 11.0.1) и оказаться в нештатной конфигурации. Полное имя конфигурационного файла, использованного при запуске сервера, всегда выдается в журнал регистрации ошибок; при невозможности найти по" добный файл сервер запускается со всеми значениями параметров, установленными по умолчанию. В предыдущих версиях SQL Server для сброса текущей конфигурации требовалось выполнить коман" ду buildmaster"r. Как правило, это делалось при случайном внесении изменений, препятствую" щих запуску сервера (например, из"за нехватки памяти на серверной машине). В System 11 сброс недопустимой конфигурации сервера осуществляется простым переименованием файла <имя_сер sepa>.cfg и перезапуском сервера без указания имени конфигурационного файла. Возможность использования нескольких конфигурационных файлов позволяет администратору сервера быстро настраивать его конфигурацию на решение различных задач, таких, например, как переход в конце рабочего дня от обслуживания OLTP"системы к выполнению больших пакетных за" дач в ночное время. Аналогичная реконфигурация сервера потребуется и в выходные дни перед на" чалом обычных операций по поддержанию работоспособности сервера. Переход от одного конфигурационного файла к другому осуществляется путем простого перезапуска сервера. Подобно предыдущим версиям, сервер System 11 имеет статические и динамические конфигура" ционные параметры. Изменения, внесенные в статические параметры, не активизируются до пере" запуска сервера, в то время как динамические параметры сервера могут устанавливаться прямо в процессе его работы. Существует несколько способов изменения параметров. Во"первых, любой па" раметр конфигурации модифицируется с помощью процедуры sp_conf igure (при этом изменения в статических параметрах будут активизированы только после перезапуска сервера). Во"вторых, из" менения можно вносить непосредственно в конфигурационный файл с последующим перезапуском сервера. Наконец, процедура sp_conf igure позволяет прочитать конфигурационный файл прямо во время работы сервера при условии, что в новом файле не содержится новых значений статиче" ских параметров.

www.books-shop.com

Конфигурационный файл представляет собой простой текстовый ASCII"файл, ничем не отличаю" щийся от других файлов из файловой структуры операционной системы. Он не является структур" ной составной частью сервера, и его содержимое не архивируется при создании дампа какой"либо базы данных сервера. Для построения запасных копий конфигурационного файла используются стандартные средства архивации операционной системы. Как отмечалось выше, сервер сохраняет копию своей текущей конфигурации в системной базе данных master (таким образом, эта копия авто" матически резервируется при создании дампа базы данных master). Однако сохранение копий всех имеющихся конфигурационных файлов, призванных ускорить реконфигурацию сервера между раз" личными режимами работы, возможно только средствами операционной системы. При каждом успешном запуске сервера его текущая конфигурация записывается в файл с именем <имя_cepвepa>.bak на тот случай, если остальные файлы окажутся утраченными. Кроме того, по" добная копия файла окажется полезной при внесении в конфигурацию изменений, препятствующих запуску сервера, поскольку она всегда содержит конфигурацию сервера при последнем успешном за" пуске. Здесь необходимо иметь в виду, что файл <имя_сервера>.bak. модифицируется только в мо" мент запуска сервера. До следующего перезапуска сервера в этом файле не отражаются изменения, сделанные во время работы сервера с помощью процедуры sp_conf igure. Рассмотрим подробнее последовательность обработки конфигурационных параметров в про" цессе запуска сервера. Сразу после запуска сервер вызывает значения конфигурационных парамет" ров (config values), установленные перед его остановом, и использует их в качестве фактических значений параметров (run values). После успешного запуска сервер записывает в файл <имя_сер Bepa>.bak текущие значения параметров (соответствующие моменту останова сервера), после чего читает указанный в командной строке конфигурационный файл либо файл <имя_сервера>.сfg, найденный в каталоге, определенном переменной SYBASE (рис. 5.3). Наконец, сервер принимает считанные из этого файла значения параметров в качестве установленных (config) и фактических (run) значений параметров конфигурации. При каждом изменении конфигурации посредством процедуры sp_conf igure сервер автома" тически сохраняет новую версию конфигурационного файла, название которой всегда выглядит как <имя_сервера>.сfg. При этом предыдущая версия файла переименовывается в <имя_сер вера>.ХХХ, где число XXX на единицу больше номера последней предыдущей версии конфигураци" онного файла (рис. 5.1). Первый такой файл имеет номер 001; номера следующих файлов увеличиваются вплоть до 999, после чего прежний файл <имя_сервера>.001 окажется переписан" ным очередным файлом последовательности. Таким образом, администратор сервера должен сле" дить за тем, чтобы в файловой структуре, используемой для хранения конфигурационных файлов, всегда оставалось свободное место. Кроме того (даже если у вас вряд ли накопится 1000 прежних версий конфигурационного файла), помните о возможности случайной перезаписи файла <имя_сервера>.001, когда номера файлов последовательности достигнут 999. Имейте в виду еще одну особенность работы с конфигурационными файлами. Хотя сервер всегда записывает новый конфигурационный файл при внесении изменений командой sp_configure, при ручном редактировании файла его прежняя версия утрачивается. Именно здесь на помощь при" ходит файл <имя_сервера>.bak, содержащий последнюю успешно запущенную конфигурацию. Если в командной строке запуска сервера отсутствует имя конфигурационного файла, сервер ищет файл с именем <имя_сервера>.сfg, находящийся в каталоге, заданном переменной среды

Рис. 5.1. Конфигурационные файлы System 11

www.books-shop.com

SYBASE. При отсутствии подобного файла сервер запускается со значениями параметров, устанав" ливаемыми по умолчанию (рис. 5.2). В подобной ситуации сервер не создает файла <имя_серве pa>.bak, и после запуска администратор сервера с помощью процедуры sp_configure может записать на диск новый конфигурационный файл со всеми реально существующими параметрами последней успешной конфигурации. Следует, однако, проявлять осторожность. Предположим, что из"за недоступности конфигурационного файла сервер стартовал с конфигурацией по умолчанию, после чего вы изменили значение какого"то параметра командой sp_conf igure. При этом сервер автоматически записал конфигурационный файл, который при отсутствии дополнительных дейст" вий с вашей стороны будет использоваться во всех последующих запусках. В результате случайное создание подобного файла (в котором лишь один параметр будет отличаться от устанавливаемых по умолчанию значений) приведет к полной утрате информации о прежней конфигурации сервера, в том числе копии этой информации, хранившейся в системной базе данных master. Таким образом, при отсутствии конфигурационного файла копию текущих установок параметров следует записы" вать на диск немедленно после запуска сервера, не внося в его конфигурацию никаких изменений.

PSYCH011 Рис. 5.2. Запуск сервера без конфигурационного файла

PSYCH011.cfg

PSYCH011 .cfg (найден на диске) PSYCH011.032 (явно указан в командной строке) Рис. 5.3. Запасная копия конфигурационного файла Телефонный звонок. "Я просто перезапустил сервер, и он тут же забыл всю свою конфи+ гурацию", — в голосе на другом конце линии звучит нескрываемая паника. "Вы меняли что+либо в системе?" — "Ни в коем случае! Мы всего лишь запустили сервер с другим именем. Неужели это имеет значение?" Имеет! Пока сервер назывался PSYCHO_KNOWS, все было в порядке, но стоило перезапустить сервер под именем NEW_NAME (указав его в параметре +s команды startserver), как тому потребовался конфигурационный файл с другим именем — NEW_NAME.cfg, которого на диске, естественно, не оказалось. В ре+ зультате сервер запустился со всеми параметрами по умолчанию. Перед тем как переименовать сервер или перенести его на другую серверную машину под новым именем, скопируйте нужную вам версию конфигурационного файла в файл с новым име+ нем (в нашем примере NEW_NAME.cfg) либо явно укажите прежнюю версию при первом запуске нового сервера. Преимущества использования конфигурационных файлов Возможность запуска сервера с различными конфигурационными файлами позволяет быстро и эф" фективно выполнить реконфигурацию сервера, не прибегая к написанию специальных командных файлов, изменяющих значения необходимых конфигурационных параметров.

www.books-shop.com

Реконфигурация сервера часто бывает вызвана необходимостью обеспечения различных конф" ликтующих друг с другом задач. К примеру, все рабочие дни сервер может поддерживать работу OLTP"системы, в то время как по выходным его используют для составления итоговых отчетов по накопленным за неделю новым данным. Кроме того, выполнение обычных операций поддержания работоспособности сервера (напри" мер, dbcc"проверок) значительно ускоряется, когда сервер специально оптимизирован для осуществ" ления таких операций. В System 11 разница особенно заметна благодаря поддержке именованных буферов и другим нововведениям. Например, реконфигурация сервера позволит распределить боль" ше оперативной памяти сервера именованному кэш"буферу, содержащему буферную область с 16"Кбайт блоками. Это хороший пример того, как объединение различных изменений конфигура" ции в общий конфигурационный файл помогает решить проблемы, связанные со значительным усложнением настройки сервера в System 11. Создание "стандартного" конфигурационного файла, который использовался бы всеми сервера" ми вашей информационной системы, значительно упрощает установку и конфигурацию большого числа серверов. Благодаря распространению стандартного конфигурационного файла на все удален" ные системы персонал этих систем получает проверенную и документированную конфигурацию. При последующих проверках работы удаленных серверов вы без особого труда убедитесь в правиль" ности установленной конфигурации и обнаружите изменения, внесенные персоналом удаленных си" стем. Конфигурационные файлы намного упрощают исправление ошибок, допущенных при настройке сервера. В предыдущих версиях сервера администратору приходилось командой sp_conf igure ме" нять значение каждого параметра в отдельности. Если задавалось недопустимое значение (напри" мер, чрезмерно большой размер области памяти серверной машины, выделяемой серверу), сервер переставал запускаться. Единственный выход в данном случае — удаление содержимого конфигура" ционного блока серверного устройства master командой buildmaster "r, устанавливавшей значе" ния всех параметров конфигурации по умолчанию. Затем в полученную по умолчанию конфигурацию с помощью команды sp_conf igure приходилось по одному вносить все необходи" мые изменения. С появлением System 11 для восстановления последней успешной конфигурации до" статочно перезапустить сервер с самой свежей запасной копией конфигурационного файла. Конфигурационные файлы и восстановление сервера после сбоев В SQL Server System 11 конфигурационные файлы стали неотъемлемой частью стратегии резервиро" вания и восстановления данных. Хотя при каждом изменении конфигурации сервер автоматически создает копию конфигурационного файла, администратору сервера все же следует побеспокоиться о регулярной архивации этих файлов. В предыдущих версиях восстановление конфигурации сервера сводилось к восстановлению базы данных master. Однако System 11 позволяет поддерживать несколь" ко конфигурационных файлов для различных режимов работы, и невозможность восстановить все подобные файлы означает неполное восстановление всего сервера (см. главу 9). О конфигурационных файлах также не следует забывать при переносе сервера с одного компью" тера на другой. Эти файлы должны быть скопированы на новую систему вместе с дампами переноси" мых баз данных. Использование конфигурационных файлов Поскольку конфигурационные файлы представляют собой обычные текстовые файлы операционной системы, они могут быть прочитаны и изменены каждым пользователем этой системы, имеющим до" статочные полномочия. Поэтому администратору сервера следует заранее побеспокоиться о том, чтобы с помощью стандартных средств безопасности операционной системы ограничить доступ по" льзователей к файлам. Еще раз подчеркнем, что сервер не контролирует доступ к конфигурационным файлам на уровне операционной системы. Работоспособность сервера существенно зависит от ресурсов серверной машины, вследствие чего конфигурационный файл, нормально работающий на одной машине, вовсе не гарантирует успешный запуск сервера на другой. При создании стандартного конфигурационного файла, пред" назначенного для использования множеством серверов, убедитесь, что все серверные машины спо" собны поддерживать стандартную конфигурацию, предусмотренную подобным файлом. Кроме того, даже на одном и том же серверном компьютере изменения в аппаратном и программном обеспече" нии (например, уменьшение объема доступной памяти из"за появления новых системных

www.books-shop.com

процессов) также могут привести к невозможности запуска сервера в конфигурации, вполне работо способной ранее. Конфигурационные файлы и именованные кэш*буферы Создание именованных буферов или модификация их параметров — это изменения в конфигурации сервера. Структура именованных буферов сервера записывается в его конфигурационном файле, в результате чего создание новых именованных буферов и буферных областей приводит к увеличению размера конфигурационного файла. Структура конфигурационного файла Поскольку для всех параметров, сохранивших установки по умолчанию, в конфигурационном файле указывается значение DEFAULT, их фактические значения можно узнать только с помощью команды sp_conf igure. После установки сервера каждый параметр конфигурации имеет значение DEFAULT. К аналогичному результату приводит запуск сервера без доступного конфигурационного файла при последующем сохранении текущих фактических значений параметров настройки в новом файле. Ниже приводится распечатка типичного конфигурационного файла SQL Server. (Отметим, что при сохранении этого файла лишь значение максимально допустимого числа пользовательских сеансов (number of user connections) отличалось от устанавливаемого по умолчанию.) # #

# # # # # # # # # # #

Configuration File for the Sybase SQL Server Please read the System Administration Guide (SAG) before changing any of the values in this file. Конфигурационный файл для Sybase SQL Server Перед внесением изменений в значения параметров рекомендуем ознакомиться с руководством системного администратора.

[Configuration Options] [General Information] [Backup/Recovery] recovery interval in minutes = DEFAULT print recovery information = DEFAULT tape retention in days = DEFAULT [Cache Manager] number of oam trips = DEFAULT number of index trips = DEFAULT procedure cache percent = DEFAULT memory alignment boundary = DEFAULT [Named Cache:default data cache] cache size = DEFAULT cache status = default data cache [Disk I/O] allow sql server async i/o = DEFAULT disk i/o structures = DEFAULT page utilization percent = DEFAULT number of devices = DEFAULT [Network Communication] default network packet size = DEFAULT max network packet size = DEFAULT remote server pre#read packets = DEFAULT number of remote connections = DEFAULT allow remote access = DEFAULT

www.books-shop.com

number of remote logins = DEFAULT number of remote sites = DEFAULT max number network listeners = DEFAULT tcp no delay = DEFAULT

[O/S Resources] max async i/os per engine = DEFAULT max async i/os per server = DEFAULT [Physical Resources] [Physical Memory] total memory = DEFAULT additional network memory = DEFAULT lock shared memory = DEFAULT shared memory starting address = DEFAULT [Processors] max online engines = DEFAULT min online engines = DEFAULT [SQL Server Administration] number of open objects = DEFAULT number of open databases = DEFAULT audit queue size = DEFAULT default database size = DEFAULT identity burning set factor = DEFAULT allow nested triggers = DEFAULT allow updates to system tables = DEFAULT print deadlock information = DEFAULT default fill factor percent = DEFAULT number of mailboxes = DEFAULT number of messages = DEFAULT number of alarms = DEFAULT number of pre#allocated extents = DEFAULT event buffers per engine = DEFAULT cpu accounting flush interval = DEFAULT i/o accounting flush interval = DEFAULT sql server clock tick length = DEFAULT runnable process search count = DEFAULT i/o polling process count = DEFAULT time slice = DEFAULT deadlock retries = DEFAULT cpu grace time = DEFAULT number of sort buffers = DEFAULT sort page count = DEFAULT number of extent i/o buffers = DEFAULT size of auto identity column = DEFAULT identity grab size = DEFAULT lock promotion HWM = DEFAULT lock promotion LWM = DEFAULT lock promotion PCT = DEFAULT housekeeper free write percent = DEFAULT partition groups = DEFAULT partition spinlock ratio = DEFAULT [User Environment] number of user connections = 200 stack size = DEFAULT stack guard size = DEFAULT systemwide password expiration = DEFAULT permission cache entries = DEFAULT user log cache size = DEFAULT

www.books-shop.com

user log cache spinlock ratio = DEFAULT [Lock Manager] number of locks = DEFAULT deadlock checking period = DEFAULT freelock transfer block size = DEFAULT

max engine freelocks = DEFAULT address lock spinlock ratio = DEFAULT page lock spinlock ratio = DEFAULT table lock spinlock ratio = DEFAULT Сервер предъявляет довольно жесткие требования к формату конфигурационного файла, поэто" му при его редактировании в качестве образца лучше взять один из файлов, сгенерированных серве" ром. Во время установки сервер создает несколько конфигурационных файлов, самому последнему из которых присваивается имя <имя_сервера>.сfg, а всем остальным — <имя_сервера>.ХХХ. Если сервер все же сообщит об ошибках в формате Конфигурационного файла, сравните используе" мый файл с одним из файлов, записанных сервером. Можно выделить следующие основные требо" вания к формату конфигурационного файла. Первая строка такого файла должна быть стандартным комментарием в формате UNIX, т.е. на" чинаться с символа "#". Каждый раздел конфигурационного файла состоит из заголовка, имеющего вид [имя_раздела], за ним перечисляются значения параметров, входящих в данный раздел, и следу" ет как минимум одна пустая строка, обозначающая конец раздела. Некоторые разделы вообще не со" держат никаких параметров. Конфигурационный файл обязательно включает в себя раздел, определяющий общий кэш"буфер данных; кроме того, существует и ряд других ограничений. К при" меру, при добавлении в файл описания нового именованного кэш"буфера необходимо указать не то" лько его размер, но и положение точки очистки (wash size). Минимальный конфигурационный файл, успешно читаемый сервером (но, разумеется, не изменяющий никаких значений параметров), имеет следующий вид: # [Named Cache:default data cache] cache size = DEFAULT cache status = default data cache Приведем еще один пример конфигурационного файла, создающего новый именованный кэш"бу" фер с нестандартной буферной областью. Поскольку создание или модификация именованных кэш"буферов является изменением статических конфигурационных параметров сервера, подобный файл может быть прочитан сервером только при его перезапуске. # [Named Cache:default data cache] cache size = DEFAULT cache status = default data cache [Named Cache:psychol_cache] cache size = 2M

cache status = mixed cache [16K I/O Buffer Pool] pool size = 1M wash size = DEFAULT Сообщения об ошибках в конфигурационном файле при запуске сервера При изменении конфигурации сервера посредством редактирования конфигурационного файла с по" следующим перезапуском сервера внимательно просмотрите все значения параметров, указанные в файле, чтобы случайно не внести в конфигурацию сервера неконтролируемые изменения. Если для регулярного реконфигурирования сервера применяются несколько конфигурационных файлов, они должны иметь содержательные и однозначно интерпретируемые названия, отличные от стандартного <имя_сервера>.сfg. Поскольку название конфигурационного файла, прочитанно" го при запуске сервера, всегда выводится в журнал регистрации ошибок, использование индивидуа" льных имен конфигурационных файлов позволит впоследствии легко установить, в какой конфигурации был запущен сервер. Состав же стандартного файла <имя_сервера>.сfg подвержен

www.books-shop.com

частым изменениям, поскольку такой файл автоматически записывается при каждом интерактивном изменении конфигурации сервера командой sp_conf igure либо при создании/модификации име нованных кэшбуферов. Необходимо отметить, что при запуске сервера с указанием нестандартного имени конфигураци онного файла автоматическое сохранение конфигурации будет производиться в файл с указанным именем. Если, например, сервер был запущен с конфигурационным файлом WEEKDAY_conf ig.cfg, то при каждом интерактивном изменении параметров конфигурации или при создании/модифика ции именованных кэшбуферов сервер сохранит новую конфигурацию в файле WEEKDAY_con" f ig.cfg, переименовав прежнюю версию файла в WEEKDAY_config.XXX. Таким образом, вместо нескольких конфигурационных файлов получается несколько последовательностей таких файлов. При запуске сервера без указания имени конфигурационного файла либо при явном указании имени вида <имя_сервера>.сfg сервер будет придерживаться стандартной последовательности конфигу рационных файлов с именами <имя_сервера>.ХХХ. В то же время явное задание нестандартного имени файла конфигурации приведет к переключению на другую последовательность конфигураци онных файлов. Как и в предыдущих версиях сервера, наиболее распространенной причиной неуспешного запус ка сервера является задание значений параметров конфигурации, находящихся вне допустимого диапазона либо не реализуемых на данной серверной машине. Кроме того, сервер не запускается при наличии ошибок в формате конфигурационного файла, рассмотренном в предыдущем разделе. Приведем примеры типичных ошибок в конфигурационном файле и соответствующих сообщений сервера. При этом будем последовательно устранять много численные ошибки, содержащиеся в исходном варианте конфигурационного файла. 1а. В конфигурационном файле отсутствует описание общего кэшбуфера. Обратите внима ние на строку комментария, с которой должен начинаться любой конфигурационный файл сервера. # [Named Cache: psychol_cache] cache size = 2M cache status = mixed cache [16K I/O Buffer Pool] pool size = 2M 16. Соответствующее сообщение об ошибке. 0 0 : 9 6 / 0 5 / 2 2 1 0 : 2 0 : 2 9 . 3 5 kernel Configuration Error: A named cache with 'cache status=default data cache.' does not exist in the configuration f i l e . 00:96/05/22 10:20:29.35 kernel Ошибка в конфигурации: в конфигурационном файле отсутствует описание именованного кэш"буфера, имеющего статус 'cache status=default data cache ' . 2a. В файле отсутствует пустая строка после описания параметра 'cache status = mixed cache'. # [Named Cache: default data cache] cache size = DEFAULT cache status = default data cache [Named Cache: psychol_cache] cache size = 2M cache status = mixed cache [16K I/O Buffer Pool] pool size = 2M 26. Соответствующее сообщение об ошибке. 00:96/05/22 10:02:18.09 server Number of proc buffers allocated: 1869. 00:96/05/22 10:02:18.14 kernel Configuration Error: Configuration file ' /home/sybase/11.0.1/THEBIRDSll_test2 ' has an unknown format on line 38. (lack of a blank line) 00:96/05/22 10:02:18.14 kernel Ошибка в конфигурации: недопустимый формат строки 38 конфигурационного файла '/home/sybase/11.0.1/THEBIRDSll_test2' .

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

(отсутствует пустая строка) За. При описании буферной области необходимо указать не только ее размер, но и положение точки очистки. # [Named Cache:default data cache] cache size = DEFAULT cache status = default data cache [Named Cache:psychol_cache] cache size = 2M cache status = mixed cache [16K I/O Buffer Pool] pool size = 2M 36. Соответствующее сообщение об ошибке. 0 0 : 9 6 / 0 5 / 2 2 10:00:44.18 kernel Network and device connection limit is 1014. 0 0 : 9 6 / 0 5 / 2 2 1 0 : 0 0 : 4 4 . 2 0 server Number of proc buffers allocated: 1869. 0 0 : 9 6 / 0 5 / 2 2 1 0 : 0 0 : 4 4 . 2 5 kernel Configuration Error: Configuration f i l e '/home/sybase/11.0.1/THEBIRDSll_test2' has an unknown format on line 37. 0 0 : 9 6 / 0 5 / 2 2 1 0 : 0 0 : 4 4 . 2 5 kernel Ошибка в конфигурации: недопустимый формат строки 37 конфигурационного файла '/home/sybase/11.О.l/THEBIRDSll_test2'. 4а. В именованном кэшбуфере недостаточно пространства для буферной области со стандартным размером блока. Указанная в конфигурационном файле буферная область с 16Кбайт блоками целиком занимает пространство кэшбуфера, в то время как в любом кэшбуфере минимум 512 Кбайт должно быть рас пределено стандартной буферной области с блоками по 2 Кбайт (см. главу 4). # [Named Cache:default data cache] cache size = DEFAULT cache status = default data cache [Named Cache:psychol_cache] cache size = 2M cache status = mixed cache [16K I/O Buffer Pool] pool size = 2M wash size = DEFAULT 46. Соответствующее сообщение об ошибке. 00:96/05/22 10:03:22.48 kernel Network and device connection limit is 1014. 00:96/05/22 10:03:22.49 server Number of proc buffers allocated: 1869. 00:96/05/22 10:03:22.55 kernel Invalid pool size of Ok (0 buffers) encountered for the 2k pool in cache psychol_cache. Buffer pools must have a minimum total size of 512k or 25 buffers, whichever is greater. 00:96/05/22 10:03:22.55 kernel В кэш#буфере psychol_cache буферная область с блоками по 2 Кбайт имеет недопустимый размер в 0 Кбайт (0 буферных блоков). Размер буферной области должен быть достаточным для размещения по крайней мере 25 буферных блоков и не может составлять менее 512 Кбайт. 5. Наконец все ошибки в конфигурационном файле исправлены и сервер успешно запущен. # [Named Cache:default data cache] cache size = DEFAULT cache status = default data cache [Named Cache:psychol_cache] cache size = 2M

www.books-shop.com

cache status = mixed cache [16K I/O Buffer Pool] pool size = 1M wash size = DEFAULT Процедура SP_CONFIGURE Системная хранимая процедура sp_configure позволяет просматривать, документировать, изме нять и восстанавливать конфигурацию сервера. Для одновременного изменения значений несколь ких параметров конфигурации и документирования текущей конфигурации сервера процедура sp_conf igure используется совместно с конфигурационным файлом. Использование sp_configure в предыдущих версиях сервера В предыдущих версиях SQL Server процедура sp_conf igure применялась исключительно для изме" нения значений каждого из 30 имевшихся параметров конфигурации в отдельности. Некоторые до" полнительные параметры настройки устанавливались с помощью команд buildmaster и dbcc, что заметно усложняло и замедляло процесс реконфигурирования сервера. Вызов процедуры sp_conf i" gure без указания параметров приводил к выводу списка текущих значений конфигурационных па" раметров. Кроме того, значения дополнительных редко используемых параметров настройки распечатывались командой buildmaster "yall. Вывод команды sp_configure в SQL Server версии 4.9.2 1> sp_configure 2> go Name minimum maximum run_value config_value 1 recovery interval 1 32767 1 1 allow updates 0 1 1 2147483647 100 user connections 5 100 2147483647 Memory 3850 8192 8192 2147483647 open databases 5 0 10 2147483647 Locks 5000 0 5000 2147483647 open objects 100 0 500 procedure cache 1 0 99 20 fill factor 0 0 100 0 time slice 50 0 1000 100 database size 2 10000 0 2 tape retention 0 0 0 365 recovery flags 0 1 0 0 serial number 1 999999 999999 999999 nested triggers 0 1 1 1 Devices 4 256 0 10 remote access 0 1 1 1 remote logins 0 2147483647 0 20 remote sites 0 2147483647 0 10 0 remote connections 0 2147483647 20 pre#read packets 0 2147483647 3 0 upgrade version 0 2147483647 492 492 default sortorder id 0 50 50 255 default language 0 2147483647 0 0 language in cache 3 3 3 100 1 1 max online engines 1 32 1 1 32 min online engines 1 engine adjust interval 1 32 0 0 default character set id 0 1 1 255 2147483647 28672 stack size 20480 0 (30 rows affected, return status = 0)

www.books-shop.com

Вывод команды sp_configure в SQL Server System 10 1> sp_configure 2> go run_value config_value Name minimum maximum 32767 0 5 recovery interval 1 0 1 0 allow updates 0 2147483647 0 25 user connections 5 20000 2147483647 20000 Memory 3850 2147483647 12 0 open databases 5 2147483647 5000 0 Locks 5000 2147483647 500 0 open objects 100 0 20 99 procedure cache 1 0 0 100 fill factor 0 100 1000 0 time slice 50 2 0 10000 database size 2 0 0 tape retention 0 365 1 0 0 recovery flags 0 1 1 1 nested triggers 0 0 10 256 Devices 4 1 1 1 remote access 0 2147483647 20 0 remote logins 0 2147483647 10 0 remote sites 0 2147483647 0 20 remote connections 0 2147483647 3 0 pre#read packets 0 2147483647 1002 1002 upgrade version 0 50 50 default sortorder id 0 255 2147483647 0 0 default language 0 3 language in cache 3 100 3 1 32 1 max online engines 1 1 1 min online engines 1 32 engine adjust interval 1 0 0 32 2147483647 200 cpu flush 1 200 2147483647 i/o flush 1 1000 1000 1 1 default character set id 0 255 28672 2147483647 stack size 20480 0 0 password expiration interval 0 32767 0 100 100 audit queue size 1 65535 0 2147483647 additional netmem 0 0 default network packet size 512 512 524288 0 maximum network packet size 512 512 0 524288 2147483647 0 extent i/o buffers 0 0 identity burning set factor 1 5000 5000 9999999 (38 rows affected, return status = 0) Каждый конфигурационный параметр, распечатываемый командой sp_configure, является либо статическим, либо динамическим. Значения динамических параметров становятся активными сразу же после их изменения, в то время как активизация новых значений статических параметров требует перезапуска сервера. Характерными примерами статических параметров настройки SQL Server 4.9.2 и System 10 служат параметры memory (оперативная память) и user connections (количество сеансов пользователей). В прежних версиях сервера вывод команды sp_conf igure представлял собой столбцы, содержа" щие для каждого параметра настройки минимальный и максимальный пределы его допустимых зна" чений, а также установленное (config_value) и фактическое (run_value) значения. При изменении значения параметра командой sp_configure новое значение приобретает статус установленного (config). Затем фактическое значение динамических параметров настройки немедленно приводится в соответствие с установленным, в то время как для статических параметров это возможно только после перезапуска сервера. Выдаваемые командой sp_conf igure фактические значения как стати" ческих, так и динамических параметров во всех случаях отражают их значения, используемые серве" ром в данный момент.

www.books-shop.com

Необходимые полномочия В SQL Server 4.9.2 только привилегированный пользователь 'sa' обладал полномочиями на изменение параметров настройки. В System 10 изменять эти значения разрешалось уже любому пользователю сервера, имеющему роль sa_role. А в System 11 роль sa_role позволяет изменять значения практи" чески всех параметров, за исключением нескольких, для модификации которых необходима роль sso_role. Формат команды sp_configure В System 11 процедура sp_conf igure пополнилась новыми параметрами, обеспечивающими работу с конфигурационными файлами сервера. По вызову sp_conf igure без параметров 1> sp_configure 2> go появляется полный список значений параметров настройки, используемых сервером в данный мо" мент. Аналогичную информацию можно получить из текущего конфигурационного файла с именем $SYBASЕ/<имя_сервера>.сfg, содержащего текущую конфигурацию (если сервер уже запущен) либо конфигурацию сервера после его запуска. Команда sp_conf igure <имя_параметра> выдает информацию только об одном указанном в ней параметре настройки: 1> sp_configure 'total memory' 2> go Наконец, при вызове sp_conf igure можно привести название одного из разделов конфигураци" онного файла, в результате чего будет выдана информация обо всей группе параметров этого разде" ла (пример см. ниже). Имя конфигурационного файла указывается при вызове процедуры sp_conf igure следующим образом: sp.configure 'configuration file', 0, 'название.подкоманды', 'имя_конфигурационно* го_файла' Подчеркнем, что имя конфигурационного файла выводится в качестве последнего параметра, в то время как первый параметр в подобной ситуации всегда имеет значение 'configuration file' и сообщает процедуре о необходимости выполнить обращение к конфигурационному файлу. Значение второго параметра должно равняться 0; его указывают для совместимости с форматом обычных команд sp_conf igure (где второй параметр содержит присваиваемое значение). Третий параметр может со" держать название одной из четырех рассматриваемых ниже подкоманд: write (записать), restore (вос" становить), read (прочитать) и verify (проверить). Четвертый параметр включает имя файла, который необходимо использовать (подкоманды read и verify) или записать (подкоманды write и restore). В принципе, команда sp_configure 'configuration file' призвана сообщать имя текущего конфигурационного файла, используемого сервером. Однако на практике она выдает лишь начало полного имени этого файла. Для того чтобы узнать требуемое пол" ное имя (включающее в себя путь к каталогу, содержащему конфигурационный файл), можно прибег" нуть к небольшой хитрости: прочитать это имя непосредственно из системной таблицы syscurconfigs, воспользовавшись запросом select value2 from syscurconfigs where config=114 Подкоманда write (записать) позволяет создать новый конфигурационный файл, содержащий те" кущие фактические (run) значения параметров настройки сервера: 1> sp_configure 'configuration f i l e ' , 0, ' w r i t e ' , 'имя_создаваемого_конфигу" рационного_файла ' 2> go Здесь не требуется указывать полный путь к каталогу, в котором создается данный файл, посколь" ку по умолчанию сервер определит этот путь из переменной среды SYBASE. Для создания конфигурационного файла, содержащего текущие установленные (config) значения параметров настройки сервера, служит подкоманда restore (восстановить): 1> sp_conf igure 'configuration f i l e ' , 0, 'restore', 'имя_восстанавливаемо" го_конфигурационного_файла ' 2> go

www.books-shop.com

Подкоманды write и restore записывают в создаваемый файл разные значения параметров, и это различие заслуживает более подробного рассмотрения. В ситуации, когда администратору наконец"то удается достичь оптимальной настройки сервера, в его распоряжении обычно уже имеется конфигу" рационный файл со всеми текущими фактическими значениями параметров настройки. Если после запуска сервера в этот файл были внесены изменения и необходимо заново получить его исходную версию, соответствующую имеющейся оптимальной конфигурации, следует использовать подкоманду write, записывающую в файл текущие фактические (run) значения параметров настройки. Наоборот, подкоманда restore сохранит в файле текущие установленные (config) значения пара" метров настройки, что может потребоваться в одной из двух следующих ситуаций. Во"первых, при утрате всех конфигурационных файлов сервера, не функционирующего в данный момент, для полу" чения информации о конфигурации из системных таблиц сервера его нужно запустить без конфигу" рационного файла. После подобного запуска все фактические (run) значения параметров настройки сервера выбираются по умолчанию, однако определенные (config) значения этих параметров вос" станавливаются сервером из своих системных таблиц. В подобной ситуации сохранение конфигура" ционного файла подкомандой write приведет к тому, что будет получен файл со всеми параметрами, установленными по умолчанию (т.е. равными DEFAULT). Однако благодаря подкоманде restore мож" но записать в файл определенные (config) на момент останова сервера значения параметров, сохра" ненные сервером в своих таблицах и соответствующие значениям параметров последнего из утраченных конфигурационных файлов. Таким образом, подкоманда restore позволяет восстановить с помощью системных таблиц сервера утраченный конфигурационный файл после запуска сервера без конфигурационного файла. Во"вторых, подкоманда restore полезна при создании нескольких конфигурационных файлов, от" личающихся значениями некоторых статических параметров конфигурации. При изменении значе" ний таких параметров сервер модифицирует только установленные (config) значения, поскольку изменение их фактических (run) значении без перезапуска невозможно. Сохранение конфигураци" онного файла подкомандой restore позволяет сохранить произведенные изменения статических па" раметров в отдельном файле без перезапуска сервера. Подкоманда verify (проверить) используется для установления возможности запуска сервера с данным командным файлом. Она полезна для контроля корректности внесенных вручную измене" ний, а также при переносе конфигурационных файлов с одного сервера или серверного компьюте" ра на другой. 1> sp_configure 'configuration f i l e ' , 0, ' v e r i f y ' , ' имя_проверяемого_конфигурационного_файла ' 2> go Наконец, загрузить в сервер конфигурационный файл с диска можно подкомандой read (про" читать): 1> sp_configure 'configuration f i l e ' , 0, 'read', ' имя_загружаемого_конфигурационного_файла ' 2> go Как и в других подкомандах, здесь нет необходимости указывать полное имя файла, поскольку путь к его каталогу будет взят сервером из переменной среды SYBASE. Подкоманда read позволяет модифицировать конфигурацию работающего сервера при условии, что загружаемый файл не изме" няет установки статических параметров настройки. В противном случае чтение конфигурационного файла завершится аварийно и ни одно из прочитанных изменении не будет внесено в конфигура" цию сервера. Кстати, конфигурационный файл вовсе не обязательно должен содержать значения всех параметров настройки: при указании в момент запуска сервера неполного (но синтаксически корректного) конфигурационного файла или при чтении такого файла подкомандой read все пара" метры, отсутствующие в файле, сохраняют свои текущие значения. Сообщения об ошибках при чтении конфигурационного файла Загрузка конфигурационного файла позволяет изменять значения сразу многих параметров настрой" ки работающего сервера. Тем самым обеспечивается быстрая реконфигурация сервера для поддерж" ки новых приложений. Однако порой процесс загрузки файла завершается сообщением об ошибке. Как отмечалось выше, при запуске сервера имя конфигурационного файла либо явно указывает" ся после параметра "с командной строки, либо сервер использует файл <имя_сервера>.сfg, нахо" дящийся в каталоге $SYBASE. При запуске сервера конфигурационный файл позволяет

www.books-shop.com

модифицировать абсолютно все параметры настройки, включая параметры именованных кэш"буфе" ров и их буферных областей. Однако при неправильном значении переменной среды SYBASE либо при изменении имени сервера поиск файла <имя_сервера>.сfg может окончиться неудачей или же сервером будет прочитан случайно обнаруженный файл с иной конфигурацией. После перезапу" ска сервера проверьте в файле регистрации ошибок название конфигурационного файла, использо" ванного сервером. При загрузке конфигурационного файла в работающий сервер с помощью подкоманды read про" цедуры sp_conf igure спектр вносимых изменений ограничен динамическими параметрами на" стройки. Таким образом, подкоманда read не позволит модифицировать параметры именованных кэш"буферов и их буферных областей, хотя в загружаемом файле обязательно должно содержаться описание общего кэш"буфера (который, впрочем, всегда существует). Несмотря на запрет модификации статических параметров настройки при загрузке конфигура" ционного файла в работающий сервер, загружаемый файл вполне может содержать описания подоб" ных параметров при условии, что указанные в файле значения совпадают с текущими значениями этих параметров, используемыми сервером. До выхода в свет System 11 единственным способом внесения изменений в конфигурацию серве" ра было использование процедуры sp_conf igure. Однако с появлением в System 11 понятия имено" ванных кэш"буферов ситуация принципиально изменилась. Любая модификация структуры именованных кэш"буферов одновременно является и модификацией конфигурации сервера, записы" ваемой в его конфигурационный файл. В результате, если после запуска сервера с конфигурацион" ным файлом config.one мы создадим именованный кэш"буфер, то еще до момента перезапуска сервера для активизации внесенных изменений последние будут автоматически отражены в этом файле. Таким образом, при дальнейшем перезапуске сервера будем иметь дело с новой версией фай" ла config.one, несмотря на то что команда sp_conf igure вообще не использовалась с момента пре" дыдущего запуска. Подкоманда read: осторожно! Если учесть все ограничения, накладываемые на модификацию конфигурации работающего сервера с помощью загрузки нового конфигурационного файла, то вы едва ли станете уж очень часто прибе" гать к подобному приему, хотя порой такое решение вполне оправданно — например, при необходи" мости регулярно изменять значения группы динамических параметров настройки сервера. При этом рекомендуется придерживаться одного из двух подходов. Во"первых, можно удалить из конфигураци" онного файла все параметры, за исключением модифицируемых (а также описания общего кэш"буфе" ра, о чем говорилось выше). В результате сервер автоматически сохранит используемые значения остальных параметров. Во"вторых, можно взять за основу текущую копию полного конфигурационно" го файла и внести в нее необходимые изменения. Здесь важно правильно определить, какой конкрет" но конфигурационный файл является текущим, приняв во внимание, что стандартный конфигурационный файл <имя_сервера>.сfg не применяется сервером при его запуске с явным указанием имени другого конфигурационного файла. Структура вывода команды sp.configure Значения параметров настройки сервера, выдаваемые командой sp_conf igure, сгруппированы в несколько перечисленных ниже разделов. Список значений параметров отдельного раздела можно получить, указав название этого раздела при вызове процедуры: sp_conf igure <название_разде" ла>. На момент написания книги два раздела вообще не имели никаких параметров, в то время как некоторые параметры настройки одновременно фигурировали в нескольких разделах. Так, конфигу" рационный параметр number of devices (количество серверных устройств) можно встретить как в разделе Disk I/O (дисковый ввод/ вывод), так и в разделе Memory Use (использование памяти). Пол" ный список разделов: • Configuration Options (режимы конфигурации; раздел не содержит параметров) • Backup/recovery (резервирование/восстановление) • Cache manager (диспетчер кэш"буфера) • Disk I/O (дисковый ввод/вывод)

• General information (общие параметры) • Languages (поддержка национальных языков) • Lock manager (диспетчер блокировок)

www.books-shop.com

• Memory Use (использование памяти) • Network communication (сетевой ввод/вывод) • O/S resources (ресурсы операционной системы) • Physical resources (аппаратные ресурсы; раздел не содержит параметров) • Physical memory (физическая память) • Processors (процессоры) • SQL Server Administration (администрирование сервера) • User environment (пользовательская среда)

Вывод sp.configure Степень детализации Каждому пользователю сервера устанавливается один из трех возможных уровней детализации ин" формации, выдаваемой командой sp_conf igure: минимальный (basic), промежуточный (intermedi" ate) и подробный (comprehensive; этот уровень используется по умолчанию). Каждый пользователь может самостоятельно изменять необходимый ему уровень детализации. Кроме того, подобная опе" рация входит в число полномочий ответственного за безопасность сервера (т.е. любого пользовате" ля, обладающего ролью sso_role), устанавливающего максимально допустимый уровень детализации для любого пользователя сервера. В последнем случае иногда возникает ситуация, когда пользователь, обладающий ролью sa_role, с помощью sp_conf igure изменяет значения парамет" ров настройки, но не может распечатать той же командой значения модифицированных параметров, если эти значения не выдаются при разрешенном ему уровне детализации (для изменения которого требуется другая роль — sso_role). Подробный уровень вывода sp_configure По умолчанию вывод команды sp_conf igure имеет подробный (comprehensive) уровень детали" зации: 1> sp_configure 2> до Group: Configuration Options Group: Backup/Recovery Run Memory Config Value Value Default Used Parameter Name 1 1 1 0 allow remote access print recovery information 0 0 0 0 recovery interval in minutes 5 5 5 0 tape retention in days 0 0 0 0 Group: Cache Manager Parameter Name memory alignment boundary number of index trips number of oam trips procedure cache percent total data cache size total memory

Default 2048

О О 20 О 7500

Memory Used 0 0 0 990 3812 15000

Config Value 2048 0 0 20 0 7500

Run Value 2048 0 0 20 3812 7500

Memory Used 0 19 4

Config Value 1 256 10

Run Value 1 256 10

Group: Disk I/O Parameter Name

allow sql server async i/o disk i/o structures number of devices

Default 1 256 10

www.books-shop.com

page utilization percent

95

0

95

95

Group: General Information Parameter Name configuration file

Default

0

Memory Used

0

Config Value

0

Run Value /home/sybas

Group : Languages Parameter Name default character set id default language id default sortorder id number of languages in cache

Default

1 0 50 3

Memory Used

0 0 0 4

Config Value

1 0 50 3

Run Value

1 0 50 3

Group: Lock Manager Parameter Name address lock spinlock ratio deadlock checking period freelock transfer block size max engine freelocks number of locks page lock spinlock ratio table lock spinlock ratio

Default

100 500 30 10 5000 100 20

Memory Used

0 0 0 0 469 0 0

Config Value

Run Value

100 500 30 10

100 500 30 10

5000 100 20

5000 100 20

Config Value

Value

Group: Memory Use Parameter Name Default additional network memory 0 audit queue size 100 default network packet size 512 disk i/o structures 256 event buffers per engine 100 executable codesize + overhead 0 max number network listeners 15 max online engines 1 number of alarms 40 number of devices 10 number of extent i/o buffers 0 number of languages in cache 3 number of locks 5000 number of mailboxes 30 number of messages 64 number of open databases 12 number of open objects 500 number of remote connections 20 20 number of remote logins number of remote sites 10 number of user connections 25 partition groups 1024 permission cache entries 15 procedure cache percent 20 remote.server pre#read packets 3 stack guard size 4096 stack size 34816 0 total data cache size

Memory Used

0 42 #135

19 #10 4941 1124 147 1

#4 0 4 469 1 1 396 489 33 22 749 1868 21 #28 990 #32 #240 #2041 3812

0 100 512 256 100 0 15 1 40 10 0 3 5000 30 64 12 500 20 20 10 25 1024 15 20 3 4096 34816 0

Run 0 100 512 256 100 4941

15 1 40 10 0 3 5000 30 64 12 500 20 20 10 25 1024 15 20 3 4096 34816 3812

www.books-shop.com

total memory Group: Network Communication

7500

Parameter Name Default additional network memory 0 allow remote access 1 default network packet size 512 max network packet size 512 max number network listeners 15 number of remote connections 20 number of remote logins 20 number of remote sites 10 remote server pre#read packets 3 tcp no delay 0 0 0 0

15000

7500

7500

Memory Used

Config Value

Run Value

0 0 #135

0 1124

33 22 749 #32

0 1 512 512 15 20 20 10 3

0 1 512 512 15 20 20 10 3

Group: O/S Resources

max max o/s o/s tcp

Parameter Name async i/os per engine async i/os per server asynch i/o enabled file descriptors no delay

Default 2147483647 2147483647 0 0 0

Memory Used

0 0 0 0 0

Config Run Value Value 2147483647 2147483647 2147483647 2147483647 0 0 0 1024 0 0

Group: Physical Resources Group: Physical Memory Parameter Name Default additional network memory 0 lock shared memory 0 shared memory starting address 0 total memory 7500

0 0 0

0 0 0

15000

7500

Run Value 0 0 0 7500

Memory Used 147 0

Config Value

Run Value

Memory Used 0 0 42 0 0 0 0 0 #10 0

Config Value

Memory Used

Config Value

Group: Processors Parameter Name max online engines min online engines

Default 1 1

1 1

1 1

Group: SQL Server Administration Parameter Name Default allow nested triggers 1 allow updates to system tables 0 audit queue size 100 cpu accounting flush interval 200 cpu grace time 500 deadlock retries 5 default database size 2 default fill factor percent 0 event buffers per engine 100 housekeeper free write percent 1

i/o accounting flush interval 1000 i/o polling process count identity burning set factor identity grab size

1:0 5000 1

0 0 0 0

Run Value

1 0 100 200 500 5 2 0 100 1

1 0 100 200 500 5 2 0 100

1000

1000

10 5000 1

5000 1

1

10

www.books-shop.com

lock promotion HWM 200 200 lock promotion LWM 100 lock promotion PCT number of alarms 40 number of extent i/o buffers 0 number of mailboxes 30 64 number of messages 12 number of open databases 500 number of open objects 2 number of pre#allocated extent number of sort buffers 0 1024 partition groups 10 partition spinlock ratio 0 print deadlock information runnable process search count 2000 10 size of auto identity column sort page count 0 sql server clock tick length 100000 100 time slice 1100 upgrade version

0 0 0 1 0 1 1 396 489 0 0 21 0 0 0 0 0 0 0 0

200 200 100 40 0 30 64 12 500 2 0 1024 10 0

200 200 100 40 0 30 64 12 500 2 0 1024 10 0

2000

2000

10 0

10 0

100000

100000

100 1100

100 1100

Config Value 512 2 25 15 4096 34816 0 2048 20

Run Value 512 2 25 15 4096 34816 0 2048 20

Group: User Environment Parameter Name Default default network packet size 512 number of pre#allocated extent 2 number of user connections 25 permission cache entries 15 stack guard size 4096 stack size 34816 systemwide password expiration 0 user log cache size 2048 user log cache spinlock ratio 20 (return status = 0)

Memory Used #135 0 1868 #28 #240 #2041 0 0 0

Минимальный уровень выдачи sp_configure Наряду с подробным в команде sp_conf igure предусматривается также минимальный (basic) и промежуточный (intermediate) уровень детализации выдаваемой информации. Каждый пользова тель сервера сам устанавливает необходимый уровень детализации. Однако любой пользователь, обладающий ролью sso_role, может ограничить максимальный уровень детализации, разрешен ный для конкретного пользователя сервера. И в первом, и во втором случае используется команда sp_displaylevel. 1> sp_displaylevel 2> go The current display level for login 'sa' is 'comprehensive'. Для пользователя 'sa' установлен уровень детальности 'comprehensive'.

(return status = 0) 1> sp_displaylevel sa, basic 2> go The display level for login 'sa' has been changed to 'basic'. Для пользователя 'sa' уровень детальности изменен на 'basic'. (return status = 0 ) 1> sp_configure 2> go Group: Configuration Options Group: Backup/Recovery

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Parameter Name recovery interval in minutes

Default

Memory Used

Config Value

0

5

Run Value

5

5

Group: Cache Manager Default Parameter Name total data cache size 0 3812 0 3812

Run

Memory Used

Config Value

Value

Memory Used

Config Value

Value

#4

10

10

Memory Used

Config Value 5000

Value 5000

Group: Disk I/O Parameter Name number of devices

Default

10

Run

Group: General Information Group : Languages Group: Lock Manager Parameter Name number of locks

Default 5000

469

Run

Group: Memory Use Parameter Name Default executable codesize + overhead 0 number of devices 10 5000 number of locks 12 number of open databases number of open objects 500 25 number of user connections 34816 stack size 0 total data cache size

Memory Used 4941

Config Value

0 10

Run Value 4941

10

#4 469 396 489 1868 #2041 3812

5000

5000

12 500 25 34816 0

12 500 25 34816 3812

Default 12 500

Memory Used 396 489

Config Value 12 500

Run Value 12 500

Default 25 34816

Memory Used 1868 #2041

Config Value 25 34816

Run Value 25 34816

Group: Network Communication Group: O/S Resources Group: Physical Resources Group: Physical Memory Group: Processors Group: SQL Server Administration Parameter Name number of open databases number of open objects Group: User Environment Parameter Name number of user connections stack size (return status = 0)

www.books-shop.com

Промежуточный уровень выдачи sp.configure 1> sp_displaylevel 2> go The current display level for login 'sa' is 'basic'. Для пользователя 'sa' установлен уровень детализации 'basic'. (return status = 0) 1> sp_displaylevel sa, intermediate 2> go The display level for login 'sa' has been changed to 'intermediate'. Для пользователя 'sa' уровень детализации изменен на 'intermediate'. (return status =0) 1> sp_displaylevel 2> go The current display level for login 'sa' is 'intermediate'. Для пользователя 'sa' установлен уровень детализации 'intermediate'. (return status = 0) 1> sp_configure 2> go Group: Configuration Options Group: Backup/Recovery Parameter Name allow remote access print recovery information recovery interval in minutes tape retention in days

Default 1 0 5 0

Memory Used 0 0 0 0

Config Value 1 0 5 0

Run Value 1, 0 5 0

Default 0 7500

Memory Used 3812 15000

Config Value 0 7500

Run Value 3812 7500

Default 10

Memory Used #4

Config Value 10

Run Value 10

Default 1 0 3

Memory Used 0 0 4

Config Value 1 0 3

Run Value 1 0 3

Default 5000

Memory Used 469

Config Value 5000

Run Value 5000

Group: Cache Manager Parameter Name total data cache size total memory Group: Disk I/O Parameter Name number of devices Group: General Information Group: Languages Parameter Name default character set id default language id number of languages in cache Group: Lock Manager Parameter Name number of locks Group: Memory Use

www.books-shop.com

Parameter Name Default additional network memory 0 audit queue size 100 default network packet size 512 executable codesize + overhead 0 max online engines 1 number of devices . 10 number of languages in cache 3 number of locks 5000 number of open databases 12 number of open objects 500 number of remote connections 20 number of remote logins 20 number of remote sites 10 number of user connections 25 remote server pre#read packets 3 stack size 34816 total data cache size 0 total memory 7500

Memory Used

0 42

Config Value

Run Value

0 100 512 0 1 10 3

4941

5000

5000

12 500 20 20 10 25 3

12 500 20 20 10 25 3

#2041 3812 .15000

34816

34816 3812 7500

Memory Used

Config Value

#135 4941

147 #4 4 469 396 489 33 22 749 1868

#32

0 7500

0 100 512 1 10 3

Group: Network Communication Parameter Name Default additional network memory 0 allow remote access 1 default network packet size 512 max network packet size 512 number of remote connections 20 number of remote logins 20 number of remote sites 10 remote server pre#read packets 3

0 0 #135

0 33 22 749 #32

0 1 512 512 20 20 10 3

Run Value

0 1 512 512 20 20 10 3

Group: O/S Resources Group: Physical Resources Group: Physical Memory Parameter Name additional network memory total memory

Default 0 7500

Memory Used

Config Value

Run Value

0

0

0

15000

7500

7500

Memory Used

Config Value

Value

Group: Processors Parameter Name max online engines min online engines

Default 1 1

147 0

1 1

Run 1 1

Group: SQL Server Administration Parameter Name Default allow nested triggers 1 audit queue size 100 deadlock retries 5 default database size 2 default fill factor percent 0 housekeeper free write percent 1

Memory Used

0 42 0 0 0 0

Config Value

1 100 5 2 0 1

Run Value

1 100 5 2 0 1

www.books-shop.com

identity burning set factor identity grab size lock promotion HWM lock promotion LWM lock promotion PCT number of open databases number of open objects print deadlock information size of auto identity column

5000 1 200 200 100 12 500 0 10

0 0 0 0 0 396 489 0 0

5000 1 200 200 100 12 500 0 10

5000 1 200 200 100 12 500 0 10

Config Value

Value

Group: User Environment Memory Parameter Name Default Used #135 default network packet size 512 number of user connections 25 1868 stack size 34816 #2041 systemwide password expiration 0 0 0 0 user log cache size 2048 0 2048 2048 user log cache spinlock ratio 20 0 20 20 (return status = 0)

Run

512 25

512 25

34816

34816

Вывод значений параметров одного раздела командой sp_configure 1> sp_configure 'Physical Memory' 2> go Group: Physical Memory Memory Config Run Parameter Name Default Used Value Value additional network memory 0 0 0 0 0 0 lock shared memory 0 0 0 0 shared memory starting address 0 0 0 0 0 0 total memory 7500 15000 7500 7500 (return status = 0 ) Вывод названия текущего конфигурационного файла командой sp.configure Как отмечалось выше, sp_configure не позволяет выдать имя текущего конфигурационного файла полностью. Для этой цели используется команда, приведенная в следующем примере. 1> sp_configure 'configuration f i l e ' 2> go Memory Config Run Parameter Name Default Used Value Value configuration f i l e О О /home/sybas (return status = 0) Определение названия текущего конфигурационного файла из системных таблиц сервера 1> select db_name() 2> go master (1 row affected) 1> select value2 from syscurconfigs where config=114 2> go value2

/home/sybase/11.0.1/THEBIRDS11.cfg (1 row affected)

www.books-shop.com

Подкоманды read и verify команды sp.configure Конфигурационный файл изменяет значение статического параметра настройки 1> sp_configure 'configuration file', 0, 'verify', '/home/sybase/ll.O/con# fig_test.001' 2> go Msg 5852, Level 16, State 1: Server 'THEBIRDS11', Procedure 'sp_configure', Line 199: Changing the value of 'total memory' is not allowed since it is a static option. Изменение значения параметра 'total memory' недопустимо, поскольку указанный параметр является статическим. (return status = 1 ) Конфигурационный файл содержит изменения в структуре именованных кэш*буферов 1> sp_configure 'configuration file', 0, 'read', '/home/sybase/ll.O/con# fig_test.001' 2> go WARNING: Dynamic loading of caches and pools through loading a new file are not supported. However, the loadfile '/home/sybase/11.0/config_test.001' will be inspected for consistency. Refer to 'sp_cacheconfig' and 'sp_poolconfig' to create or alter pools and caches. ПРЕДУПРЕЖДЕНИЕ. Динамическая реконфигурация кэш#буферов и буферных областей посредством загрузки нового конфигурационного файла не поддерживается сервером. Однако загружаемый файл '/home/sybase/11.0/config_test.001' будет проверен на непротиворечивость. Для создания и реконфигурации буферных областей и кэш#буферов используйте команды 'sp_cacheconfig' и 'sp_poolconfig'. Msg 5852, Level 16, State 1: Server "THEBIRDSll', Procedure 'sp_configure', Line 199: Changing the value of 'total memory' is not allowed since it is a static option. Изменение значения параметра 'total memory' недопустимо, поскольку указанный параметр является статическим.

(return status = 1) Успешная проверка текущего конфигурационного файла, используемого сервером 1> sp_configure 'configuration file', 0, 'verify', '/home/sybase/11.0/THE# BIRDSll.cfg' 2> go (return status = 0) Выводимые значения параметров Параметры, выводимые командой sp_conf igure в System 11, по своему составу отличаются от ана логичных, входивших в предыдущие версии сервера. Для каждого параметра настройки теперь выда ются установленное (config) и фактическое (run) значения, значение по умолчанию (столбец Default), объем памяти, необходимый серверу для поддержки текущего фактического значения этого параметра (столбец Memory Used). Установленные значения отражают конфигурацию сервера, хра нящуюся в системной таблице sysconfigures, установленные и фактические значения динамических па раметров настройки всегда совпадают. Для статических параметров установленное значение соответствует фактическому значению, которое будет иметь данный параметр после перезапуска сер вера. Текущие фактические значения параметров настройки отражают конфигурацию, которой обла дает сервер в данный момент, и хранятся в системной таблице syscurconfigs. Анализ выдачи ep_configure значительно осложняется разнообразием используемых единиц измерения, опреде ляемых для каждого параметра индивидуально. Так, общий размер памяти (total memory) выводится в виде числа 2Кбайт страниц, в то время как значения столбца с объемом памяти, используемой для поддержки текущего значения параметра (memory used), всегда измеряются в килобайтах. Наконец, количество пользовательских соединений (number of user connections) представлено безразмерным целым числом. Таким образом, на приведенных выше распечатках общий размер памяти по умолча нию равен 7500 страницам по 2 Кбайт, а объем памяти, фактически необходимый" для текущего

www.books-shop.com

значения этого параметра (также равного 7500 страницам), составляет 15 000 Кбайт. Еще более зага" дочно выглядит знак "#", предшествующий некоторым значениям в столбце Memory Used. Он указы" вает на то, что объем памяти, необходимый серверу для обеспечения текущего значения данного параметра, зависит от значений других параметров. К примеру, объем памяти, требуемой для опреде" ленного количества буферов событий каждого ядра (параметр event buffers per engine), изменяется при изменении общего числа серверных ядер. Наконец, ряд параметров имеет значение по умолча" нию, равное 0. Это указывает на то, что сервер вычисляет устанавливаемую по умолчанию величину параметра (которая вовсе не обязана равняться нулю) на основании значений других параметров на" стройки. Совместимость с предыдущими версиями Хотя администратор сервера может изменять с помощью sp_conf igure значения индивидуальных параметров настройки любых версий SQL Server, в System 11 изменены названия некоторых пара" метров. Так, параметр настройки total memory (общий размер памяти) ранее назывался просто me" mory, и любой из прежних командных файлов, содержащий команду sp_conf igure 'memory', завершится сообщением об ошибке. Таким образом, при переходе на новую версию сервера необхо" димо проанализировать все командные файлы и периодически запускаемые cron"задания, осуществ" ляющие реконфигурацию сервера. К примеру, в командных файлах запуска сервера может понадобиться явно указать имя конфигурационного файла. Кроме того, до появления System 11 по" сле любой модификации конфигурации сервера командой sp_conf igure необходимо было вы" полнить команду reconfigure. В System 11 команда reconfigure не требуется, и, хотя ее вызов не сопровождается сообщением об ошибке, Sybase не гарантирует поддержку этой команды в будущих версиях сервера. Так что рекомендуем удалить команду reconfigure из всех имеющихся командных файлов. 1 На практике процесс анализа, модификации и проверки работоспособности всех коман+ дных файлов значительно увеличивает объем работы, необходимой для перехода на сер+ вер System 11. Готовые программные средства Sybase обеспечивают здесь лишь обновление самого сервера и перенос в него новых баз данных. Процедура sp_configure и выдача сообщений в журнал регистрации ошибок При использовании процедуры sp_conf igure в журнал регистрации ошибок сервера выводятся со" общения о выполненных операциях. Изменение динамического параметра настройки командой sp_conflgure 00:96/05/15 10:58:04.06 server The configuration option 'number of user connections' has been changed by 'sa' from '25' to '30'. 00:96/05/15 10:58:04.17 server Configuration file '/home/syba# se/ll.O/THEBIRDSll.cfg' has been written and the previous version has been renamed to '/home/sybase/ll.O/THEBIRDSll.019'. Процедура sp_configure и выдача сообщений в журнал регистрации ошибок при работе с конфигурационными файлами При использовании процедуры sp_conf igure для работы с конфигурационными файлами в жур" нал регистрации ошибок выводится название конфигурационного файла, используемого сервером. Конфигурационный файл не указан при запуске сервера, но в каталоге $SYBASE имеется файл <имя_сервера>.cfg thebirds:Sybase 16: more RUN_THEBIRDS11 #!/bin/sh #

#

SQL Server Information:

#

имя сервера:

THEBIRDS11

# #

раздел для устройства master: размер устройства master:

/dev/rdsk/cOt2dOs7 45056

www.books-shop.com

# журнал регистрации ошибок: /home/sybase/11 .0/install/errorlog # файл интерфейсов: /home/sybase/11.0 # /home/sybase/11.0/bin/dataserver #d/dev/rdsk/cOt2dOs7 #sTHEBIRDSll \ #e/home/sybase/11.0/install/errorlog_THEBIRDSll #i/home/sybase/11.0 thebirds: Sybase 14: 00:96/05/15 11:02:09.68 kernel Using config area from primary master device. 00:96/05/15 11:02:09.72 kernel Warning: Using default file ' /home/sybase/11.0/THEBIRDSll.cfg' since a configuration file was not specified. Specify a configuration file name in the RUNSERVER file to avoid this message. 00:96/05/15 11:02:09.72 kernel Предупреждение. Не указан конфигурационный файл, вследствие чего используется файл по умолчанию ' /home/sybase/11.0/THEBIRDSll.cfg' . Для предотвращения вывода данного сообщения укажите имя конфигурационного файла в командном файле запуска сервера . 00:96/05/15 11:02:10.10 kernel Using 1024 file descriptors. 00:96/05/15 11:02:10.10 kernel SQL Server/11.0/P/Sun_svr4/OS 5.4/1/OPT/Thu Dec 7 23:58:01 PST 1995 00:96/05/15 11:02:10.10 kernel Confidential property of Sybase, Inc. 00:96/05/15 11:02:10.12 kernel (c) Copyright Sybase Inc., 1987, 1995. 00:96/05/15 11:02:10.12 kernel All rights reserved. 00:96/05/15 11:02:10.12 kernel 00:96/05/15 11:02:10.12 kernel Use, duplication, or disclosure by the United States Government 00:96/05/15 11:02:10.13 kernel is subject to restrictions as set forth in FAR subparagraphs 00:96/05/15 11:02:10.13 kernel 52 .227#19 (a) # (d) for civilian agency con# tracts and DFARS 00:96/05/15 11:02:10.13 kernel 252 .227#7013 (c) (1) (ii) for Department of Defense contracts. 00:96/05/15 11:02:10.13 kernel Sybase reserves all unpublished rights under the copyright 00:96/05/15 11:02:10.13 kernel laws of the United States. 00:96/05/15 11:02:10.13 kernel Sybase, Inc. 6475 Christie Avenue, Emeryville, CA 94608 USA. 00:96/05/15 11:02:10.13 kernel Using ' /home/sybase/11 . 0/THEBIRDS11 .cfg' for configuration information.

Явное указание имени конфигурационного файла при запуске сервера thebirds: Sybase 17: more RUN_THEBIRDSll_config #!/bin/sh # # SQL Server Information: # имя сервера: THEBIRDS11 # раздел для устройства master: /dev/rdsk/cOt2dOs7 # размер устройства master: 45056 # журнал регистрации ошибок: /home/sybase/11. 0/install/errorlog # файл интерфейсов: /home/sybase/11.0 # /home/sybase/11.0/bin/dataserver #d/dev/rdsk/cOt2dOs7 #sTHEBIRDSll \ #e/home/sybase/11.0/install/errorlog_THEBIRDSll #i/home/sybase/11.0 \ #c/home/sybase/11.0/THEBIRDSll.cfg_moved thebirds: Sybase 20:00:96/05/15 11:04:38.90 kernel Using config area from primary master device. 00:96/05/15 11:04:38.90 kernel Using 1024 file descriptors. 00:96/05/15 11:04:38.94 kernel SQL Server/11.0/P/Sun_svr4/OS 5.4/1/OPT/Thu Dec 7 23:58:01 PST 1995 00:96/05/15 11:04:39.15 kernel Confidential property of Sybase, Inc.

www.books-shop.com

00:96/05/15 11:04:39.16 kernel (c) Copyright Sybase Inc., 1987, 1995. 00:96/05/15 11:04:39.16 kernel All rights reserved. 00:96/05/15 11:04:39.16 kernel 00:96/05/15 11:04:39.16 kernel Use, duplication, or disclosure by the United States Government 00:96/05/15 11:04:39.16 kernel is subject to restrictions as set forth in FAR subparagraphs 00:96/05/15 11:04:39.16 kernel 52.227#19 (a) # (d) for civilian agency contracts and DFARS 00:96/05/15 11:04:39.16 kernel 252 .227#7013 (c) (1) (ii) for Department of Defense contracts. 00:96/05/15 11:04:39.16 kernel Sybase reserves all unpublished rights under the copyright 00:96/05/15 11:04:39.16 kernel laws of the United States. 00:96/05/15 11:04:39.16 kernel Sybase, Inc. 6475 Christie Avenue, Emeryville, CA 94608 USA. 00:96/05/15 11:04:39.16 kernel Using ' /home/sybase/11. 0/THEBIRDS11 .cfg_moved' for configuration information. Конфигурационный файл не указан при запуске сервера, и его нет в каталоге $SYBASE Использована конфигурация по умолчанию и создан новый файл THEBIRDSll.cfg. thebirds: Sybase 27:00:96/05/15 11:11:34.44 kernel Using config area from primary master device. 00:96/05/15 11:11:34.46 kernel Configuration Error: Configuration file, 1 /home/sybase/ll.O/THEBIRDSll.cfg', does not exist. 00:96/05/15 11:11:34.53 kernel Ошибка в конфигурации: конфигурационного файла ' /home/sybase/11.0/THEBIRDS11.cfg' не существует. 00:96/05/15 11:11:34.53 kernel Warning: A configuration file was not specified and the default file ' /home/sybase/11.0/THEBIRDS11. cfg' does not exist. SQL Server creates the default file with the default configuration. 00:96/05/15 11:11:34.53 kernel Предупреждение. Не указан конфигурационный файл; файла по умолчанию ' /home/sybase/ll.O/THEBIRDSll.cfg' не существует. SQL Server создаст конфигурационный файл с конфигурацией по умолчанию. 00:96/05/15 11:11:34.90 kernel Using 1024 file descriptors. 00:96/05/15 11:11:34.90 kernel SQL Server/11.0/P/Sun_svr4/OS 5.4/1/OPT/Thu Dec 7 23:58:01 PST 1995 00:96/05/15 11:11:34.90 kernel Confidential property of Sybase, Inc. 00:96/05/15 11:11:34.90 kernel (c) Copyright Sybase Inc., 1987, 1995. 00:96/05/15 11:11:34.90 kernel All rights reserved. 00:96/05/15 11:11:34.90 kernel 00:96/05/15 11:11:34.90 kernel Use, duplication, or disclosure by the United States Government 00:96/05/15 11:11:34.90 kernel is subject to restrictions as set forth in FAR subparagraphs 00:96/05/15 11:11:34.90 kernel 52.227#19 (a) # (d) for civilian agency contracts and DFARS 00:96/05/15 11:11:34.90 kernel 252 .227#7013 (c) (1) (ii) for Department of Defense contracts. 00:96/05/15 11:11:34.90 kernel Sybase reserves all unpublished rights under the copyright 00:96/05/15 11:11:34.90 kernel laws of the United States. 00:96/05/15 11:11:34.90 kernel Sybase, Inc. 6475 Christie Avenue, Emeryville, CA 94608 USA. 00:96/05/15 11:11:34.90 kernel Using ' /home/sybase/11 . 0/THEBIRDS11.cfg' for configuration information.

www.books-shop.com

128

Глава

5

Заключение: общие рекомендации по конфигурированию сервера Поскольку в System 11 появилось понятие именованных кэш"буферов, рассмотренных в главе 4, чита" телю потребуется выработать новый подход к процедуре конфигурирования сервера. Раньше для по" лучения всей информации о конфигурации сервера достаточно было сохранить полную выдачу sр_сопfigure. А в System 11 важной составной частью конфигурации сервера служит информация о структуре именованных кэш"буферов, которая не выдается командой sp_configure. Разумеется, по" добная структура указана в конфигурационном файле сервера, но там все установленные по умолча" нию параметры имеют значение DEFAULT и их реальные значения нельзя узнать без помощи sp_configure. Таким образом, для полного документирования конфигурации сервера необходимо одновременно с выдачей sp_configrure сохранить и соответствующий конфигурационный файл. При наличии нескольких подобных файлов для каждого из них следует иметь копию выдачи команды sp_configure.

www.books-shop.com

Глава 6

Администрирование SQL Server System 11

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Дампы баз данных При переходе к System 11 необходимо принять во внимание две особенности нового сервера, связан" ные с загрузкой дампов баз данных. Во"первых, System 11 может загружать дампы баз данных и журна" лов транзакций, созданные сервером версии System 10. Во"вторых, после загрузки дампа базы данных в сервер System 11 база данных находится в автономном (offline) состоянии. Для разрешения доступа пользователей ее необходимо перевести в активное (online) состояние. Загрузка дампов баз данных версии System 10 Как уже говорилось, дамп пользовательской базы данных SQL Server версии System 10 можно загру" зить в пользовательскую базу данных SQL Server версии 11. Подобная операция возможна только по отношению к пользовательским базам данных, но не к базе данных master. При выполнении загрузки дампа SQL Server System 11 сначала загружает дамп System 10 и после завершения загрузки автомати" чески преобразует базу данных к формату System 11 — точно так же, как базы данных преобразуются в формат System 11 при переходе всего сервера от System 10 к System 11. Здесь представляют интерес два аспекта. Во"первых, при переходе с System 10 на System 11 вряд ли получится мгновенно прекратить дея". тельность компании. Скорее всего, сервер System 10 продолжит по"прежнему поддерживать норма" льную работу бизнес"приложений, в то время как System 11 будет установлена на отдельной серверной машине. Затем в System 11 создается база данных, по размерам и структуре идентичная базам данных System 10, и из дампов загружается их содержимое, созданных сервером System 10, продолжающим нести основную пользовательскую нагрузку. Лишь окончательно убедившись в пол" ной работоспособности баз данных на новой версии сервера, можно перенести на нее всю нагрузку, сделав окончательный дамп рабочих баз данных сервера System 10 и загрузив этот дамп в System 11. Таким образом, возможность переноса дампов из System 10 в System 11 позволяет осуществить по" степенный переход на новую версию сервера с полным сохранением работоспособности приложе" ний. К сожалению, это не избавляет администратора сервера от выполнения ряда вспомогательных операций при переходе к серверу System 11. Речь идет об удалении и воссоздании ряда объектов баз данных, а также о проверке установки порогов последнего уровня (last"chance thresholds, см. гла" вы 12 и 13). Во"вторых, у администратора сервера нередко возникает необходимость загрузить старый дамп базы данных, созданный при работе с сервером System 10. После перехода от SQL Server 4.9.2 к System 10 загрузка каждого дампа, созданного в формате версии 4.9.2, требовала установки SQL Server 4.9.2, создания базы данных и ее загрузки из сохранившегося дампа (с последующим повторе" нием процесса обновления сервера на версию System 10, созданием дампа в формате System 10 и за" грузкой этого дампа в основной экземпляр сервера System 10). Сейчас же сервер System 11 позволяет без лишних хлопот загрузить любой дамп System 10. Эта возможность особенно полезна при работе с архивами старых данных, созданных сервером System 10. Не следует забывать о том, что процесс переноса дампов между различными версиями SQL Server по"прежнему сопряжен с рядом существенных ограничений. Подобная операция выполнима только при переносе дампов из System 10 в System 11. Дампы, созданные SQL Server 4.9.2, как и рань" ше, не загружаются ни в сервер System 10, ни в сервер System 11. Кроме того, дампы ни одной вер" сии SQL Server нельзя загружать в серверы предшествующих версий. В частности, созданный сервером System 11 дамп не загружается ни в сервер System 10, ни в сервер версии 4.9.2; аналогично дамп из сервера System 10 нельзя загрузить в SQL Server 4.9.2. Наконец, перенос дампов возможен только между серверами System 10 и System 11, работающими на одинаковых аппаратных платфор" мах под управлением идентичных операционных систем. У читателя может создаться ложное впе" чатление, что дампы любой версии сервера System 10 загружаются в любой сервер System 11. Увы, это не так. К примеру, нельзя создать дамп базы данных сервера System 10, работающего на компью" тере фирмы Hewlett"Packard с операционной системой HP"UX, и загрузить его в сервер System 11, установленный на машине фирмы Sun с операционной системой Solaris.

www.books-shop.com

Хотя перенос дампов между операционными системами SunOS и Solaris на практике вполне возможен, подобная операция официально не поддерживается Sybase. Разумеет+ ся, отсутствие официальной поддержки нисколько не мешает пользоваться данной воз+ можностью; и все же не следует полагаться на нее. Неподдерживаемые приемы чаще всего отказывают почему+то в самый ответственный момент, например, когда приходит+ ся искать выход из критической ситуации. Автономное и оперативное состояние баз данных В предыдущих версиях SQL Server процесс восстановления базы данных в любой момент мог быть прерван любым пользователем сервера (рис. 6.1). Предположим, для восстановления базы данных не" обходимо загрузить дамп базы данных, после чего применить к ней один или несколько сохраненных журналов транзакций. Завершив загрузку дампа базы данных, вы переходите к загрузке первого дампа журнала транзакций и... обнаруживаете, что какой"то пользователь уже успел подключиться к восста" новленной базе данных и модифицировать ее содержимое командами insert, update или dele" te. С равной вероятностью подобная неприятность может произойти и в промежуток времени между загрузкой последовательных дампов журналов транзакций. В любом случае внесение в базу данных посторонних изменений немедленно прекращает процесс ее восстановления, поскольку для повтора транзакций, сохраненных в дампе журнала транзакций, состояние базы данных должно точно соот" ветствовать ее состоянию на момент начала первой транзакции в журнале. В данной ситуации вам придется заново загружать дамп базы данных и повторять загрузку всех дампов журналов транзакций. В известной степени процесс восстановления можно защитить от вмешательства пользователей, пе" реведя командой sp_dboption базу данных в режим "dbo user only", когда доступ разрешен только владельцу этой базы данных (пользователю dbo). Однако и в этом случае все пользователи, имеющие статус пользователя dbo, смогут беспрепятственно войти в восстанавливаемую базу данных и, таким образом, прервать процесс ее восстановления. плановый процесс загрузки базы данных

загрузка журнала транзакций 1

работа администратора с базой данных

разрешен доступ пользователей (либо только пользователей со статусом dbo)

загрузка журнала транзакций 2

полный запрет доступа пользователей

Рис. 6.1. Загрузка баз данных в предшествующих версиях сервера В System 11 процесс восстановления баз данных изменен с целью исключения вмешательства со стороны пользователей. В момент начала загрузки базы данных сервер System 11 автоматически пе" реводит ее в автономное состояние (рис. 6.2). После изменения режима работы базы данных немед" ленно выводится команда sp_helpdb и системная таблица sysdatabases, входящая в состав базы данных master. В сервере не предусмотрено специальной команды для перевода базы данных в авто" номное состояние; эта операция осуществляется только автоматически при загрузке дампа базы дан" ных командой load database. Автономное состояние базы данных сохраняется вплоть до момента выполнения команды online database, к которому восстановление базы данных должно быть завершено. Право использования команды online database имеют только пользователи базы данных, имеющие статус dbo, а также пользователи сервера, обладающие ролью оператора сервера oper_role. Хотя в System 11 пользователь со статусом dbo по"прежнему может прервать процесс восстановления базы данных, здесь ему по крайней мере придется сознательно ввести команду online database. В предыдущих версиях сервера пользователь dbo мог случайно подключиться к

www.books-shop.com

плановый процесс загрузки базы данных

база данных находится в автономном состоянии полный запрет доступа пользователей доступ пользователям открыт ——————— Рис. 6.2. Загрузка базы данных в System 11 базе данных, находящейся в режиме "dbo user only", и не получить никакого предупреждения о том, что в данный момент выполняется восстановление базы данных. Перевод базы данных в оперативное состояние не исключает дальнейшей загрузки журналов транзакций при условии, что ни один пользователь не изменяет состояния восстанавливаемой базы данных. Загрузка дампа журнала транзакций не влияет на режим работы базы данных, и ее перевод в автономное состояние происходит только при загрузке дампа самой базы данных. Таким образом, после загрузки дампа журнала транзакций в базу данных, находящуюся в оперативном состоянии, эта база остается доступной для пользователей и нет необходимости выполнять команду online database. Обратите внимание, что автоматический перевод загружаемых баз данных в автономное состоя" ние относится к числу немногих особенностей System 11, требующих обязательного внесения изме" нения в процесс администрирования сервера. Во все командные файлы, осуществляющие загрузку баз данных, должна быть добавлена команда online database, переводящая восстановленные базы данных в оперативное состояние. В противном случае рассматриваемые командные файлы бу" дут успешно выполнены, но подключиться к базе данных по завершении ее загрузки ни одному поль" зователю не удастся. При модификации командных файлов также следует помнить, что команда online database выдается только из базы данных master. Команда online database играет важную роль и при загрузке дампа базы данных System 10 в сервер System 11 (рис. 6.3), поскольку именно она инициирует процесс преобразования загруженной базы данных в формат System 11. Дело в том, что проверка формата базы данных является состав" ной частью последовательности ее перевода в оперативное состояние. Обнаружив базу данных в формате System 10, сервер немедленно преобразует ее к формату System 11 (признаком осуществле" ния этого процесса является выдача большого количества сообщений после ввода команды online database) и лишь затем сообщает о доступности базы данных для пользователей. Здесь крайне важ" на одна тонкость. После загрузки дампа базы данных System 10 в сервер System 11 можно загружать

SQLServer PSYCH010

Дампы баз данных System 10

PSYCH011 установка новой версии сервера создание баз данных загрузка базы данных загрузка изменений в базе данных преобразование формата базы данных не производится до вывода команды на ее перевод в активное состояние

Рис. 6.3. Загрузка дампа базы данных System 10 и ее преобразование в формат System 11

www.books-shop.com

все необходимые дампы журналов повтора System 10, но лишь до того момента, пока база данных после выдачи команды online database не будет преобразована в формат System 11. Сервер System 11 не обеспечивает применение журналов повтора System 10 к базам данных, находящимся в формате System 11. При использовании дампов базы данных и журналов повтора для поддержания запасного серве ра базы данных либо сервера, находящегося в горячем резерве (standby server), возможны две стра тегии действия команды online database (см. главу 9). Базы данных резервного сервера могут постоянно находиться в автономном режиме, активизируясь только при переключении системы с основного сервера (в случае его отказа) на резервный. Однако если администратор баз данных со вершенно уверен, что ни одному пользователю не удастся подключиться к резервному серверу, то резервную базу данных вполне можно перевести в оперативное состояние сразу после загрузки ее дампа, поскольку загрузка последующих дампов журналов транзакций возможна и в оперативном со стоянии. В любом случае при переходе от System 10 к System 11 приходится вносить необходимые изменения в процесс сопровождения резервного сервера и переключения на него при отказе основ ного сервера.

Формат команд, вызывающих переключение базы данных между автономным и оперативным режимом, и примеры их использования Перед началом загрузки база данных находится в оперативном состоянии 1> sp_helpdb devdb 2> go name db_size owner dbid created status devdb 30.0 MB sa 7 Apr 04, 1996 no options set device_fragments size usage free kbytes ' cOt2dOs4 20.0 MB data only 19344 cOt2dOs6 10.0 MB log only 8720 (return status = 0) 1> select * from sysdatabases where name='devdb' 2> go name dbid suid status version logptr devdb 71 0 1 10278 crdate dumptrdate status2 Apr 4 1996 10:58AM May 21 1996 12:47PM 0 audflags deftabaud defvwaud defpraud 0 0 0 0 (1 row affected) Переход базы данных в автономное состояние после загрузки дампа 1> load database devdb from '/home/dbdump/devdb_52896.dmp' 2> go Backup Server session id is: 16. Use this value when executing the 'sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server. Идентификатор текущего сеанса сервера архивации: 16. Это значение указывается при осуществлении системной хранимой процедуры 'sp_volchanged' после выполнения запросов сервера архивации на смену томов магнитной ленты. Backup Server: 6.28.1.1: Dumpfile name 'devdb9614909246' section number 0001 mounted on disk file '/home/dbdump/devdb_52896.dmp' Backup Server: 4.58.1.1: Database devdb: 14342 kilobytes LOADed. Backup Server: 4.58.1.1: Database devdb: 30726 kilobytes LOADed. Backup Server: 4.58.1.1: Database devdb: 30734 kilobytes LOADed. Backup Server: 3.42.1.1: LOAD is complete (database devdb).

www.books-shop.com

Remirroring the affected portions of the usage map that are on mirrored devices. Восстановление затронутых участков таблицы использования, находящихся на зеркально отображаемых серверных устройствах. Use the ONLINE DATABASE command to bring this database online; SQL Server will not bring it online automatically. Для перевода базы данных в доступное состояние введите команду ONLINE DATABASE; SQL Server не выполняет подобную операцию автоматически.

Запись в журнал регистрации ошибок Выполняемая операция не сопровождается занесением записей в журнал регистрации ошибок сервера.

Изменения в выводе команды sp_helpdb и поле status2 таблицы sysdatabases Обратите внимание на первую строку вывода, где в поле status2 указан режим offline.

1> sp_helpdb devdb 2> go name db_size devdb 30.0 MB device_fragments cOt2dOs4 cOt2dOs6

owner sa size 20.0 MB 10.0 MB

dbid created, status 7 Apr 04, 1996 offline usage free kbytes data only 19344 log only 8720

(return status # 0) 1> select * from sysdatabases where name='devdb' 2> go name dbid suid status version 7 1 1 devdb 0 crdate dumptrdate status2 Apr 4 1996 10:58AM May 21 1996 12:47PM 16 audflags deftabaud defvwaud defpraud 0 О О О

logptr 10278

(1 row affected)

Загрузка последовательности дампов журналов транзакций и возврат базы данных в активное состояние 1> load tran devdb from '/home/dbdump/devdb_52896. trandmp_l' 2> go Backup Server session id is: 19. Use this value when executing the 'sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server. Идентификатор текущего сеанса сервера архивации: 19. Это значение указывается при осуществлении системной хранимой) процедуры 'sp_volchanged' после выполнения запросов сервера архивации на смену томов магнитной ленты. Backup Server: 6.28.1.1: Dumpfile name 'devdb9614909272 ' section number 0001 mounted on disk file '/home/dbdump/devdb_52896.trandmp_l' Backup Server: 4.58.1.1: Database devdb: 1490 kilobytes LOADed. Backup Server: 4.58.1.1: Database devdb: 1498 kilobytes LOADed. Backup Server: 3.42.1.1: LOAD is complete (database devdb). Use the ONLINE DATABASE command to bring this database online; SQL Server will not bring it online automatically. Для перевода базы данных в доступное состояние введите команду ONLINE DATABASE; SQL Server не выполняет подобную операцию автоматически. 1> load tran devdb from '/home/dbdump/devdb_52896.trandmp_2' 2> go Backup Server session id is: 21. Use this value when executing the 'sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server.

www.books-shop.com

Идентификатор текущего сеанса сервера архивации: 21. Это значение указывается при выполнении системной хранимой процедуры 'sp_vol changed' после выполнения запросов сервера архивации на смену томов магнитной ленты. Backup Server: 0001 mounted on Backup Server: Backup Server:

6.28.1.1: disk file 4.58.1.1: 3.42.1.1:

Dumpfile name 'devdb961490927C ' section number ' /home/dbdump/devdb_52896 .trandmp_2 ' Database devdb: 10 kilobytes LOADed. LOAD is complete (database devdb).

1 transactions rolled forward. 1 transactions rolled back.

Use the ONLINE DATABASE command to bring this database online; SQL Server will not bring it online automatically. Для перевода базы данных в доступное состояние введите команду ONLINE DATABASE; SQL Server не выполняет подобную операцию автоматически. 1> online database devdb 2> go Database 'devdb ' is now online. Запись в журнал регистрации ошибок Выполняемая операция не сопровождается занесением записей в журнал регистрации ошибок сервера. Вывод команды sp_helpdb и соответствующая запись таблицы sysdatabases

1> sp_helpdb devdb 2> go name devdb

db_size 30.0 MB

device_fragments cOt2dOs4 cOt2dOs6

owner sa

size 20.0 MB 10.0 MB

dbid 7

created Apr 04, 1996

usage data only log only

free kbytes 19344 10224

(return status = 0 ) 1> select * from sysdatabases where name=' devdb' 2> go name dbid suid status version devdb 7 1 0 1 crdate dumptrdate Apr 4 1996 10:58AM

Audflags 0

logptr 11024 status2

May 28 1996 10:25AM

deftabaud 0

defvwaud 0

status no options set

0

defpraud 0

(1 row affected) Вывод команды online database для преобразования базы данных, восстановленной из дампа System 10, к формату System 11

1> online database cmsdb 2> go Записи, выводимые в журнал регистрации ошибок сервера при преобразовании формата базы данных Database 'cmsdb' appears to be at an older revision than the present installation; SQL Server will assess it, and upgrade it as required.

Формат базы данных 'cmsdb' соответствует версии сервера, более старой, чем установленная; SQL Server проанализирует существующий формат и внесет в него необходимые изменения. Database 'cmsdb': beginning upgrade step: creating table (table sysattributes) [ID 80] Database 'cmsdb': beginning upgrade step: dropping index (table sysreferences, index csysreferences) [ID 1003] Database 'cmsdb': beginning upgrade step: dropping index (table sysreferences, index ncsysreferences) [ID 1004]

www.books-shop.com

Database 'cmsdb': beginning upgrade step: dropping index (table sysreferences, index nc2sysreferences) [ID 1005] Database 'cmsdb': beginning upgrade step: checking database references in sysreferences [ID 1006] (0 rows affected) (0 rows affected) (0 rows affected) Database 'cmsdb': beginning upgrade step: creating index (table sysreferences, index csysreferences) [ID 1007] Database 'cmsdb': beginning upgrade step: creating index (table sysreferences, index ncsysreferences) [ID 1008] Database 'cmsdb': beginning upgrade step: creating index (table sysreferences, index nc2sysreferences) [ID 1009] Database 'cmsdb': beginning upgrade step: changing column name (table sysindexes, column rowpage:maxrowsperpage) [ID 1011] (1 row affected) Database 'cmsdb' beginning upgrade step: creating table (table syspart it ions) [ID 1013] Database 'cmsdb' : beginning upgrade step: noting the present database upgrade level [ID 1015] Database 'cmsdb' is now online Процедура sp_sysmon Введение В состав System 11 (точнее, в SQL Server версии 11.0.1) компания Sybase включила системную храни мую процедуру sp_sysmon, позволяющую выполнять мониторинг производительности SQL Server и распечатывать результаты измерений. Именно процедура sp_sysmon позволяет администратору сер вера определить, насколько эффективными в его системе оказались новые возможности System 11. Фактически sp_sysmon представляет собой набор хранимых процедур, выдающих значительно бо лее подробную и полную информацию о производительности SQL Server, чем ранее применявшаяся для этих целей процедура sp_monitor, до появления System 11 служившая единственным средством анализа производительности сервера. По завершении установки сервера System 11 или обновления сервера System 10 хранимая процедура sp_sysmon уже должна быть установлена в базе данных sybsys temprocs. Общий обзор Процесс использования процедуры sp_sysmon и интерпретации выдаваемой информации см. в гла ве 10. Процедура sp_sysmon поддерживает те же внутренние счетчики сервера, что и SQL Monitor (рис. 6.4); при одновременном применении этих программных продуктов необходимо иметь в виду, что запуск любого из них вызывает сброс счетчиков сервера. В результате одновременный запуск sp_sysmon и SQL Monitor приведет к искажению результатов первой из этих двух запущенных про грамм. Системные таблицы К отличительным особенностям System 11 относятся три новые системные таблицы, название и основное назначение которых приводятся ниже. При работе с информацией, выделенной в эти таб лицы, необходимо внести соответствующие изменения в командные файлы, распечатывающие со держимое системных таблиц. sysattributes • Содержит информацию о конфигурации объектов баз данных • Имеется в базе данных master и всех пользовательских базах данных • Здесь, в частности, указываются параметры именованных кэшбуферов

www.books-shop.com

хранимые процедуры, входящие в состав sp_sysmon

sp_sysmon выдает результаты через интервал времени, установленный пользователем

Рис. 6.4. Совместное использование SQL Monitor и sp.sysmon в System 11 syspartitions • Содержит записи о каждом разделе каждой сегментированной таблицы базы данных • Имеется во всех базах данных syslogshold • Содержит информацию о самой ранней из незавершенных транзакций • Может содержать точку прерывания для сервера тиражирования (Replication Server truncation point) • Имеется только в базе данных master Сегментирование таблиц Обычно таблица базы данных создается сервером в виде единой последовательности страниц дан" ных, содержащих всю хранящуюся в таблице информацию. При добавлении в такую таблицу новых строк они последовательно записываются в конец последней страницы данных. Такие таблицы назы" ваются неупорядоченными (heap table); в частности, это означает, что они не имеют кластеризован" ного индекса. В ситуации, когда серверу не удается модифицировать запись данных с сохранением ее физического места в таблице, команда update обрабатывается сервером как последовательность команд delete и insert, в результате чего модифицированная запись переносится в конец таблицы. Та" ким образом, последняя страница таблицы оказывается весьма активным местом, за доступ к которо" му начинают конкурировать параллельно обрабатываемые запросы (рис, 6.5). Каждый запрос, записывающий строку данных в последнюю страницу таблицы, должен получить блокировку, исклю" чающую доступ других процессов к этой странице на время внесения в нее новой строки. Ожидание блокировки, с одной стороны, защищает другие запросы от получения некорректной или случайной информации, но с другой — ведет к существенному снижению производительности сервера. nsert 1 выполняется

insert 2 ждет insert 3 ждет

Таблица данных прежней версии SQL Server Рис. 6.5. Добавление записей в неупорядоченные таблицы прежних версий SQL Server

www.books-shop.com

Сегментирование таблиц: детали До появления System 11 каждая таблица могла состоять только из одного раздела (последовательно" сти страниц данных). System 11 поддерживает сегментированные таблицы, включающие ряд разде" лов (также называемых сегментами), что позволяет нескольким процессам одновременно добавлять записи в последние страницы данных каждого раздела (рис. 6.6). Сегментирование таблиц повышает производительность сервера, ослабляя конкуренцию между параллельно обрабатываемыми запроса" ми, а также позволяя размещать отдельные разделы таблицы на разных серверных устройствах. В ре" зультате нагрузка ввода/вывода распределяется между несколькими дисковыми накопителями. Таким образом, разделы таблицы могут находиться как на одном, так и на разных серверных устрой" ствах. Сервер самостоятельно определяет, каким именно разделом ему следует воспользоваться при выполнении очередной команды insert, случайным образом распределяя добавляемые строки табли цы между всеми ее разделами. Однако каждая отдельная транзакция вносит свои записи в один и тот же табличный раздел.

insert 1 выполняется

insert 2 выполняется

insert 3 выполняется

Рис. 6.6. Сегментированная таблица System 11 Когда используется сегментирование таблиц Сегментирование таблицы дает положительный эффект, если она используется для последовательно" го накопления записей данных, когда к существующим записям постоянно добавляются новые. В иде" альном случае ее записи после занесения в таблицу должны модифицироваться как можно реже. Сегментирование значительно ускоряет полную загрузку таблицы из файлов данных с помощью ути" литы bср, когда в таблицу загружается последовательность блоков данных. Если обрабатываемая таб" лица разбита на несколько разделов, разные блоки файла данных могут загружаться в нее параллельно — при условии, что исходный файл данных был заранее разделен на несколько. На практике выигрыш от сегментирования получают очень немногие таблицы конкретного при" ложения. Наибольшую пользу приносит сегментирование тех таблиц, в которых постоянно появля" ются новые данные либо часто осуществляется обновление данных, что нельзя выполнить посредством обновления на месте (update"in"place). И в том и в другом случае при отсутствии сег" ментирования одновременно обрабатываемые запросы начинают конкурировать за доступ к послед" ней странице таблицы. Создание сегментированной таблицы Построив таблицу, ее можно разбить на несколько разделов с помощью команды alter table (при усло" вии отсутствия у этой таблицы кластеризованного индекса). Если сегментируемая таблица целиком находится на одном серверном устройстве, то команда alter table выглядит следующим образом: alter table psycho_data partition 6 Сегментированию таблицы не препятствует наличие в ней записей данных, которые автоматиче" ски помещаются в первый раздел. При сегментировании таблицы размеры ее первого раздела зада" ются сервером, при этом учитывается необходимость размещения в нем всех существующих записей. Информацию о структуре разделов таблицы можно получить командой sp_helpartition. Сложнее построить сегментированную таблицу, разделы которой должны размещаться на раз" ных серверных устройствах. С помощью команд sp_addsegment и sp_extendsegment создайте сегмент базы данных, относящийся к нескольким серверным устройствам, либо распространите на несколько таких устройств один из существующих сегментов базы данных. Затем в этом сегменте

www.books-shop.com

постройте таблицу, и только после этого можете разбить ее на разделы. Количество разделов табли" цы и серверных устройств, используемых для их размещения, иногда различается. Для изменения структуры сегментирования таблицы ее необходимо десегментировать командой alter table psycho_data unpartition и затем заново разбить на разделы.

Ограничения Нельзя выполнять сегментирование системных таблиц, временных таблиц, а также таблиц, уже раз" битых на разделы. Сегментированная таблица не может иметь кластеризованный индекс; перед усе" чением либо удалением такой таблицы необходимо произвести ее десегментирование. Если перенос обычной таблицы между сегментами базы данных можно выполнить командой sp_placeobject, то для сегментированной таблицы подобная операция невозможна. Таким образом, использование сег" ментированных таблиц заставит администратора базы данных внести изменения в существующие приложения и командные файлы. К примеру, после сегментирования регулярно усекаемой таблицы в соответствующем командном файле потребуется предусмотреть десегментирование таблицы перед ее усечением с повторным сегментированием по завершении этой операции. К сожалению, хотя сегментирование таблиц обладает целым рядом потенциальных преиму" ществ, его практическая реализация в Sybase SQL Server System 11 оставляет желать лучшего. Практическое использование Вместо сегментирования таблицы можно ограничиться созданием ее кластеризованного индекса с ключевым полем, имеющим случайные значения. Как уже отмечалось, подобный подход также позво" ляет избежать конкуренции за право доступа к последней странице таблицы, поскольку одновремен" но выполняемые запросы, скорее всего, станут обращаться к различным страницам таблицы даже при последовательном добавлении в нее новых записей. Рассмотрим в качестве примера систему при" ема заказов. Хотя каждому новому заказу автоматически присваивается очередной порядковый но" мер, этот заказ попадает на случайно выбираемую страницу таблицы, поскольку все заказы упорядочены по ключевому полю с произвольными случайными значениями. Подобный подход позволяет избежать ограничений, возникающих при сегментировании таблиц, делает излишним контроль за заполнением свободного пространства нескольких разделов таблицы и т.п. Однако здесь серверу приходится постоянно распределять новые записи среди существующих, что требует регулярного перемещения записей таблицы по диску. Перед использованием сегментирования таблицы в промышленно эксплуатируемой базе данных рекомендуем проверить целесообразность такого шага на опытной системе. Сегментирование дей" ствительно способно повысить производительность сервера, но подобный подход удается реализо" вать только в определенных ситуациях. Многие из часто применяемых таблиц вашей системы должны иметь кластеризованные индексы, и их обработка осуществляется отнюдь не одними лишь командами insert.

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

www.books-shop.com

Глава 7

Системные базы данных SOL Server Содержание Системные базы данных База данных sybsystemprocs База данных sybsecurity База данных master База данных master и серверное устройство master Выбор размера серверного устройства master Сегмент журнала транзакций (logsegment) базы данных master Зеркальное отображение устройства master и его название Команда disk init и серверное устройство master Устройство master и серверные устройства, используемые по умолчанию Загрузка дампа базы данных master Перенос устройства master в раздел диска большего размера Очистка информации о конфигурации сервера, содержащейся в базе данных master Системные базы данных и серверные устройства Зеркальное отображение системных баз данных

www.books-shop.com

Системные базы данных Системные базы данных обеспечивают функционирование ядра SQL Server. К их числу, безусловно, относится база данных master, а также две новые системные базы данных, появившиеся в составе SQL Server System 10: sybsystemprocs и sybsecurity. Эти три базы данных и являются системными базами данных SQL Server версий System 10 и System 11. База данных sybsystemprocs В SQL Server версии 4.9.2 все системные хранимые процедуры находились в базе данных master. Они разработаны Sybase и призваны обеспечить администрирование сервера, а также контроль за его ра" ботой. К их числу относятся sp_who , sp_helpdb , sp_conf igure и sp_helpuser . В System 10 ко" личество доступных системных хранимых процедур было увеличено; хранение подобных процедур в базе данных master потребовало бы увеличения объема этой базы данных. Однако база данных master должна всегда находиться на главном серверном устройстве master, ее нельзя расширить на другое серверное устройство. При заполнении устройства master администратор сервера не имеет иного вы" бора, кроме как перенести базу данных master на новое главное устройство большего размера, что представляет собой далеко не тривиальную задачу. Многие компании, эксплуатировавшие SQL Server версии 4.9.2, заблаговременно не побеспокои" лись о выделении серверному устройству master достаточного дискового пространства, обеспечиваю" щего расширение базы данных master в процессе эксплуатации сервера. Любое увеличение базы данных master требовало от администраторов подобных систем ее переноса на новое главное устрой" ство больших размеров. Кроме того, расширение базы данных master в новой версии сервера вполне могло привести к отказу таких компаний от перехода на SQL Server System 10. Стараясь не допус" тить подобного развития событий, компания Sybase приняла решение выделить все системные хра" нимые процедуры в отдельную системную базу данных, получившую название sybsystemprocs. База данных sybsystemprocs не должна располагаться на главном серверном устройстве master , слу" жащем исключительно для размещения одноименной базы данных. Более того, администратор сер" вера вообще не обязан выделять для базы данных sybsystemprocs отдельное серверное устройство. Как и в случае с другими базами данных, следует побеспокоиться о регулярном сохранении дампов базы данных sybsystemprocs, особенно если в нее добавлены нестандартные хранимые процедуры. Базу дан" ных sybsystemprocs всегда можно восстановить с помощью стандартных командных файлов установки сервера, но при этом в ее составе остаются лишь хранимые процедуры, входящие в комплект по" ставки сервера. Конечно, для восстановления нестандартных процедур можно написать специаль" ный командный файл, но намного проще ограничиться включением базы данных sybsystemprocs в стандартную последовательность резервирования баз данных сервера. Мы настоятельно рекомендуем помещать все нестандартные хранимые процедуры именно в базу данных sybsystemprocs, а не в базу данных master , как это приходилось делать администраторам SQL Server версии 4.9.2. Это позволит создавать резервные копии и осуществлять восстановление всех хранимых процедур с помощью одного дампа. Если нестандартная хранимая процедура имеет назва" ние вида sр_<имя_процедуры>, она будет доступна из любой базы данных сервера, в то время как процедуры с другими именами могут вызываться только из самой базы данных sybsystemprocs. База данных sybsecurity SQL Server версий System 10 и System 11 поддерживает разнообразные функции аудита, позволяющие контролировать подключение пользователей к серверу и их работу с базами данных. Для реализации возможностей аудита на сервере должна быть установлена база данных sybsecurity, содержащая ряд таб" лиц, необходимых при работе средств аудита. Проще всего установить базу данных sybsecurity непо" средственно в процессе инсталляции сервера System 11 (либо обновления сервера System 10), но ее установку можно выполнить и позднее. До начала фактического использования средств аудита нали" чие базы данных sybsecurity никак не сказывается на производительности сервера. База данных sybsecurity и поддерживаемые ею средства аудита входят в основной комплект постав" ки SQL Server версий System 10 и System 11. Их не следует отождествлять с Secure SQL Server — это отдельный программный продукт с множеством дополнительных средств обеспечения безопасно" сти, на которых мы не будем останавливаться в этой книге. Средства аудита, входящие в SQL Server System 10 и System 11, подробно описаны в документации на SQL Server. Подобно базе данных sybsystemprocs, база данных sybsecurity не должна размещаться на серверном устройстве master , поэтому нет необходимости выделять для нее отдельное серверное устройство.

www.books-shop.com

В отличие от sybsystemprocs, базу данных sybsecurity нельзя восстановить с помощью стандартных командных файлов установки сервера, поскольку она содержит информацию, имеющую отношение к данному конкретному серверу и операциям, выполняемым пользователями с помощью этого серве" ра. Воссоздание базы данных sybsecurity средствами установки сервера лишь восстановит структур ее: таблиц, но не их содержимое. Поэтому необходимо регулярно сохранять дампы базы данных sybsecu rity для обеспечения возможности восстановления содержащейся в ней информации. База данных master База данных master и связанное с ней серверное устройство master имеют особое значение для сервера Sybase. База данных master и серверное устройство master База данных master содержит служебную информацию, связанную с внутренней структурой сервера: названия и состав всех баз данных сервера, регистрационные записи каждого пользователя сервера и т.д. Именно в базе данных хранятся системные таблицы, относящиеся к серверу в целом. В сервере существует только одна база данных master, ее утрата (либо порча устройства master ) приведет к поте" ре всего сервера, поэтому резервирование базы данных master имеет наивысший приоритет среди процедур обеспечения работоспособности сервера. База данных master всегда находится на серверном устройстве master, создаваемом исключительно программой установки сервера sybinit при установке самого сервера. Создание устройства master является весьма ответственной операцией, требующей внимания и осторожности; ее не стоит вы" полнять без особой надобности. Устройство master нельзя создать командой disk init, используе" мой для создания обычных серверных устройств. База данных master не может быть расширена на другое серверное устройство, отличное от устройства master. Это означает, что при заполнении устройства master нельзя воспользоваться командой alter database для расширения базы данных master на новое серверное устройство. В подобной ситуации необходимо переустановить всю базу данных master на новое устройство master большего размера, т.е. осуществить полную переустановку сервера. Ни один администратор сервера не обрадуется такой неблагодарной работе. Значительно проще следить за тем, чтобы устройство master никогда не переполнялось. Кстати, вы всегда можете создать зеркальную копию устройства master на разделе диска большего размера, после чего удалить первую копию зеркальной пары (сервер автоматически переключится на резервный раздел) и вруч" ную увеличить размер устройства master, указанный в системной таблице sysdevices (см. раздел "Пере" нос устройства master в раздел диска большего размера"). Итак, следует помнить два важных обстоятельства. Во"первых, база данных master не может пре" высить размер одноименного серверного устройства. Создавая при установке сервера с помощью программы sybinit устройство master, вы задаете максимальный размер базы данных master в тот момент, когда указываете объем устройства master. Во"вторых, администратор сервера не должен до" пускать увеличения размеров базы данных master, размещение в ней пользовательских объектов тоже не разрешается. Кроме того, пользователям запрещается устанавливать свои базы данных на устройстве master, которое ни в коем случае не может входить в состав набора серверных устройств, используемых по умолчанию (см. ниже). Все, что должно находиться на устройстве mas" ter, — это база данных master, база данных model и первые 2 Мбайт базы данных tempdb. Выбор размера серверного устройства master Разобравшись во взаимосвязи серверного устройства master с одноименной базой данных, постарай" тесь определить, каким должен быть оптимальный размер этого устройства? Вообще говоря, его объ" ем вряд ли стоит устанавливать более чем 50 Мбайт. В стандартной конфигурации, когда на устройстве master находится 2"Мбайт база данных model и первые 2 Мбайт базы данных tempdb, база данных master сможет использовать все оставшиеся 46 Мбайт свободного пространства на устройстве master. Правда, некоторые приложения требуют установки в базе данных master своих хранимых про" цедур, и наличие большого количества таких процедур вызывает необходимость увеличения базы данных master. Подобная ситуация обычно возникает при использовании приложений независимых поставщиков, поэтому перед установкой таких приложений узнайте у компании"поставщика реаль" ный объем, необходимый для размещения всех хранимых процедур, чтобы учесть его при планирова" нии размеров базы данных master и одноименного устройства. Кроме того, иногда требуется разместить в базе данных model необычно большое число регистрационных записей пользователей

www.books-shop.com

сервера и шаблонов для объектов баз данных, создаваемых этими пользователями. Однако в боль" шинстве типичных ситуаций 50"Мбайт устройства master оказывается более чем достаточно. При планировании размеров устройства master следует учесть и еще одно обстоятельство. Поско" льку базе данных master едва ли потребуется более 50 Мбайт дискового пространства и поскольку каждому физическому разделу диска может быть назначено только одно серверное устройство, нет никакого смысла размещать базу данных master на устройстве размером более 50 Мбайт. Таким обра" зом, при разбиении дискового накопителя на разделы следует предусмотреть раздел объемом в 50 Мбайт для устройства master (а также еще один 50"Мбайт раздел на другом диске для размещения его зеркальной копии). Напомним, что рекомендуемая читателю схема разбиения физических дис" ков серверной машины на разделы, назначаемые серверным устройствам и их зеркальным копиям, включает в себя 50"Мбайт раздел для устройства master (см. главу 8). Однако очень часто при уста" новке сервера все физические диски разбиваются на разделы равного размера, допустим, по неско" лько сотен мегабайт каждый, что приводит к бессмысленной потере большей части области диска, распределенной устройству master (а также равного по размерам дискового пространства, пропада" ющего на его зеркальной копии). Сегмент журнала транзакций (logsegment) базы данных master Еще одной важной особенностью базы данных master является обязательное размещение сегмен" та журнала транзакций этой базы данных на том же серверном устройстве master, что и сама база дан" ных. Для всех остальных баз данных отдельное размещение сегмента журнала транзакций (на специальном устройстве, используемом исключительно для поддержки подобных сегментов баз дан" ных) является практически обязательным требованием: в противном случае сервер не обеспечивает создание отдельных дампов журнала транзакций. При совместном размещении сегмента журнала транзакций базы данных и самой базы данных сервер способен создать только полный дамп базы данных. Разумеется, полный дамп базы данных включает в себя копию журнала транзакций, но со" здание подобного дампа не приводит к очистке журнала транзакций. Таким образом, несмотря на регулярное создание дампов базы данных master, размеры ее журнала транзакций продолжают посто" янно расти, хотя и медленными темпами (поскольку в базу данных master вносится не так много из" менений). Единственный способ уменьшить размеры журнала транзакций базы данных master — создать его дамп в режиме truncate_only (только очистка). Поэтому каждый раз после создания обычного дампа базы данных master необходимо повторно выдавать дамп журнала транзакций с ука" занием режима truncate_only. Заметим, что, поскольку в подобном режиме копирование в дамп содержимого журнала транзакций не происходит, подобная операция не противоречит запрету на создание дампа журнала транзакций на одном серверном устройстве с базой данных. Зеркальное отображение устройства master и его название При обеспечении зеркального резервирования серверного устройства master проявляется еще одна его любопытная особенность. Если в промежуток времени между созданием самого устройства master и началом создания его зеркальной копии попытаться ввести команду sp_helpdevice master, ее вы" вод будет выглядеть весьма странно. Хотя в качестве названия устройства (device_name ) вы дейст" вительно увидите "master ", поле названия физического устройства physical_name будет содержать строку "d_master ", в то время как здесь должно находиться название физического раздела диска, на" значенного устройству master. Стоит лишь создать зеркальную копию устройства master, как эта странность исчезает. При отсутствии зеркальной копии устройства master ни команда sp_helpde" vice, ни соответствующая запись системной таблицы sysdevices не позволяют определить, на каком физическом разделе находится устройство master. В подобной ситуации администратор сервера мо" жет воспользоваться одним из двух Способов: либо проанализировать содержимое журнала регистра" ции ошибок (см. главу 12), либо обратиться к командному файлу RUN_<имя_сервера>, используемому для запуска сервера. Рассмотренная здесь особенность устройства master проявляется и в процессе обновления сервера System 10 (см. главу 13), когда при переходе на сервер System 11 требуется вруч" ную установить в таблице sysdevices реальное название физического раздела, назначенного серверному устройству master. Ниже приводится вывод команды sp_helpdevice master до создания зеркальной копии этого устройства, вывод команды disk mirror и результат повторного вызова команды sp_hel" pdevice master по завершении процесса создания зеркальной копии устройства master.

www.books-shop.com

1> sp_helpdevice master 2> go device_name physical_name master d_master

description special, default disk, physical disk, 32.00 MB status cntrltype device_number low high 3 0 0 0 16383 (1 row affected, return status =0) 1> disk mirror 2> name="master", 3> mirror = '/dev/rdsk/c0t0d0s7', 4> writes=serial 5> go Creating the physical file for the mirror Starting Dynamic Mirroring of 16384 pages for logical device 'master'. 512 pages mirrored... 1024 pages mirrored... 1536 pages mirrored... 2048 pages mirrored... 2560 pages mirrored... 3072 pages mirrored... 3584 pages mirrored... 4096 pages mirrored... 4608 pages mirrored... 5120 pages mirrored... 5632 pages mirrored... 6144 pages mirrored... 6656 pages mirrored... 7168 pages mirrored... The remaining 9216 pages are currently unallocated and will be mir# rored as they are allocated. 1> sp_helpdevice master 2> go device_name physical_name description master /dev/rdsk/cOtOdOs7 special, MIRROR ENABLED, mirror = '/dev/rdsk/c0t0d0s7', serial writes., reads mirrored, default disk,32.00 MB

status cntrltype device_number 739 О О (1 row affected, return status = 0)

low О

high 16383

Команда disk init и серверное устройство master Описанная выше аномалия при определении названия физического раздела диска, распределенного под серверное устройство master, может привести к весьма серьезным последствиям во время иници ализации серверных устройств командой disk init. Как только что говорилось, при отсутствии зерка льного отображения устройства master команда sp.nelpdevice master сообщает правильное название этого устройства (device_name ="master"), но название физического устройства (раздела ди ска) выдает некорректно: physical_name= "d_master". Подобную странность SQL Server необходимо учитывать при инициализации серверных устройств, в первую очередь во время установки сервера при выполнении команды disk init по отношению ко всем физическим разделам дисков, которые будут использоваться в качестве серверных устройств. Дело в том, что к моменту инициализации сер верных устройств программа установки сервера sybinit уже успела создать и заново инициализиро вать серверное устройство master, и вам ни в коем случае не следует пытаться повторно

www.books-shop.com

инициализировать его командой disk init. В подобной ситуации естественно ожидать, что попыт" ка повторной инициализации устройства master должна быть отвергнута сервером с выдачей соответ" ствующего сообщения об ошибке. Действительно, при попытке инициализировать командой disk init раздел диска, уже назначенный одному из серверных устройств, сервер сообщает об ошибке. Однако этот защитный механизм основан на информации, хранящейся в системной таблице sysdevi" ces. Из"за обсуждаемой здесь аномалии в работе сервера таблица sysdevices может содержать неверное название раздела, назначенного устройству master (physical_name = "d_master "). В результате сервер, считая, что устройство master находится в разделе "d_master", без колебаний приступает к выполнению команды disk init, инициализирующей раздел, фактически распреде" ленный устройству master и уже содержащий информацию, жизненно важную для нормального фун" кционирования сервера. Что еще хуже, какое"то время после уничтожения содержимого устройства master сервер продолжает функционировать, а ошибка становится очевидной только при создании в соответствии со стандартной процедурой инсталляции сервера первоначального дампа базы данных master. Здесь мы получаем первые сообщения об ошибках, и попытка выполнить dbcc"проверки базы данных master приводит к выдаче 605 таких сообщений. К этому моменту базы данных master фактически уже не существует: ее следует восстановить из ранее сделанного дампа либо заново вы" полнить установку всего сервера. Таким образом, при каждом вызове команды disk init следует быть предельно внимательным. Обязательно обратитесь к журналу регистрации ошибок сервера и найдите в нем фактическое на" звание раздела диска, назначенного устройству master. Постоянно следите за тем, чтобы не инициа" лизировать этот раздел как при вводе команды disk init вручную, так и при выполнении командных файлов, нередко содержащих большое количество команд disk init. Разумеется, мож" но вручную установить правильное значение соответствующего поля таблицы sysdevices, но опти" мальным решением проблемы станет зеркальное отображение устройства master (позволяющее серверу автоматически исправить собственную ошибку), тем более что после установки сервера вам все равно придется побеспокоиться о создании зеркальной копии устройства master. Устройство master и серверные устройства, используемые по умолчанию В процессе первоначальной инсталляции SQL Server программа установки sybinit не только со" здает серверное устройство master, но и включает его в состав набора устройств сервера. Они испо" льзуются по умолчанию в ситуации, когда при создании базы данных либо ее модификации, требующей распределения дополнительной дисковой памяти, не указывается название определен" ного серверного устройства. При назначении по умолчанию доступные устройства из обсуждаемого набора серверных устройств выбираются в порядке их последовательного заполнения. Таким обра" зом, существование набора используемых по умолчанию устройств сервера (default pool) ставит под угрозу всю структуру распределения сегментов баз данных по серверным устройствам, разработан" ную администратором для повышения производительности сервера и обеспечения лучших гаран" тий целостности данных. Рекомендуем вам убедиться, что ни одно из серверных устройств, включенных в набор используемых по умолчанию, не содержит сегментов важных баз данных, име" ющихся в вашем сервере. Еще лучше вообще не назначать в рассматриваемый набор ни одного сер верного устройства. Разумеется, в подобном случае администратору сервера придется постоянно указывать названия устройств при создании и модификации структуры баз данных, но это же заста" вит администратора внимательнее оценивать влияние выполняемых действий на общую произво" дительность сервера. Важно отметить, что единственным серверным устройством, автоматически, назначаемым в на" бор используемых по умолчанию устройств сервера, является устройство master, которое админист" ратор сервера должен немедленно удалить из этого набора. Все остальные серверные устройства назначаются в этот набор командой sp_diskdefault; она же позволяет удалить устройство master (или любое другое серверное устройство) из набора используемых по умолчанию. Проверить, назна" чено ли в этот набор то или иное серверное устройство, можно с помощью команды sp_helpde" vice. Ниже приводится вывод команд sp_helpdevice и sp_diskde£ault при удалении устройства master из числа устройств сервера, используемых по умолчанию.

www.books-shop.com

1> sp_helpdevice master 2> go device_name physical_name master d_master

description special, default disk, physical disk, 32.00 MB status cntrltype device_number low high 3 0 0 0 16383 1> sp_diskdefault master, defaultoff 2> go (return status = 0) 1> sp_helpdevice master 2> go device_name physical_name description master d_master special, physical disk, 32.00 MB status cntrltype device_number low high 2 0 0 0 16383 (1 row affected, return status = 0)

Загрузка дампа базы данных master Загрузка дампа базы данных master — важный этап процесса восстановления сервера после сбоя (см. главу 9). Перед началом загрузки дампа базы данных master необходимо перевести сервер в однополь" зовательский режим. Поскольку сервер не допускает изменения режимов работы базы данных master, ее нельзя перевести в однопользовательский режим обычными методами, подходящими для всех остальных баз данных сервера. Для перевода сервера в однопользовательский режим здесь необходи" мо вручную внести изменения в командный файл RUN_<имя_сервера> (он находится в директории $SYBASE/install), добавив в команду вызова двоичного выполняемого модуля сервера пара " метр "т. После перезапуска сервер окажется в однопользовательском режиме, обеспечивающем за" грузку базы данных master из дампа. Необходимо помнить, что завершение загрузки дампа базы дан" ных master приводит к немедленному останову сервера. Более того, загрузка дампа базы данных master означает лишь восстановление ее содержимого; сервер не предпринимает никаких попыток восста" новить прочие базы данных или хотя бы открыть другие серверные устройства вплоть до момента его последующего перезапуска.

Перенос устройства master в раздел диска большего размера Необходимо иметь в виду, что перенос устройства master в раздел диска большего размера сопряжен с рядом тонкостей. Подобная операция может потребоваться в связи с переполнением устройства mas" ter (никогда не доводите дело до этого!) либо с плановым переходом на устройство master большего раздела при расширении дискового пространства сервера или при его переносе на новую серверную машину. В большинстве случаев оптимальный размер устройства master составляет около 50 Мбайт, и администратору сервера при первой же возможности следует выделить для этого устройства указан" ное дисковое пространство. Здесь вам, вероятно, придется выполнить стандартную процедуру разби" ения диска на ряд физических разделов (см. главу 8). Реальные проблемы возникают при копировании базы данных master на новое устройство master . Этот процесс выполняется независимо от того, переносится устройство на новый дисковый нако" питель прежней системы или же на совершенно новый компьютер. В случае переноса устройства master на новый диск существующей системы можно зеркально отобразить старое устройство master (находящееся в ранее использовавшемся разделе диска недостаточного размера) на новое устройст" во master, размещенное на новом разделе диска больших размеров. После этого удалите первый из элементов зеркальной пары. При инсталляции сервера на новой системе программа установки авто" матически создаст устройство master , в которое затем можно загрузить дамп прежней базы данных master. Как бы то ни было, база данных master окажется на новом серверном устройстве master желае" мого размера.

www.books-shop.com

УВЫ, и в первом, и во втором случае вы получите не совсем то, что хотели. При увеличении раз" мера устройства master дополнительное дисковое пространство необходимо сделать доступным для расширения объема базы данных master, но в каждом из приведенных выше примеров новая база данных master содержит прежнюю системную таблицу sysdevices со старым значением размера устрой" ства master. Поэтому сервер продолжает считать, что устройство master имеет прежний размер, так что для увеличения доступного серверу объема устройства master необходимо вручную внести изме" нения в соответствующую запись таблицы sysdevices. Предупреждение 1. Прямая модификация содержания системных таблиц не поддерживается продуктами Sybase. Компания не гарантирует, что различные версии сервера будут иметь одинаковую схему системных таблиц, поэтому процедура ручной модификации системных таблиц од" ной версии SQL Server может оказаться не применимой к другой версии сервера. 2. Перед изменением содержания системных таблиц обязательно проконсультируйтесь со службой технической поддержки Sybase. 3. Перед внесением изменений проверьте, имеется ли у вас полный набор дампов. Он необ" ходим для восстановления сервера в случае, если вносимые изменения приведут к наруше" нию его работоспособности. 4. После модификации системных таблиц для активизации внесенных изменений произведите перезапуск сервера. Еще раз подчеркиваем, что рассматриваемая процедура должна выполняться с большой осторож" ностью и только после подробного обсуждения вашей конкретной ситуации со службой техниче" ской поддержки Sybase. Распечатка протокола ручной модификации системной таблицы sysdevices приведена ниже. Подобно любым другим изменениям, вносимым в системные таблицы, рассматри" ваемая операция должна иметь статус транзакции, чтобы исключить модификацию других сервер" ных устройств. Более подробно процесс модификации системных таблиц сервера рассматривается в главе 12. Перед внесением изменений создайте дамп базы данных master и удалите все зеркальные копии устройства master. Еще раз убедитесь, действительно ли новое серверное устройство обладает раз" мерами, которые вы намерены указать в таблице sysdevices. В нашем случае новое устройство master состоит из 25600 2"Кбайт страниц (всего 50 Мбайт). По" скольку первая, или младшая (low), страница базы данных имеет номер 0, то номер последней, или старшей (high), страницы должен равняться 25600 " 1 = 25599. Другими словами, в интервале от О до 25999 содержится ровно 25600 страниц. 1> sp_configure "allow", 1 2> go Configuration option changed. Run the RECONFIGURE command to install. Для активизации измененного значения параметра настройки выполните команду RECONFIGURE. (return status = 0) 1> reconfigure with override 2> go 1> select * from sysdevices where name='master' 2> go low high status cntrltype name phyname mirrorname 0 7904 2 0 master /dev/rdsk/c0t0d0s7 NULL (1 row affected) 1> begin tran psycho 2> go 1> update sysdevices set high=25599 where name='master' 2> go (1 row affected)

1> select * from sysdevices where name='master' 2> go

www.books-shop.com

low high status cntrltype name 0 25599 2 0 master (1 row affected) 1> commit tran psycho 2> go 1> sp_helpdevice master 2> go device_name phys ical_name Master /dev/rdsk/c0t0d0s7

phyname /dev/rdsk/c0t0d0s7

mirrorname NULL

description special,physical disk, 50.00 MB low high 25599

status cntrltype device_number 2 0 0 0 (1 row affected, return status = 0) 1> sp_configure "allow", 0 2> go Configuration option changed. Run the RECONFIGURE command to install. Для активизации измененного значения параметра настройки выполните команду RECONFIGURE, (return status = 0 ) 1> reconfigure 2> go После модификации системных таблиц восстановите зеркальное отображение серверного устройства master на раздел диска, соответствующий новым размерам устройства master. Очистка содержащейся в базе данных master информации о конфигурации сервера Приведенная ниже информация относится только к SQL Server System 11 В System 11 конфигурация SQL Server описывается в конфигурационном файле. Для удаления ин формации о прежней конфигурации сервера достаточно перезапустить сервер без указания имени конфигурационного файла. При этом проследите за тем, чтобы в каталоге $SYBASE не оставалось файла с названием <имя_серзера>.сfg (существующий файл можно просто переименовать). После запуска без конфигурационного файла все параметры настройки сервера автоматически получат значения по умолчанию. В свою очередь, для восстановления предыдущей конфигурации сервера достаточно выполнить его перезапуск с предыдущим конфигурационным файлом либо с файлом <имя_сервера>.bak (см. главу 5). Приведенная ниже информация относится только к SQL Server версий 4,9.2 и System 10 Полная информация о конфигурации сервера хранится в системных таблицах базы данных mas ter. В процессе внесения изменений в конфигурацию сервера с помощью команды sp_conf igure велика вероятность выхода значений некоторых параметров настройки за пределы, реально дости жимые на имеющемся пространстве оперативной памяти серверного компьютера. К числу таких из менений относится, например, увеличение количества пользовательских сеансов (user connections), каждый из которых требует определенного объема памяти серверной машины. В подобной ситуа ции после выполнения команды shutdown сервер не удается запустить заново, а прежнее значение параметра настройки нельзя восстановить обычной командой sp_configure, поскольку для этого требуется сначала запустить сервер. Воспользуйтесь командой buildmaster "r, позволяющей восстановить конфигурацию сервера по умолчанию. Внимание: команду buildmaster следует исполь зовать крайне осторожно, поскольку при неправильном применении весьма реальна угроза уничто жения базы данных master, содержащей всю информацию о вашем сервере. Перед тем, как начать работать с командой buildmaster, обязательно свяжитесь со службой технической поддержки

Sybase.

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Предупреждение 1. Не используйте команду buildmaster технической поддержки Sybase.

без предварительной консультации со службой

2. Перед вызовом команды buildmaster убедитесь в наличии у вас полного набора дампов, позволяющего восстановить сервер в случае, если вносимые изменения приведут к наруше" нию его работоспособности. Следует также ясно отдавать себе отчет в том, что после вызова команды buildmaster "r все параметры настройки сервера (а не только параметр с недопустимым значением) приобретут значе" ния, устанавливаемые по умолчанию, и вся прежняя информация о конфигурации сервера окажется утраченной. Именно указанное обстоятельство заставляет регулярно сохранять дампы системных таблиц сервера (в главе 14 приведен командный файл, выполняющий эту операцию при периодиче" ском запуске через сгоn). После выполнения команды buildmaster "r и установки конфигура" ции по умолчанию администратор сервера должен восстановить его необходимую конфигурацию из хранящихся на диске дампа (или дампов) системных таблиц. Системные базы данных и серверные устройства Итак, база данных master всегда должна находиться на одноименном серверном устройстве. Нельзя размещать на указанном устройстве две другие системные базы данных — sybsystemprocs и sybsecurity, ко" торые вполне могут располагаться вместе с пользовательскими базами данных на любом другом устройстве сервера. В главе 8 даются примеры и детальные рекомендации по размещению системных баз данных при различных конфигурациях дискового пространства системы. Зеркальное отображение системных баз данных Системные базы данных играют критически важную роль в обеспечении нормальной работы SQL Server. Утрата базы данных master эквивалентна утрате всего сервера. Потеря базы данных sybsystemp rocs не приводит к полной потере работоспособности сервера, но исключает использование систем" ных хранимых процедур, что крайне затрудняет работу сервера. Наконец, утрата базы данных sybsecurity приводит к прекращению обработки запросов сервером, но только в том случае, если база данных sybsecurity реально используется при работе средств аудита. Таким образом, системные базы данных должны размещаться на зеркально резервируемых сер" верных устройствах. База данных master всегда помещается на выделенное серверное устройство mas ter, и для его зеркальной копии потребуется отдельный раздел диска (в системе Solaris раздел диска называется секцией — slice). Базы данных sybsystemprocs и sybsecurity вполне можно расположить вместе с пользовательскими базами данных на любом серверном устройстве, однако для предотвращения отказов в работе сервера это устройство должно иметь зеркальную копию.

www.books-shop.com

Глава 8

Внутренняя организация сервера Содержание Особенности различных версий SQL Server Обзор процесса установки сервера Дисковые накопители Стандартная схема разбиения дисков Дисковые разделы в операционных системах фирмы Sun Разбиение дисков различного размера Форматированные и неформатированные разделы дисков Логические дисковые устройства SQL Server Разбиение дисков на разделы Контроллеры дисков Распределение компонентов баз данных по дискам и дисковым контроллерам Инициализация серверных устройств Сегменты баз данных Размещение журналов транзакций Зеркальное резервирование серверных устройств Выбор конфигурации устройств и сегментов сервера Почему не следует торопиться расширять пространство базы данных

www.books-shop.com

Введение Администратор баз данных должен хорошо понимать процесс установки сервера на серверном компьютере с операционной системой UNIX. От принятых во время установки сервера решений за" висит то, насколько легким окажется впоследствии создание новых баз данных и расширение сущест" вующих. Различные аспекты взаимосвязей между сервером, контроллерами дисков, дисковыми накопителями и другими компонентами серверной системы обсуждаются во многих разделах книги, в этой же главе систематизируются вопросы их взаимодействия. Некоторые администраторы баз данных не считают необходимым разбираться в особенностях поддержки физических дисков и дисковых разделов средствами операционной системы. Подобная точка зрения ошибочна: следует четко представлять себе, как операционная система обеспечивает работу серверных устройств SQL Server. С ростом базы данных рано или поздно придется админист" рировать серверы, целиком занимающие серверные машины и использующие практически все про" странство дисков, подключенных к системе. Ясное понимание механизмов взаимодействия сервера с аппаратным и программным обеспечением серверного компьютера позволяет наращивать возмож" ности системы по мере увеличения объемов поддерживаемых баз данных. Кроме того, продуманное распределение сегментов баз данных по физическим дисковым накопителям обеспечивает сохране" ние производительности сервера на уровне, адекватном требованиям обработки баз данных все уве" личивающихся размеров. В настоящей главе подробно обсуждаются важнейшие принципы внутренней организации сервера. Особенности различных версий SQL Server Вопросы, рассматриваемые в данной главе, одинаково важны для всех версий SQL Server. Однако при работе можно столкнуться с двумя особенностями, которые определяются используемой версией сервера. Первая из них связана с зеркальным отображением системных баз данных. В SQL Server вер" сий System 10 и System 11 в число системных баз данных, помимо базы данных master, входят базы данных sybsystemprocs и sybsecurity. Как отмечалось в предыдущей главе, база данных sybsystemprocs исполь" зуется в серверах System 10 и 11 для размещения системных хранимых процедур, в то время как база данных sybsecurity требуется только при реализации функций аудита, впервые появившихся в составе System 10. Вторая особенность касается взаимодействия сервера System 11 и операционной системы (ОС) компьютеров фирмы Sun. Общее описание системных баз данных приведено в главе 7; здесь же рассматриваются основные принципы размещения этих баз данных на серверных устройствах при различных конфигурациях физических дисковых накопителей. SQL Server 4.9.2 В SQL Server версии 4.9.2 только одна системная база данных master должна быть размещена на сер" верном устройстве master. Администратору необходимо предусмотреть зеркальное резервирование этого устройства. SQL Server System 10 Весь материал данной главы в полной мере применим к System 10, где в составе сервера появились две новые базы данных — sybsystemprocs и sybsecurity. Помимо обязательного зеркального резервирова" ния устройства master, требуется обеспечить зеркальное резервирование серверных устройств, испо" льзуемых для размещения баз данных sybsystemprocs и sybsecurity (последняя из них может и не быть установлена на вашем сервере). В System 10 команды create database и alter database обладают новым параметром "with override", позволяющим при создании базы данных размещать сегмент журнала повтора на одном серверном устройстве с остальными сегментами этой базы данных. При этом сохраняется возмож" ность записи отдельных дампов журнала повтора. Хотя в определенных ситуация такая возможность действительно оказывается полезной, в целом мы рекомендуем придерживаться традиционной схе" мы размещения журналов повтора на отдельном серверном устройстве. Sybase советует использо" вать параметр "with override" только при серьезной нехватке дискового пространства и восстановлении работоспособности сервера после тяжелых сбоев.

www.books-shop.com

SQL Server System 11 System 11 включает в себя все перечисленные выше возможности, появившиеся в составе System 10. Однако если версии 4.9.2 и System 10 сервера Sybase поддерживали обе операционные системы фир" мы Sun — SunOS и Solaris, то SQL Server System 11 работает только в среде Solaris. Хотя такая особенность System 11 проявляется лишь на платформах Sun, она служит хорошим стимулом для того, чтобы перед обновлением сервера убедиться в совместимости его новой версии с существующим аппаратным и программным обеспечением. Одновременное обновление сервера и операционной системы представляет собой намного более громоздкую операцию, чем обновление одного сервера. Будет крайне печально, если в последнюю минуту выяснится, что, помимо обновле" ния сервера, придется устанавливать и новую операционную систему. По этой же причине, прежде чем обновлять версию сервера основной информационной системы, находящейся в промышленной эксплуатации, следует предварительно проверить работоспособность новой версии на тестовом компьютере. Это позволит заблаговременно выявить все подводные камни. Обзор процесса установки сервера Администратор базы данных, стремясь максимально упростить структуру каждого сервера системы, должен использовать для всех серверов единую простую схему выбора номеров портов и названий серверных устройств. Нумерация портов серверной машины При установке SQL Server и сопутствующих программных продуктов необходимо определить номера портов, назначаемых устанавливаемым программам и указываемых в файле интерфейсов при описа" нии каждого сервера (использование файла интерфейсов см. в главе 12). Воспользовавшись при кон" фигурировании каждого серверного компьютера стандартным набором номеров портов, администратор базы данных значительно облегчит себе работу по сопровождению обслуживаемой информационной системы. При установке каждого нового сервера не придется заново выбирать но" мера используемых портов. Просматривая журнал регистрации ошибок сервера, вы сможете немед" ленно определить, подключен он к стандартному порту или кто"то (будем думать, другой администратор) запустил сервер с неправильным номером порта, успешно изолировав его от доступа пользователей. Применение стандартного набора номеров портов точно так же облегчает и конт" роль за правильностью файлов интерфейсов пользовательских машин. Таким образом, стандартный набор номеров портов (вообще говоря, зависящий от поддерживаемой версии операционной систе" мы) позволяет значительно сократить затраты времени на создание и сопровождение файлов интер" фейсов. Установив стандартное распределение портов, сообщите их список системному администратору серверного компьютера для того, чтобы тот не назначил эти порты другому систем" ному процессу. Пример стандартного распределения номеров портов приведен в таблице 8.1. Таблица 8.1. Стандартная схема назначения портов серверной машины _ Компонент

сервера

или

сопутствующего

программного

продукта

Главный процесс SQL Server и поисковые ядра сервера Консоль

SQL

Server

(только

Monitor

для

версии

4.9.2)

Диспетчер(ы)

_

тиражирования передачи

Сервер(ы) Open Server

транзакций

порта

_

_

5002

_

5005 _

5010

Диспетчер лицензий пакета SQL BackTrack компании DataToote Сервер

Номер

5001

Сервер архивации (отсутствует в версии 4.9.2) SQL

_

5050 _

сервера

_

тиражирования

5070 _

5071,

5072,

_ 5073.

...

_

5100, 5101, 5102, ...

www.books-shop.com

Названия серверных устройств Администратору сервера следует также придерживаться определенной схемы присвоения названий логическим устройствам сервера, в число которых входят дисковые накопители и устройства записи на магнитную ленту. Названия дисковых устройств лучше всего соотносить с названием физического диска, использу" емого для размещения устройства, и номера соответствующего раздела этого диска. При возникно" вении ошибок на каком"либо из серверных устройств подобная схема поможет быстрее найти дисковый накопитель, вышедший из строя, и сопоставить сообщения из журнала регистрации оши" бок сервера с записями в системном журнале серверного компьютера. Наконец, при определении физического размера раздела диска все равно потребуется указывать название этого диска, так что тем более имеет смысл взять его за основу при выборе названий логических серверных устройств. Рекомендуем остановиться на самой простой схеме названий логических устройств сервера, ког" да серверное устройство, находящееся в разделе 7 дискового накопителя /dev/rdsk/c0t0d0, полу" чает имя c0t0d0s7. Дисковые накопители Дисковые накопители серверной машины используются для хранения всех компонентов SQL Server — от двоичных выполняемых файлов самого сервера до информации, содержащейся в поддер" живаемых этим сервером базах данных. Под термином "диск" мы имеем в виду физический дисковый накопитель (иногда его называют дисководом, или шпинделем — spindle), подключенный к одному из контроллеров дисков серверной машины (рис. 8.1). В операционной системе серверного компьютера для дисковых накопителей используются имена вида cOtOdO — cOtOd4. Каждый физический диск сер" верной машины разбивается на несколько разделов (рис. 8.2). Максимально разрешенное число раз" делов, имеющихся на одном диске, зависит от конкретной операционной системы. Так, в системе Solaris на диске может быть восемь разделов с номерами от 0 до 7; отметим, что в системной докумен" тации Solaris раздел диска называется секцией (slice). Для доступа к каждому разделу диска операци" онная система использует специальный файл, входящий в файловую структуру серверной машины. Так, файл с именем /dev/rdsk/cOtOdOs3 соответствует разделу (секции) номер 3 диска cOtOdO. Бук" ва "r" в названии каталога rdsk указывает на то, что данный раздел является небуферизованным (raw partition) и доступ к нему должен осуществляться в побайтовом режиме, когда вся информация немед" ленно записывается на диск без предварительной буферизации. Именно так должна производиться запись во все серверные устройства SQL Server. Каждый раздел диска также имеет еще одно имя

Рис. 8.1. Дисковые накопители и контроллеры дисков серверной машины

www.books-shop.com

Рис. 8.2. Разделы физических дисков в операционной системе Solaris (в данном случае оно выглядит как /dev/dsk/c0t0d0s3), используемое при доступе к диску в блоко" вом режиме, непригодном для работы с серверными устройствами. Поскольку в блоковом режиме за" писываемые данные сначала накапливаются в системном буфере, при сбое отдельного диска или всей серверной машины не записанное на диск содержимое буфера оказывается утраченным. Итак, режи" мом доступа к разделу 3 физического диска c0t0d0 управляют специальные системные файлы с имена" ми /dev/rdsk/cOtOdOs3 и /dev/dsk/cOtOdOs3. В каталоге /dev/rdsk дается полный набор системных файлов, заранее заготовленных для доступа ко всем восьми возможным разделам каждого физического диска серверной машины. Это, впрочем, не означает, что на каждом отдельном диске обязательно должны присутствовать все разделы: их реальное число и индивидуальные размеры определяются при разбиении физического диска на разделы.

Стандартная схема разбиения дисков При разбиении каждого диска серверной машины на разделы следует придерживаться единой схемы, которая предварительно должна быть согласована с системным администратором, контролирующим работу машины. Несмотря на возникающее порой желание использовать для каждой серверной ма" шины индивидуальную схему разбиения дисков, лучше всего иметь схему, соответствующую назначе" нию данного конкретного сервера и конфигурации имеющихся аппаратных средств: единый универсальный стандарт разбиения дисков значительно облегчает сопровождение системы в целом. На первом этапе необходимо выделить диски, на которых будет размещаться файловая система сер" верного компьютера, и разбить их на разделы в соответствии с принятой стандартной конфигура" цией файловых систем имеющихся серверных машин. Затем все оставшиеся диски, предназначенные для сервера, разбиваются по очень простой схеме (таблица 8.2, рис. 8.3).

Таблица 8.2. Стандартная схема разбиения диска Раздел 0 Раздел 2

Раздел 7 Разделы 1, 3, 4, 5, 6

www.books-shop.com

Рис. 8.3. Стандартная схема разбиения диска на разделы для серверных устройств и их зеркальных копий Раздел О Нельзя допускать, чтобы нулевой раздел диска, занимающий цилиндр 0 и содержащий метку тома, был доступен серверу. Выделив нулевой цилиндр в отдельный раздел и исключив его из доступного серверу дискового пространства, администратор базы данных избавит себя от серьезных потенциаль" ных неприятностей.

Раздел 2 Раздел 2 обозначает весь диск и в явной форме также не распределяется серверу, поскольку для обес" печения безопасности данных и повышения производительности сервера на диске должно быть не" сколько разделов. Раздел 7 Раздел 7 должен занимать область не слишком большого размера (например, 30 или 50 Мбайт). В каж" дом сервере обязательно найдется определенное число сравнительно коротких баз данных, которые очень удобно помещать на небольших разделах дисков. Несколько подобных разделов потребуются для размещения системных баз данных master, sybsystemprocs и sybsecurity и их зеркальных копий. Хотя даже после создания зеркальных копий всех используемых коротких дисковых разделов в вашем рас" поряжении, вероятно, все равно останется несколько таких разделов, благодаря их небольшим разме" рам это не приведет к заметным потерям дискового пространства. В то же время включение одного короткого раздела в стандартную схему разбиения каждого диска значительно упростит процесс уста" новки и сопровождения сервера. Разделы 1, 3, 4, 5, 6 Все остальные разделы диска имеют равные размеры и занимают по 1/5 пространства диска, остав" шегося после создания разделов 0 и 7. Ваш системный администратор очень скоро убедится в том что стандартная схема разбиения ди" сков намного облегчает их установку и последующий контроль за использованием дискового про" странства. При возникновении сбоев в системе сразу же попросите системного администратора проверить разделы того или иного диска — не тратьте время на попытки вспомнить, как именно был (или должен был быть) разбит на разделы каждый конкретный диск. Да и другие администрато" ры баз данных, начинающие работать вместе с вами, единую схему дисковых разделов освоят быст" рее. Кроме того, подобная схема значительно сократит внушительный объем документации, которую администратор должен вести по своему серверу. Дисковые разделы в операционных системах компьютеров фирмы Sun При эксплуатации SQL Server на компьютерах фирмы Sun необходимо учитывать, какая операцион" ная система Sun поддерживается данной версией сервера SQL Server 4.9.2 и System 10 способны рабо" тать и в SunOS, и в Solaris, но версия SQL Server System 11 совместима только с системой Solaris.

www.books-shop.com

В системе SunOS разделы дисков обозначаются буквами от а до h, в то время как в Solaris разделы называются секциями с номерами от 0 до 7. В рассматриваемых системах также различается структу" ра управляющих файлов, служащих для доступа к разделам дисков. Например, если в системе Solaris доступ к секции 2 физического диска cOtldO осуществляется через файл /dev/rdsk/c0tld0s2, то в SunOS название файла, соответствующего дисковому разделу "с", будет иметь вид /dev/rsd4c. Между буквенными обозначениями разделов SunOS и номерами секций Solaris существует взаимно однозначное соответствие (таблица 8.3). В оставшейся части данной главы будут использоваться обозначения, принятые в системе Solaris. Читателям, работающим с SQL Server в среде SunOS, необ" ходимо заменить номера секций на буквенные обозначения соответствующих разделов. Таблица 8.3. Соответствие между разделами дисков SunOS и дисковыми секциями Solaris Буквенное обозначение дискового раздела (partition) в SunOS

Номер дисковой секции (slice) Solaris

а

0

b

1

с

2

d

3

е

4

f

5

g h

6 7

Разбиение дисков различного размера Стандартная схема разделов дисков, принятая в данной главе, предназначена для дисков емкостью 4,2 Гбайт. Такие диски разбиваются на пять 800"Мбайт разделов с номерами 1, 3 — 6 и один 88"Мбайт раздел с номером 7. При работе с 2,1 Гбайт дисками для раздела 7 разумно выделить 30 Мбайт, после чего на каждый из разделов 1,3 — 6 останется примерно по 400 Мбайт. Таким образом, и 4,2", и 2,1 Гбайт диски должны иметь по одному небольшому разделу (номер 7). В первую очередь эти разде" лы предназначаются для устройства master и его зеркальной копии. При наличии достаточного числа дисков на свободных разделах по 30 или 88 Мбайт удобно размещать файловую структуру операцион" ной системы или небольшие базы данных (например, появившиеся в составе SQL Server System 10/11 базы данных sybsystemprocs и sybsecurity, а также их зеркальные копии). Форматированные и неформатированные разделы дисков Каждый раздел физического диска может быть отформатирован для включения в файловую структу" ру операционной системы либо напрямую использован SQL Server в качестве небуферизованного ди" скового раздела (raw partition). Сервер способен размещать свои базы данных как в файлах операционной системы, так и в неформатированных разделах. Поскольку файловая структура нахо" дится под управлением операционной системы, любая запись данных в файл связана с процессом их буферизации. Для повышения производительности операционная система накапливает записывае" мые данные в системном буфере, по заполнении которого все находящиеся там данные одновремен" но сбрасываются на диск. Буферизация позволяет существенно повысить производительность сервера посредством назначения логических устройств сервера файлам операционной системы. В то же время она несет с собой определенную угрозу целостности данных. Схема обеспечения целостно" сти данных в SQL Server основана на понятии фиксации транзакций; при этом если запись результа" тов зафиксированной транзакции осуществляется не на диск, а в буфер операционной системы, то существует опасность нарушения целостности данных (см. главу 9). Итак, сервер предполагает, что все операции записи на диск выполняются немедленно без ка" кой"либо буферизации. Именно так это и происходит при работе сервера с небуферизованными раз" делами физического диска. Наоборот, в случае использования буферизованной записи в файлы

www.books-shop.com

операционной системы сервер будет считать результаты зафиксированных транзакций уже записан" ными на диске, хотя фактически они все еще будут находиться в системных буферах. Системный сбой в промежуток времени между помещением результатов зафиксированных транзакций в буфер операционной системы и сбросом содержимого буфера из оперативной памяти серверной машины на диск приводит к их утрате. Если, даже несмотря на частичную утрату информации о зафиксиро" ванных транзакциях, и удастся восстановить сервер, результаты этих транзакций все равно будут считаться записанными на диск, что нарушит непротиворечивость информации в пострадавших ба" зах данных. Таким образом, файлы из стандартной файловой структуры операционной системы не должны использоваться в качестве логических серверных устройств, за исключением тех случаев, когда со" хранность информации отдельных баз данных не имеет особого значения. Впечатляющим приме" ром здесь может служить база данных tempdb, восстановление которой в любом случае не поддерживается сервером (см. главу 9), что позволяет для повышения производительности размес" тить ее на серверном устройстве, которому назначен файл операционной системы. Отметим, что неформатированные разделы дисков полностью игнорируются операционной сис" темой, которая лишь проверяет наличие у пользовательских процессов полномочий на доступ к этим разделам. Логические дисковые устройства SQL Server Успешное усвоение материала этой и последующих глав невозможно без знания терминологии, свя" занной с дисками и дисковыми устройствами. Физический диск (также называемый дисковым нако" пителем, или дисководом) может одновременно содержать несколько логических дисковых устройств SQL Server (ниже будем называть их серверными устройствами, или просто устройства" ми), а также отдельные части файловой структуры операционной системы. Разделы физического диска могут назначаться одному из логических дисковых устройств сервера либо использоваться для размещения файлов операционной системы. С точки зрения сервера раздел физического диска выглядит как логическое серверное устройство. Его мы также будем называть логическим диском сервера, подчеркивая тем самым, что речь идет об одном из известных серверу дисковых устройств, которому соответствует определенная область диска. Наоборот, под физическим диском подразумевается реальный дисковый накопитель или один из его разделов. Отметим, что термин "серверное устройство", как правило, применяется по отношению к серверным устройствам, нахо" дящимся на дисковых накопителях; накопители на магнитной ленте и файлы операционной систе" мы, используемые для вывода дампов баз данных и журналов транзакций, именуются серверными устройствами вывода дампов. Таким образом, SQL Server, не имеющий информации о фактической конфигурации физических дисковых накопителей, способен работать с разделами физических дисков только после их объявле" ния серверу в качестве одного из логических дисковых устройств (рис. 8.4). Серверу также неизвест" ны фактические размеры разделов физического диска; размеры логических устройств указываются серверу при их создании и задаются в виде числа стандартных 2"Кбайт страниц (обычно такая стра" ница действительно содержит 2048 байт, что, однако, верно не для всех платформ, поддерживаемых SQL Server). Администратор может присвоить логическому дисковому устройству сервера любое ко" личество страниц, способное поместиться в выбранном физическом разделе диска. Но каждый раз" дел диска назначается только одному серверному устройству, поэтому создание логического устройства, занимающего назначенный ему раздел диска не полностью, эквивалентно потере всего оставшегося пространства дискового раздела. Этого можно избежать одним из двух способов: либо создать во всех доступных разделах логические устройства максимально возможных размеров, либо предварительно определить требуемый размер создаваемого логического устройства, после чего за" ново разбить диск на разделы необходимого объема. Еще раз подчеркнем, что раздел диска не мо" жет одновременно использоваться и серверным устройством, и файловой структурой операционной системы либо несколькими серверными устройствами.

Разбиение дисков на разделы Администратору сервера совместно с системным администратором серверной машины следует уточ" нить структуру разделов дисков, поддерживаемую используемой версией операционной системы. Ра" зумеется, системный администратор может самостоятельно создать необходимые разделы дисков; однако он не всегда хорошо понимает, какая структура разделов является оптимальной для SQL Ser" ver. Вне зависимости от того, кто именно будет заниматься созданием разделов дисков,

www.books-shop.com

физический диск (дисковод) разделы '1', '3', '4' по 400 Мбайт каждый раздел '5' размером 800 Мбайт 1) создается серверное устройство c0t0d0s1 размером 200 Мбайт 2) зеркальной копии серверного устройства c0t0d0s1 назначается раздел /dev/rdsk/c0t0d0s3 3) 800+Мбайт раздел c0t0d0s5 форматируется и распределяется файловой системе /logdump Со стороны SQL Server: на диске находится 200+Мбайт серверное устройство cOtOdOsI с зеркальной копией на разделе c0t0d0s3 Примечание. Оставшиеся 200 Мбайт физического раздела c0t0d0s1, которые не были распределены одноименному серверному устройству, недоступны для использования. Иногда некоторые разделы диска вообще не задействованы ни сервером, ни операционной системой; в данном примере это разделы c0t0d0s0, s6 и s7.

Со стороны операционной системы серверной машины на диске находятся: три небуферизованных раздела (C0t0d0s1,c0t0d0s3 и c0t0d0s4), каждый из которых имеет размер 400 Мбайт и не используется какими+либо элементами файловой структуры форматированный раздел c0t0d0s5, распределенный файловой системе /logdump и имеющий размер 800 Мбайт

Рис. 8.4. Серверные устройства администратор сервера должен проследить за тем, чтобы их структура наилучшим образом соответ" ствовала требованиям сервера. Хотя здесь мы рассмотрим особенности разбиения дисков в системе Solaris 2.x, данные рассуждения в полной мере применимы и к другим разновидностям операционной системы UNIX, предлагаемым различными фирмами"производителями. Разделы дисков в системе Solaris В операционной системе Solaris каждый диск может иметь до восьми разделов с номерами от 0 до 7. Каждому такому разделу, за исключением раздела 2, может быть выделена определенная область фи" зического диска. Хотя операционная система не препятствует созданию взаимно перекрывающихся разделов, следует избегать подобной практики, поскольку назначение хотя бы одного из перекрываю" щихся разделов какому"либо из серверных устройств может привести к катастрофическим последст" виям. Заполнение первого раздела выше уровня, за которым новые данные будут записываться в область, перекрываемую вторым разделом, приведет к утрате информации, содержащейся во втором разделе. В ситуации, когда и второй раздел используется для размещения серверного устройства, это устройство будет уничтожено. Допустимые размеры разделов Каждому разделу может соответствовать область физического диска практически любого размера. Хотя никто не запрещает создать раздел, целиком занимающий все пространство диска, все же удоб" нее разбивать диски на ряд разделов, необходимых для поддержки нескольких логических дисковых устройств сервера и их зеркальных копий. При подключении к компьютеру нового диска все его про" странство автоматически распределяется операционной системой разделу 2. Это дает возможность быстро узнать полный объем физического диска с помощью системной команды prtvtoc, выдающей размеры каждого раздела диска. Кроме того, в некоторых случаях все же возникает необходимость выделить файловой системе целый диск в виде единого раздела. К примеру, при записи дампов баз данных на диск серверу необходимо, чтобы размеры используемой области файловой системы были достаточны для размещения создаваемых дампов. Для этой области иногда требуется отдельный фи" зический диск.

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Распределение дискового пространства разделам диска Выделение разделу диска определенной области дискового пространства осуществляется системной командой format. Если у вас недостаточно опыта работы с командой format (либо отсутствуют со" ответствующие системные полномочия), указанную операцию рекомендуется выполнять совместно с системным администратором серверной машины: некорректное применение команды format гро" зит вывести из строя весь сервер. Каждому отдельному разделу диска может быть поставлена в соот" ветствие практически любая область дискового пространства. Однако на практике не следует злоупотреблять этой возможностью, поскольку запись в один из перекрывающихся разделов способ" на привести к утрате информации, содержащейся в другом разделе. Кроме того, особую осторож" ность необходимо соблюдать при распределении нулевого цилиндра диска одному из разделов. Внимательно проследите за тем, чтобы нулевой цилиндр ни одного из дисков серверной машины не оказался распределенным небуферизованному разделу, назначенному одному из серверных устройств (либо зеркальной копии такого устройства). Рассматриваемая в следующих разделах главы стандарт" ная схема разбиения диска позволит избежать подобной ошибки. Приведем пример того, как не следует разбивать диск на разделы: Last * First Sector Sector * Partition Tag Flags Sector Count 1639439 (1) 1 3 01 0 1639440 8380799 2 5 01 0 8380800 3278879 (2) 3 0 00 1639440 1639440 4918319 4 0 00 3278880 1639440 6557759 5 0 00 4918320 1639440 8197199 6 4 00 6557760 1639440 8380799 (3) 7 0 00 8197200 183600 Mount Directory (1) #> includes cylinder 0 # don't use for raw! раздел 1 нельзя использовать в качестве неформатированного раздела: в нем содержится цилиндр 0! (2) "> 800.51 Mb 800 Mb = 409600 2К pages (3) "> 89.65 Mb 89 Mb = 45568 2K pages В приведенной выше распечатке обратите внимание на то, что раздел (или секция) 1 включает в себя нулевой цилиндр диска. Если этот раздел окажется назначенным одному из серверных устройств, то после первой же перезагрузки серверной машины весь диск станет недоступен. Ни один из нулевых цилиндров дисков вашей серверной машины ни в коем случае не должен оказаться в неформатированном разделе, непосредственно распределенном серверу. Если все же это произош" ло, не останавливайте серверную машину до создания зеркальной или резервной копии данных, на" ходящихся на соответствующем серверном устройстве. Цилиндр О Цилиндр 0 представляет собой самый первый цилиндр физического диска, на котором записана крайне важная информация об объеме диска, частоте его вращения и т.д. Цилиндр 0 можно включить в состав форматированного раздела диска, используемого для размещения файловой структуры опе" рационной системы. Однако этот цилиндр ни в коем случае не может быть частью небуферизованно" го (raw) раздела, распределенного серверу в качестве одного из логических дисковых устройств, поскольку при первом же запуске сервером команды disk init нулевой цилиндр будет перезапи" сан, а хранившаяся в нем информация окажется утраченной. Подобная ошибка внешне никак не про" является вплоть до того момента, когда уже слишком поздно что"либо предпринимать. Это еще более усугубляет ситуацию. Дело в том, что содержимое нулевого цилиндра каждого диска читается опера" ционной системой только в момент загрузки серверного компьютера, поэтому после утраты инфор" мации сервер будет совершенно нормально функционировать вплоть до следующей перезагрузки компьютера, записывая, возможно, на пострадавший диск важную информацию. После перезагрузки серверной машины операционная система не сможет распознать этот диск, поскольку ей не удастся найти в цилиндре 0 пострадавшего диска информацию, необходимую для его успешной идентифика" ции. В результате все находившиеся на диске серверные устройства окажутся недоступными вплоть до повторной записи в нулевой цилиндр корректной метки тома. К сожалению, восстановление мет" ки тома нарушит структуру информации, записанной в этот же цилиндр сервером, и это приведет к

www.books-shop.com

утрате серверного устройства, включавшего в себя нулевой цилиндр. Заметим, что восстановить кор" ректную метку тома сравнительно легко (правда, если в вашей системе имеется хотя бы еще один идентичный диск). Здесь системному администратору серверной машины не составит особого труда переписать в цилиндр 0 пострадавшего диска соответствующую информацию, сохранившуюся в нуле" вом цилиндре аналогичного диска. Если же у вас не сохранилось правильной метки тома, необходи" мую для ее восстановления информацию придется запросить у фирмы"изготовителя диска. Скорее всего, вам удастся успешно восстановить метку тома, однако процесс может затянуться надолго и все это время пострадавший диск (и даже сам сервер, если его работоспособность существенно зависела от этого диска) будет недоступен. Если серверное устройство, в которое по ошибке был включен нулевой цилиндр физического дис" ка, содержало пользовательские базы данных, эти базы данных можно восстановить с магнитной лен" ты на том же самом серверном устройстве (разумеется, после восстановления метки тома, выделения цилиндра 0 в отдельный раздел и повторной инициализации прежнего раздела командой disk init). Это возможно при условии, что сократившегося пространства раздела хватит для размещения восста" навливаемых баз данных. Кроме того, восстановление приведет к утрате результатов всех транзакций, выполненных после создания последнего дампа журнала транзакций либо полного дампа базы дан" ных. В случае же, если пострадавший раздел диска содержал серверное устройство master, результа" том ошибки становится полная потеря сервера. Необходимо также из соответствующего раздела диска удалить цилиндр 0, повторно установить в этом разделе устройство master (что эквивалентно полной переустановке сервера), а затем восстановить из резервного дампа базу данных master. Для это" го требуется, чтобы размеры нового устройства master оказались достаточными для загрузки дампа базы данных master. В рассматриваемом случае полностью восстановить все пользовательские базы данных удастся только в том случае, если имеющийся дамп базы данных master отражает текущее со" стояние системных таблиц сервера (т.е. содержит описание всех пользовательских баз данных и сер" верных устройств). Любые изменения, сделанные в системных таблицах после создания последнего имеющегося дампа базы данных master, придется повторно вносить вручную, если, конечно, у админи" стратора сервера сохранилась вся информация о них. Здесь самое время еще раз вспомнить о необхо" димости регулярного создания резервных дампов системных таблиц (например, с помощью командного файла dump_systables, рассматриваемого в главе 14). Безусловно, избежать описанных проблем позволяет и поддержание работоспособности зеркаль" ной копии серверного устройства master. В заключение еще раз подчеркнем, что опасность утраты метки тома возникает только при включении нулевого цилиндра физического диска в состав нефор" матированного дискового раздела, назначаемого одному из серверных устройств. Нет никаких при" чин, препятствующих включению цилиндра 0 в раздел, используемый файловой системой серверной машины. Стандартная схема разбиения дисков После того как вы осознали всю важность нулевого цилиндра физического диска, можно приступить к разработке простой стандартной схемы разбиения диска на разделы, позволяющей избежать слу" чайной перезаписи метки тома (рис. 8.5). Главное здесь — выделить цилиндр 0 в отдельный раздел с номером 0 на всех физических дисках, используемых для размещения серверных устройств, и раздел '2' = весь диск раздел '0' = цилиндр О

каждый из разделов '1', '3', 'Ч', '5', '6' занимает по 1/5 пространства диска, оставшегося после создания разделов '0' и '7'

раздел Т = 50 Мбайт Рис. 8.5. Стандартная схема разделов физических дисков, используемых для размещения серверных устройств и их зеркальных копий

www.books-shop.com

проследить за тем, чтобы нулевые разделы дисков никогда не использовались другими администрато" рами баз данных. Такая схема уменьшает на единицу число реально доступных на диске разделов, но оставшихся шести практически всегда оказывается вполне достаточно. Стандартную схему разделов нетрудно согласовать с системным администратором серверной машины, поскольку она одинакова для всех физических дисков, распределяемых под логические дисковые устройства сервера. Последо" вательно выделите нулевые цилиндры каждого диска в отдельный раздел 0; следите за тем, чтобы имеющиеся серверы баз данных никогда не использовали нулевые разделы дисков. Таким образом вы полностью исключите возможность случайной утраты метки тома физического диска сервера. Еще раз напоминаем, что цилиндры 0 могут без каких"либо проблем применяться операционной систе" мой серверной машины. Как уже отмечалось, раздел 2 соответствует всему физическому диску и его следует сохранить для получения информации о полном объеме диска. Таким образом, в вашем распоряжении остаются разделы 1, 3, 4, 5, 6 и 7, которые можно размес" тить в свободном пространстве диска по своему усмотрению. Здесь логично было бы использовать простую стандартную схему, в которой разделу 7 выделяется дисковая область небольшого размера, а оставшаяся часть диска поровну делится между разделами 1, 3, 4, 5, 6. В сервере обязательно дол" жен быть предусмотрен один небольшой раздел для серверного устройства master и еще один такой же раздел для его зеркальной копии. Хотя реально используемая область серверного устройства master редко превышает 20 Мбайт, логично было бы оставить на нем достаточный запас свободного места, поскольку базу данных master нельзя перенести на другое серверное устройство, а увеличение размера существующего серверного устройства master представляет собой весьма непростую опера" цию (см. главу 7). Поэтому на каждом физическом диске, используемом сервером, рекомендуется со" здать по одному 50"Мбайт разделу. На первый взгляд может показаться, что все такие разделы (за исключением двух, распределенных устройству master и его зеркальной копии) не используются, в действительности же сервер System 11 включает в себя ряд баз данных среднего размера (см. главу 13), которые очень удобно размещать на небольших серверных устройствах. Следовательно, в стан" дартную схему разделов каждого физического диска, где размещаются логические дисковые устрой" ства сервера, входит 50"Мбайт раздел 7. Для упрощения схемы разбиения дисков размеры остальных разделов (1, 3, 4, 5, 6) сделайте оди" наковыми, присвоив каждому из них одну пятую дискового пространства, оставшегося после выделе" ния цилиндра 0 в отдельный раздел 0 и создания 50"Мбайт раздела 7. Предложенная нами стандартная схема проста, поэтому ее легко запомнит системный администратор; кроме того, она позволяет избежать серьезных ошибок и значительно ускоряет процесс подключения новых дисков к серверу. Каждый дисковый накопитель должен иметь одно назначение Помимо стандартной схемы разделов физических дисков, администратору сервера следует придержи" ваться еще одного правила: дисковые накопители нельзя одновременно использовать для размещения файловой системы и логических дисковых устройств сервера. Хотя технически вполне допустимо часть разделов одного диска выделить файловой системе серверной машины, а другую часть использо" вать для поддержки серверных устройств, на практике рекомендуется избегать смешивания на одном диске форматированных и неформатированных разделов (рис. 8.6). Во"первых, подобное соглашение намного упрощает взаимодействие администратора сервера с системным администратором серверного компьютера: часть дисковых накопителей разбивается в соответствии с только что рассмотренной стандартной схемой разделов и затем используется для назначения серверным устройствам, в то время как оставшиеся диски передаются под управление системного администратора для операционной сис" темы и размещения указанных вами файловых систем, необходимых при эксплуатации сервера. Здесь системный администратор получает полную свободу выбора конфигурации разделов файловой структу" ры серверного компьютера, от него не требуется постоянно помнить о серверных устройствах. В свою очередь, администратор сервера всегда может быстро проверить стандартные разделы физических ди" сков сервера, не беспокоясь о разделах файловой системы. Во"вторых, разделение физических дисков снижает опасность случайной утраты раздела файловой системы при его ошибочном назначении одно" му из серверных устройств. В результате исключается необходимость постоянного взаимодействия между системным администратором и администратором сервера при выполнении обычных повседнев" ных задач по поддержанию работоспособности сервера и серверного компьютера. Кроме того, распре" деление серверу выделенных дисковых накопителей намного упрощает зеркальное резервирование серверных устройств, поскольку это позволяет отобразить все разделы одного диска на аналогичные разделы другого диска. Наконец, разделение дисков облегчает оценку потерь, вызванных отказом од" ного из накопителей.

www.books-shop.com

Контроллер О диск cOtOdO + диск 1 файловой системы все разделы диска cOtOdO используются для размещения одной или нескольких файловых систем диск cOtOdl + серверный диск 1 все разделы диска используются для поддержки серверных устройств диск c0t0d2 + серверный диск 2 все разделы диска используются для поддержки серверных устройств диск c0t0d3 + зеркальная копия c1t0d5 все разделы являются зеркальными копиями серверных устройств с диска c1t0d5 диск c1t0d4 + диск 2 файловой системы все разделы диска c1t0d4 используются для размещения одной или нескольких файловых систем диск c1t0d5 + серверный диск 3 все разделы диска используются для поддержки серверных устройств диск c1t0d6 + зеркальная копия c0t0d1 все разделы являются зеркальными копиями серверных устройств с диска c0t0d1 диск с1 t0d7 + зеркальная копия c0t0d2 все разделы являются зеркальными копиями серверных устройств с диска c0t0d2 В рассматриваемом примере к серверной машине подключено восемь дисковых накопителей. Каждый физический диск имеет только одно назначение и используется для размещения либо файловых систем, либо серверных устройств, либо зеркальных копий этих устройств. Рис. 8.6. Разделение дисков: каждый накопитель должен целиком использоваться для размещения либо файловых систем, либо серверных устройств, либо их зеркальных копий Контроллеры дисков Научившись распределять диски между файловыми системами и устройствами сервера, можем перей" ти к обсуждению проблем, связанных с контроллерами дисков — устройствами, связывающими физи" ческие дисковые накопители с серверной машиной. Диски и контроллеры дисков К одному дисковому контроллеру можно одновременно подключить несколько дисков; однако под" ключение слишком большого числа дисков иногда отрицательно сказывается на производительности сервера. Уточните у системного администратора серверной машины, какое максимальное число дис" ков можно подключать к одному контроллеру, чтобы при этом не снизилась производительность сис" темы. Это число различно для разных операционных систем и аппаратных платформ; к примеру, в системе Solaris к одному контроллеру рекомендуется подключать не более четырех физических дис" ков. Таким образом, при расширении дискового пространства сервера необходимо предусмотреть установку в серверный компьютер одного дополнительного контроллера на каждый из подключае" мых дисков. Кроме того, существуют различные типы контроллеров дисков, например более произ" водительные быстрые (fast) SCSI и обычные SCSI (slow SCSI). Администратор сервера должен знать, какие типы дисков и контроллеров имеются в его системе, и учитывать это при подключении новых дисков. Так, обычный SCSI"диск почти всегда удается подключить к быстрому SCSI"контроллеру (хотя это может отрицательно сказаться на производительности контроллера), но не наоборот. Команда format помогает узнать, какие диски к какому контроллеру подключены. При этом будут указаны все

www.books-shop.com

физические диски, подключенные к серверной машине, вместе с наименованиями и номерами конт" роллеров. Однако для вызова команды format необходимо войти в серверную машину в качестве при" вилегированного пользователя с именем "root", обладающего в среде UNIX системными полномочиями, поэтому необходимо соблюдать особую осторожность. В частности, неправильное использование команды format может привести к утрате всего содержимого физического диска. Накопители на магнитной ленты и контроллеры дисков Накопители на магнитной ленте тоже подключаются к серверной машине через дисковые контролле" ры. Хотя вполне можно подключать устройства записи на магнитную ленту даже к тем дисковым на" копителям, которые уже поддерживают максимально рекомендуемое число дисков, подключение этих устройств через выделенный контроллер позволит избежать снижения производительности сервера при работе с магнитными лентами (рис. 8.7). Серверная машина 1

ДОПУСТИМО

Устройство записи на ленту не рекомендуется использовать в периоды максимальной загрузки сервера

Серверная машина 2 ОПТИМАЛЬНЫЙ ВАРИАНТ

Дисковый накопитель

Устройство записи на магнитную ленту

Рис. 8.7. Подключение накопителей на магнитной ленте к дисковым контроллерам Распределение дисков по контроллерам При выборе конфигурации серверной машины очень важно достичь оптимального распределения дисков по имеющимся контроллерам. В частности, дисковые накопители, используемые для размеще" ния серверных устройств, следует распределить среди максимально возможного числа доступных контроллеров. Нельзя подключать все серверные диски к одной группе контроллеров, а все диски файловой системы — к другой (рис. 8.8). Необходимость распределения серверных дисков и дисков файловой системы по всем контроллерам вызвана двумя рассматриваемыми ниже причинами, каж" дая из которых имеет отношение исключительно к серверным дискам. Все оставшиеся диски разно" сятся по разным контроллерам только для того, чтобы получить возможность подключить к каждому контроллеру необходимое количество серверных устройств. Распределение серверных дисков по контроллерам необходимо для обеспечения целостности баз данных путем создания зеркальных копий серверных устройств (о чем подробнее говорится ниже в этой главе). При выводе данных в зеркальную пару устройств сервер записывает их как в основное устройство пары, так и в его зеркальную копию. Если диски, содержащие оба устройства, подключены к одному контроллеру, то выход этого контроллера может повлечь одновременную по" рчу и основного, и резервного серверных устройств. Кроме того, распределение серверных дисков по нескольким контроллерам позволяет повысить производительность сервера. По мере роста объемов баз данных возникает необходимость размеще" ния объектов одной базы данных на нескольких дисках посредством создания ряда сегментов базы данных (о чем также говорится ниже). К примеру, на отдельном сегменте полезно разместить ин" дексы наиболее часто используемых таблиц, что помогает серверу осуществлять поиск информации

www.books-shop.com

диск c0t0d0 + диск 1 файловой системы диск c0t0d1 + диск 2 файловой системы диск c0t0d2 + диск 3 файловой системы диск с0t0dЗ + диск 4 файловой системы диск c1t0d4 + серверный диск 1 диск c1t0d5 + зеркальная копия c1t0d4 диск c1t0d6 + серверный диск 2 диск с1t0d7 + зеркальная копия c1t0d6 диск c2t0d8 + серверный диск 3 диск c2t0d9 + серверный диск 4 диск c2t0d10 + серверный диск 5 диск c2t0d11 + серверный диск 6 диск c3t0d12 +зеркальная копия c2tOd8 диск c3tOd13 + зеркальная копия c2tOd9 диск c3tOd14 + зеркальная копия c2tOd10 диск c3tOd15 + зеркальная копия c2tOd11 НЕУДАЧНОЕ РАСПРЕДЕЛЕНИЕ СЕРВЕРНЫХ УСТРОЙСТВ Все диски файловой системы находятся на одном контроллере, что не позволяет подключать к нему серверные диски, которые следует распределять по всем доступным контроллерам серверной машины. Одновременное размещение серверных устройств и их зеркальных копий на общем контроллере в случае его выхода из строя чревато утратой баз данных, несмотря на их зеркальное резервирование. Рис. 8.8. Неудачное распределение серверных устройств по дисковым контроллерам в табличном индексе, расположенном на одном серверном устройстве, и одновременно выбирать данные из самой таблицы, расположенной на другом устройстве. Для получения наибольшего выиг" рыша в производительности дисковые накопители, на которых находятся эти серверные устройст" ва, должны быть подключены к разным контроллерам (рис. 8.9). Стандартная методика распределения дисков по дисковым контроллерам Процесс выбора конфигурации дискового пространства серверной машины заметно упрощается, если, определив, какая часть всех дисков будет использоваться для поддержки файловых систем, рав" номерно распределить их по всем доступным контроллерам. Оставшиеся диски равномерно распре" деляются по имеющимся контроллерам с учетом максимально возможного числа дисков, подключаемых к одному контроллеру. Затем для каждого контроллера выбирается единый порядок следования серверных дисков и дисков файловых систем; если файловые системы занимают одну чет" верть всех дисков, то они будут размещаться на первом диске каждого контроллера. Соблюдение стандартной конфигурации дискового пространства необходимо как системному администратору, так и администратору сервера. Это позволяет быстрее оценить, какие компоненты сервера или опе" рационной системы серверной машины оказались затронутыми при сбое. Кроме того, при расшире" нии файловой структуры можно сразу узнать, на каких дисках имеет смысл искать свободные разделы. Баланс между дисками файловой системы и серверных устройств необходимо поддерживать и при добавлении новых дисков к серверной машине, подключая эти диски одновременно с дополни" тельным контроллером. В подавляющем большинстве случаев расширение дискового пространства сервера вызывает необходимость соответствующего увеличения размеров файловой системы, и нао" борот.

www.books-shop.com

диск cOtOdO + диск 1 файловой системы диск cOtOd1 + серверный диск 1 диск с0t0d2 + серверный диск 2 диск с0t0d3 + зеркальная копия c1tOd5 диск c1tOd4 + диск 2 файловой системы диск c1tOd5 + серверный диск 3 диск c1tOd6 + зеркальная копия cOtOd1 диск c1tOd7 + зеркальная копия cOtOd2 диск c2tOd8 + диск 3 файловой системы диск c2tOd9 + серверный диск 4 диск c2tOd10 + серверный диск 5 диск c2t0d11 + зеркальная копия c3tOd13 диск c3tOd 12 + диск 4 файловой системы диск c3tOd 13 + серверный диск 6 диск c3tOd14 + зеркальная копия c2tOd9 диск c3tOd15 + зеркальная копия c2tOd10 ОПТИМАЛЬНОЕ РАСПРЕДЕЛЕНИЕ СЕРВЕРНЫХ УСТРОЙСТВ Примечание. Четверть из 16 имеющихся дисков используется для размещения файловых систем, в то время как остальные 12 дисков разделены поровну между серверными устройствами и их зеркальными копиями. Рис. 8.9. Оптимальное распределение серверных устройств по дисковым контроллерам

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

Журнал транзакций Сегмент журнала транзакций (logsegment) базы данных необходимо разместить на специальном сер" верном устройстве, не содержащем никаких других сегментов этой же базы данных. Дисковый нако" питель, на котором расположен сегмент журнала транзакций, должен подключаться к контроллеру, не используемому серверными устройствами других сегментов базы данных. Администратор сервера обязан проанализировать состав объектов базы данных. При наличии больших объектов базы дан" ных (таких, как крупная таблица или ее индекс) для этих объектов следует создать отдельные сегмен" ты, расположенные на разных серверных устройствах, в идеальном случае — подключенных к разным контроллерам, не поддерживающим другие сегменты этой же базы данных. Для повышения общей производительности операций ввода/вывода сегменты базы данных, содержащие наиболее активно используемые объекты, рекомендуется равномерно распределять по различным устройствам сервера (см. главу 10). Единственным исключением из рассмотренного выше правила является журнал транзакций. В отличие от других интенсивно используемых объектов базы данных, его не стоит распределять по нескольким серверным устройствам и разным дисковым контроллерам: вся обработка журнала

www.books-shop.com

транзакций сосредоточена лишь на его самой последней странице, и эта особенность вне власти ад" министратора сервера. Таким образом, определив требуемый размер журнала транзакций, вы може" те без лишних раздумий поместить весь журнал на одно серверное устройство. Еще раз отметим, что подобное устройство не должно содержать других сегментов той же самой базы данных. Соблю" дение этого правила столь же существенно, как и корректное определение требуемых размеров жур" нала транзакций, важность которого должна быть уже хорошо понятна читателю. Для того чтобы сократить время, в течение которого нет доступа к базе данных, и облегчить ее восстановление по" сле сбоев, серверное устройство, содержащее сегмент журнала транзакций, должно иметь зеркаль" ную копию. Размещение нескольких баз данных на одном сервере Перейдем к проблемам, возникающим при распределении объектов нескольких баз данных среди имеющихся дисковых контроллеров и серверных устройств. Разумеется, для оптимизации произво" дительности отдельной базы данных администратору сервера требуется разнести ее сегменты по раз" личным физическим дискам, подключенным к разным дисковым контроллерам. Однако при этом следует учитывать необходимость интеграции нескольких (и, вполне возможно, многих) баз данных в пределах одного сервера. Хотя в идеальном случае каждой базе данных можно было бы назначить индивидуальный набор серверных устройств и дисковых контроллеров, подобный подход редко реа" лизуется на практике. При установке сервера на серверном устройстве master разместите базы данных master, model и на" чало базы данных tempdb. Затем определите, с какой из всех оставшихся баз данных будет связан наи" больший объем операций ввода/вывода. Имейте в виду, что такой базой данных вовсе не обязательно окажется самая крупная база данных сервера. Здесь администратору сервера приходится полагаться в основном на свой опыт и интуицию, поскольку окончательный объем операций ввода/вывода можно будет узнать только в процессе эксплуатации сервера пользователями. Проанализировав планируемый состав объектов выбранной базы данных, выделите крупные и часто используемые таблицы, которые с большой долей вероятности придется разместить на специально созданных сегментах, отдельно от остальных объектов базы данных. Кроме того, возможно, вам потребуется создать специальный сег" мент для индексов крупных либо наиболее активных таблиц. Все созданные пользовательские сегмен" ты распределите по различным серверным устройствам, подключенным к разным дисковым контроллерам, не поддерживающим другие сегменты базы данных. Разместив на сервере первую пользовательскую базу данных, можете переходить к распределе" нию других баз данных по оставшемуся дисковому пространству. Подобная операция представляет собой циклический процесс, в котором сначала размещаются самые крупные базы данных, а также базы данных, генерирующие большое число операций ввода/вывода, поскольку здесь требуется мак" симальная гибкость при распределении объектов таких баз данных по различным серверным устройствам и дисковым контроллерам. Кроме того, не следует забывать о будущем. Не поддавай" тесь искушению последовательно заполнять имеющиеся диски, чтобы оставить свободными как можно большее число свободных дисков и потом использовать их для размещения новых баз дан" ных. Подобный подход нельзя назвать правильным, поскольку вы уже выбрали определенную схему размещения пользовательских сегментов наиболее активных баз данных, которая окажется нару" шенной, если в процессе роста этих сегментов придется размещать их на дополнительных сервер" ных устройствах, возможно, уже поддерживающих другие сегменты этой же базы данных. Таким образом, каждый сегмент основных баз данных должен иметь возможность расширяться, оставаясь на одном и том же физическом диске, подключенном к одному и тому же дисковому накопителю. Поэтому используемые серверные устройства не могут быть заполнены до предела. Наоборот, базы данных и их сегменты необходимо разнести по максимально возможному числу различных сервер" ных устройств и дисковых контроллеров, оставив при этом на каждом диске достаточно места для расширения существующих сегментов. Зарезервировав на каждом физическом диске определенное свободное пространство, вы не толь" ко предотвратите возможность снижения производительности сервера из"за распространения ак" тивных сегментов баз данных на другие дисковые накопители, также содержащие часто используемые сегменты. Не следует забывать, что доступное базам данных дисковое пространство будет расширяться и другими администраторами баз данных, которые могут не осознавать важности оптимального распределения сегментов баз данных по имеющимся серверным устройствам. Нако" нец, локализация сегмента базы данных в пределах одного диска значительно облегчает поддержку его зеркальной копии, поскольку, как отмечалось выше, серверные устройства следует размещать на специально предназначенных для этого дисковых накопителях, которые должны целиком отобража" ться на свои зеркальные копии, также занимающие весь выделенный диск.

www.books-shop.com

По мере последовательного распределения объектов очередных баз данных среди все сокращаю" щегося числа свободных серверных устройств и дисковых контроллеров возрастает вероятность воз" никновения конфликтных ситуаций. Это происходит, когда активно используемый сегмент одной базы данных приходится размещать на физическом диске или контроллере, общих с активным сег" ментом другой базы данных. Здесь трудно предложить какой"либо универсальный рецепт; скорее все" го, оптимальная конфигурация будет изменяться со временем в процессе роста сегментов баз данных и их миграции с диска на диск. При снижении производительности сервера может возникнуть необ" ходимость пересмотра схемы размещения баз данных по дискам и дисковым контроллерам. Размещение системных баз данных Системные базы данных master, sybsystemprocs и sybsecurity обязательно должны иметь зеркальные копии. Идеально, если каждая из этих баз данных и их зеркальных копий находится на отдельном серверном устройстве. Однако на практике это не всегда возможно. При использовании рассмотренной выше стандартной схемы разбиения дисков существенную роль играет количество физических дисков, под" ключенных к серверному компьютеру. В следующих разделах мы рассмотрим два примера, в каждом из которых предполагается, что 2,1"Гбайт физический диск разбивается на пять разделов (секций) по 400 Мбайт и один 50"Мбайт раздел. В свою очередь, 4,2"Гбайт диски содержат пять 800"Мбайт и один 80"Мбайт раздел. Минимальная конфигурация — два дисковых накопителя При наличии в системе лишь двух физических дисков меньший раздел одного диска распределяется серверному устройству master, а соответствующий раздел другого диска — его зеркальной копии. По" сле чего базы данных sybsystemprocs и sybsecurity помещаются на серверное устройство, занимающее один из крупных разделов диска и зеркально отображаемое на аналогичный раздел другого диска (рис. 8.10). Напомним, что в системе Solaris вместо понятия "раздел диска" (partition) используется термин "секция" (slice). Серверная машина КОНТРОЛЛЕР ДИСКОВ (два диска)

секция 7

ПРИМЕЧАНИЯ. Секция 0 занимает нулевой цилиндр. Секция 2 соответствует всему диску и не используется сервером. Один из дисков должен полностью использоваться серверными устройствами. Перед размещением баз данных sybsystemprocs и sybsecurity в секции 6 командой disk init необходимо создать серверное устройство. Секции 1,3,4,5 назначаются серверным устройствам, используемым для размещения пользовательских баз данных.

Рис. 8.10. Размещение системных баз данных на двух дисковых накопителях

www.books-shop.com

Рис. 8.11. Размещение системных баз данных на шести дисковых накопителях Оптимальная конфигурация — шесть дисков или более ЕСЛИ в системе имеется как минимум шесть дисков, то меньшие разделы двух из них отводятся под серверное устройство master и его зеркальную копию. Затем в малый раздел третьего диска помеща" ется база данных sybsystemprocs, и соответствующее серверное устройство зеркально отображается на малый раздел четвертого диска. Аналогично и база данных sybsecurity создается на малом разделе пято" го диска, а ее зеркальная копия — в таком же разделе шестого диска (рис. 8.11). Напомним, что серверные устройства и их зеркальные копии должны создаваться на дисках, под" ключенных к разным контроллерам. Вне зависимости от количества имеющихся дисков меньший раздел одного из них должен быть назначен серверному устройству master, содержащему только базы данных master, model и первую часть базы данных tempdb. Остальные системные базы данных — sybsystemprocs и sybsecurity — следует размещать на других выделенных для этой цели (если есть возмож" ность) серверных устройствах, имеющих зеркальные копии. Инициализация серверных устройств Итак, мы научились разбивать физические диски на разделы и распределять серверные устройства по разным дисковым контроллерам. Теперь можно начинать знакомиться с процессом инициализа" ции раздела физического диска, в результате которого в этом разделе создается серверное устройст" во и он становится доступным для использования сервером. Команда сервера disk init Прежде чем любое новое серверное устройство станет доступным серверу, его необходимо инициа" лизировать командой disk init " вне зависимости от того, что представляет собой данное устрой" ство: неформатированный раздел диска или файл операционной системы. Ниже приводится формат команды disk init; в следующих разделах главы мы рассмотрим роль каждого из ее параметров (рис. 8.12).

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

disk init name = "device_name", physname = "physical_name", vdevno = vlrtual_device_number, size = number_of_blocks Название устройства (device_name) Рассмотрим функции всех параметров команды disk init. Название устройства (device_name) ис" пользуется сервером для обозначения создаваемого устройства, в то время как физический адрес устройства (physical_name) определяет назначаемый устройству небуферизованный раздел диска или файл операционный системы, тем самым указывая, как это устройство будет выглядеть с точки зрения операционной системы. Таким образом, команда disk init устанавливает взаимосвязь меж" ду серверным устройством, известным серверу, и соответствующей областью физического диска, так или иначе известной операционной системе. В свою очередь, параметр virtual_device_number является номером данного устройства, однозначно определяющим его среди других серверных устройств. Наконец, параметр number_of_blocks устанавливает размер создаваемого серверного устройства и указывается в виде количества 2"Кбайт страниц. Как отмечалось ранее, серверному устройству может быть установлен любой размер, не превышающий размер назначенного ему небу" феризованного дискового раздела. физический диск c0t0d0 disk init name = "device_name", physname = "physical_name", vdevno = virtual_device_number, size = number of blocks раздел Т, доступный через системный файл /dev/rdsk/c0t0d0s1 name = "c0t0d0s1" physname = "/dev/rdsk/c0t0d0s1" vdevno =15 size = 204800 (в 2+Кбайт страницах, т.е. всего 400 Мбайт) Название устройства (параметр name) состоит из названия физического диска и номера раздела. Физический адрес устройства (параметр physname) представляет собой полный путь к файлу, контролирующему побайтовый доступ к неформатированному разделу физического диска; с точки зрения операционной системы серверной машины этот файл должен принадлежать пользователю с именем 'Sybase'. Значение параметра vdevno не может превышать значения параметра конфигурации 'devices', которое можно найти при выводе команды sp_configure, и не должно совпадать с номером одного из уже существующих устройств. Рис. 8.12. Инициализация логических дисковых устройств сервера Итак, название устройства используется для его адресации сервером и указывается в таких, на" пример, командах, как create database, alter database и др. Администратору сервера следу" ет придерживаться определенной схемы именования серверных устройств. Рекомендуется следующий простейший подход. Войдите в серверную машину под именем привилегированного по" льзователя "root" и выдайте командой format список всех имеющихся в системе дисковых накопите" лей, после чего при создании логических дисковых устройств сервера добавляйте к системным названиям дисков номера соответствующих разделов. К примеру, команда format сообщает вам, что в системе имеются дисковые накопители с именами c0t0d0 и c0t0d1 — c0t0d6. Тогда при инициа" лизации раздела 8 физического диска cOtOdl в качестве названия создаваемого устройства следует указать name = "c0t0d1s3". Хотя то же самое название уже содержится в имени специального систем" ного файла /dev/rdsk/c0t0d1s3, используемого для обращения к данному разделу диска, при

www.books-shop.com

назначении названий устройств необходимо руководствоваться именно результатами работы коман" ды format. При назначении серверным устройствам файлов операционной системы нет необходимости сле" довать какой"либо фиксированной схеме выбора названий таких устройств, поскольку при возник" новении ошибок сервер всегда сообщает полное имя файла, назначенного серверному устройству. По этому имени нетрудно определить, на каком физическом диске находится данный файл (сервер" ное устройство). После аварийного останова сервера вы обнаруживаете в файле регистрации ошибок со+ общения об ошибках при записи на устройство baddog1. Увы, вам никак не удается вспомнить, на каком именно диске находилось устройство baddog1 (или какому файлу операционной системы оно соответствовало). Команда sp_helpdevice тоже не помо+ жет, поскольку сервер неработоспособен. Дела плохи: перезапуск сервера без локализа+ ции отказавшего диска грозит дальнейшей утратой содержимого баз данных. Единственный выход — полная аппаратная проверка работоспособности всех дисков серверной машины. Но на это уйдет очень много времени. Единая схема названий сер+ верных устройств позволила бы немедленно определить, на каком диске размещается то или иное устройство. Адрес устройства (physical_name) Физический адрес устройства определяет его местонахождение в операционной системе. Для небу" феризованного раздела диска физическим адресом является имя специального системного файла, ис" пользуемого при доступе к этому разделу. Напомним, что доступ к диску может осуществляться в одном из двух режимов: блоковом или побайтовом, каждому из которых соответствует отдельный си" стемный файл. При задании адреса устройства SQL Server, находящегося на небуферизованном раз" деле физического диска, необходимо указывать имя системного файла, задающего побайтовый доступ к этому разделу. Это имя зависит от конкретной платформы, и его необходимо уточнить у сис" темного администратора. В нашем случае такие файлы находятся в каталоге /dev/rdsk файловой си" стемы, где буква "г" в названии каталога указывает на побайтовый доступ к соответствующим дисковым разделам. Таким образом, побайтовый доступ к разделу 1 диска cOtOdO осуществляется че" рез файл /dev/rdsk/cOtOdOs1. Именно это имя и следует задать в качестве физического адреса сер" верного устройства, находящегося в данном разделе. При назначении серверному устройству файла операционной системы в качестве адреса указывается полное имя файла (/<полный путь>/<имя_файла>), однозначно определяющее файловую систему, к которой принадлежит дан" ный файл. Номер виртуального устройства (vdevno) Назначение номера виртуального устройства выглядит не вполне очевидным, а ошибочное значение этого параметра может заблокировать создание нового серверного устройства. С точки зрения серве" ра каждое подобное устройство состоит из определенного числа N дисковых 2"Кбайт страниц с номе" рами от 0 до N"1. Однако серверу необходимо иметь возможность индивидуально адресовать каждую страницу каждого серверного устройства. Именно здесь сервер и использует значение параметра vdevno в комбинации с номером страницы в пределах данного устройства. Таким образом, в действи" тельности параметр vdevno играет очень важную роль, и при каждом вызове команды disk init сервер проверяет, не совпадает ли указанное значение параметра vdevno с номером одного из уже су" ществующих устройств, список которых (с указанием номеров) можно распечатать командой sp_helpdevice . Серверное устройство создать невозможно, если имеет место любая из перечис" ленных ниже ситуаций: • указанное значение vdevno • уже используется другим серверным устройством • задавалось в одной из предыдущих попыток выполнить команду disk init, которая завершилась неудачей • использовалось ранее удаленным серверным устройством • превышает максимально допустимое число серверных устройств (определяемое параметром конфигурации devices)

www.books-shop.com

Указано уже используемое значение vdevno Для вывода используемых значений номеров виртуальных устройств используйте команду sp_help" device (без дополнительных аргументов). Кстати, номера устройств не хранятся в системной табли" це sysdevices, а специально вычисляются в процессе выполнения процедуры sp_helpdevice , поэтому их нельзя получить непосредственной выборкой записей из таблицы sysdevices. Предыдущая команда disk init закончилась неудачей Значение параметра vdevno не может быть повторно использовано вплоть до следующего перезапуска сервера, если оно было указано в одном из предыдущих вызовов команды disk init, завершивших" ся неудачей (например, из"за слишком большого размера устройства, превышающего объем раздела диска). Значение vdevno совпадает с виртуальным номером ранее удаленного устройства ЕСЛИ после последнего перезапуска сервера вы удалили серверное устройство, его номер не может быть использован до следующего перезапуска сервера. Хотя серверные устройства создаются командой сервера disk init, их удаление производится с помощью хранимой процедуры sp_dropdevice.

Превышение допустимого числа серверных устройств Максимально допустимое число серверных устройств определяется параметром конфигурации серве" ра devices, значение которого можно узнать с помощью команды sp_conf igure. По умолчанию па" раметр devices имеет значение, равное 10, что позволяет создавать устройства с виртуальными номерами от 0 до 9 включительно. К сожалению, даже если команда disk init завершается неуда" чей из"за выхода значения параметра vdevno из допустимого диапазона, сервер выдает сообщение об отсутствии в указанном физическом разделе диска достаточного пространства для размещения созда" ваемого устройства. При получении подобного сообщения в первую очередь проверьте, не указано ли слишком большое значение параметра vdevno. Для увеличения максимально допустимого числа устройств после выполнения команды sp_c on figure произведите перезапуск сервера. Помните, что увеличение параметра devices одновременно увеличивает объем оперативной памяти, необ" ходимой серверу. Кроме того, максимальное значение параметра vdevno на единицу меньше величи" ны параметра devices, причем устройству master всегда соответствует vdevno = 0. Наконец, в максимальное число серверных устройств, задаваемое параметром devices, не входят устройства вывода дампов. Так что при их создании можно не беспокоиться о значениях параметров devices или vdevno. Процесс создания новых серверных устройств требует внимания, поскольку здесь легко оказаться в весьма запутанной ситуации. Допустим, ваша первая попытка выполнить команду disk init завершается неудачей: слишком велико значение параметра size. Исправив ошибку, вы снова выполняете disk init, и опять сталкиваетесь с неудачей, на этот раз из+за повторного использования прежнего значения параметра vdevno. Вы увеличиваете vdevno на единицу, но новое значение превышает максимально допусти+ мое, хотя оно в точности совпадает с величиной параметра devices (в то время как максимально допустимое vdevno равно N+1, где N — значение параметра devices, вы+ даваемое командой sp_configure). Поскольку в соответствующем сообщении об ошиб+ ке почему+то говорится о недостаточном размере раздела физического диска, вы начинаете заново проверять величину параметра size (которая на этот раз выглядит вполне логично), распечатываете список используемых номеров устройств (ни один из них не совпадает с указанным значением vdevno), а затем пытаетесь вспомнить, почему же нельзя указать vdevno =10, если значение devices также равняется 10. Пожалуй, здесь стоит прекратить дальнейшие попытки выполнить disk init и попытаться спо+ койно проанализировать возникшую проблему.

www.books-shop.com

Еще один пример, подчеркивающий важность параметра vdevno. Один не в меру сообра+ зительный администратор базы данных, решив повысить производительность сервера, перенес всю базу данных tempdb (включая ее первые 2 Мбайт, размещенные в процессе установки сервера на устройстве master) на отдельное логическое устройство сервера, расположенное на выделенном физическом диске (пожалуйста, никогда не поступайте таким образом!). Очень даже может быть, что подобный трюк действительно привел к существенному ускорению работы сервера. Однако... через некоторое время сервер пе+ рестал запускаться: по всей видимости, из+за нехватки памяти в результате неудачного задания командой sp_configure одного из параметров конфигурации. Недолго думая, администратор базы данных командой buildmaster >+r восстановил устанавливаемую по умолчанию конфигурацию сервера и запустил сервер, но все попытки сделать с сер+ вером еще что+либо оказались безуспешными. Почему? По причинам, так и оставшимся неизвестными, при переносе базы данных tempdb на новое серверное устройство ему был присвоен номер vdevno = 20. Как и в многочисленных примерах других опасных ма+ невров администраторов баз данных, вся опасность этого решения проявилась только тогда, когда возникли другие неприятности. В результате выполнения команды build+ master +r максимально допустимое число серверных устройств было по умолчанию установлено равным 10, что соответствует наибольшему значению vdevno = 9. Таким об+ разом, после запуска сервер не смог открыть устройство, содержащее базу данных tempdb. Описанная ситуация не фатальна, но прибывшему по срочному вызову админи+ стратору сервера пришлось немало потрудиться, прежде чем докопаться до причины ее возникновения. Для восстановления работоспособности сервера здесь достаточно вы+ звать isql и восстановить командой sp_configure прежнее значение параметра devi+ ces. Вся сложность в том, что процедура sp_helpdevice и аналогичные команды используют базу данных tempdb и поэтому не могут быть выполнены в ее отсутствие. Как видите, одно неверное решение администратора базы данных может привести к вы+ ходу из строя всей системы. Количество блоков (number_of_blocks) Параметр number_of_blocks указывает размер создаваемого серверного устройства, задаваемый в виде числа 2"Кбайт страниц. При работе с сервером используются различные единицы измерения ди" скового пространства: блоки, 2"Кбайт страницы, а также кластеры (allocation units). Они представля" ют собой область диска, распределяемую сервером за один прием (и равную 256 страницам). При работе с командой disk init блок равен одной 2"Кбайт странице. Для определения максимально возможного размера серверного устройства с помощью команды prtvtoc /dev/rdsk/ узнайте размер соответствующего раздела физического диска. В команде указывается название диска в том виде, как оно известно операционной системе, например prtvtoc /dev/rdsk/cOtOdOs1. Фактически параметр команды prtvtoc совпадает с полным именем системно" го файла, используемого для доступа к одной из секций физического диска. Разумеется, администра" тор сервера (пользователь с именем Sybase) должен иметь необходимые полномочия на доступ к этому файлу. Команда prtvtoc выдает список всех разделов соответствующего физического диска с указанием количества секторов и цилиндров, выделенных каждому разделу. Пример вывода команды prtvtoc см. в главе 13. В первую очередь нас интересует количество секторов в разделе, назначаемом создаваемому сер" верному устройству. Для определения размера раздела в байтах количество его секторов необходи" мо умножить на 512 байт, после чего результат перевести в мегабайты делением на величину 1024*1024 (которая в точности равна 1 Мбайт). Скорее всего, размер раздела не будет равен целому числу мегабайт, поэтому у него необходимо отбросить дробную часть и затем преобразовать полу" ченный ответ в количество 2"Кбайт страниц, указываемых в команде disk init. При задании раз" меров серверного устройства необходимо представлять себе, каким образом сервер распределяет дисковое пространство в процессе выполнения команд create database и alter database. При создании или расширении базы данных сервер выделяет из свободного пространства устройства необходимое число 0,5"Мбайт кластеров — единиц размещения (allocation units). Каждый из них содержит 256 2"Кбайт страниц. Поскольку команды create database и alter database позволяют указывать в качестве размера базы данных только целое число мегабайт, существование 0,5"Мбайт кластеров редко проявляется на практике. Однако с подобной особенностью вы можете столкнуться, например, в следующей ситуации. Ваш коллега, администратор баз данных, решил рас" ширить какую"то свою базу данных (или создать новую), не убедившись в наличии достаточного сво" бодного пространства на указанном им серверном устройстве. В подобном случае сервер выделяет

www.books-shop.com

место на других устройствах, используя все имеющееся в них свободное пространство (с точностью до одного кластера). Если при создании какого"либо из этих устройств в команде disk init было указано количество страниц, равное дробному числу мегабайт (хх.уу Мбайт), и дробная часть .уу пре" вышает 0,5 Мбайт, то сервер сможет распределить в этом разделе один дополнительный кластер в дополнение к целому числу доступных мегабайт. Может быть, вы никогда этого и не заметите, но выделение базе данных дополнительного кластера грозит потерей данных при восстановлении базы данных из дампа (после сбоя сервера или при переносе базы данных на новый сервер). Дело в том, что перед загрузкой дампа необходимо заново создать восстанавливаемую базу данных, причем здесь ее размер указывается только в виде целого числа мегабайт. Однако загрузка дампа эквивален" тна физическому копированию страниц базы данных с сохранением последовательности, в которой они находились в прежней базе данных. В рассматриваемом примере никто не может гарантировать точного соблюдения этой последовательности, поскольку в новую базу данных невозможно вклю" чить дополнительный 0,5"Мбайт кластер. Поэтому при задании размеров серверных устройств в команде disk init необходимо указывать количество страниц, всегда равное максимальному цело" му числу мегабайт, имеющемуся в определяемом разделе. При назначении серверному устройству файла операционной системы необходимо выяснить об" щий объем файловой системы и определить, не нужно ли зарезервировать в этой файловой системе свободное пространство для других файлов. Затем размер всей области файловой системы, распре" деляемой создаваемому устройству, следует преобразовать в количество 2"Кбайт страниц и указать полученный результат в команде disk init. Общий объем файловой системы и размер свободного пространства легко узнать с помощью системной команды df "k. Сложнее выяснить, какие еще файлы понадобится включить в эту же файловую систему. Проще всего выделить отдельную файло" вую систему для каждого серверного устройства, которому назначается файл операционной систе" мы, и затем указать в команде disk init количество страниц, соответствующее всему объему этой файловой системы (точнее, максимальному целому числу мегабайт, которое можно разместить в этом объеме). Главная причина, по которой основной единицей дискового пространства служит 2+Кбайт страница, заключается в том, что именно такое количество данных обрабатывается за одну операцию ввода/вывода. Поскольку и запись, и чтение данных осуществляются по+ рциями по 2 Кбайт, это количество становится основной единицей измерения во всех операциях, осуществляемых сервером. Заключительные замечания по команде disk init Прежде всего запомните, что команда disk init никогда не применяется для создания серверного устройства master, содержащего одноименную системную базу данных. Для этого в комплект постав" ки SQL Server включена отдельная программа buildmaster. Она автоматически вызывается про" граммой установки sybinit при инсталляции сервера. Кроме того, команда disk init никогда не должна применяться по отношению к разделу, уже содержащему серверное устройство master, поскольку это приведет к полному уничтожению серве" ра. Самое опасное в подобной ситуации то, что после разрушения серверного устройства master сер" вер еще некоторое время продолжает функционировать. При каждом вызове команды disk init необходимо проверять, в каком разделе находится устройство master, чтобы убедиться, что выпол" няемая команда не затронет этот раздел. В принципе, сервер не должен позволить вам повторно инициализировать устройство master. Тем не менее не следует всецело полагаться на механизмы бе" зопасности сервера. Наконец, команда disk init также не применяется при инициализации разде" ла, назначаемого зеркальной копии какого"нибудь серверного устройства. Для этой цели используется команда disk mirror. Вы перешли на работу в новую фирму, и сразу же вам дали поручение — установить SQL Server. Что может быть проще! Берете в руки список серверных устройств и присту+ паете к делу. А проверить, используется ли в фирме стандартная схема именования сер+ верных устройств, забыли? Увы, ваш предшественник ее игнорировал, и вы оказались в трудной ситуации. Проинициапизировав все устройства командой disk init, вы продолжа+ ете установку. Все идет нормально вплоть до записи на диск дампа базы данных master (обязательная операция, выполняемая по завершении установки сервера). И здесь начи+ нают поступать первые сообщения об ошибках. Запуск dbcc приводит к выдаче еще большего числа таких сообщений. Немного успокоившись, вы смотрите указанные спе+ цификации устройств и... обнаруживаете, что одному из этих устройств назначен раздел,

www.books-shop.com

уже содержащий устройство master, которое, естественно, было разрушено в процессе выполнения команды disk init. Конечно, в этом нет вашей вины, но перед запуском disk init следовало проверить, в каком разделе находится устройство master. Теперь единственное, что вам остается, это повторная установка сервера. Итак, ваша карьера на новом месте начинается с того, что вам не удается установить сервер с первого раза. В следующий раз, чтобы оставить о себе лучшее впечатление, не забывайте проверять местонахождение устройства master для каждого сервера, имеющегося на используемой вами серверной машине. Не полагайтесь на прежних администраторов баз данных (в особенности тех, на чье место вы пришли). После успешного завершения команды disk init новое серверное устройство не включается автоматически в набор серверных устройств, используемых по умолчанию. Подобные устройства служат для размещения объектов баз данных, при создании которых не указывается какое"то опреде" ленное серверное устройство. В большинстве случаев вообще не следует предусматривать на серве" ре используемые по умолчанию устройства, поскольку для оптимизации производительности сервера и обеспечения целостности информации каждая база данных должна располагаться как ми" нимум на одном определенном серверном устройстве. Если вам все же потребуется сделать устрой" ство используемым по умолчанию, то после выполнения команды disk init вызовите хранимую процедуру sp_diskdefault. Успешное выполнение команды disk init невозможно при отсутствии достаточных прав до" ступа к специальным системным файлам, контролирующим побайтовый ввод/вывод в соответству" ющие небуферизованные разделы физического диска. К примеру, для создания серверного устройства в разделе 1 физического диска cOtOdO файл /dev/rdsk/cOtOdOs1 должен принадлежать администратору сервера (обычно он входит в систему в качестве пользователя с именем "sybase"). Сегменты баз данных Научившись равномерно распределять серверные устройства и диски файловых систем по имеющим" ся дисковым контроллерам, вы должны ближе познакомиться с понятием сегментов баз данных. Хотя все вопросы, связанные с сегментами, могут показаться сложными и запутанными, сегменты играют важную роль в обеспечении эффективной работы сервера, вполне оправдывающую затраты времени на их изучение. Неправильно думать, что единственным назначением сегментов служит перенос жур" нала транзакций базы данных на отдельное серверное устройство. Сегменты позволяют администра" тору сервера контролировать размещение всех объектов баз данных, включая журнал транзакций, и тем самым добиваться максимальной производительности сервера. Наоборот, неудачное использова" ние сегментов может неблагоприятно отразиться на работе сервера. Выбрав определенную схему раз" мещения сегментов, администратор сервера должен постоянно следить за ее соблюдением. Все преимущества оптимального размещения сегментов по устройствам могут быть сведены на нет одним неопытным администратором базы данных, не понимающим роли сегментов, если он попытается по" сле расширения базы данных на новое устройство разместить на нем сразу несколько ее сегментов. Зачем требуются сегменты Понять необходимость использования сегментов поможет нам пример сервера, в котором базы дан" ных вообще не разделяются на отдельные сегменты. Итак, вы создаете базу данных и начинаете запи" сывать в нее информацию. При этом записи журнала транзакций находятся на одном логическом диске вперемешку с таблицами базы данных и другими ее объектами. По мере заполнения исходного серверного устройства база данных распространяются на новое устройство, занимающее другой раз" дел диска. Однако при каждом перезапуске сервера он восстанавливает свое прежнее состояние, про" сматривая содержимое журналов транзакций всех баз данных; поскольку в нашем случае записи журнала транзакций разбросаны по нескольким серверным устройствам, этот процесс займет много времени. Таким образом, объединение всех записей журнала повтора в одном месте способствует за" метному ускорению процесса восстановления сервера. Для выделения на серверных дисках отдель" ной области, предназначенной исключительно для записей журнала транзакций, и используется механизм сегментов баз данных. Сегмент журнала транзакций Чаще всего сегменты используются именно для переноса журнала транзакций в специальный сег" мент, расположенный на отдельном серверном устройстве, не содержащем других объектов базы дан" ных. SQL Server способен создавать дампы только тех журналов транзакций, которые

www.books-shop.com

предварительно были вынесены на отдельное устройство (важность периодического сохранения дам" пов журнала транзакций обсуждается в главе 9). Большие объекты должны помешаться в отдельном сегменте Пусть наш гипотетический сервер содержит большую и часто используемую таблицу данных, имею" щую несколько индексов. Разделение самой таблицы и ее индексов по разным сегментам, находящим" ся на дисках, подключенных к разным контроллерам, позволит увеличить производительность сервера, поскольку непосредственные обращения к строкам таблицы будут обрабатываться независи" мо от всех других обращений по отдельному каналу ввода/вывода (через независимый контроллер и диск). Кроме того, выделение таблицы в специальный сегмент облегчит контроль за использованием пространства диска, так как другие объекты базы данных не смогут конкурировать за свободное про" странство сегмента, выделенного таблице. В силу тех же причин имеет смысл создать отдельный сег" мент и для индекса большой таблицы. Подобное решение оказывается особенно эффективным, если значительная часть запросов к данным этой таблицы "покрывается" индексом (другими словами, ин" декс сам содержит все необходимые данные), и их можно обработать вообще без обращения к запи" сям таблицы. Для размещения таблицы или индекса на определенном сегменте достаточно включить в коман" ды create table и create index параметр on <название_сегмента>. Таким образом, пример данного гипотетического сервера наглядно убеждает в важности исполь" зования сегментов: это единственный механизм, позволяющий явно контролировать распределение объектов данных по дискам сервера. Подобная возможность способствует повышению производите" льности сервера и помогает определить, каким объектам данных разрешено конкурировать друг с другом за свободное дисковое пространство. Сегменты и команда сервера create database Перейдем к рассмотрению процесса создания сегментов и их использования. При каждом выполне" нии команд create database и alter database сервер создает новые сегменты. Так, при обра" ботке команды create database <имя_базы_данных> on <название_серверного_устройства> = <размер_в_мегабайтах> сервер распределяет базе данных указанное дисковое пространство и автоматически создает на за" данном устройстве сегменты system, default и logsegment. Сегмент system служит для размещения систем" ных таблиц и другой служебной информации, сегмент logsegment содержит все записи журнала транзакций, а в сегменте default находятся остальные объекты базы данных. Важно подчеркнуть, что по умолчанию все три сегмента (system, default и logsegment) находятся на одном устройстве; таким обра" зом, на это устройство попадают все объекты базы данных (рис. 8.13). Проверить текущую конфигу" рацию сегментов базы данных можно командой sp_helpdb <имя_базы_данных>, которая выводит список всех серверных устройств, содержащих объекты базы данных, и названия сегментов, находя" щихся на каждом из этих устройств. Для получения полной информации о сегментах и серверных устройствах, используемых базой данных, с помощью команды use <имя_базы_данных> следует физический диск cOt0dO | create database db1 on cOtOdOs1 = 100 \

раздел '1' диска cOtOdO содержит серверное устройство cOtOdOs1 созданное ранее командой disk init серверному устройству cOt0dOs1 назначены следующие сегменты базы данных db1: default system logsegment

Рис. 8.13. Сегменты базы данных, создаваемые по умолчанию

www.books-shop.com

предварительно перейти в соответствующую базу данных. Размещение всех трех сегментов базы дан" ных на одном устройстве означает, что любой сегмент может целиком заполнить все пространство устройства. Кроме того, поскольку каждому серверному устройству назначается определенный набор сегментов базы данных, все области этого устройства, выделенные конкретной базе данных, будут со" держать одинаковый набор сегментов. Взаимосвязь сегментов и устройств действительно довольно запутанна, и все же необходимо хорошо понимать ее. Части каждого серверного устройства могут распределяться различным базам данных, но сегменты любой из этих баз данных назначаются только всему серверному устройству, а не его отдельным частям. Таким образом, при выделении объектов базы данных в независимый сегмент последний должен размещаться на серверном устройстве, не со" держащем никаких других объектов той же самой базы данных (влияние подобного ограничения на процесс планирования требуемой емкости дисков см. в главе 11). Для всех основных баз данных сервера, за исключением базы данных master, сегмент журнала транзакций (logsegment) необходимо вынести на отдельное серверное устройство. Как правило, это производится прямо в момент создания базы данных командой следующего формата: create database <имя_базы_данных> on <название_серверного_устройства_1> = <размер_в_мегабайтах_1>, log on <название_серверного_устройства_2> = <размер_в_мегабайтах_2> которая автоматически назначает logsegment второму серверному устройству, оставляя сегменты default и system на первом устройстве (рис. 8.14). В случае, если журнал транзакций не был вынесен в отдель" ный сегмент при создании базы данных, он будет перемешан с сегментами default и system. Для выноса на отдельное устройство журнала транзакций уже существующей базы данных используется процеду" ра sp_logdevice, применение которой описано в руководстве системного администратора (System Administration Guide). В дальнейшем предполагается, что сегмент журнала транзакций был размещен на отдельном устройстве в момент создания базы данных. Невозможность выноса журнала транзак" ций базы данных master вызвана тем, что она должна целиком находиться на одноименном серверном устройстве. Таким образом, сегментам system, default и logsegment базы данных master всегда доступно все дисковое пространство устройства master, распределенное этой базе данных. физический диск cOtOdO create database db1 on cOtOdOs1 = 80 log on cOtOdOs3 = 20 серверные устройства cOtOdOs1 и cOtOdOs3 созданы ранее командами disk init серверному устройству cOtOdOsI назначены следующие сегменты базы данных db1: default system серверному устройству cOt0dOs3 назначены следующие сегменты базы данных db1: logsegment logsegment рекомендуется назначать серверному устройству, находящемуся на физическом диске, не содержащем других сегментов базы данных и подключенном к другому контроллеру Рис. 8.14. Размещение сегмента журнала транзакций на отдельном серверном устройстве Сегменты и команда сервера alter database Итак, сегменты system и default только что созданной нами базы данных находятся на серверном устройстве 1, в то время как на серверном устройстве 2 размещен только сегмент журнала транзакций (logsegment). При добавлении базе данных дополнительного дискового пространства на серверном устройстве, уже содержащем определенные сегменты этой базы данных, этот же набор сегментов ав" томатически назначается и вновь распределенной области устройства. В нашем случае при расшире" нии командой alter database части базы данных, находящейся на серверном устройстве 1, новому экстенту будут назначены сегменты default и system, уже находящиеся на этом устройстве. При

www.books-shop.com

расширении базы данных на серверном устройстве 2 новая область будет использоваться только сег" ментом журнала транзакций. При расширении базы данных на новое серверное устройство, еще не содержащее ни одного ее сегмента, этому устройству назначаются сегменты default и system. Кроме того, новому устройству так" же будет назначен сегмент журнала транзакций, но лишь при условии, что он не был вынесен на от" дельное серверное устройство. Создание сегмента, определенного пользователем Как создать сегмент, не совпадающий ни с одним из трех уже знакомых вам сегментов default, system и logsegmenf? Будем называть их сегментами, определенными пользователем (user"defined); перед их со" зданием решите, должен ли новый сегмент находиться на отдельном серверном устройстве. Едва ли имеет смысл создавать еще один сегмент на устройстве, уже содержащем другие сегменты базы дан" ных, но все же покажем, как это делается. Для добавления пользовательского сегмента mysegO на сер" верное устройство 1 необходимо выполнить команду

sp.addsegment myseg0, серверное_устройство_1 В общем случае формат команды выглядит следующим образом: sp.addsegment <название_сегмента>, <название_серверного_устройства> Теперь в выводе команды sp_helpdb <имя_базы_данных> будет указано, что устройство сер" верное_устройство_1 содержит сегменты system, default и mysegO. Рассмотрим более интересный случай, когда создаваемый пользовательский сегмент необходимо поместить на отдельное серверное устройство. Расширим базу данных на это устройство командой alter database <имя_базы_данных> on <название_серверного_устройства_3> size= <размерЗ> Как отмечалось выше, поскольку серверное устройство 3 ранее не содержало сегментов базы дан" ных, ему автоматически назначаются сегменты system и default (рис. 8.15). Новому устройству также мог быть назначен сегмент журнала транзакций, если бы мы сразу не выделили его на серверное устройство 2. После выполнения команды alter database добавим на серверное устройство 3 но" вый сегмент myseg1 с помощью команды ep_addsegment myseg1, серверное_устройство_3. Набрав sp_helpdb <имя_базы_данных>, нетрудно убедиться, что на серверном устройстве 3 поя" вились три сегмента: system, default и mysegl. Однако до цели нам еще далеко, ведь помимо mysegl на новом устройстве имеется два других сегмента, в результате чего на серверном устройстве 3 могут оказаться посторонние объекты базы данных, относящиеся к сегментам system и default. Можно назвать сразу две причины, по которым этого следовало бы избежать. Во"первых, выделе" ние сегмента mysegl на отдельное серверное устройство (в идеальном случае подключенное к физический диск cOtOdO create database db1 on cOtOdOs1 = 80 log on cOt0dOs3 = 20 alter database db1 on cOtOdOs4 = 50 серверному устройству cOtOdOsI назначены следующие сегменты базы данных db1: default system серверному устройству cOtOdOs3 назначены следующие сегменты базы данных db1: logsegment серверному устройству cOtOdOs41 назначены следующие сегменты базы данных db1: default system

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

Рис. 8.15. Распространение базы данных на новое серверное устройство

www.books-shop.com

контроллеру, не используемому серверными устройствами, содержащими другие сегменты рассмат" риваемой базы данных), скорее всего, преследует цель повысить производительность сервера. Появ" ление на серверном устройстве 3 сегментов system и default означает утрату контроля за распределением объектов базы данных по устройствам. Любые обращения к находящимся на сер" верном устройстве 3 объектам сегментов system и default будут конфликтовать с обращениями к сег" менту myseg1. Во"вторых, область серверного устройства 3, выделенная командой alter database, может оказать" ся заполненной объектами из сегментов system и default, в то время как первоначально она предназна" чалась исключительно сегменту mysegl. Для того чтобы предотвратить возникновение перечисленных выше проблем, с помощью коман" ды sp_dropsegment удалите сегменты default и system с серверного устройства 3. В рассматривае" мом случае вводимые команды имеют следующий вид: sp_dropsegment system, серверное_устройство_3 sp.dropsegment "default", серверное_устройство_3 Обратите внимание на кавычки вокруг названия сегмента default, необходимые, поскольку слово default входит в число зарезервированных слов SQL Server. Отметим, что в том маловероятном слу" чае, когда серверное устройство 3 является единственным устройством сервера, содержащим сег" менты system или default соответствующей базы данных, эти сегменты удалить не удастся. Однако серверное устройство 3 выступает в роли дополнительного, предназначенного для размещения сег" мента mysegl отдельно от остальных сегментов базы данных, поэтому размещение сегментов system и default уже обеспечивают другие серверные устройства. Также отметим, что нельзя сначала удалить с серверного устройства все посторонние сегменты, а затем добавить на него пользовательский сег" мент. Любая создаваемая таблица или другой объект базы данных помещаются в „определенный сег" мент этой базы данных: либо в один из пользовательских сегментов, имя которого явно указывается при создании объекта, либо в сегмент default. Поэтому после распространения базы данных на сер" верное устройство с него нельзя удалить все сегменты этой базы данных, а удаление нежелательных сегментов производится уже после добавления пользовательского сегмента. Сегменты и планирование емкости устройств Следующий момент, когда снова возможна потеря контроля за распределением объектов базы дан" ных по серверным устройствам, наступает при расширении дискового пространства, распределенно" го пользовательскому сегменту mysegl. В случае, если пользовательский сегмент распространяется на новое серверное устройство, непродуманные действия администратора базы данных (или одного из его коллег) в данном случае могут опять привести к появлению на новом устройстве посторонних сег" ментов базы данных. Такой опасности не возникает при расширении сегмента в пределах того же са" мого серверного устройства, поскольку дополнительной области серверного устройства 3, распределенной базе данных командой alter database <имя_базы_данных> on сервер" ное_устройство_3 size = <размерЗ ' >, будут автоматически назначены сегменты базы данных, уже находящиеся на этом серверном устройстве (в нашем случае только сегмент mysegl). Еще раз под" черкнем, что сегменты базы данных назначаются всему серверному устройству, поэтому все области, распределяемые одной и той же базе данных в пределах одного устройства, обязательно содержат одни и те же сегменты. Однако при распространении сегмента на новое устройство следует соблюдать осто" рожность (если, конечно, речь не идет о расширении сегментов system и default). Как и в предыдущем примере, в результате выполнения команды alter database <имя_базы_данных> on серверное_устройство_4 50 сервер автоматически назначит новой области серверного устройства 4 сегменты system и default (а также logsegment, если он не находится отдельно от остальных сегментов базы данных). Разумеется, при расширении сегментов system или default именно это и требуется сделать. В случае расширения сегмента журнала транзакции необходимо использовать процедуру sp_extendsegment. Команда sp_extendsegment logsegment, <название_серверного_устройства> добавит logsegment на указанное серверное устройство и затем автоматически удалит с него все остальные сегменты (напри" мер, system и default), ранее назначенные этому же устройству. Подчеркнем, что подобные действия осуществляются процедурой sp_extendsegment только при обработке сегмента журнала транзак" ций. По сути, процедура sp_extendsegment просто копирует схему назначения сегментов рассмат" риваемой базы данных на других устройствах, содержащих logsegment, поскольку все подобные устройства поддерживают только этот сегмент базы данных. При распространении любого пользова" тельского сегмента на новое серверное устройство администратору базы данных необходимо

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

физический диск cOtOdO

create database db1 on cOtOdOs1 = 80 log on cOtOdOs3 = 20 alter database db1 on cOtOdOs4 = 50 sp_addsegment myseg1, cOtOdOs4 sp_dropsegment system, cOtOdOs4 sp_dropsegment "default", cOtOdOs4 серверному устройству cOtOdOsI назначены следующие сегменты базы данных db1: default system серверному устройству cOtOdOs3 назначены следующие сегменты базы данных db1: logsegment серверному устройству cOtOdOs41 назначены следующие сегменты базы данных db1: mysegl

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

Рис. 8.16. Создание сегмента, определенного пользователем полностью повторить всю процедуру, описанную в предыдущем разделе главы: командой alter da" tabase распространить базу данных на новое серверное устройство, затем добавить пользователь" ский сегмент, после чего удалить с нового устройства ненужные сегменты system и default. Представьте себе, что однажды, когда вас не было на работе, вашему коллеге, админи+ стратору базы данных, срочно понадобилось добавить дополнительное дисковое про+ странство самой крупной базе данных в вашей основной информационной системе. Случайно столкнувшись с этим фактом впоследствии (никто не побеспокоился внести его в рабочую документацию), вы обнаруживаете, что пространство было добавлено на новом серверном устройстве, ранее не поддерживавшем обсуждаемую базу данных, и там присутствуют сразу три сегмента: system, default и data. Если первые два сегмента не вызывают у вас никаких подозрений, то сегмент data выглядит здесь явно лишним. После некоторых раздумий вы вспоминаете, что когда+то в базе данных действительно был создан сегмент с названием data, призванный изолировать наиболее объемные таб+ лицы базы данных на отдельном диске, подключенном к отдельному контроллеру. Появ+ ление этого сегмента на новом устройстве вместе с сегментами system и default делает бессмысленным само существование сегмента data по двум причинам. Во+первых, никто не гарантирует, что новый раздел сегмента data находится на правильном физическом диске, тоже подключенном к контроллеру, но обслуживающему остальную часть базы данных. Теперь любые обращения к сегменту data несут реальную угрозу конкуренции с операциями обработки других данных, хранящихся на том же устройстве, диске и других дисках, подключенных к общему контроллеру. Во+вторых, любые обращения к частям сегментов system и default, размещенным на новом устройстве, будут конфликтовать с обращениями к аналогичной части сегмента data. Исправить создавшуюся ситуацию со+ всем не просто. Потребуется получить полный список объектов сегмента data, использу+ ющих новое серверное устройство, и перенести все такие объекты на правильные серверные устройства, выделенные под сегмент data. Для этого необходимо командой bср вывести все данные затронутых таблиц в файл, после чего удалить таблицы, воссоз+ дать их заново на нужном месте, загрузить данные и т.д. Подобный процесс, весьма тру+ доемкий, грозит новыми ошибками. Отсюда вывод: пользовательские сегменты крайне полезны, но их применение требует эффективного и хорошо организованного админист+ рирования сервера.

www.books-shop.com

Расширение пространства пользовательского сегмента Итак, сегменты играют существенную роль при планировании конфигурации дискового пространст" ва сервера (см. главу 11) и расширении баз данных в процессе эксплуатации. Для каждого сегмента базы данных, который должен размещаться отдельно от остальных ее сегментов, фактически требу" ется создать отдельное серверное устройство (рис. 8.16). В приведенном выше примере одно устрой" ство используется для размещения сегментов default и system, другое — для сегмента журнала транзакций, на третьем находится пользовательский сегмент myseg1. Поскольку схема размещения сегментов применима только к целым серверным устройствам, при исчерпании свободного места на одном из перечисленных устройств соответствующий сегмент придется распространять на новое устройство, не содержащее других сегментов базы данных. Таким образом, получается, что всегда требуется держать в запасе несколько дополнительных устройств; по заполнении всех трех первона" чально распределенных устройств общее число используемых серверных устройств достигнет шести. Вспомнив теперь о необходимости зеркального резервирования данных, осуществляемого опять же на уровне серверных устройств целиком, мы убеждаемся в том, что работа с пользовательскими сег" ментами означает поддержку большого числа серверных устройств и физических дисков. Заключительные замечания по сегментам баз данных При работе с сегментами баз данных возможны ситуации, зачастую связанные с особенностями раз" личных сегментов баз данных: • На одном серверном устройстве находится несколько сегментов различных баз данных • Сегменты system и default находятся на одном устройстве • Сегменты system и default назначены объектам базы данных по умолчанию • Серверные устройства разделяются на устройства данных и устройства журналов транзакций • Существуют ограничения на использование устройств журналов транзакций • Сегмент журнала транзакций не вынесен на отдельное устройство • Перед добавлением сегментов соответствующее устройство должно быть распределено базе данных • Удаление всех сегментов невозможно • Сегмент всегда является частью конкретной базы данных На одном серверном устройстве несколько сегментов различных баз данных Как мы неоднократно подчеркивали, большинство сегментов базы данных должны размещаться на различных серверных устройствах отдельно друг от друга (за исключением сегментов system и default, часто помещаемых вместе). Однако нет серьезных причин, препятствующих одновременному разме" щению сегментов разных баз данных на одном устройстве. Так, серверное устройство вполне может содержать сегмент журнала транзакций базы данных databasel, сегменты system и default базы данных database2, а также определенный пользователем сегмент mysegl базы данных database3 (рис. 8.17). физический диск сОt0d0

серверное устройство cOt0dOs1 содержит: logsegment базы данных db1 сегменты system и default базы данных db2 сегмент myseg1 базы данных dbЗ

Рис. 8.17. Размещение сегментов различных баз данных на одном серверном устройстве

www.books-shop.com

На одном устройстве сегменты system и default При необходимости сегменты system и default могут быть разнесены на различные устройства. И все же предпочтительнее использовать имеющиеся устройства для выделения конкретных объектов базы данных (чаще всего таблиц и индексов), оставив сегменты system и default вместе на одном устройстве. Сегменты system и default назначены объектам базы данных по умолчанию В документации Sybase слово "default" имеет целый ряд значений; в частности, не следует смешивать название сегмента default с серверными устройствами, используемыми по умолчанию (default server device). Кроме того, при создании базы данных командой create database на соответствующем серверном устройстве автоматически создаются сегменты system и default — вне зависимости от того, было ли это устройство явно указано в команде или используется одно из серверных устройств, на" значаемых по умолчанию. Удалить с устройства нежелательные сегменты можно только после добав" ления туда других сегментов этой же базы данных. Серверные устройства данных и журналов транзакций В документации на SQL Server серверные устройства часто разделяются на устройства данных (data devices) и устройства журналов транзакций (log device); при этом устройством данных называется серверное устройство, содержащее любые сегменты базы данных, за исключением ее сегмента журна" ла транзакций. Ограничения на использование устройств журналов транзакций Выделив сегмент журнала транзакций базы данных на отдельное серверное устройство, вы больше не сможете поместить туда никакие другие сегменты той же самой базы данных вплоть до переноса сег" мента журнала транзакций на новое устройство командой sp_logdevice . По этой же причине logseg ment нельзя распространить на серверные устройства, уже содержащие другие сегменты базы данных. Гипотетическая ситуация, когда logsegment находится на всех серверных устройствах, выделенных базе данных, приведет к невозможности размещения всех остальных объектов этой базы данных, ко" торые должны находиться в сегментах system, default и сегментах, определенных пользователем. Сегмент журнала транзакций не вынесен на отдельное устройство Сегмент журнала транзакций может помещаться вместе с сегментами system и default только в том слу" чае, если нет необходимости создавать дампы журнала транзакций (необходимые для восстановле" ния базы данных после сбоя). Еще раз подчеркнем, что сохранение дампов журнала транзакций возможно только при условии его вынесения на отдельное серверное устройство. Перед добавлением сегментов соответствующее устройство должно быть распределено базе данных На серверном устройстве, не распределенном базе данных командами create database или alter database, нельзя создавать новые сегменты этой базы данных или распространять туда уже сущест" вующие сегменты. Перед тем как приступить к размещению сегментов на новом устройстве, часть его пространства должна быть назначена базе данных; как отмечалось выше, при этом устройству автома" тически назначаются сегменты system и default. Невозможно удалить все сегменты Для каждого из обязательных сегментов system, default и logsegment должно существовать по крайней мере одно серверное устройство, поддерживающее соответствующий сегмент. Поэтому эти сегменты не могут быть удалены со всех серверных устройств. По той же причине нельзя удалить серверное устройство, если оно единственное поддерживает один из перечисленных сегментов базы данных. Перед удалением последнего из серверных устройств, поддерживающих пользовательский сегмент базы данных, этот сегмент необходимо удалить из базы данных. Со всех остальных серверных устройств можно удалить все имеющиеся на них сегменты баз данных; однако такие устройства стано" вятся полностью недоступными для использования сервером. Сегмент всегда является частью определенной базы данных Сегмент существует только внутри определенной базы данных. Кроме того, любой сегмент базы дан" ных, назначенный серверному устройству, может занять всю область этого устройства, распределен" ную соответствующей базе данных.

www.books-shop.com

Размещение журналов транзакций Журнал транзакций (также называемый журналом повтора) существует в каждой базе данных и испо" льзуется сервером для регистрации всех изменений, вносимых в базу данных. Сервер обладает целым рядом механизмов защиты содержимого журнала транзакций, гарантирующих возможность восста" новления базы данных после сбоев. Использование журналов транзакции требует хорошего понима" ния их особенностей, связанных, в частности, с организацией сегментов баз данных. Размещение журнала транзакций на отдельном серверном устройстве Журнал транзакций — один из важнейших элементов Sybase SQL Server, гарантирующий целостность данных и возможность их восстановления в случае сбоев базы данных, сервера или серверной маши" ны. В этом и в ряде следующих разделов главы будет показано, как достичь оптимального баланса между безопасностью данных, обеспечением гарантий их восстановления после сбоев и производите" льностью сервера. Хотя размещение сегмента журнала транзакций (logsegment) отдельно от серверных устройств, поддерживающих другие сегменты базы данных, не является обязательным, на практике реализуется почти всегда именно такая конфигурация. Посмотрим, на чем основано подобное прави" ло и в каких случаях его можно нарушить. Главной причиной, заставляющей выделять сегмент журнала транзакций в отдельное серверное устройство, служит необходимость регулярного сохранения дампов журнала повтора без создания полного дампа базы данных (роль подобных дампов рассматривается в главе 9 при обсуждении про" цесса восстановления баз данных после сбоев). Полный дамп базы данных создавать намного доль" ше, чем дамп журнала транзакций; кроме того, из"за отсутствия достаточного дискового пространства дампы больших баз данных часто можно сбрасывать только на магнитную ленту, что еще более замедляет процесс. Продолжительное время сохранения дампов замедляет работу всей информационной системы и сокращает сроки использования сервера по его основному назначе" нию. Длительность создания полных дампов баз данных не позволяют строить их так часто, как это требуется на практике. Кроме того, при создании полного дампа базы данных не производится очи" стка ее журнала транзакций; наоборот, при сохранении отдельного дампа журнала транзакций все включенные в дамп завершенные транзакции автоматически удаляются из журнала транзакций. По" добная операция называется усечением (truncation), или очисткой журнала транзакций. Регулярное сохранение дампов журнала транзакций имеет особое значение для обеспечения как можно более полного восстановления базы данных после сбоев. Помимо наличия исчерпывающего набора дампов журнала транзакций, здесь также необходимо иметь достаточно свежий полный дамп базы данных. Кроме того, очень важно, чтобы сервер находился в работоспособном состоянии и мог прочитать содержимое системной таблицы sysdatabases, находящейся в базе данных master. Таким образом, практически во всех случаях сегмент журнала транзакций каждой базы данных требуется выносить на отдельное серверное устройство. Как уже отмечалось, это устройство дол" жно находиться на физическом диске, не содержащем других объектов базы данных и подключен" ном к отдельному контроллеру. Совместное размещение журнала транзакций с другими сегментами базы данных Не все базы данных сервера требуют при своем восстановлении обязательного наличия дампов жур" нала транзакций. Для восстановления некоторых баз данных вполне достаточно их последнего пол" ного дампа. Именно в таких базах данных имеет смысл размещать журнал повтора совместно с другими сегментами. Наглядным примером тому может служить архивная база данных, содержащая некоторую статичную часть основной базы данных и используемая редко выполняемыми приложени" ями, требующими большого объема обработки информации, (например, приложение генерации еже" месячного отчета по всем принятым заказам, необходимое руководству компании при принятии стратегических решений). В подобной базе данных за очень короткое время создается весьма значи" тельный журнал транзакций, но после завершения обработки вся база данных сохраняется в неизмен" ном виде и для ее резервирования проще всего ограничиться сохранением полного дампа. Вне зависимости от того, запускается ли приложение генерации отчета вручную специально отвечающим за это сотрудником либо активизируется автоматически как cron"задача на уровне операционной сис" темы, немедленно после окончания обработки архивной базы данных следует создать ее полный дамп. Соответствующие команды лучше всего включить непосредственно в командные файлы, осуще" ствляющие обработку этой базы данных. Поскольку между генерацией месячных отчетов архивная

www.books-shop.com

база данных используется практически исключительно для чтения итоговых данных, в эти периоды ее журнал транзакций фактически не будет пополняться новой информацией и восстановление базы данных по последнему полному дампу окажется вполне корректным. Есть и еще одна причина, поче" му журнал транзакций подобной базы данных не следует выносить на отдельное устройство: посколь" ку в редкие периоды активности он принимает весьма значительные размеры, для него потребуется серверное устройство достаточной величины, которое в промежутках между генерацией отчетов во" обще не будет использоваться базой данных. Таким образом, в рассмотренном примере журнал тран" закций следует не только разместить совместно с другими сегментами базы данных, но и распространить на все серверные устройства, выделенные этой базе данных. Подобная конфигура" ция базы данных создается автоматически при вызове команды create database без параметра log on. Хотя на практике к такому приему приходится прибегать крайне редко, о его существовании надо знать. Определение оптимального размера журнала транзакций При определении конфигурации базы данных часто требуется оценить оптимальные размеры ее жур" нала транзакций. В следующих разделах главы рассматривается процесс заполнения журнала транзак" ций, поэтому рекомендуем обратиться к главе 12, где приводится понятие порогов (thresholds), позволяющих избежать переполнения журнала повтора. Стоит ли делать журнал транзакций как можно больше На практике оптимальный размер журнала транзакций меняется с каждым днем (или даже чаще). Пе" реполнения журнала транзакций, что является серьезным нарушением, следует избегать. Дело в том, что для обеспечения восстановления базы данных после сбоев серверу необходимо регистрировать в журнале транзакций все операции, совершаемые с базой данных. При заполнении журнала транзак" ций база данных становится совершенно бесполезной вплоть до того момента, пока хотя бы неболь" шая часть журнала транзакций не будет освобождена путем создания дампа. Однако при полном отсутствии свободного места в журнале транзакций его усечение путем сохранения дампа становится невозможным, поскольку сама операция создания дампа этого журнала требует внесения в него до" полнительной записи, используемой при проверке порядка следования загружаемых дампов журнала транзакций. В подобной ситуации команду создания дампа журнала транзакций придется ввести с ука" занием параметра no_log (предварительно еще раз убедившись, что журнал транзакций совершен" но заполнен; см. главу 12). При указании параметра no_log журнал транзакций действительно усекается, но без сохранения в дампе копий удаляемых записей регистрации транзакций, т.е. факти" чески без создания самого дампа. Отсутствие хотя бы одного дампа в последовательности дампов жур" нала транзакций означает невозможность загрузки при восстановлении базы данных всех дампов журнала транзакций, следующих после пропущенного. Более того, после усечения журнала транзак" ций с параметром no_log и вплоть до создания полного дампа базы данных сервер больше не позво" лит вам сохранять новые дампы журнала транзакций, поскольку они все равно окажутся бесполезными. Таким образом, база данных при переполнении ее журнала транзакций по сути стано" вится недоступной для пользователей. В этой ситуации необходимо срочно очистить журнал транзак" ций командой создания дампа этого журнала с указанием параметра no_log (что займет определенное время, в течение которого база данных будет по"прежнему недоступна). Затем немед" ленно сохраните полный дамп базы данных (в противном случае вы рискуете утратить все транзак" ции после создания последнего успешного дампа журнала транзакций). Кстати, чем больше размеры переполнившегося журнала транзакций, тем больше времени потребуется на его очистку командой создания дампа с параметром no_log. Итак, недопустимо переполнение журнала транзакций ни од" ной из баз данных, важных для обеспечения деловой активности компании. Здесь, естественно, воз" никает желание сделать журнал транзакций как можно больше: чтобы он никогда не переполнялся. Подобное решение — серьезная ошибка. Рекомендуемые размеры журнала транзакций Получается, что те же самые пользователи, которые сегодня требовали от вас увеличить размер жур" нала транзакций, завтра могут начать настаивать на его сокращении. Однако распределенное базе данных дисковое пространство нельзя отобрать назад без полной перестройки логической структуры базы данных (см. главу 9). По всей вероятности, вам уже известна общая рекомендация резервиро" вать для журнала транзакций 20% всего пространства, распределенного базе данных. Действительно, такая оценка вполне разумна для большинства баз данных. Но стоит ли применять правило 20% к крупным базам данных? Так ли уж необходим 10"Гбайт базе данных журнал транзакций длиной 2 Гбайт? Чтобы ответить на этот вопрос, проанализируем характер изменений, вносимых в

www.books-shop.com

конкретную базу данных. В целом принцип 20% хорошо применим к небольшим базам данных, но его соблюдение при планировании баз данных значительного объема может привести к непроизводите" льному использованию имеющегося дискового пространства. Здесь лучше оценить средний объем транзакций в базе данных и выяснить размер типичной транзакции. При этом необходимо учиты" вать, как часто планируется сохранять дампы журнала транзакций. На основании результатов такой оценки нетрудно определить разумные размеры журнала транзакций, способного вместить в себя за" писи обо всех транзакциях, которые должны находиться в нем в каждый конкретный момент. К сожа" лению, на практике у администратора сервера обычно нет ни адекватных технических средств, ни времени для подобного анализа. Не забывайте, что речь идет всего лишь об одной базе данных на од" ном из многочисленных серверов, входящих в вашу информационную систему. Возможен более реа" льный подход. Попробуйте оценить размер журнала транзакций при первоначальном создании базы данных, по возможности воспользовавшись помощью разработчиков приложений. А после этого про" следите, как конкретные приложения поведут себя в процессе эксплуатации. Попытки увеличить раз" мер журнала транзакций, чтобы уберечь его от переполнения, окажутся тщетными. В следующих разделах главы вы увидите, как одна"единственная незавершенная транзакция способна вызвать пере" полнение журнала транзакций, даже если у него были большие размеры. Никогда без серьезных на то оснований не создавайте журналы транзакций, по размерам превышающие 200 Мбайт. Если в серве" ре все же существует база данных, на ваш взгляд, заслуживающая журнала транзакций больших разме" ров, обязательно уясните себе, в силу каких именно причин этой базе данных регулярно требуется столь большой журнал транзакций. Кроме того, подумайте, как вы собираетесь обрабатывать дампы журнала транзакций такого размера (в главе 9 обсуждается, к каким проблемам приводит создание слишком больших дампов журналов транзакций).

Усечение журнала транзакций Остановимся на принципах работы журнала транзакций и причинах, приводящих к его переполне" нию. Перед внесением каких бы то ни было изменений в базу данных сервер записывает эти измене" ния в ее журнал транзакций. Записи такого журнала содержат каждый шаг каждой транзакции, совершенной по отношению к этой базе данных. Транзакция состоит из начала и ряда промежуточ" ных шагов, которые завершаются либо фиксацией транзакции, либо ее откатом. С точки зрения сер" вера не так важно, чем закончилась транзакция: фиксацией или откатом. Существенное значение имеет факт ее завершения. Поскольку все вносимые в базу данных изменения одновременно вводятся в журнал транзакций, этот журнал продолжает непрерывно расти. Размеры журнала транзакций мож" но уменьшить только путем его усечения, которое производится после сохранения дампа журнала транзакций, когда все записи зафиксированных транзакций сбрасываются на указанное вами устрой" ство вывода дампов и затем уничтожаются сервером. Таким образом, при создании очередного дампа журнала транзакций размеры этого журнала обычно сокращаются. Однако здесь есть одна не слиш" ком заметная, а поэтому очень опасная ловушка, порой приводящая к катастрофическим последстви" ям. Дело в том, что при сохранении дампа журнала транзакций сервер последовательно просматривает записи транзакций, определяя, какие из них могут быть уничтожены для сокращения размеров журнала. Фактически сервер ищет запись о самой первой из транзакций, еще не завершен" ных на момент ввода команды dump transaction. Обнаружив такую запись, сервер прекращает усе" чение журнала транзакций. В результате ему удается удалить ненужные записи журнала транзакций только до момента самой старой из незавершенных (открытых) транзакций. Создание дампа переполнившегося журнала транзакций невозможно При заполнении журнала транзакций администратор базы данных оказывается в непростой ситуа" ции. Во"первых, сервер не может вносить в заполненный журнал транзакций записи о новых транзак" циях, поэтому база данных становится недоступной для вставки и модификации данных (выборка данных командой select по"прежнему производится, поскольку не регистрируется в журнале транзак" ций). Попытки сервера внести новые записи в переполнившийся журнал транзакций завершаются сообщением об ошибке под номером 1105 (этого можно избежать с помощью механизма порогов, рассматриваемого в главе 12). Появление в журнале регистрации ошибок сообщения об ошибке 1105 означает переполнение одного из сегментов базы данных, который совсем не обязательно является сегментом журнала транзакций. В главе 12 рассказывается, как определить сегмент, переполнение ко" торого вызвало ошибку 1105; пока же предположим, что ошибка 1105 связана именно с журналом транзакций и попытка сохранить дамп журнала транзакций командой dump transaction без указания параметра no_log не привела к его усечению. Последнее означает, что сервер больше не способен создавать дампы журнала транзакций; подобное ограничение выглядит не вполне логичным, но его неизбежность становится очевидной при рассмотрении процесса восстановления базы данных. Для

www.books-shop.com

восстановления базы данных необходимо сначала загрузить последний ее полный дамп, а затем по" следовательно загружать сохраненные дампы журнала транзакций. В процессе загрузки дампов сер" вер проверяет имеющиеся в каждом дампе отметки времени, гарантирующие непрерывность и корректность последовательности воспроизводимых транзакций. Непосредственно перед началом сохранения дампа журнала транзакций сервер должен внести в журнал одну из подобных отметок, ко" торая фиксирует момент начала создания дампа. Переполнение журнала транзакций делает эту опе" рацию невозможной, что в свою очередь исключает создание очередного дампа. Усечение переполнившегося журнала транзакций Единственный выход из описанной выше ситуации — выполнение команды создания дампа журнала транзакций с параметром no_log. Это существенно ограничивает возможности восстановления со" ответствующей базы данных после сбоев, так что эту команду следует использовать только при нали" чии серьезных оснований и ясного понимания всех ее последствий (см. главу 9). При указании параметра no_log сервер не пытается внести в журнал транзакций какие"либо дополнительные запи" си. Поскольку в этом случае полученный дамп журнала транзакций не содержал бы отметки времени его создания и любая попытка его загрузки все равно была бы отвергнута сервером, нет ни малейше" го смысла пытаться выводить в дамп удаляемые записи журнала повтора. Поэтому параметр no_log приводит к удалению из журнала всех записей о завершенных транзакциях без их сохранения в дам" пе. Как отмечалось выше, процесс удаления записей завершается, когда сервер встречает первую за" пись о транзакции, которая еще не закончилась. Усечение переполнившегося журнала транзакций оказывается безуспешным Продолжим обсуждение ошибки 1105. Получив сообщение об этой ошибке и убедившись, что журнал транзакций действительно переполнился (соответствующая процедура описана в главе 12), введите команду dump transaction <имя_базы_данных> with no_log Вы с удивлением обнаружите, что оказались в одной из тех нередких ситуаций, когда даже пара" метр no_log не позволяет освободить пространство в журнале транзакций. Почему? Как не раз от" мечалось выше, процесс усечения этого журнала останавливается на первой записи об открытой (незавершенной) транзакции. Представьте себе вполне реальную возможность, когда самая первая транзакция в журнале транзакций как раз оказывается открытой. Здесь серверу не удастся удалить из журнала ни одной транзакции вне зависимости от того, был ли указан ему параметр no_log. Единственный выход из создавшейся ситуации — выявить серверный процесс, которому принадле" жит ставшая источником проблемы открытая транзакция, и уничтожить его командой kill (что приведет к удалению из журнала транзакций записей о всех незавершенных транзакциях, относив" шихся к данному процессу). Хотя в команде kill должен быть явно указан идентификатор сервер" ного процесса (spid), на самом же деле прямого способа установить, какой именно процесс блокирует очистку журнала транзакций, нет. Конечно, администратор сервера может на основании разумных предположений выделить несколько подозрительных процессов и уничтожить их все, но если эта процедура затянется, самым простым выходом станет перезапуск сервера. По мере завер" шения перезапуска сервера и восстановления нормального состояния базы данных у вас появится возможность создать дамп журнала транзакций обычными средствами. Размеры журнала транзакций: будьте разумны Итак, одна открытая транзакция рано или поздно с неизбежностью приводит к переполнению журна" ла транзакций вне зависимости от того, насколько велики его размеры. Увеличение журнала транзак" ций не исключает возможность его переполнения, но в то же время значительно удлиняет время выполнения команды dump transaction <имя_базы_данных> with no_log Таким образом, чрезмерно большой журнал транзакций лишь увеличивает продолжительность кризиса. Вдобавок к периоду, в течение которого база данных оказывается практически неработос" пособной из"за переполнения журнала транзакций (разрешена выборка данных, но не их модифика" ция), мы продлеваем указанное состояние базы данных еще на время очистки журнала транзакций. Не пытайтесь избежать переполнения журнала транзакций путем увеличения его размеров: подоб" ные попытки все равно окажутся напрасными.

www.books-shop.com

Первоначальная оценка размеров журнала транзакций Создавая базу данных, предварительно определите необходимые размеры журнала транзакций. Мож" но установить его, к примеру, равным 20% общего объема базы данных. Если в процессе эксплуата" ции обнаружится, что журнал транзакций заполняется чаще, чем хотелось бы, и вам удастся выяснить, почему определенные приложения генерируют столь большой объем транзакций, можно расширить журнал транзакций командой alter database. При этом будьте максимально осторожны, по" скольку слепое следование правилу 20% может стать источником дополнительных проблем. Пусть одна из основных баз данных реальной информационной системы имеет размер 5 Гбайт, а ее журнал транзакций составляет 200 Мбайт (лишь 4% общего объема базы данных). При заполнении такого журнала транзакций запись на диск его дампа занимает около 30 мин. Сможет ли ваша компания по" зволить себе остаться без основной базы данных (точнее, без возможности вносить в базу данных из" менения и пополнять ее новой информацией) на еще больший период времени? Не забудьте, что основная часть информации, накопленной в рассматриваемой базе данных, уже не вполне нова и с каждым днем продолжает еще больше устаревать. По всей видимости, многие пользователи базы дан" ных работают лишь с незначительной ее частью, а если принять во внимание фактические размеры этой активной области, то 200"Мбайт журнал транзакций уже не покажется таким уж малым. Итак, пе" ред увеличением размеров журнала транзакций необходимо понять, действительно ли пользователям базы данных при работе с имеющимися приложениями удастся заполнить расширенный журнал транзакций. Обычное правило 20% дает разумные результаты, пока размеры журнала транзакций не выходят за пределы 100 Мбайт. Перед созданием журнала транзакций большей длины убедитесь, что и вы сами, и ваши пользователи ясно понимаете, насколько долго будет происходить очистка такого журнала, когда он все"таки переполнится. Пусть вам и удастся избежать этого, однако создание дампа даже частично заполненного журнала транзакций может занять весьма продолжительное время, если в журнале накопится значительный объем информации. Это чаще всего имеет место, когда в силу ка" ких"то причин не удается сохранить несколько запланированных дампов журнала транзакций. Поско" льку журнал транзакции будет продолжать накапливать записи о выполненных транзакциях, на создание очередного дампа журнала потребуется намного больше времени, чем обычно. Журнал транзакций никогда не бывает слишком большим Подробно объясните своему руководству и пользователям следующее: ни в одной базе данных журнал транзакций не может быть отключен. Вне зависимости от своих размеров он все равно переполнит" ся, если хотя бы один пользователь откроет транзакцию и забудет завершить ее фиксацией или отка" том. С увеличением размеров журнала транзакций на создание его дампа будет уходить все больше времени. Конечно, пользователи всегда хотят иметь журнал транзакций как можно большего разме" ра, чтобы сократить простои базы данных из"за его переполнения, но те же самые пользователи едва ли обрадуются увеличению периодов недоступности базы данных при создании дампов слишком длинного журнала транзакций. Зеркальное резервирование серверных устройств Научившись контролировать распределение сегментов баз данных по серверным устройствам, пора бы побеспокоиться и о создании зеркальных копий этих устройств. Зеркальная копия серверного устройства представляет собой еще один небуферизованный раздел диска или файл операционной системы, назначенный этому же устройству. Запись в зеркальную копию осуществляется сервером од" новременно с записью в основное устройство. Отметим, что здесь не рассматривается зеркальное отображение устройств с использованием аппаратных средств или средств операционной системы — нас интересует создание зеркальных копий исключительно средствами самого сервера. Что такое зеркальная копия SQL Server обеспечивает зеркальное отображение устройств путем создания копии одного сервер" ного устройства на другом. При этом исходное устройство называется первичным, или основным, устройством зеркальной пары, а второе — зеркальной копией, или вторичным устройством пары (рис. 8.18). После создания пары зеркальных устройств SQL Server автоматически записывает все изменения как в основное устройство, так и в его зеркальную копию. Сервер, обнаружив ошибку на главном устройстве, автоматически переключается на второе устройство пары, не прекращая обра" ботку запросов. Наоборот, если обнаружится ошибка на вторичном устройстве пары, SQL Server не" медленно выводит его из состава пары и продолжает обработку с использованием лишь одного главного устройства. Практически идентичные возможности обеспечивает аппаратное резервиро" вание массивов дисков в дисковых системах, использующих избыточный массив недорогих дисков 14—2221

www.books-shop.com

серверное устройство cOtOdOs1

ОТОБРАЖАЕТСЯ НА

дисковый раздел с небуферизованным доступом /dev/rdsk/cOtOd6s1

главное серверное устройство

вторичное серверное устройство (зеркальная копия) Основное серверное устройство cOtOdOs1 и его зеркальная копия cOtOd6s1 образуют зеркальную пару, которая по+прежнему обрабатывается сервером в качестве единого логического дискового устройства с названием 'cOtOdOs1'. Рис. 8.18. Зеркальное резервирование серверного устройства (Redundant Array of Inexpensive Drives, RAID). Они служат дополнительной гарантией сохранности наиболее важных баз данных. Все вопросы, связанные с приобретением и эксплуатацией дисковых систем RAID (возможные уровни избыточности, выбор конкретной конфигурации RAID"системы, це" лесообразность использования в RAID"системах дисков третьих фирм и т.д.), остаются за рамками данной книги. Когда следует прибегнуть к зеркальному отображению устройств Необходимость организации зеркального резервирования серверных устройств и баз данных, нахо" дящихся на этих устройствах, обусловлена рядом причин. Самая очевидная из них — стремление со" кратить время недоступности баз данных при возникновении сбоев дисковых накопителей. Говоря точнее, зеркальное резервирование уменьшает период недоступности при сбоях дисков, но не позво" ляет устранить его полностью. При аварии диска с серверным устройством, не имеющим зеркальной копии, все базы данных, использовавшие отказавшее устройство, переходят в неработоспособное со" стояние. В зависимости от конкретного состава пострадавших баз данных сам SQL Server либо сохра" няет работоспособность частично, либо утрачивает ее (последнее происходит, например, при потере серверного устройства master или устройства, содержащего журнал транзакций одной из основных баз данных). Однако с самими пострадавшими базами данных работать, безусловно, уже не" возможно. Если применяется зеркальная копия, SQL Server при возникновении ошибок немедленно переключается на нее и перестает использовать отказавшее устройство. В подобной ситуации рано или поздно все равно придется отключить сервер и серверную машину для замены вышедшего из строя диска, но здесь администратор сервера по крайней мере может выбрать момент, когда останов сервера не скажется на нормальной работе пользователей. Зеркальное резервирование устройства master Прежде всего администратору сервера необходимо создать зеркальную копию серверного устройства master, обеспечивающую зеркальное резервирование базы данных master, первых 2 Мбайт базы дан" ных tempdb и базы данных model Наличие зеркальной копии устройства master особенно важно по сле" дующим двум причинам. Во"первых, возникновение каких"либо проблем с серверным устройством master грозит утратой базы данных master, что означает полный останов сервера и всех его баз дан" ных. Используя зеркальную копию устройства master, сервер может продолжать свою работу несмот" ря на сбои одного из устройств зеркальной пары. Во"вторых, полная утрата устройства master означает утрату всего сервера и существенно затрудняет его восстановление. В подобной ситуации при отсутствии зеркальной копии устройства master администратору сначала потребуется заново со" здать базу данных master, повторно внести в нее все изменения конфигурации сервера, необходимые для его полного восстановления (например, добавить в конфигурацию SQL Server 4.9.2 устройство

www.books-shop.com

вывода дампов, без которого загрузка дампов становится невозможной), загрузить дамп базы данных master и затем перейти к восстановлению остальных компонентов сервера. Наличие зеркальной ко" пии устройства master позволяет избежать самого трудоемкого этапа воссоздания сервера — восста" новления базы данных master. Итак, в сервере всегда должна иметься зеркальная копия устройства master. Поскольку устройство master обычно является самым малым из всех серверных устройств, вам будет непросто оправдать свой отказ от его зеркального резервирования. Зеркальное резервирование журналов транзакций пользовательских баз данных Обязательно создайте зеркальные копии не только устройства master, но и всех серверных устройств, на которых находятся журналы транзакций важнейших пользовательских баз данных. Важнейшими здесь считаются базы данных, состояние которых после восстановления должно как можно более соответствовать состоянию на момент сбоя. Исходя из особенностей деловой активно" сти компании, администратор сервера определяет, утрату какого количества информации можно считать допустимой. К тому же восстановление последнего полного дампа базы данных и серии по" следующих дампов журнала транзакций приводит базу данных к состоянию, имевшему место на мо" мент создания последнего дампа журнала транзакций (см. главу 9). Все последующие транзакции окажутся утраченными, если не удастся использовать содержимое текущего журнала транзакций. Со" здание зеркальной копии журнала транзакций базы данных гарантирует, что при возникновении проблем в вашем распоряжении заведомо будет находиться точная копия текущего журнала транзак" ций, даже если основной экземпляр журнала транзакций окажется утраченным вместе с главным устройством зеркальной пары. Для организации зеркального резервирования журнала транзакций любой базы данных достаточно создать зеркальную копию серверного устройства, содержащего сег" мент журнала транзакций этой базы данных. Зеркальное резервирование при необходимости замены отказавшего диска Механизм зеркального отображения серверных устройств значительно облегчает процесс замены от" казавшего дискового накопителя. Даже если в сервере не все устройства имеют зеркальные копии, бу" дьте готовы в любой момент создать зеркальные копии всех устройств отдельного физического диска. Это нужно, чтобы в случае отказа какого"либо диска немедленно отобразить все расположен" ные на нем серверные устройства на другие диски сервера (рис. 8.19). Дело в том, что далеко не все" гда отказавший диск немедленно становится полностью недоступным. Если при постепенном отказе диска какое"то время будет сохраняться возможность прочитать записанную на нем информацию, не" медленное создание зеркальной копии диска позволит сохранить все находящиеся на нем до момента его полного отказа данные. В других ситуациях отказ диска приводит к порче определенного раздела (или нескольких разделов) диска. И здесь полезно создать зеркальные копии оставшихся доступными серверных устройств, удалить исходные устройства с отказавшего диска и заменить сам диск. После этого повторно отобразите копии прежних устройств на новый диск, восстановив тем самым исход" ные серверные устройства на их обычном месте. Подобные действия значительно надежнее, чем вос" становление баз данных из дампов, и осуществляются быстрее. Кроме того, при надлежащем выполнении всех операций они помогают избежать каких"либо потерь информации из баз данных, которые удалось зеркально отобразить с отказавшего диска. Таким образом, на серверной машине всегда должен находиться резервный диск или группа дисков, объем и конфигурация которых позво" лят воссоздать структуру разделов любого физического диска, используемого сервером. Если же все серверные устройства имеют зеркальные копии, замена одного из дисков требует еще меньше усилий со стороны администратора сервера. Просто удалите с отказавшего диска все серверные устройства, затем остановите серверную машину и замените диск на новый, отображая на него после перезапуска серверной машины все прежние устройства. 25 декабря. Рождественский вечер. Вы сидите в кресле и наблюдаете, с каким нетерпе+ нием сын раскрывает коробку с только что подаренным ему конструктором. Малыш ни о чем не догадывается... На время праздников вы были назначены дежурным администра+ тором, а значит, по вызову обязаны немедленно приступить к выполнению своих обязан+ * ностей. Утром при очередной проверке журналов регистрации ошибок было обнаружено сообщение о сбое при записи на диск одного из многочисленных серверов, поддержива+ ющих основную информационную систему вашей компании, и об автоматическом пере+ ключении сервера на второй диск зеркальной пары. Проконсультировавшись по телефону с руководством, вы принимаете решение отложить замену отказавшего диска,

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

поскольку вся система продолжает функционировать совершенно нормально. У вас нет необходимости мчаться на работу и срочно вызывать туда системного администратора серверной машины, который тоже встречает дома праздник вместе с семьей. Многочис+ ленные пользователи системы, разбросанные по всему миру, даже не подозревают о ка+ ких+либо проблемах. Вышедший из строя диск будет заменен новым на следующей неделе, после создания зеркальных копий всех других находившихся на нем серверных устройств. Кстати, при организации зеркального отображения на уровне дисков целиком последняя операция станет ненужной, поскольку в системе уже имеются зеркальные ко+ пии всех устройств диска, на котором стали появляться сбои. Не правда ли, неплохой пример ситуации, когда никакие затраты на приобретение дополнительных дисков для создания зеркальных копий устройств не покажутся лишними. КОНФИГУРАЦИЯ СЕРВЕРА ПЕРЕД ОТКАЗОМ СЕРВЕРНОГО УСТРОЙСТВА cOtOd2s1 диск cOt0dO—диск 1 файловой системы диск cOtOd1 — серверный диск 1

диск cOtOd2 — серверный диск 2

диск cOtOd3 + зеркальная копия диска cOtOd1

КОНФИГУРАЦИЯ СЕРВЕРА ПОСЛЕ ОТКАЗА СЕРВЕРНОГО УСТРОЙСТВА C0t0d2s1 диск cOtOdO—диск 1 файловой системы диск cOtOdl — серверный диск 1

диск cOtOd2 — серверный диск 2 диск cOtOd3 — зеркальная копия диска cOtOd2 В данном примере предполагается, что диски cOtOd1, с0t0d2 и cOtOd3 имеют одинаковую структуру разделов. Это позволяет отобразить на диск cOtOd3 все разделы дисков cOtOdl или cOtOd2. После отказа серверного устройства cOtOd2s1 необходимо удалить с диска сОt0d3 находившиеся там зеркальные копии, а затем отобразить на освободившиеся разделы все серверные устройства с диска cOtOd2, за исключением отказавшего устройства. Затем исходные устройства удаляются с диска cOtOd2, серверная машина останавливается для замены диска, после чего зеркальные копии устройств отображаются с диска cOtOd3 обратно на новый диск cOtOd2. При этом администратору сервера остается только восстановить базы данных, находившиеся на разделе диска с0t0d2, утраченном в результате сбоя. Рис. 8.19. Замена отказавшего диска с использованием зеркального отображения устройств Использование зеркального отображения при обновлении версии сервера Механизм зеркального отображения крайне полезен при переходе на новую версию сервера, когда создание зеркальных копий всех устройств прежнего сервера (включая устройство master) с последу" ющей отменой зеркальных пар командой disk unmirror (но без фактического удаления получен" ных копий перед началом обновления сервера) позволит сохранить полную работоспособную копию старого сервера (рис. 8.20). Таким образом, при возникновении проблем в процессе перехода на но" вую версию сервера его администратор получает возможность в любой момент переключиться на

www.books-shop.com

Контроллер 0 диск cOtOdO + диск 1 файловой системы диск cdtOd1 — серверный диск 1

диск cOtOd2 + серверный диск 2

диск cOt0d3 — зеркальная копия диска c1t0d5 (отменена, но не удалена)

диск c0tOd4 + диск 2 файловой системы диск c1tOd5 + серверный диск 3 диск c1tOd6 + зеркальная копия диска cOtOd1 (отменена, но не удалена) диск c1t0d7 + зеркальная копия диска cOt0d2 (отменена, но не удалена) Перед началом обновления сервера запретите модификацию всех баз данных и отмените все зеркальные копии с указанием параметра mode = retain. Проверьте функционирование приложений в новой версии сервера, а при возникновении проблем вернитесь к зеркальным копиям прежних баз данных, отмененным непосредственно перед началом перехода на новую версию и полностью соответствующим старой версии сервера. Ни в коем случае не разрешайте пользователям модифицировать основные базы данных, пока окончательно не убедитесь в полной работоспособности новой версии сервера. Рис. 8.20. Зеркальное отображение упрощает переход на новую версию сервера старый сервер, все копии баз данных которого остались в неприкосновенности. Для этого потребует" ся только обычными средствами системы UNIX лишить сервер полномочий на доступ к файлам об" новленных разделов физических дисков и восстановить резервирование соответствующих серверных устройств. После перезапуска сервер обнаружит недоступность основных копий устройств и автоматически переключится на их зеркальные копии, содержащие базы данных в фор" мате предыдущей версии сервера. Разумеется, при этом понадобится дополнительное дисковое про" странство, достаточное для одновременного зеркального резервирования всех серверных устройств (см. главу 13). Использование зеркального отображения при обновлении аппаратных средств серверного компьютера Механизмом зеркального отображения целесообразно воспользоваться и при обновлении аппаратно" го обеспечения серверной машины, когда требуется добавить к серверу новое дисковое пространство значительного объема и, возможно, одновременно заменить часть прежних дисков на более быстрые и вместительные устройства. В любом случае после добавления нескольких новых дисков отобразите на них существующие серверные устройства, удалите исходные копии этих устройств и отключите диски, на которых они находились. Затем добавьте на освободившееся место оставшиеся новые дис" ки и снова с помощью зеркального отображения распределите серверные устройства по имеющемуся дисковому пространству (рис. 8.21). Как и во всех рассмотренных выше примерах, зеркальное резер" вирование позволит сэкономить силы и время, избежать возможных ошибок и даже потери части са" мых свежих транзакций при восстановлении баз данных из дампов (которые могут соответствовать текущему состоянию сервера не полностью).

www.books-shop.com

Контроллер О диск cOtOdO—диск 1 файловой системы диск cOtOd1 + серверный диск 1 (полностью удалите его зеркальную копию, находящуюся на диске c1tOd6) диск cOtOd2 + серверный диск 2 (полностью удалите его зеркальную копию, находящуюся на диске c1tOd7) диск cOtOd3 — зеркальная копия диска c1tOd5 (удалите с диска c1tOd5 все основные копии серверных устройств) перед заменой дисков не забудьте сбросить на ленту копии всех файловых систем с диска c1tOd4 диск c1t0d4

диск с1t0d5

диск c1tOd6

диск c1tOd7

После удаления зеркальных копий и сохранения на ленте всех файловых систем с диска c1tOd4 накопители c1tOd4, c1t0d5, c1tOd6 и c1tOd7 отключаются от серверного компьютера и заменяются новыми. Затем восстанавливается зеркальное отображение дисков cOtOdl на dtOd6, c1tOd2 на c1tOd7 и cOtOd3 на c1tOd5, а на диск c1t0d4 с ленты загружаются файловые системы. Для того чтобы снова сделать диск c1tOd5 основным диском зеркальной пары, удалите с cOtOd3 основные копии устройств, а затем повторно отобразите c1tOd5 на cOtOd3. Замена четырех оставшихся дисков cOt0dO, cOtOd1, cOtOd2 и cOtOd3 на новые производится в том же порядке. Рис. 8.21. Зеркальное отображение облегчает расширение дискового пространства серверной машины Отображение всех серверных устройств Очень важно правильно выбрать, какие серверные устройства подлежат зеркальному резервирова нию, а какие — нет. Как показано в последующих разделах книги, полное отображение всех сервер ных устройств сэкономит администратору сервера немало времени и поможет избежать целого ряда ошибок в управлении имеющимися дисками. На первый взгляд такой подход требует слишком большого числа дисков и дисковых контроллеров. Однако сопоставьте стоимость дополнительного оборудования и суммы потерь, которые понесет ваша компания в результате утраты части содержи мого баз данных. Учтите и время простоя сервера, в течение которого вы будете пытаться вручную устранить проблемы, никогда не возникающие при наличии зеркальных копий пострадавших сер верных устройств. Кроме того, постоянно держите в памяти, какие именно устройства имеют зер кальные копии. Приоритеты при организации зеркального резервирования устройств При наличии достаточного числа дисков каждый физический диск должен целиком использоваться для размещения либо серверных устройств, либо их зеркальных копий. Организация и сопровожде ние зеркального резервирования серверных устройств значительно облегчается, если разделы всех дисков соответствуют стандартной схеме разбиения дисков, рассмотренной выше, и администратор сервера может ограничиться отображением всех устройств (разделов) одного физического диска на аналогичные разделы другого диска.

www.books-shop.com

При невозможности полного резервирования устройств создайте зеркальную копию базы дан" ных master (что, естественно, означает создание копии всего устройства master), позволяющую сер" веру продолжить работу в случае отказа одной из копий устройства master. Утрата базы данных master, являющейся сердцем всего сервера, приведет к потере его работоспособности. Поэтому устройство master обязательно должно резервироваться на всех контролируемых вами серверах. Помимо базы данных master, обеспечьте резервирование журналов транзакций наиболее важных баз данных сервера. Стандартные средства восстановления баз данных из дампов позволяют привес" ти эти базы данных к состоянию на момент сохранения последнего дампа журнала транзакций. Да" льнейшее восстановление базы данных непосредственно на момент сбоя возможно только при условии существования на одном из дисков копии текущего журнала транзакций. Это обеспечит воз" можность воспользоваться ей даже при отказе диска, поддерживавшего основную копию журнала. Подчеркнем, что резервирование журнала транзакций важнее резервирования самой базы данных, поскольку даже при отсутствии зеркальной копии базы данных ее состояние на момент начала теку" щего журнала транзакций можно восстановить из дампов базы данных и дампов журнала транзак" ций. В свою очередь, полная утрата текущей копии журнала транзакций не позволит продолжить процесс восстановления базы данных далее последнего дампа журнала транзакций даже при нали" чии зеркальной копии базы данных. При любых изменениях конфигурации дискового пространства сервера необходимо постоянно следить за тем, чтобы не нарушить зеркальное отображение журналов транзакций. Подобный конт" роль особенно обременителен при необходимости расширить одну из баз данных на серверное устройство, ранее не имевшее зеркальной копии. Это еще один пример того, почему с администра" тивной точки зрения намного проще организовать полное резервирование всех серверных устройств (разделов) на уровне физических дисков: такая схема гарантирует резервирование дан" ных, на каком бы устройстве они бы ни находились. Единственным особым случаем здесь является временная база данных tempdb. Поскольку сервер все равно не восстанавливает ее содержимое после сбоев, в существовании ее зеркальной копии, ка" залось бы, нет ни малейшей необходимости. Однако при возникновении сбоев на устройстве, под" держивающем базу данных tempdb (либо ее журнал транзакций) и при отсутствии соответствующей зеркальной копии сервер потеряет возможность доступа к tempdb и фактически перестанет функцио" нировать. Поэтому для обеспечения стабильной работы сервера при отказе любого из его дисков ра" зумно создать зеркальную копию как самой базы данных tempdb, так и ее журнала транзакций. Не следует забывать, что зеркальное резервирование удваивает объем операций ввода/вывода, выпол" няемых сервером, поэтому при очень большой нагрузке на базу данных tempdb у администратора сер" вера будут все основания отказаться от ее резервирования. Таким образом, принимая решение о зеркальном отображении базы данных tempdb, следует исходить из разумного компромисса между на" дежностью работы сервера и его производительностью. Создание зеркальных копий Познакомившись с основными функциями зеркального резервирования серверных устройств и выде" лив устройства, которые следует резервировать в первую очередь, переходим к процессу создания зеркальных копий и управлению их работой. На протяжении всего раздела будем постоянно подчер" кивать, что зеркальные копии создаются на уровне серверных устройств, а не отдельных баз данных. Действительно, при назначении серверному устройству командой disk init файла операционной системы или небуферизованного раздела диска мы создаем логическое дисковое устройство сервера, а затем — зеркальную копию этого устройства. Зеркальную копию серверного устройства нельзя раз" местить в разделе диска, уже занятом другим серверным устройством, в силу чего не следует выпол" нять команду disk init по отношению к разделу, в котором планируется создать зеркальную копию одного из серверных устройств. Если в намеченном разделе все же существует серверное устройство, удалите его перед тем, как поместить в него зеркальную копию другого устройства. Вне зависимости от количества баз данных, размещающихся на отображаемом серверном устройстве, все они автома" тически включаются в процесс зеркального отображения. Конфигурация сегментов какой"либо базы данных или характер их размещения по различным серверным устройствам также не играют никакой роли. Зеркальная копия соответствует выбранному серверному устройству, а не отдельной базе дан" ных или ее сегменту. Таким образом, для резервирования конкретной базы данных или ее отдельно" го сегмента необходимо создать зеркальные копии всех серверных устройств, на которых находится соответствующая база данных или сегмент. Зеркальная копия логического дискового устройства сер" вера создается командой disk mirror name = "device_name",

www.books-shop.com

mirror = "physical_name", writes = { serial I noserial} В ближайших разделах главы рассматриваются следующие вопросы, связанные с командой disk mirror: Параметр device_name (название устройства) Параметр physical_name (физический адрес устройства) Параметр writes Размещение главного и вторичного устройств на одном дисковом контроллере Размещение главного и вторичного устройств на разных дисковых контроллерах Пример команды disk mirror Параметр device_name (название устройства) Параметр device_name содержит название серверного устройства, зеркальную копию которого вы собираетесь создать. Разумеется, здесь следует указывать название устройства, используемое SQL Server, а не название соответствующего раздела с точки зрения операционной системы UNIX. Сер верное устройство, определенное в качестве параметра device_name, становится основным устрой" ством зеркальной пары. Параметр physicaLname (физический адрес устройства) Значение параметра mirror определяет физическое местонахождение файла или раздела, в котором создается зеркальная копия основного устройства пары. Таким образом, в качестве физического ад" реса устройства необходимо указать имя специального файла операционной системы, управляющего небуферизованным доступом к дисковому разделу, выбранному для размещения зеркальной копии. Не пытайтесь создать зеркальную копию устройства с помощью команды disk init. Если вы" бранный раздел уже используется каким"либо серверным устройством, необходимо убрать с него все сегменты баз данных, а затем удалить и само устройство. Параметр writes Значение параметра writes задает режим работы зеркальной копии. По умолчанию сервер использу" ет режим writes = serial, при котором изменения сначала заносятся в базу данных на основном устройстве, а их запись во вторичное устройство начинается только после завершения записи на основ" ное устройство. Значение writes = serial гарантирует целостность данных в большей степени.

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

Размещение главного и вторичного устройства на разных дисковых контроллерах В случае размещения главного и вторичного устройства на разных дисковых контроллерах не следует использовать режим writes = serial, поскольку лучшую производительность сервера обеспечива" ет режим writes = noserial. Так как по умолчанию сервер устанавливает режим writes = se" rial, значение noserial в команде disk mirror должно быть указано явно. Во всех последующих примерах будем придерживаться стандартной схемы назначения имен серверных устройств, описан" ной в этой главе выше. Пример команды disk mirror Предположим, что ранее на сервере командой disk init было создано серверное устройство с на" званием cOtOdlsl, которое мы намереваемся отобразить на небуферизованный раздел 1 физического диска cltOd6. Как легко понять из названий дисков, соответствующий файл операционной системы UNIX, контролирующий небуферизованный доступ к соответствующему разделу, называется /dev/rdsk/cltOd6s1, а физические диски cOtOd1 и cltOd6 подключены к разным контроллерам сО и c1, поэтому нет необходимости использовать режим writes = serial. В данном случае команда disk mirror принимает вид: disk mirror name = "cOtOd1s1, mirror = "/dev/rdsk/c1tOd6s1", writes = noserial

www.books-shop.com

Связь между главным устройством зеркальной пары, ее вторичным устройством и логическим устройством сервера Итак, главное серверное устройство и его зеркальная копия (вторичное устройство) образуют еди ное серверное устройство, которое называется зеркальной парой (рис. 8.22). Важно четко представ лять себе разницу между главным и вторичным устройством пары. Первое из них — обычное •серверное устройство* известное серверу с момента выполнения команды disk init. Вторичное устройство само по себе не является отдельным устройством сервера, а создается исключительно командой disk mirror. Для удаления одного из устройств зеркальной пары используется команда disk unmirror, в ко торой указывается название единого серверного устройства, одинаковое для обоих устройств пары. При этом удаляемое устройство пары (главное или вторичное) выбирается на основании значения параметра side (здесь очень легко ошибиться, особенно в критической ситуации, когда возникает уг роза работоспособности сервера). Формат команды disk unmirror: disk unmirror name = "device_name", side = {primary I secondary}, mode << {retain I remove} Как и при работе с командой disk mirror, при использовании disk unmirror необходимо четко понимать смысл всех задаваемых параметров: device_name (название устройства) side mode

Оба специальных файла, контролирующих доступ к главному серверному устройству (/dev/rdsk/cOtOd1s1) и его зеркальной копии (/dev/rdsk/c1tOd6s1), должны принадлежать пользователю серверной машины с системным именем 'Sybase'. серверное устройство cOtOd1s1

ОТОБРАЖАЕТСЯ НА

небуферизованный раздел /dev/rdsk/c1tOd6s1

главное серверное устройство

вторичное серверное устройство (зеркальная копия) Главное серверное устройство cOtOdOs1 и его зеркальная копия c1tOd6s1 вместе образуют зеркальную пару, которая no+прежнему обрабатывается сервером в качестве единого логического дискового устройства с названием 'cOtOd1s1'.

Рис. 8.22. Зеркальная пара серверных устройств

www.books-shop.com

Параметр device_name (название устройства) Данный параметр имеет то же самое значение, что и в команде disk mirror. Параметр side Параметр side указывает, какая "сторона" зеркальной пары подлежит удалению — главное устройство (primary) или вторичное (secondary). В частности, при возникновении необходимости замены дисково" го накопителя удалите то устройство зеркальной пары, которое находится на отключаемом диске. Параметр mode У параметра mode две стороны медали: этот дополнительный набор возможностей оказывается по" лезным в ряде ситуаций и в то же время заметно усложняет работу с зеркальными копиями устройств. В зависимости от того, что вы намерены сделать: отменить зеркальное отображение или полностью удалить указанное устройство зеркальной пары, в команде disk unmirror указывается либо mode = retain , либо mode = remove. Если указывается параметр retain, SQL Server прекращает запись на соответствующее устройство и чтение с него, но не освобождает раздел диска, занимаемый этим устройством, которое в любой момент может быть вновь включено в состав зеркальной копии коман" дой disk remirror (см. ниже). В свою очередь, при задании параметра mode = remove сервер полностью удаляет устройство с диска, и его последующее восстановление командой disk remirror становится невозможным (хотя в том же самом разделе командой disk mirror может быть создана новая зеркальная копия). Следует учитывать, что как при создании зеркальной копии командой disk mirror, так и при ее восстановлении командой disk remirror серверу приходится полностью ко" пировать все данные с основного устройства, даже если к моменту восстановления копии в нем не произошло никаких изменений. Удаление одного из устройств зеркальной пары При удалении одного из устройств, входящих в зеркальную пару, внимательнее следите за правильно" стью значений параметров, указываемых в команде disk unmirror, в первую очередь за парамет" ром device_name. Напомним, что в качестве названия устройства здесь приводится название логического серверного устройства, образованного зеркальной парой. После удаления одного из устройств пары оставшееся сохранит это название независимо от того, в каком режиме происходит удаление: mode = retain или mode = remove. Вернемся к рассмотренному выше примеру создания зеркальной пары. Для удаления основного устройства пары (по имени которого она и была названа) введите следующую команду: disk unmirror name << "cOtOd1s1", side = primary, mode * retain В свою очередь, для удаления вторичного устройства пары (до создания пары представлявшего собой небуферизованный раздел диска, вообще не известный серверу) команда disk unmirror принимает вид

disk unmirror name = "cOtOd1s1", side = secondary, mode = retain Удаление вторичного устройства зеркальной пары В каждом из этих двух примеров мы ограничились отменой зеркального отображения с сохранением удаляемого устройства зеркальной пары. Рассмотрим сначала второй пример, когда было удалено вторичное устройство пары. До ввода команды disk unmirror на сервере существовала зеркальная пара устройств с названием cOtOdlsl. Она состояла из главного устройства, до создания пары также имевшего название cOtOdlsl, и его зеркальной копии — вторичного устройства, до момента создания пары представлявшего собой небуферизованный раздел диска, контролируемый специальным фай" лом операционной системы с именем /dev/rdsk/cltOd6s1 (рис. 8.23). После удаления вторичного устройства пары в режиме mode >> retain на сервере по"прежнему существует серверное устройст" во с названием cOtOdlsl и небуферизованный раздел /dev/rdsk/cltOd6s1, содержащий копию устройства cOtOdlsl на момент выполнения команды disk unmirror. Однако в эту копию сервер бо" льше не вносит никаких изменений. При задании параметра mode = remove сервер полностью вер" нулся бы к состоянию на момент создания зеркальной пары, когда данные с серверного устройства

www.books-shop.com

главное серверное устройство /dev/rdsk/cOtOd1s1

Серверное устройство 'cOtOd1s1'

вторичное устройство (зеркальная копия) на небуферизованном дисковом разделе /dev/rdsk/c1tOd6s1

disk unmirror name = "cOtOd1s1", side = secondary, mode = retain главное серверное устройство /dev/rdsk/cOtOd1s1

Серверное устройство 'cOtOd1s1'

вторичное устройство (зеркальная копия) на небуферизованном дисковом разделе /dev/rdsk/c1tOd6s1

Вторичное устройство пары по+прежнему содержит копию раздела /dev/rdsk/cOtOd1s1 на момент выполнения команды disk unmirror, однако в нем не отражаются последующие изменения. При указании параметра mode = remove вся информация раздела /dev/rdsk/c1tOd6s1 оказалась бы утраченной. Рис. 8.23. Удаление вторичного устройства — зеркальной копии основного устройства зеркальной пары cOtOdlsl находились исключительно в небуферизованном разделе /dev/rdsk/cOtOd1s1. Таким об разом, вне зависимости от указанного значения параметра mode в нашем распоряжении остается сер верное устройство cOtOdlsl. Его размеры соответствуют указанным в команде disk init при создании этого устройства, которому с самого начала был назначен раздел 1 физического диска c O t O d l , контролируемый специальным файлом операционной системы UNIX с именем /dev/rdsk/cOtOd1s1. Именно в это состояние сервер переходит при обнаружении ошибок на вто ричном устройстве зеркальной пары, когда оно автоматически удаляется с помощью режима mode = retain. Заметим, что если бы сейчас мы ввели команду disk remirror name = "cOtOd1s1" то конфигурация зеркальной пары вернулась бы к положению, существовавшему на момент выполне ния команды disk unmirror, когда в разделе /dev/rdsk/cOtOdlsl находилось главное устройст во пары, а в разделе /dev/rdsk/cltOd6sl — ее вторичное устройство. Удаление главного устройства пары Вернемся теперь к первому примеру, когда было удалено главное устройство пары. Напомним, что до выполнения команды disk unmirror главное устройство пары, бывшее серверным устройством cOtOdlsl, находится в небуферизованном разделе 1 физического диска cOtOdl, контролируемого сис темным файлом /dev/rdsk/cOtOd1s1; вторичному же устройству соответствует аналогичный раз дел dev/rdsk/cltOd6sl (рис. 8.24). После удаления главного устройства пары в режиме mode >>

www.books-shop.com

главное серверное устройство /dev/rdsk/cOt0d1s1

Серверное устройство 'cOtOd1s1'

вторичное устройство (зеркальная копия)

на небуферизованном дисковом Ч разделе /dev/rdsk/c1tOd6s1

I disk unmirror name = "cOtOd1s1", side = primary, mode = retain главное серверное устройство /dev/rdsk/cOtOd1s1

Серверное устройство 'cOtOd1s1'

вторичное устройство (зеркальная копия) . на небуферизованном дисковом разделе /dev/rdsk/c1tOd6s1

Главное устройство пары по+прежнему содержит копию раздела /dev/rdsk/c1tOd6s1 на момент выполнения команды disk unmirror, однако в нем не отражаются последующие изменения. При указании параметра mode = remove вся информация раздела /dev/rdsk/cOtOd1s1 оказалась бы утраченной. Рис. 8.24. Удаление главного устройства зеркальной пары retain на сервере попрежнему остается серверное устройство cOtOdls1, которое теперь находится на месте бывшего вторичного устройства, т.е. на другом физическом диске. Заметим, что раздел 1 фи зического диска cltOd6 никогда не инициализировался командой disk init и до выполнения команды disk unmirror не был известен серверу как самостоятельное серверное устройство. Таким образом, при удалении главного устройства пары SQL Server автоматически преобразует вторичное устройство зеркальной пары в полноценное серверное устройство, ничем не отличающееся от обыч ного устройства, созданного командой disk init. При этом сервер устанавливает размер вторично го устройства (которое с этого момента становится единственным активным устройством бывшей зеркальной пары) равным прежнему размеру главного устройства пары. Именно такова последовате льность действий сервера при автоматическом переключении на вторичное устройство зеркальной пары, когда возникают ошибки на ее главном устройстве. Аналогично предыдущему случаю, команда disk remlrror name = "cOtOd1s1" вернула бы конфигурацию зеркальной пары к положению, существовавшему на момент выполнения команды disk unmirror: с главным устройством пары в разделе /dev/rdsk/cOtOd1s1 и вторич ным устройством — в разделе /dev/rdsk/cltOd6sl. Восстановление зеркальной пары При необходимости восстановления ранее удаленного устройства зеркальной пары необходимо ис пользовать команду disk remirror, имеющую следующий формат: disk remirror name = "device_name"

www.books-shop.com

Название устройства device_name, указываемое в команде disk remirror, совпадает со значе" нием параметра device_name при первоначальном создании зеркальной пары. Обратите внимание на то, что при вводе команды disk remirror не имеет значения, являлось ли восстанавливаемое устройство главным или вторичным устройством пары: эта команда просто возвращает удаленное устройство в активное состояние и приводит его в соответствие с текущим состоянием второго устройства пары. Отметим, что командой disk remirror нельзя восстановить устройство, удаленное с указанием параметра mode = remove. Как уже отмечалось, при удалении главного устройства пары (/dev/rdsk/cOtOdlsl) бывшее вторичное устройство (/dev/rdsk/cltOd6sl) автоматически становится главным. Поэтому при удалении главного устройства в режиме mode = remove и выполнении команды disk mirror name = "c1t0d6s1", mirror = /dev/rdsk/cOtOd1s1", write = serial получаем ту же структуру дисковых разделов, что и в ранее существовавшей зеркальной паре. Теперь главное устройство находится в разделе /dev/rdsk/cltOd6sl, а раздел /dev/rdsk/cOtOdlsl ста" нет вторичным устройством. Вся пара будет известна серверу под названием cltOd6sl. Итак, в исходном состоянии серверному устройству cOtOdlsl был назначен раздел /dev/rdsk/cOtOdlsl, а его зеркальная копия находилась в разделе /dev/,rdsk/cltOd6sl. После удаления главного устройства зеркальной пары серверному устройству cOtOdlsl был автоматически назначен раздел /dev/rdsk/cltOd6sl. Его размер приводится в соответствие с величиной, ука" занной в команде disk init при создании первоначального устройства cOtOdlsl. Поскольку в команде disk unmirror был указан параметр mode = retain, зеркальную пару можно восстано" вить в любой момент. Аналогично, при сбое одного из устройств зеркальной пары сервер автомати" чески удаляет это устройство и переключается на оставшееся. Если сбой не будет признан достаточно серьезным основанием для замены дискового устройства, администратор сервера может попытаться восстановить зеркальную пару. С точки зрения сервера восстановление такой пары с ис" пользованием команды disk remirror мало чем отличается от повторного создания зеркальной пары командой disk mirror: серверу все равно приходится копировать все данные с текущего главного устройства на новую зеркальную копию. Правда, команда disk remirror позволяет ад" министратору сервера не вспоминать адрес раздела, где находится восстанавливаемое устройство. У главного и вторичного устройства разные размеры Допустим, устройство меньшего размера (например, 100"Мбайт устройство cOtOdlsl) отображается на устройство большего размера (скажем, раздел /dev/rdsk/cltOd6sl имеет объем 200 Мбайт). За" тем по каким"то причинам главное устройство пары оказывается удаленным. В итоге на бывшем вто" ричном устройстве пары создается серверное устройство прежнего размера в 100 Мбайт (рис. 8.25). Таким образом, хотя зеркальная копия занимает все вторичное серверное устройство (чаще всего — весь назначенный раздел диска), после переключения вторичное устройство становится обычным серверным устройством с размерами, равными размерам прежнего главного устройства пары. В дан" ном случае процесс полностью эквивалентен созданию командой disk init 100"Мбайт устройства на 200"Мбайт разделе /dev/rdsk/cltOd6sl, что означает потерю значительного дискового про" странства. Именно такой ситуации можно избежать, если использовать стандартную схему дисковых разделов, обеспечивающую равенство разделов каждой зеркальной пары. Конечно, на практике не" возможно создать все разделы дисков сервера строго одинакового объема. Обычно, чтобы облегчить зеркальное отображение серверных устройств, выделенные серверу дисковые накопители группиру" ются по размерам. После этого к каждой группе дисков применяется соответствующая стандартная схема разбиения на разделы. При этом в зеркальные пары естественно включать диски равных разме" ров. Процесс упрощается еще более, если зеркальное отображение устанавливать на уровне целых дисковых накопителей. Идентичность конфигурации разделов одинаковых дисковых устройств по" зволяет избежать потерь дискового пространства при создании зеркальных пар, удалении одного из устройств пар и их последующем восстановлении. Обратите внимание на то, что реализованный на сервере подход к зеркальному отображению ме" ньшего устройства на больший раздел позволяет избежать проблем при последующем восстановле" нии меньшего раздела, когда серверу фактически пришлось бы отображать больший раздел на меньший. Единственное, что можно сделать в подобной ситуации, это ограничить используемую об" ласть большего раздела размером исходного серверного устройства, а не полным объемом самого раздела.

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

главное серверное устройство /dev/rdsk/cOtOd1s1 (100 Мбайт) *

Серверное устройство 'cOt0d1s1'

вторичное устройство (зеркальная копия) на небуферизованном дисковом разделе /dev/rdsk/c1tOd6s1 (200 Мбайт)

disk unmirror name = "cOtOd1s1", side = primary, mode = retain

главное серверное устройство /dev/rdsk/cOtOd1s1 (100 Мбайт)

Серверное устройство 'cOtOd1s1'

бывшее вторичное устройство (зеркальная копия) на небуферизованном дисковом разделе /dev/rdsk/c1tOd6s1 становится главным серверным устройством, использующим только 100 Мбайт из 200+Мбайт раздела.

Рис. 8.25. Зеркальное отображение меньшего раздела на больший Расширение баз данных, находящихся на зеркальных устройствах При зеркальном резервировании отдельных серверных устройств процедура добавления дискового пространства базам данных требует особого внимания (рис. 8.26). Пока добавляемое пространство по"прежнему размещается на серверном устройстве, содержащем расширяемую базу данных, нет опасности нарушить отображение базы данных на ее зеркальную копию. Дело в том, что зеркальное резервирование устанавливается на уровне целых серверных устройств. Однако в ситуации, когда расширяемый сегмент базы данных невозможно разместить ни на одном из серверных устройств, уже используемых для поддержки этого сегмента, и его приходится выносить на новое серверное устройство, легко забыть о необходимости создания зеркальной копии нового устройства. Именно здесь скрывается основная опасность выборочного резервирования серверных устройств. Кто"то из ваших коллег при распространении базы данных на новое устройство может забыть или полениться проверить, существует ли у этого устройства зеркальная копия. При зеркальном резервировании отображаются устройства, а не отдельные базы данных Еще раз подчеркнем, что не существует иного способа создать зеркальную копию базы данных, кроме как путем зеркального резервирования абсолютно всех серверных устройств, поддерживающих эту базу данных. Однако администратор сервера может значительно упростить контроль за зеркальными копиями устройств, содержащих ту или иную базу данных. После установки сервера немедленно раз" бейте все диски серверной машины, выделенные серверу, на диски главных серверных устройств и диски зеркальных копий, после чего создайте необходимые серверные устройства сразу в виде

www.books-shop.com

серверное устройство 'cOtOd1s1' серверное устройство 'cOtOd1s3'

ОТОБРАЖАЕТСЯ НА

небуферизованный дисковый раздел /dev/rdsk/c1tOd6s1 небуферизованный дисковый раздел /dev/rdsk/с1tOd6s3

create database db1 on cOtOd1s1 = 100 disk mirror name = "cOtOd1s1", mirror = "/dev/rdsk/c1tOd6s1", write = serial БАЗА ДАННЫХ db1 ПРИОБРЕТАЕТ ЗЕРКАЛЬНУЮ КОПИЮ alter database db1 on cOtOd1s3 = 100 БАЗА ДАННЫХ db1 БОЛЬШЕ НЕ ИМЕЕТ ПОЛНОЙ ЗЕРКАЛЬНОЙ КОПИИ Рис. 8.26. Отображение устройств еще не означает полного отображения баз данных зеркальных пар. Естественно, тем самым вы автоматически резервируете каждое устройство сервера. На первый взгляд такой подход кажется слишком дорогостоящим. Однако он помогает сделать сопро" вождение сервера значительно более легким, чем в случае, когда только часть дисков имеет зеркаль" ные копии. Конец месяца совпал с концом года, и ваш сервер работает с предельной нагрузкой. Коллеге, администратору баз данных, потребовалось расширить одну из основных баз данных. Однако ни он, ни вы не потрудились как следует проконтролировать эту элемен+ тарную операцию. В противном случае вы бы заметили, что распределенное базе дан+ ных новое серверное устройство не имеет зеркальной копии. Через некоторое время пользователи начали жаловаться, что их приложения вместо того, чтобы работать, выда+ ют сообщения о сбоях в базе данных. Ничего, вроде бы, страшного, надо только прове+ рить зеркальные пары и найти отказавшее устройство, почему+то не переключившееся на резервное устройство пары. Начав проверку, вы с ужасом убеждаетесь, что сбой про+ изошел на устройстве, не имеющем зеркальной копии. Это катастрофа. Поскольку не существует способа восстановления отдельного сегмента или объекта базы данных из ее полного дампа, вам предстоит восстанавливать полную базу данных. Этот процесс с неизбежностью растянется на многие часы, которые окажутся потерянными только пото+ му, что одно из устройств сервера случайно оказалось незарезервированным. Подобной ситуации можно было избежать, если бы все устройства сервера имели зеркальные копии. В таком случае вне зависимости от того, на каком устройстве выделяется место для базы данных, эта база данных автоматически окажется зарезервированной. Более того, для нарушения структуры зеркального отображения вашему незадачливому коллеге потребуется вручную удалить зеркальную копию одного из устройств либо создать командой disk init новое устройство на одном из дисков, ранее не входящих в состав сервера. И то и другое представляется маловероятным, поскольку требует целенаправ+ ленных дополнительных усилий.

www.books-shop.com

Администрирование зеркальных устройств Реализация эффективной схемы зеркального резервирования серверных устройств совершенно не означает, что все ваши хлопоты закончились. Причем дело не только в будущем расширении дисково" го пространства сервера. Администратор сервера должен постоянно следить за нормальным функци" онированием пар зеркальных устройств. При возникновении проблем с одним из устройств пары сервер выдает соответствующее сообщение в журнал регистрации ошибок, поэтому необходимо по" стоянно контролировать содержание этого журнала. Кроме того, после каждого перезапуска сервера следует просмотреть журнал регистрации ошибок, чтобы убедиться в успешной активизации устрой" ства master и его зеркальной копии. После перезапуска сервера с помощью процедуры p_mirror по" лезно проверить состояние всех зеркальных копий устройств. Подобную проверку имеет смысл регулярно проводить при каждом сохранении дампа системных таблиц сервера (см. главу 14). Выдача процедур p_mirror, sp_helpdevice или прямая выборка записей таблицы sysdevices из базы дан" ных master позволит определить состояние каждого серверного устройства (поле status). При этом у от" казавшего устройства зеркальной пары значение поля status будет отличаться от аналогичного значения для всех других устройств, что намного облегчает контроль за нормальной работой зеркаль" ных пар. Наступает пятница, и всю следующую неделю вы намереваетесь провести на курсах по+ вышения квалификации. Однако вас вызывают на работу, поскольку коллеги внезапно обнаружили, что один из основных серверов отказывается перезапускаться. Виноваты в этом именно вы, так как недавно попросили системного администратора серверной ма+ шины заново разбить один из дисков, чтобы он оказался целиком занят файловой систе+ мой, используемой для хранения дампов журналов повтора. Разумеется, при этом вы с помощью процедуры p_devspace проверили размещение всех устройств сервера, а так+ же проконтролировали все существующие файловые системы системной командой df +k. Что же произошло? Выяснилось, что ваш коллега, осуществлявший установку серве+ ра, по непонятным причинам решил поместить серверное устройство master на физиче+ ский диск, отведенный под файловые системы. Устройство master оказалось единственным серверным устройством на этом диске, и при анализе выдачи процедуры p_devspace вы не обратили внимания на название диска, содержавшего устройство master, считая, что все серверные устройства находятся на дисках, специально предназ+ наченных для этого. Естественно, при создании новой структуры разделов файлового диска серверное устройство master оказалось уничтоженным. Ничего страшного, скажете вы, ведь именно на этот случай на сервере имеется зеркальная копия устройства master. Но просматривая старые журналы регистрации ошибок, вы обнаруживаете, что при од+ ном из перезапусков сервера в прошлом месяце зеркальная копия устройства master была отключена сервером из+за возникновения ошибок. Итак, устройства master больше не существует. Вам предстоит восстановить его, загрузить дамп базы данных master (который, к счастью, удалось найти на диске) и перейти к восстановлению сервера. Так что мало просто создать зеркальную копию устройства master — надо периодически проверять ее работоспособность, регулярно создавать дампы базы данных master и как можно чаще сохранять дампы системных таблиц сервера. В критический момент все это должно быть под рукой. Не бойтесь зеркал. Зеркальный мир спокоен и безопасен. Зеркальные диски — залог успешной карьеры. Выбор конфигурации устройств и сегментов сервера Процесс создания конфигурации сервера, обеспечивающей оптимальную поддержку баз данных, от которых зависит работа конкретных приложений, подробно рассматривается в главе 11. Главное при этом — правильно определить, какое количество независимых сегментов (единственных сегментов, помещенных на данное серверное устройство) потребуется самой крупной базе данных, имеющейся на сервере. Установив количество таких сегментов, вы немедленно получаете минимально допусти" мое число серверных устройств (не забудьте зарезервировать еще несколько устройств для базы дан" ных master и т.п.). В идеале каждый независимый сегмент должен находиться на отдельном физическом диске, подключенном к отдельному контроллеру. Это требование немедленно определя" ет минимально допустимое число контроллеров (разумеется, на практике контроллеров может пона" добиться больше). Теперь предстоит выяснить количество дисков, подключаемых к каждому

www.books-shop.com

диск cOtOdO + диск 1 файловой системы диск cOtOd1 + серверный диск 1 (содержит сегменты default и system базы данных db1) диск cOtOd2 + серверный диск 2 диск cOtOd3 + зеркальная копия cOtOd5 диск с1tOd4 + диск 2 файловой системы диск с1tOd5 + серверный диск 3 (содержит сегмент журнала транзакций базы данных db1) диск с1tOd6 + зеркальная копия cOtOdl диск с1tOd7 + зеркальная копия cOtOd2

диск c2tOd8 + диск 3 файловой системы диск c2tOd9 + серверный диск 4 (содержит сегмент ncindexes базы данных db1) диск c2tOd10 + серверный диск 5 диск c2tOd11 + зеркальная копия c3tOd13 диск c3tOd12 + диск 4 файловой системы диск c3tOd13 + серверный диск 6 (содержит сегмент bigtable базы данных db1) диск c3tOd14 + зеркальная копия c2tOd9 диск c3tOd15 + зеркальная копия c2tOd10 База данных db1 состоит из сегментов system/default, logsegment и двух пользовательских сегментов под названиями 'ncindexes' и 'bigtable'. Примечание. Четверть из 16 имеющихся дисков используется для размещения файловых систем, в то время как остальные 12 дисков разделены поровну между серверными устройствами и их зеркальными копиями. Рис. 8.27. Пример конфигурации сегментов базы данных, серверных устройств и их зеркальных копий контроллеру. Здесь следует ориентироваться на максимальное количество дисков, которое каждый отдельный контроллер способен поддерживать без снижения производительности ввода/вывода. В свою очередь, размер дисков определяется исходя из ожидаемых объемов сегментов. На заключи" тельном этапе остается только выделить часть дисков для поддержки зеркальных копий серверных устройств и убедиться, что дисков, оставшихся свободными, хватит на размещение других баз данных и файловых систем. Пример одной из возможных конфигураций сервера приведен на рис. 8.27, где показана база дан" ных dbl. Она состоит из трех стандартных сегментов (system, default и logsegment), а также двух пользовате" льских сегментов: ncindexes, содержащего некластеризованные индексы, и bigtable, в котором размещается одна крупная и часто используемая таблица данных. Для повышения производительности сервера пользовательские сегменты ncindexes и bigtable установлены на независимые физические дис" ки, подключенные к отдельным контроллерам, не обслуживающим ни сегменты system/default, ни сег" мент журнала транзакций. В итоге рассматриваемая серверная машина должна обладать как минимум четырьмя дисковыми контроллерами (количество которых определяется именно из требо" вания размещения разных сегментов на разных контроллерах). К каждому контроллеру подключает" ся максимально допустимое число дисков, не приводящее к замедлению операций ввода/вывода (четыре диска для компьютеров фирмы Sun). Выделив четверть имеющихся дисков (четыре диска) файловой структуре и разбив оставшиеся 12 дисков на две равные группы для поддержки серверных устройств и их зеркальных копий, получим общую конфигурацию сервера. Обратите внимание, здесь неявно предполагается наличие на каждом диске достаточного места для размещения всех сег" ментов базы данных dbl. Необходимо помнить, что в ситуации, когда один из сегментов dbl не

www.books-shop.com

удастся целиком разместить на дисках, подключенных к одному контроллеру, к системе придется подключать еще один контроллер, поскольку распространение сегмента на любой другой существу" ющий контроллер приведет к возникновению конфликтов по операциям ввода/вывода с другим сег" ментом базы данных dbl, уже находящимся на этом контроллере. Предположим, у нас возникла необходимость расширить сегмент ncindexes, причем диски c2tOd9 и c2tOd10 (единственные на контроллере 2, доступные для размещения объектов базы данных) уже целиком заполнены данными сегмента ncindexes и сегментов других баз данных. В результате мы вы" нуждены искать место для сегмента ncindexes на других контроллерах. Однако при распространении сегмента ncindexes на контроллер О, 1 или 3 этот сегмент немедленно вступит в конфликт с одним из других расположенных там сегментов этой же базы данных dbl. Так, создание области сегмента ncindexes на диске cOtOd2, подключенном к контроллеру 0, вызовет конфликт по операциям вво" да/вывода с сегментами default/system. Убедимся, что реализация нескольких пользовательских сег" ментов для повышения производительности сервера значительно усложняет конфигурирование дискового пространства сервера. Здесь бессмысленно ориентироваться на общий объем доступного дискового пространства. Проблема в том, что свободное пространство необходимо на конкретном контроллере, способном поддерживать увеличившийся в размерах сегмент без потери общей произ" водительности сервера. Перед тем как создавать новый пользовательский сегмент, обязательно при" киньте, стоят ли выгоды от его использования дополнительных усилий на поддержание усложнившейся конфигурации сервера. Почему не следует торопиться расширять пространство базы данных Таковы многочисленные нюансы процесса распределения сегментов базы данных по серверным устройствам. Теперь вы уже вполне понимаете, почему администратору сервера не следует расши" рять базу сервера без серьезных на то оснований. Сам по себе процесс добавления нового дискового пространства базе данных настолько прост, что порой при этом не предпринимается никаких попы" ток оценить его возможные негативные последствия. Расширение базы данных или ее журнала тран" закций на серверные устройства, уже поддерживающие эту базу данных либо журнал транзакций этой базы данных, редко приводит к каким"либо проблемам. Правда, не следует, как показано выше, стре" миться расширять журнал транзакций за разумные пределы. Единственная открытая транзакция спо" собна переполнить журнал транзакций любого размера, а чем больше журнал транзакций, тем больше времени потребуется на сохранение его дампа. В случае переполнения журнала транзакций и необходимости его усечения путем вывода дампа в режиме no_log база данных оказывается закры" той для внесения каких бы то ни было изменений на все время очистки журнала. Расширение объе" мов журнала транзакций лишь увеличивает продолжительность этого периода времени. Перед расширением любой базы данных сервера обязательно убедитесь в существовании зерка" льных копий всех новых серверных устройств, распределяемых базе данных. Самый простой спо" соб — резервирование абсолютно всех устройств сервера. Это значительно снижает риск потери данных в случае несогласованных действий разных администраторов баз данных. Наконец, даже наличие на некоторых серверных устройствах больших объемов свободного дис" кового пространства вовсе не означает, что этим пространством удастся воспользоваться. При рас" ширении базы данных свободное пространство добавляется ее конкретным сегментам. Так, при расширении сегмента журнала повтора вы не можете распространить его на серверные устройства, уже занятые другими сегментами этой же базы данных. Подобные проблемы возникают и при увели" чении размеров пользовательских сегментов. Хотя, в отличие от сегмента журнала повтора, пользо" вательский сегмент формально может находиться на одном устройстве с другими сегментами базы данных, обычно главной целью создания пользовательского сегмента является изоляция определен" ных объектов базы данных (в частности, больших таблиц и их некластеризованных индексов) с це" лью повышения производительности сервера. Смешивание пользовательского сегмента с любыми другими сегментами той же базы данных часто приводит к потере всего выигрыша в производитель" ности, полученного благодаря изоляции этого сегмента, поскольку в подобной ситуации серверные процессы начинают конкурировать за доступ к объектам данных, ранее изолированным друг от дру" га. Поэтому далеко не все свободное пространство дисков сервера реально доступно в каждой конк" ретной ситуации. Крайне нежелательно размещать любые пользовательские объекты на серверном устройстве master, в противном случае свободной областью устройства master воспользоваться будет практически невозможно. Поэтому размеры создаваемого устройства master не должны намного превышать ожидаемые размеры базы данных master. Кроме того, не стоит учитывать свободное

www.books-shop.com

пространство устройства master при подсчете всего свободного пространства, имеющегося на серве" ре. Таким образом, необходимо постоянно контролировать распределение свободных областей сер верных устройств с тем, чтобы эти области оказывались на соответствующих устройствах и их можно было бы использовать для расширения наиболее быстрорастущих сегментов баз данных. Итак, простая операция расширения базы данных на деле имеет немало далеко идущих последст" вий, и к ней следует относиться со всей серьезностью. Заключение Процесс установки и сопровождения сервера требует от администратора четкого понимания ряда операций, которые, как считается, относятся к компетенции системного администратора серверной машины. В противном случае трудно будет обеспечить надлежащий контроль конфигурации сервера. По мере роста баз данных и усложнения их структуры критическое значение приобретает распреде" ление сегментов баз данных по доступным серверным устройствам. Кроме того, для повышения на" дежности работы сервера следует уделять должное внимание выбору оптимальной схемы разбиения физических дисков на разделы и зеркальному резервированию этих разделов. Очень полезно соблю" дать стандартные схемы разбиения дисков, что позволяет организовать зеркальное отображение на уровне целых дисков и разделить тем самым все имеющиеся диски на диски файловых систем, сер" верных устройств и их зеркальных копий. Наконец, крайне важно обеспечить зеркальное резервиро" вание устройства master и журналов транзакций всех баз данных.

www.books-shop.com

www.books-shop.com

Глава 9

Восстановление сервера после сбоев Содержание Особенности различных версий SQL Server Выбор стратегии защиты от сбоев зависит от стоимости простоя сервера Отсутствие журнала транзакций — отсутствие базы данных Восстановление баз данных с точностью до отдельной транзакции Использование резервного сервера В базе данных master нет места пользователям! Использование команды dbcc Зеркальное резервирование данных Архивация данных Чем больше серверных устройств, тем лучше Общие рекомендации по восстановлению сервера Сервер архивации (Backup Server) Дампы баз данных Дампы журналов транзакций Логические дампы и программа SQL BackTrack компании DataTools Типы сбоев и порядок восстановления сервера

www.books-shop.com

Введение Процесс восстановления сервера после сбоев часто игнорируется изучающими SQL Server. Действи" тельно, здесь читателя ожидает не очень много интригующих моментов, да и методы, рассматривае" мые в данной главе, обычно нужны, когда дела совсем плохи (а заниматься резервированием данных уже слишком поздно). Поэтому администратор сервера еще до возникновения неприятностей дол" жен хорошо понимать все этапы процесса восстановления сервера и соответствующие требования к организации эксплуатации информационных систем. Вопросы, связанные с восстановлением сервера после сбоев, требуют изучения всех доступных источников информации. В первую очередь следует воспользоваться электронными версиями доку" ментации по программным продуктам Sybase, которые позволяют с помощью компьютера быстро находить нужные сведения среди тысяч страниц текста. Они также снабжают читателя списком ссы" лок по связанным проблемам. Одним из таких электронных источников является компакт"диск SyBooks, содержащий полный комплект документации по System 11, включая SQL Server, Open Ser" ver, а также руководство по устранению неполадок в SQL Server (SQL Server Troubleshooting Guide). Хотя все это относится к System 11, большая часть информации вполне применима и к SQL Server версии 4.9.2. Другим полезным компакт"диском является AnswerBase. В нем собраны многочислен" ные справочные материалы и руководства по установке, которые охватывают большинство техниче" ских проблем, возникающих при эксплуатации серверов Sybase. Кроме того, компания Sybase организует курсы по администрированию баз данных. Для читателей данной книги интересным бу" дет углубленный курс по администрированию System 11 (Advanced DBA for System 11). Используя компакт"диски SyBooks и AnswerBase, можно заниматься администрированием сервера в любом месте, где есть персональный компьютер с дисководом CD"ROM, не нося с собой бумажную документацию. Это особенно удобно, если серверы вашей компании разбросаны по всему миру, и вам приходится часто путешествовать. Кроме того, компакт"диск позволит выполнять многие опера" ции дома, в неурочное время, т.к. под рукой всегда есть полный комплект описаний и руководств. Наконец, диск AnswerBase содержит много информации, которая не вошла ни в одну из официаль" ных публикаций Sybase. Обязательно прочитайте руководство по устранению неполадок в SQL Server (SQL Server Troubleshooting Guide). Это далеко не самая захватывающая книга, но она позволит вам избежать многих ситуаций, когда от ужаса у вас на самом деле будет захватывать дух. Учитесь находить выход из серьезных неприятностей задолго до их возникновения. Особенности различных версий SQL Server Вопросы, рассматриваемые в настоящей главе, актуальны для всех версий SQL Server. Однако в зави" симости от используемой версии сервера процесс его восстановления имеет определенные особенно" сти. Во"первых, только в System 11 вам предстоит иметь дело с конфигурационными файлами и именованными кэш"буферами. Их существование необходимо учитывать при восстановлении серве" ра после сбоев. Кроме того, у разных версий SQL Server — разный состав системных баз данных. По" мимо базы данных master, SQL Server версий System 10 и 11 включает в себя sybsystemprocs и sybsecurity. База данных sybsystemprocs используется сервером System 10 и 11 для размещения системных хранимых процедур. База данных sybsecurity необходима только при использовании функций аудита, появивших" ся в составе SQL Server System 10 и поддерживаемых сервером System 11. Эти базы следует включить в процесс резервирования и восстановления данных. Наконец, напомним читателю, что на компьюте" рах фирмы Sun сервер System 11 работает только в операционной системе Solaris. Более подробно системные базы данных обсуждались в главе 7. В главе 8 мы рассматривали осо" бенности размещения системных баз данных по серверным устройствам для различного числа дис" ковых накопителей сервера. SQL Server 4.9.2 Работая с сервером версии 4.9.2, не нужно беспокоиться о конфигурационных файлах или именован" ных кэш"буферах. Единственной системной базой данных в этой версии сервера является база дан" ных master. Следует иметь в виду, что SQL Server 4.9.2 не сохраняет на одной магнитной ленте несколько дампов баз данных.

www.books-shop.com

SQL Server System 10 Как и SQL Server 4.9.2, сервер System 10 не имеет конфигурационных файлов и именованных кэш"бу" феров. Однако в его составе появились новые системные базы данных sybsystemprocs и sybsecurity. При работе с этой версией сервера важно обеспечить зеркальное резервирование серверных устройств master и тех устройств, на которых размещается база данных sybsystemprocs (а также база данных sybsecu rity, если она установлена на сервере). Только сервер System 11 поддерживает именованные кэш"буфе" ры и буферные области с большими блоками ввода"вывода, позволяющие ускорить выполнение dbcc"проверок; в предыдущих версиях сервера подобные структуры отсутствуют. В System 10 команды create database и alter database приобрели новый параметр "with override", позволяющий разместить сегмент журнала транзакций вместе с другими сегментами базы данных на одном устройстве. При этом обеспечивается возможность сохранения отдельных дампов журнала транзакций. Это может оказаться полезным в ряде ситуаций, но мы советуем придержива" ться практики выделения журнала транзакций на отдельное серверное устройство. Документация Sybase также не рекомендует использовать параметр "with override" без серьезной необходимости, поскольку при восстановлении базы данных, созданной или расширенной с указанием этого пара" метра, невозможно сохранить в дампе текущее содержимое журнала транзакций. Обычно перед на" чалом восстановления базы данных вы выполняете команду dump transaction <имя_базы_данных> with no_truncate, спасающую в дамп текущий журнал транзакций даже при недоступности всех остальных серверных устройств, поддерживающих базу данных. Созданный дамп текущего журнала транзакций в сочетании с полным дампом базы данных и последующими дампами журнала транзакций позволит точно воспроизвести базу данных на момент сбоя. Еще раз подчеркнем, что сохранение текущего журнала транзакций при использовании параметра "with over" ride" невозможно. Его следует использовать только при большом недостатке дискового пространст" ва — например, во время восстановления сервера после некоторых особо серьезных сбоев. SQL Server System 11 В составе System 11 впервые появились конфигурационные файлы и именованные кэш"буферы, кото" рые вносят существенные коррективы в процесс восстановления после сбоев. Например, админист" ратор сервера должен всегда быть готов воссоздать все детали используемой конфигурации сервера в процессе его восстановления (подробнее это будет рассмотрено в разделе "Общие рекомендации по восстановлению сервера" данной главы). Сервер System 11 также включает в себя все описанные выше особенности сервера System 10. Кроме того, с выходом SQL Server System 11 компания Sybase прекратила поддержку операционной системы SunOS, и указанная версия сервера работает на компь" ютерах Sun только под управлением системы Solaris. Аналогично серверам версий 4.9.2 и System 10, в SQL Server System 11 необходимо предусмотреть зеркальное резервирование серверных устройств master и тех устройств, на которых размещаются базы данных sybsystemprocs и sybsecurity (если последняя имеется на сервере). Выбор стратегии защиты от сбоев зависит от стоимости простоя сервера Вне зависимости от того, насколько хорошо администратор сервера разбирается в дампах баз дан" ных, dbcc"проверках и зеркальном отображении серверных устройств, его основная задача — сокра" тить время простоя сервера до минимума. Здесь очень важно правильно определить объем усилий, которые необходимо затратить на защиту от сбоев в вашей системе баз данных. Если ваша компания должна иметь гарантированную возможность круглосуточного доступа к базам данных в течение всей недели, вам следует заранее приобрести необходимые средства, позволяющие в любой момент спра" виться с неприятностями. Основная задача дальнейшего обсуждения — показать реальную стоимость каждой минуты про" стоя сервера. Некоторые системы обеспечивают возможность осуществлять в конце каждой недели профилактические операции на сервере и серверной машине (выполнение полных dbcc"проверок и т.д.) Работу других систем нельзя прерывать ни на минуту. Стратегию защиты от сбоев следует вы" бирать, учитывая особенности системы. В последнем случае вам потребуется установить резервный сервер, являющийся точной копией основного сервера системы. Разумеется, чтобы создать такой сервер и поддерживать его в состоянии постоянной готовности взять на себя всю нагрузку, потребу" ется много времени и средств. Однако любые дополнительные расходы необходимо сопоставить с размерами потерь, возникающих в случае простоя информационной системы. Подсчитайте, сколько

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

времени вам понадобится для восстановления основного сервера и его серверной машины после сбоя, затем оцените сумму потерь, которые понесет ваша компания за время простоя. Теперь затра" ты на дублирующий сервер уже не покажутся значительными. Отсутствие журнала транзакций — отсутствие базы данных Для организации эффективной защиты от сбоев и для понимания сущности операций, описанных в документации Sybase, читателю необходимо хорошо представлять себе основные этапы процесса вос" становления сервера. В этом разделе мы рассмотрим основы восстановления отдельной базы данных с использованием ее журнала транзакций и покажем, что он играет важнейшую роль при восстанов" лении базы данных. Поэтому необходимо принимать все возможные меры для обеспечения его со" хранности. Ниже мы представим важнейшие этапы процесса восстановления. Будут рассмотрены вопросы, связанные с созданием контрольных точек (checkpoints). Восстановление базы данных в SQL Server является сложной операцией. Однако сейчас наша главная задача — объяснить читателю, почему именно журнал транзакций представляет собой важнейший компонент базы данных. Серверная документация и опыт практической эксплуатации SQL Server могут создать у читателя впечатление, что база данных и журнал транзакций этой базы представляют собой два понятия, ни" как не связанные друг с другом. Можно допустить, что сбой диска, содержащего журнал транзакций, не представляет значительной опасности, поскольку в вашем распоряжении все равно останется вся информация, хранящаяся в самой базе данных (см. рис. 9.1). Можно также подумать, что и сбой устройства, на котором размещается база данных, не является фатальным. Ведь с помощью одного из прошлых дампов базы данных и комплекта последующих дампов журнала транзакций (а также те" кущего журнала транзакций, который еще не был сохранен в дампе) всегда можно полностью вос" становить содержимое базы данных на момент сбоя. Подобная точка зрения основана на предположении о немедленной записи на диск каждой зафиксированной транзакции, в результате чего база данных всегда включает в себя результаты этих транзакций. Читатель наверняка считает, что сбой журнала транзакций не отражается на самой базе данных. Кроме того, поскольку база дан" ных должна обновляться только после фиксации транзакции, вам трудно представить себе возмож" ность записи в базу данных результатов частично выполненной транзакции. Описанную систему взглядов нельзя назвать неразумной. Однако она не учитывает целый ряд небольших, но крайне су" щественных деталей. Ниже мы подробно рассмотрим характер взаимодействия базы данных со сво" им журналом транзакций в процессе {Обработки транзакций сервером и узнаем, что же в действительности представляет собой процесс создания контрольных точек. Сначала напомним читателю, что все операции обработки данных и ее журнала транзакций осу" ществляются в кэш"буфере данных. Он оказывается в оперативной памяти серверной машины лишь после загрузки в него необходимых страниц данных. Как только транзакция начинает читать дан" ные с диска и записывать их на диск, соответствующие страницы данных сначала читаются с диска в буфер (если, конечно, они уже не находятся в буфере). Попавшие в буфер модифицированные стра" ницы данных не записываются обратно на диск — сервер сбрасывает их на диск только при необхо" димости загрузить в заполненный буфер новые страницы. При этом из буфера удаляются страницы более ранней модификации (Least Recently Used). Подобный способ действий носит название LRU"алгоритма. SQLServer аза данных на одном или нескольких дисковых устройствах сервера (за исключением журнала транзакций) текущий журнал транзакций на одном или нескольких дисковых устройствах сервера дампы журнала транзакций на дисках файловой системы

дамп базы данных на дисках файловой системы (может храниться на магнитной ленте) Рис. 9.1. База данных и ее дампы

www.books-shop.com

Попробуем теперь понять, к каким последствиям приводит описанный выше механизм обработ" ки страниц в буфере. Пусть кэш"буфер воображаемого сервера вмещает в себя только 10 страниц данных, в то время как представленная на рис. 9.2 база данных состоит из 20 страниц. Забудем на время о пространстве буфера, занятом страницами индексов и журнала транзакций, которые дол" жны находится в том же самом кэш"буфере данных при их модификации. Предположим, что рас" сматриваемая нами транзакция вносит изменения во все записи базы данных, последовательно загружая в кэш"буфер очередные страницы данных. Поскольку каждая запись каждой страницы дан" ных модифицируется, исходное и измененное содержимое записи параллельно заносится в журнал транзакций, страницы которого также находятся в кэш"буфере данных (см. рис. 9.2). Все идет нор" мально вплоть до одиннадцатой страницы базы данных, считывание которой в память невозможно без удаления из буфера первой страницы (самой старой из всех). В момент, когда первая страница базы данных записывается на диск, чтобы освободить место для загрузки в буфер одиннадцатой страницы (см. рис. 9.3), дисковая копия базы данных теряет непротиворечивость (подчеркнем, что сейчас мы рассматриваем базу данных отдельно от ее журнала транзакций). Это происходит потому, что на диск записываются изменения, внесенные незафиксированной транзакцией. (В подобной си" туации одновременно с записью измененных страниц на диск сбрасываются и соответствующие Кэш*буфер данных в оперативной памяти сервера Дисковая копия базы данных

Страницы данных в кэш*буфере

Страницы журнала транзакций: в кэш*буфере данных

страница данных 1

страница данных 1 **

изменения в странице данных 1

страница данных 2

страница данных 2 **

изменения в странице данных 2

страница данных 3

страница данных 3 **

изменения в странице данных 3

страница данных 4

страница данных 4 **

изменения в странице данных 4

страница данных 5

страница данных 5 **

изменения

в странице данных 5

страница данных 6

страница данных 6 **

изменения

в странице данных 6

страница данных 7

страница данных 7 **

страница данных 8

страница данных 8 **

страница данных 9

страница данных 9 **

страница данных 10

страница данных 10 ** изменения в странице данных 10

Дисковая копия журнала транзакций

изменения в странице данных 7 изменения

в странице данных 8

изменения в странице данных 9

страница данных 11 страница данных 12 страница данных 13 страница данных 14 страница данных 15 страница данных 16 страница данных 17 страница данных 18 страница данных 19 страница данных 20 Страницы данных загружаются в память вплоть до заполнения кэш+буфера

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

Записи журнала транзак+ ций окончательно сбрасы+ ваются на диск только при фиксации транзакции

Рис. 9.2. Загрузка страниц базы данных в кэш*буфер сервера

www.books-shop.com

Кэш"буфер данных в оперативной памяти сервере Дисковая копия базы данных

Страницы данных в кэш*буфере

Страницы журнала транзакции в кэш*буфере данных

страница данных 1

страница данных 11 изменения в странице данных 11

страница данных 2

страница данных 2 **

страница данных 3

страница данных 3 ** изменения в странице данных 3

страница данных 4

страница данных 4 **

изменения в странице данных 4

страница данных 5

страница данных 5 **

изменения в странице данных 5

страница данных 6

страница данных 6 ** изменения в странице данных 6

страница данных 7

страница данных 7 ** изменения в странице данных 7

страница данных 8

страница данных 8 **

страница данных 9

страница данных 9 ** изменения в странице данных 9

страница данных 10

страница данных 10 ** изменения в странице данных 10

страница данных 11

изменения

в

Дисковая копия журнала транзакций изменения в странице данных 1

изменения в странице данных 2

изменения в странице данных 8

странице

данных

11

страница данных 12 страница данных 13 страница данных 14 страница данных 15 страница данных 16 страница данных 17 страница данных 18 страница данных 19 страница данных 20 кэш+буфер полон, и для обеспечения возможно+ сти загрузки страницы 11 первая страница за+ писывается на диск ** страница данных со+ держит изменения, вызванные незафиксиро+ ванной транзакцией

страница данных 11 Изменения, вносимые в страницы данных, записана в кэш+буфер, регистрируются в журнале транзакций после того как страни+ ца 1 была выгружена из буфера на диск

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

Рис. 9.3. Выгрузка на диск самой старой страницы базы данных, находящейся в кэш*буфере страницы журнала транзакций.) Если в этот момент журнал транзакций будет утрачен, модифициро" ванная первая страница навсегда останется в составе базы данных. Отличить внесенные в базу дан" ных результаты зафиксированных транзакций от изменений, вызванных текущими незавершенными транзакциями, будет невозможно. Мы не сможем вернуть базу данных в исходное состояние посред" ством отката незавершенных транзакций. После обработки транзакции (но до ее фиксации) ситуа" ция еще более усугубится: все 20 страниц данных будут загружены в буфер и модифицированы, но только 10 первых страниц окажутся записанными обратно на диск (см. рис. 9.4).

www.books-shop.com

Кэш+буфер данных в оперативной памяти сервера Дисковая копия журнала транзакций

Дисковая копия базы данных

Страницы данных в кэш+буфере

страница данных 1**

страница данных 11 **

изменения в странице данных 1

изменения в странице данных 1

страница данных 2**

страница данных 12 **

изменения в странице данных 2

изменения в странице данных 2

страница данных 3**

страница данных 13 **

страница данных 4**

страница данных 14**

изменения в странице данных 4

изменения в странице данных 4

страница данных 5**

страница данных 15 **

изменения в странице данных 5

изменения в странице данных 5

страница данных 6**

страница данных 16 **

страница данных 7**

страница данных 17 **

изменения в странице данных 7

изменения в странице данных 7

страница данных 8**

страница данных 18 **

изменения в странице данных 8

изменения в странице данных 8

страница данных 9**

страница данных 19 **

изменения в странице данных 9

изменения в странице данных 9

страница данных 10**

страница данных 20 **

изменения в странице данных 10 изменения в странице данных 10

Страницы журнала транзакций в кэш+буфере данных

изменения в странице данных 3

изменения в странице данных 6

страница данных 11

изменения в странице данных 11

страница данных 12

изменения в странице данных 12

страница данных 13

изменения в странице данных 13

страница данных 14

изменения в странице данных 14

страница данных 15

изменения в странице данных 15

страница данных 16

изменения в странице данных 16

страница данных 17

изменения в странице данных 17

страница данных 18

Г

изменения в странице данных 18

страница данных 19 /|

изменения в странице данных 19

страница данных 20

изменения в странице данных 20

кэш+буфер полон, и в кэш+буфере находятся Изменения, вносимые в страницы для обеспечения воз+ страницы с 11 по 20 данных, регистрируются в журнале можности загрузки транзакций страницы 11 первая страница записывается на диск ** страница данных содержит изменения, вызванные незафикси+ рованной транзакцией

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

Рис. 9.4. Обработка запроса завершена, но внесенные изменения еще не зафиксированы

www.books-shop.com

Измененные страницы данных и соответствующие страницы журнала транзакций необходимо за" писывать на диск одновременно. Поэтому журнал транзакций следует размещать только на неформа" тированном разделе диска с небуферизованным доступом. При записи страниц журнала транзакций (например, при фиксации результатов транзакции) сервер предполагает, что эти страницы оказыва" ются на диске немедленно. Однако в операционной системе UNIX запись в файловые системы про" изводится через системные буферы, и сервер не имеет возможности определить, находятся ли записываемые страницы на диске, или же ожидают записи в буфере операционной системы. Поэто" му, когда журналу транзакций назначается серверное устройство, поддерживаемое файлом операци" онной системы, возникает угроза потери возможности восстановить базу данных в случае сбоя серверной машины, и все содержимое буферов операционной системы окажется утраченным. Серверу удастся избежать записи на диск страниц данных, модифицированных незавершенной транзакцией, только при наличии большого объема оперативной памяти, способного вместить все страницы базы данных, включая страницы индексов и журнала транзакций. В этой гипотетической ситуации сервер мог бы загрузить в память все страницы данных, подлежащие модификации, затем внести в них требуемые изменения, дождаться фиксации транзакции и лишь потом записать на диск модифицированные страницы базы данных, а также накопленные записи журнала транзакций. Тог" да в базу данных действительно не вносилось бы никаких изменений вплоть до момента фиксации транзакции. Однако подобный подход крайне редко реализуется на практике. Во"первых, многие транзакции обрабатывают массивы данных, не способные целиком поместиться в память серверной машины. Во"вторых, если отложить запись модифицированных страниц до момента фиксации тран" закции, производительность сервера снизится, поскольку все эти страницы придется записывать на диск одновременно. Серверу намного проще записывать на диск страницы данных постепенно, по мере того, как они устаревают. Отметим, что во время выполнения транзакции доступ других пользователей к модифицирован" ным страницам блокируется сервером. Поэтому пользователи сервера узнают о внесенных измене" ниях только после фиксации транзакции. Вы получили общее представление об основных действиях сервера во время обработки транзак" ций. Теперь рассмотрим процесс создания контрольной точки (checkpoint) и одноименной коман" ды сервера, а также их воздействие на страницы данных, находящихся как в кэш"буфере, так и на диске. Как вы уже знаете, некоторые модифицированные страницы базы данных могут оставаться в буфере и не записываться на диск в течение определенного промежутка времени. В случае сбоя сер" вера, при последующем восстановлении базы данных сервер будет анализировать записи журнала транзакций, чтобы определить, какие страницы базы данных оказались измененными в результате каждой транзакции. Сервер также должен уточнить, была ли транзакция зафиксирована, отменена посредством отката либо осталась незавершенной. В зависимости от этого соответствующие страни" цы базы данных будут оставлены в измененном состоянии или возвращены в состояние на момент начала транзакции. Количество транзакций, обрабатываемых сервером в момент сбоя, и модифици" рованных ими страниц определяет число изменений, которые сервер вносит в базы данных, чтобы восстановить их состояние на момент сбоя. Сервер проверяет, есть ли в базах данных результаты всех зафиксированных транзакций и удаляет любые изменения, произведенные транзакциями, ко" торые остались незавершенными в результате сбоя. Именно для этого журнал транзакций содержит данные каждой строки страницы базы данных в исходном и измененном виде. Если в базу данных необходимо внести большое число изменений, процесс ее восстановления может растянуться на длительное время, называемое периодом восстановления. Для сокращения этого периода можно ограничить максимальное количество проверяемых сервером изменений. Для этого нужно активизировать процесс создания контрольной точки, когда все страницы кэш"буфера данных, модифицированные с момента создания предыдущей контрольной точки, сбрасываются сервером на диск. После завершения сброса контрольной точки содержимое базы данных на диске будет полностью соответствовать ее страницам данных, остающимся в кэш"буфере (см. рис. 9.5). За" пись о создании контрольной точки также вносится в журнал транзакций для регистрации момента времени, когда страницы базы данных на диске были приведены в соответствие с их копиями, нахо" дящимися в кэш"буфере. В этот момент все зарегистрированные в журнале транзакций изменения оказались внесенными в дисковую копию базы данных. Таким образом, при восстановлении базы данных серверу придется проверять только изменения, внесенные в журнал транзакций после созда" ния последней контрольной точки. Однако в случае отката транзакции, открытой на момент созда" ния контрольной точки, серверу придется воспользоваться и более ранними записями журнала транзакций.

www.books-shop.com

Кэш буфер данных в оперативной памяти сервера Страницы журнала транзакций в кэш+буфере данных

Дисковая копия базы данных страница данных 1**

Страницы данных в кэш+буфере страница данных 11 **

изменения в странице данных 1

изменения в странице данных 1

страница данных 2**

страница данных 12 **

изменения в странице данных 2

изменения в странице данных 2

страница данных 3**

страница данных 13 **

изменения в странице данных 3

изменения в странице данных 3

страница данных 4**

страница данных 14 '**. изменения в странице данных 4

изменения в странице данных 4

страница данных 5**

страница данных 15 **

изменения в странице данных 5

изменения в странице данных 5

страница данных 6**

страница данных 6 **

изменения в странице данных 6

изменения в странице данных 6

страница данных 7**

(страница данных 7 **

изменения в странице данных 7

изменения в странице данных 7

страница данных 8**

страница данных 8 **

изменения в странице данных 8

изменения в странице данных 8

страница данных 9**

изменения в странице данных 9 изменения в странице данных 9 изменения в странице страница данных 10 ** изменения в странице данных 10 данных 10

страница данных 10**

Дисковая копия журнала транзакций

страница данных 9 **

страница данных 11**

изменения в странице данных 11

изменения в странице данных 11

страница данных 12**

изменения в странице данных 12

изменения в странице данных 12

страница данных 13**

изменения в странице данных 13

изменения в странице данных 13

страница данных 14**

изменения в странице данных 14

изменения в странице данных 14

страница данных 15**

изменения в странице данных 15

изменения в странице данных 15

страница данных 16 страница данных 17 страница данных 18 страница данных 19 страница данных 20 кэш буфер полон и со+ в кэш+буфере находятся Изменения, вносимые в страницы дан+ держит страницы базы страницы с 6 по 15 ных, регистрируются в журнале тран+ данных, обработанные закций последними; страницы, модифицированные ра+ нее и не поместившиеся в буфере, записаны на ДИСК ** страница данных содержит изменения, вызванные незафиксиро+ ванной транзакцией

при создании контрольной точки все модифицированные ("грязные") страницы данных сбрасываются на диск вне за+ висимости от того, были ли зафиксированы соответствую+ щие транзакции

Рис. 9.4. Обработка запроса завершена, но внесенные изменения еще не зафиксированы

www.books-shop.com

Есть два способа создания контрольных точек. Во"первых, приблизительно один раз в минуту сер" вер автоматически проверяет журнал транзакций каждой базы данных. На основании объема инфор" мации, внесенной в этот журнал зафиксированными транзакциями, он оценивает время, необходимое для внесения всех изменений в случае восстановления базы данных. Если вычисленный период време" ни превышает максимальную продолжительность периода восстановления, указанную в конфигура" ции сервера (соответствующий параметр recovery_interval выдается и модифицируется командой sp_configure), сервер автоматически выполняет команду checkpoint и сбрасывает на. диск все страницы данных, модифицированные с момента предыдущей контрольной точки. Подчерк" нем, что при создании контрольной точки на диск сбрасываются абсолютно все модифицированные страницы базы данных, а не только те, которые содержат результаты зафиксированных транзакций. Во"вторых, команду checkpoint может вручную ввести администратор сервера. Этот подход удобен, например, перед остановом сервера командой shutdown nowait (при обычном останове командой shutdown без параметра nowait сервер выполняет сброс контрольной точки автоматически). Этот вариант можно применить при создании дампа базы данных командой dump database. При этом со" храняемый дамп включает в себя все изменения, внесенные в страницы базы данных на момент созда" ния дампа. Сюда входят также изменения, сделанные незафиксированными транзакциями. Поэтому, загружая дамп базы данных, сервер должен провести анализ записей журнала транзакций, который также включается в дамп базы данных, выводимый командой dump database. Итак, при отсутствии журнала транзакций база данных редко находится в корректном непроти" воречивом состоянии. Если журнал транзакций базы данных утрачен, сервер не сможет открыть ее после следующего же перезапуска. (В процессе перезапуска сервер восстанавливает корректное со" стояние базы данных. Однако без журнала транзакций это невозможно.) База данных будет помече" на как "подозрительная", что запретит не только подключение к ней командой use <имя_6азы_данных>, но и вообще какой"либо доступ. Термин "подозрительная" точно отражает суть дела. База данных может по"прежнему нормально обрабатываться сервером, и dbcc"проверки не найдут в ней никаких нарушений, но без журнала транзакций сервер не может установить, остались ли в этой базе данных изменения, произведенные незавершенными транзакциями. Конечно, адми" нистратор сервера может вручную модифицировать системную таблицу sysdatabases и отменить "по" дозрительность" базы. После этого сервер сможет продолжить нормальную обработку этой базы данных. Однако подобная операция будет означать, что все внесенные в базу данных изменения ваша компания признает корректными. Перед тем как пойти на столь решительный шаг, обязатель" но проконсультируйтесь со своими пользователями (а также со службой технической поддержки Sy" base). Напомним о необходимости размещения журнала транзакций отдельно от всех остальных сегментов базы данных. Его следует расположить на диске, подключенном к дисковому контроллеру, не обслуживающему другие сегменты той же базы данных. Кроме того, если нельзя организовать полное зеркальное резервирование всех серверных устройств, зеркальные копии журналов транзак" ций должны создаваться сразу же после зеркальной копии серверного устройства master. Рассмотрим теперь ситуацию, когда отказ происходит на одном из серверных устройств, поддер" живающих сегменты базы данных, а сам журнал транзакций остается в сохранности. Если нет зерка" льной копии отказавшего устройства, администратор сервера должен воссоздать пострадавшую базу данных и затем загрузить содержимое базы из ее дампов и журнала транзакций. Для полного восста" новления базы данных на момент сбоя необходимо заранее сохранить дамп текущего журнала тран" закций. Если это нельзя сделать обычной командой dump transaction из"за недоступности базы данных, следует создать этот дамп с помощью команды dump transaction <имя_6азы_данных> with no_truncate. Сервер воспользуется информацией, хранящейся в базе данных master, и попы" тается напрямую прочитать содержимое журнала транзакций с диска. Заметим, что успешное созда" ние дампа командой dump transaction с параметром no_truncate возможно только при условии сохранения работоспособности сервера и доступности базы данных master (см. рис. 9.6). Создав дамп текущего журнала транзакций, вы удаляете базу данных и приступаете к ее восста" новлению. Обратите внимание на то, что сбой устройства может препятствовать перезапуску серве" ра. Поэтому сохранить дамп текущего журнала транзакций необходимо до останова сервера. В случае отказа одного из серверных устройств, поддерживающего другие сегменты базы дан" ных, следует сохранить дампы текущего журнала транзакций, даже если имеется зеркальная копия журнала транзакций. Это нужно сделать, потому что при удалении поврежденной базы данных сер" вер автоматически удалит оба устройства зеркальной пары, поддерживающей журнал транзакции. Сохранение дампа текущего журнала транзакций поврежденной базы данных возможно только при наличии базы данных master и серверного устройства master. Именно поэтому это устройство должно в первую очередь получить зеркальную копию (напомним, что зеркальное резервирование устанавливается на уровне серверных устройств, а не отдельных баз данных). Конечно, во всех

www.books-shop.com

dump transaction db1 with no_truncate серверное устройство master остается доступным

текущий журнал транзакций базы данных db1 остается доступным, поскольку находится на другом серверном устройстве

текущее содержимое журнала транзакций записывается в дисковый файл SQL Server В результате отказа одного из устройств сервера вам предстоит удалить базу данных db1, а затем восстановить ее. Для того чтобы восстановленная база в точности соответствовала своему состоянию на момент сбоя, серверу необходимо использовать заранее созданный дамп текущего журнала транзакций. Условием его успешного создания является работоспособность сервера и доступность серверного устройства master, а также серверного устройства, содержащего журнал транзакций. Рис. 9.6. Создание дампа текущего содержимого журнала транзакций случаях следует стремиться организовать полное зеркальное резервирование всех устройств сервера (см. главу 8). В начале данного раздела мы предположили, что база данных без журнала транзакций представ" ляет собой один непротиворечивый набор хранящихся в ней данных, а журнал транзакций в сочета" нии с его последующими дампами и последним полным дампом базы данных образует второй эквивалентный набор тех же самых данных. Как видите, только вторая часть этого предположения оказалась верной. При утрате текущего журнала транзакций единственным способом воссоздания базы данных является возврат к ее последнему полному дампу с последующей загрузкой всех имею" щихся дампов журнала транзакций. При этом база данных принимает состояние, в котором она была в момент сохранения последнего дампа журнала транзакций, а все последующие изменения вплоть до момента сбоя оказываются утраченными. Утрата текущего журнала транзакций означает не только потерю всех текущих транзакций, но и результатов зафиксированных транзакций, кото" рые еще не были сброшены на диск. Таким образом, администратору сервера следует уделить особое внимание резервированию сер" верного устройства master и журналов транзакций всех баз данных. Даже при наличии дампа базы данных и полной последовательности дампов журнала транзакций база данных восстанавливается только на момент создания последнего из этих дампов. В зависимости от характера деятельности ва" шей компании, стоимость потери последних транзакций в результате утраты текущего журнала транзакций может оказаться весьма внушительной. ДИСКОВАЯ КОПИЯ ЖУРНАЛА ТРАНЗАКЦИЙ begin transaction A команда транзакции А

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

команда транзакции А begin transaction В команда транзакции А

При создании контрольной точки на диск сбрасываются все записи, связанные с транзакцией В.

команда транзакции В commit transaction A команда транзакции В

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

checkpoint Рис. 9.7. Сохранение записей журнала транзакций на диске

www.books-shop.com

Восстановление баз данных производится с точностью до отдельной транзакции Администратор сервера обычно представляет себе процесс воссоздания данных после сбоя в виде пе" речня подлежащих восстановлению компонентов сервера и соответствующих сообщений об ошиб" ках. Однако на самом деле сервер восстанавливает не саму хранившуюся в базах данных информацию, а последовательность отдельных зафиксированных транзакций. Используемые прило" жения могут не давать гарантии, что после завершения каждой отдельной зафиксированной транзак" ции база данных окажется в состоянии, допустимом с точки зрения бизнес"правил. Тогда даже успешное восстановление базы данных не будет залогом соответствия восстановленной информации этим правилам. Разумеется, администратор сервера не в силах проконтролировать правильность всех имеющихся приложений. Однако указанное обстоятельство обязательно необходимо иметь в виду, когда пользователи спрашивают, насколько удачным оказалось восстановление сервера. В случае, когда бухгалтерское приложение оформляет поступление средств и заносит их на счета посредством независимых транзакций, даже после полного успешного восстановления сервера вы не можете быть уверены, что все поступившие суммы оказались внесенными на соответствующий счет. При восста" новлении после сбоя сервер просто откатывает назад все незавершенные транзакции, вне зависимо" сти от их конкретного содержания. Эту проблему должны решать разработчики приложений, определяющие особенности логиче" ской организации процесса обработки базы данных. Само существование проблемы предполагает тщательное соблюдение принципа корректности отдельных транзакций при разработке и модифи" кации приложений. Кроме того, это служит весомым аргументом в пользу обеспечения круглосуточ" ной работы сервера, поскольку подобные трудности возникают только при восстановлении баз данных после сбоя или останова сервера. Наконец, рассматриваемая проблема оправдывает макси" мальное ограничение прямого доступа пользователей к основному серверу системы оперативной об" работки транзакций. Дело в том, что любой подключившийся к серверу пользователь имеет потенциальную возможность при ручном вводе команд на время вывести базу данных из допустимо" го состояния. В случае сбоя сервер восстановит базу данных, не выдавая никаких предупредитель" ных сообщений. Использование резервного сервера Обычно защиту баз данных от сбоев связывают с регулярным созданием дампов самих баз данных и их журналов транзакций. Однако на самом деле сюда входит весь комплекс возможных мер, призван" ных обеспечить сохранность данных и их постоянную доступность для пользователей. Чтобы сокра" тить период недоступности данных при отказах сервера, можно использовать резервный сервер, который позволяет продолжить нормальную работу информационной системы во время восстанов" ления основного сервера. В данном разделе рассматриваются вопросы, возникающие при создании и поддержании резервного сервера. При этом речь пойдет о сервере, работающем на отдельной сер" верной машине и призванном поддерживать систему оперативной обработки транзакций. Прежде чем создавать резервный сервер, следует оценить стоимость потерь, вызываемых про" стоем информационной системы вашей компании. Без этой информации будет крайне трудно най" ти ответы на организационные вопросы, возникающие в связи с установкой резервного сервера. Кроме того, необходимо заранее определить, должен ли резервный сервер обеспечивать долгосроч" ную замену основного сервера, или он будет использоваться на протяжении коротких промежутков времени. В первом случае возможности резервного сервера должны как можно точнее соответство" вать возможностям основного сервера, включая модель серверной машины, версию операционной системы, количество процессоров, физических дисков и дисковых контроллеров, объем оператив" ной памяти и сетевых адаптеров, организацию зеркального отображения серверных устройств, со" став устройств вывода дампов, набор cron"заданий, список пользователей и т.д. Также потребуется определить состав баз данных, поддерживаемых резервным сервером. Оба сервера должны содер" жать одинаковый набор баз данных. При конфигурировании краткосрочного резервного сервера можно ограничиться серверной ма" шиной меньшей мощности, поддерживающей только те базы данных, которые будут абсолютно не" обходимы пользователям на протяжении непродолжительного времени восстановления главного сервера. Следует иметь в виду, что при неполной эквивалентности основного и резервного серверов вы не можете гарантировать ни сохранения производительности информационной системы, ни ее полной защиты от сбоев — например, из"за отсутствия в малом сервере достаточного дискового

www.books-shop.com

пространства для быстрой записи на диск дампов баз данных. В любом случае, организация резерв" ного сервера требует значительных средств, а также рабочего времени обслуживающего персонала. Убедитесь, что вы располагаете достаточным количеством сотрудников, способных установить ре" зервный сервер и поддерживать его постоянную готовность. Резервный сервер принесет вам мало пользы, если им нельзя будет воспользоваться в любой момент. Поэтому часть служащих должна им постоянно заниматься, даже если долгое время он простаивает. Решение сделать резервный сервер точной копией основного оказывается оправданным далеко не во всех случаях. Вне зависимости от того, насколько мощным является ваш резервный сервер, пе" реключение на него в любом случае потребует много времени, в течение которого базы данных все равно будут недоступны. Подсчитайте эти неизбежные потери и сравните их со стоимостью различ" ных конфигураций резервного сервера. Вполне возможно, что на средства, необходимые для уста" новки полноценного долговременного резервного сервера, вы сможете приобрести набор запасных частей, достаточный для полной замены всех компонентов основной серверной машины. В подоб" ной ситуации сопоставьте время, нужное для полной замены компонентов основного сервера, со временем, затраченным на переключение на резервный сервер. Если вы все"таки решили создать резервный сервер, определите способ, позволяющий поддержи" вать его в состоянии, как можно более точно соответствующем состоянию основного сервера. Глав" ное назначение резервного сервера — прийти на замену отказавшему основному серверу за более короткое время, чем то, которое нужно для восстановления работоспособности основного сервера. Поэтому резервный сервер должен с минимальной задержкой воспроизводить все транзакции, вы" полняемые главным сервером системы. В некоторых случаях достаточно ограничиться регулярным сохранением дампов баз данных основного сервера с их последующей загрузкой в резервный сервер. Именно так обычно обновляет" ся состояние серверов в системах поддержки принятия решений. При подобном подходе резервный сервер отстает от основного максимум на один интервал между последовательным сохранением дам" пов баз данных. Если, например, базы данных основного сервера сбрасываются в дампы ежедневно, то резервный сервер будет отставать от основного примерно на день. При переключении на него вам придется загрузить максимум один суточный комплект дампов журналов транзакций (после ко" пирования этих дампов с одной серверной машины на другую). Разумеется, подобная операция зай" мет определенное время и, вполне возможно, значительное. Кроме того, мы исходим из предположения, что после сбоя основная серверная машина сохраняет работоспособность, доста" точную для копирования имеющихся дампов журналов транзакции. Поскольку у нас нет никаких га" рантий столь удачного развития событий, копирование дампов на резервную машину следует производить немедленно после их создания основным сервером. При отсутствии достаточного времени на загрузку дневного комплекта дампов журналов транзак" ций их необходимо загружать в резервный сервер по мере их сохранения на основном сервере (с помощью команды load transaction <имя_6азы_даниых>). Такой способ действий значите" льно сокращает интервал отставания резервного сервера от основного, делая его равным максимум одному интервалу между созданием последовательных дампов журналов транзакций (см. рис. 9.8). В зависимости от требуемой скорости переключения на резервный сервер загрузку дампов журна" лов транзакций основного сервера можно осуществлять немедленно после их создания либо перио" дически, загружая сразу несколько скопированных дампов. Здесь администратору сервера вновь 1) полный дамп базы данных создается на основном сервере, затем копируется на резервную машину и загружается в резервный сервер

2) на основной машине регулярно сохраняются дампы журнала повтора, которые немедленно копируются на резервную машину и затем загружаются в резервный сервер

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

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

следует определить стоимость каждого подхода и выбрать более выгодный. Важно отметить, что не" медленная загрузка очередных дампов журналов транзакций представляет собой весьма трудоемкий процесс. Если возникнут проблемы с загрузкой дампа журнала транзакций в одну из баз данных ре" зервного сервера, вам придется дожидаться создания ближайшего полного дампа этой базы данных на основном сервере. Затем нужно загрузить этот дамп с последующей загрузкой всех новых дампов журнала повтора, накопившихся за время копирования и загрузки полного дампа. Только потом можно вернуться к нормальному процессу регулярной загрузки текущих дампов журнала транзакций. Другими словами, после сбоя крайне редко удается загрузить дамп журнала транзакций повторно. Таким образом, обновление резервной базы данных прекратится вплоть до ближайшего сохранения полного дампа соответствующей базы данных на основном сервере. Наконец, дампы журналов тран" закций должны копироваться с основной машины сразу после их создания, вне зависимости от вы" бранной частоты загрузки. Делать это после отказа основной машины, возможно, будет уже поздно. Даже при своевременной загрузке дампов журналов транзакций переключение на резервный сер" вер все равно потребует сохранения дампа текущего журнала транзакций отказавшего сервера и его загрузки в резервный. Это необходимо для полного включения в базы данных резервного сервера результатов последних транзакций, зафиксированных перед отказом основного сервера. Здесь мы сталкиваемся с основным недостатком резервного сервера — его состояние всегда отстает от основ" ного в пределах одного интервала между сохранением дампов журналов транзакций. Однако не сле" дует забывать, что при восстановлении основного сервера без использования резервного нам все равно потребовалось бы создать дампы текущих журналов транзакций и загрузить их после воссозда" ния утраченных баз данных и загрузки в них всех предыдущих дампов. Поэтому резервный сервер всегда соответствует состоянию основного сервера после сбоя, поскольку восстановление базы дан" ных на момент сбоя невозможно без сохранения текущего журнала транзакций. Однако резервный сервер дает возможность избежать всех хлопот по удалению пострадавших баз данных, их восста" новлению и последующей загрузке прежних дампов. Он позволяет ограничиться только созданием и загрузкой дампа текущего журнала транзакций. Разумеется, при отказе основного сервера, препятст" вующем сохранению текущего содержимого журнала транзакций, резервный сервер не удастся при" вести в состояние, соответствующее состоянию основного сервера на момент сбоя. Однако следует учесть, что в подобной ситуации восстановление баз данных основного сервера на момент его сбоя также становится невозможным. Установка резервного сервера имеет ряд условий. Во"первых, он ни в коем случае не должен быть доступен для пользователей, поскольку случайное внесение изменений в резервные базы дан" ных (или даже сам факт подключения к ним) сделает дальнейшую загрузку дампов журналов транзак" ций основного сервера невозможной. Во"вторых, базы данных резервного сервера, обновляемые путем периодической загрузки дампов журналов транзакций, должны работать в режиме "no chkpt on recovery". Дело в том, что SQL Server после перезапуска автоматически производит восстановление всех имеющихся баз данных. Обычно процесс восстановления базы данных начинается с создания контрольной точки для синхронизации "грязных" страниц данных с соответствующими страницами дисковой копии базы данных. ("Гряз" ные страницы" — это модифицированные страницы базы данных, находящиеся в кэш"буфере и еще не записанные на диск.) Однако создание контрольной точки связано с внесением изменений в со" стояние базы данных. Эти изменения делают невозможной загрузку последующих дампов журналов транзакций. В результате при работе резервных баз данных в устанавливаемом по умолчанию режи" ме загрузку журналов транзакций удастся продолжить только до ближайшего перезапуска сервера. Для поддержания резервного сервера в постоянной готовности журналы транзакций должны не" прерывно копироваться с основной серверной машины на резервную. Если при загрузке одного из дампов журнала транзакций возникнут проблемы, потребуется загрузить в резервный сервер следую" щий полный дамп соответствующей базы данных основного сервера. Все подобные операции на" много проще и быстрее выполнять с дисковых накопителей, и поэтому как основная, так и резервная машины должны обладать достаточным дисковым пространством для сохранения дампов журналов транзакций и полных дампов баз данных. По всей вероятности, дампы журналов транзак" ций понадобится сохранять на протяжении нескольких циклов создания полных дампов баз дан" ных — на тот случай, если один из полных дампов окажется непригодным для использования. Это требование, а также необходимость хранения на дисках последнего полного дампа основной базы данных (как минимум) обусловливают значительное увеличение нужного дискового пространства (подробнее см. главу 11). Если на основной серверной машине дополнительное дисковое простран" ство необходимо прежде всего для ускорения создания дампов баз данных и журналов транзакций, то на резервной машине эквивалентное пространство будет использовано для хранения копий этих дампов. Однако после переключения на резервный сервер новые дампы баз данных будут

www.books-shop.com

записываться непосредственно на дисковое пространство резервной машины. Отметим, что SQL Server System 10 значительно облегчает сохранение на диске полных дампов баз данных, позволяя записывать каждый такой дамп в несколько дисковых файлов, которые можно распределять по раз" личным дискам файловой структуры (такая операция называется striping). Для максимального сокращения времени переключения на резервный сервер, по истечении кото" рого последний начинает поддерживать пользовательские приложения, резервный сервер должен быть как можно более точной копией основного. Поскольку основные базы данных резервного серве" ра непрерывно обновляются путем загрузки журналов транзакций с основного сервера, все изменения в эксплуатационных копиях этих баз данных через некоторое время автоматически отражаются в ба" зах данных резервного сервера. Однако это не относится к изменениям в системной базе данных mas ter основного сервера (а начиная с System 10 — также и в базах данных sybsystemprocs и sybsecurity). Поэтому резервный сервер не обладает полным набором учетных записей пользователей основного сервера. Создавая резервный сервер, следует вручную синхронизировать информацию о пользовате" лях. Это делается путем копирования утилитой Ьср данных из таблицы syslogins базы данных master основного сервера. При вызове утилиты bср обязательно следует указывать параметр "с. Он позво" ляет получить файл данных в пригодном для чтения формате, поскольку вам потребуется удалить из этого файла первую строку, содержащую пользователя 'sa'. Резервный сервер содержит уже одного такого пользователя (администратора сервера). Поэтому загрузка утилитой bср файла данных, со" держащего дублирующие записи таблицы syslogins, будет заблокирована сервером. Заметим, что если в вашей системе используется двухфазная схема фиксации транзакций, то в таблице syslogins резерв" ного сервера должен также находится пользователь "probe". Его описание необходимо удалить из за" гружаемого дампа таблицы syslogins основного сервера вместе с описанием пользователя 'sa'. При переключении на резервный сервер вам снова придется вручную синхронизировать табли" цы syslogins основного и резервного сервера, предварительно удалив из таблицы syslogins резервного сервера описания всех пользователей, за исключением пользователя 'sa' (и, возможно, пользователя 'probe'). Ни в коем случае не удаляйте таблицу syslogins с основного сервера, поскольку при этом в нем не останется ни одного пользователя, и доступ к основному серверу (например, для вывода фай" лов данных утилитой bср) станет невозможным. Для успешного переключения на резервный сервер требуется тщательная предварительная под" готовка. Заранее составьте подробный план переключения, который значительно ускорит ваши дей" ствия. Поскольку основное назначение резервного сервера заключается в сокращении времени недоступности информационной системы, любая задержка уменьшает выгоду использования резерв" ного сервера. Не забудьте отразить в плане перехода на резервный сервер используемую процедуру переключения пользователей основного сервера — либо путем оперативного распространения всем пользователям нового файла интерфейсов, либо с помощью самостоятельного изменения пользова" телями значения переменной среды DSQUERY на своих машинах. (Переменная DSQUERY содержит имя сервера, используемого по умолчанию, и в этом случае необходимо заранее убедиться, что все пользовательские файлы интерфейсов содержат описание резервного сервера). Используя резервный сервер, вы сможете оценить все преимущества небольших баз данных, дам" пы которых быстро создаются и загружаются. При этом они требуют немного дискового простран" ства, что позволяет хранить дампы журнала транзакций в течение большего периода времени. Разумные размеры баз данных также значительно ускоряют выполнение dbcc"проверок. Это повы" шает гарантии создания корректных дампов баз данных и журналов транзакций, облегчает процесс их загрузки в резервный сервер и сокращает время переключения на резервную систему. Для сокра" щения размеров основных баз данных регулярно удаляйте из них устаревшие данные, помещая их в отдельные архивные базы данных. Для эффективной работы резервного сервера требуется выполнить рутинные операции — напри" мер, расширить дисковое пространство, используемое базами данных основного сервера. Одновре" менно с выделением новой дисковой области одной из баз данных основного сервера аналогичная область должна быть выделена и для соответствующей базы данных резервного сервера, поскольку загрузка журналов транзакций в прежнюю базу данных через некоторое время обязательно приве" дет к ее переполнению. Однако не следует добавлять резервной базе данных больше дискового про" странства, чем основной. На это есть три причины. Во"первых, может нарушиться соответствие структур сегментов основной и резервной базы дан" ных. Хотя различие в сегментации баз данных не будет препятствовать загрузке дампов журнала транзакций или полного дампа базы данных, размещение одних и тех же объектов данных в различ" ных сегментах основной и резервной базы данных может впоследствии привести к весьма серьез" ным проблемам. Во"вторых, структура сегментов основного сервера была оптимизирована с целью повышения производительности используемых приложений (см. главу 8). После переключения на

www.books-shop.com

резервный сервер КОНТРОЛЛЕР ДИСКОВ О (четыре диска)

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

КОНТРОЛЛЕР ДИСКОВ 1 (четыре диска)

Рис. 9.9. Конфигурация дисков основного и резервного сервера резервный сервер с другой структурой сегментов информационная система может не достигнуть прежней производительности. В"третьих, идентичность основной и резервной баз данных позволя" ет модифицировать структуру резервной базы данных теми же командами, которые указывались при расширении основной базы данных. Разумеется, здесь потребуется точное соответствие состава контроллеров, дисковых накопителей и разделов дисков основной и резервной машин. В этом слу" чае администратор сервера сможет создавать и сопровождать базы данных резервного сервера с по" мощью тех же командных файлов, которые применяются на основном сервере. Если таких командных файлов нет, они могут быть сгенерированы на основе структуры баз данных основного сервера с помощью командного файла p_dbcreate (см. главу 14). В целом подобный подход позво" ляет обеспечить полную идентичность структуры сегментов баз данных основного и резервного сер" вера (см. рис. 9.9). В заключение заметим, что во время нормального функционирования основной OLTP"системы в качестве резервного может использоваться сервер, обеспечивающий поддержку системы принятия решений или являющийся выделенным сервером для выполнения dbcc"проверок. Для переключе" ния здесь потребуется привести базы данных этого сервера в соответствие с текущим состоянием баз данных основного сервера, использовав дампы журналов транзакций с основного сервера. При необходимости можно загрузить недостающие дампы баз данных основного сервера. Так же, как и при работе с выделенным резервным сервером, структура сегментов баз данных и конфигурация ди" скового пространства вторичного сервера должна в максимальной степени соответствовать основ" ному серверу. Наконец, для воспроизведения транзакций, обрабатываемых основным сервером, может приме" няться сервер тиражирования Replication Server. Загрузка журналов транзакций позволяет загрузить все необходимые транзакции за один прием; кроме того, использование дампов журналов транзак" ций может оказаться более простым способом синхронизации резервного сервера.

www.books-shop.com

В базе данных master нет места пользователям! Никогда не позволяйте пользователям помещать свои объекты в базу данных master (и сами соблюдай" те это правило). Чем меньше информации содержится в базе данных master, тем быстрее и проще она восстанавливается. Кроме того, после ее восстановления все находившиеся в ней пользовательские объекты окажутся удаленными. Это может произойти при очистке конфигурации сервера командой buildmaster . (Очистка конфигурации случается из"за неудачного выбора значении ее параметров при вызове процедуры sp_conf igure.) To же самое будет и с вашими объектами. Тогда возникнет необходимость создания специального командного файла для их периодического воссоздания. Ко" нечно, в подобной ситуации администратор сервера может попытаться загрузить полный дамп базы данных master, но это операция весьма трудоемка. Кроме того, в зависимости от повода, заставившего воспользоваться командой buildmaster, у администратора могут появиться веские причины не за" гружать все системные таблицы, содержащиеся в дампе базы данных master. Хранимые процедуры и другие объекты, необходимые администратору сервера в его работе, луч" ше всего помещать в специальной базе данных dbadb, которую будет нетрудно восстановить из дампа после сбоя или перенести на любой другой сервер (объекты администратора сервера, размещенные в базе данных master, следует вручную извлечь оттуда и затем по отдельности включить в базу данных master нового сервера). В SQL Server System 10 и 11 администратор сервера может размещать свои объекты и процедуры в базе данных sybsystemprocs. Однако воссоздание этой базы после сбоя приведет к утрате всех посто" ронних объектов. Поэтому подобные объекты также рекомендуется хранить в специально создан" ной базе данных. Использование команды dbcc Читателю наверняка известно о необходимости регулярного выполнения dbcc"проверок всех баз дан" ных сервера. Однако, даже соблюдая график таких проверок, можно столкнуться с целым рядом проблем. Они рассматриваются в данном разделе главы. Подробное описание различных подкоманд команды dbcc и осуществляемых ими действий содержится в руководстве системного администрато" ра SQL"сервера (Sybase SQL Server System Administration Guide), а также в руководстве по устранению неполадок в SQL Server (SQL Server Troubleshooting Guide). Поэтому мы не будем останавливаться на этом. Для получения корректных результатов база данных во время выполнения dbcc"проверок должна работать в однопользовательском режиме. В противном случае любая транзакция, вносящая измене" ния в проверяемую базу данных и выполняемая пользователем одновременно с работой dbcc, при" ведет к наведенным сообщениям об ошибках. Поэтому выполнение dbcc"проверки означает недоступность соответствующей базы данных для пользователей. Кроме того, база данных mastertSK же должна периодически подвергаться dbcc"проверкам. Однако администратор сервера лишен воз" можности устанавливать режимы работы базы данных master (см. главу 7). Поэтому ее невозможно перевести в однопользовательский режим без перезапуска всего сервера в однопользовательском ре" жиме. Это делается путем задания параметра "т в команде dataserver. Таким образом, dbcc"проверки увеличивают время частичной или полной недоступности сервера. По мере роста нагрузки на сервер и увеличения требуемого времени его доступности (вплоть до непрерывной круглосуточной работы, что характерно прежде всего для OLTP"систем) администра" тор сервера может оказаться в ситуации, когда у него нет возможности регулярного осуществления полного набора необходимых dbcc"проверок. В таком случае он вынужден проверять только отдель" ные таблицы данных. Это оборачивается отсутствием контроля за состоянием некоторых баз дан" ных, что недопустимо. Для ускорения dbcc"проверок можно создать в сервере буферную область с большими блоками ввода"вывода. Непосредственно перед запуском команды dbcc измените командой sp_poolconfig конфигурацию сервера. Почти все пространство общего кэш"буфера данных (default data cache) бу" дет предоставлено области с 16"килобайтными буферными блоками. (Напомним, что любой имено" ванный кэш"буфер, включая общий буфер данных, всегда должен содержать буферную область с 2"килобайтными блоками, размер которой не может быть менее 512 Кбайт.) Наличие на сервере бу" ферной области с блоками по 16 Кбайт значительно ускоряет выполнение dbcc"проверок. Однако, завершив команду dbcc, следует восстановить прежнюю конфигурацию буферов сервера, поскольку использование большей части общего буфера в качестве области с буферными блоками по 16 Кбайт далеко не всегда является оптимальным решением при нормальной работе сервера. Здесь очень удобным оказывается применение различных конфигурационных файлов — одного для нормальной

www.books-shop.com

эксплуатации сервера, а другого для выполнения dbcc"проверок. При таком подходе переключение сервера с одной конфигурации на другую выполняется простым перезапуском сервера с указанием необходимого конфигурационного файла. Рано или поздно вы осознаете серьезность риска, возникающего при контроле лишь отдельных баз данных сервера. Не забывайте о стоимости дополнительного времени простоя сервера, необхо" димого для восстановления целостности данных. А объяснения руководству, почему вы не выполня" ли требуемые dbcc"проверки в полном объеме, могут привести к негативным результатам в вашей карьере. Есть два способа, позволяющих обеспечить регулярное проведение dbcc"проверок баз дан" ных даже очень загруженного сервера. Первый способ уже упоминался: стремитесь сокращать объем каждой базы данных, вынося ста" рые данные в специальные архивные базы данных (подробнее см. главу 10). Второй — заключается в переносе всего процесса dbcc"проверок на отдельный сервер, работающий на выделенной сервер" ной машине. Подобный подход позволяет выполнять dbcc"проверки и любые другие служебные опе" рации, не затрагивая основной сервер информационной системы. При создании вторичного DBCC"сервера на нем необходимо воссоздать все основные базы данных главного сервера и затем < загрузить свежие дампы этих баз данных (см. рис. 9.10). После этого следует последовательно запус" тить полный набор dbcc"проверок каждой базы данных. По завершении проверок нужно проанали" зировать выданные сообщения об ошибках, после чего определить, как внести требуемые исправления в основные рабочие копии баз данных на главном сервере (напомним, что команда dbcc обрабатывала лишь копии этих баз данных на вспомогательном сервере). После выполнения dbcc"проверок копий баз данных вы получаете полный список поврежденных таблиц. Это значите" льно сокращает период простоя основного сервера и время, необходимое для восстановления глав" ных копий баз данных.

Рис. 9.10. Перенос баз данных основного сервера на выделенный сервер для dbcc+проверок

Не забудьте проверить также базы данных master и model основного сервера (и базы данных sybsys temprocs и sybsecurity для SQL Server System 10). Разумеется, загрузка в DBCC"сервер дампа базы дан" ных master основного сервера вряд ли окажется успешной, поскольку конфигурации этих серверов редко бывают идентичны по финансовым соображениям. Таким образом, даже при наличии специа" льного DBCC"сервера выполнять проверки баз данных master и model придется на основном сервере. В этом случае можно попытаться запустить команду dbcc без перевода основного сервера в однопо" льзовательский режим и посмотреть, обнаружатся ли при этом ошибки в базах данных master к model. В такой ситуации отсутствие ошибок будет означать успешное завершение проверки, а их наличие укажет на необходимость повторной проверки после перезапуска основного сервера в однопользо" вательском режиме. К счастью, размеры баз данных master и model редко бывают значительными, и период недоступности сервера во время проверки этих баз данных окажется очень непродолжитель" ным. Несмотря на все хлопоты, периодическая проверка непротиворечивости баз данных master и model является обязательным условием обеспечения работоспособности сервера, поскольку любые ошибки в базе данных master должны быть обнаружены как можно скорее. Использование выделенного DBCC"сервера в некоторых случаях замедляет процесс обнаружения ошибок в базах данных основного сервера. Предположим, что полный набор dbcc"проверок базы данных dbl размером в 8 Гбайт занимает 30 часов работы вспомогательного сервера, а на загрузку дампа этой базы данных уходит еще 7 часов. В результате ошибки могут оставаться необнаруженны" ми в течение целых 37 часов. За это время на основной машине вполне мог быть сохранен новый дамп, содержащий некорректную информацию. Складывается ситуация, когда последние полные дампы базы данных содержат ошибки. Значит, нужно загрузить последний правильный дамп, после чего применить к нему все последующие дампы журнала транзакций. Здесь необходимо отметить,

www.books-shop.com

что сохранение дампа базы данных не прерывает последовательность дампов журнала транзакций, и загружаемый набор этих дампов вполне может охватывать несколько периодов сохранения полного дампа базы данных. Однако, в зависимости от конкретного состава ошибок, обнаруженных коман" дой dbcc, дампы журнала транзакций также могут содержать некорректную информацию. В сочета" нии с ошибками при загрузке одного из этих дампов это сделает невозможным полное восстановление базы данных на текущий момент времени. Разумеется, если есть резервный сервер с той же самой базой данных, следует проконтролировать достоверность резервной копии. В случае положительного результата ее можно использовать для восстановления базы данных на основном сервере или попытаться осуществить подобную операцию по отношению к отдельным пострадав" шим объектам базы данных (на что потребуется значительно меньше времени, чем на восстановле" ние всей базы данных). Поскольку любые различия структуры, размеров и порядка следования областей дисковой памя" ти, распределенных базе данных на основном и вспомогательном сервере, вызовут при выполнении команды dbcc сообщения об ошибках, конфигурация сегментов баз данных на основном и DBCC"серверах должна быть идентичной. Необходимо обеспечить точное соответствие необходи" мых компонентов таблицы sysusages между основным и вспомогательным сервером (подробно см. главу 12). Кроме того, как и при сопровождении резервного или вспомогательного сервера поддер" жки принятия решений, любое изменение конфигурации базы данных основного сервера должно немедленно воспроизводиться на DBCC"сервере. Хотя DBCC"сервер и основной сервер редко обла" дают одинаковым количеством дисков и дисковых контроллеров, следует добиться эквивалентной конфигурации сегментов базы данных. Это потребует наличия равного числа серверных устройств, размеры которых не будут уступать размерам устройств основного сервера, поддерживающих сег" менты проверяемой базы данных. Более того, устройства вспомогательного сервера лучше разме" щать на равном количестве дисков, имеющих одинаковую с основным сервером структуру разделов. Это значительно упростит распространение сегментов на новые устройства (см. рис. 9.11) и конт" роль за заполнением серверных устройств, задействованных ранее. Если на DBCC"сервере имеется необходимое количество серверных устройств с размерами, иден" тичными размерам устройств основного сервера, можно запустить на основном сервере уже упоми" навшийся командный файл p_dbcreate (см. главу 14). Он выдаст набор команд, позволяющих воссоздать на DBCC"сервере все базы данных основного сервера. Разумеется, выдача p_dbcreate будет содержать названия серверных устройств основного сервера, и перед выполнением сгенери" рованных команд на DBCC"сервере в эти названия потребуется внести необходимые изменения.

диск cOt0dO + диск 1 файловой системы диск cOtOd1 + серверный диск 1 диск cOtOd2 + серверный диск 2 диск cOt0d3 + зеркальная копия c1tOd5 диск c1tOd4 + диск 2 файловой системы диск c1tOd5 + серверный диск 3 диск c1tOd6 + зеркальная копия cOtOd1 диск c1tOd7 + зеркальная копия cOtOd2

Основной и DBCC+сервер должны иметь идентичную конфигурацию дискового пространства с одинаковой структурой разделов дисков. Диски должны быть одинаково распределены по серверным устройствам. В противном случае перед использованием на DBCC+сервере команд и командных файлов управления базами данных основного сервера в них потребуется изменить названия некоторых дисков. Рис. 9.11. Конфигурация дисков основного и DBCC*серверов

www.books-shop.com

Добавляя новые базы данных на основной сервер, одновременно добавьте их и на DBCC"сервер. Не забудьте включить эти базы данных в хранимые процедуры и командные файлы, используемые для переноса дампов с основного сервера и выполнения dbcc"проверок на вспомогательном сервере. Как и при сопровождении резервного сервера (или сервера генерации отчетов), наличие доста" точного дискового пространства на основном и DBCC"серверах позволит автоматизировать процесс переноса дампов, т.к. исключается использование магнитной ленты. Своевременная архивация уста" ревающих данных сократит размеры проверяемых оперативных баз данных и время, через которое можно узнать о наличии в них ошибок. Некоторые незаметные, но коварные нарушения в структурах данных можно обнаружить только с помощью dbcc+проверок. Вот один пример. Ваш основной сервер работает превосходно, но вы все же решаете загрузить свежий дамп базы данных на DBCC+сер+ вер и проконтролировать его достоверность командой dbcc. Внезапно команда выдает серию ошибок с номером 605 (ошибка 605 означает, что содержание страниц данных на диске и в кэш+буфере неодинаково; подробности см. в руководстве по устранению непо+ ладок в SQL Server). Вы начинаете паниковать, поскольку полный комплект dbcc+прове+ рок последний раз выполнялся очень давно — эта операция занимает 30 часов, и мало кто из ваших коллег осознает всю ее важность. Естественно, вы пытаетесь понять, когда именно произошло нарушение структуры данных, и остались ли в вашем распоряжении правильные дампы базы данных. Вы принимаете решение закрыть доступ пользователей к основному серверу и проверяете командой dbcc объект данных, вызывавший ошибки 605 на вспомогательном сервере. Команда dbcc выдает пару сообщений о второстепен+ ных погрешностях и ни одной ошибки 605. Все вздыхают с облегчением. Однако пользо+ ватели надолго запоминают, как они потеряли кучу времени из+за несуществующей проблемы с сервером. Так что же произошло на самом деле? Причиной ошибок была одна из страниц основного сервера, целиком заполненная дан+ ными. Она оказалась неправильно связана с другими страницами того же объекта базы данных. Особенность команды dump database состоит в том, что она сохраняет в дам+ пах только корректно связанные страницы данных, не выдавая при этом никакой диагно+ стики. Это привело к отсутствию указанной страницы во всех дампах базы данных. Поэтому вплоть до загрузки одного из дампов в DBCC+сервер вы не могли заподозрить существование каких+либо проблем. Естественно, запущенная на вспомогательном сер+ вере команда dbcc не смогла найти пропущенную страницу (которая тем не менее оста+ валась в составе главной рабочей копии базы данных на основном сервере) и выдала ошибки 605. При запуске dbcc на основном сервере были обнаружены только минималь+ ные погрешности. Таким образом, успешное сохранение дампов баз данных и журналов транзакций вовсе не гарантирует, что с их помощью впоследствии удастся восстановить корректное состо+ яние базы данных. При регулярном выполнении dbcc+проверок ситуация находится под вашим контролем, и вы всегда знаете, сколько времени потребуется для возврата к по+ следнему корректному дампу базы данных. В рассмотренной выше ситуации было очень важно своевременно обнаружить появление ошибки 605 на вспомогательном сервере. Тогда вы могли бы немедленно сообщить пользователям о возникновении проблем и возможных масштабах потерь, после чего остановили бы основной сервер для проверки подозрительного объекта данных (предварительно проинформировав пользователей о временном простое сервера). Обнаружив, что повреждения основной базы данных мини+ мальны, вы с помощью команды dbcc восстановили бы правильную структуру связей между страницами базы данных. Как видите, при правильном подходе вам не потребова+ лось бы осуществлять внезапный останов сервера, крайне нежелательный в любой ситу+ ации. Старайтесь никогда не поддаваться панике — это непродуктивно. Еще раз напомним о преимуществах сокращения размеров оперативных баз данных путем свое" временной архивации устаревшей информации. Это ускоряет выполнение dbcc"проверок, позволяет производить их чаще и быстрее обнаруживать нарушения в структурах данных. Своевременное об" наружение проблем снижает объем потерь данных в случае восстановления базы данных из послед" него корректного дампа. Сравните затраты на архивацию данных и частое выполнение dbcc"проверок со стоимостью потерь, которые понесет ваша компания в случает утраты данных. По" следнее почти всегда оборачивается весьма значительными суммами. Если даже такие аргументы не подействуют на ваше руководство, проследите за тем, чтобы пользователи системы знали о сущест" вовании потенциальной опасности и были готовы разделить с вами риск.

www.books-shop.com

Постарайтесь заключить с пользователями соглашение о порядке обслуживания сервера, в котором перечисляются опасные ситуации, в которых могут оказаться пользователи. Включите в это соглашение порядок действий при появлении проблем — например, дол+ жен ли администратор сервера немедленно сохранять дамп базы данных при переполне+ нии журнала транзакций в разгар рабочего дня? Соглашение также должно включать в себя график dbcc+проверок и объем вмешательств, разрешенный администратору сер+ вера для исправления обнаруженных ошибок. Соглашение о разделении риска обязательно должно заключаться в письменном виде. Оно дол" жно содержать указание максимального времени простоя сервера и максимального объема потерь данных, возникающих из"за пренебрежительного отношения пользователей к архивации данных и проведению dbcc"проверок. Храните одну из копий соглашения в надежном месте вне вашего офи" са. Можете попробовать напечатать основные выдержки из соглашения на футболке и надевать ее на каждую очередную встречу с пользователями и руководством. Чтобы не сходить с ума в предчув" ствии неизбежных неприятностей, нужно заранее подготовиться к их возникновению. Целый ряд программных продуктов третьих фирм поможет облегчить и ускорить выполнение dbcc"проверок. Например, предлагаемая компанией Platinum Technologies программа"анализатор об" разов баз данных Image Analyzer позволяет проверить непротиворечивость дампов баз данных без их загрузки в SQL Server. В результате после сохранения обычного дампа базы данных вы можете немедленно открыть сервер для пользователей, одновременно начав проверку свежего дампа про" граммой Image Analyzer. Поскольку программа Image Analyzer может выполняться на любом доступ" ном компьютере и полностью независима от SQL Server (наличие которого вообще не требуется для ее запуска), согласованность дампов баз данных может анализироваться на отдельной UNIX"машине без снижения производительности основного сервера. Главное преимущество Image Analyzer в том, что теоретически эта программа позволяет полно" стью исключить простои сервера, вызванные необходимостью выполнения dbcc"проверок. Запуск команды dbcc на основном сервере потребуется, если будут обнаружены ошибки в одном из дампов базы данных. Тогда объект данных, указанный программой Image Analyzer, будет скорректирован. При этом потребуется намного меньше времени, чем для полной проверки всей базы данных. Однако Image Analyzer сообщает описание найденных ошибок, не выдавая номеров соответству" ющих ошибок SQL Server. В рассмотренном выше примере мы получили бы сообщение о наруше" нии структуры связей между страницами одной из таблиц. Для более подробного анализа проблемы нам все равно потребовалось бы выполнить dbcc"проверки этой таблицы и на основании номеров ошибок, выданных сервером Sybase, найти выход из возникшей ситуации. Кроме того, Image Analy" zer производит не все проверки, которые SQL Server>> осуществляет при выполнении команды dbcc. Image Analyzer вообще не проверяет индексы таблиц. Поэтому при использовании программы Image Analyzer нарушение в структуре индекса может оставаться какое"то время незамеченным — вплоть до момента, когда оно проявится в работе основного сервера. Таким образом, применение Image Analy" zer не исключает периодического проведения полного набора dbcc"проверок, предусмотренных в SQL Server. Однако эта программа позволяет ограничиться одной проверкой в неделю (или даже в месяц) основного сервера и отказаться от второго сервера, предназначенного специально для dbcc"проверок создаваемых дампов. В целом проверка корректности создаваемых дампов — важная операция. Она не поддерживается самим сервером Sybase. По завершении обычного процесса сохранения дампа вы не знаете, коррек" тен ли только что полученный дамп. Это выяснится только в процессе его загрузки в SQL Server. Даже если обычный набор dbcc"проверок убеждает вас в полной непротиворечивости базы данных, это еще не гарантирует достоверности дампа этой базы данных. SQL Server не способен проконтро" лировать работу устройства записи на ленту или качество самой магнитной ленты. Поэтому сбои при записи на ленту обнаружатся только во время чтения дампа сервером. Программа Image Analy" zer позволяет администратору сервера убедиться, что имеющийся в его распоряжении дамп действи" тельно пригоден для использования. Единственный способ выполнить подобную проверку с помощью SQL Server — это попробовать загрузить дамп базы данных обратно в сервер. Image Analyzer также позволяет проверить ленточные дампы без их загрузки на диск. Это имеет особое значение для дампов размером более 2"х Гбайт, которые не помещаются в раздел файловой структуры системы UNIX. Помимо контроля достоверности структуры данных, программа Image Analyzer дает возможность еще раз убедиться, читается ли лента с дампом. Программа Image Analyzer особенно полезна для больших баз данных. Серверы информацион" ных систем многих компаний трудно остановить даже на время сохранения дампов баз данных, и

www.books-shop.com

говорить о регулярном выполнении полных dbcc"проверок не приходится. Программа Image Analy" zer позволит сократить время простоя сервера до минимума, что особенно важно для крупных баз данных, на проверку которых стандартной командой dbcc серверу требуются долгие часы работы. Зеркальное резервирование данных РОЛЬ и значение зеркального резервирования серверных устройств не раз обсуждались в предыдущих главах книги. Здесь мы еще раз подчеркнем важнейшие принципы организации зеркальных копий. Идеально было бы обеспечить полное резервирование всех устройств сервера, прежде всего потому, что это гарантирует существование зеркальной копии базы данных после ее распространения на но" вое серверное устройство. Детально рассмотрев процесс взаимодействия базы данных и ее журнала транзакций, мы устано" вили последовательность приоритетов. Если нет возможности организовать полное резервирование серверных устройств, следует придерживаться этой последовательности. В первую очередь зеркаль" ная копия должна быть создана у серверного устройства master, поскольку сбои на нем приводят к останову всего сервера. Кроме того, восстановление любой пользовательской базы данных стано" вится невозможным при недоступности базы данных master, находящейся именно на серверном устройстве master. Помимо этого устройства, в SQL Server System 10 и 11 также следует обеспечить резервирование серверных устройств, содержащих базы данных sybsystemprocs и sybsecurity. Затем зеркальные копии должны появиться у серверного устройства (или устройств), поддержи" вающих журнал транзакций наиболее важной базы данных сервера. Как уже подчеркивалось, без журнала транзакций базу данных нельзя считать непротиворечивой. Если пользовательских баз дан" ных несколько, зеркальные копии их журналов транзакций создаются в порядке убывания важности соответствующих баз данных. Еще раз отметим, что лучше всего зарезервировать все серверные устройства. Теперь создадим копии серверных устройств, поддерживающих остальные сегменты самой важ" ной пользовательской базы данных сервера. Главная цель здесь — сократить время возможного про" стоя сервера при сбое одного из таких устройств. Конечно, зарезервировав журнал транзакций, можно рассчитывать на возможность полного восстановления базы данных, но этот процесс займет много времени. При наличии нескольких пользовательских баз данных их серверные устройства ре" зервируются в той же самой очередности, как и журналы транзакций. Наверное, многие считают, что базу данных tempdb вообще не следует включать в схему резерви" рования. Такая точка зрения ошибочна. Действительно, нет смысла резервировать эту базу данных с целью восстановления после сбоев, поскольку даже сам сервер не пытается воссоздать ее содержи" мое. Однако ее недоступность означает недоступность сервера, поскольку подавляющее большинст" во приложений так или иначе используют tempdb в своей работе. Поэтому и эта база заслуживает создания зеркальной копии. Даже если невозможно обеспечить полное резервирование всех серверных устройств, админист" ратору сервера следует быть готовым в любой момент создать зеркальные копии всех разделов каж" дого физического диска сервера. Именно здесь особенно полезной окажется универсальная стандартная схема разбиения дисков на разделы. Она позволяет отобразить любой раздел любого серверного диска на эквивалентный раздел другого диска (см. главу 8). В большинстве случаев сбой диска оказывается локализованным на одном из его разделов, и теряется только одно серверное устройство. При наличии достаточного количества свободных устройств можно отобразить на них все сохранившиеся серверные устройства отказавшего диска, после чего заменить сам диск. Здесь весь процесс удаления, воссоздания, загрузки дампов и применения дампов журнала транзакций нужно провести только в базах данных утраченного устройства. Базы данных всех остальных устройств отказавшего диска окажутся перемещенными на новые разделы, и их можно вернуть на прежнее место замененного диска с помощью того же приема. Итак, зеркальное резервирование значительно сокращает время простоя сервера, поскольку по" зволяет заменять отказавшее устройство в наиболее подходящий момент. Однако администратору сервера необходимо постоянно проверять работоспособность зеркальных копий. Ситуация, когда одно из зеркальных устройств перестает функционировать, а вы не знаете об этом, намного хуже полного отсутствия такого устройства — ведь вы основываетесь на существовании зеркальной ко" пии. Периодически проверяйте состояние зеркальных устройств с помощью командного файла p_mirror (см, главу 14).

www.books-shop.com

Архивация данных Процедура архивации данных (т.е. удаление старой информации из оперативных баз данных и ее пе" ренос в архивные базы данных) подробно обсуждается в следующей главе как одно из средств на" стройки и повышения производительности сервера. Сейчас рассмотрим роль этого процесса в обеспечении возможности восстановления сервера. Цель архивации — уменьшение размеров опера" тивных баз данных, находящихся на основном сервере компании. Это ускоряет их восстановление, создание и загрузку дампов, а также выполнение dbcc"проверок. Таким образом, архивация позволяет быстрее установить факт неисправности базы данных и восстановить ее из свежего дампа. Для обеспечения архивации администратор базы данных создает необходимые архивные базы данных и затем регулярно передает в них наиболее старую информацию из оперативных баз данных (см. рис. 9.12). После каждого цикла архивации вы получаете очередную заполненную базу данных, которую можно перенести на вспомогательный сервер поддержки принятия решений или DBCC"сервер, а затем выполнить полный набор dbcc"проверок. Исправив все обнаруженные по" грешности, вы создаете полный корректный дамп архивной базы данных. Он позволяет восстано" вить все данные, заархивированные в течение указанного цикла. В результате, выполняя dbcc"проверки на основном сервере, вы проверяете только свежие данные. На это требуется значи" тельно меньше времени, поскольку команде dbcc не нужно заново проверять одни и те же старые данные.

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

Рис. 9.12. Размещение архивных баз данных на основном и вспомогательном сервере Чем больше серверных устройств, тем лучше Довольно часто у администратора сервера возникает необходимость определить, какое число разде" лов (и, соответственно, серверных устройств) следует создать на одном дисковом накопителе. Далее перечислены три причины существования на каждом диске как можно большего количества разделов (одна из них имеет непосредственное отношение к восстановлению после сбоев). А. Сбои диска обычно затрагивают лишь один его раздел. Чем он крупнее, тем больший объ" ем данных будет теряться при каждом отдельном сбое. Если на дисковом накопителе есть шесть разделов, то повреждение одного блока диска приведет к утрате только одного раз" дела из шести. Однако, если весь этот диск представляет собой единое серверное устрой" ство, то все находящиеся на нем базы данных будут утрачены.

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

В. Увеличение числа серверных устройств позволяет точнее определить, какие компоненты базы данных наиболее часто используются сервером. Это решение проблем, связанных с производительностью сервера. С. SQL Server поддерживает в оперативной памяти отдельную очередь запросов к каждому серверному устройству. Уменьшение количества серверных устройств означает, что в каж" дой из оставшихся очередей будет находиться больше запросов. Таким образом, большее число устройств позволяет сократить потери времени на ожидание во внутренних очере" дях запросов сервера. Общие рекомендации по восстановлению сервера В данном разделе мы рассмотрим ряд рекомендаций, существенных при планировании процесса вос" становления после сбоев. При сохранении в файл содержимого системной таблицы syslogins команду bср необходимо вы" зывать с параметром "с. Это позволит прочитать полученный список пользователей и внести в него необходимые изменения (например, удалить пользователей 'sa' и 'probe'). Существование пользова" теля с именем probe указывает на использование на сервере двухфазной схемы фиксации транзак" ций. При загрузке файла с дампом таблицы syslogins в базу данных master другого сервера в файле не должны находиться записи пользователей с именами, уже имеющимися в таблице syslogins второго сервера. Попытка создания в таблице syslogins дублирующих записей приведет к аварийному завер" шению команды bср. Перед загрузкой следует просмотреть содержимое таблицы syslogins второго сервера, чтобы узнать, какие пользователи там уже находятся (вы наверняка встретите пользователя 'sа'; однако, пользователя 'probe' там может и не оказаться). Затем удалите из загружаемого файла все строки с дублирующими именами. Никогда не пытайтесь полностью удалить таблицу syslogins вто" рого сервера — отсутствие учетной информации пользователя 'sa' не позволит загрузить новые запи" си командой bср или выполнить какие"либо другие команды. При восстановлении сервера после сбоя необходимо иметь свежие дампы различных системных таблиц. Эти дампы крайне важно создать заранее, до момента отказа сервера. В главе 14 указан командный файл, который можно использовать в качестве периодически запускаемого операцион" ной системой cron"задания, сохраняющего текущие копии системных таблиц. Рекомендуем также убедиться в нормальной работе стандартных средств архивации операционной системы. Они позво" ляют сразу после создания копий системных таблиц cron"процессом сбросить эти файлы на ленту. Командный файл RUN_<название_сервера>, создаваемый программой sybinit при установке сервера, позволяет узнать физический адрес серверного устройства master при отсутствии зеркаль" ной копии последнего. Второй источник, дающий этот адрес — журнал регистрации ошибок серве" ра. Поэтому текущая копия файла RUN_<название_сервера> должна быть обязательно сохранена стандартными средствами архивации файловой системы. К восстановлению сервера следует готовиться заранее. После завершения работы программы установки sybinit сохраните дамп базы данных master, предварительно проверив ее командой dbcc. Пока устанавливается или обновляется сервер, проверьте несколько раз командой dbcc базу данных master. Восстанавливая базу данных перед, загрузкой ее дампа обязательно воссоздайте прежнюю струк" туру сегментов этой базы данных. Это гарантирует, что загружаемые объекты данных будут помеще" ны в правильные сегменты. В главе 12 обсуждается системная таблица sysusages и использующая ее хранимая процедура p_dbcreate, позволяющая сгенерировать команды воссоздания структуры базы данных. Поскольку конфигурация SQL Server System 11 определяется конфигурационными файлами, обя" зательно убедитесь в наличии их резервных копий. Они могут потребоваться в процессе восстанов" ления сервера. Если при работе с сервером вы постоянно используете только один конфигурационный файл, нужна только его копия. Конфигурационный файл обычно содержится в каталоге, задаваемом значением переменной среды SYBASE и называется <название_серве" pa>.cfg. Однако, используя несколько конфигурационных файлов (например, один для повседнев" ной эксплуатации, а другой — для выполнения dbcc"проверок) , необходимо сохранить копии всех этих файлов. Напомним, что SQL Server хранит в серверном устройстве master только свою текущую конфигурацию, и поэтому после восстановления этого устройства сервер окажется в конфигурации, действовавшей на момент сбоя. Все остальные конфигурационные файлы потребуется восстановить из файловых архивов, полученных стандартными средствами системы UNIX. Работая с версией SQL Server System 11, при восстановлении конфигурации сервера вы больше не можете полагаться на файл с выдачей команды sp_conf igure, которая в предыдущих версиях

www.books-shop.com

сервера (SQL Server 4.9.2 и System 10) содержала полное описание конфигурации сервера на момент ее выполнения. В System. 11 команда sp_configure не сообщает конфигурацию именованных кэш"буферов, поэтому одновременно с сохранением дампа системных таблиц сервера (при помощи командного файла, приведенного в главе 14) вам необходимо сохранить выдачу команд sp_help" cache, sp_cacheconfig и sp_poolconfig <название_буфера> для каждого именованного бу" фера, имеющегося на сервере. Обратите внимание на то, что в System 11 ни конфигурационный файл, ни выдача команды sp_configure не содержат полной информации о конфигурации сервера. Это повышает важность си" стемных таблиц сервера, которые хранят эту информацию. Хотя конфигурационный файл сообща" ет вам все названия и конфигурацию именованных кэш"буферов, из него невозможно узнать, какие объекты баз данных были назначены каждому из этих буферов. Эти сведения можно получить из таблицы sysattributes, имеющейся в каждой базе данных сервера. Восстановить ее можно только на основании выдачи команды sp_helpcache. Конечно, эта таблица будет восстановлена и в процессе загрузки полного дампа базы данных, но при этом она будет находится в состоянии на момент созда" ния дампа. Привести ее в состояние на момент сбоя удастся только в результате полного восстанов" ления базы данных. Помните, что если невозможно восстановит состояние базы данных момент сбоя, можно потерять часть информации о назначении объектов этой базы данных именованным кэш"буферам. Сервер архивации (Backup Server) Сервер архивации представляет собой отдельный системный процесс, работающий на серверной ма" шине. SQL Server использует сервер архивации при сохранении и загрузке любых дампов баз данных. Поскольку он является независимым открытым приложением, взаимодействующим с SQL Server no сети, конфигурация SQL Server должна поддерживать удаленный доступ к серверу при создании или сохранении дампов. Кроме того, сервер архивации имеет независимый журнал регистрации ошибок и запускается отдельным командным файлом. Как и SQL Server, сервер архивации устанавливается программой sybinit. Она также конфигурирует SQL Server для поддержки удаленного доступа. Таким образом, для создания или загрузки дампов с помощью SQL Server в системе должен рабо" тать процесс сервера архивации. Перезапуск SQL Server не требует одновременного перезапуска сервера архивации. После каждого перезапуска одного из двух серверов необходимо убедиться в том, что они нормально взаимодействуют друг с другом. Для этого выполните в SQL Server команду SYB_BACKUP...sp_who Успешное завершение этой команды свидетельствует о нормальной работе сервера архивации. В случае, если эта команда не завершается, необходимо уничтожить системный процесс сервера архи" вации (если он существует) и запустить этот сервер заново. После этого проверьте, установилось ли взаимодействие сервера архивации с SQL Server. Команду запуска сервера архивации рекомендуется включить в состав командного файла RUN_<название_сервера>, используемого для запуска SQL Server. Это требуется для того чтобы при каждом перезапуске SQL Server проверял наличие процес" са сервера архивации и при необходимости автоматически запускал его. Сервер архивации также должен работать во время выполнения любых командных файлов или cron"задач, сохраняющих или загружающих дампы. В рамках SQL Server сервер архивации всегда имеет название SYB_BACKUP. Попытка вручную обратиться к системной таблице sysservers и установить для сервера архивации значение поля srvna те, отличающееся от SYB_BACKUP, приведет к невозможности сохранения дампов или их загрузки в SQL Server. При установке сервера архивации программа sybinit запрашивает сетевое имя серве" ра архивации. По умолчанию в качестве этого имени sybinit также использует SYB_BACKUP (сете" вое имя содержится в поле srvnetname той же таблицы sysservers). Такой выбор нельзя назвать оптимальным. Ведь если в вашей системе базы данных есть второй SQL Server, оба сервера будут вы" зывать сервер архивации по сетевому имени SYB_BACKUP. Какой именно сервер архивации отве" тит на этот запрос, будет неясно. Поэтому каждый сервер архивации должен иметь уникальное сетевое имя (более подробно таблица sysservers рассматривается в главе 12). Как и SQL Server версии 4.9.2, сервер архивации позволяет записать дамп на логическое сервер" ное устройство вывода дампов (наличие которого на сервере 4.9.2 обязательно). Сервер архивации способен также сбрасывать дамп на определенный диск или устройство записи магнитной ленты без предварительного определения этого устройства в качестве логического устройства вывода дампов SQL Server. Это очень важное преимущество для администратора сервера, поскольку не требуется определять любой подключенный к серверной машине накопитель на магнитной ленте в качестве

www.books-shop.com

отдельного устройства вывода дампов. Более того, при сохранении дампов в виде дисковых файлов можно указывать названия этих файлов. При работе с сервером 4.9.2 дамп приходилось сначала за" писывать на дисковое устройство вывода дампов сервера, а затем копировать в требуемый файл, чтобы исключить его случайную перезапись при сохранении следующего дампа. Сервер архивации может быть установлен на удаленной серверной машине и обслуживать SQL Server, работающий на другой серверной машине. Подобная конфигурация значительно замедляет процесс сохранения дампов. Работоспособность такой системы необходимо постоянно проверять. Однако поддержка подобного режима окажется ценной при восстановлении серверной машины по" сле катастрофических сбоев. Сервер архивации также позволяет одновременно записывать сохраняемый дамп на несколько накопителей (такой процесс называется striping). Например, параллельное сохранение дампа базы данных на четырех дисковых накопителях можно завершить примерно за одну четверть времени, необходимого для записи этого же дампа на один диск. Отметим, что параллельное сохранение дам" па на несколько устройств поддерживается сервером архивации и при записи дампа на магнитную ленту. В качестве примера мы можем привести 5"гигабайтную базу данных. Запись ее дампа на одну ленту занимала 2,5 часа, а параллельное сохранение дампа на пяти дисковых накопителях удавалось завершить за 20 минут. Помимо этого, север архивации обеспечивает и запись нескольких дампов на одну магнитную ленту, присваивая каждому из них индивидуальное имя ленточного файла или используя имя, ука" занное в команде dump database. Отметим, что при отсутствии в команде dump database имени ленточного файла сервер архивации сгенерирует его самостоятельно. Однако оно будет нечитабель" ным. Для поддержки ленточных файлов в команде load database появился параметр with lis" tonly, выдающий все имена дампов, имеющихся на ленте. При загрузке ленточного дампа администратор сервера должен обязательно указать имя нужного ленточного файла, если на ленте имеется хотя бы два дампа. Обратите внимание на то, что использование прежних командных фай" лов, сбрасывающих дампы непосредственно на ленту, при многократной записи на одну ленту при" ведет к появлению на ней нескольких последовательных дампов. Все старые командные файлы, сохраняющие или загружающие дампы, должны быть изменены с учетом нового формата команд dump database и dump transaction. При записи дампов на ленту в соответствующей команде должна быть указана емкость ленты (параметр capacity). Первый дамп на ленте следует создавать с параметром with init, производящим инициализацию тома маг" нитной ленты. Сервер архивации не требует консольного процесса. Поэтому в файле интерфейсов не надо ука" зывать номер консольного порта. При работе с SQL Server версии 4.9.2 контроль за выполнением команд dump database или dump transaction осуществлялся путем периодического просмотра выдачи процедуры sp_who и проверки значения счетчиков операций ввода"вывода для соответствующего серверного процесса. Этот прием не подходит при использовании сервера архивации. Единственный способ убедиться в выполнении записи или загрузки дампа — это узнать, имеется ли на серверной машине, содержащей сервер архивации, системный процесс с названием sybmultbuf . Указанный процесс существует то" лько во время создания или загрузки дампов. Дампы баз данных Основой любой схемы защиты данных от сбоев являются дампы баз данных и журналов транзакций. Процесс их создания рассматривается в этом и следующем разделе главы (некоторые аспекты, обсуж" даемые в текущем разделе, имеют отношение и к дампам журналов транзакций). Необходимо отме" тить, что во время сохранения дампов баз данных SQL Server не требуется переводить в автономное состояние. Однако процесс создания дампа заметно отражается на производительности сервера, и администратору сервера необходимо убедиться в достаточной производительности основных прило" жений в период сохранения дампов. В большинстве случаев видно, что сохранение дампов фактиче" ски исключает нормальную работу пользователей с приложениями, и этот период следует включить в общее время недоступности сервера. Здесь уместно еще раз вспомнить о необходимости сокращения размеров оперативных баз данных посредством их архивации. Перед началом сохранения дампа базы данных или журнала транзакций необходимо определить, будет ли этот дамп сохраняться в виде дискового или ленточного файла. Во втором случае следует также решить, намерены ли вы записывать на одну ленту сразу несколько дампов. Здесь следует иметь в виду, что SQL Server 4.9.2 не поддерживает запись нескольких дампов на одну ленту. Эта воз" можность появилась только в сервере архивации, включенном в состав SQL Server System 10.

www.books-shop.com

Глава 14 содержит пример командного файла, записывающего несколько дампов на один том маг" нитной ленты. Журналы транзакций должны создаваться через небольшие промежутки времени. Это даст возможность обеспечить восстановление сервера в состоянии, как можно более близком к моменту сбоя. Естественно, их приходится создавать прямо во время работы пользователей с серве" ром. Чтобы ускорить этот процесс и не снизить производительность сервера, дампы журналов тран" закций рекомендуется записывать в дисковые файлы. Полные же дампы баз данных могут записываться на диск или ленту в зависимости от выбора администратора сервера. Наличие на сер" вере достаточного дискового пространства позволяет ограничиться сохранением дампов баз данных на диск, что заметно ускоряет выполнение команды dump database. Есть одно ограничение. Оно касается распространенных 32"битных версий UNIX, поддерживаю" щих разделы файловых систем, не превышающих 2 Гбайт. По мере распространения 64"битных вер" сий UNIX указанное ограничение должно постепенно утратить актуальность. Дамп базы данных, записанный на ленту, можно считать надежно сохраненным на большой про" межуток времени. Однако дисковые файлы дампов продолжают оставаться на дисках серверной ма" шины и могут оказаться утраченными при сбое одного из дисков файловой системы. Перед сохранением дампов на диск убедитесь, что выбранные вами разделы файловой системы включены в схему сохранения резервных копий файлов стандартными средствами архивации UNIX. Лучше всего, если запись копии файловой системы на ленту будет производиться вскоре после сохранения дампа базы данных. Это позволит сократить промежуток времени, в течение которого дамп базы данных находится исключительно на диске серверной машины. Самым простым подходом здесь ока" жется регулярное копирование на ленту всей файловой системы серверной машины. Оно обеспечи" вает сохранение резервных копий файлов с дампами, где бы эти файлы не находились. Обратите внимание на то, что восстановление дампа, находящегося на ленте в составе дампа файловой системы, представляет собой двухступенчатый процесс. Сначала файл дампа необходимо восстановить на диск из дампа файловой системы, а затем его можно будет загрузить в сервер для восстановления исходной базы данных. Разумеется, подобная процедура займет больше времени, чем прямое восстановление дампа, сразу сохраненного на магнитную ленту. При создании дампов следует предусмотреть способ проверки их корректности. Наиболее надеж" ным методом контроля дампов является их загрузка в другой сервер с последующей загрузкой неско" льких дампов журналов транзакций. Если в вашей системе имеется отдельный сервер поддержки принятия решений (см. главу 10) либо DBCC"сервер (см. выше), вам в любом случае необходимо по" стоянно загружать дампы основного сервера. Это нужно для синхронизации вспомогательного сер" вера с основным, что означает автоматическую проверку корректности всех создаваемых дампов. Как уже указывалось, сохранность текущего журнала транзакций имеет особое значение при вос" становлении базы данных. Однако этим журналом вообще не удастся воспользоваться, если хотя бы один из его предыдущих дампов (и тем более полный дамп базы данных) отсутствует либо содержит некорректную информацию. Здесь мы возвращаемся к необходимости частого выполнения dbcc"проверок и оперативного исправления обнаруженных нарушений в структурах данных. Еще раз подчеркнем, что при отсутствии корректного дампа базы данных и полного набора последую" щих корректных дампов журнала транзакций восстановление базы данных в состоянии на момент сбоя становится невозможным (см. главу 8). Регулярное сохранение дампов всех баз данных сервера означает и регулярное создание дампа базы данных master. Поскольку журнал транзакций этой базы данных не может находиться на отдель" ном серверном устройстве, создание его отдельного дампа невозможно. При сохранении дампа этот журнал транзакций не очищается (это происходит с журналами транзакций всех остальных баз дан" ных). Для очистки журнала транзакций базы данных master следует сразу после сохранения дампа базы данных master ввести команду dump transaction master with truncate_only (подробно см. главу 7). He следует пренебрегать и созданием дампов базы данных model Чтобы ее восстановить, ее следу" ет сначала воссоздать командой sybinit, которая сделает это одновременно с воссозданием базы дан" ных master, а затем загрузить дамп базы данных model Порядок действий в различных ситуациях, связанных с утратой базы данных model, описан в руководстве по устранению неполадок в SQL Server (SQL Server Troubleshooting Guide). При переполнении одного из сегментов базы данных сервер выдает сообщение об ошибке с но" мером 1105. В случае, если переполнение произошло в сегменте журнала транзакций (это можно проверить методами, описанными в главе 12), восстановление базы данных может быть затруднено. Выдача ошибки 1105 означает, в журнале транзакций больше нет места даже для регистрации

www.books-shop.com

момента выполнения команды dump transaction, что полностью исключает возможность норма" льного сохранения дампа журнала транзакций. Спасти положение может только выдача команды dump transaction <имя_базы_данных> with no_og Она выполняет очистку журнала транзакций без сохранения его дампа. Процесс восстановления базы данных будет завершен после последнего дампа журнала транзакций. Более того, в результате выполнения команды dump transaction with no_log факт нарушения цепочки дампов журнала транзакций становится известным серверу. Поэтому все последующие попытки сохранить дампы жур" нала транзакций будут им игнорироваться. Складывается непростая ситуация. Нужно решить, продол" жить работу сервера до момента создания ближайшего полного дампа базы данных (осознавая, что любой сбой базы данных приведет к утрате всех последних транзакций), либо немедленно остановить работу пользователей на время сохранения внеочередного полного дампа базы данных. В подобных случаях следует руководствоваться деловыми интересами компании, предварительно оговорив с поль" зователями условия распределения риска и определив последовательность действий. В серверах System 10 и System 11 возникновения ошибки 1105 можно избежать с помощью меха" низма порогов (см. главу 12). Установка порога заполнения журнала транзакций исключит его пере" полнение до уровня, требующего использования команды dump transaction with no_log. При достижении порога сервер (в зависимости от выбранного значения одного из параметров конфигу" рации) приостановит или прервет выполнение всех пользовательских транзакций. Это предотвра" тит переполнение журнала транзакций и даст администратору сервера время на его очистку или даже расширение его размеров. Как и большинство любых других неприятностей, переполнение журнала транзакций обычно происходит при максимальной нагрузке сервера в разгар рабочего дня, когда его простой и потеря данных обойдутся вашей компании дороже всего. В заключение рассмотрим ряд особенностей загрузки дампов базы данных. Поскольку основная цель этого процесса заключается в восстановлении базы данных, выполняя его, сервер должен про" верить корректность абсолютно всех страниц базы данных. Даже если дамп базы данных содержит только 10 Мбайт информации, загружая его в базу данных с общим размером в 100 Мбайт, сервер проинициализирует и проверит каждую страницу из тех 90 Мбайт, которые все равно останутся не" заполненными после загрузки дампа. Таким образом, время загрузки дампа базы данных определяет" ся не столько размерами дампа, сколько размерами самой базы данных. Наоборот, сохранение дампа базы данных выполняется тем быстрее, чем меньше информации содержится в ней. Дампы журналов транзакций Перед чтением этого раздела вспомните предыдущий раздел главы, посвященный дампам баз дан" ных. Там уже был рассмотрен ряд особенностей дампов журналов транзакций. Главная причина выделения журнала транзакций на отдельное серверное устройство — это необ" ходимость создания независимых дампов этого журнала без сохранения всего содержимого базы данных. Если журнал транзакции и база данных размещены вместе, единственным способом сохра" нения журнала транзакций будет создание полного дампа базы данных, а на это потребуется намно" го больше времени. Дампы больших баз данных часто не помещаются на имеющемся пространстве файловой системы, и их удается сохранить только на ленте. Существенную роль здесь играет огра" ничение, характерное для большинства современных версий UNIX. Предел одного раздела файло" вой системы устанавливается в размере 2"х Гбайт (сервер архивации System 10 и 11 способен записывать дамп в несколько дисковых файлов, что позволяет сохранять на дисках дампы баз дан" ных, превышающие 2 Гбайт). Дампы на ленте создаются медленнее, чем дампы в дисковых файлах. Это замедляет работу основной системы. Она становится фактически недоступной для пользовате" лей. В свою очередь, увеличение периода недоступности системы не позволяет сохранять дампы с достаточной частотой. Кроме того, при выводе полного дампа сервер не производит очистку журна" ла транзакций, а при создании отдельного дампа журнала транзакций записи о всех завершенных транзакциях удаляются из журнала. Полное восстановление базы данных невозможно без использования дампов журнала транзак" ций. Результат восстановления базы данных существенно зависит от того, удастся ли вам воспользо" ваться системной таблицей sysdatabases из базы данных master. Разумеется, в этой ситуации требуется, чтобы после сбоя сервер не утратил работоспособности. В противном случае придется ограничить" ся лишь ранее сохраненными дампами. Если доступ к базе данных master закрыт, восстановление сервера и его баз данных может осуще" ствляться исключительно на основе ранее созданных дампов. Загрузка полных дампов баз данных

www.books-shop.com

позволяет восстановить их состояние только на момент записи дампа; внесение в базы данных по" следующих изменений возможно лишь при наличии полного комплекта дампов журнала транзакций. Эти дампы должны охватывать период между сохранением полного дампа базы данных и сбоем сер" вера. Если таблица sysdatabases из базы данных master по"прежнему доступна серверу (обычно это озна" чает, что сбой произошел на одном из дисков баз данных, не содержащем базы данных master), есть возможность сохранить в дамп текущее содержимое журнала транзакций командой dump transac" tion с параметром no_truncate. Последующая загрузка этого дампа в восстановленную базу дан" ных позволит привести ее в состояние, точно соответствующее моменту сбоя. В любом случае журнал транзакций, дампы которого нужно было загрузить в сервер, должен находиться на отдель" ном серверном устройстве. Создание дампов журнала транзакций представляет собой наращиваемый процесс, когда в каж" дый очередной дамп журнала транзакций записывается копия этого журнала на момент создания дампа. После этого из журнала удаляются записи обо всех завершенных транзакциях. Таким обра" зом, в отличие от полных дампов базы данных, дампы журнала транзакции не содержат повторяю" щейся информации. Это позволяет значительно сократить время создания дампа журнала транзакций и уменьшить размер этого дампа, что, в свою очередь, делает возможным (и обязатель" ным) частое сохранение дампов журнала транзакций параллельно с работой пользователей сервера. Еще раз подчеркнем, что частое сохранение дампов журнала транзакций позволяет восстановить базу данных на более поздний момент времени, по сравнению со временем создания последнего полного дампа этой базы данных. Помимо вынесения журнала транзакций на отдельное серверное устройство, для создания его дампов требуется, чтобы в базе данных отсутствовали режимы select into/bulkcopy и trun" cate log on checkpoint. В режиме select into/bulkcopy сервер запрещает запись дампа журнала транзакций после выполнения любых операций, не фиксируемых в журнале транзакций. Эти операции нарушают непрерывность записей журнала транзакции (к их числу относится, напри" мер, быстрая загрузка данных командой Ьср). Режим truncate log on checkpoint приводит к очистке журнала транзакций при создании каждой контрольной точки, что также нарушает последо" вательность записей журнала транзакций. Сервер никогда не создаст дамп журнала транзакций при отсутствии в журнале полного набора записей обо всех изменениях, произведенных в базе данных после создания предыдущего дампа журнала транзакций. Как уже отмечалось, базу данных master невозможно распространить вне пределов одноименного серверного устройства. Поэтому ее сегменты system, default и logsegment обязательно нахо" дятся на серверном устройстве master и занимают все дисковое пространство, распределенное ей. Поэтому базу данных master можно восстановить только на момент создания последнего полного дампа, и внесение любых изменений в нее должно завершаться сохранением ее полного дампа (см. главу 7). Процесс восстановления баз данных можно заметно упростить, используя механизм порогов (thresholds). В обычной ситуации журналы транзакций наиболее важных баз данных сохраняются, например, каждые 15 минут. Это приводит к необходимости загрузки в процессе восстановления очень большого числа дампов журналов транзакций. Установка соответствующих порогов, и в осо" бенности порога последнего уровня (last"chance threshold), позволяет контролировать объем свобод" ного пространства в журнале транзакций и сохранять его дамп только при возникновении реальной необходимости (подробно, см. главу 12). Логические дампы и программа SQL ВаскТгаск компании DataTools В предыдущих разделах книги мы рассматривали дампы баз данных, журналов транзакций и файло" вых систем. Все подобные дампы относятся к категории физических дампов, когда сохраняемые дан" ные копируются прямо на диск или ленту. Простота подобного процесса позволяет создавать физические дампы с максимальной скоростью, но полученный в результате дамп удастся загрузить да" леко не во все версии SQL Server, работающие на различных аппаратных платформах. Логический дамп представляет собой полный дамп всех объектов определенной базы данных, включающий в себя как содержащиеся в них данные, так и команды сервера, необходимые для со" здания самих объектов. Логический дамп загружается в любую версию SQL Server на любой аппарат" ной платформе. Он может быть применен для проверки и редактирования команд создания

www.books-shop.com

объектов данных. Из логического дампа легко выделить команды и данные, относящиеся к како" му"то определенному объекту базы данных. Если логический дамп отсутствует, любой восстанавливаемый объект данных приходится извле" кать из полного дампа базы данных. Предварительно этот дамп следует загрузить в отдельный сер вер, не используемый основными приложениями операционной системы. Только после этого можно прочитать структуру и данные поврежденного объекта, оказавшегося в главной копии базы данных на основном сервере. (Подробно см. главу 11.) Во многих наставлениях администраторам баз данных постоянно указывают на необходимость создания и своевременного сопровождения командных файлов, позволяющих воссоздать все объек" ты всех баз данных информационных систем. Кроме того, вам настоятельно советуют периодически выводить в файлы командой bср данные всех таблиц, имеющихся в вашей системе. Для любой реа" льной системы баз данных подобные рекомендации совершенно бесполезны. Ведь администратор базы данных не располагает временем для периодического копирования командой bср данных всех таблиц и редактирования командных файлов при создании каждого нового объекта данных. У него также нет свободного дискового пространства, достаточного для размещения всей вспомогательной информации. Любая ошибка, допущенная при ручной модификации одного из командных файлов, приведет к тому, что восстановленный сервер не только не будет содержать правильные объекты данных в нужных местах, но и вообще не сможет запуститься. Информационная система растет и усложняется. Потому абсурдно предполагать, что кто"то будет вручную поддерживать набор командных файлов, позволяющих восстановить все серверы, базы дан" ных, хранимые процедуры, триггеры, сегментацию баз данных и т.п. Вся подобная информация дол" жна быстро и надежно сохраняться в автоматическом режиме. Администратору сервера следует сосредоточиться на более важных вещах, чем командные файлы восстановления сервера. Именно здесь на помощь вам придут средства создания логических дампов баз данных. Периодическое сохранение полных логических дампов всех серверов вашей информационной системы необходимо в силу целого ряда причин. Во"первых, при восстановлении сервера после се" рьезных сбоев вам потребуется выполнить набор команд, позволяющих воссоздать структуру серве" ра, пострадавшей базы данных или отдельного ее объекта. Подобные команды также пригодятся при изменении сегментации базы данных для повышения производительности сервера. Тогда при удалении базы данных и ее воссоздании с новой структурой сегментов потребуется распределить все объекты по новым сегментам (будет достаточно отредактировать прежние команды создания этих объектов, содержащиеся в логическом дампе базы данных). Во"вторых, выполнение полного набора команд создания объекта является единственным способом переноса объекта данных на дру" гой сервер. Если логический дамп отсутствует, придется вручную проанализировать структуру пере" носимого объекта данных и написать собственный набор команд создания этого объекта на новом сервере. В третьих, при переходе с серверной машины одного производителя на компьютер другого теряется возможность использовать старые физические дампы, созданные с помощью SQL Server, поскольку они привязаны к определенной аппаратной платформе. В"четвертых, логические дампы требуются при переносе объектов данных между серверами различных версий, т.к. физические дам" пы из SQL Server 4.9.2 не загружаются серверами System 10 и System 11. В"пятых, пользователи могут случайно удалить несколько записей из миллиона, имеющихся в таблице, а затем потребовать вос" становления пропавших записей. При отсутствии логического дампа нужно найти свободное место для восстановления всей базы данных, загрузить полный ее дамп, и только потом извлечь из дампа искомые записи. Наконец, шестым и последним аргументом в пользу логических дампов является наличие в них действительно полного набора командных файлов, позволяющих последовательно восстановить абсолютно все содержимое сервера — проинициализировать серверные устройства командами disk init; после этого восстановить правильную конфигурацию сервера, баз данных, распределения ее сегментов по различным серверным устройствам и размещения объектов данных по соответствующим сегментам; затем перейти к восстановлению данных, хранившихся в этих объ" ектах. Таким образом, автоматические средства сохранения логических дампов всех серверов изба" вят вас от необходимости составления многочисленных командных файлов восстановления структуры 'сервера и послужат хорошим средством документирования этой структуры при внесении в нее изменений. Конечно, логический дамп сервера и базы данных можно создать вручную. Для этого нужно на" писать командные файлы, которые сначала выбирают всю необходимую информацию из системных и пользовательских таблиц, а затем с помощью команды Ьср записывают в файл данные, хранящие" ся в каждой таблице. Здесь важно проследить все взаимосвязи, которые необходимо сохранить при восстановлении любого объекта, например, очередность создания бизнес"правил и типов данных. Следует соблюсти правильную очередность воссоздания объектов, поскольку при создании каждого

www.books-shop.com

нового объекта может оказаться существенным наличие других объектов. В целом подобная проце" дура крайне трудоемка и подвержена случайным ошибкам. Даже предположив, что вам удалось вруч" ную создать корректный логический дамп базы данных, нельзя быть до конца уверенным, что его могут использовать другие администраторы баз данных. Поэтому создание логических дампов даже небольших баз данных должно быть автоматизировано и включено в регулярную последователь" ность сохранения дампов. Для этой цели предназначена созданная компанией DataTools программа SQL BackTrack, облада" ющая многочисленными дополнительными возможностями, помимо перечисленных выше. Про" грамма SQL BackTrack совместно с SQL Server позволяет создать логические дампы любых компонентов сервера — начиная с полного логического дампа сервера и кончая логическим дампом отдельного объекта базы данных. Наряду с описанием структуры таблиц данных, SQL BackTrack так" же включает в логический дамп и данные из этих таблиц. Помимо логических дампов, SQL Back" Track способна сохранять физические дампы баз данных, а также извлекать логическое определение любого объекта базы данных из ее дампа. Программа SQL BackTrack обеспечивает гиб" кость в работе. Например, она позволяет администратору сервера извлечь логический дамп табли" цы данных из логического либо физического дампа всей базы данных, после чего набрать в командной строке команду восстановления этой таблицы в другом сегменте базы данных. SQL Back" Track также дает возможность создавать наращиваемые физические дампы баз данных. Такие дампы аналогичны наращиваемым дампам файловых систем, которые выполняются стандартными средст" вами архивации UNIX. Они сокращают время простоя сервера, необходимое для создания периоди" ческих дампов баз данных. Наконец, использование программы SQL BackTrack намного упрощает сам процесс создания ло" гического дампа базы данных. Исключается необходимость ручного вывода в файл содержимого си" стемных таблиц командой bср; поиск в полученных файлах информации, необходимой при воссоздании таблиц данных, правил, пользовательских типов данных, хранимых процедур и тригге" ров; вывод той же командой bср всех данных из всех остальных таблиц сервера. При работе с SQL BackTrack перечисленные выше операции выполняются одной командой, набираемой в командой строке программы. Так же загружается логический дамп (либо его часть). Одной командой SQL Bac" kTrack можно создать все необходимые объекты со строгим соблюдением очередности их создания, после чего загрузить bср"файлы, даже не интересуясь их точным местонахождением. База данных имеет размер в 5,6 Гбайт и распределена по нескольким серверным устройствам. Внезапно на горизонте возникают клубы пыли, свидетельствующие о при+ ближении толпы паникующих пользователей, напоминающей стадо обезумевших газе+ лей, несущихся по просторам Серенгети. Едва переводя дух, пользователи объясняют, что ни один из них не предпринимал каких+либо действий, но тем не менее 10 строк таблицы данных исчезли без следа, и эти данные нужны им прямо сейчас. В ожидании пользователи бесцельно слоняются по вашему закутку. Оказывается, исчезнувшая табли+ ца действительно состояла всего из 10 строк, но ее восстановление требует полной за+ грузки дампа базы данных, поскольку у вас нет ни лишнего дискового пространства, ни времени на создание, документирование, хранение и своевременное обновление bcp+дампов всех 800 таблиц, имеющихся на сервере. Вам остается только прервать вы+ полнение dbcc+проверок на вспомогательном DBCC+сервере, чтобы загрузить туда све+ жий и еще не проверенный дамп основной базы данных. Для этого приходится удалить с DBCC+сервера несколько других баз данных, создать базу данных в 5,6 Гбайт и терпели+ во дождаться завершения загрузки ее дампа. Тем временем пользователи начинают те+ рять терпение. Через некоторое время вы извлекаете командой Ьср требуемые 10 строк из загрузивше+ гося наконец дампа базы данных и с облегчением даете их на растерзание пользовате+ лям. Все позади (включая большую часть вашего рабочего дня, потраченную на бессмысленную суету), но вы прекрасно понимаете, что при следующей случайной оплошности неизвестного пользователя подобная история повторится. Пользователи ис+ чезают, а вы начинаете устранять следы их пребывания и обнаруживаете так и не от+ правленную заявку на приобретение одной полезной программы, позволяющей автоматически сохранять логические дампы всего сервера. Самое время взять ее в руки и отправиться к королю джунглей. Несомненно, он уже ждет вас в своем угловом офисе.

www.books-shop.com

Важно заметить, что SQL BackTrack версии 3.0 может быть вызвана из хранимой процедуры, что позволяет серверу автоматически создавать логические дампы, устанавливая свободное дисковое пространство ниже заранее определенного порога. Предыдущие версии SQL BackTrack можно было вызывать только из командных файлов операционной системы (например cron"задач), что не давало возможности использовать механизм порогов, появившийся в SQL Server System 10 и 11. Пороги иг" рают весьма важную роль в процессе защиты от сбоев. С их помощью сервер предпринимает необ" ходимые действия для сокращения свободного пространства в каком"либо из сегментов базы данных. Пороги особенно полезны для контроля за свободным пространством в сегменте журнала транзакций (logsegment). Достигая порог в logsegment, сервер автоматически выполняет хранимую процедуру sp_thresholdaction или любую другую, указанную пользователем. Вне зависимости от выбранного названия этой процедуры, она должна в первую очередь попытаться сохранить дамп журнала транзакций для очистки logsegment от старых записей. В подобной ситуации не удастся вос" пользоваться предыдущими версиями SQL BackTrack, поскольку их нельзя вызвать из хранимой про" цедуры. Это хороший аргумент в пользу перехода на SQL BackTrack версии 3.0. (Подробно об использовании порогов см. в главе 12.)

Типы сбоев и порядок восстановления сервера Будьте готовы к тому, что любое из перечисленных ниже событий рано или поздно произойдет. Зара" нее продумайте свои действия в любой из подобных ситуаций. Хотя для каждого типа сбоя приводит" ся рекомендуемый порядок действий, во многих случаях возникшие проблемы можно решить несколькими способами. При наличии резервного сервера следует переключиться на него и затем из" влечь из его баз данных информацию, позволяющую восстановить основной сервер. Так же следует поступить, имея вспомогательный сервер поддержки принятия решений или DBCC"сервер. Эти сер" веры способны заменить основной сервер на время его восстановления. В приводимых примерах предполагается, что у вас есть полный набор заведомо корректных дампов баз данных и журналов транзакций. Какая прекрасная фраза — заведомо корректный дамп. Она имеет лишь один недоста+ ток: таких дампов просто не существует в природе, поскольку у администратора сервера никогда нет времени на выполнение полного объема dbcc+проверок перед сохранением дампа базы данных или журнала повтора, как того требуют руководства по эксплуатации сервера. Попробуйте объяснить пользователям, почему перед сохранением каждого дампа журнала повтора необходимо на 30 часов отключать систему для проведения всех dbcc+проверок базы данных в 8 Гбайт, если для сведения возможных потерь данных до минимума журналы повтора должны сохраняться каждые 15 минут. Если произошел сбой сервера, рекомендуется проконсультироваться со службой технической поддержки Sybase (в случае, если наши объяснения покажутся недостаточными либо вы не вполне понимаете сущность сбоя и описанные способы его устранения). Перезапуск сервера При каждом своем перезапуске сервер автоматически осуществляет процесс восстановления баз дан" ных сервера, требующий доступа сервера к текущему журналу транзакций каждой базы данных. Ошибка 1105 Если ошибка 1105 связана с переполнением любого сегмента базы данных, не содержащего ее журна" ла транзакций, администратору сервера достаточно расширить заполненный сегмент. Если же ошиб" ка 1105 свидетельствует о переполнении журнала транзакций, то читателю следует обратиться к главе 12, где рассматривается последовательность действий в подобной ситуации. Администратор сервера может избежать возникновения этих ошибок путем продуманного испо" льзования механизма порогов. Действительно, грамотно установленные пороги позволяют исклю" чить выдачу ошибки 1105 из"за переполнения журнала транзакций. Однако и в этом случае ошибки 1105 могут произойти при переполнении остальных сегментов базы данных. Кроме того, сегмент журнала транзакций базы данных master нельзя вынести на отдельное устройство. Поэтому установка порогов не предотвратит переполнения журнала транзакций базы данных master. Для полного иск" лючения появления ошибок 1105 пороги необходимо установить на все сегменты всех баз данных, имеющихся на сервере. Кроме того, не следует забывать, что при срабатывании порога переполне" ния журнала транзакций активизированная хранимая процедура попытается очистить журнал путем создания его дампа. Создание дампа может не привести к очистке журнала транзакций, если

www.books-shop.com

имеются транзакции, открытые в течение длительного периода времени. Тогда администратор сер" вера окажется в такой же ситуации, как переполнение журнала транзакций с.выдачей ошибки 1105. Здесь необходимо прежде всего определить, почему нельзя усечь журнал транзакций, а также спосо" бы устранения причины. Следует также помнить, что после добавления в сервер новой базы данных или восстановления прежней из старого дампа пороги журнала транзакций могут быть неактивизи" рованы или вообще отсутствовать, а соответствующая хранимая процедура — оказаться неработос" пособной. (Подробно см. главу 12.) При возникновении ошибки 1105 из"за переполнения журнала транзакций базы данных tempdb выполните команду dump transaction tempdb with no_log При работе с любой другой базой данных эта команда приводит к нарушению последовательно" сти дампов журнала транзакций и поэтому крайне неблагоприятно влияет на возможность восста" новления этой базы данных. Однако в рассматриваемой ситуации это не имеет значения, поскольку база данных tempdb вообще не восстанавливается после сбоев. Если журнал транзакций базы данных tempdb невозможно очистить командой dump transaction with no_log, перезапустите сервер. Это полностью удалит прежнее содержимое tempdb. Отсутствие возможности создания дампов журнала транзакций Содержимое журналов транзакций основных баз сервера должно регулярно записываться в дампы, что гарантирует возможность восстановления состояния базы данных на момент, близкий к сбою, а также обеспечивает периодическую очистку журнала транзакций, исключающую его переполнение. Если процесс регулярного создания дампов журнала транзакций нарушен, возникает опасность запол" нения журнала транзакций, а его утрата ограничит восстановление базы данных моментом создания последнего успешного дампа этого журнала. Утрата одного или нескольких дампов журнала транзакций В случае, если создаваемые дампы журнала транзакций используются для обновления баз данных вспомогательного сервера, можно надеяться на оперативное выявление сбоя в последовательности дампов. Сложится ситуация, исключающая возможность загрузки очередного дампа во вспомогатель" ный сервер. Причинами обычно бывают некорректность самого дампа или отсутствие предыдущего дампа. Если загрузка дампа журнала транзакции приводит к ошибке и выдаче сообщения о нарушения очередности дампов ("dump out of sequence"), следует найти пропущенный дамп и загрузить его. При отсутствии одного или нескольких дампов журнала транзакций продолжить процесс загрузки дампов невозможно. Также нельзя восстановить базу данных далее последнего дампа перед пропущенным. Для возобновления нормального процесса сохранения дампов журнала транзакций здесь необходимо сохранить полный дамп базы данных. До момента его создания все изменения, внесенные в базу дан" ных, имеют шанс оказаться утраченными в случае сбоя сервера. В ходе обычной dbcc*проверки обнаружена порча базы данных Воспользуйтесь командой dbcc с необходимым набором подкоманд, позволяющих исправить наруше" ния структуры базы данных, предварительно переведя базу данных (либо весь сервер, если речь идет о базе данных master) в однопользовательский режим работы. При этом все пользователи базы дан" ных или сервера будут принудительно отключены от них. Если восстановить структуру базы данных командой dbcc нельзя, ее придется загрузить из дам" пов. Если и это невозможно, значит база данных утрачена (см. ниже). Утрата пользовательской базы данных ЕСЛИ база данных master к серверное устройство, поддерживающее журнал транзакций пострадавшей базы данных, остаются доступными, сохраните на диск дамп текущего журнала транзакций командой dump transaction с параметром no_truncate. Затем удалите базу данных и воссоздайте ее на основании информации о структуре ее сегментов, их размерах и распределению по серверным устройствам. Эти сведения содержатся в дампах системных таблиц, которые должны регулярно со" храняться администратором сервера. После воссоздания структуры базы данных загрузите ее послед" ний полный дамп и полный набор последующих дампов журнала транзакций, включая дамп текущего содержимого этого журнала. Утрата серверного устройства При доступности остальных серверных устройств, находящихся на отказавшем диске, зеркально ото" бразите их на подходящие свободные разделы других дисков, после чего удалите основные

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

устройства только что созданных зеркальных пар (см. главу 8). Теперь можно заменить вышедший из строя диск, заново создать утраченное устройство и восстановить все ранее находившиеся на нем базы данных путем их удаления, воссоздания и загрузки имеющихся дампов (см. выше). Затем перейдите к выполнению обычных операций, сопутствующих замене дискового накопите" ля (см. далее). Утрата зеркальной копии серверного устройства Подобное происшествие не создает немедленной угрозы данным. Постарайтесь определить причины отказа и выясните, являлось ли отказавшее устройство главным или вторичным устройством зеркаль" ной пары. Затем попытайтесь восстановить зеркальную пару командой disk remirror, предварите" льно убедившись вместе с системным администратором серверной машины в отсутствии сообщений об аппаратных сбоях соответствующего диска. Если необходимо заменить вышедший из строя диск, воспользуйтесь процедурой, описанной в следующем разделе. Обратите внимание на то, что наличие зеркальной копии отказавшего устрой" ства дает позволяет остановить сервер для замены диска в наиболее подходящий момент. Выход из строя дискового накопителя Серверные устройства, не имеющие зеркальных копий и расположенные на отказавшем диске, ока" зываются утраченными. Список пострадавших серверных устройств можно найти в заблаговременно сохраненных дампах системных таблиц. Если после сбоя диска сервер остается работоспособным и база данных master по"прежнему доступна, запишите на диск дампы текущих журналов транзакций всех баз данных, пострадавших при отказе диска. После этого остановите сервер и серверную маши" ну и замените этот диск. Включив серверную машину и перезапустив сервер, восстановите на заме" ненном диске прежнюю структуру серверных устройств, используя для этого ранее сохраненные дампы системных таблиц базы данных master. Затем удалите все базы данных, сегменты которых нахо" дились на утраченных серверных устройствах, создайте их заново, сохраняя прежнюю структуру сег" ментов и загрузите последние дампы соответствующих баз данных. Потом загрузите все последующие дампы журналов транзакций, включая дампы текущих журналов транзакций, сохраненные непосред" ственно перед выключением сервера. В случае полного зеркального резервирования всех серверных устройств отказавшего диска не нужно предпринимать немедленных действий. Приступив в подходящий момент к замене вышедше" го из строя диска, удалите из зеркальных пар все расположенные на этом диске устройства в режи" ме mode = remove. He забудьте указать в команде disk unmirror, являлось ли удаляемое устройство главным или вторичным устройством зеркальной пары. Затем остановите сервер и сер" верную машину, замените диск и заново запустите сервер. Теперь вам остается лишь воссоздать прежнюю структуру разделов диска и заново отобразить на него сохранившиеся зеркальные копии прежних серверных устройств. Здесь мы еще раз убеждаемся в одном из основных преимуществ зеркального резервирования ди" сков: для замены диска можно выбрать самый удобный момент. Утрата физического диска, содержавшего серверное устройство master, не имеющее зеркальной копии, означает потерю базы данных master, а значит и всего сервера (см. ниже). Выход и строя серверной машины Объем операций, необходимых для восстановления сервера после утраты серверной машины, зави" сит от конкретных причин, приведших к выходу серверной машины из строя. Если после ее успешно" го восстановления на дисках не будет обнаружено повреждений, следует попытаться запустить сервер и проконтролировать процесс восстановления баз данных. В зависимости от состава выдавае" мых сообщений об ошибках может потребоваться восстановление одной или нескольких пользовате" льских баз данных, серверного устройства master либо переустановка всего сервера. При полной утрате сервера необходимо установить его заново (см. главу 13) с последующей ини" циализацией серверных устройств командой disk init и выполнением всех остальных этапов воссоздания структуры баз данных, находившихся на этих устройствах до сбоя серверной машины. Проконтролировать, правильно ли восстановлена конфигурация серверных устройств, можно при помощи дампов системных таблиц сервера (которые, вероятно, потребуется загрузить из дампов прежней файловой системы серверной машины). Затем воспользуйтесь последним имеющимся дам" пом базы данных master и восстановите таблицу syslogins. После этого загрузите дампы пользователь" ских баз данных. Не забудьте использовать информацию из системных таблиц базы данных master и регулярно сохранять дампы этих таблиц.

www.books-shop.com

Воссоздание серверных устройств и всех других компонентов сервера значительно ускорится при наличии полных логических дампов сервера, регулярное сохранение которых является важным компонентом схемы защиты сервера от сбоев. (Логические дампы подробно рассматривались в раз" деле, посвященном программе SQL BackTrack.) Утрата базы данных master или серверного устройства master Рассматриваемая ситуация эквивалентна утрате всего сервера. Если серверное устройство master является единственным утраченным устройством сервера, его можно воссоздать командой buildmaster (предварительно обязательно остановив сервер). В этой команде необходимо задать правильный размер устройства master, который содержится в коман" дном файле RUN_<названле_сервера>, создаваемого программой sybinit при установке сервера. Этот размер можно также узнать из журнала регистрации ошибок сервера. Размер устройства master следует указать в команде buildmaster с использованием правильных единиц измерения. Обязате" льно прочитайте руководство по устранению неполадок в SQL Server (SQL Server Troubleshooting Guide), где подробно обсуждаются все особенности восстановления устройства master. По завершении воссоздания устройства master и одноименной базы данных необходимо загру" зить последний полный дамп этой базы данных. Тогда сервер распознает все серверные устройства и базы данных, находившиеся до сбоя на этих устройствах. Если после сохранения последнего дам" па базы данных master в нее вносились какие"либо изменения, они должны быть в точности воспро" изведены при восстановлении сервера. Поэтому рекомендуется сохранять дамп базы данных master после каждой ее модификации. Затем можно перейти к восстановлению других поврежденных компонентов сервера. Утрата объекта базы данных и/или содержавшейся в нем информации При наличии копии соответствующей базы данных на другом сервере, утраченный объект проще все" го скопировать со вспомогательного сервера (в качестве которого может выступить резервный сер" вер, сервер поддержки принятия решения или DBCC"сервер). Если такой подход невозможен, следует восстановить на одном из серверных устройств полный дамп базы данных и скопировать тре" буемый объект. (О необходимости свободного пространства для загрузки старых дампов баз данных см. главу 11.) При регулярном сохранении логических дампов сервера восстановить утраченный объект базы данных намного легче, поскольку в логическом дампе уже содержатся все команды и данные, нуж" ные для восстановления любого объекта базы данных. Однако SQL Server не поддерживает сохране" ние логических дампов. Следует воспользоваться программами независимых поставщиков, например, обсуждавшейся ранее программа SQL BackTrack компании DataTools. Утрата данных или объекта базы данных после перехода на новую версию сервера Предположим, что после обновления SQL Server 4.9.2 до System 11 кому"то из пользователей потребо" вались данные, модифицированные либо удаленные из сервера еще до перехода на новую версию, но оставшиеся в дампах версии 4.9.2. В подобном случае нужно определить, в каком конкретно из ста" рых дампов могут содержаться необходимые данные, затем воссоздать соответствующую базу данных в сервере версии 4.9.2 (может потребоваться его установка), загрузить дамп и извлечь необходимые пользователю данные. Если пользователь настаивает на переносе восстановленных данных в SQL Ser" ver System 11, не забывайте о существенных отличиях разных версий сервера, которые могут ослож" нить подобную операцию.

www.books-shop.com

www.books-shop.com

Глава 10

Производительность сервера и его настройка Содержание Особенности различных версий SQL Server Работа с процедурой sp_sysmon Подробнее о работе с sp_sysmon Основные компоненты выдачи sp_sysmon Выдача sp_sysmon Рекомендации по конфигурированию кэшбуферов Не злоупотребляйте теорией Некоторые практические рекомендации Индексы и запросы Распределение сегментов баз данных по серверным устройствам Распределение таблицы по нескольким устройствам Архивация данных Сервер поддержки принятия решений Стандартный набор тестовых транзакций SQL Monitor Встроенные средства анализа производительности SQL Server Настройка сервера независимо от приложений

Сокращение периодов недоступности сервера

www.books-shop.com

Введение Настройке производительности баз данных посвящено много литературы. Однако степень надежно" сти конкретных рекомендаций часто напоминает прогноз погоды. Хотя существует ряд детально раз" работанных и весьма солидно выглядящих на бумаге теорий повышения производительности баз данных, только малая их часть имеет отношение к реальным информационным системам. В этой гла" ве рассматривается ряд конкретных ситуаций, приводящих к снижению производительности серве" ра. Очень полезен предлагаемый компанией Sybase курс по настройке оптимизации SQL Server (SQL Server Performance and Tuning), а также — для знакомых с SQL Server System 10 — курс лекций на ком" пакт"диске, посвященный вопросам оптимизации при переходе от System 10 к System 11 (Performance and Tuning Migration System 10 to System 11), входящий в серию компакт"дисков SKILS компании Sybase. Советуем проработать один из рекомендуемых курсов перед тем, как приступить к практиче" скому анализу производительности и настройке сервера. В следующем разделе главы кратко обсужда" ются особенности оптимизации различных версии SQL Server. Особенности различных версий SQL Server Весь материал данной главы относится ко всем существующим версиям SQL Server, за исключением раздела, посвященного системной хранимой процедуре sp_sysmon, имеющейся только в SQL Server System 11. SQL Server 4.9.2 Версия 4.9.2 SQL Server не поддерживает ни сервера архивации (Backup Server), ни расширенных конфигурационных возможностей System 11, ни процедуры sp_sysmon. SQL Server System 10 В составе System 10 впервые появился сервер архивации, значительно сокративший время создания и загрузки дампов баз данных. В этот период производительность сервера заметно снижается. Однако System 10 не полностью использует преимущества симметричных многопроцессорных систем, что да" леко не всегда обеспечивает превосходство производительности SQL Server System 10 над серве" ром 4.9.2. Кроме того, эта версия SQL Server также не поддерживает расширенные конфигурационные возможности System 11 и процедуру sp_sysmon. SQL Server System 11 Сервер System 11 обладает множеством новых параметров конфигурации, именованными кэш"буфе" рами, а также значительно улучшенной масштабируемостью. В результате сервер стал намного гибче, но и одновременно сложнее в настройке. Проблема контроля за настройкой SQL Server System 11 час" тично решается с помощью конфигурационных файлов и новых средств конфигурирования сервера. Хранимая процедура sp_sysmon, впервые появившаяся в System 11, позволяет администратору сер" вера получить полную информацию о функционировании сервера, необходимую при настройке всех его новых средств повышения производительности. SQL Server System 11 также поддерживает новый режим очистки страниц (иногда называемый housekeeper function), обеспечивающий своевремен" ную запись на диск "грязных" страниц кэш"буфера. Это заметно сокращает объем операций ввода"вы" вода, выполняемых при обработке контрольных точек. Работа с процедурой sp_sysmon Системная хранимая процедура sp_sysmon относится к числу важнейших компонентов Sybase SQL Server System 11, впервые включенных в состав SQL Server версии 11.0.1. Она позволяет администра" тору сервера получить большой объем информации о текущей производительности сервера. Схожи" ми возможностями обладает и другое полезное средство анализа производительности сервера — Sybase SQL Monitor. Это отдельный программный продукт, приобретаемый за отдельную плату, кото" рый рекомендуется использовать совместно с sp_sysmon. Однако, если у вас нет SQL Monitor, ни в коем случае не следует пренебрегать широкими возможностями sp_sysmon. Хотя возможности SQL Monitor и sp_sysmon во многом пересекаются, состав информации, вы" даваемой этими средствами, далеко не идентичен. В отличие от sp_ sysmon, SQL Monitor может прослеживать доступ сервера к отдельному объекту базы данных. В свою очередь, sp_sysmon сооб" щает много подробностей и сводных показателей по отдельным аспектам работы сервера, которые нельзя получить с помощью SQL Monitor. Таким образом, следует пользоваться обоими средствами

www.books-shop.com

одновременно, принимая во внимание, что SQL Monitor и sp_sysmon применяют одни и те же внутренние счетчики SQL Server. Поэтому запуск SQL Monitor до завершения работы sp_sysmon приведет к сбросу счетчиков сервера, что исказит выдачу процедуры sp_sysmon. Используя SQL Monitor и sp_sysmon совместно, следите за тем, чтобы не допустить их взаимного влияния. Запуск процедуры sp_sysmon приводит к снижению производительности сервера. По оценкам Sybase оно достигает 5"7% на однопроцессорных системах. Влияние sp_sysmon на производитель" ность многопроцессорных систем может оказаться несколько выше, однако о реальных значениях этого показателя специалисты продолжают дискутировать. Разумеется, sp_sysmon замедляет работу сервера, но без регулярного запуска этой процедуры настройка сервера и повышение его произво" дительности становятся невозможным. Попробуйте запускать sp_sysmon каждый час на протяже" нии недели, после чего проконтролируйте, привело ли это к заметному для пользователей снижению скорости работы приложении. Для запуска хранимой процедуры sp_sysmon достаточно задать требуемый интервал времени ее работы. Обычно он составляет от 1 до 10 минут. В течение этого промежутка sp_sysmon периоди" чески проверяет значения различных внутренних счетчиков SQL Server. Через указанное время про" цедура прекратит работу и выдаст отчет с накопленными сведениями о производительности сервера. Пока действует интервала работы sp_sysmon, основные приложения, использующие сер" вер, работают в своем обычном стабильном режиме. Выдача sp_sysmon будет содержать мало ос" мысленной информации, если в процессе работы процедуры произойдет, например, переполнение одного из именованных кэш"буферов. Анализируя выданные sp_sysmon показатели производительности сервера, их необходимо срав" нивать с определенными базовыми значениями, полученными в период небольшой загрузки серве" ра, а также с выдачей sp_sysmon во время пиковой нагрузки на него. Лишь сопоставив выдачу sp_sysmon с минимальными и максимальными достигнутыми показателями производительности сервера, можно приступать к его настройке путем изменения параметров его конфигурации. Разум" нее всего запускать sp_sysmon регулярно в качестве cron"задачи, собирающей показатели произво" дительности сервера через равные промежутки времени, охватывающие весь бизнес"цикл работы приложения. Например, анализ производительности сервера, поддерживающего систему приема за" казов, должен охватывать как минимум период одного квартала. Наибольшая нагрузка сервера сов" падет с окончанием квартала. Однако информация, отражающая нормальную работу сервера в остальные фазы бизнес"цикла, позволит лучше сопоставить имеющиеся ресурсы с фактическим их использованием. В данном примере можно обнаружить также кратковременные всплески активно" сти в конце каждого месяца. Только на основании сводки о характере работы сервера в течение пол" ного бизнес"цикла можно определить реальную конфигурацию сервера, максимально соответствующую нуждам конкретной компании. Способность sp_sysmon выдавать большой объем информации о самых разных аспектах функ" ционирования сервера не требует от администратора сервера изменять значения многих конфигу" рационных параметров одновременно. Проявляйте разумную сдержанность при анализе выдачи sp_sysmon. Вполне возможно, что в действительности конфигурация сервера вообще не нуждается в изменениях, и медленная работа приложений вызвана в вашем случае отнюдь не недостаточной производительностью сервера. Подробнее о работе с sp_sysmon Огромный объем информации, выдаваемой sp_sysmon о работе сервера, выглядит порой просто уд" ручающе. Важно научиться анализировать эту информацию систематически, не теряясь в море полу" ченных цифр. Не поддавайтесь искушению выбрать произвольный аспект работы сервера и настроить его, подбирая различные значения параметров конфигурации и не обращая внимания на все остальные показатели производительности. Для правильного использования sp_sysmon необхо" димо постоянно сопоставлять все основные параметры в распечатках, выданных этой процедурой до и после внесения изменений в конфигурацию сервера. В последующих разделах главы рассматрива" ются различные компоненты выдачи sp_sysmon в порядке их важности. Выдача sp_sysmon состоит из последовательности отдельных групп показателей производитель" ности сервера, перечисленных ниже в порядке их появления в распечатке. Один и тот же показа" тель может одновременно входить в несколько таких групп: Загрузка ядра сервера (Kernel Utilization) Управление задачами (Task Management ) Профилирование транзакций (Transaction Profile)

www.books-shop.com

Управление транзакциями (Transaction Management) Управление индексами (Index Management) Управление блокировками (Lock Management) Управление кэш"буфером данных (Data Cache Management) Управление кэш"буфером процедур (Procedure Cache Management ) Управление памятью (Memory Management) Управление контрольными точками (Recovery Management) Управление дисковым вводом"выводом (Disk I/O Management) Управление сетевым вводом"выводом (Network I/O Management) Основные компоненты выдачи sp_sysmon Полностью все разделы выдачи процедуры sp_sysmon рассматриваются в руководстве по настройке производительности SQL Server (Sybase SQL Server Performance and Tuning Guide). В этой главе об" суждаются только наиболее важные разделы этой распечатки, чтобы дать короткий перечень основ" ных параметров. Их значения при возникновении проблем с производительностью сервера необходимо проверить в первую очередь. Естественно, ни один подобный список не может полно" стью отражать все особенности конкретного сервера и приложений, используемых на нем, однако, он поможет научиться ориентироваться в огромном количестве показателей, выдаваемых процеду" рой sp_sysmon. Ниже приведен ряд рекомендаций по изменениям в конфигурации сервера, позволяющим устра" нить некоторые проблемы. При настройке сервера обязательно выполните sp_sysmon перед и по" сле модификации значений параметров настройки, чтобы убедиться в полезности внесенных изменений. (Полную распечатку выдачи sp_sysmon см. далее.) Участки распечатки, которые рассматривают" ся в ближайших разделах главы, отмечены номерами, указанными в следующем списке: 1. Загрузка ядра сервера: степень загрузки поисковых ядер (Kernel Utilization — Engine Busy Utilization) 2. Управление задачами: переключение задач из"за преднамеренного возврата управления (Task Management " Task Context Switches Due To Voluntary Yields) 3. Управление задачами: переключение задач из"за ожидания завершения транзакций (Task Management — Task Context Switches Due To Group Commit Sleeps) 4. Управление задачами: переключение задач при записи на последнюю страницу журнала транзакций (Task Management — Task Context Switches Due To Last Log Page Writes) 5. Управление задачами: переключение задач в силу других причин (Task Management — Task Context Switches Due To Other Causes) 6. Управление транзакциями: сброс пользовательского буфера журнала транзакций из"за пе" реполнения буфера (Transaction Management — ULC Flushes to Xact Log by Full ULC) 7. Управление транзакциями: сброс пользовательского буфера журнала транзакций при завер" шении транзакции (Transaction Management — ULC Flushes to Xact Log by End Transaction) 8. Управление транзакциями: сброс пользовательского буфера журнала транзакций при пере" ключении баз данных (Transaction Management — ULC Flushes to Xact Log by Change of Da" tabase) 9. Управление транзакциями: сброс пользовательского буфера журнала транзакций из"за дру" гих причин (Transaction Management — ULC Flushes to Xact Log by Other) 10. Управление транзакциями: ожидание предоставления блокировки"семафора на доступ к по" льзовательскому буферу журнала транзакций (Transaction Management — ULC Semaphore Requests Waited) 11. Управление транзакциями: кратность записи страницы на диск (Transaction Management — Avg # Writes per Log Page) 12. Управление блокировками: ожидание блокировок различных типов (Lock Management — Lock Detail — <Вид блокировки> — Waited/Total Requests)

www.books-shop.com

13. Управление кэш"буфером данных: общее количество успешных обращений ко всем кэш"бу" ферам (Data Cache Management — Cache Statistics Summary (All Caches), Cache Search Sum" mary, Total Cache Hits) 14. Управление кэш"буфером данных: количество "грязных" буферных блоков, выгруженных из буфера (Data Cache Management — Cache Statistics Summary (All Caches), Cache Turnover, Buffers Grabbed Dirty) 15. Управление кэш"буфером данных: эффективность использования больших блоков ввода"вы" вода (Data Cache Management — Cache Statistics Summary (All Caches), Large I/O Effective" ness, Pages by Lrg I/O Used) 16. Управление кэш"буфером данных: интенсивность использования буфера (Data Cache Mana" gement — Default Data Cache Utilization) 17. Управление кэш"буфером данных: количество страниц, найденных за точкой очистки (Data Cache Management — Default Data Cache, Cache Searches, Found in Wash) 18. Управление кэш"буфером данных: количество неуспешных обращений к буферу (Data Cache Management — Default Data Cache, Cache Searches, Cache Misses) 19. Управление кэш"буфером данных: количество "грязных" буферных блоков, выгруженных из буферного пула (Data Cache Management — Default Data Cache, Pool Turnover, Grabbed Dirty) 20. Использование больших блоков ввода"вывода: невыполненный ввод"вывод (Large I/O Usage — Large I/Os Denied) 21. Использование больших блоков ввода"вывода: соотношение прочитанных в буфер и реаль" но использованных страниц (Large I/O Usage — Large I/O Detail — Pages Used/Pages Cached) 22. Управление кэш"буфером процедур: выгрузка процедур из буфера (Procedure Cache Mana" gement — Procedure Removals) 23. Управление контрольными точками: количество нормальных и свободных контрольных то" чек (Recovery Management — Checkpoints, # of Free Checkpoints/# of Normal Checkpoints) 24. Управление дисковым вводом"выводом: причины задержек ввода"вывода (Disk I/O Manage" ment — I/Os Delayed by) 25. Управление дисковым вводом"выводом: общее число запросов (Disk I/O Management — Total Requested Disk I/Os) 26. Управление дисковым вводом"выводом: число выполненных запросов дискового ввода"вы" вода (Disk I/O Management — Completed Disk I/O's) 27. Управление дисковым вводом"выводом: общее число выполненных запросов (Disk I/O Management — Total Completed I/Os) 28. Управление дисковым вводом"выводом: чтение с устройства (Disk I/O Management — Devi" ce Activity Detail, Reads) 29. Управление дисковым вводом"выводом: запись на устройство (Disk I/O Management — Device Activity Detail, Writes) 30. Управление дисковым вводом"выводом: ожидание предоставления блокировки"семафора (Disk I/O Management — Device Activity Detail, Device Semaphore Waited) Загрузка ядра сервера (Kernel Utilization) Степень загрузки поисковых ядер (Engine Busy Utilization) Значением данного параметра является процент времени, в течение которого каждое поисковое ядро сервера выполняло различные задачи. Эта величина измеряется по отношению к полному про" цессорному времени, предоставляемому каждому ядру сервера операционной системой. 100%"я за" грузка означает, что ядро было занято в течение всего времени, отведенного ему операционной системой. Если степень загрузки ядра выше 80%, в систему следует добавить еще одно поисковое ядро, после чего проверить, удалось ли снизить этот показатель. Однако число поисковых ядер серве" ра никогда не должно превышать фактическое количество процессоров, имеющихся в системе. Для

www.books-shop.com

повышения производительности сервера лучше иметь несколько полностью загруженных поисковых ядер, чем много ядер, работающих с неполной загрузкой. Чтобы определить количество процессорного времени, получаемого каждым ядром от операци" онной системы, необходимо воспользоваться ее командами. Если ядро получает менее 100% всего времени процессора, следует определить, какие посторонние процессы конкурируют с серверным ядром за доступ к процессору. Управление задачами (Task Management) Причины переключения задач (Task Context Switches Due To:) Администратору сервера следует выяснить причины, по которым значения параметров, приведен" ные в перечисленных ниже разделах (кроме раздела "Другие причины" — "Other Causes"), превышают 10%. Высокие значения этих параметров указывают на излишнее количество переключений ядер с одной задачи на другую, что приводит к снижению быстродействия сервера. Преднамеренный возврат управления (Voluntary Yields) Если значение этого параметра превышает норму, следует увеличить квант времени, предоставляе" мый операционной системой каждому серверному процессу, и значение конфигурационного пара" метра "time slice". Ожидание завершения транзакций (Group Commit Sleeps) Высокое значение этого параметра означает, что производительность сервера ограничена конкурен" цией за запись в журнал транзакций. Запись на последнюю страницу журнала транзакций (Last Log Page Writes) Высокое значение данного параметра также означает, что производительность сервера ограничена конкуренцией за запись в журнал транзакций. Аругие причины (Other Causes) Данный параметр должен иметь высокое значение. Оно будет увеличиваться по мере устранения проблем, ограничивающих производительность сервера. Под "другими причинами" здесь имеются в виду причины переключения задач, находящиеся вне контроля администратора сервера.

Управление транзакциями (Transaction Management) Причины сброса пользовательского буфера журнала транзакций на диск (ULC Flushes to Xact Log): Сброс из.за переполнения буфера (by Full ULC) При значении параметра, превышающем 20%, необходимо увеличить размер пользовательского бу" фера журнала транзакций (User Log Cache). Для этого измените значение параметра конфигурации "user log cache size" с помощью процедуры sp_configure либо непосредственно в конфигурацион" ном файле. Сброс при завершении транзакции (End Transaction) Строка должна содержать высокие значения, намного превышающие значения строк "Сброс из"за переполнения буфера" ('Ъу Full ULC") и "Сброс при переключении баз данных" ("by Change of Data" base"). Сброс при переключении баз данных (by Change of Database) Значения не должны быть слишком высокими. Частые переключения баз данных означают, что ваш сервер обрабатывает большое число запросов, относящихся сразу к нескольким базам данных. Прове" рьте, является ли это нормальным и необходимым, поскольку обработка подобных запросов приво" дит к снижению производительности сервера. Аругие причины (by Other) Если выданные значения превышают 20%, необходимо сократить размеры пользовательского буфе" ра журнала транзакций.

www.books-shop.com

Запросы блокировок*семафоров на доступ к пользовательскому буферу журнала транзакций (ULC Semaphore Requests) Ожидание (Waited) Выданное значение должно быть менее 5%. В противном случае попробуйте увеличить размер поль" зовательского буфера журнала транзакций, сократить количество одновременных запросов к неско" льким базам данных и снизить интенсивность записи в журнал транзакций путем пересмотра структуры транзакций. Кратность записи страницы на диск (Transaction Management — Avg # Writes per Log Page) Выданное значение должно быть близким к 1 . Если оно превышает единицу, то некоторые страницы данных записываются на диск более одного раза. Выясните, почему серверу требуется неоднократно записывать на диск одну и ту же страницу данных. Управление блокировками (Lock Management) Подробные сведения о блокировках (Lock Detail) <Вид блокировки> Ожидание блокировки различных типов (Waited) Сравните значения, указанные для каждого типа блокировки. Найдите наиболее часто ожидаемые типы блокировок и сопоставьте количество ожидавших блокировку запросов с полным числом за" просов. Полное число запросов (Total Requests) Определите типы блокировок, вызвавшие ожидание наибольшей доли запросов (последний столбец строки "waited"). Затем обратитесь к этому же столбцу соответствующих строк "total". Если общий про" цент блокировок данного вида невелик, то задержки с их предоставлением не оказывают влияния на производительность сервера. Выделите типы часто запрашиваемых и одновременно часто ожидаемых блокировок, после чего установите причины активной конкуренции за блокировки данных типов. Управление кэш*буфером данных (Data Cache Management) Общая статистика по всем буферам (Cache Statistics Summary (All Caches)) Поиск в кэш.буферах (Cache Search Summary) Количество успешных обращений (Total Cache Hits) Для каждого из кэш"буферов сервера выданное значение должно быть выше 80%. Увеличить количе" ство успешных обращений к буферу можно путем расширения его размеров или изменением схемы назначения объектов баз данных именованным буферам. Обновление буфера (Cache Turnover) Количество буферных блоков, выгруженных "грязными" (Buffers Grabbed Dirty) Выданное значение параметра должно быть очень малым и в идеале равняться 0. Его можно умень" шить путем увеличения области очистки (buffer wash size) буферных областей тех кэш"буферов, из ко" торых выгружается наибольшее количество "грязных" буферных блоков. Эффективность использования больших блоков ввода+вывода (Large I/O Effectiveness) Использование страниц, загруженных в составе больших буферных блоков (Pages by Lrg I/O Used) Выданное значение характеризует общую эффективность использования больших блоков ввода"вы" вода по всем кэш"буферам сервера. Если процент использования загруженных страниц падает ниже 50%, значит кэш"буферы работают неэффективно, что может быть связано с большой фрагмента" цией таблиц данных. В подобной ситуации следует командой Ьср сохранить в файл данные таблицы, а потом загрузить их обратно (или удалить кластеризованный индекс, создав его затем заново).

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Общий кэш*буфер (Default Data Cache) Использование буфера (Utilization) Выданное значение представляет собой количество обращений к буферу по сравнению со всеми дру" гими именованными буферами. Сравните частоту обращений к различным буферам, чтобы найти слишком активные и малоиспользуемые буферы. Поиск в буфере (Cache Searches) Страницы, найденные за точкой очистки (Found In Wash) Слишком частое использование страниц буфера, прошедших точку очистки, указывает на слишком большой размер области очистки одной из буферных областей данного буфера. Для изменения раз" мера области очистки используйте команду sp_poolconf ig. Неуспешные обращения к буферу (Cache Misses) Процент неуспешных обращений к буферу должен быть как можно меньше и в идеале равняться 0. Проверьте значение этого параметра для каждого из именованных кэш"буферов сервера. Увеличьте размеры буферов, имеющих более 20% неуспешных обращений и меньше 80% успешных обращений ("Cache Hits"). Отсутствие нужных страниц данных в кэш"буфере обычно означает, что величина бу" фера неадекватна объектам баз данных, назначенных этому буферу. Обновление буферной области (Pool Turnover) Количество блоков, выгруженных "грязными" (Grabbed Dirty) Этот параметр должен равняться 0. Любое число блоков, выгруженных из буферной области "грязны" ми", свидетельствует о слишком малом размере области очистки (wash size) указанной буферной обла" сти. Размер области очистки устанавливается индивидуально для каждой буферной области с помощью команды sp_poolcon£ig. Название первого именованного буфера Здесь в выдаче процедуры sp_sysmon последовательно приводятся статистические данные, собран" ные по каждому именованному кэш"буферу сервера.

Название второго именованного буфера

Использование больших блоков ввода*вывода (Large I/O Usage) Невыполненный ввод*вывод (Large l/Os Denied) Большое значение параметра указывает на неэффективность использования больших блоков вво" да"вывода. Убедитесь в действительной необходимости использования этих блоков и найдите опти" мальную конфигурацию кэш"буферов и буферных областей.

Подробные сведения об использовании больших блоков ввода вывода (Large I/O Detail) Здесь приводится статистика, собранная по каждой буферной области (с блоками размером 2, 4, 8 или 16 Кбайт), имеющейся в именованном кэш"буфере. Страницы, прочитанные в буфер (Pages Cached) Использованные страницы (Pages Used) Проанализируйте процент использования страниц, загружаемых в буфер. Если он превышает 50%, то все в порядке. В противном случае загрузка в буфер лишних страниц снижает эффективность испо" льзования оперативной памяти сервера.

www.books-shop.com

Управление кэш*буфером процедур (Procedure Cache Management) Выгрузка процедур из буфера (Procedure Removals) ЕСЛИ любое из выданных значений превышает 10%, необходимо увеличить размеры кэш"буфера про" цедур. Для этого повысьте значение параметра конфигурации "procedure cache", определяющего про" цент всей оперативной памяти сервера, распределяемой кэш"буферу процедур. При сохранении общего объема памяти серверной машины, выделенной серверу, увеличение объема кэш"буфера про" цедур означает сокращение размеров кэш"буферов данных. Управление контрольными точками (Recovery Management) Контрольные точки (Checkpoints) Количество нормальных контрольных точек (# of Normal Checkpoints) Количество свободных контрольных точек (# of Free Checkpoints) Большая часть обрабатываемых контрольных точек должна являться свободными контрольными точками. В противном случае необходимо увеличить значение параметра конфигурации "housekeeper free write percent". Убедитесь в действенности внесенных изменений. Управление дисковым вводом*выводом (Disk I/O Management) Причины задержек ввода*вывода (l/Os Delayed by) Значения каждого из перечисленных ниже параметров должны равняться нулю. В противном случае устраните имеющиеся проблемы настройкой соответствующих параметров конфигурации сервера. Общее число запросов ввода*вывода (Total Requested Disk l/Os) Выданное значение должно быть близким к полному числу выполненных запросов ввода"вывода (To" tal Completed I/Os). Существенное различие значений этих параметров свидетельствует о насыще" нии дискового ввода"вывода на уровне операционной системы. Число запросов ввода*вывода, выполненных поисковыми ядрами (Completed Disk l/O's) Сравните обработанные каждым ядром запросы ввода"вывода, чтобы убедиться в сбалансированно" сти распределения нагрузки ввода"вывода между имеющимися серверными ядрами. Управление дисковым вводом*выводом: общее число выполненных запросов (Disk I/O Management — Total Completed l/Os) Значение этого параметра должно примерно равняться полному числу выданных запросов ввода"вы" вода (Total Requested Disk l/Os). Разница в величине этих параметров свидетельствует о насыщении дискового ввода"вывода на уровне операционной системы. Подробные сведения об активности дисковых устройств (Device Activity Detail) Чтение с устройства (Reads) Сопоставьте количество операций чтения со всех устройств сервера и выясните, почему одни устрой" ства используются активнее других. Проверьте правильность распределения нагрузки ввода"вывода между серверными устройствами и при необходимости переместите некоторые объекты баз данных с одного диска на другой. Запись на устройство (Writes) Действуйте аналогично предыдущему разделу. Ожидание предоставления блокировки семафора на доступ к устройству (Device Semaphore Waited) Отличное от 0 значение параметра для любого из серверных устройств означает, что это устройство неспособно обработать все полученные запросы на выполнение ввода"вывода. 18—2221

www.books-shop.com

Выдача sp_sysmon DBCC execution completed. If DBCC printed error messages, contact a user with System Administrator (SA) role. Выполнение команды DBCC завершено. Если команда DBCC выдала сообщения об ошибках, обратитесь к пользователю, имеющему статус системного администратора. Sybase SQL Server System Performance Report Jul 29 , 1996 16:41: 36 16:42: 36 1 min.

Run Date Statistics Cleared at Statistics Sampled at Sample Interval Kernel Utilization 1) Engine Busy Utilization: Engine 0

95. 5 %

CPU Yields by Engine Engine 0 Network Checks Non#Blocking Blocking

per sec 0.0

per xact

12831.2 0.9

29572.5

768886

2.0

53

Total Network I/O Checks: Avg Net I/Os per Check

12832.1 n/a

29574.6

Disk I/O Checks Total Disk I/O Checks Checks Returning I/O Avg Disk I/Os Returned

12832.1 12797.9 n/a

29574.6 29495.7

per sec 0.0

per xact

Task Management Connections Opened

Task Context Switches by Engine Engine 0 43.8 Task Context Switches Due To: 2) Voluntary Yields 0.5 Cache Search Misses 17.2 System Disk Writes 0.2 I/O Pacing 15.9 Logical Lock Contention 0.0 Address Lock Contention 0.0 Log Semaphore Contention 0.0 3 ) Group Commit Sleeps 0.9 4) Last Log Page Writes 0.5 Modify Conflicts 0.0 I/O Device Contention 0.0 Network Packet Received 0.2 Network Packet Sent 1.1 SYSINDEXES Lookup 0.0 5) Other Causes 7.3

0.0

n/a

n/a

count

0

768939 0.00010 768939 766887 0.01121 count

0.0

0

100.8

2622

1.1

29

39.7

1033

0.5

12 952 1 0 0 53 29 2 0 11 64 0 436

36.6

0.0 0.0 0.0 2.0 1.1 0.1 0.0 0.4 2.5 0.0 16.8

% of total

n/a 100.0 % 0.0 %

n/a n/a 99.7 %

n/a % of total

n/a 100 % 1.1 39.4 0.5 36.3 0.0 0.0 0.0 2.0 1.1 0.1 0.0 0.4 2.4 0.0 16.6

% % % % % % % % % % % % % % %

www.books-shop.com

Transaction Profile Transaction Summary Committed Xacts

per sec 0.4

per xact n/a

• count 26

% of total n/a

Transaction Detail Inserts Heap Table Clustered Table Total Rows Inserted

per sec

per xact

count

% of total

75.5 % 24.5 % 1.9 %

Updates Deferred Direct In#place Direct Cheap Direct Expensive Total Rows Updated Deletes Deferred Direct Total Rows Deleted Transaction Management ULC Flushes to Xact Log 6) by Full ULC 7) by End Transaction 8) by Change of Database by System Log Record 9) by Other Total ULC Flushes

1.9 0.6 2.5

4.4 1.4 5.8

114 37 151

0.3 0.0 127.4 0.0 127.6

0.6 0.0 293.6 0.0 294.2

15 0 7634 0 7649

0.5 0.1

1.2 0.1

30 3

0.6

1.3

33

0.2 0.0 99.8 0.0 97.7

% % % % %

90.9 % 9.1 % 0.4 %

per sec 108.4 0.5 0.0 2.7 0.1 111.6

per xact 249.8 1.0 0.0 6.3 0.1 257.3

count 6494 27 1 164 • 3 6689

513.2 n/a

1182.7 n/a

30751 2048

ULC Semaphore Requests Granted 10) Waited Total ULC Semaphore Req

899.9 0.0 899.9

2074.0 0.0 2074.0

53924 0 53924

100.0 % 0.0 %

Log Semaphore Requests Granted Waited Total Log Semaphore Req

149.4 0.0 149.4

344.3 0.0 344.3

8952 0 8952

100.0 % 0.0 %

Transaction Log Writes 96.9 Transaction Log Alloc 122.6 11) Avg # Writes per Log Page n/a

223.3 282.5 n/a

5807 7344 0.79071

ULC Log Records Max ULC Size

% of total

97.1 0.4 0.0 2.5 0.0

% % % % %

n/a n/a

n/a n/a n/a

Index Management Nonclustered Maintenance Ins/Upd Requiring Maint # of NC Ndx Maint Avg NC Ndx Maint / Op Deletes Requiring Maint # of NC Ndx Maint Avg NC Ndx Maint / Op

per sec 127.4 0.1 n/a 127.4 127.4 n/a

per xact 293.7 0.1

n/a 293.7 293.7 n/a

count 7637 3 0.00039 7637 7637 1.00000

% of total n/a n/a

n/a n/a n/a n/a

www.books-shop.com

RID Upd from Clust Split # of NC Ndx Maint Page Splits Page Shrinks Lock Management Lock Summary Total Lock Requests Avg Lock Contention Deadlock Percentage Lock Detail Exclusive Table Granted 12) Waited Total EX#Table Requests

0.0 0.0 0.0 . 0.0 per sec 1234.4

0.0 0.0 per sec

0.0 0.0 0.0 0.0

per xact 2844.8

0.0 0.0 per xact

0 0 0 0

n/a n/a n/a n/a

count 73966

% of total

1 0

0.0 % 0.0 % % of total

count

n/a

1.2 0.0 1.2

2.8 0.0 2.8

74 0 74

100.0 %

Shared Table Granted Waited Total SH#Table Requests

0.1 0.0 0.1

0.2 0.0 0.2

4 0 4

100.0 % 0.0 % 0.0 %

Exclusive Intent Granted Waited Total EX#Intent Requests

0.1 0.0 0.1

0.2 0.0 0.2

6 0 6

100.0 % 0.0 % 0.0 %

12.1

28.0

0.0

0.0

100.0 % 0.0 %

12.1

28.0

728 0 728

Exclusive Page Granted Waited Total EX#Page Requests

0.6 0.0 0.6

1.3 0.0 1.3

33 0 33

100.0 % 0.0 % 0.0 %

Update Page Granted Waited Total UP#Page Requests

0.7 0.0 0.7

1.5 0.0 1.5

38 1 39

97.4 % 2.6 %

583.3

1240.7

32258

0.0

0.0

0

583.3

1240.7

32258

100.0 % 0.0 % 43.6 %

402.3

927.2

24108

0.0

0.0

0

402.3

927.2

24108

100.0 % 0.0 % 32.6 %

279.0

642.9

16716

100.0 %

0.0

0.0

0

0.0 %

279.0

642.9

16716

22.6 %

Shared Intent Granted Waited Total SH#Intent Requests

Shared Page Granted Waited Total SH#Page Requests Exclusive Address Granted Waited Total EX#Address Requests Shared Address Granted Waited Total SH#Address Requests

0.0 % 0.1 %

1.0 %

0.1 %

www.books-shop.com

Last Page Locks on Heaps Granted 1.9 Waited 0.0 Total Last Pg Locks 1.9 4.4 114 0.2 % Deadlocks by Lock Deadlock Detection Deadlock Searches

per sec 0.0

4.4 0.0

per xact 0.0

114 0

count 0

100.0 % 0.0%

% of total n/a

0.0

0.0

0

n/a

0.0

0.0

0

n/a

2906.0 327.7 3233.7

75556 8520 84076

89.9 % 10.1 %

39.7 0.0

1033 0

n/a 0.0 %

Lock Promotions Data Cache Management Cache Statistics Summary (All Caches) Cache Search Summary 13) Total Cache Hits Total Cache Misses Total Cache Searches Cache Turnover Buffers Grabbed 14) Buffers Grabbed Dirty

1260.9 142.2 1403.1 17.2 0.0

Cache Strategy Summary Cached (LRU) Buffers 3464.3 Discarded (MRU) Buffers 0.0 Large I/O Usage Large I/Os Performed 1.4 Large I/Os Denied 12.1 Total Large I/O Requests 13.5 Large I/O Effectiveness Pages by Lrg I/O Cached 15) Pages by Lrg I/O Used Dirty Read Behavior Page Requests

100.8 59.5 0.0

7984.2 0.0

207589 0

100.0 % 0.0%

3.2 27.8 31.0

83 723 806

10.3 % 89.7 %

232.3 137.1

6040 3565

n/a 59.0 %

0.0

0

n/a

default data cache

16) Utilization

per sec 0.0 n/a

per xact 0.0 n/a

Cache Searches Cache Hits 17) Found in Wash 18) Cache Misses Total Cache Searches

1260.9 6.7 142.2 1403.1

2906.0 15.4 327.7 3233.7

75556 400 8520 84076

89.9 % 0.5 % 10.1 %

4.6 0.0

10.7 0.0

278 0

26.9 % 0.0,%

Pool Turnover 2 Kb Pool LRU Buffer Grab 19) Grabbed Dirty

count 0 n/a

% of total n/a 100.0 %

www.books-shop.com

16 Kb Pool LRU Buffer Grab Grabbed Dirty Total Cache Turnover

12.6 0.0 17.2

29.0 0.0 39.7

755 0 1033

73.1 % 0.0%

Buffer Wash Behavior Buffers Passed Clean Buffers Already in I/O Buffers Washed Dirty

57.3 0.0 7.9

132.1 0.0 18.2

3434 0 472

87.9 % 0.0% 12.1 %

Cache Strategy • Cached (LRU) Buffers Discarded (MRU) Buffers

3464.3 0.0

7984.2 0.0

207589 0

100.0 % 0.0%

1.4 12.1 13.5

3.2 27.8 31.0

83 723 806

10.3 % 89.7%

100.8 59.5

232.3 137.1

6040 3565

n/a 59.0 %

0.0

0.0

0

Large I/O Usage Large I/Os Performed 20) Large I/Os Denied Total Large I/O Requests Large I/O Detail 16 Kb Pool 21) Pages Cached Pages Used Dirty Read Behavior Page Requests

n/a

psychocache_l

Utilization

per sec 0.0 n/a

per xact 0.0 n/a

count 0 n/a

% of total n/a 0.0 %

Cache Searches Total Cache Searches

0.0 0.0

O.D 0.0

0 0

n/a

0.0 0.0

0.0 0.0

0 0

n/a

Pool Turnover Total Cache Turnover

Buffer Wash Behavior Statistics Not Available # No Buffers Entered Wash Section Yet Нет информации — ни один буферный блок еще не вошел в область очистки Cache Strategy Statistics Not Available # No Buffers Displaced Yet Нет информации — ни один буферный блок еще не был замещен Large I/O Usage

0.0

0.0

0

n/a

Large I/O Detail No Large Pool(s) In This Cache Dirty Read Behavior Page Requests 0.0

0.0

0

n/a

Procedure Cache Management per sec Procedure Requests 0.3

per xact 0.6

count 15

% of total n/a

www.books-shop.com

Procedure Reads from Disk Procedure Writes to Disk 22) Procedure Removals Memory Management Pages Allocated Pages Released

0.0 0.0 0.0 per sec 0.0 0.0

0.0 0.0 0.0

per xact 0.0 0.0

1 0 1

6.7 % 0.0 % n/a

count

1 1

% of total n/a n/a

count 2 0 2

% of total 100.0 % 0.0 % n/a

count 34 34

% of total n/a n/a

Recovery Management Checkpoints per sec per xact 23) # of Normal Checkpoints 0.0 0.1 # of Free Checkpoints 0.0 0.0 Total Checkpoints 0.0 0.1 Avg Time per Normal Chkpt 0 .00000 seconds Disk I/O Management Max Outstanding I/Os Server Engine 0

per sec n/a n/a

24) I/Os Delayed by Disk I/O Structures Server Config Limit Engine Config Limit Operating System Limit

n/a n/a n/a n/a

25) Total Requested Disk I/Os 129.9 26) Completed Disk I/O's Engine 0 143.4 27) Total Completed I/Os 143.4 Device Activity Detail /dev/rdsk/cOt2dOs4 cOt2dOs4 28) Reads 29) Writes Total I/Os

per sec 16.1 27.4 43.5

Device Semaphore Granted 30) Device Semaphore Waited /dev/rdsk/cOt2dOs5 cOt2dOs5

73.2 0.0

per xact n/a n/a n/a n/a n/a n/a

0 0 0 0

n/a n/a n/a n/a

299.4

7785

n/a

330.5 330.5

8593 8593

100.0 %

count 964 1641 2605

% of total 37.0 % 63,0 % 30.3 %

4388 0

100.0 % 0.0 %

per xact 37.1 63.1 100.2 168.8 0.0

Total I/Os

per sec 0.0 0.0

per xact 0.0 0.0

count 0 0

% of total n/a 0.0 %

/dev/rdsk/cOt2dOs6 cOt2dOs6 Reads Writes Total I/Os

per sec 0.9 97.9 98.8

per xact 2.2 225.6 227.7

count 56 5865 5921

% of total 0.9 % 99.1 % 68.8 %

5921 0

100.0 % 0.0 %

Device Semaphore Granted 98.8 Device Semaphore Waited 0.0

227 .7 0.0

www.books-shop.com

d_master master Reads Writes Total I/Os

per sec 0.2 1.1 1.3

Device Semaphore Granted Device Semaphore Waited

per xact 0.5 2.5 3.0

count 13 66 79

% of total 16.5 % 83.5 % 0.9%

1.3 0.0

3.0 0.0

79 0

100.0 % 0.0%

1.2 0.0

2.8 0.0

73 0

n/a 0.0%

Network I/O Management Total Network I/O Requests Network I/Os Delayed Total TDS Packets Receive Engine 0 Total TDS Packets Rec'd

per sec 0.2 0.2

per xact 0.4 0.4

count 11 11

% of total 100.0 %

Total Bytes Received per sec Engine 0 5.4 Total Bytes Rec'd 5.4 Avg Bytes Rec'd per Packet n/a

per xact 12.4 12.4 n/a

count 322 322 29

% of total 100.0 %

Total TDS Packets Sent Engine 0 Total TDS Packets Sent

per sec 1.1 1.1

per xact 2.5 2.5

count 64 64

% of total 100.0 %

Total Bytes Sent Engine 0 Total Bytes Sent

per sec 484.4 484.4

per xact 1116.4 1116.4

count 29026 29026

% of total 100.0 %

Avg Bytes Sent per Packet

n/a

n/a

453

n

/

n/a

a

t

(return status = 0 )

Рекомендации по конфигурированию кэш*буферов Приведенные ниже рекомендации следует рассматривать в качестве отправной точки при выборе распределения объектов баз данных вашего конкретного сервера по именованным кэшбуферам. Да лее перечислены объекты данных, которые должны быть назначены таким буферам в первую оче редь. 1. Таблица sysindexes и ее индекс — они активно используются в процессе работы сервера. 2. Таблица syslogs (т.е. журнал транзакций) — от ее помещения в именованный буфер особен но выиграют триггеры и множественные косвенные (deferred) операции. Чтение журнала транзакций производится при косвенном обновлении таблиц и работе сервера тиражиро вания Replication Server. 3. База данных tempdb. При частой обработке запросов, содержащих конструкции group by или order by и поэтому активно пользующихся временными таблицами, эту базу данных следует вынести в отдельный буфер. 4. Часто используемые таблицы. Их размещение в отдельном именованном буфере позволит избежать конкуренции за блокировки с ожиданием (spinlocks), поскольку каждый имено ванный буфер имеет отдельную хештаблицу и отдельный набор блокировок с ожиданием, контролирующих доступ к этой таблице. 5. Индексы, размещаемые отдельно от таблиц данных. К страницам индексов обычно обра щаются чаще, чем к страницам данных. Кроме того, каждая страница индекса обычно со держит больше записей, чем страница соответствующей таблицы данных. В SQL Server

www.books-shop.com

System 11 появилась возможность отделить кластеризованный индекс от страниц таблицы данных. 6. Небольшие таблицы просмотра (если к ним происходит много обращений). 7. Поля таблиц, содержащие текст или изображения (если к ним происходит много обращений). 8. Базы данных целиком (если к ним происходит много обращений, и сервер располагает достаточной оперативной памятью). 9. Таблицы sysobjects, syscolumns и sysprotects (если сервер обрабатывает много нерегламентиро" ванных (ad hoc) запросов, т.е. запросов, не входящих в хранимые процедуры). Оптимиза" тору запросов требуется составить план обработки каждого такого запроса. В процессе работы оптимизатор активно использует перечисленные выше системные таблицы. 10. Для большинства именованных кэш"буферов следует предусмотреть небольшую буферную область с блоками по 16 Кбайт. 11. Кэш"буферы, в которых не ожидается большого числа физических операций ввода"вывода, не должны содержать буферных областей с крупными блоками ввода"вывода. Не злоупотребляйте теорией Теоретически при настройке сервера нужно прежде всего выделить транзакции, наиболее часто на" правляемые приложениями на сервер, после чего выяснить, какие индексы требуются при их обра" ботке. Кроме того, теория учит настороженно относиться к соединениям таблиц и рекомендует прибегать к их денормализации для сокращения их числа. Эти операции действительно полезно осуществлять на практике, но больший интерес вызывает проблема ускорения конкретного приложения, ежедневно используемого конкретной компанией на протяжении многих лет. Вряд ли у вас есть возможность однажды денормализовать состоящую из миллиона записей основную таблицу вашей информационной системы. Вы не в состоянии создать множество новых индексов этой и других крупных таблиц вашего сервера, поскольку для этого по" требуется большое дополнительное дисковое пространство, и сервер будет недоступен для пользова" телей. Наконец, приложения часто изменяются и практически невозможно предсказать, какие именно запросы будут направляться на сервер в процессе модификации приложений. Хорошим примером соотношения теории производительности баз данных с реальностью являет" ся рекомендация использовать механизм обновления записей на месте (update in place). Теоретиче" ски при выполнении всех необходимых условий SQL Server сможет обновлять записи таблиц данных, не перемещая их на новое место. Это сделает ненужным множество дополнительных опера" ций. Обычно же, обновляя запись, сервер сначала удаляет ее, а затем вставляет модифицированную запись. Это может потребовать перестановки страниц данных. Перед оценкой возможности повышения производительности сервера, рассмотрим условия, по" зволяющие обновлять записи, сохраняя их на прежнем месте. Выполняя такую операцию, нельзя вносить изменения ни в один табличный индекс, использовать соединения таблиц, а в обновляемой таблице не может быть установлен триггер на модификацию данных. Можно ли такие таблицы ис" пользовать в ответственных приложениях? Много ли удастся сделать разработчикам реальных при" кладных систем без применения триггеров? Как будет обеспечиваться ссылочная целостность данных? Подобных вопросов можно поставить много. Главная польза от теории настройки произво" дительности сервера состоит в том, что она заставляет администратора сервера задуматься над ха" рактером процессов, происходящих внутри сервера. Не следует ожидать, что она снабдит вас магическим рецептом, позволяющим в один миг ускорить работу вашего сервера. Изучим теперь практические рекомендации, связанные с настройкой SQL Server. Знакомство с основными методами настройки облегчит переход к руководствам, посвященным этой проблеме. Эти руководства предполагают, что вы полностью контролируете процесс разработки приложений и действия пользователей. Многие из используемых вами приложений будут приобретены у незави" симых фирм"разработчиков. Хотя, с одной стороны, эти приложения будут лучшими в своей облас" ти, с другой стороны, они наверняка были разработаны для какой"то другой системы управления базами данных, и только позже адаптированы для SQL Server. В результате вам предстоит иметь дело с приложениями, чья логическая структура и фактическая реализация не учитывают особенно" сти SQL Server. Общие теоретические соображения о производительности SQL Server к ним приме" нить нельзя. Таким образом, у администратора базы данных окажется не так много возможностей повысить скорость работы сервера.

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Некоторые практические рекомендации Анализируя производительность сервера, следует отличать ее систематическое снижение от времен" ного — в определенные периоды суток, дни недели и месяца. Перед тем как взяться за борьбу с эпизо" дическими проблемами, определите, стоят ли эти проблемы времени, которое придется потратить на их осмысление, а тем более на устранение. Речь идет об организационном, а не техническом реше" нии — готова ли ваша компания вложить средства в оборудование, способное стабильно справляться с нагрузкой на протяжении всего бизнес"цикла? Или она предпочитает ограничиваться меньшими мощностями, требующими постоянного квалифицированного сопровождения? Реальный сервер очень трудно ускорить в равной степени для всех пользователей. Его оптимиза" ция начинается с определения группы пользователей, потребности которых вы готовы обеспечить в первую очередь. Также следует выделить пользователей, в которых ваша компания заинтересована меньше. Можно перевести последних на отдельный сервер, где их запросы смогут обрабатываться, не создавая помех всем остальным. Приступив к оптимизации сервера, прежде всего сделайте обрабатываемые транзакции как мож" но более короткими. Это позволит сократить взаимное блокирование различных серверных процес" сов. Взаимодействуя, они сэкономят время. Мы снова возвращаемся к проблеме разработки приложений, поскольку администратор сервера не имеет средств, позволяющих дробить направляе" мые на сервер транзакции. Для этого требуется пересмотреть архитектуру приложений. Кроме того, придется выяснить, какие именно операции выполняют с сервером различные пользователи. В чис" ле пользователей следует оставить только тех, кто действительно нуждается в высокой производите" льности сервера. Всех остальных перенесите на отдельный сервер, где они, не мешая другим, смогут генерировать свои квартальные отчеты и обрабатывать произвольные запросы. Пользователи основного сервера должны применять ограниченный набор коротких стандартных запросов, кото" рые необходимо оформить в виде хранимых процедур. Один сервер должен поддерживать только одно приложение, поскольку в противном случае его архитектуру не удастся оптимизировать с со" блюдением нередко противоречивых требований разных приложений. Кроме того, пользователи основного сервера не должны иметь непосредственного доступа к нему. Выбор пользовательских за" просов нужно ограничить стандартным набором обращений. Этот набор должен уже находиться на сервере в качестве хранимых процедур, а генерировать его будет основное приложение, использую" щее сервер. Для этого придется запретить доступ пользователей к программе isql и любым дру" гим приложениям, позволяющим направлять произвольные запросы непосредственно на основной сервер. В зависимости от традиций конкретной компании, можно ожидать, что подобное ограниче" ние на первых порах вызовет настоящий шок. Предположим, что вам удалось успешно решить все задачи первого этапа. Теперь можно перейти к установлению приоритетов оставшихся видов запросов. Выделим те из них, обработка которых должна быть оптимизирована в первую очередь. Скорее всего, пользователи не согласятся при" знать, что обработка одних запросов важнее для вашей компании, чем других. Тем не менее поста" райтесь максимально оптимизировать именно те транзакции, которые непосредственно приносят прибыль для вашего бизнеса (например ввод заказов). Различные вспомогательные операции (на" пример составление сводки поступивших за последние пять лет заказов, необходимой для очередно" го совещания начальства) не столь важны. Повышение быстродействия сервера требует контроля над операциями, которые предстоит ему выполнять. Эта задача неосуществима без сокращения за" просов, направляемых на сервер пользователями. Даже если вам удастся идеально настроить сервер на обработку наиболее важных запросов, пользователь, запустивший сложный и не очень важный запрос (например выборку данных о продажах за пятилетний период), способен полностью нару" шить нормальное функционирование сервера и фактически заблокировать обработку коротких основных транзакций. Разумнее всего вынести второстепенные запросы с OLTP"сервера на отдельный сервер поддерж" ки принятия решений. В зависимости от конкретных запросов пользователей вспомогательного сер" вера, можно создать на нем большее количество различных индексов. Они позволят ускорить обработку более сложных запросов, чем те, которые поступают на основной сервер, а также подо" брать оптимальную конфигурацию системных процессов и выработать регламент сопровождения DSS"сервера, обеспечивающий максимальную производительность этого сервера для большинства его пользователей (см. ниже). Выделив на основном сервере набор приоритетных запросов, можно приступить к созданию на" бора индексов, способного в максимальной степени "покрыть" как можно большую часть этих запро" сов (в идеале — все). Это будет примером того, как из теории настройки сервера действительно

www.books-shop.com

удается получить полезные практические рекомендации (см. ниже). Однако не следует создавать из" лишнее число индексов, поскольку их обновление может занять у сервера слишком много времени. Удачный набор индексов ускорит работу сервера за счет помещения их в кэш"буферы. При нали" чии достаточной оперативной памяти туда удастся поместить некластеризованные индексы таблиц. Это исключит необходимость физического ввода"вывода при обработке запросов, целиком покрыва" емых этими индексами. Кроме того, в соответствующий кэш"буфер также должна быть помещена бо" льшая часть из хранимых процедур, постоянно используемых сервером (лучше всего — все такие процедуры). Как уже отмечалось, для хранения процедур сервер использует определенную часть всей доступной ему оперативной памяти серверной машины, и установка дополнительной памяти благоприятно скажется на производительности сервера. Здесь мы сталкиваемся с проблемой плани" рования конфигурации сервера (см. главу 11). Несложным, но крайне важным и часто игнорируемым практическим приемом повышения быст" родействия сервера является архивация старых данных. Это периодически осуществляемый про" цесс поиска данных, уже не требующихся в работе OLTP"сервера и их переноса в архивные базы данных, находящиеся на вспомогательном сервере. В результате сокращаются размеры баз данных основного сервера, что значительно ускоряет как его работу, так и выполнение любых вспомогате" льных операций, включая резервирование и восстановление данных (см. главу 9). Описанные выше методы тривиальны, и их реализация не предоставит вам шанса снискать лав" ры выдающегося теоретика в области баз данных. Однако они позволяют достичь практического ре" зультата. Подобные меры безусловно окажутся непопулярными в компаниях, где пользователи привыкли в любое время использовать сервер как им заблагорассудится. Наибольшие проблемы бу" дут носить не технический, а политический (и, следовательно, личный) характер. Ваша задача — определить, что именно следует сделать в каждой конкретной ситуации, и затем реализовать все планы. Под аккомпанемент воображаемых фанфар вашу фирму посещает группа высокооплачи+ ваемых консультантов (кстати, получающих раза в четыре больше вашего). Они гаранти+ руют решение любых проблем, связанных с сервером. К сожалению, кто+то должен следить за работой основной системы, и поэтому вам не удается принять участие в дли+ тельном обеде+совещании, устроенном руководством в честь почетных гостей. По его завершении вам сообщают решение, принятое посетившими вас светилами мира баз данных: для повышения быстродействия вашего сервера как минимум на 100% удалите зеркальные копии всех устройств основного сервера и затем восстановите их с указани+ ем режима noserial (когда данные параллельно записываются в основную и зеркаль+ ную копии). Нет проблем. Вы удаляете все зеркальные копии (для гарантии целостности данных эти копии до сих пор работали в режиме serial , см. главу 8). Однако вы не за+ мечаете ускорения работы приложений. Успокаивая себя тем, что в данный момент сис+ тема работает не с полной загрузкой, вы приступаете к восстановлению зеркальных копий, не забывая задать режим noserial. Через неделю даже руководство признает, что работа сервера совершенно не ускорилась и зеркальное резервирование здесь аб+ солютно не при чем. Не позволяйте одурачить себя людям, которым и дела нет до ваших проблем, вне зави+ симости от того, сколько они берут за свои "рекомендации". Логика консультантов была безупречной, но она просто не имела ни малейшего отношения к делу. Вопросы, связан+ ные с производительностью приложений редко удается решить изменением режима зер+ калирования устройств. Помните, что только вы и ваши пользователи разбираетесь во всех тонкостях вашей системы, и только ваше дело и дело ваших пользователей зависят от должной работоспособности вашего сервера. Будьте готовы к тому, что поиск и устранение действительных причин медленной работы приложений потребует длитель+ ной напряженной работы. Кстати говоря, заезжие консультанты редко появляются на одном и том же месте дваж+ ды, поскольку у приглашавших их компаний просто не остается денег на то, чтобы за+ платить за повторный визит.

www.books-shop.com

Индексы и запросы Материал данного раздела не заменит других имеющихся руководств, содержащих подробное обсуж" дение особенностей работы оптимизатора запросов SQL Server и процесса определения состава ин" дексов, используемых сервером при выполнении каждого конкретного запроса. Все наиболее важные запросы на обработку таблиц базы данных должны покрываться индексами этих таблиц. Таким образом, каждая обрабатываемая таблица должна иметь подходящий набор не" кластеризованных индексов, включающих в себя все поля данных, необходимые для обработки за" просов. Некластеризованный индекс состоит из набора определенным образом упорядоченных страниц индекса. Они позволяют быстро найти индивидуальные записи таблицы, которые содержат необхо" димые данные в полях, являющихся ключевыми полями данного индекса. Обычно главная цель про" смотра некластеризованного индекса — найти указатели на требуемые записи основной таблицы. Однако некластеризованный индекс уже содержит полный упорядоченный набор значений полей таблицы, ставших ключевыми полями этого индекса. Этот набор, по сути, является кластеризован" ным индексом для всех вошедших в индекс полей таблицы. Поэтому при обработке покрываемых за" просов, т.е. запросов, выбирающих данные исключительно из ключевых полей таблицы, серверу не нужно обращаться к страницам самой таблицы данных, поскольку вся необходимая информация уже содержится в страницах табличного индекса. Кроме того, индекс содержит только данные ключе" вых полей таблицы. Поэтому по сравнению со страницами таблицы каждая страница индекса содер" жит больше записей данных. Это существенно сокращает объем ввода"вывода, необходимый для выполнения запроса. Таким образом, при обработке покрываемого запроса сервер может ограничи" ться выборкой данных из упорядоченной последовательности ключевых полей индекса, не интере" суясь ссылками на полные табличные записи, соответствующие каждому выбираемому значению ключа. Используя индексы, помните, что характер работы сервера определяется множеством причин. Даже при наличии индексов, идеально соответствующих запросу, оптимизатор запросов прибегнет к полному табличному просмотру, если ожидаемое количество выбираемых записей превысит 20% полного числа записей таблицы. Если, анализируя выбранные оптимизатором планы обработки за" просов, вы обнаружите полный табличный просмотр, установите долю выбираемых запросом запи" сей по отношению к числу записей таблицы. (Команда set showplan будет подробно рассматриваться в разделе "Встроенные средства анализа производительности SQL Server".) Если за" прос действительно выбирает слишком много записей, выясните, как этот запрос мог вообще по" пасть на OLTP"сервер. Все подобные транзакции должны обрабатываться исключительно на вспомогательном сервере поддержки принятия решений. Индексы приносят мало пользы при обра" ботке запросов, выбирающих значительную часть записей таблицы. Никакие индексы не помогут, если два пользователя одновременно стремятся внести изменения в одну и ту же страницу данных. Обычно это происходит, когда записи в таблице упорядочиваются согласно уникальным значениям одного из полей, например номер заказа. Предположим, что табли" ца имеет кластеризованный индекс по полю номера заказа и последовательному присвоению номе" ров новым заказам. Тогда пользователи, пытающиеся ввести новые заказы (крайне важная операция с точки зрения бизнеса), начинают конкурировать за доступ к нескольким последним страницам данных таблицы. Для решения проблемы присвойте каждой строке таблицы произвольный ключ, не имеющий никакого отношения к содержанию заказа или времени его поступления. Затем удалите прежний кластеризованный индекс и создайте новый, построенный на основе дополнительного ключевого поля со случайными значениями. В результате новые записи будут добавляться в случай" ные страницы данных, равномерно распределяемые по всей таблице, что значительно снизит риск блокировки обращений пользователей. С точки зрения производительности сервера, блокировка процесса — весьма дорогостоящее событие, поскольку блокированный процесс продолжает исполь" зовать системные ресурсы, не выполняя полезных действии. (Выдача команды sp_who позволяет установить, запросы каких пользователей заблокированы в данный момент.) Создание кластеризо" ванного индекса требует большого свободного дискового пространства. Если его не хватает, можно командой Ъср вывести данные таблицы в файл, произвести усечение таблицы и удаление прежнего индекса, затем создать новый индекс и загрузить данные обратно. К сожалению, подобный подход требует много времени. Существует еще одна проблема, нередко возникающая на практике. Планы выполнения храни" мых процедур создаются оптимизатором запросов только при первом вызове процедуры после пере" запуска сервера. Затем выработанный план хранится сервером и используется при каждом последующем выполнении процедуры. Именно исключение повторной компиляции хранимых

www.books-shop.com

процедур объясняет их большое значение для повышения быстродействия сервера. Однако повтор" ное следование заранее определенному плану выполнения хранимой процедуры неявно подразуме" вает, что эта процедура используется для обработки одного и того же набора данных. На практике выработанный оптимизатором план выполнения процедуры может оказаться неэффективным уже при следующем ее вызове. Рассмотрим, например, хранимую процедуру с параметром "номер_зака" за". Предположим, что каждый заказ представляет собой отдельную запись таблицы, имеющей мил" лион строк, а номер заказа является первичным ключом этой таблицы. Если запрос на выборку всех записей таблицы содержит номер заказа, превышающий указанное при вызове процедуры значение, при каждом вызове запрос будет возвращать определенное количество записей. Это количество за" висит от конкретных значений параметра и варьируется в широких пределах. Если приложение вы" звало процедуру в первый раз (т.е. при ее компиляции) с параметром номер_заказа = 999990, оптимизатор запросов выберет план выполнения, основанный на просмотре одного из имеющихся индексов (поскольку 10 выбираемых записей составляют ничтожный процент от полного числа за" писей). Однако следующий вызов процедуры может содержать параметр номер_заказа = 10. В этой ситуации, когда приложение фактически запрашивает выдачу практически всей таблицы, использо" вание индекса значительно снизит производительность сервера. Выборку большого количества за" писей удобнее производить путем полного просмотра таблицы. Ведь работа с индексом приведет к лишнему в этом случае просмотру всего дерева индекса для каждого значения ключа. Поэтому имей" те в виду, что план выполнения входящих в хранимую процедуру за просов, выдаваемый при ее от" ладке вручную, может отличаться от плана, выбранного оптимизатором запросов при первом вызове этой процедуры. Не забывайте сокращать виды запросов, которые приложения могут на" правлять на сервер. Запросы, осуществляющие выборку больших массивов данных, выносите на от" дельный сервер поддержки принятия решений. При создании хранимой процедуры можно указать параметр with recompile, означающий не" обходимость повторной компиляции процедуры при каждом ее вызове. Это лишает хранимую про" цедуру ее основного преимущества. Кроме того, практически очень трудно сопоставить потери от неудачно выбранного плана выполнения отдельных запросов с систематическими потерями време" ни на многократную повторную компиляцию хранимых процедур. Даже если выбор запросов строго ограничен и работа всех приложений осуществляется исключительно через хранимые процедуры, пользователи' все равно могут дезорганизовать нормальное функционирование сервера, вызвав одну из процедур с нестандартным набором параметров. Здесь мы снова сталкиваемся с проблемой, ско" рее относящейся к компетенции разработчика приложений, Чем администратора сервера. Часто возникает желание создать для каждой таблицы кластеризованный индекс по ее первично" му ключу. Подобный шаг может крайне негативно сказаться на производительности сервера. Рас" смотрим таблицу с номером заказа в качестве первичного ключа. Номер каждого следующего заказа превышает номер предыдущего, а записи таблицы с кластеризованным индексом упорядочены по значениям его первичного ключа. Поэтому все пользователи, стремящиеся ввести новые заказы, бу" дут конкурировать за блокировки доступа к последним нескольким страницам таблицы. В данной си" туации пользовательские запросы необходимо рассредоточить по всей таблице. Однако при обработке той же самой таблицы на сервере поддержки принятия решений создание кластеризован" ного индекса по номерам заказов может оказаться идеальным вариантом. Такой подход значительно ускорит выполнение запросов на выборку старых заказов с номерами, находящимися в определен" ном диапазоне. Наконец, при настройке производительности сервера следует помнить об основных принципах его работы. Перед выполнением запроса оптимизатор запросов SQL Server анализирует все подхо" дящие индексы и определяет, какой из них следует использовать (и не лучше ли прибегнуть к полно" му табличному просмотру). Оптимизатор запросов оценивает количество страниц базы данных, которые придется прочитать, используя индекс, и сравнивает его с аналогичным количеством, тре" бующемся при полном табличном просмотре. Важную роль здесь играет страница распределения значений индекса (distribution page), поддерживаемая для каждого индекса на сервере. Обратите внимание на необходимость регулярного обновления командами update statistics и sp_re" compile статистических данных о текущем распределении значений индексов всех таблиц всех баз данных сервера. Подчеркнем, что процедура sp_recompile выполняется по отношению к конкрет" ной таблице данных и вызывает повторную компиляцию всех хранимых процедур, содержащих об" ращения к этой таблице. Даже если содержимое таблицы данных не меняется в течение долгого времени, соответствующая страница распределения все равно должна периодически обновляться (и в том числе после каждой загрузки данных таблицы при ее восстановлении). Такое обновление стра" ниц распределения для всех таблиц сервера должно быть составной частью обычной последователь" ности операций поддержания работоспособности сервера. При этом страницы распределения

www.books-shop.com

активных таблиц должны обновляться наиболее часто. Администратор сервера не может проверить, устарели ли страницы распределения определенного индекса. Поэтому проще обновлять их цели" ком через определенный промежуток времени, чем пытаться запомнить, когда именно обновлялась страница распределения той или иной таблицы. Однако можно узнать, какие индексы вообще не имеют страниц распределения (другими словами, вообще не обрабатывались командой update statistics с момента создания, последнего усечения или загрузки таблицы или индекса). Для это" го достаточно ввести запрос select object_name(ld) from sysindexes where distribution >> 0 and indid > 0 and id > 100 в котором выбираются все записи таблицы sysindexes со значением поля distribution, равным нулю (что указывает на отсутствие у индекса страницы распределения). Условие id > 100 позволяет здесь исклю" чить системные таблицы. Для таблиц, вообще не имеющих кластеризованных индексов, выполняется условие indid = 0. Поскольку они также не имеют страниц распределения, их необходимо исключить из результатов запроса. Это достигается условием indid > 0. Изобретательные разработчики приложений могут сделать жизнь администратора серве+ ра сущим кошмаром. Обнаружив постепенное снижение производительности сервера, вы решаете удалить некоторые индексы и затем воссоздать их. Результат обескуражива+ ет: сервер начинает работать со скоростью черепахи. Пользователи начинают устраивать факельные шествия, а это верный признак того, что вам пора подыскивать новое место работы. Что же произошло? Оказывается, существует способ заставить сервер .исполь+ зовать при выполнении конкретного запроса строго определенный индекс. До появления System 11 это относилось к числу недокументированных возможностей SQL Server. В System 11 вы указываете имя требуемого индекса, а в предыдущих версиях сервера нужно было задать идентификатор (id) этого индекса. Естественно, удаление и воссозда+ ние индексов нарушило порядок их нумерации, в результате чего на сервер стали посту+ пать запросы, в явной форме требующие использование индекса, уже не имеющего отношения к делу. Остроумное использование недокументированных и нестандартных возможностей любой системы способно принести много хлопот. Имейте в виду, что SQL Server обладает богатым выбором подобных сюрпризов. Распределение сегментов баз данных по серверным устройствам При обсуждении методов повышения производительности сервера часто дискутируется проблема оп" тимизации размещения сегментов баз данных по различным устройствам сервера. Перед тем как при" ступать к реализации сложной схемы сегментации баз данных, ознакомимся со следующим примером. Представьте себе базу данных dbl, состоящую из трех сегментов. Первый представляет собой со" вмещенные сегменты system и default, второй является сегментом журнала транзакций (logsegment); тре" тий сегмент (ncindexes) определен пользователем и нужен для хранения некластеризованных индексов всех таблиц базы данных dbl. Предположим, что вам рекомендовали распределить каждый из этих сегментов по разным серверным устройствам. В идеале эти устройства должны быть под" ключены к разным дисковым контроллерам для обеспечения параллельного ввода"вывода каждого сегмента одновременно в несколько областей. Рассмотрев работу каждого из сегментов, докажем, что данная рекомендация крайне сомнительна. Начнем с сегмента журнала транзакций. Он пополняется новыми записями при каждом внесении изменений в базу данных вне зависимости от того, была ли соответствующая транзакция зафиксиро" вана или же произошел ее откат. В результате в журнал транзакций очень сложно записать инфор" мацию об операциях, модифицирующих состояние базы данных. Всем серверным процессам, вносящим изменения в базу данных, приходится дожидаться своей очереди на запись в последнюю страницу данных текущего экстента сегмента журнала транзакций. Администратор сервера в прин" ципе не способен устранить подобную проблему. Поэтому ему нет смысла пытаться распределить журнал транзакций по нескольким серверным устройствам, находящимся на разных контроллерах дисков. Все, что следует предпринять с сегментом журнала транзакций, — это определить размеры журнала транзакций и распределить ему необходимое пространство на серверных устройствах одно" го физического диска. Кстати говоря, тот факт, что размещение журнала транзакций на разных дис" ковых накопителях нежелательно, вовсе не означает, что его нельзя распределить по нескольким разделам одного диска.

www.books-shop.com

Теперь перейдем к сегменту ncindexes. Индексы, которые он содержит, потребуются при обработ" ке почти каждого запроса к соответствующим базам данных, причем при правильном выборе они бу" дут полностью покрывать большинство запросов. Имея индекс, покрывающий запрос, сервер может вообще не обращаться к страницам таблицы данных, поскольку всю необходимую информацию можно найти непосредственно на страницах индекса. Индекс содержит не все столбцы таблицы, а только те, которые являются индексным ключом. Поэтому каждая страница индекса содержит боль" ше записей, чем страница таблицы. Это заметно сокращает объем операций ввода"вывода, необхо" димых для обработки запроса. Если серверная машина располагает достаточной оперативной памятью и умеренным количеством табличных индексов, большая часть страниц данных сегмента ncindexes окажется в кэш"буфере сервера, и обращения к ним вообще не потребуют физического вво" да"вывода. Хотя таблицы данных, скорее всего, окажутся слишком крупными для того, чтобы помес" титься в имеющуюся память сервера, правильно созданные индексы будут содержать минимальное число столбцов этих таблиц. Этих столбцов хватит для покрытия наиболее важных запросов, кото" рые требуются большинству пользователей системы для обеспечения нужд компании. Если индексы удается разместить в кэш"буфере данных сервера, распределение дисковых копий страниц индексов по сегментам и серверным устройствам не будет иметь смысла. Осталось рассмотреть объединенный сегмент system/ default. Преимущества его распределения по нескольким устройствам будут видны только при частом использовании содержащихся в нем таблиц данных. Однако для любой активной таблицы данных нужно построить несколько индексов, обеспе" чивающих покрытие наиболее важных запросов. Созданные индексы помещаются в рассмотренный выше сегмент ndndexes и в итоге попадают в оперативную память сервера. Поэтому к таблицам дан" ных сегмента system/ default будет не слишком много обращений (во всяком случае, при обработке стандартных запросов). Таким образом, их распределение по устройствам также не будет играть особой роли. Этот пример показывает, что анализ структуры запросов, обрабатываемых сервером, и расшире" ние оперативной памяти серверной машины намного больше повысят производительность сервера, чем изощренная схема распределения сегментов по серверным устройствам. Кроме того, сложная схема сегментации баз данных затрудняет работу администратора сервера и его взаимодействие со своими коллегами. Появляется угроза возникновения ошибок при расшире" нии сегментов на новые серверные устройства. Даже распространение одного сегмента на неподхо" дящее устройство способно свести на нет все преимущества тщательно продуманной схемы распределения сегментов. Распределение таблицы по нескольким устройствам ЕСЛИ невозможно покрыть все запросы некластеризованными индексами, для каждой активно испо" льзуемой таблицы данных должен быть создан отдельный сегмент. Его необходимо распределить по нескольким физическим дискам, подключенным к разным дисковым контроллерам. Очень важно, чтобы обращения пользователей к данным таблице носили случайный характер и были рассредото" чены по всему пространству таблицы, но ни в коем случае не собраны в конце таблицы. Вероятно, по" требуется создать дополнительный ключ со случайно распределенными значениями, никак не связанными с содержанием других полей записей данных. Затем следует построить кластеризован" ный индекс по этому ключу. Подобный подход устранит в таблице "горячие точки", в которых заинте" ресованы пользователи, вынужденные конкурировать друг с другом за доступ к одним и тем же страницам данных. Архивация данных Архивация данных представляет собой наиболее эффективный и одновременно наиболее простой метод ускорения работы сервера. Этот метод в меньшей степени требует понимания технических ас" пектов функционирования сервера. Главное в нем — изменение взглядов и привычек пользователей. Архивация начинается с выделения баз данных, информация которых отражает повседневную деяте" льность конкретной компании (такие базы данных имеют стойкую тенденцию непрерывно увеличи" ваться с течением времени). Затем следует организовать периодический анализ содержимого этих баз данных, чтобы найти записи, которые старше определенного срока, и перенести их в отдельную базу данных. Архивация приносит ряд преимуществ. Во"первых, она предотвращает разрастание по" стоянно используемых баз данных, что облегчает создание их дампов, проведение dbcc"проверок и любых других процессов. Большие размеры баз данных требуют для выполнения этих операций слишком много времени. Во"вторых, сокращение размеров оперативных таблиц приведет и к

www.books-shop.com

сокращению их индексов. Эти индексы удастся поместить в имеющуюся оперативную память серве" ра. Даже полный табличный просмотр выполнится при меньших размерах таблицы заметно быстрее. Основа успешной архивации данных — регулярный перенос старой информации из оперативных баз данных. Подобный процесс должен осуществляться автоматически, чтобы занимать минимум времени у администратора сервера. Для его осуществления можно написать специальный ежеднев" но выполняемый командный файл, проверяющий все записи базы данных и отмечающий старые за" писи в специально созданном отдельном поле каждой записи. Другой способ — добавление к таблице специального поля, содержащего дату и время внесения записи в таблицу. Тогда проверка базы данных будет заключаться в сравнении соответствующим командным файлом этих данных с те" кущей датой. Архивация может учитывать не только возраст записей, но и текущие размеры базы данных. Планируя процесс архивации, следует проанализировать логическую и физическую органи" зацию основных баз данных вашего сервера. Выделив подлежащие архивации записи данных, их следует перенести в отдельную базу данных, создаваемую заново через каждый период архивации. Если архивация выполняется раз в квартал, то речь идет о базе архивных данных текущего квартала. В ней эти данные будут накапливаться вплоть до начала следующего квартала. Необходимо определить, требуется ли доступность абсолютно всех архивных данных. Если да, то можно ограничиться одной большой архивной базой данных, разме" ры которой будут постоянно увеличиваться. В противном случае следует установить определенное количество периодов архивации, в течение которых информация должна оставаться доступной, и сохранять на дисках сервера соответствующее число архивных баз данных. По завершении каждого периода архивации с сервера будет удаляться одна архивная база данных. Ее нужно перенести на сервер, предназначенный для хранения архивных данных (см. рис. 10.1). Таким образом, в конце каждого периода архивации вы либо создаете новую архивную базу дан" ных, либо продолжаете помещать архивные записи в непрерывно расширяющуюся единую архив" ную базу данных. В любом случае необходимо выполнить полный объем dbcc"проверок архивной базы данных, устранить все выявленные проблемы, а затем сохранить на ленту полный дамп базы данных. Наличие заведомо корректного дампа на магнитной ленте позволит контролировать только текущую информацию, находящуюся в небольшой оперативной базе данных. Размеры этой базы данных могут оказаться небольшими, что сэкономит вам немало сил и времени за счет упрощения ее восстановления после сбоев (см. главу 9). основной OLTP+сервер текущая архивная база данных с номером N Основной сервер должен содержать лишь текущую архивную базу данных с данными за последний период архивации. В нее помещается вся информация из оперативных баз данных, которая старше установленного срока. По окончании цикла архивации текущая архивная база данных переносится в сервер поддержки принятия решений, а на основном сервере создается новая архивная база данных. Сервер поддержки принятия решений содержит определенное число наиболее свежих архивных баз данных (4 таких базы в нашем примере). По завершении каждого цикла архивации наиболее старая из имеющихся архивных баз данных удаляется с этого сервера (при одновременном сохранении ее копии на ленте). На ее место записывается текущая архивная база данных, перенесенная с основного сервера. Возможен и другой подход, когда все данные хранятся в оперативных базах данных основного сервера. По окончании цикла архивации устаревшие записи переносятся в архивную базу данных, создаваемую непосредственно на сервере поддержки принятия решений.

сервер поддержки принятия решений

(N+1)+я архивная база данных

(N+2)+я архивная база данных (N+З)+я архивная база данных (N+4)+я архивная база данных

(N+5)+я архивная IL _база данных _ _ __

Рис. 10.1. Размещение архивных баз данных на основном OLTP*сервере и сервере поддержки принятия решений

www.books-shop.com

Однако архивация данных может потребовать внесения определенных изменений в существую" щие приложения, которые должны уметь идентифицировать запросы к архивным данным и направ" лять эти запросы в соответствующие базы данных. Кроме того, приложение должно знать, что самые старые архивные базы данных находятся на отдельном сервере поддержки принятия реше" ний. Поскольку доступ к любой базе данных сервера занимает время, необходимое серверу для обра" ботки текущих транзакций, на основном OLTP"сервере следует хранить минимальный объем архивных данных. В идеале — только одну архивную базу данных, заполняемую в течение текущего периода архивации. В заключение заметим, что хорошо организованная архивация данных вполне стоит затрат на внесение в приложения необходимых изменений. Сервер поддержки принятия решений Помимо обеспечения доступа к архивным данным, выделенный сервер поддержки принятия реше" ний выполняет еще одну крайне важную роль. Он — самое эффективное средство повышения быстро" действия основного OLTP"сервера. Для успешной настройки основного сервера прежде всего необходимо выделить транзакции, наиболее важные с точки зрения конкретного бизнеса, и максима" льно сократить их. Все остальные запросы следует вынести на отдельный сервер поддержки приня" тия решений. Это позволит изменить качество запросов, обрабатываемых основным сервером, и уменьшить их количество. Оптимизация основного сервера под выполнение ограниченного набора коротких запросов станет проще. Кроме того, наличие на сервере поддержки принятия решений ко" пии основной базы данных даст возможность ускорить обработку длинных запросов благодаря созда" нию расширенного набора табличных индексов, более разнообразного по сравнению с основным сервером. Находящаяся на сервере поддержки принятия решений копия основной базы данных OLTP"сер" вера должна регулярно обновляться. Определить нужный интервал обновления не всегда просто, поскольку некоторые пользователи вспомогательного сервера будут настаивать на необходимости свежих данных для их запросов. Однако слишком частое копирование данных отрицательно скажет" ся на производительности основного сервера, и здесь приоритет следует отдать пользователям глав" ной OLTP"системы. Пользователям сервера поддержки принятия решений следует объяснить, что им придется довольствоваться несколько устаревшими данными. Разгрузка основного сервера путем создания вспомогательного сервера поддержки принятия ре" шений также является эффективным способом повышения общей производительности системы. Этот способ требует определенной переработки используемых приложений. Например, если прило" жение позволяло пользователю анализировать содержание всех заказов, поступивших от клиентов и введенных в систему, то теперь оно направляет запросы в три разных места в зависимости от дан" ных, интересующих пользователя. (Предполагается, что все архивные данные, за исключением дан" ных текущего квартала, находятся на сервере поддержки принятия решений. Кроме того, туда каждую ночь загружаются с OLTP"сервера дампы данных о текущих заказах.) Конечно, можно разде" лить приложение на две части, обрабатывающих данные только какого"то одного сервера. Но это лишит пользователей одновременного доступа ко всем имеющимся данным и заставит их запускать каждое приложение дважды. Рассмотрим процесс синхронизации баз данных вспомогательного сервера поддержки принятия решений с оперативными базами данных OLTP"сервера. Самый простой способ синхронизации сер" веров — загрузка во вспомогательный сервер обычных дампов, сохраняемых на OLTP"сервере. При ежедневном создании дампов баз данных OLTP"сервера вспомогательный сервер будет отставать от основного не более чем на один день. Поскольку все равно нужно регулярно записывать дампы баз данных основного сервера, единственной дополнительной операцией здесь окажется загрузка полу" ченных дампов во вспомогательный сервер. Это одновременно станет эффективным способом про" верки корректности имеющихся дампов. Базы данных вспомогательного сервера не должны быть меньше баз данных основного сервера, поэтому при каждом расширении баз данных OLTP"сервера аналогичное дисковое пространство следует добавить в копии этих баз данных на сервере поддерж" ки принятия решений. По мере расширения баз данных основного сервера или увеличения их коли" чества процесс загрузки их дампов во вспомогательный сервер будет требовать все больше времени. Так как вспомогательный сервер во время загрузки дампов будет постоянно недоступен, его продук" тивное использование станет невозможным. Процесс копирования дампов можно ускорить, исполь" зуя диски вместо магнитной ленты. Однако необходимо помнить об ограничении размеров одного раздела файловой системы UNIX двумя гигабайтами. При работе с System 10/11 это ограничение можно обойти путем одновременного вывода дампа в несколько дисковых файлов. Это обеспечива" ется сервером архивации этих версий SQL Server. В любом случае, рано или поздно пользователи 19—2221

www.books-shop.com

окажутся разочарованы регулярными простоями сервера поддержки принятия решений, а его под" держание будет продолжать требовать заметных ресурсов. Когда загрузка во вспомогательный сервер всех дампов OLTP"сервера станет недопустимо мед" ленной, можно применить альтернативный подход. Полные дампы баз данных OLTP"сервера загру" жаются в сервер поддержки принятия решений только один раз, а дальнейшая синхронизация серверов осуществляется путем переноса дампов журналов транзакций. Конечно, и при таком спосо" бе действий вспомогательный сервер определенное время будет недоступен. Но этот период ока" жется намного короче, чем при загрузке полных дампов баз данных. Однако перенос дампов журнала транзакций требует большего внимания со стороны обслуживающего персонала, и при сбое загрузки одного из дампов потребуется загрузить полный дамп соответствующей базы данных. (Это сделает вспомогательный сервер на длительное время недоступным для пользователей, поско" льку при выполнении команд load database и load transaction база данных должна работать в однопользовательском режиме.) На первый взгляд может показаться, что загрузка дампов журна" лов транзакций действительно поддерживает синхронизацию вспомогательного сервера с основным в пределах одного цикла сохранения дампов журналов транзакций. Но на практике подобный под" ход оказывается не очень удобным, т.к. регулярная загрузка дампов журналов транзакций потребует периодического отключения пользователей от сервера. Итак, дампы журналов транзакций все рав" но удастся загрузить только по окончании рабочего дня (см. рис. 10.2). 1) полный дамп базы данных создается на основном сервере, затем копируется на вторую машину и загружается во вспомогательный сервер

2) на основной машине регулярно сохраняются дампы журнала повтора, которые немедленно копируются на машину сервера поддержки принятия решений

3} вспомогательный сервер периодически (например ежедневно) перезапускается для загрузки всех накопившихся журналов транзакций

Рис. 10.2. Синхронизация сервера поддержки принятия решений путем переноса дампов журналов транзакций Вне зависимости от способа синхронизации вспомогательного сервера с основным производите" льность сервера поддержки принятия решений оказывается ограниченной по следующей причине. Главной целью создания вспомогательного сервера поддержки принятия решений является удале" ние с основного OLTP"сервера любых необычных и сложных пользовательских запросов. Это огра" ничивает набор запросов, обрабатываемых основным сервером, и оптимизировать структуру индексов OLTP"сервера под обработку определенного круга запросов. В результате, полученный на" бор индексов оперативных баз данных основного сервера не будет иметь ничего общего со структу" рой индексов, требуемой для ускорения работы сервера поддержки принятия решений. Этот сервер предназначен для обработки сложных запросов, анализирующих большие объемы данных. Поэтому таблицы его баз данных должны иметь как можно больше различных индексов, включающих в себя большинство столбцов таблиц данных (или даже все имеющиеся столбцы). Наоборот, индексы OLTP"сервера следует делать компактными. Нужно включать в них столбцы, необходимые для по" крытия наиболее важных запросов. Это делается для сведения затрат времени OLTP"сервера на об" новление индексов к минимуму и размещения максимального числа строк индексов в памяти основной серверной машины. В результате после загрузки дампов баз данных основного сервера в сервер поддержки принятия решений автоматически во второй сервер переносится минимальный набор индексов OLTP"сервера, абсолютно неподходящий для обработки сложных уникальных за" просов. Единственный выход " продлить регулярный период недоступности второго сервера на время создания требуемых индексов, что еще сократит полезное время работы сервера поддержки принятия решений.

www.books-shop.com

Отметим, что синхронизация серверов посредством загрузки дампов журналов транзакций требу" ет, чтобы все синхронизируемые базы данных вторичного сервера были доступны пользователям только по чтению. Ведь любая модификация копий баз данных сделает невозможной загрузку после" дующих дампов журналов транзакций. В частности, подобное ограничение не позволяет изменять структуру индексов скопированных таблиц данных. Синхронизация путем загрузки полных дампов баз данных не требует переводить базы данных в режим доступа только по чтению. Однако загрузка каждого очередного дампа приведет к исчезнове" нию всех изменений, ранее внесенных в базы данных вторичного сервера. В частности, после за" грузки дампа будут полностью утрачены новые индексы таблиц данных. Наконец, оба рассмотренных подхода позволяют синхронизировать все базы данных, за исклю" чением базы данных master. В результате системные таблицы двух серверов не будут синхронизиро" ваны. Окажется невозможной и синхронизация учетных записей пользователей. Периодическая загрузка дампов базы данных master во вторичный сервер станет доступной только при полной иден" тичности названий и других характеристик всех устройств обоих серверов. Но это крайне трудно реализовать на практике. Итак, перенос полных дампов баз данных является наиболее простым способом синхронизации серверов, вполне применимым по отношению к не слишком большим базам данных. Однако подоб" ный подход не позволяет иметь на сервере поддержки принятия решений структуру индексов, от" личную от структуры индексов OLTP"сервера. Хотя для небольших баз данных необходимые индексы могут создаваться после каждой загрузки дампов баз данных во вторичный сервер. Увеличе" ние размеров дампов загружаемых баз данных постепенно сведет полезное время работы сервера поддержки принятия решений к минимуму. Придется решать, не следует ли перейти к использова" нию дампов журналов транзакций. Но это исключит возможность модификации индексов. Более эф" фективным способом поддержания вторичного сервера станет использование сервера тиражирования Replication Server. Он позволит автоматически иметь на сервере поддержки приня" тия решений копии любых таблиц OLTP"сервера, не ограничивая доступа пользователей к базам данных вторичного сервера. Он также даст возможность сконцентрировать ваши усилия на поддер" жание необходимой структуры индексов вторичного сервера. Полное воспроизведение на сервере поддержки принятия решений всех таблиц OLTP"сервера с помощью метода тиражирования дан" ных не слишком простое решение. Но оно имеет ряд преимуществ. В частности, подобный подход позволит отобразить на один сервер поддержки принятия решений данные нескольких OLTP"серве" ров. В результате пользователи этого сервера смогут выполнять перекрестные запросы, которые в принципе нельзя выполнить ни на одном отдельно взятом OLTP"сервере. Стандартный набор тестовых транзакций Хотя администратор сервера имеет разнообразные средства измерения истинной производительно" сти сервера, ему совсем непросто определить, насколько приемлемой выглядит скорость работы сер" вера с точки зрения пользователей. Пользователи чаще всего оценивают быстродействие сервера по времени, необходимому для выполнения определенных запросов. Их меньше всего интересует при" чина, по которой замедлилась обработка запросов. Можно сэкономить массу времени и нервов, если заранее оговорить с пользователями конкретный метод измерения производительности сервера до начала снижения скорости работы системы. Самый простой способ действий здесь — выделить стан" дартный набор транзакций, который в любой момент времени можно выполнить в приложении для определения реальной скорости работы сервера. Конечно, стандартные средства анализа производи" тельности (например SQL Monitor) выдадут более подробную и полную информацию. Но их запуск сам по себе замедлит работу сервера. Выполнение же стандартного набора тестовых транзакций по" зволяет измерить производительность сервера без каких"либо побочных эффектов. Рекомендуем проанализировать процесс выполнения такого набора еще до появления первых жалоб пользовате" лей. Ведь отсутствие информации о фактической производительности сервера не позволит вам пари" ровать утверждения пользователей о "медленной" работе их приложений. Таким образом, выделение стандартного набора обрабатываемых транзакций также является основой процесса настройки сервера. Поэтому в качестве тестовых лучше выбрать транзакции, определенные вами как наиболее важные с точки зрения бизнеса, поскольку весь процесс настрой" ки сервера в первую очередь направлен на ускорение выполнения именно этих транзакций. Выделить нужный класс транзакций можно не во всех прикладных информационных системах. Однако, если удастся это сделать, скорость обработки выбранных транзакций обязательно следует измерить в периоды минимального (или приемлемого) времени реакции сервера. Затем ее следует периодически замерять в различные периоды времени дня и квартального делового цикла

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

компании. После обновления сервера или модификации логической либо физической структуры баз данных нужно выполнить тот же набор транзакций в тестовой базе данных, чтобы на самом ран" нем этапе разработки выявить возникшие проблемы с производительностью новой системы. После начала эксплуатации новых приложений пользователями также рекомендуется замерить скорость обработки тестовых транзакций и сравнить с показателями для прежней системы. SQL Monitor SQL Monitor — это программный продукт компании Sybase, работающий совместно с SQL Server и вы" дающий в графической форме разнообразную информацию о производительности сервера. Эти све" дения исключительно полезны при анализе причин снижения его производительности. SQL Monitor версии 11.0.1 имеет ряд новых важных возможностей, существенно отличающих новую версию от всех предыдущих. SQL Monitor 11.0.1 может работать с любой версией SQL Server, начиная с 4.9.2 и кончая System 11. Однако некоторые наиболее интересные виды информации о характере использо" вания объектов баз данных и взаимодействии сервера с сетью выдаются только при мониторинге SQL Server System 10 и System 11. Естественно, данные о работе именованных кэш"буферов выдаются только при контроле производительности SQL Server System 11. Для совместимости с предыдущими версиями SQL Monitor 11.0.1 также поддерживает режим вы" дачи статистической информации о производительности сервера в файлы, которые можно исполь" зовать для последующего сравнения и анализа. Эта возможность оказывается очень полезной на практике, но ее применение усложняет процесс установки SQL Monitor. SQL Monitor состоит из двух компонентов: серверного модуля, работающего на одной машине с SQL Server для обеспечения возможности доступа к разделяемой области памяти сервера, и, клиент" ского модуля, который способен работать на любом компьютере. Главной задачей клиентского моду" ля SQL Monitor является чтение информации, накопленной серверным модулем, и ее представление пользователю в графической форме. При запуске SQL Monitor необходимо отменить проверку памяти сервера, выполняемую коман" дой dbcc memusage, поскольку эта команда существенно замедляет работу сервера. Для этого при запуске sqlmon (клиентского модуля SQL Monitor) необходимо указать параметр "nomem. Устанавливаемая по умолчанию конфигурация SQL Monitor обеспечивает одновременное под" ключение до пяти клиентских модулей к одному серверному модулю. Другими словами, к одному серверному модулю SQL Monitor может подключиться либо пять клиентских модулей с одним окном на каждом клиенте, либо один клиент с пятью открытыми окнами. Максимальное количество одно" временно открытых окон клиентов устанавливается при запуске серверного модуля SQL Monitor. Так, для поддержки 20 окон в командном файле запуска серверного модуля необходимо указать пара" метр "п2 0. При этом потребуется изменить адрес начала разделяемой области памяти сервера с по" мощью команды buildmaster и некоторых других действий. Эти действия ни в коем случае нельзя производить во время работы SQL Server. (Подробно о процессе расширения количества одновре" менно поддерживаемых клиентов см. в руководстве по серверному модулю SQL Monitor Server Supplement.) SQL Monitor имеет некоторые недостатки. Например, столбчатая диаграмма, показывающая ко" личество выполняемых операций ввода"вывода и другие характеристики работы серверных устройств, способна сообщать данные одновременно только по ограниченному числу устройств. Это неудобно при мониторинге крупного сервера с большим количеством серверных устройств. Кроме того, пользователь не может выбирать устройства, информация по которым будет включена в диа" грамму, а также переключаться между различными наборами устройств. Текстовая таблица, появля" ющаяся на экране одновременно с диаграммой, содержит перечень всех серверных устройств, но включает в себя лишь суммарное число операций ввода"вывода по каждому из них. Это особенно за" трудняет работу с большим сервером, на котором для повышения его производительности создано много серверных устройств, поддерживающих пользовательские сегменты баз данных. В этом слу" чае анализ работы всех имеющихся сегментов оказывается невозможным. SQL Monitor также не позволяет долгое время выдавать на экран динамику изменения показате" лей производительности. Он способен представить на экране данные за 60 последовательных интер" валов измерения производительности. В зависимости от выбранной продолжительности каждого интервала такая статистика может охватить довольно большой промежуток времени. Однако этот прием не дает возможности сопоставить текущие данные с показателями месячной или годовой дав" ности. Разумеется, изображения окон программы можно выдать на принтер, но тогда придется хра" нить наборы файлов или горы распечаток для оценки будущей производительности сервера. На практике администратору сервера часто приходится повторно просматривать данные, полученные

www.books-shop.com

в различные периоды делового цикла компании, а также сопоставлять информацию по одинаковым периодам последовательных деловых циклов, чтобы получить представление о реальной производи" тельности сервера. Поскольку запуск SQL Monitor приводит к некоторому замедлению работы сервера, перед нача" лом измерений необходимо определить величину этого замедления для конкретной аппаратной и программной платформы. Хороший способ измерения — выполнение стандартного набора тестовых транзакций (см. выше). Его можно применять как при наличии, так и при отсутствии SQL Monitor на серверной машине. Даже если клиентских модулей SQL Monitor нет, серверный модуль програм" мы продолжает свою работу, и его необходимо остановить отдельной командой. SQL Monitor позволяет выдавать на экран несколько, различных графических окон, каждое из ко" торых содержит информацию по определенному аспекту функционирования сервера. Главное окно SQL Monitor (Main Window) Здесь содержится перечень окон, поддерживаемых программой. В случае, если при запуске sglmon — клиентского модуля SQL Monitor — не был указан параметр "nomem, в этом окне также будет выдана круговая диаграмма использования памяти серверной машины. Кэш*буферы (Cache) В этом окне выдаются графики, характеризующие работу кэш"буферов процедур и данных. Контроли" руя количество физических и логических операций ввода"вывода в кэш"буфере данных, пользователь может определить, какую часть обращений к страницам данных сервер выполнит, используя страни" цы, уже находящиеся в буфере. Подобная статистика, полученная по буферу данных и буферу проце" дур, позволяет определить общий объем памяти, необходимый кэш"буферам сервера, и соотношение между кэш"буферами данных и процедур. Кэш*буфер данных, только для SQL Server System 11 (Data Cach) Окно сообщает количество операций физического и логического ввода"вывода по каждому из имено" ванных кэш"буферов, сконфигурированных на сервере. Дисковый ввод/вывод (Device I/O) Здесь находятся графики и сводные таблицы по текущему и полному количеству обращений к дискам. Они помогают оптимизировать распределение нагрузки ввода"вывода среди имеющихся серверных устройств. При анализе выдаваемой информации полезно использовать стандартную схему выбора названий серверных устройств по названиям соответствующих разделов физических дисков, поско" льку, наблюдая за скоростью обмена с серверными устройствами, следует знать, к какому дисковому контроллеру подключено каждое из этих устройств. Работа с сетью, только для SQL Server System 10 и 11 (Network Activity) В окне сообщается статистическая информация о сетевом вводе"выводе — размеры пакетов, объемы трафика и т.п. Блокировка доступа к объектам, только для SQL Server System 10 и 11 (Object Lock Status) Здесь выдается информация о блокировках доступа к таблицам данных, включая подробное распре" деление используемых типов блокировок, названия процессов, удерживающих блокировки и т.д. Ввод*вывод страниц объектов, только для SQL Server System 10 и 11 (Object Page I/O) Окно содержит информацию об интенсивности ввода"вывода страниц одной из таблиц данных серве" ра. Обратите внимание на эффективность SQL Monitor при составлении перечня наиболее часто ис" пользуемых таблиц сервера. Подобные сведения не выдаются процедурой sp_sysmon. Сводка данных о производительности (Performance Summar) Здесь представлена общая картина функционирования SQL Server — процент использования времени процессора, количество обрабатываемых транзакций в секунду, объем сетевого трафика, дискового ввода"вывода, а также интенсивность использования блокировок.

www.books-shop.com

Динамика показателей производительности (Performance Trend) В окне строятся непрерывные графики зависимости от времени показателей производительности сервера, выдаваемых в окне Performance Summary. Активность серверных процессов (Process Activit) Окно позволяет выбрать один или несколько серверных процессов и следить за использованием про" цессора и объемами ввода"вывода по каждому из процессов. Подробные данные о процессе (Process Detail) Окно содержит подробную информацию о выбранном серверном процессе. Список процессов (Process List) Окно содержит перечень всех имеющихся в данный момент серверных процессов с указанием их со" стояния. Очень похоже на выдачу серверной команды sp_who. Использование блокировок (Process Lock Activity) Окно выдает информацию об использовании блокировок выбранным вами серверным процессом. Использование хранимых процедур (Stored Procedure Activity) Окно содержит сведения о выполнении хранимых процедур и времени работы каждой процедуры. Обработка транзакций (Transaction Activity) В окне можно увидеть столбчатую диаграмму, показывающую количество обрабатываемых транзак" ций с распределением по различным типам транзакций. Видно, например, какую часть транзакций удается выполнить с использованием механизма обновления записей на месте (update in place). Встроенные средства анализа производительности SQL Server Ряд весьма полезных средств анализа и повышения производительности сервера встроены непосред" ственно в SQL Server. А. Системная хранимая процедура sp_monitor позволяет определить текущие значения раз" личных внутренних счетчиков сервера, отлеживающих ход его работы. На приведенной ниже распечатке представлены результаты двух последовательных вызовов процедуры sp_monitor. Для каждого параметра она выдает две величины: первая соответствует зна" чению счетчика, накопленному с момента последнего перезапуска сервера, а вторая (прй" 'веденная в скобках) показывает изменение этого значения с момента предыдущего вызова sp_monitor. Запуская эту процедуру через регулярные интервалы времени, администра" тор сервера может наглядно оценить скорость изменения интересующих его показателей. Например, при первом запуске sp_monitor полное количество операций записи на диск (total_write) после начала работы сервера составило 3472865, а при втором — 3472895(30). Параметр seconds (количество секунд, истекшее с момента предыдущего запуска sp_moni" tor) оказывается равным 28. Это означает, что за последние 28 секунд сервер выполнил 30 операций записи на диск, что примерно соответствует 1 операции в секунду. Запущенная в качестве cron"задачи, процедура sp_monitor может выполняться автомати" чески через заданный период времени с выдачей результатов в дисковый файл. Сравнивая такие файлы, накопленные за определенный период времени, легко определить произво" дительность сервера в прошлом и сравнить ее с текущими показателями. 1> sp_monitor 2> go _ last_run Apr 1 1995 1:20PM cpu_busy

18489(0)#0% packets_received 740556(10)

current_run Apr 1 1995 1:21PM io_busy _

74797(l)#2% packets_sent 1056871(10)

seconds 35 idle

_

1707049 (34) #97% packet_errors 0(0)

www.books-shop.com

total_read 2141401(2) (return status = 0)

1> sp_monitor 2> go last_run Apr 1 1995 1:21PM cpu_busy 18491(2)#7% packets_received 740562(6) total_read 2142628(1227) (return status = 0)

total_write 3472865(83)

total_errors 0(0)

#

connections 19377(1)

current_run seconds Apr 1 1995 1:22PM 28 io_busy idle 74801(4)#14% 1707072(23)#82% packets_sent packet_errors 1057195(324) 0(0) total_write total_errors connections 3472895(30) 0(0) 19378(1)

В. Чтобы узнать выбранные оптимизатором запросов планы обработки команд хранимой процедуры, командного файла на языке SQL либо отдельного SQL"предложения, перед их выполнением необходимо ввести команду set showplan. Учтите, что в выдаче этой команды не содержится информации о триггерах таблицы данных, которые могли быть активизированы в процессе выполнения запроса. План выполнения хранимой процедуры создается только при ее первом вызове и остается неизменным вплоть до повторной ком" пиляции процедуры. Поэтому анализ этого плана при отладке хранимой процедуры вруч" ную не позволяет выявить все проблемы, которые могут впоследствии замедлить ее обработку. Снижение производительности сервера может произойти из"за слишком большого количе" ства блокировок, приостанавливающих выполнение ряда серверных процессов. При обра" щении пользователя к определенной странице данных сервер устанавливает блокировку доступа к ней. Блокировка снимается только после завершения обработки этой страницы. Имейте в виду, что если запрос намеревается модифицировать более 200 страниц таблицы данных, сервер автоматически повышает уровень блокировки до табличного. В результате при установлении блокировки большой активно используемой таблицы множество пользо" вателей лишится доступа к ней на время ее модификации. Это обстоятельство еще раз подтверждает необходимость исключения объемных запросов для ускорения работы серве" ра. При обработке больших таблиц выборка одним запросом 200 страниц данных не явля" ется чем"то необыкновенным. Будьте готовы к тому, что каждая модификация такой таблицы будет блокировать всю таблицу целиком. Запросы, вызывающие установление об" ширных блокировок, требуют особого внимания при анализе производительности сервера. К сожалению, факт повышения уровня блокировки со страничного на табличный не отра" жается в выдаче команды set showplan. Его нельзя обнаружить при ручном анализе пла" нов выполнения запросов. C. Чтобы найти причины снижения быстродействия сервера, полезно выдать план выполне" ния запроса без фактического исполнения этого запроса. Для этого вместе с set showp" lan необходимо ввести команду set noexec. D. Можно также выдать информацию и о количестве операций ввода"вывода (как дискового, так и логического ввода"вывода в кэш"буфер), выполнив команды set statistics io on или set statistics time on. При необходимости обе команды могут использова" ться одновременно.

www.books-shop.com

Настройка сервера независимо от приложений В предыдущих разделах подробно рассматривались способы повышения производительности серве" ра — путем внесения изменений в пользовательские приложения и запросы, направляемые этими приложениями на сервер. Однако существуют методы, позволяющие ускорить работу сервера, не из" меняя существующие приложения. Разумеется, ни один из перечисленных ниже приемов не позволит устранить проблемы, вызванные несовершенством самих приложений, но, тем не менее, в опреде" ленных случаях такие приемы могут оказаться весьма полезными. Реальный эффект от их примене" ния зависит от конкретного сервера и его трудно предсказать заранее. Расширение оперативной памяти Большинство методов настройки сервера направлено на сокращение объемов физического ввода"вы" вода, необходимого для обработки запросов. Чем больше страниц базы данных удастся поместить в кэш"буфер сервера, тем выше оказывается быстродействие этой базы данных, поскольку обработка этих страниц не потребует обращений к дискам. Перед началом анализа конкретных механизмов за" медления сервера установите дополнительную память в серверную машину. При распределении имеющейся оперативной памяти определите соотношение размеров кэш"бу" феров данных и процедур. Первый из них используется для хранения страниц данных при их чте" нии и модификации, а второй — содержит хранимые процедуры. Расширение каждого из них повысит быстродействие сервера за счет увеличения процента попаданий, т.е. обращений сервера к страницам диска, которые удается выполнить с помощью страниц, уже находящихся в оперативной памяти сервера. Найти оптимальный баланс между размерами кэш"буфера данных и кэш"буфера про" цедур можно, наблюдая с помощью программы SQL Monitor за процентом успешных поисков в каж" дом буфере. Одновременно следует изменять соотношение, варьируя значение параметра конфигурации "procedure cache percent" процедурой sp_conf igure. По умолчанию этот параметр равен 20%. Другими словами, при запуске сервер распределяет кэш"буферу процедур 20% всего про" странства, оставшегося после резервирования памяти, необходимой для внутренних нужд самого сервера. Напомним, что не существует способа непосредственного задания размеров кэш"буфера данных. Этот буфер автоматически получает всю память, оставшуюся после создания кэш"буфера процедур. Обычно администратор сервера сначала распределяет серверу максимально возможный объем оперативной памяти серверной машины, а затем опытным путем настраивает оптимальное соотно" шение объемов кэш"буферов данных и процедур. Твердотельное запоминающее устройство Использование твердотельного запоминающего устройства (Solid State Device, SSD) является логиче" ским продолжением нашей предыдущей рекомендации расширить оперативную память серверной машины. Твердотельное устройство — это серверное устройство, расположенное не в разделе обыч" ного дискового накопителя, а на специальном полупроводниковом запоминающем устройстве, анало" гичном оперативной памяти серверной машины. В результате обращения к любым объектам данных, находящимся на нем, выполняются очень быстро. При помощи SQL Monitor нетрудно найти наибо" лее часто используемые серверные устройства и перенести их объекты на твердотельное устройство. Одним из самых активных объектов сервера является временная база данных tempdb, а также журна" лы транзакций тех баз данных сервера, к которым больше всего обращаются пользователи. Естест" венно, перемещение наиболее востребованных сегментов баз данных на твердотельное устройство позволит заметно повысить быстродействие всего сервера. Серверные устройства, поддерживаемый файлами операционной системы Серверным устройствам не следует назначать файлы операционной системы, поскольку ввод"вывод в такие файлы является буферизованным. Это может исключить восстановление баз данных устройст" ва (см. главу 8.) Однако после сбоя сервер не восстанавливает временную базу данных tempdb. Поэтому она — подходящий кандидат на размещение в серверном устройстве, поддерживаемом дисковым фай" лом. Буферизация ввода"вывода в это устройство на уровне операционной системы позволит уско" рить работу tempdb. Выгоднее использовать файловое серверное устройство, разместив на нем сегмент журнала транзакций tempdb. В любом случае, попробуйте перенести tempdb на файловое сер" верное устройство, а при отсутствии заметного эффекта верните ее на прежнее место. Поскольку со" держимое базы tempdb удаляется при каждом перезапуске сервера, ее намного проще переместить с одного устройства на другое, чем любую иную пользовательскую базу данных.

www.books-shop.com

Зеркальное отображение Зеркальное резервирование серверных устройств и расположенных на них баз данных — это один из наиболее эффективных способов обеспечения целостности данных и ускорения восстановления сер" вера после сбоев ( см. главу 8). Говоря о повышении производительности сервера, отметим, что при считывании с диска значительных объемов данных следует использовать возможность одновремен" ного чтения с главного и вторичного устройств зеркальной пары. В некоторых случаях это может ускорить выполнение подобных операций. Увеличение количества серверных устройств Довольно часто приходится решать, сколько разделов (и, соответственно, серверных устройств) сле" дует создавать на каждом дисковом накопителе. Можно привести, по крайней мере, три довода в по" льзу создания на каждом диске максимального количества разделов. Два из них связаны с необходимостью повышения производительности сервера и облегчения его настройки. A. Увеличение числа серверных устройств позволяет точнее определить, какие серверные устройства наиболее часто используются сервером. Для этого проще всего воспользоваться SQL Monitor. Однако, если найденное устройство занимает целый физический диск и со" держит множество различных баз данных, то полученная информация будет не слишком полезна при дальнейшем анализе ситуации. Создание большого числа компактных сервер" ных устройств позволит точнее локализовать источник возникновения проблем с произво" дительностью сервера. Операционная система Solaris ограничивает пределы создания разделов восемью на каждом физическом диске, причем два из этих разделов не могут быть использованы для размещения серверных устройств (см. главу 8). В итоге мы получа" ем шесть серверных устройств на диск. Это намного предпочтительнее, чем создание одно огромное устройство, охватывающее весь диск. B. SQL Server поддерживает в оперативной памяти отдельную очередь запросов к каждому серверному устройству. Сокращение количества серверных устройств приведет к тому, что в каждой из оставшихся очередей будет находиться больше запросов. Таким образом, боль" шее число устройств позволяет снизить потери времени на ожидание во внутренних оче" редях запросов сервера. С. Наконец, вопрос сокращения периода недоступности сервера при его восстановлении по" сле сбоев. Сбои диска обычно затрагивают лишь один его раздел, и чем крупнее он оказы" вается, тем больший объем данных будет теряться при каждом отдельном сбое. При наличии на дисковом накопителе шести разделов, повреждение одного блока диска приве" дет к утрате только одного раздела из шести. Однако, если весь этот диск представляет со" бой единое серверное устройство, все находящиеся на нем базы данных будут утрачены в результате любого локального сбоя диска. Влияние параметра vdevno на производительность SQL Server 4.9.2 и System 10 Содержание этого раздела не имеет отношения к SQL Server System 11. Анализируя очередь запросов к каждому серверному устройству, SQL Server постоянно просматривает список серверных устройств в ожидании выполнения текущих запросов ввода"вывода. Учтите, что список устройств обрабатыва" ется сервером в порядке возрастания виртуальных номеров устройств vdevno. Выполняя запрос вво" да"вывода на серверное устройство с vdevno = 10, сервер сможет убедиться в успешном выполнении этого запроса только после проверки состояния устройств с номерами от 0 до 9. Сервер быстрее определит освобождение устройства 1, чем устройства 10. Поэтому наиболее активным серверным устройствам следует назначать минимальные номера устройств. Однако, изменяя виртуальный номер устройства vdevno, его следует удалить, а затем повторно инициализировать командой disk init с указанием нового номера. Устройство, ранее обладавшее номером, теперь присвоенным первому устройству, также нужно удалить. Подобная операция потребует удаления всех сегментов баз данных, находившихся на обоих серверных устройствах. Настройку оптимального распределения номеров устройств разумнее всего осуществить в про" цессе первоначальной установки сервера или его восстановления после сбоя. Эта операция редко приводит к существенному выигрышу в производительности сервера и не окупает затраты сил и вре" мени на перестановку номеров существующих устройств. Сохраняется риск случайного нарушения структуры серверных устройств, приводящий к необходимости длительного и трудоемкого восста" новления сервера.

www.books-shop.com

Сокращение периодов недоступности сервера Повышение производительности сервера на первый взгляд кажется никак не связанным с увеличени" ем общего времени его нормальной работы. На самом деле это не так. Требуя ускорения работы сер" вера, пользователи неявно исходят из предположения, что сервер доступен для них в течение достаточного периода времени. Однако приходится регулярно выполнять на сервере ряд операций, приводящих к частичной или полной недоступности сервера, — производить dbcc"проверки, сохра" нять дампы баз данных и журналов транзакций, управлять зеркальным отображением серверных устройств и осуществлять другие действия, направленные на обеспечение нормальной работы серве" ра. Излишняя продолжительность периодов недоступности сервера означает снижение его реальной общей производительности. Поэтому меры, позволяющие сократить эти периоды, по своей важно" сти ничуть не уступают усилиям, направленным на повышение быстродействия сервера.

www.books-shop.com

Глава 11

Планирование конфигурации SQL Server Содержание Особенности различных версий SQL Server Информационная система в целом Отдельный сервер баз данных Реальный пример: информационная система в целом Реальный пример: отдельный сервер баз данных Планирование конфигурации глобальной информационной системы

www.books-shop.com

Введение Заблаговременным планированием конфигурации сервера почти всегда пренебрегают. Оценив раз" мер некоторых баз данных вашего будущего сервера и получив несколько общих рекомендаций от разработчиков приложений, вы отправляетесь заказывать новую серверную машину и... еще до ее по" лучения обнаруживаете, что заказанных дисков не хватит ни при каких обстоятельствах. Еще чаще вы получаете сервер от своего предшественника, вообще не имея возможности хоть как"то повлиять на его исходную конфигурацию. Однако вам несомненно представится шанс изменить ситуацию к лучшему. Конец квартала. Не выдержавший нагрузки сервер отказывается работать. Нужно срочно менять изношенные диски и контроллеры, одновременно расширив дисковое простран+ ство. На первый взгляд кажется, что вам на этот раз не повезло — ваш босс сел в углу вашего закутка и наблюдает за процессом восстановления сервера, пытаясь имитиро+ вать интерес к вашей персоне. Вы предпочитаете нахмуриться и молчать. Исчерпав свой запас ничего не значащих фраз, босс неожиданно поворачивается к вам и произносит: "Что вам нужно, чтобы такого больше не повторилось?" Не упустите этот момент. Поста+ райтесь дать как можно более конкретный и полный ответ. Напишите, каким вы собирае+ тесь сделать свой будущий сервер. Будьте всегда готовы с ходу перечислить боссу все, что вам необходимо. Очень часто простое упражнение по планированию конфигурации сервера превращается в бес" конечные попытки составить запутанный набор уравнений, позволяющий с точностью до килобай" та определить размеры каждой таблицы будущего сервера. Вы уверенно заказываете машину с дисками по 2 Гбайт, и на следующий же день основная таблица начинает экспоненциально увеличи" ваться в размерах одновременно с ростом всей вашей компании. Разумеется, в росте оборота компа" нии нет ничего плохого, но этот пример показывает, что параметры системы баз данных следует определять, исходя из реальных потребностей вашей компании. Необходимо учитывать поддержку приложений, резервных копий баз данных, систем разработки и тестирования новых приложений. Не следует забывать и о ресурсах, позволяющих обеспечить адекватное сопровождение всей систе: мы в целом. Особенности различных версий SQL Server Весь материал главы относится ко всем версиям SQL Server. Несмотря на появление в SQL Server System 10 и System 11 ряда важных возможностей, процесс построения конфигурации сервера не пре" терпел существенных изменений. Излишнее внимание к какой"то специфической особенности опре" деленной версии сервера приводит к тому, что действительно важные аспекты конфигурации оказались пропущенными. В этой главе не обсуждаются новые версии сервера. Однако рассматривае" мые здесь вопросы имеют решающее значение для стабильного функционирования всей вашей ин" формационной системы. После запуска сервера в промышленную эксплуатацию экономия дискового пространства потребует слишком много времени. Подобных трудностей можно избежать, правильно оценив действительные потребности еще на этапе планирования. Конечно, обдумывать конфигура" цию сервера не так интересно, как настраивать сложную структуру именованных кэш"буферов. Но это намного важнее — едва ли вам придется заниматься настройкой сервера, не способного вместить в себя все требующиеся базы данных. SQL Server System 11 требует (и способен задействовать с пользой для дела) больше оперативной памяти, чем предыдущие версии сервера. Поэтому при установке сервера System 11 необходимо пре" дусмотреть для серверной машины больший объем оперативной памяти, чем для SQL Server 4.9.2 и System 10. Информационная система в целом Многие представляют себе процесс планирования конфигурации как выбор конфигурации отдельно" го сервера. Однако рост баз данных приводит к появлению в составе конкретной информационной системы ряда вспомогательных серверов, и тогда потребуется определить общую конфигурацию всей системы. Система баз данных современной компании больше не может ограничиться одним серве" ром, работающим на одной серверной машине. В нее должны входить перечисленные ниже серверы. Администратор баз данных должен заранее продумать способ обеспечения постоянного обмена дан" ными между разными серверами одной системы. Возможно, для этого следует приобрести все сервер" ные машины у одного и того же производителя.

www.books-shop.com

Основной OLTP*сервер Основой поддержки повседневной деятельности вашей компании является сервер оперативной обра" ботки транзакций (On"Line Transaction Processing, OLTP). Его пропускная способность должна быть расчитана на одновременное выполнение всех функций, рассматриваемых в этой главе, но в первую очередь его следует оптимизировать для обработки множества небольших транзакций, сократив до минимума количество индексов каждой таблицы и т.д. Непосредственный доступ пользователей к этому серверу необходимо максимально ограничить, чтобы исключить направление на него громоз" дких нестандартных пользовательских запросов, способных нарушить его нормальную работу. Резервный сервер В зависимости от характера деятельности конкретной компании возможно, потребуется создать ре" зервный сервер, позволяющий за минимальное время взять на себя всю нагрузку отказавшего основ" ного сервера. Время, нужное для переключения, зависит от размеров убытков, которые понесет компания от простоя информационной системы. Также следует определить, необходимо ли поддер" живать на резервном сервере все базы данных основного сервера, или же вам можно ограничиться особо важными базами данных, позволяющими продолжить выполнение наиболее ответственных де" ловых операций до восстановления работоспособности основного сервера. В результате мощность резервного сервера должна либо равняться мощности основного сервера, либо уступать ему. На это существенно влияет и продолжительность времени, в течение которого резервный сервер должен выполнять обязанности основного. Если резервному серверу предстоит нести полную нагрузку в те" чение длительного срока, его конфигурация должна как можно точнее соответствовать конфигура" ции основного OLTP"сервера, включая количество и производительность процессоров, объем оперативной памяти и размеры дискового пространства. Напомним, что постоянная синхронизация баз данных основного и резервного сервера представляет собой весьма трудоемкий процесс. Сервер поддержки принятия решений (подготовки отчетов) Удовлетворительная производительность основного OLTP"сервера зависит от переноса всех громоз" дких или нестандартных запросов на отдельный сервер подготовки отчетов или, в более широком смысле, сервер поддержки принятия решений (Decision Support Server, DSS). Базы данных DSS"серве" ра должны быть синхронизированы с базами данных основного OLTP"сервера, например, путем регу" лярной загрузки дампов баз данных с основного сервера. Подобный способ синхронизации подойдет, если неизбежное отставание DSS"сервера от основного сервера окажется приемлемым для пользова" телей. При ежедневном сохранении дампов баз данных основного сервера отставание DSS"сервера составит около одного дня (поскольку в промежуток времени между дампами данные вторичного сер" вера не будут обновляться). Также можно перенести на вторичный сервер дампы журналов транзак" ций баз данных основного сервера с их немедленной загрузкой. Тогда время отставания DSS"сервера от OLTP"сервера удастся сократить до интервала между сохранением дампов журналов транзакций. Отметим, что оба способа требуют значительного дискового пространства как на основном, так и вторичном серверах. Такими же методами можно осуществить и синхронизацию резервного сервера, размер дискового пространства которого при этом должен совпадать с дисковым полем как основно" го, так и DSS"серверов. Сервер разработки приложений Главный OLTP"сервер информационной системы ни в коем случае не следует использовать для разра" ботки приложений или их тестирования. Подобная деятельность требует отдельного сервера, спо" собного вместить копии баз данных основного сервера. Разумеется, на сервере разработки приложений нет необходимости обеспечивать зеркальное резервирование этих баз данных, а также хранение их дампов и дампов журналов транзакций. Но этот сервер, тем не менее, должен распола" гать достаточным дисковым пространством, чтобы разместить все базы данных основного сервера, используемые будущими приложениями. Количества дисков должно хватать для размещения на сер" вере разработки приложений всех баз данных OLTP"сервера. Кроме того, дисковое поле сервера раз" работки приложений должно быть достаточным для размещения и создания больших файлов данных, необходимых при обмене данными с другими серверами. Также нужны логические дампы баз данных, которые крайне полезны в процессе разработки приложений из"за частой смены структу" ры баз данных и их отдельных объектов.

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Тестовый сервер В зависимости от сложности создаваемых приложений и индивидуальных особенностей конкрет" ной информационной системы, может понадобится отдельный сервер для тестирования новых приложений. Его возможности должны быть сопоставимы с возможностями сервера разработки приложений, поскольку на тестовом сервере также потребуется размещать копии баз данных основ" ного сервера. Такой сервер позволит тестировать приложения, не создавая помех разработчикам других приложений. DBCC*сервер С ростом размеров баз данных основного сервера, а также с распространением деловой активности вашей компании на другие части света и часовые пояса ваш сервер может отказаться выполнять необ" ходимые операции по сопровождению баз данных. Набор dbcc"проверок даже не слишком большой базы данных может растянуться на многие часы и это, не считая времени, нужного для исправления всех обнаруженных повреждений структур данных перед созданием корректного дампа базы данных. Ваша компания не имеет права закрыть доступ пользователей к основному серверу на столь длитель" ный промежуток времени. В результате придется создать еще один сервер, специально предназначен" ный для выполнения проверок баз данных. В число операций, осуществляемых на DBCC"сервере, входит загрузка старых дампов, выполнение dbcc"проверок, а также эксперименты с ускорением со" хранения логических дампов, одновременной записью дампа на несколько дисков и т.д. Сервер прежней версии Постоянное обновление версий серверов вашей информационной системы приведет к тому, что в ва" шем распоряжении не останется ни одной работоспособной копии прежней версии сервера. Это за" труднит загрузку старых дампов баз данных, созданных еще до начала перехода на новые версии. В зависимости. от частоты использования старых данных в деятельности вашей компании, а также установленного периода между сохранением полных дампов баз данных, необходимость загрузки ста" рых дампов сохраняется в течение года и более после завершения перехода на новую версию серве" ра. Для этой цели применяется специальная машина с прежней версией сервера, которая не должна быть слишком мощной. Ее можно попробовать установить на одной машине с DBCC"сервером. Одна" ко дисковое пространство такого сервера должно обеспечивать возможность загрузки самой боль" шой базы данных, данные из которой могут внезапно потребоваться. Сервер тиражирования Сервер тиражирования (Replication Server) должен работать на отдельной серверной машине. Безу" словно, этот программный продукт Sybase можно установить на любую из имеющихся серверных ма" шин, но это отрицательно отразится на производительности SQL"сервера, работающего на той же самой машине. Кроме того, перенос основных компонентов системы тиражирования на выделенный компьютер значительно облегчит ее сопровождение. Отметим, что в процессе своей работы сервер тиражирования создает в SQL Server базу данных, содержащую информацию о других серверах тира" жирования, подписках на определенные объекты данных и т.д. Поэтому на машине сервера тиражи" рования должна присутствовать копия SQL Server. Кроме того, сервер тиражирования предъявляет серьезные требования к производительности процессора машины, на которой он работает. Дисковое пространство этой машины должно быть достаточным для поддержки очередей хранимых транзак" ций. Они называются стабильными очередями запросов (stable queues) и способны накапливать все необходимые транзакции в течение допустимого срока отключения одного из узлов вашей информа" ционной системы. Естественно, увеличение максимально допустимого срока недоступности одного из узлов системы тиражирования потребует дополнительного дискового пространства на сервере ти" ражирования. Поддержка работоспособности информационной системы Определив состав и общую конфигурацию серверов вашей информационной системы, не забудьте об адекватной поддержке их нормальной работы. Эта сторона дела очень важна и к ней следует отнес" тись серьезно. Даже если вы до бесконечности будете разукрупнять вычислительные ресурсы и пе" рейдете на архитектуру клиент"сервер, вам все равно потребуются услуги персонала и сторонних организаций. Нормальная работа информационной системы невозможна без операторов, отвечаю" щих за сохранение дампов баз данных и файловых систем, а также за восстановление дампов и архи" вацию данных. Вам будет нужна помощь системных администраторов, отвечающих за установку, ремонт и модернизацию всех серверных машин вашей системы. Вам потребуются достаточные

www.books-shop.com

площади для размещения оборудования, адекватные системы электропитания, кондиционирования и охраны всех серверных машин, а также накопленных в них данных. Каждая из этих вспомогательных служб должна обеспечивать нужды системы в течение ее всех рабочих часов. Поскольку информаци" онная система компании должна расширяться по мере роста самой компании и постепенно перехо" дить на круглосуточный режим работы, планирование вспомогательных ресурсов является серьезной проблемой. Отдельный сервер баз данных При определении конфигурации серверов вашей информационной системы, каждый входящий в ее состав отдельный SQL Server потребует индивидуального подхода. В данном разделе основное внима" ние уделяется конфигурации дискового поля сервера, поскольку дисковое пространство — это то, чего всегда не хватает при эксплуатации сервера. Не стоит спорить о преимуществах той или иной процессорной архитектуры. Существует не так уж и много аппаратных платформ, обладающих доста" точной мощностью и надежностью для поддержки особо ответственных приложений. Не забывайте о том, что тесты производительности на деле оказываются бесполезными для оценки производитель" ности ваших приложений в информационной системе. Если в вопросах планирования конфигурации системы невыясненным остается только вопрос выбора процессорной архитектуры, значит вы оказа" лись впереди своих коллег. Ниже будут обсуждены различные аспекты конфигурации дискового про" странства в зависимости от особенностей конкретного сервера. Именно дисковое пространство в конечном итоге определяет производительность отдельного сервера. Конечно, всегда можно перей" ти на платформу с более быстрыми или многочисленными процессорами, если окажется, что серверу не хватает имеющихся процессорных ресурсов. Но и в этом случае придется решить все проблемы конфигурации дискового пространства, к рассмотрению которых мы и переходим. Базы данных Правильная оценка размеров будущих баз данных является программой"минимумом при планирова" нии конфигурации сервера. Нельзя недооценивать реальные размеры. При расширении уже сущест" вующего сервера скорость разрастания имеющихся баз данных можно оценить, исходя из темпов их роста в недавнем прошлом. Но планирование конфигурации совершенно нового сервера требует по" нимания структуры основных приложений, которые этот сервер будет поддерживать. Возможно, раз" работчики приложений смогут подсказать вам, сколько дисковой памяти потребуется для созданных ими систем. Однако может оказаться, что у разработчиков нет ни малейших представлений о масшта" бах информационных систем крупных компаний. Количество сегментов По всей видимости, именно здесь произошел просчет при первоначальном выборе конфигурации серверной машины. Вспомните пример, когда диски заказывались, исходя из общего объема всех баз данных. Распределение дискового пространства является непростым процессом (см. обсуждение про" цесса размещения сегментов баз данных на серверных устройствах в главе 8). Если приложению не" обходимо использовать сегменты, определяемые пользователем, то для повышения быстродействия сервера эти сегменты должны размещаться на серверных устройствах, не содержащих других сегмен" тов той же самой базы данных. В противном случае использование пользовательских сегментов теря" ет всякий смысл. В результате здесь потребуются дополнительные серверные устройства, для размещения которых необходимо добавить разделы в дисках и дисковые накопители. Кроме того, распределяя сегменты по дискам, следует учитывать, к каким контроллерам подключены эти диски. Например, поддерживающие сегмент журнала транзакций (logsegment) серверные устройства и их зеркальные копии должны находиться на физических дисках, подключенных к разным контролле" рам. На один физический диск (и, в идеале, на один контроллер) не стоит помещать более одного ак" тивного сегмента любой базы данных. Размещение на этом же диске активного сегмента другой базы данных (например, для ускорения работы сервера за счет распределения сегментов по устройствам) приведет лишь к снижению скорости ввода"вывода в каждый из сегментов. Таким образом, планируя конфигурацию сегментов, нужно учитывать требуемые размеры этих сегментов, необходимость их изоляции на разных устройствах, дисках и контроллерах, а также, какие сегменты и при каких обсто" ятельствах окажутся наиболее активными. К сожалению, большинство подобных факторов трудно оценить заранее. Поэтому дисковое пространство сервера должно позволять продолжение уточне" ния конфигурации сегментов уже после начала эксплуатации сервера. В итоге реально необходимое дисковое пространство значительно превосходит общие размеры баз данных на момент запуска сер" вера, тем более, с учетом неизбежного увеличения размеров сегментов баз данных.

www.books-shop.com

Зеркальные копии В зависимости от числа зеркально резервируемых баз данных, создание зеркальных копий сервер" ных устройств может потребовать весьма значительного дискового пространства (подробнее о прин" ципах зеркального резервирования дисковых устройств сервера см. главу 8). При этом необходимо принимать во внимание не только требуемую степень защиты данных, но и время, которое админист" ратор сервера готов выделить на сопровождение зеркальных копий устройств. Полное резервирова" ние всех сегментов всех баз данных сервера является наиболее простым и во многих отношениях предпочтительным вариантом. Если лишь часть серверных устройств имеет зеркальные копии, адми" нистратору сервера при каждом расширении базы данных на новое серверное устройство придется проверять, действительно ли отображается это устройство. Даже если база данных содержит абсо" лютно статичную информацию и ее легко восстановить по имеющемуся дампу, зеркальная копия этой базы данных будет полезна, т.к. она позволит серверу беспрепятственно продолжить работу, не" смотря на сбой серверного устройства. Размеры физических дисков При планировании конфигурации сервера определяются не только общие размеры дискового про" странства, необходимого для оптимального размещения текущих и будущих сегментов баз данных. Существенную роль играют здесь размеры и количество отдельных физических дисков. Поскольку требуется определенное число серверных устройств для размещения отдельных сегментов баз дан" ных и их зеркальных копий, серверу нужно соответствующее количество разделов (секций) дисков. Однако каждый физический диск может содержать ограниченное число разделов, причем оно не бу" дет меняться с увеличением общей емкости диска. Если конфигурацию сервера можно ограничить 10"ю дисковыми разделами, вам будет достатрчно двух дисковых накопителей. Выбор 4,2"гигабайтных дисков может привести к тому, что значительная часть пространства каждого серверного устройства останется свободной. Общий объем неиспользуемого пространства удваивается при создании полно" го набора зеркальных копий. Заказывая новый сервер, администратор должен договориться с руководством, утверждающим выбранную конфигурацию серверной машины. Необходимый объем дискового пространства следу" ет поделить на емкость одного диска и получить требуемое количество дисковых накопителей. Нуж" но иметь определенное минимальное число физических дисков и их разделов, чтобы обеспечить корректное распределение сегментов по серверным устройствам и создать их зеркальные копии. Оперативная память Объем оперативной памяти серверной машины прямо влияет на производительность сервера. У компьютера никогда не бывает слишком много памяти. Для определения нужного количества опе" ративной памяти следует исходить из числа и размеров объектов баз данных, которые будут одновре" менно находиться в кэш"буфере данных. Размеры буфера должны примерно соответствовать общему объему всех некластеризованных индексов, имеющихся на сервере. Если большая часть запросов пол" ностью покрывается (см. главу 10) подобными индексами, все необходимые для обработки запросов страницы данных окажутся загруженными в кэш"буфер. Это значительно ускорит работу сервера и со" кратит объемы физического ввода"вывода. Кроме того, некоторый объем памяти потребуется для размещения кэш"буфера процедур, содержащего хранимые процедуры. Лучше заказать серверную ма" шину с максимальным объемом оперативной памяти, поддерживаемым соответствующей аппаратной платформой. Расширение оперативной памяти — один из наиболее дешевых и эффективных спосо" бов повышения производительности сервера, не требующий перестройки структуры приложений и баз данных. Как отмечалось выше, SQL Server System 11 нуждается в большем количестве оперативной памя" ти, чем предыдущие версии сервера. System 11 использует дополнительную память как для своих внутренних потребностей, так и для размещения многочисленных именованных кэш"буферов, а так" же буферных областей с большими блоками ввода"вывода. Поэтому, планируя конфигурацию серве" ра System 11, предусмотрите значительно больше оперативной памяти, чем требовалось бы для SQL Server 4.9.2 или System 10. Размеры файловых систем Позволив системному администратору самому определить необходимый объем файловой системы серверной машины, вы получите файловое пространство, достаточное только на размещение опера" ционной системы и области подкачки. Не забывайте, что файловая система должна содержать все файлы SQL Server и любых других программных продуктов, установленных на серверной машине,

www.books-shop.com

включая рабочие копии, дистрибутивы, вспомогательные файлы, обеспечивающие поддержку раз" личных национальных алфавитов и т.д. Переход от одной версии сервера к другой потребует допол" нительного пространства файловой системы. Оно понадобится для размещения дистрибутивов новой версии (см. главу 13), причем нельзя удалить ни одного файла прежней версии вплоть до завер" шения установки и пробного периода эксплуатации нового сервера. При обновлении версии любого из связанных с сервером программных продуктов на файловых дисках точно так же придется дер" жать двойной набор всех необходимых файлов. Начиная планировать объема файловой системы, определите размеры фактически доступного файлового пространства на каждом диске. Это следует сделать, т.к. в зависимости от конкретной аппаратно"программной платформы вспомогательные структуры файловой системы, создаваемые при форматировании диска, могут занять до 10% его до" ступного объема. Выдача на диск дампов баз данных В соответствии со стандартной схемой защиты данных, на сервере должны регулярно сохраняться дампы баз данных. Обычно такие дампы сбрасываются прямо на магнитную ленту, но в некоторых случаях предпочтительнее записать их на диск. Во"первых, вывод дампа на диск выполняется быст" рее, чем его записи на ленту, что сокращает период недоступности базы данных для пользователей. Кроме того, сохранение дампов на диске позволит записать все дампы баз данных на одну ленту при создании дампа соответствующего раздела файловой системы стандартными средствами архивации операционной системы (см. главу 9). Наконец, при наличии нескольких серверов вам наверняка по" требуется организовать между ними обмен дампами, что также потребует дополнительного файлово" го пространства. Особенно большое пространство необходимо для записи на диск дампов баз данных. Здесь свободной области раздела файловой системы должно хватать для размещения копий всех баз данных, сохраняемых в виде дампов. Выдача на диск дампов журналов транзакций Регулярное сохранение дампов журналов транзакций различных баз данных сервера — необходимое условие для его восстановления после сбоев (см. главу 9). Дампы журналов транзакций лучше всего сохранять именно на диск. Это повысит частоту их сохранения и значительно сократит период за" медления работы сервера при сохранении каждого журнала. Частота создания дампов баз данных и журналов транзакций определяется планом защиты данных сервера от сбоев. Этот же план устанав" ливает и период времени, в течение которого сохраненные дампы должны храниться на дисках. По" мимо текущего набора дампов журналов повтора, созданных после сохранения последнего полного дампа баз данных сервера, на дисках может находиться и предыдущий комплект дампов. Он потре" буется в случае непригодности последнего полного дампа одной из баз данных. При подготовке пла" на защиты данных необходимо оценить размеры дампов журналов транзакций, создаваемых в разное время в течение квартала. Эти размеры могут варьироваться в течение дня, недели, месяца, квартала и года. Они нужны для определения объемов файлового пространства, необходимых для размещения всех дампов журналов транзакций, сохраняемых в соответствии с этим планом. Устройства вывода на магнитную ленту не слишком надежны и периодически оказываются нерабо" тоспособными. Поэтому зарезервируйте дисковое пространство, достаточное для накопления дам" пов журналов транзакций во время ремонта ленточных устройств. При пропуске одного или нескольких циклов сохранения дампа журналов транзакций их размер автоматически увеличивает" ся в несколько раз, и в файловой системе должно найтись свободное пространство подходящего объема. В подобной ситуации перед сохранением большого дампа журнала транзакций все прежние дампы можно перенести на другие серверные машины. Но и здесь вам потребуется свободное мес" то, только теперь — на дисках других машин. Наконец, оператор магнитных лент может не работать по выходным и праздникам. В этом случае тоже придется сохранять дампы на дисках в течение до" вольно длительных периодов времени.

www.books-shop.com

Многие месяцы дампы журналов транзакций вашего сервера сохранялись на диск каж+ дый час в течение всего рабочего дня, и за все это время у вас не возникло с ними ни единой проблемы. Внезапно размеры каждого дампа сначала удвоились, а затем и утро+ ились. Если раньше файловая система вмещала недельный запас дампов, то теперь она переполняется уже к концу вторых суток. Как оказалось, на сервере появилось новое приложение, которое при каждом запуске удаляет весь необходимый ему набор храни+ мых процедур, а затем создает их заново. Подобная операция резко увеличила объемы информации, регистрируемой в журналах транзакций. Разработчики приложения даже не подозревали о возможности возникновения подобной проблемы, поскольку соответству+ ющий компонент приложения они получили из другого подразделения вашей же собст+ венной компании. Теперь нужно срочно пересмотреть план защиты от сбоев. Недостаток дискового пространства может в любой момент внести самые существенные коррективы в ваши расчеты, даже если речь идет о вспомогательной файловой области, непосредст+ венно не используемой для размещения объектов баз данных. Настройка сервера После запуска сервера вам рано или поздно придется модифицировать существующие индексы и со" здавать новые. Подобные действия часто выполняются в процессе настройки производительности сервера. Планируя конфигурацию сервера, учтите, что для создания нового кластеризованного ин" декса таблицы данных к базе данных, содержащей эту таблицу, необходимо добавить дополнительное дисковое пространство. Его размеры должны составить приблизительно 120% от размера самой таб" лицы. Ваш сервер так и не достиг ожидаемой производительности. Как оказалось, разработчи+ ки первоначальной структуры базы данных решили не создавать кластеризованного ин+ декса к одной из самых крупных таблиц сервера. С течением времени эта, а также остальные таблицы сервера увеличивались в размерах и в конце концов заполнили прак+ тически все имеющееся пространство. Вы оказываетесь перед трудной дилеммой: с од+ ной стороны, для повышения производительности сервера необходимо как можно скорее создать кластеризованный индекс злополучной таблицы. С другой стороны, у вас нет достаточного дискового пространства. Однако добавление к серверу новых дисков исключительно для создания индекса означает, что по завершении этой операции они окажутся практически пустыми. Ведь эта операция фактически сводится к построению полной копии новой таблицы, записи которой упорядочиваются нужным образом, и уда+ лению ее оригинала. Заметим, что в вашей машине вообще не осталось места для под+ ключения новых дисков или контроллеров. Может быть, сейчас вы поймете важность заблаговременного планирования конфигурации сервера. Таким образом, добавление дополнительных индексов таблиц и повторное создание существую" щих индексов для обновления их структуры может потребовать расширения сегментов баз данных, содержащих эти индексы. Это нужно учитывать при оценке необходимого объема дискового про" странства сервера. При недостаточном свободном пространстве вы не сможете заняться настрой" кой сервера. Обмен данными с другими системами Эксплуатируя сервер, вам потребуется регулярно импортировать и экспортировать данные для обме" на ими с другими серверами или информационными системами. Придется также часто выгружать значительные объемы данных в дисковые файлы и загружать данные из подобных файлов. Вне зави" симости от того, были ли файлы данных созданы на этом же сервере, или перенесены из других сис" тем, их размещение потребует соответствующего пространства файловой системы. Например, при ежедневном импорте 10"мегабайтного файла данных недельный запас его копий займет 70 Мбайт файлового пространства. Кроме того, следует учесть непредвиденные обстоятельства — например, неработоспособность компьютерной сети компании в течение целого дня. Придется ли в подобной ситуации сохранять дисковые файлы на более длительный срок? Если да, то это необходимо преду" смотреть еще на этапе планирования конфигурации сервера.

www.books-shop.com

Запись на диск логических дампов При разработке конфигурации сервера не забудьте об обязательном периодическом извлечении определенных объектов данных из полных дампов баз данных. В силу различных причин подобную операцию часто требуется выполнить без непосредственной загрузки прежнего дампа в основную копию базы данных. Например, если из дампа месячной давности нужно извлечь 10 записей некото" рой пользовательской таблицы, этот дамп прямо в соответствующую базу данных не загрузится, по" скольку это приведет к утрате всех изменений, внесенных за последний месяц. Любые дампы баз данных, создаваемые непосредственно из SQL Server, являются физическими дампами — т.е. про" стыми копиями всей информации, содержащейся в базе данных или журнале транзакций. Когда (обратите внимание, что мы не употребляем здесь слова "если") вы будете извлекать объект данных из старого дампа всей базы данных, вам потребуется выполнить ряд сложных операций, сводящих" ся к загрузке полного дампа на подходящее свободное место основного или любого вспомогательно" го сервера. Затем можно будет получить требуемый объект. Для этого нужно дисковое пространство, как минимум соответствующее размерам полной копии самой крупной из всех имею" щихся баз данных. Загрузка этой базы может растянуться на длительное время. Альтернативой мо" жет быть регулярное сохранение логических дампов баз данных сервера. Эти дампы представляют собой дисковый файл операционной системы, содержащий логические определения всех объектов базы данных в форме команд сервера, необходимых для их создания, и дампы содержимого этих объектов. Логический дамп позволяет воссоздать объекты базы данных на том же или любом дру" гом сервере, вне зависимости от версии второго сервера и аппаратной платформы, на которой он работает. Это объясняется тем, что логические дампы определяют структуру базы данных на языке Transact"SQL. Их поддержка требует файлового пространства, размеры которого зависят от вы" бранного плана их создания. (Они могут создаваться, например, еженедельно либо после каждой су" щественной модификации базы данных.) Как отмечалось ранее, SQL Server не поддерживает создание логических дампов баз данных. Для этого нужно программное обеспечение независимых фирм"разработчиков — например, программа SQL BackTrack компании DataTools (подробности см. в главе 9). Синхронизация серверов Синхронизация различных серверов информационной системы может потребовать переноса с од" ной машины на другую файлов весьма значительных размеров. Например, база данных резервного сервера может синхронизироваться с основной копией путем переноса дампов журналов транзакций с основного сервера на резервный. При этом на обеих серверных машинах понадобится файловое пространство, достаточное для хранения дампов журналов транзакций за максимальный интервал времени между двумя последовательными операциями переноса дампов. Синхронизацию небольших баз данных проще осуществлять путем переноса их полных дампов. Ограничения, накладываемые серверной машиной При планировании структуры сервера необходимо принимать во внимание ограничения, присущие архитектуре самой серверной машины (например, наибольшее число процессоров и объем оператив" ной памяти). Однако основной момент — дисковая память, на размеры и конфигурацию которой так" же накладываются определенные ограничения. Во"первых, следует выяснить, какое максимальное количество дисковых контроллеров может быть установлено в системе. Эта величина в сочетании с допустимым числом дисков, подключаемых к одному контроллеру без насыщения производительно" сти последнего, и укажет максимальный объем дискового пространства. Кроме того, удостоверьтесь, что имеется место для размещения нужного количества дисков. Возможно, для установки всех зака" занных дисков потребуются дополнительные дисковые стойки. Сервер тиражирования Запланированную установку сервера тиражирования Replication Server на одну из серверных машин вашей системы также следует учесть на этапе определения конфигурации этой машины. Сервер тира" жирования создает так называемые стабильные очереди запросов (stable queues), используемые для хранения транзакций, подлежащих передаче из основной базы данных для воспроизведения на всех ее копиях. Подобно серверным устройствам SQL Server, очереди тиражируемых запросов размеща" ются сервером тиражирования в одном или нескольких физических разделов диска с небуферизован" ным доступом. Планируя структуру сервера тиражирования, оцените требуемый размер очередей запросов. Этот размер зависит прежде всего от промежутка времени, в течение которого сервер ти" ражирования должен нормально функционировать при отсутствии связи с удаленными компонента" ми системы тиражирования транзакций (например, из"за сетевых сбоев). В больших

www.books-shop.com

информационных системах, работающих в режиме промышленной эксплуатации, размеры стабиль" ных очередей запросов сервера тиражирования могут достигать Гбайтных размеров. Кроме того, уч" тите, что хотя текущая версия Sybase Replication Server не поддерживает зеркального резервирования очередей транзакций, подобная возможность может появиться в одной из последующих версий этого сервера. Поэтому лучше заранее удвоить объем дискового пространства, выделяемого для размеще" ния очередей этого сервера. Ленточные накопители серверной машины Проблема выбора конфигурации накопителей на магнитной ленте только кажется второстепенной. Однако параметры этих устройств, и в первую очередь их максимальная емкость, оказывают сущест" венное влияние на эксплуатацию всей системы баз данных. Если дампы всех баз данных сервера не помещаются на один том (кассету, картридж) магнитной ленты, нужно вынуть заполненную ленту из устройства и вставить на освободившееся место следующую. Несмотря на простоту операции, она мо" жет стать источником ошибок, т.к. для этого требуется вмешательство персонала. Аналогичная проб" лема возникнет и при сохранении дампа раздела файловой системы, содержащего ранее записанные дампы баз данных. Возможность сохранения и загрузки дампов без смены лент позволит сэкономить немало сил и нервов. Большое значение имеет скорость записи на ленту, определяющая продолжительность создания дампов. При круглосуточной работе сервера интервалы времени, отведенные на сохранение еже" дневных дампов баз данных и файловых систем могут оказаться недостаточными для их записи на ленту (или даже на диски). Это заставит вас пересмотреть схему резервирования данных. Таким об" разом, на этапе планирования сервера необходимо определить как требуемую емкость, так и ско" рость обмена с накопителями на магнитной ленте. Реальный пример: информационная система в целом Для иллюстрации приведенных соображений рассмотрим реальную информационную систему и один из ее серверов. Это типичная система, которая может использоваться в режиме промышленной эксплуатации. Обсуждение начнем с планирования конфигурации минимальной системы баз данных, в которой для обработки OLTP"запросов достаточно одного главного сервера. Мы изучим основные функции, выполняемые каждым сервером этой системы, а также требуемый объем дискового про" странства и необходимую производительность серверной машины. Затем перейдем к подробному описанию конфигурации главного сервера, выполняющего оперативную обработку транзакций. Основной OLTP+сервер Важнейшая задача основного OLTP"сервера информационной системы — обеспечивать работоспо" собность основных приложений, имеющих особое значение для повседневной деятельности компа" нии. Именно на нем в течение дня выполняется большая часть деловых операций, и именно сюда попадают данные о всей деятельности компании. Хотя подавляющее большинство пользователей ин" формационной системы используют в своей работе OLTP"сервер, ни одному из них не следует разре" шать направлять на этот сервер запросы, не относящиеся к числу стандартных транзакций, необходимых для осуществления деловых операций. Всю структуру OLTP"сервера, и в первую оче" редь индексы таблиц данных, нужно оптимизировать для максимального ускорения обработки фик" сированного набора коротких транзакций. Быстрое выполнение этих транзакций сведет к минимуму блокирование серверных процессов, что позволит серверу достичь наивысшей производительности. Основной OLTP"сервер рассматриваемой системы поддерживает 17 баз данных, размещенных на дисковом пространстве следующим образом. Общий объем логических дисковых устройств сервера составляет 12 Гбайт, из которых 8 распределены базам данных, а 4 — свободны для обеспечения воз" можности увеличения размеров баз данных в будущем. На первый взгляд 4 Гбайт резервного про" странства кажутся весьма значительными. Однако это не так, если принять во внимание количество сегментов самой большой базы данных и необходимость размещения каждого сегмента на сервер" ном устройстве, подключенном к отдельному контроллеру. Кроме того, при размерах основной базы данных, уже достигших 5 Гбайт и продолжающих расширяться за счет добавления новых 100"мегабайтных порций дискового пространства, свободные 4 Гбайт не выглядят солидным резер" вом. Теперь учтем необходимость зеркального резервирования сегментов этой базы данных (в на" шем примере зеркальное резервирование охватывает все серверные устройства). Не забудем и о том, что одна четверть всех дисков серверной машины отведена для нужд операционной системы и поддержки файловых систем. В целом к машине основного OLTP"сервера подключены 16 дисковых накопителей по 2,4 Гбайт каждый, причем каждые 4 диска подсоединены к одному контролеру. Из

www.books-shop.com

этих 4"х один используется для размещений файловых систем. Это позволяет распределять сегмен" ты баз данных по всем имеющимся контроллерам (если подключить диски файловых систем к одно" му контроллеру, то он не сможет поддерживать ни одного серверного устройства). После разбиения дисков на разделы и форматирования разделов файловых систем, общее дисковое поле серверной машины составляет 32 Гбайт, из которых 8 Гбайт (одна четверть) занята файловыми системами. Са" мая крупная файловая система используется для хранения дампов журналов транзакций и баз дан" ных. Оставшиеся 24 Гбайт непосредственно распределены серверу, причем 12 Гбайт отданы серверным устройствам, а другие 12 — зеркальным копиям. Зеркальное отображение устройств ра" зумнее всего организовывать на уровне физических дисков целиком. При этом одни диски будут полностью заняты серверными устройствами, а другие — их зеркальными копиями. Кроме дискового пространства серверной машине основного OLTP"сервера также требуется до" статочное количество центральных процессоров, оперативной памяти, сетевых адаптеров и других устройств для обеспечения своевременной обработки запросов при одновременной работе опреде" ленного числа пользователей. Способ узнать, сколько нужно дискового пространства, подробнее рассматривается ниже. Сейчас обратим внимание на предварительную оценку количества пользова" телей, которые будут одновременно работать с сервером. Заранее следует также зарезервировать объ" ем оперативной памяти для поддержки требуемого числа параллельных пользовательских сеансов работы, а также кэш"буферов данных и процедур, позволяющих разместить в памяти все необходимые объекты базы данных. Вам также потребуется определить хотя бы порядок величины будущего потока транзакций (количества транзакций, поступающих каждую секунду) и выяснить, какой должна быть производительность процессоров, чтобы они справились с ожидаемой нагрузкой. Резервный сервер Серверная машина резервного сервера должна обладать оперативной памятью и процессорными ре" сурсами, идентичными основной серверной машине. Не будем употреблять термин "горячее резерви" рование", поскольку сервер, действительно находящийся в "горячем резерве", должен быть способен самостоятельно определить факт сбоя основного сервера и автоматически взять на себя нагрузку. При этом период переключения должен пройти незаметно, а этого непросто добиться на практике. Реальнее заставить резервную машину обеспечивать прежнюю производительность информацион" ной системы в течение длительного периода времени. Для этого достаточно сделать аппаратные воз" можности резервной машины идентичными возможностям компьютера основного сервера. Вне зависимости от того, в насколько "теплом" состоянии находится резервный сервер, его серверная ма" шина нуждается в дисковом пространстве, равном емкости дисков основного сервера. Это объясняет" ся тем, что на резервной машине требуется поддерживать точные копии всех баз данных главного OLTP"сервера, а также воспроизводить схему зеркалирования устройств главного сервера. Кроме того, поскольку все функции отказавшего сервера лягут на резервную систему, в ней следует преду" смотреть эквивалентное количество и емкость разделов файловой системы, синхронизацию их со" держимого с основным сервером и т.д. Попытка сократить аппаратные ресурсы резервного сервера приведет к усложнению процесса переключения на него и создаст потенциальную угрозу его пере" грузки при длительной неработоспособности основной системы. Таким образом, для обеспечения полного резервирования основного сервера на резервной ма" шине потребуется предусмотреть те же 32 Гбайт дискового пространства и точно воспроизвести описанную выше схему подключения дисков к дисковым контроллерам. Полная идентичность кон" фигурации дисков основного и резервного серверов позволит использовать единый набор коман" дных файлов для инициализации серверных устройств командой disk init и создания баз данных процедурой p_dbcreate. Это заметно сэкономит время администратора баз данных. Еще раз подчеркнем, что для использования резервной машины вместо основной в течение дли" тельного времени нужна полная идентичность возможностей обеих машин. Тогда затянувшийся ре" монт основного сервера не приведет к дезорганизации деятельности всей компании. Экономия на аппаратных средствах резервной машины повлечет за собой необходимость скорейшего восстанов" ления работоспособности основного OLTP"сервера. Сервер поддержки принятия решений (подготовки отчетов) Главное требование, предъявляемое к серверу подготовки отчетов (серверу поддержки принятия ре" шений — Decision Support Server, DSS) — это способность вместить в себя полный набор копий баз данных основного OLTP"сервера. Причина этого требования в том, что именно DSS"сервер должен обрабатывать любые запросы, не относящиеся к фиксированному набору OLTP"транзакций, выпол" няемых основным сервером. Если пользователи будут выполнять подобные запросы непосредствен" но на OLTP"сервере, его работа существенно замедлится. Так как вы не будете знать, чем занят

www.books-shop.com

сервер в каждый конкретный момент, вы не сможете настроить его должным образом. Нельзя допус" тить, чтобы каждый пользователь мог в любое время подключиться к OLTP"серверу и начал полный просмотр всех его таблиц. Это нарушит нормальную работу сервера. Отметим, что для эффективного выполнения своих задач DSS"сервер должен обладать значительно более широким выбором индек" сов, чем OLTP"сервер, и эти индексы должны иметь совершенно иную структуру. Поскольку DSS"сервер не используется для непосредственной поддержки оперативной обработки транзакций, в зеркальном резервировании его баз данных нет серьезной необходимости. При лю" бом сбое базы данных DSS"сервера всегда могут быть восстановлены с помощью дампов основного OLTP"сервера. В результате при установке DSS"сервера можно ограничиться половиной дискового пространства, используемого OLTP"сервером. Однако следует предусмотреть равный объем файло" вой системы, необходимой для загрузки дампов баз данных и журналов транзакций OLTP"сервера с целью синхронизации баз данных DSS"сервера. В нашем примере DSS"серверу достаточно 20 Гбайт общего дискового пространства, из которых 8 по"прежнему займет файловые системы, а 12 будет распределено серверным устройствам. Важно подчеркнуть, что даже на DSS"сервере требуется за" планировать зеркальную копию серверного устройства master. Конфигурация дисков и контролле" ров DSS"сервера может не совпадать с OLTP"сервером. Но вы сэкономите немало времени, если базы данных двух серверов будут расположены на равном количестве дисков одинаковой емкости, имеющих идентичную структуру разделов. Тогда для переноса базы данных на DSS"сервер будет до" статочно сохранить логический дамп структуры базы данных OLTP"сервера (например, процедурой p_dbcreate), вручную изменить названия устройств в полученном командном файле, а затем вы" полнить его для создания идентичной базы данных на DSS"сервере (подробнее этот процесс рас" сматривается в главе 14). Необходимая общая производительность машины DSS"сервера зависит от предъявляемых к ней требований. Если пользователям DSS"сервера нужно максимально ускорить обработку их сложных и, в любом случае, длительных запросов, то DSS"сервер должен быть установлен на компьютере с про" цессорными ресурсами, памятью и т.п., сопоставимыми с машиной основного сервера. Однако боль" шинство пользователей систем поддержки принятия решений не ожидают немедленного ответа на свои запросы. К тому же, DSS"сервер трудно оптимизировать под выполнение произвольных и тру" доемких запросов. В целом для DSS"сервера, скорее всего, вполне хватит машины со значительно меньшими процессорными возможностями по сравнению с серверной машиной главного OLTP"сер" вера. Сервер разработки приложений Дисковое пространство сервера разработки приложений должно обеспечивать потребности всех раз" работчиков приложений вашей компании. Предположим, что сервер разработки приложений будет использоваться исключительно для создания и сопровождения приложений, ориентированных на основной OLTP"сервер. В этом случае следует предусмотреть на сервере разработки приложений до" статочное количество дисков для размещения полных копий баз данных OLTP"сервера (с учетом их неизбежного разрастания в будущем) и всего необходимого программного обеспечения. Не забудем о многочисленных версиях разрабатываемых прикладных систем, а также о дополнительном простран" стве, позволяющем загружать большие наборы данных, которые при разработке приложений часто приходится импортировать из других источников. При наличии выделенного сервера для тестирова" ния приложений (об этом сервере см. далее) нужно обязательно проследить за тем, чтобы все оконча" тельное тестирование приложений производилось исключительно на нем. Это позволит выполнять итоговые тесты в строго контролируемой операционной среде, которую трудно обеспечить на серве" ре разработки приложений, и одновременно избежать создания помех разработчикам других прило" жений. С учетом всего сказанного, нашему серверу разработки приложений также потребуется 20 Гбайт дискового пространства, из которых 8 пойдет на размещение файловых систем, а 12 — необходимых баз данных. Убедитесь заранее, что один сервер разработки приложений сможет обеспечить созда" ние приложений для всех серверов вашей информационной системы, а не одного лишь основного OLTP"сервера. Возможно, придется предусмотреть отдельный сервер разработки приложений для каждого крупного OLTP"сервера, имеющегося в вашей системе. Причина такого решения — одно" временная разработка слишком большого числа приложений на одном сервере. Разработчики начи" нают блокировать друг друга и тем самым существенно замедляют работу всего сервера. Кроме того, разработчика приложении часто преследуют отказы сервера, а вместе с ним и серверной машины. Здесь необходимо подчеркнуть, что разработка приложений ни в коем случае не должна выполнять" ся на основном OLTP"сервере и его серверной машине. Подобно DSS"серверу, сервер разработки приложений не нуждается в конфигурации дисков и контроллеров, полностью эквивалентной

www.books-shop.com

OLTP"серверу. Но и здесь вам удастся сберечь немало времени, если базы данных двух серверов бу" дут расположены на равном количестве дисков одинаковой емкости, имеющих идентичную структу" ру разделов. Как и в предыдущем примере, перенос базы данных на сервер разработки приложений потребует лишь сохранения процедурой p_dbcreate логического дампа структуры базы данных OLTP"сервера. После этого нужно вручную изменить в командном файле названия устройств, а за" тем создать с помощью этого командного файла на сервере разработки приложений базы данных, идентичные базам данных OLTP"сервера. Требуемая производительность сервера разработки приложений также зависит от многих при" чин. С одной стороны, эффективная разработка приложений и адекватная оптимизация запросов требуют наличия достаточных процессорных ресурсов. Однако слишком высокая скорость работы сервера разработки приложений может лишить разработчиков приложений желания заниматься их полноценной настройкой. Для сервера разработки приложений идеально подходит серверная маши" на, в течение нескольких лет использовавшаяся для работы основного OLTP"сервера, который за" тем был перенесен на более новую и производительную вычислительную систему. Тестовый сервер Тестовый сервер во многом напоминает сервер разработки приложений, однако о его конкретной конфигурации еще труднее сказать что"либо определенное. Постарайтесь заранее проанализировать все этапы процесса разработки приложений, принятого в вашей компании — возможно, вашей ин" формационной системе вообще не требуется отдельный тестовый сервер. Как правило, он использу" ется для полномасштабного тестирования чернового варианта (альфа"версии) нового срочно потребовавшегося приложения перед его переносом на основной сервер. Его применяют для провер" ки работоспособности уже имеющихся приложений после внесения в них очередных текущих изме" нений. И создание прототипа будущего приложения, и модификация существующих приложений должны производиться на сервере разработки приложений (обычно в максимально возможном темпе). Однако тестирование новых вариантов прикладных систем на полных копиях баз данных OLTP"сервера лучше выполнять с помощью специального тестового сервера. Это защитит приложе" ния от случайных помех со стороны разработчиков других систем, а те смогут спокойно продолжать свою работу. На тестовом сервере размещают полные копии баз данных основного сервера. Тестовый сервер должен иметь файловую систему, достаточную для хранения дампов журналов транзакций и баз дан" ных основного сервера перед их загрузкой в постоянно обновляемые базы данных тестового сервера. Поэтому размеры дискового пространства тестового сервера и сервера разработки приложений дол" жны совпадать. В нашем примере тестовому серверу необходимо 20 Гбайт дискового пространства с 8Гбайтным файловым пространством и 12"Гбайтной областью размещения баз данных. И здесь совпа" дение конфигурации физических дисков, распределенных для хранения баз данных тестового и основного серверов, позволит администратору баз данных намного ускорить перенос баз данных основного сервера с помощью логического дампа их структуры, созданного процедурой p_dbcreate. Как и в предыдущих примерах, производительность серверной машины тестового сервера дол" жна находиться в разумных пределах. DBCC*сервер При наличии в информационной системе хотя бы одной крупной базы данных вам неизбежно потре" буется отдельный DBCC"сервер. Хотя теоретически перед созданием каждого полного дампа базы данных необходимо выполнить полный набор проверок непротиворечивости ее структуры (database consistency checks, dbcc), с ростом размеров базы данных эти проверки занимают все больше време" ни. Очень скоро перевод тестируемой базы данных в однопользовательский режим (необходимый для обеспечения корректности результатов dbcc"проверок) становится невозможным с точки зрения нормальной деловой активности вашей компании. Периодическое выполнение dbcc"проверок необ" ходимо для контроля внутренней структуры баз данных и устранения обнаруженных повреждений (о роли dbcc"проверок см. главу 9). Поэтому потребуется перенести dbcc"проверки на отдельный DBCC"сервер. Кроме того, этот сервер — наиболее подходящее место для загрузки прежних дампов баз данных, которые могут дать информацию об отдельных объектах данных, оказавшихся утрачен" ными в основной системе. Поскольку SQL Server обеспечивает сохранение и восстановление только полных дампов баз данных, извлечение нескольких компонентов крупной базы данных из ее полного дампа является длительной и громоздкой процедурой. Ее удобнее всего выполнить именно на DBCG"сервере. К тому же, загрузка старого дампа одновременно позволяет проверить состояние маг" нитной ленты, на которой записан дамп, и убедиться в его пригодности для использования.

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Дисковое пространство DBCC"сервера должно быть достаточным для размещения всех баз данных OLTP"сервера и любой другой базы данных, размеры которой могут потребовать прове" дения dbcc"проверок на отдельной машине. В нашем примере DBCC"сервер получает 20 Гбайт ди" сков, распределенных с соблюдением прежней пропорции между файловыми системами и серверными устройствами (8 Гбайт/12 Гбайт). Как отмечалось выше, экономию времени можно достичь, если базы данных OLTP" и DBCC"серверов будут расположены на равном количестве ди" сков одинаковой емкости, имеющих идентичную структуру разделов. Для переноса базы данных на DBCC"сервер здесь будет достаточно сохранить логический дамп структуры базы данных OLTP"сервера (например, процедурой p_dbcreate), вручную изменить названия устройств в полученном командном файле, а затем выполнить этот файл и создать идентичную базу данных на DBCC"сервере. Производительность DBCC"сервера может значительно уступать любой из рассмотренных выше серверных машин, поскольку выполнение dbcc"проверок не создает большой нагрузки на процессор. Важнее всего вынести dbcc"проверки на отдельную машину, а ее производительность не имеет осо" бого значения. Сервер предыдущей версии В процессе развития информационной системы вам придется неоднократно обновлять версии раз" личных серверов, входящих в ее состав. Хотя в большинстве случаев новая версия сервера сохраняет совместимость с предыдущей, из этого правила существует несколько важных исключений. Напри" мер, переход с SQL Server 4.9.2 на System 11, в результате которого вы теряете возможность загружать в новый сервер дампы баз данных версии 4.9.2. В результате для извлечения информации из старых дампов баз данных версии 4.9.2 вам придется поддерживать работоспособную копию SQL Server вер" сии 4.9.2. Обновляя сервер, позаботьтесь о возможности использования старых дампов, сохраненных до перехода на новую версию SQL Server (см. главу 13). Объем дисков прежней версии сервера определяется, исходя из необходимости загрузки само" го большого имеющегося дампа базы данных, созданного до перехода на SQL Server System 10 или последующую версию сервера. Поскольку в нашем примере наиболее крупная база данных имеет объем в 5 Гбайт, для загрузки ее данных и всех необходимых файлов серверной машине с SQL Ser" ver 4.9.2 вполне хватит 10 Гбайт дисков. В принципе, прежняя версия SQL Server вполне может ра" ботать и на серверной машине одного из перечисленных выше серверов (например DBCC"сервера). Единственное назначение предыдущей версии сервера заключается в загрузке дампов баз данных и извлечении из них необходимой информации. Поэтому для этого сервера будет достаточно любой серверной машины, вне зависимости от ее производительности. Сервер тиражирования Включение сервера тиражирования Replication Server в состав информационной системы повлечет за собой внесение определенных корректив в ее планируемую структуру. Реальная производитель" ность сервера тиражирования зависит от особенностей отдельных серверов системы, уровня нагруз" ки обрабатываемых транзакций, доли этих транзакций, подлежащей тиражированию, а также пропускной способности сети и производительности каждой серверной машины. Сервер тиражирования и необходимый для его работы служебный SQL Server рекомендуется раз" мещать на отдельной серверной машине. Объем дискового пространства этой машины определяет" ся с учетом количества и размера устройств сервера тиражирования. Эти устройства используются для размещения стабильных очередей транзакции, в которых в течение определенного времени хранятся все транзакции, тиражируемые Replication Server. Требуемые размеры стабильных очере" дей транзакций (stable queues) зависят от множества различных факторов. В нашем примере разум" но предположить, что машине сервера тиражирования будет достаточно 10 Гбайт дискового пространства, из которых 4 можно распределить файловым системам, а 6 будут заняты устройства" ми Replication Server. Кроме того, потребуется создать один или даже два дополнительные серверы тиражирования. Они будут применяться для разработки системы тиражирования транзакций; на" стройки ее структуры и проверки всех этапов процесса создания подписок на данные; фактического времени начала функционирования подписок на крупные таблицы данных; восстановления после сбоев отдельных компонентов системы тиражирования. Чтобы обеспечить возможность создания и проверки системы тиражирования, на серверах разработки приложений следует предусмотреть до" полнительное дисковое пространство.

www.books-shop.com

Необходимый уровень производительности машины сервера тиражирования должен соответст" вовать объемам тиражируемых данных и допустимой задержке времени поступления тиражируемых транзакций на вторичные серверы. Учесть все существующие обстоятельства можно только, устано" вив сервер тиражирования на одну из машин для его пробной эксплуатации в условиях реальной ин" формационной системы. Реальный пример: отдельный сервер баз данных Обсудим теперь различные факторы, которые следует принять во внимание при планировании кон" фигурации дискового пространства основного OLTP"сервера информационной системы. Одним из важнейших этапов этого процесса является продуманная оценка необходимого количества дисков и дисковых контроллеров основного сервера. Это объясняется тем, что поле дисков OLTP"сервера определяет конфигурацию дисков всех остальных серверов системы. Базы данных Определяя нужное дисковое пространство OLTP"сервера, начните с оценки размеров каждой базы данных, размещаемой на будущем сервере, или уже имеющейся на существующем сервере. Примите во внимание ожидаемые темпы роста этих баз данных со временем. Информация о расширении баз данных в прошлом должна быть интерпретирована с учетом экспоненциального увеличения разме" ров большинства баз данных, когда линейная экстраполяция прежних темпов роста может скорее на" вредить, чем помочь. Здесь важно определить, в течение какого периода времени (например года) создаваемая конфигурация сервера должна оставаться адекватной увеличивающимся объемам баз данных. В нашем примере общий размер баз данных уже достиг 8 Гбайт, а все дисковое пространство, доступное для размещения баз данных, составляет 12 Гбайт. Формально можно допустить увеличение баз данных на 50%. На самом же деле необходимость тщательно контролируемого размещения сег" ментов баз данных по серверным устройствам и контроллерам приводит к значительному сокраще" нию реально доступного пространства. Обратившись к данным о расширении основной базы данных, мы увидим, что за прошлый год она увеличилась с 2,5 Гбайт до настоящих 5 Гбайт. Таким об" разом, за год ее размеры удвоились. В текущем году темпы расширения компании еще более возрос" ли, что затрудняет оценку размеров баз данных, ожидаемых к концу года. Количество сегментов Теперь определим количество сегментов, необходимых основным базам данных OLTP"сервера. В на" шем примере таких баз три. Самая большая образована обычными сегментами default, system и logseg ment, а также двумя пользовательскими сегментами — сегментом некластеризованных индексов ncindexes и сегментом data. Эти сегменты, предназначены для размещения некоторых наиболее круп" ных таблиц данных. Поскольку основная цель создания пользовательских сегментов — максимальное повышение скорости сервера, каждый из сегментов необходимо разместить на отдельном контролле" ре дисков. Поэтому серверная машина должна иметь минимум четыре контроллера, к каждому из ко" торых в нашей основной серверной машине подключается по четыре дисковых накопителя (как отмечалось выше, всего нам необходимо 16 физических дисков). В главе 8 уже говорилось о том, что в операционной системе Solaris к одному контроллеру нельзя подключить более 4"х дисков без замет" ного снижения скорости ввода"вывода. Однако это количество зависит от используемой аппаратной платформы. Две оставшиеся базы данных имеют по четыре сегмента — default, system, logsegment, а так" же сегмент ncindexes, содержащий некластеризованные индексы таблиц данных. Сегменты баз данных следует разместить отдельно друг от друга на разных контроллерах. При этом необходимо сбаланси" ровать нагрузку на каждый контроллер (поскольку мы не можем назначить каждому сегменту каждой базы данных свой индивидуальный контроллер). Распределяя сегменты одной из основных баз дан" ных по контроллерам, не забывайте, что эти же контроллеры будут применяться сегментами других часто используемых баз данных. Таким образом, мы сталкиваемся с двумя противоречащими друг другу требованиями. Во"первых, каждый сегмент базы данных должен находится на отдельном контроллере. Во"вторых, общее коли" чество контроллеров серверной машины строго ограничено. Это заставляет сегменты одних баз данных конкурировать с сегментами других баз за пропускную способность общего контроллера. Сбалансировать нагрузку на разные контроллеры можно только путем мониторинга операций вво" да"вывода в процессе эксплуатации сервера.

www.books-shop.com

Зеркальные копии Пришло время распланировать зеркальное резервирование серверных устройств. Как отмечалось выше, простейший и одновременно наиболее эффективный метод резервирования — полное зерка" лирование серверных устройств на уровне физических дисков, когда часть дисков предназначена исключительно серверным устройствам, а другая — их зеркальным копиям. Степень резервирования серверных устройств определяется потребностями компании и имеющимися ресурсами, а также вре" менем, необходимым для контроля за соблюдением сложного плана зеркалирования устройств. Со" здание выборочных зеркальных копий серверных устройств повлечет за собой постоянные проверки наличия зеркальных копий у устройств, впервые распределяемых сегментам резервированных баз данных. Отметим, что речь идет именно о зеркальных копиях устройств, поскольку SQL Server не поддерживает зеркальное отображение отдельных сегментов или баз данных. Для полного резерви" рования сегмента требуется присутствие зеркальных копий у всех серверных устройств, используе" мых для размещения этого сегмента. В нашем примере реализована простейшая схема полного зеркалирования всех имеющихся серверных устройств. Для этого нужно еще 12 Гбайт дисков " про" странства, равное общему объему всех серверных устройств (см. главу 8). Оперативная память Дополнительная оперативная память положительно сказывается на производительности сервера. Поэтому, планируя его конфигурацию, следует, по крайней мере, выяснить максимальное количество памяти, которое можно установить в серверную машину, и сопоставить стоимость подобной конфи" гурации с возможными потерями вашей компании от недостаточной производительности сервера. В любом случае, никогда не устанавливайте в сервер менее 128 Мбайт памяти (лучше всего 500 Мбайт). Помните, что память кажется дорогой, пока ее стоимость не сравнивается с убытками от медленной работы сервера и затратами труда на его настройку. Определив общий объем памяти сервера, установите соотношение между размерами кэш"буфе" ров данных и процедур. Первый из этих буферов служит для хранения страниц данных при их чте" нии и модификации, а второй содержит хранимые процедуры. Разумеется, увеличение каждого буфера повысит быстродействие сервера, поскольку больший процент требующейся серверу инфор" мации окажется уже прочитанным с диска и загруженным в соответствующий кэш"буфер. Опреде" лить оптимальный баланс между размерами кэш"буферов данных и процедур можно только путем наблюдения с помощью программы SQL Monitor за долей успешных поисков в каждом буфере. Од" новременно варьируйте параметр конфигурации "procedure cache percent", применяя процедуру sp_configure. По умолчанию, значение этого параметра составляет 20%. При запуске сервер рас" пределяет кэш"буферу процедур 20% всего пространства, оставшегося после резервирования памя" ти, необходимой для внутренних нужд самого сервера. В свою очередь кэш"буфер данных автоматически получает всю память, оставшуюся после создания кэш"буфера процедур, а это не по" зволяет точно установить его размеры заранее. Размеры файловых систем Необходимые размеры файлового пространства сервера наверняка окажутся больше, чем вы могли предполагать. В дополнение к файловым областям (см. предыдущие разделы), серверной машине так" же требуется пространство для нужд операционной системы; для размещения области подкачки стра" ниц виртуальной памяти (требуемые размеры уточните у системного администратора серверной машины); для размещения дистрибутивов SQL Server и файлов, необходимых для обеспечения его нормальной работы; для размещения всех других установленных на серверной машине программных продуктов. Не забудьте о файлах, которые могут потребоваться при переходе на новую версию опера" ционной системы, сервера и сопутствующих программных продуктов. Как вы уже знаете, для файло" вых систем серверной машины разумно отвести четверть всех подключенных к ней дисковых накопителей. Поверьте, столь значительное пространство не будет пропадать без дела. Значитель" ные области файлового пространства потребуются для целей, перечисленных ниже. Выдача на диск дампов баз данных Возможность записи на диск полных дампов крупных баз данных необходимо предусматривать зара" нее, еще на этапе планирования конфигурации сервера. Наши три наиболее крупные базы данных имеют размеры в 5, 2 и 1 Гбайт соответственно, а их общий объем составляет 8 Гбайт. Таким обра" зом, одновременная запись на диски дампов всех трех баз данных потребует 8 Гбайт файлового про" странства. Оно должно быть специально зарезервировано под эти цели — если указанное

www.books-shop.com

пространства окажется хотя бы частично занятым другими файлами, сохранение дампов может за" кончиться неудачей. Начиная с SQL Server System 10, сохранение дампов баз данных осуществляется исключительно через сервер архивации Backup Server, способный выдавать дамп на несколько ленточных устройств или в несколько дисковых файлов одновременно. Это значительно сокращает время создания дам" па. В случае, если указанные ленточные или дисковые накопители подключены к разным контролле" рам ввода"вывода, дамп создается быстрее во столько раз, сколько устройств работает одновременно. В результате создание дампа базы данных можно ускорить в четыре раза по сравне" нию с его сохранением на одну ленту или диск. Указанное обстоятельство обязательно учтите при планировании распределения дисков и накопителей на магнитной ленте по имеющимся дисковым контроллерам серверной машины. Выдача на диск дампов журналов транзакций В течение всего периода между последовательными сохранениями полных дампов баз данных следует обеспечить регулярное сохранение дампов журналов транзакций важнейших баз данных. Определив время, в течение которого должны храниться все дампы журналов транзакций, попытайтесь устано" вить их оптимальный объем, накапливаемый за каждые сутки работы сервера. Полученные цифры дадут размеры файловой системы, нужные для размещения необходимого количества дампов журна" лов транзакций. Здесь нельзя забывать об увеличении нагрузки на сервер в периоды максимальной деловой активности. В нашем примере для хранения дампов журналов транзакций крупнейшей базы данных выделен целый физический диск, на котором в периоды затишья имеется масса свободного места. Однако в конце квартала этого же диска хватает только на трехдневный комплект дампов жур" налов транзакций, хотя мы предпочли бы хранить минимум недельный запас таких дампов. Настройка сервера Хотя распределенных дисков может быть достаточно для размещения текущих баз данных, настрой" ка сервера потребует дополнительного дискового пространства. Одним из важнейших этапов на" стройки сервера является уточнение структуры индексов каждой активной таблицы базы данных. Создание новых и изменение структуры существующих индексов требует порой весьма значительно" го свободного места на диске. Особенно много дискового пространства нужно для создания кластери" зованного индекса таблицы — оно может достигать 150% от полного размера индексируемой таблицы данных. Поскольку в нашем сервере самая крупная таблица имеет длину в 800 Мбайт, мы должны за" резервировать около 1,2 Гбайт для обеспечения будущей настройки сервера. Важно подчеркнуть, что это пространство должно быть доступно для расширения индексного сегмента базы данных. Поэтому оно должно находиться на серверных устройствах, поддерживающих именно этот сегмент. Если сво" бодного места для размещения индексного сегмента базы данных нет, вновь создаваемые индексы не" льзя будет вынести в отдельный сегмент и поместить на отдельный дисковый контроллер. После создания кластеризованного индекса все дополнительное дисковое пространство вновь оказывается свободным. Однако исключить его из cocтaвa базы данных непросто. Кроме того, это пространство может потребоваться в будущем для создания кластеризованных индексов других таблиц. Представьте себе следующую ситуацию. Приобретенную у одного независимого постав+ щика готовую прикладную систему пришлось устанавливать в большой спешке. Поэтому никто не поставил вас об этом в известность. Как оказалось, приложение было написано много лет назад для другой платформы, и его адаптация опять же была выполнена на скорую руку. Проработав какое+то время, пользователи обнаружили, что производитель+ ность сервера упала почти до нуля. Теперь они решили проконсультироваться с вами. Взглянув на используемые приложением таблицы данных, вы немедленно обнаруживае+ те, что ни одна из таблиц не имеет ни одного индекса. Разумеется, индексы должны быть созданы как можно скорее, но для этого требуется много места, которого на серве+ ре уже нет. В результате, к машине приходится подключать новые диски, большая часть которых будет использована только во время создания кластеризованных индексов. Обмен данными с другими системами Импорт и экспорт данных при их обмене с другими системами также нуждается в значительных объе" мах файлового пространства. Например, если каждую ночь вы получаете от другой фирмы полезную информацию о потенциальных клиентах, необходимо заранее предусмотреть место для хранения по" лученных данных на определенное время. В некоторых случаях размеры подобных файлов

www.books-shop.com

оказываются внушительными, или же их нужно хранить весьма долго. И в том, и в другом случае вам придется использовать большие области файлового пространства. Запись на диск логических дампов Помимо записи обычных дампов баз данных, во многих случаях ощутимую пользу приносит регуляр" ное сохранение логических дампов баз данных. Эти дампы намного облегчают получение информа" ции о структуре и содержании отдельного объекта базы данных (см. главу 9). Однако их полное сохранение требует свободного пространства файловой системы. Определите, логические дампы ка" ких баз данных должны записываться на диск и как долго требуется хранить старые дампы. Как пра" вило, логический дамп базы данных занимает заметно меньше места, чем сама база данных, поскольку в него включается только описание структуры индексов таблиц, а не сами данные из этих индексов. В нашем примере следует хранить только один последний комплект логических дампов всех баз данных сервера. Установим средний размер логического дампа в 50% объема соответствую" щей базы данных. Тогда логические дампы займут до 6 Гбайт файлового пространства (половину от 12 Гбайт дисков, распределенных под серверные устройства). Обмен данными между серверами Перенос дампов между отдельными серверами информационной системы также требует наличия сво" бодного файлового пространства. Отметим, что здесь речь идет не об экспорте или импорте данных из внешних источников, а об обмене данными между серверами одной и той же системы. Необходи" мость выполнения подобных операций и требуемые объемы дискового пространства зависят от осо" бенностей работы конкретных информационных систем. Например, при наличии в системе выделенного DBCC"сервера на нем необходимо предусмотреть файловое пространство, позволяю" щее переписать с других серверов подлежащие проверке дампы баз данных. Их следует хранить до фактического начала выполнения dbcc"проверок. Определяя конфигурацию DBCC"сервера, мы запла" нировали для него 20 Гбайт дискового пространства, из которых 12 будет занято серверными устрой" ствами, а 8 — файловыми системами. Такого поля дисков действительно хватит при условии, что дампы баз данных будут загружаться в DBCC"сервер непосредственно с магнитных лент. Однако авто" матизированная синхронизация баз данных DBCC"сервера с основным OLTP"сервером потребует обеспечения копирования дисковых файлов дампов баз данных. Для этого понадобится место на DBCC"сервере. Наша наиболее крупная база данных имеет размер 5 Гбайт. Для временного размеще" ния ее дампа перед загрузкой в DBCC"сервер на нем должно быть зарезервировано 5 из 8 Гбайт имею" щегося файлового пространства. Просчитайте, хватит ли имеющихся файловых систем на размещение дампа крупнейшей базы данных системы и всех остальных файлов, требующихся для эф" фективной работы DBCC"сервера. Ограничения, накладываемые серверной машиной До настоящего момента, рассматривая дисковое пространство серверной машины, мы предполагали, что можем подключить к ней неограниченное количество дисков. Следует точно определить, сколь" ко контроллеров можно подключить к каждому из имеющихся в вашем распоряжении компьютеров. От этого зависят максимальные размеры доступного дискового пространства. Если на какой"то из серверных машин не удается уложиться в это пространство, следует либо заменить эту машину на бо" лее мощную, либо поручить часть ее функций другому серверу. Аналогичные проблемы могут возник" нуть из"за физического недостатка свободного места для установки новых дисковых накопителей. Количество дисковых стоек, а также кондиционеров и источников питания также должно устанавли" ваться заранее. Сервер тиражирования В нашем случае сервер тиражирования (Replication Server) работает на отдельной серверной машине. Поэтому его присутствие в системе не влияет на размеры дискового пространства серверной маши" ны основного OLTP"сервера. Ленточные накопители серверной машины Чтобы обеспечить обмен записанными на магнитную ленту данными между различными машинами информационной системы, следует продумать конфигурацию имеющихся устройств записи на лен" ту. Самое главное — добиться того, чтобы ленточный дамп, созданный на одной из серверных ма" шин, можно было бы загрузить в любой другой сервер. Недостаточно приобрести "все накопители на магнитной ленте одинаковой емкости у одного производителя. Имя системного файла

www.books-shop.com

устройства, указанное при сохранении дампа на ленту, влияет на степень сжатия данных при записи файла. В случае, если ленточный накопитель данной машины не поддерживает использованный дру" гой машиной алгоритм сжатия данных или установленную степень сжатия, полученный дамп не мо" жет быть прочитан на этой машине. Рекомендуем проверить на практике возможность переноса магнитных лент с одной машины на другую. Кроме того, емкость накопителей на магнитной ленте каждой серверной машины следует сопо" ставить с размерами баз данных этого сервера. Увеличиваясь, размеры баз данных могут превысить емкость ленточных устройств. Конечно, один дамп вполне может занимать несколько магнитных лент, но смена лент требует вмешательства персонала и занимает много времени. Такая же пробле" ма возникнет при записи нескольких дампов на один том магнитной ленты. (Хотя подобный режим официально не поддерживается SQL Server 4.9.2, в главе 14 будет показано, как это можно реализо" вать на практике.) Эти же трудности преследуют вас при записи дампов разделов файловой систе" мы, содержащих ранее сохраненные, дампы баз данных. Следует либо заранее оценить возможности оператора, либо вообще отказаться от создания многотомных дампов. Заключение Итак, наша информационная система основана на OLTP"сервере, базы данных которого занимают 8 Гбайт дискового пространства. Мы включили в состав системы шесть отдельных серверов, работа" ющих на шести серверных машинах, предположив, что сервер предыдущей версии удалось размес" тить на машине одного из остальных серверов. Для сервера "тиражирования Replication Server нам потребовалась седьмая машина. Мы это сделали для обеспечения нормальной работы пользователей OLTP"приложений и приложений поддержки принятия решений и разработчиков приложений. Эти серверы позволяют быстро восстанавливать работоспособность системы при сбоях основного серве" ра, своевременно проверять целостность данных и тестировать новые приложения. В целом для по" добной системы необходимо 164 Гбайт дисковой памяти. Нужно привыкнуть к столь значительному увеличению объемов требуемого дискового пространства по сравнению с размерами исходных баз данных. Общая емкость заказываемых дисков легко может достигнуть сотен Гбайт. Не следует забы" вать, что увеличение размеров каждой базы данных повлечет за собой рост объема нужного дисково" го пространства. Если одна из баз данных увеличивается на 1 Гбайт, для успешного сохранения ее дампа файловое пространство и емкость ленточного накопителя соответствующей серверной маши" ны также придется увеличить на 1 Гбайт (плюс поправка на увеличение размеров дампов журнала транзакций). Потом вам придется увеличить емкость дисков всех машин, куда хотя бы эпизодически загружается дамп этой базы данных. В итоге вы заново пройдете все этапы процесса, описанного в предыдущих разделах главы. Определив нужное вам количество машин, дисков и другого оборудования, не забудьте, что в одиночку вы физически не справитесь с его установкой, эксплуатацией и обновлением. Даже если сейчас вы выполняете все подобные функции самостоятельно, с ростом активности вашей компа" нии вам придется позаботиться о расширении персонала. Сложив размеры перечисленных в этой главе отдельных компонентов дискового про+ странства серверной машины основного OLTP+сервера, вы получите цифру 48 Гбайт. А на вашей серверной машине физически имеется только 32 Гбайт дисков. Несколько лет назад, когда эта машина была приобретена с максимально допустимым дисковым пространством, ее возможности выглядели огромными. Теперь же ее требуется заме+ нить, поскольку у вас нет другого способа расширить имеющееся пространство дисков. Не сменив ее, вы не сможете выполнять все необходимые операции. Например, сохра+ нять на диск полные дампы баз данных. (Вам понадобится постоянно переносить дампы с одной машины на другую вручную на магнитных лентах.) Планирование конфигурации глобальной информационной системы В этой главе был рассмотрен процесс определения конфигурации каждого из серверов информаци" онной системы. Полезно заранее разработать план добавления к системе новых серверов. Рост актив" ности вашей компании и увеличение размеров баз данных потребует переноса части данных на отдельный сервер. Очень часто каждая группа основных приложений поддерживается отдельным сервером баз данных. Немалую роль здесь играет и стремление разместить базы данных как можно

www.books-shop.com

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

www.books-shop.com

Глава 12

Эксплуатация SQL Server Содержание Особенности различных версий SQL Server Пороги Файл интерфейсов Преобразование файла интерфейсов SunOS в формат системы Solaris Сетевое взаимодействие серверов Преобразование командных файлов SQL и выдачи утилиты defncopy в хранимые процедуры Системная таблица sysusages Состав объектов сегмента базы данных Журнал регистрации ошибок Создание новых баз данных и эксплуатация сервера Модификация системных таблиц SQL Server вручную Команда bср Свободное пространство базы данных Ошибка 1105: переполнение журнала транзакций или другого сегмента базы данных

www.books-shop.com

Введение Администратор сервера должен хорошо представлять себе принципы работы SQL Server и особенно" сти его эксплуатации. В этой главе рассматриваются некоторые особенности, наиболее часто встре" чающиеся на практике. Особенности различных версий SQL Server SQL Server 4.9.2 При выполнении системных хранимых процедур sp_helpdb и sp_helpsegment SQL Server вер" сии 4.9.2 не сообщает размеры свободного пространства каждого сегмента. Кроме того, эта версия сервера не поддерживает порогов. Однако SQL Server 4.9.2 способен работать как в SunOS, так и в Solaris и поэтому поддерживает оба формата файла интерфейсов. SQL Server System 10 Аналогично предыдущей версии, SQL Server System 10 работает и в SunOS, и в Solaris, поддерживая оба формата файла интерфейсов, и не сообщает размеры свободного пространства сегментов при выполнении системных хранимых процедур sp_helpdb и sp_helpsegment. По завершении перехо" да от SQL Server 4.9.2 к System 10 в каждой базе данных необходимо вручную активизировать порог последнего уровня (last"chance threshold). Эта операция подробна рассматривается в посвященной порогам главе руководства системного администратора Sybase SQL Server (Sybase SQL Server System Administration Guide) для версии System 10. SQL Server System 11 Поскольку SQL Server System 11 работает только в операционной системе Solaris, его файл интерфей" сов должен быть подготовлен в формате системы Solaris. По завершении перехода на System 11 c SQL Server версии 4.9.2 (или System 10, если сервер System 10 также был установлен в процессе обновле" ния сервера версии 4.9.2) в каждой базе данных необходимо вручную активизировать порог послед" него уровня. Процедура ручной активизации порогов не упоминается в соответствующей главе руководства системного администратора Sybase SQL Server System 11 (в отличие от предыдущей вер" сии этого руководства). Пороги Пороги позволяют серверу автоматически контролировать объем свободного пространства, оставше" гося в каждом сегменте каждой базы данных. При сокращении имеющегося свободного места до уров" ня порога сервер автоматически активизирует заранее созданную администратором базы данных хранимую процедуру, связанную с данным порогом. Отметим, что Sybase не поставляет никаких стан" дартных хранимых процедур, по умолчанию связанных с порогами. Кажется, что механизм порогов специально предназначен для предотвращения переполнения сегмента журнала транзакций (logseg ment). Пороги могут оказать существенную помощь и при контроле других сегментов баз данных. На" пример, выполняющаяся при срабатывании порога хранимая процедура с помощью команд print или raiserror легко может выдать в журнал регистрации ошибок сервера необходимое сообщение. SQL Server поддерживает два типа порогов. При создании порогов первого типа вы указываете название базы данных и соответствующего сегмента, контролируемого устанавливаемым порогом; значение порога в виде количества остающихся свободных страниц; название хранимой процедуры, активизируемой при уменьшении количества свободных страниц ниже значения порога. Пороги второго типа называются порогами последнего уровня (last"chance thresholds) и устанавливаются то" лько по отношению к сегменту журнала транзакций (logsegment) каждой базы данных сервера. Задача порога последнего уровня — обеспечить наличие в текущей копии журнала транзакций достаточно" го свободного пространства для нормального выполнения команды dump transaction. Этот по" рог автоматически устанавливается в момент создания базы данных, если ее сегмент журнала транзакций вынесен на отдельное серверное устройство. Значение порога последнего уровня (ми" нимальное количество свободных страниц в logsegment) также определяется автоматически и изменя" ется при добавлении к сегменту журнала транзакций дополнительного дискового пространства. При сокращении свободного пространства журнала транзакций ниже уровня порога последнего уровня сервер автоматически выполняет системную хранимую процедуру sp__thresholdaction. Важно от" метить, что в отличие от порогов первого типа, активируемой порогом последнего уровня

www.books-shop.com

хранимой процедуре по умолчанию присваивается имя sp_thresholdaction. Однако для каждой отдельной базы данных название этой процедуры может быть изменено процедурой sp_modifyth" reshold. Имейте в виду, что Sybase не поставляет вместе сервером готовой процедуры sp_thres" holdaction. Поэтому, если она отсутствует, срабатывание порога последнего уровня не повлечет за собой никаких действий сервера. Обычно в состав этой процедуры включается команд dump transaction или другие необходимые команды, а также выдача соответствующих сообщений в журнал регистрации ошибок сервера командами print или raiserror. Эту процедуру следует на" звать sp_thresholdaction и поместить в базу данных sybsystemprocs, чтобы сделать доступной для порогов последнего уровня всех баз данных сервера. Существует важная особенность процесса уста" новки порогов, пренебрежение которой может привести к серьезным неприятностям. Порог по" следнего уровня автоматически устанавливается для каждой базы данных, созданной в SQL Server System 10 и System 11. Однако это не относится к базам данных предыдущих версий, переносимых в серверы System 10 и System 11. Поэтому по завершении перехода от SQL Server 4.9.2 на сервер System 10 или System 11 (см. главу 13) ни одна из баз данных предыдущей версии сервера не будет иметь порога последнего уровня. Его необходимо установить вручную командой select lct_admin ("lastchance", db_id()) Рекомендуем читателю проверить наличие порогов последнего уровня во всех базах данных свое" го сервера. Приведенный ниже пример относится к SQL Server System 11: 1> use psychodb 2> go 1> sp_helpthreshold 2> go segment name free pages last chance? threshold procedure logsegment 744 1 sp_thresholdaction (1 row a f f e c t e d , return status = 0) Как видите, в базе данных psychodb действительно имеется порог, являющийся порогом послед" него уровня. Давайте теперь проверим еще одну базы данных: 1> use psychodb2 2> go 1> sp_helpthreshold 2> go segment name free pages last chance? threshold procedure (0 row affected, return status = 0 ) Почему же вторая база данных не имеет порога последнего уровня? Оказывается, нынешний сер" вер System 11 был установлен на место SQL Server System 10, который поддерживает пороги послед" него уровня. Поэтому они активизированы во всех базах данных сервера System 10, дампы которых были загружены в сервер System 11 при его установке. Однако, сервер System 10 был установлен вме" сто SQL Server4.9.2. В процессе перехода на System 10 в базе данных psychodb2 и некоторых других забыли установить пороги последнего уровня, наличие или отсутствие которых не проверяется про" граммой установки System 11. Администратору сервера нужно было выполнить все необходимые проверки вручную. Наша следующая задача — установить пропущенный порог последнего уровня в базе дан" ных psychodb2. Соответствующая команда сервера имеет вид select lct_admin ("lastchance", db_id()) где db_id() является функцией, возвращающей идентификатор базы данных, в которой требуется уста" новить порог последнего уровня. Этот идентификатор может не совпадать с идентификатором теку" щей базы данных. Ошибка в указании идентификатора может привести к ненулевому результату. Поэтому обязательно убедитесь с помощью процедуры sp_helpthreshold в активации порога по" следнего уровня именно нужной вам базы данных. (Для этого sp_helpthreshold следует вызвать дважды — до и после выполнения команды select.) В нашем случае базе данных psychodb2 соответствует db_id() = 9. Команда select возвращает значение 1232, представляющее собой количество свободных страниц, при котором сработает порог последнего уровня. Как отмечалось выше, это значение зави" сит от размеров базы данных.

21—2221

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

1> select lct_admin ("lastchance", 9) 2> go 1232 (1 row affected) 1> sp_helpthreshold 2> go segment name free pages last chance? threshold procedure iogsegment 1232 1 sp_thresholdaction (1 row a f f e c t e d , return status = 0) Итак, мы убедились, что сегмент журнала транзакций базы данных psychodb2 теперь действитель" но имеет порог последнего уровня. Чтобы проверить, есть ли порог у определенного сегмента базы данных, его название следует указать при вызове процедуры sp_helpthreshold: sp_helpthreshold <название_сегмента> 1> sp_helpthreshold Iogsegment 2> go segment name free pages last chance? threshold procedure Iogsegment 1232 1 sp_thresholdaction (1 row a f f e c t e d , return status = 0) В некоторых случаях команда select выдает нулевой результат: 1> select lct_admin ("lastchance", 13) 2> go О

(1 row affected) Обычно это указывает на ошибочный идентификатор базы данных. Здесь необходимо прове" рить, что интересующая нас база данных действительно имеет db_id() = 13. С формальной точки зрения, нулевой результат может означать, что журнал транзакций указанной базы данных не выне" сен на отдельное серверное устройство, и поэтому эта база данных не может иметь порога последне" го уровня. Однако, если при неправильном задании идентификатора мы случайно попадем на базу данных с отдельно расположенным журналом транзакций, команда select будет успешно выполнена и выдаст установленное значение порога последнего уровня. Необходимо иметь в виду, что при пе" реносе на отдельное устройство журнала транзакций, ранее расположенного вместе со всей базой данных, эта база данных, скорее всего, не имеет порога последнего уровня. Его следует установить вручную. При активизации порога последнего уровня сервер по умолчанию приостанавливает все опера" ции пользователей, пытающихся что"то записать в близкий к переполнению журнал транзакций базы данных. После срабатывания порога пользователи могут выбирать информацию из таблиц базы данных, но им больше не удастся внести в нее какие"либо изменения командами insert, update или delete. В выдаче команды sp_who соответствующие пользователи будут иметь статус "suspended" (работа приостановлена). Активизированная в момент срабатывания порога хранимая процедура может содержать команду выдачи дампа журнала транзакций. Если после ее успешного за" вершения в журнале появится достаточно свободного места, сервер автоматически возобновит вы" полнение приостановленных пользовательских процессов. Пока хранимая пороговая процедура не очистит журнал транзакций, пользовательские процессы останутся в приостановленном состоянии до удаления содержимого журнала транзакций администратором сервера. Если по каким"то причинам сервер не возобновит выполнение приостановленных .пользователь" ских процессов, администратор сервера может сделать это вручную командой select lct_admin("unsuspend", db_id()) Однако не рекомендуется применять эту команду без серьезной необходимости. Речь идет о по" льзовательских процессах, приостановленных из"за того, что журнал транзакций вот"вот перепол" нится в результате работы одного из этих процессов. Возможность выполнения приостановленных процессов позволит им продолжать запись в журнал транзакций. Поскольку срабатывание порога последнего уровня происходит при очень небольшом свободном пространстве журнала транзакций, он окончательно переполнится очень быстро. Таким образом, скоро после возобновления работы пользовательских процессов вы будете иметь дело с ошибкой 1105 и всеми сопутствующими ей неп" риятностями.

www.books-shop.com

Заданное по умолчанию поведение сервера можно изменить, разрешив ему при срабатывании порога последнего уровня базы данных принудительно завершить все пользовательские процессы, обращающиеся к этой базе данных. Это делается при помощи команды sp_dboption <имя_базы_данных> , "abort tran log on log full", true Перед использованием этой команды следует продумать все ее последствия. Разумно предполо" жить, что ваша компания не заинтересована в принудительном завершении особо важных транзак" ций, вызванном возможным переполнением журнала транзакций. Если только один пользователь несет ответственность за близкое переполнение, администратор сервера может уничтожить соот" ветствующий пользовательский процесс. Остальные смогут продолжить обработку своих транзак" ций. В случае же активизации режима "abort tran log on log full" будут уничтожены все обрабатывающие базу данных пользовательские процессы, а не только процесс, вызвавший пере" полнение. С помощью порогов администратор сервера способен сократить количество ежедневно сохраня" емых дампов журналов транзакций. Можно каждые 15 минут записывать очередной дамп журнала транзакций. Однако хранимая процедура порога последнего уровня осуществит запись дампа авто" матически при возникновении реальной необходимости. Снижение количества дампов журналов транзакций заметно облегчит процесс последующего восстановления базы данных. В руководстве системного администратора Sybase SQL Server читатель найдет два примера храни" мых пороговых процедур, каждая из которых автоматически сохраняет дамп журнала транзакций и вполне может быть использована в качестве процедуры sp_threeholdaction. Как уже указыва" лось, по умолчанию именно процедура с таким именем активизируется сервером в момент срабаты" вания порога последнего уровня). Дополнительные подробности о принципах работы порогов и особенностях их использования читатель также сможет узнать из руководства системного админист" ратора Sybase SQL Server. Файл интерфейсов Файл интерфейсов играет крайне важную роль в процессе работы самого SQL Server и связанных с ним программных продуктов. Фактически, он представляет собой перечень всех доступных экземпля" ров SQL Server, Open Server, а также таких вспомогательных программных продуктов, как сервер ар" хивации Backup Server и компоненты сервера тиражирования Replication Server. В файле указываются названия доступных серверов вместе с сетевыми именами соответствующих серверных машин и номерами распределенных этим серверам портов серверных машин. Рассмотрим особенности файла интерфейсов, используя формат этого файла, принятый в систе" ме SunOS, когда сетевое имя машины и номер порта сервера указывается в файле явно. Напомним, что SQL Server System 11 не работает с системой SunOS, поэтому его интерфейсный файл должен за" даваться исключительно в формате системы Solaris. Об этом подробно говорится в разделе "Преоб" разование файла интерфейсов SunOS в формат системы Solaris". Описание каждого сервера в файле интерфейсов состоит из нескольких строк, каждая из кото" рых начинается словами "master", "query" или "console" (возможны и другие варианты, но они встре" чаются крайне редко). Существуют три варианта использования файла интерфейсов, каждый из которых подробно рассматривается ниже. Во"первых, файл интерфейсов читается при запуске SQL Server. Сервер находит в файле интер" фейсов описание сервера с именем, указанным в командном файле запуска сервера. Говоря точнее, имя сервера задается либо в качестве значения переменной среды DSLISTEN, либо указывается в командной строке при запуске выполняемого модуля сервера dataserver (параметр "s, см. главу 14). Найдя в файле интерфейсов собственное описание, сервер определяет из строки "master", на какой серверной машине он должен запуститься и какой номер порта использовать. Кроме того, сервер уз" нает из файла интерфейсов (строка "console"), где должен быть запущен консольный процесс. Обра" тите внимание на то, что для SQL Server требуется серверная версия файла интерфейсов (см. рис. 12.1), в которой указаны все три строки — "master", "query" и "console". Другие программы — на" пример, серверный модуль SQL Monitor, чье описание в файле интерфейсов приводится под име" нем <имя_сервера>_МSV, — используют только строки "master" и "query". (Необходимо заметить, что SQL Server версий System 10 и 11 больше не имеет отдельного серверного процесса, поэтому не нуж" дается в строке "console" (см. главу 13)). Отметим, что SQL Server вовсе не обязательно запускать под именем, указанным в системной таблице sysservers для локального сервера. Его можно запус" тить, задав в командном файле запуска любое имя, поскольку оно нужно только для определения

www.books-shop.com

# DDSDBA1 query tcp sun+ether machinel 1025 master tcp sun+ether machine1 1025 console tcp sun+ether machinel 1026 # DDSDBA2 query tcp sun+ether machine2 1025 master tcp sun+ether machine2 1025

серверная версия файла интерфейсов

клиентская версия файла интерфейсов

# DDSDBA1 query tcp sun+ether machinel 1025 # DDSDBA2 query tcp sun+ether machine2 1025

Рис. 12.1. Примеры файлов интерфейсов (для простоты используется формат SunOS) имени серверной машины и номера порта из файла интерфейсов. Это имя никак не влияет на соот" ветствующую запись таблицы sysseruers, значение которой можно выдать командой select @@servername Во"вторых, файл интерфейсов читается в процессе работы SQL Server, если необходимо устано" вить соединение с любым другим сервером сети. Сервер "считает доступными только те серверы, ко" торые описаны в его файле интерфейсов. Поэтому он может взаимодействовать только с серверами, описанными в файле интерфейсов, имя которого указано в командном файле запуска сервера. Если командный файл не содержит имени файла интерфейсов, оно дано в переменной сре" ды SYBASE. (Точнее, переменная SYBASE определяет только название каталога, в котором должен находится файл интерфейсов с именем "interfaces".) Найдя в файле интерфейсов описание удаленно" го сервера, SQL Server определяет из строки "query" сетевое имя серверной машины удаленного сер" вера и номер его порта. В"третьих, любая программа"клиент, которой необходимо подключиться (log in) к SQL Server, на" ходит в файле интерфейсов описание необходимого ей сервера и узнает имя серверной машины и номер порта. Все клиенты должны применять только клиентскую версию файла интерфейсов (см. рис. 12.1). Отметим, что имя сервера, используемого по умолчанию, задается в переменной среды DSQUERY. Поэтому в случаях, когда при запуске программы isql или другого пользовательского приложения имя сервера не было указано явно, приложение использует сервер с именем, определя" емым из переменной DSQUERY. В любом случае оно должно найти в файле интерфейсов сервер с соответствующим именем. Если связь с сервером невозможна, необходимо проверить, правильно ли установлена переменная среды DSQUERY (или явно указанное имя сервера) и наличие описания со" ответствующего сервера в файле интерфейсов. Файл интерфейсов имеет огромное значение для нормального запуска и работы SQL Server и должен содержать полное и точное описание (сетевое имя машины + номер порта) всех взаимодей" ствующих друг с другом серверов и других программных продуктов. Поэтому в вашей системе баз данных должен использоваться только один файл интерфейсов. Главные копии его клиентской и серверной версий должны храниться в одном стандартном месте. Оттуда серверная версия копиру" ется на все серверы, а клиентская — на клиентские машины, а также файл"серверы, обеспечивающие работу клиентских машин. Подобный подход гарантирует, что каждый сервер получит копию файла интерфейсов с полным описанием всех других серверов системы баз данных, а клиенты смогут ра" ботать только с теми серверами, которые вы включите в клиентскую версию интерфейсного файла. На первый взгляд может показаться, что использование двух версий интерфейсного файла явля" ется искусственной попыткой усложнить работу администратора баз данных. Однако мы готовы

www.books-shop.com

серверная версия файла интерфейсов DDSDBA1_TESTING query tcp sun+ether machine1 1925 master tcp sun+ether machine1 1925 console tcp sun+ether machine1 1926 # DDSDBA2 query tcp sun+ether machine2 1025 master tcp sun+ether machine2 1025

клиентская версия файла интерфейсов

# ODSDBA1 query tcp sun+ether machine1 1025 # DDSDBA2 query tcp sun+ether machine2 1025

Рис. 12.2. Примеры конфигураций интерфейсных файлов, позволяющие изолировать сервер DDSDBA1 от пользователей (для простоты используется формат SunOS) привести пример, показывающий всю важность подобного подхода. Предположим, что вам необхо" димо изолировать от пользователей один из серверов системы для его тестирования. Конечно, это можно сделать путем его перезапуска в однопользовательском режиме. Но кто гарантирует, что именно вы окажетесь тем самым единственным пользователем изолированного сервера? Можно пе" ревести все базы данных в режим доступа только для пользователя dbo. Но тогда вы лишитесь воз" можности полномасштабного тестирования сервера, поскольку не сможете подключиться к нему в качестве обыкновенного пользователя при проверке правильности разграничения прав доступа и т.п. Значительно проще изолировать сервер с помощью модификации серверной версии файла ин" терфейсов, изменив в этом файле имя сервера и номера используемых им портов (см. рис. 12.2). Указав в командном файле запуска сервера его новое имя DDSDBA1_TESTING, вы заставите сервер после запуска прослушивать порт 1925 серверной машины machine1. При этом подключиться к сер" веру смогут только пользователи, которых известили об изменении имени сервера и номера его порта. Пользователям, принимающим участие в тестировании сервера DDSDBA1_TESTING, придет" ся работать непосредственно с серверной машины, где они смогут воспользоваться локальной моди" фицированной копией файла интерфейсов. Они могут также создать на своих клиентских машинах временный интерфейсный файл, содержащий необходимые изменения. Все остальные пользовате" ли, имеющие прежнюю копию клиентской версии файла интерфейсов, не смогут подключиться к несуществующему серверу DDSDBA1 через неиспользуемый порт 1025 серверной машины machine1. Отметим, что одновременное изменение имени сервера и номера его порта было продиктовано соображениями безопасности. Предположим, вы изменили только номер порта. Потом кому"то по" надобится повторно распространить главную копию серверного файла интерфейсов по всем маши" нам. В результате у сервера восстановится прежний номер порта, и он внезапно станет доступным для всех пользователей, причем вы об этом вообще не узнаете. Изменение имени сервера одновре" менно с номером порта позволит избежать подобной ситуации, поскольку случайно разосланная прежняя копия файла интерфейсов восстановит не только номер порта, но и прежнее имя сервера. Однако в командном файле запуска сервера сохранится его модифицированное имя DDSDBA1_TESTING, и тестируемый сервер не сможет отвечать на запросы, адресованные серверу DDSDBA1 (ему вообще не удастся найти в файле интерфейсов собственное описание и, следователь" но, узнать номер своего порта). Разумеется, администратор сервера также потеряет возможность со" единиться с тестируемым сервером. Все попытки подключиться к серверу DDSDBA1_TESTING вызовут сообщение об ошибке "server not found in interface file" — "имя сервера не найдено в файле интерфейсов". Для решения проблемы будет достаточно восстановить изменения в локальной

www.books-shop.com

304

Глава 12

копии серверного файла интерфейсов и заново подключиться к тестируемому серверу, все это время остававшемуся недоступным для пользователей. Важно подчеркнуть, что в начале строк "master", "query" и "console" файла интерфейсов не дол" жны указываться пробелы. Каждая такая строка обязательно начинается с одного символа табуля" ции. В противном случае сервер не сможет прочитать такую строку, и вы получите сообщение об отсутствии сервера в файле интерфейсов. Эта ошибка особенно неприятна из"за того, что ее невоз" можно обнаружить при распечатке содержимого файла интерфейсов на экране. Кроме того, подоб" ная проблема может встретиться и в других случаях. Например, перемещая файл интерфейсов с одной машины на другую с помощью обычной программы ftp, передачу файлов необходимо осуще" ствлять в двоичном режиме (binary mode). Если это требование не выполняется, переданный файл будет выглядеть совершенно нормально, но вместо символов табуляции в началах строк будут сто" ять пробелы. Таким образом, в непонятных ситуациях с файлом интерфейсов обязательно убеди" тесь, что в начале строк описания сервера, с которым вам не удается соединиться, нет пробелов. Преобразование файла интерфейсов SunOS в формат системы Solaris Форматы файлов интерфейсов, используемых в операционных системах SunOS и Solaris, отличаются друг от друга. Хотя оба формата файлов интерфейсов содержат идентичную информацию, способ ее кодирования в системе Solaris крайне затрудняет чтение соответствующего файла интерфейсов. Тем не менее администратор сервера должен уметь преобразовывать файлы интерфейсов из одного фор" мата в другой. Для создания файла интерфейса в формате Solaris можно воспользоваться утилитой sybtli (находящейся в каталоге $SYBASE/bin). Кроме того, утилита sybinit версии System 10 (а также аналогичная утилита sybconfig для SQL Server 4.9.2) способны создавать файл интерфейсов как в фор" мате SunOS, так и в формате Solaris. Однако, версия утилиты sybinit для System 11 поддерживает толь" ко формат системы Solaris (поскольку, как не раз отмечалось ранее, SQL Server System 11 вообще не способен работать под управлением SunOS). Таким образом, вам необходимо научиться вручную пре" образовывать файл интерфейсов из одного формата в другой — на тот случай, если у вас не окажется полного комплекта необходимых утилит. Ваш Sybase SQL Server продолжает безупречно работать на старой машине с системой SunOS. Однако новые клиентские машины начинают поступать уже с системой Solaris, и требующийся им файл интерфейсов должен содержать описание вашего прежнего сер+ вера в этом формате. К сожалению, на клиентских машинах нет полного набора утилит Sybase. Единственный выход — вручную преобразовать описание сервера из формата SunOS в формат Solaris. Подобные истории происходят сплошь и рядом. Файл интерфейсов в формате Solaris Ниже приводится типичный пример файла интерфейсов в формате, принятом в операционной сис" теме Solaris. Этот файл содержит описание SQL Server System 11 вместе с сервером архивации Backup Server, а также SQL Server версии 4.9.2

## THEBIRDS11 on thebirds ## Services: ## query tcp (5001) ## mastertcp (5001) THEBIRDS11 query tli tcp /dev/tcp \x000213898196c4510000000000000000 master tli tcp /dev/tcp \x000213898196c4510000000000000000 ## THEBIRDS11_BCK on thebirds ## Services: ## query tcp (5002)

##

master tcp (5002)

THEBIRDS11_BCK query tli tcp /dev/tcp \x0002138a8196c4510000000000000000 master tli tcp /dev/tcp \x0002138a8196c4510000000000000000 #

# THEBIRDS492 on thebirds (129.150.196.81) using tcp

www.books-shop.com

# services: query (1025) master (1025) console (1026) # THEBIRDS492 query tli tcp /dev/tcp \x000204018196c4510000000000000000 master tli tcp /dev/tcp \x000204018196c4510000000000000000 console tli tcp /dev/tcp \x000204018196c4510000000000000000 Преобразование строки файла интерфейсов Solaris в формат SunOS Преобразуем в формат SunOS одну из строк приведенного выше файла интерфейсов в формате Solaris: THEBIRDS492 master tli tcp /dev/tcp \x000204018196c4510000000000000000 Шестнадцатиричные значения Десятичные значения х0002 заголовок не используется в SunOS 0401 номер порта 1025 (х0401 = 4*16*16 + 1*1) 81 IP адрес 1 129 (х81 = 8*16 + 1*1) 96 IP адрес 2 150 (х96 = 9*16 + 6*1) с4 IP адрес 3 196 (хс4 = 12*16 + 4*1) 51 IP адрес 4 81 (х51 = 5*16 + 1*1) Таким образом, соответствующая строка в формате SunOS выглядит как THEBIRDS492 master tcp sun"ether thebirds 1025 где thebirds является сетевым именем машины с IPадресом 129.150.196.81. Преобразование строки файла интерфейсов SunOS в формат Solaris Здесь мы рассмотрим порядок обратного преобразования, выбрав в качестве примера описание сер вера архивации SQL Server System 11. Поскольку System 11 SQL Server поддерживает только систему Solaris, будем считать, что в данном примере речь идет об сервере архивации System 10. THEBIRDS_BCK master tcp sun"ether thebirds 1026 Пусть машина с сетевым именем thebirds имеет IPадрес 129.150.196.81: Десятичные значения Шестнадцатиричные значения 1026 0402 (1026/16*16 = 4, 1026 " (4*16*16) = 2) 129 81 (129/16 = 8, 129 " 8*16 = 1) 150 96 (150/16 = 9, 150 " 9*16 = 6) 196 с4 (196/16 = 12, 196 " 12*16 = 4) 81 51 (81/16 = 5, 81 " 5*16 = 1) Обратите внимание на то, что номер порта был преобразован в четырехзначное шестнадцати ричное число (1026 > 0402). Файл интерфейсов в формате SunOS В этом разделе мы приведем файл интерфейсов в формате SunOS, полностью эквивалентный рас смотренному выше файлу формата Solaris. Поскольку SQL Server System 11 не работает в системе SunOS, предположим, что речь идет о System 10 версии SQL Server и сервера архивации. # THEBIRDS11 query tcp sun#ether thebirds 5001 master tcp sun#ether thebirds 5001 # THEBIRDS11_BCK query tcp sun#ether thebirds 5002 master tcp sun#ether thebirds 5002

www.books-shop.com

# THEBIRDS492 query tcp sun#ether thebirds 1025 master tcp sun#ether thebirds 1025 console tcp sun#ether thebirds 1026 Сетевое взаимодействие серверов Для успешного сетевого взаимодействия двух серверов с использованием удаленного вызова проце" дур (Remote Procedure Calls, RPC) — когда каждый из серверов запускает RPC"процедуры на машине другого сервера — нужна тщательная разработка их конфигурации. В этом разделе рассматриваются основные этапы этого процесса и покажем читателю, как можно проверить текущее состояние сете" вого взаимодействия между серверами. Прежде всего, конфигурация каждого из серверов должна разрешать удаленный доступ к этому серверу (см. рис. 12.3). Это достигается установкой соответствующего конфигурационного парамет" ра, например, командой sp_configure "remote access", 1. Во"вторых, файл интерфейсов каждого сервера должен содержать описание другого сервера. Здесь окажется полезной единая централизованная серверная версия файла интерфейсов, о кото" рой мы говорили выше. Клиентская версия файла интерфейсов может и не содержать информацию обо всех удаленных серверах. В нее следует включить описание только серверов, непосредственно открытых для пользователей. Если пользователю одного сервера потребуется направить RPC"вызов на другой сервер, это обращение будет направлено через первый сервер, который найдет описание второго сервера в своем файле интерфейсов. В третьих, каждый сервер должен содержать описание другого сервера в своей системной табли це sysseruers (см. рис. 12.3). Она включает в себя информацию, позволяющую серверу определить, к какому именно удаленному серверу ему необходимо обращаться. Перед просмотром файла 1> sp configure 2>go name

конфигурация сервера В

minimum

maximum

4 0 0 0 0 0 0

256 1 2147483647 2147483647 2147483647 2147483647 2147483647

devices remote access remote logins remote sites remote connections pre+read packets upgrade version

1> select * from sysservers 2>go srvid srvstatus srvname srvnetname 0 1 2

0 1 1

config_value

30 1 64 10 128 0 491

run_value

30 1 64 10 128 3 491

таблица sysservers сервера В

serverB SERVERB serverA SERVERA serverC SERVERC

1 > select * from sysremotelogins 2>go remoteserverid remoteusemame NULL NULL

таблица sysremotelogins сервера В suid

status

+1 +1

Рис. 12.3. Поддержка удаленных обращений с сервера А на сервер В

www.books-shop.com

интерфейсов сервер находит в таблице sysseruers имя требуемого удаленного сервера. В этой таблице каждый удаленный сервер фактически получает два имени. Внутреннее имя srvname используется первым сервером при вызове удаленного сервера. Внешнее (сетевое) имя srvnetname указано в фай" ле интерфейсов первого сервера. Это позволяет запустить на нескольких серверах приложение, в которое жестко встроено имя используемого сервера (например "servernamel"). В таблице sysseruers каждого из серверов внутреннему имени servernamel в качестве внешнего псевдонима присваивает" ся имя самого этого сервера, чтобы заставить приложение обращаться к серверу, работающему на данной локальной машине. Процесс, описанный выше, происходит при взаимодействии с сервером архивации Backup Server. SQL Server System 10 и System 11 способны создавать и загружать дампы только через сервер архивации. Он представляет собой открытое серверное приложение. Поэтому он выступает по от" ношению к SQL Server в качестве удаленного сервера. Внутреннее имя сервера архивации SYB_BACKUP жестко встроено в каждый SQL Server. Это может привести к проблемам, как только в вашей системе появляется второй SQL Server, поскольку каждый SQL Server будет обращаться к сер" веру архивации по имени SYB_BACKUP. При установке SQL Server и сервера архивации программа sybinit (см. главу 13) по умолчанию присваивает значение SYB_BACKUP параметрам srvname и srvnetname таблицы sysservers. При вызове сервера архивации по внутреннему имени (srvname) SYB_BACKUP все серверы баз данных системы определят, что в качестве его сетевого имени (srvnet пате) также указано SYB_BACKUP. Серверы найдут в своих идентичных серверных файлах интер" фейсов описание сервера архивации с именем SYB_BACKUP и дружно обратятся к одному и тому же порту одной и той же серверной машины, на которой действительно работает сервер архивации с указанным именем. Эти операции были бы не нужны, если на каждом сервере имелся бы индивидуа" льный файл интерфейсов, указывающий на локальную копию сервера архивации SYB_BACKUP. Мы не раз говорили о преимуществах, которые бы дала единая копия файла интерфейсов, действующая в масштабах всей информационной системы. Реальное решение проблемы дает модификация значе" ний сетевого имени (srvnetname) сервера архивации в таблице sysservers каждого отдельного SQL Ser" ver. Именами индивидуальных серверов архивации проще всего выбрать <имя_сервера>_BСК., где в качестве имени_сервера указывается имя соответствующего SQL Server. Теперь при обращении к серверу архивации по внутреннему имени SYBJBACKUP (srvname из таблицы sysservers) SQL Server со" поставит это имя с сетевым именем <имя_сервера>_BСК. (srvnetname из таблицы sysservers). Под этим именем в общем файле интерфейсов будет найден локальный сервер, работающий на той же самой машине. Важно подчеркнуть, что, изменив внутреннее имя сервера архивации (srvname = SYB_BACKUP), вы не сможете его использовать в работе SQL Server. В"четвертых, таблица sysremotelogins каждого сервера должна содержать строку, определяющую ха" рактер обработки запросов на соединение (remote logins), поступающих со стороны удаленных сер" веров. В приведенном на рис. 12.3 примере установлены значения параметров suid = "1 и status = 0. Это означает, что при поступлении на сервер В любого RPC"вызова с сервера А, имеющего то же са" мое учетное имя, учетная информация пользователей серверов А и В будет сопоставлена. Запрос бу" дет выполнен только при совпадении паролей пользователя на обоих серверах. Несовпадение паролей или отсутствие пользователя сервера А в числе пользователей сервера В приведет к отказу в выполнении RPC"вызова. Подобная схема обработки удаленных запросов является наиболее безо" пасной, но она требует идентичности списков пользователей на всех серверах. Можно также устано" вить соответствие некоторых пользователей сервера А с другими пользователями сервера В и задать с помощью процедуры sp_remotelogin режим взаимного доверия между серверами, не требую" щий совпадения их пользовательских паролей. Администратор баз данных должен знать, какой ре" жим контроля запросов сконфигурирован на каждом из серверов его системы, и насколько надежные гарантии безопасности этот режим предоставляет. Обратите внимание на то, что каждый удаленный сервер, описанный в таблице sysservers, имеет уникальный идентификатор srvid, соответствующий параметру remoteserverid таблицы sysremotelogins. Это позволяет установить связь между описанием удаленного сервера в таблице sysservers и уровнем контроля за обращениями, поступающими от этого сервера. В нашем примере сервер А имеет иден" тификатор srvid = 1 в таблице sysservers. Ему в таблице sysremotelogins соответствует строка с remoteserve rid = 1 и рассмотренными выше значениями suid = "1 и status = 0. В"пятых, локальный SQL Server, инициирующий RPC"вызов, должен обладать собственным внут" реннем именем. Оно описано в его таблице sysservers под идентификатором srvid = 0 и выдается командой select @@servername (т.е. результат ее выполнения не должен быть NULL). Итак; в приведенной выше конфигурации требуется, чтобы каждый пользователь сервера А, об" ращающийся с RPC"вызовами на удаленный сервер В, имел на этих серверах идентичные системные

www.books-shop.com

имена и пароли. Процедура sp_remotelogin позволит изменить или вообще отменить подобные требования. Для проверки возможности взаимодействия серверов А и В, подключитесь командой isql к сер" веру А и введите команду execute server В ... sp_who. Если ответом будет список пользователей сервера В, значит успешное обращение сервера А к серверу В возможно. Для проверки взаимодейст" вия в противоположном направлении, подключитесь командой isql к серверу В и введите команду execute server A. . .sp_who. Отметим, что имя сервера, указываемое в команде execute перед конструкцией . . . sp_who, зависит от конкретного содержимого таблицы sysseruers каждого сервера. Другими словами, для того, чтобы команда execute server В ... sp_who могла быть выполнена на сервере А, в его таблице sysseruers второй сервер должен быть описан под именем server В. Под" черкнем, что речь идет здесь о внутреннем имени (srvname) сервера В, под которым он известен сер" веру А. Сетевое имя сервера В, указанное в параметре srvnetname той же таблицы sysseruers, может быть любым. (Если оно позволит серверу А успешно найти нужный удаленный сервер в своем файле интерфейсов.) Преобразование командных файлов SQL и выдачи утилиты defncopy в хранимые процедуры Часто возникает необходимость поместить готовый SQL"командный файл на сервер базы данных в качестве командной процедуры. Для этого в заголовок отлаженного командного файла на языке SQL достаточно добавить предложение create procedure <название_хранимой_процедуры> as а в конец файла — команду до. Кроме того, при модификации существующей хранимой процедуры, в файл перед оператором create procedure также включите предложение drop procedure <название_хранимой_процедуры> as и команду до. Используя утилиту defncopy для создания SQL"определений объектов баз данных и их последу" ющего применения при создании хранимых процедур или триггеров, в надлежащие места файла также вставьте предложения drop procedure и create procedure (либо drop trigger и create trigger), а также соответствующие команды go. Системная таблица sysusages Хранящаяся в базе данных master системная таблица sysusages имеет большое значение. Однако ее роль часто понимают совершенно неправильно. Таблица sysusages содержит информацию о размещении компонентов каждой базы данных по дисковым устройствам сервера. Каждая строка этой таблицы описывает определенную область дискового пространства (экстент), распределенную одной из баз данных сервера, например, в результате выполнения команд create database или alter data" base. Записи таблицы sysusages указывают точное местонахождение соответствующей дисковой обла" сти на серверных устройствах и физических дисках и состав сегментов базы данных, назначенных данной области (столбец segmap). Схема хранения всей подобной информации в таблице sysusages весьма запутана. В нескольких разделах главы последовательно рассматриваются различные параметры, входящие в состав каждой строки таблицы sysusages. На рис. 12.4 показан фрагмент таблицы sysusages и нескольких связанных с нею таблиц. Идентификатор базы данных Столбец dbid таблицы sysusages соответствует столбцу dbid другой системной таблицы sysdatabases и по" зволяет сопоставить каждый фрагмент дискового пространства с именем (database name) использую" щей его базы данных. Таким образом, с помощью dbid устанавливается соответствие записей таблицы sysusages определенным базам данных сервера. В качестве примера проследим в таблицах рис. 12.4 за" писи, относящиеся к базе данных db1 с идентификатором dbid= 4. Следует иметь в виду, что порядок записей таблицы sysusages, относящихся к одной базе данных (т.е. имеющих одно и то же значение dbid), соответствует порядку создания указанных в ней экстентов этой базы данных. Базе данных dbl соответствуют три последние строки таблицы sysusages. Они полностью определяют размер и поря" док создания каждого фрагмента дискового пространства, распределенного этой базе данных.

www.books-shop.com

1> select * from sysusages 2>go dbid segmap start size vstart

1 1 2 2 2 3 4 4 4

0 1536 4 1024 3588 1536 0 1024 2564 1024 51200 251658240 52224 51200 268435456 0 1024 1540 0 5120 201326592 5120 2560 218103808 7680 5120 201331712

7 7 1 3 4 7 3 4 3

фрагмент таблицы sysdatabases

dbid database name 1 2 3 4

таблица sysusages

master tempdb model db1

low. 184549376 201326592 218103808 234881024

high 184733445 201510661 218287877 235132235

device_fragments sd4f sd4f sd4g

status

cntrltype

738 738 738 738

0 0 0 0

size

usage

10 MB 10MB 5 MB

data only data only log only

device

segment

sd4f sd4f

default system

name phyname sd4e sd4f sd4g sd4h

фрагмент таблицы sysdevices

/dev/rsd4e /dev/rsd4f /dev/rsd4g /dev/rsd4h

фрагмент выдачи ко

Рис. 12.4. Таблица sysusages и связанные с ней системные таблицы Размер экстента Итак, каждая строка таблицы sysusages определяет один экстент базы данных, размер которого указан в столбце size. Три экстента базы данных db1 имеют размеры в 5120, 2560 и 5120 2"килобайтных стра" ниц. Это соответствует общему объему базы данных dbl, равному 12800 2"килобайтных страниц, или 25 Мбайт.

Размещение областей базы данных Местонахождение каждого экстента базы данных можно узнать из значения столбца vstart. Именно здесь в игру вступают виртуальные номера серверных устройств (vdevno), задаваемые при инициали" зации серверных устройств командой disk init. Каждая 2"килобайтная дисковая страница сервера имеет свой уникальный виртуальный номер страницы, однозначно определяющий ее в рамках всего сервера. Кроме того, каждая страница данных также имеет уникальный в пределах этой базы данных логический номер. Поэтому каждая строка таблицы sysusages содержит поле Istart — логический номер первой страницы дискового фрагмента в базе данных, использующий этот экстент. Для каждой базы данных значение параметра Istart последовательно увеличивается от одной записи sysusages к следую" щей на количество страниц очередного экстента. В нашем примере, первый экстент базы данных dbl начинается с Istart = 0 и имеет размер в 5120 страниц данных, пронумерованных от 0 (номер первой страницы является значением Istart) до 5119. Соответственно, следующий экстент базы данных начи" нается с Istart = 5120 и имеет длину в 2560 страниц (их номера находятся в диапазоне от 5120 до 7679) и т.д. Логические номера страниц последовательно возрастают от сегмента к сегменту. Однако этого нельзя сказать о виртуальных номерах страниц (столбец vstart). Значение vstart каждой записи

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

таблицы sysusages — это виртуальный номер первой страницы соответствующего экстента. Виртуаль" ные номера страниц зависят не только от логического номера Istart, но и от виртуального номера сер верного устройства vdevno, на котором находится фрагмент дискового пространства, а также от положения этого фрагмента на устройстве. Именно по этой причине два серверных устройства не могут иметь одинаковые виртуальные номера устройств. Ведь виртуальный номер страницы vstart за" висит от vdevno и должен быть уникальным в рамках всего сервера. Теперь выясним расположение каждого фрагмента дискового пространства на серверных устройствах. Сделать это можно с помощью системной таблицы sysdevices. В ней для каждого сервер" ного устройства (поддерживаемого разделом физического диска или файлом операционной систе" мы) указаны значения виртуального номера первой (low) и последней (high) страниц данных этого устройства. Сопоставляя эти значения с данными столбца vstart таблицы sysusages, мы можем легко установить, на каком серверном устройстве находится каждый экстент базы данных. Ни одна запись таблицы sysusages не может выйти за пределы одного серверного устройства. Это объясняется тем, что при выполнении команд create database или alter database, вносящих новые записи в таблицу sysusages, сервер обнаружит переполнение соответствующего устройства и будет вынужден сократить размер распределяемой области дискового пространства. Поэтому не нужно проверять, помещается ли последняя страница каждого фрагмента дискового пространства, фигурирующего в таблице sysusages, в серверное устройство, содержащее начало этого экстента. (Оно было найдено пу" тем сравнения виртуального номера первой страницы экстента vstart с указанным в таблице sysusages диапазоном виртуальных номеров страниц (low — high) всех устройств сервера.) В нашем примере первый экстент базы данных db1 имеет vstart = 201326592, что свидетельствует о его размещении в самом начале серверного устройства sd4f (low = 201326592, high = 201510661, см. рис. 12.4). Назначение сегментов экстентам баз данных Структуру и особенности сегментов баз данных подробно рассматривалась в главе 8. Сейчас отметим лишь, что каждый фрагмент дискового пространства, соответствующий одной записи таблицы sysusa ges, может быть назначен нескольким сегментам базы данных одновременно. Состав сегментов, объ" екты которых могут находится в данном экстенте, определяется значением столбца segmap. Информация о назначении сегментов каждой отдельной записи таблицы sysusages представляется в поле segmap этой записи с использованием не вполне обычного метода. По сути, каждое значение столбца segmap представляет собой битовый массив, отдельные биты которого указывают на наличие или отсутствие соответствующего сегмента в данном экстенте базы данных. Для построения значе" ния поля segmap по известному списку сегментов каждому типу сегмента присваивается определенный код (см. табл. 12.2). Его битовое представление имеет единицу в поле данного типа сегмента и ноль во всех остальных полях массива. Итоговый вид двоичного массива можно получить, вычислив логиче" ское "ИЛИ" двоичных кодов всех имеющихся сегментов, т.е. установив единицы в поля, указывающие на наличие реально имеющихся сегментов, и нули во все остальные поля двоичного массива. Значе" ние segmap является представлением полученного двоичного массива в десятичной системе счисле" ния. Это значение равно сумме кодов всех имеющихся сегментов. Таблица 12.2. Коды сегментов и их представление в двоичном массиве segmap Тип сегмента

Код сегмента

Двоичное представление кода сегмента

system

1

000001

default

2

logsegment

4

000100

первый пользовательский сегмент

8

001000

второй пользовательский сегмент

16

010000

третий пользовательский сегмент

32 и т.д.

100000

,

000010

Обратите внимание на то, что коды сегментов являются последовательными степенями двойки (что очевидно из последнего столбца таблицы 12.2). Значение поля segmap является суммой кодов всех сегментов, присутствующих в экстенте базы данных. Поэтому при совместном размещении сег" ментов system, default и logsegment (неизбежном в случае базы данных master) соответствующий диско" вый фрагмент получает значение segmap = 7. Фрагменты базы данных, содержащие только сегмент

www.books-shop.com

журнала транзакций logsegment, имеют значение segmap = 4. Важно отметить, что код сегмента удваи" вается с каждым очередным номером пользовательского сегмента базы данных, увеличиваясь от 8 до 16, 32, 64, 128 и т.д. Поэтому значение segmap = 128 отнюдь не свидетельствует о наличии в эк" стенте 128 различных сегментов базы данных. На практике, segmap никогда не принимает всех воз" можных значений (например, от 1 до 128). Как правило его величина составляет 3 (1+2), 4 или 8. Записи об экстентах баз данных нельзя удалять вручную (кроме базы данных tempdb) Объяснив читателю значение строк таблицы sysusages, мы должны немедленно подчеркнуть, что раз" меры базы данных не могут сокращаться путем удаления отдельных строк из этой таблицы. Единст" венным исключением из этого правила служит база данных tempdb. Для ее уменьшения из таблицы sysusages можно удалить записи о любых экстентах tempdb, за исключением расположенной на сервер" ном устройстве master первой 2"мегабайтной области tempdb (которую нельзя удалять ни при каких об" стоятельствах). Чтобы сократить базу данных tempdb, после удаления всех необходимых записей таблицы sysusages следует перезапустить сервер. Более подробно этот процесс описан в руководстве по устранению неполадок SQL Server (SQL Server Troubleshooting Guide). Модификация таблицы sysusages вручную При каждом внесении изменений в системные таблицы сервера вручную следует соблюдать перечис" ленные ниже основные меры предосторожности (см. также раздел "Модификация системных таблиц SQL Server вручную" ниже в данной главе). Внимание! 1. Модификация содержания системных таблиц не поддерживается компанией Sybase. Компа" ния не гарантирует, что различные версии сервера будут иметь одинаковую конфигурацию системных таблиц. Поэтому эта операция, выполненная в одной версии SQL Server, может оказаться неприменимой к другой версии сервера. 2. Перед изменением содержания системных таблиц обязательно проконсультируйтесь со службой технической поддержки Sybase. 3. Перед внесением изменений проверьте, имеется ли у вас полный набор дампов, необходи" мый для восстановления сервера в случае, если вносимые изменения приведут к наруше" нию его работоспособности. 4. После модификации системных таблиц для активизации внесенных изменений необходи" мо произвести перезапуск сервера. Системные хранимые процедуры sp_addsegment, sp_extendsegment и sp_dropsegment ав" томатически проверяют все записи таблицы sysusages, относящиеся к базе данных и серверному устройству, указанным при вызове процедуры. Затем они вносят необходимые изменения в поле seg" map каждого дискового фрагмента. Именно этот механизм предотвращает назначение других сег" ментов базы данных серверному устройству, поддерживающему сегмент журнала транзакций. (Напомним, что logsegment имеет значение segmap = 4.) Он также не позволяет назначить log" segment серверному устройству, уже содержащему сегменты этой же базы данных. При распро" странении базы данных на серверное устройство командами create database или alter database (т.е. когда в таблице sysusages создается запись о первом экстенте распространяемой базы данных, расположенном на этом устройстве) поле segmap получает значение 7 или 3 (т.е. новому эк" стенту назначаются сегменты system, default и logsegment либо только system и default). При создании на новом устройстве каких"либо объектов базы данных, относящихся к сегментам system или default, страницы данных этих объектов будут помечены как принадлежащие этим сегментам. Попытка вручную установить в рассматриваемой записи значение поля segmap = 4, т.е. распределить все остав" шееся пространство экстента базы данных ее сегменту журнала транзакций, приведет к тому, что сервер не запишет в этот экстент страницы данных, не относящиеся к журналу транзакций. Однако в экстенте останется некоторое количество страниц данных сегментов system или default. Это не по" зволит серверу сохранить дамп журнала транзакций командой dump transaction. Пока все стра" ницы распределенных базе данных областей серверного устройства не станут доступными журналу транзакций, принудительная установка значения поля segmap, соответствующего наличию только сегмента журнала транзакций, не позволит сохранить отдельные дампы журнала транзакций. Здесь мы сталкиваемся с противоречием. Используя только стандартные хранимые процедуры, администратор сервера в принципе не может установить значение segmap = 4 для любого экстента базы данных, которым назначены посторонние сегменты. Однако вы в любой момент можете

www.books-shop.com

вручную установить требуемое значение путем прямой модификации системной таблицы sysusages. Подобную операцию следует выполнять, имея серьезные причины, предварительно составленный план действий и полный комплект свежих дампов баз данных. Внесение произвольных изменений в системные таблицы далеко не всегда приводит к ожидаемым эффектам. Во всех нормальных ситуа" циях мы рекомендуем читателю пользоваться стандартными хранимыми процедурами. Однако в некоторых случаях администратору сервера все же приходится прибегать к модифика" ции системных таблиц вручную. Хотя подобные методы работы официально не поддерживаются Sy" base, читателю все же следует знать об их существовании. При необходимости быстрого восстановления базы данных в команде create database указывается параметр for load. В результате все экстенты воссоздаваемой базы данных получают значение seg тар = 3, за исключением одного с segmap = 4 (здесь мы предполагаем, что одна из строк предложения create database содержала параметр log on). Завершив команду create database for load, вы должны загрузить дамп базы данных. После этого, используя процедуры sp_addsegment, sp_extendsegment и sp_dropsegment, вручную разнесите сегменты базы данных по правильным серверным устройствам. Этим вы восстановите в таблице sysusages ранее существовавшие значения полей segmap всех экстентов базы данных. Правильное выполнение всех процедур манипулирования сегментами (со строгим соблюдением их очередности) представляет собой весьма утомительное за" нятие, особенно для больших баз данных, расположенных на множестве серверных устройств. Зна" чительно проще внести нужные изменения непосредственно в записи таблицы sysusages, основываясь на значениях полей Istart записей sysusages, относящихся к загруженной таблице данных. Отметим, что значения полей vstart зависят от виртуальных номеров серверных устройств vdevno. Поэтому они могут измениться, если при восстановлении сервера его устройства были проинициа" лизированы командой disk init в другом порядке. Однако значения параметров Istart остаются прежними при условии, что порядок создания экстентов базы данных и их размеры соответствова" ли первоначальным. В результате мы получаем возможность использовать Istart при установке полей segmap вручную. При этом значение segmap зависит от диапазона значений Istart. Снова обратимся к базе данных db1. Предположим, что она была воссоздана командой create database с параметром for load. Эта команда восстановила в таблице sysusages три записи, сохра" нив порядок их следования и размеры соответствующих фрагментов дискового пространства. Можно приступить к восстановлению прежних значений полей segmap этих записей. Напомним, что любая операция по модификации sysusages (или любой другой системной таблицы) должна вы" полняться как единая транзакция, т.е. начинаться командой begin tran <название_транзак" ции>, что позволит в случае ошибок воссоздать исходное состояние таблицы sysusages. Найдем все записи таблицы sysusages, имеющие dbid = 4, после чего установим segmap = 3 для записей со значе" нием поля Istart в диапазоне от 0 до 5119. Напомним, что в прежней базе данных dbl (см. рис. 12.4) первый экстент с segmap = 3 имел длину в 5120 страниц (10 Мбайт). Мы не случайно говорим здесь обо "всех записях со значением поля Istart в диапазоне от 0 до 5119". Из"за изменившейся структу" ры свободных областей серверных устройств сервер может отказаться снова выделить 10 Мбайт в качестве единого фрагмента дискового пространства. Тогда прежней области базы данных будут соответствовать два экстента длиной, например, в 7 и 3 Мбайт, представленные в таблице sysusages двумя отдельными записями. Перейдя к следующим записям sysusages, соответствующим базе дан" ных dbl (dbid = 4), мы установим segmap = 4 для всех записей с Istart, находящимся в диапазоне от 5120 до 7679, a segmap = 3 — для записей со значением поля Istart, равным 7680 (или большим это" го числа). В итоге прежняя структура назначения сегментов областям базы данных окажется восста" новленной. Разумеется, описанный метод становится невозможным при отсутствии копии прежней таблицы sysusages. Это относится и к операции восстановления структуры базы данных вручную процедурой sp_createeegment и другими подобными командами. В них все равно потребуется указать исход" ные размеры экстентов базы данных с сохранением прежнего порядка их следования. Подобный процесс можно ускорить с помощью командного файла p_dbcreate, генерирующего все необходи" мые команды для воссоздания базы данных с параметром for load и ее сегментации путем моди" фикации записей таблицы sysusages (см. главу 14). Такой командный файл окажется крайне полезным при восстановлении базы данных на прежнем сервере. Им можно воспользоваться и для переноса базы данных на другой сервер, поскольку и в этом случае вам потребуется создать прежний набор экстентов базы данных для сохранения ее сегментации. Желательно, чтобы структура и названия серверных устройств нового сервера совпадала со старым. В противном случае вам следует вырабо" тать схему соответствия серверных устройств старого и нового серверов, после чего вручную вста" вить названия новых устройств в выдачу p_dbcreate. Применение этого командного файла особенно удобно для создания копий баз данных на резервном сервере или сервере поддержки при" нятия решений.

www.books-shop.com

Команда load database и таблица sysusages Существует еще одна причина, в силу которой вам необходимо хорошо разбираться в структуре запи" сей таблицы sysusages. Как отмечалось выше, порядок записей таблицы sysusages, соответствующих опре" деленной базе данных, отражает порядок распределения этой базе данных областей дискового пространства. Именно в таком порядке производится запись базы данных в дамп, а также загрузка ее страниц из ранее созданного дампа. Поэтому при воссоздании базы данных (как на прежнем, так и на новом сервере) вновь распределяемые экстенты дискового пространства должны иметь прежние раз" меры и назначаться в прежнем порядке. Для базы данных db1 сначала создадим 10"мегабайтный экстент и назначим его сегментам system и default (segmap = 3). Затем — 5"мегабайтный экстент, содержащий сег" мент журнала транзакций (segmap = 4), и, наконец, еще один 10"мегабайтный экстент с segmap = 3. Вновь создаваемые экстенты базы данных могут быть образованы из нескольких отдельных областей дисково" го пространства, которым будут соответствовать несколько строк таблицы sysusages. Важно лишь, чтобы общий объем и порядок следования экстентов с одинаковыми значениями segmap оставались прежни" ми. В нашем примере загружаемый дамп базы данных dbl будет содержать 10 Мбайт страниц данных сегментов system и default (segmap = 3); 5 Мбайт журнала транзакций (segmap = 4); еще 10 Мбайт страниц данных, также относящихся к сегментам system и default. Все страницы данных должны попасть в обла" сти, назначенные соответствующим сегментам. Поэтому дробление подобных областей не имеет зна" чения при условии, что их размеры, порядок следования и состав назначенных сегментов соответствуют конфигурации, существовавшей на момент создания дампа. Если это соответствие нарушается, загружаемые страницы данных попадают в экстенты базы данных, назначенные другим сегментам. Например, страницы журнала транзакций вместо сегмента logsegment попадут в сегменты system и default (и наоборот). Это не скажется на возможности выборки данных из восстановленной базы данных, но фактически исключит процесс записи в любые ее сег" менты. Серверу придется записывать модифицированные страницы объекта данных сегмента default на серверное устройство, которое согласно таблице sysusages назначено исключительно сегменту журнала транзакций (segmap = 4). Подобные нарушения структуры базы данных могут иметь серьез" ные последствия, что заставляет нас быть крайне внимательными при воссоздании базы данных пе" ред ее загрузкой из дампа. Состав объектов сегмента базы данных Часто возникает необходимость проверить все сегменты базы данных, чтобы узнать, какие объекты данных находятся на каждом сегменте. Здесь нужно воспользоваться системной процедурой sp_hel" psegment. При вызове без параметров она перечисляет все сегменты текущей базы данных. При последующем ее вызове с указанием названия отдельного сегмента (sp_helpsegment <назва" ние_сегмента>) сервер выдаст список всех объектов базы данных, находящихся на указанном сег" менте, а также общее количество свободных 2"килобайтных страниц этого сегмента: machinel: isql "Usa "STHEBIRDS11 Password: 1> use psychodb 2> go 1> sp_helpsegment 2> go segment name ' status 0 system 0 1 default 1 2 logsegment 0 (return status = 0) 1> sp_helpsegment system 2> go segment name 0 system

status 0

www.books-shop.com

device cOt2dOs4 table_name sysalternates

size 350.0MB index_name sysalternates

(return status = 0) 1> sp_helpsegment "default" 2> go segment name status 1 default 1 device size cOt2dOs4 350.0MB table_name index_name psycho_actions spray_idx

(return status = 0 ) 1> sp_helpsegment logsegment 2> go segment name status 2 logsegment 0 device size C0t2d0s6 ' 50.0MB table_name index_name syslogs syslogs (return status = 0)

free_pages 21400 indid 1

free_pages 21400 indid 1

free_pages 25504 indid 0

Журнал регистрации ошибок Журнал регистрации ошибок SQL Server содержит большой объем важной информации, которая ока жется особенно необходимой при восстановлении сервера. В этот критический момент администра тору сервера придется воспользоваться журналом регистрации ошибок для уточнения многих существенных подробностей конфигурации сервера. В этом и нескольких следующих разделах главы рассматривается ряд основных сообщений, выдаваемых сервером в журнал регистрации ошибок. Затем эти сообщения будут приведены в примерах журналов регистрации ошибок SQL Server вер сий 4.9.2, System 10 и System 11. 1. Версия SQL Server 2. Местонахождение журнала регистрации ошибок 3. Максимальное число одновременных сеансов работы пользователей 4. Местонахождение серверного устройства master 5. Зеркальное резервирование серверного устройства master 6. Информация из файла интерфейсов 7. Имя сервера 8. Список серверных устройств и их зеркальных копий 9. Использование асинхронного вводавывода для серверных устройств 10. Процесс восстановления баз данных 11. Порядок сортировки и набор символов, используемые по умолчанию

www.books-shop.com

Версия SQL Server Первая строка журнала регистрации ошибок SQL Server содержит номер версии сервера и номер по" следнего исправления, внесенного в выполняемый модуль сервера (Emergency Bug Fix level, EBF). Местонахождение журнала регистрации ошибок В журнал регистрации ошибок выводится сообщение с именем файла регистрации ошибок. Скорее всего, это имя вам уже известно, но после перезапуска сервера следует просмотреть этот файл, чтобы убедиться, что журнал регистрации ошибок выдается туда, куда нужно. Максимальное число одновременных сеансов работы пользователей Журнал регистрации ошибок содержит информацию о предельном количестве дескрипторов фай" лов. Это количество определяет максимальное число пользователей, одновременно поддерживаемых сервером. Отметим, что конфигурация сервера может не предусматривать столько же одновременно установленных соединений. При необходимости количество доступных дескрипторов файлов может быть увеличено. Детали этой операции зависят от конкретной платформы; читатель найдет их в ру" ководстве по установке сервера (Sybase SQL Server Installation Guide) и приложении к руководству си" стемного администратора (System Administration Guide Supplement). Местонахождение серверного устройства master Из журнала регистрации ошибок администратор сервера может узнать название раздела физическо" го диска, на котором находится серверное устройство master. Как отмечалось в главе 7, при отсутст" вии у устройства master зеркальной копии название занимаемого им раздела не указывается в таблице sysdevices. В подобном случае журнал регистрации ошибок является единственным местом, где можно получить эту информацию. Она имеет особое значение при восстановлении этого устройства с помо" щью buildmaster или других подобных программ, когда сам сервер находится в состоянии останова. Отметим, что в журнале регистрации ошибок серверное устройство master фигурирует в качестве "виртуального устройства 0" (как уже отмечалось в книге, устройству master действительно соответст" вует vdevno = 0). Зеркальное резервирование серверного устройства master При зеркальном резервировании устройства master (а это устройство всегда должно иметь зеркаль" ную копию) название соответствующего дискового раздела выводится в журнал регистрации ошибок сервера. При каждом перезапуске сервера рекомендуем убедиться в успешном подключении зеркаль" ной копии устройства master к серверу. Информация из файла интерфейсов Журнал регистрации ошибок содержит название серверной машины и номер порта, используемого сервером. Имя сервера Из журнала регистрации ошибок читателе может узнать внутреннее имя сервера, содержащееся в таблице sysservers. Это имя можно изменить только вызовом процедуры sp_addserver с параметром local. В случае, если серверу не присвоено никакого имени, журнал регистрации ошибок будет со" держать сообщение "server is unnamed". Отметим, что имя сервера, указанное в процессе его установ" ки программой sybinit, используется исключительно при генерации командного файла RUN_<имя_сервера>, запускающего сервер. Список серверных устройств и их зеркальных копий В журнал регистрации ошибок выводится полный список имеющихся серверных устройств (которые в данном случае называются виртуальными устройствами) с указанием виртуального номера vdevno каждого устройства. При наличии у устройства зеркальной копии в журнал регистрации ошибок включается дополнительная строка "mirror: <название_дискового_раздела>". Использование асинхронного ввода+вывода для серверных устройств Выдавая список серверных устройств, сервер сообщает об использовании асинхронного режима вво" да"вывода для них. Следует проверить, все ли серверные устройства используют асинхронный ввод"вывод. При наличии в составе сервера устройств, поддерживаемых файлом операционной сис" темы, эта особенность устройства также отражается в журнале регистрации ошибок. Убедитесь, что каждое серверное устройство работает в правильном режиме ввода"вывода. 22—2221

www.books-shop.com

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

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

Пример журнала регистрации ошибок SQL Server 4.9.2 В распечатке файла регистрации ошибок рассмотренные выше сообщения отмечены коммента риями /* ... */. /home/DDSDBAl/errorlog 57 % more errorlog /* 1) Версия SQL Server */ 00: 95/04/01 14:53:42.20 kernel: SQL Server/4.9.2/EBF 2825 Rollup/Sun4/OS 4.1.2/1/OPT/Sat Apr 9 10:25:53 PDT 1994 /* 2) Местонахождение журнала регистрации ошибок */ 00: 95/04/01 14:53:42.27 kernel: Logging SQL Server messages in file '/home/DDSDBAl/bin/errorlog'. 00: 95/04/01 14:53:42.27 kernel: Using config area of disk for boot information 00: 95/04/01 14:53:42.39 kernel: kdconfig: opening secondary master device 00: 95/04/01 14:53:42.43 kernel: Using config area from primary master device. /* 3) Максимальное число одновременных сеансов работы пользователей */ 00: 95/04/01 14:53:42.69 kernel: Using 2048 file descriptors. 00: 95/04/01 14:53:42.69 kernel: Network and device connection limit is 2043. 00: 95/04/01 14:53:42.71 kernel: Dump/Load buffers configured with 8 pages. /* 4) Местонахождение серверного устройства master */ 00: 95/04/01 14:53:42.99 kernel: Initializing virtual device 0, "/dev/rsd4b" /* 5) Зеркальное резервирование серверного устройства master */ 00: 95/04/01 14:53:43.00 kernel: mirror: /dev/rsd5b 00: 95/04/01 14:53:43.00 kernel: Virtual device 0 started using asynchronous i/o. 00: 95/04/01 14:53:43.10 kernel: network name ddsdbal, type sun#ether, port 1025 00: 95/04/01 14:53:43.23 server: Number of buffers in buffer cache: 5393. 00: 95/04/01 14:53:43.23 server: Number of proc buffers allocated: 1797. 00: 95/04/01 14:53:43.23 server: Number of blocks left for proc headers: 1943. 00: 95/04/01 14:53:43.81 server: Opening Master Database ... 00: 95/04/01 14:53:44.17 server: Loading SQL Server's default sort order and character set /* 6) Информация из файла интерфейсов */ 00: 95/04/01 14:53:44.19 kernel: network name machinel, type sun#ether, port 1025 ' 00: 95/04/01 14:53:44.26 server: Recovering database 'master 00: 95/04/01 14:53:44.33 server: Recovery dbid 1 ckpt (2391,23) 00: 95/04/01 14:53:44.33 server: Recovery no active transactions before ckpt. /* 7) Имя сервера */ 00: 95/04/01 14:53:44.59 server: server name is 'ddsdbal' 00: 95/04/01 14:53:44.65 setver: Activating disk 'sdld'. /* 8) Список серверных устройств и их зеркальных копий */ 00: 95/04/01 14:53:44.65 kernel: Initializing virtual device 18, "/dev/rsdld"

www.books-shop.com

00: 95/04/01 14:53:44.65 kernel: mirror: /dev/rsd10e /* 9) Использование асинхронного ввода#вывода в серверные устройства */ 00: 95/04/01 14:53:44.66 kernel: Virtual device 18 started using asynchronous i/o. 00 95/04/01 14:53:44.66 server: Activating disk 'sdle'. 00 95/04/01 14:53:44.66 kernel: Initializing virtual device 19, "/dev/rsdle" 00: 95/04/01 14:53:44.67 kernel: Virtual device 19 started using asynchronous i/o.

/*

10) Процесс восстановления баз данных */ 00: 95/04/01 14: 53 :44. 84 server: Recovering database 'model' 00: 95/04/01 14: 53 :44. 86 server : Recovery dbid 3 ckpt (266,25) 00: 95/04/01 14: 53 :44. 86 server: Recovery no active transactions before ckpt . 00: 95/04/01 14: 53 :45. 01 server : Clearing temp db 00: 95/04/01 14: 53 :57. 38 server: Recovering database 'dbl'. 00: 95/04/01 14: 53 :57. 43 server: Recovery dbid 4 ckpt (6401,1) oldest tran= (6401 ,0) 00: 95/04/01 14:53 :57. 50 server: 1 transactions rolled forward. 00: 95/04/01 14: 53 :57. 84 server: Recovering database 'db2'. 00: 95/04/01 14: 53 :57. 90 server: Recovery dbid 5 ckpt (51206,23) oldest tran= (51206 ,22) 00: 95/04/01 14:53 :57. 91 server : 1 transactions rolled forward.

00: 95/04/01 14:53:57.84 server: Recovering database 'dbn' 00: 95/04/01 14:53:57.90 server: Recovery dbid 5 ckpt (51206,23) oldest tran=(51206 ,22) 00: 95/04/01 14:53:57.91 server: 1 transactions rolled forward. 00: 95/04/01 14:59:42.38 server: Recovery complete. /* 11) Порядок сортировки и набор символов, используемые по умолчанию */ 00: 95/04/01 14:59:42.38 server: SQL Server's default sort order is: 00: 95/04/01 14:59:42.38 server: 'bin_iso_l' (ID = 50) 00: 95/04/01 14:59:42.38 server: on top of default character set: 00: 95/04/01 14:59:42.39 server: 'iso_l' (ID = 1). Пример журнала регистрации ошибок SQL Server System 10 В распечатке файла регистрации ошибок рассмотренные выше сообщения отмечены коммента риями /* ... */. /home/DDSDBAl/errorlog 53 % more errorlog 00:95/04/01 14:26:02.69 kernel Using config area of disk for boot information 00:95/04/01 14:26:02.89 kernel Using config area from primary master device. /* 1) Версия SQL Server */ 00:95/04/01 14:26:03.05 kernel SQL Server/10.0.2/P/Sun4/OS 4.1.x/l/OPT/Fri Oct 28 10:22:26 PDT 1994 /* 2) Местонахождение журнала регистрации ошибок */ 00:95/04/01 14:26:03.07 kernel Logging SQL Server messages in file '/home/DDSDBAl/errorlog/errorlog'. /* 3) Максимальное число одновременных сеансов работы пользователей */ 00:95/04/01 14:26:03.07 kernel Using 2048 file descriptors. 00:95/04/01 14:26:03.08 kernel Network and device connection limit is 2045. /* 4) Местонахождение серверного устройства master */ 00:95/04/01 14:26:03.45 kernel Initializing virtual device 0, '/dev/rsd4h'

www.books-shop.com

/*

5) Зеркальное резервирование серверного устройства master #> в данном примере у устройства master НЕТ зеркальной копии */ 00: 95/04/01 14:26:03.46 kernel Virtual device 0 started using asynchronous i/o. 00: 95/04/01 14:26:03.46 server Disk I/O affinitied to engine: 0 00: 95/04/01 14:26:03.60 server Number of buffers in buffer cache: 4978. 00: 95/04/01 14:26:03.60 server Number of proc buffers allocated: 1659. 00: 95/04/01 14:26:03.61 server Number of blocks left for proc headers: 1518. 00: 95/04/01 14:26:04.83 server Opening Master Database ... 00: 95/04/01 14:26:05.08 server Loading SQL Server's default sort order and character set /* 6) Информация из файла интерфейсов */ 00: 95/04/01 14:26:05.15 kernel network name machinel, type sun#ether, port 1025 00: 95/04/01 14:26:05.18 server Recovering database 'master' 00: 95/04/01 14:26:05.21 server Recovery dbid 1 ckpt (1385,19) 00:95/04/01 14:26:05.24 server Recovery no active transactions before ckpt. /* 7) Имя сервера */ 00:95/04/01 14:26:05.67 server server name is 'ddsdbal' 00: 95/04/01 14:26:06.73 server Activating disk 'sd4b'. /* 8) Список серверных устройств и их зеркальных копий # в данном примере зеркальное резервирование серверных устройств НЕ ПРОИЗВОДИТСЯ */ 00:95/04/01 14:26:05.73 kernel Initializing virtual device36, '/rsd4b' /* 9) Использование асинхронного ввода#вывода в серверные устройства */ 00: 95/04/01 14:26:05.74 kernel Virtual device 36 started using asynchronous i/o. 00: 95/04/01 14:26:05.74 server Activating disk 'sd4d'. 00: 95/04/01 14:26:05.74 kernel Initializing virtual device 10, '/dev/rsd4d' .00 :95/04/01 14:26:05.75 kernel Virtual device 10 started using asynchronous i/o.

00:95/04/01 14:26:06.04 server Activating disk 'sybsecurity'. 00:95/04/01 14:26:06.04 kernel Initializing virtual device 2, '/dev/rsd6h' 00:95/04/01 14:26:06.05 kernel Virtual device 2 started using asynchronous i/o. 00:95/04/01 14:26:06.05 server Activating disk 'sysprocsdev'. ' 00:95/04/01 14:26:06.05 kernel Initializing virtual device 1, '/dev/rsdSh 00:95/04/01 14:26:06.06 kernel Virtual device 1 started using asynchronous i/o. /* 10) Процесс восстановления баз данных */ 00:95/04/01 14:26:06.18 server Recovering database 'sybsecurity'. 00:95/04/01 14:26:06.21 server Recovery dbid 5 ckpt (365,2) oldest tran=(365,l) 00:95/04/01 14:26:06.23 server 1 transactions rolled forward. 00:95/04/01 14:26:06.64 server audproc: Loading global audit options from sysauditoptions. 00:95/04/01 14:26:06.66 server audproc: Global audit options successfully loaded. 00:95/04/01 14:26:06.69 server Recovering database 'model'. 00:95/04/01 14:26:06.70 server Recovery dbid 3 ckpt (323,7) 00:95/04/01 14:26:06.70 server Recovery no active transactions before ckpt. 00:95/04/01 14:26:06.82 server Clearing temp db 00:95/04/01 14:26:09.94 server Recovering database 'sybsystemprocs'.

www.books-shop.com

00:95/04/01 14:26:09.95 server Recovery dbid 4 ckpt (4122,27) 00:95/04/01 14:26:09.95 server Recovery no active transactions before ckpt . 00:95/04/01 14:26:10.40 server Recovering database 'dbl'. 00:95/04/01 14:26:10.41 server Recovery dbid 6 ckpt (5299,6) 00:95/04/01 14:26:10.41 server Recovery no active transactions before ckpt . 00:95/04/01 14:26:12.46 server Recovering database 'db2'. 00:95/04/01 14:26:12.48 server Recovery dbid 7 ckpt (2381666,9) 00:95/04/01 14:26:12.48 server Recovery no active transactions before ckpt .

00:95/04/01 14:26:36.72 server Recovering database 'dbn'. 00:95/04/01 14:26:36.75 server Recovery dbid 8 ckpt (42729,5) 00:95/04/01 14:26:36.75 server Recovery no active transactions before ckpt. 00:95/04/01 14:26:57.56 server Recovery complete. /* 11) Порядок сортировки и набор символов, используемые по умолчанию */ 00:95/04/01 14:26:57.56 server SQL Server's default sort order is: 00:95/04/01 14:26:57.58 server 'bin_iso_l' (ID = 50) 00:95/04/01 14:26:57.58 server on top of default character set: 00:95/04/01 14:26:57.58 server 'iso_l' (ID = 1). Пример журнала регистрации ошибок SQL Server System 11 В распечатке файла регистрации ошибок рассмотренные выше сообщения отмечены коммента риями /* ... */. machinel: more errorlog_PSYCHOll 00:96/07/15 12:14:54.07 kernel Using config area from primary master device. 00:96/07/15 12:14:54.20 kernel Warning: Using default file '/home/sybase/PSYCHO11.cfg' since a configuration file was not specified. Specify a configuration file name in the RUNSERVER file to avoid this message. 00:96/07/15 12:14:56.22 kernel Using 1024 file descriptors. /* 1) Версия SQL Server */ 00:96/07/15 12:14:56.31 kernel SQL Server/11.0.l/P/Sun_svr4/OS 5.4/EBF6158/OPT/Fri Apr 5 20:30:14 PST 1996 00:96/07/15 12:14:56.31 kernel Confidential property of Sybase, Inc. 00:96/07/15 12:14:56.31 kernel (c) Copyright Sybase Inc., 1987, 1996. 00:96/07/15 12:14:56.31 kernel All rights reserved. 00:96/07/15 12:14:56.31 kernel 00:96/07/15 12:14:56.31 kernel Use, duplication, or disclosure by the United States Government 00:96/07/15 12:14:56.31 kernel is subject to restrictions as set forth in FAR subparagraphs 00:96/07/15 12:14:56.31 kernel 52.227#19(a)#(d) for civilian agency contracts and DFARS 00:96/07/15 12:14:56.31 kernel 252.227#7013(c) (1) (ii) for Department of Defense contracts. 00:96/07/15 12:14:56.31 kernel Sybase reserves all unpublished rights under the copyright 00:96/07/15 12:14:56.31 kernel laws of the United States. 00:96/07/15 12:14:56.31 kernel Sybase, Inc. 6475 Christie Avenue, Emeryville, CA 94608 USA. 00:96/07/15 12:14:56.31 kernel Using /home/sybase/11.0.1/ PSYCHOll.cfg' for configuration information. /* 2) Местонахождение журнала регистрации ошибок */

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

320

Глава 12

00:96/07/15 12:14:56.33 kernel Logging SQL Server messages in file '/home/sybase/install/errorlog_PSYCHOll'. /* 3) Максимальное число одновременных сеансов работы пользователей */ 00:96/07/15 12:14:56.38 kernel Network and device connection limit is 1014. 00:96/07/15 12:14:56.41 server Number of proc buffers allocated: 3041. 00:96/07/15 12:14:56.56 server Number of blocks left for proc headers: 3091. 00:96/07/15 12:14:56.57 server Memory allocated for the default data cache e: 12866 Kb 00:96/07/15 12:14:56.60 server Size of the 2K memory pool: 12866 Kb 00:96/07/15 12:14:56.60 server Memory allocated for the psycho_cachel cache: 10240 Kb 00:96/07/15 12:14:56.61 server Size of the 2K memory pool: 9216 Kb 00:96/07/15 12:14:56.62 server Size of the 8K memory pool: 1024 Kb /* 4) Местонахождение серверного устройства master */ 00:96/07/15 12:14:56.64 kernel Initializing virtual device 0, '/dev/rdsk/cOt2dOs7' 00:96/07/15 12:14:56.65 kernel Virtual device 0 started using asynchronous i/o. 00:96/07/15 12:14:56.84 server Opening Master Database ... /* 5) Серверное устройство master HE ИМЕЕТ зеркальной копии */ 00:96/07/15 12:14:57.65 server Loading SQL Server's default sort order and character set 00:96/07/15 12:14:57.69 kernel ninit:0: listener type: master 00:96/07/15 12:14:57.69 kernel ninit:0: listener endpoint: /dev/tcp /* 6) Информация из файла интерфейсов */ 00:96/07/15 12:14:57.69 kernel ninit:0: listener raw address: \x000204018196c4500000000000000000 00:96/07/15 12:14:57.69 kernel ninit:0: transport provider: T_COTS_ORD ' 00:96/07/15 12:14:57.84 server Recovering database 'master 00:96/07/15 12:14:57.91 server Recovery dbid 1 ckpt (1955,28) 00:96/07/15 12:14:57.91 server Recovery no active transactions before ckpt. 00:96/07/15 12:14:58.02 server 3 transactions rolled forward. 00:96/07/15 12:14:58.39 server Database 'master' is now online. 00:96/07/15 12:14:58.41 server The transaction log in the database 'master' will use I/O size of 2 Kb. /* 7) Имя сервера */ 00:96/07/15 12:14:58.52 server server name is 'PSYCHO11' /* 8) Список серверных устройств, ни одно из которых также НЕ ИМЕЕТ зеркальной копии */ 00:96/07/15 12:14:58.55 server Activating disk 'cOt2dOs4'. 00:96/07/15 12:14:58.55 kernel Initializing virtual device 1, '/dev/rdsk/cOt2dOs4' /* 9) Использование асинхронного ввода#вывода в серверные устройства */ 00:96/07/15 12:14:58.58 kernel Virtual device 1 started using asynchronous i/o. 00:96/07/15 12:14:58.58 server Activating disk 'cOt2dOs5'. 00:96/07/15 12:14:58.58 kernel Initializing virtual device 2, '/dev/rdsk/cOt2dOs5' 00:96/07/15 12:14:58.59 kernel Virtual device 2 started using asynchronous i/o. 00:96/07/15 12:14:58.59 server Activating disk 'cOt2dOs6'. 00:96/07/15 12:14:58.59 kernel Initializing virtual device 3, '/dev/rdsk/cOt2dOs6' 00:96/07/15 12:14:58.60 kernel Virtual device 3 started using asynchronous i/o. /* 10) Процесс восстановления баз данных */ 00:96/07/15 12:14:59.00 server Recovering database 'model'.

www.books-shop.com

00:96/07/15 12:14:59.01 server Recovery dbid 3 ckpt (442,15) 00:96/07/15 12:14:59.01 server Recovery no active transactions before ckpt. 00:96/07/15 12:14:59.16 server The transaction log in the database 'model' will use I/O size of 2 Kb. 00:96/07/15 12:14:59.19 server Database 'model' is now online. 00:96/07/15 12:14:59.21 server Clearing temp db 00:96/07/15 12:15:02.51 server Recovering database 'sybsystemprocs'. 00:96/07/15 12:15:02.53 server Recovery dbid 10 ckpt (8075,20) 00:96/07/15 12:15:02.53 server Recovery no active transactions before ckpt. 00:96/07/15 12:15:03.21 server The transaction log in the database 'sybsystemprocs' will use I/O size of 2 Kb. 00:96/07/15 12:15:03.25 server Database 'sybsystemprocs' is now online. 00:96/07/15 12:15:03.51 server Recovering database 'admindb'. 00:96/07/15 12:15:03.53 server Recovery dbid 4 ckpt (31287,19) oldest tran=(31287,17) 00:96/07/15 12:15:03.58 server 1 transactions rolled forward. 00:96/07/15 12:15:04.95 server The transaction log in the database 'admindb' will use I/O size of 2 Kb. * 00:96/07/15 12:15:04.99 server Database 'admindb' is now online. 00:96/07/15 12:15:05.08 server Recovering database 'cmsdb'. 00:96/07/15 12:15:05.10 server Recovery dbid 5 ckpt (84917/6) 00:96/07/15 12:15:05.10 server Recovery no active transactions before ckpt. 00:96/07/15 12:15:05.29 server 2 transactions rolled forward. 00:96/07/15 12:15:07.50 server The transaction log in the database 'cmsdb' will use I/O size of 2 Kb. 00:96/07/15 12:15:07.54 server Database 'cmsdb' is now online. 00:96/07/15 12:15:07.62 server Recovering database 'curgtr_db'. 00:96/07/15 12:15:07.64 server Recovery dbid 6 ckpt (102487,27) 00:96/07/15 12:15:07.64 server Recovery no active transactions before ckpt. 00:96/07/15 12:15:09.47 server The transaction log in the database 'curgtr_db' will use I/O size of 2 Kb. 00:96/07/15 12:15:09.51 server Database 'curgtr_db' is now online. 00:96/07/15 12:15:09.59 server Recovering database 'pagedb'. 00:96/07/15 12:15:09.60 server Recovery dbid 7 ckpt (12720,15) 00:96/07/15 12:15:09.60 server Recovery no active transactions before ckpt. 00:96/07/15 12:15:10.01 server The transaction log in the database 'pagedb' will use I/O size of 2 Kb. 00:96/07/15 12:15:10.05 server Database 'pagedb' is now online. 00:96/07/15 12:15:10.13 server Recovering database 'guedb'. 00:96/07/15 12:15:10.14 server Recovery dbid 8 ckpt (13081,15) • 00:96/07/15 12:15:10.15 server Recovery no active transactions before ckpt. 00:96/07/15 12:15:11.25 server The transaction log in the database 'quedb' will use I/O size of 2 Kb. 00:96/07/15 12:15:11.29 server Database 'guedb' is now online. 00:96/07/15 12:15:11.37 server Recovering database 'cms_map'. 00:96/07/15 12:15:11.38 server Recovery dbid 9 ckpt (4127,12) 00:96/07/15 12:15:11.38 server Recovery no active transactions before ckpt. 00:96/07/15 12:15:11.67 server The transaction log in the database 'cms_map' will use I/O size of 2 Kb. 00:96/07/15 12:15:11.70 server Database 'cms_map' is now online. 00:96/07/15 12:15:11.76 server Recovering database 'PSYCHORS_RSSD'. 00:96/07/15 12:15:11.78 server Recovery dbid 11 ckpt (12000,4) 00:96/07/15 12:15:11.78 server Recovery no active transactions before ckpt. 00:96/07/15 12:15:12.39 server The transaction log in the database 'PSYCHORS_RSSD' will use I/O size of 2 Kb. 00:96/07/15 12:15:12.44 server Database 'PSYCHORS_RSSD' is now online. 00:96/07/15 12:15:12.49 server Recovering database 'corruptable'.

www.books-shop.com

00:96/07/15 12:15:12.51 server Recovery dbid 12 ckpt (13733,10) . 00:96/07/15 12:15:12.51 server Recovery no active transactions before ckpt. 00:96/07/15 12:15:13.23 server The transaction log in the database ' corruptable ' will use I/O size of 2 Kb. 00:96/07/15 12:15:13.27 server Database 'corruptable' is now online. 00:96/07/15 12:15:13.28 server Recovery complete. /* 11) Порядок сортировки и набор символов, используемые по умолчанию */ 00:96/07/15 12:15:13.28 server SQL Server's default sort order is: 00:96/07/15 12:15:13.28 server 'bin_iso_l' (ID = 50) 00:96/07/15 12:15:13.28 server on top of default character set: 00:96/07/15 12:15:13.28 server 'iso_l' (ID = 1). 00:96/07/19 10:50:36.10 server DBCC TRACEON 8399, SPID 1 Создание новых баз данных и эксплуатация сервера В главе 8 мы подробно рассмотрели процесс создания новых баз данных и их размещения по сервер" ным устройствам. Создавая новую базу данных, помните обо всех изменениях, которые необходимо внести в регламент повседневной эксплуатации сервера. Новую базу данных следует включить в командный файл периодически выполняющегося cron"процесса, который сохраняет дампы баз данных, обновляет статистику для оптимизатора за" просов, выполняет dbcc"проверки и осуществляет все другие операции, необходимые для поддержа" ния нормальной работоспособности сервера. Кроме того, проверьте, хватит ли свободного дискового пространства и емкости ленточных устройств для размещения дампа создаваемой базы данных. I Модификация системных таблиц SQL Server вручную Время от времени перед администратором сервера встает необходимость вручную внести изменения в системные таблицы сервера. Мы рекомендуем читателю предварительно согласовать план своих действий со службой технической поддержки компании Sybase, а также заранее запастись свежим дампом базы данных master. Внимание! 1. Модификация содержания системных таблиц не поддерживается компанией Sybase. Компа" ния не гарантирует, что различные версии сервера будут иметь одинаковую структуру сис" темных таблиц. Поэтому модификация системных таблиц вручную одной версии SQL Server может оказаться неприменимой к другой версии сервера. 2. Перед изменением содержания системных таблиц обязательно проконсультируйтесь со службой технической поддержки Sybase. 3. Перед внесением изменений проверьте, имеется ли у вас полный набор дампов, необходи" мый для восстановления сервера в случае, если вносимые изменения приведут к наруше" нию его работоспособности. 4. После модификации системных таблиц для активизации внесенных изменений сервер сле" дует перезапустить. Перед модификацией системных таблиц сервера переведите его процедурой sp_reconf igure в режим allow updates. Начиная вносить изменения в системную таблицу, предварительно распечатайте всю содержащу" юся в ней информацию, чтобы иметь возможность в любой момент вернуть таблицу к ее первонача" льному состоянию. Затем откройте транзакцию, внесите необходимые изменения в записи таблицы и снова распечатайте все содержимое таблицы, проверяя, что в таблицу были внесены все требуе" мые изменения. После этого зафиксируйте транзакцию и еще раз распечатайте данные таблицы для документирования внесенных изменений. Завершив модификацию системных таблиц, не забудьте отменить режим allow updates, что" бы исключить случайное вмешательство в запись и ее порчу. С примером процесса модификации си" стемной таблицы вы уже знакомились в главе 7.

www.books-shop.com

Команда bcp Команда bcp играет большую роль в самых различных операциях, которые приходится выполнять администратору сервера. Эта команда много параметров, а процесс ее использования (и в первую очередь файлы форматов) требует подробных объяснений, которые выходят за рамки нашей книги. Полное описание всех вопросов, связанных с командой bcp, вы найдете в руководстве по UNIXути литам сервера Sybase SQL Server Utility Programs for UNIX. Свободное пространство базы данных Администратор сервера должен постоянно проверять, есть ли свободное место в базах данных, а так же в их отдельных сегментах. Однако свободное место в базе имеет смысл, если оно имеется там, где оно действительно нужно. Вам вряд ли удастся воспользоваться свободным пространством сегмента system для расширения таблицы данных, вынесенной в отдельный пользовательский сегмент. При создании базы данных cmsdb, рассматриваемой ниже, ей было распределено 350 Мбайт для данных и 50 Мбайт для журнала транзакций. Выполним несколько команд сервера и проанализиру ем их результаты. Получив общие конфигурации базы данных командой sp_helpdb, применим команду sp_spaceused, выдающую информацию об использовании всего дискового пространства, распределенного базе данных: 1> sp_helpdb cmsdb 2> до name db_sizeowner dbid created status cmsdb 400.0 MB sa 9 Apr 25, 1996 no options set device_fragments size usage free kbytes cOt2dOs4 150.0 MB data only 0 cOt2dOs4 200.0 MB data only 42800 cOt2dOs6 50.0 MB log only 51008 device cOt2dOs4 cOt2dOs4 cOt2dOs6 (return status = 0 ) 1> sp_spaceused 2> go database_name cmsdb

segment default system logsegment

database_size 400.0 MB

reserved data index_size unused 314544 KB 113282 KB 167800 KB 33462 KB (return status = 0) Таким образом, распределенное базе данных пространство используется следующим образом: 113282 Кбайт " данные 167800 Кбайт " индексы 33462 Кбайт " не использовано, но распределено объектам базы данных 314544 Кбайт занято базой данных Теперь вспомним, что всего базе данных распределено 400 Мбайт, из которых 50 Мбайт занято журналом транзакций: 400 Мбайт = 409600 Кбайт 50 Мбайт = 51200 Кбайт 409600 Кбайт всего пространства

#51200 Кбайт журнала транзакций (из них 51008 Кбайт свободно) 358400 Кбайт

www.books-shop.com

"314544 Кбайт занято базой данных 43856 Кбайт = 42,8 Мбайт свободного' пространства сегментов данных Сравним полученный результат с выдачей команды sp_helpdb <имя_базы_данных>: 42800 Кбайт = 41,8 Мбайт (в пределах 2 , 5 % совпадает с предыдущей цифрой в 42,8 Мбайт) 51008 Кбайт 93808 Кбайт = 91,6 Мбайт общего свободного пространства (не доступно целиком ни одному сегменту) Очень часто возникает вопрос: хватит ли нам свободного места для создания кластеризованного индекса таблицы service_orders? Чтобы ответить, выполним команду sp_spaceused <назва" ние_таблицы> : 1> sp_spaceused service_orders 2> go name rowtotal reserved data index_size unused service_orders 20599 116654 KB 17028 KB 84602 KB 15024 KB (return status = 0) Для создания кластеризованного индекса таблицы, содержащей 17028 Кбайт данных, нам необ" ходимо свободное пространство, примерно на 20% превышающее общие размеры таблицы, т.е. 1,2 * 17028 Кбайт = 20434 Кбайт (около 20 Мбайт). С учетом того, что свободное пространство со" вмещенных сегментов данных system и default составляет 42800 Кбайт (41,8 Мбайт), мы вполне можем рассчитывать на успех. Ошибка 1105: переполнение журнала транзакций или другого сегмента базы данных Механизм порогов, на первый взгляд, должен сделать процедуру очистки переполнившегося журнала транзакций не столь актуальной. Ведь на пороге последнего уровня сервер автоматически останавли" вает все попытки пользователей записать что"либо в близкий к заполнению журнал транзакций. Тем не менее рекомендуем вам познакомится с процедурой очистки подробнее. Для этого есть следующие поводы. Во"первых, важно уметь определить, в каком именно сегменте базы данных произошло пере" полнение, приведшее к выдаче сообщения об ошибке 1105. Разумеется, пороги используются для предотвращения переполнения журнала транзакций, но в базах данных существуют и другие сегмен" ты, которые могут переполниться в любой момент. Во"вторых, по каким"то причинам порогов может не быть, а соответствующая хранимая процедура — попросту не сработать. После перехода от SQL Server 4.9.2 на System 10 или System 11 во всех перенесенных из старого сервера базах данных необхо" димо вручную активизировать пороги последнего уровня для журналов транзакций, поскольку в этом случае эти пороги не устанавливаются автоматически, и их отсутствие может привести к возникнове" нию ошибки 1105. В"третьих, пороги последнего уровня позволяют предотвратить переполнение то" лько журналов транзакций, вынесенных на отдельное серверное устройство. Если журнал транзакций размещен вместе с самой базой данных, остается опасность его переполнения с выдачей ошибки 1105. Основные последствия переполнения журнала транзакций уже рассматривались в главах 9 и 11 . Обнаружив ошибку 1105, администратор сервера должен выполнить определенные действия, чтобы найти источник проблемы и устранить ее. Эти действия подробно рассматриваются в следующих разделах главы. Прежде всего убедитесь, что вы действительно имеете дело с повторяющейся ошибкой 1105. Определите, какой именно сег" мент переполнился, и в какой базе данных он находится. Лишь затем можно приступить к решению проблемы. Отметим, что, вероятно, транзакция, ставшая причиной ошибки 1105, уже была автома" тически отменена сервером как раз вследствие возникновения ошибки 1105 при ее обработке. В ре" зультате, проверяя состояние соответствующего сегмента, вы можете обнаружить, что там имеется некоторое свободное пространство. Здесь необходимо решить, намерены ли вы немедленно присту" пить к его расширению или предпочитаете, чтобы пользователь еще раз подучил сообщение об ошибке 1105, и лишь затем взяться за анализ и ликвидацию проблемы. Название переполнившегося сегмента и его базы данных указывается в сообщении об ошибке 1105. Перед тем как принять ка" кие"либо меры, обязательно убедитесь, что указанный сегмент действительно переполнился.

www.books-shop.com

Поиск базы данных, содержащей переполнившейся сегмент Получив сообщение об ошибке 1105, выясните, в какой базе данных произошло переполнение сег" мента. В большинстве случаев это нетрудно установить из сообщений пользователей и журнала реги" страции ошибок сервера. Если вам не удается найти базу данных, в которой возникла эта ошибка, перейдите к следующему этапу процедуры и выполните действия, описанные ниже, для всех баз дан" ных сервера. Поиск переполнившегося сегмента базы данных Не выделив точно базу данных, ставшую причиной ошибки 1105, выполните следующие операции для всех баз данных сервера. В таком же порядке следует действовать, чтобы найти переполнивший" ся сегмент. 1. Проверьте наличие свободного пространства во всех сегментах базы данных. 2. Попытайтесь создать контрольную точку, чтобы убедиться в переполнении журнала тран" закций. 3. Попытайтесь создать новую таблицу данных в сегментах system и default, чтобы убедиться в переполнении этих сегментов. 4. Попытайтесь создать новую таблицу данных в каждом пользовательском сегменте, чтобы убедиться в его переполнении.

Проверка свободного пространства сегментов базы данных Подобную операцию можно выполнить с помощью процедур sp_helpdb и sp_helpeegment. При выполнении команды sp_helpdb <имя_базы_данных> сервер выдаст список всех сегментов этой базы данных с указанием свободного пространства (в килобайтах), имеющегося в каждом из них. (От" метим, что эта колонка выдается только серверами System 10 и System 11). Эта информация значите" льно облегчает поиск сегмента, вызвавшего ошибку 1105, а также общий анализ свободного дискового пространства, остающегося на сервере. Аналогичную информацию можно получить и командой sp_helpsegment <название_сегмента>. Однако здесь свободное пространство выдает" ся в виде количества свободных 2"килобайтных страниц (пример приводился в разделе "Состав объ" ектов сегмента базы данных" этой главы). Пример выдачи процедуры sp_helpdb приводится ниже: machinel: isql #Usa #STHEBIRDS11 Password: 1> use psychodb 2> go 1> sp_helpdb psychodb 2> go name db_size owner dbid created status psychodb 400.0 MB sa 9 Apr 25, 1996 no options set device fragments cOt2dOs4 cOt2dOs4 C0t2d0s6 device cOt2dOs4 cOt2dOs4 cOt2dOs6

size 150.0 MB

200.0 MB 50.0 MB

usage data only data only log only

free kbytes 0 42800 51008

segment default system logsegment

(return status = 0)

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

www.books-shop.com

указывать параметр no_log при очистке журнала командой dump transaction. Отметим, что в этой ситуации попытка выполнения команды dump transaction with no_log может привести к порче базы данных и другим проблемам. Присутствие свободного места в журнале транзакций позво" ляет сделать следующие выводы: 1. Возможно, мы имеем дело не с той базой данных. Если ошибка 1105 действительно вызва" на переполнением сегмента журнала транзакций (logsegment), то этот сегмент переполнился в другой базе данных, к поискам которой и следует перейти. 2. Ошибка 1105 — случайность. Может быть, сервер выполнил автоматический откат транзак" ции, ставшей причиной переполнения журнала транзакций. Следует решить, намерены ли вы немедленно приступить к очистке журнала транзакций или дождетесь выдачи новых ошибок 1105. 3. Переполнен какой"то другой сегмент базы данных. Даже если переполнение действительно возникло в этой базе данных, ошибка 1105 не означает переполнения именно сегмента журнала транзакций. Ненормальное завершение команды checkpoint и выдача нового сообщения об ошибке 1105 свидетельствуют о переполнении журнала транзакций — он не имеет свободного места даже для за" писи о создании контрольной точки. В этой ситуации переходите прямо к разделу "Переполнение журнала транзакций" этой главы. Создание таблицы АЛЯ проверки переполнения сегментов system и default После успешного создания контрольной точки попытаемся создать в базе данных несколько таблиц. Их названия должны быть как можно более необычными, например: create table psycho1 (a int) Использование нестандартных имен позволит в будущем легко найти эти таблицы среди назва" ний других объектов базы данных, перечисленных в системной таблице sysobjects. (Это нужно на случаи, если вы забудете удалить эти таблицы, закончив проверку). Нормальное завершение команды create table свидетельствует о наличии свободного пространства в соответствующем сегменте базы данных (в базы данных, не имеющей пользовательских сегментов, — это сегменты system и default). Ненормальное завершение команды create table с выдачей сообщения об ошибке 1105 ука" зывает на действительное переполнение сегмента, в котором мы пытались создать новую таблицу. Необходимо расширить пространство сегмента. Об этом говорится в разделе "Переполнение сег" мента базы данных" этой главы. Завершив проверку сегмента, не забудьте удалить только что созданную таблицу. Перед ее удале" нием обязательно проверьте, что вы удаляете именно ту таблицу, которая была создана для провер" ки заполнения сегмента.

Создание таблицы АЛЯ проверки переполнения пользовательского сегмента Если подозрение падает на один из пользовательских сегментов базы данных, таблица для проверки должна создаваться обязательно в этом сегменте. При наличии нескольких пользовательских сегмен" тов таблицы следует создать в каждом из них, используя команды следующего вида: create table psycho1 (a int) on <название_сегмента> Аналогично предыдущему случаю, аварийное завершение команды create table с выдачей со" общения об ошибке 1105 свидетельствует о переполнении данного сегмента и необходимости рас" ширения выделенного ему дискового пространства (см. раздел "Переполнение сегмента базы данных" далее в этой главе). Еще раз напомним о необходимости удалить созданную таблицу, завершив проверку сегмента. Удостоверьтесь, что вы удаляете именно ту таблицу, которая была сделана для контроля заполнения сегмента. Переполнение журнала транзакций Прежде всего попытайтесь командой dump transaction без каких"либо параметров записать обыч" ный дамп журнала транзакций. Вы сохраните на диск содержимое журнала транзакций и очистите за" писи обо всех завершенных (т.е. зафиксированных либо отмененных) транзакциях. Выполнив

www.books-shop.com

и checkpoint. Ее нормальное завершение указывает на успешную очистку журнала транзакций. Объ" ем свободного пространства, имеющегося в журнале транзакций, можно проверить одной из следую" щих команд: sp_spaceused syslogs sp_helpdb <имя_базы_данных> sp_helpsegment logsegment Полученный результат следует сопоставить с общим объемом журнала транзакций рассматривае" мой базы данных. Если даже после сохранения дампа журнала транзакций он близок к переполне" нию, то причина заключается в том, что одна или несколько транзакций остались незавершенными. (Напомним, что усечение журнала транзакций прекращается с первой записью об открытой тран" закции.) В случае, когда повторная попытка создать контрольную точку также завершается неудачей и вы" дачей ошибки 1105, вам придется очистить журнал транзакций командой dump transaction с па" раметром no_log (не записывающей в журнал транзакций информации о создании контрольной точки), а затем снова выполнить команду checkpoint. Если на этот раз контрольную точку создать удалось, то с помощью команды sp_spaceused syslogs определите, сколько свободного места появилось в журнале транзакций. Убедившись, что журнал транзакций практически пуст и его очистка завершена, можете приступать к сохранению полного дампа базы данных. (Напомним, что принудительная очистка журнала транзакций коман" дой dump transaction with no_log прерывает нормальную последовательность его дампов и тем самым не позволяет продолжить восстановление базы данных после момента очистки журнала, см. главу 9.) Если невозможно создать контрольную точку даже после принудительной очистки журнала тран" закций оказалось невозможно, найдите открытую транзакцию, запись о которой переместилась в на" чало журнала транзакций и полностью исключает его даже частичную очистку. Как мы не раз подчеркивали выше, наличие в журнале транзакций хотя бы одной записи о транзакции, остающей" ся открытой в течение длительного времени, неизбежно приведет к переполнению журнала. В подобной ситуации ликвидируйте серверный процесс, обрабатывающий открытую транзак" цию. Можно попросить пользователя, ответственного за эту транзакцию, отключиться от сервера, что приведет к откату этой транзакции. Самое сложное здесь — найти пользователя. Если вы не зна" ете, какие пользователи могут на длительное время оставить открытые транзакции (например, из"за особенностей отдельных приложений), вам придется приступить к последовательному уничтоже" нию пользовательских процессов. Другой путь — перезапустить сервер для полного удаления процес" сов пользователей и отката всех открытых транзакций. Разумеется, при переполнении сегмента журнала транзакций (logsegment) администратор сервера может расширить дисковое пространство, распределенное этому сегменту и тем самым временно из" бежать повторения ошибки 1105. Однако это не устранит реальных причин переполнения журнала транзакций (например, зависшей транзакции). Кроме того, разрастание журнала транзакций замет" но осложняет сопровождение сервера (см. главу 8). Поэтому при переполнении журнала транзакций во всех возможных случаях следует стремиться произвести его очистку. Переполнение сегмента базы данных Убедившись в переполнении определенного сегмента базы данных, вам нужно расширить этот сег" мент, если он не является сегментом журнала транзакций (logsegment — см. предыдущий раздел гла" вы). Напомним, что расширение сегмента базы данных требует особого внимания, если расширяемый сегмент распространяется на новое серверное устройство. Пользовательские сегмен" ты чаще всего создаются для повышения производительности сервера путем вынесения определен" ных объектов данных (таблиц или индексов) на отдельное серверное устройство. Поэтому распространение такого сегмента на неподходящее устройство может привести к конкуренции вво" да"вывода для нескольких сегментов, оказавшихся на одном устройстве, физическом диске или кон" троллере дисков. В результате все преимущества, полученные от создания пользовательского сегмента, будут сведены на нет. (Подробно о расширении сегментов баз данных см. главу 8.) Кроме того, в главе 11 мы рассматривали процедуру заблаговременного планирования распределения сег" ментов по серверным устройствам.

www.books-shop.com

Наличие нескольких сегментов на одном серверном устройстве В заключение главы отметим, что при размещении на одном серверном устройстве нескольких сег" ментов базы данных (в подобной конфигурации нет ничего необычного) переполнение одного из сегментов может повлечь за собой одновременное переполнение нескольких других сегментов. На" пример, при создании баз данных их сегмент журнала транзакций logsegment обычно выносится на от" дельное серверное устройство, а два других обязательных сегмента — system и default — размещаются вместе на всех остальных серверных устройствах, распределенных базе данных. В результате после получения сообщения об ошибке 1105, вызванной переполнением сегмента system, любая попытка со" здания новой таблицы (которая умолчанию будет размещаться в сегменте default) также окончится выдачей ошибки 1105. Добавление к базе данных дополнительного дискового пространства на одном из серверных устройств приведет к автоматическому расширению всех сегментов базы данных, нахо" дящихся на этом устройстве.

www.books-shop.com

Глава 13

Установка и обновление SQL Server

Содержание Особенности различных версий SQL Server Установка SQL Server Обновление SQL Server: общий обзор Обновление EBFверсии Переход на новую главную версию SQL Server

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Введение Обновление используемой версии SQL Server входит в круг повседневных операций администратора сервера. Обновление сервера может производиться в различных формах. Простейшей из них являет" ся установка нового выполняемого программного модуля сервера, в который внесены очередные EBF"исправления (Emergency Bug Fix — экстренное исправление выявленных ошибок; ныне слово "эк" стренный" уже устарело, сейчас EBF"версии выпускаются регулярно). Одновременное исправление множества ошибок, найденных за определенный интервал времени, осуществляется в результате так называемого "наката" (rollup) сервера. Наконец, раз в несколько лет происходит полное обновление сервера — переход на его новую версию. Как правило, подобный процесс включает в себя внесение изменений в структуру существующих баз данных, что приводит к несовместимости последних с прежней версией сервера. Особенности различных версий SQL Server Процесс установки и обновления различных существующих версий SQL Server имеет существенные особенности. Здесь мы коротко перечислим основные отличия. SQL Server 4.9.2 SQL Server версии 4.9.2 способен работать как в операционной системе SunOS, так и в Solaris. Про" грамма установки SQL Server 4.9.2 называется sybconfig. Если вы эксплуатируете одну из ранних версий SQL Server и желаете обновить ее на SQL Server 4.9.2, рекомендуем предварительно обратиться в службу технической поддержки компании Sybase. SQL Server System 10 Программа установки сервера System 10 называется sybinit. В процессе установки автоматически создается база данных sybsystemprocs, а также (при намерении использовать средства аудита сервера) база данных sybsecurity. Аналогично предыдущей версии, SQL Server System 10 способен работать и в SunOS, и в Solaris. Переход к SQL Server System 10 с версии 4.9.2 сервера представляет собой многоступенчатый процесс, включающий в себя проверку конфликтов между зарезервированными словами, инициали" зацию небуферизованных разделов физических дисков, необходимых для размещения новых баз данных sybsystemprocs и sybsecurity, и целый ряд других операций. SQL Server System 11 Установка сервера System 11 на компьютерах фирмы Sun возможна только при наличии операцион" ной системы Solaris 2.4 или более новой версии. Аналогично System 10, программа установки сервера System 11 также называется sybinit. В процессе своей работы она создает базу данных sybsystemprocs. Создание базы данных sybsecurity необходимо только при условии, что предполагается использовать средства аудита сервера. Переход к System 11 осуществляется как от SQL Server System 10, так и от SQL Server 4.9.2. Одна" ко подобная операция может потребовать установки на серверной машине системы Solaris. Переход с System 10 на System 11 осуществляется одним из двух способов. Можно либо в один прием обно" вить весь сервер System 10, либо сначала установить сервер System 11, затем создать на нем копии баз данных System 10 и загрузить дампы этих баз данных в новый сервер. На последней стадии сер" вер System 11 автоматически приводит структуру загружаемых баз данных к новой версии сервера. Переход на System 11 c SQL Server 4.9.2 включает в себя все этапы обновления сервера 4.9.2 на System 10, т.е. анализ зарезервированных слов, создание баз данных sybsystemprocs и sybsecurity и т.д. Установка SQL Server При соблюдении всех необходимых правил процесс установки SQL Server не вызывает никаких серь" езных затруднений. Разумеется, в нормальных условиях подобная операция выполняется не слишком часто, поэтому перед установкой сервера рекомендуем еще раз просмотреть необходимую документа" цию. Отметим, что поставляемая вместе с программными продуктами Sybase документация весьма не" плоха, но ее составители подразумевают, что к моменту начала установки сервера вы уже подключили дисковые накопители к серверной машине и разбили их на разделы. Кроме того, в

www.books-shop.com

документации описание процесса установки ограничивается основным набором базовых операций. На страницах нашей книги представлено более подробное и приближенное к реальности описание процесса установки и конфигурирования сервера перед вводом его в эксплуатацию. Рассматриваются также необходимые подготовительные операции, выполняемые до запуска программы установки. Разумеется, при необходимости программу установки sybinit можно вызвать повторно (напри" мер, в случае ошибок при первой установке или изменении требуемых параметров сервера). Однако каждый вызов sybinit приводит к полному удалению всей информации разделов дисков, использу" емых для размещения устройства master нового сервера (а также устройств, где будут находиться базы данных sybsystemprocs и sybsecurity). Поэтому на первоначальных этапах установки программа sy" binit может вызываться столько раз, сколько это необходимо, но по завершении формирования основных компонентов сервера к использованию этой программы следует подходить с большой осторожностью. Отметим, что sybinit и впредь будет необходима для уточнения конфигурации сервера; однако ее вызов с неверно указанными параметрами может полностью уничтожить устанав" ливаемый сервер. Подготовка к установке сервера Перед тем как приступить к фактической установке Sybase SQL Server, необходимо должным образом подготовить серверную машину. Основные этапы этой подготовки подробно рассматриваются ниже: • Получить и прочитать' руководство по установке сервера, описание особенностей текущей версии сервера и приложение к руководству администратора сервера • Уточнить наличие соглашения со службой поддержки пользователей Sybase • Познакомиться с системным администратором серверной машины • Проинформировать пользователей и руководство • Получить полномочия пользователя root • Установить серверную машину • Присвоить переменной среды SYBASE значение /home/sybase • Скопировать дистрибутивы сервера в инсталляционный каталог • Запустить программу sybinit Получить и прочитать руководство по установке сервера, описание особенностей текущей версии сервера и приложение к руководству администратора сервера Перед установкой сервера вам необходимо ознакомиться с руководством по установке сервера (Sybase SQL Server Installation Guide), с описанием особенностей текущей версии сервера (Release Notes) и с приложением к руководству системного администратора (System Administration Guide Supplement). Перечисленные документы поставляются с каждой главной версией сервера и содер" жат крайне важную информацию, специально ориентированную на конкретную аппаратно"програм" мную платформу. Поскольку эти документы не поставляются Sybase при промежуточных обновлениях сервера, следует уделить должное внимание их сохранности. Если в ваши обязанности входит сопровождение нескольких версий сервера на различных платформах, то обзаведитесь небо" льшой библиотечкой руководств по каждой отдельной версии SQL Server для каждой имеющейся ап" паратно"программной платформы. Для любого настоящего администратора баз данных чтение этих руководств станет за+ хватывающим и очень интересным делом. Почерпнутая информация значительно повы+ сит ваш профессиональный уровень, в то время как ее незнание превратит каждую очередную установку сервера в кошмар. Комплект руководств по установке SQL Server подобен словарю латинского языка в обложке с золотым тиснением, совершенно беспо+ лезному в повседневной жизни, но абсолютно незаменимому, как только в нем возника+ ет необходимость. Уберите эти руководства в надежное место — они сослужат добрую службу в моменты тяжелых сбоев сервера, требующих его полной переустановки. Кроме того, знакомство с многочисленными полезными советами сделает вас признанным мас+ тером, причем без особых усилий с вашей стороны. 23—2221

www.books-shop.com

Уточнить наличие соглашения со службой поддержки пользователей Sybase Приступая к установке сервера, убедитесь в наличии соглашения о предоставлении технической под" держки службой поддержки компании Sybase. Будет весьма печально обнаружить в середине процесса установки, что бухгалтерия вашей компании решила сэкономить именно на оплате контракта со службой поддержки Sybase. При отсутствии контракта на круглосуточную поддержку не рекомендует" ся приступать к установке сервера в вечернее время или в выходные дни, если при возникновении неприятностей у вас не будет возможности дождаться начала следующего рабочего дня для обраще" ния в службу поддержки Sybase. Надежнее всего позвонить в службу поддержки и убедиться, что там знают о существовании контракта на поддержку вашей компании, и в находящейся у них копии конт" ракта перечислены фамилии всех сотрудников, которым может потребоваться помощь, а также указа" ны правильные номера вашего телефона и факса. Познакомиться с системным администратором серверной машины Проверьте, что при необходимости вы можете рассчитывать на помощь со стороны системного ад" министратора серверной машины. Убедитесь, что такой человек действительно существует, познако" мьтесь с ним и предупредите о предстоящей установке сервера. Хорошие деловые отношения с системным администратором имеют крайне важное значение. Заранее обсудите с ним план совмест" ных действий. Из руководств по установке сервера вы узнаете о необходимых для нормальной рабо" ты SQL Server, параметрах ядра системы UNIX, которые должны быть установлены и затем периодически контролироваться в процессе эксплуатации сервера. Уточните у системного админист" ратора, выполнил ли он установку необходимых системных заплаток и завершена ли конфигурация аппаратных средств серверной машины. Позаботьтесь о том, чтобы у системного администратора было достаточно времени на выполнение всех подготовительных операций с его стороны. Конечно, нельзя исключить, что вам предстоит одновременно выступать в роли администратора сервера и сис" темного администратора серверной машины. Хотя в подобной ситуации нет ничего необыкновенно" го, она требует хорошего понимания множества различных аспектов функционирования аппаратных средств, операционной системы и сервера. Возможно, здесь потребуется помощь системного админи" стратора, имеющего практический опыт работы с данной аппаратной платформой, в особенности по установке SQL Server. Заранее выясните процедуру обращения в службы технической поддержки ком" паний"поставщиков аппаратного и программного обеспечения серверной машины, включая оборудо" вание и программы независимых фирм"производителей, например рассмотренную нами программу SQL BackTrack, позволяющую создавать логические и физические дампы объектов баз данных. При необходимости включения в состав сервера подобных программных продуктов уточните наличие контракта на техническую поддержку их эксплуатации. Всегда старайтесь быть как можно более доброжелательным по отношению к системным администраторам, обслуживающему персоналу и сотрудникам служб технической под+ держки. При возможности постарайтесь нанести им "визит доброй воли", причем не с пустыми руками. Эти люди настолько привыкли, что на них смотрят свысока или просто игнорируют, что любое внимание с вашей стороны будет оценено по достоинству. Хоро+ шее отношение к вам сослужит добрую службу, когда при отказе сервера вы окажетесь крайним, и босс начнет описывать сужающиеся круги по вашему закутку, задавая один и тот же бессмысленный вопрос: "Когда же вы запустите сервер? Когда же вы наконец за+ пустите сервер?" Проинформировать пользователей и руководство Заранее известите пользователей и руководство о предстоящей установке сервера. Сообщите им об ожидаемой продолжительности этой операции и ее возможных осложнениях. Если новый сервер устанавливается на аппаратно"программной платформе, хорошо знакомой вам по установке предыду" щих серверов, тогда можете рискнуть дать пользователям какие"то определенные обещания. Но ни в коем случае не недооценивайте время, необходимое для установки сервера на новом для вас компью" тере или операционной системе. В любом случае заранее составьте план тестирования сервера, по" зволяющий объективно оценить его работоспособность — например, путем выполнения основного приложения на новом сервере в течение определенного периода времени перед переключением на" грузки со старого сервера. Если целью создания нового сервера является перенос существующих при" ложений со старого сервера, будьте готовы поддерживать оба сервера на время установки и тестирования нового.

www.books-shop.com

Получить полномочия пользователя root Заблаговременно позаботьтесь о наличии у вас системных полномочий на серверной машине либо об участии в процессе установки одного из пользователей с root"полномочиями. При установке сервера вам потребуется выполнить команду su (либо войти в систему в качестве пользователя root), чтобы иметь возможность проверить командой format состояние поверхности дисковых накопителей сер" верной машины. Каждый из администраторов баз данных, отвечающий за работоспособность серве" ра, должен иметь доступ к системным полномочиям. Тем не менее во многих компаниях администраторы баз данных лишены root"полномочий, которые зарезервированы за системным ад" министратором серверной машины. В подобной ситуации понадобится присутствие одного из сис" темных администраторов во время установки сервера. Установить серверную машину Перед установкой сервера на серверной машине необходимо завершить процесс ввода этой машины в эксплуатацию, включающий в себя установку дисковых накопителей и их разбиение на разделы, а также подключение машины к локальной компьютерной сети.

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

Проверка конфигурации установленных дисков Убедитесь в том, что все подключенные дисковые накопители правильно опознаны операционной системой серверной машины. Здесь необходимы полномочия пользователя root, позволяющие воспо" льзоваться системной командой format. Отметим, что администратор сервера не обязан детально вла" деть всеми возможностями команды format. Однако перед первым ее запуском обязательно поставьте системного администратора в известность о том, что вы периодически будете выполнять данную команду (а также, как мы увидим ниже, ряд других системных команд) и что вы не намерены осуществлять командой format каких"либо действий с системой, а ограничитесь исключительно ана" лизом ее выдачи. Если у системного администратора все же останутся возражения, обяжите его пре" доставлять выдачу этой команды по первому вашему требованию. Подчеркнем, что после запуска команды format и появления на экране списка физических дисков серверной машины следует не" медленно выйти из этой команды нажатием клавиш Ctrl"D (на экране терминала появится ^D) и не пытаться выполнить каких"либо других операций. Выдача команды format состоит из трех основных компонентов. Во"первых, format сообщает названия всех физических дисков, известных серверной машине. Во"вторых, эта команда показыва" ет распределение дисковых накопителей по контроллерам дисков, что особенно важно при распре" делении сегментов баз данных по серверным устройствам. В"третьих, анализ выдачи команды format позволяет установить, сколько накопителей подключено к каждому контроллеру, и тем са" мым узнать, какое количество дополнительных дисков может быть подключено к системе. Как отме" чалось выше, для каждой аппаратной платформы существует определенное максимально допустимое количество дисковых накопителей, подключаемых к одному контроллеру дисков без насыщения его пропускной способности. Например, для компьютеров фирмы Sun это число равно четырем. В при" веденной ниже распечатке определяется состав физических дисков северной машины с сетевым именем machinel (напомним, что перед запуском команды format вам необходимо получить ro" ot"полномочия, например, путем выполнения команды su). Рассмотрим сначала информацию, выда" ваемую командой format по одному дисковому накопителю: 0. cOt3dO <SUN2.1G cyl 2733 alt 2 hd 19 sec 80> /iommu@f,eOOOOOOO/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@3,0 Как следует из распечатки, первый физический диск (с номером 0) называется t3dO. Он подклю" чен к контроллеру сО. Вторая строка описания диска содержит его аппаратный адрес. Отметим, что диски иногда называют по их номерам; так, SCSI"диск номер 0 может называться sdO. Из полной рас" печатки выдачи команды format нетрудно установить, что в системе имеются шесть физических дис" ков, подключенных к двум контроллерам (сО, cl), причем к первому контроллеру подключены два, а ко второму — четыре диска:

www.books-shop.com

machinal# format Searching for disks...done AVAILABLE DISK SELECTIONS: 0. cOt3dO <SUN2.1G cyl 2733 alt 2 hd 19 sec 80> /iommu@f,eOOOOOOO/sbus@f,e0001000/espdma@f,400000/esp@f, 800000/sd@3,0 1. cOt5dO <SUN4.2G cyl 3880 alt 2 hd 16 sec 135> /iommu@f,eOOOOOOO/sbus@f,e0001000/espdma@f,400000/esp@f, 800000/sd@5,0 2. cltOdO <SUN4.2G cyl 3880 alt 2 hd 16 sec 135> /iommu@f,eOOOOOOO/sbus@f,e0001000/QLGC,isp@0,10000/sd@0,0 3. cltldO <SUN4.2G cyl 3880 alt 2 hd 16 sec 135> /iommu@f,eOOOOOOO/sbus@f,e0001000/QLGC,isp@0,10000/sd@l,0 4. clt2dO <SUN4.2G cyl 3880 alt 2 hd 16 sec 135> /iommu@f,eOOOOOOO/sbus@f,e0001000/QLGC,isp@0,10000/sd@2,0 5. clt3dO <SUN4.2G cyl 3880 alt 2 hd 16 sec 135> /iommu@f,eOOOOOOO/sbus@f,e0001000/QLGC,isp@0,10000/sd@3,0 Specify disk (enter its number): Разбиение дисков на разделы Убедившись в работоспособности физических дисков и дисковых контроллеров серверной машины, необходимо распределить имеющиеся диски между файловыми системами, серверными устройства" ми и зеркальными копиями серверных устройств, после чего воспользоваться стандартной схемой разделов дисков серверных устройств и их зеркальных копий. Создание разделов дисков файловых систем должно выполняться совместно с системным администратором серверной машины. Напом" ним основные элементы стандартной схемы разделов дисков серверных устройств, подробно рас" смотренной в предыдущих главах книги: 1. Выделите цилиндр 0 каждого физического диска в отдельный раздел 0, после чего систем" ный администратор должен сделать этот раздел недоступным для UNIX"пользователя с именем Sybase, сменив принадлежность соответствующих системных файлов: /dev/dsk/<название_диска>a и /dev/r<название_диска>a для системы SunOS (например, /dev/dsk/sdOa и /dev/rsdOa для диска sdO) либо /dev/dsk/s0 и / d e v / r d s k / < н а з в а н и е _ д с к а > s O для системы Solaris (например, /dev/dsk/cOt3dOsO и /dev/rdsk/cOt3dOsO для диска cOtSdO из приведенного выше примера). 2. Выделите разделу 7 количество цилиндров, соответствующее 50 Мбайт дискового про" странства. 3. Распределите оставшиеся цилиндры диска поровну между разделами 1, 3, 4, 5 и 6. Важно, чтобы все эти разделы имели строго одинаковое количество цилиндров. При необходимо" сти добавьте оказавшиеся лишними цилиндры в раздел 7. 4. Не пытайтесь использовать раздел 2. Аналогично разделу 0, системный администратор должен сделать этот раздел недоступным для пользователя sybase. 5. Попросите системного администратора установить принадлежность UNIX"пользователю Sy" base специальных файлов управления небуферизованным доступом ко всем разделам всех серверных дисков, за исключением разделов 0 и 2 этих дисков.

Определение точных размеров разделов серверных устройств После создания разделов физических дисков администратору сервера необходимо с помощью коман" ды prtvtoc определить точные размеры разделов, назначаемых серверным устройствам. Пример выдачи команды prtvtoc для одного физического диска показан ниже. Обратите внимание на то, что размеры разделов даются в виде количества секторов, имеющихся в каждом разделе. Это число необходимо перевести в мегабайты, умножив его на 512 байтов в секторе и поделив на 1024*1024 бай" тов в мегабайте. К примеру, в приведенной ниже распечатке размер (sector count) раздела 1 составля" ет 1 639 440 секторов, что эквивалентно 800.51 Мбайт. У полученного числа следует отбросить дробную часть и преобразовать его в эквивалентное количество 2"килобайтовых страниц (из расчета 1 Мбайт = 512 страниц), которое указывается при инициализации серверного устройства командой disk init. Отметим, что при использовании стандартной схемы разделов дисковых накопителей

www.books-shop.com

подавляющее большинство разделов имеет идентичные размеры, что значительно сокращает объем требующихся преобразований. machinel: /usr/sbin/prtvtoc /dev/rdsk/cOt5dOsl * /dev/rdsk/cOt5dOsl partition map * * Dimensions: * 512 bytes/sector

* * *

135 sectors/track 16 tracks/cylinder 2160 sectors/cylinder

* 4392 cylinders * 3880 accessible cylinders * * Flags: * 1: unmountable * 10: read"only *

Partition 0 1

First

Tag 0

Flags 00 01 01 00

Sector

Sector Count 2160 1639440 8380800 1639440

Last Sect or Mount

Directory 2159 #> cylinder 0 3 1641599 2 5 8380799 3 0 3281039 #> 800.51 Mb 800 Mb = 409600 2K pages 4 0 00 1639440 3281040 4920479 0 5 00 1639440 4920480 6559919 6 4 00 1639440 6559920 8199359 7 0 00 8199360 181440 8380799 #> 88.59 Mb 88 Mb = 45056 2K pages В данном примере серверным устройствам будут назначаться разделы 1, 3, 4, 5 и 6, каждый из ко" торых содержит 1 639 440 секторов, а также раздел 7, состоящий из 181 440 секторов. Для получе" ния размеров разделов в байтах мы умножаем количество секторов на 512 байтов в секторе (это значение принято в системе Sun Solaris и может отличаться на других платформах), после чего пере" водим байты в мегабайты делением на 1024*1024 (но не на один миллион ровно!). Затем умножаем количество полных мегабайтов (целую часть предыдущего результата) на 512 и находим количество стандартных 2"килобайтовых страниц, размещаемых на данном серверном устройстве. Отметим, что здесь размер одной страницы равен 2048 байт (2 Кбайт). Это значение действует в среде Sun Solaris и может отличаться на других платформах. Для двух только что рассмотренных типов разделов получаем следующие результаты: количество количество количество количество секторов байтов мегабайтов страниц по 2 Кбайт 1639440 839393280 800.508 Мбайт 409600 181440 92897280 88.594 Мбайт 45056 (в системе Solaris • (1 Мбайт = 1024*1024 (в системе Solaris 1 сектор = 5 1 2 байт) = 1048576 байт) 1 страница = 2048 байт и 1 Мбайт = 512 страниц) Напомним читателю ряд положений, обсуждавшихся в главе 8. Каждому разделу диска может быть назначено только одно серверное устройство. Тогда размещение 30"мегабайтового серверного устройства на разделе размером в 500 Мбайт автоматически означает потерю 470 Мбайт дискового пространства. Именно поэтому на сервере обязательно должно иметься несколько небольших разде" лов (например, по 50 Мбайт). Отметим, что в SQL Server System 10 и 11 базы данных master, sybsystemprocs и sybsecurity должны раз" мещаться на трех отдельных серверных устройствах (предпочтительно находящихся на разных кон" троллерах), каждое из которых должно иметь размер около 50 Мбайт. Как подчеркивалось выше, вычисленный размер раздела в мегабайтах должен быть округлен до максимального числа полных мегабайтов. Задание в команде disk init дробного количества мега" байтов (точнее, количества страниц, соответствующего дробному числу мегабайтов) может привес" ти к неприятным последствиям (см. главу 8). Напомним, что инициализация командой disk init

0 2160 0 1641600

www.books-shop.com

производится для всех устройств сервера, за исключением серверного устройства master. Это устройство автоматически создается при работе программ sybinit и buildmaster, которыми луч" ше не пользоваться, если нет полного понимания сути выполняемых действий или рекомендаций службы технической поддержки Sybase. При установке SQL Server System 10 программа sybinit, помимо серверного устройства master, создает устройства syspwcsdev и sybsecurity. Ни одно из трех перечисленных устройств не должно по" вторно инициализироваться командой disk init. Перед запуском sybinit заранее определите требуемый размер серверного устройства master и сообщите его в виде наибольшего полного числа мегабайтов, способных поместиться в выбранном разделе. Получение списка доступных файловых систем Завершив конфигурацию дисков серверных устройств, проверьте наличие необходимых файловых систем командой df "k (пример выдачи команды df "k приводится ниже). Отметим, что формати" рование файловых систем и их установка (mount) на определенные каталоги файловой структуры производится системным администратором серверной машины. Проследите за тем, чтобы ни на од" ном физическом диске одновременно не находились разделы файловых систем и разделы серверных устройств/зеркальных копий серверных устройств. machinel : df "k Filesystem kbytes used avail capacity Mounted on /dev/dsk/cOt3dOsO 674471 262434 344597 44% / /proc 0 0 0 0% /proc fd 0 0 0 0% /dev/fd swap 501984 8 501976 1% /tmp /dev/dsk/cOt3dOs7 1032142 217464 711468 24% /export/home /dev/dsk/cltOdOsl 806647 35190 690797 5% /export/diskl He забудьте проверить, что в каталоге, куда будет производиться установка сервера и сопутствую" щих программных продуктов, имеется достаточно свободного пространства. В данной главе базо" вым (или инсталляционным) каталогом программных продуктов Sybase является каталог machinel : /home/ Sybase (полный путь к нему содержится в переменной среды SYBASE). Именно в этот каталог помещаются переписанные с магнитной ленты (либо скопированные с другой маши" ны) дистрибутивы сервера. По возможности загрузите все исходные файлы непосредственно с носи" теля дистрибутива программных продуктов Sybase, поскольку это гарантирует наличие полного комплекта файлов, требующихся при установке сервера. С помощью руководства по установке сер" вера Sybase на вашей аппаратно"программной платформе определите, какое дисковое пространство требуется для загрузки всех дистрибутивов сервера и для его установки. Убедитесь в наличии нужно" го дискового пространства. Кроме того, уточните принадлежность всех необходимых в процессе установки и сопровождения SQL Server файловых систем UNIX"пользователю с системным именем sybase. Именно этому пользователю предстоит запускать и останавливать сервер, а также записывать дампы баз данных.

Принадлежность специальных файлов устройств и каталога /home/sybase Теперь нужно убедиться в том, что любой администратор баз данных может войти в серверную маши" ну под именем пользователя Sybase, необходимым при запуске программы sybinit для установки SQL Server. Важно подчеркнуть, что установка SQL Server и его запуск не должны выполняться привилегиро" ванным UNIX"пользователем с системным именем root. Ни непосредственная установка сервера программой sybinit, ни его последующая эксплуатация не требуют наличия системных полномо" чий, имеющихся у пользователя root. Разумеется, такие полномочия более чем достаточны для запу" ска программы sybinit или SQL Server, но это может привести к случайному уничтожению произвольных разделов дисков сервера и компонентов его программного обеспечения. Перед установкой проверьте принадлежность файлов в инсталляционной директории (все фай" лы в этом каталоге и его подкаталогах должны принадлежать пользователю sybase). Кроме того, по" скольку программа sybinit будет создавать серверные устройства master, sysprocsdev и sybsecurity, все системные файлы небуферизованного (raw) доступа к соответствующим разделам физических дисков также должны принадлежать UNIX"пользователю sybase.

www.books-shop.com

Для начала получим полный список разделов (секций — slices), имеющихся на серверной машине: machinel: cd /dev/rdsk machinel: Is Clt0d0s4 cltldOs3 cOt3dOs7 cOt5dOs6 cOt6dOs5 cOt3dOsO Clt2d0s2 clt3dOsl cltldOs4 cOt5dOsO cOt5dOs7 cOt6dOs6 cltOdOs5 cOt3dOsl Clt2d0s3 clt3dOs2 cOt6dOs7 cltOdOs6 cltldOs5 cOt3dOs2 cOt5dOsl cOt6dOsO Clt2d0s4 clt3dOs3 clt0d0s7 cltldOs6 cltOdOsO cOt3dOs3 cOt5dOs2 cOt6dOsl Clt2d0s5 clt3dOs4 cltldOs7 cOt3dOs4 cOt6dOs2 cltOdOsl cltldOsO cOt5dOs3 clt2dOs6 Clt3d0s5 Clt2d0s0 cltOdOs2 cOt3dOs5 cOt5dOs4 cOt6dOs3 cltldOsl clt2dOs7 Clt3d0s6 cltldOs2 clt2dOsl cOt3dOs6 cOt6dOs4 cltOdOs3 cOt5dOs5 clt3dOs7 Clt3d0s0 Теперь проверим принадлежность специального файла небуферизованного доступа к одному из перечисленных выше разделов: machinel: 1s "1 cOt5dOs3 1rwxrwxrwx 1 root other 88 Jul 22 16:49 cOt5dOs3 "> ../../devices/iommu@f,eOOOOOOO/sbus@f,e0001000/espdma@f,400000/esp@f, 800000/sd@5,0:d,raw Создается впечатление, что указанный раздел принадлежит пользователю root; однако это невер но. В системе Solaris подобная команда должна вызываться с параметром L: machinel: 1s #L1 cOt5dOs3 crw#r 1 sybase sys 32, 43 Jul 22 16:49 cOt5dOs3 Присвоить переменной среды SYBASE значение /home/sybase Важно проверить, что переменная среды SYBASE действительно указывает на инсталляционный каталог программ Sybase, который должен называться /home/sybase. Текущее значение перемен" ной SYBASE можно распечатать командой echo $SYBASE и при необходимости установить командой setenv SYBASE /home/sybase. Неправильное значение переменной SYBASE может привести к не" полной установке сервера либо к невозможности запуска программы sybinit. Скопировать дистрибутивы сервера в инсталляционный каталог Перед установкой SQL Server все необходимые файлы следует скопировать в инсталляционный ката" лог /home/sybase. При наличии в системе нескольких версий SQL Server или других программных продуктов Sybase каждая из этих версий должна быть установлена в отдельном каталоге. Например, все файлы SQL Server System 10 следует разместить в каталоге /home/sybase/10 . О . 2, а сервер вер" сии System 11 — в каталоге /home/sybase/11.0.1. Хотя инсталляционные файлы при необходимо" сти могут быть скопированы с одной из других серверных машин, на которых уже установлена требуемая версия сервера, их лучше переписать непосредственно с исходной магнитной ленты (это будет гарантировать наличие полного комплекта исходных файлов, поскольку часть из них могла быть удалена с работающего сервера из"за недостатка свободного места). Запустить программу sybinit По завершении всех необходимых подготовительных операций можно наконец запустить программу sybinit, входящую в комплект поставки SQL Server, и приступить к установке сервера. В процессе своей работы программа sybinit создаст серверное устройство master, базы данных master, model, tempdb и sybsystemprocs (а также необязательную базу данных sybsecunty), после чего установит на сервер комплект системных хранимых процедур (таких, как sp_who), включит в файл интерфейсов описа" ние нового сервера, создаст командный файл запуска этого сервера (с именем RUN_<имя_сервера>), определит язык, набор символов и порядок сортировки, используемые по умолчанию, и установит поддержку всех необходимых дополнительных наборов символов и национальных языков. Успешное завершение работы программы sybinit означает окончание установки собственно сервера, после чего можно перейти к процессу конфигурирования сервера и инициализации сервер" ных устройств, подключение которых к серверу позволит приступить к созданию пользовательских баз данных.

www.books-shop.com

Установка SQL Server System 11 Как уже хорошо известно читателю, SQL Server System 11 на компьютерах SUN работает только под управлением операционной системы Solaris, в то время как предыдущие версии — SQL Server 4.9.2 и System 10 — успешно функционировали как в системе Solaris, так и в SunOS. Поэтому во многих случа" ях первым этапом установки сервера System 11 становится перевод серверной машины на операцион" ную систему Solaris. Непосредственная установка SQL Server System 11 начинается с запуска программы sybinit, ад" ресующей пользователю ряд запросов. Ответы на них желательно подготовить заранее. Хотя в данном разделе рассматривается первоначальная установка сервера System 11, а не про" цесс обновления SQL Server 4.9.2, необходимо отметить наиболее существенные различия в установ" ке этих версий SQL Server. Важнейшим из них является то, что установка SQL Server 4.9.2 требует создания только одного серверного устройства — master, в то время как программа установки Sys" tem 11 создает сразу три серверных устройства. Помимо master, к их числу относится серверное устройство sysprocsdev, используемое для размещения базы данных sybsystemprocs. База данных sybsys temprocs содержит основную часть системных хранимых процедур, в SQL Server 4.9.2 находившихся непосредственно в базе данных master. Необходимость создания отдельной базы данных для систем" ных процедур была вызвана значительным расширением их состава в System 11. Сохранение систем" ных процедур в базе данных master потребовало бы расширения серверного устройства master в процессе перехода от SQL Server 4.9.2 к System 11. Однако во многих информационных системах на серверном устройстве master уже нет свободного дискового пространства, а его расширение потре" бовало бы полной переустановки сервера. В результате компания Sybase приняла решение включить в состав сервера отдельную системную базу данных sybsystemprocs Третье серверное устройство, создаваемое программой sybinit при установке SQL Server Sys" tem 11, называется sybsecurity и предназначается для размещения одноименной базы данных, обеспе" чивающей поддержку появившихся в составе System 11 новых средств аудита работы сервера. Подобные средства позволяют серверу регистрировать разнообразную информацию об операциях, выполняемых пользователями сервера с самим сервером и с хранящимися в нем данными. Отметим, что создание базы данных и серверного устройства sybsecunty не является обязательным. В случае же их создания устройство sybsecurity, подобно устройствам master и sysprocsdev, должно находиться в отдельном зеркально резервированном разделе диска (причем все три перечисленных устройства лучше всего разместить на отдельных контроллерах). Если непосредственно в процессе установки сервера вы решили не создавать отдельного небольшого (минимальный размер 30 Мбайт) серверно" го устройства специально для базы данных sybsecunty, то при последующий активизации средств аудита сервера эту базу данных придется разместить на одном из больших серверных устройств со" вместно с другими базами данных сервера. Таким образом, поскольку в процессе установки все рав" но следует создать небольшое серверное устройство (а также его зеркальную копию) для базы данных sybsecurity, то проще выполнить полную установку средств аудита, что в дальнейшем значите" льно облегчит их активизацию. Отметим, что установка устройства и базы данных sybsecunty вовсе не означает автоматической активизации средств аудита SQL Server. Заметим, что в процессе установки SQL Server программа sybinit самостоятельно запустит но" вый сервер, и по завершении ее работы не нужно запускать еще одну копию сервера. В состав SQL Server System 11 в качестве отдельного программного продукта входит сервер архи" вации Backup Server, обеспечивающий создание дампов баз данных и журналов транзакций. Его установка также осуществляется с помощью программы sybinit — либо непосредственно в процес" се установки SQL Server, как это показано в прилагаемом протоколе сеанса установки, либо в рамках отдельного сеанса работы с программой sybinit. Наконец, при установке SQL Server System 11 не требуется специальная строка авторизации кли" ента или серийный номер сервера. В рассматриваемой версии сервера строку авторизации клиента (customer authorization string) необходимо ввести в процессе загрузки файлов с магнитной ленты ди" стрибутива сервера Sybase. Процесс загрузки файлов зависит от конкретной платформы и подробно рассматривается в руководстве по установке сервера. Каталог установки (Release Directory) В ответ на данный запрос укажите фактически используемое имя каталога, куда будет производиться установка данной версии сервера. Этот каталог должен совпадать с инсталляционной директорией SYBASE, которая в нашем примере называется /home/sybase.

www.books-shop.com

Имя сервера (Server Name) Задайте имя устанавливаемого сервера. В некоторых случаях не возможно сразу дать серверу его окончательное имя для промышленной эксплуатации — например, при замене одного из существую" щих серверов информационной системы, которому предстоит продолжать нормальную работу до за" вершения тестирования нового сервера.

Информация для файла интерфейсов (Configure Server Interfaces File Entry) Здесь программа sybinit запрашивает информацию, на основании которой в файл интерфейсов бу" дет включено описание нового сервера. Отметим, что сам файл интерфейсов появится в инсталляци" онной директории, и впоследствии вам потребуется вручную перенести необходимые строки в основной файл интерфейсов вашей системы. В ответ на запрос нужно указать номер порта серверной машины, распределяемый серверу в соответствии с общей схемой конфигурации серверов и сервер" ных машин вашей информационной системы (см. главу 8). В качестве серверной машины программа sybinit выбирает компьютер, на котором она запущена. Если это не так, необходимо явно указать программе sybinit имя требуемой серверной машины. Помимо сетевого имя серверной машины и номера ее порта, вы также можете указать число попыток (Retry Count), предпринимаемых при не" возможности соединения клиента с сервером, и интервал между последовательными попытками (Retry Delay). По умолчанию обе величины имеют значение, равное нулю. При их изменении следует иметь в виду, что невозможность соединения клиента с сервером обычно свидетельствует о наличии серьезных проблем, которые вряд ли устранятся сами собой через небольшой промежуток времени. Более подробно роль этих параметров рассматривается в руководстве по установке сервера. Файл небуферизованного доступа к разделу серверного устройства master (File for Master Device Raw Partition) Укажите полное имя файла, который управляет небуферизованным доступом к разделу диска, назна" чаемому серверному устройству master. Размер серверного устройства master в мегабайтах (Size of Master Device in Megabytes) Обратите внимание на то, что размер серверного устройства master задается программе sybinit в мегабайтах, а не в виде количества секторов, как этого требует программа sybconf ig при установке SQL Server 4.9.2. Напомним, что здесь необходимо указать наибольшее целое число мегабайтов, вме" щаемое выбранным дисковым разделом (см. главу 8). Файл небуферизованного доступа к разделу серверного устройства sysprocsdev (File for Sysprocsdev Device Raw Partition) Здесь следует указать полное имя файла, управляющего небуферизованным доступом к разделу дис" ка, которому будет назначено серверное устройство sysprocsdev. Это устройство используется для раз" мещения обязательной системной базы данных sybsystemprocs, содержащей системные хранимые процедуры сервера. Устройство sysprocsdev не может совпадать с серверным устройством master; эти устройства лучше размещать на разных дисковых накопителях, подключенных к разным контролле" рам. Размер серверного устройства sysprocsdev в мегабайтах (Size of Sysprocsdev Device in Megabytes) Сообщите программе sybinit размер серверного устройства sysprocsdev в мегабайтах. Не забудьте, что необходимо указать наибольшее целое число мегабайтов, вмещаемое выбранным дисковым раз" делом (см. главу 8). Местонахождение журнала регистрации ошибок (Errorlog Location) Укажите полное имя файла регистрации ошибок сервера. Этот файл по умолчанию размещается в подкаталоге install инсталляционной директории Sybase (т.е. имеет полное имя / home/ sybase/ ins " tall/errorlog) . Поскольку в процессе своей работы программа sybinit должна запустить сервер для установки хранимых процедур и внесения ряда изменений в конфигурацию сервера, журнал реги" страции ошибок, созданный при первом запуске сервера, будет содержать весьма важную информа" цию, и его следует сохранить вместе со всеми инсталляционными файлами. Рекомендуем принять

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

предложенное по умолчанию имя и только по завершении всего процесса установки вручную задать окончательное имя и каталог журнала регистрации ошибок. Время от времени администратор сервера должен удалять старые журналы регистрации ошибок, накапливающиеся в соответствующем каталоге промышленно эксплуатируемого сервера (обычно этот каталог называется /homeе/<имя_сервера>/еггог1од), чтобы избежать переполнения файловой системы, влекущее за собой останов сервера. Попадание самого первого журнала регистрации ошибок в один каталог со всеми последующими журналами с большой вероятностью приведет к его случайному удалению. Имя сервера архивации (Backup Server Name) Задайте имя сервера архивации. Отметим, что здесь речь идет вовсе не об установке сервера архива" ции, а только об изменении его имени, хранящегося в системной таблице sysservers устанавливаемого SQL Server (по умолчанию имя сервера архивации задается как SYB_BACKUP). Установка сервера ар" хивации производится с помощью той же программы sybinit по завершении установки основного SQL Server. Рекомендуем придерживаться стандартной схемы назначения имен и назвать сервер ар" хивации <имя_SQL_Server>_BCK., Установленные и используемые по умолчанию национальные языки (Languages Installed and Default) Установленное значение языка, используемого по умолчанию, должно быть таким же, как и на всех остальных серверах информационной системы. Выбирая другой применяемый по умолчанию язык, соблюдайте крайнюю осторожность. Постарайтесь предварительно выяснить последствия подобно" го шага. В качестве дополнительных национальных языков можно указать любые языки, поддержива" емые SQL Server. Установленные и используемые по умолчанию наборы символов (Character Sets Installed and Default) Аналогично языку, используемый по умолчанию набор символов должен быть одним и тем же на всех серверах информационной системы. Выбор набора символов влияет на порядок сортировки, приме" няемый по умолчанию. Более подробную информацию о взаимосвязях между наборами символов и порядком сортировки можно получить из руководства по установке сервера и другой сопутствующей документации. В качестве дополнительно устанавливаемых наборов символов вы можете указать лю" бые наборы символов, поддерживаемые SQL Server. Порядок сортировки (Sort Order Installed) Как отмечалось в предыдущем разделе, установленный порядок сортировки связан с набором симво" лов, используемым по умолчанию. Тождественность порядка сортировки на разных серверах одной информационной системы имеет исключительно важное значение. После загрузки в сервер каких"ли" бо данных невозможно изменить ранее установленный порядок сортировки без создания полного ло" гического дампа сервера (см. главу 9) и его последующей загрузки. Более того, изменение порядка сортировки приведет к невозможности загрузки всех физических дампов баз данных, созданных ра" нее на том же самом сервере. Порядок сортировки определяет, как именно должны упорядочиваться данные при их записи на диск. Любое изменение порядка сортировки приводит к необходимости пе" реупорядочивания записанных на диске данных, на что в случае больших баз данных потребуется очень много времени. Перед тем как приступить к изменению установленного порядка сортировки в процессе эксплуатации сервера, обязательно проконсультируйтесь со службой технической поддерж" ки Sybase и подготовьте подробный план восстановления всех имеющихся баз данных. При выборе первоначально устанавливаемого порядка сортировки рекомендуем проверить порядок сортировки, используемый другими серверами информационной системы (все они обязательно должны иметь одинаковый порядок сортировки и используемый по умолчанию набор символов), а затем установить на новом сервере значения, идентичные значениям на всех остальных серверах. Для быстрого опре" деления используемого порядка сортировки и набора символов по умолчанию следует посмотреть за" ключительные записи процедуры запуска сервера в журнале регистрации ошибок сервера. В самом конце своего восстановления после запуска сервер выдает в журнал регистрации ошибок значения идентификаторов порядка сортировки и набора символов по умолчанию. Убедитесь, что журнал ре" гистрации ошибок вашего нового сервера содержит те же самые значения этих идентификаторов, что и журналы ошибок всех остальных серверов системы.

www.books-shop.com

Файл небуферизованного доступа к разделу серверного устройства sybsecurity (File for sybsecurity Device Raw Partition) Здесь указывается полное имя файла, управляющего небуферизованным доступом к разделу диска, ко" торому будет назначено серверное устройство sybsecurity. Это устройство используется для размеще" ния необязательной системной базы данных sybsecurity, необходимой при использовании средств аудита SQL Server System 11. Отметим, что первоначальная установка сервера вовсе не требует уста" новки средств аудита. Однако при их установке впоследствии вам все равно потребуется небольшой (минимум 30 Мбайт) дисковый раздел и его зеркальная копия, которых на промышленно эксплуати" руемом сервере может уже не оказаться. Поэтому рекомендуем в любом случае установить средства аудита, даже если вы не намерены немедленно активизировать их. Устройство sybsecurity не может совпадать с серверными устройствами master и sysprocsdev. Все три устройства лучше размещать на разных дисковых накопителях, подключенных к разным контроллерам. Размер серверного устройства sybsecurity в мегабайтах (Size of sybsecurity Device in Megabytes) Укажите размер серверного устройства sybsecurity в мегабайтах. Не забудьте, что нужно указать наибольшее целое число мегабайтов, вмещаемое выбранным дисковым разделом (см. главу 8). Следующие несколько разделов главы описывают установку сервера архивации Backup Server System 11 с помощью программы sybinit. Подобная операция может выполняться как в ходе сеан" са установки SQL Server, так и в качестве отдельного сеанса работы с программой sybinit. Сервер архивации обязательно следует установить до начала записи или загрузки дампов баз данных и жур" налов транзакций SQL Server. Каталог установки сервера архивации (Backup Server Release Directory) Введите имя каталога, куда будет производиться установка сервера архивации. Этот каталог должен совпадать с инсталляционной директорией SYBASE, которая в нашем случае называется /home/sy" base. Имя сервера архивации (Backup Server Name) При выборе имени сервера архивации рекомендуется придерживаться стандартной схемы назначе" ния имен, согласно которой сервер архивации должен называться <имя_SQL_Server>BCK.. Как отме" чалось выше, устанавливаемый SQL Server далеко не во всех случаях сразу получает свое окончательное имя, что также необходимо учитывать при выборе имени сервера архивации. Журнал регистрации ошибок сервера архивации (Backup Server Errorlog) В силу причин, рассмотренных выше при обсуждении выбора имени журнала ошибок SQL Server, ре" комендуем принять предложенное по умолчанию имя журнала регистрации ошибок сервера архива" ции. Информация для файла интерфейсов (Backup Server Interfaces File Information) Укажите программе sybinit информацию, необходимую для включения описания сервера архива" ции в файл интерфейсов. Созданный программой sybinit файл интерфейсов появится в инсталля" ционной директории, и впоследствии вам потребуется вручную перенести необходимые строки в основной файл интерфейсов вашей системы. Программа sybinit запросит номер порта серверной машины, назначаемого серверу архивации в соответствии с общей схемой конфигурации серверов и серверных машин информационной системы (см. главу 8). По умолчанию в качестве серверной ма" шины программа sybinit выбирает компьютер, на котором она запущена. Если это не так, необхо" димо явно указать программе sybinit имя требуемой серверной машины. Язык и набор символов сервера архивации (Backup Server Language and Character Set) Набор символов и язык сервера архивации должны совпадать с установленными в SQL Server.

www.books-shop.com

Установка SQL Server System 10 Процесс установки SQL Server System 10 практически идентичен установке сервера System 11 — с той лишь разницей, что, помимо системы Solaris, сервер System 10 поддерживает на компьютерах фирмы Sun и систему SunOS. При установке SQL Server System 10 диалог пользователя с программой sybinit практически аналогичен описанному выше в разделе "Установка SQL Server System 11". Единственным отличием является установка сервера архивации, когда в самом конце программа sybinit запрашивает назва" ние конфигурационного файла ленточных устройств сервера архивации, которое рекомендуется за" давать по умолчанию. Сервер архивации System 11 способен определять параметры ленточных устройств самостоятельно, без помощи специального конфигурационного файла. Установка SQL Server 4.9.2 Установка SQL Server версии 4.9.2 производится с помощью программы sybconf ig, адресующей пользователю ряд перечисленных ниже запросов. Ответы на них полезно подготовить заблаговре" менно. Перед установкой сервера переменной среды SYBASE следует присвоить название инсталляцион" ной директории программных продуктов компании Sybase (/home/sybase в нашем случае). При по" иске необходимых ей файлов программа sybconf ig постоянно использует переменную SYBASE, не запрашивая непосредственно название инсталляционной директории. Текущее значение перемен" ной SYBASE можно проверить UNIX"командой echo $ SYBASE. В процессе установки сервера программа sybconf ig автоматически запускает новый сервер для установки хранимых процедур и для внесения ряда изменений в его конфигурацию. По завершении процесса установки сервера, перед тем как приступить к созданию дерева директорий эксплуатаци" онной копии сервера и командных файлов его запуска, не забудьте остановить запущенную sybcon" f ig копию сервера к моменту повторного запуска сервера из эксплуатационной директории. Тип серверного устройства master — раздел диска или файл (Type of Master Device — Raw Partition or Regular File) Серверное устройство master должно всегда находиться в небуферизованном разделе физического диска (принципиальные отличия файловых серверных устройств обсуждаются в главе 8). Полное имя серверного устройства master, размещенного в разделе физического диска (Path Name for Master Device) Укажите полное имя специального системного файла, который управляет небуферизованным вво" дом"выводом в дисковый раздел, назначаемый устройству master. Размер дискового раздела в виде числа секторов (Size of Partition in Sectors) Количество секторов, расположенных в данном разделе диска, легко определить из выдачи команды prtvtoc (см. выше). Однако здесь важно указать количество секторов, соответствующее целому чис" лу мегабайтов. Напомним, что для определения числа байтов в разделе количество секторов необхо" димо умножить на 512 байтов в секторе (уточните применимость приведенного значения количества байтов в секторе для вашей аппаратной платформы). В одном мегабайте содержится 2048 512"байто" вых секторов. Имя сервера (Server Name) Выберите для сервера подходящее имя — например, на основании сетевого имени машины и версии SQL Server. При установке SQL Server версии 4.9.2 на серверную машину psycho ему можно дать имя PSYCHO_492. Номер порта для запросов серверу (Server Query Port Number) (рекомендуется 5001) Указанный номер порта должен соответствовать стандартной схеме нумерации портов, используе" мой в вашей информационной системе (см. главу 8). Язык по умолчанию (Default Language) Язык, используемый по умолчанию, должен совпадать с языками, установленными в остальных серве" рах вашей системы баз данных. При выборе любого другого языка будьте крайне осторожны.

www.books-shop.com

Постарайтесь заранее проанализировать все возможные ограничения, которые возникнут при переносе данных между разными серверами системы, а также при импорте и экспорте данных вне системы. Набор символов по умолчанию (Default Character Set) Сделайте используемый по умолчанию набор символов идентичным наборам, установленным в оста" льных серверах информационной системы. Выбор иного набора символов повлияет на используе" мый порядок сортировки, что может серьезно ограничить обмен дампами между серверами. Взаимосвязь набора символов и порядка сортировки подробнее описана в руководстве по установке сервера и в другой сопутствующей документации. Порядок сортировки (Sort Order) Установленный порядок сортировки связан с набором символов, используемым по умолчанию. Тож" дественность порядка сортировки на разных серверах одной информационной системы имеет иск" лючительно важное значение. После загрузки в сервер каких"либо данных нельзя изменить ранее установленный порядок сортировки без создания полного логического дампа сервера (см. главу 9) и его последующей загрузки. Изменение порядка сортировки приводит к невозможности загрузки всех физических дампов баз данных, созданных ранее на том же самом сервере. Порядок сортировки ука" зывает серверу, как именно должны упорядочиваться данные при их записи на диск. Любое измене" ние порядка сортировки приводит к необходимости переупорядочивания записанных на диске данных, на что в случае больших баз данных требуется очень много времени. Перед тем как присту" пить к изменению установленного порядка сортировки в процессе эксплуатации сервера, обязатель" но проконсультируйтесь со службой технической поддержки Sybase и подготовьте подробный план восстановления всех имеющихся баз данных. При выборе первоначально устанавливаемого порядка сортировки рекомендуем проверить порядок сортировки, используемый другими серверами инфор" мационной системы, которые обязательно должны иметь одинаковый порядок сортировки и исполь" зуемый по умолчанию набор символов, а затем установить на новом сервере значения, идентичные значениям на всех остальных серверах. Для определения используемого порядка сортировки и набо" ра символов по умолчанию найдите в журнале регистрации ошибок заключительные записи процеду" ры запуска сервера. При завершении восстановления после запуска сервер выдает в журнал регистрации ошибок значения идентификаторов порядка сортировки и набора символов по умолча" нию. Проверьте совпадение значений этих идентификаторов в журналах регистрации ошибок ново" го сервера и в журналах всех остальных серверов системы. Дополнительная языковая поддержка (Additional Languages) При необходимости дополнительные национальные языки могут быть установлены позднее. Дополнительные наборы символов (Additional Character Sets) При необходимости дополнительные наборы символов могут быть установлены позднее. Серийный номер (Serial Number) Укажите серийный номер устанавливаемого экземпляра SQL Server. В принципе, здесь можно задать любое число, например 99999. Заметим, что серийный номер указывается в выдаче процедуры sp_configure. Основные операции после установки сервера Успешное завершение работы программы sybinit означает окончание первоначальной установки сервера. Перед практической эксплуатацией сервера требуется выполнить целый ряд перечисленных ниже операций. За небольшим исключением, все рассматриваемые действия относятся ко всем вер" сиям SQL Server. Возможно, при установке конкретного сервера в приведенный список придется внести некоторые изменения и дополнения. • Записать дамп базы данных master 1

• Изменить пароль пользователя 'sa • Задать объем памяти сервера

• Установить количество серверных устройств • Сконфигурировать устройства вывода дампов (только для SQL Server 4.9.2) • Создать и выполнить командный файл инициализации серверных устройств

www.books-shop.com

• Создать и выполнить командный файл зеркального отображения серверных устройств • Создать командный файл установки конфигурации сервера • Создать и выполнить командный файл добавления серверов в таблицу sysservers • Создать файл интерфейсов (или внести необходимые изменения в существующую версию файла) • Загрузить таблицу syslogins • Добавить в базу данных model учетные записи пользователей, осуществляющих запись дампов (только для SQL Server 4.9.2) • Создать пользовательские базы данных • Записать дамп базы данных master • Сохранить ленточные дампы файловых систем • Создать командные файлы для эксплуатационной копии сервера Записать дамп базы данных master По завершении первоначальной установки сервера следует немедленно сохранить дамп базы данных master, что позволит восстановить ее при ошибках и сбоях в ходе дальнейшей модификации сервера. В зависимости от версии сервера, перед записью дампа базы данных master может потребоваться со" здать серверное устройство сохранения дампов, а также изменить принадлежность файловой систе" мы, предназначенной для вывода дампов, либо файла управления выводом на ленточное устройство вывода дампов. По всей видимости в этот момент вы по"прежнему будете работать в качестве UNIX"пользователя Sybase. В процессе работы программа sybinit создает ряд устройств вывода дампов, применяемых по умолчанию. Перед тем как использовать одно из этих устройств для записи дампа базы данных mas ter, проверьте его командой sp_helpdevice и убедитесь, что это устройство производит запись в дисковый файл или ленточное устройство, реально существующее на серверной машине и способ" ное вместить сохраняемый дамп. При работе с SQL Server 4.9.2 перед созданием дампа базы данных master необходимо вручную включить устройство вывода дампов в конфигурацию сервера. В процес" се дальнейшей установки сервера рекомендуется неоднократно сохранять дампы базы данных master. Изменить пароль пользователя 'sa' Измените пароль администратора сервера — пользователя 'sa'. Для того чтобы новый сервер мог нор" мально взаимодействовать по сети с другими серверами информационной системы, пароль пользова" теля 'sa' должен быть одинаковым на всех серверах. Впрочем, следует внимательно проанализировать структуру обеспечения безопасности межсерверного взаимодействия в системе и определить, абсо" лютно ли необходимо подобное требование в каждом конкретном случае. Задать объем памяти сервера Установленный сервер должен быть сконфигурирован таким образом, чтобы использовать максима" льно возможный объем оперативной памяти серверной машины. Для начала попробуйте выделить серверу 80% всей оперативной памяти, имеющейся на серверной машине. Учтите, что для нормаль" ной работы операционной системы необходимо от 10 до 20 Мбайт оперативной памяти (эти цифры следует уточнить у системного администратора, поскольку они сильно различаются для разных аппа" ратно"программных платформ). Поскольку многие другие изменения в конфигурации сервера (на" пример, увеличение количества серверных устройств и одновременно поддерживаемых сеансов работы пользователей) требуют дополнительной оперативной памяти, ее необходимо распределить в самом начале конфигурирования сервера. Установить количество серверных устройств При установке сервера максимальное количество серверных устройств (логических дисков сервера) по умолчанию равняется 10. Уточнить фактически установленное значение этого и других конфигу" рационных параметров сервера можно с помощью вызова процедуры sp_configure без дополните" льных аргументов. Максимальное количество поддерживаемых серверных устройств должно быть увеличено до запланированного, что обеспечит работу всех пользовательских баз данных, которые предполагается создать на новом сервере.

www.books-shop.com

Сконфигурировать устройства вывода дампов (только для SQL Server 4.9.2) При установке SQL Server версии 4.9.2 в его конфигурацию нужно вручную включить все необходи" мые устройства вывода дампов на магнитные ленты и в дисковые файлы. Отметим, что как минимум одно такое устройство требуется создать перед сохранением дампа базы данных master. Создать и выполнить командный файл инициализации серверных устройств Инициализацию серверных устройств проще всего выполнить с помощью командного файла, кото" рый представляет собой последовательность команд disk init, инициализирующих логические ди" сковые устройства сервера в соответствии с заранее запланированной конфигурацией дискового поля сервера. Как подчеркивалось в главе 8, перед определением количества 2"килобайтовых стра" ниц фактический объем устройства следует уменьшить до ближайшего целого числа мегабайтов. По" сле создания командный файл инициализации серверных устройств не следует запускать на выполнение немедленно. Любая опечатка в одной из команд инициализации может нарушить струк" туру устройств, создаваемых последующими командами. Поэтому копию только что созданного командного файла следует разбить на набор команд, выполняемых по отдельности. Напомним, что любая ошибка при выполнении команды disk init блокирует виртуальный номер устройства vdev по, указанный в команде. После однократного выполнения всех команд файла инициализации устройств и внесения в него необходимых исправлений можно повторно выполнить эти команды уже в составе единого файла, при необходимости предварительно перезапустив сервер для разблокирова" ния ранее использовавшихся виртуальных номеров устройств. Готовый командный файл инициали" зации серверных устройств является важнейшим средством воссоздания сервера, а также одним из ключевых элементов эксплуатационной документации сервера. Как неоднократно подчеркивалось в книге, серверное устройство master ни в коем случае не сле" дует инициализировать командой disk init. Кроме того, его необходимо исключить из пула сер" верных устройств, используемых по умолчанию. Создать и выполнить командный файл зеркального отображения серверных устройств Командный файл, создающий зеркальные копии серверных устройств, состоит из последовательно" сти команд disk mirror. При отладке этот файл также следует разбить на отдельно выполняемые команды. Создать командный файл установки конфигурации сервера Все изменения, вносимые в конфигурацию сервера, должны отражаться в отдельном командном фай" ле. Это позволит при необходимости быстро воссоздать сервер. В начале подобного файла нужно ука" зать команду распределения оперативной памяти серверной машины, вслед за ней — другие команды установки конфигурации сервера, например увеличения числа серверных устройств. При создании рассматриваемого командного файла большую помощью окажет выдача команды sp_configure, ко" торую рекомендуется периодически выполнять в процессе установки сервера.

Создать и выполнить командный файл добавления серверов в таблицу sysservers Этот командный файл включает в системную таблицу sysservers нового сервера описания всех локаль" ных и удаленных серверов, имеющихся в системе. За основу можно взять аналогичный командный файл любого из других серверов системы, поскольку оба сервера не должны отличаться по составу удаленных серверов. Отметим, что новый сервер должен быть внесен в таблицы sysservers всех серве" ров, с которыми ему предстоит взаимодействовать, а также в соответствующие командные файлы этих серверов. Создать файл интерфейсов (или внести необходимые изменения в существующую версию файла) Проанализируйте структуру вашей информационной системы и определите, какие группы пользова" телей и другие серверы системы должны знать о существовании нового сервера, описание которого нужно внести во все соответствующие файлы интерфейсов. Вероятно, на новой серверной машине уже установлена полная серверная версия файла интерфейсов. Перед установкой сервера этот файл следует скопировать в инсталляционную директорию нового сервера (/home/sybase). Программа

www.books-shop.com

установки автоматически включит описание нового сервера в данный файл. В результате вы получи" те готовую обновленную серверную версию интерфейсного файла информационной системы. Выяс" ните, следует ли включать описание нового сервера в клиентскую версию этого файла. Загрузить таблицу syslogins После запуска нового сервера необходимо загрузить учетную информацию обо всех его будущих поль" зователях (которые могут составлять лишь некоторую часть пользователей системы). Для этого мож" но написать два командных файла, один из которых будет находить каждую учетную запись в таблице syslogins какого"либо из существующих серверов системы, а другой — загружать командой sp_addlo" gin все найденные записи в новый сервер. Более простым и быстрым вариантом является выдача командой bср всех записей таблицы syslogins прежнего сервера в дисковый файл с последующим ко" пированием этого файла и его загрузкой в новый сервер. Но перед загрузкой в полученный файл не" обходимо внести некоторые изменения. И старый, и новый серверы содержат учетную запись администратора сервера — пользователя 'sa' с идентификатором suid = 1. Однако поле suid является уникальным ключом индекса таблицы syslogins, и это приведет к аварийному завершению работы команды bср, загружающей учетные записи пользователей в новый сервер. Попытаться избежать этой проблемы можно путем удаления всех записей таблицы syslogins нового сервера. Но делать этого не следует, поскольку тем самым будет удалена и учетная запись администратора сервера. При прави" льном способе действий вы удаляете из таблицы syslogins все записи, за исключением учетной записи пользователя 'sa'. Затем перед загрузкой файла учетных записей вручную удаляете из него строку с описание пользователя 'sa' (с идентификатором suid= 1). Заметим, что загрузка полного комплекта учетных записей обеспечит совпадение идентификаторов пользователей (suid) старого и нового сер" веров. Это очень важно при переносе дампов баз данных, поскольку при описании прав доступа поль" зователей к объектам в базах данных используются именно идентификаторы suid. Добавление к новому серверу любых пользователей, не имевших доступа к прежнему серверу, следует осуществлять только после загрузки всех учетных записей пользователей прежнего сервера. Это позволит свести к минимуму проблемы с присвоением пользовательских идентификаторов suid. Еще раз подчеркнем, что каждый пользователь информационной системы должен иметь один и тот же идентификатор suid на всех серверах системы, это значительно облегчает решение проблем с контролем за правами доступа к данным. Добавить в базу данных model учетные записи пользователей, осуществляющих запись дампов (только для SQL Server 4.9.2) Любой пользователь, намеревающийся записать дамп одной из баз данных, должен являться пользо" вателем этой базы данных и иметь необходимые полномочия на сохранение ее дампа. Обычно за со" здание дампов баз данных в информационной системе отвечает определенная группа пользователей. При работе с SQL Server версии 4.9.2 можно сэкономить немало времени, если с самого начала доба" вить всех соответствующих пользователей в базу данных model, что автоматически сделает их пользо" вателями любой будущей базы данных (одновременно не забудьте добавить этих пользователей и в базу данных master). Для этого сначала создайте в базе данных model группу для пользователей, кото" рым требуются полномочия на сохранение дампа базы данных, добавьте в эту группу всех пользовате" лей, отвечающих за работу с дампами, а затем предоставьте всей группе необходимые полномочия. Рекомендуем оформить этот процесс в виде командного файла, который пригодится при восстанов" лении сервера в будущем. Создать пользовательские базы данных После запуска сервера, отведения ему необходимой памяти, увеличения количества серверных устройств, инициализации этих устройств последовательностью команд disk init и добавления в базу данных model пользователей, отвечающих за работу с дампами, можно наконец приступить к со" зданию пользовательских баз данных. Рекомендуем сразу подготовить командный файл, создающий все пользовательские базы данных, существующие на момент установки сервера. Подобный файл зна" чительно ускорит восстановление сервера, а также перенос отдельных баз данных на другой сервер. Записать дамп базы данных master После создания пользовательских баз данных следует еще раз сохранить дамп базы данных master. Ре" гулярно повторяйте эту операцию в будущем, особенно после создания каждой новой пользователь" ской базы данных.

www.books-shop.com

Сохранить ленточные дампы файловых систем Запишите на ленту дампы файловых систем, содержащих протоколы установки, дампы баз данных и командные файлы, созданные в процессе установки сервера. При копировании командных файлов записи дампов файловых систем не забудьте внести в них поправки, связанные с различиями в кон" фигурации дисковых и ленточных устройств разных серверных машин. Создать командные файлы для эксплуатационной копии сервера Установите все командные файлы, используемые в процессе эксплуатации сервера для регулярного сохранения дампов баз данных и журналов транзакций, для выполнения dbcc"проверок и для обнов" ления статистики оптимизатора запросов командой update statistics (см. главу 14). Ошибки в процессе установки сервера В процессе установки сервера программой sybinit (sybconfig в случае SQL Server версии 4.9.2) не" редко возникают самые разнообразные проблемы. При этом, как правило, можно переключиться в другое окно или параллельный сеанс работы, устранить проблему, о которой сообщила программа sybinit, после чего продолжить процесс установки сервера. Ниже рассматриваются некоторые проблемы, наиболее часто возникающие во время установки SQL Server: Недостаточные права доступа к файлам Неправильное значение $SYBASE Недостаточные права доступа к файлам устройств Сервер не запускается Выдача сообщений в журналы регистрации ошибок Недостаточные права доступа к файлам Наиболее распространенной ошибкой при установке сервера является неправильное задание прав доступа к файлам. В процессе своей работы программа sybinit должна прочитать и создать множе" ство файлов, находящихся в разных каталогах серверной машины, а также выполнить необходимые действия со всеми разделами дисков, на которых создаются серверные устройства (master и другие). При отсутствии у UNIX"пользователя Sybase достаточных прав доступа хотя бы к одному из файлов, каталогов или устройств выполнение программы sybinit будет аварийно завершено с выдачей сооб" щения об ошибке на экран терминала sybinit, в файл регистрации ошибок sybinit (название ко" торого появляется на экране в начале и конце сеанса работы с sybinit), а также в журнал регистрации ошибок сервера, уже запущенного в ходе сеанса установки. При возникновении ошибок еще раз убедитесь в том, что UNIX"пользователь Sybase имеет права доступа ко всем необходимым объектам. Этого проще всего добиться путем установки принадлежно" сти пользователю Sybase всех файлов в инсталляционной директории /home/Sybase и ее подката" логах, а также всех специальных файлов управления небуферизованным доступом к разделам дисков, назначаемым серверным устройствам master, sysprocsdev и sybsecurity. Неправильное значение $SYBASE Неправильное значение переменной SYBASE приведет к прекращению процесса установки сервера на самых ранних стадиях. Убедитесь в том, что переменная SYBASE действительно содержит полное имя инсталляционной директории (/home/sybase). Отметим, что программа sybinit (но не syb" conf ig) специально запрашивает у пользователя название каталога установки (release directory), сов" падающее с инсталляционной (и базовой) директорией программных продуктов Sybase. Недостаточные права доступа к файлам устройств Проблема доступа к специальным файлам устройств встречается настолько часто, что следует еще раз обратить на нее внимание. Перед установкой сервера абсолютно необходимо указать принадлеж" ность UNIX"пользователю Sybase всех специальных файлов управления небуферизованным доступом к разделам дисков, назначаемым серверным устройствам master, sysprocsdev и sybsecurity. Отсутствие необходимых прав доступа к этим устройствам приводит к выдаче невразумительных сообщений об ошибках типа "недостаточно места на устройстве" (insufficient space on device). При появлении ошибок подобного рода уточните указанные программе sybinit названия устройств и последовательно проверьте принадлежность каждого из них. 24—2221

www.books-shop.com

Сервер не запускается Если сервер не запускается в процессе установки (либо уже после завершения работы программы sy" binit), то прежде всего необходимо убедиться в отсутствии проблем с правами доступа к различным объектам серверной машины. Однако причиной могут быть любые другие проблемы, исключающие нормальный запуск сервера, например недостаток памяти, сбои на дисках, выход из строя локальной сети и т.д. Постарайтесь проанализировать журнал регистрации ошибок сервера и определить харак" тер проблемы. В подобной ситуации не следует надеяться на содействие со стороны программы sy" binit, поскольку та ограничивается выдачей сообщения "ожидаю завершения загрузки сервера" (waiting for server to boot) и терпеливо ждет несостоявшегося запуска сервера. Если даже после анали" за журнала регистрации ошибок ситуация продолжает оставаться неясной, уничтожьте системный процесс установки сервера (т.е. программу sybinit) и попытайтесь вручную запустить сервер с по" мощью командного файла RUN_<имя_сервера>, к этому моменту уже созданного программой уста" новки. Подобный шаг позволит вам сосредоточиться на поиске проблем с сервером без многократного повторения процесса его установки. Когда причина будет найдена и устранена, оста" новите запустившийся сервер и повторите его установку. Необходимо уверенно ориентироваться в сообщениях, выдаваемых сервером в журнал регистра" ции ошибок (см. главу 12). Вне зависимости от того, в какой момент установки сервер отказался за" грузиться, вашим главным источником информации является именно журнал регистрации ошибок сервера. После успешного завершения процесса установки сервера обязательно загляните в его журнал регистрации ошибок и убедитесь, что вы установили именно ту версию SQL Server, которую намере" вались. Поскольку программа установки автоматически запускает выполняемый модуль сервера, за" груженный с магнитной ленты дистрибутива сервера, скорее всего вы действительно получите требуемую версию. Однако в процессе последующей эксплуатации сервера в директории /home/sy" base/bin могут появиться выполняемые модули различных версий сервера, отличающихся уров" нем EBF и т.п. В некоторых случаях "незапуск" сервера связан именно с попыткой вызова одной из предыдущих его версий. Выдача сообщений в журналы регистрации ошибок В процессе работы с программой sybinit на диске создается несколько различных файлов регистра" ции ошибок, каждый из которых может содержать важную информацию о причинах возникших проблем. Во"первых отметим, что программа sybinit выдает различные сообщения непосредствен" но на экран терминала, с которого она была запущена. Во"вторых, эта программа создает свой собст" венный файл регистрации ошибок, название которого выводится на экран в начале и конце каждого сеанса работы с sybinit. В третьих, не следует забывать и о журнале регистрации ошибок сервера, в процессе установки создающегося в одном из подкаталогов инсталляционной директории ($SYBASE/install). Наконец, при необходимости не забудьте просмотреть системный журнал сер" верной машины, в который заносятся сообщения о сбоях в работе системы и ее аппаратного обеспе" чения.

Обновление SQL Server: общий обзор Введение Обновление SQL Server представляет собой обычную повседневную операцию, выполняемую на трех различных уровнях. Простейшей формой обновления сервера является внесение в его программные модули очередного EBF"исправления (Emergency Bug Fix — экстренное исправление выявленных ошибок; поскольку сегодня очередные EBF"исправления выпускаются регулярно, слово "экстренный" можно считать устаревшим). Одновременное исправление целого ряда ошибок, найденных за опре" деленный интервал времени, осуществляется в результате так называемого "наката" (rollup) сервера. Значительно реже производится полное обновление сервера — при переходе на новую версию. Обыч" но этот процесс включает в себя внесение изменений в структуру существующих баз данных, что при" водит к несовместимости этих баз данных с прежней версией сервера. Особенности различных версий SQL Server SQL Server 4.9.2 При обсуждении различных процедур обновления сервера предполагается, что у вас уже имеется ра" ботоспособный SQL Server версии 4.9.2. Если же вы продолжаете эксплуатировать SQL Server одной

www.books-shop.com

из более ранних версий, обратитесь в службу технической поддержки Sybase, поскольку переход на SQL Server System 10 и 11 возможен только с SQL Server версии 4.9.2. SQL Server System 10 SQL Server System 10 работает как в системе SunOS, так и в Solaris, поэтому переход на System 10 не требует переустановки операционной системы. В процессе перехода необходимо разрешить возмож" ные конфликты с зарезервированными словами, а также создать дополнительные серверные устрой" ства для новых баз данных sybsystemprocs и sybsecurity. Кроме того, в составе System 10 появился отдельный сервер архивации Backup Server, что существенно отразилось на процедурах создания дампов баз данных и журналов транзакций. SQL Server System 11 Переход к SQL Server System 11 от SQL Server версии 4.9.2 включает в себя все этапы перехода к сер" веру System 10. Поскольку сервер System 11 требует (и способен продуктивно использовать) больший объем оперативной памяти, при переходе на эту версию, возможно, придется установить дополните" льную память в серверную машину. Кроме того, SQL Server System 11 работает только в операцион" ной системе Solaris, поэтому серверные машины, функционировавшие под управлением SunOS, необходимо предварительно перевести на систему Solaris. Руководство по установке, перечень особенностей текущей версии сервера и сопроводительное письмо к очередной EBF*версии При установке очередной EBF"версии SQL Server необходимо иметь под рукой соответствующую до" кументацию, в том числе руководство по установке сервера (Sybase SQL Server Installation Guide) и описание особенностей текущей версии сервера (Release Notes). Перечень исправленных ошибок и ряд рекомендаций относительно процесса установки EBF"версии сервера даются в сопроводитель" ном письме (EBF Cover Letter), распространяемом вместе с носителем дистрибутива EBF"версии. Процесс перехода на новую главную версию сервера (например, с SQL Server 4.9.2 на System 11) подробно описывается в специально переработанном для новой версии сервера руководстве по установке сервера (либо в бюллетене особенностей нового релиза сервера Release Bulletin). Перед тем как приступить к переходу на новую версию, необходимо ознакомиться с этими документами, поскольку ошибки, допущенные во время установки новой версии сервера, могут привести к серьез" ным последствиям. Служба технической поддержки компании Sybase Перед установкой очередной EBF"версии или перед более значительным обновлением сервера опре" делите уровень EBF вашего текущего сервера. Для этого проще всего подключиться к серверу с помо" щью программы isql и выполнить команду select @@version В ее выдаче следует обратить внимание не только на номер версии сервера (например, 4.9.2), но и на номер текущего EBF"уровня сервера. Определив версию сервера и его EBF"уровень, обратитесь в службу технической поддержки Syba" se и узнайте, какие исправления ошибок (и, не исключено, дополнительные возможности) были вне" сены в установленную у вас EBF"версию. Кроме того, сообщите номер EBF"версии, на которую вы намереваетесь перейти, и уточните ее совместимость с текущей EBF"версией. Особенно важна консультация со службой технической поддержки Sybase, если вы работаете с "однократной" (one"off) EBF"версией, индивидуально подготовленной Sybase для исправления ряда необычных ошибок, с которыми сталкивалась только ваша компания. Эти исправления могут оказа" ться несовместимыми с очередными общими EBF"версиями, в особенности, если новая EBF"версия осуществляет "накат" (rollup) сервера с одновременным внесением целого набора изменений. Необ" ходимые вам индивидуальные исправления, возможно, не внесены в этот набор, и единственным способом предварительной проверки подобного факта является обращение в службу поддержки Sy" base с просьбой сопоставить текущую и новую EBF"версии SQL Server. Специально уточните в службе технической поддержки, относится ли ваша текущая EBF"версия сервера к основной последовательности версий, эксплуатируемых большинством клиентов Sybase. На" личие в вашей версии индивидуальных исправлений, не включенных в основное семейство версий сервера, порождает проблемы двоякого рода. Во"первых, переход на новую EBF"версию может

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

привести к утрате исправлений, внесенных в прежнюю индивидуальную версию сервера (подобная ситуация называется регрессией). Во"вторых, дополнительные изменения, внесенные в новую EBF"версию, могут оказаться не проверенными на совместимость с исправлениями редко встречаю" щихся ошибок, сделанными при выпуске вашей индивидуальной EBF"версии. В результате переход на новую EBF"версию приведет лишь к заметному ухудшению ситуации из"за появления новых оши" бок. Возможные риски при переходе на новую версию Перед любым обновлением сервера постарайтесь четко сформулировать, с какой конкретной целью вы устанавливаете новую версию и что намерены предпринять в случае возникновения проблем. При неудачной установке очередных EBF"версий, как правило, можно вернуться к прежней EBF"версии пу" тем ее повторной установки в качестве очередной EBF"версии. К.сожалению, это редко удается сде" лать после перехода на новую главную версию сервера, поэтому здесь требуется разработать план восстановления нормальной работоспособности сервера предыдущей главной версии. Даже при нор" мальном обновлении сервера несовместимость различных исправлений, внесенных в новую EBF"вер" сию, может привести к нарушению структур баз данных вашего сервера, что не удастся исправить возвратом к прежней EBF"версии. Вероятность возникновения проблем значительно возрастает при переходе на новую главную версию SQL Server (например, с версии 4.9.2 на System 10 или 11). Если обновление сервера закан" чивается неудачей, то вы можете оказаться в состоянии, когда все базы данных прежнего сервера уже преобразованы в формат System 10, но сам сервер System 10 еще не установлен, и восстанавли" вать прежний SQL Server 4.9.2 бессмысленно из"за его несовместимости с новым форматом баз дан" ных. Перед обновлением сервера обсудите все возможные затруднения со службой технической поддержки Sybase и определите последовательность действий в случае преждевременного заверше" ния процесса установки новой версии SQL Server. Обновление EBF*версии Процесс перехода на новую EBF"версию SQL Server несложен и выполняется довольно часто. Поэто" му возникает необходимость в его максимальной стандартизации, которая позволит обновить EBF"версию любому дежурному администратору базы данных, а также упростит, ускорит и сделает бо" лее безопасным возврат к предыдущей EBF"версии в случае необходимости. Кроме того, единый про" цесс установки EBF"версий существенно облегчит стандартизацию сопровождения всех серверов информационной системы. Документация Выше уже говорилось о необходимости ознакомиться с перечнем особенностей устанавливаемой вер" сии (Release Notes) либо с сопроводительным письмом к ней (EBF Cover Letter). В этих документах со" держится описание внесенных изменений и особенностей процесса установки новой версии. Кроме того, полезно еще раз просмотреть руководство по установке сервера и убедиться во внесении всех необходимых заплаток в операционную систему серверной машины и в правильности конфигурации ее аппаратных средств. Загрузка новой EBF*версии Новая EBF"версия SQL Server загружается с магнитной ленты либо с другой серверной машины непо" средственно в стандартный каталог, содержащий двоичные выполняемые модули сервера (напри" мер, /home/sybase/bin). Каждой очередной EBF"версии должно быть присвоено стандартное название, облегчающее ее идентификацию. Рекомендуем придерживаться схемы <имя_серве ра>. <номep_вepсии>datasvr. <уровень_ЕВF> с предварительным преобразованием имени сер" вера к строчным буквам, например ddsdbal.1101datasvr. 6158. Проверить текущую версию и EBF*уровень сервера Для проверки номера версии и EBF"уровня вашего сервера перед его обновлением подключитесь к серверу с помощью isql и введите команду select ©©version Выдача этой команды выглядит следующим образом: machinel: isql #Usa #SREARWINDOWll Password:

www.books-shop.com

1> select @@version 2> go SQL Server/11.0.l/P/Sun_svr4/OS 5.4/EBF6158/OPT/Fri Apr 5 20:30:14 PST 1996

(1 row affected) Таким образом, в нашем распоряжении SQL Server версии 11.0.1, имеющий EBF"уровень 6158. Если выданный EBF"уровень (и тем более номер версии) отличается от ожидаемого, следует внима" тельно проанализировать текущее состояние системы. Никогда не приступайте к обновлению серве" ра при отсутствии полной уверенности в том, что установка новой EBF"версии не нарушит нормального функционирования сервера. Перед установкой новой EBF"версии выясните, почему EBF"уровень сервера (и тем более его версия) не соответствует предполагаемому, а затем приведите сервер к состоянию, в котором он должен был находиться. Заархивировать текущую версию выполняемого модуля сервера Определив действительную версию и EBF"уровень сервера, скопируйте его двоичный выполняемый файл в файл с именем, отражающим номер версии и EBF"уровня. Как правило, SQL Server запускается командным файлом с полным именем /home/Sybase/install/RUN_<имя_сервера>, который вы" зывает двоичный выполняемый файл сервера с именем dataserver. Именно файл dataserver и должен быть скопирован в файл с именем <имя_сервера>. <номер_версии>datasrvr.<уровень_ЕВF> (на" пример, ddsdbal.1101datasvr .3434). Имя сервера рекомендуется предварительно преобразовать к строчным буквам. Созданная резервная копия выполняемого модуля прежнего сервера может по" требоваться в дальнейшем. Отметим, что при соблюдении рассматриваемой в этой главе стандарт" ной процедуры обновления EBF"версии SQL Server резервный файл текущей EBF"версии сервера уже был создан в процессе ее установки, и в повторном создании этого файла нет необходимости. Остановить сервер Теперь нужно остановить сервер. Как и при любом плановом останове сервера, выполните все приве" денные в главе 9 рекомендации, чтобы привести базы данных и сам сервер в стабильное состояние. Скопировать новую EBF*версию в каталог выполняемых модулей сервера После останова сервера скопируйте новый выполняемый модуль сервера в файл с именем <имя_сервера>. <номер_версии>datasvr.<новый_уровень_ЕВF>, например ddsdbal.1101p2da" tasvr .6158 (имя сервера следует привести к строчным буквам). Собственно говоря, весь переход на новую EBF"версию сводится к помещению этого файла в один каталог с другими выполняемыми моду" лями сервера и к его копированию в файл с именем dataserver. Следующий вызов командного файла RUN_<имя_сервера> приведет к автоматическому запуску новой EBF"версии. Процесс смены EBF"версии SQL Server действительно очень прост и сводится к выполнению не" скольких команд системы UNIX. Здесь не требуется вручную редактировать какие"либо файлы, что заметно облегчает выполнение этой операции во внеурочные часы с удаленного терминала (напри" мер, из дома). Перезапустить сервер После перезапуска сервера просмотрите журнал регистрации ошибок и убедитесь, что запущенный сервер действительно имеет требуемый EBF"уровень. Состав информации, выдаваемой в журнал ре" гистрации ошибок при запуске сервера, подробно рассмотрен в главе 12. Проверить EBF*уровень сервера После полного восстановления работоспособности сервера подключитесь к нему с помощью isql и проверьте фактический EBF"уровень командой select ©©version. Внести новый EBF*уровень в текущую документацию Отразите переход на новую EBF"версию сервера в эксплуатационной документации, чтобы поставить в известность остальных администраторов баз данных об обновлении сервера. Переход на новую главную версию SQL Server В отличие от обновления EBF"уровня сервера, переход на новую главную версию SQL Server не удает" ся осуществить простым перезапуском сервера с новым выполняемым модулем. Как правило, после установки новой версии сервера, возврат к прежнему серверу представляет собой весьма громоздкую

www.books-shop.com

операцию, поскольку в процессе подобного перехода (например, от версии 4.2 к SQL Server 4.8 или от сервера 4.9 к System 10) модифицируется структура баз данных, что исключает загрузку прежних дампов в обновленный сервер. Кроме того, переход на новую версию сервера может потребовать пе" реработки существующих приложений. Любые изменения в синтаксисе поддерживаемой версии язы" ка SQL или приведение возможностей сервера в соответствие с очередным ANSI"стандартом нередко самым печальным образом отражаются на работоспособности используемых приложений. Единст" венным надежным способом проверки совместимости приложений с новой версией сервера являет" ся пробная эксплуатация нового сервера. Преждевременное завершение процесса перехода на новую версию может серьезно отразиться на работоспособности информационной системы. Будьте заранее готовы немедленно приступить к восстановлению прежней версии сервера. Кроме того, не забывайте, что дампы баз данных нового сервера не могут быть прочитаны прежними версиями сервера, поэтому обновление основного OLTP"сервера системы без одновременного обновления сервера подготовки отчетов приведет к по" тере синхронизации баз данных основного и вспомогательного серверов. Необходимость в перио" дической загрузке старых дампов данных для извлечения из них информации об отдельных объектах баз данных требует поддержания на одной из серверных машин системы работоспособной копии прежней версии сервера в течение длительного периода времени. Таким образом, переход на новую версию сервера требует заблаговременного планирования всех необходимых операций, включая тестирование нового сервера перед его запуском в промышленную эксплуатацию. В последующих разделах главы описывается переход с SQL Server 4.9.2 на сервер System 11 (или System 10). Подготовка перехода с SQL Server 4.9.2 на System 11 (либо System 10) Рассмотренную ниже последовательность действий необходимо выполнить перед обновлением серве" ра 4.9.2. Некоторые операции призваны исключить возможность возникновения осложнений в про" цессе обновления сервера, и их следует выполнить заблаговременно. К таким операциям относится предварительная проверка готовности сервера к обновлению с обязательным последующим восстанов" лением исходных режимов работы баз данных, что позволит продолжить нормальную обработку запро" сов во время анализа результатов необходимых предварительных проверок. Однако ряд других подготовительных операций, например отмену зеркального резервирования серверных устройств, сле" дует осуществлять непосредственно перед началом действительного обновления сервера. Зеркальные копии серверных устройств играют важную роль в процессе перехода на новую вер" сию сервера, поскольку обеспечивают быстрый возврат к прежнему серверу 4.9.2 в случае возникно" вения проблем с установкой сервера System 11. Подчеркнем, что быстрое восстановление прежних версий баз данных возможно только при наличии их полных зеркальных копий перед обновлением сервера. Все остальные базы данных придется удалить, создать заново и загрузить из дампов. Пол" ное зеркальное резервирование всех серверных устройств желательно в силу целого ряда причин, и одной из основных является возможность быстрого возврата к прежней версии сервера. Установить режимы работы баз данных по умолчанию При проведении предварительных проверок сервера ни одна из баз данных обновляемого сервера не может работать в режиме, отличном от устанавливаемого по умолчанию (другими словами, столбец "options set" в выдаче команды sp_helpdb должен быть пуст). Единственным исключением является база данных tempdb, которую следует оставить в режиме select into/bulkcopy. Выполнить предварительную проверку баз данных программой sybinit Для предварительной проверки конфигурации баз данных SQL Server 4.9.2 пользователю Sybase следу" ет запустить программу sybinit (но не sybconf ig!) и выбрать режим обновления существующего SQL Server (Upgrade an existing SQL Server), а затем — операцию проверки готовности сервера к об" новлению (Test SQL Server upgrade eligibility now). Фрагмент протокола сеанса работы с программой sybinit: SQL SERVER UPGRADE

1. Test SQL Server upgrade eligibility now 2. Check for reserved word conflicts 3. sybsystemprocs database configuration 4 . Upgrade SQL Server now

www.books-shop.com

(...) Ctrl#a Accept and Continue, Ctrl#x Exit Screen, ? Help. Enter the number of your choice and press return: 1 (Введите номер выбранной вами операции и нажмите return:) Testing SQL Server "THEBIRDS492 ' for eligi# bility to upgrade to release '11.0'. ......................... Done Server "THEBIRDS492 ' passed preupgrade eligibility test.

Выполнить предварительную проверку программой sybinit использования зарезервированных слов Для проверки использования зарезервированных слов в объектах обновляемого сервера версии 4.9.2 на предмет возможных конфликтов с зарезервированными словами System 11 также следует восполь зоваться программой sybinit, запускаемой UNIXпользователем Sybase. После запуска sybinit сно ва выберите режим обновления существующего сервера (Upgrade an existing SQL Server), а затем — проверку конфликтов зарезервированных слов (Check for reserved word conflicts). Распечатка соот ветствующего сеанса работы представлена ниже. Протокол проверки конфликтов зарезервированных слов программой sybinit Приведенная ниже распечатка фрагмента сеанса работы с программой sybinit показывает ход про цесса проверки конфликтов зарезервированных слов и, аналогично предыдущей распечатке, начина ется с меню "ОБНОВЛЕНИЕ SQL SERVER" (SQL SERVER UPGRADE). Обратите внимание на то, что файлы дистрибутива SQL Server System 11 находятся в каталоге /home/sybase/11 . 0, в то время как все файлы обновляемого сервера версии 4.9.2 остаются в обычной инсталляционной (базовой) ди ректории Sybase с именем /home /Sybase. SQL SERVER UPGRADE 1. Test SQL Server upgrade eligibility now 2. Check for reserved word conflicts 3 . sybsystemprocs database configuration 4 . Upgrade SQL Server now

(...) Ctrl#a Accept and Continue, Ctrl#x Exit Screen, ? Help. Enter the number of your choice and press return: 2 (Введите номер выбранной вами операции и нажмите return:) ...Done The log file for sp_checkreswords output is ' /home/sybase/11. 0/init/logs/checkres.dmp' . Warning: 2 conflicts with 11.0 reserved words were found. Sybase suggests that you resolve these conflicts before upgrading the SQL Server. Run ' sp_checkreswords ' on each database for more information. Press to continue . (Внимание. Обнаружены 2 конфликта с зарезервированными словами версии 11.0, которые рекомендуется разрешить до начала обновления сервера. Для получения дополнительной информации запустите ' sp_checkreswords ' для каждой базы данных по отдельности. Для продолжения работы нажмите .) Файл /home/sybase/ 11. 0/init/logs/checkres.dmp содержит следующую информацию о конфликтах зарезервированных слов: machinel: more checkres .dmp Reserved Words Used as Database Objects for Database 'admindb' Database#wide Objects Reserved Words Used as Database Objects for Database 'cms_map' Database#wide Objects

Reserved Words Used as Database Objects for Database 'cmsdb' Owner dbo

www.books-shop.com

Object Type user table Database#wide Objects

Reserved Word Object Names references

Reserved Words Used as Database Objects for Database 'curqtr_db' Owner dbo

Object Type user table Database"wide Objects

Reserved Word Object Names references

Reserved Words Used as Database Objects for Database 'master' Database"wide Objects Reserved Words Used as Database Objects for Database 'model' Database"wide Objects Reserved Words Used as Database Objects for Database 'pagedb' Database"wide Objects Reserved Words Used as Database Objects for Database 'guedb' Database"wide Objects Reserved Words Used as Database Objects for Database 'suneds_sunu' Database"wide Objects Reserved Words Used as Database Objects for Database 'tempdb' Database"wide Objects Приведенный в распечатке перечень обнаруженных названий объектов баз данных, которые конфликтуют со списком зарезервированных слов SQL Server System 11 и поэтому не могут быть ис" пользованы в командах Transact"SQL, а также в других аналогичных ситуациях, не совсем полон. В системной таблице sysobjects каждой базы данных SQL Server 4.9.2 обязательно имеется столбец с названием schema, которое является зарезервированным словом SQL Server System 11. Однако при обновлении сервера оно автоматически заменяется на schema2 (в этом можно убедиться путем срав" нения тех мест в документации серверов 4.9.2 и System 11, где речь идет о таблице sysobjects). Наличие конфликтов зарезервированных слов само по себе не препятствует переводу сервера на версию System 11, и процесс установки новой версии можно успешно завершить без изменения кон" фликтующих названий объектов баз данных (таблиц, столбцов данных и т.п.). Однако при любой по" пытке обращения к этим объектам данных сервер System 11 выдаст сообщение об ошибке. В этом случае можно воспользоваться специальным режимом работы сервера System 11 (включаемым командой set quoted_identifier on), позволяющим использовать зарезервированные слова при условии их включения в двойные кавычки. Таким образом, конфликты зарезервированных слов не препятствуют нормальному ходу обновления сервера, но в будущем могут потребовать модифика" ции запросов и приложений. При анализе каждого конфликтующего зарезервированного слова следует определить, насколько часто оно используется в других объектах, и как можно скорее внести необходимые изменения во все эти объекты. Если объекты, затронутые конфликтом зарезервированных слов, представляют особую важность для деятельности вашей компании, то обновление сервера следует отложить до разрешения конфликтов или до перехода на использование двойных кавычек. Именно поэтому ре" комендуется выполнить все предварительные проверки заблаговременно. Из приведенной выше распечатки видно, что в базах данных cmsdb и curqtr_db пользователями были созданы таблицы с названием references, которое относится к числу зарезервированных слов SQL Server System 11. Вам необходимо определить, насколько серьезно отразится на работе прило" жений невозможность обращения к указанным объектам данных, и внести необходимые изменения во все связанные с ними объекты сервера.

www.books-shop.com

Конфликт зарезервированных слов во многих случаях приводит к очистке содержимого конфликтующих объектов, если они не принадлежат администратору сервера (пользова+ телю 'sa'). Поэтому при обнаружении конфликтов в пользовательских объектах данных сообщите их владельцам о невозможности использования этих объектов после обновле+ ния сервера. Скорее всего это послужит должным стимулом для немедленного пере+ смотра конфликтующих названий объектов. Перед обновлением сервера можете смело удалять конфликтующие объекты всех пользователей, не прислушавшихся к вашему пре+ достережению. Восстановить исходные режимы работы баз данных Поскольку все предварительные проверки сервера должны производиться задолго до начала его об" новления, по окончании проверок следует немедленно восстановить прежние режимы работы баз данных, отмененные на время проведения проверок. Здесь можно еще раз убедиться в преимущест" вах регулярного сохранения дампов системных таблиц, поскольку состав используемых режимов ра" боты баз данных содержится в одной из подобных распечаток. Освободить место для новых серверных устройств System 11 SQL Server System 11 требует наличия дополнительного серверного устройства sysprocsdev для разме" щения новой системной базы данных sybsystemprocs, содержащей системные хранимые процедуры сер" вера System 11. Кроме того, при установке имеющихся в составе System 11 средств аудита работы сервера вам потребуется еще одно серверное устройство sybsecurity для одноименной базы данных. Хотя обе новые системные базы данных можно разместить на любом серверном устройстве, лучше расположить их на индивидуальных серверных устройствах (их минимальный размер — 30 Мбайт), специально созданных для этой цели. Крайне нежелательно помещать эти базы данных на серверное устройство master из"за неизбежного увеличения его размеров, значительно усложняющего процесс восстановления сервера. Каждое из дополнительных серверных устройств, поддерживающих новые системные базы данных, должно иметь зеркальную копию (более подробно структура дисковых раз" делов, требующихся для сервера System 11, рассмотрена в главе 8). Перед обновлением сервера подго" товьте необходимые дисковые разделы. Поскольку их инициализация производится программой sybinit непосредственно в процессе установки сервера, следует заранее удалить прежние сервер" ные устройства (а также их зеркальные копии), занимавшие выбранные разделы. Отсутствие в системе подходящих 30+мегабайтовых дисковых разделов означает, что вы решили пренебречь необходимой процедурой предварительного планирования конфигу+ рации дискового пространства сервера. Подобная процедура направлена не столько на оценку общего объема дисков, сколько на создание оптимальной структуры их разделов, позволяющей разнести системные базы данных на разные диски и контроллеры. Отме+ тим, что предложенная в главе 8 стандартная схема разделов дисков позволяет легко разместить все серверные устройства, необходимые при установке SQL Server System 11. Проверить работоспособность зеркальных копий всех серверных устройств После удаления серверных устройств (и их зеркальных копий) из разделов, предназначенных для но" вых системных баз данных System 11, необходимо убедиться в существовании работоспособных зер" кальных копий всех оставшихся серверных устройств. Полное зеркальное резервирование серверных устройств не только облегчает возврат от System 11 к SQL Server 4.9.2, но и значительно упрощает процесс поддержания работоспособности сервера. Проверить разделы, назначаемые новым серверным устройствам System 11 Уточните размеры дополнительных дисковых разделов, инициализируемых программой sybinit, и убедитесь в принадлежности этих разделов UNIX"пользователю sybase. Проверить базы данных командой dbcc Перед обновлением сервера необходимо убедиться в правильности структур всех баз данных посред" ством выполнения полного набора dbcc"проверок.

www.books-shop.com

Определить размеры свободного пространства баз данных Переход на новую версию сервера приведет к изменению структуры компилируемых объектов баз данных (таких, как хранимые процедуры и триггеры) и к увеличению размеров каждого подобного объекта, что требует наличия в базе данных определенного свободного пространства (не менее 10% от всего объема базы данных). С помощью команды sp_spaceused определите свободное простран" ство, имеющееся в каждой базе данных, и при необходимости увеличьте его до 10% от размера базы данных. Это следует сделать даже, если при предварительной проверке баз данных программа sybi" nit сообщила о наличии в них достаточного свободного пространства. Проверить соответствие таблиц sysindexes и sysobjects Два приведенных ниже запроса следует выполнить во всех базах данных обновляемого сервера. Если какой"либо из запросов завершится с непустым результатом, то в соответствующей базе данных име" ется объект, не отраженный должным образом в таблице sysindexes, либо индекс, не указанный в таб" лице sysobjects. Важно подчеркнуть, что команда dbcc далеко не всегда сообщает о проблемах подобного рода, которые могут привести к преждевременному завершению процесса обновления сервера. При наличии в вашем сервере несоответствия таблиц sysindexes и sysobjects обратитесь в служ" бу технической поддержки Sybase за рекомендациями по надлежащим способам удаления некоррект" ных объектов или записей таблицы sysindexes. Указанные запросы имеют следующий вид:

select id from sysobjects where (type >> 'U' or type << 'S') and id not in (select id from sysindexes) select id from sysindexes where id not in (select id from sysobjects) Записать дампы журналов транзакций всех баз данных сервера и создать контрольные точки Перед обновлением сервера сохраните дампы журналов транзакций всех баз данных и выполните в каждой базе данных команду checkpoint. Таким образом вы освободите в журналах транзакций до" статочно места, которое потребуется при обновлении, а также получите свежие копии журналов транзакций на случай восстановления сервера. При наличии в информационной системе резервного сервера с копиями обновляемых баз данных заранее загрузите в этот сервер новые дампы журналов транзакций, что при необходимости сократит время переключения на резервный сервер. Обновление SQL Server 4.9.2 на System 11 (либо System 10) Теперь можно приступить к непосредственному выполнению процедуры обновления сервера, вклю" чающей в себя множество операций. Возможно, некоторые из этих операций покажутся излишними; однако они призваны защитить вас, ваших пользователей и данные вашего сервера от неполного за" вершения процесса обновления сервера, исключающего возврат к прежнему серверу версии 4.9.2. Пе" ред обновлением сервера внимательно ознакомьтесь со всеми перечисленными ниже операциями. Рассматриваемая ниже последовательность действий соответствует обновлению SQL Server 4.9.2 именно на сервер версии System 11. Перед выполнением этого процесса рекомендуем обсудить со службой технической поддержки Sybase все особенности аппаратной конфигурации серверной ма" шины, ее программного обеспечения, используемой конфигурации сервера и его EBF"версии. Изолировать сервер от пользователей Перед обновлением сервер обязательно должен быть изолирован от пользователей. Для этого лучше всего полностью остановить сервер (разумеется, после заблаговременного оповещения пользовате" лей), затем перезапустить его с указанием другого номера порта серверной машины (в главе 12 описа" но изменение номера порта, указанного в файле интерфейсов). Подобная предосторожность позволит избежать случайного подключения кого"то из пользователей к серверу в процессе его об" новления. Главное — чтобы новый номер порта не был указан ни в одном пользовательском файле ин" терфейсов, и обновляемый сервер использовал индивидуальный файл интерфейсов. Обратите внимание на время, которое потребуется серверу для перезапуска с новым номером порта. Снова сохранить дампы журналов транзакций Повторно создайте полный комплект дампов журналов транзакций и выполните в каждой базе дан" ных команду checkpoint. Здесь мы сохраняем все транзакции, завершенные пользователями в

www.books-shop.com

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

Записать на ленту полные дампы баз данных С момента отключения сервера от пользователей проследите за тем, чтобы случайно не внести ка" ких"либо изменений в пользовательские базы данных. Сбросьте на ленту дампы всех баз данных, включая master и model Если вы все же предпочитаете записывать дампы на диск, то перед переходом к следующему этапу обязательно запишите на ленту полный дамп дисковых файлов с дампами баз дан" ных. Для большей гарантии сохранности данных попробуйте восстановить эти дампы на другом сер" вере. Возможно, вы сочтете подобный подход параноидальным и будете правы. Тем не менее попробуйте оценить стоимость потерь от невозможности восстановления баз данных сервера на мо" мент начала его обновления, а также потери информации, полученной после сохранения предыдуще" го полного комплекта дампов баз данных. Сохранить конфигурацию сервера С помощью рассматриваемого в главе 14 командного файла dump_systables запишите на диск дамп содержимого системных таблиц. Здесь проще всего вручную запустить стандартный командный файл, используемый в качестве cron"задания для регулярного сохранения дампов этих таблиц. Убеди" тесь в том, что полученный файл действительно содержит только что созданные дампы системных таблиц. Кроме того, сохраните выдачу команды sp_helpdb для каждой базы данных сервера. Для этого достаточно подключиться к серверу с помощью программы isql и выполнить последователь" ность команд вида use dbl и sp_helpdb dbl, сохранив копию выдачи в дисковом файле. Сохранить учетные записи пользователей С помощью утилиты Ьср запишите в дисковый файл все содержимое таблицы syslogins на случай не" обходимости последующего восстановления сервера или нарушения структуры учетных записей при обновлении сервера. В частности, полученный файл позволит определить идентификатор suid, сис" темное имя, пароль и используемую по умолчанию базу данных каждого пользователя SQL Server 4.9.2. Поскольку перед загрузкой этого файла в новый сервер необходимо будет вручную удалить из файла описание пользователей 'sa' и 'probe', при создании файла обязательно вызывайте утилиту bср с па" раметром "с.

Сохранить дамп базы данных master с зеркальным отображением серверных устройств Запишите на диск дамп базы данных master. Поскольку мы все еще имеем дело с сервером версии 4.9.2, этот дамп придется сначала сбросить на дисковое устройство вывода дампов, а затем переименовать, чтобы исключить его случайную перезапись при сохранении последующих дампов. Рекомендуем дать этому дампу имя dump_<имя_cepвepa>_master_4.9.2_withmirrors_<датa>_<вpeмя>. out, явно указывающее на наличие в дампе таблицы sysdevices с полным описанием зеркальных копий сервер ных устройств. Проверить состояние зеркальных копий серверных устройств Убедитесь в нормальном функционировании всех зеркальных копий серверных устройств на момент сохранения дампа базы данных master, созданного на предыдущем этапе. Сохраните выдачу командно" го файла p_mirror (см. главу 14) с полным описанием структуры зеркалирования серверных устройств. Удалить вторичные устройства зеркальных пар Для каждого серверного устройства, имеющего зеркальную копию, выполните следующую команду: disk unmirror name = '<название_устройства>', side = secondary,

www.books-shop.com

mode = remove Это приведет к полному удалению зеркальных копий всех серверных устройств. Значение подоб" ной процедуры подробно рассмотрено в главе 8 (где неоднократно подчеркиваются разнообразные преимущества полного резервирования всех серверных устройств). Здесь лишь напомним, что и первичное, и вторичное устройства зеркальной пары содержат полный комплект данных в формате сервера версии 4.9.2. Для ускорения отмены зеркальных копий можно создать специальный коман" дный файл, содержащий требуемую последовательность команд disk unmirror. Убедиться в отмене всех зеркальных пар С помощью командного файла p_mirror убедитесь в полном отсутствии зеркальных копий устройств обновляемого сервера. Отключить все нестандартные режимы работы баз данных Переведите все базы данных в режимы работы, устанавливаемые по умолчанию. Оставьте для базы данных tempdb режим select into/bulkcopy. Установить пароль пользователя 'sа' в NULL Установите для пароля администратора сервера значение NULL. Проверить установленный пароль пользователя 'sа' Убедитесь в том, что пароль системного администратора действительно имеет значение NULL. Для этого подключитесь к серверу из программы isgl в качестве пользователя 'sa'. Проверить, что пользователь 'sa' по умолчанию подключается к базе данных master Убедитесь, что для системного администратора в качестве базы данных по умолчанию установлена база данных master. Сохранить дамп базы данных master без зеркальных копий серверных устройств Запишите на диск дамп базы данных master. Поскольку мы работаем с сервером версии 4.9.2, новый дамп базы данных master придется сначала сбросить на дисковое устройство вывода дампов, а затем присвоить ему имя dump_<имя_сервера>_master_4.9.2_пот1ггогз_<дата>_<время>.ои1;. Это имя явно отражает наличие в дампе таблицы sysdevices описания только первичных устройств ранее существовавших зеркальных копий (см. рис. 13.16). Увеличить значение параметра TIMEOUTCOUNT в командном файле обновления сервера ЕСЛИ при последнем перезапуске на восстановление сервера потребовалось значительное время (бо" лее 10 минут) даже при полном отсутствии пользователей, обязательно увеличьте значение парамет" ра TIMEOUTCOUNT в командном файле обновления сервера. За необходимыми подробностями обратитесь в службу технической поддержки компании Sybase. Установить конфигурацию сервера, оптимальную для его обновления Системный процесс обновления сервера займет значительную часть оперативной памяти сервер" ной машины, поэтому следует уменьшить количество сеансов пользователей (параметр user connec" tions) до 10, а размер стека (stack size) установить равным 286 720. Активизация указанных значений требует перезапуска сервера. Добавить в файл интерфейсов описание сервера <имя_сервера>_SYS11 Перед запуском процесса обновления сервера необходимо изменить имя сервера, чтобы подчерк" нуть, что он больше не является сервером версии 4.9.2. Помимо включения описания нового сервера в файл интерфейсов, внесите необходимые изменения и в командный файл RUN_<имя_сервера>. Перезапустить сервер Перезапустите сервер под именем <имя_cepeepa>_SYS11.

www.books-shop.com

Сохранить дамп базы данных master с новой конфигурацией сервера Здесь нужно еще раз записать на диск дамп базы данных master. Так как мы все еще имеем дело с серве" ром версии 4.9.2, новый дамп базы данных master придется сначала записать на дисковое устройство вывода дампов, а затем присвоить ему имя dump_<имя_сервера>_master_4 . 9 . 2_nomirrors_ne" wconfig_<дата>_<время>.оut. Отметим, что находящаяся в дампе таблица sysdevices содержит описания только первичных устройств ранее существовавших зеркальных копий, которые по"преж" нему включают в себя данные в формате сервера версии 4.9.2. Запустить программу sybinit и выбрать режим обновления сервера Запустите программу sybinit так же, как и при выполнении рассмотренных выше предварительных проверок сервера. Выполнить повторную проверку баз данных программой sybinit Повторите проверку годности баз данных для обновления программой sybinit, чтобы убедиться в отсутствии изменений с момента предыдущей проверки.

Выполнить программой sybinit повторную проверку использования зарезервированных слов Проверку использования зарезервированных слов необходимо повторить на тот случай, если с мо" мента предыдущей проверки были изменены названия каких"либо объектов сервера. Сравните выда" чу программы s y b i n i t с аналогичной выдачей при предыдущей проверке и определите, препятствуют ли вновь обнаруженные конфликты зарезервированных слов продолжению процесса обновления сервера. Указать конфигурацию серверного устройства для базы данных sybsystemprocs Приступая к фактическому обновлению сервера, сообщите программе sybinit параметры (полное имя специального системного файла и размер) дискового раздела, назначаемого устройству sysprocs" dev, а также размеры создаваемой базы данных sybsystemprocs. Обновить сервер В меню "ОБНОВЛЕНИЕ SQL SERVER" (SQL SERVER UPGRADE) программы sybinit выберите ре" жим "Приступить к обновлению SQL Server" (Upgrade SQL Server now) и дождитесь завершения этого процесса. Установить сервер архивации и средства аудита По завершении обновления SQL Server установите сервер архивации Backup Server и средства аудита System 11. Для этого можно перезапустить программу sybinit либо продолжить текущий сеанс рабо" ты с sybinit и перейти к меню "КОНФИГУРИРОВАНИЕ НОВОГО ИЛИ СУЩЕСТВУЮЩЕГО SQL SERVER" (NEW OR EXISTING SQL SERVER). Основные операции после перехода от SQL Server 4.9.2 к System 11 (или System 10) Записать дамп обновленной базы данных master Установить пароль пользователя 'sa' Восстановить режимы работы баз данных Восстановить конфигурацию сервера Восстановить прежнее имя сервера Активизировать пороги Создать роли для администраторов баз данных и пользователей Повторно записать дамп базы данных master Сохранить дампы всех баз данных Проверить эксплуатационные командные файлы сервера Восстановить прежние зеркальные пары

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Обновить статистику оптимизатора Открыть доступ пользователей Удалить и воссоздать необходимые объекты баз данных Записать дамп обновленной базы данных master Сразу после установки сервера архивации Backup Server сохраните на диске дамп базы данных master. При работе с SQL Server System 11 и с сервером архивации пользователь может непосредственно ука" зывать имя файла, в который следует записать дамп базы данных или журнала транзакций, т.е. боль" ше не требуется использовать серверные устройства вывода дампов (хотя они остаются доступными). Для облегчения возможного восстановления сервера дайте файлу с дампом базы данных master имя dump_<имя_cepвepa>_master_11x _<дата>_<время>.out. Напомним, что находящаяся в дампе таблица sysdevices содержит описания только первичных устройств ранее существовавших зеркаль" ных копий, и эти устройства теперь содержат данные в формате System 11. Установить пароль пользователя 'sа' По завершении обновления сервера немедленно восстановите прежний пароль системного админи" стратора (напомним, что перед обновлением сервера этот пароль был установлен в NULL). Посколь" ку SQL Server System 11 шифрует пароли пользователей, записываемые в системную таблицу syslogins, теперь соответствующие поля таблицы нельзя прочитать "невооруженным глазом" (и, в частности, проверить, что пользователь 'sa' действительно имеет пароль NULL). Если вы забыли пароль систем" ного администратора, действовавший до обновления сервера, попробуйте найти его в таблице syslo gins одного из серверов версии 4.9.2, остающихся в вашей информационной системе. Восстановить режимы работы баз данных Установите для всех баз данных режимы работы, использовавшиеся в прежнем сервере. Здесь вам снова понадобится ранее сохраненный дамп системных таблиц сервера (см. главу 14). Восстановить конфигурацию сервера Здесь требуется вернуть количество поддерживаемых пользовательских сеансов работы и размеры стека к прежним значениям (напомним, что перед установкой новой версии SQL Server этим парамет" рам были присвоены значения 10 и 286 720 соответственно). Одновременное изменение значений рассматриваемых параметров может оказаться невозможным, поскольку при перезапуске сервер сна" чала резервирует память для пользователей, а затем уменьшает размер стека. Если, например, необ" ходимо увеличить количество пользователей с 10 до 800, одновременно сократив стек с 286 720 до 40 960, то сервер перезапустится успешно лишь при наличии достаточной памяти для поддержки 800 пользователей при размере стека, равном 286 720. Поэтому рекомендуется сначала сократить раз" мер стека, перезапустить сервер для его загрузки с новым размером стека, проверить конфигурацию сервера и затем повторить эти действия для увеличения количества пользователей. Восстановить прежнее имя сервера В процессе обновления имя сервера было изменено на <имя_сервера>_SYS11, чтобы сделать невозмож" ным случайный запуск командных файлов, ориентированных на сервер версии 4.9.2 с прежним име" нем сервера. В процессе подготовки обновленного сервера к доступу пользователей нужно восстановить имя сервера в командном файле его запуска и в файле интерфейсов либо установить но" вое постоянное имя, если это необходимо для используемых приложений. Подчеркнем, что речь здесь не идет об изменении имени сервера, записанного в системной таблице sysservers (подробнее об этом "постоянном" имени рассказано в главе 12).

www.books-shop.com

Вы — единственный из всех администраторов баз данных, еще не получивший повыше+ ния. Путем длительных и настойчивых усилий вы наконец+то уговорили босса разрешить вам самостоятельно перевести один из основных серверов системы с версии 4.9.2 на System 10. Для оценки и контроля за вашими действиями руководство заставляет одного из старших администраторов баз данных прийти на работу в свободное время (которого у старших администраторов совсем немного). Вы смело приступаете к обновлению сер+ вера и... обнаруживаете, что новый сервер не работает. Запаниковав, вы срочно вызыва+ ете старшего администратора прямо с обеда. Бросив один взгляд на журнал регистрации ошибок "нового" сервера, тот немедленно обнаруживает, что вы пытаетесь запустить старый сервер 4.9.2 на устройстве master, уже обновленном под System 10. Что ж, вы действительно выглядите идиотом, в лучшем случае заслуживающим продол+ жительного ничегонеделания рядом с никому не нужным сервером, стоящим в другом здании. И не надо обижаться — внимательнее читайте журнал ошибок, когда с сервером что+то не в порядке. Активизировать пороги SQL Server System 11 позволяет определить пороги во всех базах данных. В частности, в каждой из них можно установить порог последнего уровня (last"chance threshold). При преобразовании баз дан" ных сервера 4.9.2 к формату System 11 пороги последнего уровня не устанавливаются автоматически, и их необходимо задать вручную путем выполнения команды select lct_admin ("lastchance", db_id ( ) ) в каждой обновленной базе данных. Основное назначение порогов последнего уровня — исключить переполнение журналов транзакций. Детальное описание работы порогов и ситуаций, когда в базах данных следует установить дополнительные пороги, представлено в документации Sybase. Здесь лишь отметим, что при срабатывании в одной из баз данных порога последнего уровня сервер по умолчанию приостанавливает все пользовательские транзакции, пытающиеся записать что"либо в журнал транзакций этой базы данных. Если в подобной ситуации желательно полное пре" кращение всех таких транзакций с выдачей сообщения об ошибке 1105 (переполнение сегмента — segment full), то с помощью процедуры sp_dboption установите для соответствующей базы данных режим работы abort tran on log full. Создать роли для администраторов баз данных и пользователей Пользовательские роли являются основой механизма распределения полномочий в System 11. Новая версия сервера позволяет назначить роль оператора сервера (oper_role) определенной группе по" льзователей, каждый из которых сможет записывать и загружать дампы баз данных без установки спе" циальных полномочий в каждой базе данных по отдельности, как это делалось в SQL Server 4.9.2 и в предшествующих версиях сервера. Нужно также определить, как именно будет осуществляться те" перь работа администратора сервера. С одной стороны, вы можете назначить роли sso_role и sa_role всем пользователям сервера, ранее входившим в него под именем 'sa', что позволит индиви" дуально контролировать действия каждого администратора. С другой стороны, на сервере могут оста" ваться командные файлы, жестко сконфигурированные для запуска исключительно пользователем 'sa'. При переработке этих файлов следует решить, как именно командный файл будет определять, под именем какого пользователя ему следует подключаться к серверу. Повторно записать дамп базы данных master Сейчас нужно еще раз записать на диск дамп базы данных master. Поскольку SQL Server System 11 и сервер архивации позволяют явно указывать имя файла для записи дампа базы данных или журнала транзакций, больше не требуется использовать серверные устройства вывода дампов (хотя они оста" ются доступными). Для облегчения поиска создаваемого дампа базы данных master дайте его файлу имя dump_<имя_cepвepa>_master_llx_oldconfig_<дата>_<время>.оut:. Сохранить дампы всех баз данных Снова сбросьте дампы всех баз данных сервера на магнитную ленту (либо сначала в дисковые файлы, а затем эти файлы — на ленту). Тем самым вы получаете первый полный комплект дампов, которым можно будет воспользоваться непосредственно из сервера System 11 (не способного читать старые дампы SQL Server 4.9.2). Проверить эксплуатационные командные файлы сервера По завершении обновления сервера на System 11 и перед открытием доступа пользователей к новому серверу следует убедиться в работоспособности всех командных файлов и cron"заданий прежнего

www.books-shop.com

сервера. При необходимости внесите в них изменения, учитывающие особенности System 11 (напри" мер, появление механизма пользовательских ролей или использование зашифрованных паролей). Восстановить прежние зеркальные пары С того момента, как перед обновлением сервер был изолирован от пользователей, в содержание основных баз данных не вносилось никаких изменений. Это позволяет быстро вернуться к прежнему серверу версии 4.9.2 с помощью сохраненных зеркальных копий устройств прежнего сервера либо дампов баз данных, сохраненных перед его обновлением. Перед открытием доступа пользователей к базам данных нового сервера необходимо окончательно убедиться в стабильной работе нового серве" ра System 11 со всеми существующими приложениями и в полной доступности прежних данных этим приложениям. Любой возврат к старому серверу после начала работы пользователей с сервером Sys" tem 11 будет означать утрату всех новых данных. Приняв окончательное решение о переходе на новый сервер, восстановите зеркальное отобра" жение устройств сервера System 11 на прежние разделы зеркальных копий этих устройств. Разумеет" ся, в этот момент теряются все прежние версии баз данных в формате сервера 4.9.2, находившиеся на зеркальных копиях устройств старого сервера. Обновить статистику оптимизатора С помощью рассматриваемого в главе 14 командного файла выполните команды update statis" tics и sp_recompile по отношению ко всем таблицам данных сервера. Открыть доступ пользователей Перезапустите новый сервер System 11 с прежним номером порта, указанным в клиентской версии файла интерфейсов (принципы использования интерфейсных файлов и порядок назначения номе" ров портов обсуждены в главе 12). В этот момент сервер становится доступным для пользователей, поскольку его имя и номер порта совпадают с именем и номером порта прежнего сервера, указанны" ми в файлах интерфейсов всех компьютеров"клиентов системы. Удалить и воссоздать необходимые объекты баз данных Из"за того что в SQL Server System 11 пересмотрена схема обработки вложенных запросов, при пере" ходе к этой версии сервера необходимо удалить все объекты баз данных, содержащие вложенные за" просы, а затем создать эти объекты заново. Рассматриваемую операцию следует обязательно выполнить для всех баз данных, перенесенных в сервер System 11 из SQL Server 4.9.2 и System 10. Пре" небрежение подобным требованием может привести к серьезному снижению производительности сервера, поскольку при обработке вложенных запросов будет использоваться прежняя схема их вы" полнения, созданная оптимизатором запросов старого сервера. В некоторых случаях применение в сервере System 11 схем выполнения запросов, выработанных оптимизатором прежних версий серве" ра, приводит к значительному увеличению времени обработки этих запросов. В процессе повторной компиляции объектов, выполняемой при их воссоздании, будут построены новые схемы выполнения запросов, учитывающие особенности сервера System 11. В комплект поставки SQL Server System 11 компания Sybase включила хранимую процедуру sp_procmode, определяющую, какие именно объекты баз данных должны быть удалены и созданы заново. Эта процедура должна быть выполнена в каждой базе данных сервера. Не всякий объект, на" звание которого сообщается процедурой sp_procqmode, в действительности содержит вложенные запросы. Тем не менее рекомендуем удалить и создать заново все объекты, выданные этой процеду" рой: 1> sp_procqmode 2> go

Object Owner.Name dbo.actions_trigger dbo.assignments_trigger dbo.attachments_trigger dbo.cover_hist_trigger dbo.customers_trigger dbo.labor_trigger

Object Type trigger trigger trigger trigger trigger trigger

Processing pre#System pre#System pre#System pre#System pre#System pre#System

dbo.parts_trigger

trigger

pre#System 11

dbo.reference_trigger dbo.service_order_trigger dbo.states_trigger

trigger trigger trigger

System 11 or later pre#System 11 pre#System 11

•

Mode 11 11 11 11 11 11

www.books-shop.com

dbo.action_status_proc dbo.cms_who dbo.sp_disks

stored procedure stored procedure stored procedure

pre#System 11 pre#System 11 pre#System 11

(return status = 0 ) Возврат к SQL Server 4.9.2 после его неудачного обновления на System 10 или 11 ЕСЛИ попытка перехода на сервер System 11 оканчивается неудачей, можно быстро вернуться к преж" нему серверу 4.9.2, используя записанные в процессе обновления сервера дампы базы данных master, a также сохраненные зеркальные копии устройств прежнего сервера. Ниже рассматриваются основ" ные этапы этого процесса (рис. 13.1). Важно отметить, что подобный процесс позволяет восстано" вить только базы данных, имевшие в сервере 4.9.2 полные зеркальные копии. Все остальные базы данных потребуется воссоздать заново и загрузить из дампов — при условии, что предварительно уда" стся восстановить базу данных master сервера версии 4.9.2. При неуспешном завершении процесса перевода сервера на System 11 обсудите возникшую ситуа" цию со службой технической поддержки компании Sybase. Уточните, является ли предлагаемый нами план возврата к прежнему серверу наилучшим выходом из создавшегося положения. Не исклю" чено, что преждевременное завершение процесса установки сервера System 11 вызвано второсте" пенными причинами, после устранения которых вам удастся завершить обновление сервера. Никогда не торопитесь возвращаться назад, но заранее подготовьтесь к быстрому и точному выпол" нению соответствующей процедуры. Остановить сервер Установить сервер 4.9.2 на действующем серверном устройстве master Загрузить дамп базы данных master сервера версии 4.9.2 Изменить принадлежность первичных серверных устройств Перезапустить сервер Восстановить исходную конфигурацию дисковых устройств' сервера 4.9.2 Остановить сервер Если после неудачной попытки обновления сервер все еще продолжает работать, остановите его. Это позволит восстановить серверное устройство master в формате версии 4.9.2 в дисковом разделе, уже содержащем устройство master нового сервера System 10 или 11. Установить сервер 4.9.2 на действующем серверном устройстве master Наша основная цель — загрузить дамп базы данных master прежнего сервера 4.9.2. Для этого необходи" мо запустить SQL Server 4.9.2, что, в свою очередь, требует восстановления прежнего серверного устройства master программой buildmaster (которая уничтожит находившееся в том же разделе устройство master, уже преобразованное к формату System 10/11). Для восстановления устройства master в формате 4.9.2 введите команду buildmaster "d /dev/rdsk/ <раздел_диска> "s <размер_устройства_master> Размер устройства master необходимо задать в виде числа 2"килобайтовых страниц. Подчеркнем, что здесь нужно воспользоваться версией программы buildmaster, входящей в состав SQL Server 4.9.2, а не System 10/11. Загрузить дамп базы данных master сервера версии 4.9.2 Запустите сервер в однопользовательском режиме (указав параметр "т в командном файле запу" ска сервера RUN<имя_сервера>). Убедитесь в том, что вы запустили сервер версии 4.9.2, а не System 10/11, и что он по"прежнему полностью изолирован от пользователей. Загрузите создан" ный в процессе обновления сервера дамп базы данных master из файла с именем dump_<имя_cep" sepa>_master_4 . 9 .2_withmirrors_<датa>_<время>.out (проверьте, что загружается именно этот дамп!). Процедура загрузки дампа базы данных master детально описывается в руководстве по устранению неполадок SQL Server (SQL Server Troubleshooting Guide). Загрузка базы данных master приведет к автоматическому останову сервера. 25—2221

www.books-shop.com

Рис. 13.1. Возврат к версии 4.9.2 SQL Server

www.books-shop.com

Используемый дамп базы данных master содержит таблицу sysdevices с полным описанием зеркаль" ных копий серверных устройств, существовавших в сервере 4.9.2 (см. параграф "Сохранить дамп базы данных master с зеркальным отображением серверных устройств" раздела "Обновление SQL Ser" ver 4.9.2 на System 11 (либо System 10)"). После перезапуска сервера ему вновь станут доступны ранее удаленные зеркальные копии серверных устройств, содержащие прежние базы данных в формате версии 4.9.2 (в то время как первичные устройства зеркальных пар содержат эти же базы данных, но уже преобразованные к формату System 10 или System 11, см. рис. 13. 1г). Изменить принадлежность первичных серверных устройств Измените принадлежность (и, возможно, права доступа) специальных системных файлов управления доступом к разделам дисков, на которых находятся первичные устройства всех зеркальных пар серве" ра. UNIX"пользователь Sybase больше не должен иметь возможности обращаться к этим разделам. Перезапустить сервер При перезапуске SQL Server 4.9.2 откроет восстановленную базу данных и найдет в ней таблицу sysde vices с описанием ранее существовавших зеркальных пар. Поскольку попытка обращения к первич" ным устройствам этих пар (где находятся базы данных в формате System 10/11) окажется безуспешной, сервер автоматически переключится на вторичные устройства пар, содержащие преж" ние базы данных в их исходном формате SQL Server 4.9.2. С этого момента сервер станет использо" вать первичную копию серверного устройства master и вторичные копии всех остальных серверных устройств (см. рис. 13. 1д). Восстановить исходную конфигурацию дисковых устройств сервера 4.9.2 Здесь необходимо решить, насколько долго вы намерены продолжать эксплуатацию прежней версии сервера. Если восстановленный сервер версии 4.9.2 будет использоваться в течение длительного пе" риода времени, следует удалить первичные устройства зеркальных пар и затем восстановить их в ка" честве зеркальных копий активных устройств сервера 4.9.2 (являвшихся ранее вторичными устройствами зеркальных пар прежнего сервера). Подобная операция приведет к замене обновлен" ных версий баз данных копиями этих же баз данных в формате версии 4.9.2. В заключение еще раз отметим, что представленный на рис. 13.1 процесс возврата к SQL Server версии 4.9.2 возможен только при наличии полного комплекта зеркальных копий устройств прежне" го сервера и своевременного сохранения дампа базы данных master (а также удаления зеркальных ко" пий прежних устройств) в процессе обновления сервера. Обновление SQL Server 4.9.2 на сервер System 10 Процесс перехода от SQL Server 4.9.2 к SQL Server System 10 практически идентичен переходу к System 11 (см. выше). Полное обновление SQL Server System 10 до версии System 11 Переход от System 10 к System 11 выполняется намного проще, чем обновление SQL Server 4.9.2, по" скольку подавляющая часть несовместимостей между SQL Server 4.9.2 и System 11 устраняется при пе" реходе от версии 4.9.2 к System 10. В частности, работоспособный сервер System 10 уже включает в себя серверные устройства с базами данных sybsystemprocs и sybsecurity. Кроме того, при переходе от System 10 к System 11 конфликты зарезервированных слов маловероятны, так как в составе System 11 появилось лишь несколько новых зарезервированных слов. Ниже перечислены основные этапы пол" ного обновления SQL Server System 10 до версии System 11. Каждый из этих этапов подобен аналогич" ной операции, рассмотренной при описании перехода от SQL Server 4.9.2 к System 11. Установить режимы работы баз данных по умолчанию Выполнить предварительную проверку баз данных программой sybinit Выполнить программой sybinit предварительную проверку использования зарезервированных слов Удалить вторичные устройства зеркальных пар При необходимости освободить место для новых серверных устройств System 11 Проверить работоспособность всех оставшихся зеркальных копий серверных устройств Проверить базы данных командой dbcc

www.books-shop.com

Убедиться в наличии достаточного свободного пространства во всех базах данных Сохранить дампы журналов транзакций и выполнить команду checkpoint во всех базах данных Обновление SQL Server System 10 до System 11 путем загрузки дампов баз данных System 10 Переход от System 10 к System 11 можно выполнить и по"другому: сначала установить отдельный SQL Server System 11, создав в нем все необходимые базы данных, а затем загрузить дампы этих баз дан" ных, записанные на прежнем сервере System 10. Приведение структуры баз данных System 10 к форма" ту System 11 будет выполнено автоматически в процессе их загрузки в SQL Server System 11. К преимуществам подобного подхода относится сохранение работоспособности прежнего сервера вплоть до момента переключения системы на полностью подготовленный и протестированный но" вый сервер. Кроме того, в процессе последовательной загрузки дампов баз данных проще проследить за возникновением проблем, относящихся к отдельным базам данных, и тем самым исключить воз" можность порчи сразу нескольких баз данных. Записать дампы баз данных SQL Server System 10 Сохраните дампы всех баз данных System 10, которые вы намерены перенести на новый сервер System 11. Установить SQL Server System 11 Выполните все этапы установки нового сервера System 11, подробно описанные выше. Затем коман" дой bср скопируйте в дисковый файл содержимое таблицы syslogins сервера System 10 и загрузите этот файл в SQL Server System 11 (некоторые существенные особенности данного процесса рассмотрены в главе 9). Создать на сервере System 11 все требуемые базы данных Создайте на новом сервере System 11 копии всех баз данных прежнего сервера, переносимых на но" вый. Как и при любом воссоздании базы данных, перед загрузкой ее дампа следует проследить за со" блюдением порядка распределения базам данных экстентов дискового пространства и за размерами этих экстентов. Для выдачи логической структуры баз данных сервера System 10 рекомендуем воспо" льзоваться командным файлом p_dbcreate (см. главу 14). Сохранив в отдельном файле выдачу, полу" ченную при выполнении p_dbcreate в каждой из переносимых баз данных, вы сможете непосредственно применить полученный командный файл для создания точных копий баз данных на новом сервере. При этом в команде create database необходимо указать параметр for load (авто" матически включаемый в выдачу командного файла p_dbcreate). Загрузить дампы баз данных System 10 в сервер System 11 Перенеся дампы баз данных на новую серверную машину, загрузите их в сервер System 11. Перевести загруженные базы данных в оперативный режим По завершении загрузки дампов перенесенные базы данных находятся в автономном (off"line) режи" ме, и их необходимо перевести в оперативный (on"line) режим командой online database <имя_базы_данных>. В процессе выполнения этой команды сервер System 11 автоматически преоб" разует активизируемую базу данных из формата System 10 в формат System 11, что завершит процесс обновления сервера System 10. Удалить и воссоздать необходимые объекты баз данных Как и при полном обновлении сервера до версии System 11, здесь необходимо удалить и создать зано" во все объекты данных, содержащие вложенные запросы. Порядок выполнения подобной операции рассмотрен выше в разделе "Удалить и воссоздать объекты баз данных".

www.books-shop.com

Глава 14

Командные

файлы

Универсальные командные файлы для работы с SQL Server Запись дампов журналов транзакций баз данных (dumplog) Запись дампов нескольких баз данных SQL Server 4.9.2 (dumpdb_492) Загрузка дампов баз данных в SQL Server 4.9.2 (loaddb_492) Обновление статистики оптимизатора по всем таблицам сервера (update_statistics_all_tables) Построение командного файла создания баз данных (dump_db_create) Выполнение dbccпроверок (checkdb) Выдача содержимого системных таблиц (dump_systables) Генерация командного файла создания базы данных (хранимая процедура p_dbcreate) Проверка состояния зеркальных пар устройств (хранимая процедура p_mirror) Проверка использования дискового пространства серверного устройства (хранимая процедура p_devspace) Выдача дампов баз данных (dumpdb) Загрузка баз данных (loaddb) Отслеживание хода загрузки дампа базы данных (хранимая процедура p_dbload) Командный файл запуска сервера Командные файлы эксплуатации SQL Server System 11 Дампы баз данных System 11 (dump_listof_dbs) Выдача дампов журналов транзакций (logdump_listof_dbs) Принудительная очистка журнала транзакций (trunclog_listof_dbs) Удаление старых файлов (remove_old_files) Обновление статистики оптимизатора (update_listof_dbs) Выполнение dbccпроверок (dbcc_listof_dbs) Поиск сообщений об ошибках в журнале регистрации ошибок SQL Server (scan_errorlog) Выдача конфигурации сервера (dump_server_config) Контроль активности пользователей (monitor_report) Запуск процедуры sp_sysmon (execute_sp_sysmon) Автоматический перезапуск сервера Строки описания командных файлов в таблице crontab

www.books-shop.com

В этой главе приводится ряд командных файлов, которые можно разбить на две категории. К первой из них относятся командные файлы общего назначения, применяемые для запуска серве" ра, для создания дампов баз данных SQL Server версий 4.9.2 и System 10, а также для создания храни" мых процедур, помогающих контролировать состояние сервера и процесс его работы. Вторая группа командных файлов специально ориентирована на контроль и поддержание работоспособно" сти промышленно эксплуатируемого сервера System 11. Все важнейшие составные части каждого командного файла сопровождаются подробными ком" ментариями, начинающимися с символа #. Однако комментарии к конкретной команде или синтак" сической конструкции приводятся только при первом ее использовании и не повторяются в последующих командных файлах. Завершив выполнение, командные файлы высылают электронной почтой по адресу администра" тора сервера полный протокол своей работы. Информация о возникновении ошибок в процессе вы" полнения командного файла посылается администратору отдельным сообщением. В эти файлы можно вставить дополнительные команды, например, позволяющие оповестить других администра" торов баз данных о появившихся проблемах. Копии протоколов выполнения командных файлов со" храняются на диске, но только до следующего вызова соответствующего файла, что позволяет избежать самопроизвольного переполнения файловой системы. Рекомендуем сохранять поступаю" щие по электронной почте сообщения о выполнении командных файлов, тем самым регистрируя ход работы сервера в течение длительного периода времени. Разумеется, перед началом практиче" ского использования командных файлов в них необходимо указать правильный электронный адрес администратора сервера. При выполнении перечисленных ниже командных файлов предполагается, что поставляемая компанией Sybase утилита isql находится в каталоге с именем $SYBASE/bin. Если на вашей сер" верной машине этот каталог называется по"другому, то в командные файлы следует внести необхо" димые изменения. Командные файлы общего назначения Рассматриваемый набор командных файлов рекомендуется к использованию на всех серверах вашей информационной системы. На основе этих файлов вы можете создать собственные файлы для осуще" ствления других регулярно выполняемых операций. Все командные файлы общего назначения напи" саны для оболочки С. Однако, благодаря детальным комментариям, данные файлы легко адаптировать под любую другую оболочку, используемую в вашей системе. Особенности различных версий SQL Server Все командные файлы общего назначения могут использоваться (с определенными изменениями) со" вместно с любой версией сервера. SQL Server 4.9.2 Ряд приведенных ниже командных файлов специально предназначен для того, чтобы обойти некото" рые ограничения, имеющиеся в версии 4.9.2 SQL Server, например невозможность записи несколь" ких дампов баз данных на одну магнитную ленту и т.п. В этих командных файлах предполагается, что все создаваемые и используемые хранимые процедуры должны находиться в базе данных sybsystemp rocs, специально предназначенной для размещения хранимых процедур. Однако SQL Server вер" сии 4.9.2 не имеет такой базы данных, поэтому при работе с ним необходимо указать в командном файле фактическое название базы данных, в которой содержится соответствующая хранимая проце" дура (обычно в этой роли выступает база данных master). Командный файл dump_systables написан специально для сервера System 11. При его исполь" зовании в SQL Server 4.9.2 или System 10 необходимо учитывать, что большая часть дополнительной информации о конфигурации сервера выдается UNIX"командой следующего вида: $SYBASE/bin/buildmaster "d<физический_адрес_устройства_master> "yall Более подробное описание порядка применения программы buildmaster можно найти в руковод" стве по сообщениям об ошибках SQL Server (Sybase SQL Server Error Messages). Отметим, что рабо" тать с этой программой должны только опытные пользователи. Командные файлы, использующие возможности сервера архивации Backup Server, не могут при" меняться в SQL Server версии 4.9.2.

www.books-shop.com

SQL Server System 10 Все создаваемые хранимые процедуры должны находиться в системной базе данных sybsystemprocs. SQL Server System 11 Все создаваемые хранимые процедуры должны находиться в системной базе данных sybsystemprocs. Выдача дампов журналов транзакций баз данных (dumplog) Приведенный ниже командный файл сохраняет дампы журналов транзакций всех баз данных, указан ных при его вызове. Как правило, подобный командный файл должен использоваться в качестве cronзадания, автоматически выполняющегося через определенные промежутки времени. В этом слу чае файл с паролем пользователя 'sa' должен быть доступен только UNIXпользователю с именем dba, что позволит обратиться к этому паролю при описании командного файла dumplog в файле сгоп" tab. Ниже приводится пример описания командного файла dumplog в файле crontab, обеспечиваю щем автоматический запуск dumplog через каждый час в интервале времени с 10 до 22 часов: О 10"22 * * * /dba/<имя_cepвepa>/scripts/dumplog 'cat /usr/dba/ . <имя_сервера> ' dbl Подобная строка, указанная в файле crontab, обеспечит выполнение командного файла dumplog в начале каждого часа (точнее, через 0 минут после начала каждого часа) в интервале времени с 10 до 22 часов. И всякий раз командный файл dumplog будет сохранять журнал тран закций базы данных dbl. В этом и ряде последующих примеров файл паролей называется /usr/dba/.<имя_cepвepa> . Команда вызова файла dumplog имеет следующий формат: dumplog <sа_пароль> Результатом ее выполнения станет запись на диск дампов журналов транзакций всех перечислен ных баз данных. # ! / b i n / c s h "f # # # # # # # #

Первая строка файла крайне важна # она указывает, что данный командный файл должен обрабатываться оболочкой С (хотя на первый взгляд кажется, что это просто строка комментария) . Теперь давайте убедимся в наличии достаточного количества аргументов. Аргумент номер 0 всегда содержит имя командного файла при его вызове, аргумент номер 1 должен представлять собой пароль, а аргумент номер 2 является названием первой из указанных баз данных.

if ($#argv < 2 ) then # # # # #

Команда echo выводит указанный в ней текст на экран; соответственно, команда echo $ { 0 } выдает на экран значение нулевого аргумента (имя командного файла, указанное при его вызове) и весь последующий текст. При недостаточном количестве параметров командный файл выдает список требуемых параметров и прекращает работу. echo ${0}: invalid format: $#argv parameters provided, at least 2 required echo ${0}: required format: ${0} '<sa password> ' exit(l)

# Команда exit(l) приводит к завершению выполнения файла с кодом # возврата 1, указывающим на наличие ошибок. Это полезно при # вызове данного командного файла из другого командного файла. endif # Проверяем, действительно ли файл вызван пользователем 'dba'. Если

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

# это не так, прекращаем выполнение с выдачей сообщения об ошибке. if 'whoami' != "dba") then echo you must be UNIX user dba to dump the transaction log # выдача дампа журнала транзакций разрешена только UNIX#пользователю dba exit(1) endif # # # # # # # # #

Команда umask определяет права доступа, которые устанавливаются по умолчанию всем файлам, создаваемым в процессе работы командного файла. Для получения фактически устанавливаемых прав доступа необходимо вычислить выражение 'umask' XOR 666, где 'umask' — значение, указанное в команде umask (в нашем случае 006). Команда unalias удаляет все псевдонимы, определенные для команды rm # пользователи системы UNIX часто делают команду rm псевдонимом командного файла, запрашивающего подтверждение на удаление каждого отдельного файла.

umask 006 unalias rm # # # #

Установим значения различных параметров, которые будут использоваться впоследствии. Переменная SYBASE содержит полное имя базового каталога программных продуктов компании Sybase.

setenv SYBASE /home/sybase # Переменная SERVER содержит имя сервера, с которым мы работаем, setenv SERVER PDSOPS21 # Переменная BIN указывает полное имя подкаталога каталога $SYBASE, # содержащего выполняемые модули программ Sybase. set BIN=${SYBASE}/bin # # # # # # # #

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

set logdir=/diskdump set outfile=${logdir}/dumplog.out set password=$l shift ' . # Переменная dmptime содержит текущие дату и время, set dmptime='date +%y%m%d%H%M%S' # # # #

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

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

www.books-shop.com

# # # # #

Команда ps #ef выдает список всех системных процессов, выполняющихся на серверной машине. Команда grep извлекает из этого списка только строки, содержащие слово 'dumplog'. Команда wc #1 определяет количество таких строк (при вызове без параметра #1 команда wc вычисляет количество слов).

ps #ef > /tmp/ps.dumplog set cnt = 'grep dumplog /tmp/ps.dumplog

wc

#1'

# Из значения переменной cnt необходимо вычесть число 2 (одна строка # соответствует текущему процессу dumplog, а другая # cron#процессу). # Команда ехрr вычисляет значение выражения, указанного в обратных # кавычках '. set cntl = 'expr $cnt # 2' if ($cntl > 0) then # Команда mail посылает пользователю dba сообщение, в строке # "Subject:" которого будет содержаться текст, указанный в # качестве значения параметра s. mail #s "${SERVER} dumplog aborted" dba < /tmp/ps.dumplog exit 1 endif # Удаляем временный файл, содержащий выдачу команды ps #ef. rm /tmp/ps.dumplog # Присваиваем переменной dbs_to_trandump список баз данных, указанный # при вызове dumplog. set dbs_to_trandump=($argv) # Записываем в файл протокола дату и время начала обработки баз данных, echo "dumplog:${SERVER}: started at 'date'." > $outfile # Начинаем цикл последовательной обработки всех баз данных, указанных .# при вызове командного файла. foreach dbname ($dbs_to_trandump) # Создаем дисковый файл, в который будет записан дамп журнала транзакций, set logfile=${dbname}.log_${dmptime} # # # # # #

Вызываем утилиту isgl с явным указанием ее полного имени (соответствующий каталог может не входить в путь просмотра cron#процесса). Параметр #е направляет копии выдачи в файл вывода, создаваемый для каждой отдельной обрабатываемой базы данных. После вызова isgl все последующие команды (вплоть до метки finish_sql) направляются непосредственно этой утилите.

${BIN}/isql #Usa #S${SERVER} #I$SYBASE/interfaces #e > ${dbname}_logdump.out << finish_sql $password dump tran $dbname to '${logdir}/${logfile}' go exit

finish_sgl # Если выполнение утилиты isql завершилось с ненулевым кодом возврата,. # то сообщим о возникновении ошибок пользователю dba.

www.books-shop.com

if ($status) then echo dumplog:${SERVER}: log dump of $dbname failed at 'date'. >> $outfile mail #s "${SERVER}: log dump of $dbname failed" dba < $outfile endif # Запишем в файл протокола время завершения выдачи дампа журнала # транзакций. echo dumplog:${SERVER}: completed xact log dump of $dbname at 'date' >> $outfile end # Вне зависимости от результатов выполнения dumplog запишем в протокол # время завершения работы и вышлем весь протокол пользователю dba. echo "dumplog:${SERVER}: exiting at 'date'." >> $outfile mail #s "${SERVER}: log dump cronjob complete" dba < $outfile exit Запись нескольких дампов баз данных SQL Server 4.9.2 на одну ленту (dumpdb_492) Внимание! Запись нескольких дампов баз данных на одну магнитную ленту не входит в число возмож" ностей SQL Server, официально поддерживаемых компанией Sybase. Командный файл dumpdb_492 позволяет записать на магнитную ленту дампы одной или несколь" ких баз данных. Хотя Sybase SQL Server 4.9.2 официально не обеспечивает этой операции, она впол" не возможна при наличии накопителя на магнитной ленте, не перематывающего ленту к началу автоматически по завершении записи. Сбросив на ленту один дамп, мы начинаем записывать на нее следующий — и так до конца ленты либо до момента, когда накопитель перемотает ее к началу. Еще раз отметим, что вы используете командный файл dumpdb_492 на свой страх и риск, поскольку за" пись на ленту более одного дампа не поддерживается Sybase. Поскольку мы намерены записывать именно на ленту, командный файл dumpdb_492 ориентиро" ван на запуск вручную оператором сервера после установки ленты на записывающее устройство. Имя и пароль пользователя запрашиваются в интерактивном режиме после запуска dumpdb_492. Разумеется, пользователь должен иметь необходимые права для записи дампов баз данных: во всех базах данных ему должны быть установлены полномочия dump database. При работе с SQL Ser" ver 4.9.2 рекомендуется еще до создания пользовательских баз данных внести всех таких пользовате" лей в базу данных model с указанием соответствующих полномочий, что автоматически сделает их пользователями остальных баз данных сервера, имеющими право записывать дампы этих баз дан" ных. При желании командный файл dumpdb_492 может быть модифицирован для автоматического запуска в качестве cron"задачи. Основные изменения потребуется внести в начальную часть файла, чтобы обеспечить чтение имени пользователя и его пароля непосредственно из командной строки формата dumpdb_492 <имя_пользователя> <пароль>. Приведенная ниже версия файла dumpdb_492 ориентирована на интерактивное выполнение и запрашивает эту информацию непо" средственно с экрана терминала, ожидая завершения ее ввода. #!/bin/csh #f umask 006 setenv SYBASE /home/sybase # # # # #

Запрашиваем с терминала имя пользователя и пароль. Команда echo #n не переводит курсор на новую строку после вывода текста на экран. Введенный пользователем текст присваивается переменным с помощью команд вида set username = $<

www.books-shop.com

# Команда stty #echo отключает выдачу вводимых символов на экран. # Команда clear очищает экран. echo #n Please set username = stty #echo echo #n Please set password = stty #echo clear

enter your SQL Server login: $< enter your SQL Server password: $<

# Записываем имя файла протокола в переменную outfile. set outfile=/diskdump/public_dumpdb.out # Выдаем на экран и в протокол дату запуска dumpdb_492 и имя файла # протокола. echo "dumpdb:PDSOPS21: started at 'date'." echo "dumpdb:PDSOPS21: started at 'date'." > $outfile # # # # # # #

В системе UNIX для управления устройством записи на ленту применяется команда mt. Параметр #f задает название используемого устройства (nrst8). Это накопитель без автоматической перемотки ленты к началу, выполняющий данную операцию только после получения специальной команды. Именно такую команду мы применяем для установки ленты на место записи первого дампа.

mt #f /dev/nrst8 rewind # # # # # # # # # # # # # #

Прежде всего выдадим на ленту запись заголовка, содержащую имя серверной машины,' а также дату и время запуска файла dumpdb_492. Заголовок потребуется для идентификации ленты в будущем. Его приходится записывать вручную, поскольку подобная операция не поддерживается SQL Server 4.9.2. Сначала имя серверной машины и дата выдаются во временный файл dumptape_header, который затем сбрасывается на ленту стандартной UNIX#командой dd, используемой для непосредственной записи информации в файлы и на устройства. В команде dd параметр if задает имя входного файла, of — имя выходного файла, bs указывает длину блока для входного и выходного файлов, a count устанавливает количество блоков, выдаваемых в выходной файл. Команда uname #а позволяет получить сетевое имя машины и используемую версию операционной системы.

echo '/usr/bin/uname #a'" "'/usr/bin/date' >/tmp/dumptape_header dd if=/tmp/dumptape_header of=/dev/nrst8 bs=80 count=l # # # # # #

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

foreach dbname (master dbl db2 db3 db4 model) echo "dumpdb:PDSOPS21: dump of $dbname started at

'date'." echo "dumpdb:PDSOPS21: dump of $dbname started at 'date'." >> $outfile

www.books-shop.com

# # # # # # # # # # #

Вывод дампов баз данных осуществляется на логическое устройство вывода дампов ntapedump8, которому назначен физический накопитель на магнитной ленте nrst8. При работе с файлом dumpdb_492 вы должны самостоятельно указать названия логического устройства вывода дампов и используемого ленточного накопителя. Поскольку файл dumpdb_492 вызывается оператором, а не UNIX#пользователем 'dba', мы не можем использовать серверную копию утилиты isgl ($SYBASE/bin/isql) и вызываем локальную копию этой утилиты, находящуюся на рабочей станции оператора. Здесь требуется указать полное имя общедоступной копии утилиты isgl в вашей системе.

/usr/local/sybase/bin/isgl #U$username #SPDSOPS2 #е >> ${outfile} <> $outfile cat ${dbname}_dbdump.out >> $outfile else echo "dumpdb:PDSOPS21: database dump at 'date' echo "dumpdb:PDSOPS21: database dump at 'date'." >> $outfile endif end

of $dbname has FAILED of $dbname has FAILED

of $dbname completed of $dbname completed

# По завершении записи всех дампов баз данных на ленту # текущие дата и время выдаются на экран оператора # и записываются в протокол. echo "dumpdb:PDSOPS21: exiting at 'date'." echo "dumpdb:PDSOPS21: exiting at 'date'." >> $outfile # Высылаем протокол пользователю dba. mail #s "dumpdb:PDSOSP21: output" dba < $outfile # С помощью UNIX#команды mt с параметром offline перематываем ленту # к началу и разгружаем ее с устройства. mt #f /dev/nrst8 offline exit

# Перемотка ленты

Загрузка дампов баз данных в SQL Server 4.9.2 (loaddb_492) Командный файл loaddb_4 92 загружает один или несколько дампов баз данных, записанных на лен ту командным файлом dumpdb_492. Поскольку размещение на одной ленте сразу нескольких дампов баз данных не поддерживается стандартными средствами SQL Server 4.9.2, для чтения таких лент

www.books-shop.com

также требуется специальный командный файл. В процессе своей работы SQL Server 4.9.2 не контро" лирует состояния магнитной ленты и сразу по получении команды load database начинает читать ленту с того места, на которое она была установлена. Главная задача командного файла lo" addb_492 — перемотать ленту точно к началу дампа требуемой базы данных. Поскольку после записи заголовка ленты командный файл dumpdb_492 сохраняет дампы баз данных в строго определенном порядке, можно определить порядковый номер каждого отдельного дампа и перемотать ленту к его началу. Пусть, к примеру, с помощью приведенного выше файла dumpdb_492 мы записали на ленту дам" пы баз данных master, db1, db2, db3, db4 и model При загрузке дампа базы данных dbl необходимо иметь в виду, что в качестве первого ленточного файла (которому соответствует порядковый номер count = 0) записывается заголовок ленты. Поэтому дамп базы данных dbl является вторым дампом и третьим файлом ленты; его порядковый номер count = 2. Для перемотки ленты в начало дампа базы данных значение его порядкового номера достаточно указать при вызове UNIX"команды mt. Поскольку загрузка дампов баз данных редко выполняется автоматически в качестве сrоn"зада" ния, командный файл loaddb_492 прежде всего рассчитан на выполнение в режиме ручного запу" ска администратором сервера (который во время серьезных сбоев сервера, требующих восстановления баз данных из дампов, обычно находится на рабочем месте). При запуске файла 1о" addb_492 необходимо указать следующие аргументы:

loaddb_492 <имя_сервера> <sа_пароль> <список_6аз_данных> Во время работы командный файл loaddb_492 последовательно просматривает список указан" ных баз данных и определяет порядковые номера их дампов на магнитной ленте, после чего уста" навливает ленту в нужное место и начинает загрузку дампа. Необходимо принять во внимание ряд особенностей подобного подхода. Во"первых, количество, состав и порядок записи дампов баз дан" ных, выдаваемых на магнитную ленту командным файлом dumpdb_492, должны соответствовать пе" речню баз данных, указанных в операторе switch командного файла loaddb_492 , Во"вторых, если один из дампов не удалось записать на ленту, то нарушится порядок следования оставшихся дампов, и вам придется вручную внести соответствующие изменения в файл loaddb_492. Именно здесь ад" министратору сервера потребуется сообщение об ошибках выполнения dumpdb_492, отправленное по электронной почте в процессе работы этого командного файла. Таким образом, перед использо" ванием каждой магнитной ленты, записанной файлом dumpdb_492, рекомендуем внимательно про" смотреть сообщения, отправленные в процессе записи этой ленты, и при необходимости внести изменения в файл loaddb_492. # ! / b i n / c s h "f umask 006

#

Установка

прав

доступа

к

файлам

#rw#rw

—

# Убедимся в наличии всех требуемых параметров. При их отсутствии # читаем и выдаем на экран заголовок ленты, распечатываем список # необходимых параметров и завершаем работу с кодом возврата 1 . if ! ($#argv) then dd if=/dev/rst8 bs=80 count=l echo loaddb: format: loaddb.PDSOPS21 '<Server Name> <Server Password> ' exit (1) endif setenv SYBASE /home /Sybase setenv SERVER PDSOPS21 set BIN=${ SYBASE} /bin # Присвоим значения имени сервера и пароля администратора # переменным srvname и password, после чего командой shift удалим # их из списка аргументов. set srvname = $1 shift

set password = $1 shift set databases_to_load = ($argv) echo "loaddb: started at 'date'."

www.books-shop.com

# # # # # #

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

mt #f /dev/rst8 rewind # # # # #

# Перематываем ленту к началу

Обработаем список загружаемых баз данных. Для каждой базы данных определим порядковый номер, под которым файл с ее дампом находится на ленте, и сохраним его в переменной counter. Если хотя бы одна из указанных при вызове баз данных отсутствует в списке сохраненных баз данных, завершаем работу с кодом возврата 1.

foreach dbname ($databases_to_load) echo loaddb: beginning load of $dbname switch ($dbname) case master: set counter = 1 breaksw case dbl: set counter = 2 breaksw case db2: set counter = 3 breaksw case db3: set counter = 4 breaksw case db4: set counter = 5 breaksw case model: set counter = 6 breaksw default: echo invalid database name $dbname exit (1) endsw # Перематываем ленту на начало n#го файла (здесь n=counter+l). # Напомним, что первый файл ленты имеет порядковый номер # counter=0. mt #f /dev/nrst8 fsf $counter # При ошибке во время позиционирования ленты рекомендуем # обратиться к администратору сервера. if ($status) then echo database load script failed during positioning of tape — contact DBA for help exit (1) endif # Записываем в протокол дату и время начала загрузки дампа.

echo "loaddb: started at 'date'." > /dba/${SERVER}/diagnostics/${dbname}_loaddb.out # Вызываем утилиту isql для загрузки первого дампа базы данных.

www.books-shop.com

# Перед началом работы с файлом вместо ntapedump8 укажите название # подходящего ленточного устройства вашего сервера. ${BIN}/bin/isql #Usa #S${srvname} #e >> /dba/${SERVER}/diagnostics/${dbname}_loaddb.out <> /dba/${SERVER)/diagnostics/${dbname}_loaddb.out exit (1) endif echo load of $dbname completed at 'date'. >> /dba/${SERVER}/diagnostics/${dbname}_loaddb.out # Перематываем ленту к началу и сгружаем ее с устройства. mt #f /dev/rst8 off

# перемотка ленты

end

# Выдаем в протокол дату и время завершения работы loaddb_492 и # высылаем протокол администратору сервера. echo "loaddb: ended at 'date'." >> /dba/${SERVER}/diagnostics/${dbname}_loaddb.out mail #s 'load of database complete' dba < /dba/${SERVER}/diagnostics/${dbname}_loaddb.out exit Обновление статистики оптимизатора по всем таблицам сервера (update_statistics_all_tables) Приведенный ниже командный файл автоматически выполняет серверную команду update sta tistics и хранимую процедуру sp_recompile по отношению к каждой пользовательской таблице, имеющейся йа сервере. На практике бывает сложно проследить за графиком своевременного обнов ления статистики оптимизатора по отдельным таблицам сервера. Даже если у вас имеется список основных таблиц, статистические данные по которым регулярно обновляются вручную, все равно ре комендуется использовать командный файл update_statistics_all_tables для регулярного ав томатического обновления статистики по всем таблицам сервера. Так вы сможете исключить возможность появления таблиц, по которым вообще не имеется статистических данных, необходи мых для нормальной работы оптимизатора запросов сервера. Среди таких таблиц могут оказаться не только вновь созданные, но и усеченные, а также некоторые другие таблицы, статистические данные которых сервер игнорирует до выполнения очередной команды update statistics. Командный файл update_statistics_all_tables рекомендуется запускать в качестве сronза дачи. Соответствующая строка его описания в файле crontab имеет вид: О 21 б * * /dba/<имя_cepвepa>/scripts/update_statistics_all_tables <имя_сервера> 'cat /usr/dba/.<имя_сервера>' Включение подобной строки в файл crontab приведет к автоматическому выполнению командно го файла update_statistics_all_tables в 21:00 каждой субботы каждого месяца и каждого года.

Отметим, что в файле crontab дни недели отсчитываются от воскресенья (день 0) до субботы (день 6). Кроме того, рассматриваемый командный файл можно запустить вручную: update_statistics_all_tables <имя_сервера> <sа_пароль>

www.books-shop.com

#!/bin/csh "f # Устанавливаем значения требуемых переменных и задаем имя файла # протокола unalias rm setenv SYBASE /home/sybase setenv BIN ${SYBASE}/bin set SERVER = $1 set PASSWORD = $2 set outfile=/dba/$${server}/diagnostics/update_statistics.out cp /dev/null $outfile # Сначала необходимо составить список всех баз данных сервера set TEMPFILE=/tmp/${SERVER}_databases.list cp /dev/null $TEMPFILE ${BIN}/isql #Usa #P$PASSWORD #S$SERVER #I$SYBASE/interfaces << finish_sgl >> $TEMPFILE use master go select name from sysdatabases where name != "tempdb" order by name go finish_sgl # Выдадим полученный список в файл протокола, после чего запишем # туда же имя сервера, текущие дату и время echo " " >> $outfile echo "all databases in server...." >> $outfile echo " " >> $outfile cat $TEMPFILE >> $outfile echo " " ${BIN}/isgl #Usa #P$PASSWORD #S$SERVER #I$SYBASE/interfaces << finish_sgl >> $outfile select @@servername go select getdate() go finish_sgl # Описание приведенных ниже команд можно найти в командном # файле dump_db_create set num_lines='wc #1 $TEMPFILE cut #cl#9' set last_line='expr $num_lines # 2' set first_line='expr $last_line # 2' set databases_list='tail #$last_line $TEMPFILE I head #$first_line' rm #f $TEMPFILE # Начинаем обработку полученного списка баз данных foreach dbname ($databases_list) # Теперь выдадим список всех пользовательских таблиц в каждой # обрабатываемой базе данных set TEMPFILE2=/tmp/${dbname}_tables.list cp /dev/null $TEMPFILE2 ${BIN}/isgl #Usa #P$PASSWORD #S$SERVER #I$SYBASE/interfaces #e << finish_sgl >> $TEMPFILE2 use $dbname

www.books-shop.com

до select name from sysobjects where type="U" order by name go finish_sql echo " " >> $outfile echo "gggggggggg@@g@gggggggg>> >> $outfile echo "all tables in database $dbname...." >> $outfile echo "@ggggggg@g@@@ggggggggg" >> $outfile echo " " >> $outfile cat $TEMPFILE2 >> $outfile echo " " >> $outfile # Из списка пользовательских таблиц удаляем четыре первые и две # последние строки set num_lines='wc #1 $TEMPFILE2 I cut #cl#9' set last_line='expr $num_lines # 4' set first_line='expr $last_line # 2' set tables_list='tail #$last_line $TEMPFILE2 I head #$first_line' rm #f $TEMPFILE2 # Переходим к обновлению статистики по каждой таблице базы данных # и к повторной компиляции всех объектов сервера, использующих # эти таблицы echo >>gggggggggggg@@gggg@@ggg@gggggggg@@gggg@@gg" >> $outfile echo "updating statistics for tables in database $dbname" >> $outfile echo >>g@giggggggggggg@gg@ggggggggggg@ggggg@@gggg" >> $outfile echo " " >> $outfile foreach table_name ($tables_list) ${BIN}/isql #Usa #P$PASSWORD #S$SERVER #I$SYBASE/interfaces.#e << finish_sql >> $outfile use $dbname go select getdate() go update statistics $table_name go sp_recompile $table_name

go select getdateO

go finish_sql # Первый оператор end завершает цикл просмотра таблиц базы данных, # а второй end — цикл просмотра всех баз данных сервера end end mail "s "$SERVER update statistics" dba < $outfile exit(O)

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Построение командного файла создания баз данных >_cepsepa>/scripts/dump_db_create <имя_сервера> 'cat /usr/dba/.<имя_сервера>' (В данном случае командный файл dump_db_create будет запускаться ежедневно в 23:00.) При руч ном запуске файла необходимо указать следующие параметры: dump_db_create <имя_сервера> <sа_пароль> # ! / b i n / c s h "f # Устанавливаем значения требуемых переменных и задаем имя файла # протокола. unalias rm setenv SYBASE /home/sybase setenv BIN ${SYBASE}/bin set SERVER = $1 set PASSWORD = $2 set outfile=/dba/${SERVER}/diagnostics/dump_db_create.out cp /dev/null $outfile # Поскольку необходимо сгенерировать команды (воc)создания всех # баз данных сервера, начнем с построения списка этих баз данных. set TEMPFILE=/tmp/${SERVER}_databases.list cp /dev/null $TEMPFILE ${BIN}/isql #Usa #P$PASSWORD #S$SERVER #I$SYBASE/interfaces << finish_sql >> $TEMPFILE use master go select name from sysdatabases where name != "tempdb" order by name go finish_sql # Выдадим полученный список в файл протокола, после чего запишем # туда же имя сервера, текущие дату и время. echo " " >> $outfile echo "all databases in server...." >> $outfile echo ". " >> $outfile cat $TEMPFILE >> $outfile echo " " ${BIN}/isql #Usa #P$PASSWORD #S$SERVER #I$SYBASE/interfaces << finish_sql >> $outfile select @@servername

go select getdate() go finish_sql # Получив список всех баз данных сервера, удалим из него две первые # и две последние строки, содержащие названия столбцов распечатки и # количество найденных записей. Для этого командой wc #1 необходимо

www.books-shop.com

# # # # # # # # #

определить полное количество строк временного файла $TEMPFILE, содержащего список (параметр #1 требуется для того, чтобы команда wc (word count) подсчитала количество строк, а не слов). Команда cut #с оставляет в выдаче команды wc #1 только необходимое нам количество строк num_lines, после чего команда tail выдает (num_lines # 2) последних строк файла $TEMPFILE (т.е. все строки без первых двух) , а команда head отсекает две последние строки. В итоге, мы получаем все строки временного файла $TEMPFILE, за исключением двух первых и двух последних строк.

set num_lines='wc #1 $TEMPFILE I cut #cl#9 set last_line= ' expr $num_lines # 2' set first_line='expr $last_line # 2' set databases_list='tail #$last_line $TEMPFILE I head #$first_line' rm #f $TEMPFILE # Получив требуемый список баз данных, выполним для каждой из них # хранимую процедуру p_dbcreate. foreach dbname ($databases_list) ${BIN}/isql #Usa #P$PASSWORD #S$SERVER #I$SYBASE/interfaces

<< finish_sql >> $outfile # # # # # #

В приведенных ниже командах предполагается, что хранимая процедура p_dbcreate находится в базе данных sybsystemprocs, отсутствующей в сервере версии 4.9.2. Если процедура p_dbcreate помещена в другую базу данных, то в следующей строке необходимо указать имя этой базы данных (таковой для SQL Server 4.9.2 окажется, скорее всего, база данных master) .

use sybsystemprocs go p_dbcreate $dbname go finish_sql end

exit (0)

Выполнение dbccпроверок (checkdb) Командный файл checkdb позволяет выполнить полный набор dbccпроверок структуры базы дан ных — например, после ее загрузки из дампа на специальный DBCCсервер. В приведенном ниже командном файле проверяется база данных с именем dbl, уже загруженная на сервер. Заметим, что при создании копии этой базы данных на вспомогательном сервере большую помощь может оказать процедура p_dbcreate (см. ниже), позволяющая получить полное описание структуры исходной базы данных основного сервера в виде последовательности команд создания этой базы данных (при необходимости в полученной последовательности потребуется изменить названия серверных устройств). Отметим, что генерируемые процедурой p_dbcreate команды автоматически создают базу данных в режиме for load. Командный файл checkdb запускается в ручном режиме с указанием единственного параметра — пароля администратора сервера: checkdb <sа_пароль> Имя проверяемой базы данных жестко встроено в приведенный ниже командный файл. Однако его легко изменить так, чтобы это имя указывалось в командной строке при запуске файла. Отме тим, что фактически используемая структура файла checkdb зависит от особенностей процедуры проверки баз данных, принятой в вашей информационной системе. Как правило, в наиболее круп ных базах данных dbccпроверки производятся только по отношению к некоторым таблицам. В по добной ситуации, возможно, придется создать набор командных файлов, проверяющих каждую базу данных по отдельности.

www.books-shop.com

#!/bin/csh #f # # # # # # # # # # # #

Команда select @@servername выдает имя сервера, к которому вы подключились. Команда select db_name() возвращает название текущей базы данных. Команда select getdate() сообщает дату и время выполнения файла. Команда dbcc traceon (3604) направляет выдачу dbcc#подкоманд на экран терминала (в нашем случае выдача переадресовывается в файл протокола). В процессе работы командный файл checkdb сообщает дату и время завершения каждой отдельной dbcc#проверки, что важно для планирования последующих запусков команды dbcc на основном сервере системы (например, для устранения повреждений, обнаруженных при анализе копий баз данных на вспомогательном DBCC#сервере).

isql #Usa #P$l #SDDSMAIN1 > dbcc_dbl.out << finish_sql select @@servername go use dbl go

select db_name() go select getdate() go dbcc traceon (3604) go dbcc checkalloc (dbl)

go select getdate() go dbcc checkdb (dbl)

go select getdate() go dbcc checkcatalog (dbl) go select getdate() go finish_sql mail #s "dbcc runs for dbl completed" dba < dbcc_dbl.out exit(0)

Выдача содержимого системных таблиц (dump_systables) При запуске в качестве cronзадачи командный файл dump_systables позволяет регулярно записы вать на диск информацию о конфигурации сервера, содержащуюся в его различных системных табли цах. Файл dump_systables должен выполняться не реже одного раза в день. Поскольку в процессе эксплуатации SQL Server System 11 могут использоваться разные конфигурационные файлы, их копии необходимо сохранять вместе с выдачей dump_systables и ежедневно сбрасывать на магнитную ленту стандартными средствами архивации системы UNIX. Очень важно обеспечить регулярное и полное сохранение сведений о конфигурации всех серверов вашей системы — эта информация потре буется в момент устранения сбоев сервера, когда получить ее непосредственно из сервера, как прави ло, бывает уже невозможно. Следующая запись в файле crontab обеспечит ежедневный запуск командного файла dump_sys tables ровно в 20:00; О 20 * * * /dba/<имя_cepвepa>/scripts/dump_systables <имя_сервера> 'cat /usr/dba/.<имя_сервера>'

www.books-shop.com

При каждом запуске файл dump_systables читает из командной строки имя обрабатываемого сервера и выводит информацию в дисковый файл, название которого определяется именем этого сервера: dump_systables <имя_сервера> <sа_пароль> Одновременно из этого файла удаляется вся информация, оставшаяся от предыдущего запуска. # ! / b i n / c s h "f if ($#argv < 2) then echo ${0}: invalid format, $#argv parameters given, 2 required. echo ${0}: required format: ${0} '<svrname> <password> .' exit (1) endif umask 006 # Установка прав доступа к файлам #rw#rw — setenv SYBASE /home/sybase setenv BIN ${SYBASE}/bin set SERVER=$1 shift set PASSWORD=$1 shift # Зададим имя каталога, где будет находиться файл выдачи # dump_systables . set dir=/dba/${ SERVER} /diagnostics cd $dir # # # # # # # # # #

Вызвав утилиту isql, подключаемся к серверу в качестве пользователя 'за' и направляем выдачу в файл. Сначала извлекаем информацию из таблиц базы данных master, затем распечатываем конфигурацию сервера хранимой процедурой sp_configure и переходим к базе данных sybsystemprocs. Здесь с помощью хранимых процедур p_mirror и p_devepace определяем конфигурацию зеркальных копий серверных устройств и распределение их дискового пространства. Наконец, сохраняем все учетные записи пользователей в системной таблице syslogins — они будут нужны при восстановлении сервера.

${BIN}/isql #Usa #S${SERVER} > ${dir} /${SERVER}_dump_systables.out << finish_sql $PASSWORD use master go ' select * from sysusages go select * from sysdevices

go select * from sysdatabases

go select * from sysservers go select * from sysremotelogins go exec sp_configure

go exec sp_helpdevice go

exec sp_helpdb go select * from syslogins go

www.books-shop.com

use sybsystemprocs go exec p_mirror go exec p_devspace go exec p_servermap go exit finish_sql # В конец файла выдачи записываем текущие дату и время. date >> ${dir}/${SERVER}_dump_systables.out chmod 600 ${SERVER}_dump_systables.out exit Хранимая процедура, генерирующая командный файл создания базы данных (p_dbcreate) Приведенный ниже командный файл создает в базе данных sybsystemprocs хранимую процедуру p_dbcreate, которая выдает в дисковый файл последовательность команд, позволяющих воссоздать структуру любой базы данных сервера, и используется при работе командного файла dump_db_crea" te, рассмотренного выше. Параметр for load позволяет значительно ускорить обработку команды create database, поскольку в этом случае сервер предполагает немедленную загрузку всего дампа созданной базы дан" ных, не позволяя выполнять с ней каких"либо других действий. В результате сервер имеет возмож" ность не производить полной инициализации всех распределенных базе данных страниц данных, как это происходит при выполнении обычной команды create database, что дает значительную экономию времени при создании больших баз данных. Помимо команды create database for load, процедура p_dbcreate генерирует команды на языке Transact"SQL, которые вносят в системную таблицу sysusages базы данных master полный на" бор записей, устанавливающих распределение экстентов базы данных по серверным устройствам. Подробно структура записей таблицы sysusages рассмотрена в главе 12. Здесь лишь отметим, что пря" мая загрузка записей в таблицу sysusages эквивалентна последовательному распространению сегмен" тов базы данных по серверным устройствам командами добавления, удаления и расширения сегментов при условии строгого соблюдения последовательности и содержания команд, использо" ванных при создании структуры сегментов исходной базы данных. Для того чтобы после загрузки в базу данных sybsystemprocs процедура p_dbcreate могла вызыва" ться из любой базы данных, ее имя следует изменить на sp_dbcreate. Если, помимо пользователя 'sa', эта процедура будет применяться пользователями, не являющимися администраторами сервера (и не имеющими роли sa_role в случае SQL Server System 10/11), то после загрузки p_dbcreate в базу данных sybsystemprocs необходимо выполнить команду grant execute on p_dbcreate to public

Ручной вызов процедуры p_dbcreate осуществляется следующим образом: isql Usa $<имя_сервера> Р<sа_пароль> use sybsystemprocs go p_dbcreate <имя_базы_данных> go use sybsystemprocs

go create proc p_dbcreate @dbname varchar(40) as # Первое предложение select генерирует первую строку команды # create database, после чего из таблицы sysusages выбираются

www.books-shop.com

# все записи, относящиеся к создаваемой базе данных, с преобразованием # количества логических страниц каждого экстента базы данных в # число мегабайтов (1 мегабайт = 1024*1024 байт; для системы SunOS # одна страница содержит 2048 байт). # # Для определения названий серверных устройств, содержащих тот или # иной экстент базы данных, используется описанная в главе 12 # процедура сопоставления виртуального номера начальной страницы # vstart каждой записи таблицы sysusages с диапазоном виртуальных # номеров страниц (lowhigh) каждого серверного устройства, # указанного в системной таблице sysdevices. select 'create database ' + @dbname + ' on' select name + '=' + convert (char (4) , (size*2048) / (1024*1024) ) + ',' from master .. sysusages u, master. .sysdevices d where u. vstart >= d.low and u.vstart <= d.high and d.cntrltype=0 and u.dbid=(select dbid from master. .sysdatabases where name=@dbname) order by u.lstart select 'for load' # # # # # # # # # # # #

Теперь перейдем к генерации команд, которые обеспечивают внесение в системную таблицу sysusages изменений, отражающих требуемое размещение сегментов восстанавливаемой базы данных по серверным устройствам. Для этого в поле segmap (битовый массив типов сегментов) каждой записи таблицы sysusages запишем значение этого поля из аналогичной записи исходного сервера. При определении набора записей таблицы sysusages, принадлежащих одному серверному устройству и тем самым имеющих одинаковые значения поля segmap, снова сопоставим виртуальные номера vstart первых страниц записей sysusages с диапазоном виртуальных номеров страниц (lowhigh) каждого серверного устройства, указанного в таблице sysdevices.

select 'update sysusages set segmap=' + convert (char (4) ,u. segmap) + ' where dbid=( select dbid from master . .sysdatabases where name="' + @dbname +

'") and Istart >= ' + convert (char (9) ,lstart) + 'and Istart < ' + convert (char (9) , 1start+size) from master .. sysusages u, master .. sysdevices d where u. vstart >= d.low and u. vstart <= d.high and d.cntrltype=0 # В ходе выполнения генерируемого командного файла мы должны # модифицировать только те строки таблицы sysusages, которые принадлежат • # восстанавливаемой базе данных. Поэтому необходимо проверить поле # идентификатора базы данных dbid каждой записи sysusages и выбрать записи # с нужным идентификатором восстанавливаемой базы данных, который никак # не связан с идентификатором исходной базы данных, расположенной на другом # сервере. Для определения требуемого идентификатора используем

# конструкцию select dbid ... where паше = @dbname. and u.dbid= (select dbid from master . .sysdatabases where name=@dbname) go

www.books-shop.com

Проверка состояния зеркальных пар устройств (хранимая процедура p_mirror) Предлагаемый командный файл создает в базе данных sybsystemprocs хранимую процедуру p_mirror, используемую для проверки состояния (поле status) зеркальных копий всех серверных устройств. Она выдает полный список серверных устройств с указанием имеющихся зеркальных копий и состояния каждого серверного устройства. Процедура p_mirror вызывается из командного файла dump_sys" tables (см. выше) и дает возможность убедиться в том, что все серверные устройства, которым дол" жны были быть назначены зеркальные копии, действительно имеют их. Кроме того, значение поля status позволяет найти зеркальные пары, в которых сервер переключился на одно из зеркальных устройств вследствие отказа другого устройства пары. В подобном случае оба устройства по"прежне" му выдаются процедурой p_mirror, и на отказ одного из них указывает только изменившееся состоя" ние (поле status) этого устройства. Отметим, что в нормальном режиме работы все зарезервированные устройства должны находиться в одном и том же состоянии (это относится и к серверным устройствам, не имеющим зеркальных копий). Как и в предыдущем случае, название процедуры p_mirror следует сменить на sp_mirror, если она должна вызываться из любой базы данных. Для того чтобы процедура p_mirror была доступна пользователям, не являющимся администраторами сервера, после ее загрузки в базу данных sybsystem procs необходимо выполнить команду grant execute on p_mirror to public

Ручной вызов процедуры p_mirror осуществляется следующим образом: isql Usa S<имя_сервера> Р<sа_пароль> use sybsystemprocs go p_mirror go Командный файл на языке SQL, создающий хранимую процедуру p_mirror , приводится ниже. В процессе своей работы эта процедура выбирает название (пате), физический адрес (phyname), ад рес зеркальной копии (mirrarname) и состояние (status) каждого серверного устройства из находящей ся в базе данных master системной таблицы sysdevices. Поскольку нас не интересуют устройства вывода дампов SQL Server, ограничимся распечаткой устройств со значением поля cntrltype = 0. use sybsystemprocs go create procedure p_mirror as select getdate() select @@servername select db_name() select "logical"=substring(name,l,10) , "physical "=substring (phyname, 1,20) , "mirror "=substring(mirrorname, 1,20) , status from master. .sysdevices where cntrltype=0 go Проверка использования дискового пространства серверного устройства (хранимая процедура p_devspace) Данный командный файл записывает в базу данных sybsystemprocs хранимую процедуру p_devspace, выдающую общее дисковое пространство каждого серверного устройства, а также размер используе" мой и свободной области. Подобно процедуре p_mirror, хранимая процедура p_devspace вызыва" ется командным файлом dump_systables. Она также полезна при распространении баз данных на новые серверные устройства и при анализе структуры свободного дискового пространства, имеюще" гося на сервере. Изменение названия процедуры p_devspace на sp_devspace позволит вызывать ее из любой базы данных. Следующая команда сделает процедуру p_devspace доступной для пользователей, не являющихся администраторами сервера:

www.books-shop.com

grant execute on p_devspace to public Ручной вызов процедуры p_devspace осуществляется стандартным образом: isql Usa S<имя_сервера> Р<sа_пароль> use sybsystemprocs

go p_devspace go use sybsystemprocs

go create procedure p_devspace as select device_name = sysdev.name, total_Mb = (sysdev.high # sysdev.low + 1) / 512, used_Mb = sum(sysuse. size) /512, free_Mb = (sysdev.high # sysdev.low + 1)/512 # sum(sysuse. size) /512 into #space_on_devices from sysdevices sysdev, sysusages sysuse where sysdev.cntrltype = 0 and sysuse.vstart between sysdev.low and sysdev.high group by sysdev.name /* теперь проверим все проинициализированные серверные устройства, еще не используемые ни одной базой данных */ insert #space_on_devices select sysdev.name, total_Mb = (sysdev.high # sysdev.low + 1) / 512, used_Mb = 0 , free_Mb = (sysdev.high # sysdev.low + 1) / 512 from sysdevices sysdev, sysusages sysuse where sysdev.cntrltype = 0 and not exists (select * from sysusages sysuse2 where sysuse2.vstart between sysdev.low and sysdev.high) /* выдача итоговых результатов */ select distinct * from #space_on_devices order by device_name compute sum(total_Mb), sum(used_Mb) , sum(free_Mb) return go

www.books-shop.com

Построение списка всех сегментов баз данных, находящихся на всех устройствах сервера (хранимая процедура p_servermap) Приведенный ниже командный файл помещает в базу данных sybsystemprocs хранимую процедуру p_servermap, которая выдает полный список всех сегментов различных баз данных, находящихся на дисковых устройствах сервера. Процедура p_servermap также играет существенную роль при вы" полнении командного файла dump_systables. В ее выдаче последовательно перечисляются все сер" верные устройства, на которых есть хотя бы один сегмент произвольной базы данных, и для каждого такого устройства выдается список всех находящихся на нем сегментов баз данных с указанием кодов и размеров сегментов, а также общего пространства устройства, занятого сегментами баз данных. В сочетании с процедурами p_mirror и p_devspace процедура p_servermap позволяет составить детальную схему использования всего дискового пространства сервера. Отметим, что, поскольку код сегмента уникален только в пределах одной базы данных, для получения информации о названиях по" льзовательских сегментов, соответствующих определенному коду в конкретной базе данных, необхо" димо выполнить следующие команды: Isql *Usa *S<имя_сервера> *Р<sа_пароль> use <имя_базы_данных> до select * from syssegments до Важно подчеркнуть, что процедура p_servermap не сообщает никакой информации о сервер" ных устройствах, которым еще не назначено ни одного сегмента баз данных. Для получения полно" го списка серверных устройств используйте /процедуру p_devspace. Подобно другим хранимым процедурам, изменение названия процедуры p_servermap на sp_servermap позволит вызывать ее из любой базы данных, а следующая команда сделает рассматриваемую процедуру доступной для пользователей, не являющихся администраторами сервера: grant execute on p_servermap to public Порядок ручного вызова процедуры p_servermap: Isql *Usa *S<имя_сервера> *Р<sа_пароль> use sybsystemprocs go p_servermap go use sybsystemprocs go # Сначала получим список серверных устройств. Затем для каждого # устройства выберем из таблицы sysusages необходимую информацию # и поместим ее во временную таблицу #smap. create procedure p_servermap as select device_name =substring( sysdev.name,1,11) , database_name=substring(sysdb.name,1,20), seg#=substring( convert (char (4) , sysuse.segmap),1,4), size_Mb = substring (convert (char(7),sysuse. size/512),1,7) into #smap from sysdevices sysdev, sysdatabases sysdb, sysusages sysuse where sysdev.cntrltype = 0 and sysuse.vstart

www.books-shop.com

between sysdev. low and sysdev.high and sysuse.dbid = sysdb.dbid # # # # #

Используя информацию из таблицы #smap, подведем итог по каждой базе данных, сегменту и коду сегмента на каждом устройстве, сохранив результат в таблице #smap2. Таким образом, мы объединим информацию, которая относится к разрозненным фрагментам одного и того же сегмента, находящимся на одном и том же устройстве.

select device_name,database_name, seg#, space_per_seg=sum( convert (int ,size_Mb) ) into #smap2 from #smap group by device_name,database_name,seg# # # # # # # # # # # # #

Теперь займемся анализом кодов сегментов segmap. Значения segmap в диапазоне от 1 до 7 имеют одинаковый смысл во всех базах данных, в то время как последующие значения указывают на присутствие сегментов, определенных пользователями. Названия этих сегментов можно узнать из таблицы syssegments соответствующей базы данных. Отметим, что в SQL Server System 10 база данных аудита (sybsecurity) содержит сегмент auditsegment с кодом segmap = 8. Поскольку все сегменты sybsecurity должны находиться на одном серверном устройстве вместе с сегментами system (segmap = 1) , default (segmap = 2) и logsegment (segmap =4), поле segmap каждого экстента базы данных sybsecurity получает значение, равное 15 (segmap = 1 + 2 + 4 + 8 ) .

set nocount on select "segmap values 1 through 1 seg# and segment name 1 — system 2 # default 3 — default/system 4 — log only 5 # log/system 6 — log/default 7 # log/system/default 8 — user defined 15 — audit/log/sys/def 16 — user defined" set nocount off # Окончательная выдача производится на основе информации из # временной таблицы #smap2 с одновременным суммированием полного # используемого дискового пространства каждого серверного устройства. select device_name,database_name, seg# , space_per_seg from #smap2 order by device_name,database_name, seg# compute sum(space_per_seg) by device_name return go

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

Выдача дампов баз данных (dumpdb) Командный файл использует возможности сервера архивации Backup Server для записи дампов баз данных на ленту или диск. Разумеется, любой администратор сервера стремится записывать все дам" пы именно на диск, но для этого редко имеется достаточное свободное пространство (чаще всего из"за ошибок на этапе планирования конфигурации сервера). В итоге дампы не очень больших баз данных записываются на диск, но дампы крупных баз данных приходится сохранять непосредственно на ленте. В нашем примере будем считать, что база данных db1 настолько большая, что требует отде" льного тома магнитной ленты; база db2 также слишком велика для записи на диск, и мы сбрасываем ее дамп на одну ленту с дампом базы данных master, а все остальные базы данных можно сохранять в дис" ковых файлах. Напомним, что после записи дампов в дисковые файлы все равно необходимо запи" сать дамп соответствующей файловой системы на ленту. После сохранения дампа базы данных master нужно произвести принудительную очистку ее жур" нала транзакций, поскольку этот журнал нельзя разместить на отдельном серверном устройстве ана" логично журналам транзакций всех других баз данных. В результате журнал транзакций базы данных master не может быть выдан в отдельный дамп, что является стандартной процедурой усече" ния (очистки) обычных журналов транзакций, и для его очистки необходимо выполнить включен" ную в файл dumpdb команду dump transaction с параметром truncate_only. Подобная команда должна выполняться только после сохранения полного дампа базы данных master командой dump database master (см. главу 7). В принципе, нет необходимости производить усечение журнала тран" закций базы данных master после записи каждого ее дампа, но пренебрежение этой операцией при" ведет к переполнению этого журнала и к останову сервера. Подобно командному файлу dumpdb_492 (см. выше), файл dumpdb рассчитан на запуск операто" ром сервера вручную и не предназначен для использования в качестве cron"задания. Участие опера" тора необходимо прежде всего для смены двух томов магнитной ленты, на которые записываются дампы больших баз данных. Аналогично dumpdb_492, имя пользователя и пароль запрашиваются при запуске файла dumpdb в интерактивном режиме. Подразумевается, что пользователь, запустив" ший файл, обладает ролью oper_role, разрешающей сохранять дампы баз данных. Ручной запуск файла dumpdb производится командой

dumpdb <имя_пользователя> <пароль> #!/bin/csh #f umask 006 setenv SERVER PDSOPS21 setenv SYBASE /home/sybase # # # # #

Для перехода к использованию другого ленточного устройства достаточно изменить его номер, присваиваемый переменной TAPEDEVNO. Переменные REWINDINGTAPE и NONREWINDINGTAPE ПОЗВОЛЯЮТ обратиться к ленточному устройству в режимах с автоматической перемоткой к началу и без нее.

setenv TAPEDEVNO 8 setenv REWINDINGTAPE /dev/rst${DEVNO} setenv NONREWINDINGTAPE /dev/nrst${DEVNO} echo #n Enter Your Server Username: set username = $< stty #echo echo #n Enter Your Server Password: set password = $< stty echo clear echo dumpdb:${SERVER}: beginning dump of ${SERVER} system 10 server set dir=/diskdump set outfile=${dir}/${srvname}_dumpdb.out

www.books-shop.com

# # # #

Команда tee, поддерживаемая оболочкой С, записывает в файл копию информации, выдаваемой на устройство стандартного вывода (в данном случае — терминал). Поэтому все появляющиеся на экране сообщения автоматически копируются в файл протокола.

setenv COPYINPUT '/bin/tee #a '${outfile} mt #f ${NONREWINDINGTAPE} rewind # Дамп первой базы данных практически целиком занимает первый том # магнитной ленты. set dbname=db1 echo "dumpdb:${SERVER}: [${dbname}] started at 'date'." > ${outfile} # # # # # # # # #

Записываем на первую ленту дамп базы данных db1. Обратите внимание, что при работе с System 10 в команде dump database необходимо указывать новый параметр capacity=5000000, сообщающий серверу архивации, что емкость устройства записи на ленту составляет 5 Гбайт. Параметр with init указывает серверу архивации на необходимость инициализации тома магнитной ленты (с удалением всей ранее записанной информации). Этот параметр следует использовать только для первого дампа, выдаваемого на том магнитной ленты.

$SYBASE/bin/isgl #U${username} #S${SERVER} #e <
go exit finish_sql_tape1 # При возникновении ошибок во время записи первого дампа # завершаем выполнение файла с кодом возврата 1. if ($status) then echo "dumpdb:${SERVER}: database dump of ${dbname} has FAILED at 'date'." | $COPYINPUT cat ${dbname}_dbdump.out | $COPYINPUT exit(1) else echo "dumpdb: ${SERVER}: dump of ${dbname} completed at 'date'." | $COPYINPUT endif # Перематываем и разгружаем первую ленту. mt #f ${NONREWINDINGTAPE} off # Для продолжения работы просим оператора установить вторую ленту. echo #n "Load 2nd PDSOPS21 server tape. Press return when ready to continue." # "Установите на сервер PDSOPS21 вторую ленту и нажмите return." set waiting = $< echo #n "Are you sure the 2nd tape is loaded? Press return if ready to continue. " # "Если вторая лента действительно установлена, нажмите return."

www.books-shop.com

set waiting = $<

mt #f ${NONREWINDINGTAPE} rewind

# Перемотка ленты к началу

# Записываем на вторую ленту дампы баз данных db2 и master. # Обратите внимание, что при выводе последнего дампа параметр with init # в команде dump database не указывается. set dbname=db2 set dbname2=master echo "dumpdb:${SERVER}: [${dbname}] started at 'date'." | $COPYINPUT $SYBASE/bin/isql #U${username} #S${SERVER} #e <
go dump database ${dbname2} to '${NONREWINDINGTAPE}' capacity=5000000

go dump tran master with truncate_only go exit finish_sgl_tape2 if ($status) then echo "dumpdb:${SERVER}: database dump of $dbname has FAILED at 'date'." | $COPYINPUT cat ${dbname}_dbdump.out | $COPYINPUT else echo "dumpdb:${SERVER}: dump of $dbname completed at 'date'." | $COPYINPUT endif # Перематываем и разгружаем вторую ленту. mt #f ${NONREWINDINGTAPE} off # # # # #

# Перемотка ленты к началу

Переходим к записи дампов оставшихся баз данных в отдельные дисковые файлы, названия которых явно указываются в команде dump database. При работе с SQL Server System 10 нет необходимости использовать специальные серверные устройства вывода дампов.

foreach dbname (db3 db4 db5 db6 db7) echo "dumpdb:${srvname}: [${dbname}] started at 'date'." I $TEE $SYBASE/bin/isgl #U${username} #S${SERVER} #e <
dump database ${dbname} to ''/diskdump/${dbname}_databasedump.out" go exit finish_sql_diskdumpdb if ($status) then

echo "dumpdb:${SERVER}: database dump of $dbname has FAILED at 'date'.# I $COPYINPUT cat ${dbname}_dbdump.out I $COPYINPUT

else echo "dumpdb:${SERVER}: dump of $dbname completed at •date'." I $COPYINPUT

www.books-shop.com

endif # Конец цикла записи дисковых дампов баз данных. end

echo " dumpdb:$ {SERVER}: exiting at 'date'." I $COPYINPUT # Файл протокола отправляется пользователю dba. mail #s "dumpdb:${srvname} : output" dba < $outfile clear exit Загрузка баз данных (loaddb) В отличие от SQL Server 4.9.2, при работе с сервером System 10 нет необходимости использовать спе" циальный командный файл для загрузки дампов с магнитной ленты. Сервер архивации System 10 под" держивает запись нескольких дампов на одну ленту, и при наличии на ленте более одного дампа необходимо явно указать имя ленточного файла в команде загрузки дампа. Помимо названий устройств вывода дампов SQL Server, сервер архивации разрешает указывать в командах записи и за" грузки дампов физические адреса устройств или имена дисковых и ленточных файлов. Перед загруз" кой дампов с незнакомой ленты выполните команду load database db1 with listonly Она выдает список всех дампов, имеющихся на установленном в устройстве томе магнитной лен" ты, с указанием имени каждого ленточного файла. Отметим, что при отсутствии имени ленточного файла в команде записи дампа на ленту сервер сам сгенерирует произвольное имя, включающее в себя порядковый номер дня в году и количество секунд, истекшее после полуночи. Поскольку выби" раемое сервером имя трудно предугадать заранее, его следует узнать из выдаваемой сервером ин" формации о ходе создания дампа или из полного списка ленточных файлов, получаемого с помощью представленной выше команды. Для автоматизации процесса записи и загрузки дампов в командном файле dumpdb рекомендует" ся явно указывать имена ленточных файлов в виде параметра file= 'имя_файла' команды dump database. Тогда в командном файле загрузки дампов можно будет использовать оператор выбора switch, позволяющий по имени базы данных определить имя ленточного файла с ее дампом. Разуме" ется, здесь придется поддерживать строгое соответствие между командными файлами записи дам" пов и их загрузки. Отслеживание хода загрузки дампа базы данных (хранимая процедура p_dbload) Рассматриваемый в этом разделе командный файл создает в базе данных sybsystemprocs хранимую про" цедуру p_dbload, которая сообщает количество мегабайтов, загруженное каждой командой загрузки базы данных при выполнении процедуры p_dbload. Несмотря на свою простоту, эта процедура очень полезна при работе с большими базами данных, загрузка которых способна растянуться на дли" тельное время. Рекомендуем сделать процедуру p_dbload доступной для всех пользователей, выпол" нив команду grant execute on p_dbload to public Кроме того, изменение имени процедуры на sp_dbload позволит вызывать ее из любой базы данных. Пример вызова процедуры p_dbload в ручном режиме: isql *Usa *$<имя_сервера> *Р<sа_пароль> use sybsystemprocs go p_dbload go Командный файл на языке SQL, создающий хранимую процедуру p_dbload, выглядит так: Use sybsystemprocs

go

www.books-shop.com

create procedure p_dbload as # # # #

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

select spid,cmd,(convert(int,physical_iO))*2048/(1024*1024) "Mb loaded" from master..sysprocesses where cmd="LOAD DATABASE" go

Ниже представлен пример использования процедуры p_dbload, показывающий динамику про цесса загрузки дампа базы данных. trainwreck% isgl #Usa #SPSYCHO_DB Password: 1> p_dbload 2> go

spid 1

cmd LOAD DATABASE

Mb loaded .

60

Time Apr 01 1996 11:59AM

(1 row affected, return status = 0) 1> p_dbload 2> go spid cmd Mb loaded 1

LOAD DATABASE

62

Time Apr 01 1996 12:00PM

(1 row affected, return status = 0) 1> p_dbload 2> go spid cmd Mb loaded 1

LOAD DATABASE

103

Time Apr 01 1996 12:04PM

(1 row affected, return status = 0) Командный файл запуска сервера Представим пример командного файла, запускающего SQL Server 11.O.l. #!/bin/sh #

# SQL Server Information: # имя сервера:

PSYCHO11

# адрес устройства master: /dev/rdsk/cOt2dOs7 # размер устройства master: 10752 # журнал регистрации ошибок: /home/sybase/11.О.1/install/errorlog # файл интерфейсов: /home/sybase/11.0.1 # /home/sybase/11.0.1/bin/dataserver #d/dev/rdsk/cOt2dOs7 #sPSYCHOll \ #e/home/sybase/11.0.l/install/errorlog_PSYCHOll #i/home/sybase/11.0.1 Следующий командный файл используется для запуска сервера архивации Backup Server ll.O.l #!/bin/sh # # Backup Server Information: # имя сервера:

PSYCHO11_BCK

# # # #

/home/sybase/11.О.I/install/backup.log /home/sybase/11.0.I/interfaces

журнал регистрации ошибок: файл интерфейсов: местонахождение программы multibuf:

/home/sybase/11.О.1/bin/sybmultbuf

# язык:

us_english

# набор символов:

iso_l

# конфигурационный файл # ленточных устройств:

/home/sybase/11.О.l/backup_tape.cfg

www.books-shop.com

# # /home/sybase/ll.O.l/bin/backupserver "SPSYCHO11_BCK \ "e/home/sybase/11 . О . 1 /install /backup. log "I/home/sybase/11 . 0 . 1/interfaces \ "M/home/sybase/11 .0 . 1/bin/sybmultbuf "Lus_english "Jiso_l \ "c/home/sybase/11 .0 .l/backup_tape.cfg Командные файлы эксплуатации SQL Server System 11 Второй комплект командных файлов обеспечивает сопровождение и контроль за функционировани" ем промышленно эксплуатируемого сервера System 11. После внесения минимальных изменений эти командные файлы можно использовать и для работы с серверами версии 4.9.2 или System 10. Однако при рассмотрении второй группы файлов предполагается применение именно SQL Server System 11. Все командные файлы этой группы имеют одинаковую структуру. Для обеспечения максимальной пе" реносимости на другие платформы они ориентированы на оболочку Bourne. Каждый командный файл независим от остальных и не вызывает других файлов в процессе своей работы, хотя коман" дный файл выдачи конфигурации сервера использует ряд хранимых процедур, рассмотренных выше. Во всех случаях мы опираемся только на стандартные команды системы UNIX и SQL Server, не прибе" гая к использованию sed, awk или perl. Надеемся, что это значительно облегчит чтение и модифи" кацию командных файлов, приведенных в книге. Во всех случаях предполагается, что пароль пользователя 'sa' хранится в файле . kparm (ответст" венность за его создание лежит на вас). Права доступа, установленные для этого файла, должны по" зволять его чтение только пользователям, которые действительно являются администраторами сервера. Обычно данный файл должен быть доступен только UNIX"пользователю Sybase. Скорее все" го, перед запуском командных файлов вам придется внести изменения в указанные в них полные пути к каталогам, содержащим этот и другие необходимые файлы. Те места в файлах, где могут по" требоваться изменения, отмечены последовательностью из пяти звездочек (*****). Дампы баз данных System 11 (dump_listof_dbs) Командный файл dump_listof_dbs записывает дампы одной или нескольких баз данных в дисковые файлы. Перед записью дампа этот файл создает временную хранимую процедуру, которая фактиче" ски и осуществляет сохранение дампа. Подобный прием позволяет отследить возможные ошибки, возникающие в процессе записи дампов. Если бы сохранение дампов выполнялось бы непосредствен" но из утилиты isgl, то командный файл мог бы проанализировать только код возврата, выданный isgl. Однако нулевой код возврата isql указывает на успешное завершение работы самой утилиты isql, но не на полное выполнение сервером всех направленных ему команд. Применение же времен" ной хранимой процедуры позволяет непосредственно проконтролировать код возврата команды dump database и при наличии ошибок выслать администратору сервера соответствующее сообще" ние. Каждый дамп базы данных сохраняется в отдельном дисковом файле, имя которого включает в себя имя базы данных, а также дату и время записи дампа. Подчеркнем, что здесь применяется пря" мая запись дампа в файл с указанным именем, поддерживаемая сервером архивации System 10 и 11. Для использования командного файла dump_listof_dbs с SQL Server 4.9.2 необходимо включить в этот файл команды, создающие временное серверное устройства вывода дампов перед сохранением дампа, а затем удаляющие это устройство по завершении записи дампа. #!/bin/sh # # Командный файл для оболочки Bourne , который записывает на # диск дампы баз данных, перечисленных при вызове этого файла. # 30.8.96 Брайан Хичкок # if [ $# #lt 2 ] then echo $0: invalid format: $# argv parameters provided, at least 2

required # требуется как минимум 2 аргумента echo $0: required format: $0 ' <SERVER> ' exit 1 27—2221

www.books-shop.com

fi # # Параметры инициализации # # ***** Установите правильные значения # переменных SYBASE и PWD. SYBASE=/export/home/Sybase SERVER=$1 PWD='cat /export/home/sybase/.kparm' # ***** укажите каталог для файлов дампов. dumpdir=/export/home/dbdump outfile=${dumpdir}/${SERVER}_dumpdb.out outfile2=${dumpdir}/${SERVER}_dumpdb.out2 shift dbs_to_dump ="$ *"

# # Приступаем к выводу дампов. # echo "database dump:$(SERVER}: started at 'date'." > $outfile echo "database dump:${SERVER}: started at 'date'." > $outfile2 echo " " >> $outfile echo " " >> $outfile2 # # Начало цикла по всем указанным в командной строке базам данных. # for dbname in $dbs_to_dump do dmptime='date +%m%d%y_%H%M%S' dumpfi1e=${SERVER}_${dbname}_${dmptime}.dmp proc_name=dump_temp_sproc_${dmptime} # ***** укажите полное имя утилиты isql и полное имя файла интерфейсов. # Ниже начинается командный файл на языке SQL, создающий временную # хранимую процедуру, которая осуществляет фактическую запись дампа # очередной базы данных. Этот прием позволяет обнаружить ошибки # во время выполнения команды dump database. # ***** при работе с SQL Server 4.9.2 вместо конструкции # ${dumpdir}/${dumpfile} необходимо указать название одного # из серверных устройств вывода дампов. # # Вызываем утилиту isql и подключаемся к SQL Server. # $SYBASE/bin/isgl #Usa #S${SERVER} #P${PWD} #I$SYBASE/interfaces #e >> ${outfile} << finish_sql create procedure $proc_name as declare @status int dump database $dbname to '${dumpdir}/${dumpfile}' go declare @return_status int execute @return_status=$proc_name drop procedure $proc_name if @return_status = 0 begin print "************************************************" print "Stored Procedure Execution Complete — no errors" #print "Успешное завершение хранимой процедуры" end else begin

www.books-shop.com

print "!!!!!!!!!!!!!!!!!!!!!!!!!!!" print "FAILURE of Stored Procedure" #print "НЕНОРМАЛЬНОЕ завершение хранимой процедуры" end go exit finish_sgl # # Сохраняем код возврата программы isql. Ненулевой код возврата # указывает на наличие проблем при подключении к серверу из#за # неправильно указанного пароля, имени файла интерфейсов или из#за # неработоспособности сервера. # isql_status=$< # # Сохраняем код возврата SQL#файла, создававшего и выполнявшего # хранимую процедуру. # sproc_status= ' tail #l ${outfile}' # # Если программа isql завершилась с ненулевым кодом возврата: # if [ $isql_status #ne 0 ] then echo " " >> $outfile echo database dump: $ {SERVER }: isql for dump of $dbname failed at 'date' >> $outfile echo " " >> $outfile echo " " >> $outfile2 echo database dump: $ {SERVER }: database dump of $dbname failed at 'date' >> $outfile2 echo " " >> $outfile2 # ***** Укажите правильный электронный адрес администратора сервера. /usr/ucb/mail #s "${SERVER}: database dump of $dbname failed" psychoDBA@dbahost < $outfile # # В случае успешного завершения isql проверяем код возврата # хранимой процедуры. # else # # Если хранимая процедура завершилась успешно: # if [ "$sproc_status" = "Stored Procedure Execution Complete # no errors" ] then echo " " >> $outfile echo database dump :$ {SERVER }: completed database dump of $dbname at 'date' >> $outfile echo " " >> $outfile2 echo database dump: ${SERVER}: completed database dump of $dbname at 'date' >> $outfile2 fi # # Если хранимая процедура завершилась с ненулевым кодом возврата: #

if [ "$sproc_status" = "FAILURE of Stored Procedure" ] then echo " " >> $outfile echo database dump :${SERVER}: sproc for database dump $dbname failed

www.books-shop.com

at 'date' >> $outfile /usr/ucb/mail #s "${SERVER}: database dump of $dbname failed" psychoDBA@dbahost < $outfile echo " " >> $outfile2 echo database dump:$(SERVER}: sproc for database dump $dbname failed at 'date' >> $outfile2 fi fi # # Конец цикла по именам баз данных # done # # Записываем файл протокола в конец основного выходного файла и # посылаем основной файл администратору сервера. # echo " " >> $outfile echo "database dump:${SERVER}: exiting at 'date'." >> $outfile echo " " >> $outfile echo " " >> $outfile2 echo " " >> $outfile2 echo "database dump:${SERVER}: exiting at 'date'." >> $outfile2 echo " " >> $outfile2 echo " " >> $outfile2 echo "******************************************************<< >> $outfile2 cat $outfile >> $outfile2 # ***** укажите правильный электронный адрес администратора сервера. /usr/ucb/mail #s "${SERVER}: database dump cronjob complete" psychoDBA@dbahost < $outfile2 exit Выдача дампов журналов транзакций (logdump_listof_dbs) Командный файл 1ogdump_listоf_dbs записывает на диск дампы журналов транзакций одной или нескольких баз данных. Каждый дамп журнала транзакций сохраняется в отдельном файле с именем, определяемым датой и временем записи дампа, а также именем самой базы данных. Здесь мы опира емся на возможности сервера архивации, входящего в состав SQL Server System 10 и 11. При исполь зовании командного файла logdump_listof_dbs с SQL Server 4.9.2 в генерируемую этим файлом хранимую процедуру необходимо включить команды создания временного серверного устройства вы вода дампов перед записью каждого дампа и удаления этого устройства по окончании записи дампа. #!/bin/sh # # Командный файл для оболочки Bourne, который записывает на диск дампы # журналов транзакций баз данных, перечисленных при вызове этого файла. # 6.9.96 Брайан Хичкок # if [ $# #lt 2 ] then echo $0: invalid format: $# argv parameters provided, at least 2 required # требуется как минимум 2 аргумента echo $0: required format: $0 '<SERVER> ' exit, 1 fi # # Параметры инициализации # # ***** Установите правильные значения

www.books-shop.com

Командные файлы # переменных SYBASE и PWD. SYBASE=/export/home/Sybase SERVER=$1

PWD='cat /export/home/Sybase/.kparm' # ***** укажите каталог для вывода дампов. durnpdir=/export/home/dbdump outfile=${dumpdir}/${SERVER}_dumplog.out outfile2=${dumpdir}/${SERVER}_dumplog.out2 shift dbs_to_logdump="$*° # # Приступаем к выводу дампов. # echo "transaction log dump:${SERVER}: started at 'date'." > $outfile echo "transaction log dump:${SERVER}: started at 'date'." > $outfile2 echo " " >> $outfile echo " " >> $outfile2 # # Начало цикла по всем базам данных, указанным в командной строке # for dbname in $dbs_to_logdump do dmptime='date +%m%d%y_%H%M%S' dumpfile=${SERVER}_${dbname}_${dmptime}_log.dmp proc_name=dlog_temp_sproc_${dmptime} # ***** Укажите полное имя утилиты isgl и полное имя файла интерфейсов. # Ниже начинается командный файл на языке SQL, создающий временную # хранимую процедуру, которая осуществляет фактическую запись дампа # журнала транзакций очередной базы данных. Этот прием позволяет # обнаружить ошибки во время выполнения команды dump transaction. # ***** при работе с SQL Server 4.9.2 вместо конструкции # ${dumpdir}/${dumpfile} необходимо указать название одного # из серверных устройств вывода дампов. # # Вызываем утилиту isql и подключаемся к SQL Server. # $SYBASE/bin/isql #Usa #S${SERVER) #P${PWD} #I$SYBASE/interfaces #e >> ${outfile} << finish_sgl create procedure $proc_name as declare @status int dump tran $dbname to '${dumpdir}/${dumpfile}'

go

declare @return_status int execute @return_status=$proc_name drop procedure $proc_name if @return_status=0 begin print "************************************************" print "Stored Procedure Execution Complete — no errors" #print "Успешное завершение хранимой процедуры" end else begin print "!!!!!!!!!!!!!!!!!!!!!!!!!!!" print "FAILURE of Stored Procedure" #print "НЕНОРМАЛЬНОЕ завершение хранимой процедуры" end

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

399

до exit finish_sql # # Сохраняем код возврата программы isql. Ненулевой код возврата # указывает на наличие проблем при подключении к серверу из#за # неправильно указанного пароля, имени файла интерфейсов или из#за # неработоспособности сервера. # isql_status=$< # # Сохраняем код возврата SQL#файла, создававшего и выполнявшего # хранимую процедуру. # sproc_status='tail #1 ${outfile}' # # Если программа isql завершилась с ненулевым кодом возврата: # if [ $isql_status #ne 0 ] then echo " " >> $outfile echo database 1ogdump:${SERVER}: isql for logdump of $dbname failed at 'date' >> $outfile echo " " >> $outfile echo " " >> $outfile2 echo database logdump:${SERVER}: database logdump of $dbname failed at 'date'>> $outfile2 echo " " >> $outfile2 # ***** Укажите правильный электронный адрес администратора сервера. /usr/ucb/mail #s "${SERVER}: database logdump of $dbname failed" psychoDBA@dbahost < $outfile # # В случае успешного завершения isql проверяем код возврата # хранимой процедуры. # else # # Если хранимая процедура завершилась успешно: # if [ "$sproc_status" = "Stored Procedure Execution Complete # no errors" ] then echo " " >> $outfile echo database logdump:${SERVER}: completed database logdump of $dbname at 'date' >> $outfile echo " " >> $outfile2 echo database logdump:${SERVER}: completed database logdump of $dbname at 'date' >> $outfile2 fi # # Если хранимая процедура завершилась с ненулевым кодом возврата: # if [ "$sproc_status" = "FAILURE of Stored Procedure" ] then echo " " >> $outfile echo database 1ogdump:${SERVER}: sproc for database logdump $dbname failed at 'date' >> $outfile # ***** Укажите правильный электронный адрес администратора сервера. /usr/ucb/mail #s "${SERVER}: database logdump of $dbname failed" psychoDBA@dbahost < $outfile

www.books-shop.com

echo " " >> $outfile2 echo database logdump:${SERVER}: sproc for database logdump $dbname failed at 'date' >> $outfile2 fi fi # # Конец цикла по именам баз данных # done # # Записываем файл протокола в конец основного выходного файла и # посылаем основной файл администратору сервера. # echo " " >> $outfile echo "database logdump:${SERVER}: exiting at 'date'." >> $outfile echo " " >> $outfile echo " " >> $outfile2 echo " " >> $outfile2 echo "database logdump:${SERVER}: exiting at 'date'." >> $outfile2 echo " " >> $outfile2 echo n" " >> $outfile2 echo ******************************************************" >> $outfile2 cat $outfile >> $outfile2 # ***** Укажите правильный электронный адрес администратора сервера, /usr/ucb/mail #s "${SERVER}: database logdump cronjob complete" psychoDBA@dbahost < $outfile2 exit Принудительная очистка журнала транзакций (trunclog_listof_dbs) Следующий командный файл выполняет принудительное усечение журналов транзакций одной или нескольких баз данных. Напомним, что журналы транзакций, вынесенные на отдельное серверное устройство, очищаются при каждом сохранении их дампoв. Однако SQL Server не поддерживает запи си дампов журналов транзакций, расположенных вместе с другими сегментами базы данных, что за ставляет периодически выполнять принудительное усечение журналов транзакций для предотвращения их переполнения. Хотя базу данных можно перевести в режим, когда журнал тран закций автоматически очищается при создании каждой контрольной точки, случайное отключение этого режима приведет к постепенному заполнению журнала транзакций, угрожающему его перепол нением. Обязательно проверьте, что каждая база данных вашего сервера (за исключением базы дан ных tempdb, всегда работающей в режиме очистки журнала транзакций при создании контрольной точки) регулярно обрабатывается командным файлом logdump_listof_dbs или trunclog_lis tof_dbs. !/bin/sh # # Командный файл для оболочки Bourne, который очищает журналы # транзакций баз данных, перечисленных при вызове этого файла. # 6.9.96 Брайан Хичкок # if [ $# #lt 2 ] then echo $0: invalid format: $# argv parameters provided, at least 2 required # требуется как минимум 2 аргумента

echo $0: required format: $0 '<SERVER> ' exit 1 fi #

www.books-shop.com

# Параметры инициализации # # ***** Установите правильные значения # переменных SYBASE и PWD. SYBASE= /export /home /Sybase SERVER=$1 PWD= ' cat /export /home /sybase/.kparm' # ***** Укажите каталог для файлов дампов. dumpdir=/export /home/dbdump outfile=${dumpdir}/${SERVER}_trunclog.out outfile2=${dumpdir}/${SERVER}_trunclog.out2 shift dbs_to_trunclog= " $* " # # Приступаем к выдаче команд dump transaction. # echo "transaction log truncate: $ {SERVER} : started at 'date'." > $outfile echo "transaction log truncate: $ {SERVER} : started at 'date'." > $outfile2 echo " " >> $outfile echo " " >> $outfile2 # # Начало цикла по всем указанным в командной строке базам данных # for dbname in $dbs_to_trunclog do dmptime='date +%m%d%y_%H%M%S' dumpfile=${SERVER}_${dbname}_${dmptime}_log.dmp proc_name=tlog_temp_sproc_${dmptime} # ***** Укажите полное имя утилиты isgl и полное имя файла интерфейсов. # Ниже начинается командный файл на языке SQL, создающий временную # хранимую процедуру, которая осуществляет фактическую очистку журнала # транзакций очередной базы данных. Этот прием позволяет обнаружить # ошибки во время выполнения команды dump transaction. Поскольку # в наши планы не входит фактическая запись дампов, указывать # название устройства вывода дампов или имя файла дампа здесь # не требуется. # # Вызываем утилиту isgl и подключаемся к SQL Server. # $SYBASE/bin/isgl #Usa #S$ {SERVER} #P${PWD} #I$SYBASE/interfaces #e >> ${outfile} << finish_sgl create procedure $proc_name as declare ©status int dump tran $dbname with truncate_only go declare @return_status int execute ireturn_status=$proc_name drop procedure $proc_name if @return_status = 0 begin print "************************************************" print "Stored Procedure Execution Complete — no errors"

#print "Успешное завершение хранимой процедуры" end else begin

www.books-shop.com

print "I!!!!!!!!!!!!!!!!!!!!!!!!!!" print "FAILURE of Stored Procedure" #print "НЕНОРМАЛЬНОЕ завершение хранимой процедуры" end go exit finish_sql # # Сохраняем код возврата программы isql. Ненулевой код возврата # указывает на наличие проблем при подключении к серверу из#за # неправильно указанного пароля, имени файла интерфейсов или из#за # неработоспособности сервера. # isql_status=$< # # Сохраняем код возврата SQL#файла, создававшего и выполнявшего # хранимую процедуру. # sproc_status='tail #l ${outfile}' # # Если программа isql завершилась с ненулевым кодом возврата: # if [ $isql_status #ne 0 ] then echo " " >> $outfile echo transaction log truncate:$(SERVER): isql for logtrunc of $dbname failed at 'date' >> $outfile echo " " >> $outfile echo " " >> $outfile2 echo transaction log truncate:${SERVER}: database logtrunc of $dbname failed at 'date' >> $outfile2 echo " " >> $outfile2 # ***** Укажите правильный электронный адрес администратора сервера. /usr/ucb/mail #s "${SERVERJ: transaction log truncate of $dbname failed" psychoDBA@dbahost < $outfile # # В случае успешного завершения isql проверяем код возврата # хранимой процедуры. # else # # Если хранимая процедура завершилась успешно: # if [ "$sproc_status" = "Stored Procedure Execution Complete — no errors" then echo " " >> $outfile echo transaction log truncate:${SERVER}: completed database logtrunc of $dbname at 'date' >> $outfile echo " " >> $outfile2 echo transaction log truncate:${SERVER}: completed database logtrunc of $dbname at 'date' >> $outfile2 fi # # Если хранимая процедура завершилась с ненулевым кодом возврата: #

if [ "$sproc_status" = "FAILURE of Stored Procedure" ] then echo " " >> $outfile echo transaction log truncate:${SERVER}: sproc for database logtrunc

www.books-shop.com

$dbname failed at 'date' >> $outfile # ***** укажите правильный электронный адрес администратора сервера, /usr/ucb/mail #s "${SERVER}: transaction log truncate of $dbname failed" psychoDBA@dbahost < $outfile echo • " >> $outfile2 echo database dump:${SERVER}: sproc for database logtrunc $dbname failed at 'date' >> $outfile2 fi fi # # Конец цикла по именам баз данных # done

# # Записываем файл протокола в конец основного выходного файла и # посылаем основной файл администратору сервера. # echo * * >> $outfile echo "transaction log truncate:${SERVER}: exiting at 'date'." >> $outfile echo " " >> $outfile echo " " >> $outfile2 echo " " >> $outfile2 echo "transaction log truncate:${SERVER}: exiting at 'date'." >> $outfile2 echo " " >> $outfile2 echo " " >> $outfile2 echo "******************************************************>> >> $outfile2 cat $outfile >> $outfile2 # ***** Укажите правильный электронный адрес администратора сервера, /usr/ucb/mail #s "${SERVER}: transaction log truncate cronjob complete" psychoDBA@dbahost < $outfile2 exit

Удаление старых файлов (remove_old_files) Командный файл remove_old_f iles удаляет с диска файлы, возраст которых превышает указанное при его вызове количество дней. Данный файл предназначен прежде всего для автоматического уда ления с диска устаревших дампов баз данных и журналов транзакций, что позволяет избежать пере полнения файловой системы. Предположим, что каждый вечер вы сохраняете на ленте полную копию файловой системы серверной машины стандартными средствами архивации системы UNIX. Тогда по завершении записи ленты вполне можно использовать файл remove_old_files для удале ния всех дампов, которые старше двух дней (и благодаря этому уже находятся как минимум на двух разных лентах). #!/bin/sh #

# Командный файл для оболочки Bourne, удаляющий с диска # файлы дампов, возраст которых превышает X дней # 11.9.96 Брайан Хичкок # if. [ $# #lt 2 ] then echo $0: invalid format: $# argv parameters provided, at least 2 required # требуется как минимум 2 аргумента echo $0: required format: $0 '<"/path/filename pattern to remove"> ' exit 1

www.books-shop.com

fi # # Параметры инициализации # remove_file=$l days_old=$2 # ***** укажите каталог для файлов дампов dumpdir=/export/home/dbdump outfile=${dumpdir}/remove_flies.out outfile2=${dumpdir}/remove_flies.out2 # # Начало работы # echo "remove old files ${remove_file}: started at 'date'." > $outfile echo "remove old files ${remove_file}: started at 'date'." > $outfile2 echo " " >> $outfile echo " " >> $outfile2 # # Построим список удаляемых файлов # find ${remove_file) #mtime +${days_old} #a #exec ls #1 {} \; >> $outfile # # Вычислим количество найденных файлов... # num_files='find ${remove_file} #mtime +${days_old) #exec ls #1 {} \;

wc

#1'

#

# ... и удалим их с диска # find ${remove_file} #mtime +${days_old} #a #exec rm #rf {} \; # # Если указанного каталога с удаляемыми файлами не существует: # remove_dir='dirname "${remove_file}"' if [ ! #d "${remove_dir}" ] then echo " " >> $outfile echo remove old files ${remove_file}: find failed at 'date'. >> $outfile echo " > directory not found!" >> $outfile echo " " >> $outfile echo " " >> $outfile2 echo remove old files ${remove_file}: find failed at 'date'. >> $outfile2 echo " > directory not found!" >> $outfile2 echo " " >> $outfile2 # ***** Укажите правильный электронный адрес администратора сервера /usr/ucb/mail #s "${SERVER> remove old files ${remove_file} failed" psychoDBA@dbahost < $outfile #

# Если указанный каталог существует: # else #

www.books-shop.com

# Выдаем количество удаленных файлов # echo " " >> $outfile echo remove old files ${remove_file}: number of files deleted = ${num_files} >> $outfile echo " " >> $outfile2 echo remove old files ${remove_file}: number of files deleted = ${num_files} >> $outfile2 fi # Записываем файл протокола в конец основного выходного файла и # посылаем основной файл администратору сервера # echo " " >> $outfile echo "remove old files ${remove_file}: exiting at 'date'." >> $outfile echo " " >> $outfile echo " " >> $outfile2 echo " " >> $outfile2 echo "remove old files ${remove_file}: exiting at 'date'." >> $outfile2 echo " " >> $outfile2 echo " " >> $outfile2 echo "******************************************************• >> $outfile2 cat $outfile >> $outfile2 # ***** Укажите правильный электронный адрес администратора сервера /usr/ucb/mail #s "${SERVER} remove old files ${remove_file} cronjob complete" psychoDBA@dbahost < $outfile2 exit Обновление статистики оптимизатора (update_listof_dbs) Этот командный файл выполняет команды update statistics и sp_recompile по отношению к каждой таблице одной или нескольких баз данных. Из выдачи файла update_listоf _dbs можно уз нать, какое время потребовалось на обработку каждой таблицы. #!/bin/sh # # Командный файл для оболочки Bourne, который выполняет # команды update statistics и sp_recompile для всех таблиц баз # данных, перечисленных при его вызове. # 18.10.96 Брайан Хичкок # if [ $# #lt 2 ] then echo $0: invalid format: $# argv parameters provided, at least 2 required # требуется как минимум 2 аргумента echo $0: required format: $0 '<SERVER> ' exit 1 fi # # Параметры инициализации # # ***** Установите правильные значения

# переменных SYBASE и PWD. SYBASE=/export/home/sybase SERVER=$1 PWD='cat /export/home/sybase/.kparm'

www.books-shop.com

# ***** Укажите каталог для файлов дампов. dumpdir= /export/home/dbdump outfile=$ {dumpdir}/${SERVER}_updatestats.out outfile2=${dumpdir}/${SERVER}_updatestats.out2 tempfile=${dumpdir}/${SERVER}_updatestats.tempi shift dbs_to_update="$*" # # Приступаем к обновлению статистики. # echo "update statistics:${SERVER}: started at 'date'." > $outfile echo "update statistics:${SERVER}: started at 'date'." > $outfile2 echo " " >> $outfile echo " " >> $outfile2 # # Начало цикла обработки каждой базы данных # for dbname in $dbs_to_update do # # Для выполнения цикла по всем таблицам базы данных необходимо # составить полный список имеющихся пользовательских таблиц. # $SYBASE/bin/isql #Usa #S$ {SERVER} #P${PWD} #I$SYBASE/interfaces #e > ${tempfile} << finish_sqll use $dbname go select name from sysobjects where type="U" order by name go finish_sgll # # Выдаем список всех таблиц текущей базы данных # echo " " >> $outfile echo "@@@@@§@@@@@@@@@@@@@@@@@@" >> $outfile echo "all tables in database $dbname...." >> $outfile echo "@@@@@@@@@@@@@@@@@@@@@@>> >> $outfile echo " " >> $outfile cat ${tempf ile} >> $outfile echo " " >> $outfile # # Из списка пользовательских таблиц удаляем четыре первые и две # последние строки. # Описание приведенных ниже команд дается в # командном файле dump_db_create. # num_lines= ' wc #l ${tempfile} I cut #cl#9' last_line= 'expr $num_lines # 4' first_line= 'expr $last_line # 2' tables_list=' tail #$last_line $ {tempfile} I head #$first_line' rm #f $ {tempfile} # # Переходим к обновлению статистики по каждой таблице базы данных # и к повторной компиляции всех объектов сервера#, использующих # эту таблицу . # echo "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" >> $outfile echo "updating statistics for tables in database $dbname" >> $outfile echo "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" >> $outfile

www.books-shop.com

echo " " >> $outfile # # Начало цикла обработки каждой таблицы текущей базы данных # for table_name in $tables_list do $SYBASE/bin/isgl #Usa #S${SERVER} #P${PWD} #I$SYBASE/interfaces #e >> ${outfile} << finish_sql2 use $dbname

go select getdate()

go update statistics $table_name

go sp_recompile $table_name go select getdateO go finish_sql2 #

# Первый оператор done завершает цикл просмотра таблиц базы данных, # а второй done # цикл просмотра всех баз данных сервера. # done #

# Конец цикла обработки баз данных # done # # Записываем файл протокола в конец основного выходного файла и # посылаем основной файл администратору сервера. # echo " " >> $outfile echo "update statistics:${SERVER}: exiting at 'date'." >> $outfile echo " " >> $outfile echo " " >> $outfile2 echo " " >> $outfile2 echo "update statistics:${SERVER}: exiting at 'date'." >> $outfile2 echo " " >> $outfile2 echo " " >> $outfile2 echo "******************************************************>> >> $outfile2 cat $outfile >> $outfile2 # ***** Укажите правильный электронный адрес администратора сервера, /usr/ucb/mail #s "${SERVER}: update statistics cronjob complete" psychoDBA@dbahost < $outfile2 exit

Выполнение dbccпроверок (dbcc_listof_dbs) Командный файл dbcc_listof_dbs выполняет полный набор dbccпроверок одной или нескольких баз данных командами dbcс checkdb, dbcc checkalloc и dbс checkcatalog, выдача которых записывается на диск, а затем проверяется командным файлом на наличие ошибок. Перед завершени ем своей работы файл dbcc_listof_dbs высылает администратору сервера количество найденных ошибок и сообщения о них, а затем полный протокол выполнения dbccпроверок. #!/bin/sh # # Командный файл для оболочки Bourne, который выполняет

www.books-shop.com

# dbcc #проверки баз данных, перечисленных при его вызове. # 9.9.96 Брайан Хичкок #

if [ $# #lt 2 ] then echo $0: invalid format: $# argv parameters provided, at least 2 required # требуется как минимум 2 аргумента echo $0: required format: $0 '<SERVER> ' exit 1 fi # # Параметры инициализации # # ***** Установите правильные значения # переменных SYBASE и PWD. SYBASE=/export /home/sybase SERVER=$1 PWD='cat /export/home/sybase/.kparm' # ***** Укажите каталог для файлов дампов. dumpdir=/export/home/dbdump outfile=${dumpdir}/${SERVER}_dbcclog.out outfile2=${dumpdir}/${SERVER}_dbcclog.out2 outfile3=${dumpdir}/${SERVER}_dbcclog.out3 outfile4=${dumpdir}/${SERVER}_dbcclog.out4 shift dbs_to_dbcc="$*" # # Приступаем к проверкам. # echo "dbcc log:${SERVER}: started at 'date'." > $outfile echo "dbcc log:${SERVER}: started at 'date'." > $outfile2 echo " " >> $outfile echo " " >> $outfile2 # # Начало цикла по всем проверяемым базам данных # for dbname in $dbs_to_dbcc do dmptime='date +%m%d%y_%H%M%S' proc_name=dbcc_temp_sproc_${dmptime} # ***** Укажите полное имя утилиты isql и полное имя файла интерфейсов. # Ниже начинается командный файл на языке SQL, создающий временную # хранимую процедуру, которая осуществляет фактическую проверку # очередной базы данных. Этот прием позволяет обнаружить ошибки # во время выполнения команды dbcc. # # Вызываем утилиту isql и подключаемся к SQL Server. # $SYBASE/bin/isql #Usa #S${SERVER} #P${PWD} #I$SYBASE/interfaces #e > ${outfile3} << finish_sql create procedure $proc_name as declare @status int select getdate() dbcc checkdb($dbname) select getdate() dbcc checkalloc($dbname) select getdate() dbcc checkcatalog($dbname) go

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

declare @return_status int execute @return_status=$proc_name drop procedure $proc_name if @return_status = 0 begin print ************************************************** print "Stored Procedure Execution Complete # no errors" #print "Успешное завершение хранимой процедуры" end else begin print "!!!!!!!!!!!!!!!!!!!!!!!!!!!" print "FAILURE of Stored Procedure" #print "НЕНОРМАЛЬНОЕ завершение хранимой процедуры" end

go exit finish_sql # # Сохраняем код возврата программы isql. Ненулевой код возврата # указывает на наличие проблем при подключении к серверу из#за # неправильно указанного пароля, имени файла интерфейсов или из#за # неработоспособности сервера. # isql_status=$< # # Начинаем анализ выдачи команд dbcc при проверке текущей базы # данных. Нас интересуют сообщения о ошибках. # Msg_count='grep Msg ${outfile3} | wc #1' grep Msg ${outfile3) > ${outfile4} DBlib_COunt='grep DB#LIBRARY ${outfile3} | wc #l' grep DB#LIBRARY ${outfile3) >> ${outfile4} Error_count='expr $Msg_count + $DBlib_count' echo $Error_count # # Сохраняем код возврата SQL#файла, создававшего и выполнявшего # хранимую процедуру. # sproc_status='tail #1 ${outfile3}' # # Выделив командой grep сообщения об ошибках, добавляем полный # протокол проверки текущей базы данных к выходному файлу. # cat ${outfile3} >> ${outfile} # # Если программа isql завершилась с ненулевым кодом возврата: # if [ $isql_status #ne 0 ] then echo " " >> $outfile echo dbcc log:${SERVER}: isql for dbcc of $dbname failed at 'date' >> $outfile echo " " >> $outfile echo " " >> $outfile2 echo dbcc log:${SERVER}: database dbcc of $dbname failed at 'date' >> $outfile2 echo " " >> $outfile2 # ***** Укажите правильный электронный адрес администратора сервера.

www.books-shop.com

/usr/ucb/mail #s "${SERVER}: dbcc of $dbname failed" psychoDBA@dbahost < $outfile # # В случае успешного завершения isql проверяем код возврата # хранимой процедуры. # else # # Если хранимая процедура завершилась успешно: # if [ "$sproc_status" = "Stored Procedure Execution Complete — no errors" ] then echo " " >> $outfile echo dbcc log:${SERVER}: completed database dbcc of $dbname at 'date' >> $outfile echo " ##############> total error count = ${Error_count} " >> $outfile echo " " >> $outfile2 echo dbcc log:${SERVER}: completed database dbcc of $dbname at 'date' >> $outfile2 echo " ##############> total error count = ${Error_count} " >> $outfile2 # # При успешном завершении программы isql и хранимой процедуры # записываем в выходной файл сообщения об ошибках, выданные # командами dbcc. # if [ "$Error_count" #ne "0" ] then cat ${outfile4} >> $outfile2 /usr/ucb/mail #s "${SERVER}: dbcc of $dbname failed" psychoDBA@dbahost < $outfile4 # fi fi # # Если хранимая процедура завершилась с ненулевым кодом возврата: # if [ "$sproc_status" = "FAILURE of Stored Procedure" ] then echo " " >> $outfile echo dbcc log:${SERVER}: sproc for dbcc of $dbname failed at 'date' >> $outfile # ***** Укажите правильный электронный адрес администратора сервера. /usr/ucb/mail #s "${SERVER}: dbcc of $dbname failed" psychoDBA@dbahost < $outfile echo " " >> $outfile2 echo dbcc log:${SERVER}: sproc for dbcc of $dbname failed at 'date' >> $outfile2 fi fi # # Конец цикла по проверяемым базам данных # done # # Записываем полный протокол в конец основного выходного файла # и посылаем этот файл администратору сервера.

www.books-shop.com

# echo " " >> $outfile echo "dbcc log:${SERVER}: exiting at 'date'." >> $outfile echo " " >> $outfile echo " " >> $outfile2 echo " " >> $outfile2 echo "dbcc log:${SERVER}: exiting at 'date'." >> $outfile2 echo " " >> $outfile2 echo " " >> $outfile2 echo "******************************************************" >> $outfile2 cat $outfile >> $outfile2 # ***** укажите правильный электронный адрес администратора сервера, /usr/ucb/mail #s "${SERVER}: dbcc cronjob complete" psychoDBA@dbahost < $outfile2 exit Поиск сообщений об ошибках в журнале регистрации ошибок SQL Server (scan_errorlog) Командный файл scan_errorlog просматривает журнал регистрации ошибок сервера и высылает администратору сервера строки сообщений о найденных ошибках, общее их количество, а также чис ло перезапусков сервера за время записи текущего журнала ошибок. #!/bin/sh # # Командный файл для оболочки Bourne, проверяющий # журнал регистрации ошибок сервера и высылающий администратору # сервера перечень найденных сообщений об ошибках. # # 25.11.96 Брайан Хичкок # if [ $# #lt 1 ] then echo $0: invalid format: $# argv parameters provided, 1 required # требуется 1 аргумент echo $0: required format: $0 '<SERVER>' exit 1 fi # # Параметры инициализации # # ***** Присвойте переменной errorlog_filename правильное полное # имя файла журнала регистрации ошибок вашего сервера. Здесь # предполагается, что этот файл называется еrrorlog_<имя_сервера>. filea=/export/home/Sybase/install/errorlog_ SERVER=$1 errorlog_filename=${filea}${SERVER} # ***** Укажите желаемый каталог для выходных файлов, outdir=/export/home/dbdump outfile=${outdir}/${SERVER}_scan_errorlog.out outfile2=${outdir}/${SERVER}_server_errors.out outfile3=${outdir}/${SERVER}lserver_restarts.out # # Приступаем к просмотру файла. # echo "scan server errorlog:${SERVER}: started at 'date'." > $outfile echo " " >> $outfile #

www.books-shop.com

# Ищем сообщения об ошибках. # Error_count='grep Error ${errorlog_filename} | wc #l' grep Error ${errorlog_filename} > ${outfile2) echo "server Errorlog Errors found = ${Error_count}" >> $outfile # # Определяем число перезапусков сервера. # Restart_count='grep 'SQL Server/' ${errorlog_f ilename} I wc #l' grep 'SQL Server/' ${errorlog_f ilename} > ${outfile3} echo "server Errorlog Restarts found = ${Restart_count} " >> $outfile # # Высылаем результаты просмотра журнала регистрации ошибок. # echo " " >> $outfile echo "scan server errorlog:${SERVER}: exiting at 'date'." >> $outfile echo " " >> $outfile echo "************************* Errors ************************" >> $outfile cat $outfile2 >> $outfile echo " " >> $outfile echo "************************ Restarts ************************" >> $outfile cat $outfile3 >> $outfile # ***** Укажите правильный электронный адрес администратора сервера. /usr/ucb/mail #s "${SERVER}: scan errorlog job complete" psychoDBA@dbahost < $outfile exit Выдача конфигурации сервера (dump_server_config) Командный файл dump_server_conf ig записывает на диск полную информацию о конфигурации сервера. Подчеркнем, что дело здесь не ограничивается выполнением процедуры sp_configure. Командный файл сохраняет все сведения о сервере, составе баз данных сервера и пользователях этих баз данных, позволяющие точно восстановить состояние сервера после сбоя или при переносе серве ра на другую серверную машину. Кроме того, командный файл dump_server_config регистрирует конфигурацию именованных кэшбуферов сервера. Поскольку такие буферы поддерживаются только SQL Server System 11, при выполнении файла в серверах System 10 и 4.9.2 выводятся сообщения об ошибках. Отметим, что, по мимо выдачи файла dump_server_config, важную информацию о конфигурации сервера можно найти в конфигурационных файлах сервера и в командном файле его запуска (RUN_<имя_cepвe" ра>). Эта информация не включена в выдачу dump_server_config, поскольку соответствующие файлы уже находятся на диске. После выполнения файла dump_server_config рекомендуем запи сать на ленту стандартными средствами архивации системы UNIX копию файловой системы, содер жащей наряду с выдачей dump_server_config и перечисленные выше файлы. #!/bin/sh # # Командный файл для оболочки Bourne, сохраняющий на диске конфигурацию # сервера, имя которого указывается в командной строке # # 02.12.96 Брайан Хичкок # if [ $# #lt l ] then echo $0: invalid format: $# argv parameters provided, at least 1 required

# требуется как минимум 1 аргумент echo $0: required format: $0 '<SERVER>' exit 1

www.books-shop.com

fi # # Параметры инициализации # # ***** Установите правильные значения # переменных SYBASE и PWD SYBASE=/export/home/sybase SERVER=$1 PWD='cat /export/home/sybase/.kparm' # ***** Укажите каталог для выдачи дампа # конфигурации сервера dumpdir=/export/home/dbdump outfilе=${dumpdir}/${SERVER}_config_dump.out outfile2=${dumpdir}/${SERVER}_config_dump.out2 tempfile=${dumpdir}/${SERVER}_config_dump.temp1 # chmod 700 $outfile chmod 700 $outfile2 # # Приступаем к выдаче дампа конфигурации сервера # echo "dump server config:${SERVER}: started at 'date'." > $outfile echo "dump server config:${SERVER}: started at 'date'." > $outfile2 echo " " >> $outfile echo " " >> $outfile2 # # Выдаем общую конфигурацию сервера # $SYBASE/bin/isql #Usa #S${SERVER} #P${PWD} #I$SYBASE/interfaces #e >> ${outfile} << finish_sqll use master go select * from sysusages go select * from sysdevices

go select * from sysdatabases go select * from sysservers go select * from sysremotelogins go select * from syslogins go sp_configure go sp_helpdevice go sp_helpdb go sp_helpcache go sp_cacheconfig go sybsystemprocs..p_mirror

go sybsystemprocs..p_devspace

go sybsystemprocs..p_servermap

www.books-shop.com

go finish_sgll # # Выдаем перечень баз данных сервера # $SYBASE/bin/isql #Usa #S${SERVER} #P${PWD) #I$SYBASE/interfaces #e > ${tempfile} << finish_sg;2 use master go select name from sysdatabases order by name go finish_sql2 # # Записываем полученный список баз данных в выходной файл # echo " • >> $outfile echo "@@@@@@@@@@@@@@@@@@@@@@>> >> $outfile echo "all databases in server $SERVER...." >> $outfile echo "@@@@@@@@@@@@@@@@@@@@@@@" >> $outfile echo " " >> $outfile cat ${tempfile} >> $outfile echo " " >> $outfile # # Из списка баз данных удаляем четыре первые и две последние # строки с помощью приема, подробно описанного в командном # файле dump_db_create # num_lines='wc #l ${tempfile} I cut #cl#9' last_line='expr $num_lines # 4' first_line='expr $last_line # 2' databases_list='tail #$last_line ${tempfile} I head #$first_line' rm #f ${tempfile} # # Выдаем информацию о конфигурации каждой базы данных сервера for database_name in $databases_list do # echo "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" >> $outfile echo "dumping configuration information for database $database_name in $SERVER" >> $outfile echo >>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@>> >> $outfile echo " " >> $outfile # $SYBASE/bin/isql #Usa #S${SERVER} #P${PWD} #I$SYBASE/interfaces #e >> ${outfile} << finish_sql2 use $database_name go sp_helpdb $database_name go sp_helpsegment go sybsystemprocs..p_dbcreate $database_name go sp_helpuser go select * from sysusers

go select * from sysalternates go

www.books-shop.com

finish_sql2 # # Конец цикла по базам данных # done # # Записываем файл протокола в конец основного выходного файла и # посылаем основной файл администратору сервера # echo " " >> $outfile echo "dump server config:${SERVER}: exiting at 'date'." >> $outfile echo " " >> $outfile echo "dump server config:${SERVER}: exiting at 'date'." >> $outfile2 echo " " >> $outfile2 echo " " >> $outfile2 echo "******************************************************" >> $outfile2 cat $outfile >> $outfile2 # ***** Укажите правильный электронный адрес администратора сервера /usr/ucb/mail #s "${SERVER}: dump server config cronjob complete" psychoDBA@dbahost < $outfile2 exit Контроль активности пользователей (monitor.report) Командный файл monitor_report отслеживает активность всех пользователей определенного сер вера. Хотя monitor_report выдает минимум информации о каждом отдельном пользователе, в це лом это позволяет составить ясное представление о количестве пользователей, работающих с сервером в данный момент, об интенсивности блокировок и использования ресурсов сервера. Выпол нение самого файла monitor_report приводит к крайне незначительной нагрузке на сервер и поэ тому позволяет обеспечить постоянный контроль за действиями пользователей сервера. К примеру, столкнувшись со снижением производительности сервера, вы можете начать запускать monitor_re" port каждые 15 минут, чтобы проследить, какие пользователи наиболее активно используют блоки ровки, какие таблицы оказываются заблокированными чаще всего и т.д. Подобная информация оказывает существенную помощь при анализе причин временного замедления работы сервера. #!/bin/sh # # Командный файл для оболочки Bourne, который контролирует # активность пользователей сервера, указанного при вызове файла # # 03.12.96 Брайан Хичкок # if [ $# #lt l ] then echo $0: invalid format: $# argv parameters provided, at least 1 required # требуется как 'минимум 1 аргумент echo $0: required format: $0 '<SERVER>' exit 1 fi # # Параметры инициализации # # ***** Установите правильные значения # переменных SYBASE и PWD SYBASE=/export/home/sybase SERVER=$1

PWD='cat /export/home/sybase/.kparm' # ***** Укажите каталог для выходных файлов dumpdir=/export/home/dbdump

www.books-shop.com

outfile=${dumpdir}/${SERVER}_monitor_report.out outfile2=${dumpdir}/${SERVER}_monitor_report.out 2 # # Начинаем составление отчета # echo "monitor report:${SERVER}: started at 'date'." > $outfile echo "monitor report:${SERVER}: started at 'date'." > $outfile2 echo " " >> $outfile echo " " >> $outfile2 # $SYBASE/bin/isgl #Usa #S${SERVER} #P${PWD} #I$SYBASE/interfaces #e >> ${outfile} << finish_sqll use master go select @@servername, getdate()

go sp_who go sp_lock go select * from sysprocesses go sp_monitor

go finish_sql1 # # Записываем файл протокола в конец основного выходного файла # и посылаем выдачу администратору сервера # echo " " >> $outfile echo "monitor report:${SERVER}: exiting at 'date'." >> $outfile echo " " >> $outfile echo " " >> $outfile2 echo "monitor report:${SERVER}: exiting at 'date'." >> $outfile2 echo " " >> $outfile2 echo " " >> $outfile2 echo "******************************************************" >> $outfile2 cat $outfile >> $outfile2 # ***** Укажите правильный электронный адрес администратора сервера /usr/ucb/mail #s "${SERVER}: monitor report cronjob complete" psychoDBA@dbahost < $outfile2 exit Запуск процедуры sp_sysmon (execute_sp_sysmon) Командный файл execute_sp_sysmon выполняет на сервере системную хранимую процедуру sp_sysmon и высылает ее выдачу электронной почтой администратору сервера. Процедура sp_sys mon относится к новым средствам SQL Server версии System 11, что не позволяет использовать файл execute_sp_sysmon с предыдущими версиями сервера. Несмотря на всю ценность и подробность выдаваемой информации, выполнение sp_sysmon в определенной степени сказывается на произво дительности сервера, поэтому данную процедуру следует запускать только при реальной необходимо сти (в отличие от приведенного выше командного файла monitor_report, который можно использовать без ограничений). Именно по этой причине мы выделили запуск sp_sysmon в коман дный файл, включаемый отдельной строкой в crontab (список всех cronзадач серверной машины), что позволяет выполнять sp_sysmon по специальному графику. При настройке сервера sp_sysmon должна запускаться регулярно, а в дальнейшем достаточно выполнять ее один раз в день для отслежи вания долговременных тенденций изменения производительности.

www.books-shop.com

#!/bin/sh # # Командный файл для оболочки Bourne, который запускает # процедуру sp_sysmon на сервере, заданном в командной строке # # 03.12.96 Брайан Хичкок # if [ $# #lt 1 ] then echo $0: invalid format: $# argv parameters provided, at least 1 required # требуется как минимум 1 аргумент echo $0: required format: $0 '<SERVER>' exit 1 fi # # # Параметры инициализации # # ***** Установите правильные значения # переменных SYBASE и PWD SYBASE=/export/home/Sybase SERVER=$1 PWD='cat /export/home/sybase/.kparm' # ***** Укажите каталог для файлов дампов dumpdir=/export/home/dbdump outfile=${dumpdir}/${SERVER}_monitor_report.out outfile2=${dumpdir}/${SERVER}_monitor_report.out2 # # Приступаем к запуску sp_sysmon # echo "execute sp_sysmon:${SERVER}: started at 'date'." > $outfile echo "execute sp_sysmon:${SERVER}: started at 'date'." > $outfile2 echo " " >> $outfile echo " " >> $outfile2 # $SYBASE/bin/isql #Usa #S${SERVER} #P${PWD} #I$SYBASE/interfaces #e >> ${outfile} << finish_sqll use master go select @@servername, getdate()

go

sp_sysmon 1 go finish_sqll # # Записываем полный протокол в конец основного выходного файла # и посылаем этот файл администратору сервера # echo " " >> $outfile echo "execute sp_sysmon:${SERVER}: exiting at 'date'." >> $outfile echo " " >> $outfile echo " " >> $outfile2 echo "execute sp_sysmon:${SERVER}: exiting at 'date'." >> $outfile2 echo " " >> $outfile2 echo " " >> $outfile2 echo "******************************************************" >> $outfile2 cat $outfile >> $outfile2 # ***** Укажите правильный электронный адрес администратора сервера

www.books-shop.com

/usr/ucb/mail #s "${SERVER}: execute sp_sysmon cronjob complete" psychoDBA@dbahost < $outfile2 exit Автоматический перезапуск сервера Рассматриваемый командный файл автоматически запускает SQL Server при каждом перезапуске сер верной машины. Обычно приведенные ниже команды являются фрагментом файла /etc/rc3.d. Рекомендуем уточнить у системного администратора серверной машины, куда именно следует вклю чить команды перезапуска сервера. Помимо SQL Server, наш командный файл запускает также сервер архивации Backup Server и ряд компонентов сервера тиражирования Sybase Replication Server. Запуск сервера тиражирования производится с 5минутной задержкой (300 с), необходимой для нормально го запуска основного сервера и для завершения восстановления им всех баз данных. #!/bin/sh ##################################################### # Команды запуска сервера баз данных Sybase # ##################################################### if [ #f /export/home/sybase/install/startserver ] ;then su sybase #c "/bin/sh" << Here SYBASE=/export/home/sybase; export SYBASE /export/home/sybase/install/RUN_SPOTUS & /export/home/sybase/install/RUN_SPOTUS_BCK & sleep 300 /export/home/sybase/install/RUN_SPOTUSRS & /export/home/sybase/install/RUN_SPOTUS_SPOTUSRS_RSSD_ltm & /export/home/sybase/install/RUN_SPOTUS_spotdb_ltm & /export/home/sybase/install/RUN_SPOTUK_spotdb_ltm & Here fi Строки описания командных файлов в таблице crontab В этом разделе представлен набор строк файла crontab, которые устанавливают типичный график ав томатического запуска рассмотренных в данной главе командных файлов эксплуатации SQL Server System 11. Каждый вечер в 23:00 сохраняются полные дампы баз данных, через полчаса — в 23:30 — дампы журналов транзакций, а в 23:45 осуществляется принудительная очистка журналов транзакций баз данных master к sybsystemprocs (журналы транзакций этих двух баз данных не вынесены на отдельное серверное устройство, что не позволяет указать их в процедуре записи дампов журналов транзакций). Удаление прежних дампов, хранящихся более двух дней, планируется выполнять в час ночи (фак тически из каталога /export /home/dbdump удаляются все файлы с именами вида SPOTUS_*.dmp, созданные более двух дней назад). В два часа ночи запускаются dbccпроверки баз данных, в 3 часа ночи обновляется статистика по всем таблицам некоторых баз данных, в 4 часа утра просматривает ся журнал регистрации ошибок в поисках сообщений об ошибках, и, наконец, в 5 часов утра на диск записывается полная конфигурация сервера. Командный файл быстрого контроля за активностью пользователей (monitor_report) запуска ется ежедневно в 9, 12 и 15 часов, в то время как полный анализ функционирования сервера (с по мощью файла execute_sp_sysmon) производится только один раз в день в 12:30. Используя приведенный ниже фрагмент таблицы crontab, вы сможете реализовать собственный распорядок за пуска cronзаданий на различных серверах своей информационной системы. 0 23 * * * /export/home/sybase/local/bin/dump_listof_dbs SPOTUS spotdb SPOTUSRS_RSSD master sybsystemprocs 30 23 * * * /export/home/sybase/local/bin/logdump_listof_dbs SPOTUS spotdb SPOTUSRS_RSSD 45 23 * * * /export/home/sybase/local/bin/trunclog_listof_dbs SPOTUS master sybsystemprocs

Ⱦɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRS ɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕ Ɉɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭ[email protected]

О 1 * * * /export/home/sybase/local/bin/remove_old_files "/export/home/dbdump/SPOTUS_*.dmp" 2 0 2 * * * /export/home/sybase/local/bin/update_listof_dbs SPOTUS spotdb SPOTUSRS_RSSD master sybsystemprocs 0 3 * * * /export/home/sybase/local/bin/dbcc_listof_dbs SPOTUS spotdb 0 4 * * * /export/home/sybase/local/bin/scan_errorlog SPOTUS 0 5 * * * /export/home/sybase/local/bin/dump_server_config SPOTUS 0 9,12,15 * * * /export/home/sybase/local/bin/monitor_report SPOTUS 30 12 * * * /export/home/sybase/local/bin/execute_sp_sysmon SPOTUS

www.books-shop.com