March 5, 2010 at 9:39 am
We are going live tomorrow in a completely new environment for our PeopleSoft HR and Finance systems. We are getting a few intermittent errors with our batch processes during testing:
File: E:\pt850-903-R1-retail\peopletools\SRC\psmgr\mgrvers.cppSQL error. Stmt #: 879 Error Position: 0 Return: 8200 - [Microsoft][SQL Server Native Client 10.0]TCP Provider: An existing connection was forcibly closed by the remote host.
Our PeopleSoft Admin has gone in and disable shared memory and put TCP as the first protocol for connecting to our SQL Server database server. Still getting the error.
I have checked all our logs on the database servers, I can't find anything to indicate any problems on the database side.
Any suggestions on next steps to take here in trying to identify and resolve this issue are appreciated.
March 5, 2010 at 9:53 am
Not sure this is exactly what you are looking at, but try this blog post about TCP Offloading by the CSS team. Here's another blog post[/url] that mentions it and some problems they experienced after turning it off.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
March 5, 2010 at 10:00 am
Here's a KB Article that talks about how TCP Offloading works and how to enable/disable it.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
March 5, 2010 at 10:11 am
Jack,
Thanks. I have forwarded the info you provided to my PeopleSoft Admin and Network Services. We'll see what transpires and I'll keep everyone posted.
As to the second blog, I don't think that should be a problem on our OLTP system, but I will definately keep an eye on it to be sure.
March 5, 2010 at 11:54 am
We've disabled TCP Offloading on the SQL Server systems. Now it is a waiting game to see if the intermittent problem still occurs.
March 5, 2010 at 1:37 pm
Hope that works out for you.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
March 5, 2010 at 2:11 pm
We'll see soon enough. We move everything to the new hardware tomorrow and will be live by 5:00 PM.
March 6, 2010 at 9:25 am
Lynn,
is shared memory still disabled, that doesn't sound like a good idea for any local connections.
---------------------------------------------------------------------
March 6, 2010 at 9:41 am
Shared memory is disabled on the application servers. These are separate systems, so no local connections to the database servers. All connections from the application servers are using TCP.
March 6, 2010 at 9:48 am
Oh, OK, I misunderstood, so shared memory wasn't disabled on the SQL server itself?
---------------------------------------------------------------------
March 6, 2010 at 9:54 am
No. I need that when I rdp into the server and run ssms there as well as for any processes that run local to the server.
March 6, 2010 at 10:07 am
Lynn Pettis (3/6/2010)
No. I need that when I rdp into the server and run ssms there as well as for any processes that run local to the server.
exactly what I was worried about. Glad we sorted that out 🙂
---------------------------------------------------------------------
March 11, 2010 at 2:49 pm
Okay, still getting this error and we are now in production. I'm thinking I should set up a server-side trace to see if we can catch anything that may help us solve this problem. Here is where I need some help, what should I be looking for, what events and columns would you suggest I configure?
I'll do some research this evening, but any suggestions would be welcome as well.
March 11, 2010 at 3:01 pm
Do you have your network and sever admins involved as well? It doesn't seem to me to be a SQL Server issue.
I'm not sure that you'd get anything from the trace since it is a connection being closed and you don't really get any events when that happens. You'd want the queries happening so RPC:Starting & Completed, T-SQL:BatchStarting & Completed - I say starting and completed in case it's happening mid-query. I'd also do Errors and Warnings:Exception because made you are getting one and it isn't getting back to the client.
That's all I've got to offer. I'll be interested to hear more.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
March 11, 2010 at 3:08 pm
Jack Corbett (3/11/2010)
Do you have your network and sever admins involved as well? It doesn't seem to me to be a SQL Server issue.I'm not sure that you'd get anything from the trace since it is a connection being closed and you don't really get any events when that happens. You'd want the queries happening so RPC:Starting & Completed, T-SQL:BatchStarting & Completed - I say starting and completed in case it's happening mid-query. I'd also do Errors and Warnings:Exception because made you are getting one and it isn't getting back to the client.
That's all I've got to offer. I'll be interested to hear more.
If you knew our network people you'd understand why I am looking at the SQL side first. I'll have to prove it isn't SQL before we get any real support.
Viewing 15 posts - 1 through 15 (of 26 total)
You must be logged in to reply to this topic. Login to reply