Есть база Торговля в 8.2 sql. Сейчас стоит FULL. Делал шринк лога, при фулл не получилось. Перевел в Симпл, сработало
Могу оставить ее в этом режиме? Или каждый раз прыгать туда - сюда?
У кого как стоит и что посоветуете?

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

Емнип, на симпле логшиппинг не делается. Только на фуле

И каждый час выгрузка в dt

График работы 24/7

(110) это издевательство же. юзеров выкидывать каждый час из базы.

(110) dt не гарантирует сохранности данных

Спасибо за ответы - я для себя решил СИМПЛ оставить. База бекапится раз в сутки, бекапов до минут не надо.

(96) тоже плюс. При базах до 50 гб более чем достаточно, как мне кажется.
Использую эту схему.

(111) не, никого не выкидывает
(112) за три года проблем не было ни разу

(115) Успеваете во время регламентированного ежечасового 10-минутного перекура, к которому если не вышел из базы - лишение премии?

бекап 4 раза в сутки,утром полный,если простой это все вешалка,документо оборот до и больше.

(116) неа.. пользователи работают, база бекапится в дт и отправляется на удаленный фтп

(118)выгрузка при работающих пользователях?

(119) типатово

фантастика прям какая-то

(121) http://infostart.ru/public/22419/

(122)молодец

(122) так бы сразу и сказал что из копии выгружаешь

(118) чем это лучше обычного цкульного бэкапа?

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

(18) в обед вообще-то все как раз обедают и отдыхают, или может вы работаете? ))

(126) в общем случае со цкулем и сервером 1с:предприятия, т.к. лимит 4гб/тбл еще никто не отменял.

10 гигов DBF, побыстрее ваших SQL будет

+(128) знаю..
когда то получилось что дт меньше по объему занимал
вот и родилась такая идея

(130) Сама по себе идея с мгновенными снимками заслуживает внимания. Возможно, даже возьму на вооружение. Спасибо.

Если пожать в 7z или rar по окончании процесса, может даже и поменьше dt-шника выйти. Но это уже мелочи.

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

(131) из скульного бэкапа не развернуть базу локально... поэтому тема с дт интересна

У мну FULL каждые 10 минут, т.к. ячеистое хранение. Если база наикнется (не дай бох)..., то даже часовой давности бэкап не поможет. Т.к. рота бойцов бегает по складу с терминалами. Попробуй потом восстанови - чего они там между ячейками наперемещали...

(134) это ты погорячился с фулом каждые 10 минут. делай дифы каждые например 2 часа, и лог журнала каждые 10-15 минут

(131) Насколько я помню, сам снапшот делается моментально. Но с момента создания запись происходит сразу в 2 места, что приводит к более медленной работе.
+ Enterprise - у него более дорогие требования лицензирования, чем у стандарта, например.
+ в 2008 появилась возможность архивировать скулевские бэкапы самим скулем.

Хы!!! Помнится прожжённый SQLщик пяткой в грудь себе стучал за подробные архивы. Оно ж чуть ли не с минутной частотой делается!! Ну настало время Х, навернулся у него супер-пупер надежный рэйд. Навернулся тазом. Медным. Тот с криками "банзай" начал колдовать со своими архивами. Пол дня тъяхался. В конце взял обычную ДТшку, восттановил и бухи начали работать дальше.
Уж я не знаю как оно там сохранялось, но восстанавливая наикрутейшие минутные срезки, получали затыки то в одном месте, то в другом

(137)а чего там колдовать-то ... может там такой-же скульщик как я испанский летчик?

В общем надо держать базу СУБД в симпле, делать периодические бакапы средствами СУБД и раз в сутки переводить один архив в формат 1С, т.е. в DTшку

(138) Фиг знает как, но получалось, что база из портала выходила частично

И целиться надо не на крутейшее восстановление, а на предусмотрение катастрофы.
Спрашивается, нагуя тратить ресурсы железа, если можно просто минимизировать катастрофы? А то сразу возникает вопрос, почему любители крутого восстановления с собой спасательный жилет или круг не носят? Фиг его знает, ведь есть же шанс упасть в холодную воду

Все базы ставлю фулл. В рабочее время бекапы лога каждый час делаются. Все что старше 30 дней - удаляется. Плюс планы обслуживания. Все нормально шринкуется.

+(143) Раз несколько это спасало. Только катастрофы не было. Просто просили сделать копию по состоянию на определенное время.

(28) "Неопытный прог зачистил регистр сведений значения свойств объектов (отбор не установил) на живой базе" - а что неопытный прог делал в живой базе?

(144) Т.е. бухи забыли кто что час назад делал???? С таким самодурством архивы не спасут. Эти зверки найдут методы обвинить восстановленные базы в подтасовке данных. А вот полугодичные данные иногда нужны.

(146) Не час назад. А например - восстановите базу по состоянию на 15:20 среды прошлой недели, чтобы посмотреть - что было в базе на момент предоставления отчета большому боссу :)

(147) А, понял. Это там где все быстро-быстро вертится и персонал иногда косячит, за что получает по шее. Нет, у меня просто все спокойнее. Косяки в журнале регистрации смотрим и этого хватает. А руководители не тянут одеяло на себя и не копаются в мелочевке простолюдинов, они крупными вещами правят и минимальная единица тут месяц.
В общем согласен, конторы разные бывают и порядки формируются тоже разные.

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

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

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

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

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

Кстати, у нас настроен логшиппинг на другой скульный сервачок. В результате, если грохнется основной - запустить рабочую базу можно через 15 минут с потерей данных в 10 минут. А логшиппинг только фулл.

(152) Ок. А потом что? Когда надо восстановить базу на час назад?

(153) А у нас кластер из 1С серверов и СКЛных и мы еще быстрее восстановим работу, если что-то поломается без потери данных вообще.

кто быстрее понеслось,
восстановление базы

(135) ну да, конечно, речь о логе каждые 10 минут

(139) А если база гигов 100 - как ее в dtшку каждые сутки делать?

ни разу еще не понадобилось восстанавливать базу на определенный момент, пользователи рады и базой недельной давности, лишь бы работала.

(142) "Спрашивается, нагуя тратить ресурсы железа, если можно просто минимизировать катастрофы? А то сразу возникает вопрос, почему любители крутого восстановления с собой спасательный жилет или круг не носят? Фиг его знает, ведь есть же шанс упасть в холодную воду"

Ну вот представь. Склад у тя хотя бы 10 тыс ячеек и хотя бы столько же номенклатуры. И база, которая все это дело хранит. И человек 50, которые в эту базу на терминалах фигачат каждую секунду по нескольку транзакций.
И что тебе даст вчерашний simple?
Да ничего... Он будет также полезен, как и архив годичной давности. Т.е. с таким же успехом брякнется в корзину.

(139) переводить это как, извиняюсь? расширение бкп менять на дт? помоему дт имеет смысл при размерах до 1г, дальше он будет восстанавливаться дольше чем руками доки забить

(159)не завидую я твоим пользователям

(160) Симпле мне даст то, что я смогу на каждый момент времени сделать складской отчет и посмотреть инфу по всем складам на любой период. Или так не делают? Отчеты на разный момент времени делают исключительно из бакапов? Хм, надо подумать

(161) Попробуй мир скриптов. На каждый день своя DT-шка без остановки баз

(158) Для таких объёмов, свои подходы. Самое первое - когда покупаю много продуктов в магазине, прошу упаковать в несколько пакетов, а не трамбовать в один, что бы потом не корячиться и не рыдать, пока буду нести

(163)симпл собственно это просто модель восстановления данных ... как он у тебя влияет на то, что ты смотришь в базе?

(164) Вот именно - ни как! Ни симпле, ни фулл, не влияют. А вот на ресурсы это влияет. Поэтому я за маленький размер СУБД, вместо секса с ней

База маленькая до 10 Гб.

Если база большая ну где-нибудь 100 ГБ, то тут без Full сложно будет делать частые архивы ...

У меня SQL Express и маленькая база. Архивирование полное длится минут 5-10 ... да я могу хоть каждый час его запускать, тем более, что полный архив всегда надежнее разностного

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


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

(167) Я понял где горячее, а где холодное. Историю склада я смотрю средствами платформы, а не средствами бэкапов!!!!

В (151) описан случай разгильдяйства, а не штатная ситуация. Если автоматизировать разгильдяйство, то получится полный абзадец. Перво-наперво, надо научиться регламентным операциям и по максимуму их автоматизировать. Да, всякое бывает, но проще предусматривать непонятный развал, нежели лечить.

(163) Про маленькие базы - прирост базы 20 гигов в месяц. Делать новый архив каждый месяц? Или каждый год?
Свертка вещь хорошая, но потом приходит VIP клиент и говорит - мы проходим аудит, а предоставьте мне единый отчет с 01.06.2008 по текущую дату, и начинаешь склеивать отчеты с нескольких баз...

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

(170) Нууу, имхо, за предоставление пользователям права на непосредственное удаление надо бить табуретом.
Другой вопрос, когда покосячили данные и надо их восстановить. Здесь может помочь версионирование, если оно реализовано/включено. Ну или поднимать бэкап

(145) Работал е-мое..
Кто же не косячит?

(169) Я ж говорю, ситуация не из тех, где обсуждается модель СУБД. Тут надо думать про то, на чем вообще это дело должно крутиться. И если 20 гиг в месяц прирост, то... надо работать с ИТ отделом. Это же за год 240 гиг, а за 4 года 960!!!!!
Нет, тут тоже 120-140 гиговый монстр был и доказывали. что это ноухау уникальное во всей вселенной. Утверждали... пока не отказались от уникальности.
Извини, я не против больших объёмов, но 20 гиг в месяц на 1С-е!!!!

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

Обычно хватает бэкапа сделанного раз в сутки. Поэтому

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

(177)причем тут интерактивное удаление?

(171) Ммммм, это интересно, а как можно прокосячить?

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

(163) "Симпле мне даст то, что я смогу на каждый момент времени сделать складской отчет и посмотреть инфу по всем складам на любой период. Или так не делают? Отчеты на разный момент времени делают исключительно из бакапов? Хм, надо подумать "

чевооо? При чем тут бэкап и складской отчет?

так, мои проигрывают, надо поддержать

(175) Журнал регистрации + дописка как и версионирование в УПП + инструкция ответственным лицам. В итоге косячники исчезли как класс, все подобные косяки главбух находит мгновенно.
Стоп, неужели крутейший бэкап лучше будет?

(180) в (183) кратенько описал, как это исключить эволюционно

(183)расскажи мне как в журнале регистрации посмотреть какую строчку удалили из документа?

(181) Ну а тебе то что дает фул? Восстановить базу на 9 сентября в 12:36 по мск. Что увидишь такого удивительного, чего не увижу я?

Симпл. Еженочные копии. На пальцах разложила, мои сказали что в аварийном случае готовы перебить данные за день. Ну и отлично :) Пока аварий не было :)

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

(185) "+ дописка как и версионирование в УПП" я же написал. Там все изменения фиксируются прекрасно. Какая строка была, как её удалили. Все видно. И этим уже давноооо ни кто не пользуется

(186)что было с документом из которого удалили строчку 12:35

(188) Любители твоего метода, тъяхаются с поиском удаленных строк, поддерживающие мои методы, просто не сталкиваются с таким. Когда народ видит, что кара приходит незамедлительно, пропадает желание нечаянно удалять строки. У нас по началу сабботаж был. Мы даже не ругались, просто указывали на косяки. Это первое время и все

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

(190) Я посмотрю в версионировании. Понимаешь? Это будет быстрее, удобнее и без участия ИТ отдела!

(193)блажен тот кто верует ... удачи тебе ... и моли бога что-бы к вам на работу не пришел специалист по отжиму лишних денех у компаний

(192) Жаль, что ты со мной не работаешь. Очень жаль. Особенно жаль, что ты не работаешь на тех местах, где мы создавали инструменты для контроля таких вот "менеджеров" и какие им дела после этого шили

(194) Что ты? Приходят постоянно! Не переживай, они уверенны в себе. Отжимальщик, блин...

(196)к вам приходят чайники ... ну или овцы криворукие ...

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

(197) Не обзывай людей, не зная их. Это так, совет просто

(168) Вот именно.

FULL - есть средство предотвращения непредвиденной ситуации.
Когда по любым ситауциям, кроме аппаратных сбоев на сервере и физического разрушения БД SQL (а это не так легко сделать) есть возможность откатиться на _любой_ момент времени. В т.ч. и за минуту до аварии.
Поэтому (тсссс.... секрет...) после косяков первым делом делают... еще один бюкап лога. И восстанавливают за минуту до этого.

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

При нормальной настройке плана обслуживания никаких проблем с базой нет и снижение производительности несущественно.

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

Кстати, версионирование в УПП _гораздо_ тяжелее FULLа :) и занимает намного больше места.

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

(200) Кстати, самописное версионирование вообще не заметно

(201) Имхо, независимые и очень важные направления.
Надо и принимать действия для уменьшения вероятности поломок. И реализовывать механизмы, позволяющие пережить поломки с минимальными последствиями.

(202) +100500. Да! надо и то и другое.
(201) насчет твоего самописного ничего сказать не могу. А из 230-гиговой базу УПП 72Гб _старых_ данных версионирования вычищал. И после уменьшения количества версионируемых документов (оставил минимально необходимые) по замерам +15% скорости прибавилось.

Я не хочу сказать, что "версионирование - это плохо". Наоборот. Просто это довольно тяжелый инструмент и применять его надо аккуратно.

А "на соседний сервер/в соседнее здание/в соседний город" прекрасно архивируются ранее созданные бэкапы.

(202) Да я не спорю. Чесслово. Просто мы предложили такую концепцию и она прижилась. У нас сильные скульщики. Мы оценили время реакции и шансы получить по шее. Уверяю, ответственные гораздо больше довольны системой отчетов, нежели мальчика, держащего палец на кнопке восстановления. Если бы выбрали упор на бэкапы, то нам пришлось бы в начале кампании дежурить круглосуточно и без выходных.
В общем для бэкапы на самый страшный случай, которого не будет (!!!!!!!!!!). А вот для выявления не честных, анализа прошлых данных и прочих хотелок пользователе, лучше использовать средства платформы.
Это у нас так

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

(205) "Использовать бэкапы для анализа - жесть"

В большинстве случаев - да. Но у них есть одно неоспоримое преимущество: они предоставляют машину времени для всей базы в целом, а не по отдельности для отдельных объектов. Т.е. когда поведение системы изменилось, и не сразу ясно почему - надо еще найти "в каком объекте произошли изменения". И версионирование тут слабый помощник.

Правда, чаще всего для этого хватит и более древнего бэкапа.
Но ситуации, когда его мало - вполне возможны.

(205) ты сейчас нахаляву рассказываешь решения, которые стоят денег. Нафига?