После проведения документа в 1С8.2 УПП тормозит SQL
Есть 2х Xeon (всего 16 потоков) сервер 32Гб опер., raid, 2008R2, на нем SQL2008SP1 и сервер предприятия 8.2.15.289
База УПП 1.3.15 весит около 30Гб
Было замечено, что при проведении документа "Отчет о розничных продажах" (около 60 строк) sqlserver на пару секунд загружает почти на 100% все 16 потоков, потом все освобождаются от нагрузки, кроме одного, который так и весит на 100%, через некоторое время может перескочить на другой поток, но так же на 100%. Естественно документ проводиться около 5 минут и в это время никто не может провести. Хуже того, все последующие проведения различного вида документов так же происходит на одном потоке и очень долго (раз в 10). Лечиться перезагрузкой sql сервера.
Кто-нить может подсказать в чем может быть дело (sql, 1С?) и как с этим справляться?
База УПП 1.3.15 весит около 30Гб
Было замечено, что при проведении документа "Отчет о розничных продажах" (около 60 строк) sqlserver на пару секунд загружает почти на 100% все 16 потоков, потом все освобождаются от нагрузки, кроме одного, который так и весит на 100%, через некоторое время может перескочить на другой поток, но так же на 100%. Естественно документ проводиться около 5 минут и в это время никто не может провести. Хуже того, все последующие проведения различного вида документов так же происходит на одном потоке и очень долго (раз в 10). Лечиться перезагрузкой sql сервера.
Кто-нить может подсказать в чем может быть дело (sql, 1С?) и как с этим справляться?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Исходные данные вопроса порождают ещё больше вопросов.
Хотелось бы узнать какая УПП, а именно типовая или с доработками. Может там после проведения запускается в фоне мегорасчет по розничным продажам.
А в настройках 1С и SQL какая стоит частота перестройки индексов, сколько выделено памяти под SQL?
Хотелось бы узнать какая УПП, а именно типовая или с доработками. Может там после проведения запускается в фоне мегорасчет по розничным продажам.
А в настройках 1С и SQL какая стоит частота перестройки индексов, сколько выделено памяти под SQL?
>Кто ж Вам присоветовал SQL - сервер переустанавливать?
А что здесь страшного, большинство проблем таким способом решается
>1)формирование транзакции из приложения (по каким регистрам проводится)
Регистров там аж семь штук и они все стандартные. Не хотелось бы переписывать запросы с обновлением потом замучаешься.
>После этого смотрите в таблицы в самом сервере. Возможно индексы вообще не задействованы в момент проведения.
Как узнать какой индекс нужно создать чтоб ускорить формирование запроса?
Вот запрос на котором долго весит СКЛ:
exec sp_executesql N'SELECT
T1._Fld19078,
T2.Fld21482_TYPE,
T2.Fld21482_RTRef,
T2.Fld21482_RRRef,
CASE WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x00000176 THEN CASE WHEN T10._IDRRef IS NOT NULL THEN 0x00000176 END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000019C THEN CASE WHEN T11._IDRRef IS NOT NULL THEN 0x0000019C END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001AC THEN CASE WHEN T12._IDRRef IS NOT NULL THEN 0x000001AC END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011B THEN CASE WHEN T13._IDRRef IS NOT NULL THEN 0x0000011B END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DD THEN CASE WHEN T14._IDRRef IS NOT NULL THEN 0x000001DD END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011D THEN CASE WHEN T15._IDRRef IS NOT NULL THEN 0x0000011D END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DC THEN CASE WHEN T16._IDRRef IS NOT NULL THEN 0x000001DC END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011E THEN CASE WHEN T17._IDRRef IS NOT NULL THEN 0x0000011E END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001E3 THEN CASE WHEN T18._IDRRef IS NOT NULL THEN 0x000001E3 END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DB THEN CASE WHEN T19._IDRRef IS NOT NULL THEN 0x000001DB END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000019A THEN CASE WHEN T20._IDRRef IS NOT NULL THEN 0x0000019A END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x00000161 THEN CASE WHEN T21._IDRRef IS NOT NULL THEN 0x00000161 END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000000F9 THEN CASE WHEN T22._IDRRef IS NOT NULL THEN 0x000000F9 END ELSE CAST(NULL AS BINARY(4)) END,
CASE WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x00000176 THEN T10._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000019C THEN T11._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001AC THEN T12._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011B THEN T13._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DD THEN T14._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011D THEN T15._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DC THEN T16._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011E THEN T17._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001E3 THEN T18._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DB THEN T19._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000019A THEN T20._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x00000161 THEN T21._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000000F9 THEN T22._IDRRef ELSE CAST(NULL AS BINARY(16)) END,
CASE WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x00000176 THEN T10._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000019C THEN T11._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001AC THEN T12._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011B THEN T13._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DD THEN T14._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011D THEN T15._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DC THEN T16._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011E THEN T17._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001E3 THEN T18._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DB THEN T19._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000019A THEN T20._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x00000161 THEN T21._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000000F9 THEN T22._Number ELSE CAST(NULL AS NVARCHAR(11)) END,
CASE WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x00000176 THEN T1
А что здесь страшного, большинство проблем таким способом решается
>1)формирование транзакции из приложения (по каким регистрам проводится)
Регистров там аж семь штук и они все стандартные. Не хотелось бы переписывать запросы с обновлением потом замучаешься.
>После этого смотрите в таблицы в самом сервере. Возможно индексы вообще не задействованы в момент проведения.
Как узнать какой индекс нужно создать чтоб ускорить формирование запроса?
Вот запрос на котором долго весит СКЛ:
exec sp_executesql N'SELECT
T1._Fld19078,
T2.Fld21482_TYPE,
T2.Fld21482_RTRef,
T2.Fld21482_RRRef,
CASE WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x00000176 THEN CASE WHEN T10._IDRRef IS NOT NULL THEN 0x00000176 END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000019C THEN CASE WHEN T11._IDRRef IS NOT NULL THEN 0x0000019C END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001AC THEN CASE WHEN T12._IDRRef IS NOT NULL THEN 0x000001AC END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011B THEN CASE WHEN T13._IDRRef IS NOT NULL THEN 0x0000011B END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DD THEN CASE WHEN T14._IDRRef IS NOT NULL THEN 0x000001DD END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011D THEN CASE WHEN T15._IDRRef IS NOT NULL THEN 0x0000011D END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DC THEN CASE WHEN T16._IDRRef IS NOT NULL THEN 0x000001DC END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011E THEN CASE WHEN T17._IDRRef IS NOT NULL THEN 0x0000011E END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001E3 THEN CASE WHEN T18._IDRRef IS NOT NULL THEN 0x000001E3 END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DB THEN CASE WHEN T19._IDRRef IS NOT NULL THEN 0x000001DB END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000019A THEN CASE WHEN T20._IDRRef IS NOT NULL THEN 0x0000019A END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x00000161 THEN CASE WHEN T21._IDRRef IS NOT NULL THEN 0x00000161 END WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000000F9 THEN CASE WHEN T22._IDRRef IS NOT NULL THEN 0x000000F9 END ELSE CAST(NULL AS BINARY(4)) END,
CASE WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x00000176 THEN T10._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000019C THEN T11._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001AC THEN T12._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011B THEN T13._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DD THEN T14._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011D THEN T15._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DC THEN T16._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011E THEN T17._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001E3 THEN T18._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DB THEN T19._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000019A THEN T20._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x00000161 THEN T21._IDRRef WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000000F9 THEN T22._IDRRef ELSE CAST(NULL AS BINARY(16)) END,
CASE WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x00000176 THEN T10._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000019C THEN T11._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001AC THEN T12._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011B THEN T13._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DD THEN T14._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011D THEN T15._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DC THEN T16._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000011E THEN T17._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001E3 THEN T18._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000001DB THEN T19._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x0000019A THEN T20._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x00000161 THEN T21._Number WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x000000F9 THEN T22._Number ELSE CAST(NULL AS NVARCHAR(11)) END,
CASE WHEN T2.Fld21482_TYPE = 0x08 AND T2.Fld21482_RTRef = 0x00000176 THEN T1
Переустановка SQL сервера ничего не дала. Установка SQL Enterprise Edition тоже.
То, что документ "О розничных продажах" долго проводиться меня мало беспокоит. Почему после его проведения все остальные проведения документов начинают тормозить (в 10 раз медленнее) вот в чем вопрос?
То, что документ "О розничных продажах" долго проводиться меня мало беспокоит. Почему после его проведения все остальные проведения документов начинают тормозить (в 10 раз медленнее) вот в чем вопрос?
Кто ж Вам присоветовал SQL - сервер переустанавливать? А? Смотрите в два места: 1) формирование транзакции из приложения (по каким регистрам проводится, какие доп операции формируются в момент проведения). 2) После этого смотрите в таблицы в самом сервере. Обратите внимание на индексацию таблицы, по которой проходит транзакция! Как построен индекс и какие поля задействует ваша транзакция. Возможно индексы вообще не задействованы в момент проведения. Вот процы и молотят на сухую без индексов.
документ слишком много делает движений по регистрам если документ не типовой а был доработан программистами тогда все понятно надо менять и оптимизировать код документа. Деалть его более легким.
Второй вариант нужно ресурсов сервака поболее поставить например нарастить оперативную память.
SQL переустанавливать смысла нет.
Второй вариант нужно ресурсов сервака поболее поставить например нарастить оперативную память.
SQL переустанавливать смысла нет.
>если документ не типовой а был доработан программистами ...
уже несколько раз говорил, что документ ТИПОВОЙ.
>нужно ресурсов сервака поболее поставить например нарастить оперативную память
Памяти на серваке: 32Гб - это уже больше размера самой базы (30Гб)
P.S.: Можно советы дельные давать, а не отделываться общими фразами...
уже несколько раз говорил, что документ ТИПОВОЙ.
>нужно ресурсов сервака поболее поставить например нарастить оперативную память
Памяти на серваке: 32Гб - это уже больше размера самой базы (30Гб)
P.S.: Можно советы дельные давать, а не отделываться общими фразами...
Сегодня с аналогичной проблемой у себя на работе столкнулся, SQL 2005 , 1с8.0 ,база 200гб , тупо висит при проведении, хотя за неделю до этого всё работало и с 200Гб, эта хрень выросла в течении недели с каждым днём всё больше и больше\ Буду пробовать шаманить с серваком и с SQL, конкретных вариантов пока нет.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот