Я понимаю, что вопрос уже "изжованный" до "неМогу", но все-же прошу меня простить, и подсказать.
Встал вопрос перехода на скуль, из-за размеров и реиндексаций, решили сначала потестировать, ... и вот тут офигели! разница в скорости перепроведения в 5 !!! раз.

в ДБФ месяц перепроводится 8 минут, в СКЛ - 40.
Вопрос: это нормально или нет?

БД самописная на регистрах (оперучет),в ДБФ - 1,5Г, в СКЛ - 2,3Г
сервер не дохлый - 2 ксеона 6х3,33, 48 гиг оперативы, 2 САТА + 2 ССД.
сервер без нагрузки (балуюсь на нем ТОЛЬКО я)
Win2008 x 64  + SQL 2008x64 (http://tavalik.ru/ustanovka-1spredpriyatie-7-7-na-microsoft-sql-server-2008-r2/)
о том что СКЛ не быстрее, и даже чаще медленнее ДБФ это я уже начитался, но нигде не пишут - "на сколько медленнее"?
Замер производительности показывает что основные задержки на ВыгрузитьИтоги() с фильтрами (в модуле проведения), при проведении в СКЛ-варианте, никаких значимых нагрузок на проц или дисковую подсистему нет.

переходите на 8-ку. откуда скорость на клюшках будет без 1с++ и прочих приблуд

ну во первых скуль нужно настроить правильно....

во вторых сама конфа требует некоторых изменений....

Ответ - да, нормально. SQL на перепроведении медленнее примерно в 5 раз. На отчетах при этом будет быстрее.

(1) 8-ка сейчас не рассматривается
(2) вроде все делал по описаниям из тырнета, но фактически с скулем только знакомлюсь и понимаю что мог сделать или не сделать что-то не так... за дельные советы в данном направлении буду признателен.
(3) если такую скорость перепроведения не победить - то вопрос перехода на СКЛ для меня закрывается :(

(0) коллега, Полтора гига в дбф - это вообще ни о чем. я на дбф сижу - у меня за 8 гиг уже. и все норм. переиндексация занимает минут 5-7. сервак года 2010...

Если прямые запросы,то скл будет быстрее и на проведении, а на отчетах и подавно

может лучше разобраться почему так много и часто перепроводить приходится?
это вообще говоря ненормальная ситуация

(0) > Замер производительности показывает что основные задержки на ВыгрузитьИтоги() с фильтрами (в модуле проведения),
- если работа идет задним числом, то основное время жрет времннгый расчет.
- если у автора основное время жрет ВыгрузитьИтоги В ТА (!?) то ускорить получится очень мало штатно. долгая выгрузка итогов означает что итогов ОЧЕНЬ МНОГО - при полутора гигах это ссомнительно. скорее всего как обычно - незакрытые регистры, которые раздувают до невозможности таблицу итогов.

(0) > БД самописная на регистрах (оперучет),в ДБФ - 1,5Г, в СКЛ - 2,3Г

Ей еще жить и жить на dbf.

> Встал вопрос перехода на скуль, из-за размеров и реиндексаций,
Сеть переложите и систему нормально настройте.

Уровень совместимости SQL базы какой?
7.7 запускается с 2008 через какие костыли?

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

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

- да, при 1,5 г на ДБФ жить и жить, но хотелось подумать заранее, не дожидаясь момента (и с учетом того что база сейчас сильно пере/до писывается.)
(10) совместимость с 2000(80)

(4) 40 минут перепроведение - это много? Расчет себестоимости в УПП 12 часов (это один документ) - это считается быстро, до этого трое суток было. ::

(11) Установите "секретный релиз" и совместимость 2008, потом проверьте.

можете поделиться?

(14) см почту.

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

Зато стабильность вырастает на порядок. Ни битых ссылок, ни битых индексов...

(16) Ну и безопасность. Файловую базу любой юзер может скопировать, а скулевую базу только айтишник имеющий доступ соответствующий.

(17) Кто угодно может слить sql-базу через прямые запросы. С обычным юзерским доступом, лишь бы была возможность загружать внешние компоненты в 1с.

(11) ну так вот тебе и тормоз при выорузке итогов. Вместо сто тысяч записей выгружается миллион

+ (19) Если регистры не закрываются - значит регистры используются неправильно. Скорее всего лишние измерения.

(0) "Встал вопрос перехода на скуль ... БД самописная на регистрах (оперучет),в ДБФ - 1,5Г, в СКЛ - 2,3Г"
Лучше переведите на терминал в нормальным дисковым массивом. Можно на SSD. SQL на таких объёмах просто не стоит использовать.

(11) "перепроведения за месяц (или 2-3) в нашем случае не избежать это факт..."
Если перепроведений никак не избежать, можно в свою самописку ввести последовательность и ночью её автоматически восстанавливать. То есть перепроводить документы с границы последовательности по ТА. И будет не важно, что 40 минут.

(0) Это нормально.
СКЛ не для скорости.

(18) Для этого нужна чуть большая квалификация.
(21) да это вообще не база и даже не базёнка. недоразумение какое-то мелкое

и если уж на то пошло, то перепроводить надо с переносом ТА.

Всегда поражало, насколько убого реализованы механизмы работы с регистрами в 7.7. Такое ощущение, что они были предназначены только для одной цели - получения итогов на точку актуальности. Остальное реализовали просто "чтобы было", через одно место. Один "временный расчет" чего стоит, с созданием временных итогов в каталоге временных файлов... Именно поэтому и неэффективно их использование с sql-сервером. А вот бухитоги нормально реализованы на sql.

(26) ну так это когда было сделано-то?
ты еще периодику вспомни...

(27) И периодику, и итоги по регистру можно было переработать с полным сохранением объектной модели. Просто 1с поступала как ВАЗ в своё время, нафига что-то новое придумывать, когда жигули и так берут..

(26) Бухитоги нормально?!!  Да их вообще по укурке делали, или скорее даже со страшной похмелюги.

(29) Работал с бухгалтерской базой в 35 гигов на sql - бухитоги просто летали.

(29) угу. во время страшной ломки после укурки... зато - (30)
(28) нет. просто сделали "более прогрессивную платформу".
если сделать клюшки по-человечески году в 2005 - кому был бы нужен снеговик?

(29) (30) (31) вы лучше скажите как данные упереть/убить простому смертному, если запуск внешних обработок закрыт (1cpp загружена)
не преступления ради, защиты для

(32) внешние отчеты/обработки разумеется используются, на открываются только определенно разрешенные, и подмена на файловом уровне закрыта правами

а, вспомнил - пароль из dba вскрыть же

(15) чота ничего не пришло в почту, но я вроде нашел ну ру-доске, буду пробовать.
(19) (20) самый "тормозящий" регистр - остатки товаров, 4 измерения, в нем максимально пытаюсь наводить порядок, но много операций (производство) и + переписываю/дописываю учет в производстве - были добавлены два измерения(для пр-ва) - не все происходит корректно.
(21) сейчас итак работа идет на терминале, и проблем с быстродействием - "0" !
хочется повысить надежность и секьюрность ...

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

(33) А формульный калькулятор?

(35) отправлял на почту в профиле big......@gmail.com

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

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

(37) все верно.
ещё задрочнул такой момент: меняю структуру регистра, в ДБФ - зависает на "Пересчет регистров" (после 12 часов терпение кончилось), а в скуле 6-7 минут и готово...
и формирование запросом служебного документа на 5-6 т.строк, и проведение его в скуле быстрее в 2-3 раза (раз в месяц закрывает регистр с 2 измерениями).

(32) "вы лучше скажите как данные упереть/убить простому смертному, если запуск внешних обработок закрыт"
Формульный калькулятор, табло, открытие MXL с нужной расшифровкой в нужной ячейке.
Но гораздо проще инсайдерски унести на флэшке или фотке в смартфоне клиентскую базу и прочие отчеты.

//******************************************************************************
Процедура Таймер()
    Если (глЗавершитьПрограммно=1) или (Константа.Выключить<>0) Тогда  
        глЗавершитьПрограммно=1;
        Форма.Закрыть(0);
        ЗавершитьРаботуСистемы(0);
    КонецЕсли;                  
КонецПроцедуры    
//******************************************************************************
Процедура ПриОткрытии()
    СессияОткрыта=0;
КонецПроцедуры
//******************************************************************************
Процедура ПослеОткрытия()
    ФормаРасш = СоздатьОбъект("РасширениеФормы");
    ФормаРасш.УстановитьФорму(Форма);
    ФормаРасш.ОбработкаОжидания("Таймер", 5000);
КонецПроцедуры
//******************************************************************************

это кусок кода обработки - модального окна авторизации

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

(42) А системные окна? Окно вопроса со сменой рабочей даты, выбор периода, предпросмотр, печать, параметры страницы и многое другое...

(42) дергать в таймера таблицу констант не кажется мне хорошим вариантом

(45) у меня есть константа "Выключить" когда я её вручную ставлю в 1 - все должны вывалится из 1с, ещё она устанавливается в 2 по событию, и тогда тоже всевываливаются, но отрабатывает ещё процедурка...

(44) смену рабочей даты - автоматом. всякие предпросмотры - нафиг (ИТшнег настраивает, остальные тупо печатают). выбор периода вроде подменяли, но проблема есть. равно как и "окно блокировки"

(41) (36) Формульный калькулятор и табло - не выполняют ОткрытьФорму если у пользователя нет права "Использование внешних отчетов/обработок"

(41) и не могу догадаться - как через расшифровку MXL заинъектить вредоносный код?

(49) вызвать обработку?

что больше всего возмущает - это отсутствие нагрузки на проце, памяти, винте....

(51) запусти кваку...

(50) я конечно же проверил это прежде чем писать

(53) а я лентяй...

ОткрытьФорму("Обработка",,"c:\1.ert") в расшифровке ничего недает. даже с правами открывать внешние

(53) см. пример тут, например:

http://catalog.mista.ru/public/202853/

Половина кода в мокселе + все вк там же.
Ну и в моксель можно запиахать всё что угодно

+56 найди, например, процу Конвертировать

(0)

Для такой базы скуль не нужен. У нас была база в 20 гигов, вот её порезали, ибо основные регистры к 1.9 приближались.
А так, всех в терминал и вперёд и с пестней.
+ оптимизировать чутка.

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

(58) обычно за 3 года регистры "наполняются" и проходится обрезание делать... хотелось бы и от этого уйти ;)

секретный релиз 27 + режим совместимости 2008(100) - работает медленнее, 53 минуты.

короче, можно подвести итог и тему закрыть :
перепроведение на регистрах в ДБФ существенно (в 5 раз) быстрее чем на SQL, выровнять или исправить ситуацию можно только прямыми запросами.

ЗЫ: теперь предстоят тесты с бухгалтерией, там все печальней из-за таблицы проводок, - заростает за 1,5-2 года, и там переход на СКЛ более актуальный.

(60) Нет. Всё не так. Штатно можно убыстрить. Будет на скуле летать, а на дбф просто космос.

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

(56) (57) ее в модуле нет, ее вероятно создаешь динамически в доп.глобальнике или в контексте.
Но ведь изначально кто то должен выполнить этот код по добавлению другого кода, по загрузке формекса и т.п.
Как это организовать если запрещен запуск левых ert?

(63) она в мокселе, ищи лучше :))

(63) открыл формульный калькулятор и твори

ну или табло

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

+64 причем в мокселе, в открытом виде

(63) на счет запуск левых ert - подменил печ форму на свою и привет :)

(69) выше писал - это закрыто. ридонли на уровне ос

(65) (66) ОткрытьФорму() или что то другое?

(67) хак dll или расшифровка dba - про это писал выше - не рассматриваем

(61) я понимаю, что занимаясь оптимизацией - можно ускорить процессы, НО "Будет на скуле летать, а на дбф просто космос" - разве это опровергает мое утверждение, что ДБФ все-равно быстрее существенно ?

(73) А ты запусти в базу побольше операторов, которые долбят первичку...

(73) прошу прощения за мой оффтоп в твоей ветке

(74) 80 активно долбящих юзверей у нас прекрасно держала дбф в терминале.

Ну это смотря что и куда долбить :))))

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

(78) 1совский - не быстрее. а прямой - быстрее втрое вроде (не помню, давно мерялись)

(78) Запрос в модуле проведения в 5 раз медленнее выгрузки итогов.

(80) Спасибо

(77) Комплексная, 2 плана счетов, задвоенные регистры для 2-х типов учета

(73) Все от задачи зависит.
200 пользователей никакой dbf не выдержит

(78) Если запрос-1с попадет в индекс то будет быстрее если не попадет то не будет.

(84) Не будет. Проверено годами практики. Выгрузка быстрее.

(80) Для 77 да, для 8.Х есть нюансы

(61) Подскажи как штатно ускорить SQL?
Перевел одному клиенту 7.7 DBF на скуль, большие документы (от 100 строк) тормозят при проведении задним числом на РассчитатьРегистрыНа(...).

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

(88) Я не перепровожу, они сами проводят :)
Там старинная ТИС, переписанная вдоль и поперек, есть над чем работать в плане оптимизации.

(87) похоже, что регистры - никак!
я уже преманентно (между работой) 2 месяца исследую этот вопрос, и пришет к такому выводу, вот и тему создал - обсудить свое убеждение :)

кстати по теме: самый большой(тормозящий) регистр "остатки товаров" - у меня в относительном порядке - т.движений 201 МБ, т.итогов 24Мб (против "незакрытого" регистра резервов, где т.Дв. 33Мб. а т.Ит. 65 Мб.)...

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

но сам не проверял, будет возможность - попробую.

(90) Отрежь базу. Но смыслом отреза базы поставь не просто сокращение данных в базе, а именно закрытие регистров на дату. Естественно сначала надо разобраться почему регистры не закрываются. Скорее всего некоторые измерения используются не во всех документах или заведены заведомо неправильно.

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

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

sql однозначно лучше особенно если переписать проведение на
прямой доступ типа 1cpp или taySQL никакой dbf b близко не стоял правда и отчеты еще переписывать нужно

(92) посмотри у меня на ИС "автоснятие просроченных резервов"

переписать на прямые запросы

(95) +1. А нецензурный императив "Рассчитать регистры, на..!" забыть как страшный сон.

Только-что увидел тему..
От SQL отказались года 3 назад, после аналогичного эксперимента. Шеф лелеял надежду.
В пять-не-в-пять раз, но что в СКЛ операции выполнялись дольше - факт. Тестил все возможные варианты.
Остались на файловом варианте базы.

ЗЫ. Можете сказать, что я не умею готовить СКЛ.. типа ©..

(97) типа да.

+97 правда, у меня нет ни прямых запросов, в виду их ненадобности, ни запросов длиной в 1500 и более строк.
Обхожусь простыми средствами.

(97) хотя если типовая - то проблемы в "готовке" не у тебя

(100) Нет, типовой там и не ночевало.
образца 2000-го года, переписанная вдоль и поперёк.
От названия "ТиС" осталась только "Т"

(101) нуу дык тогда дописывай по диагонали...

(102) А как-же: "Работает - не трожь!" ?? :)

(64) нашел КодыАП/D2
Но кто же сможет выполнить этот код, если:
1. запрещено открывать левые ert
2. открытие левых mxl код с картинок не выполняет
3. подмена ert и mxl невозможна

(104) всё можно.

(105) что конкретно?

Ты же понимаешь сам, что 7.7 базу ты не защитишь никогда, так, трудности только мелкие создашь и всё :)

(107) я знаю только один способ - расшифровка dba.
От остального (того что мне известно) можно закрыться.
Вот я и хочу узнать того чего не знаю.

(108) Т.е ты уже убрал табло, меню файл открыть, F1, формульный калькулятор ?

каким то макаром внештние ert-ки закрыл на редактирование, запретил загрузку внешних компонент ?
Запретил запуск портативных 1с-ок ?

(108) в моей боевой ИБ предприняты следующие меры:
Запрещено открывать внешние отчеты/обработки настройкой прав в конфигурации (это, кроме меню файл/открыть, блокирует и Табло и Формульный калькулятор);
Запрещена запись всех каталогов ИБ где расположены разрешенные внешние/отчеты обработки;
Запрещена запись всех каталогов ИБ где расположены КОП;
Запрещена запись всех каталогов ИБ где расположены выгруженные модули для ТурбоМД (turbomd.prm там же);
Запрещена запись 1Cv7.MD

(109) Выключено право "Использование функций в табло и формульном калькуляторе"

Настройкой прав по-боку если писать ОткрытьФорму

(113) так я же проверил - не работает

(109) про F1 просвети. что-то даже не знаю в какую сторону думать

(110) "запуск портативных 1с-ок"
"боевой движок" распространяется через GPO. даже если будет подменен exe/dll при старте он восстанавливается на дистрибутивный.
Запуск левого модифицированного движка из другого источника - тут надо проработать вопрос.

(116) я те с флешки запущю свою 1с-ину :)

(117) принимается.
но и это можно прикрыть

(116) на счет Права и открытьФорму, это тоже обходилось из самой 1с-ины. Надо только вспомнить как.

(119) буду признателен

Копируем базу в каталог без копирование прав и делаем что хочем.

(120) можно в личку, если тут светить не пожелаешь

(121) из разных каталогов не пустит в одну sql базу

Если в базе никого нет то с другого каталога пустит.
Или убиваю юзеров становлюсь админом смотрю
глобальную при выборе ячейки таблицы.
В любой таблице выключаем только просморт в расшифровке
пишу что то типа {"B","0","0","174","0","0","      2572BO "}
Включаю только просморт клацаю по ячейки. запускаю отчет.

(121,124) У нас всегда  1с запущена на сервере.

Как Вы в sql убъете пользовыателей у Вас слетят параметры подключения к базе sql ?

(124) >Если в базе никого нет то с другого каталога пустит.
В базе есть кто-либо 24*7, как минимум роботы
>Или убиваю юзеров становлюсь админом смотрю
Если речь про удаление users.usr - то нужно будет по новой прописать параметры подключения, которые надо знать
Если речь про активных юзверей на скл-сервере, то надо обладать правами sa
>Включаю только просморт клацаю по ячейки. запускаю отчет.
как может запустится отчет по ссылке на элемент справочника?

(all) может кому пригодиться :
у меня на файл user.usr права только на чтение
что не дает право смотреть(удалять ) этот фай но дает право работать всем с текущим файлом.
Для изменения пользователей :
1. администратор ставит все права на файл user.usr
2. администратор меняетфайл пользователей 1с
3. администратор ставит только чтение на файл user.usr

по моему так будет работать и для 1c sql и для 1с dbf

(127) А просто правами нужный доступ не сделать? Зачем извращения "толькочтением" на файл?

(128) Чтобы нельзя было удалить этот файл и
сделать как пишет 124
да и сделано это было более 10 лет назад ( я не знаю всех
возможностей серверных современных ОС может сейчас это можно и проще сделать)

(129) Более 10 лет назад уже была NTFS и права доступа.

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

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

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

(133) Основное что склю в плане безопасности перед дбф не имеет никаких преимуществ.

(132) да, dba - это проблема и об этом я уже сказал

(134) но и не уступает

(136) Но в случае с dbf можно просто скопировать dbf и все.
В случае с sql нужно уметь расшифровать dba или usr

(trad) В дбф объем больше можно квотами боротья с копированием. Долго научить расшифровывать? Система или безопасная или нет. А то что вы закрыли 90% из известных дверей оставив открытыми 10% вряд ли устроит того кто озабочен безопасностью.

Что бы темы не плодить, спрошу тут.
База дбф, список справочника, есть реквизит для сортировки. Включаем сортировку по этому реквизиту. Сортирует сначала по нему, потом по наименованию.
Та же база на SQL. Сортирует сначала по реквизиту, потом по коду.
Как сделать вторичную сортировку по наименованию, как в DBF?
И возможно ли это?
В методе Сортировка(<Способ>,<Разрешение>) только одно поле для реквизита.