PCM locks on the LMT datafile bitmap header blocks, just like those used for
enqueues. Difference is, there can be many such blocks and locks, instead
of
just one...
- Original Message -----
To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
Sent: Tuesday, August 13, 2002 12:50 PM
> But probably there is some other resource that replaces the ST enqueue to
> control concurrency in case of LMT tablespaces and the update of the
bitmap
> headers.
>
> Waleed
>
> -----Original Message-----
> Sent: Tuesday, August 13, 2002 2:35 PM
> To: Multiple recipients of list ORACLE-L
>
>
> On OPS and RAC, the issue is not really the contention for the UET$ and
FET$
> tables themselves. It is the contention for the "ST" enqueue/lock which
is
> global across all instances. Only one session on one instance can hold
"ST"
> across all instances in the OPS/RAC database. Essentially, all dictionary
> space-management operations become single-threaded across all instances,
> which is avoided by using LMT...
>
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> Sent: Tuesday, August 13, 2002 9:23 AM
>
>
> > Hello,
> >
> > Some may not agree with this sentiment, but unless there is an
overriding
> > reason for your needing to switch from dictionary-based tablespaces to
> > locally-managed, I would leave well enough alone. Our OPS started out
> doing
> > many things wrong, which we straightened out as we got more
sophisticated
> > about middle tiers, various contention issues, set up better granularity
> for
> > locks, etc. One thing that we decided to leave in place was the
> > dictionary-based tablespaces. We decided that it was more effort to
modify
> > the production system than would be gained by a small reduction in
> > contention for $UET and $FET. If we were creating a new OPS, we would
use
> > locally-managed. With respect to the raw device allocation, our UNIX guy
> set
> > up the devices in /dev/vg0x, and the DBAs create links (ln -s) in
> > /u01/oradata/DB_name to those devices. When we drop a tablespace, we
break
> > the links. For a new tablespace, we create new links. This way we have
> > client-specific datafile names in /u01/oradata/DB_name. And we created
the
> > devices based on some growth assumptions, so DBAs do not have to chase
> after
> > UNIXAdmin every month to add more raw devices.
> >
> > Thank you,
> >
> > Paul Sherman
> > DBA Elcom, Inc.
> > email - psherman_at_elcom.com
> >
> >
> > -----Original Message-----
> > Sent: Tuesday, August 13, 2002 10:19 AM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > You do not have to do anything on Unix. Once you drop the Tablespace
the
> > raw file (device) could be used immediately in a new TS.
> >
> > Regards,
> >
> > Waleed
> >
> > -----Original Message-----
> > To: Multiple recipients of list ORACLE-L
> > Sent: 8/13/02 9:38 AM
> >
> > Hi,
> >
> > Wondering if anyone can help me with this question. Basically we have a
> > parallel server setup (solaris 2.8 oracle 8.1.7.3)and so are using raw
> > devices. I am in the process of recreating the tablspaces to be locally
> > managed as opposed to dictionary. My question is this: In a filesystem
> > environment, I would drop the tablespace in oracle and rm the
> > corresponding datafile on the unix level, and then I can go about
> > recreating my tablespace. I know that the OS doesnt really "interact"
> > with the raw devices as such, but, in this situation would I be able to
> > drop the tablespace and recreate it without having to do anything on the
> > unix level? Would that corresponding raw device just be overwritten??
> >
> > Any help would be greatly appreciated
> >
> > Rgds
> >
> > Fawzia
> >
> >
> > **********************************************************************
> > Information in this email is confidential and may be privileged.
> > It is intended for the addressee only. If you have received it in error,
> > please notify the sender immediately and delete it from your system.
> > You should not otherwise copy it, retransmit it or use or disclose its
> > contents to anyone.
> > Thank you for your co-operation.
> > **********************************************************************
> >
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: Khedr, Waleed
> > INET: Waleed.Khedr_at_FMR.COM
> >
> > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> > San Diego, California -- Public Internet access / Mailing Lists
> > --------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from). You may
> > also send the HELP command for other information (like subscribing).
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: Sherman, Paul R.
> > INET: PSherman_at_elcom.com
> >
> > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> > San Diego, California -- Public Internet access / Mailing Lists
> > --------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from). You may
> > also send the HELP command for other information (like subscribing).
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Tim Gorman
> INET: Tim_at_SageLogix.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Khedr, Waleed
> INET: Waleed.Khedr_at_FMR.COM
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Tim Gorman
INET: Tim_at_SageLogix.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Wed Aug 14 2002 - 06:58:24 CDT
