Автоматизация копирования таблиц

@c0rvax · Регистрация: 02.07.2013

Студворк — интернет-сервис помощи студентам

MSSQL2008. Два сервера. Надо все таблицы с одного периодически копировать на другой. Решение в лоб

SQL
1
2
DELETE FROM Server2.DBName.dbo.TableName1
INSERT INTO Server2.DBName.dbo.TableName1 SELECT * FROM Server1.DBName.dbo.TableName1

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

Т.е., очень бы хотелось сделать так:
1) определить список таблиц
2) с каждой проделать выше написанное, причём так, чтобы несуществующая таблица создалась
3) и совсем идеально было бы копировать только то содержимое, что новое, всё старое оставалось, а неиспользуемое старое удалялось.

Естественно, всё должно работать без всякой интерактивности, чтобы даже никто не догадывался, что там что-то вообще работает.

@Аватар · 18.11.2013, 20:21

backup restore не подходит?

@c0rvax · 18.11.2013, 20:32 **[ТС]**

Аватар, может и подойдёт, но, во-первых, я не знаю, как это реализовать командами скрипта. А во-вторых, не уверен, в каких именно файлах размещена база на другом сервере. Не хотелось бы плодить кучу объёмных, неиспользуемых mdf, если вдруг не совпадут имена файлов. Ну и в-третьих, бэкап+рестор может вылиться в достаточно долгую по времени операцию, не знаю, будет ли быстрее, чем копировать по-очереди, да ещё и не всё?

@invm · 18.11.2013, 21:03

Сообщение от c0rvax

1) определить список таблиц
2) с каждой проделать выше написанное, причём так, чтобы несуществующая таблица создалась

Репликация моментальных снимков, транзакционная репликация, SSIS-пакет с соответствующей логикой.

Сообщение от c0rvax

я не знаю, как это реализовать командами скрипта.

См. описание инструкций backup и restore.

Сообщение от c0rvax

А во-вторых, не уверен, в каких именно файлах размещена база на другом сервере.

Это совершенно без разницы. Резервное копирование БД - это не копирование ее файлов.

Сообщение от c0rvax

Не хотелось бы плодить кучу объёмных, неиспользуемых mdf, если вдруг не совпадут имена файлов.

Зачем имена файлов должны совпасть?

Сообщение от c0rvax

бэкап+рестор может вылиться в достаточно долгую по времени операцию

У вас БД большого объема?

Сообщение от c0rvax

да ещё и не всё

Тогда, если это критично, см. репликацию и пр.

@c0rvax · 18.11.2013, 21:22 **[ТС]**

invm, я пока что далёк от SQL-философии, поэтому некоторые мои пёрлы могут отдавать ересью, так что заранее прошу прощения. Когда я выполнял рестор из бак-файла, то приходилось вручную править имена файлов БД. Я так понимаю, что пути к ним хранятся в самом бак-файле. Поэтому я и думал, что эти имена на исходной и конечной машинах должны совпасть. БД у меня с десяток-два Гб. Поэтому я и не хотел гонять бэкап, который будет отжирать дополнительное место, а копировать напрямую. К тому же хочу копировать только то, что добавилось, а не всё подряд. Почитаю про всякие страшные слова, спасибо...

@invm · 18.11.2013, 21:45

Сообщение от c0rvax

Когда я выполнял рестор из бак-файла, то приходилось вручную править имена файлов БД. Я так понимаю, что пути к ним хранятся в самом бак-файле.

Хранятся. Но восстановить можно в другое место и дать БД другое имя. Что вы и проделали. Причем заранее создавать пустую БД в нужном месте не обязательно.

Сообщение от c0rvax

Почитаю про всякие страшные слова, спасибо...

Попробуйте начать вот с этого - Репликация моментальных снимков

@c0rvax · 18.11.2013, 21:47 **[ТС]**

invm, как я понял, репликация - это автоматически сгенерированный скрипт, который создаёт такую же БД начиная с create и заканчивая тучей insert? И так для каждой таблицы? Я боюсь, что он будет выполняться ещё дольше, займёт ещё больше места на диске, чем бак, и потом ещё раз по столько будет восстанавливаться...

@invm · 18.11.2013, 22:34

Сообщение от c0rvax

как я понял, репликация - это автоматически сгенерированный скрипт, который создаёт такую же БД начиная с create и заканчивая тучей insert?

Неправильно поняли. Вкратце, для репликации снимков - на издателе формируются скрипты создания таблиц и файлы данных в формате, пригодном для массовой загрузки данных утилитой bcp, все это хозяйство передается подписчику и там применяется.

@_katon_ · 19.11.2013, 01:15

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

@c0rvax · 19.11.2013, 14:59 **[ТС]**

С репликацией повозился и что-то мне взгрустнулось. Много нового, непонятного и, самое главное, нет уверенности. Что-то там началось делаться, пошли ошибки.. Брррр... Поэтому сделал "в лоб" с обходом всех таблиц.

SQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
CREATE PROCEDURE [dbo].[CopyDatabase] @ServerName VARCHAR(50), @DatabaseName VARCHAR(50) AS
 
DECLARE @cursor cursor 
DECLARE @tablename VARCHAR(100)
DECLARE @sqltext VARCHAR(500)
 
SET @sqltext = 'USE ' + @DatabaseName
EXEC(@sqltext)
 
SET @cursor = cursor FOR SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
 
OPEN @cursor
fetch NEXT FROM @cursor INTO @tablename
while @@FETCH_STATUS = 0
BEGIN
    SET @sqltext = 'DELETE FROM ' + @ServerName + '.[' + @DatabaseName + '].[dbo].[' + @tablename + ']'
    EXEC(@sqltext)
    SET @sqltext = 'INSERT INTO ' + @ServerName + '.[' + @DatabaseName + '].[dbo].[' + @tablename +'] SELECT * FROM [' + @tablename + ']'
    EXEC(@sqltext)
    fetch NEXT FROM @cursor INTO @tablename
END;
close @cursor

Пусть непрофессионально, но по крайней мере, тут я уверен в том, что происходит.

Новые блоги и статьи Все статьи Все блоги /
Валидация и контроль данных табличной части документа перед записью Maks 22.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в КА2. Задача: контроль и валидация данных табличной части документа перед записью с учетом регламента компании. . .	Отчёт о затраченных материалах за определенный период с макетом печатной формы Maks 21.04.2026 Отчёт из решения ниже размещён в конфигурации КА2. Задача: разработка отчёта по затраченным материалам за определённый период, с возможностью вывода печатной формы отчёта с шапкой и подвалом. В. . .	Отчёт о спецтехнике находящейся в ремонте Maks 20.04.2026 Отчёт из решения ниже размещен в конфигурации КА2. Задача: отобразить спецтехнику, которая на данный момент находится в ремонте. Есть нетиповой документ "Заявка на ремонт спецтехники" который. . .	Памятка для бота и "визитка" для читателей "Semantic Universe Layer (Слой семантической вселенной)" Hrethgir 19.04.2026 Сгенерировано для краткого описания по случаю сборки и компиляции скелета серверного приложения. И пусть после этого скажут, что статьи сгенерированные AI - туфта и не интересно. И это не реклама -. . .
Запрет удаления строк ТЧ документа при определённом условии Maks 19.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "Аккумуляторы", разработанного в конфигурации КА2. У данного документа есть ТЧ, в которой в зависимости от прав доступа. . .	Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .

@Аватар 5393 / 1465 / 513 Регистрация: 31.05.2012 Сообщений: 5,153
	18.11.2013, 20:21
	backup restore не подходит? 0

@c0rvax 91 / 91 / 22 Регистрация: 02.07.2013 Сообщений: 332
	18.11.2013, 20:32 [ТС]
	Аватар, может и подойдёт, но, во-первых, я не знаю, как это реализовать командами скрипта. А во-вторых, не уверен, в каких именно файлах размещена база на другом сервере. Не хотелось бы плодить кучу объёмных, неиспользуемых mdf, если вдруг не совпадут имена файлов. Ну и в-третьих, бэкап+рестор может вылиться в достаточно долгую по времени операцию, не знаю, будет ли быстрее, чем копировать по-очереди, да ещё и не всё? 0

@c0rvax 91 / 91 / 22 Регистрация: 02.07.2013 Сообщений: 332
	18.11.2013, 21:22 [ТС]
	invm, я пока что далёк от SQL-философии, поэтому некоторые мои пёрлы могут отдавать ересью, так что заранее прошу прощения. Когда я выполнял рестор из бак-файла, то приходилось вручную править имена файлов БД. Я так понимаю, что пути к ним хранятся в самом бак-файле. Поэтому я и думал, что эти имена на исходной и конечной машинах должны совпасть. БД у меня с десяток-два Гб. Поэтому я и не хотел гонять бэкап, который будет отжирать дополнительное место, а копировать напрямую. К тому же хочу копировать только то, что добавилось, а не всё подряд. Почитаю про всякие страшные слова, спасибо... 0

@c0rvax 91 / 91 / 22 Регистрация: 02.07.2013 Сообщений: 332
	18.11.2013, 21:47 [ТС]
	invm, как я понял, репликация - это автоматически сгенерированный скрипт, который создаёт такую же БД начиная с create и заканчивая тучей insert? И так для каждой таблицы? Я боюсь, что он будет выполняться ещё дольше, займёт ещё больше места на диске, чем бак, и потом ещё раз по столько будет восстанавливаться... 0

@_katon_ 414 / 265 / 25 Регистрация: 03.10.2011 Сообщений: 1,094
	19.11.2013, 01:15
	Можно очень редко делать полную резервную копию и часто разностную. - чтобы восстановить базу нужно накатывать все разностные копии + резервное копирование будет происходить очень быстро и незаметно для глаза. 0

Опции темы