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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > 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 - [EMAIL PROTECTED] > > > > > > -----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: [EMAIL PROTECTED] > > > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] > > > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
