Добрый день. Проблема следующая: бехгалтерия 7.7 (sql), в базе одновременно работают 10 пользователей. Как только кто-то из них запускает формирование акта сверки, скажем, за месяц, все остальные начинают жутко тормозить. Как лечится эта проблема?
И еще момент. Во время групповой обработки документов частенько вылетает сообщение об ошибке "Время ожидания блокировки таблицы 1SJourn истекло". В принципе, это и так понятно, что таблица журнала доков в момент записи/проведения конкретного документа блокируется для всех остальных юзеров, но - опять же, - вроде бы есть какой-то патч?

(18)мож ты к полю Vdtsc0 обращаешься? Код нужно видеть.

(0) дело в том, что 1с не использует БухЗапрос

(19) Лови:

SELECT
   |    Проводки.DocID As [Док $Документ],
   |    Жур.IDDocDef As Док_вид,
   |    Проводки.SUM_ As СуммаПроводки,
   |    Проводки.AMOUNT As КолВо,
   |    Проводки.ACCDTID As [СчетДт $Счет.Основной],
   |    Проводки.ACCKTID As [СчетКт $Счет.Основной],
   |    Проводки.DTSC0 As СубконтоДт1
   |FROM
   |    _1SENTRY As Проводки (NOLOCK)
   |INNER JOIN
   |    _1SJourn As Жур (NOLOCK)
   |ON
   |    Проводки.DocID = Жур.IDDoc
   |WHERE
   |    Проводки.Active <> '*'
   |    AND (Жур.Date_Time_IDDoc BETWEEN :НачДата AND :КонДата~)
   |    AND (Проводки.ACCDTID IN (SELECT val FROM #ВТСчет) OR
   |         Проводки.ACCKTID IN (SELECT val FROM #ВТСчет))

(21)на ЭТОМ запросе валится ошибка? Или это уже что-то другое?

(22) Да, ошибка именно в таком виде. Если убрать Проводки.DTSC0 As СубконтоДт1, то запрос выполняется успешно.

(0)Поищи на Инфоstarte. Я переделывал для УСН, но смысл тот же. Заменил ВыбратьОперации с проводками  на использование бухитогов. Работает в разы быстрее.

(23)показывай тогда остальной обвес. Ошибки в запросе нет. Или ты не все показываешь!

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

(25) Что еще показать? Весь код процедуры? Мне вот тоже непонятно, почему из-за одной этой строки такая ошибка вываливается. Мож это там в самой таблице в этом поле где глюк какой сидит?

+27 всё, заработало :-) мой косяк был. В-общем, вариант в (23) рабочий. Теперь возникает вопрос, как это значение привести к типу 1с?

усё, со всем разобрался вроде бы :-)

ппц, я в шоке... Вот ведь какая хрень: сделал замер скорости выполнения обычного акта сверки 1С и сделанного на прямом запросе (см. (23)), с одними и теми же условиями. Так вот что получилось:
- время выполнения первого - 8 сек.
- время выполнения второго - 98 сек...

Прямые запросы меня начинают все больше разочаровывать... :(((
Как такое вообще может быть?! Что делать?

(30) см. в (20)

(31) То есть ускорить через прямой запрос эту фигню никак не получится?! :(((((((((((

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

(32) хз

(30)Попросить людей или сделать самому правильно. Чтобы сделать самому правильно, нужно попытаться понять, что ты своим запросом, с большой вероятностью, сканируешь кластерный индекс - отсюда и все проблемы.

(30) ты жалуешься или хвастаешься? :-)

(35) Можешь ткнуть в нужном направлении? Как можно оптимизировать запрос из (23), чтобы он шустрее работал?

(37) Тебе же уже сказали - использовать виртуальные таблицы

(38) Где про них можно почитать? Именно про таблицы для 1SEntry

(39) тебе надо использовать один из классов на базе 1С++
Либо ПрямойЗапрос либо AccountsRecordset

(40) Интересно... Что такого волшебного в этих классах, что только они позволяют ускорить запрос к таблице проводок?

Есличо, с классами вообще пока что не работал

http://1csql.ru/materials/articles/develop.html~ed7512c5-4b62-fb0e-5c98-b1987e9fe5f5

(41) они попадают в индексы получше, чем ты в (21). можно и без классов - посмотри на план выполнения и подумай

(44) Чо за план, как куриццо?

(43) Это я уже видел. Что там должно мне указать на то, как ускорить мой запрос?

Вот что нарыл:

http://www.1cpp.ru/forum/YaBB.pl?num=1265705989

Там сначала чувак, задающий вопрос, приводит вот такой код без AccountRecordset:

ТекстЗапроса = "
     |SELECT
     |  entr.DTSC0 as [Субконто $Справочник.ВидыНоменклатуры],
     |  jur.iddoc as [Док $Документ],
     |  jur.iddocdef as [Док_вид],
     |  sum(entr.sum_)   as ДО
     |FROM
     |  _1sentry as entr
     |INNER JOIN _1sjourn as jur ON entr.docid = jur.iddoc
     |WHERE
     |  entr.date_time_docid between :НачДата and :КонДата~
     |  and entr.ACCDTID = :СчетДТ
     |GROUP BY entr.DTSC0,jur.iddoc,jur.iddocdef
     | ";    

Затем - с оным:

RS=СоздатьОбъект("AccountsRecordset");
     RS.УстБД1С();
     
     // обороты 90.1
     ТекстЗапроса = "
     |SELECT
     |  entr.DTSC0 as [КорСубконто $Справочник.Контрагенты],
     |  entr.KTSC0 as [Субконто $Справочник.ВидыНоменклатуры],
     |  jur.iddoc as [Док $Документ],
     |  jur.iddocdef as [Док_вид],
     |  sum(entr.sum_)   as КО
     |FROM
     |  _1sentry as entr
     |INNER JOIN _1sjourn as jur ON entr.docid = jur.iddoc
     |WHERE
     |  entr.date_time_docid between :НачДата and :КонДата~
     |  and entr.ACCDTID = :СчетДТ
     |  and (entr.ACCKTID = :СчетКТ1 or  entr.ACCKTID = :СчетКТ2)
     |  and $РазделительУчета = :Предприятие
     |GROUP BY entr.DTSC0,entr.KTSC0,jur.iddoc,jur.iddocdef
     | ";    

Товарищи, т.е. фактически получается, что вариант 2 будет быстрее выполняться по времени по сравнению с вариантом 1?

(45) http://msdn.microsoft.com/ru-ru/library/ms190402.aspx

(47) это совсем разные запросы, сравнивать время их выполнения не имеет смысла. а так, для эффективной работы варианта 2 в нем не хватает отборов по provkind и active

Отбор по _1SENTRY почти всегда будет неоптимальным и тормозным. Акт сверки (обороты в разрезе движений) надо формировать бухзапросом, с отбором по субконто Контрагенты. Причем, по моему опыту - лучше не запускать запрос по всем счетам, а вызвать его несколько раз, по каждому счету, где есть субконто Контрагенты, далее эти данные свернуть в таблице значений. Почему-то несколько бухзапросов по одному счету выполняются значительно быстрее, чем один бухзапрос по списку счетов.

(49) Имеется в виду стандартный 1совский бухзапрос? Насколько быстрее?

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

(51) это будет тормозить, если по контрам не включен отбор

(51) Можно по-разному.. главное не запускать бухзапрос по списку счетов. И не использовать ВыбратьОперацииСПроводками. У нас на бухии изначально был акт сверки жутко тормозным, когда ушли от глобального бухзапроса по всем счетам - сразу стало всё летать, повышение скорости на порядок или на два. sql-версия.

Товарисчи - есть такой файл который называется Отбор проводок по субконто - _1sbkttl. Так вот именно его а также отбор проводок по счетам и надо использовать

(52) нужно нужно смотреть только обороты

(54) Как в данном случае его использовать?

(55) это понятно. но без отбора по субконто это выльется в скан таблицы проводок

(0) Перепиши акт сверки). Он все равно как был уе..ким так и остался.
(6) Памяти мало. SQL жрет дофига, а там еще терминальный сервер. Это ППЦ. Так то вообще изврат, но способ (SQL + TS) вошел прочно в обиход.

(57) нет
у БИ три таблицы : итоги/остатки/проводки
будет по итогам идти

(59) у тебя уже тяпница? :-) в таблице итогов нет данных о документах-регистраторах движений

и таблиц там куда больше трех

+58 По момему проще памяти добросить - очевидно что ее мало. Потом написать нормальный акт сверки без всяких прямых запросов - они тут нафиг не нужны... имхо, и не трахать мозг, 10 пользователей всего. Ну любят люди извращаться на ровном месте.

(0) а можно вопрос не в тему? Зачем бухгалтерскую базу с паршивым десятком пользователей сажать на sql? Терминал плюс dbf будут работать намного быстрее

(67) Память не поможет - всё равно последовательный скан это сильно не ускорит.. даже если сервер полностью базу закэширует. Алгоритмы надо переписывать. В типовой алгоритмы под sql не всегда оптимально построены..

(60) сколько больше ?

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

(61) "Нормальный" - это какой?

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

(66) Я тут подумал - из за акта может тормозить по одной причине - нехватает памяти. Так что наверное и переписывать ничего не надо. Хотя типовой уродский, писал свои давненько работали гораздо приятнее с использованием бух запроса обычного.

+68 Все делал в одном запросе, потом выюборка и все. Код был крайне компактный.

(69) Стандартный бух. запрос?

Почему про память говорю, потмоу что никакие таблицы в акте тут не блокируються... следовательно все упираеться тупо в производитеьность, котороя резко падает если не хватает памяти - ввиду использования под недостающее винта.

(70) Да

(70) Но я его не на почве производительности писал. Прсто тогда актов вообще не было в типовых))) да было время)

+73 Или был совсем убогий

(72) В таблице проводок хотя бы десяток мегазаписей есть? :)

(75) было наверное, я хрен его знает. Непомню уже.

(75) У человека тормозит не акт! Другие юзвери. Так что колбасить атк особого смысла не вижу.

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

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

+77 Ну т.е смыс есть но после увеличения памяти. Но вообще я повторюсь SQL + TS это дурдом на мой взгляд. Это уж когда выхода нет. Клиенты дохлые совсем, а в DBF база не влазит.

(79) С фига ли ее станет надо больше? Акт формируеться за определнный период по контретному контрагенту. Т.е. ясное дело SQL зажрет еще себе сколько влезет, но к акту никакого отношения это не имеет.
Я вот что то думаю, что SQL столбит себе память, терминальные сессиям вероятно приходиться сосать... с диска). Както так. А править алгоритмы в данном конкретном случае тут дело третье. Добавте памяти страждущему. Ведь каждая сессия дофига жрет памяти а тут еще данные обработать надо. 4Гб для SQL + TS - фигово, как впрочем и сама конфигурация дурацкая - SQL + TS.

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

(62) Кстати у меня один и тот же запрос Бух на SQL базе выполняеться в 10-ки раз быстрее чем на DBF. Практика. Правда я терминалы не сажу на SQL сервер)

(81) Давать советы типа "добавьте памяти", не видя реального состояния системы, показаний счетчиков производительности в динамике, в часы наибольшей нагрузки и в среднем - по меньшей мере непрофессионально!

(82) спс, гляну

(84) А че тут видеть то? - Чисто из опыта 4ГБ ОЗУ одной SQL то было мало на сравнимой базе - предел по DBF и за, а тут еще сессии терминальные подвешены на серваке. Я бы и думать не стал удволи бы и все. Тут вопрос в винде сервачной - сожрет ли 8 и все. А так самое простое и экономически целесообразное решение.  Худже точно не будет, а дальше бы уже думать стал.

+86 если с памятью напряг подумал бы на перевод части юзверей с терминального клиента.

Напряг в дисковой подсистеме в первую очередь, а потом уже с памятью. Чтобы построить акт нужно перебрать за период горы данных тупым сканированием, хоть и, кластерного индекса. Физически это можно сравнить с тем, как золото добывают - большими экскаваторами выгребать руду, а потом искать писчинки золота. Вот ковш экскаватора это память скуля. И сессно, если ковш больше, то и загребать он сможет больше и, вроде как, дело пойдет быстрее. Но один фиг перебираем горы. Нужно искать подход такой, чтобы грести золотой песок - попадание в индекс. Как-то вот так :)

(88) Хорошо сказано!

(88) Ну, сранение красивое, не спорю :) Только теория она теория и есть. На данный момент самый быстрый вариант - акт сверки, о котором речь в (82). И это не прямой, а обычный, бухгалтерский запрос 1С.

(+88) Индекс в подобной аналогии - это подробный указатель координат точек, где этот золотой песок находится.. и рыть экскаватору приходится на порядки меньше.. и можно обойтись меньшим размером "ковша".

(90)уже было сказано, что запрос ты нарисовал не верно. Логически он верен, конечно. Но часто решение в лоб не дает хороших результатов, что и доказал твой опыт.

Вот смотри..
0. sp_help '_1sentry' - вот тут тебе будет вся инфа по табличке.
1. изучаем индексы для этой таблички: PK__1SENTRY, ACCDTID, ACCKTID и другие не интересные.
2. твой запрос идет по идексу PK__1SENTRY - 100%, а это тупо проводки отсортированные по дате (упрощенно говоря), следовательно, чем больше период, тем страшнее.
Вывод: нужно искать другие пути.

Если у тебя включен отбор по Контрагентам (как уже тебе тут твердили) - Метаданные-ВидыСубконто-Контрагенты-Отбор, то у тебя в табличке _1ssbsel будет немного счастья. Потому как sp_help '_1ssbsel' кажет там индекс VALUE, из значений которого можно спозиционироваться в таблице _1SENTRY.

(92) Где эти индексы находятся? В самой табличке _1SENTRY? Она у мну дюже здоровая... При попытке ее открыть QA мну на хутор за бабочками посылает :(

(93)да.

(92) Глянул. Тогда возникают след. вопросы:
1. По какому индексу оптимальнее строить запрос?
2. Как заставить RecordSet выполняться именно по этому индексу?

(95)я, №;ять, на китайском написал (92) чтоли?

(96) "немного" счастья - это сколько? :)

_1ssbsel - это у нас таблица отбора субконто, я правильно понял?

Делаю запрос с соединением таблиц журнала доков, 1ssbsel и 1sentry - вываливается ошибка "подключение занято до получения результатов для другого hstmt". Что опять за хня? SET NOCOUNT ON не помогло.

100!

ап

(99) результат = рекордсет.выполнитьинструкцию(текстзапроса);

(102) ?

(103) используй выполнитьинструкцию вместо открыть/получить/закрыть

(104) Какие "открыть/получить/закрыть"? Ты о чем вообще?

(105)народ телепатирует как может.

(88) А SQL то думаете почему память выжирает? Кусок базы в памяти вертиться. Винт тут не причем.

+107 Если бы про DBF шла речь еще туда сюда... И то винда кэширует диск.

По моему чем второй день обсуждать, уже давно памяти можно было купить и попробовать .елси конечно это реально и память не спецефическая. Хотя судя по процу врядли. Это очень древний комп.

(0) Что еще крутится на SQL-сервере?

(0) лови оптимизированный акт.
http://info_start.ru/public/75034/

(109) Хотя судя по процу врядли, это очень древний комп.
Так правильно.

(107) В памяти "вертится" кусок базы, к которому были последние обращения, это базовая стратегия кэширования. Как правило, на реальных задачах одновременный доступ сразу к гигабайтам данных не происходит. При увеличении объема кэша данные конечно с большей вероятностью окажутся в оперативной памяти, но прирост быстродействия тут явно не линейный. Можно увеличить объем памяти вдвое, но получить прирост быстродействия в единицы процентов.

(113) SQL память выжирает это факт. Какое там у нее кэширование и алгоритмы работы спамятью, я понятия не имею. Думаю как раз что вовсе не обычное кэширование. Потому что жрёт она сразу и не мало.  Кэширование, которое вы описали - это общий универсальный принцип для всех приложений - это ОС организует, СУБД думаю делает разумнее, вероятно знает какую информацию надо в память пихать, что бы потом за ней пореже на диск ползать, возможно и статистику ведет, возможно разработчик базы может подсказать.
Не знаю мне лично ситуация прозрачна. Напихать памяти в первую очередь. А дальше голову ломать.
У меня схожая ситуация была память 4Гб, бюджетка с типовым актом, размер как раз вышел за предел DBF (перестала загружаться в DBF), и ничего не тормозило из-за актов, SQL тоже 2000, только терминалов не было. Проц. был дохлее. Ну райд 3 был. Более того бух. запросы выполнялись постоянно оплату рассчитывали по документам (ну тут не оптимально конечно, и с основных итогов) - ничего, 20 юзверей сидело.
Все проблемы начинались при блокирвоках при тяжелых проведениях, ну а что бы из за акта - это фантастика.

(111) Ай, спасибо тебе, добрый человек!

(111) штатный ?

(116) Да, с периодичностью по проводкам. Летает :)

Давно бы так и сделал