Бешеные тормоза после переноса на MS SQL

1С v8

11.05.15

✎

10:36

После переноса переписанной файловой базы УТ 10.3 на MS SQL наблюдается лютые тормоза при работе с ней. Пользователей немного, штук 15 одновременной работы.При проведении ОРП с ТЧ в 226 строк система задумывается на 2(!) минуты, при чем 97% времени на строчку:
УправлениеЗапасамиПартионныйУчет.ДвижениеПартийТоваров(Ссылка, Движения.СписанныеТовары.Выгрузить()); Ну и формирование всяких отчетов стало занимать намного больше времени.
На этом же сервере крутится еще 4 базы, с ними таких проблем нет. Настройки БД у всех одинаковые. Вроде и гуглил, и статейки всякие читал - причину найти не могу. Спасайте!

Вводные:
8-ядерный Xeon CPU E5-2407
32Гб оперативной памяти
SCSI винт (на котором базы)
База УТ 10.3 размером в почти 9 Гб
Платформа 1С:Предприятие 8.2 (8.2.19.90)
Сервер 1с предприятия находится на другом компе
Если нужна еще какая-нибудь информация - скажите.

Насоветуйте чего-нибудь.

1 Альбатрос

11.05.15

✎

10:37

+ Microsoft SQL Server 2008 R2

2 shuhard_серый

11.05.15

✎

10:43

(0)[SCSI винт]
не верю (с)

3 Andrewww123

11.05.15

✎

10:50

Я бы на индексы обратил внимание. Ну и регламентные процедуры обязательно настроить(проверить выполняются ли).

4 Альбатрос

11.05.15

✎

10:50

(2) SCSI\DiskIBM_____ServeRAID_M5110_3.24

5 Альбатрос

11.05.15

✎

10:52

(3) Можно поподробней? желательно статью, где эти проблемы описываются

6 shuhard_серый

11.05.15

✎

10:56

(5) http://www.gilev.ru/mssqlserver/
в хвосте

(4) это не скази, это название драйвера рэйда

7 Andrewww123

11.05.15

✎

10:56

(5)
Про индексы. Вот таким запросом можно смотреть статистику по отсутствующим индексам. В конце дня нужно выполнить и если есть в результате какие-то строки, то нужно разбираться и создавать индексы.
SET NOCOUNT ON
DECLARE @dbid int

IF (object_id('tempdb..##IndexAdvantage') IS NOT NULL) DROP TABLE ##IndexAdvantage
CREATE TABLE ##IndexAdvantage ([Преимущество индекса] float, [База данных] varchar(64), [Transact SQL код для создания индекса] varchar(512),
[Число компиляций] int, [Количество операций поиска] int, [Количество операций просмотра] int,
[Средняя стоимость ] int, [Средний процент выигрыша] int );

DECLARE DBases CURSOR FOR
SELECT database_id FROM sys.master_files -- Получаем список ID баз данных
WHERE state = 0 AND -- ONLINE
has_dbaccess(db_name(database_id)) = 1 -- Only look at databases to which we have access
GROUP BY database_id

OPEN DBases
FETCH NEXT FROM DBases
INTO @dbid

WHILE @@FETCH_STATUS = 0
BEGIN -- Выполняем для каждой базы данных --------------------------------------------------

INSERT INTO ##IndexAdvantage
SELECT [Преимущество индекса] = user_seeks * avg_total_user_cost * (avg_user_impact * 0.01),
      [База данных] = DB_NAME(mid.database_id),
      [Transact SQL код для создания индекса] = 'CREATE INDEX [IX_' + OBJECT_NAME(mid.object_id,@dbid) + '_' +
      CAST(mid.index_handle AS nvarchar) + '] ON ' +
      mid.statement + ' (' + ISNULL(mid.equality_columns,'') +
      (CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ', ' ELSE '' END) +
      (CASE WHEN mid.inequality_columns IS NOT NULL THEN + mid.inequality_columns ELSE '' END) +
      ')' +
      (CASE WHEN mid.included_columns IS NOT NULL THEN ' INCLUDE (' + mid.included_columns + ')' ELSE '' END) +
      ';',
      [Число компиляций] = migs.unique_compiles,
      [Количество операций поиска] = migs.user_seeks,
      [Количество операций просмотра] = migs.user_scans,
      [Средняя стоимость ] = CAST(migs.avg_total_user_cost AS int),
      [Средний процент выигрыша] = CAST(migs.avg_user_impact AS int)
FROM  sys.dm_db_missing_index_groups mig
JOIN  sys.dm_db_missing_index_group_stats migs
ON    migs.group_handle = mig.index_group_handle
JOIN  sys.dm_db_missing_index_details mid
ON    mig.index_handle = mid.index_handle
AND   mid.database_id = @dbid

    FETCH NEXT FROM DBases
    INTO @dbid
END ----------------------------------------------------------------------------------------
CLOSE DBases
DEALLOCATE DBases
GO

SELECT * FROM ##IndexAdvantage ORDER BY 1 DESC
-- Значение ''Преимущество индекса'' выше 5000 в промышленных системах означает, что следует рассмотреть возможность создания этих индексов.
-- Если же значение превышает 10000, это обычно означает, что индекс может обеспечить значительное повышение производительности для операций чтения.
--------------------------------------------------------------------------------------------
IF (object_id('tempdb..##IndexAdvantage2') IS NOT NULL) DROP TABLE ##IndexAdvantage2
SELECT * FROM ##IndexAdvantage WHERE [Преимущество индекса] >= 5000 ORDER BY 1 DESC

Стырено с инфорстарта, кажется.

Про регламентные процедуры статей куча, в гугле "регламентные процедуры sql 1с".

8 Альбатрос

11.05.15

✎

11:00

(6) ну я хз, это мне админ так говорил, а (4) это из ИД оборудования, единственное, на что у меня есть права посмотреть

9 shuhard_серый

11.05.15

✎

11:02

(8) не парься,
подними регламенты
и начни с того, фулл у тебя в бэкапе или симпл, где темп сидит и далее по списку

10 Fragster

гуру

11.05.15

✎

11:04

отладка на сервере включена? разбей строку из (0) на две - одна для получения ТЗ из движений, другая для выполнения процедуры общего модуля

11 Альбатрос

11.05.15

✎

11:07

(10) Отладка на сервере отключена. Строки разбил, получение ТЗ из движения не занимает времени, что тормозит в общем модуле - посмотреть не могу.

12 Альбатрос

11.05.15

✎

11:07

(9) в бэкапе симпл

13 Fragster

гуру

11.05.15

✎

11:13

(11) так включи отладку на сервере, бро. наверняка тормозит один запрос, который банальным выносом виртуальных таблиц из соединения во временные, а потом уже соединение со временными таблицами ускорится раз в пять.

14 vde69

11.05.15

✎

11:26

для начала - регламенты!!! обновление статистики и индексы...

дальше несколько дней ждать и если все будет плохо - писать сюда

15 Альбатрос

11.05.15

✎

11:52

(14) регламенты есть только по индексам, обновление статистики добавил и сразу провел на проблемной базе - результат 0.

16 Альбатрос

11.05.15

✎

11:53

(14) Эффект будет только через несколько дней? ))))

17 Альбатрос

11.05.15

✎

11:56

(13) Это в реестр лезть надо?

18 dmrjan

11.05.15

✎

13:56

Как вариант - поднять базу на PostgreSQL, которая в отличие от MSSQL не жрет всю память и при правильных запросах в 1с почти не блокирует данные на чтение. И посмотреть - если оперативки не станет хватать, значит дело в некорректных запросах. Я в свое время на Linux с помощью Htop выявил некорректный запрос.

19 Альбатрос

11.05.15

✎

13:58

(18) Да, такая мысль тоже была, спасибо.
Вечером подключим отладку на сервере, регламентные я поднял. осмотрим короче...

20 H A D G E H O G s

11.05.15

✎

14:03

1. Регламенты.
2. Переписать партионное списание на годный код.
3. Реализовать управляемые блокировки.

Но так как nobody_cares, то все останется как есть.

21 floody

11.05.15

✎

14:42

(20) +146%, соник дело говорит

22 ДенисЧ

11.05.15

✎

14:43

(18) "поднять базу на PostgreSQL, которая в отличие от MSSQL не жрет всю память и при правильных запросах в 1с почти не блокирует данные на чтение"

Точнее - всё наоборот )))

23 ILM

гуру

11.05.15

✎

14:56

(20) Подробнее можно по п.2? Можно на почту.

24 ILM

гуру

11.05.15

✎

14:58

+(23) да и по п.3 интересно. Так как пишут многие, а реализаций не видел.

25 Lamer1C

11.05.15

✎

15:42

(0) попробуй статистику обновить. проверь. потом индексы перестроить, если 1 не поможет. а так причин может быть очень много...

26 Fragster

гуру

11.05.15

✎

15:52

(25) например древний релиз УТ, в котором соединяются виртуальные таблицы

27 Drac0

11.05.15

✎

16:15

(0) проверь в настройках скуля Max degree of parallelism (DOP). Скинь в 0 и проверь.

28 Lamer1C

11.05.15

✎

16:21

(27) для MS SQL Server лучше наоборот 1 ставить.

29 Lamer1C

11.05.15

✎

16:22

(27) точнее для баз 1С

30 Drac0

11.05.15

✎

16:24

(28) Я точно не помню. Просто была непонятная фигня со сложным запросом: вплоть до вешанья сервака. Оказалось, что в DOP было дикое число, скуль паралеллил и сам потом развлекался с этими потоками, ни на что больше не реагируя :)

31 Lamer1C

11.05.15

✎

16:27

(30) ну тогда точно в 0 ставил :) это параметр отвечает за распараллеливание операций для многоядерных процессоров: 0 - это неограниченно

32 Lamer1C

11.05.15

✎

16:28

(31) т.е. в 1 ))

33 orangekrs

11.05.15

✎

17:43

Ну да, в остальными базами всё ок. Тем не менее, а что показывает тест гилева ? http://www.gilev.ru/tpc1cgilv/

34 orangekrs

11.05.15

✎

17:44

А, шаг увеличения тмп файла у скл увеличен ? (по умолчанию он 1мб)

35 Kvant1C

11.05.15

✎

17:56

(0) Посмотри какое приращение установлено для базы данных, если оно слишком маленькое, то возможно, что сервер только и занимается приращением бд при каждом добавлении записей, отсюда и тормоза могут быть

36 H A D G E H O G s

11.05.15

✎

18:37

(23) Скинул на почту

37 vde69

11.05.15

✎

19:00

http://wiki.mista.ru/doku.php?id=it:analiz_sql_block

38 Альбатрос

14.05.15

✎

05:22

Max degree of parallelism (DOP) значение 1
У меня такая проблема, при добавлении строчки -debug у меня перестает запускаться агент на сервере.

Вот такая ошибка, это мне админ прислал:

Имя журнала:   System
Подача:        Microsoft-Windows-DistributedCOM
Дата:          14.05.2015 8:03:56
Код события:   10016
Категория задачи:Отсутствует
Уровень:       Ошибка
Ключевые слова:Классический
Пользователь:  1CSERVER\USR1CV82
Компьютер:     1CSERVER.kom-kastor.local
Описание:
Параметры разрешений для конкретного приложения не дают разрешения Локальный Активация для приложения COM-сервера с CLSID
{BA126AD1-2166-11D1-B1D0-00805FC1270E}
пользователю 1CSERVER\USR1CV82 с SID (S-1-5-21-4102014034-2086728852-1080897402-1002) и адресом LocalHost (с использованием LRPC). Это разрешение безопасности можно изменить с помощью служебной программы управления службами компонентов.
Xml события:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">;
  <System>
    <Provider Name="Microsoft-Windows-DistributedCOM" Guid="{1B562E86-B7AA-4131-BADC-B6F3A001407E}" EventSourceName="DCOM" />
    <EventID Qualifiers="49152">10016</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2015-05-14T01:03:56.000Z" />
    <EventRecordID>792819</EventRecordID>
    <Correlation />
    <Execution ProcessID="0" ThreadID="0" />
    <Channel>System</Channel>
    <Computer>1CSERVER.*******.local</Computer>
    <Security UserID="S-1-5-21-4102014034-2086728852-1080897402-1002" />
  </System>
  <EventData>
    <Data Name="param1">для конкретного приложения</Data>
    <Data Name="param2">Локальный</Data>
    <Data Name="param3">Активация</Data>
    <Data Name="param4">{BA126AD1-2166-11D1-B1D0-00805FC1270E}</Data>
    <Data Name="param5">1CSERVER</Data>
    <Data Name="param6">USR1CV82</Data>
    <Data Name="param7">S-1-5-21-4102014034-2086728852-1080897402-1002</Data>
    <Data Name="param8">LocalHost (с использованием LRPC)</Data>
  </EventData>
</Event>

Я так понимаю, там что-то с настройками безопасности. Админ комментариев не дает. Подскажите, что не так?

39 Альбатрос

14.05.15

✎

05:40

для (38) вроде вот решение, вечером только проверим
http://forum.kaspersky.com/lofiversion/index.php/t161843.html

40 Альбатрос

14.05.15

✎

06:36

(34) увеличил до 200 - по фигу...
для журнала тоже

41 vde69

14.05.15

✎

09:48

(28)для 8 лучше ставить 0, это для 7.7 надо ставить 1

42 Альбатрос

14.05.15

✎

10:07

(41) вернул обратно на ноль

43 Альбатрос

14.05.15

✎

10:08

sql server 2008 r2 best practices analyzer ничего страшного не выяснил

44 leonidkorolev

14.05.15

✎

10:38

(0) Я бы посмотре что внутри этой процедуры тормозит.

УправлениеЗапасамиПартионныйУчет.ДвижениеПартийТоваров(Ссылка, Движения.СписанныеТовары.Выгрузить())

45 Альбатрос

14.05.15

✎

10:59

(44) для этого надо отладку на сервере включить, а это не получается пока

46 Гёдза

14.05.15

✎

11:03

(45) без этого дальнейший разговор бессмысленный.
Может там блокировки идут

47 leonidkorolev

14.05.15

✎

11:05

(45) Ну ок. Можно в профайлере посмотреть что происходит на скуле в момент выполнения этой процедуры. Поставь точку останова на процедуру, перед выполнение запусти профайле и смотри самые тяжелые запросы.

48 vde69

14.05.15

✎

11:05

(45) сделай (37)...

49 Альбатрос

14.05.15

✎

11:12

(48) Я несколько хз, где это запускать :))) И не понял, что конкретно этот скрипт делает. Буду рад пояснениям )))

50 vde69

14.05.15

✎

11:14

(49) запускать в скуле, скрипт выводит статистику ожидания блокировок (показывает слабые места)

51 Альбатрос

14.05.15

✎

11:21

(50) Этот скрипт будет 5 часов мониторить при первом значении в 300?

52 vde69

14.05.15

✎

11:21

(51) да

53 Альбатрос

14.05.15

✎

11:24

(52) Поставил на 5 минут и начал проведение проблемного документа, жду...

54 Klesk666

14.05.15

✎

11:25

+(33) прогони тест Гилева

55 Kvant1C

14.05.15

✎

11:27

(40) Проверь размер приращения БД, вот полезная статья на эту тему: http://www.sql.ru/blogs/dbasimple/1924

не поленись прочитать

56 Альбатрос

14.05.15

✎

11:28

(52) Таааак, а результат в мс?

57 Klesk666

14.05.15

✎

11:28

какая конфигурация дисковой системы?

58 vde69

14.05.15

✎

11:29

(56) там в % куда нагляднее... нормально когда запись и чтение диска занимает 5-15%

59 Альбатрос

14.05.15

✎

11:29

(54) (55) Ок, спасибо. Щас после оценки результата из (37) займусь

60 Klesk666

14.05.15

✎

11:30

может админы все на один диск запихали

61 Альбатрос

14.05.15

✎

11:30

(58) LAZYWRITER_SLEEP процент = 25

62 slavikzzz

14.05.15

✎

11:30

вот еще статья по оптимизации + делали пересчет итогов
http://1cgmix.ru/base/base1c/30-optimize1cupp

63 Альбатрос

14.05.15

✎

11:31

(60) Рейд массив там вроде как. А так да, все на одном диске

64 vde69

14.05.15

✎

11:31

(61) запускать на менее часа смысла нет...

65 Альбатрос

14.05.15

✎

11:32

(64) Надо ведь и нагрузку тогда обеспечить на проблемную базу для хорошего результата, не?

66 Kvant1C

14.05.15

✎

11:33

Кстати на счет дисков, был такой случай когда проблемы на новом сервере были связаны именно с дисками, был косяк с контроллером, после настройки проблема ушла.
В общем не лишне саму дисковую подсистему проверить на скорострельность.

67 Альбатрос

14.05.15

✎

11:34

(66) Ну как бэ я не могу это сделать, а сисадмин по-любому скажет, что все норм и проверять не надо.

68 Kvant1C

14.05.15

✎

11:34

(65) Попробуй бэкап свернуть/развернуть

69 Klesk666

14.05.15

✎

11:34

а не проблемные базы типовые?

70 vde69

14.05.15

✎

11:35

(65) запускать нужно на рабочем сервере во время обычной работы юзеров... никаких эмуляторов, перепроведений и т.д.

там анализируется например время отклика клиента и т.д. то есть ситема в целом а не сервер

71 Kvant1C

14.05.15

✎

11:36

(67) >>сисадмин по-любому скажет, что все норм и проверять не надо

ну тогда скажи ему чтобы он со скулем тогда сам боролся...

72 Альбатрос

14.05.15

✎

11:38

(69) да, и все обновленные до последнего релиза. А проблемная это "Управление торговлей", редакция 10.3 (10.3.18.3)

(71) Ну он заявит что проблема в самой базе. При этом его заявление будет выглядеть логичным, ведь остальные базы не тормозят.

(70) Запустил на час без нагрузки, кроме обычной

73 Kvant1C

14.05.15

✎

11:42

(72) Ну тогда проблемы с диском можно отмести.

74 Альбатрос

14.05.15

✎

11:43

(73) Размер прироста выставлен в 200 мб при базе в 9гб. Судя по статье - норм показатель.

75 Гёдза

14.05.15

✎

11:45

(72) один работаешь или нет? Может регламент какой блокировки накладывает?

76 Гёдза

14.05.15

✎

11:46

Если только с этой базой так на этом сервере, то очень вероятно что именно они

77 Klesk666

14.05.15

✎

11:46

(73) это если база располагается также как остальные

78 Альбатрос

14.05.15

✎

11:52

(75) Нет, не один. На протяжении рабочего дня регламентов нет.

79 dmrjan

14.05.15

✎

11:52

Попробуй в MSSQL включить регулятор запросов, и поставь 2000-10000, документы будет проводится быстрее, а вот кто больше всего начнет кричать, у того и смотри. Обычно отчеты сами начинают ругаться на этот параметр.

80 dmrjan

14.05.15

✎

11:53

Начни с 2000.

81 Альбатрос

14.05.15

✎

11:54

(79) Это не скажется на работе других баз?

82 dmrjan

14.05.15

✎

11:55

(81) Если скажется, значит не все в порядке с другими базами. Но это не смертельно, всегда можно отключить это значение. Или поменять.

83 dmrjan

14.05.15

✎

11:57

Кстати - какой у тебя размер tempdb?

84 Kvant1C

14.05.15

✎

12:00

(74) Модель восстановления какая устновлена, full или simple? Если full, то поменяй на simple.

85 Альбатрос

14.05.15

✎

12:01

(84) Simple

86 Альбатрос

14.05.15

✎

12:01

(83) Где посмотреть? ))))

87 dmrjan

14.05.15

✎

12:04

В системных базах данных (86)

88 vde69

14.05.15

✎

12:06

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

оптимизация - она не быстрая... сделал проверил подумал, потом снова можно делать

89 Зеленый пень

14.05.15

✎

12:12

(45) Тогда сделай копию базы, там у модуля поставь галку "клиент" и отлаживай.

90 dmrjan

14.05.15

✎

12:14

Может проблема в том, что в файловой версии было прописано, что процедура выполняется локально, а нужно на сервере? Посмотри - при проведении - сколько у тебя грузится сеть.

91 Альбатрос

14.05.15

✎

12:44

(89) Ошибки валятся про мутабельные значения

92 Альбатрос

14.05.15

✎

12:46

(88) Тест ничего особо не показал, кроме LAZYWRITER_SLEEP, у нее 21 %, все остальные не превышают 12
Может все-таки нагрузить ее?

93 Альбатрос

14.05.15

✎

12:47

(90) Но ведь тогда замер бы на нее сработал, нет?

94 Альбатрос

14.05.15

✎

12:48

(87) Tempdb = 8мб, прирост 10%

95 Альбатрос

14.05.15

✎

12:49

+(92) ghjcnj ,fpf ctqxfc vj;tn ,snm yt jcj,j yfuhe;tyf gjkmpjdfntkzvb

96 Альбатрос

14.05.15

✎

12:49

+(92) просто база сейчас может быть вообще не нагружена пользователями

97 0wl

14.05.15

✎

13:00

(94) Получается, сервер недавно перезагружал?

Для tempdb это очень маленький размер, поставь изначальный размер хотябы Мб 500, иначе постоянно будут блокировки на расширении файла данных.

И я пропустил, индексы уже перестраивал? Если нет, запусти на ночь, днем перестроение индексов помешает работе пользователей

98 Альбатрос

14.05.15

✎

13:01

(97) Индексы регламентом перестраиваются в воскресенье - не помогло... Сервер перегружали сегодня ночью.

99 vde69

14.05.15

✎

13:21

(92) так ты выложи табличку...

100 dmrjan

14.05.15

✎

13:28

(94) (97) Получается база небольшая?

101 dmrjan

14.05.15

✎

13:31

(93) Замер мог и не сработать, ведь если запрос большой, то как раз пару минут данные и перекачиваются на твой компьютер, где потом происходит выборка.

102 Альбатрос

14.05.15

✎

13:56

(99) табличка результата
http://my-files.ru/jgf2g3

103 vde69

14.05.15

✎

13:58

(102) сюда ТЕКСТ скопируй...

а то у многих помойки заблокированы

104 Альбатрос

14.05.15

✎

14:05

***total***;                    30759327.0;      100.0
LAZYWRITER_SLEEP;               6494140.0;       21.1
XE_TIMER_EVENT;                 3571619.0;       11.6
LOGMGR_QUEUE;                   3536668.0;       11.5
REQUEST_FOR_DEADLOCK_SEARCH;    3545187.0;       11.5
SQLTRACE_INCREMENTAL_FLUSH_SLEEP;3535646.0;      11.5
FT_IFTS_SCHEDULER_IDLE_WAIT;    3480672.0;       11.3
CHECKPOINT_QUEUE;               2967207.0;       9.6
SLEEP_TASK;                     1774646.0;       5.8
BROKER_TO_FLUSH;                1771903.0;       5.8
SLEEP_BPOOL_FLUSH;              20295.0;         0.1
CHKPT;                          0.0;             0.0

105 Альбатрос

14.05.15

✎

14:06

Остальные по процентам нули

106 vde69

14.05.15

✎

14:11

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

107 vde69

14.05.15

✎

14:12

(106)+ план запросов кривой строится.

108 Альбатрос

14.05.15

✎

16:36

(106) Попробую, спасибо
(107) можно поподробней про план запросов?

109 mr_K

14.05.15

✎

16:51

Я в УТ не силен, но в УПП переписав думаю аналогичную процедуру УправлениеЗапасамиПартионныйУчет.ДвижениеПартийТоваров получил жутчайший прирост производительсти.
До этого были испробованы буквально все танцы с бубном вокруг SQL с практически нулевыми результатами.

110 Fragster

гуру

14.05.15

✎

17:16

(109) я об этом еще в (13) написал - что неплохо бы замер производительности сделать

111 Альбатрос

15.05.15

✎

05:24

(109) (110) Да, так и есть. Подключили мне наконец отладку на сервере и замер показал 92% времени выполнения на вот эту строчку - Возврат Запрос.Выполнить().Выгрузить(ОбходРезультатаЗапроса.ПоГруппировкам);

112 Альбатрос

15.05.15

✎

05:25

начинаю ковырять запрос )))

113 Альбатрос

15.05.15

✎

05:28

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

114 Альбатрос

15.05.15

✎

07:27

115 ЧеловекДуши

15.05.15

✎

08:26

(114) Используй ВТ для отбора

116 ЧеловекДуши

15.05.15

✎

08:29

+(114) >>> .Регистратор

Используй точный отбор: .Регистратор Ссылка Документ.Такой-ТО

У тебя же известен Вид докмента, по которому ведется отбор, так накой ты все отбираешь.
По составному типу, 1С компилирует запрос так, что все документы, которые выступают регистратором, участвуют в отборе...
В общем этот момент уже на 50% ускорит зарос :)

117 ЧеловекДуши

15.05.15

✎

08:32

Сдается мне, что у вас в БД все запросы нужно допиливать под SQL версию.

118 vde69

15.05.15

✎

08:58

тормозит вот это РегистрСведений.СписанныеТовары.Регистратор = &Ссылка"

вынеси этот запрос во ВТ и проиндексируй поля по которым джойнишь

это для начала :)

119 vde69

15.05.15

✎

08:59

(118) и не забудь привести тип регистратора в ВТ, там наверняка составной, а они во ВТ тупят прилично...

120 Альбатрос

15.05.15

✎

09:14

(116) (118) (119) Спасибо, сейчас буду пробовать

121 Альбатрос

15.05.15

✎

09:14

(117) К моей великой печали это скорей всего так

122 DayDreamer

15.05.15

✎

09:17

возможно вопрос не к месту, но на серваке с SQL какой установлен план электропитания? максимальная производительность или нет?

123 Альбатрос

15.05.15

✎

09:22

(122) Спрошу у админа как появится, у меня прав нет самому глянуть

124 DayDreamer

15.05.15

✎

09:28

(123) и еще вопрос - сервер физический или виртуальный?

125 Альбатрос

15.05.15

✎

10:22

(124) Физический

126 Альбатрос

15.05.15

✎

10:24

127 Альбатрос

15.05.15

✎

10:25

время выполнения упало с 2 минут до 6 секунд!

128 Альбатрос

15.05.15

✎

10:25

Радуюся, млять, как пацан, которому водяной пистолет подарили

129 Альбатрос

15.05.15

✎

10:26

Всем ОГРОМНОЕ спасибо, но , видимо, я эту ветку еще не раз подниму, ибо оптимизация только начинается (((

130 Гёдза

15.05.15

✎

10:27

вот тут еще можно соптимизировать
ПартииТоваровНаСкладах.ДокументОприходования.Дата

131 Альбатрос

15.05.15

✎

10:29

(130) Тоже вытащить в ВТ и соединить?

132 H A D G E H O G s

15.05.15

✎

10:29

(131) Давай я те готовый модуль сброшу, а?

133 vde69

15.05.15

✎

10:31

проиндексируй в ХП два поля

|    СписанныеТовары.Номенклатура,
|    СписанныеТовары.Склад

и еще у тебя в самом конце есть условие

ГДЕ
    |    СписанныеТовары.Регистратор = &ОсновнойДокумент

его или в джойн впихни или подними выше (сделай вложеный или ВТ)

134 Альбатрос

15.05.15

✎

10:39

(132) Давай))) bearsin62@Gmail.com
и другие модули тоже было бы круто ))))

135 Альбатрос

15.05.15

✎

10:41

(133) Ок, спасибо

136 serpentt

15.05.15