Итак
Дано :
есть высоконагруженная база под 1c77 база данных ms sql 2000 sp3a
конфигурация самописная по многим вещам достаточно оптимизирована и заточена под 1с++
есть новый сервер
ram 32 Гб
Xeon-R CPU E-52603 @ 1.80 GHz 2 процессора ( 8 ядер )
LSI контролер с кешем + 8 дисков sas димков, 1 диск ide-sata
ос Windows Server 2008 R2 Standart
sp1
Требуется установить и настроить ms sql2005
Microsoft SQL Server 2005 - 9.00.5000.00 (X64) Dec 10 2010 10:38:40
Copyright (c) 1988-2005 Microsoft Corporation
Standard Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)
Описание будет растянуто по времени
это во первых мне так легче будет все описать
во вторых каждую из глав можно будет отдельно обсудить.
Надеюсь это изложение поможет установить все гораздо быстрее и правильней,
может также кто-то для себя откроет что-то новое ( в том числе и я в ходе обсуждения этой темы ).
Еще раз подчеркну что речь идет о высоконагруженной OLTP базе.
Многое из сказаное относится исключительно к настройке ms sql сервера
поэтому может быть применимо не только к базам 1cv77 но и другим ( например v8 )
глава 1. Планирование Дисковой системы.Так как мы говорим о серьезной нагрузке то на сервере не может быть никаких виртуальных машин.
Все это конечно хорошо ( вирт машины ) и на малых и средних нагрузках это работает,
но при высоких нагрузках виртуальные машины недопустимы.
Основная причина недопустимости состоит в том, что виртуальная машина значительно снижает скорость
дисковых операций.А дисковые операции и их скорость это основа залога успеха работы ms sql сервера.
Итак если Вы до установки ( в том числе и ОС) все грамотно спланируете - имеется ввиду дисковые ресурсы
сервера то половина успешной установки сервера уже сделана.
И наоборот просчеты и Ошибки в дисковой системе сервера практически ничем исправить
нельзя ( только новая переустановка сервера ).
Выбрана следущая конфигурация (
c: 2 диска raid 1
d: 4 диска raid 10
e: 2 диска raid 1
f: 2 диска raid 1
Почему все сделано на raid - чтобы обеспечить надежность.
Диск с отводиться под операционную систему
диск d отводиться под базу данных файл mdf
диск е под базу tempdb + другие вспомагательные базы данных
диск f отводиться под журнал транзакций базы данных log файл
Примечание если используется os win 2003 то для дисков с данными sql необходимо обязательно установить размер
блока 64 Кб и обеспечивать выравнивание по границе 64 Кб
первоисточник в русскоязычном интернете
Alexander Gladchenko Tips for DBA: выравнивание кластеров NTFS и блоков RAID-массивов
http://msmvps.com/blogs/gladchenko/archive/2008/10/19/1651317.aspx там же найдете как это преодолеть и англоязычеые ссылкы где это описано.
Для raid массивов под Window 2008 эта ошибка исправлена.
надо назначить только размер блока 64кб (или больше но кратный 64к )
Кратко почему такая конфигурация
диск с: на отдельный диск ОС. тут все понятно главное чтобы ос не мешала данным ms msq.
диск d: диск для базы данных raid 10 самый производительный массив данных ( и самый дорогой )
обеспечивающий высокую надежность.
Почему файл журнала транзакций вынесен на разные диски.
Все дело в том что ms sql имеет упреждающую запись.
Если подробно то это выглядит так :
предположим sql серверу передается команда на изменение данных (например update )
происходит это так и никак иначе :
1. Открывается явная или неявная трнзакция информация об этом пишется в журнал транзакций
2. данные с диска закачиваются в память ( если нужные страницы уже в памяти то шаг 2 пропускается )
3. команды , данные и измененные данные заносяться в журнал транзакций
4. фиксируется транзакция информация об этом тоже заноситься в журнал транзакций
5. страница помечается как грязная
6. в будущем страница скидывается из памяти на диск и страница помечается как чистая.
Операции 2-4 синхронные
операция 5 не дисковая.
операция 6 ассинхронная.
задания 1-6 выполняюся непрерывно и паралельно разными процессами.
При этом запись в журнал транзакций идет строго последовательно на запись.
Но все меняется если происходит откат транзакции то чтение из журнала транзакций идет блоками
причем эти блоки не расположены друг за доугом (из-за других множества одновременно пишущих процессов),
одним словом при откате транзакций можно считать что
доступ к журналу транзакций прямой и при этом вся информация об откате
также последовательно пишеться в журнал транзакций.
ну и как бы следствие при откате транзакции sql серверу надо сделать на порядок больше работы
чем при успешной фиксации транзакции.(поэтому по возможности избегайте откатов транзакций).
Т.е. если у Вас есть два конкрурирующих процесса ( самом деле их гораздо больше)
и журнал и mdf файл будут расположены
на одном диске то вполне возможны задержки и на уровне контролера и на уровне диска ( а это особено печально
т.к. скорость перемещения головок очень маленькая по сравнению с другими скоростями ).
Поэтому разнос файлов данных и журналов обкспечивает более лучшую общую производительность
дисковой системы sql сервера. Т.е разные диски обеспечивают разнесение потоков ( без столкновений)
потока данных и потока журнала транзакций.
Еще как дополнительный бонус при выбранной конфигурации дисковой системы
мы избегаем внешней фрагментации файлов(пустячок а приятно) основной базы данных.
На оставшийся диск e вынесена база tempdb и другие вспомогательные базы
тоже вроде все понятно. Microsoft рекомендует по возможности базу tempdb размещать на быстрый диск.
Страницы: [1] 
переход 1сv77 базы на ms sql2005 64х (число прочтений - 11523 )
