rows/sec zero in the monitor window

scottr · Post by **scottr** » Mon Mar 14, 2005 9:46 am

source is flat file ,target is Oracle 9.2
these jobs have hash file and these hash file loading normally(these are fine),but after the hash files are loaded ,the links from source to next transformer and the rest of the links are showing rows/sec as zero in the monitor window.couple of our jobs are showing this abnormal behavior from last couple of days.

any idea what's wrong?

thanks

roy · Post by **roy** » Mon Mar 14, 2005 10:14 am

Hi,
most likely your rt_status files are not synced and need to be cleared.
this might happen when a hard nasty system crash happens that leaves them in a situation where DS simply thinks they are done when they have not yet even started.
clear the status files of theese jobs from the director (if you enabled administration from director in your project, via ds administrator)

you could build a start-up script/job that takes care of such miss-haps

IHTH,

scottr · Post by **scottr** » Mon Mar 14, 2005 10:46 am

Thanks Roy,
I do clear the RT_STATUS files ,but no luck the job is showing the same behavior. any suggestion.

and yes i came to know this morning that some maintaince work on the server faild and the server crashed during the weekend.our server is some where else and some guy at that site told me on last thursday that the server is under heavy load from wednsday and there is no fulltime admin over there.- this is the back ground for this problem.

thanks.

ArndW · Post by **ArndW** » Mon Mar 14, 2005 12:08 pm

Hello ScottR,

I am assuming from you post that you have verified that the links showing as processing 0 records actually do write data.

If you run your job from the Designer does the link/count information show up the same way as the monitor window in the Director? Also, does the summary log entry detail record at the end of the job log the correct row count information? Have you recompiled your jobs, or perhaps done a "save as" under another name and tried to see if the new job shows the same behaviour?

scottr · Post by **scottr** » Mon Mar 14, 2005 1:55 pm

Hello Arnd,
i am running this job through shell script.and actually this job is not writing data bcoz usually it takes 3 hr and today it is running for more than 3 hrs and it's in the same status.
i can save it with new name and run.i will let u know the result.

thanks

Sainath.Srinivasan · Post by **Sainath.Srinivasan** » Mon Mar 14, 2005 3:32 pm

Check whether you have any locking issues in Oracle. Ask your DBA to monitor when you attempt to execute the job.

scottr · Post by **scottr** » Mon Mar 14, 2005 5:01 pm

thanks sainath ,
my DBA says database is clean.
i got this kind of problem with two jobs .one jobs target table is clean and sql qurries are fast.

but DBA is creating indexes on the second jobs target table.this table has 200ml records and DBA says creating indexes is ongoing process which may takes couple of days.on this table i am unable to insert even single record even the jobs runs 4 hrs.
is there any performance issue with indexes.

mvg2004 · Post by **mvg2004** » Mon Mar 14, 2005 8:53 pm

Hello Scottr,
Just in Case did u check to see if JobMonApp is up and running. Bcoz its wierd if ur load is complete and u see 0rows in the link.

....

ArndW · Post by **ArndW** » Tue Mar 15, 2005 2:18 am

Scottr,

I'm not quite sure what is happening - if you say the monitor shows 0 rows processed and no rows are being written to the output table then why are you assuming that the monitor is not working? It looks like the monitor is showing the correct value and that something else is not functioning as expected. Have you turned on tracing or looked into the log files & directory?

Sainath.Srinivasan · Post by **Sainath.Srinivasan** » Tue Mar 15, 2005 3:03 am

Do you have any constraints that are rejecting rows from source in the first transformer itself.

Or are you doing a massive pre-job action?

I assume you said your source query to be only a simple 'select * from table'.

So you can attempt a job to connect the source SQL directly to a seq file. That may give you a better idea.

What happens if you try to view data from source?

scottr · Post by **scottr** » Thu Mar 17, 2005 1:18 pm

thanks for your responses friends.
finally we came to know there are multiple locks on the target table.once after killing those locks the job runs fine.

once again thanks for ur responses.