Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Caveat: If you are not using SQL Parser, then only sqlrules would apply in sql_direct folder.  (Other types of rules and forecast modeling do NOT apply in the sql_direct folder if you are not using SQL Parser for Oracle.)
  • If you are using Oracle with Datical DB 5.9 or higher you could consider using SQL Parser to add forecast modeling and forecast rules to data_dml folder (packageMethod=data_dml) and sql_direct folder (packageMethod=direct).  Please see this page → Using SQL Parser


10.  If you are using Oracle with Datical DB 5.3 or higher, you may have a small performance improvement by having packager NOT use the trace file option.  The trace file option is only relevant for the ddl folder (packageMethod=convert).  If the only types of scripts you package in the ddl folder are DDL scripts, then you do not need trace file and can set packager to disable it in the deployPackager.properties file.  If trace file is enabled, non-DDL changes can be executed from the ddl folder including DCL (such as grants) and DML (such as inserts).  If trace file is disabled, non-DDL changes will NOT be executed from the ddl folder including DCL (such as grants) and DML (such as inserts).  This is only a setting for Oracle.  See disableTraceFile=true on this page →  /wiki/spaces/DDOC59/pages/79573903711.  Having the build agent and the database in close proximity can help performance.


1211.  If you have enabled the Automatically Generate SQL setting you may see performance improvements by turning off that project setting.  

...


1312.  Certain types of script errors (such as missing end delimiter) can cause a packager job to hang indefinitely. To avoid having this happen, you can set a Script Execution Timeout for your REF environments.  It is recommended to set it on your REF dbDef step only, not for your higher environments.  You can configure the number of seconds packager should wait before timing out when deploying a script, for example 600 seconds (10 minutes).  You can use the number of seconds that seems appropriate for the types of scripts you typically package.  The timeout period is per each individual script.  If a script is taking longer than the timeout value, packager will fail with a timeout error and indicate which script timed out.  Having packager fail with a timeout error allows packager to finish all of its steps normally, including restoring/reverting REF DB to its previous state from prior to the error.  This is better than having packager hang indefinitely then terminating the job manually, which could leave REF in an unexpected state with an incomplete deployment. 

...

  • In the desktop client/Eclipse GUI, set it on the REF dbDef step.  See "CLPPLus Timeout (seconds)" for DB2, "SQL*Plus Timeout (seconds)" for Oracle, "EDB*Plus Timeout (seconds)" for Postgres, and "SQLCMD Timeout (seconds)" for SQL Server here  → /wiki/spaces/DDOC59/pages/795706031
  • Set it using the hammer CLI command (example: "hammer set scriptExecutionTimeout REF 600").  See scriptExecutionTimeout here  → /wiki/spaces/DDOC59/pages/795771831
  • If you use the optional project creator script, see scriptExecutionTimeout here  → /wiki/spaces/DDOC59/pages/795804403


1413.  If you run deployPackager on Windows clients or Windows agents, please consider upgrading to Datical version 6.8 or higher.  We made performance improvements for forecast on Windows in Datical version 6.8 (or higher).  Performance improvements for forecast can also improve performance time for deployPackager, since deployPackager does run forecast.  This performance improvement can be noticeable compared to older versions of Datical when you run hammer commands on a Windows machine or when you run the Datical desktop client/Eclipse GUI on a Windows machine.  (This code change is not relevant if you run Datical on a Linux box.)


1514.  Although not specifically about packager, these links both list ways to improve Deploy performance:

...