Force SCN Also called "force archive SCN"[note1] or "force archiving SCN"[note2], the force SCN is best described by Steve Adam at http://www.ixora.com.au/notes/log_switch_triggers.htm "Whenever a log file is reused in any thread, the force SCN recorded in the database entry of the controlfile is advanced to 1 beyond the high SCN of the reused log file (unless the force SCN was already higher). If the low SCN for the current log file in any enabled thread thereby falls behind the force SCN, a log switch is forced in that thread." Because of the existence of the force SCN, it's not possible you'll have a thread or instance in RAC (or OPS before 9i) that lags in SCN behind other threads too much. How much? It can only lag behind at most as old as the oldest (in terms of first_change#) online redo logfile in the most active thread. (Did I get that right?) So you don't need to worry too much about not having enough archive logs. But still, if your online redo logs are all very big and there're many groups, even the most active thread will wrap in a very long time. Other than changing that, you may want to manually archive all threads' redo manually once in a while with e.g. alter system archive log current, or simply set archive_lag_target to some number. To view the force SCN directly, you can dump controlfile (alter system set events 'immediate trace name controlf level 3'). You'll see it in the trace like this: Arch list: Head=1, Tail=1, Force scn: 0x0007.0223960dscn: 0x0007.02280c61 The force SCN is 30100657677 in decimal. Instead of dumping the controlfile , it's easier to get this number from v$database.archive_change#, which is x$kccdi.difas (difas must be database information force archive SCN). SQL> set numw 12 SQL> select archive_change# from v$database; ARCHIVE_CHANGE# --------------- 30100657677 It works even on Oracle9i where the documentation incorrectly calls this column "Last SCN archived" instead of the correct "Database force archiving SCN" (documentation Bug 2396046). The significance of that number can be borne out by saying that the following query does not return any row most of the time, and when it returns rows, they should be gone quickly as ARCn are archiving them: select * from v$log where first_change# < (select archive_change# from v$database) and archived = 'NO'; Ref: http://www.freelists.org/post/oracle-l/Log-Switches-in-RAC,7 [2012-09 Update] If the thread is disabled (v$thread.enabled='DISABLED'), or the database runs in noarchivelog mode even if the thread is enabled (v$thread.enabled='PUBLIC' or 'PRIVATE') and open (v$thread.status='OPEN'), its logs will not be switched by the active instance (where "alter system switch logfile" is issued). Its logs can be switched by explicitly specifying its log group (e.g. "alter system archive log group xxx"). _______________ [note1] Lawrence To, "Archiving Tips and Hints", Oracle Note:75071.1. [note2] Oracle documentation for database 10.2 and up, Reference, V$DATABASE, column ARCHIVE_CHANGE#.