Лучший способ архивации / резервного копирования таблиц и изменений в большой базе данных

Question

У меня есть интересная проблема и требование для большой базы данных с несколькими схемами.

- Размер базы данных составляет около 130 Гб.

-Это база данных с несколькими схемами, у каждого клиента есть схема.

-В настоящее время в системе 102,247 таблиц.

-Microsoft SQL Server 2k8 r2

Это связано с требованиями к настройке клиентов, которые используют единый определенный интерфейс.Проблема, с которой мы столкнулись, заключается в том, что резервные копии нашей базы данных становятся астрономическими, а восстановление базы данных для поиска потерянных / отсутствующих / неправильных данных - это кошмар.В первоначальном продукте не было определенных контрольных журналов, и у нас нет «изменений» в хранимых данных, у нас просто есть 1 версия данных.

Возвращение потерянных данных в основном означает восстановление полной резервной копии объемом 130 ГБ и загрузку разностных файлов / файлов транзакций для получения данных.

Мы хотим ввести «Changeset» для каждой важной таблицы в каждой схеме.по существу, содержит набор данных, а затем любые измененные / различные данные по мере их сохранения - каждые X количество минут.Сначала это должно быть задание на SQL, но я хочу знать, какой из методов будет наилучшим.

По сути, я бы запустил скрипт для вставки «резервных» таблиц в каждую схему для таблиц, для которых мы хотим сохранить резервную копию.

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

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

У меня будет ощущение:

INSERT INTO BACKUP_table (UNIQUE ID, col1,col2,col3)
select col1,col2,col3 from table where and ModifiedDate < DATEADD(mi,+90,Current_TimeStamp)

* грубый SQL

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

Это даже хороший метод?

Что ТАК думает?

Answer 1

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

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

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

Если вы действительно намерены хранить всех в одной базе данных, тогдаМожно рассмотреть возможность хранения важных таблиц внутри каждой схемы в пределах своей файловой группы и перемещения всего из основной файловой группы.Теперь вы можете создавать резервные копии этих файловых групп независимо друг от друга и, основываясь исключительно на полной первичной резервной копии и частичном восстановлении отдельной резервной копии файловой группы, вы можете перевести только схему этого клиента в другое место и получить нужные данные (возможно, скопировав их).в основную базу данных с использованием импорта / экспорта, BCP или простых запросов DML), без необходимости полного восстановления всей базы данных.Перемещение всех пользовательских данных из основной файловой группы сводит к минимуму время, необходимое для восстановления этой первоначальной резервной копии, и позволяет восстановить файловую группу конкретного клиента.В то время как это делает вашу стратегию резервного копирования / восстановления немного более сложной, она действительно достигает того, что вам нужно.

Другим вариантом является использование пользовательской реализации доставки журналов с намеренной задержкой.Некоторое время мы делали это, отправляя наши журналы на сервер отчетов, но подождав 12 часов, прежде чем применять их.Это дало нам защиту от того, что клиенты стреляли себе в ногу, а затем требовали восстановления - если они связались с нами в течение 12 часов после своей ошибки, мы, вероятно, уже имели данные «до взлома» онлайн на сервере отчетов, что делает их тривиальнымиисправить это на основном сервере.Он также удваивается в качестве сервера отчетов для отчетов, которые просматривают данные старше 12 часов, что значительно снижает нагрузку на основной сервер.

Вы также можете рассмотреть изменение сбора данных , но вам, очевидно, потребуетсячтобы проверить производительность и влияние на остальную часть вашей рабочей нагрузки.Это решение также будет зависеть от используемой вами версии SQL Server, поскольку оно недоступно в Standard, Web, Workgroup и т. Д.