Transfert efficace d'une grande quantité (84 millions de lignes) de données

J'ai environ 84 millions de lignes. De ceux-ci, tous doivent être transférés vers une base de données distincte sur le même serveur, puis je supprime pour supprimer environ 60 millions de lignes de la base de données source.

Les 84 millions de lignes sont toutes dans le même tableau. Ce tableau représente à lui seul 90% de l'ensemble de la base de données.

Alors ... Source: 84 millions de lignes -> 24 millions de lignes Destination: 0 lignes -> 84 millions de lignes

La source exécute le mode de récupération complète, la destination sera simple.

Je me demande quelle serait la façon la plus efficace de procéder?

Plan A:

1) INSÉRER DANS la destination SELECT * FROM source

2) Source TRUNCATE

3) INSERT INTO source SELECT * FROM destination WHERE keep_condition = 1

Plan B:

1) Restaurer une sauvegarde de la base de données source en tant que base de données de destination

2) Supprimez toutes les tables sauf celle requise dans la base de données de destination

3) Source TRUNCATE

4) INSERT INTO source SELECT * FROM destination WHERE keep_condition = 1

Plan C:

1) INSÉRER DANS la destination SELECT * FROM source

2) SUPPRIMER la source OERE keep_condition = 0

ou autre chose?

Merci

J'ajouterais que, quelle que soit votre décision, vous devrez regrouper ces transactions . J'ai eu beaucoup de chance avec l'article lié récemment, et j'apprécie la façon dont il tire parti des index par opposition à la plupart des solutions par lots que je vois.

Même très peu enregistrées, ce sont de grosses transactions , et vous pourriez passer beaucoup de temps à gérer les ramifications d'une croissance anormale des journaux (VLF, troncature, dimensionnement à droite, etc.).

Merci

"Efficace" peut s'appliquer à l'utilisation du fichier journal, aux performances d'E / S, au temps CPU ou au temps d'exécution.

J'essaierais de réaliser une opération à journalisation minimale, ce qui serait assez efficace du point de vue de la journalisation. Cela devrait vous faire gagner un peu de temps d'exécution. Si vous avez l'espace tempdb, les éléments suivants peuvent fonctionner pour vous.

CREATE TABLE #temp;
ALTER source -> BULK_LOGGED recovery model

BEGIN TRANSACTION;

    INSERT INTO dest SELECT FROM source;
    INSERT INTO #temp SELECT FROM source WHERE keep_condition=1;
    TRUNCATE TABLE source;
    INSERT INTO source SELECT FROM #temp;

COMMIT TRANSACTION;

ALTER source -> FULL recovery model
DROP TABLE #temp;

Pour qu'une opération à journalisation minimale se produise, un certain nombre de conditions doivent être remplies, notamment aucune sauvegarde en cours d'exécution, la base de données définie sur le BULK_LOGGEDmode de récupération et, en fonction de vos index, la table cible doit être vide. Certains de ces comportements ont également changé (améliorés) de SQL Server 2005 à 2008.

Là encore, sans connaître les spécificités de votre table et de vos données, n'importe laquelle de vos autres options pourrait bien fonctionner mieux. Essayez d'utiliser

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

.. et voyez ce qui fonctionne le mieux.

EDIT : lorsque vous effectuez des opérations de journalisation en masse, assurez-vous de faire une sauvegarde (journal complet ou journal des transactions) avant et après l'opération si vous avez besoin d'une capacité de restauration ponctuelle et que vous soupçonnez que d'autres activités peuvent être en cours dans la base de données à en même temps que votre travail ETL s'exécute.

J'ai écrit un article de blog sur les opérations minimalement enregistrées il y a un moment, il y a des liens vers d'autres articles et de la documentation.

Pourquoi pas BCP?

1. Sauvegarder le sourcedb
2. Remplacez sourcedb par un enregistrement en bloc

3. Ouvrir l'invite de commande

4. bcp server.sourcedb.table out Filename.flt -T -c

5. bcp "SELECT * FROM sourcedb.table WHERE keep_condition = 1" queryout Filename2.flt -T -c

6. bcp Server.destinationdb.table in Filename.flt -T -c -b1000

7. vérifier les données

8. Depuis SSMS Tronquez la table sourcedb
9. bcp server.sourcedb.table in Filename2.flt -T -c -b1000
10. Remettre le sourcedb en position pleine

Ne pensez pas que vous devriez recommander de changer le modèle de récupération sans sauvegarde complète de la base de données ou sauvegarde t-log avant et après . L'une des caractéristiques du modèle de récupération BULK_LOGGED est que vous perdrez la possibilité d'effectuer une récupération ponctuelle pour les journaux T contenant des opérations enregistrées en bloc. Scénario classique: sauvegarde complète nocturne, sauvegardes t-log horaires. Vous changez le modèle de récupération en journal en bloc et démarrez votre opération. Quelque chose ne va pas et la transaction est annulée (ou vous n'en avez pas utilisé). Cependant, vous n'êtes pas sûr de ce qui se passait dans la base de données, vous devez donc restaurer à un bon point connu.

Quand pouvez-vous restaurer à nouveau? Dernière sauvegarde t-log toutes les heures qui ne contient pas d'opérations enregistrées en masse, ce qui peut entraîner la perte de n minutes de transactions. Une sauvegarde complète ou une sauvegarde t-log avant de modifier le modèle de récupération créera un point de repli. Lequel vous choisissez dépend de votre RTO.

La suppression de partitions d'une table est un moyen très rapide et économe en ressources de supprimer de gros morceaux de données d'une table. Si cette table était partitionnée de manière à prendre en charge votre répartition source / destination, la réponse serait de restaurer une copie, de supprimer les tables et les partitions redondantes de la destination et de supprimer les partitions complémentaires de la source.

Le coût de l'activation du partitionnement peut cependant rendre cette opération plus coûteuse dans l'ensemble.