In your database, you may be forced to perform a recovery using the RESETLOGS option during which the redo logs would be reset to sequence number 1. You want to avoid the overwriting of old log…

The format %t_%s.dbf includes thread and sequence but omits the resetlogs ID, so after RESETLOGS a new sequence-1 archive log would overwrite the old sequence-1 archive log.

The format arch_%t.arc includes only the thread number with no sequence or resetlogs ID, producing the same filename for every log switch and causing constant overwriting.

The format arch_%d.arc uses only the static DBID, which never changes, so every archived log generated would share an identical filename.

The format arch_%t_%d.arc combines thread and DBID but omits the sequence number, so multiple archive logs within a single incarnation collide on the same filename.

The format arch_%d_%s_.dbf includes DBID and sequence but lacks %r, so after RESETLOGS the restarted sequence numbers produce filenames that collide with those from the previous incarnation.

The format arch_%t_%s_%r.arc combines thread number (%t), log sequence number (%s), and the resetlogs incarnation identifier (%r). After a RESETLOGS operation the sequence number resets to 1, but the resetlogs ID changes to a new value, so every filename produced in the new incarnation is distinct from any filename produced in a prior incarnation. This guarantees no old archived log file is ever overwritten, regardless of how many RESETLOGS operations occur.