Есть довольно-таки простая задача:
На рабочем сервере в рабочей базе что-то происходит.
Хочу каждые три-пять минут забирать информацию с рабочего сервера на свой и уже оттуда делать "отчёты".
Не хочу репликацию - там некоторые таблицы в минимальном варианте модифицируются.
В какую сторону смотреть что бы нагрузка на основной сервер была минимальной?
Целостность/непротиворечивость данных на вторичном сервере в "отчётной базе" не нужна. Даже если дублирование раз в год/квартал/месяц/неделю отвалится на полдня,- то это не сильно страшно.

Дифференцированные бэкапы в силу высокой частоты обновлений не приветствуются.

Пока думаю насчёт растянутого по времени копирования таблиц типа truncate table MyTable; Insert into MyTable (field1, field2...) select field1, field2... from LinkedServer.WorkDataBase.dbo.SourceTable WITH (NOLOCK).
Но есть два момента:
1. есть длииииинные таблицы (новые строки в них я чётко вижу, а вот удаление старых гарантированно на 100% "засечь" не могу)
2. есть всё-таки связанные первичными/внешними ключами таблицы (и это как раз "длиииинные таблицы) которые лучше вытаскивать попарно,- что не есть хорошо при их объёме.

Хочу понять КАК реализуются механизмы (ну, типа, always on, снэпшоты ....) хотя бы примерно, что бы оценить нагрузку на основной сервер.


Модель восстановления - simple (но это не принципиально)
Исходный сервер - MSSQL 2008 R2 , целевой 2012 или любой другой (не принципиально).
С рабочим (исходным) MSSQL Server (и Win Server) могу много чего делать (в рамках разумного), с отчётным сервером (как с сиквелом, так и с виндой вообще) - всё что можно через терминальное окно локальному (и не только) администратору.
--------------------------
No ROM Basic...

Relic HunterSIMPLicity_Пока думаю насчёт растянутого по времени копирования таблиц типа truncate table MyTable; Insert into MyTable (field1, field2...) select field1, field2... from LinkedServer.WorkDataBase.dbo.SourceTable WITH (NOLOCK).
Но есть два момента:
1. есть длииииинные таблицы (новые строки в них я чётко вижу, а вот удаление старых гарантированно на 100% "засечь" не могу)
2. есть всё-таки связанные первичными/внешними ключами таблицы (и это как раз "длиииинные таблицы) которые лучше вытаскивать попарно,- что не есть хорошо при их объёме.
Буду краток.

https://docs.microsoft.com/en-us/sql/t-sql/statements/merge-transact-sql?view=sql-server-2017

Ээээ.... это точно "ТА" ссылка?
Для мерджа нужны как минимум две таблицы и одна из них должна быть высосана с сервера-источника. Вопрос - как "легко" высосать таблицу. а не как найти "прибитые" записи....

aleks222Relic Hunterпропущено...

Буду краток.

https://docs.microsoft.com/en-us/sql/t-sql/statements/merge-transact-sql?view=sql-server-2017

Ога merge одной нехилой таблицы в другую нехилую таблицу... это как раз для тредстартера.

ЗЫ. Тредстартер, по факту, хочет самопальную репликацию. Т.е. чудак, но на известную букву.
Ну, флаг ему в руки.

Это пройденный этап и ни чего страшного в подобном нет. Репликация в MS SQL Server изначально "самопальная" была (я по общему принципу, - в версиях 6.5, 7 и 2000, - добавлялись (при необходимости) поля, вешались триггера и проч... ) - и ни кого это особо не смущало.

Вопрос был не совсем так поставлен..

EleanorSIMPLicity_Хочу понять КАК реализуются механизмы (ну, типа, always on, снэпшоты ....) хотя бы примерно, что бы оценить нагрузку на основной сервер.

Снэпшоты - это настроить зеркалирование и периодически делать на зеркальном сервере снэпшоты БД.

Чтобы не было задержек при фиксации транзакций на основном сервере, настраивается асинхронное зеркалирование. Зеркало будет отставать всего на несколько секунд, но снэпшоты будет отражать состояние БД на момент их снятия. Поэтому придется периодически снимать новые, и решать как при этом не затронуть уже запущенные отчеты.

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

Дополнительные плюсы зеркалирования:
- настраивается проще любого другого средства высокой доступности
- появится резервная копия БД, куда можно переключиться в случае сбоя основного сервера
- битые страницы на основном сервере автоматически восстанавливаются с зеркального

SIMPLicity_удаление старых гарантированно на 100% "засечь" не могу
Кроме Change Data Capture можно использовать еще и Change Tracking. CT есть даже в Standard версии Sql сервера.

Ок. Покопаюсь подробнее в этом направлении...

StarikNavySIMPLicity_Не хочу репликацию - там некоторые таблицы в минимальном варианте модифицируются.

хочу кататься, но не хочу покупать автомобиль. его надо иногда ремонтировать.
низачот: есть каршаринг и есть такси - надо только платить деньги и иметь права (для первого варианта) ...