Динамическое обновление больше не страшно! Сохранение таблицы Config перед динамическим обновлением

Администрирование - Архивирование (backup)

Обработка для резервного сохранения SQL-таблиц Config b ConfigSave перед динамическим обновлением, а также восстановления этих таблиц в случае сбоя.

Протестировано на релизе 1С:Предприятие 8.3 (8.3.9.2033)

Сделана по мотивам публикации //b1c.ru/public/324751/ 

Отличия:  сделана отдельной обработкой. 

Содержит обычную и управляемую формы. 

Не требует создания процедур на SQL-сервере.  

Требует логина и пароля администратора. 

Перед динамическим обновлением, чтобы не рисковать потерять базу данных (крайне редко, но случается)  копирует таблицы Config и ConfigSave из вашей базы данных в базу master, добавляя к имени таблицы  имя база данных, так как наверняка на вашем SQL-сервере не одна база. 

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

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

Скачать файлы

Наименование Файл Версия Размер
Динамическое обновление больше не страшно! Сохранение таблицы Config перед динамическим обновлением.:
.epf 10,88Kb
09.02.18
23
.epf 1.0 10,88Kb 23 Скачать

См. также

Комментарии
1. Евгений Мадонов (madonov) 157 12.02.18 08:36 Сейчас в теме
Не очень понятно как воспользоваться обработкой для восстановления, если база валится и при запуске в пользовательском режиме.
=============================
Кажется дошло, её можно запустить из под любой другой живой базы.

Как мне кажется минус в том, что требуется делать бэкапы вручную. По любому именно при падении базы и поймешь, что забыл об этом.
Резервное копирование, все таки должно быть автоматическим. И желательно хранить несколько последних копий, а не только крайнюю.

У меня каждые 20 минут на SQL-сервере выполняется задание, которое копирует конфу в специальную базу.
GO
SET ANSI_NULLS ON
GO 
SET QUOTED_IDENTIFIER ON 
GO 

GO 
DECLARE @SQL varchar(8000), @table_name varchar(100)

SET @table_name = '[Conf_Backup].[dbo].[Config_' + LEFT(CONVERT(VARCHAR, GETDATE(), 120), 16) + ']'
SET @table_name = REPLACE(@table_name, '-', '_')
SET @table_name = REPLACE(@table_name, ':', '_')
SET @table_name = REPLACE(@table_name, ' ', '_')

SET @SQL = 'CRE ATE   TABLE '+@table_name+' 
 ( 
[FileName] [nvarchar](128) NOT NULL, 
[Creation] [datetime] NOT NULL, 
[Modified] [datetime] NOT NULL, 
[Attributes] [smallint] NOT NULL, 
[DataSize] [int] NOT NULL, 
[BinaryData] [image] NOT NULL, 
PRIMARY KEY CLUSTERED 
( 
[FileName] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
INS ERT INTO '+@table_name+'  
SEL ECT * FR OM [BUH].[dbo].[Config]'
exec(@SQL)
GO
Показать


Ночью эта база очищается, чтобы не разрасталась:
USE [Conf_Backup]
GO
declare @i int
set @i = 0
while (@i<99)
begin
declare @table_name varchar(100)
declare table_list cursor for
sel ect name fr om sysobjects o2 wh ere xtype='U' and
not exists (
sel ect * fr om sysforeignkeys k
join syscolumns c1 on (k.fkeyid = c1.id and c1.colid=k.fkey)
join syscolumns c2 on (k.rkeyid = c2.id and c2.colid=k.rkey)
wh ere c2.id = o2.id and c1.id <> o2.id
)
open table_list
fetch next from table_list into @table_name
while @@fetch_status = 0
begin
print 'dropping table '+@table_name
exec ('dr op   table '+@table_name)
fetch next fr om table_list into @table_name
end
close table_list
deallocate table_list
set @i = @i+1
end
go
Показать


В случае неудачного демонического обновления база восстанавливается за 30 секунд:
GO 
DR OP   TABLE [BUH].[dbo].[Config] 
GO 
SET ANSI_NULLS ON 
GO 
SE T QUOTED_IDENTIFIER ON 
GO 
CRE ATE   TABLE [BUH].[dbo].[Config]( 
[FileName] [nvarchar](128) NOT NULL, 
[Creation] [datetime] NOT NULL, 
[Modified] [datetime] NOT NULL, 
[Attributes] [smallint] NOT NULL, 
[DataSize] [int] NOT NULL, 
[BinaryData] [image] NOT NULL, 
PRIMARY KEY CLUSTERED 
( 
[FileName] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] 
GO 
INS ERT INTO [BUH].[dbo].[Config] 
SELE CT * FR OM [Conf_Backup].[dbo].[%ИмяТаблицыСКрайнимБэкапом%] 
GO
Показать


Таким образом получается автоматическое резервное копирование таблицы с конфигурацией каждые 20 минут. Больше 20 минут работы не потеряешь.
Обработка - задумка хорошая, только её бы расширить немного, чтобы умела настраивать на SQL-сервере автоматическое резервное копирование.
cleaner_it; корум; dour-dead; KroVladS; kondrat230386; +5 Ответить
8. vovan_victory vovan_victory (vovan_victory) 55 13.02.18 08:33 Сейчас в теме
(1)А если повести выполнение обработки по расписанию?...
2. Доминант ГК (ingmar) 12.02.18 10:02 Сейчас в теме
Полезно, но я бы ещё добавил возможность доменной авторизации при подключении к SQL серверу, т.к. это секьюрнее и чаще применяется.

Connection.Open("Provider=SQLOLEDB.1; Server="+Сервер+"; Database="+ИмяБазы+"; Trusted_Connection=yes;");
Sergey.Noskov; +1 Ответить
3. Максим Горбачев (Tangram) 130 12.02.18 11:17 Сейчас в теме
я так понимаю, на PostgreSQL не взлетит?
perpleks; Jkey; +2 Ответить
4. Андрей Овсянкин (Evil Beaver) 4738 12.02.18 12:38 Сейчас в теме
По-моему, на ИС уже был автоматический триггер MSSQL, который при начале дин. обновления делал копию автоматически безо всяких "каждый 20 минут" и без ручных действий.
корум; A_Max; madonov; +3 Ответить
7. Евгений Мадонов (madonov) 157 13.02.18 06:53 Сейчас в теме
5. Руслан Ибрагимов (break) 29 12.02.18 12:39 Сейчас в теме
6. Александр Рудницкий (info1i) 23 13.02.18 02:07 Сейчас в теме
Помню, еще несколько лет назад я такое читал, скачал и применял. Похоже, что данная статья - дубль статьи: https://infostart.ru/public/237871/
Могу, конечно, и ошибаться, но так похоже :)
Silenser; +1 Ответить
9. Алексей Соловьев (Silenser) 457 13.02.18 09:33 Сейчас в теме
(6) Конечно копия, изобретение велосипедов - наше все!
10. Александр Рудницкий (info1i) 23 13.02.18 13:20 Сейчас в теме
Пока вспомнил, подскажу важный нюанс: эти две таблицы не всегда спасают. Копировать надо еще таблицу dbschema или db_schema, как-то так.
11. Андрей Хорошулин (dinopopyys) 44 13.02.18 16:03 Сейчас в теме
Насчет "крайне редко" это автор смягчил. Иначе не нужна была обработка!)
12. svk (svk) 14.02.18 11:36 Сейчас в теме
А эта проблема ещё существует разве?? Как-то слышал, что давно побеждена 1с-никами...
13. Алексей Соловьев (Silenser) 457 14.02.18 14:00 Сейчас в теме
Оставьте свое сообщение