Реализация периодической записи временных меток в базе данных MS SQL - PullRequest
1 голос
/ 29 июня 2010

Задача:

Запись меток времени в таблицу базы данных MS SQL каждую секунду.

Решения:

  1. Внешнее приложение, которое записывает метки времени по расписанию (например, агент Sql)).
  2. Хранимая процедура, которая записывает метки времени в бесконечном цикле.

Вопросы.

  1. Какое из решений лучше?
  2. Есть ли недостатки выполнения бесконечного цикла в хранимой процедуре?
  3. Как запустить хранимую процедуру после перезагрузки сервера?
  4. Любые другие решения?

Ответы [ 3 ]

3 голосов
/ 03 июля 2010
  1. Либо, но я бы склонялся к маршруту хранимой процедуры с WAITFOR DELAY
  2. Не совсем
  3. sp_procoption и запуск хранимых процедур
  4. Без привлечения внешнего клиента или системы я не могу вспомнить ни одного
2 голосов
/ 06 июля 2010

1, оба имеют свои преимущества и недостатки. Оцените и выберите в зависимости от вашей среды

Преимущества процедуры:
- Не тратите время на обработку агента SQL раз в секунду. (На самом деле, я не думаю, что вы можете заставить SQL Agent последовательно запускать одно и то же задание один раз в секунду.)
- Я не думаю, что процедура в режиме WAITFOR использует ресурсы - но вы бы хотели проверить

Процедура Disads:
- Если процедура не выполняется (как-то останавливается), она не запустится. (Если у вас не запущено задание агента SQL, чтобы проверить, остановилась ли процедура, в этом случае можно использовать процедуру)
- Может быть легче остановить / прервать, чем вы думаете (параллелизм / взаимоблокировки, отключенные БД, остановка вручную во время обслуживания, а затем перезапуск)

Преимущества работы:
- Если работа не удалась (возможно, БД недоступна), следующая работа все равно будет запущена

Вакансии:
- Кажется очень грязным, когда агент SQL запускается каждую секунду. Измерьте необходимые издержки сервера, если вы сделаете это.
- Если агент SQL не работает или остановлен, задание не будет запущено

Предложение: должно ли это быть раз в секунду? Это может быть один раз в 5, 10, 15 или 30?

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

3, как говорит @gbn, sp_procoption

4, Ничего, что не связано с громоздкими уловками, основанными на пессимистических методах блокировки, или византийской логикой, основанной на типе метки времени (не даты-времени). Лучшим решением, похоже, будет долгосрочное объединение этих двух баз данных в одну, но это не краткосрочный вариант.

Из чистой паранойи я бы объединил их так:

  • Задание запускается каждые 2, 3 или 5 минут
  • Процедура вызова заданий, которая обновляет ваш временной интервал, затем подождет несколько секунд
  • Процедура не останавливается, поэтому задание продолжает выполняться; во время выполнения задания оно не будет запущено (потому что оно все еще выполняется)
  • Если процедура каким-то образом умирает, задание запустит ее снова в следующий раз, когда запланировано ее выполнение.
1 голос
/ 06 июля 2010

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

http://msdn.microsoft.com/en-us/library/ms345108(SQL.90).aspx#sqlsvcbr_topic2

Это может помочь, http://msdn.microsoft.com/en-us/library/bb839488.aspx

...