Page History
HTML |
---|
<style> .release-box { height: 30px; width: 100px; padding-top: 8px; text-align: center; border-radius: 5px; font-weight: bold; background-color: #0ACA8B; border-color: #FCE28A; } .release-box:hover { cursor: hand; cursor: pointer; opacity: .9; } </style> <meta name="robots" content="noindex"> <meta name="robots" content="noindex"> <div class="release-box"> <a href="https://docs.perspectium.com/display/fluorineplus" style="text-decoration: none; color: #FFFFFF; display: block;"> Fluorine+ </a> </div> |
ServiceNow App
Divbox | |||||
---|---|---|---|---|---|
|
DataSync Agent
Divbox | |||||
---|---|---|---|---|---|
|
Divbox | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Divbox | |||||
---|---|---|---|---|---|
|
Divbox | |||||
---|---|---|---|---|---|
|
Divbox | |||||
---|---|---|---|---|---|
| |||||
Divbox |
Expand | ||
---|---|---|
| ||
You can alter the default <connection_request_timeout> by setting it to 120000. This should give your connection plenty more room to handle all the IO of large transaction. You would place it within your agent.xml like so: <config> <agent> <subscribe> <task> <task_name>timeout_example</task_name> <message_connection connection_request_timeout="120000" user="XXX" password="XXX" >your_url</message_connection> ... <task> <subscribe> </agent> </config> This should be placed on the <message_connection> within the task level of the desired connection. This attribute will only be set for the specified <message_connection>, so if you have separate connections for monitoring or replicating data they will use the default unless specified. Another option is if you have firewall access to both your https and AMQPS connections (https://your_instance.perspectium.net & amqps://your_instance-amqp.perspectium.net) you can try either
|
Expand | ||
---|---|---|
| ||
You can add a loginTimeout database parameter to the agent.xml configuration file to control the DB connection timeout. In your agent.xml, under each <task> entry, add <database_parms>loginTimeout=NN</database_parms> where nn is in seconds. For example: <database_parms>loginTimeout=30</database_parms> If you already have <database_parms> configured, then append the loginTimeout parameter using: <database_parms>integratedSecurity=true;loginTimeout=30</database_parms> |
Expand | ||
---|---|---|
| ||
Open the wrapper.conf file located in the Agent's conf folder and change the following configuration: #wrapper.java.maxmemory=64 Removing the “#” and putting a numeric value higher than 64. This numeric value is a size in MB for the Java memory heap space the agent can use. Generally, you would base this value on the memory available on the server where the Agent is running. For example, if the server has 1GB of memory, you can set it to be 512MB here: wrapper.java.maxmemory=512 |
Expand | ||
---|---|---|
| ||
The DataSync AQL Agent leverages the default connection commit strategy of the JDBC driver for which Oracle is auto commit. The agent does not explicitly decide when to perform a commit. The JDBC driver makes this decision. The Agent retrieves a message from the message store in the order they were published, performs the required processing such as decryption, validation etc., possibly determines the type of SQL operation required (such as update or insert), and then issues the request to the database. The Agent then determines the response and does any further processing required. Once completed, the Agent will fetch the next message from the message store in the queue. NOTE: You can configure either multiple tasks to run against a single queue or you can configure multiple instances of a single task to run against a single queue. This is done primarily when throughput of the Agent is an issue. Both of these configurations introduce more than a single consumer of the queue and so the order in which the database transaction occurs could be different than the order of the messages within the message store due to scheduling of the task or thread. |
Expand | ||
---|---|---|
| ||
The reason the you're receiving this error is due to Oracle's parameters for SHARED_POOL_SIZE. Note that when SGA_TARGET is set and the parameter is not specified, then the default is 0 (internally determined by the Oracle Database), but if the parameter is specified, then your specified value indicates a minimum value for the memory pool. In the case where a value was set for SGA_TARGET, that would be the value you would need to update rather than the SHARED_POOL_SIZE since by setting SGA_TARGET, you are using automatic SGA management. Hence, there is no need to manually set the value of SHARED_POOL_SIZE because Oracle will internally transfer memory between the SGA components. In the case where you are more concerned with setting a larger value for SGA_TARGET, you can also make a larger value for SHARED_POOL_SIZE but the value must be smaller than SGA_TARGET to avoid encountering the following issue: SGA_TARGET = 1GB
SHARED_POOL_SIZE = no value You will encounter an issue when the value of SHARED_POOL_SIZE exceeds the value of SGA_TARGET. It is recommended to set the SGA_TARGET value at a minimum of 5GB. Therefore, if the SHARED_POOL_SIZE value is at 1GB, the SGA_TARGET will still have at least 4GB for allocation of other memory components that are concurrently stored in SGA_TARGET. NOTE: Be sure to restart the Oracle Database after making the described value changes. For additional information, refer to SHARED_POOL_SIZE or SGA_TARGET. |
Can't find what you're looking for?
See additional DataSync Agent troubleshooting topics or browse the Perspectium Community Forum.
Similar topics
Content by Label | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
...