RE: alter system quiesce restricted never finishes

From: Lyall Barbour <>
Date: Thu, 29 Nov 2012 09:47:15 -0500
Message-ID: <>

Right! Someone asked that when i posted this question on the Oracle Community site... This system is as close to 24/7 as you can get. We have 2, sometimes 3 shifts working on our OLTP Sales/Production Orders/Supply Chain system that has all the GL, AP, and AR invoices etc stuff in it too. We never bounce the database, EXCEPT for month end work which we'd like to get rid of and keep the db up all the time.  Quiescing seemed like the best way to do this and get the processes finished that needed to be finished for EOM.  What i've found in my testing is that I just don't really know when the Quiescing statement will finish, but, that when the ACTIVE_STATE column is anything other then NORMAL (so QUIESCING or QUIESCED) that no one can do stuff, but a different AS SYSDBA log in can.  So, i've got a PL/SQL block that'll do what we need and then loop until the database is QUIESCED or the time frame is done. Then a third log in will UNQUIESCE or DISCONNECT IMMEDIATE the session that was trying to QUIESCE the database.  ...Unless someone has a better idea to find out why/how the QUIESCE command doesn't finish.

----- Original Message -----

From: John Hallas
Sent: 11/28/12 01:02 PM
To:, Subject: RE: alter system quiesce restricted never finishes

 I have not seen a response to this yet (and to be honest I have never found a use for the quiesce database command). Is the issue that the user is logged in as a sysdba user and therefore may be doing 'priviliged work'. Why are you considering the use of the quiesce database command Lyall over say bouncing and starting up in restricted mode? John -----Original Message----- From: [] On Behalf Of Lyall Barbour Sent: 27 November 2012 17:04 To: Subject: alter system quiesce restricted never finishes Hello everyone, We are trying to get some End-Of-Month procedures automated for our accouting application on Oracle. We'd like to Quiesce the database and have an AS SYSDBA login do the procedures. We've tested quiescing an empty 10g database, and it works fine with the Default Resource Manager settings. It seems to work with Grid's 12c Agent turned on for that da

 tabase's host also. If someone is logged into the application, though, the ALTER SYSTEM statement never finishes (or, at least takes longer then 1 hour and 20 minutes when i came back from lunch) The logged in user does not have to be doing anything, just have the application up. I've looked at what Cursors that user has open and the only "transaction" i can see is Auditing insertion into sys.AUD$ I've went through Google and Metalink, and have queried v$blocking_quiesce and v$lock views (found that in Metalink) but even with nothing coming back from those queries, the command never finishes if someone is simply logged into the Forms application. Can a database be quiesced if Auditing is turned on? Anybody know what i'm doing wrong? Thanks, Lyall Barbour -- ______________________________________________________________________ Wm Morrison Supermarkets Plc is registered in England with number 358949. The registered office of the compa
 ny is situated at Gain Lane, Bradford, West Yorkshire BD3 7DL. This email and any attachments are intended for the addressee(s) only and may be confidential. If you are not the intended recipient, please inform the sender by replying to the email that you have received in error and then destroy the email. If you are not the intended recipient, you must not use, disclose, copy or rely on the email or its attachments in any way. This email does not constitute a contract in writing for the purposes of the Law of Property (Miscellaneous Provisions) Act 1989. Our Standard Terms and Conditions of Purchase, as may be amended from time to time, apply to any contract that we enter into. The current version of our Standard Terms and Conditions of Purchase is available at: Although we have taken steps to ensure the email and its attachments are virus-free, we cannot guarantee this or accept any responsibility, and it is the responsibility of recipients
 to carry out their own virus checks. ______________________________________________________________________ --

-- Received on Thu Nov 29 2012 - 15:47:15 CET

Original text of this message