It completely slipped my attention to check for that and development forgot about it as well. An emergency bug fix is currently in the makings, DS 12.2.2.3 will have a multithreaded RFC Server.
I upgraded to version 12.2.2.3 to solve this issue. However, I can’t test because now I have another problem:
The Jobs can’t be started from BW. I receive the following error message:
ORA-01400: cannot insert NULL into (“BODS_ADM”."AL
I saw in RFC Log (Management Console) and the error is:
12/02/2010 10:39:38 [ SEVERE ] Could not execute the following SQL command: insert into AL_BW_REQUEST (REQUESTID,TYPE,VALUE,DF_NAME,CREATION_TIME) values(?,?,?,?,?)
12/02/2010 10:39:38 [ SEVERE ] ORA-01400: cannot insert NULL into (“BODS_ADM”.“AL_BW_REQUEST”.“VALUE”)
If I run the Jobs from Management Console or Designer, it’s fine.
This did resonate somehow, so I did a search on my emails. On 20.7.2010 I got an email saying “Before launching a job, the RFC Server will insert a record with value=NULL in the AL_BW_REQUEST table […] and when a request is received from BW, this record is updated”.
I believe, when you look at the repo scripts in your \DI\admin\repo… directory you will find that the script for this table allows NULLs on the value column. So when the repo was created, we obviously shipped an wrong version of the create script and later repo upgrades did not deal with that change.
I looked in the \DI\admin\repo\oracle directory and two scripts have the string ‘AL_BW_REQUEST’: ora.sql and ora_upgrade1220.sql.
Both have the same creation table statement:
CREATE TABLE AL_BW_REQUEST
(
REQUESTID NVARCHAR2(64) NOT NULL,
TYPE INTEGER NOT NULL,
VALUE NVARCHAR2(255) NOT NULL,
DF_NAME NVARCHAR2(255),
CREATION_TIME DATE NOT NULL,
PRIMARY KEY (REQUESTID)
);
The column VALUE is a column NOT NULL.
So, if the statement (“Before launching a job, the RFC Server will insert a record with value=NULL in the AL_BW_REQUEST table […] and when a request is received from BW, this record is updated”.) really happens, something is wrong: or this statement or the creation table script.
We have a similar issue after upgrade to 12.2.2.3. The symptom in our case is when we run the infopackage, we see that the job starts, but then hangs for several minutes or sometimes several hours. When we run the InfoPackage with full trace switched on (-T-1 in advanced params), I see in the trace file:
(12.2) 01-28-11 16:13:45 (7472:7760) REPO: Saving object in the repository. The SQL generated is: .
The next line in the trace comes nearly two hours later.
(12.2) 01-28-11 18:05:01 (7472:7760) JOB: Job <JOB_XYZ> of runid <2011012816134574727760> is initiated by user .
I was thinking this maybe a locking issue specific to SQL Server, so I am thinking to change the repo to an Oracle db.
We have updated from 12.2.2.1 to 12.2.2.3 to fix this issue, but the issue remains - Jobs still queue rather than run in parallel. Does additional configuration need to happen to force multithreading?
The update was performed by uninstalling 12.2.2.1 but leaving the directory structure and config files in place, then running a full install.
I should clarify, the jobs run in parallel when initiated from the DS console. It is only when initiated from the BW end that they queue.
There is also an intermittent error which occurs, when 1 job is initiated from DS and another concurrently from BW. In this case, the BW job succeeds but the DS one fails with this error:
Load data to BW failed: RequestID = <ZPAK_4JEG7UY6B41YY602RWVP3KAJZ>, Packet Number = <-1>.
The RFC log states that the error occurred in the source system, in Extractor.