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

@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 09.04.2026 Алгоритм из решения ниже применим как для типовых, так и для нетиповых документов на самых различных конфигурациях. Задача: при копировании документа очищать определенные реквизиты и табличную. . .	модель ЗдравоСохранения 8. Подготовка к разному выполнению заданий anaschu 08.04.2026 https:/ / github. com/ shumilovas/ med2. git main ветка * содержимое блока дэлэй из старой модели теперь внутри зайца новой модели 8ATzM_2aurI	Блокировка документа от изменений, если он открыт у другого пользователя Maks 08.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в конфигурации КА2. Задача: запретить редактирование документа, если он открыт у другого пользователя. / / . . .	Система безопасности+живучести для сервера-слоя интернета (сети). Двойная привязка. Hrethgir 08.04.2026 Далее были размышления о системе безопасности. Сообщения с наклонным текстом - мои. А как нам будет можно проверить, что ссылка наша, а не подделана хулиганами, которая выбросит на другую ветку и. . .
Модель ЗдрввоСохранения 7: больше работников, больше ресурсов. anaschu 08.04.2026 работников и заданий может быть сколько угодно, но настроено всё так, что используется пока что только 20% kYBz3eJf3jQ	Дальние перспективы сервера - слоя сети с космологическим дизайном интефейса карты и логики. Hrethgir 07.04.2026 Дальнейшее ближайшее планирование вывело к размышлениям над дальними перспективами. И вот тут может быть даже будут нужны оценки специалистов, так как в дальних перспективах всё может очень сильно. . .	Горе от ума kumehtar 07.04.2026 Эта мне ментальная установка, что вот прямо сейчас, мол, мне для полного счастья не хватает (нужное вписать), и когда я этого достигну - тогда и полный кайф. Одна из самых сильных ловушек на пути. . . .	Использование значений реквизитов справочника в документе, с определенными условиями и правами Maks 07.04.2026 1. Контроль срока действия договора Алгоритм из решения ниже реализован на примере нетипового документа "ЗаявкаНаРаботу", разработанного в конфигурации КА2. Задача: уведомлять пользователя, если. . .

@Аватар 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