All Forums Database
Sandeepyadav 52 posts Joined 09/13
16 Oct 2014
Issue : All virtual circuits are in use

Hi All,
 
We are facing issue “All virtual circuits are in use”. I know this issue comes when we have reached the session limit either in PE or gateway. Can anybody tell what the limit for gateway is as PE can handle 120 sessions
and we have 2 Node (4 PE) that means it can handle 4*120=480 sessions. When we got this issue there were only aprox. 190 sessions. So it may be the case for gateway.
 
Would it be good to connect with different IP for this system as we all are using one IP to connect this system? If yes please explain.
 
As we are able to check that all PE are having almost same number of sessions.
 
Please suggest resolving this issue.
 

Thanks, -Sandeep.
CarlosAL 512 posts Joined 04/08
17 Oct 2014

Hi.
Speaking from memory:
Gateway can handle up to 1200 connections, 600 is the default though.
Cheers.
Carlos.

Sandeepyadav 52 posts Joined 09/13
17 Oct 2014

Thanks Carlos for your reply.
 
but sessions are not that much. But still we are facing this issue.
Then what may be the reason. It wiil be great help if you provide some input for this.
 
 

Thanks, -Sandeep.

CarlosAL 512 posts Joined 04/08
17 Oct 2014

Hi
Check the value of the sessions allowed in the gateway configuration with gtwcontrol utility.
Cheers.
Carlos

Sandeepyadav 52 posts Joined 09/13
17 Oct 2014

Its 600.
 

Thanks, -Sandeep.

CarlosAL 512 posts Joined 04/08
17 Oct 2014

Hi
I overlooked this:
"Would it be good to connect with different IP for this system as we all are using one IP to connect this system? If yes please explain."
If the connections are made with explicit IPs instead of using 'Cop' entries you may be flooding one node/PE/Gateway.
Cheers.
Carlos.

Sandeepyadav 52 posts Joined 09/13
17 Oct 2014

Thanks Carlos
It means that connection with one IP connect to the PEs on that Node only ?
BUT
I found that each PE has equall number of sessions ,with the help of logonoff view. It means that sessions connect with one IP but these sesssions are being divided among all the PEs for load balancing internally ( i do not know how its happening)
One thing i know about Cop Entry that if one node is down and HSN comes then users will not know which IP they are connect now, means users will not affect. it help to balance the sessions in between IPs of different Nodes.
Please suggest and correct if i am wrong.
 
 

Thanks, -Sandeep.

CarlosAL 512 posts Joined 04/08
17 Oct 2014

Hi.
The gateway distributes the requests from workstations to the PEs on the same node where the gateway is running.
Cheers.
Carlos.

tomnolan 594 posts Joined 01/08
17 Oct 2014

@Sandeep,
 
Regarding: "It means that connection with one IP connect to the PEs on that Node only ?"
 
The answer is No. The way it works is that connections is one IP address connect to Teradata Database Gateways on that node only. TCP connections go to Teradata Database Gateways; they do not go to PEs directly.
 
 
@Carlos,
Regarding: "The gateway distributes the requests from workstations to the PEs on the same node where the gateway is running."
 
First, I suspect that when you used the word "requests", you actually meant "session logon requests".
 
So if we modify your statement to "The gateway distributes the session logon requests from workstations to the PEs on the same node where the gateway is running."
 
Actually, that's not true. The Teradata Database Gateway distributes each session logon request to the PE with the fewest number of logged-on sessions, and that PE may be on the same node as the Gateway, or it may be on a different node from the Gateway.
 

tomnolan 594 posts Joined 01/08
17 Oct 2014

And by the way, a few years back I created an RFC against the Teradata Database Gateway -- GTW RFC 138835 "At logon time DBS Gateway should prefer On-Node PE for the session"
 
That RFC is planned to be included in an upcoming release of the Teradata Database.
 
Even after that RFC ships; however, it will still be possible for the Gateway to select a PE for a session that is on a different node from the Gateway. What that RFC does is change the Gateway's algorithm for choosing a session's PE such that it will try to select an on-node PE when it can.

Sandeepyadav 52 posts Joined 09/13
17 Oct 2014

Thanks a lot Tomnolan.
So i am just summarizing this,upto my understanding
We have 2 node (4PEs) system and we use one IP to connect the TD database. It mean system can handle 600 session at gateway level and 480 (4*120) session at PE level.
I found that PEs have equal number of sessions on each PE its mean gateway distributes session logon request to PEs with fewest number of logged-on request,PE may be on same node or other node. Correct ?
But we are facing this issue before 480 sessions. Is there any other reasons for this.?
As you mentioned that all PEs are being used ,no mater PE is on same node or other node while connecting to database with one IP. gateway distributes sessions accordingly then  my question is : will Cop entery be helpful in this ?
 
 

Thanks, -Sandeep.

CarlosAL 512 posts Joined 04/08
20 Oct 2014

Hi Tom.
Thanks for the clarification.
 Then I think the documentation is misleading:
"In a workstation environment, CliV2 builds the request parcel and, via MTDP and MOSI sends it over the network to the gateway. The gateway distributes the parcel to an available PE on the node on which the gateway is running."
Cheers.
Carlos.

amar.gundu 1 post Joined 11/11
20 Oct 2014

Hi Sandeep,
Your issue would be intermittent, even if you will try to trace, you can only find the highest number of sessions on any PE at any given time, but you won't be able to see actual limits exceeding, because its instantaneous. In your case, if any of the PE reaches max.120 it throws the error.
I would recommend you to have two cop(tdnodecop1, tdnodecop2) entries for your two nodes and use HOSTNAME(tdnode) to connect Teradata system, thats the standards.This should resolve your error.
Thanks,
- Amar

Thanks - Amar

tomnolan 594 posts Joined 01/08
20 Oct 2014

Sandeep,
It's too difficult to troubleshoot the 8024 error in a forum thread. It might be caused by a variety of reasons, even a Teradata Database Gateway defect. If you're a customer, then I recommend that you open a Teradata Customer Services incident for this issue.

tomnolan 594 posts Joined 01/08
20 Oct 2014

Carlos,
That text is from the Teradata Database Reference book "Database Administration". Thank you for reporting the error in that text. I created defect DR 174049 against that book, to change the text you quoted to the following:
 
In a network environment, the client interface product (such as CLIv2, the Teradata JDBC Driver, etc.) builds the request parcel and sends it over the network to the gateway. The gateway sends the parcel to the session's PE, which may reside on the same node, or on a different node, as the gateway.

Sandeepyadav 52 posts Joined 09/13
20 Oct 2014

Thanks Amar and Carlos :)
I hope copentery will be helpful.
 

Thanks, -Sandeep.

CarlosAL 512 posts Joined 04/08
21 Oct 2014

Tom:
Diving into old documentation I found the same (wrong) reference in Teradata Factory Student Book (V14.10.4) page 3-10.
Thanks.
Cheers.
Carlos.

You must sign in to leave a comment.