How to resize Redo Logs in Dataguard Envrionment in oracle 11g


Primary Database Server: server1.soumya.com
Standby Database Server: server2.soumya.com

Primary Database: prim
Standby database: stand

Database version:11.2.0.1.0

Both the database prim and stand are in sync. For the “Real Time Apply” implementation, we need to make
sure that we have created the Standby Redo Logs on the standby database with the size same as that of the
Online Redo logs in primary database. The Standby Redo Logs also needs to be created on the primary
database, but this is not mandatory. The Standby Redo Logs would not be used on the Primary database until
there is a switchover operation performed and the primary database starts behaving as a standby database.

At Primary Database:
[oracle@server1 ~]$ sqlplus sys/sys@stand as sysdba
SQL> select status,instance_name,database_role from v$database,v$instance;

STATUS       INSTANCE_NAME    DATABASE_ROLE
------------ ---------------- ----------------
OPEN         stand            PHYSICAL STANDBY

SQL> select group#,sum(bytes/1024/1024)"Size in MB" from v$log group by group#;
    GROUP# Size in MB
---------- ----------
         1         50
         2         50
         3         50

SQL> select group#,sum(bytes/1024/1024)"size in MB" from v$standby_log group by group#;

    GROUP# size in MB
---------- ----------
         6         50
         4         50
         5         50
         7         50

At Standby Database:
[oracle@server2 ~]$ sqlplus sys/sys@prim as sysdba
SQL> select status,instance_name,database_role from v$database,v$Instance;

STATUS       INSTANCE_NAME    DATABASE_ROLE
------------ ---------------- ----------------
OPEN         prim             PRIMARY

SQL> select group#,sum(bytes/1024/1024)"Size in MB" from v$log group by group#;

    GROUP# Size in MB
---------- ----------
         1        100
         2        100
         3        100

SQL> select group#,sum(bytes/1024/1024)"Size in MB" from v$standby_log group by group#;

    GROUP# Size in MB
---------- ----------
         6         50
         4         50
         5         50
         7         50
Check if the parameter standby_file_management is set to AUTO or MANUAL on standby database.
If it is not set to MANUAL, then set it.

At standby database:-
SQL> show parameter standby_file_management

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
standby_file_management              string      auto

SQL> alter system set standby_file_management=manual;
System altered.

SQL> show parameter standby_file_management

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
standby_file_management              string      manual

On the primary database(prim), check the status of the Online Redo Logs and resize them by dropping
the INACTIVE redo logs and re-creating them with the new size.

At primary database:-
SQL> select group#,status from v$log;

    GROUP# STATUS
---------- ----------------
         1 INACTIVE
         2 INACTIVE
         3 CURRENT
Here you can see that Online Redo Log groups 1 and 2 are INACTIVE. Hence we can drop them and re-create
with the new size.
SQL> alter database drop logfile group 1;

Database altered.

SQL> alter database add logfile group 1 size 100M;

Database altered.

SQL> select group#,status from v$log;

GROUP# STATUS
------ -------
1      UNUSED
2      INACTIVE
3      CURRENT

SQL> alter database drop logfile group 2;

Database altered.

SQL> alter database add logfile group 2 size 100M;

Database altered.

SQL>
SQL> select group#,status from v$log;

GROUP# STATUS
------ -------
1      UNUSED
2      UNUSED
3      CURRENT

Now that Online Redo Log Groups 1 and 2 are resized and the status of Group 3 is CURRENT, switch logfiles
manually until Group 3 becomes INACTIVE.

SQL> select group#,status from v$log;

GROUP# STATUS
------ -------
1      ACTIVE
2      CURRENT
3      INACTIVE

Now that Group 3 is INACTIVE, we can drop it and re-create it with the new size.

SQL> alter database drop logfile group 3;
Database altered.

SQL> alter database add logfile group 3 size 100M;
Database altered.

Now, we have resized all the Online Redo Logs on the Primary Database from 50M to 100M.
SQL> select group#,sum(bytes/1024/1024)"size in MB" from v$log group by group#;

GROUP# size in MB
------ -------------
1      100
2      100
3      100

Moving on to the Standby Redo Logs on the Primary Database:
SQL> select group#,sum(bytes/1024/1024)"size in MB" from v$standby_log group by group#;

    GROUP# size in MB
---------- ----------
         6         50
         4         50
         5         50
         7         50


SQL> select group#,status from v$standby_log;

    GROUP# STATUS
---------- ----------
         4 UNASSIGNED
         5 UNASSIGNED
         6 UNASSIGNED
         7 UNASSIGNED
The status of the Standby Redo Logs (SRL) on the Primary database would be UNASSIGNED as they would be
used only when the primary database starts behaving as a Standby (Switchover)
We can easily drop the UNASSIGNED SRLs and re-create them with the new size.

At standby database:-
SQL> alter database drop standby logfile group 4;
Now while using the above query i faced an error

SQL> alter database drop standby logfile group 4;
alter database drop standby logfile group 4
*
ERROR at line 1:
ORA-01156: recovery or flashback in progress may need access to files

To solve this issue we have to cancel the recovery on standby database
At standy database:-
SQL> alter database recover managed standby database cancel ;
Database altered.

SQL>  alter database drop standby logfile group 4;
Database altered.
SQL>  alter database drop standby logfile group 5;
Database altered.
SQL>  alter database drop standby logfile group 6;
Database altered.
SQL>  alter database drop standby logfile group 7;
Database altered.

SQL> alter database add standby logfile group 4 size 100M;
Database altered.
SQL> alter database add standby logfile group 5 size 100M;
Database altered.
SQL> alter database add standby logfile group 6 size 100M;
Database altered.
SQL> alter database add standby logfile group 7 size 100M;
Database altered.

SQL> select group#,sum(bytes/1024/1024)"size in MB" from v$standby_log group by group#;

    GROUP# size in MB
---------- ----------
         6        100
         4        100
         5        100
         7        100
Once all the Standby Redo Logs and Online Redo Logs have been resize on both Primary and standby database
set the STANDBY_FILE_MANAGEMENT to AUTO on the standby database and start the recovery (MRP) on standby database.
At standby database:-
SQL> alter system set standby_file_management=auto;
System altered.

To sync both databases we will start recovery process at standby database:-
At standby database:-
SQL> select sequence#, first_time, next_time, applied from v$archived_log order by sequence#;
SEQUENCE# FIRST_TIM NEXT_TIME APPLIED
---------- --------- --------- ---------
        29 28-DEC-14 28-DEC-14 NO
        30 28-DEC-14 28-DEC-14 NO
        31 28-DEC-14 28-DEC-14 NO
        32 28-DEC-14 28-DEC-14 NO
        33 28-DEC-14 28-DEC-14 NO
        34 28-DEC-14 28-DEC-14 NO
        35 28-DEC-14 28-DEC-14 NO
        36 28-DEC-14 28-DEC-14 NO
        37 28-DEC-14 28-DEC-14 NO

SQL> alter database recover managed standby database disconnect from session;

Database altered.

SQL>  select sequence#, first_time, next_time, applied from v$archived_log order by sequence#;
 SEQUENCE# FIRST_TIM NEXT_TIME APPLIED
---------- --------- --------- ---------
        29 28-DEC-14 28-DEC-14 YES
        30 28-DEC-14 28-DEC-14 YES
        31 28-DEC-14 28-DEC-14 YES
        32 28-DEC-14 28-DEC-14 YES
        33 28-DEC-14 28-DEC-14 YES
        34 28-DEC-14 28-DEC-14 YES
        35 28-DEC-14 28-DEC-14 YES
        36 28-DEC-14 28-DEC-14 YES
        37 28-DEC-14 28-DEC-14 YES
SQL> alter database recover managed standby database cancel;

Database altered.
QL> select open_mode from v$database;

OPEN_MODE
--------------------
READ ONLY

SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered.

SQL> select open_mode from v$database;

OPEN_MODE
--------------------
READ ONLY WITH APPLY



At primary database:-
SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
--------------
37

At standby database:-
SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
--------------
37
   

How to enable Block change tracking

RMAN's change tracking feature for incremental backups improves incremental backup performance by recording
changed blocks in each datafile in a change tracking file. If change tracking is enabled, RMAN uses the
change tracking file to identify changed blocks for incremental backup, thus avoiding the need to scan
every block in the datafile.

Prior to 10.2, all incremental backups had to read every single block in the database, and if the block
has changed, it was backed up. This meant the RMAN backup job took nearly as long as a normal full backup
because every block had to be read regardless.

Change tracking is disabled by default, because it introduces some minimal performance overhead on
database during normal operations. However, the benefits of avoiding full datafile scans during backup
are considerable, especially if only a small percentage of data blocks are changed between backups.
If backup strategy involves incremental backups, then we should enable change tracking.

From Oracle 10g, the background process Block Change Tracking Writer (CTWR) will do the job of writing
modified block details to block change tracking file.

Checking Whether Change Tracking is enabled:-
SQL> SELECT status FROM v$block_change_tracking;

STATUS
----------
DISABLED

Enabling and Disabling Change Tracking:-
We can enable or disable change tracking when the database is either open or mounted as sysdba.

To enable:-
SQL> alter database enable block change tracking  using file '/u01/app/oracle/oradata/prim/rman_change_track.f' ;

The REUSE option tells Oracle to overwrite any existing file with the specified name.
SQL> alter database enable block change tracking  using file '/u01/app/oracle/oradata/prim/rman_change_track.f' REUSE;

To disable:-
SQL> alter database disable block change tracking  ;

Moving the Change Tracking File:-
If you need to move the change tracking file, the ALTER DATABASE RENAME FILE command updates the control file
to refer to the new location.

1.Check the file name
SQL> SELECT filename FROM V$BLOCK_CHANGE_TRACKING;

FILENAME
-------------------------------------------------------------
/u01/app/oracle/oradata/prim/rman_change_track.f

2.Shutdown the dbase
SQL> shut immediate;
exit

3.Move the file into different location
[oracle@server1 ~]$mv /u01/app/oracle/oradata/prim/rman_change_track.f /home/oracle/rman_change_track.f

4.Mount the database and move the change tracking file to a location.
SQL> ALTER DATABASE RENAME FILE '/u01/app/oracle/oradata/prim/rman_change_track.f' TO '/home/oracle/rman_change_track.f';

5.Open the database
SQL> alter database open;

6.Determine the new location of block change tracking file
SQL> SELECT filename FROM V$BLOCK_CHANGE_TRACKING;

FILENAME
--------------------------------------------------------------------------------
/home/oracle/rman_change_track.f


If you cannot shutdown the database, then you must disable change tracking and re-enable it, at the new location:
SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/home/oracle/rman_change_track.f';

How to Perform Block Recovery without having RMAN backup

Oracle Version :- 11g
Os Version:-    Rhel 6.4

To demonstrate this scenario we need some corrupted datablocks on some data files.


It’s possible to perform Block Media Recovery with having only OS based “hot” backups and having NO RMAN backups.

Step 1. Create a new user and a table in that schema
[oracle@server1 ~]$ sqlplus /  as sysdba
SQL> create user soumya identified by soumya;
User created.

SQL> grant dba to soumya;
Grant succeeded.

Step 2. Now create a table inside the newly created user
SQL> conn soumya/soumya
Connected.
SQL> create table tbs_corruption (id number);
Table created.

SQL> insert into tbs_corruption values (1);
1 row created.

SQL> commit;
Commit complete.

Step 4. Confirm created user's tablespace and datafile
SQL> COLUMN segment_name FORMAT a45
SQL> SELECT segment_name, tablespace_name from dba_segments WHERE segment_name='TBS_CORRUPTION';
SEGMENT_NAME                                  TABLESPACE_NAME
--------------------------------------------- ------------------------------
TBS_CORRUPTION                                    USERS

SQL> COLUMN segment_name FORMAT a15
SQL> COLUMN tablespace_name FORMAT a15
SQL> COLUMN name FORMAT a45
SQL> SELECT segment_name, a.tablespace_name, b.name FROM dba_segments a, v$datafile b
  2  WHERE a.header_file=b.file# AND a.segment_name=
  3  'TBS_CORRUPTION';

SEGMENT_NAME    TABLESPACE_NAME NAME
--------------- --------------- ---------------------------------------------
TBS_CORRUPTION  USERS           /u01/app/oracle/oradata/prim/users01.dbf


Step 5. Take hot backup of users01.dbf datafile.
SQL> ALTER TABLESPACE users BEGIN BACKUP;
Tablespace altered.

SQL> ! cp /u01/app/oracle/oradata/prim/users01.dbf /u01/app/oracle/oradata/prim/users01_bkp.dbf

SQL> ALTER TABLESPACE users END BACKUP;

Tablespace altered.

Step 6. Find out the header block where the below table exists.
SQL> SELECT header_block FROM dba_segments WHERE segment_name='TBS_CORRUPTION ';

HEADER_BLOCK
------------
         706

[oracle@server1 ~]$ dd of=/u01/app/oracle/oradata/prim/users01.dbf bs=8192 conv=notrunc seek=707  <<EOF
> corruption
> EOF
0+1 records in
0+1 records out
11 bytes (11 B) copied, 7.5949e-05 s, 145 kB/s

[oracle@server1 ~]$ sqlplus /  as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Mon Jan 19 19:01:19 2015

Copyright (c) 1982, 2009, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> conn soumya/soumya
SQL> ALTER SYSTEM FLUSH BUFFER_CACHE;

System altered.

SQL> SELECT * FROM TBS_CORRUPTION;
SELECT * FROM TBS_CORRUPTION
              *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 4, block # 707)
ORA-01110: data file 4: '/u01/app/oracle/oradata/prim/users01.dbf'


SQL> exit

       
Step 7. Now we will try to recover the corrupted datablock.
[oracle@server1 ~]$ rman target sys

Recovery Manager: Release 11.2.0.1.0 - Production on Mon Jan 19 19:02:33 2015

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

target database Password:
connected to target database: PRIM (DBID=4130009889)

RMAN> BLOCKRECOVER DATAFILE 4 BLOCK 707;

Starting recover at 19-JAN-15
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=37 device type=DISK

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 01/19/2015 19:03:08
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 4 found to restore

Step 8.Catalog the “hot backup”
to the RMAN repository
RMAN> CATALOG DATAFILECOPY '/u01/app/oracle/oradata/prim/users01_bkp.dbf';

cataloged datafile copy
datafile copy file name=/u01/app/oracle/oradata/prim/users01_BKP.DBF RECID=2 STAMP=869425424

RMAN> BLOCKRECOVER DATAFILE 4 BLOCK 707;

Starting recover at 19-JAN-15
using channel ORA_DISK_1

channel ORA_DISK_1: restoring block(s) from datafile copy /u01/app/oracle/oradata/prim/users01_BKP.DBF

starting media recovery
media recovery complete, elapsed time: 00:00:03

Finished recover at 19-JAN-15

RMAN> EXIT

Step 9.Verify the data.
[oracle@server1 ~]$ sqlplus SOUMYA/SOUMYA

SQL*Plus: Release 11.2.0.1.0 Production on Mon Jan 19 19:04:08 2015

Copyright (c) 1982, 2009, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select * from TBS_CORRUPTION;

        ID
----------
         1

Related Posts Plugin for WordPress, Blogger...