Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: ←Ctrl назад 1 2 [3] 4 вперед Ctrl→ все |
импосибле имплементе
Guest |
JustCurious,
все идентификаторы переделать на int/bigint начать можно с нахрен никому не нужного "GUID" строки ЖУРНАЛА
да. это делается с помощью гуидов. а без гуидов - сооветственно - вообще не делается. |
||||
16 сен 15, 12:14 [18155313] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
по-моему, без данных о железе вообще разговор ни о чем. у нас тоже стонут и жалуются, у самих 48Гиг памяти и кучка баз по 2Тб, ну так в одной нашей основная таблица 400 гиг и ее постоянно ВСЮ лопатят (угадайте наше PLE с 3-х раз!) зарефакториться можно, но толку будет 0 все равно. а еще их супер-диски плачут постоянно, еррорлог -- это коллекция сообщений вида SQL Server has encountered 4506 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file... зато мы имеем постоянную и гарантированную неприемлемую производительность, значит, всем есть, чем заняться. кстати, они видимо еще и подстраховались на случай малых объемов и выставили серверный FF 80%. у нас вообще-то DWH, 2 базы вообще READ ONLY, остальные заливаются через SELECT INTO, кластерные потом сверху навешиваются, разреживая таблицы, чтоб больше места заняли. думаю, если вдруг размер баз уменьшился бы, они бы FF в 30 выставили или в 10. --- и как это все увидеть без доступа к серверу? |
16 сен 15, 12:36 [18155426] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5516 |
сильно сомневаюсь, что автору топика дадут что либо переделывать в боевой базе, если у него задача "за 100 баксов ускорить отчет" тем более, что база у клиентов, доступ только к UAT с тестовыми данными (34 турбины) |
||||||
16 сен 15, 12:56 [18155538] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
у него в первом посте как раз хотят улучшить производительность за счет изменения структуры: "I think the idea is not to optimize on each individual SQL stmt, it's more to see if there is smth generally we can change in DB structure to give a performance boost" |
||
16 сен 15, 13:15 [18155669] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5516 |
проглядел ;) |
||||
16 сен 15, 13:16 [18155679] Ответить | Цитировать Сообщить модератору |
Мих001 Member [заблокирован] Откуда: Сообщений: 121 |
и как ты к такому выводу пришел? |
||
16 сен 15, 16:05 [18156954] Ответить | Цитировать Сообщить модератору |
JustCurious Member Откуда: UA Сообщений: 94 |
Высокая врагментация влияет на объём считываемых данных. |
||||
16 сен 15, 16:48 [18157249] Ответить | Цитировать Сообщить модератору |
churupaha Member Откуда: Краснодар Сообщений: 1015 |
А как выяснили, что именно фрагментация является причиной сейчас? Потому, что многие говорят и везде написано об этом? Или вы уже посмотрели sys.dm_db_index_physical_stats увидели высокий уровень фрагментации? Сделали rebuild и все начало летать? |
||||
16 сен 15, 17:16 [18157390] Ответить | Цитировать Сообщить модератору |
JustCurious Member Откуда: UA Сообщений: 94 |
Именно так. Посмотрели dmv, убрали кластерный индекс с ПК по ГУИДу и перестроили его по другим полям. |
||||
16 сен 15, 17:35 [18157490] Ответить | Цитировать Сообщить модератору |
JustCurious Member Откуда: UA Сообщений: 94 |
Не заметил слова сейчас в предыдущем посте |
16 сен 15, 17:36 [18157499] Ответить | Цитировать Сообщить модератору |
Мих001 Member [заблокирован] Откуда: Сообщений: 121 |
короче если к тому что вы описали делаете ещё дефрагментацию диска и обновление статистик то нужно смотреть почему у вас при линейном увеличении данных нелинейно растет нагрузка тут кроме тупости админов может быть ещё то что у вас алгоритм перелопачивает все данные каждый раз тогда вам нужно переработать его так чтобы были промежуточные результаты какие-то или результаты предварительных расчетов а если вам принципиально например складывать всё каждый раз то добавьте оперативы много до предела и проца насколько хватит денег ИМХО если скуль не задавлен дибильными настройками и отсутствием регламента в нем и на виндах под ним то вычислительные его способности таковы что нужно сильно постараться чтобы они стали неприемлемы смотрите как происходят вычисления, возможно там и есть узкое место а лучше позовите специалиста |
||
17 сен 15, 09:33 [18159133] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
А то. Каждый день. Индексы же на диске, дефрагментированы. Боремся ![]() |
||
17 сен 15, 09:49 [18159189] Ответить | Цитировать Сообщить модератору |
Мих001 Member [заблокирован] Откуда: Сообщений: 121 |
ещё пожать все таблицы и индексы |
17 сен 15, 14:08 [18160840] Ответить | Цитировать Сообщить модератору |
хлебороб
Guest |
Мих001, сначала - посеять. а сентябрь на дворе. |
17 сен 15, 14:13 [18160886] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9646 |
Вы поменяли у таблицы кластерный индекс. Соответственно, планы запросов, в которых она участвует, тоже изменились. |
||
17 сен 15, 14:35 [18161052] Ответить | Цитировать Сообщить модератору |
Мих001 Member [заблокирован] Откуда: Сообщений: 121 |
сжатие применить если это ms sql, в других скорее всего и так оно включено |
||
17 сен 15, 14:37 [18161075] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
![]() |
17 сен 15, 14:38 [18161084] Ответить | Цитировать Сообщить модератору |
Мих001 Member [заблокирован] Откуда: Сообщений: 121 |
я так понял в контексте что база стала тупо меньше размером когда этот индекс удалили ибо затраты на апдейт индекса тут не актуальны |
||||
17 сен 15, 14:38 [18161090] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
Мих001, давайте еще. кстати, если *все* индексы удалить, база станет еще меньше. вот тогда все и залетает. |
17 сен 15, 14:46 [18161160] Ответить | Цитировать Сообщить модератору |
Мих001 Member [заблокирован] Откуда: Сообщений: 121 |
ты ветку почитай автор же сам чайник и инфы дал минимум но если он решил проблемы тем что индекс снес то как бы в контексте других вариантов нет почему стало лучше |
||
17 сен 15, 14:54 [18161239] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
вы шо, я букв и то знаю только 3, а тут аж 3 страницы, захлебнусь еще ненароком. индекс, кстати, кластерный был, вы чуете, сколько ж места высвободилось-то? аж дефрагментировать стало нечего, надо бы оплакать это дело |
||
17 сен 15, 14:59 [18161271] Ответить | Цитировать Сообщить модератору |
Мих001 Member [заблокирован] Откуда: Сообщений: 121 |
я хз тут замеры рулят |
||||
17 сен 15, 15:02 [18161305] Ответить | Цитировать Сообщить модератору |
Мих001 Member [заблокирован] Откуда: Сообщений: 121 |
o-o, я обычно запускаю мониторы производительности виндовый и скульны и медитирую в моменты нагрузок если там смотреть нечего значит сервер "придавлен" если есть то можно уже в алгоритмы заглянуть идеально в пик должно быть 100% все процы и спад потом до нуля (без фона т.е.) с этого малого можно дальше смотреть а у нас обычно дядки в разных кабинетах которые имеют на всё это права и каждый гадит по своему |
17 сен 15, 15:05 [18161328] Ответить | Цитировать Сообщить модератору |
JustCurious Member Откуда: UA Сообщений: 94 |
ЧСВ поднимаешь своё? ) Всё относительно, для тебя я - чайник, для товарища Ицика Бен-Гана - ты.
Дал, сколько было у самого. Над этим проектом могу работать только после осн.работы, и за 4 дня удалось уделить толко полчаса времени на него. |
||||
18 сен 15, 11:56 [18164735] Ответить | Цитировать Сообщить модератору |
JustCurious Member Откуда: UA Сообщений: 94 |
Я понял, что Вы имеете в виду. Тогда так - на предыдущих кластерных индексах были менее оптимальные планы и более высокая фрагментация. |
||||
18 сен 15, 12:26 [18164895] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: ←Ctrl назад 1 2 [3] 4 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |