Ensure that you have performed a clean shutdown; if not, you may see this error:

ORA-00265: instance recovery required, cannot set ARCHIVELOG mode.

1. Start the database in the MOUNT state.

2. Enable the archive log mode and open the database as follows:

3. Check if archiving has been enabled or not.

After enabling the archive log mode, perform a LOG SWITCH and check whether the archive log is created or not
from the V$ARCHIVED_LOG view, as follows:
SQL> SELECT * FROM V$ARCHIVED_LOG;

FORCE LOGGING

When the redo/ archived logfile containing the NOLOGGING operation is used to recover the datafiles on the
standby database, Oracle invalidates such blocks and the error ORA-26040 along with error ORA-1578 are
reported by SQL statements in the next block reads. You can see the following errors if operations are performed
by NOLOGGING:

ORA-01578: ORACLE data block corrupted (file # 4, block # 84)

ORA-01110: data file 4: ' /u01/app/oracle/oradata/orcl/users01.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option

1. Check the force logging status as follows:

2. Enable the force logging mode and check the force logging status again as follows
 Enabling FORCE LOGGING on Primary Database is MANDATORY.

In the alert log, you will see following lines:

[oracle@rac-node1 trace]$ pwd

/u01/app/oracle/diag/rdbms/cdb1/CDB1/trace

[oracle@rac-node1 trace]$ vi alert_CDB1.log

STANDBY REDO LOGS

 Standby redo logfiles (SRL) are used by a standby database to store the redo received from the
primary database. The redo received by a standby database via redo transport is written to the
current SRL group by the Remote File Server (RFS) background process. When a log switch occurs on
the primary database, RFS writes the redo to the next standby redo log group and the previously
used standby redo log group is archived on the standby database by an ARCn process.

 The SRL files must be the same size as your online redo log (ORL) files. You also need to have enough
SRL groups; that is, one more than the number of ORL groups

 On RAC databases, you should create n+1 SRL groups for each thread. For example, in an RAC
primary database with two instances and three ORL groups per instance, we should create 2*(3+1)
SRL groups (that is, 8 groups).

 We will use the RMAN DUPLICATE method to create the physical standby database; if SRLs exist on primary,
they'll be automatically created on standby.

1. Check the ORL's members and the sizes of each member as follows:
SELECT A.GROUP#, A.STATUS, A.BYTES/1024/1024 SIZEMB, B.MEMBER

FROM V$LOG A, V$LOGFILE B WHERE A.GROUP#=B.GROUP# ORDER BY GROUP#;

 In this single instance of the primary database, we have 3 ORL groups, each with one member
and a size of 200 MB. We should create at least 4 SRL groups.

2. Add the SRL as shown in the following example:

ALTER DATABASE ADD STANDBY LOGFILE GROUP 11 ('
/u01/app/oracle/oradata/cdb1/sdby01.log') SIZE 200M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 12 ('

/u01/app/oracle/oradata/cdb1/sdby02.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 13 ('
/u01/app/oracle/oradata/cdb1/sdby03.log') SIZE 200M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 14 ('

/u01/app/oracle/oradata/cdb1/sdby04.log') SIZE 200M;

ERROR at line 1:
ORA-00301: error in adding log file '
/u01/app/oracle/oradata/cdb1/sdby01.log' - file cannot be created
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 1

ALTER DATABASE ADD STANDBY LOGFILE GROUP 11 ('/u01/app/oracle/oradata/cdb1/sdby01.log') SIZE 200M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 12 ('/u01/app/oracle/oradata/cdb1/sdby02.log') SIZE 200M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 13 ('/u01/app/oracle/oradata/cdb1/sdby03.log') SIZE 200M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 14 ('/u01/app/oracle/oradata/cdb1/sdby04.log') SIZE 200M;

3. Check the status of new the standby redo logfiles:

SELECT GROUP#, BYTES/1024/1024 AS "Size(MB)" ,STATUS FROM V$STANDBY_LOG;

FAST RECOVERY AREA (FRA)

Prior to 11g R2, FRA stood for Flash Recover Area, but since Oracle Database 11g R2, FRA stands for Fast
Recovery Area. It's a place on the disk where the database automatically manages naming, retention, and
deletion of recovery-related files. FRA can contain control files, online redo logfiles, archived redo logs,
flashback logs, and RMAN backups. It's not mandatory but strongly recommended to configure FRA.

1. Check the default FRA location as follows:

SHOW PARAMETER DB_RECOVERY_FILE_DEST
2. Configure the FRA size.

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=12G;

3. Configure the FRA destination.

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/u01/app/oracle/recovery_area';

 In RAC databases, use the keyword SID='*'; this ensures that the change will apply to all instances in
the cluster.

Understanding initialization parameters

DB_NAME
The DB_NAME parameter specifies the database identifier up to eight characters. This parameter must be the
same in all the instances of the RAC database and also in the physical standby database.

DB_UNIQUE_NAME
This parameter specifies a unique name for each database having the same DB_NAME parameter. This
parameter must be different on the primary, standby, or logical standby database. The DB_UNIQUE_NAME
parameter is limited to 30 characters. It can contain alphanumeric, underscore (_), dollar ($), and pound (#)
characters but must begin with an alphabetic character. This parameter is static, so it requires bouncing the
database in order to change this parameter
ALTER SYSTEM SET DB_UNIQUE_NAME='TURKEY_UN' SCOPE=SPFILE;

 The DB_UNIQUE_NAME parameter allows a location-specific alias to be created for a database. It is

better to avoid using names related to the role, such as primary and standby

 The DB_UNIQUE_NAME parameter will be the same in all RAC databases across all instances. In RAC
databases, only the instances are hosted in different nodes but they are using only one database…

The following table shows the naming format that we are going to use for the physical standby Data Guard
configuration example:

PARAMETER PRIMARY PHYSICAL STANDBY

Instance name CDB1IDC1 CDB1IDC2
DB_NAME CDB1 CDB1
DB_UNIQUE_NAME CDB1_DC1 CDB1_DC2
Net Service Name CDB1IDC1 CDB1IDC1
LOG_ARCHIVE_CONFIG
Its default value is SEND, RECEIVE, NODG_CONFIG and we only need to update the DG_CONFIG part as
follows:
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(CDB1_DC1, CDB1_DC1)'
SCOPE=both;

LOG_ARCHIVE_MAX_PROCESSES
This parameter specifies the number of archiver processes in a database. In Data Guard, it's important to
have enough archiver processes on the primary database. Think of the value of this parameter as the number
of channels where redo can be transferred to the standby database. In peak database times and in gap
resolution, if the number of the LOG_ARCHIVE_ MAX_PROCESSES value is not sufficient on the primary
database, redo shipping may suffer.

LOG_ARCHIVE_DEST_n
Where n is from 1 to 31 in 11g R2

 LOCATION and SERVICE

ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/u01/app/oracle/oraarch';

ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST';

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=CDB1IDC2 DB_UNIQUE_NAME=

CDB1_DC2';

 VALID_FOR
This attribute specifies in which states the destination will be valid…

REDO_LOG_TYPE can be set to the following values:

ONLINE_LOGFILE is valid only when archiving online redo logfiles
STANDBY_LOGFILE is valid only when archiving standby redo logfiles
ALL_LOGFILES is valid when archiving either ORLs or SRLs (DEFAULT)

DATABASE_ROLE can be set to the following values:

PRIMARY_ROLE is valid only when the database role is primary
STANDBY_ROLE is valid only when the database role is standby
ALL_ROLES is valid when the database is either primary or standby (DEFAULT)

 SYNC and ASYNC

 ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=CDB1IDC2 LGWR ASYNC
DB_UNIQUE_NAME=CDB1_DC2';

 AFFIRM and NOAFFIRM

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=CDB1IDC2 LGWR ASYNC NOAFFIRM
DB_UNIQUE_NAME=CDB1_DC2';

SQL> SELECT AFFIRM FROM V$ARCHIVE_DEST WHERE DEST_ID=2;

AFF

---

NO

 COMPRESSION
This attribute is used to specify whether redo data is compressed before transmission.

 You should remember that compression is a CPU-intensive operation and this compression is an
option of ORACLE ADVANCED COMPRESSION; so, in order to enhance this feature you must purchase
a license.

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=CDB1IDC2 LGWR ASYNC NOAFFIRM

COMPRESSION=ENABLE DB_UNIQUE_NAME=CDB1_DC2';

log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_
FOR=(ALL_LOGFILES,ALL_ROLES)'

log_archive_dest_2='SERVICE=CDB1IDC2 LGWR ASYNC VALID_FOR=(ONLINE_

LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=CDB1_DC2'

 LOG_ARCHIVE_DEST_STATE_n
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2='defer';
 Creating the physical standby database

1. Set the standby database initialization parameters: