Хочу сделать следующее.

1. Дела архивную копию базы .dt
2. Удаляю базу в ms sql
3. Создаю базу в ms sql
4. Развертываю в ней свой архив .дт

Приведет ли это к уменьшению лога транзакций? Подскажите, кто такое уже делал.

А каким боком тут лог?

(0) Сделай Full Backup

Сделал вот так  http://catalog.mista.ru/public/168314/

ничего не изменилось

(5) на каком сиквеле, с какой платформой, в какой моде база ?

1. Зачем?
2. Какая модель восстановления базы? Full или Simple

ms sql 2012

ЗУП, ERP

модель полная

(9) Тогда переходите на Simple. А если нужна возможность восстановления на любой момент (а не только на момент создания архива), тогда не смотрите на размер файла транзакций.

(0)[Приведет ли это к уменьшению лога транзакций? Подскажите, кто такое уже делал.] да

(8) кроме бэкапа базы нужен бэкап журнала

смысл хранить логи журнала - очень специфический , лучше чаще бэкапить

(13) каждую ночь бэкап создается

(12)Не совсем вас понял. Если есть .дт, то какая разница

(14) скульный бэкап можно делать с работающей базы средствами SQL , максимум - что будет - тормоза на время бэкапа , так что хоть каждый час  (ну и если поставить модель simple в базе) то лог авторезаться будет и расти так не будет
(15) сами 1С говорят что хранить архивы в ДТ не очень отказоустойчиво

(15) если нужно убить базу, то ни какой

(17) Что значит убить. Я предварительно сделаю бэкапы в ms sql и dt

(18) DT не для бэкапов.

(16)Если я поставлю простую модель, то лог уменьшится? Останется таким как есть?

(20) Не уменьшится. Останется, как есть.
Бэкап лог в нул, шринк. Повторить два раза.

(20) советую почитать азы по работе с 1С + SQL администрирование , в инете полно информации

(21) "Бэкап лог в нул" - вот этого не понял

(20) А можно узнать для чего так параноидально нужно уменьшить лог? Чего добиться этим хотите? Ускорения работы?

(23) BACKUP LOG TO NUL
Ему же не нужны резервные копии.

(0) Хороший ник, веселая затея. Пошел за попкорном.

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

(24) Лог может быть очень большим. Когда баз много то место на диске может закончиться.

(27) Убедили.

(0) И для того чтобы уменьшить лог нужно всего лишь сделать
в SQL Server Management Studio на нужной базе

Задачи - Сжать - Базу

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

+(30) Причем это можно делать даже на работающей базе.

Удалять базу и создавать ее для этого не нужно

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

Но это чрезвычайо редко происходит.
Для этого проще временно версионирование включить по нужному документу.

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

(33) Не обязательно откатывать. Поднять копию по состоянию на эн часов, эм минут.

(30) Спасибо! Сделано. Журнал стал мизерным, вся пена осела:)

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

(34) Ну да я про это и написал в (33)
Но это очень редко нужно бывает.
Только если конфликты возникли "а ктоооо это сделал ???"

(37) В (36) привели еще вариант. Никогда не говори "никогда" )

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

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

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

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

(41) Переливаются откуда?

(40) А самое главное - отбить руки тому кто дал в руки пользователей групповые обработки.

Это инструмент исключительно программиста.

(42) Делается копия рабочей базы.

В рабочую базу восстанавливается копия баз по состоянию на утро.

В рабочую базу из копии переливаются измененные документы.
Список измененных документов получается из журнала регистрации рабочей базы.

(44) Не, конечно можно чесать левое ухо правой ногой через спину, но не проще ли из бекапа поднять на момент действия? Или Вы считаете, что можно остановить на хрен предприятие на несколько часов, пока программер будет извращаться с восстановлением, собирая все из кусков?

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

(45) "Вы считаете, что можно остановить на хрен предприятие на несколько часов, пока программер будет извращаться с восстановлением, собирая все из кусков"

Да можно.

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

Даже обработка базы групповой обработкой быстро устраняется не останавливая работу предприятия.

У меня самый последний опыт остановки предприятия - сознательное приведение базы в неработоспособное состояние предшественником. Когда из SQL базы были просто физически удалены таблицы. Ну и что ? пара часов и все работало.

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

(46) Отнюдь. Все проходит достаточно быстро. И разностные бекапы делаются тоже. Одно другому не мешает.

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

(47) У нас за пару часов в сезон отгружается 12 фур. И оплата услуг транспортной компании примерно 800 руб. в час. Если фура не доедет до покупателя до конца суток, то в зависимости от условий договора возможен еще и нехилый штраф от суммы заказа. Вот такая вот математика.

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

Вы понимаете что восстановление базы на точку когда произошло разрушение не решает всех проблем ?

За то время пока ошибка будет выявлена выпишут еще документы, у существующих поменяются статусы и т.п.

Ошибка произошла в 12 часов, выявили ее в 13 часов. За чам выписали 50 счетов фактур и поменяли по 20 реализациям статус с "Собирается" на "Отгружен". Ваши действия ? Откатывать базу по состоянию на 12 часов ?

(51) Чем откат на 12 часов хуже отката на 9 часов?

(51) Причем тут тестирование и разработчик? Есть вполне обычные групповые обработки прямо в конфигурации. Есть полно всяких восстановлений последовательностей, которые запущенные в неправильном периоде хотя бы на копейки, но порвут учет в сданном периоде. Есть пользователи, которые думают что они что-то исправляют, а на самом деле не понимают какие последствия будут. Есть умники, которым плевать на регламенты и руководства и которые "А вот у нас в Газпроме программеры говорили, что так делать можно!". Что Вы уперлись в программера?

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

(53) Групповые обработки у обычных пользователей которые не понимают что они ими могут сделать должны быть запрещены.

После сданного период период закрывается.

"Есть умники, которым плевать на регламенты и руководства"
А должность таких умников какая ?

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

(53) Симпл неистребим. Наблюдаю данное явление лет 15. Есть подозрение, что это происходит всю историю скуля. Вопросы "как уменьшить лог" возникают с завидной регулярностью.

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

Но при этом никому в голову не приходило дать ей механизм по массовому изменению документов.

(54) "Мой способ" при отсутствии вообще каких-либо трудозатрат по поддержанию бекапов позволяет кардинально сократить время простоя и трудозатраты по восстановлению базы в исходное состояние. Хотя реально он не мой, а Мелкософта.

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

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

(57) А после отката инфобазы кто в ней "наводит красоту"? Например, до отката, но после факапа склад насобирал реализаций, распечатал документацию и отправил машинки?

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

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

(60) "Свежие" - это с датой создания после факапа или с датой изменения после факапа?
В базе как-то журналируется дата последнено изменения?

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

(63) Сурово - пользователь не заметит что-нибудь, что стало по-другому, и тогда оно так и останется "по-другому", выходит.
А ведь правку всего, кроме, пожалуй, независимых РС, можно довольно легко датировать (хранить дату изменения).

*кроме, пожалуй, _удаления из_ независимых РС

(64) Вы считаете менее суровым пытаться разобраться в том, что начудили в момент "факапа" и восстановить это?

(0)
1. Ни в коем случае нельзя сжимать БД (так как тебе тут посоветовали - через SSMS, есть еще другое сжатие, но это отдельная тема). Это увеличивает фрагментацию и приносит кучу других проблем.
2. Лог транзакций не надо уменьшать, нужно чтобы в нем было свободное место чтобы он не рос, для этого надо его регулярно бэкапить.
3. Модель восстановления должна быть Полная, бэкап лога надо делать каждые 15-30 мин. (настрой через Планы обслуживания), в этом случае максимальная потеря данных составит эти же 15-30 мин.
4. Не слушай ЧессМастера, он ламер.

(67) "Модель восстановления должна быть Полная, бэкап лога надо делать каждые 15-30 мин. "
Нафейхоя, если не делается рестор базы из логов?
Кто тут ламер?

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

(69) Бывает, что... если админ базы даёт юзверям права на запуск всяких обработок.... Вот этот админ и есть ламер...

(70) не путай хрен с пальцем...если у тебя сдохнет рэйд, как ты объяснишь потерю данных за целый день?

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

(71) Кстати у нас сдыхал. Добрые электрики запендюрили вместо 220 380 в сеть. Половина серверной накрылась медным тазом вместе с дисковым массивом. Хорошо бекапы хранились даже не на отдельном диске - на другом конце города.

(73) а как они туда доставлялись?

(67)Поздно батенька. Всё сделано по ево.

(74) Волшебная сеть Интернет

(75) ты сейчас сделал большой Косяк

(76) по vpn копируются?

(74) Интернет. Между заводом и офисом широкий канал, а база тогда небольшая была - примерно 5 месяцев работы только. Сейчас не влезет уже :( Ни по деньгам, ни по времени. В другое здание по оптике передается, но это не сильно бы спасло - оба здания на одной подстанции.

(78) Да, криптовался канал. Но потом счета стали приходить конские. Пришлось отказаться.

(78) Не знаю. Предположил.

(77)Да вроде всё фунциклирует штатно

(71) Если у меня сдохнет рейд, я подам заявление по собственному в связи служебным несоответствием
(72) Админ должен сделать так, чтобы не появлялась потребность у пользовтелей куда-то лезть

(82) ЛОЛ, подавай)))

Есть админы 2 типов. Первые не делают бекапы. Вторые уже делают.

(84) Есть еще 3-й тип, которые проверяют бэкапы.

(82) Лучше застрелитесь сразу. Сдохший не вовремя контроллер легко развалит рейд. И хоть брендовый Вы поставьте, хоть китайщину - вопрос только в вероятности наступления данного события. А про 380 в сети см. выше - против лома вообще нет приема.

(82) Да, и что значит "админ должен сделать"? Админ может как-то повлиять на то, что контрагенту квартал отгружали товар не по тому договору и только при сверке это обнаружилось? Что он должен сделать в этой ситуации?

(58) Вы сами себе противоречите

Сначала "Мне неинтересно обсуждать Ваши религиозные фантазии и доказывать, что белое это белое, а черное это черное"

а потом все таки выясняется

"Свежие документы естественно из копии базы"

То есть восстановить бэкап на точку восстановления и все равно переливать документы из резервной копии.

По факту никакой выгоды нет но зато душу греет "у меня где то есть ПОЛНАЯ копия базы данных".

(88) Есть разница перелить 30 документов или 300 документов? Причем 100 документов в текущем периоде, а не 300 в старых периодах?

(58) По факту вы никуда не уйдете от необходимости восстанавливать из резервной копии документы.

При простой модели это будет начиная с утра, при полной начиная с момента косяка до того как его обнаружили.

Ну может на полчаса времени в случае восстановления сэкономите.

Зато затраты на хранение полных копий и логов несравнимы с этой выгодой.

(89) В старом периоде не будет 300 документов.

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

(90) Вы лопатой килобайты грузите? О каких затратах Вы говорите? Гигабайт на HDD стоит 6 центов, гигабайт на SSD стоит 17 центов по данным TrendForce. Час работы одноэсника минимум 25-30 баксов.

(91) Да что Вы докопались до этих прав! Вам легче будет, если главбух это грохнет, установив неправильный отбор?

(92) Одинесник получает фиксированный оклад.

И он получает зарплату за то что может решить определенные проблемы. Никто ему почасовку не считает.

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

(92) Странно что это приходится пояснять.

На хранение бэкапов тратится дисковое место. Чтобы его расширить требуются деньги. Если я пойду к начальству и скажу "дайте мне денег на закупку жестких дисков потому что хочу поменять модель восстановления полную (что приведет к размеру бэкапов в 2-3 раза)" меня спросят обоснование.

На текущем месте работы приходится бэкапы за прошлый год хранить 1 и 15 число месяца. Потому что диск не резиновый.

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

(95) Размер хранимых бэкапов отличается на 5-10%, но не в 2-3 раза. Зависит от глубины по периоду. Один месяц вполне достаточно.

(87) Должен сам внимательно перегрузить документы. А не пускать ТП в базу

(97) ?! А декларацию по налогу на прибыль не сдать еще? А то мало ли бухгалтер нажмет не туда. Бухотчетность заодно, статистику, отчетность в фонды... За кладовщика накладные пооформлять, а то мало ли что ... За мастера смены производственные отчеты...

(94) Вы полагаете, что при "фиксированном окладе" предприятие не несет никаких расходов? Если сотрудник загружен задачами, то лишняя задача отодвигает выполнение остальных запланированных задач в очереди. Не выполненная вовремя задача - потерянные деньги. Если сотрудник сидит и в носу ковыряется в ожидании, когда что-то случится, значит предприятие зря ему выплачивает зарплату.

(98) "А декларацию по налогу на прибыль не сдать еще? А то мало ли бухгалтер нажмет не туда."
Это проблемы буха. А вот лить данные из внешних источников - это дело 1сника. И не фиг в это лезть гряз^W бухгалтерскими руками.

(99) В каком момент про заливку из внешних источников речь пошла? Вроде только про групповые обработки было.

(66) Э, ну смотря что за факап.
Вообще Я лишь предлагал не ограничиваться только лишь откатом на момент "до факапа": если факап заключался в массовом изменении, то обычно это изменение какого-то одного или нескольких определенных (и известных) типов объектов метаданных. Остальные же объекты БД, "нетронутые" факапом, но тронутые регулярной работой пользователей уже после "факапа", легко можно восстановить (по дате изменения). Хранение дат изменения - копеечная работа для разработчика, а пользователям приятно :)

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