Подскажите пожалуйста, конфигурация торговля и склад, там есть справочник "лог" в который записываются любые манипуляции пользователей, и он сильно разросся, вобщем задача стоит сначала выгрузить его (отдельно, для резерва) и потом весь удалить. Я никогда этого не делал, говорят есть специальные обработки... Не подскажите как это все делается?

(0) позови кого-нибудь из взрослых

(0) "задача стоит сначала выгрузить его (отдельно, для резерва)"
копии базы недостаточно?

Ой ну ладно троллить, я конечно сам сделаю, просто хотел спросить совета у опытных людей

(0) Зачем тебе его удалять?
К примеру у нас есть справочник "НомерУпаковки", уже перевалило за несколько миллионов записей.
Да с ним невозможно работать через диалог, медленно все.
Но он отлично работает с запросами и альтернативными диалогами :)

(3) Ты уже пытаешься уничтожить то, что по сути не мешает...
Не вникнув смысл сего девайса :)

(4) фактически в справочник лог нужен только программисту, пользователи не будут там копаться... И уже был опыт того что после удаления этого справочника база работала на порядок быстрее.

(6) Фактически он нужен тебе, как спасательный Круг, автор сего девайса сделал его исходя из того, что к нему вечно приходили и пытались доказать, что они пушистые, а виновен Программист.
Уничтожив этот справочник, ты по сути делаешь себе приговор.

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

(8) Медленно оно работает, если ты его смотришь из диалога.
Как правило, такие девайсы надо смотреть через отчет или еще как, но не через типовой диалог от 1С :)

+(8)База то у вас SQL ?

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

(10), не база DBF-ная

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

(12)Печально, такое только через прямые запросы неплохо уживается, хотя... :)

Если быть еще конкретней, наверняка там есть привязка к объектам, ну типо "Быстрого отбора по объекту".
Было бы лучше вообще такое чудо привязывать к документам, вернее формировать отчетик из документов.

Хотя я не вижу как у вас реализовано, но могу только догадываться.

(12) перечитай этот свой пост раз на 10 и приди к верному решению :))
подсказка, ответ из 3х букв... первая буква S##

Вообще стоит задача какими-нибудь способами повысить производительность базы, сейчас она весит 4 гига, и самое обидное, что "тестирование и исправление" зависает и все, и пока единственная пришедшая идея - это прибить справочник лог. Тем более в него постоянно пишутся данные, и я думал, может ли  скорость записи зависеть от размера справочника?

(15) Уничтожение справочника не приведет к повышению производительности.

Погугли по поводу ВК "1sqlite"

(14) если бы клиент хотел раскошелится.. Но вообщем предлагали уже SQL, вообщем не хотят...

(15) могу дать вредный совет, открой файлик DD, посмотри какие таблицы dbf отвечают за этот справочник, скопируй их в резерв, удали из текущей базы эти таблицы :)))

(17) 1sqlite - Прямые запросы для DBF

(16) а что вообще можно реально сделать для повышения производительности? ну хоть что-то?

+(20) Или если лень и побоку, то вот выход в (18)

(19) а, ну это тогда ведь полбазы переписывать?

+(20) Не забудь потом зайти в БД монопольно, что бы таблички сформировать опять.

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

(22) А ты что подразумевал под оптимизацией?
Так и есть, не пол БД, а самые узкие места.
Как правило, это 1-3 мего отчета.

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

(24) И как это ему поможет? Логи нужны только ему самому в час Х... А пользователи даже не в курсе, что да как там пишется :)

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

(28) Тоже верно, но для DBF БД это не критично :)

(27) что бы не хранить их в основной базе.

(30) И как он будет их быстро писать, когда у него должна быть связь с другой БД, по ОЛЕ?

+(31) Я про Проведение документов

(31) не обязательно. Можно раз в неделю скидывать логи в другую базу и удалять скинутые

(33) А читать их потом как? :)

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

ну, чтобы не совсем, но в лоб... и ЕСЛИ в этом справочнике нет периодики. Я бы сделал так.
1.1) копию конфигурации;
1.2) удалить из неё (в конфигураторе) все объекты кроме этого справочника;
1.3) удалить (если оно там есть) из кода модулей этого справочника все упоминания об удаленных в п.1.2 объектах.
1.4) сделать ТиИ-Упаковку базы.
Итого останется только одна таблица данных справочника SCxxx.DBF(+ индекс .CDX). Причем имя этих файлов будут совпадать с сответствующими именами файлов этого справочника в орининальной базе.
Далее. В копии.
2.1) Переименовать эти файлы, добавив осмысленные постфиксы о временном интервале, за который составлен лог (SCxxx-ГГММДД-ГГММДД).
2.2) Запустить конфигуратор. Сохранить конфигурацию - создадутся пустые файлы SCxxx.DBF(+CDX) этого справочника. скопировать эти "пустышки" про запас на будущее (см.ниже).
Теперь можно.
3.1) Смело периодически при надобности переименовывать в ИСХодной(РАБочей) базе распухшие файлы этого справочника указанным в п.2.1 способом и перебрасывать их в каталог изуродованной базы-копии, а из полученные в этой изуродованной базе-копии "пустышки" (см.п.2.2) копировать в ИСХодную(РАБочую) базу данных.
3.2) В каталоге изуродованной базы-копии - подсовывать нужные для анализа файлы SCxxx-ГГММДД-ГГММДД.DBF(+CDX) с исходными именами SCxxx-ГГММДД-ГГММДД.DBF(+CDX) и штатно смотреть и крутить-вертеть логи.

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

База для логов должна содержать 1 справочник, в котором по сути 4 реквизита.
1) Дата
2) ТипОбъекта
3) Юзер
4) Строка - в нее будет писаться сам объект созданого справочника (значение в строку)

Первые 3 - это основные фильтры по которым быстро можно отобрать

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

(39) это похоже на чистку зубов засовыванием зубной щетки с удлинненной ручкой через задницу.

А можно вообще стандартным логом платформы воспользоваться и писать туда руками. Только периодически его объединять с архивным и чистить.

(36) Проще вообще, сделать копию БД в другой Каталог.
Удалить почти все DBF файлы, кромя:
- Справочника лога
- Справочника Пользователей
- еще какого справочника, относящегося к логу, но не содержащего много информации (мало ли мысль автора мне не видна)

И вуаля, у тебя твой 100% клон с чистым логом.

Потом удаляем вообще файл лога DBF.
И в рабочей базе нет больше лога, как нет и быстрой возможности оправдаться от надоедливых пользователей :)

(41) А вот это как раз самый паршивый вариант:
- Читается такое еще дольше
- Отбор делается не столь красиво, как кажется.

(43) ПоставщикДанныхЖурналРегистрации ?

(44) Это ты про 1С++?
Не все же знают про возможности 1С++ :)

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

(45) есть стопиццот способов.
судя по вопросу в (0) - самый лучший способ для ТС - заплатить денег программисту.

(42): а, да, точно, ещё справочник пользователей наверняка.
но - нет, не проще. перековырять - лучше, в том числе доп.функционал упомянутый прикрутить (аналих с использованием по ОЛЕ данных исходной ИБ). единственно что - удаление объектов (п.1.2) лучше делать на дейс-но пустой базе (только с мд-шником) иначе умается реорганизацию делать по сто раз на дню - а результат-МД уже "загрузить" в архив-ИБ.
А нет - и не надо. надо - так появится: или из архива простым подсовыванием файла получить и возможность появится; или в архив-базе все "быстрое" доработать на использование (при надобе!) объектов исх.ИБ.