To enable direct SQL deployment, set the useDirectSQLReplication
property in the /atg/epub/DeploymentServer
component on the asset management server to true
:
useDirectSQLReplication=true
If you are using an Oracle database, this setting enables direct SQL deployment for both full and incremental deployments. If you are using a Microsoft SQL Server database, this setting enables direct SQL deployment for full deployments only. You can disable direct SQL deployment by setting useDirectSQLReplication
back to false
.
By default, each deployed repository is replicated in its own thread during direct SQL deployment. The maximum number of threads to use during data transfer is determined by the /atg/epub/version/VersionManagerService.maxReplicationThreadCount
property. The default value of this property is -1, which means there is no limit to the number of threads, and therefore there is a separate thread for each repository. If you are deploying a large number of repositories, the number of concurrent processes could overwhelm your network. If so, you can set maxReplicationThreadCount
to a positive integer to limit the number of threads to use.
The maximum number of database records each thread can deploy in a single transaction is determined by the /atg/epub/version/VersionManagerService.replicationTransactionBatchSize
property. The default value of this property is -1, which means that the batch size is unlimited, and therefore all records for an individual repository are deployed in a single transaction. For very large data sets, batching may improve performance, so you may want to experiment with transaction batch sizes to find the optimal value for your data. Note, however, you should not set replicationTransactionBatchSize
to less than 200, as this may result in errors due to the use of too many database links.