Exactly... I had to face this at my current job... I have a separate alter to read only job... Basically, it is a script that calls a stored procedure... I put the script in cron to run every 12 hours... The stored procedure alters eligible tablespaces to read only (eligible as defined by the product)... If an alter to read only hangs for more then 12 hours then the next alter to read only sends a messages (i.e. email or trap) to let you know the condition exists... If there are no tablespaces to alter then the procedure simply exits... And, since it is async then it really doesn't matter if it hangs since it won't hold anything else up... The only problem is that is the database crashes while the file is pending read only, the file needs media recovery on restart...
Tim -----Original Message----- Sent: Friday, September 27, 2002 3:24 PM To: Multiple recipients of list ORACLE-L Thanks. I believe that's how it works on 8.1.6 as well. Of course if someone has walked away without committing a transaction then one is still stuck. There is also the problem of distributed queries. If on database A, one selects from <table_name>@B. An entry is made into the transaction table on database A. That transaction entry will stay until the session on A which issued the distributed query commits. I can almost guarantee that at least one user will have failed to commit when it comes to changing a tablespace to read only, and that user will be unreachable. Ian MacGregor Stanford Linear Accelerator Center [EMAIL PROTECTED] -----Original Message----- Sent: Friday, September 27, 2002 11:03 AM To: Multiple recipients of list ORACLE-L Hi Ian... I can tell you how it works in 8.1.7... You can alter a tablespace to read only with transactions in the database and the steps are as follows: You issue the alter to read only command and it will wait for EVERY transaction in the database that started BEFORE you issued the command to finish before the alter is completed. Any transaction that starts after you issue the command is cleanly handled. If it is on the tablespace you are attempting to alter it will fail. If it is on another tablespace it will not have impact on your alter command. i.e. Trans 1 on Tablespace X Trans 2 on Tablespace Y Alter Tablespace Y to read only ( it waits ) End Trans 2 Notice Alter is still waiting Attempt to start Trans 3 on Tablespace Y ( You will get an error ) Start Trans 4 on Tablespace X End Trans 1 Notice Alter completes HTH Tim -----Original Message----- Sent: Friday, September 27, 2002 1:09 PM To: Multiple recipients of list ORACLE-L I tried to post this in response to the "Best Practices" thread, but for unkown reasons it didn't seem to make it. My apologies if this is a repeat. It had been stated that placing each partition in a separate tablespace allowed one to make a tablespace read only once that partition would no longer be used for insert/update/delete operations. I have not tried to switch a database from online to read only after 8.1.6, but as of that release doing so was difficult in an active database. Oracle required not only that there be no active transactions against the tablspace to be converted but no such transactions against the entire database. If this has changed, when did it happen? We have a system where the ability to make a tablespace read only while the database is actively processing transactions bound for other tablespaces would be extremely useful. Ian MacGregor Stanford Linear Accelerator Center [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: MacGregor, Ian A. INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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: Johnston, Tim INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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: MacGregor, Ian A. INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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: Johnston, Tim INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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).
