NUmber of job server cores

[StuartS]

Hello

I am hoping to get an opinion from this forum.

In 8.4 FP1 and FP2 I was aware of an issue where a high number of job server cores could cause error/failures with publishes.    IBM Cognos feedback was that planning had issues when using lost of cores, (40 in this case)

In an environment with 10.1.1 FP1 I am seeing alot of error when using 36 job cores.  Is anyone aware of errors with large numbers of cores, is this something that Cognos have not been able to resolve?

The error I am seeing is (from OUT file)

SQL*Loader-951: Error calling once/load initialization
ORA-00604: error occurred at recursive SQL level 1
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired

The other issue that should be noted is that the environment with 8.4 used SQL Server and 10.1.1 uses Oracle.

Stuart

[topedgemonk]

Hey Stuart,

If that is a shared Oracle DB, have you checked if other DB intensive jobs are happening at the time you get the error. I sometimes get this when DB is busy with ETL data loads (into different schemas on same DB). It usually works when I run the job again, but then, I have only 10 cores of CPU.


(As an aside, I'm curious to know how much of RAM per core you keep and how many servers those 36 cores are split among?)

[ykud]

Well, judging by the Oracle error description and the fact that it happens during publish (sql loader is used to import published data in tables), I would check whether you have
"Direct=True, Parallel=True"
line in CAC / Application Admin Options, because that is usually the cause of locking on publish tables.

Take a look at this document http://public.dhe.ibm.com/software/dw/dm/cognos/performance/cognos_specific/publish_performance_improvements_oracle.pdf

[StuartS]

Hello

Thank you for your comments.

ykud I believe that you are right in that the options are linked to the publish options in the CAC, DIRECT=TRUE and PARALLEL = TRUE.  Where we are with investigations is trying to identify why the SQL Loader intermittanly returns an error.  On the one hand IBM Cognos suggest using DIRECT = TRUE as its faster, by then they also say this can cause the issues seen.  Perhaps its an oracle DB issue?

I guess I was hoping someone else may have had these issues and could share their experience.

My employer has decided to go from 8.4 FP 2 on SQL and physical machines to 10.1.1 FP1 on Oracle and virtual machines.  They are now trying to find out why performance is not good.    (My thoughts are that the VM's share their cores with other apps).

@topedgemonk
We have 36 cores, JS1 - 4, JS2 - 4, JS3 - 8, JS4 - 8, JS5 - 6, JS7 - 6).  Not sure of the memory, think its around 1.5GB/core.
The wierd issue is that the errors do not coincide with DM/ETL jobs or other jobs in the same DB/different schemas.  The tables are not clustered but it is a shared farm with other apps.

Stuart

[Danno]

I guess I was hoping someone else may have had these issues and could share their experience.

My employer has decided to go from 8.4 FP 2 on SQL and physical machines to 10.1.1 FP1 on Oracle and virtual machines.  They are now trying to find out why performance is not good.    (My thoughts are that the VM's share their cores with other apps).

Stuart

My experience with VM's using shared memory have not been overyly positive so far...we have had instances where a major process on another set of VM's has grabbed the majority of resources and negatively impacted our users. I am not a fan of that setup.

[ykud]

ykud I believe that you are right in that the options are linked to the publish options in the CAC, DIRECT=TRUE and PARALLEL = TRUE.  Where we are with investigations is trying to identify why the SQL Loader intermittanly returns an error.  On the one hand IBM Cognos suggest using DIRECT = TRUE as its faster, by then they also say this can cause the issues seen.  Perhaps its an oracle DB issue?

It is an Oracle DB issue, but parallel = true should solve it. You (your DBAs) need to look at Oracle DB configuration in terms of number of sessions avalaible. Might be good to contact Oracle support as well.
Some more ideas:
1) Try running with direct = false and parallel = true and see if you get the error.
2) Try disabling indexes on publish database before publishing

[StuartS]

Thank you