Имеем базу Комплексну - файловую. База доработана сильно. Размер базы 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 года без проблем.

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

В общем если этот обор отключен программисту будет тяжелее строить отчеты непосредственно к проводкам , именно в разрезах номенклатуры , ибо отбора нет , всякие там ВыбратьПоЗначению() , но на самом деле это требуется достаточно редко . Бухзапросы просто замедлятся в некоторых случаях .
Например оборотка по 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) Свертку уже предлагали , но по каким то не очень понятным причинам , такой вариант не очень канает