Re: CTIME zero in v$lock

yong321_at_yahoo.com (Yong Huang) wrote in message news:<b3cb12d6.0309082035.51872ecd_at_posting.google.com>...
> To OP, can we see the result of two consecutive select * from v$timer?
> Is there anything unusual in alert.log?
>
> I looked at a Tru64 5.1 Oracle installation
>
> Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production
> PL/SQL Release 9.2.0.3.0 - Production
> CORE 9.2.0.3.0 Production
> TNS for Compaq Tru64 UNIX: Version 9.2.0.3.0 - Production
> NLSRTL Version 9.2.0.3.0 - Production
>
> and ctime is showing non-zero values. This is a publicly accessible
> database at 192.233.54.208 or 192.233.54.207, set up as RAC.
>
> Yong Huang
>
> Brian Peasland <dba_at_remove_spam.peasland.com> wrote in message news:<3F5CA397.CE86343A_at_remove_spam.peasland.com>...
> > In my Oracle 8i and 9i instances on Sun Solaris, the CTIME column is
> > non-zero. I don't have Tru64 to test out on.
> >
> > HTH,
> > Brian
> >
> > Sadik Aral Bozkirli wrote:
> > >
> > > Hi,
> > >
> > > I have oracle 9.2.0.0.0 on Compaq Tru64 UNIX V5.1.
> > >
> > > We are having problems with one of our applications but can't exactly
> > > pinpoint the problem. Though, I'm not sure there is a problem with
> > > the database, I have something like the following in my v$lock view...
> > > Notice CTIMEs are zereo for MR and RT locks. Is this normal?
> > >
> > > Thank...
> > >
> > > ADDR KADDR SID TY ID1 ID2
> > > LMODE REQUEST CTIME BLOCK
> > > ---------------- ---------------- ---------- -- ---------- ----------
> > > ---------- ---------- ---------- ----------
> > > 00000004009B7D58 00000004009B7D78 2 MR 5 0
> > > 4 0 0 0
> > > 00000004009B7C78 00000004009B7C98 2 MR 1 0
> > > 4 0 0 0
> > > 00000004009B7C08 00000004009B7C28 2 MR 2 0
> > > 4 0 0 0
> > > 00000004009B7B98 00000004009B7BB8 2 MR 3 0
> > > 4 0 0 0
> > > 00000004009B7B28 00000004009B7B48 2 MR 4 0
> > > 4 0 0 0
> > > 00000004009B7DC8 00000004009B7DE8 3 RT 1 0
> > > 6 0 0 0
> > > 00000004009B7CE8 00000004009B7D08 5 TS 3 16777218
> > > 3 0 170371 0
> >
> > --
> > ===================================================================

Interesting, this looks just like a problem posted to metalink yesterday. As I responded there MR, media recovery, locks are normal and always present. I am not sure but I think the CTIME column value may be dependent on timed_statistics being set on.

See Oracle Metalink note 34647.1 for information about MR locks.

If the standard problem resolution process of checking the alert log, background dump, and user dump destination directories for problem related trace files does not yield results then running statspack is probably the best way to investigate the unspecified problem.

HTH -- Mark D Powell -- Received on Tue Sep 09 2003 - 08:08:34 CDT