Всем привет.
Ситуация такая: имеется сервер Win 2003 на нём крутится SQL 2000 и сервер терминалов с 1С Предприятием 7.7.
Не так давно по причине того что надвигался крах винта, диск был склонирован акронисом на новый винт. Всё прошло нормально, всё стартануло без пробуксовок. Однако периодически у юзеров начали вылетать следующие ошибки : SQL State: HYT00 Native: 0 Message: [Microsoft][ODBC SQL Server Driver]Время ожидания истекло
и при проведении документа раз 10 надо нажать кнопку провести чтобы документ провёлся.  Куда капать камрады?  Находил в инете советы по трассировке кода и отлавливании "слабых мест", но дело в том что база переферийная и такие копии с таким же кодом крутятся ещё на 3 серверах и всё нормально. И так же до переноса на новый винт всё было нормально, сервер без перезагрузки проработал полгода - всё летало.
Прошу помощи.

2000 скуль при долгой работе одного сеанса 1с замедляется достаточно сильно. надо переходить на 2005 или ЕМНИП в 1с++ был костыль

(0) Сколько пользователей?
Как работают?
Что за ОСь сервера?
Что за Скуль?
Версию, битность... пиши есче, а то телепат через 3 часа, как на празднике :)

(1) Да и это не проблема. Проблема только в руках программиста.
И один кривой отчет или запрос в модуле проведения, могут положить всю БД :)

Книга знаний: Исправление ошибки 1С:Предприятие 7.7/8.0 - 100% загрузка процессора при ожидании блокировки

(3) нет, типовое восстановление последовательности по одному месяцу с перезапуском клюшек существенно быстрее, чем восстановление последовательности за весь период за 1 присест.

(2)Windows Server 2003 Enterprises SP2 (x86)
SQL Sever 2000 SP4 (x86).
8 юзеров, все через терминал в торговле склад.

(3) до переноса все обработки и отчёты работали как часы. Так что дело не в них.

Может статистику обновить для базы данных.

(8) в терминале актуально (4)

(6) 8 человек, и уже транзакция, сознавайся, какой отчет писал без команды (NOLOCK)?
Или в Каком документе при проведения по навтыкал "Черных" запросов от 1С?

(8) не можно, а нужно. плюс проверить базу на ошибки

Я в свое время столкнулся с дидлоками
у нас в 1с7 работало большое количество пользователей + УРБД обмены. можно было поймать deadlock и 20-30-40 минут база висит.

(8) 1С не любят антивирусники, вернее поставь в исключения, как 1С так и сам скуль.

Каков размер БД на SQL?

Как часто делаешь бекапы БД?
И делаешь ли их?

(10) обработка через которую торгуют пользоватили, но писал её не я. Там море запросов. Она с 2008 года робит.

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

(14) И шо, там нет в Select-ах "NOLOCK" ?

(16) там не прямые запросы.

+ (12)вот та тема
sql 2000 дидлоки с утра достали(( как обнаружить того кто блочит

(17) Размер БД? Тогда.

(13)Размер базы подозрительно большой для переферийной. Кстати только заметил. 10 Гигов. Центральная база 4,5 Гига.
Бекапы каждую ночь, но на другом сервере. В течении дня каждый час логи бекапятся.

Ночью полный бекап

(20) Вот эта прога смотрит деадлоки http://sqlblocks.narod.ru/

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

(20) А модель у БД какой Full или Simple?

(24) видишь, пишет "логи бекапятся" - значит ФУЛЛ

+(25) точнее это не значит, а должно значить))

Попробуй реиндексацию средствами 1С для начала.

(27) а разница? она все равно sqlную делает

Ну тогда, как делать шринк, и т.д....

ОК, постараюсь объяснить....
Сразу прошу прощения за не совсем профессиональные высказывания в процессе - я ж все-таки не супер-пупер спец в SQL  , просто где-то полгода назад столкнулся с подобной ситуацией, у одного клиента база 1С в SQL-серве выросла до 10(!) гигов. Вот тогда мне один чел и подсказал что делать.
Значит так, первое это регулярная переиндексация базы. Цель - уменьшение времени поиска по запросу.
Выглядит это дело так.( exec _1sp_DBReindex )

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

Код
backup log (name_base) with NO_LOG можно еще написать "with truncate_only" вместо NO_LOG

truncating-ом (усечением) называется процесс удаления из журнала завершенных транзакций Этот процесс НЕ влияет на физический размер файла журнала.
После truncating-а освободившиеся в журнале место может быть использовано снова либо возвращено оп.системе.
Затем идет изменение физического размера файла журнала (shrinking) Shinking НЕ удаляет из файла журнала завершенные транзакции.
Он лишь возвращает оп.системе то место из журнала, которое было в нем освобождено в результате truncating-а.

Код
Backup Log [DB] with truncate_only
dbcc SHRINKDATABASE (DB)
BACKUP DATABASE [DB] TO  DISK = N''C:\BACKUPS\db.bak'' WITH  INIT ,  NOUNLOAD ,  NAME = N''DB backup'', NOSKIP ,  STATS = 10,  NOFORMAT', @database_name = N'DB'

Вот для примера база сжимается, обрезается лог и потом полный бекап.

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

Индексация.

USE base_1c
EXEC _1sp_DBReindex


Проверка на ошибки...

Как производить проверку, переиндексацию базы на SQL Server
Проверку логической целостности нужно выполнять штатными средствами 1С:Предприятия (Тестирование и исправление ИБ). В случае, если такую проверку не удается выполнить, следует проверить физическую целостность БД средствами MS SQL. Для проверки целостности средствами MS SQL нужно выполнить следующую команду: DBCC CHECKDB ('<имя базы>',REPAIR_REBUILD) Перед выполнением этой команды нужно базу данных перевести в режим "single user": sp_dboption '<имя базы>','single user',true. В процессе работы DBCC CHECKDB могут быть обнаружены ошибки и часть может быть сразу же исправлена. Если ошибки остались, то по всей видимости их нельзя восстановить без потери некоторых данных. В этом случае нужно запустить DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS (перед запуском желательно сделать копию файлов базы данных). DBCC CHECKDB ('<имя базы>',REPAIR_ALLOW_DATA_LOSS) После выполнения DBCC CHECKDB нужно не забыть вернуться в нормальный режим (выйти из режима "single user"): sp_dboption '<имя базы>','single user',false Переиндексацию базы данных на MS SQL не нужно делать так часто, как в случае с DBF-версией 1С:Предприятия (например, при аварийном завершении работы пользователя). MS SQL автоматически поддерживает индексы в актуальном состоянии. Пересоздавать индексы имеет смысл в одном из следующих случаев:
1) Индекс физически поврежден. Это случается довольно редко и для восстановления нужно использовать вышеупомянутый DBCC CHECKDB.
2) Страницы индекса сильно фрагментированы и требуется их упорядочить.
3) Нужно изменить степень заполнения индексных страниц (fill factor).
4) Требуется изменить тип индекса (кластерный/некластерный). При использовании 1С это обычно неактуально.
Для пересоздания индексов следует воспользоваться командой: DBCC DBREINDEX ('<имя таблицы>') или запустить хранимую процедуру, которая переиндексирует все таблицы в базе данных: EXEC _1sp_DBReindex

(27) Средствами 1С оно на SQL вообще нечего не делает :)
(28) Увы, индексация от 1С не делается :)

Еще посмотри в каталогах типа Usr1 - нет мусора? Там должно быть только 2 файла.

только не вздумайте шринковать базу (данные, mdf файл) после реиндексации)) это бессмысленная операция.

(32) >>Там должно быть только 2 файла.

ага, щаз

(31) Как не делается? Попробуй выгрузить в файловый вариант и там реиндексировать. На 7.7 очень большое значение может играть мусор в каталогах Usr.

(32) мы говорим не о каталогах, а о размере SQLных файлов

(34) Не раз такое было, lock - и все.

(35) ты спутал с большим файлом конфигурационным.
если cfg файл большого размера то 7-ка может тупить и из-за этого тоже. Блин. вспоминаю 7.7, она же тупила по любому поводу))))

(35) мусор у вас в голове...

(39) Ну если вы там что-то еще храните - флаг Вам в руки.

(38) Ну, насчет "любого повода" - это ты зря....

(40) Лечитесь, мил человек...

(35) 40 Гб БД, уже не выгрузишь :)

+(35) на SQL БД начинает жизнь от 6-ти Гб, т.е. 6 - это первый год работы, после тенденция накопления объемов спадает :)

(43) :-)
он тебе щазз скажет, что таких баз не бывает..

(42) Каталоги, назначаемые для пользователя используются для хранения временных файлов. Если вы делаете отчет и потом Вас выкидывает, то в Usr остается мусор, который мешает работе с базой данных.

(45) И там у меня работает 50 человеков :)

(24)Full

(48) тогда не удивительно, что она так быстро растет

(46) а также - сохраняемых настроек отчетов, сохраненных значений и т.п.

(50) Это в принципе тоже мусор. Мы же чистим его в 8.2.
del /F /Q /S "%USERPROFILE%\Local Settings\Application Data\1C\1Cv82"
del /F /Q /S "%USERPROFILE%\Application Data\1C\1Cv82\"

(51) кто это мы?

(49) Центральная база 4,5 Гига, с неё и делаются бэки и на другом сервере. У этой кстати поглядел ночью в планах обслуживания стоит реорганизация индексов и обновление статистики.
Кстати другая переферийная база этой же центральной базы на третьем сервере весит 2,5 Гига, а на сервере где тупит 10 Гигов

ЧеловекДуши +++ благодарю за инфу, сегодня ночью буду пробовать.

(47) чот в аське сейчас не нашел сходу- чувак спрашивал, сможе ли 1с7.7 работать с гигантскими базами данных и очень большим количеством народа...
после тоснения гигансткие базы - это 6Г, а очень большое количество народа - "20, нет даже 25!"

(52) дятлы

(52) (56) Никогда не встречали ситуации, когда после изменения конфигурации приходится чистить кэш 1с?

(57) в восьмёрке приходилось. Но не таким варварским способом, как в (51)

Ещё господа подскажите пожалуйста. Для 1С модель восстановления Simple кто нибудь юзает?
И ещё заметил когда в настройках скуля задействуешь все ядра процессора производительность сильно падает.

(59) кто нибудь? ха... все

(59) я недавно перевел все свои базы на симпл. у меня каждый час делается архив базы и ежечасная копия живет 5 недель. и еженочная живет всегда.

убить все подсказки

(58) Ну на клиентских машинках должен быть типовой механизм.

(59) еменьши степень параллелизма

(59) начиная с 2008 SQL умеет сам сжимать архивы, вообще клевое дело. 27 гигов база жмется в 10 раз. и архивация идет очень быстро.

(59) Семрка не может использовать больше одного ядра в принципе.

(66) а причем тут 7.7
мы про sql говорим

(59) Все, даже на 8-ке :)

(56) деревянные

(65) Он на 7.7 сидит, какая 2008?

(66) что ?

(66) 8-ка тоже не далеко оторвалась :)

(71) 1С

(72) 100500+ Там главное чтобы проц мощный был.

что 1С ?

(54) Бекапы главное сделай, как БД, так и каталога с БД :)

Перевод базы в Simple увеличивает производительность?
Для перевода в Simple достаточно EM поменять режим?

(67) А при том. что он использует версию 1С 7.7, а она нормально работает только с MSSQL 2000.

(77) по производительности не скажу а по второму - да

(77) 1. спорное утверждение, достойное холиваров.
2. Да

(80) Не то, чтоб сильно спорное. Просто когда знаешь, как работают эти режимы - и спорить-то лень...

(77) Нет, увеличит место на HDD, т.е. у тебя БД будет почти равна центральной БД

Всем привет.
Сделал всё что обсуждали. Тестирование и исправление,
реиндексация. В итоге вообще полностью пересоздал переферийную базу. Сейчас она весит 3,2 Гб. Но в такая шняга по прежнему вылетает((  вот к вечеру вылетело. Я уж было обрадовался что всё ништяк. А нет(((.  Что ещё можно покрутить?
Сервер 2 ядра Core Duo, DDR2 6 Гб, винт сата на 1 TB поделён кеш 64 Мб.  Чего бы не жить то?.
В других магазинах нашей фирмы и послабже сервачки стоят но такой хрени нет. Народу конечно в них поменьше ходит, этот магазин самый крупный у нас в котором вылетает сия шняга.
Придётся наверное на ручные блокировки переходить. ((

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

(78) и кто тебе сказал что только на 2000?
у мене уже больше года на 2008 крутятся все базы.
И причем скорострельность выросла значительно.
А так же что на 2000 1С не может заставить SQL использоватеть сразу несколько процов, а вот на 2008 сколько дашь SQL-лю столько он и будет разом использовать.

(85) у тебя 7.7 ?

Да.
Причем чем круче сервак тем лучше летает.
Я было переводил знакомы с 2000 на 2008.
Так вот на одном и том же серваке проверяли производительность.
2000 уступает на одинх и тех же операция раз в 10.
Так что думай.
И не надо утверждать что 2000 это единственная СУБД.

О чем спор я так и непонял.
(0) А скажи мне по секрету - что делают эти 8 идиотов что сервак ложат?.. Просто интресно.
======================================
Я вот думаю у товарищей на 2012 поставить базу. Но че-то очкую слегка. Может кто уже работает на 2012 - напишите как полет. Интересуют базы 20+ Гиг с 40+ идиотами.

(88) создают док-ы реализация розница, через обработку. Которая позволяет продавать товар с разных складов автоматически создавая перемещения если товар списывается не со своего склада (например с другого отдела.
Эта обработка работает с 2007 года.  Работает во всех магазинах. А ошибка такая вылетает только у одного юзера как ни странно.

(89) Ну могу сказать что если проблем в коде нет и железо тянет нагрузку, то однозначно вы накосячили с настройками. Что и где угадать сложно. Как вариант перепроверить все еще раз.
Чудес небывает.