[Translated from mos] After recreating the control file, the Missed Database Supplemental Log Information and database

[Translated from mos] After recreating the control file, the Missed Database Supplemental Log Information and database
After the control file is rebuilt, the Supplemental Log Information of the Database (Missed Database Supplemental Log Information) is lost)

Reference Original:
Missed Database Supplemental Log Information After Recreate Controlfile In 10g Database. (Doc ID 1474952.1)

Applicable:
Oracle Server-Enterprise Edition-Version 10.1.0.2 and later
Information in this document applies to any platform.

Symptoms:
You have rebuilt the control file and noticed that the Supplemental Log Information of the Database (Missed Database Supplemental Log Information) has been reset. You can query it through the following SQL:

SQL> SELECT supplemental_log_data_min min_log,            supplemental_log_data_pk pk_log,            supplemental_log_data_ui ui_log,            supplemental_log_data_fk fk_log,            supplemental_log_data_all all_log,            force_logging force_log     FROM v$database;

Note: When you use the following features: Logminer, Streams or Standby Databases, you need to add log information.

Change:
This problem occurs after the control file is rebuilt.

Cause:
Once you use the create controlfile command to recreate the control file, the session of the control file Supplemental log will be reset to the default value. The default value is that all Supplemental log levels are off.

Solution:

We strongly recommend that you use alter database backup controlfile to trace when recreating the control file; the generated trace file TO recreate the control file.

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

Note: after this command has been executed, this trace file will be available under udump.

In the text section of the trace file, you will find the alter database supplemental log command, which corresponds to the supplemental log information used by the database before the control file is rebuilt.

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX, FOREIGN KEY, ALL) COLUMNS;

After recreating the control file, you must execute the preceding statement (the statement is in the text section of the trace file)
Oracle uses redo logs and control files to restore data that lacks data files?

I recommend a software to you to see if it can help you.

FROMBYTE Reconstructor for Oracle is a software product used to restore ORACLE database files. It mainly serves to reorganize ORACLE Database fragments and export complete files.
I. Applicable disaster situations:
(1) the ORACLE database file is deleted by mistake.
(2) Storage repartitioning and formatting result in the loss of ORACLE Database files.
(3) Sudden storage power failure, file system failure, and fsck cause ORACLE database file loss.
(4) ORACLE database files are lost due to an ASM storage failure.
Ii. Supported file system features:
(1) Supported file system types: NTFS/EXT3/EXT4/REISERFS/REISER4/XFS/HTFS/UFS1/UFS2/JFS1/JFS2/VXFS/ASM.
(2) Supported file system platforms: Little Endian/Big Endian.
(3) Supported file system blocks: 512 Bytes/1 KB/2 KB/4 KB/8 KB/16 KB/32 KB.
Iii. Supported database features:
(1) supported database versions: ORACLE 8i/ORACLE 9 I/ORACLE 10g/ORACLE 11g.
(2) supported database Tablespace modes: Smallfile Tablespace/Bigfile Tablespace.
(3) Size of supported database file blocks: 512 Bytes/1 KB/2 KB/4 KB/8 KB/16 KB/32 KB and custom block size.
4. Other features:
(1) supports Virtual Disk file scanning and recovery.
(2) You can save the current scan information or load saved scan information.
(3) allows you to create a custom disk scan area or an ASM disk group.
(4) supports tens of millions of File Fragment scans and a variety of different buffer sizes.
(5) supports filtering and searching by database file ID/Size/Integrity/Version/Block Size (for database files ).
(6) supports filtering and searching by File ID/Block Count/Block Size of database File fragments (for database File fragments ).
(7) Support Generating technical reports on database file recoverability.

Is it appropriate to place database files, backup files, and log files on the same hard disk during database configuration? And describe the reason

It doesn't matter. I am A, B, two sets of servers. All backups are stored in files from the disk, including photos uploaded by the client, Database backups are stored in the shared folder, and shared to another server. In case of a fault, you can switch the server account set and import the data if necessary. In other words.