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

Откуда:
Сообщений: 72
Гавриленко Сергей Алексеевич
И инфу по блокировкам во время запроса. А то ща выясниться, что кто-то таблицу честно на N минут блокирует.


Как получить эту инфу?
4 авг 09, 13:52    [7495636]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36801
anshag
Таблица "Documents". Число просмотров 1, логических чтений 3, физических чтений 0, упреждающих чтений 0, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.
Значит ничего он там не сканит по факту. Блокировки давайте.
4 авг 09, 13:52    [7495638]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36801
sp_lock в параллельном коннекте во время выполнения запроса.
4 авг 09, 13:52    [7495642]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Anddros
Member

Откуда:
Сообщений: 1077
А
set statistics time on
go
select min ([DocumentDate]) from dbo.Documents
go
set statistics time off

?

Может у вас elapsed time хромает, а cpu time мизерно
4 авг 09, 13:56    [7495677]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
anshag
Member

Откуда:
Сообщений: 72
Гавриленко Сергей Алексеевич
sp_lock в параллельном коннекте во время выполнения запроса.


spid dbid ObjId IndId Type Resource Mode Status
80 37 0 0 DB S GRANT
80 37 1216059418 20 PAG 1:82709 S GRANT
80 37 1216059418 20 PAG 1:83473 S GRANT
80 37 1216059418 0 TAB IS GRANT
80 37 1216059418 0 TAB IS GRANT
80 37 1216059418 0 TAB IS GRANT
80 37 1216059418 0 TAB IS GRANT
80 37 1216059418 0 TAB IS GRANT
80 37 1216059418 20 PAG 1:81483 S GRANT
80 37 1116583066 0 TAB IS GRANT
81 37 0 0 DB S GRANT
4 авг 09, 13:56    [7495680]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
anshag
Member

Откуда:
Сообщений: 72
Anddros
А
set statistics time on
go
select min ([DocumentDate]) from dbo.Documents
go
set statistics time off

?

Может у вас elapsed time хромает, а cpu time мизерно


У меня на графике плана запроса при наведении на иконку "index scan" выводится:
Estimated I/O Cost 6,8349
Estimated CPU Cost 5,4684
Estimated Operator Cost 0,0032831 (100%)

Значит затык в жёстких дисках и процессоре?
4 авг 09, 14:00    [7495707]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
anshag
Member

Откуда:
Сообщений: 72
Anddros
Glory
И где план запроса ?

+1

2 автор:

Если там у вас table scan, значит у вас нет индекса по DocumentDate. :)
Если index scan - устаревшая статистика
Если index seek - гнилое железо

Или вы просто-напросто чего-то не договариваете. Чудес, знаете ли, не бывает...


Не согласен с тем, что index seek - это плохо.
Наоборот, надо стремиться к операциям seek по индексу (кластерному/некластерному).
4 авг 09, 14:05    [7495740]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3650
anshag
Anddros
Glory
И где план запроса ?

+1

2 автор:

Если там у вас table scan, значит у вас нет индекса по DocumentDate. :)
Если index scan - устаревшая статистика
Если index seek - гнилое железо

Или вы просто-напросто чего-то не договариваете. Чудес, знаете ли, не бывает...


Не согласен с тем, что index seek - это плохо.
Наоборот, надо стремиться к операциям seek по индексу (кластерному/некластерному).


имелось ввиду, если идет index seek, то с запросом все ок, а железо не справляется.
4 авг 09, 14:07    [7495751]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
а очередь не диске есть ? Хотя опять же ето чтение... хотя и рейд 0
-------------------------------------
Jedem Das Seine
4 авг 09, 14:08    [7495756]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
anshag
Не согласен с тем, что index seek - это плохо.
Наоборот, надо стремиться к операциям seek по индексу (кластерному/некластерному).
Здесь, наверное про сик имелось в виду, что, если сик и с такой скоростью, то да - скорее всего железо.
А вот статистику проапдейтить не мешало бы...
4 авг 09, 14:08    [7495761]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3650
Maxx
а очередь не диске есть ? Хотя опять же ето чтение... хотя и рейд 0
-------------------------------------
Jedem Das Seine

Давно уже просим инфу по счетчикам....
4 авг 09, 14:08    [7495762]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
anshag
Member

Откуда:
Сообщений: 72
Ozerov
anshag
Anddros
Glory
И где план запроса ?

+1

2 автор:

Если там у вас table scan, значит у вас нет индекса по DocumentDate. :)
Если index scan - устаревшая статистика
Если index seek - гнилое железо

Или вы просто-напросто чего-то не договариваете. Чудес, знаете ли, не бывает...


Не согласен с тем, что index seek - это плохо.
Наоборот, надо стремиться к операциям seek по индексу (кластерному/некластерному).


имелось ввиду, если идет index seek, то с запросом все ок, а железо не справляется.


А может нужно перестроить AWE (Address Windowing Extentions)?
4 авг 09, 14:09    [7495764]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Ozerov
Member

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


А может нужно перестроить AWE (Address Windowing Extentions)?[/quot]

надо сначала получить инфу по Performance
4 авг 09, 14:10    [7495773]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
anshag
Member

Откуда:
Сообщений: 72
Ozerov
[quot Maxx]а очередь не диске есть ? Хотя опять же ето чтение... хотя и рейд 0
Давно уже просим инфу по счетчикам....


У меня нет доступа к серверу. Можно ли получить инфу по счётчикам через SQL Server Management studio?
4 авг 09, 14:10    [7495774]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
anshag
Ozerov
[quot Maxx]а очередь не диске есть ? Хотя опять же ето чтение... хотя и рейд 0
Давно уже просим инфу по счетчикам....


У меня нет доступа к серверу. Можно ли получить инфу по счётчикам через SQL Server Management studio?


только в счетчикам скл сервера,к системным нет :(

а если удаленно перфмоном подключиться ?
4 авг 09, 14:11    [7495782]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
anshag
А может нужно перестроить AWE (Address Windowing Extentions)?
Сделайте лучше сперва:
UPDATE STATISTICS dbo.Documents
4 авг 09, 14:13    [7495790]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Anddros
Member

Откуда:
Сообщений: 1077
anshag
Не согласен с тем, что index seek - это плохо.

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

Впрочем, судя по всему в плане select min(...) при наличии индекса светится index scan, а не seek. Тут ошибся я... :(


И все-таки предъявите статистику:
set statistics time on
go
select min ([DocumentDate]) from dbo.Documents
go
set statistics time off
Что там cpu и elapsed time?
4 авг 09, 14:14    [7495797]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3650
anshag
Ozerov
[quot Maxx]а очередь не диске есть ? Хотя опять же ето чтение... хотя и рейд 0
Давно уже просим инфу по счетчикам....


У меня нет доступа к серверу. Можно ли получить инфу по счётчикам через SQL Server Management studio?


Через Profiler можно, там есть значок. Смотря какие у Вас права..
4 авг 09, 14:15    [7495801]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
anshag
Member

Откуда:
Сообщений: 72
Ozerov
anshag
Ozerov
[quot Maxx]а очередь не диске есть ? Хотя опять же ето чтение... хотя и рейд 0
Давно уже просим инфу по счетчикам....


У меня нет доступа к серверу. Можно ли получить инфу по счётчикам через SQL Server Management studio?


Через Profiler можно, там есть значок. Смотря какие у Вас права..


Снял статистику по счётчикам. Но залить файлик сюда не получается. Видимо, что-то у нас админы в конторе накрутили.

В целом, на счётчиках видна загрузка на 25-30% памяти, очередь к жёсткому диску - 35-40%, процент загрузки процессоров - 20-25%.
4 авг 09, 14:27    [7495871]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
anshag
Member

Откуда:
Сообщений: 72
tpg
anshag
А может нужно перестроить AWE (Address Windowing Extentions)?
Сделайте лучше сперва:
UPDATE STATISTICS dbo.Documents


Сделал. Ничего не изменилось.
Судя по счётчикам загрузки и очереди к диску, диски загружены на 35-40%, процессоры - на 20-25%, обмен страницами в памяти - 30-35%.
4 авг 09, 14:29    [7495889]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
x-x
Member

Откуда:
Сообщений: 230
anshag
очередь к жёсткому диску - 35-40%

Видимо, не тот счетчик.
Нужна текущая длина очереди к физическому диску.
4 авг 09, 14:30    [7495896]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3650
А точнее ? page\sec 25-30 % ??? Там вообще не в процентах... да и все остальное не в процентах, можно среднии цифры, они внизу пишутся. Но что то, мне кажется (если правильно Вас понял) по памяти и дисковой подлсистеме, у Вас ужасть.
4 авг 09, 14:30    [7495898]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Glory
Member

Откуда:
Сообщений: 104760
А можно все таки увидеть select @@version ?
И SELECT * FROM sys.configurations ORDER BY name ?
4 авг 09, 14:34    [7495919]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
anshag
Member

Откуда:
Сообщений: 72
Glory
А можно все таки увидеть select @@version ?
И SELECT * FROM sys.configurations ORDER BY name ?


select @@version

Microsoft SQL Server 2008 - 10.00.2723 (Intel X86) July 21 2009 22:47:07 Copyright (c) 1988-2005 Microsoft Corporation Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

и


configuration_idnamevalueminimummaximumvalue_in_usedescriptionis_dynamicis_advanced
16391Ad Hoc Distributed Queries0010Enable or disable Ad Hoc Distributed Queries11
1550affinity I/O mask0-214748364821474836470affinity I/O mask01
1535affinity mask0-214748364821474836470affinity mask11
16384Agent XPs1011Enable or disable Agent XPs11
102allow updates0010Allow updates to system tables10
1548awe enabled0010AWE enabled in the server01
1569blocked process threshold00864000Blocked process reporting threshold11
544c2 audit mode0010c2 audit mode01
1562clr enabled0010CLR user code execution enabled in the server10
1577common criteria compliance enabled0010Common Criteria compliance mode enabled01
1538cost threshold for parallelism50327675cost threshold for parallelism11
400cross db ownership chaining0010Allow cross db ownership chaining10
1531cursor threshold-1-12147483647-1cursor threshold11
16386Database Mail XPs0010Enable or disable Database Mail XPs11
1126default full-text language1033021474836471033default full-text language11
124default language210999921default language10
1568default trace enabled1011Enable or disable the default trace11
114disallow results from triggers0010Disallow returning results from triggers11
109fill factor (%)001000Default fill factor percentage01
1567ft crawl bandwidth (max)100032767100Max number of full-text crawl buffers11
1566ft crawl bandwidth (min)00327670Number of reserved full-text crawl buffers11
1565ft notify bandwidth (max)100032767100Max number of full-text notifications buffers11
1564ft notify bandwidth (min)00327670Number of reserved full-text notifications buffers11
1505index create memory (KB)070421474836470Memory for index create sorts (kBytes)11
1570in-doubt xact resolution0020Recovery policy for DTC transactions with unknown outcome11
1546lightweight pooling0010User mode scheduler uses lightweight pooling01
106locks0500021474836470Number of locks for all users01
1539max degree of parallelism1006410maximum degree of parallelism11
1563max full-text crawl range402564Maximum crawl ranges allowed in full-text indexing11
1544max server memory (MB)21474836471621474836472147483647Maximum size of server memory (MB)11
1536max text repl size (B)655360214748364765536Maximum size of a text field in replication.10
503max worker threads0128327670Maximum worker threads01
1537media retention003650Tape retention period in days01
1540min memory per query (KB)102451221474836471024minimum memory per query (kBytes)11
1543min server memory (MB)12802147483647128Minimum size of server memory (MB)11
115nested triggers1011Allow triggers to be invoked within triggers10
505network packet size (B)4096512327674096Network packet size11
16388Ole Automation Procedures0010Enable or disable Ole Automation Procedures11
107open objects0021474836470Number of open database objects01
1557PH timeout (s)601360060DB connection timeout for full-text protocol handler (s)11
1556precompute rank0010Use precomputed rank for full-text query11
1517priority boost0010Priority boost01
1545query governor cost limit0021474836470Maximum estimated cost allowed by query governor11
1541query wait (s)-1-12147483647-1maximum time to wait for query memory (s)11
101recovery interval (min)00327670Maximum recovery interval in minutes11
117remote access1011Allow remote access00
1576remote admin connections0010Dedicated Admin Connections are allowed from remote clients10
1519remote login timeout (s)200214748364720remote login timeout10
542remote proc trans0010Create DTC transaction for remote procedures10
1520remote query timeout (s)60002147483647600remote query timeout10
16392Replication XPs0010Enable or disable Replication XPs11
1547scan for startup procs0010scan for startup stored procedures01
116server trigger recursion1011Allow recursion for server level triggers10
1532set working set size0010set working set size01
518show advanced options0010show advanced options10
16387SMO and DMO XPs1011Enable or disable SMO and DMO XPs11
16385SQL Mail XPs0010Enable or disable SQL Mail XPs11
1555transform noise words0010Transform noise words for full-text query11
1127two digit year cutoff2049175399992049two digit year cutoff11
103user connections00327670Number of user connections allowed01
1534user options00327670user options10
16389Web Assistant Procedures0010Enable or disable Web Assistant Procedures11
16390xp_cmdshell0010Enable or disable command shell11


Сообщение было отредактировано: 4 авг 09, 14:47
4 авг 09, 14:42    [7495984]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
anshag
Member

Откуда:
Сообщений: 72
Ozerov
А точнее ? page\sec 25-30 % ??? Там вообще не в процентах... да и все остальное не в процентах, можно среднии цифры, они внизу пишутся. Но что то, мне кажется (если правильно Вас понял) по памяти и дисковой подлсистеме, у Вас ужасть.


page\sec ~ 288 000
средняя длина очереди диска - 12,244
4 авг 09, 14:48    [7496034]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить