Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Про производительность  [new]
alex8901
Guest
волей случая получил часть проекта в котором есть база на 100+ GB на основе которой делается планирование. каждый день в базу сливаются данные из других систем и потом на основе этих данных делаются некоторые расчеты левым приложением. моя задача - доработка "левого приложения". сразу же столкнулся с кучей тормозов т.к. в основном на нужных мне таблицах нет ни индексов, ни primary keys. банальный select count(*) выполняется за 20 сек. а в основном все запросы которые приходится выполнять используют множественные JOIN (опять же по полям на которых отсутствуют индексы). спрашиваю, че за фигня. отвечают, пробовали ставить индексы и primary keys, но тогда начинает тормозить процесс "слива" данных, который выполняется каждую ночь. мол, без ключей он занимает пару часов, с ключами - значительно много больше. поэтому ни ключей ни индексов.

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

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

идею добавления primary keys завернули несмотря на то что я сделал тест на копии одной из таблиц куда добавил clustered primary key в виде дополнительного поля. select count(*) стал выполняться за 0 сек, а выборка по другим полям (которую использует левое приложение) стала выполняться в 2 раза быстрее. как вариант есть возможность сделать копии "нужных" таблиц с primary keys и индексами, копировать все данные из оригинала и потом использовать эти "проиндексированные дубликаты".

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

SQL 2000
27 май 09, 11:42    [7233244]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36807
1. select count(*) - нихрена не банальный запрос, приводящий к скану индкса/таблицы и работающий пропорционально размеру таблицы. И, самое главное, непонятно зачем нужный.

2. Пробовали сначала сливать данные во временные/перманентные таблицы без ключей/индексов, а потом уже раскладывать как надо?
27 май 09, 11:47    [7233318]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
alex8901
Guest
1. согласен. "банальность" была к слову, чтобы показать как работает база

2. задача "левого приложения" в общем-то и состоит чтобы из таблиц без индексов

- сделать выборку (например, за текущий год),
- произвести некую калькуляцию (например, Sum(Price)/Sum(Quantity) .... Group by ProductGroup)
- залить эту выборку в другую таблицу.

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

поэтому я и хотел послушать мнения что тут можно сделать

- оставить как есть, т.к. "левое приложение" не критично к скорости
- делать дубликаты таблиц
- поставить ключи
- нанять нормального DBA :-)
27 май 09, 12:18    [7233585]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31194
alex8901
поэтому я и хотел послушать мнения что тут можно сделать

- оставить как есть, т.к. "левое приложение" не критично к скорости
- делать дубликаты таблиц
- поставить ключи
- нанять нормального DBA :-)

оставить как есть, т.к. "левое приложение" не критично к скорости

Ставит задачи и выделят бабло на их решение бизнес в соостветствии со своими потребностями.
27 май 09, 12:35    [7233713]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
komrad
Member

Откуда: Msk -> Utrecht
Сообщений: 5189
alex8901
- оставить как есть, т.к. "левое приложение" не критично к скорости

своими действиями "левое" приложение вымывает кэш сиквела и приводит к снижению скорости работы других приложений
+ осуществляет нагрузочное тестирование дисковой подсистемы в риал-тайме ;)
27 май 09, 12:46    [7233788]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
alex8901
Guest
komrad, и что вы предлагаете?
27 май 09, 12:49    [7233815]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
Crimean
Member

Откуда:
Сообщений: 13148
индексы - делать. но хитро. "слив" данных усложнить. перед сливом - снести индексы. после слива - построить заново. возможно сносить / строить не все, пробовать надо
в итоге слив не сильно замедлится а отчетность "взлетит"
когда большая база трансферится индексы обычно снимаются - разница заливки действительно в разы
27 май 09, 13:23    [7234187]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
komrad
Member

Откуда: Msk -> Utrecht
Сообщений: 5189
alex8901
komrad, и что вы предлагаете?

если народ устраивает общая производительность сиквела (особенно в моменты работы "левого" приложения, то не ломиться в закрытую дверь

если есть жалобы или волнение в умах, то предложить свое аргументированное решение подкрепленное тестами и выигрышем по времени / деньгам для бизнеса

На самом в случае "если №1" была история по "разгону" приложения, в базе которого вообще практически не было индексов. С этой БД работал склад и офис. Когда работал склад (заливка данных, порядка 1-2 часов), то в офисе всё подвисало. Бизнес наловчился разводить эти операции по времени, т.е. существовал регламент работы для склада и офиса.
Так что бизнес - это еще тот зверь! ;)
27 май 09, 13:26    [7234214]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
VZaich
Member

Откуда:
Сообщений: 19
Crimean
индексы - делать. но хитро. "слив" данных усложнить. перед сливом - снести индексы. после слива - построить заново. возможно сносить / строить не все, пробовать надо
в итоге слив не сильно замедлится а отчетность "взлетит"
когда большая база трансферится индексы обычно снимаются - разница заливки действительно в разы


+1
27 май 09, 14:01    [7234543]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
alex8901
Guest
автор
индексы - делать. но хитро. "слив" данных усложнить. перед сливом - снести индексы. после слива - построить заново. возможно сносить / строить не все, пробовать надо
в итоге слив не сильно замедлится а отчетность "взлетит"
когда большая база трансферится индексы обычно снимаются - разница заливки действительно в разы

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

автор
Так что бизнес - это еще тот зверь! ;)

как по мне так они рубят сук на котором сидят. база только накапливает данные, индексов не строят мотивируя ускорением "заливки", с другой стороны говорят что "неплохо бы увеличить скорость работы". команда поддержки уповает на то что когда-нибудь бизнес раскошелится на sql 2008, который как думают автоматически решит все проблемы
27 май 09, 17:34    [7236328]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
iljy
Guest
alex8901
автор
индексы - делать. но хитро. "слив" данных усложнить. перед сливом - снести индексы. после слива - построить заново. возможно сносить / строить не все, пробовать надо
в итоге слив не сильно замедлится а отчетность "взлетит"
когда большая база трансферится индексы обычно снимаются - разница заливки действительно в разы

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

Постройте на таблице индексы какие надо, а при заливке отключайте (ALTER INDEX Index_Name ON Table_Name DISABLE) все, кроме кластерного - по идее грамотно сделаный кластерный тормозить заливку сильно не должен, а вот перестроение его может стать дорогим. после заливки - ALTER INDEX Index_Name ON Table_Name REBUILD


Так что бизнес - это еще тот зверь! ;)

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

ню-ню, а потом машины восстанут и безнес станет уже не нужен;)
27 май 09, 17:46    [7236406]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
alex8901
Guest
Постройте на таблице индексы какие надо, а при заливке отключайте (ALTER INDEX Index_Name ON Table_Name DISABLE) все, кроме кластерного - по идее грамотно сделаный кластерный тормозить заливку сильно не должен, а вот перестроение его может стать дорогим. после заливки - ALTER INDEX Index_Name ON Table_Name REBUILD


спасибо так и сделаю, проблема правда в том что места для копии базы нет, на рабочей тестировать не дадут, надо как-то изворачиваться
27 май 09, 18:14    [7236576]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
iljy
Guest
alex8901

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


Вот вам способ - поставьте себе SQL Express, создайте на нем две таблицы одинаковой структуры, одну с индексами, другую без, потом подключите к нему рабочий сервер как linked server и запустите
insert into Local_Table_1 select top (1000000) * from WorkingTable
а потом
ALTER INDEX ... DISABLE
...
insert into Local_Table_2 select top (1000000) * from WorkingTable

ALTER INDEX ... REBUILD
...

и замерьте разницу. 100% точности не получится, но думаю качественную картину оценить сможете. Если 1000000 слишком много - поставьте поменьше.
27 май 09, 18:25    [7236605]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
iljy
Guest
alex8901,

забыл еще один финальный штрих - выполните на обоих таблицах самый долгий запрос из исходной базы. И результат - к отчетности.
27 май 09, 18:26    [7236616]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
Crimean
Member

Откуда:
Сообщений: 13148
2 iljy

> SQL 2000

похоже, основательно забыли про это условие?
27 май 09, 21:17    [7237041]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
iljy
Guest
Crimean
2 iljy

> SQL 2000

похоже, основательно забыли про это условие?

упс, сори. но принципиально ничего не меняется, вместо SQL Express - MSDE (хотя это не обязательно), вместо ALTER INDEX - DROP INDEX/CREATE INDEX, слова про кластерный индекс остаются в силе.
27 май 09, 21:40    [7237105]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
alex8901
Guest
млин, я уже было лыжи намылил пробовать ;-(( сам в основном с 2005-м работаю, не дошло посмотреть BOL

не знаю как быстро работает DISABLE, но вот c DROP и CREATE по-моему будут тормоза
27 май 09, 22:54    [7237279]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
alex8901
Guest
ну конечно для теста будет важно. так что все равно сделаю
27 май 09, 22:55    [7237280]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
iljy
Guest
alex8901
ну конечно для теста будет важно. так что все равно сделаю

да нет, принципиальной разницы никакой. ALTER INDEX просто инфу о нем из системных таблиц не удаляет, а индекс все равно создается заново фактически. т.е. вы проигрываете на операции удаления-вставки в системные таблицы, ну возможно еще некоторые операции с освобождением страниц индекса, но не думаю что это существенно изменит картину.
27 май 09, 23:44    [7237371]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
--__Александр__--
Member

Откуда:
Сообщений: 2631
ИМХО
-От кластерного индекса лучше отказаться.
-Оценить отношение А=кол-во новых данных)/(кол-во старых данных).
-Взависимости от значения А сделать вывод о целесообразности или не целесообразности
пересоздавать каждый раз индексы(в вашем случае скоре всего от пересоздания индекса занова выигрыша не будет)

ИМХО, у вас руководство неадекватное. В SQL Server-е разбирается слабо, а еще какие-то догадки строит.
Если задачи от бизнеса по рефакторингу БД и процесса заливки нет, то лучше не рыпаться.
Испортите чего-нибудь, вам же потом хуже будет.
28 май 09, 08:18    [7237675]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
Crimean
Member

Откуда:
Сообщений: 13148
в принципе, если оборудования хватает, то можно эту "нагруженную" базу вынести на отдельные диски и на отдельный инстанс, которому порезать процессора через афинити и память. и будет некое распределение нагрузки даже под 2000 :)
по крайней мере остальные задачи останавливаться не будут. или на 2005/2008 переходите - там UMS поменян и остальных ваша база без индексов будет тормозить СИЛЬНО меньше, хотя, конечно, если все на одном диске то чуда не случится
28 май 09, 10:56    [7238129]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
alex8901
Guest
--__Александр__--, данные приходят каждый день новые. Т.е. job делает truncate и заливает все по-новой. В чем система я не знаю, скорее всего разработчикам было лень писать проверку существующих записей (или она долго занимает).

автор
Если задачи от бизнеса по рефакторингу БД и процесса заливки нет

по-моему такого не бывает. бизнес даже не знает что-такое "БД", не то что "рефакторинг"
28 май 09, 11:18    [7238262]     Ответить | Цитировать Сообщить модератору
 Re: Про производительность  [new]
--__Александр__--
Member

Откуда:
Сообщений: 2631
alex8901
Тогда да, лучше индексы убивать перед заливкой и воссоздавать заново.

Под "бизнесом" я имел ввиду вашего IT начальника.
28 май 09, 18:26    [7241511]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить