Hi Boris and All,
for your comment #1,
we can't just separate the CHECKPOINT(soft/incremental) issues related LOG SWITCH and the SLOW CHECKPOINT as pointed by Tamil related to this topic, because the title of the thread itself is "WHEN LOG SWITCH OCCUR..."

In fact it was even overlooked in the whole process of discussion here. WHEN LOG SWITCH OCCUR a mandatory incremental or soft CHECKPOINT is necessary. So now, the SLOW CHECKPOINT is different(given a premise that this two are different) since its concern touches only for dirty buffers while the INCREMENTAL CHECKPOINT concern mostly for LOG SWITCHING due to a CURRENT online redo log being full and need to advance to the next available online REDO LOG with the new sequence # or influenced by the value settings in your INIT parameter which already mentioned here. Nevertheless, bought have the same objective, and that is to give partial/incomplete CHECKPOINT.

for your comment #2
Its nice to know about the SLOW CHECKPOINT, I may have hear this before but perhaps with different name.
And yet, I'd like to emphasize in my previous post that if you have configured your db buffer cache and you have an adequate size of redo log, your system will not most likely encounter SLOW CHECKPOINT.

And I'd like to correct if you don't mind, about what you assume about a redo log not needed during instance recovery after being checkpointed and archived.

Example:
I will create an uncommitted transaction that has a size larger than the whole total size of online redo logs, so that the redo logs involved with the transaction are both online and archived. And let’s find out also if there are other checkpoints involved other than that happen during log switch.

This example was based on Tamil's theory of a huge transaction against a smaller size of redo logs.


Again let’s assume that the db is newly started, and no other user to create a transaction but me.

Item #1 Just to show that no transaction happens yet in the system
select name, value from v$sysstat
where name like 'DBWR%' and name like 'redo%;
-------------------
NAME VALUE
---------------------------------------------------------------- ----------

DBWR checkpoint buffers written 0
DBWR transaction table writes 0
DBWR undo block writes 0
DBWR revisited being-written buffer 0
DBWR make free requests 0
DBWR free buffers found 0
DBWR lru scans 0
DBWR summed scan depth 0
DBWR buffers scanned 0
DBWR checkpoints 0
DBWR cross instance writes 0
redo synch writes 2
redo synch time 0
redo entries 59
redo size 12676
redo buffer allocation retries 0
redo wastage 5676
redo writer latching time 0
redo writes 21
redo blocks written 37
redo write time 0
redo log space requests 0
redo log space wait time 0
redo log switch interrupts 0
redo ordering marks 0


Item #2 Query the ONLINE REDO LOG- note the STATUS and SEQUENCE# as start before the transaction was executedSELECT A.GROUP#, A.MEMBER, B.SEQUENCE#, B.BYTES, B.STATUS
FROM V$LOGFILE A, V$LOG B
WHERE A.GROUP# = B.GROUP#;

GROUP# MEMBER SEQUENCE# BYTES STATUS
---------- ------------------------------------ ---------- ---------- ----------------
1 C:\ORACLE\ORADATA\HRISESM\REDO01.LOG 188 1048576 INACTIVE
2 C:\ORACLE\ORADATA\HRISESM\REDO02.LOG 189 1048576 INACTIVE
3 C:\ORACLE\ORADATA\HRISESM\REDO03.LOG 190 1048576 CURRENT


Item #3 table structure used for testing data inserts.
SQL> DESC TEMPTAB
Name Null? Type
----------------------------------------- -------- ----------------------------
TESTFLD VARCHAR2(110)

Item #4 create an insert script – a multiple of this pl/sql that can create a transaction size bigger than the whole size of online redo logs. Probably up to 36000 records

declare mcounter number :=0;
begin
for mcounter IN 1..6000 LOOP
DBMS_OUTPUT.PUT_LINE('INSERT INTO TEMTAB VALUES (''THIS IS SAMPLE DATA '||TO_CHAR(MCOUNTER)||''');');
END LOOP;
end;
/

Item #5 execute the spool file create from item #4 without commit

Item #6 Status of the ONLINE redo logs –note new SEQUENCE# and STATUS
- if you notice from the original status, there 12 sequence# advanced, since 3 are the ONLINE REDO LOGS, the remaining 9 should be archived.
GROUP# MEMBER SEQUENCE# BYTES STATUS
---------- ------------------------------------ ---------- ---------- -------------
1 C:\ORACLE\ORADATA\HRISESM\REDO01.LOG 200 1048576 INACTIVE
2 C:\ORACLE\ORADATA\HRISESM\REDO02.LOG 201 1048576 ACTIVE
3 C:\ORACLE\ORADATA\HRISESM\REDO03.LOG 202 1048576 CURRENT


Item #7 System statistics shows after the insert transaction was made-uncommitted.
- Please observer the new value of “DBWR checkpoints” and “redo log space requests”.
- It is the same value with the # REDO LOG switches. So all, are INCREMENTAL checkpoint and not SLOW CHECKPOINT.---------------------
NAME VALUE
---------------------------------------------------------------- ----------
DBWR checkpoint buffers written 814
DBWR transaction table writes 18
DBWR undo block writes 278
DBWR revisited being-written buffer 0
DBWR make free requests 0
DBWR free buffers found 0
DBWR lru scans 0
DBWR summed scan depth 0
DBWR buffers scanned 0
DBWR checkpoints 12
DBWR cross instance writes 0

redo synch writes 2
redo synch time 0
redo entries 36617
redo size 11759540
redo buffer allocation retries 12
redo wastage 348700
redo writer latching time 0
redo writes 1118
redo blocks written 24418
redo write time 0
redo log space requests 12
redo log space wait time 0
redo log switch interrupts 0
redo ordering marks 0


Item #8 Issue SHUTDOWN ABORT
Item #9 Issue STARTUP

Item #10 Let’s see below the alertSID.log. Here it shows, that only 2 redo logs was used
during transaction recovery, and they are both ONLINE redo logs.
But would you believe that there were only 2 redo logs used during the instance recovery knowing that there were 12 redo logs generated for the INSERT DML?
The answer is NO, all 12 redo logs (ONLINE/ARCHIVED) were used and that’s what CONTROL FILE plays in this process.
-------------------------------------
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
Wed Apr 04 13:41:34 2007
Thread recovery: start rolling forward thread 1
Recovery of Online Redo Log: Thread 1 Group 2 Seq 201 Reading mem 0
Mem# 0 errs 0: C:\ORACLE\ORADATA\HRISESM\REDO02.LOG
Recovery of Online Redo Log: Thread 1 Group 3 Seq 202 Reading mem 0
Mem# 0 errs 0: C:\ORACLE\ORADATA\HRISESM\REDO03.LOG
Wed Apr 04 13:41:35 2007
Thread recovery: finish rolling forward thread 1
Thread recovery: 68 data blocks read, 66 data blocks written, 1845 redo blocks read
Crash recovery completed successfully
-------------------------------------

And Thank you Tamil for the compliment.