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

Откуда:
Сообщений: 72
Имеется таблица вида

table Documents
Id int identity(1, 1) primary key,
[DocumentDate] datetime,
Header nvarchar(1500).

Также в таблице есть штук 8 других незначительных полей (типа int, nvarchar(100) и т.д.)
На таблицу повешены индексы. На поле [DocumentDate] тоже есть некластерный индекс, который находится в актуальном состоянии (то есть у него поле 'пересчитать статистику' выставлено в 'True'). В таблице 10 млн. записей.

Запрос вида

select min([DocumentDate])
from Documents

отрабатывает более 10 секунд. А это очень хреново.
База данных - MS SQL 2008.
База крутится на хорошем 4ёхпроцессорном сервере с 2 быстрыми дисками SAS, объединёнными в RAID 0 массив. Поэтому проблема не в железе и не в устаревшей статистике индекса.

Как оптимизировать данный тривиальный запрос? Как же так?
4 авг 09, 12:57    [7495213]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Glory
Member

Откуда:
Сообщений: 104760
И где план запроса ?
4 авг 09, 12:58    [7495221]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
x-x
Member

Откуда:
Сообщений: 230
anshag

1. Также в таблице есть штук 8 других незначительных полей (типа int, nvarchar(100) и т.д.)
2. На таблицу повешены индексы.

select min([DocumentDate])
from Documents

отрабатывает более 10 секунд. А это очень хреново.
База крутится на хорошем 4ёхпроцессорном сервере с 2 быстрыми дисками SAS, объединёнными в RAID 0 массив. Поэтому проблема не в железе и не в устаревшей статистике индекса.

Блин, поулыбался
select top 1 DocumentDate from Documents order by DocumentDate ?
при индексе по DocumentDate
4 авг 09, 13:01    [7495234]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
x-x
Member

Откуда:
Сообщений: 230
anshag
1. Также в таблице есть штук 8 других незначительных полей (типа int, nvarchar(100) и т.д.)
2. На таблицу повешены индексы.
3. На поле [DocumentDate] тоже есть некластерный индекс, который находится в актуальном состоянии (то есть у него поле 'пересчитать статистику' выставлено в 'True').
4. Запрос отрабатывает более 10 секунд. А это очень хреново.
5. База данных - MS SQL 2008.
6. База крутится на хорошем 4ёхпроцессорном сервере с 2 быстрыми дисками SAS, объединёнными в RAID 0 массив. Поэтому проблема не в железе и не в устаревшей статистике индекса.

Как оптимизировать данный тривиальный запрос? Как же так?

Скрипт на создание таблицы и 1,2,3 можно было не писать
Может и не хреново, а замечательно. Был бы хоть план.
@@version говорит больше
4-х процессорный сервер всего с двумя дисками и неизвестным объёмом памяти сложно назвать хорошим для БД с таблицами по 10млн. записей. А в чем проблема обычно говорят после тестов, а не на основании количества процов и дисков.
4 авг 09, 13:07    [7495265]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
anshag
Member

Откуда:
Сообщений: 72
x-x
anshag

1. Также в таблице есть штук 8 других незначительных полей (типа int, nvarchar(100) и т.д.)
2. На таблицу повешены индексы.

select min([DocumentDate])
from Documents

отрабатывает более 10 секунд. А это очень хреново.
База крутится на хорошем 4ёхпроцессорном сервере с 2 быстрыми дисками SAS, объединёнными в RAID 0 массив. Поэтому проблема не в железе и не в устаревшей статистике индекса.

Блин, поулыбался
select top 1 DocumentDate from Documents order by DocumentDate ?
при индексе по DocumentDate


Над чем тут улыбаться? Обычный сервер от Hewlett Packard. Марку не помню.

Запрос с select top 1 отрабатывает ещё хуже - 3 минуты 24 секунды.
4 авг 09, 13:08    [7495277]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
a_shats
Member

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

База крутится на хорошем 4ёхпроцессорном сервере с 2 быстрыми дисками SAS, объединёнными в RAID 0 массив. Поэтому проблема не в железе и не в устаревшей статистике индекса.


Намекаю: запустите perfmon, посмотрите очередь к дискам во время этого запроса.
Применение RAID0 для хранения 8 ГБ базы - нуу... есть, конечно, способы потерять живую базу проще, но этот - один из самых верных
4 авг 09, 13:09    [7495286]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3650
anshag
Поэтому проблема не в железе и не в устаревшей статистике индекса.


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

Откуда:
Сообщений: 230
anshag
Над чем тут улыбаться? Обычный сервер от Hewlett Packard. Марку не помню.
Запрос с select top 1 отрабатывает ещё хуже - 3 минуты 24 секунды.

Улыбаюсь над формулировкой первого сообщения. Почему - написал ниже.
x-x
при индексе по DocumentDate
???
4 авг 09, 13:16    [7495325]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Anddros
Member

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

+1

2 автор:

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

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

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

StmtText
select min ([DocumentDate]) from dbo.Documents

StmtText
  |--Stream Aggregate(DEFINE:([Expr1003]=MIN([ds].[dbo].[Documents].[DocumentDate])))
       |--Top(TOP EXPRESSION:((1)))
            |--Index Scan(OBJECT:([ds].[dbo].[Documents].[IX_Documents_6]), ORDERED FORWARD)

Как же так? Вроде всё просто.
4 авг 09, 13:20    [7495347]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Glory
Member

Откуда:
Сообщений: 104760
anshag
Glory,

StmtText
select min ([DocumentDate]) from dbo.Documents

StmtText
  |--Stream Aggregate(DEFINE:([Expr1003]=MIN([ds].[dbo].[Documents].[DocumentDate])))
       |--Top(TOP EXPRESSION:((1)))
            |--Index Scan(OBJECT:([ds].[dbo].[Documents].[IX_Documents_6]), ORDERED FORWARD)

Как же так? Вроде всё просто.

И вы можете предоставить скрипт создания этого [ds].[dbo].[Documents].[IX_Documents_6] ?
А данные о его фрагментации ?
4 авг 09, 13:22    [7495362]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
x-x
Member

Откуда:
Сообщений: 230
anshag
Как же так? Вроде всё просто.

А скрипт индекса IX_Documents_6 можно?

А если так
create index [idx_test] on [dbo].[Documents] 
(	[DocumentDate] asc)

select top 1 DocumentDate
from dbo.Documents with (index (idx_test))
order by DocumentDate 
тоже 3 минуты?
4 авг 09, 13:23    [7495373]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Anddros
Member

Откуда:
Сообщений: 1077
И что у вас за индекс 'IX_Documents_6'?
4 авг 09, 13:25    [7495380]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Anddros
Member

Откуда:
Сообщений: 1077
DocumentDate в нем явно есть, но, подозреваю, что он идет НЕ ПЕРВЫМ в списке столбцов. :)
4 авг 09, 13:27    [7495402]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
anshag
Member

Откуда:
Сообщений: 72
Glory
anshag
Glory,

StmtText
select min ([DocumentDate]) from dbo.Documents

StmtText
  |--Stream Aggregate(DEFINE:([Expr1003]=MIN([ds].[dbo].[Documents].[DocumentDate])))
       |--Top(TOP EXPRESSION:((1)))
            |--Index Scan(OBJECT:([ds].[dbo].[Documents].[IX_Documents_6]), ORDERED FORWARD)

Как же так? Вроде всё просто.

И вы можете предоставить скрипт создания этого [ds].[dbo].[Documents].[IX_Documents_6] ?
А данные о его фрагментации ?


CREATE NONCLUSTERED INDEX [IX_Documents_6] ON [dbo].[Documents] 
(
	[DocumentDate] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO


Name	Updated	Rows	Rows Sampled	Steps	Density	Average key length	String Index
IX_Documents_6 	авг  4 2009 12:29PM	4971155	4971155	23	0	12	NO 

All density	Average Length	Columns
0,04347826	8	DocumentDate

RANGE_HI_KEY	RANGE_ROWS	EQ_ROWS	DISTINCT_RANGE_ROWS	AVG_RANGE_ROWS
2009-07-03 11:13:44.577	0	144900	0	1
2009-07-09 00:00:00.000	0	1	0	1
2009-07-10 00:00:00.000	0	1	0	1
2009-07-13 00:00:00.000	0	15	0	1
2009-07-13 11:10:05.857	0	959984	0	1
2009-07-15 09:02:21.390	0	48300	0	1
2009-07-23 00:00:00.000	0	1	0	1
2009-07-23 11:59:21.890	0	61949	0	1
2009-07-24 00:00:00.000	0	1	0	1
2009-07-24 10:41:32.810	0	24000	0	1
2009-07-24 10:44:24.513	0	216000	0	1
2009-07-24 12:41:10.937	0	120000	0	1
2009-07-24 13:19:42.763	0	60000	0	1
2009-07-24 13:21:23.890	0	119999	0	1
2009-07-24 13:25:38.903	0	120000	0	1
2009-07-24 13:28:52.280	0	120000	0	1
2009-07-24 13:33:18.293	0	96000	0	1
2009-07-24 13:53:24.560	0	960000	0	1
2009-07-24 14:33:15.577	0	960000	0	1
2009-07-24 15:26:40.043	0	960000	0	1
2009-07-27 00:00:00.000	0	1	0	1
2009-07-28 00:00:00.000	0	2	0	1
2009-07-29 00:00:00.000	0	1	0	1
4 авг 09, 13:38    [7495503]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
anshag
Member

Откуда:
Сообщений: 72
x-x
anshag
Как же так? Вроде всё просто.

А скрипт индекса IX_Documents_6 можно?

А если так
create index [idx_test] on [dbo].[Documents] 
(	[DocumentDate] asc)

select top 1 DocumentDate
from dbo.Documents with (index (idx_test))
order by DocumentDate 
тоже 3 минуты?


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

Откуда: Moscow
Сообщений: 36808
Смотреть сначала блокировки, потом очереди к дискам.
Хотя там скан.

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

Откуда:
Сообщений: 72
Anddros
DocumentDate в нем явно есть, но, подозреваю, что он идет НЕ ПЕРВЫМ в списке столбцов. :)


Именно первым и единственным. Как же так?

То есть создавать большие базы (более 1 Гб) на MS SQL - это дохлый номер? Даже с учётом создания распределённых таблиц. В общем, я разочаровался в мощи MS SQL 2008.
Либо MS SQL делали студенты-индусы, либо сама технология у Microsoft - балалайка.

Вот Oracle ещё более-менее нормальная база данных. Правильно?
4 авг 09, 13:42    [7495538]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36808
Какой гигабайт, вы о чем? Не более 3 Мб. Индусы-то больше трех считать не умеют.
4 авг 09, 13:44    [7495557]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3650
anshag
Anddros
DocumentDate в нем явно есть, но, подозреваю, что он идет НЕ ПЕРВЫМ в списке столбцов. :)


Именно первым и единственным. Как же так?

То есть создавать большие базы (более 1 Гб) на MS SQL - это дохлый номер? Даже с учётом создания распределённых таблиц. В общем, я разочаровался в мощи MS SQL 2008.
Либо MS SQL делали студенты-индусы, либо сама технология у Microsoft - балалайка.

Вот Oracle ещё более-менее нормальная база данных. Правильно?


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

Откуда:
Сообщений: 72
Гавриленко Сергей Алексеевич
Какой гигабайт, вы о чем? Не более 3 Мб. Индусы-то больше трех считать не умеют.


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

Откуда:
Сообщений: 72
Ozerov
anshag
Anddros
DocumentDate в нем явно есть, но, подозреваю, что он идет НЕ ПЕРВЫМ в списке столбцов. :)


Именно первым и единственным. Как же так?

То есть создавать большие базы (более 1 Гб) на MS SQL - это дохлый номер? Даже с учётом создания распределённых таблиц. В общем, я разочаровался в мощи MS SQL 2008.
Либо MS SQL делали студенты-индусы, либо сама технология у Microsoft - балалайка.

Вот Oracle ещё более-менее нормальная база данных. Правильно?


Вы, прежде чем делать такие заявления, начали бы со счетчиков производительности.


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

Откуда: Moscow
Сообщений: 36808
anshag
Гавриленко Сергей Алексеевич
Какой гигабайт, вы о чем? Не более 3 Мб. Индусы-то больше трех считать не умеют.


Как же так? Как же быть?
А какую версию Oracle Вы тогда посоветуете?
Я посоветую не смешить народ высказываниями про индусов и балалайки. Могут не понять.

Давайте сюда статистику
set statistics io on
go
select min ([DocumentDate]) from dbo.Documents
go
set statistics io off
go
4 авг 09, 13:48    [7495605]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36808
И инфу по блокировкам во время запроса. А то ща выясниться, что кто-то таблицу честно на N минут блокирует.
4 авг 09, 13:50    [7495614]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса к большой базы данных (>=8 Гб)  [new]
anshag
Member

Откуда:
Сообщений: 72
Гавриленко Сергей Алексеевич
anshag
Гавриленко Сергей Алексеевич
Какой гигабайт, вы о чем? Не более 3 Мб. Индусы-то больше трех считать не умеют.


Как же так? Как же быть?
А какую версию Oracle Вы тогда посоветуете?
Я посоветую не смешить народ высказываниями про индусов и балалайки. Могут не понять.

Давайте сюда статистику
set statistics io on
go
select min ([DocumentDate]) from dbo.Documents
go
set statistics io off
go



Таблица "Documents". Число просмотров 1, логических чтений 3, физических чтений 0, упреждающих чтений 0, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.
4 авг 09, 13:50    [7495618]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить