Доброго времени суток всем.
Моё обращение к форуму в сабж. Не хватает знаний применения прямых запросов к базе из 1С. Умею строить запросы на встроенном языке 1С, а  так же SQL запросы. Но как то одно с другим у меня плохо складывается по синтаксису и в понимании как запрос написанный средствами 1С преобразовывается в SQL. Знаю, тут есть много профессионалов и специалистов по платформе. Отсюда и вопрос. что можно почитать, чтобы разобраться в этом вопросе?

(39) ну и в чем проблема тогда? Сделай копию базы для отчетов, настрой репликацию sql или обмен 1Сный пусть в своей копии кувыркаются. Зачем прямые запросы?!

(31) Литературы нет. Вообще. Внутренняя кухня 1С - закрыта, вмешательства недопустимы.

Для понимания процессов достаточно:
1) ms sql profiler
2) Структура таблиц 1С: https://its.1c.ru/db/metod8dev#content:1798:hdoc
3) Структура индексов 1С: https://its.1c.ru/db/metod8dev/content/1590/hdoc

(40) Ахереть совет.

+(40) хотя с репликациями там всегда траблы были. Лучше 1Сный обмен настроить.

(37) Возможно. Я просто не вижу смысла делать запрос из базы 1с в скуль которым она работает. Ну тока если большое количество записей поменять сразу(Аля поиск и замена в документах для экстремалов)

Хочешь поучить/посмотреть запросы 1Ски со скулем есть чудесный инструмент SQL profiler

(42) Все эти ваши експерты по техвопросам вообще ни о чем. Вот партионный учет тормозит давай иди потрать год, перепиши на кошерный код, получи прирость в 0.01 процента.

(42) как вы и говорили... с Египтянином весело будет.
(40) (43) Какой обмен? .. нужны актуальные отчёты в пределах 5 минут максимум

(46) + точнее в минутные отчёты

(43) РИБ на большой загрузке не работает.
И 1С никогда не была реляционной БД

(46) А ну давай давай сиди тормози дальше. С    H A D G E H O G s тебе еще веселей будет.

(41) в зависимости от версии и выставленной версии совместимости структура меняется

(45) "Все эти ваши експерты по техвопросам вообще ни о чем."

Вот сейчас обидно было.

(46) раз ты такой умный, то что же у тебя отчеты по 40 минут собираются?

(52) читай выше... Поднялся объём базы и количество пользователей

(47) Попробуй начать делать оптимизацию запросов самой 1Ски. Все явные параметры указывай в запросе, подумай над структурой самих запросов. С прямых запросов много времени не выиграешь. Имеет смысл быть если лезишь в другую базу и хочешь без ком соединения

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

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

*Ври - вот.

(53)+ При этом не у меня! База переписанная многими до меня. Отчеты нормально работали (по производительности, но с резким увеличением объёмов некоторые из них надо оптимизировать

(58) А что по ресурсу сервака? может просто оперативы мало/база не на ssd/ Ширина канала маленькая

(54) Вот. Дельный разговор пошёл. Дело осложняется тем. что на некоторых филиалах ещё "Торговля и Склад" 77 крутится. Через обмен получаем дневное обновление с этих баз.

(60) данные этих филиалов не критичны для отчетов основного филиала. Во время обмена отчеты фин.отдела выдают сообщения, что отчет будет выдан без учета изменения филиалов

(58) В общем ты утомил, я тебе сказал, что надо делать для начала.
(60) только эти  тяжелые запросы надо найти сначала. Во первых в проведении документов. А там уже решать, что делать. Ну, а так чего тут разговаривать, ты глуп, работодатель жлоб раз нанял тебя на работу, страдайте.

(59) Серверных проблем нет. Три сервера, по ресурсам все отличные.

(62) Зато ты "умный" не фига толкового не сказал. а деньги уже требуешь... За хз какое решение

(61) Разбирать, смотреть, учить... В (41) есть инфа от которой для начала можно оттолкнуться.Дальше все индивидуально от базы и задачи.

(63) Счастье - в неведении.

(66) Системное администрирование - это моя первая специальность по диплому. Программирование - это дополнительное образование. Так что ведаю...

(64)
1. Вот смотри, у меня в УПП документ проводился 2 часа, я отладчик на замер поставил, нашел место, где в цикле данные искались по построителе запросов, я взял вместо построителя  сделал тз, выгрузил туда запрос, проиндексировал поля по которым был поиск, документ стал проводится в 4 раза быстрее.
2. Проводились у меня некоторые документы по 2 минуты некоторые, я взял замер поставил, выяснил, что это те документы, в строках, которых была номенклатура с 20 000 характеристик. Взял и переписал запрос с отбором по характеристикам.
И так далее. Чем тебе я могу помочь удаленно? Тебе свои мозги вставить?

(65) Спасибо за адекватные ответы. Начну толкаться от структуры (41)

+(68) работал я еще на семерке, полез код оптимизировать, а там в проведении документа, каждые 30 строк кода регистрыРасчитатьНА по 3 секунды и так раз 20, а еще до кучи Вопрос("Желаете там чего то сделать?). Небось такой же как ты фокспрошник навоял. Правда он потом плохо кончил, взял базу данных конкурентам слил, так его прям с работы в наручниках увели, так и не знаю, что с ним потом стало. С твоими умственными способностями, тебе тоже самое грозит.

(68) >>> "я взял вместо построителя  сделал тз, выгрузил туда запрос, проиндексировал поля по которым был поиск" <<<

Что ты имеешь ввиду под индексацией полей? Проидексировал их один раз? Или поставил в конфигураторе эти поля индексируемыми? Например в справочниках... проиндексировал "нужные" поля.. И что получается? Теперь список справочника минут 10 открывается

(55)
Что, Морозов не дал тебе корочку? Поэтому так пригорает?

Мне вот интересно, какие поделия писал автор на Дельфи.

(72) Морозов, не давший корочку - это даже почетно и не обидно.

(71) Было ПостроительТакойто.Найти(дло,ждло,ждло,дло) как то так я из построителя выгрузил в ТЗ, ТЗ.Индексы.Доабвить(ждл)
ТЗ.Найти(жд,ддлж)

Но, это частный случай тебе это не поможет, у тебя же не УПП и не расчет себестоимости.

(71) Он про индексы в ТЗ, куда ты разогнался, успокойся.

(75)
Напиши об этом еще не менее 5 раз, опиши все подробности, мы не до конца прониклись всей твоей гениальностью!

(73) Ну еще много баз есть делфях держиться, которые невозможно перевести в 1С.

(71) по индексируемым полям в ТЗ или временной таблице в запросе идет быстрый поиск, условие ГДЕ и соединение в разы быстрее. Как ты на фокспро то писал?

(75) Научишь?

(80) а чему там учить? Есть у тебя таблица значений, в ней 100500 строк, если ты в ней ковыряешься методом Найти, то поле по которому ты ищешь должно быть отсортировано и проиндекировано. ТЗ.Индекс.Добавить("поле поиска"). ТЗ.Сортировать("поле поиска").

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

(81) Ага. А еще и выделено красным цветом. Красный цвет акцентирует внимание 1С на этом поле.

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

А то, вдруг я ваши поделища потом встречу.

(83) Ты мне просто завидуешь, что я смог ускорить закрытие месяца в УПП в разы, без всяких там ЦУПОВ, ЦКК и прочих разводов на деньги.

(81) В любом поисковом случае индексируй? Я правильно понял?

А если меня надо искать по двум колонкам, какую сначала проиндексировать?

(85) Истинно говоришь, я в немом восторге от твоего божественного скилла

(85) Подумаешь.
Гляди, чего люди добиваются
Конференция Маньяка Как за 5 лет одиночкой заработать миллионы на своих разработках

(86) Если там 10 строк то не индексируй, если там 100500 строк то индексируй. Да хоть все 10 колонок проиндексируй, на поиске это никак не скажется, просто новые строки после этого не добавляй будет тормозить.

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

(82) Жаль, платформа творит гениальному программисту засады и не дает сортировать временные таблицы, в которых нет top xx. Реальные пацаны выгружают в ТЗ, сортируют руками и помещают обратно. Говорят, некоторые умудрялись достигатьв  расчете себестоимости такого ускорения, что она вычислялась даже немного раньше, чем пользователь нажимал "Провести"

(91) Еще один завистник. Я не виноват, что пацаны из 1С написали в закрытии месяца Построитель.Найти("дл"), в котором оно ковыряется часами. Я молодец переписал как надо.

(89)
"Да хоть все 10 колонок проиндексируй, на поиске это никак не скажется"

Какая интересная мысль. Ты главное не останавливайся!

(93) я читай (90).

(94) Ты бы хоть про составные индексы почитал бы чтоли, подумал бы как они работают

(92)
Всё классно, только ты за древностью времен забыл, что это не построитель был, у которого нет метода "Найти", а выборка из запроса, и УПП был какой-нить 1.2

(95) Документ проводился 2 часа, стал проводится 30 минут. Чего тебе от меня еще нужно? Чувак из 0 попросил примеров оптимизаций, я ему их дал. Прежде чем искать, что то где то или соединять в запросе, добавь индекс по полям поиска, условия или соединения.

(97)
Ты несешь какой-то синтезированный бред в виде "советов".
Льёшь полную кашу, не понимаешь отличия нескольких одиночных индексов от составного, не понимаешь отличия индекса от сортировки, лепишь наугад что попало, ориентируясь на свой опыт, который даже нормально не можешь вспомнить и который актуален чуть менее, чем никак на сегодняшний день.

(93) Индексируй в любом не понятном случае ...

(98) 1.3 по любому никто там ничего так и не переписывал это раз. У меня дома была большая советская энциклопедия в 53 тома, к ней шло два тома индексов, где было написано в каком томе, что искать. Так, что таки что такое индекс, это я понимаю. В отсортированной таблице поиск быстрее.

Ты то со своим экспертом каких успехов добился кроме понтов? Я конкретно ни одну базу из ховна вытащил, а ты?

+(101) Я на конкретных предприятиях, на конкретных базах в 100-200 пользователей, добился конкретных успехов. А от вас вообще никакой пользы, кроме ну мы бы наоптимизировали, но это будет стоить 100500тыщ руб, так что сидите и терпите.

(100) А ты точно 1Сник? Чем номер строки в таблице документа, отличается от индекса?

(103) Объясняю для идиотов. я понимаю, что ты в лесу без библиотек жил. Но представь ситуацию простую есть у тебя книжка, где написано что статья ВасяПупкин лежит в томе, 5. Ты идешь к стелажу а там 1,2, 3,4,5 , о вот пятый том. или ты ищель к стелажу за 5тым томом,  а там 10, 50,34,12,1,52,5. В каком случае ты найдешь свою статью быстрее?
А ты точно не умственно отсталый?

(100)
Если бы ты хоть заглянул в эти свои бессчисленные энциклопедии, ты бы понял, что индекс - это и есть отдельная таблица с указателями, отсортированными по полям индекса. Мы, конечно, говорим не про кластерный, т.к. речь про ТЗ.
Ну и специально разжую вывод - когда поиск идет по индексу, сортировка основной таблицы уже не имеет значения.

(103) Он - самый настоящий, классический 1Сник. Не сомневайся.

(106) А вы типа голубых кровей? Ну подумаешь, с сортировкой это лишнее было. Зато тз.индексы.добавить вполне себе рабочее решение.

(102)
Сынок. Вопрос нужно ставить так: "А ты сколько баз вытащмл после таких как я гениальных оптимизаторов?"
Вам по рукам бить надо и клавиатуру больше не давать, с таким сочетанием гонора и некомпетентности нельзя подпускать к живым базам

(107) "Ну подумаешь, с сортировкой"
Херня случается. Даже красным цветом выделять не пришлось.

Потом дойдешь до того, что и в ВТ индексирование не нужно.

(108)  вопрос для голубых кровей.
1) Дает ли прирост в поиске по ТЗ.Найти("код") по таблице ТЗ.Индексы.Добавить("код"); ТЗ.Найти("Код")?

Дает ли прирост при объединении
Или ВЫБРАТЬ ЧегоТо
ПОМЕСТИТЬ ВремТЧ
ИЗ
Траливали
ИНДЕКСИРОВАТЬ ПО ЧегоТо

////
ВЫБРАТЬ ЧегоТО
Из ВремТЧ
   ВНУТРЕННЕЕ СОЕДИНЕНИЕ Таблица2 КаК Таблица2
        ПО ВремТч.ЧегоТо = Таблица2 .ЧегоТо

Дает ли здесь прирост Индексировать если таблицы огромные или нет?

а сейчас уже не банят за оскорбления на форуме?

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

(106) Это тот который от ста тыщ, не меньше.
(110) А почему "Траливали" сразу не соединить внутреннем? Меньше кода => быстрее работает
(111) Так я же простофиля, все норм

(110) "Дает ли здесь прирост Индексировать если таблицы огромные или нет?"

нет, не даст.

(113) Я не достоин отвечать на такие вопросы, вон пусть эксперты отвечают. Но, есть мнение, что sql при каждом соединении будет циклом всю таблицу перебирать

(110) Да вот представь себе, что без индекса в таблице2 по полю ЧегоТо, толку от всего этого не будет.

(115)
Ну да.
ВТ с индексом это вообще гарантия успеха.
У тебя таблица с 30 000 000 строк и нужно найти 2 строки по неиндексированному реквизиту?
Помести ее всю в ВТ, проиндексируй это поле и потом дерзко и эффектно отбери из нее 2 строки!

(116) а теперь представь, что ВремТЧ  - это ТаблицаРегистраОстатков, а Таблица2  это табличная часть документа из 10 строк. Будет прирост?

(118) Начнем с того, что карачун настанет на момент помещения большой таблицы в ВТ. На этом и закончим. Если ты имеешь намерения поместить Остатки без фильтра, что еще более дичь.

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

(119) а зачем мне вся таблица остатков? Я х.з. как вам там мозги выносят на ваших экспертах, но 1С пишет в типовых вот так. И я просто повторяю. А чего там как это уже не важно.

(118) Без индексов sql построит hash-join и даже не почешется.

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

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

(115)
Для каждого ... по

А ваще скуль не перебором кареток работает.
(120) Имеет смыл в некоторых местах индексировать когда условие состоит из нескольких полей, где есть условие = и <>, или что то похуже

(121)
Я не знаю, зачем тебе вся таблица остатков.
Но это именно ты описывал кейс, обозначил таблицу остатков и сказал, что в ней много записей

Понятно что здорово, но здорово непонятно

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

а упп на каком скуле быстрей работает?

(0) Зачем так сразу? Сначала нужно провести анализ: что тормозит и почему.  Возможно, у тебя кривая структура данных. Или алгоритмы "кривые".

(0) тут даже эксперты по технологическим вопросам встречаются (минимум 2 в 1 сотне постов отписались)... вопрос "как ускорить" - это к ним.
Чтение мимо сервера 1С - нао=рушение лицензионного соглашения, начтите с того что-бы прочитать именно его.

(0) Начни с этого Книга знаний: Эффективное использование MSSQL с помощью ВК 1C++

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

(0) Хехе, вы не с того начали, если проблемы с производительностью. Ну вам тут уже все рассказали. ) Запросы 1С обычно преобразуются в более-менее прямые запросы в SQL. Если по каким-то причинам этого не происходит, план запроса не оптимальный и выполняется долго, нужно каждый случай рассматривать отдельно. В УТ10 куча стандартных отчетов на универсальном отчете, которые можно загнать в **пу некорректной настройкой, к примеру, взять ведомость по партиям товаров и навыбирать условий по документу расчетов или регистратору, через "несколько точек". Тогда, конечно, он будет выполняться по 40 минут, особенно если не настроен план обслуживания в SQL. В общем, почитайте на предмет производительности Мисту и Инфостарт, много любопытного откроете. )

все не читал, но осуждаю, если отчеты тормозят, то дело в самих отчетах, а не в СУБД или серванте 1С

(134) В космосе хаос все люди грешники так спасемся

Что-то ветка превратилась в индексо-срач какой-то :)

(0) как минимум, вот это: http://v8.1c.ru/metod/books/book.jsp?id=499

(39) для этого прямые запросы не нужны.

(136) а разве так не всегда бывает, когда в ветке появляется слово sql?

(138)
Тут началось с вброса "все эти ваши эксперты-шмексперты фигня, я тут давеча узнал, что ТЗ можно индексировать!"