Restore non-critical Oracle files, redo, temporary files, index files, and password files

Restore non-critical Oracle files, redo, temporary files, index files, and password files

Restore non-critical Oracle files, redo, temporary files, index files, and password files

The Application of Incremental backup is in the rediscovery stage and is no longer in the restore stage.

Learn about the database settings table:
SQL> desc database_properties
Name Null? Type
-----------------------------------------------------------------------------
PROPERTY_NAME not null VARCHAR2 (30)
PROPERTY_VALUE VARCHAR2 (4000)
DESCRIPTION VARCHAR2 (4000)

Critical and non-critical
Non-critical files are files that can continue to run without the database and most applications. For example, if the database loses a multiplexing redo log file, you can still use copies of other redo log files to keep the database running continuously.
Although the loss of non-critical files will not cause database crashes, it will weaken the function of the database. For example, the loss of index tablespaces can significantly slow down the running of applications and queries, or if these indexes are used to enforce constraints, the loss may even lead to application unavailability.
The loss of the online redo log group (as long as it is not the current online log group) will cause the database operation to be suspended when LGWR attempts to write data to the group next time until a new log file is generated.

The loss of temporary tablespace will make the user unable to run queries or create indexes until these users are allocated to the new temporary tablespace.
-- A temporary tablespace is lost at 10 Gb, and the database cannot be started. When a temporary file is lost at 11 GB, the database automatically creates a temporary file with the same name and bit;
-- When this happens in 11g, the following message is displayed in the warning log during startup:
--
Re-creating tempfile/u01/app/Oracle/oradata/orcl/temp01.dbf
Bytes ----------------------------------------------------------------------------------------------------------------

Redo log modification and Reconstruction

Undo tablespace and redo logs

I. Log member loss:
To deal with the loss of redo log files, it is very important to understand the possible status of the redo log group. During the normal operation of Oracle DB, redo log groups go through three different states cyclically. In the order of loops, the statuses are:

CURRENT: this status indicates that LGWR is writing data to the redo log group to record the redo data of all ongoing transactions in the database. This log group remains in this status until it is switched to another log group.

ACTIVE: The redo log group still contains the redo data required to restore the instance. This is the status of the redo log group before the checkpoint is executed. All data changes in the redo log group will be written into the data file.

INACTIVE: the checkpoint has been executed. This indicates that the redo log group is no longer required to restore the instance. It can be changed to the next CURRENT log group.

Operations on online redo logs:

View the status of the log group:
SQL> select GROUP #, SEQUENCE #, MEMBERS, ARCHIVED, STATUS from v $ log;

GROUP # SEQUENCE # MEMBERS ARC STATUS
-------------------------------------------------
1 7 2 YES INACTIVE
2 8 2 NO CURRENT
3 6 2 YES INACTIVE
View the log file status:
SQL> select GROUP #, TYPE, MEMBER from v $ logfile;

GROUP # TYPE MEMBER
---------------------------------------------------------------------------
3 ONLINE
/U01/app/oracle/oradata/PROD/onlinelog/o1_mf_3_b22567o2 _. log

3 ONLINE
/U01/app/oracle/fast_recovery_area/PROD/onlinelog/o1_mf_3_b2256827 _. log

2 ONLINE
/U01/app/oracle/oradata/PROD/onlinelog/o1_mf_2_b2255zsg _. log

2 ONLINE
/U01/app/oracle/fast_recovery_area/PROD/onlinelog/o1_mf_2_b22560gb _. log

1 ONLINE
/U01/app/oracle/oradata/PROD/onlinelog/o1_mf_1_b2255npg _. log

1 ONLINE
/U01/app/oracle/fast_recovery_area/PROD/onlinelog/ow.mf_1_b2255nxl _. log

-- Delete the original log group. (only the inactive log group is operated)
-- If the operation log group is current, you must switch the Log First: alter system switch logfile;
-- If it is active, you can force the checkpoint: alter system checkpoint;

1. operation log file;

1) when a data file in a log group is lost, add it before deleting it online;

Alter database add logfile member '/u01/app/oracle/oradata/PROD/onlinelog/o1_mf_2_ B _. log' to group 2;

Alter database drop logfile member '/u01/app/oracle/oradata/PROD/onlinelog/o1_mf_1_b2255npg _. log' to group 2;

2) Add a group online and add another member;

SQL> alter database add logfile group 4'/u01/app/oracle/oradata/ORCL/onlinelog/redo04.log 'size 100 m;

SQL> alter database add logfile member '/u01/app/oracle/oradata/ORCL/onlinelog/redo04_ B .log' to group 4;

3) view the log group and its members;
SQL> select GROUP #, members, BYTES/1024/1024 size_M, STATUS, ARCHIVED from v $ log;

2. Log File loss, restart, or alter system switch logfile trigger error. In the production database, it is generally a log switch trigger error;

1) Loss of Non-current redo log groups

Select a. group #, a. status, a. archived, B. member from v $ log a, v $ logfile B where a. group # = B. group #;
-- Check the status of the log group and the position of the file