none
Delta import/Delta Synch to fimma management agent taking more then 3 hours to run in fim 2010 RRS feed

  • Question

  • Hi,

    We have only some user and 5 Management agent (AD and sql type).When i run the FIMMA Managenment agent , it is taking  more than 3 hours to  run the Export,Sync and import opertaion.only i update 32 records from Source Sql table(HRMS System) and run HRMSMA Full Import then it show 32 records has been updated and after this i run Full Sync of HRMSMA this show 32 records is ready for FIMMA Export and AD Export,after this i run FIMMA Export then 32 records comes in FIM Portal at this stage this is working fine for me, but after this i run Delta Import of FIMMA that shows 1980 records is Adds and 5179 records Updates and Delta Synch shows 2512 records for Export attribute flow so please tell me why this happend however i update only 32 records in HRMS System.  Please suggest me how to improve the performance of FIMMA.

    Regards

    Anil Kumar

    Thursday, July 4, 2013 9:17 AM

All replies

  • Is this the first time you've synced to the portal? Do you have users changing things in the portal?
    Friday, July 5, 2013 3:07 AM
  • Hi,

    I have Synch all users to Portal,i do not have users chanhing in the Portal still this taking lot of time to run all the management agent.

    Regards

    Anil Kumar

    Monday, July 8, 2013 6:14 AM
  • There should be a hyperlink next to where it shows you how many adds there were. Click on the hyperlink and you will see what objects are being added. This should help you to figure out what is happening. An add on an import indicates that there was data in your end system, in this case the FIM Portal, that was not yet pulled into the connector space. After the import these added objects will appear in your connector space.

    It sounds like you're being careful to watch exactly what changes you make and then to look at exactly what FIM is doing as a result. If you want to be able to do this, to trace exactly what FIM is doing, it needs to be in a settled state. To make sure you're in a settled state you need to run a Full Import Full Sync on each MA then go through each MA following this process:

    1. Export
    2. Delta Import
    3. Delta Sync
    4. If the sync created any pending exports to this MA return to step 1

    If you do this, as long as the end systems aren't touched, you'll have a cleaner base to start on and your solution will be more likely to give predictable results.

    Monday, July 8, 2013 8:32 AM
  • Anil,

    See, whenever users are exported to the FIM Portal onto which you must have defined the Sync Rules, therefore Users get those rules attached, Here what you see in large numbers is the MPRs, Sync Rules that are being applied onto these users. So, not to worry for them. Though these rules will be applied once you do Delta Import and Delta Sync of FIMMA.

    Regards,

    Manuj Khurana

    • Proposed as answer by Manuj Khurana Monday, September 1, 2014 7:57 AM
    Monday, July 8, 2013 9:24 AM
  • Oh yeah, I didn't think about EREs or DREs. If you're doing sync in the portal you'll get them back in too. 
    Monday, July 8, 2013 9:25 AM
  • Hi, We have run GOOGLE MA full import is running since 15-20 Hours but it is not showing anything in Statics. please suggest



    Regards, Rishi

    Saturday, August 30, 2014 4:51 AM
  • Hi Rishi,

    Stop the Import and rebuild the solution and attach the dll again in the MA.

    Post this try again.


    Regards,
    Manuj Khurana

    • Proposed as answer by Manuj Khurana Monday, September 1, 2014 8:00 AM
    • Unproposed as answer by Manuj Khurana Monday, September 1, 2014 8:00 AM
    Monday, September 1, 2014 7:59 AM
  • Hi,

    We have only some user and 5 Management agent (AD and sql type).When i run the FIMMA Managenment agent , it is taking  more than 3 hours to  run the Export,Sync and import opertaion.only i update 32 records from Source Sql table(HRMS System) and run HRMSMA Full Import then it show 32 records has been updated and after this i run Full Sync of HRMSMA this show 32 records is ready for FIMMA Export and AD Export,after this i run FIMMA Export then 32 records comes in FIM Portal at this stage this is working fine for me, but after this i run Delta Import of FIMMA that shows 1980 records is Adds and 5179 records Updates and Delta Synch shows 2512 records for Export attribute flow so please tell me why this happend however i update only 32 records in HRMS System.  Please suggest me how to improve the performance of FIMMA.

    Regards

    Anil Kumar

    Updating 32 records in FIM should not generate that many EREs or DREs with 5 connected data sources - there's certainly something odd going on looking at the number of adds/updates you get when you do a delta import in FIM. Can you give a breakdown of your MPR design, the ERE's etc? 

    Even if there are these many objects, it still shouldn't take 3 hours to do the export into FIM. Its hard to say why without knowing more about your network infrastrcuture, in particular the connection between the backend SQL database and your sync server. Are they on a high speed connection? 


    • Edited by kmittal82 Monday, September 1, 2014 10:23 AM
    Monday, September 1, 2014 10:23 AM
  • Reindex your FIMService and FIMSynchronization Databases, I have found that the system could be extremely slow if the databases is not re-indexed.

    You could run the following statement for the FIMSynchronizationService / FIMService Database to give yu an outpit of which tables needs defragmentation:

    SELECT TOP 20 
     OBJECT_NAME (ips.[object_id]) AS [Object Name],
     si.name AS [Index Name],
     ROUND (ips.avg_fragmentation_in_percent, 2) AS [Fragmentation],
     ips.page_count AS [Pages],
     ROUND (ips.avg_page_space_used_in_percent, 2) AS [Page Density],
     CASE 
     WHEN ips.avg_page_space_used_in_percent = 0
     THEN ips.page_count * ROUND (ips.avg_fragmentation_in_percent, 2)/100
     ELSE ips.page_count * ROUND (ips.avg_fragmentation_in_percent, 2) / ROUND (ips.avg_page_space_used_in_percent, 2)
     END AS [Weighting]
    --FROM sys.dm_db_index_physical_stats (DB_ID ('FIMService'), NULL, NULL, NULL, 'DETAILED') ips
    FROM sys.dm_db_index_physical_stats (DB_ID ('FIMSynchronizationService'), NULL, NULL, NULL, 'DETAILED') ips
    CROSS APPLY sys.indexes si
    WHERE
     si.object_id = ips.object_id
     AND si.index_id = ips.index_id
     AND ips.index_level = 0
     AND si.name IS NOT NULL
    ORDER BY CASE 
     WHEN ips.avg_page_space_used_in_percent = 0
     THEN ips.page_count * ROUND (ips.avg_fragmentation_in_percent, 2)/100
     ELSE ips.page_count * ROUND (ips.avg_fragmentation_in_percent, 2) / ROUND (ips.avg_page_space_used_in_percent, 2)
     END DESC
    GO

    To run it for the FIMService just change the DBID to FIMService in the line:

    FROM sys.dm_db_index_physical_stats (DB_ID ('FIMSynchronizationService'),

    Or you could just defrag/reindex them by default. I have found that the Synchronization for a took more than 4 hours for 1500 objects prior to the reindex and after the reindexing it completed in less than 5 minutes. The statement to reindex the databases is located on http://social.technet.microsoft.com/wiki/contents/articles/6647.how-to-reindex-all-of-the-tables-in-the-backend-fimsynchronizationservice-database.aspx

      


    Regards Andre van der Westhuizen

    Friday, September 5, 2014 2:04 PM