Serveur de reporing - Insertion de données sur base distante [Résolu]

[Oishiiii]

Bonjour,

J'ai besoin de votre expertise pour me conseiller sur la réalisation d'un projet.

J'ai différents serveurs avec du SQL Server 2000 et 2005.

1) Sur chacun de ces serveurs je vais créer une base de "reporting" qui sera alimentée par des jobs, afin d'avoir différents indicateurs sur l'état des bases, le status et le temps d'exécutions des plans de maintenance etc...

2) Je pense créer une base spécifique (SQL Server 2005), qui sera alimentée automatiquement par les données des bases 1).
Ce serveur enverra des rapports par email de manière hebdomadaire ou quotidienne en fonction des indicateurs.

Qu'en pensez-vous ?

Comment mettre en place l'import de données depuis les bases 1) vers la base du serveur 2) ?
Apparemment je n'aurai pas besoin de Mirroring ou de réplication, mais plutôt de simples requêtes de type INSERT INTO... SELECT...;

Est-ce qu'il s'agit de mettre en place des "Linked Server" ?

Merci

[mikedavem]

Bonjour,

Pour avoir vu cela et participer a cela chez mon ancien client (une centaine de serveurs a surveiller), nous avons dedie une instance pour cela avec une seule base de donnees et des jobs personnalisees qui permettent de recuperer les informations a distance sur chaque serveur. (Les jobs doivent pouvoir prendre en compte une mise a jour des serveurs a surveiller .. Un table de serveurs par exemple).

Bien entendu il faut un compte de connexion generique sur l'ensemble des serveurs et les droits necessaires pour relever les informations. A vous de voir comment vous voulez l'implementer (batchs SQL, jobs SSIS etc ....)

L'idee est en fait de faire un "entrepot de donnees" des metriques de performance ou de fonctionnement de vos instances.

++

[dbaffaleuf]

Si la véhicule retenu est le job, alors une architecture en MSX/TSX permettra aussi de se simplifier la vie. (http://msdn.microsoft.com/en-us/library/ms180992.aspx). Dans le cas d'un parc de versions hétérogènes, il faut que le MSX soit toujours au plus haut niveau. Donc soit 2005, soit si tu peux passer directement en 2008 histoire de prévoir l'avenir.

[mikedavem]

J'aurais aime implementer ca avec dans ce type d'architecture .. dommage que l'architecture existante ne le permettait pas :-) .. on avait bien fait un workshop et ca marchait bien ...

++

[Oishiiii]

Merci à vous deux pour les réponses.

Je vais étudier les différentes options d'implémentation.
Cette administration multi-serveur a l'air très intéressante.

[Oishiiii]

On m'a gentiment expliqué que l'option administration multiserveur avec une instance master et plusieurs cibles est à éviter car entre autre, cela représenterait une charge trop importante pour le réseau.

Donc là je vais étudier l'impact des serveurs liés (pour et contre) pour aller extraire les données en SQL d'une base à l'autre.

Au pire ça finira en script VBScript qui requêtera toute les bases et enverra les mails, mais je vais essayez d'éviter ça.

[dbaffaleuf]

Tout ça s'étudie:
- Combien de machines en tout seraient des TSX ?
- Quelle fréquence de polling souhaite-t-on mettre en place ?
- Quelle est la nature du réseau (LAN, WAN, quel débit) entre le MSX et les TSX ?

Si toutes les machines sont dans la même salle et reliées par un LAN 1Gb/s , que le polling est raisonnable (10 minutes par exemple), et que l'information qui transite est bien ciblée, l'argument de l'impact réseau est discutable. Tu n'auras pas moins de charge réseau avec des serveurs liés. L'avantage de MSX/TSX par rapport à une solution à base de serveurs liés est qu'elle est bien plus scalable en raison de la consommation de mémoire sur l'instance maître qui augmente avec le nombre d'instances liées. Si le master est en 32 bits, tu seras plafonné en nombre d'instances esclaves.

[Oishiiii]

Merci encore dbaffaleuf

Envoyé par dbaffaleuf

L'avantage de MSX/TSX par rapport à une solution à base de serveurs liés est qu'elle est bien plus scalable en raison de la consommation de mémoire sur l'instance maître qui augmente avec le nombre d'instances liées. Si le master est en 32 bits, tu seras plafonné en nombre d'instances esclaves.

Où est-ce que je peut trouver ce genre d'information ? Je ne trouve pas ces détails technique sur MSDN.

[dbaffaleuf]

- Pour les +/-: http://msdn.microsoft.com/en-us/library/ms189316.aspx

- Pour la question de la mémoire, ce n'est pas vraiment écrit tel quel. C'est juste qu'une partie de la mémoire réservée au démarrage par SQL Server (MemToLeave) est utilisée par les providers de connexion aux instances liées. Cette zone mémoire est limitée en fontion de la configuration (32/64 bits, nb de procs, etc...) en général ça tourne autour de 384Mb en 32 bits et 576Mb en 64 bits, mais ce n'est pas extensible. Il y a régulièrement des problèmes de fuites liées à la fragmentation dans cette zone. Pour plus d'info, lire le chapitre 11 du livre suivant : http://www.amazon.com/Gurus-Guide-Server-Architecture-Internals/dp/0201700476.