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
Accessing different LPar's from DS Server
Moderators: chulett, rschirm, roy
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.
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.
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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
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
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
The database lpars, not the DS server.ray.wurlod wrote:Is this really a Windows server? I've not encountered LPARs in a Windows environment.
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle