Showing posts with label Redo Log files. Show all posts
Showing posts with label Redo Log files. Show all posts

Friday, January 12, 2024

Syntax for dropping standby redo logs

In one of my primary databases, I had several old standby redo log files that were forgotten from a previous relocation using Data Guard. They could all be dropped at this point.

set lines 200
col member format a50
select s.group#,s.thread#,s.sequence#,s.archived,s.status,f.member, f.type
from v$standby_log s, v$logfile f
where f.type = 'STANDBY'
and s.group# = f.group#;

    GROUP#    THREAD#  SEQUENCE# ARC STATUS     MEMBER                                             TYPE
---------- ---------- ---------- --- ---------- -------------------------------------------------- -------
         6          1          0 YES UNASSIGNED /data03/oradata/prod01/onlinelog/stb_redo06.log         STANDBY
         7          1          0 YES UNASSIGNED /data03/oradata/prod01/onlinelog/stb_redo07.log         STANDBY
         8          1          0 YES UNASSIGNED /data03/oradata/prod01/onlinelog/stb_redo08.log         STANDBY
         9          1          0 YES UNASSIGNED /data03/oradata/prod01/onlinelog/stb_redo09.log         STANDBY
        10          1          0 YES UNASSIGNED /data03/oradata/prod01/onlinelog/stb_redo10.log         STANDBY
        11          1          0 YES UNASSIGNED /data03/oradata/prod01/onlinelog/stb_redo11.log         STANDBY
Syntax for dropping:
SQL> alter database drop standby logfile group n;
In my case
alter database drop standby logfile group 6;
alter database drop standby logfile group 7;
etc etc.


The official Oracle 19c Alter Database documentation is here

Monday, December 5, 2022

How to avoid redo logs and standby redo logs being created as OMF files during a DUPLICATE ... FOR STANDBY operation

Recently I had to create a Data Guard physical standby database, and I used RMAN active database duplication ( "duplicate target database for standby from active database" ) to create the database on the remote server.

As the remote server had the same file system layout as the primary, I used the directive
NOFILENAMECHECK
in the duplicate command.

Consequently, I expected all datafiles, including the redo and standby redo log files, to be created in exactly the same location as the target.

For some reason this did not happen; in fact, they were named with OMF file names, and placed in the db_recovery_file_dest which point to the path /recovery_data, while on the primary, the same files reside in /u02/oradata

I found the solution based on a post called "JoeLi's TechLife" and added my own experience to find a workaround.

The author points out

after the duplication, all other files seem to be fine regarding their names and locations except for redo log files and standby redo log files. They are created under the fast recovery area with OMF file names!

How come? Well here is the reason — duplicate will always re-create redo log files and standby redo log files. And because DB_RECOVERY_FILE_DEST is defined on the Primary server, redo and standby redo log files are created as OMF despite NOFILENAMECHECK is used. And they are not multiplexed as you have on the Primary database!


I was not aware of this.

The author continues to point out that he hasn't found a solution, yet.

The proposed solution according to Joe is

... to recreate redo log and standby redo log files on the newly created standby server — basically dropping the OMF ones and creating them under the correct locations with correct file names.

I did however, find a solution, which worked for me and was really quite simple, although not very intuitive: simply set the directive log_file_name_convert in your clone script, like examplified below:

connect target sys/password@primary
connect auxiliary target sys/password@stb
run{
        allocate channel c1 type disk;
        allocate channel c2 type disk;
        allocate channel c3 type disk;
        allocate channel c4 type disk;
        allocate auxiliary channel stby type disk;
duplicate target database for standby from active database
spfile
SET DB_UNIQUE_NAME='stb'
SET FAL_CLIENT='stb'
SET FAL_SERVER='primary'
SET LOG_ARCHIVE_DEST_1='location=use_db_recovery_file_dest valid_for=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=stb'
SET LOG_ARCHIVE_DEST_2='' comment 'Must be set to empty string during duplication'
SET STANDBY_FILE_MANAGEMENT='AUTO'
SET DG_BROKER_CONFIG_FILE1='/u01/oracle/product/12c/dbs/dr1stb.dat'
SET DG_BROKER_CONFIG_FILE2='/u01/oracle/product/12c/dbs/dr2stb.dat'
SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(stb,primary)'
SET DG_BROKER_START='TRUE'
SET LOG_ARCHIVE_TRACE='0' comment 'Must be set to same value as primary during duplicaton'
SET dispatchers='(PROTOCOL=TCP) (SERVICE=stbXDB)' comment 'Must be set to unique name of stb db'
SET LOCAL_LISTENER='stb.skead.no' comment 'Must be set to unique name of stb db'
SET LOG_ARCHIVE_FORMAT='%t_%s_%r.dbf' comment 'Must be set to same value as primary during duplicaton'
SET LOG_FILE_NAME_CONVERT='/redodata','/redodata' comment 'Must be set during cloning to avoid OMF naming of redo log files'
NOFILENAMECHECK
USING COMPRESSED BACKUPSET;
}
Aftwards, the query
COL MEMBER FORMAT A50
SET LINES 200
SELECT A.GROUP#,A.MEMBER, B.BYTES/1024/1024 "MB", B.ARCHIVED,B.STATUS,B.SEQUENCE#
FROM V$LOGFILE A INNER JOIN  V$LOG B ON A.GROUP# = B.GROUP#
ORDER BY GROUP# ASC;

set lines 200
col member format a50
select s.group#,s.thread#,s.sequence#,s.archived,s.status,f.member, f.type
from v$standby_log s, v$logfile f
where f.type = 'STANDBY'
and s.group# = f.group#;

confirms that the standby database was created with non-OMF datafiles:
SQL> @chk_redo.sql

    GROUP# MEMBER                                                     MB ARC STATUS            SEQUENCE#
---------- -------------------------------------------------- ---------- --- ---------------- ----------
         1 /redodata/redo01.log                            2048 NO  CURRENT                 156
         2 /redodata/redo02.log                            2048 YES UNUSED                    0
         3 /redodata/redo03.log                            2048 YES UNUSED                    0


    GROUP#    THREAD#  SEQUENCE# ARC STATUS     MEMBER                                             TYPE
---------- ---------- ---------- --- ---------- -------------------------------------------------- -------
         4          1          0 YES UNASSIGNED /redodata/stb_redo01.log                  STANDBY
         5          1          0 YES UNASSIGNED /redodata/stb_redo02.log                  STANDBY
         6          1          0 YES UNASSIGNED /redodata/stb_redo03.log                  STANDBY
         7          1          0 YES UNASSIGNED /redodata/stb_redo04.log                  STANDBY

Wednesday, May 12, 2021

How to clear a standby redo logfile and then dropping it

During set up of a physical standby database, one of the standby redo logfiles was marked as "ACTIVE" when querying the v$standby_log:
  THREAD#     GROUP#  SEQUENCE#      BYTES ARCHIVED  STATUS
---------- ---------- ---------- ---------- --------- ------------------------------
         0         12          0 2097152000 YES       UNASSIGNED
         0         13          0 2097152000 YES       UNASSIGNED
         0         14          0 2097152000 YES       UNASSIGNED
         0         15          0 2097152000 YES       UNASSIGNED
         0         16          0 2097152000 YES       UNASSIGNED
         0         17          0 2097152000 YES       UNASSIGNED
         0         18          0 2097152000 YES       UNASSIGNED
         1         11     392344 2097152000 YES       ACTIVE
The file is not even existing on my system, but the path was somehow copied from the primary database, which has a different file structure.
The query:
SELECT thread#, group#, sequence#, bytes, archived, status FROM v$standby_log order by thread#, group#;

would return

  GROUP# TYPE                  MEMBER
---------- --------------------- ------------------------------------------------------------
        11 STANDBY               /backup/fast_recovery_area/PRODDB01/onlinelog/stb_redo01.log
The path /backup/fast_recovery_area/PRODDB01/onlinelog doesn't even exist on my server. This makes it impossible to drop and recreate it:
SQL> alter database drop standby logfile group 11;
alter database drop standby logfile group 11
*
ERROR at line 1:
ORA-00313: open failed for members of log group 11 of thread 1
ORA-00312: online log 11 thread 1:
'/fra/stdb/onlinelog/stb_redo01.log'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Solution: Clear the logfile:
SQL> alter database clear logfile group 11;

Database altered.
Then drop and recreate the standby redo logfile:
SQL> alter database drop standby logfile group 11;

Database altered.

SQL> alter database add standby logfile group 11 ('/data1/oradata/PRODDB01/stb_redo01.log') size 2000M;

Tuesday, January 29, 2019

The difference between REDO and UNDO


UNDO REDO
Used during normal database operations Used during instance and media recovery only
Contains changed column values Contains "change vectors", a description of a change made to a single block
Stored inside the database, in a separate tablespace Stored outside the database, in redo log files
Can be utilized for many purposes Has one purpose only

The redo log files has one and only one purpose in life: instance recovery.
The undo tablespace(s) has one primary purpose in life: to support read-consistency. However, unlike redo, UNDO data can also be utilized for many other purposes, like Oracles flashback technologies.

Oracle 12.2 Documentation about the redo logs can be found here

Wednesday, November 18, 2015

How to drop a redo logfile group and redo logfile group members - syntax

alter database drop logfile group 4;

The drop statement will be confirmed by an entry in the database's alert log.

Don't forget to physically remove the file from disk afterwards.

You can also drop individual Group members:
alter database drop logfile member '/u03/oradata/proddb01/red04a.log';

Pay attention to the restrictions when dropping redo log groups and redo log members!

A good Query for redo log file information can be found here

Query to find basic redo log information

COL MEMBER FORMAT A50
SET LINES 200
SELECT A.GROUP#,A.MEMBER, B.BYTES/1024/1024 "MB", B.ARCHIVED,B.STATUS,B.SEQUENCE#
FROM V$LOGFILE A INNER JOIN  V$LOG B ON A.GROUP# = B.GROUP#
ORDER BY GROUP# ASC;
Result:

GROUP# MEMBER MB ARCHIVED STATUS SEQUENCE#
1
/u04/oradata/proddb01/log1a.ora
1024
YES INACTIVE
90510
1
/u04/oradata/proddb01/log1b.ora
1024
YES INACTIVE
90510
2
/u04/oradata/proddb01/log2b.ora
1024
YES INACTIVE
90511
2
/u04/oradata/proddb01/log2a.ora
1024
YES INACTIVE
90511
3
/u04/oradata/proddb01/log3b.ora
1024
NO CURRENT
90508
3
/u04/oradata/proddb01/log3a.ora
1024
NO CURRENT
90508

Thursday, May 7, 2015

How to add a logfile group and a logfile member - syntax

alter database add logfile group 2
(
'/u01/app/oracle/flash_recovery_area/mydb/onlinelog/redo02a.log',
'/u01/app/oracle/oradata/mydb/onlinelog/redo02b.log'
) size 50M;

Remember, if you have just recently dropped the redo log members, they are still present physically on disk.
If you'd like to reuse the log file member names, and to avoid

ORA-00301: error in adding log file /u03/oradata/arutvt/redo03.log - file cannot be created,

add the REUSE keyword at the end of the statement:

alter database add logfile group 3 ('/u03/oradata/mydb/redo03.log') size 1024M REUSE;
To add another member to an already existing group:
ALTER DATABASE ADD LOGFILE MEMBER '/u03/oradata/mydb/redo03.log' TO GROUP 3;
If the redo log file member is already present on disk, use reuse:
ALTER DATABASE ADD LOGFILE MEMBER '/u03/oradata/mydb/redo3b.log' REUSE TO GROUP 3;

If you do not specifically say which log group number you want to create, Oracle will take add another group based on the largest log file group number in v$logfile. So if I have 3 groups already, and execute
alter database add logfile '/rdodata/mydb/redo04.log' size 2048M;
It will create group number 4 for you, even if you do not explicitly say so:
SYS@cdb>SQL>@redo

    GROUP# MEMBER                                                     MB ARC STATUS            SEQUENCE#
---------- -------------------------------------------------- ---------- --- ---------------- ----------
         1 /rdodata/mydbredo01.log                              2048 YES INACTIVE                220
         2 /rdodata/mydb/redo02.log                             2048 YES INACTIVE                221
         3 /rdodata/mydb/redo03.log                             2048 NO  CURRENT                 222
         4 /rdodata/mydb/redo04.log                             2048 YES UNUSED                    0


Documentation for Oracle 19c is found here