Имеем базу Комплексну - файловую. База доработана сильно. Размер базы 7 гигов. Самый большой ДБФ 1.3 Гига - это общий журнал.
60 Пользователей онлайн, 1000 документов в день в срднем.

До прошлой недели всё просто летало идеально. Потом  обновили релиз с 493 на последний, сохранив все доработки соответственно. После этого намного чаще начала появляться ошибка транзакции, что таблица занята пользователем и так далее. Но работала ещё сносно. К концу недели база вообще стопорнула.
Полезли ошибки DATABASE ERROR 110, ругаясь на индексный файл.
Тестирование и исправление, удаление индексных файлов и загрузка-востановление базы не помогло. При создании документа всегда выдавалась ошибка транзакции.

Был обратно загружен старый релиз 493, правда план счетов остался новый, чтобы не пересчитывать итоги, так как делалось в рабочее время.
После этого на несколько дней ошибка DATABASE ERROR 110 пропала, но работать в базе было не возможно из-за транзакций. из 100 документов создавалось несколько.


В итоге щас из 60 человек в базе работает 2-3 чловека. заходит больше, снова лезут ошибки DATABASE ERROR 110  и ошибка транзакции. Помогает только выкидывание всех пользователей, переиндексация базы и запуск опять 2-3 пользователей. И это пока не зайдут ещё несколько.

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


P.S. Пока что решили чтобы быстрее вернуть базу - это перейти на SQL. Но из-за существенных затрат на это ищется также альтернативные пути решения.  Вообще думалось, что до 2 гигового лимита база проработает 3 года. Уже идёт 3-тий год. В конце года планировалось просто свернуть базу и работать следующие 3 года без проблем.

Лимит на само деле 1гиговый
"Самый большой ДБФ 1.3 Гига" - всё приплыли
Либо скальпель, либо скуль

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

(2) При 2Г база просто умирает. А при 1Г появляются спорадические ошибки.
Пора действовать уже при дбфке = 900М

(2) http://www.softpoint.ru/faq_id140.htm
ЗЫ а Цыдыикс скока ?

(0) Винт посыпался?

1270 байт - размер записи - что-то дофига. Чего надобавляли в журнал, да еще с отборами? небось, "составных реквизитов для поиска"? :-)

Проверьте свободное место на диске

(1) не всё еще потеряно, ставишь заплатку от hogik и живешь до 2-х гигов смело

Автор, отборы самодельные налепил + непомерянно много общих реквизитов с галкой отбор ?
:)))

(7) закусывать надо

(5) 10 рэйд. ошибок нет. Места много свободного ещё.

(3) ЦДХ 1,6 гигов всего Самый большой 450 метров

(8) Ну а дальше что?

(12) Ну а дальше как я понял - это скальпель.

(8) Есть ли ссылка где его скачать можно?

(8) Нашл твой старый ответ сссылкой http://infostart.ru/public/15577/
Но публикация удалена у меня пишет.

(13) Скальпель уже вчера.

(15) это непредвиденный инцидент. Мы это ожидали, но через годик только. Скальпель мы готовили к новому году.

Я так и не понял, что это за способ от hogik, который решает эту проблему?

Сделай для начала дефрагментацию диска.

(17) Это лишнее. Достаточно просто системник попинать.

(17) Сделал анализ, фрагментация не критична. Есть пара фрагментированных файлов в каталоге базы, но это не общий журнал  1,3 гига который.

(17) А так ночью запущу.

(20) Свёртку на майских сделай, пока не поздно.

никак не могу найти патч от hogik. Есть у кого этот патчик?

(12) наслаждаться
(22) есть

а так, поснимай отборы и сортировки с общих реквизитов (они еще и поди типа строка 50 у тебя ? :) )

(23) Можешь на maxnn2(собака)mail.ru сбросить? Буду очень признателен.


(24) Если бы я в этом что нибудь понимал.... Я нихрена не программист 1С.

(25) Тогда непарьте людям мозг а найдите денег на программиста. Это как минимум.

(26) Программист есть. Но он ограничился указанием ставить SQl.


Короче мне нужен патч от hogik.

(27) тебе ж сказали - вам программист нужен...

(28) программист есть. Идёт переход на SQL. Но за это время мне нужно нормализовать работу 1С на 2-3 дня. А для этого мне нужен патч.

http://disk.tom.ru/yqxlyg7

(29) Переход на скуль занимает 1 день. И то это если водки и закуски ну очень много.

(31) это если база правильная...

(32) Боюсь что база кривовата... Ни разу никто не занимался её оптимизацией, а только доработками.


Кстати, может кто обрисовать, какие подводные камни нас ждут при переходи и во время работе на SQL?

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

(30) Огромное спасибо.


Подскажите пож-та. Если я хочу установить Kernel37.dll вместо Kernel33.dll, то мне нужно в библиотеках Seven.dll и DBEng32.dll изменить Kernel32.dll на Kernel37.dll

А то в описании это не сказано.

"Я нихрена не программист 1С" "Программист есть. Но он ограничился указанием ставить SQl."

при базе в 60 юзеров онлайн и 1000док/день это ППЦ !!!

У вас куроводство невменяемое и готово рискнуть остановкой работы своей фирмы ?

(0) Я понимаю, что на форуме уже 5 лет почти, но все же ТИИ делали? упаковку таблиц пробовали? На другой диск базу перенести? На вирусы прогнать сервер?

(37) Ну вроде проблему локализовали. Проблема в том, что есть барьер в 1Гб ДБФ. Если ДБФ больше 1Гб и один пользователь записывает в неё информацию, то другие пользователи не могут полусить доступ к этой ДБФ даже на чтение. Вот и возникают ошибки.

Вроде как Патч Kernel33.dll эту проблему решает.

Вот завтра и проверится это.


(36) Я системный администратор и всю базу поднимал сам, и за 13 лет что я там работаю в этом направлении у нас база вылетала на 1-2 дня максимум 3 раза. Вот вчера было 3-тий раз. Всё остальное - полёт нормальный.

Услуги программиста берём у приходящего по 1000 р/ч.

(38) ну раз за 13 лет доросла до 1,3 Гига, то с патчем еще лет 5-6 протянет

(39) Этой базе 3 года. До этого было 4 разных баз.

(38) Если этот патч решит эту проблему, то может ну нафег этот SQL? Доработаем в этой до конца года, а с нового года свернём её и начнём заново? И так каждые 3 года делать.  Такой в принципе и был план....

(40) ну тогда хватит еще на 1-3 года.. а там на 8-ку или 9ку переползать можно будет

(41) решит, проверено

скуль дает стабильность и некоторые вкусности, которые ни дбфной нет

(43) Поставил патч. Запустил проведение с начала года, вроде по шустрее раза в 2 стала эта процедура.

(44) А какие вкусности? Про стабильность то у нас просто красота. База летает и так, сбоев нет практически.

(38) Реальный барьер по объему 2 гига , имел DBF 1.7 гиг , все нормально работало , имеет еще значение количество записей в таблице . Сбои начинаются когда в DBF таблице за 20 миллионов записей .

(47) А не сталкивался ли при таком размере со сбоями в расчётах? Например сделать 3 одинаковые сверки и получить все 3 раза разные результаты?  наш программист это объясняет именно размером....

(48) Нет , не сталкивался , причем Kernel33.dll не использовал .
Два нюанса , конфа вылизанная и достаточно оптимизированная . Обслуживалась регулярно (ночью скриптом) на принудительное переиндексирование и тестирование . С переходом на 24/7 , перешли на скуль

(49) У меня тоже каждую ночь идёт переиндексация.

(48) гворят что как раз именно так и проявляется..

Самопальный финанализ на бухкомпоненте , до сих пор крутится по DBF , 1sentry.dbf 1.7 гига около 9 миллинов строк . Проблем нет , правда пользователей не много , 5-6 одновременно не более .
В ТиС к тоже самый большой был где то на 1.8 гиг барьеру достаточно близко подходили , без проблем , но записей было меньше 20 млн , а вот с превышением начинались сбои

(51) Это не из за размера , точнее не только из за него , это след индекса , например при отвале терминальной сессии . Если пользователей много - несколько десятков , а железо и сеть не фонтан и сессии слетают и принудительно закрываются вут тут то такое и начинается

(53)  То есть если поставим SQL то такие проблемы там исключены?

Просто хотим понять.. Стоит это полмиллиона рублей или нет.

(54) - практически да

(55) а откуда у вас полимона рублей на скуль? у вас там что - полсотни пользователей?

(55) у меня сейчас в пике вертится 30 пользователей на ТиСе на ДБФе в терминале, из них половина - складские терминалы, + в ближайшее время еще десяток мест образуется дополнительных.

(57) Ну 57 пользователей онлайн из которых 30-35 на постоянной выписке. В особо нагруженные дни до 1500 документов в день.

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

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

(59) Ну мы перешли на скул с DBF при 60 примерно активных пользователех , и пиковомом размере базы около 8.5 гиг , считаю что подзатянули , надо было раньше .
Но готовились основательно , не за один день , многое переписали

(61) то есть если я щас с ходу конвертну базу на Скуль и пущу туда пользователей, то ничего хорошего из этого не выйдет?

(59) О! тогда надо консультироваться с более продвинутыми людьми.
опять же - нскольо большие документы? наскольо часто идут клинчи между пользователями? итд.
.
опять же, глубочайщее имхо в конторе где 30-35 зверей на постоянной выписке - полляма на софт не должны выхывать никаких трудностей.
.
опять же если 35 чел на выписке за год-два нагенерили базу на объем самого большого файла да еще общего журнала - скорее всего доки у вас не шибко большие.
.
поубирай с общего журнала все что несвойоственно как ЖУРНАЛУ. урежь короче его по функционалу если размер жмет

Тут еще нюанс есть , бухкомпонента не очень со скулем дружит а у тебя комплексная

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

(62) Такой шанс есть :(

(64) Вот тут можно по подробнее? У меня просто завтра будет оперативка у руководства по этому поводу. И ГлавБух имеет не последнее слово в этом деле.

(62) нет, все должно пройти нормально. Если народ работает на та - то все будет ОК. будут проблемы с ночным перепроведением на 2000 скуле. могут вылететь некоторые отчеты, которые на дбфе работают, а на скуле не будут...
.например запрос в котором
Сумма(Код), где код - текстовый код справочника - в дбфе канает, в скуле - сразу обломается ;-)

(63) 70% документов маленькие 2-5 строк.

(67) опять же - если плохо - то всегда со скуля назад пройдешь. время уйдет только на ЗАГРУЗКУ базы в дбф и пересчет итогов - если все ок, то пересчет проканает относительно быстро, еслия бяково/полубяково - может и на часов 2-4-6-больше затянуться

(69) ржупацтулам

(68) Я на 2008 скуль буду переводить тогда уж.

(69) итого у тебя 30-35 пользователей сумаррно генерят примерно столько же строк, скольок у меня 4 продажника... ;-)

(71) А что смешного? Основной поставщик документов - это розница... 20 магазинов.

(72) проработай этот вопрос - там есть что-то по 2008 скулу.
.
используй секретный релиз 27.7.7 - смотри на ИСе http://infostart.ru/public/82018/ - изучи комменты

(74) немного в сторону - а что у  тебя 30 вколачивателей делают? наладить автоприем - и сосать автоматом..??

(67) На эту тему тут немеряно холливаров было :)
Ну в общем структура данных которую использует бухкомпонента не очень подходит для скуля сама по себе , промежуточные итоги редко хранятся  и т.п. Напимер Рассчитать промежуточные итоги скажем с 11 по 27 число очень медленно работает , от таких конструкций надо избавлятся ,"черные запросы" тормозят , бух запрос  получше но тоже не фонтан . прямые запросы к бух итогам ИМХО не очень удобны .

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

..для бухов держать базу -1день.. ;-)

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

(79) нет у него массовых документов, 70% доков = 2-5 строк.
.
если не пожлобиться и взять нормальный сервак, да еще с каким нибудь аппаратным рамдрайвом гиг на 8-16, то все будет летать не хуже чем на дбфе... + плюшки от скуля

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

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

Одним словом я бы потестировал предварительно :) ....

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

да пусть поставит на 1-2 дня на скуль в рабочий режим - ничего страшнего не произойдет ;-) н уна крайня потормозят малость... или СРАЗУ сломаются

*83) Потестить по живому то же вариант :))

главное расходниками запастись
http://img-fotki.yandex.ru/get/4702/28706865.6c/0_5fc64_eaea312a_-1-orig

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

А так скуль рулит , надо только уметь его готовить :)

(85) Злобный ты :))

(85) Это мне уже сегодня бы пригодилось...


(86) Вот я тоже хочу развить данную мысль. По тому как у нас летает всё это время ДБФка, то даже не хочется ничего менять... Ибо лучшее враг хорошему...  А ДБФ-ки гляну щас.

(87) жизнь такая.. ;-)

(88) + проведи аудит.. может присутсвовать много ненужных записей... упаковать базу через ТиИ, почистить от нулевых итогов - короче живи себе спокойно на ДБФе с патчем еще год-два

Щас глянул количество записей...
Самый большой ДБФ - Общий журнал 1Sentry 1,2 Гб - 4млн записей
1SACCSEL 740Мб - 17 млн записей!!!

В остальных не больше 3-4 млн.

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

Цитрикс в этом деле до определенной степени панацея (против стандартного RDP) , но он едва ли не дороже скуля получается :)

(92) Как можно по быстрому такой аудит сделать?

(91) Близко к пределу , и именно на бухии .
Похоже бухия задействована весьма интенсивно .

Переход на скуль необходим , но он же может быть и чреват :(
Сворачивать базу , как вариант
Или перепиливать бухию , такое очучение что стоит отбор по субконто номенклатура , табличные части доков попадают отбор , та низя

Народ, а что будет когда ДБФ перевалит за 20 млн? И за что отвечает 1SACCSEL  и самое главное как можно её урезать?

Да, бухия у нас задействована очень серьёзно.

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

Поверь стоит ли отбор по субконто номенклатура

(98) Скажешь как? Я просто не программист и так глубоко не шарю.

Но то что база кривая и нужно её оптимизировать жабрами чую.

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

Если это о чём то говоит, то у меня RGххх и RAххх файлов на 3 гига набралось.

(101) Записал... Завтра до программиста это донесу.

(101) по любому стоит
в типовых по умолчанию этот отбор стоит

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

(102) сумма файлов значения не имеет
критично только на одном файле

(104) Давненько я типовые клюшки не юзал :)

(105) Стоит родимая.

(106) Угу

(106) В каком?

> Самый большой ДБФ 1.3 Гига - это общий журнал.


1sjournal.dbf ?

(110) в принципе в любом

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

(111) ой 1sjournal.dbf у меня мизерный 70 Мб и 500 тыс записей.

А за что отвечает 1Sentry?

(110) Самый большой файл не может быть больше двух гиг , и ни в одном не может быть больше 20 млн строк (записей)

По размеру файла еще запас есть , а вот по файлу отбора по субконто конец уже близок
Либо свертка , либо реструктуризация с исключением отборов , либо скуль

(112) Самый большой RA - RA328 - 600 Мб почти 3 млн записей

(114) Журнал проводок бухии

Его тоже можно подоптимизировать

(114) о да, меня кто-то услышал


напоминаю : Можно ли щас купить Комплексную 7.7 на SQL?

(116) см (115)

(115) пиZдёшь

(114) файл проводок

(119) Я данный вопрос поднимал сегодня. Кстати именно по твоему посту. Но мне было отказано. Ибо в бухгалтерии нужны проводки по документам.

(123) ты уверн, что в бухгалтерии не муд@чЪё ?

(123) Зачем ?

(123) в файле 1Cv7.dd инфа про все файлы твоей базы
открыть его можно экселем

(121) Ты мог работать c 3 гиг файлом в DBF ?

(125) они так привыкши
и им пофиг что файл проводок разросся
это проблемы "компьютерщиков"

(125) Попробую у них обоснование выбить сегодня уже.

(124) ГлБухгалтер очень опытный, я таких мало видел.

(129) я только знаю одно но : это курсовые разницы

(129) Частенько для бухии не нужна даже детализация до товарной аналитики , достаточно группировок
Регламент ежемесячный , зачем по докам то ?

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

(129) самый быстрый и лёгкий для тебя способ - это kernel33
спасет на первое время
а дальше либо скуль, либо свёртка базы
выбирайте сами

(130) Они не так уж и нагружают базу ибо не требуют супер-пупер аналитики

(132) Уже поставил  kernel37.
Как я понял, дотянуть до конца года - до плановой свертки, мне не даст 1SACCSEL.

(132) Не на долго
(134) Угу

(134) ну отрежьте там 10 или 11 год
чем она не плановая?

(133) оценка будет по-разному рассчитана

Итак, если можно подытожу.

Поставленная kernel37 даст продержаться базе недолго, пока 1SACCSEL не достигнет 20млн (3-4 месяца).

Тут есть 2 пути.
1. Переход на SQL - но это вызовет большие проблемы с бухгалтерией, а также очень затруднит проведение документов, так как SQL не любит задних чисел. + база будет намного медленнее работать без оптимизации.
2. Это оптимизировать  1SACCSEL, что даст прожить без проблем до конца года. А там свернуть базу и следующие 3 года без хлопот работать до следующей свертки.

1 путь - это большие финансовые вливания ок 500 тыс + к этому возможно придётся докупать сервак для SQL и нанимать программиста для оптимизации.
2 путь - это тупо нужно нанять программиста, который за разумные деньги может оптимизировать что надо, чтобы безпроблем прожить до конца года.

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

(138) У тебя же база за несколько лет , ну сверни там 2010 год например

(138) если ты каждый период пересчитаешь - уже будет результат

(139) я уже не валютчик, но помню, что в упп расчёт курсовых неверный

(140) А по трудозатратам, свернуть вот так 1 год  во что это вливается? Это мне нужно чтобы программист не отнекивался.

(141) В смысле каждый период?

(113) Глянул одного пользователя за март месяц... 33 входа и 30 выходов. Вроде в пределах нормы?

(143) если проводки будешь формировать одним число за месяц

(143) Ок. этот вопрос я уже записал. Я думаю достаточно даже формирование проводок по дням а не по документам сделать.

(144) В общем да , посмотри по всем , для уверенности

А так , отключения отбора по номенклатуре , при 5000 активных номенклатурных единиц , в типовой бухии , уменьшает количество записей в 1saccsel примерно на 25 процентов . Последствия отключения отбора должны быть учтены , но типовые отчеты этот отбор практически не используют . Быстродействие бухзапроса при отборе по субконто номенклатура упадет заметно , но не критически

(144) Номенклатуры у нас примерно 20 тыс.
Что мне нужно сделать? Просто убрать галку "Отбор" в Субконто-номенклатура. Перепроводить что либо нужно? Или 1saccsel сразу уменьшится после сохранения изменений в конфигураторе?

И на что ещё повлияет отключение этого свойства?

(144) -> (147)

(148) Пробуй на копии :)
Ничего не нужно перепроводить , но у тебя запустится перерасчет итогов , это несколько часов может занять

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

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

Перестанет работать например метод УстановитьОтбор , при обращении к номенклатуре
Станет недоступным отбор по номенклатуре в шурнале проводок
Скрость работы методов ИспользоватьСубконто() и КорСубконто() в бух запросе уменьшится , при условии отбора оборотов заметно , при работе с итогами на конец месяца практически не заметно

(151) То есть нельзя будет делать все отчёты с выборкой по отдельным номенклатурным позициям?

В общем повлияет на производительность в несколько худшую сторону , но ИМХО игра стоит свеч , я по крайней мере в клюшках этот отбор всегда отключал , по субконто реквизитов шапки отборы имеют смысл , по табличным частям , очень раздувают базу .

(152) Можно

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

В общем если этот обор отключен программисту будет тяжелее строить отчеты непосредственно к проводкам , именно в разрезах номенклатуры , ибо отбора нет , всякие там ВыбратьПоЗначению() , но на самом деле это требуется достаточно редко . Бухзапросы просто замедлятся в некоторых случаях .
Например оборотка по 41 за месяц целиком будет строится с такой же скорость как и раньше , а вот напрмер оборотка скажем с 1-го по 15-е , может будет строится в два-три раза дольше , ибо там сам запрос выбирает проводки , а отбора-индекса то и нет

Стандартный размен - объем на скорость :)

Чегой-то hogik-овые статьи на Инфостарте все удалены
http://www.peeep.us/41557f35

(156) Он удалил все свои наработки с Инфостарта.

16777215 вот оно волшебное количество записей в DBF при котором начинается кабздец

При стандартном Kernel :)

(158) оппа... У меня в 1saccsel 16 835 204 записи... Так занчит у меня из-за него база полетела?

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

(143) Если есть готовый инструментарий для свертки (стандартный желательно допиливать) то все упирается в объем базы и мощность железа . Сама свертка ну несколько часов идет если правильно все делать .

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

(160) Ога :(
(161) Самые тяжелые :(

(162) А Kernel137 этот лимит поднимает до 2 млн всего лишь?

(162) И как мне последствия такой работы проверить? Просто перепровести доки за последнюю неделю и всё встанет нормально?

(164) см. (145)

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

(158) FFFFFF в шестнадцатеричной системе однако
(0) 60 пользователей это много для ДБФ, выгружайте в SQL, если не выгружается то есть опять же патч (я пейсал). Книга знаний: Плагин для лечения выгрузки и загрузки больших баз в 1С 7.7

(163)Плюс минус , несколько поможет , но ...
(164) Не факт , могли доки вообще потеряться , хотя у тебя врят ли , проблем с 1SCRDOC нету , не записались проводки , или док удален а проводка осталась (свободная проводка)

Все таки КАЧЕСТВЕННЫЙ переход на скуль , особенно большой и сильно переписанной базы , дело не одного дня , если по уму , и активно используемая бухия однако то же вопросы вызывает.

Срочная свертка , или срочное отключение отбора , даст время на размышления

(167) Только что отключил отбор... После реорганизации количество записей в 1saccsel  не изменилось. Размер остался тот же. Все изменения делались в течение 15 минут. При сохранении файл 1saccsel был создан заново.

(167) Есть какие мысли?

(166) А модифицированная kernel37 до какой планки поднимает тогда это число?

Так , конфигуратор-проводка посмотри какие отборы стоят
Может стоять только  разрешить отбор , а может еще по дебет-кредиту и для всех

(167) Да какие там вопросы. У нас всю жизнь была SQL везде. Гораздо кошернее и стабильнее.
(170) 2 гига на файл у них физический предел (лимит для целого числа со знаком).

Если стоит только галка "Разрешить отбор" тогда плохо , её лучше не отключать

(172) Стабильней - абсолютно точно , масштабируемей , и плюшковатей

(174) Экспертам НАСА виднее :-))

(175) НАСА уже перешли на 1С в связке со скулем :))

(171)  У меня стоит галки в "Разрешить отбор" и "Для всех".

Какие дальше действия Кэп?

(176) Да они даже на метрическую систему перешли с дюймовой. http://science.compulenta.ru/301905/ С проста ли.

(178) РФ пустит штаты на луну ?

Ну можно снять все галки вообще :)
Тогда у тебя этот файл просто исчезнет , некоторые отчеты в которых задействован отбор счетов будут считаться медленно , очень медленно
Ними калку Для всех , и попробуй установить количество уровней 1 , файл должен уменьшится заметно

Сними галку для всех , в смысле :)

(180) Снял... Идёт сохранения...
А на что это отразиться?

Я вот что заметил. Копаю щас файл 1SACCSEL сегодняшний в DBF Viewer 2000.

В этом файле первое поле ab  Accid, так вот напротив этого ab стоит везде зелёная галка, а в конце файла на нескольких сотен записей вместо зелёной галки стоит красный крест.

О чём это может говорить?

Повторюсь, количество записей 16 835 204.
В копии базы до того как появились проблемы кол-во записей 16 592 499

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

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

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

(185) Сохранились изменения. 1SACCSEL стал вместо 730 Мб 236 Мб. Количество записей с 16 млн уменьшилось до 6 млн.

(187) Сбоить по блокировке не будет :)

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

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

(189) А по сути, для чего мы это делали если у меня стоит уже модифицированный kernel37? Он же это ограничение снимает?

Как я понял 16777215 это и есть проблема 2-ух млн строк?

(190) Недокументированный метод :)
kernel37 в основном снимает ограничение на размер файла в 1 гбт . Несколько по другому строит индексы в DBF , вылетов и блокировок скорее всего не будет , но по поводу корректного построения отчетов на таком количестве записей могут возникнуть проблемы .

Больше 16777215 не надо , никаких гарантий корректности

(191) Не помог kernel37, всё равно полезли ошибки когда все в базу вошли.... Щас удаляю отбор у номенклатуры и в проводках на рабочей базе...

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

Если количество движений по субсчетам счетов распределено не равномерно , сильного замедления бухзапросов не будет бли отключении отбора по счетам "Для всех" и ограничении одним уровнем . А по уму так надо базу смотреть , так трудно сказать

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

именно из-за этого файла у тебя все ошибки сейчас.

(192) не надо этого делать.

+ нужен именно kernel33, а не 37

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

(198) ерунда это всё..
Для комплексной, всё можно.
+можно в разы уменьшить файло проводок.

200 :)

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

+(201) И нужно вообще то :)

(201) там всё делается гораздо проще.

(193) После Снятии "отбора" и "для всех" база заработала нормально.

(197) А разве kernel37 это не тот же kernel33 только ещё с исправление загрузки процессора при ожидании?


(202) Буду прорабатывать этот вариант.

(204) нет

(205) В текстовом файле идущем с библиотеками вот что было сказано
"В комплекте имеется файл Kernel37.dll. Эта библиотека решает (кроме проблемы 1 гигабайта) еще и проблему “100% загрузка процессора при ожидании блокировки”."

(206) всё вопросы к автору
http://infostart.ru/profile/304810/

37 - раньше была для других решений, типа адвантадже

(158) откуда инфа? есть авторитетные ссылки?
а то я проексперементировал - забил справочник 16977214 элементами и "кабздец" не наблюдаю

вот про >1 гБ - с этим сам сталкивался, а про (158) - не в курсах...

(208)
Ошибка возникает при непосредственном удалении записи (в терминах 1С) в таблице с количеством записей более 16777215 штук.
Ошибка возникает при непосредственном удалении записи (в терминах 1С) в таблице с количеством записей более 16777215 штук. Удаляемые записи могут располагаться и до этой границы. Сообщение об ошибке указывает на индекс "IDELETED" с индексным выражением "D" и выражением фильтра "DELETED()". Этот индекс используется для нахождение помеченных на удаление записей (в терминах DBF) и размещения на их месте новых добавляемых записей в таблицу.
Первые кандидаты на такой количество записей: 1SCRDOC, 1SACCSEL.
Способов устранения проблемы, пока, не найдено.
Мнение разработчиков по поводу этой ошибки:
http://www.codebase.com/support/kb/?article=C01054
Допускаю, что такое проявление ошибки было привнесено именно в 1С. Т.к. продукт "CodeBase" продаётся с исходными текстами и "встраивался" в 1С с некоторыми изменениями на уровне исходных текстов разработчиками 1С. Само ядро "CodeBase" находится в библиотеке DBEng32.dll. Эта библиотека одинаковая для версий 1С: 18, 25, 27. Другие версии не проверялись.
Временное решение проблемы в ручном режиме.
Суть способа:
Отключить индекс "IDELETED" для проблемных таблиц. Естественно, отключится механизм использования помеченных на удаление записей (в терминах DBF). А это приведет к более быстрому росту размера таблицы. Частично решает проблему установка "Kernel3x", т.е. снимается ограничение на размер DBF файла в 1 гигабайт. Но при использовании данной разработки категорически нельзя использовать прямые запросы на FoxPro. Кроме этого придется чаще (регулярно) выполнять упаковку таблиц и внимательно отслеживать рост размера таблиц, т.к. существует ограничение на размер DBF файла в 2 гигабайта.
Последовательность действий:
1) При возникновении ошибки -310, на любой рабочей станции, срочно выгнать всех пользователей из 1C. Не сохранять никаких открытых форм ввода информации. Прекратить (прервать) выполнение отчетов. И т.д. Если произошёл сбой при выполнении регламентных работ, то восстановить базу с последней копии. При этом заранее оповестить всех пользователей об возможности появления такой ошибки и довести до них информацию о действиях в таком случае.
2) Т.к. в сообщении об ошибке -310 не выдаётся имя таблицы, то необходимо найти эту таблицу силой ума или тупым открытием подряд всех DBF-ов в порядке от большего размера файла к меньшему. Ищем таблицы в которых количество записей подбирается или уже больше 16777215 штук.
3) Удалить все CDX файлы. Зайти в сессию 1С монопольно и выполнить, тем самым, реиндексацию.
4) Вызвать утилиту обслуживания DBF/CDX структур. Например, бесплатную утилиту "Advantage Data Architect" можно скачать по ссылке:
http://devzone.advantagedatabase.com/dz/content.aspx?Key=20&Release=13&Product=8&Platform=6
5) Открыть проблемную таблицу в формате "FoxPro (DBF/CDX)". Вызвать свойства таблицы. Выбрать закладку с описанием индексов. Найти индекс "IDELETED". Изменить выражение фильтра с "DELETED()" на ".F.". Сохранить изменения с реиндексацией. Закрыть таблицу.
6) Открыть таблицу "1SUSERS" (DBF файл без индексов). В поле "USRSCNT" установить значение больше нуля. Закрыть таблицу. Выйти из утилиты.
7) Запустить сессию 1С в монопольном режиме. Согласиться с реиндексацией.
Дополнительная информация:
1) Необходимо повторять действия по отключению индекса после каждого удаления файлов CDX. После реиндексации без удаления файлов повторять отключение индекса не надо.
2) Данная технология проверялась только на тестовой базе. В промышленной эксплуатации - нет возможности проверить, т.к. у нас не возникала ошибка -310 при использовании "родного движка" и мы уже давно перешли на другу СУБД.
3) Надеюсь найдутся заинтересованные люди, и напишут утилиту для автоматического анализа проблемных таблиц и не ручного отключения
©hogik

Ромикс уже считал. В файле может быть 2 млрд.записей (_StrToId("ZZZZZZ"
))

(209) ага... вот где собака порылась.
Значит если непосредственно удаление запрещено, то в принципе работать со справочниками/документам можно. Главное что бы системные таблички (итоги, движения регистров и тп) не пухли

(211) читай внимательнее, дело не в "непосредственном удаленинии объектов"

(212) дык вроде внимательно прочитал. Вот на примере справочника - в идеальных условиях "удаленных" записей  у нас быть не может. Естественно к движениям регистров, итогам, 1scrdoc и тп это не относится - там движок сам "удаляет"...

(213) так и есть.. думал ты про 1SCRDOC речь ведешь

я ужо неоднократно упирался в это ограничение.. на 1SCRDOC

(215) у меня _1SACCSEL давно за 20 перевалил и RA1051 уже 15
а вот _1SCRDOC всего 7
но конфа не типовая, так что видимо взаимосвязей между доками меньше чем в типовых.

Спасибо за разъяснения.

(216) сыми отбор по счетам и.. 1SACCSEL  исчезнет
:)

(217) Ага , а потом тащись как удав по шкурке №5 от скорости исполнения такой конструкции
Ит.ВыполнитьЗапрос(Дата1, Дата2, Счет, КорСчет, Валюта, 3, ВидПериода)
особенно когда Дата1 и Дата2 не равны началу и концу месяца
А если Счет и КорСчет списки то вообще

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

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

(219) Разговор не идет о том что МОЖНО в комплексной , разговор идет о выплнении запросов к бухгалтерским данным , и о влиянии на это отборов .

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

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

(220) база не встанет колом, это раз.
Комплексную оптимизировать надо изначально, это два.

(321) Комплексную оптимизировать надо изначально - 100 % согласен
Если полностью отключить отборы по счетам , при "живом" проведении по счетам в реальном време (с расчетами остатков и средневзвешенной) встанет

Или по крайней мере имеет значительную вероятность

(222) не встанет, проверенно на 20 гиговой базе в дбф

(224) Круть , а че до 30 гиг на DBF не довели ?

(225) предел в 2 гига на файло достигли, пришлось резать

(226) А можно узнать причину того, почему на SQL не переходили?

(227) зачем ?

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

Относительно небольшая (средняя) бух база - чуть больше 4 гиг
1SACCSEL около 9 миллионов записей

Стандартная синтетеческая оборотка по субсчетам с включенным отбором по счетам за период 15 окт - 15 дек строится 2.5 сек , если отключить отбор полностью ,7.5 секунд .
С одной стороны мелочь 5 сек , с другой стороны в три раза дольше .

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

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

У ТС как раз второй случай .

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

а если тупо в скуль закинуть - на наших объемах всё колом встанет, проверенно.

(230) на одном серваке 30-40 минут, на другом 15-20, это реиндекс.
ТиИ не делается по причине отсутствия в его необходимости

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

(229) Эх.. мне бы твою уверенность и твои познания... А то я говорю что дешевле и для нас лучше 100-150 тыс потратить на полную оптимизацию нашей ДБФ базы, чем 500 тыс тратить на скуль, да ещё и новый гемор приобрести....

Программист говорит что нужно переходить на SQL, так как все большие конторы работают на SQL и что с ДБФ при таких объёмах уже никто не работает... И руководство соглашается с его доводами.

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

пусть переписывает и оптимизирует

(234) >>>> все большие конторы работают на SQL и что с ДБФ при таких объёмах уже никто не работает

ну это враньё, работают и еще как.

(236) Ну и как мне это обосновать?

(237) да никак, всё познается в сравнении.
Закинуть базу в скуль большого ума не надо.
А вот заставить её работать со скоростью, хотя бы сопоставимой с дбф - вот в этом и будет затык.

+238 под "скоростью" я понимая время проведения документов, а не получение отчетов с ИБ.
Которые и в дбф варианте мгноввенно извлекаются при должном умении

(232) Извиняй , но не очень то верится , 4-х гиг база , на очень не хилом железе индексится около5-6 мин , скорость индексации растет не линейно .

А ну у тебя как то и 10-гиг база за 10 мин реиндексировалась :)

Преимущество скуля никак не в скорости :)

(237) Почитай форум , преимущества скуля и DBF обсуждались многократно .

Я например то же считаю что темк еще можно и нужно оставаться на DBF , хотя сам сторонник SQL . Вот будет за 50 активных пользователей , потребуется работа 24/7 , потребуется интеграция с например OLAP серверами , тогда скуль без вопросов .

(240) ты у него лучше про дисковую подсистему спроси
например на ССД реиндексация ускоряется в несколько (до 10) раз по сравнению с зеркальным САТА-рейдом

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

Опять таки прямозапросечника в штат надо брать. А он ОстаТыщ запросит.

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

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

Я как-то легкомысленно закинул одну ДБФ базу в скуль. Там еще и конфа какая-то левая и старая была. Больше одного дня не выдержали. При беглом анализе оказалось, что там переписывать дохрена и еще чуть-чуть.

(234) Пригласи "программиста" в эту ветку, пусть аргументированно объяснит свою позицию не руководству, а простым специалистам.

(247) Вот поэтому "спецов", безапелляционно заявляющих: "Только Скуль", пинком под зад.

(243) ты про винты все же расскажи - что там на сервере стоит?

(250) да ничего особенного .. немножко винтов в 10-ке.. хотя лучще всё же 0 ставить.

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

(252) Свертку уже предлагали , но по каким то не очень понятным причинам , такой вариант не очень канает