Thursday, April 17, 2014

OGG-01296 Error mapping from SAP.BHU1000 to SAP_SCHEMA.BHU1000

  OGG-01296  Error mapping from SAP.BHU1000 to SAP_SCHEMA.BHU1000

Situation
We have added new tables to the existing Extract & Replicate. after adding the tables in the replicate, Replicate got aborted with the below error message.


2014-04-17 14:23:19  WARNING OGG-00869  No unique key is defined for table 'BHU1000'. All viable columns will be used to represent the key, but may not guarantee uniqueness.  KEYCOLS may be used to define the key.
2014-04-17 14:23:19  WARNING OGG-01503  Aborting BATCHSQL transaction. Mapping error.
2014-04-17 14:23:19  WARNING OGG-01137  BATCHSQL suspended, continuing in normal mode.
2014-04-17 14:23:19  WARNING OGG-01003  Repositioning to rba 95972561 in seqno 309.
2014-04-17 14:23:19  WARNING OGG-01431  Aborted grouped transaction on 'SAP_SCHEMA.BHU1000', Mapping error.
2014-04-17 14:23:19  WARNING OGG-01003  Repositioning to rba 95972561 in seqno 309.
2014-04-17 14:23:19  WARNING OGG-01151  Error mapping from SAP.BHU1000 to SAP_SCHEMA.BHU1000.
2014-04-17 14:23:19  WARNING OGG-01003  Repositioning to rba 95972561 in seqno 309.
Source Context :
  SourceModule            : [er.errors]
  SourceID                : [/scratch/aime1/adestore/views/aime1_adc4150256/oggcore/OpenSys/src/app/er/errors.cpp]
  SourceFunction          : [take_rep_err_action]
  SourceLine              : [632]
  ThreadBacktrace         : [8] elements
                          : [/oracle/product/ggs_112105/CRIC1/libgglog.so(CMessageContext::AddThreadContext()+0x1e) [0x2b83a93900de]]
                     : [/oracle/product/ggs_112105/CRIC1/libgglog.so(CMessageFactory::CreateMessage(CSourceContext*, unsigned int, ...)+0x2cc) [0x2b83a9388dfc]]
                          : [/oracle/product/ggs_112105/CRIC1/libgglog.so(_MSG_ERR_MAP_TO_TANDEM_FAILED(CSourceContext*, ggs::gglib::ggapp::CQualDBObjName<(DBObjType)1
> const&, ggs::gglib::ggapp::CQualDBObjName<(DBObjType)1> const&, CMessageFactory::MessageDisposition)+0x53) [0x2b83a9384cc7]]
                          : [/oracle/product/ggs_112105/CRIC1/replicat(take_rep_err_action(short, int, char const*, extr_ptr_def*, __std_rec_hdr*, char*, file_def*, bo
ol)+0xaa5) [0x520cc1]]
                          : [/oracle/product/ggs_112105/CRIC1/replicat(process_extract_loop()+0x2e42) [0x53ad82]]
                          : [/oracle/product/ggs_112105/CRIC1/replicat(main+0x732) [0x54bf02]]
                          : [/lib64/libc.so.6(__libc_start_main+0xf4) [0x3cd661d9c4]]
                          : [/oracle/product/ggs_112105/CRIC1/replicat(__gxx_personality_v0+0x31a) [0x4c035a]]

2014-04-17 14:23:19  ERROR   OGG-01296  Error mapping from SAP.BHU1000 to SAP_SCHEMA.BHU1000.

FINDING & SOLUTION
1)      We found that table doesn’t have any primary key columns
2)      We found that table has 4 indexes in the source side (extract) but no indexes created on the replicate side while adding tables in the replicate.
3)      We found multiple check constraints are created but no primary key constraints.

We have created all the indexes on the target side (Replicat database) for the table(similar one like source) and try to start the replicate.
We found apply process goes fine and that solves the problem.

Happy reading JJJ

Monday, November 11, 2013

Error: ORA-16651: requirements not met for enabling fast-start failover

When I try to enable the fast start failover in the data guard below I got the below error message
Error: ORA-16651: requirements not met for enabling fast-start failover
DGMGRL> show configuration;
Configuration - DG_BHU
  Protection Mode: MaxAvailability
  Databases:
    BHU_A - Primary database
    BHU_B - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
DGMGRL> show fast_start failover;
Fast-Start Failover: DISABLED
  Threshold:        90 seconds
  Target:           (none)
  Observer:         Bhuvan_observer
  Lag Limit:        30 seconds
  Shutdown Primary: TRUE
  Auto-reinstate:   TRUE
Configurable Failover Conditions
  Health Conditions:
    Corrupted Controlfile          YES
    Corrupted Dictionary           YES
    Inaccessible Logfile            NO
    Stuck Archiver                  NO
    Datafile Offline               YES

  Oracle Error Conditions:
    (none)

DGMGRL> enable fast_start failover;
Error: ORA-16651: requirements not met for enabling fast-start failover

Failed.

SOLUTION
1)  Check whether the flashback database is enabled on primary & standby database
Select flashback_on from gv$database;

2) Check whether you have set the FastStartFailoverTarget parameter.
Ex:
 edit database 'BHU_A' set property FastStartFailoverTarget='BHU_B';
edit database 'BHU_B' set property FastStartFailoverTarget='BHU_A';

Monday, August 12, 2013

RMAN-05541: no archived logs found in target database






This is very interesting error message while performing RMAN Duplication of full database
I have taken a full database backup in a local disk including archive log; when i try to restore the production database in the test environment it has thrown below error message.

ERROR MESSAGE DURING RMAN DUPLICATION
RMAN-01005: Errors in memory script
RMAN-01005: RMAN-03015: error occurred in stored script Memory Script
RMAN-06136: ORACLE error from auxiliary database: ORA-01507: database not mounted
ORA-06512: at "SYS.X$DBMS_RCVMAN", line 13466
ORA-06512: at line 1
RMAN-05541: no archived logs found in target database

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 08/06/2013 13:56:37
RMAN-05501: aborting duplication of target database

BACKUP START AT: 13:00.00 and completed at 15:30. RMAN looking for the archive log backup files from 12:50:00 to 13.10.00(I have supplied 10 min before & after the backup)

SUGGESTION#1
CHECK THE BACKUP FILES PERMISSION AS A FIRST THINGS

SUGGESTION#2
1) Perform switch log file before start the backup

2) After a long struggle; we found that RMAN is looking for some old archive logs during the start of the hot backup; once we place the old archive log backup in the backup area then RMAN duplication script started working fine. i doesn’t know why RMAN expecting the old archive log files before the backup start; that how it is working in oracle 11gR2(11.2.0.3.0)



Friday, August 9, 2013

ORA-16795: the standby database needs to be re-created


DB CONFIGURATION
2 node primary database
2 node standby database
Fast_Start FailOver(observer)- Enabled

BHU_A è Primary database
BHU_B è standby database

n  Due to the network issues, FSFO failover the standby database (BHU_B) as a new primary and old primary database (BHU_A) is in the mount stage.


oracle BHU bhuora001> dgmgrl
DGMGRL for Linux: Version 11.2.0.3.0 - 64bit Production

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

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys /xxxxxxxxxxxxxx
Connected.

DGMGRL> show configuration

Configuration - DG_BHU

  Protection Mode: MaxAvailability
  Databases:
    BHU_B - Primary database
      Warning: ORA-16817: unsynchronized fast-start failover configuration

    BHU_A - (*) Physical standby database (disabled)
      ORA-16795: the standby database needs to be re-created

Fast-Start Failover: ENABLED

Configuration Status:
WARNING


n  We check the flashback enabled option on both old & new primary. We are showing the output of new primary database

SQL> select flashback_on from v$database;

FLASHBACK_ON
------------------
YES


n  On the NEW PRIMARY SITE; check when the conversion happened(standby to primary) and you can see the time by looking to scn_to_timestamp conversion.

SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;

TO_CHAR(STANDBY_BECAME_PRIMARY_SCN)
----------------------------------------
12788498729592

SQL> SELECT SCN_TO_TIMESTAMP(12788498729592) from dual;

SCN_TO_TIMESTAMP(12788498729592)
---------------------------------------------------------------------------
08-AUG-13 22.04.00.000000000



On the OLD PRIMARY DATABASE(BHU_A). Check the status of database


SQL> select name,open_mode,database_role from gv$database;

NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
BHU    MOUNTED              PRIMARY


SQL> select flashback_on from v$database;

FLASHBACK_ON
------------------
YES

n When we try to check  CURRENT_SCN number on the old primary and it has displayed as “0”

SQL> select current_scn from v$database;

CURRENT_SCN
-----------
          0

Now, We are converting the old primary database as a NEW STANDBY DATABASE

n  We are mounting the database first

SQL> shutdown immediate;
ORA-01109: database not open


Database dismounted.
ORACLE instance shut down.

SQL> startup mount;
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.

Total System Global Area 2271580160 bytes
Fixed Size                  2230352 bytes
Variable Size            1191184304 bytes
Database Buffers         1073741824 bytes
Redo Buffers                4423680 bytes
Database mounted.

n  We have identified the failover time from the new database. so we will use that time to flashback the old primary database; we have add 20 further to actual time.

SQL> FLASHBACK DATABASE TO TIMESTAMP to_timestamp('2013-08-08 21:50:00', 'YYYY-MM-DD HH24:MI:SS');

Flashback complete.

n  We are checking the current role before converting the old primary to new standby database.

SQL> select name,open_mode,database_role from v$database;

NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
BHU    MOUNTED              PRIMARY

n  Converting database to standby database.

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

Database altered.

n  We are checking the current role after converting the old primary to new standby database.

SQL> select name,open_mode,database_role from v$database;
select name,open_mode,database_role from v$database
                                         *
ERROR at line 1:
ORA-01507: database not mounted


n  After converting the database; database will go to nomount stage; so we have to stop & start the database.

SQL> shutdown immediate;
ORA-01507: database not mounted


ORACLE instance shut down.
SQL> startup mount;
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.

Total System Global Area 2271580160 bytes
Fixed Size                  2230352 bytes
Variable Size            1191184304 bytes
Database Buffers         1073741824 bytes
Redo Buffers                4423680 bytes
Database mounted.

SQL> select name,open_mode,database_role from v$database;

NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
BHU    MOUNTED              PHYSICAL STANDBY


n  We could see the current status of the old primary as new standby database.
n  Now we are login to the dg broker to enable the new standby database

DGMGRL> enable database 'BHU_A';
Enabled.

n  Once enabled, oracle will take some time to apply the logs till the current time


DGMGRL> show configuration;

Configuration - DG_BHU

  Protection Mode: MaxAvailability
  Databases:
    BHU_B - Primary database
      Warning: ORA-16817: unsynchronized fast-start failover configuration

    BHU_A - (*) Physical standby database
      Warning: ORA-16817: unsynchronized fast-start failover configuration

Fast-Start Failover: ENABLED

Configuration Status:
WARNING

n  Now primary database & standby database are in sync.

DGMGRL> show configuration;

Configuration - DG_BHU

  Protection Mode: MaxAvailability
  Databases:
    BHU_B - Primary database
    BHU_A - (*) Physical standby database

Fast-Start Failover: ENABLED

Configuration Status:
SUCCESS






Friday, October 26, 2012

ORA-16649: possible failover to another database prevents this database from being opened


We have two-node primary RAC database & two-node standby RAC database. For the business testing purpose, they will want both side of the database in the READ WRITE Mode. So we have decided to disabled the log shipping and made the standby database as a new primary database using failover database.
During the standby failover process, we made the existing primary database down. We have successfully failover the standby database as a new primary database. Once the process completed, we have disabled the DG configuration.

When we try to start the old primary database, we go the below error message. After analyzing further, we found the DG configuration file has been update from the standby database DG configuration file. Since the standby database become a new primary. So it has update the DG configuration file in the old primary database.
ORA-16649: possible failover to another database prevents this database from being opened

SOLUTION

After disabling the DG_BROKER_START=FALSE;  the old primary database able to start in the READ WRITE mode.

SQL> startup force
ORACLE instance started.
Total System Global Area 7.2958E+10 bytes
Fixed Size                  2235808 bytes
Variable Size            1.9059E+10 bytes
Database Buffers         5.3687E+10 bytes
Redo Buffers              209866752 bytes
Database mounted.
ORA-16649: possible failover to another database prevents this database from being opened

SQL> select database_role from v$database;
DATABASE_ROLE
----------------
PRIMARY

SQL> alter system set dg_broker_start=false scope=both sid='*';
System altered.

SQL> alter database open;
Database altered.

Friday, October 12, 2012

ORA-16649: possible failover to another database prevents this database from being opened


We have two node primary & standby RAC. It is in sync and i have to split the primary database & standby database.

I have shutdown the primary database and went to the standby database server.
I logged in as DGMGRL and performed a fail over to the standby. Now the standby database become a primary database. Once i complete the failover; i have disabled the DG configuration using the DG broker.

When i try to started the old primary which i have shutdown before performing a failover to the standby. I got a error message saying  “ORA-16649: possible failover to another database prevents this database from being opened”

SQL> startup force
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.
Total System Global Area 7.2958E+10 bytes
Fixed Size                  2235808 bytes
Variable Size            1.9059E+10 bytes
Database Buffers         5.3687E+10 bytes
Redo Buffers              209866752 bytes
Database mounted.
ORA-16649: possible failover to another database prevents this database from being opened

WHEN I CHECKED THE DB ROLE; it is primary
SQL> select database_role from v$database;
DATABASE_ROLE
----------------
PRIMARY

Then i managed to find that database control file get the information from the DG broker config file. So i have disable the config file on the primary database.

SQL> alter system set dg_broker_start=false scope=both sid='*';

System altered.

-         After disabling the DG broker; i can able to open the database without any issue.
SQL> alter database open;
Database altered.

Thursday, September 20, 2012

index Rebuild - Progress & Index creation Progress

To identify the index rebuild progress.

i have used the oracle schema to identify the session which are active in nature.

Note: For some reason V$SESSION_LONGOPS doesn't show the progress of index Rebuild process. use the below query for index rebuild. index creation can be seen in the below query and other query with the
V$SESSION_LONGOPS


SQL> SELECT MESSAGE FROM V$SESSION_LONGOPS WHERE SID IN (SELECT SID FROM V$SESSION WHERE USERNAME='BHUVAN' AND STATUS='ACTIVE') ORDER BY START_TIME;

MESSAGE
-----------------------------------------------------------------------------------Table Scan:  (stale or locked) obj# 31940: 1426408 out of 1426408 Blocks done
Table Scan:  BHUVAN.EMP: 2388523 out of 2388523 Blocks done
Sort Output:  : 235280 out of 235280 Blocks done
Table Scan:  BHUVAN.EMP: 154318 out of 2388523 Blocks done

-- i have merge active session with the V$SESSION_LONGOPS view to retrieve progress of index creation with the index creation syntax.


SQL> col a.sid format 9999
SQL> select a.sid, sql_text ,target, sofar, totalwork, time_remaining still, elapsed_seconds tillnow
  2  from v$session a ,  v$sql b, v$session_longops c
  3  where a.sid=c.sid
  4  and a.sql_address = b.address
  5  and a.sql_address = c.sql_address
and status  = 'ACTIVE';
 SID
SQL_TEXT
TARGET                                                                SOFAR  TOTALWORK      STILL    TILLNOW
---------------------------------------------------------------- ---------- ------ 366
CREATE INDEX "EMP~EXT" ON "EMP" ("CLIENT", "BPEXT") PCTFREE 10 INITRANS 002 TABLESPACE PBHUVAN COMPRESS 2 STORAGE (INITIAL 0000000064 K NEXT 0000001024 K MINEXTENTS 0000000001 MAXEXTENTS UNLIMITED PCTINCREASE 0000 FREELISTS 001)
BHUVAN.EMP                                                        894046    2388523        563        337


Hope this help you..... Happy Learning