Экспорт и импорт выбранных строк в базе данных

Question

Допустим, у меня есть такая база данных:

Users
-----
ID int PK Identity
Name vchar(max)

Sales
-----
UserID int FK
Description vchar(max)

И некоторые данные:

Users
1, "Daniel"
2, "Barnie"
3, "Frank"

Sales
2, "New computer"
2, "Rubber duck"
3, "Cabbage"

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

Вопросы: 1) Есть ли способ создать файл .bak, используя только частичные данные? Я не хочу делать резервную копию всего этого, только выбранные записи. 2) Если .bak файлы не лучший способ, что еще можно сделать? Я думал о создании файла CSV или сценария INSERT SQL, но это приводит к проблемам в функции импорта. Проблема возникает, когда вы экспортировали из двух или более баз данных, и теперь у вас есть потенциальные конфликты в первичном ключе для таблицы пользователей. Как вы справляетесь с этим? Я также использую потоковую передачу файлов в некоторых таблицах, поэтому у меня есть некоторые данные, которые нельзя легко вывести в текстовый формат.

Я также хотел бы сделать все это программно. Использование SQL Server 2008.

Answer 1

Вы можете использовать разбиение для разделения данных между разными файловыми группами или разными серверами.Затем вы можете выбрать способ резервного копирования каждого раздела, применяя различные расписания резервного копирования к файловым группам / серверам.

Но в целом хранилище в наши дни очень дешевое.Если вы действительно не знаете, что это будет стоить, я бы просто сделал резервную копию всего.Чем сложнее система резервного копирования, тем более подвержены сбоям и затраты на несколько гигабайт не будут равны стоимости потери всех данных!

Answer 2

Вопросы: 1) Есть ли способ создать файл .bak, используя только частичные данные?Я не хочу делать резервную копию всего этого, только выбранные записи.

Нет.В SQL Server функция резервного копирования будет выполнять резервное копирование только всей базы данных.

2) Если файлы .bak не лучший способ, что еще можно сделать?

Я бы рекомендовал настроить вторую архивную базу данных на том же сервере, что и исходный, и использовать репликацию для синхронизации только определенных записей.Тогда я бы только сделал резервную копию архивной базы данных (или обеих, но по разным графикам).

Если репликация вам не по вкусу водки, то вы могли бы даже выполнить запуск или удалить в этой архивной базе данных.

Я думал о создании файла CSV или сценария INSERT SQL, но это приводит к проблемам в функции импорта.Проблема возникает, когда вы экспортировали из двух или более баз данных, и теперь у вас есть потенциальные конфликты в первичном ключе для таблицы пользователей.Как вы справляетесь с этим?Я также использую потоковую передачу файлов в некоторых таблицах, поэтому у меня есть некоторые данные, которые нельзя легко вывести в текстовый формат.

Это ситуация с несколькими арендаторами?Независимо от этого, для каждой базы данных я бы создал вторую архивную базу данных, которая использовалась бы для резервного копирования информации, которая действительно требовалась.Таким образом, никакие две базы данных не будут поданы в одну и ту же фильтрованную архивную базу данных.

Answer 3

Относительно простой вариант - заполнить таблицу пользователями, для которых требуется создать резервную копию, создать другую БД на том же экземпляре сервера для архивированных пользователей, а затем сделать выбор в новой БД (очевидно, сначала таблица пользователей).Удалите из старой БД, где существуют значения в новой БД, создайте резервную копию новой БД, и вы получите золотой.

Answer 4

Другая возможность - использовать SSIS с пользовательскими операторами выбора и выводами необработанных данных. Содержимое будет очень быстро импортировать и экспортировать в собственном формате, получая при этом именно те записи, которые вы хотите. Кроме того, вы можете запустить сжатие файлов после экспорта или запустить файловые команды для их перемещения.

Answer 5

Я бы применил обобщенный подход к архивированию этой проблемы:

• Создать центральную базу данных со всеми схемы для всех таблиц, которые вам нужны на экспорт

Так как вы хотите сохранить Данные файлового потока, я не вижу, как .csv или BCP файлы могут быть использованы. Плюс это вписывается в идею, которую вы упомянули о имея одну гигантскую базу данных для накапливать информацию.

• Для каждой таблицы добавьте новый столбец называется DbName.

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

• Создать хранимую процедуру, которая будет загрузить необходимые данные в новый базу данных и удалить ее одновременно время (или хотя бы отметка для удаления).

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

Answer 6

А как насчет этой идеи:

• Создание таблиц резервных копий для каждой связанной таблицы, которую вы хотите сделать резервную копию.
• С помощью простого запроса заполните эти таблицы (вы просто выберете данные, относящиеся кпользователи, которым требуется резервная копия)
• Простой триггер для каждой соответствующей таблицы (добавление или обновление) для синхронизации таблиц резервного копирования.
• Теперь вы можете экспортировать резервную копию из этой новой таблицы
• Для восстановления данных используйте insert ignore.

Это просто идея, давайте критикуем:)

Answer 7

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