Skip to main content
Announcements
See what Drew Clarke has to say about the Qlik Talend Cloud launch! READ THE BLOG
cancel
Showing results for 
Search instead for 
Did you mean: 
gseckin
Contributor II
Contributor II

Reaching max db connection

Hi,

Two of our qlik tasks stopped because of the max connection count on database side. According to our dba, they can provide only  max 500 connections. And we already 520 connection that's why some of our tasks are failed. How can we fix this issue? We need to set max connection count globally and each task should up and running. 

We have many instances and you can see the count of connections in these instances. 

 

Qlik Replicate    netstat                lsof 
01e1                     125                    1500 
01e3                    75                     975
02e1                    100                    1200
02e3                    50                     650
03e1                    25                     300
03e3                     50                     650
04e1                    50                     600
04e3                     50                     650

 

 

 

Labels (1)
1 Solution

Accepted Solutions
Heinvandenheuvel
Specialist III
Specialist III

You failed to indicate the SOURCE endpoint type, version and Replicate version. MS SQL? Oracle? 

Some endpoints indeed do have hard limits on connections. If that is the case, skip to the hints.

Mostly is is DBA's with their own made-up rules. The DBA is likely wrong possible due to your failure to make them aware of the business requirements. Your DBA might not know most connections will be idle, only used for full-load, and table structure checking on startup.

It is often best for the Replicate engineer to step back and let the Business folks beat up the DBA. It is the Business folks want/need this to work and you, and the DBA's are merely servants to make it happen, not decision makers in the scenario. Correct?

With the limited information you made available so far here are a few possible things you can do

1)  Change the maximum number of tables to be processed in parallel. Is it still at the default of 5? Try dropping to 3. Has it been raised to a large number? Drop it to 1/2 that large number.

2) Are there multiple CDC tasks for the same DB? Consider using LOGSTREAM to read the changes.

3) Maybe the limitation is per username? Duplicate your source endpoint to a different name and use a different - but equally powerful - username for the second end-points, alternating tasks between the two. Yes this would be cheating, but cheating a silly rule which is there for the wrong reason is fair game is it not?

Hein.

 

View solution in original post

2 Replies
Heinvandenheuvel
Specialist III
Specialist III

You failed to indicate the SOURCE endpoint type, version and Replicate version. MS SQL? Oracle? 

Some endpoints indeed do have hard limits on connections. If that is the case, skip to the hints.

Mostly is is DBA's with their own made-up rules. The DBA is likely wrong possible due to your failure to make them aware of the business requirements. Your DBA might not know most connections will be idle, only used for full-load, and table structure checking on startup.

It is often best for the Replicate engineer to step back and let the Business folks beat up the DBA. It is the Business folks want/need this to work and you, and the DBA's are merely servants to make it happen, not decision makers in the scenario. Correct?

With the limited information you made available so far here are a few possible things you can do

1)  Change the maximum number of tables to be processed in parallel. Is it still at the default of 5? Try dropping to 3. Has it been raised to a large number? Drop it to 1/2 that large number.

2) Are there multiple CDC tasks for the same DB? Consider using LOGSTREAM to read the changes.

3) Maybe the limitation is per username? Duplicate your source endpoint to a different name and use a different - but equally powerful - username for the second end-points, alternating tasks between the two. Yes this would be cheating, but cheating a silly rule which is there for the wrong reason is fair game is it not?

Hein.

 

SushilKumar
Support
Support

Hello @gseckin 

Thanks for reaching out to Qlik via Qlik Community Support page. We would apricates if you could mention the involved source endpoint.  To add more to the previous Expert Suggestion . 

Ask your DBA to put some script to kill inactive session which are there since long . let say 7 to 10 days old.

if you have configured mex_sessions then increase it to further as per no of application or user using it to connect . 

World of caution keep in mind the allocated memory to DB server as if you increase session limit in result it will consume more memory to allocate process/sessions. 

if you are using group and plan then try to adjust the session or process value there.

If our response has been helpful, please consider clicking "Accept as Solution". This will assist other users in easily finding the answer.

 

Regards,

Sushil Kumar