Собственно, коллеги, давно не работал с 1с77. Тут обратился потенциальный клиент с просьбой решить проблему с производительностью и остатками(работает на файловой версии и база доросла до 8 Гб). Напрашивается перевод на серверную версию, если откажется от вариантов перехода на 1с8. Последний раз когда  работал, использовал MS Sql server 2000. Подскажите, какую версию лучше выбрать? Есть ли смысл использовать более новые?  
Заранее спасибо!

Официально 77 работает только с SQL2000

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

(0) рекомендую смотреть в сторону 1С++

(2) Насчет производительности я особенных иллюзий и не испытываю, но с остатками поможет гарантированно.
Увидел статью про настройку 2008 R2 под 77.

(3) Туда и хотел смотреть, но уже после перехода на MS Sql, так как база большая слишком для файловой. Я насколько знаю, ограничение для файловой версии 77 - 1Гб. Или как-то можно обойтись без перехода используя только 1С++?

2008 r2
Ну или 2005
http://1c911.by/stati_1s/statya-1s-77-i-sql-2008.htm#3

(6) Простите мою неосведомленность. 2008 r2 или 2005 встанет на Windows server 2003?

Да
Винда тоже провереннная временем, претензий не помню :)

(5) Откуда такая инфа?
Вроде было 2GB для ОДНОГО файла, тобишь если одна из dbf-ок начинает подходить к этому размеру нужно начинать задумаывать.
Да и если честно это как правило решается обрезанием предыдущих периодов.

(0) В чем проблема? В том, что база большая? Или в том, что тормозит? 1С++ работает и с файловой базой. Я бы для начала проверил ограничение, указанное в (9). Если до него еще далеко - оцениваем объем проблемных мест по быстродействию. И смотрим, можно ли их решить без дополнительных телодвижений (т.е. без перехода на SQL и без обрезания базы). Далее: оцениваем, можем ли урезать базу. Если нет такой возможности - переходим на SQL.

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

(10) Клиент озвучил, что база весит 8 гб и надоела постоянная переиндексация. Постоянно не идут остатки.
Я сам пока базу не смотрел.
Думаю, что можно предложить.
Поеду разговаривать через час.  
(11) Согласен, не решает.

Встречу перенесли - у них света нет.

На 2005 стабильно работает, на 2008 тоже работает, но запускается с бубном, и с нормальной нагрузкой не тестиль, в офисе разворачивать базу клиентов

(12) Фигня, у меня база весит более 7 Гб - в файловой версии проблем нет. ни в тормозах, ни впереиндексации. Переиндексация занимает 7 мин (ломается где-то при отправке на печать, разбираться влом так как на данные не влияет).
насчет "не идут остатки" - в 99% это либо проблема "1,2Гб" (лечится), либо проблема кривых мозгов (неверная интепретация данных, без удара по лицу не лечится ;-).

(15) Уважаемый Злобчинский, а как лечится проблема "1,2Гб"? Свёртка? Как ускорить переиндексацию(клиент говорит, что каждое утро по 40 минут)?

Злопчинский. Sorry за описку...

(0) на ту которую сможете купить лицензию. Ниже 2012 помоему уже непродаются.

(16) Режим работы то какой файловый по сети или в терминале?

Что за сервер?
Конфигурация какая?

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

У меня база 16 гигов. В терминале. Переиндексация около 15-20 минут.

+19 А да, пользователей сколько?

(19) Пользователей в районе 20.

Конфигурацию сервера не знаю. Сидят терминально.

(19) Конфигурация 1С - доработанная ТиС. Что там дописано пока не видел.

(0) Работала оптовка на ТиС и на 2005 скуле, года три.
Пару раз их посещал неприятный песец "Cannot insert duplicate key"

Потом вернул их обратно на 2000 скуль, все норм, как и должно было быть (1)
Ща правда на dbf сидят и не жужжат, обрезал я их базу :)

Мораль такова. Если некрофил - нех выеживаться, юзай w2003 и sql2000 иль dbf

(24) после перехода с 2000-го два года проработали на 2008 - ничего подобного не наблюдали. Проблемы были только с подчиненными доками - решилось прямыми запросами, заодно и скорость слегка увеличилась. База почти 170, юзверей около 90, документов порядка 130-132 в месяц.

(0) Бери ту, на какую хватит у конторы денег, или на какую у тебя "твердые яйца", когда нет денег ;)

+(26) 1С 7.7 лучше оставить на SQL 2000 и на отдельном серваке :)
8-ку на 2012 и вперед или Посгрес :)

+(26) Для 1С 7.7 SQL, в базовой комплектации (установил и забыл), не дает нечего, кроме разграничения в дисковом пространстве. Но и тут надо понимать, что Журнал документов это ИД состоящее из 9-ти символов, где первые 3- это вид документа, и последние 6-ть это сам ИД документа. И того один документ может быть в количество = 2 176 782 336. И превышение сего количество документов фатальна для 1С 7.7. Хотя ни разу не видывал контору работающую столь долго в одной и той же БД :)

(28) бредишь...

Переводил базы с SQL 2000 на 2008. Пришлось править конфу и во всех конструкциях ВыбратьПодчиненныеДОкументы() указать даты. На 2008 стабильнее работает на "секретном релизе 27.1".
Плюсы SQL 2008 - использует всю доступную оперативку сервера. Но это и минус тоже, надо больше ресурсов.
На "SQL 2000" будет гарантированно работать без всяких костылей и танцев с бубнами.
Вообще все базы больше 500 Мб сразу переводил на SQL и никаких проблем больше не было - ни со скоростью, ни со стабильностью и особенно с переиндексацией.

рекомендую SQL 2000

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

если не устраивает скорость работы с 2000 - переходите на 8.2 только не на последние конфы, а на обычный интерфейс

еще один момент - версий 1С 7.7 для SQL в продаже нет, 1С их больше не производит и не продает

(31) Будет. С использованием тех же CTE и еще кучи функционала T-SQL. Чем новее тем лучше. SQL 2014

Скуль собираетесь пиратский ставить?

(34) имхо, это риторический вопрос. Наверняка и серверная винда без лицензии окажется. Если б было все на лицензиях, то не усидели бы  они на реликтовых релизах. Да и на терминальные сессии тоже лицензии надо покупать, если по честному.

(35) Я просто к чему вопрос задал, возможно ли сейчас купить MS SQL 2000?
Ведь метод "downgrade" тут уже не пройдет ?

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

(34) У них админ, вроде, есть. Пусть с ним решают лицензия или пиратка.

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

(39) Дык в профайлере посмотреть, что там за запрос на самом деле.

(39) Для начала планы запроса смотреть...

(40) да я даже не знаю где этот профайлер открывается! ;-) Открыл манагмент студию, посмотрел полазил по деоеву... закрыл обратно...
(39) а это где/как?

(42) Ну, тут уже классически - пригласи специалиста...

(42) https://msdn.microsoft.com/ru-ru/library/ms173799(v=sql.120).aspx

(0) Скажи базе, чтобы не тормозила, а то Злопчинский набьёт ей морду!

+(44) Вот еще малеха: https://technet.microsoft.com/ru-ru/library/ms173757(v=sql.105).aspx

Спасибо, буду смотреть.
ну и сюда стучаться

(0) лет 5-7 используем 2005, из нестандартных бубнов - пришлось переписать выборку подчиненных доков на прямых запросах. Почему перешли с 2000, уже не вспомню, но если бы сейчас переходили, то на 2008, там вроде, нет проблем с подчиненными доками.

(39) Покажи свой "чорный запрос".

(47) У меня друга проблема, переехал с 2008 на 2014 начали тормозить запросы к _1SCRDOC.
Переиндексировал. Стало быстрее.
Видно статистика поехала. Пришлось переделать запросы правильно.

(47) Сделай переиндексацию
alter index all on "+ИмяТаблицыОстатков+" rebuild

и обнови статистику

exec sp_msforeachtable 'UPDATE STATISTICS ?'

(0) насчет 2008 и позже хз, не имел дела, а на 2005 нормально работает

(51) на больших объёмах лучше поаккуратней, а то можно нарваться. Например так: http://catalog.mista.ru/public/256292/

(49) Чорный как чорный... публикую
.
    ТекстЗапроса = " Период с ДатаН по ДатаК;
    |Склад            = Регистр.ОстаткиТМЦ.Фирма;
    |Номенклатура    = Регистр.ОстаткиТМЦ.Номенклатура;
    |Количество        = Регистр.ОстаткиТМЦ.Количество;
    |
    |Функция КоличествоНачОст = НачОст(Количество);
    |Функция КоличествоКонОст = КонОст(Количество);
    |Функция КоличествоПриход = Приход(Количество);
    |Функция КоличествоРасход = Расход(Количество);
    |
    |Условие(Склад в СписокСкладов);
    |Условие(Номенклатура в СЗтовары);
    |
    |Группировка День;
    |Группировка Склад Без Групп;
    |Группировка Номенклатура Без Групп;
    |";

Всем спасибо за советы, буду пробовать

(54) СписокСкладов - СЗ, только элементы
СЗтовары - только элементы

2014, конечно

(24) Это, скорее всего, глюки, не связанные с скл
Помню вылавливал одну такую фичу с профайлером долгое время
Ругалось на строку ТЧ
Оказалось 1С отслеживает ковыряние в строках, т.е. пришлось насильно якобы редактировать ТЧ чтобы появилась нужная инструкция
Подробнее - есть тема на 1спп.ру

(58) Верх вежливости - не только послать, но и проводить!

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

(60) это багофичи 7.7
переходите уже на 8.3

(61) а чё, в 8.3 багофич меньше? или они там какие-то более православные?

(61) Ради элементарных вещей разбирать тонны кода типовых...
Использовать 20% всего написанного, зато грузить ресурсы :)
Семерочка актуальна, сам свой учет веду в самописке :)
Работает - не трогаю, никаких неожиданностей, все фичи известны

В продолжение - дошли руки... немного...
Простой чорный запрос

    ТекстЗапроса = " Период с ДатаН по ДатаК;
    |Склад            = Регистр.ОстаткиТМЦ.Фирма;
    |Номенклатура    = Регистр.ОстаткиТМЦ.Номенклатура;
    |Количество        = Регистр.ОстаткиТМЦ.Количество;
    |
    |Функция КоличествоНачОст = НачОст(Количество);
    |Функция КоличествоКонОст = КонОст(Количество);
    |Функция КоличествоПриход = Приход(Количество);
    |Функция КоличествоРасход = Расход(Количество);
    |
    |Условие(Склад в СписокСкладов);
    |Условие(Номенклатура в СЗтовары);
    |
    |Группировка День;
    |Группировка Склад Без Групп;
    |Группировка Номенклатура Без Групп;
    |";

Период - ровно месяц (октябрь).
Движений вообщем мало.
По моему разумению тормозит адски. Не просто адски, а издевательски.

Пока ничего не делал (никаких статистик не обновлял, ничего)
Осилил запустить профайлер.
наблюдаю мнепонятные для меня действия...
.
Постоянно идет создание и выполнение
.
CREATE PROCEDURE #RGTEMP1PROC(@current CHAR(9)) AS
   SET NOCOUNT ON
   SET TEXTSIZE 0
   DECLARE @VAL CHAR(9)
   IF EXISTS (SELECT * FROM SC84 WITH (NOLOCK) WHERE ID=@current AND ISFOLDER=1 ) BEGIN
       SET NOCOUNT ON
       INSERT INTO #RGTEMP1 SELECT ID,ISFOLDER FROM SC84 WITH (NOLOCK) WHERE PARENTID=@current AND ID NOT IN( SELECT VAL FROM #RGTEMP1 )
       WHILE 1=1 BEGIN
           SELECT @VAL=MAX(VAL) FROM #RGTEMP1 WHERE ISFOLDER=1
           IF @VAL IS NULL BREAK
           INSERT INTO #RGTEMP1 SELECT ID,ISFOLDER FROM SC84 WITH (NOLOCK) WHERE PARENTID=@VAL AND ID NOT IN( SELECT VAL FROM #RGTEMP1 )
           DELETE FROM #RGTEMP1 WHERE VAL=@VAL AND ISFOLDER=1
       END
   END
   ELSE
   IF NOT EXISTS( SELECT * FROM #RGTEMP1 WHERE VAL=@current )
       INSERT #RGTEMP1 VALUES(@current, 2)
return (0)

создание этой процедуры
выполнение ее (длительность=1)
и потом выполнение (длительность=16)
exec #RGTEMP1PROC '  25I1CBD'
drop procedure #RGTEMP1PROC

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

СписокСкладов - СЗ с элементами (групп нет)
СЗтовары - СЗ с элементами (групп нет)

вот эта фигня выполняется постонно
exec #RGTEMP1PROC '  25I1CBD'
drop procedure #RGTEMP1PROC

только строка типа '  25I1CBD' - меняется

(5) у нас 6 Гб - пока работает.

(32) Продает, по спецзапросу. Мы с год назад купили.

а обновление статистики
exec sp_msforeachtable 'UPDATE STATISTICS ?'
- как долго работает?
запустил, фурычит 20 мин уже.

(69) обычно быстро

(70) 50 мин уже фурычит..
и это нормально что внизу висит "отладка запроса.."?
http://content.screencast.com/users/Che66/folders/Jing/media/4c08336d-fc9f-4db9-9d51-4e681815703d/2015-11-07_2310.png

Все еще фурычит обсчет статистики, 2 часа уже
???

блин, точно что-то не так в скуле - бамбашит - по моему разумению - кучу временных таблиц типа чуть ли не на каждый элемент справочника номенклатуры...
скрин к (64)
http://screencast.com/t/jpgT7Zm5

И в чем разница между приведенным в этой ветке советом по обновлдению статистики
exec sp_msforeachtable 'UPDATE STATISTICS ?'
и нагугленным аналогичным, но почему-то везде пишут
exec sp_msforeachtable N'UPDATE.... - буквочка N
??? это что значит

не дождался, прибил обновление статистики
это чем-нить чревато ?

(75) Ты испортил себе карму. В следующей жизни ты родишься берёзой и тебя будет обнимать Безруков.

(74) Разницы никакой.
N - это уникод

Замерил. База 150 гигов. Обновление статистики 18 мин.

Так что делать-то?
В чем причина явно неправильного поведения в (64)?
Чего он там колбасит по справочнику номенклатуры?
Базато младенческая 7 гигов
В движениях регистра продаж 900 тыс записей
В справочнике номенклатуры 140 тыс
Количество детское какоето для скуля
Куда смотреть
Во что тыкать?

(79) втыкай в 1сpp.ru и не того нам мозги....
Большой мальчик уже, должОн понимать...

(80)  это в корне неверный подход
Я понимаю когда надо запрос ускорить
Но тут вообще затык кардинальный
Черный зпрос который должен секунд за десять отработать - молотит два часа
Обновление статистики молотит два часа
Гдето явная проблема

(81) Черные запросы в семерке реализованы так, что лучше бы их вообще не было.

Может у тебя запрос в цикле? под твои СЗ создается многократно временная таблица

(82) это точно

(79) ну как всегда checkDb, ТИИ

(79) посмотри может с винчестером беда.

(81) Явная проблема понятно где

(82) А ещё лучше - не было бы тебя....

не очень понял вы о чем?

Какую версию MS Sql Server выбрать для перехода с файловой версии?
Что это значит?

а я сижу и пью чай

(91) Ты сиди и пей. Не отвлекайся.

проверь, если убрать, как работает:
Условие(Склад в СписокСкладов);
|Условие(Номенклатура в СЗтовары);
Есть ли в списках группы?

(88) У вас велосипеда нет?

(94) у меня винтовки нет...

(95) А я то думаю, что вы вредный какой

(96) Я не вредный. Я некоторыми местами - очень даже полезный

(83)  нет, не в цикле

(84)  понятно что чорные запросы не сильно быстрые и возможностей мало. Но вообщемто работают. А здесь вообще жпс

(89)  смотри (64)

(86)  с винтом нормально все

(93)  в списках - групп нет
Сейчас проверю
Думаю что если убрать условие на список товаров то будет нормально

Проверил
В СЗтовары групп нет

Если закомментарить услрвие по списку товаров то выполняется ожидаемо - порядка 7 сек

Ниже еще есть аналогичный запрос к остаткам товаров
Ситуация точно такая же

Чтото явно не то со справочником номенклатуры... И его использованием в условиях запросов

в данном конкретном случае я выкручусь - запросы без условия по номенклатуре и потом отфильтрую тз с результатом запроса по нужному списку

Но это же не наш путь!!!!

дальше идет тоже тривиальный запрос:

    ТекстЗапроса = " Период с ДатаН по ДатаК;
    |Склад            = Регистр.ОстаткиТМЦ.Фирма;
    |Номенклатура    = Регистр.ОстаткиТМЦ.Номенклатура;
    |Количество        = Регистр.ОстаткиТМЦ.Количество;
    |
    |Функция КоличествоНачОст = НачОст(Количество);
    |Функция КоличествоКонОст = КонОст(Количество);
    |Функция КоличествоПриход = Приход(Количество);
    |Функция КоличествоРасход = Расход(Количество);
    |
    |Условие(Склад в СписокСкладов);
    //|Условие(Номенклатура в СЗтовары);
    |
    |Группировка День;
    |Группировка Склад Без Групп;
    |Группировка Номенклатура Без Групп;
    |";

Условие по списку товаров закомментарил.
но идет тоже очень медленно, за 3 минуты - 1 день, по строке статуса выполнения запроса видно. Это же полная хрень..
в профайлере ползет вот такое:

http://screencast.com/t/RS8I0lks

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

все... спецов не осталось.. 8-ка всем разжижила мозг...

(106) Есть уверенность, что нужно вызвать программиста, который сможет помочь.

(106) Переписывать на прямые запросы.

+109 Дело тут не в секретном релизе. Тут дело в том, как работает 1С с SQL. И самая подстава в том, что разработчик не может на это повлиять.

(107)
В регистре остатков на измерениях Склад и Номенклатура отбор движений и отбор итогов в конфигураторе установлен?

Да, и ещё вопрос, по номенклатуре видел что 140 тыс. записей а по складам сколько? Может складов тоже тысячи?

Складов - с десяток.
Номенклатура = 140 тыс всего.
в списке товаров, который участвует в запросе остатков по итогам - ~2 тысяч (это если анализировать большой промежуток времени, если за день - то получается вообще несколько десятков и выполняется запрос все равно долго!)

1 шаг.
Выбираем продажи по списку товаров (в списке нет групп)
Список товаров ~2000 элементов
.
    ТекстЗапроса = " Период с ДатаН по ДатаК;
    |Склад            = Регистр.Продажи.Фирма;
    |Номенклатура    = Регистр.Продажи.Номенклатура;                
    |Количество        = Регистр.Продажи.Количество;
    |Выручка        = Регистр.Продажи.ПродСтоимость;
    |Себестоимость    = Регистр.Продажи.Себестоимость;
    |
    |Функция КоличествоНачОст = Сумма(0);
    |Функция КоличествоКонОст = Сумма(0);
    |Функция КоличествоПриход = Сумма(0);
    |Функция КоличествоРасход = Сумма(0);
    
    |Функция КоличествоПродажи        = Сумма(Количество);
    |Функция СуммаПродажи            = Сумма(Выручка);
    |Функция СебестоимостьПродажи    = Сумма(Себестоимость);
    |
    |Условие(Склад в СписокСкладов);
    //включение условия вводит скуль в очень длительную обработку
    //ВРЕМЕННО: ОТЛАДКА: будем брать по всем товарам и уже на выходе фильтровать по списку
    //|Условие(Номенклатура в СЗтовары);
    |
    |Группировка День;
    |Группировка Склад Без Групп;
    |Группировка Номенклатура Без Групп;
    |";
.
- с условием - тупит отчаянно.
без условия - нормально.

шаг 2.
Отбираем остатки по дням по списку товаров (в списке нет групп)
Список товаров ~2000 элементов
    
    ТекстЗапроса = " Период с ДатаН по ДатаК;
    |Склад            = Регистр.ОстаткиТМЦ.Фирма;
    |Номенклатура    = Регистр.ОстаткиТМЦ.Номенклатура;
    |Количество        = Регистр.ОстаткиТМЦ.Количество;
    |
    |Функция КоличествоНачОст = НачОст(Количество);
    |Функция КоличествоКонОст = КонОст(Количество);
    |Функция КоличествоПриход = Приход(Количество);
    |Функция КоличествоРасход = Расход(Количество);
    |
    |Условие(Склад в СписокСкладов);
    //|Условие(Номенклатура в СЗтовары);
    |
    |Группировка День;
    |Группировка Склад Без Групп;
    |Группировка Номенклатура Без Групп;
    |";

- с условием - тупит отчаянно совсем адски, нереально.
без условия - тупит сильно, итоги по одному дню - 3 мин.

Регистр.Продажи, оборотный
Номенклатура - Отбор итогов=0, Отбор движений=0;
Фирма(то есть склад) - Отбор итогов=0, Отбор движений=0;

Регистр.ОстаткиТМЦ, остатки
Номенклатура - Отбор итогов=1, Отбор движений=0;
Фирма(то есть склад) - Отбор итогов=0, Отбор движений=0;

Номенклатура - Отбор итогов=0, Отбор движений=0;
Фирма(то есть склад) - Отбор итогов=0, Отбор движений=0;
Номенклатура - Отбор итогов=1, Отбор движений=0;
Фирма(то есть склад) - Отбор итогов=0, Отбор движений=0;

вот и ответ.

(115) а вот если я поставлю эти флажки, в ЦБ - понятно..
а что получится при выгрузке на ПБ? - запустится пересчет регистров?

(116) F xnj? d W< e nt,z 'njuj gthtcx`nf yt ghjbpjql`n&

Перевод
А что, в ЦБ у тебя этого пересчёта не произойдёт?

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

Всегда есть возможность не делать этот пересчёт на медленных базах...
Или погоди... У тебя запрос на дбф тормозит, что ли?

(120) не, на скуле

(120) пересчитать итоги в ЦБ и скинуть признак модифицированности перед выгрузкой на ЦБ?