Действительно ли возможно получить sub-1-second задержку с репликацией транзакций?
Хотя я согласен с ответом Джоша Густа, вот более ориентированный на Visual Studio подход:
Кажется, что добавляемый вами файл находится вне папок, которые Git может отслеживать для вашего решения. Чтобы определить, что это, вам нужно найти папку .git - это скрытая папка, поэтому убедитесь, что вы можете просматривать скрытые папки в проводнике . Обычно вы можете щелкнуть правой кнопкой мыши свое решение в обозревателе решений и выбрать Открыть папку в проводнике файлов в контекстном меню. Оказавшись там, вы должны увидеть папку .git, если ваше решение находится под контролем исходного кода Git. Посмотрите путь к папке / файлу к папке .git, и это корень Git. Вооружившись этой информацией, вы должны убедиться, что любой добавляемый вами файл добавляется либо в эту корневую папку, либо в одну из ее подпапок. Основываясь на том, что вы описываете, вы добавляете файл, который находится выше - и, таким образом, вне - корня Git вашего решения, и в этом случае этот добавленный файл не может быть отслежен.
3 ответа
Нет. Очень маловероятно, что Вы могли достигнуть sub-1s времен задержки с репликацией транзакций SQL Server даже с быстрыми аппаратными средствами.
Если можно получить задержку 1 - 5 секунд затем, Вы преуспеваете.
Используя репликацию транзакций, для Подписчика возможно быть несколькими секундами позади Издателя. С задержкой только нескольких секунд Подписчик может легко использоваться в качестве сервера создания отчетов, разгрузка дорогих пользовательских запросов и создание отчетов от Издателя Подписчику.
В следующем сценарии (использующий таблицу Customer, показанную позже в этом разделе), Подписчик был только четырьмя секундами позади Издателя. Еще более впечатляющий, 60 процентов времени это имело задержку двух секунд или меньше. Время измеряется от того, когда запись была вставлена или обновлена в Издателе, пока она не была на самом деле записана в подписывающуюся базу данных.
Что-то для запоминания о репликации транзакции - то, что единственное обновление теперь требует, чтобы несколько операций, оказались, для того изменения произойти.
Сначала Вы обновляете исходную таблицу. Затем читатели журнала видят изменение и пишут изменение в базе данных распространения. Затем агент распределения видит новую запись в базе данных распространения и чтения, которые изменяются, затем выполняет корректную хранимую процедуру на подписчике для обновления строки.
При контроле времени выполнения оператора на этих двух серверах, Вы будете, вероятно, видеть, что они работают во всего нескольких миллисекундах. Однако это - время задержки при ожидании читателя журнала и агента распределения, чтобы видеть, что они должны сделать что-то, что собирается уничтожить Вас.
Если Вам действительно будет требоваться sub второе время обработки затем, то Вы захотите изучить запись Вашего собственного механизма обработки для обработки данных, перемещающихся от одного сервера до другого. Я рекомендовал бы использовать Сервисного Брокера SQL для обработки этого как этого способа, которым все является собственным к SQL Server, и никакой сторонний код не должен быть написан.
Я сказал бы, что это определенно возможно.
Я посмотрел бы на:
- Ваша сеть
Выполненные команды ping между этими двумя серверами и видят, существуют ли какие-либо проблемы
Если серверы друг рядом с другом, у Вас должен быть <1 мс. - Узкие места на сервере
Это могло быть сетевым трафиком (объем)
Как сетевые платы, не настраиваемые для 1GB/sec
Антивирус или другие вещи - Сделайте некоторый анализ некоторых запросов и посмотрите, можно ли определить индексы или блокировку, которая могла бы быть проблемой
- Посмотрите, мог ли какой-либо из выборов на базе данных чтения блокировать записи.
Добавьте с (nolock) и посмотрите, имеет ли это значение на одном или двух запросах, Вы анализируете.
По существу у Вас есть сложная система, с которой у Вас есть проблема, необходимо определить, какой компонент является проблемой, и зафиксируйте его.
Репликация транзакций является, вероятно, лучшей, если отчеты / выбирают Вас, должен выполнить потребность быть актуальным. Если бы они не делают Вы могли бы посмотреть на передачу журналов, хотя это добавило бы некоторое время простоя с каждым импортом.
Для данных/файлов журнала удостоверьтесь, что они находятся на отдельных дисках, таким образом, производительность максимизируется.