Thursday, July 11, 2013

RMAN-05535: WARNING: All redo log files were not defined properly. ORACLE error from auxiliary database: ORA-19527: physical standby redo log must be renamed

When i am creating Standby database using RMAN active database option , it has thrown below Errors while creating online relogfiles .

ORACLE error from auxiliary database: ORA-19527: physical standby redo log must be renamed
ORA-00312: online log 1 thread 1: 'C:\ORACLE\ORADATA\DUMMY\REDO0101.LOG'

Solution

Use the log_file_name_convert option in RMAN duplicate command.

Ex:
RMAN>run
{
duplicate target database for standby from active database
spfile
set db_unique_name='dummy'
set control_files='M:\oracle\oradata\DUMMY\CONTROL01.CTL'
set log_file_name_convert='M:\oracle\oradata\DUMMY\',''M:\oracle\oradata\DUMMY\'
set instance_number='1'
nofilenamecheck;

}

Note: If you set the db_recovery_file_dest parameter RMAN will not give give above Error, By default online redo log files will be generated on db_recovery_file_dest parameter folder location .

Monday, July 8, 2013

ORA-19811: cannot have files in DB_RECOVERY_FILE_DEST with keep attributes

ORA-19811: cannot have files in DB_RECOVERY_FILE_DEST with keep attributes

Cause: When ever using keep option in Rman Backup Command with FRA (Flashback Recovery Area) as backup location above error will occur.



Solution: Either Remove the Keep option from RMAN Backup Command or Change the Backup location to other than FRA (While Restoring Register the backup sets).


Thursday, April 4, 2013

Flashback Database in Dataguard Environment (Dataguard Broker Configuration)

We have to follow the below steps to sync the standby database with Primary after flashback operation on Primary. Here we are used Dataguard Broker for Configuration.
Step-1

Do the Flashback operation on primary database.

SQL> select * from v$restore_point;

SCN       DATABASE_INCARNATION#   GUA STORAGE_SIZE TIME RESTORE_POINT_TIME                    PRE                 NAME

4127139        157286400                       YES              2                02-APR-13 01.05.40.000000000 AM      YES                FBTESTDG

SQL> shut immediate
SQL> startup mount
SQL> flashback database to restore point fbtestdg;
Flashback complete.
SQL> alter database open resetlogs;
Database altered.
SQL> archive log list
SQL> alter system switch logfile;

System altered.

Step-2

Check the status of Standby Database. It will give the Error Message.
DGMGRL> show configuration
Configuration - DG1
  Protection Mode: MaxPerformance
  Databases:
    ECPIX    - Primary database
    ECPIXSTB - Physical standby database
 Error: ORA-16810: multiple errors or warnings detected for the database
Fast-Start Failover: DISABLED
Configuration Status:
ERROR

Step-3

Flashback the Standby database to two less than production SCN i.e. 4127139-2=4127137
Sql> flashback database to scn 4127137;

Step-4

Enable redo apply for Standby database.
DGMGRL> show configuration
Configuration - DG1
  Protection Mode: MaxPerformance
  Databases:
    ECPIX    - Primary database
      Error: ORA-16778: redo transport error for one or more databases
    ECPIXSTB - Physical standby database
      Error: ORA-16766: Redo Apply is stopped
Fast-Start Failover: DISABLED
Configuration Status:
ERROR
DGMGRL> edit database ecpixstb set state=apply-on;
DGMGRL> show configuration
Configuration - DG1
 Protection Mode: MaxPerformance
 Databases:
  ECPIX    - Primary database
  ECPIXSTB - Physical standby database
 Fast-Start Failover: DISABLED
Configuration Status:
 SUCCESS

 

Wednesday, April 3, 2013

PRVF-7617 : Node connectivity between "SEZ08WTR-0723 : 192.168.3.***" and "SEZ08WTR-0724 : 192.168.3.***" failed TCP connectivity check failed for subnet




My Oracle 11G R2 GRID insttaltion failed at the end of the installation in windows 2008 R2 nodes with Oracle Cluster Verification Utility failed Error.
I clicked NEXT tab to proceed and completed INstallation. found below Errors in INstallActions.log

INFO: ERROR:

INFO: PRVF-7617 : Node connectivity between "SEZ08WTR-0723 : 192.168.3.198" and "SEZ08WTR-0724 : 192.168.3.199" failed

INFO: TCP connectivity check failed for subnet "192.168.3.0"

When I executed Cluvfy with post option given same Error and failed requisites.

cluvfy.bat stage -post crsinst -verbose -n SEZ08WTR-0723,sez08wtr-0724



If we proceed to create the database with the above Errors, It will create the problems.

In my case problem with host names  node 1 host name with all capital letters and Node 2 host name all small letters. But when i execute Cluvfy it is taking all capital letters (from domain) for host names and
checking prerequisites.

Solution:

I have changed my Second node host name to capital letters and tested Cluvfy, it went successful with out any Errors.





Thursday, March 28, 2013

Deleting Guaranteed Flashback restoepoints when v$restore_point view showing error

If you delete the flashback logs unexpectedly with out dropping Guaranteed Flashback Restore Points in Database, you will get following Error while select restore points from v$restore_point view.

SQL> select * from v$restore_point;
select * from v$restore_point
              *
ERROR at line 1:
ORA-38701: Flashback database log 142 seq 326 thread 1:
"C:\APP\ORACLE\FLASH_RECOVERY_AREA\ECPIX\FLASHBACK\O1_MF_8O59SSWM_.FLB"
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) The system cannot find the file specified.
Solution:

If we don't know restore points names, we can get the Restore points through RMAN Commands as mentioned below.

RMAN> list restore point all;
SCN              RSP Time  Type       Time      Name
---------------- --------- ---------- --------- ----
34541743                   GUARANTEED 28-MAR-13 BEFORE_CHANGES

Connect to sql prompt and drop the restore points.

SQL>drop restore point BEFORE_CHANGES;
SQL>select * from v$restore_point;


Note: After recieving this error if you turn off the flashback of the database, after that you can't turn on the flashback. To turn on the Flashback of database we have to drop the old restore points using above steps.



 

Thursday, March 21, 2013

ORA-00704: bootstrap process failure ORA-39700: database must be opened with UPGRADE option

Hi All,

To day I have faced the problem with  ORA-00704: bootstrap process failure ORA-39700: database must be opened with UPGRADE option errors while opening the database which is created newly.
There may be 3 possibilites to get above errors. I have solved my problem by using 3 rd option.

1) giving wrong or old ORACLE_HOME or PATH variables while opening newly upgraded DAtabase.
Solution:
set or export ORACLE_HOME= <newly upgraded ORACLE_HOME>
set or export PATH=<newly upgraded PATH variables>

2) After upgraing the ORACLE_HOME, if you missed to run catupgrd.sql script, we will get above errors while starting the datbase.

Solution:

sqlplus / as sysdba
sql>startup upgrade
sql>@<ORACLE_HOME>/rdbms/admin/catupgrd.sql
sql>@<ORACLE_HOME>/rdbms/admin/utlrp.sql
sql>shut immediate
sql>startup

3) After creation of new database if we missed to execute catalog.sql,catproc.sql or  executed with errors also we will get above errors.

Solution:

sqlplus / as sysdba
sql>startup upgrade
sql>@<ORACLE_HOME>/rdbms/admin/catalog.sql
sql>@<ORACLE_HOME>/rdbms/admin/catproc.sql
sql>shut immediate
sql>startup