Pour transférer de grands volumes de données entre des serveurs SQL, plusieurs stratégies sont utilisées, notamment bulk insert, processus ETL (Extract-Transform-Load), réplication, ainsi que des mécanismes de sauvegarde/restauration, de db-link et d'outils intégrés d'exportation-importation.
Il est optimal d'utiliser des mécanismes de transmission par lots. Un exemple sur SQL Server est BULK INSERT pour charger de grands fichiers, ou SSIS/Integration Services pour des scénarios ETL complexes. Dans des variantes plus portables, des scripts avec une logique LIMIT/OFFSET et la fixation de la position de transmission sont utilisés. Pour la fiabilité, on utilise souvent :
-- Transmission des données par morceaux entre les bases (PostgreSQL) INSERT INTO target_db.public.data_table (col1, col2) SELECT col1, col2 FROM source_db.public.data_table WHERE transferred = FALSE LIMIT 10000;
Quelle est la différence entre réplication et exportation-importation, et pourquoi la réplication ne convient-elle pas toujours pour la migration de grands archives historiques ?
Réponse : La réplication maintient la synchronisation des modifications actuelles et fonctionne efficacement pour les données « vivantes ». Pour la migration d'archives historiques, la réplication peut être insuffisamment rapide et flexible, car elle ne prend pas en charge la transformation personnalisée et ne résout pas le problème du transfert massif unique — on utilise plus souvent ETL ici.
Histoire
L'entreprise a intégré plusieurs bases régionales en un seul référentiel. Lors d'une importation massive sans lots, le système "se gelait" à cause du manque de mémoire vive, entraînant des commits partiels et une récupération manuelle de l'état. Cela a été corrigé par le passage à une extraction par lots avec journalisation des progrès via des tables de staging.
Histoire
En raison d'un contrôle incorrect des sommes de contrôle lors du transfert de grands fichiers avec BULK INSERT, une partie de l'information a été corrompue, mais ce fait n'a été découvert que plusieurs semaines plus tard. La solution a été de recalculer les sommes de contrôle avant et après chaque lot avec une répétition automatique en cas de non-conformité.
Histoire
Dans une tentative de migration de 100+ millions de lignes via l'exportation-importation standard, un développeur n'a pas tenu compte de la gestion des verrous : le blocage des tables sur le serveur cible a entraîné un ralentissement des opérations commerciales pendant plusieurs heures. Conclusion : pour de telles tâches, utiliser uniquement des fenêtres de nuit et un transfert par étapes avec réindexation temporaire.