Как обеспечить отсутствие дубликатов при использовании LogParser для загрузки журналов IIS в SQL Server каждые пятнадцать минут?

Question

Как обеспечить отсутствие дубликатов при использовании LogParser для загрузки журналов IIS в SQL Server каждые пятнадцать минут?

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

Как я могу гарантировать, что я не копирую дубликаты данных, но в то же время гарантирую, что все записи были скопированы?

Кроме того, как заставить LogParser всегда просматривать текущий журнал без выполнения дорогих запросов, таких как SELECT * FROM ex*.log и используя дату и время?

До сих пор я играл с:

SELECT *
FROM \\Path\To\Logs\ex*.log
WHERE date = SYSTEM_DATE()
AND time > SUB(SYSTEM_TIME(), TO_TIMESTAMP('00:30', 'hh:mm'))

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

Какие-нибудь советы?

1

iis logging logparser

Источник

Ian Roke 24 фев '11 в 11:31

3 ответа

Другие вопросы по тегам iis logging logparser

justSteve 17 дек '11 в 04:01 2011-12-17 04:01 · Answer 1 · 2011-12-17 04:01

Вы проверяли переключатель "-iCheckPoint"? Он хранит метку времени последнего запуска и обращается только к последующим записям.

3

Источник

justSteve 17 дек '11 в 04:01

Ian Roke 24 фев '11 в 12:08 2011-02-24 12:08 · Answer 2 · 2011-02-24 12:08

После некоторой игры я могу ответить на часть моего собственного вопроса.

Код для просмотра только сегодняшнего журнала IIS:

SELECT *
FROM \\Path\To\Logs\ex%date:~8,2%%date:~3,2%%date:~0,2%.log

Я не уверен, что это работает для дат, которые не являются стандартом Великобритании, но это работает для меня. Код выше генерирует это для сегодняшней даты, которая 24/02/2011:

SELECT *
FROM \\Path\To\Logs\ex110224.log

Channdeep Singh 07 ноя '15 в 17:54 2015-11-07 17:54 · Answer 3 · 2015-11-07 17:54

Я преодолел эту проблему, просто создав PRIMARY KEY для столбца RecordNumber в таблице сервера SQL, что помогло остановить дубликаты.

Кроме того, в кластерной среде я преодолел это, создав составной PRIMARY KEY (ComputerName,RecordNumber), и это сработало потрясающе, поскольку в моей среде это всегда была уникальная комбинация.

При преднамеренном тестировании повторного анализа журнала в LOG PARSER он обнаружил ожидаемую ошибку "нарушения первичного ключа" на самом экране LOG PARSER.... и проблема была решена.