If the data of the oracle business table is added, deleted, or modified, will the index of the table write redo and undo?

When we insert a piece of data, first the action will be recorded in the redo log, the operation will also be recorded in the undo, the action of the undo itself will also be recorded in the redo log as a piece of data, insert a piece of data,The index (indexes) will change, and the change of the index will also make a data record to the redo log

Index maintenance will also generate corresponding redo logs
This ensures that the corresponding index will also be changed when applying log recovery

Of course.

Keep in mind an essential principle that redo information will be recorded for operations involving block changes.

If you think about delayed block clearing, it's just that changes in transaction slots in the database will record redo (the essential reason why select will cause redo in some cases), not to mention the relatively "heavyweight" operation of maintaining indexes.

I thought about it again, I personally think that the operation of automatically updating the index with the addition, deletion and modification of the table will not record redo and undo.(Do not consider the DDL situation of manual addition, deletion, rebuilding, and index modification.)
Because: the update of the index occurs automatically according to the addition, deletion and modification of the table. If the index or index-related change information also records redo and undo, thenWhen doing rollback and rollforward, the automatic index maintenance mechanism and the index change update registered in the rollforward (rollback) will conflict.

I think so.Let me tell you what I understand: In oracle, indexes and data belong to different segments, and the bottom layer is a block. To delete a piece of data, you need to maintain the index tree, and you need to operate the block. In order to achieve crash recovery, it is necessary to change these changes.Both are written to the redo log, and I guess, if they are written together with the redo of the data block, if they belong to two atomic operations, then the transactionality of these two operations must be guaranteed.

Just test it yourself, it's clear at a glance, why guess, just by feeling?

SQL> create table t1 (id number);Table created.SQL> insert all 2 into t1 values(1) 3 into t1 values(2) 4 into t1 values(3)5 select 1 from dual;3 rows created.SQL> commit;Commit complete.SQL> create index idx_t1 on t1(id);Index created.SQL> select current_scn from v$database;CURRENT_SCN----------- 46939397SQL> update t1 set id=5 where id=3;1 row updated.SQL> commit;Commit complete.SQL> select current_scn from v$database;CURRENT_SCN----------- 46939443SQL> altersystem dump logfile '/u01/app/oracle/oradata/HKORA/onlinelog/o1_mf_3_j7z2qcb9_.log' scn min 46939397 scn max 46939443;System altered.SQL> @tracefileVALUE------------------------------------------------------------------------------------------------------------------------------------------------------/u01/app/oracle/diag/rdbms/hkora/hkora/trace/hkora_ora_15168.trcSQL> select object_id from dba_Objects where object_Name='T1' and owner='DEVIN'; OBJECT_ID---------- 82502SQL> select object_id from dba_Objects where object_Name='IDX_T1'; OBJECT_ID---------- 82503

CHANGE #3 CON_ID:0 TYP:2 CLS:1 AFN:8 DBA:0x0200240c OBJ:82502 SCN:0x0000000002cc3cbe SEQ:1 OP:11.5 ENC:0 RBL:0 FLG:0x0000

CHANGE #2 CON_ID:0 TYP:0 CLS:1 AFN:8 DBA:0x02002413 OBJ:82503 SCN:0x0000000002cc3cd7 SEQ:1 OP:10.4 ENC:0 RBL:0 FLG:0x0000