Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Вопрос к DBA по рефакторингу базы  [new]
Иван Ивыныч Иванов
Guest
Здравствуйте. Такая ситуация: есть база в которой штук пять "ходовых" таблиц (по 300000 строк), использующихся в большинстве запросов. И возникла мысль разнести их по отдельным файлам на разных дисках, чтобы использовать весь рейд массив хардов на сервере. Стоит ли это вообще затевать, какие проблемы могут возникнуть в связи с этим ?

З.Ы. Microsoft SQL Server 2000 (SP4)
14 окт 09, 07:36    [7782207]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Knyazev Alexey
Member

Откуда: Екб -> Мск
Сообщений: 10234
Блог
можно поэксперементировать, разнести по разным файловым группам (на разных дисках)...
теоретически должно ускорить работу, так же посмотрите в сторону секционирования
14 окт 09, 07:39    [7782214]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Влом регистрироваться
Guest
Иван Ивыныч Иванов,

рефакторинг базы - это несколько иное (уж было обрадовался интересной теме).

А что, у вас на таких маленьких таблицах что-то тормозит? Может просто индексы посмотреть?
14 окт 09, 08:05    [7782237]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
автор
Стоит ли это вообще затевать


Без определенияболее ясных целей, чем:

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


нет, ибо

автор
по 300000 строк


это очень маленькие таблички.

Если есть проблемы с производительностью, то надо сначала определить их причины.
14 окт 09, 08:25    [7782275]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Иван Ивыныч Иванов
Guest

рефакторинг базы - это несколько иное (уж было обрадовался интересной теме).

Пардон, если я в терминологии напутал.

В чем идея всего этого. Есть Центральный Запрос, офорленный в виде вьюхи vMainQuery, который определяет доступную информацию. Все остальные запросы базы работают через него:
select t.* from Tabl1 t join vMainQuery... 
Это автоматически накладывает на него требование того, чтобы он "летал". В силу сложившихся обстоятельств архитектура базы такова, что есть центальная таблица, скажем Сущность, и все остальные сущности (физ, юр лица, банки, счета) определяются через нее. Скажем если нужно физ. лицо, то делаю запрос вида
select * form ФизЛицо join Сущность on ID=ID
Банк
select * form Банк join Сущность on ID=ID
и т.д.
Теперь к сути. Центальный Запрос имеет примерно следующий вид:
Select КонкретныйПроцес.*
from Процесы
join КонкретныйПроцес on ID=ID and КонкретныйПроцес.Тип='Выполняется'
and EXISTS
(
[b]
     select top 1 1 
	 from Пользователи P
     join
     (
         select Филиал.Permission 
         from Филиал join Сущность СущностьФилиала on СущностьФилиала.ID=Филиал.ID
		 join Сущность СущностьПроцеса on СущностьПроцеса.Филиал=СущностьФилиала.Код and СущностьПроцеса.Код=КонкретныйПроцес.КодПроцесса
			UNION ALL
         select Филиал.Permission 
         from Филиал join Сущность СущностьФилиала on СущностьФилиала.ID=Филиал.ID and СущностьФилиала.Код=КонкретныйПроцес.КодФилиала and КонкретныйПроцес.Тип=19
     )where Пользователи.User=Current_User
[/b]
)
JOIN
(
	Select Код
	From Сущность
    Cross join 
    (
       Select Роль from Роли join Пользователи on Роли.ID=Пользователи.ID and Пользователи.User=Current_User and Роли.Роль='Ограниченный'
    ) P where Сущность.Удаленная=0 and P.Роль is NULL
		UNION 
	Select Код from Сущность where Ответственный is NULL
		UNION 
	Select Код from Сущность C
	join СущностиПользователи СП on С.Ответственный=СП.Код 
	join Пользователи П on П.ID=СП.ID and Пользователи.User=Current_User 
) ДоступныеПроцессы on ДоступныеПроцессы.Код=КонкретныйПроцес.Код

Как видите, обращений к таблице Сущность очень много. Особенно в говнокоде EXISTS выделенном жирным шрифтом. Он будет колбаситься для каждой из 100000 строк выборки. А сделано это так по причине того, что этот запрос создается динамически. Жирные параметры это условия определения разрешений, которые я могу задавать для процесса. Скажем я пишу что для такого то процесса разрешения брать по такому то условию, и тогда когда создается вьюха то я читаю алгоритм выборки из таблицы и подсовываю его в Exists. Проблема в том что производительность этого Центрального Запроса неприемлимо медленна. Все идеи по его оптимизации у меня закончились. Осталоось переделка всех архитектуры но этого делать не хочется, потому я решил оптимизировать все разнесением по разным жестким для увеличения его производительности
14 окт 09, 09:21    [7782406]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
автор
Проблема в том что производительность этого Центрального Запроса неприемлимо медленна.


Ну так показывайте его план в текстовом виде и DDL на таблицы с индексами.
14 окт 09, 09:35    [7782450]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36814
Иван Ивыныч Иванов
Он будет колбаситься для каждой из 100000 строк выборки.
Вы это сами придумали или в плане увидали?
14 окт 09, 12:12    [7783687]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Иван Ивыныч Иванов
Guest
автор
Вы это сами придумали или в плане увидали?

В плане запроса, да и по смыслу если, то Exists выполняется же для каждой строки выбоки. Ну и кост по IO у него самый большой - 200, тогда как остальные опреации имеют 0 с хреном в минус второй
14 окт 09, 12:49    [7784046]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
Иван Ивыныч Иванов
автор
Вы это сами придумали или в плане увидали?

В плане запроса, да и по смыслу если, то Exists выполняется же для каждой строки выбоки. Ну и кост по IO у него самый большой - 200, тогда как остальные опреации имеют 0 с хреном в минус второй

И вы думаете, что размещение таблиц по разным файловым группам умешит число выполнений подзапроса Exists ?
14 окт 09, 12:52    [7784078]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Иван Ивыныч Иванов
Guest
автор
И вы думаете, что размещение таблиц по разным файловым группам умешит число выполнений подзапроса Exists ?

Не уменьшит - запрос то тот же. Просто я думал что если эти дикие чтения будут делаться с отдельного жесткого то это позволит осущесвить распределение нагрузки, может появится какой нибудь параллелизм и запрос начнет бегать быстрее.
14 окт 09, 13:07    [7784190]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
автор
эти дикие чтения


Это Ваши предположения подтверждаются планом выполнения и статистикой IO?
14 окт 09, 13:09    [7784211]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
Иван Ивыныч Иванов
автор
И вы думаете, что размещение таблиц по разным файловым группам умешит число выполнений подзапроса Exists ?

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

Т.е. вам Performance Monitor показал "дикие чтения" при выполнении этого запроса ? Или DBCC SQLPERF(WAITSTATS) ?
14 окт 09, 13:11    [7784227]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Иван Ивыныч Иванов
Guest
автор

Это Ваши предположения подтверждаются планом выполнения и статистикой IO?

Да, судя по фактическому плану выполнения на тестовом(моем) компе.

автор
Т.е. вам Performance Monitor показал "дикие чтения" при выполнении этого запроса ? Или DBCC SQLPERF(WAITSTATS) ?

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

З.Ы. 1 Запрос этот и раньше крпутился. Добавился только последний джоин после Exists.
З.Ы. 2 DBCC SQLPERF(WAITSTATS) в какой момент это применять ?
14 окт 09, 13:31    [7784418]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
Иван Ивыныч Иванов


автор
Т.е. вам Performance Monitor показал "дикие чтения" при выполнении этого запроса ? Или DBCC SQLPERF(WAITSTATS) ?

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

И вы смотрели предварительный план выполнения на промышленном сервере ?
И что такое "база просела" ?
14 окт 09, 13:33    [7784448]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Иван Ивыныч Иванов
Guest
Просела в том что счетчики процессора и очереди IO устремились рзеко вверх, запросы пользователей замедлелись от 0 до нескольких секунд.

автор

DBCC SQLPERF(WAITSTATS)


я запустил это на рабочем серваке:
 DBCC SQLPERF(WAITSTATS,CLEAR) 
 DBCC SQLPERF(WAITSTATS) 
на какие цифры смотреть внимание?

С планом запроса на боевом сервере фигня какая то: команда
set statistics profile on
не обрабатывается - возвращает простой селект. как исправить пока не знаю.
14 окт 09, 14:19    [7784845]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
Для получения предварительного плана достаточно в меню QA выбрать соответствующий пункт
А в WAITSTATS нужно смотреть, какой тип ожидания дает наибольшие цифры
14 окт 09, 14:24    [7784899]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Иван Ивыныч Иванов
Guest
автор

Для получения предварительного плана достаточно в меню QA выбрать соответствующий пункт


А фактический разве не лучше узнать сразу ?

А вообще какой порядок работы с WAITSTATS
сначала запрос а потом WAITSTATS или это вообще никак между собой не связано?
а цифры такие:
Total7411.00251530.00817252.00
RESOURCE_QUEUE99.00179203.0025000.00
SLEEP35.0047000.0047000.00
LCK_M_S2.009953.00.00
CXPACKET240.006785.0016.00
LATCH_EX5772.005499.00343.00
OLEDB685.001531.00744893.00
PAGEIOLATCH_SH85.001371.00.00
WRITELOG22.0079.00.00
DTC1.0062.00.00
PAGEIOLATCH_EX2.0031.00.00
PAGELATCH_UP143.0016.00.00
PAGELATCH_EX3.00.00.00


Сообщение было отредактировано: 14 окт 09, 14:33
14 окт 09, 14:30    [7784949]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
Иван Ивыныч Иванов
автор

Для получения предварительного плана достаточно в меню QA выбрать соответствующий пункт


А фактический разве не лучше узнать сразу ?

Ну а зачем вы тогда прервали выполнение запроса ?
14 окт 09, 14:34    [7784991]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
Иван Ивыныч Иванов

А вообще какой порядок работы с WAITSTATS
сначала запрос а потом WAITSTATS или это вообще никак между собой не связано?

WAITSTATS - это не анализатор текущего запроса. Это аккамулятор статистики многих запросов для выяснение узких мест системы. Не нужно было его очищать
14 окт 09, 14:36    [7785010]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Иван Ивыныч Иванов
Guest
автор

Ну а зачем вы тогда прервали выполнение запроса ?

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

автор
Не нужно было его очищать

Черт. затвра тогда соберу статистику.и все таки на что смотреть ?
RESOURCE_QUEUE с waittime= 179203.00 это много или нет? где можно почитатть про такое?
Попутный вопрос сразу. из-за чего на базе может не отрабатывать
 set statistics profile on
это определяется каким то специальными пермишанами?
14 окт 09, 14:43    [7785068]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос к DBA по рефакторингу базы  [new]
Glory
Member

Откуда:
Сообщений: 104760
Иван Ивыныч Иванов
автор

Ну а зачем вы тогда прервали выполнение запроса ?

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

- Тогда я вас не пойму. Плана выполнения у вас нет и получить вы его не стремитесь
- Если что-то не работает, то сервер генерирует ошибку. Если ошибки нет, то значит, что все работает
14 окт 09, 14:49    [7785106]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить