Периодически смотрю планы ресурсоемких запросов в СКЛ мониторе.. Студия дает рекомендации по сабжам..

типа создать некласторизированный индекс
для RA99
столбцы ключа SP100, DATE_TIME_IDDOC
включенные столбцы (покрывающий индекс)
--
для 1sjourn
СК (IDDOCDEF, DATE_TIME_IDDOC)
ВК (IDDOC, CLOSED)

стоит пробывать?

пробый

(1) вопрос - не повлияют ли манипуляции с индексами на данные БД?

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

(2) Как индексы могут повлиять на данные?
Единственно - что они у тебя после обновленя структуры исчезнут, заново создавать придётся

неужели не было рекомендации отказа от PK ROW_ID ?

(4) ясно. ну спрашиваю подстраховаться =)
(5) ? подробнее

(6)

подробнее - в поиск.

(5) Студия таких рекомендаций не даёт. Даёт адвайзер, и то если галку поставиьт

(8) пусть будет так =) верхнее окошко при отображении плана выполнения запроса

+(7)
http://www.softpoint.ru/article_id163.htm

(9) Там ты не увидишь рекомендаций по удалению индексов.

(0) SP100, DATE_TIME_IDDOC на RA99 делается штатно путем вкл. галки "отбор движений" у соответствующего измерения

(10) пасиб, просвещаюсь =)
(12) буду знать
(9) считаешь, что оно рекомендует зря?

(13) нет, не зря. Но настройку индексов по одному запросу делать нехорошо. Нужно комплексно.

Мне кажется надо смотреть кол-во запросов*ресурсы сервера, а не просто ресурсы сервера и делать выводы
Надо мониторить хотя бы недельку в рабочем режиме
А что затыки какие-то? 300 пользователей колбасят нипадецки?

Всякие галки не спеши ставить - замедлится проведение
Отчеты и обработки также нужно посмотреть ВСЕ, как и документы

всего пользователей немногим больше 100
колбасят нормально =)
активная выписка доков около 11 юзверей одновременно
+ прием заявок секрами и манагерами (еще юзверей 30)
+ заяки розницы (наши-же отдельные магазы)
бывает притормаживает.. а всем же надо чтобы работало как в монопольном режиме =)

Возьми профайлер, собери трассировку за рабочий день и натрави на неё Tuning Advisor. Посмотри, что оно тебе выдаст...
Но прежде чем применять - думай...

(17) Для ста пользователей тут даже думать нечего создавай
индекс СК  делай как в 12 написано.

про индекс ВК  не знаю.

(17) Надо уделить внимание массовым документам на предмет сокращения времени их проведения
И практиковать роботов, они лучше менеджеров

(19) посмотрю как завтрашний день пойдет.. с отбором движений
СК ВК - это я так сократил (столбцы ключа, включенные столбцы)
(20) робот в перспективе =)

(20,21) что за роботы ?

(22) ну чтобы клиенты через мыло или фтп могли свои заявки в базу закидывать.. или получать накладные за период и т.д.. я так это вижу =)

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

(22) Ну для заявок. Они точнее и меньше дергаются :)
У меня допроводилось по 2-3 заявки в секунду при ста пользователях на среднем сервере

+(25) не запрашивают остатки по всем товарам, не делают кучу лишних телодвижений...

(24) Для того роботы и существуют, чтобы правила не менялись.

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

(28) С роботом проще...

(29) так руками работать надо....
вот сейчас так лениво это делать...
уже душой встречаю первомай...

(28) Настройки, приоритеты и проч.
Доступ к изменению - ответственному лицу.

(27) вот тебе живой пример - =)
сегодня товар1 можно продавать штучно.. завтра - не, только кратно упаковке
сегодня товар2 можно резервировать, завтра - только продажа и никаких резервов

(32) все это решается через свойства

(32) изменения согласовываются заранее, робот меняется и в день Х логика начинает работать по-новому.

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

+(33) причем достаточно оперативно. у нас это называется "квант отгрузки" и "неоперативное резервирование"

(36) а как назвать, когда розница дерется за дефицитный товар? =) там робота в клочья порвут

(37) Матрицу товар-точка-квота или доступность можно организовать
Вообще проще если это делается централизованно, парой умных человек
На объекте тупо продают что дали по чем дали

(37) "кто первый встал, того и тапки".
Либо резервирование из резерва отдела. либо резервирование из резерва контрагента (такое - для сетевых клиентов реализовано).

хм.. сделал как в (12)

адвайзер все также трет о своем.. =)
отсутствует индекс - влияние 90.3265

88% кластеред индекс скан

(40) Дык сравни индексы-то..
Разный порядок полей иногда даёт принципиально разные результаты...

SP100, DATE_TIME_IDDOC, LINENO_, ACTNO
основное отличие, что адвайзер предлогает сделать индекс с добавочными полями

(42) Поэтому и советует... Чтобы лишний джойн не делать.

еще такой момент - студия русские символы принципиальноне показывает? =)
Рег.ОстатокТовараРасход as РасходТовара

(44) У меня студия с русских вполне себе дружит...
А вот у твоей оная дружба, видать, перешла в более тесные отношения....

(42) Есть такой термин - покрытие индекса. Посмотри его.

(45) смотрю текст запроса - там отображается все правильно,
а вот в плане выполнения - кракозябры =\

(46) угу, это уже читал
получается все-таки предпочтительнее пользоваться механизмом SQL

(48) Да, потому что средствами 1с невозможно создать индексы с включенными полями. А это бывает очень полезно, и может серьезно ускорить некоторые запросы, но - для больших таблиц несколько замедлится вставка и места под индексы будет тратиться больше. Это тоже надо учитывать.

если конкретно по RA99 - 1гб вес самой таблицы

(50) На такой ты ничего не заметишь:)

(51) имеешь ввиду выйгрыш от индекса или прибавку тормозов? =)