|
v8: Как заставить sql сервер кешировать определенные данные | ☑ | ||
---|---|---|---|---|
0
MadHead
04.04.13
✎
11:50
|
Есть потребность ускорить формирования запросов к бухгалтерскому регистру. Можно ли заставить ms sql сервер кешировать по нему данные в большем объеме нежели это делается стандартно?
|
|||
1
Sammo
04.04.13
✎
11:52
|
В такой постановке - нет.
Что надо то? |
|||
2
piter3
04.04.13
✎
11:53
|
текст запроса покажи
|
|||
3
MadHead
04.04.13
✎
12:00
|
Есть очень большая таблица регистра бухгалтерии. К ней даже элементарные запросы выполняются довольно долго.
(2) как пример самый простой запрос вида (но тут дело не в запросе) ВЫБРАТЬ Таблица.КорСчет.Ссылка КАК КорСчет, Таблица.КорСчет.Порядок КАК КорСчетПорядок, Таблица.КорСчет.Представление КАК КорСчетПредставление, Таблица.СуммаОборотДт КАК СуммаОборотДт, Таблица.СуммаОборотКт КАК СуммаОборотКт ИЗ РегистрБухгалтерии.Хозрасчетный.Обороты(&ДатаНач, &ДатаКон, , Счет = &Счет, , Организация = &Организация, , ) КАК Таблица УПОРЯДОЧИТЬ ПО КорСчетПорядок ИТОГИ СУММА(СуммаОборотДт), СУММА(СуммаОборотКт) ПО ОБЩИЕ, Таблица.Счет ИЕРАРХИЯ КАК Счет, КорСчет ИЕРАРХИЯ КАК КорСчет Выполняется за 3 месяца по счету "товары на складе" выполняется около 20 секунд первый раз в консоле |
|||
4
Spieluhr
04.04.13
✎
12:10
|
(0) режим блокировок какой в конфигурации?
|
|||
5
MadHead
04.04.13
✎
12:12
|
автоматический
|
|||
6
mistеr
04.04.13
✎
12:16
|
(3) Данный запрос должен выполняться по таблице итогов, а не по основной таблице. С итогами все в порядке?
|
|||
7
Spieluhr
04.04.13
✎
12:17
|
(5) переход на управляемые блокировки вам поможет однозначно
|
|||
8
mistеr
04.04.13
✎
12:18
|
(7) С какого?
|
|||
9
Spieluhr
04.04.13
✎
12:18
|
(8) С какого числа или что? кэш сиквела абсолютно не причем, дело в избыточных блокировках при запросах к регистру бухгалтерии
|
|||
10
Solemn
04.04.13
✎
12:19
|
(7) При чем здесь блокировки? Запрос в консоли (отчетах) вообще без (несмотря на) блокировок читает
|
|||
11
mistеr
04.04.13
✎
12:19
|
(8) С какого хрена "поможет однозначно"
|
|||
12
Зойч
04.04.13
✎
12:20
|
select * from ...
|
|||
13
Зойч
04.04.13
✎
12:21
|
а во 2 раз за сколько выполняется?
|
|||
14
Solemn
04.04.13
✎
12:23
|
(9) Тут нет проведения документов, такие запросы выполняются с хинтом NOLOCK
|
|||
15
MadHead
04.04.13
✎
12:24
|
(7) Я и не сомневаюсь что поможет в целом для параллельности работы. Но на запрос в (3) никак не повлияет. Да и это очень большой кусок работы
|
|||
16
Spieluhr
04.04.13
✎
12:25
|
(14) да-да, я невнимательно прочитал (3)
|
|||
17
MadHead
04.04.13
✎
12:25
|
(6) Вот я итоги и хотел кешировать.
|
|||
18
Solemn
04.04.13
✎
12:26
|
(17) секционирование таблиц вам поможет
|
|||
19
MadHead
04.04.13
✎
12:29
|
(18) Смотрели в эту сторону. Пока некоторые таблицы разнесли по файловым группам, со временем планируем и секционирование сделать
|
|||
20
mistеr
04.04.13
✎
12:35
|
(17) Что, итоги тоже очень большие?
Я и спросил, все ли с ними в порядке. Может там нулевых записей много. Может, не посчитаны за какой-то период. |
|||
21
МихаилМ
04.04.13
✎
12:36
|
(18)
а при реструктуризации (пересоздании) каждый раз секции заново создавать ? (19) тоже с фг |
|||
22
el-gamberro
04.04.13
✎
12:38
|
(18) Причем тут партионирование? Это все для записи помогает.
А автор хочет скорости ОЛАП для регистров бухии. |
|||
23
Solemn
04.04.13
✎
12:41
|
(22) Если вы ответите на вопрос почему секционирование уменьшает скорость записи, то вы тут же ответите на вопрос почему скорость чтения увеличивается
|
|||
24
Solemn
04.04.13
✎
12:42
|
+(23)*увеличивает скорость записи
|
|||
25
piter3
04.04.13
✎
12:54
|
это все здорово, а план запроса автор смотрел
|
|||
26
el-gamberro
04.04.13
✎
13:01
|
(23) Что-то я сумневанюсь. Вот из ОЛАП легко читать, но пишут туда данные очень долго и мучительно :)
Почему секционирование облегчает запись понятно. В 2 мешка что-то сложить что-то проще, чем плотно упаковать в один. Но ведь достать что из одного, что из 2х примерно одинаково :) |
|||
27
mistеr
04.04.13
✎
13:03
|
(26) Не просто достать, а найти.
|
|||
28
Solemn
04.04.13
✎
14:07
|
(26) найти в одной (из 2х) кучек которая в 2 раза меньше чем большая кучка обычно гораздо быстрее ))
|
|||
29
MadHead
04.04.13
✎
14:26
|
ладно с этим вопросом понятно, что особо повлиять на кеширование таблиц я не могу.
Тогда другой вопрос, коль уж тут собрался народ. Какими способами можно уменьшить время наложения блокировок. Так как запросы вне транзакций выполняются в 3-4 раза быстрее чем в транзакциях даже если я в базе сам? |
|||
30
Solemn
04.04.13
✎
14:29
|
(29) что значит сам? Один? Выполнять запросы вне транзакций, если конечно логика системы позволяет
|
|||
31
MadHead
04.04.13
✎
15:36
|
(29) Да одни. Этим хотел подчеркнуть что, это не блокировки с другими пользователями. Эти запросы в обработке проведения.
|
|||
32
gallam
04.04.13
✎
20:08
|
(0)
А вы уверены, что кеширование вам поможет? Надо обосновать, а именно в момент выполнения запроса очередь к диску на чтение зашкаливает? Раньше до 2000 была команда PINTABLE как раз для этого, но она не так сильно эффективно, как кажется на первый взгляд. |
|||
33
MadHead
06.04.13
✎
00:28
|
(32) не особо большая очередь. в самых пиках до 60 бывает.
|
|||
34
andreynikus
06.04.13
✎
08:14
|
(0) Зачем секционирование, зачем кэш, зачем из пушки по воробьям?
Автор к тебе вопрос: Выполняются ли регламентные операции sql? Если да, то план запроса в студию, без него дальнейшее обсуждение не имеет смысла. |
|||
35
MadHead
08.04.13
✎
01:39
|
все регламентные операции скл выполняются. В плане запроса много ветвлений и 90-99% операция index seek
|
|||
36
andreynikus
08.04.13
✎
05:31
|
(35) Возможно проблема связана с большим количеством нулевых строк в регистре.
Для проверки прочитай статью на инфостат "Зачем в 1С нужно периодически пересчитывать итоги по регистрам?", там же приведено решение этой проблемы. Если не поможет, тогда выкладывай план запроса, а не свои выводы. |
|||
37
andreynikus
08.04.13
✎
05:38
|
Забыл ссылку на статью
http://infostart.ru/public/177171/ |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |