Как я могу сделать резервную копию логического подмножества данных в базе данных SQL?

Question

У нас есть клиенты, которые по неприступным причинам не могут использовать встроенные функции резервного копирования SQL Server, поскольку он создает резервные копии всей базы данных. Этим клиентам необходимо разбить и сделать резервную копию базы данных на подмножество тех, кто владеет данными, чтобы соответствующие стороны могли создавать резервные копии своих собственных данных в соответствии со своими собственными правилами. У меня вопрос двоякий:

1. Как бы я сделал что-то подобное?
2. Вас когда-нибудь просили разделить ваши резервные копии следующим образом? Если нет, вас когда-нибудь просили сделать что-то, что, кажется, идет вразрез с отраслевым стандартом? Люди в нашей компании предлагают, чтобы мы / я просто «свернули» свой собственный процесс резервного копирования, который создает резервные копии только необходимых подмножеств данных. Это означает, конечно, что мы / я должны просто «свернуть наш» процесс восстановления. Когда я утверждаю, что это определение переизобретения колеса и часть того, почему мы в первую очередь выбрали SQL Server, у меня возникает ощущение, что они думают, что я технический сноб и / или ленивый.

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

Обновление: Наконец-то я нашел способ реализовать это, создав резервную копию «полной» базы данных с помощью SMO, восстановив резервную копию и удалив из резервной копии записи, которые не являются частью подмножества. Я очень разочарован, обнаружив, что это привело к увеличению журнала транзакций до 5 ГБ в течение 5 минут. Кажется, что создание пустой базы данных и вставка будет проще, но как мне реплицировать схему без статического сценария, который необходимо обновлять при обновлении базы данных?

Answer 1

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

Без рассмотрения рассматриваемой базы данных трудно дать указания, почему это плохая идея. Но некоторые сразу приходят на ум:

1. Потеря резервной копии журнала транзакций.

2. Автоинкрементные идентификаторы не любят вставлять «пропущенные» записи вручную, а отключение функции IDENT и / или ограничений во время вставки просто вызывает проблемы ссылочной целостности.

3. А как насчет общих данных? Существуют ли какие-либо таблицы для нескольких клиентов? Что происходит, когда эти данные изменяются со временем ... где вы будете получать последнюю резервную копию только для этих данных? И как это повлияет на других клиентов, живущих в той же базе данных?

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

5. Что происходит при изменении схемы? Если вы выполняете резервное копирование всех этих данных в виде отдельных вставок, они больше не будут работать как есть, без сопоставления резервных копий схем.

Есть множество вещей, которые нужно учитывать. Лично, если бы я был ими, я бы начал с одной резервной копии всей базы данных SQL Server (еще лучше, разделив их клиентов на разные базы данных вместо того, чтобы все они разделяли одну большую базу данных), ежедневно создавая различия (или любой график, который лучше соответствует их потребностям). Затем, в качестве дополнительной услуги, они могли бы предложить какой-то метод экспорта и импорта данных, будь то через XML, CSV, что угодно. Разрешить клиентам выполнять резервное копирование своих данных с помощью экспорта, и при необходимости они могут в любое время повторно импортировать его, что позволяет проводить повторную проверку и т. Д.

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

Наконец, что не менее важно, могут быть инструменты, которые подойдут для работы. Red Gate предлагает множество отличных инструментов SQL Server, таких как SQL Server Compare, Data Compare и их собственные приложения резервного копирования. Несмотря на это, я бы использовал их в качестве крайней меры ...

http://www.red -gate.com /

Answer 2

Короткий ответ: нет собственного способа справиться с этим.

Более длинный ответ: если вы создали новую базу данных только с помощью схемы, а затем загрузили данные о клиентах из основной базы данных, вы могли бы затем сделать резервную копию базы данных меньшего размера в одном файле резервной копии и передать его им.

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

Answer 3

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

Я бы назвал это «Экспорт» и «Импорт» данных, а не «резервная копия». Но это игра слов. Мы много занимаемся этим видом экспорта в некоторых наших системах.

В разделе «Как» мне нужно больше информации, хотят ли они экспортировать ее на другой сервер, на тот же сервер, но на другую базу данных, или на что-то еще?

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

Редактировать: Ответить на комментарий:
В большинстве случаев мы удаляем существующую subsetdb, а затем восстанавливаем пустой db и заполняем его отфильтрованными данными. Другой способ - просто создать полную резервную копию, восстановить как новую базу данных и удалить строки, не входящие в подмножество.

Я предполагаю, что subsetdb - это больше "только для чтения" -db со статистическими данными, поэтому вам не нужно беспокоиться о записи изменений и т. Д.

Answer 4

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

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

Answer 5

У вас есть возможность создания нескольких баз данных? Возможно, вы сможете найти решение, в котором одна «центральная» база данных содержит представления, которые эффективно объединяют таблицы других баз данных. Я знаю, что некоторые приложения веб-фильтрации делают это, конечно, они не делают обновления таким образом. Но это может быть работоспособным. И в этом случае каждая база данных может быть зарезервирована с использованием собственных средств.