Accessing different LPar's from DS Server

danddmrs · Post by **danddmrs** » Tue Nov 20, 2007 3:12 pm

My company is in the process of moving TEST & STAGE databases to their own LPar's. Our DB is Datacom and recently TEST has been moved to LParC, STAGE and PROD are still on the same LPar.

The next step is to move STAGE to LParB but it is being held up because of a DStage performance problem accessing TEST data on LParC.

A job extracting data runs in STAGE and PROD in about 5 minutes extracting about 7,000 rows per second. Pointed at TEST the job runs for over 1 hour and only processes 350 rows per second. Before the move to LParC TEST had the same performance as STAGE and PROD.

Sorry about the limited information provided. I would be happy to ask our Tech Support any questions that might be helpful.

Thanks,
Richard

kcbland · Post by **kcbland** » Tue Nov 20, 2007 4:59 pm

I missed finding a question. Are you asking why the performance difference and how to fix it?

kcbland · Post by **kcbland** » Tue Nov 20, 2007 5:09 pm

My first thought is to remove DataStage from the equation. But that may not be simple for you to try.

I'm guessing you're using an ODBC driver to talk to Datacom. You've probably got at least 3 ODBC DSN's setup (TEST, STAGE, PROD). The same job can be used to pull the same test table from all three instances, just supply a different DSN each run. I'd setup a benchmark comparison of the exact same table spooling out to a transformer stage with an @FALSE constraint going to an empty sequential file. This will give you the purest indication of performance for a DataStage Server process to receive data from a source.

After confirming the performance discrepancy on an apples-to-apples benchmark, I'd move on to removing the ODBC configuration as the cause. When you rehosted the TEST database to the different lpar, you probably had to twiddle something in the ODBC DSN setup on the DataStage server to know where the instance is now located. I'd go back and double-check that the configurations are identical to the higher performing DSN.

After that, it pretty much looks like it's not on the DataStage server side but must be something about the lpar itself. Maybe it's partition has limiters as to connections, user priorities, etc.

ray.wurlod · Post by **ray.wurlod** » Tue Nov 20, 2007 5:54 pm

Is this really a Windows server? I've not encountered LPARs in a Windows environment.

danddmrs · Post by **danddmrs** » Wed Nov 21, 2007 8:40 am

Tech Support has resolved.

The DataStage server is connected to LParA and LParA was connected to LParC via a router. DataStage is not the problem but rather the connection from A to C was causing the performance issue. Rather than connecting A and C via a router the connection was changed to the sysplex on the mainframe. This resolved the problem.

This had the crew stumped for a couple of weeks but they resolved it within hours of the original post. Thanks all for your help and sorry about the bad information.

Richard

ray.wurlod · Post by **ray.wurlod** » Wed Nov 21, 2007 1:45 pm

Time to mark the thread as Resolved, then.

kcbland · Post by **kcbland** » Wed Nov 21, 2007 2:35 pm

ray.wurlod wrote:Is this really a Windows server? I've not encountered LPARs in a Windows environment.

The database lpars, not the DS server.