J'ai plusieurs serveurs avec dessus du SQL7, SQL2000, Oracle 8i et Oracle 9i.
 
Je voudrais les mettre à jour avec les differents patchs et service packs.
Comment connaitre ceux deja installé et connaitre ceux à installer encore ?
 
Merci.

C'est du software, ça...section Windows, Soft et Réseau.

c'est surtout une tache qui peut vite devenir enorme ...
fo voir l'impact sur tes applis apres !
concernant sql server je sais pas par contre oracle, les pathcs etc ca se trouve par ici  http://metalink.oracle.com/

Skeye > Bah va sur S&R, et attends une réponse pour ce genre de question, dans 2 ans quand tu seras tout sec, je pense que tu reviendras sur ton post
 
Grumly- > Pour SQL Server, aucun souci. Tu prends le dernier SP pour chacun des serveur, et tu lis bien la doc associée, et tu fait les manips indiquées (selon les SP, c'est très lourd, je me souviens que le SP1 de SQL Server 2000 était extrêment chiant à appliquer : lancement d'un batch, enregistrement de DLL, mises à jour de fichiers à la main, lancement de requêtes dans SQL Server, la plaie.
A priori, maintenant les patches de SQL Server sont automatisés.
 
Pour Oracle, au vue des mails que j'ai reçu des admins qui ont tenté de passer un patch sur un de nos serveurs, je pense qu'installer une nouvelle instance sera moins coûteuse.
 
Résumé du truc :
- Jour 1 : Arrêt du serveur pendant 10 minutes le temps de passer le patch. Le serveur n'a jamais voulu redémarrer. Restauration des binaires du serveur.
- Jour 2 : Arrêt du serveur durant tout la nuit, avec 3 DBA et 2 administrateurs Unix pour résoudre le problème. Rien à faire, restore des binaires.
- Jour 3 : Passage d'autres patches. Arrêt des serveurs pendant une demi-journée pour transformer les données des bases.
- Jour 4 : Nouvelle tentative de passage du patch initial. Plantage
- Jour 5 : Abandon du passage du patch.
 
=> Résultat : une dizaine de personnes ont perdu environ 4 à 5 jours de travail chacune
=> Un peu plus de 1 000 utilisateurs ont perdu un peu plus de 4 heures de boulot en une semaine.

Pour SQL Server par contre, je n'ai pas d'expérience sur environnement "réel" (gros serveurs, grosses bases).
 
Sur mon serveur, avec une très faible charge, un patch type SP dure environ 15 minutes à tourner. Descendre la base avant de faire quoique ce soit, et faire un backup de toutes les bases (préconnisé dans la doc de toute façon).
Chose importante aussi, lors du passage du patch, locker l'accès au serveur par les utilisateurs/applications. En effet, un coup j'ai poireauté 20 minutes avant de comprendre que j'avais une connection utilisateur active à base qui empêchait le script du patch de démarrer
 
Etant donné qu'une grande partie des patches de M$ consistent en des scripts SQL, qui vont à la fois mettre à jour les fonctions système, et la façon dont sont stockés les objets dans la base, il faut prévoir un temps d'application du patch proportionnel à la taille des bases. Pour ma part, je n'ai jamais fait tourner de patch sur un serveur ayant plus de 100 Mo de données.

oué mais la je tourne sur des serveurs avec plus de 100Go de bases et jusqu'a 240Go donc c chaud et rien que faire des backups ca prend un temps fou !

Ha ben les backup c'est obligatoire. Que ce soit Oracle ou Microsoft, les deux préconnisent absolument de faire un backup avant toute modif des serveurs.
 
En plus de ça, tu es cencé faire un backup complet des données régulièrement (avec une fréquence de moins de 4 semaines) et un backup différenciel au moins chaque jour, sans compter un backup des logs qui devrait être fait toutes les heures au maximum.
 
Le jour où tes serveurs se prennent un pet (virus, fausse manipulation, erreur disque) tu seras bien content de pouvoir récupérer les données à la minute près.

PS: avant de passer un patch, en plus d'un backup de tes données, je te recommande grandement de faire un backup complet (binaires compris). Parceque si ça nique le moteur du SGBD, tu seras content de restaurer une image du serveur en 2 heures plutôt que passer 3 jours à réinstaller un serveur entier.

tout a fait d'accord avec arjuna
fais des backups, c'est le plus important pour un dba
et puis tu ne peux pas passer des patches sur des serveurs de prod (enfin je suppose que c'est de la prod vu les volumes) comme ca sans repetition. tu dois bien avoir des serveurs de dev, recette ou integration non ?
et surement des serveurs de tests sur lesquels tu dois te faire la main et mettre une procedure au point  
 
en tout cas bon courage c'est jamais sur à 100% une migration alors fais des backups et si tu veux pas bloquer les utilisateurs fais des backups online