Вход | Регистрация

  1  2   
1С:Предприятие :: 1С:Предприятие 8 общая

Вопрос по уменьшению лога транзакций базы.

Вопрос по уменьшению лога транзакций базы.
Я
   Косяк
 
09.04.18 - 10:58
Хочу сделать следующее.

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

Приведет ли это к уменьшению лога транзакций? Подскажите, кто такое уже делал.
 
 
   Cyberhawk
 
1 - 09.04.18 - 10:58
Зачем?
   assasu
 
2 - 09.04.18 - 11:08
(0) надо книжки почитать по скл. пока что есть вообще не годится, никто такое не делал
   Cool_Profi
 
3 - 09.04.18 - 11:08
А каким боком тут лог?
   Волшебник
 
4 - 09.04.18 - 11:08
(0) Сделай Full Backup
   Косяк
 
5 - 09.04.18 - 11:10
Сделал вот так  http://catalog.mista.ru/public/168314/

ничего не изменилось
   shuhard
 
6 - 09.04.18 - 11:11
(5) на каком сиквеле, с какой платформой, в какой моде база ?
   Sammo
 
7 - 09.04.18 - 11:13
1. Зачем?
2. Какая модель восстановления базы? Full или Simple
   Косяк
 
8 - 09.04.18 - 11:13
ms sql 2012

ЗУП, ERP
   Косяк
 
9 - 09.04.18 - 11:13
модель полная
   Sammo
 
10 - 09.04.18 - 11:17
(9) Тогда переходите на Simple. А если нужна возможность восстановления на любой момент (а не только на момент создания архива), тогда не смотрите на размер файла транзакций.
 
 Рекламное место пустует
   shuhard
 
11 - 09.04.18 - 11:26
(0)[Приведет ли это к уменьшению лога транзакций? Подскажите, кто такое уже делал.] да
   shuhard
 
12 - 09.04.18 - 11:27
(8) кроме бэкапа базы нужен бэкап журнала
   Карст
 
13 - 09.04.18 - 11:28
смысл хранить логи журнала - очень специфический , лучше чаще бэкапить
   Косяк
 
14 - 09.04.18 - 11:30
(13) каждую ночь бэкап создается
   Косяк
 
15 - 09.04.18 - 11:32
(12)Не совсем вас понял. Если есть .дт, то какая разница
   Карст
 
16 - 09.04.18 - 11:33
(14) скульный бэкап можно делать с работающей базы средствами SQL , максимум - что будет - тормоза на время бэкапа , так что хоть каждый час  (ну и если поставить модель simple в базе) то лог авторезаться будет и расти так не будет
(15) сами 1С говорят что хранить архивы в ДТ не очень отказоустойчиво
   shuhard
 
17 - 09.04.18 - 11:38
(15) если нужно убить базу, то ни какой
   Косяк
 
18 - 09.04.18 - 11:39
(17) Что значит убить. Я предварительно сделаю бэкапы в ms sql и dt
   Мыш
 
19 - 09.04.18 - 11:41
(18) DT не для бэкапов.
   Косяк
 
20 - 09.04.18 - 11:42
(16)Если я поставлю простую модель, то лог уменьшится? Останется таким как есть?
   Мыш
 
21 - 09.04.18 - 11:43
(20) Не уменьшится. Останется, как есть.
Бэкап лог в нул, шринк. Повторить два раза.
   Карст
 
22 - 09.04.18 - 11:44
(20) советую почитать азы по работе с 1С + SQL администрирование , в инете полно информации
   Косяк
 
23 - 09.04.18 - 11:45
(21) "Бэкап лог в нул" - вот этого не понял
   SSSSS_AAAAA
 
24 - 09.04.18 - 11:48
(20) А можно узнать для чего так параноидально нужно уменьшить лог? Чего добиться этим хотите? Ускорения работы?
   Мыш
 
25 - 09.04.18 - 11:49
(23) BACKUP LOG TO NUL
Ему же не нужны резервные копии.
   cons74
 
26 - 09.04.18 - 11:55
(0) Хороший ник, веселая затея. Пошел за попкорном.
   ЧессМастер
 
27 - 09.04.18 - 12:00
(0) Поставьте модель восстановления Simple и не усложняйте себе жизнь. При ежедневных бэкапах баз полная модель восстановления не нужна потому что вы никогда не будете откатывать базу по журналу транзакций на определенное время. Гораздо проще взять испорченный документ из архивной базы и перегрузить
   ЧессМастер
 
28 - 09.04.18 - 12:00
(24) Лог может быть очень большим. Когда баз много то место на диске может закончиться.
   Косяк
 
29 - 09.04.18 - 12:01
(27) Убедили.
   ЧессМастер
 
30 - 09.04.18 - 12:02
(0) И для того чтобы уменьшить лог нужно всего лишь сделать
в SQL Server Management Studio на нужной базе

Задачи - Сжать - Базу
   Мыш
 
31 - 09.04.18 - 12:02
(27) Случаи бывают разные. Иногда на определенное время нужно поднять. Но в данном случае соглашусь. Только симпл.
   ЧессМастер
 
32 - 09.04.18 - 12:03
+(30) Причем это можно делать даже на работающей базе.

Удалять базу и создавать ее для этого не нужно
   ЧессМастер
 
33 - 09.04.18 - 12:06
(31) Единственный пример который приходит в голову пользы полной модели восстановления - какие-то разбирательства на тему "кто сделал эту операцию в базе и какое было ее состояние перед выпиской документа".

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

А в других случаях полная модель восстановления бесполезна.
Никто не будет откатывать базу назад по состоянию на какой-то момент времени из-за одной ошибки.
 
 
   Мыш
 
34 - 09.04.18 - 12:08
(33) Не обязательно откатывать. Поднять копию по состоянию на эн часов, эм минут.
   Косяк
 
35 - 09.04.18 - 12:09
(30) Спасибо! Сделано. Журнал стал мизерным, вся пена осела:)
   Sammo
 
36 - 09.04.18 - 12:09
(33) Не надо быть категоричным. Случаи бывают разные. И базы бывают разные. При нескольких сотен тысяч операций в день возможность восстановить на конкретный период может сэкономить время и нервы. Например.
Хотя я соглашусь, что для подавляющего большинства 1с-баз обычно достаточно симпла.
   ЧессМастер
 
37 - 09.04.18 - 12:11
(34) Ну да я про это и написал в (33)
Но это очень редко нужно бывает.
Только если конфликты возникли "а ктоооо это сделал ???"
   Мыш
 
38 - 09.04.18 - 12:13
(37) В (36) привели еще вариант. Никогда не говори "никогда" )
   ЧессМастер
 
39 - 09.04.18 - 12:15
(36) Конечно если очень много операций то нужна полная модель. Но в таком случае и деньги хорошие выделают на хранение бэкапов.
   Джинн
 
40 - 09.04.18 - 12:16
(27) Это пока какой-то умник групповой обработкой не снесет полбазы.
   ЧессМастер
 
41 - 09.04.18 - 12:21
(40) При групповой обработке восстанавливается копия базы на утро и переливаются документы сделанные за день.

Получить список измененных документов по журналу регистрации не составляет большого труда.
   Джинн
 
42 - 09.04.18 - 12:22
(41) Переливаются откуда?
   ЧессМастер
 
43 - 09.04.18 - 12:22
(40) А самое главное - отбить руки тому кто дал в руки пользователей групповые обработки.

Это инструмент исключительно программиста.
   ЧессМастер
 
44 - 09.04.18 - 12:24
(42) Делается копия рабочей базы.

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

В рабочую базу из копии переливаются измененные документы.
Список измененных документов получается из журнала регистрации рабочей базы.
   Джинн
 
45 - 09.04.18 - 12:30
(44) Не, конечно можно чесать левое ухо правой ногой через спину, но не проще ли из бекапа поднять на момент действия? Или Вы считаете, что можно остановить на хрен предприятие на несколько часов, пока программер будет извращаться с восстановлением, собирая все из кусков?
   los_hooliganos
 
46 - 09.04.18 - 12:33
(45) Восстановление по журналу транзакций тоже займет часы.
Вернее всего, при такой необходимости, делать разностные бекапы.
   ЧессМастер
 
47 - 09.04.18 - 12:39
(45) "Вы считаете, что можно остановить на хрен предприятие на несколько часов, пока программер будет извращаться с восстановлением, собирая все из кусков"

Да можно.

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

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

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

База может не работать так же пару часов например из за отключения света.
   Джинн
 
48 - 09.04.18 - 12:39
(46) Отнюдь. Все проходит достаточно быстро. И разностные бекапы делаются тоже. Одно другому не мешает.
   ЧессМастер
 
49 - 09.04.18 - 12:41
(47) И это не программер будет извращаться. Программеру квалификация не даст сделать то что положит нахрен базу предприятия. Это надо быть реально криворуким дебилом и не тестировать обработку на копии перед запуском на реальной базе.
 
 Рекламное место пустует
   Джинн
 
50 - 09.04.18 - 12:43
(47) У нас за пару часов в сезон отгружается 12 фур. И оплата услуг транспортной компании примерно 800 руб. в час. Если фура не доедет до покупателя до конца суток, то в зависимости от условий договора возможен еще и нехилый штраф от суммы заказа. Вот такая вот математика.
   ЧессМастер
 
51 - 09.04.18 - 12:50
(50) Если один раз высчитать из зарплаты того кто положил базу эту сумму он быстро научится тестировать то что написал на копии рабочей базы.

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

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

Ошибка произошла в 12 часов, выявили ее в 13 часов. За чам выписали 50 счетов фактур и поменяли по 20 реализациям статус с "Собирается" на "Отгружен". Ваши действия ? Откатывать базу по состоянию на 12 часов ?
   Мыш
 
52 - 09.04.18 - 12:53
(51) Чем откат на 12 часов хуже отката на 9 часов?
   Джинн
 
53 - 09.04.18 - 12:57
(51) Причем тут тестирование и разработчик? Есть вполне обычные групповые обработки прямо в конфигурации. Есть полно всяких восстановлений последовательностей, которые запущенные в неправильном периоде хотя бы на копейки, но порвут учет в сданном периоде. Есть пользователи, которые думают что они что-то исправляют, а на самом деле не понимают какие последствия будут. Есть умники, которым плевать на регламенты и руководства и которые "А вот у нас в Газпроме программеры говорили, что так делать можно!". Что Вы уперлись в программера?

На хрена при наличии готового, штатного, работающего и проверенного механизма городить какой-то религиозный огород? Только потому, что админ не усилил мануал по настройке бекапа?
   ЧессМастер
 
54 - 09.04.18 - 13:01
(53) Групповые обработки у обычных пользователей которые не понимают что они ими могут сделать должны быть запрещены.

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

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

Ваш способ с откатом базы на точку когда ошибка  возникла не решает вопроса как повторить в базе изменения которые сбыли сделаны между временем ошибки и временем ее восстановления
   Мыш
 
55 - 09.04.18 - 13:01
(53) Симпл неистребим. Наблюдаю данное явление лет 15. Есть подозрение, что это происходит всю историю скуля. Вопросы "как уменьшить лог" возникают с завидной регулярностью.
   ЧессМастер
 
56 - 09.04.18 - 13:05
(53) У меня на прошлом месте работы была ситуация - пользователь уровня финансового директора (которая была выше главбуха) постоянно генерировала проблемы в прошлых периодах. Причем организационными способами (это к  вашему  
"Есть умники, которым плевать на регламенты и руководства") решить этот вопрос было нельзя - жаловаться на нее нельзя, запретить ей изменять в прошлых периодах нельзя). Решение было найдено - копия базы и перелив измененных ей документов.

Но при этом никому в голову не приходило дать ей механизм по массовому изменению документов.
   Джинн
 
57 - 09.04.18 - 13:06
(54) "Мой способ" при отсутствии вообще каких-либо трудозатрат по поддержанию бекапов позволяет кардинально сократить время простоя и трудозатраты по восстановлению базы в исходное состояние. Хотя реально он не мой, а Мелкософта.

А должности у умников достаточные, чтобы окрыть закрытый период. Или Вы считаете, что программер должен за них работать?
   Джинн
 
58 - 09.04.18 - 13:09
(56) Мне неинтересно обсуждать Ваши религиозные фантазии и доказывать, что белое это белое, а черное это черное. Фулл-модель восстановления вполне рабочая, несложная в настройке, дает дополнительные возможности по сравнению с симл-моделью и в минусах имеет только необходимость дополнительного дискового пространства, которое по нынешним временам стоит копейки.
   Cyberhawk
 
59 - 09.04.18 - 13:14
(57) А после отката инфобазы кто в ней "наводит красоту"? Например, до отката, но после факапа склад насобирал реализаций, распечатал документацию и отправил машинки?
   Джинн
 
60 - 09.04.18 - 13:17
(59) Свежие документы естественно из копии базы. С последующей верификацией пользователями. Но это а) немного б) все они в текущем периоде.
   Мыш
 
61 - 09.04.18 - 13:21
(58) Мало того, именно фулл-модель рекомендована вендором для рабочих баз. Есть ещё небольшой минус по снижению производительности на некоторых операциях, но в случае с 1С он проявляется редко.
   Cyberhawk
 
62 - 09.04.18 - 13:23
(60) "Свежие" - это с датой создания после факапа или с датой изменения после факапа?
В базе как-то журналируется дата последнено изменения?
   Джинн
 
63 - 09.04.18 - 13:31
(62) С датой создания. Для того и последующая верификация пользователями их. Если в старых периодах правили одновременно несколькими способами, то хрен это вообще отследишь.
   Cyberhawk
 
64 - 09.04.18 - 13:34
(63) Сурово - пользователь не заметит что-нибудь, что стало по-другому, и тогда оно так и останется "по-другому", выходит.
А ведь правку всего, кроме, пожалуй, независимых РС, можно довольно легко датировать (хранить дату изменения).
   Cyberhawk
 
65 - 09.04.18 - 13:35
*кроме, пожалуй, _удаления из_ независимых РС
   Джинн
 
66 - 09.04.18 - 13:42
(64) Вы считаете менее суровым пытаться разобраться в том, что начудили в момент "факапа" и восстановить это?
   systemstopper
 
67 - 09.04.18 - 13:43
(0)
1. Ни в коем случае нельзя сжимать БД (так как тебе тут посоветовали - через SSMS, есть еще другое сжатие, но это отдельная тема). Это увеличивает фрагментацию и приносит кучу других проблем.
2. Лог транзакций не надо уменьшать, нужно чтобы в нем было свободное место чтобы он не рос, для этого надо его регулярно бэкапить.
3. Модель восстановления должна быть Полная, бэкап лога надо делать каждые 15-30 мин. (настрой через Планы обслуживания), в этом случае максимальная потеря данных составит эти же 15-30 мин.
4. Не слушай ЧессМастера, он ламер.
   Cool_Profi
 
68 - 09.04.18 - 13:48
(67) "Модель восстановления должна быть Полная, бэкап лога надо делать каждые 15-30 мин. "
Нафейхоя, если не делается рестор базы из логов?
Кто тут ламер?
   systemstopper
 
69 - 09.04.18 - 13:49
(68) ну к кого-то не делается, а мне пару раз приходилось ресторить до запуска групповой обработки. Ты тоже ламер.
   Cool_Profi
 
70 - 09.04.18 - 13:50
(69) Бывает, что... если админ базы даёт юзверям права на запуск всяких обработок.... Вот этот админ и есть ламер...
   systemstopper
 
71 - 09.04.18 - 13:52
(70) не путай хрен с пальцем...если у тебя сдохнет рэйд, как ты объяснишь потерю данных за целый день?
   Джинн
 
72 - 09.04.18 - 13:52
(70) Админ сам будет за юзверей подменять что-то в документах, если обнаружилась ошибка?
   Джинн
 
73 - 09.04.18 - 13:55
(71) Кстати у нас сдыхал. Добрые электрики запендюрили вместо 220 380 в сеть. Половина серверной накрылась медным тазом вместе с дисковым массивом. Хорошо бекапы хранились даже не на отдельном диске - на другом конце города.
   systemstopper
 
74 - 09.04.18 - 13:56
(73) а как они туда доставлялись?
   Косяк
 
75 - 09.04.18 - 13:59
(67)Поздно батенька. Всё сделано по ево.
   Мыш
 
76 - 09.04.18 - 14:02
(74) Волшебная сеть Интернет
   systemstopper
 
77 - 09.04.18 - 14:02
(75) ты сейчас сделал большой Косяк
   systemstopper
 
78 - 09.04.18 - 14:03
(76) по vpn копируются?
   Джинн
 
79 - 09.04.18 - 14:04
(74) Интернет. Между заводом и офисом широкий канал, а база тогда небольшая была - примерно 5 месяцев работы только. Сейчас не влезет уже :( Ни по деньгам, ни по времени. В другое здание по оптике передается, но это не сильно бы спасло - оба здания на одной подстанции.

(78) Да, криптовался канал. Но потом счета стали приходить конские. Пришлось отказаться.
   Мыш
 
80 - 09.04.18 - 14:04
(78) Не знаю. Предположил.
   Косяк
 
81 - 09.04.18 - 14:06
(77)Да вроде всё фунциклирует штатно
   Cool_Profi
 
82 - 09.04.18 - 14:07
(71) Если у меня сдохнет рейд, я подам заявление по собственному в связи служебным несоответствием
(72) Админ должен сделать так, чтобы не появлялась потребность у пользовтелей куда-то лезть
   systemstopper
 
83 - 09.04.18 - 14:10
(82) ЛОЛ, подавай)))
   los_hooliganos
 
84 - 09.04.18 - 14:11
Есть админы 2 типов. Первые не делают бекапы. Вторые уже делают.
   systemstopper
 
85 - 09.04.18 - 14:12
(84) Есть еще 3-й тип, которые проверяют бэкапы.
   Джинн
 
86 - 09.04.18 - 14:12
(82) Лучше застрелитесь сразу. Сдохший не вовремя контроллер легко развалит рейд. И хоть брендовый Вы поставьте, хоть китайщину - вопрос только в вероятности наступления данного события. А про 380 в сети см. выше - против лома вообще нет приема.
   Джинн
 
87 - 09.04.18 - 14:14
(82) Да, и что значит "админ должен сделать"? Админ может как-то повлиять на то, что контрагенту квартал отгружали товар не по тому договору и только при сверке это обнаружилось? Что он должен сделать в этой ситуации?
   ЧессМастер
 
88 - 09.04.18 - 15:19
(58) Вы сами себе противоречите
Сначала "Мне неинтересно обсуждать Ваши религиозные фантазии и доказывать, что белое это белое, а черное это черное"

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

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

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

По факту никакой выгоды нет но зато душу греет "у меня где то есть ПОЛНАЯ копия базы данных".
   Джинн
 
89 - 09.04.18 - 15:21
(88) Есть разница перелить 30 документов или 300 документов? Причем 100 документов в текущем периоде, а не 300 в старых периодах?
   ЧессМастер
 
90 - 09.04.18 - 15:22
(58) По факту вы никуда не уйдете от необходимости восстанавливать из резервной копии документы.

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

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

Зато затраты на хранение полных копий и логов несравнимы с этой выгодой.
   ЧессМастер
 
91 - 09.04.18 - 15:24
(89) В старом периоде не будет 300 документов.

Если вы даете всем подряд пользователям права запускать обработки по групповому изменению документов и только ради этого держите полную модель восстановления то это явно неоптимальное решение.
   Джинн
 
92 - 09.04.18 - 15:27
(90) Вы лопатой килобайты грузите? О каких затратах Вы говорите? Гигабайт на HDD стоит 6 центов, гигабайт на SSD стоит 17 центов по данным TrendForce. Час работы одноэсника минимум 25-30 баксов.
   Джинн
 
93 - 09.04.18 - 15:29
(91) Да что Вы докопались до этих прав! Вам легче будет, если главбух это грохнет, установив неправильный отбор?
   ЧессМастер
 
94 - 09.04.18 - 16:24
(92) Одинесник получает фиксированный оклад.

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

Уволить штатного программиста и перейти на обслуживание франча выходит в несколько раз дороже.
   ЧессМастер
 
95 - 09.04.18 - 16:28
(92) Странно что это приходится пояснять.

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

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

Если я скажу "а вдруг главный бухгалтер запустит обработку и ляжет база" на меня посмотрят как на идиота.
   Мыш
 
96 - 09.04.18 - 16:53
(95) Размер хранимых бэкапов отличается на 5-10%, но не в 2-3 раза. Зависит от глубины по периоду. Один месяц вполне достаточно.
   Cool_Profi
 
97 - 09.04.18 - 16:55
(87) Должен сам внимательно перегрузить документы. А не пускать ТП в базу
   Джинн
 
98 - 09.04.18 - 17:03
(97) ?! А декларацию по налогу на прибыль не сдать еще? А то мало ли бухгалтер нажмет не туда. Бухотчетность заодно, статистику, отчетность в фонды... За кладовщика накладные пооформлять, а то мало ли что ... За мастера смены производственные отчеты...

(94) Вы полагаете, что при "фиксированном окладе" предприятие не несет никаких расходов? Если сотрудник загружен задачами, то лишняя задача отодвигает выполнение остальных запланированных задач в очереди. Не выполненная вовремя задача - потерянные деньги. Если сотрудник сидит и в носу ковыряется в ожидании, когда что-то случится, значит предприятие зря ему выплачивает зарплату.
   Cool_Profi
 
99 - 09.04.18 - 17:05
(98) "А декларацию по налогу на прибыль не сдать еще? А то мало ли бухгалтер нажмет не туда."
Это проблемы буха. А вот лить данные из внешних источников - это дело 1сника. И не фиг в это лезть гряз^W бухгалтерскими руками.
   Джинн
 
100 - 09.04.18 - 17:09
(99) В каком момент про заливку из внешних источников речь пошла? Вроде только про групповые обработки было.
  1  2   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует