Check Whether Archiving Has Been Enabled or Disabled, As Follows
Check Whether Archiving Has Been Enabled or Disabled, As Follows
Check Whether Archiving Has Been Enabled or Disabled, As Follows
Ensure that you have performed a clean shutdown; if not, you may see this error:
ORA-00265: instance recovery required, cannot set ARCHIVELOG mode.
4. Enable the archive log mode and open the database as follows:
5. 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:
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
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
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
In RAC databases, use the keyword SID='*'; this ensures that the change will apply to all instances in
the cluster.
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 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:
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
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.
log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_
FOR=(ALL_LOGFILES,ALL_ROLES)'
LOG_ARCHIVE_DEST_STATE_n
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2='defer';
Creating the physical standby database