La vérification de la logique SSIS max fonctionne mais prend plus de temps pour migrer les données

Question

Je crée un package SSIS qui interroge une procédure stockée et stocke le jeu de résultats dans une table. Cette table contiendra le jeu de résultats de 18 milliards d'enregistrements. Comme je n'ai aucune colonne clé unique, j'ai créé dynamiquement une colonne rowno en interrogeant la procédure stockée que je stocke dans la table de destination.

J'ai créé une tâche d'exécution SQL qui va obtenir le maximum de la table de destination et filtrer la source avec le maximum pour que je ne transférer que le delta avec chaque migration. Je peux voir que la logique max fonctionne et que seul le delta est migré, mais je pense que la migration est un événement lent bien qu'il n'y ait pas de données à transmettre.

Vous ne savez pas quel est le problème? Je peux voir que même s'il n'y a pas de données, il faut le même laps de temps pour terminer l'événement de processus, mais il n'y a pas de données.

Voici la requête

SELECT * 
FROM 
    (SELECT 
     rowno = row_number() OVER (order by (SELECT NULL)) , 
     fp.companyid, 
     fd.dataitemid, 
     di.dataitemname, 
     fd.dataitemvalue, 
     fu.unittypevalue, 
     fp.fiscalyear, fp.fiscalquarter, 
     fi.periodenddate, fi.filingdate, 
     rt.restatementtypename, 
     fi.latestforfinancialperiodflag, fi.latestfilingforinstanceflag, 
     conv.currencyconversionflag, 
     cur.currencyname, 
     pt.periodtypename 
    FROM 
     ciqfinperiod fp 
    INNER JOIN 
     CoreReferenceStaging.dbo.MarketDataTemp1 a ON a.companyId = fp.companyid 
    INNER JOIN 
     ciqperiodtype pt ON pt.periodtypeid = fp.periodtypeid 
    INNER JOIN 
     ciqfininstance fi ON fi.financialperiodid = fp.financialperiodid 
    LEFT JOIN 
     ciqrestatementtype rt ON rt.restatementtypeid = fi.restatementtypeid 
    INNER JOIN 
     ciqfininstancetocollection ic ON ic.financialinstanceid = fi.financialinstanceid 
    INNER JOIN 
     ciqfincollection fc ON fc.financialcollectionid = ic.financialcollectionid 
    INNER JOIN 
     ciqfincollectiondata fd ON fd.financialcollectionid = fc.financialcollectionid 
    INNER JOIN 
     ciqdataitemconversionrule conv ON conv.dataitemid = fd.dataitemid 
    INNER JOIN 
     ciqcurrency cur ON cur.currencyid = fc.currencyid 
    INNER JOIN 
     ciqdataitem di ON di.dataitemid= fd.dataitemid 
    INNER JOIN 
     ciqfinunittype fu ON fu.unittypeid = fd.unittypeid) q 
WHERE 
    q.rowno > @maxrowno 

La logique max qui est appelée par la tâche d'exécution

select COUNT_BIG(rowno) as rowno 
from [CoreReferenceStaging].[dbo].[FinancialStatementIds] 

Answer 1

tout d'abord: vous ne pouvez pas faire confiance à l'ordre des lignes. Donc, pour cette perspective, vous devriez trouver au moins un marqueur temporel pour filtrer vos données. Votre problème actuel est que SQL Server doit exécuter la requête entière pour pouvoir compter les lignes, puis effectuer le filtrage. Avez-vous vu le plan d'exécution de la requête? Donc, résumant: vous avez une quantité limitée de données d'envoi, mais le serveur sur le côté source lit des tonnes de données. C'est pourquoi cela prend tellement de temps.

Kamil

http://SQLPlayer.net