Three log-based methods are used to differentiate incremental checkpoints and full checkpoints.

Theory: logs are active, that is, logs overwritten by RBA pointers. If the checkpoint is complete, RBA will immediately redo the last redo log group. If RBA is absent

Theory: logs are active, that is, logs overwritten by RBA pointers. If the checkpoint is complete, RBA will immediately redo the last redo log group. If RBA is absent

The incremental checkpoint is used to balance the load. It is triggered by the fast_start_mttr_target parameter and is incrementally written out. Therefore, CHECKPOINT_CHANGE # will have a delay and will not be updated immediately.
Three methods are used to prove the problem:
Method 1:
Theory: logs are active, that is, logs overwritten by RBA pointers. If the checkpoint is complete, RBA will immediately redo the last entry of the log group. Without RBA, the log state is inactive. If the checkpoint is incremental, RBA will move slowly down, all RBA-covered instances are active. Oracle always wants the shortest distance between RBA and the last redo log group. The incremental checkpoint is to move it from time to time.
Lab:
SQL> alter system switch logfile;

System altered

SQL> select group #, status from v $ log;

GROUP # STATUS
--------------------------
1 CURRENT
2 INACTIVE
3 ACTIVE

SQL> alter system switch logfile;

System altered

SQL> select group #, status from v $ log;

GROUP # STATUS
--------------------------
1 ACTIVE
2 CURRENT
3 ACTIVE

Method 2:
Theory: not all incremental checkpoints are written, so checkpoint_change # is not updated immediately. But it is a full checkpoint. Because all writes are performed, checkpoint_change # is updated immediately.
Lab:
SQL> select checkpoint_change # from v $ database;

CHECKPOINT_CHANGE #
------------------
1716093

SQL> alter system checkpoint;

System altered

SQL> select checkpoint_change # from v $ database;

CHECKPOINT_CHANGE #
------------------
1716275

Method 3:
Lab:
SQL> show parameter log_checkpoints_to _

NAME TYPE VALUE
-----------------------------------------------------------------------------
Log_checkpoints_to_alert boolean FALSE

SQL> alter system set log_checkpoints_to_alert = true;

System altered

SQL> alter system checkpoint;

System altered

Manually trigger a full checkpoint. The alarm log is recorded as follows:
Thu Jun 07 01:27:17 2012
Beginning global checkpoint up to RBA [0x2d. 1e4. 10], SCN: 1716634
Completed checkpoint up to RBA [0x2d. 1e4. 10], SCN: 1716634

Next, manually trigger an incremental checkpoint:
SQL> alter system switch logfile;

System altered
The alarm log is as follows:
Thu Jun 07 01:28:15 2012
Beginning log switch checkpoint up to RBA [0x2e. 2.10], SCN: 1716660
Thread 1 advanced to log sequence 46
Current log #3 seq #46 mem #0: D: \ ORACLE \ PRODUCT \ 10.2.0 \ ORADATA \ ORCL \ ONLINELOG \ O1_MF_3_7TQZWZOY_.LOG
Current log #3 seq #46 mem #1: D: \ ORACLE \ PRODUCT \ 10.2.0 \ FLASH_RECOVERY_AREA \ ORCL \ ONLINELOG \ O1_MF_3_7TQZX11D_.LOG

From the two alarm logs, we can see that the full checkpoint will immediately move the RBA down, and the incremental checkpoint will take a long time.

For more information about Oracle, see the Oracle topic page? Tid = 12