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

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

Это надо понимать, что вы провели анализ узкого места запроса(ов) и установили, что это от количества записей в таблице ?
Или просто перебираете варианты ?


Есть сведения говорящие в пользу того, что количество записей существенно играет роль в изменении скорости.
23 окт 09, 16:23    [7831015]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
Glory
Member

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

Это надо понимать, что вы провели анализ узкого места запроса(ов) и установили, что это от количества записей в таблице ?
Или просто перебираете варианты ?


Есть сведения говорящие в пользу того, что количество записей существенно играет роль в изменении скорости.

Это если типа мильен записей читать с ide и со scsi ?
23 окт 09, 16:26    [7831038]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
Grage
Member

Откуда:
Сообщений: 15
Не совсем понял о чем Вы. Говорю же, что я непосредственно разработчик ПО работающего с БД.

А так имеется видимый прирост при работе через интерфейс + логи подсказывают. Тупо запускается система с БД разных размеров и отслеживается изменение скорости.
23 окт 09, 16:33    [7831092]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Grage
Не совсем понял о чем Вы. Говорю же, что я непосредственно разработчик ПО работающего с БД.

Я говорю о методах поиска узкого места.
То, что запрос к таблице с одной записью будет быстрее запроса к таблице с миллионом записей, это очевидно. Но это не значит, что нужно все таблицы приводить к размеру одной записи
23 окт 09, 16:35    [7831108]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
Grage
Member

Откуда:
Сообщений: 15
По сути все данные содержатся всего в 2х таблицах. Тут как бы особо больше некуда пенять)
23 окт 09, 16:38    [7831122]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Grage
По сути все данные содержатся всего в 2х таблицах. Тут как бы особо больше некуда пенять)

Т.е. вы считаете, что
- ваш запрос оптимален
- структура оптимальна
- блокировки оптимальны
- производительность оборудования оптимальна
23 окт 09, 16:40    [7831137]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
Grage
Member

Откуда:
Сообщений: 15
- при данной структуре таблиц запрос скорее всего оптимален (некогда он был оптимизирован специалистом по SQL) По крайне мере это самое быстрое что удалось изобразить
- вопрос об изменении структуры не стоит, ибо система в эксплуатации
- про блокировки ничего не знаю, но подозреваю что либо это уже анализировалось, либо изменение их вызовет те же проблемы что и изменение структуры, а именно существенную переработку всей системы
- так получается что оборудование вообще вне нашей компетенции

Как-то так. Так что разбиение таблиц есть то немногое, что лежит на поверхности и реализуемое нашими силами.
23 окт 09, 16:50    [7831213]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Grage
- при данной структуре таблиц запрос скорее всего оптимален (некогда он был оптимизирован специалистом по SQL) По крайне мере это самое быстрое что удалось изобразить
- вопрос об изменении структуры не стоит, ибо система в эксплуатации
- про блокировки ничего не знаю, но подозреваю что либо это уже анализировалось, либо изменение их вызовет те же проблемы что и изменение структуры, а именно существенную переработку всей системы
- так получается что оборудование вообще вне нашей компетенции

Как-то так. Так что разбиение таблиц есть то немногое, что лежит на поверхности и реализуемое нашими силами.

Ну так и понятно, что узкое место вы собстенно и не искали. А просто выбрали один из общих способов снижения нагрузки
23 окт 09, 16:53    [7831232]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
Grage
Member

Откуда:
Сообщений: 15
Ну выходит так.
Но проблему этот вывод не решает =)
23 окт 09, 16:54    [7831241]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5499
Блог
Grage
Как-то так. Так что разбиение таблиц есть то немногое, что лежит на поверхности и реализуемое нашими силами.
Для того, чтобы при разбиении таблиц не получить проблем больше (включая производительность), чем было изначально, нужна очень хорошая квалификация.
Зачастую этой квалификации достаточно, чтобы не делать разделения при первом же появлении проблем - банальная оптимизация.

А хранение данных за 3 месяца по 2К в день - это всего-ничего 200к записей.
Даже если за год - то все равно не больше 1М.
На таких объемах секционирование уж точно применять не нужно.
Это все равно, что ради онлайн-игр на Рамблере собирать компьютер с SLI видео и дискретным RAID-контроллером с SAS дисками. ;)
23 окт 09, 17:37    [7831570]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
aleks2
Guest
iljy
aleks2
iljy
Grage
В среднем по 2к записей каждый день добавляется. Уже примерно около года.


а сколько предельно планируете хранить? пока необходимости в танцах с бубном нет, а в перспективе - переходите на 2005 или 2008 и делайте секционирование.

Да хучь за мильен лет пусть хранят.
Ты объясни, убогому, в чем они поимеют выгоду от секционирования?

Да хучь в удалении окончательно ненужных данных. 1. Отщипнул секцию в отдельную таблицу и дропнул, без шуму, без пыли. 2. Ну и работа с одной секцией в 1 месяц может быть побыстрее, чем работа со всей таблицей за мильен лет, хотя бы за счет уменьшения уровней индекса. 3.И кластеный или нет - значения не имеет. 4. Ну а уж простор для оптимизации с выносом старых секций на более емкие, но медленные хранилища открывается аграмадный.

1. Пыли от простого удаления хвоста таблицы с правильным кластерным индексом еще меньше.
2. Это вам голос был или привиделось? А разборка в какую таблицу лезть - это не хуже индекса будет?
3. Надо подучиться.
4. Проблемы следует решать по мере их поступления. Хранилищ у тредстартера пока нету.
23 окт 09, 18:50    [7831970]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
aleks2
Guest
Grage
так как она будет сильно меньше полной. Соответственно многочисленные запросы к такой таблице/базе буду выполнятся существенно быстрее, что позволило бы несколько разгрузить сервер.


Хе-хе... с какого дубу вы упали? Зачем использовать собственные (да еще и неправильные) домыслы о том как сервер производит чтение данных из таблицы?

Не лучше ли ознакомиться с документацией по организации данных в таблице и смыслом кластерного индекса?
23 окт 09, 19:05    [7832028]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
iljy
Member

Откуда:
Сообщений: 8711
aleks2
iljy
aleks2
iljy
Grage
В среднем по 2к записей каждый день добавляется. Уже примерно около года.


а сколько предельно планируете хранить? пока необходимости в танцах с бубном нет, а в перспективе - переходите на 2005 или 2008 и делайте секционирование.

Да хучь за мильен лет пусть хранят.
Ты объясни, убогому, в чем они поимеют выгоду от секционирования?

Да хучь в удалении окончательно ненужных данных. 1. Отщипнул секцию в отдельную таблицу и дропнул, без шуму, без пыли. 2. Ну и работа с одной секцией в 1 месяц может быть побыстрее, чем работа со всей таблицей за мильен лет, хотя бы за счет уменьшения уровней индекса. 3.И кластеный или нет - значения не имеет. 4. Ну а уж простор для оптимизации с выносом старых секций на более емкие, но медленные хранилища открывается аграмадный.

1. Пыли от простого удаления хвоста таблицы с правильным кластерным индексом еще меньше.
2. Это вам голос был или привиделось? А разборка в какую таблицу лезть - это не хуже индекса будет?
3. Надо подучиться.
4. Проблемы следует решать по мере их поступления. Хранилищ у тредстартера пока нету.

1. Простое удаление даже хвоста даже кластера - логгируется. Если индексов много - логгируются все операции со всеми индексами. DROP TABLE логгируется по минимуму, переключение секций тоже.
2. ? Сдается мне голос был вам, и какой-то левый. Обратитесь к марксу чтоли
http://msdn.microsoft.com/ru-ru/library/ms190787.aspx , http://msdn.microsoft.com/ru-ru/library/ms177411.aspx
или сюда http://www.cyberguru.ru/database/sqlserver/sqlserver2008-query-productivity-page11.html и сюда https://www.sql.ru/articles/mssql/2005/073102PartitionedTablesAndIndexes.shtml . В последнем даже примеры есть, что используемая секция определяется при компиляции запроса.
3. А это вы к чему? Что-то конкретное хотите порекомендовать для изучения или так, блеснуть?
4. А я ему и не предлагал все бросать и секционировать, он спросил - я ответил. Уточнив, что "пока необходимости в танцах с бубном нет"
23 окт 09, 19:18    [7832089]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
aleks2
Guest
iljy
1. Простое удаление даже хвоста даже кластера - логгируется. Если индексов много - логгируются все операции со всеми индексами. DROP TABLE логгируется по минимуму, переключение секций тоже.
2. ? Сдается мне голос был вам, и какой-то левый. Обратитесь к марксу чтоли
http://msdn.microsoft.com/ru-ru/library/ms190787.aspx , http://msdn.microsoft.com/ru-ru/library/ms177411.aspx
или сюда http://www.cyberguru.ru/database/sqlserver/sqlserver2008-query-productivity-page11.html и сюда https://www.sql.ru/articles/mssql/2005/073102PartitionedTablesAndIndexes.shtml . В последнем даже примеры есть, что используемая секция определяется при компиляции запроса.
3. А это вы к чему? Что-то конкретное хотите порекомендовать для изучения или так, блеснуть?
4. А я ему и не предлагал все бросать и секционировать, он спросил - я ответил. Уточнив, что "пока необходимости в танцах с бубном нет"


1. Иногда логгирование очень кстати. Не используйте TRUNCATE table и не будете сожалеть о содеяном.
2. Не надо заглядывать в святцы, шоб указать на невозможность определить что-либо заранее в параметрическом (с переменной) запросе. А уж определять что-то на этапе компиляции или исполнения - ишо неизвестно что лучше - компиляция тож времени требует.
3. Учиться полезно - не будете давать плохих советов.
23 окт 09, 19:31    [7832134]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
iljy
Member

Откуда:
Сообщений: 8711
aleks2
Grage
так как она будет сильно меньше полной. Соответственно многочисленные запросы к такой таблице/базе буду выполнятся существенно быстрее, что позволило бы несколько разгрузить сервер.


Хе-хе... с какого дубу вы упали? Зачем использовать собственные (да еще и неправильные) домыслы о том как сервер производит чтение данных из таблицы?

Не лучше ли ознакомиться с документацией по организации данных в таблице и смыслом кластерного индекса?


Послушайте, может хватить излагать собственные (да еще и неправильные) домыслы как истину в последней инстанции? Проверьте уже хоть раз. Только что провел такую проверку - объединил во view таблицу с 10000 и 10млн записей, с неперекрывающимися диапазонами дат, делаю 2 выборки с фильтром по диапазонам из разных таблиц - выборка 1000 записей из маленькой 200мс, из большой 400мс. Воспроизведете эксперимент сами или скрипты выдать?
23 окт 09, 19:39    [7832162]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
iljy
Member

Откуда:
Сообщений: 8711
aleks2

1. Иногда логгирование очень кстати. Не используйте TRUNCATE table и не будете сожалеть о содеяном.
2. Не надо заглядывать в святцы, шоб указать на невозможность определить что-либо заранее в параметрическом (с переменной) запросе. А уж определять что-то на этапе компиляции или исполнения - ишо неизвестно что лучше - компиляция тож времени требует.
3. Учиться полезно - не будете давать плохих советов.

1. Иногда - кстати, но не тогда, когда требуется оптимизировать производительность в автоматическом режиме. Впрочем ТС сказал, что ему удаление не требуется.
2. И тем не менее - доступ к секциям очень хорошо параллелиться. И при польших выборках время компиляции как правило Омалое от времени выполнения.
3. Еще раз - порекомендуете что-то конкретное? Если нет - не надо засорять форум.
23 окт 09, 19:43    [7832178]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
aleks2
Guest
iljy
aleks2
Grage
так как она будет сильно меньше полной. Соответственно многочисленные запросы к такой таблице/базе буду выполнятся существенно быстрее, что позволило бы несколько разгрузить сервер.


Хе-хе... с какого дубу вы упали? Зачем использовать собственные (да еще и неправильные) домыслы о том как сервер производит чтение данных из таблицы?

Не лучше ли ознакомиться с документацией по организации данных в таблице и смыслом кластерного индекса?


Послушайте, может хватить излагать собственные (да еще и неправильные) домыслы как истину в последней инстанции? Проверьте уже хоть раз. Только что провел такую проверку - объединил во view таблицу с 10000 и 10млн записей, с неперекрывающимися диапазонами дат, делаю 2 выборки с фильтром по диапазонам из разных таблиц - выборка 1000 записей из маленькой 200мс, из большой 400мс. Воспроизведете эксперимент сами или скрипты выдать?

Ну а теперь построй кластерный индекс и получи 200мс на ЛЮБОМ интервале кластерного индекса.

Ладно, может кому еще пригодиться... Кластерный индекс определяет порядок физическое расположения данных в таблице. Если брать пример с датами, то это означает что все записи расположены в порядке следования дат и чтение любого такого интервала в таблице с 1000000000 записей и в таблице с 1000 записей требует одинакового времени. Естественно реч идет об интервалах НЕ превышающих длину маленькой таблицы.
23 окт 09, 19:50    [7832208]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
Crimean
Member

Откуда:
Сообщений: 13148
если у вас в большинстве запросов присутствует "критерий секционирования", то секционирование может помочь. "устриц ел". разумеется, бонус будет для тех запросов, которые покрывают не более 1 секции. да, я все еще про sql 2000
возникшие при секционировании проблемы почти все решаются
но проверять надо будет на ваших типовых запросах
23 окт 09, 20:16    [7832304]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
iljy
Member

Откуда:
Сообщений: 8711
aleks2

Ну а теперь построй кластерный индекс и получи 200мс на ЛЮБОМ интервале кластерного индекса.

Ладно, может кому еще пригодиться... Кластерный индекс определяет порядок физическое расположения данных в таблице. Если брать пример с датами, то это означает что все записи расположены в порядке следования дат и чтение любого такого интервала в таблице с 1000000000 записей и в таблице с 1000 записей требует одинакового времени. Естественно реч идет об интервалах НЕ превышающих длину маленькой таблицы.


Эээ... мне этому предлагается подучиться? Боюсь разочарую, но чем отличается кластерный индекс от некластерного и что такое включенные поля я в курсе ;) И в большом индексе больше уровней B-дерева, за счет этого дольше поиск. А в экперименте все таблицы имеют кластерный индекс по дате, нефрагментированный. Правда есть одна вещь, которая меня смущает - чтение напрямую из маленькой таблицы ПРОИГРЫВАЕТ, причем сильно, как чтению из большой, так и чтению из нее же, но через view. Скорее всего это вызвано использованием под ее данные разделяемых экстентов (да, DBCC DROPCLEANBUFFERS перед каждым запросом делается), но почему через view быстрее - это не объясняет.
По существу топика - предлагаю ТС не морочить себе голову, а решать проблемы по мере возникновения, потому что на ткущем количестве данных выигрыш он врядли ощутит в любом случае.
23 окт 09, 21:05    [7832442]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5499
Блог
Crimean
возникшие при секционировании проблемы почти все решаются
но проверять надо будет на ваших типовых запросах
Решаются.
Но при условии, что у человека не возникает проблем на таблице с всего одним миллионом записей.
А если с таким небольшим объемом человек разобраться не может, то уж после секционирования проблемы базы можно будет решить только покупкой новой готовой программы.
23 окт 09, 23:29    [7832780]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
Grage
Member

Откуда:
Сообщений: 15
Обсуждение ушло в какие-то далекие дали.

aleks2, Вы себя троллю подобно ведете, высказываясь столь категорично и провоцируя участников.

iljy, Glory, iap спасибо за советы и участие в обсуждении, узнал много нового=)
24 окт 09, 01:24    [7833124]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
aleks2
Guest
iljy
aleks2

Ну а теперь построй кластерный индекс и получи 200мс на ЛЮБОМ интервале кластерного индекса.

Ладно, может кому еще пригодиться... Кластерный индекс определяет порядок физическое расположения данных в таблице. Если брать пример с датами, то это означает что все записи расположены в порядке следования дат и чтение любого такого интервала в таблице с 1000000000 записей и в таблице с 1000 записей требует одинакового времени. Естественно реч идет об интервалах НЕ превышающих длину маленькой таблицы.


Эээ... мне этому предлагается подучиться? Боюсь разочарую, но чем отличается кластерный индекс от некластерного и что такое включенные поля я в курсе ;) И в большом индексе больше уровней B-дерева, за счет этого дольше поиск. А в экперименте все таблицы имеют кластерный индекс по дате, нефрагментированный. Правда есть одна вещь, которая меня смущает - чтение напрямую из маленькой таблицы ПРОИГРЫВАЕТ, причем сильно, как чтению из большой, так и чтению из нее же, но через view. Скорее всего это вызвано использованием под ее данные разделяемых экстентов (да, DBCC DROPCLEANBUFFERS перед каждым запросом делается), но почему через view быстрее - это не объясняет.
По существу топика - предлагаю ТС не морочить себе голову, а решать проблемы по мере возникновения, потому что на ткущем количестве данных выигрыш он врядли ощутит в любом случае.


Это только лишний раз демонстрирует: знание и понимание - разные вещи.
Вот ты еще раз себе объясни: чем лишний уровень B-дерева будет отличаться от выбора между таблицами?

>>так и чтению из нее же, но через view.
Точно привиделось.
24 окт 09, 08:21    [7833313]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
aleks2
Guest
Grage
Обсуждение ушло в какие-то далекие дали.

aleks2, Вы себя троллю подобно ведете, высказываясь столь категорично и провоцируя участников.


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

Вот, например, какой ты, к черту, программист ДБ? Ежели ты не уха ни рыла не смыслишь в том: как производится выборка данных из таблицы. И, подобно блондинке, считаешь что это зависит от размера таблицы... Хе-хе... зависит - в некоторых случаях. Но эти случаи НАДО ЗНАТЬ.
24 окт 09, 08:27    [7833314]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
iljy
Member

Откуда:
Сообщений: 8711
aleks2

Это только лишний раз демонстрирует: знание и понимание - разные вещи.
Вот ты еще раз себе объясни: чем лишний уровень B-дерева будет отличаться от выбора между таблицами?

>>так и чтению из нее же, но через view.
Точно привиделось.

Умный и понимающий? На, объясняй
+

select 'TestT1', MIN(date), MAX(date), COUNT(*) from TestT1 union all
select 'TestT2', MIN(date), MAX(date), COUNT(*) from TestT2
TestT1 1900-01-01 00:01:00.000 1919-01-06 10:40:00.000 10000000
TestT2 1850-01-01 00:01:00.000 1850-01-07 22:40:00.000 10000

create view [dbo].[TestView] as
select DATE, value from TestT1
	union all
select date, value from TestT2
GO

set statistics time on set statistics io on 
DBCC DROPCLEANBUFFERS DBCC FREEPROCCACHE
select top 1000 * from TestT1
where DATE between '19010101' and '19500101'
GO

DBCC DROPCLEANBUFFERS DBCC FREEPROCCACHE
select top 1000 * from TestT2
where DATE between '18500101' and '18500103'
GO

DBCC DROPCLEANBUFFERS DBCC FREEPROCCACHE
select top 1000 * from TestView
where DATE between '19010101' and '19500101'
GO

DBCC DROPCLEANBUFFERS DBCC FREEPROCCACHE
select top 1000 * from TestView
where DATE between '18500101' and '18500103'
GO

Время работы SQL Server:
Время ЦП = 31 мс, затраченное время = 20 мс.
Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.

Время работы SQL Server:
Время ЦП = 0 мс, затраченное время = 1 мс.

(1000 row(s) affected)
Таблица "TestT1". Число просмотров 1, логических чтений 14, физических чтений 9, упреждающих
чтений 1509, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.

Время работы SQL Server:
Время ЦП = 16 мс, затраченное время = 182 мс.
Время синтаксического анализа и компиляции SQL Server:
время ЦП = 0 мс, истекшее время = 49 мс.
Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.

Время работы SQL Server:
Время ЦП = 0 мс, затраченное время = 7 мс.
Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.

Время работы SQL Server:
Время ЦП = 0 мс, затраченное время = 0 мс.

(1000 row(s) affected)
Таблица "TestT2". Число просмотров 1, логических чтений 6, физических чтений 1, упреждающих
чтений 18, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.

Время работы SQL Server:
Время ЦП = 0 мс, затраченное время = 83 мс. (Пересоздал кластерный индекс, до этого цифра была порядка 200мс)
Время синтаксического анализа и компиляции SQL Server:
время ЦП = 0 мс, истекшее время = 40 мс.
Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.

Время работы SQL Server:
Время ЦП = 0 мс, затраченное время = 8 мс.
Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.

Время работы SQL Server:
Время ЦП = 0 мс, затраченное время = 0 мс.

(1000 row(s) affected)
Таблица "Worktable". Число просмотров 0, логических чтений 0, физических чтений 0,
упреждающих чтений 0, lob логических чтений 0, lob физических чтений 0, lob упреждающих
чтений 0.
Таблица "TestT1". Число просмотров 1, логических чтений 14, физических чтений 9, упреждающих
чтений 1509, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.

Время работы SQL Server:
Время ЦП = 0 мс, затраченное время = 161 мс.
Время синтаксического анализа и компиляции SQL Server:
время ЦП = 16 мс, истекшее время = 153 мс.
Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.

Время работы SQL Server:
Время ЦП = 0 мс, затраченное время = 5 мс.
Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.

Время работы SQL Server:
Время ЦП = 0 мс, затраченное время = 0 мс.

(1000 row(s) affected)
Таблица "TestT2". Число просмотров 1, логических чтений 6, физических чтений 1, упреждающих
чтений 10, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.
Таблица "TestT1". Число просмотров 1, логических чтений 3, физических чтений 3, упреждающих
чтений 0, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0.

Время работы SQL Server:
Время ЦП = 0 мс, затраченное время = 46 мс.
Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (Intel X86)   Mar 29 2009 10:27:29
  Copyright (c) 1988-2008 Microsoft Corporation  Developer Edition on Windows NT 5.1 <X86> (Build 2600: Service Pack 3) 
Да, вчера снес 2008 Workgroup, поставил Developer, все цифры уменьшились вдвое.
24 окт 09, 11:08    [7833456]     Ответить | Цитировать Сообщить модератору
 Re: Использование триггеров для обработки входящих запросов  [new]
aleks2
Guest
iljy
aleks2

Это только лишний раз демонстрирует: знание и понимание - разные вещи.
Вот ты еще раз себе объясни: чем лишний уровень B-дерева будет отличаться от выбора между таблицами?

>>так и чтению из нее же, но через view.
Точно привиделось.

Умный и понимающий? На, объясняй


Дарагой, кроме фазы Луны, на свете есть еще масса вещей влияющих на выборку из конкретной таблицы. Многие из них тебе даже не снились.

Но это еще не повод уверять, что обзывание таблицы X псевдонимом Y будет влиять на скорость выборки.

Запомни: наука не занимается единичными артефактами. Наука занимается БЕСКОНЕЧНОЕ число раз воспроизводимыми явлениями.
24 окт 09, 11:20    [7833469]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить