Re: dbms_job failed to execute

Igor,

I did check for broken jobs before I ran it manually. None of the jobs had the flag set to Y. The only other trace files I have are generated from a utl_smtp procedure that we have. Sometimes the end-users format the e-mail addresses wrong and the job fails. That is all. This is a known issue that I've asked the developers to fix and catch in the application before it reaches the database.

Magnus

On 10/27/05, Igor Neyman <ineyman_at_perceptron.com> wrote:
>
> Magnus,
> Did you check dba_jobs before you run them manually this morning?
> Did you see "broken" jobs? When you run jobs manually, "broken" changes
> from Y to N.
> If yes - there supposed to be corresponding trace files in "udump"
> directory. Or look for more _j000_ or _j001_ and so on in bdump directory
> with the timestamps between Saturday and this morning.
> Igor
>
> ------------------------------
> *From:* Magnus Andersen [mailto:mag.andersen_at_gmail.com]
> *Sent:* Thursday, October 27, 2005 11:04 AM
> *To:* Igor Neyman
> *Cc:* oracle-l_at_freelists.org
> *Subject:* Re: dbms_job failed to execute
>
> Igor,
>
> The database only goes down Saturday mornings for cold backup. I'm doing
> hot backups the rest of the week. I'm thinking about changing this to only
> to hot backups since I've read that there is no reason to do the cold, but
> that is an other thread I might start to iron that out. My guess is that the
> problem started saturday, but I didn't catch the issue before Tuesday
> morning. The reason you see all the jobs executed this morning is that I had
> to run them manually. We have several processes that are depending on these
> procedures being run. They do not execute on their own.
>
> Hope this makes sense.
>
> Magnus
>
> On 10/27/05, Igor Neyman <ineyman_at_perceptron.com> wrote:
> >
> > Magnus,
> > When you are saying that jobs stopped executing on Tuesday, does it
> > mean that they were not executed since then?
> > Your output from dba_jobs shows that all your jobs were executed this
> > morning (probably when your instance was started) and they all are scheduled
> > to be executed tomorrow at different times (probably, as they are supposed
> > to).
> > The reason they all were executed this morning right after instance
> > started is that most probably your instance was down at the time when they
> > were scheduled to be executed, and when oracle starts, it checks if it
> > missed to execute some jobs while the instance was down.
> > And if it finds such jobs that "missed" their scheduled time, it will
> > execute them immediately (not waiting for next scheduled time).
> > HTH
> > Igor
> >
> > ------------------------------
> > *From:* oracle-l-bounce_at_freelists.org [mailto:
> > oracle-l-bounce_at_freelists.org] *On Behalf Of *Magnus Andersen
> > *Sent:* Thursday, October 27, 2005 10:17 AM
> > *Cc:* oracle-l_at_freelists.org
> > *Subject:* Re: dbms_job failed to execute
> >
> > I found two trace files with the same time stamp on them. These are the
> > closest to when I saw the problem. Could this have "hung" since the database
> > bounced?
> >
> > --
> > Magnus Andersen
> > Systems Administrator / Oracle DBA
> > Walker & Associates, Inc.
> >
> >
> > Trace file information...
> >
> > Dump file /opt/oracle/ora92/rdbms/log /prd/bdump/prd_j000_9659.trc
> > Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production
> > With the Partitioning, OLAP and Oracle Data Mining options
> > JServer Release 9.2.0.6.0 - Production
> > ORACLE_HOME = /opt/oracle/ora92
> > System name: Linux
> > Node name: oraprd.walkerassoc.com <http://oraprd.walkerassoc.com/>
> > Release: 2.4.21-32.0.1.ELsmp
> > Version: #1 SMP Tue May 17 17:52:23 EDT 2005
> > Machine: i686
> > Instance name: prd
> > Redo thread mounted by this instance: 1
> > Oracle process number: 28
> > Unix process pid: 9659, image: oracle_at_oraprd.walkerassoc.com (J000)
> >
> > *** 2005-10-22 00:38:58.415
> > *** SESSION ID:(27.52095) 2005-10-22 00:38:58.391
> > OPIRIP: Uncaught error 1089. Error stack:
> > ORA-01089: immediate shutdown in progress - no operations are permitted
> > ORA-00448: normal completion of background process
> >
>
>
>
> --
> Magnus Andersen
> Systems Administrator / Oracle DBA
> Walker & Associates, Inc.
>

--
Magnus Andersen
Systems Administrator / Oracle DBA
Walker & Associates, Inc.

--
http://www.freelists.org/webpage/oracle-l