Re: Raw devices and redo
I'm sure that each source is accompanied by some type of explanation? Surely neither would make such a bald sweeping statement without some substantiation? I would agree with your summarization of Mr. Lewis's position. The type of I/O activity associated with online redo log files (i.e. high volumes of sequential write I/O) suggests an unbuffered type of file. Storing the data written by LGWR in any form of a file-system buffer-cache (which is characteristic of most file-systems) would be a waste of time and processing. Caching is associated with things which you want to write once and then read many, many times. This is not the case with redo data written down by LGWR. At best, it will be read only once more (by the ARCH process), and certainly not in a timely-enough fashion as to justify buffering it... As the name suggests, "raw" devices (a.k.a "logical volumes") are just that -- an unmanaged, unbuffered, "raw" access to the underlying I/O subsystem. There are also file-systems with which the caching can be turned off (i.e. DEC/Compaq/HP AdvFS, etc), so like any simple sweeping statement, the real answer is more complicated, but in general Mr. Lewis's statements are certainly more correct than the other mystery document. Please consider the possibility also that you may have misunderstood the message in the "couple years old document by Oracle", because the interpretation you stated is so far from correct... - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Sunday, August 18, 2002 2:23 AM > Hi, > please give your opinion. > I am reading Jonathan Lewis book Practical Oracle 8i. > He says redo log definitly should be placed on raw devices. > On the other hand I have a couple of years old document by Oracle > stating redo logs definitly do not belong on raw devices. > So who is right? > Antje Sackwitz > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Antje Sackwitz > 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).
Re: raw devices
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 > > DBAElcom, 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: h
RE: raw devices
Hi, Following on from this has anyone else had negative experiences with LMT??? Rgds -Original Message- Sent: 13 August 2002 16:24 To: Multiple recipients of list ORACLE-L 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 DBAElcom, 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: Malik, Fawzia 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).
RE: raw devices
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 > DBAElcom, 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 lis
Re: raw devices
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 > DBAElcom, 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 FA
RE: raw devices
Title: RE: Which index need rebuilding? thankyou!! -Original Message-From: Tim Gorman [mailto:[EMAIL PROTECTED]]Sent: 13 August 2002 15:19To: Multiple recipients of list ORACLE-LSubject: Re: raw devices You are correct; drop and recreate the tablespace and don't do anything at UNIX level, as the contents of the logical volume (a.k.a. raw device) will just be overwritten... - Original Message - From: Malik, Fawzia To: Multiple recipients of list ORACLE-L Sent: Tuesday, August 13, 2002 7:38 AM Subject: raw devices 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 itscontents to anyone. Thank you for your co-operation.**
RE: raw devices
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 DBAElcom, 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).
Re: raw devices
Title: RE: Which index need rebuilding? You are correct; drop and recreate the tablespace and don't do anything at UNIX level, as the contents of the logical volume (a.k.a. raw device) will just be overwritten... - Original Message - From: Malik, Fawzia To: Multiple recipients of list ORACLE-L Sent: Tuesday, August 13, 2002 7:38 AM Subject: raw devices 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 itscontents to anyone. Thank you for your co-operation.**
Re: raw devices
Title: RE: Which index need rebuilding? Yes, I believe it to be so. Just drop and recreate with the same size and filename. - Original Message - From: Malik, Fawzia To: Multiple recipients of list ORACLE-L Sent: Tuesday, August 13, 2002 4:38 PM Subject: raw devices 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 itscontents to anyone. Thank you for your co-operation.**
RE: raw devices
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).
Re: RE: raw devices
Hi! With support for different file systems apart from 'ufs' like jfs and vxfs Much of the perfomance issues have been covered. In fact apart from Oracle Parallel Server having datafiles,redo log files and controlfiles on raw devices does NOT make much sense. Particularly with 'features' like 'Oracle Managed files' not making ANY SENSE at all in raw devices! Thanks -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Cyril Thankappan 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).
Re: raw devices
Raw versus filesystem is almost a religious issue. There are very good arguments both ways. The main advantages of filesystems are ease of use and flexibility. I tend to favor raw devices for critical production systems - for write-intensive OLTP at least. For development and functional test servers, at least, filesystems are simpler, more flexible and usually more appropriate. (Incidentally, one CAN clone a raw database to filesystem without any special magic.) For a more thorough discussion of some of the performance issues, see Jonathan Lewis' site at http://www.jlcomp.demon.co.uk , specifically see http://www.jlcomp.demon.co.uk/raworfs_i.html Also see Steve Adams' site at http://www.ixora.com.au , specifically see http://www.ixora.com.au/tips/creation/raw_datafiles.htm . Search on "raw device" to find more there. (Sorry if this is some sort of infraction by posting direct links to the topic pages!) There are a number of other such references - on both sides of the argument. (I'm looking forward to Gaja's well-reasoned arguments against raws!) The following is not at all comprehensive, but contains a few considerations not often mentioned. Filesystem -advantages Flexibility - easy to add, delete, and resize files. Autoextend, etc. File system read buffering MAY actually be an advantage for some Oracle systems. Easy to back up with anything - including cp or copy Everybody "understands" files (but often less well than they think - see next) -disadvantages Files and filesystems can get extremely fragmented! (Think about it - resize, autoextend,...) Write performance penalty OS-level datafile locking issues May not support async I/O or may not support it well (UFS) fsck of large filesystems can take FOREVER after a crash! Raw device -advantages Significant write performance advantage File system buffering MAY be a disadvantage Guaranteed sequential datafile space - if the raws are built that way Much more difficult to accidentally munge (e.g. "$ rm *" OOPS!!!) Async I/O support [on any (?) platform] -disadvantages Requires much more preparation work for layout (This is a disadvantage? ;-) More administrative overhead - at least initially Backups must be done with something that handles raw devices Not as easy to move things about and perhaps to resize or autoextend them Note that there is no particular distinction made above between UFS and journaled filesystems (e.g VxFS). Due to space and time constraints, I am arbitrarily declaring that "out of scope" for my part of this discussion! The URLs above do consider that distinction in some detail. In general, filesystems are easier, but are, at least in my opinion and experience, less secure and perform worse - at least for write-intensive systems. Some of the traditional arguments against raws are largely moot today. For example: Backups - most modern backup utilities can handle raws transparently. Administration - modern volume managers make setting up raws actually a bit easier than setting up filesystems. However, you will still have a lot more of them since you need a raw device for every datafile, redo log, or control file you place on raw. Raws do still introduce some constraints. Chief among them is up front planning for the layout and its prerequisite analysis. My personal regimen for making raw devices usable includes: * Get the system administrators onboard early. I have often found initial resistance, then their conversion to advocates. * Create a dedicated "disk group" (or whatever it might be called in your volume manager) for your database disks. Perhaps one for each database if multiple Oracle databases exist, (Aside: One of the worst raw device fiascoes I ever saw was when a rookie sys admin at a client site, an major telecom, overwrote several raw datafiles. He was asked to add space to some filesystem and was unaware of the procedures and conventions in place to prevent this from happening - like reserving everything in oradg for Oracle!) * Keep the number of distinct raw device sizes small. Perhaps 100M, 500M, 1000M, & 2000M. (Note: Pick your own favorites. This is just an example. Also, the "real" size may need to be a bit bigger - you can't actually create 20 * 100M extents in a tablespace on a 2000M raw device (or a 2000M UFS file for that matter.) Also, reconsider whether or not you actually need datafiles larger than 2 GB. (I don't like "custom sizing" datafiles - not even very large ones. I would much rather have a tablespace with a number of 2 GB datafiles than with one huge datafile.) * Go through a very serious I/O pattern analysis and a thorough space utilization/growth analysis in preparation of the layout. This is, by far, the most difficult and time-consuming part. But, its something you want to / should do anyway. Raws are a convenient excuse! * Create additional "spare" raw devices up front. If something
RE: raw devices
Don & Oracle Gurus, Going by your answers, I have a question for you? What you have explained is excatly the same environment we had back in our previous work place. But here we have everything what you have MINUS the raw devices. The question I have for Don and the forum folks is, What is the benefits of having flat files over raw? I have been working with RDBMS for over 10 years and I have always worked with RAw and I have raw as recommended by MS,SYBASE and INformix. The reason for this question is because we are moving to RMAN/Veritas and EMC Timefinder, I suggested things would be better if we move to raw. But I could not prove for the fact that Raw is better of Flat FS. Please Suggest from your past experiences. Thanx Srikanth -Original Message- Sent: Monday, August 20, 2001 9:46 AM To: Multiple recipients of list ORACLE-L I don't know about NT, but on Solaris you should have some sort of cluster volume manager - Veritos is the most common. Rather than repeat all the information for vxva, vxprint, etc. here, just read the manuals - "$ man vxva". Another option is to run the vxva GUI and capture the commands it issues. When setting up non-trivial systems with Veritos, I typically script everything rather than wade through hours in the GUI. Since we don't know yet what you have - for a volume manager, for backup utilities, and other such information, it is going to be impossible to give you the detailed technical information, scripts, etc. that you desire. Establish a helpful naming convention - for disks, volumes, etc. Adding a datafile is just like adding any other datafile. Using the Veritos volume manager example again, you would need to: 1) Create the volume in the vxva GUI or by using the vxassist command 2) Assign ownership of the volume to oracle:dba using the vxva GUI or the vxedit command 3) SQL> alter tablespace add datafile '/dev/vx/rdsk/oradg/volume_name' size 100M; Contrary to popular conception, you can expand a datafile inside a raw device - if there is space available. For example, assume you have created a 2001 MB raw device, and have created a 1001 MB datafile on that raw device. You could: SQL> alter database datafile '/dev/vx/rdsk/oradg/volume_name' resize 2001 MB; You can also autoextend within a raw device, but set a maximum size! If it tries to extend beyond the available space for the raw, it will error out. (I prefer not to use autoextend anyway - for other reasons). To drop a tablespace, reclaim the space, and build a new tablespace, do it exactly as you would with filesystems - unless you want to combine datafiles. Only the file names are different. If you want to, for example, combine two smaller raw volumes into one larger raw volume, you will need to drop the tablespace, drop the smaller raw devices, create a larger raw volume in their place (if possible) via the volume manager utility, then create the new tablespace on the new raw volume. For backups, you need something that can back up raw devices. dd is the lowest common denominator utility in Unix. On Solaris PDB OPS clusters with large raw databases, I have always used Veritos NetBackup combined with RMAN or EBU. There are a number of other choices though. One caveat is to understand how your backup utility works in a clustered environment. For example, consider this scenario. You have a two node OPS cluster, with database MYORA and nodes named mynode1 running instance MYORA1, and mynode2 running instance MYORA2. You always run NetBackup/RMAN backups from mynode1. If mynode1 crashes and you now have to run backups or restores from mynode2, you will need to modify the bp.conf configuration file for NetBackup. This is something you want to know how to do BEFORE you loose the node from which you have been doing backups and have to perform a restore from another node! Sorry if these are not the easy unambiguous answers you were seeking, but setting up a good OPS environment is not trivial. Intelligent and well-considered configuration and design is essential to make administration manageable. Raw devices are not really that difficult, but do require significant understanding. One of the signature distinctions between a well-designed OPS system and a maintenance nightmare is in how well all the physical infrastructure (disks, volumes, stripes, mirrors, etc.) are laid out since these are the hardest things to change once it is operational. Backup utilities and other such things must be chosen with raw devices, OPS, the cluster software, the volume manager, and other critical infrastructure elements in consideration. These systems require much more front-end planning than most. Shops that typically operate in fire fighting mode, rather than fire prevention mode, will most likely find OPS and/or raw devices to be inappropriate choices. It is my considered opinion that this is why both (OPS and raw) have long suffered in reputation. -Don Granaman [certifiable OraSauru
RE: raw devices
Thanks a lot for your incedible answer , Don ! -Original Message- Sent: Monday, August 20, 2001 4:46 PM To: Multiple recipients of list ORACLE-L I don't know about NT, but on Solaris you should have some sort of cluster volume manager - Veritos is the most common. Rather than repeat all the information for vxva, vxprint, etc. here, just read the manuals - "$ man vxva". Another option is to run the vxva GUI and capture the commands it issues. When setting up non-trivial systems with Veritos, I typically script everything rather than wade through hours in the GUI. Since we don't know yet what you have - for a volume manager, for backup utilities, and other such information, it is going to be impossible to give you the detailed technical information, scripts, etc. that you desire. Establish a helpful naming convention - for disks, volumes, etc. Adding a datafile is just like adding any other datafile. Using the Veritos volume manager example again, you would need to: 1) Create the volume in the vxva GUI or by using the vxassist command 2) Assign ownership of the volume to oracle:dba using the vxva GUI or the vxedit command 3) SQL> alter tablespace add datafile '/dev/vx/rdsk/oradg/volume_name' size 100M; Contrary to popular conception, you can expand a datafile inside a raw device - if there is space available. For example, assume you have created a 2001 MB raw device, and have created a 1001 MB datafile on that raw device. You could: SQL> alter database datafile '/dev/vx/rdsk/oradg/volume_name' resize 2001 MB; You can also autoextend within a raw device, but set a maximum size! If it tries to extend beyond the available space for the raw, it will error out. (I prefer not to use autoextend anyway - for other reasons). To drop a tablespace, reclaim the space, and build a new tablespace, do it exactly as you would with filesystems - unless you want to combine datafiles. Only the file names are different. If you want to, for example, combine two smaller raw volumes into one larger raw volume, you will need to drop the tablespace, drop the smaller raw devices, create a larger raw volume in their place (if possible) via the volume manager utility, then create the new tablespace on the new raw volume. For backups, you need something that can back up raw devices. dd is the lowest common denominator utility in Unix. On Solaris PDB OPS clusters with large raw databases, I have always used Veritos NetBackup combined with RMAN or EBU. There are a number of other choices though. One caveat is to understand how your backup utility works in a clustered environment. For example, consider this scenario. You have a two node OPS cluster, with database MYORA and nodes named mynode1 running instance MYORA1, and mynode2 running instance MYORA2. You always run NetBackup/RMAN backups from mynode1. If mynode1 crashes and you now have to run backups or restores from mynode2, you will need to modify the bp.conf configuration file for NetBackup. This is something you want to know how to do BEFORE you loose the node from which you have been doing backups and have to perform a restore from another node! Sorry if these are not the easy unambiguous answers you were seeking, but setting up a good OPS environment is not trivial. Intelligent and well-considered configuration and design is essential to make administration manageable. Raw devices are not really that difficult, but do require significant understanding. One of the signature distinctions between a well-designed OPS system and a maintenance nightmare is in how well all the physical infrastructure (disks, volumes, stripes, mirrors, etc.) are laid out since these are the hardest things to change once it is operational. Backup utilities and other such things must be chosen with raw devices, OPS, the cluster software, the volume manager, and other critical infrastructure elements in consideration. These systems require much more front-end planning than most. Shops that typically operate in fire fighting mode, rather than fire prevention mode, will most likely find OPS and/or raw devices to be inappropriate choices. It is my considered opinion that this is why both (OPS and raw) have long suffered in reputation. -Don Granaman [certifiable OraSaurus] - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Monday, August 20, 2001 7:41 AM > Dear gurus ! > I have inherited several OPS databases on both NT & Sun Solaris cluster. > Although i have had some experience in basic ongoing maintenance of OPS , i > have never went a "coast to coast" with it alone. > The most problematic issue , as i currently see it , is raw devices. > How do i manipulate raw devices on NT & Solaris ? (Commands , utilities > etc.. - real hands on , technical stuff , not the theory ) > How do i add / enlarge a data file residing on a raw device ? > How should i backup this OPS DB ? > What should i do if i want to drop a tabl
RE: raw devices
Thanks a lot ! I always concentrate on mice and don't see the elephant :-( -Original Message- Sent: Monday, August 20, 2001 3:42 PM To: Multiple recipients of list ORACLE-L Andrey, All your answers are in the Oracle manuals. I am currently preparing for an NT OPS install. The Oracle8i Parallel Server for NT Guide has all your answers for OPS on NT. And, of course, these docs are available via technet.oracle.com. Have fun!! This is cool stuff. Chris "May Oracle be with you...always" -Original Message- Sent: Monday, August 20, 2001 8:42 AM To: Multiple recipients of list ORACLE-L Dear gurus ! I have inherited several OPS databases on both NT & Sun Solaris cluster. Although i have had some experience in basic ongoing maintenance of OPS , i have never went a "coast to coast" with it alone. The most problematic issue , as i currently see it , is raw devices. How do i manipulate raw devices on NT & Solaris ? (Commands , utilities etc.. - real hands on , technical stuff , not the theory ) How do i add / enlarge a data file residing on a raw device ? How should i backup this OPS DB ? What should i do if i want to drop a tablespace , reclaim the space occupied by it's datafiles and then build another tablespace (with new datafiles) using this reclaimed space ? Would U please also point me to some GOOD technical materials on the web . Thank U very much in advance !!! Andrey. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Andrey Bronfin 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: Grabowy, Chris 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: Andrey Bronfin 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).
Re: raw devices
I don't know about NT, but on Solaris you should have some sort of cluster volume manager - Veritos is the most common. Rather than repeat all the information for vxva, vxprint, etc. here, just read the manuals - "$ man vxva". Another option is to run the vxva GUI and capture the commands it issues. When setting up non-trivial systems with Veritos, I typically script everything rather than wade through hours in the GUI. Since we don't know yet what you have - for a volume manager, for backup utilities, and other such information, it is going to be impossible to give you the detailed technical information, scripts, etc. that you desire. Establish a helpful naming convention - for disks, volumes, etc. Adding a datafile is just like adding any other datafile. Using the Veritos volume manager example again, you would need to: 1) Create the volume in the vxva GUI or by using the vxassist command 2) Assign ownership of the volume to oracle:dba using the vxva GUI or the vxedit command 3) SQL> alter tablespace add datafile '/dev/vx/rdsk/oradg/volume_name' size 100M; Contrary to popular conception, you can expand a datafile inside a raw device - if there is space available. For example, assume you have created a 2001 MB raw device, and have created a 1001 MB datafile on that raw device. You could: SQL> alter database datafile '/dev/vx/rdsk/oradg/volume_name' resize 2001 MB; You can also autoextend within a raw device, but set a maximum size! If it tries to extend beyond the available space for the raw, it will error out. (I prefer not to use autoextend anyway - for other reasons). To drop a tablespace, reclaim the space, and build a new tablespace, do it exactly as you would with filesystems - unless you want to combine datafiles. Only the file names are different. If you want to, for example, combine two smaller raw volumes into one larger raw volume, you will need to drop the tablespace, drop the smaller raw devices, create a larger raw volume in their place (if possible) via the volume manager utility, then create the new tablespace on the new raw volume. For backups, you need something that can back up raw devices. dd is the lowest common denominator utility in Unix. On Solaris PDB OPS clusters with large raw databases, I have always used Veritos NetBackup combined with RMAN or EBU. There are a number of other choices though. One caveat is to understand how your backup utility works in a clustered environment. For example, consider this scenario. You have a two node OPS cluster, with database MYORA and nodes named mynode1 running instance MYORA1, and mynode2 running instance MYORA2. You always run NetBackup/RMAN backups from mynode1. If mynode1 crashes and you now have to run backups or restores from mynode2, you will need to modify the bp.conf configuration file for NetBackup. This is something you want to know how to do BEFORE you loose the node from which you have been doing backups and have to perform a restore from another node! Sorry if these are not the easy unambiguous answers you were seeking, but setting up a good OPS environment is not trivial. Intelligent and well-considered configuration and design is essential to make administration manageable. Raw devices are not really that difficult, but do require significant understanding. One of the signature distinctions between a well-designed OPS system and a maintenance nightmare is in how well all the physical infrastructure (disks, volumes, stripes, mirrors, etc.) are laid out since these are the hardest things to change once it is operational. Backup utilities and other such things must be chosen with raw devices, OPS, the cluster software, the volume manager, and other critical infrastructure elements in consideration. These systems require much more front-end planning than most. Shops that typically operate in fire fighting mode, rather than fire prevention mode, will most likely find OPS and/or raw devices to be inappropriate choices. It is my considered opinion that this is why both (OPS and raw) have long suffered in reputation. -Don Granaman [certifiable OraSaurus] - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Monday, August 20, 2001 7:41 AM > Dear gurus ! > I have inherited several OPS databases on both NT & Sun Solaris cluster. > Although i have had some experience in basic ongoing maintenance of OPS , i > have never went a "coast to coast" with it alone. > The most problematic issue , as i currently see it , is raw devices. > How do i manipulate raw devices on NT & Solaris ? (Commands , utilities > etc.. - real hands on , technical stuff , not the theory ) > How do i add / enlarge a data file residing on a raw device ? > How should i backup this OPS DB ? > What should i do if i want to drop a tablespace , reclaim the space occupied > by it's datafiles and then build another tablespace (with new datafiles) > using this reclaimed space ? > Would U pleas
RE: raw devices
Andrey, All your answers are in the Oracle manuals. I am currently preparing for an NT OPS install. The Oracle8i Parallel Server for NT Guide has all your answers for OPS on NT. And, of course, these docs are available via technet.oracle.com. Have fun!! This is cool stuff. Chris "May Oracle be with you...always" -Original Message- Sent: Monday, August 20, 2001 8:42 AM To: Multiple recipients of list ORACLE-L Dear gurus ! I have inherited several OPS databases on both NT & Sun Solaris cluster. Although i have had some experience in basic ongoing maintenance of OPS , i have never went a "coast to coast" with it alone. The most problematic issue , as i currently see it , is raw devices. How do i manipulate raw devices on NT & Solaris ? (Commands , utilities etc.. - real hands on , technical stuff , not the theory ) How do i add / enlarge a data file residing on a raw device ? How should i backup this OPS DB ? What should i do if i want to drop a tablespace , reclaim the space occupied by it's datafiles and then build another tablespace (with new datafiles) using this reclaimed space ? Would U please also point me to some GOOD technical materials on the web . Thank U very much in advance !!! Andrey. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Andrey Bronfin 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: Grabowy, Chris 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).
