Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Производительность, распределение данных по файлам внутри ФГ, перенос данных между файлами  [new]
Eugene_p1
Member

Откуда: Москва
Сообщений: 295
ДД!

Коллеги, помогите пожалуйста!

Классическая ситуация. Есть кривой софт, который нельзя изменять. Работает с
Microsoft SQL Server 2000 - 8.00.2273 (Intel X86) Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2)
в нескольких полностью отдельных офисах.
База разрослась до 200-250 гиг, и начались серьезные проблемы с быстродействием. Железо старенькое и апгрейд не светит. (IBM x260/16Gb/12x146Gb SAS). В некоторых офисах используется RAID5, и админы клятвенно уверяют меня, что по тестам с DB он не проигрывает RAID10-му (хотя у меня иное мнение на этот счет). Типовая конфигурация массива: 2xHDD - RAID1 (system), 8-9xHDD RAID5 (data), 1-2хHDD hotspare.
TempDB используется время от времени достаточно серьезно, но в основном ночью, во время пересчета, а претензии к производительности круглосуточные, т.е. и у пользователей. Заметное понижение производительности произошло после роста базы до 200 гиг.
Пользователей 90-140 днем, и только системные ночью.

Почитал форум.
Решил для поднятия производительности на тестовой машине перенести индексы в отдельную файлгруппу, и создать по 2 файла в файлгруппе. Итого, 2х2 файла, +1 лог, +4 файла на tempdb.
Физически файлгруппы на разных дисках (D:, E:), tempdb на C:, лог ПОКА на D:, но после замеров перенесу на F:.
1 логический диск = 1 физический.

Вопросы следующие:
1. Правильно ли я двигаюсь в плане отделения индексов от таблиц? Размер индексов больше размера данных в 1.2-1.5 раза.
2. Сколько должно быть свободного места в базе (база скорее OLAP)?
3. Дополнительный файл создается пустым. Как перенести в него половину данных из основного файла? Предполагаю в итоге хранить каждый файл на отдельном RAID1.
4. В случае, если я восстановлю базу из бэкапа, конфигурация файлов сохранится, или будет перезаписана?

Интересно ваше мнение.
Какая дополнительная информация нужна?
17 май 11, 20:49    [10667697]     Ответить | Цитировать Сообщить модератору
 Re: Производительность, распределение данных по файлам внутри ФГ, перенос данных между файлами  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31948
Eugene_p1
Вопросы следующие:
1. Правильно ли я двигаюсь в плане отделения индексов от таблиц? Размер индексов больше размера данных в 1.2-1.5 раза.
2. Сколько должно быть свободного места в базе (база скорее OLAP)?
3. Дополнительный файл создается пустым. Как перенести в него половину данных из основного файла? Предполагаю в итоге хранить каждый файл на отдельном RAID1.
4. В случае, если я восстановлю базу из бэкапа, конфигурация файлов сохранится, или будет перезаписана?
1. Нужно определить, какие именно операции тормозят. Может, дело и не в файлах.
Далее, для OLTP нужен в первую очередь отдельный быстрый диск (райд) для лога.
Разнесение индексов или отдельных таблиц на отдельные диски может и замедлить скорость. Тут нужно быть очень аккуратным.

2. Оно должно быть :-) , и такое, чтобы не было нужды постоянно увеличивать файл. Делайте свободное место на год вперёд.

3. Перестроением кластерного индекса

4. Будет перезаписана. Менять при восстановлении можно только расположение файлов.
17 май 11, 20:59    [10667729]     Ответить | Цитировать Сообщить модератору
 Re: Производительность, распределение данных по файлам внутри ФГ, перенос данных между файлами  [new]
Eugene_p1
Member

Откуда: Москва
Сообщений: 295
Спасибо!
База у нас OLAP.
Но не суть. Сегодня был проведен тест по ночным работам. 6 часов вместо 10. Неплохо вроде бы...

Ламерский вопрос - как перестроить кластерные индексы по всей базе (таблиц более 1500)?

Насчет места в логе.
Столкнулся с интересной ситуацией в одном из офисов.
Лог был 150 гиг, из них занято около 100 мег.
База ЖУТКО тормозила.
Интересно, почему (механика процесса)?
18 май 11, 11:31    [10669945]     Ответить | Цитировать Сообщить модератору
 Re: Производительность, распределение данных по файлам внутри ФГ, перенос данных между файлами  [new]
Glory
Member

Откуда:
Сообщений: 104751
Eugene_p1
Столкнулся с интересной ситуацией в одном из офисов.
Лог был 150 гиг, из них занято около 100 мег.
База ЖУТКО тормозила.
Интересно, почему (механика процесса)?

И как вы установили, что причина торможения именно в размере лога ?
18 май 11, 11:47    [10670096]     Ответить | Цитировать Сообщить модератору
 Re: Производительность, распределение данных по файлам внутри ФГ, перенос данных между файлами  [new]
Eugene_p1
Member

Откуда: Москва
Сообщений: 295
Glory
Eugene_p1
Столкнулся с интересной ситуацией в одном из офисов.
Лог был 150 гиг, из них занято около 100 мег.
База ЖУТКО тормозила.
Интересно, почему (механика процесса)?

И как вы установили, что причина торможения именно в размере лога ?

Srink'ом, разумеется. :)
18 май 11, 11:52    [10670157]     Ответить | Цитировать Сообщить модератору
 Re: Производительность, распределение данных по файлам внутри ФГ, перенос данных между файлами  [new]
Slava_Nik
Member

Откуда: из России
Сообщений: 901
Eugene_p1,

и что "shrink" сказал?
а по делу вопрос Glory, какую и как диагностику сделали?
18 май 11, 11:57    [10670202]     Ответить | Цитировать Сообщить модератору
 Re: Производительность, распределение данных по файлам внутри ФГ, перенос данных между файлами  [new]
Glory
Member

Откуда:
Сообщений: 104751
Eugene_p1
Glory
пропущено...

И как вы установили, что причина торможения именно в размере лога ?

Srink'ом, разумеется. :)

Srink - это новое средство диагностики/мониторинга ?
18 май 11, 11:59    [10670227]     Ответить | Цитировать Сообщить модератору
 Re: Производительность, распределение данных по файлам внутри ФГ, перенос данных между файлами  [new]
Eugene_p1
Member

Откуда: Москва
Сообщений: 295
Glory, ну зачем же язвить?
Просто после шринка лога сервер заработал гораздо быстрее (гораздо - это значит пользователи перестали ощущать торможения, а админ возрадовался :), точных данных - увы - не имею.).

Всё же я не исключаю, что было сделано что-то еще.
Поэтому перефразирую вопрос:
мог ли большой размер лога (при малой используемой части) замедлять работу сервера?

И всё-таки, самое важное - прокомментируйте пожалуйста ситуацию из первого сообщения.

Тут еще загадка подвернулась. Этот самый ночной job завешивал машину. В логах записи типа

Недостаточно системных ресурсов. "~~невозможно записать файл"
Невозможно писать в лог базы 1, потом 2, и так всех остальных.
Что-то насчет "программа, запускаемая из registry, не может писать на диск".
Естественно, на дисках полно места, файлы данных и логов не успевают заполниться и не увеличиваются, и т.п.

Было 12 гиг памяти, использовалось жестко 10.
Потом стало 14-12.
И только после установления 16-14 сервак перестал вешаться.

Вопросы:
В чем может крыться причина такого поведения? Насколько я понимаю, ошибка в системе, SQL Server здесь не при чем?
Памяти серверу отдавал меньше общей на 2 гига... с чем же может быть связано и как подиагностировать?
19 май 11, 01:57    [10675337]     Ответить | Цитировать Сообщить модератору
 Re: Производительность, распределение данных по файлам внутри ФГ, перенос данных между файлами  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2680
Разделение (не важно, таблиц, или индексов) по разным файлгруппам на MSSQL2000 может преследовать две основные цели.
1. Ускорение работы за счет разных дисковых массивов.
2. Подсказка для 2000-х врубить параллелизм. (он там хромает, и кстати, если есть гипертрединг, то вырубить, поэтому же)

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

Ну, а если после шринка проблемы частично исчезают - делайте шринк по шедулеру, ночью.
И поставьте рекавери в simple.
Тока тогда полные бэкапы делать почаще надо. :)
19 май 11, 03:49    [10675514]     Ответить | Цитировать Сообщить модератору
 Re: Производительность, распределение данных по файлам внутри ФГ, перенос данных между файлами  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2680
Eugene_p1
Насчет места в логе.
Столкнулся с интересной ситуацией в одном из офисов.
Лог был 150 гиг, из них занято около 100 мег.
База ЖУТКО тормозила.
Интересно, почему (механика процесса)?

Если Recovery стоит уже как simple, то это скорее всего означает, что бывают конкурирующие транзакции, которые кушают много.
Если у вас ночью пересчет на 6-10 часов, то это не сильно удивляет.
Можно и одной строкой запроса сожрать пару терабайт как в tempdb, так и в логах.
А потом как бы, по завершению... место занято, но пустует...
19 май 11, 03:55    [10675522]     Ответить | Цитировать Сообщить модератору
 Re: Производительность, распределение данных по файлам внутри ФГ, перенос данных между файлами  [new]
beginner_dba
Member

Откуда: Киев
Сообщений: 331
Makar4ik
Разделение (не важно, таблиц, или индексов) по разным файлгруппам на MSSQL2000 может преследовать две основные цели.
1. Ускорение работы за счет разных дисковых массивов.
2. Подсказка для 2000-х врубить параллелизм. (он там хромает, и кстати, если есть гипертрединг, то вырубить, поэтому же)

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

Ну, а если после шринка проблемы частично исчезают - делайте шринк по шедулеру, ночью.
И поставьте рекавери в simple.
Тока тогда полные бэкапы делать почаще надо. :)

Чтобы сервер бедняга, опять расширял лог.
У них 2000, значит log-shppinga нет, модель simple не позволит им восстановится на момент "Ч", а учитывая что база за 200 Гб и 140 юзеров..
Лучше делать еженочные полные копии, ежечасные дифф. копии и еже15минутные журнальные копии.
Потом какая-то глупость с разбиением диском у них, как можно хранить на массиве и журнал и данные. Лог тупо пишет последовательно, причем постоянно, значит нужно обеспечить "пишущим" массивом, в то же время лог нужно сохранить, значит зеркало. Данные имеют другую природу, они хранятся в разных частях диска и могут очень долго отличатся от данных ОЗУ, то есть здесь нужно обеспечить "читающим" массивом, например как у них 5-й рейд. Раз у них ОЛАП, то таблицу фактов лучше целиком вынести на отдельный массив.
19 май 11, 06:59    [10675615]     Ответить | Цитировать Сообщить модератору
 Re: Производительность, распределение данных по файлам внутри ФГ, перенос данных между файлами  [new]
beginner_dba
Member

Откуда: Киев
Сообщений: 331
Eugene_p1
Glory, ну зачем же язвить?
Просто после шринка лога сервер заработал гораздо быстрее (гораздо - это значит пользователи перестали ощущать торможения, а админ возрадовался :), точных данных - увы - не имею.).

Всё же я не исключаю, что было сделано что-то еще.
Поэтому перефразирую вопрос:
мог ли большой размер лога (при малой используемой части) замедлять работу сервера?

И всё-таки, самое важное - прокомментируйте пожалуйста ситуацию из первого сообщения.

Тут еще загадка подвернулась. Этот самый ночной job завешивал машину. В логах записи типа

Недостаточно системных ресурсов. "~~невозможно записать файл"
Невозможно писать в лог базы 1, потом 2, и так всех остальных.
Что-то насчет "программа, запускаемая из registry, не может писать на диск".
Естественно, на дисках полно места, файлы данных и логов не успевают заполниться и не увеличиваются, и т.п.

Было 12 гиг памяти, использовалось жестко 10.
Потом стало 14-12.
И только после установления 16-14 сервак перестал вешаться.

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


Разнести лог и данные по разным массивам, и за шринк введите смертную казнь.
Какие средние очереди дисковой подсистемы? Норма к-во шпинделей умножить на 1.5-2
19 май 11, 07:07    [10675620]     Ответить | Цитировать Сообщить модератору
 Re: Производительность, распределение данных по файлам внутри ФГ, перенос данных между файлами  [new]
Eugene_p1
Member

Откуда: Москва
Сообщений: 295
beginner_dba
Разнести лог и данные по разным массивам, и за шринк введите смертную казнь.
Какие средние очереди дисковой подсистемы? Норма к-во шпинделей умножить на 1.5-2

Про огромный лог - это был единичный случай.
Средние очереди на моём тестовом сервере - 1-3. 4 шпинделя на массив. В филиалах бывают скачки до 40 при 8 шпинделях, но, как я уже сказал, у них 5-й рэйд, всё на одном диске, и осторожные админы, которых нужно тыкнуть в материал, где написано, что RAID5 не для баз данных.

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

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

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

Про зависание есть мысли?
19 май 11, 11:41    [10676678]     Ответить | Цитировать Сообщить модератору
 Re: Производительность, распределение данных по файлам внутри ФГ, перенос данных между файлами  [new]
Eugene_p1
Member

Откуда: Москва
Сообщений: 295
К сожалению, я поторопился.
Тестовый сервер всё равно виснет.
20 май 11, 10:10    [10682362]     Ответить | Цитировать Сообщить модератору
 Re: Производительность, распределение данных по файлам внутри ФГ, перенос данных между файлами  [new]
Eugene_p1
Member

Откуда: Москва
Сообщений: 295
Журнал винды:

Тип события: Ошибка
Источник события: Service Control Manager
Время: 14:33:20
Описание:
Служба VMware Tools Service была неожиданно завершена. Это произошло 1 раз(а). Следующее корректирующее действие будет предпринято через 0 мсек: Перезапуск службы.

Тип события: Ошибка
Источник события: Application Popup
Время: 14:33:30
Описание:
Неустранимый сбой операции ввода/вывода, запущенной из реестра. Не удалось выполнить чтение, запись или запись буфера для одного из файлов, содержащих образ системного реестра.

Тип события: Ошибка
Источник события: MSSQLSERVER
Время: 14:33:57
Описание:
17053 :
LogWriter: Operating system error 1453(Недостаточная квота для завершения операции.) encountered.

Тип события: Ошибка
Источник события: MSSQLSERVER
Время: 14:34:17
Описание:
Error: 9001, Severity: 21, State: 1
The log for database 'tempdb' is not available.


И так далее по всем базам.
20 май 11, 11:42    [10683110]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить