1 votes

Comment puis-je m'assurer qu'il n'y a pas de doublons lorsque j'utilise LogParser pour charger les journaux de IIS dans le serveur SQL toutes les quinze minutes ?

Je voudrais configurer une tâche programmée qui s'exécuterait toutes les quinze minutes sur un serveur Web de travail et qui exécuterait LogParser sur le fichier journal IIS du jour et l'insérerait dans une table de base de données SQL Server.

Comment puis-je m'assurer que je ne copie pas de données en double tout en m'assurant que tous les enregistrements ont été copiés ?

De même, comment faire pour que LogParser regarde toujours le fichier journal du jour sans exécuter des requêtes coûteuses telles que SELECT * FROM ex*.log et en utilisant une condition de date et d'heure ?

Ce avec quoi j'ai joué jusqu'à présent est :

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

Cependant, si je l'exécute toutes les demi-heures, je suis sûr d'obtenir des entrées en double. De plus, si cela ne fonctionnait pas pour une raison quelconque, je me retrouverais avec des données manquantes que j'éliminerais en écrasant chaque matin l'ensemble du fichier de la journée précédente.

Des conseils ?

3voto

justSteve Points 839

Avez-vous vérifié l'option ' -iCheckPoint' ? Il stocke un horodatage de la dernière exécution et n'accède qu'aux enregistrements suivants.

0 votes

C'est trop facile.

0voto

Ian Roke Points 111

Après avoir joué un peu, je peux en fait répondre à une partie de ma propre question.

Le code pour pouvoir regarder le journal IIS d'aujourd'hui est le suivant :

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

Je ne sais pas si cela fonctionne pour les dates qui ne sont pas aux normes britanniques, mais cela fonctionne pour moi. Le code ci-dessus génère ceci pour la date d'aujourd'hui qui est le 24/02/2011 :

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

0voto

J'ai surmonté ce problème en créant simplement une PRIMARY KEY sur la colonne RecordNumber dans la table du serveur SQL, ce qui a permis d'arrêter les doublons.

De plus, dans un environnement en grappe, j'ai surmonté ce problème en créant une PRIMARY KEY composite sur (ComputerName,RecordNumber) et cela a très bien fonctionné, car il s'agissait toujours d'une combinaison unique dans mon environnement.

Lorsque l'on a testé intentionnellement l'analyse d'un journal en double dans LOG PARSER, l'erreur attendue de 'violation de clé primaire' s'est affichée sur l'écran de LOG PARSER lui-même.... et le problème a été résolu.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X