Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Производительность БД  [new]
porcupine
Member

Откуда:
Сообщений: 26
o-o
статистики же не только по индексным колонкам бывают.

Понято
komrad
обычно как раз наоборот - раз в неделю реиндекс, апдейт статистик по необходимости ежесуточно
fullscan делают для критичных таблиц

кстати, ваш вариант реиндекса совсем тяжелый и не оптимальный - это либо специально, либо от незнания

Ну знаниями в sql не похвастаюсь, но регламенты настраивались по рекомендациям обслуживания баз 1С)
Статистики по данной схеме чаще не получается обновлять, долго выполняются, если делать во время активной работы тормоза серьезные.
13 янв 16, 23:31    [18675511]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
komrad
Member

Откуда:
Сообщений: 5758
porcupine
komrad
обычно как раз наоборот - раз в неделю реиндекс, апдейт статистик по необходимости ежесуточно
fullscan делают для критичных таблиц

кстати, ваш вариант реиндекса совсем тяжелый и не оптимальный - это либо специально, либо от незнания

Ну знаниями в sql не похвастаюсь, но регламенты настраивались по рекомендациям обслуживания баз 1С)
Статистики по данной схеме чаще не получается обновлять, долго выполняются, если делать во время активной работы тормоза серьезные.


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

кстати, весьма вероятно, что вам не нужен фуллскан всех таблиц, и апдейт может проходить быстрее

не настаиваю именно на этом решении, но гляньте сюда:
https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html

этот набор скриптов развернут в банке, где я сейчас работаю, на примерно 450-500 сиквелах
удобная штука с историей работы и гибкими настройками
13 янв 16, 23:39    [18675544]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
o-o
Guest
хотите анекдот в тему?
мне попался недавно интересный дэдлок.
2 разных процесса конвертировали Sch-S -> Sch-M на одном и том же объекте.
не, угадайте, что это было?
2 одинаковых шага у двух разных джобов, с одинаковым расписанием.
и шаг этот...обновление статистики.
кто бы мог подумать.
один джоб у них назывался вменяемо, Fulltext_Statistics.
а второй загадочно, BackupMonitor.
но у меня еще и ожидания раз в 5 минут пишутся,
смотрю, одинаковые команды на одном и том же объекте друг друга ждут, что за бред?
а вот так вот.
умельцы.
может, и у вас из разных джобов одно и то же делают одновременно?
вот время и возросло в 2 раза,,,

К сообщению приложен файл. Размер - 87Kb
13 янв 16, 23:41    [18675552]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
komrad
Member

Откуда:
Сообщений: 5758
o-o
хотите анекдот в тему?
мне попался недавно интересный дэдлок.
...
но у меня еще и ожидания раз в 5 минут пишутся,
смотрю, одинаковые команды на одном и том же объекте друг друга ждут, что за бред?


дедлок длиной в 5 минут?
их же сиквел проверяет каждые 5 сек...

параллельных апдейтов статистики не видел, но перестройку индексов в середине дня видал - приложение (sccm или sharepoint, уже не помню точно) само ломилось, не смотря на время, и мурыжило базу ;)
13 янв 16, 23:57    [18675598]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
porcupine
Member

Откуда:
Сообщений: 26
komrad
не настаиваю именно на этом решении, но гляньте сюда:
https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html


Спасибо, буду разбираться в этом подходе.

o-o
может, и у вас из разных джобов одно и то же делают одновременно?

Все регламенты разнесены по времени, что бы исключить пересечение.
14 янв 16, 00:04    [18675615]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34705
porcupine
.
Время реиндексации осталось прежним.


вот с этого момента пожалуйста поподробнее...
14 янв 16, 02:33    [18675862]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34705
porcupine
Из моих соображений. Возможна ли ситуация когда таблица разрастается до определенных размеров (самые большие таблицы от 60 до 100 гб) и сиквел меняет логику запросов к ним?


возможна.
также возможна ситуация когда "и сиквел меняет логику запросов к ним", но при этом предыдущего условия не соблюдается.
14 янв 16, 02:36    [18675863]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34705
porcupine
'
после DBCC FREEPROCCAHE

Реиндексация 1 раз в сутки
sp_msforeachtable N'DBCC DBREINDEX ()


а на кой?

DBCC FREEPROCCAHE тебе уже только сам по себе может давать тот эффект, о котором ты говорил - внезапная смена образа мышления оптимизатора.
14 янв 16, 02:39    [18675866]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
o-o
Guest
komrad
дедлок длиной в 5 минут?

нет.
дедлок как дедлок, попался в еррорлоге, для одного процесса был кусок кода с апдэйтом статистик, для второго ничего, непонятно было, что это вообще, ну разве можно было догадаться, что они оба апдэйтят одинаковым кодом? идея была, ну может он сам для какого-то запроса себе решил пересчитать.
граф надо? у меня сохранен...
а вот независимо от еррорлога у меня пишутся ожидания, раз в 5 минут, и уже на другой день, просматривая их, попалось то, что на картинке. с конкретным одинаковым кодом и гуидами заданий.
тогда и пролился свет на дедлок
14 янв 16, 07:42    [18675957]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
StarikNavy
Member

Откуда: Москва
Сообщений: 2415
komrad

не настаиваю именно на этом решении, но гляньте сюда:
https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html


тоже этим переодически пользуюсь. но (может что-то пропустил, прошу просветить), в этих скриптах нету процедуры пересчета статистики?
14 янв 16, 11:31    [18677027]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
porcupine
Member

Откуда:
Сообщений: 26
MasterZiv
вот с этого момента пожалуйста поподробнее...


Каждую ночь проводится реиндексация, после падения производительности длительность этого регламента не изменилась.
как было 2,5 - 3 часа, так и осталось.
А вот обновление статистик начало занимать в 2 раза больше времени.

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


Запускается опять же по рекомендациям обслуживания базы от 1С, после обновления статистик. 1раз в неделю.
14 янв 16, 13:08    [18677810]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
porcupine
Member

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


IndexOptimize.sql: Stored procedure to rebuild and reorganize indexes and update statistics
14 янв 16, 13:12    [18677856]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
komrad
Member

Откуда:
Сообщений: 5758
StarikNavy
komrad
не настаиваю именно на этом решении, но гляньте сюда:
https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html


тоже этим переодически пользуюсь. но (может что-то пропустил, прошу просветить), в этих скриптах нету процедуры пересчета статистики?


есть, но может у вас старая версия скриптов
поищите на странице по ссылке "UpdateStatistics"
14 янв 16, 13:22    [18677958]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
komrad
Member

Откуда:
Сообщений: 5758
MasterZiv
porcupine
'
после DBCC FREEPROCCAHE

Реиндексация 1 раз в сутки
sp_msforeachtable N'DBCC DBREINDEX ()


а на кой?

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

это во избежание cache pollution
такая рекомендация типична для 1С
нет же информации какая версия 1С, параметризированы ли частые запросы, структура процедурного кэша не ясна
14 янв 16, 13:43    [18678181]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
komrad
Member

Откуда:
Сообщений: 5758
porcupine,

кстати, а покажите, плз

select name,value,minimum,maximum,value_in_use
from sys.configurations
go
select @@version
go
select
	cpu_count
	,hyperthread_ratio
	,os_priority_class
	,affinity_type_desc
	,sqlserver_start_time
from sys.dm_os_sys_info 
go
14 янв 16, 13:45    [18678219]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
porcupine
Member

Откуда:
Сообщений: 26
komrad,

черный ящик в студию)

namevalue minimum maximum value_in_use
recovery interval (min) 0 0 32767 0
allow updates 0 0 1 0
user connections 0 0 32767 0
locks 0 5000 2147483647 0
open objects 0 0 2147483647 0
fill factor (%) 0 0 100 0
disallow results from triggers 0 0 1 0
nested triggers 1 0 1 1
server trigger recursion 1 0 1 1
remote access 1 0 1 1
default language 0 0 9999 0
cross db ownership chaining 0 0 1 0
max worker threads 2048 128 32767 2048
network packet size (B) 4096 512 32767 4096
show advanced options 1 0 1 1
remote proc trans 0 0 1 0
c2 audit mode 0 0 1 0
default full-text language 1033 0 2147483647 1033
two digit year cutoff 2049 1753 9999 2049
index create memory (KB) 0 704 2147483647 0
priority boost 1 0 1 1
remote login timeout (s) 20 0 2147483647 20
remote query timeout (s) 600 0 2147483647 600
cursor threshold -1 -1 2147483647 -1
set working set size 0 0 1 0
user options 0 0 32767 0
affinity mask 16777214 -2147483648 2147483647 16777214
max text repl size (B) 65536 -1 2147483647 65536
media retention 0 0 365 0
cost threshold for parallelism 500 0 32767 500
max degree of parallelism 2 0 1024 2
min memory per query (KB) 1024 512 2147483647 1024
query wait (s) -1 -1 2147483647 -1
min server memory (MB) 0 0 2147483647 16
max server memory (MB) 58000 16 2147483647 58000
query governor cost limit 0 0 2147483647 0
lightweight pooling 0 0 1 0
scan for startup procs 0 0 1 0
awe enabled 0 0 1 0
affinity64 mask 0 -2147483648 2147483647 0
affinity I/O mask 0 -2147483648 2147483647 0
affinity64 I/O mask 0 -2147483648 2147483647 0
transform noise words 0 0 1 0
precompute rank 0 0 1 0
PH timeout (s) 60 1 3600 60
clr enabled 0 0 1 0
max full-text crawl range 4 0 256 4
ft notify bandwidth (min) 0 0 32767 0
ft notify bandwidth (max) 100 0 32767 100
ft crawl bandwidth (min) 0 0 32767 0
ft crawl bandwidth (max) 100 0 32767 100
default trace enabled 1 0 1 1
blocked process threshold (s) 0 0 86400 0
in-doubt xact resolution 0 0 2 0
remote admin connections 0 0 1 0
common criteria compliance enabled 0 0 1 0
EKM provider enabled 0 0 1 0
backup compression default 0 0 1 0
filestream access level 0 0 2 0
optimize for ad hoc workloads 0 0 1 0
access check cache bucket count 0 0 65536 0
access check cache quota 0 0 2147483647 0
Agent XPs 1 0 1 1
SQL Mail XPs 0 0 1 0
Database Mail XPs 0 0 1 0
SMO and DMO XPs 1 0 1 1
Ole Automation Procedures 0 0 1 0
xp_cmdshell 0 0 1 0
Ad Hoc Distributed Queries 0 0 1 0
Replication XPs 0 0 1 0


Microsoft SQL Server 2008 R2 (SP3) - 10.50.6000.34 (X64) Aug 19 2014 12:21:34 Copyright (c) Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)


cpu_counthyperthread_ratioos_priority_classaffinity_type_descsqlserver_start_time
24 12 128 MANUAL 2016-01-05 22:50:54.160
14 янв 16, 14:44    [18678702]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
StarikNavy
Member

Откуда: Москва
Сообщений: 2415
komrad,

спасибо
14 янв 16, 14:58    [18678803]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
komrad
Member

Откуда:
Сообщений: 5758
porcupine
komrad,

черный ящик в студию)

namevalue minimum maximum value_in_use
priority boost 1 0 1 1
cost threshold for parallelism 500 0 32767 500
max degree of parallelism 2 0 1024 2



вопросы к этим настройкам
1) буст зачем включен?
http://blogs.msdn.com/b/arvindsh/archive/2010/01/27/priority-boost-details-and-why-it-s-not-recommended.aspx
2) по параллелизму - у вас 24ЦПУ на борту и только в случае очень тяжелых запросов вы позволяете серверу использовать доп. цпу для запроса? Есть для этого какие-то реальные причины?
я бы поставил так :
max degree 6
cost threshold 50
и дальше бы смотрел на картину нагрузки


а что у вас с памятью ?

select * from sys.dm_os_performance_counters where counter_name like 'T%Server Memory%'
go
select physical_memory_in_bytes from sys.dm_os_sys_info
go
14 янв 16, 15:10    [18678890]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
porcupine
Member

Откуда:
Сообщений: 26
komrad,
Буст остался в настройках со времен когда сервер приложений и сиквел жили на одном сервере. Что бы отдать приоритет серверу БД

Параллелизм всегда был установлен 6 при весе 500. После начала глюков при формировании проблемных запросов почти все ядра начали нагружаться под 100 проц, а если учесть, что время выполнения запроса повысилось с 5-10 мин до 30 уменьшил до 2х, что бы не сильно тормозить остальные.

Памяти на борту 64 гб
Сиквелу отдал 58, остальное под систему.

object_name counter_name instance_name cntr_value cntr_type
SQLServer:Memory Manager Target Server Memory(KB) 5939200065792
SQLServer:Memory Manager Total Server Memory (KB)59392000 65792
14 янв 16, 16:39    [18679442]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
komrad
Member

Откуда:
Сообщений: 5758
porcupine,
а вы параллелизм поменяли после начала всех тормозов или, например, поменяли для запросов, а после этого и статистика стала медленно считаться?
14 янв 16, 17:19    [18679703]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
porcupine
Member

Откуда:
Сообщений: 26
komrad,
Поменял когда проблема уже пришла, до этого все настройки были статичны. Не менялось ничего. Ни на уровне запросов 1С, ни СУБД, ни железо. Единственное изменение - это перезагрузка сервера и новые учетные данные в базе.
14 янв 16, 17:28    [18679773]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
komrad
Member

Откуда:
Сообщений: 5758
porcupine
это перезагрузка сервера и новые учетные данные в базе.

ну, видать, пора пришла, жить по-новому :)
14 янв 16, 18:14    [18680095]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
o-o
Guest
я все думаю, если переиндексация все столько же занимает,
значит индексов сколько и было.
а статистика дольше, и не по 2 раза, значит...вдруг статистик реально больше стало?
ага, и запросы только определенные стали тормозить,
уж не у них ли более не выходит какие-то индексы использовать?
а как можно "запретить" какие-то индексы одним махом?

у меня как-то было,
сервер перестал фильтрованные индексы использовать.
это тут постарались и выставили базе parameterization forced.
и все, фильтрованные индексы сразу недоступны.
проверьте свою базу на этот предмет
14 янв 16, 18:36    [18680172]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
porcupine
Member

Откуда:
Сообщений: 26
komrad
ну, видать, пора пришла, жить по-новому :)


Сто проц, ну есть и хорошая сторона, повод улучшить знания sql)

o-o
это тут постарались и выставили базе parameterization forced.


Значение судя по всему впорядке
is_parameterization_forced
0
15 янв 16, 11:27    [18682836]     Ответить | Цитировать Сообщить модератору
 Re: Производительность БД  [new]
komrad
Member

Откуда:
Сообщений: 5758
porcupine,

кстати, я бы отключил boost priority и включил опцию "remote admin connections"

первое поможет не потерять сервер, если сиквел очень напряжется
второе поможет подключиться через remote DAC, если сиквел уйдет в себя и перестанет принимать коннекты
15 янв 16, 11:54    [18683036]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить