Сервер | Физическое расположение | Размер | Автоматическое приращение файла данных | Автоматическое приращение файла журнала транзакций |
А1 | Первый физический диск | 40% от размера самой большой базы данных | 35% | 40% |
Б1, Б2, Б3, Б4 | Дисковый массив RAID1 | 40% от размера самой большой базы данных | 35% | 40% |
А2, А3 | Дисковый массив RAID0 внешней дисковой подсистемы | 40% от размера самой большой базы данных | 35% | 40% |
А4 | Дисковый массив RAID0 внешней дисковой подсистемы | 40% от размера самой большой базы данных | 35% | 40% |
Объяснение: База данных tempdb используется для временного хранения рабочих файлов, например, промежуточных наборов результатов сложных запросов, временных таблиц и процедур. Размер этой базы данных должен составлять от 25% до 40% самой большой базы данных. Размещаться база данных tempdb должна на отдельном физическом диске. Автоматическое приращение файлов должно иметь достаточно большую величину, чтобы рост файлов происходил нечасто и не оказывал большой нагрузки на систему.
Примечание. Порядок действий по переносу базы данных tempdb, изменению ее размера и автоматического приращения файлов см. в Приложении 2.
4 Создание и конфигурирование пользовательских баз данных
4.1 Физическое размещение файлов базы данных
Таблица 7. Рекомендации по физическому размещению файлов базы данных
Сервер | Размещение файлов данных базы данных | Размещение файлов журнала транзакций базы данных | Примечание |
А1 | Первый жесткий диск – первичный файл данных базы данных | Второй жесткий диск | Аппаратная конфигурация сервера А1 не позволяет обеспечить одновременно отказоустойчивость и производительность. |
Б1, Б2, Б3, Б4 | Третий жесткий диск – первичный файл данных базы данных | Четвертый жесткий диск | Аппаратная конфигурация серверов Б позволяет обеспечить отказоустойчивость только для операционной системы. В рекомендациях по размещению файлов базы данных на серверах Б предпочтение отдается производительности, поэтому на серверах Б необходимо очень часто проводить резервное копирование базы данных. |
А2, А3 | Дисковый массив RAID0+1 внешней дисковой подсистемы – первичный файл данных базы данных | Дисковый массив RAID1 внешней дисковой подсистемы | |
А4 | Первый дисковый массив RAID0+1 внешней дисковой подсистемы – первичный файл данных базы данных Второй дисковый массив RAID0+1 внешней дисковой подсистемы – вторичный файл данных для некластерных индексов пользовательских таблиц EXTREM, REM3_INCOME REM1, REM2 и REM3 | Третий дисковый массив RAID0+1 внешней дисковой подсистемы |
Объяснение: Журнал транзакций не должен размещаться на том же диске, что и файлы данных. Если для журнала транзакций выделяется отдельный диск, то головка диска остается на месте в период от одной записи в журнал транзакций до следующей. Операции чтения из журнала также будут выполняться быстрее, поскольку данные будут размещаться на диске последовательно. Таким образом, выделение отдельных дисков для файлов данных и файлов журнала транзакций позволяет существенно повысить производительность, а также уменьшить время восстановления после сбоя. Сервер А4 позволяет сделать следующий шаг к оптимизации дисковой системы – повышению производительности операций ввода-вывода. С этой целью для некластерных индексов «тяжелых» таблиц создается отдельная группа файлов, которая размещается на отдельном физическом диске, что также повышает производительность ввода-вывода.
Примечание. Порядок действий по изменению размещения файлов данных и файлов журнала транзакций, а также по созданию вторичного файла данных и перемещения в него некластерных индексов «тяжелых» таблиц описан в Приложении03.
4.2 Установка величины приращения файла данных и файла журнала транзакций
Рекомендации: Установить величину приращения 35% для файлов данных и 45% для файлов журнала транзакций.
Объяснение: Для снижения нагрузки на систему нужно устанавливать достаточно большую величину приращения размера файлов данных и файлов журнала транзакций, чтобы рост этих файлов происходил нечасто.
Примечание – Порядок действий по изменению величины приращения файлов данных и файлов журнала транзакций описан в Приложении03.
4.3 Ограничение размера файла данных и файла журнала транзакций
Рекомендации: Ограничить рост файлов данных и файлов журналов транзакций.
Объяснение: Если не ограничивать рост файлов базы данных, то неограниченный рост этих файлов может привести к переполнению диска и препятствовать работе операционной системы и базы данных.
Примечание. Порядок действий по ограничению размера файлов данных и файлов журнала транзакций описан в Приложении03.
4.4 Конфигурирование базы данных
Рекомендации: Установить следующие параметры базы данных: модель восстановления bulk_logged либо full; auto update statistics; torn page detection; auto create statistics
Объяснение: Параметры базы данных определяют различные аспекты стандартного поведения базы данных. В большинстве сред, как правило, изменяют лишь некоторые параметры базы данных.
Модель восстановления bulk_logged не записывает в журнал транзакций информацию о загрузке каждой строки при импорте данных. При установке этой модели восстановления массовая загрузка (импорт) данных в базу данных будет выполняться быстрее. Однако при крахе базы данных вы не сможете восстановить информацию, внесенную в базу данных во время импорта данных, с использованием резервной копии журнала транзакций. Для этого потребуется полная резервная копия базы данных, созданная сразу после операции импорта данных.
Модель восстановления full записывает в журнал транзакций информацию о загрузке каждой строки при импорте данных. При установке этой модели восстановления массовая загрузка (импорт) данных в базу данных будет выполняться медленнее. Однако при крахе базы данных вы сможете восстановить информацию, внесенную в базу данных во время импорта данных, с использованием резервной копии журнала транзакций.
Опция «auto update statistics» дает команду SQL Server периодически обновлять статистику распределения данных, что оптимизирует поиск и выборку данных.
Опция «torn page detection» позволяет SQL Server контролировать ситуацию, когда в результате сбоя питания или системного сбоя операции ввода-вывода для страницы завершились не полностью или некорректно.
Примечание. Порядок действий по изменению параметров базы данных описан в Приложении03.
5 Резервное копирование и восстановление баз данных
5.1 Введение
Резервное копирование является самым надежным способом защиты данных от потери.
Технологии RAID обеспечивают функционирование системы при выходе из строя одного из жестких дисков или даже дискового контроллера, однако они не помогут при выходе из строя оперативной памяти, центрального процессора или сетевой карты.
Кластерные технологии обеспечивают более высокую степень сохранности данных, чем RAID, однако возможен и такой случай, когда информация будет уничтожена на всех серверах.
Чтобы иметь возможность восстановить данные, необходимо иметь полную их копию. Такая копия данных называется резервной, и, при потере данных, она переносится в систему, и пользователи могут снова работать с информацией.
После восстановления резервной копии система будет восстановлена в том состоянии, в котором она была на момент создания резервной копии. Поэтому необходимо внимательно относиться к вопросу, с какой частотой будет создаваться резервная копия. Если данные обновляются интенсивно, то резервное копирование необходимо выполнять достаточно часто, чтобы в случае повреждения данных восстановить информацию с наименьшими потерями.
СУБД SQL Server 2000 позволяет очень гибко управлять процессом создания резервных копий.
Рекомендуемая схема резервного копирования:
– один раз в сутки во внерабочее время создается новая полная резервная копия базы данных
– каждый час создается резервная копия журнала транзакция
– перед созданием новой полной резервной копии происходит либо копирование предыдущей полной резервной копии и резервной копии журналов транзакций на определенный сетевой диск в папку с конкретной датой, либо с помощью утилит-архиваторов из предыдущей полной резервной копии и резервной копии журналов транзакций создается архивный файл с именем, отражающим конкретную дату
– резервные копии за конкретную дату копируются на внешний носитель
5.2 Устройства резервного копирования
Рекомендации: В качестве устройства резервного копирования баз данных выбрать сетевой диск.
Объяснение: Ленточные накопители (стримеры) работают медленно и имеют ограниченный объем, т. е. резервная копия базы данных может не поместиться на одну ленту, и кто-то должен эти ленты менять. Копирование на сетевой диск в большинстве случаев является наиболее быстрым способом создания резервной копии базы данных. По утверждению компании Microsoft создание на сетевом диске резервной копии базы данных размером 20 Гб занимает около 8 минут. После создания резервных копий базы данных на сетевом диске эти копии необходимо регулярно (например, каждую ночь) автоматически копировать на стример обычными средствами операционной системы, либо копировать на другой внешний носитель.
Примечание. Порядок действий по созданию устройств резервного копирования описан в Приложении04.
5.3 Операторы
Рекомендации: Назначить хотя бы одного человека, ответственного за поддержку SQL Server 2000, и сконфигурировать хотя бы одного оператора SQL server 2000.
Объяснение: Оператор – это пользователь, которого можно уведомить об успехе, ошибке или завершении выполнения какой-либо задачи SQL Server. Например, оператора можно уведомить о том, как завершилось резервное копирование базы данных; о том, сколько места осталось в файлах базы данных (что особенно важно, если файлы базы данных сконфигурированы не расти автоматически); о превышении допустимого размера файлов базы данных и т. п. Оператор может уведомляться по сети (командой NET SEND), по электронной почте или посредством пейджера.
Примечание – Порядок действий по созданию операторов описан в Приложении04.
5.4 Задания для резервного копирования
Рекомендации: Создать задания для обслуживания базы данных, для полного резервного копирования базы данных и для резервного копирования журнала транзакций.
Объяснение: Задания позволяют выполнять стандартные административные функции по расписанию (в данном случае – автоматическое резервное копирование базы данных). Создавая задание, можно избавиться от ручного выполнения того же резервного копирования базы данных; кроме того, можно уведомить оператора об ошибке создания резервной копии. Необходимо регулярно создавать полную резервную копию базы данных и резервные копии журнала транзакций, а также проводить регулярное обслуживание базы данных.
Примечание. Порядок действий по созданию заданий описан в Приложении04. Рекомендуется создать задание резервного копирования для всех пользовательских баз данных, а также для баз данных master, model и msdb.
5.5 Оповещения
Рекомендации: Создать оповещения для информирования оператора о заполнении журнала транзакций базы данных.
Объяснение: Оповещения позволяют уведомлять соответствующих лиц об определенных событиях и условиях производительности, а также запускать различные задания в ответ на такие события и условия. Например, можно создать оповещение, которое срабатывает при заполнении журнала транзакций на 80%, архивирует и усекает его, а также извещает оператора об успехе или ошибке выполнения.
Примечание. Порядок действий по созданию оповещений описан в Приложении04.
5.6 Мониторинг файла данных
Рекомендации: Проводить регулярный мониторинг свободного места в файлах данных базы данных.
Объяснение: Поскольку для повышения производительности рекомендуется не конфигурировать автоматическое приращение файлов, то необходимо проводить регулярный мониторинг свободного места в файлах данных и своевременно принимать меры к увеличению дискового пространства, если данные приближаются к размеру файла.
Примечание. Порядок действий по мониторингу описан в Приложении04.
5.7 Восстановление базы данных
Восстановление базы данных может потребоваться в двух случаях:
Промышленный сервер баз данных находится в рабочем состоянии, и произошел крах только базы данных Промышленный сервер баз данных вышел из строяВ первом случае достаточно просто восстановить базу данных из резервной копии. Во втором случае необходимо иметь резервный сервер, на котором можно провести восстановление базы данных, и временно использовать для работы резервный сервер, пока не восстановится работоспособность промышленного сервера.
Примечание. Порядок действий по восстановлению базы данных в обоих случаях приведен в Приложении04.
Приложение 1. Аппаратная конфигурация серверов
Наименование | Серверы в комплекте |
Комплект № 1 | А1 и Б1 |
Комплект № 2 | А2 и Б2 |
Комплект № 3 | А3 и Б3 |
Комплект № 4 | А4 и Б4 |
Сервер А1
– CPU – 4 (четыре) процессора Intel® Xeon™ MP, частота не менее 3 ГГц, Кэш – 4 MB Level 3 (для каждого процессора), частота системной шины 400МГц;
– Оперативная память – 2 ГБ DDR SDRAM ECC с возможностью расширения до 32ГБ; подсистема памяти должна поддерживать возможность построения вариантов защиты с использованием “горячих” режимов “зеркалирования”;
– RAID-контроллер, удовлетворяющий следующим требованиям:
― Поддержка жестких дисков с интерфейсом Ultra320;
― Аппаратная реализация массива RAID 0, 1, 1+0;
― Кэш-память объемом не менее 64МБ с аккумуляторной батареей;
― Поддержка режимов кэширования по записи и чтению;
― Поддержка внутренней дисковой подсистемы сервера;
― Поддержка внутренних ленточных накопителей;
– Внутренняя дисковая подсистема - 2 (два) жестких диска с возможностью “горячей” замены, с интерфейсом Ultra320, объем каждого диска не менее 300ГБ и скорость вращения не менее 10000 оборотов в минуту.
Сервер Б1
– CPU – 2 (два) процессора Intel® Xeon™ , частота не менее 3,2 ГГц, Кэш – 2 MB Level 2 (для каждого процессора), частота системной шины 800МГц;
– Оперативная память – 1 ГБ DDR2 400MHz ECC с возможностью расширения до 12ГБ;
– RAID-контроллер, удовлетворяющий следующим требованиям:
― Поддержка жестких дисков с интерфейсом Ultra320;
― Аппаратная реализация массива RAID 0, 1, 1+0, 5;
― Кэш-память объемом не менее 128МБ с аккумуляторной батареей;
― Поддержка режимов кэширования по записи и чтению;
― Поддержка внутренней дисковой подсистемы сервера;
– Внутренняя дисковая подсистема должна иметь 4 (четыре) жестких диска с возможностью “горячей” замены, с интерфейсом Ultra320, объем каждого диска не менее 72 ГБ и скорость вращения не менее 10000 оборотов в минуту; внутренняя дисковая подсистема должна иметь не менее 6 (шести) посадочных мест для установки жестких дисков с интерфейсом Ultra320.
Сервер А2
– CPU – 4 (четыре) процессора Intel® Xeon™ MP, частота не менее 3 ГГц, Кэш – 4 MB Level 3 (для каждого процессора), частота системной шины 400МГц;
– Оперативная память – 6 ГБ DDR SDRAM ECC с возможностью расширения до 32ГБ; подсистема памяти должна поддерживать возможность построения вариантов защиты с использованием “горячих” режимов “зеркалирования”; подсистема памяти должна включать все необходимые платы расширения для обеспечения расширения памяти до максимального объема и перевода подсистемы памяти в режимы защиты “зеркалирования”;
– Внутренняя дисковая подсистема должна иметь 2 (два) жестких диска с возможностью “горячей” замены, с интерфейсом Ultra320, объем каждого диска не менее 36ГБ и скорость вращения не менее 15000 оборотов в минуту;
– RAID-контроллер, удовлетворяющий следующим требованиям:
― Не менее 4-х (четырёх) внешних каналов с интерфейсом Ultra320;
― Поддержка жестких дисков с интерфейсом Ultra320;
― Аппаратная реализация массива RAID 0, 1, 1+0, 5;
― Кэш-память объемом не менее 256МБ с аккумуляторной батареей;
― Поддержка режимов кэширования по записи и чтению;
― Поддержка Внешней дисковой системы.
Остальные технические параметры Сервера А2 должны соответствовать техническим параметрам Сервера А1.
1.1.1.1.1.1 Внешняя дисковая подсистема
Внешняя дисковая система, подключаемая к Серверу A2, должна отвечать следующим требованиям:
– Одна дисковая полка для размещения дисков с «горячей» заменой с интерфейсом Ultra320 c количеством посадочных мест для дисков не менее 14 (четырнадцать); внешний интерфейс для подключения к Серверу А3 два канала Ultra320;
– Восемь жестких дисков с интерфейсом Ultra320 и возможностью «горячей» замены; объем каждого диска 72ГБ и скорость вращения 10000 оборотов в минуту;
Должна иметься возможность по расширению количества устанавливаемых жестких дисков с возможностью горячей замены, не менее чем 50 штук путём наращивания количества внешних дисковых полок.
Сервер Б2
Сервер Б2 должен соответствовать техническим параметрам Сервера Б1.
Сервер А3
– Оперативная память – 16 ГБ DDR SDRAM ECC с возможностью расширения до 32ГБ; подсистема памяти должна поддерживать возможность построения вариантов защиты с использованием “горячих” режимов “зеркалирования”; подсистема памяти должна включать все необходимые платы расширения для обеспечения расширения памяти до максимального объема и перевода подсистемы памяти в режимы защиты “зеркалирования”.
Остальные технические параметры Сервера А3 должны соответствовать техническим параметрам Сервера А2.
1.1.1.1.1.2 Внешняя дисковая подсистема
Внешняя дисковая система, подключаемая к Серверу A3, должна отвечать следующим требованиям:
– 1 (одна) дисковая полка для размещения дисков с «горячей» заменой с интерфейсом Ultra320 c количеством посадочных мест для дисков не менее 14 (четырнадцать); внешний интерфейс для подключения к Серверу А3 два канала Ultra320;
– 8 (восемь) жестких дисков с интерфейсом Ultra320 и возможностью «горячей» замены; объем каждого диска 72ГБ и скорость вращения 10000 оборотов в минуту.
Должна иметься возможность по расширению количества устанавливаемых жестких дисков с возможностью горячей замены, не менее чем 50 штук путём наращивания количества внешних дисковых полок.
Сервер Б3
Сервер Б3 должен соответствовать техническим параметрам Сервера Б1.
Сервер А4
– CPU – 4 (четыре) процессора Intel® Xeon™ MP, частота не менее 3 ГГц, Кэш – 4 MB Level 3 (для каждого процессора), частота системной шины 400МГц;
– Оперативная память – 16 ГБ DDR SDRAM ECC с возможностью расширения до 32 ГБ; подсистема памяти должна поддерживать возможность построения вариантов защиты с использованием “горячих” режимов “зеркалирования”; подсистема памяти должна включать все необходимые платы расширения для обеспечения расширения памяти до максимального объема и перевода подсистемы памяти в режимы защиты “зеркалирования”;
– Внутренняя дисковая подсистема должна иметь 2 (два) жестких диска с возможностью “горячей” замены, с интерфейсом Ultra320, объем каждого диска не менее 36ГБ и скорость вращения не менее 15000 оборотов в минуту.
Остальные технические параметры Сервера А4 должны соответствовать техническим параметрам Сервера А3.
1.1.1.1.1.3 Внешняя дисковая подсистема
Внешняя дисковая подсистема, подключаемая к Серверу A4, должна отвечать следующим требованиям:
– 2 (два) RAID контроллера, для повышения надежности и безостановочной работы дисковой системы, c аппаратной поддержкой массивов RAID 1, 10(0+1), 5; каждый контроллер должен обеспечить подключение жестких дисков в режиме Hot Plug, иметь кэш-память не менее 256 МВ;
– 2 (два) внешних оптических порта с пропускной способностью не менее 2 ГБит/сек;
– 14 жестких дисков с интерфейсом Ultra320 и возможностью «горячей» замены; объем каждого диска 72ГБ и скорость вращения 10000 оборотов в минуту;
– Должна иметься возможность по расширению количества устанавливаемых жестких дисков с возможностью горячей замены, не менее чем до 80 штук;
– Внешняя дисковая система должна иметь возможность наращивания для обеспечения подключения нескольких серверов с резервированными путями доступа.
Сервер Б4
Сервер Б4 должен соответствовать техническим параметрам Сервера Б1.
Приложение 2. Конфигурирование SQL Server 2000 после установки
1. Конфигурирование службы SQL Server Agent для запуска при запуске операционной системы
1.1. Запустить утилиту Service Manager:
Пуск → Программы → Microsoft SQL Server → Service Manager.
1.2. В открывшемся окне (см. Рисунок 1) убедиться, что выбран установленный экземпляр SQL Server.
1.3. Открыть выпадающий список Services и выбрать службу SQL Server Agent.
Рисунок Рисунок 1. Окно SQL Server Service Manager
1.4. Установить флаг Auto-start service when OS starts (если он еще не стоит).
1.5. Если служба остановлена (доступна кнопка Start/Continue), то запустить службу нажатием на кнопку Start/Continue.
2. Изменение настроек SQL Server после установки
1.6. Запустить утилиту Enterprise Manager.
1.7. В открывшемся окне (см. Рисунок 2) утилиты выбрать нужный экземпляр SQL Server, щелкнуть по нему правой кнопкой мыши и в открывшемся контекстном меню выбрать пункт Свойства.
1.8. Перейти на закладку Security и в разделе Security/Audit Level поставить переключатель в положение All.
Рисунок Рисунок 2. Окно SQL Server Properties
3. Включение поддержки API-интерфейса AWE
– убедиться, что учетной записи Windows, под которой запускается SQL Server, назначена привилегия lock pages in memory (закрепление страниц в памяти)
– в файле boot.ini поставить переключатель /PAE
Примечание. Для того чтобы режим AWE мог корректно использовать более 16 Гб памяти, в файле boot.ini не должно быть переключателя /3Gb.
– перезагрузить сервер Windows
– открыть утилиту Query Analyzer
– в окне утилиты выполнить скрипт (подразумевается, что аппаратный сервер имеет 16 Гб памяти, и для операционной системы мы оставляем 2 Гб памяти):
EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
EXEC sp_configure 'awe enabled', 1
GO
RECONFIGURE
GO
EXEC sp_configure 'max server memory', 14000
GO
RECONFIGURE
GO
– закрыть утилиту Query Analyzer
– перезапустить SQL Server
– после перезапуска снова открыть утилиту Query Analyzer и выполнить:
EXEC sp_configure 'awe enabled'
GO
– убедиться, что в результатах работы команды в столбце run_value стоит значение 1.
4. Изменение физического расположения базы данных tempdb
1.9. Допустим, что база данных tempdb перемещается на диск E.
1.10. Открыть утилиту Query Analyzer.
1.11. В окне утилиты выполнить следующий скрипт:
USE master
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME='tempdev', FILENAME='E:\tempdb. mdf')
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME='templog', FILENAME='E:\templog. ldf')
GO
1.12. Остановить и снова запустить SQL Server.
1.13. Удалить старые файлы базы данных tempdb из их прежнего расположения. Обычно файлы базы данных tempdb по умолчанию располагаются в каталоге установки SQL Server по пути C:\Program Files\Microsoft SQL Server\MSSQL\Data. Имена файлов – tempdb. mdf и templog. ldf.
5. Изменение размера базы данных tempdb и величины автоматического приращения
1.14. Открыть утилиту Enterprise Manager.
1.15. Правой кнопкой мыши щелкнуть по базе данных tempdb, вызвать из контекстного меню ее свойства и перейти на закладку Data Files.
1.16. В поле Space allocated для файла данных tempdev поставить нужную величину размера файла с тем, чтобы размер базы данных tempdb составлял 40% от размера самой большой базы данных.
1.17. В разделе File growth установить переключатель By percent и ввести величину 35 (см. Рисунок 3).
Рисунок Рисунок 3. Окно «tempdb properties»
1.18. Перейти на закладку Transaction Log и проделать те же действия для файла журнала транзакций, установив величину приращения 40%.
Приложение 3. Конфигурирование пользовательских баз данных
1. Изменение размещения файлов данных и файлов журнала транзакций
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 |
