Доброго времени суток профессионалы и пользователи!

Система ТИС переписанная работает по УРБД.

3(4) базы(сейчас станет 5(6)).
ЦБ в себя все получает + ведет выписки по банку + бухпроводки(минимал).
3-5 баз ПБ в ней создаются документы складские,реализации + касса(чтоб склады друг к другу не лазили).

ЦБ достигла показателя 2,54 гб за 1 год.
Максимальный файл ДБФ 455 мб.
НА этот год скорость роста увеличиться.

1. Вопрос какие максимальные значения возможны для ДБФ-баз.
2. И как правильнее действовать переходить на Скуль или ДБФ каждый год сворачивать?
3. Сейчас говорят о переходе на 8-ку УТ. Какая там БД испоьзуется и если делать, какую БД использовать?


Заранее спасибо, думаю тема обсуждалась не раз.
Но мне хочется понять актуальную ситуацию особенно по 8-ке....

Гиг для файла - безопасный лимит. Два - предельный.

мелкая базенка.

на файловом снеговике ты быстрее в предел упрешься.
а переведдя эту на сиквел - будешь жить долго и щщасстливо

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

ну из опыта - на хорошем сервере ДБФ вполне себе живет до 6-8 гб.
Конечно переиндексация имеет место быть - но в общем жить можно.

нужно только следить за отдельными файлами - как уже писалось - гиг и больше это уже не есть хорошо.

Кроме того регулярная дефрагментация тоже не лишней будет.

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

Перегруз в СКЛ - гарантированные тормоза раза в 3-4 все станет медленнее.

СКЛ - это последний вариант - если база достигла предельного размера - а разбивать год на части не хочется.
Будет тупить, но зато не будет падать.
Есть правда подводный камень - для перехода на СКЛ нужно следить за файлом выгрузки - если он превысит 2 Гб - то стнадартными средствами перейти на СКЛ не получится.

Есть правда обходные решения позволяющие выгрузить базу когда файл выгрузки больше 2 Гб, но лучше не рисковать, да и если файл выгрузки достигает 2 гб - то это очень большой ДБФ.

Только не файловый снеговик!
Ставьте SQL, будет надежность лучше и администрировать лучше.
Резать не всегда удобно (и нужно).

(5) в сиквеле все нормально работает.

А я за дбф и резать каждый год (безопасность и все такое)
А инфу сливать в 8-ку на скуле где уже и смотреть аналитику за последние 20 лет

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

(7) А никто и не говорит, что работает не нормально - тупит просто сильно.
А так конечно работает.
В отличие от дбф - который конечно шустрее, но за пределами 8 гб находится в постоянной зоне риска и иногда просто перестает работать - че с ним не делай

(10) надо просто "доработать напильником"©.

(0) в продолжение темы.
Сейчас нужно было делать перепроводку центральной базы.
ГП восстановить и пере провести предыдущий период.

А именно 04/2013. НА проводку 10 дней ушло 5 часов.

С чем может быть связано.
На копии запустил ТИИ, но это минимум часов на 12....

Что скажите?

Может свернуть началом года.
Из этой документы с 01/01/14 по сг перенести в новую базу, это реально?

+(12) на сервер терминалов не винить.
Там железо мать не горбюй.
Максимальная нагрузка в монопольном режиме от 1С 25%.

Проводить со сдвигом ТА или штатной фичей

(9) В 8-ке СКД-ные отчеты прикольные

(14) штатной!

К тому же RLS, проще ограничить отчеты по дате или по какому то параметру

(17) 8-ка в принципе удобнее.
Мы из ТИС переливаем данные для работы бухии в 8-ку Бухию...

Просто стандартную УТ придется так допиливать под наши процессы...

(9) И да ты не поверишь, хотели так сделать, но скуль просто не успевал оперативно грузить обмены.

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

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

правда мы это делаем каждые 2 недели

(20) регистр заявки самое больное место для ТИСа?
А как со связками с документом реализацией?

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

(24) у меня проще 1 заявка = 1 реализация!
Я и задаюсь вопросом почему регистр такой большой.
Я думал что реализация должен быть больше!

ну у меня 95% это доставки, и цикличность 2-3 раза в неделю, так что менеджер обычно пару дней "принимает" заявку добиваю в нею то что пришло или что клиент дополнительно заказал, поэтому чтобы задом не правили  вот и пришлось вводить систему "сторно" т.е. заявку провели и редактировать нельзя, а для изменения вводим на основании она отсторнирует старые записи и проведёт текущим числом новые

(25) Ну так приход-расход однако записывается в заявки, резервы?

(11) Ну да. Наверное можно.
Только когда лет 5 назад вопрос задали столичным спецам занимающимся как раз таким допилом и они обозначили ценник 7-значный с негарантированным результатом - то как то желание у заказчика пропало.

Тем более тормоза хоть и заметные - но поскольку все работает - то тормоза можно и потерпеть.

(27) резервирование не используем.
В качестве заявки идет документ "Неподтвержденная заявка".

(28) Это из МагкойТочки? да, они цены ломят огого... Я сам допилил. 130 000 документов в месяц сейчас держит.
Правда, нашел узкое место совершенно в другом - у меня один юзверь создает 15% нагрузки системы (из 85!).
ну и проблема 85+ пользователей осталась непобежденной...
(20)(23)(27) по-идее, если заявка не полностью закрывается реализацией - (например, граммовка весового товара), то в штатной реализации регистр не закрывается. Или если резерв по одной фирме, отгрузка по другой....

(30) и как решать проблему не закрытого регистра?
Для нас вариант не полной отгрузки заявки постоянная ситуация.

(23) самое больное место в ТиСе - пользователи и кривые руки автоматизаторов. я не претендую на уровень Левши, но когда вижу RG файл 1.7 гига и при этом RA-файл 280 мб, который называется УчетКредита - то только профсолидарность спасает меня...
.
а в реализациях тупо подчищаем и перезаписываем без проведения

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

(30)  заявка не полностью закрывается реализацией - (например, граммовка весового товара), то в штатной реализации регистр не закрывается.
.
исправляется добавлением одного опенатора в нужное место, типа
чтото = 1; //вот таким простым оператором. и реализация будет полностью закрывать заявку

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

(0) "ЦБ достигла показателя 2,54 гб за 1 год. Максимальный файл ДБФ 455 мб."

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

(31) как-как... закрывать регистр... прочитай, что такое закрытие регистра, и дописывай "типовую".
(34) не всегда. ну и этот вариант не единственный.

(0) 2.35, это ты размер каталога БД нам привел?
Тогда не дрейф, мала твоя поделка :)

Самое страшное, это какой либо файлик DBF до 2 Гб :)

(38) для немонопольной работы - 1 гиг. а у него один файлис, считай, пол-гига... он "готовит сани летом", что правильно

(39) Ха... а ты поинтересуйся, за какой срок у него пол гига файлик вырос :)

+(39) Ежегодная свертка БД спасет отца демократии :)

(40) типа за год. значит, еще год может протянуть (хотя если  RG, то не протянет.)

(42) За год?...
Им бы уже на SQL переходить :)
И не волнует...

(43) дорого, и смысла не имеет на таких копеечных объемах.. дешевле резать.

(44) 1 Год, и уже пол гига?
2 года и гиг...
3 года ... её колбасит лихорадочно с крахом итогов :)
4 года и БД Отдыхает :)

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

Но, это дело их...

(0) Насколько я понимаю то это макс размеры ЦБ? Вообще если есть УРБД то ЦБ лучше держать в скуле. На то есть много причин. И лучше в ней неработать, держите ее тупо для обмена с другими базами.
Приведите размеры ДБФ ПБ, а также количество пользователей. Тогда можно будет сказать что делать с ПБ.
(31) А вы уверены что регистр у вас незакрывается? Если это так то пните программиста и пусть он решит вопрос. Собственно нерешаемых вопросов небывает.

Тут наткнулся на засаду с реализацией розницей и пко введенном на основании этой реализации. Если коротко, то пко по покупателям не закрывает реализацию.

(48) А должен? Соственно и недолжен. Это если ПКО на основании обычной продажи а не розницы то закроет.

Хеерня какая-то. у меня типовая ТиС, ПКо прекрасно закрыаает документ "Реализаци (розница)"

http://content.screencast.com/users/Che66/folders/Jing/media/6233f058-bc97-467d-afff-4a229c7da605/2014-01-13_2103.png

(48) возможны варианты - распечататй структуру подчиненности от розничнйо реализации и отчет по движениям документа ПОК - что именно закрывает будет видно...