Page Comparison

...

• Please see the notes in these pages:
  
  • Stored Logic Validity Check details
  • Project Settings
• Performance recommendations:
  • If you do not review or use the information in the Stored Logic Validity Check section of your deploy reports, then set storedLogicValidityCheck="disabled" to avoid possible performance slow down for a feature you aren't actively using.
  • If you review and use the Stored Logic Validity Check information in your deploy reports but you do not use the storedLogicValidityAction=FAIL option, then we recommend setting storedLogicValidityCheck="limited".
  • If you review and use the Stored Logic Validity Check information in your deploy reports and you also have enabled the storedLogicValidityAction=FAIL option, then we recommend setting storedLogicValidityCheck="local".
  • Although storedLogicValidityCheck="global" is an available setting and is the most comprehensive, if performance timing is an important consideration then it may be better to use a smaller scope such as "local" or "limited".
• There are different ways you can set the stored logic validity check level, use the method you prefer to set the value:
  • In the desktop client/Eclipse GUI, set it to limited.  See Stored Logic Validity Check here  → Configuring Project Settings
  • Set it using the hammer CLI command (example: "hammer set invalidsCheck limited").  See invalidsCheck here  → CLI Commands#set
  • If you use the optional project creator script, see invalidsCheck here  → Creating a Datical Project Using the Project Creation Script (project_creator.groovy)
  • In the datical.project file, this is represented as storedLogicValidityCheck="disabled" or storedLogicValidityCheck="limited" or storedLogicValidityCheck="local".

...

• There were performance improvements during the forecast stage for those who run deployPackager on Windows clients or Windows agents in Datical DB version 6.8 (and higher).There were performance improvements for those who use the Stored Logic Validity Check project setting in Datical DB version 6.12 (and higher).
• There were performance improvements for several operations Status, statusDetails, and Pipeline Status in Datical DB version 6.14 (and higher).  Areas where you may notice performance improvements:
• Status/Pipeline Status operations in the Datical DB GUI
• 'status' & 'statusDetails' commands in the CLI
Complex operations which run status implicitly (CLI & GUI) - All types of 'deploy' operations, All types of 'rollback' operations, Deploy Packager, Convert SQL, and Change Log Sync This also improved operations which run status implicitly such as deploy, rollback, deployPackager, convert SQL and changeLogSync.  
• There were performance improvements specifically for multi-database/multi-catalog configurations of SQL Server projects in Datical DB version 6.16 (and higher).
• There is a fix for the DATAPUMP API Oracle backup and restore in Datical DB version 6.16 (and higher) to better handle running multiple packager jobs concurrently.
• There is a new cleanup command for packager in Datical DB versions 7.3 (and higher).  The cleanup command can be run after any time that you might need to manually interrupt a packager build job midway.  The cleanup command is to unblock subsequent packager jobs after a manual interruption by clearing the locks on DATABASECHANGELOGLOCK and DATICAL_SPERRORLOG tables and also restoring REF.  Please see this page for more details: How To: Use ReleaseLocks Command and Packager with Cleanup Option
• With Datical DB version 7.6 (and higher), there is a new feature that prevents continuing to run packager jobs after a backup error or restore error.  Please see the "Recovering from a Backup or Restore Failure" section here for more details: https://datical-cs.atlassian.net/wiki/spaces/DDOC/pages/896570174/Managing+Database+Backup+and+Restore#ManagingDatabaseBackupandRestore-RecoveringfromaBackuporRestoreFailureRestore Failure" section here for more details: Recovering from a Backup or Restore Failure
• There were improvements for memory utilization of SQL scripts that produce a high-volume output in 7.11 (and higher).
• There were improvements for SQL Parser for Oracle in version 7.12 (and 7.8.  If you are using SQL Parser for Oracle, we recommend running a recent 7.x version.higher). 
• There were improvements for Limited Forecast in version 7.13 .  Areas where you may notice performance improvements(and higher):
  • Limited Forecast will only profile tables impacted by the changesets to be forecasted or deployed
  • Limited Forecast will only profile the schema impacted by the changesets to be forecasted or deployed in multi-schema projects
• Significant performance improvements for Forecast profiling in version 7.14 (and higher):
  • Faster forecasting of Views and Materialized Views
  • Faster profiling for tables, columns, and views in multi-schema projects)
  • Use multiple connections to profile schemas simultaneously in Oracle multi-schema projects

16.  Although not specifically about packager, it may also be useful to check the items on these pages that may improve Deploy performance:

...