| Table of Contents |
|---|
...
- Please see the notes in these pages:
- 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".
...
- Caveat: If you are not using SQL Parser for Oracle, then only sqlrules would apply in sql_direct and ddl_direct folder, or any folder with any name that uses packageMethod=ddl_direct or packageMethod=direct. (Other types of rules and forecast modeling do NOT apply for ddl_direct/direct/sql_direct changes if you are not using SQL Parser for Oracle.)
- If you are using Oracle with a recent version of Liquibase Enterprise/Datical DB 7.x, you could consider using SQL Parser for Oracle to add forecast modeling and forecast rules.
- When you enable the SQL Parser for Oracle project setting, SQL Parser is applicable by default to the ddl_direct folder (packageMethod=ddl_direct), the sql_direct folder (packageMethod=direct), and sql folder (packageMethod=sqlfile).
- You could also opt to set packageMethod=ddl_direct for your ddl folder using flexible folder configuration so that folder would also use SQL Parser. Using SQL Parser with packageMethod=ddl_diretdirect/packageMethod=direct for ddl would be faster than using the packageMethod=convert for ddl (convert is the default for ddl). You can change the packageMethod for the ddl folder in the metadata.properties file for the ddl folder. Using packageMethod=ddl_direct would make that folder be processed near the beginning of the folder order. Or using packageMethod=direct would make that folder be processed near the end of the folder order.
- If your DML scripts are quite large, for performance reasons you could disable SQL Parser for any folder where large DML scripts may be packaged. You can disable SQL Parser at the folder level by setting disableSqlParser=true in the metadata.properties file for that folder. Note that disableSqlParser=true is already set by default for the DATA_DML folder in newer versions 7.6 and higher.
- There were improvements to SQL Parser for Oracle in versions 7.8 and 7.12. We recommend upgrading to a recent 7.x version if you are using SQL Parser for Oracle.
- Please see these pages:
...
14. Consider increasing the amount of RAM used by Datical using the Xmx setting. See the instructions here: Increase the amount of RAM used by Datical DBLiquibase Enterprise
15. Upgrade to a current version of Liquibase Enterprise/Datical:
...