Things to Consider for BCC Deployment Improvement

Publishing Instance Configuration Override

1.    /dyn/admin/nucleus/atg/epub/deployment/Deployment Manager/

·        use Eager Loading Strategy For Source Item Property Value =true

·        max Threads=<<Increase this to a number less than the number of connections specified for PUB Data Source>>

2.    /dyn/admin/nucleus/atg/epub/version/Version Manager Service

Use Unnest Hint For SELECT MAX Inner SQL Query =true

3.    Set selective Cache Invalidation Enabled=false on Product Catalog and Price List Repositories

4.    /dyn/admin/nucleus/atg/epub/deployment/Deployment Manager/

Purge Deployment Data=false

Enable Purge=false

5.    /dyn/admin/nucleus/atg/epub/deployment/Deployment Manager/

Once Deployment is completed and baseline or partial indexing is run do the following:

Navigate to the Deployment Manager component page and invoke the purge Data For Completed Deployment method to delete all completed deployments data. It will execute this query which seems to slow down deployment significantly

DELETE FROM das_rep_mark WHERE rep_marker_id in (

    SELECT marker_id

    FROM das_deploy_mark

    WHERE deployment_data = <<my deployment data>>

) 

Configured Publishing Purging Service to remove old versions assets and project: /atg/epub/purge/Purging Service/

Note: This is something to consider going forward but it is essential.

Over time, the versioning system in Content Administration can accumulate a large number of asset versions and completed projects. As asset versions accumulate, they can strain storage capacity and system performance. It is generally a good idea to periodically purge versioned repositories of outdated projects and asset versions. A Content Administration purge encompasses all versioned repositories and file systems. The purge operates on asset versions and projects whose check-in date is earlier than the specified purge cut-off date.

The service can be run manually or scheduled and should follow ATG general sauvegards:

1.     Before you start a purge, back up all affected data stores and file systems. If you run scheduled purges, you can write code that uses the Purging Service event listener to trigger the required backup operations.

2.     After executing a purge, you might need to repair database indexes, especially if a large amount of versioned data is removed. This is often the case the first time you purge versioned data. Other database-specific considerations might apply.