I followed this up and I found some of my old reference materials that say "the database can freeze [...] whenever LGWR is forced to wait for an inactive redo log group to become available for reuse".
I also found some recommendations I once collated for 24x7 Oracle systems that strongly suggest such systems should have "extra" monitoring in place to detect failures in the redo log archiving process - precisely because of its impact on database availability.
Is there any way you can find out if the automated redo log archiving had likely failed when you had your problem? Maybe from timestamps on the archived copies at the archive destination?
Incidentally, for very-high-throughput systems, archiving via a network or comms link can be an issue because the database may be able to create online logs (at local-disk bandwidth) faster than they can be archived. That's very unlikely to be the case with 'normal' applications though.
Also, FWIW, I never used to set production systems up with less than five online log groups.
When all of the redo log groups are currently being archived, you should see a message similar to the following in the alert log:
Thread 1 cannot allocate new log, sequence 23611
Once the archiving process is done with one of the log groups the database should resume normal operations.
You can press the Windows Print Screen key to copy a bitmap of the screen to the Windows Clipboard and from there paste it to any windows application that accepts bitmaps. We typically use this in along with a Print Screen utility to only capture the current applicaiton. Print Screen utility