Перенес базу из DBF в SQL, одни и те же отчёты стали работать медленнее до 8 раз по времени, 19 сек, против 157 сек.
Пошерстил по интеру нашел вот это: http://catalog.mista.ru/public/82018/?detail=Y
всё выполнил.
Шерстил этот форум, проблема есть, решений нигде не нашел.

База весит 4Гб, планировал загружать товары от поставщиков по 200-300тыс наименований, для выгрузки в инт. магазин, поэтому заведемо перешел на SQL.

Конфиг:
Софт
Win Serv 2008R2 + Сервер терминалов
MSSQL 2008 R2. Режимы совместимости пробовал все 2000/2005/2008
1С 7.7 v27 Секретный релиз

Xeon E5-1650v4 6*3,6-4,2GHz
16Gb 2400 DDR4 ECC
SSD 200Gb Intel S3710 (один из топовых)

Задача №1 ускорить работу, №2 расширить базу до объёмов 20ГБ++

Вопрос: мне пытаться дальше мучать 1С 7.7 чтобы она заработала быстро на SQL, или это мертвая тема?

Надо переписывать все запросы на прямые, с использованием 1с++.

Даже не так, недо переписать все на прямые запросы.

отчеты точно надо переписывать

Слава богу в типовых 77 торговли такого кода совсем немного

(3) аналитические - может быть... А остальные юзаются раз в неделю

(5) топик перечитай - там нет упоминания чего-то "типового"

(6) ускорить работу - хз что там тормозит

У меня например база растёт потихоньку, но например, отчет по остаткам время формирования меняется вообще совсем никак. Ведомость по движениям - да, конечно дольше формируются разница но на то оно иивыборка движений - тут отиувеличения объёма вывода и времени - не уйдешь

1. не надо ничего переписывать
2. нужно настроить SQL сервер для работы с 7.7, поищи рекомендации... как минимум нужно убрать параллелизм (до 1 потока)...
3. нужно настроить регламент SQL (как минимум обновление статистики)
4. нужно поискать где именно тормозит http://wiki.mista.ru/doku.php?id=it:analiz_sql_block

когда все пункты пройдешь, тогда уже можно думать чего делать в самой 1с...

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

Не знаю, у меня всё отчеты на sql работают быстро (даже без использования прямых запросов), sql 2005, база 20+++ гб

SQL в 7.7 работает крайне неоптимально и обогнать DBF в терминале не способен. Но восьмикратное замедление, это как-то перебор.
Займитесь сначала оптимизацией SQL: запретите параллелизм, установите разумное ограничение по памяти, вынесите tempdb на быстрый независимый диск. Если нет возможности убрать SQL на другой сервер, включите протокол SharedMemory и выключите все остальные. И так далее, поиск по инету рулит.
Попробуйте в 1С применить http://catalog.mista.ru/public/64620/ . Особенно помогает в дописанных отчётах, куда натолкали десяток-другой группировок.

(11) Все ВошедшиеВЗапрос используешь в запросах?

(11) "Быстро" - понятие относительное. На быстродействие больше повлияет не размер базы, а сложность учёта, количество субконто/регистров/измерений... ПУБ будет тормозить гораздо сильнее Бух при одинаковом размере базы, количестве и активности пользователей.

(0) для начала проведи анализ тормозов.. банально замером производительности.

я много раз занимался ускорением без прямых запросов.

как правило это неоптимальное обращение к вложенным реквизитам. Например в цикле постоянно используется

СтавкаНДС = Запрос.Док.Номенклатура.ставка.

простейший разбор
Док = Запрос.Док
Ном = Запрос.Док.Ном. А далее с переменными.

Кроме того очень долго обращение к периодическим реквизитам.

например ту же ставкуНДС номенклатуры получают при каждом обращении к строке. бывали циклы когда ставку НДС получали 80 тыс раз перебирая строки дока при том, что номенклатура в базе 100 позиций.

ставку получать 1раз, пихать в ТЗ и далее получать из тз..

КОроче там такого тюнинга очень много

главный тормоз это
1. множественное обращение к вложенным реквизитам порой через 4-5 "точек"
2. периодические реквизиты медленное получение.
3. в типовых обращение и поиск свойств КА и Товаров..

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

Если прямые запросы. то есть комплект ТИСа у тойскл от Шемякина Павла. Я вот его бух отчетами стандартными пользуюсь. Мегабаза на 100 гигов с 80 юрлицами. работает очень быстро

(16) еще все что связано с ЗиК... замечено, что ЗиК лучше вообще не переводить, или переводить с осторожностью...

(18) а у ТС ЗиК, да?

(0) а что dbf 200-300 тыс. наименований не понятнет?

Спасибо за советы по оптимизации, но вопрос то не в этом.
Ок, я оптимизирую до идеала, а толку то, получу 6 сек в DBF против 48ми в SQL.
Проблема то не в этом, а том чтобы разобраться почему одно и то же работает с такой разницей в скорости на разных типах БД?

(12) у меня конфа самописная, отчёт о котором речь я писал сам, ничего лишнего в нём нет, он тяжел тем, что рассчитываются итоги на каждый день за месяц, для расчета среднего. Можно было бы перепились регистр, но не хочу, отчёт 1 раз в месяц крутиться. Собсно и в других отчётах тоже тормоза, на этом я просто посчитал разницу во времени.
(13) нет
(14) учёт сложный, вопрос в том что DBF на том же серваке работает в разы быстрее, чем SQL? это и надо исправить. (15),(16),(17),(18)   см. мой ответ на (14)
(19)  у меня конфа самописная,
(20) боюсь нарваться на проблемы из-за размера, плюс проблема частая с блокировками из-за автоматический проводок документов с несколькими тысячами строк, что занимает ощутимое время.

(21) думаешь на SQL не будет блокировок?

>>Проблема то не в этом, а том чтобы разобраться почему одно и то же работает с такой разницей в скорости на разных типах БД?

вопросу тыщу лет, была на кубани статья "почему SQL тормозит" про 7-ку...чувак как ты телепортировался из прошлого?

>>1С 7.7 v27 Секретный релиз

что за релиз? патченный штоли?

(22) читал, но у меня в 8 раз разница в производительности в отчётах... в 1,5-2 раза будет норм.
(23) да, пропатченный, брал отсюда: http://catalog.mista.ru/public/82018/?detail=Y

(23) на том же серваке, ту же базу, тем же ехешником запускаю на dbf и вуаля, всё летает.

Ещё вопрос аудитории. Если я перейду на 8.3 в конфу УТ 11.3, она на SQL будет быстрее работать, чем DBF?

>> разобраться почему одно и то же работает с такой
>> разницей в скорости на разных типах БД?
В том то и дело, что "одно и то же". Не может быстро работать приложение, когда оно работает с SQL базой в том же стиле, что и с DBF. Ну никак не получится "крутить педали" на камазе так же, как на велосипеде. Не уедете никуда.
Попробуйте посмотреть профайлером, что делает в SQL 7.7 при формировании какого-нибудь отчёта. Вместо идеального варианта одного запроса с выводом данных на клиенте без обращения к базе вы увидите активность в несколько сотен, если не тысяч, мелких запросиков.
Формируется отчёт с выводом ваших 200-300 тысяч наименований номенклатуры. 1С выбирает из базы сначала остатки/движения по регистру с внутренними идентификаторами номенклатуры. Потом для каждого внутреннего идентификатора делает запрос к таблице номенклатуры, что бы получить по идентификатору наименование.
В случае DBF это нормально. Особенно, если индекс таблицы номенклатуры достаточно мал, что бы целиком закешироваться в памяти. Для SQL это катастрофа. Потому что для SQL каждый из этих 200-300 тысяч запросиков, это полноправный запрос. Для которого нужно проверить статистику. Проанализировать и, при необходимости, распараллелить. Проверить права на таблицы. В общем - дохрена чего сделать кроме, собственно, выборки данных из таблицы.

(26) ИМХО - не надо тебе 11. Десятку бери.

(26) 8.3 с DBF не работает, так что ваш запрос не имеет смысла. Или вы имеете в виду файловая или серверная? Если вы планируете размер базы 20++, то без вариантов. Только серверная.

(28) Не хочется поднимать флейм, но смысл для НОВОГО внедрения брать продукт, который производитель фактически считает мёртвым? По результатам вдумчивого изучения функциональности конфигурации, анализа потребностей бизнеса с прикидкой возможного развития на ближайшие несколько лет такое делать можно. Но осторожно.

Тема жесть)))

*ветка

(18) ну ЗИК да.

(21) ты на СКЛ переходишь не для того чтобы у тебя отчет за 6 сек выполнялся, а чтобы база на 20 Гб не умерла.

так что забудь про простые ответы на сложные вопросы.

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

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

можно просто терпеть. ну проживешь 50-60 вместо 80-90

и да. отчет на СКЛ можно сделать чтобы он работал за 6 сек. только потратить на это можно много сил. а можно потратить не очень много сил, чтобы он выполнялся скажем 20 сек, вместо 150.

зато на СКЛ можно сделать так чтобы отчеты выполняющиеся на ДБФ минутами выполнялись за секунды.

а еще на СКЛ можно сделать чтобы документы параллельно проводились.

100 раз уже писали вариантов всего два или юзай 1cpp++ (http://www.1cpp.ru/index.php/Main)
или если лень купи готовы библиотеку на тауSQL у павла сайт не помню

и ты поймешь как медлено у тебя все работало на dbf

(36) (35) народ сравнивает монопольную дбф версию со скулем. а как только в дбф влезло 3-4 человека и начало активно что-то делать. скорость сразу просаживается. я уж молчу про много юзеров и большую базу

а если дбф версия не на терминале а доступ по сети то вообще вешалка

(36) Не знаю у меня 100+ юзверей в базе в файловой дбф на штатных механизмов. Все попытки перевода на скуль проваливались из-за скорости работы (записи).
Покупка библиотеки тауSQL ничего не дает. ТОчнее надо полностью отказываться от штатных механизмов на прямые запросы. А это по силе равносильно переходу на 8-ку. Вот только вместе с переходом у тебя и современная платформа и шанс найти специалистов которые завтра смогут в твоей нетленки работать и типовые бибилиотеки (БСП, БПО, БЭД). А вот с в случае "покупки тауSQL" ты навечно привязан к единственному специалисту, и других ты будешь долго и безрезультатно искать (посмотрю я на 1с-ника который сегодня согласиться в новой конторе  сопровождать 7-ку с тауSQL, если конечно ценник не будет в 3-4 раза выше рынка)

(39) у меня 8 лет назад замечательно работало 40 активных и еще 80 изредка в типовой SQL2000 7.7, ни кто не жаловался...

размер базы в не зазаипованом бекапе был около 40 гигов

вообще, все штатно и без извращений....


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

(39) не знаю сколько раз пытался больше 20 юзверов в dbf  на 7.7 всегда были тормоза, sql + 1cpp или toySQL это лучший выбор для 7.7 ине надо меня убеждать что 8.хх будет быстрей, никогда не будет , с чем соглашусь так это с тем что 8.хх технологичней и больше плюшек (особенно в управляемом режиме web это нечто ему альтернативу трудно придумать)

(39) один тот кошмар что несет в себе вечная индексация базы по 15 30 минут в dbf

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

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

В типовых 77 тис не надо работать задним числом и тогда все норм.

(44) ТС где-то говорил, что самописка. Вангую самописку на опер. учете.

(45) Правильно будет так:
"В типовых 77 тис не надо работать".

У меня ТиС на SQL2005 WinServ2008, работает лет 7.
Настройку тут брал
http://needhelp-1c.narod.ru/sql2005_1c.htm
Как показывает практика Скуль быстрее работает в отчетах, при выборе товара в документы.
НО при восстановлении последовательности на севере все в разы дольше чем в DBF. База большая в день больше 200 доков.
Решил выгрузкой в базу DBF, далее восстановление последовательности и загрузка на Скуль. Нужно только менять на сервере BkEnd Для загрузки и BkEnd Для работы (ну или бантиком автоматизировать).

(0)
В свое время переписал на прямые запросы - на старом железе и куче юзеров под нагрузкой отчеты выполнялись 1 сек максимум

Основные тормозящие отчеты спец перепишет за месяц.
Это дешевле перехода на 8.3 раз в 10

(39),(40) хорошие сказки на ночь про 40 активных юзеров на ДБФ и 100+ юзеров в базе на ДБФ ... ну-ну. еще скажите что все 40 из них фигачат отгрузки, а не заводят контрагентов с договорами.

(39) Вот это "А это по силе равносильно переходу на 8-ку" все неправда. Одно дело дело когда ты все свои извращения на 7ке хочешь перетащить в УТ11. А другое когда ты устоявшуюся логику просто оптимизируешь. Это 2 большие разницы.

Почему люди до сих пор и сидят на 7.7. Причем большинство из них на 1С++ или ToySQL или чем-то подобном. Я не говорю что это хорошо. Просто это ОХРЕНЕТЬ какая работа переводить все свое добро нажитое годами на 8ку. Обычно это решается только усилием воли - выбросить все к чертям и пилить типовую с 0.

Я бы уже честно и сайт-то свой закрыл, но раз или в два в год кому-то хочется (ВСЕ ЕЩЕ, КАРЛ!) перевести свою 7ку с ДБФ на СКЛ.

(49) да активно финачать. Не все 100+, а где то 80 менеджеров, остальные по мелочи, ну там разносят кассу, банк. ревизоры движения по товару смотрят и т.п

в день до 8000+ документов, в среднем на круг 10 строк в каждом

(52)
Я вижу тему у вас 1Sqlite )))
1Sqlite Левое соединение по документу неопределенного вида
это и есть прямые запросы на ДБФ и на штатные механизмы слабо похоже

(52) (53) такое можно, если при проведении нет в модулях никаких расчетов чего либо.
Максимум все строго на ТА.

8000 доков на ДБФ в одной базе при 24ч рабочем дне это 5 доков в минуту. По 12 сек на документ...

Ну это можно сказать вероятный случай, но какой-то сильно сказочный.

Я и себе прям представляю как эти 80 менеджеров должны свои 100 документов за день ввести в таком режиме. Они там что у вас роботы что ль?

(56) А что 24 часа, а что не 36 или 48?

А нас нормальный рабочий день с 9 до 18 + 1 час обеденный перерыв
Никто 24 часа в сутки не сидит не бъет.
В пике (если смотреть по ЖР) по 3-4 документа в секунду проводят

(57) А я разве где то написал что 8000 реализаций?

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

(60) я щяз заплачу ... каких еще у вас там есть документов, которые ну вообще от словам СОВСЕМ не влияют на производительность системы?

(50) Полностью согласен! Переписать что написано годами на 8?
Нужен штат программистов, а главное время на отладку. А если сеть магазинов там работа встанет.

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

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

Более того какая нагрузка на систему когда менежджер сидит в подборе? никакой

А вот когда на основании отчета водителя системе нужно сформировать 250 приходников по кассю... или сформировать одновременно 80 фактур... вот тогда и понимаешь на сколько важна скорость записи и что средняя температура по больнице тут никак не канает, потому что машина не будет ждать до 20 вечера, если она должна в 15 часов уехать

Если все расчеты на прямых запросах, то собственно запись 10 строк в 1С доли сек штатно занимает в один регистр

ну проблема с общим журналом для всех документов имеет место быть

(56) А если база распределенная и документы прилетают из других баз?
Все реально.

(66) ну только так. и никак иначе. но это нечестно :)

(62) и изучить и переписать ВСЕ на прямые запросы быстрее?
Все отчеты, подборы, документы, которые "писались годами" и "прекрасно" работали на dbf на скуле работать будут с большим скрипом.
И тут вопрос что лучше писать с 0 на прямых запросах но на 7-ке или писать с нуля но на 8-ке. Какой вариант более перспективным?
Более того в случае с 8-кой у тебя хоть сообщество есть у которого спросить можно, какого хрена оно тормозит и что покрутить. А в случае прямых запросов ты где найдешь мамонтов, которые согласны за спасибо все грабли рассказать?

(68) ну. так ты перешел на 8ку?

(69) меня и дбф устраивает. Сейчас вот нашел косяк со модом, переделал кое что и всё хорошо.

(68)
За 8 ку больше платят и работы больше, интереснее, карьеры больше
так что выбор очевиден

(66) нет как раз в этом году последний филиал пересадили в единную базу
До этого (лет 10 назад) пытались создать единную базу на скуле куда стекаются все данные, но тупо по времени не успевала обмены проходить.
Ушли на мод с выборочными обменами (НСИ + межфилиальные перемещения). А елинную базу создали на 8-ки

(65) все запросы штатные. Я прикручивал логи на модули проведения, там действительно все проводится за доли секунды. Вот если кто то задним числом пытается провести, то там да расчеты 10-15 секунд занимать. Но для нас работа задним числом больше нонсенс чем практика. Любыые изменения через документ (вычерки, клиент что-то не принял - возврат текущим числом, а ПФ уже учитывают структуру подчиненности и автоматом печатают за вычетом. Правка заявок - через ввод на основании и корректировка новой)

(72) Штатными средствами распределенных ИБ сложно (если много баз не реально по времени).
У меня текстовыми файлами все летит на сервер и обратно через почту.

(0) если вопрос в только "планировал загружать товары от поставщиков по 200-300тыс наименований" дак пиши в базу сразу и выборку делай для выгрузки тоже от туда

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

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

(76) Конечно все зависит чем базу нагружают отчетом, проведением документов или еще чем. Ведется запись или считывание информации? Исходя из этого и нужно копать.
(0) Скуль тупит по всему - я не верю.

(75)  у меня тоже есть аналогичный справочник, куда я гружу прайсы поставщика (с ценами количеством).
При этом менеджер имеет возможность принимать заявки по этому справочнику (где он видит индивидуальные цены клиентов), автоматом загружаются фото при наличии (при загрузки тащатся с сайта поставщика)
Короче при количество элементов порядка 630 тысяч элементов дбф имеет размер в 450 метров.
Т.е. для дбф 200-300 тысяч это семечки по размеру. Т.е. будет порядка 200-300 мб.

(54) А я и не говорил что у меня все без ВК. Я говорил про модули проведения и расчета.
Например у меня есть отчет который показывает текущую загрузку машины (в рублях, кг, в клиентах и т.п.) и в сравнении в средней за последние 3 месяца. Естественно я не считаю каждый раз данные за последние 3 месяца а храню их в SQlite таблицах. Т.е. к проведению и расчетам это никак не относится. Можно конечно зависит справочник и в 7-ке и хранить там, но я решил хранить во внешних таблицах
Еще на Sqlite у меня логи изменения документов (т.е. кто когда и что поменял в документах/справочниках)

Из 1С++ я юзаю ИТЗ ибо группировки для отчета проще формировать методом сгруппировать. Но опять таки это для внешних отчетов

Еще в некоторых отчетах Йоксель, чтобы "плюсики как в 8-ке"
Ну и Сканер, ФР - это тоже ВК

В частности та тема. (если ты прочел) тоже чисто для отчета и чисто для фана (ну просто хотелось эту задачу решить именно прямым запросом, чтобы всё летало). Т.е. к проведению и расчетам она не относится

(49) 40 активных на ТИПОВОЙ SQL-2000  версии бухии

(51) Подожди, еще пара десятков постов и тебе начнут доказывать, что гибкие блокировки не нужны, и вообще покупатели у тебя ненастоящие :))))

(81) Честно говоря, использование прямых запросов на бух. учете не так эффективно как на опер.учете, в первую очередь из-за особенностей работы регистра бухгалтерии.

(83) С бухучетом и так проблем особых нет, на sql он хорошо работает через бухгалтерские запросы.

(84) не ври.. переписывал для московской страховой под прямые

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

(84) ага да типовая ОСВ по 41 счету в базе упрощенка с 30 юрлицами за месяц формировалась 10-15 минут. с той скл 15 -20 сек

(85) Ну не знаю. У нас одно время была семерочная база с 8 миллионами проводок - на sql отлично крутилась.

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

Если вернуться к вопросу топикстартера - что-то у него в самопальной базе не хОчет крутиться внутри сиквела, а ему об этом так никто и не сказал.

(0) 4 гб в дбф это база ни о чем, можно было и не переводить

ну и почти любую базу, даже без вк можно заставить ездить

(90) // Задача №1 ускорить работу, №2 расширить базу до объёмов 20ГБ++

(92) Ну для начала, нужно было решить задача №0 - уменьшить размер базы в 2-5 раз. Уверен, там мусора больше, чем половина. И тогда, мот и на скуль не надо совсем.

(44) писал я, самописная конфа у меня, не дал её один программер в 2006г когда я начинал бищнес, она была корявая и недописанная, но когда я это понял уже было не до перехода в другую.

(88) фигня какая, у меня на дбф крутилась база с под 16 млн проводов, норм.
Когда перестала влазить - года 4 назад купили скальный вариант

(93) угу. И регистров незакрытых. Поэтому и тормозит.

Тс для начала ужми базу на ИС обработка
Шишки для мартышки

(94) размер самого большого дбф файла огласите и его имя..ну и следующих пару в этом "рейтинге"

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

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

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

Конфу то озвучили?

(101) проснулись? всю ветку читали?

(99) не, тупо читает через метаданные регистры

На дбф все было хорошо кроме двух существенных - 1)слетали индексы 2) Так и не реализовали динамический список на прямых

(63) 10 часов народ начинает потихоньку заходить в базу
https://b.radikal.ru/b03/1801/56/cf32ceeaf44c.png

Я кстати пропарсил ЖР за прошлый понедельник. Всего уникальных сессий 140. Т.е. это теоретический максимум.

(21) "почему одно и то же работает с такой разницей в скорости на разных типах БД" - так работает движок, смирись. Или переписывай.

12 часов - 118 подключений и 2400 документов

(0) 1C++ может ускорить работу до 100(ста) раз. Проверено. Не во всех местах, но, если покопаться, эффекта добиться можно.

(107) Очень круто. Режете раз в год или чаще?

у нас 70 магазинов. примерно 500 000 клиентов в справочнике.  Режем каждый год.

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

(98) 500Мб документы расхода РН
и ещё с десяток по 430-480Мб, не смотрел что там.
Но мне надо сотни тысяч товаров с описанием загружать, и по несколько раз на день их переоценивать документом.
Сейчас база, конечно, не большая, но я хочу сразу на вырост, решить задачу, чтобы потом сломя голову не думать, что делать?

(108) Это если слабо оптимизирована. При анормальной настройки индекса цифры будут на порядок выше. Избавление от периодических элементов и переделка регистра партий радикально ускоряет базу.

(110) А какой смысл резать базу, если она на SQL переписана? Сделайте сегментирование в СУБД, если места мало.

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

(108) благодаря чему? Это если переписать на прямые запросы?

(112) Зачем все хранить в базе?
Зачем их каждый день переоценивать

(115) благодаря http://www.1cpp.ru/docum/icpp/html/TurboBL.html просто "холостым" подключением ВК.
А прямые запросы не 100, а в 1000 могут ускорить.

(112) имя файла какое ?

(112) тебя в (98) спросилимвполне конкретно про имена самых больших файлов. Что ты здесь мургу невнятную гонишь? Не знаешь как ответить на поставленный вопрос - так и пиши: звиняйте, не квалифицирован, свнтезник я, поставили одинэсить, покажмте пальцем как размер файла посмотреть...

(0) //для выгрузки в инт. магазин,

в интернет магазин? Кассу уже подключили?

(120) А что не так с кассой? С июля бъем из 7-ки.
Сейчас вот еще 2 кассы по новой организации буду подключать

(121) вы и (0) это одно и тоже? Вы в три смены? ночью оплата проходит? Как чек выбивается?

(122) А ты в этом контексте
Нет разные люди, но наличие сайте не означает что будет оплата на сайте.

У нас, к примеру, сайт чисто для заявок, оплаты ночью не приходят.
Хз как у ТС

(123) ну вот а мне интересно, иначе зачем переходить на скуль. Что за интернет магазин на 300 тысяч номенклатуры это филиал алиэкспресс что ли?

(124) это лавочники типичные. которые торгуют ничем и одновременно всем.

(124) ну почему. В автозапчастях на отечественные машины это число легко превышает 500 тысяч. А если брать иномарки, то 5 лямов это не предел

Удобно. Собрал прайсы с поставщиков переоценил и вывесил на сайте. Потом успевай только переадрисовывать заказы поставщикам. Красота. Ни тебе нелеквидов, ни складских площадей

(127) именно так в середине 2000-ых работал по фармации-опту. на складе был минимальный запас. вся торговля шла "с колес". большие прайсы от поставщиков - компилировались - вывешивались как собственные. по заказам - шла мегаразброска и согласование. Я как-то уже здесь упоминал - по отдельным заказам клиентов - дерево подчиненности от заказа до отгрузок на 20-30 листов - это вообще было норма. ниче, справлялись... правда не 200-300 тыс.. наименований товара - много меньше, тыщ 15...

(128) Это как "с колес" - только целыми коробами торговали? Принимали на складе и сразу навешивали ярлыки с адресом клиента?
Не представляю логистику - это ж надо всю фуру поставщика быстро распродать, чтобы остатков не было!

(112) "но я хочу сразу на вырост" - абсолютно правильное желание, и оптимальный выход пока один - 1С 8. Фирма получит: масштабируемость, большое кол-во спецов. Да, тебя легко смогут заменить, но опыт внедрения сыграет свою роль в резюме, в отличие от SQL 7.7.

(129) Ну примерно так. У нас сразу при поступлении печатается бумажка по клиентам и направлениям. И при приходе они сразу раскладывают по коробкам по клиентам.

(125) не скажи, может типа мосхозторга что-то у которого миллионы товаров в прайсе. Правда в основном мелочевка - болтики, гаечки разных размеров...

(129) нет. заказ на 100-200-300 строк. раскмидывался по куче поставщитиков с выбором предпочтнений по предоплате/отсрочке и прочео всего. По приходу поставоке - они принимались сразу как положено - в т.ч. с выбраковокой по фальсификатам и проочему и сразу шли в сортировку/набор по заказу/заказам (кросс-докинг) остаток шел на склад. фурами не приходили поставки - не тот масштаб. ;-)

(119) http://clip2net.com/s/3Pmdwar

(119) https://c2n.me/3RvU51G

(125) 20-30к рабочие позиции, остальные неактуальные для индексиции в поисковиках. Вон глянь сайт nix.ru у них с самого начала работы фирмы позиции хранятся в ИМ и фото к ним.

(127) Вот-вот, только ещё и переоценка должны быть автоматическая, некоторые сервисы сами собирают цены, за небольшую плату. По API можно забрать этот анализ и на основании него создвать док. переоценка.

В   шапке   документа 3237   поди  88 реквизитов с типом строка(1000) ?
:)

Ну и видно 4 незакрытых регистра

Ну и в целом, этой базе с таким размером еще лет 20 жить на дбф можно

особо не заморачиваясь

(138)реквизитов много, но типов значения "строка" с неограниченной длиной нет.
(139) Подробнее плиз, можно? Что значит незакрытый, как определить и как закрыть?
(140) (141) Ок, но скорость хотелось бы увеличить.

(142)
1.прос строки неогр длины разговора не было, они если че, в отдельном файле хранятся, а не в шапке документа

2. когда RG>RA одноименного регистра

(143)
2. А что понимается по "закрытием" регистра, есть какая ссылка или как вообще искать решение, каким запросом?

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

(117) Ну это у меня уже давно, я пользуюсь раскраской таблиц от 1c++ FormEx, так что эта компонента у меня подгружается при старте системы.

(145) Как такое возможно? Если это регистр остатков денег или остатков товаров, я же не могу заприходовать товар на одну фирму, у списать потом вообще не указав фирму... У меня будет остаток "0" пока я точно не укажу набор измерений с положительным остатком...
Ну или в отчётах без фильтров по измерениям должны будут вылазить "минуса" перекрываемые "плюсами".
Но ни того ни другого у меня нет.

(145) а если я измерение не указываю, например "подвид товара" т.к. ими не пользуюсь то и запись м него идёт пустая как при "Приходе" так и при "Расходе".

(148) покрути регистр, например, каким-нибудь RegPrint'ом.

(147)
приход
   фирма1 товар1 количество 10

расход
   пусто   товар1 количество 10

в RG будет 2 записи
период1  фирма1 товар1 количество 10
период1  пусто товар1 количество -10

и они будут переходить из периода в период

а в отчете останков по товару ты видишь 0.

ну и т.д.. Это тебе примитивный пример

(150) Ясно, ща закручу отчёт проверю.
А когда всё исправлю, что надо сделать чтобы файл уменьшился?

(150) Собсно нашел один регистр, с одним измерением, но у него ещё есть реквизит, так вот реквизит всегда разный во всех проводках. Из-за этого может быть незакрыт регистр?

(154) реквизит фигня

главное набор измерений

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