Discussion :

[fweiner]

Messieurs

Nous allons prochainement devoir mettre en place une réplication de notre base données de production.

J'envoie ce message pour avoir votre retour d'expérience sur de telle mise en place. (Efficacité, Cout de mise en place etc ....)

La contrainte est simple : Perte de données Inimaginable, Delta de re-lancement peut être variant. (A chaud, ou différé (léger, 1h, 3h)) le tout est d'être clair et garant de la récupération globale des données.

Pour ma part j'avais dans l'idée d'utilisé le centre de réplication Db2 pour utilisé la réplication SQL existante de manière interne a DB2. (Mais après l'avoir un tout pti peu testé je trouve ça un peu lourd a configuré pour toute une base donnée table a table avec + 500 Tables)

On me parle du Log Shipping (Copie de log a chaud pour ré-aplication a partir de la dernière sauvegarde) Je vais me renseigné. Je ne suis pas contre mais si nous faisons ce choix cela signifie qu'il faudra remontée notre outil de sauvegarde avant + le serveur etc (TSM) .
(Je m'excuse d'avance de vous avouer que notre robotique n'est pas dupliquée et qu'elle ce trouve au même emplacement que le serveur dont je parle : "honte").

Bref j'ai plein de question sur le sujet :

Qu'elles solutions de réplication existe t'il ?
Qu'elles sont vos avis sur chacune ?
Qu'avez vous mis en place dans vos société respective ?

Je me lance dans les recherches, je prendrai le temps qu'il faut et si personne n'apporte de réponse, je compléterai ce sujet par les solutions que je trouve, expliqué avec mon niveau de compétence, cela sera peut être utile de toutes façon.

Fweiner.

[fweiner]

Le Log shipping est une methode ou les logs de transaction sont automatiquement copier ou externaliser via la modification d'un programme d'exit de DB2. (Pour intégration par la suite par schedule d'un Rollforward db <database> to end of logs plus ou moins rapidement (au choix) sur le serveur distant)

Db2 a aussi la posibilité d'être configurer pour ecrire simultanément les logs a deux emplacement différent.

Cette méthode est peu couteuse est simple en configuration, mais utilisé via un programme d'exit copiant les fichiers vers un emplacement extérieure peut comporter des risque de perte de données.

L'association a des systémes intelligent de gestion du stokage, comme du mirroring de disque distant permet de sécurisé la solution.

http://www.ibm.com/developerworks/db...04mcinnis.html

[fweiner]

Je reviens sur ce sujet pour ajouté qqes ptites choses :

Donc :

- Il existe des solutions matérielles :

Les nouvelles baies offres des solutions de réplication basées sur le mirroring des disques. (notamment intégré a la V6R1 pour ceux qui sont sur Iseries)

Regarder cela et diffuser le, c'est trés intéressant sur les nouveautes V6R1 sur Iséries
http://www-05.ibm.com/fr/events/imag..._J_Esnault.pdf


- Il existe des solutions intégré a Db2 entreprise éditions :
Comme la configuration manuelles de technique de Log shipping (Pgm d'exit etc ...)

Comme le centre de réplication Sql intégré de Db2, qui permet de configurer des réplications table a table via des programmes de capture et d'application de modification.

Comme le module HADR qui lui concerne la reprise d'une base de données au complet.

- Il existe des solutions logiciels externe comme double take et surement plein d'autres.

Pour info je part pour le moment sur la configuration du module HADR intégré.

N'hésiter pas a vous manifester si vous avez des infos pour ce sujet. lol

Je me sens seul sur le coup là. j'espère que ce n'est pas de possibles explications simpliste de ma part qui nuit a l'intérêt du sujet.

[db24ever]

Je me sens seul sur le coup là. j'espère que ce n'est pas de possibles explications simpliste de ma part qui nuit a l'intérêt du sujet.

Non non, c'est juste que je dormais

Il existe également une solution de réplication en temps-réel développée par StarQuest. Pour la version iSeries, la réplication se fait à partir des journaux (et récepteurs de journaux) DB2 et la réplication peut se faire vers DB2, SQL Server ou Oracle.
La même réplication peut également se faire depuis DB2 sous Windows ou UNIX.

Cf http://www.starquest.com/Productfolder/infoSQDR.html et http://www.groovysoft.com/SQDR.html

Sinon, il existe également des solutions de réplication chez DataMirror et Hit, entre autre.

[fweiner]

Voici les choix que nous avons fait pour db2 micro sous windows :

Double take d'un serveur physique vers une Virtual machine sur Vmware ESX. (mise place quasiment terminé(bcp d'autre serveurs dans le scope)

Pour l'iseries, la décision sera bientot prise. (Pour le moment réplication via data mirror. (enfin, la version IBM puisqu'ibm a racheté la solution pour l'intégrer(je ne connais pas encore le nom qu'il ont donné au produit))

[wlassout]

Qu'elles version de DB2 utilisez vous ?


chez nous toutes les bases sont en hadr automatisé avec TSA, aucun problème de perte de données et bascule entre les deux bases très rapide

de plus en db2 V9.5 hadr et tsa sont integrés au moteur ....

[fweiner]

DB2 V8 sur windows (ainsi que db2 udb V5R4 sur Iseries ).

Nous nous étions dirigé au départ sur cette solution (HADR), mais pour uniformisé la solution de réplication que nous avions choisi pour tout les autres serveurs (applicatifs) nous avons opté aussi pour double take sur le serveur hébergeant DB2.

Oila