|
Вопрос по уменьшению лога транзакций базы. | ☑ | ||
---|---|---|---|---|
0
Косяк
09.04.18
✎
10:58
|
Хочу сделать следующее.
1. Дела архивную копию базы .dt 2. Удаляю базу в ms sql 3. Создаю базу в ms sql 4. Развертываю в ней свой архив .дт Приведет ли это к уменьшению лога транзакций? Подскажите, кто такое уже делал. |
|||
3
Cool_Profi
09.04.18
✎
11:08
|
А каким боком тут лог?
|
|||
4
Волшебник
09.04.18
✎
11:08
|
(0) Сделай Full Backup
|
|||
5
Косяк
09.04.18
✎
11:10
|
||||
6
shuhard
09.04.18
✎
11:11
|
(5) на каком сиквеле, с какой платформой, в какой моде база ?
|
|||
7
Sammo
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
|
модель полная
|
|||
10
Sammo
09.04.18
✎
11:17
|
(9) Тогда переходите на Simple. А если нужна возможность восстановления на любой момент (а не только на момент создания архива), тогда не смотрите на размер файла транзакций.
|
|||
11
shuhard
09.04.18
✎
11:26
|
(0)[Приведет ли это к уменьшению лога транзакций? Подскажите, кто такое уже делал.] да
|
|||
12
shuhard
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С говорят что хранить архивы в ДТ не очень отказоустойчиво |
|||
17
shuhard
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) "Бэкап лог в нул" - вот этого не понял
|
|||
24
SSSSS_AAAAA
09.04.18
✎
11:48
|
(20) А можно узнать для чего так параноидально нужно уменьшить лог? Чего добиться этим хотите? Ускорения работы?
|
|||
25
Мыш
09.04.18
✎
11:49
|
(23) BACKUP LOG TO NUL
Ему же не нужны резервные копии. |
|||
26
cons74
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) Спасибо! Сделано. Журнал стал мизерным, вся пена осела:)
|
|||
36
Sammo
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) Не, конечно можно чесать левое ухо правой ногой через спину, но не проще ли из бекапа поднять на момент действия? Или Вы считаете, что можно остановить на хрен предприятие на несколько часов, пока программер будет извращаться с восстановлением, собирая все из кусков?
|
|||
46
los_hooliganos
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) Мне неинтересно обсуждать Ваши религиозные фантазии и доказывать, что белое это белое, а черное это черное. Фулл-модель восстановления вполне рабочая, несложная в настройке, дает дополнительные возможности по сравнению с симл-моделью и в минусах имеет только необходимость дополнительного дискового пространства, которое по нынешним временам стоит копейки.
|
|||
59
Cyberhawk
09.04.18
✎
13:14
|
(57) А после отката инфобазы кто в ней "наводит красоту"? Например, до отката, но после факапа склад насобирал реализаций, распечатал документацию и отправил машинки?
|
|||
60
Джинн
09.04.18
✎
13:17
|
(59) Свежие документы естественно из копии базы. С последующей верификацией пользователями. Но это а) немного б) все они в текущем периоде.
|
|||
61
Мыш
09.04.18
✎
13:21
|
(58) Мало того, именно фулл-модель рекомендована вендором для рабочих баз. Есть ещё небольшой минус по снижению производительности на некоторых операциях, но в случае с 1С он проявляется редко.
|
|||
62
Cyberhawk
09.04.18
✎
13:23
|
(60) "Свежие" - это с датой создания после факапа или с датой изменения после факапа?
В базе как-то журналируется дата последнено изменения? |
|||
63
Джинн
09.04.18
✎
13:31
|
(62) С датой создания. Для того и последующая верификация пользователями их. Если в старых периодах правили одновременно несколькими способами, то хрен это вообще отследишь.
|
|||
64
Cyberhawk
09.04.18
✎
13:34
|
(63) Сурово - пользователь не заметит что-нибудь, что стало по-другому, и тогда оно так и останется "по-другому", выходит.
А ведь правку всего, кроме, пожалуй, независимых РС, можно довольно легко датировать (хранить дату изменения). |
|||
65
Cyberhawk
09.04.18
✎
13:35
|
*кроме, пожалуй, _удаления из_ независимых РС
|
|||
66
Джинн
09.04.18
✎
13:42
|
(64) Вы считаете менее суровым пытаться разобраться в том, что начудили в момент "факапа" и восстановить это?
|
|||
67
systemstopper
09.04.18
✎
13:43
|
(0)
1. Ни в коем случае нельзя сжимать БД (так как тебе тут посоветовали - через SSMS, есть еще другое сжатие, но это отдельная тема). Это увеличивает фрагментацию и приносит кучу других проблем. 2. Лог транзакций не надо уменьшать, нужно чтобы в нем было свободное место чтобы он не рос, для этого надо его регулярно бэкапить. 3. Модель восстановления должна быть Полная, бэкап лога надо делать каждые 15-30 мин. (настрой через Планы обслуживания), в этом случае максимальная потеря данных составит эти же 15-30 мин. 4. Не слушай ЧессМастера, он ламер. |
|||
68
Cool_Profi
09.04.18
✎
13:48
|
(67) "Модель восстановления должна быть Полная, бэкап лога надо делать каждые 15-30 мин. "
Нафейхоя, если не делается рестор базы из логов? Кто тут ламер? |
|||
69
systemstopper
09.04.18
✎
13:49
|
(68) ну к кого-то не делается, а мне пару раз приходилось ресторить до запуска групповой обработки. Ты тоже ламер.
|
|||
70
Cool_Profi
09.04.18
✎
13:50
|
(69) Бывает, что... если админ базы даёт юзверям права на запуск всяких обработок.... Вот этот админ и есть ламер...
|
|||
71
systemstopper
09.04.18
✎
13:52
|
(70) не путай хрен с пальцем...если у тебя сдохнет рэйд, как ты объяснишь потерю данных за целый день?
|
|||
72
Джинн
09.04.18
✎
13:52
|
(70) Админ сам будет за юзверей подменять что-то в документах, если обнаружилась ошибка?
|
|||
73
Джинн
09.04.18
✎
13:55
|
(71) Кстати у нас сдыхал. Добрые электрики запендюрили вместо 220 380 в сеть. Половина серверной накрылась медным тазом вместе с дисковым массивом. Хорошо бекапы хранились даже не на отдельном диске - на другом конце города.
|
|||
74
systemstopper
09.04.18
✎
13:56
|
(73) а как они туда доставлялись?
|
|||
75
Косяк
09.04.18
✎
13:59
|
(67)Поздно батенька. Всё сделано по ево.
|
|||
76
Мыш
09.04.18
✎
14:02
|
(74) Волшебная сеть Интернет
|
|||
77
systemstopper
09.04.18
✎
14:02
|
(75) ты сейчас сделал большой Косяк
|
|||
78
systemstopper
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)Да вроде всё фунциклирует штатно
|
|||
82
Cool_Profi
09.04.18
✎
14:07
|
(71) Если у меня сдохнет рейд, я подам заявление по собственному в связи служебным несоответствием
(72) Админ должен сделать так, чтобы не появлялась потребность у пользовтелей куда-то лезть |
|||
83
systemstopper
09.04.18
✎
14:10
|
(82) ЛОЛ, подавай)))
|
|||
84
los_hooliganos
09.04.18
✎
14:11
|
Есть админы 2 типов. Первые не делают бекапы. Вторые уже делают.
|
|||
85
systemstopper
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 раза. Зависит от глубины по периоду. Один месяц вполне достаточно.
|
|||
97
Cool_Profi
09.04.18
✎
16:55
|
(87) Должен сам внимательно перегрузить документы. А не пускать ТП в базу
|
|||
98
Джинн
09.04.18
✎
17:03
|
(97) ?! А декларацию по налогу на прибыль не сдать еще? А то мало ли бухгалтер нажмет не туда. Бухотчетность заодно, статистику, отчетность в фонды... За кладовщика накладные пооформлять, а то мало ли что ... За мастера смены производственные отчеты...
(94) Вы полагаете, что при "фиксированном окладе" предприятие не несет никаких расходов? Если сотрудник загружен задачами, то лишняя задача отодвигает выполнение остальных запланированных задач в очереди. Не выполненная вовремя задача - потерянные деньги. Если сотрудник сидит и в носу ковыряется в ожидании, когда что-то случится, значит предприятие зря ему выплачивает зарплату. |
|||
99
Cool_Profi
09.04.18
✎
17:05
|
(98) "А декларацию по налогу на прибыль не сдать еще? А то мало ли бухгалтер нажмет не туда."
Это проблемы буха. А вот лить данные из внешних источников - это дело 1сника. И не фиг в это лезть гряз^W бухгалтерскими руками. |
|||
100
Джинн
09.04.18
✎
17:09
|
(99) В каком момент про заливку из внешних источников речь пошла? Вроде только про групповые обработки было.
|
|||
101
Cyberhawk
09.04.18
✎
17:10
|
(66) Э, ну смотря что за факап.
Вообще Я лишь предлагал не ограничиваться только лишь откатом на момент "до факапа": если факап заключался в массовом изменении, то обычно это изменение какого-то одного или нескольких определенных (и известных) типов объектов метаданных. Остальные же объекты БД, "нетронутые" факапом, но тронутые регулярной работой пользователей уже после "факапа", легко можно восстановить (по дате изменения). Хранение дат изменения - копеечная работа для разработчика, а пользователям приятно :) |
|||
102
Джинн
09.04.18
✎
17:33
|
(101) В любом случае это дополнительная фишка ко всему тому, что Вы смогли бы сделать без наличия такого бекапа. Больше возможностей при минимальных затратах.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |