День добрый!
Стали что-то бухи жаловаться на медленную работу 1С. Опишу структуру работы:
есть два офиса, в одном сидят все бухи, а во втором терминальный сервер и сервер, где крутится SQL. Между ними канал на 10 Мбит, но нагрузка на него не критичная. Терминальный сервер периодически нагружается до 100%, но штатно 20-40%. На нем стоит Xeon 4 ядра и 4 гига оперативки. про сервер, где крутится SQL посмотреть нет возможности (разные офисы курируют разные айтишники, прямого доступа у нас туда нет).

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

Попробовал ТИС на выгружнной и получил тьму ошибок вроде:
Файл DT12027.dbf. Запись 459340. Поле SP12025. Неверное содержимое текстового поля - "                                                                                                  "
Файл DH12070.dbf. Запись 12319. Поле SP40382. Неверное содержимое текстового поля - "        "
Файл 1SBLOB.dbf. Запись 7600. Поле BLOCK. Неверное содержимое текстового поля - "1e       Денисов Дмитрий Александрович                                         "

Первая таблица - это "Документ (Мн.ч.) ОперацияПоРасчСчету" и строка Значение; вторая - "Документ ПлатежноеПоручение" и строка КППполучателя. Ну с третьими все ясно - случайно нажатые комбинации клавиш.

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

1. реиндексация и обновление статистики на сиквеле
2. сиквел очень нехорошо работает с бухподсистемой

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

кстати, на терминальнике может помочь приблуда от ромикса..

а поиск узких мест - скрипт от vde69, либо старая древняя статья "семь главных счетчиков производительности SQL-сервера"(или типа того, точное название не помню) - лежит на sql.ru

(1) нормально он работает с бухподсистемой...

(5) хуже, чем с оперативным, гораздо...

infostart.ru/public/16681/

а вообщето для 20 терминальных сесий 4 гига оперативки - это мало, ОЧЕНЬ мало!!! посмотри может память уходит в своп

(8) Для 7.7 нормально
Если конечно не грузить в сессиях Експлорер, офис, мониторчики от принтера и тп

Я смотрел на dbf-ной базе: 1-пользователь в обычном режиме отъедает около 50Мб оперативки терминального сервера, но при формировании тяжелых отчетов (весь отчет тоже сидит в ОП)доходило до 200 (отчет был ~ на 70 тыс. строк)

(8) Для 7.7 - это мегамного!

(0) В (1) тебе уже все сказали: реиндексация каждую ночь и обновление статистики каждый час.

(1) "сиквел очень нехорошо работает с бухподсистемой" - Вы не любите собак? (с)

(0) Да, неверное содержимое текстового поля никак не влияет на скорость выполнения отчета.

(12) может, я не сильно умею их готовить, но тем не менее - при использовании штатных бухзапросов - медленнее. Штатная ОСВ за большой период (года два-три) клала сервер напрочь.
а работатать с бухией напрямую - мне не понравилось. регистры логичнее, роднее и ближе :-)

(8) Памяти отъедают максимум гига 2-3, даже в период большой загрузки.
(12) Что ж будем разговаривать с админами, курирующими SQL сервер. Спасибо за советы :)

Что ж, админы курирующие SQL сервер на вопрос какогда было произведена последняя реиндексация и как происходит обновление статистики, сказали: "Мы не знаем, подключись посмотри". А вот теперь не пинайте, пожалуйста, но подключиться-то я подключился через Enterprise Manager, стоящий на другом компе в другом домене, а вот как узнать когда эти процедуры были проделаны с этой базой, да и как их сделать не смог слету разобраться. Если есть возможность, то ткните носом в статью или подскажите примерно. Буду премного благодарен!

+(16) как сделать нашел, а вот как посмотреть ,когда в последний раз было - нет ...

+(17) в логах только запуск и бэкапы постоянные

(18) смотри в job-ах, скорее всего вообще не настроено

(0) Переделай канал между серверами на 1гигобит

(20) кошерный вариант, учитывая, что нагрузка на канал далека от 100% :) Боюсь себе представить счет от провайдера ...

(19) Да, как вы и предполагали в джобах только бэкапы (и то слава богу!). Будем настраивать. Еще раз спасибо!

(0) Отчеты если гоняют стандартные типа обороток и проч. поставь комплект на прямых запросах. у меня уже 2 последние конторы в бух на одних и тех же граблях. после вопросов не возникает. а то как развернут карточку 41 счета за год. вот надо им и все. так 30-40 минут лопатит. а тут 1-5 минуты.

а то и быстрее.

(21) Бред какой-то. Кто же sql сервер и терминал сервер держат в разных сетках да еще внешних речь именно об 1с sql.
Обычно Все в одной сети локальной ( даже для твоих 30 пользователей можно совмещать оба сервера в один но это требует более тщательной настройки.) и терминал и sql а извне лезут именно на терминал.

"Между ними канал на 10 Мбит" можно прочитать двояко
1. между офисами канал 10 мб
2. между серверами канал 10 мб.
когда читал 0 то прочел как вариант 2
но если действует 1 все равно должно быть верно и  20
т.е между серверами должен быть 1 гбит

(24) Терминал и SQl находятся в одной сети конечно же. Так что это все нормально.
(22) Я думал, чтобы перевести на прямые, но есть достаточно много самописных отчетов, так придется многое перелопачивать, а учитывая, что очень хочется перейти на 8-ку (мне и бухам/кадрам, но не начальству), то смысл в этом будет чуть. Проверим, как будет работать после запуска периодической переиндексации и обновления статистики.

(26) Бухзапросы оборотные будут работать также медленно

(0) То есть файлы базы 1сной лежат у тебя на терминальном сервере? А до sqlя 10 мегабит? Проведи эксперимент все на сервер SQL. И посмотри скорость формирования отчетов. А то чует мое сердце что эти 10 мегабит тебе и дают пол часа формирования отчетов...
SQL какой версии? Какие сервис паки?
Длина содержания операции какая? Количество субконто на счетах 3? или вы добавили еще 5?
Прямые запросы не помогут. Хотя, зависит от отчетов... Но чтобы получить остатки на начало месяца голову себе поломаешь.

(28) Я уже в (26) писал, что терминал и SQl  в одной сети и там, скорее всего, честный гбит. 10 Мбит от офиса с бухами до терминала. SQL - 2000. Субконто - 3.

(29) А что за отчеты? Типовые или самописные?
Сервис пак на SQLе какой? длину содержания операции не увеличивали? Размер базы какой?

(16) _1sp_DBReindex - реиндексация
sp_updatestats - обновление статистики.
Все - без параметров.
Имей в виду, что при реиндексации ощутимо вырастает лог. Это нормально, резать его не надо.
Реиндексация обновляет статистику сама, сразу после нее обновлять статисику не надо.
Сделай копию базы, сделай на копии реиндексацию и сравни скорость тяжелых отчетов.

(31) Реиндексацию можно делать и выборочную. Скрипт валяется с незапамятных времен.
а вот насчет "лог резать не надо" - просвети?

(30) Отчет самописный один, типа оборотки по определенным счетам. Писалось все до меня. SP3, хз, 12Гиг+.
(31) Спасибо, но планирую это в джобы поставить все-таки. Если удастся админов отвечающих за скуль убедить ...

(32) "Реиндексацию можно делать и выборочную" - можно.
Но телепатией я не владею, и какие именно таблицы автору нужно переиндексировать, я не знаю.
"а вот насчет "лог резать не надо" - просвети?" - каждую ночь будет идти переиндексация, и каждую ночь лог снова будет расти, а это время и задержки на рост лога, а вы снова и снова будете его шринковать? Лог должен быть такой величины, чтобы не требовался постоянно его рост. Конечно, не забываем про бекап логов (например, через каждые 15 минут).

(34) а и не нужно знать, "какие именно таблицы" - достаточно их переиндексировать последовательно.
Да и переиндексация каждую ночь - мягко говоря, излишество.
хотя все зависит от нагрузки на базу. Если я буду индексировать все таблицы разом - работа замедлится очень надолго, а в режиме 24*7 это критично.

(35) "хотя все зависит от нагрузки на базу" -золотые слова.
"в режиме 24*7 это критично" - у автора бухгалтерия.
Вот у меня в самом деле 24*7, поэтому переиндексацию я делаю раз в неделю, а обновление статистики - выборочно по нагруженным таблицам каждый час.

(36) некоторые и на бухии умудряются продажи вести...

(37) Ну, у нас продажи и деятельность управленческие ведутся на AS 400, просто выгружается в бухию, но и в ней работа кипит, но, слава Богу, не 24/7.

(34) Если реиндексацию запускать планово после бэкапа, сколько она может проходить примерно на базе объема 12гиг+?

(38) на полтиннике - идет 4,5 часа полная.
а вообще, зависит от сервера - железа, настроек и т.п.

(38) база 9 гиг полная реиндексация - 7 минут.
Сервер хороший, с SSD дисками.

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

(38) достаточно древний ноут (Intel Core 2 Duo T7300, 2Гб RAM) с SSD KINGSTON SNVP325 под Вин7+локальный скуль 2000 перелопатил 18+ Гиг менее чем за 40 минут

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

Фигня какая-то. С админом договорили, что он ночью после бэкапа в Maintance plan запускает разого реиндексацию, сейчас смотрю в SQL Server Logs и там кроме бэкапов ничего нет. Как я понимаю, там должен быть отмечен запуск реиндексации и его окнчание? Или я не прав?

(44) Не там смотришь.
Один фиг не поможет...

Выгрузка базы и загрузка в чистую базу SQL. предлогали?

тут явно либо касяк в файле DD либо кто то хорошо напрямую полазил в SQL

(0) Проблему решить очень просто. Достаточно сделать:
1. Выяснить причину тормозов.
2. Избавится от этой причины.

:)

А вот выяснить причину - это целая наука!
Выясни, что у тебя все таки тормозит: терминал или SQL.

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

(47) Канечно, так оно и есть, ага

(47) в днк у тебя "касяк"... или кто-то у тебя в мозгах полазил, напрямую через задний проход...

(44) скрипт от vde запускали?

(51) откуда тогда это?
Файл DT12027.dbf. Запись 459340. Поле SP12025. Неверное содержимое текстового поля - "                                                                                                  "
Файл DH12070.dbf. Запись 12319. Поле SP40382. Неверное содержимое текстового поля - "        "
Файл 1SBLOB.dbf. Запись 7600. Поле BLOCK. Неверное содержимое текстового поля - "1e

(52) адресовано (50)

Ну и в целом: 1С-ские базы на SQL работают медленнее, чем на DBF.

(52) Само вырасло

(52) это легко обьяснимо :) просто кто-то вручную в SQL лазил...

(55) Само?интерестно с этого момента поподробнее.как это могло случится?или все таки прямой доступ к SQL

++(56) посмотри на пост (50) чел нефига незнает а пытается сразу оскорблят у самого в голове мухи е...ся

Сейчас разворачиваю бэкап на бесплатном SQL 2005 локально. Посмотрим, как быстро будет работать.
(51) Пока нет.

(52) и кстати из за этих ошибок вполне могут тупить отчеты

(60) Да ни вопрос: неверное содержимое поля КППполучателя тормозит ОСВ

(60) из-за этих ошибок только ты тупить можешь...
(59) это надо было сделать в первую очередь. получил бы море информации.

(61)кто тебе сказал про КПП? )))
автор сказал что онибок масса

(61) несомненно. почти все ОСВ строятся именно по КПППолучателя (кроме тех, которые строятся по КПП отправителя).

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

(63) Масса ошибок, которые я привел. Пол сотни первого типа, куча второго типа, и меньше всего третьего.

(66) залей куда нить файл DDS.

(63) А что по твоему DH12070 SP40382?

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

(67) Эти ошибки скорее всего взялись из-за экспорта из AS 400. Обработку самого экспорта еще не копал, но возможно она иногда некорректно переносит данные, ее я уже потом покапаю.

(69) Я в первом посте описал, какие это документы и какие реквизиты -_-

(71) оу не прочитал извини

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

и еще на сервак только по RDP подключаетесь или в офисе еще по сети работают?

(69) Если у тебя нет DDS от бухии, то видимо ты никогда её в глаза не видел

(75) для особо одаренных DDS может менятся если ты не знал

и то что у тебя один документ у меня может быть совершенно другим

пипец какой-то... чем тупее дятел, тем агрессивнее....

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

если у тебя буха одна йз первых версий а я поставил ее сразу(не обнавлял) последнию сравни файлы DDS будешь удевлен

Mikeware ты уже все сказал и все это видели я тебя игнорю

+++(79) я тоже так считаю

(80) Конечно в каждом релизе бухии платежное поручение в разных таблицах

(83) еще раз повоторяю я не прочитал что это за таблицы

поэтому просил файл

(84) Так ты с начала читай, что люди пишут в т.ч. и ТС, может и не постил бы фуйню

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

(75) кстати там вроде не буха а ТИС

(88) -_- там буха. То что вы прочитали ТИС, это было ТИИ, просто опечатался.

(88) Чего б тогда бухи жаловались :).

Попробовал ТИС на выгружнной и получил тьму ошибок вроде:

тогда уж комплексная наверное

(88) читай (86)

(88) в ТиС есть документ "ОперацияПоРасчСчету"?

(94) почитай вопрос внимательнее
в частности Попробовал ТИС на выгружнной и получил тьму ошибок вроде:

ТИС это торговля и склад?или что то другое скрывается за абривиатурой

почему вы решили что у него бухгалтерия а не комплексная

Мдя, вот упорный долбодятел.
(95) читай (38) и (89)

(95) млять. нужно не только читать написанное, но и думать над ним... хотя тебе слово "думать" определенно незнакомо...

(99) после того как ты сказал что в SQL не лазили вообще бы молчал

Drac0 правь ошибки

(100) В SQL не лазили с 99% вероятностью. Возможную причину ошибок я уже написал.

(44) Попробуйте выполнить вот это:
SELECT OBJECT_NAME (stat.object_id) [table], [name] [statistics name], STATS_DATE(stat.object_id, stat.stats_id) [update time] FROM sys.stats as stat
WHERE stat.object_id IN (SELECT obj.object_id FROM sys.objects obj WHERE type = 'U')
ORDER BY [update time] ASC

Увидите когда обновлялась статистика.

(103) достаточно посмотреть журнал заданий

блджад! Забыл, что SQL 2005 Express ограничение до 4 гигов. Где-то у нас должны быть лицензия, буду искать ...

(104) это будет особенно актуально, если админ забыл дописать в задание обновление статистики

(106) читай (44)

(105) вместо поисков - запустил бы сбор статистики...

(0)ошибки ниочем, даже голову греть не нужно. А вот самое забавное, это делать ТиИ базы, выгруженной из SQL в DBF.

(44) В логи реиндексация не пишется.
Но если создан JOB, можно посмотреть его History (правой кнопкой мышки по джобу)

(108) Я бы рад. Да тут вот закавыка Query Analyzer не может подключиться к серву, который находится в другом домене. А как иначе можно выполнить скрипт на базе как-то не знаю ...

(110) нету джоба. Если запускали реиндексацию разово, он должен был остаться?

(112) Разово как именно?

(111) попробуй через 1cQA :-)

(113) Админ хотел через Meintenence Planner

(113) хранимкой. или скриптом. или из ТиИ...

(113) Meintenence Plan как раз генерит джоб, который и выполняется.
(111) Если IP SQL сервера пингуется, а он должен пинговаться, можешь подключиться по IP.

+(117) посмотри в конфигураторе параметы подключения к SQL серверу и смело используй то, что там написано.

(117) Мде, совсем туго сегодня с головой. Не заметил, что сервер можно вручную ввести. Это бяда ...

(117) А скрипт от vde не сильно будет нагружать сервер? Работать не станет слишком некомфортно?

(120) нет, не будет.

(105) Локально поднимай Developer Edition, он не имеет ограничений на размер базы.

А точно проблема не в терминале?

Сама структура хранения данных бух-компонентой (главным образом  способа хранения промежуточных итогов) , не оптимальна с точки зрения скуля , бух компонента дружит со скулем значительно хуже чем оперативный учет .
Торговля на бухкомпоненте это нормально , до определенных объемов данных , и если не требуется особо высокая детализация аналитики , масштабируемость такой системы будет не высокой , опять же из за , не очень хорошей работы с SQL

(123) Точно, подключился не через терминал, отчет тормозит так же.

"10 Мбит" - это канал между пользователями и терминалом? Или между терминалом и SQL-серваком?

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

(126) Уже писал, что между пользователями и терминалом.

(0) Неверное содержимого текстого поля прямого влияние на быстродействие не оказывает , но базу проверить не помешает (и переиндексировать), видно что давно не обслуживалась
Посмотри "Управление бухгалтерскими итогами" , не стоит ли там какой нибудь 3-й квартал 2015 года , на некоторых бухзапросах перенесенный вперед период может вгонять базу в ступор . Хотя в общем не похоже , локально то все шустро.
Установи 1С прямо SQL-сервер , и проверь скорость сразу отсечешь вероятные причины по сети и терминалу
Между терминальныйм серваком и скульным , для клюшек настоятельно рекомендуется имет гигабитную сетку

(127) Значит так отчет написан.
На файловой версии будет всяко быстрее.

+130 Сколько строк кода в отчете?

(127) Вы уверены, что реиндексировали именно Вашу базу?
Вы это делали сами? Каким образом?

(130) Для бухкомпоненты да , все отчеты использующие бухитоги , работают значительно быстрей в файловом варианте

(127) Значит, самописный написан не очень качественно. Хотя не факт.
Прямые запросы (класс AccountRecordset), конечно, помогут...
но это придется немного попотеть...

(134) Прямыми запросами к бух-итогам очень геморно обращаться , и не факт что выигрыш будет в скорости

(130) 241 строка, но меня несколько напрягает, что бух запрос сформирован с помощью конструктора ...
(132) Да, уверен. Посмотрел в  Maintanace Plann History

Есть еще один вопрос тогда: насколько лучше дела обстоят на 8 в такой ситуации?

(136) 240 строк - ни о чем... Запускай отладчик, втыкай замер производительности и оптимизируй.

(133) не только для бухии. для торговли файловая тоже быстрее. Но сиквельная все-таки надежнее и позволяет бОльшие объемы

(135) будет. От 3 до 10 раз.

Бухгалтерия восьмерки намного лучше уживается со скулем чем семерочная , как впрочеми восьмерка в целом :)

(137) бух подсистема в ней гораздо лучше.

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

(137) И в восьмерке можно наваять отчет, который будет тормозить и глючить...  :)

(138) Переписать отчет не проблема, но таких отчетов у нас самописных достаточно много.

(145) "Пилите, Шура, пилите! Они золотые" (с)   :)

(140) Если отчет за период месяц или квартал то да , а если за произвольный период (скажем с 03.05.2011 по 24.05.2011) , то нет
(144) Ну это то само собой :)

(146) Есть нюанс. Возможно жить этой семерке у нас полгода ... Поэтому надеялся на более оптимальный вариант.
Сначала поставлю и погоняю локально на 2005 скуле, если итога не будет, будем пилить, раз уж они золотые :)

(148) Давно перешли на SQL?

(143) На проводках да (это прямые записи в базу) , на итогах нет , что бы посмотреть оборот скажем за пол года по 41 счету , запросу придется обрабатывать МНОГО проводок , итогами проще и быстрее .
Надо использовать преимущество бухкомпоненты там где оно есть , не надо с ней как регистрами работать

(148) Ещё в (27) было написано - не взлетит. Не зависимо от версии SQL

(150) "Давайте спорить до хрипоты о вкусе устриц. Которых я не ел." (с) Жванецкий.
В бухкомпоненте кроме таблица проводок есть таблица итогов.

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

(152) С периодичностью в месяц , и приходится делать много промежуточных запросов и расчетов к проводкам же опять , если период не цельный

(153) Открою секрет - я использовал прямые запросы в файловой (DBF) бухбазе к проводкам и итогам. Все равно прямые быстрее в 5-10 раз. Если вы умеете попадать в индекс.

(153)
"С периодичностью в месяц , и приходится делать много промежуточных запросов и расчетов к проводкам же опять , если период не цельный".
А с регистрами не так?
Совершенно одинаково.

(153) Разве бухитоги хранятся помесячно? :-))) всегда поквартально хранились...
более того, сама 1с считает точно так же... Только ввиду большей универсальности - менее оптимально, и через промежуточные таблицы (временные файлы)

(156)помесячно в том числе.

(156) Считаются по квартально , хранятся по месячно
(155) Итоги  хранятся чаще , есть актуальные итоги , и можно создать произвольные регистры для храения итогов при необходимости , на бух компоненте , если только на забаланс , но и там особо не поизвращаешся :)
Или ты что бы посмотреть складские остатки в опер учете запрос по операциям делаешь ? Шучу :)

И кстати я не спорю что прямые запросы быстрее , потому как сам их использую :)
Но ИМХО
Прямые запросы в бухкомпоненте геморойней чем к регистрам
Выйгрыш в скорости при переходе на прямые запросы выше в опер учете чем в бух учете
Очередное изменение типовой конфы бухии , может изменить ключевую структуру данных , и прямой запрос придется переписывать , в опер учете (по крайней мере в ТиС) ситуация помягче
Грамотное использование бух-запроса к итогам дает очень хорошие результаты но только при файловом типе базы

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

так, для справки: а как будут жить несколько десятков миллионов проводок в v8.x?

Хуже чем несколько миллионов операций на регистрах , но намного лучше чем такой же объем на клюшках , все это касаемо скуля
На DBF просто больше 10 миллионов (примерно смотря как в проводки сконфигурированны) не запихнешь , 1SENTRY.DBF превысыт предельный размер

(161)теоретические рассуждения не интересны.

На восьмерке пока не набрали еще приличный объем , пока два миллиона проводок в бухии , полет нормальный
На семерке файловой на 8-9 миллионах сворачиваемся , живет приемлемо, этот же объем в скуле , просто умирает , переписывать все отчеты и модули документов в более или менее типовой нет смысла

(163) Бухгалтерия живет на SQL с 2003г. без свертки. Много десятков миллионов проводок. Типовые отчеты не переписывались. Без тормозов.

(164) А перепроводитесь как ?
А как же высокоэффективные прямые запросы ?
Пострение стандартной карточки счета (проводки через бух-запрос) на скуле тормоза еще те

(165) Если один документ, то спокойно и легко.
Если массово, то, как и в оперучете, используем ReconnectNative.
Прямые запросы использую в своих отчетах и при расшивке узких мест. Как, впрочем, и в оперучете.

(165) Повторюсь: я не вижу никакой разницы между работой прямыми запросами между регистрами и проводками.
Как в регистрах остатки и движения - RG и RA, так и в проводках остатки и движения. Периодичность чаще всего одинаковая - месяц.
Но структура таблицы проводок универсальная, а у регистров - уникальная для каждого регистра.
Поэтому для проводок один раз написать несколько универсальных процедур - и все.

При перепроведении львиную долю занимет собственно расчеты остатков и себестоимости , ReconnectNative тут как бы ине при делах . Но честно говоря  я глубоко этот метод  не копал , первые весии (бетовые) прикручивал к опер учету , получалось глючно , предпочел смещать ТА при групповом проведении , а потом перешли на SQL 2005

(165) посмотри мой пост (147) , если периодичность месяц то естественно , а если период произвольный то нет

(167)нет, разница все-таки ощутима и различима.
в бухучете возможно только сканирование таблицы за период(!!), а в оперучете можно попадать в индекс, который можно крутить.

Что ж, запустил связку Win7 64bit + SQl Server 2005 Developer Edition на ноуте с Core i3 M 350 2,27 и 3 Гиг оперативы. Самописный отчет и карточка счета формируются на порядок дольше, чем в файловом варианте на этом компе.
Думаю, может забить и перевести базу на файловый вариант? Только интересно, как 25 активных пользователей уживутся ...

(170) В терминале легко , если объем базы не превысит критический см (161)

Самописка на регистрах спокойно работала при нагрузке 70-80 пользователей (причем все достаточно активные) , правда с использованием Citrix (приличная экономия оперативы терминального сервака)
В файловой бухии (практически типовой) без проблем работают до 20 пользователей  (правда опять же под Citrix)

(171) Таблица проводок весит 400+ метров, так что запас прочности достаточный.

(172) Меня вот тут другой вопрос волнует: если кто-то вылетал с ошибкой, то сколько времени уходило на то, чтобы всех выгнать из 1С и провести переиндексацию?

(174) ночью такие вещи делать надо...

(174) Ну вылетел и вылетел , остальные продолжают работать , вылетевший штатно заходит и продолжает так же работать , ночью скриптом бекап , переиндексация , обмены данными , возможно тестирование и исправление  .
Но кстати одним из факторов перевода оперучета на скуль несколько лет назад у нас был переход складов на 24/7 , но бухгалтерия я думаю ночами не работает :)

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

Интересная ветка. Автор, так а что там с 10 мегабиткой? Ты таки попробовал всех на терминал згнать или нет?

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

(179) "Просто на текущем крутится еще две тяжелые БД"... Возможно причина в этом? :)

(179) Дело конечно ваше и SQL по любому надежнее
но у клюшек файловый вариант не так уж плох.
Оперативный учет крутился в файловом фарианте несколько лет , база достигала почти 8-ми гигов (при переходе на скуль пришлось кстати переписать 60% всех запросов , в том числе и на прямые) , бухия клюшковая до сих пор крутится в файловом варианте . Размер базы больше 4-гигов , пользователей до 20 (в период месячной и квартальной отчетности и налоговых проверок , штатно 7-8)
При надежном железе , хорошей настройке служб терминала (Citrix-а) и своевременном обслуживании баз , проблем не наблюдается .
Восьмерка другое дело , только SQL , ИМХО файловый вариант в ней только для разработчика , ну максимум нескольких пользователей

(180) На не хилом ноуте - тормоза ,
Остаюсь при мнении что бухкомпонента и SQL - достаточно несовместимые штуки , или все переписывать :)

Если строить все отчеты строго за цельный период (месяц, квартал) вполне себе можно работать в бухии и на SQL (падение производительности будет , но не столь заметное) , но это не реально (всякие скрыжки за кородкие периоды и т.п.), а как только запрос (буховский или "черный") обращается к не цельному периоду , или напрямую к операции или проводке , на скуле можно тушить свет

(179) Если есть возможность сделать свертку делайте , поможет именно для SQL , это связанно с особенностями реализации бухкомпоненты , процентов 25-30 по производительности выиграете .
И совет - сворачивайте в файловом режиме , с последующей загрузкой в новую SQL базу , типовая обработка свертки бухгалтерии под SQL это , слов нет . Или переписывать обработку свертки капитально.

(184) Спасибо за совет. Когда все сделаем и потестим, отпишусь о результатах.

Удачи :)

В общем, все плохо. после свертки (отрезал почти 3 года) и полного ТиИ базы скорость банальнейшего отчета не ускорилась ни на ять. Даже наоборот, стала 4029 сек. против 4017 сек. (вертится все на другом сервере для теста, собранном на каленке) Ну это не считается, т.к. укладывается в погрешность и прочее.

Чутка переписал этот отчет, выиграл 20% при формировании за 1 неделю (по сути карточка двух счетов с доп. рассчитываемыми показателями). 99% времени занимает запрос к бухитогам. Посему такая просьба: может кто-нибудь подкинуть ссылочки на инфу по работе с прямыми запросами на бух. компоненте? Попробую, что это даст.

(187) Привет
Странно , должно было улучшится , не намного но все же . загружал в новую SQL базу ?
Запрос бухгалтерский или "черный"
Строится за цельный период ?

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

Собрали отдельный сервер, грубо говоря из того, что нашли. Девственно чистый. Поднял на нем SQL 2000. Создал в нем 2 базы под 1С: одну для старой, вторую для идентичной, но после свертки и ТиИ. Загрузил и запустил этот горе-отчет. Итог для старой - 4017 секунд, для новой - 4029 секунд. Период - месяц. Выводятся остатки и обороты по этим счетам в разрезе контрагентов.

Запрос бухгалтерский.

Беда этого отчета была в том, что там запрос делался дважды? сначала для первого выбранного счета, потом для второго. Это безобразие я убрал, заменив на один запрос. Проверил, что дало: 1230 секунд, против 1518 секунд при формировании отчета за неделю.

Тот кто курировал 1С до меня и до сих пор к ней причастен (просто работает, так сказать, в другом отделе) КАТЕГОРИЧЕСКИ против DBF, по той причине, что если понадобится переиндексация, то это будет сделать крайне сложно и долго (всех обзвонить, всех выгнать, потом всех обратно звать в 1С). Вот так вот. Поэтому хочу проверить, что дадут прямые запросы. Их надо для пары кретичных отчетов только реализовать.

(189) ну есть выгонялка , и я уже писал что простом вылете реиндексация не требуется

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

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

10 минут простоя в оперативной базе может быть смерти подобно (это я про переиндексацию) , но бухия то не настолько оперативный учет ведет .
4000 сек это 66 мин , блин на DBF база в 3 гига типовой бухии реиндексируется 10-15 мин в зависимости от железа , по моему потери времени меньше .

(190) А я и не говорю про разрыв терминальной сессии. Я про конкретный такой глюк 1С, или кривые руки пользователя, или еще что-либо. Хоть я и понимаю, что при отлаженной работе шанс таких ошибок стремится к 0, но убедить не получается. И даже догадываюсь, почему.

2005 ставил на ноуте локально и скорость работы не обрадовала :) Это я уже писал.
Выгрузка/Загрузка естественно была сделана.

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

Бяда в том, что в этой бухии работают и кассиры, а у них оперативность должна быть ого-го. (раньше кассиры работали в управленческой системе, но так вышло, что они стали работать с 1С).

Но формировании отчета не останавливает работу на 100%. Хотя и понятно, что это сомнительное преимущество при столь сильных тормозах.

+(190) Что-то не сразу подумал. Субконто - контрагенты, так что отбор по нему стоит. По поводу проводок: вы имеете ввиду добавить в отчет методы ВыбранаПоДт() и ВыбранаПоКт() ?

(190) почистить базу от нулевых итогов можно (и быстрее) и без выгрузки-загрузки

(193) можно и быстрее (хоть шринком) , но так надежнее :)
(192) Если у объекта метаданных "Проводка" стоит режим отбора Дебет/кредит (в типовых по умолчанию отключен , включен только общий отбор), в разы возрастет скорость при использованиии "ФлагДК" при любой выборке результатов запроса , скорость собственно метода "ВыполнитьЗапрс" не изменится .
В самом запросе "ТипИтогов" очень влияет на производительность , без необходимости обороты межд счетами лучше не смотреть.
У "ИспользоватьСубконто" проверь использование группировки по группам , если нет необходимости - то же долой

(194) Да вроде все нормально с типами. сам запрос

Ит.ИспользоватьСубконто(ВидСуб,ВыбКонтрагенты, 1);

Ит.ВыполнитьЗапрос(ВыбНачПериода, ВыбКонПериода, СпСчетов,,, 1,, "С");

Именно сам ВыполнитьЗапрос() и занимает 99% времени. Выборка результатов и формирование таблицы занимают от силы 3-7 секунд ...

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

(6) Это просто бух. подсистема сама такая ... нехорошая.

(197) На скуле :)
Ну да запрос простой , косячить вроде неоткуда , если только в список счетов поподают счета у которых нет субконто Контрагенты , даже выборки периодичности нет
(196) Здесь я тебе к сожалению ничем не помогу , давненько еще ковырялся пр. запр в бухкомпоненте , запутался , не получил приемлемых результатов и бросил это дело , регистры дело другое .
Если у тебя ВыбКонтрагенты практически весь справочник , ну по крайней мере 3/4 , попробуй метод Рассчитать() , и работай через временные итоги .
С трудом припоминаю , но несколько лет назад чето такое было на халтурке со скулем то же , парадоксально но вроде помогло . Хотя врят ли поможет , но попытка не пытка

(196) Используй класс Accounts Recordset отличная штука.

(199) А можно поподробней? Как я полагаю, это класс 1C++?

(200) Угу
в ряде случаев , позволяет поднять производительность запроса в раза в три , по крайней мере версии 2007 года , сейчас может подоптимизирован , производительность сильно зависит от общей структуры плана счетов , скажем одно субконто на счете при нескольких сотнях (или тысячах) аналитик прилично производительность растет , если 2 (или три) субконто на счете уже не так все облачно. Просто сама структура журнала проводок и итогов (и индексов) не очень оптимально для скуля реализована
Просто ИМХО - ну перепишешь ты этот отчет на прямые , получишь прирост производительности (хотя не факт) , а с остальными то отчетами (и документами) , что делать ? , бухия в отличии от оперучета должна регулярно обновляться

А зачем 20-30 пользователей в бух базе пихать на сиквел, файловый вариант для данного случая работает намного быстрее, если не переписывать на прямые запросы

(202) О том и разговор , вообще честно говоря не понятно что 30 пользователей могут делать в бухгалтерии если задействована программа оперативного учета .
Ну главбух , зам , несколько бухов , финансисты , ну кассир .
10 пользователей . У меня например в оперативном учете до 90 пользователей сидят в одной базе под скулем , в бухии как правило не более 8-9 . В период авралов только (отчетность там , проверки) до 20 доходит , и в  файловой бухии никаких проблем с надежностью и стабильностью нет.
В конце концов можно было бы подумать о вторичном реплицировании SQL базы в файловый вариант на автомате , типа скульная база надежно хранит , а файловой работают , но у TC похоже значительная часть оперативного учета именно в бухгалтерской программе ведется , так что этот вариант не проходит.
И и почему в предыдущие 2-3 года вопрос не возник , если после свертки 3 лет такие тормоза ?

Такое ощущение что в конфе не так давно задействовали разделитель учета , и завязали его как-нибудь криво , на тип документа например

(191) о блин, в ноутах стоят супербыстрые диски...

(205) Вообще то файловые клюшки на более менее приличных объемах базы сильнее дисковую подсистему загружают чем скульные , особенно если оперативки достаточно . У TC на  ноуте 3 гига , что в принципе достаточно для имеющихся объемов и одном пользователе . Кроме того тестировалось в первую не абсолютное быстродействие а относительное (к файловой)

(204) Снова здравствуйте :) Разделителя учета нет.

(203) Пользователей штатно 25: главбух, 14 бухов, 4-5 финансиста, 5 кассиров и еще некоторые.
 
По поводу копирования SQL в файловый у меня уже зародилась мысль, только несколько иная: каждую ночь делать выгрузку базы в файловый вариант, чтобы на этой копии гонять тяжелые отчеты. Надо только выяснить, наколько оперативная информация нужна бухам.

Оперативный учет ведется только у кассиров, но для них это крайне критично.

Думаю вопрос быстродействия возникал постоянно, только никто не хотел его решать :)

(207) У меня оперативный учет какой то период реплицировался для построения тяжелых отчетов (ночью) , но репликация шла средствами скуля (из скуля в скуль на другой сервак)
С переходом на 24/7 и развитем у нас OLAP серверов от таких репликаций отказались

(208) а олап у тебя какого типа и как часто пересчтитывается?

А извини за не скомный вопрос нафига столько бухов то , да и кассовые операции это в общем то оперативный учет
(209) стандартные кубы на SQL2008 с использованием MDA , оперативный пересчет идет ежедневно (ночно  , без прекращения работы) итоговый ежемесячно , клиент - excel

(210) ROLAP? Ночью никто в базе не работает?

MOLAP , работают но нагрузка минимальна , и как правило на чтение - печать документов , построение наборных карточек , расчет маршрутов на завтра

(212) Понятно.

(210) Извини за нескромны ответ, но я в душе не знаю :) Но этого пока не изменить. то что кассы - это опер. учет понятно, но того, что они ведутся в бухе это тоже пока не изменить.