An atypical ORA-01555 Solution

ORA-01555: the snapshot is too old. A classic problem for ORACLEDBA. Root Cause: consistency reads the problem. I saw a classmate on the Internet. For example,

ORA-01555: the snapshot is too old. A classic problem for ORACLE DBAs. Root Cause: consistency reads the problem. I saw a classmate on the Internet. For example,

ORA-01555: the snapshot is too old. A classic problem for Oracle DBAs.
Root Cause: consistency reads the problem.

I saw a classmate on the Internet. For example, I thought it was good. I 'd like to use it:
Suppose there is a table named table1 with 50 million rows of data. It is estimated that it will take one hour to scan the entire table once. We can see from the process:

1. At one o'clock, A user A sent A select * from table1; no matter how table1 changes in the future, the correct result should be that user A will see the content at one o'clock. There is no doubt about this.
2. At 01:30, user B executed the update command to update the record of 4,000th million rows in table 1, user A's full table scan has not reached 4,000th million. Undoubtedly, at this time, the record of 4,000th million rows was written into the rollback segment. I assume it is the rollback segment RBS1, if user A's full table scan reaches 4,000th million rows, it should correctly read the one o'clock contents from the rollback segment RBS1.
3. At this time, user B will commit the operation he just made, but at this time, the system can still provide user A with the correct data, because the contents of the 4,000th million rows record are still in the rollback segment RBS1, the system can find the correct data in the rollback segment according to the SCN, but you have noticed that, at this time, the 4,000th million rows of records recorded in RBS1 have undergone a major change: The 4,000th million rows of data in the rollback segment RBS1 may be overwritten at any time, because this record has been submitted !!!
4. Because user A has been querying for A long time and the service is continuously running, the RBS1 rollback segment is used by multiple different tracnsactions, the extent in This rollback segment loops to the extent where 4,000th million rows of data are located. Because this record has been marked and submitted, this extent can be overwritten by other transactions!
5. At 01:40, user A's query finally reached 4,000th million rows, and now there are already 4th cases, so we need to go to the rollback segment RBS1 to find the data, but it has been overwritten, so 01555 will appear.

The ORA-01555 that appears this time, cause very special reason.
The error message is that the rollback segment SYSSMU1 has a problem.
Therefore, it is concluded that the consistency read error is not caused by a large number of reads and writes, and the snapshot has a problem due to the rollback segment error.

First, observe the rollback segment:
SQL> select segment_name, tablespace_name, status from dba_rollback_segs;
It is found that the rollback segment _ SYSSMU1 $-10 $ of the tablespace UNDOTBS1 is online.
We found that the rollback segment SYSSMU1 of the tablespace UNDOTBS2 was actually the needs recovery, and the rest were offline.
The most interesting thing is that the specified UNDO in this database is UNDOTBS1, and UNDOTBS2 is actually discarded.

Delete the rollback segment after offline, but the error message is invalid.
After the database is restarted, the rollback segment status changes to availabe.
If you try offline again, you are still prompted to use it.

Directly update the data dictionary
SQL> update undo $ set status $ = 2 where;
If the status of the rollback segment is changed to offline, drop it.
ORA-1555 no longer appears.