Это полный ппц, что только не делал не чего не помогает. Разве что голый не бегал перед серваком. База 31 Гиг. в жатом виде 1,2 Гб. Конфа УПП 14 релиз ( предпоследний который) Платформа последняя. Тестирование делал, переиндексацию делал, выгрузку загрузку делал. Тормозит на всех документах, проведение по партиям отключаешь один фиг. Даже записать документ не дает. Что можно еще попробывать? Позвать специалиста не предлагать ( мало того что у нас с ними напряг, этот вариант уже рассматривается).

Книга знаний: Быстрое создание и настройка правил обмена для зависимых объектов в Конвертации Данных v8

(0) Описание железа и прочего софта, установленного на серваке в студию

(0) попробывать можно внимательное разглядывание сиквела, хотя бы профайлером

а после чего стало тормазить? кто то потряс бубном и началось?

SQL: Xeon 2,66 2 шт , 4 гиги памяти, 135 гигов ХДД ( 75*4 шт), SQL2000, MS Server2003
1C: Xeon 2,8 2 2 шт, 3 гига памяти,135 гигов ХДД (75*4 шт), SQL2000, MS Server2003

связаны гигабиткой.

(4) После расчета себестоимости за год

Нас однажды спас полный пересчет итогов по регистрам (в конфигураторе).

(7) ПРобывал

(5)1C: ... SQL2000
а нафига там сиквел?

(9) Что значит нафига?

(10) Зачем на терминальном сервере установлен SQL?

(11) С чего ты взял что он терминальный?

У нас нет сервера терминалов. На скуле база, на сервере 1с тоже база в которой указана БД (SQL).

У узверев указан сервер 1С и база.

(0) Точку Актуальности итогов меняли?

(15) Нет

(12) Тогда поясни, что значит в (5) "SQL:.."  и "1C:..."?

Установлено по:30.04.2008

(18)ТА должна быть текущая дата и время

(17) 2 компутера на одном скуль на другом сервер 1С

(0) База на сиквел конечно  в Simple ?

(21) Конечно

(21) а надо?

(20) И зачем на обоих серверах установлен скуль?

(0) как вариант: синхронизируй везде время (там с этим есть небольшие заморочки)

(24) ппц полный, 25 раз говорю на одном Скуль на другом сервер 1С

(26) Пипец полный. Ты посмотри, что ты в (5) написал.

(23) угу
(26) успокойся, ты сам указал SQL2000 два раза

(27) Ты считаешь, что база тормозит из-за того что я в (5) написал? Можешь по проблеме подсказать?

(28) Да блин почему так всегда стебанулся немножко ну скопировал все 2 слова,зато философии, суть то вопроса не в этом.

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

(0) переиндексацию делал в ms sql или из 1С?

(31) Не у меня тоже все оригинальное, просто их не кто целый год не делал и я с января 2007 по январь 2008 года создал 12 документов.

Может у тя винт какой-нить вытармаживать начал, и сыпется потихоньку

SQL: обнови статистику, перестрой индексы, проверь базу tempdb, свободное место на дисках
1с: тестирование базы с удалением объектов, удаление объектов помеченных на удаление, укороти журнал регистрации

(33) Вернее 36 документов

Спасибо всем буду пробывать.

(29) Нет, не считаю. Просто, пытаюсь выяснить что же у тебя на каком из серваков крутится. Согласись, немаловажная информация?

(38)

SQL: Xeon 2,66 2 шт , 4 гиги памяти, 135 гигов ХДД ( 75*4 шт), SQL2000, MS Server2003
1C: Xeon 2,8 2 2 шт, 3 гига памяти,135 гигов ХДД (75*4 шт), MS Server2003

А замерить через отладку время выполнения?
*подсказка - возможно после накатки обновления включились планы обмена, если не нужны - отключай нафик, жутко тормозят работу (+30% времени)

Zlodey (13:41:52 12/05/2008)
если при отключенном списывание партий то на

ТаблицаДвижений = ПолныеПрава.ОпределитьНаличиеДвиженияПоРегистру();


Zlodey (13:42:07 12/05/2008)
54 % времени


Zlodey (13:43:50 12/05/2008)
Если с списанием по партиям то

80% на УпрЗапасамиПартионныйУчет.ДвижениеПартийТОваров() (30 секунд)

Что самое интересное в файловом варианте запустил проведение документов с 1 01 2008 скорость проведения в среднем 1,5 секунды

(42) я же тебе сказал "Время синхронизируй" там целых 2 засады есть, обьяснять долго..

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

у меня 19.36, на скуле 19.36, на 1С 19.36 тормоза продолжаются ( время было одинаковое).

(44)регламентные работы настроил на SQL  как рекомендуют в 1С?

(44) перезапуск сервера 1С делал ?

1. Обновление статистик
MS SQL Server строит план запроса на основании статистической информации о распределении значений в индексах и таблицах. Статистическая информация собирается на основании части (образца) данных и автоматически обновляется при изменении этих данных. Иногда этого оказывается недостаточно для того, что MS SQL Server стабильно строил наиболее оптимальный план выполнения всех запросов.



В этом случае возможно проявление проблем с производительностью запросов. При этом в планах запросов наблюдаются характерные признаки неоптимальной работы (неоптимальные операции). См. более подробную информацию о работе запросов и планах запросов.
Для того, чтобы гарантировать максимально правильную работу оптимизатора MS SQL Server рекомендуется регулярно обновлять статистики базы данных MS SQL.
Для обновления статистик по всем таблицам базы данных необходимо выполнить следующий SQL запрос:



exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'



Обновление статистик не приводит к блокировке таблиц, и не будет мешать работе других пользователей. Статистика может обновляться настолько часто, насколько это необходимо. Следует учитывать, что нагрузка на сервер СУБД во время обновления статистик возрастет, что может негативно сказаться на общей производительности системы.
Оптимальная частота обновления статистик зависит от величины и характера нагрузки на систему и определяется экспериментальным путем. Рекомендуется обновлять статистики не реже одного раза в день.
Приведенный выше запрос обновляет статистики для всех таблиц базы данных. В реально работающей системе разные таблицы требуют различной частоты обновления статистик. Путем анализа планов запроса можно установить, какие таблицы больше других нуждаются в частом обновлении статистик, и настроить две (или более) различных регламентных процедуры: для часто обновляемых таблиц и для всех остальных таблиц. Такой подход позволит существенно снизить время обновления статистик и влияние процесса обновления статистики на работу системы в целом.

2. Очистка процедурного КЭШа
Оптимизатор MS SQL Server кэширует планы запросов для их повторного выполнения. Это делается для того, чтобы экономить время, затрачиваемое на компиляцию запроса в том случае, если такой же запрос уже выполнялся и его план известен.
Возможна ситуация, при которой MS SQL Server, ориентируясь на устаревшую статистическую информацию, построит неоптимальный план запроса. Этот план будет сохранен в процедурном КЭШе и использован при повторном вызове такого же запроса. Если Вы обновили статистику, но не очистили процедурный кэш, то SQL Server может выбрать старый (неоптимальный) план запроса из КЭШа вместо того, чтобы построить новый (более оптимальный) план.
Таким образом, рекомендуется всегда после обновления статистик очищать содержимое процедурного КЭШа.
Для очистки процедурного КЭШа MS SQL Server необходимо выполнить следующий SQL запрос:



DBCC FREEPROCCACHE



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

3. Дефрагментация индексов
При интенсивной работе с таблицами базы данных возникает эффект фрагментации индексов, который может привести к снижению эффективности работы запросов.
Рекомендуется регулярное выполнение дефрагментации индексов. Для дефрагментации всех индексов всех таблиц базы данных необходимо использовать следующий SQL запрос (предварительно подставив имя базы):



sp_msforeachtable N'DBCC INDEXDEFRAG (<имя базы данных>, ''?'')'



Дефрагментация индексов не блокирует таблицы, и не будет мешать работе других пользователей, однако создает дополнительную нагрузку на SQL Server. Оптимальная частота выполнения данной регламентной процедуры должна подбираться в соответствии с нагрузкой на систему и эффектом, получаемым от дефрагментации. Рекомендуется выполнять дефрагментацию индексов не реже одного раза в день.
Возможно выполнение дефрагментации для одной или нескольких таблиц, а не для всех таблиц базы данных.
Подробная информация о дефрагментации индексов

4. Реиндексация таблиц базы данных
Реиндексация таблиц включает полное перестроение индексов таблиц базы данных, что приводит к существенной оптимизации их работы. Рекомендуется выполнять регулярную переиндексацию таблиц базы данных. Для реиндексации всех таблиц базы данных необходимо выполнить следующий SQL запрос:



sp_msforeachtable N'DBCC DBREINDEX (''?'')'



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

(47) а ты сам это пробовал?

(48) а что , есть сомнения?

Все пререпробывал, не помогло.

(49) АГА!

(50)Даже записать документ не дает

А в чем это выражается ? Гоаорит че нить ?

(51) напиши пожалста, я обычно сам кое чем из (47) пользуюсь.

(53) про что написать?

(54) почему по твоему действия. описанные  в (47) не окажут эффекта .

(54) Про то, что для тебя выглядит сомнительно в (47).

>1. Обновление статистик
сиквел обновляет автоматом. поэтому этот пункт - бред.

(57) это если выставлено в настройках..

(58) по умолчанию выставлено

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

попробуй перейти на 2005 скуль

При тестировании средствами 1С вылазит вот такая херня

http://foto.mail.ru/mail/skovan/3/s-63.jpg

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

ну батенька - да у вас переполнение лог файла временной базы tempdb (служебная база скля).
Варианты решения:
1. перезагрузить SQL (tempdb очистится автоматически)-  рекомендуется
2. дать возможность неограниченного роста для лог файла вышеупомянутой базы (только если слишко сильно растет в течение дня)

(64) Перезагружал
Чистил темпдб(обрезал) хотя это полная глупость как вы правильно сказали он сам должен обрезаться. Фаул лога был 17 мегов, после обрезки 2 мега

(65) тогда п.2 из (64)

(62) лог транзакций большой?

ПРоблема из (62) решилась увеличением размера базы tempdb