Всем привет!

В субботу после двух часов работы на одном из компьютеров выскакивает примерно следующая ошибка: "...Codebase...Index..." и пропадают проводки во всех операциях. Ну думаю всё, пипец... Быстро всех выгоняю, удаляю физически все CDX-файлы, запускаю реиндексацию (она занимает чуть больше часа). Все заходят в базу, но через пять минут на другом компе эта же ошибка!

Говорю всем - на этом ваш рабочий день закончился :-), пишите всё на бумаге (потом внесёте)!

Первым делом запускаю тест оперативки (6 часов - 3 полных прогона) - ни одного намёка... Затем HDD - всё в норме... Остаётся (по моему мнению) только одно - сама база! Удаляю я опять все CDX, запускаю полный контроль, пересчёт, проверку - ни одной ошибки... Выгружаю базу и загружаю в другой каталог - практически ничем по размеру не отличается...

Сейчас 3 минут уже все работают в SQL-базе, пока тьфу-тьфу-тьфу всё нормально, телефон на столе не подпригивает...

Вот я и хочу узнать, не ужели у меня DBF-база достигла своего предела стабильной работы (или физического предела)???
Наверняка, кроме размера самого файла (более 2 гиг), на это влияет и кол-во строк в одном DBF-фале? А может и сама структура? Размер моей базы на момент краха:
DBF: 4 116 370 847
CDX: 1 829 090 304
Всего: 5 945 461 151
Из них:
1 481 735 692 1SENTRY.DBF
 755 029 415 1SACCSEL.DBF
 599 197 779 1SSBSEL.DBF
 476 158 464 1SENTRY.CDX
 454 624 256 1SACCSEL.CDX
 424 482 304 1SSBSEL.CDX
 287 741 222 DT5370.DBF
 269 622 222 1SBKTTL.DBF
 180 408 832 1SCRDOC.CDX
 152 617 468 DH5370.DBF
  96 610 746 1SCRDOC.DBF
  95 895 749 DT4961.DBF
  95 041 536 1SBKTTL.CDX
  92 772 864 1SJOURN.CDX
  77 840 974 1SJOURN.DBF
  63 885 138 1SOPER.DBF
  53 197 312 1SOPER.CDX
  ...

Тех.инфо: XEON, терминал, RAID 15000, 4 Гига, 20-25 пользователей

обычно базу размером с гиг-полтора обрезают

(1) кто ?

(0) Разбиение какое FAT32 или NTFS?

(3)+ Если FAT, то достигнут максимальный размер файла - 4Гб с хвостиком. Перекидывай базу на NTFS и работай дальше.

(4) где ?

(5) На жёстком диске с базой.

(5) На жёстком диске с базой.

(6,7) какой ?
самый большой не дотягивает до ограничения по ДБФ...

Вы прикалываетесь что ли??? Какой FAT???
Если нужны данные за весь период - никто базу обрезать не будет

(4) Где ?

fat32 - максимайный размер файла 4 гига.
DBF: 4 116 370 847
правильно говорит Андрюха.

(11) Читать не умеете?? Эта сумма файлов DBF: 4 116 370 847

(11) чукча, однако, не читатель, чукча писатель....

(11) неправильно

(12) сеть наверно...

(12) Блин, точно. А всётаки файловая система какая?

тестирование и исправление?

(15) Терминал
(16) NTFS, куча аппаратных раидов...
(17) Без ошибок каждую ночь, примерно 7 часов занимает

(0) Сорее всего достигнут именно физический предел формата DBF.
Наблюдал подобную ситуацию дважды (и в 1С7.7 и в БЕСТ4).
У формата DBF кроме ограничения на размер файла (до 2 Гб) существует обграничение на количество индексных элементов.
При приближении какого-нибудь файла к размеру 2Гб начинали возникать проблемы с индексами. Переиндексация спасала, но не надолго. Через некоторое время работы опять выскакивала ошибка по поводу индексов. Причем чем дальше рос файл, тем чаще ошибка.
Фактически происходило следующее. В какой-то момент кончались свободные индексы в системе и при попытки добавления новой записи в DBF-файл системе не удавалось получить индекс и выскакивало сообщение об ошибке.

То что у тебя это произошло достаточно рано - это просто невезение.
Но со временем, подобная ситуация будет возникать постоянно.
Такая штука начинает происходить, если файл DBF около 1.5 Гб или больше. От этого временно может защить постоянная переиндексация. Но только временно.

Либо обрезай базу, либо переходи на SQL. Время у тебя пока есть.

(18) один чёрт, у тебя летит СDХ, туда копать надо....

а перед Скулем религиозный страх?
или понятия не позволяют?

(21) Для скуля необходим выделенный сервак, на него деньги не дают. И к тому же, даже при наличии выделенного сервака скорость работы в DBF выше (не про отчёты).
Сейчас уже час все работают в SQL, размер базы 12 054 268 789 байт (только MDF), но загрузка процессоров временами на пределе...
Поживём - посмотрим

дык напугай - дайте денег или в один момент
злой бог 1С (точнее его зам 1СДБФ) вас покарает
и что надо молиться на нового бога 1Скуль,
но для этго надо принести в жертву 2000$ на сервак...

(23) В крайнем случае скажут - режь!

сам же сказал - резать нельзя.

(25) Резать нельзя для пользователей, бухгалтерии, а начальство если скажет "режь!" то неудобство для пользователей отойдёт на второй план

как я понял проблема - критический размер ДБФ базы,
выход или скуль или обрезание.
значит обрезание

А что если SQL на пользовательскую тачку поставить?

(28) Рассмешил

ага и движок от камаза в Оку засунь

Ну мы же не знаем какие тачки у пользователей. Это раз. А два - что это за машина "XEON, RAID 15000, 4 Гига"? Почему бы на неё не поставить?

кстати, а почему бы тебе скуль на этот сервак не поставить?

(31) Потому что на ней терминал, FireWall и много другой хни

(32) Да стоит он у меня, бухгалтерия у меня всегда в SQL работала, и сейчас все пользователи в таком режиме работают: на одном серваке и SQL, и терминал, и FireWall, и файл-сервер и сервер печати...

(34) Желаю тебе тогда $3000-4000 на сервак

(35) :-)

Я так думаю, что HagMan в (19) прав.
Можно тему в базу знаний добавить :-)