v7: Нужен совет по связке 7.7 + mssql 2005 #668798

Понимаю, что тема изъезжена, но после дня перелопачивания информации остались вопросы. Сервер: 2x Xeon E5335 2GHz, 8GB DDR2 (4+4), 4x SAS 10k RAID10. ОС Windows Server 2003 SP2 x86. MSSQL 2005 SP4 x86 (включен AWE, priority boost), серверу отдано 3ГБ ОЗУ, которые он успешно забирает. Платформа 7.70.027 + самописная конфигурация - в основном оперативный учет, база 15ГБ, около 20-30 одновременных пользователей. Все пользователи сидят на терминальных сессиях на этом же сервере. На MSSQL 2005 перешли несколько дней тому, поскольку перевожу бух базы 8.2 на SQL + планируем перейти на УТ11 SQL. Пошли жалобы на несистематические тормоза интерфейса (открыть док из журнала, из отчета, поклацать меню), при котором зависает только окошко 1С. Сам смог словить тормоза только пару раз при открытии журнала подчиненных документов. При этом 1С крепко повисает на пару минут и явно подтормаживает пока не закрыть журнал. Проблему с выбором подчиненных документов на sql 2005 изучил, но мучает вопрос: почему открытие журнала подчиненных вешает 1С только в редких случаях? Можно ли это победить малой кровью? Находил инфу, что 7.7 может работать на именованом инстансе, что планирую сделать, если не разберусь, поскольку от 7.7 планирую отказываться.

Победить можно, секретным релизом.

это сейчас была шутка? Я понял в чем проблема с подчиненными, что можно перехватывать и модифицировать запрос или патчить bkend.dll в куче мест. Переписывать все вхождения ВыдбартьПодчиненныеДокументы на использование с указанным периодом или на прямые запросы. Не понял почему сейчас все утро подчиненные открываются нормально, а ближе ко второй половины дня у части юзеров начинаются проблемы.

спасибо, что ткнули носом! Странно, что за полтора дня изучения проблемы не наткнулся на это решение... прошу прощения. По незнанию подумал, что подшучиваете надо мной.

хы! полтора дня - не срок... :-))) зы. приходил лет несколько назад кадр на собеседование... Достижения: - пользователи жаловались на медленную работу сиквельной базы. -- как решили? - установил 2005 и перевел базу на него. -- проблем не возникло? - возникли! -- с чем? - зависание журнала подчиненных. - решили? -- решил! - как? -- перевел на 2000-й... © йа плякалЪ... ""

согласен, но два дня жалоб от пользователей и руководства стимулируют найти решение побыстрее. Я тоже задумался вернуть 2000-й в виде именованого инстанса чисто для 7.7. Правда во-первых не считаю это решением проблемы, во-вторых у меня философия не "как-нибудь решать проблемы", а "решать проблемы оптимально". Долго спорили с начальством, когда только пришел сюда работать, что я часто лезу переписывать то, что не просят. Закончилось, когда показал конкретные косяки предыдущей айти команды и на что они повлияли.

стукач :)

тогда откажитесь от PK на rowid если удалите его, то с помощью + vk_hook подмените запросы.

сделай реальный журнал подчиненных + в конструкции выбратьподчиненные задавай всегда дату, не оставляй пустой

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

+ для ms sql2005 мне ,как полумера, помог отказ от  авто обновления статистики с заменой на ежечасный job. количество каллизий уменьшилось с 5 раз в день до 2 в неделю.

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

Спроси завтра, скину код, как получить подчиненные документы. И как подменять нужные запросы в общем журнале :) Но можешь не терять времени и поискать самому, гугл это знает :)

На мисте уже терли сей вопрос, попробуй поискать

+ Вот тут нужный тебе код.

Спасибо. Выше посоветовали секретный релиз. Там же вроде как поправлена проблема с журналом подчиненных.

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

Да, патчить тоже придется :)

Не замечал каких-то тормозов если были нормальные запросы Было около 100 юзверей на 2005 SQL и база побольше

На х.. вообще пользовать журнал подчиненных документов?

Ээээ Зачем вообще заниматься программированием? :)

Держи мою поделку, доработку... выбора подчиненных документов.        Сообщить("Запрос не выполнен:

вот и я о том же... только у мну еще вариант с Классом "ПрямойЗапрос" прикручен

+А вот так я заменяю запросы...

А мне класс не нравится :) Люблю сам писать :)

+ А вот как делаю инициализацию перехвата, один раз при старте 1С        Сообщить("Ошибка инициализации ""vk_Hook1C"": Перехватывает SQL-запросы 1С:Предприятие, и позволяет их изменять на лету.

+ И понадобится для этого безобразия, ВК "vk_Hook1C.dll", от Ромикса Она требует Админские права при первом запуске или её надо регать, через RegSvr32.exe Addin.vk_Hook1C=0a729a72-531f-4a96-a3ec-b3fabdbfaec8 Качать её тут ...Спасибо ромиксу...

Всё, страницу в закладки))

Это чо за чрезжопица?

попробуй метод РегистрироватьКомпонентыВ_HKCU / RegisterAddinsInHKCU встроенного класса Система

У меня так и сделано, просто автору нестал расписывать сей код :)

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

Мне нравится, доработка примерно сего чуда в

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

Проще сделать так.... +Держи обработку по регистрации ВК, там и сами ВК... Но с ней придется разобраться самому :)

Ну мне было важно: - отобрать не только проведенные документы (не проведенные я дописал, мало ли) - Отобрать только какой-то определенный вид документов, или парочку видов. Все остальное задел на будущее, мало ли :)

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

Может быть, но уж как написал :)

по поводу журнала подчиненных: у нас тут вообще не дружат с журналом регистрации. Все разборки кто чего натворил руководство разбирает подчиненными документами - уж очень много доков между собой связаны подчинением. Узнать распроводился ли документ умеют только через подчиненные - там сторно светится. я еще не "дорос" до использования 1С++. Прекрасно понимаю, что прямые запросы - это круто и быстро. С языком SQL более-менее знаком, но с особенностями T-SQL и структурой хранения данных 1С в базе не особо. Это все чертовски интересно, когда есть время этим заниматься. Но реалии таковы, что нужно сначала навести порядок как в конфигурациях, так и в остальной инфрастуктуре (отвечаю за все ИТ, в подчинении два оболтуса: админ и вебпрог, денег на ИТ, как всегда не особо), а потом уже можно изощряться с оптимизацией.

>>> я еще не "дорос" до использования 1С++ Придется расти, коль вы решили сесть на SQL 2005 :) Без этого никак...

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

+ Нет времени и желания, тогда вам лучше вернуться на SQL 2000

+>>> MSSQL 2005 SP4 x86 Лучше всего х64, а то на х32 только зря время терять :)

хорошо сказано, возьму на вооружение! когда упрутся в несносные тормоза - поставят приоритетную задачу, а сейчас, как бы это не звучало, есть задачи поважнее. в очередной раз согласен с Вами. нет только времени. Поэтому и "еще не дорос", а не "не использую и не буду". я понимаю это, но полный реинстал сервера сейчас очень проблематичен. В планах есть, возможно даже, если заведется, на Win2008R2 + SQL 2008R2. Свободными вечерами поднимаю платформу для тестирования.

А на SQL 2008, думаешь будет лучше :DDDD

Если на сервере больше 4 гиг ОЗУ тогда лучше X64 Windows и SQL.

нет, не думаю. Но если уже работают одинаково, то я за SQL посвежее. В прекрасном будущем мечтаю убрать семерку с организации вообще и первые шаги к этому уже сделаны. В моем случае стоит x86 ибо оперативки сначала было 4ГБ, а еще 4 добавили недавно.

Чем лучше 32-ух, если там 8Гб? Все ровно Скуль не увидит больше 4-рех, если железо не поддерживает расширение памяти :)

Просветись, неведующий.

+ Все что выше SQL 2000 и младше XP SP3 считается шаманством и колдовством. И по определению самой 1С работать не должно с 1С 7.7 :)

Я не говорил, что лучше. Имелось в виду, что х86 уже давно стоял на 4ГБ. Недавно добавили еще 4 и пока переустановить сервер задача не первой важности, особенно с учетом того, что память полностью утилизируем. Что ж Вы так, сразу "неведующий"? Я знал на что иду. Если  SQL 2005 и 2008 шаманство и количество плясок с бубном для обоих одинаков, то почему бы не использовать более свежий продукт?

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

ну, если вспоминать "православные определения"...

мизда - никкое не исключение. просто если ты _пытался_ что-то  сделать сам, то тут с бОльшей вероятностью помогут... а если вопрос интересный - помогут обязательно. помогать с вопросами, на которые есть ответы в СП и ЖКК - остомиздело..

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