Log shipping not happening from Primary DB to Standby DB [message #656856] |
Thu, 20 October 2016 08:21 ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
![](//www.gravatar.com/avatar/cafd3e3c0cb0b8569708b7bae6a7d6e4?s=64&d=mm&r=g) |
Mythili Gopisetty
Messages: 8 Registered: October 2016
|
Junior Member |
|
|
Hi Experts,
We have using SAP PI system with Oracle as database, which is having both Primary and Standby DB.
Recently there was a failover between primary and standby, the failover is caused due to sudden reboot of primary db.
Here the problem is we had switched over, but standby db is not getting logs from Primary no shipping was happening and it was showing like Control file corrupted so we had recovered the DB and control file from primary db.
Now no log shipping is happening between primary and standby after recovering also.
Regards,
Mythili G
|
|
|
|
|
|
|
|
|
|
|
Re: Log shipping not happening from Primary DB to Standby DB [message #656977 is a reply to message #656880] |
Tue, 25 October 2016 00:07 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
![](//www.gravatar.com/avatar/cafd3e3c0cb0b8569708b7bae6a7d6e4?s=64&d=mm&r=g) |
Mythili Gopisetty
Messages: 8 Registered: October 2016
|
Junior Member |
|
|
Hi John,
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE; has worked and the logs are shipping now.
but there is a huge gap MRP process is in waiting status only. I has checked for the gap is
THREAD# LowGap# HighGap#
---------- ---------- ----------
1 7 70
SQL> select name,db_unique_name,open_mode,database_role,switchover_status from v$database;
NAME DB_UNIQUE_NAME OPEN_MODE DATABASE_ROLE SWITCHOVER_STATUS
--------- ------------------------------ -------------------- ---------------- --------------------
PI3 PI3_p READ WRITE PRIMARY UNRESOLVABLE GAP
how to resolve this unresolvable gap.
FAL parameter is active but i could see error as below.
Trace file E:\ORACLE\PI3\SAPTRACE\diag\rdbms\pi3_p\pi3\trace\pi3_fal_4260.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Windows NT Version V6.1 Service Pack 1
CPU : 8 - type 8664, 8 Physical Cores
Process Affinity : 0x0x0000000000000000
Memory (Avail/Total): Ph:11730M/16383M, Ph+PgF:35156M/41381M
VM name : VMWare Version (6)
Instance name: pi3
Redo thread mounted by this instance: 1
Oracle process number: 71
Windows thread id: 4260, image: ORACLE.EXE (SHAD)
*** 2016-10-25 05:35:31.449
*** SESSION ID:(354.5267) 2016-10-25 05:35:31.449
*** CLIENT ID:() 2016-10-25 05:35:31.449
*** SERVICE NAME:(PI3_p) 2016-10-25 05:35:31.449
*** MODULE NAME:(ORACLE.EXE) 2016-10-25 05:35:31.449
*** ACTION NAME:() 2016-10-25 05:35:31.449
FAL Redo Shipping Client Established Network Login
Failed to queue the whole gap
GAP - thread 1 sequence 6-70
DBID 1471204172 branch 925468071
Regards,
Mythili G
|
|
|
|
|
Re: Log shipping not happening from Primary DB to Standby DB [message #657027 is a reply to message #657018] |
Wed, 26 October 2016 07:12 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
John Watson
Messages: 8964 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
Mythili, you have to learn to read. I said this,
Quote:drop the standby and create it again
Data Guard Broker says this,
Quote: the standby database needs to be re-created
Does that give you an idea of what you should do?
However, there is something you should do first. You should inform your employer that his very expensive and (presumably) mission critical database is, right now, vulnerable to a loss of data and downtime in the event of any problems. You should also explain that you are not at the moment competent to deal with this, and that he should hire a consultant to sort out the mess while you attend a course to upgrade your skills. In the meantime, you might want to consider shutting down the database. You are operating in a risky situation.
|
|
|
|