Нужна 10% копия моей базы данных SQL Server для разработки

Question

Я хотел бы взять 10% -ную копию данных в производственной базе данных, сохранить ее целостность и восстановить ее в новой базе данных.

Есть ли способ, который позволяет это сделать в SQL Server? Я рассмотрел создание служб SSIS, которые экспортируют схему и данные базы данных, а затем поставил задачу выборки строк, чтобы уменьшить объем данных, поступающих в новую базу данных, но мне было интересно, есть ли лучший способ сделать это?

Answer 1

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

Во-первых, я знаю, что Data Bee подразделяет базы данных, но этого может быть недостаточно для вас. Вы можете использовать пробную версию этого, чтобы увидеть, работает ли он.

Во-вторых, я обычно рекомендую вам получить набор данных для областей разработки (dev, test, UAT и т. Д.), Который содержит примеры проблемных областей, которые вам необходимо решить. Есть два способа сделать это. Одним из них является программное обеспечение для виртуализации данных, которое Redgate использует в SQL Clone, Delphix в своих продуктах и ​​некоторые другие. Это, по сути, копирует производство один раз, а затем передает его всем разработчикам / qa / etc. Это уменьшает большую часть времени / хранилища, необходимого для получения копий. Это может помочь.

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

Если вы работаете в ипотеке, как отмечает HoneyBadger, вам, возможно, придется учитывать фиксированные кредиты, переменные APR, различные условия и т. Д. Часто самый простой способ сделать это - узнать, в каких случаях ваши клиенты спрашивают о новых функциях или какие бизнес-аналитики используют, а затем копируют эти элементы в новую базу данных. Скорее всего, это будут относительные несколько строк транзакционных данных и все данные типа поиска.

Это также непрерывный процесс, поскольку вы понимаете, что упустили что-то. Сохраните эту базу данных в VCS или известном месте и используйте ее в качестве источника для вашей системы. Если ваши разработчики, ваша система сборки, ваш QA, все вытащить отсюда, вы получите согласованный набор данных. Вы можете дополнить это случайными данными, например, Redgate Data Generator, чтобы помочь заполнить некоторые значения.

Аддитивный подход часто намного проще, чем вычитающий. При этом также имейте в виду, что маскирование / запутывание конфиденциальных данных очень важно. Я был бы здесь более осторожным, поскольку GDPR и другие законодательные акты вступают в силу.

Раскрытие информации: я работаю на Redgate Software.

Answer 2

В то время как не по теме для SO, я хотел бы дать некоторые рекомендации, которым вы можете следовать:

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

Как только вы определились со своей основной сущностью, вы можете выбрать 10% своей базы данных. Например, если вашей основной сущностью являются Учетные записи, вы можете выбрать 10% AccountId из таблицы Account. Эти 10% вы можете положить в таблицу.

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

SELECT      Src.*
INTO        [dbo].[GTP_MSI_MORTGAGERELATION_MORTGAGE_RELATION]
FROM        [ATV].[GTP_MSI_MORTGAGERELATION_MORTGAGE_RELATION] AS Src 
INNER JOIN  atv.GTP_MSI_MORTGAGEREQUEST_APPLICANT APP
        ON  APP.MORTGAGE_RELATION_ID = Src.MORTGAGE_RELATION_ID
INNER JOIN  ATV.GTP_MSI_MORTGAGELOAN_LOAN MLL
        ON  MLL.MORTGAGE_REQUEST_ID = APP.REQUEST_ID
INNER JOIN  dbo.DOOR D
        ON  CONVERT(VARCHAR(255), D.NUMHYP) = MLL.LOAN_NUMBER

В этом примере таблица dbo.DOOR содержит выборку ипотечных идентификаторов в области действия (в этом примере обнаруживаются все отношения между всеми лицами / организациями, связанными с ипотекой).

Что я чаще всего делаю, так это производственные данные (некоторого извлечения во времени) в некоторой схеме и использование запросов, подобных приведенным выше, для заполнения схемы dbo. Таким образом, [ATV].[GTP_MSI_MORTGAGERELATION_MORTGAGE_RELATION] в приведенном выше примере будет содержать производственные данные, в то время как его тезка dbo содержит меньший набор этих производственных данных (данные, относящиеся к объему закладных). Заполнив схему dbo, я могу использовать программное обеспечение анонимизации (как правило, использую Red Gate Datagenerator) для удаления конфиденциальной / конфиденциальной бизнес-информации. Анонимизированные данные я могу затем извлечь и использовать в качестве источника для своей базы данных разработки.

См. Также this (На данный момент, к сожалению, только на голландском языке, но если вы нажмете на него через переводчик, это все равно будет иметь большой смысл.)