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.